[gentoo-dev] Re: [gentoo-dev-announce] crypto@ packages up for grabs

[Mike Auty]

I'd like to claim:

> app-crypt/ssdeep

and

> app-crypt/xca

I'll add my information to the metadata.xml for them...

Mike  5:)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

[Mike Auty]

Hiya,

On 13/09/2018 01:23, Chí-Thanh Christopher Nguyễn wrote:
> Installation will proceed, but the user will get a big fat warning that
> the sys-fs/zfs package is potentially broken.

This seems like a sure-fire way to make users paranoid and/or
desensitized?  People will learn to ignore warnings if we make them big
red and flashing but then say they're only potential breakages (and they
subsequently discover that most everything runs fine).  If they learn to
ignore big red flashing warnings it'll be more difficult when they're
not potential breakages but actual ones we've accurately identified...

Mike  5:)



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-vcs/giggle

[Mike Auty]

# Mike Auty  (22 Jun 2018)
# Not maintained upstream, at least one bug and three upstream bugs
# Removal in 30 days. Bug #658264
dev-vcs/giggle

Mike  5:)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] How to deal with git sources?

[Mike Auty]

So,

tldr; Github will tarball up specific commits (or master) for you to add
to SRC_URI.

I ended up using the github API to pull down a tarball of the git repo,
rather than using git to pull it down.  I suppose that offers the
ability to Manifest it and check for changes, but I now have to encode
the fixed commit into every version of the ebuild because the only
location it's recorded is in the submodule commit hash of the package's
repo.

I could have it live in the PV, but I think that'd lead to potential
version sorting errors if people try and use copies of the ebuild.
Making typeshed its own package doesn't help because it's installed
under /usr/share/mypy/typeshed, not /usr/share/typeshed so it really is
part of mypy (for now).  So I'll see how this goes and listen for
feedback...

Mike  5:)

On 11/03/18 18:05, Mike Auty wrote:
> Hiya,
> 
> I'm trying to update/package up mypy for the main tree which, whilst it
> provides a release tarball, relies upon a data library (typeshed) which
> does not provide releases.  The recommended method of installation by
> upstream is to use git submodules (which the ebuild will do happily),
> but repoman rightly complains about LIVEVCS issues.
> 
> Is the current recommended method for dealing with this to manually
> create a tarball and stash it on dev.gentoo.org somewhere accessible or
> are there updated guidelines for this kind of scenario?  If so, where
> would they be documented?  Searching for LIVECVS found a bunch of
> repoman change discussions, but no documentation as to how to deal with
> ebuilds that require this...
> 
> Mike  5:)
> 




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] How to deal with git sources?

[Mike Auty]

Hiya,

I'm trying to update/package up mypy for the main tree which, whilst it
provides a release tarball, relies upon a data library (typeshed) which
does not provide releases.  The recommended method of installation by
upstream is to use git submodules (which the ebuild will do happily),
but repoman rightly complains about LIVEVCS issues.

Is the current recommended method for dealing with this to manually
create a tarball and stash it on dev.gentoo.org somewhere accessible or
are there updated guidelines for this kind of scenario?  If so, where
would they be documented?  Searching for LIVECVS found a bunch of
repoman change discussions, but no documentation as to how to deal with
ebuilds that require this...

Mike  5:)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[Mike Auty]

On 10/03/18 14:52, Pacho Ramos wrote:
> This packages are now up for grabs:
> ...
> dev-python/mypy
> ...

I can look after this one if nobody else wants it?

Mike  5:)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Mike Auty]

On 08/02/18 20:55, Mike Gilbert wrote:
> However, there are plenty of examples of commands that normal users
> may run from sbin.
Hiya,

I'm not really for or against the idea, but whenever the justification
for something is "there are plenty of examples" it's really helpful to
have a number of them listed so that people can see what actual benefit
is being provided by the change.  Could you name a few of the most
common/important examples so that it's part of the discussion please?

Mike  5:)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] bzipped manpages

[Mike Auty]

Hiya Jan,

The following snippet from Ingo is correct:

> So, you want to hear something constructive?  Your best option is to
> just decompress that stuff on your system.  (Gentoo is famous for
> its excessive configurability - maybe there is even an option?)

We are both famous for our excessive configurability and there is even
an option already!  5:)  If you look in the manpage (once you've
decompress it somewhere, or online at [1]) for make.conf, you'll see the
entry for PORTAGE_COMPRESS, which you can set as follows:

PORTAGE_COMPRESS=""

As mentioned in [2,3,others].  You'll then need to reinstall all
packages.  If you manually decompress the files, then the uncompressed
manpages won't be registered with portage and won't get removed if the
owning package is uninstalled.  Hope that helps...

Mike  5:)

[1] https://dev.gentoo.org/~zmedico/portage/doc/man/make.conf.5.html
[2] https://blog.flameeyes.eu/2007/12/a-word-against-ecompress/
[3] http://www.gossamer-threads.com/lists/gentoo/user/286024



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Developer GitHub usernames

[Mike Auty]

Sorry for the spam!

Apparently the sender of list mails isn't the actual author of the
message.  5:S

Mike  5:)

On 21/11/16 09:27, Mike Auty wrote:
> Hiya,
> 
> It wasn't clear how to get added to the github team in the first place,
> but I've got the same username on github as I use for my gentoo handle
> (ikelos).  I've also now got my ike...@gentoo.org GPG key verified on
> there if you're after confirmation.  Thanks!
> 
> Mike  5:)
> 
> On 21/11/16 09:01, Michał Górny wrote:
>> Hi, everyone.
>>
>> I've finally found a little time to work on syncing our teams to
>> GitHub. For this reason, I've prepared a mapping from Gentoo developer
>> names to GitHub usernames:
>>
>> https://github.com/mgorny/dev2github/blob/master/devs.json
>>
>> I've filled it based on people in our GitHub developers team. Some of
>> the developers are certainly missing there. Since some of our people
>> don't want to admit they're using GitHub or otherwise want to pretend
>> they're not, and some of the developers are already retiring I didn't
>> go forward attempting to find more people.
>>
>> Please ping me if you're mapped to an empty string (i.e. no GitHub
>> account) and would like to get added to teams on GitHub. I'll invite
>> you to the developers team then and add you to the list. Thanks.
>>
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Developer GitHub usernames

[Mike Auty]

Hiya,

It wasn't clear how to get added to the github team in the first place,
but I've got the same username on github as I use for my gentoo handle
(ikelos).  I've also now got my ike...@gentoo.org GPG key verified on
there if you're after confirmation.  Thanks!

Mike  5:)

On 21/11/16 09:01, Michał Górny wrote:
> Hi, everyone.
> 
> I've finally found a little time to work on syncing our teams to
> GitHub. For this reason, I've prepared a mapping from Gentoo developer
> names to GitHub usernames:
> 
> https://github.com/mgorny/dev2github/blob/master/devs.json
> 
> I've filled it based on people in our GitHub developers team. Some of
> the developers are certainly missing there. Since some of our people
> don't want to admit they're using GitHub or otherwise want to pretend
> they're not, and some of the developers are already retiring I didn't
> go forward attempting to find more people.
> 
> Please ping me if you're mapped to an empty string (i.e. no GitHub
> account) and would like to get added to teams on GitHub. I'll invite
> you to the developers team then and add you to the list. Thanks.
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] .git folder getting mirrored to rsync mirrors

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hiya,

I also experienced this (on 2a01:488:67:1000:b01c:3277:0:1).  It will
also prevent portage from resyncing because it assumes the portage
tree is under revision control (when there's just git directories, no
actual data).  It looks like infra are on the case:
https://infra-status.gentoo.org/

Mike  5:)

On 29/11/15 09:17, Joshua Kinard wrote:
> 
> Looks like some part of the .git folder got mirrored to the rsync
> mirrors.  I'm seeing this on rsync25.us.gentoo.org.  Seems to
> bugger repoman up if you run "repoman manifest".  It sees that .git
> folder and complains that the portage tree is not a valid git
> location or such.  Deleting the folder fixes the issue.
> 
> 
> receiving incremental file list timestamp.chk
> 
> Number of files: 1 (reg: 1) Number of created files: 0 Number of
> regular files transferred: 1 Total file size: 32 bytes Total
> transferred file size: 32 bytes Literal data: 32 bytes Matched
> data: 0 bytes File list size: 33 File list generation time: 0.001
> seconds File list transfer time: 0.000 seconds Total bytes sent:
> 98 Total bytes received: 1.15K
> 
> sent 98 bytes  received 1.15K bytes  830.67 bytes/sec total size is
> 32  speedup is 0.03 
> - ___
> ___   ___   ___ /\__\ /\  \ /\  \
> /\  \ /:/  //::\  \   /::\  \   /::\  \ /:/  /
> /:/\ \  \ /:/\ \  \ /:/\:\  \ /:/  /  ___   _\:\~\ \  \
> _\:\~\ \  \   /:/  \:\  \ /:/__/  /\__\ /\ \:\ \ \__\ /\ \:\ \ \__\
> /:/__/_\:\__\ \:\  \ /:/  / \:\ \:\ \/__/ \:\ \:\ \/__/ \:\  /\
> \/__/ \:\  /:/  /   \:\ \:\__\\:\ \:\__\\:\ \:\__\ \:\/:/
> / \:\/:/  / \:\/:/  / \:\/:/  / \::/  /   \::/  /
> \::/  /   \::/  / \/__/ \/__/ \/__/
> \/__/
> 
> Indiana University Unix Systems Support Group 
> ftp://ftp.ussg.iu.edu/ Located in Bloomington, Indiana AKA:
> rsync25.us.gentoo.org
> 
> Questions and comments to: u...@iu.edu
> 
> !!!NOTICE!!! Maintenance window is every Tuesday beginning at 0900
> (1400 GMT)
> 
> -
> 
> receiving incremental file list .git/ .git/hooks/ .git/info/ 
> .git/logs/ .git/logs/refs/ .git/logs/refs/heads/ 
> .git/logs/refs/remotes/ .git/logs/refs/remotes/origin/ 
> .git/logs/refs/remotes/origin/dev/ 
> .git/logs/refs/remotes/origin/project/ .git/objects/ 
> .git/objects/00/ .git/objects/01/ .git/objects/02/ 
> .git/objects/03/ .git/objects/04/ .git/objects/05/ 
> .git/objects/06/ .git/objects/07/ .git/objects/08/ 
> .git/objects/09/ .git/objects/0a/ .git/objects/0b/ 
> .git/objects/0c/ .git/objects/0d/ .git/objects/0e/ 
> .git/objects/0f/ .git/objects/10/ .git/objects/11/ 
> .git/objects/12/ .git/objects/13/ .git/objects/14/ 
> .git/objects/15/ .git/objects/16/ .git/objects/17/ 
> .git/objects/18/ .git/objects/19/ .git/objects/1a/ 
> .git/objects/1d/ .git/objects/1e/ .git/objects/1f/ 
> .git/objects/20/ .git/objects/22/ .git/objects/23/ 
> .git/objects/24/ .git/objects/25/ .git/objects/26/ 
> .git/objects/27/ .git/objects/28/ .git/objects/29/ 
> .git/objects/2a/ .git/objects/2b/ .git/objects/2c/ 
> .git/objects/2d/ .git/objects/2e/ .git/objects/2f/ 
> .git/objects/30/ .git/objects/31/ .git/objects/32/ 
> .git/objects/33/ .git/objects/34/ .git/objects/35/ 
> .git/objects/36/ .git/objects/37/ .git/objects/38/ 
> .git/objects/39/ .git/objects/3a/ .git/objects/3b/ 
> .git/objects/3c/ .git/objects/3d/ .git/objects/3e/ 
> .git/objects/3f/ .git/objects/40/ .git/objects/41/ 
> .git/objects/42/ .git/objects/43/ .git/objects/44/ 
> .git/objects/45/ .git/objects/46/ .git/objects/47/ 
> .git/objects/48/ .git/objects/49/ .git/objects/4a/ 
> .git/objects/4b/ .git/objects/4c/ .git/objects/4d/ 
> .git/objects/4e/ .git/objects/4f/ .git/objects/50/ 
> .git/objects/52/ .git/objects/53/ .git/objects/54/ 
> .git/objects/55/ .git/objects/56/ .git/objects/57/ 
> .git/objects/58/ .git/objects/59/ .git/objects/5a/ 
> .git/objects/5b/ .git/objects/5c/ .git/objects/5d/ 
> .git/objects/5e/ .git/objects/5f/ .git/objects/60/ 
> .git/objects/61/ .git/objects/62/ .git/objects/63/ 
> .git/objects/64/ .git/objects/65/ .git/objects/66/ 
> .git/objects/67/ .git/objects/68/ .git/objects/69/ 
> .git/objects/6a/ .git/objects/6b/ .git/objects/6c/ 
> .git/objects/6d/ .git/objects/6e/ .git/objects/6f/ 
> .git/objects/70/ .git/objects/71/ .git/objects/72/ 
> .git/objects/74/ .git/objects/75/ .git/objects/76/ 
> .git/objects/77/ .git/objects/78/ .git/objects/79/ 
> .git/objects/7b/ .git/objects/7c/ .git/objects/7d/ 
> .git/objects/7e/ .git/objects/7f/ .git/objects/80/ 
> .git/objects/81/ .git/objects/82/ .git/objects/83/ 
> .git/objects/84/ .git/objects/85/ .git/objects/86/ 
> .git/objects/87/ .git/objects/88/ .git/objects/89/ 
> .git/objects/8a/ .git/objects/8b/ .git/objects/8c/ 
> .git/objects/8d/ .git/objects/8e/ .git/objects/8f/ 
> .git/objects/90/ .git/objects/91/ .git/objects/92/ 
> 

Re: [gentoo-dev] Re: ffmpeg vs libav choice of default

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hiya,

On 07/02/15 05:16, Ben de Groot wrote:
 I discussed this beforehand with said developer on IRC.

Ok, that wasn't clear from the commit message.

 Do you think a news item to explain this situation and giving
 explicit instructions for users who wish to stay with libav would
 be useful?

No, I think the coincidence of the timing was unfortunate, but it's
done now, and if it had been done a month or so after the first news
item, it wouldn't have needed any explanation, so probably best just
to leave it now.  Perhaps a forums article, just so the instructions
are available somewhere, but I don't think it deserves a fully fledged
news article.

 No. Users can unmask the useflag and build mpv with libav if they
 wish.

You're quite right, the point I was trying to make was that unmasking
a USE flag is a very uncommon event, and as such I think seen as
riskier than simply unmasking a package.  It doesn't stop people
building the newer mpv, it just makes them jump through more hoops to
follow the news article's guidance.  If you're happy with that
requirement for that package then there's no real problem...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iKYEARECAGYFAlTWN7xfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEZGQjEyM0ZDRDBCRjcwREE1MzA0MjNBREJC
QkFENkEyNkMyMDE1N0EACgkQu7rWomwgFXqTMQCgoAmuIE3YISgo0dEc1l/5DMT5
y+oAn2wLZG2Wds5Is5cLKbksrCTvjyq6
=NwzJ
-END PGP SIGNATURE-

Re: [gentoo-dev] ffmpeg vs libav choice of default

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hiya,

On 06/02/15 11:49, Ben de Groot wrote:
 Since we introduced the libav useflag, we have now a way to
 finally make mpv-0.7* (using the upstream recommended ffmpeg as
 default) visible to ~arch users, without the need to unmask it.
 Users who wish to use libav with it, can do so by unmasking the
 useflag and the relevant libav version. (While before they would
 have had to unmask both mpv and libav. The resulting change is
 minor.)

I guess I see knowing how to unmask USE flags (uncommon event) as more
difficult than unmasking a couple of packages (much more common
event).  It's also particularly confusing given that there was a news
article published saying libav was now the default and that people
could explicitly swap to mpv with libav.  The news article might have
been published prematurely or without checking, I've no idea.

Either way, what's going on at the moment is causing users confusion,
and I was just suggesting that the decisions be made first and then
action taken, rather than this back and forth we're having with
packages and USE flags and masking of all kinds, which is not giving
our users a good experience, even if the change is for the best.

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iKYEARECAGYFAlTVeoJfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEZGQjEyM0ZDRDBCRjcwREE1MzA0MjNBREJC
QkFENkEyNkMyMDE1N0EACgkQu7rWomwgFXpcrgCggW9zbw+7ZTfO2CZ75w40voS4
Fp4An31h4XyQ6YGnvEw1Py7bdEcXRDqk
=Or5S
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: ffmpeg vs libav choice of default

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hiya,

