Re: [gentoo-dev] Suggestion related with dropping keywords policy
El jue, 17-06-2010 a las 06:07 +0200, Jeroen Roovers escribió: On Fri, 11 Jun 2010 07:39:01 -0400 Joseph Jezak jos...@gentoo.org wrote: 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. Well, reasoning for the HPPA team, which maintains an architecture that is dying rather more quickly than PPC32 (which still has all kinds of embedded uses and so on),, in favour of IA64, I'd rather see dropped keywords than new profile entries, possibly with the keyworded ebuilds being gradually removed after an OK. That way I can make a choice to keep a package (set) for a bit or to stop supporting it immediately. In that case, could you then consider to un-CC from keywording bugs hppa team is not willing to fix? I think it would help a lot to clean the tree of old versions that are been kept as it's the inly keyworded on hppa Thanks a lot signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion related with dropping keywords policy
On Thu, 17 Jun 2010 14:04:42 +0200 Pacho Ramos pa...@gentoo.org wrote: In that case, could you then consider to un-CC from keywording bugs hppa team is not willing to fix? I think it would help a lot to clean the tree of old versions that are been kept as it's the inly keyworded on hppa Sounds like a plan. The problem I see is the amount of breakage that would cause in reverse dependencies, but can I hazard a guess that the greater desktop teams have ample compute power to resolve those? Regards, jer
Re: [gentoo-dev] Suggestion related with dropping keywords policy
On Fri, 11 Jun 2010 07:39:01 -0400
Joseph Jezak jos...@gentoo.org wrote:
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.
Well, reasoning for the HPPA team, which maintains an architecture
that is dying rather more quickly than PPC32 (which still has all kinds
of embedded uses and so on),, in favour of IA64, I'd rather see dropped
keywords than new profile entries, possibly with the keyworded ebuilds
being gradually removed after an OK. That way I can make a choice to
keep a package (set) for a bit or to stop supporting it immediately.
Since there is no unveiling effect in re-adding dropped keywords, as
opposed to using profile masks that you can only remove safely by
first revdep-checking the entire tree again, I'd rather have people
file bug reports than touching the HPPA profile files themselves.
Since we (HPPA) basically agreed to drop support for the major desktop
environments in due time already (we still need to make that official
some time soon and then actually work on the problem for the last time),
dropping those keywords is a lot better than masking specific versions
of ebuilds or specific uses of USE flags.
Funnily enough, I've expressed these wishes to the people who are doing
the *DEPEND checks before they commit (hundreds of ebuilds) time and
again, and still ended up with sometimes years old entries in
package.{,use.}mask files.
In fact I think there's a bug open about it and I tried to get some
discussion about it going on this very mailing list. :)
jer
Re: [gentoo-dev] 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 :-) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion related with dropping keywords policy
On Mon, 14 Jun 2010 10:08:58 +0200 Pacho Ramos pa...@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
Re: [gentoo-dev] Suggestion related with dropping keywords policy
El lun, 14-06-2010 a las 11:30 +0200, Jeroen Roovers escribió: On Mon, 14 Jun 2010 10:08:58 +0200 Pacho Ramos pa...@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 http://bugs.gentoo.org/show_bug.cgi?id=298200#c23 ;-) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] 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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 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? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion related with dropping keywords policy
On Mon, 14 Jun 2010 00:29:19 +0200 Pacho Ramos pa...@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
[gentoo-dev] 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 signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] Suggestion related with dropping keywords policy
Pacho Ramos pa...@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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] 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
