Re: [gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal

[Paul Varner]

On 9/20/17 2:22 PM, Paul Varner wrote:

On 9/20/17 2:49 AM, Martin Gysel wrote:

Am Dienstag, 19. September 2017, 19:10:23 CEST schrieb Paul Varner:

emerge --deselect app-portage/gentoolkit-dev
emerge --depclean app-portage/gentoolkit-dev


why deselect it first? From man emerge, --depclean:
"When given one or more atoms, it will unmerge matched packages that 
have no

reverse dependencies."

Mainly as an extra precaution. However, just --depclean should work. 
This is the update with the typo pointed out by ulm corrected and 
changing the command to just be depclean.


Regards,
Paul
I just realized that the devmanual says to copy PR on the news items, so 
they are copied on this message. This should be what gets committed 
after three days as there have been no more comments on the item.


Regards,
Paul
Title: app-portage/gentoolkit-dev deprecation and removal
Author: Paul Varner <fuzzy...@gentoo.org>
Posted: 2017-09-19
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-portage/gentoolkit-dev

The app-portage/gentoolkit-dev package has been deprecated and the ebump,
ekeyword and imlate have been moved to the app-portage/gentoolkit-0.4.0
package. With the upcoming marking of >=app-portage/gentoolkit-0.4.0 stable,
users will need to take action since gentoolkit-dev and those versions of
gentoolkit block each other.

In order to upgrade to the new version of gentoolkit, you will need to resolve
the blocks. The following command will remove gentoolkit-dev from your world
set and uninstall gentoolkit-dev. This will then allow the installation of 
>=app-portage/gentoolkit-0.4.0.

emerge --depclean app-portage/gentoolkit-dev

Once >=app-portage/gentoolkit-0.4.0 is stabilized, the remaining gentoolkit-dev
releases will be masked for removal and subsequent tree-cleaning.

Re: [gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal

[Paul Varner]

On 9/20/17 2:49 AM, Martin Gysel wrote:

Am Dienstag, 19. September 2017, 19:10:23 CEST schrieb Paul Varner:

emerge --deselect app-portage/gentoolkit-dev
emerge --depclean app-portage/gentoolkit-dev


why deselect it first? From man emerge, --depclean:
"When given one or more atoms, it will unmerge matched packages that have no
reverse dependencies."

Mainly as an extra precaution. However, just --depclean should work. 
This is the update with the typo pointed out by ulm corrected and 
changing the command to just be depclean.


Regards,
Paul
Title: app-portage/gentoolkit-dev deprecation and removal
Author: Paul Varner <fuzzy...@gentoo.org>
Posted: 2017-09-19
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-portage/gentoolkit-dev

The app-portage/gentoolkit-dev package has been deprecated and the ebump,
ekeyword and imlate have been moved to the app-portage/gentoolkit-0.4.0
package. With the upcoming marking of >=app-portage/gentoolkit-0.4.0 stable,
users will need to take action since gentoolkit-dev and those versions of
gentoolkit block each other.

In order to upgrade to the new version of gentoolkit, you will need to resolve
the blocks. The following command will remove gentoolkit-dev from your world
set and uninstall gentoolkit-dev. This will then allow the installation of 
>=app-portage/gentoolkit-0.4.0.

emerge --depclean app-portage/gentoolkit-dev

Once >=app-portage/gentoolkit-0.4.0 is stabilized, the remaining gentoolkit-dev
releases will be masked for removal and subsequent tree-cleaning.

Re: [gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal

[Paul Varner]

On 9/18/17 3:09 PM, Paul Varner wrote:
Please provide any feedback on the upcoming deprecation and removal of 
app-portage/gentoolkit-dev with the upcoming stabilization of 
app-portage/gentoolkit-0.4.0 (Bug 627350)


Regards,
Paul
Updated to just tell the user to remove gentoolkit-dev from the world 
set and depclean the package.


Regards,
Paul

Title: app-portage/gentoolkit-dev deprecation and removal
Author: Paul Varner <fuzzy...@gentoo.org>
Posted: 2017-09-19
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-portage/gentoolkit-dev

The app-portage/gentoolkit-dev package has been deprecated and the ebump,
ekeyword and imlate have been moved to the app-portage/gentoolkit-0.4.0
package. With the upcoming marking of >=app-portage/gentoolkit-0.4.0 stable,
users will need to take action since gentoolkit-dev and those versions of
gentoolkit block each other.

In order to upgrade to the new version of gentoolkit, you will need to resolve
the blocks. The following commands will remove gentoolkit-dev from your world
set and uninstall gentoolkit-dev. This will then allow the installation of 
>=app-portage/gentoolkit-0.4.0

emerge --deselect app-portage/gentoolkit-dev
emerge --depclean app-portage/gentoolkit-dev

Once >=app-portage/gentoolkit-0.4.0 is stabilized, the remaining gentoolkit-dev
releases will be masked for removal and subsequent tree-cleaning.

[gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal

[Paul Varner]

Please provide any feedback on the upcoming deprecation and removal of 
app-portage/gentoolkit-dev with the upcoming stabilization of 
app-portage/gentoolkit-0.4.0 (Bug 627350)


Regards,
Paul
Title: app-portage/gentoolkit-dev deprecation/removal
Author: Paul Varner <fuzzy...@gentoo.org>
Posted: 2017-09-19
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-portage/gentoolkit-dev

The app-portage/gentoolkit-dev package has been deprecated and the ebump,
ekeyword and imlate have been moved to the app-portage/gentoolkit-0.4.0
package. With the upcoming marking of >=app-portage/gentoolkit-0.4.0 stable,
users will need to take action since gentoolkit-dev and those versions of
gentoolkit block each other.

In order to upgrade to the new version of gentoolkit, you will need to resolve
the blocks. In many cases, removing app-portage/gentoolkit-dev from the world
set will allow Portage to automatically resolve the blockers and remove 
gentoolkit-dev. You can remove it from world using the following command.

emerge --deselect app-portage/gentoolkit-dev

If that fails to work, then unmerge the gentoolkit-dev package with

emerge --unmerge app-portage/gentoolkit-dev

Once >=app-portage/gentoolkit-0.4.0 is stabilized, the remaining gentoolkit-dev
releases will be masked for removal and subsequent tree-cleaning.

Re: [gentoo-portage-dev] OT: Screen bragging. Was: [PROPOSAL] Don't split user visible messages across multiple lines

[Paul Varner]

On 03/17/2017 03:51 AM, Brian Dolbec wrote:

On Fri, 17 Mar 2017 06:58:23 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:


Brian Dolbec posted on Thu, 16 Mar 2017 01:08:30 -0700 as excerpted:


We could also increase the max. line length to something like
120 or 130.

I think more people should chime in on that. I use vertical splits
for the screen when coding, and 120 characters is too long for me,
but if the preferred width ends up changing to 120 or 130 I can
work with it.

   

You need to get some large 4K monitors... love them :D I treated
myself to two 28 inch ones during boxing week sales.
My aging eyes love them :)  They are so much better than my old 24
inch 1080p monitors.  Those were getting tired/starting to loos
clarity along with my eyes working at them all week long.  I now
work with larger fonts which are still physically smaller than my
old monitors, but so much clearer.  My eyes don't get nearly so
tired as they did with my other monitors.

 ;)

Posting resistance failing...

Try a 65-inch 4K with a 48-inch 1080p (now the older monitor, often
running youtube full-screen) off to the side. =:^)

(They're actually TVs used as monitors via the HDMI input, no actual
TV hooked up.  Above about 32-inch, TVs tend to be cheaper than
stand-alone monitors and of course they're the same 4K high or
full-hd lower resolution these days.)

Six 1280x1080 working windows three wide by two stacked on the 65"
4k, still set for 96 dpi standard, FreeMono Bold 9.0 in my konsole
windows, yields:

$ echo $COLUMNS x $LINES
179 x 78

And that's six of those on the 65" 4K, PLUS the full-screen 1080p
youtube or whatever window on the 48". =:^)

This is the first time I can honestly say I have enough screen space
that most of the time I'm not actively using it all. =:^)


Yeah, I've seen lots of those types of setups.

Just a few years ago when I was an A/C mechanic for my day job, I
serviced A/C systems at numerous business's trading floors, where many
stations ran 2 or 3 pc's mostly to house/power the video cards to
drive 4,6, sometimes 8 monitors in a dual high setups, then numerous big
screens overhead in various places around the floor...

I don't think I could handle the large ones like you have, my eyes
haven't got the focal range for that anymore.  As it is, I recently had
to pull my monitors closer about 8 inches because my eyes were getting
too tired by the end of the week.  They were just too close to the
limits of my eyes and glasses.

I do need to get a decent video card to drive these new 4K's, then
maybe I'll think about re-connecting the old 24 inch 1080p's back up
to the old card too  ;)  But if I really needed more screen space, I'd
pick up 2 more of these 4k's, 2 video cards and spin them vertical ;)
  That could make for a great driving/flight simulator :D


