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

[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

[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

[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 

Re: [gentoo-dev] Signed push & clock drift rejection

[Rafael Goncalves Martins]

On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko  wrote:
> Hi,
>
> On Fri, 15 Jul 2016 18:03:30 + Robin H. Johnson wrote:
>> Hi all,
>>
>> In tracing down problems with the git->rsync path, it has been noticed
>> that some developers have significant clock drift on their local systems
>> (up to one case of 14 days wrong), and it's potentially contributing to
>> problems in generating the rsync tree.
>>
>> I have implemented a check as part of the hook that validates Git push
>> certificates (require-signed-push). It looks for clock drift or an
>> overly long push, and aborts if needed.
>>
>> The tolerances are presently set to:
>> - 5 seconds of clock drift.
>
> Why such tight requirement? Why not a minute, which will not hurt
> git, but will help with system _temporarily_ out-of-sync.
>
> Some hardware clocks are real mess and can drift more that for 5
> seconds in a few days (e.g. when system was shut down). And for NTP
> it will take time to correct system clock _properly_. While stuff
> like running ntpdate before ntp server if system is out of sync is
> possible, but it is not recommended nor possible on some workloads.
> So IRL NTP may take several hours to sync system properly.
>
> Set it for a minute or two. This will protect from commits from
> really out-of-sync systems (like 14 days mentioned above) and will
> keep usablity hight for others.

I second this "request" :)

remote: Your system clock is off by 6 seconds (limit 5)

Regards,
Rafael

>> - 'git push' must be completed in 60 seconds.
>
> Why?! What is wrong if push will take 120 seconds? I often commit
> from quite an old box and git push takes 20-40 seconds, while this
> is within your limits, the margin is not safe.
>
> What if someone needs to commit via 2G GPRS or similar slow network
> link? Afaik we have developers on quite slow and unstable links.
>
> Just set this limit to 5 minutes to make it a sane protection of a
> stale push.
>
> Best regards,
> Andrew Savchenko



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

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

[Rafael Goncalves Martins]

# Rafael G. Martins  (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

[Rafael Goncalves Martins]

On Mon, Mar 9, 2015 at 2:27 AM, Robin H. Johnson  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

[Rafael Goncalves Martins]

On Sun, Mar 1, 2015 at 6:46 PM, Rafael Goncalves Martins
 wrote:
> On Sun, Mar 1, 2015 at 9:45 AM, Vadim A. Misbakh-Soloviov  
> 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

[Rafael Goncalves Martins]

On Sun, Mar 1, 2015 at 9:45 AM, Vadim A. Misbakh-Soloviov  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

[Rafael Goncalves Martins]

On Mon, Feb 16, 2015 at 11:19 AM, Mike Frysinger  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-dev] Packages up for grabs

[Rafael Goncalves Martins]

On Sun, Jun 16, 2013 at 6:49 AM, Pacho Ramos  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

[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  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

[Rafael Goncalves Martins]

On Tue, May 14, 2013 at 3:06 PM, Hans de Graaff  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

[Rafael Goncalves Martins]

On Mon, Apr 8, 2013 at 9:29 AM, Chí-Thanh Christopher Nguyễn
 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

[Rafael Goncalves Martins]

On Fri, Mar 22, 2013 at 8:15 PM, Markos Chandras  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> # Markos Chandras  (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

[Rafael Goncalves Martins]

# Rafael G. Martins  (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

[Rafael Goncalves Martins]

On Tue, Jan 22, 2013 at 10:57 PM, Brian Dolbec  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  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  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

[Rafael Goncalves Martins]

On Wed, Jan 2, 2013 at 10:11 AM, Samuli Suominen  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)

[Rafael Goncalves Martins]

On Tue, Dec 18, 2012 at 7:31 PM, Mike Gilbert  wrote:
> On Tue, Dec 18, 2012 at 4:10 PM, Christoph Junghans  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

[Rafael Goncalves Martins]

On Mon, Nov 26, 2012 at 11:40 AM, Dirkjan Ochtman  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)

[Rafael Goncalves Martins]

On Sun, Nov 18, 2012 at 3:37 PM, Rafael Goncalves Martins
 wrote:
