gmane.linux.gentoo.devel

Re: Changing doc use flag on gtk-doc packages togtk-doc-rebuild or something else

Mart Raudsepp — 2008-10-07T19:56:04

So you propose we would always install the documentation, but have a new global USE flag (remember, we are talking about over a hundred of packages here - everything that inherits gnome2.eclass) with a yet to be determined name to control the re-generation? However, with the advancements of the gtk-doc system, there _might_ not be any more benefits in rebuilding the documentation, so I've had the intention to check that out and perhaps propose removing the doc USE flag completely and never regenerate it if it's true that it has no point. But checking this has been quite a low priority, and given that we need to get GNOME-2.24 out there for the users, it remains so during this month, at least for me. I would propose that we (the GNOME team) investigates the benefits (or lack thereof these days) of the regeneration in the first part of November, and if we don't, you get to remind us and we take care of it as the hurry with a new major GNOME version, that users are awaiting (including squashing all bugs need

Re: Re: EAPI-2 and src_configure in eclasses

Ciaran McCreesh — 2008-10-07T16:33:22

On Tue, 07 Oct 2008 17:07:21 +0100 Steve Long rathaus.eclipse.co.uk> wrote: The whole point of PMS is that it provides a way to avoid relying upon implementation specific things. There are currently no packages that rely upon calling phase functions in the wrong place, and there are good reasons a package manager might want to avoid implementing things in a way such that doing so is legal, so we don't allow it. Also, I don't think it has to be done at that point. I think it's convenient to do it at that point, and when combined with several other reasons doing it that way is the best option. Strange how you repeatedly seem to pop up in favour of doing whatever you think will cause most inconvenience to Paludis, though...

Re: EAPI-2 and src_configure in eclasses

Steve Long — 2008-10-07T16:07:21

That seems a bit implementation-specific; how one alternative package manager generates that metadata isn't important (though it does seem odd that you think it has to be done at that point) nor should it get in the way.

Re: EAPI-2 and src_configure in eclasses

Steve Long — 2008-10-07T15:49:30

Well it's simple enough to check (and give a QA warning) for unknown functions; adding a check for a specific string prefix (or to exclude a certain subset) in EXPORT_FUNCTIONS (based on current EAPI) is simple enough too. Is that what you mean? The behaviour to trigger could change eg for debug mode, or a repoman check. I don't quite see how that deals with an eclass calling econf in its exported src_compile? Seems like EAPI versioning for eclasses (with implicit 0 only) is more what you're after for that issue (so the PM could suppress src_configure if src_compile is going to resolve to an EAPI-0 eclass function, although the inheritance stack might prove problematic.) Having to die for an unsupported EAPI seems like the wrong approach; if it's not going to work the PM shouldn't source it. If it can be made to work by filtering certain functions, that's doable. In the worst case, an ebuild switching to EAPI will require eclass maintenance; this is where the separation of elibs (useful code) and eclass

Re: Baselayout-2 / OpenRC Stabilization

Doug Goldstein — 2008-10-07T14:28:23

I've been taking the time to mark legit OpenRC bugs with [OpenRC] in the subject and init script isssues with [init.d]

Re: developer profile

Steve Long — 2008-10-07T11:59:15

That seems like a clean (and simple) solution. Wooh, calm down there ;) Longer synonyms with no additional semantic data don't help anyone ime; it's already long enough (and, speaking as an end-user, typing it in does make you stop and think about what you're doing, after you stop laughing, so it does serve its purpose.) Hehe. I think just doing what you mentioned above, ie not setting it in the defaults, but allowing the user to do so at installation (or whenever) would solve it. The loud warning notice does put casual users off, and it should be enabled by default for arguably any unsupported profile. Devs will no doubt be quick to set up their own machines as and how they want; expecting a single additional config var in amongst the make.conf template isn't such a big deal, and keeps the support burden down.

Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)

Steve Long — 2008-10-07T11:46:24

++ This makes the most sense; it's simple and it enables users to interact with the appropriate channels to get support, or file bugs and patches. If a notice is needed, the website can be amended to state explicitly that upstream is dead (if the homepage points to self.)

Re: Re: "Slacking" arches - which are stable, whicharen't?

Santiago M. Mola — 2008-10-07T07:18:17

El lun, 06-10-2008 a las 23:13 +0000, Duncan escribió: I fully agree. I think bringing some understaffed arches back to ~arch is an option, but should be avoided if possible. I wonder how many of these 190 open bugs in s390 are actually bugs about brokenness, and not just regular stabilizations... And by the way, amd64 had a similar amount of open bugs by the end of 2007. Regards,

Re: Baselayout-2 / OpenRC Stabilization

Josh Saddler — 2008-10-07T06:06:33

