[gentoo-dev] Re: Packages up for grabs due bass retirement

[Ryan Hill]

On Sun, 18 Mar 2012 20:25:58 +0100
Pacho Ramos  wrote:

> Due his retirement the following packages need a new maintainer:

> app-doc/ebookmerge

This is something bass wrote that grabs html manuals from
http://htmlhelp.berlios.de (which doesn't exist anymore - it moved to
http://code.google.com/p/htmlhelp/).  I don't really see the usefulness of it
since almost all of the content is just html versions of standard info/man
pages.  Anyways, it's completely broken as-is.


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/ffmpeg: ffmpeg-0.10.2.ebuild ChangeLog

[Samuli Suominen]

On 03/19/2012 07:39 AM, Ryan Hill wrote:

On Sun, 18 Mar 2012 13:54:03 + (UTC)
"Alexis Ballier (aballier)"  wrote:


aballier12/03/18 13:54:03

   Modified: ChangeLog
   Added:ffmpeg-0.10.2.ebuild
   Log:
   version bump

   (Portage version: 2.2.0_alpha91/cvs/Linux x86_64)




FFTOOLS="aviocat cws2fws ffeval graph2dot ismindex pktdumper qt-faststart 
trasher"

for i in ${FFTOOLS}; do
IUSE="${IUSE} +$i"
done



Is it really useful to have such fine-grained control over these?  ffmpeg
already has a ton of USE flags.  Would you consider just putting these under
"tools" or something?


I'd prefer to drop all USE flags which don't have external deps and just 
always install them


(We actually discussed this with beandog on #gentoo-media month ago or 
something, and he suggested same)

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-video/ffmpeg: ffmpeg-0.10.2.ebuild ChangeLog

[Ryan Hill]

On Sun, 18 Mar 2012 13:54:03 + (UTC)
"Alexis Ballier (aballier)"  wrote:

> aballier12/03/18 13:54:03
> 
>   Modified: ChangeLog
>   Added:ffmpeg-0.10.2.ebuild
>   Log:
>   version bump
>   
>   (Portage version: 2.2.0_alpha91/cvs/Linux x86_64)


> FFTOOLS="aviocat cws2fws ffeval graph2dot ismindex pktdumper qt-faststart 
> trasher"
> 
> for i in ${FFTOOLS}; do
>   IUSE="${IUSE} +$i"
> done


Is it really useful to have such fine-grained control over these?  ffmpeg
already has a ton of USE flags.  Would you consider just putting these under
"tools" or something?


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Walter Dnes]

On Sat, Mar 17, 2012 at 03:12:11AM -0400, Walter Dnes wrote

>   TOOT!!! (blowing my own horn).  See http://www.waltdnes.org/mdev/ for
> instructions on replacing udev with mdev for simple Gentoo systems.
> Hopefully more info will start arriving, allowing more complex systems
> to work with mdev.

  With more people getting interested, the project has been moved to
wiki format https://wiki.gentoo.org/wiki/Mdev to allow more people to
contribute.

-- 
Walter Dnes 

Re: [gentoo-dev] Gentoo CJK team empty, or anyone knows about ibus?

[Naohiro Aota]

Ben  writes:

> On 19 March 2012 01:09, Pacho Ramos  wrote:
>
>>
>> Will CC cjk team then to let them know you are interested to join (looks
>> like there are four devs in cjk alias...)
>
> But none of them seem active...

hmm, Matuu and I'm working on some bugs one-by-one... Are there any bugs
you'd like to have some action? I'll taking a look at them if any.

Regards,


pgp17c6l4PeEe.pgp
Description: PGP signature

Re: [gentoo-dev] Gentoo CJK team empty, or anyone knows about ibus?

[Naohiro Aota]

Hi,

It is great to hear Jack is willing to join cjk herd. I can help Jack
working on cjk bugs. But, to be honest, I'm not familiar with recruiting
process so I need some devs to do or to help me on the recruiting.

Also I've read the "Mentor Guide" [1] and found "your project lead must
be CC'd". I'm concerning about this "project". Does he need some project
to join in? or is it just enough to join cjk herd?

[1] http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml

Pacho Ramos  writes:

> El lun, 05-03-2012 a las 07:12 -0800, Jack Morgan escribió:
>
>> I'd like to help with this and will take a look at the bug below. I'd
>> like to be part of the cjk herd as well.
>> 
>> On 03/05/12 05:56, Samuli Suominen wrote:
>> > Really need a reply on http://bugs.gentoo.org/405777 and nobody seems to
>> > be listening the cjk@ alias
>> > 
>> > Should I just roll a dice and CC arch's?
>> 
>> 
>> 
>> Thanks,
>> 
>
> Will CC cjk team then to let them know you are interested to join (looks
> like there are four devs in cjk alias...)


pgpCJlQBsCd1E.pgp
Description: PGP signature

Re: [gentoo-dev] Re: RFD: EAPI specification in ebuilds

[Brian Harring]

