[gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Hi, I have founded a new Gentoo Project for the Gentoo User Overlay. The intention is to give contributors a single place to put their ebuilds - a place where they can be downloaded, updated and be moved to portage more easily than through bugzilla. It is also a good place for users who would like to become developers to learn how to commit and how to not break the tree. You can find the project page as a subproject of the overlays project [1] The overlay is available on overlays.gentoo.org [2] Initially jokey and myself will be working on this. The current focus is to migrate ebuilds from bugzilla into the overlay and to get contributors to commit their changes to the overlay instead of updating the bugzilla every time. Anyone who wants to help, please stop by in #gentoo-overlays @ freenode [1] http://gentoo.org/proj/en/overlays/sunrise [2] http://overlays.gentoo.org/svn/proj/sunrise - Stefan PS: This is an announcement - No flamewars allowed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
Jakub Moc wrote: > Olivier Crete wrote: >> Is there a recent list of non-ported packages ? Maybe we should do a >> last effort to port everything for a week or two and then package.mask >> the packages that no one cares enough about to port them. > > Hmmm, not a up2date one, AFAIK... There's a tracker bug > > http://bugs.gentoo.org/show_bug.cgi?id=112675 > > and below is the most recent list from spyderous I was able to find (no > idea how much relevant it still is). > > http://dev.gentoo.org/~spyderous/broken_modular/broken_modular.txt.20060315 I can probably generate one tonight. Need to dig up the scripts, and I've got an emerge -e world running in the background. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
Ned Ludd wrote: On Wed, 2006-06-07 at 16:05 -0400, Alec Warner wrote: We've discussed this multiple times, and it's always been the conclusion that per package.env should go in bashrc, as bashrc is generally more powerful than anything we could devise. The only downside afaik, for bashrc is that you can't do per package FEATURES as FEATURES is a python-side var. But you shouldn't need per package FEATURES by design; FEATURES are for portage, not your ebuild. This is a thumbs up? I've got the code sitting in my $PORTDIR/profiles/base/profile.bashrc to give us just this. I'd be all to happy to commit it. So that's a yes right? :) As I told you on IRC, it's not your job to listen to the portage devs on this one, you know what was intended for that support, we've argued over it a dozen times. There is nothing we can do to stop you from "mis-using" something in portage, aside from complaining and removing it in the next version. I believe we have made our recommendation and you know what we think you should do, but we are not Gentoo. I would be more concerned with convincing the rest of the developers. adding crap in base profile.bashrc will affect 99% of users, so it better be friggin correct and useful, otherwise you will piss a ton of people off. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
Olivier Crete wrote: > Is there a recent list of non-ported packages ? Maybe we should do a > last effort to port everything for a week or two and then package.mask > the packages that no one cares enough about to port them. Hmmm, not a up2date one, AFAIK... There's a tracker bug http://bugs.gentoo.org/show_bug.cgi?id=112675 and below is the most recent list from spyderous I was able to find (no idea how much relevant it still is). http://dev.gentoo.org/~spyderous/broken_modular/broken_modular.txt.20060315 -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
On Wed, 2006-06-07 at 16:05 -0400, Alec Warner wrote: > We've discussed this multiple times, and it's always been the conclusion > that per package.env should go in bashrc, as bashrc is generally more > powerful than anything we could devise. The only downside afaik, for > bashrc is that you can't do per package FEATURES as FEATURES is a > python-side var. But you shouldn't need per package FEATURES by design; > FEATURES are for portage, not your ebuild. This is a thumbs up? I've got the code sitting in my $PORTDIR/profiles/base/profile.bashrc to give us just this. I'd be all to happy to commit it. So that's a yes right? :) -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
On Thu, 2006-06-08 at 05:26 +0930, Raymond Lewis Rebbeck wrote: > > Is there a recent list of non-ported packages ? Maybe we should do a > > last effort to port everything for a week or two and then package.mask > > the packages that no one cares enough about to port them. > > games-roguelike/slashem is one package that I know of. It should have very > similar dependencies to nethack. It is also already masked. We'll update it once we get a proper solution to the security bug that caused it to be masked. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
Alec Warner <[EMAIL PROTECTED]> writes: > The only downside afaik, for bashrc is that you can't do per package > FEATURES as FEATURES is a python-side var. But you shouldn't need > per package FEATURES by design; FEATURES are for portage, not your > ebuild. >From the perspective of a user, not a developer (though I have been a programmer for over 25 years), it would sometimes be useful to set some features on a per package basis rather than globally. These include binpkg, nostrip, splitdebug and test. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SATA disk slower as /dev/sda then as in /dev/hda
Mivz wrote: /dev/sda: Timing cached reads: 1424 MB in 2.00 seconds = 711.96 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Timing buffered disk reads: 114 MB in 3.00 seconds = 37.95 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Now I tryed a old Gentoo 1.4-rc1 livecd, cause this one loads the disk still as /dev/hda and not sda. After enabling dma, 32bit io and udma: hdparm -X66 -c1 -d1 It had a speed of 2560.00 MB/sec bufferd and 37,65 unbufferd. The unbuffered speed is identical, the cached read is the only difference. Cached reads are not a test of hard disk performance, this is a mostly useless benchmark (note that on that metric, your cdrom drive performs at the same speed as your hard disk...) Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: > debug-build can always be expanded to turn on generic debugging > for other build systems and languages. Really? Perhaps you can explain the implementation details a little more, because it's not obvious to me. From my perspective a package level debug-build USE flag models the desired functionality much better than a package manager level FEATURE. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEhzdL/ejvha5XGaMRAsKYAJ44xOQPuMNPyhZwSPhb7Y2ywCC5bQCdHHzU 5EKsxkielr/7eyaOp6oOXqk= =/vtf -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SATA disk slower as /dev/sda then as in /dev/hda
On Wed, Jun 07, 2006 at 10:07:07PM +0200, Mivz wrote: > Why is it that when I use the new kernel SATA drivers and load is as > /dev/sda it is slower as with the old IDE drivers? You didn't tell us which sata drivers you were using, nor what kernel version. Either way, try asking this on the linux-kernel or linux-ide mailing lists, gentoo-dev isn't the right place for it. good luck, greg k-h -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grant Goodyear wrote: > Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT] >> Mike Frysinger wrote: >>> this is a *huge* con ... developers are lazy, *i'm* lazy ... i >>> certainly do not want to go through every single package i maintain >>> and add 'debug-build' to IUSE or 'inherit some-new-eclass' >> Sometimes it takes a little extra work to do things right, but >> hopefully it will pay off in the long run. A poor design decision >> made now can haunt us for years to come. > > A "little extra work"? I'm pretty sure that such an eclass would be > required for better than half the tree (every package that contains some > C or C++). If almost everybody has to add the same piece of > boilerplate to their ebuilds, then perhaps a sane package manager should > be able to figure out what to do without the boilerplate. That It's a slippery slope when we start to incorporate special cases like that into a generic package manager. Where does it end? The same argument could be made again and again to add more special cases that further pollute the package manager. We already have a standard solution for cases such as this, and that is to share the specialized functionality via an eclass. > rationale seems especially true in this case, where nostrip and > debugging flags will do no harm for packages that aren't C or C++. >>> if the large majority of packages are going to be taking advantage of a >>> feature, isnt the logical thing to opt everyone in rather than forcing the >>> majority to opt themselves in ? >> It really depends on the pros/cons applying something on a *global* >> scale, like you propose. A package manager (such as portage) will >> never be able to make debug-build decisions that work well for *every* >> ebuild. That's why it's better for ebuilds to make those decisions >> themselves (with the help of eclasses). > > I would think that your argument would depend on the probability of a > package being an exception to the general rule. How many packages > actually fail to do what is expected when compiled with -g and nostrip > (noting that those cases without binaries to strip don't count)? > Unless that percentage is significant, then I would think that a simple > solution that handles the common case is a very good thing. Again, it's a slippery slope... > Wouldn't the "simple" solution be to have package.* files that allow the > user to specify FEATURES, CFLAGS, and CXXFLAGS per package? (Of course, > I do realize that it's the lack of such files that lead vapier to > propose his solution, which is rather more convenient for one-off > builds.) Well, I'd say that per-package environment variables would be a better way to implement per-package CFLAGS, CXXFLAGS, etc.. There is a patch attached to bug 44796 that implements this. Note that the debug-build.bashrc attached to my last post actually allows per-package debug-build via package.use. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEhzK3/ejvha5XGaMRAufAAKDm2l8429xS14uPjbYV7Ky5dlFGHgCggXXH rBVkHEMCcJZflR13vA26kog= =DXg0 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] SATA disk slower as /dev/sda then as in /dev/hda
Hello, I have a Intel SATA controler in my laptop and it is adressed as /dev/sda. My cdrom is /dev/hdc. My cdrom drive I can configure with hdparm to use dma and 32-bit io and it has a nice speed: /dev/hdc: Timing cached reads: 1408 MB in 2.00 seconds = 702.55 MB/sec Timing buffered disk reads:4 MB in 5.56 seconds = 736.64 kB/sec I can not use hdparm to configure /dev/sda, also sdparm can not set anything: sdparm --set UDMA6=1 /dev/sg0 /dev/sg0: ATA HTS726060M9AT00 MH4O change_mode_page: failed setting page: SAT pATA control This happens with all options, also awre, arre and wce. The speed of this disk: /dev/sda: Timing cached reads: 1424 MB in 2.00 seconds = 711.96 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Timing buffered disk reads: 114 MB in 3.00 seconds = 37.95 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Now I tryed a old Gentoo 1.4-rc1 livecd, cause this one loads the disk still as /dev/hda and not sda. After enabling dma, 32bit io and udma: hdparm -X66 -c1 -d1 It had a speed of 2560.00 MB/sec bufferd and 37,65 unbufferd. It was almost 4 times as fast. Why is it that when I use the new kernel SATA drivers and load is as /dev/sda it is slower as with the old IDE drivers? Mivz -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
Grant Goodyear wrote: Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT] Mike Frysinger wrote: this is a *huge* con ... developers are lazy, *i'm* lazy ... i certainly do not want to go through every single package i maintain and add 'debug-build' to IUSE or 'inherit some-new-eclass' Sometimes it takes a little extra work to do things right, but hopefully it will pay off in the long run. A poor design decision made now can haunt us for years to come. A "little extra work"? I'm pretty sure that such an eclass would be required for better than half the tree (every package that contains some C or C++). If almost everybody has to add the same piece of boilerplate to their ebuilds, then perhaps a sane package manager should be able to figure out what to do without the boilerplate. That rationale seems especially true in this case, where nostrip and debugging flags will do no harm for packages that aren't C or C++. I tend to agree here on pragmatic principal as opposed to bowing to "this is the ideal case" that some members of the portage team seem to want. debug-build can always be expanded to turn on generic debugging for other build systems and languages. I realize it's not the "perfect solution." But no one has implemented a better one. People only wait so long for things before getting fed up and saying "it's going in anyway." if the large majority of packages are going to be taking advantage of a feature, isnt the logical thing to opt everyone in rather than forcing the majority to opt themselves in ? It really depends on the pros/cons applying something on a *global* scale, like you propose. A package manager (such as portage) will never be able to make debug-build decisions that work well for *every* ebuild. That's why it's better for ebuilds to make those decisions themselves (with the help of eclasses). I would think that your argument would depend on the probability of a package being an exception to the general rule. How many packages actually fail to do what is expected when compiled with -g and nostrip (noting that those cases without binaries to strip don't count)? Unless that percentage is significant, then I would think that a simple solution that handles the common case is a very good thing. Wouldn't the "simple" solution be to have package.* files that allow the user to specify FEATURES, CFLAGS, and CXXFLAGS per package? (Of course, I do realize that it's the lack of such files that lead vapier to propose his solution, which is rather more convenient for one-off builds.) We've discussed this multiple times, and it's always been the conclusion that per package.env should go in bashrc, as bashrc is generally more powerful than anything we could devise. The only downside afaik, for bashrc is that you can't do per package FEATURES as FEATURES is a python-side var. But you shouldn't need per package FEATURES by design; FEATURES are for portage, not your ebuild. -g2boojum- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
On Thursday, 8 June 2006 5:15, Olivier Crete wrote: > On Wed, 2006-07-06 at 18:41 +0200, Jakub Moc wrote: > > Arek (James Potts) wrote: > > > Donnie Berkholz wrote: > > >>> >=virtual/x11-7 is hiding breakage in ebuilds that are not ported for > > >>> > > >>> modular X. > > >> > > >> I couldn't agree more, but I was forced to add this rather than allow > > >> unported ebuilds to break. > > > > > > Hmmm...Looks to me like it would be a great idea to fix the unported > > > ebuilds. Would it be possible to mark virtual/x11-7 as deprecated > > > (using enotice/ewarn or similar), in order to get people to port any > > > build relying on it to modular X? > > > > > > The way I see it, once virtual/x11-7 has been deprecated for a while (6 > > > months to a year) and most popular packages have been ported to modular > > > X, virtual/x11-7 and any packages still relying on it could be given > > > Last Rites. > > > > Hmm, I don't think so... There's been a plenty of time to do this when > > modular X has been package.masked, the remaining unported stuff didn't > > get much further even after it's been unmasked. There's been a > > (debatable) repoman check, which has been too annoying so devs nuked it > > for themselves, now it's non-fatal warning again (which is mostly being > > ignored). > > > > S - I'd pretty much say until the real breakage is *visible* and > > users start to scream - not much will change. Making it visible could > > also help us differentiate between used and used stuff. If there's > > something unported and you get no bug, then probably noone uses the > > thing, nothing depends on it and it can be punted from the tree. > > Is there a recent list of non-ported packages ? Maybe we should do a > last effort to port everything for a week or two and then package.mask > the packages that no one cares enough about to port them. games-roguelike/slashem is one package that I know of. It should have very similar dependencies to nethack. -- Raymond Lewis Rebbeck -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
On Wed, 2006-07-06 at 18:41 +0200, Jakub Moc wrote: > Arek (James Potts) wrote: > > Donnie Berkholz wrote: > >>> >=virtual/x11-7 is hiding breakage in ebuilds that are not ported for > >>> modular X. > > >> I couldn't agree more, but I was forced to add this rather than allow > >> unported ebuilds to break. > > > Hmmm...Looks to me like it would be a great idea to fix the unported > > ebuilds. Would it be possible to mark virtual/x11-7 as deprecated > > (using enotice/ewarn or similar), in order to get people to port any > > build relying on it to modular X? > > > > The way I see it, once virtual/x11-7 has been deprecated for a while (6 > > months to a year) and most popular packages have been ported to modular > > X, virtual/x11-7 and any packages still relying on it could be given > > Last Rites. > > Hmm, I don't think so... There's been a plenty of time to do this when > modular X has been package.masked, the remaining unported stuff didn't > get much further even after it's been unmasked. There's been a > (debatable) repoman check, which has been too annoying so devs nuked it > for themselves, now it's non-fatal warning again (which is mostly being > ignored). > > S - I'd pretty much say until the real breakage is *visible* and > users start to scream - not much will change. Making it visible could > also help us differentiate between used and used stuff. If there's > something unported and you get no bug, then probably noone uses the > thing, nothing depends on it and it can be punted from the tree. Is there a recent list of non-ported packages ? Maybe we should do a last effort to port everything for a week or two and then package.mask the packages that no one cares enough about to port them. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT] > Mike Frysinger wrote: > > this is a *huge* con ... developers are lazy, *i'm* lazy ... i > > certainly do not want to go through every single package i maintain > > and add 'debug-build' to IUSE or 'inherit some-new-eclass' > > Sometimes it takes a little extra work to do things right, but > hopefully it will pay off in the long run. A poor design decision > made now can haunt us for years to come. A "little extra work"? I'm pretty sure that such an eclass would be required for better than half the tree (every package that contains some C or C++). If almost everybody has to add the same piece of boilerplate to their ebuilds, then perhaps a sane package manager should be able to figure out what to do without the boilerplate. That rationale seems especially true in this case, where nostrip and debugging flags will do no harm for packages that aren't C or C++. > > if the large majority of packages are going to be taking advantage of a > > feature, isnt the logical thing to opt everyone in rather than forcing the > > majority to opt themselves in ? > > It really depends on the pros/cons applying something on a *global* > scale, like you propose. A package manager (such as portage) will > never be able to make debug-build decisions that work well for *every* > ebuild. That's why it's better for ebuilds to make those decisions > themselves (with the help of eclasses). I would think that your argument would depend on the probability of a package being an exception to the general rule. How many packages actually fail to do what is expected when compiled with -g and nostrip (noting that those cases without binaries to strip don't count)? Unless that percentage is significant, then I would think that a simple solution that handles the common case is a very good thing. Wouldn't the "simple" solution be to have package.* files that allow the user to specify FEATURES, CFLAGS, and CXXFLAGS per package? (Of course, I do realize that it's the lack of such files that lead vapier to propose his solution, which is rather more convenient for one-off builds.) -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp5cgkviFCsQ.pgp Description: PGP signature
Re: [gentoo-dev] [Last Rites ipkg-utils]
Hi All, Just to let you know: ipkg-utils' last rites have been postponed indefinitely. James Rowe and I will be maintaining it from here on in. Thanks James! Thanks all, Seemant -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
> On Wednesday 07 June 2006 11:13, Brian Harring wrote:
>> 1) requires modifying the tree, and introduction of eclass for it.
>
> this is a *huge* con ... developers are lazy, *i'm* lazy ... i certainly do
> not want to go through every single package i maintain and add 'debug-build'
> to IUSE or 'inherit some-new-eclass'
Sometimes it takes a little extra work to do things right, but hopefully it
will pay off in the long run. A poor design decision made now can haunt us for
years to come.
> if the large majority of packages are going to be taking advantage of a
> feature, isnt the logical thing to opt everyone in rather than forcing the
> majority to opt themselves in ?
It really depends on the pros/cons applying something on a *global* scale, like
you propose. A package manager (such as portage) will never be able to make
debug-build decisions that work well for *every* ebuild. That's why it's
better for ebuilds to make those decisions themselves (with the help of
eclasses).
Sure, it will take some work to make those changes to ebuilds, but it will be
worth the effort in the long run. I've attached a script that you can use for
/etc/portage/bashrc that provides the same functionality as your debug-build
feature. You can use it as an interim solution until USE=debug-build support
has been added to all of the ebuilds that would benefit from it.
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFEhxtN/ejvha5XGaMRAlRuAJ0Q0/p6Tq1k/+N3ejzScYsAe8TgvgCg3Wym
EpgniVng6MItb8uxtJLk5Ac=
=2nT/
-END PGP SIGNATURE-
#!/usr/bin/env bash
hasq() {
[[ " ${*:2} " == *" $1 "* ]]
}
if hasq debug-build ${USE}; then
[ -z "${DEBUG_CFLAGS}" ] && export DEBUG_CFLAGS="-g -O"
[ -z "${DEBUG_CXXFLAGS}" ] && export DEBUG_CXXFLAGS="${DEBUG_CFLAGS}"
for x in CFLAGS CXXFLAGS LDFLAGS; do
eval "export ${x}=\"\${DEBUG_${x}}\""
done
if ! hasq splitdebug ${FEATURES}; then
export FEATURES="${FEATURES} nostrip"
fi
fi
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
Arek (James Potts) wrote: > Donnie Berkholz wrote: >>> >=virtual/x11-7 is hiding breakage in ebuilds that are not ported for >>> modular X. >> I couldn't agree more, but I was forced to add this rather than allow >> unported ebuilds to break. > Hmmm...Looks to me like it would be a great idea to fix the unported > ebuilds. Would it be possible to mark virtual/x11-7 as deprecated > (using enotice/ewarn or similar), in order to get people to port any > build relying on it to modular X? > > The way I see it, once virtual/x11-7 has been deprecated for a while (6 > months to a year) and most popular packages have been ported to modular > X, virtual/x11-7 and any packages still relying on it could be given > Last Rites. Hmm, I don't think so... There's been a plenty of time to do this when modular X has been package.masked, the remaining unported stuff didn't get much further even after it's been unmasked. There's been a (debatable) repoman check, which has been too annoying so devs nuked it for themselves, now it's non-fatal warning again (which is mostly being ignored). S - I'd pretty much say until the real breakage is *visible* and users start to scream - not much will change. Making it visible could also help us differentiate between used and used stuff. If there's something unported and you get no bug, then probably noone uses the thing, nothing depends on it and it can be punted from the tree. On a side note, this virtual also hides potential bugs in ebuilds that already have been ported, you can miss dependencies there if you have already them emerged b/c of the virtual. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
On Wednesday 07 June 2006 11:13, Brian Harring wrote: > Resurrecting this issue (yet another round) since FEATURES=debug-build > was shoved in... yes, i forced the issue after requesting feedback several times and getting no further blocking input > 1) flip on nostrip in the restrict. > > For #1, use conditional support was added to portage somewhere around > 2.0.51_pre18; support is still there, so you can use > RESTRICT="debug-build? ( nostrip )" now. FEATURES=debug-build already takes care of the nostrip/splitdebug logic ... you'd rather have us add that one conditional line to every ebuild ? > 2) adjust CX*FLAGS, LDFLAGS > > As for #2, we already have eclasses mangling flags, this is no > different. sure it is ... again, you'd have us utilize the eclass in every single package instead of having a sane default via portage for everything ? > Two approaches to this- > 1) FEATURES="debug-build". > pros: > 1) doesn't require modifying anything in the tree. everyone gets it for free > cons: > 1) no way to know if the feature will actually affect a pkg (won't >do jack to a pure python/perl/shell/ruby pkg, no point in even >trying) true, but do you really expect debug output from shell scripts > 2) FEATURES are not controllable via any package.* file. only because the portage guys have refused to implement what many people have requested over and over, telling them to use bashrc hacks instead > 3) pkgs that support debug builds, but are not affected by trying to >set a default set of *FLAGS have to now go and check FEATURES to >discern if they should produce a debug build. like what ? whether you're checking USE or FEATURES, it's the same thing > 4) no way to make the debug-build option associative to deps; simple >example, consider mysql python bindings. Debug info there quite >likely isn't all that useful for a segfault- if the horkage occurs >in mysql, you just get the usual ?? backtrace, and wind up having >to take a second manual step of rebuilding mysql with debug >enabled. how is this specific to using FEATURES ? you have to manually rebuild the deps whether you use USE or FEATURES > 5) cannot control the setting per package. way to duplicate (2) so that the cons list would be bigger than your pro list below > 2) USE="debug-build" > pros: > 1) it's explicit. if the package can generate a debug-build version >of itself, you see the debug-build flag in it's IUSE. true > 2) appropriate designed eclass, ebuild can specify up front any >nonstandard *flags additions that should be made- for example, >ciaran's suggestion to mangle CXXFLAGS when dealing with STL so >that the result is useful. the flags ciaran suggested would be useful for all of C++, regardless of STL >Possible via FEATURES, but ebuild would >have to test features for it (something it should be mostly unaware >of, features are mainly pkg manager directives, not ebuild). i dont get it ... are you arguing for FEATURES=debug-build or USE=debug-build here ? > 3) via use deps, it's possible to address 1.4 from above- >python-mysql can just slip in a >"debug-build? ( dev-db/mysql[debug-build] )", one less manual step >required. sounds like you're duplicating the work of RDEPEND split that people have already decided on doing > 4) use flags can be controlled per package via package.use; you can >force $YOUR_PERSONAL_PROJECT to always be built with debug symbols >cleanly. which is a moot point once portage peeps actually implement a package.env > cons: > 1) requires modifying the tree, and introduction of eclass for it. this is a *huge* con ... developers are lazy, *i'm* lazy ... i certainly do not want to go through every single package i maintain and add 'debug-build' to IUSE or 'inherit some-new-eclass' if the large majority of packages are going to be taking advantage of a feature, isnt the logical thing to opt everyone in rather than forcing the majority to opt themselves in ? > 2) existing USE="debug" (namely nano) is used to enable runtime >changes, asserts, etc; would have two sets of flags, debug-build >and runtime changes (debug flag). how is this a con ? you provide no way of letting this useful runtime debug code from being enabled -mike pgpEodlK3Q9Gd.pgp Description: PGP signature
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
Donnie Berkholz wrote: Jakub Moc wrote: =virtual/x11-7 is hiding breakage in ebuilds that are not ported for modular X. I couldn't agree more, but I was forced to add this rather than allow unported ebuilds to break. Thanks, Donnie Hmmm...Looks to me like it would be a great idea to fix the unported ebuilds. Would it be possible to mark virtual/x11-7 as deprecated (using enotice/ewarn or similar), in order to get people to port any build relying on it to modular X? The way I see it, once virtual/x11-7 has been deprecated for a while (6 months to a year) and most popular packages have been ported to modular X, virtual/x11-7 and any packages still relying on it could be given Last Rites. --Arek -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
Jakub Moc wrote: >> =virtual/x11-7 is hiding breakage in ebuilds that are not ported for > modular X. I couldn't agree more, but I was forced to add this rather than allow unported ebuilds to break. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] fix binary debug support, part elevenity billion + 1
Resurrecting this issue (yet another round) since FEATURES=debug-build was shoved in... Background info- http://thread.gmane.org/gmane.linux.gentoo.devel/35202/focus=35212 Quick summary, there needs to be an easy way to flag on essentially "leave the symbols intact/don't mangle the code too much for this build"; needs a few things- 1) flip on nostrip in the restrict. 2) adjust CX*FLAGS, LDFLAGS For #1, use conditional support was added to portage somewhere around 2.0.51_pre18; support is still there, so you can use RESTRICT="debug-build? ( nostrip )" now. As for #2, we already have eclasses mangling flags, this is no different. Two approaches to this- 1) FEATURES="debug-build". pros: 1) doesn't require modifying anything in the tree. cons: 1) no way to know if the feature will actually affect a pkg (won't do jack to a pure python/perl/shell/ruby pkg, no point in even trying) 2) FEATURES are not controllable via any package.* file. 3) pkgs that support debug builds, but are not affected by trying to set a default set of *FLAGS have to now go and check FEATURES to discern if they should produce a debug build. 4) no way to make the debug-build option associative to deps; simple example, consider mysql python bindings. Debug info there quite likely isn't all that useful for a segfault- if the horkage occurs in mysql, you just get the usual ?? backtrace, and wind up having to take a second manual step of rebuilding mysql with debug enabled. 5) cannot control the setting per package. 2) USE="debug-build" pros: 1) it's explicit. if the package can generate a debug-build version of itself, you see the debug-build flag in it's IUSE. 2) appropriate designed eclass, ebuild can specify up front any nonstandard *flags additions that should be made- for example, ciaran's suggestion to mangle CXXFLAGS when dealing with STL so that the result is useful. Possible via FEATURES, but ebuild would have to test features for it (something it should be mostly unaware of, features are mainly pkg manager directives, not ebuild). 3) via use deps, it's possible to address 1.4 from above- python-mysql can just slip in a "debug-build? ( dev-db/mysql[debug-build] )", one less manual step required. 4) use flags can be controlled per package via package.use; you can force $YOUR_PERSONAL_PROJECT to always be built with debug symbols cleanly. cons: 1) requires modifying the tree, and introduction of eclass for it. 2) existing USE="debug" (namely nano) is used to enable runtime changes, asserts, etc; would have two sets of flags, debug-build and runtime changes (debug flag). Now... not to hard to figure out from above which route I prefer, but that *should* be an accurate pro/con of the two routes for this. Note also that common pros/cons are exempted; fex, ability to specify via profile default debug *flags. So... kindly state which you view as best. Thoughts? ~harring pgpDUQR0mmJHi.pgp Description: PGP signature
Re: [gentoo-dev] maybe im wrong here but nsswitch and udev
On Tue, June 6, 2006 20:45, Greg KH wrote: > On Tue, Jun 06, 2006 at 11:05:00AM -0700, Robin H. Johnson wrote: > >> The udev/nss_ldap thing has been brewing for a while, and we're still >> trying to get upstream udev to fix the issue. >> http://bugs.gentoo.org/show_bug.cgi?id=99564#c44 >> >> >> In that comment I list the proper solution that upstream needs to >> undertake (make udev not lookup nss entries unless it is actually >> creating device nodes that need the entries), and some other >> workarounds. > > "upstream" agrees that this is the proper solution, yet no one has sent > a patch to fix this yet. Combine this with a lack of free time to work on > things like this by upstream, and we have a stalled bug :) thanks cheers and i thought i was stupid or my box broke Juergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gcc-config added to info_pkgs
On Wednesday 07 June 2006 07:49, Henrik Brix Andersen wrote: > On Wed, Jun 07, 2006 at 07:11:16AM -0400, Mike Frysinger wrote: > > so i dont have to chase down bugs caused by new eselect-compiler, ive > > added gcc-config to profiles/info_pkgs > > Did you mean you're going to add it? I don't see it there yet... i'm slow and want to see if anyone complains :p -mike pgpoFMPBrW3Xq.pgp Description: PGP signature
Re: [gentoo-dev] gcc-config added to info_pkgs
On Wed, Jun 07, 2006 at 07:11:16AM -0400, Mike Frysinger wrote: > so i dont have to chase down bugs caused by new eselect-compiler, ive added > gcc-config to profiles/info_pkgs Did you mean you're going to add it? I don't see it there yet... Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpqGwPFI2Cy7.pgp Description: PGP signature
[gentoo-dev] gcc-config added to info_pkgs
so i dont have to chase down bugs caused by new eselect-compiler, ive added gcc-config to profiles/info_pkgs -mike pgptgwwef7F3Y.pgp Description: PGP signature
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
@4u wrote: > After posting and closing the bug report: > http://bugs.gentoo.org/show_bug.cgi?id=135870 > Jakub Moc noticed that the current >=virtual/x11-7.0 ebuild misses its > task and creates trouble. Indeed. To re-iterate here, I'll basically re-paste what I've said on the bug, so that people don't have to jump to bugs.g.o.: >=virtual/x11-7 is hiding breakage in ebuilds that are not ported for modular X. The side effect is that dependencies like X? ( || ( foo bar baz ) virtual/x11 ) fail once virtual/x11 gets emerged by one of those broken ebuilds, because the dependency is already satisfied by virtual/x11. If that virtual doesn't depend on either of foo bar baz, then the dependency doesn't get emerged and a perfectly valid ebuild without any missing dependencies fails. > For example: This ebuild behaves partly like a ordinary meta build and > installs imake. You need imake (more correctly xmfmk) to install tightvnc. Yeah, as it is now, it's essentially a dumpspace for redundant dependencies that are already stated in ebuilds fixed for modular X, but that frequently don't get installed b/c of the problem described above. We are mis-using a 'new style' virtual to produce yet another metabuild that serves the only purpose - to hide borkage. > For that reason I want to request the deletion of virtual/x11-7.0 and > that at least some dependencies of virtual/x11 are moved to > =>x11-base/xorg-x11-7.0 where these dependencies belong to IMHO. > xorg-x11 is a meta ebuild. Each ebuild should state its own dependencies. x11-base/xorg-x11 is a metabuild for users' convenience, which should produce a pretty full-featured X server install, but nothing more. It's not a dumpspace for whatever redundant dependencies either. So - IMHO we should stop shoving the real breakage under the carpet, if ebuilds are not ported for modular X, they are broken and should be fixed. If noone cares to fix them enough for some time, they'll probably need to be package.masked and subsequently removed from the tree. Until then, they'll bomb out, because they are broken, that's a perfectly expected behaviour... What we are instead doing now, is hiding the breakage by misusing virtual/x11-7 to emerge most frequently missing deps, which is bloating more and more, as more and more not broken ebuilds are hit by the redundant virtual. Not good, really. Some examples of needless borkage include: http://bugs.gentoo.org/show_bug.cgi?id=123071 http://bugs.gentoo.org/show_bug.cgi?id=127617 http://bugs.gentoo.org/show_bug.cgi?id=128163 http://bugs.gentoo.org/show_bug.cgi?id=128353 http://bugs.gentoo.org/show_bug.cgi?id=128354 (plus numerous duplicates). While the above bugs are marked fixed, they won't be really fixed until >=virtual/x11-7 goes to /dev/null and stops causing more harm than good. Sorry for a long post, but this problem really needs to be addressed. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eselect-compiler updates and unmasking
On Jun 7, 2006, at 02:47 , Mike Frysinger wrote: On Tuesday 06 June 2006 18:39, Jeremy Huddleston wrote: Uhm, what is this all about? If you have suggestions, make them, but don't come out of the gate in a huff talking about unsubstantiated breakage. That's about the least constructive way to get heard. i guess his point is, you're the only guy supporting eselect- compiler ... if you arent going to be around to support it, then dont unmask it -mike Yeah, I couldn't agree more. That's part of the reason why I hadn't unmasked it until now. --Jeremy -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] last call for xml2 (#116346)
you guys have had plenty of time to do this ... so last call before i scrub xml2 from use.desc and repoman starts complaining :P -mike pgpSEcwSRXAda.pgp Description: PGP signature
[gentoo-dev] Problems with virtual/x11
Hi there I haven't search the mailing list. Please forgive me if the discussion was already started earlier by someone else. After posting and closing the bug report: http://bugs.gentoo.org/show_bug.cgi?id=135870 Jakub Moc noticed that the current >=virtual/x11-7.0 ebuild misses its task and creates trouble. For example: This ebuild behaves partly like a ordinary meta build and installs imake. You need imake (more correctly xmfmk) to install tightvnc. Unfortunately you are not forced to install at least virtual/x11-7.0-r1. virtual/x11-7.0 causes trouble with tightvnc because of the missing xmfmk tool. For that reason I want to request the deletion of virtual/x11-7.0 and that at least some dependencies of virtual/x11 are moved to =>x11-base/xorg-x11-7.0 where these dependencies belong to IMHO. xorg-x11 is a meta ebuild. virtual/x11 shouldn't be a second meta ebuild for the Modular X.org because otherwise you would have two meta ebuilds that will maybe cause more trouble in the future. Thanks and best regards @4u -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
On Tuesday 06 June 2006 18:39, Jeremy Huddleston wrote: > Uhm, what is this all about? If you have suggestions, make them, but > don't come out of the gate in a huff talking about unsubstantiated > breakage. That's about the least constructive way to get heard. i guess his point is, you're the only guy supporting eselect-compiler ... if you arent going to be around to support it, then dont unmask it -mike pgp1yPKlfYVxw.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tuesday 06 June 2006 02:13, Harald van Dijk wrote: > On Tue, Jun 06, 2006 at 01:48:37AM -0400, Mike Frysinger wrote: > > you dont use alsa-driver with 2.6 kernels and the 2006.1 profiles are 2.6 > > based > > You can use alsa-driver with 2.6 kernels. ok, but imho that's enough of a use case to warrant oss by default -mike pgpOif22GaR0E.pgp Description: PGP signature
