[gentoo-dev] Re: Portage sets support Was: Defaulting for debug information in profiles

[Duncan]

Zac Medico posted on Tue, 18 Dec 2012 09:58:42 -0800 as excerpted:

> It's important to clarify that, because /etc/portage/sets (aka GLEP 21
> User Sets) has already been supported in stable portage since 2.1.11.9
> [1].

I didn't know that.  Last I knew, stable portage had special-case 
acceptance of @system and @world to prepare the way, but I hadn't seen 
that full /etc/portage/sets/* and /var/lib/portage/world_sets support was 
stabilized.

If indeed it is as you say, I've even more to rejoice about! =:^)

And extended sets support... it'd be nice, but it's beyond the daily 
usage I so much depend on sets for, so personally, I see no big need for 
it, especially with all the extra complexity it'd bring.

Just to clarify, tho, for those who could use 'em (I don't, but the 
gentooers I help on the various lists would likely find them useful):  
Are sets such as @live-rebuild and @module-rebuild available in stable, 
so I can start mentioning them, or are they part of the "advanced sets 
support" you mention as not yet stabilized?

And... I thought I was already CCed on the bug (#235454) for this but 
apparently not.  If sets support is stable already, gentoo-bashcomp could 
really use portage tab-completion for sets.  =:^)

https://bugs.gentoo.org/show_bug.cgi?id=235454

(Unfortunately I've yet to wrap my head around actually programming bash's 
programmable completion functionality or I'd likely post the patches.  
The bug had idled for near two years until I just CCed myself.)

-- 
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] Moving our/portage stuff to var

[Joshua Saddler]

On Mon, 17 Dec 2012 11:19:20 +0100
Tomáš Chvátal  wrote:

> Currently we put portage into /usr/portage and all related stuff is to
> be in the subfolders there (distfiles, binpkg).
> 
> I've always myself override these defaults in make.conf to point for
> /var/portage/ (not /var/lib because I never bothered enough how to
> make world and config files to be put elsewhere :P).
> 
> The only reason why we have this currently in usr is that bsd ports
> put their stuff in there and I suppose Daniel just did the same.
> 
> With respect to reality how stuff is done in the linux land all the
> variable data should be in /var so we should adjust and move it in
> there too.
> 
> What would you think?

do it. stick it somewhere in /var. i have a small SLC SSD just for /var and 
/usr/portage partitions, since those consistently incur high writes. dropping 
to just one partition for all that i/o would be real nice.

if this proposed change is made, please make sure to contact the GDP. while we 
don't update things like manpages or elog announcements, we would have a ton of 
stuff to fix in gentoo.org/doc/en/ . also, make sure stuff is sorted out on the 
catalyst/releng end well in advance, so users aren't stuck with bad stages.


signature.asc
Description: PGP signature

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

[Jeroen Roovers]

On Mon, 17 Dec 2012 10:40:06 +0100
Michał Górny  wrote:

> > People aren't bothering. It's not because of any fundamental
> > problem -- it's because the process is obscure and potentially a
> > waste of time.
> 
> I agree with that. The process takes a lot of time for a minor
> benefit, and most of it doesn't prove really helpful. I think the
> process should mostly prove that someone is able to find and read
> docs, write ebuilds and understand the major concepts.

Please show me some numbers that prove your point about the recruitment process
having "little benefit".

> Honestly, I see no reason to ask recruits for a lot of things we do
> right now. There's no point in telling them to summarize a large piece
> of the docs. From my personal experience, there is a lot of things
> which you learn and then forget because you don't need them for a
> long time.

I could go all cynical here and give a few examples of how a couple of people
recently got through and actually managed to mess up a few very basic
things you would never contemplate quizzing them about.

But I would much rather see to it that those few bits get fixed, rather than
the even greater mess we would be in if everybody with the "right mindset" got
commit privileges. Since nobody's perfect, we already have enough work to do,
thank you.


 jer

Re: [gentoo-dev] RFC: change of the default value for EHG_REVISION (mercurial.eclass)

[Rafael Goncalves Martins]

On Tue, Dec 18, 2012 at 7:31 PM, Mike Gilbert  wrote:
> On Tue, Dec 18, 2012 at 4:10 PM, Christoph Junghans  wrote:
>> With nelchael's retirement I (with backup from djc) will take over the
>> maintenance of mercurial.eclass. As one of the first things I would
>> like to change the default value of EHG_REVISION.
>>
>> EHG_REVISION defines the revision/branch/tag to be checkout in src_unpack.
>> The current default is "tip", which identifies the most recent revision.
>> This can lead to unwanted branch changes (see
>> ) as the branch in
>> which tip resides is not fixed.
>> The new default should be "default", which is mercurial's default name
>> for the main branch.
>>
>> Looking at the packages using mercurial.eclass
>> () the
>> above change shouldn't cause any problems (some packages already use
>> EHG_REVISION="default" to avoid branch changes), but I will wait
>> another week before committing the change.
>>
>> --
>> Christoph Junghans
>> http://dev.gentoo.org/~ottxor/
>>
>
> Sounds good to me; using "tip" never made sense to me either.
>

+1

--
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/

Re: [gentoo-dev] Moving our/portage stuff to var

[Zac Medico]

On 12/18/2012 01:33 PM, Diego Elio Pettenò wrote:
> No /var/gentoo. No /var/repositories.
> 
> /var/db/gentoo, /var/db/repositories, /var/cache/portage ... as long as
> Zac is fine with one whatever, but let's not invent any new top-level.

Yeah, /var/db or /var/cache sounds good to me.

I would encourage all those interested to coordinate with the catalyst
developers to have the new defaults written in the make.conf that it
generates. Having the new defaults explicitly recorded there does not
require any changes to portage (though I will bring portage's internal
defaults into sync as soon as possible). Also, I think it might help
avoid confusion for users if they are able to see the new defaults
explicitly recorded in make.conf (as opposed to
/usr/share/portage/config/make.globals which is somewhat obscure).
-- 
Thanks,
Zac

Re: [gentoo-dev] Moving our/portage stuff to var

[Diego Elio Pettenò]

No /var/gentoo. No /var/repositories.

/var/db/gentoo, /var/db/repositories, /var/cache/portage ... as long as Zac
is fine with one whatever, but let's not invent any new top-level.

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



On Tue, Dec 18, 2012 at 10:20 PM, Florian D.  wrote:

> Am Mon, 17 Dec 2012 13:45:35 +0100
> schrieb Diego Elio Pettenò :
>
> > On 17/12/2012 13:42, Ulrich Mueller wrote:
> > > If we change the location, can we then move distfiles to some place
> > > outside of the tree? Something like:
> > >
> > >/var/cache/portage
> > >/var/cache/distfiles
> >
> > What I do on my systems is
> >
> > /var/cache/portage/tree
> > /var/cache/portage/distfiles
> >
>
> +1 for moving the location
>
> my suggestion:
>
> /var/gentoo/distfiles
> /var/gentoo/packages
> /var/gentoo/repositories
>
> /var/gentoo/repositories/layman
> /var/gentoo/repositories/portage
> .
> .
> this could be extended, like:
> /var/gentoo/repositories/sth_paludis_related
>
> It would be nice, if you'd adopted my scheme, then I don't need to change
> anything.. ;)
>
>

Re: [gentoo-dev] RFC: change of the default value for EHG_REVISION (mercurial.eclass)

[Mike Gilbert]

On Tue, Dec 18, 2012 at 4:10 PM, Christoph Junghans  wrote:
> With nelchael's retirement I (with backup from djc) will take over the
> maintenance of mercurial.eclass. As one of the first things I would
> like to change the default value of EHG_REVISION.
>
> EHG_REVISION defines the revision/branch/tag to be checkout in src_unpack.
> The current default is "tip", which identifies the most recent revision.
> This can lead to unwanted branch changes (see
> ) as the branch in
> which tip resides is not fixed.
> The new default should be "default", which is mercurial's default name
> for the main branch.
>
> Looking at the packages using mercurial.eclass
> () the
> above change shouldn't cause any problems (some packages already use
> EHG_REVISION="default" to avoid branch changes), but I will wait
> another week before committing the change.
>
> --
> Christoph Junghans
> http://dev.gentoo.org/~ottxor/
>

Sounds good to me; using "tip" never made sense to me either.

Re: [gentoo-dev] Moving our/portage stuff to var

[Florian D.]

Am Mon, 17 Dec 2012 13:45:35 +0100
schrieb Diego Elio Pettenò :

> On 17/12/2012 13:42, Ulrich Mueller wrote:
> > If we change the location, can we then move distfiles to some place
> > outside of the tree? Something like:
> > 
> >/var/cache/portage
> >/var/cache/distfiles
> 
> What I do on my systems is
> 
> /var/cache/portage/tree
> /var/cache/portage/distfiles
> 

+1 for moving the location

my suggestion:

/var/gentoo/distfiles
/var/gentoo/packages
/var/gentoo/repositories

/var/gentoo/repositories/layman
/var/gentoo/repositories/portage
.
.
this could be extended, like:
/var/gentoo/repositories/sth_paludis_related

It would be nice, if you'd adopted my scheme, then I don't need to change 
anything.. ;) 

[gentoo-dev] RFC: change of the default value for EHG_REVISION (mercurial.eclass)

[Christoph Junghans]

With nelchael's retirement I (with backup from djc) will take over the
maintenance of mercurial.eclass. As one of the first things I would
like to change the default value of EHG_REVISION.

EHG_REVISION defines the revision/branch/tag to be checkout in src_unpack.
The current default is "tip", which identifies the most recent revision.
This can lead to unwanted branch changes (see
) as the branch in
which tip resides is not fixed.
The new default should be "default", which is mercurial's default name
for the main branch.

Looking at the packages using mercurial.eclass
() the
above change shouldn't cause any problems (some packages already use
EHG_REVISION="default" to avoid branch changes), but I will wait
another week before committing the change.

--
Christoph Junghans
http://dev.gentoo.org/~ottxor/

Re: [gentoo-dev] Defaulting for debug information in profiles

[Pacho Ramos]

El lun, 17-12-2012 a las 08:55 -0500, Rich Freeman escribió:
[...]
> I usually keep a debug file in /etc/portage/env.d and symlink it to
> anything I'm working on.
> 
> Rich
> 
> 

I do the same, for example, I had end.d files for all evince related
packages to get proper backtraces as I was getting crashes from time to
time for some files


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

Re: [gentoo-dev] Moving our/portage stuff to var

[Rick "Zero_Chaos" Farina]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/18/2012 02:49 PM, Rick "Zero_Chaos" Farina wrote:
> On 12/18/2012 01:38 PM, Zac Medico wrote:
>> On 12/17/2012 02:19 AM, Tomáš Chvátal wrote:
>>> Currently we put portage into /usr/portage and all related stuff is to
>>> be in the subfolders there (distfiles, binpkg).
>>>
>>> I've always myself override these defaults in make.conf to point for
>>> /var/portage/ (not /var/lib because I never bothered enough how to
>>> make world and config files to be put elsewhere :P).
>>>
>>> The only reason why we have this currently in usr is that bsd ports
>>> put their stuff in there and I suppose Daniel just did the same.
>>>
>>> With respect to reality how stuff is done in the linux land all the
>>> variable data should be in /var so we should adjust and move it in
>>> there too.
>>>
>>> What would  you think?
> 
>> I like the idea. As noted in bug #378603 [1], I'd like the portage
>> ebuild to ensure that the locations don't unexpectedly change for
>> existing installs.
> 
>> Will it break catalyst? If so, we might begin the migration by fixing
>> catalyst and having to set the new default locations in the make.conf
>> that it generates.
> 
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=378603#c1
> 
> Yes, it will break catalyst.  However, if the folder that the portage
> tree goes in is still something/something/portage then it shouldn't be
> hard to fix.
> 
It should probably be mentioned (since most of us don't use the
snapshots every day) that the snapshots actually contain a folder called
"portage" in the tarball.  Not that it would be impossible to change,
but if we migrate from /usr/portage to /var/whatever/portage then the
changes are trivial, if we migrate to /var/repositories/gentoo that
makes things like unpacking the snapshots significantly non-trivial.

I really don't care what everyone wants to do here (although I'm
generally for sticking closer to FHS), but I warn that if the path
doesn't end in "portage" the changes are going to be significantly
non-trivial.

Thanks,
Zero

> -ZC
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ0MwqAAoJEKXdFCfdEflKF0YQAJ1mBkAPgDcIdXL+2eIdc5GO
yk7t2qSOtSaU159C8d2xI2AdB3b5jm5AXWrrvpAovNIAMTN/fFa781oKQVkFprsS
AZsT3UFluLep3ngLVTvpv8nry2t0AhT+/k1u1GAeurnTT5b4GDGXu7EF+QHzeaLC
+8VF8/N0TvRp+PwZ9lEJGXd+RVXxQ6AJXo1XsIbgKnA/L5mCKCfYn3o+9oQCqHbW
fPVeGyqEAKVYFG8rNUHwxPHYUvxhIC7xxuBl81ErXv5VqhcgNNjX4SMnKXeT3Z/V
FRxtnLJMz69mlX9C+CMf9boFVfveMjGj7pZOzopJGGhJM3d8Q/rAbgHejEmtrlAd
n9FBLc7ihGGBGGcTHrmhG+1DalmY/c2WaR63NfR+Le5mIpPpC0mibhK5TYeWRAcF
zFJhjmLwBfyAlBLnQk6gd4x/c8jMH68wgvRqPNMJbWETkT3tntgl7cUcoesv6TdT
fGNuISGCqMSEHHTKxX9XvqBl5EDSNEIS4I7rbFwO3qtuHuR2+88H506E9RQU4Xdd
+/bV6EW3Z7s/9hp7LhvK5CqEXAfJwN278aJOKAuyNX/YmwKa1VXy/ZDMXEUrTa6x
r+LcgyNHUkY3Sr4OFR7yoIY/oH4FrP1Y5H45GQUNje/XeL7bnLoN9h4QfeIwwt/L
6KZZtj3hmJa7I/m5hBwv
=VeR7
-END PGP SIGNATURE-

Re: [gentoo-dev] Moving our/portage stuff to var

[Rick "Zero_Chaos" Farina]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/18/2012 01:38 PM, Zac Medico wrote:
> On 12/17/2012 02:19 AM, Tomáš Chvátal wrote:
>> Currently we put portage into /usr/portage and all related stuff is to
>> be in the subfolders there (distfiles, binpkg).
>>
>> I've always myself override these defaults in make.conf to point for
>> /var/portage/ (not /var/lib because I never bothered enough how to
>> make world and config files to be put elsewhere :P).
>>
>> The only reason why we have this currently in usr is that bsd ports
>> put their stuff in there and I suppose Daniel just did the same.
>>
>> With respect to reality how stuff is done in the linux land all the
>> variable data should be in /var so we should adjust and move it in
>> there too.
>>
>> What would  you think?
> 
> I like the idea. As noted in bug #378603 [1], I'd like the portage
> ebuild to ensure that the locations don't unexpectedly change for
> existing installs.
> 
> Will it break catalyst? If so, we might begin the migration by fixing
> catalyst and having to set the new default locations in the make.conf
> that it generates.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=378603#c1
> 
Yes, it will break catalyst.  However, if the folder that the portage
tree goes in is still something/something/portage then it shouldn't be
hard to fix.

- -ZC
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ0MjSAAoJEKXdFCfdEflKTZ4P/2h5iKIGbNWhxAGkWEDRez31
YiCVUf5lJeDGAYpJ0hM20aWebzrR+HITqcKENKfGwerr+2/VeKVKsyYR8M1tNbQs
9jCNTMBfoYOEm8ElOu0Vzny5uWV3LflP0BMsnOjBDUpxw9ESXuz+54tkknsyEaLD
yBoVoe4zj4GfY/B3aXO08gqig/w7sGR3iLPyhy3iJimznK/qMszyMJ9LzCFVSmwz
zXVMoaM1VKTwVI7E/CZmxBWIF4KVoQ1fl4xJoqt4l82HK/5IDoRLu+s5c6rJLDhp
SPDsFQa+XtdHOZvaXhn+15zAcWFJm8UBdXtnfi8tJmpoukEJr3BscC9DRUCdRzbR
mzE0ptqDayoJ8tKuxUR+ppU987PPIAJ03h/X3yTWsIc7QPB1TtFI5W6mk4/iVPSy
FF9LrcxYvAM/+Cqu+LlhKIapqK+XAA7nw6txpEjiw3HcTZ+0O/GGHTlKM0gxbx0i
kMGe00zwodoN7DwGYenmulDk3eX71moZ/ioXMMNisDAazmcbOKOEXC/pmuUk342H
9oUtgYCH/PJGjdZHAlQnBwyfIP2YCNRZEnL6lN5t6V+p0XPzMB97tJCYsB2qEifx
m1qOPZhQX5dXovKJZyrs93SbpkUhMF8TXi6IsosVtAQFldRd2LJOawRBEkZzF2Yn
mn0gQl0ORyorOMEYsxbL
=lZrh
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: eudev project announcement

[Rich Freeman]

On Tue, Dec 18, 2012 at 1:45 PM, William Hubbs  wrote:
> On Tue, Dec 18, 2012 at 07:50:51AM +0100, Ulrich Mueller wrote:
>> > On Mon, 17 Dec 2012, William Hubbs wrote:
>>
>> > This all started with the April 2012 council meeting when it was
>> > pushed through that separate /usr without an initramfs is a
>> > supported configuration, so yes, the previous council started this
>> > issue.
>>
>> Sorry, but that's not an accurate account of what the council has
>> decided on. What we voted on in the April 2012 meeting was this:
>>
>> The question is: "Decide on whether a separate /usr is still
>>  a supported configuration."
>
> I know at least one council member who was at that meeting who would
> strongly disagree and say that what you voted for was that separate
> /usr, without an initramfs, is a supported configuration.

Does it really matter?  We're arguing over what the council decided
six months ago, and they never really took a clear vote (I see lots of
discussion, and no motion followed by aye/nay's).  I would certainly
recommend in the future that if the Council wants to set some kind of
policy that they make a clear statement of the policy followed by a
simple yes/no vote.  However, there is little value in going back over
that particular decision.

This whole thread really seems like a major waste of hot air.  Does it
really matter whether udev supports a separate /usr or not?  If your
system works, then good for you.  If it doesn't work, then install an
initramfs, or use something other than udev, and if that fixes your
probably great.  Just don't talk about it here, or you'll have 400
people telling you that you're wrong.

If you think that eudev is a big waste of time, then don't use it.

Rich

Re: [gentoo-dev] Re: eudev project announcement

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/12/12 01:45 PM, William Hubbs wrote:
> On Tue, Dec 18, 2012 at 07:50:51AM +0100, Ulrich Mueller wrote:
>>> On Mon, 17 Dec 2012, William Hubbs wrote:
>> 
>>> This all started with the April 2012 council meeting when it
>>> was pushed through that separate /usr without an initramfs is
>>> a supported configuration, so yes, the previous council started
>>> this issue.
>> 
>> Sorry, but that's not an accurate account of what the council
>> has decided on. What we voted on in the April 2012 meeting was
>> this:
>> 
>>  The question is: "Decide on whether a separate /usr is
>> still a supported configuration."
> 
> Ulrich,
> 
> I have read the log, and that is where the confusion is.
> 
> If that is true, and I think folks would beg to differ, we can say
> that the way separate /usr is supported is via requiring an
> initramfs and move forward from there because that would still be
> within the council's requirement since there is now documentation
> on how to build an initramfs.
> 
> I know at least one council member who was at that meeting who
> would strongly disagree and say that what you voted for was that
> separate /usr, without an initramfs, is a supported configuration.


There was at least one council member that said they would not accept
an initramfs solution as the only way to support separate-/usr, but
having also been there I believe the vote itself was still that
"separate /usr will be supported" period.

So yes, a proper initramfs solution including documentation would
suffice for this April meeting decision.  This however rolls forward
to the October council meeting and it's decision to wait and/or not
officially adopt a "separate-/usr is only supported through an
initramfs" policy.  (The decision at that meeting was rather
complicated so i'm not really trying to summarize it but rather just
reference that it happened)

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

iF4EAREIAAYFAlDQweAACgkQ2ugaI38ACPAApAD+JDWX90fnT3IL2aYitnLO8Kiz
JF9+0NxbDy3tr/gHeHkA/3WnBWrl14tsMQKyB5IlHv445BJFFouMKMQId4xznhEi
=bUdE
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: eudev project announcement

[William Hubbs]

On Tue, Dec 18, 2012 at 01:51:27PM -0500, Richard Yao wrote:
> On 12/18/2012 01:45 PM, William Hubbs wrote:
> > On Tue, Dec 18, 2012 at 07:50:51AM +0100, Ulrich Mueller wrote:
> >>> On Mon, 17 Dec 2012, William Hubbs wrote:
> >>
> >>> This all started with the April 2012 council meeting when it was
> >>> pushed through that separate /usr without an initramfs is a
> >>> supported configuration, so yes, the previous council started this
> >>> issue.
> >>
> >> Sorry, but that's not an accurate account of what the council has
> >> decided on. What we voted on in the April 2012 meeting was this:
> >>
> >> The question is: "Decide on whether a separate /usr is still
> >>  a supported configuration."
> >  
> > Ulrich,
> > 
> >  I have read the log, and that is where the confusion is.
> > 
> >  If that is true, and I think folks would beg to differ, we can say that
> >  the way separate /usr is supported is via requiring an initramfs and
> >  move forward from there because that would still be within the
> >  council's requirement since there is now documentation on how to build
> >  an initramfs.
> > 
> > I know at least one council member who was at that meeting who would
> > strongly disagree and say that what you voted for was that separate
> > /usr, without an initramfs, is a supported configuration.
> > 
> > Thoughts?
> > 
> > William
> > 
> 
> Our official documentation for LVM2 explicitly advised users to use such
> configurations. Dropping support now will break existing systems
> unnecessarily.
> 
> Before anyone says to use a news item, let me say that publishing a news
> item to inform users that we decided to break their systems will not
> make it better.

I don't follow. The initramfs document [1] clearly points out that if
you have lvm you have to include it when you run genkernel, and we can't
move forward until a proper version of genkernel is stable.

William

[1] http://www.gentoo.org/doc/en/initramfs-guide.xml


pgphCRtt64DZx.pgp
Description: PGP signature

Re: [gentoo-dev] Re: eudev project announcement

[Richard Yao]

On 12/18/2012 01:45 PM, William Hubbs wrote:
> On Tue, Dec 18, 2012 at 07:50:51AM +0100, Ulrich Mueller wrote:
>>> On Mon, 17 Dec 2012, William Hubbs wrote:
>>
>>> This all started with the April 2012 council meeting when it was
>>> pushed through that separate /usr without an initramfs is a
>>> supported configuration, so yes, the previous council started this
>>> issue.
>>
>> Sorry, but that's not an accurate account of what the council has
>> decided on. What we voted on in the April 2012 meeting was this:
>>
>> The question is: "Decide on whether a separate /usr is still
>>  a supported configuration."
>  
> Ulrich,
> 
>  I have read the log, and that is where the confusion is.
> 
>  If that is true, and I think folks would beg to differ, we can say that
>  the way separate /usr is supported is via requiring an initramfs and
>  move forward from there because that would still be within the
>  council's requirement since there is now documentation on how to build
>  an initramfs.
> 
> I know at least one council member who was at that meeting who would
> strongly disagree and say that what you voted for was that separate
> /usr, without an initramfs, is a supported configuration.
> 
> Thoughts?
> 
> William
> 

Our official documentation for LVM2 explicitly advised users to use such
configurations. Dropping support now will break existing systems
unnecessarily.

Before anyone says to use a news item, let me say that publishing a news
item to inform users that we decided to break their systems will not
make it better.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: eudev project announcement

[William Hubbs]

On Tue, Dec 18, 2012 at 07:50:51AM +0100, Ulrich Mueller wrote:
> > On Mon, 17 Dec 2012, William Hubbs wrote:
> 
> > This all started with the April 2012 council meeting when it was
> > pushed through that separate /usr without an initramfs is a
> > supported configuration, so yes, the previous council started this
> > issue.
> 
> Sorry, but that's not an accurate account of what the council has
> decided on. What we voted on in the April 2012 meeting was this:
> 
> The question is: "Decide on whether a separate /usr is still
>  a supported configuration."
 
Ulrich,

 I have read the log, and that is where the confusion is.

 If that is true, and I think folks would beg to differ, we can say that
 the way separate /usr is supported is via requiring an initramfs and
 move forward from there because that would still be within the
 council's requirement since there is now documentation on how to build
 an initramfs.

I know at least one council member who was at that meeting who would
strongly disagree and say that what you voted for was that separate
/usr, without an initramfs, is a supported configuration.

Thoughts?

William



pgpqbJ1r810A0.pgp
Description: PGP signature

Re: [gentoo-dev] Moving our/portage stuff to var

[Zac Medico]

On 12/17/2012 02:19 AM, Tomáš Chvátal wrote:
> Currently we put portage into /usr/portage and all related stuff is to
> be in the subfolders there (distfiles, binpkg).
> 
> I've always myself override these defaults in make.conf to point for
> /var/portage/ (not /var/lib because I never bothered enough how to
> make world and config files to be put elsewhere :P).
> 
> The only reason why we have this currently in usr is that bsd ports
> put their stuff in there and I suppose Daniel just did the same.
> 
> With respect to reality how stuff is done in the linux land all the
> variable data should be in /var so we should adjust and move it in
> there too.
> 
> What would  you think?

I like the idea. As noted in bug #378603 [1], I'd like the portage
ebuild to ensure that the locations don't unexpectedly change for
existing installs.

Will it break catalyst? If so, we might begin the migration by fixing
catalyst and having to set the new default locations in the make.conf
that it generates.

[1] https://bugs.gentoo.org/show_bug.cgi?id=378603#c1
-- 
Thanks,
Zac

Re: [gentoo-dev] Moving our/portage stuff to var

[Zac Medico]

On 12/17/2012 02:19 AM, Tomáš Chvátal wrote:
> Currently we put portage into /usr/portage and all related stuff is to
> be in the subfolders there (distfiles, binpkg).
> 
> I've always myself override these defaults in make.conf to point for
> /var/portage/ (not /var/lib because I never bothered enough how to
> make world and config files to be put elsewhere :P).
> 
> The only reason why we have this currently in usr is that bsd ports
> put their stuff in there and I suppose Daniel just did the same.
> 
> With respect to reality how stuff is done in the linux land all the
> variable data should be in /var so we should adjust and move it in
> there too.
> 
> What would  you think?

I like the idea. As noted in bug #378603 [1], I'd like the portage
ebuild to ensure that the locations don't unexpectedly change for
existing installs.

Will it break catalyst? If so, we might begin the migration by fixing
catalyst and having to set the new default locations in the make.conf
that it generates.

[1] https://bugs.gentoo.org/show_bug.cgi?id=378603#c1
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: eudev project announcement

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 17/12/12 06:23 PM, William Hubbs wrote:
> On Mon, Dec 17, 2012 at 01:31:59PM -0800, Greg KH wrote:
>> 
>> Can this topic finally be put to rest please?  There is a whole
>> web page devoted to this topic, why do people blindly ignore it?
> 
> This is a very good question.

Please!

(that is, after this final clarification of the eudev team's stance)


> 
> Also, yes, eudev believes they will be able to fix it.

No.

1 - The developers of eudev (at least some of us) believe we can push
to at least try and get the various separate-/usr issues fixed via
bugs and patches to the packages that cause them.

2 - Eudev developers believe we can ensure that there is a *udev* that
supports separate-/usr without initramfs.[**]  This doesn't mean that
we think there is any way for udev to fix the whole separate-/usr
issue, but we certainly know that udev can be configured to not cause
it on its own.

3 - There are still many system configurations that have no issues
running with separate-/usr, despite the potential for bugs or
conflicts to occur.  Via #2 we intend to easily allow systems with
such configurations to continue doing it their way.


To summarize, the eudev team knows that breakages caused by
separate-/usr without an initramfs are not trivial and are not
something that changes in eudev will magically fix.  Further, we
acknowledge that separate-/usr support in systemd-udev isn't "broken"
in specific binary terms, either (although the gentoo packages of
~sys-fs/udev-185 through 196-r1 are; sys-fs/udev packaging choices
isn't a conversation we need to re-hash either though).

So I hope the above alleviates the concerns of GregKH, WilliamH and
other respected developers, that the eudev team really is aware of the
complexity of the issues and do not have their heads stuck in the
clouds regarding separate-/usr support.

- ---

** the eudev codebase does need something to compensate for the
removal of the failed rules queue, as that was the method that used to
be leveraged to handle re-running rules that needed something in /usr
when /usr wasn't available.  This is part of what differentiates eudev
from systemd-udev, as this codepatch would most likely fall into the
category of "exotic configurations" for which systemd plans to reject
patches.

For more eudev-specific discussion, especially development or
technical discussions, please join us on eu...@gentoo.org rather than
- -dev@

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

iF4EAREIAAYFAlDQsNQACgkQ2ugaI38ACPBJ7wD9H9x4olYqGM9OhcL1Xmi07F8O
vWjadBlDyruC4YiTJqcA/jwd+YxNMSB2CA/0XWVD88aOzkJUJs3LK6lT/owIOeFg
=1OT9
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage sets support Was: Defaulting for debug information in profiles

[Zac Medico]

On 12/18/2012 12:26 AM, Duncan wrote:
> Zac Medico posted on Mon, 17 Dec 2012 23:31:24 -0800 as excerpted:
> 
>> On 12/17/2012 09:59 PM, Duncan wrote:
> 
>>> [1] I long ago filed a bug suggesting a new world-sets line for
>>> depclean,
>>> but I expect it'll be resolved/fixed about the time sets support
>>> finally gets unmasked to ~arch, the status of which looks about like
>>> the tree's git conversion status... in practice, target "bluesky".  I
>>> guess these are gentoo's Duke Nukem' Forever projects.
>>
>> Fixed now:
>>
>>  https://bugs.gentoo.org/show_bug.cgi?id=298298
>>
>> It was a lot easier than the git conversion. ;-p
> 
> Hurray! =:^)
> 
> FWIW, I guess I wasn't as clear in my post as I was in my head, but what 
> I /intended/ to compare to the git conversion was sets support in at 
> least ~arch-unmasked portage.  I've been eagerly awaiting both the git 
> tree conversion and sets support that ordinary users (at least in ~arch) 
> can use without unmasking, but both are complicated as much by the 
> political issues as the technical ones, so it's not as simple as just 
> hammering down on the technical issues and getting it done; the political 
> issues simply take /time/.

I guess you're talking about extended set configuration via
/etc/portage/sets, /usr/share/portage/config/sets/, and
$PORTDIR_OVERLAY/sets.conf?

It's important to clarify that, because /etc/portage/sets (aka GLEP 21
User Sets) has already been supported in stable portage since 2.1.11.9 [1].

> This particular bug was taking some time too, but I wasn't worried about 
> it since I knew I was using a masked portage and it was n/a everywhere 
> else.  I figured it'd be fixed eventually, as I said, about the time sets 
> support got unmasked to ~arch.
> 
> But with luck, that's about to happen too, and I was right.  Should I be 
> on the lookout for flying pigs too?  =:^)
> 
> Seriously, from your perspective, what /is/ the status on ~arch sets 
> support?  I know I've not had any technical issues in that regard in 
> /ages/, but I believe the original political problem was that portage's 
> implementation of sets differed from that of paludis, and the idea was to 
> standardize on something that could be used by both, possibly covered by 
> PMS, so sets could be distributed in the tree, etc.  And not being on the 
> PMS list and not having seen anything on it here, I'm not sure if there 
> has been any movement at all in that regard or not.  And if not, is it 
> even practical to thing it could still happen?  And if standardization 
> isn't practical, will the feature eventually be introduced, or dropped, 
> and if the plan is still to introduce it, is it something you believe you 
> can do right away as a portage update, or do you believe you need council 
> blessing for it, or?

Before we had EAPI 5 sub-slots and slot-operators [1], there was a real
danger of people over-using sets to trigger rebuilds, rather than doing
it properly with sub-slots and slot-operators. Now that sub-slot and
slot-operator support has been deployed in EAPI 5, it will be much
easier to deter people from misusing sets like that.

Therefore, it's now safer to consider enabling extended set
configuration in stable portage. However, I'm not sure how useful
extended set configuration really is. Maybe /etc/portage/sets is all
that people really want/need.

> I guess if you're bothering to commit depclean summary changes to support 
> sets, as you just did, the feature isn't on the cutting block yet, which 
> is a good sign, but I'd still like to be able to share sets with people 
> without worrying about explaining the concept and that support for it is 
> available but is still masked, every time.  Is that something that I can 
> realistically expect to be able to do by say, the end of 2013, or not?

As mentioned, /etc/portage/sets is supported in stable portage [1], so
the depclean summary fix applies to stable portage. So, it doesn't
necessarily imply that extended set configuration is not on the cutting
block.

[1] https://bugs.gentoo.org/show_bug.cgi?id=6411
[2] http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators
-- 
Thanks,
Zac

Re: [gentoo-dev] Defaulting for debug information in profiles

[viv...@gmail.com]

Il 17/12/2012 11:11, Tomáš Chvátal ha scritto:

Hi lads,
lately I am having bit of problems from getting relevant debug info from users.

Since we already have splitdebug for quite time (and I suppose quite
few of us are using it) how about making it to default profiles
default enabled and add -g to default cflags. Currently it is only
enabled in the developer profile.

This results in 2 gb data in /usr/lib/debug for my system which is not
that bad with current disk sizes and it saves users quite some time
when i have to request them to recompile half of their system with
debug info just to get idea how to fix their issue.

I would go even for compressdebug feature but that one needs more time
as some packages like glibc fails to merge with it and you need newer
gdb to work with it.

Cheers

Tom



By the way gcc-4.8 will have support for -gsplit-dwarf, should be 
something similar to split-debug, just done pre linking and with 
different file names.
While I've no idea how this feature work, probably start planning would 
be beneficial.


   -gsplit-dwarf
   Separate as much dwarf debugging information as possible into a 
separate output file with the extension .dwo.
   This option allows the build system to avoid linking files with 
debug information.
   To be useful, this option requires a debugger capable of reading 
.dwo files.




Also thinking about this a bit more, seem a binpkg for debug stuff can 
be interesting, similarly to how binary distro do.

rogue example implementation:
with FEATURE="buildpkg split-debug-pkg"
all the /usr/lib/debug and /usr/src/debug files are put in a separate 
package debug/category/pn or similarly to sec-policy/selinux* debug/cat--pn
the user can then install debug packages at will, the dependancies 
should work (and clone those of the real package) but not be mandatory.


how difficult would be to implement this in portage (keep in mind that 
packages are coupled and should stay that way also for unmerge and 
whatever)?

Would be possible to have FEATURE=" -buildpkg  split-debug-pkg"?

A similar feature would be useful for linguas support but more difficult 
to implement.

Re: [gentoo-dev] Defaulting for debug information in profiles

[Marcin Mirosław]

W dniu 18.12.2012 13:03, Sven Eden pisze:
> Am Dienstag, 18. Dezember 2012, 12:43:55 schrieb Marcin Mirosław:
>> W dniu 18.12.2012 12:13, Sven Eden pisze:
> 
> (snip, because this has nothing to do with the previous discussion.)
> 
   On my 32-bit machines I have...

 FLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
 -fno-unwind-tables -fno-asynchronous-unwind-tables" CXXFLAGS="${CFLAGS}"

   See http://comments.gmane.org/gmane.linux.busybox/36695 for why I

 include "-fno-unwind-tables -fno-asynchronous-unwind-tables".  Would I
 have to rebuild system and world without...

 -fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables

 ...to have debug data available?
>>>
>>> No, you haven't, if you have compiled everything with "-g" or "-ggdb".
>>>
>>> According to the web page you linked, the DWARF-2 tables are then written
>>> into the .debug files. Without -g/-ggdb, they are stripped and no longer
>>> available for debugging.
>>>
>>> So according to your CFLAGS, you'd have to rebuild everything, yes, but a
>>> simple "-g" would do.
>>>
>>> Oh, and "splitdebug" in "FEATURES" would be a good idea, too! ;)
>>
>> Hi Sven!
>> Meseems you are not right, please look at it:
>> $ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
>>
>> |grep "unwind\|-g"
>>
>>   [   1e2]  -grecord-gcc-switches
>>   [   1f8]  -ggdb
>>   [   202]  -frecord-gcc-switches
>> $ size /usr/bin/sqlite3
>>textdata bss dec hex filename
>>   445454124 328   48997bf65 /usr/bin/sqlite3
>>
>>
>> And with -fno-unwind...
>> $ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
>>
>> |grep "unwind\|-g"
>>
>>   [   1e2]  -grecord-gcc-switches
>>   [   1f8]  -ggdb
>>   [   202]  -frecord-gcc-switches
>>   [   218]  -fno-unwind-tables
>>   [   22b]  -fno-asynchronous-unwind-tables
>> $ size /usr/bin/sqlite3
>>textdata bss dec hex filename
>>   427134124 328   47165b83d /usr/bin/sqlite3
>>
>> As you can see I have splitdebug turned on.
>> Marcin
> 
> Hi Marcin,

Hi Sven!

> I am not right with what? All I did was interpreting a quoted link. And what 
> is this supposed to mean? So /usr/bin/sqlite3 looses size. Yes. This goes 
> along with the quoted link. But did you compare the current size of 
> /usr/lib64/debug/usr/bin/sqlite3.debug before and after?

My fault, I didn't respond below correct paragraph. I was thinking about:
>>> According to the web page you linked, the DWARF-2 tables are then written 
>>> into 
>>> the .debug files. Without -g/-ggdb, they are stripped and no longer 
>>> available 
>>> for debugging.

I tried to show that without "-g/-ggdb" gcc generates DWARF-2 tables and
strip doesn't remove it from binaries. I pasted examples with sqlite3
compiles with "-ggdb" but I'm getting the same results without debug
flags. When I add -fno-unwind-tables and -fno-asynchronous-unwind-tables
I'm getting smaller size of "text" (and all binary also).
And I agree with all you write about recompiling system with "-g" and
splitdebug.
Hmm, now I think you was thinking only about adding debug information to
Walters' gentoo and didn't want to talk about growing eh_frame...

> Sorry for any inconvenience, but I assure you, I have absolutly no idea what 
> you intent to show.

I hope I throwed some light on my earlier answer.
regards,
Marcin

Re: [gentoo-dev] Defaulting for debug information in profiles

[Sven Eden]

Am Dienstag, 18. Dezember 2012, 12:43:55 schrieb Marcin Mirosław:
> W dniu 18.12.2012 12:13, Sven Eden pisze:

(snip, because this has nothing to do with the previous discussion.)

> >>   On my 32-bit machines I have...
> >>
> >> FLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
> >> -fno-unwind-tables -fno-asynchronous-unwind-tables" CXXFLAGS="${CFLAGS}"
> >>
> >>   See http://comments.gmane.org/gmane.linux.busybox/36695 for why I
> >>
> >> include "-fno-unwind-tables -fno-asynchronous-unwind-tables".  Would I
> >> have to rebuild system and world without...
> >>
> >> -fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables
> >>
> >> ...to have debug data available?
> >
> > No, you haven't, if you have compiled everything with "-g" or "-ggdb".
> >
> > According to the web page you linked, the DWARF-2 tables are then written
> > into the .debug files. Without -g/-ggdb, they are stripped and no longer
> > available for debugging.
> >
> > So according to your CFLAGS, you'd have to rebuild everything, yes, but a
> > simple "-g" would do.
> >
> > Oh, and "splitdebug" in "FEATURES" would be a good idea, too! ;)
>
> Hi Sven!
> Meseems you are not right, please look at it:
> $ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
>
> |grep "unwind\|-g"
>
>   [   1e2]  -grecord-gcc-switches
>   [   1f8]  -ggdb
>   [   202]  -frecord-gcc-switches
> $ size /usr/bin/sqlite3
>textdata bss dec hex filename
>   445454124 328   48997bf65 /usr/bin/sqlite3
>
>
> And with -fno-unwind...
> $ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
>
> |grep "unwind\|-g"
>
>   [   1e2]  -grecord-gcc-switches
>   [   1f8]  -ggdb
>   [   202]  -frecord-gcc-switches
>   [   218]  -fno-unwind-tables
>   [   22b]  -fno-asynchronous-unwind-tables
> $ size /usr/bin/sqlite3
>textdata bss dec hex filename
>   427134124 328   47165b83d /usr/bin/sqlite3
>
> As you can see I have splitdebug turned on.
> Marcin

Hi Marcin,

I am not right with what? All I did was interpreting a quoted link. And what
is this supposed to mean? So /usr/bin/sqlite3 looses size. Yes. This goes
along with the quoted link. But did you compare the current size of
/usr/lib64/debug/usr/bin/sqlite3.debug before and after?

Sorry for any inconvenience, but I assure you, I have absolutly no idea what
you intent to show.

Sincerly

Sven

--
http://pwxlib.sourceforge.net

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

Re: [gentoo-dev] Defaulting for debug information in profiles

[Marcin Mirosław]

W dniu 18.12.2012 12:13, Sven Eden pisze:
> Am Montag, 17. Dezember 2012, 11:48:12 schrieb Walter Dnes:
>> On Mon, Dec 17, 2012 at 01:37:27PM +0100, Sven Eden wrote
>>
>>> 1) --- kde-base/kate
>>> -
>>>
>>> Compiled with -ggdb in CFLAGS:
>>>  # sum=0; for file in $(equery f kde-base/kate | grep "\.debug") ; do
>>>
>>> xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum"
>>> 32652140
>>>
>>> Compiled with -g in CFLAGS:
>>>  # sum=0; for file in $(equery f kde-base/kate | grep "\.debug") ; do
>>>
>>> xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum"
>>> 32652140
>>>
>>> Result: No size change at all.
>>>
>>>
>>> 2) --- dev-libs/lzo
>>> -
>>>
>>> Compiled with -ggdb in CFLAGS:
>>>  # sum=0; for file in $(equery f dev-libs/lzo | grep "\.debug") ; do
>>>
>>> xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum"
>>> 558664
>>>
>>> Compiled with -g in CFLAGS:
>>>  # sum=0; for file in $(equery f dev-libs/lzo | grep "\.debug") ; do
>>>
>>> xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum"
>>> 558304
>>>
>>>
>>> Result: A difference of 260 bytes or 0.06%. Far away from the assumed
>>> 300%.
>>>
>>>
>>> Conclusion:
>>> I do not doubt that -ggdb adds size. It does. And maybe, if I did an
>>> emerge -e @world would reduce the size used on my system between 30% and
>>> 40%. But not about 66% like assumed.
>>>
>>>
>>> However, even if it where "around 5-6" G, it would be thrice the initial
>>> assumption of 2G. And that's the whole point.
>>
>>   On my 32-bit machines I have...
>>
>> FLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
>> -fno-unwind-tables -fno-asynchronous-unwind-tables" CXXFLAGS="${CFLAGS}"
>>
>>   See http://comments.gmane.org/gmane.linux.busybox/36695 for why I
>> include "-fno-unwind-tables -fno-asynchronous-unwind-tables".  Would I
>> have to rebuild system and world without...
>>
>> -fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables
>>
>> ...to have debug data available?
> 
> No, you haven't, if you have compiled everything with "-g" or "-ggdb".
> 
> According to the web page you linked, the DWARF-2 tables are then written 
> into 
> the .debug files. Without -g/-ggdb, they are stripped and no longer available 
> for debugging.

> So according to your CFLAGS, you'd have to rebuild everything, yes, but a 
> simple "-g" would do.
> 
> Oh, and "splitdebug" in "FEATURES" would be a good idea, too! ;)

Hi Sven!
Meseems you are not right, please look at it:
$ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
|grep "unwind\|-g"
  [   1e2]  -grecord-gcc-switches
  [   1f8]  -ggdb
  [   202]  -frecord-gcc-switches
$ size /usr/bin/sqlite3
   textdata bss dec hex filename
  445454124 328   48997bf65 /usr/bin/sqlite3


And with -fno-unwind...
$ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
|grep "unwind\|-g"
  [   1e2]  -grecord-gcc-switches
  [   1f8]  -ggdb
  [   202]  -frecord-gcc-switches
  [   218]  -fno-unwind-tables
  [   22b]  -fno-asynchronous-unwind-tables
$ size /usr/bin/sqlite3
   textdata bss dec hex filename
  427134124 328   47165b83d /usr/bin/sqlite3

As you can see I have splitdebug turned on.
Marcin

Re: [gentoo-dev] Re: College Course in Gentoo Development

[Kevin Chadwick]

> People simply don't seem to realize that you can go away and 
> do something else while all that's happening

Like servers I prefer build machines to be more secure dedicated build
machines without a browser or X, so I expect it's a bit of a barrier
for me.

Having said that I haven't found the time to see how much time and
resources are involved compared to Sabayon and how often yet whilst
using libreoffice binaries.

-- 
___

'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] Defaulting for debug information in profiles

[Sven Eden]

Am Montag, 17. Dezember 2012, 11:48:12 schrieb Walter Dnes:
> On Mon, Dec 17, 2012 at 01:37:27PM +0100, Sven Eden wrote
> 
> > 1) --- kde-base/kate
> > -
> > 
> > Compiled with -ggdb in CFLAGS:
> >  # sum=0; for file in $(equery f kde-base/kate | grep "\.debug") ; do
> > 
> > xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum"
> > 32652140
> > 
> > Compiled with -g in CFLAGS:
> >  # sum=0; for file in $(equery f kde-base/kate | grep "\.debug") ; do
> > 
> > xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum"
> > 32652140
> > 
> > Result: No size change at all.
> > 
> > 
> > 2) --- dev-libs/lzo
> > -
> > 
> > Compiled with -ggdb in CFLAGS:
> >  # sum=0; for file in $(equery f dev-libs/lzo | grep "\.debug") ; do
> > 
> > xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum"
> > 558664
> > 
> > Compiled with -g in CFLAGS:
> >  # sum=0; for file in $(equery f dev-libs/lzo | grep "\.debug") ; do
> > 
> > xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum"
> > 558304
> > 
> > 
> > Result: A difference of 260 bytes or 0.06%. Far away from the assumed
> > 300%.
> > 
> > 
> > Conclusion:
> > I do not doubt that -ggdb adds size. It does. And maybe, if I did an
> > emerge -e @world would reduce the size used on my system between 30% and
> > 40%. But not about 66% like assumed.
> > 
> > 
> > However, even if it where "around 5-6" G, it would be thrice the initial
> > assumption of 2G. And that's the whole point.
> 
>   On my 32-bit machines I have...
> 
> FLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
> -fno-unwind-tables -fno-asynchronous-unwind-tables" CXXFLAGS="${CFLAGS}"
> 
>   See http://comments.gmane.org/gmane.linux.busybox/36695 for why I
> include "-fno-unwind-tables -fno-asynchronous-unwind-tables".  Would I
> have to rebuild system and world without...
> 
> -fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables
> 
> ...to have debug data available?

No, you haven't, if you have compiled everything with "-g" or "-ggdb".

According to the web page you linked, the DWARF-2 tables are then written into 
the .debug files. Without -g/-ggdb, they are stripped and no longer available 
for debugging.

So according to your CFLAGS, you'd have to rebuild everything, yes, but a 
simple "-g" would do.

Oh, and "splitdebug" in "FEATURES" would be a good idea, too! ;)

Sincerly

Sven


-- 
http://pwxlib.sourceforge.net

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

Re: [gentoo-dev] College Course in Gentoo Development

[Richard Yao]

On 12/17/2012 07:46 PM, Anthony G. Basile wrote:
>>
>> 2. Write an ebuild for the project above, maintained in an overlay
>> (also on GitHub), with sources fetched from GitHub. Add some small
>> patch to configure.ac in the ebuild. Add USE flags. Add "make check"
>> support to the build system, test with FEATURES=test. Many
>> ebuild-related tasks can be easily added (e.g. installing init.d
>> scripts).
> 
> This would be totally new to them but I agree that's a good idea.  I
> don't know about GitHub.  Can you delete projects from it when you're
> done because I don't want to polute GitHub with lots of unpolished stuff.

You can.

>>
>> 3. Take an old-version ebuild for a project with a known bug, fetch
>> the relevant git tag, and bisect to find the bug. Prepare a patch,
>> describe patch submission process.
> Hmm ... I didn't think of this but I could do that with the kernel on
> virtual machines.

You might want a userland program to avoid having to do reboots. I
suppose git itself could be a good candidate for this.

>>
>> Wrt. subjects covered, will you cover sandboxing, installing to image
>> vs. merging to live system, etc.? I would expect students to like such
>> stuff.
>>
> At some point I would have to cover that.  Like when I got over the
> phases of emerging, stepping through them with ebuild.
> 

You make me wish that this class was available when I was doing my
undergraduate degree. I had to learn this on my own.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] College Course in Gentoo Development

[Richard Yao]

On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
> Hi everyone,
> 
> Give the talk on the list about attracting devs, I've should probably
> mention that I'm teaching a College Course on Gentoo Development next
> semester.  I know two students will most likely go through the
> recruitment process, others may at least contribute.  So its like GSoC
> but the focus is not one project but an overview of general gentoo
> development, and I will have to touch on lots of stuff outside of gentoo
> per se, like how autotools and other build systems work.
> 
> So what should I teach?  Here's what I've got off the top of my head:
> 
> 1. Open source communities and Gentoo's internal political structure.
> 
> 2. Building a gentoo system, ie the handbook.  Gentoo as metadistribution.
> 
> 3. Delivering the goods: code -> build system -> portage -> compiled
> goodies -> working system
> 
> 4. How to work with gnu autotools.  Writing a build system.
> 
> 5.  How to write ebuilds, ie the dev manual.  How to work with cvs and git.
> 
> 6. Arches, arch testing.  Profiles.
> 
> 7. Building stages.  Catalyst.
> 
> Somewhere in there I'll squeeze in Gentoo's "alt" factor: alternative c
> libs, alternative compilers and hardening, alternative kernels, prefixes.
> 
> Please comment.  If it gets systematized enough, it can be a guide to
> future devs too.  Everything will be creative commons.
> 

You might want to have a lecture about software licensing.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Attracting developers (Re: Packages up for grabs...)

[Duncan]

Markos Chandras posted on Tue, 18 Dec 2012 08:44:23 + as excerpted:

> Nowadays, I use google docs ( and I am also open to g+ and skype
> interviews as well ). So IRC is not an absolute requirement.

Thanks.  Good to know.

-- 
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] Moving our/portage stuff to var

[Ultrabug]

On 17/12/2012 13:15, Dirkjan Ochtman wrote:

On Mon, Dec 17, 2012 at 11:23 AM, Diego Elio Pettenò
 wrote:

I would say let's work on that so that portage can keep them there.
Although I'm more for /var/cache/portage myself, as both distfiles and
tree can be re-generated.


+1.

Cheers,

Dirkjan



+1

Ultra

Re: [gentoo-dev] Re: eudev project announcement

[Richard Yao]

On 12/17/2012 06:23 PM, William Hubbs wrote:
> On Mon, Dec 17, 2012 at 01:31:59PM -0800, Greg KH wrote:
>> On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:
>>> Olav Vitters  wrote:
>>>
 On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
> As I said in an earlier email, Lennart Poettering claims that it does
> not work. We are discussing some of the things necessary to make it
 work.

 Just to repeat:
 In this thread it was claimed that a separate /usr is not supported by
 systemd/udev.

 A case which works with latest systemd on various distributions. I
 checked with upstream (not Lennart), and they confirmed it works. I can
 wait for Lennart to say the same, but really not needed.

 I assume this will again turn into a "but I meant something else".
>>>
>>> Olav.
>>>
>>> Lennart has stated that he considers a seperate /usr without init* broken.
>>
>> Yes, as do I, and so do a lot of other developers.
>>
>> But that is a system configuration issue, not a systemd issue, please
>> don't confuse the two.
>>
>>> This has worked correctly in the past.
>>
>> Define "past" please.
>>
>> Note, it's still broken, I have yet to see any upstream fixes to resolve
>> all of the issues that are involved here with "fixing" this up.
>>
>> Yes, as always, for some subset of users, you can be lucky and it will
>> work for them, but those systems are getting rarer and rarer these days,
>> as the rest of upstream (not systemd here) are moving on and not doing
>> anything to change their behavior for this topic.
>>
>>> The direction udev development is going, according to Lennart, is to
>>> make that impossible and he refuses to fix this regression.
>>
>> Again, this has NOTHING to do with udev or systemd, as has been pointed
>> out numerous times.  I understand your _wish_ that it would have
>> something to do with it, but that will not change the facts, sorry.
>>
>>> I am really happy with this project and intend on testing it once
>>> requests for this appear in the eudev mailing list.
>>
>> Good luck, the root problems still remain, and nothing that eudev ever
>> does can resolve that, sorry.
>>
>> Can this topic finally be put to rest please?  There is a whole web page
>> devoted to this topic, why do people blindly ignore it?
>  
>  This is a very good question.
> 
>> Again, a separate /usr without an initrd has NOTHING to do with systemd
>> or udev, with the minor exception that Gentoo's packaging of those
>> programs _might_ have an issue, but that is Gentoo's issue, NOT
>> upstream's issue.
>>
>> If anyone involved with eudev, or is involved with the Gentoo Council
>> thinks that the previous paragraph is incorrect, they are flat out
>> wrong.
>  
> This all started with the April 2012 council meeting when it was pushed
> through that separate /usr without an initramfs is a supported
> configuration, so yes, the previous council started this issue.
> 
> Also, yes, eudev believes they will be able to fix it.
> 
> I am another one who has been pointing out how this is wrong multiple
> times but my statements about it are falling on deaf ears.
> 
> William
> 

I have also explained how we can fix this multiple times and I can say
that my explanations have been ignored. The eudev project's solution to
this can be summarized in the few sentences that I said in a response to
gregkh (after you wrote your email):

>I reject
>the notion that there be a single rules directory. That opens the door
>to having a second directory on /usr that enforce the requirement that
>rules that depend on /usr execute after /usr is mounted.

The only argument that has been made against it involves libraries that
cross the /usr boundary. I consider such situations to be avoidable.
There has been no other argument made against this approach and I am
quite confident that it is sound. Furthermore, it satisfies the request
of various users to support a separate /usr mount without an initramfs.
Satisfying that seems to me to be a worthwhile goal and it is one that I
and others believe that we can do.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: eudev project announcement

[Richard Yao]

On 12/17/2012 04:31 PM, Greg KH wrote:
> On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:
>> Olav Vitters  wrote:
>>
>>> On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
 As I said in an earlier email, Lennart Poettering claims that it does
 not work. We are discussing some of the things necessary to make it
>>> work.
>>>
>>> Just to repeat:
>>> In this thread it was claimed that a separate /usr is not supported by
>>> systemd/udev.
>>>
>>> A case which works with latest systemd on various distributions. I
>>> checked with upstream (not Lennart), and they confirmed it works. I can
>>> wait for Lennart to say the same, but really not needed.
>>>
>>> I assume this will again turn into a "but I meant something else".
>>
>> Olav.
>>
>> Lennart has stated that he considers a seperate /usr without init* broken.
> 
> Yes, as do I, and so do a lot of other developers.
> 
> But that is a system configuration issue, not a systemd issue, please
> don't confuse the two.

You can add me to that list. The only difference is that I feel
differently about what the proper solution is. In particular, I reject
the notion that there be a single rules directory. That opens the door
to having a second directory on /usr that enforce the requirement that
rules that depend on /usr execute after /usr is mounted.

>> This has worked correctly in the past.
> 
> Define "past" please.
> 
> Note, it's still broken, I have yet to see any upstream fixes to resolve
> all of the issues that are involved here with "fixing" this up.
> 
> Yes, as always, for some subset of users, you can be lucky and it will
> work for them, but those systems are getting rarer and rarer these days,
> as the rest of upstream (not systemd here) are moving on and not doing
> anything to change their behavior for this topic.

In practice, the majority of users have no issues in areas that matter
to them. Those that do seem to be a small minority.

>> The direction udev development is going, according to Lennart, is to
>> make that impossible and he refuses to fix this regression.
> 
> Again, this has NOTHING to do with udev or systemd, as has been pointed
> out numerous times.  I understand your _wish_ that it would have
> something to do with it, but that will not change the facts, sorry.

It can be said that the systemd developers are not very accommodating to
people who want to pursue alternative solutions.

>> I am really happy with this project and intend on testing it once
>> requests for this appear in the eudev mailing list.
> 
> Good luck, the root problems still remain, and nothing that eudev ever
> does can resolve that, sorry.
> 
> Can this topic finally be put to rest please?  There is a whole web page
> devoted to this topic, why do people blindly ignore it?
> 
> Again, a separate /usr without an initrd has NOTHING to do with systemd
> or udev, with the minor exception that Gentoo's packaging of those
> programs _might_ have an issue, but that is Gentoo's issue, NOT
> upstream's issue.
> 
> If anyone involved with eudev, or is involved with the Gentoo Council
> thinks that the previous paragraph is incorrect, they are flat out
> wrong.
> 
> greg k-h
> 

The systemd developers do not appear to accept patches unless the
patches have direct relevance to Fedora. Many people consider this to be
an upstream issue in the context of that. They likely would not think
such things had the systemd developers said that they would welcome
patches to improve separate /usr support, despite the fact that it would
never be used in any configuration that they care to support. The
disdain that they have expressed toward such configurations provides
validation for such beliefs.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Attracting developers (Re: Packages up for grabs...)

[Markos Chandras]

On 17 December 2012 22:13, Peter Stuge  wrote:
> Duncan wrote:
>> Apparently, IRC is a hard requirement.  At least the one final
>> evaluation must be done on IRC.
>
> I understand why online communication is not everyone's prefered format.
>
> I guess that the IRC part of the recruitment is not very formal, I
> don't know as I haven't seen one, but in general I would expect that
> it is simply a lightweight substitute for going to the pub and having
> a chat in person, or talking on the phone to a friend.
>
> I further guess that if you would prefer a chat with someone over the
> phone then that could work just as well.
>
> That said, I find that IRC is a useful tool for developers sometimes.
> It's not mandatory by any means, and sometimes it's just a huge time
> sink, and a little bit like filing bugs it isn't mandatory, but it
> *can* be useful.
>
>
> //Peter
>

Nowadays, I use google docs ( and I am also open to g+ and skype
interviews as well ). So IRC is not an absolute requirement.

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

[gentoo-dev] Portage sets support Was: Defaulting for debug information in profiles

[Duncan]

Zac Medico posted on Mon, 17 Dec 2012 23:31:24 -0800 as excerpted:

> On 12/17/2012 09:59 PM, Duncan wrote:

>> [1] I long ago filed a bug suggesting a new world-sets line for
>> depclean,
>> but I expect it'll be resolved/fixed about the time sets support
>> finally gets unmasked to ~arch, the status of which looks about like
>> the tree's git conversion status... in practice, target "bluesky".  I
>> guess these are gentoo's Duke Nukem' Forever projects.
> 
> Fixed now:
> 
>  https://bugs.gentoo.org/show_bug.cgi?id=298298
> 
> It was a lot easier than the git conversion. ;-p

Hurray! =:^)

FWIW, I guess I wasn't as clear in my post as I was in my head, but what 
I /intended/ to compare to the git conversion was sets support in at 
least ~arch-unmasked portage.  I've been eagerly awaiting both the git 
tree conversion and sets support that ordinary users (at least in ~arch) 
can use without unmasking, but both are complicated as much by the 
political issues as the technical ones, so it's not as simple as just 
hammering down on the technical issues and getting it done; the political 
issues simply take /time/.

This particular bug was taking some time too, but I wasn't worried about 
it since I knew I was using a masked portage and it was n/a everywhere 
else.  I figured it'd be fixed eventually, as I said, about the time sets 
support got unmasked to ~arch.

But with luck, that's about to happen too, and I was right.  Should I be 
on the lookout for flying pigs too?  =:^)

Seriously, from your perspective, what /is/ the status on ~arch sets 
support?  I know I've not had any technical issues in that regard in 
/ages/, but I believe the original political problem was that portage's 
implementation of sets differed from that of paludis, and the idea was to 
standardize on something that could be used by both, possibly covered by 
PMS, so sets could be distributed in the tree, etc.  And not being on the 
PMS list and not having seen anything on it here, I'm not sure if there 
has been any movement at all in that regard or not.  And if not, is it 
even practical to thing it could still happen?  And if standardization 
isn't practical, will the feature eventually be introduced, or dropped, 
and if the plan is still to introduce it, is it something you believe you 
can do right away as a portage update, or do you believe you need council 
blessing for it, or?

I guess if you're bothering to commit depclean summary changes to support 
sets, as you just did, the feature isn't on the cutting block yet, which 
is a good sign, but I'd still like to be able to share sets with people 
without worrying about explaining the concept and that support for it is 
available but is still masked, every time.  Is that something that I can 
realistically expect to be able to do by say, the end of 2013, or not?

As the slogan goes, "Enquiring minds want to know!" =:^)

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