Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

[Samuli Suominen]

On 02/01/13 15:29, Luca Barbato wrote:

last I checked prefix didn't have issues with the pkg-config bootstrap
either. there is no circular deps either.


check glib deps iirc some non-glibc platforms have few problems with it.


not if you enable USE=internal-glib. i've added the USE flag on request 
from vapier mostly, so we could punt pkg-config-lite from Portage. it 
should not depend on any of the stuff embedded (uclibc) has problems 
with anymore. as for anything other than uclibc, glibc, i'd like to see 
an bug, there isn't one

Re: [gentoo-dev] collision-protect -> protect-owned ?

[Alexandre Rostovtsev]

On Thu, 2013-01-03 at 00:25 -0500, Rick "Zero_Chaos" Farina wrote:
> On 01/03/2013 12:06 AM, Michał Górny wrote:
> > On Wed, 02 Jan 2013 19:49:02 -0800
> > ""Paweł Hajdan, Jr.""  wrote:
> > 
> >> It came up again with ,
> >> and I think it's worth to think about a better fix. I still keep hitting
> >> mysterious collisions with orphaned files from time to time.
> >>
> >> How about switching the developer profile from collision-protect to
> >> protect-owned, and proceeding with enabling protect-owned by default for
> >> all profiles? (not all developers are using the developer profile)
> > 
> > Well, it all depends.
> > 
> > protect-owned is easy and lazy. You just get errors on package
> > collisions, care about nothing else.
> > 
> > collision-protect cares about every collision. It can help you notice
> > that *your* package lefts orphaned files for some reason or writes
> > where it is not supposed to write.
> > 
> In the years I ran collision-protect I can say it prevented hundreds of
> merges of linux-firmware (because the kernel also installs firmware) and
> not much else.
> 
> Would you be able to share more specific insight on how
> collision-protect helped protect files that need to be protected where
> protect-owned would have been inferior?

It protects files that cannot be owned by any one package, but must still
be protected, for example /usr/share/glib-2.0/schemas/gschemas.compiled

This file contains the compiled database of all your gsettings schemas.
It needs to be updated by running glib-compile-schemas every time you
install or remove a gsettings schemas xml file. Ebuilds for glib-based
stuff have to run glib-compile-schemas in pkg_postinst(), and the
gschemas.compiled must remain outside package manager control.

However, some packages' build systems have "make" or "make install" call
glib-compile-schemas by default. A careless developer who doesn't use
collision-protect *and* doesn't pay attention to protect-owned's warning
messages might accidentally allow his ebuild to compile and install 
/usr/share/glib-2.0/schemas/gschemas.compiled in src_install(), marking
the file as owned by his ebuild. When his ebuild is uninstalled, the
gschemas.compiled file would be removed, breaking the system.

Re: [gentoo-dev] collision-protect -> protect-owned ?

[Rick "Zero_Chaos" Farina]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/03/2013 12:06 AM, Michał Górny wrote:
> On Wed, 02 Jan 2013 19:49:02 -0800
> ""Paweł Hajdan, Jr.""  wrote:
> 
>> It came up again with ,
>> and I think it's worth to think about a better fix. I still keep hitting
>> mysterious collisions with orphaned files from time to time.
>>
>> How about switching the developer profile from collision-protect to
>> protect-owned, and proceeding with enabling protect-owned by default for
>> all profiles? (not all developers are using the developer profile)
> 
> Well, it all depends.
> 
> protect-owned is easy and lazy. You just get errors on package
> collisions, care about nothing else.
> 
> collision-protect cares about every collision. It can help you notice
> that *your* package lefts orphaned files for some reason or writes
> where it is not supposed to write.
> 
In the years I ran collision-protect I can say it prevented hundreds of
merges of linux-firmware (because the kernel also installs firmware) and
not much else.

Would you be able to share more specific insight on how
collision-protect helped protect files that need to be protected where
protect-owned would have been inferior?

- -Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ5RZIAAoJEKXdFCfdEflKUxIP/1OApovsseVqUhIPPCQB1Z08
Yua5b2ripFwh/190eqNqvRFStp+K8ZChMMbfhjdjr3kzrqhpvOYHoM6/fdyz8yeC
BqOXfTg+wrHkPl5ql1YMv8ZHs8VrGF7ZIRMcwiylS0GaftPwIh1i0nD2ZYEEKhyz
FlIY9ZzX4dnKtNXeEahDTu38aLIwF0XWCcPcIOEtFEnaNjgmxVR1ZRmXk1ynB/VQ
XYaHNTL6irxA/YkImQR4JCBOAZKyjLZzy6vbLqsjic+MAzpfklmgVebnBY6hWkxK
FKfz13Gt9EWno3b0tTDa+OYrVMw0Z84GpMWPILCfChI3YcSj+ODi5ql2yM4avAiU
t7lQCTzOYfKCSZOXwAiN65DJL+ssq3DX3kJfA5/uyRmsJfGYMd2M9/F3lbmxhquN
lbzhzaJQyyPMCXmsKcKiAAioOL8FhP5jYjuYsH2b6XlCkNC7BB1TaY2FOlvoyZPF
50z31AguddD7ylofVKojU2BPJKF4pKPub5qy+hb0wyCmjEuNjp0W6t20azOZMNM/
LxPLLd7s6+YbgbS1pIbEWPwe2U1bHpkvb2RHZ8tPzCAvtlkT5LcUzV3OdHgZ3kxh
Z1hHPTCZJx+7y4aQFJAXvUx0RpnXQ92MsPPMeFGl/j4oIjNvphRlYR9wctDskWst
ECOuGbPwMI+PCq1K3DWk
=DY2e
-END PGP SIGNATURE-

Re: [gentoo-dev] collision-protect -> protect-owned ?

[Michał Górny]

