Re: [gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
On Sun, 2008-10-05 at 23:38 -0700, Josh Saddler wrote: > Ulrich Mueller wrote: > >> On Sun, 5 Oct 2008, Robin H Johnson wrote: > > > HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/"; > >>> That would impose needless lookups on subdomains of gentoo.org for > >>> clients trying to load the homepage. > >> http://gentoo.org/package-has-no-homepage/ then. > > > > Couldn't a page be created at this URL, with a notice that the package > > has no real homepage? > > I think that'd take too much time to create and maintain that sort of > thing, especially once old packages are finally removed from the tree. I think the suggestion is to have one generic homepage for all packages without one, not a Gentoo-specific homepage for each project. > Why not just stick in a message that says "This package has no > homepage"? Or "none"? Is there any reason why that couldn't go into the > HOMEPAGE="" variable? Will it break QA tools and other utilities? I guess there are a bunch of tools out there that expect a URL in HOMEPAGE, so providing one will not raise any potential incompatibilities. Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
Ulrich Mueller wrote: >> On Sun, 5 Oct 2008, Robin H Johnson wrote: > HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/"; >>> That would impose needless lookups on subdomains of gentoo.org for >>> clients trying to load the homepage. >> http://gentoo.org/package-has-no-homepage/ then. > > Couldn't a page be created at this URL, with a notice that the package > has no real homepage? > > Ulrich > I think that'd take too much time to create and maintain that sort of thing, especially once old packages are finally removed from the tree. Why not just stick in a message that says "This package has no homepage"? Or "none"? Is there any reason why that couldn't go into the HOMEPAGE="" variable? Will it break QA tools and other utilities? Sure, it'd be nice if there was a homepage, but putting one on gentoo.org implies that we do code fixes and other work, not just hosting the tarballs. Do we really want to *be* upstream for all our orphaned packages? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
> On Sun, 5 Oct 2008, Robin H Johnson wrote: >> > HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/"; >> That would impose needless lookups on subdomains of gentoo.org for >> clients trying to load the homepage. > http://gentoo.org/package-has-no-homepage/ then. Couldn't a page be created at this URL, with a notice that the package has no real homepage? Ulrich
[gentoo-dev] Re: bzr.eclass into Portage
> On Mon, 06 Oct 2008, Jorge Manuel B S Vicetto wrote: > No objections here, just a question. Do you know if the issue with the > lp:// sources has been fixed in bzr? Looks like this is working fine with bzr-1.5, so I'll change the dependency. Ulrich
[gentoo-dev] Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
"Alec Warner" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 05 Oct 2008 19:52:48 -0700: > On Sun, Oct 5, 2008 at 2:55 PM, Thilo Bangert <[EMAIL PROTECTED]> > wrote: >> >> HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/"; >> > That would impose needless lookups on subdomains of gentoo.org for > clients trying to load the homepage. I like Thilo's suggestion -- modified a bit and with the caveat that such a page is actually created, with some generic details explaining that no other homepage could be found and how Gentoo handles such cases (a link to the DMCA/copyright notification page may be helpful as a CYA, this being written assuming Gentoo has one, I've not checked but if we don't it could save a LOT of trouble if someone makes a mistake...), and encouraging anyone who comes across a homepage for such a package to bug it. The modification bit would be to make it a new page on an existing subdomain. Something like this: http://www.gentoo.org/no-homepage.xml It could be made per-project or the like, too, but that makes it more difficult to auto-detect, for anyone/anything that desires to. -- 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
Re: [gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
On Sun, Oct 05, 2008 at 07:52:48PM -0700, Alec Warner wrote: > On Sun, Oct 5, 2008 at 2:55 PM, Thilo Bangert <[EMAIL PROTECTED]> wrote: > > Ciaran McCreesh <[EMAIL PROTECTED]> said: > >> On Sun, 5 Oct 2008 03:44:20 -0700 > >> > >> "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: > >> > Either we need special cases to declare that it no longer has a > >> > homepage, or we need to allow the empty HOMEPAGE. > >> > >> HOMEPAGE="( )" > > > > HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/"; > > > That would impose needless lookups on subdomains of gentoo.org for > clients trying to load the homepage. http://gentoo.org/package-has-no-homepage/ then. > HOMEPAGE="UNKNOWN" seems to work fine and keeps logic fairly simple: > if HOMEPAGE != "UNKNOWN" > do_something_with_HOMEPAGE > ... My reason to support an empty HOMEPAGE variable is that the only existing code that needs changing is repoman. If we change to have some special value that isn't a URL, then all existing code (esp code that doesn't use the Portage APIs) needs to be changed. HOMEPAGE="" # with some comment explaining why -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgppql8XSj3r4.pgp Description: PGP signature
Re: [gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
On Sun, Oct 5, 2008 at 2:55 PM, Thilo Bangert <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh <[EMAIL PROTECTED]> said: >> On Sun, 5 Oct 2008 03:44:20 -0700 >> >> "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: >> > Either we need special cases to declare that it no longer has a >> > homepage, or we need to allow the empty HOMEPAGE. >> >> HOMEPAGE="( )" > > HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/"; > That would impose needless lookups on subdomains of gentoo.org for clients trying to load the homepage. HOMEPAGE="UNKNOWN" seems to work fine and keeps logic fairly simple: if HOMEPAGE != "UNKNOWN" do_something_with_HOMEPAGE ... The metadata API could even wrap this functionality such that packages with no homepages could return nothing (not even UNKNOWN) or throw some kind of error. The only reason I would prefer UNKNOWN to Ciaran's suggestion is that HOMEPAGE="( )" is not obvious to the majority of people (it basically looks like a developer mis-pasted or had some other accident). -Alec
[gentoo-dev] Re: "Slacking" arches - which are stable, which aren't?
On Sun, 05 Oct 2008 20:44:51 -0500 Jeremy Olexa <[EMAIL PROTECTED]> wrote: > I would suggest moving all the "slacking" arches to "experimental" > until there is desire from the dev community (read: manpower) to > support a stable tree again. Until then, it seems pretty pointless to > keep assigning bugs to these arches and they just keep rotting there > because no one gets around to them. > > 2 cents, > -Jeremy ++ $473.57 -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] "Slacking" arches - which are stable, which aren't?
Friedrich Oslage wrote: Am Sonntag, den 05.10.2008, 16:26 -0500 schrieb Steev Klimaszewski: Thoughts? Helps? Afaik we have 3 types of arches: - experimental They are not CCed on stablization bugs and don't do stablizations at all. ~mips, ~sparc-fbsd and ~x86-fbsd - unsupported They are CCed on stablizations bugs, but they are not supported by the Gentoo Linux Security Project. It may take quite long until they actually do the stablization. But I'm also wondering why some of their profiles are marked as "dev". arm, ia64, m68k, sh, s390 - supported Most popular arches, supported by the Gentoo Linux Security Project, they usually do your stablizations in time unless it requires some exotic hardware(the devs/ats don't have) to test. alpha, amd64, hppa, sparc, ppc, ppc64, x86 Sources: - commits logs - http://www.gentoo.org/security/en/vulnerability-policy.xml I would suggest moving all the "slacking" arches to "experimental" until there is desire from the dev community (read: manpower) to support a stable tree again. Until then, it seems pretty pointless to keep assigning bugs to these arches and they just keep rotting there because no one gets around to them. 2 cents, -Jeremy
Re: [gentoo-dev] Re: bzr.eclass into Portage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ulrich. Ulrich Mueller wrote: >> On Fri, 21 Mar 2008, Christian Faulhammer wrote: > >> "Jorge Manuel B. S. Vicetto" <[EMAIL PROTECTED]>: >>> With the help of Ingmar we did some cleanup and added support for >>> eclass-manpages at >>> http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=bzr. >>> >>> I'll be moving the updated eclass to the master branch, testing and >>> asking users to try it out during this weekend. >>> This eclass is used in the overlay for the live >>> avant-window-navigator ebuilds, so it's probably not as used/tested >>> as the remaining packages. It has provided us the support we needed >>> for awn, but you might need additional features or to review existing >>> ones. Please test the updated eclass on your overlay, feel free to >>> maintain it and, when you think its ready, add it to the tree. When >>> you do so, I'll remove it from our overlay and we'll use the eclass >>> on the tree. > >> We have a prior version for some time now in the Emacs overlay for >> two live ebuilds...so we go and merge your changed (ulm already >> did), test it and report any problems. > > As I just learned there are (at least) three overlays using > bzr.eclass, namely desktop-effects, emacs, and ltsp. > > So I think it is justified to move bzr.eclass to the Portage tree. > Currect version of bzr.eclass is attached. > > Please raise your objections *now*. No objections here, just a question. Do you know if the issue with the lp:// sources has been fixed in bzr? I'll be waiting for the commit to remove the eclass from the desktop-effects overlay. > Ulrich > > - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjpYrcACgkQcAWygvVEyAI3lwCZAfnVwW9RWALkXOINwaCbdxgg QIsAn2noprlga9qzUtFtwIRZk8ew9ia+ =9xKc -END PGP SIGNATURE-
Re: [gentoo-dev] Changing doc use flag on gtk-doc packages to gtk-doc-rebuild or something else
Mart Raudsepp kirjoitti: > On P, 2008-10-05 at 20:34 +0200, Thomas Sachau wrote: >> Rémi Cardona schrieb: >>> Thomas Sachau a écrit : Why not do both (rebuild and install) with the doc useflag and none of both, if it is not set? Imho the doc flag is for control of installation for (additional) docs, the way it is used for gtk-doc is surely confusing. >>> Building gtk-doc documentation pulls in a lot of deps. Installing it >>> requires only some disk-space. For a full Gnome system, I only have 96M >>> of docs. >>> >>> As for rebuilding docs, one of the advantage is to correctly crosslink >>> docs for tools such as dev-util/devhelp. >>> >>> If anyone is _that_ short on diskspace, we'll gladly take patches :) >>> >>> Cheers >>> >>> Rémi >>> >>> >> Did i say something about disk space? I say, you are using the doc use flag >> in a way that is not >> expected. > > The doc USE flag is typically used when it means additional > dependencies, noticeable build time increase or extra downloads. For all > the GNOME packages the former two apply for USE=doc because it requires > a hefty dependency list for doc generation and a long documentation > regeneration time. > The tradition is to always install documentation that is already > available. That is what we do. Those that want extra benefits of waiting > on the doc building to get better doc hyperlinking and such, can do so > with USE=doc, which is expected to take a longer time to build. > With USE="doc" the GNOME packages behave like what you expect but it's the USE="-doc" case that's in question here. With USE="-doc" you don't get any use flags installed normally and if it's in the tarball and is always installed then there is no doc in IUSE either. Global use flags should behave about the same for both on and off cases. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-10-05 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-10-05 23h59 UTC. Removals: media-fonts/liberation-fonts-ttf2008-09-30 02:01:51 je_fro app-emulation/vmware-workstation-tools 2008-09-30 20:13:11 ikelos dev-tex/extsizes2008-10-04 08:40:06 aballier dev-tex/eurosym 2008-10-04 08:41:07 aballier Additions: dev-perl/JavaScript-SpiderMonkey2008-09-29 01:52:55 robbat2 dev-perl/SQL-Abstract-Limit 2008-09-29 02:06:05 robbat2 dev-perl/Net-Z3950-ZOOM 2008-09-29 02:06:23 robbat2 dev-perl/Class-DBI-AbstractSearch 2008-09-29 02:06:41 robbat2 dev-perl/MARC-Charset 2008-09-29 02:06:59 robbat2 dev-perl/MARC-Record2008-09-29 02:07:19 robbat2 dev-perl/MARC-XML 2008-09-29 02:07:52 robbat2 dev-libs/OpenSRF2008-09-29 04:13:48 robbat2 net-misc/amazonmp3-libcompat2008-09-29 14:16:45 lack media-fonts/liberation-fonts2008-09-30 00:47:30 je_fro dev-perl/WWW-Curl 2008-09-30 08:41:04 robbat2 dev-lang/sunstudioexpress 2008-09-30 12:08:07 flameeyes x11-plugins/pidgin-mpris2008-10-01 11:19:27 chainsaw dev-libs/libhid 2008-10-01 16:36:55 matsuu app-office/akonadi-server 2008-10-02 05:01:16 jmbsvicetto media-sound/phonon 2008-10-02 05:16:17 jmbsvicetto kde-base/akonadi2008-10-02 06:04:35 jmbsvicetto kde-base/automoc2008-10-02 06:09:53 jmbsvicetto kde-base/kbreakout 2008-10-02 06:49:13 jmbsvicetto kde-base/kblocks2008-10-02 06:50:42 jmbsvicetto kde-base/kdebase-cursors2008-10-02 07:28:35 jmbsvicetto kde-base/kdegraphics-strigi-analyzer2008-10-02 07:39:32 jmbsvicetto kde-base/kdemaildir 2008-10-02 07:54:59 jmbsvicetto kde-base/kdepim-icons 2008-10-02 08:05:20 jmbsvicetto kde-base/kdepim-strigi-analyzer 2008-10-02 08:10:04 jmbsvicetto kde-base/kdeplasma-addons 2008-10-02 08:12:30 jmbsvicetto kde-base/kdesdk-strigi-analyzer 2008-10-02 08:18:17 jmbsvicetto kde-base/kdiamond 2008-10-02 08:27:22 jmbsvicetto kde-base/kiconfinder2008-10-02 08:45:49 jmbsvicetto kde-base/kleopatra 2008-10-02 08:59:10 jmbsvicetto kde-base/kollision 2008-10-02 09:27:34 jmbsvicetto kde-base/kontactinterfaces 2008-10-02 09:35:37 jmbsvicetto kde-base/ksirk 2008-10-02 09:58:46 jmbsvicetto kde-base/kstartperf 2008-10-02 10:07:39 jmbsvicetto kde-base/ksystemlog 2008-10-02 10:13:20 jmbsvicetto kde-base/ktimetracker 2008-10-02 10:18:02 jmbsvicetto kde-base/kubrick2008-10-02 10:28:11 jmbsvicetto kde-base/libkdcraw 2008-10-02 10:41:22 jmbsvicetto kde-base/libkexiv2 2008-10-02 10:46:12 jmbsvicetto kde-base/libkipi2008-10-02 10:48:42 jmbsvicetto kde-base/libkleo2008-10-02 10:50:03 jmbsvicetto kde-base/libksane 2008-10-02 10:54:33 jmbsvicetto kde-base/lokalize 2008-10-02 11:01:16 jmbsvicetto kde-base/okteta 2008-10-02 11:07:57 jmbsvicetto kde-base/phonon-xine2008-10-02 11:11:17 jmbsvicetto kde-base/plasma-apps2008-10-02 11:12:43 jmbsvicetto kde-base/plasma-workspace 2008-10-02 11:14:06 jmbsvicetto kde-base/renamedlg-plugins 2008-10-02 11:16:12 jmbsvicetto kde-base/solid-hardware 2008-10-02 11:18:40 jmbsvicetto kde-base/step 2008-10-02 11:21:08 jmbsvicetto app-misc/anki 2008-10-02 23:13:39 hncaldwell dev-libs/ustr 2008-10-03 03:15:41 pebenito dev-python/sepolgen 2008-10-03 03:46:23 pebenito dev-util/qbzr 2008-10-03 14:01:04 jokey dev-java/jtreemap 2008-10-03 21:34:39 serkan dev-util/statcvs2008-10-03 21:39:24 serkan dev-util/statsvn2008-10-03 21:44:32 serkan games-rpg/mangos2008-10-04 07:38:26 trapni x11-themes/sound-theme-freedesktop 2008-10-05 05:23:12 leio media-libs/libcanberra 2008-10-05 06:37:11 leio java-virtuals/stax-api 2008-10-05 16:19:12 serkan -- Robin Hugh Johnson Gentoo Linu
[gentoo-dev] [RFC] Label profiles with EAPI for compatibility checks (revised)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, This is a revised version of the profile EAPI lables proposal which has been discussed previously [1]. Please consider a new 'eapi' profile configuration file that will designate the EAPI to which any package atoms within the files of a given directory of a profile stack must conform. This will allow package managers to bail out with an informative error message if the user accidentally selects a profile containing an EAPI that is not supported by the currently installed package manager. In order to allow a mixture of EAPIs in the profiles, each directory of the profile stack may contain an 'eapi' configuration file to indicate the EAPI for files contained within that specific directory. In order to simplify things and avoid confusion, the EAPI will never be inherited. Therefore, the EAPI assigned to a given directory is assumed to be 0 if that directory does not explicitly contain an 'eapi' configuration file. In addition to the profiles themselves, the root profiles/ directory may also contain an 'eapi' configuration file, since that directory contains 'package.mask' and 'info_pkgs' files which contain dependency atoms. The format of the configuration file is very simple, containing only the EAPI value on the first line and nothing more. For example, a file containing just a single "0" character, followed by a newline, could be created at profiles/base/eapi in order to explicitly declare that files in the profiles/base/ directory contain dependency atoms that conform to EAPI 0. However, this particular declaration would be redundant since the EAPI is already assumed to be 0 if a given directory does not contain an 'eapi' configuration file. Different directories within a given profile stack will be allowed declare different EAPIs. For example, the base profile can remain at EAPI 0 and can thus be shared between some older profiles that conform to EAPI 0 (in all directories of the stack) and some newer profiles that contain some directories which require EAPI 1 or EAPI 2. By allowing a mixture of directories with different EAPIs, the intention is to promote code sharing such that it will be possible to use a common base profile between older and newer profiles, yet still be able to use new EAPIs in newer profiles. Does this seem like a good approach? Are there any suggestions for improvements or alternative approaches? [1] http://archives.gentoo.org/gentoo-dev/msg_b976702d0adcaa5ca5edd0d280f05000.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjpUuEACgkQ/ejvha5XGaPGjACbBMTF2wvtfwwOkXVNv6cStQr/ iIIAn1v7DbGnYyuWgs2GVxwlOfqyFRl1 =MAsI -END PGP SIGNATURE-
Re: [gentoo-dev] Changing doc use flag on gtk-doc packages to gtk-doc-rebuild or something else
On P, 2008-10-05 at 20:34 +0200, Thomas Sachau wrote:
> Rémi Cardona schrieb:
> > Thomas Sachau a écrit :
> >> Why not do both (rebuild and install) with the doc useflag and none of
> >> both, if it is not set? Imho
> >> the doc flag is for control of installation for (additional) docs, the
> >> way it is used for gtk-doc is
> >> surely confusing.
> >>
> >
> > Building gtk-doc documentation pulls in a lot of deps. Installing it
> > requires only some disk-space. For a full Gnome system, I only have 96M
> > of docs.
> >
> > As for rebuilding docs, one of the advantage is to correctly crosslink
> > docs for tools such as dev-util/devhelp.
> >
> > If anyone is _that_ short on diskspace, we'll gladly take patches :)
> >
> > Cheers
> >
> > Rémi
> >
> >
>
> Did i say something about disk space? I say, you are using the doc use flag
> in a way that is not
> expected.
The doc USE flag is typically used when it means additional
dependencies, noticeable build time increase or extra downloads. For all
the GNOME packages the former two apply for USE=doc because it requires
a hefty dependency list for doc generation and a long documentation
regeneration time.
The tradition is to always install documentation that is already
available. That is what we do. Those that want extra benefits of waiting
on the doc building to get better doc hyperlinking and such, can do so
with USE=doc, which is expected to take a longer time to build.
> The global use flag says, it installs additional documentation. But your doc
> use flag does
> not install anything additional, but instead rebuilds those docs. There is
> nothing wrong with
> rebuilding them on use=doc, but imho you should also only install those docs
> with use=doc.
Docs are installed always when they do not mean extra downloads, build
time or dependencies. They don't if they are kept in the form they are
in the tarballs already, so we already install them, just like many
other packages do (including all the dodoc's)
> The patch could be as simple as adding >use doc || rm -rf
> "${D}"usr/share/gtk-doc< at the end of
> src_install()-function in gnome2.eclass, that should be simple enough to
> apply without a patch. :)
Sorry, I'm not convinced there is anything to patch or change here.
> Btw: e.g. x11-libs/gtk+ has no doc use flag, does not rebuild those docs, but
> does also install
> those docs as reported in bug 239524.
It does have a doc USE flag, and it controls the same thing it does for
everything else gtk-doc - passing --disable-gtk-doc or --enable-gtk-doc
which acts like described above for regeneration.
Making USE=doc control both installation and regeneration is out of the
question. The benefits of rebuilding are not that big that everyone
would want to do that, especially with recent versions of gtk-doc, but
some do want it. Use INSTALL_MASK if you don't want developer API docs
is the current stance.
--
Mart Raudsepp
Gentoo Developer
Mail: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] "Slacking" arches - which are stable, which aren't?
Am Sonntag, den 05.10.2008, 16:26 -0500 schrieb Steev Klimaszewski: > > Thoughts? Helps? > Afaik we have 3 types of arches: - experimental They are not CCed on stablization bugs and don't do stablizations at all. ~mips, ~sparc-fbsd and ~x86-fbsd - unsupported They are CCed on stablizations bugs, but they are not supported by the Gentoo Linux Security Project. It may take quite long until they actually do the stablization. But I'm also wondering why some of their profiles are marked as "dev". arm, ia64, m68k, sh, s390 - supported Most popular arches, supported by the Gentoo Linux Security Project, they usually do your stablizations in time unless it requires some exotic hardware(the devs/ats don't have) to test. alpha, amd64, hppa, sparc, ppc, ppc64, x86 Sources: - commits logs - http://www.gentoo.org/security/en/vulnerability-policy.xml Cheers, Friedrich signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
Ciaran McCreesh <[EMAIL PROTECTED]> said: > On Sun, 5 Oct 2008 03:44:20 -0700 > > "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: > > Either we need special cases to declare that it no longer has a > > homepage, or we need to allow the empty HOMEPAGE. > > HOMEPAGE="( )" HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/"; signature.asc Description: This is a digitally signed message part.
[gentoo-dev] "Slacking" arches - which are stable, which aren't?
Not wanting to start a huge war about what arches are slacking and which aren't - I asked in -dev on IRC and was told to check out profiles.desc - based on this information, I closed Bug 208917 which was about stablizing dbus-glib-0.74. The bug was opened on 04 Feb 2008, and as of today 05 Oct 2008, the only arches left to stable it are arm, sh, and s390 (and according to profiles.desc, they are all dev profiles) however hoffie said that didn't seem right since he knows things get requested for stable for those arches. So, IS there a definitive list somewhere of what arches are stable, and which aren't, and if so, where can it be found? I have no problem re-opening the bug, but as I stated in -dev, its been almost 8 months since the last *activity* on the bug, and I doubt that they are going to be stabling it any time soon. Thoughts? Helps?
Re: [gentoo-dev] Re: bzr.eclass into Portage
Here is a patch that adds support for shared repositories. Since bzr
is still a bit slow this is quite useful when using multiple branches.
For example I have modified the live emacs(-cvs) ebuild to use the bzr
mirror of emacs instead of cvs. I also have my own emacs branches, and
sometimes want to install from one of these and at other times from
trunk. Without support for shared repositories this would require the
standalone branches to be manually moved out of the way everytime I
want to switch branches. (Or worse the complete tree to be checked out
from scratch every time I switch branches.)
Please consider these changes
Jonas
--- /usr/local/portage/layman/emacs/eclass/bzr.eclass 2008-10-05
22:40:18.0 +0200
+++ /usr/portage/eclass/bzr.eclass 2008-10-05 10:22:12.0 +0200
@@ -9,6 +9,7 @@
# @DESCRIPTION:
# The bzr.eclass provides support for apps using the bazaar DSCM
(distributed source control management system).
# The eclass was originally derived from the git eclass.
+# Shared repository support added by Jonas Bernoulli <[EMAIL PROTECTED]>.
#
# Note: Just set EBZR_REPO_URI to the url of the branch and the src_unpack
# this eclass provides will put an export of the branch in ${WORKDIR}/${PN}.
@@ -22,13 +23,23 @@
HOMEPAGE="http://bazaar-vcs.org/";
DESCRIPTION="Based on the ${EBZR} eclass"
-DEPEND=">=dev-util/bzr-0.92"
+DEPEND=">=dev-util/bzr-1.6"
# @ECLASS-VARIABLE: EBZR_STORE_DIR
# @DESCRIPTION:
# The dir to store the bzr sources.
EBZR_STORE_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/bzr-src"
+# @ECLASS-VARIABLE: EBZR_SHARED_REPO
+# @DESCRIPTION:
+# Whether to use a shared repository (see bzr help repositories).
+EBZR_SHARED_REPO="${EBZR_SHARED_REPO:-}"
+
+# @ECLASS-VARIABLE: EBZR_INIT_REPO_CMD
+# @DESCRIPTION:
+# The bzr command to initialize the shared repository.
+EBZR_INIT_REPO_CMD="bzr init-repo"
+
# @ECLASS-VARIABLE: EBZR_FETCH_CMD
# @DESCRIPTION:
# The bzr command to fetch the sources.
@@ -54,9 +65,24 @@
# The bzr command to list revision number of the branch.
EBZR_REVNO_CMD="bzr revno"
+# @ECLASS-VARIABLE: EBZR_INIT_REPO_OPTS
+# @DESCRIPTION:
+# Options passed to the init-repo commands.
+EBZR_INIT_REPO_OPTS="${EBZR_INIT_REPO_OPTS:-}"
+
+# @ECLASS-VARIABLE: EBZR_FETCH_OPTS
+# @DESCRIPTION:
+# Options passed to the fetch commands in additon to EBZR_OPTIONS.
+EBZR_FETCH_OPTS="${EBZR_FETCH_OPTS:-}"
+
+# @ECLASS-VARIABLE: EBZR_UPDATE_OPTS
+# @DESCRIPTION:
+# Options passed to the update commands in additon to EBZR_OPTIONS.
+EBZR_UPDATE_OPTS="${EBZR_UPDATE_OPTS:-}"
+
# @ECLASS-VARIABLE: EBZR_OPTIONS
# @DESCRIPTION:
-# The options passed to the fetch and update commands.
+# The common options passed to the fetch and update commands.
EBZR_OPTIONS="${EBZR_OPTIONS:-}"
# @ECLASS-VARIABLE: EBZR_REPO_URI
@@ -72,7 +98,7 @@
# - lp://
# @CODE
#
-# Note: lp = https://launchpad.net
+# Note: lp = http://launchpad.net
EBZR_REPO_URI="${EBZR_REPO_URI:-}"
# @ECLASS-VARIABLE: EBZR_BOOTSTRAP
@@ -93,21 +119,26 @@
# @ECLASS-VARIABLE: EBZR_BRANCH
# @DESCRIPTION:
# The branch to fetch in bzr_fetch().
-#
-# default: trunk
-EBZR_BRANCH="${EBZR_BRANCH:-trunk}"
+EBZR_BRANCH="${EBZR_BRANCH:-}"
# @ECLASS-VARIABLE: EBZR_REVISION
# @DESCRIPTION:
# Revision to get, if not latest (see http://bazaar-vcs.org/BzrRevisionSpec)
EBZR_REVISION="${EBZR_REVISION:-}"
-# @ECLASS-VARIABLE: EBZR_CACHE_DIR
+# @ECLASS-VARIABLE: EBZR_CACHE_REPO_DIR
# @DESCRIPTION:
-# The dir to store the source for the package, relative to EBZR_STORE_DIR.
+# The dir name of the local shared repository (if any).
#
# default: ${PN}
-EBZR_CACHE_DIR="${EBZR_CACHE_DIR:-${PN}}"
+EBZR_CACHE_REPO_DIR="${EBZR_CACHE_REPO_DIR:-}"
+
+# @ECLASS-VARIABLE: EBZR_CACHE_BRANCH_DIR
+# @DESCRIPTION:
+# The dir name of the local branch.
+#
+# default: ${EBZR_BRANCH} when using a shared repository or ${PN} otherwise
+EBZR_CACHE_BRANCH_DIR="${EBZR_CACHE_BRANCH_DIR:-}"
# @FUNCTION: bzr_fetch
# @DESCRIPTION:
@@ -143,37 +174,64 @@
cd -P "${EBZR_STORE_DIR}" || die "${EBZR}: can't chdir to
${EBZR_STORE_DIR}"
- EBZR_BRANCH_DIR="${EBZR_STORE_DIR}/${EBZR_CACHE_DIR}"
-
addwrite "${EBZR_STORE_DIR}"
- addwrite "${EBZR_BRANCH_DIR}"
- debug-print "${FUNCNAME}: EBZR_OPTIONS = ${EBZR_OPTIONS}"
+ if [[ -n ${EBZR_SHARED_REPO} ]]; then
+ # using shared repository
+ EBZR_REPO_DIR="${EBZR_STORE_DIR}/${EBZR_CACHE_REPO_DIR:-${PN}}"
+
EBZR_BRANCH_DIR="${EBZR_REPO_DIR}/${EBZR_CACHE_BRANCH_DIR:-${EBZR_BRANCH}}"
+
+ addwrite "${EBZR_REPO_DIR}"
+ else
+ # using stand-alone branch
+
EBZR_BRANCH_DIR="${EBZR_STORE_DIR}/${EBZR_CACHE_BRANCH_DIR:-${PN}}"
+ fi
+
+ addwrite "${EBZR_BRANCH_DIR}"
- local repository
+ local branch
- if [[ ${EBZR_REPO_URI} == */* ]]; then
- repository="${EBZR_REPO_URI}${EBZR_BRANCH}"
+ if [[ -n ${EBZR_BRANCH} ]] ; then
+
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 05 Oct 2008 10:11:08 -0700 > Zac Medico <[EMAIL PROTECTED]> wrote: >> They can call 'die' in global scope. Perhaps it's not the nicest >> thing to do, but it can be done. > > Last time I tried it, Portage behaved rather horribly with global scope > dies. Is this still the case? In terms of dependency resolution, the current behavior is to report that the package is "masked by corruption". >> Considering that they can already call 'die' in global scope I don't >> see it as being that urgent. > > If we're considering global scope die to be a usable solution, we need > to start defining its behaviour and providing a way of tracking it in > metadata. Sure, we can add some bells and whistles. But like I said before, I don't see it as being especially urgent. If an eclass uses 'die' as an assertion, it's not something that should be triggered under normal circumstances. It serves mostly a feedback mechanism which quickly informs the developer when they've made a mistake that needs to be corrected immediately. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjpIo0ACgkQ/ejvha5XGaOtrwCg4Q58XViLtI9/YNMz2hj6VX1k y2QAoIHGMLelGKmIyYDYmZNmg61z0LUj =iwn8 -END PGP SIGNATURE-
Re: [gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
On Sun, 5 Oct 2008 03:44:20 -0700 "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: > Either we need special cases to declare that it no longer has a > homepage, or we need to allow the empty HOMEPAGE. HOMEPAGE="( )" -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
081005 Ryan Hill wrote: > 5 Oct 2008 "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: >> For projects where the upstream has vanished off the face of the planet >> but ... the code works fine still, there's problems >> with either the requirements of HOMEPAGE or the repoman check. >> Either we need special cases to declare it no longer has a homepage >> or we need to allow the empty HOMEPAGE. > I'd rather see "unknown" or something that implies "I looked, no luck" > rather than "I forgot to fill this in". As a user who sometimes checks the upstream site for further info, I strongly support eg 'Unknown' or 'No support site can be found'. Leaving it blank is ambiguous & might even encourage a buzy dev not to bother trying to find a changed upstream site. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 05 Oct 2008 10:11:08 -0700 Zac Medico <[EMAIL PROTECTED]> wrote: > They can call 'die' in global scope. Perhaps it's not the nicest > thing to do, but it can be done. Last time I tried it, Portage behaved rather horribly with global scope dies. Is this still the case? > Considering that they can already call 'die' in global scope I don't > see it as being that urgent. If we're considering global scope die to be a usable solution, we need to start defining its behaviour and providing a way of tracking it in metadata. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
On Sun, 5 Oct 2008 21:48:09 +0200 Ulrich Mueller <[EMAIL PROTECTED]> wrote: > All our documentation (devmanual, ebuild howto, skel.ebuild, pms) > recommends "econf || die". I've fixed PMS. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Changing doc use flag on gtk-doc packages to gtk-doc-rebuild or something else
Le dimanche 05 octobre 2008 à 20:34 +0200, Thomas Sachau a écrit :
> Did i say something about disk space? I say, you are using the doc use flag
> in a way that is not
> expected. The global use flag says, it installs additional documentation. But
> your doc use flag does
> not install anything additional, but instead rebuilds those docs. There is
> nothing wrong with
> rebuilding them on use=doc, but imho you should also only install those docs
> with use=doc.
>
> The patch could be as simple as adding >use doc || rm -rf
> "${D}"usr/share/gtk-doc< at the end of
> src_install()-function in gnome2.eclass, that should be simple enough to
> apply without a patch. :)
I've not dig that information but it seems to me this is the way it is
because gtk-doc configure switch itself acts like this.
Now if ones digs the archive of this mailing list, I think there was
some talk about renaming the flag for compilation vs. installation only
in order to be more consistent with global use flag meaning but I can't
remember the outcome.
Besides if one really doesn't want to install _any_ gtk-doc there is
still the INSTALL_MASK option (I know it's for l33t users reading mans,
but...).
--
Gilles Dartiguelongue <[EMAIL PROTECTED]>
Gentoo
signature.asc
Description: Ceci est une partie de message numériquement signée
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
> On Sun, 05 Oct 2008, Thomas Sachau wrote:
>> econf \
>> [...]
>> ${myconf} || die
> "|| die" could be dropped
All our documentation (devmanual, ebuild howto, skel.ebuild, pms)
recommends "econf || die".
So maybe you should first make an effort to have it changed there?
I wouldn't consider it a bug in ebuilds if they conform to what is
documented.
Ulrich
Re: [gentoo-dev] developer profile
Thomas Sachau wrote: > I just had a user in bugzilla who thought, the developer profile would be for > software developers, > not just for gentoo developers. Probably he is not the only one. > > What about either adding some big warning on portage output or renaming this > profile to e.g. > "gentoodeveloper"? I think this discussion has popped up before on both this list and on gentoo-doc. I added some substantial warnings to the documentation that discusses profiles per Donnie's request if I remember right. The bottom line is that you can try to make things as tricky as you want; users will still try to do it because they don't bother to read any documentation. That's something you can't force 'em to do. Still, perhaps adding some output would be good, though I'm not sure how. eselect doesn't seem to be setup to display anything; "eselect profile set 9" to switch to "amd64/2008.0" doesn't even return a message that it was set. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Ali Polatel (hawking) schrieb:
> use threads \
> && myconf="${myconf} --with-threads" \
> || myconf="${myconf} --without-threads"
What about an econf option $(use_with threads)?
> econf \
> --with-fpectl \
> --enable-shared \
> `use_enable ipv6` \
> --infodir='${prefix}'/share/info \
> --mandir='${prefix}'/share/man \
> --with-libc='' \
> ${myconf} || die
"|| die" could be dropped
> src_install() {
> dodir /usr
Will the install fail without a /usr dir?
> src_configure
> make DESTDIR="${D}" altinstall maninstall || die
Why not emake?
> if use examples ; then
> mkdir -p "${D}"/usr/share/doc/${P}/examples
> cp -r "${S}"/Tools "${D}"/usr/share/doc/${P}/examples
> fi
what about this:
insinto /usr/share/doc/${P}/examples
doins -r Tools
> python_mod_cleanup /usr/lib/python${PYVER}
> [[ "$(get_libdir)" == "lib" ]] || \
> python_mod_cleanup /usr/$(get_libdir)/python${PYVER}
Why not remove the first 2 lines?
> python_mod_optimize -x "(site-packages|test)" \
> /usr/lib/python${PYVER}
> [[ "$(get_libdir)" == "lib" ]] || \
> python_mod_optimize -x "(site-packages|test)" \
>
> /usr/$(get_libdir)/python${PYVER}
the same here
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Changing doc use flag on gtk-doc packages to gtk-doc-rebuild or something else
Rémi Cardona schrieb:
> Thomas Sachau a écrit :
>> Why not do both (rebuild and install) with the doc useflag and none of
>> both, if it is not set? Imho
>> the doc flag is for control of installation for (additional) docs, the
>> way it is used for gtk-doc is
>> surely confusing.
>>
>
> Building gtk-doc documentation pulls in a lot of deps. Installing it
> requires only some disk-space. For a full Gnome system, I only have 96M
> of docs.
>
> As for rebuilding docs, one of the advantage is to correctly crosslink
> docs for tools such as dev-util/devhelp.
>
> If anyone is _that_ short on diskspace, we'll gladly take patches :)
>
> Cheers
>
> Rémi
>
>
Did i say something about disk space? I say, you are using the doc use flag in
a way that is not
expected. The global use flag says, it installs additional documentation. But
your doc use flag does
not install anything additional, but instead rebuilds those docs. There is
nothing wrong with
rebuilding them on use=doc, but imho you should also only install those docs
with use=doc.
The patch could be as simple as adding >use doc || rm -rf
"${D}"usr/share/gtk-doc< at the end of
src_install()-function in gnome2.eclass, that should be simple enough to apply
without a patch. :)
Btw: e.g. x11-libs/gtk+ has no doc use flag, does not rebuild those docs, but
does also install
those docs as reported in bug 239524.
--
Thomas Sachau
Gentoo Linux Developer
use doc || rm -rf "${D}usr/share/gtk-doc
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI
Robert Buchholz schrieb:
> On Sunday, 5. October 2008, Ulrich Mueller wrote:
>>> On Sun, 5 Oct 2008, Robert Buchholz wrote:
> It's not. If you want to have default DOCS then you should loop
> through the items and check with [[ -e ]] before trying to
> install them.
So, maybe just do a 'dodoc "${DOCS}"' and omit the die? Then it won't
fail but the warning message would be preserved.
>>> I understood Petteri's comment to be related to the default case
>>> (i.e. the else-branch), and I have to agree there: Ebuilds that do
>>> not override src_install should not emit a warning when some
>>> ChangeLog file is missing that the ebuild never specified to
>>> install.
>> The default would be an empty DOCS variable, or did I miss something?
>
> Correct.
>
>> So if the ebuild includes non-existing files in DOCS, then why would
>> you want to suppress the warnings?
>
> I don't. My point was that the default action on an empty DOCS variable is
> to "dodoc AUTHORS ChangeLog NEWS README", and this should not emit
> warnings, because it is merely a heuristic.
>
> To be clearer:
> else
> -# No die here because we don't know if any of these exist
> -dodoc AUTHORS ChangeLog NEWS README
> +for x in AUTHORS ChangeLog NEWS README; do
> +if [ -e ${x} ]; then
> +dodoc ${x} || die "dodoc ${x} failed"
> +fi
> +done
> fi
>
>
> Robert
So what about this funcion for the next EAPI and also implementation in
base.eclass?
default_src_install() {
if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
emake DESTDIR="${D}" install || die "emake install failed"
fi
if [ -n "${DOCS}" ]; then
dodoc ${DOCS} || die "dodoc failed"
else
for x in AUTHORS ChangeLog NEWS README; do
if [ -e ${x} ]; then
dodoc ${x} || die "dodoc ${x} failed"
fi
done
fi
}
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
On Sat, 04 Oct 2008 10:17:05 -0700 Zac Medico <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ryan Hill wrote: > > Though I'm still not sure what happens when a package is in two > > unrelated sets.. > > > > @gnome: > >RDEPEND=">=gnome-extra/gnome-screensaver-2.22.2" > > > > @xfce4: > >RDEPEND="gnome-extra/gnome-screensaver" > > > > package.use: > > @gnome opengl > > @xfce -opengl > > > > I suppose we could use the order that they are listed in package.use > to apply the incremental stacking, so opengl would be disabled since > @xfce comes after @gnome. I guess I'll need to stop sorting my package.use then. :p But yeah, I have no better idea. If someone really needs to lock down a USE flag on a pkg they can put the pkg atom itself into p.use. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
On Sun, 5 Oct 2008 03:44:20 -0700
"Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
> For projects where the upstream has vanished off the face of the
> planet, and the project was reasonably obscure, but the code works
> fine still, there's problems with either the requirements of HOMEPAGE
> or the repoman check.
>
> From PMS:
> \item[HOMEPAGE] The URI or URIs for a package's homepage, including
> protocols. May be defined by an eclass. See section~\ref{dependencies}
> for full syntax.
>
> Devmanual:
> HOMEPAGE: Package's homepage. If you are unable to locate an official
> one, try to provide a link to freshmeat.net or a similar package
> tracking site. Never refer to a variable name in the string; include
> only raw text.
>
> As Infra, I suggested that zero or more valid URLs should be present
> in the bug where the question was raised.
>
> However repoman doesn't like an empty HOMEPAGE variable:
>
> HOMEPAGE.missing 1
> app-mobilephone/smssend/smssend-3.4.ebuild
>
> Either we need special cases to declare that it no longer has a
> homepage, or we need to allow the empty HOMEPAGE.
>
> I'm in favour of allowing the variable to empty, because I'm a lazy
> upstream, and I haven't even made a basic webpage for some of my
> projects (diradm, localshell, readahead-list, etc).
I'd rather see "unknown" or something that implies "I looked, no luck"
rather than "I forgot to fill this in".
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
[gentoo-dev] Re: bzr.eclass into Portage
> On Fri, 21 Mar 2008, Christian Faulhammer wrote:
> "Jorge Manuel B. S. Vicetto" <[EMAIL PROTECTED]>:
>> With the help of Ingmar we did some cleanup and added support for
>> eclass-manpages at
>> http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.eclass;hb=bzr.
>>
>> I'll be moving the updated eclass to the master branch, testing and
>> asking users to try it out during this weekend.
>> This eclass is used in the overlay for the live
>> avant-window-navigator ebuilds, so it's probably not as used/tested
>> as the remaining packages. It has provided us the support we needed
>> for awn, but you might need additional features or to review existing
>> ones. Please test the updated eclass on your overlay, feel free to
>> maintain it and, when you think its ready, add it to the tree. When
>> you do so, I'll remove it from our overlay and we'll use the eclass
>> on the tree.
> We have a prior version for some time now in the Emacs overlay for
> two live ebuilds...so we go and merge your changed (ulm already
> did), test it and report any problems.
As I just learned there are (at least) three overlays using
bzr.eclass, namely desktop-effects, emacs, and ltsp.
So I think it is justified to move bzr.eclass to the Portage tree.
Currect version of bzr.eclass is attached.
Please raise your objections *now*.
Ulrich
# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# @ECLASS: bzr.eclass
# @MAINTAINER:
# Jorge Manuel B. S. Vicetto @gentoo.org
# @BLURB: This eclass provides support to use the Bazaar DSCM
# @DESCRIPTION:
# The bzr.eclass provides support for apps using the bazaar DSCM (distributed
source control management system).
# The eclass was originally derived from the git eclass.
#
# Note: Just set EBZR_REPO_URI to the url of the branch and the src_unpack
# this eclass provides will put an export of the branch in ${WORKDIR}/${PN}.
inherit eutils
EBZR="bzr.eclass"
EXPORT_FUNCTIONS src_unpack
HOMEPAGE="http://bazaar-vcs.org/";
DESCRIPTION="Based on the ${EBZR} eclass"
DEPEND=">=dev-util/bzr-0.92"
# @ECLASS-VARIABLE: EBZR_STORE_DIR
# @DESCRIPTION:
# The dir to store the bzr sources.
EBZR_STORE_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/bzr-src"
# @ECLASS-VARIABLE: EBZR_FETCH_CMD
# @DESCRIPTION:
# The bzr command to fetch the sources.
EBZR_FETCH_CMD="bzr branch"
# @ECLASS-VARIABLE: EBZR_UPDATE_CMD
# @DESCRIPTION:
# The bzr command to update the sources.
EBZR_UPDATE_CMD="bzr pull"
# @ECLASS-VARIABLE: EBZR_DIFFSTAT_CMD
# @DESCRIPTION:
# The bzr command to get the diffstat output.
EBZR_DIFFSTAT_CMD="bzr diff"
# @ECLASS-VARIABLE: EBZR_EXPORT_CMD
# @DESCRIPTION:
# The bzr command to export a branch.
EBZR_EXPORT_CMD="bzr export"
# @ECLASS-VARIABLE: EBZR_REVNO_CMD
# @DESCRIPTION:
# The bzr command to list revision number of the branch.
EBZR_REVNO_CMD="bzr revno"
# @ECLASS-VARIABLE: EBZR_OPTIONS
# @DESCRIPTION:
# The options passed to the fetch and update commands.
EBZR_OPTIONS="${EBZR_OPTIONS:-}"
# @ECLASS-VARIABLE: EBZR_REPO_URI
# @DESCRIPTION:
# The repository uri for the source package.
#
# @CODE
# Supported protocols:
# - http://
# - https://
# - sftp://
# - rsync://
# - lp://
# @CODE
#
# Note: lp = https://launchpad.net
EBZR_REPO_URI="${EBZR_REPO_URI:-}"
# @ECLASS-VARIABLE: EBZR_BOOTSTRAP
# @DESCRIPTION:
# Bootstrap script or command like autogen.sh or etc.
EBZR_BOOTSTRAP="${EBZR_BOOTSTRAP:-}"
# @ECLASS-VARIABLE: EBZR_PATCHES
# @DESCRIPTION:
# bzr eclass can apply patches in bzr_bootstrap().
# you can use regexp in this valiable like *.diff or *.patch or etc.
# NOTE: this patches will applied before EBZR_BOOTSTRAP is processed.
#
# Patches are searched both in ${PWD} and ${FILESDIR}, if not found in either
# location, the installation dies.
EBZR_PATCHES="${EBZR_PATCHES:-}"
# @ECLASS-VARIABLE: EBZR_BRANCH
# @DESCRIPTION:
# The branch to fetch in bzr_fetch().
#
# default: trunk
EBZR_BRANCH="${EBZR_BRANCH:-trunk}"
# @ECLASS-VARIABLE: EBZR_REVISION
# @DESCRIPTION:
# Revision to get, if not latest (see http://bazaar-vcs.org/BzrRevisionSpec)
EBZR_REVISION="${EBZR_REVISION:-}"
# @ECLASS-VARIABLE: EBZR_CACHE_DIR
# @DESCRIPTION:
# The dir to store the source for the package, relative to EBZR_STORE_DIR.
#
# default: ${PN}
EBZR_CACHE_DIR="${EBZR_CACHE_DIR:-${PN}}"
# @FUNCTION: bzr_fetch
# @DESCRIPTION:
# Wrapper function to fetch sources from bazaar via bzr fetch or bzr update,
# depending on whether there is an existing working copy in ${EBZR_BRANCH_DIR}.
bzr_fetch() {
local EBZR_BRANCH_DIR
# EBZR_REPO_URI is empty.
[[ -z ${EBZR_REPO_URI} ]] && die "${EBZR}: EBZR_REPO_URI is empty."
# check for the protocol or pull from a local repo.
if [[ -z ${EBZR_REPO_URI%%:*} ]] ; then
case ${EBZR_REPO_URI%%:*} in
# lp:// is https://launchpad.net
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 5 Oct 2008 17:07:40 +0200 > Alexis Ballier <[EMAIL PROTECTED]> wrote: >> Maybe eclasses should die on unknown eapi; the fact is I really hate >> the current way it's done when switching an ebuild to EAPI-2 which >> uses an eclass that exports src_compile; most eclasses don't special >> case eapi-2 yet and we end up running econf twice at best. I fear >> that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll >> support src_configure too) > > There's currently no mechanism for an ebuild or eclass to 'die' in > global scope. They can call 'die' in global scope. Perhaps it's not the nicest thing to do, but it can be done. > It's something that could be available for future EAPIs without too > much difficulty, though... We discussed this for Exherbo, and decided > upon something like this: > > * Add a new metadata key called BROKENNESS. > > * Any ID with non-empty BROKENNESS is treated as being hard masked and > not unmaskable by the user, in the same way than an unknown EAPI is. > > * Add a function which can only be called in global scope that adds an > item to BROKENNESS. This does *not* prevent further sourcing. > > This one hopefully shouldn't be too hard to implement (Zac?). If people > are running into excessive difficulties with eclasses, it might be > worth doing an EAPI 3 quickly with just this addition... > Considering that they can already call 'die' in global scope I don't see it as being that urgent. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjo9SsACgkQ/ejvha5XGaOUUQCfRSaJYF3xqWfaLVfE1M5lT0Fk NDcAnikfPOu/6nnBZIXuKbUXptNIPyOP =Lpc7 -END PGP SIGNATURE-
Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI
> On Sun, 5 Oct 2008, Robert Buchholz wrote:
>> So if the ebuild includes non-existing files in DOCS, then why would
>> you want to suppress the warnings?
> I don't. My point was that the default action on an empty DOCS
> variable is to "dodoc AUTHORS ChangeLog NEWS README", and this
> should not emit warnings, because it is merely a heuristic.
> To be clearer:
> else
> -# No die here because we don't know if any of these exist
> -dodoc AUTHORS ChangeLog NEWS README
> +for x in AUTHORS ChangeLog NEWS README; do
> +if [ -e ${x} ]; then
> +dodoc ${x} || die "dodoc ${x} failed"
> +fi
> +done
> fi
I agree. You (and Petteri) are absolutely right.
Ulrich
Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI
On Sunday, 5. October 2008, Ulrich Mueller wrote:
> > On Sun, 5 Oct 2008, Robert Buchholz wrote:
> >> >
> >> > It's not. If you want to have default DOCS then you should loop
> >> > through the items and check with [[ -e ]] before trying to
> >> > install them.
> >>
> >> So, maybe just do a 'dodoc "${DOCS}"' and omit the die? Then it won't
> >> fail but the warning message would be preserved.
> >
> > I understood Petteri's comment to be related to the default case
> > (i.e. the else-branch), and I have to agree there: Ebuilds that do
> > not override src_install should not emit a warning when some
> > ChangeLog file is missing that the ebuild never specified to
> > install.
>
> The default would be an empty DOCS variable, or did I miss something?
Correct.
> So if the ebuild includes non-existing files in DOCS, then why would
> you want to suppress the warnings?
I don't. My point was that the default action on an empty DOCS variable is
to "dodoc AUTHORS ChangeLog NEWS README", and this should not emit
warnings, because it is merely a heuristic.
To be clearer:
else
-# No die here because we don't know if any of these exist
-dodoc AUTHORS ChangeLog NEWS README
+for x in AUTHORS ChangeLog NEWS README; do
+if [ -e ${x} ]; then
+dodoc ${x} || die "dodoc ${x} failed"
+fi
+done
fi
Robert
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Changing doc use flag on gtk-doc packages to gtk-doc-rebuild or something else
Thomas Sachau a écrit : Why not do both (rebuild and install) with the doc useflag and none of both, if it is not set? Imho the doc flag is for control of installation for (additional) docs, the way it is used for gtk-doc is surely confusing. Building gtk-doc documentation pulls in a lot of deps. Installing it requires only some disk-space. For a full Gnome system, I only have 96M of docs. As for rebuilding docs, one of the advantage is to correctly crosslink docs for tools such as dev-util/devhelp. If anyone is _that_ short on diskspace, we'll gladly take patches :) Cheers Rémi
Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI
> On Sun, 5 Oct 2008, Robert Buchholz wrote:
>> > It's not. If you want to have default DOCS then you should loop
>> > through the items and check with [[ -e ]] before trying to
>> > install them.
>> So, maybe just do a 'dodoc "${DOCS}"' and omit the die? Then it won't
>> fail but the warning message would be preserved.
> I understood Petteri's comment to be related to the default case
> (i.e. the else-branch), and I have to agree there: Ebuilds that do
> not override src_install should not emit a warning when some
> ChangeLog file is missing that the ebuild never specified to
> install.
The default would be an empty DOCS variable, or did I miss something?
So if the ebuild includes non-existing files in DOCS, then why would
you want to suppress the warnings?
Ulrich
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 17:38:11 +0200 Ulrich Mueller <[EMAIL PROTECTED]> wrote: > > By the way, do we really want to special case eapi-2 in every > > eclass ? That's lot of code duplication and will get even worse > > when we'll reach eapi-42. That would have been cool to have a pm > > function that tells "has my eapi foo support" but that sort of > > bites its tail that way. > > Hm, what about: > [ "$(type -t src_configure)" == function ] && EXPORT_FUNCTIONS > src_configure > > Or is this too fragile or trying to be too clever? It's illegal, according to PMS. It also won't work with Paludis, since phase function definitions aren't made available until just before that phase executes (there is a reason for this -- it provides us with a way of identifying whether a package has a particular phase or not). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
> On Sun, 5 Oct 2008, Alexis Ballier wrote: > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: >> Export it if and only if EAPI is 2. > By the way, do we really want to special case eapi-2 in every eclass ? > That's lot of code duplication and will get even worse when we'll reach > eapi-42. That would have been cool to have a pm function that tells > "has my eapi foo support" but that sort of bites its tail that way. Hm, what about: [ "$(type -t src_configure)" == function ] && EXPORT_FUNCTIONS src_configure Or is this too fragile or trying to be too clever? Ulrich
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 17:07:40 +0200 Alexis Ballier <[EMAIL PROTECTED]> wrote: > Maybe eclasses should die on unknown eapi; the fact is I really hate > the current way it's done when switching an ebuild to EAPI-2 which > uses an eclass that exports src_compile; most eclasses don't special > case eapi-2 yet and we end up running econf twice at best. I fear > that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll > support src_configure too) There's currently no mechanism for an ebuild or eclass to 'die' in global scope. It's something that could be available for future EAPIs without too much difficulty, though... We discussed this for Exherbo, and decided upon something like this: * Add a new metadata key called BROKENNESS. * Any ID with non-empty BROKENNESS is treated as being hard masked and not unmaskable by the user, in the same way than an unknown EAPI is. * Add a function which can only be called in global scope that adds an item to BROKENNESS. This does *not* prevent further sourcing. This one hopefully shouldn't be too hard to implement (Zac?). If people are running into excessive difficulties with eclasses, it might be worth doing an EAPI 3 quickly with just this addition... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: developer profile
Thomas Sachau <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 05 Oct 2008 14:24:55 +0200: > I just had a user in bugzilla who thought, the developer profile would > be for software developers, not just for gentoo developers. Probably he > is not the only one. > > What about either adding some big warning on portage output or renaming > this profile to e.g. "gentoodeveloper"? > There's a thread in the archive discussing this. The conclusion then seemed to be that the traditional profile.bashrc test for I_KNOW_WHAT_I_AM_DOING=yes, with a suitable warning if it wasn't set, should be enough. The problem with that is that the profile itself sets that var in profiles/targets/developer/make.defaults, so anyone using the profile has it set automatically, rather defeating the purpose of the test in the first place. The solution would be to remove that bit from profiles/targets/developer (and other places it may be set in the profiles, forcing those using the developer profiles to actually set it themselves. If they don't, they get the warning. If they see the warning and set it anyway, well, one would hope they /do/ know what they are doing, and if they don't, as the saying goes "If it breaks, you (they) get to keep the pieces!" I'd suggest a somewhat less generic var as well. Perhaps I_AM_A_GENTOO_TESTER_AND_I_KNOW_WHAT_I_AM_DOING, or maybe I_KNOW_THIS_MAY_BREAK_BUT_I_AM_TESTING_AND_KNOW_WHAT_I_AM_DOING. Or make the profile.bashrc test for both the var and a more specific value, perhaps like this: I_KNOW_WHAT_I_AM_DOING="and I know it can break but I am testing" -- 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
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 15:24:20 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sun, 5 Oct 2008 16:15:46 +0200 > Alexis Ballier <[EMAIL PROTECTED]> wrote: > > An eapi.eclass with such functions and lists of eapi & features > > maintained there could help though. > > The problem is, 'features' change between EAPIs. For example, all > three EAPIs have src_compile, but it does different things for all > three. One can't assume that a feature working for current EAPIs will > carry on working for future EAPIs, and even if it does there can be > other interactions that break. Indeed; different names could be given to different implementations of the same thing, but that might completely kill the point of abstracting it. Maybe eclasses should die on unknown eapi; the fact is I really hate the current way it's done when switching an ebuild to EAPI-2 which uses an eclass that exports src_compile; most eclasses don't special case eapi-2 yet and we end up running econf twice at best. I fear that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll support src_configure too) > > An EXPORT_FUNCTIONS ignoring any function its doesn't know for its > > eapi would help too. > > An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place > checking for eclass screwups... yes; that's just a matter of choice though, but for eclasses it's probably not luxury. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 16:15:46 +0200 Alexis Ballier <[EMAIL PROTECTED]> wrote: > An eapi.eclass with such functions and lists of eapi & features > maintained there could help though. The problem is, 'features' change between EAPIs. For example, all three EAPIs have src_compile, but it does different things for all three. One can't assume that a feature working for current EAPIs will carry on working for future EAPIs, and even if it does there can be other interactions that break. > An EXPORT_FUNCTIONS ignoring any function its doesn't know for its > eapi would help too. An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place checking for eclass screwups... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 15:07:27 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sun, 5 Oct 2008 15:36:30 +0200 > Ulrich Mueller <[EMAIL PROTECTED]> wrote: > > How should exporting of src_configure in eclasses be handled? Should > > it be conditional, depending on the EAPI? Or is it O.K. to export > > src_configure unconditionally, since it doesn't harm for EAPI<2? > > Export it if and only if EAPI is 2. > > Note that this means EAPI really really has to be set as the first > thing in the ebuild (*cough* or in the file extension). By the way, do we really want to special case eapi-2 in every eclass ? That's lot of code duplication and will get even worse when we'll reach eapi-42. That would have been cool to have a pm function that tells "has my eapi foo support" but that sort of bites its tail that way. An eapi.eclass with such functions and lists of eapi & features maintained there could help though. An EXPORT_FUNCTIONS ignoring any function its doesn't know for its eapi would help too. Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI
On Sunday, 5. October 2008, Ulrich Mueller wrote:
> > On Tue, 30 Sep 2008, Petteri Räty wrote:
> >>>
> >>> dodoc ${DOCS} || die "dodoc failed"
> >>
> >> This seems alright fine to me
> >
> > It's not. If you want to have default DOCS then you should loop
> > through the items and check with [[ -e ]] before trying to install
> > them.
>
> I'm not convinced that this is a good idea. Then you won't catch cases
> where upstream removes or renames files.
>
> Besides, dodoc already checks for -e by itself (and emits a warning if
> the file does not exist).
>
> So, maybe just do a 'dodoc "${DOCS}"' and omit the die? Then it won't
> fail but the warning message would be preserved.
I understood Petteri's comment to be related to the default case (i.e. the
else-branch), and I have to agree there: Ebuilds that do not override
src_install should not emit a warning when some ChangeLog file is missing
that the ebuild never specified to install.
Robert
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
On Sun, 5 Oct 2008 15:36:30 +0200 Ulrich Mueller <[EMAIL PROTECTED]> wrote: > How should exporting of src_configure in eclasses be handled? Should > it be conditional, depending on the EAPI? Or is it O.K. to export > src_configure unconditionally, since it doesn't harm for EAPI<2? Export it if and only if EAPI is 2. Note that this means EAPI really really has to be set as the first thing in the ebuild (*cough* or in the file extension). -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] EAPI-2 and src_configure in eclasses
How should exporting of src_configure in eclasses be handled? Should it be conditional, depending on the EAPI? Or is it O.K. to export src_configure unconditionally, since it doesn't harm for EAPI<2? A concrete example is elisp.eclass which should export an empty elisp_src_configure function for EAPI=2. Ulrich
Re: [gentoo-dev] Changing doc use flag on gtk-doc packages to gtk-doc-rebuild or something else
Petteri Räty schrieb: > Currently the doc use flag on gtk-doc using packages does not control > doc installation but instead whether to rebuild them so that they are > properly cross linked. I think we should be using a separate use flag > from doc for this purpose. Any comments? > > 15:40 <@Betelgeuse> EvaSDK: Just change the doc use flag to something > else and it won't confuse people > 15:56 <@EvaSDK> Betelgeuse: it not like it's been like this forever... > 15:56 <@EvaSDK> send a mail to -dev if you want to discuss it > > Regards, > Petteri > Why not do both (rebuild and install) with the doc useflag and none of both, if it is not set? Imho the doc flag is for control of installation for (additional) docs, the way it is used for gtk-doc is surely confusing. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] Changing doc use flag on gtk-doc packages to gtk-doc-rebuild or something else
Currently the doc use flag on gtk-doc using packages does not control doc installation but instead whether to rebuild them so that they are properly cross linked. I think we should be using a separate use flag from doc for this purpose. Any comments? 15:40 <@Betelgeuse> EvaSDK: Just change the doc use flag to something else and it won't confuse people 15:56 <@EvaSDK> Betelgeuse: it not like it's been like this forever... 15:56 <@EvaSDK> send a mail to -dev if you want to discuss it Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] developer profile
I just had a user in bugzilla who thought, the developer profile would be for software developers, not just for gentoo developers. Probably he is not the only one. What about either adding some big warning on portage output or renaming this profile to e.g. "gentoodeveloper"? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
On Sunday 05 of October 2008 12:44:20 Robin H. Johnson wrote: > I'm in favour of allowing the variable to empty, because I'm a lazy > upstream, and I haven't even made a basic webpage for some of my > projects (diradm, localshell, readahead-list, etc). lol +1 for allowing empty $HOMEPAGE
[gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
For projects where the upstream has vanished off the face of the planet,
and the project was reasonably obscure, but the code works fine still,
there's problems with either the requirements of HOMEPAGE or the repoman
check.
From PMS:
\item[HOMEPAGE] The URI or URIs for a package's homepage, including
protocols. May be defined by an eclass. See section~\ref{dependencies}
for full syntax.
Devmanual:
HOMEPAGE: Package's homepage. If you are unable to locate an official
one, try to provide a link to freshmeat.net or a similar package
tracking site. Never refer to a variable name in the string; include
only raw text.
As Infra, I suggested that zero or more valid URLs should be present in
the bug where the question was raised.
However repoman doesn't like an empty HOMEPAGE variable:
HOMEPAGE.missing 1
app-mobilephone/smssend/smssend-3.4.ebuild
Either we need special cases to declare that it no longer has a
homepage, or we need to allow the empty HOMEPAGE.
I'm in favour of allowing the variable to empty, because I'm a lazy
upstream, and I haven't even made a basic webpage for some of my
projects (diradm, localshell, readahead-list, etc).
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpEY9IMEIoLw.pgp
Description: PGP signature
Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI
> On Tue, 30 Sep 2008, Petteri Räty wrote:
>>> dodoc ${DOCS} || die "dodoc failed"
>> This seems alright fine to me
> It's not. If you want to have default DOCS then you should loop
> through the items and check with [[ -e ]] before trying to install
> them.
I'm not convinced that this is a good idea. Then you won't catch cases
where upstream removes or renames files.
Besides, dodoc already checks for -e by itself (and emits a warning if
the file does not exist).
So, maybe just do a 'dodoc "${DOCS}"' and omit the die? Then it won't
fail but the warning message would be preserved.
Ulrich
