Re: [gentoo-dev] Removal of auto-use in portage-2.0.54
On Sunday 27 November 2005 01:48, Henrik Brix Andersen wrote:
> On Sat, Nov 26, 2005 at 05:12:45PM +0200, Marius Mauch wrote:
> > As I said earlier, we'd like to get rid of the nasty auto-use feature,
> > including the support for the USE_ORDER variable. Right now we intend
> > this for 2.0.54 (might not be the final version number) unless there are
> > major objections to it.
>
> What will happen to the USE flags currently in use.defaults when this
> is removed?
It will turn off unless it is enabled somewhere else.
> Perhaps some of them be moved to the profiles instead?
This is more of a releng/basesystem question rather than a portage question.
Makes no difference to me as a user as I have USE="-* ..." in make.conf. ;)
> I'm mostly concerned about the 'udev' USE flag. Some packages rely on
> this to be able to function correctly on an udev enabled system.
> Since udev seems to be the default choice for our default-linux
> profiles, it would make sense to also set USE=udev in those profiles?
Message logging will come in at the same time so it might be better to do
something like:
portageq has_version ${ROOT} sys-fs/udev && use !udev && (
ewarn "You have udev installed but do not the udev USE flag enabled."
ewarn "${PN} might behave incorrectly."
)
Except with better bash style of course.. But that's just what I'd do. Once
proper logging goes in, it'd be a good idea for policies on things like this
to be developed.
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On 25/11/2005 11:46:54, Marius Mauch ([EMAIL PROTECTED]) wrote:
> Except that no{man,info,doc} are on the to-die list anyway.
When you say 'to-die' do you mean completely removed, or do you
mean replaced with {man,info,doc} (i.e. removing inverted logic)?
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (default or not?)
On 26/11/2005 13:55:25, Ned Ludd ([EMAIL PROTECTED]) wrote: > On Sat, 2005-11-26 at 19:30 +0100, Bruno wrote: > > > What's the advantage of splitting out the debug info to some extra > > location instead of leaving it in the original binary (maybe smaller > > foot-print in memory while the debugging info is not used), > > Yes exactly a stripped binary will occupy less space in RAM. I may be wrong, but I don't think this is true. As I understand it, debug sections aren't part of the PT_LOAD segments so the loader won't load them into memory. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: last rites for avifile, vcr, zphoto, drip, divx4linux, quicktime4linux
Luca Barbato posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 27 Nov 2005 01:55:14 +0100: > Luca Barbato wrote: > [snip] > > avifile will be removed tomorrow since mlt and mlt++ (required by jahshaka > as avifile replacement) will be released tomorrow. > > If you are maintaining or using one of the packages in the list keep in > mind that it will be removed in 24h if aren't avifile free. I have very little idea what I'm talking about here, but that's why the questions... I have mjpegtools listed as dependant on avifile, and transcode dependant on mjpegtools, and transcode installed for k3b. Looking at the ebuild, the version hasn't been bumped, but it no longer has the avi USE flag or avifile dependancy. Shouldn't the -r# be bumped, so folks don't end up with an mjpegtools that doesn't work, or is it not cross-linked to a library, only calling an independant executable (avicap, maybe?). I don't see any indication that mjpegtools works with the replacements? -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (default or not?)
On Sun, 2005-11-27 at 10:53 +0100, Kevin F. Quinn wrote: > On 26/11/2005 13:55:25, Ned Ludd ([EMAIL PROTECTED]) wrote: > > On Sat, 2005-11-26 at 19:30 +0100, Bruno wrote: > > > > > What's the advantage of splitting out the debug info to some extra > > > location instead of leaving it in the original binary (maybe smaller > > > foot-print in memory while the debugging info is not used), > > > > Yes exactly a stripped binary will occupy less space in RAM. > > I may be wrong, but I don't think this is true. As I understand it, > debug sections aren't part of the PT_LOAD segments so the loader won't > load them into memory. See the objcopy manpage. Look for the --only-keep-debug section. The entire elf has to be mmaped before individual sections are mapped. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sat, 2005-11-26 at 13:20 -0600, R Hill wrote: > Ned Ludd wrote: > > Good afternoon, > > > > probably in portage-2.0.54 a patch will be added to emit split debug > > info. Having a split debug allows us to retain all the advantages of > > stripping executables while gaining the ability to properly debug > > executables in bfd aware programs. It's been in testing with a small > > hand full of devs and works quite well, but before it's pushed in we > > would like to get input from our devs & users. > > > > Would you be willing to give up space in $ROOT/usr/lib/debug for ELF > > executables by default in order to aid in better debugging by or do we > > want to only emit it when a FEATURE= is defined. > > How much space are we talking about? There is no fixed size here and depends on the number of packages you have and the CFLAGS passed to the programs you build. Naturally if you start building all your code with CFLAGS="-g3 -ggdb" your going to end up with a larger debug info. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (default or not?)
On Sat, 2005-11-26 at 23:42 +0200, Petteri Räty wrote:
> Ned Ludd wrote:
> > Good afternoon,
> >
> > Would you be willing to give up space in $ROOT/usr/lib/debug for ELF
> > executables by default in order to aid in better debugging by or do we
> > want to only emit it when a FEATURE= is defined.
> >
> > Having a split debug pretty much obsoletes the need to add nostrip to
> > your features in order to get debug info.
> >
> > Users wishing to not have debug info can simply add
> > INSTALL_MASK="/usr/lib/debug ${INSTALL_MASK}" to make.conf or the
> > environment unless we make it FEATURE based.
> >
> > I'm in favor of it enabled per default but I'd like to know what you
> > think and why. (advantages of on/off by default etc..)
> >
>
> How useful is this debug information with -fomit-frame-pointer? From
> what I have read it makes debugging at least harder. I think most people
> have -fomit-frame-pointer in their CFLAGS so it should not be enabled by
> default if the debug info is not very useful any way.
>
> Regards,
> Petteri
-fomit-frame-pointer does indeed make certain aspects of debugging
harder but it does not moot the idea entirely.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sunday 27 November 2005 00:10, Luca Barbato wrote: > It's great! > Make it a FEATURE default on for common profiles. +1, and it would be better if the FEATURES, instead of removing the generated files, would disable the building of them completely, mainly because "work" systems with limited CPU, RAM and HDD space would probably prefer not having to create and store them :) /me thinks of laptops -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpgPcOc1xxQW.pgp Description: PGP signature
Re: [gentoo-dev] manpages that requires dependencies
On Fri, 2005-11-25 at 12:46 +0200, Marius Mauch wrote:
> Ciaran McCreesh wrote:
> > On Fri, 25 Nov 2005 00:49:23 +0100 "Diego 'Flameeyes' Pettenò"
> > <[EMAIL PROTECTED]> wrote:
> > | Hi everybody, a little question that I'd like to be answered (so that
> > | we can make it a sort of rule).
> > | How should manpages that are generated be managed?
> > |
> > | The common sense and looking to other ebuilds would say to always
> > | build man pages, but when it asks me to install something like
> > | docbook-sgml-utils, I'm tempted not to do that ;)
> >
> > man pages can't be considered optional (despite what RMS says). They're
> > not fancy extra HTML API documentation, they're core, so they don't get
> > a USE flag.
> >
> > Of course, if FEATURES were in the USE expand list, you could use
> > ! features_noman ? ( ) ...
>
> Except that no{man,info,doc} are on the to-die list anyway.
They are very valuable features and quite easy to use without mucking
with INSTALL_MASK. I'm against this change without some justification.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sun, 2005-11-27 at 07:24 -0500, Ned Ludd wrote: > On Sat, 2005-11-26 at 13:20 -0600, R Hill wrote: > > Ned Ludd wrote: > > > Good afternoon, > > > > > > probably in portage-2.0.54 a patch will be added to emit split debug > > > info. Having a split debug allows us to retain all the advantages of > > > stripping executables while gaining the ability to properly debug > > > executables in bfd aware programs. It's been in testing with a small > > > hand full of devs and works quite well, but before it's pushed in we > > > would like to get input from our devs & users. > > > > > > Would you be willing to give up space in $ROOT/usr/lib/debug for ELF > > > executables by default in order to aid in better debugging by or do we > > > want to only emit it when a FEATURE= is defined. > > > > How much space are we talking about? > > There is no fixed size here and depends on the number of packages you > have and the CFLAGS passed to the programs you build. > Naturally if you start building all your code with > CFLAGS="-g3 -ggdb" your going to end up with a larger debug info. Of course I will be compiling with CFLAGS="-g3 -ggdb" :) The reason I don't do it now is because debug info: 1) makes binaries larger 2) makes binaries slower ( in my experience ( may have to do with 1) ) And I don't ( not sure if anyone does ) care about any non-gdb debugger. So, can you give us a wild guess about the disk space ? How much does it take on your system and how many packages do you have installed ? And one more thing. For proper debugging, don't I need the source to be present ? -- Cheers, Ivan Yosifov. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sun, 2005-11-27 at 07:58 -0500, Ned Ludd wrote:
> On Fri, 2005-11-25 at 12:46 +0200, Marius Mauch wrote:
> > Ciaran McCreesh wrote:
> > > On Fri, 25 Nov 2005 00:49:23 +0100 "Diego 'Flameeyes' Pettenò"
> > > <[EMAIL PROTECTED]> wrote:
> > > | Hi everybody, a little question that I'd like to be answered (so that
> > > | we can make it a sort of rule).
> > > | How should manpages that are generated be managed?
> > > |
> > > | The common sense and looking to other ebuilds would say to always
> > > | build man pages, but when it asks me to install something like
> > > | docbook-sgml-utils, I'm tempted not to do that ;)
> > >
> > > man pages can't be considered optional (despite what RMS says). They're
> > > not fancy extra HTML API documentation, they're core, so they don't get
> > > a USE flag.
> > >
> > > Of course, if FEATURES were in the USE expand list, you could use
> > > ! features_noman ? ( ) ...
> >
> > Except that no{man,info,doc} are on the to-die list anyway.
>
> They are very valuable features and quite easy to use without mucking
> with INSTALL_MASK. I'm against this change without some justification.
further investigation shows that you can't simply get rid of these as
several core ebuilds use the feature to control the creation of
packages. A quick grep shows that several ebuilds do stuff like.
has noman FEATURES && do_stuff
openssl/glibc/gcc/dhcp/boa/gdb to name a few that take advantage of the
no{man,info,doc} FEATURES= already.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sun, 2005-11-27 at 15:09 +0200, Ivan Yosifov wrote: > On Sun, 2005-11-27 at 07:24 -0500, Ned Ludd wrote: > > On Sat, 2005-11-26 at 13:20 -0600, R Hill wrote: > > > Ned Ludd wrote: > > > > Good afternoon, > > > > > > > > probably in portage-2.0.54 a patch will be added to emit split debug > > > > info. Having a split debug allows us to retain all the advantages of > > > > stripping executables while gaining the ability to properly debug > > > > executables in bfd aware programs. It's been in testing with a small > > > > hand full of devs and works quite well, but before it's pushed in we > > > > would like to get input from our devs & users. > > > > > > > > Would you be willing to give up space in $ROOT/usr/lib/debug for ELF > > > > executables by default in order to aid in better debugging by or do we > > > > want to only emit it when a FEATURE= is defined. > > > > > > How much space are we talking about? > > > > There is no fixed size here and depends on the number of packages you > > have and the CFLAGS passed to the programs you build. > > Naturally if you start building all your code with > > CFLAGS="-g3 -ggdb" your going to end up with a larger debug info. > > Of course I will be compiling with CFLAGS="-g3 -ggdb" :) > > The reason I don't do it now is because debug info: > > 1) makes binaries larger > 2) makes binaries slower ( in my experience ( may have to do with 1) ) > > And I don't ( not sure if anyone does ) care about any non-gdb debugger. > > So, can you give us a wild guess about the disk space ? How much does it > take on your system and how many packages do you have installed ? > > And one more thing. For proper debugging, don't I need the source to be > present ? I've been installing debug symbols and debug sources for a few weeks now, using bashrc hacks. I use "debugsymbols" and "debugsources" in FEATURES. At a rough estimate, debug symbols with -ggdb3 will add 60% to package sizes, and debug sources will add another 40%. So having this on by default will necessitate a repartition for many users. Ed Catmur -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sun, 2005-11-27 at 15:09 +0200, Ivan Yosifov wrote: > On Sun, 2005-11-27 at 07:24 -0500, Ned Ludd wrote: > > On Sat, 2005-11-26 at 13:20 -0600, R Hill wrote: > > > Ned Ludd wrote: > > > > Good afternoon, > > > > > > > > probably in portage-2.0.54 a patch will be added to emit split debug > > > > info. Having a split debug allows us to retain all the advantages of > > > > stripping executables while gaining the ability to properly debug > > > > executables in bfd aware programs. It's been in testing with a small > > > > hand full of devs and works quite well, but before it's pushed in we > > > > would like to get input from our devs & users. > > > > > > > > Would you be willing to give up space in $ROOT/usr/lib/debug for ELF > > > > executables by default in order to aid in better debugging by or do we > > > > want to only emit it when a FEATURE= is defined. > > > > > > How much space are we talking about? > > > > There is no fixed size here and depends on the number of packages you > > have and the CFLAGS passed to the programs you build. > > Naturally if you start building all your code with > > CFLAGS="-g3 -ggdb" your going to end up with a larger debug info. > > Of course I will be compiling with CFLAGS="-g3 -ggdb" :) > > The reason I don't do it now is because debug info: > > 1) makes binaries larger > 2) makes binaries slower ( in my experience ( may have to do with 1) ) > > And I don't ( not sure if anyone does ) care about any non-gdb debugger. > > So, can you give us a wild guess about the disk space ? How much does it > take on your system and how many packages do you have installed ? -rwxr-xr-x 1 root root 49268 Nov 19 18:00 /usr/bin/scanelf -rw-r--r-- 1 root root 5292 Nov 19 18:02 /usr/lib/debug/usr/bin/scanelf.debug I really can't give an accurate example. Halcyon who has been testing it merged world and he was yeilded with 18M of debug info (I have no idea how many packages he has). ChrisWhite has also been merging a lot of merging with it recently to test KDE stuff which is a pretty big package. He may have some useful data that your after. The reason I posted the patch and prepstrip here was so that people could formulate their own opinions. I'm also using an additional patch in my local portage system where I'm sub packaging the debug info and it only gets installed when I tell it to be installed via the emerge -K option. I use some pretty crafty tricks to accomplish this like dynamic ebuild creation. I do this in order to have compressed debug info handy vs having it on the live filesystem. This probably would not be accepted by portage mainline unless I do it in a more elegant way that wont conflict with the future portage-3.x series. > And one more thing. For proper debugging, don't I need the source to be > present ? -g3 -ggdb embeds the source code in the debug info so I don't see the point. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 22:09, Ned Ludd wrote:
> On Sun, 2005-11-27 at 07:58 -0500, Ned Ludd wrote:
> > On Fri, 2005-11-25 at 12:46 +0200, Marius Mauch wrote:
> > > Except that no{man,info,doc} are on the to-die list anyway.
> >
> > They are very valuable features and quite easy to use without mucking
> > with INSTALL_MASK. I'm against this change without some justification.
>
> further investigation shows that you can't simply get rid of these as
> several core ebuilds use the feature to control the creation of
> packages. A quick grep shows that several ebuilds do stuff like.
> has noman FEATURES && do_stuff
>
> openssl/glibc/gcc/dhcp/boa/gdb to name a few that take advantage of the
> no{man,info,doc} FEATURES= already.
Core packages or not, they are all broken. When the requirement came up, the
respective maintainers should have spoken up so that a proper solution could
be found. When are the quick hacks going to stop? :|
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On 11/27/05, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote: > On Sunday 27 November 2005 00:10, Luca Barbato wrote: > > It's great! > > Make it a FEATURE default on for common profiles. > +1, and it would be better if the FEATURES, instead of removing the generated > files, would disable the building of them completely, mainly because "work" > systems with limited CPU, RAM and HDD space would probably prefer not having > to create and store them :) Err, maybe I am incorrect, but isn't it more "work" to ungenerate them (using strip) then to just not install them? > > /me thinks of laptops > > -- > Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ > Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE > > > -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] manpages that requires dependencies
27.11.2005, 15:39:48, Jason Stubbs wrote:
> On Sunday 27 November 2005 22:09, Ned Ludd wrote:
>> On Sun, 2005-11-27 at 07:58 -0500, Ned Ludd wrote:
>> > On Fri, 2005-11-25 at 12:46 +0200, Marius Mauch wrote:
>> > > Except that no{man,info,doc} are on the to-die list anyway.
>> >
>> > They are very valuable features and quite easy to use without mucking
>> > with INSTALL_MASK. I'm against this change without some justification.
>>
>> further investigation shows that you can't simply get rid of these as
>> several core ebuilds use the feature to control the creation of
>> packages. A quick grep shows that several ebuilds do stuff like.
>> has noman FEATURES && do_stuff
>>
>> openssl/glibc/gcc/dhcp/boa/gdb to name a few that take advantage of the
>> no{man,info,doc} FEATURES= already.
> Core packages or not, they are all broken. When the requirement came up, the
> respective maintainers should have spoken up so that a proper solution could
> be found. When are the quick hacks going to stop? :|
I can't see why exactly do we need to get rid of useful features? :-(
--
jakub
pgpdTiupJuCiA.pgp
Description: PGP signature
Re: [gentoo-dev] manpages that requires dependencies
On Sun, 2005-11-27 at 23:39 +0900, Jason Stubbs wrote:
> On Sunday 27 November 2005 22:09, Ned Ludd wrote:
> > On Sun, 2005-11-27 at 07:58 -0500, Ned Ludd wrote:
> > > On Fri, 2005-11-25 at 12:46 +0200, Marius Mauch wrote:
> > > > Except that no{man,info,doc} are on the to-die list anyway.
> > >
> > > They are very valuable features and quite easy to use without mucking
> > > with INSTALL_MASK. I'm against this change without some justification.
> >
> > further investigation shows that you can't simply get rid of these as
> > several core ebuilds use the feature to control the creation of
> > packages. A quick grep shows that several ebuilds do stuff like.
> > has noman FEATURES && do_stuff
> >
> > openssl/glibc/gcc/dhcp/boa/gdb to name a few that take advantage of the
> > no{man,info,doc} FEATURES= already.
>
> Core packages or not, they are all broken. When the requirement came up, the
> respective maintainers should have spoken up so that a proper solution could
> be found. When are the quick hacks going to stop? :|
Yeah I can also confirm that things are broken and hacks probably wont
stop till upstream for a given package starts making things like
nroff/groff optional vs forced. I really don't think we will see that
happening anytime soon.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sunday 27 November 2005 15:39, Dan Meltzer wrote: > Err, maybe I am incorrect, but isn't it more "work" to ungenerate them > (using strip) then to just not install them? Their creation in-line of a binary is probably a simpler work (for the disk) than having to split them out, but I might be wrong. For sure they'll take a bit more disk space while building, and that might be significant for things like OpenOffice. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpYe2EgSjSfr.pgp Description: PGP signature
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 15:39, Jason Stubbs wrote: > Core packages or not, they are all broken. When the requirement came up, > the respective maintainers should have spoken up so that a proper solution > could be found. When are the quick hacks going to stop? :| Is my mail enough as a speak-up for finding a proper solution? :P -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpPbCoKei1nq.pgp Description: PGP signature
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sun, 2005-11-27 at 09:39 -0500, Dan Meltzer wrote: > On 11/27/05, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote: > > On Sunday 27 November 2005 00:10, Luca Barbato wrote: > > > It's great! > > > Make it a FEATURE default on for common profiles. > > +1, and it would be better if the FEATURES, instead of removing the > > generated > > files, would disable the building of them completely, mainly because "work" > > systems with limited CPU, RAM and HDD space would probably prefer not having > > to create and store them :) > > Err, maybe I am incorrect, but isn't it more "work" to ungenerate them > (using strip) then to just not install them? it's pretty easy to add a check to the save_elf_debug function to tell it to return if we decide that FEATURES=splitdebug will be the default and that if it's not set to simply return from the function without doing anything. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 23:50, Diego 'Flameeyes' Pettenò wrote: > On Sunday 27 November 2005 15:39, Jason Stubbs wrote: > > Core packages or not, they are all broken. When the requirement came up, > > the respective maintainers should have spoken up so that a proper > > solution could be found. When are the quick hacks going to stop? :| > > Is my mail enough as a speak-up for finding a proper solution? :P No because you haven't listed any requirements beyond those that solar has already pointed out. :P -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 23:43, Jakub Moc wrote:
> 27.11.2005, 15:39:48, Jason Stubbs wrote:
> > On Sunday 27 November 2005 22:09, Ned Ludd wrote:
> >> On Sun, 2005-11-27 at 07:58 -0500, Ned Ludd wrote:
> >> > On Fri, 2005-11-25 at 12:46 +0200, Marius Mauch wrote:
> >> > > Except that no{man,info,doc} are on the to-die list anyway.
> >> >
> >> > They are very valuable features and quite easy to use without mucking
> >> > with INSTALL_MASK. I'm against this change without some justification.
> >>
> >> further investigation shows that you can't simply get rid of these as
> >> several core ebuilds use the feature to control the creation of
> >> packages. A quick grep shows that several ebuilds do stuff like.
> >> has noman FEATURES && do_stuff
> >>
> >> openssl/glibc/gcc/dhcp/boa/gdb to name a few that take advantage of the
> >> no{man,info,doc} FEATURES= already.
> >
> > Core packages or not, they are all broken. When the requirement came up,
> > the respective maintainers should have spoken up so that a proper
> > solution could be found. When are the quick hacks going to stop? :|
>
> I can't see why exactly do we need to get rid of useful features? :-(
Nobody said anything about getting rid of the features. The only thing that
has been stated is that FEATURES="noman" cannot be relied upon to mean that
portage won't install man pages or vice-versa.
There are three possibilities that I can see:
1) FEATURES="noman" becomes FEATURES="man"
2) FEATURES="noman" is dropped in favour of INSTALL_MASK="/usr/share/man"
3) FEATURES="noman" is dropped in favour of USE="man" or USE="manpages"
In light of the above requirements and the fact that dyn_* will likely be
moved into the tree down the track, #3 seems to be the best in my mind.
Similarly, it would solve the previously discussed problems related to
FEATURES="test".
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sat, Nov 26, 2005 at 12:50:30PM -0500, Ned Ludd wrote: > I'm in favor of it enabled per default but I'd like to know what you > think and why. (advantages of on/off by default etc..) > This should definitely be enabled by default, we dont need to enable debugging information for this to be useful, just having the symbol table available will make getting backtraces and diagnosing problems many times easier with little extra diskspace requirements. Gentoo is way behind on this feature, all the other major distributions have caught on to how useful detatched debugging symbols can be. If we dont enable this by default, I think the users who really need it (ie, the ones who want us to track down a bug but are unable to provide enough debugging information to do so) probably wont have the foresight to turn it on. This could also be a major boon for administrators imho, if a service is dumping core unpredicatbly this feature and enabling coredumps would be enough to start tracking down the problem, or at least identifying the culprit. -- - [EMAIL PROTECTED] | finger me for my pgp key. --- pgpV2NGP7C5dB.pgp Description: PGP signature
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sun, 2005-11-27 at 08:40 -0500, Ned Ludd wrote: > On Sun, 2005-11-27 at 15:09 +0200, Ivan Yosifov wrote: > > And one more thing. For proper debugging, don't I need the source to be > > present ? > > -g3 -ggdb embeds the source code in the debug info so I don't see the > point. It doesn't; at least not with gcc 3.4.4. It does embed function prototypes and macro definitions, though. Ed Catmur -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
Random thought May be completely off base. Could this debug info be NFS shared? assuming like computers, or would it be different on each computer. On 11/27/05, Tavis Ormandy <[EMAIL PROTECTED]> wrote: > On Sat, Nov 26, 2005 at 12:50:30PM -0500, Ned Ludd wrote: > > I'm in favor of it enabled per default but I'd like to know what you > > think and why. (advantages of on/off by default etc..) > > > > This should definitely be enabled by default, we dont need to enable > debugging information for this to be useful, just having the symbol > table available will make getting backtraces and diagnosing problems > many times easier with little extra diskspace requirements. Gentoo is > way behind on this feature, all the other major distributions have > caught on to how useful detatched debugging symbols can be. > > If we dont enable this by default, I think the users who really need it > (ie, the ones who want us to track down a bug but are unable to provide > enough debugging information to do so) probably wont have the foresight > to turn it on. > > This could also be a major boon for administrators imho, if a service > is dumping core unpredicatbly this feature and enabling coredumps would > be enough to start tracking down the problem, or at least identifying > the culprit. > > -- > - > [EMAIL PROTECTED] | finger me for my pgp key. > --- > > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sun, 2005-11-27 at 09:39 -0500, Dan Meltzer wrote: > On 11/27/05, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote: > > On Sunday 27 November 2005 00:10, Luca Barbato wrote: > > > It's great! > > > Make it a FEATURE default on for common profiles. > > +1, and it would be better if the FEATURES, instead of removing the > > generated > > files, would disable the building of them completely, mainly because "work" > > systems with limited CPU, RAM and HDD space would probably prefer not having > > to create and store them :) > > Err, maybe I am incorrect, but isn't it more "work" to ungenerate them > (using strip) then to just not install them? The debug info gets built into the binary by gcc. We copy out the debug info using objcopy --only-keep-debug, add a link with --gnu-debuglink and then remove it from the binary using strip. Without FEATURES=splitdebug the first two steps would be omitted, making it exactly the same as what happens now. So, no more work. Ed Catmur -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 23:50, Diego 'Flameeyes' Pettenò wrote: > On Sunday 27 November 2005 15:39, Jason Stubbs wrote: > > Core packages or not, they are all broken. When the requirement came up, > > the respective maintainers should have spoken up so that a proper > > solution could be found. When are the quick hacks going to stop? :| > > Is my mail enough as a speak-up for finding a proper solution? :P Err.. Apologies. I has forgotten that you were the one to start the thread. :( -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sun, 2005-11-27 at 15:22 +, Edward Catmur wrote:
> On Sun, 2005-11-27 at 08:40 -0500, Ned Ludd wrote:
> > On Sun, 2005-11-27 at 15:09 +0200, Ivan Yosifov wrote:
> > > And one more thing. For proper debugging, don't I need the source to be
> > > present ?
> >
> > -g3 -ggdb embeds the source code in the debug info so I don't see the
> > point.
>
> It doesn't; at least not with gcc 3.4.4. It does embed function
> prototypes and macro definitions, though.
>
> Ed Catmur
Eh?
[EMAIL PROTECTED] ~ $ gcc -g3 -nopie -ggdb segfault_me.c -o segfault_me
[EMAIL PROTECTED] ~ $ paxctl -permsx segfault_me
[EMAIL PROTECTED] ~ $ gdb -q ./segfault_me
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) b main
Breakpoint 1 at 0x804853d: file segfault_me.c, line 25.
(gdb) step
The program is not being run.
(gdb) r
Starting program: /home/solar/segfault_me
Breakpoint 1, main () at segfault_me.c:25
25 foo();
(gdb) step
foo () at segfault_me.c:17
17 int i = 0;
(gdb)
18 for (i = 0 ; i < 3; i++) {
(gdb)
19 printf("Just an example %d\n", i);
(gdb)
Just an example 0
18 for (i = 0 ; i < 3; i++) {
(gdb)
19 printf("Just an example %d\n", i);
(gdb)
Just an example 1
18 for (i = 0 ; i < 3; i++) {
(gdb)
19 printf("Just an example %d\n", i);
(gdb)
Just an example 2
18 for (i = 0 ; i < 3; i++) {
(gdb)
21 bar();
(gdb)
bar () at segfault_me.c:13
13 baz();
(gdb)
baz () at segfault_me.c:9
9 atexit(break_self);
(gdb)
10 }
(gdb)
bar () at segfault_me.c:14
14 }
(gdb)
foo () at segfault_me.c:22
22 }
(gdb)
main () at segfault_me.c:26
26 return 0;
(gdb)
27 }
(gdb)
0x400407b6 in __libc_start_main () from /lib/libc.so.6
(gdb)
Single stepping until exit from function __libc_start_main,
which has no line number information.
Program received signal SIGSEGV, Segmentation fault.
0x40050681 in kill () from /lib/libc.so.6
(gdb)
[EMAIL PROTECTED] ~ $ cat segfault_me.c
#include
#include
void break_self() {
kill(getpid(), SIGSEGV);
}
int baz() {
atexit(break_self);
}
void bar() {
baz();
}
void foo() {
int i;
for (i = 0 ; i < 3; i++) {
printf("Just an example %d\n", i);
}
bar();
}
int main() {
foo();
return 0;
}
# While single stepping sure looks like source code to me.
[EMAIL PROTECTED] ~ $ gcc -v 2>&1 | tail -n 1
gcc version 3.4.4 (Gentoo Hardened 3.4.4, HTB-3.4.4_pre-1.00,
ssp-3.4.4-1.0, pie-8.7.8)
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Monday 28 November 2005 00:05, Jason Stubbs wrote: > 3) FEATURES="noman" is dropped in favour of USE="man" or USE="manpages" > > In light of the above requirements and the fact that dyn_* will likely be > moved into the tree down the track, #3 seems to be the best in my mind. > Similarly, it would solve the previously discussed problems related to > FEATURES="test". I'd be very interested in people's thoughts on this. The more I think about it, the more I think it's the most appropriate solution. Nothing in FEATURES="noman nodoc noinfo test" affects portage whatsoever other than "noinfo" which (only recently) prevents emerge from regenerating info indexes. That one could be handled by a hook (although not yet available) and the rest could easily be switched to USE flags. Anybody see any flaws? Anybody want (shudders) a GLEP? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Are there valid uses for repoman --ignore-other-arches?
--ignore-other-arches Instructs repoman to ignore arches that are not relevent to the committing arch. REPORT/FIX issues you work around. Are there any valid uses for this switch or can it be deprecated? From a QA point of view this seems like a very bad option. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] manpages that requires dependencies
On Mon, 2005-11-28 at 00:48 +0900, Jason Stubbs wrote: > On Monday 28 November 2005 00:05, Jason Stubbs wrote: > > 3) FEATURES="noman" is dropped in favour of USE="man" or USE="manpages" > > > > In light of the above requirements and the fact that dyn_* will likely be > > moved into the tree down the track, #3 seems to be the best in my mind. > > Similarly, it would solve the previously discussed problems related to > > FEATURES="test". > > I'd be very interested in people's thoughts on this. The more I think about > it, the more I think it's the most appropriate solution. Nothing in > FEATURES="noman nodoc noinfo test" affects portage whatsoever other than > "noinfo" which (only recently) prevents emerge from regenerating info > indexes. That one could be handled by a hook (although not yet available) and > the rest could easily be switched to USE flags. > > Anybody see any flaws? Anybody want (shudders) a GLEP? USE=(man|info|doc) wont quite work. While they could have an advantage that you can use them to control depend strings the doc use flag has already been heavily used for other things which everybody surely wont want. by default only level of profiles should be using these features and it uses it because it needs it or things fail to build. I could bore you with how sandbox and groff don't get along and this functionality is a must. I don't see any immediate benefits in removal so I'd rather we put off discussions of the removal of those 3 features till we are closer to the 2006.0 release cycle. portage-2.0.5(4|5) days. Unless you want to discuss SpanKY idea of use expanding FEATURES which clearly seems the winner in desired functionality (my eyes anyway) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sun, Nov 27, 2005 at 11:12:32AM -0500, Ned Ludd wrote: > On Mon, 2005-11-28 at 00:48 +0900, Jason Stubbs wrote: > > On Monday 28 November 2005 00:05, Jason Stubbs wrote: > > > 3) FEATURES="noman" is dropped in favour of USE="man" or USE="manpages" > > > > > > In light of the above requirements and the fact that dyn_* will likely be > > > moved into the tree down the track, #3 seems to be the best in my mind. > > > Similarly, it would solve the previously discussed problems related to > > > FEATURES="test". this seems like the best idea imo too ... > > I'd be very interested in people's thoughts on this. The more I think about > > it, the more I think it's the most appropriate solution. Nothing in > > FEATURES="noman nodoc noinfo test" affects portage whatsoever other than > > "noinfo" which (only recently) prevents emerge from regenerating info > > indexes. That one could be handled by a hook (although not yet available) > > and > > the rest could easily be switched to USE flags. > > USE=(man|info|doc) wont quite work. > While they could have an advantage that you can use them to control > depend strings the doc use flag has already been heavily used for other > things which everybody surely wont want. i dont see what USE=doc has to do with this ? doc should never be used to control manpages in ebuilds now ... -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Masking of [EMAIL PROTECTED] 3.x and related packages
Hi, It has been a while since the [EMAIL PROTECTED] project has moved to a BOINC-based client. Thanks to Marcus Hanwell (cryos), we have working ebuilds for BOINC and the new [EMAIL PROTECTED] client (4.x) in the tree. The "classic" [EMAIL PROTECTED] 3.x service has now been discontinued (and the software is no longer distributed). This is why I will start masking the relevant packages. These will be removed from the tree in about a month. They are: =sci-astronomy/setiathome-3* sci-astronomy/ksetispy sci-astronomy/ksetiwatch sci-astronomy/lin-seti sci-astronomy/msetimon sci-astronomy/setimgr sci-astronomy/tkseti x11-plugins/gkrellm-seti x11-plugins/wmseti x11-plugins/wmsetimon x11-plugins/wmufo The "seti" local USE flag used in "app-admin/torsmo" and "app-admin/conky" will be masked in the base profile. Tracker bug for the new BOINC-based [EMAIL PROTECTED] is #103250 (http://bugs.gentoo.org/show_bug.cgi?id=103250). Regards, -- Olivier Fisette (ribosome) Gentoo Linux Developer Scientific applications, Developer relations pgpIyWqlWDfrl.pgp Description: PGP signature
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 17:12, Ned Ludd wrote: > USE=(man|info|doc) wont quite work. > While they could have an advantage that you can use them to control > depend strings the doc use flag has already been heavily used for other > things which everybody surely wont want. As vapier said, doc useflag does not mean much in this discussion. FEATURES="nodoc" is less than an install mask, as it just (iirc) make dodoc commands no-ops. An INSTALL_MASK makes simpler to handle that. We already use the doc useflag to avoid adding dependencies only for doc building, so the similar meaning for info and man is already in use. Basic doc does not require any dep (as it's already built), while man and info requires the man command and texinfo, so there's a big difference. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpjo00wZVz3A.pgp Description: PGP signature
Re: [gentoo-dev] manpages that requires dependencies
On Sun, 2005-11-27 at 16:28 +, Mike Frysinger wrote: > On Sun, Nov 27, 2005 at 11:12:32AM -0500, Ned Ludd wrote: > > On Mon, 2005-11-28 at 00:48 +0900, Jason Stubbs wrote: > > > On Monday 28 November 2005 00:05, Jason Stubbs wrote: > > > > 3) FEATURES="noman" is dropped in favour of USE="man" or USE="manpages" > > > > > > > > In light of the above requirements and the fact that dyn_* will likely > > > > be > > > > moved into the tree down the track, #3 seems to be the best in my mind. > > > > Similarly, it would solve the previously discussed problems related to > > > > FEATURES="test". > > this seems like the best idea imo too ... > > > > I'd be very interested in people's thoughts on this. The more I think > > > about > > > it, the more I think it's the most appropriate solution. Nothing in > > > FEATURES="noman nodoc noinfo test" affects portage whatsoever other than > > > "noinfo" which (only recently) prevents emerge from regenerating info > > > indexes. That one could be handled by a hook (although not yet available) > > > and > > > the rest could easily be switched to USE flags. > > > > USE=(man|info|doc) wont quite work. > > While they could have an advantage that you can use them to control > > depend strings the doc use flag has already been heavily used for other > > things which everybody surely wont want. > > i dont see what USE=doc has to do with this ? doc should never be used > to control manpages in ebuilds now ... The 3 no* features in question. Removing just one would be silly. So they either all should go or all stay. If noman were to become USE=man then logic would say that nodoc would become USE=doc and noinfo would become USE=info. Unless we want to call them USE=(docpages|manpages|infopages) all respectively then it wont matter so much. But then USE=-* emerge foo would all of the sudden make USE=-* kinda suck for users who just want to escape the normal default-linux USE flag bloat. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Are there valid uses for repoman --ignore-other-arches?
On Sun, Nov 27, 2005 at 06:08:53PM +0200, Petteri R??ty wrote: > --ignore-other-arches Instructs repoman to ignore arches that are not > relevent to the committing arch. REPORT/FIX issues you work around. > > Are there any valid uses for this switch or can it be deprecated? From a > QA point of view this seems like a very bad option. uhh yeah, like people who want to commit a fix unrelated to any arch breakage someone else may have caused arch breakage is for arch teams to worry over ... without the -I option, maintainers are basically fucked and unable to commit any fixes until the arch issue is resolved and in case i wasnt clear, i'd be very against removing this -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sun, 2005-11-27 at 10:44 -0500, Ned Ludd wrote: > On Sun, 2005-11-27 at 15:22 +, Edward Catmur wrote: > > On Sun, 2005-11-27 at 08:40 -0500, Ned Ludd wrote: > > > On Sun, 2005-11-27 at 15:09 +0200, Ivan Yosifov wrote: > > > > And one more thing. For proper debugging, don't I need the source to be > > > > present ? > > > > > > -g3 -ggdb embeds the source code in the debug info so I don't see the > > > point. > > > > It doesn't; at least not with gcc 3.4.4. It does embed function > > prototypes and macro definitions, though. > > > > Ed Catmur > > Eh? Never mind you were right Ed. taviso pointed out that dwarf2 doesnt support embedding the actual source. I was seeing the source due to me not having deleted the source. Guess that is where the debugedit thing of Tester's would come in handy on glibc hosts. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Are there valid uses for repoman --ignore-other-arches?
On Sun, 2005-11-27 at 18:08 +0200, Petteri Räty wrote: > --ignore-other-arches Instructs repoman to ignore arches that are not > relevent to the committing arch. REPORT/FIX issues you work around. > > Are there any valid uses for this switch or can it be deprecated? From a > QA point of view this seems like a very bad option. Unless we get proper arch teams for the less used arches like m68k the switch will probably need to exist for a very long time. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] manpages that requires dependencies
On Sun, 27 Nov 2005 23:39:48 +0900 Jason Stubbs <[EMAIL PROTECTED]> wrote: | Core packages or not, they are all broken. When the requirement came | up, the respective maintainers should have spoken up so that a proper | solution could be found. When are the quick hacks going to stop? :| A proper solution requires Portage changes. Unfortunately, for some packages waiting a year or more to fix something isn't an option. -- Ciaran McCreesh : Gentoo Developer (The one that looks before leaping) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 17:49, Ciaran McCreesh wrote: > A proper solution requires Portage changes. Unfortunately, for some > packages waiting a year or more to fix something isn't an option. Maybe not, if we just make man and info two useflags enabled by default in all profiles and change one-by-one the ebuilds that installs man pages or info manuals. The info index regen can go in an eclass, as it's only needed for packages that does install info pages, and they are not so many. Not a simple way, but it would be clean on the long run. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpkL2IJTbgqE.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
On Thursday 24 November 2005 12:31, Diego 'Flameeyes' Pettenò wrote: > What I'm waiting for now are comments if someone has ideas where to put > guides that does not belong directly to an existant project. And if someone > wants to join the effort of documenting maintenance process for his > packages, it would be helpful, too. Trying not to let this idea die, as I still think it might be good in the long run, especially if there's a way to get them collected in a single place. Right now the main problem is that they are spread across projects (at least video/sound projects). Possible solutions I thought of: 1) have every herd controlled by a project, so that the maintainers' guides can be committed there; it would be difficult to find the maintainer's guide for a package this way; 2) have a single repository for maintainers' guides that does not belong to other projects; 3) have a single repository for *every* maintainers' guide. The problem with 1 and 2 is that the maintainers' guides would be difficult to locate in the mess of projects. The problem of 3 is that we have already complex maintainers' guides such as xine's and the one spyderous wrote for X11 herd, that might be difficult to fit in a single organization.. To solve 1's and 2's problem, the solution could be adding a tag to metadata.xml, that carries the URL to the maintainer's guide for the package. It would also make simpler, for example, the case where a single guide is used for more than one package (see always xine's). -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp9xae7VUadb.pgp Description: PGP signature
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
Ned Ludd <[EMAIL PROTECTED]> said: > I really can't give an accurate example. Halcyon who has been testing it > merged world and he was yeilded with 18M of debug info (I have no idea > how many packages he has). Just for the sake of reference, this was with 95 packages and CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe". It is essentially a stage3. Mark pgpkM7nAOcyWJ.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego 'Flameeyes' Pettenò wrote: | Possible solutions I thought of: | | 1) have every herd controlled by a project This should be the goal already, and all herds should be looking to either join or create a project, in conjunction with other herds. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDigitXVaO67S1rtsRAj3MAJ0e94IaRqF3QAlQDBeKU/AJtw1J9ACfZHRf 6PiASl9wYGQ59dQ8HNXTG6I= =80iT -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sun, 2005-27-11 at 13:03 -0500, Mark Loeser wrote: > Ned Ludd <[EMAIL PROTECTED]> said: > > I really can't give an accurate example. Halcyon who has been testing it > > merged world and he was yeilded with 18M of debug info (I have no idea > > how many packages he has). > > Just for the sake of reference, this was with 95 packages and CFLAGS="-O2 > -march=pentium4 -fomit-frame-pointer -pipe". It is essentially a stage3. I have been building stuff with CFLAGS="-O2 -pipe -ggdb" for a while with my own keepdebug/keepsources patch and I have over 475 MB of debug info and 246 MB of source code, but I have 1.5 GB inside /usr/lib .. -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Maintainer's guides?
On Sunday 27 November 2005 20:27, Donnie Berkholz wrote: > This should be the goal already, and all herds should be looking to > either join or create a project, in conjunction with other herds. Okay that probably goes fine for most of the cases, there are still non-herded ebuilds but that's a side problem. Anyway if the organization is non-trivial, the metadata thing is really needed. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpgq6BBJB6tA.pgp Description: PGP signature
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sun, 2005-11-27 at 11:55 -0500, Ned Ludd wrote: > On Sun, 2005-11-27 at 10:44 -0500, Ned Ludd wrote: > > On Sun, 2005-11-27 at 15:22 +, Edward Catmur wrote: > > > On Sun, 2005-11-27 at 08:40 -0500, Ned Ludd wrote: > > > > On Sun, 2005-11-27 at 15:09 +0200, Ivan Yosifov wrote: > > > > > And one more thing. For proper debugging, don't I need the source to > > > > > be > > > > > present ? > > > > > > > > -g3 -ggdb embeds the source code in the debug info so I don't see the > > > > point. > > > > > > It doesn't; at least not with gcc 3.4.4. It does embed function > > > prototypes and macro definitions, though. > > > > > > Ed Catmur > > > > Eh? > > > Never mind you were right Ed. taviso pointed out that dwarf2 doesnt > support embedding the actual source. I was seeing the source due to me > not having deleted the source. > > Guess that is where the debugedit thing of Tester's would come in handy > on glibc hosts. What is this debugedit thing for us non-devs ? IMO portage should have some way to keep the sources around for debugging, for the patch you are proposing to be fully useful. -- Cheers, Ivan Yosifov. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sun, 2005-11-27 at 23:01 +0200, Ivan Yosifov wrote: > On Sun, 2005-11-27 at 11:55 -0500, Ned Ludd wrote: > > On Sun, 2005-11-27 at 10:44 -0500, Ned Ludd wrote: > > > On Sun, 2005-11-27 at 15:22 +, Edward Catmur wrote: > > > > On Sun, 2005-11-27 at 08:40 -0500, Ned Ludd wrote: > > > > > On Sun, 2005-11-27 at 15:09 +0200, Ivan Yosifov wrote: > > > > > > And one more thing. For proper debugging, don't I need the source > > > > > > to be > > > > > > present ? > > > > > > > > > > -g3 -ggdb embeds the source code in the debug info so I don't see the > > > > > point. > > > > > > > > It doesn't; at least not with gcc 3.4.4. It does embed function > > > > prototypes and macro definitions, though. > > > > > > > > Ed Catmur > > > > > > Eh? > > > > > > Never mind you were right Ed. taviso pointed out that dwarf2 doesnt > > support embedding the actual source. I was seeing the source due to me > > not having deleted the source. > > > > Guess that is where the debugedit thing of Tester's would come in handy > > on glibc hosts. > > What is this debugedit thing for us non-devs ? IMO portage should have > some way to keep the sources around for debugging, for the patch you are > proposing to be fully useful. Having the source around or not does not make the splitdebug feature any less useful. debugedit would however enhance some aspects of debugging. See the comments posted at the top of this thread from [EMAIL PROTECTED] on debugedit. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sat, 2005-11-26 at 12:50 -0500, Ned Ludd wrote:
> Good afternoon,
>
> probably in portage-2.0.54 a patch will be added to emit split debug
> info. Having a split debug allows us to retain all the advantages of
> stripping executables while gaining the ability to properly debug
> executables in bfd aware programs. It's been in testing with a small
> hand full of devs and works quite well, but before it's pushed in we
> would like to get input from our devs & users.
>
> Would you be willing to give up space in $ROOT/usr/lib/debug for ELF
> executables by default in order to aid in better debugging by or do we
> want to only emit it when a FEATURE= is defined.
>
> Having a split debug pretty much obsoletes the need to add nostrip to
> your features in order to get debug info.
>
> Users wishing to not have debug info can simply add
> INSTALL_MASK="/usr/lib/debug ${INSTALL_MASK}" to make.conf or the
> environment unless we make it FEATURE based.
>
> I'm in favor of it enabled per default but I'd like to know what you
> think and why. (advantages of on/off by default etc..)
>
> Anybody wanting to test or make use of this feature right away can grab
> a copy of my prepstrip from
> http://dev.gentoo.org/~solar/portage_misc/prepstrip and save it to
> /usr/lib/portage/bin/prepstrip or patch portage with
> http://dev.gentoo.org/~solar/patch_overlay/sys-apps/portage/portage-2.0.53_rc7-prepstrip.patch
> It requires you merge pax-utils for the scanelf util.
>
I would certainly like this as on by default, and controlled via
INSTALL_MASK rather than a FEATURE.
(Although I'd have to rebuild my complete system, since I do have it all
with debug-symbols enabled ;)
//Spider
--
begin .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Split ELF Debug (defult or not?)
maillog: 27/11/2005-13:54:33(+0100): Diego 'Flameeyes' Pettenò types > On Sunday 27 November 2005 00:10, Luca Barbato wrote: > > It's great! > > Make it a FEATURE default on for common profiles. > +1, and it would be better if the FEATURES, instead of removing the generated > files, would disable the building of them completely, mainly because "work" > systems with limited CPU, RAM and HDD space would probably prefer not having > to create and store them :) Wouldn't that break binary packages? I.e., if a binary package is built on a system with FEATURES=-splitdebug and then merged on a system with FEATURES=splitdebug the debug info would be missing. -- \Georgi Georgiev \ "What a wonder is USENET; such wholesale \ / [EMAIL PROTECTED]/ production of conjecture from such a / \ http://www.gg3.net/ \ trifling investment in fact." ale-- Carl \ / --- / S. Gutekunst / pgpWmFZG6nWWG.pgp Description: PGP signature
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Mon, 2005-11-28 at 10:18 +0900, Georgi Georgiev wrote: > maillog: 27/11/2005-13:54:33(+0100): Diego 'Flameeyes' Pettenò types > > On Sunday 27 November 2005 00:10, Luca Barbato wrote: > > > It's great! > > > Make it a FEATURE default on for common profiles. > > +1, and it would be better if the FEATURES, instead of removing the > > generated > > files, would disable the building of them completely, mainly because "work" > > systems with limited CPU, RAM and HDD space would probably prefer not > > having > > to create and store them :) > > Wouldn't that break binary packages? I.e., if a binary package is built > on a system with FEATURES=-splitdebug and then merged on a system with > FEATURES=splitdebug the debug info would be missing. There's nothing to break. The only program that looks for debug symbols is gdb; if they're not there it does what it does currently; print "(no debugging symbols found)". Ed Catmur -- gentoo-dev@gentoo.org mailing list
