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

[Michał Górny]

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 
 1 file changed, 12 insertions(+)

diff --git a/gx86/eclass/autotools-multilib.eclass 
b/gx86/eclass/autotools-multilib.eclass
index fe6372d..d4e0f77 100644
--- a/gx86/eclass/autotools-multilib.eclass
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -34,6 +34,18 @@ EXPORT_FUNCTIONS src_configure src_compile src_test 
src_install
 
 IUSE=multilib
 
+# @ECLASS-VARIABLE: MULTILIB_USEDEP
+# @DESCRIPTION:
+# The USE-dependency to be used on dependencies (libraries) needing
+# to support multilib as well.
+#
+# Example use:
+# @CODE
+# RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
+#  net-libs/libbar[ssl,${MULTILIB_USEDEP}]"
+# @CODE
+MULTILIB_USEDEP=multilib?
+
 # @FUNCTION: autotools-multilib_foreach_abi
 # @USAGE: argv...
 # @DESCRIPTION:
-- 
1.8.1

[gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass

[Michael Weber]

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


 Original Message 
Subject: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog
toolchain.eclass
Date: Tue, 15 Jan 2013 02:30:53 + (UTC)
From: Ryan Hill (dirtyepic) 
Reply-To: gentoo-dev@lists.gentoo.org, dirtye...@gentoo.org
To: gentoo-comm...@lists.gentoo.org

dirtyepic13/01/15 02:30:53

  Modified: ChangeLog toolchain.eclass
  Log:
  Drop go support for 4.6 - broken by newer glibc versions and upstream
recommends it not be used.

Revision  ChangesPath
1.615eclass/ChangeLog

file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?rev=1.615&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?rev=1.615&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?r1=1.614&r2=1.615

Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v
retrieving revision 1.614
retrieving revision 1.615
diff -u -r1.614 -r1.615
--- ChangeLog   13 Jan 2013 22:35:28 -  1.614
+++ ChangeLog   15 Jan 2013 02:30:53 -  1.615
@@ -1,6 +1,10 @@
 # ChangeLog for eclass directory
 # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.614 2013/01/13
22:35:28 eva Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.615 2013/01/15
02:30:53 dirtyepic Exp $
+
+  15 Jan 2013; Ryan Hill  toolchain.eclass:
+  Drop go support for 4.6 - broken by newer glibc versions and upstream
+  recommends it not be used.

   13 Jan 2013; Gilles Dartiguelongue  gnome2.eclass:
   Allow ebuild override of eclass generated econf.



1.567eclass/toolchain.eclass

file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?rev=1.567&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?rev=1.567&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.566&r2=1.567

Index: toolchain.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v
retrieving revision 1.566
retrieving revision 1.567
diff -u -r1.566 -r1.567
--- toolchain.eclass29 Dec 2012 06:45:06 -  1.566
+++ toolchain.eclass15 Jan 2013 02:30:53 -  1.567
@@ -1,6 +1,6 @@
-# Copyright 1999-2012 Gentoo Foundation
+# Copyright 1999-2013 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v 1.566
2012/12/29 06:45:06 vapier Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v 1.567
2013/01/15 02:30:53 dirtyepic Exp $
 #
 # Maintainer: Toolchain Ninjas 

@@ -115,7 +115,7 @@
tc_version_is_at_least "4.3" && IUSE+=" fixed-point"
tc_version_is_at_least "4.4" && IUSE+=" graphite"
[[ ${GCC_BRANCH_VER} == 4.5 ]] && IUSE+=" lto"
-   tc_version_is_at_least "4.6" && IUSE+=" go"
+   tc_version_is_at_least "4.7" && IUSE+=" go"
fi
 fi






-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber 

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

[Dan Douglas]

On Tuesday, January 15, 2013 03:20:20 AM 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."  

While I agree, I wouldn't lose sleep over it. Both are perfectly acceptable 
and nearly equal in clarity. [[ $x ]] is probably most common.

> Consider:
> ...
> 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 ]] && ...

-z is the negation. -n is the default. [[ $x ]] is rewritten internally as [[ 
-n $x ]]. [[ ! $x ]] == [[ ! -n $x ]] == [[ -z $x ]]. It's perfectly logical 
that this expression evaluates true when given a non-empty value. As ''expr || 
die'' is the most expected form for error-checking, negating this with ''-z'' 
or otherwise makes little sense.

"Empty == False" is not an uncommon concept. e.g. python -c 'print(bool(""))'

> 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.

