New package: passt-2023.03.09.7c7625d #42517
Conversation
srcpkgs/passt/template
Outdated
| version=2023.02.27.c538ee8 | ||
| revision=1 | ||
| # upstream uses YYYY_MM_DD.COMMIT | ||
| _version=${version/./_} | ||
| _version=${_version/./_} |
There was a problem hiding this comment.
Debian seems to use 0.0~gitYYYYMMDD, Fedora uses 0^YYYYMMDD, I think we should go with them. As those version was listed as official in passt homepage?
There was a problem hiding this comment.
That's going to make converting to the YYYY_MM_DD format upstream uses for its tags even more inconvenient I think.
Or are you mainly suggesting prepending a 0-Version number in case they start using proper version?
There was a problem hiding this comment.
By the way, Debian package versions are formed with this uscan rule:
options="uversionmangle=s/_//g; s/^/0.0~git/"
and this is the rpkg macro for Fedora:
printf "0^%s.g%s" "$(date -uI -d "${__date}" | tr -d -)" "${__commit}"
those are just to comply with distribution guidelines, there's no particular reason why. Upstream versions (tags) simply uses YYYY_MM_DD.SHORT_SHA as you noted because I find it more readable.
Or are you mainly suggesting prepending a 0-Version number in case they start using proper version?
There are no plans to switch to semantic versioning or suchlike. The current agreement, for the foreseeable future, is that dates are more meaningful than version numbers, yet should be readable enough, and the SHA immediately and uniquely identifies tags. We have no branches or "stable" releases, so that's quite convenient.
But sure, prepending a 0 is probably not a bad idea, even though it's a bit less readable. If we ever switch to a different scheme, we could also start with a 3.
There was a problem hiding this comment.
@sbrivio-rh thanks for checking in. I can live with the current format. It's just that we don't allow - and _ in the version part, so we can unambiguously match it. And if no semantic (that's the correct word, not "proper" :) ) versioning is planned, I think it's best to keep the ., since they allow me to generate the format with built-ins.
Getting musl support would be nice though, but I failed to find the correct includes for __bswap_constant_16 for example.
There was a problem hiding this comment.
I think it's best to keep the ., since they allow me to generate the format with built-ins.
Sure, it looks a bit nicer too.
Getting musl support would be nice though, but I failed to find the correct includes for __bswap_constant_16 for example.
I guess that needs something like this -- probably a good fit for util.h.
In general I'd say we should carry own implementations for fundamental things like that (we really shouldn't swap those values at runtime), and instead change whatever code we didn't write in a portable way by mistake.
There was a problem hiding this comment.
See also https://bugs.passt.top/show_bug.cgi?id=4#c1 (!)
|
Added the patch from https://bugs.passt.top/show_bug.cgi?id=4#c1. With that it compiled on --- musl.patch 2023-03-02 20:11:41.273250878 +0100
+++ musl-limits.patch 2023-03-02 20:12:16.791228390 +0100
@@ -41,7 +41,7 @@
#include <stdbool.h>
-
-+#include <bits/limits.h>
++#include <limits.h>
#include "packet.h"
#include "icmp.h"
#include "port_fwd.h"This is looking promising. Looks to me we can afford to wait for |
|
Building against musl is now fixed in upstream version 2023_03_09.7c7625d |
lemmi
changed the title
3 participants
podman-v4.4.0 added support for pasta with containers/podman#16141. It's interesting for proper IPv6 forwarding with rootless containers.
There is an open issue for
muslsupport.Testing the changes
New package