On 06/02/15 08:48, Duncan wrote:
 Daniel Campbell posted on Thu, 05 Feb 2015 22:55:05 -0800 as
 excerpted:
 
 As a user and prospective developer, why? Transparency is
 important to open communities like Gentoo's, and reading the
 discussions can give users and developers alike some context that
 they wouldn't normally get if they hadn't seen the
 discussion(s).
 
 (As a user myself...) I believe he's referring not to the technical
  disagreements themselves, but to the practical effects on users of
  unmasking, remasking, unmasking, changing USE flags, changing the
 / meaning/ of USE flags, changing USE flag defaults... before a
 final plan of action is settled on.

Duncan was absolutely right, and I communicated myself poorly.  I have
no issue with them discussing the best course of action.  I positively
would like to get this situation resolved as quickly as possible!  I
was concerned that a warning which had been in place in package.mask
since September was removed by a different developer than the one who
put it in place, and that a package was unmasked (while a USE flag was
masked) which then forced everyone who read the portage news article
and swapped mplayer to mpv based on the article, to then be told they
have to rebuild with ffmpeg after all, and potentially rebuild a lot
of other packages because of that.  The mask of the USE flag even
removed the possibility of building the newer mpv with libav, even
though it's actually possible (so users who'd unmasked =libav-10,
could no longer build mpv-0.7.x when the had previously).

I don't care which way it gets sorted out, but having such direct
effects on users, without agreement or even discussion of the action
beforehand is what I'd like to avoid (and then poorly phrased as
airing in front of the users, for which I apologize)...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iKYEARECAGYFAlTVc7tfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEZGQjEyM0ZDRDBCRjcwREE1MzA0MjNBREJC
QkFENkEyNkMyMDE1N0EACgkQu7rWomwgFXqPrgCfdyve0LLT1eeMPTo8+sPaLs7s
4TYAn2joniuA4LOPbU03XRLBXoh7gWX/
=lSq2
-END PGP SIGNATURE-

Re: [gentoo-dev] ffmpeg vs libav choice of default

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Whilst the default *is* still in place (and particularly after the
recent news article detailing that users should be using libav), could
we please keep commits like the following until *after* we've made an
agreed upon decision please?

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/package.mask?r1=1.16328r2=1.16329

Anyone using mpv (because mplayer does not work with libav, and they
were directed to use mpv by the news article) will now be hit by
blockers attempting to reinstall ffmpeg.

It's fine to have disagreements, but airing them in front of the users
like this is not an ideal situation...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iKYEARECAGYFAlTSE/pfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEZGQjEyM0ZDRDBCRjcwREE1MzA0MjNBREJC
QkFENkEyNkMyMDE1N0EACgkQu7rWomwgFXos8ACeIq/rqIdp9DAowP2qVyrUQFfn
4rUAn1coOLGSk60pA9VSbKdXBnPiiSki
=aOWg
-END PGP SIGNATURE-

Re: [gentoo-dev] Adding large files to the mirrors?

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hiya,

First off, thanks everybody for the suggestions.  It seems like people
aren't keen to mirror the large tables on our mirrors, but no one's
mentioned a reason for not doing so.  Is there an infra reason behind
that or did everyone just take my caution and run with it?

On 16/10/13 02:40, Chí-Thanh Christopher Nguyễn wrote:
 I suggest that you add a large USE flag, and if it is enabled,
 download and install the whole thing. If disabled, just print the
 URLs in a log message, so the user can download themselves if they
 wish.

So downloading them manually is a pain (the larger tables aren't in a
single zip, they're split amongst 12 files for each table), and the
ebuild to do the downloading is already built.  I'll include a
postinst note indicating that the tables are getting stored twice, and
I should even be able to give them an indication of how much space
they're wasting.  I'll also provide a URL they can visit if they want
to download manually instead.

The question then becomes, do I split the ebuild into two (giving us
three ebuilds for what is otherwise a tiny package) just so some SRCs
are mirror-restricted and others aren't?  All of that hinges on
whether our servers can handle the extra size...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlJeWR4ACgkQu7rWomwgFXq8bQCfRde/Tg7sAirqT05d5spckC+s
fUIAoIH1SlXvLmM3CqM0x1vQN0oPdiKi
=qqsa
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Adding large files to the mirrors?

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 16/10/13 12:01, Duncan wrote:
 If it's a core requirement, no problem.  But the further from core
  requirement it gets the more sensitive infra seems to be about
 non- trivial space requirements, and any way you look at it, 30
 gigs of rainbow tables are both non-core and non-trivial,
 especially with the split package and no-mirror on the big package
 solution, so...

No, that's fine.  I wanted to check, because I don't take the
resources for granted, but I do see us as providing a mirroring
service for open source projects (to a degree), and no one so far had
put forward an opinion about how infra would feel about it.

Anyway, Francesco made an excellent point, and I think I'll be going
with the additional bash script for grabbing the large tables...

Thanks for you help everyone!  5:)

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlJfGKkACgkQu7rWomwgFXo7dwCeIgp2WTS5vaBpG+zNTzdw0Q6g
4ocAoLUlnjIcZzcWzJ8Va1P5mdx65moP
=Y1m5
-END PGP SIGNATURE-

Re: [gentoo-dev] Adding large files to the mirrors?

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hiya,

On 16/10/13 12:54, Francesco R. wrote:
 Il 16/10/2013 11:15, Mike Auty ha scritto: Add a bash script that
 can download all the files and mention it in postinst. the script
 will download all the files in current directory and put them in
 the correct place.

That's an absolutely awesome suggestion, I'll do that!  Thanks!  5:)

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlJfGK8ACgkQu7rWomwgFXrUIACfTTUcmqbApW4CqMlNd3YLC5yp
pLwAn0hUHOEoG+noOMtgHqhBtKFb6tbT
=E9tY
-END PGP SIGNATURE-

[gentoo-dev] Adding large files to the mirrors?

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

I'm updating the app-crypt/ophcrack-tables package to include the new
tables available from their site.  These are basically just additional
data packages that can be useful with the app-crypt/ophcrack package,
but they're very large.  Including all of them will come just short of
30Gb.  I don't know whether it's ok to add that to our mirrors, or add
RESTRICT=mirror?

Also, these take up a lot of space in distfiles.  Does anyone know of
a clever way to allow them to be installed without also stashing a
copy in distfiles (symlinking to the distfiles directory is a no go,
because each set needs its own files to have the same name as the
other sets)?

I guess it's a bit of an infra question, but thought I'd ask here in
case anyone else has found themselves in a similar situation.  For
more specifics about what the package is like/for see the test ebuild
at [1]...

Mike  5:)

[1]
http://git.overlays.gentoo.org/gitweb/?p=dev/ikelos.git;a=blob;f=app-crypt/ophcrack-tables/ophcrack-tables-1.1.ebuild
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlJdzaQACgkQu7rWomwgFXqq1wCePSA0S03pVVxeesqAbd2faO4h
2wgAn0P0y5dvhsArRnFdFajrApM5C4YV
=fim1
-END PGP SIGNATURE-

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/08/13 23:42, Wulf C. Krueger wrote:
 On 09.08.2013 02:26, Mike Auty wrote:
 I could be a KDE developer, or a Gentoo documenter, or work on 
 mplayer.  All those people are open source contributors and 
 necessary ones, but that doesn't mean that any of them
 necessarily has the skills or the time to look after udev.  Does
 that invalidate their opinion on the choices of upstream project
 they rely on?
 
 Yes, it does.

In that situation then, developers are only developing for themselves?
 What's more likely is that they've taken a gamble that most users
will simply accept their changes, which they deem as necessary to move
forward.

That would be fine if there were alternative options, but as more and
more things are vertically integrated the choices made by one
project are knocking over into others.  Before I could simply ignore
systemd and choose something else, now I'm having to choose between
using both Gnome and systemd, or neither.

It is a difficult choice, but just as Gnome has chosen to forsake my
desire for a simplistic init system at the expense of a little boot
speed and some features I've never needed in the past, I'm having to
walk away to some other less well developed desktop environment.  The
cost of ignoring their users opinions is losing the users themselves.
 I don't know how many users they'll have to lose before someone
decides to take the ship in a new direction, but I would like to see
how many they stand to lose, by asking those who care to speak up and
find a way of being heard before the damage is too much to repair...

Mike  5:\
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIGyGUACgkQu7rWomwgFXpeugCeMGQmjB7tcnpZd12DF8Baml0s
xcsAn12+EXQwTSwTeK0lautDxJmwgC7r
=tgWV
-END PGP SIGNATURE-

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/08/13 00:45, Canek Peláez Valdés wrote:
 They thought deeply about the changes that are being made to the 
 desktop, and they discussed it and reached a consensus about what
 the direction of the project is; you can usually read about in the
 mailing lists, Planet GNOME, or even watch the videos from the
 GUADEC presentations. You can of course disagree with that
 direction: but acting like they, poor things, don't know what they
 are doing and need that someone go an tell them so they can know
 before the damage is much to repair, is quite condescending.

I'm not trying to be condescending and I'm not suggesting they don't
know what they're doing.  If I were to suggest it, doing so on a
Gentoo thread about stabilization would be futile.  The only reason
I'm responding on here is to find out from others in my community if
there's a place that people are collecting their opinions such that it
might be heard/discussed by the people at Gnome.

 People have been predicting the dead of GNOME since before the 1.0 
 version came out, but right now it has more contributors than ever
 in the past, and at least half a dozen companies actually pay money
 to people to work in it, so perhaps they actually know what they
 are doing. But even if they don't, there are a couple forks you can
 try or several alternatives you can switch to if the damage is too
 much to repair.

Just because companies pour money into something does not mean they
know what they're doing, or that they've done their market research
into what their users want.  I've tried several of the forks, and
sadly Gnome, because of the backing it's had, hangs together as a
Desktop Environment the best which is precisely why it's so
disappointing they've chosen this strong a demand of their users.  I
have even tried systemd, which realized rather than allayed my fears,
but this isn't the place for my personal experiences with that.

I'm interested in solutions, specifically to get the most out of Gnome
without being forced to make changes lower down my system's stack.  If
necessary, I'd at least like to have a logind that works distinct from
systemd, according to a well defined specification that can be created
separate to any one implementation (like the PMS provided for package
managers), and ask Gnome to work to that specification.  Until
systemd-205, that was possible.  The fact that systemd has the power
to remove that ability in a single version bump, and did so without
thought for the impact on Gnome, should be worrying to Gnome for the
future, not just to the users that were affected now.  The hope for a
clear specification that can't be changed or dictated by a single
implementation feels like a fair compromise, but unless I know where
to suggest that, or where it has already been suggested, it won't help
in the slightest.

 And at the end of the day, all that code is 100% Free Software,
 with public repositories with all the history of the components of
 the project for all the world to see and use.

I've already addressed how this doesn't help those who contribute to
open source software, but don't have the skills to manage such a large
and important project.

 The GNOME developers already made their decision. The GNOME 
 maintainers in Gentoo followed through (like they have been doing
 in almost every other distro). Now it's up to each user to decide
 if she keeps using GNOME (and therefore switches, if necessary, to
 systemd since 3.8), or if she stops using it.
 
 Arguing about it is quite useless.

Having read my emails, you'll have seen that I haven't been arguing,
I've been expressing a desire to collect together those who disagree
with the decision and communicate it such that the decision might get
discussed publicly.  I have yet to be pointed to the processes and
procedures whereby the decision to make systemd a hard dependency was
carried out.  In Gnome 2 there were specific meetings, well
documented, to discuss and decide the blessed dependencies, but
those and several other key decision-making meetings now appear to
happen outside of the public infrastructure.  This is to the point
where there were public emails saying systemd would not become a hard
dependency for gnome-3.8 and yet here we are.

The Gentoo Gnome herd tried their hardest to avoid the move to
systemd, and I have mentioned my appreciation for their efforts in my
previous emails.  I am currently exploring my options, as you
reiterated my point back to me, but one of those is to not give up
hope on the Gnome project or their developers and to try to
communicate with them.  However, having people assume I'm arguing
because I'm keen to get to the bottom of their decision making doesn't
help...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIG5ZQACgkQu7rWomwgFXrWVACeJakbnBmoJfYP91wOrC/EmG6W
EMAAn1yZItvdNyz6AuPhcnbk9MBxcYVb
=iOpy
-END PGP SIGNATURE-

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 09/08/13 10:35, Tom Wijsman wrote:
 Listening comes at a price; you can't listen to everyone at the
 same time, all you will hear is noise because all the voices clash.
 So, you've got to listen to a selective bit of users and satisfy
 them; after all you can't satisfy everyone. Resources are
 finite...

That's exactly why I'm trying to get all the frustrated voices on the
Gentoo-dev mailing list making one single concerted comment to the
developers, so that they only need to listen once, and can see from
the number how many people feel the same way...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIFcToACgkQu7rWomwgFXo0UgCfXYsL4VtS2HjWDxop5+E6mFJQ
6mQAnjM6fQqDSL6xGigE0AncqyqQjIhJ
=Enah
-END PGP SIGNATURE-

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/08/13 21:32, Tom Wijsman wrote:
 On Sat, 10 Aug 2013 03:11:55 +0800 Ben de Groot yng...@gentoo.org
 wrote:
 
 On 9 August 2013 21:57, Michał Górny mgo...@gentoo.org wrote:
 This one is *so special* just because we have a few folks
 which really have nothing useful to do and instead spit their
 systemd hatred on gentoo-dev@ and expect others to join their
 stupid vendetta.
 
 Please keep your insults off this list. You may want to deny
 them, but there are valid reasons why people oppose systemd. It
 doesn't help to keep so aggressively pushing it.
 
 Neither does it help to make statements like People are free to
 use a saner desktop environment... which add nothing to the
 discussion, which in fact can be seen as an insult as well; because
 sane basically stands for free from mental derangement or free
 from being unreasonably, unsound judgment or bad sense where both
 come close to what people will perceive as the negative form of
 stupid.

I'm not sure where you're quoting from, it doesn't appear to have been
the thread Ben was commenting on.

I'm glad someone stepped in and said something, Michael's comments
appeared overly aggressive, as they would have even if the word hatred
had read agenda.  I'm not sure why there were so many rebuttals of his
request to keep things civil.  It wasn't a statement for or against
systemd, it was a request to maintain a hospitable environment...

Mike
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIFe/gACgkQu7rWomwgFXr5sACeJkIl6rDKmyVdNmaQW9HupK35
s4MAn3EvU9agxaAOJI5Gf7uHUqcEJ7Mv
=x6Dm
-END PGP SIGNATURE-

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/08/13 11:38, Samuli Suominen wrote:
 i'm not volunteering but I never really got why our GNOME
 maintainers insisted on staying with it instead of going with the
 distribution after it was clear logind is a dead end on non-systemd
 systemd

Ok,

So there's lots of people that don't want systemd.  Can't we group
together and have some kind of an affect on upstream?  Upstream
appears to be suffering the same split we found with portage, in that
the specification that people are working to is in fact the only
implementation (as least, that's how I read the fact that a separate
logind which follows the specification will no longer work without
systemd explicitly?).  We now have paludis, pkgcore and the PMS.  Is
there some way, we as the Gentoo Foundation, Developers or even just
Users can form a petition, or an open letter, that might make enough
impact on the Gnome foundation for them to reconsider their position?

Perhaps if there were an init system specification project, separate
from systemd, that systemd had to adhere to rather than deciding to
change the rules at a random version (like 205), then Gnome could
potentially have other options than just systemd?

Does anyone know how Gnome is dealing with being run under non-linux
systems given the new systemd hard dependency?  Is it simply not
shutting down, etc?  Can we introduce a similar build capability so
that people can have a non-full Gnome installation that still
includes most of the apps?

Either way, bickering amongst ourselves won't have any effect,
fighting against upstream's changes seems similarly futile (they have
no reason to improve the situation if we're happy to do the extra work
when things are bad), so the best chance we have is communicating with
upstream and asking them to reconsider.  That's not guaranteed to
work, but focusing our efforts on that, rather than lengthy arguments
about time-intensive Gentoo solutions seems like a better option...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIEAiAACgkQu7rWomwgFXpYUgCgk+XJynbo4MCRcFlqHrYtDgyV
U+UAnAnn6tnrYYx/3ptOU7EGJF0efCyu
=R4BF
-END PGP SIGNATURE-

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/08/13 22:06, Pacho Ramos wrote:
 Anyway, are you sure openRC is better than systemd for desktop
 systems (for deserving the effort to keep maintaining consolekit,
 that is currently orphan, cgroups stuff and any other things I am
 probably forgetting now) ? In that case, if you decide to try to
 suggest that to upstream, I would try to contact with Ubuntu/Debian
 guys, openBSD maintainer and Solaris one (Brian Cameron I think)

I'm not, systemd may be excellent for desktop systems, and for binary
systems that can build it once and have it work fine it may fit the
use case perfectly.  I do believe that openrc is a more reliable init
system (not least because, after having tried to swap to systemd, I
was presented with a kernel panic and no rescue shell, which realized
all my fears immediately).