Since we are off topic and I have crappy eyes that have required a 
couple of surgeries. My current setup that works well is two 40" 4K TV's 
set to 1080p. Doesn't give me the real estate that 4k would, but my 
eyeballs love the big crisp fonts and it is more space than I had before.

Re: [gentoo-dev] why is the security team running around p.masking packages

[Paul Varner]

On 07/06/2016 10:11 AM, Rich Freeman wrote:
> On Wed, Jul 6, 2016 at 10:02 AM, Kristian Fiskerstrand  
> wrote:
>> On 07/06/2016 03:49 PM, Rich Freeman wrote:
>>
>>> I understand that.  However, I just sometimes wonder whether that
>>> approach makes sense.  The result of the current system is that we
>>> don't release GLSAs until well after a bug is fixed, sometimes after
>>> months.
>> It makes sense for long term server management where you don't want to
>> update the full tree too often, but I agree GLSAs needs to be put out
>> more timely
>>
> Another way to do it is to have a system like this:
> 1.  Vulnerability is logged into database.
> 2.  After embargo period (if any), entry is published.  Tools
> available to the user make them aware they have a vulnerable package
> installed and the realtime status of whether a fix is available.
> 3.  Once a package is stable, the tools let the user auto-update the package.
> 4.  Once all archs are cleaned up, publish the GLSA by email as usual.
>
> So, this is like the current state, except tools like glsa-check use a
> realtime-updated database (or at least one as up-to-date as the latest
> sync) and not a database that is only updated after the last arch is
> stable.  We don't need to send users 14 emails as archs are
> stabilized.  But, the tools they likely would want to use do use the
> latest info.
>
> Sure, in the early days it would just tell them they're vulnerable
> with no suggested fix, since we don't have a fix yet.  But, that is
> still information the user can use to their advantage.
>
> Ideally the early phases of this would be tied into bugzilla so that
> somebody isn't manually updating GLSA xml files every time something
> changes.
>
(Speaking with my tools-portage lead hat on)

While I don't like touching glsa-check within gentoolkit, due to the
nature of what it does. I will fully support and work with the security
team on updating the tool if something like this is desired.

Regards

Paul

Re: [gentoo-dev] Uncoordinated changes

[Paul Varner]

On 02/11/2016 07:34 PM, Rich Freeman wrote:
> Ultimately, the only way anybody can be assured that their favorite
> Gentoo tool will work in a year is if they're maintaining it.  It
> sounds like nobody was really paying attention to it, which is why
> nobody noticed that it was going to break.

Not completely true in this case.  Gentoolkit is maintained, just slowly
due to lack of time.  For this migration, there is a bug for it (Bug
573030) that was filed by me before the migration was complete.  The
problem here is that there are two devs that primarily work on the
package and both of us currently are busy with other things in our
work/life balance.

With that said, Patrick has attached a patch to the bug and I will take
a look at it and if it works, put it in and generate a release.

As a side note, any Gentoo developer is authorized to work on
Gentoolkit, the restrictions are don't make a new release without
asking, and fix any accidental breakage. With regards to releases, it is
fine to release a rev-bumped ebuild with patches as long as the patch is
in the git repository and you follow the second rule of fixing
accidental breakage.

Regards,
Paul

[gentoo-dev] The Beauty of Unix

[Paul Varner]

On 2/9/16 7:44 AM, Rich Freeman wrote:

I thought the whole beauty of unix was the everything-is-a-file design?
No, the beauty of Unix has always been the architectural philosophy of 
loose-coupling of the components of the system.
The "everything is a file" is a result of that philosophy.  The end 
result of this is that you can switch out components of the system 
without redesigning other aspects of the system.  That is the philosophy 
that allows Gentoo to exist as meta-distribution and to provide choice 
for what you want.


On the other side you have Windows which tightly-couples everything in 
the system.  This does have the advantage of making everything have the 
same look and feel and "just work".  And I fully understand why 
Microsoft went that route, it made things easy for people who don't care 
and is what made them the huge company that they are today.


Sidebar, the reason you have to reboot a Windows box so much during 
updates is because of the tight-coupling.  With Unix, you typically only 
need to reboot if you update the kernel.


However, tight-coupling has big issues for people who do care or don't 
like the design that is being given to them.  I switched from Windows to 
Linux and OS X solely because I got very tired of fighting the design 
forced on to me and the fact that a bug in one piece of software would 
often kill the entire system.


And that is the reason that I don't care for systemd.  They are 
tightly-coupling everything together under their design approach. It is 
intended to be a one size fits all. While it will have the benefit of 
"just working", and does fit in with where Red Hat, etc, want to go with 
Linux. It will have the same disadvantages that Windows has.


Regards,
Paul

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Paul Varner]

On 01/21/2016 06:52 AM, Lars Wendler wrote:
> Hi Dirkjan,
>
> make it part of the news item please.
>
> Kind regards
> Lars
>
> On Wed, 20 Jan 2016 13:16:19 +0100 Dirkjan Ochtman wrote:
>
>> On Wed, Jan 13, 2016 at 6:13 PM, Dirkjan Ochtman 
>> wrote:
>>> After what feels like ages, we're just about ready to stabilize
>>> apache-2.4. Since this is a major upgrade that in many cases require
>>> configuration changes, we wanted to do a news item. After some
>>> discussion with Lars (Poly-C), here's an initial attempt at a
>>> draft.  
>> I'm currently attempting this upgrade on a stable system I run. It
>> mostly just works, although I run into trouble when trying to load
>> modules that are not part of www-server/apache (e.g. mod_wsgi). I
>> resolved this by reemerging all packages listed in `equery b
>> /usr/lib/apache2/modules/*`, but maybe there's a different way? Should
>> this be in an elog message, or part of the news item?
>>
The simple command to do this is: emerge -av1 /usr/lib/apache2/modules
--exclude=www-servers/apache

Regards,
Paul

Re: [gentoo-portage-dev] gentoolkit.git repository reorganized

[Paul Varner]

On 10/21/2015 11:48 PM, Mike Frysinger wrote:
> On 22 Oct 2015 00:45, Mike Frysinger wrote:
>> On 21 Oct 2015 16:35, Paul Varner wrote:
>>> On 10/20/2015 03:34 AM, Alexander Berntsen wrote:
>>>> On 15/10/15 19:42, Paul Varner wrote:
>>>>> Over the last couple of days, I have done the following:
>>>>> 1. Migrated the gentoolkit-dev branch to its own gentoolkit-dev.git
>>>>> repository
>>>>> 2. Moved the gentoolkit branch to master on the
>>>>> gentoolkit.git repository
>>>> Why did you not just make gentoolkit master, and leave gentoolkit-dev as
>>>> a branch? That's certainly the common way of using git.
>>>>
>>> Mainly, because at this point gentoolkit and gentoolkit-dev are now
>>> almost completely separate code bases as well as being separate packages.
>>>
>>> They share a common ancestry and that can be seen looking through the
>>> commit log, but starting with gentoolkit-0.2.5, gentoolkit started
>>> migrating to python as the only scripting language and utilizing the
>>> Portage API with setuptools as the build system. The two remaining bash
>>> scripts are being rewritten in python and when that is complete, they
>>> will be completely separate code bases.
>>>
>>> gentoolkit-dev has stayed as a collection of stand-alone scripts written
>>> in multiple languages intended mainly for Gentoo developers.
>>>
>>> Since they really do not share any code anymore, it did not make sense
>>> to me keeping gentoolkit-dev as a branch and it should be in its own
>>> repository.
>> echangelog is the only non-shell/python script, and arguably not useful
>> anymore.  repoman itself has a changelog option, and since the move to
>> git, we don't commit ChangeLog entries anymore.  i would just punt it.
>>
>> there's also eviewcvs written in perl, but that's also dead now that
>> we use git, so it should be punted.
>>
>> that really only leaves three:
>>  - ebump - bash
>>  - ekeyword - python
>>  - imlate - python
>>
>> why not merge them into a single repo ?  you can have a dev/ subdir
>> for scripts that are more developer oriented and put them behind a
>> USE=dev flag.
> another reason i think there should be one: gentoolkit-dev rarely sees
> releases, nor is it clear who is supposed to be making them, nor does
> it seem like a good use of time to have independent builds/packages.
> since gentoolkit is getting rolled, updates could finally go out.
>
> case in point: ekeyword was rewritten almost 2 years ago and it still
> hasn't seen a release.
> -mike

