[gentoo-dev] Defaulting for debug information in profiles

[gentoo-dev] Defaulting for debug information in profiles

[Tomáš Chvátal]

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

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

[Diego Elio Pettenò]

On 17/12/2012 11:11, Tomáš Chvátal wrote:
> 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.

Why, somebody uses default cflags?

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

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

[Tomáš Chvátal]

2012/12/17 Diego Elio Pettenò <flameeyes@flameeyes.eu>:
> On 17/12/2012 11:11, Tomáš Chvátal wrote:
>> 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.
>
> Why, somebody uses default cflags?
>
I silently hope they copy the default cflags to their make.conf and
then set march and add more stuff, rather than starting from scratch.
Also we can pop-up newsitem asking them to put it into cflags ;-)

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

[Ben de Groot]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

On 17 December 2012 18:26, Tomáš Chvátal <tomas.chvatal@gmail.com> wrote:

> 2012/12/17 Diego Elio Pettenò <flameeyes@flameeyes.eu>:
> > On 17/12/2012 11:11, Tomáš Chvátal wrote:
> >> 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.
> >
> > Why, somebody uses default cflags?
> >
> I silently hope they copy the default cflags to their make.conf and
> then set march and add more stuff, rather than starting from scratch.
> Also we can pop-up newsitem asking them to put it into cflags ;-)
>
>
Please don't. For most users this is a waste of resources.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[-- Attachment #2: Type: text/html, Size: 1311 bytes --]

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

[Tomáš Chvátal]

2012/12/17 Ben de Groot <yngwin@gentoo.org>:
> Please don't. For most users this is a waste of resources.
>
On first look it seems like waste of resources.
On second hand it makes stuff easy wrt bugreports provided by users.
And believe me when I say most upstreams are pissed by gentoo reports
because they lack any good debuginfo features, nor they know how to
tell users how to make their systems contain debug informations. I
have seen quite few upstreams rejecting all  by Gentoo reported issues
because of this, plus they were quite suprised that I actually can
generate any sane debug informations with it.

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

[Ben de Groot]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

On 17 December 2012 18:55, Tomáš Chvátal <tomas.chvatal@gmail.com> wrote:

> 2012/12/17 Ben de Groot <yngwin@gentoo.org>:
> > Please don't. For most users this is a waste of resources.
> >
> On first look it seems like waste of resources.
> On second hand it makes stuff easy wrt bugreports provided by users.
> And believe me when I say most upstreams are pissed by gentoo reports
> because they lack any good debuginfo features, nor they know how to
> tell users how to make their systems contain debug informations. I
> have seen quite few upstreams rejecting all  by Gentoo reported issues
> because of this, plus they were quite suprised that I actually can
> generate any sane debug informations with it.
>
>

I still think it is a bad idea to enable something that is not necessary
for most users by default.

For your purposes it should be enough to update our existing documentation
about debugging, and link to it from the handbook. Let the user make an
informed choice by himself.
-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[-- Attachment #2: Type: text/html, Size: 1626 bytes --]

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

[Diego Elio Pettenò]

On 17/12/2012 11:26, Tomáš Chvátal wrote:
> I silently hope they copy the default cflags to their make.conf and
> then set march and add more stuff, rather than starting from scratch.
> Also we can pop-up newsitem asking them to put it into cflags ;-)
> 

They don't, they use those coming from cataylist.

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

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

[Dirkjan Ochtman]

On Mon, Dec 17, 2012 at 11:26 AM, Tomáš Chvátal <tomas.chvatal@gmail.com> wrote:
> I silently hope they copy the default cflags to their make.conf and
> then set march and add more stuff, rather than starting from scratch.
> Also we can pop-up newsitem asking them to put it into cflags ;-)

You might want to get the handbook to recommend that for new installs?

http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=5#doc_chap3

Cheers,

Dirkjan

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

[Sven Eden]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

Am Montag, 17. Dezember 2012, 11:11:38 schrieb Tomáš Chvátal:
> 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
> (snip)

Hello Tomáš,

on my system I have set up everything with splitdebug enabled. My CFLAGS use -
march=native, -O2 and -ggdb.
And this is the result: (Yes, I have a dedictated partition for that.)

 ~ $ LC_ALL=C df -h /usr/lib/debug/.
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda10       25G   22G  1.7G  93% /usr/lib64/debug

This is a full KDE-4.9.4 system with a total 
of 1,807 packages installed.

