date:20130115

On Tue, Jan 15, 2013 at 5:25 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote:

 I still ascert that apps adding groups with NOPASSWD sudoers lines
 perhaps even commented out by default in all or some cases is far
 better than polkit for many reasons. Any counter argument can apply
 to sudo too and rather easily.


I think you need to consider the use case for polkit and such.  I
believe they were focused on linux on the desktop.  Imagine you have
10,000 users running linux on the desktop.  Anybody can log into any
PC.  Do you want anybody to be able to remote login to any PC and
access the webcam and audio, or access local USB drives and such
(which do not have POSIX security applied to their filesystems)?
Unless sudo has some config setting that allows access only when
logged in via console it isn't really a solution.

Rich

Re: [gentoo-dev] January stabilization candidates

2013-01-15 Thread Sergey Popov

13.01.2013 02:49, Paweł Hajdan, Jr. wrote:
 Please review attached automatically generated stabilization candidates
 for January.

 # pinkbyte 
 app-shells/ccsh-0.0.4-r3
 app-shells/rrs-1.70-r1
 dev-libs/jthread-1.3.1

Ok for them

 # netmon 
 dev-libs/geoip-1.4.8-r2

Ok for it

And thanks for your work.

-- 
Best regards, Sergey Popov
Gentoo Linux Developer
Desktop-effects project lead



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Chromium system ffmpeg

Hi,

On Mon, 14 Jan 2013 20:34:42 -0800
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:

 I'm trying to make Chromium be more compatible with more versions of
 ffmpeg:
 https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion
 (although not stated there, that includes libav).

I've done quite a lot of work for various packages among the past years
on that side, so if you have specific questions, feel free to ask.

 Now the initial response there is not enthusiastic (which doesn't
 surprise me), but do you think there are some points useful for the
 discussion I'm not aware of?

I don't get what is the problem: chromium uses an internal version
corresponding to ffmpeg git master and doesn't build with older ones?
What is the min. version it works with?
As a distro we have two options:
1) patch chromium to add #if's for older ffmpeg versions and be
compatible: this may or may not be accepted by upstream, supporting
older versions is just garbage code for them.
2) (preferred) coordinate the other packages to be compatible with
newer versions and unmask latest (we should be very close to be able to
unmask ffmpeg-1) and make chromium require this version (this require
chromium upstream to figure out what is the min. req. version)

we should probably do something in-between 1 and 2 in order not to hold
off sec. stabilizations of chromium because dozens of stable packages
do not build with latest ffmpeg.


 What are the main challenges of keeping up-to-date with latest ffmpeg
 API changes? How do other projects deal with that?

Specify a min. supported version, use #if for what remains.
It may be easy or quite a lot of work, depending on what part of the
API is used. ATM, being compatible with ffmpeg 0.10 up to git master
isn't _that_ heavy on #if's (see eg:
http://dev.gentoo.org/~aballier/distfiles/xbmc-11.0-ffmpeg-1.0-compat-1.tar.bz2
) but may require a lot of changes.
Usually, if you build with the latest ffmpeg release and don't see any
deprecation warning, you are safe for ~1 year or more.

IMHO a compatibility layer like you suggest on your link will be a
pain, #if's are easier to handle.

Alexis.

Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14/01/13 09:48 PM, William Hubbs wrote:
 On Tue, Jan 15, 2013 at 01:25:01AM +0100, Peter Stuge wrote:
 William Hubbs wrote:
 I have a bug opened with the docs team and release engineering 
 to discuss whether we want the new names for new installs.
 
 IMO yes we do.
 
 What's that bug - or what is the good way to thumbs up/down?
 
 https://bugs.gentoo.org/show_bug.cgi?id=451950
 
 The focus of this bug really is how to document the new names in
 the handbook if they decide to go that way. The problem we will
 have is we don't know the names of the interfaces a user will see.
 

That's easy enough to deal with -- list a code block that says what
command to use to find out the iface names, and show an example of the
output.

For that matter, if udev-197 goes stable it'll be included on the
livecd, right?  So a user's interface on the livecd will already be
set to the new naming scheme.

***OH***, that'll mean the livecd's config (or at least the openrc
oldnet portion) is going to need some work

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1Ww0ACgkQ2ugaI38ACPB/sAEAlr+wzX5X7jEsY2KkbC9hylu7
IAIyoZkbtl0A5Z+68A8BALXbRZyv+PZg1eqmWr0DNXfmdwVidOq0RISOxBt0sK7W
=mTAM
-END PGP SIGNATURE-

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/01/13 02:20 AM, Michael Weber wrote:
 Hi folks,
 
 this commit changes the set of USE flags on the just stabled
 gcc-4.6, running a huge number into an rebuild of an freshly
 updated package. (emerge --newuse recaclulates from go disabled
 to go missing)
 
 Wouldn't it be possible to a) refrain from this change (really, who
 has USE=go turned on?) b) handle this with package.use.mask, c)
 figure it out before stabilization
 
 I see the point in nobody beeing perfect, but these recurring 
 effect-less rebuilds of widespread base packages set me up.
 
 Imho, editing /var/db/pkg/sys-devel/gcc-4.6.3/USE is not a recipe
 to be carried out to the user. But can we do stuff like this in
 profile updates? Without hurting system with USE=go activated,
 which need actually need the recompile.
 
 my 2 cents
 
 Michael
 

  emerge -uD --reinstall=changed-use @world  

