On 06/08/2013 00:09, Robin H. Johnson wrote:
> I'm replying the start of this thread, rather than picking a single
> person to respond to. I DO want more brainstorming on ideas for the
> naming of the package, and I think people need to cast a wider net for
> naming ideas.
>
> I'm most certainly n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/06/2013 12:09 AM, Robin H. Johnson wrote:
> Various proposed names (in no specific order):
names, *sigh*
It's rather a interface setup utility than a networking thing.
Networkin happens - most cases - when you have paths and entities and
such
On 08/05/2013 09:45 PM, Michael Orlitzky wrote:
> On 08/05/2013 06:09 PM, Robin H. Johnson wrote:
>> - netrc (conflicts)
>
> Would naming it net-rc alleviate the perceived conflict?
>
Or, duh, networkrc.
On 08/05/2013 06:09 PM, Robin H. Johnson wrote:
> - netrc (conflicts)
Would naming it net-rc alleviate the perceived conflict?
On Mon, Aug 05, 2013 at 10:09:54PM +, Robin H. Johnson wrote
> Naming goals:
> - Should describe what it does
> - Does NOT have a name conflict as verified by Google.
> - Does NOT imply OpenRC.
> - Implying Gentoo is fine, as it's where the package comes from.
> - Should drop 'old'
Some sug
On Mon, 5 Aug 2013 19:13:06 +0100
Ciaran McCreesh wrote:
> > > and
> > > it's not clear such a concept makes sense as-is. We haven't worked
> > > out what happens in a || ( a b !c ) case where a, b and c are all
> > > installed, for example.
> >
> > subslot = concatenation of the subslots of all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 08/06/2013 12:09 AM, Robin H. Johnson wrote:
> I'm replying the start of this thread, rather than picking a
> single person to respond to. I DO want more brainstorming on ideas
> for the naming of the package, and I think people need to cast a
> w
On Mon, 5 Aug 2013 22:09:54 +
"Robin H. Johnson" wrote:
>
> Naming goals:
> - Should describe what it does
> - Does NOT have a name conflict as verified by Google.
> - Does NOT imply OpenRC.
> - Implying Gentoo is fine, as it's where the package comes from.
> - Should drop 'old'
>
> I think
I'm replying the start of this thread, rather than picking a single
person to respond to. I DO want more brainstorming on ideas for the
naming of the package, and I think people need to cast a wider net for
naming ideas.
I'm most certainly not planning to get rid of the package whatsoever,
many of
On Mon, Aug 5, 2013 at 2:09 PM, Samuli Suominen wrote:
>
> okay, maybe this plan sucks as some have suggested in later posts in this
> thread.
> however the main point from first post stands, don't at least do
> virtual/jpeg:= deps, use at least virtual/jpeg:0 or virtual/jpeg:0= whatever
>
++
Th
On Mon, 5 Aug 2013 13:58:49 -0400
Alexis Ballier wrote:
> > Unfortunately things that "don't seem" to be complicated sometimes
> > are complicated. We haven't established whether that's the case
> > here. In particular, we don't have any notion of "providers"
> > currently,
>
> s/currently/anymor
On 05/08/13 18:06, Samuli Suominen wrote:
On 05/08/13 18:00, Michael Palimaka wrote:
On 5/08/2013 21:58, Samuli Suominen wrote:
On 05/08/13 13:56, Michael Palimaka wrote:
On 5/08/2013 19:33, Samuli Suominen wrote:
This is a friendly reminder.
I've found the tree again to have dependencies li
On Mon, 5 Aug 2013 18:28:54 +0100
Ciaran McCreesh wrote:
> On Mon, 5 Aug 2013 12:51:48 -0400
> Alexis Ballier wrote:
> > > Not really. There's a tradeoff between dependencies that are
> > > occasionally too strict, and dependencies that are horribly
> > > complicated (see "subslot dictionaries")
On Mon, 5 Aug 2013 12:51:48 -0400
Alexis Ballier wrote:
> > Not really. There's a tradeoff between dependencies that are
> > occasionally too strict, and dependencies that are horribly
> > complicated (see "subslot dictionaries").
>
> having a way to express 'my subslot is the one of my provider'
On Mon, Aug 5, 2013 at 12:15 PM, Alexis Ballier wrote:
> On Mon, 5 Aug 2013 18:10:46 +0200
> Michał Górny wrote:
>> We can simply have multiple virtual versions, each depending
>> on the proper jpeg & jpeg-turbo versions.
>
> you can do it that way, yes.
>
> what will you do when jpeg 10 is out o
On Mon, 5 Aug 2013 18:37:29 +0200
"Andreas K. Huettel" wrote:
> Am Montag, 5. August 2013, 18:22:32 schrieb Alexis Ballier:
> >
> > 'horrible breakage' is mitigated by preserve-libs and running
> > @preserved-rebuild as soon as possible has the same end result
> > avoiding useless rebuilds.
>
>
On Mon, 5 Aug 2013 17:36:49 +0100
Ciaran McCreesh wrote:
> On Mon, 5 Aug 2013 12:22:32 -0400
> Alexis Ballier wrote:
> > On Mon, 5 Aug 2013 17:13:49 +0100
> > Ciaran McCreesh wrote:
> > > On Tue, 06 Aug 2013 02:03:28 +1000
> > > Michael Palimaka wrote:
> > > > > How often does this situation e
Am Montag, 5. August 2013, 18:22:32 schrieb Alexis Ballier:
>
> 'horrible breakage' is mitigated by preserve-libs and running
> @preserved-rebuild as soon as possible has the same end result avoiding
> useless rebuilds.
No it is not and does not.
[Providing roughly the same information depth in
On Mon, 5 Aug 2013 12:22:32 -0400
Alexis Ballier wrote:
> On Mon, 5 Aug 2013 17:13:49 +0100
> Ciaran McCreesh wrote:
> > On Tue, 06 Aug 2013 02:03:28 +1000
> > Michael Palimaka wrote:
> > > > How often does this situation even come up? If 9/10 times the
> > > > libraries are set up as maintaine
On 6/08/2013 02:13, Ciaran McCreesh wrote:
On Tue, 06 Aug 2013 02:03:28 +1000
Michael Palimaka wrote:
How often does this situation even come up? If 9/10 times the
libraries are set up as maintainers expect them to be, it is
probably better to deal with the odd unnecessary rebuild until
somebo
On Mon, 5 Aug 2013 17:13:49 +0100
Ciaran McCreesh wrote:
> On Tue, 06 Aug 2013 02:03:28 +1000
> Michael Palimaka wrote:
> > > How often does this situation even come up? If 9/10 times the
> > > libraries are set up as maintainers expect them to be, it is
> > > probably better to deal with the o
On Mon, 5 Aug 2013 18:10:46 +0200
Michał Górny wrote:
> Dnia 2013-08-05, o godz. 11:50:38
> Alexis Ballier napisał(a):
>
> > On Mon, 05 Aug 2013 18:06:33 +0300
> > Samuli Suominen wrote:
> > > The plan is to change SLOT of virtual/jpeg from "0" to eg. "0/1"
> > > after next SONAME change in th
On Tue, 06 Aug 2013 02:03:28 +1000
Michael Palimaka wrote:
> > How often does this situation even come up? If 9/10 times the
> > libraries are set up as maintainers expect them to be, it is
> > probably better to deal with the odd unnecessary rebuild until
> > somebody spots it, rather than going
Am Montag, 5. August 2013, 15:39:48 schrieb Ulrich Mueller:
> No package has the following flags in IUSE, so I'll remove them in a
> few days from now:
>
>kdeprefix - Makes a KDE prefixed install into /usr/kde/${SLOT} if
> enabled or into /usr (FHS compatible) otherwise
kdeprefix is long gon
Dnia 2013-08-05, o godz. 11:50:38
Alexis Ballier napisał(a):
> On Mon, 05 Aug 2013 18:06:33 +0300
> Samuli Suominen wrote:
> > The plan is to change SLOT of virtual/jpeg from "0" to eg. "0/1"
> > after next SONAME change in the default of the virtual, so it's
> > useful to have everything depend
On 6/08/2013 01:07, Rich Freeman wrote:
I suspect most maintainers would rather upgrade their package once to
EAPI5 and not keep checking back every month to see if there is a new
opportunity to add another slot operator dep. If maintainers don't
add them up-front even with the deps don't suppor
[snip]
> :p I'm actually thinking netrc if Robin is ok with it. William
replaying to a random message in the tree
Not going to suggest a name but if has to be something for general
consumption, it should avoid the "gentoo" inside the name
just my 0.2¢
On Mon, 05 Aug 2013 18:06:33 +0300
Samuli Suominen wrote:
> The plan is to change SLOT of virtual/jpeg from "0" to eg. "0/1"
> after next SONAME change in the default of the virtual, so it's
> useful to have everything depend on virtual/jpeg:0= ready, to get the
> benefits of the subslot.
last I
On 6/08/2013 01:06, Samuli Suominen wrote:
The plan is to change SLOT of virtual/jpeg from "0" to eg. "0/1" after
next SONAME change in the default of the virtual, so it's useful to have
everything depend on virtual/jpeg:0= ready, to get the benefits of the
subslot.
Does that mean that anyone t
On 05/08/13 18:00, Michael Palimaka wrote:
On 5/08/2013 21:58, Samuli Suominen wrote:
On 05/08/13 13:56, Michael Palimaka wrote:
On 5/08/2013 19:33, Samuli Suominen wrote:
This is a friendly reminder.
I've found the tree again to have dependencies like:
dev-libs/openssl:=
virtual/jpeg:=
Is
On Mon, Aug 5, 2013 at 11:00 AM, Michael Palimaka wrote:
> Even though the subslot is implicit, is that any reason to still use the
> operator? We don't know what the maintainer's future intentions for the
> subslot will be.
> For example, we caused many useless rebuilds with poppler because depen
On 5/08/2013 21:58, Samuli Suominen wrote:
On 05/08/13 13:56, Michael Palimaka wrote:
On 5/08/2013 19:33, Samuli Suominen wrote:
This is a friendly reminder.
I've found the tree again to have dependencies like:
dev-libs/openssl:=
virtual/jpeg:=
Is there any reason for the subslot operator b
No package has the following flags in IUSE, so I'll remove them in a
few days from now:
kdeprefix - Makes a KDE prefixed install into /usr/kde/${SLOT} if enabled or
into /usr (FHS compatible) otherwise
nocxx - Old flag -- USE=cxx from now on
Ulrich
On Aug 5, 2013 8:06 AM, "Ulrich Mueller" wrote:
>
> > On Mon, 05 Aug 2013, Samuli Suominen wrote:
>
> > You don't need to see it, because portage sets implicit subslot /0
> > in EAPI="5" so it's there, even if you don't see it.
>
> Shouldn't the implicit sub-slot be equal to the regular slot?
> On Mon, 05 Aug 2013, Samuli Suominen wrote:
> You don't need to see it, because portage sets implicit subslot /0
> in EAPI="5" so it's there, even if you don't see it.
Shouldn't the implicit sub-slot be equal to the regular slot?
Ulrich
On 05/08/13 13:56, Michael Palimaka wrote:
On 5/08/2013 19:33, Samuli Suominen wrote:
This is a friendly reminder.
I've found the tree again to have dependencies like:
dev-libs/openssl:=
virtual/jpeg:=
Is there any reason for the subslot operator being specified at all? I
don't see those pac
Currently, USE flag descriptions are a mix of imperative ("Enable")
and indicative ("Enables") forms, the former occuring more often:
Enable : Enables = 2143 : 408
Add : Adds = 525 : 341
Build : Builds = 833 : 27
Use : Uses = 619 : 11
Install : Installs =
On 08/05/2013 01:10 PM, Michael Weber wrote:
> On 08/05/2013 01:01 PM, Rich Freeman wrote:
>> It isn't a bad idea to still post on -dev. Maintainers should be
>> removing the local definitions, and just because a decision seems like
>> the obviously-correct one doesn't mean that it is.
> Follow-up
On 08/05/2013 01:01 PM, Rich Freeman wrote:
> It isn't a bad idea to still post on -dev. Maintainers should be
> removing the local definitions, and just because a decision seems like
> the obviously-correct one doesn't mean that it is.
Follow-up question: Should _I_ remove the identical local def
On Mon, Aug 5, 2013 at 6:56 AM, Ryan Hill wrote:
> On Sat, 03 Aug 2013 16:19:16 +0200
> hasufell wrote:
>
>> I find it a bit silly to require discussing global useflags on dev-ML.
>
> The purpose of the discussion is to come up with a description that is general
> enough to apply to most ebuilds
On 5/08/2013 19:33, Samuli Suominen wrote:
This is a friendly reminder.
I've found the tree again to have dependencies like:
dev-libs/openssl:=
virtual/jpeg:=
Is there any reason for the subslot operator being specified at all? I
don't see those packages defining any subslots.
On Sat, 03 Aug 2013 16:19:16 +0200
hasufell wrote:
> I find it a bit silly to require discussing global useflags on dev-ML.
The purpose of the discussion is to come up with a description that is general
enough to apply to most ebuilds that use that flag. It's a throwback to when
global and loca
On 08/05/2013 11:49 AM, Michał Górny wrote:
> Dnia 2013-08-05, o godz. 12:33:45
> Samuli Suominen napisał(a):
>
>> This is a friendly reminder.
>>
>> I've found the tree again to have dependencies like:
>>
>> dev-libs/openssl:=
>> virtual/jpeg:=
>>
>> Neither of which are correct, since dev-libs/
Picked random mail from this thread.
So, I've seen many people raising intrest in keeping IUSE="static" in
cryptsetup and lvm2 but I haven't really seen anyone working on it yet,
except _AxS_ committed one patch but that isn't enough.
Take eg. http://bugs.gentoo.org/show_bug.cgi?id=472692#c4
Dnia 2013-08-05, o godz. 12:33:45
Samuli Suominen napisał(a):
> This is a friendly reminder.
>
> I've found the tree again to have dependencies like:
>
> dev-libs/openssl:=
> virtual/jpeg:=
>
> Neither of which are correct, since dev-libs/openssl has SLOT="0" and
> SLOT="0.9.8" and virtual/jp
This is a friendly reminder.
I've found the tree again to have dependencies like:
dev-libs/openssl:=
virtual/jpeg:=
Neither of which are correct, since dev-libs/openssl has SLOT="0" and
SLOT="0.9.8" and virtual/jpeg has SLOT="0" and SLOT="62".
Need to pull in the SLOT that installs headers:
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
>
> 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 Thu, 1 Aug 2013 13:33:48 +0200
Michał Górny wrote:
> What can we do to improve this? I'm not really happy to have LLVM
> ebuild analyze CFLAGS to set proper space constraints. Maybe we should
> make check-reqs-r1 automatically bump the constraints by some
> statistical multiplier when it detec
On Fri, 2 Aug 2013 13:47:10 +0100
Diego Elio Pettenò wrote:
> On Fri, Aug 2, 2013 at 1:08 PM, Andreas K. Huettel
> wrote:
>
> > I thought -O0 was generally discouraged, even for debugging?!
>
>
> As Michał said, it all depends on what you want to debug. I would say that
> for 90% of issues you
50 matches
Mail list logo