On Wed, 02 Jan 2013 19:49:02 -0800
""Paweł Hajdan, Jr.""  wrote:

> It came up again with ,
> and I think it's worth to think about a better fix. I still keep hitting
> mysterious collisions with orphaned files from time to time.
> 
> How about switching the developer profile from collision-protect to
> protect-owned, and proceeding with enabling protect-owned by default for
> all profiles? (not all developers are using the developer profile)

Well, it all depends.

protect-owned is easy and lazy. You just get errors on package
collisions, care about nothing else.

collision-protect cares about every collision. It can help you notice
that *your* package lefts orphaned files for some reason or writes
where it is not supposed to write.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] collision-protect -> protect-owned ?

[Rick "Zero_Chaos" Farina]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/02/2013 10:49 PM, "Paweł Hajdan, Jr." wrote:
> It came up again with ,
> and I think it's worth to think about a better fix. I still keep hitting
> mysterious collisions with orphaned files from time to time.
> 
> How about switching the developer profile from collision-protect to
> protect-owned, and proceeding with enabling protect-owned by default for
> all profiles? (not all developers are using the developer profile)
> 
> Paweł
> 

I've been using protect-owned for months if not years with no issues at
all.  collision-protect is a broken implementation, the way it always
should have been was as protect-owned is.

Protecting unowned files is silly, it only matters when two packages
collide.

- -Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ5QKIAAoJEKXdFCfdEflKB+8P/3IG6e2yuDH/zGp+PXqRI0YH
cUEFw/L1hw8wvOp/rGgLDC0l8JSZTF8gzsiK5IG6ur3JR0+K/dLejR71ug1uPxo0
Vh5Rbq4QrWDWjw/KMhq2pvdVnCY7aK1y0er82vSx49k7bXXuNV3UMnDHP3GnZ/fT
w2cji4GT1cO96Ut2tjDRmUebcqcC0rd2eH2MnvewYvOnTuti14P4/1Z4Ur5p+tkf
+1yQTp+8ZNjSStAnxsuR5UjNE1b9Exr2+O8wPg5sC2H6fFqjVJjJ+BPA/KlKTVZw
mEoSq0+DjGH9ETsPj4/tLUztXf5H6DomT8BBEAPHuZF/WNBShmhyfv4R6iiQjD5v
bElSzjjbn5HfViprW9BmZ96xZCOw8FMWb2kuquVefWybGj+F4mI4LN4viBVXdNvf
y5vx3/fF9sPuu7wcyWCaHUjV2Nn3fa6CZebxOVXXr5KOMI6OpapIwasRZw+YZehD
pz5+FRCPAHixTixZL+AZIxzwuJuTA7EQlolwZ4EiW3jEVmbLQ+vClTFgxDNmDfAz
GqL5LsUY5wMcBKjusWoTJO4bx1A5Jnhz9p5xWQgfsvO4j8SycIq855jVTQ9TKpWF
rcDMFUyyCDRraLpplm6EWssCiscPrVXjxRlkdbIKMgSf4msMM6h1fVKg5WTeJwbN
q5QL1VtGtGccPS/7khtC
=Ljgj
-END PGP SIGNATURE-

[gentoo-dev] collision-protect -> protect-owned ?

[Paweł Hajdan, Jr.]

It came up again with ,
and I think it's worth to think about a better fix. I still keep hitting
mysterious collisions with orphaned files from time to time.

How about switching the developer profile from collision-protect to
protect-owned, and proceeding with enabling protect-owned by default for
all profiles? (not all developers are using the developer profile)

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others

[Mike Frysinger]

On Wednesday 02 January 2013 18:41:26 Pacho Ramos wrote:
> and similar in some eclasses (like eutils, multilib) but not others

i added it to the most popular eclasses and the ones i maintained.  i left the 
rest up to other people to add it and make sure things still worked.
-mike


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

Re: [gentoo-dev] emerge --depclean vs missing IUSE in older ebuild.. what exactly is right?

[Zac Medico]

On 01/02/2013 08:49 AM, Leho Kraav wrote:
> Ok my conclusion is then that gdm-3.4.1.ebuild should be patched for 
> [systemd?-], considering it seems otherwise fully compatible with current 
> stable pambase. Opinions?

Since gdm is using EAPI 4, sys-auth/pambase[consolekit?,systemd(-)?]
seems doable. You can file a bug at http://bugs.gentoo.org to have the
maintainers fix it (if they agree).
-- 
Thanks,
Zac

Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2

[Rick "Zero_Chaos" Farina]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/02/2013 06:11 PM, Pacho Ramos wrote:
> El lun, 29-10-2012 a las 10:39 -0400, Rich Freeman escribió:
>> On Mon, Oct 29, 2012 at 10:13 AM, Rick "Zero_Chaos" Farina
>>  wrote:
>>> I'm confident no one would
>>> attempt to block my adding eselect-bzip2 to the tree (aside from my poor
>>> coding skills),
>>
>> ++
>>
>>> but would anyone be interested in blocking using lbzip2
>>> by default?  It seems pretty safe and I've done dozens of full system
>>> builds etc.
>>
>> Why not just make it an option to start, advertise it by all means,
>> and then see how it turns out with volunteers before we make it the
>> default.  Going from nobody-has-heard-of-it to default overnight seems
>> a bit much.
>>
>> Rich
>>
>>
> 
> How this ended finally? :/
It ended with my setting PORTAGE_BZIP2_COMMAND="lbzip2" in my profile
and moving on with my life.  I am very not good at eselect scripts and
I've not had the time to dig at it. You are welcome to work on the
eselect script if you like.

> Thanks for the info!
> 