This skips rebuilds for packages that receive new use flags or have
use flags removed but were already disabled.  Unfortunately it's not
as convenient to type as -uDN , but it does keep your system updated
while skipping spurious/unnecessary rebuilds.

[tangent]
I wonder if it might be pertinent for future portage's to install an
alias command, emerge-system-update or similar, that would wrap the
standardly accepted emerge update command more or less everyone
already runs..  easier end-user experience as they don't need to
learn/remember all the little fiddly options, plus portage dev's can
control the default (probably we make it over-ridable via a make.conf
var or something) so that if things change with newer EAPIs or portage
features the default flags can be adjusted too...
[/tangent]

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1XUwACgkQ2ugaI38ACPA0WQD/RPIat2/eR6x2qRblQsc5xyVs
IhOj7bQdrM5Uou/Zn1cBAKnsBMYRlw4ZVhqOT7/4XCOl824dFp543jAO+hJeuErm
=zVJr
-END PGP SIGNATURE-

Re: [gentoo-dev] call for testers: udev predictable network interface names

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/01/13 04:16 AM, Michael Weber wrote:
 Hi,
 
 This can have serious security implications [1]
 
 For whom?

I think the idea there is that a user expects eth0 and eth1 to stay
the same, writes iptables rules on a per-interface basis to control
what they want, then update the kernel or make some other change
(upgraded udev, maybe? :D) which swaps them around and poof, the rules
they thought were correct don't end up protecting them they way they
assumed it would...

Not saying this is necessarily valid, just saying how I interpreted
their meaning of serious security implications.



 [about NIC names] ... Opt-out urges users into either adapt their
 setups or disable the rules.

Unless i'm mistaken (and i haven't done any sort of comprehensive
search so I could be), I believe the majority of package rollouts for
systemd-udev is going to provide an opt-in rather than an opt-out.  I
understand the general point here, that systemd-udev upstream perhaps
should also be defaulting to an opt-in, but there isn't a whole lot of
benefit in making that point on the gentoo ML.. :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1YKMACgkQ2ugaI38ACPA8OgEAtK1Y3vHB3oBQyAdmZHYFZcBW
4g9ry2YFts41Zu1wuXcA/REe9lunWnLQ9w4uZNxvFnZ0LqEK9lMrOP0pJEr3UHAq
=06X2
-END PGP SIGNATURE-

Re: [gentoo-dev] call for testers: udev predictable network interface names

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/01/13 03:42 AM, Michael Weber wrote:
 
 e) Some distro/driver constellations (archlinux?) tend to name
 their wireless lan eth*. [...] e) never happened to me.

It has for me, but not for a *LONG* time -- iirc it was prior to
2.6.16 and I think it was with an (externally compiled) ipw2100
driver.  Neither of which are supported now in general, and certainly
not with a current udev.

I think (e) has been sorted out long ago in the kernel.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1YbYACgkQ2ugaI38ACPC1vQEArVONIEOlLPrvd4PV7NnXszOg
AOTxveWpT5drCAV681sA/1WuQwKaqnvfoZReEedNk6Uthedp8dSSIVyvsYaEj0Ud
=0Hnr
-END PGP SIGNATURE-

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

On Tue, Jan 15, 2013 at 8:44 AM, Ian Stakenvicius a...@gentoo.org wrote:
 I wonder if it might be pertinent for future portage's to install an
 alias command, emerge-system-update or similar, that would wrap the
 standardly accepted emerge update command more or less everyone
 already runs..  easier end-user experience as they don't need to
 learn/remember all the little fiddly options, plus portage dev's can
 control the default (probably we make it over-ridable via a make.conf
 var or something) so that if things change with newer EAPIs or portage
 features the default flags can be adjusted too...

I'm fairly confident that this was already discussed a while back, and
generally had positive feedback.

I'd make it easy-to-remember though - either a one-letter option, or
something short.

To avoid rehashing the same arguments over again a few things to note:
1.  The settings would be reasonably conservative - intended for
newbies and such and unlikely to break things.
2.  We would not re-use any existing parameter - no changes in behavior/etc.
3.  Users could still throw alphabet soup at portage if they already
know the one-true-way (TM).
4.  Script writers would be warned up-front that the behavior of this
feature would be subject to change without much notice.

Is there any reason that this can't just be done?  It would only be an
alias, so it shouldn't really require development per-se.

Some open questions:
1.  What is the correct use-flag behavior - -N, or --reinstall=changed-use?
2.  What is the correct --with-bdeps behavior?
3.  What is the correct --deep behavior?

Now let the bikeshedding commence...

Rich

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

On Tue, Jan 15, 2013 at 3:03 PM, Rich Freeman ri...@gentoo.org wrote:
 I'd make it easy-to-remember though - either a one-letter option, or
 something short.

+1. Maybe just -U?

 Some open questions:
 1.  What is the correct use-flag behavior - -N, or --reinstall=changed-use?
 2.  What is the correct --with-bdeps behavior?
 3.  What is the correct --deep behavior?

Seems to me that emerge -U should equal emerge -D --reinstall=changed-use.

Cheers,