I need everyone to take a peek at bug 213988 (http://bugs.gentoo.org/show_bug.cgi?id=213988) -- it concerns the documentation. Please add any blocker bugs for stuff that needs to be fixed in /doc/en/ and /doc/en/handbook/ -- if you know of initscript updates and the like, be sure to add your bug to this tracker bug. We do have a migration guide at http://www.gentoo.org/doc/en/openrc-migration.xml, so please review it to make sure it's accurate and complete. I seem to be the only guy working on English docs these days, so I need any changes ASAP, the better to cram 'em into the time available before stabilization.

Re: "Slacking" arches - which are stable, which aren't?

Duncan — 2008-10-06T23:13:23

Jeremy Olexa gentoo.org> posted 48EA6FF2.8020201< at >gentoo.org, excerpted below, on Mon, 06 Oct 2008 15:07:14 -0500: Having been an amd64 user back when it was much smaller, and having followed the previous discussion on this here, including the mips -> experimental move, yes, it does matter. With the bugs there's at least some info on a package and its stabilization potential when/if someone gets around to doing something about it. Without them, the job of bringing them back to unsupported and then to full supported, if there's suddenly a leap in interest, becomes much harder as there's that much less info on what /was/ stable at one point, and on anything in the ~arch versions that might need checked before they go stable again. So it matters; there's a practical reason for it. However, that's not the same as saying it's the overall best solution at this time. I have no opinion on that, particularly as I /personally/ prefer ~arch in any case.

Re: Baselayout-2 / OpenRC Stabilization

Doug Goldstein — 2008-10-06T21:04:42

I've created a branch for tracking any patches that we use that deviate from the release tarball http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=shortlog;h=refs/heads/gentoo-0.3.x

Re: Re: "Slacking" arches - which are stable, which aren't?

Jeremy Olexa — 2008-10-06T20:07:14

I wasn't trying to go down that road either but you should know that this discussion will be forced there if there is to be any conclusion to this topic. AFAIK, it is incorrect right now to exclude s390, arm, sh, etc on stablereqs right now..But, I ask this question to the dev community: "Why?" There are ~190 open bugs with s390 as assignee or on the CC list. Does it *really* matter if these under-staffed "odd" arches have a stable tree or not? If there is a problem with a stable package right now, will there be a new version marked stable in a reasonable amount of time? I think we can conclude that having a stable tree for understaffed arches might cause more harm than good. To conclude my input on the topic: It is my opinion that filing stablereqs against these arches is silly. However, I will continue to do so until requested otherwise. I respect that people may not have enough resources or time to keep up to x86 or amd64, so maybe there needs to be a policy change somehow..? (or maybe it j

Re: Baselayout-2 / OpenRC Stabilization

Petteri Räty — 2008-10-06T19:18:42

Doug Goldstein kirjoitti: That list doesn't take into consideration if init scripts don't work properly with openrc. Regards, Petteri

Baselayout-2 / OpenRC Stabilization

Doug Goldstein — 2008-10-06T18:59:30

As some people may have already noticed, I have recently added OpenRC 0.3.0 to the tree. This will be the stabilization candidate in approximately 30 days. I encourage everyone to kick the tires on this one. Current Bugs: *http://tinyurl.com/4housz*

Re: Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)

Jeroen Roovers — 2008-10-06T18:46:50

On Mon, 06 Oct 2008 19:22:14 +0200 flameeyes< at >gmail.com (Diego 'Flameeyes' Pettenò) wrote: There are two reasons against that I can think: 1) it isn't under our control. 2) related to (1), we cannot form a URL local to that site that incorporates /. A solution like rbu suggested, pointing to packages.g.o, would be preferable over an external site. Of course we could then liaise with www.unmaintained-free-software.org and post a link on packages.g.o to their site if HOMEPAGE is a reference to packages.g.o itself. :) Kind regards, JeR

Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)

Diego 'Flameeyes' Pettenò — 2008-10-06T17:22:14

What about www.unmaintained-free-software.org? Possibly opening a page?

Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)

Robert Buchholz — 2008-10-06T13:59:43

Why not use our package site for this, i.e. HOMEPAGE="http://packages.gentoo.org/package/${CAT}/${PN}" i.e. for this particular use case, http://packages.gentoo.org/package/app-mobilephone/smssend The site contains a link to ChangeLog, description, current version, forums and bugs. I would suggest it is the most usable homepage a user can expect if no other exists. Robert

Re: Re: "Slacking" arches - which are stable, which aren't?

Steev Klimaszewski — 2008-10-06T13:27:30

My aim with the email wasn't to start up this discussion so much as to figure out which arches are supported by stable keywords, and which ones are okay to not request stable keywords so that bugs don't sit around for months without action on them. I know that vapier is pretty much the only dev with an sh or s390 box, but I know there are a couple of people with ARM, I was just hoping we had some sort of official list somewhere.

Re: gentoo-x86 commit in dev-lang/python: ChangeLogpython-2.6.ebuild python-2.5.2-r6.ebuild

Ali Polatel — 2008-10-06T12:10:48

Thomas Sachau yazmış: +*python-2.6-r1 (06 Oct 2008) + + 06 Oct 2008; Ali Polatel gentoo.org> -python-2.6.ebuild, + +python-2.6-r1.ebuild: + Revbump. Use use_with for threads, remove die from econf, use emake + instead of make, remove redundant python_mod_{cleanup,optimize}. Drop old. + Thanks!

Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)

Jeroen Roovers — 2008-10-06T07:47:20

On Mon, 06 Oct 2008 08:49:04 +0200 Hans de Graaff gentoo.org> wrote: +1 http://www.gentoo.org/proj/en/abandoned/ Put that in all ebuilds for packages with no homes to go to. Then, do something very smart where the page automatically assembles a list of those packages, and explains how they have been taken under Gentoo's developers' wings. :) We could perhaps do something similar for no-herd in metadata.xml... make herds.xml actually list the no-herd herd with some kind of explanation... Kind regards, JeR

Re: Projects without a homepage, and valid contentsof HOMEPAGE (per bug 239268)

Hans de Graaff — 2008-10-06T06:49:04

I think the suggestion is to have one generic homepage for all packages without one, not a Gentoo-specific homepage for each project. 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