On Mon, Mar 19, 2012 at 02:36:34PM +1300, Kent Fredric wrote:
> On 19 March 2012 14:12, Steven J Long  wrote:
> >
> > As for non-bash ebuilds, I have always agreed with antarus that they should
> > simply use a different extension. Adding a new extension per source language
> > is a *lot* cleaner than one per EAPI.
> 
> Ok: If we take this notion and enshrine it in stone:
> 
> If we assume Bash 4 is a seperate language from Bash 3, as its
> syntax-backwards-incompatible, is it fair to suggest that for some
> future EAPI which require Bash 4, that the extension change to suit?
> 
> ie:  move from .ebuild  to .ebuild4 , where '.ebuild' conveys the
> format is bash, and that '.ebuild4' is bash4 only?
> 
> That way you have a forwards declaration of the syntax/file format
> required to parse the file, but no declaration of the EAPI, so you're
> not breaking encapsulation.
> 
> This is breaking the direct file==eapi connection, but still
> maintaining a loose file<->eapi connection.
> 
> Its /sort/ of like the "one time extension change" proposal, except
> its less 'arbitrary' than something like .eb , and it gives us the
> future option of changing the suffix again if bash 5 comes out with
> different syntax.
> 
> Then we can do
> 
> .ebuild = EAPI 0 - 4& bash >= 3
> .ebuild4 = EAPI5 - 9& bash >= 4
> .ebuild5 = EAPI10 - 15 & bash >= 5
> 
> Thoughts?

This is a bad idea; it arbitrarily bleeds the bash version into the 
ebuild name, still requires an EAPI mechanism w/in the actual file, 
and is likely to break tools that have assumptions about extensions 
(even ones sooner or later written against such a setup).

Besides; it's not bash version as much as global scope settings, 
functions, etc, that are the issue.

Syntax is generally minor in comparison.
~harring

Re: [gentoo-dev] Gentoo CJK team empty, or anyone knows about ibus?

[Ben]

On 19 March 2012 01:09, Pacho Ramos  wrote:
>
> Will CC cjk team then to let them know you are interested to join (looks
> like there are four devs in cjk alias...)

But none of them seem active...

Re: [gentoo-dev] Re: RFD: EAPI specification in ebuilds

[Kent Fredric]

On 19 March 2012 14:12, Steven J Long  wrote:
>
> As for non-bash ebuilds, I have always agreed with antarus that they should
> simply use a different extension. Adding a new extension per source language
> is a *lot* cleaner than one per EAPI.

Ok: If we take this notion and enshrine it in stone:

If we assume Bash 4 is a seperate language from Bash 3, as its
syntax-backwards-incompatible, is it fair to suggest that for some
future EAPI which require Bash 4, that the extension change to suit?

ie:  move from .ebuild  to .ebuild4 , where '.ebuild' conveys the
format is bash, and that '.ebuild4' is bash4 only?

That way you have a forwards declaration of the syntax/file format
required to parse the file, but no declaration of the EAPI, so you're
not breaking encapsulation.

This is breaking the direct file==eapi connection, but still
maintaining a loose file<->eapi connection.

Its /sort/ of like the "one time extension change" proposal, except
its less 'arbitrary' than something like .eb , and it gives us the
future option of changing the suffix again if bash 5 comes out with
different syntax.

Then we can do

.ebuild = EAPI 0 - 4& bash >= 3
.ebuild4 = EAPI5 - 9& bash >= 4
.ebuild5 = EAPI10 - 15 & bash >= 5

Thoughts?

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

[gentoo-dev] Re: RFD: EAPI specification in ebuilds

[Steven J Long]

Firstly, wrt probing the ebuild for EAPI=.. I'd just like to point out that 
a regex is not required during the scan, and nor is restricting it to the 
first N lines, though the latter may be desirable and could trivially 
exclude comment and whitespace-only or empty lines.

Ciaran McCreesh wrote:
>Michael Orlitzky wrote:
>> Fair enough, but aren't you arguing the opposite point with Zac? If
>> ebuilds are data, fine, we write EAPI=4 somewhere and be done with
>> it. Anything not having that format is out-of-spec.
> 
> The problem is that right now there's no way to determine the format of
> the data until you already know the format of the data.
Well, we know it's bash.. ;)

> We hack around
> this by not allowing "drastic" format changes, where "drastic" includes
> "using things in newer versions of bash" and "not adding new global
> scope commands".
> 
> The question under discussion is whether we a) keep "what format the
> data is in" as being part of the data, but impose some strange and
> arbitrary conditions on it
Stipulating an allowed set of characters is in no way arbitrary, nor 
strange- we already have similar restrictions on category and package names, 
versions, keywords and USE flags, for example. Requiring that the EAPI 
assignment for a bash .ebuild must be a literal (ie EAPI="foo" or EAPI=foo 
or EAPI='foo') at the start of a line, is not hard to understand; as you 
said ebuild authors already have to deal with lots of other subtle 
restrictions. As Marc Schiffbauer said, EAPI "might be the most important 
constraint in an ebuild at all" (from this and earlier discussion, it's 
clear that it definitely is) -- ebuild developers have to know about it, and 
this is a simple, clear restriction. Michał Górny stated: "The most 
important ebuild variables like EAPI should be readable on sight, without 
having to lookup random variables, functions etc" and in fact, all ebuilds 
in the tree already use a string literal- it just makes more sense from a 
code readability pov, quite apart from anything else.