Dirkjan

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/01/13 09:16 AM, Dirkjan Ochtman wrote:
 On Tue, Jan 15, 2013 at 3:03 PM, Rich Freeman ri...@gentoo.org
 wrote:
 I'd make it easy-to-remember though - either a one-letter option,
 or something short.
 
 +1. Maybe just -U?
 
 Some open questions: 1.  What is the correct use-flag behavior -
 -N, or --reinstall=changed-use? 2.  What is the correct
 --with-bdeps behavior? 3.  What is the correct --deep behavior?
 
 Seems to me that emerge -U should equal emerge -D
 --reinstall=changed-use.
 
 Cheers,
 
 Dirkjan
 

Bikeshedding, but I'm thinking that it would be better to provide a
whole separate command for this rather than a quicker convenience
option -- the command would, for instance, also include @world as the
target by default.  As for the options, i'd recommend adding --ask and
- --verbose

The advantage I see for it being an extra command is that it's a clear
one-purpose convenience command; while if we use the '-U' option
there'll be others that will probably add additional modifier options
and possibly also use it against targets other than @world; i'm not
sure if we'd want people to do that by default..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1Z18ACgkQ2ugaI38ACPCNLQEAvi05mWKPbFZ0gi7yhSKieSY/
KA+THvQYTFSKDxyUTCUBAINfve059rg6IcGdBWc+HcGlRtny0T3miIM5mLER26br
=E0zR
-END PGP SIGNATURE-

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

On Tue, Jan 15, 2013 at 3:27 PM, Ian Stakenvicius a...@gentoo.org wrote:
 Bikeshedding, but I'm thinking that it would be better to provide a
 whole separate command for this rather than a quicker convenience
 option -- the command would, for instance, also include @world as the
 target by default.  As for the options, i'd recommend adding --ask and
 - --verbose

 The advantage I see for it being an extra command is that it's a clear
 one-purpose convenience command; while if we use the '-U' option
 there'll be others that will probably add additional modifier options
 and possibly also use it against targets other than @world; i'm not
 sure if we'd want people to do that by default..

Yeah, but this is another command to remember. Since the purpose is
quite similar to other emerge actions, I think it should just be
provided by emerge (and documented clearly up top in man emerge and
emerge -h).

I was rather wondering about the other direction: include --deep and
--reinstall=changed-use in an --update action. This would actually
make more sense to me; I think those options still make sense for
single-package or other-set emerges?

I don't mind adding --ask and --verbose, but I think they should be
orthogonal. Some of this I guess depends on it being a separate
command. I think the better solution is to just provide a clear path
to upgrades, i.e. an -u/--update action with better defaults (even if
the backwards compatibility might be a little crappy -- might deserve
a news item).

BTW, what happened with -u? I still use it because I'm used to it, but
it seems to have gone away (i.e. I can't find it in the current man
page).

Cheers,

Dirkjan

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/01/13 09:39 AM, Dirkjan Ochtman wrote:
 
 BTW, what happened with -u? I still use it because I'm used to it,
 but it seems to have gone away (i.e. I can't find it in the current
 man page).

It's there:

 --update (-u)
  Updates packages to the best version available, ...

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1bH0ACgkQ2ugaI38ACPBl0AD/UF5lj7K1R65TWOcaaCf1NG41
dTPmGfvb6VldF4Fe+jUA/0uuZj1q51lYaylBQEP8TOrg8dZVlTLUsN02Fyr8S0g8
=qLlJ
-END PGP SIGNATURE-

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/01/13 09:39 AM, Dirkjan Ochtman wrote:
 On Tue, Jan 15, 2013 at 3:27 PM, Ian Stakenvicius a...@gentoo.org
 wrote:
 Bikeshedding, but I'm thinking that it would be better to provide
 a whole separate command for this rather than a quicker
 convenience option -- the command would, for instance, also
 include @world as the target by default.  As for the options, i'd
 recommend adding --ask and - --verbose
 
 The advantage I see for it being an extra command is that it's a
 clear one-purpose convenience command; while if we use the '-U'
 option there'll be others that will probably add additional
 modifier options and possibly also use it against targets other
 than @world; i'm not sure if we'd want people to do that by
 default..
 
 Yeah, but this is another command to remember. Since the purpose
 is quite similar to other emerge actions, I think it should just
 be provided by emerge (and documented clearly up top in man emerge
 and emerge -h).
 
 I was rather wondering about the other direction: include --deep
 and --reinstall=changed-use in an --update action. This would
 actually make more sense to me; I think those options still make
 sense for single-package or other-set emerges?
 
 I don't mind adding --ask and --verbose, but I think they should
 be orthogonal. Some of this I guess depends on it being a separate 
 command. I think the better solution is to just provide a clear
 path to upgrades, i.e. an -u/--update action with better defaults
 (even if the backwards compatibility might be a little crappy --
 might deserve a news item).
 


I don't know about changing default -u behaviour...  I still use
'emerge -u [package]' for instance if I want to upgrade just one
package.  I'd rather not have to negate the --deep and
- --reinstall=changed-use  (well, the --deep, anyhow) when i do this.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1bVsACgkQ2ugaI38ACPDRsAD/abiZ2hMlUXfoGAbsxM8E2e+0
P364P8o+QjcP6pN/xccA/iq//d3FqpcvllLlxWg9yLto2YgR8z4T2imjEDWurdki
=orNG
-END PGP SIGNATURE-

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

