On Mon, Sep 22, 2008 at 1:04 AM, Ulrich Mueller <[EMAIL PROTECTED]> wrote:
>
> > On Sun, 21 Sep 2008, Steve Long wrote:
>
> > Vaeth wrote:
> >> let me remark that the more clever way to this is
> >> [ -n "${DOCS}" ] && eval "dodoc ${DOCS}"
>
> > [...]
> > BASH arrays will cope with *any* charac
On Wed, May 20, 2009 at 5:01 AM, Ulrich Mueller wrote:
>
>
>${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
>${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
>
> With our current versioning scheme the rule is very simple: ${P} is
> split into ${PN} and ${PV} at the last hyphen. This can be done i
On Tue, Jun 9, 2009 at 12:57 PM, Benny Pedersen wrote:
>
> i like to use g-cpan more, but as lately it seems not to be so much stable
> with latest portage :/
>
> my question is how to make a bug on it or even if its worth doing it, is
> there a better proper way of make cpan modules into ebuilds
On Wed, Jun 10, 2009 at 11:40 AM, Benny Pedersen wrote:
>
>
> perl 5.8.8 no go
>
> dependse on Moose
>
dev-perl/Moose : Available in gentoo
dev-perl/MooseX-Getopt : Available in perl overlay
All other deps should be in there already.
( cant remember if -X functions can be chained or not in 5.8.
> # revdep-rebuild --library '/usr/lib/libv8.so.3.9.4' && \
> rm '/usr/lib/libv8.so.3.9.4'
Might even be worth patching revdep-rebuild:
revdep-rebuild --library /usr/lib/libv8.so.3.9.4 --autoclean
--
Kent
On 9 March 2012 06:30, Jeroen Roovers wrote:
> On Thu, 8 Mar 2012 17:14:58 +
> Ciaran McCreesh wrote:
>
>> Having a different, special rule for something that looks exactly like
>> lots of other things that do not have that different, special rule is
>> hardly hair splitting. This rule would
On 12 March 2012 15:20, Rich Freeman wrote:
> On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring wrote:
>> Pragmatic reality, the eapi function actually would work fine. As
>> pointed out elsewhere, bash parses as it goes- which isn't going to
>> change.
>
> Unless the ebuild isn't written in bash.
On 12 March 2012 15:24, Alec Warner wrote:
> I will stab the next person who suggests 'xml-like ebuilds.'
State-fully coded ebuilds, while perhaps not to your liking, for some
code-types can be incredibly useful.
For example, 9/10 perl-module ebuilds don't need any code at all in
the ebuild its
On 12 March 2012 20:08, Zac Medico wrote:
> On 03/11/2012 11:50 PM, Kent Fredric wrote:
>> #!/usr/bin/env eapi-xml-5
>>
>> would send the current file ( foo.ebuild ) to the process "eapi-xml-5"
>> ( as defined by the current $PATH setting )
>
> All
On 11 March 2012 22:09, Brian Dolbec wrote:
>
> eg:
>
> Channel #gentoo-guis on the freenode network
> or
> #gentoo-guis on the freenode IRC network,
> irc://irc.gentoo.org/gentoo-guis
>
Though a freeform text field is probably better for humans, I'd
suggest having more explicit data avail
On 12 March 2012 21:27, Michał Górny wrote:
> And we could just use a good regex for that instead.
>
> Something like: [eE][aA][pP][iI] [a-z0-9-+]+
>
> and just require users for this to be the first thing declared in
> an ebuild. Of course, this could make problems with stuff like:
>
> # EAPI 4
On 12 March 2012 22:09, Michał Górny wrote:
>> or as .
>
> No, definitely not. That's not the XML style.
Sure, but these examples are just examples after all. And XML is only
being used for an example use case, but there are many more
structured formats than XML.
Some of us are mostly just wor
On 12 March 2012 22:48, Ulrich Mueller wrote:
>>>>>> On Mon, 12 Mar 2012, Kent Fredric wrote:
> There's little danger if we require the EAPI specification to be in
> the first line of the ebuild. Of course the regexp should be general
> enough to account for a non
On 12 March 2012 22:37, Brian Harring wrote:
> Ebuilds *are* bash. There isn't ever going to be a PMS labeled
> xml format that is known as ebuilds... that's just pragmatic reality
> since such a beast is clearly a seperate format (thus trying to call
> it an 'ebuild' is dumb, confusing, and coun
On 13 March 2012 06:53, Ulrich Mueller wrote:
>
> There are very good reasons not to embed this information in the
> filename. That it makes the filename harder to parse for the human eye
> and more difficult to type is one of them.
>
> Besides, we already have a council decision about that GLEP.
On 13 March 2012 07:17, Ulrich Mueller wrote:
>
> Note the smiley in my posting. And yes, it _is_ ugly.
>
It may be ugly, but I'll take ugly over "doesn't work" and "serious
technical limitations" any day ;)
Binary executables are "ugly", you don't see many people complaining ;)
--
Kent
perl
On 13 March 2012 10:14, Ulrich Mueller wrote:
>> On Mon, 12 Mar 2012, James Broadhead wrote:
>
>> I'm sure that it's been considered already, but what are the arguments
>> against embedding the EAPI on a per-package (default) or per-version
>> basis in metadata.xml. It IS metadata after all.
>
On 13 March 2012 11:02, Mike Gilbert wrote:
>> The previous council's decision does not prevent this same glep from
>> going to the council again (decisions are not forever.)
>> Some folks seem to think that taking glep55 back to the council is not
>> allowed somehow (or is perhaps futile, but tha
On 13 March 2012 14:22, Joshua Kinard wrote:
> I thought this up on a whim, it hasn't been tested nor vetted. It's largely
> meant as a joke, but also to provoke discussion on the current filesystem
> design and the direction we're getting pulled in with Fedora's declaration
> that separate /usr
On 13 March 2012 17:31, Brian Harring wrote:
> Worse, it actually makes parsing _worse_ than it already is. What G55
> had going for it was ease of filtering out unsupported eapi's.
> Literally just filter the readdir results. This behemoth Zac is
> proposing basically requires throwing regex at
On 13 March 2012 19:41, Walter Dnes wrote:
> On Mon, Mar 12, 2012 at 05:12:28PM +, Ciaran McCreesh wrote
>
>> This whole thing is just an exercise in trying to find excuses not to
>> use GLEP 55.
>
> A filename should not be (ab)used as a database. The main argument for
> GLEP 55 is that it
On 15 March 2012 07:48, Duncan <1i5t5.dun...@cox.net> wrote:
> It does, especially when it's literally the case, including a /usr/etc
> bind-mounted on a tmpfs-based rootfs, that by login time, all that's
> visible of rootfs is mountpoints, nothing else, and /usr literally IS the
> "unified system
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
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 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 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 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 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 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
>
> /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: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.
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: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 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
>
> 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 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.
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
>
>
> ...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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: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 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
> 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 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
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
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 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
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 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
>
> 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
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
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
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 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 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 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 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 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 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 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 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 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 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.
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
1 - 100 of 875 matches
Mail list logo