Cgroups, and other new features may be excellent, but I'm not in so
much of a rush that I can't have things that need them started from a
small reliable init, rather than instead of it.

Thanks for your suggestions, I know the Gnome Gentoo guys and lxnay
have tried hard to maintain the option of not using systemd, and I
really appreciate all the hard work you guys put in.  I'm more
disappointed in Gnome itself for failing to be happy at being a great
Desktop Environment, and instead dictating the rest of my operating
system requirements for me...

Mike  5:\
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIENSQACgkQu7rWomwgFXr4zQCfejaFh0R2Dslx07E9zOeZT1mc
IKwAnRsZwH7CHDoxHbIhk32g7SNn3O+A
=kRAJ
-END PGP SIGNATURE-

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/08/13 00:19, Greg KH wrote:
 Become upstream developers and create fixes to remove the
 dependancy either by working on openrc features to emulate the same
 things that systemd has that GNOME requires, or split things out of
 GNOME so that it does not require systemd dependencies.
 
 But to complain to upstream without providing patches is a bit
 futile, don't you think?  That's not how open source projects work,
 we all know that.
 
 greg k-h
 

I would like to think that open source developers working on such a
large and integral project might listen to their users.  The way open
source is supposed to work is that people write something, and if it's
good people use it, and if it's not they don't.

I would very much like to have seen systemd succeed, but based on its
own merits, whereas it seems to have been accepted by being championed
at certain distributions, made indispensable to desktop environments
like Gnome, and by dropping the responsibility of developing udev in
favour of developing systemd.

I have heard the systemd developers say that no one has been forced to
use systemd, and that in the open source world, if I don't like
something I can write something different.  That's a wholly selfish
perspective, each and every person that contributes to open source
does so in their own way, and we're entirely dependent upon each other
to make the community and choices as vibrant as they are.  I could be
a KDE developer, or a Gentoo documenter, or work on mplayer.  All
those people are open source contributors and necessary ones, but that
doesn't mean that any of them necessarily has the skills or the time
to look after udev.  Does that invalidate their opinion on the choices
of upstream project they rely on?

There are certain key projects (like the kernel, glibc and udev) which
nearly every system has come to rely upon and, I believe, with that
reliance comes responsibility.  I wouldn't expect Linus to just one
day and walk away to go developing a new kernel he thought was better,
but he could.  If he did though, I would expect him to leave
infrastructure in place behind him to look after the project he made
which people all over the world now depend upon, and I'd continue
using that until his new kernel had proved its worth.  I certainly
wouldn't expect him to use his natural monopoly to force his new idea
on everyone!

I'm not trying to hinder advancement, the trying out of new ideas is
what open source is all about.  We've got source-based distributions
because someone wanted to see if it would work, it did and there's a
good community around it.  However, that hasn't come at the cost of
binary distributions, they both co-exist peacefully and people use
whichever one they want.

I don't have the skills to make a difference, so all I can do is vote
with my feet.  Even after sticking with Gnome 3 through its early
phases, I don't think I can continue using it at this point and I am
investigating alternatives, one of which is to try to remind the Gnome
developers, if not the systemd ones, of why UNIX succeeded even with
such a distributed development base; it was not because of enforced
uniformity...

Mike  5:\
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlIENyAACgkQu7rWomwgFXrv9wCdGHA4IhltnJBSt/2uY1XP6Xcs
QM4AoKS2V5AWgfD+EAeyE43Jm1hwRaVT
=DcNA
-END PGP SIGNATURE-

Re: [gentoo-dev] mercurial.eclass: change clone destination

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/11/10 02:40, Donnie Berkholz wrote:
 I read it more closely and realized I was a little confused by the way 
 you listed all the bullet points mixing together benefits and problems.
 
 So I'll try again: if you really want to do this change, you might want 
 to consider adding a mercurial-2.eclass instead. Eclasses of this nature 
 (svn, git, hg, etc) tend to be broadly used outside the tree as well as 
 within, so breaking backwards compatibility can be a real problem. A new 
 versioned eclass allows for a much more gradual transition.
 

I've only just jumped into the conversation, but the obvious question
is, why not just use ${S} as the location of the working directory
(rather than ${WORKDIR}/${workdir})?  That way, if it's set old
ebuilds still work, and if it's not set, new ebuilds get the benefit of
using ${S}?  I can only see a problem with this if there's somewhere
that the value of the working directory needs to be known before any of
the phases...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkzWloYACgkQu7rWomwgFXosEACgiFBLbFABweQR0JrZqprBxdkT
10UAoJVESt/2T3Y1AXkBXu7qYPY4NBf2
=ULZu
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It should be possible to still maintain this distinction, something like:

Version bump.  Added feature foo.
- --
Feature foo required a complete rewrite of src_install.

And then the ChangeLog generation can happen separately.  The problem
with this method is that if we later rely only on commit logs, users may
see things developers hadn't intended them to see.  So the question is,
will we always generate changelogs from the version control system, or
will we one day expect the user to directly read the commit logs?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkyWKWsACgkQu7rWomwgFXoBoACcCAeaYpUzquKEyp09NHk7nrrK
w9AAoKf8HtoAY68UMYSEwwvyqemV54M+
=iVC7
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23/08/10 18:26, Olivier Crête wrote:
 
 Other distributions are going one step further and are going for
 shell-free boot. We should follow that lead.
 

Why?  Presumably they're doing it by writing programs that do their own
parsing and executing, which means they'll need a maintainer just for
that program and they'll have to go through a few iterations to get the
initial bugs out, and then people will have to learn how to use the
different-yet-again language that goes with it.  Why not rely on a
prebuilt parser that devs already have to know to look after ebuilds?

I'm happy to accept that there might be some very good reasons
(respawning a shell for each script is time consuming/expensive?), but
without describing what those reasons are, it's not a direction we
should just be following blindly...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkxyuXMACgkQu7rWomwgFXrqSwCgjANV5zpo/uYrML+q1mCXHVgI
ghcAn2oRJMUl4V+L4UHhEABYUs58e9c5
=jen/
-END PGP SIGNATURE-

Re: [gentoo-dev] app-editors/vim-7.3 and python[3] USE flags

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'd thought that the new eclass was designed to ensure that if you asked
for USE=python it was built for as many different python ABIs as was
installed on your system (so python2 and python3 if they're both
installed).  I believe it's possible to ask the eclass which ABIs are
installed, and ask for the either in-use or highest versions of those.

If they're not mutually exclusive, and if vim won't break if they go
away, then why should the user choose which ones to enable and disable?
 Why not just get them to say whether they want python support or not,
and try to accomodate them for as many python versions as
installed/possible.

I realize there may be some controversy surrounding the new python
eclass, however that does seem to be how most python packages work these
days, so I'd say it's better to keep everything working the same way.

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkxuRQEACgkQu7rWomwgFXrpJQCgiMBnn9bWdbwtE4xcFsNmmKkV
IV0An3FC4w3eImueLxZ7bwC3tLkv8+YC
=uCL+
-END PGP SIGNATURE-

Re: [gentoo-dev] Over using preserve_old_lib, don't do that

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry I'm a bit late to the thread,

Just to add that empathy preserves libemapthy in this manner too.

On 05/07/10 17:40, Gilles Dartiguelongue wrote:
 
  1. How is it different than preserved-libs feature from
 portage-2.2 ? The issue that I have with you argument is that
 you encourage breaking user apps at build time instead of
 leaving the user some time to run revdep-rebuild or any other
 tool needed when user wishes so.

This is different from preserve-libs because FEATURES=-preserve-libs
doesn't stop these calls from keeping old libraries around.  Also, once
preserve-libs has been used, a normal revdev-rebuild won't spot these
issues, and cruft-checkers can't find them because they're classed as
part of the new package.

I understand we have users who want this feature, and also that we
advise everybody to read through every single elog message ever made.
Having said that, I personally know how to run revdep-rebuild, and I do
it often so that when I'm upgrading 100+ packages in one go, I don't
then have to sit around reading through every elog message to make sure
that a library I didn't ask for doesn't accidentally get left on my
system for all time.

I can live with this for in places where it causes massive breakage
(openssl/libpng/libjpg), because it's genuinely useful, but I think it
should be restricted to such important packages, or at least disabled by
FEATURES=-preserve-libs.

Ideally, these calls should either adhere to FEATURES=-preserve-libs,
or there should be a tool that can identify which files portage has
preserved, and allow easy rebuilding of dependent packages, and removal.
 At the moment, I'm having to manually grep ebuilds, ls the libraries
and run revdep-rebuild over them one at a time...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEARECAAYFAkw+y6oACgkQu7rWomwgFXoehQCgsrbUBRorY6J4rBmASh16t1eP
YzoAnAhAi7kWd/bI9xhUh8UHMFfCR5xY
=OOj9
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Over using preserve_old_lib, don't do that

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/07/10 14:57, Maciej Mrozowski wrote:
 And what about using portage 2.2 and be done with it. I don't see the point 
 in 
 reinventing the wheel yet again.

I'm using portage-2.2 and have been since it first came out.  I find the
@set notation invaluable.  I didn't like the preserve-libs feature
however, so I set FEATURES=-preserve-libs.  Unfortunately the eutils
function only checks for the presence of preserve-libs to drop out and
let portage handle it, not the absence of it.  So there's no way to get
that function *not* to leave these extraneous files around, even with 2.2.

As I said, that's fine, and I'm happy with that for extreme situations
(toolchain breaking or libpng/jpg size changes), but I'm not for most of
the other packages.

If portage offers a way to turn off functionality (like preserving
libraries), it should actually turn it off, rather than sometimes turn
it off...

 Imho, revdep-rebuild and all 'misc' tools requiring users' good will like 
 python-updater should be obsolete and phased out in favour of package manager 
 controlled mechanisms.

You're just moving around the good will, but it's still required.
Instead of typing revdep-rebuild preserved-libs, you have to type
emerge @preserved-libs, but neither of those solutions is automatic.

Also, if you feel that way, why not request that preserve-libs be made
mandatory in portage-2.2?  If the changes are big enough, and
not-well-tested enough that they warrant making the feature optional,
then why not ensure that the simpler fallback tools to correct problems
(like revdep-rebuild) can still do the job...

Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEARECAAYFAkw/GgcACgkQu7rWomwgFXrY5QCeJha63SB9lpl1lLhgq9CqePj8
QsQAniLZpr0RymqtQlXAJVdoCa9eEEjW
=5a5g
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: New global USE flag: introspection

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/06/10 15:33, Arun Raghavan wrote:
 Why not just gintrospection?
 
 I still think introspection is easier to grok. It's unlikely that
 it's going to be used in a completely different sense by other
 packages in the future, so let's stick with introspection please.

Gintrospection gives more information (things starting with g are
generally gnome related, which this is), and grepping for introspection
will still turn it up.  It also solves the concerns that all the people
on this thread have voiced about introspection being too generic.  I
can't see why introspection is that much easier for people to grok?
Gintrospection seems like a good compromise that everyone can agree on...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEARECAAYFAkwg5d0ACgkQu7rWomwgFXqr+QCggMCbz0F9Jm/WxK080ZcVLLWV
+bcAnj4A72j+T9iLmbyW+0uFDCyYg23o
=vbNg
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: New global USE flag: introspection

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/06/10 18:11, Arun Raghavan wrote:
 It is not a GNOME-only flag.

A general introspection flag may not be, but this isn't a general
introspection flag, this is specific to gobject and the suggestions try
to clarify that.  People who want gobject-introspection (which concerns
gobject, and is therefore appropriate for a g prefix) will not want to
have to manually differentiate between arbitrary-library-introspection
and gobject-introspection by fiddling around with a package.use file to
individually turn it on and off.  It should be an easy, global USE flag
to enable once in make.conf and forget about.

 Which should not be an issue since any library that has some sort of
 introspection can use this flag (and the use.desc can be changed
 appropriately at that time if it does not use gobject-introspection).

Why have to change it in the future (and probably split it into two
flags then), when the choice hasn't been made yet?  Or, to put your own
question to you, why are you vehemently for introspection when others
have shown concern with the choice?  As far as I can see, the only
difference is requiring a slightly longer use_enable line.

In the end, it's not a big issue and whichever is chosen it'll work out.
 I'm just trying to figure out why the compromise solutions aren't good
enough to satisfy everyone?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEARECAAYFAkwhGkAACgkQu7rWomwgFXp0dQCePjaHQn6JeBO6OrzwsIHBp8f1
+2gAoJDD4MS1spuo1DiqD96uOfX8ZBj9
=TJvC
-END PGP SIGNATURE-

