date:20150329

Dnia 2015-03-30, o godz. 00:07:16
Ben de Groot yng...@gentoo.org napisał(a):

 Title: FFmpeg default
 Author: Ben de Groot yng...@gentoo.org
 Content-Type: text/plain
 Posted: 2015-04-01
 Revision: 1
 News-Item-Format: 1.0
 Display-If-Installed: virtual/ffmpeg
 
 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
 this in their local /etc/portage configuration.

Include example code.

Also please prepare an update to the USE=libav news item to state
updated default.

-- 
Best regards,
Michał Górny


pgpitKpfm_2ac.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: multilib amd64 news item for review


On 17/03/15 18:29, Michał Górny wrote:

Dnia 2015-03-17, o godz. 16:55:32
René Neumann li...@necoro.eu napisał(a):


Am 17.03.2015 um 16:33 schrieb Michał Górny:

  However, some
users may prefer setting ABI_X86 globally to enable 32-bit libraries
in all packages that support building them. This can be done using
the following package.use entry:

  */* abi_x86_32



I'm confused: Has this a different semantics from adding
USE+='abi_x86_32' to make.conf? If no, why mention this strange way
(which is new to me) for setting default global useflags.


Because this is how users learn new fun stuff. Like sane configuration.


I don't see why ABI_X86 is not the sane option. Using wildcards in 
package.use is what sounds insane to me.


Are you suggesting that the sane way of setting USE flags globally is 
moving them from make.conf into package.use and use wildcards to set 
them globally?




And to bring this even further: Wouldn't the nicest approach to add
ABI_X86=32


This will disable some 64-bit web browser plugins.


I don't see why the package.use wildcard wouldn't do that too.



ABI_X86=32 64
to make.conf? (With the latter being more descriptive, as the first one
might suggest that _only_ 32bit should be built).


This will enable some possibly-unwanted 64-bit software, e.g. 64-bit
Windows support in wine.


I don't see why the package.use wildcard wouldn't do that too.

Re: [gentoo-dev] Should Gentoo do https by default?

Dnia 2015-03-27, o godz. 15:33:15
Hanno Böck ha...@gentoo.org napisał(a):

 I think defaulting the net to HTTPS is a big step for more security and
 I think Gentoo should join the trend here.

While I don't mind this entirely, we need to make sure to get things
right. For example, I'm quite unhappy being unable to use Forums or
sources.g.o from my phone because of some SSL issues… Do you really
believe serving content insecurely is worse than serving no content
at all?

-- 
Best regards,
Michał Górny


pgpzn579fMX37.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: app-emulation/emul-linux-x86*

Dnia 2015-03-29, o godz. 11:57:12
James Le Cuirot ch...@gentoo.org napisał(a):

 On Sun, 29 Mar 2015 12:13:32 +0200
 Pacho Ramos pa...@gentoo.org wrote:
 
   app-emulation/emul-linux-x86-jna-20140508-r1  
  
  Why do we need to keep app-emulation/emul-linux-x86-jna-20140508-r1 to
  simply end up rdepending on
  =virtual/libffi-3.0.13-r1[abi_x86_32(-)] ? Also, no package in the
  tree rdepends on this emul set and, then,
  packages outside portage could simply rdepend on libffi directly
  instead of needing to keep this
 
 Michał, as already discussed with Pacho [1], emul-linux-x86-jna can just
 go away entirely. Nothing requires it and it doesn't make any sense
 without emul-linux-x86-java though I note that isn't in the list either;
 I thought it would be. Java herd is struggling with the regular VM
 packages enough as it is, we could really do without supporting this
 one as well. I very much doubt that end users need it any more. Any
 objections to removing it?
 
 [1] https://bugs.gentoo.org/show_bug.cgi?id=474464#c5

I don't really want to touch Java stuff, so I'd prefer if you handled
that yourself. That said, feel free to add it to the same p.mask entry.
Just make sure not to break the dependency graph :).

-- 
Best regards,
Michał Górny


pgpcg6iJ6xE0A.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: multilib amd64 news item for review

Dnia 2015-03-29, o godz. 19:14:43
Nikos Chantziaras rea...@gmail.com napisał(a):

 On 17/03/15 18:29, Michał Górny wrote:
  Dnia 2015-03-17, o godz. 16:55:32
  René Neumann li...@necoro.eu napisał(a):
 
  Am 17.03.2015 um 16:33 schrieb Michał Górny:
However, some
  users may prefer setting ABI_X86 globally to enable 32-bit libraries
  in all packages that support building them. This can be done using
  the following package.use entry:
 
*/* abi_x86_32
 
 
  I'm confused: Has this a different semantics from adding
  USE+='abi_x86_32' to make.conf? If no, why mention this strange way
  (which is new to me) for setting default global useflags.
 
  Because this is how users learn new fun stuff. Like sane configuration.
 
 I don't see why ABI_X86 is not the sane option. Using wildcards in 
 package.use is what sounds insane to me.

Because it overrides the defaults without providing a way to append to
them.

 Are you suggesting that the sane way of setting USE flags globally is 
 moving them from make.conf into package.use and use wildcards to set 
 them globally?

Yes.

  And to bring this even further: Wouldn't the nicest approach to add
  ABI_X86=32
 
  This will disable some 64-bit web browser plugins.
 
 I don't see why the package.use wildcard wouldn't do that too.

It is applied on top of the default rather than overriding it.

  ABI_X86=32 64
  to make.conf? (With the latter being more descriptive, as the first one
  might suggest that _only_ 32bit should be built).
 
  This will enable some possibly-unwanted 64-bit software, e.g. 64-bit
  Windows support in wine.
 
 I don't see why the package.use wildcard wouldn't do that too.

Ditto.

-- 
Best regards,
Michał Górny


pgpMbkABIYH83.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: zsh completions -- optional or mandatory?

2015-03-29 Thread Andreas K. Huettel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Donnerstag, 26. März 2015, 17:51:04 schrieb William Hubbs:

 I'm seeing at least two ways of handling zsh completion files in the
 tree.
 
[...]

 The other method is shown by dev-vcs/hub at least, and maybe several
 other packages -- e.g. unconditionally installing the completions
 according to our small files installation practice and not reflecting
 the rdepend on app-shells/zsh.
 
 I think we should be consistent with how we handle this, and personally
 I would vote for the first way since zsh is not all that common.
 However, if the feeling is that we should nuke the zsh-completion use
 flag, I'll be the first to do it, and I'll start opening bugs against
 other packages.