You mentioned indentation in another mail; afaics there is no problem with 
whitespace at the start of the line.

Ensuring EAPI declaration and sourced value match, has value beyond use in 
EAPI extraction: it's a sanity check that should be performed in any case, 
way before an ebuild hits the tree.

> , b) make a one-time change to have some kind
> of 'header' inside the file describing its format that isn't really part
> of the data itself, or c) admit that GLEP 55 already solved the problem
> and we might as well just fix the issue properly once and for all, even
> if GLEP 55's author is considered by some to be one of Satan's little
> minions.
> 
Regardless of your past behaviour, my objections to GLEP 55 are, and always 
have been, technical: it breaks encapsulation, which once implemented cannot 
be taken back. It results in a mess of filename extensions, which are 
confusing and irrelevant to end-users, as well as making other tools and 
scripts trickier to implement; a simple example: a highlighting editor would 
need to pattern-match the file extension. It's not needed: the simplest, 
least-invasive alternative already works, and should have been adopted years 
ago, when the Council asked for alternatives to be tried. The tree is 
clearly in shape to do so now, though.

Package versions have to be in the filename to avoid collisions, and indeed 
the information is relevant to both end-users and developers. EAPI, while 
vital to the mangler and of immediate concern to developers, matches neither 
of those. Since it is of immediate concern, restricting it to a string 
literal makes sense from both maintenance (which is why it matches tree-
usage) and implementation perspectives. And specifying what characters are 
allowed is a no-brainer; it's odd that that still has not been done, despite 
it also being a requirement for embedding EAPI in filenames.

Your motivation for GLEP-55 states: "In order to get the EAPI the package 
manager needs to source the ebuild." Given a suitable specification, that 
isn't the case. repoman checks and explicit documentation are all that's 
needed beyond that.

As for non-bash ebuilds, I have always agreed with antarus that they should 
simply use a different extension. Adding a new extension per source language 
is a *lot* cleaner than one per EAPI.

Regards,
Steve.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-03-18 23h59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2012-03-18 23h59 UTC.

Removals:
gnustep-libs/objcunit   2012-03-14 23:26:20 voyageur
gnustep-apps/cynthiune  2012-03-14 23:27:43 voyageur
gnustep-apps/gridlock   2012-03-14 23:27:44 voyageur
gnustep-apps/talksoup   2012-03-14 23:27:44 voyageur
kde-base/kdeaccessibility-colorschemes  2012-03-15 21:09:02 alexxy
kde-base/kdeaccessibility-iconthemes2012-03-15 21:09:02 alexxy
kde-base/kdebase-wallpapers 2012-03-15 21:09:02 alexxy
kde-base/kdebindings-csharp 2012-03-15 21:09:02 alexxy
kde-base/kdebindings-perl   2012-03-15 21:09:02 alexxy
kde-base/kdebindings-ruby   2012-03-15 21:09:02 alexxy
kde-base/kvtml-data 2012-03-15 21:09:02 alexxy
kde-base/smoke  2012-03-15 21:09:02 alexxy
dev-php/pecl-enchant2012-03-17 11:01:30 olemarkus
dev-php/pecl-idn2012-03-17 11:02:13 olemarkus
dev-dotnet/db4o 2012-03-18 12:12:21 pacho
app-text/man2html   2012-03-18 12:13:25 pacho
app-admin/pcihpview 2012-03-18 12:15:05 pacho
net-print/xpp   2012-03-18 12:15:50 pacho
dev-libs/libtranslate   2012-03-18 12:17:17 pacho
app-arch/q7z2012-03-18 12:18:34 pacho
net-im/skysentials  2012-03-18 12:19:37 pacho
sys-power/powersoftplus 2012-03-18 12:20:21 pacho
net-dns/dlint   2012-03-18 12:21:00 pacho
x11-terms/wterm 2012-03-18 12:21:42 pacho
dev-lang/cm3-bin2012-03-18 12:22:21 pacho
media-sound/alsa-driver 2012-03-18 12:23:09 pacho
app-laptop/thinkpad 2012-03-18 12:24:40 pacho
app-laptop/tpctl2012-03-18 12:24:41 pacho
app-emulation/libdsk2012-03-18 12:26:08 pacho
dev-lang/nemerle2012-03-18 12:28:28 pacho
net-p2p/monsoon 2012-03-18 12:29:29 pacho
sci-visualization/scidavis  2012-03-18 12:30:39 pacho
media-sound/esound  2012-03-18 12:32:02 pacho
gpe-base/libsoundgen2012-03-18 12:32:29 pacho
media-plugins/gst-plugins-esd   2012-03-18 12:32:54 pacho
x11-plugins/wmpop   2012-03-18 12:33:36 pacho
x11-plugins/wsoundserver2012-03-18 12:33:36 pacho
media-sound/extace  2012-03-18 12:34:11 pacho
app-emulation/lib7652012-03-18 12:34:57 pacho
app-laptop/configure-thinkpad   2012-03-18 12:35:38 pacho
sci-astronomy/ast   2012-03-18 12:37:47 pacho
dev-perl/Test-SimpleUnit2012-03-18 12:40:57 pacho
net-mail/vmailmgr   2012-03-18 12:45:31 pacho
net-mail/vmailmgr-tools 2012-03-18 12:45:31 pacho
net-misc/x25_utils  2012-03-18 12:47:03 pacho

