Discussion:
TU Application: Baptiste Jonglez
(too old to reply)
Baptiste Jonglez
2016-11-28 06:33:16 UTC
Permalink
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
Levente Polyak
2016-11-28 11:20:40 UTC
Permalink
Hi Bapiste,
Post by Baptiste Jonglez
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/
Eli Schwartz via aur-general
2016-11-28 16:05:06 UTC
Permalink
Post by Baptiste Jonglez
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!
Post by Baptiste Jonglez
- #tag= should never be used for git packages, instead store the commit
hash for the tag and always use the #tag= prefix.
Typo?
Post by Baptiste Jonglez
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".
Post by Baptiste Jonglez
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.
Post by Baptiste Jonglez
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
Levente Polyak
2016-11-28 16:26:25 UTC
Permalink
Post by Eli Schwartz via aur-general
Post by Levente Polyak
- #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!
Post by Eli Schwartz via aur-general
Post by Levente Polyak
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)
Post by Eli Schwartz via aur-general
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 :)
Post by Eli Schwartz via aur-general
Post by Levente Polyak
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.
Post by Eli Schwartz via aur-general
Post by Levente Polyak
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
Eli Schwartz via aur-general
2016-11-28 18:05:51 UTC
Permalink
Post by Levente Polyak
- 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.
Post by 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 :)
That is very interesting information, thanks for mentioning it. My
curiosity is now sated. :)
Post by Levente Polyak
Post by Eli Schwartz via aur-general
Post by Levente Polyak
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
Jan Alexander Steffens via aur-general
2016-11-29 21:35:41 UTC
Permalink
Post by 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/gitpkg

Made from cardboard and duct tape. Use with care. May eat your babies for
breakfast.
Baptiste Jonglez
2016-11-28 23:29:44 UTC
Permalink
Hi,
Post by Levente Polyak
Post by Baptiste Jonglez
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 :)
Post by Levente Polyak
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.
Post by Levente Polyak
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.
Post by Levente Polyak
- 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.
Post by Levente Polyak
- 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.
Post by Levente Polyak
- 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://.
Post by Levente Polyak
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.
Post by Levente Polyak
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.
Post by Levente Polyak
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.
Post by Levente Polyak
- 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.
Post by Levente Polyak
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.
Post by Levente Polyak
tsocks-ipv6
- this looks like it should also provide tsocks as it just adds
additional v6 support
Indeed, fixed.
Post by Levente Polyak
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.
Post by Levente Polyak
- 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.
Post by Levente Polyak
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.
Post by Levente Polyak
- every reference to $pkgdir should be put inside double-quotes in case
it contains spaces.
Fixed in all packages (hopefully).

