[gentoo-dev] Last rites for sys-kernel-usermode-sources

2011-04-13 Thread Daniel Gryniewicz
# Daniel Gryniewicz d...@gentoo.org (13 Apr 2011)
# Masked for removal in 30 days. Functionality is merged into and maintained
in
# the upstream kernel.  Use any kernel (e.g. gentoo-sources) instead.
sys-kernel/usermode-sources


Daniel


Re: [gentoo-dev] Packages up for grabs: genstef gems special edition

2009-03-24 Thread Daniel Gryniewicz
On Mon, 2009-03-23 at 23:08 +0100, Peter Alfredsen wrote:
 Since genstef has been .away for some time, I arranged with him that I'd
 send a list of his ebuilds that need maintenance to be put up for grabs.
 This list contains all ebuilds that have no herd, at least one open bug
 and where genstef is the maintainer.

 net-misc/vde

I'll take this one.

Daniel




Re: [gentoo-dev] Re: bash-4.0 regression heads up (escaped semicolons in subshells)

2009-02-24 Thread Daniel Gryniewicz
On Sat, 2009-02-21 at 19:44 -0500, Mike Frysinger wrote:

snip

  
   i'll tweak the eclasses to use quoting for now

 
 no one suggested doing any of this crap you're talking about.  if you want to 
 get all retarded, dont install the masked ebuild.  i gave a heads up to 
 people 
 who might want to experiment so they wouldnt have to figure out weird errors. 
  
 in the mean time, i tweaked a few common files so people wouldnt hit errors 
 and could investigate even further.
 
 i guess in the future i simply wont post heads up so i dont have to listen to 
 people whine about non-existent issues.


I personally took the quoted line above to indicate that changes would
be made to the tree.  I can understand how confusion would occur.

Dan




Re: [gentoo-dev] Proposal: disable python and perl USE flags in profile

2008-12-09 Thread Daniel Gryniewicz
On Tue, 2008-12-09 at 04:09 +0200, Petteri Räty wrote:
 Maciej Mrozowski wrote:
  Following advise from https://bugs.gentoo.org/show_bug.cgi?id=250179, I'm 
  bringing it here.
  
 
 I think this is probably a good idea after EAPI 2 is stable and we
 eliminate built_with_use usage from the tree. I think having stuff build
 out of the box instead of dying in the middle of emerge outweighs
 pulling in some extra stuff with default settings.
 
 Regards,
 Petteri
 

+1

Daniel




Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds

2008-11-18 Thread Daniel Gryniewicz
On Mon, 2008-11-17 at 19:08 -0600, Ryan Hill wrote:
 On Mon, 17 Nov 2008 10:10:57 -0500
 Daniel Gryniewicz [EMAIL PROTECTED] wrote:
 
  On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote:
  
  snip
  
   The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the
   latest stable ebuild of an arch without the approval of the arch
   team or he/she will be fed to the Galrog.
  
  As long as the maintainer can pass off the maintenance of the
  (sometimes dozens) of ancient ebuilds that need to be kept around for
  that one arch to the arch team, and re-assign any resulting bugs to
  them, fine.
 
 Since when do we maintain ancient ebuilds kept around for an arch
 team now?  Drop the other keywords and get on with your life.

Since forever, at least in my experience.  See below.

 
 Did you not read the first part of the suggestion?  

Yes.  I was not objecting to this sequence.  I was objecting to the
MUST NOT NEVER EVER NOT EVEN A LITTLE BIT part.

 
 - maintainer files a stabilization request.
 - arch testers do their thing
 - arch teams gradually mark ebuild stable
 - maintainer pokes arm, sh, mips, ppc (only an example, relax)
 - mips reminds maintainer there is no stable mips keyword
 - ppc stables
 - maintainer waits
 - maintainer pokes arm, sh
 - maintainer waits
 - maintainer marks stable on arm, sh
 - maintainer removes ancient stable ebuilds that maintainer doesn't
   want to maintain anymore because everyone has a nice new stable
   ebuild.
 - maintainer goes out for a frosty beverage

- Arch team comes back and says the new version doesn't work.
- Maintainer is stuck maintaining the old version *forever*, at least
potentially.

Concrete example.  Gnome was keyworded on an arch.  A new version of
gnome came out that needed hal.  Hal did not work on said arch.  For a
long long time, we had to keep a very old version of gnome in the tree,
just for that arch.  This was a maintenance burden.  Gnome is not just
one or 2 packages.

 
 the idea is that arch teams are around to help the maintainer test on
 architectures the maintainer doesn't have.  if the arch teams are
 unable or unwilling to help at the moment, that should not stop the
 maintainer from maintaining.
 
 also keep in mind that this only occurs after the arch teams have ample
 time to interject (which is why i suggested 90 days).  if an arch team
 can't comment on a bug in 3 months (a simple i'd rather this not go
 stable until i can test it further should be enough) then they have
 IMO lost their opportunity to matter.

