Re: [gentoo-portage-dev] .53, .54 and beyond...
Jason Stubbs wrote: On Wednesday 07 December 2005 01:01, Marius Mauch wrote: On Tue, 6 Dec 2005 23:19:38 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: If there's no solid opposition, Saturday I will put current trunk into ~arch as 2.1_beta20051210. Well, I've already stated several times that IMO using a 2.1 branch is wrong (use 2.2 instead), but if I'm overvoted, so it shall be. As Brian stated, 2.2 being a version higher than 2.1 will have all the same expectations placed on it. From what I can see, 1% of users know anything about 2.1 so 99% would be wondering why there was a jump from 2.0 to 2.2. Do you have anything against 2.1 other than fearing that people will expect more from it than it will turn out to be? As for stable users? If arch teams are willing to selectively choose what fixes they want backported to stable (when they're not prepared to move the ~arch version into stable) things will go much smoother. Of course, it would still be our responsibility to get those things backported and assert some confidence that it is working. However, once the requested fixes are backported all that needs to be done is put out the patched stable version with ~arch keywords and then leave it up to the arch teams again. Except for the slight extra burden on (which I believe many would actually find to be a blessing), it should be a win-win situation. Just in case you forgot and also for general reference, when I asked the arch teams about the portage keywording policy a few months ago (wether we should stable even without testing on all archs or to delegate that to arch teams) everyone seemed to be happy with the old policy, at least nobody voted for a change. As portage doesn't really have any arch specific code and a rather short dep list IMO it also doesn't yield any real benefit other than more people testing it (which is of course always a good thing). Really, the bottom line is that regardless of what the response was when you asked about portage keywording, if all the arch teams had confidence in what we thought 2.0.53 would have been stable a long time ago. On the surface the only benefit is extra testing (which has already payed off) but it also allows others to take an active hand in the quality of portage as well as strengthens the communication channels. It's these auxillary benefits as well as the benefit of being able to focus on trunk more (which will yield faster rollout of features) that make me think it is the best way to go. On Wednesday 07 December 2005 01:21, Alec Warner wrote: I spoke with Brian today ( no clue if he will be sending mail or not ) but he stressed that he would like the cache rewrite in ~arch. Any reason why you're speaking on his behalf? From what I understood he was busy/moving IRL and didn't have time to catch up on his mail, so I told him I would send something expressing what he said when we spoke on IRC; he didn't explicitly tell me to do so, but I told him I was going to. I would prefer that it be in .54, the code itself is old, 6+ months. It is a straight backport from the 2.1 branch (the dead one) and the interface code to make it fit with 2.0 is small compared to the patch size ( Brian estimated 100-150 lines ). These are all reasons that I myself have given already. I don't have a problem with releasing 2 ebuilds, one with the patch and one without ( or a use flag ) although the question that raises is will the cache rewrite actually end up in .54 final, or will it be put off :) This, I do have a problem with. You're essentially suggesting that three lines be maintained rather than the current two. I can't tell if you followed what I said in my last email so I'll reiterate. Trunk will go into ~arch on Saturday. 2.0.54 will go out (also in ~arch) two weeks after that with the two fixes and include the cache rewrite based on the opinion of a broad range of users (rather than just the noise makers). SHA1 will of course also go in based on how it is voted. Bah, for some reason I kept thinking that the rewrite wasn't in trunk, but as I look in svn now I see it there; my apologies :/ The detailed explanation looks good to me ;) -Alec Warner (Antarus) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-dev] Around 425 non-existent packages in p.mask?
Luis F. Araujo wrote: Hello everyone, A few days ago i glanced over package.mask , and i was surprised about how many non-existent ebuild/packages entries are there. So, i wrote a script to try to get a list of those orphaned entries, and it looks like there are more than 400 packages/ebuilds which are still listed in p.m but that don't exist in the tree anymore. (A bunch of them from the KDE herd btw) *Please* take a look at http://dev.gentoo.org/~araujo/old_package.mask , for the list of these non-existent ebuilds/packages, in case you have forgotten something in there. I'd like if every person takes care of their own entries if possible. If not, i *personally* could go slowly removing the entries, along with other people willing to help, or any other _better_ suggestion to deal with this? I *of course* haven't checked all of the entry generated by the script manually , so there might probably exist packages which are indeed correct, so please re-check before doing something. I also noticed (slight detail) that there are a couple of recent entries at the bottom of this file, isn't the policy to have new entries added at the top? , is there any special reason for this? Ok, that's all for now! Looks like something that could be added to the list of unstable ebuilds deal that also gets sent here, simple to script... ;) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Commercial software in portage
Chris Gianelloni wrote: On Thu, 2005-09-22 at 15:29 -0500, Brian Harring wrote: Alternatives/better approaches I'd be open to, although I'll admit up front I think what you're attempting needs to be pkg specific, which implies DESCRIPTION in the ebuild (to me at least). Snipping pretty much everything since I *really* don't care. I'm just dumping this idea. I was proposing it because of a conversation with a user where we thought it would be a good idea to give the user some way of knowing that a package requires some additional purchased (or otherwise obtained) portion that is not a distfile/tarball. Anyway, you seem to have done a good job of convincing me of whatever it is you think you've convinced me of, but the truth is I just didn't care enough to bother getting into some pointless pissing match over something that I didn't feel very strongly about in the first place. Basically, you win by default of me just not caring enough to argue anymore. A. The above is kind of sad in terms of the outcome, I'm sorry more people didn't jive with your idea, but there is no need to cry about it. B. Whats wrong with stuffing it into metadata.xml and modifying p.g.o to pull the extra data out? It certainly isn't that complicated. Or just modify the DESCRIPTION field. Doom3 - DESCRIPTION = A popular first person shooter. This game requires a license key to play. Simple no? -Alec Warner -- gentoo-dev@gentoo.org mailing list
Re: Two-level USE-flag system VAR: [gentoo-dev] USE=minimal for kernel sources
Tom Fredrik Blenning Klaussen wrote: The average gentoo users are not stupid. Many people would not agree with that statement ;) come so far as to adjust something beyond the most basic USE flags at all, you're probably advanced enough to deciphre such a message. (It would be nice to have some knowledge of who the average gentoo user is though.) Now as for the USE flag system. It has actually become so big that it's difficult to use it effectively. There is a USE flag group GLEP that is being implemented...sometime ;) I don't think masking USE flags has come up...*pokes portage people* Also might want to submit the ebuild to breakmygentoo or some other overlay. I'll consider it, but as mentioned above it's really a change to an eclass. You can put eclasses in the overlay as well IIRC. -Alec Warner (antarus) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] C++ herd proposal
Mark Loeser wrote: Paul de Vrieze wrote: I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. This isn't for what the package is written in, but more for what the package is for. If the package is a utility for use when doing coding with C++, like the ones I listed, then I think it should be in dev-cpp. That's what the metadata for the category describes it to be. Mark Once again I'd like to point out that organizing packages in the tree by category is a stupid idea for this very reason. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Portability eclass
Diego 'Flameeyes' Pettenò wrote: On Friday 16 September 2005 19:28, Mike Frysinger wrote: current stable does yes, but ive started adding customizable compression to trunk Okay, then *that* is a problem :P Suggestion how to fix it? You are going to have to ask portage what it used via a PortageAPI call, I'd gather. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] USE=minimal for kernel sources
Greg KH wrote: On Thu, Sep 08, 2005 at 10:49:04PM +0100, twofourtysix wrote: On 05/09/05, Petteri R?ty [EMAIL PROTECTED] wrote: I have a couple of old machines I maintain and emerging and unmerging kernel sources take a while because there are so many files. Also one set of gentoo sources takes about 230MB of disk space. By removing stuff not belonging to x86 I was able to succesfully run make with 58MB/230MB removed. The stuff I removed: arch/* except i386 and x86_64 include/asm-* expect asm-generic, asm-i386 and asm-x86_64 Is this safe? No it isn't. Please don't try to do this, it's not worth it. If disk space is limited, just build on one box, and install the kernel to the other one. IMHO it is, but not as a USE flag (it will never be stable enough without upstream support) but I think many would find the functionality useful in a script. I know I would. If it works most of the time and saves space, there is no reason not trim things. If it breaks, you immediately revert to a normal build. Or, put the kernel source on a cd, and build off of it (putting the objects on your local disk.) This lets you only use the local disk for your built objects. thanks, greg k-h -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
Ciaran McCreesh wrote: On Tue, 06 Sep 2005 23:19:43 +0200 Martin Schlemmer [EMAIL PROTECTED] wrote: | What about !arch or something (to connect with the one reply to the | summary thread) to really indicate unstable on that arch? Should | cover those things that sorda work on the arch, but you rather want | developers or experienced users that can patch bugs to look at it ... Those go in per-profile package.masks. It's more flexible than a keyword. Speaking of flexabilty, are there tools out there to perform look-ups into p.masks to figure out why things are masked? There seems to be a standard format to the file although the part at the beginning kind of throws off a simpler regex. Flexability is good sure, but I would think a developer needs to easily determine why something is pmasked ( broken, testing, security, removal, etc... ) and keywords do that a lot faster than searching through a pmask file. If the searching is sped up via a better format and a searching tool then all the better, yes? The other thing being a keyword is right in the ebuild where pmask status is in package.mask. I am not for putting pmask status in the ebuild though, as that is not necessary, once again a tool problem :/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
Ciaran McCreesh wrote: On Tue, 06 Sep 2005 17:41:35 -0400 warnera6 [EMAIL PROTECTED] wrote: | Speaking of flexabilty, are there tools out there to perform look-ups | into p.masks to figure out why things are masked? emerge -pv emerge -pv would be a cludge for what many are after. If I want to say, figure out how many mediawiki versions are pmasked; emerge -pv is a crappy way to go about it. I will look into taking that code and put it in another, more flexable script ;) -Alec Warner -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
Jon Portnoy wrote: On Wed, Aug 17, 2005 at 03:45:49PM +0200, Henrik Brix Andersen wrote: not everyone uses echangelog [snip] it does, but not everyone uses echangelog Why not? Because I don't want to. :) badjokeYou are the weakest link, goodbye!/badjoke -- gentoo-dev@gentoo.org mailing list