Please let's nuke the useflag and install the files unconditionally. This is 
the overall agreed policy for small add-on files.

(The only real alternative would be to finally, please, please, please 
introduce IUSE_RUNTIME. Which just got booted from EAPI=6 again.)

- -- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVF+6gAAoJEB9VdM6hupKV0LAP/0NZxMJ0Gt+Fz89la1LTkfpq
88HehQQ7u69liFX+/EI+dWMS8ZCzg9H1VefhIWwDIC42LAVE+gPbheVBSgfcqFr2
8KLsPrl4Vp++XyidScE5CD71Oy/XXK6wsy8VoPQtppGAKEh56+cqIdSwUpU4W4yj
o1blqw+/pnwuuxnwdVGuhrht24xVhMdZOTDGVpUqscxIiEvn9lDFQydy7OYZlk3n
wQsQQ5SiCWZXHJjhSxbvRBSIzXVt4enp/f/mUpf+p3f16M2tS/ALeCpR/TB1o62d
FPWCDPaMzxMaAIoxObQ021cRWOcZ09kBxJstI/7J1Vnw0W0zFyLlevJ6wmwoimGl
Vav1zGZMk0cl/ft8c6nlRi876eDwpwGAhsF51MM4ijtB4mBkBveR+gLUjHDdOYWq
jOqOysDF1Fv0JeVwJEpk71HotcN/ev1GE3DlveaGssT9lPb1sQrCRydkIxwKKuoQ
v/AjeBkTSliQ0vtYID4hUdSlVTpkcdURqtckuXJiVxqxhOMh87XKuzR67R16hUU2
mgizmqYnlnSm9+cG4XKDE3y3q4w1QIynjZyjQJDWySaF7yV6SRSuyEaTK///1ufH
k1E0NX9IG+9uIzxUgxhh3GqCy8h5pqFvXXHtGYJU5ipUVJCfVHQAGcWNY+qga6dB
3j1XVICXWyptqyXhfJFu
=YceU
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: zsh completions -- optional or mandatory?

Dnia 2015-03-29, o godz. 14:22:56
Andreas K. Huettel dilfri...@gentoo.org napisał(a):

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 Am Donnerstag, 26. März 2015, 17:51:04 schrieb William Hubbs:
 
  I'm seeing at least two ways of handling zsh completion files in the
  tree.
  
 [...]
 
  The other method is shown by dev-vcs/hub at least, and maybe several
  other packages -- e.g. unconditionally installing the completions
  according to our small files installation practice and not reflecting
  the rdepend on app-shells/zsh.
  
  I think we should be consistent with how we handle this, and personally
  I would vote for the first way since zsh is not all that common.
  However, if the feeling is that we should nuke the zsh-completion use
  flag, I'll be the first to do it, and I'll start opening bugs against
  other packages.
 
 Please let's nuke the useflag and install the files unconditionally. This is 
 the overall agreed policy for small add-on files.
 
 (The only real alternative would be to finally, please, please, please 
 introduce IUSE_RUNTIME. Which just got booted from EAPI=6 again.)

IUSE_RUNTIME wouldn't allow you to change installed files.

-- 
Best regards,
Michał Górny


pgpH1WLAQHN7H.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: multilib amd64 news item for review


On 29/03/15 19:24, Michał Górny wrote:

Dnia 2015-03-29, o godz. 19:14:43
Nikos Chantziaras rea...@gmail.com napisał(a):


On 17/03/15 18:29, Michał Górny wrote:

Dnia 2015-03-17, o godz. 16:55:32
René Neumann li...@necoro.eu napisał(a):


Am 17.03.2015 um 16:33 schrieb Michał Górny:

   However, some
users may prefer setting ABI_X86 globally to enable 32-bit libraries
in all packages that support building them. This can be done using
the following package.use entry:

   */* abi_x86_32



I'm confused: Has this a different semantics from adding
USE+='abi_x86_32' to make.conf? If no, why mention this strange way
(which is new to me) for setting default global useflags.


Because this is how users learn new fun stuff. Like sane configuration.


I don't see why ABI_X86 is not the sane option. Using wildcards in
package.use is what sounds insane to me.


Because it overrides the defaults without providing a way to append to
them.


According to emerge --info, ABI_X86 seems to append, not override. In 
make.conf:


  ABI_X86=32

Then:

  $ emerge --info | grep -i abi_x86

You get:

  ABI_X86=32 64


64 seems to be always there. You cannot override it. Using 
ABI_X86=32 in make.conf seems to only append 32 to the default.


If this is not the case, and */* abi_x86_32 in package.use really does 
something different, then this is implemented in a way too confusing for 
people and should be considered a bug :-/

Re: [gentoo-dev] Re: multilib amd64 news item for review

Dnia 2015-03-29, o godz. 19:59:19
Nikos Chantziaras rea...@gmail.com napisał(a):

 On 29/03/15 19:24, Michał Górny wrote:
  Dnia 2015-03-29, o godz. 19:14:43
  Nikos Chantziaras rea...@gmail.com napisał(a):
 
  On 17/03/15 18:29, Michał Górny wrote:
  Dnia 2015-03-17, o godz. 16:55:32
  René Neumann li...@necoro.eu napisał(a):
 
  Am 17.03.2015 um 16:33 schrieb Michał Górny:
 However, some
  users may prefer setting ABI_X86 globally to enable 32-bit libraries
  in all packages that support building them. This can be done using
  the following package.use entry:
 
 */* abi_x86_32
 
 
  I'm confused: Has this a different semantics from adding
  USE+='abi_x86_32' to make.conf? If no, why mention this strange way
  (which is new to me) for setting default global useflags.
 
  Because this is how users learn new fun stuff. Like sane configuration.
 
  I don't see why ABI_X86 is not the sane option. Using wildcards in
  package.use is what sounds insane to me.
 
  Because it overrides the defaults without providing a way to append to
  them.
 
 According to emerge --info, ABI_X86 seems to append, not override. In 
 make.conf:
 
ABI_X86=32
 
 Then:
 
$ emerge --info | grep -i abi_x86
 
 You get:
 
ABI_X86=32 64
 
 
 64 seems to be always there. You cannot override it. Using 
 ABI_X86=32 in make.conf seems to only append 32 to the default.

Portage may do that because it's forced by default. But some packages
'unforce' it, and that's when it matters.

 
 If this is not the case, and */* abi_x86_32 in package.use really does 
 something different, then this is implemented in a way too confusing for 
 people and should be considered a bug :-/

