[gentoo-dev] [warning] the bug queue has 108 bugs
Our bug queue has 108 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
Re: [gentoo-dev] libressl status
On 6 April 2015 at 23:06, Paul B. Henson hen...@acm.org wrote: What are the downsides of the approach pkgsrc is tentatively taking, where there are no modifications to libressl but the libraries are installed in an alternative location? Packages that require libressl can just use the appropriate linker options to find those libraries rather than the openssl ones? https://blog.flameeyes.eu/2014/07/libressl-drop-in-and-abi-leakage Let's say you have program foo that uses libtls and libssl functions *and* CURL. Now you built CURL against openssl, but foo requires libtls, so you link it against libressl. What happens when you run foo? Symbols from openssl's libssl and libressl's libssl have the same name for API compatibility, right? So whichever of the two is loaded first (I *think* that's libressl but it is of course loader-dependent and in the case of glibc it depends on the environment variables too) will provide the symbols. But their ABIs are different so the calls coming from CURL (built against OpenSSL) will provide different data structures and parameter size than expected by libressl, or vice-versa. Given these are security functions, the collisions are even riskier than just crashing, especially as *most* of the functions will likely work either way, as long as the same set of allocators/users/deallocators are used… Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/
RE: [gentoo-dev] libressl status
From: hasufell Sent: Sunday, April 05, 2015 4:34 AM However, openntpd still compiles with openssl. Well, the current stable openntpd in portage compiles with openssl but that's not surprising as it is ancient and predates libressl :). The current unstable openntpd actually has no ssl dependencies and needs neither openssl nor libressl to compile and function. It is the most recent upstream portable release that added an optional dependency on libressl for tls constraint functionality, that version is not yet in portage. It will work without libressl just as well as the current unstable openntpd does, you just won't have access to the new feature. So it's not really critical, but at some point it would be nice to get it working one way or the other. By that you are effectively forking libressl and causing a huge mess downstream for both developers and users. What are the downsides of the approach pkgsrc is tentatively taking, where there are no modifications to libressl but the libraries are installed in an alternative location? Packages that require libressl can just use the appropriate linker options to find those libraries rather than the openssl ones? worse. This is something that has to be resolved upstream. If they don't cooperate long-term, then their fork will just die out for sure (and for good). However, I currently don't see strong signs for that. I don't think their fork will ever die; even if no one outside of openbsd uses the portable version, it is now the official ssl provider for openbsd and I am sure will continue to be used by them as well as the portable versions of any of their other applications such as openntpd...
Re: [gentoo-dev] libressl status
Solution: Packages that will compile against either one get || (openssl libressl). Packages that require a specific one will just have that one listed. Openssl will block Libressl and vice versa. The result of this arrangement is that systems that require few packages will probably be able to have libressl installed, so long as all their ssl-using apps are okay with libressl. Systems that require openssl-only packages won't get libressl. Then, overtime, upstreams and patch writers will gradually fill in the gaps, and eventually most packages will support both. This is the reasonable evolutionary approach. And it'll provide a good ground for gradually rolling out libressl support. On Apr 5, 2015 10:35 PM, hasufell hasuf...@gentoo.org wrote: On 04/05/2015 08:59 PM, Rich Freeman wrote: On Sun, Apr 5, 2015 at 2:35 PM, hasufell hasuf...@gentoo.org wrote: You are ranting at the wrong place. If you want to make a difference, take this to the openbsd mailing lists. It seems unlikely that this would make much of a difference. It doesn't make one here. I think that allowing this package to create another ffmpeg vs libav mess is a mistake. If you want to do some crazy downstream hackery, you'll have to do that yourself and count me out. It's not even clear what you want to fix. It was known from the start that we do not have ABI-compatibility. The only problem right now are libressl-exclusive features. These are currently optional codepaths afais, so packages still compile with openssl. Everything else is future prediction. That's why libressl is still in an overlay.
Re: [gentoo-dev] libressl status
On 7 April 2015 at 06:07, Jason A. Donenfeld zx...@gentoo.org wrote: Solution: Packages that will compile against either one get || (openssl libressl). Packages that require a specific one will just have that one listed. Openssl will block Libressl and vice versa. This would result in a similar mess as we have been dealing with in the ffmpeg / libav situation. Please don't do that. Make the choice explicit, and don't rely on semi-automagic dependency resolution. Also, explain clearly to users what the default implementation is and why. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] RFC News item: FFmpeg default
On 6 April 2015 at 17:35, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-04-06, o godz. 14:10:12 Ben de Groot yng...@gentoo.org napisał(a): On 30 March 2015 at 00:23, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-03-30, o godz. 00:07:16 Include example code. Updated version: Title: FFmpeg default Author: Ben de Groot yng...@gentoo.org Content-Type: text/plain Posted: 2015-04-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav Since the choice between ffmpeg and libav has been made more explicit, there has been a lot of discussion about what the default implementation should be. It can be concluded that media-video/ffmpeg has wider support, and would be somewhat more convenient for most end-users. For this reason the default implementation has been switched back from media-video/libav to media-video/ffmpeg by removing the libav useflag from the base profile. 'Switched back' is suggesting there was some 'unintentional' switch from ffmpeg to libav. Keep this free of politics, and just 'switched'. No, it does not suggest that. It simply reflects the history of the issue: once upon a time we had ffmpeg. Then libav was introduced and at some point made the default implementation. Now we are switching back to ffmpeg as default implementation. There is no politics in my statement. If the libav useflag is already globally enabled or disabled in /etc/portage/make.conf, then no further action is required. Users who implicitly relied on libav being enabled in their profile, and who wish to continue using libav, should enable USE=libav in their /etc/portage/make.conf file. Also please prepare an update to the USE=libav news item to state updated default. Diff: --- /var/portage/metadata/news/2015-02-01-use-libav/2015-02-01-use-libav.en.txt 2015-02-04 05:31:20.0 +0800 +++ /home/ben/tmp/2015-02-01-use-libav.en.txt 2015-04-06 14:05:56.982039939 +0800 @@ -2,7 +2,7 @@ Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-02-01 -Revision: 1 +Revision: 2 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav @@ -20,17 +20,17 @@ However, whenever appropriate additional USE=libav will be introduced to control the preference of one implementation over the other. -Users who currently use libav (the Gentoo default) do not have to -perform any action since USE=libav is enabled by default. It should be -noted that the users still need to enable USE=ffmpeg on packages with -optional libav support as well. Users who want to use ffmpeg instead -need to specify USE=-libav in make.conf explicitly. +Users who currently use libav need to enable USE=libav in +/etc/portage/make.conf. It should be noted that users still need to +enable USE=ffmpeg on packages with optional libav support as well. +Users who currently use ffmpeg need to take no action. Please also note that some packages support only one of the two implementations. An attempt to install one of those packages may result in blockers requiring the user changes the global USE=libav state. The most notable example of such package is media-video/mplayer. -media-video/mpv may be used as a replacement for users who prefer libav. +media-video/mpv may be used as a replacement for users who prefer libav, +even though upstream mpv developers recommend using ffmpeg. This is off-topic, and strongly biased. The original statement may give the impression that mpv is to libav what mplayer is to ffmpeg. Many users were surprised to find out that mpv upstream actually recommends ffmpeg, and that some of mpv's features do not work with libav. If we are going to specifically recommend mpv, then it is something users need to be aware of. We could change it to: media-video/mpv works with both ffmpeg and libav, though some of its features require ffmpeg. Or something along those lines. Please do not alter the state of 'libav' flag on a per-package basis (e.g. via package.use). The flag needs to be set globally to have FYI: since Council's meeting in one week, I have added this to the agenda. I'm really concerned about Gentoo's PR when users suffer due to developers ping-ponging implementations/defaults. It's not so much ping-ponging as stumbling upon what is the best solution for our users. Some years ago libav was made a soft default. And if I recall correctly, that was done with very little discussion. Recently this default was made harder by adding USE=libav to the base profile. This resulted in quite a backlash from users. Moreover, many upstreams of consuming packages actually prefer ffmpeg. Add to that the upstream ffmpeg policy of merging in changes from libav. All in all, from an end-user point of view it makes more sense to have ffmpeg as default. And when users were asked, they overwhelmingly expressed support for changing the
Re: [gentoo-dev] libressl status
On 6 April 2015 at 23:07, Jason A. Donenfeld zx...@gentoo.org wrote: Packages that will compile against either one get || (openssl libressl). Packages that require a specific one will just have that one listed. Openssl will block Libressl and vice versa. Doesn't work, you'd have to rebuild *all* the packages built with one or the other when switching, or (if the SONAME were the same) they would be built against a different ABI that they are built against, which can be possibly causing security issues as data structure size (and thus meaning of the content) changes. Diego Elio Pettenò — Flameeyes https://blog.flameeyes.eu/
Re: [gentoo-dev] RFC News item: FFmpeg default
On 30 March 2015 at 00:23, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-03-30, o godz. 00:07:16 Include example code. Updated version: Title: FFmpeg default Author: Ben de Groot yng...@gentoo.org Content-Type: text/plain Posted: 2015-04-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav Since the choice between ffmpeg and libav has been made more explicit, there has been a lot of discussion about what the default implementation should be. It can be concluded that media-video/ffmpeg has wider support, and would be somewhat more convenient for most end-users. For this reason the default implementation has been switched back from media-video/libav to media-video/ffmpeg by removing the libav useflag from the base profile. If the libav useflag is already globally enabled or disabled in /etc/portage/make.conf, then no further action is required. Users who implicitly relied on libav being enabled in their profile, and who wish to continue using libav, should enable USE=libav in their /etc/portage/make.conf file. Also please prepare an update to the USE=libav news item to state updated default. Diff: --- /var/portage/metadata/news/2015-02-01-use-libav/2015-02-01-use-libav.en.txt 2015-02-04 05:31:20.0 +0800 +++ /home/ben/tmp/2015-02-01-use-libav.en.txt 2015-04-06 14:05:56.982039939 +0800 @@ -2,7 +2,7 @@ Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-02-01 -Revision: 1 +Revision: 2 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav @@ -20,17 +20,17 @@ However, whenever appropriate additional USE=libav will be introduced to control the preference of one implementation over the other. -Users who currently use libav (the Gentoo default) do not have to -perform any action since USE=libav is enabled by default. It should be -noted that the users still need to enable USE=ffmpeg on packages with -optional libav support as well. Users who want to use ffmpeg instead -need to specify USE=-libav in make.conf explicitly. +Users who currently use libav need to enable USE=libav in +/etc/portage/make.conf. It should be noted that users still need to +enable USE=ffmpeg on packages with optional libav support as well. +Users who currently use ffmpeg need to take no action. Please also note that some packages support only one of the two implementations. An attempt to install one of those packages may result in blockers requiring the user changes the global USE=libav state. The most notable example of such package is media-video/mplayer. -media-video/mpv may be used as a replacement for users who prefer libav. +media-video/mpv may be used as a replacement for users who prefer libav, +even though upstream mpv developers recommend using ffmpeg. Please do not alter the state of 'libav' flag on a per-package basis (e.g. via package.use). The flag needs to be set globally to have -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Last Rites: net-misc/gns3
# Aaron Bauman b...@gentoo.org (6 Apr 2015) # Superseded by net-misc/gns3-gui and net-misc/gns3-server. # Removal in 30 days. net-misc/gns3 -- Cheers, Aaron Bauman (b-man) Gentoo Linux Developer signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC News item: FFmpeg default
Dnia 2015-04-06, o godz. 14:10:12 Ben de Groot yng...@gentoo.org napisał(a): On 30 March 2015 at 00:23, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-03-30, o godz. 00:07:16 Include example code. Updated version: Title: FFmpeg default Author: Ben de Groot yng...@gentoo.org Content-Type: text/plain Posted: 2015-04-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav Since the choice between ffmpeg and libav has been made more explicit, there has been a lot of discussion about what the default implementation should be. It can be concluded that media-video/ffmpeg has wider support, and would be somewhat more convenient for most end-users. For this reason the default implementation has been switched back from media-video/libav to media-video/ffmpeg by removing the libav useflag from the base profile. 'Switched back' is suggesting there was some 'unintentional' switch from ffmpeg to libav. Keep this free of politics, and just 'switched'. If the libav useflag is already globally enabled or disabled in /etc/portage/make.conf, then no further action is required. Users who implicitly relied on libav being enabled in their profile, and who wish to continue using libav, should enable USE=libav in their /etc/portage/make.conf file. Also please prepare an update to the USE=libav news item to state updated default. Diff: --- /var/portage/metadata/news/2015-02-01-use-libav/2015-02-01-use-libav.en.txt 2015-02-04 05:31:20.0 +0800 +++ /home/ben/tmp/2015-02-01-use-libav.en.txt 2015-04-06 14:05:56.982039939 +0800 @@ -2,7 +2,7 @@ Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-02-01 -Revision: 1 +Revision: 2 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav @@ -20,17 +20,17 @@ However, whenever appropriate additional USE=libav will be introduced to control the preference of one implementation over the other. -Users who currently use libav (the Gentoo default) do not have to -perform any action since USE=libav is enabled by default. It should be -noted that the users still need to enable USE=ffmpeg on packages with -optional libav support as well. Users who want to use ffmpeg instead -need to specify USE=-libav in make.conf explicitly. +Users who currently use libav need to enable USE=libav in +/etc/portage/make.conf. It should be noted that users still need to +enable USE=ffmpeg on packages with optional libav support as well. +Users who currently use ffmpeg need to take no action. Please also note that some packages support only one of the two implementations. An attempt to install one of those packages may result in blockers requiring the user changes the global USE=libav state. The most notable example of such package is media-video/mplayer. -media-video/mpv may be used as a replacement for users who prefer libav. +media-video/mpv may be used as a replacement for users who prefer libav, +even though upstream mpv developers recommend using ffmpeg. This is off-topic, and strongly biased. Please do not alter the state of 'libav' flag on a per-package basis (e.g. via package.use). The flag needs to be set globally to have FYI: since Council's meeting in one week, I have added this to the agenda. I'm really concerned about Gentoo's PR when users suffer due to developers ping-ponging implementations/defaults. -- Best regards, Michał Górny pgpmjTQO8Vcxi.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Review: Apache AddHandler news item
Hello Duncan, On 06.04.2015 06:53, Duncan wrote: Sebastian Pipping posted on Mon, 06 Apr 2015 01:29:19 +0200 as excerpted: Published a slightly improved version now: https://gitweb.gentoo.org/proj/gentoo-news.git/tree/2015/2015-04-06- apache-addhandler-addtype If there's anything wrong with it, please mail me directly (or put me in CC) so there is zero chance of slipping through. Thanks! [also mailing sp...@gentoo.org as requested] thanks! $ echo Apache AddHandler/AddType vulnerability protection | wc -c 51 GLEP 42 says max title length 44 chars. 51-44=7 chars too long. Actually, echo prints a newline that is also counted. So it's 50 and 6 characters too much but you still have a point :) Off the top of my head, maybe just s/vulnerability/vuln/ ? That'd cut 9 chars for 42, leaving two to spare. Anyone with a better idea? I made it say exploit now: # echo -n 'Apache AddHandler/AddType exploit protection' | wc -c 44 I hope that's correct enough in terms of security language. The fix protections against exploits of the related vulnerability. That's the big one. Here's a couple more minor English usage change suggestions as well. (Changes denoted in caps here, obviously lowercase them): Line 25, add also: may be helpful. Unfortunately, it can ALSO be a security threat. Fixed. Line 74 s/at/in/: You may be using AddHandler or AddType IN other places, Fixed. https://gitweb.gentoo.org/proj/gentoo-news.git/commit/?id=a63ce98a6297bf371488c26c034dc22f6d8877b9 Thanks for the review. Best, Sebastian
[gentoo-portage-dev] [PATCH] Enable cgroup, ipc-sandbox network-sandbox by default
All three features should be mature enough to be enabled by default. CGroups provide better tracking for ebuild processes, while the two sandboxes improve security through restricting IPC network access for build-only phases. All the features degrade gracefully when the relevant kernel features are not available. --- cnf/make.globals | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/cnf/make.globals b/cnf/make.globals index dd99618..2d93e9d 100644 --- a/cnf/make.globals +++ b/cnf/make.globals @@ -50,9 +50,10 @@ RESUMECOMMAND_SSH=${FETCHCOMMAND_SSH} FETCHCOMMAND_SFTP=bash -c \x=\\\${2#sftp://} ; host=\\\${x%%/*} ; port=\\\${host##*:} ; host=\\\${host%:*} ; [[ \\\${host} = \\\${port} ]] port=22 ; eval \\\declare -a ssh_opts=(\\\${3})\\\ ; exec sftp -P \\\${port} \\${ssh_opts[@]}\\\ \\${host}:/\\\${x#*/}\\\ \\$1 sftp \\${DISTDIR}/\${FILE}\ \\${URI}\ \\${PORTAGE_SSH_OPTS}\ # Default user options -FEATURES=assume-digests binpkg-logs +FEATURES=assume-digests binpkg-logs cgroup config-protect-if-modified distlocks ebuild-locks - fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned + fixlafiles ipc-sandbox merge-sync network-sandbox + news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync -- 2.3.5
Re: [gentoo-portage-dev] Re: Dynamic USE dependencies
On Mon, Apr 6, 2015 at 8:02 AM, Martin Vaeth mar...@mvath.de wrote: My suggestion is something in between - less invasive (and, in particular, less time consuming) than your suggestion to recalculate the USE-settings with every emerge, but more automatic than the current state. Keep in mind that keeping track of past decisions made by portage does not require user-editable config files in /etc. It just requires a cache of some kind, much as we do with installed packages/etc. That said, portage still has to spend time basically re-validating the consistency of the entire system because we allow the use of overlays and other situations that don't guarantee that portage will have some kind of consistent pre-calculated depgraph handed to it. If we required all repositories to have some kind of pre-generated cache in them and ensured that this was always up-to-date and better controlled the kinds of dependency changes we made, then maybe there might be an opportunity to offload some of the work to the repository level instead of doing it on every Gentoo system. Still, unless we banned overlays I'm not sure how much even this would buy you, since you'd have many of these that need to be merged somehow. From Zac's email and other discussions in the past it seems like we're basically committed to doing all these calculations all the time anyway, so we shouldn't be too shy about taking advantage of them. -- Rich
[gentoo-portage-dev] Re: Dynamic USE dependencies
Rich Freeman ri...@gentoo.org wrote: On Sun, Apr 5, 2015 at 11:47 AM, Martin Vaeth mar...@mvath.de wrote: One suggestion around this problem would be to use different directories for these two types of use-flags, say package.use and package.use.needed. I still think we need a better long-term solution, but the workaround is simpler than that. I try to keep files in directories for package.keywords and package.use. One starts with a z and is a dumping ground for auto-whatever. So you use package.use/z instead of package.use.needed as in my suggestion. (In fact, I do currently a similar thing, only that I use a file named zzz_autounmask, because this is even later in the alphabet). I think it would be more transparent to the user if really a dedicated directory/file would be used and not some which by accident is the last in the alphabet. Anyway, this is a minor issue. The main problem is how to cleanup this directory/file (no matter how it is called). Currently, the only way to do this, is to remove this file and to hope that portage can recreate it. Unfortunately, quite often portage is not able to do this. The problem is at least NP hard, so probably any backtracking value just is too low. If portage would use the old values as a hint, how conflicts might possibly be resolved, perhaps this algorithm might be improved. However, I think a cleaner solution would be better... ++ My suggestion is something in between - less invasive (and, in particular, less time consuming) than your suggestion to recalculate the USE-settings with every emerge, but more automatic than the current state. With my suggestion the USE-settings have to be recalculated only if a special command is used (or - as currently - if resolving is not possible without changing USE-flags). Probably other approaches are possible, too.