This is not about arches just being slackers.  This is about arches
denying stable (or even ~) for some reason.  If I cannot drop an old
version of something just because the new version doesn't (and won't)
work on an arch, that's really bad for me.

Daniel




Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds

2008-11-18 Thread Daniel Gryniewicz
On Tue, 2008-11-18 at 17:50 +, Ciaran McCreesh wrote:
 On Tue, 18 Nov 2008 11:57:23 -0500
 Daniel Gryniewicz [EMAIL PROTECTED] wrote:
  This is not about arches just being slackers.  This is about arches
  denying stable (or even ~) for some reason.  If I cannot drop an old
  version of something just because the new version doesn't (and won't)
  work on an arch, that's really bad for me.
 
 What is the cost of keeping it there and not changing it?
 

Assuming no one ever uses it?  Just some sync bandwidth, emerge think
time, and disk space.  Not a lot.  However, if people use it, and
especially if they manage to get mixed versions of gnome with it (or new
versions of apps built against it), then we get lots of bugs about it.
Generally, we tend to get lots of interaction bugs about old versions of
gnome.  That's why we try to remove them.

One of the biggest problems is packages not having the correct upstream
deps, since upstream and most distros have moved on to new versions of
gnome.  There's no way we can catch those (since we, too, have moved on
to new versions) and users find them and report them.  Most users I've
encountered don't do --deep upgrades, ever.

I suppose a possible solution would be to de-keyword all those old
versions for all other arches.  That would reduce such reported bugs to
users of the arch in question.  It still leaves something unmaintained
(and probably unmaintainable, except maybe on the target arch) in the
tree marked as stable.  That's a bad thing in-and-of itself.

Daniel




Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds

2008-11-18 Thread Daniel Gryniewicz
On Tue, 2008-11-18 at 15:18 -0600, Ryan Hill wrote:
 On Tue, 18 Nov 2008 11:57:23 -0500
 Daniel Gryniewicz [EMAIL PROTECTED] wrote:
 
  On Mon, 2008-11-17 at 19:08 -0600, Ryan Hill wrote:
   On Mon, 17 Nov 2008 10:10:57 -0500
   Daniel Gryniewicz [EMAIL PROTECTED] wrote:
   
On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote:

snip

 The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove
 the latest stable ebuild of an arch without the approval of the
 arch team or he/she will be fed to the Galrog.

As long as the maintainer can pass off the maintenance of the
(sometimes dozens) of ancient ebuilds that need to be kept around
for that one arch to the arch team, and re-assign any resulting
bugs to them, fine.
   
   Since when do we maintain ancient ebuilds kept around for an arch
   team now?  Drop the other keywords and get on with your life.
  
  Since forever, at least in my experience.  See below.
  
   
   Did you not read the first part of the suggestion?  
  
  Yes.  I was not objecting to this sequence.  I was objecting to the
  MUST NOT NEVER EVER NOT EVEN A LITTLE BIT part.
  
   
   - maintainer files a stabilization request.
   - arch testers do their thing
   - arch teams gradually mark ebuild stable
   - maintainer pokes arm, sh, mips, ppc (only an example, relax)
   - mips reminds maintainer there is no stable mips keyword
   - ppc stables
   - maintainer waits
   - maintainer pokes arm, sh
   - maintainer waits
   - maintainer marks stable on arm, sh
   - maintainer removes ancient stable ebuilds that maintainer doesn't
 want to maintain anymore because everyone has a nice new stable
 ebuild.
   - maintainer goes out for a frosty beverage
  
  - Arch team comes back and says the new version doesn't work.
  - Maintainer is stuck maintaining the old version *forever*, at least
  potentially.
 
 See, here's your problem.  If the arch team has issues and needs an
 old ebuild, the arch team is effectively the maintainer of that
 ebuild.  Drop the other keywords if you like, and forget it exists.

Leaving unmaintained ebuilds in the tree.  If that's what people want,
that's fine with me.

 
  Concrete example.  Gnome was keyworded on an arch.  A new version of
  gnome came out that needed hal.  Hal did not work on said arch.  For a
  long long time, we had to keep a very old version of gnome in the
  tree, just for that arch.  This was a maintenance burden.  Gnome is
  not just one or 2 packages.
 
 So you would rather have the ability to just drop the keywords on
 this arch and leave them and their gnome users up the creek?

No.  But I also don't want any policy that forbids me from ever removing
that ebuild.  Which is what the above is proposing.  I don't want any
kind of absolutes in policy.  If you advocate absolutes in favor of the
arch teams to the detriment of the maintainers, then the maintainers are
going to ask for absolutes (such as I asked for above) in retaliation,
and we'll have a thermonuclear meltdown.  That's all.

