Re: [gentoo-dev] rfc: adding GOPATH to ENV_UNSET in base profile

2020-06-01 Thread Rafael Goncalves Martins
On Sun, May 31, 2020 at 9:06 PM William Hubbs  wrote:

> All,
>
> The GOPATH variable has similar issues to GOBIN [1], so I would like to
> add it along side GOBIN to ENV_UNSET in the base profile.
>
> The message link below is only there for reference, but I see ebuilds
> unsetting GOPATH in the tree and this would take care of it across all
> of the tree.
>
> Thoughts?
>
>
We need this. Anyone developing go software with GOPATH explicitly set will
hit issues like this when installing a package using go-module.eclass, at
least:

verifying github.com/mitchellh/go-homedir@v1.1.0: open
/home/rafael/dev/git/go/pkg/mod/cache/download/
github.com/mitchellh/go-homedir/@v/v1.1.0.ziphash: permission denied


> Thanks,
>
> William
>
> [1]
> https://archives.gentoo.org/gentoo-dev/message/163010f83ae7819d80c0cfdf797cbfe0
>

Thanks,

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


[gentoo-dev] Last rites: net-dns/dnsimple-dyndns

2020-03-27 Thread Rafael Goncalves Martins
# Rafael G. Martins  (2020-03-27)
# Python 2 only. Uses old version of DNSimple API.
# Removal in 30 days.  Bug #712960
net-dns/dnsimple-dyndns

-- 
Rafael


[gentoo-dev] packages up for grabs

2020-01-09 Thread Rafael Goncalves Martins
app-emulation/qemu-init-scripts
app-text/txt2tags
dev-lua/luadoc
dev-lua/luaexpat
dev-lua/luafilesystem
dev-lua/luarocks
dev-lua/luasec
dev-lua/toluapp
dev-vcs/mercurial-server
www-apps/trac-accountmanager
www-apps/trac-mercurial
www-apps/trac-tags

-- 
Rafael 


[gentoo-dev] Last rites: dev-vcs/blogc-git-receiver, www-server/blogc-runserver

2016-04-29 Thread Rafael Goncalves Martins
# Rafael G. Martins <rafaelmart...@gentoo.org> (30 Apr 2016)
# Packages merged upstream with app-text/blogc. Please install
# app-text/blogc with USE=git and USE=httpd instead. Removal in 30 days.
dev-vcs/blogc-git-receiver
www-server/blogc-runserver

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



Re: [gentoo-dev] Gitolite with WebHooks: testers wanted

2015-03-09 Thread Rafael Goncalves Martins
On Mon, Mar 9, 2015 at 2:27 AM, Robin H. Johnson robb...@gentoo.org wrote:

 Hi all,

 Amongst Git migration preparations, one of the previously mentioned
 items was that GitHub's webhooks were very useful for many tasks.

 The QA team is already using them on the gentoo-portage-rsync-mirror
 repo, to trigger regular Travis-CI runs.

 In line with our policies of not depending on closed source and concerns
 about the persistence of GitHub, I've got an initial cut of WebHook
 support for Gitolite. These will probably be the primary means of
 interaction with external services, as we'd prefer not to give gitolite
 any SSH private keys to reach out to the world.

 It's based on the notify-webhook project [1], I also have the blessing
 of that author to improve his code and push generic changes to it.

 I'm looking for testers:
 Do you have a repo on gitolite AND would like pushes to trigger a
 webhook?

 If so, please file a bug for the public details. Additionally, if your
 hook has a username/password/secret token, please send me a GPG email
 with those details.

 Details needed:
 - repo path
 - webhook URL
 - webhook contenttype (json or url-encoded [default])
 - webhook auth details if any (user, pass, realm, secret token)

 I do have plans to make it self-service later, but that will be a while
 coming.

 [1] https://github.com/metajack/notify-webhook


Just some quick notes, about changes that may be needed in current github
webhooks to work with our infra:

- some webhooks may validate for github's IP range [1], and fail to be
triggered by gentoo infra servers.
- some webhooks may parse repository URLs assuming that the webhooks are
triggered by github, e.g. to add some user/password/token.

[1]
https://help.github.com/articles/what-ip-addresses-does-github-use-that-i-should-whitelist/

[]'s

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


Re: [gentoo-dev] [RFC] luajit global useflag

2015-03-01 Thread Rafael Goncalves Martins
On Sun, Mar 1, 2015 at 6:46 PM, Rafael Goncalves Martins
rafaelmart...@gentoo.org wrote:
 On Sun, Mar 1, 2015 at 9:45 AM, Vadim A. Misbakh-Soloviov m...@mva.name 
 wrote:
 В письме от Вс, 1 марта 2015 20:36:03 пользователь Ben de Groot написал:

 Or maybe one of the other lua package maintainers has plans?


 Not that I'm in-tree lua maintainer, but as Lua-overlay contributor and lua-
 fanboy, I'd suggest to unmask all lua-interpreters and make them slotted just
 as python/ruby/whatever. And provide a eselect-lua (I had ebuild for it
 somewhere).

 This isn't going to happen any time soon, for several reasons. :(

 Although, there is single issue: precompiled bytecode isn't compatible 
 between
 even 5.1 PUC-Rio Lua and LuaJIT, and, of course, AFAIR, between Lua5
 releases.

 You explained why yourself. This issue can be solved doing something
 like what is done for python, compiling and installing bytecode for
 each interpreter, but unless someone implements this perfectly, at
 least luajit isn't going to be involved in such thing.

 But I don't think Lua-users do not know about that, so I don't think it is a
 real problem.

 No, this is a real problem to implement multi-interpreter support.
 They don't care about the issue because they don't care about
 supporting other interpreters, or even multiple versions of Lua
 installed in parallel.

 I'm going to repeat this once again: Lua was designed to be built
 statically, then upstream don't cares about compatibility between
 different versions and interpreters. Creating static libraries is
 something that distributions want (and is generally the best
 approach), but the upstream developers don't care about this at all.
 That said, if you want to go that way, you are in your own, upstream
 isn't going to care about your issues or make your life easier.

s/Creating static libraries/Creating shared libraries/

obviously. :)

[]'s

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



Re: [gentoo-dev] [RFC] luajit global useflag

2015-03-01 Thread Rafael Goncalves Martins
On Sun, Mar 1, 2015 at 9:45 AM, Vadim A. Misbakh-Soloviov m...@mva.name wrote:
 В письме от Вс, 1 марта 2015 20:36:03 пользователь Ben de Groot написал:

 Or maybe one of the other lua package maintainers has plans?


 Not that I'm in-tree lua maintainer, but as Lua-overlay contributor and lua-
 fanboy, I'd suggest to unmask all lua-interpreters and make them slotted just
 as python/ruby/whatever. And provide a eselect-lua (I had ebuild for it
 somewhere).

This isn't going to happen any time soon, for several reasons. :(

 Although, there is single issue: precompiled bytecode isn't compatible between
 even 5.1 PUC-Rio Lua and LuaJIT, and, of course, AFAIR, between Lua5
 releases.

You explained why yourself. This issue can be solved doing something
like what is done for python, compiling and installing bytecode for
each interpreter, but unless someone implements this perfectly, at
least luajit isn't going to be involved in such thing.

 But I don't think Lua-users do not know about that, so I don't think it is a
 real problem.

No, this is a real problem to implement multi-interpreter support.
They don't care about the issue because they don't care about
supporting other interpreters, or even multiple versions of Lua
installed in parallel.

I'm going to repeat this once again: Lua was designed to be built
statically, then upstream don't cares about compatibility between
different versions and interpreters. Creating static libraries is
something that distributions want (and is generally the best
approach), but the upstream developers don't care about this at all.
That said, if you want to go that way, you are in your own, upstream
isn't going to care about your issues or make your life easier.

[]'s

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



Re: [gentoo-dev] Making more repoman checks fatal

2015-02-16 Thread Rafael Goncalves Martins
On Mon, Feb 16, 2015 at 11:19 AM, Mike Frysinger vap...@gentoo.org wrote:
 On 16 Feb 2015 21:00, Patrick Lauer wrote:
 Thus I suggest making the following warnings proper errors:

 some of these are because they produce false positives.  at least these bugs
 probably need to be fixed first:
 https://bugs.gentoo.org/405017
 https://bugs.gentoo.org/488836
 https://bugs.gentoo.org/533460
 -mike

I think that just the last bug is still valid.

[]s

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



Re: [gentoo-portage-dev] Portage team, Zac's development break and stepping down as lead

