On Fri, 25 Nov 2016 14:40:36 +0800
Jason Zaman wrote:
> One way would be to use a plain text attachment with a standardized
> filename. If there are updates to the list then the new should obsolete
> the old and the script can pull non-obsoleted ones.
> The problem then is how do you search for t
On Fri, 25 Nov 2016 20:05:55 +1100
Michael Palimaka wrote:
> I'm not sure what you mean. A standardised format and a bot to repoman
> check lists in this format is part of my original post.
Ah. I didn't take enough care reading it and mostly replied on the earlier part.
Good to see we reached s
On Sat, 26 Nov 2016 17:32:02 -0600
William Hubbs wrote:
> Listing the architectures seems redundant if they are also in the cc:
> field. In your example above, why would you need arm in the cc: field
> for app-foo/bas-2.3.4?
Often, the required work for "lists of keywords/stabilizations" has
i
On Sat, 3 Dec 2016 08:14:26 +0100
Ulrich Mueller wrote:
> The ebuild has to be written only once, while users will type the
> package name many times.
An ebuild will require maintaining 10x the number of times
users need to specify the cat/pn of that package.
An ebuild will also need depending
On Sat, 3 Dec 2016 15:06:36 +
Markos Chandras wrote:
> That's reasonable but I also think that bumping and fixing an ebuild at
> the same time can be considered an atomic change since it's effectively
> a _new_ ebuild
One problem is that can seriously confuse git about what's happening,
give
On Thu, 1 Dec 2016 02:30:20 +0300
Andrew Savchenko wrote:
> Error 404 here.
https://marc.info/?l=gentoo-dev&m=147974883628079&w=2
FYI, the file's removed now as I've found out that we already have
an LDAP field for that. So if you're not on Gentoo developers team on
GitHub, please set it:
p
On Thu, 1 Dec 2016 14:53:51 +0800
konsolebox wrote:
> I got similar idea here, but my version is that you don't have to use
> u: or v:
The entire point of defining it as a prefix-space was to avoid ambiguity,
and leave plenty of room for other such selector prefixes.
Relying on properties like
On Mon, 5 Dec 2016 01:21:34 +0800
konsolebox wrote:
> Well that's just it: ease of use and simplicity vs. portability with
> possible new parameter types in the future; your pick. I'll
> personally go for the former this time.
>
> Also, what kind of added type of parameters would you expect tha
On Sun, 18 Dec 2016 21:08:09 -0500
Michael Orlitzky wrote:
> dev-php/ca-bundle20161124-07:43 mjo[1] 7597666
> dev-php/cli-prompt 20161124-07:21 mjo[1] d3bd351
> dev-php/composer 20161124-08:09 mjo[1] d273046
> ...
>
>
On Tue, 20 Dec 2016 23:57:10 +0100
Jonas Stein wrote:
> The shutdown is in two weeks.
> One can see clearly a drop of broken ebuilds after the first mail on the
> mailinglist and after the personal mail on 2016-11-24. [1] Thank you all
> for fixing so many ebuilds already.
> But still 400 ebuilds
On Sun, 25 Dec 2016 13:41:29 +0100
Agostino Sarubbo wrote:
> NOTE: I'm intending this message as a sort of announcement to invite everyone
> to port their stable requests. I guess there isn't much to discuss here. If
> you don't like some of the changes that have been done, please open a
> spe
On Sun, 25 Dec 2016 22:55:27 +0300
Andrew Savchenko wrote:
>
> Description how to test this package...
>
Alternatively, why not have a metatag that just
permits a valid URL that points to testing instructions?
Benefits:
* Multiple packages can share instructions without redundancy
* Edits
On Sun, 25 Dec 2016 23:32:56 +0900
Aaron Bauman wrote:
> It is not necessary to use a file now. Just put the list in the "Atoms to
> stabilize" as described.
Well, to an extent it was more a problem I feel the *need* to use this feature
already ;)
Because I have some stuff that bumps into ut
On Wed, 28 Dec 2016 21:11:43 +0100
Ulrich Mueller wrote:
> PMS uses "package dependency specification", but that may be too long
> for the name of the field. How about "ebuilds to stabilise"?
>
> Ulrich
Reading "man 5 ebuild"
Atom Bases
The base atom is just a full category/pa
On Thu, 29 Dec 2016 17:23:58 +
Ciaran McCreesh wrote:
> Because it isn't... Are set names atoms? Are package names without an
> associated category atoms?
If I use the content of man 5 ebuild as a guide, I'd say no, sets can't be
atoms.
Because sets can't have "base name" and "version" sub
On Mon, 2 Jan 2017 12:49:59 -0500
Rich Freeman wrote:
> However, in this case why would we want to rule out sets, "and all the
> other shenanigans?" We've already established that a single stable
> request bug can apply to multiple package-versions, so why not allow
> full dependency specificati
On Tue, 3 Jan 2017 10:23:02 -0500
Rich Freeman wrote:
> I tend to be firmly in the camp that a package shouldn't be removed
> unless there is evidence of a serious bug (and that includes things
> blocking other Gentoo packages).
I would probably go further and extend that argument to older versi
On Wed, 04 Jan 2017 05:11:18 +0200
Mart Raudsepp wrote:
> I believe with this mgorny has given ample proof that he is just a
> ciaranm sock puppet account.
One neat trick is to have *two* sock puppet accounts, and then have one
accuse the other of being a sock puppet, which typically leads peop
On Mon, 9 Jan 2017 09:30:11 +
Mike Auty wrote:
> As mentioned in [2,3,others]. You'll then need to reinstall all
> packages.
Well, most. Probably a subset of "all", and if anything gets stuck half way,
you'll
want to know which remaining packages need merged.
find /usr/share/man/ -na
On Tue, 10 Jan 2017 13:05:58 +0100
Jan Stary wrote:
> I am not really familiar eith this system - what would be
> the right piece of information that does relate tot this?
Nothing really, because Gentoo doesn't have "a version", its a rolling release
model.
The closest approximation would be th
On Tue, 10 Jan 2017 15:06:47 +0100
Michał Górny wrote:
> > the manpage formatter needs to call
> > external unpackers. All this to save 40M. I honestly don't think
> > it's worth it.
>
> Calling external tools in a pipeline is a pretty normal solution
> in the *nix world. It could be even cons
On Wed, 18 Jan 2017 08:19:19 +0100
Dirkjan Ochtman wrote:
> This sounds like a much better strategy to me. We're expecting people
> to check things that should be easy to check for machines. Yes, some
> people (like myself) will always use repoman to commit, but it would
> be much better if somet
On Wed, 18 Jan 2017 10:48:18 +0100
Dirkjan Ochtman wrote:
> This doesn't ring intuitively true for me. Maybe you're talking about
> running a "repoman full" for every committed package; I'm not. The
> checks Doug describes are all package-local. What makes this process
> so expensive?
Even on a
On Fri, 27 Jan 2017 09:32:23 +0100
Fabian Groffen wrote:
> I'm interested to hear how other people feel about this.
Yeah. Pretty much my reaction to
Mart Raudsepp wrote:
> The maintainer should be giving the choice of both,
> but if only one can be chosen, the maintainer should make the choi
On Fri, 27 Jan 2017 13:20:10 +
"M. J. Everitt" wrote:
> I don't think anyone truly wants a /_desert_/ Rich, but perhaps you
> meant a /*dessert*/ ?!
You never know, he could be a giant sand worm, digging through the deserts
of spice on Dune.
pgpyt9mdKwDff.pgp
Description: OpenPGP digital s
On Sun, 29 Jan 2017 18:20:34 +0200
Mart Raudsepp wrote:
> Maybe declare from the start that any extra columns should be silently
> ignored in implementations from start, as to be able to safely add more
> columns in the future without breaking backwards compatibility.
Maybe not silently, maybe j
On Sun, 29 Jan 2017 18:20:34 +0200
Mart Raudsepp wrote:
> Might want a "broken" (with maybe a better name) for some of these. I
> bet the ~arch of some of these is broken too, and no-one to respond to
> keyword requests, just happens when it happens.
> arm64 and mips are in that state too until w
On Sun, 29 Jan 2017 14:08:05 -0500
james wrote:
> I do
> not have access to Kent's posting so perhaps a reference to Kent's ideas?
Happened on IRC, not on any ML ( though I copied a basic copy of it in another
thread )
But I'm not going to reiterate it here due to its chances of introducing
On Mon, 30 Jan 2017 14:04:06 -0600
William Hubbs wrote:
> As I said on the bug, the downside is the addition of py3 and ninja as
> build time dependencies, but I think the upside (a build system where
> we don't have to worry about parallel make issues or portability)
> outweighs that.
On princi
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
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 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 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
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
> 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
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 "
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
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 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
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 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 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 16 June 2013 16:01, "Paweł Hajdan, Jr." wrote:
> On 6/9/13 7:22 AM, Alex Legler wrote:
> > I'd appreciate some input on below plan to move project pages to the
> Wiki:
>
> Alex, thanks for working on this! Some feedback:
>
> 1. How will the project pages be protected against "unwanted" edits?
On 28 July 2013 21:11, Michał Górny wrote:
> Now, what portage does is implicitly applying _some_ of the metadata
> from the ebuild tree to vardb without rebuilding the package. In some
> cases. As an effect, vardb is no longer self-satisfactory,
> and represents something between the package that
>
> Probably not a big deal, but there is a “~/.netrc” file which holds
> usernames and password for various services (some FTP clients use it,
> maybe others).
>
> Chris
https://github.com/kr/netrc
https://metacpan.org/module/Net::Netrc
^ too much evidence of prior work
And worse, Net::Netrc i
On 5 August 2013 17:33, Christopher Head wrote:
> Probably not a big deal, but there is a “~/.netrc” file which holds
> usernames and password for various services (some FTP clients use it,
> maybe others).
If you want a suggestion that imbues all the things we want to imbue,
and isn't a recogni
On 26 August 2013 19:38, Michał Górny wrote:
> Hello, all.
>
> I've noticed that some people are using internal eclass functions
> in their ebuilds. I mean, functions that are explicitly marked
> @INTERNAL and that start with an underscore. What should I do to them?
>
>
Not sure if this is a warn
On 26 August 2013 19:55, Pacho Ramos wrote:
> El lun, 26-08-2013 a las 09:38 +0200, Michał Górny escribió:
>
>
> I would open a bug and try to contact the developer. Not sure if
> internal functions could be named in a "standard" way allowing repoman
> to die on its usage by ebuilds :/
>
>
This r
On 27 August 2013 22:14, Michał Górny wrote:
> Dnia 2013-08-18, o godz. 18:39:56
> Ulrich Mueller napisał(a):
>
> > 3. So far, we don't have a good name for the function.
>
> eapply.
>
> - consistent with 'git apply',
> - short,
> - e* prefix,
> - no known collisions.
>
> I wouldn't call it perf
On 3 September 2013 09:22, Ulrich Mueller wrote:
> I'd consider any tool as broken if it outputs escape sequences when
> the output doesn't go to a terminal. (Unless such output was
> explicitly asked for.)
>
However, what about when output is going to a terminal *and* a log file?
It seems sma
On 3 September 2013 16:17, Richard Yao wrote:
> I admit that it is annoying
> to view them in a web browser where the escape characters are not
> parsed, but that is easily resolved at the terminal
>
You could plausibly also have a filter in bugzilla that detects escape
codes in the log, and ad
Presently, in tree, for perl modules, there's a generic perl-module.eclass
This has been OK for the most part, because the assumptions it has made
have often been true.
For instance, perl-module.eclass thinks that if a file exists called
Build.PL, that it will be using Module::Build, so it uses
On 4 September 2013 08:11, Tom Wijsman wrote:
> And then I asked the questions that I'd like to see answered:
>
>
> Why do they not belong there? What do people have to do who want them?
>
If anyone needs a poster child for the sort of escape sequence outputs that
most definitely are of no valu
On 4 September 2013 21:59, Michał Górny wrote:
> And how are you going to implement this? I doubt that fd/vt input has
> any sort of 'writing process id' indicator.
>
In one terminal:
cat -vET
In another:
pgrep -x cat # 199935
ls -la /proc/199935/fd/
dr-x-- 2 kent kent 0 Sep 4 23:29
On 4 September 2013 21:59, Michał Górny wrote:
> And how are you going to implement this? I doubt that fd/vt input has
> any sort of 'writing process id' indicator.
>
Though granted, my other post is not going to be useful on a line-by-line
basis.
The obvious easy approach is have an exec laun
On 25 September 2013 10:30, Tom Wijsman wrote:
> If I want to browse all documentation with a browser, just going to
> something like file:///usr/share/doc and read them all in the same
> style (using an extension like Stylebot or so); then it would be neat
> if Gentoo could bring them down to th
On 25 September 2013 12:33, Tom Wijsman wrote:
> The existence of a tool does not exclude that an ebuild cannot use it;
> so, I agree with your paragraph but that doesn't necessarily mean we can
> apply this in an ebuild context.
>
I guess I can agree I would be amenable to a scenario where you
On 26 September 2013 19:53, Michał Górny wrote:
> How do we handle packages which install multiple libraries? I'm afraid
> forcing such a policy and/or hurrying developers to adapt will only
> cause more of poppler-like issues to occur.
>
Can you give a an example package which:
- installs mult
On 27 September 2013 03:10, Andreas K. Huettel wrote:
>
> app-text/poppler
> https://bugs.gentoo.org/show_bug.cgi?id=462020
Reading this bug re-fuels my wish for virtuals to un-happen. Maintaining a
virtual with a massive list of || ( ) conditions is so so painful,
especially considering thei
On 27 September 2013 06:00, Kent Fredric wrote:
>
> ie: every time there is a new iteration of Foo, one must iterate all the
> virtuals that relate to it, and vet their need to be updated, and every
> single update you do is just something thats easy to get wrong, when it
> alway
On 27 September 2013 05:57, Ciaran McCreesh
wrote:
> virtual/perl-* is self-inflicted.
How would you recommend it?
Like for instance, we really do need virtuals ( or equivalent ) for many
things in there, because those things may stop being part of dev-lang/perl
at a future time. One such examp
On 27 September 2013 08:02, Martin Vaeth
wrote:
> For those which are provided by perl itself, you could have
> a corresponding useflag of dev-lang/perl and make a use dependency:
> If the main perl tarball does not provide the package, the perl ebuild
> can pull in the corresponding package as a
On 28 September 2013 07:48, Martin Vaeth
wrote:
> Sorry if this is duplicate: I repost since I cannot see it after
> a few hours.
>
> Kent Fredric wrote:
> >
> > On 27 September 2013 08:02, Martin Vaeth
> >wrote:
> >
> >> For those which are p
On 28 September 2013 22:31, Martin Vaeth
wrote:
>
> Note that it would be stupid to depend on e.g.
> =virtual/perl-Term-ANSIColor-4.02
> for several reason:
>
> 1. The virtual does not even exist :)
>
Nope, it does. Its just called =virtual/perl-Term-ANSIColor-4.20.0 ,
because upstreams versionin
On 28 September 2013 22:46, Martin Vaeth
wrote:
> Kent Fredric wrote:
> >
> > you'll still need logic like "|| (
> > dev-lang/perl[perl_module_Term_ANSIColor(-)] perl-core/Term-ANSIColor
> )"
> > to just deal with the reality of what upstream
On 28 September 2013 23:36, Martin Vaeth
wrote:
>
> Concerning the eclass idea which was already mentioned and
> which is perhaps even better than my suggeestion from the
> other posting, since it avoids some of the disadvantages:
>
> > by having an eclass that translates a special variable, say,
On 29 September 2013 08:51, Ciaran McCreesh
wrote:
> The only reason anyone can make that claim is that no-one really knows
> what slot dictionaries are or how they'd work in practice. Until
> there's a rough description of how they work and a prototype
> implementation, "subslot dictionaries" is
On 29 September 2013 09:14, Martin Vaeth
wrote:
> the
> dependencies would not pull in unnecessary packages for the user.
>
Its just every time you say "unnessecary", that also implies that users **
NEVER** want new versions of dependencies.
That is just not true for most of the gentoo tree. If
On 29 September 2013 09:14, Martin Vaeth
wrote:
> this dependency will install for a user with
> unstable keywords
>
That, in itself, indicates the user is usually OK with "new versions of
things" ;)
corelist -a says virtual/perl-Digest-MD5-2.520.0 should || ( perl v5.18 )
Though that virtual
On 29 September 2013 11:13, Martin Vaeth
wrote:
>
> > The best solution I presently have for this problem, would be to have
> > a PROVIDES-${PV}.json file in every package under files/
>
> Not under files but in the eclass, and the rest of the
> work is done by the perl-dep function.
The reason
On 1 October 2013 04:52, Martin Vaeth wrote:
>
> For instance, if you have your home-brewn version of program X,
> you can just install the version under its own package name Y and
> make it satisfy all dependencies of X.
> (Currently you have to mess around with package.provided which has
> many
On 2 October 2013 08:51, Peter Stuge wrote:
> I agree, but I think the problem is basically that many people
> consider it impossible for "newer" to ever be shitty.
>
> Even if they are intimately familiar with the details of a package
> upstream they may still not be capable of determining what
On 3 October 2013 05:43, yac wrote:
> I'd be cautious about involving users in this as it very often happens
> to myself that something breaks, I get mad and then figure it was my
> own fault (eg. messing with cflags I shouldn't mess with)
>
That does happen from time to time on the CPAN Testers
On 4 October 2013 05:11, "Paweł Hajdan, Jr." wrote:
> Even then, no amount of testing guarantees lack of problems.
Indeed, but which is a better assurance, "5 testers tested this combination
and nothing bad happened", or "5000 people tested this combination and
nothing bad happened".
Now, if y
On 4 October 2013 17:03, "Paweł Hajdan, Jr." wrote:
> but even what you're describing
> above won't cover _everything_, and this is mostly what I'm saying.
>
Yeh, its a given that it won't cover /all/ scenarios. Its obviously not
intended to /replace/ arch testers, just supplementary context.
On 21 October 2013 01:09, hasufell wrote:
> what does the games team think of an official games repository?
>
> These are some arguments for such a repo:
> * sunrise does not allow ebuilds when any version is already in the
> tree (so no live or beta ebuilds for existing in-tree-games), so that
>
On 1 November 2013 11:02, Alessandro DE LAURENZIS wrote:
>
> In case of vim-core/vim/gvim (and vim-qt?), I cannot understand
> the reason... Are still there advantages in doing so?
Useflags have their perks for giving variations on behaviour, but having 3
effective packages in one, governed by u
On 7 November 2013 04:15, Ian Stakenvicius wrote:
>
> The bug that was filed, is that a user didn't do a full emerge -uDN
> @world prior to emerging (upgrading?) firefox, and they had icu-49
> already installed. Because the firefox dep didn't have a minimum
> version, portage didn't see upgradin
On 14 November 2013 04:23, Martin Vaeth
wrote:
> The use.stable.mask "solution" is to not inform the user but just
> decide behind his back that he cannot use the flag and enforce
> this decision.
> Instead, e.g. one can let portage report if some useflag described
> in use.stable.mask needs to be
On 14 November 2013 09:21, James Potts wrote:
> To be honest, I think that printing a summary of masked useflags which
> contradict a user's settings in USE= at the end of the pretend/ask portion
> of an emerge would be a step in the right direction. Making it so that
> portage bails with an erro
On 15 November 2013 17:56, Matt Turner wrote:
> After using it for a month, he's now convinced that
> Gentoo is clearly the most difficult to use.
>
> I'm inclined to agree,
I'd have to disagree there slightly, arch is more easy to use if you
stick to the core set, the binary packages ... as is
On 17 November 2013 01:39, Martin Vaeth
wrote:
>
> This is really a severe restriction since the motivation
> for installation can be very different for these variants.
> For instance, for a native ffmpeg the user might want support
> for a lot of codecs/devices while for the 32 bit variant
> the
On 17 November 2013 10:52, Michał Górny wrote:
> Unless I'm misunderstanding something, you are not correct.
>
> You can surely do something like:
>
> RDEPEND="abi_x86_32? ( dev-libs/c[abi_x86_32(-)] )"
It was more you cant do
IUSE="foo"
without doing
RDEPEND=" abi_x86_32? ( foo ? ( dev-lib
On 19 December 2013 06:33, Jan Kundrát wrote:
> I'm worried by the cost of such a policy, though, because we would suddenly
> have to patch some unknown amount of software
Given the nature that changing that CXX Flag globally for all users
could cause many packages to spontaneously fail to build
On 26 December 2013 02:16, Patrick Lauer wrote:
> I'm getting tired of cleaning up behind people (not only you, it's on
> average 2 issues a day I have to figure out and either fix or file
> bugs)
>
I don't believe anyone is impervious to mistakes ;).
https://bugs.gentoo.org/show_bug.cgi?id=489
On 3 January 2014 01:50, Ryan Hill wrote:
> Maybe we could add RESTRICT=srcdist which would cause ebuilds to save
> their distfiles in a separate directory controlled by PORTDIR_NODIST or
> something. If the variable is unset then it's business as usual.
>
I was going to suggest similar.
Thoug
On 3 January 2014 02:18, Ulrich Mueller wrote:
> > Maybe we could add RESTRICT=srcdist which would cause ebuilds to
> > save their distfiles in a separate directory controlled by
> > PORTDIR_NODIST or something. If the variable is unset then it's
> > business as usual.
>
> Interesting idea, but h
On 3 January 2014 05:28, Luis Ressel wrote:
>
> @Kent: Why do you think another distinction for RESTRICT=fetch is
> neccessary? If it really is, it could also be integrated into this
> solution, but I don't get the point -- either you're allowed to
> redistribute it, or you're not. RESTRICT=fetch
On 3 January 2014 06:02, Luis Ressel wrote:
> These are good arguments. Just to be clear: Would you favor if the
> default setup did this separation? I personally also like the idea, but
> I'd prefer to leave the default at "one distdir for *", and just make
> it configurable via the proposed var
On 10 January 2014 17:58, Michał Górny wrote:
>
> Just to be clear, what is the exact use case for this? I can't think
> of a really good reason to manipulate mirror lists in subsequent repos.
>
For Perl, in ::gentoo , its considered not too optimal to have backpan
listed as a mirror, and its un
On 12 January 2014 08:16, Kent Fredric wrote:
> diff <( grep cpan
> /var/paludis/repositories/perl-git/profiles/thirdpartymirrors ) <( grep
> cpan /usr/portage/profiles/thirdpartymirrors )
>
Oh... also, there's a wide variety of location specific CPAN mirrors
avai
On 18 January 2014 18:02, Robin H. Johnson wrote:
> - More people need to use the infra-status page to learn about the state
> of Gentoo services.
>
A service middle layer like fastly or cloudflare which could link to the
infra page would be good here perhaps, so when an outage occurred ( at
On 14 February 2014 04:28, Anthony G. Basile wrote:
> 2) You want your vcs to show the diff in that file and you can make sense
> of that diff.
>
Though how many of them are "well formatted" SVGs, and how many of them are
single-line SVG files without whitespace, such as linefeeds and
appropria
On 24 March 2014 11:54, Joshua Kinard wrote:
> That said, Is XML that specific that every single atom has to be wrapped by
> an individual tag? A comma-separated list of values in its own XML tag is
> prohibited by the spec? I don't use XML often (if at all), so I am not
> familiar with its int
I often see one of two patterns:
Pattern A) Code Before `inherit` to drive behaviour
Example A.1
SOME_VALUE="Foo"
inherit someclass
OTHERVALUE=Bar"
inherit someotherclass
This is used heavily in things using perl-module.eclass
Pattern B) Require either function calls or have a finalising fun
On 28 March 2014 23:47, Michał Górny wrote:
> Please paste a real example, it's easier to understand what you're
> trying to do when we see what it does.
>
For the A.1 style:
MODULE_AUTHOR=DOY
MODULE_VERSION=2.0604
inherit perl-module
^ from Moose 2.60.400.ebuild , this creates SRC_URI based
On 29 March 2014 06:12, Ciaran McCreesh wrote:
> These look a lot like they're just parameters to an eclass... An
> alternative approach is to make this explicit, rather than having
> zillions of environment variables:
>
Something I'd *like* to be able to do is have eclass specific keys that map
On 25 March 2014 03:55, Damien Levac wrote:
> A lot of people already replied to this question: package search.
>
> A trivial example, a user want to know all terminals available in portage.
> Of course he could try a `emerge --searchdesc terminal`, but then he would
> get anything mentioning ter
On 29 March 2014 09:56, yac wrote:
> terminal ∩ jabber ∩ client
And now you want *only* terminal terminals, do you have to search for
terminal ∩ !( jabber ∪ client ∪ everything ∪ else ) ?
Or
terminal ∩ emulator
( Which may include terminals for emulators instead of terminal emulators )
--
On 8 May 2014 22:23, Jason A. Donenfeld wrote:
> Would somebody help me to make the ebuild do the right thing with the
> emacs stuff? It would be most appreciated.
Title of the mail is a little confusing/distracting/misleading and kinda
made it hard for me to initially understand what you were
401 - 500 of 875 matches
Mail list logo
