Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays

2013-06-16 Thread Alexander V Vershilov
On 16 June 2013 08:08, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
 On 6/12/13 11:51 PM, Dirkjan Ochtman wrote:
 Still seems like working in gentoo-x86 without doing stabilization
 would cover most of those bases. Working in the unstable main tree is
 still a lot better than keeping stuff out there in an overlay, IMO.

 +1

 This works really well for the Gentoo Chromium team, where we have just
 hard masked packages and ~arch packages right in the tree.

In this is a continuation of a 'gentoo-haskell' sub-thread I have to say that
Chromium and co. it not a development library this is a end user application.
End user applications should be in tree (except for some testing reasons), if
not just ignore this letter. And thanks for your work.

--
Alexander



Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-16 Thread Arfrever Frehtes Taifersar Arahesis
2013-06-15 17:51 Rich Freeman napisał(a):
 Plus, right now with Gentoo there is no way to set an overlay as being LOWER
 priority than the main tree - so that you can grab packages not supported in
 main from an overlay but still use the main packages when available.

Portage has been supporting setting of priority in /etc/portage/repos.conf for 
about 2.7 years.

$ cat /etc/portage/repos.conf
[name_of_overlay]
priority = -1001

(`emerge --info -v` shows repositories with their priorities.)

--
Arfrever Frehtes Taifersar Arahesis



[gentoo-dev] Re: [gentoo-dev-announce] Lastrites: rox-base/rox-clib, sys-firmware/iwl3945-ucode, rox-extra/downloadmanager, sys-cluster/mpi-dotnet, media-tv/livestation, dev-lang/boo, gnome-extra/cont

2013-06-16 Thread Pacho Ramos
El dom, 16-06-2013 a las 11:38 +0800, Patrick Lauer escribió:
 On 06/16/2013 04:37 AM, Pacho Ramos wrote:
  # Pacho Ramos pa...@gentoo.org (15 Jun 2013)
  # Upstream dead for ages, nothing requires it, wrongly
  # generated .la files (#201440). Removal in a month.
  rox-base/rox-clib
  
 
 No :)
 
 I've commented out that mask in package.mask because:

ah, I missed the dependency from eclasses :S

Thanks!




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

2013-06-16 Thread Tom Wijsman
On Sat, 15 Jun 2013 21:01:00 -0700
Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:

 On 6/9/13 7:22 AM, Alex Legler wrote:
  I'd appreciate some input on below plan to move project pages to
  the Wiki:
 
 Alex, thanks for working on this! Some feedback:
 
 1. How will the project pages be protected against unwanted edits? I
 think it's valuable to have some official pages where you know only
 Gentoo devs can edit them.

Pages can be protected and limited by group using Page Protection.
http://en.wikibooks.org/wiki/MediaWiki_Administrator%27s_Handbook/Page_Protection#Page_Protection_in_MediaWiki_1.5_and_later

Pages can be watched for changes using a Watchlist.
http://www.mediawiki.org/wiki/Manual:Watchlist

Watchlist notifications can be send by mail.
http://www.mediawiki.org/wiki/Extension:Email_notification

You could probably use a Procmail rule to filter whom you want to track.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


[gentoo-dev] Packages up for grabs

2013-06-16 Thread Pacho Ramos
Due ramereth lack of time:
sys-block/megacli
net-misc/stunnel
app-admin/mcollective





[gentoo-dev] Packages up for grabs

2013-06-16 Thread Pacho Ramos
Due nixphoeni lack of time the following package is up for grabs:
app-misc/gourmet





[gentoo-dev] gdesklets herd is empty

2013-06-16 Thread Pacho Ramos
Feel free to join to it or will be removed in two weeks

Thanks!




[gentoo-dev] Packages up for grabs

2013-06-16 Thread Pacho Ramos
Due ferringb retirement the following packages are up for grabs:
app-arch/tarsync
dev-python/snakeoil
dev-util/bsdiff
dev-util/diffball
sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained
and neither has eapi5 support)





[gentoo-dev] Packages up for grabs

2013-06-16 Thread Pacho Ramos
Due elvanor lack of time the following packages are up for grabs:
app-office/openerp-server
net-print/xerox-drivers
media-gfx/iscan-plugin-gt-f720 
net-libs/pjsip





Re: [gentoo-dev] mono-env.eclass: set a default SRC_URI

2013-06-16 Thread Pacho Ramos
El vie, 24-05-2013 a las 21:19 +0200, Pacho Ramos escribió:
 I noticed the following addition to mono-env.eclass would be needed to
 let us kill go-mono.eclass (setting now obsolete SRC_URI and build
 phases relying on base.eclass)
 
 Patch attached
 

Done




Re: [gentoo-dev] About moving vala to global USE flags

2013-06-16 Thread Pacho Ramos
El lun, 03-06-2013 a las 21:48 +0200, Pacho Ramos escribió:
 It's widely used in gnome related packages with similar purposes, its
 description could be:
 Enable bindings for pkgdev-lang/vala/pkg
 
 Are you ok with moving it to global?

Done




[gentoo-dev] Re: Packages up for grabs

2013-06-16 Thread Pacho Ramos
El dom, 16-06-2013 a las 12:03 +0200, Pacho Ramos escribió:
 Due elvanor lack of time the following packages are up for grabs:
 app-office/openerp-server
 net-print/xerox-drivers
 media-gfx/iscan-plugin-gt-f720 
 net-libs/pjsip
 

Also:
app-office/openerp-client
app-office/openerp-web 




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

2013-06-16 Thread Alex Legler
On 16.06.2013 06:01, Paweł Hajdan, Jr. wrote:
 On 6/9/13 7:22 AM, Alex Legler wrote:
 I'd appreciate some input on below plan to move project pages to the Wiki:
 
 Alex, thanks for working on this! Some feedback:
 
 1. How will the project pages be protected against unwanted edits? I
 think it's valuable to have some official pages where you know only
 Gentoo devs can edit them.

The Project: namespace is restricted to only allow users in the
developer group to edit.

 
 2. How will the staffing needs page be updated after dropping gorg?

You create a subpage for each staffing need, filling in information
using a form. Semantic magic aggregates these, and you'll get a template
to include for your project page to list the ones for your project
specifically.

 
 3. How secure is the wiki? Do we have regular backups and security
 updates procedures in place? I know you're member of the security team
 and infra team is doing its job well, but I just wanted to check.
 Dynamic web applications arguably have bigger attack surface than
 effectively a bunch of static files only editable after you gain server
 access.

It's part of the usual infra backup, and I follow upstream release
announcements and update accordingly.

 
 Paweł
 
 


-- 
Alex Legler a...@gentoo.org
Gentoo Security/Ruby/Infrastructure



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Diego Elio Pettenò
On 16/06/2013 11:03, Pacho Ramos wrote:
 media-gfx/iscan-plugin-gt-f720 

I'll clean it up so that it behaves like the other iscan-plugins but if
somebody has hardware that would be nice to co-maintain (including users)

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-16 Thread Luca Barbato
On 06/16/2013 02:24 AM, Zac Medico wrote:
 How about it we add a src_fetch phase, so that the VCS intricacies
 can be delegated to ebuilds/eclasses (like they are now, but without
 having to abuse src_unpack). If we include a way for src_fetch to
 communicate changes in VCS revisions to the package manager, then
 we'll be able to integrate functionality like smart-live-rebuild
 directly into the package manager (as discussed in bug 182028 [1]).

Sounds interesting.

Still please notice that the initial and misdelivered point about live
ebuild being NOT for everybody beside who develops software should be clear.

lu



Re: [gentoo-dev] [23]/3 API files

2013-06-16 Thread Alex Legler
On 16.06.2013 03:21, Robin H. Johnson wrote:
 Special pages and contents
 --
 herds.xml, repositories.xml, etc.:
 As these are intended for other applications to use, these should go to
 a new site, possibly api.gentoo.org, initially fed from a git repository.
 This site should get backed by SSL.
 Here's a partial list of the ones I know about:
 http://www.gentoo.org/proj/en/overlays/repositories.xml
 http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml
 http://www.gentoo.org/main/en/mirrors3.xml
 Both of these are broken I think:
 http://www.gentoo.org/proj/en/perl/outdated-cpan-packages.xml
 http://www.gentoo.org/proj/en/perl/outdated-cpan-packages-perl-experimental.xml
 
 - Do you know of more?

http://www.gentoo.org/proj/en/metastructure/herds/herds.xml

 - How can we better encourage these to move to an API site?

Not sure what you mean with that.

 - Some of these are meant for human consumption, others are meant for
   tool consumption, should be differentiate?

Human consumption - qa-reports.g.o

 
 Image resources:
 These can be uploaded to the Wiki.
 How can we ensure later that the media files don't get deleted?
 

Deletion is restricted to administrators, mediawiki also keeps old
versions around in case someone reuploads a file.
To prevent even that, we can restrict editing certain assets to developers.

 Other files and downloads:
 Until proper project file hosting is implemented, again a simple
 git-backed static site, possibly projects.gentoo.org.
 Please don't put lots of binary files in Git.
 

How do we expose that site to developers then? Akin to the mirroring
system on d.g.o?

-- 
Alex Legler a...@gentoo.org
Gentoo Security/Ruby/Infrastructure



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-16 Thread Georg Rudoy
2013/6/16 Zac Medico zmed...@gentoo.org:
 How about it we add a src_fetch phase, so that the VCS intricacies can be
 delegated to ebuilds/eclasses (like they are now, but without having to
 abuse src_unpack). If we include a way for src_fetch to communicate changes
 in VCS revisions to the package manager, then we'll be able to integrate
 functionality like smart-live-rebuild directly into the package manager (as
 discussed in bug 182028 [1]).

As a side note from a developer of an app that keeps various loosely
coupled modules in one repo — it'd be great if there would be a way to
also tell whether the changed revision actually affects the given
package. The default, of course, should be to assume that every change
in the repo affects a given package, but when it can be proved that
package doesn't need to be rebuilt — why bother rebuilding it? Of
course, the task of the proof lies on exact ebuild maintainer.

--
  Georg Rudoy
  LeechCraft — http://leechcraft.org



Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-16 Thread Vadim A. Misbakh-Soloviov
I'd like that behaviour!