> On Sun, Nov 18, 2012 at 3:32 PM, Rich Freeman  wrote:
>> On Sun, Nov 18, 2012 at 11:52 AM, Rafael Goncalves Martins
>>  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] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Rafael Goncalves Martins]

On Sun, Nov 18, 2012 at 3:32 PM, Rich Freeman  wrote:
> On Sun, Nov 18, 2012 at 11:52 AM, Rafael Goncalves Martins
>  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)

[Rafael Goncalves Martins]

On Sun, Nov 18, 2012 at 2:36 PM, Rich Freeman  wrote:
> On Sun, Nov 18, 2012 at 11:14 AM, Rafael Goncalves Martins
>  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)

[Rafael Goncalves Martins]

On Sun, Nov 18, 2012 at 11:38 AM, Kacper Kowalik  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. 

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] Re: CIA replacement

[Rafael Goncalves Martins]

On Tue, Oct 2, 2012 at 9:21 PM, Jeroen Roovers  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  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

[Rafael Goncalves Martins]

On Mon, Oct 1, 2012 at 2:29 PM, Rich Freeman  wrote:
> On Mon, Oct 1, 2012 at 11:21 AM, Rafael Goncalves Martins
>  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] CIA replacement

[Rafael Goncalves Martins]

Hi Ben,

On Mon, Oct 1, 2012 at 5:14 AM, Ben de Groot  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] A friendly reminder: Ciaran McCreesh is not a Gentoo dev

[Rafael Goncalves Martins]

On Fri, Jun 22, 2012 at 3:40 AM, Ciaran McCreesh
 wrote:
> On Thu, 21 Jun 2012 23:01:15 +0200
> Michał Górny  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

[Rafael Goncalves Martins]

-1


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

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

[Rafael Goncalves Martins]

On Sat, Nov 12, 2011 at 9:40 PM, Mike Frysinger  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] have portage be quiet by default

[Rafael Goncalves Martins]

On Sat, Nov 12, 2011 at 8:24 PM, 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 ? ;)
>>> -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] FEATURES="stricter" as a default in developer profile not the best idea

[Rafael Goncalves Martins]

On Sat, Sep 17, 2011 at 9:42 PM, "Paweł Hajdan, Jr."
 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-dev] RFC: splitting virtual/

[Rafael Goncalves Martins]

On Mon, Aug 15, 2011 at 5:22 PM, Patrick Lauer  wrote:
> On 08/15/11 21:55, Michał Górny wrote:
>> On Mon, 15 Aug 2011 12:46:59 -0700
>> Alec Warner  wrote:
>>
>>> On Mon, Aug 15, 2011 at 11:41 AM, Michał Górny 
>>> 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/

Re: [gentoo-dev] Ohloh statistics updated

[Rafael Goncalves Martins]

On Mon, Jul 25, 2011 at 2:30 PM, Jeroen Roovers  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/

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

[Rafael Goncalves Martins]

On Wed, Jul 27, 2011 at 6:02 AM, Pacho Ramos  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/

[gentoo-dev] anion3 - an ion3 fork

[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

[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] Re: New category for Lua related packages

[Rafael Goncalves Martins]

I've just created a tracker bug [1] and CC'd the affected maintainers.

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

Best regards,

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

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

[Rafael Goncalves Martins]

On Tue, Nov 2, 2010 at 1:11 PM, Donnie Berkholz  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/

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

[Rafael Goncalves Martins]

On Tue, Nov 2, 2010 at 5:09 AM, "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?
>

>From a quick search, the packages are:

dev-lang/luarocks
dev-lang/toluapp
dev-libs/luaevent-prosody
dev-libs/luaexpat
dev-libs/luafilesystem
dev-libs/luasec
dev-libs/luasocket
dev-util/luadoc

but as I'm planning to add more soon, should be good to fix this now,
when will be pretty easy to fix the reverse dependencies.

Best regards,

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

[gentoo-dev] New category for Lua related packages

[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

[Rafael Goncalves Martins]

On Fri, Oct 29, 2010 at 11:46 AM, Thomas Sachau  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/