Honestly, I don't want to be a dick to the arch teams.  I really don't.
But I *also* don't want them (or policy) to be a dick to me.  That's my
whole point; that requirement of never removing the last stable ebuild,
in shouting caps no less, is way too absolute, and is just going to piss
people like me off.

I think the whole policy should be more-or-less Don't be a dick.  Take
the other guy into account.  Leave shouting-caps absolute requirements
out of it.

(For what it's worth, with my arch team hat on, I'm not in favor of
letting anyone mark things stable on arches they can't test on.  But
that's a much lesser issue IMO than absolute prohibitions on removing
ebuilds.)

Daniel




Re: [gentoo-dev] zeroconf/avahi USE flag

2008-11-04 Thread Daniel Gryniewicz
On Tue, 2008-11-04 at 15:44 -0500, Doug Goldstein wrote:

snip

 bonjour is Apple specific branding for zeroconf. This is another case
 that needs to be changed.
 
 zeroconf/avahi/howl/bonjour/mdnsresponder all need to be condensed.
 

I agree.  Let's just have zeroconf.

Daniel




[gentoo-dev] Last rites for dev-cpp/{libbonobomm,libbonobouimm}

2007-06-19 Thread Daniel Gryniewicz
Nothing in the tree depends on the, they don't currently build, and the
last upstream release was 2003.

Daniel

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Last rites for dev-cpp/{libbonobomm,libbonobouimm}

2007-06-19 Thread Daniel Gryniewicz
On Tue, 2007-06-19 at 21:20 -0400, Daniel Gryniewicz wrote:
 Nothing in the tree depends on the, they don't currently build, and the
 last upstream release was 2003.
 
 Daniel
 

Forgot: scheduled to be removed Jul 19; bug #182612

Daniel

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] QA issue: No stable skype in Tree

2007-06-13 Thread Daniel Gryniewicz
On Wed, 2007-06-13 at 17:36 +0100, Gustavo Felisberto wrote:
 A little background info: Right now there are three versions of
 net-im/skype in the tree:
 
 1 - the 1.2 series (with a stable version)
 2- the 1.3 series also with a stable version
 3- the 1.4 series with a ~/hardmask version
 
 Also the skype license states that we cannot mirror it's files (this
 will be need later)
 
 The 1.4 series will have a version released soon that skype wants to
 become the standard stable version, it has many new features and better
 audio quality.
 
snip
 Suggestions:
 1- in the 19th remove skype  1.4 from the tree
 2- Make  1.4 ebuilds empty and leave them on the tree and ewarn the
 users to use the unstable skype
 
 
 The first option will trigger portage errors and prompt users to open
 bugs until we have a stable 1.4, the second gives us a chance to explain
 the issue.
 
 Any alternatives?
 

3. Mask  1.4 on the 19th with a descriptive message.  That should have
the effect of 1 and 2, without breaking anything necessarily?

Sounds like we have a lose-lose situation here, and the best we can do
is make it not horrible.

Daniel

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] New global use flag, xulrunner

2007-06-06 Thread Daniel Gryniewicz
On Wed, 2007-06-06 at 17:44 +0300, Samuli Suominen wrote:
 use.local.desc:dev-java/swt:xulrunner - Build native browser integration 
 against xulrunner
 use.local.desc:dev-python/gnome-python-extras:xulrunner - Enable support for 
 xulrunner instead of firefox
 use.local.desc:dev-util/devhelp:xulrunner - Enable support for xulrunner 
 instead of firefox
 use.local.desc:gnome-extra/yelp:xulrunner - Enable support for xulrunner 
 instead of firefox
 use.local.desc:media-video/totem:xulrunner - Enable support for xulrunner 
 instead of firefox
 use.local.desc:net-news/liferea:xulrunner - Enable xulrunner as renderer in 
 liferea
 use.local.desc:www-client/epiphany-extensions:xulrunner - Enable support for 
 xulrunner instead of firefox
 use.local.desc:www-client/epiphany:xulrunner - Enable support for xulrunner 
 instead of firefox
 
 List is likely to grow in future.
 
 Any objections?
 
 - Samuli Suominen

++ from gnome

Daniel

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: stabilizing expat 2.0.0

2007-05-19 Thread Daniel Gryniewicz
On Fri, 2007-05-18 at 23:33 +0200, Christian Faulhammer wrote:
 Steve Long [EMAIL PROTECTED]:
 
  Carsten Lohrke wrote:
   the amd64 team is unresponsive on even trivial stabilisation
   request form the KDE team as well, lately.
  
  welp's been away ;)
 
  welp does not touch KDE packages...
 

More importantly, I don't think anyone currently active on amd64 does
touch KDE packages.   Looking at changelogs, kugelfang is active (but
not stabling amd64, it seems); wolf31o2 and cryos are away; lanius,
absinthe, and jhuebel are no longer on amd64; that leaves malc, who
hasn't done anything kde related since 2004, as far as I can see.