16.06.2013 07:24, Zac Medico пишет:
 How about it we add a src_fetch phase, so that the VCS intricacies can
 be delegated to ebuilds/eclasses (like they are now, but without having
 to abuse src_unpack). If we include a way for src_fetch to communicate
 changes in VCS revisions to the package manager, then we'll be able to
 integrate functionality like smart-live-rebuild directly into the
 package manager (as discussed in bug 182028 [1]).
 
 [1] http://bugs.gentoo.org/show_bug.cgi?id=182028




signature.asc
Description: OpenPGP digital signature


RE: [gentoo-dev] Packages up for grabs

2013-06-16 Thread gmt
On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped:
 Due ramereth lack of time:
 net-misc/stunnel

Pretty sure my (dead, eventually to be revived) server uses stunnel.  I've 
never officially maintained anything, is there some documentation somewhere as 
to what exactly I'm agreeing to, if I take on proxy maintainer-ship?  Also, of 
how proxy maintainer-ship actually works?  I.e.: would I need some particular 
person to agree to be my commit-bitch or can I just sign off on patches, 
somehow, and expect a pool of commit-bitches to magically push commits for me?

-gmt





[gentoo-dev] vmware herd is empty

2013-06-16 Thread Pacho Ramos
Will drop it in two weeks if nobody joins

Thanks




Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread hasufell
On 06/16/2013 02:19 PM, g...@malth.us wrote:
 On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped:
 Due ramereth lack of time:
 net-misc/stunnel
 
 Pretty sure my (dead, eventually to be revived) server uses stunnel.  I've 
 never officially maintained anything, is there some documentation somewhere 
 as to what exactly I'm agreeing to, if I take on proxy maintainer-ship?  
 Also, of how proxy maintainer-ship actually works?  I.e.: would I need some 
 particular person to agree to be my commit-bitch or can I just sign off on 
 patches, somehow, and expect a pool of commit-bitches to magically push 
 commits for me?
 
 -gmt
 
 
 

http://www.gentoo.org/proj/en/qa/proxy-maintainers/

Afaik any of the proxy maintainers listed there can be contacted
whenever you need to apply changes to the ebuild.

They will do some kind of minimal review to check that coding style and
general ebuild rules are respected.

But basically any developer can be your proxy.



Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Pacho Ramos
El dom, 16-06-2013 a las 05:19 -0700, g...@malth.us escribió:
 On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped:
  Due ramereth lack of time:
  net-misc/stunnel
 
 Pretty sure my (dead, eventually to be revived) server uses stunnel.  I've 
 never officially maintained anything, is there some documentation somewhere 
 as to what exactly I'm agreeing to, if I take on proxy maintainer-ship?  
 Also, of how proxy maintainer-ship actually works?  I.e.: would I need some 
 particular person to agree to be my commit-bitch or can I just sign off on 
 patches, somehow, and expect a pool of commit-bitches to magically push 
 commits for me?
 
 -gmt
 

I think you will need to simply contact proxy-maint people (CCing them)
http://www.gentoo.org/proj/en/qa/proxy-maintainers/




[gentoo-dev] Re: Lastrites: rox-base/rox-clib, sys-firmware/iwl3945-ucode, rox-extra/downloadmanager, sys-cluster/mpi-dotnet, media-tv/livestation, dev-lang/boo, gnome-extra/contacts, net-im/qutecom,

2013-06-16 Thread Duncan
Pacho Ramos posted on Sat, 15 Jun 2013 22:37:50 +0200 as excerpted:

[Snipped as my comment refers to the subject]

Could you split-up announcements like this into multiple announcements, 
so the subject lines remain a reasonable length, please?

Particularly when there's lots of unrelated packages.  If they're all in 
the same pkg-category or are otherwise obviously related, it's not so 
bad.  But here we have rox packages, firmware, cluster, media, office, 
gnome, dev-sharp... all combined in the same very long subject that's 
well beyond any reasonable single-line subject length, making it very 
easy to miss something critical for the very people who are otherwise 
targeted, those who could be interested in maintaining those packages, as 
well as any remaining users who might like an early heads-up before they 
find their @world update broken due to now-masked packages that they'd 
have otherwise caught in the last-rites announcement.

That request made, thanks for helping to de-cruft the tree.  I'm glad 
someone's putting in the effort. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Dirkjan Ochtman
On Sun, Jun 16, 2013 at 11:49 AM, Pacho Ramos pa...@gentoo.org wrote:
 Due ferringb retirement the following packages are up for grabs:
 dev-python/snakeoil
 sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained
 and neither has eapi5 support)

