Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 276341 - gnome-do-docklets ebuild request
Summary: gnome-do-docklets ebuild request
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Low enhancement with 1 vote (vote)
Assignee: Default Assignee for New Packages
URL: http://do.davebsd.com
Whiteboard:
Keywords: EBUILD
Depends on:
Blocks:
 
Reported: 2009-07-03 08:55 UTC by Thomas Pani
Modified: 2018-01-24 08:20 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
gnome-do-docklets-0.8.2.ebuild (gnome-do-docklets-0.8.2.ebuild,935 bytes, text/plain)
2009-07-03 08:57 UTC, Thomas Pani
Details
Cleaned up docklets ebuild (gnome-do-docklets-0.8.2.ebuild,753 bytes, text/plain)
2009-07-04 11:30 UTC, Kim
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Pani 2009-07-03 08:55:58 UTC
Please provide an ebuild for the new gnome-do docklets.
Comment 1 Thomas Pani 2009-07-03 08:57:02 UTC
Created attachment 196476 [details]
gnome-do-docklets-0.8.2.ebuild

Proposed ebuild, deps may need a checking.
Comment 2 Kim 2009-07-04 11:30:06 UTC
Created attachment 196614 [details]
Cleaned up docklets ebuild

Removed some 'inheritance'.
Replaced PVC with PV.

Adding a docklets use flag to gnome-do-plugins might be nice, if/when this package gets into portage.
Comment 3 Romain Perier (RETIRED) gentoo-dev 2009-07-04 15:38:47 UTC
I dislike totally the idea to not build using parellel build, parellel builds can get things done faster.
If all emerge steps doesn't work, this ebuild can't be candidate to go into the main tree, except if someone could fix it of course.

In the worst case it could be moved into gnome overlay, waiting a clean fix.

Thomas, Kim: Don't worry this remark isn't for you, and ebuild seems to be good :)
Comment 4 Thomas Pani 2009-07-04 16:49:52 UTC
(In reply to comment #3)
> If all emerge steps doesn't work, this ebuild can't be candidate to go into the
> main tree, except if someone could fix it of course.
Huh? Sorry, but restricting to 1 make job is hardly a main tree blocker [though I totally agree fixing the build system would be preferable :) ]

% grep -R -- '-j1' /usr/portage/gnome-* | wc -l
18
Comment 5 Gilles Dartiguelongue (RETIRED) gentoo-dev 2009-07-04 18:38:27 UTC
It might be more interesting to CC current maintainer of gnome-do...

(In reply to comment #4)
> (In reply to comment #3)
> > If all emerge steps doesn't work, this ebuild can't be candidate to go into the
> > main tree, except if someone could fix it of course.
> Huh? Sorry, but restricting to 1 make job is hardly a main tree blocker [though
> I totally agree fixing the build system would be preferable :) ]
> 
> % grep -R -- '-j1' /usr/portage/gnome-* | wc -l
> 18

did you count how many ebuild are actually maintained by gnome and what percentage that actually represents of the number of ebuilds we maintain ? I'm sorry but we try hard to avoid including new ebuilds with the same non-sensical limitations.
Comment 6 Romain Perier (RETIRED) gentoo-dev 2009-07-04 19:48:46 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > If all emerge steps doesn't work, this ebuild can't be candidate to go into the
> > main tree, except if someone could fix it of course.
> Huh? Sorry, but restricting to 1 make job is hardly a main tree blocker [though
> I totally agree fixing the build system would be preferable :) ]
> 
> % grep -R -- '-j1' /usr/portage/gnome-* | wc -l
> 18
> 

Yeah but it's better when multiples make jobs work perfectly during compile or install phase, otherwises it's decrease performances.
When stuffs can be fix it's always preferable to do it, that's what I meant.
If the fix is very hard, or need a big amont of time to fix it (for example bad autotools with a big number of Makefile to fix...), I can understand...
But usually "fix are always preferable".
(And sorry but the grep isn't an argument :P)
Comment 7 Thomas Pani 2009-07-04 20:15:41 UTC
@eva: I never stated gnome was maintaining anything, I just took a random subset of the main tree, so I didn't have to grep through all of it. wranglers CC'd gnome, I should have CC'd graaff myself, sorry.
@mrpouet: I merely stated that -j1 is not blocking anything from going into gentoo-x86, however undesirable it might be.

graaff decided to put gnome-do-plugins in the tree, therefore I see no reason to leave -docklets out. I have no idea what makes parallel builds fail, but obviously neither upstream nor graaff cared to fix it. I'd therefore prefer to hear from graaff before arguing about possible non-issues.
Comment 8 Romain Perier (RETIRED) gentoo-dev 2009-07-04 21:09:54 UTC
Please note that's I just gave my opinion, I just said what I thought.
But I'm sorry a fix is still preferable when it's possible,
Graaff will be the maintainer, so he has his own rules about what's he bumps or what's he manages into the tree.
Comment 9 Hans de Graaff gentoo-dev Security 2009-07-05 06:52:44 UTC
(In reply to comment #7)
> I have no idea what makes parallel builds fail, but
> obviously neither upstream nor graaff cared to fix it. I'd therefore prefer to
> hear from graaff before arguing about possible non-issues.

Upstream clearly doesn't care. When talking with them on IRC they had zero interest in fixing this unless someone provided patches. I care about fixing it, but at the same time I also want to see progress, so I'm always balancing my efforts. Also, gnome-do and the plugins got added to the tree before repoman started to generate feedback about this. In any case I think this should be fixed.

I'll have a look at the gnome-do-docklets ebuild later.

Comment 10 Gilles Dartiguelongue (RETIRED) gentoo-dev 2014-02-18 22:49:16 UTC
Fix keywords.
Comment 11 Gilles Dartiguelongue (RETIRED) gentoo-dev 2018-01-24 08:20:57 UTC
A long time has passed and gnome-do was removed from the tree in bug #504036.

Looks like the homepage is now https://launchpad.net/do but it shows no sign of activity since 2014.

Closing wontfix.