I suspect the kde team and the amd64 team need to get together to find
someone who can test KDE on amd64.

Daniel

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Last rite app-misc/baobab

2007-05-03 Thread Daniel Gryniewicz
 
+# Daniel Gryniewicz [EMAIL PROTECTED] (3 May 2007)
+# It's now part of gnome-utils; bug #176864
+app-misc/baobab

Scheduled for removal June 2 2007

Daniel

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] tests

2007-05-01 Thread Daniel Gryniewicz
On Tue, 2007-05-01 at 15:08 +0200, Piotr Jaroszyński wrote:
 Hello,
 
 There was some discussion about forcing/not forcing tests in EAPI-1, but 
 there 
 was clearly no compromise. Imho, tests are very important and thus I want to 
 discuss them a little more, but in more sensible fashion.
 
 Firstly each test can be(not all categories are mutually exclusive):
 - not existant
 - non-functional
 - not runnable from ebuild
 - useful but unreasonable resource-wise
 - useful and reasonable resource-wise
 - necessary
 - known to partially fail but with a way of skipping failing tests
 - known to partially fail but with no easy way of skipping failing tests
 Is that list comprehensive?
 
 Secondly we must answer the question how precisely we want to distinguish 
 them, so users/dev can choose which categories of tests they want to run. 
 What comes to mind is:
 - run all tests
 - run only necessary tests
 - run only reasonable tests
 - don't run tests at all
 Again, is that list comprehensive?
 

Don't forget tests that have heavy requirements to run.  Many gnome
tests, for example, need a virtual X to run, which puts a new set of
DEPENDS requirements on your system.

Daniel

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] tests

2007-05-01 Thread Daniel Gryniewicz
On Wed, 2007-05-02 at 01:32 +0200, Marius Mauch wrote:

 
 I'd approach it a bit different: Before creating fixed classification
 groups I'd first identify the attributes of tests that should be used
 for those classifications.
 a) cost (in terms of runtime, resource usage, additional deps)
 b) effectiveness (does a failing/working test mean the package is
 broken/working?)
 c) importance (is there a realistic chance for the test to be useful?)
 d) correctness (does the test match the implementation? overlaps a bit
 with effectiveness)
 e) others?

There is one serious problem with this:  Who's going to do the work to
figure all this out for the 11,000 odd packages in the tree?  This seems
like a *huge* amount of work, work that I have no plan on doing for the
100-odd packages I (help) maintain, let alone the 4-10 different
versions of each package.  I highly doubt other maintainers want to do
this kind of work either.

Daniel

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] tests

2007-05-01 Thread Daniel Gryniewicz
On Wed, 2007-05-02 at 01:12 +0100, Stephen Bennett wrote:
 On Tue, 01 May 2007 19:46:56 -0400
 Daniel Gryniewicz [EMAIL PROTECTED] wrote:
 
  There is one serious problem with this:  Who's going to do the work to
  figure all this out for the 11,000 odd packages in the tree?  This
  seems like a *huge* amount of work, work that I have no plan on doing
  for the 100-odd packages I (help) maintain, let alone the 4-10
  different versions of each package.  I highly doubt other maintainers
  want to do this kind of work either.
 
 Last I heard the intention was to tie it to the EAPI=1 bump, so that
 packages can be updated one by one as they move to the newer eapi.
 Current (ie EAPI=0) ebuilds will continue to function as they have done.

Sure, but now you're requiring me to go through all that extra work if I
want any of the benefits of EAPI=1.  Or alternatively, dooming us to
support EAPI=0 forever, since I don't want to do that work.  Or, third
option, is that everyone marks their packages as low priority tests,
don't run them just to switch to EAPI=1, and we have no gain over what
we have now.

Honestly, tests are nice, but too many of them are broken upstream, and
we are not (and should not be, IMO) in the position of fixing them all.
If a developer wants to work with her upstream to fix the tests in her
packages, great and more power to her.  Most of us are swamped just
supporting them, let alone fixing test cases.  You really need an
upstream who cares a lot about tests for the tests to be meaningful and
work.  Lots of upstreams don't currently care, and have inherited
obsolete and (now) broken tests from previous maintainers.

I think this thread in general overestimates the value of tests in
packages.  I think we will find, if we go through the effort, that more
of them are useless and/or broken than are useful.  My 2 cents.

Daniel

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] That time again...

2007-04-27 Thread Daniel Gryniewicz
On Wed, 2007-04-25 at 20:12 -0400, Michael Cummings wrote:
 Any other cool updates in the last few weeks? (it's been 20 days since
 the last time I started this thread - at this rate, we might make enough input
 to make Chris' job on the gwn easier).
 

For Gnome, 2.18.1 is almost entirely in the tree, but still masked
pending the unmasking of hal (which has one bug left, last I checked).
2.19.1 is going into the overlay slowly.

Daniel

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] forwarding a video

