[gentoo-dev] [warning] the bug queue has 108 bugs

2015-04-06 Thread Alex Alexander
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

2015-04-06 Thread Diego Elio Pettenò
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

2015-04-06 Thread Paul B. Henson
 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

2015-04-06 Thread Jason A. Donenfeld
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

2015-04-06 Thread Ben de Groot
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

2015-04-06 Thread Ben de Groot
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

2015-04-06 Thread Diego Elio Pettenò
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

2015-04-06 Thread Ben de Groot
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

2015-04-06 Thread Aaron Bauman
# 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

2015-04-06 Thread Michał Górny
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

2015-04-06 Thread Sebastian Pipping
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

2015-04-06 Thread Michał Górny
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

2015-04-06 Thread Rich Freeman
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

2015-04-06 Thread Martin Vaeth
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.