Thanks for the feedback, this is one reason why I've kept the branch and
have not deleted it yet.  As far as releases for gentoolkit-dev, idl0r
was managing it, but as you have observed that has not been happening. 

Mike, I know you're busy with other stuff, but if you ever want to see a
new gentoolkit/gentoolkit-dev release, consider this your authorization
to just do it.  The README.dev files state how to make releases.

Since, the tools have dwindled down in gentoolkit-dev, I do think it
does make sense to keep it in the same repo and merge the packages
together behind a USE flag.  I will revert the commit, that emptied the
genttolkit-dev branch and ask mgorny to nuke the new gentoolkit-dev
repository.

As I get time, I will work towards moving the gentoolkit-dev tools into
gentoolkit and putting them behind a USE flag in the ebuild.

Regards,
Paul

[gentoo-portage-dev] gentoolkit.git repository reorganized

[Paul Varner]

All:

Due to historical reasons the gentoolkit git repository was organized
with two branches, gentoolkit and gentoolkit-dev with master effectively
being an empty branch.  This was confusing to contributers and with git
did not make a lot of sense.  Over the last couple of days, I have done
the following:

1. Migrated the gentoolkit-dev branch to its own gentoolkit-dev.git
repository
2. Moved the gentoolkit branch to master on the gentoolkit.git repository

The one thing left to do is to remove the gentoolkit-dev branch from the
gentoolkit repository, I'm going to wait for several days to make sure
that there is nothing missing in the gentoolkit-dev repo before removing it.

Due to the nature of the changes to the repos, I've found that it is
easiest to backup the current clone and re-clone the repository to make
sure that everything is up to date with the changes.

Regards,
Paul

[gentoo-portage-dev] Tools-Portage Lead

[Paul Varner]

All:

I inherited the tools-portage lead position on 12/1/2008 when genone
retired from Gentoo, and have been the lead since that time.

Reading GLEP-39, it is not clear to me if a sub-project needs to have
their leads elected or not.  Anyhow, I'm asking the following:

1. Do we want to elect a tools-portage lead?
2. Do we want the portage lead to select/confirm the tools-portage lead
when they are elected?
3. Do we just want continue as we have been until I get tired of the
position and step down?
4. Any option not already listed.

Since the tools-portage team is quite small, there hasn't been any real
issues with the leadership or running the team, our problems are lack of
manpower and time.  I'm only asking this since the Council would like
all projects to consider electing or confirming the project lead(s)

If we do decide to hold an election, I will like to nominate myself and
Brian as co-leads.

Regards,
Paul

Re: [gentoo-portage-dev] [RFC] Package description index file format for faster emerge search actions

[Paul Varner]