2007-03-05 Thread Daniel Gryniewicz
On Mon, 2007-03-05 at 12:18 +0100, Marijn Schouten (hkBst) wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Mike Frysinger wrote:
  no, i'm not directing this at any one person as i dont believe singling out 
  any one person addresses anything in our case
  
  a video sent to out by a good mate
  http://video.google.com/videoplay?docid=-4216011961522818645
  -mike
 
 what a nice flash website,
 

If you'd bothered to look, there's a nice download link on the right
that downloads as an avi.  You don't even need flash installed.  All you
need to do is get past the tagging of the download as being for
Windows/Mac.

Daniel

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: What do you think about removing gtk-1.2 theme engines from tree?

2007-02-26 Thread Daniel Gryniewicz
On Sun, 2007-02-25 at 21:31 -0600, Ryan Hill wrote:
 Andrej Kacian wrote:
  It makes sense slowly removing *applications* depending on gtk1. Themes 
  should
  go last, along with gtk1 itself.
  
  Gtk1 is already ugly enough, do you want it to be even more ugly?
 
 Point, set, and match.
 

Much as I hate gtk1, I agree with this.  Leave the themes as long as
they're working and there's apps.

Daniel

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] let's clear things up (was Slacker archs)

2007-02-20 Thread Daniel Gryniewicz
On Tue, 2007-02-20 at 08:11 -0500, Stephen P. Becker wrote:
 On Tue, 20 Feb 2007 01:35:32 +
 Ciaran McCreesh [EMAIL PROTECTED] wrote:
 
  It is widely perceived that Gentoo has a huge problem with slacker
  archs cluttering up the tree and making maintainers' work harder.
  Clearly, something needs to be done about this.
 
 snip
 
 Wow, I almost don't know where to begin.  The amount of FUD,
 misinformation, and outright lies floating around all of this bullshit
 is astounding. 

snip again

I'd like to chime in here, if I may, with some personal experience.
I've been involved with arch keywording from both sides (being in the
amd64 herd, and being the current gnome lead), and I have to say that
it's definitely blown out of proportion.  Yes, keyword bugs slip through
the cracks.  Some of my gnome keyword bugs hang around forever;
sometimes, in my bug sweeps for amd64, I find keyword bugs that have
been hanging around forever.  It happens.  However, there have been a
number of cases recently for gnome where we wanted to punt old versions
of gnome.  We like to only keep 1-2 old versions around, so we remove
whole sets of packages every 6-8 months.  In this, we're probably close
to unique.  Many of these are newest keyworded versions on some arch or
other.  Generally, all the arches have been responsive to the problem,
either by keywording newer versions, or by agreeing to drop keywords.
Again, there's the odd case; but that seems to mostly be oversight.

Summary: I don't see a real problem with any arch, mips included, either
from the arch side or from the gnome side.  There's more gnome cruft in
the tree from us failing to clean intermediate versions up than there is
from slacker arches.

Daniel

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GNOME 1.x and GNOME 1.x dependent package masking

2006-11-14 Thread Daniel Gryniewicz
On Sat, 2006-11-11 at 22:55 +0200, Alin Nastac wrote:
 Paul de Vrieze wrote:
  On Friday 10 November 2006 16:28, Daniel Gryniewicz wrote:

  On Fri, 2006-11-10 at 08:56 +0100, Marius Mauch wrote:
  
  Ok, the list definitely isn't accurate. If there is a legitimate reason
  to mask sylpheed-claws-1.x you also have to mask it's reverse deps.
  However I'm still waiting for the explanation why it is on that list.
  (I don't mind if it's masked for a good reason, but I need to know
  that reason).

  There is no immediate reason, of course.  However, gtk+-1 and glib-1
  will be removed as soon after the big cleanup as is feasible, and
  sylpheed-clasws-1.x is a gtk+-1 app, and therefore must go as well.  I
  didn't generate the list, but my understanding was that it was intended
  to include all packages with a hard dep on gtk+-1, in addition to gnome
  1.x.
  
 
  Gtk1 actually is broken for --as-needed. It's linking is broken thanks to a 
  libtool which refuses to link against a non-installed libgdk.
 

 I think gtk+-1.2.10-r12 solved this problem.
 
 Hope you guys aren't seriously considering dropping gtk+1. As long as we
 have packages that depend on it (packages that has nothing to do with
 gnome herd/team), gtk+1 should stay in the tree.
 

We (gnome) are not going to maintain gtk+-1.  We would very much prefer
it get removed.  If some other person or group wants to maintain it, I
guess it's fine with me; it will only cause Jakub and company headaches
for re-assigning all the bugs that mistakenly get assigned to gnome.