Additions:
dev-python/python-poppler-qt4   2012-03-12 16:05:10 ssuominen
media-sound/qastools2012-03-13 01:21:14 pesa
dev-python/PyQtMobility 2012-03-13 11:44:34 pesa
app-misc/brewtarget 2012-03-14 00:16:53 pesa
dev-php/awl 2012-03-14 06:43:43 patrick
www-apps/davical2012-03-14 06:46:26 patrick
app-benchmarks/os-autoinst  2012-03-14 14:30:34 scarabeus
dev-ruby/coolio 2012-03-14 15:10:54 matsuu
net-misc/udpxy  2012-03-15 14:33:59 pva
app-crypt/shishi2012-03-15 15:01:21 eras
dev-perl/Unicode-EastAsianWidth 2012-03-15 18:58:55 ssuominen
x11-misc/compton2012-03-15 23:50:37 ssuominen
kde-misc/plasma-network-status  2012-03-16 10:27:00 johu
app-emulation/phpvirtualbox 2012-03-16 22:44:27 hwoarang
dev-python/futures  2012-03-17 10:19:23 radhermit
net-analyzer/2ping  2012-03-18 12:55:41 blueness
net-analyzer/flowgrind  2012-03-18 22:42:58 radhermit

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
gnustep-libs/objcunit,removed,voyageur,2012-03-14 23:26:20
gnustep-apps/cynthiune,removed,voyageur,2012-03-14 23:27:43
gnustep-apps/gridlock,removed,voyageur,2012-03-14 23:27:44
gnustep-apps/talksoup,removed,voyageur,2012-03-14 23:27:44
kde-base/kdeaccessibility-colorschemes,removed,alexxy,2

[gentoo-dev] Lastrite: dev-cpp/cppserv and dev-cpp/sptk

[Samuli Suominen]

# Samuli Suominen  (18 Mar 2012)
# The only working versions got declared obsolete by upstream
# See, http://bugs.gentoo.org/show_bug.cgi?id=402149#c9
# Removal in 30 days
dev-cpp/cppserv
dev-cpp/sptk

Re: [gentoo-dev] Re: Change USE flags when compiling with FEATURES=test

[Zac Medico]

On 03/18/2012 12:18 AM, Duncan wrote:
> What's you're definition of "sane"?  Does it include the
> /etc/portage/package.env and/or /etc/portage/env/cat-egory/pkg files 
> configuration options?
> 
> I've been using (and prefer) the latter for quite some time for various 
> per-package settings (tho not the particular one in question here) 
> without an issue.  The former is newer but somewhat more limited, to 
> make.conf style direct variable assignments, while the latter allows full 
> bash flexibility, which I take advantage of.

For best results, you should use package.env for FEATURES settings,
because it's applied very early, so it will even take care of enabling
USE=test when resolving dependencies. On the other hand, bashrc settings
are applied much later, when the ebuild is being executed by bash. As a
general rule of thumb, use package.env for anything that involves
variable settings alone, and use bashrc for anything that must be
executed by bash.
-- 
Thanks,
Zac

[gentoo-dev] www-servers herd is empty

[Pacho Ramos]

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



signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Packages up for grabs due bass retirement

[Pacho Ramos]

Due his retirement the following packages need a new maintainer:
app-admin/localepurge
app-admin/recursos
app-doc/ebookmerge
app-misc/gnomecatalog 
dev-embedded/gnap-dev
dev-embedded/gnap
net-analyzer/midas-nms 
net-im/coccinella
net-misc/htbinit
net-nds/lat


Thanks for taking them







signature.asc
Description: This is a digitally signed message part

[gentoo-dev] lcd herd is empty

[Pacho Ramos]

With jokey retirement (#118003) 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


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Packages up for grabs due jokey retirement

[Pacho Ramos]

Due his retirement the following packages need a new maintainer:
app-misc/ytree
app-portage/maintainer-helper
app-shells/pdmenu
dev-libs/libmba
dev-vcs/easygit
net-misc/italc
net-misc/proxytunnel
net-misc/x-lite (has a proxy maintainer!)
sys-fs/archfs


Thanks for taking them






signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Packages up for grabs due iluxa retirement

[Pacho Ramos]

Due his retirement the following packages need a new maintainer:
dev-cpp/cppserv


Thanks for taking them





signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Last-rite for dev-php/PEAR-DB_DataObject_FormBuilder

[Matti Bickel]

# Matti Bickel  (18 Mar 2012)
# masked for removal in 30 days, ~15 Apr 2012
# unmaintained upstream (bug #396963)
dev-php/PEAR-DB_DataObject_FormBuilder

Re: [gentoo-dev] Gentoo CJK team empty, or anyone knows about ibus?

[Pacho Ramos]

El lun, 05-03-2012 a las 07:12 -0800, Jack Morgan escribió:
> I'd like to help with this and will take a look at the bug below. I'd
> like to be part of the cjk herd as well.
> 
> On 03/05/12 05:56, Samuli Suominen wrote:
> > Really need a reply on http://bugs.gentoo.org/405777 and nobody seems to
> > be listening the cjk@ alias
> > 
> > Should I just roll a dice and CC arch's?
> 
> 
> 
> Thanks,
> 

Will CC cjk team then to let them know you are interested to join (looks
like there are four devs in cjk alias...)


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] media-optical and net-zope herds are empty