Looks like these should go together, with pkgcore-checks (currently
maintained by python, but I'm not sure that makes sense). There's also
app-portage/maintainer-helper, which has a dead HOMEPAGE in jokey's ~
on woodpecker.

Cheers,

Dirkjan



Re: [gentoo-dev] Calling die in a subshell

2013-06-16 Thread Ulrich Mueller
 On Sat, 15 Jun 2013, Ulrich Mueller wrote:

 PMS doesn't guarantee that die works correctly in a subshell:
 http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12800011.3.3
 
 So the devmanual agrees with the spec, and the eclasses need to be
 fixed.

 How does that make any sense?

 It makes perfect sense. The specification doesn't require that the
 package manager's die function works in a subshell, so ebuilds and
 eclasses cannot rely on such behaviour.

It turns out that killing the main process (as both Portage and
Paludis do) isn't sufficient in all cases, thanks to Ciaran for
pointing this out. It will already fail for something simple like:

foo | ( bar || die )

See bug 465008 comment #2 and following.

 If you want a different behaviour for future EAPIs, then PMS
 needs to be changed.

Ulrich



RE: [gentoo-dev] Packages up for grabs

2013-06-16 Thread gmt
On Sun, 16 Jun 2013, at 05:27, Pacho Ramos thusly quipped:

 El dom, 16-06-2013 a las 05:19 -0700, g...@malth.us escribió:
 On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped:
 Due ramereth lack of time:
 net-misc/stunnel
 
 Pretty sure my (dead, eventually to be revived) server uses stunnel.  I've 
 never
 officially maintained anything, is there some documentation somewhere as to
 what exactly I'm agreeing to, if I take on proxy maintainer-ship?  Also, of 
 how
 proxy maintainer-ship actually works?  I.e.: would I need some particular 
 person
 to agree to be my commit-bitch or can I just sign off on patches, somehow, and
 expect a pool of commit-bitches to magically push commits for me?
 
 -gmt
 
 
 I think you will need to simply contact proxy-maint people (CCing them)
 http://www.gentoo.org/proj/en/qa/proxy-maintainers/

Maybe I shouldn't do this just yet.  I need to figure out whether the box in 
question gets its stunnel from gentoo or some other distribution (it has a 
severe multiple personality disorder).

If I take on maintainer-ship and it turns out I don't actually use the ebuild 
in-house, dereliction of duty on my part is almost an inevitability.  On the 
other hand, if I am relying on the ebuild, I'll almost certainly want to 
proxy-maintain, once I get my hardware issues sorted out.  There'd be no 
problem resurrecting it from the grave, if need be, would there?

-gmt





Re: [gentoo-dev] Re: Lastrites: rox-base/rox-clib, sys-firmware/iwl3945-ucode, rox-extra/downloadmanager, sys-cluster/mpi-dotnet, media-tv/livestation, dev-lang/boo, gnome-extra/contacts, net-im/qutec

2013-06-16 Thread Pacho Ramos
El dom, 16-06-2013 a las 12:42 +, Duncan escribió:
 Pacho Ramos posted on Sat, 15 Jun 2013 22:37:50 +0200 as excerpted:
 
 [Snipped as my comment refers to the subject]
 
 Could you split-up announcements like this into multiple announcements, 
 so the subject lines remain a reasonable length, please?

I am not sure it deserves the effort, or do you have any idea about how
to send all this in splitted mails easily (currently, I need to simply
add all the mask entry and copy it to the mail body) :/






[gentoo-dev] Re: Packages up for grabs

2013-06-16 Thread Michael Palimaka

On 16/06/2013 23:02, g...@malth.us wrote:

There'd be no problem resurrecting it from the grave, if need be, would there?


Please note that being unmaintained does not mean the package will be 
removed. That would only happen if there are long term unresolved issues 
with the package.


Best regards,
Michael




[gentoo-dev] Re: [RFC] SRC_URI behaviour

2013-06-16 Thread Michael Palimaka

On 16/06/2013 10:24, Zac Medico wrote:

How about it we add a src_fetch phase, so that the VCS intricacies can
be delegated to ebuilds/eclasses (like they are now, but without having
to abuse src_unpack). If we include a way for src_fetch to communicate
changes in VCS revisions to the package manager, then we'll be able to
integrate functionality like smart-live-rebuild directly into the
package manager (as discussed in bug 182028 [1]).

[1] http://bugs.gentoo.org/show_bug.cgi?id=182028


This sounds interesting. It definitely would be nice to have proper 
package manager support for VCS.


I don't think that this will somehow legitimise live ebuilds. We use 
policies to prevent inappropriate things from entering the tree, not by 
preventing tools that might facilitate it.


Best regards,
Michael




Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Brian Dolbec
On Sun, 2013-06-16 at 14:48 +0200, Dirkjan Ochtman wrote:
 On Sun, Jun 16, 2013 at 11:49 AM, Pacho Ramos pa...@gentoo.org wrote:
  Due ferringb retirement the following packages are up for grabs:
  dev-python/snakeoil
  sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained
  and neither has eapi5 support)
 
 Looks like these should go together, with pkgcore-checks (currently
 maintained by python, but I'm not sure that makes sense). There's also
 app-portage/maintainer-helper, which has a dead HOMEPAGE in jokey's ~
 on woodpecker.
 
 Cheers,
 
 Dirkjan
 

I'll take pkgcore (if somehow we can get eapi 5 finished.)

I'll take snakeoil.  I'm adding some of it's libs into catalyst

maintainer-helper also did not work for my testing.  I needed to patch
it just to get it to start.




[gentoo-dev] Re: Lastrites: rox-base/rox-clib, sys-firmware/iwl3945-ucode, rox-extra/downloadmanager, sys-cluster/mpi-dotnet, media-tv/livestation, dev-lang/boo, gnome-extra/contacts, net-im/qutecom,

2013-06-16 Thread Duncan
Pacho Ramos posted on Sun, 16 Jun 2013 15:19:26 +0200 as excerpted:

 El dom, 16-06-2013 a las 12:42 +, Duncan escribió:
 Pacho Ramos posted on Sat, 15 Jun 2013 22:37:50 +0200 as excerpted:
 
 [Snipped as my comment refers to the subject]
 
 Could you split-up announcements like this into multiple announcements,
 so the subject lines remain a reasonable length, please?
 
 I am not sure it deserves the effort, or do you have any idea about how
 to send all this in splitted mails easily (currently, I need to simply
 add all the mask entry and copy it to the mail body) :/

If it's a (semi-)manual process as the simply add all seems to imply, 
you could just do it in smaller chunks, say no more than arbitrary 
number, simply eyeballing it's fine a half-dozen packages at a time, so 
the subject length stays reasonable.  Or as I said if the packages are 
all related, don't worry about the length as it'd then be reasonably easy 
to glance at and say oh, that's nothing I care about anyway or that 
interests me I better look closer.

If it's an automated script, that could be more difficult, but at the 
same time, I'd /guess/ that if there's a script doing most of it already, 
adding logic to split by category and fire off one for each if there's 
more than a half-dozen individual packages to deal with at once, 
shouldn't be but an incremental add.

Using this one as an example, by my count there's 20 packages listed, 
which would split into ~3-4 separate announcements using the eyeballed 
half-dozen method, or ~7 announcements using a crude group by first 
category-segment (rox-*(2), sys-*(2), media*(1), dev-*(4), gnome-*(2), 
net-*(5), app-*(3) ) automated method.  Using an incrementally more 
advanced combine groups until you hit a half-dozen max method, rox/sys/
media would combine for one announcement, dev/gnome combine, net by 
itself, app by itself, four separate announcements total.

If nobody else finds the long subjects worth worrying about, maybe it's 
just me and don't worry about it.  But I'd think it'd be easier to follow 
threads just from an I'll take this one reply context as well, as even 
just that gets confusing to follow when there's 20 unrelated packages in 
the same thread, such that a dev interested in just one now has to look 
at all the replies to see if there's an I'll take this on his target 
package already, instead of just scanning subjects and seeing there isn't 
a reply yet to the thread naming the single package he's interested in.

But maybe it /is/ just me... shrug

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-16 Thread Rick Zero_Chaos Farina
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/15/2013 08:24 PM, Zac Medico wrote:
 On 06/15/2013 06:05 AM, Michał Górny wrote:
 Dnia 2013-06-15, o godz. 15:56:53
 Vadim A. Misbakh-Soloviov m...@mva.name napisał(a):

 And, moreover, I guess, SRC_URI can even be used for VCS:

 SRC_URI=
 git+ssh://github.com/lol/moo.git
 hg+ssh://bitbucket.org/lol/moo
 svn+ssh://assembla.com/lol/moo
 

 It simply can't work. Don't even try to implement, it's waste of time.
 Just grep the tree, see how various packages use VCS-es. There's too
 many differences, too many needs and -- most importantly -- VCS-es
 change over time much more quickly than, say, unpackers.

 Even *if* we get a SRC_URI VCS support that works for all consumers,
 and that'd be awfully hard to do properly, it will eventually stop
 being 'good enough' and require further changes. It will just become
 never-ending story for a minor benefit.
 
 How about it we add a src_fetch phase, so that the VCS intricacies can
 be delegated to ebuilds/eclasses (like they are now, but without having
 to abuse src_unpack). If we include a way for src_fetch to communicate
 changes in VCS revisions to the package manager, then we'll be able to
 integrate functionality like smart-live-rebuild directly into the
 package manager (as discussed in bug 182028 [1]).
 
 [1] http://bugs.gentoo.org/show_bug.cgi?id=182028

+1 on src_fetch in or out of the context of this thread.

+1 on more granular fetch/mirror restrictions

+-0 on VCS in SRC_URI, as I already stated I'm fine with the current
functionality (aside from a vast desire for src_fetch phase).

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

iQIcBAEBAgAGBQJRvc4cAAoJEKXdFCfdEflK990P/267Ej2p26SvRGItzFHtHakH
EwDEQcLxfykfqs1p1AWjR2O9e7ZvW7PaF9EyFdypY0MxAu0faB24ek4OKGD4842L
VbkQFXRjSOu1e+bLvQERofiVJ2/qSJZmg/phBsLwQiT0GVTm6ZXykZHSjfyTSALG
6ip+bhwUnYGGmxs8oudb7abBy7HfqhFlA6GTnyonqeRXre4QxfWFi1Yup/mRFuWp
XFwEoBe9t/95DBiXfjbvO5b6rlVEsChXuxELDUgP1dTdXTYKVRohs0lU6uZqlJkz
RY+8p8bJDsZas0Ucw7+7ePb93mH+XCKz5bvMrz2YhEM//NTOC6QY9+F6iy/NevTp
FNJeBCYUNKPpGzy4bm1649vDCqG51WK9iG8qtYO5G0y2QpkGZugUfALwalXK7L3M
eThjhlGrn0LZvGXxkYNtHgimFg3VWDJXJLHipMkP5dUqC5t4HEaEqgdGTCpzwuka
IUAahKdFLd3EZBlc3MHkYwuzfa0/MayOFiMcHKVV2+ONa5FcwkO8Rg6QJk5Xb7A1
NpPU87VampYERtaNcJKVACl8wR8Pltg4Y5xyz5Dgs+ga/gLvun6VePPO3WvKrAsS
UirS6VqysSEFaZTFotW0LAN6N8+Mll90gjRRgJxaQcGy1IiZ7VXYGzb8Q9nRWL9n
1PD6mk8hNr9C3aV14QzM
=7DTn
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: Lastrites: rox-base/rox-clib, sys-firmware/iwl3945-ucode, rox-extra/downloadmanager, sys-cluster/mpi-dotnet, media-tv/livestation, dev-lang/boo, gnome-extra/contacts, net-im/qutec

2013-06-16 Thread Pacho Ramos
El dom, 16-06-2013 a las 14:09 +, Duncan escribió:
 Pacho Ramos posted on Sun, 16 Jun 2013 15:19:26 +0200 as excerpted:
 
  El dom, 16-06-2013 a las 12:42 +, Duncan escribió:
  Pacho Ramos posted on Sat, 15 Jun 2013 22:37:50 +0200 as excerpted:
  
  [Snipped as my comment refers to the subject]
  
  Could you split-up announcements like this into multiple announcements,
  so the subject lines remain a reasonable length, please?
  
  I am not sure it deserves the effort, or do you have any idea about how
  to send all this in splitted mails easily (currently, I need to simply
  add all the mask entry and copy it to the mail body) :/
 
 If it's a (semi-)manual process as the simply add all seems to imply, 
 you could just do it in smaller chunks, say no more than arbitrary 
 number, simply eyeballing it's fine a half-dozen packages at a time, so 
 the subject length stays reasonable.  Or as I said if the packages are 
 all related, don't worry about the length as it'd then be reasonably easy 
 to glance at and say oh, that's nothing I care about anyway or that 
 interests me I better look closer.

It's a manual process, then, will try to divide them. Currently, length
depends on how many opened bugs are pending each time I review the
queue ;)





Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Tom Wijsman
On Sun, 16 Jun 2013 06:55:23 -0700
Brian Dolbec dol...@gentoo.org wrote:

 I'll take pkgcore (if somehow we can get eapi 5 finished.)

Here's the catch: it's not only about finishing EAPI 5, but also about
implementing the upcoming EAPI 6 changes and fixing any bugs that arise.

For it to be feasible to use it would need an upstream maintainer
for that package; it goes a little further than let's implement X or
fix Y, the code has to be understood to gain the necessary insight.

If one just hacks in things to make it work, he'll waste efforts.
Think before anyone plans to pick this up, it is quite a commitment.

http://c2.com/cgi/wiki?LegacyCode

http://www.amazon.com/books/dp/0131177052

I sincerely have interest in working on a heavily refactored PM or a PM
from scratch; but, I can't see myself pick up a big Python project as
I'm not really used to anything beyond average Python scripts. Or maybe
I'm afraid of nothing, I can't tell in advance not knowing its code.

I'll take it into consideration though; there is quite a huge choice
between applying software re-engineering practices (mostly reverse
engineering) to pkgcore, applying those practices (mostly refactoring)
to Portage or implementing an all new PM from scratch.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] vmware herd is empty

2013-06-16 Thread Andreas K. Huettel
Am Sonntag, 16. Juni 2013, 14:20:38 schrieb Pacho Ramos:
 Will drop it in two weeks if nobody joins
 
 Thanks

I've added myself to the vmware herd for now. 

However, I don't have much time and only really care about vmware-workstation, 
so additional help is more than welcome. 


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/



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


Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Anthony G. Basile

On 06/16/2013 08:27 AM, Pacho Ramos wrote:

El dom, 16-06-2013 a las 05:19 -0700, g...@malth.us escribió:

On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped:

Due ramereth lack of time:
net-misc/stunnel

Pretty sure my (dead, eventually to be revived) server uses stunnel.  I've 
never officially maintained anything, is there some documentation somewhere as 
to what exactly I'm agreeing to, if I take on proxy maintainer-ship?  Also, of 
how proxy maintainer-ship actually works?  I.e.: would I need some particular 
person to agree to be my commit-bitch or can I just sign off on patches, 
somehow, and expect a pool of commit-bitches to magically push commits for me?

-gmt


I think you will need to simply contact proxy-maint people (CCing them)
http://www.gentoo.org/proj/en/qa/proxy-maintainers/




arg sorry!  I already took this, cleaned it up and bumped it to 4.56 for 
an outstanding security issue, bug #460278.  gmt, I'd be happy to work 
with you in the future.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA




Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Brian Dolbec
On Sun, 2013-06-16 at 16:44 +0200, Tom Wijsman wrote:
 On Sun, 16 Jun 2013 06:55:23 -0700
 Brian Dolbec dol...@gentoo.org wrote:
 
  I'll take pkgcore (if somehow we can get eapi 5 finished.)
 
 Here's the catch: it's not only about finishing EAPI 5, but also about
 implementing the upcoming EAPI 6 changes and fixing any bugs that arise.
 
 For it to be feasible to use it would need an upstream maintainer
 for that package; it goes a little further than let's implement X or
 fix Y, the code has to be understood to gain the necessary insight.
 
 If one just hacks in things to make it work, he'll waste efforts.
 Think before anyone plans to pick this up, it is quite a commitment.
 
 http://c2.com/cgi/wiki?LegacyCode
 
 http://www.amazon.com/books/dp/0131177052
 
 I sincerely have interest in working on a heavily refactored PM or a PM
 from scratch; but, I can't see myself pick up a big Python project as
 I'm not really used to anything beyond average Python scripts. Or maybe
 I'm afraid of nothing, I can't tell in advance not knowing its code.
 
 I'll take it into consideration though; there is quite a huge choice
 between applying software re-engineering practices (mostly reverse
 engineering) to pkgcore, applying those practices (mostly refactoring)
 to Portage or implementing an all new PM from scratch.
 