Note that maintaining it basically means being upstream, as there is no
upstream for it.

Daniel


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] GNOME 1.x and GNOME 1.x dependent package masking

2006-11-10 Thread Daniel Gryniewicz
On Fri, 2006-11-10 at 08:56 +0100, Marius Mauch wrote:

 Ok, the list definitely isn't accurate. If there is a legitimate reason
 to mask sylpheed-claws-1.x you also have to mask it's reverse deps.
 However I'm still waiting for the explanation why it is on that list.
 (I don't mind if it's masked for a good reason, but I need to know
 that reason).
 

There is no immediate reason, of course.  However, gtk+-1 and glib-1
will be removed as soon after the big cleanup as is feasible, and
sylpheed-clasws-1.x is a gtk+-1 app, and therefore must go as well.  I
didn't generate the list, but my understanding was that it was intended
to include all packages with a hard dep on gtk+-1, in addition to gnome
1.x.

Daniel


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] GeNUS : how I currently manage my gentoo network (200+ machines)

2006-10-23 Thread Daniel Gryniewicz
On Sat, 2006-10-21 at 08:22 +0200, Hubert Mercier wrote:
 Hi,
 
 When I recently officially joined the Gentoo Project, I had the idea 
 to share a part of my work, in the way of a scripts set I've been 
 working on for more than 2 years now, which I called GeNUS (Gentoo 
 Network Update System).
 

snip

Sounds really useful here at work, where we run a lab of test boxes
running Gentoo.  Got a link?

Daniel


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Orphaned packages

2006-09-18 Thread Daniel Gryniewicz
On Mon, 2006-09-18 at 20:00 +0100, Gustavo Felisberto wrote:
 The list of orphans is:
 

 net-misc/blogtk

I'll take blogtk.

Daniel


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection

2006-09-13 Thread Daniel Gryniewicz
On Wed, 2006-09-13 at 19:47 +0200, Benno Schulenberg wrote:
 Ciaran McCreesh wrote:
  * If no existing file with the intended target name exists, or if 
the existing file has identical content to the file to be 
installed, the file to be installed is installed as normal.
 
 I would much prefer new files to be treated as if replacing an 
 existing zero length file.  When something is installed into /etc, 
 etc-update should alert me to this, because logically speaking a 
 new configuration file is a big configuration change.
 
 Ideally the package manager would unconditionally respect the config 
 protection area, and it should be up to tools like etc-update to 
 (configurably) automerge new files and identical files, just like 
 it can be configured to automerge trivial/comment changes.
 

I disagree.  If there is a sane default configuration for something
(which is most things), I want it installed, so it works out of the box.
I don't want to have to fiddle with config files to get sshd up and
running.

Obviously, if there's no sane default configuration (samba?), then the
installed configuration shouldn't do anything.

Daniel


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

2006-07-30 Thread Daniel Gryniewicz
On Sun, 2006-07-30 at 15:50 +0200, Paul de Vrieze wrote:
 On Friday 28 July 2006 20:51, Donnie Berkholz wrote:
  Robert Cernansky wrote:
   If I have some application that is not included in portage why
   I decide to make an ebuild? Because I hope that then it will be
   accepted and included to portage, so maintained by developers (big
   thanks for this). If I have to take care of package + ebuild +
   dependencies, I'll rather choose not to make an ebulid but compile
   package right from .tar.gz archive.
 
  Many people disagree with you here, that's why overlays exist. Somebody
  wants to use Portage to manage ebuilds that aren't yet in the actual tree.
 
 I'm one of those. Portage namely is also a package manager allowing what 
 using 
 the tarbal method does not: file tracking and deinstallation.
 
 Paul

FWIW, my company uses Gentoo and overlays extensively to manage our
workstations and testbeds.  The packages we have are not suitable for
inclusion in portage (for a number of reasons), and we have no intention
of ever submitting them.

Overlays are a *great* way of customizing a local network of boxes to be
different than upstream Gentoo for whatever reason.  I, personally, find
this to be a more useful function than a place to hold ebuilds not-yet
in portage (although, I do that also).

-- 
Daniel Gryniewicz
Gentoo AMD64 Team / Gentoo Gnome Herd / Gentoo Kernel Herd / Gentoo Printing 
Herd
AMD64 Operational AT Lead


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Off with your heads!

2006-07-09 Thread Daniel Gryniewicz
On Thu, 2006-07-06 at 20:46 -0600, Steve Dibb wrote:
 @devs,
 
 If your blog is being aggregated on Planet Gentoo / Universe, it's time to 
 send 
 us a copy of your smiling face.  I'm putting out a request for some 
 hackergotchis.  Really, you don't want just a few of us to have all the fun, 
 do you?
 

Here's mine.

Daniel


dang.png
Description: PNG image


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Virtualization Herd

