Andreas K. Huettel | 18 Dec 22:21 2014
Picon

Perl team is dropping some packages


Hi all, 

the Perl team is dropping some packages (we've got enough already); the 
changes to the metadata.xml files will be done over the next days. 

(If you add packages using Perl to the tree, you don't have to add perl as co-
maintainer.)

Going to maintainer-needed, feel free to pick them up (yes, please do!!!):

app-accessibility/perlbox-voice
app-admin/pprocm
app-backup/snapback2
app-editors/XML-XSH2
app-i18n/cstools
app-misc/misterhouse
app-misc/smtm
app-text/po4a
dev-libs/syck
dev-util/autodia
mail-filter/spamassassin
net-analyzer/nikto
net-libs/libwhisker

The following already have an additional maintainer, who will become sole 
maintainer then:

dev-db/bucardo
media-gfx/galleryadd
(Continue reading)

Tim Harder | 14 Dec 06:14 2014
Picon

app-emulation/vagrant up for grabs

Hi,

I've dropped myself as maintainer of app-emulation/vagrant as I have no
time or interest to try debundling the path that upstream has taken and
rarely use it anyway.

If someone is interested, feel free to pick it up and reassign bugs
466344 and 505124 to yourself. However, my advice to those interested
(if you value your time and possibly sanity) you'll last rite
app-emulation/vagrant and add something like app-emulation/vagrant-bin
instead if you must have it in the main tree.

Tim
Brian Dolbec | 13 Dec 16:18 2014
Picon

Fw: FOSSASIA 2015, March 13-15 Singapore: Call for Speakers and Projects

Hi everyone... I received this email to my personal email account.
I don't know how I got on their list... but I am forwarding a somewhat
chopped version of their html email to the list. I removed a bunch of
the html stuff (pics, etc.) not relevant to the basic message.

If your interested, click on the first link for a web version of the
complete message.

Begin forwarded message:

Date: Sat, 13 Dec 2014 12:14:49 +0000
From: Hong Phuc | FOSSASIA <no-reply <at> fossasia.org>
To: FOSSASIA Supporter  <brian.dolbec <at> gmail.com>
Subject: FOSSASIA 2015, March 13-15 Singapore: Call for Speakers and
Projects

** FOSSASIA 2015
------------------------------------------------------------

** Call for Speakers Open for FOSSASIA'15 in Singapore from March 13-15
------------------------------------------------------------

View this email in your browser
(http://us9.campaign-archive2.com/?u=d5cf526b4ceea238da3512fb3&id=6b11ca2eee&e=c6ace56087)

Dear FOSSASIA Supporter,

please join us at FOSSASIA 2015 in Singapore, the premier Free and Open
Source technology event in Asia for developers, students, start-ups,
and contributors. In 2015 the event will take place from March 13-15.
(Continue reading)

Michał Górny | 12 Dec 23:31 2014
Picon

Last rites: net-zope/zope-fixers

# Michał Górny <mgorny <at> gentoo.org> (12 Dec 2014)
# No longer used by any package in the tree, and unlikely to be ever
# needed again for its main use is updating package code. Bug #532394.
# Removal in 30 days.
net-zope/zope-fixers

--

-- 
Best regards,
Michał Górny
Michał Górny | 11 Dec 11:36 2014
Picon

[PATCH 0/3] Remove parallel run support from multilib & multibuild

Hello, everyone.

Following a similar change in distutils-r1, I would like to remove
the parallel run support in multilib eclasses, and effectively from
multibuild completely.

The goal is to make things simpler, and follow PMS properly. Right now
the parallel runs imply running commands in a subshell. This has three
important implications:

1. variable exports and environment changes inside the implicit subshell
don't affect the outer scope -- developers are sometimes confused by
that,

2. parallel runs can collide if temporary files aren't named uniquely --
think of ffmpeg, waf,

3. 'die' called in a subshell is unsupported by the PMS, and didn't make
it into EAPI 6.

The side advantages are that we can get rid of multiprocessing inherit
and locking in multibuild_merge_root().

Possible issues: if people were relying on commands inside parallel not
to affect the outer environment (i.e. doing 'cd' and expecting the next
call to start in the initial location, or exporting variables and
expecting them to disappear), the ebuilds will fail randomly. However,
that's quite unlikely.

Your thoughts?
(Continue reading)

Michał Górny | 9 Dec 00:46 2014
Picon

metadata.xml un<herd/>-ization, v2

Hello, all.

So considering the previous thread, the Council and QA discussions, I
have prepared a new version of the metadata.xml update. To hopefully
make everyone happy, I come with this three-step process:

1. Add type="" attribute to <maintainer/> tag (see attached patch),

2. Convert <herd/> to <maintainer type="herd"/>,

3. Eventually drop <herd/> from DTD.

If you like the idea, I'll prepare a smart conversion script soon.

As for the exact details, I've pretty much decided to go for featurism
here, IOW making everyone happy. It also proves how absurd typing
maintainers is but if you really feel like having it, sure. The default
is 'developer', <herd/> tags would be converted into 'herd' and there
are other options including 'proxy-maintainer', 'project', 'team' meant
to fit all our wannabies. The diff explains the particular options.

The main benefit of this project over other ideas is that it preserves
backwards compatibility. We're adding a new attribute which should
simply be ignored by old tools. Since we still require <email/> to be
something valid, the output will change a bit but will still be
meaningful (or even more meaningful in some cases).

And since I removed <herd>no-herd</herd> some time ago, we can drop
<herd/> tags without worrying.

(Continue reading)

Michał Górny | 7 Dec 19:54 2014
Picon

RFC: USE=awt on sys-devel/gcc[gcj]

Hello, developers.

A quick sit: right now toolchain.eclass is a big blocker for multilib
that doesn't seem to want to fix itself. Considering the complexity of
the eclass, the amount of automagic dependencies and the size of
resulting patches ([1] for a start but it lacks EAPI conditionals), I'm
thinking: wouldn't it be better to just remove awt support completely?

Rationale: gcj doesn't seem to have any future, and has exactly two
reverse dependencies in Gentoo. However, only one of them -- gcj-jdk --
requires awt support. gcj-jdk can be supposedly used as a JDK for old
versions of Java, and supposedly can be used to bootstrap icedtea.
However, it never made it to stable and lags behind gcc. I've opened
a bug requesting lastriting it [2].

If we masked gcj-jdk and USE=awt on gcc, we could successfully continue
working on multilib without having to increase toolchain.eclass
by a few hundred lines. That would probably also be the first step
towards removing gcj, which could become possible once mcpdf is
introduced to replace pdftk [3].

What do you think? I've applied the masks listed here in
non-emul-linux-x86 subprofiles if you'd like to test them (not that
there's anything to test).

[1]:https://511832.bugs.gentoo.org/attachment.cgi?id=389818
[2]:https://bugs.gentoo.org/show_bug.cgi?id=531900
[3]:https://bugs.gentoo.org/show_bug.cgi?id=531898

--

-- 
(Continue reading)

Michał Górny | 7 Dec 11:37 2014
Picon

sys-devel/gcc::mgorny up for testing

Hello, developers and users.

As some of you know, the toolchain packages in Gentoo suffer from
lack-of-sanity issues and their maintainers are completely unwilling to
improve things. I have finally decided to start working on a fork of
the sys-devel/gcc ebuilds, and I have some bits ready for initial
testing in 'mgorny' repo, so I would like to know your opinion.

Before you start, the shortcomings are:

1. No cross-compilation support. If the project proves being a success
it will be readded at some point. However, I will likely fork glibc
first and work on a sane crossdev alternative.

2. No gcj support. Since the ebuild has been forked out of
toolchain.eclass, and the gcj support suffers a lot of issues there, I
decided there's no point in copying the code. Not sure if anybody
actually uses it, and if it is actually useful for anything but will
probably get reintroduced one day [above 'if' applies too].

3. No bootstrapping, fallbacks and possible some other random feature
support. The goal was pretty much to get gcc compiling first, and avoid
awful lot of effort if things prove to have no future.

4. Hardened is not tested. I think I have copied all the needed code
and fixed some stuff but I have no clue if it still works ;).

Now, the major changes are:

1. Most of the insanity removed. No more toolchain.eclass. The ebuild
(Continue reading)

Brian Dolbec | 6 Dec 07:11 2014
Picon

New portage-9999 plugin-sync system


For those people running portage-9999.  I've now merged the new
plugin-sync system into the master branch.  I've just added the
following einfo block to the 9999.ebuild.  I will be preparing
a news item for review soon.  We will be extending some of the modules
options, adding more capabilities such as git branch and depth options.

Also in this new sync system, is a new portage native postsync hook
system. It extends the hooks capabilities.  I will send another email
detailing those.  We are making a few more adjustments to it for better
backwards compatibility.

Additionally Devan <twitch153> has created a layman plugin-sync module
as part his GSOC project, so emerge/emaint will be able to perform
sync operations on layman installed overlays as well. layman-9999 will
be getting that plugin install capability soon.

Currently all available sync modules are installed.  The ebuild(s) will
be getting additional use flags to control which modules will be
installed once ready.

Please read over the einfo messages so that you can help those people
that ignored them when they upgraded portage.  There can also be cases
where the pre-einfo'd ebuild upgraded portage-9999 and consequently
they did not get the enifo messages.  In that case, their next emerge
--sync will do nothing.  They will need to set the auto-sync option in
their repos.conf/gentoo.conf file.  The new emaint sync module is
capable of syncing any repo, regardless of the auto-sync setting.

pkg_postinst() {
(Continue reading)

Pacho Ramos | 5 Dec 11:59 2014
Picon

(unknown)

Hi!

We found out that pulseaudio ebuild was modified by QA without QA
talking to the maintainers (gnome team) and without considering/updating
the relevant bugzilla issue at
https://bugs.gentoo.org/show_bug.cgi?id=519530

In that link it's explained a bit more why the ebuild was written in
that way and the problems we try to avoid. We have then hardmasked that
version until it's discussed THERE how to handle that situations.

And would really appreciate that next time we are even notified about a
change is going to be committed and don't need to see it in
packages.gentoo.org (well, in my case I am not all the time on IRC...
but I read the mail often and, also, Gilles and Leio can also be
contacted on IRC. You can also simply send a mail to the alias and give
us at least some days of timeout).

Thanks a lot

Anthony G. Basile | 5 Dec 12:00 2014
Picon

Re: Notes on toolchain

On 12/03/14 19:11, Michał Górny wrote:
> Hi,
>
> Some observations I made when forking gcc. Hope you find them helpful
> for toolchain.eclass work.
>
> 1. src_unpack() is likely unnecessary -- the default will unpack
> the fetched tarballs,
>
> 2. setup_multilib_osdirnames() doesn't do anything with gcc-4.9
> (possibly some older too) -- the sed expression doesn't match anything,
>
> 3.         *-linux)         needed_libc=no-fucking-clue;;
> very professional, isn't it?
>
> 4. if you enable --enable-version-specific-runtime-libs and add a small
> patch from funtoo, you can get rid of that big post-install library
> moving thing.
>
> 5. the 'gdbdir' definition fails on non-SYMLINK_LIB systems -- i.e.
> when gcc is actually in /usr/lib/gcc.
>
> 6. some things just ask for REQUIRED_USE rather than silent disabling.
>
> 7. you miss dep on doxygen with USE=cxx,doc.
>
Thanks for posting this.  Can I please see where you are working on this 
so I can test and make sure this is going to work with the stuff I do 
--- minor arches + alternative/embedded libc's.  I'd like to pre-empt 
issues and not repeat some of the headaches I hit with multilib because 
(Continue reading)


Gmane