I wish people would stop referring to features that predate both Bash and 
POSIX as "Bashisms". ''[['' is superior to and easier to understand than 
''[''. Everyone should be familiar with both. As only Bash is relevant here, 
''test'' and ''['' are mostly irrelevant. With few exceptions, ''[['' should 
be preferred when available (and in this case, guaranteed available).

> Obviously the example in #6 is taking it a bit far, but my point is, an 
> explicit (if one-of-many) -z/-n test vs. the standalone (single-case) 
> $string test really is personal preference.

The performance difference is considerable.

-- 
Dan Douglas

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

[gentoo-dev] Chromium system ffmpeg

[Paweł Hajdan, Jr.]

I'm trying to make Chromium be more compatible with more versions of
ffmpeg:

(although not stated there, that includes libav).

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?

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

If there is anything else you want to share/say about this, please do.

Paweł



signature.asc
Description: OpenPGP digital signature

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

[Duncan]

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."  

Consider:

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.

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."

3) The situation in #2 is even worse than it might be due to the  
standalone alternative, making -n (and -z, #4) far less common than they 
would be otherwise.

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 ]] && ...

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.

6) If you're arguing for explicit, be consistent, with explicit
if/then, test, positive -z instead of negated -n logic... ::

if test -z "${BUILD_DIR}"; then die "${FUNCTNAME}: BUILD_DIR not set."



Obviously the example in #6 is taking it a bit far, but my point is, an 
explicit (if one-of-many) -z/-n test vs. the standalone (single-case) 
$string test really is personal preference.  You obviously prefer it one 
way, others (including me) prefer the other... for the very same reason, 
to us, our preferred way is instantly parsable, while the other way 
triggers "extra processing".

As such, IMO, "He who codes, decides." =:^)

(IIRC I did bring up the same thing, naturally arguing my standalone 
string test preference, in an earlier eclass proposal thread.  However, I 
believe I explicitly mentioned that I considered it a purely personal 
style thing and that others had the opposite preference, with to my 
knowledge no official gentoo coding style position taken on it.  Given 
that I had seen, I think you, bring up the point before, I was hoping 
someone would post the gentoo style-guide link proving me wrong, if there 
was one.  Given that nobody did so, I still believe it to be "he who 
codes, decides" territory.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[William Hubbs]

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.

William



pgpOr7kUoyxc4.pgp
Description: PGP signature

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

[Peter Stuge]

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?


//Peter


pgpswXbIiseJI.pgp
Description: PGP signature

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

[Mike Frysinger]

On Monday 14 January 2013 12:55:29 Dan Douglas wrote:
> On Sunday, January 13, 2013 01:28:42 PM Mike Frysinger wrote:
> > On Sunday 13 January 2013 08:29:43 Michał Górny wrote:
> > > + [[ ${BUILD_DIR} ]] || die "${FUNCNAME}: BUILD_DIR not set."
> > 
> > really should use -n there
> 
> Doesn't matter. Only zsh requires it (and pointlessly disagrees with every
> other implementation).

the point wasn't "will it work".  it's more "how easy is it to glance at code 
and know what it is doing".
-mike


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

Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds

[Mike Frysinger]

On Monday 14 January 2013 15:15:03 Pacho Ramos wrote:
> El lun, 14-01-2013 a las 18:15 +0100, hasufell escribió:
> [...]
> 
> > >> +1 to allow empty/missing HOMEPAGE variable
> > >> 
> > >> dead homepage => useless
> > >> http://gentoo.org => useless
> > >> https://bugs.gentoo.org => too obvious
> > > 
> > > An empty homepage usually means the package is dead. I'd rather see
> > > the cvs/git/svn url being used as HOMEPAGE in case your tiny little
> > > script has no proj page at all.
> > 
> > No, an empty homepage just means upstream is dead. There are numerous
> > examples of years old packages still working fine without a single
> > update.
> 
> Other option is to use "gentoo.org" as HOMEPAGE for that packages (as
> some of them are already doing). But, since people think it's useless,
> why not use as HOMEPAGE
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/...
> ?

semi-related, drop that intermediate noise.
http://sources.gentoo.org/${CATEGORY}/${PN}/
it'll redirect to the right place
-mike


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

Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds

[Pacho Ramos]

El lun, 14-01-2013 a las 15:49 -0500, Ian Stakenvicius escribió:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 14/01/13 03:15 PM, Pacho Ramos wrote:
> > El lun, 14-01-2013 a las 18:15 +0100, hasufell escribió: [...]
>  +1 to allow empty/missing HOMEPAGE variable
>  
>  dead homepage => useless http://gentoo.org => useless 
>  https://bugs.gentoo.org => too obvious
>  
> >>> 
> >>> An empty homepage usually means the package is dead. I'd rather
> >>> see the cvs/git/svn url being used as HOMEPAGE in case your
> >>> tiny little script has no proj page at all.
> >>> 
> >> 
> >> No, an empty homepage just means upstream is dead. There are
> >> numerous examples of years old packages still working fine
> >> without a single update.
> >> 
> >> 
> > 
> > Other option is to use "gentoo.org" as HOMEPAGE for that packages
> > (as some of them are already doing). But, since people think it's
> > useless, why not use as HOMEPAGE 
> > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/... ?
> 
> Or what about a URL to a wiki.gentoo.org page for dead upstream packages?

Well, the advantage of using sources.gentoo.org is that people will find
there patches and stuff related with the package :/


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

Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14/01/13 03:15 PM, Pacho Ramos wrote:
> El lun, 14-01-2013 a las 18:15 +0100, hasufell escribió: [...]
 +1 to allow empty/missing HOMEPAGE variable
 
 dead homepage => useless http://gentoo.org => useless 
 https://bugs.gentoo.org => too obvious
 
>>> 
>>> An empty homepage usually means the package is dead. I'd rather
>>> see the cvs/git/svn url being used as HOMEPAGE in case your
>>> tiny little script has no proj page at all.
>>> 
>> 
>> No, an empty homepage just means upstream is dead. There are
>> numerous examples of years old packages still working fine
>> without a single update.
>> 
>> 
> 
> Other option is to use "gentoo.org" as HOMEPAGE for that packages
> (as some of them are already doing). But, since people think it's
> useless, why not use as HOMEPAGE 
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/... ?

Or what about a URL to a wiki.gentoo.org page for dead upstream packages?

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

iF4EAREIAAYFAlD0b2YACgkQ2ugaI38ACPANAgD+IqKtIy4+UN/nanB20V5Hm99E
8FGmxroCAzpEGGikZb4A/Rj3nOYX3ZXFksojiAhbtcmwQ13Kg+I26MHwtxRhreUE
=6T1r
-END PGP SIGNATURE-

Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations

[Andreas K. Huettel]

[CC'ing this to core so noone can complain afterwards.]

Since 48h did not lead to any responses positive or negative, I'll start 
implementing the procedure as given in the original e-mail (quoted below).

As also said below, each arch will get a mail before I touch their profile 
tree and after I've finished.

Cheers, Andreas


Am Samstag, 12. Januar 2013, 21:47:18 schrieb Andreas K. Huettel:
> Hi everyone,
> 
> since Council has approved the creation of a fresh set of EAPI=5 "13.0"
> profiles, I would like to volunteer for creating them. The proposed
> procedure is outlined below in detail, and I'd be happy for comments.
> [If anything below deviates from Council decision, please tell me- not my
> intention.]
> 
> One general question comes first, though: Right now, the releases/10.0
> profile directory does the following things:
> * mask too-old portage
> * set eapi
> * add USE=bzip2
> 
> Is there anything unrelated to EAPI=5 that absolutely must be added to the
> new releases/13.0 directory in addition in your opinion? (Whether this is
> the right place and was the right place in the beginning for USE=bzip2 is
> another question.)
> 
> ###
> 
> The procedure (all paths relative to profiles):
> 
> 1) create directory eapi-5-files, with eapi (containing 5), skeletons for
> package.stable.mask etc and a readme
> 
> 2) copy releases/10.0 to releases/13.0, in releases/13.0:
> * increase required portage version
> * additionally inherit ../../eapi-5-files
> * other changes as per question above?
> 
> 3) for each arch in default/linux,
> * announce on arch alias (to prevent overlapping commits)
> * copy default/linux/${arch}/10.0 to default/linux/${arch}/13.0 and
> * change inheritance in the new copy to inherit ../../../../releases/13.0
> instead of ../../../../releases/10.0
> * announce on arch alias (so future changes go into 13.0 tree)
> [This describes the simple case. I realize that there are differences in
> the directory structure, e.g. powerpc/ppc64/10.0, which is why this step
> needs extra care.]
> 
> 4) edit profiles.desc and copy all "10.0 lines" to "13.0 lines", with an
> initial setting "dev" (if dev or stable before) or "exp" (if exp before)
> This makes repoman check against the new profiles when using developer
> profiles.
> 
> 5) announce the state on the dev list, urging devs to update their symlink
> manually and !test!
> 
> 6) wait one / two weeks
> 
> 7) in profiles.desc, mark all 13.0 profiles stable that were stable in
> 10.0, and remove the lines for the 10.0 profiles. This makes eselect
> profile now only offer the new ones, and repoman test by default against
> 13.0 profiles.
> 
> 8) mark all 10.0 profiles as deprecated by creating a "deprecated" file
> (containing the replacement suggestion) in the directory. This makes
> portage warn users to upgrade (suggesting a new profile for them), and
> repoman ignore the 10.0 profiles.
> 
> 9) long waiting time as decided by Council
> 
> ###
> 
> Everything that does NOT use/inherit 10.0 will remain unaffected, and
> whoever responsible may have to take care of that some time before (in
> step 10) the main profile directory becomes EAPI=5. This means e.g.
> hardened, ulibc, prefix or bsd.
> 
> Cheers,
> Andreas


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/



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

Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds

[Pacho Ramos]

El lun, 14-01-2013 a las 18:15 +0100, hasufell escribió:
[...]
> >> +1 to allow empty/missing HOMEPAGE variable
> >>
> >> dead homepage => useless
> >> http://gentoo.org => useless
> >> https://bugs.gentoo.org => too obvious
> >>
> > 
> > An empty homepage usually means the package is dead. I'd rather see
> > the cvs/git/svn url being used as HOMEPAGE in case your tiny little
> > script has no proj page at all.
> > 
> 
> No, an empty homepage just means upstream is dead. There are numerous
> examples of years old packages still working fine without a single update.
> 
> 

Other option is to use "gentoo.org" as HOMEPAGE for that packages (as
some of them are already doing). But, since people think it's useless,
why not use as HOMEPAGE
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/...
?


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

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

[Alec Warner]

On Mon, Jan 14, 2013 at 9:30 AM, Dan Douglas  wrote:
> On Sunday, January 13, 2013 06:02:26 PM Michał Górny wrote:
>> On Sun, 13 Jan 2013 07:36:59 -0800
>> Alec Warner  wrote:
>> > local -i ret
>> > ?
>>
>> Looks good. I didn't even know bash has something like that.
>>
>
> Useless use of -i is usually unhelpful. In Bash (but not all shells), it's
> slower, because it's still just storing the value as a string and marking the
> variable with the integer attribute which modifies the way certain assignments
> behave.
>
> It doesn't do any harm in this specific case, but there are a lot of gotchas
> with -i to be aware of if you're going to use it.
> --
> Dan Douglas

It is bash...there are lots of gotchas with almost *all* of bash's features ;)

-A

Re: [gentoo-dev] systemd/udev split

[Rich Freeman]

On Mon, Jan 14, 2013 at 2:28 PM, William Hubbs  wrote:
> The only time I see eudev replacing udev as our default is if the
> systemd guys actually kill udev on non-systemd systems.
>

Seems likely to me, but anticipating about 300 replies to your post, I
think we're all agreed that we'll do what makes sense when it makes
sense to do it.  Really no value in another thread speculating about
the future of udev - bottom line is that we're prepared any which way.

Rich

Re: [gentoo-dev] systemd/udev split

[William Hubbs]

On Mon, Jan 14, 2013 at 01:59:14PM -0500, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 14/01/13 01:06 PM, Oleksii Shevchuk wrote:
> > Hi list!
> > 
> > After introducing eudev, is there any reason to do systemd/udev
> > split?
> > 
> 
> Ask in 6 months to a year, after eudev is fully established and has a
> solid track record.

The only time I see eudev replacing udev as our default is if the
systemd guys actually kill udev on non-systemd systems.

William



pgpmBdABOFaJp.pgp
Description: PGP signature

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

[William Hubbs]

On Mon, Jan 14, 2013 at 06:04:01AM +, Steven J. Long wrote:
> On Sat, Jan 12, 2013 William Hubbs wrote:
> > Steven J. Long wrote:
> > > If you're certain that every user with a current simple setup, who
> > > uses the kernel default names, and has such a firewall setup isn't
> > > going to suddenly find their interface name changed when they reboot,
> > > fair play to you. If not, allow the admin to opt-in, rather than force
> > > them to opt-out when something breaks.
> > 
> > The following is taken from the wiki:
> > 
> > You basically have three options: 
> <3 options that all require an admin opt-in to keep their existing
>  config running>
> 
> There you go: the exact wrong way to do it. As Poettering might say:
> "C'mon man, seriously? (whiny voice and pleading looks)"

If you have read this thread at all, you see that when you upgrade to
udev-197, I create a file, /etc/udev/rules.d/80-net-name-slot.rules on
your system.

Now, go and compare that fact to the wiki page and tell me if I'm not
setting you up to be opted out of this by default.

There is a separate issue, which is new installs. I have a bug opened
with the docs team and release engineering to discuss whether we want
the new names for new installs.

William



pgpvRLLiLgugN.pgp
Description: PGP signature

Re: [gentoo-dev] systemd/udev split

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14/01/13 01:06 PM, Oleksii Shevchuk wrote:
> Hi list!
> 
> After introducing eudev, is there any reason to do systemd/udev
> split?
> 

Ask in 6 months to a year, after eudev is fully established and has a
solid track record.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD0VYIACgkQ2ugaI38ACPDYXQD/eHTwH7TzoSHhA2bkt7BUpIC1
Oi2Na7R+T5ptZ5c0AAQA/1NkdatkFy84LKDuA6HHBfLg5dIHnKTSf7N06aahQaBi
=2RL4
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

On Mon, 14 Jan 2013 15:04:45 -0300
Alexis Ballier  wrote:

> On Thu, 03 Jan 2013 11:44:58 +0100
> Thomas Sachau  wrote:
> 
> > Please keep in mind, that the USE flags are different, depending on
> > your arch. E.g. on amd64, you may additionally have x86 and x32,
> > while on ppc64, you may have ppc64 and ppc. You dont want the later
> > on amd64 nor the first on ppc. So how do you want to add different
> > (use-expanded) USE flags based on the arch the user is running?
> 
> no, the useflags are not different:
> 
> coma=""
> for i in $MULTILIB_ABIS ; do
> multilib_use_deps+="${coma}multilib_abi_${i}?"
> coma=", "
> done
> 
> deps like foo[multilib?] becomes foo[${multilib_use_deps}]
> and voila, you are not anymore limited to multilib or not multilib but
> really control the abis.

Hmm, it may be a good idea to introduce such a variable already.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

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

[Kevin Chadwick]

> William is packaging upstream udev for Gentoo.
> 
> You are shooting the messenger.

I expect there is 0 blame meant for William. 


P.s. 

Is it William that Lennart dished some blame in the direction of. I
completely disagree. It's not the job of every distro to look for all
build flags to fix some software's defaults because other software has
some small issues. That's simply ludicrous and my best guess is it
being a feeble attempt at reasoning an excuse. At the very least and
like in many release notes, it should have been made clear that distros
may wish to consider using that flag to keep the current behaviour
whether any reason to do was understood or not. The thought strikes me
now that in the reverse case their likely wouldn't be any justification
for having a build flag?