Thank you for considering helping.  I have stayed away form the
intricate details of package management in the past, but I also do not
like how long portage is taking now for dep calculations.  So, I am
going to look into what it needs to be completed. I know there are
others out there that would also like to see pkgcore keep going.  If we
(that means I want help, so please speak up) can get EAPI 5 finished.
Then EAPI 6 will be that much easier when the time comes, which is
hopefully not too soon.

For the record, I have admin capability to pkgcore's repo, so if we can
get things ironed out.  It will be possible to push the changes to the
main repo and release it.  But, I also admit that pkgcore may have to
move to an overlay to get it up to speed with current required
functionality.




Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Pacho Ramos
El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
[...]
 Thank you for considering helping.  I have stayed away form the
 intricate details of package management in the past, but I also do not
 like how long portage is taking now for dep calculations. 

And, cannot that efforts be put in enhancing portage instead?





Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread hasufell
On 06/16/2013 07:21 PM, Pacho Ramos wrote:
 El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
 [...]
 Thank you for considering helping.  I have stayed away form the
 intricate details of package management in the past, but I also do not
 like how long portage is taking now for dep calculations. 
 
 And, cannot that efforts be put in enhancing portage instead?
 
 
 

How many forks do we got now?

And I know of at least another gentoo dev who is working on his own.



Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Brian Dolbec
On Sun, 2013-06-16 at 19:21 +0200, Pacho Ramos wrote:
 El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
 [...]
  Thank you for considering helping.  I have stayed away form the
  intricate details of package management in the past, but I also do not
  like how long portage is taking now for dep calculations. 
 
 And, cannot that efforts be put in enhancing portage instead?
 
 
 

Many of the speed improvements currently in portage CAME from Brian's
work in pkgcore.  But there comes a time when you can do only so much
with the framework that portage is based upon.  Pkgcore's base framework
is done differently and more efficiently, which is a good deal of why it
is so much faster than portage.

It has been long past due for gentoo to switch to the newer, better base
framework that is pkgcore and enhance it.

But, as you can see in gentoo's package management history for portage
and pkgcore, development tends to be a lonely endeavour, with the brunt
of it lying solely on one developer.  That has currently been the case
for portage for the past many years as well.  Others have chipped in,
including myself, but it is Zac that is doing most of it.  Too many
others have started a PM in c, c++, to replace portage, with only
paludis having come into usable existence.





Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Tom Wijsman
On Sun, 16 Jun 2013 19:21:38 +0200
Pacho Ramos pa...@gentoo.org wrote:

 El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
 [...]
  Thank you for considering helping.  I have stayed away form the
  intricate details of package management in the past, but I also do
  not like how long portage is taking now for dep calculations. 
 
 And, cannot that efforts be put in enhancing portage instead?

To make you see the problems and decisions, I'm going to elaborate a
little and would like you to ask yourself some questions.

Is it possible to reasonable enhance the Portage code to improve dep
calculations in a reasonable amount of time?

Let's take a call graph, demonstrating the amount of calls on the
arrows and the amount of ticks spend in the call in the boxes:

http://i.imgur.com/A93CdNR.png

Which part do you think is problematic? What can we do to get an
improvement in time that you can actually benefit from? Which
improvements are reasonable to implement? ...?

Ignoring that call graph, you could look at what has recently been
introduced to increase the amount of time needed to calculate the
dependency graph; you don't have to look far.

http://blogs.gentoo.org/mgorny/2013/05/27/the-pointless-art-of-subslots/

While I don't want point out the contents of that blog post, the title
is relevant; implementing features like subslots on an algorithm that
was not written with subslots in mind introduces a lot of inefficiency.

And it's not just subslots, newer features keep getting added to the
dependency graph calculation and it gets slower and slower over time.
It feels like revdep-rebuild moved into the dependency calculation!

A combination of these two above arguments (where do we start? and
why try to fix something broken by design?) makes me feel that there
is need for a huge refactoring; ask yourself another question, what if
these systems were written from scratch with subslots in mind?

Exactly, if you write a system with the features in mind you can write
it much more efficient and don't have to deal with historical decisions
that you have made in the past; you can continue writing without having
to change half of your code, because you though about it in advance.
But well, this is true in the start; some EAPIs later, history repeats!

So, when we acknowledge that it is useless to waste effort on fixes
that are unlikely to have a huge benefit or rewriting something that
might as well get replaced some years later; we should instead look for
better opportunities to do, there are multiple options:

 1) Spend an awful lot of time refactoring our well known Portage;
this doesn't only involve moving code around, but also nuking
legacy code you can't deal with (see my earlier response) as well
as writing new code where it is needed. It may sound easy, it isn't.

 2) Write a system from scratch that is certain to be future proof;
it is designed with the current and future specifications in mind,
not based on specifications that were awesome some time in the past.

 3) Spend time on learning how pkgcore is implemented, then improve it;
pkgcore can be somewhat seen as a a mix from (1) and (2).

Then, which option would you pick?

I'm not saying Portage or the team behind it is bad; it is just a bit
at the end of its time, I'm afraid of what the future will do to it.

For option (1), I've thinked slightly further than to just generate the
dependency graph, there are two things that came to mind that might be
interesting _if_ we can get it to somehow work:

 A) Multiple threads

I think the way trees work (branches), threads are a huge benefit.

Maybe zmedico can elaborate on this again, but there were some
problems that make it not easy to introduce these threads; there
was something regarding a global interpreter lock, but I can't
recall the details and am not that acquainted with Python.

Besides that, the threads will have to be organized; so properly
designing the threads, locks and inter-thread interactions might be
an interesting task that could require some effort.

 B) Additional caching

Some of the parts of the dependency graph calculation could benefit
from a bit of caching; implementing caching right might be a tricky
thing, too small cache is useless and too large cache is overhead.

Let me take one example part; resolving the USE flags to consider
which packages are dependencies, this happens again and again.

For example, let's say you have

=dev-libs/glib-2.33:2
gnome-keyring? ( =app-crypt/libsecret-0.5 )
introspection? ( =dev-libs/gobject-introspection-1 )

then Portage has to go and turn that into maybe something like

=dev-libs/glib-2.33:2

because the user has neither USE flag set; and it is not only the
USE flags the user has set, but also the USE flag in profiles, the
default USE flags, the REQUIRED_USE and sometimes even other USE
flags like use1? 

Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Tom Wijsman
On Sun, 16 Jun 2013 19:27:12 +0200
hasufell hasuf...@gentoo.org wrote:

 On 06/16/2013 07:21 PM, Pacho Ramos wrote:
  El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
  [...]
  Thank you for considering helping.  I have stayed away form the
  intricate details of package management in the past, but I also do
  not like how long portage is taking now for dep calculations. 
  
  And, cannot that efforts be put in enhancing portage instead?
  
 
 How many forks do we got now?

How much longer are we going to hold on to something that suffers from
feature creep and is based on a design invented years ago that doesn't
take into account the new features (eg. subslots) that are added today?

See my reply to Pacho for more insight why we can't enhance Portage.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


[gentoo-dev] Re: Packages up for grabs

2013-06-16 Thread Duncan
Tom Wijsman posted on Sun, 16 Jun 2013 20:23:24 +0200 as excerpted:

 On Sun, 16 Jun 2013 19:21:38 +0200 Pacho Ramos pa...@gentoo.org wrote:
 
 El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
 [...]
  Thank you for considering helping.  I have stayed away form the
  intricate details of package management in the past, but I also do
  not like how long portage is taking now for dep calculations.
 
 And, cannot that efforts be put in enhancing portage instead?
 
 To make you see the problems and decisions, I'm going to elaborate a
 little and would like you to ask yourself some questions.
 
 Is it possible to reasonable enhance the Portage code to improve dep
 calculations in a reasonable amount of time?

TL;DR: SSDs help. =:^)

Quite apart from the theory and question of making the existing code 
faster vs. a new from-scratch implementation, there's the practical 
question of what options one can actually use to deal with the problem 
/now/.

FWIW, one solution (particularly for folks who don't claim to have 
reasonable coding skills and thus have limited options in that regard) is 
to throw hardware at the problem.

I recently upgraded my main system to SDD.  As it happens, my primary 
boot didn't speed up much[1], but having both the main system partition 
(bindirs/libdirs/etc) and the portage tree and overlays on SSD 
*DRAMATICALLY* improved portage's update-ask-deep-newuse-@world 
dependency resolution time, both for the cold-tree-cache case, and, 
surprisingly, even (apparently, I've not timed it but I was sometimes 
annoyed by the time before especially for hot-cache case, and it hasn't 
bothered me at all since the upgrade) for the hot-cache case.

Between that and the 6-core bulldozer[3] I upgraded to last year, I'm 
quite happy with portage's current performance, even doing routine 
rebuilds of the perhaps half of kde I have installed, plus some other 
packages with @live-rebuild.[2]

The SSD doesn't have to be particularly big, either, but fast (if you're 
running SATA3 to use it) is nice.  I figured ~64 gig usage here, tho I 
wanted some overprovisioning, so thought I'd do 128 gig or so.  I ended 
up with 256 gig, only ~60%  partitioned (130-some gig) even with 
duplicate backup partitions for everything.  System, tree, /home, etc, on 
SSD, but still doing spinning rust for my media partitions and third-copy 
(second backup) partitions, on demonstrated reliable here reiserfs, while 
the SSD is all still-development-so-keep-your-backups-updated btrfs.

---
[1] I'm running ntp and the initial ntp-client connection and time sync 
takes ~12 seconds a lot of the time, just over the initial 10 seconds 
down, 50 to go, trigger on openrc's 1-minute timeout.

[2] 131 packages in @live-rebuild, with kde-live-branch, currently 
4.10.49., being low 120-some, plus choice bits of of X/mesa/drivers 
and a few other packages including openrc, btrfs-progs and pan.  The 
@live-rebuild typically takes ~20 minutes with ccache, a good portion of 
which is kdelibs, so the whole update including the sync and change/git-
logs check for interesting stuff, @world update, @live-rebuild, etc-
update and revdep-rebuild/depclean, runs ~1 hour, often less, sometimes  
more if there's a new mozilla-overlay firefox build or something in 
addition to the kde-libs long-build update.

