[aur-general] TU Application: Baptiste Jonglez
Hello, I would like to apply to become a TU. Lukas Fleischer has kindly accepted to sponsor my application. I am currently a PhD student in France, doing research on networking. I am also involved in several projects, in particular DIY ISPs [1], the FDN Federation in France [2], OpenWRT/LEDE [3], etc. The common motivation is to work towards a more open and decentralised Internet. I have been using Arch Linux on my personal laptops since around 2010. I think I have never had to reinstall Arch Linux on my main laptop since then! In the past, I was also running Arch Linux on my servers, but I since switched to Debian for all my servers. By the way, I am not very active on the mailing lists, but I read most threads on aur-general and arch-dev-public. In the AUR, I maintain 33 packages [4], of which the most noteworthy are: - ring: a secure and distributed voice/video/chat communication software (Ring is the successor of SFLphone, basically using a DHT to find contacts instead of relying on SIP servers, and tons of other improvements) - coq: a formal proof assistant written in Ocaml - linux-mptcp: the linux kernel with support for Multipath TCP, from Université Catholique de Louvain The other packages I maintain are either dependencies of the above, or small software tools that I packaged when I needed them. I regularly use about 2/3 of these packages, but I still try to maintain the other ones. I mostly want to become a TU to push ring, coq and linux-mptcp to the [community] binary repository. These packages all take a fairly long time to build, and additionally the Ring packages are a dependency nightmare. It is often necessary for users to rebuild all dependencies simultaneously because of API/ABI changes, and this is impractical and time-consuming when using the AUR, especially given the number of dependencies. Regarding linux-mptcp, it is not popular enough at the moment, and there are few kernel packages in binary repositories. I would wait for the package to obtain 10 votes (and confirmation that another kernel package is indeed welcome in the repositories) before pushing it to [community]. As a final note, I am already using the devtools to test-build my AUR packages in clean chroots on a server. This provides some form of "continuous integration" of my AUR packages, although it is not completely satisfying right now. Don't hesitate if you have any questions, or comments on my AUR packages! Baptiste [1] https://diyisp.org/dokuwiki/doku.php [2] https://www.ffdn.org/en [3] https://lede-project.org/ [4] https://aur.archlinux.org/packages/?O=0&SeB=m&K=zorun&SB=v&SO=d
Hi Bapiste,
Don't hesitate if you have any questions, or comments on my AUR packages!
Sure, I always take a look at all packages of an applicant and suggest changes before I decide how to vote... so here we go :P Excuse me if I copy-paste some blocks, its just simpler doing so :) ring-daemon: - just a feeling but a description with 202 chars feels quite long :P opendht: - you should use git+https:// instead of plain git:// even through the CA world is a bit wonky it still authenticates the server and at the very bare minimum adds confidentiality. sig2dot - every reference to $pkgdir should be put inside double-quotes in case it contains spaces. pjproject - if you must use -j1 for every make call, you can simply add !makeflags to the options instead. opendht-git - you should use git+https:// instead of plain git:// even through the CA world is a bit wonky it still authenticates the server and at the very bare minimum adds confidentiality. pius - documentation, or hint to documentations inside .install files always feels like the wrong place. If there is documentation in /usr/share/doc/pius then people will find it. linux-mptcp - you should use git+https:// instead of plain git:// even through the CA world is a bit wonky it still authenticates the server and at the very bare minimum adds confidentiality. - #tag= should never be used for git packages, instead store the commit hash for the tag and always use the #tag= prefix. A named tag does not mean much and you won't even notice when upstream changes such. This is especially bad when using plain git:// :-) - You should add an initramfs post transaction hook like in the regular kernel [0] to avoid problems like described in #51818. coq-doc - the sources must be prefixed with the version as otherwise older tarballs will "conflict". on top of that "stdlib.tar.gz" sounds a bit too generic and may overlap with another package, conisder also including the package name into the prefix to avoid such situation. asio-latest - you should use git+https:// instead of plain git:// even through the CA world is a bit wonky it still authenticates the server and at the very bare minimum adds confidentiality. - every reference to $pkgdir should be put inside double-quotes in case it contains spaces. ring-gnome-git - a VCS package should always provide its non-VCS package variant like 'ring-gnome' - the pkgver() function doesn't sound specific enough, it just returns a simple date without anything else (f.e. 20161110) which means building on the same date can result in the same package version while being built from quite different source states. restbed-latest - you should use git+https:// instead of plain git:// even through the CA world is a bit wonky it still authenticates the server and at the very bare minimum adds confidentiality. restbed - #tag= should never be used for git packages, instead store the commit hash for the tag and always use the #tag= prefix. A named tag does not mean much and you won't even notice when upstream changes such. kashmir - you should use git+https:// instead of plain git:// even through the CA world is a bit wonky it still authenticates the server and at the very bare minimum adds confidentiality. udrawgraph - just a bit of style, but we have arch specific depends like depends_x86_64 which looks better :P - every reference to $pkgdir should be put inside double-quotes in case it contains spaces. - every reference to $srcdir should be put inside double-quotes in case it contains spaces. ring-daemon-git - a VCS package should always provide/conflicts its non-VCS package variant like 'ring-daemon' - just a feeling but a description with 202 chars feels quite long :P - the pkgver() function doesn't sound specific enough, it just returns a simple date without anything else (f.e. 20161110) which means building on the same date can result in the same package version while being built from quite different source states. libringclient-git - a VCS package should always provide its non-VCS package variant like 'libringclient' - If there is no strong reason to depend on a git variant, always depend on the non VCS, in this case ring-daemon instead of ring-daemon-git - the pkgver() function doesn't sound specific enough, it just returns a simple date without anything else (f.e. 20161110) which means building on the same date can result in the same package version while being built from quite different source states. npiet - every reference to $pkgdir should be put inside double-quotes in case it contains spaces. tsocks-ipv6 - this looks like it should also provide tsocks as it just adds additional v6 support iproute-mptcp - sources that are not unique (like "/v$pkgver.tar.gz" from github) should be prefixed with the package name (+ of cause pkgver) to be unique. This is important if you configures shared SRCDEST to avoid conflicts. bdsync - sources that are not unique (like "/v$pkgver.tar.gz" from github) should be prefixed with the package name (+ of cause pkgver) to be unique. This is important if you configures shared SRCDEST to avoid conflicts. net-tools-mptcp - #branch= should never be used for non VCS git packages, instead store the commit hash for the tag and always use the #tag= prefix. A named branch does not mean much and you won't even notice when upstream changes or adds commits to such. - you should use git+https:// instead of plain git:// even through the CA world is a bit wonky it still authenticates the server and at the very bare minimum adds confidentiality. cheers, Levente [0] https://git.archlinux.org/svntogit/packages.git/commit/trunk/80-linux.hook?h=packages/linux&id=617173dcde960f00112ebdfee4c80ede71e67375 [1] https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/
On 11/28/2016 06:20 AM, Levente Polyak wrote:
linux-mptcp - you should use git+https:// instead of plain git:// even through the CA world is a bit wonky it still authenticates the server and at the very bare minimum adds confidentiality.
Now that you mention it, this does seem rather obvious... maybe I should switch my own AUR packages to do this. It is just as fast, so there is no real downside. Now I'm glad I read these threads!
- #tag= should never be used for git packages, instead store the commit hash for the tag and always use the #tag= prefix.
Typo?
A named tag does not mean much and you won't even notice when upstream changes such. This is especially bad when using plain git:// :-)
Well, I should hope upstream doesn't re-release their tags... if so, you might have other problems. Anyway, I would instead suggest that there is no need to pull the source code for stable releases via git (which for long-lived projects like the Linux kernel means a *lot* of history to download). I can barely understand that, in the case of e.g. systemd which uses git to backport commits. Although really, github allows you to download a commit as a patch file... I usually only see that in repo PKGBUILDs. I guess since the devs are usually the only ones building the package, and the dev keeps the clone around, it "doesn't matter" that hypothetical others would have to clone all that history? But from the repo PKGBUILDs I have seen, it seems to me as though there is no policy whatsoever... some devs do like you suggest, other devs are more than happy to use "#tag=$pkgver".
udrawgraph - just a bit of style, but we have arch specific depends like depends_x86_64 which looks better :P
That isn't "style", that is something that *must* be done, for practical purposes. makepkg --printsrcinfo relies on arch-dependent variables that are *always* there, in order to actually print truthful values. Also, arch-dependent sources done properly will allow updpkgsums to properly update, rather than merging the local *sums_$CARCH into the main checksums array. All that matters a lot in the AUR, which depends on .SRCINFO, even if it doesn't matter so much in the repos which depend on the metadata in a built package.
net-tools-mptcp - #branch= should never be used for non VCS git packages, instead store the commit hash for the tag and always use the #tag= prefix. A named branch does not mean much and you won't even notice when upstream changes or adds commits to such.
It has a pkgver() function which generates a VCS-style pkgver, and draws from a #branch= so actually it is a VCS git package. The problem is that it doesn't say so in the pkgname. :p -- Eli Schwartz
On 11/28/2016 05:05 PM, Eli Schwartz via aur-general wrote:
On 11/28/2016 06:20 AM, Levente Polyak wrote:
- #tag= should never be used for git packages, instead store the commit hash for the tag and always use the #tag= prefix.
Typo?
uuups, you caught me :P My bad! Of cause this should be #commit= Thanks Eli!
A named tag does not mean much and you won't even notice when upstream changes such. This is especially bad when using plain git:// :-)
Well, I should hope upstream doesn't re-release their tags... if so, you might have other problems.
Well I already encountered a re-release at least twice, shame on them! When using a commit hash you gain basically two things out of the box: - get aware if wonky upstream changes something - get an integrity value that a potential attacker must defeat, which not be the easiest task for a full commit hash (for a short partial hash there are of cause some PoC's/tools available)
But from the repo PKGBUILDs I have seen, it seems to me as though there is no policy whatsoever... some devs do like you suggest, other devs are more than happy to use "#tag=$pkgver".
Well i assume "more happy" just means "able to be more lazy" (without any offense to anyone!) :P In fact we already had several discussions in the IRC about this topic and what I mentioned above was always sufficient to justify getting rid of it. The only reason we don't yet have a TODO list to switch away from #tag= is simply lack of time (but its still on my todo list besides getting a TODO list for git:// sources). If a remember correctly either heftig or JGC has created a convenience script to update a PKGBUILDs values, maybe they share it with us :)
udrawgraph - just a bit of style, but we have arch specific depends like depends_x86_64 which looks better :P
That isn't "style", that is something that *must* be done, for practical purposes. makepkg --printsrcinfo relies on arch-dependent variables that are *always* there, in order to actually print truthful values. Also, arch-dependent sources done properly will allow updpkgsums to properly update, rather than merging the local *sums_$CARCH into the main checksums array.
All that matters a lot in the AUR, which depends on .SRCINFO, even if it doesn't matter so much in the repos which depend on the metadata in a built package.
Fair enough... that's a pretty good point why it should be mandatory. Did not really take the .SRCINFO into account for this particular case.
net-tools-mptcp - #branch= should never be used for non VCS git packages, instead store the commit hash for the tag and always use the #tag= prefix. A named branch does not mean much and you won't even notice when upstream changes or adds commits to such.
It has a pkgver() function which generates a VCS-style pkgver, and draws from a #branch= so actually it is a VCS git package. The problem is that it doesn't say so in the pkgname. :p
Well yes... and no... though the same while looking at it but at the end I'm not quite sure what the intention of Baptiste is. As the branch used is a simple version identifier, I assumed he pretty much wanted to have a static versioned package. pkgver() itself does not tell us which one it should be, if you have a static version package that pulls from a git commit hash you can have a pkgver() function for convenience. cheers, Levente
On 11/28/2016 11:26 AM, Levente Polyak wrote:
When using a commit hash you gain basically two things out of the box: - get aware if wonky upstream changes something - get an integrity value that a potential attacker must defeat, which not be the easiest task for a full commit hash (for a short partial hash there are of cause some PoC's/tools available)
Hmm, that is true. git has builtin integrity checks but also ends up almost completely lacking in any capacity for authentication. At least as far as makepkg is concerned. As a user, I think I would still prefer tarballs rather than unnecessary git history... but if you must use git for non-VCS packages then commit hashes are useful.
In fact we already had several discussions in the IRC about this topic and what I mentioned above was always sufficient to justify getting rid of it. The only reason we don't yet have a TODO list to switch away from #tag= is simply lack of time (but its still on my todo list besides getting a TODO list for git:// sources).
If a remember correctly either heftig or JGC has created a convenience script to update a PKGBUILDs values, maybe they share it with us :)
That is very interesting information, thanks for mentioning it. My curiosity is now sated. :)
net-tools-mptcp - #branch= should never be used for non VCS git packages, instead store the commit hash for the tag and always use the #tag= prefix. A named branch does not mean much and you won't even notice when upstream changes or adds commits to such.
It has a pkgver() function which generates a VCS-style pkgver, and draws from a #branch= so actually it is a VCS git package. The problem is that it doesn't say so in the pkgname. :p
Well yes... and no... though the same while looking at it but at the end I'm not quite sure what the intention of Baptiste is. As the branch used is a simple version identifier, I assumed he pretty much wanted to have a static versioned package. pkgver() itself does not tell us which one it should be, if you have a static version package that pulls from a git commit hash you can have a pkgver() function for convenience.
I have noticed that trick in repo packages, yeah. But this is pulling from a branch... anything that has changing sources would be VCS, except that without both #branch= and a pkgver() it is merely broken beyond repair. Now, while some projects do use versioned branches to separate development on apparently incompatible release branches, it could be that this upstream only commits to that branch when releasing, and otherwise it will never get new commits (so it is a static versioning branch, and the tag itself wasn't used for inexplicable reasons which justify themselves because "because"). I couldn't be bothered to read the PKGBUILD *and* check the upstream sources, just to make random comments about style. :p (If so, why does the pkgver function specifically use `git describe --long` when `git describe` would by default exclude "r0.guselesshashpointingtoatag"` ???) But either way, you said "you won't even notice when upstream changes or adds commits to such" and the *current* pkgver function guarantees he *will* notice. -- Eli Schwartz
On Mon, Nov 28, 2016 at 5:26 PM Levente Polyak
In fact we already had several discussions in the IRC about this topic and what I mentioned above was always sufficient to justify getting rid of it. The only reason we don't yet have a TODO list to switch away from #tag= is simply lack of time (but its still on my todo list besides getting a TODO list for git:// sources).
If a remember correctly either heftig or JGC has created a convenience script to update a PKGBUILDs values, maybe they share it with us :)
I did, and it's tracked here now: https://git.archlinux.org/infrastructure.git/tree/roles/archbuild/files/gitp... Made from cardboard and duct tape. Use with care. May eat your babies for breakfast.
Hi, On Mon, Nov 28, 2016 at 12:20:40PM +0100, Levente Polyak wrote:
Don't hesitate if you have any questions, or comments on my AUR packages!
Sure, I always take a look at all packages of an applicant and suggest changes before I decide how to vote... so here we go :P
Yes, I was expecting this :)
pjproject - if you must use -j1 for every make call, you can simply add !makeflags to the options instead.
Good catch, this was actually copied unchanged from the pjproject package https://aur.archlinux.org/packages/pjproject. I just tested building in parallel on a 16-core machine, and it works fine, so I removed the -j1. The original issue must have been fixed upstream.
linux-mptcp - #tag= should never be used for git packages, instead store the commit hash for the tag and always use the #tag= prefix. A named tag does not mean much and you won't even notice when upstream changes such. This is especially bad when using plain git:// :-)
Interesting, I had never thought about this issue. I think I will switch to a tarball as suggested by Eli, I didn't know that github provides tarballs for each commit. The downside is that $pkgver will no longer be computed automatically, I will have to update it manually.
- You should add an initramfs post transaction hook like in the regular kernel [0] to avoid problems like described in #51818.
Thanks for the hint, will do.
ring-daemon: - just a feeling but a description with 202 chars feels quite long :P
Is there a hard limit somewhere, maybe in the AUR? Anyway, upstream has changed its description to a shorter one, so I used that instead. It's now "only" 130 chars.
- you should use git+https:// instead of plain git:// even through the CA world is a bit wonky it still authenticates the server and at the very bare minimum adds confidentiality.
I don't like the "everything-over-HTTP(S)" approach in general, especially when there is a dedicated protocol that works (yes, I know, this is basic ranting). Assuming the git revision is identified by a commit hash, I see no value in using HTTPS for authentication or verification. I agree it is useful however when building from a tag or a branch, as you correctly pointed out for another package. On the other hand, if one day the TLS certificate becomes invalid (expired certificate, untrusted CA, etc), the package would fail to build. I see this as a significant drawback of using git+https://.
pius - documentation, or hint to documentations inside .install files always feels like the wrong place. If there is documentation in /usr/share/doc/pius then people will find it.
I generally agree with this. In this case, however, the suggested configuration option is really needed on Arch when using the new Gnupg key format, and this is not explicitely documented upstream. I think I will send a patch upstream to fix the issue (auto-detect the keyring format) and remove the .install file altogether with the next release.
ring-gnome-git - a VCS package should always provide its non-VCS package variant like 'ring-gnome'
Actually, the missing "provides" is intended. The Ring components are interdependent and get updated quite frequently, so at any given time `ring-foo` and `ring-foo-git` are likely offer a different API/ABI. More practically, when the "provides" was here, I had issues with AUR users mixing -git and non-git ring packages and complaining of building errors.
libringclient-git - a VCS package should always provide its non-VCS package variant like 'libringclient' - If there is no strong reason to depend on a git variant, always depend on the non VCS, in this case ring-daemon instead of ring-daemon-git
See the above comment on gnome-ring-git.
- the pkgver() function doesn't sound specific enough, it just returns a simple date without anything else (f.e. 20161110) which means building on the same date can result in the same package version while being built from quite different source states.
Good point, I can switch to the `git describe` method used by most of my other git packages.
udrawgraph - just a bit of style, but we have arch specific depends like depends_x86_64 which looks better :P
Fixed. This package long predates arch-specific depends.
tsocks-ipv6 - this looks like it should also provide tsocks as it just adds additional v6 support
Indeed, fixed.
coq-doc - the sources must be prefixed with the version as otherwise older tarballs will "conflict". on top of that "stdlib.tar.gz" sounds a bit too generic and may overlap with another package, conisder also including the package name into the prefix to avoid such situation.
Fixed.
- sources that are not unique (like "/v$pkgver.tar.gz" from github) should be prefixed with the package name (+ of cause pkgver) to be unique. This is important if you configures shared SRCDEST to avoid conflicts.
Fixed.
net-tools-mptcp - #branch= should never be used for non VCS git packages, instead store the commit hash for the tag and always use the #tag= prefix. A named branch does not mean much and you won't even notice when upstream changes or adds commits to such.
Fixed, I switched to a tarball.
- every reference to $pkgdir should be put inside double-quotes in case it contains spaces.
Fixed in all packages (hopefully). Thanks, Baptiste
On 11/29/2016 12:29 AM, Baptiste Jonglez wrote:
- you should use git+https:// instead of plain git:// even through the CA world is a bit wonky it still authenticates the server and at the very bare minimum adds confidentiality.
I don't like the "everything-over-HTTP(S)" approach in general, especially when there is a dedicated protocol that works (yes, I know, this is basic ranting).
Assuming the git revision is identified by a commit hash, I see no value in using HTTPS for authentication or verification. I agree it is useful however when building from a tag or a branch, as you correctly pointed out for another package.
On the other hand, if one day the TLS certificate becomes invalid (expired certificate, untrusted CA, etc), the package would fail to build. I see this as a significant drawback of using git+https://.
Well pulling over TLS was discussed over and over and over and over again and we ended up that we just do it for all of our packages if available... Thats why this came up in the first place: https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/ I quote dave: "Security is not a binary thing". It adds another layer of security, if you like it or not. It authenticates the server (yes there may be untrusted CA, so? *shrug*) and i repeat again: at the very bare minimum adds confidentiality. Feel free to re-read the arch-dev-public thread, the outcome was the mentioned todo list. I heard a lot of opinions and some of them are understandable... but saying that its a significant drawback as the certificate could possible be invalid/expired is certainly nothing i would _ever_ consider as such. I never get why people always make such a big fuzz in not pulling over TLS. The same argumentation could be used for the regular tarballs and I repeat, the outcome is simple: use https, easy as that.
ring-gnome-git - a VCS package should always provide its non-VCS package variant like 'ring-gnome'
Actually, the missing "provides" is intended. The Ring components are interdependent and get updated quite frequently, so at any given time `ring-foo` and `ring-foo-git` are likely offer a different API/ABI.
More practically, when the "provides" was here, I had issues with AUR users mixing -git and non-git ring packages and complaining of building errors.
This could be the case for literally _any_ library f.e. and still all of them have their corresponding provides. If there would be anything depending on ring-gnome you created an unresolvable hell be just conflicting it because it may have API changes.
libringclient-git - a VCS package should always provide its non-VCS package variant like 'libringclient' - If there is no strong reason to depend on a git variant, always depend on the non VCS, in this case ring-daemon instead of ring-daemon-git
See the above comment on gnome-ring-git.
And here is the -git hell I describes, either take all -git or none... that's not how it should be. Think how it would be if every library would be like that, that would mean you need to use -git for the whole system just because you switch a single package. Don't enforce it just because... if such happens people will figure. cheers, Levente
On Tue, Nov 29, 2016 at 01:04:47AM +0100, Levente Polyak wrote:
On 11/29/2016 12:29 AM, Baptiste Jonglez wrote:
- you should use git+https:// instead of plain git:// even through the CA world is a bit wonky it still authenticates the server and at the very bare minimum adds confidentiality.
I don't like the "everything-over-HTTP(S)" approach in general, especially when there is a dedicated protocol that works (yes, I know, this is basic ranting).
Assuming the git revision is identified by a commit hash, I see no value in using HTTPS for authentication or verification. I agree it is useful however when building from a tag or a branch, as you correctly pointed out for another package.
On the other hand, if one day the TLS certificate becomes invalid (expired certificate, untrusted CA, etc), the package would fail to build. I see this as a significant drawback of using git+https://.
Well pulling over TLS was discussed over and over and over and over again and we ended up that we just do it for all of our packages if available... Thats why this came up in the first place: https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/
Yes, I saw the discussion on arch-dev-public (but obviously could not participate).
I quote dave: "Security is not a binary thing". It adds another layer of security, if you like it or not. It authenticates the server (yes there may be untrusted CA, so? *shrug*) and i repeat again: at the very bare minimum adds confidentiality. Feel free to re-read the arch-dev-public thread, the outcome was the mentioned todo list.
I heard a lot of opinions and some of them are understandable... but saying that its a significant drawback as the certificate could possible be invalid/expired is certainly nothing i would _ever_ consider as such.
For a package in [community], an expired certificate for the upstream tarball is not a big deal, since it does not directly affect the Arch user installing the package. As a packager, you can just get the tarball by some other means, or wait a few days so that somebody renews the cert. But for the AUR, an expired certificate would be annoying, as any user trying to build the package (e.g. using an AUR helper) would encounter an error.
I never get why people always make such a big fuzz in not pulling over TLS. The same argumentation could be used for the regular tarballs and I repeat, the outcome is simple: use https, easy as that.
Well, I agree with the outcome of the discussion, which was basically "One way or the other does not change much security-wise, so let's switch to HTTPS if doing so does not require significant efforts".
ring-gnome-git - a VCS package should always provide its non-VCS package variant like 'ring-gnome'
Actually, the missing "provides" is intended. The Ring components are interdependent and get updated quite frequently, so at any given time `ring-foo` and `ring-foo-git` are likely offer a different API/ABI.
More practically, when the "provides" was here, I had issues with AUR users mixing -git and non-git ring packages and complaining of building errors.
This could be the case for literally _any_ library f.e. and still all of them have their corresponding provides. If there would be anything depending on ring-gnome you created an unresolvable hell be just conflicting it because it may have API changes.
libringclient-git - a VCS package should always provide its non-VCS package variant like 'libringclient' - If there is no strong reason to depend on a git variant, always depend on the non VCS, in this case ring-daemon instead of ring-daemon-git
See the above comment on gnome-ring-git.
And here is the -git hell I describes, either take all -git or none... that's not how it should be. Think how it would be if every library would be like that, that would mean you need to use -git for the whole system just because you switch a single package. Don't enforce it just because... if such happens people will figure.
Again, the constraints are a bit different on the AUR and on a binary repository. What I try to ensure is that somebody running e.g. "yaourt -S ring-gnome-git" will not have compilation issues. If ring-gnome-git depends on libringclient, then the former will not build if the API provided by libringclient has changed recently. But you're right, it's a mess. I updated the *ring*-git packages so that they only depend on non-git packages, and they now all provide their non-git version. Anyway, I was thinking of orphaning all those -git Ring packages, since I don't use them anymore and they take time to maintain. Baptiste
On 11/29/2016 11:33 AM, Baptiste Jonglez wrote:
For a package in [community], an expired certificate for the upstream tarball is not a big deal, since it does not directly affect the Arch user installing the package. As a packager, you can just get the tarball by some other means, or wait a few days so that somebody renews the cert.
But for the AUR, an expired certificate would be annoying, as any user trying to build the package (e.g. using an AUR helper) would encounter an error.
I call bullshit, especially as your cases are purely about github! Surly, as if they can't wait "a few days" in such an unlikely scenario. And what if upstream forgets to pay for their servers, it won't be available too. How often do you think that certificates stay in an expired state. Of cause there may be one or two cases that could be named, its still certainly nothing to build upon.
I never get why people always make such a big fuzz in not pulling over TLS. The same argumentation could be used for the regular tarballs and I repeat, the outcome is simple: use https, easy as that.
Well, I agree with the outcome of the discussion, which was basically "One way or the other does not change much security-wise, so let's switch to HTTPS if doing so does not require significant efforts".
Fine, if you were already aware of the outcome, why this useless waste of time to discuss it yet again. Especially a TU applicant should follow chosen best practices and decisions. The AUR should not be any different from how they should be in the binary repos, so I expect to see those changes in your packages as well.
libringclient-git - a VCS package should always provide its non-VCS package variant like 'libringclient' - If there is no strong reason to depend on a git variant, always depend on the non VCS, in this case ring-daemon instead of ring-daemon-git
See the above comment on gnome-ring-git.
And here is the -git hell I describes, either take all -git or none... that's not how it should be. Think how it would be if every library would be like that, that would mean you need to use -git for the whole system just because you switch a single package. Don't enforce it just because... if such happens people will figure.
Again, the constraints are a bit different on the AUR and on a binary repository. What I try to ensure is that somebody running e.g. "yaourt -S ring-gnome-git" will not have compilation issues. If ring-gnome-git depends on libringclient, then the former will not build if the API provided by libringclient has changed recently.
Again, even through there are quite obviously no -git packages in the binary repository, the PKGBUILDs in the AUR should not be created in a different way then you would write them in the binary repo. Also AUR packages are influenced by each other and just completely abandon all provides is clearly a very bad practice. As easy as that. https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html cheers, Levente
On November 29, 2016 12:08:39 PM GMT+01:00, Levente Polyak
Fine, if you were already aware of the outcome, why this useless waste of time to discuss it yet again.
Well, I actually withdraw this sentence, the discussion period is pretty much about discussing :P Cheers, Levente
Well, I actually withdraw this sentence, the discussion period is pretty much about discussing :P
technically the discussion period has not even begun, since there was no confirmation of sponsorship yet. g
On Tue, 29 Nov 2016 12:08:39 +0100
Levente Polyak
On 11/29/2016 11:33 AM, Baptiste Jonglez wrote:
For a package in [community], an expired certificate for the upstream tarball is not a big deal, since it does not directly affect the Arch user installing the package. As a packager, you can just get the tarball by some other means, or wait a few days so that somebody renews the cert.
But for the AUR, an expired certificate would be annoying, as any user trying to build the package (e.g. using an AUR helper) would encounter an error.
I call bullshit, especially as your cases are purely about github! Surly, as if they can't wait "a few days" in such an unlikely scenario. And what if upstream forgets to pay for their servers, it won't be available too. How often do you think that certificates stay in an expired state. Of cause there may be one or two cases that could be named, its still certainly nothing to build upon.
I never get why people always make such a big fuzz in not pulling over TLS. The same argumentation could be used for the regular tarballs and I repeat, the outcome is simple: use https, easy as that.
Well, I agree with the outcome of the discussion, which was basically "One way or the other does not change much security-wise, so let's switch to HTTPS if doing so does not require significant efforts".
Fine, if you were already aware of the outcome, why this useless waste of time to discuss it yet again. Especially a TU applicant should follow chosen best practices and decisions. The AUR should not be any different from how they should be in the binary repos, so I expect to see those changes in your packages as well.
Git packages were not discussed, and https wasn't really "chosen best practices", it was more "eh, why not". Getting all emotional because someone doesn't buy into your reteric 100% isn't helping anyone.
libringclient-git - a VCS package should always provide its non-VCS package variant like 'libringclient' - If there is no strong reason to depend on a git variant, always depend on the non VCS, in this case ring-daemon instead of ring-daemon-git
See the above comment on gnome-ring-git.
And here is the -git hell I describes, either take all -git or none... that's not how it should be. Think how it would be if every library would be like that, that would mean you need to use -git for the whole system just because you switch a single package. Don't enforce it just because... if such happens people will figure.
Again, the constraints are a bit different on the AUR and on a binary repository. What I try to ensure is that somebody running e.g. "yaourt -S ring-gnome-git" will not have compilation issues. If ring-gnome-git depends on libringclient, then the former will not build if the API provided by libringclient has changed recently.
Again, even through there are quite obviously no -git packages in the binary repository, the PKGBUILDs in the AUR should not be created in a different way then you would write them in the binary repo. Also AUR packages are influenced by each other and just completely abandon all provides is clearly a very bad practice. As easy as that.
https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html
Reality time: The AUR is different than the binary repos. Yes, ideally the PKGBUILD should be able to go directly to the binary repos, but reality needs to take precedence over blind ideology. AUR packages are managed differently than repo packages and in the vast majority of cases are built differently as well. I agree with you in this case, but please don't use this dubious argument. It does make sense to depend on the -git versions in cases like this as well. We're not talking everything, we're talking everything in a given stack provided by a single upstream. Applying this to another example, Qt5 packages from git should depend on other Qt5 packages from git, not on their stable versions. Doug
On 11/29/2016 12:08 PM, Levente Polyak wrote:
On 11/29/2016 11:33 AM, Baptiste Jonglez wrote:
For a package in [community], an expired certificate for the upstream tarball is not a big deal, since it does not directly affect the Arch user installing the package. As a packager, you can just get the tarball by some other means, or wait a few days so that somebody renews the cert.
But for the AUR, an expired certificate would be annoying, as any user trying to build the package (e.g. using an AUR helper) would encounter an error.
I call bullshit, especially as your cases are purely about github! Surly, as if they can't wait "a few days" in such an unlikely scenario. And what if upstream forgets to pay for their servers, it won't be available too. How often do you think that certificates stay in an expired state. Of cause there may be one or two cases that could be named, its still certainly nothing to build upon.
About all this https discussion: I think we should all confirm with the gpg and https standards we made recently (and the string hashes that i suggested) and we should also try to increase the quality of AUR in general and especially as TU to advise other people to do so too. Packaging a secure chat program and being so lazy about https makes me wonder. Also you do not need to move the packages as fast as possible into community. I became TU month ago and arduino is still not in community because some issues needed to be solved first. So quality and security is more important here. I think it'd be good for you to rethink the https (and gpg, hash) topic, because (especially) as secure chat messenger packager it'd be extremely important to me that you try to achieve the best security as possible. ~Nico
Hi Nicohood, On Thu, Dec 01, 2016 at 04:23:27PM +0100, NicoHood wrote:
you do not need to move the packages as fast as possible into community. I became TU month ago and arduino is still not in community because some issues needed to be solved first. So quality and security is more important here.
Agreed.
About all this https discussion: I think we should all confirm with the gpg and https standards we made recently (and the string hashes that i suggested) and we should also try to increase the quality of AUR in general and especially as TU to advise other people to do so too. Packaging a secure chat program and being so lazy about https makes me wonder.
I think it'd be good for you to rethink the https (and gpg, hash) topic, because (especially) as secure chat messenger packager it'd be extremely important to me that you try to achieve the best security as possible.
You almost sound like I'm opposing all forms of "security" (whatever you mean by that). Of course we should promote the use of TLS and HTTPS on the Internet, even though the trust model is flawed and implementations are bloated/bugged. My point is that in the context of packaging, we have different requirements than for web browsing. HTTPS does not provide authenticity and integrity of the sources themselves, which is what we are interested in. PGP (preferably) and strong hash algorithms (as a substitute) should be used for that. To avoid repeating the same arguments, I agree with what seblu said on arch-dev-public: On Tue, Nov 01, 2016 at 04:03:04PM +0100, Sébastien Luttringer wrote:
TLS is about security of the transportation of sources, not the security of sources themselves, that's why I asked, to know what you had in mind.
My definition of securing the sources, is a way to trust the sources at the build time, no matter the way they were fetched. I want to be sure that my sources are "correct" even if I get them by usb key, ftp, rsync or even if they were not corrupted locally by a btrfs bug. And when possible, I want to be sure that the server (mirror or not) was not compromised (even at the first fetch).
Keeping that in mind, enforcing tls, doesn't improve much the source security. In fact, it improves only security during the transportation of the sources at the cost of the caching.
Besides this issue, I already mentioned another drawback of using HTTPS: untrusted certificates (either expired, self-signed, or just signed by an untrusted CA) will cause build failure. This was a real issue for OpenWRT, so they switched to using --no-check-certificate in 2010 [1] to avoid build failures. Sources are already validated with a checksum. Anyway, some of my packages do not use HTTPS, and this is indeed mostly because of laziness. I consider this is a low priority task. It does not mean that I am fundamentally opposed to the use of HTTPS, especially for "big" providers like github which are not very likely to have expired certs. I had a look at the sources for my AUR packages, and here is the result: - 5 fetched over HTTPS - 7 fetched over git+https:// - 5 fetched over HTTP, with no HTTPS available - 1 fetched over FTP, with no HTTPS available - 5 fetched over HTTP while HTTPS is available (including 1 with a PGP signature) - 6 fetched over git:// while git+https:// is available So, less than half of them needed to be "fixed". I just switched to HTTPS for 10 out of the 11 fixable packages. The only remaining one is linux-mptcp, because I plan to move it away from git soon anyway. Baptiste [1] https://git.lede-project.org/?p=openwrt/source.git;a=blobdiff;f=scripts/down...
Em dezembro 1, 2016 20:37 Baptiste Jonglez escreveu:
You almost sound like I'm opposing all forms of "security" (whatever you mean by that). Of course we should promote the use of TLS and HTTPS on the Internet, even though the trust model is flawed and implementations are bloated/bugged.
I don't think Nico is saying that you oppose security. And I agree that the CA model is practically broken. But we have alternatives to improving the trustworthiness of that model. The recent HPKP RFC is one of those. There are also preload lists, even though most of the software used to get the sources do not use them.
My point is that in the context of packaging, we have different requirements than for web browsing. HTTPS does not provide authenticity and integrity of the sources themselves, which is what we are interested in. PGP (preferably) and strong hash algorithms (as a substitute) should be used for that.
Yes, preferably upstream must provide PGP signed sources. HTTPS only prevent tampering in transit, which is nice, but it doesn't guarantee you didn't got tampered software from upstream.
Besides this issue, I already mentioned another drawback of using HTTPS: untrusted certificates (either expired, self-signed, or just signed by an untrusted CA) will cause build failure. This was a real issue for OpenWRT, so they switched to using --no-check-certificate in 2010 [1] to avoid build failures. Sources are already validated with a checksum.
Well, relying only on checksums is not good enough in my opinion. We know for a fact that hashing algorithms are built on top of *reasonable* chance that collisions won't happen. Sure, the space of a SHA256 hash is huge, but we must not just shrug over it. Because if we, as maintainers do, upstream will think they don't need to provide signed sources, because hashes are probably "good enough".
Anyway, some of my packages do not use HTTPS, and this is indeed mostly because of laziness. I consider this is a low priority task. It does not mean that I am fundamentally opposed to the use of HTTPS, especially for "big" providers like github which are not very likely to have expired certs.
I had a look at the sources for my AUR packages, and here is the result:
- 5 fetched over HTTPS - 7 fetched over git+https://
- 5 fetched over HTTP, with no HTTPS available - 1 fetched over FTP, with no HTTPS available
- 5 fetched over HTTP while HTTPS is available (including 1 with a PGP signature) - 6 fetched over git:// while git+https:// is available
So, less than half of them needed to be "fixed". I just switched to HTTPS for 10 out of the 11 fixable packages. The only remaining one is linux-mptcp, because I plan to move it away from git soon anyway.
The one thing I can take away from all this HTTPS or not discussion is that we as maintainers are specially vulnerable. If we don't use whatever tools at our disposal to be completely sure we didn't got the right source, who knows how long those changes will go undetected? Heck, it's hard enough finding bugs on *open source* software. Finding "intentional" ones on binaries is harder. Cheers, Giancarlo Razzolini
Besides this issue, I already mentioned another drawback of using HTTPS: untrusted certificates (either expired, self-signed, or just signed by an untrusted CA) will cause build failure. This was a real issue for OpenWRT, so they switched to using --no-check-certificate in 2010 [1] to avoid build failures. Sources are already validated with a checksum.
Well, relying only on checksums is not good enough in my opinion. We know for a fact that hashing algorithms are built on top of *reasonable* chance that collisions won't happen. Sure, the space of a SHA256 hash is huge, but we must not just shrug over it. Because if we, as maintainers do, upstream will think they don't need to provide signed sources, because hashes are probably "good enough".
The signature itself is only a signed hash (sha256). So we do rely on the collision resistance of sha256[1] (or whatever the GPG itself uses). You are right, that hashes themselves are not enough to verify that the original author provided this source. But it gives you the guarantee that you downloaded the same source, as the maintainer(PKGBUILD writer) did. That is what integrity is all about, that is not only a checksum! The weakest spot though is the initial fetching of the source on which the maintainer relies on. However with strong hashes you can at least ensure that you (for a rebuild) download the exact same sources, as the maintainer did. You just cannot prove who published that source itself. Saying sha256 is not secure enough for that purpose would also say GPG is not safe. Correct me if I am wrong though. I'd be also nice to discuss this in the email I recently opened and not in the TU Application. I think this is a highly important topic, especially for those packages where we do not have gpg and https available and you can only rely on the hash that the maintainer gave out (AUR). [1]https://www.bestvpn.com/wp-content/uploads/2015/03/Digital_Signature_diagram... Cheers Nico
Em dezembro 2, 2016 11:18 NicoHood escreveu:
The signature itself is only a signed hash (sha256). So we do rely on the collision resistance of sha256[1] (or whatever the GPG itself uses). You are right, that hashes themselves are not enough to verify that the original author provided this source. But it gives you the guarantee that you downloaded the same source, as the maintainer(PKGBUILD writer) did.
GPG uses DSA[0]. And the signatures done using GPG are done in a way that requires a key pair on the part of the person doing the signature. The link you sent demonstrate precisely that. They are much more than simple hashes.
That is what integrity is all about, that is not only a checksum! The weakest spot though is the initial fetching of the source on which the maintainer relies on. However with strong hashes you can at least ensure that you (for a rebuild) download the exact same sources, as the maintainer did. You just cannot prove who published that source itself. Saying sha256 is not secure enough for that purpose would also say GPG is not safe.
I'm not saying that sha256 is not secure enough for that purpose. I'm saying that for *maintainers* it is not enough. There's a difference, it's subtle, but it is there nevertheless. We replace upstream trust with our own. So we must be sure that we're packaging from the right upstream source, even if said source can't be obtained securely, nor does it has proper hashes or not even TLS.
Correct me if I am wrong though. I'd be also nice to discuss this in the email I recently opened and not in the TU Application. I think this is a highly important topic, especially for those packages where we do not have gpg and https available and you can only rely on the hash that the maintainer gave out (AUR).
Sure, lets discuss that. But I think we already, even if informally, agreed that using TLS were available is better than not. I'll stop deviating from the purpose of the TU application discussion. Baptiste, you fixed what we suggested, and that's ok by me. Cheers, Giancarlo Razzolini [0] https://www.gnupg.org/gph/en/manual.html#AEN216
On 02/12, Giancarlo Razzolini wrote:
Em dezembro 2, 2016 11:18 NicoHood escreveu:
The signature itself is only a signed hash (sha256). So we do rely on the collision resistance of sha256[1] (or whatever the GPG itself uses). You are right, that hashes themselves are not enough to verify that the original author provided this source. But it gives you the guarantee that you downloaded the same source, as the maintainer(PKGBUILD writer) did.
GPG uses DSA[0]. And the signatures done using GPG are done in a way that requires a key pair on the part of the person doing the signature. The link you sent demonstrate precisely that. They are much more than simple hashes.
That's quite outdated, and RSA has been the default for quite a long time. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
On 11/28/2016 06:29 PM, Baptiste Jonglez wrote:
On the other hand, if one day the TLS certificate becomes invalid (expired certificate, untrusted CA, etc), the package would fail to build. I see this as a significant drawback of using git+https://.
When you say drawback, are you referring to TLS performing its intended role? I am really confused as to what you are trying to accomplish here. I thought the whole point of switching to git+https:// is in order that builds should fail when suspicious things happen to the source code, like getting served from a domain with a very suspiciously broken certificate. The CACERT model assumes website owners are still alive and capable of renewing their certificate before people call their customer service (if applicable) number to complain that they can't access the website. On the whole, it tends to be pretty successful. (Leaving aside peoples' questions on the premise of the model, at least when we use it we use it according to spec.) An untrusted CA is, well, untrusted. Why would I want to build a package authenticated by them, if I don't trust them? Seriously, your argument is an argument against using TLS on the World Wide Web. "I don't wanna use TLS, because now I cannot access all these broken websites anymore!" -- Eli Schwartz
I am currently updating the xfce4-pulseaudio-plugin and have a few namcap warnings to resolve. Mainly I am focusing this kind of warnings: xfce4-pulseaudio-plugin W: Unused shared library '/usr/lib/libdbus-glib-1.so.2' by file ('usr/lib/xfce4/panel/plugins/libpulseaudio-plugin.so') https://aur.archlinux.org/packages/xfce4-pulseaudio-plugin/ However configure does use shared libraries as you can see from the log: checking whether to build shared libraries... yes checking whether to build static libraries... no Does this require upstream fixes? And if so, what should be changed? I want to move the package to [community] once gpg signatures and https are provided, but that also should get fixed first. Cheers, Nico
Den 04-12-2016 kl. 14:03 skrev NicoHood:
I am currently updating the xfce4-pulseaudio-plugin […]
(Please don't create new mails as replies to existing ones. Sane mail clients will thread your mail in the existing thread and will make both harder to follow.) -- Namasté, Frederik “Freso” S. Olesen https://freso.dk/ AUR: https://aur.archlinux.org/account/Freso Wiki: https://wiki.archlinux.org/index.php/User:Freso
On 04/12/16 08:03 AM, NicoHood wrote:
I am currently updating the xfce4-pulseaudio-plugin and have a few namcap warnings to resolve. Mainly I am focusing this kind of warnings:
xfce4-pulseaudio-plugin W: Unused shared library '/usr/lib/libdbus-glib-1.so.2' by file ('usr/lib/xfce4/panel/plugins/libpulseaudio-plugin.so')
https://aur.archlinux.org/packages/xfce4-pulseaudio-plugin/
However configure does use shared libraries as you can see from the log: checking whether to build shared libraries... yes checking whether to build static libraries... no
Does this require upstream fixes? And if so, what should be changed? I want to move the package to [community] once gpg signatures and https are provided, but that also should get fixed first.
Cheers, Nico
It might be possible to get rid of this output by putting the "-Wl,--as-needed" compiler flag in the upstream configure script. But honestly this happens with most GTK programs. The libgtk-x11-2.0.so library is setup to bring in most of its own dependencies every time a program uses it. Even when that program doesn't need to call pango, cairo or any of that. I would just ignore it.
On 12/04/2016 08:50 PM, Connor Behan via aur-general wrote:
On 04/12/16 08:03 AM, NicoHood wrote:
I am currently updating the xfce4-pulseaudio-plugin and have a few namcap warnings to resolve. Mainly I am focusing this kind of warnings:
xfce4-pulseaudio-plugin W: Unused shared library '/usr/lib/libdbus-glib-1.so.2' by file ('usr/lib/xfce4/panel/plugins/libpulseaudio-plugin.so')
https://aur.archlinux.org/packages/xfce4-pulseaudio-plugin/
However configure does use shared libraries as you can see from the log: checking whether to build shared libraries... yes checking whether to build static libraries... no
Does this require upstream fixes? And if so, what should be changed? I want to move the package to [community] once gpg signatures and https are provided, but that also should get fixed first.
Cheers, Nico
It might be possible to get rid of this output by putting the "-Wl,--as-needed" compiler flag in the upstream configure script. But honestly this happens with most GTK programs. The libgtk-x11-2.0.so library is setup to bring in most of its own dependencies every time a program uses it. Even when that program doesn't need to call pango, cairo or any of that. I would just ignore it.
I also got this suggestion on IRC. I added the LD_FLAGS=-Wl,--as-needed to the configure command, but that did not help at all. Maybe I did it wrong? The fact that more programs have this problem does not mean we should ignore it. Also because of possible outdated software and security reasons. ~Nico
On 12/04/2016 04:47 PM, NicoHood wrote:
I also got this suggestion on IRC. I added the LD_FLAGS=-Wl,--as-needed to the configure command, but that did not help at all. Maybe I did it wrong?
The fact that more programs have this problem does not mean we should ignore it. Also because of possible outdated software and security reasons.
Please get your own thread, aur-general is currently having a buy-one-get-one-free special on ML threads. Your current subthread is annoyingly bumping the "TU Application: Baptiste Jonglez" thread with $offtopic -- Eli Schwartz
--> I hope this is in a new post now. Sorry Eli Schwartz, I did not know that the ML gets messed up like this. On 12/04/2016 08:50 PM, Connor Behan via aur-general wrote:
On 04/12/16 08:03 AM, NicoHood wrote:
I am currently updating the xfce4-pulseaudio-plugin and have a few namcap warnings to resolve. Mainly I am focusing this kind of warnings:
xfce4-pulseaudio-plugin W: Unused shared library '/usr/lib/libdbus-glib-1.so.2' by file ('usr/lib/xfce4/panel/plugins/libpulseaudio-plugin.so')
https://aur.archlinux.org/packages/xfce4-pulseaudio-plugin/
However configure does use shared libraries as you can see from the log: checking whether to build shared libraries... yes checking whether to build static libraries... no
Does this require upstream fixes? And if so, what should be changed? I want to move the package to [community] once gpg signatures and https are provided, but that also should get fixed first.
Cheers, Nico
It might be possible to get rid of this output by putting the "-Wl,--as-needed" compiler flag in the upstream configure script. But honestly this happens with most GTK programs. The libgtk-x11-2.0.so library is setup to bring in most of its own dependencies every time a program uses it. Even when that program doesn't need to call pango, cairo or any of that. I would just ignore it.
I also got this suggestion on IRC. I added the LD_FLAGS=-Wl,--as-needed to the configure command, but that did not help at all. Maybe I did it wrong? The fact that more programs have this problem does not mean we should ignore it. Also because of possible outdated software and security reasons. ~Nico
On Mon, 28 Nov 2016 at 07:33:16, Baptiste Jonglez wrote:
I would like to apply to become a TU. Lukas Fleischer has kindly accepted to sponsor my application.
I confirm that I sponsor Baptiste. I have worked with him several times in the past; among other things he contributed several patches to calcurse back in 2012 [1]. He is knowledgable and I think he will be a great addition to the team! Let the discussion period begin! [1] http://git.calcurse.org/calcurse.git/log/?qt=author&q=Baptiste+Jonglez
On Tue, Nov 29, 2016 at 08:11:39PM +0100, Lukas Fleischer wrote:
I confirm that I sponsor Baptiste.
I have worked with him several times in the past; among other things he contributed several patches to calcurse back in 2012 [1]. He is knowledgable and I think he will be a great addition to the team!
Let the discussion period begin!
Thanks Lukas! There are some points that I feel could be worth discussing (besides TLS…): 1) Would linux-mptcp [1] have its place in [community]? From what I read about linux-zen and linux-grsec [2], there does not seem to be strong objections, especially since most (or even all?) third-party kernel modules now use DKMS. 2) Some dependencies of my packages are orphaned in [community], such as msgpack-c [3]. As a TU, I guess it would make sense to adopt them. 3) ring-daemon requires non-released versions of restbed [4] and asio [5]. Is it better to wait for upstream to release a version of these libs, or is it acceptable to package a snapshot in [community]? Baptiste [1] https://aur.archlinux.org/packages/linux-mptcp/ [2] https://lists.archlinux.org/pipermail/arch-dev-public/2015-July/027311.html [3] https://www.archlinux.org/packages/community/x86_64/msgpack-c/ [4] https://aur.archlinux.org/packages/restbed-latest/ [5] https://aur.archlinux.org/packages/asio-latest/
On Wed, Nov 30, 2016 at 11:38:56PM +0100, Baptiste Jonglez wrote:
1) Would linux-mptcp [1] have its place in [community]? From what I read about linux-zen and linux-grsec [2], there does not seem to be strong objections, especially since most (or even all?) third-party kernel modules now use DKMS.
Hello Baptiste, depends on the votes. As far i can see the package has 9 votes. It's not that much. I would wait for more votes or discuss this with the community if another version of the linux kernel in the official repositories is asked for.
2) Some dependencies of my packages are orphaned in [community], such as msgpack-c [3]. As a TU, I guess it would make sense to adopt them.
Yep, this would make sense.
3) ring-daemon requires non-released versions of restbed [4] and asio [5]. Is it better to wait for upstream to release a version of these libs, or is it acceptable to package a snapshot in [community]?
Baptiste
[1] https://aur.archlinux.org/packages/linux-mptcp/ [2] https://lists.archlinux.org/pipermail/arch-dev-public/2015-July/027311.html [3] https://www.archlinux.org/packages/community/x86_64/msgpack-c/ [4] https://aur.archlinux.org/packages/restbed-latest/ [5] https://aur.archlinux.org/packages/asio-latest/
It is definitly better to wait for a stable upstream release. Please do not push snapshots of git branches in community when you can avoid that. Best regards chris
On Mon, 28 Nov 2016 at 07:33:16, Baptiste Jonglez wrote:
I would like to apply to become a TU. Lukas Fleischer has kindly accepted to sponsor my application. [...] Don't hesitate if you have any questions, or comments on my AUR packages!
The discussion period is over. Please cast your votes at [1]. [1] https://aur.archlinux.org/tu/?id=89
On Wed, 07 Dec 2016 at 08:05:59, Lukas Fleischer wrote:
[...] The discussion period is over. Please cast your votes at [1]. [...]
The voting period has ended. The results are: * Yes: 24 * No: 4 * Abstain: 11 This means that the proposal has been accepted. Congratulations, Baptiste, and welcome aboard! I already upgraded your AUR account. Please go through the TODO list for new Trusted Users [1] to learn about the next steps. Regards, Lukas [1] https://wiki.archlinux.org/index.php?title=AUR_Trusted_User_Guidelines#TODO_...
On Wed, Dec 14, 2016 at 08:16:39AM +0100, Lukas Fleischer wrote:
The voting period has ended. The results are:
* Yes: 24 * No: 4 * Abstain: 11
This means that the proposal has been accepted.
Congratulations, Baptiste, and welcome aboard!
Great news, thanks everyone!
I already upgraded your AUR account. Please go through the TODO list for new Trusted Users [1] to learn about the next steps.
Ok, I will do that as soon as possible. Baptiste
participants (13)
-
Baptiste Jonglez
-
Christian Rebischke
-
Connor Behan
-
Doug Newgard
-
Eli Schwartz
-
Frederik “Freso” S. Olesen
-
georg
-
Giancarlo Razzolini
-
Jan Alexander Steffens
-
Johannes Löthberg
-
Levente Polyak
-
Lukas Fleischer
-
NicoHood