Debian having to patch KDE to use /etc for configs is simply wrong too.

You are right though, I don't suppose it helps much airing any of it
here.

-- 
___

'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] systemd/udev split

[Rich Freeman]

On Mon, Jan 14, 2013 at 1:21 PM, Diego Elio Pettenò
 wrote:
> I don't want systemd and I don't want eudev. And I'm not alone I'm sure.

++

If it costs me 1200 seconds of CPU time and 40 millicents in
electricity twice I year I can live with that...

Rich

Re: [gentoo-dev] systemd/udev split

[Georg Rudoy]

2013/1/14 Diego Elio Pettenò :
> I don't want systemd and I don't want eudev. And I'm not alone I'm sure.

You are definitely not alone (though I'm not a gentoo dev).

I think it makes sense to keep it split as long as udev is buildable
without systemd and until eudev proves to be stable enough. After all,
sadly, upstream udev has much larger userbase than eudev.

--
  Georg Rudoy
  LeechCraft — http://leechcraft.org

Re: [gentoo-dev] systemd/udev split

[Diego Elio Pettenò]

Yes.

I don't want systemd and I don't want eudev. And I'm not alone I'm sure.

[gentoo-dev] systemd/udev split

[Oleksii Shevchuk]

Hi list! 

After introducing eudev, is there any reason to do systemd/udev split?

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Thu, 03 Jan 2013 11:44:58 +0100
Thomas Sachau  wrote:

> Pacho Ramos schrieb:
> > El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió:
> >> On Sun, 23 Sep 2012 16:49:13 +0200
> >> Thomas Sachau  wrote:
> >>
> >>> It is not hard by itself to inherit an eclass. There is just the
> >>> limitation, that occurs with an eclass, e.g.:
> >>>
> >>> -the one from mgorny only does it for autotools based ebuilds
> >>> only and even there only for libraries, headers and binaries are
> >>> not done. While one may create the same for cmake based ones,
> >>> those are still only for a subset of packages, since not all do
> >>> use autotools/cmake or are satisfied with a libs only solution
> >>> -the multilib-native eclass does extend it way more, but still
> >>> has its limitations, e.g. what happens with a new target ABI
> >>> (like x32 on the amd64 profile) or how are dependencies handled?
> >>>
> >>> multilib-portage is the answer to those limitations, since it does
> >>> work for any target with multilib cross-compile support, can
> >>> handle things like the dependencies internally and can even work
> >>> on not prepared/modified ebuilds.
> >>>
> >>> So before i invest even more time in getting this official, we
> >>> should better get to some conclusion, if we either go the route
> >>> with eclass based multilib cross-compile support with its
> >>> limitations or if we move this up to the package manager level.
> >>>
> >>
> >> Can't we get something in between ?
> >>
> >> Unless I'm mistaken, portage-multilib has its limitations also:
> >>
> >> - I have package foo and package bar, both depending on ffmpeg and
> >> canditates for a multilib build. However, package foo does not
> >> link to ffmpeg but simply spawns the 'ffmpeg' binary to process
> >> some files, package bar links to libavcodec. You need
> >> ffmpeg[multilib] for a multilib build of bar but not for foo. How
> >> do you distinguish between the two ?
> 
> I dont really understand your question here. So do you:
> 
> - simply have 2 64bit apps wanting to use ffmpeg?
> - have 2 32bit binary packages wanting to use ffmpeg?
> - want to build foo and bar on a 64bit platform for a 32bit platform?
> - want a 64bit or a 32bit version of ffmpeg or both?
> - if you want a 32bit version of ffmpeg, do you only want 32bit libs
> or also a 32bit binary?


it depends on what you are building; let's say we want all abi flavors
for foo and bar.

in the above example, package foo uses fork/exec so needs a libc
compatible with its abis and that's all; it doesn't care if ffmpeg is
an elf executable, a bash script, or running through an emulator.
package bar needs ffmpeg libraries for every abi it installs.
portage multilib doesn't seem to distinguish between the two cases.

> >> - When an out-of-tree build is possible, it is more efficient to
> >> do it that way while multilib-portage will probably run the full
> >> src_* phases twice. mgorny's eclass is a solution to this for
> >>   autotools-utils based ebuilds. I have added basic support for
> >> this in freebsd-lib some time ago also.
> 
> Isnt "out-of-tree build" just building in a seperate location, so in
> the end doing one unpack instead of 2, while everything else still
> needs to be done for each target?

yes, so?
(unpack in the EAPI0 sense btw, prepare shouldn't need to be done twice
either)

> >> However, it is clear that USE=multilib is limited too. What we
> >> probably need, as I read in the draft you posted some time ago, is
> >> a MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in
> >> an eclass, add them to IUSE of multilib-enabled packages and then
> >> you can use the USE-deps. When a new ABI gets added, add it to the
> >> list in the eclass and be done. You already have PM support for
> >> this :)
> 
> Please keep in mind, that the USE flags are different, depending on
> your arch. E.g. on amd64, you may additionally have x86 and x32,
> while on ppc64, you may have ppc64 and ppc. You dont want the later
> on amd64 nor the first on ppc. So how do you want to add different
> (use-expanded) USE flags based on the arch the user is running?

no, the useflags are not different:

coma=""
for i in $MULTILIB_ABIS ; do
multilib_use_deps+="${coma}multilib_abi_${i}?"
coma=", "
done

deps like foo[multilib?] becomes foo[${multilib_use_deps}]
and voila, you are not anymore limited to multilib or not multilib but
really control the abis.

> >> You can leverage the generic multilib building code you have to an
> >> eclass, so that you don't need to spec it; spec-ing it has its
> >> problems too: what happens if next year pkg-config is deprecated
> >> and now we shall all use foo-config ? your spec adjusts
> >> PKG_CONFIG_PATH but not FOO_CONFIG_PATH. You probably need a small
> >> EAPI change to be able to implement sanely a generic solution into
> >> an eclass though.
> >>
> >> My question to you would be: what are we missing from current
> >> EAPIs to be able to perfectly support mu

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

[Dan Douglas]

On Sunday, January 13, 2013 01:28:42 PM Mike Frysinger wrote:
> On Sunday 13 January 2013 08:29:43 Michał Górny wrote:
> > +   [[ ${BUILD_DIR} ]] || die "${FUNCNAME}: BUILD_DIR not set."
>
> really should use -n there
>
Doesn't matter. Only zsh requires it (and pointlessly disagrees with every
other implementation).

There are many possibilities.
${BUILD_DIR:+:} die "${FUNCNAME}: BUILD_DIR unset or empty."

--
Dan Douglas

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

Re: [gentoo-dev] Clarify log message?

[Diego Elio Pettenò]

On 14/01/2013 18:32, Zac Medico wrote:
> Ah, right! So, those packages also need to be patched to use /run
> directly, instead of relying on the symlink.