[3] Also relevant, 16 gigs RAM, PORTAGETMPDIR on tmpfs.

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




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

2013-06-16 Thread Robin H. Johnson
On Sun, Jun 16, 2013 at 12:53:16PM +0200, Alex Legler wrote:
  2. How will the staffing needs page be updated after dropping gorg?
 You create a subpage for each staffing need, filling in information
 using a form. Semantic magic aggregates these, and you'll get a template
 to include for your project page to list the ones for your project
 specifically.
This should probably also feed back to the qa-reports site.

  3. How secure is the wiki? Do we have regular backups and security
  updates procedures in place? I know you're member of the security team
  and infra team is doing its job well, but I just wanted to check.
  Dynamic web applications arguably have bigger attack surface than
  effectively a bunch of static files only editable after you gain server
  access.
 It's part of the usual infra backup, and I follow upstream release
 announcements and update accordingly.
A somewhat crazy idea, but could the git-mediawiki extension be used to
create a downloadable archive of every revision as well?

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee  Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85



Re: [gentoo-dev] Re: Packages up for grabs

2013-06-16 Thread Andreas K. Huettel
Am Sonntag, 16. Juni 2013, 21:33:53 schrieb Duncan:
 Tom Wijsman posted on Sun, 16 Jun 2013 20:23:24 +0200 as excerpted:
  On Sun, 16 Jun 2013 19:21:38 +0200 Pacho Ramos pa...@gentoo.org wrote:
  El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
  [...]
  
   Thank you for considering helping.  I have stayed away form the
   intricate details of package management in the past, but I also do
   not like how long portage is taking now for dep calculations.
  
  And, cannot that efforts be put in enhancing portage instead?
  
  To make you see the problems and decisions, I'm going to elaborate a
  little and would like you to ask yourself some questions.
  
  Is it possible to reasonable enhance the Portage code to improve dep
  calculations in a reasonable amount of time?
 
 TL;DR: SSDs help. =:^)
 

Some more RAM too.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/



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


Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Ciaran McCreesh
On Sun, 16 Jun 2013 20:23:24 +0200
Tom Wijsman tom...@gentoo.org wrote:
 Is it possible to reasonable enhance the Portage code to improve dep
 calculations in a reasonable amount of time?

Before you start looking at speed, you should make it do full, correct
dependency enforcing. Get it right first, and fast later.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [23]/3 API files

2013-06-16 Thread Robin H. Johnson
On Sun, Jun 16, 2013 at 02:08:00PM +0200, Alex Legler wrote:
 On 16.06.2013 03:21, Robin H. Johnson wrote:
  Special pages and contents
  --
  herds.xml, repositories.xml, etc.:
  As these are intended for other applications to use, these should go to
  a new site, possibly api.gentoo.org, initially fed from a git repository.
  This site should get backed by SSL.
  Here's a partial list of the ones I know about:
  http://www.gentoo.org/proj/en/overlays/repositories.xml
  http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml
  http://www.gentoo.org/main/en/mirrors3.xml
  Both of these are broken I think:
  http://www.gentoo.org/proj/en/perl/outdated-cpan-packages.xml
  http://www.gentoo.org/proj/en/perl/outdated-cpan-packages-perl-experimental.xml
  
  - Do you know of more?
 
 http://www.gentoo.org/proj/en/metastructure/herds/herds.xml
 
  - How can we better encourage these to move to an API site?
 Not sure what you mean with that.
It needs to be really easy for any developer to throw up a new data
source w/ scripts onto the API site.

Even qa-reports is somewhat stalled, and doesn't have good visibility,
because it's not that easy for any dev to add something new to it.

  Image resources:
  These can be uploaded to the Wiki.
  How can we ensure later that the media files don't get deleted?
 Deletion is restricted to administrators, mediawiki also keeps old
 versions around in case someone reuploads a file.
 To prevent even that, we can restrict editing certain assets to developers.
See my other comment about git-mediawiki maybe, that would satisfy my
needs, just having old versions of the images around as needed (not
admin-deletable).

  Other files and downloads:
  Until proper project file hosting is implemented, again a simple
  git-backed static site, possibly projects.gentoo.org.
  Please don't put lots of binary files in Git.
  
 How do we expose that site to developers then? Akin to the mirroring
 system on d.g.o?
I need to dust off the project hosting proposal, because there are a lot
of files that need to move to it (like all the elections  PR
materials).

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee  Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85



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

2013-06-16 Thread Kent Fredric
On 16 June 2013 16:01, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:

 On 6/9/13 7:22 AM, Alex Legler wrote:
  I'd appreciate some input on below plan to move project pages to the
 Wiki:

 Alex, thanks for working on this! Some feedback:

 1. How will the project pages be protected against unwanted edits? I
 think it's valuable to have some official pages where you know only
 Gentoo devs can edit them.

 2. How will the staffing needs page be updated after dropping gorg?

 3. How secure is the wiki? Do we have regular backups and security
 updates procedures in place? I know you're member of the security team
 and infra team is doing its job well, but I just wanted to check.
 Dynamic web applications arguably have bigger attack surface than
 effectively a bunch of static files only editable after you gain server
 access.

 Paweł



IMHO, the criteria for being able to edit the wiki should be lower than the
present requirements on being a Gentoo Dev.

There should still be some degree of vetting, but the risk a person poses
being able to make doc updates is significantly less than the risk a person
poses by throwing them a CVS bit.

I'd be interested in seeing if theres' a way to have vetted edits of some
kind, ala a patchqueue/pull-merge feature but for wikis, allowing a user to
edit a page as they see fit, but the changes are only visible to them until
they mark their edits done where it can be pushed to a moderation queue
for somebody trusted to check over.

Because otherwise, I feel you're missing out on the benefits of wiki.

A game I play, tribalwars.com, has a wiki, but the purpose of having a wiki
is incredibly redundant, because most the documentation there is grossly
out of date, and the tribalwars staff (the only people who can edit it)
don't edit anything themselves much, and as a result, there are huge chunks
of the wiki that are blatantly wrong, and I would edit them if I could, and
there is no good reason to suggest my edits would be likely malevolent in
fixing this, but alas, due to fear of abuse to security, the wiki hugely
misses its intended audience and is practically useless, and the rigmarole
that is required for any casual user correcting finding a minor flaw is so
great, it simply never occurs.


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

2013-06-16 Thread Andreas K. Huettel
Hi Kent, 
 
 IMHO, the criteria for being able to edit the wiki should be lower than the
 present requirements on being a Gentoo Dev.

Only a small subset of official pages is locked, everything else is free to 
edit for anyone who signs himself up.

 
 I'd be interested in seeing if theres' a way to have vetted edits of some
 kind, ala a patchqueue/pull-merge feature but for wikis, allowing a user to
 edit a page as they see fit, but the changes are only visible to them until
 they mark their edits done where it can be pushed to a moderation queue
 for somebody trusted to check over.
 

That exists and is used in the German Wikipedia.
(Basically, you get the last vetted page by default, with a small message 
saying newer versions available.)

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/



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


Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Tim Harder
On 2013-06-16 06:55, Brian Dolbec wrote:
   Due ferringb retirement the following packages are up for grabs:
   dev-python/snakeoil
   sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained
   and neither has eapi5 support)

 I'll take pkgcore (if somehow we can get eapi 5 finished.)

 I'll take snakeoil.  I'm adding some of it's libs into catalyst

I can help with pkgcore, pkgcore-checks, and snakeoil as well. I've got
most of the EAPI 5 resolver work done in a local fork and have been
fixing other bugs I've found along the way.

Tim



[gentoo-dev] Gentoo: growing pains the future.

2013-06-16 Thread Robin H. Johnson
(Please reply on the gentoo-project list, I have set the Reply-To header
for this mail appropriately).

===
TL;DR: 
- Does GLEP39 still serve all the needs of Gentoo? Devrel useful?
- How to improve ourselves as a distribution (technical) and as people
  (personal interactions)?
- Would EVERY developer please start acting professionally in all fora?
===

I would like us to thank (and remember those no longer with us) all of
the past trustees and council members (a near-complete list is included
as footnote [9]), for what they have done to try and grow the
distribution.

Regardless of whoever who decides to run for council and trustees this
year, I would like to ask developers and foundation members to look at
the history of Gentoo, prior councils and prior trustees, and ask
themselves: 
What value does the distribution, Council, and Trustees provide to you?
Why they are voting for any given candidate; is this the best for the
future of Gentoo, or does it really even matter?

Of candidates: Is it because of their technical prowess; ability to
reach compromises; they can manage people well; possibly because you
simply like or respect them; or because they're a hothead and you want
to shake things up?  Regardless of why you pick them, all of the above
are things they may have to do on the council and trustees.

I have contributed just over a decade of my life to Gentoo at this
point, many times choosing consulting work or jobs because they enabled
me to contribute more.  I'm one of the very few developers that has been
both a council member and a trustee, the others are: dberkholz, seemant,
swift, agriffis, azarah, wolf31o2

In 2006, I ran for council, on a platform of improving the security of the
Portage tree, via my tree-signing GLEPs.
http://thread.gmane.org/gmane.linux.gentoo.devel/39928/focus=40610
I would call that project a long-term failure; the standards were completed,
but like many GLEPs, mostly become forgotten and left by the wayside.
In that original goal, I would consider my term on the council to be a failure,
but extremely enlightening as to the politics and human aspect of a technical
organization. I left at the end of my term, not seeking re-election.