Yes, USE support in make.conf is a big pile of random misbehaviors
and bugs that need to be killed with fire.


-- 
Best regards,
Michał Górny


pgpTYXut6UTdz.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

Despite of all you're talking about is right from paranoid point of view, I'd,
anyway, say DO NOT DO THAT, because you propose to revoke the right of
choice from the users.

It is user's decision, which protocol to use to fetch the sources. Although,
you're, of course, free to make layman to fetch official repos from https,
but not http/git protocols by default.

Moreover, there are some times where it is impossible to fetch sources via
secure way, but you need it right here and right now.

В письме от Вс, 29 марта 2015 18:41:33 пользователь Sebastian Pipping написал:
Hi!

For the current Gentoo Git setup I found these methods working for
accessing a repository, betagarden in this case:

git://anongit.gentoo.org/proj/betagarden.git
(git://git.gentoo.org/proj/betagarden.git)
(git://git.overlays.gentoo.org/proj/betagarden.git)

http://anongit.gentoo.org/git/proj/betagarden.git

(http://cgit.gentooexperimental.org/proj/betagarden.git)

git+ssh://g...@git.gentoo.org/proj/betagarden.git
(git+ssh://g...@git.overlays.gentoo.org/proj/betagarden.git)

Those without braces are the ones announced at the repository's page [1].

My concerns about the current set of supported ways of transfer are:

* There does not seem to be support for https://. Please add it.

* Why do we serve Git over git:// and http:// if those are vulnerable
to man-in-the-middle attacks (before having waterproof GPG
protection for whole repositories in place)?
Especially with ebuilds run by root, we cannot afford MITM.

So I would like to propose that

* support for Git access through https:// is activated,

* Git access through http:// and git:// is deactivated, and

* the URLs on gitweb.gentoo.org and the Layman registry are
updated accordingly. (Happy to help with the latter.)

Thanks for your consideration.

Best,

Sebastian

[1] https://gitweb.gentoo.org/proj/betagarden.git/

--
Best regards,
mva

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: multilib amd64 news item for review

On Sun, 29 Mar 2015 19:28:22 +0200 Michał Górny wrote:
  If this is not the case, and */* abi_x86_32 in package.use really does 
  something different, then this is implemented in a way too confusing for 
  people and should be considered a bug :-/
 
 Yes, USE support in make.conf is a big pile of random misbehaviors
 and bugs that need to be killed with fire.

The proposal above is an absolute madness, especially for global
USE flags.

Why users should deal with dozens (if not hundreds useless */*)?

Best regards,
Andrew Savchenko


pgp3bqx8yyxIN.pgp
Description: PGP signature

Re: [gentoo-dev] Re: multilib amd64 news item for review

Dnia 2015-03-29, o godz. 20:35:27
Andrew Savchenko birc...@gentoo.org napisał(a):

 On Sun, 29 Mar 2015 19:28:22 +0200 Michał Górny wrote:
   If this is not the case, and */* abi_x86_32 in package.use really does 
   something different, then this is implemented in a way too confusing for 
   people and should be considered a bug :-/
  
  Yes, USE support in make.conf is a big pile of random misbehaviors
  and bugs that need to be killed with fire.
 
 The proposal above is an absolute madness, especially for global
 USE flags.
 
 Why users should deal with dozens (if not hundreds useless */*)?

To get sane, consistent and predictable config for a start. But you
know that you can specify multiple flags on one line, right? In fact,
'*/* ' is shorter than 'USE='!


-- 
Best regards,
Michał Górny


pgpdNQzPcaXHj.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

 Doesn't git:// uses SSH wich is secure? I think that was on github.
git+ssh:// — does. git:// — does not. It is just git-daemon listening on 
separate port and serving plaintext, readonly (by default) access.

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

 GitHub does not support git:// but only secure protocols (HTTPS, SSH),
GitHub DO (!) support git://

$ git clone git://github.com/msva/mva-overlay.git
Cloning into 'mva-overlay'...
remote: Counting objects: 10435, done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 10435 (delta 11), reused 0 (delta 0), pack-reused 10393
Receiving objects: 100% (10435/10435), 2.99 MiB | 758.00 KiB/s, done.
Resolving deltas: 100% (5132/5132), done.
Checking connectivity... done.


 see [2].

shoud-i-use != do not support

-- 
Best regards,
mva


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Re: [gentoo-user] Re: This nite's switch to full multilib

(crossposting to -dev since this is fairly high-impact)

On Sun, Mar 29, 2015 at 1:27 PM, Michael Palimaka kensing...@gentoo.org wrote:
 On 30/03/15 03:43, waben...@gmail.com wrote:

 I also have dev-qt/qtcore-4.8.5-r2 and some other qt packages installed
 but I had no problems with that.

 I'm on gentoo stable (not ~amd64) and I don't use KDE.

 If you're on stable, you'll need to keyword qt-4.8.6 in its entirety.
 You can't mix and match versions, and 4.8.6 is the only one that
 supports multilib.

I think we really need to either stabilize 4.8.6, or backport
qtchooser/multilib/etc to the current stable version.

qt is a pretty significant package to have break with multilib, and
trying to run qt-5 on a stable system is already a nightmare with the
qtchooser switch (in my case I ended up abandoning qt5 as I didn't
need it that badly).

-- 
Rich

[gentoo-dev] Re: multilib amd64 news item for review


On 29/03/15 21:00, Andrew Savchenko wrote:

*/* long list of 433 flags


Yeah, just noticed that I can't split the lines.

I then tried to define an array of USE flags in make.conf:

  GLOBAL_USE_FLAGS=( ... )

so that I can then use that array in package.use, but for some reason 
make.conf doesn't accept arrays :-/

Re: [gentoo-dev] Re: multilib amd64 news item for review

Dnia 2015-03-29, o godz. 21:31:49
Nikos Chantziaras rea...@gmail.com napisał(a):

 On 29/03/15 21:00, Andrew Savchenko wrote:
  */* long list of 433 flags
 
 Yeah, just noticed that I can't split the lines.
 
 I then tried to define an array of USE flags in make.conf:
 
GLOBAL_USE_FLAGS=( ... )
 
 so that I can then use that array in package.use, but for some reason 
 make.conf doesn't accept arrays :-/

Because make.conf is only pseudo-shell that is parsed with a broken
pseudo-shell parser.

-- 
Best regards,
Michał Górny


pgpkgTJzc4mqd.pgp
Description: OpenPGP digital signature

[gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

Hi!


For the current Gentoo Git setup I found these methods working for
accessing a repository, betagarden in this case:

  git://anongit.gentoo.org/proj/betagarden.git
 (git://git.gentoo.org/proj/betagarden.git)
 (git://git.overlays.gentoo.org/proj/betagarden.git)

  http://anongit.gentoo.org/git/proj/betagarden.git

 (http://cgit.gentooexperimental.org/proj/betagarden.git)

  git+ssh://g...@git.gentoo.org/proj/betagarden.git
 (git+ssh://g...@git.overlays.gentoo.org/proj/betagarden.git)

Those without braces are the ones announced at the repository's page [1].

My concerns about the current set of supported ways of transfer are:

 * There does not seem to be support for https://.  Please add it.

 * Why do we serve Git over git:// and http:// if those are vulnerable
   to man-in-the-middle attacks (before having waterproof GPG
   protection for whole repositories in place)?
   Especially with ebuilds run by root, we cannot afford MITM.


So I would like to propose that

 * support for Git access through https:// is activated,

 * Git access through http:// and git:// is deactivated, and

 * the URLs on gitweb.gentoo.org and the Layman registry are
   updated accordingly.  (Happy to help with the latter.)


Thanks for your consideration.

Best,



Sebastian


[1] https://gitweb.gentoo.org/proj/betagarden.git/

Re: [gentoo-dev] Should Gentoo do https by default?

Dnia 2015-03-29, o godz. 18:50:17
Hanno Böck ha...@gentoo.org napisał(a):

 On Sun, 29 Mar 2015 16:46:05 +0200
 Michał Górny mgo...@gentoo.org wrote:
 
  While I don't mind this entirely, we need to make sure to get things
  right. For example, I'm quite unhappy being unable to use Forums or
  sources.g.o from my phone because of some SSL issues…
 
 Can you be more specific on that? Of course if there are problems we
 should fix them - and I'm glad to help in analyzing those.
 (However there are some unfortunate issues that are hard to fix, e.g.
 some devices relying on broken protocols like sslv3 - but I think these
 should be rare)
 
 What phone? Should we move such issues to bugzilla? (cc me if you open
 a bug)

Xperia X10 Mini, with ancient Android 2.1.

bugs.gentoo.org works, though it complains about hostname mismatch (I
guess it doesn't handle wildcard certs or sth).

forums.gentoo.org, sources.gentoo.org it first complains about
untrusted issuer, and after telling it to configure tries a bit more
and gives 'Unable to connect to server, try again later.'

-- 
Best regards,
Michał Górny


pgpJMrdIriBa1.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: multilib amd64 news item for review

2015-03-29 Thread Ciaran McCreesh

On Sun, 29 Mar 2015 20:35:27 +0300
Andrew Savchenko birc...@gentoo.org wrote:
 The proposal above is an absolute madness, especially for global
 USE flags.
 
 Why users should deal with dozens (if not hundreds useless */*)?

The syntax for package.use allows multiple flags per line, and
comments...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

2015-03-29 Thread Kristian Fiskerstrand

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/29/2015 06:41 PM, Sebastian Pipping wrote:
 Hi!
 

...

 
 * Why do we serve Git over git:// and http:// if those are
 vulnerable to man-in-the-middle attacks (before having waterproof
 GPG protection for whole repositories in place)?

pedantOpenPGP (GPG is just one implementation)/pedant, but indeed,
that is what the gentoo-keys project is about. There is experimental
support for OpenPGP verification in portage already using gkeys.
Currently the focus is on getting developer's keys up to GLEP63 specs,
i currently see 36 good Gentoo developer keys. The scheme is also
flexible enough to allow for overlays.

 Especially with ebuilds run by root, we cannot afford MITM.
 
 
 So I would like to propose that
 
 * support for Git access through https:// is activated,

https is not a good protection against MITM when factoring in global
PKIX CA setup, nor would it protect with regards to server compromise.
So the only viable way to secure ebuild repositories is proper OpenPGP
usage.


- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVGD9LAAoJEP7VAChXwav6VmsIALlhZ1g1GXYAL/ZkP+vi1L0H
MLKfYcxkMgZNwEfykmRP4DvafNPDDhWT0gvFfD+vG4zucI7liQSUnzK8SbVtzz3l
o/cCELtOvjq6pMnefizwxoG0IyJmu07Tu2kUPo3Qyw1I5IqHqaqFWDB/Noe5Rvuy
rbXgWqMgg6rcYxOhUHN4YQFtw1xEgWW4CS8Smri2jjSRaizgQ2sw+Iji/ej4XUyW
JvWdZfGfHuzTX/uWPr7ptyi9foVvTkc9Hko2t97XS/bNZvtECRNceZBOTGgHftgD
nCopTHBY42G69B+z07qctdI2AH2ozskI1+42rE2k6vJLNfFcY5loidsWDPiG3a8=
=9GQH
-END PGP SIGNATURE-

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

 
 They would not do online banking over http, right?  Why would they run
 code with root privileges from http?

1) Actually, they will :(
2) Because they can't review what bank received via insecure channel, while 
they can review what they're themselves received via http/git.

-- 
Best regards,
mva


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs

2015-03-29 Thread Matthias Schwarzott

Hi there!

I updated my ~amd64 system recently to new hardware (Intel Core i3-4160).
Since then valgrind did no longer work for 32bit programs because
-march=native did choose instructions that valgrind does not support
in 32bit mode (even ld.so was unusable).

After some research I put this into make.conf and now it works:
CFLAGS_x86=${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2
CXXFLAGS_x86=${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2

Is this the best solution to the problem?
If yes, the valgrind ebuild could suggest something like this.
Either always show it or check cpu-flags first (is this maintainable?).

Regards
Matthias

Re: [gentoo-dev] RFC News item: FFmpeg default

2015-03-29 Thread Peter Stuge

Ben de Groot wrote:
 Title: FFmpeg default
 Posted: 2015-04-01

Bad date for such news.


//Peter

Re: [gentoo-dev] Should Gentoo do https by default?

2015-03-29 Thread James Le Cuirot

On Sun, 29 Mar 2015 19:23:51 +0200
Michał Górny mgo...@gentoo.org wrote:

 Xperia X10 Mini, with ancient Android 2.1.
 
 bugs.gentoo.org works, though it complains about hostname mismatch (I
 guess it doesn't handle wildcard certs or sth).

Not exactly, it can't handle servers with more than one SSL certificate
per IP. A wildcard certificate probably would work. Android 2.3
(Gingerbread) is the last release and probably the only OS of any
significant concern to not support SNI at all. Even XP does with
certain browsers.

I know that particular phone and to be fair, it's pretty poor. That
240x320 screen surely hurts your eyes. ;) You could probably pick up
something better for nothing. That phone can also be rooted quite
easily (I've done it) and then flashed with something more recent.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpnCRFXGIzBb.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
 So I would like to propose that
 
  * support for Git access through https:// is activated,
 
  * Git access through http:// and git:// is deactivated, and

Some people have https blocked. http:// and git:// must be
available read-only.

Best regards,
Andrew Savchenko


pgpMY89uyP7TG.pgp
Description: PGP signature

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

On 29.03.2015 19:39, Andrew Savchenko wrote:
 On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
 So I would like to propose that
 
 * support for Git access through https:// is activated,
 
 * Git access through http:// and git:// is deactivated, and
 
 Some people have https blocked. http:// and git:// must be 
 available read-only.

They would not do online banking over http, right?  Why would they run
code with root privileges from http?

Best,



Sebastian

[gentoo-dev] Re: multilib amd64 news item for review


On 29/03/15 20:28, Michał Górny wrote:

Dnia 2015-03-29, o godz. 19:59:19
Nikos Chantziaras rea...@gmail.com napisał(a):

According to emerge --info, ABI_X86 seems to append, not override. In
make.conf:

ABI_X86=32

Then:

$ emerge --info | grep -i abi_x86

You get:

ABI_X86=32 64


64 seems to be always there. You cannot override it. Using
ABI_X86=32 in make.conf seems to only append 32 to the default.


Portage may do that because it's forced by default. But some packages
'unforce' it, and that's when it matters.



If this is not the case, and */* abi_x86_32 in package.use really does
something different, then this is implemented in a way too confusing for
people and should be considered a bug :-/


Yes, USE support in make.conf is a big pile of random misbehaviors
and bugs that need to be killed with fire.


Looks like I'm moving USE flags and abi_x86_32 into package.use...

I hope that doesn't compromise emerge --info output for bugzilla issues?

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

2015-03-29 Thread Diamond

On Sun, 29 Mar 2015 18:41:33 +0200
Sebastian Pipping sp...@gentoo.org wrote:

 Hi!
 
 
 For the current Gentoo Git setup I found these methods working for
 accessing a repository, betagarden in this case:
 
   git://anongit.gentoo.org/proj/betagarden.git
  (git://git.gentoo.org/proj/betagarden.git)
  (git://git.overlays.gentoo.org/proj/betagarden.git)
 
   http://anongit.gentoo.org/git/proj/betagarden.git
 
  (http://cgit.gentooexperimental.org/proj/betagarden.git)
 
   git+ssh://g...@git.gentoo.org/proj/betagarden.git
  (git+ssh://g...@git.overlays.gentoo.org/proj/betagarden.git)
 
 Those without braces are the ones announced at the repository's page
 [1].
 
 My concerns about the current set of supported ways of transfer are:
 
  * There does not seem to be support for https://.  Please add it.
 
  * Why do we serve Git over git:// and http:// if those are vulnerable
to man-in-the-middle attacks (before having waterproof GPG
protection for whole repositories in place)?
Especially with ebuilds run by root, we cannot afford MITM.
 
 
 So I would like to propose that
 
  * support for Git access through https:// is activated,
 
  * Git access through http:// and git:// is deactivated, and
 
  * the URLs on gitweb.gentoo.org and the Layman registry are
updated accordingly.  (Happy to help with the latter.)
 
 
 Thanks for your consideration.
 
 Best,
 
 
 
 Sebastian
 
 
 [1] https://gitweb.gentoo.org/proj/betagarden.git/
 
 
Doesn't git:// uses SSH wich is secure? I think that was on github.

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

On Sun, 29 Mar 2015 19:52:38 +0200 Sebastian Pipping wrote:
 On 29.03.2015 19:39, Andrew Savchenko wrote:
  On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
  So I would like to propose that
  
  * support for Git access through https:// is activated,
  
  * Git access through http:// and git:// is deactivated, and
  
  Some people have https blocked. http:// and git:// must be 
  available read-only.
 
 They would not do online banking over http, right?  Why would they run
 code with root privileges from http?

Gentoo tree access is not even near on the same security scale as
online banking.

Best regards,
Andrew Savchenko


pgpNDyzmTqg3y.pgp
Description: PGP signature

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

On 29.03.2015 19:56, Diamond wrote:
 Doesn't git:// uses SSH wich is secure? I think that was on github.

git:// is the git protocol [1] with absolutely no authentication and
no encryption.

GitHub does not support git:// but only secure protocols (HTTPS, SSH),
see [2].

Best,



Sebastian


[1]
http://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#The-Git-Protocol
[2] https://help.github.com/articles/which-remote-url-should-i-use/

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

 pedantOpenPGP (GPG is just one implementation)/pedant, but indeed,
 that is what the gentoo-keys project is about. There is experimental
 support for OpenPGP verification in portage already using gkeys.
 Currently the focus is on getting developer's keys up to GLEP63 specs,
 i currently see 36 good Gentoo developer keys. The scheme is also
 flexible enough to allow for overlays.
 
 
 https is not a good protection against MITM when factoring in global
 PKIX CA setup, nor would it protect with regards to server compromise.
 So the only viable way to secure ebuild repositories is proper OpenPGP
 usage.

I'd double that pedant paranoid! :)

-- 
Best regards,
mva


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

On Sun, Mar 29, 2015 at 1:52 PM, Sebastian Pipping sp...@gentoo.org wrote:
 On 29.03.2015 19:39, Andrew Savchenko wrote:
 On Sun, 29 Mar 2015 18:41:33 +0200 Sebastian Pipping wrote:
 So I would like to propose that

 * support for Git access through https:// is activated,

 * Git access through http:// and git:// is deactivated, and

 Some people have https blocked. http:// and git:// must be
 available read-only.

 They would not do online banking over http, right?  Why would they run
 code with root privileges from http?


I don't see the point in disabling it.  Certainly we should support
ssl though.  If people want to obtain their code over http they should
be permitted to do so.  Even without using ssl it is easy to just
check that your commit hash is correct and it becomes as tamper-proof
as sha1 (tell me again why the scm of the future is still using
sha1?).

-- 
Rich

Re: [gentoo-dev] Should Gentoo do https by default?

2015-03-29 Thread Hanno Böck

On Sun, 29 Mar 2015 16:46:05 +0200
Michał Górny mgo...@gentoo.org wrote:

 While I don't mind this entirely, we need to make sure to get things
 right. For example, I'm quite unhappy being unable to use Forums or
 sources.g.o from my phone because of some SSL issues…

Can you be more specific on that? Of course if there are problems we
should fix them - and I'm glad to help in analyzing those.
(However there are some unfortunate issues that are hard to fix, e.g.
some devices relying on broken protocols like sslv3 - but I think these
should be rare)

What phone? Should we move such issues to bugzilla? (cc me if you open
a bug)

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpyyxhG77Xma.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: multilib amd64 news item for review

On Sun, 29 Mar 2015 19:43:51 +0200 Michał Górny wrote:
 Dnia 2015-03-29, o godz. 20:35:27
 Andrew Savchenko birc...@gentoo.org napisał(a):
 
  On Sun, 29 Mar 2015 19:28:22 +0200 Michał Górny wrote:
If this is not the case, and */* abi_x86_32 in package.use really 
does 
something different, then this is implemented in a way too confusing 
for 
people and should be considered a bug :-/
   
   Yes, USE support in make.conf is a big pile of random misbehaviors
   and bugs that need to be killed with fire.
  
  The proposal above is an absolute madness, especially for global
  USE flags.
  
  Why users should deal with dozens (if not hundreds useless */*)?
 
 To get sane, consistent and predictable config for a start. But you
 know that you can specify multiple flags on one line, right?

I'm well aware of that..

 In fact, '*/* ' is shorter than 'USE='!

Only for short sets. For a long list of USE flags right now I have:
USE=
flag1
-flag2
flag3
...
flag433


This is an easily maintainable list, which is alphabetically sorted
(it is trivial to do in vim).

Why 433 flags? Because for flags common to more than a single
package I don't want to duplicate them. For unique flags I have 225
entries (with comments) in package.use.

With your proposal I have three alternatives:

1.
*/* long list of 433 flags

Hard to read, hard to maintain, no benefits.

2.
*/* flag1
*/* -flag2
*/* flag3
...
*/* flag433

A lot of useless stuff, no benefits.

3.
*/* \
flag1 \
-flag2 \
flag3 \
... \
flag433

A lot of useless stuff, no benefits, easy to make mistake (e.g.
forgot \ after a new flag and have a lot of stuff broken).

Best regards,
Andrew Savchenko


pgppjXewzvxKD.pgp
Description: PGP signature

Re: [gentoo-dev] Last rites: app-emulation/emul-linux-x86*

2015-03-29 Thread Pacho Ramos

El sáb, 28-03-2015 a las 23:03 +0100, Michał Górny escribió:
 # Michał Górny mgo...@gentoo.org (14 Sep 2014)
 # on behalf of gx86-multilib project multi...@gentoo.org
 # Mask emul-linux-x86 packages along with unported old versions
 # of reverse dependencies for removal in 60 days, bug #544876.
 # Please use multilib ebuilds with abi_x86_32 instead.

Thanks a lot! :D

[...]
 app-emulation/emul-linux-x86-jna-20140508-r1

Why do we need to keep app-emulation/emul-linux-x86-jna-20140508-r1 to
simply end up rdepending on =virtual/libffi-3.0.13-r1[abi_x86_32(-)] ?
Also, no package in the tree rdepends on this emul set and, then,
packages outside portage could simply rdepend on libffi directly instead
of needing to keep this

Re: [gentoo-dev] Cluster tinderbox poc

2015-03-29 Thread Pacho Ramos

El sáb, 28-03-2015 a las 17:20 +0100, Magnus Granberg escribió:
 Hi
 
 As some of you may know, I have been working on code for a tinderbox with
 frontend support. I think its time to move it to a offcial project.  
 The Proof-Of-Concept (poc) is almost ready, but it still have alot of the
 frontend left to do.   You can see the logs and summit bugsreports and
 chose what to build. The poc is runing on a 64core box with help of ganeti
 to manges the virtual machines (vm). I have 4 vm's runing for now but I will
 add 4 more later. I'm building the vm's with help of 
 ganeti-instance-gentoobootstrap.  The vm's query the db for what to build.
 Db is update with tree info and list to builds for the vm's. The vm's are 
 runing python code that call portage api to build the packages in the list.  
 The frontend is just django.
 
 Featuers
 -Support multiplay repos
 -Support any arch there the python code can run.
 -Attach the build logs.
 -Use the db to store the repex for log search.
 
 /Magnus G.
 
 

Thanks a lot :)

Re: [gentoo-dev] Last rites: app-emulation/emul-linux-x86*

2015-03-29 Thread James Le Cuirot

On Sun, 29 Mar 2015 12:13:32 +0200
Pacho Ramos pa...@gentoo.org wrote:

  app-emulation/emul-linux-x86-jna-20140508-r1  
 
 Why do we need to keep app-emulation/emul-linux-x86-jna-20140508-r1 to
 simply end up rdepending on
 =virtual/libffi-3.0.13-r1[abi_x86_32(-)] ? Also, no package in the
 tree rdepends on this emul set and, then,
 packages outside portage could simply rdepend on libffi directly
 instead of needing to keep this

Michał, as already discussed with Pacho [1], emul-linux-x86-jna can just
go away entirely. Nothing requires it and it doesn't make any sense
without emul-linux-x86-java though I note that isn't in the list either;
I thought it would be. Java herd is struggling with the regular VM
packages enough as it is, we could really do without supporting this
one as well. I very much doubt that end users need it any more. Any
objections to removing it?

[1] https://bugs.gentoo.org/show_bug.cgi?id=474464#c5

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpoHyxHdr55C.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Current Gentoo Git setup / man-in-the-middle attacks

2015-03-29 Thread Hanno Böck

On Sun, 29 Mar 2015 23:35:54 +0600
Vadim A. Misbakh-Soloviov m...@mva.name wrote:

 Despite of all you're talking about is right from paranoid point of
 view, I'd, anyway, say DO NOT DO THAT, because you propose to
 revoke the right of choice from the users.

A right of choice from the user only makes sense if there is a
reasonable choice.

Just to take this to the extreme: Should we add a heartbleed-enabled
version of openssl back to the portage tree? It's the choice of the
user if they want to have heartbleed enabled, right?

If there is no disadvantage for the more secure protocols then there is
no need for a choice.

 Moreover, there are some times where it is impossible to fetch
 sources via secure way, but you need it right here and right now.

This has been said before, also in the thread about the webpage. Can
you say what times that would be?
Basically these days it's not possible to use the mainstream internet
without https (you can't search google or log into facebook without
https).
I'd really like to hear of any real world situation where this is an
issue.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpQ0bCBb3afe.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs

2015-03-29 Thread Matt Turner

On Sun, Mar 29, 2015 at 11:58 AM, Matthias Schwarzott z...@gentoo.org wrote:
 Hi there!

 I updated my ~amd64 system recently to new hardware (Intel Core i3-4160).
 Since then valgrind did no longer work for 32bit programs because
 -march=native did choose instructions that valgrind does not support
 in 32bit mode (even ld.so was unusable).

 After some research I put this into make.conf and now it works:
 CFLAGS_x86=${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2
 CXXFLAGS_x86=${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2

 Is this the best solution to the problem?
 If yes, the valgrind ebuild could suggest something like this.
 Either always show it or check cpu-flags first (is this maintainable?).

Valgrind's policy is that they don't implement new instruction sets in 32-bit.

Doing what you've done is the only option I'm aware of, short of
implementing support in valgrind for these instructions.

Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs

2015-03-29 Thread Matthias Schwarzott

On 29.03.2015 20:58, Matthias Schwarzott wrote:
 Hi there!
 
 I updated my ~amd64 system recently to new hardware (Intel Core i3-4160).
 Since then valgrind did no longer work for 32bit programs because
 -march=native did choose instructions that valgrind does not support
 in 32bit mode (even ld.so was unusable).
 
 After some research I put this into make.conf and now it works:
 CFLAGS_x86=${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2
 CXXFLAGS_x86=${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2
 
 Is this the best solution to the problem?
 If yes, the valgrind ebuild could suggest something like this.
 Either always show it or check cpu-flags first (is this maintainable?).
 
I should add, that it seems to break for exactly one package: mariadb

# file /usr/lib32/libmysqlclient.so.18.0.0
/usr/lib32/libmysqlclient.so.18.0.0: ELF 64-bit LSB shared object,
x86-64, version 1 (SYSV), dynamically linked, stripped

After commenting the flags again:
# file /usr/lib32/libmysqlclient.so.18.0.0
/usr/lib32/libmysqlclient.so.18.0.0: ELF 32-bit LSB shared object, Intel
80386, version 1 (SYSV), dynamically linked, stripped

Regards
Matthias

Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs

2015-03-29 Thread Anthony G. Basile


On 03/29/15 15:07, Matt Turner wrote:

On Sun, Mar 29, 2015 at 11:58 AM, Matthias Schwarzott z...@gentoo.org wrote:

Hi there!

I updated my ~amd64 system recently to new hardware (Intel Core i3-4160).
Since then valgrind did no longer work for 32bit programs because
-march=native did choose instructions that valgrind does not support
in 32bit mode (even ld.so was unusable).

After some research I put this into make.conf and now it works:
CFLAGS_x86=${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2
CXXFLAGS_x86=${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2

Is this the best solution to the problem?
If yes, the valgrind ebuild could suggest something like this.
Either always show it or check cpu-flags first (is this maintainable?).

Valgrind's policy is that they don't implement new instruction sets in 32-bit.

Doing what you've done is the only option I'm aware of, short of
implementing support in valgrind for these instructions.



This is a known issue.  I could add a pkg_postinst() message, but with 
valgrind, there would be lots of caveats.  Maybe open a bug and we'll 
track the issue in gentoo that way, like the strlen issue and a few 
other valgrind oldies.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] multilib and different CFLAGS for 32 and 64bit ABIs

2015-03-29 Thread Davide Pesavento

On Sun, Mar 29, 2015 at 9:12 PM, Matthias Schwarzott z...@gentoo.org wrote:
 On 29.03.2015 20:58, Matthias Schwarzott wrote:
 Hi there!

 I updated my ~amd64 system recently to new hardware (Intel Core i3-4160).
 Since then valgrind did no longer work for 32bit programs because
 -march=native did choose instructions that valgrind does not support
 in 32bit mode (even ld.so was unusable).

 After some research I put this into make.conf and now it works:
 CFLAGS_x86=${CFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2
 CXXFLAGS_x86=${CXXFLAGS_x86} -mno-avx2 -mno-sse4 -mno-bmi -mno-bmi2

 Is this the best solution to the problem?
 If yes, the valgrind ebuild could suggest something like this.
 Either always show it or check cpu-flags first (is this maintainable?).

 I should add, that it seems to break for exactly one package: mariadb


Not only mariadb, there are other known breakages... see
https://bugs.gentoo.org/show_bug.cgi?id=541616#c5

According to mgorny (Cc'ed):
You are not supposed to touch CFLAGS_x86, ever. That's some magic
stuff that's used in profiles  multilib.eclass.

Regards,
Davide

[gentoo-dev] rfc: add-on files handling improvements

2015-03-29 Thread William Hubbs

All,

I want to start a discussion about our add-on files practice and try to
improve it.

I agree it is reasonable to install bash completions
unconditionally, because bash is part of the base requirement for
Gentoo. However, I do not agree that we should continue installing
add-on files for everything under the sun unconditionally.

I believe, back in the day we started this practice, portage did not
support --newuse or --changed-use, so there was no way to only update
packages that had changed or new use flags. In that situation, I
understand why we installed all of these add-on files unconditionally
and told users to use INSTALL_MASK if they wanted them not to be on
their systems.

However, I feel that we should update our practice now since we have these
features available to us and to our users.

In my previous thread about zsh, it was suggested that I could use the
zsh-completion use flag to control zsh-completion installation, and not
rdepend on zsh. This is now how pybugz is set up.

The suggestion was made because zsh is not common, so let's try to
define what common means to get an idea of when use flags can be used
like this.

I think the most fair/objective way to define whether something is
common is whether or not it is part of the base requirement, like bash,
or whether it is the default provided by a virtual. In either of those
cases, I would say it makes sense to install add-on files that the
program might use unconditionally.

Thoughts?

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-user] Re: This nite's switch to full multilib

2015-03-29 Thread Davide Pesavento

On Sun, Mar 29, 2015 at 8:23 PM, Rich Freeman ri...@gentoo.org wrote:
 I think we really need to either stabilize 4.8.6, or backport
 qtchooser/multilib/etc to the current stable version.


Backporting is not an option. The introduction of multilib support in
qt4 required extensive changes to the eclass (substantial portions of
code were rewritten) and the ebuilds.

Therefore stabilizing 4.8.6-r1 is the way to go. We had surprisingly
few regressions, but the ones that are still unsolved are proving
quite hard to debug. Please help with the blockers of bug #530238.

As usual, at least for me, the problem is the lack of time for gentoo
development, plus the fact that very few people are actively working
on qt{4,5} packaging (kensington, me, and more recently yngwin).

 qt is a pretty significant package to have break with multilib, and
 trying to run qt-5 on a stable system is already a nightmare with the
 qtchooser switch (in my case I ended up abandoning qt5 as I didn't
 need it that badly).


I'm not sure how qt5 is relevant to this discussion.

Thanks,
Davide

Re: [gentoo-dev] Last rites: app-emulation/emul-linux-x86*

2015-03-29 Thread James Le Cuirot

On Sun, 29 Mar 2015 17:49:50 +0200
Michał Górny mgo...@gentoo.org wrote:

  Michał, as already discussed with Pacho [1], emul-linux-x86-jna can
  just go away entirely. Nothing requires it and it doesn't make any
  sense without emul-linux-x86-java though I note that isn't in the
  list either; I thought it would be. Java herd is struggling with
  the regular VM packages enough as it is, we could really do without
  supporting this one as well. I very much doubt that end users need
  it any more. Any objections to removing it?
  
  [1] https://bugs.gentoo.org/show_bug.cgi?id=474464#c5  
 
 I don't really want to touch Java stuff, so I'd prefer if you handled
 that yourself. That said, feel free to add it to the same p.mask
 entry. Just make sure not to break the dependency graph :).

Okay. It'll also mean killing off sun-j2me-bin and proguard, which we
seem to be cool with (very dead), and getting novell-groupwise-client to
always use the bundled JRE. I need dilfridge's input on the latter.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgprcZKTnT0wB.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: add-on files handling improvements

2015-03-29 Thread Matthias Maier


 Thoughts?

One point in favor of the current practice (installing add-on files
unconditionally) is the fact that you can basically do it for free - you
neither have to depend on additional packages, nor is the presence of
the add-on files a penalty in download time or storage.

Further, a lot of packages install _small_ additional files
unconditionally - let it be examples, minimal documentation, example
configurations - unconditionally. And this is done with the very same
reasoning as above; the penalty is small enough to not warrant the
introduction of a use flag.

Personally, I would not introduce yet another set of global use flags
just for the sake of controlling everything with use flags. The
complexity this introduces (naming choice - enforcing the rule -
ensuring uniformity) is worse than the current behavior of just
installing small add-on files.

Best,
Matthias


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-user] Re: This nite's switch to full multilib

On Sun, Mar 29, 2015 at 5:56 PM, Davide Pesavento p...@gentoo.org wrote:
 On Sun, Mar 29, 2015 at 8:23 PM, Rich Freeman ri...@gentoo.org wrote:

 qt is a pretty significant package to have break with multilib, and
 trying to run qt-5 on a stable system is already a nightmare with the
 qtchooser switch (in my case I ended up abandoning qt5 as I didn't
 need it that badly).

 I'm not sure how qt5 is relevant to this discussion.


As I understand it, qt5 cannot be installed side-by-side with the
current stable qt4, but it can be installed side-by-side with 4.8.6.
My understanding is that this is the result of the same overall
ebuild/eclass changes.  Therefore, it is another reason to stabilize
4.8.6.  You are correct that it has nothing to do with the multilib
changes otherwise.

-- 
Rich

Re: [gentoo-dev] rfc: add-on files handling improvements

2015-03-29 Thread William Hubbs

On Mon, Mar 30, 2015 at 12:11:34AM +0200, Matthias Maier wrote:
 
  Thoughts?
 
 One point in favor of the current practice (installing add-on files
 unconditionally) is the fact that you can basically do it for free - you
 neither have to depend on additional packages, nor is the presence of
 the add-on files a penalty in download time or storage.

The add-on files i'm talking about are not specifically used by the
packages that install them. They are add-ons that hook the packages into
external functions, such as shell completions, logrotate files, xinetd
configurations, etc.

The penalty is cruft on the users's systems when they don't use the
programs that read these files, such as app-admin/logrotate,
sys-apps/xinetd, etc.

All I'm saying is if the application that processes these small
files is not installed, I don't think the files should be either, unless
the upstream build system forces it; I guess we shouldn't try to do
anything about that.

 Further, a lot of packages install _small_ additional files
 unconditionally - let it be examples, minimal documentation, example
 configurations - unconditionally. And this is done with the very same
 reasoning as above; the penalty is small enough to not warrant the
 introduction of a use flag.
 
 The small files I'm talking about, technically, aren't used by the
 package that installs them; they are used by another package, which may
 or may not be installed, independently from the package that installs
 the small files.

 Personally, I would not introduce yet another set of global use flags
 just for the sake of controlling everything with use flags. The
 complexity this introduces (naming choice - enforcing the rule -
 ensuring uniformity) is worse than the current behavior of just
 installing small add-on files.

Actually I'm not talking about introducing more use flags; the flags I'm
interested in adding this functionality to are already there.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] rfc: add-on files handling improvements

On Sun, Mar 29, 2015 at 7:28 PM, William Hubbs willi...@gentoo.org wrote:
 On Mon, Mar 30, 2015 at 12:11:34AM +0200, Matthias Maier wrote:

  Thoughts?

 One point in favor of the current practice (installing add-on files
 unconditionally) is the fact that you can basically do it for free - you
 neither have to depend on additional packages, nor is the presence of
 the add-on files a penalty in download time or storage.

 The add-on files i'm talking about are not specifically used by the
 packages that install them. They are add-ons that hook the packages into
 external functions, such as shell completions, logrotate files, xinetd
 configurations, etc.

 The penalty is cruft on the users's systems when they don't use the
 programs that read these files, such as app-admin/logrotate,
 sys-apps/xinetd, etc.

The problem is that if you don't install this stuff up-front you end
up rebuilding half your system to install it later.

I think the cleanest solution is to just install this stuff
unconditionally, and users who really object to having it around can
use INSTALL_MASK.  It is just a couple of inodes, on a distro that by
default sticks a dozen inodes for every package in the repository on
their root partition.

You suggested that the past policy was due to the lack of
--changed-use in portage at the time, but this is not the case.  That
option has been around for a very long time.  Maybe if it first came
up for manpages or docs that might have been the case, but certainly
not in more recent cases.

Not everybody uses logrotate, xinetd, cron.d, and so on.  It still
makes sense to just install the files, since they passively sit there
doing nothing in those cases.


-- 
Rich

Re: [gentoo-dev] Review: Apache AddHandler news item