2006-07-03 Thread Daniel Gryniewicz
On Mon, 2006-07-03 at 22:28 +0200, Benedikt Böhm wrote:
 On Monday 03 July 2006 21:56, Nick Devito wrote:
  Okay, in that case, extend the vserver herd to include a larger range of
  virtualization stuff, including Xen, Bochs, and so on. It just seems
  more fitting to group those packages together.
 
 not really, bochs, qemu and vmware is emulation, merely used in 
 virtualization 
 environments
 
 uml and xen do run with VMMs and don't share anything with 
 OpenVZ/Linux-VServer
 
 uml and xen could be integrated into the VPS project (with a different herd) 
 but i don't know what their maintainers are thinking about this

UML is not complicated or hard to maintain.  I'm fairly happy
maintaining it with the help of the kernel herd, and (being a linux
kernel port) I think it really belongs in kernel, not in virtualization
or vmm or vserver, or whatever.

Maybe if there were some projects for full virtual server setups that
could use xen or uml or vmware or ... as it's underlying hosting
service, that could be useful, but just for maintenance, I don't think
it's really necessary.

I'm open to arguments in favor of such a project, tho, if people have
real plans.  Certainly, an easier way to generate and maintain root
filesystems for UML would be nice.

Daniel


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Virtualization Herd

2006-07-03 Thread Daniel Gryniewicz
On Mon, 2006-07-03 at 20:15 -0600, Nick Devito wrote:
 Generating root filesystems for UML and Xen are basically the same
 process. I've heard of domi, but, bleh, I never could get it to work. I
 usually just make my images in chroot, and that usually works well. But,
 since the images are *basically* the same, that means it would be
 possible to use the jailtime images, unless you are running on a 64-bit
 arch. Then, in that case, least with gentoo, running a 64-bit kernel and
 32-bit userland doesn't work for long (first glibc (re)compile, and the
 whole thing borks out).

I'm on amd64, as my primary arch.  I generally use a chroot, as well,
and have knocked up some scripts to help me, but a well-designed package
to do it would be very helpful.  Maybe I'll write one...

Several patches just went into -mm to make UML work well as a 32-bit
process on 64-bit arches, which would make the root image a pure 32-bit
image.

Daniel


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] sys-kernel/usermode-sources facing removal

2006-05-07 Thread Daniel Gryniewicz
On Sun, 2006-05-07 at 14:40 +0100, Daniel Drake wrote:
 Hi,
 
 I've been wrangling with usermode-sources maintenance for some time now, 
 but I don't have any interest in it and have no clue how it works.
 
 Any volunteers?
 
 If not, this package will be removed in 30 days. It will be put in 
 package.mask sometime over the next day or two due to the open security 
 bugs.
 

I'll take it over.  I'm a UML user, both personally and for work. 

Daniel


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Re: shoving utils from xpdf to poppler...

2005-12-28 Thread Daniel Gryniewicz
On Wed, 2005-12-28 at 17:18 +0100, Carsten Lohrke wrote:
 Hi Daniel, 
 
 what you've done breaks runtime dependencies, if not for other packages so at 
 least for KDE. Such a change should be announced on the gentoo-dev mailing 
 list before you do it. Also a tracking bug to coordinate stabilization of new 
 ebuild revisions will be needed, once the changed ebuilds go stable. Moreover 
 you're not free to put a 200k patch into cvs, 20k is the accepted maximum.
 

It's not supposed to break runtime dependencies.  Everything that was
installed before is installed now, in the same location.  I therefore
didn't feel it should case problems and that it wouldn't require
coordination.  Could you please elaborate, possibly with a bug?

I'll fix the patch.  I didn't see repoman complain, but I may have just
missed it.  Sorry about that.

Daniel


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Moving GCC-3.4 to stable on x86

2005-11-28 Thread Daniel Gryniewicz
On Mon, 2005-11-28 at 19:12 +0100, Bjarke Istrup Pedersen wrote:

 
 Does this mean that we can get rid of the libstd++ dependency of gcc,
 and move it to the binary packages that depends on gcc 3.3 .
 I know this has been discussed before, but once it's stable I see no
 reason to keep the dependency in the gcc ebuild, when it could be in the
 binary packages.
 

Well, right after the upgrade, there will still be tons of non-binary
programs built against the old libstdc++, so no.  Unless you want to
force everyone to emerge -e world after the upgrade (which will make you
very unpopular).

Daniel


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] app-admin/gwcc being removed

2005-11-01 Thread Daniel Gryniewicz
On Thu, 2005-09-22 at 16:33 -0400, Daniel Gryniewicz wrote:
 Hi, all.
 
 app-admin/gwcc has security issues, and has been unmaintained upstream
 for 3 years.  The Gnome herd is no longer interested in maintaining it.
 I've masked it, and will remove it in a couple of weeks, if no one steps
 forward to maintain it.
 
 Daniel
 