In 2009, I ran for trustees on a platform of radical transparency, that
manifesto is also still available
http://dev.gentoo.org/~robbat2/robbat2-foundation2009-manifesto.txt
My goals were somewhat less quantifiable at the time, but I feel that I
did help bring trustees to the same well-documented level as council;
our financial  legal affairs are in good shape (many thanks to
quantumsummers), and well-visible to the member base (yes, I would like
a return to visible quarterly accounting or more detailed granularity,
but we don't have that many transactions). I ran again successfully in
2011, because I wasn't done my work yet.

I choose to not nominate anybody for either body this time; not because
I have no faith in my fellow developers, but because I think we as a
distribution have needs beyond our present structure of Council and
Trustees, *Rel and the projects.

Many of our early organizational issues have been replaced with those of
a more mature organization. I think to a degree, we have grown beyond
GLEP39.  Go ahead, read GLEP39 again, and think about it from the
perspective of a new(er) developer, vs. The Old Ones (as I saw it put
recently). Now go to the projects that you're in, and tell me, when was
the last time you had a real discussion about who lead a given project
(the GLEP was careful to say 'selection' rather than 'election'). Does
who leads a project actually matter in all cases? If a more
established dev refuses a change, what can you do?

The council, originally founded as technical body in 2005, has been
running for 8 years, and in that time GLEP submissions have been
replaced by EAPI changes to a minor degree, but overall we are no longer
adapting to change as we once were.

GLEP submissions have dropped dramatically, and instead we have a lot
less highly visible change (unless it breaks things). Does this mean I
expect everything to be a GLEP? No, the GLEP process in itself can be a
hindrance to getting what you want done, and regardless of how great an
idea it is, it doesn't guarantee adoption. Should we scrap GLEPs
entirely? No, we should push even more of our changes through them,
because they are a lot less personal than other proposals on the mailing
lists. They are TECHNICAL improvements, and need to be considered
PROFESSIONALLY, without any personal malice.

Put the GLEPs to the council if they need more consensus, and the
council needs to consider/approve them more often. If it's just smaller
technical changes, let any developer feel free to do it; and take
responsibility for their actions if they cause any breakage. Herds were
created to group related ebuilds together (not developers), nor to stop
development.

Many times in our history, we have tried to grapple with the human
problems in our distribution, 

Re: [gentoo-dev] Re: Packages up for grabs

2013-06-16 Thread Tom Wijsman
On Sun, 16 Jun 2013 19:33:53 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 TL;DR: SSDs help. =:^)

TL;DR: SSDs help, but they don't solve the underlying problem. =:-(

I have one; it's great to help make my boot short, but it isn't really
a great improvement for the Portage tree. Better I/O isn't a solution
to computational complexity; it doesn't deal with the CPU bottleneck.

Sadly, an improvement to the CPU as good as the switch from HDD to SSD,
I'm yet to see such a hardware improvement. Maybe if we stack the
transistors into the third dimension, something Intel was working on.

 Quite apart from the theory and question of making the existing code 
 faster vs. a new from-scratch implementation, there's the practical 
 question of what options one can actually use to deal with the
 problem /now/.

Don't rush it: Do you know the problem well? Does the solution
properly deal with it? Is it still usable some months / years from now?

 FWIW, one solution (particularly for folks who don't claim to have 
 reasonable coding skills and thus have limited options in that
 regard) is to throw hardware at the problem.

Improvements in algorithmic complexity (exponential) are much bigger
than improvements you can achieve by buying new hardware (linear).

 I recently upgraded my main system to SDD. ... SNIP ... Between that
 and the 6-core bulldozer[3] I upgraded to last year, I'm quite happy
 with portage's current performance, ... SNIP ...

Ironically, you don't even fully use the CPU, but only one core of it;
I'm glad you have a 6-core processor, but to Portage it is a 1-core
during dependency tree calculation.

Portage becomes slower at a faster rate than your hardware get faster;
this will continue to be that way until you make Portage benefit of
it, or failing that you would need to come up with an alternative PM.

I didn't get my short boot from upgrading hardware alone; quite the
opposite, it was rather the results of the efforts spent on it.

 ---
 [1] I'm running ntp and the initial ntp-client connection and time
 sync takes ~12 seconds a lot of the time, just over the initial 10
 seconds down, 50 to go, trigger on openrc's 1-minute timeout.

Why do you make your boot wait for NTP to sync its time?

How could hardware make this time sync go any faster?

 [2] ... SNIP ... runs ~1 hour ... SNIP ...

Sounds great, but the same thing could run in much less time. I have
worse hardware, and it doesn't take much longer than yours do; so, I
don't really see the benefits new hardware bring to the table. And that
HDD to SSD change, that's really a once in a lifetime flood.

 [3] Also relevant, 16 gigs RAM, PORTAGETMPDIR on tmpfs.

Sounds all cool, but think about your CPU again; saturate it...

Building the Linux kernel with `make -j32 -l8` versus `make -j8` is a
huge difference; most people follow the latter instructions, without
really thinking through what actually happens with the underlying data.
The former queues up jobs for your processor; so the moment a job is
done a new job will be ready, so, you don't need to wait on the disk.

Something completely different; look at the history of data mining,
today's algorithms are much much faster than those of years ago.

Just to point out that different implementations and configurations have
much more power in cutting time than the typical hardware change does.

Though, this was pretty much OT; we're talking about the dependency tree
calculation, not about emerging which is rather a result of building
(eg. your compiler) than it has anything to do with the package manager.

PS: A take home thought: What if the hardware designers decided to not
RD storage, then we wouldn't have a SSD; same story, different level.
Another level higher; we have physics, maybe CERN can improve hardware?
But when will that happen? Can we rely and wait on that to happen?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Packages up for grabs

2013-06-16 Thread Ciaran McCreesh
On Sun, 16 Jun 2013 23:24:27 +0200
Tom Wijsman tom...@gentoo.org wrote:
 I have one; it's great to help make my boot short, but it isn't really
 a great improvement for the Portage tree. Better I/O isn't a solution
 to computational complexity; it doesn't deal with the CPU bottleneck.

If the CPU is your bottleneck, Python won't help you. Python's threads
are fine for making IO easier, but the GIL prevents them from being of
any use for CPU intensive calculations.

Having said that, the CPU isn't your bottleneck.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Zac Medico
On 06/16/2013 11:23 AM, Tom Wijsman wrote:
 Ignoring that call graph, you could look at what has recently been
 introduced to increase the amount of time needed to calculate the
 dependency graph; you don't have to look far.
 
 http://blogs.gentoo.org/mgorny/2013/05/27/the-pointless-art-of-subslots/
 
 While I don't want point out the contents of that blog post, the title
 is relevant; implementing features like subslots on an algorithm that
 was not written with subslots in mind introduces a lot of inefficiency.

It's actually not bad, since all of the subslot rebuilds are triggered
in a single backtracking run. Anyway, I welcome having people work on
competing package managers, trying to do all of this stuff more
efficiently. :-)

 And it's not just subslots, newer features keep getting added to the
 dependency graph calculation and it gets slower and slower over time.
 It feels like revdep-rebuild moved into the dependency calculation!

I guess the main things that make it slower than it has been
historically would be things like --autounmask, --backtrack,
--complete-graph-if-new-use and --complete-graph-if-new-ver. Note that
you can use EMERGE_DEFAULT_OPTS to disable these things if you would
prefer to live without them. You might use something like --backtrack=2
if you want it to bail out early for all but the simplest backtracking
cases. Use --ignore-built-slot-operator-deps=y if you want to disable
all rebuilds involving subslots and slot-operators.
-- 
Thanks,
Zac



Re: [gentoo-dev] Re: Packages up for grabs

2013-06-16 Thread Tom Wijsman
On Sun, 16 Jun 2013 22:38:56 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Sun, 16 Jun 2013 23:24:27 +0200
 Tom Wijsman tom...@gentoo.org wrote:
  I have one; it's great to help make my boot short, but it isn't
  really a great improvement for the Portage tree. Better I/O isn't a
  solution to computational complexity; it doesn't deal with the CPU
  bottleneck.
 
 If the CPU is your bottleneck, Python won't help you. Python's threads
 are fine for making IO easier, but the GIL prevents them from being of
 any use for CPU intensive calculations.
 
 Having said that, the CPU isn't your bottleneck.

That's assuming you would go threaded, but you can also aim for lower
algorithmic complexities; the complexity makes the CPU the bottleneck.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] [23]/3 API files

2013-06-16 Thread Alex Legler
On 16.06.2013 21:44, Robin H. Johnson wrote:
 […]
 - How can we better encourage these to move to an API site?
 Not sure what you mean with that.
 It needs to be really easy for any developer to throw up a new data
 source w/ scripts onto the API site.
 
 Even qa-reports is somewhat stalled, and doesn't have good visibility,
 because it's not that easy for any dev to add something new to it.
 

Currently, it's files in CVS, soon to be files in a Git. That's at least
the same reachability as before. I think solving this problem is a
separate task.

Image resources:
 These can be uploaded to the Wiki.
 How can we ensure later that the media files don't get deleted?
 Deletion is restricted to administrators, mediawiki also keeps old
 versions around in case someone reuploads a file.
 To prevent even that, we can restrict editing certain assets to developers.
 See my other comment about git-mediawiki maybe, that would satisfy my
 needs, just having old versions of the images around as needed (not
 admin-deletable).

Um, got a link for that extension?
I didn't clarify, the Wiki can be configured to keep a revision even if
someone deletes a file.

 
 Other files and downloads:
 Until proper project file hosting is implemented, again a simple
 git-backed static site, possibly projects.gentoo.org.
 Please don't put lots of binary files in Git.

 How do we expose that site to developers then? Akin to the mirroring
 system on d.g.o?
 I need to dust off the project hosting proposal, because there are a lot
 of files that need to move to it (like all the elections  PR
 materials).
 

…or that.

-- 
Alex Legler a...@gentoo.org
Gentoo Security/Ruby/Infrastructure



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Ciaran McCreesh
On Sun, 16 Jun 2013 14:57:32 -0700
Zac Medico zmed...@gentoo.org wrote:
 It's actually not bad, since all of the subslot rebuilds are triggered
 in a single backtracking run. Anyway, I welcome having people work on
 competing package managers, trying to do all of this stuff more
 efficiently. :-)

I'm starting to think we're all doing this wrong by going for a naive
single choice then backtrack model, fully consistent or otherwise.
Perhaps we're going to have to bite the bullet and go for stronger
propagation models and one of the many better alternatives to
backtracking...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Packages up for grabs

2013-06-16 Thread Ciaran McCreesh
On Mon, 17 Jun 2013 00:07:57 +0200
Tom Wijsman tom...@gentoo.org wrote:
 That's assuming you would go threaded, but you can also aim for lower
 algorithmic complexities; the complexity makes the CPU the bottleneck.

Dependency solving is NP-hard in theory and better than quadratic in
practice. The resolution algorithms also aren't the problem in terms of
runtime (and still won't be if we started using more sophisticated
algorithms for better decision making). The problem is simply that the
model is large and messy, and the problem being solved has all kinds
of awful corner cases that have to be considered.

(As one example, every user has somewhere between a hundred and a
thousand packages installed, each of which depends directly or
indirectly upon every other package in this collection.)

