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: 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] "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: [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 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] 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] Re: [gentoo-core] crap use flags in the profiles
> On Mon, 2005-08-29 at 20:10 +0200, Patrick Lauer wrote: >> On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote: >> > As I understood it, they were implemented to reduce the amount of work >> > necessary in maintaining them. As it was back then, it required >> changes >> > to an extremely large number of profiles every time a change was made >> to >> > the default USE flags. > >> Just a crazy idea - why not create a package containing some profiles? >> You can use the default profile, and if you want a different profile, >> "emerge portage-profiles" or whatever it is called and use that. I guess >> I've missed something obvious here? > > How exactly would updating a ton of profiles, making a tarball of them, > uploading the new tarball, waiting for it to hit the mirrors, then > updating the ebuild in portage be easier to maintain than just > maintaining the profiles directly in the tree? > >> > I honestly don't think it would be a good idea >> > to forget the lessons of the past and start bloating the profiles with >> > tons of "desktop" and "server" profiles, among anything else people >> > would want. After all, as soon as we did a "desktop" profile, then we >> > would have requests for "gnome" and "kde" sub-profiles. > >> which are not much work if kde = desktop -gtk -gnome +kde > > Once there is multiple inheritance, I see this being easier. I still > think it is going to be a waste of time for us to maintain them, > however. Especially since *NO MEDIA* will be built against *any* of > them except the default. > >> > As I stated earlier, it's easier to not provide *any* than to try to >> > provide all of the ones that will inevitably be requested as soon as >> we >> > start adding them. >> Or provide them in an extra ebuild that throws lots of warnings so that >> any users that don't read the warnings can be RESOLVED WONTFIXed? > > You're more than welcome to do this. *I* would just WONTFIX it anyway > and not add *any* superfluous profiles just to appease some lazy users. > The current profiles are built to be used *as is* for doing GRP > installations. If the user doesn't like a flag or two, then they change > it themselves. We don't need to get into the business of determining > what should and should not be enabled on user's systems because we would > *never* be able to make people happy. > I think Brian mentioned /etc/portage/profile and other fun portage tricks to mess with the default profile. If you think the profile shouldn't be changed then don't make it a mutable option. If you think that bugs where people fubared their profile are a problem then write a tool to print out that information and have the user present it to you when they file the bug. As far as maintainability, you could always make a profile outside of the default-linux tree ( default-gentoo/* ) and construct the smaller/faster/better profiles there. That means anyone that wants to customize can change the symlink and you ( releng ) still get your pristine release profiles ( which IMHO is a silly notion, but I don't manage your bugs, so whichever way you like ;) ). Going on that notion, you could also do default-linux/x86/2005.1/release or whatnot if you want to maintain that as well. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use flags in both use.defaults and make.defaults
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > All, > > since there has been a lot of discussion lately about default use flags, > I looked at the profiles and found the following: > > All of these use flags are in base/use.defaults. As I understand it, if > the package listed with the flag in this file is installed on the > system, the flag is automatically turned on. If that's true, why are > they also listed in default-linux/x86/make.defaults? Wouldn't it be Obviously because default-linux/x86 is the only profile worth looking at :) Try looking at the default use flags for say, the s390 profile :) I still agree with your point "stuff in both places" but I think it's more of an "it's there because it doesn't work right otherwise" rather than some sort of USE flag conspiracy ;) > better to have them turned on automatically when the package that > installs them is merged? > > arts cups eds emboss foomaticdb gnome kde nls opengl perl python tcpd X > > I also found the following flags in both places. The difference here is > that the packages listed with these in base/use.defaults are libraries. > Again, do these need to be listed in both places? I would think these > don't need to be in base/use.defaults if we are going to allow the user > to turn on/off support for them. > > alsa berkdb gdbm gif gpm gstreamer gtk imlib libwww mad mikmod motif > ncurses ogg pam pdflib png qt readline sdl ssl vorbis zlib > > any thoughts? I believe in the current implementation of use.defaults the use flag is not propagated backwards through the buildplan. So you "USE="-everything in /etc/make.profile/make.defaults" emerge xmms alsa" and xmms won't have the ALSA use flag set, because alsa was merged second. I'd have to double check with Jason or Brian though..haven't talked about implentation of use.defaults in a while *pokes*. > William > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFDEhJKblQW9DDEZTgRAlzaAKCc+sLiwCO6HCE+UUnOvrnhY7f4kwCgoqkx > Xzz8eV610fWxhZ6ccQ+adZ4= > =HC0T > -END PGP SIGNATURE- > -- > gentoo-dev@gentoo.org mailing list > -- 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. :) You are the weakest link, goodbye! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] flat profiles punted (and a note about x86/OpenBSD)
Mike Frysinger wrote: On Monday 15 August 2005 01:37 am, Alec Warner wrote: Mike Frysinger wrote: as previously mentioned, i've punted all the flat profiles since the 2005.1 release since it seems like no one is using x86-obsd, can their team (if there is one) please create the proper cascading profiles for those of you looking to upgrade older portage versions, profiles/obsolete// exists for you -mike If you haven't done so already, might want to fire off a mail to -user as well. someone should forward my mail then ... i stopped subscribing to that list long ago :/ -mike as did I, but I figured a copy should get there one way or another, preferably not 10 copies though :) -- gentoo-dev@gentoo.org mailing list