[Pacho Ramos]

El dom, 04-03-2012 a las 15:11 +0100, Dirkjan Ochtman escribió:
> On Sun, Mar 4, 2012 at 14:31, Pacho Ramos  wrote:
> > Only two for net-zope, but many more for, for example, sgml and
> > media-optical.
> 
> We just cleaned out most of the net-zope packages. The remaining
> net-zope packages will be maintained by the python team; the net-zope
> herd can probably be removed.
> 
> Cheers,
> 
> Dirkjan
> 
> 

Just moved two remaining packages to python ;)


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty

[Pacho Ramos]

El vie, 09-03-2012 a las 21:21 +0100, Pacho Ramos escribió:
> El vie, 09-03-2012 a las 21:15 +0100, Pacho Ramos escribió:
> > El vie, 09-03-2012 a las 22:02 +0200, Samuli Suominen escribió:
> > > On 03/09/2012 09:48 PM, Pacho Ramos wrote:
> > > > El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió:
> > > >> On Fri, 09 Mar 2012 09:02:23 +0100
> > > >> Pacho Ramos  wrote:
> > > >>
> > > >>> El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió:
> > >  El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió:
> > > > El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió:
> > > >> Even if they have some people in their mail aliases, looks like
> > > >> herds are empty. If nobody volunteers to join to them, I think
> > > >> we should drop that herds and move their packages to
> > > >> maintainer-needed in a week or so.
> > > >>
> > > >> What do you think?
> > > >>
> > > >
> > > > The same applies to "sgml" now that cryos is retiring :(
> > > 
> > >  and text-markup, I think it's the last empty herd now
> > > >>>
> > > >>> Maybe we could do the same as did in the past for openoffice herd:
> > > >>> - Change metadatas and bugs to assign them to maintainer-needed (and
> > > >>> reflect reality)
> > > >>> - Keep herd in metadatas and CCed them to bug reports
> > > >>>
> > > >>> The other option would be to simply drop that herds, assign packages
> > > >>> to maintainer-needed and wait developers to grab whatever they want
> > > >>
> > > >> For net-zope, I'd prefer dropping it. We decided to get rid of Zope,
> > > >> removed almost all relevant packages, so there's no point in keeping
> > > >> the herd.
> > > >>
> > > >
> > > > OK but, what about the rest? ;)
> > > 
> > > Please leave at least media-optical@ be as it is. Changing it doesn't 
> > > make any sense.
> > > 
> > > 
> > 
> > Well, the idea would be to get their bugs assigned to maintainer-needed
> > and media-optical CCed if somebody wants to take that stuff someday, it
> > would reflect better reality as, currently, their bugs are being
> > assigned to an empty herd (yes, xarthisius (I think he was in alias but
> > not officially in herd last time I checked, anyway it's only one
> > example, nothing personal against him of course :)). What will occur
> > when he simply drops his mail from alias as he never wanted to be a
> > member of that herd? What would occur if he only wants to maintain some
> > packages but others are getting ignored?
> > 
> > The idea to get them moved to "orphan" is to reflect reality and, that
> > way, try to get developers (or users willing to proxy maintain them)
> > involved on exact apps they really want to keep maintained.
> 
> As talked just now with Samuli, he added him to media-optical (both, to
> alias and herds.xml) and then, this no longer applies to media-optical
> obviously ;)
> 

Will then do the following:
- Add a  tag to their metadatas to get bugs assigned to
maintainer-needed
- Keep herd to get it CCed (like was done some weeks ago with openoffice
herd)

This applies to "sgml" and "text-markup" since media-optical is active
again and looks like net-zope packages will go away soon



signature.asc
Description: This is a digitally signed message part

Re: Anybody willing to take care of sgml herd? (Was: Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty)

[Pacho Ramos]

El dom, 18-03-2012 a las 13:38 -0400, Mike Gilbert escribió:
> On Sun, Mar 18, 2012 at 1:28 PM, Pacho Ramos  wrote:
> > Is anyone willing to join the herd? If not, maybe somebody could take a
> > few packages if they want to take care of only a set of them and not all
> > the beast :-/
> 
> I took a look at the sgml bugs list, and most of them seem pretty
> straightforward. I'll add myself and work on them as I have time.
> 
> Please don't let that stop you if you are thinking of picking up any
> of the packages in pacho's list.
> 
> 

