Re: [gentoo-dev] Suggestion related with dropping keywords policy
On Thu, 17 Jun 2010 14:04:42 +0200 Pacho Ramos 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
El jue, 17-06-2010 a las 06:07 +0200, Jeroen Roovers escribió: > On Fri, 11 Jun 2010 07:39:01 -0400 > Joseph Jezak 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 Fri, 11 Jun 2010 07:39:01 -0400
Joseph Jezak 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 11:30 +0200, Jeroen Roovers escribió: > On Mon, 14 Jun 2010 10:08:58 +0200 > Pacho Ramos 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 Mon, 14 Jun 2010 10:08:58 +0200 Pacho Ramos 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
On 14.6.2010 5.59, Jeroen Roovers wrote: > On Mon, 14 Jun 2010 00:29:19 +0200 > Pacho Ramos 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
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 00:29:19 +0200 Pacho Ramos 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
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
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
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
> > 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
Re: [gentoo-dev] Suggestion related with dropping keywords policy
Pacho Ramos 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.
