Re: [gentoo-dev] Default HOMEPAGE for packages with unavailable website
> On Wed, 30 Jul 2014, William Hubbs wrote: > I just noticed in PMS that HOMEPAGE is an optional variable, so we > really don't need a default home page at all. It seems completely > legit for an ebuild to not even define the HOMEPAGE variable. That's one of the places where our policy is stricter than PMS. The devmanual says clearly that HOMEPAGE is mandatory, except for virtuals. Ulrich pgp5s8t5VfZ8Q.pgp Description: PGP signature
Re: [gentoo-dev] About current ppc/ppc64 status
On Wed, Jul 30, 2014 at 07:44:57PM -0400, Anthony G. Basile wrote: > On 07/30/14 17:18, Joseph Jezak wrote: > > On 07/30/2014 06:26 AM, Anthony G. Basile wrote: > >> On 07/29/14 22:16, Jack Morgan wrote: > >>> On Sat, Jul 26, 2014 at 04:29:51PM -0400, Anthony G. Basile wrote: > On 07/26/14 09:44, Pacho Ramos wrote: > > El sáb, 26-07-2014 a las 09:37 -0400, Anthony G. Basile escribió: > >> On 07/26/14 09:28, Pacho Ramos wrote: > >>> El sáb, 26-07-2014 a las 14:55 +0200, Andreas K. Huettel escribió: > Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos: > > > I guess we will need to wait for the next Council to > > officially decide > > to do this as it will be a big change for ppc* users :/ (I > > remember > > their action was needed for the move to testing of some arches > > and the > > "package-by-package" proposal for others) > > > > Also, I am not sure if any other arch teams (sparc, ia64?) > > would want to > > get this policy too :| (I got ppc* because this concrete case ;)) > At first this is an arch team decision. No need for the council. > > (Given that in this case there is a responsive and addressable > arch team...) > > -- > > Andreas K. Huettel > Gentoo Linux developer > dilfri...@gentoo.org > http://www.akhuettel.de/ > > >>> The problem is that blueness looks to be the only member currently > >>> replying :/, I have checked their page and I see no team lead or > >>> similar. Then, I am not sure how to get the ok to proceed or not > >>> :| (to > >>> prevent this from getting stalled and we keep trying stabilizing > >>> all the > >>> things). > >>> > >>> I remember from older thread (one related with udev > >>> stabilization), that > >>> blueness was also the only one replying. > >>> > >>> > >> Yeah, not having a clear lead is a problem. No one wants to just > >> make a > >> big decision on behalf of the team without making sure everyone > >> is on > >> board. Pacho, do you have access to timberdoodle? If so, join both > >> teams and just take the initiative and let any other "claimants" > >> step > >> forward now. BTW, taking the lead doesn't mean doing all the work > >> yourself. I want to see ppc/ppc64 in good shape. I'll be happy to > >> write scripts to do the demoting to ~ etc etc. > >> > > I don't even know about timberdoodle :( > > > > I forwarded the mail to both alias (as I forgot first time), then, > > hopefully they will review it :/ > > > > Will CC them again to this just now with this link to allow all to > > read > > the full thread: > > http://comments.gmane.org/gmane.linux.gentoo.devel/92151 > > > > > > > I think its clear who cares about ppc/ppc64. If there are no > objections, I'll take the lead of those teams and see this plan > through. I'll wait a few days for people to voice concerns. Then I'll > start by generating a list of all stable and testing packages on > ppc and > ppc64. I'll post then and then continue the conversation on just the > ppc and ppc64 lists. Don't worry, I won't start dropping to ~ > until we > have a concise plan and we're all on board. > >>> I don't think you can/should just take over the leadership of an > >>> arch. > >>> Why not have meeting/discussion for team members. Especially since you > >>> are proposing such a big change. > >>> > >>> > >>> Thanks, > >>> > >> > >> Okay, any members of the ppc team please speak up. I'll wait a week. > >> > > I'm still trying to escape from grad school and getting married this > > fall, so my contributions have been limited at best, which is why I've > > been shying away from throwing in my two cents. That said, while I'd > > rather not just remove stable keywords until there's a reason, I have > > no problem with dropping keywords for stuff that is holding up > > stabilization bugs if that's what it takes for things to move forward. > > If you'd like to have a meeting about it, that's fine too. > > > > -Joe > > > > Sure, let's meet. I'd like to have jmorgan come too and any other > ppc/ppc64 members. How does Monday Aug 4 at 20:00 UTC sound to people. > If not please counter propose a time. This sounds fine for me. I'll be there. I've been away for a few months but getting back to helping out. If the current lead isn't active, then we should have a vote as to who should take over that role. Then discuss how to proceed with the topics in this thread. Thanks for organizing this. Cheers,` -- Jack Morgan Pub 4096R/761D8E0A 2010-09-13 Jack Morgan > Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A signature.asc Description: Digital si
Re: [gentoo-dev] About current ppc/ppc64 status
On 07/30/14 17:18, Joseph Jezak wrote: On 07/30/2014 06:26 AM, Anthony G. Basile wrote: On 07/29/14 22:16, Jack Morgan wrote: On Sat, Jul 26, 2014 at 04:29:51PM -0400, Anthony G. Basile wrote: On 07/26/14 09:44, Pacho Ramos wrote: El sáb, 26-07-2014 a las 09:37 -0400, Anthony G. Basile escribió: On 07/26/14 09:28, Pacho Ramos wrote: El sáb, 26-07-2014 a las 14:55 +0200, Andreas K. Huettel escribió: Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos: I guess we will need to wait for the next Council to officially decide to do this as it will be a big change for ppc* users :/ (I remember their action was needed for the move to testing of some arches and the "package-by-package" proposal for others) Also, I am not sure if any other arch teams (sparc, ia64?) would want to get this policy too :| (I got ppc* because this concrete case ;)) At first this is an arch team decision. No need for the council. (Given that in this case there is a responsive and addressable arch team...) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ The problem is that blueness looks to be the only member currently replying :/, I have checked their page and I see no team lead or similar. Then, I am not sure how to get the ok to proceed or not :| (to prevent this from getting stalled and we keep trying stabilizing all the things). I remember from older thread (one related with udev stabilization), that blueness was also the only one replying. Yeah, not having a clear lead is a problem. No one wants to just make a big decision on behalf of the team without making sure everyone is on board. Pacho, do you have access to timberdoodle? If so, join both teams and just take the initiative and let any other "claimants" step forward now. BTW, taking the lead doesn't mean doing all the work yourself. I want to see ppc/ppc64 in good shape. I'll be happy to write scripts to do the demoting to ~ etc etc. I don't even know about timberdoodle :( I forwarded the mail to both alias (as I forgot first time), then, hopefully they will review it :/ Will CC them again to this just now with this link to allow all to read the full thread: http://comments.gmane.org/gmane.linux.gentoo.devel/92151 I think its clear who cares about ppc/ppc64. If there are no objections, I'll take the lead of those teams and see this plan through. I'll wait a few days for people to voice concerns. Then I'll start by generating a list of all stable and testing packages on ppc and ppc64. I'll post then and then continue the conversation on just the ppc and ppc64 lists. Don't worry, I won't start dropping to ~ until we have a concise plan and we're all on board. I don't think you can/should just take over the leadership of an arch. Why not have meeting/discussion for team members. Especially since you are proposing such a big change. Thanks, Okay, any members of the ppc team please speak up. I'll wait a week. I'm still trying to escape from grad school and getting married this fall, so my contributions have been limited at best, which is why I've been shying away from throwing in my two cents. That said, while I'd rather not just remove stable keywords until there's a reason, I have no problem with dropping keywords for stuff that is holding up stabilization bugs if that's what it takes for things to move forward. If you'd like to have a meeting about it, that's fine too. -Joe Sure, let's meet. I'd like to have jmorgan come too and any other ppc/ppc64 members. How does Monday Aug 4 at 20:00 UTC sound to people. If not please counter propose a time. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] About current ppc/ppc64 status
On 07/30/2014 06:26 AM, Anthony G. Basile wrote: On 07/29/14 22:16, Jack Morgan wrote: On Sat, Jul 26, 2014 at 04:29:51PM -0400, Anthony G. Basile wrote: On 07/26/14 09:44, Pacho Ramos wrote: El sáb, 26-07-2014 a las 09:37 -0400, Anthony G. Basile escribió: On 07/26/14 09:28, Pacho Ramos wrote: El sáb, 26-07-2014 a las 14:55 +0200, Andreas K. Huettel escribió: Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos: I guess we will need to wait for the next Council to officially decide to do this as it will be a big change for ppc* users :/ (I remember their action was needed for the move to testing of some arches and the "package-by-package" proposal for others) Also, I am not sure if any other arch teams (sparc, ia64?) would want to get this policy too :| (I got ppc* because this concrete case ;)) At first this is an arch team decision. No need for the council. (Given that in this case there is a responsive and addressable arch team...) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ The problem is that blueness looks to be the only member currently replying :/, I have checked their page and I see no team lead or similar. Then, I am not sure how to get the ok to proceed or not :| (to prevent this from getting stalled and we keep trying stabilizing all the things). I remember from older thread (one related with udev stabilization), that blueness was also the only one replying. Yeah, not having a clear lead is a problem. No one wants to just make a big decision on behalf of the team without making sure everyone is on board. Pacho, do you have access to timberdoodle? If so, join both teams and just take the initiative and let any other "claimants" step forward now. BTW, taking the lead doesn't mean doing all the work yourself. I want to see ppc/ppc64 in good shape. I'll be happy to write scripts to do the demoting to ~ etc etc. I don't even know about timberdoodle :( I forwarded the mail to both alias (as I forgot first time), then, hopefully they will review it :/ Will CC them again to this just now with this link to allow all to read the full thread: http://comments.gmane.org/gmane.linux.gentoo.devel/92151 I think its clear who cares about ppc/ppc64. If there are no objections, I'll take the lead of those teams and see this plan through. I'll wait a few days for people to voice concerns. Then I'll start by generating a list of all stable and testing packages on ppc and ppc64. I'll post then and then continue the conversation on just the ppc and ppc64 lists. Don't worry, I won't start dropping to ~ until we have a concise plan and we're all on board. I don't think you can/should just take over the leadership of an arch. Why not have meeting/discussion for team members. Especially since you are proposing such a big change. Thanks, Okay, any members of the ppc team please speak up. I'll wait a week. I'm still trying to escape from grad school and getting married this fall, so my contributions have been limited at best, which is why I've been shying away from throwing in my two cents. That said, while I'd rather not just remove stable keywords until there's a reason, I have no problem with dropping keywords for stuff that is holding up stabilization bugs if that's what it takes for things to move forward. If you'd like to have a meeting about it, that's fine too. -Joe
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Wed, Jul 30, 2014 at 07:29:22PM +0200, Michael Haubenwallner wrote:
>
> Am 2014-07-30 14:33, schrieb Samuli Suominen:
> >
> > There is no need to package.mask if proper if -logic is used, like, for
> > example,
> >
> > if [[ ${PV} == * ]]; then
> > inherit git-r3
> > KEYWORDS=""
> > else
> > KEYWORDS="~amd64 ~arm ~arm64 ~x86"
> > fi
> >
> > Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
> > the KEYWORDS
> > ready, and 1.2.3 and ebuilds can be identical
>
> Which instance of the KEYWORDS line is touched by the ekeyword tool these
> days?
>
> To have ekeyword touch the else-part in the release ebuild, what about this:
>
> if [[ ${PV} == * ]]; then
> inherit vcs...
> :; KEYWORDS=""
> else
> KEYWORDS="..."
> fi
Actually you can even go further since KEYWORDS is an optional variable:
if [[ ${PV} == * ]]; then
inherit vcs...
else
KEYWORDS="..."
fi
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] Default HOMEPAGE for packages with unavailable website
On Mon, Jul 21, 2014 at 06:20:12PM -0500, Gordon Pettey wrote: > On Mon, Jul 21, 2014 at 5:06 PM, Alexander Berntsen > wrote: > > > On 21/07/14 19:41, Ciaran McCreesh wrote: > > > What's wrong with HOMEPAGE="()" ? > > It is not very informative. > > > The wiki page is equivalently informative. What's the point of metadata > that just says "there's no metadata"? I'm just picking a random message to respond to. I just noticed in PMS that HOMEPAGE is an optional variable, so we really don't need a default home page at all. It seems completely legit for an ebuild to not even define the HOMEPAGE variable. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On 30/07/14 20:29, Michael Haubenwallner wrote:
> Am 2014-07-30 14:33, schrieb Samuli Suominen:
>> There is no need to package.mask if proper if -logic is used, like, for
>> example,
>>
>> if [[ ${PV} == * ]]; then
>> inherit git-r3
>> KEYWORDS=""
>> else
>> KEYWORDS="~amd64 ~arm ~arm64 ~x86"
>> fi
>>
>> Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
>> the KEYWORDS
>> ready, and 1.2.3 and ebuilds can be identical
> Which instance of the KEYWORDS line is touched by the ekeyword tool these
> days?
>
> To have ekeyword touch the else-part in the release ebuild, what about this:
>
> if [[ ${PV} == * ]]; then
> inherit vcs...
> :; KEYWORDS=""
> else
> KEYWORDS="..."
> fi
>
> /haubi/
>
You are propably looking for this,
http://bugs.gentoo.org/show_bug.cgi?id=321475
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
Am 2014-07-30 14:33, schrieb Samuli Suominen:
>
> There is no need to package.mask if proper if -logic is used, like, for
> example,
>
> if [[ ${PV} == * ]]; then
> inherit git-r3
> KEYWORDS=""
> else
> KEYWORDS="~amd64 ~arm ~arm64 ~x86"
> fi
>
> Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
> the KEYWORDS
> ready, and 1.2.3 and ebuilds can be identical
Which instance of the KEYWORDS line is touched by the ekeyword tool these days?
To have ekeyword touch the else-part in the release ebuild, what about this:
if [[ ${PV} == * ]]; then
inherit vcs...
:; KEYWORDS=""
else
KEYWORDS="..."
fi
/haubi/
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Wed, 30 Jul 2014 15:33:19 +0300
Samuli Suominen wrote:
> There is no need to package.mask if proper if -logic is used, like,
> for example,
>
> if [[ ${PV} == * ]]; then
> inherit git-r3
> KEYWORDS=""
> else
> KEYWORDS="~amd64 ~arm ~arm64 ~x86"
> fi
>
> Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
> the KEYWORDS
> ready, and 1.2.3 and ebuilds can be identical
>
> That's what this thread was originally about... That's how x265's
> ebuild work, just like eg.
> media-libs/xine-lib or sys-fs/udev ebuilds does
>
> (It just seemed this was unclear to some replying in this thread.)
>
> - Samuli
>
>
Thanks for the clarification. This approach seems to be the optimum.
Regards,
Luis Ressel
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On 30/07/14 14:18, Rich Freeman wrote: > On Wed, Jul 30, 2014 at 3:38 AM, "Paweł Hajdan, Jr." > wrote: >> On 7/30/14, 7:36 AM, Samuli Suominen wrote: >>> If it's 2-3 packages out of ~300, I'd rather pick them out than >>> revision bump all ~300 for the 2-3. Or not pick them out at all >>> and let users do the rebuild (which is the obvious answer >>> to the output you posted) >> Peter Stuge pointed it out already, but I also wanted to say rebuilding >> the affected packages is not obvious to me either. > Sure, but this seems more like a portage bug (or at least a portage > output bug) rather than a fundamental issue. > > After all, there was no true block - just a need for a rebuild. > > I heard prerm as a reason why dynamic deps can break (especially with > slot operator deps, though obviously it also breaks for > non-slot-operator deps that should be expressed as such), though as > has been pointed out those will break unless we unmerge and remerge > all reverse-deps on every upgrade. Are there other issues. > > To be honest I was expecting a plethora of issues that can go wrong > with dynamic deps, but so far I'm hearing something like 2-3, and if > that really is all that there is then this may be a solvable issue. > > That's what I've been trying to point out, people are seriously suggesting disabling dynamic deps for race conditions It's like fixing one audio driver in the kernel by deleting whole ALSA block :-( - Samuli
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On 30/07/14 14:48, Luis Ressel wrote:
> On Wed, 30 Jul 2014 09:38:16 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
>
>> In the context of that policy and a content-touchless-bump goal, I
>> suppose I'd script the bump, pulling keywords from the highest
>> previous version, prepending the ~ as necessary and inserting them in
>> the keywords line after copying the file from the live-ebuild . That
>> wouldn't be content-touchless, but the touch would be automated so as
>> to avoid mistakes and unnecessary work.
> That proposed script reminds me of http://xkcd.com/1319/. ;)
>
> I think I'd rather go with the original workflow. Okay, perhaps
> package.masking - is a bit uncommon and clutters package.mask, but
> it's not all *that* bad and it eases the workflow.
>
>
> Regards,
> Luis Ressel
There is no need to package.mask if proper if -logic is used, like, for
example,
if [[ ${PV} == * ]]; then
inherit git-r3
KEYWORDS=""
else
KEYWORDS="~amd64 ~arm ~arm64 ~x86"
fi
Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
the KEYWORDS
ready, and 1.2.3 and ebuilds can be identical
That's what this thread was originally about... That's how x265's ebuild
work, just like eg.
media-libs/xine-lib or sys-fs/udev ebuilds does
(It just seemed this was unclear to some replying in this thread.)
- Samuli
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Wed, 30 Jul 2014 09:38:16 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > In the context of that policy and a content-touchless-bump goal, I > suppose I'd script the bump, pulling keywords from the highest > previous version, prepending the ~ as necessary and inserting them in > the keywords line after copying the file from the live-ebuild . That > wouldn't be content-touchless, but the touch would be automated so as > to avoid mistakes and unnecessary work. That proposed script reminds me of http://xkcd.com/1319/. ;) I think I'd rather go with the original workflow. Okay, perhaps package.masking - is a bit uncommon and clutters package.mask, but it's not all *that* bad and it eases the workflow. Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Wed, 30 Jul 2014 07:18:22 -0400 Rich Freeman wrote: > Sure, but this seems more like a portage bug (or at least a portage > output bug) rather than a fundamental issue. > > After all, there was no true block - just a need for a rebuild. It's often not possible to produce a decent error message, given the limited information that ebuilds supply and the unnecessary pseudocleverness they employ to do it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Wed, Jul 30, 2014 at 3:38 AM, "Paweł Hajdan, Jr." wrote: > On 7/30/14, 7:36 AM, Samuli Suominen wrote: >> If it's 2-3 packages out of ~300, I'd rather pick them out than >> revision bump all ~300 for the 2-3. Or not pick them out at all >> and let users do the rebuild (which is the obvious answer >> to the output you posted) > > Peter Stuge pointed it out already, but I also wanted to say rebuilding > the affected packages is not obvious to me either. Sure, but this seems more like a portage bug (or at least a portage output bug) rather than a fundamental issue. After all, there was no true block - just a need for a rebuild. I heard prerm as a reason why dynamic deps can break (especially with slot operator deps, though obviously it also breaks for non-slot-operator deps that should be expressed as such), though as has been pointed out those will break unless we unmerge and remerge all reverse-deps on every upgrade. Are there other issues. To be honest I was expecting a plethora of issues that can go wrong with dynamic deps, but so far I'm hearing something like 2-3, and if that really is all that there is then this may be a solvable issue. Rich
Re: [gentoo-dev] Restructuring the ppc/ppc64 profiles to be better multilib
On 07/30/14 00:34, Jack Morgan wrote: On Sat, Jun 28, 2014 at 02:46:43PM -0400, Anthony G. Basile wrote: Hi everyone, This is a ppc/ppc64 issues, but I'm sending this to gentoo-dev@ because it seems to me that those herds are pretty scattered right: 1) The issue came up about restructuring the arch/powerpc profiles. There we have some ancient stuff like ppc64/32ul. I don't know why that's needed and it doesn't make much sense wrt the new direction multilib is going. I'd like to clean up those profiles. Any objections to removing ppc64/32ul, coalescing ppc64/64ul into just ppc64 and making whatever other tweaks are needed? 2) Can we try to get the ppc/ppc64 herds communicating more. I don't believe every team needs a lead but at least have a point of reference so we can communicate. What is the status of this? I've been away for a few months but am back now. Do you need help with this? Thanks, I did not proceed because there was no response from any ppc/ppc64 members. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] About current ppc/ppc64 status
On 07/29/14 22:16, Jack Morgan wrote: On Sat, Jul 26, 2014 at 04:29:51PM -0400, Anthony G. Basile wrote: On 07/26/14 09:44, Pacho Ramos wrote: El sáb, 26-07-2014 a las 09:37 -0400, Anthony G. Basile escribió: On 07/26/14 09:28, Pacho Ramos wrote: El sáb, 26-07-2014 a las 14:55 +0200, Andreas K. Huettel escribió: Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos: I guess we will need to wait for the next Council to officially decide to do this as it will be a big change for ppc* users :/ (I remember their action was needed for the move to testing of some arches and the "package-by-package" proposal for others) Also, I am not sure if any other arch teams (sparc, ia64?) would want to get this policy too :| (I got ppc* because this concrete case ;)) At first this is an arch team decision. No need for the council. (Given that in this case there is a responsive and addressable arch team...) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ The problem is that blueness looks to be the only member currently replying :/, I have checked their page and I see no team lead or similar. Then, I am not sure how to get the ok to proceed or not :| (to prevent this from getting stalled and we keep trying stabilizing all the things). I remember from older thread (one related with udev stabilization), that blueness was also the only one replying. Yeah, not having a clear lead is a problem. No one wants to just make a big decision on behalf of the team without making sure everyone is on board. Pacho, do you have access to timberdoodle? If so, join both teams and just take the initiative and let any other "claimants" step forward now. BTW, taking the lead doesn't mean doing all the work yourself. I want to see ppc/ppc64 in good shape. I'll be happy to write scripts to do the demoting to ~ etc etc. I don't even know about timberdoodle :( I forwarded the mail to both alias (as I forgot first time), then, hopefully they will review it :/ Will CC them again to this just now with this link to allow all to read the full thread: http://comments.gmane.org/gmane.linux.gentoo.devel/92151 I think its clear who cares about ppc/ppc64. If there are no objections, I'll take the lead of those teams and see this plan through. I'll wait a few days for people to voice concerns. Then I'll start by generating a list of all stable and testing packages on ppc and ppc64. I'll post then and then continue the conversation on just the ppc and ppc64 lists. Don't worry, I won't start dropping to ~ until we have a concise plan and we're all on board. I don't think you can/should just take over the leadership of an arch. Why not have meeting/discussion for team members. Especially since you are proposing such a big change. Thanks, Okay, any members of the ppc team please speak up. I'll wait a week. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
Denis Dupeyron posted on Tue, 29 Jul 2014 07:58:26 -0600 as excerpted: > [H]ere is what I was instructed to teach recruits back when I became a > recruiter in 2006 or 2007, and what competent developers have been doing > since even before I was a developer: > > The package.mask file is only for temporary masking, even if more or > less long term. Anything that should be permanently masked has no place > in the tree. Live ebuilds should not be keyworded, reflecting the fact > that the code they're pulling has not be tested for any architecture due > to it being live. Moreover, live ebuilds should not be masked as this > results in unnecessary cruft in the package.mask file. Thanks. That makes sense, tho it does conflict with "content-touchless" bumps from the live ebuild. In the context of that policy and a content-touchless-bump goal, I suppose I'd script the bump, pulling keywords from the highest previous version, prepending the ~ as necessary and inserting them in the keywords line after copying the file from the live-ebuild . That wouldn't be content-touchless, but the touch would be automated so as to avoid mistakes and unnecessary work. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: don't rely on dynamic deps
On 7/30/14, 7:36 AM, Samuli Suominen wrote: > If it's 2-3 packages out of ~300, I'd rather pick them out than > revision bump all ~300 for the 2-3. Or not pick them out at all > and let users do the rebuild (which is the obvious answer > to the output you posted) Peter Stuge pointed it out already, but I also wanted to say rebuilding the affected packages is not obvious to me either. Paweł >> >> !!! Multiple package instances within a single package slot have been pulled >> !!! into the dependency graph, resulting in a slot conflict: >> >> virtual/udev:0 >> >> (virtual/udev-208-r2::gentoo, installed) pulled in by >> >=virtual/udev-171:0/0=[gudev] required by >> (media-video/cheese-3.12.2::gentoo, installed) >> virtual/udev:0/0=[gudev] required by (x11-misc/colord-1.2.1::gentoo, >> installed) >> >> (virtual/udev-215::gentoo, ebuild scheduled for merge) pulled in by >> =virtual/udev-215 required by (games-util/xboxdrv-0.8.5-r1::gentoo, >> installed) >> (and 22 more with the same problem) >> > > > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
Samuli Suominen wrote: > let users do the rebuild (which is the obvious answer > to the output you posted) Reality check time, Samuli. Unless emerge says "Your dependencies are b0rk, please rebuild $P to fix it." that answer is nowhere near obvious. Watch out with the tunnel vision. //Peter