Re: [gentoo-dev] sudo vs su

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hiya William,
Sudo can be used to restrict access, so that only certain programs can
be run using it.  It asks for your password rather than the user you're
trying to login to (unlike su).  It also helps maintain a more accurate
audit trail (although I don't have details on exactly how it does that).
 Also su I believe only allows access to people in the wheel group.
Therefore, you'll see people using them in conjunction (particularly
with systems like ubuntu that don't give you a root user), so that a
user can enter their own password and be restricted to a particular
program in this case su, and keep better audit logs all thanks to sudo.
 Whilst at the same time it still gives you complete access to the
system/login shell through su (a simpler and therefore presumably easier
to secure program).  So they can achieve the same results, but it is the
differences in the programs and the way they work that makes people
choose one over the other (or try and combine their best qualities).
That's the best of my understanding, hope it helps?
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAkuKyisACgkQu7rWomwgFXp6KQCfRGn4b10R8onUVIXlaMgGJ/1o
gpQAn1wiKNrFzlHZLKozCgaJujSUkKH4
=55Bj
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Patrick Lauer wrote:
 At least I'm trying to keep these 
 packages alive, which noone else seems to do. 

If you spot that a new version is available, you're more than welcome to
post a version bump bug assigned to the appropriate herd and developer
(forensics and me, in this instance).

I don't necessarily have time to stayed glued to exactly when new
versions of a package come out, but that doesn't mean I'm not willing to
spend the time to keep it up to date once I'm aware a new version's come
out.  If nobody tells me, it'll have to wait until I spot it myself.

Foremost has a single bug open against it, which is a stabilization bug,
that means it still compiles, and works, or that no one's bothered to
complain about it.  So I'd class the package as far from dead.

Please don't claim no one else wants to keep the package alive, when you
don't afford them the opportunity to demonstrate that they do.  If you
take responsibility for bumping a package from the appropriate
maintainer, you can't then turn around and claim you're allowed to cut
corners because no one was maintaining it.  It's quite rude to the
people who are willing to look after it...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.13 (GNU/Linux)

iEYEARECAAYFAkr25AYACgkQu7rWomwgFXrIxQCgnVdigpUJZnaW28HcJ2U8qQZy
b9IAoJc2Afv0UfrrYu7xe7EdP1DCP2Ze
=m8Os
-END PGP SIGNATURE-

Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ok,

Here's the list of ebuilds that feature a CONFIG_CHECK, and which ones
I've been through to check for either NONEED (already using ~option),
MODULE (builds a module so may really want to bomb out), and FIXED
(packages which I've fixed).

About half the list is done, I'm posting it here as a progress/grab 'em
if you want to do 'em type list (as requested by robbat2).

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqcUhoACgkQu7rWomwgFXp3GwCfddJEgoKsDgaGTLzkouavCdVp
srQAoLUMEEwmobCBwWAHasrwJjjSt9k5
=iMAd
-END PGP SIGNATURE-
FIXED   app-admin/longrun/longrun-0.9-r3.ebuild:CONFIG_CHECK=X86_MSR X86_CPUID
FIXED   app-cdr/nero/nero-3.5.2.3.ebuild:CONFIG_CHECK=CHR_DEV_SG
FIXED   app-cdr/nero/nero-3.5.3.1.ebuild:CONFIG_CHECK=CHR_DEV_SG
FIXED   app-crypt/truecrypt/truecrypt-6.2.ebuild:   local 
CONFIG_CHECK=BLK_DEV_DM DM_CRYPT FUSE_FS CRYPTO
FIXED   app-crypt/truecrypt/truecrypt-6.2a.ebuild:  local 
CONFIG_CHECK=BLK_DEV_DM DM_CRYPT FUSE_FS CRYPTO
MODULE  app-emulation/vmware-modules/vmware-modules-1.0.0.15-r2.ebuild: 
CONFIG_CHECK=
MODULE  app-emulation/vmware-modules/vmware-modules-1.0.0.15-r2.ebuild: 
CONFIG_CHECK=UNUSED_SYMBOLS
MODULE  app-laptop/acer_acpi/acer_acpi-0.10.ebuild:CONFIG_CHECK=LEDS_CLASS 
BACKLIGHT_LCD_SUPPORT
MODULE  app-laptop/acer_acpi/acer_acpi-0.11.2.ebuild:CONFIG_CHECK=LEDS_CLASS 
BACKLIGHT_LCD_SUPPORT
MODULE  app-laptop/acer_acpi/acer_acpi-0.8.2.ebuild:CONFIG_CHECK=LEDS_CLASS
MODULE  app-laptop/acpi4asus/acpi4asus-0.41.ebuild: 
CONFIG_CHECK=LEDS_CLASS
MODULE  app-laptop/acpi4asus/acpi4asus-0.41.ebuild: 
CONFIG_CHECK=~ASUS_LAPTOP
DONEapp-laptop/hdapsd/hdapsd-20060409-r1.ebuild:CONFIG_CHECK=SENSORS_HDAPS
DONEapp-laptop/hdapsd/hdapsd-20060409-r3.ebuild:
CONFIG_CHECK=SENSORS_HDAPS
DONEapp-laptop/hdapsd/hdapsd-20060409.ebuild:CONFIG_CHECK=SENSORS_HDAPS
MODULE  
app-laptop/lenovo-sl-laptop/lenovo-sl-laptop-.ebuild:CONFIG_CHECK=HWMON 
BACKLIGHT_CLASS_DEVICE
MODULE  app-laptop/tp_smapi/tp_smapi-0.37.ebuild:   
CONFIG_CHECK=!SENSORS_HDAPS
MODULE  app-laptop/tp_smapi/tp_smapi-0.39.ebuild:   
CONFIG_CHECK=!SENSORS_HDAPS
MODULE  app-laptop/tp_smapi/tp_smapi-0.40.ebuild:   
CONFIG_CHECK=~INPUT_UINPUT
MODULE  app-laptop/tp_smapi/tp_smapi-0.40.ebuild:   
CONFIG_CHECK=!SENSORS_HDAPS
NONEED  app-laptop/tpb/tpb-0.6.4.ebuild:CONFIG_CHECK=~NVRAM
NONEED  app-misc/actkbd/actkbd-0.2.8.ebuild:CONFIG_CHECK=~INPUT_EVDEV
NONEED  app-misc/dnetc/dnetc-2.9013.498.ebuild: local CONFIG_CHECK=~SYSVIPC
NONEED  app-misc/dnetc/dnetc-2.9015.504.ebuild: local CONFIG_CHECK=~SYSVIPC
MODULE  
app-misc/sdricoh_cs/sdricoh_cs-0.1.3_p20080521.ebuild:CONFIG_CHECK=MMC_BLOCK
MODULE  
app-misc/sdricoh_cs/sdricoh_cs-0.1.3_p20080525.ebuild:CONFIG_CHECK=MMC_BLOCK
FIXED   
app-mobilephone/gnokii/gnokii-0.6.27-r2.ebuild:CONFIG_CHECK=UNIX98_PTYS 
(STABLE)
FIXED   
app-mobilephone/gnokii/gnokii-0.6.27-r4.ebuild:CONFIG_CHECK=UNIX98_PTYS
FIXED   app-mobilephone/gnokii/gnokii-.ebuild:CONFIG_CHECK=UNIX98_PTYS
MODULE  
dev-embedded/parapin-driver/parapin-driver-1.0.0.ebuild:CONFIG_CHECK=PARPORT
FIXED   dev-java/jusb/jusb-0.4.4-r1.ebuild:CONFIG_CHECK=USB_DEVICEFS
MODULE  dev-util/sysprof/sysprof-1.0.12-r1.ebuild:  CONFIG_CHECK=PROFILING
MODULE  dev-util/sysprof/sysprof-1.0.12.ebuild: CONFIG_CHECK=PROFILING
NONEED  dev-util/systemtap/systemtap-0.7.ebuild:CONFIG_CHECK=~KPROBES ~RELAY 
~DEBUG_FS
NONEED  dev-util/systemtap/systemtap-0.8.ebuild:CONFIG_CHECK=~KPROBES ~RELAY 
~DEBUG_FS
NONEED  dev-util/systemtap/systemtap-0.9.5.ebuild:CONFIG_CHECK=~KPROBES ~RELAY 
~DEBUG_FS
NONEED  dev-util/systemtap/systemtap-0.9.7.ebuild:CONFIG_CHECK=~KPROBES ~RELAY 
~DEBUG_FS
NONEED  dev-util/systemtap/systemtap-0.9.8.ebuild:CONFIG_CHECK=~KPROBES ~RELAY 
~DEBUG_FS
NONEED  dev-util/systemtap/systemtap-0.9.9.ebuild:CONFIG_CHECK=~KPROBES ~RELAY 
~DEBUG_FS
NONEED  gnome-base/gnome-menus/gnome-menus-2.20.3.ebuild:   
CONFIG_CHECK=~INOTIFY
MODULE  media-sound/alsa-driver/alsa-driver-1.0.20-r1.ebuild:   local 
CONFIG_CHECK=!SND SOUND ${CHECK_PNP} ${CHECK_ISA} ${CHECK_FW} ${CHECK_PARPORT}
MODULE  media-sound/alsa-driver/alsa-driver-.ebuild:local 
CONFIG_CHECK=!SND SOUND ${CHECK_PNP} ${CHECK_ISA} ${CHECK_FW}
MODULE  media-sound/line6usb/line6usb-0.7.3.ebuild:CONFIG_CHECK=USB SOUND
MODULE  media-sound/line6usb/line6usb-0.8.1.ebuild:CONFIG_CHECK=USB SOUND
MODULE  media-sound/xfi-drivers/xfi-drivers-1.00.ebuild:CONFIG_CHECK=SND SOUND
MODULE  media-tv/ivtv/ivtv-1.0.1.ebuild:CONFIG_CHECK=EXPERIMENTAL KMOD 
HAS_IOMEM FW_LOADER I2C I2C_ALGOBIT
MODULE  media-tv/ivtv/ivtv-1.0.1.ebuild:
CONFIG_CHECK=${CONFIG_CHECK} FB FB_TRIDENT FRAMEBUFFER_CONSOLE FONTS
MODULE  media-tv/ivtv/ivtv-1.0.2.ebuild:CONFIG_CHECK=EXPERIMENTAL KMOD 
HAS_IOMEM FW_LOADER I2C I2C_ALGOBIT
MODULE  media-tv/ivtv/ivtv-1.0.2.ebuild:

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

William Hubbs wrote:
  I agree here.  The eclass should check /proc/config.gz.
  Also, another reason to use the eclass is it respects KBUILD_OUTPUT if
  it is set.

- From the indenting I can't tell if you wrote this or not, however, we
need to differentiate between running and build time environments.
Ebuilding is a build-time process.  That means the running kernel isn't
 important, since we're not running udev, we're just building it.  When
the machine is next rebooted, we could be using a completely different
kernel (or even one that hasn't been installed yet).  We should only
care about the build-time kernel when we're building, which the user has
to specify (which they do implicitly by using /usr/src/linux, or
explicitly by using KBUILD_OUTPUT or another environment variable).

If you go by the running kernel, then you're requiring people to reboot
their computers before they can build software for a kernel they're
about to run.  That simply ensures downtime on a potentially critical
service, and moreover it's an unnecessary constraint.  The existing udev
can continue running until the machine is rebooted without a problem.
When the machine restarts *any* kernel could be chosen, and build time
checks won't help prevent a bad kernel from being booted.  That's why
the linux-info.eclass does the checks it currently does, and *doesn't*
check /proc/config.gz and *doesn't* check /$(uname -r)/ directories...

So in summary:

* Check the running kernel if you're about to run.
* Check the kernel the user's chosen to build against if you're about to
build, using linux-info.

If the ebuild restarts the service (causing a reread off disk, rather
than just a reread of the rules) then fine, use the check to disable the
restart, and/or warn the user, but don't stop the user from building the
software.

You can also put a check in the init.d, but it just creates the
possibility that the check is wrong when udev could potentially still
run.  I'd simply try running udev and check if it exits or errors as
expected.  Only if it doesn't exit or error when it should would I add
checks to the initscript, and even then I'd suggest fixing the code to
error correctly, over adding our own checks in...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqapk4ACgkQu7rWomwgFXqDbACgtYdXtmlgo6JA49o9on111XPE
Y/QAnROtzEhAUg0ML9J+nd6rTvKfZeFz
=pbOj
-END PGP SIGNATURE-

Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin H. Johnson wrote:
 It does NOT check /proc/config.gz presently. The original logic against
 not checking /proc was that we were targeting the kernel being built,
 but that's moot given the use of `uname -r` in OUTPUT_DIR.

I might be reading the eclass wrong, but it looks as though OUTPUT_DIR
is only set to use uname -r if the KV_* variables match the output of
uname -r:

[ ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA} == $(uname -r) ]  \
OUTPUT_DIR=${OUTPUT_DIR:-/lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build}

Otherwise it's taken from the KBUILD_DIR and then it even checks inside
the KV_DIR's Makefile to find one.  So not checking /proc/config.gz
isn't a moot point anymore, which is not to say it's not a good idea,
but the reason against doing it still stands.  To deal with running
kernel's, there's a get_running_version function, that will use uname to
fill out the KV_* variables appropriately.

 Proposed solution:
 --
 We need to be able to reduce user error, so we cannot simply make it
 trust the user by default. So I propose that we add an environment
 variable (I'm not set on the name yet), eg:
 EXTERNALLY_BUILT_KERNEL=1
 
 This option will cause linux-info.eclass to consider ALL kernel option
 checks non-fatal. That way we still get the warnings and logs, but it
 does not stop the builds.

I'm not sure what this is solving?  It doesn't seem to reduce user
error, it just allows users a way to override portage errors?  It seems
unrelated to config.gz and the discussion going on in the previous
thread.  I do like the idea of being able to override portage when it's
stopping us from building (incorrectly), but surely with the capability
to have non-fatal checks, we can try to minimize the times when
portage/the ebuild is wrong using that, instead of a whole new override?

 When is the above NOT enough?
 -
 The only time that ANY kernel sources are required is when you are
 building an out-of-tree module. For this purpose, they must be
 configured.

There's a lot of ebuilds that use linux-info, and they can't all be
out-of-tree modules.  Are they misusing linux-info, or are you saying
there's a specific instance in which linux-info requires configured
kernel sources?

 The check for having configured kernel sources must only be executed
 when the modules are about to be compiled. Putting it in pkg_preinst
 would block use of binpkgs on (related) machines.
 
 - If a package builds modules AND userspace, we should offer a way to
   build the userspace only, as the user can build their modules
   externally (or patch them into the kernel) [1]
 - For packages that ONLY build modules, and no userspace at all, having
   EXTERNALLY_BUILT_KERNEL=1 means that they should error out? [2]
   (this case might be thrown into the above one).

That all seems fine, but again these just seem like standard guidelines.
 Is there not already some how to write kernel module ebuilds page
somewhere that documents how you're supposed to use linux-info?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqa30QACgkQu7rWomwgFXo99gCfd8NbK9QkxtJ9BKalq/n1iBxn
l0QAoLiBsvKXZRzR4Dp8HEtoxrsONCtc
=ZK9i
-END PGP SIGNATURE-

Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin H. Johnson wrote:
 FYI:
 get_running_version is used in one single ebuild, in the entire tree:
 sys-fs/evms/evms-2.5.5-r10.ebuild
 And there it's only for a warning.

Ok, I was just suggesting that if there was an intention to implement
config.gz checks, they should only apply when people ask about the
running version rather than the build version.  Since that doesn't seem
popular or even necessary, perhaps neither is the need to check config.gz?

 The great majority of CONFIG_CHECK usage in the tree is fatal already.
 It only actually needs to be fatal only when it's being used to build a
 module.

Ok, I see what you're suggesting now.  When people want to build
packages, but portage knows their kernel isn't setup to run them
properly, then it should still build them, but warn them strongly about
it (as opposed to currently, where it'll just die).

 This leaves us between hand-holding the basic user's kernel configuration
 (exiting if the kernel config option is not enabled), and changing all
 non-module instances in the tree to be non-fatal.

Ok, so then the question is do we sacrifice correctness for fewer
(invalid) bugs?  Seems like a judgement call.  For what it's worth, I'm
not sure adding extra plumbing to allow smart users to bypass the checks
is the right middle ground.  I'd either leave it as is, or change the
ebuilds to accurately reflect whether the userspace will build or not.

 That all seems fine, but again these just seem like standard guidelines.
  Is there not already some how to write kernel module ebuilds page
 somewhere that documents how you're supposed to use linux-info?
 If you're building modules, most of the time you're using linux-mod, not just
 linux-info. There's no document or recommended behavior in the tree for the
 above actually, and I'd like to introduce one.

Sounds like a good idea, it might also be worth adding to the quizes, if
existing devs are asking how it should be done?  I guess that's a call
on how common it is to have kernel config requirements on userspace...

Still, I think I'm on the right page, and even in agreement (which makes
me happy).  5:)  Thanks!

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqa9gkACgkQu7rWomwgFXq1PwCfTbp8hqsGZjDmsxKE21gKe1Y8
lYYAoI2EBCn5KwQdlm6Xd8u0q7KGl7gI
=Jrsa
-END PGP SIGNATURE-

Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin H. Johnson wrote:
 The existing state is:
 - Force the user to install sources
 
 Our choices are:
 - `uname -r` output.
 - Create an override environment variable for all the checks.
 
 /proc/config.gz comes back here again, in that, we can use it as a
 middle ground with `uname -r`, rather than having the environment
 variable.

Ok, that seems a very reasonable use.

 So from our discussion, I propose the following:
 Finding the kernel version:
 ---
 0. (optional) give an env var to bypass entirely.
 1. Use existing logic of /usr/src/linux, KERNEL_DIR et al.
 2. Fall back to using the running version, with a warning.
 
 Checking a configuration option, for non-module use:
 
 0. (optional) give an env var to make all checks non-fatal.
 1. Use existing logic of .config from /usr/src/linux, KERNEL_DIR et al.
 2. Fall back to /proc/config.gz if available.

Where 2 also issues a warning, presumably?  I've had a think and can't
see any repercussions in changing the default behaviour, but I'm
assuming people would only generally hit 2 with virtual machines and/or
hardened servers.  Can you see either of these suffering from defaulting
to the running kernel?  Do you know of many circumstances where 2 might
get hit by normal users other than those situations?

Also (and potentially off-topic), if we're using linux-info to detect
kernel sources, whether installed or not, should we also check the tree
for ebuilds that require a package which PROVIDES=sources?  I
personally use a single git checkout, since I think (possibly
mistakenly, I honestly haven't checked) that it will leave different
checkouts of the kernel all over my /usr/src directory, whenever a new
version's emerged.  I've had to create a fake-sources package to trick
ebuilds that need *some* sources installed, and I'm wondering if that
should be necessary?

 Two different cases here:
 1. Portage knows their kernel is not setup correctly.
 2. Portage cannot find out enough info.
 
 It's #2 that bites on virtual machines and hardened servers, and is what
 I'd like to fix.

Ok, I'm all for it, and the solution you've suggested sounds fine.

 It's a one-liner to give an override making all checks non-fatal, with
 the downside that it can't differentiate why the checks are being made.
 So yes, in the case we should simply fix all of the ebuilds (after the
 kernel source check is fixed as well).

I'd definitely try and do things the right way, and a global override
(whilst easy) doesn't sound like it.  Fixing all the ebuilds (and the
kernel source check) sounds like the way to go.

 So I propose this as resolutions from the above:
 1. USE=modules added to the base profile.
 2. Every package that builds kernel modules must offer USE=modules, 
which can be used to disable building the kernel modules, leaving a
pure userspace build of that package.

 Most of the changes to the above can be done in the linux-mod eclass, so
 I don't think we'll have to touch that many packages directly.


Yep, although if the changes are in linux-mod, then those packages that
*only* provide kernel modules will need a way to not present that use
flag (no point installing a package is USE=-modules and nothing gets
installed).  Also, I'd assume +modules would be added as a default.

The whole plan sounds extremely sensible in general!  5:)

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqbC3oACgkQu7rWomwgFXpwywCeKzcB0Znzuul3wq9U9ew5+SuX
scQAnjShkQTVQQrFABb8u2t0RsP9K34z
=LFlY
-END PGP SIGNATURE-

Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin H. Johnson wrote:
 Yes, a warning with using /proc/config.gz.
 
 I missed a bit for the config option.
 If there is NO source of the config data, what do we do?
 Error out or more warnings?

Well, if we can't determine whether a config option's set or not, if
it's not critical (ie, it's ~CHECK), then we warn.  If there's any hard
checks, then we error out I suppose.

 This is what I use for my home workstation:
 /etc/portage/profile/virtuals:virtual/linux-sources sys-kernel/git-sources
 /etc/portage/profile/virtuals:virtual/alsa sys-kernel/git-sources
 /etc/portage/profile/package.provided:sys-kernel/git-sources-2.6.30
 
 Saves having any fake package like that.