I guess the regular user would end up somewhere between your 2G and my 22G. 
But I bet it will be slightly more likely my end, wouldn't it?


Sincerly

Sven

-- 
http://pwxlib.sourceforge.net

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

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

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

On 17/12/2012 11:33, Sven Eden wrote:
> on my system I have set up everything with splitdebug enabled. My CFLAGS use -
> march=native, -O2 and -ggdb.

That's  -ggdb that increases the size.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 553 bytes --]

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

[vivo75]

Il 17/12/2012 11:42, Diego Elio Pettenò ha scritto:
> On 17/12/2012 11:33, Sven Eden wrote:
>> on my system I have set up everything with splitdebug enabled. My CFLAGS use -
>> march=native, -O2 and -ggdb.
> That's  -ggdb that increases the size.
>

In short FEATURES=compressdebug should be stable and default before you 
(gentoo) decide for something like this.
As mentioned somewhere else in this thread some packages are on the 
unbeareable side when compiled with debug information, those should 
default to filter out debug flags if not actually wanted by the user 
USE=gdb maybe?
When going with debug information the best available should be used so 
-ggdb not -g if possible.
Please try to understand the differences between the  various options 
(nodebug, -g, -ggdb) versus (time to build, memory needed, disk space) 
before attempting this.
Diego maybe it's worth some runs in the tinderbox.

Some numbers:

Packages installed:   1756
Packages in world:    626
Packages in system:   42
Required packages:    1756
Number to remove:     0


ECFLAGSbase='-O2 -march=corei7-avx -pipe -frecord-gcc-switches'
ECFLAGSnative='-mno-movbe -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop 
-mno-bmi -mno-tbm --param=l1-cache-size=32 --param=l1-cache-line-size=64 
--param=l2-cache-size=6144 -mtune=corei7-avx'
ECFLAGSnative="${ECFLAGSnative} -mno-bmi2 -mno-avx2 -mno-lzcnt -mrdrnd 
--param=l1-cache-size=32"
ECFLAGSo3='-fgcse-after-reload -fpredictive-commoning -ftree-vectorize 
-funswitch-loops' # O3 - -finline-functions -fipa-cp-clone
ECFLAGSgraphite='-fgraphite-identity -floop-block -floop-interchange 
-floop-strip-mine' # graphite & co (-fira-loop-pressure no good amd64)

ECFLAGSdbug='-ggdb -gdwarf-4 -fvar-tracking-assignments'

ECFLAGSlto=''
CFLAGS="${ECFLAGSbase} ${ECFLAGSnative} ${ECFLAGSo3} ${ECFLAGSgraphite} 
${ECFLAGSlto} ${ECFLAGSdbug}"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
ELDFLAGSoptimize='-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
-Wl,--sort-common -Wl,--no-copy-dt-needed-entries'

ELDFLAGSdebug='-Wl,--build-id'

ELDFLAGSlto=''
LDFLAGS="${LDFLAGS} ${ELDFLAGSoptimize} ${ELDFLAGSdebug}"


FEATURES="${FEATURES} splitdebug installsources compressdebug"

du -csh /usr/lib/debug/ /usr/src/debug/
5,5G    /usr/lib/debug/
3,9G    /usr/src/debug/
9,4G    totale