- -Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ5N63AAoJEKXdFCfdEflKdn0P/R9W6idHgpd+n7y5nyKQM9si
noHmFC6KHJSZJnjO8BlrhsN2HZrgZyPqPIlWLn5VwK+KcDTh0s1y4UGGh22a93qD
JodVbmmSJlnWA+EkzNloG+nTk1FxJYnmoL7o6/dhqv5x1Q/FD/xf0rAGCgTvDPSb
RuoMbCfkgSwZZlSSJtHr7Xd3w1psAgVemXNcG1C49AmnNrrmEkvawk5SNzg5Ruyn
UVMKSbLt1zEkRmUZHWS+lizN+GjFMVlaPEb6KK7ELbYWEMIjBihZ0WqdSWQ5Yxcn
yaZN9RTM2xel9tS+PEZjxwCBwb4ndXxuj51zK91WeTeWL+1wvwRXQ0nL+jFi3WfA
9nIHe26Cop5btYnCw2/5wlmKYReAxasql0ZVS8mrob5IgiptMIrxCAhCq8raJVZn
VD3+GiWzHYQRBUEkwQq/Qq7n7d5hgyd8l2/CCSgNUxmNbtFLoNWxPK5aVvEeb5EH
zyLH0eOQp4JA2ViZtnYgkviFRaEr9pa+Kc2S4BbvPTqYOX7Q7Ah2LMOw8uXQMefB
cNlVBa6ar5feAybWkmKH+c9n6mjAU9iCWyuoATSUMpSQ1dPmDnmKmxst4kARgMVK
Ou1F4mREQk7N23AqAnREF3b4RNLQqv6ff5GuxG4COjXZpIynFcm4o/x4nnzan6xr
ALCXZ5LIRk5D5K//oYJU
=yYs4
-END PGP SIGNATURE-

Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files

[Zac Medico]

On 01/02/2013 02:46 PM, Brian Dolbec wrote:
> On Mon, 2012-12-10 at 08:59 +0100, Ulrich Mueller wrote:
>>> On Mon, 10 Dec 2012, Sergei Trofimovich wrote:
>>
>>> gentoo-x86/profiles/updates $ LANG=C ls -1 --sort=time
>>> [long list omitted]
>>
>>> old entries are done in different context (comparing to 2012):
>>
>>> - some packages change names 2 or 3 times
>>> - slots have different meaning
>>
>>> moreover:
>>
>>> -  if you set your PORTDIR to different directory you'll get all
>>>that full update. And will break the system. Old profile entries
>>>used to break eclass-manpages and latex-base (due to double
>>>renaming)
>>
>> It's worse: Bad entries in the old files may go unnoticed for a long
>> time. But if such a file is updated for whatever reason, it will be
>> reprocessed on users' systems, including any bad entries contained in
>> it.
>>
>>> Thus the reason for removal is simple: old entries are potentially
>>> buggy as nobody verifies them.
>>
>> I wouldn't even know how to verify them.
>>
>> Let's remove that cruft. We can be extra conservative and keep five
>> years of backlog (i.e. everything from before 2008 would be removed
>> now).
>>
>> Ulrich
>>
> 
> OK, that seems to be some very good reasons to tree-clean them.
> 
> What's our next step?

It might be nice to document the removal policy in the developer
handbook, devmanual, or something.

> Tree-cleaners, does this fall into your department?

That seems fitting.

> Or should I prepare a list of files and/or updates to clean?

This command seems to do the trick:

$ ls -1 /usr/portage/profiles/updates/ | grep -Ev '(08|09|10|11|12|13)$'
1Q-2004
1Q-2005
1Q-2006
1Q-2007
2Q-2004
2Q-2005
2Q-2006
2Q-2007
3Q-2004
3Q-2005
3Q-2006
3Q-2007
4Q-2004
4Q-2005
4Q-2006
4Q-2007


-- 
Thanks,
Zac

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Peter Stuge]

Alexis Ballier wrote:
> - I have package foo and package bar, both depending on ffmpeg and
> canditates for a multilib build. However, package foo does not link to
> ffmpeg but simply spawns the 'ffmpeg' binary to process some files,
> package bar links to libavcodec. You need ffmpeg[multilib] for a
> multilib build of bar but not for foo. How do you distinguish between
> the two ?

foo.ebuild has RDEPEND=ffmpeg
bar.ebuild has DEPEND=ffmpeg[multilib?]

Right?


> - When an out-of-tree build is possible, it is more efficient to do it
>   that way while multilib-portage will probably run the full src_*
>   phases twice.

Certainly.


//Peter

Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others

[Mike Gilbert]

On 1/2/2013 6:54 PM, Mike Gilbert wrote:
> On 1/2/2013 6:41 PM, Pacho Ramos wrote:
>> What is the purpose of this stuff:
>> if [[ ${___ECLASS_ONCE_EUTILS} != "recur -_+^+_- spank" ]] ; then
>> ___ECLASS_ONCE_EUTILS="recur -_+^+_- spank"
>>
>> and similar in some eclasses (like eutils, multilib) but not others
>> (like python-single-r1 that I was looking some days ago for learning how
>> to use it)?
>>
>> Thanks a lot for the info
> 
> It prevents eclasses from being sourced more than once. It is meant as a
> performance enhancement for when eclasses inherit other eclasses. vapier
> posted some stats on this list a while back.
> 
> We have a similar thing in python-single-r1. We call it
> _PYTHON_SINGLE_R1 and assign a value of 1 at the bottom of the eclass.
> 

Here's the thread.

http://archives.gentoo.org/gentoo-dev/msg_18dab542c1c59873f8cb68c96cdf6619.xml



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others

[Mike Gilbert]

On 1/2/2013 6:41 PM, Pacho Ramos wrote:
> What is the purpose of this stuff:
> if [[ ${___ECLASS_ONCE_EUTILS} != "recur -_+^+_- spank" ]] ; then
> ___ECLASS_ONCE_EUTILS="recur -_+^+_- spank"
> 
> and similar in some eclasses (like eutils, multilib) but not others
> (like python-single-r1 that I was looking some days ago for learning how
> to use it)?
> 
> Thanks a lot for the info