Or the symlink should just stay for however long that's going to take,
which is probably a good idea, as it does not bother anyone.

I don't think that's going to be a problem for running systems though:
the symlink will never be entirely empty.

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

Re: [gentoo-dev] Clarify log message?

[Zac Medico]

On 01/14/2013 09:23 AM, Diego Elio Pettenò wrote:
> On 14/01/2013 18:14, Zac Medico wrote:
>> It might be a lot simpler to just go and patch all the ebuilds that
>> installed stuff in /var/run with a one-liner like this at the end of
>> src_install:
> 
> It's a good idea to do so to avoid the check coming from portage to
> happena nd waste time, but ...
> 
>> Once all the ebuilds are fixed, emerge will automatically remove the
>> /var/run symlink, and it's history.
> 
> That should not happen. Ever. Because if it did we'd be in deep shit.
> The fact that /var/run is a symlink is what saves us from having to
> convert everything to actually use /run, and instead we still refer to
> /var/run in most places _but_ we use checkpath for it.
> 
> If /var/run symlink was killed, we'd end up with a ton of services
> creating a (now permanent) /var/run directory structure, with even more
> trouble.

Ah, right! So, those packages also need to be patched to use /run
directly, instead of relying on the symlink.
-- 
Thanks,
Zac

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

[Dan Douglas]

On Sunday, January 13, 2013 06:02:26 PM Michał Górny wrote:
> On Sun, 13 Jan 2013 07:36:59 -0800
> Alec Warner  wrote:
> > local -i ret
> > ?
>
> Looks good. I didn't even know bash has something like that.
>

Useless use of -i is usually unhelpful. In Bash (but not all shells), it's
slower, because it's still just storing the value as a string and marking the
variable with the integer attribute which modifies the way certain assignments
behave.

It doesn't do any harm in this specific case, but there are a lot of gotchas
with -i to be aware of if you're going to use it.
--
Dan Douglas

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

Re: [gentoo-dev] Clarify log message?

[Diego Elio Pettenò]

On 14/01/2013 18:14, Zac Medico wrote:
> It might be a lot simpler to just go and patch all the ebuilds that
> installed stuff in /var/run with a one-liner like this at the end of
> src_install:

It's a good idea to do so to avoid the check coming from portage to
happena nd waste time, but ...

> Once all the ebuilds are fixed, emerge will automatically remove the
> /var/run symlink, and it's history.

That should not happen. Ever. Because if it did we'd be in deep shit.
The fact that /var/run is a symlink is what saves us from having to
convert everything to actually use /run, and instead we still refer to
/var/run in most places _but_ we use checkpath for it.

If /var/run symlink was killed, we'd end up with a ton of services
creating a (now permanent) /var/run directory structure, with even more
trouble.

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

Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds

[hasufell]

On 01/14/2013 11:06 AM, Markos Chandras wrote:
> On 13 January 2013 18:06, hasufell  wrote:
>> On 01/13/2013 07:03 PM, Zac Medico wrote:
>>> On 01/13/2013 09:43 AM, hasufell wrote:
 On 01/13/2013 03:24 PM, Michał Górny wrote:
> Hello,

> Right now an attempt to commit an ebuild with no HOMEPAGE results
> in:

> HOMEPAGE.missing  1
> app-admin/eselect-sh/eselect-sh-0.4.ebuild

> Note: use --include-dev (-d) to check dependencies for 'dev'
> profiles

> Please fix these important QA issues first.

> Why is this considered an 'important QA issue'? Does the policy
> really say that if something doesn't have a homepage, we're
> supposed to put garbage in there?



 That is already lifted:
 https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-660007.2

 seems to be a repoman bug or just not yet implemented
>>>
>>> repoman is intended to enforce policies, which can be stricter than pms.
>>> So, the question is, what is our policy going to be?
>>
>>
>> +1 to allow empty/missing HOMEPAGE variable
>>
>> dead homepage => useless
>> http://gentoo.org => useless
>> https://bugs.gentoo.org => too obvious
>>
> 
> An empty homepage usually means the package is dead. I'd rather see
> the cvs/git/svn url being used as HOMEPAGE in case your tiny little
> script has no proj page at all.
> 

No, an empty homepage just means upstream is dead. There are numerous
examples of years old packages still working fine without a single update.

Re: [gentoo-dev] Clarify log message?

[Zac Medico]

On 01/14/2013 09:00 AM, Ian Stakenvicius wrote:
> At least then we can see if there really is a benefit to changing how
> it is now.  I can probably hack an install so that the /var/run
> migration can be redone, for testing..

It might be a lot simpler to just go and patch all the ebuilds that
installed stuff in /var/run with a one-liner like this at the end of
src_install:

  rm -rf "${ED}"/var/run

Once all the ebuilds are fixed, emerge will automatically remove the
/var/run symlink, and it's history.
-- 
Thanks,
Zac

Re: [gentoo-dev] app-emulation/qemu-user mask

[Doug Goldstein]

On Mon, Jan 14, 2013 at 1:47 AM, Alexey Shvetsov  wrote:
> В письме от 14 января 2013 00:38:06 пользователь Doug Goldstein написал:
>> On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov  wrote:
>> > Hi!
>> >
>> > For cross-chroots its needed to have static qemu-$arch user translators.
>> > May be you can introduce user-static use flag for them? Also it will be
>> > cool to have init script for kvm
>>
>> USE=static is available for app-emulation/qemu. I'll get a chroot for
>> arm setup soon and test everything to make sure its working well.
>
> It doesnt allow to build dynamik qemu-system* and static user targets

That can be fixed. File a bug.

>
>>
>> With regards to the KVM init script, I'm uninterested in maintaining
>> it and it doesn't belong in the package as it is. There's a number of
>> submitted init scripts that are attempting to create "init scripts"
>> but really they're re-inventing libvirt and ganeti, but instead
>> poorly. Ones I know about are:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=321517
>> https://bugs.gentoo.org/show_bug.cgi?id=406043
>
> Ghm.. Its some kind of overkill to install libvirt or gannety just for 1-2 vms
>



-- 
Doug Goldstein

Re: [gentoo-dev] Clarify log message?

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14/01/13 11:36 AM, Zac Medico wrote:
> On 01/14/2013 08:26 AM, Ian Stakenvicius wrote:
>> On 14/01/13 10:53 AM, Zac Medico wrote:
>>> On 01/14/2013 07:44 AM, Zac Medico wrote:
 On 01/14/2013 07:09 AM, Ian Stakenvicius wrote:
> OK i'm a little confused.  Putting my earlier note aside,
> if the symlink will be auto-cleaned after no packages use
> it, what's the point/need for the original message from
> portage then??  Is it just QA for the ebuild maintainer?
 
 Unfortunately, there are a number of different possible 
 scenarios. It may serve as QA for the ebuild maintainer. It
 may be triggered by a symlink that the sysadmin has manually
 created. In any case, there's a performance penalty, since
 portage has to search for other packages that installed files
 underneath the symlink. The performance penalty can be
 avoided for a given symlink by adding it to UNINSTALL_IGNORE
 (which makes the message useful, regardless of where the
 symlink originated from).
>> 
>>> You can measure the performance penalty for the /var/run
>>> symlink by running this command:
>> 
>>> time portageq owners / /var/run
>> 
>> 
>> Based on the performance penalty, would it make sense then for 
>> system-managed symlinks like /var/run that it would be
>> automatically added to UNINSTALL_IGNORE and its removal managed
>> separately by whatever put it there in the first place??
> 
> There's currently no way for ebuilds to add things to
> UNINSTALL_IGNORE though (aside from having them edit make.conf).
> And how is openrc going to know when to remove it?

That would be where some sort of external tracking would need to
occur, which could be triggered via pkg_postinst and/or
pkg_{pre,post}rm in the eclass


> 
>> (and additionally, that the warning wouldn't be presented to
>> end-users because of it being a system-managed migration symlink
>> instead of a end-user-managed one)?
> 
> Do you want to introduce a new variable for this purpose, and
> allow ebuilds to modify it via /etc/env.d or something?

Possibly...

For the proof-of-concept phase I'm thinking of doing it via an eclass,
a file that'd be managed by that eclass, an external tool if required
to manage said file and/or process removal of the symlink (for cases
when the symlink isn't put in place by an ebuild during pkg_postinst,
ie if an init script should clean it up), and either source  that file
or a separate file in make.conf.

At least then we can see if there really is a benefit to changing how
it is now.  I can probably hack an install so that the /var/run
migration can be redone, for testing..

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

iF4EAREIAAYFAlD0OcAACgkQ2ugaI38ACPDkEgD/XYba0NejxqOPv41EsNa8U7tr
rm4vanPJubJCBX+rsrwA+wUKW3w9nOEkXw87AYJmq0/QFx0vFVfKJLUsrcF168gk
=imL1
-END PGP SIGNATURE-

Re: [gentoo-dev] Clarify log message?

[Zac Medico]

On 01/14/2013 08:26 AM, Ian Stakenvicius wrote:
> On 14/01/13 10:53 AM, Zac Medico wrote:
>> On 01/14/2013 07:44 AM, Zac Medico wrote:
>>> On 01/14/2013 07:09 AM, Ian Stakenvicius wrote:
 OK i'm a little confused.  Putting my earlier note aside, if
 the symlink will be auto-cleaned after no packages use it,
 what's the point/need for the original message from portage
 then??  Is it just QA for the ebuild maintainer?
>>>
>>> Unfortunately, there are a number of different possible
>>> scenarios. It may serve as QA for the ebuild maintainer. It may
>>> be triggered by a symlink that the sysadmin has manually created.
>>> In any case, there's a performance penalty, since portage has to
>>> search for other packages that installed files underneath the
>>> symlink. The performance penalty can be avoided for a given
>>> symlink by adding it to UNINSTALL_IGNORE (which makes the message
>>> useful, regardless of where the symlink originated from).
> 
>> You can measure the performance penalty for the /var/run symlink
>> by running this command:
> 
>> time portageq owners / /var/run
> 
> 
> Based on the performance penalty, would it make sense then for
> system-managed symlinks like /var/run that it would be automatically
> added to
> UNINSTALL_IGNORE and its removal managed separately by whatever put it
> there in the first place??

There's currently no way for ebuilds to add things to UNINSTALL_IGNORE
though (aside from having them edit make.conf). And how is openrc going
to know when to remove it?

> (and additionally, that the warning wouldn't be presented to end-users
> because of it being a system-managed migration symlink instead of a
> end-user-managed one)?

Do you want to introduce a new variable for this purpose, and allow
ebuilds to modify it via /etc/env.d or something?
-- 
Thanks,
Zac

Re: [gentoo-dev] Clarify log message?

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14/01/13 10:53 AM, Zac Medico wrote:
> On 01/14/2013 07:44 AM, Zac Medico wrote:
>> On 01/14/2013 07:09 AM, Ian Stakenvicius wrote:
>>> OK i'm a little confused.  Putting my earlier note aside, if
>>> the symlink will be auto-cleaned after no packages use it,
>>> what's the point/need for the original message from portage
>>> then??  Is it just QA for the ebuild maintainer?
>> 
>> Unfortunately, there are a number of different possible
>> scenarios. It may serve as QA for the ebuild maintainer. It may
>> be triggered by a symlink that the sysadmin has manually created.
>> In any case, there's a performance penalty, since portage has to
>> search for other packages that installed files underneath the
>> symlink. The performance penalty can be avoided for a given
>> symlink by adding it to UNINSTALL_IGNORE (which makes the message
>> useful, regardless of where the symlink originated from).
> 
> You can measure the performance penalty for the /var/run symlink
> by running this command:
> 
> time portageq owners / /var/run
> 

Based on the performance penalty, would it make sense then for
system-managed symlinks like /var/run that it would be automatically
added to
UNINSTALL_IGNORE and its removal managed separately by whatever put it
there in the first place??

(and additionally, that the warning wouldn't be presented to end-users
because of it being a system-managed migration symlink instead of a
end-user-managed one)?

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

iF4EAREIAAYFAlD0McYACgkQ2ugaI38ACPADjgD8D1nRkHqYNQLwtfb43X5QwAFI
V9EM0yqdOWX9zI98+tABAJS5KTiZkejCVwK9Ord0VRtkyGVkGgZ+HDBvuOJHsIUA
=3+S4
-END PGP SIGNATURE-

Re: [gentoo-dev] Clarify log message?

[Zac Medico]

On 01/14/2013 07:44 AM, Zac Medico wrote:
> On 01/14/2013 07:09 AM, Ian Stakenvicius wrote:
>> OK i'm a little confused.  Putting my earlier note aside, if the
>> symlink will be auto-cleaned after no packages use it, what's the
>> point/need for the original message from portage then??  Is it just QA
>> for the ebuild maintainer?
> 
> Unfortunately, there are a number of different possible scenarios. It
> may serve as QA for the ebuild maintainer. It may be triggered by a
> symlink that the sysadmin has manually created. In any case, there's a
> performance penalty, since portage has to search for other packages that
> installed files underneath the symlink. The performance penalty can be
> avoided for a given symlink by adding it to UNINSTALL_IGNORE (which
> makes the message useful, regardless of where the symlink originated from).

You can measure the performance penalty for the /var/run symlink by
running this command:

  time portageq owners / /var/run

-- 
Thanks,
Zac

Re: [gentoo-dev] Clarify log message?

[Zac Medico]

