Re: [gentoo-dev] pending dooooooom of use.defaults
On Fri, Jan 13, 2006 at 06:57:24AM -0500, Mike Frysinger wrote: as one of the new sane features of the next portage-2.1_pre release, we're looking to cut out use.defaults support Could you add a USE_ORDER without auto to /etc/make.globals for that release, please, or alternatively provide some other way of checking whether use.defaults is read? This would greatly help me out with ufed, which currently has no way to check this, and instead has to hardcode env:pkg:conf:auto:defaults as the default USE_ORDER just like portage does. pgpx4vERZRK22.pgp Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
On Thu, Jan 19, 2006 at 05:56:47PM -0500, Mike Frysinger wrote: - USE=debug *never* changes CFLAGS or LDFLAGS or what have you, it *only* enables additional runtime code (such as assert()'s or helpful debug output) ... I'd like to see cases such as use debug append-flags -DDEBUG explicitly mentioned, please. I'm sure you meant that this is okay, but to avoid confusion, could you actually say so? (Or, if I'm completely misunderstanding, tell me it's not okay. :) pgpl3dqm0NRzA.pgp Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Mon, Jan 30, 2006 at 06:17:36AM +0100, Diego 'Flameeyes' Pettenò wrote: [ebuild R ] media-tv/kdetv-0.8.8-r1 USE=-arts -debug -lirc -opengl -xinerama -zvbi LINGUAS=it% -bg% -br% -ca% -cs% -cy% -da% -de% -el% -en_GB% -es% -et% -fi% -fr% -ga% -gl% -hu% -is% -lt% -mt% -nb% -nl% -pa% -pl% -pt% -pt_BR% -ro% -ru% -rw% -sr% [EMAIL PROTECTED] -sv% -ta% -tr% -zh_CN% 0 kB ... the linguas_* useflags should be listed in use.desc (consider that it would take a while, _if_ we decide to go this route, before all packages are updated to do this, but it's silly to pollute the use.local.desc file until 5 How would this work with packages which treat unset LINGUAS as install all languages, and empty but set LINGUAS as install no languages (the way LINGUAS was supposed to work)? When changing between the two, emerge -pv would show no changes, and there is no way for ebuilds to work around that. I'm all for telling users what parts of a package are optional, but incorrect info is worse than no info. (This doesn't apply to the KDE ebuilds, since they treat empty and unset LINGUAS the same, but you said all packages.) pgpRfBdN8xPlV.pgp Description: PGP signature
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
On Sat, Mar 04, 2006 at 05:43:22PM +0200, Dan Armak wrote: Has anyone actually complained that too many docs are installed by default? Don't know about docs, but if examples count here too, see bug #111508. pgpWPL45zC4Dq.pgp Description: PGP signature
Re: [gentoo-dev] DEPEND/RDEPEND question
On Tue, Apr 25, 2006 at 09:53:58AM +0300, Alin Nastac wrote: Lets say a package foo depends on bar, both at compile time and run time. Shouldn't DEPEND _and_ RDEPEND of the foo package reflect that dependency? I usually set DEPEND=$RDEPEND ... or vice-versa (depending on which is the most demanding). Am I utterly wrong here? Unless there's been a change I'm not aware of, that's right. You should often use something similar to COMMON=... DEPEND=$COMMON ... RDEPEND=$COMMON ... when not exactly all of $DEPEND is part of RDEPEND or vice versa though. I know that when a package is installed the usual way (not from a binary tarball) dependencies==RDEPEND+DEPEND, but portage functionality could change in the future. It may not be the wisest decision ever made, but portage could very well remove whatever dependencies are found in DEPEND - RDEPEND, once the package is installed. You already mentioned binary packages. In addition to that, I think bad dependencies can break things even under current portage versions by building with ROOT set. Something worth noting is that if RDEPEND is unset, it defaults to $DEPEND, so in some cases, DEPEND=... can be enough even if there are also runtime dependencies. However, if RDEPEND is set at all, it should be complete (except that system packages of course can be omitted). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: When will KDE 3.5 be marked as stable?
On Fri, May 05, 2006 at 09:20:08AM +0200, Bart Braem wrote: Michael Kirkland wrote: I think the problem is that Gentoo is falling into the same sandtrap the Debian project has been mired in forever. arch and ~arch are polarizing into stable, but horribly out of date, and maybe it will work. This leads to people trying to maintain a frankenstinian /etc/portage/package.keywords file, constantly adding to it and never knowing when things can be removed from it. I would suggest opening a middle ground tag, where things can be moved to from ~arch when they work for reasonable configuration values, but still have open bugs for some people. That way, people who prefer stability over the latest features can run arch, and everyone who bitches about packages being out of date can run the middle tag, and ~arch can be kept for testing. I really, really agree here. I know this seems like a flamewar but it is starting to annoy me. There are several packages that are several months behind the official releases. I am going to name some of them: Disclaimer: I maintain none of the packages you mentioned, so these are possible reasons, there may be other more important reasons that I didn't think of. Firefox 1.5: 5 months (the entire world uses it now, in stable) The ebuild itself causes problems with LINGUAS because of a portage bug (or limitation). And on IRC just yesterday two devs complained about Firefox because for one, 1.5 was unacceptably slow, and for another 1.5.0.3 took 100% CPU. Additionally, the latest stable is 1.0.8, which was released less than a month ago; the 1.0 versions are still maintained. KDE 3.5.2: 1.5 months (I know our devs get prereleases, so we had this time) kdelibs-3.5.2 needed fixes and workarounds for miscompilations and crashes less than a month ago, according to the changelog. Xorg 7: 5 months Strange behaviour for some with virtual/x11 being provided when it shouldn't be, causing missing dependencies for other ebuilds, and compilation issues. I know we have a lot of work to do, but I have some concerns. How long are we going to maintain old packages? KDE 3.4.3 is no longer supported by the KDE developpers. Firefox extensions for 1.0 are becoming extinct. You are also getting a lot of work trying to fix bugs in old software. Most probably you are starting to backport bugfixes, is this the way we want things to go? I understand you don't care about how many users you have, Gentoo is not a bussiness. But if I try to convince users about the current situation that is hard. I can't explain this, I really can't. My only answer is put it in /etc/portage/package.keywords. But that one is growing very fast... One nice thing for users would be the addition of more metabugs for recent packages. I'd like to know why some packages are not stable, and I am not the only one. Adding a metabug instead of closing all requests for stabilization with wontfix/wontresolve is much more userfriendly. Searching for open and recently closed bugs about the packages in question can help a lot in figuring out reasons packages aren't marked stable. As for metabugs, they would help if the package maintainers feel software is almost ready to go stable and just want to finish up the remaining issues, but in other cases, why? How does it help? Once again, I love to use Gentoo but I don't understand the current situation. I have the feeling that I'm not the only user so I posted these comments in order to discuss them. Hopefully you don't mind trying to explain it all... Bart -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Modular X and hardened
On Sun, May 14, 2006 at 11:32:13AM +0200, Kevin F. Quinn (Gentoo) wrote: [...] In summary, for Duncan's issue I suggest adding: # Xorg server is unaviodably suid with lazy bindings RESTRICT=stricter to the xorg-server ebuild to stop it dying for people with FEATURES=stricter (the comment helps people who have enabled STRICTER to see why it's disabled, in case anything else crops up) and also to add: filter-ldflags -Wl,-z,now to the eclass (perhaps in x-modular_src_compile, or in both x-modular_src_config and x-modular_src_make). If you do it just on the xorg-server ebuild, and people do what Duncan did and set LDFLAGS in make.conf, it'll set BIND_NOW on everything which at the very least will cause the radeon and GL drivers to fail to load. The idea of filter-ldflags is a bad one, IMO. There are an infinite number of ways to enable a flag (for -z now: -Wl,-z,now; -Wl,-z -Wl,now; -Xlinker -z -Xlinker -now; -Wl,-O1,-z,now; ...). Even if you restrict yourself to the sane ones, you can't reasonably catch them all. Normally, the proper fix would be `append-ldflags -Wl,-z,nonow`, but as binutils completely ignores this, that's not going to work either (as also noted earlier). I think the only sane thing to do (treating -Wl,-z,now -Wl,-O1 differently from -Wl,-z,now,-O1 is not sane) is to give a warning message telling users not to enable -z now even if portage states otherwise. Ideally, binutils would also be patched to support -z nonow, and -Wl,-z,nonow would be appended to LDFLAGS, but that's something for later concern. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] LINGUAS support
On Mon, May 15, 2006 at 12:09:09PM -0700, Tuan Van wrote: The other day spyderous was looking for a tool to remove extra .po that he doesn't need. I recommended him to set LINGUAS in make.conf. Then I realized some package doesn't respect that variable (ie eject) Would it be better (easier) to have portage removes those extra locales in $D/usr/share/locale/ before merge than patch the source? Part of bug #9988, the response was that it didn't belong in portage. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 10:06:54AM -0400, Chris Gianelloni wrote: On Wed, 2006-05-17 at 01:42 +0100, Stephen Bennett wrote: paludis/packages: -*=sys-apps/portage-2.0.51.22 -*sys-apps/portage would be best Everything after the - must be *exactly* what is already specified in base/packages, or it will have no effect. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] et_EE locale and language of error messages
On Fri, May 19, 2006 at 11:38:06AM +0200, Stefan Schweizer wrote: Hi, there are at least two problems with how portage currently handles locales: - Firstly some packages fail to build with obscure LC_* settings The continuous stream of et_EE bugs is annoying: http://tinyurl.com/jsqzb - and secondly I get my gcc output in german when I have a german locale set. This makes it really hard to report bugs or the bugreports are useless for most developers that do not understand the language. Those problems cannot be easily workarounded since portage does not use LC_ALL and LANG settings from /etc/make.conf I propose to have the portage build environment set the language to English or LC_ALL=C by default. That would significantly reduce the bugs with unreadable error messages+ solve all the et_EE bugs at once. One problem could be that packages depend on LC_* to install the correct language. But that is a real bug then in my opinion, because ebuilds should only honour LINGUAS and not LC_* during build time. Those bugs should be detected and fixed. What do you think? LC_ALL=C in portage or not? No, it's needlessly unfriendly to users, and encourages broken packages. et_EE breakage should be fixed, and slowly but surely is, and as for unreadable error messages, getting German gcc output in a German locale is a feature, not a bug. It can indeed be a problem in bugreports, but it's a much milder one, since it's trivial to look up what any particular message is translated from. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] et_EE locale and language of error messages
On Fri, May 19, 2006 at 09:09:08AM -0400, Patrick McLean wrote: No, it's needlessly unfriendly to users, and encourages broken packages. et_EE breakage should be fixed, and slowly but surely is, and as for unreadable error messages, getting German gcc output in a German locale is a feature, not a bug. It can indeed be a problem in bugreports, but it's a much milder one, since it's trivial to look up what any particular message is translated from. It's not trivial if you don't have the German locales installed. grep through gcc/po/*, which doesn't require installation of the locales, only that you didn't delete the gcc tarball after fetching it. (Yes, I do it myself, and no, I don't normally have the gcc sources unpacked.) Jakub, probably not very seriously, mentioned automating such a lookup. Well, a simple shell script should do it, and if there is actual interest in it, I might write it myself. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: et_EE locale and language of error messages
On Fri, May 19, 2006 at 03:13:48PM +0200, Stefan Schweizer wrote: Marc Hildebrand wrote: Otoh LC_ALL=C could help if you intend to use a .utf-8 locale as root, though. So if it does help solving bugs and causes no trouble, why not. ok, we have prepared a patch now, so everyone can have a look at it. http://dev.gentoo.org/~zmedico/tmp/portage_lc_all.patch the default LC_ALL=C will be overwriteable by PORTAGE_LC_ALL= in make.conf. Of course broken settings like et_EE will not be supported. Different != broken. It's the packages that are broken with unwarranted assumptions. If no other objections come up against patch will be added to portage within a day. So, if you have any problem with it, speak up now. Yes, please do ignore my current objections. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] et_EE locale and language of error messages
On Fri, May 19, 2006 at 02:44:03PM +0100, Daniel Drake wrote: Harald van Dijk wrote: and as for unreadable error messages, getting German gcc output in a German locale is a feature, not a bug. I agree - but only when you use gcc on the command line, or in a Makefile, or in some other normal usage scenario. I think Stefan is suggesting just using the standard English locale *during portage merges* rather than as a system-wide thing. Does that change your view at all? I know that's what he's suggesting, so no, it doesn't change my view. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Signing everything, for fun and for profit
On Fri, May 19, 2006 at 04:17:38PM +0100, Chris Bainbridge wrote: On 19/05/06, Andrew Gaffney [EMAIL PROTECTED] wrote: Chris Bainbridge wrote: It is a single signature across the entire portage tree. It means that after rsync emerge can check the signature against the retrieved tree to validate the whole tree (or overlay). This idea has been brought up before and shot down. Signing the whole tree does not work, since we allow users to only sync parts of the tree. We do? What option to emerge enables this behaviour? The PORTAGE_RSYNC_EXTRA_OPTS variable does. (Or RSYNC_EXCLUDEFROM with older versions of portage.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: et_EE locale and language of error messages
On Fri, May 19, 2006 at 05:44:34PM +0200, Stefan Schweizer wrote: Harald van Dijk wrote: [..] encourages broken packages. et_EE breakage should be fixed, and slowly but surely is[..] That is your main problem here and I have discussed this in IRC with you and it is true in my opinion that it does not improve gentoo or make the distribution any better to close et_EE bugs as WONTFIX. But the default should be C to make sure everyone can compile their system without an error, and if people want locale output and help with bugfixing they can of course enable it in their make.conf and keep the bugs coming :) Also developers wont have to translate that often or ask for translations when the default locale is C. Developers are more likely to fix a bug quickly if they do not have to ask twice :) Indeed, this is less than ideal, but not unacceptable to me :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Signing everything, for fun and for profit
On Fri, May 19, 2006 at 06:50:34PM +0200, Marius Mauch wrote:
On Fri, 19 May 2006 15:13:15 +0100
Chris Bainbridge [EMAIL PROTECTED] wrote:
find /usr/portage -path '/usr/portage/metadata' -prune -o -path
'/usr/portage/distfiles' -prune -o -path '/usr/portage/packages'
-prune -o -type f -exec cat {} /tmp/blah \;
time gpg --detach-sign -a /tmp/blah
I get 1.5 seconds on a desktop and 6.5 seconds on a laptop.
Because you're only checking the last file returned by find ;)
' /tmp/blah' is a shell construct, and while it is (hopefully
unintentionally) strangely written, it is applied to find, not to cat,
even though it's between {} and \;. So all files are added together,
and then gpg is run on the result.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving virtual/eject to new-style virtual
On Tue, May 23, 2006 at 12:38:55PM +0200, Diego 'Flameeyes' Pettenò wrote: So, right now virtual/eject is the old-style virtual that gets listed in virtuals file in the profiles, defaulting to sys-apps/eject that is Linux only. I would like to move it to a new-style virtual to make it simpler to handlef or other platforms, having the deps this way: || ( kernel_linux? ( sys-apps/eject ) sys-block/unieject kernel_FreeBSD? ( sys-apps/eject-bsd ) ) this way when used with a kernel different by Linux it defaults to unieject (my reimplementation) that using libcdio would be simpler to port. Thoughts? (I've been meaning to ask this for a while, it's not specific to virtual/eject.) How does it help? New-style virtuals have several disadvantages, and the usual advantages of new-style virtuals don't apply here. If it actually provides real benefits, then no objections from me, but how is this easier to maintain than a virtual/eject sys-block/unieject entry in the default-bsd profile? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving virtual/eject to new-style virtual
On Tue, May 23, 2006 at 07:12:53AM -0700, Donnie Berkholz wrote: Harald van Dijk wrote: How does it help? New-style virtuals have several disadvantages, and the usual advantages of new-style virtuals don't apply here. If it actually provides real benefits, then no objections from me, but how is this easier to maintain than a virtual/eject sys-block/unieject entry in the default-bsd profile? Could you expand on the disadvantages? New-style virtuals aren't automatically provided when the relevant packages get installed, can't block themselves when only one may be installed at a time, can't be provided from an ebuild in an overlay without adding a virtual ebuild too, which must be kept in sync with the one in gentoo-x86, and more simply are ugly in emerge --pretend output. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
On Sun, Jun 04, 2006 at 08:36:57PM -0400, Doug Goldstein wrote: Jakub Moc wrote: Matteo Azzali wrote: Repoman considers lots of local variables as an error, I was pointed to expanded vars as a solution. If no developers has something against I'll be happy to use 28 local flags mattepiu Well uh, no please Don't create 28 local use flags for one ebuild, use.local.desc is cluttered enough as it is... :) Otherwise, I'd say you've misunderstood the repoman output, you probably didn't put them into use.local.desc when testing your local stuff. My plan with xmltv was to USE locales since the xmltv grabbers actually use the same locale codes (i.e. de for the German ones). Granted there's some differences (two de grabbers and they're called xmltv_de_something and xmltv_de_something else). However the de locale setting would turn both on. I think that's the best option. But I just haven't had enough time to do it. Please don't do that. LINGUAS is for translations, nothing more, and using it for xmltv grabbers will be a huge pain for everyone using different languages than implied by their locations. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Sun, Jun 04, 2006 at 04:09:44PM -0400, Alec Warner wrote: Slipping this in before 2.1 goes stable, it's a small check. Basically if your ebuild inherits a VCS eclass ( currently darcs, subversion, cvs ) AND your ebuild has stable keywords on any arches repoman will report an error. One thing to note here: Are there any cases when one inherits a VCS eclass but the ebuild itself is not a live checkout ebuild. I don't see any, looking at the eclasses. Some gnustep stuff inherits cvs, but uses -D in the cvs options to always download exactly the same thing. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Mon, Jun 05, 2006 at 03:45:50AM -0400, Mike Frysinger wrote: On Monday 05 June 2006 02:07, Harald van Dijk wrote: Some gnustep stuff inherits cvs, but uses -D in the cvs options to always download exactly the same thing. then arent you just adding overhead to the poor gnustep cvs servers ? why not roll a cvs snapshot tarball and distro via our mirrors Yeah, that'd probably be a better idea, but even if the current ebuilds are less than perfect, it seems like a valid use of the eclass to me, so making repoman error out is a bad idea, I think. A warning would be useful, though. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Mon, Jun 05, 2006 at 01:54:08AM -0700, Brian Harring wrote: On Mon, Jun 05, 2006 at 10:19:41AM +0200, Harald van Dijk wrote: On Mon, Jun 05, 2006 at 03:45:50AM -0400, Mike Frysinger wrote: On Monday 05 June 2006 02:07, Harald van Dijk wrote: Some gnustep stuff inherits cvs, but uses -D in the cvs options to always download exactly the same thing. then arent you just adding overhead to the poor gnustep cvs servers ? why not roll a cvs snapshot tarball and distro via our mirrors Yeah, that'd probably be a better idea, but even if the current ebuilds are less than perfect, it seems like a valid use of the eclass to me, so making repoman error out is a bad idea, I think. A warning would be useful, though. 'Cept standards for ebuilds is typically http/https/ftp access for fetching files- forcing pserver means people behind firewalls are screwed... which is why non standard uri that is generally accessible to users must be http/https/ftp, and if they aren't, upload the file to the mirrors. Ebuilds might work, don't think they qualify as valid though- assume initially it was easier to just copy the ebuild and lock the date; doesn't make it valid though. :) I now checked: http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html If it's explained how to do it in the docs, I consider it valid, regardless of how bad an idea it may be. Should be an error imo- there isn't any real requirement for a cvs/git/darcs/subversion eclass consumer to be visible really. ~harring Are you hoping for even ~arch cvs ebuilds to cause a repoman error? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Mon, Jun 05, 2006 at 02:24:24AM -0700, Brian Harring wrote: On Mon, Jun 05, 2006 at 11:14:45AM +0200, Harald van Dijk wrote: On Mon, Jun 05, 2006 at 01:54:08AM -0700, Brian Harring wrote: On Mon, Jun 05, 2006 at 10:19:41AM +0200, Harald van Dijk wrote: On Mon, Jun 05, 2006 at 03:45:50AM -0400, Mike Frysinger wrote: On Monday 05 June 2006 02:07, Harald van Dijk wrote: Some gnustep stuff inherits cvs, but uses -D in the cvs options to always download exactly the same thing. then arent you just adding overhead to the poor gnustep cvs servers ? why not roll a cvs snapshot tarball and distro via our mirrors Yeah, that'd probably be a better idea, but even if the current ebuilds are less than perfect, it seems like a valid use of the eclass to me, so making repoman error out is a bad idea, I think. A warning would be useful, though. 'Cept standards for ebuilds is typically http/https/ftp access for fetching files- forcing pserver means people behind firewalls are screwed... which is why non standard uri that is generally accessible to users must be http/https/ftp, and if they aren't, upload the file to the mirrors. Ebuilds might work, don't think they qualify as valid though- assume initially it was easier to just copy the ebuild and lock the date; doesn't make it valid though. :) I now checked: http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html If it's explained how to do it in the docs, I consider it valid, regardless of how bad an idea it may be. Except the doc specifically states they should be package.mask'd if added; what that doc is talking about is vcs head ebuilds, not an ebuild that's locked down to an exact rev/date. It first lists the disadvantages of CVS sources in general, and then the disadvantages of live CVS sources. If it only applied to live CVS sources, why would it split them up? As mike said, why hammer on their servers? The ebuild isn't changing (it's effectively a locked version), tarball it and upload it. And as I said, I agree that that would be a better idea. Basically, the locked cvs version ebuild referenced above seems like a lazy trick someone did to avoid rewriting it to drop the cvs usage. Should be an error imo- there isn't any real requirement for a cvs/git/darcs/subversion eclass consumer to be visible really. ~harring Are you hoping for even ~arch cvs ebuilds to cause a repoman error? Original rules *were* that no vcs head based ebuild should be visible, that it must be masked. Current devrel docs contradict that (those docs bluntly are wrong- that change I don't think anyone ever agreed to), devmanual states it correctly. The devmanual states that they should not generally be added to the tree softmasked or unmasked. It does not state that they should never be added as such at all. Or, in other words, there can be exceptions. There's nothing wrong with vcs head ebuilds if they're masked; if they're user visible (~arch), there is _no_ way to gurantee they're actually sane (the source can and does change), that's why they're suppossed to be masked. ~harring -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Mon, Jun 05, 2006 at 12:57:08PM +0100, Ciaran McCreesh wrote: On Mon, 5 Jun 2006 11:56:16 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: | The devmanual states that they should not generally be added to the | tree softmasked or unmasked. It does not state that they should never | be added as such at all. Or, in other words, there can be exceptions. It's not a hard ban because when I wrote it I was thinking that maybe some day someone would come up with a legitimate reason for it. You've yet to do that, so you don't get to take the exception clause. The proposal was to change it to a hard ban. You say that there could be legitimate reasons for (un)stable CVS ebuilds. What I'm saying is that they're valid from a portage POV even without reasons, that they're currently used, and that the current stable CVS ebuilds are indeed a bad idea. So far, I don't think you disagree, but if you do, please explain. I then said that *you* say there can be legitimate reasons for them. So why do *I* have to come up with examples of it? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new repoman check
On Mon, Jun 05, 2006 at 01:51:31PM +0100, Ciaran McCreesh wrote: On Mon, 5 Jun 2006 14:41:43 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: | I then said that *you* say there can be legitimate reasons for them. | So why do *I* have to come up with examples of it? Well that's just it. I didn't say there were legitimate reasons, I just didn't commit myself to saying that there weren't. Fair enough, but if you read can as could in my posts, they still make sense. Two reasons for CVS ebuilds that aren't hardmasked, by the way: One: see emacs-cvs-22*; it's more reliable than the emacs-22* snapshot. (Something like this is only for ~arch.) Two: when a specific revision is wanted, but snapshots aren't possible for legal reasons. (This could even be marked stable.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, Jun 05, 2006 at 06:03:57PM +0200, Stefan Schweizer wrote: Hi, today I would like to propose a few default keywords for removal. They are outdated and no longer needed on current systems: -imlib - imlib depends on gtk-1, which imo should not be installed in a default gentoo installation - there should be no legacy depends for a plain emerge kde. I see imlib doesn't forcibly depend on gtk1 in the 1.9.15 version. It's been in the tree for a year, but never unmasked apparently. Maybe that would be a better idea than removing this flag as a default? (Honest question, I'm not sure.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Mon, Jun 05, 2006 at 06:59:22PM +0200, Carsten Lohrke wrote: Any comments/objections - any outdated useflags I forgot? Have a look at /usr/portage/profiles/default-linux/x86/2006.0/make.defaults for the list of current default use flags. I think gtk2 should be finally removed¹ from all packages and from make.defaults as well, before the 2006.1 release. Maintainers, who explicitly want to allow building against using Gtk 1, should default their ebuilds to Gtk 2 and add a (local) gtk1 use flag instead. No, the decision with the gtk/gtk2 USE flag mess was to have package maintainers decide for each ebuild whether to support only gtk1 or only gtk2, but not have support for both in a single ebuild. The decision before that (and one with more support, IIRC) was to have one flag for gtk1, and one flag for gtk2. But what you're proposing now is getting back to the old mess, except defaulting to gtk2 instead of gtk1. That not only doesn't fix anything, but even says that gtk1 support was removed from a bunch of ebuilds for no benefit whatsoever. Please don't do that. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tue, Jun 06, 2006 at 12:07:42AM -0400, Mike Frysinger wrote: On Monday 05 June 2006 21:23, Chris Gianelloni wrote: On Mon, 2006-06-05 at 18:03 +0200, Stefan Schweizer wrote: -oss - oss is a legacy audio interface that has been superseeded by alsa in most current installs, a default use flag is no longer needed There are *many* applications in the tree that do not use ALSA, but work only via the OSS emulation. Removing this is a bad idea and it would definitely be blocked by the games team. Probably half of the packages that I maintain require OSS capabilities. do we really need the USE flag though ? i was under the impression that you need to enable the OSS compat layer in the kernel and that's enough ... and the USE flag doesnt affect kernel build options ... It depends on whether you use the kernel drivers or the alsa-driver package, I think. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tue, Jun 06, 2006 at 01:48:37AM -0400, Mike Frysinger wrote: On Tuesday 06 June 2006 01:31, Harald van Dijk wrote: On Tue, Jun 06, 2006 at 12:07:42AM -0400, Mike Frysinger wrote: On Monday 05 June 2006 21:23, Chris Gianelloni wrote: On Mon, 2006-06-05 at 18:03 +0200, Stefan Schweizer wrote: -oss - oss is a legacy audio interface that has been superseeded by alsa in most current installs, a default use flag is no longer needed There are *many* applications in the tree that do not use ALSA, but work only via the OSS emulation. Removing this is a bad idea and it would definitely be blocked by the games team. Probably half of the packages that I maintain require OSS capabilities. do we really need the USE flag though ? i was under the impression that you need to enable the OSS compat layer in the kernel and that's enough ... and the USE flag doesnt affect kernel build options ... It depends on whether you use the kernel drivers or the alsa-driver package, I think. 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] parallel fun in src_install - going beyond the serial monotony of 'make install'
On Thu, Jun 08, 2006 at 01:58:07AM -0700, Robin H. Johnson wrote:
In the present devmanual, for src_install, it notes that
make install DESTDIR=${D}
is the preferred way to fire off the install, and to not use emake, for
fear of parallel issues.
Actually, it uses `make DESTDIR=${D} install`. Is there a reason you
changed it around, or does it simply not matter at all?
I completely agree with the rest of what you wrote.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, Jun 14, 2006 at 09:13:34AM -0400, Chris Gianelloni wrote: A great example of this are web-based applications. The web-apps project does not own all the web-based packages in the Portage tree. There are many such packages in the tree that are managed by developers that are not part of the project. The web-apps project gets to decide what happens to the packages grouped in the web-apps herd, but we neither have the right (nor the desire) to tell other developers that they can't add web-based packages to the tree; nor do other developers require our permission before adding packages to the tree. Again, you are confusing herds and projects. Here's another example of it done correctly. If you add a game to the tree, the herd should be listed as games. Period. Even if you are going to be the sole maintainer of the package, games should be the herd. Why? Because it is a game, silly. Why do no games' metadata.xml specify games@ as the maintainer? I thought it was because herdgames/herd implies this already, but if it doesn't, then dozens of games can be considered unmaintained right now, and fair game for anyone to mess with without approval. Are you sure you like this interpretation of 'herd'? You're probably right that herd is supposed to mean what you say it does, but existing practise, even by yourself, is very different from it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, Jun 14, 2006 at 05:13:48PM -0400, Chris Gianelloni wrote: On Wed, 2006-06-14 at 15:54 +0200, Harald van Dijk wrote: On Wed, Jun 14, 2006 at 09:13:34AM -0400, Chris Gianelloni wrote: A great example of this are web-based applications. The web-apps project does not own all the web-based packages in the Portage tree. There are many such packages in the tree that are managed by developers that are not part of the project. The web-apps project gets to decide what happens to the packages grouped in the web-apps herd, but we neither have the right (nor the desire) to tell other developers that they can't add web-based packages to the tree; nor do other developers require our permission before adding packages to the tree. Again, you are confusing herds and projects. Here's another example of it done correctly. If you add a game to the tree, the herd should be listed as games. Period. Even if you are going to be the sole maintainer of the package, games should be the herd. Why? Because it is a game, silly. Why do no games' metadata.xml specify games@ as the maintainer? I thought it was because herdgames/herd implies this already, but if it doesn't, then dozens of games can be considered unmaintained right now, and fair game for anyone to mess with without approval. Are you sure you like this interpretation of 'herd'? You're probably right that herd is supposed to mean what you say it does, but existing practise, even by yourself, is very different from it. Umm... no. See, if there's no maintainer listed, it defaults to the maintaining project *for that herd*... So herdgames/herd implies managed by the games team sometimes but not always? Meaning if the maintainer is games team + X, then games team must be explicitly listed as a maintainer in metadata.xml ? If so, sorry, misunderstood you, and this is far less insane than what I thought you were saying. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eclasses maintainers - raise your hands please
On Thu, Jun 15, 2006 at 02:32:36PM -0400, Mike Frysinger wrote: On Thursday 15 June 2006 11:21, Diego 'Flameeyes' Pettenò wrote: On Thursday 15 June 2006 16:50, Mike Frysinger wrote: this is dead as it's been integrated into portage Can gnuconfig_update calls go away from new ebuilds, then? yes, i'll update the func to complain about being deprecated Should it be removed from old ebuilds too, then? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eclasses maintainers - raise your hands please
On Thu, Jun 15, 2006 at 04:25:10PM -0400, Mike Frysinger wrote: On Thursday 15 June 2006 14:48, Harald van Dijk wrote: On Thu, Jun 15, 2006 at 02:32:36PM -0400, Mike Frysinger wrote: On Thursday 15 June 2006 11:21, Diego 'Flameeyes' Pettenò wrote: On Thursday 15 June 2006 16:50, Mike Frysinger wrote: this is dead as it's been integrated into portage Can gnuconfig_update calls go away from new ebuilds, then? yes, i'll update the func to complain about being deprecated Should it be removed from old ebuilds too, then? of course ... i didnt say anything to indicate otherwise ... The question was explicitly about new ebuilds, so your answer concerning only new ebuilds is the reasonable assumption without an indication otherwise. Anyway, gnuconfig removed from sawfish now. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] variable quoting, setting optional variables to , and depending on virtual/libc
On Sat, Jun 17, 2006 at 12:35:30AM -0400, Thomas Cort wrote:
What is the proper quoting style for using epatch? In the tree there
are about 3 different styles...
epatch ${FILESDIR}/some-fix.patch # used by 7326 ebuilds
epatch ${FILESDIR}/some-fix.patch# used by 3092 ebuilds
epatch ${FILESDIR}/some-fix.patch# used by 1434 ebuilds
${FILESDIR} should be quoted, but as long as there are no wildcards in
the /some-fix.patch, it doesn't matter whether that is.
What is the proper quoting style for defining the S variable? In the
tree there are about 3 different styles...
S=${WORKDIR}/${MY_P}# used by 5270 ebuilds
S=${WORKDIR}/${MY_P} # used by 43 ebuilds
S=${WORKDIR}/${MY_P} # used by 2259 ebuilds
Any is fine, there is no word splitting or wildcard expansion in
shell variable assignments.
What is the purpose of setting DEPEND and RDEPEND to if DEPEND and
RDEPEND are optional[1][2]? Isn't that just a waste of disk space /
bandwidth?
RDEPEND defaults to DEPEND (in ebuilds), so if DEPEND is set, and
RDEPEND should be empty, then RDEPEND must be set to explicitly.
As for DEPEND=, that's mostly a stylistic issue, I think.
DEPEND=virtual/libc seems like a waste too as it is an
implicit system dependency[3], any reason for using it?
Not really.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] variable quoting, setting optional variables to , and depending on virtual/libc
On Fri, Jun 16, 2006 at 11:31:27PM -0700, Drake Wyrm wrote: Harald van D??k [EMAIL PROTECTED] wrote: Any is fine, there is no word splitting or wildcard expansion in shell variable assignments. $ foo=bar * baz $ wombat=$foo $ echo $wombat bar somedir somefile baz The wildcard expansion is not during the variable assignment, it's during the expansion of $wombat. Just try echo $wombat instead. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] strict-aliasing rules, don't break them
On Sat, Jun 17, 2006 at 01:57:33PM +0200, Diego 'Flameeyes' Pettenò wrote:
On Saturday 17 June 2006 13:43, Luca Barbato wrote:
you can use unions or rewrite completely the line using it in another
way, in certain case the type pun is the quickest solution so it's
better to append -fno-strict-aliasing in the Makefile.
Err give me an example of the line, a lot of strict aliasing breakage was due
to double pointers.
Using your own example from
http://planet.gentoo.org/developers/flameeyes/2006/03/02/fixing_strict_aliasing_warnings
struct dl_node {
struct dl_node *next;
struct dl_node *prev;
};
struct dl_head {
struct dl_node *first;
struct dl_node *null;
struct dl_node *last;
};
and then accessing {first, null}, or {null, last} as a struct dl_node
the way to fix the code would be to rewrite the code to use arrays
of pointers instead of simply three pointer members. There is no
valid way to do what the code does using pointer members (that's simple
logic: it relies on the padding between first and null to be exactly the
same as that between null and last, which is a guarantee standard C
doesn't make), so fixing it requires quite a bit of work.
If you don't mind keeping the code invalid, but in such a way that GCC
will compile it as intended, you could do
struct dl_head {
union {
struct {
struct dl_node *first;
struct dl_node *null;
struct dl_node *last;
};
struct {
struct dl_node firstnode;
struct dl_node *dummy1;
};
struct {
struct dl_node *dummy2;
struct dl_node secondnode;
};
};
} h;
and then change
(struct dl_node *) h-first
to
h-firstnode
and similarly, change
(struct dl_node *) h-null
to
h-secondnode
Again, it's not valid, and it can still break if not handled with care
even with GCC.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] strict-aliasing rules, don't break them
On Sat, Jun 17, 2006 at 03:32:36PM +0200, Kevin F. Quinn wrote: Easiest way to find these is to stick -Wall in global CFLAGS (or just -Wstrict-aliasing if you want to be more specific), and grep the build log for 'will break strict aliasing' (LC_ALL=C obviously). That warning is given for valid code too. Please only add -fno-strict-aliasing if you actually find a package misbehaves without it, or if you have verified that there is indeed an aliasing violation in the code. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] strict-aliasing rules, don't break them
On Sat, Jun 17, 2006 at 02:28:28PM +0100, Ciaran McCreesh wrote:
On Sat, 17 Jun 2006 15:20:52 +0200 Harald van Dijk [EMAIL PROTECTED]
wrote:
| and then accessing {first, null}, or {null, last} as a struct dl_node
| the way to fix the code would be to rewrite the code to use arrays
| of pointers instead of simply three pointer members. There is no
| valid way to do what the code does using pointer members (that's
| simple logic: it relies on the padding between first and null to be
| exactly the same as that between null and last, which is a guarantee
| standard C doesn't make), so fixing it requires quite a bit of work.
It can be done using nested structs.
No, it can't: the two dl_nodes overlap.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] strict-aliasing rules, don't break them
On Sat, Jun 17, 2006 at 01:15:58PM -0400, Mike Frysinger wrote: On Saturday 17 June 2006 06:17, Luca Barbato wrote: Long term solution: 1- check your new package for aliasing compliance, and if you have time fix it in the code or in the makefile, if you haven't append -fno-strict-aliasing to the cflags and maybe send a notice about it upstream 2- append -fno-strict-aliasing to every source known to have such issue. 3 - include checking in portage http://bugs.gentoo.org/111436 Would this make builds fail by default, or would it provide a hook for the user to allow builds to fail if specific conditions are matched ? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tue, Jun 20, 2006 at 06:56:58PM +0200, Diego 'Flameeyes' Pettenò wrote: On Tuesday 20 June 2006 18:40, Stefan Schweizer wrote: 3) split the qt flag into a qt3 and a qt4 flag. This allows users to specifically pick qt3 or qt4 and the flag meanings are obvious - downsides are it is a lot of work. I would like migration to this idea, that would have been what I've liked to see for gtk too. Same here, both for gtk and for qt. Also, with qt it's slightly worse than with gtk: qt3 and qt4 are both huge, so if at all possible, I'd like to not see a requirement to install both qt3 and qt4 just to get poppler-bindings support for one (which would be required with a single flag). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
On Wed, Jun 21, 2006 at 05:20:47PM +0200, Carsten Lohrke wrote: On Wednesday 21 June 2006 15:44, Stefan Schweizer wrote: qt3 - enable optional qt3 support qt4 - enable optional qt4 support That will be a mess to support in the long run. Why? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla usage for overlays' projects [was: sunrise, a temporary compromise]
On Fri, Jun 23, 2006 at 08:43:23AM -0400, Seemant Kulleen wrote: First of all, I'm not sure why devrel was involved in a technical decision without actually having all the interested parties there, but aside from that, when Gentoo developers become a bunch of 5 year olds? What is this absolute nonsense of you don't like my toy, you can't have your toy going on around here? Jakub, if you will disrupt others because you can't have your way, then please reconsider exactly what your role is in this project, and maybe even how you might better serve some other project. You're suggesting jakub maybe shouldn't even be a Gentoo dev because he *doesn't* give one unofficial overlay special treatment over another? This childishness from *all* sides is getting really old, really fast. People need to grow the hell up, and quit with the melodrama. Don't you think you yourself are overreacting a bit in your message? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla usage for overlays' projects [was: sunrise, a temporary compromise]
On Fri, Jun 23, 2006 at 03:27:53PM +0100, Ciaran McCreesh wrote: On Fri, 23 Jun 2006 15:09:24 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: | You're suggesting jakub maybe shouldn't even be a Gentoo dev because | he *doesn't* give one unofficial overlay special treatment over | another? One unofficial project that has screwed up so badly that the council has had to step in and say no to it, It's entirely possible that I missed some important message, but as far as I know, council hasn't said either yes or no to it, and the overlay as hosted on o.g.o is suspended only until a council decision is made. as opposed to an unofficial project that has not attracted complaints and that is being worked into the tree? Quoting the original message: Until the council makes a firm decision about non-gentoo hosted overlays, this will be the defining method of dealing with them. Please explain to me how any non-gentoo hosted overlay can possibly be an exception to this. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla usage for overlays' projects [was: sunrise, a temporary compromise]
On Fri, Jun 23, 2006 at 11:11:15AM -0400, Seemant Kulleen wrote: On Fri, 2006-06-23 at 15:09 +0200, Harald van Dijk wrote: You're suggesting jakub maybe shouldn't even be a Gentoo dev because he *doesn't* give one unofficial overlay special treatment over another? The jave unofficial overlay is well on its way to becoming an official and officially hosted overlay. And once it is, it can be given special treatment. This childishness from *all* sides is getting really old, really fast. People need to grow the hell up, and quit with the melodrama. Don't you think you yourself are overreacting a bit in your message? Not at all. I've been back on the gentoo-dev list for three weeks, and the actual dev part of it has been pretty much missing. This list would be more ideal as gentoo-rant, gentoo-torture-every-reader-with-endless-threads, gentoo-lets-not-get-along, gentoo-babies, gentoo-childishness, we can come with a few more. Maybe discussions have been focused on policy more than development itself, but for the most part (yes, there have been exceptions), they have still been focused on Gentoo. You seem to be making it personal, which is over the line for me. My personal view is apparently starting to be more public here, so I'll be plain: I think developers needs to all seriously reconsider what they are doing with Gentoo and why. I'm not advocating anything other than a bit of introspection on why people do this to begin with. That is a good idea regardless. In the past few weeks, I've seen devs get at each others' throats; and worse still at users' throats. And really, it's a little too much already. Your frustration is understandable, but I think you took it out on the wrong message, and very possibly the wrong person. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla usage for overlays' projects [was: sunrise, a temporary compromise]
On Fri, Jun 23, 2006 at 01:33:21PM -0400, Seemant Kulleen wrote: On Fri, 2006-06-23 at 18:07 +0200, Harald van Dijk wrote: On Fri, Jun 23, 2006 at 11:11:15AM -0400, Seemant Kulleen wrote: On Fri, 2006-06-23 at 15:09 +0200, Harald van Dijk wrote: You're suggesting jakub maybe shouldn't even be a Gentoo dev because he *doesn't* give one unofficial overlay special treatment over another? The jave unofficial overlay is well on its way to becoming an official and officially hosted overlay. And once it is, it can be given special treatment. We're talking around each other, let's stop. I'm not advocating that the overlay keywords for sunrise cease -- as I stated in another part of this thread: I do not care one way or the other. I don't think it is appropriate, however, to make other projects hostage because you don't like what's going on with your pet project. Agreed, but I don't think there's any reading of the original message that allows continuing use of Gentoo's bugzilla for Java's overlay until it is hosted by Gentoo, so I don't consider this Jakub's decision. Maybe discussions have been focused on policy more than development itself, but for the most part (yes, there have been exceptions), they have still been focused on Gentoo. You seem to be making it personal, which is over the line for me. I'm pretty sure I have not made it personal. I'm not addressing any one in particular on these, nor do I have anything against any parties (or for any parties for that matter). I'm sorry if you took my words that way, that was certainly not the intent from this side. It was mostly the gentoo-babies reference to this list that I considered name-calling and a bit too much, even if it wasn't directed at any single person in particular. If I misunderstood you, sorry. Your frustration is understandable, but I think you took it out on the wrong message, and very possibly the wrong person. I know what I did, and they were both the correct target. We can take this off-list and include Jakub himself in it, if you're dying to know. I think Jakub himself knows full well *exactly* where I came from and why. If there's something between you and Jakub that I'm not aware of, I'll stay out of that. It doesn't affect my opinion on this specific topic, though. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, Jul 06, 2006 at 02:21:43PM +0200, Diego 'Flameeyes' Pettenò wrote:
On Thursday 06 July 2006 13:58, Donnie Berkholz wrote:
Well, there are enough in the tree
There are ebuilds for non-gcc compilers. There's no support in using them for
anything like building stuff. Let's think to all the append-flags there are
in the tree.
`append-flags $(test-flags ...)` can be used instead, if the options are
gcc-specific, and I have done that myself in a case where every
supported GCC version supported the specific option. (-fpermissive was
the one.)
This is not going to make the support any less working. There's
no project maintaining support for icc and the like.
When the answer is make icc not suck even when it is capable of
compiling mostly any package if the portage tree would not assume gcc,
that's not going to happen. First, alternative compilers must be
accepted (even when not supported) by package maintainers, and only then
might they ever become supported.
that you should at least make sure
they don't completely break and error out when passing them invalid
flags,
Uhm, If you look at the function itself you can see that I drop the stderr
output and I just care about the other part. The flags used are the ones set
by the user with the exclusion of -E -dM that are, afaik, standard unix
compiler options like -c and -o..
-E is a standard unix compiler option. -dM isn't. What you could do
instead is `$(tc-getCC) ${CFLAGS} -E - /dev/null 21 EOF
#if !($macro)
#error
#endif
EOF` and check $CC's return value. If $macro is not defined, or is
defined to something like 0, preprocessing won't succeed, and $CC will
return nonzero.
if the compiler does not support those,
it's unlikely it can actually do anything useful in Gentoo.
And anyway it cannot break, it will just report that no extensions are
available.
That's sane behaviour regardless. :)
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, Jul 06, 2006 at 11:41:26AM -0400, Ned Ludd wrote:
On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
Diego 'Flameeyes' Pettenò wrote:
echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null
Thoughts? Comments?
How will you handle non-gcc compilers?
Non gcc compilers have never been supported and probably never will be.
Gentoo uses the GNU Toolchain.
The GNU toolchain is not supported by Gentoo, and in fact gets actively
broken with unsupported command-line options. Only the GNU toolchain as
modified by Gentoo's toolchain guys is supported, unfortunately.
--
gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote: On Thu, 6 Jul 2006 21:06:18 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: The GNU toolchain is not supported by Gentoo, and in fact gets actively broken with unsupported command-line options. Only the GNU toolchain as modified by Gentoo's toolchain guys is supported, unfortunately. What exactly is it about the toolchain supplied with Gentoo that causes you problems? I don't have a lot of trust in Gentoo's patches, as they have resulted in completely and utterly unusable ld, and (minor) data loss due to a miscompilation by Gentoo's gcc, in the past. Also, being able to check whether your own software compiles with a GNU toolchain is to me a good thing. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, Jul 06, 2006 at 04:03:26PM -0400, Stephen P. Becker wrote: Harald van Dijk wrote: On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote: On Thu, 6 Jul 2006 21:06:18 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: The GNU toolchain is not supported by Gentoo, and in fact gets actively broken with unsupported command-line options. Only the GNU toolchain as modified by Gentoo's toolchain guys is supported, unfortunately. What exactly is it about the toolchain supplied with Gentoo that causes you problems? I don't have a lot of trust in Gentoo's patches, as they have resulted in completely and utterly unusable ld, and (minor) data loss due to a miscompilation by Gentoo's gcc, in the past. Also, being able to check whether your own software compiles with a GNU toolchain is to me a good thing. Isn't this why gcc et al support the vanilla USE flag? Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote: On Thursday 06 July 2006 16:14, Harald van Dijk wrote: Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. you're just griping because i forced ssp/pie regardless of USE=vanilla ... I didn't mind that you applied ssp/pie patches regardless of USE=vanilla, I did mind that you applied the stub patches with USE=nossp vanilla, and I also didn't like that this was either done accidentally but ignored when pointed out, or that this was done deliberately with a misleading cvs log message. since gcc-4.0 and below are on the way out, i have no problem changing this behavior besides, since both of these technologies are in mainline gcc now, i really dont see how you can continue to gripe with gcc-4.1.1+ I don't know how much gcc-spec-env.patch can be trusted, and even if it is 100% safe, such patches don't belong in anything that would be called vanilla. (I have commented on that patch long before this thread started, so don't think I'm just looking for something to complain about now.) -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote: On Fri, 7 Jul 2006 07:46:16 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote: On Thursday 06 July 2006 16:14, Harald van Dijk wrote: Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. you're just griping because i forced ssp/pie regardless of USE=vanilla ... I didn't mind that you applied ssp/pie patches regardless of USE=vanilla, I did mind that you applied the stub patches with USE=nossp vanilla, and I also didn't like that this was either done accidentally but ignored when pointed out, or that this was done deliberately with a misleading cvs log message. If you take out the stub patches (which incidentally have no impact on code generation), many builds will simply fail because they expect the additional flags from ssp, htb etc to be there. That's the point. I mentioned being able to test whether your own software compiles with a pure GNU toolchain as a desire. Being able to see whether unofficial compiler options are used is not just a nice extra, but even necessary for that. Since they have no impact on code generation, their presence doesn't impact comparisons with a pure upstream release. since gcc-4.0 and below are on the way out, i have no problem changing this behavior besides, since both of these technologies are in mainline gcc now, i really dont see how you can continue to gripe with gcc-4.1.1+ I don't know how much gcc-spec-env.patch can be trusted, and even if it is 100% safe, such patches don't belong in anything that would be called vanilla. (I have commented on that patch long before this thread started, so don't think I'm just looking for something to complain about now.) Again, if you don't gave GCC_SPECS defined in your environment then that patch makes no difference to code generation. Yes, but if GCC_SPECS is defined in the environment, I don't know enough about it to be sure that it interacts properly with -specs command-line options. Even if it works perfectly, though, the point remains that it does not belong in a USE=vanilla build. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote: Keep pushing this and the only thing you will end up with is the vanilla flag being removed all together.. Is that a threat? If not, is there a reason behind this? You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. If you mean modifying the build system to actually work properly, then I have no problem with that. USE=vanilla refers to runtime behaviour, not the build system. (See use.desc.) Specifically, if patches are applied that make sure GCC compiles, and those patches make sure GCC compiles to the same program intended by the GCC devs at that release, those patches are appropriate, IMO. None of the GCC patches I have problems with are of this nature. If you mean vanilla GCC + build fixes is unusable, then I'd appreciate an explanation, because as far as I know, it can work just fine as a system compiler, and plenty of people, at some times myself included, use it as one. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 03:57:51PM -0400, Ned Ludd wrote: On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote: Keep pushing this and the only thing you will end up with is the vanilla flag being removed all together.. Is that a threat? If not, is there a reason behind this? Yes.. When users or devs complain non stop when they don't understand something it leaves us with a few choices. 1) put up with people not having a clue. 2) remove the option so they can't bitch about it. Option #1 is not fun as it pushes the hand on #2 Option 3: Enlighten me. I have explained why I feel the way I do, so if there's some big flaw in my understanding, please do correct it. You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. If you mean modifying the build system to actually work properly, then I have no problem with that. USE=vanilla refers to runtime behaviour, not the build system. (See use.desc.) Specifically, if patches are applied that make sure GCC compiles, and those patches make sure GCC compiles to the same program intended by the GCC devs at that release, those patches are appropriate, IMO. None of the GCC patches I have problems with are of this nature. If you mean vanilla GCC + build fixes is unusable, then I'd appreciate an explanation, because as far as I know, it can work just fine as a system compiler, and plenty of people, at some times myself included, use it as one. You use the Gentoo modified one. Regardless of what USE= flags you have enabled you are still getting Gentoo behaviors. Gentoo isn't the only system I use. I have used vanilla GCC + build fixes, and I have been able to get a working system with it. So I'm still waiting on your explanation of how it is unusable. Think vanilla-sources are pure? They are not. They get patched as well with the minimal amount of patches required. Interesting, and I did not know that, but looking at kernel-2.eclass (which appears to be the only thing doing any modifying), the modifications are all build system fixes, and won't affect the generated kernel. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 05:12:21PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 01:46, Harald van Dijk wrote: On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote: On Thursday 06 July 2006 16:14, Harald van Dijk wrote: Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. you're just griping because i forced ssp/pie regardless of USE=vanilla ... I didn't mind that you applied ssp/pie patches regardless of USE=vanilla, I did mind that you applied the stub patches with USE=nossp vanilla, and I also didn't like that this was either done accidentally but ignored when pointed out, or that this was done deliberately with a misleading cvs log message. it was not ignored, i told you the answer was no ... i listened to your request and then i evaluated the situation and deemed at the time to go with what we have now. see how your usage of ignored is incorrect here ? Actually, you did ignore. The below text refers to something older. as Kevin pointed out, the stubs do not affect code generation so i preferred to keep users from breaking themselves also, at the time, i told you you could easily work around the stub situation by simply deleting them: rm /usr/portage/sys-devel/gcc/files/stubs/* and then add sys-devel/gcc/files/stubs/ to your rsync exclude list Yes, you told me this, before USE=vanilla even existed for gcc. When there's no implicit claim that installed GCC is official GCC, it's much less of a problem that it's not. Back then, I never complained that the installed GCC wasn't the official GCC, only that (a manually installed) official GCC wasn't a supported compiler. And I did not ask for an official way to disable the stub patches then, I only asked how I could do it for my own system. once we have 4.1.1 in stable, i'll be happy to update the eclass to not apply the stubs when USE=nossp as the majority of users will no longer be in the situation i referred to earlier Thanks. I hope that if a similar situation comes up, ebuilds will use test-flags instead of assuming the option is valid, though. since gcc-4.0 and below are on the way out, i have no problem changing this behavior besides, since both of these technologies are in mainline gcc now, i really dont see how you can continue to gripe with gcc-4.1.1+ I don't know how much gcc-spec-env.patch can be trusted, and even if it is 100% safe, such patches don't belong in anything that would be called vanilla. (I have commented on that patch long before this thread started, so don't think I'm just looking for something to complain about now.) you never pointed that patch out to me nor did i notice it, so i dont really see how you could have expected this to be fixed already I didn't point that out to you, I pointed that out to another of the toolchain guys. I'm not completely sure who, but I think it was Halcy0n. i'll update cvs when i get a chance Thanks again. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 06:13:27PM -0400, Mike Frysinger wrote: ignored *what* then ? you requested USE=vanilla control ssp, i said no and i'll add support for USE=nossp ... you requested USE/stub control, i said no, go delete the stubs USE=nossp existed before USE=vanilla did. To be sure I'm remembering right, I checked `cvs log toolchain.eclass`. In order, probably skipping a few steps: 1- No SSP 2- Choice between SSP [USE=-nossp] and stub patches [USE=nossp]. USE=vanilla didn't exist. 3- Choice between SSP [USE=-nossp -vanilla], stub patches [USE=nossp -vanilla], and nothing [USE=vanilla] 4- Choice between SSP [USE=-nossp] and stub patches [USE=nossp] USE=vanilla exists but has no effect on SSP. It was during 2 that I asked for a way to disable stub patches for myself (and not as part of the official ebuild), and you said to delete them. That was good enough for me during 2. We are now in 4. i dont see what else you're referring to ... be specific, vague claims only lead to wasting of both our times I hope this is specific enough: toolchain.eclass revision 1.234 (separating ssp/... from vanilla) log message: ssp/pie/htb have their own USE flags sep from vanilla, so people can utilize those when in fact the old USE=vanilla behaviour is unavailable now. You have never (as far as I know) answered whether it was intended to keep the old behaviour as an option, and if it wasn't, why the log message is what it is. all bets are off now then ... with Halcy0n leaving us, that leaves me as the only person maintaining the toolchain (there are few devs who contribute fixes for their ports and it helps out a ton, but that doesnt really count as being fully responsible for the toolchain packages). I'll keep that in mind, I wasn't aware that the other toolchain guys handle specific parts of the toolchain packages only. Even if I disagree with some specific decisions, nice job overall, then. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 19:04, Harald van Dijk wrote: I hope this is specific enough: toolchain.eclass revision 1.234 (separating ssp/... from vanilla) log message: ssp/pie/htb have their own USE flags sep from vanilla, so people can utilize those when in fact the old USE=vanilla behaviour is unavailable now. You have never (as far as I know) answered whether it was intended to keep the old behaviour as an option, and if it wasn't, why the log message is what it is. well i cant answer it if you havent asked it ... me not answering you on irc when i'm not around does not constitute being ignored and anyone who relies on irc in this respect really needs to learn more about irc I also mentioned it in a bugzilla comment, though admittedly not as a question there. (The gcc 2 bug, I think.) Bugzilla comments are safe to assume read, right? the log message looks pretty clear to me, i dont see this hidden message you're referring to the ssp/pie/htb patches have their own USE flags so separating them from USE=vanilla makes perfect sense ... I'm not disagreeing with that, but removing an older option is not just providing more choices. now you can do: gentoo patches + ssp gentoo patches + nossp vanilla + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla + ssp vanilla + stub whereas before you only had the option of: gentoo patches + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. this is also the reason i havent added USE=vanilla to glibc, too many users would simply break their boxes No complaints there. :) -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Sat, Jul 08, 2006 at 11:27:57AM +0200, Martin Schlemmer wrote: On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 19:04, Harald van Dijk wrote: the ssp/pie/htb patches have their own USE flags so separating them from USE=vanilla makes perfect sense ... I'm not disagreeing with that, but removing an older option is not just providing more choices. now you can do: gentoo patches + ssp gentoo patches + nossp vanilla + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla + ssp vanilla + stub whereas before you only had the option of: gentoo patches + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. No offence, but you are being very unreasonable in this thread. The fact that you can get what you are after, even though its not entirely supported, should be enough for you, especially for the fact that you are not clueless. You should remember that somebody at the end of the day have to sacrifice time and effort to fix bugs, and especially with something as complex as gcc, the more variables, the more effort it is going to be. And as Mike is relatively the only person currently who seems to maintain gcc, it should be his prerogative to decided that he get too much spam without the stubs. Sorry, but how much mail he gets does not affect one bit which behaviour is better, it only helps understand why the lesser behaviour could be chosen by reasonable people anyway. (Regardless of which behaviour is the lesser one.) And I don't harass anyone about -- it's been a very long time since I even mentioned any problems like this, and if nothing is done after this thread dies, I'll likely be quiet about it for a long time again -- so please don't act like I do. And you should really know by now that being documented as NOT FOR GENERAL USE will still not stop more than enough users to waste his time in telling them not to disable SSP with vanilla if they don't know what they are doing. I guess that's a fair point. Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. For the fact that we do not support vanilla gcc - I assume this is a gcc built by yourself - Actually, I meant gcc built with the vanilla flag here, as opposed to pure official GCC, which I already stated is unsupported earlier. this truly is really unfair of you to expect it. The 'contract' we usually have with upstream, is that if we apply patches to their software, we will be the first tier in the support chain. Now you want to run gcc which was not modified by us to fix the known hangups in how we do things - or save us time for that matter, and you still want us to support it - or at least make life easier for us by not leaving gaping holes that cost us maintenance time? Differences between official GCC and Gentoo's GCC are 1) fixed bugs, and 2) added features. (Assuming no patches are broken.) I think it's reasonable to not rely on the existence of those added features. You seem to think I think it's reasonable to not rely on bugs being fixed. No problem there, I don't. Besides, I said it's unfortunate that vanilla GCC (either one) is unsupported, not that it must be. My other problem, that vanilla GCC is different from Gentoo's GCC with the vanilla flag (plus maybe nossp/nopie/...), can be handled without requiring support for it from anyone. Am I the only one feeling that this is really selfish/absurd thinking since you have such an hackle in what we do, to not research, debug, and file thus your own bugs with http://gcc.gnu.org/bugzilla/ ? I actually do file bugs there when I run into them. The alternative to this that you seem to ignore, is that you can start helping maintaining gcc (I am sure Mike will appreciate help with Halcy0n gone as well, and me not having that much time currently). Since I'm more interested in vanilla GCC, I think there's little to help maintain from Gentoo's side (support in ebuilds, and possibly the build process, that's it). If that's something you think help would be good for anyway, though, sure, if I can. And of course promising so long as the stubs do
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
(Not commenting on the whole message, just parts.) On Sat, Jul 08, 2006 at 03:46:24PM +0200, Martin Schlemmer wrote: You can however fix the tree to make sure it will fully build without those flags, and then talk to Mike again about removing them. I am sure he might be more willing if it will not steal his time again. I ask again: would such patches be accepted? (Mike stated he would remove stubs once GCC 4.1 is stable -- thanks -- so users wouldn't run into problems often regardless.) Vanilla, Gentoo patched - they all have bugs which bugzilla have more than enough of in. Ah yes, I see some that definitely apply to USE=vanilla builds. I'll see if there's anything I can understand. :) OK, maybe I was just too dense to see it before, or maybe you kept dancing around the issue. To put it clear (or try at least), your whole issue currently is that you cannot use a 'Vanilla' gcc (ie without the stubs) to build everything in the tree ? No, being able to use vanilla GCC as Gentoo's system compiler would be a nice addition, and if it's agreed as a good idea I don't mind helping out with getting it working, but I can live without it. And not as much the stubs them selfs ? Being able to check software for unofficial compiler flags is for some cases a must. I repeat: two separate issues. They keep getting mixed up here. I think you understood wrongly. If the stubs were to be just removed say tomorrow, and breakage in the tree is still of such an extend that bugs starts to flood in again, its not just you that will have to read the mail. If the user is clueless, then Jakub have to reassign the bug to either toolchain or the package maintainer. If he could not determine it was due to the missing CFLAG, The error is very clear: cc1: error: unrecognized command line option -fno-stack-protector Maybe I have a little bit more confidence in people, sorry if that's misplaced. :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Fri, Jul 14, 2006 at 09:09:15PM +0200, Paul de Vrieze wrote: On Wednesday 21 June 2006 15:45, Donnie Berkholz wrote: -qt +qt3: This would only be available in 2 cases: - Package supports both qt4 and qt3, and they're mutually exclusive - Package supports both qt4 and qt3, and they can both be enabled at once In case 1, -qt +qt3 would enable qt3. In case 2, -qt +qt3 would enable qt3. In other words, as I've been trying to say all along, there is no such thing as a preference flag here. That creates a 2-flag combination to get a single feature, which is _not_ what we want. There is a qt flag to indicate enabling the best available qt for that package, and there are qt# flags to indicate enabling older qt for that package. The downside to this setup is that it's difficult to avoid installing certain qt versions when it's unknown which version USE=qt will pull in for any given package. This favors an entirely versioned setup instead, and we should get rid of USE=qt altogether in favor of only USE=qt#. Avoiding installation of a package can IMHO better be done by using /etc/portage/package.mask Arguably better, but sure not easier. It requires lots of entries in /etc/portage/package.use since portage won't automatically disable the qt flag if the required qt version is masked, and when packages change from/to qt3 to/from qt4, there is no way for portage to let the user know (so that cat/pkg -qt can be removed from package.use again). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Tue, Jul 25, 2006 at 02:14:46PM +0200, Enrico Weigelt wrote: * Ned Ludd [EMAIL PROTECTED] schrieb: snip Non gcc compilers have never been supported and probably never will be. If someone decides to work on that topic, IMHO the best approach would be providing an gcc-style frontend, so we actually get an drop-in-replacement (at least from the command line view). What would it do if a gcc-specific option is used for which the real compiler does not provide any option, even with a different name? If it would ignore it, things would break horribly (just think of -funsigned-char). If it would error out, are any options other than those already specified by POSIX (`man 1p c99`) available on all systems? (If not, no gcc-style frontend is necessary, because the options are already the same for all compilers intended to be usable as a (Unix-like-)system compiler.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] atom matching behavior
On Thu, Aug 03, 2006 at 07:07:35AM +0200, Marius Mauch wrote: Repost from gentoo-portage-dev[1]: Was just brought to my attention that the =* operator doesn't work as I thought, as for example =foo-1.2* matches foo-1.20 as well as foo-1.2.3. This wouldn't be a bug problem if it could be used as a general glob operator like with =foo-1.2.*, Even if that would be supported, it wouldn't match foo-1.2, unless the meaning of * changes. but it's use is strictly limited to the above version (can only be used when a version component separator may appear), so atm there is no facility to reliably lock an atom at a specific version component when you have to account for multi-digit components. Now the question is if we want this glob-style behavior or not. From the code comments it seems to be intentional, but I'd suspect that many people share my original assumption and expect it to only match full version components (as that is the much more common use case). Doesn't help that the atom description in ebuild(5) doesn't specify the behavior for this case either, * means match any version of the package so long as the specified base is matched can be read both ways. Opinions? Marius For packages with MMDD versions, =c/p-2005* can make sense, and I have used this in the past. Please continue to allow that, and possibly provide an alternative syntax for what you currently expect =c/p-v* to do (=c/p-v.* -- if it doesn't require the . -- being a possibility). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Make FEATURES=test the default
On Sat, Aug 05, 2006 at 12:04:01PM -0400, Alec Warner wrote: Ciaran McCreesh wrote: On Sat, 5 Aug 2006 17:35:32 +0200 Kevin F. Quinn [EMAIL PROTECTED] wrote: | USE=test is a workaround; portage cannot use FEATUREs in dep | strings. Actually, it could, if anyone ever got around to adding FEATURES to USE_EXPAND... We would do lots of things; that doesn't mean we should ;) s/would/could/ ? Anyway, sure, there's plenty of things we could do that we shouldn't. Forcing a hack by users (USE=test) when a hack by devs is available is one such thing, in my opinion. Yes, I'm aware that relevant people think FEATURES in USE_EXPAND is a bad idea, and I'm not sure I disagree. I think as a temporary workaround until a clean fix is available, it beats the current situation, though. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make FEATURES=test the default
On Sat, Aug 05, 2006 at 02:35:49PM -0400, Mike Frysinger wrote: On Saturday 05 August 2006 06:57, Kevin F. Quinn wrote: On Sat, 5 Aug 2006 11:49:53 +0200 Danny van Dyk [EMAIL PROTECTED] wrote: Please re-read the list of packages that fail tests: * glibc * autoconf * gettext * tar That makes _4_ system packages. Before I would consider making FEATURES=test a default, I would add least want the system set to actually merge with it. So you're happy to let users install these packages without them knowing the tests would fail? before i added binutils-2.17, i ran `make check` on it for about 25 targets ... of those, about 10 failed ... i checked with upstream and others reproduced it ... i dont know about you, but i dont have the skills to go in and fix the failures for all of those architectures Then RESTRICT=test, or use a src_test which warns on test failures rather than aborting, could be used. Or am I missing something? while i like the idea of all packages being able to pass FEATURES=test, somethings it just aint gonna happen with Gentoo's available skill set -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Setting USE_EXPAND defaults in profiles (in some cases)
On Mon, Aug 07, 2006 at 10:01:12AM +0200, Jakub Moc wrote: Zac Medico wrote: Donnie Berkholz wrote: agaffney suggested this in the first place, and every time I think about it, it seems like a better idea. If we set VIDEO_CARDS and INPUT_DEVICES in the arch profiles, we get the arch-specific defaults we need without the really hugely ugly indecipherable mess in the ebuilds that nobody can understand besides Josh_B and me. The very strange corner case this doesn't work with is if people manually set VIDEO_CARDS=, then they will no longer get the behavior of pulling in everything. But the default case will still work great. As of portage-2.1.1_pre4-r4, VIDEO_CARDS= should now continue to work like before no matter how you've enabled the flags in the profile. As part of the fix for bug 142125, portage automatically regenerates all of the USE_EXPAND variables to be consistent with the corresponding USE flags. Zac Well, please don't change the behaviour in every other release, it's very confusing and people file bugs about it. And -r4 behaviour is incorrect, as it ignores defaults in profiles when you set anything in make.conf. -r3 got it correctly so that foo in profiles could be overriden with -foo in make.conf, this doesn't work any more in -r4. That was a bug, not a feature. Older portage versions behave as -r4 does, and -r3's behaviour forces users to set invalid values in certain cases. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o
On Sat, Aug 12, 2006 at 01:13:48PM +0200, Simon Stelling wrote: Jeroen Roovers wrote: On a minor note, I'd also like to see bug reporters use canonical package names in bug descriptions, including the category (and preferably the specific version, not some =foo-3*!!!one, not to mention specifying no version at all). Including the category means arch devs won't need to guess/discover which of a few hundred categories a package is meant to reside in. First off, I second that. Second, here's how you still get where you want without looking up the category: $ cd gentoo-x86/*/foo This works better: $ cd gentoo-x86/*/foo/ This avoids the case where a file by the same name exists (for example, in licenses/). This of course doesn't work if there are multiple packages with the same name in different categories, but if a package maintainer doesn't specify the category in such a case, he should be hit anyway ;P -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o
On Sat, Aug 12, 2006 at 02:42:32PM +, Francesco Riosa wrote: [...] $ cd gentoo-x86/*/foo This works better: $ cd gentoo-x86/*/foo/ This avoids the case where a file by the same name exists (for example, in licenses/). may be $ cd gentoo-x86/*-*/foo/ ? Maybe. That avoids virtual/*, which may or may not be a good thing, depending on your needs. (The only other case where it helps is uclibc, which is probably already a special enough case that it can be mostly ignored for this thread.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Mon, Sep 11, 2006 at 11:22:11PM +0100, Ciaran McCreesh wrote: Comments both on the nature and the specifics of the specification would be welcomed. In particular, I'd like to know if people think we're mandating the appropriate degree of specificity and whether we're providing sufficient generality to avoid overly restricting innovation. I think this is overly restrictive, actually. It's a good idea to specify which files and directories will be matched by CONFIG_PROTECT and _MASK, since that's something ebuilds end up using, but it may be better to leave the details on how they will be protected up to the package manager (which can in turn make it configurable for the user). For one example of what a package manager, if configured to do so, should in my opinion be allowed to do: automatically remove unmodified and abandoned configuration files on updates. (This is not the same as setting CONFIG_PROTECT=-*.) For another, a package manager, if configured to do so, should in my opinion be allowed to store the config files on a (possibly local) cvs/svn server in addition to the real filesystem, avoiding ._cfg* files altogether. Specifying how they will be protected prevents things like this. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Fri, Sep 15, 2006 at 07:39:35PM +0100, Ciaran McCreesh wrote: On Thu, 14 Sep 2006 08:51:09 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: | On Mon, Sep 11, 2006 at 11:22:11PM +0100, Ciaran McCreesh wrote: | Comments both on the nature and the specifics of the specification | would be welcomed. In particular, I'd like to know if people think | we're mandating the appropriate degree of specificity and whether | we're providing sufficient generality to avoid overly restricting | innovation. | | I think this is overly restrictive, actually. It's a good idea to | specify which files and directories will be matched by CONFIG_PROTECT | and _MASK, since that's something ebuilds end up using, but it may be | better to leave the details on how they will be protected up to the | package manager (which can in turn make it configurable for the user). | For one example of what a package manager, if configured to do so, | should in my opinion be allowed to do: automatically remove unmodified | and abandoned configuration files on updates. (This is not the same as | setting CONFIG_PROTECT=-*.) For another, a package manager, if | configured to do so, should in my opinion be allowed to store the | config files on a (possibly local) cvs/svn server in addition to the | real filesystem, avoiding ._cfg* files altogether. Specifying how | they will be protected prevents things like this. Hm, the specification doesn't preclude additional functionality. It just describes how things should work when normal configuration protection is in action. Sure, the specification does not prohibit package managers from having behaviour that can be configured to not match what is specified, but that isn't the point. The point is that if configured as such, it isn't a Gentoo package manager anymore. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] LC_ALL=C Set by default for portage
On Sun, Mar 08, 2009 at 09:20:14PM +0100, Tomáš Chvátal wrote: Hi, lately i see that in our bugzilla most of the build reports are reported with localized build logs which we dont understand. This leads to us asking the user to run the emerge once more with LC_ALL=C. Wont it be nice to have this variable set by default in portage so users reporting bugs report in English? I can't speak for others, but I'd like to find and fix bugs with strange locales, at least for the packages I maintain. If portage were to force LC_ALL=C on me, I'd have a very hard time doing so.
Re: [gentoo-dev] LC_ALL=C Set by default for portage
On Sun, Mar 08, 2009 at 09:27:20PM +0100, Alexis Ballier wrote: Moreover this would automagically solve the [a-z] friends regexp failures; though that's still good QA to fix them but we wouldn't encounter them anymore. We would encounter them when using the programs outside of portage, but not when running the testsuite (if available) from within portage. It would succeed in working around compile-time only bugs, but it would be a major pain for locale bugs that can also cause problems at run time.
Re: [gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness
On Wed, Jul 08, 2009 at 05:02:10AM +0200, Arfrever Frehtes Taifersar Arahesis wrote: 2009-07-07 01:01:11 Ciaran McCreesh napisał(a): ... IUSE_IMPLICIT=build debug Are people wanting to make those implicit? IMHO they shouldn't be implicit. Agreed. They shouldn't be implicit, if only because you really want emerge --newuse (or equivalent) to pick up on changes in USE=build or USE=debug. Also, are USE dependencies possible with implicit IUSE? If not, things like DEPEND=dev-lang/python[-build] would have to be changed even though they're probably a good idea.
Re: [gentoo-dev] Non-free software in Gentoo
On Wed, Dec 30, 2009 at 08:51:18PM -0800, Greg KH wrote: On Wed, Dec 30, 2009 at 06:43:47AM -0500, Richard Freeman wrote: On 12/29/2009 07:52 PM, Greg KH wrote: No, the readme/copying is correct, it covers all of the code that runs on the processor as one body of work. Firmware blobs are different in that they do not run in the same processor, and can be of a different license. Yes, but they don't cover everything in the tarball. If I want to copy the tarball, then I need to comply with the distribution license of the tarball. That license isn't clearly advertised. It is a mix of a number of licenses from GPL v2 to allowed-to-copy-without-modifications. No, you can copy that tarball just fine, and when you _distribute_ it, the GPLv2 applies to it. Then I can distribute modified versions of the tarball, with altered firmware, in direct violation of the license granted for that firmware, just because it's allowed by the GPL? Seriously, you're saying the license of the firmware doesn't matter. The processor that the software runs on is fairly irrelevant. Not true at all, why would you think that? Since when does a license cross a processor boundry? When I copy the Linux kernel sources, all files are copied by a single processor. This isn't about running the kernel. In any case, I'm sure the kernel team will update the ebuild license string appropriately - this is more of a debate for the LKML. I just don't think that they've done a good job with it. Others are welcome to hold differing opinions. :) You don't think the gentoo kernel team (of which I think I'm the longest-term member), or the Linux kernel developers (of which I am the actual person who put those images in the kernel back in the late 1990's after consulting many lawers, and Linus, on the issue) are doing a good job with this? Please stop avoiding the issue. No one is saying the firmware is in conflict with the GPL, or that distribution of the kernel is illegal. The way it's distributed is fine. It's just not reflected properly in Gentoo.
Re: [gentoo-dev] Re: [RFC] base.eclass
On Sun, Jan 03, 2010 at 02:56:01AM +0100, Tomáš Chvátal wrote:
Dne 3.1.2010 01:56, Mark Bateman napsal(a):
There seems to be alot of unquoted variables
65 base_src_util $@
This is not problem
Only because you can be sure there will be exactly one word in the
result, which will not be split. In general, $@ should be quoted, and it
would be a good idea to either do it here too even though it's not
strictly necessary, or make the intent clearer and just write
base_src_util $1
90 case $1 in
Yarp this is problem and fixed
That's not a problem. A case expression is another example where quoting
is unnecessary; there won't be any word splitting on $1 anyway.
95 [[ ! -z ${A} ]] unpack ${A}
${A} is not used quoted :]
Right, that doesn't need quoting, and it would even be okay to drop the
unnecessary quotes in [[.
Re: [gentoo-dev] Re: [RFC] base.eclass
On Sun, Jan 03, 2010 at 11:28:27AM +0100, Ulrich Mueller wrote: On Sun, 3 Jan 2010, Harald van Dijk wrote: 65 base_src_util $@ This is not problem Only because you can be sure there will be exactly one word in the result, which will not be split. In general, $@ should be quoted, and it would be a good idea to either do it here too even though it's not strictly necessary, or make the intent clearer and just write base_src_util $1 I think this would not be correct. Note the while loop over parameters in base_src_util. You're right. I'm so used to src_unpack normally not having any arguments that I didn't stop to think base_src_unpack could easily be called explicitly, with as many parameters as you'd like. Checking shows this is not done in the tree (never more than one parameter, and usually zero), but that's no reason to drop it. :) So it should be $@ (with quotes). That'd be better, but my point still stands: the arguments to base_src_unpack won't ever contain anything that can be expanded, so quoting isn't strictly necessary, just a good idea. Not that I'm against the quoting, of course.
Re: [gentoo-dev] Non-free software in Gentoo
On Wed, Jan 06, 2010 at 10:57:01AM -0800, Greg KH wrote: On Tue, Jan 05, 2010 at 11:55:49PM -0500, Vincent Launchbury wrote: Greg KH wrote: And note, _I_ placed those images in the kernel image, after consulting lawyers about this issue, so it's not like I don't know what I am talking about here. I'm not questioning whether it's legal to distribute non-free firmware alongside the GPL. I'm merely saying that the firmware _is_ non-free, which should be reflected by the ebuild licenses. So you are saying that the license for the kernel should show the license for all of the different firmware files as well? If all the different firmware files get installed, then yes. That would get pretty unusable, and keep the kernel from being able to be installed on anyone's machine that didn't want such licenses, right? Also note that the license of the firmware files do not matter to almost everyone using the kernel, as almost no one uses those files anymore, the ones in the linux-firmware package should be used instead. Right, which is why at the same time it would be useful to have an option to not install those files. There's no problem with USE conditionals in LICENSE; LICENSE=GPL-2 firmware? ( freedist ) or expanded further would be fine, and simply nuke those files on install with USE=-firmware. So as we are a source-based distro, if you object to those firmware licenses, just don't build them in your kernel builds. But to expect to list all of them as the license for the whole kernel package, that's not a workable solution as far as I can see. The kernel sources are unusual in that they install the sources, and the user is responsible for configuration and compilation. For anything built from an ebuild, the license of unused parts of the source code shouldn't matter, but here all of the source files of the kernel get installed. So it's a pointless effort. To you maybe, but it's important to some. Note that updating the licenses would only affect those with strict ACCEPT_LICENSE settings anyway. I don't understand why you'd oppose the change. So you want anyone with such strict settings to not be able to install the kernel package at all? If so, what kernel do you want them to be able to use? :) The GPL-2 licensed parts of all the kernel packages -- so probably everything that matters -- could be installed with ACCEPT_LICENSE=GPL-2 with my above suggestion.
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On Mon, Apr 19, 2010 at 04:58:57PM -0400, James Cloos wrote: CM == Ciaran McCreesh ciaran.mccre...@googlemail.com writes: CM There's no need to offer the user the choice to do something that is CM always broken. Your car doesn't have a connect the exhaust fumes to CM the air conditioning intake button. Overriding portage's eclasses with one's own is not always broken; your analogy is not at all on point. Overriding portage's eclasses with your own is already possible. You're asking to override portage's eclasses, without letting portage handle the fact that you are overriding eclasses. And that is a bad idea. You haven't commented, at least not in this thread that I have seen, on how to handle metadata changes as a result of eclass changes. Let's say this is in the tree: foo.eclass: DEPEND=dev-lang/python:2.6 bar-1.ebuild: inherit foo Let's say this is in your overlay: foo.eclass: DEPEND=|| ( dev-lang/python:3.1 dev-lang/python:2.6 ) Now you install bar. How should portage know that it must regenerate the metadata cache, to see that it doesn't need to install python 2.6 if you already have 3.1?
Re: [gentoo-dev] bug wrangler queue is large...
On Tue, May 25, 2010 at 03:33:33PM -0400, Mike Frysinger wrote: On Tuesday 25 May 2010 14:46:01 Matti Bickel wrote: I wrangle bugs when there's a need and I'd like to hear what maintainers want to see on a bug assigned to them. If info is missing I usually ask for it and assign the bug anyway. If that's not wanted, let me know. i dont feel like this should go to the maintainer yet. if a report is missing something that the maintainer needs, it isnt ready for them to look at. so wranglers ask for it, leave it assigned to bug-wranglers, and close as NEEDINFO. when (if) things become available, it can then be re-opened and moved to the maintainer. No, don't close as NEEDINFO, mark as ASSIGNED. NEEDINFO bugs cannot be reopened by other users, even if they provide the requested information. NEEDINFO bugs are also easily forgotten about when the reporter forgets to reopen the bug him/herself. Plus, it's in the docs anyway. Do not assume that the reporter ought to know how to report bugs. An omitted `emerge --info' does not call for a public flogging, it simply calls for the missing `emerge --info'. Even experienced reporters make mistakes, so simply request the information, mark the bug as ASSIGNED and wait for the information you requested. http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml
Re: [gentoo-dev] bug wrangler queue is large...
On Tue, May 25, 2010 at 04:25:20PM -0400, Mike Frysinger wrote: and people on the wrangler alias see that traffic, so the state doesnt matter. but i guess you're trying to cater to people who only scan the assigned list rather than watching the e-mails sent to it. Yes, people like myself who don't normally wrangle bugs but try to help out occasionally. I'm not really interested in receiving all bug wrangler e-mails.
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
On Sat, Jun 05, 2010 at 05:49:08PM +0200, Thomas Sachau wrote: If any package does inherit python or distutils eclass, then those eclasses do pull in dev-lang/python, which is unversioned, so it will always pull in the latest version, in this case python-3*. You could change this, so it allows any major installed slot to satisfy the python dependency. A dependency on dev-lang/python *is* satisfied by any slot, any version. You've been told so already, if I recall correctly.
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
On Sun, Jun 06, 2010 at 01:03:48AM +0200, Thomas Sachau wrote: Am 05.06.2010 20:31, schrieb Harald van Dijk: On Sat, Jun 05, 2010 at 05:49:08PM +0200, Thomas Sachau wrote: If any package does inherit python or distutils eclass, then those eclasses do pull in dev-lang/python, which is unversioned, so it will always pull in the latest version, in this case python-3*. You could change this, so it allows any major installed slot to satisfy the python dependency. A dependency on dev-lang/python *is* satisfied by any slot, any version. You've been told so already, if I recall correctly. Every slot and every version *should* satisfy a dev-lang/python dependency, but currently such unspecified version dependency does automaticly pull in the latest version/slot, which in case of python does mean python-3*, even when you have e.g. python:2.6 installed. Fine, I'll be as explicit as possible: not quite. I have a Python 3-free system. I created a dummy ebuild that does nothing but pull in unversioned python. Let's see how it behaves. $ emerge -pv python These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS ] dev-lang/python-3.1.2-r3 [2.6.5-r2] USE=gdbm ipv6 ncurses readline sqlite ssl threads tk (wide-unicode) xml -build -doc -examples -wininst ELIBC=(-uclibc) 9,558 kB $ cat test-2.0.ebuild KEYWORDS=~amd64 SLOT=0 DEPEND=dev-lang/python $ emerge -pv test These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N] test/test-2.0 0 kB [1] Total: 1 package (1 new), Size of downloads: 0 kB Portage tree and overlays: [0] /usr/portage [1] /etc/portage/overlay Note how python 3 is *not* pulled in, despite an unversioned dependency on dev-lang/python. You only get that if you tell portage to try and update dependencies as well, and yes, if you do that, it's only fair that it attempts to update python.
Re: [gentoo-dev] LINGUAS handling
On Wed, Jun 09, 2010 at 11:38:03AM +0400, Peter Volkov wrote:
1. Do we want all packages to support LINGUAS if possible? It is
possible to leave gettext based package without LINGUAS and everything
will just work, but I think that it's good idea to make supported
languages visible to user through linguas_lang flags.
I agree, but I'd like to point out this would be a visible change in
default behaviour: the default would change from install everything to
install nothing. For gettext-based packages, install everything is a
sane default, in my opinion.
2. How should we handle case of unset LINGUAS in ebuild? Should we mimic
gettext and install all supported languages, using code like
LINGUAS=${LINGUAS-%UNSET%}
if test %UNSET% == $LINGUAS; then
# install all supported languages
fi
Firstly, don't use == with test. It's not portable. The bash built-in
test supports ==. Other test implementations don't, such as the one from
GNU coreutils, and the built-in test in other shells, don't. If you use
test in a context where you're absolutely sure the built-in version will
be used, and the executing shell is bash, then I suppose you can use ==,
but at that point you're better off using [[ ]] anyway.
That said, to test if a variable is set, use ${VAR+set} over
${VAR-unset}. ${VAR-unset} evaluates to unset if VAR is unset, and if
VAR is set to the string unset. I suppose that's why you used %UNSET%,
to reduce the possibility of accidents. You can reduce it to 0, using
for example
if [[ -z ${LINGUAS+set} ]]; then
# LINGUAS is unset
fi
? If yes, it's easy to write such code and put in eclass. If no, how do
we live with inconsistency that some packages will install all languages
some, will install nothing (document in handbook and add portage warning
in case LINGUAS is unset?)?
Unfortunately, consistency either way is bad. Making unset LINGUAS
install nothing changes gettext's design, when the whole idea behind
LINGUAS was to mimic gettext's design. Making unset LINGUAS install
everything causes massive disk space requirements for the default
settings for some packages such as openoffice. In my opinion, either of
those would be worse than having LINGUAS behave inconsistently.
3. What is the purpose of strip-linguas function (mentioned in
devmanual)? It's clear what it does but I have no ideas why. Probably
similar code could be used in QA function that will gather supported
languages from po directories and warn maintainer that it's time to
update linguas_lang in IUSE (and probably later it could be expanded
to support qt packages too).
It's used for some packages that fail to build with certain LINGUAS
values. If I recall correctly, binutils had a bug where putting en_GB in
your LINGUAS made the build fail, for example. binutils doesn't support
en_GB anyway, so it gets filtered out,
Re: [gentoo-dev] lastrite: www-client/kazehakase
On Sat, Jun 26, 2010 at 11:35:29AM +0300, Samuli Suominen wrote: nothing usable left in tree. # Samuli Suominen ssuomi...@gentoo.org (26 Jun 2010) # Masked for QA # # Fails to compile with stable xulrunner, see bug 317275 # Fails to compile with GTK+-2.20, see bug 325661 # Ignores LDFLAGS, see bug 268491 # Current stable is using vulnerable xulrunner, see bug 324953 # # Removal in 30 days www-client/kazehakase In case anyone is interested in picking this up, I've attached the patches from upstream for xulrunner and gtk+ to their bugs. With those, it's at least possible to get kazehakase to build, run, and display web pages.
Re: [gentoo-dev] Re: FYI: Rules for distro-friendly packages
On Sun, Jun 27, 2010 at 02:56:33PM +0300, Nikos Chantziaras wrote: On 06/27/2010 01:47 PM, Enrico Weigelt wrote: * Nikos Chantziarasrea...@arcor.de schrieb: Did it actually occur to anyone that warnings are not errors? You can have them for correct code. A warning means you might want to look at the code to check whether there's some real error there. It doesn't mean the code is broken. In my personal experience, most times a warning comes it, the code *is* broken (but *might* work in most situations). That's the key to it: most times. Granted, without -Wall (or any other options that tweaks the default warning level) we can be very sure that the warning is the result of a mistake by the developer. But with -Wall, many warnings are totally not interesting (unused parameter) and some even try to outsmart the programmer even though he/she knows better (taking address of variable declared register). In that last example, fixing it would even be wrong when you consider the optimizer and the fuzzy meaning of register which the compiler is totally free to ignore. The compiler is not totally free to ignore the register keyword. Both the C and the C++ standards require that the compiler complain when taking the address of a register variable. Other compilers will issue a hard error for it. Fixing the code to not declare the variable as register would be the correct thing to do. Make sure you *understand* warnings, and then you can decide whether to fix the code, if there is anything to fix, or to ignore.
Re: [gentoo-dev] Re: FYI: Rules for distro-friendly packages
On Sun, Jun 27, 2010 at 05:46:28PM +0300, Nikos Chantziaras wrote: On 06/27/2010 03:23 PM, Harald van Dijk wrote: The compiler is not totally free to ignore the register keyword. Both the C and the C++ standards require that the compiler complain when taking the address of a register variable. Other compilers will issue a hard error for it. Fixing the code to not declare the variable as register would be the correct thing to do. No, it would not be the correct thing to do, because of the following. (This is part of a discussion between me and someone quite smarter than me, who explained the issue in detail.) [snip] That explanation seems to be written by someone who does not know that taking the address of a register variable is simply not allowed. OK, long read, but the the conclusion is that fixing the code to not declare the variable as register would be the correct thing to do it *not* the correct thing to do. The correct thing to do is to ignore the warning, which is not possible if warnings are turned into errors. And which is not possible if the warning is a hard error in the first place. You also mentioned that other compilers will issue a hard error for it. That sounds rather strange, and I wonder which compilers that might be; someone should file a bug report against them ;) Well, let's start with gcc; that's quite an important one for Gentoo...
Re: [gentoo-dev] Minor changes in python.eclass and distutils.eclass
On Mon, Jul 05, 2010 at 07:01:27PM +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
2010-07-05 18:36:09 Tomáš Chvátal napisał(a):
Dne 5.7.2010 18:34, Arfrever Frehtes Taifersar Arahesis napsal(a):
python.eclass uses colors for build time outputting, which doesn't
communicate anything for users.
+ echo ${_RED}*${_NORMAL} ${_RED}Deprecation Warning: NEED_PYTHON
variable is deprecated and will be banned on 2010-10-01.${_NORMAL}
+ echo ${_RED}*${_NORMAL} ${_RED}Use PYTHON_DEPEND variable instead of
NEED_PYTHON variable.${_NORMAL}
+ echo ${_RED}*${_NORMAL} ${_RED}The ebuild needs to be fixed. Please
report a bug, if it has not been already reported.${_NORMAL}
The above is build outputting since when?
The colored, non-logged output in deprecation warnings is used as exception
to increase
the chance that ebuild maintainers will be notified earlier about the
necessity of changes
in given ebuilds.
einfo/ewarn/eerror output is repeated by default when emerge exits. By
not using einfo/ewarn/eerror, you are making it less likely that others
will be reading your deprecation notices.
Re: [gentoo-dev] Minor changes in python.eclass and distutils.eclass
On Mon, Jul 05, 2010 at 07:38:32PM +0200, Harald van Dijk wrote:
On Mon, Jul 05, 2010 at 07:01:27PM +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
2010-07-05 18:36:09 Tomáš Chvátal napisał(a):
Dne 5.7.2010 18:34, Arfrever Frehtes Taifersar Arahesis napsal(a):
python.eclass uses colors for build time outputting, which doesn't
communicate anything for users.
+ echo ${_RED}*${_NORMAL} ${_RED}Deprecation Warning: NEED_PYTHON
variable is deprecated and will be banned on 2010-10-01.${_NORMAL}
+ echo ${_RED}*${_NORMAL} ${_RED}Use PYTHON_DEPEND variable instead of
NEED_PYTHON variable.${_NORMAL}
+ echo ${_RED}*${_NORMAL} ${_RED}The ebuild needs to be fixed. Please
report a bug, if it has not been already reported.${_NORMAL}
The above is build outputting since when?
The colored, non-logged output in deprecation warnings is used as exception
to increase
the chance that ebuild maintainers will be notified earlier about the
necessity of changes
in given ebuilds.
einfo/ewarn/eerror output is repeated by default when emerge exits. By
not using einfo/ewarn/eerror, you are making it less likely that others
will be reading your deprecation notices.
Ugh. I see that you're using einfo already and suppressing its output.
In that case, my objection doesn't apply, but it's still nasty.
Re: [gentoo-dev] rgb file specification
On Sat, Jan 19, 2008 at 05:43:18PM +, Ferris McCormick wrote:
This is random musing based based on perhaps my own problems.
I need a local color.file to see well what I have going on, and
current xorg ignores that. Thus, at every build, there is in
oscolor.c a constant I must change from 1 to 0.
While I don't have any need for your specific change, I do have the same
problem with some other unrelated patches for unrelated packages. Instead
of manually changing the code for every version bump, you can set up your
bashrc to define a post_src_unpack function, which checks if
${CATEGORY}/${PN} == x11-base/xorg-server, and if so, applies the patch.
solar's old bashrc which does this is still found at
http://dev.gentoo.org/~solar/bashrc, and I've put up the function as
I'm using it at http://dev.gentoo.org/~truedfx/bashrc.
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-wm/sawfish: ChangeLog sawfish-1.3.2.ebuild sawfish-1.3_p20050816-r1.ebuild sawfish-1.3_p20060816.ebuild sawfish-1.3.20040120.ebuild sawfi
On Tue, Jan 22, 2008 at 11:21:26PM -0500, Mike Frysinger wrote: On Tuesday 22 January 2008, Donnie Berkholz wrote: On 20:58 Tue 22 Jan , Harald van Dijk (truedfx) wrote: WANT_AUTOCONF=latest WANT_AUTOMAKE=latest redundant, please drop Done. eaclocal || die eautoconf || die these things call die themselves ... an reason you're using these instead of eautoreconf ? aclocal/autoconf changes often imply having to regenerate Makefile.in ... sawfish doesn't use automake (except for aclocal), and eautoreconf used to force automake. As it no longer has that problem, I've switched to eautoreconf. Thanks for the comments. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-util/eclipse-sdk: eclipse-sdk-3.2.1-r2.ebuild ChangeLog eclipse-sdk-3.3.1.1.ebuild
On Wed, Jan 23, 2008 at 05:31:13PM -0500, Mike Frysinger wrote:
On Wednesday 23 January 2008, Steve Long wrote:
Or even: find blah -exec sed 'blah blah' +
we specifically discourage `find -exec` in favor of `find -print0 | xargs -0`
because it sucks.
In what way? I'm not aware of any problems with find -exec ... {} + that
are handled any better by find -print0 | xargs -0. It's too bad that you
can only add {} + at the very end of the command, but that's just as
much a problem with xargs -0.
Your reply didn't make it clear, but you're aware of the difference
between -exec {} ; and -exec {} +, right? The former executes a single
command for every file, while the latter builds one long argument list
when possible, the same way xargs does.
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-editors/ted
On Fri, Sep 12, 2008 at 10:17:12PM -0500, Jeremy Olexa wrote: # Jeremy Olexa [EMAIL PROTECTED] (13 Sep 2008) # Masked for removal in 60 days. Multiple issues, broke for some people. Needs # maintainer. automagic deps. See bug #154997 app-editors/ted I've fixed the build and marked myself as maintainer; I don't want to see this gone just yet.
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
On Thu, Oct 20, 2005 at 10:56:57PM -0400, Mike Frysinger wrote: On Thursday 20 October 2005 10:49 pm, Dan Meltzer wrote: Why single out this one? ones system will not break irreperbly without a cxx compiler, it'll just cause a another recompile to get it to work after breakage if the person is using -* (which has already been said to be hackish and ill-advised, so doom on them! it will actually if you build gcc w/out C++ support that means no libstdc++ no libstdc++ means python on most boxes is now broken no python means no emerge how exactly are you going to re-emerge gcc then ? oh, you cant ... -mike It could be handled the same way busybox handles USE=make-symlinks: simply abort unless the user makes it really clear via an extra variable that he knows what he's doing. A nocxx flag isn't necessary to protect users. : Test phase [not enabled]: sys-apps/busybox-1.01 : : Install busybox-1.01 into /var/tmp/portage/busybox-1.01/image/ category sys-apps : * setting USE=make-symlinks and emerging to / is very dangerous. : * it WILL overwrite lots of system programs like: ls bash awk grep (bug 60805 for full list). : * If you are creating a binary only and not merging this is probably ok. : * set env VERY_BRAVE_OR_VERY_DUMB=yes if this is realy what you want. : : !!! ERROR: sys-apps/busybox-1.01 failed. : !!! Function src_install, Line 176, Exitcode 0 : !!! silly options will destroy your system : !!! If you need support, post the topmost build error, NOT this status message. pgpivGcvFDvuY.pgp Description: PGP signature
[gentoo-dev] Ebuilds for packages without a homepage?
What's the right thing to do with an ebuild's HOMEPAGE variable if there is not any homepage? Different packages have different approaches for this; some don't have any HOMEPAGE line (dev-util/cdecl), some set HOMEPAGE to the empty string (app-i18n/kon2), possibly with a comment following it (app-i18n/kcc), and some set HOMEPAGE to some string that's obviously not a URL such as none (app-doc/xmltoman) or I HAVE NO HOME :( (app-text/dos2unix). There don't seem to be any guidelines in the docs, either official or unofficial, other than to put a link to the freshmeat page or something similar, which isn't possible in my case because there is no freshmeat page or anything similar that I know of, so what should I do? pgp6vZRTejf0M.pgp Description: PGP signature
Re: [gentoo-dev] status of http://wwwredesign.gentoo.org
On Mon, Nov 21, 2005 at 02:18:21AM -0500, Curtis Napier wrote: If you have access to a Macintosh, Windows, *BSD or any other OS or Browser please test the site and include your OS and the browser version in your feedback. I haven't received feedback from Konqueror or Safari so feedback from those browsers would be much appreciated. It looks good in w3m, except for one minor thing: since background images don't show, the top left link (a transparent image to show the background) is simply a large empty block. Could you use a real image for that, assuming that doesn't break anything in other browsers? pgpOrYhLRAmHt.pgp Description: PGP signature
Re: [gentoo-dev] status of http://wwwredesign.gentoo.org
On Mon, Nov 21, 2005 at 02:18:21AM -0500, Curtis Napier wrote: If you have access to a Macintosh, Windows, *BSD or any other OS or Browser please test the site and include your OS and the browser version in your feedback. I haven't received feedback from Konqueror or Safari so feedback from those browsers would be much appreciated. With IE 5 for Mac, the top bar looks messed up: http://dev.gentoo.org/~truedfx/ie5mac.png I haven't looked for a way to get it displayed right yet; if I find something before you do, I'll let you know :) pgpczS2ZVLcIP.pgp Description: PGP signature
Re: [gentoo-dev] Re: Decision to remove stage1/2 from installation documentation
On Tue, Nov 22, 2005 at 11:39:29AM -0500, Chris Gianelloni wrote: Another Gentoo is about choice argument. Can I ask you something? Where does it say that Gentoo is about choice? I see lots of places that say that Gentoo allows you to customize, but nowhere do I see anything that says that we are about choice. http://www.gentoo.org/doc/en/handbook/2005.1/handbook-x86.xml?part=1 About the Gentoo Linux Installation Users not familiar with Gentoo do not always know that choice is what Gentoo is all about. And following that link: http://www.gentoo.org/doc/en/handbook/2005.1/handbook-x86.xml?part=1chap=1 Welcome! First of all, welcome to Gentoo. You are about to enter the world of choices and performance. Gentoo is all about choices. When installing Gentoo, this is made clear to you several times -- you can choose how much you want to compile yourself, how to install Gentoo, what system logger you want, etc. Gentoo is a fast, modern metadistribution with a clean and flexible design. Gentoo is built around free software and doesn't hide from its users what is beneath the hood. Portage, the package maintenance system which Gentoo uses, is written in Python, meaning you can easily view and modify the source code. Gentoo's packaging system uses source code (although support for precompiled packages is included too) and configuring Gentoo happens through regular textfiles. In other words, openness everywhere. It is very important that you understand that choices are what makes Gentoo run. We try not to force you onto anything you don't like. If you feel like we do, please bugreport it. (Note that I'm not going to argue either way whether this is a good thing; I'm merely pointing out that the docs do say we're about choice.) pgpVhourpnf0y.pgp Description: PGP signature
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Fri, Nov 25, 2005 at 12:14:53PM +, kang wrote: Curtis Napier wrote: gentoo.org and all domains owned by the Gentoo Foundation should render correctly in all browsers that are still in general use. IE5 on the mac is still a valid browser and will be supported as much as possible. IE5 for mac contains unfixed security issues which won't be fixed (as announced by MS), how is that considered supported ? Is it even still distributed within MacOSX Tiger ? Even with its bugs, it's one of best browsers for MacOS 8.1, which I still use. But if you can suggest a better one, please do. pgpNK7kaZudKw.pgp Description: PGP signature
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Fri, Nov 25, 2005 at 03:56:14PM +, kang wrote: Harald van Dijk wrote: Even with its bugs, it's one of best browsers for MacOS 8.1, which I still use. But if you can suggest a better one, please do. You might want to try iCab or opera. Well, I'd suggest you to run linux on it though ;) Or simple mozilla: http://www.t3.rim.or.jp/~harunaga/mozilla-macos9/ Linux can work fine on it, and I'd use that with MOL if I didn't have to deal with a dead battery not remembering the nvram settings, making Linux unbootable every time I pull out the cables. :) iCab has the same CSS issues as IE5 plus more, and as far as I know, all Mozilla ports require MacOS 8.6 (or higher). An older Opera should work though, thanks. And assuming it does, no complaints here if the site won't display right in IE5. pgpm6a1f7eN6P.pgp Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
On Wed, Dec 14, 2005 at 03:50:16AM +, Mike Frysinger wrote: my gnu stack docs are actually complete: http://hardened.gentoo.org/gnu-stack.xml A question about that: you discourage fixing this with --noexecstack because it's better to be able to submit a patch upstream. What's your take on patches that modify configure scripts or similar files to check for this flag, keeping it out of the ebuild? Is that good, acceptable, or bad, and why? pgpdHOunZ5i9m.pgp Description: PGP signature
Re: [gentoo-dev] Textrels in packages policy
On Wed, Dec 14, 2005 at 08:51:42AM +0100, Kevin F. Quinn wrote: On Wed, 14 Dec 2005 07:59:23 +0100 Harald van Dijk [EMAIL PROTECTED] wrote: On Wed, Dec 14, 2005 at 03:50:16AM +, Mike Frysinger wrote: my gnu stack docs are actually complete: http://hardened.gentoo.org/gnu-stack.xml A question about that: you discourage fixing this with --noexecstack because it's better to be able to submit a patch upstream. What's your take on patches that modify configure scripts or similar files to check for this flag, keeping it out of the ebuild? Is that good, acceptable, or bad, and why? Using '--noexecstack' overrides anything the compiler works out for itself, so applying it indiscriminately is a bad idea. For example, if an application contains asm code with no markings, but also contains code that creates trampolines, it should be marked for executable stack even if the asm code is fixed. Applying '--noexecstack' via LDFLAGS would break such an application. Regarding patches, it's usually much simpler to patch asm source code compared to patching an application's make process. Patching asm source code just means appending a few lines depending on the type of assembler used. As far as ebuilds are concerned, if you add it to LDFLAGS you will need to re-check the application every time you bump the ebuild, and it's difficult to find new occurrences of nested functions for example if you've applied '--noexecstack'. LDFLAGS? Assuming you meant ASFLAGS, this doesn't affect C files, and would need rechecking of the assembly code on updates just as much as patches which add .note.GNU-stack would, right? pgpNUhmpkS0CL.pgp Description: PGP signature