There are certainly improvements to be made, both in terms of
efficiency and correctness, but if you're looking for a big leap
forward then the most useful thing we could do is reduce or eliminate
some of the requirements that make dependency resolution such a fiddly
(not hard) problem.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [23]/3 API files

2013-06-16 Thread Alex Xu
On 16/06/13 03:44 PM, Robin H. Johnson wrote:
 Image resources:
   These can be uploaded to the Wiki.
   How can we ensure later that the media files don't get deleted?
  Deletion is restricted to administrators, mediawiki also keeps old
  versions around in case someone reuploads a file.
  To prevent even that, we can restrict editing certain assets to developers.
 See my other comment about git-mediawiki maybe, that would satisfy my
 needs, just having old versions of the images around as needed (not
 admin-deletable).
 

With modern MediaWiki, it is impossible to permanently remove a page or
file without the system administrator (I mean SSH access, not MW sysop)
intentionally permitting it or deleting the file archive.

https://www.mediawiki.org/wiki/Manual:Image_administration#Undeleting_files
https://www.mediawiki.org/wiki/Extension:Oversight
https://www.mediawiki.org/wiki/Manual:RevisionDelete



signature.asc
Description: OpenPGP digital signature


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

2013-06-16 Thread Alex Xu
On 16/06/13 04:36 PM, Andreas K. Huettel wrote:
 Hi Kent, 

 IMHO, the criteria for being able to edit the wiki should be lower than the
 present requirements on being a Gentoo Dev.
 
 Only a small subset of official pages is locked, everything else is free to 
 edit for anyone who signs himself up.
 

 I'd be interested in seeing if theres' a way to have vetted edits of some
 kind, ala a patchqueue/pull-merge feature but for wikis, allowing a user to
 edit a page as they see fit, but the changes are only visible to them until
 they mark their edits done where it can be pushed to a moderation queue
 for somebody trusted to check over.

 
 That exists and is used in the German Wikipedia.
 (Basically, you get the last vetted page by default, with a small message 
 saying newer versions available.)
 

MediaWiki has a builtin flag mechanism for revisions, but this serves
only to try to get all revisions reviewed by at least one person.

Pending Changes as implemented by the English Wikipedia uses
Extension:FlaggedRevs [0] which, in the most common configuration,
allows anyone to edit but hides their changes from the general public
until an authorized user approves the changes. [1]

[0] https://www.mediawiki.org/wiki/Extension:FlaggedRevs
[1] https://en.wikipedia.org/wiki/Wikipedia:Pending_changes



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-06-16 23h59 UTC

2013-06-16 Thread Robin H. Johnson
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2013-06-16 23h59 UTC.

Removals:
kde-misc/ktouchpadenabler   2013-06-12 18:19:14 johu

Additions:
sys-devel/heirloom-devtools 2013-06-10 00:10:32 ryao
app-text/jmupdf 2013-06-10 08:45:58 xmw
dev-python/sphinxcontrib-httpdomain 2013-06-10 09:07:30 idella4
www-apache/mod_auth_xradius 2013-06-10 09:12:25 chainsaw
dev-ruby/source_map 2013-06-10 12:58:36 graaff
dev-ml/core_kernel  2013-06-10 13:23:17 aballier
dev-ml/textutils2013-06-10 14:34:18 aballier
sci-physics/geant-data  2013-06-10 16:34:20 bicatali
dev-python/discogs-client   2013-06-10 18:02:46 idella4
dev-lang/ats2013-06-11 03:54:55 patrick
dev-java/jama   2013-06-11 13:55:47 tomwij
app-leechcraft/lc-imgaste   2013-06-11 14:25:18 
maksbotan
dev-tex/circuit_macros  2013-06-11 14:41:06 calchan
gnome-extra/gnome-shell-extensions-topicons 2013-06-12 10:15:16 pacho
dev-python/tdaemon  2013-06-12 14:06:53 idella4
dev-ruby/state_machine  2013-06-13 05:28:46 graaff
dev-python/itsdangerous 2013-06-14 03:17:21 
rafaelmartins
sys-fs/squashfuse   2013-06-14 08:23:09 zmedico
net-libs/libblkmaker2013-06-14 18:11:59 blueness
dev-python/send2trash   2013-06-15 04:19:08 idella4
dev-lang/nwcc   2013-06-15 06:20:36 patrick
net-firewall/sanewall   2013-06-15 11:07:43 
radhermit
dev-java/hamcrest-generator 2013-06-15 19:54:51 tomwij
dev-python/recaptcha-client 2013-06-16 11:38:33 idella4
dev-util/reviewboard2013-06-16 16:02:06 idella4

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
kde-misc/ktouchpadenabler,removed,johu,2013-06-12 18:19:14
Added Packages:
sys-devel/heirloom-devtools,added,ryao,2013-06-10 00:10:32
app-text/jmupdf,added,xmw,2013-06-10 08:45:58
dev-python/sphinxcontrib-httpdomain,added,idella4,2013-06-10 09:07:30
www-apache/mod_auth_xradius,added,chainsaw,2013-06-10 09:12:25
dev-ruby/source_map,added,graaff,2013-06-10 12:58:36
dev-ml/core_kernel,added,aballier,2013-06-10 13:23:17
dev-ml/textutils,added,aballier,2013-06-10 14:34:18
sci-physics/geant-data,added,bicatali,2013-06-10 16:34:20
dev-python/discogs-client,added,idella4,2013-06-10 18:02:46
dev-lang/ats,added,patrick,2013-06-11 03:54:55
dev-java/jama,added,tomwij,2013-06-11 13:55:47
app-leechcraft/lc-imgaste,added,maksbotan,2013-06-11 14:25:18
dev-tex/circuit_macros,added,calchan,2013-06-11 14:41:06
gnome-extra/gnome-shell-extensions-topicons,added,pacho,2013-06-12 10:15:16
dev-python/tdaemon,added,idella4,2013-06-12 14:06:53
dev-ruby/state_machine,added,graaff,2013-06-13 05:28:46
dev-python/itsdangerous,added,rafaelmartins,2013-06-14 03:17:21
sys-fs/squashfuse,added,zmedico,2013-06-14 08:23:09
net-libs/libblkmaker,added,blueness,2013-06-14 18:11:59
dev-python/send2trash,added,idella4,2013-06-15 04:19:08
dev-lang/nwcc,added,patrick,2013-06-15 06:20:36
net-firewall/sanewall,added,radhermit,2013-06-15 11:07:43
dev-java/hamcrest-generator,added,tomwij,2013-06-15 19:54:51
dev-python/recaptcha-client,added,idella4,2013-06-16 11:38:33
dev-util/reviewboard,added,idella4,2013-06-16 16:02:06

Done.

Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays

2013-06-16 Thread Paweł Hajdan, Jr.
On 6/16/13 12:36 AM, Alexander V Vershilov wrote:
 In this is a continuation of a 'gentoo-haskell' sub-thread I have to say that
 Chromium and co. it not a development library this is a end user application.
 End user applications should be in tree (except for some testing reasons), if
 not just ignore this letter. And thanks for your work.

Nice. :)

Note however that v8 and ninja (the build system) are also maintained by
the project in the tree. There is also libsrtp...

Paweł




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Rafael Goncalves Martins
On Sun, Jun 16, 2013 at 6:49 AM, Pacho Ramos pa...@gentoo.org wrote:

 Due ferringb retirement the following packages are up for grabs:
 ...
 dev-util/diffball


I'll take it.

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


Re: [gentoo-dev] How to spread intltool fixes to all packages

2013-06-16 Thread Mike Frysinger
On Tuesday 11 June 2013 05:55:14 Pacho Ramos wrote:
 Because of:
 https://bugs.gentoo.org/show_bug.cgi?id=432848
 
 We discovered an old bug affecting intltool that causes prefix of
 localedir to be always hardcoded to the same location instead of
 respecting configure flags.
 
 The patch is fixed by intltool upstream in their master branch but still
 no new version was released including it. Anyway, we now have
 dev-util/intltool-0.50.2-r1 with the bug fixed.
 
 The problem of this issue (and most involving intltool) is that we need
 to run:
 intltoolize --copy --automake --force
 (it doesn't seem to trigger maintainer mode in all ebuilds I have tried,
 then, doesn't look to require eautoreconf to be run)
 
 for all packages to get new and fixed ${S}/po/Makefile.in.in copied to
 the sources, otherwise bundled file is used and, then, the one unfixed.
 As it's unreliable to ping all upstreams involving intltool (they are a
 ton) and this kind of problem will likely re-appear again in the future
 (since the Makefile.in.in will be fixed in intltool upstream tarball but
 will take a lot of time to reach all affected packages) we were
 considering to run above command always at eclass level - that way we
 would stop using bundled ${S}/po/Makefile.in.in and, then, we would
 always use the one provided by our intltool package (that should get
 fixed and updated more often).
 
 Other possible solution would be to use ELT-PATCHES to achieve that, but
 I am still unsure about how would it work.

ELT-PATCHES is only used by elibtoolize which means it requires an explicit 
call to patch things

you're basically talking about the same type of problem that 
https://bugs.gentoo.org/220040 tried to address.  maybe we should update 
autotools.eclass to have a general patching mechanism since any EAPI based one 
is doomed to failure.  and then we rebase elibtoolize to that.
-mike


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


Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Sergey Popov
16.06.2013 13:49, Pacho Ramos пишет:
 Due ferringb retirement the following packages are up for grabs:

 dev-util/bsdiff

I will take care of it...

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Qt project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs

2013-06-16 Thread Brian Harring
It's low maintenance; only thing needed is either to rebase to my
libtransform work, or add proper xz support.

Either way, any questions, let me know.
~brian


On Mon, Jun 17, 2013 at 1:16 AM, Sergey Popov pinkb...@gentoo.org wrote:

 16.06.2013 13:49, Pacho Ramos пишет:
  Due ferringb retirement the following packages are up for grabs:
 
  dev-util/bsdiff

 I will take care of it...

 --
 Best regards, Sergey Popov
 Gentoo developer
 Gentoo Desktop-effects project lead
 Gentoo Qt project lead




Re: [gentoo-dev] Re: evar_push/pop helpers

2013-06-16 Thread Mike Frysinger
On Sunday 02 June 2013 13:38:04 Steven J. Long wrote:
 On Sat, Jun 01, 2013 at 11:03:20PM -0400, Mike Frysinger wrote:
  --- eutils.eclass   22 May 2013 05:10:29 -  1.421
  +++ eutils.eclass   2 Jun 2013 03:00:46 -
  @@ -146,6 +146,77 @@ estack_pop() {
  eval unset ${__estack_name}\[${__estack_i}\]
   }
 
 Just in passing, one of the places you don't want nullglob messing things
 up.