On Tue, Jan 15, 2013 at 9:39 AM, Dirkjan Ochtman d...@gentoo.org wrote:
 On Tue, Jan 15, 2013 at 3:27 PM, Ian Stakenvicius a...@gentoo.org wrote:
 Bikeshedding, but I'm thinking that it would be better to provide a
 whole separate command for this rather than a quicker convenience
 option -- the command would, for instance, also include @world as the
 target by default.  As for the options, i'd recommend adding --ask and
 - --verbose

++ to including @world and --ask / --verbose.  We really want a simple
command that does it all with fairly conservative settings.

Anybody who runs debian knows that the only two commands you really
need to know are apt-get --update and apt-get --upgrade.  We really
need to keep things just that simple.  apt-get prompts if the install
pulls in extra dependencies, and is fairly verbose.

I don't really care if it is a separate command or built-into emerge.
One thing the command probably should do is echo the full command
expansion.  Then users know exactly what is going on under the hood,
and if they need to tweak the command they can just do a copy-paste or
define their own alias.


 The advantage I see for it being an extra command is that it's a clear
 one-purpose convenience command;

 Yeah, but this is another command to remember.

I'm not sure I agree here - for the typical Gentoo user it might be
the only command to remember.

 I was rather wondering about the other direction: include --deep and
 --reinstall=changed-use in an --update action. This would actually
 make more sense to me; I think those options still make sense for
 single-package or other-set emerges?

I'm not keen on redefining existing options.  That is going to lead to
a bazillion complaints about broken scripts, and sometimes you really
do just want to do a partial resolution.


 I don't mind adding --ask and --verbose, but I think they should be
 orthogonal.

For the one-size-fits-all default command, I think they should be
defaults.  By all means have --quiet and --non-interactive or
whatever, but I think the default should be ask and verbose.  Keep in
mind this is the command that newbies will run.  It doesn't mean that
any existing options will be disabled.

The goal is that the Gentoo handbook will introduce new users to
maintaining their systems by giving them a single command that they
should run daily, or whatever.  It should nearly guarantee that users
will not run into valid bugs, and if for some reason the upgrade path
on some package requires deviation from this command it should be
considered as a news item.

The side goal is to get rid of unnecessary diversity.  I'm fine with
users doing things differently because they have different needs and
we should of course support this.  However, I think too often every
Gentoo box ends up being maintained completely differently just
because we're so wishy-washy with the defaults.  We shouldn't be
afraid of declaring a reasonable default, and then just letting
individuals change it.

Rich

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

2013-01-15 Thread Alec Warner

On Tue, Jan 15, 2013 at 3:00 AM, Rich Freeman ri...@gentoo.org wrote:
 On Tue, Jan 15, 2013 at 5:25 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote:

 I still ascert that apps adding groups with NOPASSWD sudoers lines
 perhaps even commented out by default in all or some cases is far
 better than polkit for many reasons. Any counter argument can apply
 to sudo too and rather easily.


 I think you need to consider the use case for polkit and such.  I
 believe they were focused on linux on the desktop.  Imagine you have
 10,000 users running linux on the desktop.  Anybody can log into any
 PC.  Do you want anybody to be able to remote login to any PC and
 access the webcam and audio, or access local USB drives and such
 (which do not have POSIX security applied to their filesystems)?
 Unless sudo has some config setting that allows access only when
 logged in via console it isn't really a solution.

 Rich


I manage 'thousands' of desktops at Google and we generally like
polkit. It is however, designed for graphical UI single-seat systems.
Its command line support sucks (they only added a CLI auth agent in
May) and it is not well adopted. Multi-user systems do not work well
with polkit. Certainly with polkit and dbus you can allow users to
take more specific action without complex wrappers, setuid scripts, or
sudo. My package manager can have a polkit action like 'install a
signed package' and I can grant the user access to do that, but not
access to install unsigned packages (root exploit there...) or run
other dangerous apt commands. It comes built into apt, so I don't have
to write extra wrappers.

I don't recommend letting anyone log into any desktop, from a security
policy POV :)

-A

Re: [gentoo-dev] [PATCH] Support MULTILIB_USEDEP for writing USE-deps.

On Tue, 15 Jan 2013 08:31:46 +0100
Michał Górny mgo...@gentoo.org wrote:

 Although the eclass does 'multilib?' only now, in the future it is
 likely to use more fine-tuned ABI flags.
 ---
  gx86/eclass/autotools-multilib.eclass | 12 

I think it'd better fit in a more generic eclass like multilib.eclass

A.

Re: [gentoo-dev] [PATCH] Support MULTILIB_USEDEP for writing USE-deps.

2013-01-15 Thread Michał Górny

On Tue, 15 Jan 2013 14:19:36 -0300
Alexis Ballier aball...@gentoo.org wrote:

 On Tue, 15 Jan 2013 08:31:46 +0100
 Michał Górny mgo...@gentoo.org wrote:
 
  Although the eclass does 'multilib?' only now, in the future it is
  likely to use more fine-tuned ABI flags.
  ---
   gx86/eclass/autotools-multilib.eclass | 12 
 
 I think it'd better fit in a more generic eclass like multilib.eclass

