Re: [gentoo-dev] Packages up for grabs

2021-09-03 Thread Ultrabug

On 30/08/2021 13:37, Jakov Smolić wrote:

On 8/30/21 10:39 AM, Lars Wendler wrote:


the following packages are up for grabs:

app-emulation/sen (3 open bugs)
sys-process/nmon (2 open bugs)

I can take i3. If anybody else is interested feel free to join in.

I'll join you mate, cheers


Re: [gentoo-dev] Packages up for grabs

2021-08-04 Thread Ultrabug

On 04/08/2021 11:08, Sergei Trofimovich wrote:

Last batch of packages in search of a dedicated maintainer:


I've taken it, thanks Sergei

None of them should have any immediate problems.

Re: [gentoo-dev] [RFC] Dropping PyPy(3) back to ~arch

2021-03-02 Thread Ultrabug

On 02/03/2021 16:05, Michał Górny wrote:



I don't really want to remove it entirely or revert all the work we've
put into testing packages with it -- but I think we should move it to
~arch at the very least.


I agree with you, I'd drop it back to ~arch too.

Thanks for your work on keeping pypy up.

[gentoo-dev] Re: [gentoo-dev-announce] Developer commit timeline updates

2018-06-26 Thread Ultrabug
On 24/06/2018 00:36, Michał Górny wrote:
> Hi, everyone.
> I'd like to just make a short announcement that I've updated
> the developer commit timeline [1].  Besides the usual periodic update,
> there are two major changes:
> a. I've added commit counts to the bars (in the popups shown upon
> hovering the bar),
> b. I've created an additional timeline for determining activity of
> active Gentoo developers, as a partial replacement for the semi-broken
> 'slacker' script used by Undertakers [2].

Thank you for updating and sharing this!

I remember a sort of animated / timelapse version that was shared
someday, it was good too.

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-09 Thread Ultrabug
Hash: SHA256

On 08/05/2017 15:49, Michał Górny wrote:
> Dnia 8 maja 2017 15:27:18 CEST, Dirkjan Ochtman 
> napisał(a):
>> On Mon, May 8, 2017 at 12:49 PM, Mikle Kolyada
>>  wrote:
>>> Against. Do not touch things you are not working on, council
>>> has
>> already
>>> dropped m68k s390 and sh to exp few years ago. Now we have a
>>> big mess there and only, while ia64 sparc and co have slow but
>>> progress and mature enough stable profiles.
>> Obviously we should prevent big messes from happening. But it's
>> a mistake that things I don't work on don't affect me -- work
>> left over by lagging arch teams can affect me in many ways, in
>> terms of having to keep older versions of my packages working and
>> in the tree, and having to keep track of many more KEYWORDREQs
>> and STABLEREQs.
>> To me it's likely that the pace of stabilization for everyone is 
>> affected by the slower arches, in the sense that maintainers are
>> less likely to stabilize newer versions if they see that arches
>> can't keep up with previous requests. This means that even stable
>> amd64 users are affected to some extent by ppc being slow to
>> stabilize.
> Plus the usual mess of having to keep up with multiple large
> stablereqs for stuff where we need to stabilize newer while some
> arches are still two stabilizations behind.
> Not to mention when we want to stabilize a new version but the
> arches still haven't even keyworded it...

That !

We can all face that our latency is not good for our traction on a
wider user base.

Freeing ourselves from this kind of latency is energy saving and thus
a positive move imho.

>> Cheers,
>> Dirkjan


Re: [gentoo-dev] EAPI Cheat Sheet for review

2015-10-19 Thread Ultrabug
Hash: SHA256

On 17/10/2015 21:52, Ulrich Mueller wrote:
> In addition to the EAPI 6 specification, a draft of the "EAPI
> Cheat Sheet" is ready.

Great idea, I love it!

Thanks for your time on this

>  The second version doesn't combine the leaflet pages and may be
> better suited for online viewing. EAPI 6 is on pages 5 and 6. I
> also include the patch for the LaTeX source below.
> Please review.
> Ulrich
Version: GnuPG v2


Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

2015-08-11 Thread Ultrabug
Hash: SHA256