It prevents eclasses from being sourced more than once. It is meant as a
performance enhancement for when eclasses inherit other eclasses. vapier
posted some stats on this list a while back.

We have a similar thing in python-single-r1. We call it
_PYTHON_SINGLE_R1 and assign a value of 1 at the bottom of the eclass.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages

[Chí-Thanh Christopher Nguyễn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pacho Ramos schrieb:
> Looks like finally you added yourself to metadata but with instructions 
> to bug-wranglers to CC you and assign to herd. I would like to confirm 
> this way of assigning things

The difference is almost inconsequential in practice. Bugmail will be sent
to both assignee and CC:. Only for maintainers without bugzilla privileges
they need to ping their proxy to make certain updates to the bug.
x11 team has similar instructions in the metadata for their proxy
maintained package.


Best regards,
Chí-Thanh Christopher Nguyễn

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDkxhkACgkQ+gvH2voEPRAQZgCbBnoIB6/peK8UWwuz/dxJitLk
4NQAnirKXvPLW+mfnAWMuAiGGZGXNbl6
=Jkiy
-END PGP SIGNATURE-

[gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others

[Pacho Ramos]

What is the purpose of this stuff:
if [[ ${___ECLASS_ONCE_EUTILS} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_EUTILS="recur -_+^+_- spank"

and similar in some eclasses (like eutils, multilib) but not others
(like python-single-r1 that I was looking some days ago for learning how
to use it)?

Thanks a lot for the info


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

Re: [gentoo-dev] Make connman a global USE flag

[Pacho Ramos]

El sáb, 21-07-2012 a las 13:51 +0200, Pacho Ramos escribió:
> Several packages are using it with the same sense (support connman),
> maybe we should move it from local to global USEs, what do you think?

Will proceed then ;)


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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Pacho Ramos]

El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió:
> On Sun, 23 Sep 2012 16:49:13 +0200
> Thomas Sachau  wrote:
> 
> > It is not hard by itself to inherit an eclass. There is just the
> > limitation, that occurs with an eclass, e.g.:
> > 
> > -the one from mgorny only does it for autotools based ebuilds only and
> > even there only for libraries, headers and binaries are not done.
> > While one may create the same for cmake based ones, those are still
> > only for a subset of packages, since not all do use autotools/cmake
> > or are satisfied with a libs only solution
> > -the multilib-native eclass does extend it way more, but still has its
> > limitations, e.g. what happens with a new target ABI (like x32 on the
> > amd64 profile) or how are dependencies handled?
> > 
> > multilib-portage is the answer to those limitations, since it does
> > work for any target with multilib cross-compile support, can handle
> > things like the dependencies internally and can even work on not
> > prepared/modified ebuilds.
> > 
> > So before i invest even more time in getting this official, we should
> > better get to some conclusion, if we either go the route with eclass
> > based multilib cross-compile support with its limitations or if we
> > move this up to the package manager level.
> > 
> 
> Can't we get something in between ?
> 
> Unless I'm mistaken, portage-multilib has its limitations also:
> 
> - I have package foo and package bar, both depending on ffmpeg and
> canditates for a multilib build. However, package foo does not link to
> ffmpeg but simply spawns the 'ffmpeg' binary to process some files,
> package bar links to libavcodec. You need ffmpeg[multilib] for a
> multilib build of bar but not for foo. How do you distinguish between
> the two ?
> 
> - When an out-of-tree build is possible, it is more efficient to do it
>   that way while multilib-portage will probably run the full src_*
>   phases twice. mgorny's eclass is a solution to this for
>   autotools-utils based ebuilds. I have added basic support for this in
>   freebsd-lib some time ago also.
> 
> 
> 
> However, it is clear that USE=multilib is limited too. What we probably
> need, as I read in the draft you posted some time ago, is a
> MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an
> eclass, add them to IUSE of multilib-enabled packages and then you can
> use the USE-deps. When a new ABI gets added, add it to the list in the
> eclass and be done. You already have PM support for this :)
> 
> You can leverage the generic multilib building code you have to an
> eclass, so that you don't need to spec it; spec-ing it has its problems
> too: what happens if next year pkg-config is deprecated and now we
> shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not
> FOO_CONFIG_PATH. You probably need a small EAPI change to be able to
> implement sanely a generic solution into an eclass though.
> 
> My question to you would be: what are we missing from current EAPIs to
> be able to perfectly support multilib builds ?
> 
> A.
> 
> 

What finally occurred with this? What would be the problem of opting by
this "mixed" solution (eclass for some packages and PM features
requiring newer eapi for others)?

Thanks


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

Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages

[Pacho Ramos]

El jue, 11-10-2012 a las 08:13 +0200, Pacho Ramos escribió:
> El mié, 10-10-2012 a las 20:11 -0400, Jesus Rivero (Neurogeek) escribió:
> > On Wed, Oct 10, 2012 at 5:53 PM, Chí-Thanh Christopher Nguyễn
> >  wrote:
> > > Pacho Ramos schrieb:
> > >> I am noticing for a long time that bugs related with ekiga,
> > >> opal, yate... are completely unattended by voip team for
> > >> years. If nobody from that team is willing to maintain
> > >> them, please move them to maintainer-needed to, at least,
> > >> reflect reality.
> > >
> > >> Any news here? I can move that packages to maintainer-needed if you
> > >> send me the list of packages you don't want to maintain. Also,
> > >> maybe telepathy stuff could be moved to its own herd (that is
> > >> basically gnome team + tester... or maybe tester could join gnome
> > >> team ;))
> > >
> > > There is now one proxy maintainer for a couple of packages, he is
> > > currently waiting for voip overlay access in bug 437538. He will take
> > > care of linphone and related packages (see bug 399735 and its
> > > dependencies).
> > >
> > > Regarding the packages that can be moved to maintainer-needed: I think
> > > a good heuristic is if the package has several open bugs with no
> > > maintainer reaction, and hasn't been touched by anyone from voip herd
> > > in over a year. This would include the ekiga, opal and yate packages
> > > mentioned above.
> > >
> > I'd gladly take maintainership of opal and ekiga, if nobody wants them.
> > 
> > Cheers,
> > 
> 
> Would be nice as they need a lot of bumps and pending work 
> 