Thanks a lot Mike :D


signature.asc
Description: This is a digitally signed message part

Re: Anybody willing to take care of sgml herd? (Was: Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty)

[Mike Gilbert]

On Sun, Mar 18, 2012 at 1:28 PM, Pacho Ramos  wrote:
> Is anyone willing to join the herd? If not, maybe somebody could take a
> few packages if they want to take care of only a set of them and not all
> the beast :-/

I took a look at the sgml bugs list, and most of them seem pretty
straightforward. I'll add myself and work on them as I have time.

Please don't let that stop you if you are thinking of picking up any
of the packages in pacho's list.

Anybody willing to take care of sgml herd? (Was: Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty)

[Pacho Ramos]

El dom, 18-03-2012 a las 18:01 +0100, Pacho Ramos escribió:
> El vie, 09-03-2012 a las 21:21 +0100, Pacho Ramos escribió:
> > El vie, 09-03-2012 a las 21:15 +0100, Pacho Ramos escribió:
> > > El vie, 09-03-2012 a las 22:02 +0200, Samuli Suominen escribió:
> > > > On 03/09/2012 09:48 PM, Pacho Ramos wrote:
> > > > > El vie, 09-03-2012 a las 16:57 +0100, Michał Górny escribió:
> > > > >> On Fri, 09 Mar 2012 09:02:23 +0100
> > > > >> Pacho Ramos  wrote:
> > > > >>
> > > > >>> El dom, 04-03-2012 a las 13:56 +0100, Pacho Ramos escribió:
> > > >  El dom, 04-03-2012 a las 13:51 +0100, Pacho Ramos escribió:
> > > > > El dom, 04-03-2012 a las 13:47 +0100, Pacho Ramos escribió:
> > > > >> Even if they have some people in their mail aliases, looks like
> > > > >> herds are empty. If nobody volunteers to join to them, I think
> > > > >> we should drop that herds and move their packages to
> > > > >> maintainer-needed in a week or so.
> > > > >>
> > > > >> What do you think?
> > > > >>
> > > > >
> > > > > The same applies to "sgml" now that cryos is retiring :(
> > > > 
> > > >  and text-markup, I think it's the last empty herd now
> > > > >>>
> > > > >>> Maybe we could do the same as did in the past for openoffice herd:
> > > > >>> - Change metadatas and bugs to assign them to maintainer-needed (and
> > > > >>> reflect reality)
> > > > >>> - Keep herd in metadatas and CCed them to bug reports
> > > > >>>
> > > > >>> The other option would be to simply drop that herds, assign packages
> > > > >>> to maintainer-needed and wait developers to grab whatever they want
> > > > >>
> > > > >> For net-zope, I'd prefer dropping it. We decided to get rid of Zope,
> > > > >> removed almost all relevant packages, so there's no point in keeping
> > > > >> the herd.
> > > > >>
> > > > >
> > > > > OK but, what about the rest? ;)
> > > > 
> > > > Please leave at least media-optical@ be as it is. Changing it doesn't 
> > > > make any sense.
> > > > 
> > > > 
> > > 
> > > Well, the idea would be to get their bugs assigned to maintainer-needed
> > > and media-optical CCed if somebody wants to take that stuff someday, it
> > > would reflect better reality as, currently, their bugs are being
> > > assigned to an empty herd (yes, xarthisius (I think he was in alias but
> > > not officially in herd last time I checked, anyway it's only one
> > > example, nothing personal against him of course :)). What will occur
> > > when he simply drops his mail from alias as he never wanted to be a
> > > member of that herd? What would occur if he only wants to maintain some
> > > packages but others are getting ignored?
> > > 
> > > The idea to get them moved to "orphan" is to reflect reality and, that
> > > way, try to get developers (or users willing to proxy maintain them)
> > > involved on exact apps they really want to keep maintained.
> > 
> > As talked just now with Samuli, he added him to media-optical (both, to
> > alias and herds.xml) and then, this no longer applies to media-optical
> > obviously ;)
> > 
> 
> Will then do the following:
> - Add a  tag to their metadatas to get bugs assigned to
> maintainer-needed
> - Keep herd to get it CCed (like was done some weeks ago with openoffice
> herd)
> 
> This applies to "sgml" and "text-markup" since media-optical is active
> again and looks like net-zope packages will go away soon
> 

Finally, only sgml is inside this case as it contains a lot of packages:
app-doc/halibut
app-emacs/nxml-mode
app-emacs/psgml
app-office/passepartout
app-text/asciidoc
app-text/build-docbook-catalog
app-text/docbook-dsssl-stylesheets
app-text/docbook-sgml-dtd
app-text/docbook-sgml-utils
app-text/docbook-sgml
app-text/docbook-xml-dtd
app-text/docbook-xml-simple-dtd
app-text/docbook-xsl-stylesheets
app-text/docbook2X
app-text/gentoo-guide-xml-dtd
app-text/gnome-doc-utils
app-text/grutatxt
app-text/highlight
app-text/html-xml-utils
app-text/html2text
app-text/html401
app-text/htmlrecode
app-text/htmltidy
app-text/linuxdoc-tools
app-text/openjade
app-text/opensp
app-text/robodoc
app-text/sablotron
app-text/scrollkeeper-dtd
app-text/scrollkeeper
app-text/sgml-common
app-text/sgmltools-lite
app-text/sgrep
app-text/txt2tags
app-text/webgen
app-text/xhtml1
app-text/xml2
app-text/xml2doc
app-text/xmlformat
app-text/xmlstarlet
app-text/xmlto
dev-ruby/xml-simple
www-client/htmlview

