Re: [gentoo-dev] Baselayout-2 / OpenRC Stabilization

2008-10-07 Thread Josh Saddler
Doug Goldstein wrote:
 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*
 

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.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Slacking arches - which are stable, which aren't?

2008-10-07 Thread Santiago M. Mola
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

2008-10-07 Thread Steve Long
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

2008-10-07 Thread Doug Goldstein
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)

2008-10-07 Thread Steve Long
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

2008-10-07 Thread Steve Long
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

2008-10-07 Thread Ciaran McCreesh
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

2008-10-07 Thread Steve Long
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

2008-10-07 Thread Mart Raudsepp
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

2008-10-07 Thread Brian Harring
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

2008-10-07 Thread Iain Buchanan

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 iaindb at netspace dot net dot au

fenderberg, n.:
The large glacial deposits that form on the insides
of car fenders during snowstorms.
-- Sniglets, Rich Hall  Friends