Looks like finally you added yourself to metadata but with instructions
to bug-wranglers to CC you and assign to herd. I would like to confirm
this way of assigning things with both as voip herd people didn't touch
ekiga related packages and, also, would be better to clarify things
before me going to their bugs and assigning them properly to comply
current metadatas (as I have seen some ekiga bugs still only assigned to
voip herd without you CCed)

Thanks


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

Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2

[Pacho Ramos]

El lun, 29-10-2012 a las 10:39 -0400, Rich Freeman escribió:
> On Mon, Oct 29, 2012 at 10:13 AM, Rick "Zero_Chaos" Farina
>  wrote:
> > I'm confident no one would
> > attempt to block my adding eselect-bzip2 to the tree (aside from my poor
> > coding skills),
> 
> ++
> 
> > but would anyone be interested in blocking using lbzip2
> > by default?  It seems pretty safe and I've done dozens of full system
> > builds etc.
> 
> Why not just make it an option to start, advertise it by all means,
> and then see how it turns out with volunteers before we make it the
> default.  Going from nobody-has-heard-of-it to default overnight seems
> a bit much.
> 
> Rich
> 
> 

How this ended finally? :/

Thanks for the info!


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

Re: [gentoo-dev] app-text/dbacl is up for grabs

[Pacho Ramos]

El jue, 27-12-2012 a las 21:40 +0100, Amadeusz Żołnowski escribió:
> Quoting Pacho Ramos (2012-12-27 12:20:11)
> > Steev contacted me few hours ago to tell me he won't maintain dbacl
> > anymore and, then, it's now up for grabs.
> > 
> > Thanks for taking care of it
> 
> If nobody is interested I can take it.
> 
> 

I guess nobody will take it in the near future, feel free to edit its
metadata

