FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-11-2010, 09:27 AM
Pacho Ramos
 
Default Suggestion related with dropping keywords policy

Hello

Let my explain the problem and my suggestion to handle it better (at
least from my point of view) with an example:

Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that
bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added.
Since libcap-ng was not keyworded in all arches but x86 and amd64, I had
to drop keywords for bluez and open
http://bugs.gentoo.org/show_bug.cgi?id=303527 for handling it.

From my point of view, I would prefer to:
1. Mask "caps" for net-wireless/bluez on affected arches, letting us to
keep bluez keyworded.
2. Open two bug reports as done with current policy: one for keywording
libcap-ng and other to check bluez works ok with it asking arch team to
unmask that USE flag if possible.

This way to go would have the advantage of letting people running bluez
on affected arches to still get the latest bluez version instead of
still having to run a pretty old (and buggy) one.

Thanks for considering it
 
Old 06-11-2010, 09:39 AM
Thilo Bangert
 
Default Suggestion related with dropping keywords policy

Pacho Ramos <pacho@gentoo.org> said:
> Hello
>
> Let my explain the problem and my suggestion to handle it better (at
> least from my point of view) with an example:
>
> Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that
> bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added.
> Since libcap-ng was not keyworded in all arches but x86 and amd64, I
> had to drop keywords for bluez and open
> http://bugs.gentoo.org/show_bug.cgi?id=303527 for handling it.
>
> From my point of view, I would prefer to:
> 1. Mask "caps" for net-wireless/bluez on affected arches, letting us to
> keep bluez keyworded.
> 2. Open two bug reports as done with current policy: one for keywording
> libcap-ng and other to check bluez works ok with it asking arch team to
> unmask that USE flag if possible.
>
> This way to go would have the advantage of letting people running bluez
> on affected arches to still get the latest bluez version instead of
> still having to run a pretty old (and buggy) one.

it seems to depend on turnaround time. if arch teams respond quickly, then
the USE flag masking would just be an increase in workload. if they are
slow to respond then that may be a good investment.

given that one cant dictate the speed at which arch teams work, your
proposal sounds very sensible.

I am OK with both methods.

kind regards
Thilo

>
> Thanks for considering it
 
Old 06-11-2010, 11:39 AM
Joseph Jezak
 
Default Suggestion related with dropping keywords policy

>
> Hello
>
> Let my explain the problem and my suggestion to handle it better (at
> least from my point of view) with an example:
>
> Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that
> bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added.
> Since libcap-ng was not keyworded in all arches but x86 and amd64, I had
> to drop keywords for bluez and open
> http://bugs.gentoo.org/show_bug.cgi?id=303527 for handling it.
>
> From my point of view, I would prefer to:
> 1. Mask "caps" for net-wireless/bluez on affected arches, letting us to
> keep bluez keyworded.
> 2. Open two bug reports as done with current policy: one for keywording
> libcap-ng and other to check bluez works ok with it asking arch team to
> unmask that USE flag if possible.
>
> This way to go would have the advantage of letting people running bluez
> on affected arches to still get the latest bluez version instead of
> still having to run a pretty old (and buggy) one.
>
> Thanks for considering it
>
Your preferred method is exactly how (as a ppc keyworder) I like to see
these kind of bugs handled. Dropping keywords makes an awful lot more
work for us and hurts our users, especially since we're not always very
prompt at handling bugs.

Thanks for bringing this up on the mailing list!
-Joe
 
Old 06-13-2010, 11:16 AM
Petteri Räty
 
Default Suggestion related with dropping keywords policy

On 06/11/2010 12:27 PM, Pacho Ramos wrote:

>
> From my point of view, I would prefer to:
> 1. Mask "caps" for net-wireless/bluez on affected arches, letting us to
> keep bluez keyworded.
> 2. Open two bug reports as done with current policy: one for keywording
> libcap-ng and other to check bluez works ok with it asking arch team to
> unmask that USE flag if possible.
>

There's nothing preventing you from already doing this. package.use.mask
is something package maintainers themselves should be looking after for
their packages.

Regards,
Petteri
 
Old 06-13-2010, 12:43 PM
Pacho Ramos
 
Default Suggestion related with dropping keywords policy

El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió:
> On 06/11/2010 12:27 PM, Pacho Ramos wrote:
>
> >
> > From my point of view, I would prefer to:
> > 1. Mask "caps" for net-wireless/bluez on affected arches, letting us to
> > keep bluez keyworded.
> > 2. Open two bug reports as done with current policy: one for keywording
> > libcap-ng and other to check bluez works ok with it asking arch team to
> > unmask that USE flag if possible.
> >
>
> There's nothing preventing you from already doing this. package.use.mask
> is something package maintainers themselves should be looking after for
> their packages.
>
> Regards,
> Petteri
>


OK, thanks a lot :-D
 
Old 06-13-2010, 10:29 PM
Pacho Ramos
 
Default Suggestion related with dropping keywords policy

El dom, 13-06-2010 a las 14:43 +0200, Pacho Ramos escribió:
> El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió:
> > On 06/11/2010 12:27 PM, Pacho Ramos wrote:
> >
> > >
> > > From my point of view, I would prefer to:
> > > 1. Mask "caps" for net-wireless/bluez on affected arches, letting us to
> > > keep bluez keyworded.
> > > 2. Open two bug reports as done with current policy: one for keywording
> > > libcap-ng and other to check bluez works ok with it asking arch team to
> > > unmask that USE flag if possible.
> > >
> >
> > There's nothing preventing you from already doing this. package.use.mask
> > is something package maintainers themselves should be looking after for
> > their packages.
> >
> > Regards,
> > Petteri
> >
>
>
> OK, thanks a lot :-D