Yes, I was thinking about that. Probably would be easy to move
the relevant functions into it.

The name remains the question -- multilib-utils? :D

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] Support MULTILIB_USEDEP for writing USE-deps.

On Tue, 15 Jan 2013 18:25:16 +0100
Michał Górny mgo...@gentoo.org wrote:

 On Tue, 15 Jan 2013 14:19:36 -0300
 Alexis Ballier aball...@gentoo.org wrote:
 
  On Tue, 15 Jan 2013 08:31:46 +0100
  Michał Górny mgo...@gentoo.org wrote:
  
   Although the eclass does 'multilib?' only now, in the future it is
   likely to use more fine-tuned ABI flags.
   ---
gx86/eclass/autotools-multilib.eclass | 12 
  
  I think it'd better fit in a more generic eclass like
  multilib.eclass
 
 Yes, I was thinking about that. Probably would be easy to move
 the relevant functions into it.
 
 The name remains the question -- multilib-utils? :D

I'd say multilib.eclass; it probably doesn't deserve a new eclass, and
multilib.eclass is already what could be called multilib-utils.eclass :)

A.

Re: [gentoo-dev] [PATCH] Support MULTILIB_USEDEP for writing USE-deps.

2013-01-15 Thread Michał Górny

On Tue, 15 Jan 2013 14:42:27 -0300
Alexis Ballier aball...@gentoo.org wrote:

 On Tue, 15 Jan 2013 18:25:16 +0100
 Michał Górny mgo...@gentoo.org wrote:
 
  On Tue, 15 Jan 2013 14:19:36 -0300
  Alexis Ballier aball...@gentoo.org wrote:
  
   On Tue, 15 Jan 2013 08:31:46 +0100
   Michał Górny mgo...@gentoo.org wrote:
   
Although the eclass does 'multilib?' only now, in the future it is
likely to use more fine-tuned ABI flags.
---
 gx86/eclass/autotools-multilib.eclass | 12 
   
   I think it'd better fit in a more generic eclass like
   multilib.eclass
  
  Yes, I was thinking about that. Probably would be easy to move
  the relevant functions into it.
  
  The name remains the question -- multilib-utils? :D
 
 I'd say multilib.eclass; it probably doesn't deserve a new eclass, and
 multilib.eclass is already what could be called multilib-utils.eclass :)

But that variable requires IUSE... and adding IUSE to multilib.eclass
seems like a bad idea to me.

I was saying 'multilib-utils' as with the common mistake started with
'cmake-utils', and then forked as 'autotools-utils' (because
'autotools' was taken, I guess).

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] January stabilization candidates

2013-01-15 Thread Robin H. Johnson

On Sat, Jan 12, 2013 at 02:49:52PM -0800, Paweł Hajdan, Jr. wrote:
 # robbat2 
 app-admin/diradm-2.9.7.1
+1
 # robbat2 
 app-shells/localshell-1.3.4
+1
 # netmon 
 dev-libs/geoip-1.4.8-r2
+0.5 looking for another vote
 # base-system 
 sys-apps/irqbalance-1.0.5
+1
 # base-system 
 sys-apps/sg3_utils-1.34
+1
 # base-system 
 sys-block/aoetools-35
+0.5
 # sysadmin 
 sys-libs/freeipmi-1.2.3-r1
+0.5

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee  Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] January stabilization candidates

2013-01-15 Thread Diego Elio Pettenò

On 15/01/2013 20:05, Robin H. Johnson wrote:
  sys-libs/freeipmi-1.2.3-r1
 +0.5

I'd really prefer to see 1.2.2 or 1.2.3 stable first, given the history
with FreeIPMI, I don't aim for too many stable candidates...

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.

2013-01-15 Thread Mike Frysinger

On Monday 14 January 2013 22:20:20 Duncan wrote:
 Mike Frysinger posted on Mon, 14 Jan 2013 17:09:51 -0500 as excerpted:
  + [[ ${BUILD_DIR} ]] || die ${FUNCNAME}: BUILD_DIR not set.
  
  really should use -n there
  
  Doesn't matter.
  
  the point wasn't will it work.  it's more how easy is it to glance at
  code and know what it is doing.
 
 Indeed.  But arguably standalone [[ ${var} ]] tests ARE easier to know
 what it doing.
 
 1) The [[ $var ]] case is exactly one of one.  There's no misinterpreting
 it.  Even if you don't know the rule by rote, given that it's a boolean
 test on a string, there's logically only one way to parse it.  No
 mistakes to make.

not really.  when you see [[ ${var} ]], which did the dev actually mean to do:
if ( ${var} ) ; then
if ${var} ; then
if [[ -n ${var} ]] ; then

if i see the -n, i'm pretty confident they meant to do a string test.  if i 
don't, then i need to read the rest of the code to figure out the meaning  use 
of ${var} to see if they screwed up.

and yes, this still happens.  i've seen fixes in the last month along these 
lines.

 2) By contrast, -n is only one of a whole list of -X style tests, and one
 must stop and think, Let's see... Oh, yes, -n was non-null.