On 10/14/14 02:40, Zac Medico wrote:
 Hi,

 As we all know, emerge --search/--searchdesc actions are embarrassingly
 slow (from most users' perspectives, anyway), especially in comparison
 to external tools like eix and esearch.

 Wouldn't it be nice if the performance of emerge's search functionality
 was more competitive with other offerings? Then, external search tools
 might not be seen as an absolute necessity.

 In order to solve this problem, I suggest that we add support for a
 package description index file format. For example, the attached script
 will generate a suitable index formatted as series of lines like this:

 sys-apps/sandbox-1.6-r2,2.3-r1,2.4,2.5,2.6-r1: sandbox'd LD_PRELOAD hack

 Using this format, the index file for the entire gentoo-x86 repository
 consumes approximately 1.5 MB. The whole file can be quickly searched as
 a stream (the whole file need not be in memory at once), yielding emerge
 --search/--searchdesc performance that will be competitive with
 app-portage/esearch.

 The index can either be generated on the server side by egencache, or on
 the client side by a post emerge --sync hook. It makes sense to support
 both modes of operation, so that server side generation is purely optional.

 What do others think about this proposal?

Please do this.  Once this is in place, I will probably deprecate
esearch and point users to emerge for basic searching and eix for
advanced searching.

Regards,
Paul

Re: [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask

[Paul Varner]

On 11/21/13 03:21, Alexander Berntsen wrote:
 After talking to zmedico privately, and raising the issue and
 discussing it with people in bug #481578[0], I implemented the
 behaviour described in a comment[1] on said bug.

 I sent this to zmedico almost two months ago, but it doesn't look like
 he's coming back any time soon, so I'm sending it here and ask someone
 to review and commit it (a role zmedico has typically played for me,
 as well as being my mentor and guide and so on and so forth for
 Portage hacking).

 [0]  https://bugs.gentoo.org/show_bug.cgi?id=481578
 [1]  https://bugs.gentoo.org/show_bug.cgi?id=481578#c10

I turn off autounmask because I don't find it useful.  I have found too
many times when it wants me to unmask something that really doesn't need
to be unmasked.

It is not clear to me from the patches if I can still do that.

Regards,
Paul

Re: [gentoo-dev] Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c

[Paul Varner]

On 01/17/13 13:21, Pacho Ramos wrote:
 # Pacho Ramos pa...@gentoo.org
 # Multiple bugs (#449458). No maintained at all and upstream
 # dead. Removal in a month.
 app-portage/epm

Peter Weilbacher has stepped up to maintain this package and I am acting
as his proxy.  app-portage/epm-1.40 has been added to the tree that
fixes most of the bugs.  I have removed the package mask entry and
updated metadata and bugzilla appropriately.

Regards,
Paul Varner
tools-portage lead

[gentoo-dev] revdep-rebuild bikeshedding

[Paul Varner]

All:

Time for some bikeshedding :)

For the gentoolkit-0.3.0 series, I removed any filtering of emerge
options set in EMERGE_DEFAULT_OPS for revdep-rebuild.  This has caused
some people to complain because some of the flags in their
EMERGE_DEFAULT_OPTS are not suitable for a revdep-rebuild run.

I am not going to go back to filtering any of the emerge options,
however, I just added support for a make.conf variable called
REVDEP_DEFAULT_OPTS which currently gets appended to the list of options
after the EMERGE_DEFAULT_OPTS and before the command line options.

Here is where the bikeshedding begins:
1. What variable name do we prefer? REVDEP_DEFAULT_OPTS or
REVDEP_EMERGE_DEFAULT_OPTS
2. What behavior do we want? append to EMERGE_DEFAULT_OPTS or replace
EMERGE_DEFAULT_OPTS

Regards,
Paul

Re: [gentoo-dev] tools-portage herd unmaintained packages

[Paul Varner]

On 12/25/12 08:09, Pacho Ramos wrote:
 El mar, 06-11-2012 a las 12:35 -0600, Paul Varner escribió:
 All:

 The following packages in the tools-portage herd are effectively
 unmaintained packages and need a maintainer to step up and maintain them.

 app-portage/deltup
 app-portage/epm
 app-portage/maintainer-helper
 app-portage/splat
 app-portage/ufed

 If no one steps up in the next 30 days, I will be moving them out of the
 herd and to maintainer-needed and they will be candidates for the
 treecleaners.

 Regards,
 Paul Varner
 tools-portage lead


 What did occur finally with them?
Nothing has occurred with them yet, but since nobody has stepped up for
any of them, they will be moved to maintainer-needed. This will probably
be within the next couple of days since work has calmed down due to the
holidays.

Regards,
Paul

Re: [gentoo-dev] tools-portage herd unmaintained packages

[Paul Varner]

On 12/25/12 12:03, Sven Eden wrote:
 Hi all,

 what has happened to app-portage/ufed? I could take care of it. I am
 no official dev, but maybe via a proxy maintainership? Would that be
 possible?

Yes, I'm willing to proxy maintain app-portage/ufed.  The sources are
available from overlays.gentoo.org. See
http://git.overlays.gentoo.org/gitweb/?p=proj/ufed.git;a=summary. 
Initially, you would need to send me patches or point me to your copy of
the project to pull from.  However, once I'm comfortable with your work,
I can grant direct access to the project for pushing commits.

If you do want to proxy maintain it, please send me in private email,
the email address that you use in Gentoo's bugzilla, so I can update the
metadata.xml file appropriately.

Regards,
Paul

Re: [gentoo-dev] tools-portage herd unmaintained packages

[Paul Varner]

On 12/26/12 11:00, Paul Varner wrote:
 On 12/25/12 08:09, Pacho Ramos wrote:
 El mar, 06-11-2012 a las 12:35 -0600, Paul Varner escribió:
 All:

 The following packages in the tools-portage herd are effectively
 unmaintained packages and need a maintainer to step up and maintain them.

 app-portage/deltup
 app-portage/epm
 app-portage/maintainer-helper
 app-portage/splat
 app-portage/ufed

 If no one steps up in the next 30 days, I will be moving them out of the
 herd and to maintainer-needed and they will be candidates for the
 treecleaners.

 Regards,
 Paul Varner
 tools-portage lead


 What did occur finally with them?
 Nothing has occurred with them yet, but since nobody has stepped up for
 any of them, they will be moved to maintainer-needed. This will probably
 be within the next couple of days since work has calmed down due to the
 holidays.
I have moved everything except app-portage/ufed to maintainer-needed in
metadata.xml.  I still need to go through and reassign any bugs for
these packages.

I'm going to hold off on app-portage/ufed since there is interest in it
being proxy maintained.

Regards,
Paul

[gentoo-dev] tools-portage herd unmaintained packages

[Paul Varner]

All:

The following packages in the tools-portage herd are effectively
unmaintained packages and need a maintainer to step up and maintain them.

app-portage/deltup
app-portage/epm
app-portage/maintainer-helper
app-portage/splat
app-portage/ufed

If no one steps up in the next 30 days, I will be moving them out of the
herd and to maintainer-needed and they will be candidates for the
treecleaners.

Regards,
Paul Varner
tools-portage lead

Re: [gentoo-portage-dev] tools-portage packages

[Paul Varner]

Based upon all of the responses, this is the list of completely
unmaintained packages managed by  tools-portage.  If no one objects, I
will send this list to gentoo-dev in a few days asking for maintainers
or they will be last rited.

app-portage/deltup
app-portage/epm
app-portage/maintainer-helper
app-portage/splat
app-portage/ufed

Regards,
Paul

[gentoo-portage-dev] tools-portage packages

[Paul Varner]

All:

Sending this here before I send to the gentoo-dev list.  Below is the
list of packages that are managed by the tools-portage herd and their
maintainer (if any).  I know we have several packages in the herd that
are not being maintained and I would like to either get a maintainer or
last rite the package.  I've included comments on what I know about the
packages.

$ equery meta -m $(fgrep tools-portage /usr/portage/*/*/metadata.xml |
awk -F'/' '{printf(%s/%s\n, $4, $5)}')

* app-portage/deltup [gentoo]
None specified

-- I don't know anything about this package.

* app-portage/eclass-manpages [gentoo]
vap...@gentoo.org

-- Actively maintained by Mike.

* app-portage/elogv [gentoo]
fuzzy...@gentoo.org (Paul Varner)
sp...@gentoo.org (Sebastian Pipping)

-- Being maintained more by Sebastian than myself.

* app-portage/elogviewer [gentoo]
fuzzy...@gentoo.org (Paul Varner)

-- Effectively unmaintained, I can't find the upstream repository and I
haven't done anything with it recently.

* app-portage/epm [gentoo]
None specified

-- Old perl script that mimics rpm.  I've done some ebuild cleanup, but
otherwise unmaintained.

* app-portage/esearch [gentoo]
None specified

-- Actively maintained by myself and Brian.  Upstream repository is on
Github

* app-portage/etc-proposals [gentoo]
dol...@gentoo.org (Brian Dolbec)

-- Actively maintained by Brian

* app-portage/euses [gentoo]
j...@gentoo.org (Jeroen Roovers)

-- Actively maintained by Jeroen

* app-portage/genlop [gentoo]
None specified

-- Not actively being maintained although fixes have been made in the
upstream gentoo-perl repository on Github. it might be appropriate to
transfer this to the gentoo-perl herd.

* app-portage/gentoolkit-dev [gentoo]
None specified

-- Actively maintained by Christian.

* app-portage/gentoolkit [gentoo]
None specified

-- Actively maintained by Paul and Brian

* app-portage/gpytage [gentoo]
dol...@gentoo.org (Brian Dolbec)

-- Brian took over maintenance. Not sure of active status

* app-portage/layman [gentoo]
dol...@gentoo.org (Brian Dolbec)

-- Brian is actively maintaining

* app-portage/maintainer-helper [local]
None specified

-- Not actively maintained, it really needs a maintainer or be dropped
from the tree.

* app-portage/mirrorselect [gentoo]
None specified

-- Actively maintained by various people.

* app-portage/porthole [gentoo]
dol...@gentoo.org (Brian Dolbec)
Upstream Maintainer (please CC on bugs)

-- Actively maintained by Brian

* app-portage/splat [gentoo]
None specified

-- I don't know anything about this package.  Upstream URL is dead.

* app-portage/udept [local]
fuzzy...@gentoo.org

-- Effectively last rited, due to dead upstream.  Still in tree in hard
masked status due to no replacement.  However, in the time that it has
been hard masked, there has not been anyone to step up and either fork
or create a replacement.

* app-portage/ufed [gentoo]
None specified

-- Not being maintained since Harald retired and needs a maintainer. 
Repository is on overlays.g.o

* dev-util/bdelta [gentoo]
sly...@gentoo.org (Sergei Trofimovich)
Primary Maintainer

-- I don't know anything about this package.  Based on the ChangeLog,
Sergei is actively maintaining it.

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

[Paul Varner]

On 3/19/12 2:26 PM, Pacho Ramos wrote:

El lun, 19-03-2012 a las 10:56 -0500, Paul Varner escribió:

On 03/18/12 13:50, Pacho Ramos wrote:

Due his retirement the following packages need a new maintainer:

app-portage/maintainer-helper


Thanks for taking them


I've added app-portage/maintainer-helper to the tools-portage herd,
however, I've left it as maintainer-needed.  So if anyone wants to take
it, feel free.  The tools-portage herd will fix bugs for it as we find
the time.


I disagree with leaving maintainer-needed as default assign, if you will
fix bugs when you have time it's better than what I will do with
maintainer-needed packages.


Okay, I've taken out the maintainer-needed as the maintainer and have 
just left it assigned to the herd.  However, in reading through 
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=4, I 
don't see a good mechanism to convey that the package is up for grabs, 
but in the meantime go ahead and assign any bugs to the herd.


Regards,
Paul

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

[Paul Varner]

On 03/18/12 13:50, Pacho Ramos wrote:
 Due his retirement the following packages need a new maintainer:

 app-portage/maintainer-helper


 Thanks for taking them

I've added app-portage/maintainer-helper to the tools-portage herd,
however, I've left it as maintainer-needed.  So if anyone wants to take
it, feel free.  The tools-portage herd will fix bugs for it as we find
the time.

Regards,
Paul

Re: [gentoo-dev] preserve_old_lib and I'm even more lazy

[Paul Varner]

On Wed, 2012-02-29 at 09:45 +0100, Paweł Hajdan, Jr. wrote:
 On 2/27/12 10:37 PM, Brian Dolbec wrote:
  I think somebody pointed some revdep-rebuild versions where exiting
  with successful code even when failed, was fixed version stabilized?
  
  No, it is only in - so far.  It has not been released in a -0.3*
  ebuild yet.
  
  The last patch to revdep-rebuild fixing return codes is:
  
  http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=commit;h=3e51df74595c535656ef9f38bf7a577a4f64d0f5
   
  from 11 days ago.
 
 If the maintainers of the package in question do not consider it
 important enough to do a release (not even mentioning stabilization), I
 don't think this is blocking.
 
 Any further objections? (I'm going to listen)
 

Yes, you are going to break systems if you do this change.  If you
really want to do this before we have a fixed gentoolkit to support it,
then put yourself in the tools-portage herd and handle all of the bugs
that arise out of the change.

I just did a new release of gentoolkit-0.3.0.5 with the fixes in them so
that you could do this change once it gets stable.

Regards,
Paul

Re: [gentoo-dev] Packages looking for proxy as ian no longer has commit access

[Paul Varner]

On Thu, 2011-11-24 at 17:25 +0100, Ulrich Mueller wrote:
  On Thu, 24 Nov 2011, Pacho Ramos wrote:
 
  Due https://bugs.gentoo.org/show_bug.cgi?id=99016 ian doesn't
  have commit access and, then, his packages need a proxy maintainer:
  app-portage/autounmask
  app-portage/demerge
 
 I would volunteer to proxy maintain these packages, if Christian still
 wants to be maintainer for them (his last commit was in 2009). If not,
 proxy maintainership doesn't make much sense.
 

Ulrich,

If we decide to proxy maintain these two packages, go ahead and add
tool-portage as the herd to back you up.

Regards,
Paul

Re: [gentoo-dev] Re: rfc: news item for png15

[Paul Varner]

On Fri, 2011-10-14 at 23:03 +0200, Pacho Ramos wrote:

 It shouldn't, I am sure I have used this some times before and it worked
 as expected, but I don't know when revdep-rebuild cache files are
 removed (and then, broken packages recalculated) :-/ 
 
 Any revdep-rebuild maintainer here to clarify this please? Thanks :)
 
Actually all of the current versions of revdep-rebuild are broken and
always remove the cache files after completion. The exception to this is
when --pretend is used.

When it is fixed in the next version of gentoolkit, the behavior is to
keep the files if it is a pretend run or if emerge exits with a non-zero
status.

Note: emerge will exit with a non-zero status if --keep-going is used
and there is a build failure.

Regards,
Paul

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

[Paul Varner]

On Wed, 2011-07-20 at 18:34 +0200, Pacho Ramos wrote:
 Due truedfx retirement the following packages need a new maintainer:
 
 app-editors/le
 app-editors/nvi
 app-editors/ted
 app-misc/glastree
 app-portage/cfg-update
 dev-libs/librep
 dev-libs/tvision
 dev-util/dialog
 x11-apps/xkbset

Additionally, the tools-portage team would be very appreciative if
someone would be willing to do active maintenance on app-portage/ufed.
The repository for it is at: 

http://git.overlays.gentoo.org/gitweb/?p=proj/ufed.git;a=summary

Regards,
Paul

[gentoo-dev] tools-portage herd status

[Paul Varner]

On Mon, 2009-04-27 at 09:08 -0500, Paul Varner wrote:
 All:
 
 The tool-portage herd is currently understaffed and as such is not
 making updates in a timely fashion.  Currently the herd consists of
 zmedico and myself.  While Zac has done a good job where he can, he has
 a full time job with maintaining and updating portage.  In my case, my
 real life job has me working 60 - 80 hour work weeks which severely
 limits the time I have to work on Gentoo. We are in the process of
 recruiting another member of the herd, however, he has a full time job
 as well which also limits the amount of time he has available for
 Gentoo.
 
 Because of this, I am publicly announcing that any Gentoo developer who
 wants to touch stuff belonging to the tools-portage herd is welcome to
 do so.  The only requirement is if you accidentally break it, please fix
 it as well.

Back in April of last year I wrote the above message.  Since then the
tools-portage team has added idl0r as well as several community
developers.  However, we are now in the process of losing truedfx who
was the main maintainer of ufed.

If a current Gentoo developer wants to join the herd to become the ufed
maintainer, please let us know.

Additionally, since I don't like touching and breaking glsa-check, it
would be appreciated if someone would be willing to act as the primary
maintainer for that piece of gentoolkit as well.

Finally, we have migrated the gentoolkit source code from subversion to
git.  Gentoo developers can access the repository at:

git+ssh://g...@git.overlays.gentoo.org/proj/gentoolkit.git

Gentoo Developers have full priviledges to the repository.  As before,
any Gentoo developer can do work on the gentoolkit source.  We only have
several requirements.  If you want to do a major change (i.e
rewrite/refactor something), please talk to us before pushing any
commits. If you break something, please fix it.  Finally, if you want a
new release of gentoolkit or gentoolkit-dev, please coordinate it with
either myself or idl0r.

Any non Gentoo developers who wish to assist, the best way to get
started is by pulling a copy of the repository and submitting patches to
bugzilla.  Additionally, we can be found in the #gentoo-portage IRC
channel.

On behalf of the tools-portage team.

Paul




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

[gentoo-dev] Last Rites: app-text/manedit

[Paul Varner]

# Paul Varner fuzzy...@gentoo.org (26 Apr 2010)
# Masking for removal (bug #315947).
# It doesn't compile with newer versions of zlib, still uses gtk1+, and 
# upstream is unresponsive.  Unfortunately, there is not a suitable
# replacement.
app-text/manedit

Re: [gentoo-portage-dev] equery displays warnings about masked deps, even when those deps are deeper than --depth specification

[Paul Varner]

On Mon, 2010-01-11 at 15:40 +0200, Amit Dor-Shifer wrote:
 is this a bug?

As the gentoolkit maintainer, I would say that it is a bug.  Which
version of gentoolkit do you have installed?

Regards,
Paul

Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options

[Paul Varner]

On Mon, 2009-10-26 at 20:04 +0200, Arthur D. wrote:
  I am very much against allowing EMERGE_DEFAULT_OPTS in revdep-rebuild
  since I went through hell trying to support it when it was first added
  as a feature to portage and I really don't want to go through that
  again.
 
 Paul, there's good option to filter _only_ safe options from  
 EMERGE_DEFAULT_OPTS and
 pass them to emerge. If you don't like to maintain it alone, I will help  
 you.
 Just forward all tickets connected to EMERGE_DEFAULT_OPTS to me. Deal?

The biggest issue is determining that EMERGE_DEFAULT_OPTS is the
problem.  Anyhow, I'm looking at it to see what can be done.

Regards,
Paul

[gentoo-dev] tools-portage herd status

[Paul Varner]

All:

The tool-portage herd is currently understaffed and as such is not
making updates in a timely fashion.  Currently the herd consists of
zmedico and myself.  While Zac has done a good job where he can, he has
a full time job with maintaining and updating portage.  In my case, my
real life job has me working 60 - 80 hour work weeks which severely
limits the time I have to work on Gentoo. We are in the process of
recruiting another member of the herd, however, he has a full time job
as well which also limits the amount of time he has available for
Gentoo.

Because of this, I am publicly announcing that any Gentoo developer who
wants to touch stuff belonging to the tools-portage herd is welcome to
do so.  The only requirement is if you accidentally break it, please fix
it as well.

The gentoolkit repository is in Subversion and can be checked out by a
developer with the following:

svn co svn+ssh://${us...@svn.gentoo.org/var/svnroot/gentoolkit

If any developer has questions, I can always be reached by email.  I am
on IRC when I can, but that time is limited by work.

Regards,
Paul


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

[gentoo-dev] Last Rites: app-portage/udept

[Paul Varner]

# Paul Varner fuzzy...@gentoo.org (14 Dec 2008)
# Dead upstream, masked for removal in ~30 to 60 days.
app-portage/udept

Additionally, it doesn't play well with EAPI's greater than zero.

The removal bug is Bug #250839.  If upstream comes back alive or someone
forks and actively maintains, I will unmask or re-add to the tree.

Regards,
Paul Varner



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

Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted

[Paul Varner]

On Tue, 2008-08-26 at 13:40 -0700, Robin H. Johnson wrote:
 Q: How much have you utilized the primary use case?
Not at all

 Q: Are there any other use-cases you have and actively use?
No

Re: [gentoo-dev] Packages up for grabs

[Paul Varner]

On Sun, 2008-07-20 at 08:44 +0200, Christian Faulhammer wrote:
 Hi,
 
 packages that are in a herd, but could need someone dedicated to it:
 
   app-portage/elogv, elogviewer, kelogviewer (tools-portage) -- low
 maintenance

I'll take care of these packages.

Regards,
Paul

[gentoo-dev] echangelog maintainer needed

[Paul Varner]

All:

I need a Gentoo developer to apply some loving care to echangelog. There
have been several requests to add git and subversion support to
echangelog and the basics are already in place.  However, it has bugs
and since I don't have the setup to test that support, I have not done a
good job at getting the bugs fixed and resolved.

The code for echangelog is in the gentoolkit repository in subversion
and any developer should have access to the repository.

I can walk you through how to cut a new gentoolkit-dev release, or if
you are not comfortable with that, I can continue to cut the new
releases whenever it needs to be done.

Regards,
Paul Varner
Lead, Gentoo Portage Tools
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] New developer: Bo Ørsted Andresen (zlin)