On 11/08/2015 16:32, Michał Górny wrote:
 Hello, everyone.
 Now that we're officially on git and can officially use pull
 requests to provide rapid community interaction, it'd be convenient
 to have a little better framework for pinging package maintainers.
 With the unofficial mirror/pull request project, I was either
 looking for project member GitHub accounts and pinging found
 project members by name, or talking to them directly on IRC.
 However, with the growth in number of pull requests this will
 become more and more inconvenient. Therefore, I think it's time to
 be able to mirror teams willing to work with GitHub community there
 for easier 'pings'.

I like the idea, sounds very handy

 I have two ideas right now:
 1. creating GitHub Gentoo project teams corresponding to willing
 Gentoo teams,
 2. preparing lists of GitHub usernames on project wiki pages.
 Solution 1. is cleaner. In this case, we create GitHub teams under 
 the Gentoo projects, and add appropriate Gentoo developers having 
 GitHub accounts to the teams. Then, in PRs we can just ping the
 whole team like @Gentoo/Qt or like.

+1 imho, clean  simple, only team and ppl willing to participate can
get there

 Solution 2. avoids adding any GitHub teams. In this case, in team
 wiki page we collect team member usernames like @Pesa,
 @kensington, ... so we could copy-paste it to pull requests. We
 still require extra effort when 'assigning' PRs but at least I
 don't have to lookup the same people over and over again.
 With some Wiki people help, we could even implement updating
 GitHub teams automatically following Wiki member changes.
 Your thoughts?
Version: GnuPG v2


Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources

2015-06-30 Thread Ultrabug
Hash: SHA256

On 30/06/2015 05:25, Zac Medico wrote:
 On 06/29/2015 07:24 PM, Michael Orlitzky wrote:
 On 06/29/2015 07:44 PM, Zac Medico wrote:

Having faced the exact same problem I have to say I agree 100% with
Zac. I'd like to say that Gentoo needs this kind of packages to stay
actual and that our NOGO (yes that's an actual joke) on Go packages is
not good for us nowdays.

 While it would certainly be possible to split out a number of
 separate ebuilds for Go libraries that are used *exclusively*
 by consul, what advantages would it have?
 Even in this limiting case,
 1. You avoid pointless rebuilds. You rebuild the library (and 
 probably the binary, for Go packages) when the library is
 upgraded rather than rebuilding everything whenever anything is
 From my experience, Go packages don't take very long to build.

+1, Go is not C, I have the same feeling

 2. Security. If upstream treats the packages as separate, a user 
 might hear that there's a security issue in libfoo but then run 
 eix and see that he doesn't have libfoo installed (because it's 
 That's a reasonable motivation. However, many of these libraries
 don't have any tags. So, you'll have to use the commit hashes if
 you want to test for vulnerabilities. In the case of the consul
 ebuild, the commit hashes of the libraries are available in the
 SRC_URI. I suppose that we could standardize a way to expose

+1, there is no strong tagging on every upstream. Maybe that's another
topic but handling git sub modules et al could be made easier while
satisfying our QA (or maybe make some exceptions)

 3. Chicken and egg problem. If the library only has one consumer
 and you keep it bundled with that consumer forever, then it will 
 probably only ever have one consumer. If somebody wants to use it
 in an overlay or something he'd have to pull in the whole 
 If a Go developer wants to use the libraries in question, then
 he'll probably use 'go get' to install them. I doubt the existence
 of an ebuild will have much relevance in people's decision to adopt
 a given Go library.
 4. Ebuild complexity. Now you have to compile e.g. three packages
 in src_compile, install three packages in src_install, etc. The
 result is more complicated than building once, three times.
 In the case of the consul ebuild, all of the libraries are
 automatically built when the ebuild calls the emake. Even without a
 Makefile, Go makes it trivial to build the dependencies.

Non live GIT ebuilds already make ebuilds more complex, this should
indeed be enough.

 5. One maintainer has to commit to maintaining all of the
 dependencies in addition to the program that he cares about.
 I guess that's a reasonable argument, depending on how much
 maintenance the dependencies require.

Since there is no real Go support as such, this would be a pain ...

 Someone actually has to do the work to split out the libraries,
 so it may not be a clear-cut win in some cases. But it's nicer to
 have them split out should that happen by magic.
 Considering that Go binaries are statically linked, you'll end up
 with a bunch of Go libraries installed that you don't need during

+1, this defeats Go's main advantage imho (not that I think it's
smart, but it's the actual fact)


Re: [gentoo-dev] CGA Web™ graphics standards

2015-04-02 Thread Ultrabug
Hash: SHA256

On 01/04/2015 20:29, Joshua Kinard wrote:
 Arguably the best 04/01 gag I've seen today.  Can we keep this? 
 It'll make browsing the site on old SGI machines so much easier...

+1, very good job guys it made my day. Thank you !
Version: GnuPG v2


Re: [gentoo-dev] New portage-9999 plugin-sync system

2014-12-10 Thread Ultrabug
Hash: SHA256

On 06/12/2014 07:11, Brian Dolbec wrote:
 For those people running portage-.  I've now merged the new 
 plugin-sync system into the master branch.  I've just added the 
 following einfo block to the .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.

Thank you guys, I'm eager to see it live :)
Version: GnuPG v2


Re: [gentoo-dev] Thank you

2014-02-10 Thread Ultrabug

On 02/06/2014 07:30 AM, Canek Peláez Valdés wrote:

Hi. TL;DR, this is basically just a THANK YOU to the Gentoo devs, so
you can go on your daily business if you don't want to read the rest
of it. No biggie.

Thank you for all the work you guys do and have done.
Thank you for not penalize progress.
Thank you for not being so rigid.
Thank you for keeping the distribution moving and evolving.
And finally, just thank you.

Thank you for your email mate, it's great to read such a positive one :)

 From a proud Gentoo+systemd+GNOME 3 user, thank you.



Re: [gentoo-dev] Maintainer-needed on many of my packages

2013-12-30 Thread Ultrabug

On 12/29/2013 01:19 AM, Robin H. Johnson wrote:


I'll try my best on this one.


Obviously I'll keep on working on this one along with the cluster team.



Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?

2013-12-12 Thread Ultrabug

On 12/10/2013 09:55 PM, Pacho Ramos wrote:

This has reminded me that maybe we should switch to cronie from
vixie-cron as default and recommended cron provider in Handbook. Last
time I checked, vixie-cron upstream was died while cronie forked it
fixing some bugs :/

What do you think?

+1 here, thx

Re: [gentoo-dev] Moving more arches to dev profiles

2013-08-21 Thread Ultrabug

On 08/21/2013 01:04 PM, Markos Chandras wrote:


It's time of year again to consider moving a few arches to dev-only status.

I propose the following arches to lose their stable keywords

- s390
- sh
- ia64
- alpha
- m68k
- sparc

The manpower on these arches is below acceptable levels and they often
block stabilizations
for many months. This also causes troubles to developers trying to get
rid of old versions of

I am CC'ing Mike and  on this to draw his attention since he seems to
be doing stabilizations and
keywording on a few of them. Moreover, Agostino is also doing a lot of
work on these arches.
Consider what will happen if he ever goes MIA or decides to retire ;)
We will probably end up
with a pile of stabilization bugs like the good old days.

In my opinion, having these arches be ~arch only, will improve the
overall user experience
since the arch teams will only have to test a single tree. It will
also help developers get rid of
old ebuilds and keep the portage tree healthy and reasonably updated.

If I get enough positive feedback on this, I will propose this in the
next Council's agenda.


Even if I'm not directly concerned by those arches, I agree with your 
point and can see its benefits for both devs and users.


Re: [gentoo-dev] RFC: Moving project pages to

2013-06-10 Thread Ultrabug

On 10/06/2013 17:15, Alex Legler wrote:

On 10.06.2013 14:36, Sergey Popov wrote:

09.06.2013 18:22, Alex Legler пишет:

I'd appreciate some input on below plan to move project pages to the Wiki:


The main motivation is to reduce the contents on the main website,
allowing for an easier makeover. Also, the Wiki exposes the contents and
an editing capability to more people, allowing for better collaboration.
Finally, this is an opportunity for projects to go through the contents
in their project spaces and update/remove outdated contents as well
Gentoo as a whole to remove orphaned projects.