2014-01-12 Thread Rafael Goncalves Martins
On Sun, Jan 12, 2014 at 1:40 PM, Brian Dolbec dol...@gentoo.org wrote:
 On Sun, 2014-01-12 at 04:27 -0200, Rafael Goncalves Martins wrote:

 Hi Brian,

 I'm somewhat familiar with portage code, and want to help a bit too.
 My main target would be to integrate distpatch (distfile delta
 support, a.k.a. my work on gsoc 2011) with portage. I sent the patch
 to the list years ago, but it never got any reviews, etc. I'm going to
 rewrite it and add some tests, etc.

 Can I join the team? :)

 Thanks!


 Sure. With more people, it will be less demanding on each of us.

 I know myself I've only spent maybe half an hour in the code so far, and
 still haven't finished it.  The rest of the time I've spent in getting
 established as lead.  Also with more people being familiar with the
 code, team decisions will help keep bad ideas from creeping in, etc..

 Can you give us the link to any code you have (with g.o.g.o down) and a
 brief summary of how it works please.  The we can start to have a look
 at it.  Possibly come up with some better (if possible) ideas on
 integrating it.

 P.S. add yourself to the project wiki page as a member.

I'm currently rewriting the patch. It does not seems to work with
current master. Will send to the list asap.

General description of the feature is here:
http://www.gentoo.org/proj/en/infrastructure/distpatch/

I'll migrate this page to the wiki soon.

BR,

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



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] Package up for grabs: dev-libs/fcgi

2013-05-15 Thread Rafael Goncalves Martins
On Tue, May 14, 2013 at 10:31 PM, Rafael Goncalves Martins 
rafaelmart...@gentoo.org wrote:

 On Tue, May 14, 2013 at 3:06 PM, Hans de Graaff gra...@gentoo.org wrote:

 Hi,

 I thought I already dropped maintainership of this package a long time
 ago, since I haven't been using fastcgi for ages, but a new bug today
 told me I forgot. I've done so now. Someone please pick this up if you
 still use fastcgi.

 dev-libs/fcgi

 https://bugs.gentoo.org/show_bug.cgi?id=469794 is the one open bug about
 the AM_CONFIG_HEADER macro.

 Hans



 I'm still using it. will get it if nobody gets until tomorrow :)


Got it.

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


Re: [gentoo-dev] Package up for grabs: dev-libs/fcgi

2013-05-14 Thread Rafael Goncalves Martins
On Tue, May 14, 2013 at 3:06 PM, Hans de Graaff gra...@gentoo.org wrote:

 Hi,

 I thought I already dropped maintainership of this package a long time
 ago, since I haven't been using fastcgi for ages, but a new bug today
 told me I forgot. I've done so now. Someone please pick this up if you
 still use fastcgi.

 dev-libs/fcgi

 https://bugs.gentoo.org/show_bug.cgi?id=469794 is the one open bug about
 the AM_CONFIG_HEADER macro.

 Hans



I'm still using it. will get it if nobody gets until tomorrow :)

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


Re: [gentoo-dev] Automagic pax-mark

2013-04-08 Thread Rafael Goncalves Martins
On Mon, Apr 8, 2013 at 9:29 AM, Chí-Thanh Christopher Nguyễn
chith...@gentoo.org wrote:
 Mike Gilbert schrieb:
 After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call 
 no
 longer has a || die. This means that the resulting binaries may have PT_PAX,
 XATTR_PAX, both or neither markings depending on kernel configuration,
 filesystem and mount options.

 I'd say that is not a good thing. If you agree with me, what could be done
 here? Have pax-mark die in the eclass or mandate || die in ebuilds? This
 would probably require pax-mark calls to be conditional on pax_kernel USE
 flag or similar.

 Most ebuilds do not call pax-mark || die. Most people do not run PaX
 systems, so a failure here is not a major issue.

 I agree that not having the pax-mark is not a significant problem
 currently. It could become one when PaX becomes more widespread, but
 that is not likely in the near term.

 What I think is bad is the automagic aspect of enabling pax-mark.


 Best regards,
 Chí-Thanh Christopher Nguyễn



I had some issues with pax-mark failling to work on openvz containers
stored on partitions mounted without the user_xattr argument and
ebuilds with '|| die', and was going to open bugs to people remove the
'|| die' statements from the ebuilds, when I saw this thread.

Disable xattr isn't a very common use case, but it is still valid. I
don't want to have my builds falling at install phase just because the
binary can't be pax-mark'ed, when I clearly don't care about PaX.

If we don't want the automagic behavior, we should allow users to
explicitly disable it.

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



Re: [gentoo-dev] Last rites: media-tv/tvtime

2013-03-24 Thread Rafael Goncalves Martins
On Fri, Mar 22, 2013 at 8:15 PM, Markos Chandras hwoar...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 # Markos Chandras hwoar...@gentoo.org (22 Mar 2013)
 # Fails with automake-1.12 (#424289)
 # Problems with the alsa patches (#403389)
 # Herd has not interest in it and needs a maintainer
 # Removal in a month unless a new maintainer steps up
 # and fix all the bugs
 # Alternatives: media-tv/me-tv, media-tv/mythtv
 media-tv/tvtime


Too sad to see it being treecleaned. :(

I used it for a long time, and it really rocks, but I don't own any
pc-tv hw anymore. I'd like to avoid it being treecleaned, but without
the hw, it is just impossible.

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



[gentoo-dev] Lastrite: www-client/xxxterm

2013-01-30 Thread Rafael Goncalves Martins
# Rafael G. Martins rafaelmart...@gentoo.org (31 Jan 2013)
# Renamed to xombrero. Please install www-client/xombrero (bug #417555)
# The package was not pkg-moved to fix the upstream versioning mess.
# Removal in 30 days
www-client/xxxterm

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



Re: [gentoo-dev] stabilization candidates rss feed html pages

2013-01-22 Thread Rafael Goncalves Martins
On Tue, Jan 22, 2013 at 10:57 PM, Brian Dolbec dol...@gentoo.org wrote:
 On Tue, 2013-01-22 at 14:44 +0100, Theo Chatzimichos wrote:
 On Tue, Jan 22, 2013 at 2:25 PM, Petteri Räty betelge...@gentoo.org wrote:
  On 13.1.2013 0.49, Paweł Hajdan, Jr. wrote:
  Please review attached automatically generated stabilization candidates
  for January.
 
  I don't want to annoy people with automatically filed bugs, and at the
  same time I also received lots of positive feedback about the effort to
  keep the stable tree more up-to-date.
 
  I think the best way to proceed is to listen to that feedback and
  continue the effort, while also keeping an updated list of exclusions
  for packagers/herds that are actively stabilized by maintainers.
 
 
  I have an RSS feed for this purpose at:
 
  http://gentoo.petteriraty.eu/stable.rss
 
  Sources are available here:
 
  https://github.com/betelgeuse/scripts/blob/master/rss-changelog
 
  Maybe this is something that should be pushed to official Gentoo
  infrastructure so more people know about it and use it?

 File a bug against us then, with all the information needed for the 
 deployment

 Theo

 I had a look at the script, unfortunately (for me), it's both a ruby
 script and deps on paludis to get the information.

 Personally I think this would work well, but re-written in python and
 use portage for info.  As euscan is all about scanning for upgradeable
 pkgs, it is already getting updated pkg info, scanning metadata.xml,
 etc. using portage, gentoolkit, and custom code.  So this would fit well
 with it.  It is python, django based.  It could also offer the rss feed
 in a web page with a search box, and/or integrate the candidates into
 the pkgs status reports it does.

 Second reason, I believe it is getting or already has deployment on
 gentoo infra servers.

 I pinged `fox` in #-www about it, Corentin iksaif wasn't online there
 at the time.  cc'ing them here.

I think that euscan would benefit of this feature, but the your
arguments against ruby/paludis aren't valid IMO. If the euscan guys
want to integrate the feature, nice. If not, lets just stick with this
script. It is simple enough that even ruby n00bs like me can
understand what it does :P

BR.


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



Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

2013-01-02 Thread Rafael Goncalves Martins
On Wed, Jan 2, 2013 at 10:11 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
 On 01/01/13 23:01, Jeff Horelick wrote:

 I would like to propose a switch of the order of DEPENDs in
 virtual/pkgconfig to make dev-util/pkgconf[pkg-config] the default
 choice for new installations.

 dev-util/pkgconf has less external dependencies, is lighter and is
 faster than dev-util/pkgconfig while being now 100% compatible

 This switch has already been made by Funtoo, Alpine Linux and FreeBSD
 with very little in the way of ill effects recently from any of those
 3 camps.

 There are no more pending bugs against pkgconf (and Diego did a
 tinderbox run with it a while back) in Gentoo.

 pkgconf also has a upstream that is more than happy to work with us
 specifically (or anyone for that matter) and I (a Gentoo developer) am
 one of the upstream developers.

 If this is approved, I will make the change in ~2 weeks. I'm not
 planning on making a news item because users should notice little
 difference.

 Thanks
 Jeff


 i'd say never. there is no benefit in switching. pkg-config is the default
 implementation from freedesktop.org.
 pkg-config is now lighter and has less dependencies than before as the
 switch from bundled glib1 to glib2 allowed dropping of the popt library.

 and since pkgconf upstream doesn't properly follow pkg-config upstream git
 and do necessary changes, like for bug 445796 it would mean pkg-config
 related bugs would have to be reported to double upstream and thus, not be
 maintainable

 last I checked prefix didn't have issues with the pkg-config bootstrap
 either. there is no circular deps either.

 lose-lose situation for the switch, so over my commit access ;-)