i don't buy that.  -z and -n are the most common `test` tests out there.  if 
you can't handle that, then you probably can't handle a lot of the 
ebuilds/eclasses.

 4) You are arguing the at a glance position, but didn't even MENTION
 the needlessly negated logic of [[ -n $string ]] || ... , which could be
 rewritten to avoid the || negation as [[ -z $string ]]  ...

that depends on the code.  there is no correct answer here.

 5) [[ ]] is already a bashism while the standalone string test is common
 shell.  Surely you're not arguing that people familiar enough with the
 [[ ]] || construct to parse it at a glance can't equally capably parse
 the a standalone string test, given its use in non-bash shell context as
 well.

bashisms are irrelevant.  we already stated the whole tree is bash.
-mike


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

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

2013-01-15 Thread Kevin Chadwick

Unless sudo has some config setting that allows access only when
logged in via console it isn't really a solution.

Rich

man sudoers - /requiretty

I manage 'thousands' of desktops at Google and we generally like
polkit.

I never meant it is rubbish as such but I saw it as rediculously
inferior to sudo before I even read this.

http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/

It is however, designed for graphical UI single-seat systems.
Its command line support sucks (they only added a CLI auth agent in
May) and it is not well adopted. Multi-user systems do not work well
with polkit. Certainly with polkit and dbus you can allow users to
take more specific action without complex wrappers, setuid scripts, or
sudo.

Except you can't, it only encourages more coarse grained approaches,
less useful commands available and devs to learn an api rather than C
and simply moves code into a far less secure mechanism and increases the
chance that the code will not be well designed to the task at hand and
running as root. It can be a real pain to work out exactly what polkit
allows and you cannot just edit it to suit your application and it
completely ignores the existing unix security technologies with
brilliant track records.

You could try to argue that many eyes will look at a central piece of
code but in fact less implementations will likely mean less eyes and
just assumption that a guy who got JS through as a config language has
everything covered. Granted, unmaintained code running as root may be
higher with sudo but if it needs maintaining, should it be running as
root at all or is it actually simply doing too much.

My package manager can have a polkit action like 'install a
signed package' and I can grant the user access to do that, but not
access to install unsigned packages (root exploit there...) or run
other dangerous apt commands. It comes built into apt, so I don't have
to write extra wrappers.

That would be the default and wouldn't even need the command line
argument control of sudo. Just allowing updates is apt-get update.

In fact I have a debian system where experimental iceweasel is
installable but nothing else. I have an Arch system where the only
kernel updateable is a signed by me when offline kernel and polkit is
disabled as I don't have the time to keep track of what it is
permitting and code comments weren't helpful there.

Sudo even supports regex!

p.s. apt should be downloading as an _apt user, simply as best
practice before adding polkit support ;-)

--
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: [gentoo-dev] January stabilization candidates

2013-01-15 Thread Markos Chandras

On 12 January 2013 22:49, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
 Please review attached automatically generated stabilization candidates
 for January.

 I don't want to annoy people with automatically filed bugs, and at the
 same time I also received lots of positive feedback about the effort to
 keep the stable tree more up-to-date.

 I think the best way to proceed is to listen to that feedback and
 continue the effort, while also keeping an updated list of exclusions
 for packagers/herds that are actively stabilized by maintainers.

 Paweł

ack for the packages I maintain

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] January stabilization candidates

On Sat, Jan 12, 2013 at 11:49 PM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
 I think the best way to proceed is to listen to that feedback and
 continue the effort, while also keeping an updated list of exclusions
 for packagers/herds that are actively stabilized by maintainers.

I filed dev-python/paramiko-1.9.0 myself. :)

Cheers,

Dirkjan

Re: [gentoo-dev] January stabilization candidates

2013-01-15 Thread Panagiotis Christopoulos

On 14:49 Sat 12 Jan , Paweł Hajdan, Jr. wrote:
 Please review attached automatically generated stabilization candidates
 for January.
 
 I don't want to annoy people with automatically filed bugs, and at the
 same time I also received lots of positive feedback about the effort to
 keep the stable tree more up-to-date.
 

I'm just curious, how this actually works. Do you have a script that
checks specific categories/packages for dependencies, open bugs. etc.? 

-- 
Panagiotis Christopoulos ( pchrist )
( Gentoo Lisp Project )


pgpi8aZayF1Fw.pgp
Description: PGP signature

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

2013-01-15 Thread Peter Stuge

Rich Freeman wrote:
 Anybody who runs debian knows that the only two commands you really
 need to know are apt-get --update and apt-get --upgrade.  We really
 need to keep things just that simple.

We're halfway there;

emerge --sync

So how about adding:

emerge --upgrade

?


//Peter

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

2013-01-15 Thread Maxim Kammerer

On Tue, Jan 15, 2013 at 9:43 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote:
 You could try to argue that many eyes will look at a central piece of
 code but in fact less implementations will likely mean less eyes and
 just assumption that a guy who got JS through as a config language has
 everything covered.

Still can't wrap my mind around that. A call into a multi-MB generic
language library (usually with JIT as well) on every PolKit action —
right, a good idea. I kind of liked PolKit before that change.

This is a major problem, there are other questionable choices that
raise the question whether developers are familiar with how things are
done on Unix:
https://bugs.freedesktop.org/show_bug.cgi?id=58787

 Sudo even supports regex!