find /usr/* -maxdepth 0 -type d -not -name src -not -name portage -exec 
echo  {} +
/usr/armv7a-hardfloat-linux-gnueabi /usr/bin /usr/brlcad /usr/data 
/usr/etc /usr/fakelib /usr/gnu-classpath-0.98 /usr/include /usr/lib32 
/usr/lib64 /usr/libexec /usr/local /usr/man /usr/Mod /usr/sbin 
/usr/share /usr/x86_64-pc-linux-gnueabi

find /usr/* -maxdepth 0 -type d -not -name src -not -name portage -exec 
du -csh {} +
38M     /usr/armv7a-hardfloat-linux-gnueabi
825M    /usr/bin
86M     /usr/brlcad
1,3M    /usr/data
16K     /usr/etc
8,0K    /usr/fakelib
12M     /usr/gnu-classpath-0.98
425M    /usr/include
392M    /usr/lib32
11G     /usr/lib64  <== 5,5G    /usr/lib/debug/
415M    /usr/libexec
28K     /usr/local
304K    /usr/man
18M     /usr/Mod
81M     /usr/sbin
3,3G    /usr/share
27M     /usr/x86_64-pc-linux-gnu
17G     totale

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

[Diego Elio Pettenò]

On 17/12/2012 12:37, vivo75@gmail.com wrote:
> 
> In short FEATURES=compressdebug should be stable and default before you
> (gentoo) decide for something like this.
> As mentioned somewhere else in this thread some packages are on the
> unbeareable side when compiled with debug information, those should
> default to filter out debug flags if not actually wanted by the user
> USE=gdb maybe?
> When going with debug information the best available should be used so
> -ggdb not -g if possible.
> Please try to understand the differences between the  various options
> (nodebug, -g, -ggdb) versus (time to build, memory needed, disk space)
> before attempting this.
> Diego maybe it's worth some runs in the tinderbox.

Again, I'm against using USE flags to handle debug information, it's
already hard enough as it is without adding extra complexity.

I'd be more for _suggesting_ the use of -g but leaving it to the user.
And yes I also agree that -ggdb makes more sense.

I'll write something about it later on I guess.

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

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

[Duncan]

vivo75@gmail.com posted on Mon, 17 Dec 2012 12:37:49 +0100 as excerpted:

> Some numbers:
> 
> Packages installed:   1756
> Packages in world:    626
> Packages in system:   42
> Required packages:    1756
> Number to remove:     0

Heh... try my depclean summary (this is from my workstation, but the 
netbook's summary is similar):

Packages installed:   863
Packages in world:    0
Packages in system:   0
Required packages:    863
Number removed:       0

A rather unusual depclean summary for sure, but how?

Simple enough.

1) /etc/portage/profile/packages has a whole bunch of -*cat/pkg entries 
in it, negating everything that would otherwise be in @system, thus the 0 
packages in system line.  (When I first set that up, I negated 
everything, then took a look at what a depclean pretend run did, and 
added back to my sets, see the next point, anything it was trying to 
remove that I actually needed to keep.  There was surprisingly little, as 
most of my former @system was a specified dependency of something or 
other.)

2) My world file is empty, because I use the sets support in portage 2.2, 
and have categorized all my former world-file entries into about two 
dozen sets such as jed.admin, jed.kde.base.kdebase.apps, jed.net.admin, 
and jed.net.user, which are in turn listed in my world_sets file.  (jed 
are my initials, easy way to avoid set namespace pollution and tell my 
custom sets from those in the kde overlay, for instance.)

3) portage-2.2 pulls in the world_sets, but doesn't yet have a line in 
depclean that reports them[1], and doesn't include them in the world line 
either, so the depclean summary ends up being rather cryptic, to say the 
least, the more so due to factor #1 meaning 0 packages in @system, as 
well.  

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

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

[Zac Medico]

On 12/17/2012 09:59 PM, Duncan wrote:
> vivo75@gmail.com posted on Mon, 17 Dec 2012 12:37:49 +0100 as excerpted:
> 
>> Some numbers:
>>
>> Packages installed:   1756
>> Packages in world:    626
>> Packages in system:   42
>> Required packages:    1756
>> Number to remove:     0
> 
> Heh... try my depclean summary (this is from my workstation, but the 
> netbook's summary is similar):
> 
> Packages installed:   863
> Packages in world:    0
> Packages in system:   0
> Required packages:    863
> Number removed:       0
> 
> A rather unusual depclean summary for sure, but how?
> 
> Simple enough.
> 
> 1) /etc/portage/profile/packages has a whole bunch of -*cat/pkg entries 
> in it, negating everything that would otherwise be in @system, thus the 0 
> packages in system line.  (When I first set that up, I negated 
> everything, then took a look at what a depclean pretend run did, and 
> added back to my sets, see the next point, anything it was trying to 
> remove that I actually needed to keep.  There was surprisingly little, as 
> most of my former @system was a specified dependency of something or 
> other.)
> 
> 2) My world file is empty, because I use the sets support in portage 2.2, 
> and have categorized all my former world-file entries into about two 
> dozen sets such as jed.admin, jed.kde.base.kdebase.apps, jed.net.admin, 
> and jed.net.user, which are in turn listed in my world_sets file.  (jed 
> are my initials, easy way to avoid set namespace pollution and tell my 
> custom sets from those in the kde overlay, for instance.)
> 
> 3) portage-2.2 pulls in the world_sets, but doesn't yet have a line in 
> depclean that reports them[1], and doesn't include them in the world line 
> either, so the depclean summary ends up being rather cryptic, to say the 
> least, the more so due to factor #1 meaning 0 packages in @system, as 
> well.  
> 
> ---
> [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
-- 
Thanks,
Zac

[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

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

[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] Re: Portage sets support Was: Defaulting for debug information in profiles

[Zac Medico]

On 12/18/2012 11:58 PM, Duncan wrote:
> 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! =:^)

Yeah, it's only been in stable for a few months now, so lots of people
aren't aware of it yet.

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

The current list available in portage-2.1.10.x, reported by emerge
--list-sets is:

live-rebuild
module-rebuild
preserved-rebuild
selected
system
world
x11-module-rebuild

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


-- 
Thanks,
Zac

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

[Rich Freeman]

On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico <zmedico@gentoo.org> wrote:
> On 12/18/2012 11:58 PM, Duncan wrote:
>> 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! =:^)
>
> Yeah, it's only been in stable for a few months now, so lots of people
> aren't aware of it yet.
>
> The current list available in portage-2.1.10.x, reported by emerge
> --list-sets is:
>
> preserved-rebuild

If @preserved-rebuild and the corresponding FEATURES=preserve-libs are
now stable, we should create a news item about this.

Otherwise people will still be running revdep-rebuild a decade from
now, as this feature was never formally announced as far as I'm aware,
and all the mentions of it were ages ago and not available to stable
users at the time.

Rich

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

[Zac Medico]

On 12/20/2012 12:09 PM, Rich Freeman wrote:
> On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico <zmedico@gentoo.org> wrote:
>> On 12/18/2012 11:58 PM, Duncan wrote:
>>> 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! =:^)
>>
>> Yeah, it's only been in stable for a few months now, so lots of people
>> aren't aware of it yet.
>>
>> The current list available in portage-2.1.10.x, reported by emerge
>> --list-sets is:
>>
>> preserved-rebuild
> 
> If @preserved-rebuild and the corresponding FEATURES=preserve-libs are
> now stable, we should create a news item about this.
> 
> Otherwise people will still be running revdep-rebuild a decade from
> now, as this feature was never formally announced as far as I'm aware,
> and all the mentions of it were ages ago and not available to stable
> users at the time.

It's not enabled by default yet though. In the following blog post I've
mentioned that I would like to wait for EAPI 5 and automatic rebuilds
(via sub-slots and slot-operators) to gain widespread adoption before
preserve-libs is enabled by default:

http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/

The reason that I want to wait is that EAPI 5 automatic rebuilds provide
solutions for known problems with @preserved-rebuild. These problems
include symbol collisions [1] and unnecessary rebuilding of packages
that are eligible for removal by emerge --depclean [2].

[1]
http://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour
[2] https://bugs.gentoo.org/show_bug.cgi?id=364425
-- 
Thanks,
Zac

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

El jue, 20-12-2012 a las 12:23 -0800, Zac Medico escribió:
> On 12/20/2012 12:09 PM, Rich Freeman wrote:
> > On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico <zmedico@gentoo.org> wrote:
> >> On 12/18/2012 11:58 PM, Duncan wrote:
> >>> 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! =:^)
> >>
> >> Yeah, it's only been in stable for a few months now, so lots of people
> >> aren't aware of it yet.
> >>
> >> The current list available in portage-2.1.10.x, reported by emerge
> >> --list-sets is:
> >>
> >> preserved-rebuild
> > 
> > If @preserved-rebuild and the corresponding FEATURES=preserve-libs are
> > now stable, we should create a news item about this.
> > 
> > Otherwise people will still be running revdep-rebuild a decade from
> > now, as this feature was never formally announced as far as I'm aware,
> > and all the mentions of it were ages ago and not available to stable
> > users at the time.
> 
> It's not enabled by default yet though. In the following blog post I've
> mentioned that I would like to wait for EAPI 5 and automatic rebuilds
> (via sub-slots and slot-operators) to gain widespread adoption before
> preserve-libs is enabled by default:
> 
> http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/
> 
> The reason that I want to wait is that EAPI 5 automatic rebuilds provide
> solutions for known problems with @preserved-rebuild. These problems
> include symbol collisions [1] and unnecessary rebuilding of packages
> that are eligible for removal by emerge --depclean [2].
> 
> [1]
> http://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour
> [2] https://bugs.gentoo.org/show_bug.cgi?id=364425

Regarding symbol collisions, they would appear when people don't rebuild
packages after updating (and that would be solved with eapi5, no? But,
it's not exactly the same as is occurring currently if people forget to
run revdep-rebuild (or if it's partially run)?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Zac Medico]

On 12/20/2012 12:35 PM, Pacho Ramos wrote:
> El jue, 20-12-2012 a las 12:23 -0800, Zac Medico escribió:
>> On 12/20/2012 12:09 PM, Rich Freeman wrote:
>>> On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico <zmedico@gentoo.org> wrote:
>>>> On 12/18/2012 11:58 PM, Duncan wrote:
>>>>> 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! =:^)
>>>>
>>>> Yeah, it's only been in stable for a few months now, so lots of people
>>>> aren't aware of it yet.
>>>>
>>>> The current list available in portage-2.1.10.x, reported by emerge
>>>> --list-sets is:
>>>>
>>>> preserved-rebuild
>>>
>>> If @preserved-rebuild and the corresponding FEATURES=preserve-libs are
>>> now stable, we should create a news item about this.
>>>
>>> Otherwise people will still be running revdep-rebuild a decade from
>>> now, as this feature was never formally announced as far as I'm aware,
>>> and all the mentions of it were ages ago and not available to stable
>>> users at the time.
>>
>> It's not enabled by default yet though. In the following blog post I've
>> mentioned that I would like to wait for EAPI 5 and automatic rebuilds
>> (via sub-slots and slot-operators) to gain widespread adoption before
>> preserve-libs is enabled by default:
>>
>> http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/
>>
>> The reason that I want to wait is that EAPI 5 automatic rebuilds provide
>> solutions for known problems with @preserved-rebuild. These problems
>> include symbol collisions [1] and unnecessary rebuilding of packages
>> that are eligible for removal by emerge --depclean [2].
>>
>> [1]
>> http://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour
>> [2] https://bugs.gentoo.org/show_bug.cgi?id=364425
> 
> Regarding symbol collisions, they would appear when people don't rebuild
> packages after updating (and that would be solved with eapi5, no? But,
> it's not exactly the same as is occurring currently if people forget to
> run revdep-rebuild (or if it's partially run)?

The problem with symbol collisions is only possible for people who have
preserve-libs enabled. On the other hand, when preserve-libs is
disabled, programs simply fail to run due to the libraries that they
linked against having been unmerged when the library was updated.
-- 
Thanks,
Zac

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

On Thu, 20 Dec 2012 15:09:45 -0500
Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico <zmedico@gentoo.org>
> wrote:
> > On 12/18/2012 11:58 PM, Duncan wrote:
> >> 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! =:^)
> >
> > Yeah, it's only been in stable for a few months now, so lots of
> > people aren't aware of it yet.
> >
> > The current list available in portage-2.1.10.x, reported by emerge
> > --list-sets is:
> >
> > preserved-rebuild
> 
> If @preserved-rebuild and the corresponding FEATURES=preserve-libs are
> now stable, we should create a news item about this.
> 
> Otherwise people will still be running revdep-rebuild a decade from
> now, as this feature was never formally announced as far as I'm aware,
> and all the mentions of it were ages ago and not available to stable
> users at the time.

We really shouldn't... EAPI 5 is the way to go, not preserve-libs.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ian Stakenvicius]

sorry for the format, this was
Sent from my iPhone

On 2012-12-20, at 4:51 PM, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Thu, 20 Dec 2012 15:09:45 -0500
> Rich Freeman <rich0@gentoo.org> wrote:
>> On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico <zmedico@gentoo.org>
>> wrote:
>>> On 12/18/2012 11:58 PM, Duncan wrote:
>>>> 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! =:^)
>>> 
>>> Yeah, it's only been in stable for a few months now, so lots of
>>> people aren't aware of it yet.
>>> 
>>> The current list available in portage-2.1.10.x, reported by emerge
>>> --list-sets is:
>>> 
>>> preserved-rebuild
>> 
>> If @preserved-rebuild and the corresponding FEATURES=preserve-libs are
>> now stable, we should create a news item about this.
>> 
>> Otherwise people will still be running revdep-rebuild a decade from
>> now, as this feature was never formally announced as far as I'm aware,
>> and all the mentions of it were ages ago and not available to stable
>> users at the time.
> 
> We really shouldn't... EAPI 5 is the way to go, not preserve-libs.
> 

preserved-libs complements EAPI5, it should not disappear.

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

[Zac Medico]

On 12/20/2012 03:00 PM, Ian Stakenvicius wrote:
> 
> 
> sorry for the format, this was
> Sent from my iPhone
> 
> On 2012-12-20, at 4:51 PM, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
>> On Thu, 20 Dec 2012 15:09:45 -0500
>> Rich Freeman <rich0@gentoo.org> wrote:
>>> On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico <zmedico@gentoo.org>
>>> wrote:
>>>> On 12/18/2012 11:58 PM, Duncan wrote:
>>>>> 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! =:^)
>>>>
>>>> Yeah, it's only been in stable for a few months now, so lots of
>>>> people aren't aware of it yet.
>>>>
>>>> The current list available in portage-2.1.10.x, reported by emerge
>>>> --list-sets is:
>>>>
>>>> preserved-rebuild
>>>
>>> If @preserved-rebuild and the corresponding FEATURES=preserve-libs are
>>> now stable, we should create a news item about this.
>>>
>>> Otherwise people will still be running revdep-rebuild a decade from
>>> now, as this feature was never formally announced as far as I'm aware,
>>> and all the mentions of it were ages ago and not available to stable
>>> users at the time.
>>
>> We really shouldn't... EAPI 5 is the way to go, not preserve-libs.
>>
> 
> preserved-libs complements EAPI5, it should not disappear.

Plus, if we are somehow able to do away with preserve-libs then we also
need to ban preserve_old_lib from eutils.eclass, since it's the same
thing only worse due to its lack of automatic garbage collection.
-- 
Thanks,
Zac

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

[Tomáš Chvátal]

2012/12/17 Sven Eden <sven.eden@gmx.de>:
> Hello Tomáš,
>
> on my system I have set up everything with splitdebug enabled. My CFLAGS use -
> march=native, -O2 and -ggdb.
> And this is the result: (Yes, I have a dedictated partition for that.)
>
>  ~ $ LC_ALL=C df -h /usr/lib/debug/.
> Filesystem      Size  Used Avail Use% Mounted on
> /dev/sda10       25G   22G  1.7G  93% /usr/lib64/debug
>
> This is a full KDE-4.9.4 system with a total
> of 1,807 packages installed.
>
> I guess the regular user would end up somewhere between your 2G and my 22G.
> But I bet it will be slightly more likely my end, wouldn't it?
>
>
Well your "problem" is using -ggdb, that adds ton of stuff that makes
things large exponencialy in most cases, i bet you would be around 5-6
on -g usage.

Cheers

Tom

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

[Sven Eden]

[-- Attachment #1: Type: text/plain, Size: 3951 bytes --]

Am Montag, 17. Dezember 2012, 11:47:24 schrieb Tomáš Chvátal:
> 2012/12/17 Sven Eden <sven.eden@gmx.de>:
> > Hello Tomáš,
> > 
> > on my system I have set up everything with splitdebug enabled. My CFLAGS
> > use - march=native, -O2 and -ggdb.
> > And this is the result: (Yes, I have a dedictated partition for that.)
> > 
> >  ~ $ LC_ALL=C df -h /usr/lib/debug/.
> > 
> > Filesystem      Size  Used Avail Use% Mounted on
> > /dev/sda10       25G   22G  1.7G  93% /usr/lib64/debug
> > 
> > This is a full KDE-4.9.4 system with a total
> > of 1,807 packages installed.
> > 
> > I guess the regular user would end up somewhere between your 2G and my
> > 22G.
> > But I bet it will be slightly more likely my end, wouldn't it?
> 
> Well your "problem" is using -ggdb, that adds ton of stuff that makes
> things large exponencialy in most cases, i bet you would be around 5-6
> on -g usage.

First, I do not want to argue. I just want to state, and prove for at least 
_my_ machine, that this is not true.

Second, my whole system is compiled using gcc-4.7.2. This means, that the 
results below might differ greatly from a setting where stable gcc-4.5.4 is 
used for the whole. But this doesn't matter, because gcc-4.7.* will, 
eventually, become the stable and current gcc. (Unless it is skipped, of 
course.)

Third, "_My_ Machine" means: My setting, hardware, USE-Flags and CFLAGS.

For this the assumption -ggdb would add about 300% in size is "a bit" 
exsessive. 

Background:
The option "-g" produces debugging information in the operating systems native 
format, already fit for GDB. -ggdb simply uses the most expressive format. 
Both, as I believe, result in "DWARF-2" format on my system. At least I get no 
difference whether I specify "-g -gdwarf-2" or "-ggdb". GDB extensions are 
added if possible.

It seems to me, judging the results of the tests below, that those "gdb-
extensions" are already enabled by default (gcc-4.7.2).
I have not found any information on that regarding DWARF-2, but at least
 http://gcc.gnu.org/onlinedocs/gccint/DBX-Options.html
states that DEFAULT_GDB_EXTENSIONS (for DBX output) is always turned on by 
default.

Maybe that's true for DWARF-2 as well?


Below are the resulting sizes of all .debug files having been generated first 
using "-ggdb", then using "-g" in make.conf CFLAGS.

The tested packages are:

1) kde-base/kate (C++ Code, heavy library usage) and
2) dev-libs/lzo (ANSI C)

I believe both are, regarding their code base, far enough apart for building 
up a test case. It is _not_ representative, of course.


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.



Sincerly

Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

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

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

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Sven Eden]

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

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
   text    data     bss     dec     hex filename
  44545    4124     328   48997    bf65 /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
   text    data     bss     dec     hex filename
  42713    4124     328   47165    b83d /usr/bin/sqlite3

As you can see I have splitdebug turned on.
Marcin

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

[Sven Eden]

[-- Attachment #1: Type: text/plain, Size: 2566 bytes --]

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
>    text    data     bss     dec     hex filename
>   44545    4124     328   48997    bf65 /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
>    text    data     bss     dec     hex filename
>   42713    4124     328   47165    b83d /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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

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
>>    text    data     bss     dec     hex filename
>>   44545    4124     328   48997    bf65 /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
>>    text    data     bss     dec     hex filename
>>   42713    4124     328   47165    b83d /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

[Alexandre Rostovtsev]

On Mon, 2012-12-17 at 11:11 +0100, Tomáš Chvátal wrote:
> 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

The bigger problem is not disk space but memory usage at link time. Try
building something like *-webkit-* or firefox with debugging CFLAGS on a
machine with limited memory.

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

[Tomáš Chvátal]

2012/12/17 Alexandre Rostovtsev <tetromino@gentoo.org>:
>
> The bigger problem is not disk space but memory usage at link time. Try
> building something like *-webkit-* or firefox with debugging CFLAGS on a
> machine with limited memory.
>
>
That ain't problem, we acutally can patch in those packages to strip
the debug by default and add there useflag to not strip those for
those really needing it.

Also the culprit is again -ggdb rather than -g.

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

[Diego Elio Pettenò]

On 17/12/2012 11:54, Tomáš Chvátal wrote:
> That ain't problem, we acutally can patch in those packages to strip
> the debug by default and add there useflag to not strip those for
> those really needing it.

No. USE=debug is for _something else_ entirely. And I'm going to kick
hard whoever tries to make USE=debug provide debug information rather
than debug codepaths.

> Also the culprit is again -ggdb rather than -g.

Which makes now interesting for somebody to test what webkit-gtk
requires, memory-wise, with just -g rather than -ggdb.

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

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

[Markos Chandras]

On 17 December 2012 10:11, Tomáš Chvátal <tomas.chvatal@gmail.com> wrote:
> 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
>

Sounds like a reasonable request to me although most people will have
their own cflags in make.conf.

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

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

[Kacper Kowalik]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

On 12/17/2012 11:11 AM, Tomáš Chvátal wrote:
> Hi lads,
> lately I am having bit of problems from getting relevant debug info from users.

All trouble can be saved by asking user to recompile package with
relevant flags on bug report, resolving the bug as NEEDINFO. Instead of
forcing everybody out there using Gentoo to have additional XGb for
debug, patching troublesome packages like webkit-gtk etc. Bug without
valid data is by definition... invalid?

I'm pretty amused by this thread, cause *you* taught me that ^^. I had
once the very same idea :)
Cheers,
Kacper

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

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

[Rich Freeman]

On Mon, Dec 17, 2012 at 8:43 AM, Kacper Kowalik <xarthisius@gentoo.org> wrote:
> All trouble can be saved by asking user to recompile package with
> relevant flags on bug report, resolving the bug as NEEDINFO. Instead of
> forcing everybody out there using Gentoo to have additional XGb for
> debug, patching troublesome packages like webkit-gtk etc. Bug without
> valid data is by definition... invalid?

Tend to agree.  Plus, you can always compile -O0 in such a case and
get more useful debug info besides (yes, I know this can be misleading
under some circumstances, but not all packages are glibc).  Plus, if
the user doesn't enable core dumps the debug info is useless unless
the problem is reproducible, and if it is reproducible then you can
just build it with debug info.

But, by all means make it easy for the user to make their own choice.

I usually keep a debug file in /etc/portage/env.d and symlink it to
anything I'm working on.

Rich

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

[Diego Elio Pettenò]

On 17/12/2012 14:55, Rich Freeman wrote:
> Tend to agree.  Plus, you can always compile -O0 in such a case and
> get more useful debug info besides (yes, I know this can be misleading
> under some circumstances, but not all packages are glibc).

No. No. No. No. No. ......... No.

It's not "being glibc", it's "using glibc" — sure not all packages use
glibc, but most do. And using -O0 means that more than half the time you
won't hit the issue.

Why? Because dead-code elimination and constant propagation change
_enormously_ the code that is executed, so you are basically debugging
two completely different programs.

So please stop giving this stupid suggestion, which causes enough grief
as it is without being repeated once again.

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

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

[Rich Freeman]

On Mon, Dec 17, 2012 at 9:05 AM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> So please stop giving this stupid suggestion, which causes enough grief
> as it is without being repeated once again.

Uh, sure, insofar as it is possible to stop doing something that
you've done exactly once...  :)

However, I've found it a useful tool, assuming the error is still
reproducible.  If it prevents the error from being reproduced it is
obviously less useful.  I for one like having all parameters on my
stack frame, but perhaps there is another switch that will only toggle
this.

Rich

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

[Diego Elio Pettenò]

On 17/12/2012 15:20, Rich Freeman wrote:
> Uh, sure, insofar as it is possible to stop doing something that
> you've done exactly once...  :)

In general, I've heard the same suggestion touted too many times
already. It's this kind of misinformation and cargo culting that often
causes `strip-flags` to be used (even when gcc codegen is perfectly
fine), or that make upstream complain that Gentoo users are ricers for
not sticking with -O0.

> However, I've found it a useful tool, assuming the error is still
> reproducible.  If it prevents the error from being reproduced it is
> obviously less useful. 

By experience with the kind of crashes we get reported on bugzilla,
roughly eight times out of ten it's perfectly pointless to use -O0.

_FORTIFY_SOURCES overflows can't happen at -O0.
Uninitialized variables are zeroed out at -O0.

At -O0 you're debugging a completely different program. Sure it's
possible that the crash is so blatantly broken than it will crash
anyway, but that kind of crashes tend to be extremely rare and easy to
catch to begin with.

In most cases, you just want to know the ballpark of where the crash is
happening, as you want to know which assumption is not holding up.

> I for one like having all parameters on my
> stack frame, but perhaps there is another switch that will only toggle
> this.

There is, but it can stop constant propagation from working properly. If
we're discussing about crashes, which is what debug information in
general is useful for, -O0 is useless in most cases.

It's a different story altogether if you go into what a developer would
do to debug a particularly nasty crash, or to see why something's
misbehaving, and you want to use gdb rather than fill your code of
printf() statements. But that's a completely different story, so let's
leave it at that.

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

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

[Luca Barbato]

On 12/17/2012 02:55 PM, Rich Freeman wrote:
> On Mon, Dec 17, 2012 at 8:43 AM, Kacper Kowalik <xarthisius@gentoo.org> wrote:
>> All trouble can be saved by asking user to recompile package with
>> relevant flags on bug report, resolving the bug as NEEDINFO. Instead of
>> forcing everybody out there using Gentoo to have additional XGb for
>> debug, patching troublesome packages like webkit-gtk etc. Bug without
>> valid data is by definition... invalid?
> 
> Tend to agree.  Plus, you can always compile -O0 in such a case and

Ages ago I wrote something about how wrong is using -O0 and expect to
reproduce issues. IIRC Diego blogged about it as well.

Please do not use -O0, it changes a _lot_ the codepats of programs and
glibc (and other libc) might or might not switch to compiler specific
implementation that might uncover problems.

I'd rather suggest the user to install valgrind and run the application
under it.

lu

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

On 12/17/12 2:11 AM, Tomáš Chvátal wrote:
> 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.

Fully seconded.

For people raising concerns in this thread: it can be easily disabled.

I think good defaults are really important. What do you think is more
reasonable to assume: (1) that the user hits crashes and wants to submit
a good bug report but doesn't want to recompile half of the system, or
(2) that the user has very limited disk space or some other kind of
special configurations.

Note that (2) is totally fine, I just think it's less likely to happen
(hopefully we can avoid a bias here with people thinking if _they_ have
a setup that can't use splitdebug or something, the same would apply to
everybody else).

Paweł



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[vivo75]

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.