On 01/14/2013 07:09 AM, Ian Stakenvicius wrote:
> On 14/01/13 09:57 AM, Zac Medico wrote:
>> On 01/14/2013 06:46 AM, Ian Stakenvicius wrote:
>>> This particular symlink was put there by openrc though, wasn't
>>> it?
> 
>> Yeah, openrc uses the migrate_to_run function from
>> /etc/init.d/bootmisc.
> 
>>> So I'd expect that on the whole this should be left for openrc to
>>> deal with or otherwise left to the user...?
> 
>> As things are now, the symlink is an orphan, and emerge will 
>> automatically remove the symlink when the last package that
>> installed something under /var/run/ is uninstalled.
> 
> ...that doesn't sound good ; /var/run traditionally isn't a path used
> solely via src_install() but rather a path used by packages at
> runtime, no?  If that's the case, that symlink probably should've been
> set up to remain until user intervention removes it..

It would be possible would be possible to protect the symlink by having
openrc or baselayout install the symlink, so that it's not an orphan.

Alternatively, users could manually protect it, by adding this setting
to make.conf:

 UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /var/run"

>>> [tangent] it's a bit late for /var/run , but i wonder if, for the
>>> next path migration, there might be some way to account for which
>>> packages use the old path, say, make a list somewhere, and have
>>> the ebuilds remove their atom from that list as they migrate to
>>> the new path..  Then once the list is empty the compatibility
>>> symlink could be cleaned up automatically or the user notified..
>>> Probably this would need to be handled via an eclass and specific
>>> function calls in all relevant ebuilds, as i doubt there would be
>>> a way to do this generically in portage itself. [/tangent]
>>>
> 
>> That sounds a lot like the existing behavior (automatic symlink
>> removal by emerge).
> 
> OK i'm a little confused.  Putting my earlier note aside, if the
> symlink will be auto-cleaned after no packages use it, what's the
> point/need for the original message from portage then??  Is it just QA
> for the ebuild maintainer?

Unfortunately, there are a number of different possible scenarios. It
may serve as QA for the ebuild maintainer. It may be triggered by a
symlink that the sysadmin has manually created. In any case, there's a
performance penalty, since portage has to search for other packages that
installed files underneath the symlink. The performance penalty can be
avoided for a given symlink by adding it to UNINSTALL_IGNORE (which
makes the message useful, regardless of where the symlink originated from).
-- 
Thanks,
Zac

Re: [gentoo-dev] Clarify log message?

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14/01/13 09:57 AM, Zac Medico wrote:
> On 01/14/2013 06:46 AM, Ian Stakenvicius wrote:
>> This particular symlink was put there by openrc though, wasn't
>> it?
> 
> Yeah, openrc uses the migrate_to_run function from
> /etc/init.d/bootmisc.
> 
>> So I'd expect that on the whole this should be left for openrc to
>> deal with or otherwise left to the user...?
> 
> As things are now, the symlink is an orphan, and emerge will 
> automatically remove the symlink when the last package that
> installed something under /var/run/ is uninstalled.

...that doesn't sound good ; /var/run traditionally isn't a path used
solely via src_install() but rather a path used by packages at
runtime, no?  If that's the case, that symlink probably should've been
set up to remain until user intervention removes it..


> 
>> [tangent] it's a bit late for /var/run , but i wonder if, for the
>> next path migration, there might be some way to account for which
>> packages use the old path, say, make a list somewhere, and have
>> the ebuilds remove their atom from that list as they migrate to
>> the new path..  Then once the list is empty the compatibility
>> symlink could be cleaned up automatically or the user notified..
>> Probably this would need to be handled via an eclass and specific
>> function calls in all relevant ebuilds, as i doubt there would be
>> a way to do this generically in portage itself. [/tangent]
>> 
> 
> That sounds a lot like the existing behavior (automatic symlink
> removal by emerge).

OK i'm a little confused.  Putting my earlier note aside, if the
symlink will be auto-cleaned after no packages use it, what's the
point/need for the original message from portage then??  Is it just QA
for the ebuild maintainer?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD0H68ACgkQ2ugaI38ACPC+vAEAhGHZMfN2/dY+SXHFBStbckkH
9geiYEJAOEa6kcbOS28A/2hUq67WlVRiRP0vqW1WdeTod7aHhvc//q2TH994BWaI
=pWiP
-END PGP SIGNATURE-

Re: [gentoo-dev] Clarify log message?

[Zac Medico]

On 01/14/2013 06:46 AM, Ian Stakenvicius wrote:
> This particular symlink was put there by openrc though, wasn't it?

Yeah, openrc uses the migrate_to_run function from /etc/init.d/bootmisc.

> So
> I'd expect that on the whole this should be left for openrc to deal
> with or otherwise left to the user...?

As things are now, the symlink is an orphan, and emerge will
automatically remove the symlink when the last package that installed
something under /var/run/ is uninstalled.

> [tangent]
> it's a bit late for /var/run , but i wonder if, for the next path
> migration, there might be some way to account for which packages use
> the old path, say, make a list somewhere, and have the ebuilds remove
> their atom from that list as they migrate to the new path..  Then once
> the list is empty the compatibility symlink could be cleaned up
> automatically or the user notified..  Probably this would need to be
> handled via an eclass and specific function calls in all relevant
> ebuilds, as i doubt there would be a way to do this generically in
> portage itself.
> [/tangent]
> 

That sounds a lot like the existing behavior (automatic symlink removal
by emerge).
-- 
Thanks,
Zac

Re: [gentoo-dev] Clarify log message?

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14/01/13 04:44 AM, Zac Medico wrote:
> On 01/14/2013 01:33 AM, Dirkjan Ochtman wrote:
>> I've seen this pop up a lot recently:
>> 
>> * One or more symlinks to directories have been preserved in
>> order to * ensure that files installed via these symlinks remain
>> accessible. This * indicates that the mentioned symlink(s) may be
>> obsolete remnants of an * old install, and it may be appropriate
>> to replace a given symlink with * the directory that it points
>> to. * *  /var/run *
>> 
>> This might just be me being dense, but this doesn't seem very 
>> actionable to me. Who should replace the given symlink with the 
>> directory that it points to, the user or the package maintainer?
> 
> It depends on who created the symlink in the first place, and
> whether or not the symlink is still desirable. Unfortunately, there
> are a number of possible scenarios.
> 
> You probably want to keep that /var/run symlink, at least until all
> of your installed packages have been fixed to use /run directly.
> You can suppress the warning by putting a setting like this in
> make.conf:
> 
> UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /var/run"
> 
> That will prevent portage from trying to uninstall that symlink.
> 
>> And where should it be replaced? In ebuild code?
> 
> It's possible for ebuild code to do it, if appropriate for the
> given scenario. For example, the skype ebuild removes an obsolete 
> "${EROOT}"/usr/share/${PN} symlink in pkg_preinst.