Only glob patterns, and it's not too good at that.
http://www.sudo.ws/bugs/show_bug.cgi?id=500

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] January stabilization candidates

2013-01-15 Thread Mike Pagano

13.01.2013 02:49, Paweł Hajdan, Jr. wrote:
Please review attached automatically generated stabilizatiocandidates
for January.

 

# mpagano kernel-misc
sys-kernel/linux-docs-3.6.

I'll do this for the just committed version linux-docs-3.6.11. What I will do 
for now on is change our stabilization procedure for kernels to include 
opening up a bug to stabilize the corresponding linux-docs version.

So going forward, you can exclude this and hopefully we'll do a better job of 
keeping this package stable.

-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index

Re: [gentoo-dev] [PATCH] Support MULTILIB_USEDEP for writing USE-deps.

On Tue, 15 Jan 2013 18:56:15 +0100
Michał Górny mgo...@gentoo.org wrote:

 On Tue, 15 Jan 2013 14:42:27 -0300
 Alexis Ballier aball...@gentoo.org wrote:
 
  On Tue, 15 Jan 2013 18:25:16 +0100
  Michał Górny mgo...@gentoo.org wrote:
  
   On Tue, 15 Jan 2013 14:19:36 -0300
   Alexis Ballier aball...@gentoo.org wrote:
   
On Tue, 15 Jan 2013 08:31:46 +0100
Michał Górny mgo...@gentoo.org wrote:

 Although the eclass does 'multilib?' only now, in the future
 it is likely to use more fine-tuned ABI flags.
 ---
  gx86/eclass/autotools-multilib.eclass | 12 

I think it'd better fit in a more generic eclass like
multilib.eclass
   
   Yes, I was thinking about that. Probably would be easy to move
   the relevant functions into it.
   
   The name remains the question -- multilib-utils? :D
  
  I'd say multilib.eclass; it probably doesn't deserve a new eclass,
  and multilib.eclass is already what could be called
  multilib-utils.eclass :)
 
 But that variable requires IUSE... and adding IUSE to multilib.eclass
 seems like a bad idea to me.

yes its a bad idea, but the variable doesnt require IUSE, only its usage
does.

I'd go for something like:

MULTILIB_IUSE=multilib
MULTILIB_USE_DEP=multilib?

and usage of MULTILIB_USE_DEP would imply MULTILIB_IUSE is in IUSE
so that later it can be populated by abi variables instead

A.

Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes

On Tue, Jan 15, 2013 at 9:18 PM, Peter Stuge pe...@stuge.se wrote:
 We're halfway there;

 emerge --sync

 So how about adding:

 emerge --upgrade

 ?

I was thinking the same thing!

Cheers,

Dirkjan

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

2013-01-15 Thread Kevin Chadwick

On Tue, 15 Jan 2013 22:19:37 +0200
Maxim Kammerer m...@dee.su wrote:

 This is a major problem, there are other questionable choices that
 raise the question whether developers are familiar with how things are
 done on Unix:
 https://bugs.freedesktop.org/show_bug.cgi?id=58787
 

I have to confess that despite this being a serious matter that really
made me chuckle.

  Sudo even supports regex!  
 
 Only glob patterns, and it's not too good at that.
 http://www.sudo.ws/bugs/show_bug.cgi?id=500


/etc/sudoers:
anonliberte = NOPASSWD: /sbin/shutdown -[hr] now

sudo shutdown -h now - allowed
sudo shutdown -h now - allowed (probably shouldn't be)

It may not be perfect and is why I would love to see distros grow some
balls or perhaps more rightly packagers and embrace sudoers again but it
is far clearer what is allowed than polkit and I believe.

/sbin/shutdown -[h][r]

Would do what you want. You may need to test but I have never found a
command I couldn't add to sudoers.

After all it can only make the likes of Ubuntu and perhaps all in fact
more secure ;-)

Re: [gentoo-dev] [PATCH] Support MULTILIB_USEDEP for writing USE-deps.

2013-01-15 Thread Michał Górny

On Tue, 15 Jan 2013 17:38:17 -0300
Alexis Ballier aball...@gentoo.org wrote:

 On Tue, 15 Jan 2013 18:56:15 +0100
 Michał Górny mgo...@gentoo.org wrote:
 
  On Tue, 15 Jan 2013 14:42:27 -0300
  Alexis Ballier aball...@gentoo.org wrote:
  
   On Tue, 15 Jan 2013 18:25:16 +0100
   Michał Górny mgo...@gentoo.org wrote:
   
On Tue, 15 Jan 2013 14:19:36 -0300
Alexis Ballier aball...@gentoo.org wrote:

 On Tue, 15 Jan 2013 08:31:46 +0100
 Michał Górny mgo...@gentoo.org wrote:
 
  Although the eclass does 'multilib?' only now, in the future
  it is likely to use more fine-tuned ABI flags.
  ---
   gx86/eclass/autotools-multilib.eclass | 12 
 
 I think it'd better fit in a more generic eclass like
 multilib.eclass

Yes, I was thinking about that. Probably would be easy to move
the relevant functions into it.

