Re: [gentoo-dev] RFC: emerge =net-dialup/ppp-2.4.3-r10 will fail requesting for user action
Hello. Although my English is not perfect, may be you like my idea. On Птн, 2005-11-25 at 21:58 +0200, Alin Nastac wrote: > I plan to release a new version of net-dialup/ppp that will add > support for the pppd net module found in > sys-apps/baselayout-/baselayout-1.12.0_pre11. I think it's good idea to add some *reasons* why that files are obsoleted. fex: * Gentoo is moving toward common configuration file for all network * interfaces. Thus starting from >=ppp-2.4.3-r10 the following files * are obsoleted and should be removed to avoid future confusion: > * /etc/conf.d/net.ppp0 - conflict with baselayout > * /etc/init.d/net.ppp0 - conflict with baselayout > * /etc/ppp/chat-default - unused by this version > * /etc/ppp/options-pppoe - unused by this version > * /etc/ppp/options-pptp - unused by this version And so on... Peter. signature.asc Description: This is a digitally signed message part
[gentoo-dev] Removal of auto-use in portage-2.0.54
Hi, 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. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Removal of auto-use in portage-2.0.54
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? Perhaps some of them be moved to the profiles instead? 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? Apart from that, no objections from me - auto-use can be rather confusing at times. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpCqJGKxNm7I.pgp Description: PGP signature
[gentoo-dev] Split ELF Debug (defult or not?)
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.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Saturday 26 November 2005 18:50, 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.
For me either way is good as long as it's well documented in the install
handbook.
A notice for all those upgrading would be fine as well..
> 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.
FEATURE based is probably the best way of doing it...
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), and what tools are compatible
with this external debug info?
> 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..)
>
Having the debug info preserved by default makes it possible for the user to
get debug information which may be used for bug-reporting on program crashes,
but will probably just fill the disk of basic users who do have no interest
in reporting bugs or trying to get more information about the cause of bugs.
Bruno
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (default or not?)
On Sat, 2005-11-26 at 19:30 +0100, Bruno wrote: [snip] > 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. > and what tools are compatible > with this external debug info? gdb being the main one. With tools like valgrind you can simply do. LD_LIBRARY_PATH=/usr/lib/debug valgrind --foo ELF is cool like that. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sat, 2005-26-11 at 12:50 -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..) First, I fully support solar's patch, this feature should have been integrated into portage months ago. > 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. Second, it's often helpful for development to also have the source code of the libraries when debugging a program (like MSFT has done for years). Red Hat also does that, they have built a tool to extract the list of referenced files from the debug info itself. I've made a patch to integrate that tool into portage and an ebuild for the tool. Patch (apply on top of solar's patch): http://dev.gentoo.org/~tester/prepstrip-keep-sources.patch Fully patched prepstrip: http://dev.gentoo.org/~tester/prepstrip The debugedit ebuild is at: http://dev.gentoo.org/~tester/debugedit-4.4.3-ebuild.tar.bz2 -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
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.
>
>
> --
> Ned Ludd <[EMAIL PROTECTED]>
> Gentoo Linux
+1 for default
IMO it should be on by default but documented in bold in the install
guide for those who wish to disable it. It makes sense to able to debug
a problem right away rather than having to reemerge things first, to get
the debugging info.
How much disk space should the debug info consume ?
--
Cheers,
Ivan Yosifov.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Split ELF Debug (defult or not?)
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? I like on-by-default, along with a feature option to turn it off. --de. -- 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: > 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. would make more sense to have it be a FEATURE and then put the FEATRE into our profiles that way users can disable it via standard make.conf config rather than having to add some weird INSTALL_MASK setting -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] festival use flag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, The following packages have festival as a use flag: media-plugins/mythphone:festival - Enable festival support media-radio/xastir:festival - Enable festival support I would like to add this use flag to app-accessibility/speech-dispatcher also. Is 3 packages enough to move this use flag to global status? If so, I will do this if I hear no objections by Monday. Thanks, William -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDiMTkblQW9DDEZTgRAv12AJ9sclzbN/mW3ppGyO3gYosac1pO3gCdHbDT 9JkVmLLTTswC0+HisWPqx3A= =e0th -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] festival use flag
William Hubbs wrote: > All, > > The following packages have festival as a use flag: > > media-plugins/mythphone:festival - Enable festival support > media-radio/xastir:festival - Enable festival support > > I would like to add this use flag to > app-accessibility/speech-dispatcher also. > > Is 3 packages enough to move this use flag to global status? If so, I > will do this if I hear no objections by Monday. > > Thanks, > > William > I don't think so. Especially when all of those are not something very core system. The amount of global use flags is already quite long. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: festival use flag
Petteri Räty posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 26 Nov 2005 22:40:38 +0200: > William Hubbs wrote: >> All, >> >> The following packages have festival as a use flag: >> >> media-plugins/mythphone:festival - Enable festival support >> media-radio/xastir:festival - Enable festival support >> >> I would like to add this use flag to >> app-accessibility/speech-dispatcher also. >> >> Is 3 packages enough to move this use flag to global status? If so, I >> will do this if I hear no objections by Monday. >> > I don't think so. Especially when all of those are not something very core > system. The amount of global use flags is already quite long. >From past comments I've read, here, three packages with the same USE flag is absolute minimum to start considering it global, but it's not really accepted at that. Five is the more accepted minimum. -- 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 (defult or not?)
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
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] festival use flag
On Sunday 27 November 2005 05:26, William Hubbs wrote: > All, > > The following packages have festival as a use flag: > > media-plugins/mythphone:festival - Enable festival support > media-radio/xastir:festival - Enable festival support > > I would like to add this use flag to > app-accessibility/speech-dispatcher also. > > Is 3 packages enough to move this use flag to global status? If so, I > will do this if I hear no objections by Monday. Actually, please see this bug as well: http://bugs.gentoo.org/show_bug.cgi?id=113500 remember that there's festival and festival lite (festival and flite), which somewhat do the same thing with regards to tts. In fact, this is somewhat needed for kde-base/kttsd to work properly, as it needs the appropriate tts daemon to provide its services. Chris White pgpvg9zXOOFCN.pgp Description: PGP signature
Re: [gentoo-dev] Split ELF Debug (defult or not?)
Ned Ludd wrote: [snip] It's great! Make it a FEATURE default on for common profiles. lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On 11/26/05, Petteri Räty <[EMAIL PROTECTED]> 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.
Well, only on x86 and other lacking arches...
>
> Regards,
> Petteri
>
>
>
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sat, 2005-11-26 at 19:48 -0500, Dan Meltzer wrote:
> On 11/26/05, Petteri Räty <[EMAIL PROTECTED]> 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.
>
> Well, only on x86 and other lacking arches...
Please note that gcc4 generates location lists by default (at least on
debug builds). This should allow for debugging on x86 with
-fomit-frame-pointers. Not sure how that works in relation to split ELF
debug files.
http://gnu.paradoxical.co.uk/software/gcc/gcc-4.0/changes.html
"Location lists are now generated by default when compiling with debug
info and optimization. Location lists provide more accurate debug info
about locations of variables and they allow debugging code compiled with
-fomit-frame-pointer."
Of course gcc4 isn't even ~x86 yet... ;)
--
With regards,
Mart Raudsepp
Project manager of wxMUD - http://wxmud.sourceforge.net/
Developer of wxWidgets - http://www.wxwidgets.org/
Gtk+ port maintainer of cpaf - http://cpaf.berlios.de/
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] last rites for avifile, vcr, zphoto, drip, divx4linux, quicktime4linux
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. lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: emerge =net-dialup/ppp-2.4.3-r10 will fail requesting for user action
Volkov Peter wrote: >I think it's good idea to add some *reasons* why that files are >obsoleted. > >fex: > >* Gentoo is moving toward common configuration file for all network >* interfaces. Thus starting from >=ppp-2.4.3-r10 the following files >* are obsoleted and should be removed to avoid future confusion: > > > sounds great, message replaced. signature.asc Description: OpenPGP digital signature