Ah cunning, I'll have to try that...

 Want to lend a hand fixing up the ebuilds then? I'll work on the eclass 
 sources
 check.

Sure, as long as I sure I know how we're fixing them, I'd be glad to
help.  5:)  I'd just be fixing the userspace ones to make sure they're
~CHECK or would I be doing something else as well?  Also should I do
that via bugs and a week's grace period, or would you recommend I just
dive right in?

 There IS still a point of having the entirely empty kernel package installed:
 - Split userspace/kernel packages where the userspace package has a dependency
   on the module-providing package. 
 - other packages that might have a dependency on the module-providing package.
 - /etc/modprobe.d/ files.
 
 USE=-modules will ONLY block files installed to /lib/modules/.

Ok, presumably USE=-modules will also stop the kernel checks, otherwise
the following could occur.  Let's say the foobar package builds external
modules and explicitly requires that foobar not be set in the kernel.
With USE=-modules, there's no internal version and there's no external
version, but the kernel package is installed, and the deps are happy,
even though they'll bug out when it's showtime.

Presumably there's also packages that aren't split, or depended on,
where not installing the modules is never a good idea.  Is there still a
way to disable the USE flag, or will it be a requirement of the
linux-mod package?

 I'm not sure we can get away with USE-defaults for this change, due to the
 amount of EAPI=0 stuff that will be changing, so it'll be in
 profiles/base/make.defaults instead.

That's fine, just so long as it's on and not off, I don't mind what
system we use to do it.  5:)

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqbEqkACgkQu7rWomwgFXq53QCdFi8YlDrKwkh9b0g6EX2DBI35
0t0AnRRRV+oxqQaKPqzcWxGJDtW2lszQ
=oia+
-END PGP SIGNATURE-

Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin H. Johnson wrote:
 If you feel like reviewing ~140 packages and filing bugs for them, I
 won't stop you. But I'm just going to go and fix the ones that seem
 simple enough to me, and only file bugs for the complex ones.

Ok, I'll do what I can tomorrow.  I'm off to bed now...  5:)

 Err, I'm not following what you claim is the problem here?
 
 cat/foo-mod:
 inherit linux-mod
 CONFIG_CHECK=!option

 ...
 
 The user sets USE=-modules because they have built cat/foo-mod on their
 own, into the kernel. foo-mod installs nothing

Just checking that it will actually install nothing, rather than failing
out with an error because the kernel has option set.  I'm just
re-iterating that CONFIG_CHECK should only occur if USE=modules.  If
USE=-modules, then the CONFIG_CHECK options should probably be ignored
shouldn't they?

 It needs to be ALWAYS available. The ipset bug I linked earlier in the
 thread was an example of that. The userspace is useless without the
 kernel code, but there is nothing to stop the user patching it into
 their kernel and not having it as a module at all (as is the case on a
 couple of my work boxes, which is why the bug got filed).

Ok, fair enough.  However, in that instance, ipset is a userspace
dependency, I was talking about kernel modules that have no userspace
dependencies.  I suppose there could be a case where someone is trying
to custom build a userspace tool that isn't in portage yet, but I still
think it might cause confusion to allow USE=modules on kernel modules
(without any dependencies) that then install nothing.  I'm wondering
which will cause more bugs to be filed?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqbHEEACgkQu7rWomwgFXrEpQCeIMWofCtvwHKJoZsb3/qUyLcP
tTUAoIb3Sr645x6NY82LXK6i/3g75NF5
=uaOB
-END PGP SIGNATURE-

Re: [gentoo-dev] Standalone libstdc++

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Казанков Александр Владимирович wrote:
 Hello.

Hi,

Could you please file all this information (and the output from emerge
- --info at https://bugs.gentoo.org/.  This mailing list is for technical
discussions, whereas the bug tracker at https://bugs.gentoo.org/ is for
problems such as compilation issues or when things go wrong.

Thanks,

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkpFBX8ACgkQu7rWomwgFXpaeQCeNuRMyqZIjxMjFIT0nknMqjsz
hhgAnRzw7ID7FUP2XKAzCffd6Na10RSg
=LYVG
-END PGP SIGNATURE-

Re: [gentoo-dev] Adding Nipper license to the tree

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin H. Johnson wrote:
 The website stills says GPL v3:
 http://nipper.titania.co.uk/licensing.php

Yep, the website's going to be updated for version 1.0 (with the license
change).

 ...

I can't really comment on a lot of this, unfortunately.

 Similar to the TrueCrypt issue, I'd say do NOT commit any ebuild covered
 by this license until the matter is resolved.

Yeah, that's what I was afraid of...

 ... legal comments ...

Again, I'm afraid I can't really comment on these, but thank you for the
analysis, it was much appreciated to have a second pair of eyes look
this stuff over.

 Any patches or updates that the Licensee may develop for NIPPER must
 be immediately submitted to the Licensor. In addition, the Licensee
 will forthwith transfer without charge all current and future rights
 including copyrights and other intellectual property rights relating
 to such updates to the Licensor.
 Gentoo is NOT a licensee under any of the classes of use listed in the
 license. We don't use it, and we're not a commercial integrator. Ergo
 there is a loophole that allows us to patch it without losing our rights
 to the patches. HOWEVER, I'd be concerned that the context
 (non-modified) portions of the path are still bound by the original
 license, and would violate non-distribution.

I'm not keen on relying on loopholes.  If I did still want to try and
get a version of this into the tree, would packaging the binary RPM seem
a reasonable solution?  It's a shame given that the sources are
potentially available (primarily released for Gentoo) and no real
problem with making an ebuild, it's just the legalese...  5:(

So I'll leave the source version out of the tree, but I'd like thoughts
on using RPM as a solution?  Also I don't know whether an exception
could be made for Gentoo, but equally I don't know how to phrase one of
them either (Gentoo Foundation or all Gentoo developers), so I'm
hesitant to ask.  If anyone has any other ideas or possibilities, do let
me know.  Thanks...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAko24AoACgkQu7rWomwgFXqEKACgsibF2QEaIB8t+flrhA0wHMMp
Y0gAn3qesB0Li4DmRrquiXCEmUkDfbA6
=nvtn
-END PGP SIGNATURE-

[gentoo-dev] Adding Nipper license to the tree

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hiya guys,

One of the packages I maintain (nipper) has recently undergone a change
of license, from being GPLed to a new license that whilst mostly being
commercial features a non-commercial/personal use element.

Due to the new license (and the no redistribution of any kind bits) the
package will need mirror/fetch restrictions, which is fine.  My concern
is with the copyright clause which states:

Any patches or updates that the Licensee may develop for NIPPER must be
immediately submitted to the Licensor. In addition, the Licensee will
forthwith transfer without charge all current and future rights
including copyrights and other intellectual property rights relating to
such updates to the Licensor.

I'm wondering how this might affect any in-tree patching, because whilst
I'm aware of this clause and happy to send any patches upstream and/or
not patch at all, I can't say the same for every Gentoo dev that might
want to fix a problem.

I know the upstream author personally, and he's providing the
source-code primarily for Gentoo users (we can always use the existing
binary RPMs if patching is an issue), but I thought I should ask what
the best course of action would be here?

Thanks,

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAko1XWYACgkQu7rWomwgFXpWYACfaJO7c77PVD4kuEsPrLOG7Qsx
Sw0An1JswTwSB0Asa2BEUQZyS4OBGbeE
=rinb
-END PGP SIGNATURE-
  LICENCE AGREEMENT FOR NIPPER

This is a binding, legal agreement between you the end user (the Licensee) 
and 
Titania Limited (Company Number 06870498) whose registered office is at 46 
Cormorant 
Rise, Worcester, WR2 4BA, United Kingdom (the Licensor) for the use of the 
Nipper 
software products (NIPPER) and electronic documentation (including the Nipper 
SDK).

By installing, copying, downloading, accessing or otherwise using NIPPER you 
agree to 
be bound by the terms of this Agreement. If you do not agree to the terms of 
this 
agreement you may not download, install or use NIPPER.

1. Definitions

Computer shall mean a device that NIPPER is installed on/run from.

Device shall mean a device for which NIPPER is used to produce a report.

Commercial Use shall mean any use of Nipper for profit whether by or for the 
Licensee or for any person, organisation, government or government department. 
For 
the avoidance of doubt Commercial Use includes the use by the Licensee in the 
course 
of research funded by a commercial organisation.

Non-Commercial Use shall mean any use of NIPPER (by an individual) which is 
not 
for profit.

Subscription Fee shall mean the fee payable for a Commercial Use Licence.

Subscription Period is the period renewable every 1, 2 or 3 years (as defined 
by 
the subscription) from the date the Subscription Fee is paid for which the 
Licensee 
may use NIPPER on a specified number of individual Devices.

2. Licensed Software

2.1 This Licence relates to all versions of NIPPER developed by the Licensor. 
The 
Licensor reserves all rights.

3. Grant Of Licence

3.1 End User Commercial Use Licence

3.1.1 The Licensee may only use NIPPER after paying the Subscription Fee. The 
Subscription Fee shall be determined in accordance with the Licensor's (or the 
Licensor's reseller's) price list which shall be available from the Licensor 
(or 
the Licensor's reseller's) on request.

3.1.2 The Licensor grants the Licensee a non-exclusive, non-transferable 
licence 
to use NIPPER during the Subscription Period.

3.1.3 The Licensee may only use NIPPER for the number of licensed Devices 
during 
the Subscription Period. Any additional use will require the payment of an 
additional Subscription Fee.

3.1.4 The Licensee may only install NIPPER on Computers owned by the Licensee.
 The Licensee may install NIPPER on any number of Computers owned by the 
Licensee. 
An exclusion is made where the Licensee provides a managed service, then the 
Licensee may additionally install NIPPER on devices managed by the Licensee.

3.1.5 The Licensee may not sell or re-sell NIPPER or otherwise share, exploit 
or 
allow it to be transferred to any person for value or for Commercial Use.

3.1.6 The Licensee may not rent, lease, hire out or lend NIPPER.

3.2 System Integrator Commercial Use Licence

3.2.1 The Licensee may only use NIPPER after paying the Subscription Fee. The 
Subscription Fee shall be determined in accordance with the Licensor's (or the 
Licensor's reseller's) price list which shall be available from the Licensor 
(or 
the Licensor's reseller's) on request.

3.2.2 The Licensor licenses NIPPER for use in commercial products developed by 
the Licensee where NIPPER comprises not more than 50% of the product's 
functionality (the Licensed Product).

3.2.3 The Licensor grants the Licensee the right to integrate NIPPER using only 
the NIPPER API, library and executables developed by the Licensor.

3.2.4 The Licensor grants the Licensee a 

[gentoo-dev] The VMware packages are in need of a maintainer

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Everybody,

Last week I stepped down from the vmware herd, and since I was the only
member left, there are no more maintainers for the vmware packages in
the tree.  The current packages are vmware-workstation, vmware-server,
vmware-player, vmware-modules, and open-vm-tools; and there are two more
that should probably be masked and removed (vmware-dsp and
vmware-gsx-console).

All emails being delivered to vmw...@g.o and all bugs assigned to the
vmware herd are going unread.  The software is effectively in the
maintainer-needed group, just with its own email address.

As such, for vmware to continue to be supported under Gentoo we need
some developers or new recruits to look after the packages.  If you want
to help look after these packages, please contact me (off-list) and I'll
be happy to start training you in how the ebuilds/eclasses work and give
you guidance about how vmware packages their software.

If you're not a Gentoo developer yet, but are interested in becoming one
to look after the vmware packages, do also feel free to contact me and
we can look at getting you recruited.  The sort of information you'll
need to become a Gentoo developer is available at [1], [2] and [3].

The kinds of challenges you'll be dealing with are mostly kernel
related, ensuring that the modules are working with various gentoo
supported kernels, etc.  The current vmware installer is written in
python, whilst previously a perl script was used, so knowledge of both
of these languages would be advantageous.

If you've got any other questions or comments, again feel free to
contact me.

Mike  5:)

[1] http://www.gentoo.org/doc/en/index.xml?catid=gentoodev
[2] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml
[3] http://devmanual.gentoo.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoYajUACgkQu7rWomwgFXo9lACdEnYCocadAGfMKKeXZFK7Rqni
XK8An2P5Akzf4WzIVyIrlxPYXMSaEK3p
=KmWx
-END PGP SIGNATURE-

Re: [gentoo-dev] Baselayout 2 stabilisation todo

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Roy Marples wrote:
 Attached is the new conf.d/net sample.

Sorry, I missed those.  Did lists.g.o remove them, or were they not
attached?

 As such, a side project I've started is a new ifconfig tool
 [1] to handle everything from vlans, to bridging, to bonding, to
 wireless (up to WEP) with a similar syntax to the BSD ifconfig.

Also [1]'s missing, and I couldn't find it at http://roy.marples.name/.
 Where should I be looking?

 This decision is heavily influenced by NetBSD (disclaimer - I'm now a
 NetBSD dev).

Congrats on becoming a NetBSD dev!  5:)

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoYdCoACgkQu7rWomwgFXq5NwCfdI7nIk7Am0goWcbip9eCWBE/
iHgAnjHS2V/HpvngD9EUmnBa3ZNCUk4D
=aiQu
-END PGP SIGNATURE-

Re: [gentoo-dev] Baselayout 2 stabilisation todo

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christian Faulhammer wrote:
 What else?  As some of you might foresee, this can be as hard as a
 major GCC stabilisation, so it must be well-planned and organised.

Depends on which version of openrc gets stabilized in the process.
We're currently working out some issues with 4.3.2-r2 in bug 270646 [1].

Mike  5:)


[1] http://bugs.gentoo.org/270646
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoWfUgACgkQu7rWomwgFXpuVwCeLJRmQ4fparXM+fGzX4Ufr6Yj
kkMAn1JzD8yGhiUUrEHaEJrDA0ZR8o75
=+r5R
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Baselayout 2 stabilisation todo

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Duncan wrote:
 Or should I file the bugs?  It seems no one else has and maybe the 
 maintainers don't have the config for what they're maintaining, or 
 otherwise don't see the warnings.

I'm aware of the dm-crypt issue and will try and spend some time this
weekend getting that into shape.  If you do file bugs, please make them
block bug 251730 [1], which is the deprecated warning tracker.  Thanks...

Mike  5:)

[1] http://bugs.gentoo.org/251730
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoWoI8ACgkQu7rWomwgFXo0UgCeKTtnrZAR0y8rIdNSDOJRje1w
F5MAoKr1jJIM/JtBJL+ibxmzkFIV96lB
=AyNP
-END PGP SIGNATURE-

Re: [gentoo-dev] Git eclass update

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tomáš Chvátal wrote:
 I am throwing in full new eclass [1] and its diff [2].

Errr, maybe it's my eyes, but it looks as though the new eclass isn't
the same as the existing eclass with the diff applied (for instance,
git_src_prepare doesn't get called in the diff, but does in the new eclass).

Also, base_src_prepare doesn't get exported if EAPI != 2, so I'm not
sure what happens when it gets called from git_src_prepare (which can be
called when EAPI = 0|1).  Has anyone actually tried this on a non-EAPI2
ebuild?

Lastly (and this happened in the old eclass, but I figured since it was
getting an update now would be a good time to fix it), because checking
out uses --depth 1, it's possible for a checkout to fail (specifically
if EGIT_BRANCH/EGIT_TREE is set on first checkout) since the required
commitish may not exist in the shallow copy.  The error messages thrown
out are along the lines of not a tar file, but I believe the ebuild
continues, until it doesn't find the unpacked source.  The possible
fixes would be to:

a) ask git to clone at a specific commitish (although I can see how to
do that in git clone --help)

b) see if there's a specific commit set, and then clone the whole tree

c) see if there's a specific commit set, and if so trap the error
message and offer a useful warning like remove the repo and set
EGIT_FETCH_CMD='git clone --bare'

Unfortunately a) and b) don't solve the problem of a specific commit
being set by a user after the initial clone's taken place (in which
case, if it's not in the clone there'll never be a way to get it from
that checked out copy).

Perhaps on an error during an update could clear out the git repository
from distfiles/git-src and try again without a --depth?  Clones made
without a --depth entry that then fail would be an actual fail...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkmuZk4ACgkQu7rWomwgFXoZ9wCbBh2BH7ERu+Ck/0W0IkLxHPU4
GW4An1DMBJ2rK+Hkb92U571QegW+VDhQ
=aB2B
-END PGP SIGNATURE-

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Petteri Räty wrote:
 3) EAPI in locked down place in the ebuild
   c) .ebuild in current directory
   - needs one year wait