[Paul Varner]

On Thu, 2008-02-28 at 14:28 +0200, Petteri Räty wrote:
 He has been breaking the tree for a while now but as Calchan has been 
 having availability problems I get to insult him a little bit later than 
 usual. Bo hails from Aalborg, Denmark. He studies to become a control 
 engineer. On the Gentoo side he is one of the people who enabled KDE4 
 coming to our main tree via contributing to their overlays. He has also 
 contributed to Paludis. Let the usual mud slinging begin.

Welcome aboard.  If you have the time and inclination, you are more than
welcome to join me over in tools-portage.

Regards,
Paul
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Projects and subproject status

[Paul Varner]

On Mon, 2008-01-07 at 22:31 +0100, Luca Barbato wrote:
 Here is a list of interesting questions: Are we fine? What are we
 going to do?
 
 Please project leaders try to reply in short.

tools-portage:

Are we fine?  The short answer is no.  We need more developers.
Unfortunately, real life work is consuming all of my time and what free
time is left is going to my family.  mpagano has started to step up and
work bugs, but we definitely need more help. I am on email and IRC so I
can answer questions and work with any developer who would like to step
up and help (even temporarily).

Marius (genone) stepped down as team lead on December 3rd and asked for
help for the team at that time.  I have not seen any reponses to that
request.