Thanks,
Baptiste
Levente Polyak
2016-11-29 00:04:47 UTC
Permalink
Post by Baptiste Jonglez
Post by Levente Polyak
- 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.
Post by Baptiste Jonglez
Post by Levente Polyak
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.
Post by Baptiste Jonglez
Post by Levente Polyak
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
Baptiste Jonglez
2016-11-29 10:33:32 UTC
Permalink
Post by Levente Polyak
Post by Baptiste Jonglez
Post by Levente Polyak
- 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...
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).
Post by Levente Polyak
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.
Post by Levente Polyak
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".
Post by Levente Polyak
Post by Baptiste Jonglez
Post by Levente Polyak
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.
Post by Baptiste Jonglez
Post by Levente Polyak
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
Levente Polyak
2016-11-29 11:08:39 UTC
Permalink
Post by Baptiste Jonglez
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.
Post by Baptiste Jonglez
Post by Levente Polyak
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.
Post by Baptiste Jonglez
Post by Levente Polyak
Post by Baptiste Jonglez
Post by Levente Polyak
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
Levente Polyak
2016-11-29 11:55:46 UTC
Permalink
Post by 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
georg
2016-11-29 11:58:26 UTC
Permalink
Post by Levente Polyak
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
Doug Newgard
2016-11-29 14:08:14 UTC
Permalink
On Tue, 29 Nov 2016 12:08:39 +0100
Post by Levente Polyak
Post by Baptiste Jonglez
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.
Post by Baptiste Jonglez
Post by Levente Polyak
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.
Post by Levente Polyak
Post by Baptiste Jonglez
Post by Levente Polyak
Post by Baptiste Jonglez
Post by Levente Polyak
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
NicoHood
2016-12-01 15:23:27 UTC
Permalink
Post by Levente Polyak
Post by Baptiste Jonglez
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
Baptiste Jonglez
2016-12-01 22:37:25 UTC
Permalink
Hi Nicohood,
Post by NicoHood
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.
Post by NicoHood
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
Post by NicoHood
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/download.pl;h=633a4f6f7d;hp=fe27df5e8f;hb=65fad8645d;hpb=5884b43b51
Giancarlo Razzolini
2016-12-02 10:50:07 UTC
Permalink
Post by Baptiste Jonglez
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.
Post by Baptiste Jonglez
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.
Post by Baptiste Jonglez
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".
Post by Baptiste Jonglez
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.
- 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
NicoHood
2016-12-02 13:18:50 UTC
Permalink
Post by Giancarlo Razzolini
Post by Baptiste Jonglez
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]Loading Image...

Cheers
Nico
Giancarlo Razzolini
2016-12-02 14:16:39 UTC
Permalink
Post by NicoHood
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.
Post by NicoHood
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.
Post by NicoHood
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
Johannes Löthberg via aur-general
2016-12-03 00:34:21 UTC
Permalink
Post by Giancarlo Razzolini
Post by NicoHood
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.
[0] https://www.gnupg.org/gph/en/manual.html#AEN216
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/
Eli Schwartz via aur-general
2016-11-29 14:01:17 UTC
Permalink
Post by Baptiste Jonglez
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
NicoHood
2016-12-04 13:03:01 UTC
Permalink
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
Frederik “Freso” S. Olesen via aur-general
2016-12-04 14:02:28 UTC
Permalink
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
Connor Behan via aur-general
2016-12-04 19:50:45 UTC
Permalink
Post by NicoHood
I am currently updating the xfce4-pulseaudio-plugin and have a few
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/
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.
NicoHood
2016-12-04 21:47:43 UTC
Permalink
Post by Connor Behan via aur-general
Post by NicoHood
I am currently updating the xfce4-pulseaudio-plugin and have a few
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/
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
Eli Schwartz via aur-general
2016-12-05 00:20:21 UTC
Permalink
Post by NicoHood
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
NicoHood
2016-12-05 07:41:48 UTC
Permalink
--> I hope this is in a new post now. Sorry Eli Schwartz, I did not
know that the ML gets messed up like this.
Post by Connor Behan via aur-general
Post by NicoHood
I am currently updating the xfce4-pulseaudio-plugin and have a few
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/
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
Lukas Fleischer
2016-11-29 19:11:39 UTC
Permalink
Post by Baptiste Jonglez
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
Baptiste Jonglez
2016-11-30 22:38:56 UTC
Permalink
Post by Lukas Fleischer
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/
Christian Rebischke
2016-11-30 22:53:19 UTC
Permalink
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
Lukas Fleischer
2016-12-07 07:05:59 UTC
Permalink
Post by Baptiste Jonglez
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
Lukas Fleischer
2016-12-14 07:16:39 UTC
Permalink
Post by Lukas Fleischer
[...]
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_list_for_new_Trusted_Users
Baptiste Jonglez
2016-12-14 07:41:17 UTC
Permalink
Post by Lukas Fleischer
* Yes: 24
* No: 4
* Abstain: 11
This means that the proposal has been accepted.
Congratulations, Baptiste, and welcome aboard!
Great news, thanks everyone!
Post by Lukas Fleischer
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

Continue reading on narkive:
Loading...