I'm all for 1 or 3c, because we're not in any rush.

I don't see why there's such an immediate need to make as drastic
changes as are being suggested for GLEP-55, simply to allow for the
possibility of future unknown ebuild mechanisms (like ebuilds not being
bash scripts).  If ebuilds change significantly from their current form,
then and only then, would it be a good time to change the ebuild suffixes.

I don't want to get an attachment from bugzilla and find I have to try
four different file extensions because whilst the package and version
were obvious from the bug, the eapi number wasn't.

I also don't want to run into a situation where this package manager
supports kdebuilds, whilst that package manager supports gnomebuilds,
and a third one supports xfcebuilds.  That's just recreating the browser
wars, and will leave us with the likes of IE6.

I'd be relatively happy with a shebang that specifies the parser or
passes the ebuild version, as long as it was standardized, linear and
supported by all the PMs (ie, some rogue PM can't suddenly start
allowing a myeapi that only it can build)...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkmlKQEACgkQu7rWomwgFXoRFACdHfDHuHhj7ojsQV5FvF+rRpRT
PgQAoKTq6iAmNLC50a97JHrQghRZK6O0
=ELuP
-END PGP SIGNATURE-

Re: [gentoo-dev] About prepalldocs

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Petteri Räty wrote:
 So until we have a decision on what the replacement will be I
 don't see a need to remove current prepalldocs usage but any new usage
 must be avoided.

If it's simply discouraged, perhaps a repoman check, and some people to
come forward with a better suggestion is all that's necessary?  Once the
new system's in place the repoman check can be made fatal, and suggest
the new mechanism.  That would save endless do/don't conversations on
- -dev.

It might also be worthwhile the council posting another official mail
clarifying the position, so that we can all get on with our lives.
Those that don't agree with the council can take the normal steps to
bring their disagreement to their attention...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkmcaWIACgkQu7rWomwgFXomBACeLkFewJjIieT0oA5uMcSWbJyO
dO4AoKhF0PGFz//jWIH1FxhidJ6c9CEx
=AKtW
-END PGP SIGNATURE-

Re: Fwd: [gentoo-portage-dev] search functionality in emerge

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Emma Strubell wrote:
 There must be a faster python pickler out there, though, any
 recommendations?

Right off the bat, you might try cPickle.  It should work identically,
just faster.  Also you can try importing psyco, if it's present it will
try semi-compiling some bits and pieces and *might* offer some speed-ups
(as in, it won't always, for small projects it might actually slow it down).

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmUjy8ACgkQu7rWomwgFXrW6wCfS9zTTgqbhiDyaU1opDJO3BM2
VO4AoIaPQ+t27OnTGh7tBEH/mqYntO/v
=NzDj
-END PGP SIGNATURE-

[gentoo-dev] Last rites: app-emulation/vmware-esx-console

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

# Mike Auty ike...@gentoo.org (1 Feb 2009)
# Masked for removal in 30 days.  Old and unmaintained.
# Vmware herd has no access to the product, and it's
# for a very old version.  See bug 143232.
app-emulation/vmware-esx-console
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmGGYoACgkQu7rWomwgFXry8QCfangI+iJDf7QCdz19e//H+j7c
VHkAn3p+BmdUVJHI1OgGO5xZiLykELAE
=aqPd
-END PGP SIGNATURE-

Re: [gentoo-dev] Advice regarding backporting to Gentoo from Tin Hat.

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hiya Anthony,
First off, it certainly sounds interesting and making it more
accessible (simple ebuild setup and so on) seems like a good plan even
if it doesn't get picked up officially.  The best way to start
development would probably be an overlay, which will make it easy to
bring into the tree if/when a developer wants to pick it up officially.
You might also want to look into integrating your ramification
process into catalyst the gentoo release building tool (the release
engineering team can probably tell you more about that than I can).
Also, reading the TinHat front page and mention of ram dumping, you
might be interested in [2].  It suggests not leaving the key in RAM when
it's not necessary, but shoving it into the CPU cache...
Mike  5:)

[1] http://www.gentoo.org/proj/en/releng/catalyst/
[2] http://frozencache.blogspot.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmEcQgACgkQu7rWomwgFXp+3ACghLB+686vqMLqcEm9Ye3gM1JN
KKQAoJ4R3dyx5KcVeg6+9OugRsCA0nha
=MCQf
-END PGP SIGNATURE-

Re: [gentoo-dev] GLI Officially Deprecated

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I realize it might be a bit obvious to us, but from reading it people
might wonder how they're supposed to carry out installs now.  When the
notice finally goes out, it might be worth mentioning that just the
LiveCDs are no longer supported, and mention how often the install media
is produced, and basically how people should go about doing installs
these days.  It's so easy to misread these things and for people to
start pushing out blogs and articles saying Gentoo's stopped producing
release media, etc, etc...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkluG20ACgkQu7rWomwgFXqhlgCgn0W1kVdcA256EOpNIIozgkk/
0y8An1ARvIFW8lFVjt78TmlkwU77W4gJ
=/az4
-END PGP SIGNATURE-

Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin H. Johnson wrote:
 Neither set of rules is ideal. Ordering makes a lot of sense when you
 just read it. Consider metadata with multiple maintainers and multiple
 herds. Either you have to start assigning explicitly (requires editing
 metadata.xml), or you need to fall back to ordering. If you're going to
 do ordering further down, why not do it from the start and be done with
 it.

Ok, I'm convinced.  5:)  I tend not to prefer having hidden meanings,
but as you point out XML is ordered, and you definitely made the case
that it won't have a large impact.  Fine by me...  5:)

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkljaG4ACgkQu7rWomwgFXq53gCeMRe+n+S6N2za00zuHjrge/gw
nUIAniyeVK/RTlVUaR2Q3Eqw+5cCMIoU
=01UN
-END PGP SIGNATURE-

Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeroen Roovers wrote:
 I spotted that too but didn't remember putting it in black and white. :)
 
 The order (first maintainer as assignee or first maintainer/herd as
 assignee) is open to discussion and I think this is the proper forum to
 have that discussion.

It seems sensible to me.  I would've thought that being more specific
would surely be better?  Splitting them up means those who are mostly in
charge of a package see it easily, and it's also then easier to spot
packages that only have a herd, rather than them getting lost in all the
packages that do have individual maintainers...

I've attached a quick patch that should fix up assign.py to add all the
herds on the end.  Since the order of the second item onwards doesn't
matter, all herds are added at the end.  If we do need an ordering (like
maintainer1, herd1, maintainer2, maintainer3, herd2) then it'll need a
more complex patch...

Hope this helps,

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAklg7p8ACgkQu7rWomwgFXoDwACcCDBD5Dj/F//7Bxq+zIB1/GPZ
UHQAnA82J6UxuHva7uEXmEL9wuNDMkIk
=SRmT
-END PGP SIGNATURE-
diff --git a/assign.py b/assign.py
index 82d894b..c7c2c59 100644
--- a/assign.py
+++ b/assign.py
@@ -54,6 +54,7 @@ def get_pkg_cat(string):
 def get_maintainer_for(directory):
  returns a priority-sorted list of maintainers for a given CAT or 
CAT/PN 
 cc = []
+hcc = []
 try:
 if not heXML:
 globals()['heXML'] = et.parse(HERDS)
@@ -65,7 +66,7 @@ def get_maintainer_for(directory):
 if thisherd.findtext(name) == elem.text:
 herdmail = thisherd.findtext(email)
 if herdmail:
-cc.append(herdmail)
+hcc.append(herdmail)
 elif elem.tag == maintainer:
 email = elem.findtext(email)
 if not email:
@@ -75,6 +76,7 @@ def get_maintainer_for(directory):
 cc.remove(email)
 else:
 cc.append(email)
+cc.extend(hcc)
 
 except Exception:
 pass


assign-patch.py.sig
Description: Binary data

Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Buchholz wrote:
 Accepting the fact that different teams have different preferences, we 
 need to find a solution for them to set theirs individually. This could 
 either be the order of elements in metadata.xml (and would set the 
 preference on a per-package basis) or some attribute in herds.xml 
 (which would be a global setting per herd, and we'd need to find a 
 default).

Ok, sounds like we've got some options:

a) herds.xml per-herd priority flag (herd gets assigned)
b) metadata.xml priority element (can be opt-in or opt-out)
c) order of elements in metadata.xml

I'm personally not keen on the order of elements, since adding meaning
to the order might mean a fair number of misassignments until people fix
the metadata.xml files.

The herds.xml element isn't very specific, but if the herd-first rules
apply to the whole herd, then it's probably the least-impact solution.

Finally, if we think we'll ever need something more specific than
herds.xml, we could add an extra element.  priority type=herd or
priority type=maintainer could be added to the minority case (I'm
not sure which has fewer ebuilds, but if there's hard and fast rules
this should be relatively automatable).

More involved solutions could include wrapping the appropriate element
in assignee/assignee (what happens if there's no assignee tag), or
adding an assignee attribute to one of the herd/maintainer tags (how can
we ensure there's never two assignees).

I'm up for whatever, with a slight preference toward not relying on
ordering...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAklg/AEACgkQu7rWomwgFXolAACgoujUIQs0AYRHK+JRoOsMiO41
HMkAoIHx5re/FOiD3GQNCR7fJ7xC3ebM
=Sc4j
-END PGP SIGNATURE-

Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Buchholz wrote:
 * Order in metadata.xml is what dictates assignee, i.e.: The first herd
   or maintainer listed in the metadata.xml of the first CAT or CAT/PN
   is who is assignee, all other follow as CC.

Great work, just wanted to double check the ordering though?

According to [1], When the file lists multiple entries, then you assign
the bug to the first maintainer, and CC the other maintainer(s) and
herd(s).  So it looks as though the file should go through the
maintainers first and herds second?  Should be pretty easy to fix...

Keep up the good work!  5:)

Mike  5:)