What are we going to do?

Due to lack of time and participation, I currently don't have a good
answer for that.

On my short list is to get revdep-rebuild fixed.  The current state
leaves much to be desired and while it works for most people, it is
definitely a visible turn off for people when it fails.

Regards,
Paul
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/gentoolkit: ChangeLog gentoolkit-0.2.4_rc1.ebuild

[Paul Varner]

On Wed, 2007-09-26 at 18:39 -0700, Donnie Berkholz wrote:
 On 00:18 Thu 27 Sep , Paul Varner (fuzzyray) wrote:
  
  pkg_postrm() {
  python_mod_cleanup ${ROOT}usr/lib/gentoolkit
 
 Shouldn't gentoolkit go into get_libdir() instead of lib? Portage 
 appears to...

It probably should, it is going to require changes to the python source
code and Makefile as well though.

Regards,
Paul
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] That time again...

[Paul Varner]

On Wed, 2007-04-25 at 20:12 -0400, Michael Cummings wrote:
 G-cpan-0.15 was put out last night; 99% bug fixes, a few easter eggs, and some
 tweaks. Any other cool updates in the last few weeks? (it's been 20 days since
 the last time I started this thread - at this rate, we might make enough input
 to make Chris' job on the gwn easier).

I'll use this to send out the message that I was going to send
anyways :)

I have just placed gentoolkit-dev-0.2.6.5 in the tree which contains an
echangelog that supports subversion and git (thanks to antarus and
genstef).  It is currently package masked so that it can be fully
tested.

Anyhow, consider this a call for people to test.  If you run into any
bugs please report them on bug #136048.

Secondly, the next pre-release of gentoolkit (gentoolkit-0.2.4_pre6)
will have two new utilities in the path (thanks to solar), genpkgindex
and epkginfo.  genpkgindex creates metadata for binary packages and is
suitable for use with qmerge from portage-utils. epkginfo is a small
program that will display metadata information about packages in
portage.

Regards,
Paul
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Everyone developer should downgrade back to gentoolkit-dev-0.2.6.2

[Paul Varner]

On Sat, 2007-03-24 at 21:56 -0400, Mike Frysinger wrote:
 On Saturday 24 March 2007, Petteri Räty wrote:
  Joshua Baergen kirjoitti:
   It appears to be a problem with gentoolkit-dev-0.2.6.3.  0.2.6.2
   produces proper changelogs.
 
  Until the problem is solved everyone should downgrade back to 0.2.6.2. I
  package.masked 0.2.6.3 in the meanwhile.
 
 isnt this what package mask is for ?  and/or just put out a quick -r1 that 
 reverts echangelog

Both have occurred.  The bad version has been package masked and removed
from the tree. Additionally, the newer version reverts to the same
echangelog from 0.2.6.2

Regards,
Paul
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Introducing Daniel Robbins (drobbins)

[Paul Varner]

On Tue, 2007-02-27 at 19:06 +0200, Petteri Räty wrote:
 It's my please to introduce to you Daniel drobbins Robbins.

Welcome back Daniel, it is good to see you back.

Regards,
Paul
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: New preserve-libs feature

[Paul Varner]

On Sat, 2007-02-17 at 20:56 +, Duncan wrote:
 Question:  With the old library still around, will revdep-rebuild even try
 to rebuild anything linked against it?  Maybe I'm wrong, but I thought it
 would only rebuild when the library was actually missing.  (There's also a
 hint of that in another comment, but maybe I'm reading that wrong as well.)

Not by default.  However, if you specify the --library parameter with
the older library, it will rebuild the stuff linked to that library.

Regards,
Paul
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] RFC: new virtual metadata variable to list combined deps

[Paul Varner]

On Thu, 2006-10-26 at 18:50 +0200, Marius Mauch wrote:
 So now I was wondering a) if I'm the only one who finds this
 feature useful and b) if adding it at the dbapi level (in dbapi.aux_get)
 would be considered a good idea, so it could be used by other tools?

Not sure if it would fit better in portage or gentoolkit.  Anyhow, one
of the big things that I need to do is fix the equery depends command.

I see this code as potentially being useful in that regard.

Regards,
Paul
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users

[Paul Varner]

On Mon, 2006-10-09 at 23:30 -0400, Kari Hazzard wrote:
 The point is that if you build Gentoo to be developer-friendly rather than 
 user-friendly, Gentoo will be replaced by something else.
 
 User-centric design is why Gentoo is/was different from everything else. Take 
 away choices that people want and you take the Gentoo philosophy out of 
 Gentoo itself.

However, all developers are users first.  If you have an itch to scratch
that the current development team isn't meeting, then get involved.
There are lots of ways to do that.

Regards,
Paul
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] glsa-check wrong

[Paul Varner]

On Sun, 2006-07-09 at 19:34 +0200, Radoslaw Stachowiak wrote:
 glsa-check returns  errorlevels 255 which results in shell being
 unable to parse it (anything greater 255 is 0).

I've opened Bug #139804 to track this.

Regards,
Paul

-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] making permission/ownership retention consistent

[Paul Varner]

On Wed, 2006-07-05 at 02:20 -0400, Mike Frysinger wrote:
 personally i think that we should be retaining the permissions of the file as 
 is instead of resetting it, but i wont fight too hard in either direction ... 
 we just need the behavior to be consistent

I agree with retaining permissions of an already existing
directory/file.  Nothing I hate more as a system admin is having to
double check permissions when reinstalling software.

Regards,
Paul
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] portage-2.1 and gentoolkit-0.2.2

[Paul Varner]

On Wed, 2006-05-31 at 18:20 -0400, Ned Ludd wrote:
 Things can be fast tracked if it's better for the overall health of the 
 tree. The 30 thing is just a general guideline and more so before we 
 had any arch teams/ATs/etc... Now that we have arch teams the QA/stable 
 process has been highly improved.
 
 On Wed, 2006-05-31 at 14:49 -0500, Paul Varner wrote:
  If portage-2.1 is requested to be marked stable before then, we need to
  also make the same request for gentoolkit, so that we don't break it.

I don't think that we need to fast track marking gentoolkit-0.2.2 stable
at this point. However, as my last paragraph states, if portage-2.1 is
going to go stable before then, we should then fast track gentoolkit.

Regards,
Paul
-- 
gentoo-portage-dev@gentoo.org mailing list

[gentoo-portage-dev] portage-2.1 and gentoolkit-0.2.2

[Paul Varner]

Just a reminder that due to the changes in portage-2.1, that it breaks
gentoolkit-0.2.1 which is the current stable version.  I have placed
gentoolkit-0.2.2 in the tree which works with portage-2.1 and opened bug
#135068 http://bugs.gentoo.org/135068

I have not added the arch teams to the bug since it has obviously not
been in the tree for thirty days.  I will add the arch teams at that
time.

If portage-2.1 is requested to be marked stable before then, we need to
also make the same request for gentoolkit, so that we don't break it.

Regards,
Paul
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-dev] Not offering help to certain parts of society

[Paul Varner]

On Sat, 2006-04-01 at 16:41 +, George Prowse wrote:
 The problem is that we are in no way helping our Amish friends. If we
 made it easier to use linux then i'm sure they'd embrace FOSS straight
 away! I suggest some measures that would help them integrate better
 because it may be frowned upon at first. 

We could start by implementing RFC 1149.
http://www.faqs.org/rfcs/rfc1149.html

Regards,
Paul
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Portage-2.1_pre5

[Paul Varner]

On Tue, 2006-02-21 at 20:07 -0500, Alec Warner wrote:
 Your testing is appreciated.

The only thing that I have noted so far is that every emerge command is
printing ** before it does anything else. For example:

# emerge -pv portage

**
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-apps/portage-2.1_pre5  USE=-build -doc 0 kB [1]

Total size of downloads: 0 kB
Portage overlays:
 [1] /usr/local/portage

Regards,
Paul
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Portage-2.1_pre5

[Paul Varner]

On Tue, 2006-02-21 at 20:07 -0500, Alec Warner wrote:
 Your testing is appreciated.

I'll file a bug for this one, once I investigate further. 'genlop -t'
doesn't get along with it very well.

# genlop -t screen
 * app-misc/screen
