Re: [gentoo-dev] Re: "Slacking" arches - which are stable, which aren't?
El lun, 06-10-2008 a las 23:13 +, Duncan escribió: > Jeremy Olexa <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > excerpted below, on Mon, 06 Oct 2008 15:07:14 -0500: > > > 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? > > 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. > 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, -- Santiago Moisés Mola Jabber: [EMAIL PROTECTED] | GPG: AAD203B5 signature.asc Description: Esta parte del mensaje está firmada digitalmente
[gentoo-dev] Re: developer profile
Duncan wrote: > 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. That seems like a clean (and simple) solution. > 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. > 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.) > 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" > 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: [gentoo-dev] Baselayout-2 / OpenRC Stabilization
Petteri Räty wrote: > Doug Goldstein kirjoitti: > >> 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* >> >> > > That list doesn't take into consideration if init scripts don't work > properly with openrc. > > Regards, > Petteri > > I've been taking the time to mark legit OpenRC bugs with [OpenRC] in the subject and init script isssues with [init.d]
[gentoo-dev] Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
Robert Buchholz wrote:
> On Sunday 05 October 2008, Thilo Bangert 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/";
>
> 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.
>
++ 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.)
[gentoo-dev] Re: EAPI-2 and src_configure in eclasses
Alexis Ballier wrote: > 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. >> > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: >> 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. > 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 eclasses (template ebuilds) would be useful, although that needs versioning too.
Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
On Tue, 07 Oct 2008 17:07:21 +0100 Steve Long <[EMAIL PROTECTED]> wrote: > > 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). > > > 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. 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... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI-2 and src_configure in eclasses
Ciaran McCreesh wrote: > 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). > 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: [gentoo-dev] Changing doc use flag on gtk-doc packages to gtk-doc-rebuild or something else
On E, 2008-10-06 at 03:46 +0300, Petteri Räty wrote: > 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. 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 needed before stabilization), will be over then. Taking the renaming of the USE flag approach as a start would also mean touching many GNOME packages (build-depends on gtk-doc if eautoreconf is involved), and I'd rather not risk that at the moment. It would also heavily disrupts the moving of the new version ebuilds from overlay to portage tree. -- 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] Re: EAPI-2 and src_configure in eclasses
On Tue, Oct 07, 2008 at 05:07:21PM +0100, Steve Long wrote: > Ciaran McCreesh wrote: > > > 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). > > > 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. Actually both alternative PM's do this now (>=pkgcore-0.4.7.9), although in pkgcore's case the default phase functions are installed after sourcing rather then at the time of invocation. Long term, this is the correct way to go imo- the downside to it is that a common sourcing env needs be defined at some point (newdepend, newrdepend, etc) to avoid any question of what's available. ~brian pgplTnmKBbhpJ.pgp Description: PGP signature
Re: [gentoo-dev] Re: Testing is not a valid reason to package.mask
Ryan Hill wrote: On Thu, 2 Oct 2008 22:24:35 +0200 Jeroen Roovers<[EMAIL PROTECTED]> wrote: Please people, if you want to get something tested, then don't mask it. Um... no? One thing that package.mask has always been used for is temporarily masking a package until it can be tested and then unleashed on the general population. I think there's "testing" and "testing", and we're getting confused between the two :) The testing cycle with packages that you know will badly break something, usually involves test, patch, test, patch, etc. During which the package is masked for good reason (the reason specified in package.mask) and certain users may unmask for whatever reason (helping to test, etc). Then once you're happy to unleash it on ~arch, it still requires some amount of testing, but generally isn't "may delete all your data" testing. It's not like we're putting masked stuff in the tree with the hope that someone will find it and try it out. You mask a package, ask the user or whoever to test it, and unmask it when it's ready. We don't just throw untested stuff into the tree when we suspect problems with it. ~arch is not a playground. Already one of the major complaints we see against Gentoo time and time again is that it breaks too often and the maintenance burden is too high. Why would we want to exacerbate that? But this isn't a complaint against ~arch surely? The general feeling I get from gentoo-user when someone complains about an ~arch "production box" or "remote system" that broke, is "well, what did you expect from ~arch?" We don't /want/ ~arch systems to get "automatically widely exposed to the stuff we're intending to get tested". No, not "delete all your data" testing, but yes you do want it exposed to "may still be slightly quirky" testing. That's the whole point of masking it! We want it tested by a few people before we expose it to the unwashed masses. I would assume the unwashed masses are arch, not ~arch. If you're installing ~arch: "~arch keyword means that the application is not tested sufficiently to be put in the stable branch" [1] "We recommend that you only use the stable branch. However, if you don't care about stability this much..." [1] "The testing branch is exactly what it says - Testing. If a package is in testing, it means that the developers feel that it is functional but has not been thoroughly tested. You could very well be the first to discover a bug in the package in which case you could file a bugreport to let the developers know about it. Beware though, you might notice stability issues, imperfect package handling (for instance wrong/missing dependencies), too frequent updates (resulting in lots of building) or broken packages. If you do not know how Gentoo works and how to solve problems, we recommend that you stick with the stable and tested branch." [1] So, no, I'll continue using package.mask for testing just as it always has been. Sorry. All IMHO from a user point of view, of course. [1] Gentoo Linux x86 Handbook http://www.gentoo.org/doc/en/handbook/ cya, -- Iain Buchanan fenderberg, n.: The large glacial deposits that form on the insides of car fenders during snowstorms. -- "Sniglets", Rich Hall & Friends
