Re: [gentoo-dev] Re: Documentation for sys-boot/grub:2
On Tue, Mar 20, 2012 at 23:34, Duncan <1i5t5.dun...@cox.net> wrote: > But with one of the other commands I tried, it was the reverse, help worked for it, but --help did nothing (at least it didn't > trigger a reboot as help cat did). Such issues could be caused by bad interaction of commands with the same name in different modules: command.lst: *cat: cat *help: help cat: minicmd help: minicmd Something I noticed is that in grub2-mkimage, --prefix option must come after --memdisk, and --config causes empty $prefix, --compression doesn't seem to do anything, and individually compressing modules works only for some of them. In short, GRUB is a mess (like usual). You might find the following script interesting — it is similar to grub2-mkstandalone, but selective wrt. modules (I still didn't manage to boot Linux in QEMU with EFI firmware, however): https://github.com/mkdesu/liberte/blob/master/src/root/helpers/gen-efi -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Re: Documentation for sys-boot/grub:2
On Tue, Mar 20, 2012 at 5:34 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Talking about which, should I actively pursue bug filing on it yet? With > gentoo, upstream, or both? If you're actively wanting those bugs now, > please do put an elog to that effect in the ebuild, and I'll start being > particular about stuff like help cat working, and filing bugs if it > doesn't! > By all means, please file your bugs! I will probably refer you upstream for most of them, so please register for an account on savannah.gnu.org. If you are reasonably sure that your issue is not caused by something Gentoo-specific, you file them upstream immediately.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/ffmpeg: ffmpeg-0.10.2.ebuild ChangeLog
On 20/03/12 10:40, Samuli Suominen wrote: > On 03/20/2012 07:36 PM, Alexis Ballier wrote: >> On Tue, 20 Mar 2012 12:06:30 +0200 >> Samuli Suominen wrote: >> if we want to make it a use expand, the only thing we need to agree on is the prefix i think: what about fftools ? ffmpegtools ? >>> >>> Maybe there could be use expand that could be reused by other ebuilds >>> too? Such as EXTERNAL_TOOLS ? >> >> is it really worth it ? these are by design package specific, so i dont >> see any gain in trying to merge them under an arbitrary common namespace >> >> fftools is generic enough to me so that libav ebuilds can adopt it too, >> if that's what matters >> > > you're right, +1 for fftools > For libav I'll provide just aviocat, graph2dot ismindex, qt-faststart and cws2fws under either a single useflag or unconditionally. The rest of the tools aren't of any use since avprobe superceeds them. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
[gentoo-dev] Re: Documentation for sys-boot/grub:2
Maxim Kammerer posted on Tue, 20 Mar 2012 21:31:53 +0200 as excerpted: > On Tue, Mar 20, 2012 at 18:07, Mike Gilbert wrote: >> So, my question to the community: what level of documentation do we >> want to put in the handbook? > > I think that the EFI usecase should be well-documented, since EFI is the > reason that many users migrate to GRUB 2. Currently, you're right. But consider that we're talking about unmasking grub2 to ~arch and ultimately to stable, at which point it should be in the handbook and all x86 and amd64 users will be getting it, that won't remain the case forever. >> Is there any other issue with grub:2 that would keep me from unmasking >> (adding keywords) on x86 and amd64? I plan on waiting for the 2.00 >> release. > > Note that whereas 1.99 searches for modules in $prefix, 2.00 searches > for them in $prefix/. FWIW, the 2.00 betas haven't been entirely smooth for me. beta0 was fine. beta1 would load to grub but would reboot when I tried to boot a kernel, so I masked it. beta2 is getting there, but there's still some problems with various interactive commands. IIRC it was help cat that triggered a reboot here, while cat --help (or was it cat -h?) works. But with one of the other commands I tried, it was the reverse, help --help did nothing (at least it didn't trigger a reboot as help cat did). Assuming those sorts of issues are gone by 2.00 release, it should be a reasonable target. But I'd definitely recommend thorough testing both at the maintainer level, and with an elog urging users who have manually unmasked it to file any remaining bugs ASAP, before it's unmasked to ~arch. Talking about which, should I actively pursue bug filing on it yet? With gentoo, upstream, or both? If you're actively wanting those bugs now, please do put an elog to that effect in the ebuild, and I'll start being particular about stuff like help cat working, and filing bugs if it doesn't! -- 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] Fix spurious dep to eselect-python
On Tue, Mar 20, 2012 at 5:20 PM, Alexis Ballier wrote:
> On Tue, 20 Mar 2012 17:09:55 -0400
> Mike Gilbert wrote:
>
>> On Tue, Mar 20, 2012 at 5:05 PM, Alexis Ballier
>> wrote:
>> > On Tue, 20 Mar 2012 17:57:29 -0300
>> > Alexis Ballier wrote:
>> >
>> >> On Tue, 20 Mar 2012 20:35:17 +0100
>> >> Arfrever Frehtes Taifersar Arahesis wrote:
>> >>
>> >> > 2012-03-20 17:53:56 Michał Górny napisał(a):
>> >> > > On Tue, 20 Mar 2012 17:41:39 +0100
>> >> > > Arfrever Frehtes Taifersar Arahesis
>> >> > > wrote:
>> >> > >
>> >> > > > 2012-03-20 05:29:20 Luca Barbato napisał(a):
>> >> > > > > Hi, I tried to avoid depending on eselect-python if the
>> >> > > > > useflag is disabled.
>> >> > > > >
>> >> > > > > Please test and review.
>> >> > > >
>> >> > > > The proper fix is to make python.eclass add dependency on
>> >> > > > app-admin/eselect-python only when ${CATEGORY}/${PN} is
>> >> > > > dev-lang/python, dev-java/jython or dev-python/pypy. See bug
>> >> > > > #341037.
>> >> > >
>> >> > > Couldn't we just push that dependency to the specific ebuilds?
>> >> >
>> >> > We want to control required version (>=20091230 in case of
>> >> > app-admin/eselect-python) in 1 place.
>> >> >
>> >>
>> >> this can be achieved by setting a variable that said ebuilds will
>> >> append to (R)DEPEND; no need for complex 'if then else' on CAT/PN
>> >> in an eclass for this.
>> >>
>> >
>> > or also by adding a new python-implementation.eclass instead of
>> > polluting an eclass used by hundreds of packages for only 3 special
>> > ones...
>> >
>>
>> A four-way if-then statement is not what I would call "complex". This
>> was already present in the eclass anyway, so there is no additional
>> "pollution".
>
> a four-way if-then with pattern matching / strcmp is slower than a
> constant variable assignment; it could matter when this is done
> everytime an ebuild inheriting it is sourced. it probably doesnt, but
> imho, its good practice to keep global scope code in eclasses as simple
> as possible.
>
Ah right. It is now being executed in global scope, so there is a
slight performance degradation there. Point taken.
Re: [gentoo-dev] Fix spurious dep to eselect-python
On Tue, 20 Mar 2012 17:09:55 -0400
Mike Gilbert wrote:
> On Tue, Mar 20, 2012 at 5:05 PM, Alexis Ballier
> wrote:
> > On Tue, 20 Mar 2012 17:57:29 -0300
> > Alexis Ballier wrote:
> >
> >> On Tue, 20 Mar 2012 20:35:17 +0100
> >> Arfrever Frehtes Taifersar Arahesis wrote:
> >>
> >> > 2012-03-20 17:53:56 Michał Górny napisał(a):
> >> > > On Tue, 20 Mar 2012 17:41:39 +0100
> >> > > Arfrever Frehtes Taifersar Arahesis
> >> > > wrote:
> >> > >
> >> > > > 2012-03-20 05:29:20 Luca Barbato napisał(a):
> >> > > > > Hi, I tried to avoid depending on eselect-python if the
> >> > > > > useflag is disabled.
> >> > > > >
> >> > > > > Please test and review.
> >> > > >
> >> > > > The proper fix is to make python.eclass add dependency on
> >> > > > app-admin/eselect-python only when ${CATEGORY}/${PN} is
> >> > > > dev-lang/python, dev-java/jython or dev-python/pypy. See bug
> >> > > > #341037.
> >> > >
> >> > > Couldn't we just push that dependency to the specific ebuilds?
> >> >
> >> > We want to control required version (>=20091230 in case of
> >> > app-admin/eselect-python) in 1 place.
> >> >
> >>
> >> this can be achieved by setting a variable that said ebuilds will
> >> append to (R)DEPEND; no need for complex 'if then else' on CAT/PN
> >> in an eclass for this.
> >>
> >
> > or also by adding a new python-implementation.eclass instead of
> > polluting an eclass used by hundreds of packages for only 3 special
> > ones...
> >
>
> A four-way if-then statement is not what I would call "complex". This
> was already present in the eclass anyway, so there is no additional
> "pollution".
a four-way if-then with pattern matching / strcmp is slower than a
constant variable assignment; it could matter when this is done
everytime an ebuild inheriting it is sourced. it probably doesnt, but
imho, its good practice to keep global scope code in eclasses as simple
as possible.
Re: [gentoo-dev] Fix spurious dep to eselect-python
On Tue, Mar 20, 2012 at 5:05 PM, Alexis Ballier wrote:
> On Tue, 20 Mar 2012 17:57:29 -0300
> Alexis Ballier wrote:
>
>> On Tue, 20 Mar 2012 20:35:17 +0100
>> Arfrever Frehtes Taifersar Arahesis wrote:
>>
>> > 2012-03-20 17:53:56 Michał Górny napisał(a):
>> > > On Tue, 20 Mar 2012 17:41:39 +0100
>> > > Arfrever Frehtes Taifersar Arahesis wrote:
>> > >
>> > > > 2012-03-20 05:29:20 Luca Barbato napisał(a):
>> > > > > Hi, I tried to avoid depending on eselect-python if the
>> > > > > useflag is disabled.
>> > > > >
>> > > > > Please test and review.
>> > > >
>> > > > The proper fix is to make python.eclass add dependency on
>> > > > app-admin/eselect-python only when ${CATEGORY}/${PN} is
>> > > > dev-lang/python, dev-java/jython or dev-python/pypy. See bug
>> > > > #341037.
>> > >
>> > > Couldn't we just push that dependency to the specific ebuilds?
>> >
>> > We want to control required version (>=20091230 in case of
>> > app-admin/eselect-python) in 1 place.
>> >
>>
>> this can be achieved by setting a variable that said ebuilds will
>> append to (R)DEPEND; no need for complex 'if then else' on CAT/PN in
>> an eclass for this.
>>
>
> or also by adding a new python-implementation.eclass instead of
> polluting an eclass used by hundreds of packages for only 3 special
> ones...
>
A four-way if-then statement is not what I would call "complex". This
was already present in the eclass anyway, so there is no additional
"pollution".
I have already committed Arfrever's patch. If anyone wants to move the
dependency into the ebuilds, you are welcome to do so; patching the
eclass was just faster/easier.
Re: [gentoo-dev] Fix spurious dep to eselect-python
2012-03-20 22:05:17 Alexis Ballier napisał(a):
> On Tue, 20 Mar 2012 17:57:29 -0300
> Alexis Ballier wrote:
>
> > On Tue, 20 Mar 2012 20:35:17 +0100
> > Arfrever Frehtes Taifersar Arahesis wrote:
> >
> > > 2012-03-20 17:53:56 Michał Górny napisał(a):
> > > > On Tue, 20 Mar 2012 17:41:39 +0100
> > > > Arfrever Frehtes Taifersar Arahesis wrote:
> > > >
> > > > > 2012-03-20 05:29:20 Luca Barbato napisał(a):
> > > > > > Hi, I tried to avoid depending on eselect-python if the
> > > > > > useflag is disabled.
> > > > > >
> > > > > > Please test and review.
> > > > >
> > > > > The proper fix is to make python.eclass add dependency on
> > > > > app-admin/eselect-python only when ${CATEGORY}/${PN} is
> > > > > dev-lang/python, dev-java/jython or dev-python/pypy. See bug
> > > > > #341037.
> > > >
> > > > Couldn't we just push that dependency to the specific ebuilds?
> > >
> > > We want to control required version (>=20091230 in case of
> > > app-admin/eselect-python) in 1 place.
> > >
> >
> > this can be achieved by setting a variable that said ebuilds will
> > append to (R)DEPEND; no need for complex 'if then else' on CAT/PN in
> > an eclass for this.
> >
>
> or also by adding a new python-implementation.eclass instead of
> polluting an eclass used by hundreds of packages for only 3 special
> ones...
Some functions in python.eclass need to know if they are called in ebuild of a
Python implementation.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Fix spurious dep to eselect-python
On Tue, 20 Mar 2012 17:57:29 -0300
Alexis Ballier wrote:
> On Tue, 20 Mar 2012 20:35:17 +0100
> Arfrever Frehtes Taifersar Arahesis wrote:
>
> > 2012-03-20 17:53:56 Michał Górny napisał(a):
> > > On Tue, 20 Mar 2012 17:41:39 +0100
> > > Arfrever Frehtes Taifersar Arahesis wrote:
> > >
> > > > 2012-03-20 05:29:20 Luca Barbato napisał(a):
> > > > > Hi, I tried to avoid depending on eselect-python if the
> > > > > useflag is disabled.
> > > > >
> > > > > Please test and review.
> > > >
> > > > The proper fix is to make python.eclass add dependency on
> > > > app-admin/eselect-python only when ${CATEGORY}/${PN} is
> > > > dev-lang/python, dev-java/jython or dev-python/pypy. See bug
> > > > #341037.
> > >
> > > Couldn't we just push that dependency to the specific ebuilds?
> >
> > We want to control required version (>=20091230 in case of
> > app-admin/eselect-python) in 1 place.
> >
>
> this can be achieved by setting a variable that said ebuilds will
> append to (R)DEPEND; no need for complex 'if then else' on CAT/PN in
> an eclass for this.
>
or also by adding a new python-implementation.eclass instead of
polluting an eclass used by hundreds of packages for only 3 special
ones...
Re: [gentoo-dev] Fix spurious dep to eselect-python
On Tue, 20 Mar 2012 20:35:17 +0100
Arfrever Frehtes Taifersar Arahesis wrote:
> 2012-03-20 17:53:56 Michał Górny napisał(a):
> > On Tue, 20 Mar 2012 17:41:39 +0100
> > Arfrever Frehtes Taifersar Arahesis wrote:
> >
> > > 2012-03-20 05:29:20 Luca Barbato napisał(a):
> > > > Hi, I tried to avoid depending on eselect-python if the useflag
> > > > is disabled.
> > > >
> > > > Please test and review.
> > >
> > > The proper fix is to make python.eclass add dependency on
> > > app-admin/eselect-python only when ${CATEGORY}/${PN} is
> > > dev-lang/python, dev-java/jython or dev-python/pypy. See bug
> > > #341037.
> >
> > Couldn't we just push that dependency to the specific ebuilds?
>
> We want to control required version (>=20091230 in case of
> app-admin/eselect-python) in 1 place.
>
this can be achieved by setting a variable that said ebuilds will append
to (R)DEPEND; no need for complex 'if then else' on CAT/PN in an eclass
for this.
Re: [gentoo-dev] Fix spurious dep to eselect-python
2012-03-20 17:53:56 Michał Górny napisał(a):
> On Tue, 20 Mar 2012 17:41:39 +0100
> Arfrever Frehtes Taifersar Arahesis wrote:
>
> > 2012-03-20 05:29:20 Luca Barbato napisał(a):
> > > Hi, I tried to avoid depending on eselect-python if the useflag is
> > > disabled.
> > >
> > > Please test and review.
> >
> > The proper fix is to make python.eclass add dependency on
> > app-admin/eselect-python only when ${CATEGORY}/${PN} is
> > dev-lang/python, dev-java/jython or dev-python/pypy. See bug #341037.
>
> Couldn't we just push that dependency to the specific ebuilds?
We want to control required version (>=20091230 in case of
app-admin/eselect-python) in 1 place.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Documentation for sys-boot/grub:2
On Tue, Mar 20, 2012 at 18:07, Mike Gilbert wrote: > So, my question to the community: what level of documentation do we > want to put in the handbook? I think that the EFI usecase should be well-documented, since EFI is the reason that many users migrate to GRUB 2. > Is there any other issue with grub:2 that would keep me from unmasking > (adding keywords) on x86 and amd64? I plan on waiting for the 2.00 > release. Note that whereas 1.99 searches for modules in $prefix, 2.00 searches for them in $prefix/. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/ffmpeg: ffmpeg-0.10.2.ebuild ChangeLog
On 03/20/2012 07:36 PM, Alexis Ballier wrote: On Tue, 20 Mar 2012 12:06:30 +0200 Samuli Suominen wrote: if we want to make it a use expand, the only thing we need to agree on is the prefix i think: what about fftools ? ffmpegtools ? Maybe there could be use expand that could be reused by other ebuilds too? Such as EXTERNAL_TOOLS ? is it really worth it ? these are by design package specific, so i dont see any gain in trying to merge them under an arbitrary common namespace fftools is generic enough to me so that libav ebuilds can adopt it too, if that's what matters you're right, +1 for fftools
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/ffmpeg: ffmpeg-0.10.2.ebuild ChangeLog
On Tue, 20 Mar 2012 12:06:30 +0200 Samuli Suominen wrote: > > if we want to make it a use expand, the only thing we need to agree > > on is the prefix i think: what about fftools ? ffmpegtools ? > > > > Maybe there could be use expand that could be reused by other ebuilds > too? Such as EXTERNAL_TOOLS ? is it really worth it ? these are by design package specific, so i dont see any gain in trying to merge them under an arbitrary common namespace fftools is generic enough to me so that libav ebuilds can adopt it too, if that's what matters
Re: [gentoo-dev] Fix spurious dep to eselect-python
On Tue, Mar 20, 2012 at 12:41 PM, Arfrever Frehtes Taifersar Arahesis
wrote:
> 2012-03-20 05:29:20 Luca Barbato napisał(a):
>> Hi, I tried to avoid depending on eselect-python if the useflag is disabled.
>>
>> Please test and review.
>
> The proper fix is to make python.eclass add dependency on
> app-admin/eselect-python only when
> ${CATEGORY}/${PN} is dev-lang/python, dev-java/jython or dev-python/pypy. See
> bug #341037.
>
Could you provide a patch against gentoo-x86 python.eclass for that? I
think you may have already done that, but things said in IRC get
forgotten.
Re: [gentoo-dev] Fix spurious dep to eselect-python
On Tue, 20 Mar 2012 17:41:39 +0100
Arfrever Frehtes Taifersar Arahesis wrote:
> 2012-03-20 05:29:20 Luca Barbato napisał(a):
> > Hi, I tried to avoid depending on eselect-python if the useflag is
> > disabled.
> >
> > Please test and review.
>
> The proper fix is to make python.eclass add dependency on
> app-admin/eselect-python only when ${CATEGORY}/${PN} is
> dev-lang/python, dev-java/jython or dev-python/pypy. See bug #341037.
Couldn't we just push that dependency to the specific ebuilds?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Fix spurious dep to eselect-python
2012-03-20 05:29:20 Luca Barbato napisał(a):
> Hi, I tried to avoid depending on eselect-python if the useflag is disabled.
>
> Please test and review.
The proper fix is to make python.eclass add dependency on
app-admin/eselect-python only when
${CATEGORY}/${PN} is dev-lang/python, dev-java/jython or dev-python/pypy. See
bug #341037.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Documentation for sys-boot/grub:2
I believe the only thing keeping GRUB 2 masked is a lack of "documentation". By this, I assume people are referring to the handbook. I have created a very minimal "quick start" guide that could be adapted for the handbook. It relies on the grub2-mkconfig command auto-detecting most things, which actually works pretty well. http://wiki.gentoo.org/wiki/GRUB2_Quick_Start scarabeus created a guide a while back that goes into slightly more detail: http://dev.gentoo.org/~scarabeus/grub-2-guide.xml The wiki also has a longer GRUB2 guide. This goes into some of the more exotic setups. However, some of it is poorly written and I find editing it quite tedious. http://wiki.gentoo.org/wiki/GRUB2 So, my question to the community: what level of documentation do we want to put in the handbook? If the intent is just to get people up and running on Gentoo, I think adapting the quick start guide from the wiki is enough. grub2.info has a very detailed reference; I think we can refer people to that for manual/advanced configuration. Is there any other issue with grub:2 that would keep me from unmasking (adding keywords) on x86 and amd64? I plan on waiting for the 2.00 release.
Re: [gentoo-dev] www-servers herd is empty
El mar, 20-03-2012 a las 11:40 +0200, Samuli Suominen escribió: > On 03/20/2012 11:36 AM, Pacho Ramos wrote: > > El lun, 19-03-2012 a las 20:48 +, Markos Chandras escribió: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA512 > >> > >> On 03/19/2012 08:32 AM, Pacho Ramos wrote: > >>> El dom, 18-03-2012 a las 20:29 -0400, Chris Reffett escribió: > Hi, I'd be interested in helping with www-servers, but I would > have to help by proxy because I am not a dev yet. Chris Reffett > > On 03/18/12 15:27, Pacho Ramos wrote: > > With bass retirement (#391429) lcd has become empty, is anybody > > willing to join or should their packages be moved to > > maintainer-needed (CCing that empty herd to allow somebody > > joining in the future to easily resurrect the herd)? > > > > Thanks > > > >>> > >>> Thanks for offering your help, will CC gentoo-dev mailing list and > >>> proxy-maint to see how we could handle this case > >>> > >> It is very unlikely for proxy-maintainers to proxy an entire herd. Sorry > >> > >> - -- > >> Regards, > >> Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 > > > > We need to try to find a way to let him contribute, the problem is that > > I don't know much about Chris to know if he is ready to try to become a > > gentoo-dev in the near future :S > > I find the whole concept of www-servers herd flawed. > It's not very likely one person would be running many different servers, > and thus be able to contribute to them. > > Propably why the team has no members in the first place... > > Then, the way to go would be to move them to maintainer-needed and let people pick whatever they want. I agree and can do it myself just now if you let me do signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/ffmpeg: ffmpeg-0.10.2.ebuild ChangeLog
On Mon, 19 Mar 2012 21:15:45 -0600 Ryan Hill wrote: > On Mon, 19 Mar 2012 15:05:46 -0300 > Alexis Ballier wrote: > > > imho it doesnt hurt anyone to have fine-grained control > > > > what could be discussed is to put these into a use expand variable, > > to better distinguish between important useflags and less important > > ones > > > > is that what you mean by 'putting these under "tools" or > > something?' ? > > No, I meant one USE flag, called "tools", that builds and installs > all or none of them. Unless they have external dependencies, or > extraordinary build times, or licensing issues, then I can't see a > situation where someone would want or need to pick and choose like > this. If you disagree then I suppose an expanded variable is an > improvement, though I don't like them myself. > > Kudos on the USE flag descriptions in any case. Very informative. well, there's no extra dep nor licensing issue, and its not that they are big either, problem is with a merged useflag to rule them all we'll lose all the descriptions; i can imagine: tools - install random extra tools vs. a per tool useflag describing what it is for i clearly prefer the latter, even if it requires me 5 more minutes to decide the fate of the useflags i'll build the package with personally i dont like the tools useflag, the same i dont like the server one or the minimal one. they're too generic and, for this reason, useless if we want to make it a use expand, the only thing we need to agree on is the prefix i think: what about fftools ? ffmpegtools ?
Re: [gentoo-dev] www-servers herd is empty
On 03/20/2012 11:36 AM, Pacho Ramos wrote: El lun, 19-03-2012 a las 20:48 +, Markos Chandras escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/19/2012 08:32 AM, Pacho Ramos wrote: El dom, 18-03-2012 a las 20:29 -0400, Chris Reffett escribió: Hi, I'd be interested in helping with www-servers, but I would have to help by proxy because I am not a dev yet. Chris Reffett On 03/18/12 15:27, Pacho Ramos wrote: With bass retirement (#391429) lcd has become empty, is anybody willing to join or should their packages be moved to maintainer-needed (CCing that empty herd to allow somebody joining in the future to easily resurrect the herd)? Thanks Thanks for offering your help, will CC gentoo-dev mailing list and proxy-maint to see how we could handle this case It is very unlikely for proxy-maintainers to proxy an entire herd. Sorry - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 We need to try to find a way to let him contribute, the problem is that I don't know much about Chris to know if he is ready to try to become a gentoo-dev in the near future :S I find the whole concept of www-servers herd flawed. It's not very likely one person would be running many different servers, and thus be able to contribute to them. Propably why the team has no members in the first place...
Re: [gentoo-dev] Packages up for grabs due jokey retirement
El lun, 19-03-2012 a las 22:41 -0500, Paul Varner escribió: > On 3/19/12 2:26 PM, Pacho Ramos wrote: > > El lun, 19-03-2012 a las 10:56 -0500, Paul Varner escribió: > >> On 03/18/12 13:50, Pacho Ramos wrote: > >>> Due his retirement the following packages need a new maintainer: > >>> > >>> app-portage/maintainer-helper > >>> > >>> > >>> Thanks for taking them > >> > >> I've added app-portage/maintainer-helper to the tools-portage herd, > >> however, I've left it as maintainer-needed. So if anyone wants to take > >> it, feel free. The tools-portage herd will fix bugs for it as we find > >> the time. > > > > I disagree with leaving maintainer-needed as default assign, if you will > > fix bugs when you have time it's better than what I will do with > > maintainer-needed packages. > > Okay, I've taken out the maintainer-needed as the maintainer and have > just left it assigned to the herd. However, in reading through > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4, I > don't see a good mechanism to convey that the package is up for grabs, > but in the meantime go ahead and assign any bugs to the herd. > > Regards, > Paul > > Yeah, a mechanism for indicating a package is up for grabs would be interesting, the problem is how to prevent people from tagging as so a lot of packages and, then, making that mechanism completely useless as wouldn't distinct between "real" up for grabs packages or not "as real" :( But thanks a lot for taking care :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] www-servers herd is empty
El lun, 19-03-2012 a las 20:48 +, Markos Chandras escribió: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 03/19/2012 08:32 AM, Pacho Ramos wrote: > > El dom, 18-03-2012 a las 20:29 -0400, Chris Reffett escribió: > >> Hi, I'd be interested in helping with www-servers, but I would > >> have to help by proxy because I am not a dev yet. Chris Reffett > >> > >> On 03/18/12 15:27, Pacho Ramos wrote: > >>> With bass retirement (#391429) lcd has become empty, is anybody > >>> willing to join or should their packages be moved to > >>> maintainer-needed (CCing that empty herd to allow somebody > >>> joining in the future to easily resurrect the herd)? > >>> > >>> Thanks > >>> > > > > Thanks for offering your help, will CC gentoo-dev mailing list and > > proxy-maint to see how we could handle this case > > > It is very unlikely for proxy-maintainers to proxy an entire herd. Sorry > > - -- > Regards, > Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 We need to try to find a way to let him contribute, the problem is that I don't know much about Chris to know if he is ready to try to become a gentoo-dev in the near future :S signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/ffmpeg: ffmpeg-0.10.2.ebuild ChangeLog
On 03/20/2012 11:47 AM, Alexis Ballier wrote: On Mon, 19 Mar 2012 21:15:45 -0600 Ryan Hill wrote: On Mon, 19 Mar 2012 15:05:46 -0300 Alexis Ballier wrote: imho it doesnt hurt anyone to have fine-grained control what could be discussed is to put these into a use expand variable, to better distinguish between important useflags and less important ones is that what you mean by 'putting these under "tools" or something?' ? No, I meant one USE flag, called "tools", that builds and installs all or none of them. Unless they have external dependencies, or extraordinary build times, or licensing issues, then I can't see a situation where someone would want or need to pick and choose like this. If you disagree then I suppose an expanded variable is an improvement, though I don't like them myself. Kudos on the USE flag descriptions in any case. Very informative. well, there's no extra dep nor licensing issue, and its not that they are big either, problem is with a merged useflag to rule them all we'll lose all the descriptions; i can imagine: tools - install random extra tools vs. a per tool useflag describing what it is for i clearly prefer the latter, even if it requires me 5 more minutes to decide the fate of the useflags i'll build the package with personally i dont like the tools useflag, the same i dont like the server one or the minimal one. they're too generic and, for this reason, useless if we want to make it a use expand, the only thing we need to agree on is the prefix i think: what about fftools ? ffmpegtools ? Maybe there could be use expand that could be reused by other ebuilds too? Such as EXTERNAL_TOOLS ? - Samuli
Re: [gentoo-dev] gentoo-news repository migrated to git
On 03/15/12 at 08:11PM +0100, Michał Górny wrote: > On Thu, 15 Mar 2012 19:28:03 +0100 > Ulrich Mueller wrote: > > > Seems that nobody has announced it yet: > > > > The gentoo-news repository has moved from subversion to git some time > > ago. New news items should be committed to git only, because the > > master rsync doesn't pull from the svn repository any more. > > > > Especially, this concerns the news about udev unmasking that was > > committed (to svn) yesterday. > > Can we make svn read-only then? > Done. It will be archived in a few days. > -- > Best regards, > Michał Górny -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 pgpzUhDiyxHca.pgp Description: PGP signature