(I fixed some days ago his opened bugs, it's now "clean" then ;)


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

Re: [gentoo-dev] Packages up for grabs

[Alex Alexander]

On Thu, Jan 3, 2013 at 12:57 AM, Panagiotis Christopoulos <
pchr...@gentoo.org> wrote:

> On 22:52 Thu 20 Dec , Pacho Ramos wrote:
> > Due araujo no longer taking care of them:
> > dev-lang/gnu-smalltalk
> > ...
>
> I'm taking this one.
>
> --
> Panagiotis Christopoulos ( pchrist )
> ( Gentoo Lisp Project )
>

o_O

xD
-- 
Alex 

Re: [gentoo-dev] Packages up for grabs

[Panagiotis Christopoulos]

On 22:52 Thu 20 Dec , Pacho Ramos wrote:
> Due araujo no longer taking care of them:
> dev-lang/gnu-smalltalk
> ...

I'm taking this one.

-- 
Panagiotis Christopoulos ( pchrist )
( Gentoo Lisp Project )


pgpJt1_yi2GXq.pgp
Description: PGP signature

Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files

[Brian Dolbec]

On Mon, 2012-12-10 at 08:59 +0100, Ulrich Mueller wrote:
> > On Mon, 10 Dec 2012, Sergei Trofimovich wrote:
> 
> > gentoo-x86/profiles/updates $ LANG=C ls -1 --sort=time
> > [long list omitted]
> 
> > old entries are done in different context (comparing to 2012):
> 
> > - some packages change names 2 or 3 times
> > - slots have different meaning
> 
> > moreover:
> 
> > -  if you set your PORTDIR to different directory you'll get all
> >that full update. And will break the system. Old profile entries
> >used to break eclass-manpages and latex-base (due to double
> >renaming)
> 
> It's worse: Bad entries in the old files may go unnoticed for a long
> time. But if such a file is updated for whatever reason, it will be
> reprocessed on users' systems, including any bad entries contained in
> it.
> 
> > Thus the reason for removal is simple: old entries are potentially
> > buggy as nobody verifies them.
> 
> I wouldn't even know how to verify them.
> 
> Let's remove that cruft. We can be extra conservative and keep five
> years of backlog (i.e. everything from before 2008 would be removed
> now).
> 
> Ulrich
> 

OK, that seems to be some very good reasons to tree-clean them.

What's our next step?  
Tree-cleaners, does this fall into your department?  
Or should I prepare a list of files and/or updates to clean?
-- 
Brian Dolbec 


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

Re: [gentoo-dev] Local bindist descriptions

[Mike Frysinger]

On Wednesday 02 January 2013 12:58:01 Cyprien Nicolas wrote:
> Alexis Ballier wrote:
> > It's probably too idealistic but I tend to consider that global flags
> > should be enabled/disabled globally while local flags on a
> > per-package basis. bindist is really something you want to enable
> > globally.
> 
> On the other hand, "doc" is a global flag you don't want to enable
> globally.

or "vanilla" or "debug" or "examples" ...

i'm sure there are others too
-mike


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

Re: [gentoo-dev] Local bindist descriptions

[Cyprien Nicolas]

Alexis Ballier wrote:

It's probably too idealistic but I tend to consider that global flags
should be enabled/disabled globally while local flags on a
per-package basis. bindist is really something you want to enable
globally.


On the other hand, "doc" is a global flag you don't want to enable globally.

--
Cyprien (Fulax)

Re: [gentoo-dev] emerge --depclean vs missing IUSE in older ebuild.. what exactly is right?

[Leho Kraav]

Ok my conclusion is then that gdm-3.4.1.ebuild should be patched for 
[systemd?-], considering it seems otherwise fully compatible with current 
stable pambase. Opinions?

--
Sent from my Nokia N9On 31.12.12 17:34 Michał Górny wrote:
On Mon, 31 Dec 2012 17:22:16 +0200
Leho Kraav  wrote:

> Just bumped into something I haven't encountered before. Running amd64.
>
> Already had sys-auth/pambase-20101024-r2 (stable) installed. Then
> installed gnome-base/gdm-3.4.1-r3 binpkg, binhost had newer pambase,
> which is why this didn't surface before.
>
> Everything is fine for runtime, but emerge --depclean pukes with
> "sys-auth/pambase[consolekit] is not installed". Looking at this from 
> all angles, this condition *is* most certainly fulfilled.
>
> Trying to re-emerge gdm from source revealed that only
>  >=pambase-20120417 seems to fulfill its requirements. Initially I
> couldn't figure out why.
>
> Poking around in gdm-3.4.1-r3.ebuild L56 reveals [1]:
>
>  sys-auth/pambase[consolekit?,systemd?]
>
> This lead me to check the pambase-2010 ebuild and sure enough there is
> no IUSE="systemd" flag.
> Adding "systemd" to /var/db/pkg/sys-auth/pambase-20101024-r2/IUSE made
> emerge --depclean work just fine.
>
> Now, my question is: why does portage-2.1.11.31 not calculate a missing
> IUSE=systemd in ebuild for being the same as just USE="-systemd"? It
> feels like pambase-20101024-r2.ebuild [2] should fulfill gdm-3.4.1
> requirements just fine, but it doesn't, at least not for this portage 
> version.
>
> Am I missing anything known and obvious?

http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-870008.2.6.4

«Unless a 4-style default is specified, it is an error for a use
dependency to be applied to an ebuild which does not have the flag in
question in IUSE_REFERENCEABLE.»

which in understandable language means that without USE defaults, even
[-foo] matches only packages which have 'foo' in IUSE.

--
Best regards,
Michał Górny

Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
> Double-standards aside, I don't think the "original" implementation is
> what matters, so much as what works best for our users (and ourselves)
> in practice.

I don't think the "original" matters either. But I wouldn't mind having
libusb over libusbx, jpeg over libjpeg-turbo (did you notice any speed
increase on your computer?), openoffice(-bin) over libreoffice.

Only if one implementation is vastly better than the alternative, then I
would expect the distro to make the sane choice. Else it can be choosen
randomly during each install for what I care.

> Others have pointed out that we don't have enough data to safely
> switch the default, and I think that alone is sufficient reason to
> hold off for now, but once that data is collected if it makes sense to
> switch we should do so. We don't use XFree86 or LILO,

Using LILO is still documented as an alternative to GRUB:
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=10#doc_chap3


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

[Jeff Horelick]

On 1 January 2013 16:46, Diego Elio Pettenò  wrote:
> On 01/01/2013 22:29, Tony "Chainsaw" Vroon wrote:
>> That sounds like a clear win. If it has survived the tinderboxing there
>> likely isn't much to hold you back. As non-contentious topics sometimes
>> end up with no replies at all... consider 48 hours of radio silence an
>> implicit yes.
>
> It didn't survive. I'm not sure if all the bugs have been fixed now but
> at some point I had to stop the tinderboxing because it was hitting
> package failures, and then it was "fixed for next version" — which was
> difficult to test.
>
> So I would veto this _for the moment_. (I'd be happy to run another test
> _after_ the glibc-2.17 one.)
>
> --
> Diego Elio Pettenò — Flameeyes
> flamee...@flameeyes.eu — http://blog.flameeyes.eu/
>

I was unaware that the tinderbox run hadn't finished. I definetly
think it should be fully run through with pkgconf before we fully
consider switching the virtual. All the bugs that have been found were
fixed, last i checked, only 2 were not verified fixed, but I could not
reproduce and after ~2 months of asking people to verify whether the
bugs still existed on pkgconf-0.8.9, no one had replied with the
results of a test, so i closed them.

If you could run it through the tinderbox again Diego, that would be
great and we can finish evaluating based on those results.

Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

[Peter Stuge]

Rich Freeman wrote:
> >> i'd say never. there is no benefit in switching. pkg-config is the
> >> default implementation from freedesktop.org.
> >
> > That's one awful double standard. :\
> 
> Double-standards aside, I don't think the "original" implementation is
> what matters, so much as what works best for our users (and ourselves)
> in practice.

Sure thing! I agree with that, that is a pragmatic approach.


> Others have pointed out that we don't have enough data to safely
> switch the default

A good point.


> once that data is collected if it makes sense to switch we should
> do so.

I think that is fair, along with..


> We don't use XFree86 or LILO, and quite a few are eager to drop udev.
> The important thing is to offer users meaningful choices, and make the
> default whatever makes the most sense at the time we set it.

..always being open to re-evaluate and change the default again, if
that makes the most sense at a later time.


//Peter

PS. I for one would actually prefer LILO to be the Gentoo default. :)

Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

[Rich Freeman]

On Wed, Jan 2, 2013 at 10:44 AM, Peter Stuge  wrote:
> Samuli Suominen wrote:
>> i'd say never. there is no benefit in switching. pkg-config is the
>> default implementation from freedesktop.org.
>
> That's one awful double standard. :\

Double-standards aside, I don't think the "original" implementation is
what matters, so much as what works best for our users (and ourselves)
in practice.  Others have pointed out that we don't have enough data
to safely switch the default, and I think that alone is sufficient
reason to hold off for now, but once that data is collected if it
makes sense to switch we should do so.

We don't use XFree86 or LILO, and quite a few are eager to drop udev.
The important thing is to offer users meaningful choices, and make the
default whatever makes the most sense at the time we set it.