not sure what you mean.  that escapes the [] so that bash doesn't accidentally 
glob things.  when the code actually executes, you don't need to escape 
things.

touch f i d x
unset arr
declare -A arr
arr[f]=1234
arr[idx]=4321
echo ${arr[f]} ${arr[idx]}
__estack_name=arr
__estack_i=f
eval unset ${__estack_name}\[${__estack_i}\]
echo ${#arr[@]}
__estack_i=idx
eval unset ${__estack_name}\[${__estack_i}\]
echo ${#arr[@]}

seems to work

  +# is not specified, the var will be unset.
  +evar_push_set() {
  +   local var=$1
  +   evar_push ${var}
  +   case $# in
  +   1) unset ${var} ;;
  +   2) eval ${var}=\$2 ;;
 
 I wish you wouldn't use eval for this. I know it's technically okay here,
 or would be if you verified the parameter, but bash has printf -v for this
 purpose:

interesting, i hadn't seen that before ... looks new to bash-3.1.  /me tucks 
that into his tool belt.

although it doesn't quite work in the edge case where the value is an empty 
string.  consider:
unset x
printf -v x ''
echo ${x+set}

that should show set, but it does not.  i'll have to keep `eval ${var}=` 
when the value we're setting is empty.  or just keep the eval code since i 
have to do eval anyways at that point.

i'll report it upstream to the bash guys.

 printf -v $1 '%s' $2 2/dev/null || die unable to set: '$1' to: '$2'
 
 Note you should verify the variable name, ime, irrespective of a die on the
 printf (or eval in sh.) It's much better feedback to the developer using
 the routine.

i don't think it's worth it.  if you screw up the name, it tends to be a one-
time cost, and the error shown is pretty clear as to where it's coming from.

 printf -v also works with array members btw, if you do decide to extend in
 that direction:

i don't think i will, but i probably can convert the other core stack code to 
use this ...

  +   : ${cnt:=bad}
  +   [[ -n ${cnt//[0-9]} ]]  die ${FUNCNAME}: first arg must be a
  number: $*
  +   ;;
 
 Though a generic is_int function comes in much handier, ime.

yeah, and we have other code that wants this (a simple grep for 0-9 in eclass/ 
shows a bunch of hits)

  -   # Some people like to make dirs of patches w/out suffixes (vim)
  +   # We have to force sorting to C so that the wildcard expansion
  # is consistent #471666.
  +   evar_push_set LC_COLLATE C
  +   # Some people like to make dirs of patches w/out suffixes (vim).
  set -- $1/*${EPATCH_SUFFIX:+.${EPATCH_SUFFIX}}
  +   evar_pop
 
 Have to say I'd just do this in a function adding to a locally-scoped
 array, if it were me, eg local args; foo $1 $EPATCH_SUFFIX; set --
 ${args[@]}; unset args
 foo() {
   local LC_COLLATE=C
   args=($1/*${2:+.$2})
 }

since i plan on using these funcs in other places, using the existing api 
keeps things simple

 though I'd prefer it if EPATCH_SUFFIX were allowed to be a list,
 personally.

wouldn't really make this any easier
-mike


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


Re: [gentoo-dev] evar_push/pop helpers

2013-06-16 Thread Mike Frysinger
On Sunday 02 June 2013 03:48:17 Tom Wijsman wrote:
 On Sun, 2 Jun 2013 03:29:33 -0400 Mike Frysinger wrote:
  except you aren't handling edge cases (like set vs unset)
 
 You've got me there, though this is quite an exception; I don't see
 why we have to introduce something that's barely used...
 
 `qgrep -eH '^\s*\bset\b' | wc -l`
 yields 150
 
 `qgrep -eH '^\s*\bset\b' | sed 's/:.*//g' | sed
 's/\/[a-zA-Z0-9_.-]*$//g' | sort -u | wc -l`
 yields 34
 
 Only 34 packages, and do these all _really_ need a 'set'? I doubt it.

i've got at least 4 consumers in mind, and that's more than enough imo to 
implement it right than half-ass it every time

   Much like fixing tiny bug and trying to
   avoid checking whether anything else is affected.
  
  yeah, because forcing specific behavior for an entire function is
  always the correct answer.  it's like telling people to export
  LC_ALL=C in make.conf so they never hit locale related problems.
 
 Actually, bug wranglers stopped asked for English build logs because
 setting LC_ALL=C ended up breaking things.

i know it doesn't work which is why i was providing it as an example
-mike


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


Re: [gentoo-dev] evar_push/pop helpers

2013-06-16 Thread Mike Frysinger
here's v2
-mike

--- eutils.eclass   22 May 2013 05:10:29 -  1.421
+++ eutils.eclass   17 Jun 2013 05:41:58 -
@@ -146,6 +146,79 @@ estack_pop() {
eval unset ${__estack_name}\[${__estack_i}\]
 }
 
+# @FUNCTION: evar_push
+# @USAGE: variable to save [more vars to save]
+# @DESCRIPTION:
+# This let's you temporarily modify a variable and then restore it (including
+# set vs unset semantics).  Arrays are not supported at this time.
+#
+# This is meant for variables where using `local` does not work (such as
+# exported variables, or only temporarily changing things in a func).
+#
+# For example:
+# @CODE
+#  evar_push LC_ALL
+#  export LC_ALL=C
+#  ... do some stuff that needs LC_ALL=C set ...
+#  evar_pop
+#
+#  # You can also save/restore more than one var at a time
+#  evar_push BUTTERFLY IN THE SKY
+#  ... do stuff with the vars ...
+#  evar_pop # This restores just one var, SKY
+#  ... do more stuff ...
+#  evar_pop 3   # This pops the remaining 3 vars
+# @CODE
+evar_push() {
+   local var val
+   for var ; do
+   [[ ${!var+set} == set ]] \
+val=${!var} \
+   || val=${___ECLASS_ONCE_EUTILS}
+   estack_push evar ${var} ${val}
+   done
+}
+
+# @FUNCTION: evar_push_set
+# @USAGE: variable to save [new value to store]
+# @DESCRIPTION:
+# This is a handy shortcut to save and temporarily set a variable.  If a value
+# is not specified, the var will be unset.
+evar_push_set() {
+   local var=$1
+   evar_push ${var}
+   case $# in
+   1) unset ${var} ;;
+   # Can't use `printf -v` as that does not set $var when $2 is .
+   2) eval ${var}=\$2 ;;
+   *) die ${FUNCNAME}: incorrect # of args: $* ;;
+   esac
+}
+
+# @FUNCTION: evar_pop
+# @USAGE: [number of vars to restore]
+# @DESCRIPTION:
+# Restore the variables to the state saved with the corresponding
+# evar_push call.  See that function for more details.
+evar_pop() {
+   local cnt=${1:-bad}
+   case $# in
+   0) cnt=1 ;;
+   1) isdigit ${cnt} || die ${FUNCNAME}: first arg must be a number: 
$* ;;
+   *) die ${FUNCNAME}: only accepts one arg: $* ;;
+   esac
+
+   local var val
+   while (( cnt-- )) ; do
+   estack_pop evar val || die ${FUNCNAME}: unbalanced push
+   estack_pop evar var || die ${FUNCNAME}: unbalanced push
+   # Can't use `printf -v` as that does not set $var when $2 is .
+   [[ ${val} == ${___ECLASS_ONCE_EUTILS} ]] \
+unset ${var} \
+   || eval ${var}=\${val}
+   done
+}
+
 # @FUNCTION: eshopts_push
 # @USAGE: [options to `set` or `shopt`]
 # @DESCRIPTION:
@@ -218,6 +291,18 @@ eumask_pop() {
umask ${s} || die ${FUNCNAME}: sanity: could not restore umask: ${s}
 }
 
+# @FUNCTION: isdigit
+# @USAGE: number [more numbers]
+# @DESCRIPTION:
+# Return true if all arguments are numbers.
+isdigit() {
+   local d
+   for d ; do
+   [[ ${d:-bad} == *[!0-9]* ]]  return 1
+   done
+   return 0
+}
+
 # @VARIABLE: EPATCH_SOURCE
 # @DESCRIPTION:
 # Default directory to search for patches.
@@ -344,8 +429,11 @@ epatch() {
local EPATCH_SUFFIX=$1
 
elif [[ -d $1 ]] ; then
-   # Some people like to make dirs of patches w/out suffixes (vim)
+   # We have to force sorting to C so that the wildcard expansion 
is consistent #471666.
+   evar_push_set LC_COLLATE C
+   # Some people like to make dirs of patches w/out suffixes (vim).
set -- $1/*${EPATCH_SUFFIX:+.${EPATCH_SUFFIX}}
+   evar_pop
 
elif [[ -f ${EPATCH_SOURCE}/$1 ]] ; then
# Re-use EPATCH_SOURCE as a search dir


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


Re: [gentoo-dev] [RFC] unpacker.eclass extensions

2013-06-16 Thread Mike Frysinger
On Saturday 15 June 2013 04:39:10 Vadim A. Misbakh-Soloviov wrote:
 # @DESCRIPTION:
 # Unpack nixstaller generated files

needs a period at the end.  content in @DESCRIPTION is normalized.

 # They're shell scripts with the blob package tagged onto
 # the end of the archive. In the blob placed tarballs with
 # actual content.

They're shell scripts with a tarball appended to them.

 # Please note, if you need additional dependecies make sure to unpack
 subarch
 # archive as first argument.

no idea what this means

 nixstaller_unpack() {

this does not follow the API naming convention (unpack comes first)

 local unpack_files=$@

this doesn't work.  you normalized the input into a string.  just inline the 
$@ below.  or don't specify it at all ... this does the same thing (albeit, 
correctly):
local src
for src ; do

 unpack_banner $i
 # Make sure that file exists
 [[ -f ./$i ]]  (
 local type=$(file -b ${i})
 case ${type} in
 data)
 tar -xJf ./$i

why doesn't the bzip2 detect as bzip2 ?

 ;;
 gzip*)
 tar -xzf ./$i
 ;;
 esac
 ) || die Failed to unpack $i

the subshell should go away -- you don't even need it:
[[ $? -eq 0 ]] || die ...

i wish we could merge with the file detection in unpack_makeself somehow
-mike


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