The problem is that hppa team seems to not allow others than they to
edit their package.use.mask :-/, is there any special reason for it?
 
Old 06-14-2010, 02:59 AM
Jeroen Roovers
 
Default Suggestion related with dropping keywords policy

On Mon, 14 Jun 2010 00:29:19 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El dom, 13-06-2010 a las 14:43 +0200, Pacho Ramos escribió:
> > El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió:
> > > On 06/11/2010 12:27 PM, Pacho Ramos wrote:
> > >
> > > >
> > > > From my point of view, I would prefer to:
> > > > 1. Mask "caps" for net-wireless/bluez on affected arches,
> > > > letting us to keep bluez keyworded.
> > > > 2. Open two bug reports as done with current policy: one for
> > > > keywording libcap-ng and other to check bluez works ok with it
> > > > asking arch team to unmask that USE flag if possible.
> > > >
> > >
> > > There's nothing preventing you from already doing this.
> > > package.use.mask is something package maintainers themselves
> > > should be looking after for their packages.
> > >
> > > Regards,
> > > Petteri
> > >
> >
> >
> > OK, thanks a lot :-D
>
> The problem is that hppa team seems to not allow others than they to
> edit their package.use.mask :-/, is there any special reason for it?

What is the problem? The files in place ask you to file a bug report
instead of fiddling with the files yourselves. I put that in place
because I got (fucking) tired of seeing the after effects of people
fiddling with the arch profile files without 1) consideration, 2)
informing the involved arch team. What do you expect? File a bloody bug
report detailing the (commit) problem you are facing and you will
probably see 1) response and 2) cooperation. If you fuck around with
the arch profile files without doing any of that, you will face 1) a
lack of willingness to cooperate and 2) evil wrath.


Regards,
jer
 
Old 06-14-2010, 08:08 AM
Pacho Ramos
 
Default Suggestion related with dropping keywords policy

El lun, 14-06-2010 a las 04:59 +0200, Jeroen Roovers escribió:
> What is the problem? The files in place ask you to file a bug report
> instead of fiddling with the files yourselves. I put that in place
> because I got (fucking) tired of seeing the after effects of people
> fiddling with the arch profile files without 1) consideration, 2)
> informing the involved arch team. What do you expect? File a bloody bug
> report detailing the (commit) problem you are facing and you will
> probably see 1) response and 2) cooperation. If you fuck around with
> the arch profile files without doing any of that, you will face 1) a
> lack of willingness to cooperate and 2) evil wrath.
>
>
> Regards,
> jer

The problem is that, at least regarding gnome related bugs, there are a
lot of keywords dropped for your arch that could be prevented
use.masking an USE, like, for example, dev-util/anjuta-2.28*, that is
causing us to preserve and old (and broken) 2.24 release only for hppa.

My intention is only to try to help you and improve the situation, I
also have opened bug reports for every change have committed to, for
example, powerpc profiles (you will see that I edited your profile
yesterday, but it was because I totally missed the note preventing us to
do that, this is why I didn't committed any more changes and sent reply
above; it wasn't premeditated)

Would you allow me to edit hppa package.use.mask *if I open
corresponding bug report* ?

Thanks :-)
 
Old 06-14-2010, 08:21 AM
Petteri Räty
 
Default Suggestion related with dropping keywords policy

On 14.6.2010 5.59, Jeroen Roovers wrote:
> On Mon, 14 Jun 2010 00:29:19 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
>
>> El dom, 13-06-2010 a las 14:43 +0200, Pacho Ramos escribió:
>>> El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió:
>>>> On 06/11/2010 12:27 PM, Pacho Ramos wrote:
>>>>
>>>>>
>>>>> From my point of view, I would prefer to:
>>>>> 1. Mask "caps" for net-wireless/bluez on affected arches,
>>>>> letting us to keep bluez keyworded.
>>>>> 2. Open two bug reports as done with current policy: one for
>>>>> keywording libcap-ng and other to check bluez works ok with it
>>>>> asking arch team to unmask that USE flag if possible.
>>>>>
>>>>
>>>> There's nothing preventing you from already doing this.
>>>> package.use.mask is something package maintainers themselves
>>>> should be looking after for their packages.
>>>>
>>>> Regards,
>>>> Petteri
>>>>
>>>
>>>
>>> OK, thanks a lot :-D
>>
>> The problem is that hppa team seems to not allow others than they to
>> edit their package.use.mask :-/, is there any special reason for it?
>
> What is the problem? The files in place ask you to file a bug report
> instead of fiddling with the files yourselves. I put that in place
> because I got (fucking) tired of seeing the after effects of people
> fiddling with the arch profile files without 1) consideration, 2)
> informing the involved arch team. What do you expect?

If there's a problem with how developers do stuff shouldn't we rather
educate them and make sure new developers are trained so there will not
be many problems? Aren't arch teams overloaded for work already?
package.use.mask is local to a single package so usually there's not a
big need for arch teams to be aware of the entries (unless of course
it's some central package but hopefully their maintainers have due
diligence).

Regards,
Petteri
 
Old 06-14-2010, 09:30 AM
Jeroen Roovers
 
Default Suggestion related with dropping keywords policy

On Mon, 14 Jun 2010 10:08:58 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> The problem is that, at least regarding gnome related bugs, there are
> a lot of keywords dropped for your arch that could be prevented
> use.masking an USE, like, for example, dev-util/anjuta-2.28*, that is
> causing us to preserve and old (and broken) 2.24 release only for
> hppa.

What bug is that?


jer
 

Thread Tools




All times are GMT. The time now is 07:11 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org