I agree with you. The original implementation should be our default.
People interested in get rid of the glib dependency should be able to
replace pkg-config with pkgconf manually. No need to make an
unofficial implementation the default.

Regards,

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



Re: [gentoo-dev] RFC: change of the default value for EHG_REVISION (mercurial.eclass)

2012-12-18 Thread Rafael Goncalves Martins
On Tue, Dec 18, 2012 at 7:31 PM, Mike Gilbert flop...@gentoo.org wrote:
 On Tue, Dec 18, 2012 at 4:10 PM, Christoph Junghans ott...@gentoo.org wrote:
 With nelchael's retirement I (with backup from djc) will take over the
 maintenance of mercurial.eclass. As one of the first things I would
 like to change the default value of EHG_REVISION.

 EHG_REVISION defines the revision/branch/tag to be checkout in src_unpack.
 The current default is tip, which identifies the most recent revision.
 This can lead to unwanted branch changes (see
 https://bugs.gentoo.org/show_bug.cgi?id=380947#c16) as the branch in
 which tip resides is not fixed.
 The new default should be default, which is mercurial's default name
 for the main branch.

 Looking at the packages using mercurial.eclass
 (http://qa-reports.gentoo.org/output/eclass-usage/mercurial.txt) the
 above change shouldn't cause any problems (some packages already use
 EHG_REVISION=default to avoid branch changes), but I will wait
 another week before committing the change.

 --
 Christoph Junghans
 http://dev.gentoo.org/~ottxor/


 Sounds good to me; using tip never made sense to me either.


+1

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



[gentoo-dev] Re: Packages up for grabs: prosody + lua deps

2012-11-26 Thread Rafael Goncalves Martins
On Mon, Nov 26, 2012 at 11:40 AM, Dirkjan Ochtman d...@gentoo.org wrote:

 I'd like to retire from these sometime soon:

 dev-lua/lua-zlib: no other maintainers/herd
 dev-lua/luadbi: no other maintainers/herd
 dev-lua/luaevent: blueness, rafaelmartins
 dev-lua/luaexpat: rafaelmartins
 dev-lua/luasec: rafaelmartins
 net-im/prosody: klausman, rafaelmartins

 AFAICT Rafael isn't very active these days. There shouldn't be that
 much immediate work except for bug 436648. Someone willing to take
 these off my hands?


Yeah, help is very appreciated! Feel free to add yourself as co-maintainer
of any of these packages that I'm listed as maintainer, and to ask
questions related to lua on IRC. I should be around, even if not very
active on package maintenance.

BR,

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


Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

2012-11-18 Thread Rafael Goncalves Martins
On Sun, Nov 18, 2012 at 11:38 AM, Kacper Kowalik xarthis...@gentoo.org wrote:
 On 18.11.2012 08:57, Greg KH wrote:
 On Sat, Nov 17, 2012 at 11:02:19PM -0800, Alec Warner wrote:
 1) systemd-udev will require systemd. Stated by the systemd
 maintainers themselves as a thing they want to do in the future. Some
 users don't want to use systemd. We could go into detail as to why;
 but I think that is not as important as one may think. The point is
 that the desire is there, and thusly there are users who want to make
 other systems (namely openrc) work.

 People like openrc. My VMs for instance, boot reasonably quickly.
 Booting 5 seconds faster may be super duper, but not at the cost of an
 existing reliable solution.

 So is this the goal?  Great, someone say that then, that's all I'm
 asking for here.

 That's wonderful, seriously.  But why is this suddenly an official
 Gentoo project?  When did that happen, and why?  Why not just do a
 normal project and if it matures and is good enough, then add it to
 the distro like all other packages are added.

 My main point here is the fact that this is now being seen as an act by
 Gentoo, the distro / foundation.  And that happened in private, without
 any anouncement.  Which is not good on many levels.

 I'm unsure on what grounds you disapprove. People start (and abandon)
 projects often in Gentoo. Suddenly you dislike one such project and
 object to this practice? Certainly if we had to get some sort of
 Foundation consensus (for anything) nothing would happen. We can't
 even get more than 40% of foundation members to vote.

 I object if this is seen as a Gentoo blessed fork of a community
 project that is worked on by all other major Linux distros.  That is the
 type of decision that can be made by the Gentoo Council, which is fine,
 but it sure would be nice if it were publicly stated, instead of having
 to see it on the Gentoo github site instead.

 Hi,
 I've seen this argument being repeated all over this thread and I'd like
 to clarify: http://github.com/gentoo (nor it's bitbucket.org
 counterpart) was never meant to host Gentoo blessed forks/projects and
 it *doesn't*.
 Sole purpose of it, was to encourage more contribution from users using
 web goodies like click a button to fork, since most of the people are
 very comfortable with github's workflow. We (gentoo-science team) have
 seen significant increase of interest since we've started using github.
 Cheers,
 Kacper

Hi,

Well, if yoiu fork a big community project, like udev, in a github
account called gentoo, people *will* think it is a Gentoo project.

If these organizations aren't governed by Gentoo they should have some
disclaimers, saying that the projects hosted there aren't sponsored by
Gentoo, but this udev-ng/eudev/whatever thing does the opposite and
actually advertise the Gentoo sponsorship with the sentence This is a
Gentoo sponsored project and testing is currently being done with
openrc. in their README

I don't think that someone can claim this sponsorship without a council vote.

I disagree with this fork, and tend to agree with what Greg and Diego
said before in this thread.

BR,

Rafael

 P.s. Just to emphasise it even more: There's a pornview fork there too.
 I don't recall Gentoo Council acknowledging it as default imageviewer.
 We should definitely put it into agenda. /reductio ad absurdum