Last call for gwcc.  If no one steps up, I'll remove it in the next
couple of days.

Daniel

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

2005-09-12 Thread Daniel Gryniewicz
On Mon, 2005-09-12 at 19:53 -0400, Stephen P. Becker wrote:
 Let me clarify here.  I'm not concerned about ATs having more privileges
 at all.  I just want to know why if we're making them full developers
 for all intents and purposes, we don't go the extra step and get them
 commit access after a probationary period?  It seems like this is
 supposed to be the end goal anyway.  Basically, I feel like this GLEP
 goes outside the bounds of what I think of when somebody mentions the
 arch testers.  Maybe it's just me though.
 
 -Steve
  
  
  For once agreeing with Ciaran, the less people who aren't seasoned
  developers with commit access the better?  Some don't want commit
  access, most of them really don't need it.  Those that want it can ask
  for it and take any requisite quizzes.
 
 You also have misunderstood my point.  I've always been under the 
 impression that ATs are regarded highly enough that they could easily 
 become members of the dev team.  With that in mind, *if* we are going to 
 give them nearly every privilege an arch dev has anyway, why not go one 
 step further and just make them an official arch dev and avoid 
 unnecessary bloating of categories with respect to Gentoo dev-team 
 membership?  They don't even need commit access if they don't want it. 
 We currently have developers without tree access already in any case. 
 Should we reclassify those folks as well?

You're somehow implying that being an AT is not as good as being a dev.
My understanding is that this GLEP is supposed to make AT as good as
being a dev, but with a different role, one that doesn't need commit
access.  If the people involved decide they want to become committing
devs, it also make it easier to make that transition.  If they don't
want to commit, they can stay as an AT.

 Besides, if you want to get technical, our entire userbase are arch 
 testers to some extent.  They run Gentoo, report bugs, unmask packages 
 locally, submit keywording requests to bugzilla, etc.  The good users 
 make Gentoo a good distribution by providing feedback on bugzilla.  The 
 very best of these folks are typically tapped for membership in arch teams.

I agree.  What the AT program has done for amd64, tho, is give us a base
of users that have known skills (they were recruited and passed the
ebuild quiz) and have a known process they follow for testing and
marking bugs, so that the devs have a much easier time staying on top of
keywording issues.  We've basically said that we trust the ATs to know
how to test a package, and we'll take their word for it that it works.
It's been very useful for us, and we think it will be useful for others.

Daniel
(former AT)

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff

2005-09-12 Thread Daniel Gryniewicz
On Tue, 2005-09-13 at 00:05 +0100, Daniel Drake wrote:
 Simon Stelling wrote:
  This has been in the todo-list for quite a while, but finally it's done. 
  I'm curious what you think of it.
 
 I'm curious how much change this would involve for the people involved.
 
 Perhaps you could explain how the current system works (I presume from 
 reading 
 the GLEP that they _don't_ currently have commit access and havent taken any 
 quizzes)? How do they get their keywording work into the tree?
 
 Thanks,
 Daniel

They don't have commit access (or any CVS access at all) but have taken
the ebuild quiz, the first dev quiz.  They have the ability to KEYWORD
bugs in bugzilla, that the only special ability they get (other than
voice in #-amd64-dev) currently.

Daniel
(former AT)

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] combining x86 and amd64

2005-09-01 Thread Daniel Gryniewicz
On Thu, 2005-09-01 at 12:10 -0500, Grant Goodyear wrote:
 The recent discussion about having a real x86 arch team and combining
 the x86 and amd64 keywords was both interesting and provocative.  Of
 course, this is the sort of thing that the GLEP system was meant for.
 Now that we have a new council that (I hope) will be active in approving
 or rejecting GLEPs, perhaps someone should be writing a GLEP about
 combining x86 and amd64?
 
 -g2boojum-

Just out of curiousity, what makes people think that the amd64 team will
sit still for having all of x86 foisted off on them?
-- 
Daniel Gryniewicz
Gentoo AMD64 Team

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New Developer: dang

2005-05-22 Thread Daniel Gryniewicz
On Sun, 2005-05-22 at 09:59 -0500, Homer Parker wrote:
 On Sun, 2005-05-22 at 00:57 -0500, Jason Huebel wrote:
  It's with pleasure that I announce a new developer: Dang.  Dang has been 
  working as an Arch Tester for AMD64 for a while now and has proven 
  himself 
  to be an asset to the team.  So we felt it would be good to officially make 
  him a developer.  He'll be helping with amd64 bug squashing of course, 
  along 
  with helping out the gnome herd.
  
  Welcome dang!
  
 
   /me needs to recruit more ATs... But, that's ok.. Congratz Dan!!!
 

Thanks, all. (And yes, I've heard all the jokes before... :) )

Daniel

-- 
gentoo-dev@gentoo.org mailing list