Is anyone willing to join the herd? If not, maybe somebody could take a
few packages if they want to take care of only a set of them and not all
the beast :-/


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Lastrites: dev-libs/libtomcrypt, app-admin/srlog2, dev-libs/tomsfastmath, gnome-extra/hardware-monitor, dev-dotnet/gluezilla

[Pacho Ramos]

# Pacho Ramos  (18 Mar 2012)
# Broken in several ways, removal in 30 days.
# Bug 262601
dev-libs/libtomcrypt
app-admin/srlog2
dev-libs/tomsfastmath

# Pacho Ramos  (18 Mar 2012)
# Upstream dead, nobody willing to maintain it and
# buggy, bug #348500. Removal in 30 days.
gnome-extra/hardware-monitor

# Pacho Ramos  (18 Mar 2012)
# Unmaintained, nothing needs it, bug #363205
# Removal in 30 days.
dev-dotnet/gluezilla



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ulrich Mueller]

> On Sun, 18 Mar 2012, Ralph Sennhauser wrote:

> If we want to keep .ebuild but avoid the compat issue another
> variant would be "EAPI in header comment and one-time change of
> ebuild location" or more formal:

> 6 EAPI in header comment and one-time change of ebuild location:

> - add a directory $CATEGORY/$PN/ebuilds to ebuild repositories.
> - all files in $CATEGORY/$PN/ebuilds are ebuilds and are using a
>   well defined first line to denote the EAPI.
> - For practical reasons the header should be a bash comment. PMs
>   shouldn't have to remove or skip first line from file for further
>   processing of ebuilds supporting bash comments.
> - the .ebuild extension can be kept but could be changed if ever
>   desired. This due to the filename only having meaning if the
>   EAPI of the file is known.

Similar ideas have been discussed before, in 2007 and 2009:



> Comparing this with GLEP 55 then this allows us to keep .ebuild in
> return of some overhead with roughly the same pros and cons
> otherwise, right?

>From a technical point of view, it's the same pros and cons. There are
however non-technical aspects for all these propositions. For example,
we would have to live with ebuilds in different directories for a long
transition period (as we would have to live with two file extensions
for a long time if we changed that).

Ulrich

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Rich Freeman]

On Sun, Mar 18, 2012 at 3:23 AM, Ralph Sennhauser  wrote:
> The ebuild extensions for GLEP 55
> would likely always be ebuild- as integers are reserved for
> future use by Gentoo.

Looking at GLEP 55 the proposal was ebuild- - not
ebuild-.  I don't believe there is any restriction that EAPIs
be integers or incremental in nature.

Don't mean to nitpick, but perhaps not all realize this...

Rich

Re: [gentoo-dev] Deprecate EAPI1?

[Pacho Ramos]

El mar, 13-03-2012 a las 11:52 -0700, Zac Medico escribió:
> On 03/11/2012 05:49 PM, Brian Harring wrote:
> > If people want to enforce the eapi1 is no longer used in the gentoo 
> > repo, that's fine- we stick a list of acceptable EAPI's into 
> > its layout.conf.
> 
> That sounds pretty reasonable, although I think a deprecation warning
> would be more appropriate that an outright ban. A deprecation warning
> should be sufficient to send the intended message, without placing an
> unnecessary burden on people doing simple version bumps or adding
> ebuilds that are already well tested though they happen to use an older
> EAPI.

I fully agree with this approach 


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ralph Sennhauser]

On Wed, 7 Mar 2012 21:41:02 +0100
Ulrich Mueller  wrote:

> Hi all,
> 
> The way how we currently specify the EAPI in ebuilds has some
> problems. For example, there is no sane way to allow usage of features
> of a new bash version in a new EAPI. So we are currently stuck with
> bash 3.2. Also changes of global scope behaviour, like addition of new
> global scope functions (similar to "inherit") are not possible.
> 
> These flaws are outlined in GLEP 55 [1]:
> | In order to get the EAPI the package manager needs to source the
> | ebuild, which itself needs the EAPI in the first place. Otherwise it
> | imposes a serious limitation, namely every ebuild, using any of the
> | future EAPIs, will have to be source'able by old package managers
> | [...]
> 
> The council has voted down GLEP 55 more than a year ago, but at the
> same time requested that a solution for the mentioned issues should be
> found. [2] However, there was no progress since then.
> 
> The issue arose again in bug 402167 [3] where several solutions have
> been discussed. Below, I try to summarise the possible options
> resulting from that discussion.
> 
> 
> *** Proposal 1: "Parse the EAPI assignment statement" ***
> 
> This first proposal would require that the syntax of the EAPI
> assignment statement in ebuilds matches a well defined regular
> expression. A scan of the Portage tree shows that the statement only
> occurs in the following variations (using EAPI 4 as example):
> 
>EAPI=4
>EAPI="4"
>EAPI='4'
> 
> Sometimes this is followed by whitespace or a comment (starting with
> a # sign). Also, with very few exceptions the EAPI assignment occurs
> within the first few lines of the ebuild. For the vast majority of
> ebuilds it is in line 5.
> 
> Written in a more formal way, appropriate for a specification:
> - Ebuilds must contain at most one EAPI assignment statement.
> - It must occur within the first N lines of the ebuild (N=10 and N=30
>   have been suggested).
> - The statement must match the following regular expression (extended
>   regexp syntax):
>   ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$
> 
> Note: The first and the third point are already fulfilled by all
> ebuilds in the Portage tree. The second point will require very few
> ebuilds to be changed (9 packages for N=10, or 2 packages for N=30).
> 
> The package manager would determine the EAPI by parsing the assignment
> with above regular expression. A sanity check would be added. Citing
> Zac Medico in [3]: "The fact that we can compare the probed EAPI to
> the actual EAPI variable after the ebuild is sourced seems like a
> perfect sanity check. We could easily detect inconsistencies and flag
> such ebuilds as invalid, providing a reliable feedback mechanism to
> ebuild developers."
> 
> This proposal comes in two variants:
> 1a) The change is applied retroactively for all EAPIs.
> 1b) It is only applied for EAPI 5 and later (which means that the
> result of the EAPI parsing would be discarded for earlier EAPIs).
> 
> 
> *** Proposal 2: "EAPI in header comment" ***
> 
> A different approach would be to specify the EAPI in a specially
> formatted comment in the ebuild's header. No syntax has been suggested
> yet, but I believe that the following would work as a specification:
> - The EAPI must be declared in a special comment in the first line of
>   the ebuild's header, as follows:
> - The first line of the ebuild must contain the word "ebuild",
>   followed by whitespace, followed by the EAPI, followed by
>   end-of-line or whitespace.
> 
> Again, the proposal comes in two variants:
> 2a) It is combined with a one time change of the file extension, like
> .ebuild -> .eb.
> 2b) The usual EAPI assignment statement in the ebuild is still
> required, at least for a transition period.
> 
> In the 2a case, the EAPI variable could be made read-only in bash
> before sourcing the ebuild. In the 2b case, a sanity check similar to
> the one mentioned above would be added.
> 
> 
> What do you think?
> 
> (I really hope for a constructive discussion here. So, if you want
> to comment that all of the above proposals suck and GLEP 55 is much
> superior, then please open a new thread for it.)
> 
> Ulrich
> 

Currently 5 proposals are listed on the wiki. [4]

While all of them have some temptations the actual goal is to make
obtaining the EAPI the very first step so everything else can be
defined in terms of EAPI and so immediately deployable in future. This
are changes in atom syntax like needed for GLEP 54 or those bash
feature often mentioned besides many other things one can think of. 

GLEP 55 requires changing ebuild extensions on a regular basis but
doesn't impose any limit on the ebuild format or atom syntax, only the
file extensions would be imposed. The ebuild extensions for GLEP 55
would likely always be ebuild- as integers are reserved for
future use by Gentoo. While for example .ebuild-5 is still recognised
as an ebuild; .eb .ebld .ebd .bld .

[gentoo-dev] Re: Change USE flags when compiling with FEATURES=test

[Duncan]

Kent Fredric posted on Sun, 18 Mar 2012 08:43:55 +1300 as excerpted:

> I think what would be more practical is a sane way to enable FEATURES=""
> on a per-package level like USE flags in portage, then you could enable
> FEATURES="test" for that one package and it would always build that
> package with USE="test"
> 
> Paludis does this already via an extended use.conf syntax:

> Perhaps portage does this already and I'm hiding under a rock, but I
> haven't seen it

What's you're definition of "sane"?  Does it include the
/etc/portage/package.env and/or /etc/portage/env/cat-egory/pkg files 
configuration options?

I've been using (and prefer) the latter for quite some time for various 
per-package settings (tho not the particular one in question here) 
without an issue.  The former is newer but somewhat more limited, to 
make.conf style direct variable assignments, while the latter allows full 
bash flexibility, which I take advantage of.

For example, the following /etc/portage/env/media-video/smplayer-0.6.9-r1 
allowed me to avoid editing the ebuild directly.  (IIRC it was a patch 
necessary to build the package with gcc-4.6.  I'm on smplayer-0.7.1 now, 
but the version-specific package-path limited deployment to just that one 
version.)

post_src_prepare () {
sed -i '1i#define OF(x) x' src/findsubtitles/quazip/*.h
}


See the /etc/portage/package.env and /etc/portage/env/ sections of the 
portage (5) manpage for the details.

So... Does that fit your definition of "sane"? =:^)

-- 
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