The name remains the question -- multilib-utils? :D
   
   I'd say multilib.eclass; it probably doesn't deserve a new eclass,
   and multilib.eclass is already what could be called
   multilib-utils.eclass :)
  
  But that variable requires IUSE... and adding IUSE to multilib.eclass
  seems like a bad idea to me.
 
 yes its a bad idea, but the variable doesnt require IUSE, only its usage
 does.
 
 I'd go for something like:
 
 MULTILIB_IUSE=multilib
 MULTILIB_USE_DEP=multilib?
 
 and usage of MULTILIB_USE_DEP would imply MULTILIB_IUSE is in IUSE
 so that later it can be populated by abi variables instead

I wanted to add the multilib_foreach_abi() there as well, and I think
it really deserves its own eclass. And if it's own eclass where every
func relies on IUSE, no point in hacking it over.

It's just the question of name, I believe. multilib-base?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] packages up for grabs

2013-01-15 Thread Markos Chandras

Hi,

The following packages are up for grabs

app-cdr/daa2iso
app-cdr/gaffitter
app-laptop/prey
app-misc/recoll
app-backup/fsarchiver
media-libs/liblqr
net-news/canto
sys-apps/pyrenamer

I will drop them to maintainer-needed in ~10 days

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] call for testers: udev predictable network interface names

2013-01-15 Thread Greg KH

On Tue, Jan 15, 2013 at 08:58:59AM -0500, Ian Stakenvicius wrote:
 On 15/01/13 04:16 AM, Michael Weber wrote:
  Hi,
  
  This can have serious security implications [1]
  
  For whom?
 
 I think the idea there is that a user expects eth0 and eth1 to stay
 the same, writes iptables rules on a per-interface basis to control
 what they want, then update the kernel or make some other change
 (upgraded udev, maybe? :D) which swaps them around and poof, the rules
 they thought were correct don't end up protecting them they way they
 assumed it would...
 
 Not saying this is necessarily valid, just saying how I interpreted
 their meaning of serious security implications.

Yes, that is true.

And it's not udev that could rename the interface (hint, it wouldn't),
it's the kernel, it _never_ guarantees the same interface name every
time you boot.  You might just be getting lucky, but really, PCI busses
can be enumerated in different ways, USB devices can come and go and
initialize sometimes slower one boot from another, and lots of other
things can happen.

So anyone who relies on network names right now to be deterministic, and
you have more than one network device in your system, should seriously
reconsider how they are naming their devices, as it will not work if you
only rely on the kernel.

You might have gotten lucky for the past 5 years, but you never know
what could happen if you reboot today.  Seriously, I've seen it happen
all the time.

Hope this helps explain things a bit better.

greg k-h

Re: [gentoo-dev] [PATCH] Support MULTILIB_USEDEP for writing USE-deps.

On Tue, 15 Jan 2013 21:47:19 +0100
Michał Górny mgo...@gentoo.org wrote:

 On Tue, 15 Jan 2013 17:38:17 -0300
 Alexis Ballier aball...@gentoo.org wrote:
 
  On Tue, 15 Jan 2013 18:56:15 +0100
  Michał Górny mgo...@gentoo.org wrote:
  
   On Tue, 15 Jan 2013 14:42:27 -0300
   Alexis Ballier aball...@gentoo.org wrote:
   
On Tue, 15 Jan 2013 18:25:16 +0100
Michał Górny mgo...@gentoo.org wrote:

 On Tue, 15 Jan 2013 14:19:36 -0300
 Alexis Ballier aball...@gentoo.org wrote:
 
  On Tue, 15 Jan 2013 08:31:46 +0100
  Michał Górny mgo...@gentoo.org wrote:
  
   Although the eclass does 'multilib?' only now, in the
   future it is likely to use more fine-tuned ABI flags.
   ---
gx86/eclass/autotools-multilib.eclass | 12 
  
  I think it'd better fit in a more generic eclass like
  multilib.eclass
 
 Yes, I was thinking about that. Probably would be easy to move
 the relevant functions into it.
 
 The name remains the question -- multilib-utils? :D

I'd say multilib.eclass; it probably doesn't deserve a new
eclass, and multilib.eclass is already what could be called
multilib-utils.eclass :)
   
   But that variable requires IUSE... and adding IUSE to
   multilib.eclass seems like a bad idea to me.
  
  yes its a bad idea, but the variable doesnt require IUSE, only its
  usage does.
  
  I'd go for something like:
  
  MULTILIB_IUSE=multilib
  MULTILIB_USE_DEP=multilib?
  
  and usage of MULTILIB_USE_DEP would imply MULTILIB_IUSE is in IUSE
  so that later it can be populated by abi variables instead
 
 I wanted to add the multilib_foreach_abi() there as well, and I think
 it really deserves its own eclass. And if it's own eclass where every
 func relies on IUSE, no point in hacking it over.

yep, it sounds sensible if you want to add more 'generic' functions
then, and indeed it's simpler to just set IUSE (not sure if it'd be
wanted in all cases but I can't imagine any)

 It's just the question of name, I believe. multilib-base?

-utils sounds better for utility functions, -base is better if it's
really the building blocks of most multilib packages; since the goal
should be the latter, I'd prefer -base, but then it makes me think
multilib.eclass is higher level than multilib-base, which is in fact the
contrary. Maybe multilib-builds ? multibuilds-base ?

Re: [gentoo-dev] call for testers: udev predictable network interface names