This particular symlink was put there by openrc though, wasn't it?  So
I'd expect that on the whole this should be left for openrc to deal
with or otherwise left to the user...?

[tangent]
it's a bit late for /var/run , but i wonder if, for the next path
migration, there might be some way to account for which packages use
the old path, say, make a list somewhere, and have the ebuilds remove
their atom from that list as they migrate to the new path..  Then once
the list is empty the compatibility symlink could be cleaned up
automatically or the user notified..  Probably this would need to be
handled via an eclass and specific function calls in all relevant
ebuilds, as i doubt there would be a way to do this generically in
portage itself.
[/tangent]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD0GjkACgkQ2ugaI38ACPD5rwD/f4MkzFrlSShRWt/9WB12kybX
uY0uzf5SFmfihzNthOABALr6bT3bB7PAr4eh4tmQH+jH9Z635OD5/BcdJBYw7tLl
=S5ML
-END PGP SIGNATURE-

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

[Peter Stuge]

Steven J. Long wrote:
> What I'm not in favour of is making the simple cases more
> difficult, to deal with the complex ones. It's completely
> brain-dead thinking.

This is exactly what some people think or say when they learn that I
use Gentoo.

I appreciate Gentoo because I am able and willing to control my system.

Users of other distributions are either not able or not willing or
both, and thus they find Gentoo completely brain-dead. That's fine.

I don't have to care about them when deciding what I will run.

I hope the analogy is clear.

If the kernel changes it's network device naming policy, please talk
to the kernel developers - it seems counterproductive to expect that
some distribution will bend far f-ing backwards in order to provide
you the same experience that you were used to with the old kernel.

It seems equally counterproductive to expect or demand that udev will
change (or not change) the way you want it to, if you are not one of
the core developers.

William is packaging upstream udev for Gentoo.

You are shooting the messenger.

If you do not like what udev is doing, then step in and PARTICIPATE
in that project, or in one of the competing projects. (I wish there
wouldn't be so much fragmentation, but the NIH syndrome is mighty.)

The task of distributions is to deliver a composite of upstreams.

The task of distributions is NOT to deliver an immutable system where
internals are magically updated with all the latest developments and
fixes, except for all the latest developments that make any sort of
visible change because those require an administrator to work.


I think that if you have a requirement for an extremely stable
environment, to the point where network interface names matter,
then you need to take significant responsibility to *create* that
environment *yourself*. You can't really rely on distributions to
do that for you - that's not part of their value proposition.

I would suggest to leverage the fantastic Gentoo tools and portage,
in order to create your own distribution which suits your needs.

Open source is only ever successful when you own your problems.


//Peter

Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds

[Markos Chandras]

On 13 January 2013 18:06, hasufell  wrote:
> On 01/13/2013 07:03 PM, Zac Medico wrote:
>> On 01/13/2013 09:43 AM, hasufell wrote:
>>> On 01/13/2013 03:24 PM, Michał Górny wrote:
 Hello,
>>>
 Right now an attempt to commit an ebuild with no HOMEPAGE results
 in:
>>>
 HOMEPAGE.missing  1
 app-admin/eselect-sh/eselect-sh-0.4.ebuild
>>>
 Note: use --include-dev (-d) to check dependencies for 'dev'
 profiles
>>>
 Please fix these important QA issues first.
>>>
 Why is this considered an 'important QA issue'? Does the policy
 really say that if something doesn't have a homepage, we're
 supposed to put garbage in there?
>>>
>>>
>>>
>>> That is already lifted:
>>> https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-660007.2
>>>
>>> seems to be a repoman bug or just not yet implemented
>>
>> repoman is intended to enforce policies, which can be stricter than pms.
>> So, the question is, what is our policy going to be?
>
>
> +1 to allow empty/missing HOMEPAGE variable
>
> dead homepage => useless
> http://gentoo.org => useless
> https://bugs.gentoo.org => too obvious
>

An empty homepage usually means the package is dead. I'd rather see
the cvs/git/svn url being used as HOMEPAGE in case your tiny little
script has no proj page at all.

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

Re: [gentoo-dev] Clarify log message?

[Zac Medico]

On 01/14/2013 01:33 AM, Dirkjan Ochtman wrote:
> I've seen this pop up a lot recently:
> 
>  * One or more symlinks to directories have been preserved in order to
>  * ensure that files installed via these symlinks remain accessible. This
>  * indicates that the mentioned symlink(s) may be obsolete remnants of an
>  * old install, and it may be appropriate to replace a given symlink with
>  * the directory that it points to.
>  *
>  *  /var/run
>  *
> 
> This might just be me being dense, but this doesn't seem very
> actionable to me. Who should replace the given symlink with the
> directory that it points to, the user or the package maintainer?

It depends on who created the symlink in the first place, and whether or
not the symlink is still desirable. Unfortunately, there are a number of
possible scenarios.

You probably want to keep that /var/run symlink, at least until all of
your installed packages have been fixed to use /run directly. You can
suppress the warning by putting a setting like this in make.conf:

  UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /var/run"

That will prevent portage from trying to uninstall that symlink.

> And where should it be replaced? In ebuild code?

It's possible for ebuild code to do it, if appropriate for the given
scenario. For example, the skype ebuild removes an obsolete
"${EROOT}"/usr/share/${PN} symlink in pkg_preinst.
-- 
Thanks,
Zac

[gentoo-dev] Clarify log message?

[Dirkjan Ochtman]

I've seen this pop up a lot recently:

 * One or more symlinks to directories have been preserved in order to
 * ensure that files installed via these symlinks remain accessible. This
 * indicates that the mentioned symlink(s) may be obsolete remnants of an
 * old install, and it may be appropriate to replace a given symlink with
 * the directory that it points to.
 *
 *  /var/run
 *

This might just be me being dense, but this doesn't seem very
actionable to me. Who should replace the given symlink with the
directory that it points to, the user or the package maintainer? And
where should it be replaced? In ebuild code?

Cheers,

Dirkjan

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/13/2013 04:59 AM, Pacho Ramos wrote:
> El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
>> On 01/13/2013 04:18 AM, Pacho Ramos wrote:
>>> What about this approach?
>>
>> You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
>> don't care about the sub-slot and the slash would cause problems.
> 
> Thanks, updated eclass attached
> 

Here are a few problems I see with readme.gentoo_print_elog:

1) contains duplication of code

2)  [[ -f "${FILESDIR}/README.gentoo-${SLOT%/*}" ]] condition seems
wrong, shouldn't it just use [[ -f "${T}"/README.gentoo ]] since the
file was copied to "${T}"/README.gentoo iby readme.gentoo_create_doc?

3) [[ "${REPLACING_VERSIONS}:${SLOT%/*}" ]] condition seems wrong
because SLOT is always non-empty and that means the condition is always
true.

-- 
Thanks,
Zac