[gentoo-dev] Re: Jeeves IRC replacement now alive - Willikins
"Robin H. Johnson" <[EMAIL PROTECTED]> said: > Getting the bot out there > - > If you would like to have the new bot in your #gentoo-* channel, would > each channel founder/leader please respond to this thread, stating the > channel name, and that they are the contact for any problems/troubles. #gentoo-ir ( I am one of the channel operators ) Get your preferred Email name! Now you can @ymail.com and @rocketmail.com. http://mail.promotions.yahoo.com/newdomains/aa/
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: | Hi everyone, | | Please consider a PROPERTIES=live value that, when set in an ebuild, | will serve to indicate that the ebuild will use some form of "live" | source code that may vary each time that the package is installed. | The intention is for PROPERTIES=live to have a relatively pure and | simple meaning. Therefore, the definition is intentionally more | narrow than the definitions previously suggested for the related | RESTRICT=live [1] and PROPERTIES=live-sources [2] values. In the | future we may add additional (orthogonal) properties to represent | other things like locking [3]. | | Since there is no direct correspondence between what PROPERTIES=live | represents and any existing ebuild metadata (though there is some | limited correspondence with various INHERITED values), addition of | PROPERTIES=live will provide metadata that is useful in at least a | few ways: | | * Make the @live-rebuild package set [4] more accurate. | | * Make repoman's LIVEVCS.stable check more accurate. | | * Add exemptions to repoman's KEYWORDS.missing and KEYWORDS.dropped |checks. Although an exemption to KEYWORDS.missing is in itself already a good progress, imho it would be even better if repoman, pcheck and other QA testing tools complained if there were any keywords set for an ebuild with PROPERTIES="live". | Do the name and definition of this PROPERTIES=live value seem good? | Would anybody like to discuss any changes to the name, definition, | or both? Seems a good idea. Thanks for all the work on the good proposals you've submitted lately to the dev ml. | [1] | http://archives.gentoo.org/gentoo-dev/msg_164fd8d5d513121ab772509d06a7b27a.xml | [2] | http://archives.gentoo.org/gentoo-dev/msg_187585c5d49b69034183719ff473710d.xml | [3] | http://archives.gentoo.org/gentoo-dev/msg_7b5e4610fe1802149960ae5365bdedce.xml | [4] | http://planet.gentoo.org/developers/zmedico/2008/07/31/live_rebuild_package_set - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiwksAACgkQcAWygvVEyAJHEgCeKrJF4tVLd7etilp9JdbQTyCq BZUAmweZ+nbSVwj+kpeQWJb4MdVUkN15 =+wSW -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
Zac Medico wrote: The intention is for PROPERTIES=live to have a relatively pure and simple meaning. Ok. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
Zac Medico wrote: > Do the name and definition of this PROPERTIES=live value seem good? > Would anybody like to discuss any changes to the name, definition, > or both? ++ -Joe
[gentoo-dev] [RFC] PROPERTIES=live (instead of PROPERTIES=live-sources or RESTRICT=live)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, Please consider a PROPERTIES=live value that, when set in an ebuild, will serve to indicate that the ebuild will use some form of "live" source code that may vary each time that the package is installed. The intention is for PROPERTIES=live to have a relatively pure and simple meaning. Therefore, the definition is intentionally more narrow than the definitions previously suggested for the related RESTRICT=live [1] and PROPERTIES=live-sources [2] values. In the future we may add additional (orthogonal) properties to represent other things like locking [3]. Since there is no direct correspondence between what PROPERTIES=live represents and any existing ebuild metadata (though there is some limited correspondence with various INHERITED values), addition of PROPERTIES=live will provide metadata that is useful in at least a few ways: * Make the @live-rebuild package set [4] more accurate. * Make repoman's LIVEVCS.stable check more accurate. * Add exemptions to repoman's KEYWORDS.missing and KEYWORDS.dropped checks. Do the name and definition of this PROPERTIES=live value seem good? Would anybody like to discuss any changes to the name, definition, or both? [1] http://archives.gentoo.org/gentoo-dev/msg_164fd8d5d513121ab772509d06a7b27a.xml [2] http://archives.gentoo.org/gentoo-dev/msg_187585c5d49b69034183719ff473710d.xml [3] http://archives.gentoo.org/gentoo-dev/msg_7b5e4610fe1802149960ae5365bdedce.xml [4] http://planet.gentoo.org/developers/zmedico/2008/07/31/live_rebuild_package_set - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiwdZ0ACgkQ/ejvha5XGaMlTwCdEqg6mpLAn8r/6JCfaVzQpBaC xMMAn3wGpli8sAuOYLf2Se4NHtrA0mC6 =6Mco -END PGP SIGNATURE-
Re: [gentoo-dev] License Interpretation
Donnie Berkholz wrote: Have you heard of the term "contributory infringement"? It means you're helping someone else break copyright law. Wouldn't somebody need to distribute the software to be in violation of copyright law? If I in legal and fully-licensed manner install a program on my PC, and then I modify that program but don't distribute it, have I violated copyright law? If the end-user doesn't violate copyright, then Gentoo couldn't be guilty of contributory infringement. If I purchase a piece of artwork and then draw over it I haven't violated copyright. If I make 10 copies of the resulting modified art and distribute them then I may have. If I sell a magic marker and print on the box "you can draw all over your expensive artwork" on it I'm not contributing to copyright infringement. If I write on the box "you can draw all over your expensive artwork and sell it on ebay" then I may be contributing to copyright infringement. At least, that is how I see it... :)
[gentoo-dev] Re: Re: Re: Re: [RFC] What features should be included in EAPI 2?
Alec Warner wrote: > At least one has...do you want to vote for each feature? What will it > take to convince you? > It's not up to me, and I've already conceded on IRC that the consensus is against me (just letting others know); that's life *shrug* >>> (The one missing is a src_fetch_extra or somesuch, for use by the scm >>> eclasses. But that wants special handling, and is probably best left to >>> another EAPI...) >>> >> Yes, a defined, configurable API for dealing with any version control >> would be useful, though your minion seemed to argue against it in >> #-portage. I can think of a couple of things that would be more useful to >> end-users: pkg_check for interactive ebuilds (eg license acceptance or >> media access), proper support for cross-compiling, integration of prefix, >> better handling of overlays, and of binpkgs.. >> > > Your comment is arguably about feature prioritization; not about > whether a given feature is necessary. > > If we have two orthogonal features A and B; you can't argue that A is > necessary and B is not because A is more important to work on; the > only thing you have succeeded in doing is arguing that A should be > done first. > My point was that pkg_check has been requested from years ago, and focus (on the ml, not in terms of what gets done on portage) over the last year or so seems to be much more on things which make it easier for devs to work on live ebuilds (not surprising with kde-4) not on stuff which would make the end-user experience easier, which is what would bring more new users (and thus new devs) in. Both are important, but making your users' lives easier means less support burden, which means you get more time to play with shiny new (aka 'broken') code. Further, I think it would be cleaner if the package manager had a defined configuration to deal with any version control system via an eclass, meaning adding a new one would simply be a case of adding the .eclass to the tree and the eclass name to a profile, with no changes at all required in the mangler, beyond support for the base API (which is in any event handled by bash.) Eclass versioning would be nice too. >> In maintenance terms (when looking at the >> lifecycle of an ebuild) I don't see the need, since there is no unpacking >> required from a vcs pull. Once it's made into a normal ebuild, any >> preparation would necessarily require review and might not be needed at >> all. >> >> Call the function what you like (or add a new phase with the hooks) it's >> still logically one point in time. For a live ebuild it's to prepare the >> src, for a normal one to (possibly) unpack and prepare. >> >> src_configure is a logically distinct action which warrants a new phase, >> since the e*conf call in compile makes retrying a long build (without >> having to recompile stuff which doesn't need it) much more difficult; its >> absence prevents full use of make. Prepare does not warrant a new phase >> imo since it should only be run once per compilation instance; anything >> it does can either be done in unpack, or in configure should that be more >> useful. > > src_prepare is a logically distinct action (maybe if we called it > src_patch it would be clearer?) Er no you're fine, I've been thinking of it as src_patch for quite a while now. > Certainly we only want to patch sources once every time we want to > build a package; what if patching is expensive? > Indeed, that was my point above; it only needs to be done once per instance, whereas configure is something that might well be done more than once. How does that change by having it in unpack (which is empty for a live vcs pull in any case)? Also, if you added support for declarative patches, I think you'd soon end up in a similar situation as with unpack, where there simply isn't a need for the ebuild author to write their own in the vast majority of cases. Thing is you'd then be stuck with a new phase and unable to withdraw it, cos it "only took 10 minutes to add." > The point being the same argument that is for src_configure (that it > is expensive and adding it makes ebuilds clearer) could be said for > src_prepare (preparation could be expensive and it makes ebuilds > clearer). > The compelling argument for configure isn't that it's clearer (although it helps): it's that not having it makes it _impossible_ to restart an ebuild which uses the standard configure make cycle, say if the user has turned off collision-protect in order to get OpenOffice to install, or as recently highlighted in #-dev-help, for an ebuild dev to do the same, via FEATURES=noclean ebuild package.ebuild install. Presumably that's the root cause of "confusion over where to put eautoreconf," since putting it in unpack and not compile gets round the issue. > So why again should we not add it? > I have no issue with the function being part of the EAPI; adding it as a _phase_ seems less wise, but like I said, I accept the consensus is against me.
[gentoo-dev] Re: [GLEP 56] metadata.xml status
Doug Goldstein <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 23 Aug 2008 02:47:54 -0400: > Thanks to everyone that converted a package, and a double thanks to > anyone that converted a category. > > GLEP 56 is now done. And thanks for your pushing it, too. =:^) -- 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