You really want to compare pornview, that was dead and someone kindly
resurrected, with udev, that is actively maintained and the quality of
the fork is questionable? :(

 And if that is the decision of the council, I would expect the ability
 to have some type of discussion about it, wouldn't you?

 Also, the whole issue with the copyrights is very serious, for the
 reasons I've stated before.  Don't mess with copyrights, developers, and
 companies, take them very serious, as they are the basis for our
 licenses.

 thanks,

 greg k-h







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



Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

2012-11-18 Thread Rafael Goncalves Martins
On Sun, Nov 18, 2012 at 2:36 PM, Rich Freeman ri...@gentoo.org wrote:
 On Sun, Nov 18, 2012 at 11:14 AM, Rafael Goncalves Martins
 rafaelmart...@gentoo.org wrote:
 If these organizations aren't governed by Gentoo they should have some
 disclaimers, saying that the projects hosted there aren't sponsored by
 Gentoo, but this udev-ng/eudev/whatever thing does the opposite and
 actually advertise the Gentoo sponsorship with the sentence This is a
 Gentoo sponsored project and testing is currently being done with
 openrc. in their README

 I don't think that someone can claim this sponsorship without a council vote.


 Read GLEP 39.  Any dev can create a project.  Granted, most Gentoo
 projects don't follow the GLEP to the letter, and as long as nothing
 goes wrong it isn't a big problem. The council can step in if
 necessary, but having some source out on github won't kill anybody.

Yeah, but I think that there's a big difference about any developer
being allowed to create a project under the gentoo umbrella and create
a project and claim it as Gentoo sponsored without any review of the
council. I agree that it can exists in the Github account, or even in
our own infrastructure, but say that Gentoo supports it without a
previous analysis of the council is wrong IMHO.

 Keep in mind though that using github exclusively isn't exactly
 aligned with the social contract - I would encourage having the
 sources on Gentoo servers.  That said, I don't think it matters where
 people do the work vs what is the mirror - just nobody should be
 forced to use github (proprietary) to contribute.

 As long as everybody behaves Gentoo devs can work on whatever they
 want to.  None of us are paid to do this.

 If a bunch of strangers made the same claim I'd be more concerned.

 If anybody feels a Gentoo project is out of line feel free to submit a
 bug to the Council or Trustees as appropriate.  However, please save
 that for things like they're breaking the law or they refuse to
 have elections for a lead or whatever, and not I don't like what
 they're working on.  The recourse for the latter is to adjust your
 profile/USE-flags/killfile as appropriate.

 Rich


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



Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

2012-11-18 Thread Rafael Goncalves Martins
On Sun, Nov 18, 2012 at 3:32 PM, Rich Freeman ri...@gentoo.org wrote:
 On Sun, Nov 18, 2012 at 11:52 AM, Rafael Goncalves Martins
 rafaelmart...@gentoo.org wrote:
 Yeah, but I think that there's a big difference about any developer
 being allowed to create a project under the gentoo umbrella and create
 a project and claim it as Gentoo sponsored without any review of the
 council. I agree that it can exists in the Github account, or even in
 our own infrastructure, but say that Gentoo supports it without a
 previous analysis of the council is wrong IMHO.

 In practice there is no difference.  About the only sponsorship
 Gentoo projects get most of the time is hosting, and considering that
 they stuck this one on Github they're not really even getting that.

 That said, I see no reason why this project would be any less eligible
 for other forms of sponsorship than other projects are, assuming that
 somebody can make a compelling pitch for the Trustees.  The Foundation
 is aimed to further Gentoo in particular in FOSS in general, so
 obviously we don't spend a lot on individual projects.  When we do it
 tends to be in proportion to how it benefits the entire community, and
 I'm sure that community sentiments would be balanced accordingly.
 However, there aren't real projects and wanna-be projects in
 Gentoo.

 Rich


Hmm, pretty cool! Then I can create a stupid project, put it on gentoo
infra and claim it as being Gentoo sponsored. Good to know, thanks!

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



Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

2012-11-18 Thread Rafael Goncalves Martins
On Sun, Nov 18, 2012 at 3:37 PM, Rafael Goncalves Martins
rafaelmart...@gentoo.org wrote:
 On Sun, Nov 18, 2012 at 3:32 PM, Rich Freeman ri...@gentoo.org wrote:
 On Sun, Nov 18, 2012 at 11:52 AM, Rafael Goncalves Martins
 rafaelmart...@gentoo.org wrote:
 Yeah, but I think that there's a big difference about any developer
 being allowed to create a project under the gentoo umbrella and create
 a project and claim it as Gentoo sponsored without any review of the
 council. I agree that it can exists in the Github account, or even in
 our own infrastructure, but say that Gentoo supports it without a
 previous analysis of the council is wrong IMHO.

 In practice there is no difference.  About the only sponsorship
 Gentoo projects get most of the time is hosting, and considering that
 they stuck this one on Github they're not really even getting that.

 That said, I see no reason why this project would be any less eligible
 for other forms of sponsorship than other projects are, assuming that
 somebody can make a compelling pitch for the Trustees.  The Foundation
 is aimed to further Gentoo in particular in FOSS in general, so
 obviously we don't spend a lot on individual projects.  When we do it
 tends to be in proportion to how it benefits the entire community, and
 I'm sure that community sentiments would be balanced accordingly.
 However, there aren't real projects and wanna-be projects in
 Gentoo.

 Rich


 Hmm, pretty cool! Then I can create a stupid project, put it on gentoo
 infra and claim it as being Gentoo sponsored. Good to know, thanks!


Just to make it clear: I'm not saying that any of the people involved
with udev-ng/eudev/whatever, or even the project itself, is stupid. I
was just interpreting rich0's answer.

Do whatever you people want, I'll stop caring about this topic.

Best Regards,

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



Re: [gentoo-dev] Re: CIA replacement

2012-10-03 Thread Rafael Goncalves Martins
On Tue, Oct 2, 2012 at 9:21 PM, Jeroen Roovers j...@gentoo.org wrote:
 Responding to no one in particular, but to the sub-thread about IRC
 bots:

 On Tue, 2 Oct 2012 08:32:26 +0200
 Fabian Groffen grob...@gentoo.org wrote:

 On 02-10-2012 12:40:20 +0800, Ben de Groot wrote:
  The irker proxy was mentioned in this thread. I think we should look
  into this. Unless someone has a better idea.

 I think it might be more beneficial to try and relay -commits email to
 irc.

 An IRC bot is nice, but CIA also provided current (!) statistics, which
 isn't merely useful in order to boost your own morale/ego/self-esteem,
 but also provided up to date information about other developers'
 activity, which can help other developers decide if and when to step in
 and start (temporarily) maintaining packages that need immediate
 attention. ohloh cannot do that for us, presently, and a simple IRC
 bot cannot either.


Yeah, I miss the stats page too, but unfortunately I`m not aware of
anybody working on this feature. some people may list ohloh as a
replacement for CIA stats, but it is way behind the simplicity of the
CIA stats, and currently uses an almost always outdated git clone of
our cvs tree to gather the stats.

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



Re: [gentoo-dev] CIA replacement

2012-10-01 Thread Rafael Goncalves Martins
Hi Ben,

On Mon, Oct 1, 2012 at 5:14 AM, Ben de Groot yng...@gentoo.org wrote:
 Since CIA.vc is dead [1], I think we should be looking into a
 replacement service, or host our own [2].
 Is infra already looking into this?

 1: http://shadowm.rewound.net/blog/archives/245-CIA.vc-is-dead.html
 2: http://www.donarmstrong.com/posts/switching_to_kgb/

Maybe someone with good cvs knowledge can contribute a hook for irker
[1], so we can have #gentoo-commits flooding our irc clients again! :)

[1] http://www.catb.org/esr/irker/

Best regards.

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



Re: [gentoo-dev] CIA replacement

2012-10-01 Thread Rafael Goncalves Martins
On Mon, Oct 1, 2012 at 2:29 PM, Rich Freeman ri...@gentoo.org wrote:
 On Mon, Oct 1, 2012 at 11:21 AM, Rafael Goncalves Martins
 rafaelmart...@gentoo.org wrote:
 Maybe someone with good cvs knowledge can contribute a hook for irker
 [1], so we can have #gentoo-commits flooding our irc clients again! :)

 Why exactly are we still using cvs?  Rather than building enhancements
 for cvs, why not just migrate everything to git, and spend our time
 building the git hooks/etc necessary to make this work?

It is amazing how a simple thread about a quite simple topic, with an
easy solution, like this, turns to useless discussions about endless
topics, like this git conversion. This mailing-list is getting really
boring. :(

I'm not asking nobody to write any enhancement for cvs. irker is
already done, and working fine, but the authors just implemented
support for git and svn, because this is what they use. We *use* CVS
for now, then we would need to fix it to work with CVS, no matter if
we will have git repositories at some time. I stopped believing in
Santa Claus when I was 5 years old.

This should be doable with 10 lines of python, or using the cia-irker
proxy that jdhore mentioned in another email.

 Looking at the tracker [1], we need a pre-upload hook (I'm not quite
 sure why), an rsync conversion script, the ability to validate the
 converted tree, and documentation.  There is still an open bug for
 commit signing, and I'm not quite sure why as this was implemented.

Have you ever thought that people may be not really interested on this
move? or don't have the time to work on it? or don't care enough to
spend time on it? or just wants someone else to do the work?

If you want it, go ahead and push it, but in the right places, please.
I'm tired of bikeshedding here in this list. :(

[snip]

Best regards,

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



Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev

2012-06-23 Thread Rafael Goncalves Martins
On Fri, Jun 22, 2012 at 3:40 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 On Thu, 21 Jun 2012 23:01:15 +0200
 Michał Górny mgo...@gentoo.org wrote:
 Just a short note as it seems some confusion arises lately:

 Ciaran McCreesh is not a Gentoo dev and his words don't represent
 the position of Gentoo development team.

 Right. Doesn't that make me more important than you?

 https://lwn.net/Articles/501815/

 --
 Ciaran McCreesh

This thread is totally useless, but that lwn link made my day.

Thank you.

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



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

2012-05-23 Thread Rafael Goncalves Martins
-1


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



Re: [gentoo-dev] have portage be quiet by default

2011-11-12 Thread Rafael Goncalves Martins
On Sat, Nov 12, 2011 at 8:24 PM, Patrick Lauer patr...@gentoo.org wrote:
 On 11/11/11 16:44, Zac Medico wrote:

 good point.  we don't want to punish old portage users.  let's enable it
 by
 default in portage itself then.  just add `elog` output to the portage
 ebuild
 to inform users of the change ?  or do we want a news item ?

 what's the flag to negate the default ?  --no-quiet-build ? ;)
 -mike

 It's --quiet-build=n. I've gone ahead and enabled it for release in
 portage-2.1.10.34:


 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc174b6fc28feb26ea151d76f794e0ff2c2fa39

 Lots of people in #gentoo are unhappy with it.

 Most devs will be unhappy as it makes it harder to view the log while
 building.

 Please consider reverting it and let users set it with EMERGE_DEFAULT_OPTS
 if they want it less noisy.

+1


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



Re: [gentoo-dev] have portage be quiet by default

2011-11-12 Thread Rafael Goncalves Martins
On Sat, Nov 12, 2011 at 9:40 PM, Mike Frysinger vap...@gentoo.org wrote:
 On Saturday 12 November 2011 17:24:08 Patrick Lauer wrote:
 On 11/11/11 16:44, Zac Medico wrote:
  good point.  we don't want to punish old portage users.  let's enable it
  by default in portage itself then.  just add `elog` output to the
  portage ebuild to inform users of the change ?  or do we want a news
  item ?
 
  what's the flag to negate the default ?  --no-quiet-build ? ;)
 
  It's --quiet-build=n. I've gone ahead and enabled it for release in
  portage-2.1.10.34:
 
  http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc1
  74b6fc28feb26ea151d76f794e0ff2c2fa39

 Lots of people in #gentoo are unhappy with it.

 most changes people will be unhappy with because it's different

 Most devs will be unhappy as it makes it harder to view the log while
 building.

 devs are not the normal case.  it's trivial to have them use --quiet-build=n
 in their default emerge opts.

Then why not you and the other 2 guys that approved this change here
(and are the only people I saw approving this, TBH), add
--quiet-build=y to your default emerge opts and avoid this kind of
change?

Regards,

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



Re: [gentoo-dev] FEATURES=stricter as a default in developer profile not the best idea

2011-09-18 Thread Rafael Goncalves Martins
On Sat, Sep 17, 2011 at 9:42 PM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
 TLDR: Let's remove FEATURES=stricter from developer profile, I bet
 most people have it disabled anyway and it doesn't seem useful.


Really, I disabled it.

+1

Regards,

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



Re: [gentoo-portage-dev] [PATCH] Distfile Patching Support for Portage

2011-08-21 Thread Rafael Goncalves Martins
Patch reworked, after Zac's feedback on #-portage.

Attached.

-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/
From a12f837c20d3149f077737983bdfea23c8545abb Mon Sep 17 00:00:00 2001
From: Rafael G. Martins rafaelmart...@gentoo.org
Date: Sun, 21 Aug 2011 03:42:06 -0300
Subject: [PATCH] distpatch: basic implementation of distfile patching
 support.

This patch allows Portage to call the tools from app-portage/distpatch
to reconstruct distfiles from binary deltas and validate them.
---
 cnf/make.globals   |6 ++
 man/make.conf.5|   15 
 pym/portage/const.py   |6 +-
 pym/portage/dbapi/porttree.py  |   24 ++-
 pym/portage/package/ebuild/doebuild.py |3 +
 pym/portage/package/ebuild/fetch.py|  117 +++-
 6 files changed, 150 insertions(+), 21 deletions(-)

diff --git a/cnf/make.globals b/cnf/make.globals
index 2892d50..33b93fc 100644
--- a/cnf/make.globals
+++ b/cnf/make.globals
@@ -126,6 +126,12 @@ PORTAGE_ELOG_MAILFROM=portage@localhost
 # Signing command used by repoman
 PORTAGE_GPG_SIGNING_COMMAND=gpg --sign --clearsign --yes --default-key \\${PORTAGE_GPG_KEY}\ --homedir \\${PORTAGE_GPG_DIR}\ \\${FILE}\
 
+# URL for distpatch deltas root url
+PORTAGE_DELTAS_ROOT_URL=http://soc.dev.gentoo.org/~rafaelmartins/;
+
+# distpatch command, to fetch deltas (depends on app-portage/distpatch)
+PORTAGE_DISTPATCH_COMMAND=distpatcher --db \\${DELTADB}\ --root-url \\${ROOT_URL}\ --output \\${OUTPUT_DIR}\ --input \\${INPUT_DIR}\ --distfile \${VERBOSE} \\${FILE}\
+
 #*
 #**  DO NOT EDIT THIS FILE  **
 # ***
diff --git a/man/make.conf.5 b/man/make.conf.5
index d83258c..b19b38c 100644
--- a/man/make.conf.5
+++ b/man/make.conf.5
@@ -272,6 +272,11 @@ strangely configured Samba server (oplocks off, NFS re\-export). A tool
 /usr/lib/portage/bin/clean_locks exists to help handle lock issues
 when a problem arises (normally due to a crash or disconnect).
 .TP
+.B distpatch
+Enable experimental support to Distfile Patching. It depends on
+\fBapp-portage/distpatch\fR. Partially based on GLEP 25.
+See: \fIhttp://www.gentoo.org/proj/en/infrastructure/distpatch/\fR
+.TP
 .B ebuild\-locks
 Use locks to ensure that unsandboxed ebuild phases never execute
 concurrently. Also see \fIparallel\-install\fR.
@@ -652,6 +657,16 @@ matching files are excluded when the \fBPORTAGE_COMPRESS\fR command is
 called. Regular expressions are supported and the match is performed only
 against the portion of the file name which follows the last period character.
 .TP
+\fBPORTAGE_DELTAS_ROOT_URL\fR = \fIURL\fR
+This variable contains the URL used to fetch deltas to be used by the
+\fBdistpatch\fR feature.
+.TP
+.B PORTAGE_DISTPATCH_COMMAND
+This variable contains the command used for reconstruct distfiles from old
+distfiles and deltas. It must contain the executable as well as the
+place\-holders \\${DELTADB}, \\${ROOT_URL}, \\${OUTPUT_DIR}, \\${INPUT_DIR},
+\\${VERBOSE} and \\${FILE}.
+.TP
 .B PORTAGE_ELOG_CLASSES
 .TP
 .B PORTAGE_ELOG_SYSTEM
diff --git a/pym/portage/const.py b/pym/portage/const.py
index ecaa8f1..6b211f8 100644
--- a/pym/portage/const.py
+++ b/pym/portage/const.py
@@ -71,6 +71,8 @@ PRELINK_BINARY   = /usr/sbin/prelink
 INVALID_ENV_FILE = /etc/spork/is/not/valid/profile.env
 REPO_NAME_FILE   = repo_name
 REPO_NAME_LOC= profiles + / + REPO_NAME_FILE
+DELTADB_FILE = delta.db
+DELTAS_DIR   = deltas
 
 PORTAGE_PACKAGE_ATOM = sys-apps/portage
 LIBC_PACKAGE_ATOM= virtual/libc
@@ -89,8 +91,8 @@ SUPPORTED_FEATURES   = frozenset([
allow-missing-manifests,
assume-digests, binpkg-logs, buildpkg, buildsyspkg, candy,
ccache, chflags, collision-protect, compress-build-logs,
-   digest, distcc, distcc-pump, distlocks, ebuild-locks, fakeroot,
-   fail-clean, fixpackages, force-mirror, getbinpkg,
+   digest, distcc, distcc-pump, distlocks, distpatch, ebuild-locks,
+   fakeroot, fail-clean, fixpackages, force-mirror, getbinpkg,
installsources, keeptemp, keepwork, fixlafiles, lmirror,
metadata-transfer, mirror, multilib-strict, news,
noauto, noclean, nodoc, noinfo, noman,
diff --git a/pym/portage/dbapi/porttree.py b/pym/portage/dbapi/porttree.py
index bf8ecd9..75a5c8f 100644
--- a/pym/portage/dbapi/porttree.py
+++ b/pym/portage/dbapi/porttree.py
@@ -15,11 +15,13 @@ portage.proxy.lazyimport.lazyimport(globals(),
 	'portage.util:ensure_dirs,shlex_split,writemsg,writemsg_level',
 	'portage.util.listdir:listdir',
 	'portage.versions:best,catpkgsplit,_pkgsplit@pkgsplit,ver_regexp

Re: [gentoo-portage-dev] [PATCH] Distfile Patching Support for Portage

2011-08-21 Thread Rafael Goncalves Martins
On Sun, Aug 21, 2011 at 3:42 PM, Rafael Goncalves Martins
rafaelmart...@gentoo.org wrote:
 Patch reworked, after Zac's feedback on #-portage.

 Attached.


Re-sending. I forgot a print statement in the code. :(

Sorry.

-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/
From 3fe23a65638160c19abe991d9db6f023818c5395 Mon Sep 17 00:00:00 2001
From: Rafael G. Martins rafaelmart...@gentoo.org
Date: Sun, 21 Aug 2011 20:32:02 -0300
Subject: [PATCH] distpatch: basic implementation of distfile patching
 support.

This patch allows Portage to call the tools from app-portage/distpatch
to reconstruct distfiles from binary deltas and validate them.
---
 cnf/make.globals   |6 ++
 man/make.conf.5|   15 
 pym/portage/const.py   |6 +-
 pym/portage/dbapi/porttree.py  |   24 ++-
 pym/portage/package/ebuild/doebuild.py |3 +
 pym/portage/package/ebuild/fetch.py|  116 +++-
 6 files changed, 149 insertions(+), 21 deletions(-)

diff --git a/cnf/make.globals b/cnf/make.globals
index 2892d50..33b93fc 100644
--- a/cnf/make.globals
+++ b/cnf/make.globals
@@ -126,6 +126,12 @@ PORTAGE_ELOG_MAILFROM=portage@localhost
 # Signing command used by repoman
 PORTAGE_GPG_SIGNING_COMMAND=gpg --sign --clearsign --yes --default-key \\${PORTAGE_GPG_KEY}\ --homedir \\${PORTAGE_GPG_DIR}\ \\${FILE}\
 
+# URL for distpatch deltas root url
+PORTAGE_DELTAS_ROOT_URL=http://soc.dev.gentoo.org/~rafaelmartins/;
+
+# distpatch command, to fetch deltas (depends on app-portage/distpatch)
+PORTAGE_DISTPATCH_COMMAND=distpatcher --db \\${DELTADB}\ --root-url \\${ROOT_URL}\ --output \\${OUTPUT_DIR}\ --input \\${INPUT_DIR}\ --distfile \${VERBOSE} \\${FILE}\
+
 #*
 #**  DO NOT EDIT THIS FILE  **
 # ***
diff --git a/man/make.conf.5 b/man/make.conf.5
index d83258c..b19b38c 100644
--- a/man/make.conf.5
+++ b/man/make.conf.5
@@ -272,6 +272,11 @@ strangely configured Samba server (oplocks off, NFS re\-export). A tool
 /usr/lib/portage/bin/clean_locks exists to help handle lock issues
 when a problem arises (normally due to a crash or disconnect).
 .TP
+.B distpatch
+Enable experimental support to Distfile Patching. It depends on
+\fBapp-portage/distpatch\fR. Partially based on GLEP 25.
+See: \fIhttp://www.gentoo.org/proj/en/infrastructure/distpatch/\fR
+.TP
 .B ebuild\-locks
 Use locks to ensure that unsandboxed ebuild phases never execute
 concurrently. Also see \fIparallel\-install\fR.
@@ -652,6 +657,16 @@ matching files are excluded when the \fBPORTAGE_COMPRESS\fR command is
 called. Regular expressions are supported and the match is performed only
 against the portion of the file name which follows the last period character.
 .TP
+\fBPORTAGE_DELTAS_ROOT_URL\fR = \fIURL\fR
+This variable contains the URL used to fetch deltas to be used by the
+\fBdistpatch\fR feature.
+.TP
+.B PORTAGE_DISTPATCH_COMMAND
+This variable contains the command used for reconstruct distfiles from old
+distfiles and deltas. It must contain the executable as well as the
+place\-holders \\${DELTADB}, \\${ROOT_URL}, \\${OUTPUT_DIR}, \\${INPUT_DIR},
+\\${VERBOSE} and \\${FILE}.
+.TP
 .B PORTAGE_ELOG_CLASSES
 .TP
 .B PORTAGE_ELOG_SYSTEM
diff --git a/pym/portage/const.py b/pym/portage/const.py
index ecaa8f1..6b211f8 100644
--- a/pym/portage/const.py
+++ b/pym/portage/const.py
@@ -71,6 +71,8 @@ PRELINK_BINARY   = /usr/sbin/prelink
 INVALID_ENV_FILE = /etc/spork/is/not/valid/profile.env
 REPO_NAME_FILE   = repo_name
 REPO_NAME_LOC= profiles + / + REPO_NAME_FILE
+DELTADB_FILE = delta.db
+DELTAS_DIR   = deltas
 
 PORTAGE_PACKAGE_ATOM = sys-apps/portage
 LIBC_PACKAGE_ATOM= virtual/libc
@@ -89,8 +91,8 @@ SUPPORTED_FEATURES   = frozenset([
allow-missing-manifests,
assume-digests, binpkg-logs, buildpkg, buildsyspkg, candy,
ccache, chflags, collision-protect, compress-build-logs,
-   digest, distcc, distcc-pump, distlocks, ebuild-locks, fakeroot,
-   fail-clean, fixpackages, force-mirror, getbinpkg,
+   digest, distcc, distcc-pump, distlocks, distpatch, ebuild-locks,
+   fakeroot, fail-clean, fixpackages, force-mirror, getbinpkg,
installsources, keeptemp, keepwork, fixlafiles, lmirror,
metadata-transfer, mirror, multilib-strict, news,
noauto, noclean, nodoc, noinfo, noman,
diff --git a/pym/portage/dbapi/porttree.py b/pym/portage/dbapi/porttree.py
index bf8ecd9..75a5c8f 100644
--- a/pym/portage/dbapi/porttree.py
+++ b/pym/portage/dbapi/porttree.py
@@ -15,11 +15,13 @@ portage.proxy.lazyimport.lazyimport(globals

Re: [gentoo-dev] RFC: splitting virtual/

2011-08-15 Thread Rafael Goncalves Martins
On Mon, Aug 15, 2011 at 5:22 PM, Patrick Lauer patr...@gentoo.org wrote:
 On 08/15/11 21:55, Michał Górny wrote:
 On Mon, 15 Aug 2011 12:46:59 -0700
 Alec Warner anta...@gentoo.org wrote:

 On Mon, Aug 15, 2011 at 11:41 AM, Michał Górny mgo...@gentoo.org
 wrote:
 Hello,

 Now that we don't have any old-style virtuals in gx86 anymore,
 I think the 'virtual' category is basically one another plain
 category nowadays.

 Considering the number of different virtuals in this category,
 maybe it would be a good idea to split it a little? What I'm
 proposing is maybe creating some kind of '*-virtual' categories.

 For example, half of the current virtuals are prefixed with 'perl-'.
 Maybe they could be transformed into 'perl-virtual/*'?

 why?

 Because I like categories much more than I do prefixes.


 But right now all virtuals are easily recognizable and nicely grouped
 into one category. From my point of view that's the best categorization
 we could ask for ... what would we gain from changing it?


Nothing IMO.

+1 to keep virtuals as they are now.

Regards,

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



[gentoo-portage-dev] [PATCH] Distfile Patching Support for Portage

2011-08-11 Thread Rafael Goncalves Martins
Hi,

I'm sending attached a patch that does the basic implementation of
Distfile Patching Support for Portage. This is part of my GSoC project
[1].

It relies on the tools provided by app-portage/distpatch, commited to
the tree today, and is able to get an old tarball, plus a XZ
compressed binary delta and reconstruct the needed tarball, if a delta
is available.

You may find a few sample deltas and a delta.db in my public page in
soc.dev.gentoo.org [2]. More deltas will be available soon. These ones
are just for tests.

Basic steps to test: (be careful with the commands! :)

# echo 'DELTAS_ROOT_URL=http://soc.dev.gentoo.org/~rafaelmartins/;'
 /etc/make.conf
# echo 'FEATURES=${FEATURES} distpatch'  /etc/make.conf
# wget -O $(portageq distdir)/delta.db
http://soc.dev.gentoo.org/~rafaelmartins/delta.db
# emerge --fetchonly =grep-2.8
# rm $(portageq distdir)/grep-2.9.tar.xz
# emerge -av1 =grep-2.9

You'll see that the fetch size reported is pretty smaller than the
full tarball (80kB X 1MB). If you hit return, a delta will be fetched
and saved to $DISTDIR/deltas, the tarball will be reconstructed, the
checksums will be verified and the package will be installed. The
reconstructed tarball will be saved to $DISTDIR, if the checksums
match with the original tarball, ofrto $DISTDIR/delta-reconstructed,
if the checksums from compressed files unmatched but the checksums for
the uncompressed files matched. This is handled in a secure way by the
distpatch tools and the delta.db file.

Currently the delta.db file is fetched manually and placed in $DISTDIR
because we don't decided yet about how it will be shipped to users.
Probably through rsync, but we can't say this before have a real
deployment of the delta generators. This will require a little patch
soon.

This patch isn't obtrusive, and shouldn't affect any users with
FEATURES=-distpatch.

All the variable names can be changed, if wanted. I'm not very good at
choose names :)

That's it.

[1] - http://www.gentoo.org/proj/en/infrastructure/distpatch/
[2] - http://soc.dev.gentoo.org/~rafaelmartins/

Regards,

-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/
From 32e2626e849e221bace8c4150c82efb4170f6807 Mon Sep 17 00:00:00 2001
From: Rafael G. Martins rafaelmart...@gentoo.org
Date: Thu, 11 Aug 2011 04:25:57 -0300
Subject: [PATCH] distpatch: basic implementation of Distfile Patching
 Support.

This patch allows Portage to call the tools from app-portage/distpatch
to reconstruct distfiles from binary deltas and validate them.
---
 pym/portage/const.py   |6 +-
 pym/portage/dbapi/porttree.py  |   24 ++-
 pym/portage/package/ebuild/doebuild.py |3 +
 pym/portage/package/ebuild/fetch.py|  116 +++-
 4 files changed, 128 insertions(+), 21 deletions(-)

diff --git a/pym/portage/const.py b/pym/portage/const.py
index ecaa8f1..6b211f8 100644
--- a/pym/portage/const.py
+++ b/pym/portage/const.py
@@ -71,6 +71,8 @@ PRELINK_BINARY   = /usr/sbin/prelink
 INVALID_ENV_FILE = /etc/spork/is/not/valid/profile.env
 REPO_NAME_FILE   = repo_name
 REPO_NAME_LOC= profiles + / + REPO_NAME_FILE
+DELTADB_FILE = delta.db
+DELTAS_DIR   = deltas
 
 PORTAGE_PACKAGE_ATOM = sys-apps/portage
 LIBC_PACKAGE_ATOM= virtual/libc
@@ -89,8 +91,8 @@ SUPPORTED_FEATURES   = frozenset([
allow-missing-manifests,
assume-digests, binpkg-logs, buildpkg, buildsyspkg, candy,
ccache, chflags, collision-protect, compress-build-logs,
-   digest, distcc, distcc-pump, distlocks, ebuild-locks, fakeroot,
-   fail-clean, fixpackages, force-mirror, getbinpkg,
+   digest, distcc, distcc-pump, distlocks, distpatch, ebuild-locks,
+   fakeroot, fail-clean, fixpackages, force-mirror, getbinpkg,
installsources, keeptemp, keepwork, fixlafiles, lmirror,
metadata-transfer, mirror, multilib-strict, news,
noauto, noclean, nodoc, noinfo, noman,
diff --git a/pym/portage/dbapi/porttree.py b/pym/portage/dbapi/porttree.py
index bf8ecd9..e19adbf 100644
--- a/pym/portage/dbapi/porttree.py
+++ b/pym/portage/dbapi/porttree.py
@@ -15,11 +15,13 @@ portage.proxy.lazyimport.lazyimport(globals(),
 	'portage.util:ensure_dirs,shlex_split,writemsg,writemsg_level',
 	'portage.util.listdir:listdir',
 	'portage.versions:best,catpkgsplit,_pkgsplit@pkgsplit,ver_regexp',
+	'subprocess',
 )
 
 from portage.cache import metadata_overlay, volatile
 from portage.cache.cache_errors import CacheError
 from portage.cache.mappings import Mapping
+from portage.const import DELTADB_FILE, DELTAS_DIR
 from portage.dbapi import dbapi
 from portage.exception import PortageException, \
 	FileNotFound, InvalidAtom, InvalidDependString

Re: [gentoo-portage-dev] [PATCH] Distfile Patching Support for Portage

2011-08-11 Thread Rafael Goncalves Martins
On Thu, Aug 11, 2011 at 12:29 PM, Arfrever Frehtes Taifersar Arahesis
arfrever@gmail.com wrote:
 2011-08-11 10:12:04 Rafael Goncalves Martins napisał(a):
 +                                       except 
 subprocess.CalledProcessError, e:

 Please test your patch with all Python versions supported by Portage (at 
 least using runtests.sh).


Fixed. Tests ok.

New patch attached.

Thanks.

-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/
From 749c931c69c531f5a5ac41608c4e797c1f83bcd7 Mon Sep 17 00:00:00 2001
From: Rafael G. Martins rafaelmart...@gentoo.org
Date: Thu, 11 Aug 2011 04:25:57 -0300
Subject: [PATCH] distpatch: basic implementation of Distfile Patching
 Support.

This patch allows Portage to call the tools from app-portage/distpatch
to reconstruct distfiles from binary deltas and validate them.
---
 pym/portage/const.py   |6 +-
 pym/portage/dbapi/porttree.py  |   24 ++-
 pym/portage/package/ebuild/doebuild.py |3 +
 pym/portage/package/ebuild/fetch.py|  116 +++-
 4 files changed, 128 insertions(+), 21 deletions(-)

diff --git a/pym/portage/const.py b/pym/portage/const.py
index ecaa8f1..6b211f8 100644
--- a/pym/portage/const.py
+++ b/pym/portage/const.py
@@ -71,6 +71,8 @@ PRELINK_BINARY   = /usr/sbin/prelink
 INVALID_ENV_FILE = /etc/spork/is/not/valid/profile.env
 REPO_NAME_FILE   = repo_name
 REPO_NAME_LOC= profiles + / + REPO_NAME_FILE
+DELTADB_FILE = delta.db
+DELTAS_DIR   = deltas
 
 PORTAGE_PACKAGE_ATOM = sys-apps/portage
 LIBC_PACKAGE_ATOM= virtual/libc
@@ -89,8 +91,8 @@ SUPPORTED_FEATURES   = frozenset([
allow-missing-manifests,
assume-digests, binpkg-logs, buildpkg, buildsyspkg, candy,
ccache, chflags, collision-protect, compress-build-logs,
-   digest, distcc, distcc-pump, distlocks, ebuild-locks, fakeroot,
-   fail-clean, fixpackages, force-mirror, getbinpkg,
+   digest, distcc, distcc-pump, distlocks, distpatch, ebuild-locks,
+   fakeroot, fail-clean, fixpackages, force-mirror, getbinpkg,
installsources, keeptemp, keepwork, fixlafiles, lmirror,
metadata-transfer, mirror, multilib-strict, news,
noauto, noclean, nodoc, noinfo, noman,
diff --git a/pym/portage/dbapi/porttree.py b/pym/portage/dbapi/porttree.py
index bf8ecd9..75a5c8f 100644
--- a/pym/portage/dbapi/porttree.py
+++ b/pym/portage/dbapi/porttree.py
@@ -15,11 +15,13 @@ portage.proxy.lazyimport.lazyimport(globals(),
 	'portage.util:ensure_dirs,shlex_split,writemsg,writemsg_level',
 	'portage.util.listdir:listdir',
 	'portage.versions:best,catpkgsplit,_pkgsplit@pkgsplit,ver_regexp',
+	'subprocess',
 )
 
 from portage.cache import metadata_overlay, volatile
 from portage.cache.cache_errors import CacheError
 from portage.cache.mappings import Mapping
+from portage.const import DELTADB_FILE, DELTAS_DIR
 from portage.dbapi import dbapi
 from portage.exception import PortageException, \
 	FileNotFound, InvalidAtom, InvalidDependString, InvalidPackageName
@@ -588,7 +590,27 @@ class portdbapi(dbapi):
 		# into account? check checksums?
 		for myfile in myfiles:
 			try:
-fetch_size = int(checksums[myfile][size])
+if distpatch in self.settings.features:
+	try:
+		remaining_size = subprocess.check_output([
+			distpatchq,
+			delta_fetch_size,
+			os.path.join(self.settings[DISTDIR], DELTADB_FILE),
+			myfile,
+			self.settings[DISTDIR],
+			os.path.join(self.settings[DISTDIR], DELTAS_DIR),
+		], env=self.settings.environ())
+	except subprocess.CalledProcessError:
+		fetch_size = int(checksums[myfile][size])
+	else:
+		try:
+			filesdict[myfile] = int(remaining_size)
+		except ValueError:
+			fetch_size = int(checksums[myfile][size])
+		else:
+			continue
+else:
+	fetch_size = int(checksums[myfile][size])
 			except (KeyError, ValueError):
 if debug:
 	writemsg(_([bad digest]: missing %(file)s for %(pkg)s\n) % {file:myfile, pkg:mypkg})
diff --git a/pym/portage/package/ebuild/doebuild.py b/pym/portage/package/ebuild/doebuild.py
index a710e09..19963bb 100644
--- a/pym/portage/package/ebuild/doebuild.py
+++ b/pym/portage/package/ebuild/doebuild.py
@@ -1037,6 +1037,9 @@ def _prepare_fake_distdir(settings, alist):
 	for x in alist:
 		symlink_path = os.path.join(edpath, x)
 		target = os.path.join(orig_distdir, x)
+		reconstructed_target = os.path.join(orig_distdir, delta-reconstructed, x)
+		if distpatch in settings.features and os.path.exists(reconstructed_target):
+			target = reconstructed_target
 		try:
 			link_target = os.readlink(symlink_path)
 		except OSError:
diff --git a/pym/portage/package/ebuild/fetch.py

Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)

2011-07-27 Thread Rafael Goncalves Martins
On Wed, Jul 27, 2011 at 6:02 AM, Pacho Ramos pa...@gentoo.org wrote:
 El mié, 27-07-2011 a las 09:39 +0200, Michał Górny escribió:
 Hello,

 As many of us already raged, the Python eclasses are delaying half
 a year with support of EAPI=4. The reason for that is not actually
 the lack of time or complexity of needed changes but willingness to use
 the new EAPI as an excuse to turn the eclass API upside down.

 The question I'm raising here: should eclasses be actually allowed to
 do *heavy* changes in their APIs in such cases? Or should the eclass
 maintainers create a new eclass instead (python-r1.eclass or so)?

 The main advantage I see in that is that devs are somehow forced
 to migrate their ebuilds as soon as they bump EAPI in them. Taking
 a look at a number of ebuilds still using git.eclass (instead of git-2)
 this is a serious advantage.

 On the other hand, I find this idea very unclear. Why should two
 ebuilds use completely different eclass variables just because they're
 using two different EAPIs? More importantly, why is a dev forced to do
 the migration in a random point when he/she wants to bump the ebuild
 EAPI? I'd like to remind you that python eclass is still hard to read
 for many of us.

 And why do we have to wait so long to use a new EAPI? We already had to
 fix a lot of ebuilds when old EAPIs were banned in Python eclasses. We
 wanted to bump the ebuilds to EAPI 4 then but the eclasses didn't
 support it. And now it still doesn't come with EAPI 4 support.

 And keeping two different EAPIs in a single eclass file means probably
 that older EAPIs are going to be banned at a random point once again.
 Devs will have to pro-actively migrate their ebuilds, overlays will
 break and so on. The usual procedure related to eclass removal wouldn't
 apply.

 So, don't you think it would be better to simply add EAPI=4 support to
 python eclass with no changes and start developing the new API in
 python-r1? Devs could migrate then at any point they want (and have
 time to!), and when Python team wants to get rid of the old eclass,
 the usual removal procedure will apply.


 About the concrete case of python eclass, per Arfrever's comment in bug
 report related with its eapi4 support, that support is already available
 in overlay, but not yet merged to the tree (probably because of the
 possible upcoming retirement of Arfrever :-/). What is preventing python
 team to merge eclass from overlay?


AFAIK, the EAPI4 support in the overlay is EAPI 4-python, that almost
certainly will never come to gx86, and some guys are trying to port
the functionality to raw EAPI4, IIRC.

Regards,

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



Re: [gentoo-dev] Ohloh statistics updated

2011-07-27 Thread Rafael Goncalves Martins
On Mon, Jul 25, 2011 at 2:30 PM, Jeroen Roovers j...@gentoo.org wrote:
 [1] https://www.ohloh.net/p/gentoo
 [2]
 http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary

 It appears they count rather more commits than does CIA - Manifest
 commits look to be the likely cause.



Each user can setup an ignore list from the ohloh interface. don't
know if there's a way to ignore files project-side.

Regards,


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



[gentoo-dev] anion3 - an ion3 fork

2010-12-23 Thread Rafael Goncalves Martins
Hi all,

some of you may remember that almost all the Linux distributions had
problems with the ion3 (a famous tiling tabbed X11 window manager)
developer (Tuomo Valkonen) and his weird license clauses, that was
becoming impossible to maintain packages for ion3. Some time ago Tuomo
abandoned the development of ion3 and removed the problematic clauses
from the license, giving rise to some nice forks.

I'd like to add anion3 [1] to gentoo-x86, that's one of the forks,
licensed with GPL-2, according to its authors.

Objections?

[1] http://code.google.com/p/anion3/

Regards,.

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



Re: [gentoo-dev] Re: New category for Lua related packages

2010-11-05 Thread Rafael Goncalves Martins
Looks like the new category is created and the packages are moved!

If you have some issue with the pkgmoves, please reopen the tracker
bug,open a new bug and make the tracker depends on it.

Thanks guys! :)

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



Re: [gentoo-dev] New category for Lua related packages

2010-11-03 Thread Rafael Goncalves Martins
On Tue, Nov 2, 2010 at 1:11 PM, Donnie Berkholz dberkh...@gentoo.org wrote:
 On 08:09 Tue 02 Nov     , Paweł Hajdan, Jr. wrote:
 On 11/2/10 4:24 AM, Rafael Goncalves Martins wrote:
  I think that a first step should be create a new category, maybe
  called dev-lua, for all the Lua related stuff.

 Just checking: how many packages would be in the new category?

 In case anyone was wondering, I wanted to check how many packages
 typically showed up in a category. Here's a histogram of the
 distribution. The number of packages are in column 1, and the number of
 categories having that many packages are in column 2 (bin size 10,
 number shown ±5).

 To summarize, half the categories have 10-50 packages, then there are a
 number of huge ones. If you can get at least 15 packages, it's a
 reasonable starting point for a new category.

 5       5
 15      19
 25      15
 35      21
 45      14
 55      9
 65      7
 75      10
 85      9
 95      2
 105     7
 115     1
 125     4
 135     4
 145     1
 165     1
 185     4
 195     1
 205     1
 215     1
 225     1
 245     2
 255     1
 265     3
 295     2
 345     2
 355     2
 375     1
 485     1
 545     1
 985     1


Hi Donnie,

thanks for the stats.

I'm just wondering if it's worth add the packages now, before create
the new category, and have more packages to fix when creating the new
category.

Best regards,

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



[gentoo-dev] New category for Lua related packages

2010-11-01 Thread Rafael Goncalves Martins
Hi all,

as said in my blog post [1], I'm planing to improve our support to the
Lua [2] programming language, adding packages for the libraries and
the related software. Actually we already have some libraries on the
tree but they are spread in some categories like dev-lang and
dev-libs.

I think that a first step should be create a new category, maybe
called dev-lua, for all the Lua related stuff.

Are any of you against the creation of this new category?

[1] http://rafaelmartins.eng.br/en-us/post/lua-libraries-on-gentoo/
[2] http://www.lua.org/

Best regards,

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



Re: [gentoo-dev] Changes in server profiles

2010-10-29 Thread Rafael Goncalves Martins
On Fri, Oct 29, 2010 at 11:46 AM, Thomas Sachau to...@gentoo.org wrote:
 Am 29.10.2010 14:13, schrieb Petteri Räty:
 On 29.10.2010 15.02, Jorge Manuel B. S. Vicetto wrote:


 2) Furthermore I would like to drop the following use flags from default
 IUSE

 -apache2
 -ldap

 A minimal server installation does requires neither apache2 nor ldap

 Although one can install a server without apache or ldap, I'd say the
 server profile seems the natural choice to have them enabled.
 If we had the statistics for it, we could check how many people have
 apache installed with that profile vs not having it. As there's nothing
 preventing one from having USE=-apache2 -ldap when required and I
 don't use the server profiles, I don't really have a strong opinion
 about this.


 And enabling a use flag should be question of is it wanted when a
 package actually support those flags. On a server when you are
 installing a package with a apache use flag it's certainly possible to
 you would like to have it enabled more often than not.

 Regards,
 Petteri



 Which raises the question, if those people, who want to install a minimal 
 server will mostly use
 apache or something different. And especially for minimal setups, i dont 
 think that apache will be
 the first choice, so i agree with the removal of those USE flags from default 
 IUSE.
 The profile is intended to have a minimal set of flags, i would call apache 
 an additional optional
 flag, not a default option for minimal server setups.


Totally agreed!

Best regards.

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