Re: [gentoo-dev] Re: Installing COPYING or LICENSE files
On Tue, Dec 27, 2005 at 01:01:10AM -0600, R Hill wrote: Removing these files and relying on LICENSE=foo in the ebuild could be seen as a copyright violation. There are lots of samples in /usr/src/licenses that aren't generic, but include a copyright notice naming the authors of a particular piece of software, but it doesn't match with all packages under this license of course. Take ZLIB as example. Since I'm not a lawyer I might be wrong, but me thinks it would make sense to ask one. AFAIK most licenses need to be included with the distribution of the source, not installed on the system after compilation. But I could be wrong too. There are exceptions, a popular one being BSD. * Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. As a quick example, iputils is BSD-licensed and does not install or reproduce its license, so does this cause problems for iputils binpkgs? pgp6nvBCbR8Qu.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml
On 26-12-2005 22:11:46 -0200, Marcelo Ges wrote: Fellow Gentooers, Here is a draft of an enhancement proposal that should allow upstream information to be included in metadata.xml: http://dev.gentoo.org/~vanquirius/glep-0099.txt using http://www.gentoo.org/proj/en/glep/glep-0046.html The bugs-to tag can hold either an email address or URL. Not a big issue, but why not make it an URI, such that an email address is written as mailto:[EMAIL PROTECTED]? Using an URI gives a nice specified format (already including the http(s) which you require) and should go with regular URI parsers. Given the URI thing, maybe it can be useful to define the changelog tag to have an URI as well, since some upstreams ship the changelog with the sources and don't put them on the web. In such case you might want to use a file:// URI to point to the file on disk when installed? I realise this is tricky. Not clear from the text, but I take it from the example that remote-id has an attribute named type which points to some source. Is there a reason to make that an attribute, instead of a tag? Also, the remote-id tag in the example has a TEXT node which apparently is the id, but needs some information in order to track it. Taking your SourceForge example: remote-id type=sourceforgeadium/remote-id Usually for SourceForge means that adium in this case is the UNIX project name, hence an URL such as http://sourceforge.net/projects/adium points to the project's SourceForge home, while http://adium.sourceforge.net/ points to the project's home page. It's not clear for me where this is different from the home page URL in the ebuild itself. I don't know if FreshMeat can be a real project home. What I wanted to say, where is the logic stored on how to make this id into some resource? And if you store that logic somewhere, why not in the XML structure? Any reason to use an id, and not for instance an URI to the remote 'developers' homepage/resource? Observation: the added data is mainly targetted at developers, not users. Given the ongoing discussion, this might be an interesting side note. In an overlay I'm currently keeping 'portnotes' in metadata.xml, which basically give us developers a quick look on what was necessary to port an ebuild. This is by no means interesting for a regular user, and we put it in metadata.xml because that allows to group the portnotes, since XML is a bit more structured than a changelog. For the sake of rsyncs/speed/storage/whatever, perhaps this purely targetted at developers information should be put in a separate file, which is by default excluded in the rsync? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Installing COPYING or LICENSE files
Harald van Dijk wrote: On Tue, Dec 27, 2005 at 01:01:10AM -0600, R Hill wrote: Removing these files and relying on LICENSE=foo in the ebuild could be seen as a copyright violation. There are lots of samples in /usr/src/licenses that aren't generic, but include a copyright notice naming the authors of a particular piece of software, but it doesn't match with all packages under this license of course. Take ZLIB as example. Since I'm not a lawyer I might be wrong, but me thinks it would make sense to ask one. AFAIK most licenses need to be included with the distribution of the source, not installed on the system after compilation. But I could be wrong too. There are exceptions, a popular one being BSD. * Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. As a quick example, iputils is BSD-licensed and does not install or reproduce its license, so does this cause problems for iputils binpkgs? We are not redistributing anything in binary form when installing programs. This all happens on the users computers. We are distributing upstream source tarballs verbatim of course. If the license should be installed, shouldn't the upstream make install take care of it then? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Installing COPYING or LICENSE files
On Tue, Dec 27, 2005 at 12:32:25PM +0200, Petteri Räty wrote: Harald van Dijk wrote: On Tue, Dec 27, 2005 at 01:01:10AM -0600, R Hill wrote: Removing these files and relying on LICENSE=foo in the ebuild could be seen as a copyright violation. There are lots of samples in /usr/src/licenses that aren't generic, but include a copyright notice naming the authors of a particular piece of software, but it doesn't match with all packages under this license of course. Take ZLIB as example. Since I'm not a lawyer I might be wrong, but me thinks it would make sense to ask one. AFAIK most licenses need to be included with the distribution of the source, not installed on the system after compilation. But I could be wrong too. There are exceptions, a popular one being BSD. * Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. As a quick example, iputils is BSD-licensed and does not install or reproduce its license, so does this cause problems for iputils binpkgs? We are not redistributing anything in binary form when installing programs. Of course, but we are redistributing programs in binary form in exactly the same state as when installing them, via stages and live/packagecds. If the license should be installed, shouldn't the upstream make install take care of it then? iputils doesn't do a make install, and if it did, it would still be reasonable if that didn't copy the license, since the users who run that themselves don't need it. pgpdVplq0zAmF.pgp Description: PGP signature
Re: [gentoo-dev] Re: Installing COPYING or LICENSE files
On Tue, Dec 27, 2005 at 12:20:39PM +0100, Harald van Dijk wrote: iputils doesn't do a make install, and if it did, it would still be reasonable if that didn't copy the license, since the users who run that themselves don't need it. I don't really see the big difference (regarding this issue) in manually installing a package or using Gentoo Portage for installing it? Why would people who install it via a script in Gentoo Portage want the useless files installed - when they wouldn't want them installed when doing a manual install? Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpEzADs1tCOj.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 12:08, Brian Harring wrote: On Tue, Dec 27, 2005 at 03:54:38AM +0100, Carsten Lohrke wrote: On Tuesday 27 December 2005 03:40, Brian Harring wrote: The version of digikam being merged requires slot=3.5- it should be depending on libk* slot=3.5, also, no? No! It (and also its dependencies) can be built against each 3.x slot. As long as the information is represented dependency wise, portage should be able to handle it fine. Just need to have that info there. It can't be handled dependency wise, because what is interesting is against which KDE version the relevant ebuilds are actually installed. So note the comment in the email you are responding to about locking down the used dep/rdeps for an install. Via that, could lock down the slot it was compiled against. Bit more to it then that, but the concerns your raising *again* are not use/slot based, your pointing at other portage faults (thus please seperate those concerns from use/slot). I may be missing something, but I can't see how this will resolve Carsten's issue. From what I can tell, the ebuilds would be laid out something like: digikam:DEPEND=|| ( kdelibs:3.5 kdelibs:3.4 ) libkipi libkexif libkipi:DEPEND=|| ( kdelibs:3.5 kdelibs:3.4 ) libkexif:DEPEND=|| ( kdelibs:3.5 kdelibs:3.4 ) If all three of those packages were first built against kdelibs:3.4 and then kdelibs:3.5 became available then rebuilding any one of them without rebuilding the others will break digikam. I can't see how it's directly represented in the metadata unless you want to overload the meaning of SLOT. If overloading, dependencies would be flattened (meaning || ( kdelibs:3.5 kdelibs:3.4 ) would have became kdelibs:3.4 for the original install) within the installed package database but there's also there's the implication that only one slot of a package be allowed in a connected set of nodes. Is that what you're getting at? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 04:08, Brian Harring wrote: So note the comment in the email you are responding to about locking down the used dep/rdeps for an install. That would be a maintenance nightmare. Every time a new KDE versions comes out a new ebuild revision for every package depending on KDE would be needed to work with this particular KDE version. Just for the sake of having to match with insufficient slot dependencies. I'll give another example: Application X works with KDE 4.0 (which implies that it will work with all KDE 4.x versions). Locking the dependency down to e.g. kde-base/kdelibs:4.0 implies adding another ebuild revision depending on kde-base/kdelibs:4.1, another one on kde-base/kdelibs:4.2. In short: Even having slot dependencies they won't be used, because =kde-base/kdelibs-4* is the dependency, which matches and no one will add hundreds of ebuilds just to follow the limiting scope Portage is providing via slot dependencies. Based on the packages we have now in Portage, that would mean ~300 additional new ebuild revisions as a side effect of every KDE version bump. Simply ridiculous. Carsten pgptdIP2KO63X.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 04:07, Ciaran McCreesh wrote: But it's not binary compatible between KDE slots. So, once we have :slot dependencies, you should link to a specific :slot (possibly controlled via USE). It's like packages that can use either gtk or gtk2 -- this has to be handled via a USE flag rather than linking against whichever happens to be there. Forget it. Not maintainable, doesn't make any sense at all and won't happen. And it's not like gtk1/gtk2. An application working with KDE 3.0 works as fine with KDE 3.5. gtk1/gtk2 is comparable to KDE 3.x/KDE 4.x. Carsten pgpOJXgRK2fLD.pgp Description: PGP signature
Re: [gentoo-dev] Re: Installing COPYING or LICENSE files
On Tuesday 27 December 2005 08:08, Mike Frysinger wrote: anyone who installs a program in portage already has a copy of the license on their system ... $PORTDIR/licenses/ My point was that it is often not the license of the copyright holder, because the copyright notice included in many licenses names the author of a specific application. Carsten pgpDkHtnGULA0.pgp Description: PGP signature
Re: [gentoo-dev] Re: Installing COPYING or LICENSE files
On Tue, Dec 27, 2005 at 03:57:55PM +0100, Henrik Brix Andersen wrote: On Tue, Dec 27, 2005 at 12:20:39PM +0100, Harald van Dijk wrote: iputils doesn't do a make install, and if it did, it would still be reasonable if that didn't copy the license, since the users who run that themselves don't need it. I don't really see the big difference (regarding this issue) in manually installing a package or using Gentoo Portage for installing it? Why would people who install it via a script in Gentoo Portage want the useless files installed - when they wouldn't want them installed when doing a manual install? Right, end users don't need them, regardless of package manager. But as I mentioned in my previous message, ebuilds are not only for end users. pgplxt6FcLO6R.pgp Description: PGP signature
Re: [gentoo-dev] Installing COPYING or LICENSE files
Petteri Räty wrote: Petteri Räty wrote: R Hill wrote: Daniel Ahlberg wrote: * if ebuild installs COPYING and/or INSTALL into doc. Is this actually important? There are a hell of a lot of ebuilds that fail under this rule. I'd like to start filing patches for some of the packages in this list so I'm interested in knowing what's worth fixing and what's being pedantic. Not a blocker but just useless. Filing patches for ebuilds doing this is greatly appreciated by at least me. Regards, Petteri https://bugs.gentoo.org/show_bug.cgi?id=113680 So is there a policy about [not] installing the COPYING or LICENSE files already? If there isn't one, I propose we make a decision about this to have uniform behaviour across the tree. Regards, Petteri Looking at the thread I don't see anyone opposing not installing for example a copy of GPL-2 or the generic INSTALL file. So could we write a policy somewhere not to these duplicated files when we are not legally required to install these files? That should satisfy any conserns raised. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 14:00, Jason Stubbs wrote: If all three of those packages were first built against kdelibs:3.4 and then kdelibs:3.5 became available then rebuilding any one of them without rebuilding the others will break digikam. I can't see how it's directly represented in the metadata unless you want to overload the meaning of SLOT. It's not possible to represent that via dependencies. What is needed is some sort of introspection which relevant ebuild is built against which KDE version and if those _installed_ ebuild:kdever combinations match the one the _actual_ ebuild to emerge. But you're right about the overloading of the meaning of slots, because that's happening right now. Slots are used to install several versions of a package side by side. The idea Ciaranm and Brian are proposing to lock ebuilds depending on slotted packages down to a single slot is the redefinition. And once again: This doesn't match reality. Carsten pgpJIb6PA58Z0.pgp Description: PGP signature
Re: [gentoo-dev] Unified nVidia Driver Ebuild ready for testing
On Fri, Dec 23, 2005 at 09:49:04PM +0100, Diego 'Flameeyes' Pettenò wrote: I thought that we (gentoo devs) were trying to split the modules from ebuilds, so that people don't need to waste time with userland when rebuilding modules after kernel update. We are. At least that's the policy suggested by the kernel herd. This policy also allows applying securiy/bug fixes to kernel modules without forcing users to recompile the userland part and vice versa. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgppcUbnhOGPn.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 22:45, Carsten Lohrke wrote: On Tuesday 27 December 2005 14:00, Jason Stubbs wrote: If all three of those packages were first built against kdelibs:3.4 and then kdelibs:3.5 became available then rebuilding any one of them without rebuilding the others will break digikam. I can't see how it's directly represented in the metadata unless you want to overload the meaning of SLOT. It's not possible to represent that via dependencies. What is needed is some sort of introspection which relevant ebuild is built against which KDE version and if those _installed_ ebuild:kdever combinations match the one the _actual_ ebuild to emerge. Do you mind reading and replying to the second paragraph (which happens to be the only new information I brought to this thread). Underlining words to emphasize a point to me that I've opened by agreeing is really not necessary. But you're right about the overloading of the meaning of slots, because that's happening right now. Slots are used to install several versions of a package side by side. The idea Ciaranm and Brian are proposing to lock ebuilds depending on slotted packages down to a single slot is the redefinition. And once again: This doesn't match reality. You've misunderstand what is meant by locking ebuild dependencies. I gave you a definition in my second paragraph. Please have a re-read. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 14:59, Jason Stubbs wrote: Do you mind reading and replying to the second paragraph (which happens to be the only new information I brought to this thread). Underlining words to emphasize a point to me that I've opened by agreeing is really not necessary. I did not want to hurt your feelings by underlining, Jason. :) You missed a point in your wording of the digikam example in your first paragraph (while implied in the second), though. It's not only that libkexif and libkipi need to be rebuilt, but any other application (e.g. showimg) depending on them as well. You've misunderstand what is meant by locking ebuild dependencies. I gave you a definition in my second paragraph. Please have a re-read. I did not comment on what you wrote, but on Ciaranm's and Brian's ideas about using slot dependencies regarding KDE packages. Carsten pgpPqXa3zhQjN.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml
On Tuesday 27 December 2005 03:06, Marius Mauch wrote: Ciaran McCreesh wrote: On Tue, 27 Dec 2005 02:43:19 +0100 Marius Mauch [EMAIL PROTECTED] wrote: | Will those new tags support the restrict attribute? Is restrict something that's in use and working, or did it never get off the drawing board? Well, it's listed in metadata.dtd, so any package *could* use it. I currently don't have a tree anywhere near me to check if it is actually used nor do I know if any metadata.xml related tools understand it correctly. It has been in for a long while. If there are metadata.xml related tools for which it makes sense to understand it, they are broken if they don't. Adding the attribute on these tags should not put a problem. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpGe9ZrhpIUK.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml
On Tuesday 27 December 2005 01:11, Marcelo Góes wrote: Fellow Gentooers, Here is a draft of an enhancement proposal that should allow upstream information to be included in metadata.xml: http://dev.gentoo.org/~vanquirius/glep-0099.txt It is authored by ciaranm and me (vanquirius). Please comment :-). What is the reason for having an upstream tag? Wouldn't it be easier to just name the tags properly. And what about just using a general attribute tag like meta name=upstreammaint value=[EMAIL PROTECTED]/ Besides this, is it really useful to put this information in the metadata.xml file? Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpFR0NOh6wgv.pgp Description: PGP signature
Re: [gentoo-dev] Optimizing performance
On Saturday 24 December 2005 00:52, Diego 'Flameeyes' Pettenò wrote: On Friday 23 December 2005 18:35, Paul de Vrieze wrote: Just to add. This is not so much related to debugging information in the library files (what gdb can use). That information never makes it from disk so is not that much of a speed issue (esp. if it is split out). Actually, if the binaries are not stripped, they consume more memory. With splitdebug the issue is unseen (I'm happily using it with -g3 for everything now..) Debug info shouldn't be loaded into memory. Or is it? I agree though that splitting them out is probably better for memory use. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpNBJEvWmG1i.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Monday 26 December 2005 21:28, Ciaran McCreesh wrote: On Mon, 26 Dec 2005 21:09:31 +0100 Carsten Lohrke [EMAIL PROTECTED] Well, any library that changes ABI should use a different SLOT for each revision. So SLOT depends should be able to replace the need for = and ~ and and = dependencies entirely. Which is a good thing, since those atoms make dependency resolution a general-case unsolvable problem. Well, it shouldn't be unsolvable. Choosing can be done with the following process: - Get the list of packages with the requested name. - Sort the list from the newest version, to the oldest. - Iterate over the packages: - Apply all restrictions on the package (including exclusions). If the package satisfies all, test it's dependencies recursively. - If all dependencies match, this package matches the dependency. Continue with the next depend atom. - If no match, iterate the next package. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpHcsngDFnQV.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 01:33, Carsten Lohrke wrote: On Monday 26 December 2005 21:28, Ciaran McCreesh wrote: If they're purely in DEPEND, that one isn't even an incompatability. Right. But it's not that unlikely to see such a corner case sooner or later and it would be good if Portage catches it, instead spitting out a weird message, leaving the root of the issue in the dark. Should be also simple to write a test case. Well, any library that changes ABI should use a different SLOT for each revision. So SLOT depends should be able to replace the need for = and ~ and and = dependencies entirely. Which is a good thing, since those atoms make dependency resolution a general-case unsolvable problem. The problem is not the SLOT change, but to build foo depending on bar against KDE X, while bar is built against KDE Y. foo and bar support all slotted KDE versions, but they need to be build against the same one. You simply cannot express this via slot dependencies, so this feature is useless for KDE packages. Yes, this needs more sophisticated ebuild syntax and handling. In general one must support dependent dependencies for this. This requires many features portage doesn't offer yet. A.o. recording the actual versions that satisfied a dependency at compile time. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpLVfMXmW7nj.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Saturday 24 December 2005 04:40, Jason Stubbs wrote: I don't think its trolling when we've been let down on it in the past, had it postponed to the great redesign ( project baghira, I think, too) And so on. Even though I'd probably not hold my breath? It's something that many people want but most are not evening willing to attempt implementing it. What was the purpose of that comment? To express that based on my experience, I don't expect it to be in production before June 2006. I do understand it would take such long though. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpbJi5DUj7Jh.pgp Description: PGP signature
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On Friday 23 December 2005 22:36, Ciaran McCreesh wrote: On Fri, 23 Dec 2005 20:33:13 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | - Checkout time of a full new tree (no load, and with load) Do we really care about this? SVN will do really really badly here, but does it matter? Depends on how long it takes. More than half an hour on a fast connection would certainly be quite long. If it gets into 4 hours or more, it becomes a real anoyance. | - Concurrency performance (how do multiple simultaneous commits and | updates perform) With this one, you've got to bear in mind that SVN will correctly handle transaction commits, whereas CVS will quite happily let you crap all over half of someone else's transaction. Performance comparisons are only one part of it... I know, I should probably have mentioned it. But the proper concurrency support comes at a price. To make a proper decision, we need to know how big the price is. A theoretically perfect solution may very well be practically impossible. At that point it shows that the theory overlooked certain issues that users care about. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpBJPfAyKVBU.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 17:06, Jason Stubbs wrote: What about using the ( kde-libs/kde:4 =kde-libs/kde-4.0.1 ) syntax, where the would indicate that the atoms are to be folded, and consider a single package that should satisfy them instead of the default where it would require two packages. Portage's current behaviour is to consider individual atoms individually, but I wouldn't take that to mean it to be the default (as in that all atoms must be satisfied individually). Optimal behaviour would be to do as little work as possible to adhere to all requirements, making (or ranged deps) unneccessary. That is true, but my proposal would then still add value in requiring both to be satisfied by one and the same package. If you have different syntax (perhaps not duplicating the package name) that would be good /better for me. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp6uLWN8jTcd.pgp Description: PGP signature
Re: [gentoo-dev] Allow upstream tags in metadata.xml
On 12/27/05, John Myers [EMAIL PROTECTED] wrote: What if upstream is more than one person, but less than an organization? What if there is more than one upstream such as for gentoo-sources, where the maintainer of each of the patchsets could be considered an upstream? I don't see a problem with having multiple name and email fields. Perhaps there could be an additional description tag to discriminate what each person is responsible for. if this is to be subject to automated processing, shouldn't there be a registry of valid type values maintaining a definition of what the value of the element corresponds to for each type? Yes. Thus far, I have in mind freshmeat, sourceforge and cpan, but other types can be added later. On 12/27/05, Grobian [EMAIL PROTECTED] wrote: The bugs-to tag can hold either an email address or URL. Not a big issue, but why not make it an URI, such that an email address is written as mailto:[EMAIL PROTECTED]? Using an URI gives a nice specified format (already including the http(s) which you require) and should go with regular URI parsers. Sounds good enough. Given the URI thing, maybe it can be useful to define the changelog tag to have an URI as well, since some upstreams ship the changelog with the sources and don't put them on the web. In such case you might want to use a file:// URI to point to the file on disk when installed? I realise this is tricky. Hmmm... I'm not sure about this one. Not only is it tricky, but the whole point of this GLEP is to facilitate the finding of online up-to-date information. If there is no online changelog, I think it may be better just to ommit this field. What I wanted to say, where is the logic stored on how to make this id into some resource? And if you store that logic somewhere, why not in the XML structure? Any reason to use an id, and not for instance an URI to the remote 'developers' homepage/resource? Yes, there is a logic. I think it is easier to maintain an external list, such as we do with thirdpartymirrors. The point of listing alternative resources is that they may include features not provided by upstream itself. For example, an announce list that lets one know when a new version has been released. On 12/27/05, Paul de Vrieze [EMAIL PROTECTED] wrote: What is the reason for having an upstream tag? Aggregate useful upstream information in one place. Wouldn't it be easier to just name the tags properly. How? And what about just using a general attribute tag like meta name=upstreammaint value=[EMAIL PROTECTED]/ It's not bad, but isn't it better to have it in the structured way we suggest? It's graphically easier to read/write. Cheers! I'll be back the first week of January :-). Marcelo -- Marcelo Góes [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Wed, 28 Dec 2005 01:20:50 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | If backtracking was all there was to it, it could be done very | quickly of course. However, it's essentially a brute force method; | I'm not very good with O notation but I think it's O(n^n). I've got | an algorithm in my head that'll do it but it goes into an infinite | loop in the cases that Carsten mentioned. That's why things are | taking so long. I should really write it down... It's worse than O(n^n) if you try to do USE dep conflict resolution too... -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, 27 Dec 2005 16:48:55 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | Well, it shouldn't be unsolvable. Choosing can be done with the | following process: Your algorithm doesn't work for cases which can be solved by up / down cycling of a version. It also doesn't work for cases where we need the dep tree today rather than some time next year. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, 27 Dec 2005 14:05:21 +0100 Carsten Lohrke [EMAIL PROTECTED] wrote: | On Tuesday 27 December 2005 04:08, Brian Harring wrote: | So note the comment in the email you are responding to about locking | down the used dep/rdeps for an install. | | That would be a maintenance nightmare. Every time a new KDE versions | comes out a new ebuild revision for every package depending on KDE | would be needed to work with this particular KDE version. Just for | the sake of having to match with insufficient slot dependencies. eclass, and no -r bump. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 18:07, Ciaran McCreesh wrote: It's worse than O(n^n) if you try to do USE dep conflict resolution too... Theoretically yes, practically the worst number of dependency levels we speak of to walk up/down is not infinite ;). Of course there's no chance to get this linear (speak: walking down the dependencies once), unless you store the information which ebuild depends (or more exactly DEPENDs RDEPENDs) on foo in a list in foo's pkg db entry. The dependency resolution of the packages needed to rebuild on top of it is not different as usual. Carsten pgp3ntoKKjKxX.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 18:10, Ciaran McCreesh wrote: eclass, and no -r bump. Then it would not be possible to build the Application against different KDE versions and those who want to stay with a previous KDE version wouldn't be able to install any application. And conditional dependencies would break caching. Carsten pgple7l1HhYiZ.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, 27 Dec 2005 18:37:05 +0100 Carsten Lohrke [EMAIL PROTECTED] wrote: | On Tuesday 27 December 2005 18:07, Ciaran McCreesh wrote: | It's worse than O(n^n) if you try to do USE dep conflict resolution | too... | | Theoretically yes, practically the worst number of dependency levels | we speak of to walk up/down is not infinite ;). Can you prove it, for the allow USE and version cycling case? (Hint: you may find the PCP somewhat useful...) -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing
On Tue, 27 Dec 2005 16:50:16 +0100, Henrik Brix Andersen wrote: On Fri, Dec 23, 2005 at 09:49:04PM +0100, Diego 'Flameeyes' Pettenò wrote: I thought that we (gentoo devs) were trying to split the modules from ebuilds, so that people don't need to waste time with userland when rebuilding modules after kernel update. We are. At least that's the policy suggested by the kernel herd. This policy also allows applying securiy/bug fixes to kernel modules without forcing users to recompile the userland part and vice versa. Regards, Brix Thanks all for the feedback. It's important to realize that userland in this case is under 1 minute compile time. One of the modules, glx, doesn't even get compiled. A poster on this thread noted that glx took 14 seconds -- it just copies closed source libraries. Sometimes one can go overboard trying to modularize and perfect an installation process. Look at the user list and see how many problems some enhancements cause -- keyword changes, use variables, etc.! Here, the intent is to simplify things, remove steps and ebuilds, and make it more user friendly and require less interaction. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Tue, 27 Dec 2005 18:44:01 +0100 Carsten Lohrke [EMAIL PROTECTED]
wrote:
| On Tuesday 27 December 2005 18:10, Ciaran McCreesh wrote:
| eclass, and no -r bump.
|
| Then it would not be possible to build the Application against
| different KDE versions and those who want to stay with a previous KDE
| version wouldn't be able to install any application.
Sure they would. In the eclass, do something like (untested, buggy,
just a vague proof of concept not real code):
s=
for s_p in ${KDE_NEEDS_PACKAGES} ; do
s_s=
for s_v in 3.3 3.4 4.0 ; do
[[ -z ${KDE_MIN_VER} ]] || version_is_at_least ${KDE_MIN_VER}
s_v || continue
s_s=${s_s} ${s_p}:${s_v}
done
DEPEND=${DEPEND} || ( ${s_s} )
done
| And conditional dependencies would break caching.
Nnnope. If you modify an eclass it forces a cache regen for packages
using said eclass (except possibly if you're using an overlay, but
that's a separate issue...).
--
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 18:44, Ciaran McCreesh wrote: Can you prove it, for the allow USE and version cycling case? (Hint: O.k, let m treat you as a the hot potato that you're Ciaran: - We speak about ebuilds, which are installed and need to be reinstalled. There is no version cycling (or I do not get what you're after, please explain in that case). - Changed use flags will be processed by the normal dependency calculation of the ebuilds to be rebuilt which may lead to additional dependencies or blockers. It could also be that some ebuilds are installed, which do not exist in the repository anymore. you may find the PCP somewhat useful...) PCP - pretty colored potato? I don't know the abbreviation. Please explain it and whatelse I miss in your eyes. Carsten pgpzCSIWdJLT9.pgp Description: PGP signature
Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing
On Tuesday 27 December 2005 18:55, Peter wrote: Thanks all for the feedback. It's important to realize that userland in this case is under 1 minute compile time. One of the modules, glx, doesn't even get compiled. A poster on this thread noted that glx took 14 seconds -- it just copies closed source libraries. Here it takes a time variable between 30 seconds and 2 minutes depending on the load of the machine. It's always things that gets copied, overwriting the extended attributes for pax (well I think pax counts only the executables, I'm wondering if paxctl would work on .so files, but I don't think so). For sure, -xconfig and -settings are not going to be as simple to merge into the single ebuild for the paxctl thing above at least, not counting that many people (included me) don't really need -settings or -xconfig, and just use the default. Current situation seems to me one of the most clean possible, way simpler than using nvidia's manual installation, and for what I've seen with users, it's not _so_ difficult to understand. Here, the intent is to simplify things, remove steps and ebuilds, and make it more user friendly and require less interaction. I already said that FreeBSD and Linux modules have _nothing_ in common and merging all in one ebuild is going to give me an headache to fix it. I'm not going to drop the FreeBSD support tho. -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp6fvwC5ORpd.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tuesday 27 December 2005 18:59, Ciaran McCreesh wrote: Nnnope. If you modify an eclass it forces a cache regen for packages using said eclass (except possibly if you're using an overlay, but that's a separate issue...). You're trying to solve something which is already solved, but this has nothing to do with our problem. The question is not listen the possible valid KDE versions or a change of the eclass, but the need to know actual used KDE version. You'd need to call e.g. kde-config to get it. And this breaks caching. Carsten pgpmtt63wzs1W.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, 27 Dec 2005 19:27:01 +0100 Carsten Lohrke [EMAIL PROTECTED] wrote: | - We speak about ebuilds, which are installed and need to be | reinstalled. There is no version cycling (or I do not get what you're | after, please explain in that case). foo-1.0: DEPEND==foo-2.0 foo-2.0: DEPEND= foo-3.0: DEPEND==foo-1.0 bar-1.0: DEPEND==foo-1.0 baz-1.0: DEPEND==foo-2.0 bar moo-1.0: DEPEND==foo-3.0 baz # emerge moo -pv One solution for this particular case, assuming I didn't get confused and screw it up: [n] foo-2.0 [d] foo-1.0 [n] bar-1.0 [u] foo-2.0 [n] baz-1.0 [d] foo-1.0 [u] foo-3.0 [n] moo-1.0 Notice how we have to repeatedly upgrade and downgrade foo. | - Changed use flags will be processed by the normal dependency | calculation of the ebuilds to be rebuilt which may lead to additional | dependencies or blockers. It could also be that some ebuilds are | installed, which do not exist in the repository anymore. Again, you can get cycling. This one's even nastier, if you have various packages that DEPEND upon something built with [foo], various packages that DEPEND upon something built with [!foo] and upgrade / downgrade cycling on that package... | you may find the PCP somewhat useful...) | | PCP - pretty colored potato? I don't know the abbreviation. Please | explain it and whatelse I miss in your eyes. Post's Correspondence Problem. It's a proven general case unsolvable problem that looks suspiciously similar to the general case dependency resolution with cycling situation... -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke [EMAIL PROTECTED] wrote: | On Tuesday 27 December 2005 18:59, Ciaran McCreesh wrote: | Nnnope. If you modify an eclass it forces a cache regen for packages | using said eclass (except possibly if you're using an overlay, but | that's a separate issue...). | | You're trying to solve something which is already solved, but this | has nothing to do with our problem. The question is not listen the | possible valid KDE versions or a change of the eclass, but the need | to know actual used KDE version. You'd need to call e.g. kde-config | to get it. And this breaks caching. So you RDEPEND upon the version of KDE against which you were built, and use the || ( ) flattening feature that's already been proposed. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] New Developer: codergeek42
Danny van Dyk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, please help me to welcome Peter Gordon aka codergeek42, our latest addition to the ranks of Gentoo Developers. And someone please explain to him how to secure his bum in SpanKY's immediate vicinity ;-) Welcome codergeek! I'm his mentor so everyone wish him *lots* of luck, he's gonna need it. LOL -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world
On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote: Currently there are quite a few ebuilds in the tree that execute dodoc or dohtml for files that do not exist. I think it would be nice to have ebuilds die if this is the case. To not break current ebuilds this would only happen with FEATURES=stricter. This is what I currently do in my bashrc. Obviously when integreted to portage one can use helper functions like hasq which are not available in bashrc. Well some people opposed this idea so what do everyone think about making portage output stuff like this to a qa-warnings (or whatever) file that developers can use? This would have the added benefit that users would not normally see this stuff and report stuff so easily but developers would still have easy access to it. Portage could even output a header to this file saying not to file bug reports unless you know what you are doing? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world
On Tuesday 27 December 2005 14:41, Petteri Räty wrote: On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote: Currently there are quite a few ebuilds in the tree that execute dodoc or dohtml for files that do not exist. I think it would be nice to have ebuilds die if this is the case. To not break current ebuilds this would only happen with FEATURES=stricter. This is what I currently do in my bashrc. Obviously when integreted to portage one can use helper functions like hasq which are not available in bashrc. Well some people opposed this idea so what do everyone think about making portage output stuff like this to a qa-warnings (or whatever) file that developers can use? This would have the added benefit that users would not normally see this stuff and report stuff so easily but developers would still have easy access to it. Portage could even output a header to this file saying not to file bug reports unless you know what you are doing? if we start hiding the output like that then most people will ignore them -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world
On Tue, 2005-12-27 at 21:41 +0200, Petteri Räty wrote: On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote: Currently there are quite a few ebuilds in the tree that execute dodoc or dohtml for files that do not exist. I think it would be nice to have ebuilds die if this is the case. To not break current ebuilds this would only happen with FEATURES=stricter. This is what I currently do in my bashrc. Obviously when integreted to portage one can use helper functions like hasq which are not available in bashrc. Well some people opposed this idea so what do everyone think about making portage output stuff like this to a qa-warnings (or whatever) file that developers can use? This would have the added benefit that users would not normally see this stuff and report stuff so easily but developers would still have easy access to it. Portage could even output a header to this file saying not to file bug reports unless you know what you are doing? I see the point about not showing all the QA stuff to the 'regluar' user. Maybe only show this info on screen with --verbose set. As for the QA-warnings file, how does this differ from parsing the files in PORTLOG_DIR? Later Days, -Lares -- Lares Moreau [EMAIL PROTECTED] | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world
Lares Moreau wrote: On Tue, 2005-12-27 at 21:41 +0200, Petteri Räty wrote: On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote: Currently there are quite a few ebuilds in the tree that execute dodoc or dohtml for files that do not exist. I think it would be nice to have ebuilds die if this is the case. To not break current ebuilds this would only happen with FEATURES=stricter. This is what I currently do in my bashrc. Obviously when integreted to portage one can use helper functions like hasq which are not available in bashrc. Well some people opposed this idea so what do everyone think about making portage output stuff like this to a qa-warnings (or whatever) file that developers can use? This would have the added benefit that users would not normally see this stuff and report stuff so easily but developers would still have easy access to it. Portage could even output a header to this file saying not to file bug reports unless you know what you are doing? I see the point about not showing all the QA stuff to the 'regluar' user. Maybe only show this info on screen with --verbose set. As for the QA-warnings file, how does this differ from parsing the files in PORTLOG_DIR? Stuff that goes to PORT_LOGDIR is also shown to the user. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world
On Tue, 2005-12-27 at 22:10 +0200, Petteri Räty wrote: I see the point about not showing all the QA stuff to the 'regluar' user. Maybe only show this info on screen with --verbose set. As for the QA-warnings file, how does this differ from parsing the files in PORTLOG_DIR? Stuff that goes to PORT_LOGDIR is also shown to the user. Could it be split? Have the QA stuff shown on screen only when --verbose is set, but have all the information written to PORT_LOGDIR no matter the flag. In my experience most users don't use PORT_LOGDIR in the first place. People who want the information define PORT_LOGDIR and have the information. Why add files containing duplicate information? -Lares -- Lares Moreau [EMAIL PROTECTED] | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
Ciaran McCreesh wrote: On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer [EMAIL PROTECTED] wrote: | That will increase the sync time for all of our users - can we please | keep this info out of the sync-tree? Learn to use the rsync exclude list. FAQ: http://forums.gentoo.org/viewtopic-t-356536-highlight-rsync+exclude.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] checdeps.rb for getting deps out of elf files
Mike Frysinger wrote: On Fri, Dec 23, 2005 at 01:09:08PM +0200, Petteri R??ty wrote: Basically it does ldd on all the elf files in a package and then checks to which packages those libraries belong. ldd is garbage for this purpose use `readelf -d ELF | grep NEEDED` or just `scanelf -n ELF` -mike Adjusted to using scanelf: http://dev.gentoo.org/~betelgeuse/scripts/checkdeps.rb This has the side affect that the library location code is not used until I code or take the logic from glibc from example. [EMAIL PROTECTED] ~/bin $ checkdeps.rb subversion dev-libs/apr dev-libs/apr-util dev-libs/expat dev-libs/openssl dev-util/subversion net-misc/neon sys-libs/db || app-office/openoffice-bin sys-libs/gdbm sys-libs/glibc sys-libs/zlib Old ldd using version: http://dev.gentoo.org/~betelgeuse/scripts/checkdepsldd.rb Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unified nVidia Driver Ebuild ready for testing
Peter wrote: To Gentoo nVidia users: We are in the process of developing and testing a unified nVidia driver ebuild. When implemented, it will replace the nvidia-kernel, nvidia-glx, and nvidia-settings ebuilds. It will also add the utility nvidia-xconfig. We would like your help in evaluating, testing, and commenting on this approach. Please locate the latest nvidia ebuild at: http://bugs.gentoo.org/show_bug.cgi?id=116085 The download package for the new ebuild is at: http://bugs.gentoo.org/attachment.cgi?id=75389 This is the very latest nVidia 8178 driver. Please be sure and review the nVidia changelog and readme. If your fonts are abnormally small, see Appendix Y and the nVidia forums for info on DPI. See http://www.nvnews.net/vbulletin/forumdisplay.php?s=forumid=14 for specific news and info about the nVidia drivers for linux. Since this is a developmental ebuild, it is NOT currently in portage. If you would like to try it out, please follow these simple instructions: 1) Untar the file into /usr/local/portage/x11-drivers (if your portage overlay is in a different location, adjust accordingly). 2) exit all window managers 3) unmerge nvidia-kernel, nvidia-glx, and nvidia-settings (emerge -C .) This ebuild will NOT install if any other nVidia ebuilds are installed. 4) edit /etc/portage/package.keywords and add x11-drivers/nvidia-drivers ~x86 (or ~amd64). Other arches are not supported. Sorry. 5) emerge nvidia-drivers. This will load the kernel module, glx support, nvidia- settings and -xconfig all in one swoop. NOTE: Modular X support is not yet implemented. If you have comments, notice a bug, or if you have suggestions for improvement, PLEASE post to the existing bug report: http://bugs.gentoo.org/show_bug.cgi?id=116085. Please DO NOT report bugs about the upstream driver. If the driver does not work, then see the nVidia news forum. We hope you will find this approach a more streamlined and easy implementation for nVidia. Thanks for your participation and feedback. Peter Hyman on behalf of the nVidia devs. In my opinion if you want to build monolitic ebuild in system like gentoo where everything is going to be modular you should try some local USE flags for example monolitic to install all the stuff you are puting into it and of cours flags for every part which could be istalled independly. As a common user i need only nvidia-kernel and its dependency nvidia-glx to be happy. Greets Pawel Madej -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world
Lares Moreau wrote: On Tue, 2005-12-27 at 22:10 +0200, Petteri Räty wrote: I see the point about not showing all the QA stuff to the 'regluar' user. Maybe only show this info on screen with --verbose set. As for the QA-warnings file, how does this differ from parsing the files in PORTLOG_DIR? Stuff that goes to PORT_LOGDIR is also shown to the user. Could it be split? Have the QA stuff shown on screen only when --verbose is set, but have all the information written to PORT_LOGDIR no matter the flag. That will be difficult to explain as a behaviour, not logical to me. In my experience most users don't use PORT_LOGDIR in the first place. People who want the information define PORT_LOGDIR and have the information. Why add files containing duplicate information? ditto. Imagine a world where every (Gentoo) user is a developer... dream... more! You are right - impossible. However, by bitching about problems, there are some users that decide to check WTF is this warning, in turn they urge devs to fix it (and that is the main point of QA, right?), they report it with their bug reports and so on. In other words, the problem gets _NOTICED_ by everybody. IMHO, leave it as it is now and don't bother. It is not that much of an output, compared to the compile output anyway. I'd prefer even having it red/bold/whatever for easy spotting. And for the future, what about defining something like GENTOO_LEVEL=n00b|user|know_how|master|admin|dev|guru in make.conf? And act acording to this, but trying to move the user up a level or two most of the time. Kalin. /know_how -master --dev/ -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world
On Wed, 2005-12-28 at 10:34 +0900, Kalin KOZHUHAROV wrote: what about defining something like GENTOO_LEVEL=n00b|user|know_how|master|admin|dev|guru in make.conf? And act acording to this, but trying to move the user up a level or two most of the time. This is what happens anyway, but it is called FEATURES :) -Lares -- Lares Moreau [EMAIL PROTECTED] | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world
Lares Moreau wrote: On Wed, 2005-12-28 at 10:34 +0900, Kalin KOZHUHAROV wrote: what about defining something like GENTOO_LEVEL=n00b|user|know_how|master|admin|dev|guru in make.conf? And act acording to this, but trying to move the user up a level or two most of the time. This is what happens anyway, but it is called FEATURES :) From `man make.conf` FEATURES = sandbox ccache autoaddcvs Defines actions portage takes by default. These options should not be changed by anyone but developers and/or maintainers. 'sandbox' is an important part of FEATURES and should not be disabled by default. This is an incremental variable. So I guess I am close to developers and/or maintainers as I change that on day 0 on any Gentoo box I install :-) s/'sandbox' is an important part of FEATURES and should not be disabled by default/ 'sandbox' is an important part of FEATURES and should not be disabled by default (but disabled on `emerge perl`)/g or die; I still think, GENTOO_LEVEL is a better one though. Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: codergeek42
On Tue, 2005-12-27 at 14:25 -0500, Curtis Napier wrote: Welcome codergeek! I'm his mentor so everyone wish him *lots* of luck, he's gonna need it. LOL Jeez thanks for the wonderful encouragement, Curtis. Ha ha. :-P -- Peter Gordon (codergeek42) GnuPG Public Key: 0xDA3634D7 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world
snip However, by bitching about problems, there are some users that decide to check WTF is this warning, in turn they urge devs to fix it (and that is the main point of QA, right?), they report it with their bug reports and so on. In other words, the problem gets _NOTICED_ by everybody. IMHO, leave it as it is now and don't bother. It is not that much of an output, compared to the compile output anyway. I'd prefer even having it red/bold/whatever for easy spotting. I agree - hiding QA stuff just makes it be there longer. The more people notice it, the more likely it is to get fixed, which is the best way of making it not show up (IMHO anyway). And for the future, what about defining something like GENTOO_LEVEL=n00b|user|know_how|master|admin|dev|guru in make.conf? And act acording to this, but trying to move the user up a level or two most of the time. I don't think many people would enjoy having a system that made it its business to tell them what they should know about. Different people have different learning rates and learn in different ways about different things. People who want to learn to solve their own problems will; those who don't aren't likely to want their computer to try to force them to (although I'll admit that Gentoo doesn't exactly attract loads of the latter type). -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Optimizing performance
Paul de Vrieze posted [EMAIL PROTECTED], excerpted below, on Tue, 27 Dec 2005 16:38:21 +0100: On Saturday 24 December 2005 00:52, Diego 'Flameeyes' Pettenò wrote: On Friday 23 December 2005 18:35, Paul de Vrieze wrote: Just to add. This is not so much related to debugging information in the library files (what gdb can use). That information never makes it from disk so is not that much of a speed issue (esp. if it is split out). Actually, if the binaries are not stripped, they consume more memory. With splitdebug the issue is unseen (I'm happily using it with -g3 for everything now..) Debug info shouldn't be loaded into memory. Or is it? I agree though that splitting them out is probably better for memory use. From what I've read, binary files are read into memory as a file, before being having their elements loaded at specific addresses by ldd. Unsplit debug information at minimum, then, increases the i/o load, requiring more data be read into memory initially, even if it's immediately thrown out again, when it's not actually loaded anywhere. In practice, it would at least remain in cache rather longer, thereby taking up space that could be used to cache data that might actually be used, not to mention forcing other potentially useful data out of cache on initial read into cache. Debug information split into entirely separate files, then, shouldn't affect performance at all over stripped, and be rather better performing than debug information stored in the same file. That's only what I've read. I have no special knowledge on the subject, and if what I read was incorrect, than so is the above. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-portage-dev] [RFC] Making --quiet really mean it
Attached is the initial framework to make portage stfu. pym/portage_util.py - (wrappers the writemsg function) By default writemsg() has noiselevel handling, but it sends everything to stderr. We wrapper it in order to pass an additional file descriptor so we can use stdout vs stderr. pym/portage.py - (use writemsg_stdout function) To take advantage of the newy created writemsg_stdout() function we swap it in place of alot of the default print foo statements that are in portage's merge/unmerging phases. Shifts env var PORTAGE_QUIET to doebuild where it can be used by ebuild.sh. bin/emerge - (-q/--quiet trigger) Sets noiselimit to -1 and uses writemsg_stdout in a few places. bin/ebuild.sh - (ulgy not attached) bin/prepstrip - (ulgy not attached) -- solar [EMAIL PROTECTED] Gentoo Linux --- pym/portage_util.py (revision 2485) +++ pym/portage_util.py (working copy) @@ -6,13 +6,20 @@ import sys,string,shlex,os.path noiselimit = 0 -def writemsg(mystr,noiselevel=0): + +def writemsg(mystr,noiselevel=0,fd=None): Prints out warning and debug messages based on the noiselimit setting global noiselimit + if fd is None: + fd = sys.stderr if noiselevel = noiselimit: - sys.stderr.write(mystr) - sys.stderr.flush() + fd.write(mystr) + fd.flush() +def writemsg_stdout(mystr,noiselevel=0): + Prints messages stdout based on the noiselimit setting + writemsg(mystr, noiselevel=noiselevel, fd=sys.stdout) + def grabfile(myfilename, compat_level=0, recursive=0): This function grabs the lines in a file, normalizes whitespace and returns lines in a list; if a line begins with a #, it is ignored, as are empty lines Index: pym/portage.py === --- pym/portage.py (revision 2485) +++ pym/portage.py (working copy) @@ -90,7 +90,7 @@ import portage_util from portage_util import grab_multiple, grabdict, grabdict_package, grabfile, grabfile_package, \ grabints, map_dictlist_vals, pickle_read, pickle_write, stack_dictlist, stack_dicts, stack_lists, \ - unique_array, varexpand, writedict, writeints, writemsg, getconfig, dump_traceback + unique_array, varexpand, writedict, writeints, writemsg, getconfig, dump_traceback, writemsg_stdout import portage_exception import portage_gpg import portage_locks @@ -2293,7 +2293,7 @@ print return 0 else: - print checksums +note+ ;-),x + writemsg_stdout( checksums +note+ ;-) %s\n % x) return 1 @@ -2493,6 +2493,9 @@ mysettings[PV] = mysplit[1] mysettings[PR] = mysplit[2] + if portage_util.noiselimit 0: + mysettings[PORTAGE_QUIET] = 1 + if mydo != depend: try: mysettings[INHERITED], mysettings[RESTRICT] = db[root][tree].dbapi.aux_get( \ @@ -5704,7 +5707,7 @@ #we skip this if we're dealing with a symlink #because os.path.exists() will operate on the #link target rather than the link itself. - print --- !found +str(pkgfiles[obj][0]), obj + writemsg_stdout(--- !found +str(pkgfiles[obj][0])+ %s\n % obj) continue # next line includes a tweak to protect modules from being unmerged, # but we don't protect modules from being overwritten if they are @@ -5712,56 +5715,56 @@ # functionality for /lib/modules. For portage-ng both capabilities # should be able to be independently specified. if self.isprotected(obj) or ((len(obj) len(modprotect)) and (obj[0:len(modprotect)]==modprotect)): - print --- cfgpro +str(pkgfiles[obj][0]), obj + writemsg_stdout(--- cfgpro %s %s\n % (pkgfiles[obj][0], obj)) continue lstatobj=os.lstat(obj) lmtime=str(lstatobj[stat.ST_MTIME]) if (pkgfiles[obj][0] not in (dir,fif,dev)) and (lmtime != pkgfiles[obj][1]): - print --- !mtime, pkgfiles[obj][0], obj + writemsg_stdout(--- !mtime %s %s\n % (pkgfiles[obj][0], obj)) continue if pkgfiles[obj][0]==dir: if not os.path.isdir(obj): - print --- !dir ,dir, obj + writemsg_stdout(--- !dir %s %s\n % (dir, obj)) continue mydirs.append(obj) elif pkgfiles[obj][0]==sym: if not os.path.islink(obj): - print --- !sym ,sym, obj + writemsg_stdout(--- !sym %s %s\n % (sym, obj)) continue try: os.unlink(obj) - print,sym,obj + writemsg_stdout( %s %s\n % (sym,obj)) except (OSError,IOError),e: - print !!! ,sym,obj + writemsg_stdout(!!! %s %s\n % (sym,obj)) elif pkgfiles[obj][0]==obj: if not os.path.isfile(obj): - print --- !obj ,obj, obj + writemsg_stdout(--- !obj %s %s\n % (obj, obj)) continue mymd5=portage_checksum.perform_md5(obj, calc_prelink=1) # string.lower is needed because db entries used to be in upper-case. The # string.lower allows for backwards compatibility. if mymd5 != string.lower(pkgfiles[obj][2]): - print --- !md5 ,obj, obj + writemsg_stdout(--- !md5 %s %s\n % (obj, obj)) continue