Err, i do not want to say that wiki is not suite for this purpose, but
what's wrong with current situation? Is there something wrong with gorg?

The software is unmaintained, and the website template is next to
unmaintainable. I could go on a bit more about this, but I think these
two points *alone* justify moving away from it.

Well, it is not always clear how to use some of it's features, but apart
of that, why we should migrate to wiki?

Just to clear orphaned project pages?

No, I described multiple points. Again:
  - Less contents on www.g.o - we can much more easily relaunch it
  - Users can more easily contribute to project documentation
  - Update/purge project documentation
  - Remove orphaned projects

Why we can not just have official project pages, maintained as usual
through gorg and additional info in wiki(if it is needed, for example,
like we do on Gentoo Qt project page?

In case it wasn't clear enough yet: This is step 1 of n to get rid of
gorg and GuideXML for the website (read: not main docs) aspects of Gentoo.
Running two project page venues increases maintenance instead of
lowering it. I intend to have less work after this change, not more.

Do you have any concerns beyond 'never change a running system'?

+1, totally agree.. It's 2013 duh..

Gentoo / cluster

Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations

2013-01-18 Thread Ultrabug

Thanks for your work mate !

On 14/01/2013 21:24, Andreas K. Huettel wrote:

[CC'ing this to core so noone can complain afterwards.]

Since 48h did not lead to any responses positive or negative, I'll start
implementing the procedure as given in the original e-mail (quoted below).

As also said below, each arch will get a mail before I touch their profile
tree and after I've finished.

Cheers, Andreas

Am Samstag, 12. Januar 2013, 21:47:18 schrieb Andreas K. Huettel:

Hi everyone,

since Council has approved the creation of a fresh set of EAPI=5 13.0
profiles, I would like to volunteer for creating them. The proposed
procedure is outlined below in detail, and I'd be happy for comments.
[If anything below deviates from Council decision, please tell me- not my

One general question comes first, though: Right now, the releases/10.0
profile directory does the following things:
* mask too-old portage
* set eapi
* add USE=bzip2

Is there anything unrelated to EAPI=5 that absolutely must be added to the
new releases/13.0 directory in addition in your opinion? (Whether this is
the right place and was the right place in the beginning for USE=bzip2 is
another question.)


The procedure (all paths relative to profiles):

1) create directory eapi-5-files, with eapi (containing 5), skeletons for
package.stable.mask etc and a readme

2) copy releases/10.0 to releases/13.0, in releases/13.0:
* increase required portage version
* additionally inherit ../../eapi-5-files
* other changes as per question above?

3) for each arch in default/linux,
* announce on arch alias (to prevent overlapping commits)
* copy default/linux/${arch}/10.0 to default/linux/${arch}/13.0 and
* change inheritance in the new copy to inherit ../../../../releases/13.0
instead of ../../../../releases/10.0
* announce on arch alias (so future changes go into 13.0 tree)
[This describes the simple case. I realize that there are differences in
the directory structure, e.g. powerpc/ppc64/10.0, which is why this step
needs extra care.]

4) edit profiles.desc and copy all 10.0 lines to 13.0 lines, with an
initial setting dev (if dev or stable before) or exp (if exp before)
This makes repoman check against the new profiles when using developer

5) announce the state on the dev list, urging devs to update their symlink
manually and !test!

6) wait one / two weeks

7) in profiles.desc, mark all 13.0 profiles stable that were stable in
10.0, and remove the lines for the 10.0 profiles. This makes eselect
profile now only offer the new ones, and repoman test by default against
13.0 profiles.

8) mark all 10.0 profiles as deprecated by creating a deprecated file
(containing the replacement suggestion) in the directory. This makes
portage warn users to upgrade (suggesting a new profile for them), and
repoman ignore the 10.0 profiles.

9) long waiting time as decided by Council


Everything that does NOT use/inherit 10.0 will remain unaffected, and
whoever responsible may have to take care of that some time before (in
step 10) the main profile directory becomes EAPI=5. This means e.g.
hardened, ulibc, prefix or bsd.


Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-18 Thread Ultrabug

On 17/12/2012 13:15, Dirkjan Ochtman wrote:

On Mon, Dec 17, 2012 at 11:23 AM, Diego Elio Pettenò wrote:

I would say let's work on that so that portage can keep them there.
Although I'm more for /var/cache/portage myself, as both distfiles and
tree can be re-generated.






Re: [gentoo-dev] net-misc/rabbitmq-server up for grabs

2012-07-19 Thread Ultrabug
I'll take it tho I don't use it. If someone else want it feel free to
ping me, I share my toys.



On 18/07/2012 18:37, Benedikt Böhm wrote:
 i'm not using rabbitmq-server except as a dependency for
 app-admin/chef and i've no interest or time to fix it. Feel free to
 take it.

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-24 Thread Ultrabug
On 24/05/2012 03:19, Mark Wright wrote:
 Michael Weber writes:
 Clean cut turns of cvs access on a given and announced timestamp,
 rsync-generation/updates is suspended (no input - no changes), some
 magic scripts prepare the git repo (according to [3], some hours
 duration) and we all checkout the tree (might be some funny massive load).
 +1 for clean cut to git

clean cut +1

Re: [gentoo-dev] www-servers herd is empty

2012-03-21 Thread Ultrabug
Hash: SHA256

On 20/03/2012 10:47, Pacho Ramos wrote:
 El mar, 20-03-2012 a las 11:40 +0200, Samuli Suominen escribió:
 On 03/20/2012 11:36 AM, Pacho Ramos wrote:
 El lun, 19-03-2012 a las 20:48 +, Markos Chandras
 On 03/19/2012 08:32 AM, Pacho Ramos wrote:
 El dom, 18-03-2012 a las 20:29 -0400, Chris Reffett
 Hi, I'd be interested in helping with www-servers, but I
 would have to help by proxy because I am not a dev yet.
 Chris Reffett
 On 03/18/12 15:27, Pacho Ramos wrote:
 With bass retirement (#391429) lcd has become empty, is
 anybody willing to join or should their packages be
 moved to maintainer-needed (CCing that empty herd to
 allow somebody joining in the future to easily
 resurrect the herd)?
 Thanks for offering your help, will CC gentoo-dev mailing
 list and proxy-maint to see how we could handle this case
 It is very unlikely for proxy-maintainers to proxy an entire
 herd. Sorry
 - -- Regards, Markos Chandras / Gentoo Linux Developer / Key
 We need to try to find a way to let him contribute, the problem
 is that I don't know much about Chris to know if he is ready to
 try to become a gentoo-dev in the near future :S
 I find the whole concept of www-servers herd flawed. It's not
 very likely one person would be running many different servers, 
 and thus be able to contribute to them.

That's my case tbh, I co-maintain a www-servers package but don't feel
like being able to maintain the whole of them as I just don't use them

 Propably why the team has no members in the first place...
 Then, the way to go would be to move them to maintainer-needed and
 let people pick whatever they want. I agree and can do it myself
 just now if you let me do

I think that's a good idea and reasonable way to go.
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


[gentoo-dev] Re: [gentoo-commits] proj/betagarden:master commit in: dev-db/mongodb/files/, dev-db/mongodb/

2011-04-11 Thread Ultrabug
 deleted file mode 100644
 index 25f1299..000
 --- a/dev-db/mongodb/mongodb-1.8.0_rc1.ebuild
 +++ /dev/null
 @@ -1,65 +0,0 @@
 -# Copyright 1999-2010 Gentoo Foundation
 -# Distributed under the terms of the GNU General Public License v2
 -# $Header: $
 -inherit eutils scons-utils versionator
 -DESCRIPTION=A high-performance, open source, schema-free document-oriented 
 -LICENSE=AGPL-3 Apache-2.0
 -KEYWORDS=~amd64 ~x86
 - dev-lang/spidermonkey[unicode]
 - dev-libs/boost
 - dev-libs/libpcre
 - net-libs/libpcap
 - sys-libs/readline
 - sys-libs/ncurses
 -pkg_setup() {
 - enewgroup mongodb
 - enewuser mongodb -1 -1 /var/lib/${PN} mongodb
 -#src_prepare() {
 -#epatch ${FILESDIR}/${PN}-1.6.3-fix-scons.patch
 -src_compile() {
 - escons all || die Compile failed
 -src_install() {
 - escons --full --nostrip install --prefix=${D}/usr || die Install 
 - for x in /var/{lib,log,run}/${PN}; do
 - dodir ${x} || die Install failed
 - fowners mongodb:mongodb ${x}
 - done
 - doman debian/mongo*.1 || die Install failed
 - dodoc README docs/
 - newinitd ${FILESDIR}/${PN}.initd ${PN} || die Install failed
 - newconfd ${FILESDIR}/${PN}.confd ${PN} || die Install failed
 -src_test() {
 - escons smoke --smokedbprefix='testdir' test || die Tests failed

 diff --git a/dev-db/mongodb/mongodb-1.8.0.ebuild 
 similarity index 58%
 rename from dev-db/mongodb/mongodb-1.8.0.ebuild
 rename to dev-db/mongodb/mongodb-1.8.1.ebuild
 index 3849f20..74b7af6 100644
 --- a/dev-db/mongodb/mongodb-1.8.0.ebuild
 +++ b/dev-db/mongodb/mongodb-1.8.1.ebuild
 @@ -16,36 +16,50 @@ SRC_URI=${MY_P}.tar.gz;
  LICENSE=AGPL-3 Apache-2.0
  KEYWORDS=~amd64 ~x86
 - dev-lang/spidermonkey[unicode]
 +RDEPEND=!v8? ( =dev-lang/spidermonkey- )
 + v8? ( dev-lang/v8 )
 - dev-libs/libpcre
 - net-libs/libpcap
 + dev-libs/libpcre[cxx]
 + net-libs/libpcap
 - sys-libs/ncurses
 + sys-libs/ncurses
  pkg_setup() {
   enewgroup mongodb
   enewuser mongodb -1 -1 /var/lib/${PN} mongodb
 + if use v8; then
 + scons_opts=--usev8
 + else
 + scons_opts=--usesm
 + fi
 +src_prepare() {
 + epatch ${FILESDIR}/${PN}-1.8.1-fix-scons.patch
 + if use v8; then
 + # Suppress known test failure with v8:
 + #
 + sed -e '/add NumberLong /d' -i dbtests/jstests.cpp || die
 + fi
  src_compile() {
 - escons all || die Compile failed
 + escons ${scons_opts} all || die Compile failed
  src_install() {
 - escons --full --nostrip install --prefix=${D}/usr || die Install 
 + scons ${scons_opts} --full --nostrip install --prefix=${D}/usr || die 
 Install failed
   for x in /var/{lib,log,run}/${PN}; do
 - dodir ${x} || die Install failed
 + dodir ${x}
   fowners mongodb:mongodb ${x}
 @@ -57,5 +71,5 @@ src_install() {
  src_test() {
 - escons smoke --smokedbprefix='testdir' test || die Tests failed
 + scons ${scons_opts} smoke --smokedbprefix='testdir' test || die Tests 

Hi mate, thanks for working on mongodb fix/bump !

Just so you know, I'm working with @jbergstroem on this aswell, maybe
you could have a look at my overlay (ultrabug) and give your feedback
please ?


Gentoo / cluster

Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-admin/rsyslog: ChangeLog rsyslog-5.6.5.ebuild rsyslog-5.6.4.ebuild

2011-03-30 Thread Ultrabug
On 30/03/2011 16:12, Tomas Chvatal (scarabeus) wrote:
 scarabeus11/03/30 14:12:55

   Modified: ChangeLog rsyslog-5.6.5.ebuild rsyslog-5.6.4.ebuild
   Drop logrotate useflag. Fixes bug #344175.
   (Portage version: 2.2.0_alpha29/cvs/Linux x86_64)

 Revision  ChangesPath
 1.39 app-admin/rsyslog/ChangeLog

 file :
 diff :

 Index: ChangeLog
 RCS file: /var/cvsroot/gentoo-x86/app-admin/rsyslog/ChangeLog,v
 retrieving revision 1.38
 retrieving revision 1.39
 diff -u -r1.38 -r1.39
 --- ChangeLog 25 Mar 2011 09:27:20 -  1.38
 +++ ChangeLog 30 Mar 2011 14:12:55 -  1.39
 @@ -1,6 +1,10 @@
  # ChangeLog for app-admin/rsyslog
  # Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2
 -# $Header: /var/cvsroot/gentoo-x86/app-admin/rsyslog/ChangeLog,v 1.38 
 2011/03/25 09:27:20 ultrabug Exp $
 +# $Header: /var/cvsroot/gentoo-x86/app-admin/rsyslog/ChangeLog,v 1.39 
 2011/03/30 14:12:55 scarabeus Exp $
 +  30 Mar 2011; Tomáš Chvátal rsyslog-5.6.4.ebuild,
 +  rsyslog-5.6.5.ebuild:
 +  Drop logrotate useflag. Fixes bug #344175.
25 Mar 2011; Ultrabug rsyslog-5.6.5.ebuild:
add back virtual/logger provider waiting for migration (#358881)

 1.3  app-admin/rsyslog/rsyslog-5.6.5.ebuild

 file :
 diff :

 Index: rsyslog-5.6.5.ebuild
 RCS file: /var/cvsroot/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.5.ebuild,v
 retrieving revision 1.2
 retrieving revision 1.3
 diff -u -r1.2 -r1.3
 --- rsyslog-5.6.5.ebuild  25 Mar 2011 09:27:20 -  1.2
 +++ rsyslog-5.6.5.ebuild  30 Mar 2011 14:12:55 -  1.3
 @@ -1,6 +1,6 @@
  # Copyright 1999-2011 Gentoo Foundation
  # Distributed under the terms of the GNU General Public License v2
 -# $Header: /var/cvsroot/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.5.ebuild,v 
 1.2 2011/03/25 09:27:20 ultrabug Exp $
 +# $Header: /var/cvsroot/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.5.ebuild,v 
 1.3 2011/03/30 14:12:55 scarabeus Exp $
 @@ -11,13 +11,12 @@
  KEYWORDS=~amd64 ~arm ~hppa ~sparc ~x86
 -IUSE=dbi debug doc extras gnutls kerberos logrotate mysql oracle postgres 
 relp snmp static-libs zlib
 +IUSE=dbi debug doc extras gnutls kerberos mysql oracle postgres relp snmp 
 static-libs zlib
  DEPEND=dbi? ( dev-db/libdbi )
   extras? ( net-libs/libnet )
   gnutls? ( net-libs/gnutls )
   kerberos? ( virtual/krb5 )
 - logrotate? ( app-admin/logrotate )
   mysql? ( virtual/mysql )
   postgres? ( dev-db/postgresql-base )
   oracle? ( dev-db/oracle-instantclient-basic )
 @@ -98,10 +97,8 @@
   doins plugins/ompgsql/createDB.sql || die
 - if use logrotate; then
 - insinto /etc/logrotate.d/
 - newins ${FILESDIR}/${BRANCH}/rsyslog.logrotate rsyslog || die
 - fi
 + insinto /etc/logrotate.d/
 + newins ${FILESDIR}/${BRANCH}/rsyslog.logrotate rsyslog || die
  pkg_postinst() {

 1.2  app-admin/rsyslog/rsyslog-5.6.4.ebuild

 file :
 diff :

 Index: rsyslog-5.6.4.ebuild
 RCS file: /var/cvsroot/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.4.ebuild,v
 retrieving revision 1.1
 retrieving revision 1.2
 diff -u -r1.1 -r1.2
 --- rsyslog-5.6.4.ebuild  4 Mar 2011 09:01:47 -   1.1
 +++ rsyslog-5.6.4.ebuild  30 Mar 2011 14:12:55 -  1.2
 @@ -1,6 +1,6 @@
  # Copyright 1999-2011 Gentoo Foundation
  # Distributed under the terms of the GNU General Public License v2
 -# $Header: /var/cvsroot/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.4.ebuild,v 
 1.1 2011/03/04 09:01:47 ultrabug Exp $
 +# $Header: /var/cvsroot/gentoo-x86/app-admin/rsyslog/rsyslog-5.6.4.ebuild,v 
 1.2 2011/03/30 14:12:55 scarabeus Exp $
 @@ -11,13