snip

 Thu Dec 15 23:10:28 2005  app-misc/screen-4.0.2-r4
   merge time: 1 minute and 11 seconds.

 Wed Feb 22 13:11:30 2006  app-misc/screen-4.0.2-r4
   merge time: 5 days, 14 hours, 2 minutes and 13 seconds.

 Wed Feb 22 13:16:04 2006  app-misc/screen-4.0.2-r4
   merge time: 5 days, 14 hours, 6 minutes and 47 seconds.

 Wed Feb 22 13:16:47 2006  app-misc/screen-4.0.2-r4
   merge time: 5 days, 14 hours, 7 minutes and 30 seconds.

The last three emerges were done with 2.1_pre5 where I was testing the
effects of enabling confcache

Regards,
Paul
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Portage-2.1_pre5

[Paul Varner]

On Wed, 2006-02-22 at 18:35 -0800, Zac Medico wrote:
 After you've updated to the new ebuild (with patch), run `sed -i
 's/ Emerging/ emerge/g' /var/log/emerge.log` and genlop should
 work correctly again.
 

Did all of the above and everything is looking good.  Thanks for the
quick response

Regards,
Paul
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-dev] bootstrapping since gcc 3.4 is stable

[Paul Varner]

On Thu, 2006-01-26 at 16:55 -0600, MIkey wrote:
 Jan Kundrát wrote:
 
  Those are bugs against the revdep-rebuild package.
 
 Which is one of the suggested methods to migrate gcc.  Not necessary from
 stage1...

How does the listing of revdep-rebuild bugs have anything to do with
this topic? None of those bugs are relevant to either a stage 1 install,
stage 3 install, or gcc upgrade.

Regards,
Paul

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] emerge-webrsync patch

[Paul Varner]

On Wed, 2005-12-28 at 13:04 +0100, Johannes Fahrenkrug wrote:
 I put a nice -n 19 in front of the tar, rsync and emerge metadata 
 commands because normally calling emerge-webrsync renders my box 
 unusable for 15 to 20 minutes. You still notice a difference when using 
 nice but everything seems to be at least noticably smoother than before.

Instead of hardcoding the nice value, use PORTAGE_NICENESS.  Here is how
it is done in revdep-rebuild

# Obey PORTAGE_NICENESS
PORTAGE_NICENESS=$(portageq envvar PORTAGE_NICENESS)
[ ! -z $PORTAGE_NICENESS ]  renice $PORTAGE_NICENESS $$  /dev/null

Regards,
Paul
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] emerge-webrsync patch

[Paul Varner]

On Wed, 2005-12-28 at 17:38 +0100, Johannes Fahrenkrug wrote:
 Good point. Is this patch better? Or should it rather be _exactly_ as it 
 is in revdep-rebuild?

I personally would do it the same way as revdep-rebuild since that
causes the entire script and anything it calls to be run at the value
set in PORTAGE_NICENESS. However, the way you have done it works just as
well.

As far as your patch goes, you don't need to call the emerge metadata
with a nice value since the emerge command reads and uses the
PORTAGE_NICENESS value.

Finally, I am not a portage developer, so if this gets accepted and used
depends upon them and not me.

Regards,
Paul
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.14 stabilization

[Paul Varner]

 since we have baselayout-1.12.x in ~arch, the new stable candidate
 (1.11.14) isnt getting much air time ... can people try upgrading to
 it and post any feedback they have with it ?  it should mostly be a
 bugfix release over 1.11.13 since we arent doing any more real features
 for the 1.11.x branch ...

Looking good here on a stable x86 system.  The only thing that I noted
is that =sys-apps/sysvinit-2.86-r3 will have to go stable at the same
time due to it being a dependency.

Regards,
Paul
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving GCC-3.4 to stable on x86

[Paul Varner]

On Tue, 2005-11-29 at 18:37 +0100, Andreas Proschofsky wrote:
 It's not that easy for every package. For instance openoffice and
 openoffice-bin need to got to the same location, cause OOo does a user
 install and this will break when changing between them (and all the
 settings / paths and so on).
 
 So either we would have both in /opt which then means that the source
 based OOo is ignored too, or we have them in /usr/lib which results in
 the ooo-bin annoyance. I would say the second one is less harmful.
 
 Btw, there is a long running bug about the revdep-rebuild, which also
 has a solution for this:
 
 https://bugs.gentoo.org/show_bug.cgi?id=32276

While we are talking about this, I would like to point out the following
message that I sent here on November 3rd:

http://article.gmane.org/gmane.linux.gentoo.devel/32556/

To summarize, in order for revdep-rebuild to ignore binary packages, it
needs help from the package maintainers.  This is done, by the package
installing a file into /etc/revdep-rebuild/ that tells revdep-rebuild
what directories to ignore.

Regards,
Paul
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Binary packages and revdep-rebuild

[Paul Varner]

One of the common complaints with revdep-rebuild is that it wants to
constantly rebuild binary packages (most notably openoffice-bin). To
assist in resolving this issue, I have released gentoolkit-0.2.1_pre9
which adds the capability for an ebuild maintainer to adjust how
revdep-rebuild behaves towards binary packages.

The latest revdep-rebuild allows the user to control the following
variables:

LD_LIBRARY_MASK  - Mask of specially evaluated libraries
SEARCH_DIRS  - List of directories to search for executables and
libraries
SEARCH_DIRS_MASK - List of directories to not search

With the capability that I just added, a package maintainer can now
adjust the same variables.  To use this capability do the following:

1. Install a file into /etc/revdep-rebuild (I'm using the same
convention as /etc/env.d and prefixing the files with a number)
2. Inside of the file, place the appropriate changes to the variables.

For example: I have the following
file /etc/revdep-rebuild/10openoffice-bin on my system

# openoffice-bin revdep-rebuild configuration file
SEARCH_DIRS_MASK=/usr/lib/openoffice

3. revdep-rebuild will accumulate the variables in the following order:

environment, /etc/make.conf, /etc/revdep-rebuild/* 

This means that a user can override your changes if desired, but your
changes will be honored by default.

Finally, one other change that I am considering is to add a PACKAGE_MASK
variable that will only be read from the files in /etc/revdep-rebuild
and cannot be overridden by the user (except by editing the file).  The
purpose will be to tell revdep-rebuild to never attempt to rebuild that
package. Before I implement that I would like to get some feedback on if
that is a desired feature.

Regards,
Paul



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

Re: [gentoo-portage-dev] ECONF_EXTRA handling: bug 38618

[Paul Varner]

On Fri, 2005-10-07 at 16:03 -0500, Brian Harring wrote:
 It allows for users to override ebuild defined configure options, 
 potentially shooting themselves in the foot, but in the same token 
 they can already shoot themselves in the foot via EXTRA_ECONF...

Since EXTRA_ECONF is all about letting users shoot themselves, I see no
reason not to.

Regards,
Paul
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] PATCH: gentoolkit: Make portage.config object a global object

[Paul Varner]

On Tue, 2005-09-20 at 19:00 -0500, Brian Harring wrote:
 On Tue, Sep 20, 2005 at 06:55:44PM -0500, Paul Varner wrote:
  On Tue, 2005-09-20 at 18:34 -0500, Brian Harring wrote:
Updated patch to add a semaphore to control access to the global
portage.config object. Unless anyone sees any other issues with this
patch, I will be placing it into gentoolkit.
   Reason for a semaphore over threading.Lock ?
  
  No reason other than I'm used to thinking of them as semaphores instead
  of locks, so semaphore is what I searched for in the Python docs.
 Need to make some chunks of the rewrite thread safe, so I poked a bit;
 python -m timeit -n 1 -r 3 -s 'import threading;s=threading.Lock()' 
 's.acquire();s.release()'
 around 1us
 python -m timeit -n 1 -r 3 -s 'import threading;s=threading.Semaphore()' 
 's.acquire();s.release()'
 20us
 

Okay, I've changed the Semaphore to a Lock and removed the
self._settings.reset() call.  

Anything else before I commit this?

Regards,
Paul

PS: As an aside the command 'equery hasuse perl' goes from 34s to 2s on
my Pentium 4 with this patch.
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-dev] revdep-rebuild

[Paul Varner]

On Sun, 2005-08-14 at 16:32 +0200, Diego 'Flameeyes' Pettenò wrote:
 On Sunday 14 August 2005 16:20, Stefan Jones wrote:
  But you could use ldconfig -p to gain a list of all the libraries, put
  them in a hash table and then use scanelf.
 Please don't. FreeBSD's ldconfig is *not* the same and this would mean 
 breaking (again) revdep-rebuild on Gentoo/FreeBSD.
 

Actually, for the next major revision, I am planning on some major
collaboration between myself, the Gentoo/FreeBSD team, the OSX team,
solar/vapier, and anyone else that is interested.  

The biggest complaint right now is lack of speed and that means
investigating and exploring the different ways of determining library
breakage. Some of those solutions are definitely not portable.

Regards,
Paul

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: gcc-config 2.0 development

[Paul Varner]

On Tue, 2005-08-09 at 18:14 -0400, Daniel Ostrow wrote:
 On Tue, 2005-08-09 at 15:12 -0700, Jeremy Huddleston wrote:
  On Tue, 2005-08-09 at 22:19 +0100, Ciaran McCreesh wrote:
   | but I think having the xml configuration files allows a much more
   | robust configuration.
   
   How so? Using XML doesn't magically make your data files any different.
   It simply makes them much harder to parse.
  
  That's a matter of opinion.  I see it as a way to abstract away the
  configuration and utilize an existing library to handle the parsing.  If
  we do want to eliminate outside dependencies (which I think is an
  extremely valid point and concern), then we could internally implement a
  different configuration format that is easier to parse.  I'd probably go
  for something similar to the samba/gdm config files if we were to go
  down this road:
 
 snip
 
 I've always been a fan of samba style config files..unlike xml they tend
 to be both easy to parse and are human readable. I'd far rather see this
 over XML. It's especially attractive as this is also the way that
 portage is moving (at the moment) as well.

AOL
me too
/AOL

I highly prefer the samba style config file over an XML file. It is easy
to read, parse, and edit by both human and machine.

Regards,
Paul
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unmasking of gentoolkit-0.2.1_pre3

[Paul Varner]

On Fri, 2005-06-24 at 14:47 +0200, Sven Köhler wrote:
 Last time i used revdep-rebuild, i saw that revdep-rebuild does check
 things twice, since therere symlinks like /usr/X11R6/lib to /usr/lib.
 
 It this fixed in the new version?

Yes it is.  Here is the list of bug fixes and enhancements:

* Delete temporary files if the environment does not match the previous
environment (bug 95274)
* Imported revdep-rebuild release from bug 62644
* Major changes to the functionality when using --package-names/-X The
script should now update slotted packages correctly. (bug 22161)
* Customizable searching controlled through environment variables.  This
removes the need for end users to directly modify the script.  (bugs
32276, 38011, 59803)
* The directories to search are no longer hard coded into the script.
revdep-rebuild now determines the directories to search based
upon/etc/profile.env and /etc/ld.so.conf. (bugs 32276, 38011, 89781)
* --ignore option to ignore temporary files left from previous runs.
Automatically ignore temporary files older than 24 hours. (bug 34052)
* Always return an exit status based upon success or failure. (bug
38472)
* Fixed to only emerge packages with direct missing dependencies. (bug
38487)
* New man page. (bug 40042)
* emerge is no longer called with --nodeps. This allows for needed
dependencies to be pulled in. (bug 62893)
* Cleaned up grammatical errors (bug 85278)
* Added support for revdep-rebuild --soname /path/to/library.so (bug
91503)
* Removed symbolically linked directories from search (bug 93574)
* --nocolor option to turn off colored output, the script also obeys the
NOCOLOR setting from /etc/make.conf.
* Removed dependency on qpkg
* Script uses PORTAGE_NICENESS from /etc/make.conf
* Undocumented --keep-temp option.  This is primarily for
debugging/testing.  This option prevents temporary files from being
deleted.
* Changed --soname --soname-regexp options to --library and treat all
arguments as basic regular expressions. --soname and --soname-regexp can
still be used as options for backwards compatability.
* Removed requirement to keep revdep-rebuild and emerge options
distinct.  Options that are unrecognized by revdep-rebuild are passed
directly to emerge.

Regards,
Paul


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Unmasking of gentoolkit-0.2.1_pre3

[Paul Varner]

Unless there are objections, I am planning on unmasking
gentoolkit-0.2.1_pre3 this weekend.  This build of gentoolkit contains
the new version of revdep-rebuild.  This version has been in the tree
and package masked since 12 June. During that time, I have not received
any bug reports and the feedback that I have seen from the gentoo-user
mailing list has been positive.

Even though I am unmasking the package, I still need the following
architectures to test and keyword the ebuild as requested in bug #62644

mips arm hppa ia64 ppc64 s390 ppc-macos

Regards,
Paul

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Request for testing revdep-rebuild (gentoolkit-0.2.1_pre3)

[Paul Varner]

All:

I have bumped gentoolkit to 0.2.1_pre3 and package masked it for
architecture testing and general testing of the new improved
revdep-rebuild.  This version contains lots of bug fixes and I would
like give it a workout before unmasking.

There are some major changes in identifying the broken links and since I
only have access to x86, I want to make sure that I have not broken
portability to other achitectures. Because of this, I have keyworded
this ebuild with -* ~x86.

I have CC'ed the architecture teams on bug #62644. However, if you are
interested in helping to test, please add gentoolkit to
your /etc/portage/package unmask and let me know of your results.

Regards,
Paul
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers

[Paul Varner]

On Wed, 2005-06-01 at 21:59 -0400, Mike Frysinger wrote:
 On Wednesday 25 May 2005 06:20 pm, Mike Frysinger wrote:
  yes, it's finally that time ... after months of hearing us say 'we want to
  get new baselayout stable asap', we're serious
 
 last chance !
 
 can someone forward the original e-mail here to gentoo-user ?

The comments back from gentoo-user have been that it works fine.  One
was a glowing endorsement of all the changes.

Regards,
Paul
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] module-rebuild

[Paul Varner]

On Wed, 2005-05-04 at 00:00 +0100, John Mylchreest wrote:
 Can I please introduce into the tree sys-kernel/module-rebuild.
 This tracks linux-mod installed kernel modules, and also gives you the
 ability to remove/add/toggle the list of modules to rebuild.
 
 Basically.. following a kernel upgrade running: module-update rebuild,
 will install all modules installed via portage.
 
 If you experience any problems, please file a bug at bugzilla. Likewise,
 please file a bug and assign it to [EMAIL PROTECTED] if you have any
 ideas about the tool.

Thanks!

I'm installing and playing with it as I type.  The code looks a lot
cleaner than the code I had plagiarized from revdep-rebuild to do the
same thing.

Regards,
Paul
-- 
My Gentoo stuff: http://varnerfamily.org/pvarner/gentoo
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New apache stuff in testing - please package.mask it

[Paul Varner]

On Thu, 2005-04-21 at 05:48 +0100, Elfyn McBratney wrote:
 I've filed a bug[1] requesting that ebuilds with updated apache stuff 
 (anything using the new apache-module or depend.apache eclass/the new install 
 layout) be package.mask'd due to the regressions and breakages in testing.  I 
 may have missed packages in the bug, hence this mail - you know best if your 
 using new stuff. :)
 
 Please package.mask said ebuilds ASAP so we can get apache itself into 
 package.mask.

Even though I stated my opinion that I would like to see the new changes
package masked again, the consensus that I read on the thread disagreed
with that approach.

My unsolicited opinion based upon the previous thread is since it is
already out of the bag, leave it in ~arch and actively work the bugs so
that you can get it to the point of being able to mark it stable.

Regards,
Paul
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [Bug 89729] configure always print a warning message about possibly mistaking build system type

[Paul Varner]

On Wed, 2005-04-20 at 09:52 -0400, Mike Frysinger wrote:
 On Wednesday 20 April 2005 08:27 am, Harald van Dk wrote:
  Perhaps
  make.conf.example (that's provided by portage, right?) should include
  CBUILD, assuming it doesn't cause problems?
 
 i'm afraid the possibility of users botching this makes it not worth the 
 effort
 
 better to keep the definition of CBUILD 'hidden' from most eyes

As a user, I had the same thought.  Why not have portage set it
appropriately unless the user has explicitly defined it?  That of course
is making the assumption that someone who has explictly set the CBUILD
variable knows what they are doing, since they had to go through the
trouble of learning about it and the fact that they could set it.

Regards,
Paul

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask

[Paul Varner]

On Sat, 2005-04-16 at 06:56 +0100, Elfyn McBratney wrote:
 The way I see it, we have three options:
  - package.mask (downgrades for those early adopters)
  - keep the same layout (/etc/apache2/conf, etc.) and wait until 2.2 is out to
change it
  - have the newer apache ebuilds migrate from old-style to new-style config
(very hard to do, but possible)
 

As a user whose apache install is completely hosed at the moment due to
these changes, my recommendation is all the above, with it being package
masked immediately.

Regards,
Paul
--
gentoo-dev@gentoo.org mailing list