Rich

[gentoo-dev] Last rites: dev-python/pypy:1.8

[Mike Gilbert]

# Mike Gilbert  (03 Jan 2013)
# No longer maintained upstream.
# Please upgrade to PyPy 1.9 or 2.0.
# Removal in 30 days.
dev-python/pypy:1.8



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

[Peter Stuge]

Samuli Suominen wrote:
> i'd say never. there is no benefit in switching. pkg-config is the
> default implementation from freedesktop.org.

That's one awful double standard. :\

dev-libs/libusb is the default implementation from libusb.org, yet
you are astonishingly eager to *avoid* that it is the default in
virtual/libusb-1, even if ~keywords make it apply "only" to ~ systems.


> and since pkgconf upstream doesn't properly follow pkg-config upstream
> git and do necessary changes, like for bug 445796 it would mean
> pkg-config related bugs would have to be reported to double upstream
> and thus, not be maintainable

In the case of libusb and libusbx, libusbx have consistently
communicated that they are eager to *break* the API, and they have
indeed made at least one release with an outright change of existing
API, which broke things for library users. They released another
version with that change reverted a day or so later, but still.

I even asked you if you would consider swapping the default, but no.


> lose-lose situation for the switch

Funny that you should write that. I think it applies also when you
prefer libusbx over the default implementation from libusb.org.


Kind regards

//Peter

Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

[Matt Turner]

On Wed, Jan 2, 2013 at 4:11 AM, Samuli Suominen  wrote:
> i'd say never. there is no benefit in switching. pkg-config is the default
> implementation from freedesktop.org.
> pkg-config is now lighter and has less dependencies than before as the
> switch from bundled glib1 to glib2 allowed dropping of the popt library.

As a data point: pkgconfig and glib:2 are built during stage3 and
removed during --depclean. Switching to pkgconf avoids glib:2 entirely
and saves some stage3 building time.

Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

[Rafael Goncalves Martins]

On Wed, Jan 2, 2013 at 10:11 AM, Samuli Suominen  wrote:
> On 01/01/13 23:01, Jeff Horelick wrote:
>>
>> I would like to propose a switch of the order of DEPENDs in
>> virtual/pkgconfig to make dev-util/pkgconf[pkg-config] the default
>> choice for new installations.
>>
>> dev-util/pkgconf has less external dependencies, is lighter and is
>> faster than dev-util/pkgconfig while being now 100% compatible
>>
>> This switch has already been made by Funtoo, Alpine Linux and FreeBSD
>> with very little in the way of ill effects recently from any of those
>> 3 camps.
>>
>> There are no more pending bugs against pkgconf (and Diego did a
>> tinderbox run with it a while back) in Gentoo.
>>
>> pkgconf also has a upstream that is more than happy to work with us
>> specifically (or anyone for that matter) and I (a Gentoo developer) am
>> one of the upstream developers.
>>
>> If this is approved, I will make the change in ~2 weeks. I'm not
>> planning on making a news item because users should notice little
>> difference.
>>
>> Thanks
>> Jeff
>>
>
> i'd say never. there is no benefit in switching. pkg-config is the default
> implementation from freedesktop.org.
> pkg-config is now lighter and has less dependencies than before as the
> switch from bundled glib1 to glib2 allowed dropping of the popt library.
>
> and since pkgconf upstream doesn't properly follow pkg-config upstream git
> and do necessary changes, like for bug 445796 it would mean pkg-config
> related bugs would have to be reported to double upstream and thus, not be
> maintainable
>
> last I checked prefix didn't have issues with the pkg-config bootstrap
> either. there is no circular deps either.
>
> lose-lose situation for the switch, so over my commit access ;-)
>

I agree with you. The original implementation should be our default.
People interested in get rid of the glib dependency should be able to
replace pkg-config with pkgconf manually. No need to make an
"unofficial" implementation the default.

Regards,

--
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/

Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

[Luca Barbato]

On 02/01/13 13:11, Samuli Suominen wrote:
> On 01/01/13 23:01, Jeff Horelick wrote:
>> I would like to propose a switch of the order of DEPENDs in
>> virtual/pkgconfig to make dev-util/pkgconf[pkg-config] the default
>> choice for new installations.
>>
>> dev-util/pkgconf has less external dependencies, is lighter and is
>> faster than dev-util/pkgconfig while being now 100% compatible
>>
>> This switch has already been made by Funtoo, Alpine Linux and FreeBSD
>> with very little in the way of ill effects recently from any of those
>> 3 camps.
>>
>> There are no more pending bugs against pkgconf (and Diego did a
>> tinderbox run with it a while back) in Gentoo.
>>
>> pkgconf also has a upstream that is more than happy to work with us
>> specifically (or anyone for that matter) and I (a Gentoo developer) am
>> one of the upstream developers.
>>
>> If this is approved, I will make the change in ~2 weeks. I'm not
>> planning on making a news item because users should notice little
>> difference.
>>
>> Thanks
>> Jeff
>>
> 
> i'd say never. there is no benefit in switching. pkg-config is the
> default implementation from freedesktop.org.

And has its share of issues.

> pkg-config is now lighter and has less dependencies than before as the
> switch from bundled glib1 to glib2 allowed dropping of the popt library.

As if glib-2 is any lighter...

> and since pkgconf upstream doesn't properly follow pkg-config upstream
> git and do necessary changes, like for bug 445796 it would mean
> pkg-config related bugs would have to be reported to double upstream and
> thus, not be maintainable

Non sequitur at best. My interaction with both upstreams had been decent
though.

> last I checked prefix didn't have issues with the pkg-config bootstrap
> either. there is no circular deps either.

check glib deps iirc some non-glibc platforms have few problems with it.

lu

Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

[Samuli Suominen]

On 01/01/13 23:01, Jeff Horelick wrote:

I would like to propose a switch of the order of DEPENDs in
virtual/pkgconfig to make dev-util/pkgconf[pkg-config] the default
choice for new installations.

dev-util/pkgconf has less external dependencies, is lighter and is
faster than dev-util/pkgconfig while being now 100% compatible

This switch has already been made by Funtoo, Alpine Linux and FreeBSD
with very little in the way of ill effects recently from any of those
3 camps.

There are no more pending bugs against pkgconf (and Diego did a
tinderbox run with it a while back) in Gentoo.

pkgconf also has a upstream that is more than happy to work with us
specifically (or anyone for that matter) and I (a Gentoo developer) am
one of the upstream developers.

If this is approved, I will make the change in ~2 weeks. I'm not
planning on making a news item because users should notice little
difference.

Thanks
Jeff



i'd say never. there is no benefit in switching. pkg-config is the 
default implementation from freedesktop.org.
pkg-config is now lighter and has less dependencies than before as the 
switch from bundled glib1 to glib2 allowed dropping of the popt library.


and since pkgconf upstream doesn't properly follow pkg-config upstream 
git and do necessary changes, like for bug 445796 it would mean 
pkg-config related bugs would have to be reported to double upstream and 
thus, not be maintainable


last I checked prefix didn't have issues with the pkg-config bootstrap 
either. there is no circular deps either.


lose-lose situation for the switch, so over my commit access ;-)

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/02/2013 03:48 AM, Pacho Ramos wrote:
> El mar, 01-01-2013 a las 16:01 -0800, Zac Medico escribió:
>> On 01/01/2013 05:39 AM, Pacho Ramos wrote:
>>> El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
  pkg_postinst() {
 @@ -48,6 +56,8 @@
elog
fi
  
 +  echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
 elog "${ELINE}"; done
 +
# files/systemd/acpid.socket -> ListenStream=/run/acpid.socket
mkdir -p "${ROOT}"/run

 This could probably be moved to eutils.eclass to use it on this kind of
 ebuilds
>>>
>>> Well, "elog" part should be behind:
>>> if ! has_version "${CATEGORY}/${PN}"; then
>>> echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
>>> "${ELINE}"; done
>>> fi
>>>
>>
>> Not that `has_version "${CATEGORY}/${PN}"` is always true in
>> pkg_postinst, since the package is already installed. So, you should
>> choose one of these alternatives for it to work as intended:
>>
>> 1) call has_version in pkg_preinst
>> 2) use [[ ${REPLACING_VERSIONS} ]] instead
>>
> 
> Yeah, that is true (and looks like current acpid ebuild is buggy in
> this). I wouldn't have any problem on either solution, but using first
> one would work in all eapis, is there any reason for printing this kind
> of messages in pkg_postinst?

If you need to use pkg_postinst for any reason, you can still call
has_version in pkg_preinst and use a variable to store the result, like
this:

pkg_preinst() {
has_version "${CATEGORY}/${PN}"
has_version_result=$?
}

pkg_postinst() {
if [ ${has_version_result} -eq 0 ] ; then
elog "${CONFIGURATION_INSTRUCTIONS}"
fi
}
-- 
Thanks,
Zac

Re: [gentoo-dev] Dropping keywords, again

[Jeroen Roovers]

On Wed, 2 Jan 2013 12:36:36 +0100
Jeroen Roovers  wrote:

> You are supposed to[1] tell the arch team when you drop their keyword.


*PDL-2.4.11 (16 Jun 2012)
  
  16 Jun 2012; Sébastien Fabbro  +PDL-2.4.11.ebuild,
  +files/PDL-2.4.11-fortran.patch, +files/PDL-2.4.11-shared-hdf.patch,
  metadata.xml:
  Version bump. Added many use flags, previously assumed automagic'ed. Respect
  user fortran compiler and flags. Added a port_rm to remove generated files.
  Added sci as maintainer and a long description. USe the newer PDL homepage

There as well, I guess.



 jer


[1] http://devmanual.gentoo.org/keywording/index.html

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

El mar, 01-01-2013 a las 16:01 -0800, Zac Medico escribió:
> On 01/01/2013 05:39 AM, Pacho Ramos wrote:
> > El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
> >>  pkg_postinst() {
> >> @@ -48,6 +56,8 @@
> >>elog
> >>fi
> >>  
> >> +  echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
> >> elog "${ELINE}"; done
> >> +
> >># files/systemd/acpid.socket -> ListenStream=/run/acpid.socket
> >>mkdir -p "${ROOT}"/run
> >>
> >> This could probably be moved to eutils.eclass to use it on this kind of
> >> ebuilds
> > 
> > Well, "elog" part should be behind:
> > if ! has_version "${CATEGORY}/${PN}"; then
> > echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
> > "${ELINE}"; done
> > fi
> > 
> 
> Not that `has_version "${CATEGORY}/${PN}"` is always true in
> pkg_postinst, since the package is already installed. So, you should
> choose one of these alternatives for it to work as intended:
> 
> 1) call has_version in pkg_preinst
> 2) use [[ ${REPLACING_VERSIONS} ]] instead
> 

Yeah, that is true (and looks like current acpid ebuild is buggy in
this). I wouldn't have any problem on either solution, but using first
one would work in all eapis, is there any reason for printing this kind
of messages in pkg_postinst?


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

[gentoo-dev] Dropping keywords, again

[Jeroen Roovers]

*octave-3.6.2-r1 (11 Jun 2012)

  11 Jun 2012; Sébastien Fabbro 
  +octave-3.6.2-r1.ebuild: Re-add hdf5, some octave packages might need
  it. Do in source configuring for preventing more bugs. Drop hppa
  (needs hdf5)


You are supposed to[1] tell the arch team when you drop their keyword.


 jer


[1] http://devmanual.gentoo.org/keywording/index.html