[1] http://www.gentoo.org/proj/en/qa/bug-wranglers/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAklg650ACgkQu7rWomwgFXpokwCgmocuZFPeNu6x9qXOml+DtI/a
3i0An0tGDd1va7VthoWrWyTyald9erxX
=ksov
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Use full package atoms for bug reports

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Duncan wrote:
 Amarok2 - dev-db/mysql-community - ld: /usr/lib64/mysql/libmysqld.a
 (client.o): relocation R_X86_64_32S against `client_errors' can not be 
 used when making a shared object; recompile with -fPIC

Well, I fixed this individual instance.  As Jer pointed out, it's in the
bug-wrangling guide.  Unfortunately the bug wranglers are only human,
and sometimes some will slip through.  If you find any more, it might be
worth contacting a bug wrangler directly...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAklhS6wACgkQu7rWomwgFXo5cwCePAVcKM2cJwY8SeXiDEHldzfl
NycAn3JA5dtadT7Ip/4RDyoXODd8NEtY
=PST+
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: News item: World file handling changes in Portage-2.2

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:
 Maybe the best solution is to drop the non-prefixed versions of 'world'
 and 'system' completely 

Deprecating the old syntax sounds like a sensible action to get people
shifted onto the new system.  I imagine it would work very similarly to
emerge info at the moment?

Speaking of which, when will that actually get removed (and does anyone
know how long it's been hanging around)?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjHo78ACgkQu7rWomwgFXp5aQCdEmxjiguMc1qAszRPKE4dleYo
VgoAnRuug4Or0kYPZgA3GylvPClkN5LK
=iEfE
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Santiago M. Mola wrote:
 If you're just dealing with the default phases, it's not too hard to
 say in advance the exact command that will be executed.

If that's the case, why go so far as to define three new variables and
potentially put them out in the main variable area?  If we've got
default_src_compile defined, we could do the following:

src_compile() {
default_conf=$(use_with blah)
  $(use_enable flibble)
default_src_compile
}

It then doesn't require *any* additional changes (except maybe to give
default_src_compile a well known variable name like $default_conf).
This is then only a single variable, and no more difficult to remember
than some of the eutils function names, and just as easy to look up.

It seems to allow the maximum flexibility, with the minimum changes to
package managers (assuming the defaults get into EAPI-2).

Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjE8vsACgkQu7rWomwgFXomRACgnvJZPSWEaSls4Fd+cy3T1cF5
UWQAoJ9fnZ82v5r2S/oz6GBo5Ot8iC9a
=pgRO
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] EAPI 2 Draft

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Buchholz wrote:
 How is using the eclass better for bandwidth usage? It won't allow for 
 mirroring, and all users would have to checkout the repository from one
 place. Furthermore, you cannot have (signed) Manifests that allow 
 integrity checks.

- From what I understand of the idea, the eclass will just change the
SRC_URI field from the first case (sf=tgz) to the second case (-).
Eclasses have to be sourced before the SRC_URI is determined because
they can already add (and presumably alter) elements of the SRC_URI
variable.  So I'm not sure how this would directly affect mirroring or
manifests any more than simply using the - notation?  Could you explain
what you mean when you say it won't allow for mirroring?

Generating different tarballs is much more of an issue, and would impact
on manifests too.  I guess it's a try-it-and-see situation...

Either way, it seems like the eclass idea would be a good compromise for
those that don't want gitweb specific workarounds in the package
manager, but would like to allow the flexibility for people who do?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjBJlYACgkQu7rWomwgFXowcACgt8wHN3OwRN9B19WHXVdn23BV
xvYAn1URdx9VR3z3wFiRG3RqMTlAxaOC
=crVS
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] EAPI 2 Draft

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Buchholz wrote:
 How is using the eclass better for bandwidth usage? It won't allow for 
 mirroring, and all users would have to checkout the repository from one
 place. Furthermore, you cannot have (signed) Manifests that allow 
 integrity checks.

- From what I understand of the idea, the eclass will just change the
SRC_URI field from the first case (sf=tgz) to the second case (-).
Eclasses have to be sourced before the SRC_URI is determined because
they can already add (and presumably alter) elements of the SRC_URI
variable.  So I'm not sure how this would directly affect mirroring or
manifests any more than simply using the - notation?  Could you explain
what you mean when you say it won't allow for mirroring?

Generating different tarballs is much more of an issue, and would impact
on manifests too.  I guess it's a try-it-and-see situation...

Either way, it seems like the eclass idea would be a good compromise for
those that don't want gitweb specific workarounds in the package
manager, but would like to allow the flexibility for people who do?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjBJlYACgkQu7rWomwgFXowcACgt8wHN3OwRN9B19WHXVdn23BV
xvYAn1URdx9VR3z3wFiRG3RqMTlAxaOC
=crVS
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It seems,
Slightly like an abuse of the RESTRICT variable.  I had thought that
RESTRICT was generally for when a normal ebuild needed a feature turning
off (such as mirroring, strict checking and hopefully one day ccache).
5:)  Overloading it with the live value doesn't seem to fit into that
scheme...
If there's need for a new class of ebuild information (such as a new
way of categorizing ebuilds by feature), perhaps we should add an ebuild
features variable specifically for the purpose?
Are there many ebuilds where differentiating by inheritance is
inaccurate?  If so, I'd definitely suggest a new variable, if not then
perhaps it's not worth the effort for the accuracy (there are eclasses
for almost every type of live ebuild).  If adding a new variable would
require an EAPI bump (rather than simply being ignored by older versions
of portage) then I'd still suggest against overloading a variable from
its normal usage, especially if something better's already in the works.
If we start adding bits and pieces against the naming convention for
ease now, it has the potential to end up being ugly (and a problem that
needs fixing) later down the line...
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiUJIUACgkQu7rWomwgFXobdwCeJyvzTtdPLAC0AoqFM8O69ajl
wwQAoLiFutlJw/LjHltw2uEAkCdPHNGU
=gUMq
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Zac Medico wrote:
| Honestly I don't care what the existing scheme is.

Fair enough, I don't maintain the code or have to deal with the
complaints.  It seems a waste to abandon an existing scheme though.

Particularly since RESTRICT is an odd name for random boolean flags.
Something like OPTIONS would be better, but it that can't be
added/changed quickly.  Is there an urgent pressing need for this?

| primaryuri - Fetch from URLs in SRC_URI before GENTOO_MIRRORS.

| Looking at the above list I say it's fair game to put just about any
| boolean flag in RESTRICT.

To me, almost every item in that list has not, disable, restrict
or some other negative in it, which lets it fit into a restriction.
Primaryuri is the only one that looks out of place.

You did sound up for a name change though, and if nothing else please do
change it.  Our new users/developers that don't know RESTRICT is seen as
a general purpose options flag will not find it intuitive and will
definitely wonder what RESTRICT=live means.  Not everybody knows the
ebuild format intimately, and allowing people to easily pick up what's
going on is important...

| That requires an EAPI bump, which also means that it can't be used
| in ebuilds with EAPI 0 or 1. The RESTRICT solution is simpler and we
| can use it right now in any ebuild.

It is simpler, and as I say if there's an urgent need then go for it,
but to me it feels like it's bolting on functionality into any space
it'll go.  Given that some time was spent changing all the noblah
flags to blah to fit the RESTRICT name, it's a little disappointing to
consider shoving extra flags in it now it all makes sense.

This is a relatively minor point.  In the long run, if people don't like
it, it'll get QA bugged/ironed out, if they do it'll stay, you just
asked for thoughts...  5:)

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiUT5cACgkQu7rWomwgFXqqdACfadwat4gS8/O4mX1zwcI+0VeU
XawAnjbJa2LXHiK1VMN7ZBf9ICNK+dtl
=572l
-END PGP SIGNATURE-

Re: [gentoo-portage-dev] [2/4] proto-GLEPS for Tree-signing

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry,
I lost my notes from when I last looked these over several months ago,
and only just found them again.  I haven't copied this to [EMAIL PROTECTED], so
let me know if I should do that.  I just had a quick couple of things I
was thinking about, and one of them I figured out during my re-read, so
it's only really the following...

In this Glep (xx+1), in the section discussing the procedure for
creating a MetaManifest file, in step 3.3, does that include
verification of the manifest's signature if it has one?  It would seem
odd to ignore the signature if it's wrong (I'm not sure about the case
if a signature isn't present).  I also don't know how this would then be
handled (a complete abort, or ignoring the latest changeset to that
ebuild?).
If the signature check happened here, it could also allow for
enforcable revocation of developer certificates (once they're revoked,
any signed manifests will have the ebuild changes ignored).  That may be
a lot of work and may take too long, but if not (and depending on our
users' trust needs), it might allow them just to check the
MetaManifest's signature, and not that of the individual packages.  Does
that seems sensible?

I've probably missed a key issue somewhere along the way, in which
case, sorry, and do feel free to chide me liberally...  5:)
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiPdNAACgkQu7rWomwgFXoJ9gCeLZOvpGAyr+EzI/d8EKWrnqnf
CVoAoI63EiYvB4+1cBSURIlRxaH0xy4o
=yZH7
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: GLEP 55

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mike Kelly wrote:
| Wrong.

Thanks for that.  I'm gonna assume you meant I think you're wrong.

| Sure, because of how the algorithm works, people could potentially do
| both, but the GLEP makes it pretty clear that they shouldn't.

It doesn't just say they shouldn't, it *says what happens if they do*:

pkg-4.ebuild-2, EAPI=1

~pre-source EAPI is 2, post-source EAPI is 1. EAPI 1 is used

So to live up to the GLEP specification, package managers must source
the ebuild to determine the correct EAPI.

| Basically, you don't set the post-source EAPI. It is only supposed to
| be used when the pre-source EAPI cannot be determined.

If that's what was meant, the GLEP needs changing to say that.
Something like:

pkg-4.ebuild-2, EAPI=X

~Pre-source EAPI is 2, post-source EAPI is X.  In this instance the
post-source EAPI is ignored, since a pre-source EAPI is set, so EAPI 2
is used.

It's not a big deal, but it will need a change to the GLEP in its
current form, if that's what's meant.

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhPdRUACgkQu7rWomwgFXq1twCgqnFzBqQI8vl63faZ1cq27MF7
7ekAn0aA73nic1v/ovwAUuHsaL44MrTE
=StC2
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
| No, it results in a new open() on a file that's elsewhere on disk, which
| results in two new seeks. You get about fifty seeks per second.

The speed issues aren't really a concern, since the GLEP suggests that
the ebuild must be sourced anyway.  The GLEP allows for a .ebuild-2 file
to contain EAPI=1.  This requires the package manager to source the
ebuild to find out exactly what EAPI should be being used.  The GLEP
doesn't strictly outline what happens to a .ebuild-1 containing EAPI=2
for a PM that supports EAPI=2 (which needs to be addressed before the
GLEP gets put into action).

It does say a developer should not specify both a pre- and post- source
EAPI, but the GLEP says that if both exist the post-source one is used.
~ That means all package managers would have to source the ebuilds.

Personally, as a developer, I don't want to be messing around with yet
more numbers in the ebuild filenames, and I think it looks ugly.  Not
great arguments, granted.

It also feels like a bad idea to separate information required to
process the contents of the file from the contents of the file itself.
P/PN/PV variables are used in clearly defined locations of the file, and
the script could run under a different name and version (as proved by
every version bump around).  The suggestion seems to be that an ebuild
could not run under a different EAPI.  In that case, the EAPI version
should be embedded in the contents of the file.

As people have pointed out though, there's no need to rush this
decision.  We're simply not going to achieve backwards compatibility
forever (we haven't in the past), so why not choose a time period to
allow for upgrades (6 months, a year?) and implement a new EAPI
definition mechanism that's present in the file and offers a slightly
better compromise between the various parties than the current suggestion?

It will require a little more patience, but it offers time for a thought
out and well designed choice.  What's the rush?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhOpDEACgkQu7rWomwgFXoFvgCeMxSfRiQLEZr3QyT+Bx4b5aNe
/9EAnicrcCQTXxsliAeM4mdisgjO7abg
=tGD8
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: --as-needed to default LDFLAGS

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ulrich Mueller wrote:
| But maybe Emacs is an uncommon application, or I am looking for the
| wrong things? Could one of the experts please shed some light on this?

I think you're looking for the wrong things.  I'm not an expert, but I
think --as-needed means that if there are 20 libraries on your system
that use libexpat.so.0 and 400 programs that use those 20 libraries,
when libexpat is updated to libexpat.so.1, you only need to rebuild the
20 libraries, not all 420 packages (as you would do otherwise).  I
believe that's the main reason for using as-needed...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhBp9oACgkQu7rWomwgFXr8JQCfYFDwcebduPVaY3yqUIEfVOxp
G80AoKV6SsAewxyyfv+fsiwbc6M1BHsc
=12e5
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Volkov wrote:
| Is there any reason why --as-needed is not enabled by default?

There's still about 18 open bugs on the tracker[1] for it.  You can see
how many problems it had been causing by the huge number of blocking bugs.

I've been using it for a pretty long time now (probably a couple weeks
after Diego first blogged about it) and don't have many problems at all
(now), but every once in a while a version bump or a new package will
just fail to compile properly and the problem leads back to as-needed.
I'm not sure whether ~arch users would be able to catch all the
as-needed bugs before they hit stable, so I couldn't say whether it
should be enabled by default or not.

I also don't think it would completely eliminate the problems that Diego
mentioned with preserve-libs (there could still be instances where bar
and foo both NEEDED thing.so, but bar had been compiled more recently
and needed thing.so.1 whilst foo needed thing.so.0, and starting bar
would break trying to load both)...

Mike  5:)

[1] http://bugs.gentoo.org/show_bug.cgi?id=129413
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkg/qb4ACgkQu7rWomwgFXpl7wCdFhDuZbQOVy1b12dgXbZbSWtj
dIMAn3Z6FDx5HW1KD83JxdboNrQOOap1
=Nca2
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] RFC: Should preserve-libs be enabled by default?

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:
| The purpose of this is to keep the system operational after library
| upgrades until all affected packages could be rebuilt and to simplify
| the process, not to avoid the rebuilds.

I couldn't find it mentioned in your email, but if portage is
effectively doing reference counts, what happens when its reference
count gets to 0?  Once no ebuilds rely on the old library is it removed
automatically, or do the you need to rebuild these message just go away?

Is there a way to have portage delete the libraries once it's sure
they're no longer necessary?  If so, is that done by rebuilding the
owning package itself, or by editing the owning pacakge's contents and
removing the old library?

Does @preserved-rebuild contain just the affected packages, or the
package containing the old library as well?  (i.e. Does an emerge
@preserved-rebuild ensure that the old library will no longer exist on
your system, or not?)

Basically, if I can safely replace revdep-rebuild with emerge
@preserved-rebuild then I'd be happy to keep it enabled.  If it's going
to leave cruft on the system (or then require manual rebuilds of
packages containing preserved libraries to clear out the cruft) then I'd
personally be inclined to turn it off and stick with revdep-rebuild...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkg+aSAACgkQu7rWomwgFXoR2ACeJnf+J/pd/GEEh5Ds/Q80sjOR
vIkAoKEyLD2lTGfehoSoYLP6pH/R++2J
=0sv1
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: new 'virtualization' project or herd

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tiziano Müller wrote:
| That's true. How about having a virtualization project which takes care of
| the common part, the docs and the coordination (if any) and have separate
| herds for larger subprojects?

Sounds ideal.  5:)

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkguUzwACgkQu7rWomwgFXrO0ACeIx8aTebKqkMKQe81bh/dm8mq
wXMAnRUHPhfQJsaVy1shWRsdNUd1IP4w
=bOB4
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] retirement

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hiya Duncs,
Sorry to hear your time constraints have gotten the better of you
finally.  Best of luck with well-typed, I hope it proves interesting and
that you bring much Haskelly joy to the world...  5;)
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkgNxccACgkQu7rWomwgFXpiQgCgnQuYSH3lwN8UkPfJy+DQaFwW
57MAn2yeN2Ck4jC3OgIoGngg2eMW9aKL
=umiM
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: New global USE flag: keyring

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alon Bar-Lev wrote:
| If we know there may be a future problem, why make the next *VALID*
| addition perform extra work?

I think the reasoning is that whilst there may be a future problem,
there currently isn't.  If it gets changed to gnome-keyring, it will
definitely requires all the users of the keyring USE flag to change it.
~ We could save them that hassle until there is actually a conflict?
It's just a design decision, either we do, or we don't, but I don't
think it's too big a deal.  Depends if we want to be strictly correct,
or delay a small headache for our users?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkgLdjAACgkQu7rWomwgFXrBDQCeJHUe52Czxdn41fyjmfSI7Fjt
og4AoKhxy1B8rp6k/g8o2PFcBw2DLphm
=RkIz
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for April

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Petteri Räty wrote:
| Yeah, you only need access to one ebuild to do whatever you want to
| user's systems.

Perhaps then we should direct more of our efforts towards the GPG
package signing system, so that when a dev becomes a libability, their
keys can be revoked?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkf0xgsACgkQu7rWomwgFXrStgCglCcTvdRaEGMyOdU0qfhcG7w8
TuwAnj1Vmho+LPCqreZNKlNhSRBHUjQU
=LjIi
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for April

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
|
| Signing offers no protection against a malicious developer.
|

I had envisaged a system whereby when the tree was synced, as was some
kind of master signed list of all acceptable dev-keys.  Every package
would also be signed, and would only be installed when signed.  As soon
as a dev becomes a liability their key is removed from the list/revoked.
~ On next sync any packages or package upgrades signed after the time of
revocation would not be installed.  There would be a window of
vulnerability, but no bigger than with revoking a dev's access to the
tree.  Do you think this would offer suitable protection for users from
a malicious dev or not?

I understand there are difficulties with eclasses, etc, which is why the
current implementation is still not widely used or mandated, but I'm
more interested in the feasibility of the idea.

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkf0yu8ACgkQu7rWomwgFXrxOwCeKOdkiFhpknf/q/6jq1sPf70t
3xMAoJxlLYhweQspnIJe626TYdmeA3BQ
=hKID
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for April

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

William L. Thomson Jr. wrote:
| It's about quality not quantity maybe?

It's about both, and getting the balance right is effectively what this
boils down to (as do many discussions on -dev).  There's those devs who
want high levels of QA and those devs that want the
latest/obscure/testing/rare packages.  Generally the two sides play
oppose each other.

Personally I think having both super-devs (who do lots of commits, care
deeply about QA and know their stuff intimately) and
official-contributor type devs (those who maintain a few specialist
packages when they can) is a good idea.  Giving the undertakers more
work by giving them more reports of potentially lax devs and requiring
them to investigate seems a little wasteful to me.  I'd far rather the
undertakers spent the extra time on positive contributions to the actual
distribution (rather than it's administration).

So the still unanswered question appears to be, would we like Gentoo to
have fewer packages and less choice but greater QA, stability and a feel
of professionalism, or would we like to have more packages and choice
but a worse QA record, make some mistakes, and have a more
community-based feel?  If you're going to try to answer this question
please be delicate with your repsonses, in the past I can recall
developers leaving over exactly this divide...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkf0y6wACgkQu7rWomwgFXoCRACdHKACZY9yjfetGKJ5JtRP6y6U
YBkAniFzWanDJvUkXUe8XglBBBP9sXsk
=mp9f
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for April

[Mike Auty]

Petteri Räty wrote:
Defining required amount of activity for ebuild devs. I would like us to 
raise the required amount of activity for ebuild devs.


Given that the low number of developers is ranked as our number one 
problem in Donnie's informal survey[1], taking any kind of action 
against infrequently-committing developers is likely to reduce the 
number of devs we have, and potentially make the problem worse.


What benefits are you aiming to get from the suggestion?  I can think og 
keeping the books tidy and reducing management time required to maintain 
the devs.  Are there others I've missed?  If they're worth the 
cost/effort involved with putting someone through the dev tests and 
getting them trained, then it seems a good idea, but otherwise probably 
not...


Mike  5:)

[1] http://dberkholz.wordpress.com/2008/02/21/redux-gentoos-top-3-issues/
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for April

[Mike Auty]

Petteri Räty wrote:
If you can't manage weekly commits, you can't respond to security issues 
either.


I can see your point, I was more thinking about developers who have 
maybe one or two small packages that don't have many version bumps or 
bugs.  They may be entirely able to respond to security issues, but may 
not have reason to make the weekly commit quota.  I don't know the 
habits of developers well enough to know if this is a reasonable scenario?


I was under the impression that if a dev couldn't respond quickly enough 
to a security issue, the security team could take steps (mask the 
package, try to fix it) to ensure the package doesn't pose a problem (as 
is presumably the case now with devs who forget to mark themselves as 
away).  Depending on the actions you envisaged (sending a warning email, 
marking as away or retiring) this could create a lot of extra work for 
little benefit.  If it was simply a warning email it might not be very 
pointful, but marking them as away then it sounds like it could be 
useful and automated...  5:)


Mike  5:)
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] iptables and libiptc

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Jo,
It appears that bug 177978 answers your question.  Apparently libiptc
wasn't meant to be a public interface and is intended to be removed from
the iptables pacakge[2].  Hope this helps answer your question.  Please
do have a good hunt through bugzilla when you've got a question, it's
got a huge wealth of information stored in there in both open and closed
bugs...  5:)
Mike  5:)

[1] http://bugs.gentoo.org/show_bug.cgi?id=177978
[2] http://www.netfilter.org/documentation/FAQ/netfilter-faq-4.html#ss4.5
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHvXasu7rWomwgFXoRAm84AKC06Ww9JJ3eQusx5du0SMYsJ3co6wCgryCV
ydbBEAi1Y3IAIf8DEGgkdOw=
=vB9r
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] retiring + looking maintainers for sendmail, tenshi, scapy, ftester

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry to see you leave,
I can maintain scapy if no one else wants to?
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHqglzu7rWomwgFXoRAismAJ4+4D50v0k6VSRfEfRV4mMiBP9QHACeLHJB
1IYpKEqzWFsdiFYXG7IJyhc=
=16SE
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John R. Graham wrote:
 Mike, I agree.  But, the file that _must_ exist isn't ~/.bashrc but
 ~/.bash_profile.  That's where the that particular bit of
 man-page-defined behavior is implemented.  If ~/.bash_profile doesn't
 exist, then ~/.bashrc won't be sourced whether it exists or not.

Well, bash can't install a .bash_profile file into every user's home
directory for obvious reasons.  That means they shouldn't rely on the
existence of one to source .bashrc, otherwise they could never guarantee
that functionality...

It appears as though you're looking for a location that is guaranteed to
be installed by bash and always executed when there's a non-login shell
start, from where you can source ${HOME}/.bashrc.  I'm not familiar
enough with bash or Gentoo's setup of bash to comment on this I'm afraid
(possibly /etc/bash/bashrc?), but relying on .bash_profile so that you
can or can't source ${HOME}/.bashrc seems a little odd.

Moreover, however ${HOME}/.bashrc got into ${HOME}, presumably
.bash_profile could be put there at the same time if it doesn't already
exist?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFG8mcFu7rWomwgFXoRAnIIAKCUC1ShfOYvKKt5SN4oGV1uYz8HkACfVkVU
72TtoVvFFI/RXR4WGy5ya4o=
=dxNr
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: Cryptsetup changes

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dirk,
Could you please describe the problem you faced?  From the detail you
gave, it sounds as though you might not have moved /etc/conf.d/cryptfs
to /etc/conf.d/dmcrypt.  There's currently several ewarn lines saying
that this must be done before the package will continue to work.  The
idea is that the package should work with both baselayout-1.12 and
baselayout-2, so it therefore should not need hardmasking.
Could you please provide a few more details and/or file a bug report so
that we can figure out what exactly went wrong?  If it was something
other than the move from cryptfs to dmcrypt then we should investigate,
and we'll need as much information as you can provide us to help get it
solved.  Thanks very much,
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.5 (GNU/Linux)

iD8DBQFGwtJQu7rWomwgFXoRAmvWAKCWqguvu98OVrV/CSUSU3Uz26jd5ACfZfNe
UKrhItE7ETb7XVW3UWlwNIk=
=7gz/
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] RFC : New ebuild function pkg_create for creating corespondent sorce tarball

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Vlastimil Babka wrote:
 I think he wants to do exactly that, but having the code needed for this
 right in the ebuild, so it can benefit from varibles like PV and
 versionator eclass for converting PV to e.g. CVS tags... I think it's
 quite elegant for this, and that you don't need another script
 maintained somewhere else. If there was also switch in the respective
 new 'ebuild foo.ebuild src_create' command to automatically scp files
 specified by mirror://gentoo in SRC_URI to the right place... mmm :)

It also means that if a developer has had to move files around or in
some way create the specific layout of the tarball for the ebuild, they
won't be lost if the dev goes away, or retires, etc.  So attaching the
specific package creation code to the specific package unpacking code
seems fairly sensible.  Although, I can see why there may be objections,
given the very specific circumstances in which it's useful...

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.5 (GNU/Linux)

iD8DBQFGnKUqu7rWomwgFXoRAsGzAJ9Qx8Qg4zInhXSJsoOy3C8L7ZVwjgCfS+dh
fUx8fdYlqBTPX6TSgrSLQnQ=
=kWPM
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] automated extended information gathering

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kent Fredric wrote:
 
 Ok, I've re-thought some of my ideas and tried to come up with a more
 concise explanation
 with some practical example syntax. The basic concept of 'check' was
 'this will work even if the package aint installed yet' and info was
 'for working but bust packages only', but that can be superceded with
 a CHECKLIST and a conditional driven INFO function.
 
 
 
 CHECKLIST=
a? ( some-cat/a-lib )
b? ( some-cat/b-lib )
 
 
 That would make building a checklist for lazy people as simple as
 
 CHECKLIST=${RDEPEND}
 

This seems to be quite a heavy solution just to get a little more
information.  Info seems much more simple and flexible.  If you're
having to encode information in the ebuild about what dependencies to
check when you break then how will you diagnose missing dependencies?
  From Mike's idea, I envisaged something more along the lines of:

Bug:
Compilation failed as followed:

  Package X failed to install
  ...stuff...
  X.c: ../Y.h not found
  X.c: ../Z.h not found
  ...stuff...

Response:
Could you please run emerge --info --verbose Y Z and paste the output here

Counter-Response:
 Lots of useful standard info
  Y was compiled with USE flags blah
  Y was compiled from overlay BLAH
  Y's manifest was not signed
  Y's internal env included myconf='--disable-something-critical'
  Z wasn't emerged

Speedy response:
Ah, your problem is that for some reason, something-critical was
disabled in package Y, and Z wasn't included in the dependencies.
Please try this to solve it...

It's difficult to think of situations where you'd ask for information
from an uninstalled ebuild that you couldn't ask for from installed
dependencies, but I'd rather do that manually than try encoding it into
the ebuilds and then still have to ask the user to do it manually in
some circumstances.

Most of this could be in a default pkg_info, but it allows for
overriding by an eclass, and on a per package basis, without requiring
each package writing custom error-locating code.  This is, after all,
just giving more information, it's not guaranteed to find the error.

I hope that makes some sense?

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (GNU/Linux)

iD8DBQFGkMBIu7rWomwgFXoRAghUAJ0a/EP6wRQlT2j+GcND5LZoNoqWMwCbBhbR
WwvnMHqEgmlz/auL00YvhIQ=
=kmNa
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] RFC: phasing out app-accessibility/festival

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It can also,
Be used by kismet, but it's not clear whether there are strong bindings
there, or if espeak could easily be substituted using kismet.conf.
Dunno if that's useful or not, but there you go...
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (GNU/Linux)

iD8DBQFGZbwEu7rWomwgFXoRAudDAKCUpJ9x0txA82bKkgG67TesMxl84ACfVmh0
Nx8uCQX1bhQMGj/sF/aujMw=
=+CjA
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] What's it about, anyway?

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tobias,
As a mostly under-spoken developer, I'd like to say that there are many
other developers in Gentoo than just those seen regularly on -dev.  We
also add ebuilds to the tree, but tend to be content minding our own
little corner of Gentoo.  The number of Gentoo developers, I believe, is
in the range of 400, but I've never counted them all.
We are all, at our own speeds and in our own ways contributing towards
the public domain information that goes into making up Gentoo.  Gentoo
is not a group of people, it is not the servers or the hardware, it is
the sheer amount of data that people have spent their time crafting, to
give away for free, so that Gentoo users everywhere can run a good
operating system.
I cannot speak for the other seldom-seen developers, but I personally
tend to accept the advice offered by those accused of inflaming
situations.  They say that if you can't take jokes, or seem to easily
take offense at their words, you should simply ignore them.  I have been
ignoring most of the -dev goings on for quite some time, and I shall
continue to do so for quite some time.  Throughout this though, I will
still go on maintaining the few ebuilds in the tree that I am care-taker
for, until some other kindly soul steps up to take my place.
Whilst there are those that want a vision for Gentoo, want to push it
this way, or improve it that way, they do not in themselves comprise the
entirety of Gentoo, and they too look after ebuilds entrusted to them.
Whilst they may be frustrated, wanting a larger goal, some grand
direction, there are many, many developers whose only goal is simply to
maintain an operating system they like.
I hope this offers you a slightly different perspective of this
distribution, and perhaps even causes you to reflect on your decision.
If you still wish to remove your support, I and I'm sure the other
watching developers will understand.  If, however, you can see past the
frustrations from all those searching for a way to pour their nervous
energy into Gentoo, there will be always be some developers in Gentoo
who will appreciate your contributions and be thankful that you made them.
Thank you for your thoughtful post,
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (GNU/Linux)

iD8DBQFGZfOqu7rWomwgFXoRAkeLAJ4xv12hcGrmSNB62mSahGc71YqhrQCfez3S
hB7Bu7D4TG63sdP5q2Yvml8=
=/Qrr
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Linux 2.6.21 plans

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hiya,
Reading over the discussion on lkml, it appears that it only affects
x86_64 systems...
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)

iD8DBQFGQQlpu7rWomwgFXoRAhzPAJ94Dcg/S0a6dtHodXRyPRgRT4CS0gCdHSW2
kszd0QRaPlWLg8zhoTZlc/I=
=2/I+
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: [soc] Python bindings for Paludis

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Duncan wrote:
 However, now that PMS is finally about to provide what should be a 
 definitive description of current generation package behavior, with the 
 announced intention to update this with new versions into the future as 
 required, the dependence on portage as the reference will soon be going 
 away.  The announced intention for this, among other things, is to allow 
 alternate package managers, such that it can still be clear when it's the 
 package broken and when it's the package manager.  

From what I've read of the PMS, it currently only describes the input
format it would accept (namely the format for ebuild files and their
contents).  This question can be delayed until the PMS defines the
operation of the package manager, including but not limited to the
recording of installed package data.  If the package managers do not
agree on which packages are installed or how to uninstall them, then
they are not yet interchangeable.

I apologize if this point has already been raised elsewhere in the
thread.  I try not to get involved in threads like this, but
accidentally read a reply and thought this might be a valuable response.

Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)

iD8DBQFGD6/0u7rWomwgFXoRAiT9AKCV/+YGLba3owSWEt/cbOPbyC3YrgCfbboE
+oqnTwPBGzD7ORY15VwOxoo=
=I3ta
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [soc] Python bindings for Paludis

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Duncan wrote:
 The point being, however, that all this quarreling about official 
 package managers doesn't /really/ have to happen. [...]
  I just don't see why so many are spending 
 so much time arguing over it, when regardless, people are going to make 
 their choices, and official status won't matter so much when people do 
 so, because the package spec and what works is going to be the defining 
 factor, not some official blessing, except indirectly as that affects 
 further package spec updates.

I agree that the title official is nothing more than a title or label
and will most likely be applied to the most common/popular manager.  I
think the reason for the discussion is that arguably Gentoo has been
goal-less or at the very least major-project-less, and developers with
vision are nervously looking for the direction to push the project.
Personally, I'm very happy with Gentoo as is, it's flexible, I can add
the packages I might find when browsing the web and it does everything I
need.  I don't need a major direction, or a big change, or an upheaval,
or pretty much anything else, and I believe many of the less vocal
developers feel similarly.
However, for those that are looking for a change (and sunrise and seeds
both seem recent evidence that a body of developers are looking for a
change), then I think the alternative package manager is a nice big area
with big uncertainty, given that it's well developed source-based
package management is arguably the unique selling point of Gentoo.  I
think if someone were writing a new portage that simply took over from
the old one one day, there would be nowhere near as much discussion.
Therefore, the issue at the heart of these threads is the possibility of
splintering of the project.
There are quite clearly two sides.  Those that would like to see
multiple package managers: their reasoning is that they'd like to offer
an alternative, with features and designs that would be difficult to
integrate into the existing code, and some decisions that would break
with the current design (albeit slightly).  The other side doesn't
necessarily fear another, better package manager, but fears that
allowing multiple package managers will start to cause incompatibilities
and will divide both the user group and the developer group.  Overlays
are a feature capable of this division, and already it's given rise to
the seeds idea, which again met with the same dissent: that of divided
time and resources spent on a number of smaller Gentoos, each with less
popularity, less time devoted to each, and the difficulty of
re-integration with the main branch.
Nobody actively wants to break the main tree, but no one has yet
figured out a way of ensuring that users do not encounter disruption if
they decide to use a different package manager.  The PMS is a step to
overcome this by defining a standard, or interface, to ensure compatibility.
So how can we smooth the way between the two sides?  The best I can
come up with is a more complete specification.  One that includes both
the package format, and the local state required to store data.  The
Pros for this, are that package managers could become interchangeable,
to the point that it would never matter which package manager were in
use at the time.  The cons for this idea, are that it would slow down
the development, changes and feature additions to the various managers,
as the changes must first pass through the specification and then
finally be implemented.
We've already seen (with the introduction of Manifest2) that changes to
the tree and distribution mechanism are slow at best (I believe manifest
signing is over two years old and still not in place for every
package?).  Requiring adherence to a specification, and maintaining that
specification will be even more difficult and slow, but it would allow
both sides to move on, and work together towards the new direction.
So now the question is, are we willing to accept the cons for the pros,
or do we need to find a different solution.  If not, then other package
managers should invest their time in ratifying a specification quickly,
so that they can get down to coding to the specification.  Also, those
against a new manager, should get down to agreeing the specification so
that managers with the possibility of fracturing are bound within a
framework of acceptability.  As I see it, that leaves both sides working
towards the same direction, and should give impetus to both groups to
come to a common point as fast as possible.
If not, then probably we should return to the drawing board, but I
concur that bickering and worrying about the future without pinpointing
the problem and trying to tackle it, is far more futile than working
towards a viable solution...
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)

Re: [gentoo-dev] Network configuration and bash

[Mike Auty]

Or perhaps,
	Something a little more explicit might work?  In instances such as the 
ifconfig lines, it's to create eth0 aliases (such as eth0:0), so perhaps 
that could look like:


ifconfig_eth0:0 = 10.1.1.1 netmask 255.255.255.0
ifconfig_eth0:1 = 10.1.1.2 netmask 255.255.255.0

For uses that really do require a list (such as modules), something 
like:

modules = wpa_supplicant, ifconfig

or redefinition:

modules = wpa_supplicant
modules = ifconfig

might work?  If the comma separated syntax is acceptable, it may be that 
brackets around it are acceptable too, in which case the bash syntax is 
fine.
	If the normal shells will still require *some* form of processing to 
deal with the list, could they not be given processing to deal with 
lists that bash already has builtin?

Mike  5:)
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Masked by corruption

[Mike Auty]

Jim,
	I opened bug 158632, so that's worth looking at.  It also points to a 
post on the forums about the problem.  I can't add much to the 
discussion myself, just that it affected two of my machines differently 
which I found rather odd (one has difficulty with all versions of mpc, 
the other with only one version).  I hope that helps...

Mike  5:)
--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-dev] 2.6.18 going stable in 1 week

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm not certain,
That turning vanilla-sources into linux-sources is wise, since it would
then follow that gentoo-sources become gentoo-linux-sources, and so on
for all the other linux variants.  Since everybody knows and understands
what vanilla sources mean (the installation documentation I think
explains it) it's probably not worthwhile.  Does it provide any more
advantages than being a more accurate title?
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFOKBeu7rWomwgFXoRAhpoAJoCWRbLIr2Gb454WRySa379oAITGQCghbVa
RsWPxoKQvh5TiQVUF7oZBXg=
=jSGT
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Developer: Alon Bar-Lev (alonbl)

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hiya Alon!
Congratulations, your bug contributions so far have been supremely
helpful, I'm really glad to see you made the leap to developer.  Welcome
aboard!  5:)
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFJugfu7rWomwgFXoRAsxzAKCtHYOyWxag/UZlEw1aiWCav2ybbQCfQsRC
ZVHIk5Erqu2fOif/AvoSaJc=
=iQRX
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Proposed eclasses: vmware and vmware-mod

[Mike Auty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everybody,

The Gentoo vmware team have been developing new ebuilds for
vmware-workstation, vmware-player and vmware-server (and
vmware-server-console), to help ease the maintenance of the shared
modules and shared patches between these products.  Since they all have
a similar shared installer, and many use the same modules, it was a felt
eclasses would be the best system for reducing the shared code between them.

The first eclass is for installing the video and network modules that
most vmware products use, but should also be able to deploy the modules
used in a guest vmware, for the various tools packages.

The second eclass if for installing the products themselves, which all
tend to follow a similar install process, putting the files in similar
locations, and maintaining a pseudo-installation-database used by the
vmware configuration and init scripts.

So, please take a look through the following proposed eclasses:

http://overlays.gentoo.org/svn/proj/vmware/trunk/eclass/vmware-mod.eclass
http://overlays.gentoo.org/svn/proj/vmware/trunk/eclass/vmware.eclass

and feel free to post any comments, questions or suggestions relating to
them so that we can get them fixed up and put in the tree.  Once that
happens we'll being migrating over the packages from the overlay to the
main tree, and we'll be halfway towards having easily maintained and
mess free vmware installations for all!  5:)

Thanks very much!
Mike  5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFEyTrsu7rWomwgFXoRAtGvAJ9yQMtjTgWYabA8cR0+ydrKI8UwugCbBpiP
ua+Udbyc0jIiaOQkBSKJUE0=
=UFup
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Mike Auty]

Forgive me,
I'm a little new at this and I really don't want to get involved, but
since my inbox has seen nothing but this for the past day or two, I'm
going to ask a few questions I'm interested in the answers to...
First and foremost is, will adding this to the tree be used for
function creep, whereby the next request to add to/alter the portage
tree is backed up by Well, the profile change was already added to the
tree?  I wouldn't want a precedent like this set without the council
reviewing it.
Secondly, is that what's already being done by asking individual arch
devs to add individual paludis profiles?  Surely paludis would
eventually require all archs to be there, or have I missed something
(which I may have)?  Having already added a file to the profiles
directory, which caused a few posts on here earlier, and then having
asked the question of all the devs so as to avoid a similar incident,
and then received a mixed response, now specific people have been asked
if individually they'll help get paludis in the tree.  Doesn't that seem
a little improper, perhaps?
Thirdly has anything like this ever happened to Debian or the Sourcery
group?  If so how did they cope with it, and if not, how have they
avoided it?
As you may have guessed I'm of the, You can do the same thing with an
overlay, so why must it be in the tree.  I am however willing to wait
and see what the council says, why can't the changes to the tree wait
until then, what is so urgent?  I'm especially intrigued since all this
is simply to no longer require portage as a dependency of system.  Can't
paludis peacefully co-exist with a portage installation for a little
longer, until it's mature?
Thanks,
Mike  5:\
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Paludis and Profiles

[Mike Auty]

Stephen Bennett wrote:
 The
 question is simply one of whether I can add a top-level paludis profile
 without people complaining overmuch, or whether I have to go through
 the arch teams and make sub-profiles in 4 different places under
 default-linux/.

That implies it's going to be added to the tree one way or another.  You
seem to have misplaced the third option of not adding anything to the tree.
Mike  5:)
-- 
gentoo-dev@gentoo.org mailing list