On 13 June 2013 13:35, Dennis Lan (dlan) wrote:
> HI ALL:
>Is it ok to introduce USE=dmalloc global flag? description as following
> "dmalloc - Enable debugging with the dmalloc library"
>
> current consumers:
> 1) net-fs/autofs
> 2) net-misc/directvnc
> 3) sci-biology/yass
>
> also
> 4)
On 3 May 2013 07:01, Fabio Erculiani wrote:
>
>
> If it's that simple, why on earth do we have all the eselect modules we
> have!?
>
>
Hm, upon reading that list and seeing what they do, it raises another
argument in favour of eselect:
If there needs to be more things changed prior to reboot tha
On 2 May 2013 16:21, Mike Frysinger wrote:
> On Wednesday 01 May 2013 21:24:07 Kent Fredric wrote:
>
> please do not top post
> -mike
>
My apologies, Gmail has forced upon us this new message composer, and it
sucks, it actively discourages bottom posting, and I'm st
On 2 May 2013 15:18, William Hubbs wrote:
> Like I've already said too, I don't see that we need to do this change.
>
> Systemd is called /usr/lib/systemd/systemd (it should be
> /lib/systemd/systemd), and sysvinit is called /sbin/init,, so I don't
> see the need for moving init around and creati
2 other classes of tests you may want to consider :
- network/internet accessibility required tests
- markers for tests that are known/expected to fail under many conditions
and are not worth end-user-testing, but end-users can force-running any way
if they really want to see the individual failur
On 22 February 2013 20:43, Diego Elio Pettenò wrote:
> On 22/02/2013 08:37, Kent Fredric wrote:
>> I'd make sure to add some sort of easy support to switch to
>> snapshotted tar.gz installs instead of live git checkouts, ie:
>>
>> GH_SNAPSHOT=deadbeef # use co
On 22 February 2013 19:53, Vadim A. Misbakh-Soloviov wrote:
> Hi there!
>
> Since we have tons of ebuild (including -) for software, that uses
> GitHub for sourcecode hosting — I've got an idea to write something
> like GitHub eclass, which will ease creating of such ebuilds (by
> providing "
> The key rotation as described in RiseUp best practices should be a very
> rare occurrence. Each dev is going to run it at most once.
>
Some material I read recommended doing a key rotation every 6 months,
which I did for a while until it got tiresome to perform the rotation.
I believe the ratio
It may be advantageous to have a gentoo wrapper script that calls GPG
with recommended settings to make some tasks easier,
> gentoo-gpg-create --recommended
> EDITOR=vim gentoo-gpg-rotation --recommended --old=DEADBEEF
and gentoo-gpg-rotation would make a templated key-expiry document ,
edited
On 2 January 2013 08:14, Vadim A. Misbakh-Soloviov wrote:
> Hi there!
> Long time ago I discovered that many language-specific packages
> (libraries, webapps) written on languages like PHP, Ruby, Lua and so on
> has (often) almost hardcoded dependence to be installed via their native
> package man
On 27 December 2012 13:32, Jeroen Roovers wrote:
>
> What you want to do is contact your mentor - that is the person who
> should be able to point out where to find the actual answer or just
> tell you what the answer is - the point of the quizes is to properly
> teach you how things work, not how
On 27 December 2012 05:39, Kent Fredric wrote:
> It could actually be just the Proxy Maintainer workflow is not clear enough,
> or simple enough, and that we need more push towards a more heavy
> proxy-maintainer based system ( I don't know, I'm ignorant to too much of
>
On 19/12/2012 10:03 p.m., Michał Górny wrote:
Doesn't this prove that the recruitment process fails to work?
If I were to throw random ideas, I'd think about letting new recruits
did all commits through a proxy (mentor?). Of course, it all would be
easier if we used git.
I know this side ques
The issue is basically, as you'll see in my comments on the updated
bug, Perl virtuals are not very trivial, and every perl release
results in a nightmare of fixes we have to apply to every Perl virtual
in tree, so we don't , at present, want more virtuals than necessary.
I'd personally love to ha
On 11 November 2012 00:27, aranea wrote:
>>
>
> It's been 3 months since I filed this bug, and one month ago I sent a
> reminder to the gentoo-perl ML. There haven't been any reactions. I
> also couldn't reach anyone on IRC. Is this herd dead or what?
https://en.wikipedia.org/wiki/Warnock%27s_Dil
On 15 September 2012 08:51, Rick "Zero_Chaos" Farina
wrote:
> ozzie eclass # grep 'DESCRIPTION="Based on the ' *.eclass
> cannadic.eclass:DESCRIPTION="Based on the $ECLASS eclass"
> confutils.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> embassy.eclass:DESCRIPTION="Based on the $ECLASS ecla
On 14 September 2012 10:17, Brian Harring wrote:
>> All you need is something in bash that can parse DEPENDENCIES and
>> populate *DEPEND , and the underlying guts could be done in
>> practically any language without requiring PM specific
>> implementations.
>
> You've got it inverted; if any auto
On 11 September 2012 14:16, Brian Harring wrote:
> On Fri, Sep 07, 2012 at 04:14:17PM -0400, Ian Stakenvicius wrote:
>> Is there anything in particular in the spec/proposal for DEPENDENCIES
>> that would exclude the addition of individual "build: app-cat/myatom"
>> "run: app-cat/myatom" deps by an
On 9 September 2012 15:53, Matthias Bethke wrote:
> I think Gentoo of all distributions should aim to provide software as
> "original" as possible. If there are any reasons that I have ignored so
> far why people would want the current behavior, how about I make this
> patch conditional on a new
On 8 August 2012 22:55, Duncan <1i5t5.dun...@cox.net> wrote:
> LOL! THAT's what it was! Along the same lines...
>
> ...senil emas eht gnolA !saw ti tahw s'TAHT !LOL
>
> http://www.textreverse.com/
>
> (While the link I had saved was stale it did mean I still remembered
> enough about it to plug
On 8 August 2012 01:58, Michał Górny wrote:
> I don't think that's possible. Much like with other kinds of updates,
> the packages in the tree would be updated to install in the new
> location anyway.
Sure, but the question is "when does this happen". Users are expecting
such changes when they em
On 7 August 2012 19:52, Michał Górny wrote:
> Hello,
>
> Right now, every time a bigger bunch of stuff (installed by various
> packages) needs to be moved around the filesystem, we have a lot of
> work to handle it somehow. And finally, users end up having to either
> rebuild a lot of packages to
I was goofing around trying to get current dev-vcs/git- building
by skipping the CVS patch ( which is applied with epatch ) and I had a
bizzare amount of time working out how to get it working.
Looking at the source of eutils.eclass ' # Let people filter things
dynamically ' suggests to me th
On 31 July 2012 05:33, Michael Orlitzky wrote:
> On 07/30/12 12:28, Michał Górny wrote:
>>
>> My point here is that you want the thing to change. So you first try to
>> convince people here to change. We practically did a small survey here
>> and in the result we didn't agree on doing the change.
On 26 July 2012 19:32, Michał Górny wrote:
> But you are aware that this is *upstream* naming?
>
> Similarly, ati-drivers (which is not upstream naming :P)
> and nvidia-drivers don't follow the suite.
I wasn't aware of that, but thats beside the point I was trying to
make. Its just a mechanism th
On 23 July 2012 08:48, Rick "Zero_Chaos" Farina wrote:
> A fair point, suggestion retracted. I'm on board with sys-firmware as
> well, but I do see some advantage of the current way of putting the
> firmware in the category of what it is for...
If you wanted, you could do something like x11-driv
On 22 July 2012 16:12, Doug Goldstein wrote:
> I've got a few ROMs to add to the tree and some which are already in
> the tree if people have a suggestion where they should live. Short
> list:
>
> ipxe
> openbios
> seabios
> sgabios
> vgabios
>
> --
> Doug Goldstein
>
I just noticed that the sys-
On 10 July 2012 13:28, Jeroen Roovers wrote:
> On Tue, 10 Jul 2012 00:04:15 +0200
> Agostino Sarubbo wrote:
>
>> I proposed to have an 'integration' between euscan and pybugz.
>
> Sounds superficially like a giant security hole / spam gateway. What
> kind of integration are we talking about?
>
>>
On 8 July 2012 00:38, Pacho Ramos wrote:
> After reading:
> https://bugs.gentoo.org/show_bug.cgi?id=424719
> https://bugs.gentoo.org/show_bug.cgi?id=397973
>
> Looks like there is not consensus about how to handle this cases,
> probably a PROPERTIES variable for this would help :-/
>
> Any ideas o
On 1 July 2012 05:12, Ian Stakenvicius wrote:
> Do all packages need to be rebuilt when some of these use flags
> change? Maybe auto-appending those particular flags (ithreads, debug)
> to IUSE and putting them on the dev-lang/perl dep is all that'll be
> needed, if this is the case.
Not all pa
On 4 July 2012 05:56, Ciaran McCreesh wrote:
>
> But whether or not a and b can be installed together sounds an awful
> lot like a property of a and b, not of c.
Its just when C is really something abstract, ( a virtual ) provided
by both possibly a & b, and b doesn't know a even exists till afte
On 4 July 2012 02:16, Michał Górny wrote:
> a) || ( a b ) should be || ( b a ), to actually state what perl does,
I don't really see how that would help much, if anything, I get the
impression that would
1) needlessly install "b" even when it could be satisfied by a instead
( ie: before both a &
On 4 July 2012 02:16, Michał Górny wrote:
>> I have thought of scrapping the virtuals entirely and handling it so
>> that things depend on perl-core/* instead, and perl-core can just
>> dynamically decide at install time whether or not it needs to no-op (
>> and sometimes perl-core/* will need to
On 3 July 2012 20:24, Michał Górny wrote:
>
> --depclean?
eix Module-Metadata
[I] perl-core/Module-Metadata
Available versions: ~1.0.3 ~1.0.4 ~1.0.5 1.0.6 ~1.0.9<---
not unmasked by --autounmask
Installed versions: 1.0.6(15:59:00 06/26/12)
Homepage:http://search.c
On 3 July 2012 19:08, Ciaran McCreesh wrote:
> On Tue, 3 Jul 2012 15:44:04 +1200
> Kent Fredric wrote:
>> Firstly, we already have a ^^( ) syntax for REQUIRED_USE , "one of,
>> but not more than one of".
>
> A user has a and b installed. c depends upon ^^ ( a
Firstly, we already have a ^^( ) syntax for REQUIRED_USE , "one of,
but not more than one of".
However, to my knowledge, we don't have such for ebuilds.
Sure, there are ways of implementing this in ebuilds without this
notation, but they're a bit messy.
For instance, we seem to find the need fo
>
> Perhaps it would be best to tell users that if they'd like to see the
> possible choices they can run ie 'qdepends -r virtual/cron'
>
Quite, perhaps it could be a seperate mechanism, it would just seem
that for virtuals that just provide a list of alternatives, having a
seperate package that g
On 30 June 2012 00:13, Corentin Chary wrote:
> It's already the case:
> https://github.com/iksaif/euscan/blob/master/pym/euscan/handlers/cpan.py
> but my mangling functions are probably broken in some cases. If
> somebody with a better knowledge of CPAN versionning scheme could fix
> them it woul
On 29 June 2012 17:32, Duncan <1i5t5.dun...@cox.net> wrote:
>
> EUSCAN_VERSION=0.71
>
> I don't know how difficult that would be for euscan to pickup on, but
> since this would have no bearing on actual package behavior, only on
> euscan, I'd guess it shouldn't require going thru the formal PMS pro
On 27 June 2012 19:51, Federico "fox" Scrinzi wrote:
> The main question is: what would you like to have on this dashboard?
> Currently (in the development version) there's the possibility to login
> and watch/unwatch packages/categories/herds/... and see the watched
> stuff in the account dashboa
I was doing a fresh Gentoo install today, following the manual, and it
appeared to me that the manual suggests to install a "logger" and a
"cron", and gives some defacto suggestions.
However, the available packages that provide this facility(s) are not
overly obvious from a portage standpoint.
Th
On 24 June 2012 05:16, Alec Warner wrote:
>>
>> That's covered in the devmanual and in the user documentation, so
>> there's no need to repeat it here.
>
> http://devmanual.gentoo.org/general-concepts/slotting/index.html
> http://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-d
On 3 June 2012 09:46, Robin H. Johnson wrote:
If there are enough "Alice" developers, is it a possibility that Bob
> will never have a chance to get his commit in?
>
> All this requires, is that in the time it takes Bob to do 'git pull',
> Alice manages to do 'git push' again.
>
> Alice can thus
> Only in your local history. The push to the central repo would only send
> the commits in the active chain to your branch HEAD.
Any commits that are rebased, and then replicated somewhere after that
rebase, will be stripped of their signatures by the rebase process.
--
Kent
perl -e "print
On 2 June 2012 04:33, Robin H. Johnson wrote:
> On Fri, Jun 01, 2012 at 10:45:48AM -0500, William Hubbs wrote:
>> Overlays are completely separate repositories. There is nothing stopping
>> an overlay from using git right now even if the main tree isn't using
>> git. They just work in their git re
On 2 June 2012 03:53, Rich Freeman wrote:
> git-rebase is just a shell script, that ultimately just calls
> git-commit as far as I can see, which means that implementing
> re-signing is just a matter of adding the appropriate parameters, or
> use default configuration (assuming it doesn't already
On 2 June 2012 03:39, Rich Freeman wrote:
> On Fri, Jun 1, 2012 at 9:25 AM, Nicolas Sebrecht wrote:
>> So, like explained before your concern is clearly out of the current
>> discussion. Importing commit history from Overlays is not supported and
>> will probably never be. Gentoo doesn't forces (
On 2 June 2012 03:12, Andreas K. Huettel wrote:
>> "git cat-file -p $sha" is as close as you can get to commit objects
>> without needing to write your own decompressing wrapper. But it gives
>> the same results.
>
> Now, does the "signed data" also contain the parent sha?
>
> If yes, our discuss
On 2 June 2012 00:42, Rich Freeman wrote:
> On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric wrote:
>>
>> Nope, at least not as far as I can tell, and I just implemented commit
>> signature verification >_>
>
> I've been trying to find an example of a signed com
On 1 June 2012 22:54, Rich Freeman wrote:
> On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric wrote:
>>
>> Hmm, thats annoying. Almost makes me wish it was the trees that were
>> signed, not the commits.
>
> I think it is the tree that is signed, but that changes too.
Nop
On 1 June 2012 20:16, Dirkjan Ochtman wrote:
> Can you elaborate on why the cleaner history a no-merge policy
> enforces is a good thing? I actually think that seeing merge commits
> might clarify the history; it can be valuable to see that some mistake
> was made in a merge instead, but you can o
On 1 June 2012 14:49, Rich Freeman wrote:
> On Thu, May 31, 2012 at 5:52 PM, Kent Fredric wrote:
>> Just I haven't worked out what happens when the SHA1 of the 'parent'
>> header changes, which *will* change if the rebase is anything other
>> than a fast-forw
On 1 June 2012 08:26, Duncan <1i5t5.dun...@cox.net> wrote:
> William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted:
> Of course, if all the official overlays are converted to git branches of
> the main tree... but won't they still require rebasing as they've already
> been pushed? (
On 1 June 2012 07:58, Rich Freeman wrote:
> On Thu, May 31, 2012 at 3:33 PM, Michał Górny wrote:
>> What would git signing work with rebased commits? Would all of them
>> have to be signed once again?
>>
>
> The whole point of rebasing is to throw away history (which is either
> good or bad based
On 1 June 2012 07:52, Alexey Shvetsov wrote:
>>
>> What would git signing work with rebased commits? Would all of them
>> have to be signed once again?
>
>
> Commits itsels still will be signed
Do you know how git does this? Do you have experience/information you
can cite as to that this works?
On 25 May 2012 20:52, Grant wrote:
> I switched local-lib from the g-cpan one to the perl-experimental one
> and all is well as far as installation all the way through
> Net-Braintree. Thank you very much for sticking with me on this guys.
>
> May I ask why you force the g-cpan category to dev-pe
On 25 May 2012 18:16, Grant wrote:
>
> That did it, but there's more trouble. g-cpan strikes again?
>
Configuring source in
/var/tmp/portage/dev-perl/local-lib-1.008004/work/local-lib-1.008004 ...
For local-lib, you're best trying using the copy in the
perl-experimental overlay. If
On 25 May 2012 18:12, Ulrich Mueller wrote:
>
> Actually, Alec's question is not so far-fetched. The Gentoo Social
> Contract says that Gentoo will never depend upon a piece of software
> unless it is open source.
>
Though in the case of github, gentoo is not "depending upon it".
Github could die
On 25 May 2012 13:21, Alec Warner wrote:
>
> So I'm a bit confused. Is GitHub open source?
>
Your confusion begets more confusion:
Whether or not Github is open-source seems orthogonal to whether or
not we use it, as github is a website, a service, and there are a few
such websites, of which, git
On 25 May 2012 09:14, Alexey Shvetsov wrote:
> In gentoo git tree all git commits will be signed by commiter gpg keys (and
> this will be requerd!)
>
> Aaron W. Swenson писал 2012-05-25 00:00:
Something that still confuses me about commit signing that I haven't
seen answered: How does a signed co
On 25 May 2012 09:00, Aaron W. Swenson wrote:
> I do believe git pull-requests should go through Bugzilla. A
> pull-request is the equivalent to bump requests, patch fixes, and all
> sorts of stuff that we already handle through Bugzilla. Bugzilla also
> contains our history.
+1
>
> If they hap
On 25 May 2012 08:28, Zac Medico wrote:
>
> I expect that reading and validating the cache is probably not going to
> be much faster than just parsing the eclasses over again.
> --
Unless, you don't care if the cache is out-dated because the cache is
optional / the syntax checking is optional, an
On 25 May 2012 07:47, Mike Frysinger wrote:
> -mike
Were it me, I'd have a tool that scrapes the eclass files's
documentation and emits a .json file which repoman can then optionally
use for consistency checks.
Mostly because I don't like the idea of repoman re-probing all the
eclasses every tim
On 25 May 2012 07:22, Grant wrote:
>
> EAPI="2"
>
> MODULE_AUTHOR="IKEGAMI"
>
> inherit perl-module
>
> DESCRIPTION="Parse and format RFC3339 datetime strings"
>
> LICENSE="|| ( Artistic GPL-1 GPL-2 GPL-3 )"
> SLOT="0"
add this:
MODULE_VERSION="v${PV}"
just before the inherit line and that *sho
>
>
> ...is this something we (as the developer base) WANT non-dev's to be
> able to do?? I would expect we'd want the tree to still be treated as
> read-only-not-modifyable by the rest of the gentoo/linux community,
> otherwise we're going to have a rather large mess on our hands
> (multiple fork
On 25 May 2012 03:05, Grant wrote:
> DateTime-Format-RFC3339
Ah. The dreaded v-strings.
You'll note: http://cpan.metacpan.org/authors/id/I/IK/IKEGAMI/
That there is a "v" before the version specifier in the problem dist,
and the portage ebuild has not factored this into the equation, and is
loo
On 25 May 2012 03:02, Ralph Sennhauser wrote:
> On Thu, 24 May 2012 16:40:02 +0200
> Michał Górny wrote:
>
>> d) Talk with github folks to add our repo as 'mirror'.
>
> Can we keep the master on Gentoo hardware please.
Definitely. But having a mirror on github will increase forkability,
and wil
On 25 May 2012 00:05, Dirkjan Ochtman wrote:
> On Thu, May 24, 2012 at 1:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> In that regard, git is nothing like for instance svn, where branches come
>> at a much higher cost, as does merging between them.
>
> That's wrong. SVN branches are just about as
On 21 May 2012 04:26, Michał Górny wrote:
> Hello,
>
> In today's MythBusters™: do we actually need the whole ugly-awful
> mangling games.eclass does for games? By that I mean:
> - installing games in random pre-/postfixes rather than standard FHS-y
> locations,
> - changing ownership and permiss
On 24 May 2012 19:01, Grant wrote:
> I've never had very good luck with g-cpan. I thought there were a lot
> of dev-perl ebuilds in portage for CPAN modules and that g-cpan was
> for those that hadn't been added to portage yet?
Yes, to an extent. Also, if you haven't already, check out the
perl-
On 24 May 2012 19:01, Grant wrote:
Verifying ebuild manifests
> !!! A file is not listed in the Manifest:
> '/usr/local/portage/dev-perl/DateTime-Format-RFC3339/DateTime-Format-RFC3339-1.0.5.ebuild'
> !!! A file is not listed in the Manifest:
> '/usr/local/portage/dev-perl/DateTime-Format-Ato
On 24 May 2012 09:48, Michael Weber wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 05/23/2012 11:14 PM, Dan Douglas wrote:
>> On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote:
>>> 2. rsync generation is NOT going away. Users will still be using
>>> it.
>
> First, I'
On 24 May 2012 08:32, Rich Freeman wrote:
>
> Sure. The slow commit rate encourages careful deliberation before
> hitting the enter key, which therefore improves quality.
>
> Then, if you do make a mistake the slow commit rate means that fixing
> that mistake can take a long time, which increases
On 24 May 2012 05:35, Alexey Shvetsov wrote:
> Full clone will be about 1G or so but no more then 2. If we will drop
> changelog it will be much smaller
>
And if you use git commit signing instead of ebuild manifests,
intra-commit churn will almost be negligible. :D
--
Kent
perl -e "print su
On 13 May 2012 07:43, Torsten Veller wrote:
> * Corentin Chary :
>> On Sat, Apr 21, 2012 at 03:33:18PM +1200, Kent Fredric wrote:
>> > { "term": { "status":"latest"} },
>> >
On 13 May 2012 07:43, Torsten Veller wrote:
> * Corentin Chary :
>> On Sat, Apr 21, 2012 at 03:33:18PM +1200, Kent Fredric wrote:
>> > { "term": { "status":"latest"} },
>> >
On 10 May 2012 21:39, Ulrich Mueller wrote:
>. Are there any other licenses
> besides *GPL and FDL that would require such a file?
I'd welcome groups so we can have a "Perl_5" group. The lions share of
modules published on CPAN are licensed "Under the same license as Perl
5 Itself", which implies
On 21 April 2012 08:33, Corentin Chary wrote:
> On Fri, Apr 20, 2012 at 9:35 PM, Kent Fredric wrote:
>> On 21 April 2012 01:34, Corentin Chary wrote:
>>> Yeah, not very important, but seems to work with this patch:
>>> https://github.com/ik
On 21 April 2012 01:34, Corentin Chary wrote:
> Yeah, not very important, but seems to work with this patch:
> https://github.com/iksaif/portage-janitor/commit/972aff94744741e34e99f917337430d245883c48
>
> Example:
> $ python remoteids.py --diff WWW-Bugzilla Moose bioperl
> --- a/dev-perl/WWW-Bugzi
On 20 April 2012 23:21, Corentin Chary wrote:
>
> Currently it uses SRC_URI and HOMEPAGE, but honestly it wouldn't be
> hard to use any other environment variable and to do some checks on a
> webservice.
> Anyway for tricky cases it can still be done by hand.
>
> --
> Corentin Chary
> http://xf.ik
On 20 April 2012 19:46, Corentin Chary wrote:
> On Fri, Apr 20, 2012 at 9:37 AM, Kent Fredric wrote:
>> On 20 April 2012 03:31, Corentin Chary wrote:
>>> Add rubygems, github, gitorious, pecl, pear, bitbucket.
>>> All of them are handled by my remoteids.py
On 20 April 2012 03:31, Corentin Chary wrote:
> Add rubygems, github, gitorious, pecl, pear, bitbucket.
> All of them are handled by my remoteids.py script.
>
> ref: https://bugs.gentoo.org/show_bug.cgi?id=406287
> ref: https://github.com/iksaif/portage-janitor/blob/master/remoteids.py
>
> --- a/m
On 30 March 2012 17:08, Walter Dnes wrote:
> in the install handbook gives "/usr/local/portage" as an example overlay
> directory. I thought it was implicit that one shouldn't edit or create
> files in /usr/portage because they may be overwritten by the system e.g.
> during an "emerge --sync".
On 29 March 2012 08:21, Aaron W. Swenson wrote:
>
>
> 'Support' is the keyword here. The repositories are regenerated given
> machinesan 'emerge --sync' and can be considered as temporary as the
> packages themselves are impermanent. Further, the repository isn't
> required to persist. If somebod
On 29 March 2012 07:43, Aaron W. Swenson wrote:
> So, we're all getting way off topic and discussing reorganizing the
> whole enchilada.
>
> How about we all agree or disagree on the primary point: The Portage
> tree doesn't belong in /usr.
>
+1
> I believe that it does belong under /var/cache
On 28 March 2012 20:16, Brian Dolbec wrote:
> On Tue, 2012-03-27 at 19:16 +0100, Ciaran McCreesh wrote:
>> But that's ok, because extensive studies have shown that the only
possible
>> reasons for putting /usr/portage on its own partition are historical,
>> since everyone has an SSD now.
>>
>
> Ye
On 28 March 2012 23:04, Piotr Szymaniak wrote:
> Just use categories from repos?
>
> /usr/portage/distfiles/sys-devel/gcc-1.2.tar.bz2
> /usr/portage/distfiles/sys-libs/glibc-2.3.tar.bz2
> /usr/portage/distfiles/sys-libs/zlib-3.4.tar.bz2
> /usr/portage/distfiles/zomg-soft/zomgawesomesoft-5.3.1.tar.
>
> Just use categories from repos?
>
> /usr/portage/distfiles/sys-devel/gcc-1.2.tar.bz2
> /usr/portage/distfiles/sys-libs/glibc-2.3.tar.bz2
> /usr/portage/distfiles/sys-libs/zlib-3.4.tar.bz2
> /usr/portage/distfiles/zomg-soft/zomgawesomesoft-5.3.1.tar.xz
> (from zomg repo with custom zomg-soft cat
On 28 March 2012 20:46, Alex Alexander wrote:
> For example, my /usr/portage/ on this system looks like this:
>
> portage/
> tree/
> profiles/ -> tree/profiles/
> distfiles/
> packages/
> layman/
>
> it is a big improvement over the current
> distfiles-and-packag
On 28 March 2012 08:57, Richard Yao wrote:
>
> Could we amend this to also include the benefits of ZFS and why you
> would want to use XFS or reiserfs instead of ext{2,3,4} as your
> filesystem in situations where ZFS is not yet appropriate (e.g. using it
> on Gentoo stable)? We could also include
On 28 March 2012 08:59, William Hubbs wrote:
> What I was wanting to discuss mainly was that /usr/portage isn't right;
> I think we need to move that out of the /usr directory.
>
> I'm not sure what the new default should be, nor how the default should
> be decided. Maybe we just let Zac pick one?
On 28 March 2012 08:47, Alec Warner wrote:
> The gentoo-x86 ebuild tree is not necessarily portage related.
> However I think we should paint the bike shed '/srv/tree'
I for one never developed any love for /srv , its always seemed like
an unwanted bit of poo left behind by an unloved gremlin.
>
> /var/cache/repositories/gentoo/*
> /var/cache/repositories/perl-experimental/*
> /var/cache/distfiles/*
> /var/cache/packages/*
>
Actually, now I think of it, repositories /might/ be suitable for
being under /db/
the repository does sort of function like a database, the tools we use
to access
On 28 March 2012 08:05, William Hubbs wrote:
> All,
>
> I know this has come up before, but I don't really recall what the
> specific objections were.
>
> IMO the portage directory doesn't belong under /usr at all.
> I was chatting with another developer who uses
> /var/cache/portage/{tree,distfil
On 28 March 2012 08:15, Sven Vermeulen wrote:
>> Then again, Gentoo is about choice. It just seems like we're
>> presenting users with more choices than makes sense for a newbie. If
>> there is a choice between something that 99.99% of users will want,
>> and some ancient piece of cruft that sti
On 28 March 2012 07:53, Ian Stakenvicius wrote:
> You know, we have "Code Listing 2.1: Filesystem Example" in Section 4,
> we could always adjust that to have a /usr/portage partition in it
> (take a bit of space away from /home, or something)
>
> It doesn't recommend/require anything, but when us
On 22 March 2012 03:18, Justin wrote:
> Hi,
>
> I need some comments on following License Agreement:
>
> http://fizz.cmp.uea.ac.uk/dyndom/dyndomDownload.do
>
> QUOTE
>
> In downloading this code you agree with the following:
>
> I will not redistribute the software to others outside of my immediat
On 19 March 2012 14:12, Steven J Long wrote:
>
> As for non-bash ebuilds, I have always agreed with antarus that they should
> simply use a different extension. Adding a new extension per source language
> is a *lot* cleaner than one per EAPI.
Ok: If we take this notion and enshrine it in stone:
On 18 March 2012 08:33, Matt Turner wrote:
> So you run set FEATURES=test to run a package's test suite during
> keywording. Later, you emerge -vuNDa ... and portage wants to reemerge
> that package with USE=-test.
>
> Can't we avoid this somehow? I presume in the vast majority of cases
> emerging
On 17 March 2012 01:05, Christoph Niethammer
wrote:
> Hello.
quse -D amd64 consolekit declarative gdu kipi mudflap nptlonly pango
phonon pppd qt3support sysfs xorg
arch:amd64: amd64 architecture
local:consolekit:app-emulation/spice-vdagent: Use sys-auth/consolekit
to determine the master vd
701 - 800 of 875 matches
Mail list logo
