I think a better solution, if we need to indicate this, is to have
bugzilla grab the status from devaway and display it next to the dev's
name in bug reports. Changing the user's name seems a bit cumbersome,
and I don't agree that people will know what devaway means - i.e.
they may not even
El jue, 10-06-2010 a las 12:23 -0600, Joe Peterson escribió:
I think a better solution, if we need to indicate this, is to have
bugzilla grab the status from devaway and display it next to the dev's
name in bug reports. Changing the user's name seems a bit cumbersome,
and I don't agree that
On 06/10/2010 07:07 PM, Pacho Ramos wrote:
Hello
Currently, we only need to set a proper message in ~/.away (as talked in
http://www.gentoo.org/proj/en/devrel/roll-call/devaway.xml ) when
becoming devaway. The problem is that a lot of our users don't know
about that devaway list and, then,
Petteri Räty wrote:
I suggest that we dedicate the next bugday in March to migrating as many
built_with_use calls to use dependencies as possible. Actively
maintained packages should have mostly been migrated by now and in
general it's better for the user experience to get rid of all those
On Freitag, 20. Februar 2009, Petteri Räty wrote:
Suggestions/objections?
If you mean by mass migration doing that more or less blindly, I do object.
When an ebuild directly or indirectly inherits an eclass, which is EAPI 2
enabled, like base.eclass, while another isn't, you have to expect
Dne neděle 22 Únor 2009 22:34:19
Carsten Lohrke wrote:
On Freitag, 20. Februar 2009, Petteri Räty wrote:
Suggestions/objections?
If you mean by mass migration doing that more or less blindly, I do
object. When an ebuild directly or indirectly inherits an eclass, which is
EAPI 2 enabled,
Carsten Lohrke wrote:
On Freitag, 20. Februar 2009, Petteri Räty wrote:
Suggestions/objections?
If you mean by mass migration doing that more or less blindly, I do object.
When an ebuild directly or indirectly inherits an eclass, which is EAPI 2
enabled, like base.eclass, while another
On Sonntag, 22. Februar 2009, Petteri Räty wrote:
Even if the eclasses are not EAPI 2 ready you can work
around it in the ebuild by for example those empty functions.
This is fine with me, when you care for said packages and their eclasses and
know for sure such hacks have a very limited
On Sonntag, 22. Februar 2009, Tomáš Chvátal wrote:
Well that is the reason why i am first eapi2ing the kde eclass. I was
really suprised when i saw kde3 ebuilds with eapi2 :(
I value users suffering from package manager issues higher and fix issues as I
see them, walking through the tree. Only
I suggest that we dedicate the next bugday in March to migrating as many
built_with_use calls to use dependencies as possible. Actively
maintained packages should have mostly been migrated by now and in
general it's better for the user experience to get rid of all those
built_with_use calls
John Brooks wrote:
Random idea: How about a different bug assignee for maintainer-needed
packages with provided ebuilds/patches? Either something generic, or
try to go for something more category/package specific (herds, etc).
Lots of work for bugwranglers, though. There is a huge difference
On Mon, Aug 18, 2008 at 5:12 PM, Tobias Scherbaum [EMAIL PROTECTED] wrote:
John Brooks wrote:
Random idea: How about a different bug assignee for maintainer-needed
packages with provided ebuilds/patches? Either something generic, or
try to go for something more category/package specific
Jeremy Olexa wrote:
Also, devs willing to maintain
packages but then later retiring and leaving the packages in limbo.
Maybe there should be some policy such as, when devs retire if no one
else steps up to maintain the package, then it automatically gets
moved to sunrise overlay and only
I agree that packages shouldn't be removed or moved because they have no
active developer maintaining them - that is going to take the value of
portage down quite a lot. Outdated packages do too, but not in quite the
same way.
I like the idea of a list or mailing list of developers willing to
Hi,
Borg hasn't been updated in portage for a while despite the fact that
new versions were released over a year ago (see
http://bugs.gentoo.org/show_bug.cgi?id=184699 ). Therefor I suggest
app-office/borg gets removed from portage.
Regards,
Aniruddha
On Sat, 16 Aug 2008 09:17:10 +0200
Aniruddha [EMAIL PROTECTED] wrote:
Borg hasn't been updated in portage for a while despite the fact that
new versions were released over a year ago (see
http://bugs.gentoo.org/show_bug.cgi?id=184699 ). Therefor I suggest
app-office/borg gets removed from
On Sat, 2008-08-16 at 19:30 +0100, Robert Bridge wrote:
On Sat, 16 Aug 2008 09:17:10 +0200
Aniruddha [EMAIL PROTECTED] wrote:
Borg hasn't been updated in portage for a while despite the fact that
new versions were released over a year ago (see
On Sat, 16 Aug 2008 18:42:35 +0200
Aniruddha [EMAIL PROTECTED] wrote:
I've filed the bugreport (version bump) a year ago. It looks like borg
has no maintainer.
So maintain it. You don't need to be a dev to write an ebuild, and
there are enough devs who are happy to throw an eye over user
It can be somewhat difficult to find someone to look over and commit an
ebuild on an unmaintained package though - the several times i've done that
have involved tracking down developers with previous commits to the package
or who are active in the category and trying to find one who isn't retired
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Bridge wrote:
On Sat, 16 Aug 2008 18:42:35 +0200
Aniruddha [EMAIL PROTECTED] wrote:
I've filed the bugreport (version bump) a year ago. It looks like borg
has no maintainer.
So maintain it. You don't need to be a dev to write an
Kevin F. Quinn wrote:
People reporting bugs often get annoyed when their bug is marked
INVALID; especially when they're relatively new to the Gentoo
Experience. We've all seen it many times, I'm sure.
I know I'm coming in late on this one, but I can see how having a bug
marked as INVALID with
On Saturday 24 March 2007, Jakub Moc wrote:
Kevin F. Quinn napsal(a):
[snip]
See, I don't really care how the reporter feels, if something's not a
bug, then it's not a bug. Don't invent confusing 'politically correct'
junk for this just because someone might feel 'offended'.
One issue is
Kevin F. Quinn wrote:
I know I've seen many instances where the word INVALID has got
peoples hackles up, [...] This is the same issue I have with
NOTABUG - it's like saying, you're wrong, shouldn't have raised
the report, just perhaps not as in-your-face as INVALID.
Precisely. NOTABUG
On 2007/03/25, Benno Schulenberg [EMAIL PROTECTED] wrote:
Precisely. NOTABUG sounds less harsh than INVALID (for some
just a little, for others a lot), it is less likely to irk people,
and it is also used elsewhere, so why not use it instead?
Not that i care that much, but imho INVALID
People reporting bugs often get annoyed when their bug is marked
INVALID; especially when they're relatively new to the Gentoo
Experience. We've all seen it many times, I'm sure.
Arguably no bug is invalid in the normal sense - if someone raises an
issue, they have an issue, regardless what we
Kevin F. Quinn napsal(a):
Arguably no bug is invalid in the normal sense - if someone raises an
issue, they have an issue, regardless what we think of it. To that end
I'd like to propose bugzilla be reconfigured to use the phrase
NOCHANGE instead of INVALID. NOCHANGE would indicate that
On Sat, 24 Mar 2007 18:34:21 +0100
Kevin F. Quinn [EMAIL PROTECTED] wrote:
People reporting bugs often get annoyed when their bug is marked
INVALID; especially when they're relatively new to the Gentoo
Experience. We've all seen it many times, I'm sure.
Arguably no bug is invalid in the
On Sat, Mar 24, 2007 at 06:34:21PM +0100, Kevin F. Quinn wrote:
People reporting bugs often get annoyed when their bug is marked
INVALID; especially when they're relatively new to the Gentoo
Experience. We've all seen it many times, I'm sure.
But sometimes, just sometimes, the bugs are
On Sat, 24 Mar 2007 19:14:38 +0100
Marius Mauch [EMAIL PROTECTED] wrote:
On Sat, 24 Mar 2007 18:34:21 +0100
Kevin F. Quinn [EMAIL PROTECTED] wrote:
People reporting bugs often get annoyed when their bug is marked
INVALID; especially when they're relatively new to the Gentoo
Experience.
I think that there is a problem of concept. If a bug is marked INVALID,
it's because it is not a real bug. Marking a bug NOCHANGE or
NOCHANGEREQUIRED, not only overlaps with other resolutions, but fails to
better explain the reason why the bug was closed, whereas INVALID indeed
means that the
On Sat, 24 Mar 2007 14:48:25 -0400
Michael Cummings [EMAIL PROTECTED] wrote:
On Sat, Mar 24, 2007 at 06:34:21PM +0100, Kevin F. Quinn wrote:
People reporting bugs often get annoyed when their bug is marked
INVALID; especially when they're relatively new to the Gentoo
Experience. We've all
Kevin F. Quinn wrote:
The problem I have with NOTABUG is pretty much the same problem I have
with INVALID - it's not as severe, but it still does the same thing to
the user (i.e. slaps him with a wet fish rather than a frozen one).
Maybe, just maybe, the problem is not with the resolution
On Sat, 24 Mar 2007 22:07:08 +0100
Kevin F. Quinn [EMAIL PROTECTED] wrote:
Certainly good explanations as to why a bug is being closed are to be
encouraged. My issue isn't with that - it's with the way that the
marking INVALID is perceived, when there's no need to be so harsh.
And NOCHANGE
On Sat, 24 Mar 2007 22:02:48 +0100
Ioannis Aslanidis [EMAIL PROTECTED] wrote:
I think that there is a problem of concept. If a bug is marked
INVALID, it's because it is not a real bug. Marking a bug NOCHANGE or
NOCHANGEREQUIRED, not only overlaps with other resolutions, but fails
to better
On Sat, 24 Mar 2007 23:17:52 +0200
Alin Năstac [EMAIL PROTECTED] wrote:
Kevin F. Quinn wrote:
The problem I have with NOTABUG is pretty much the same problem I
have with INVALID - it's not as severe, but it still does the same
thing to the user (i.e. slaps him with a wet fish rather than a
On Sat, 24 Mar 2007 22:46:07 +0100
Marius Mauch [EMAIL PROTECTED] wrote:
On Sat, 24 Mar 2007 22:07:08 +0100
Kevin F. Quinn [EMAIL PROTECTED] wrote:
Certainly good explanations as to why a bug is being closed are to
be encouraged. My issue isn't with that - it's with the way that
the
Kevin F. Quinn napsal(a):
[snip]
See, I don't really care how the reporter feels, if something's not a
bug, then it's not a bug. Don't invent confusing 'politically correct'
junk for this just because someone might feel 'offended'.
Thanks.
--
Best regards,
Jakub Moc
mailto:[EMAIL
On Sun, 25 Mar 2007, Jakub Moc wrote:
Kevin F. Quinn napsal(a):
[snip]
See, I don't really care how the reporter feels, if something's not a
bug, then it's not a bug.
In which case it must be a feature, so why not use the keyword FEATURE?
Don't invent confusing 'politically correct'
junk
Christopher Sawtell napsal(a):
See, I don't really care how the reporter feels, if something's not a
bug, then it's not a bug.
In which case it must be a feature, so why not use the keyword FEATURE?
And why use it? Anything else than 'so that we are 'politically
correct'? Sorry, this doesn't
On Sun, 25 Mar 2007 00:05:02 +0100
Jakub Moc [EMAIL PROTECTED] wrote:
Oh, so resolving 'INVALID' a bug for people that report crap like 'oh,
my sci-mathematics/*' thingy got horribly broken with -ffast-math'
causes an offense to them? Well, that's a good thing, maybe they'll
actually use their
Ciaran McCreesh napsal(a):
Jakub Moc [EMAIL PROTECTED] wrote:
Oh, so resolving 'INVALID' a bug for people that report crap like 'oh,
my sci-mathematics/*' thingy got horribly broken with -ffast-math'
causes an offense to them? Well, that's a good thing, maybe they'll
actually use their brain
Christopher Sawtell wrote:
On Sun, 25 Mar 2007, Jakub Moc wrote:
Kevin F. Quinn napsal(a):
[snip]
See, I don't really care how the reporter feels, if something's not a
bug, then it's not a bug.
In which case it must be a feature, so why not use the keyword FEATURE?
Why would
Hi all,
A friend of mine and myself are willing to develop some tools to help ebuild
development.
We have some constraints, but we are thinking on something like:
1) A tool to ease writing ebuilds. It would take some parameters, i.e.:
1.1) Where are the sources?
1.2) Decompression algorithm?
On Thu, 8 Feb 2007 10:38:08 +0100 Jose San Leandro
[EMAIL PROTECTED] wrote:
| A friend of mine and myself are willing to develop some tools to help
| ebuild development.
All the common cases should be handled by default functions, package
manager functions and eclasses. Thus, writing ebuilds
On Thursday 08 February 2007 10:38 pm, Jose San Leandro wrote:
Hi all,
A friend of mine and myself are willing to develop some tools to help
ebuild development.
We have some constraints, but we are thinking on something like:
1) A tool to ease writing ebuilds. It would take some parameters,
Apropos ebuild-aware text editor, has anyone written an eclipse plugin
yet? I find that setting up ebuild as an external tool is basically
all I need but syntax highlighting and eclass reference would make
things prettier.
On 2/8/07, Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Thu, 8 Feb 2007
That is enough once you know how to write ebuilds.
We were thinking of a GUI to soften the learning curve to non-experts.
Probably not useful for a Gentoo developer, but could provide an easy way to
write ebuilds to project maintainers themselves, not to Gentoo resources.
On Thursday 08
On Thu, 2007-02-08 at 11:59 +0100, Jose San Leandro wrote:
That is enough once you know how to write ebuilds.
We were thinking of a GUI to soften the learning curve to non-experts.
Probably not useful for a Gentoo developer, but could provide an easy way to
write ebuilds to project
Christopher Covington wrote:
Apropos ebuild-aware text editor, has anyone written an eclipse plugin
yet? I find that setting up ebuild as an external tool is basically
all I need but syntax highlighting and eclass reference would make
things prettier.
I have no idea of the status, but I
I would like to suggest to globalize cairo, openexr and udev USE flags. These
USE flags are used by enough amount of packages. Also cairo and udev USE flags
are set defaultly in many profiles.
Arfrever
--
gentoo-dev@gentoo.org mailing list
Dear Developers of Gentoo,
I would really appreciate if you decided to globalize cairo, openexr and udev
USE flags. cairo and openexr USE flags are used by enough amount of packages.
cairo and udev USE flags are set defaultly in many profiles.
Arfrever
--
gentoo-dev@gentoo.org mailing list
Carsten Lohrke wrote [2006-08-31 15:16:31]:
On Thursday 31 August 2006 16:58, Simon Stelling wrote:
About the udev, there's one package that doesn't share the effect:
sys-apps/pcmciautils:udev - Install as an udev helper instead of a
hotplug helper
Which is different from the other 5 Enable
I think that cairo, logrotate, openexr, udev and vnc USE flags should be
global. These are now local USE flags.
Do you agree to change their globalness?
Jak zerwać z dziewczyną, która potrafi fruwać, przenosić
góry i przebijać wzrokiem
On Thursday 31 August 2006 07:24, Arfrever Frehtes Taifersar Arahesis wrote:
I think that cairo, logrotate, openexr, udev and vnc USE flags should be
global. These are now local USE flags.
Gotta say why along with that.
Jak zerwać z
Chris White wrote:
On Thursday 31 August 2006 07:24, Arfrever Frehtes Taifersar Arahesis wrote:
I think that cairo, logrotate, openexr, udev and vnc USE flags should be
global. These are now local USE flags.
Gotta say why along with that.
Local use flags:
cairo: 15
logrotate: 8
Steve Dibb wrote:
And the descriptions seem to be pretty much the same in all of them from
use.local.desc
I think we agreed at least 3 times on that the logrotate use flag
shouldn't exist at all because those files add 4kb to the package.
About the udev, there's one package that doesn't share
On Thursday 31 August 2006 16:58, Simon Stelling wrote:
I think we agreed at least 3 times on that the logrotate use flag
shouldn't exist at all because those files add 4kb to the package.
Right. Open a bug and cc involved maintainers. This is the way it works -
maybe slowly, but it does. We
Simon Stelling wrote:
I think we agreed at least 3 times on that the logrotate use flag
shouldn't exist at all because those files add 4kb to the package.
Please look at http://article.gmane.org/gmane.linux.gentoo.devel/35754 .
I said it once, I'm saying again: squid need this USE flag.
On Thu, 31 Aug 2006 16:58:20 +0200 Simon Stelling [EMAIL PROTECTED]
wrote:
| I think we agreed at least 3 times on that the logrotate use flag
| shouldn't exist at all because those files add 4kb to the package.
No we didn't. It's another file in /etc, which is entirely different
from another
Ciaran McCreesh wrote: [Thu Aug 31 2006, 10:37:21AM CDT]
On Thu, 31 Aug 2006 16:58:20 +0200 Simon Stelling [EMAIL PROTECTED]
wrote:
| I think we agreed at least 3 times on that the logrotate use flag
| shouldn't exist at all because those files add 4kb to the package.
No we didn't. It's
Some packages don't provide standard setup.py. Take a look at the attachment.This is a new ebuld.So my suggestion is to add a new variable to distutils.eclass, e.g. SETUP.PY, if it's set, then use it, otherwise let it defaults to
setup.py.Looking forward to hear your feedback on this.-- Zhang Le,
Zhang Le wrote:
Some packages don't provide standard setup.py.
Take a look at the attachment.
This is a new ebuld.
So my suggestion is to add a new variable to distutils.eclass, e.g.
SETUP.PY, if it's set, then use it, otherwise let it defaults to
setup.py.
what about making a simple
On Mon, 2006-07-17 at 00:49 +0800, Zhang Le wrote:
Some packages don't provide standard setup.py.
Take a look at the attachment.
This is a new ebuld.
I agree with Stefan, just put a symlink in from whatever their distutils
install script is to setup.py in src_unpack(). This seems to be such
On 7/17/06, Alastair Tse [EMAIL PROTECTED] wrote:
On Mon, 2006-07-17 at 00:49 +0800, Zhang Le wrote: Some packages don't provide standard setup.py. Take a look at the attachment. This is a new ebuld.I agree with Stefan, just put a symlink in from whatever their distutils
install script is to
On Wed, 2005-10-19 at 17:31 -0400, Chris Gianelloni wrote:
Actually, genkernel does have the --callback option, which runs an
external command before finalizing the build. We use it for building
external modules and packages that require a configured kernel when
building the releases, but I
On Thu, 2005-10-20 at 18:19 +0100, John Mylchreest wrote:
On Wed, 2005-10-19 at 17:31 -0400, Chris Gianelloni wrote:
Actually, genkernel does have the --callback option, which runs an
external command before finalizing the build. We use it for building
external modules and packages that
There could be some way to remember users what installed packages need to be reemerged after a new kernel is installed.
I thought in this ideas:
- Patch kernel's make to warn at the end of make modules_install
- Warn user after any boot (during init.d stage). This script should
detect the new
On Wed, Oct 19, 2005 at 11:32:19AM -0200, Herbert G. Fischer wrote:
There could be some way to remember users what installed packages need to be
reemerged after a new kernel is installed.
I thought in this ideas:
- Patch kernel's make to warn at the end of make modules_install
- Warn user
That's cool.2005/10/19, Henrik Brix Andersen [EMAIL PROTECTED]:
On Wed, Oct 19, 2005 at 11:32:19AM -0200, Herbert G. Fischer wrote: There could be some way to remember users what installed packages need to be reemerged after a new kernel is installed. I thought in this ideas:
- Patch kernel's
On Wednesday 19 October 2005 06:36, Henrik Brix Andersen wrote:
On Wed, Oct 19, 2005 at 11:32:19AM -0200, Herbert G. Fischer wrote:
[snip]
- Patch kernel's make to warn at the end of make modules_install
[snip]
I think you should check out sys-kernel/module-rebuild
Actually, a combination of
Perhaps the modules-update could be extended to detect new kernels and
warn users or automatically update modules. This could also be
documented in Gentoo docs since this is a basic and common problem that
almost every Gentoo user may have.
Thanks for the patch!2005/10/19, John Myers [EMAIL
Oops... sorry for the last e-mail. I confess that I did not read your
code-piece before answering. It's exactly what I had in mind (as you
saw).2005/10/19, Herbert G. Fischer [EMAIL PROTECTED]:
Perhaps the modules-update could be extended to detect new kernels and
warn users or automatically
2005/10/19, Herbert G. Fischer [EMAIL PROTECTED]:
Perhaps the modules-update could be extended to detect new
kernels and warn users or automatically update modules. This
could also be documented in Gentoo docs since this is a basic
and common problem that
On Wed, 2005-10-19 at 21:44 +0100, John Mylchreest wrote:
I don't particular feel comfortable doing this. the only place I can
actually see this being of some use is with the pkg_config since an
ebuild postinst is far too soon, and patching up Kbuild to do this is
far too intrusive (let alone
101 - 174 of 174 matches
Mail list logo
