Dnia 2013-11-14, o godz. 07:49:55
Patrick Lauer napisał(a):
> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>
> > It's also worth pointing out that the whole reason why abi_x86_32 is
> > {package.,}use.stable.masked is because trying to manage the partial
> > transisition between emul-* and mu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> long story short having a portage-20130126.tar.bz2 snapshot
>> (before the EAPI 5 switch) greatly simplified the upgrade of an
>> old server on a client.
I have done the switch to the current profile+portage on many server
recently and i don't t
# Pawel Hajdan jr (13 Nov 2013)
# Masked for removal in 30 days. Depends on masked dev-lang/v8,
# no commits since 2011. See bug #429276, bug #443586, bug #443688,
# bug #490214.
dev-lang/v8cgi
# Pawel Hajdan jr (13 Nov 2013)
# Masked for removal in 30 days. Does not have stable API resulting in
#
On Mon, 11 Nov 2013 10:32:55 +0100
Manuel Rüger wrote:
> Hi,
>
> I recently noticed it twice, that it seems to be common practice to
> remove a package without using the methods described in [1], but just
> dropping it from cvs.
>
> From my observations packages removed without last-rites could
On Wed, 13 Nov 2013 14:12:24 -0500
Rich Freeman wrote:
> On Wed, Nov 13, 2013 at 1:58 PM, Francesco R.
> wrote:
> >
> > long story short
> > having a portage-20130126.tar.bz2 snapshot (before the EAPI 5
> > switch) greatly simplified the upgrade of an old server on a client.
> >
> > Why not kee
On Wed, 13 Nov 2013 10:41:40 -0500
Mike Gilbert wrote:
> Let's talk about the development workflow we use for a minute:
>
> [...]
>
> This is not a completely social issue; there is a very real
> technical/QA issue that needs to be addressed on the development side.
> If you can figure that out
On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
> It's also worth pointing out that the whole reason why abi_x86_32 is
> {package.,}use.stable.masked is because trying to manage the partial
> transisition between emul-* and multilib-build dependencies
^^
Why is there a partial random transition
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
# Matti Bickel (13 Nov 2013)
# Now included in dev-php/phpunit, removal on 20131213
dev-php/DBUnit
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iKYEARECAGYFAlKEB3tfF
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 Wed, Nov 13, 2013 at 3:49 PM, Roy Bamford wrote:
> The GPL obliges us to keep such patches around for three years, iirc.
> Don't we do that ?
Why? We own the copyright on the patches (to whatever degree that
they're copyrightable), so we don't need a license to distribute them.
If somebody e
On 2013.11.13 19:12, Rich Freeman wrote:
[snip]
> Going back in time with portage is the easy part - it is in CVS.
>
> The real problem is all the distfiles themselves, especially things
> like out-of-tree patch tarballs hosted by devs.
>
> Rich
>
Rich,
The GPL obliges us to keep such patche
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 error if package.use conflicts with
use.(package.)mask woul
gtk+:1 and glib:1 using apps masked for removal on 20131213
app-text/gsview
mail-client/gbuffy
net-print/pup
dev-libs/libsmtp
net-analyzer/traffic-vis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/13/2013 01:58 PM, Francesco R. wrote:
>
> long story short having a portage-20130126.tar.bz2 snapshot
> (before the EAPI 5 switch) greatly simplified the upgrade of an old
> server on a client.
>
> Why not keep a copy on the servers? I mean
>
On Wed, Nov 13, 2013 at 1:58 PM, Francesco R. wrote:
>
> long story short
> having a portage-20130126.tar.bz2 snapshot (before the EAPI 5 switch)
> greatly simplified the upgrade of an old server on a client.
>
> Why not keep a copy on the servers? I mean
> http://distfiles.gentoo.org/snapshots/
long story short
having a portage-20130126.tar.bz2 snapshot (before the EAPI 5 switch)
greatly simplified the upgrade of an old server on a client.
Why not keep a copy on the servers? I mean
http://distfiles.gentoo.org/snapshots/
thanks,
Francesco Riosa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/13/2013 09:16 AM, Ian Stakenvicius wrote:
> On 13/11/13 09:55 AM, Thomas Kahle wrote:
>> On 11/13/2013 03:30 PM, Duncan wrote:
>>> Rich Freeman posted on Wed, 13 Nov 2013 08:37:51 -0500 as
>>> excerpted:
>>>
On Wed, Nov 13, 2013 at 8:25 AM
On Wed, Nov 13, 2013 at 1:24 PM, Peter Stuge wrote:
> Rich Freeman wrote:
>> >> Users who take advantage of new features in these kinds of states
>> >> are going to run into problems. That's just the cost of being on
>> >> the cutting edge.
>> >
>> > Why should a feature be allowed to cause probl
Rich Freeman wrote:
> >> Users who take advantage of new features in these kinds of states
> >> are going to run into problems. That's just the cost of being on
> >> the cutting edge.
> >
> > Why should a feature be allowed to cause problems? To me that just
> > means that the feature isn't finish
On Wed, Nov 13, 2013 at 12:03 PM, Peter Stuge wrote:
>
> Rich Freeman wrote:
>> Users who take advantage of new features in these kinds of states
>> are going to run into problems. That's just the cost of being on
>> the cutting edge.
>
> Why should a feature be allowed to cause problems? To me t
On 11/13/13 8:05 AM, Martin Vaeth wrote:
> 1. A tiny change in the display: ~foo instead of (-foo)
I was thinking about same/similar thing: displaying USE flags masked in
general and USE flags masked for stable differently.
I'd in fact opt for ~(-foo) in this case, to indicate that the flag is
ma
Michał Górny wrote:
> Did you ever do any serious package work, or are just discussing theory?
Michał, you're talking with a user. Please behave.
Make a concerted effort to put yourself in his situation. Talking
down to him ("did you ever do any serious work") is not helpful
for your image, for t
Michał Górny wrote:
>
> Repoman is not a social tool. It's a technical dep checker, and if you
> start allowing exceptions to the rules
Repoman might still access use.stable.mask without having
portage force it on users.
The social conflict I mean is: You *want* that users do not
decide for ~ARC
Kent Fredric wrote:
>
> Maybe IUSE can be extended in a future EAPI to have ~
I like this "~foo" idea very much from the user's point of view:
You see clearly why useflags are disabled, and one could have a
"simple" mechanism to override it.
However, extending IUSE is not the correct way, becaus
On Wed, Nov 13, 2013 at 10:02 AM, Ian Stakenvicius wrote:
> It's also worth pointing out that the whole reason why abi_x86_32 is
> {package.,}use.stable.masked is because trying to manage the partial
> transisition between emul-* and multilib-build dependencies on stable
> or mixed-keyworded syste
Dnia 2013-11-13, o godz. 15:23:44
Martin Vaeth napisał(a):
> Michał Górny wrote:
> >
> >> As I understand, it tries to solve a "social" issue
> >> (that an ARCH user might set a USE-flag which eventually
> >> pulls in an ~ARCH package) on a technical level
> >> (by forcibly disabling the USE-fla
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 Wed, Nov 13, 2013 at 10:23 AM, Martin Vaeth
wrote:
> Michał Górny wrote:
>>
>>> As I understand, it tries to solve a "social" issue
>>> (that an ARCH user might set a USE-flag which eventually
>>> pulls in an ~ARCH package) on a technical level
>>> (by forcibly disabling the USE-flag for the u
Michał Górny wrote:
>
>> As I understand, it tries to solve a "social" issue
>> (that an ARCH user might set a USE-flag which eventually
>> pulls in an ~ARCH package) on a technical level
>> (by forcibly disabling the USE-flag for the user).
>> Solving social problems by technical means is never a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/11/13 09:55 AM, Thomas Kahle wrote:
> On 11/13/2013 03:30 PM, Duncan wrote:
>> Rich Freeman posted on Wed, 13 Nov 2013 08:37:51 -0500 as
>> excerpted:
>>
>>> On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle
>>> wrote:
On 11/13/2013 12:39 PM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/11/13 09:10 AM, Michał Górny wrote:
>>
>> 1. For several reasons I always want the most current
>> emul-linux-x86* libraries, so they are in
>> package.accept_keywords. Due to global ABI_X86=32 (which I also
>> want), this forced me of course
On 11/13/2013 03:30 PM, Duncan wrote:
> Rich Freeman posted on Wed, 13 Nov 2013 08:37:51 -0500 as excerpted:
>
>> On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle wrote:
>>> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
On Wed, 13 Nov 2013 10:28:02 + (UTC)
Martin Vaeth wrote:
>
Tom Wijsman wrote:
>
> and I quote "quite a few bugs are closed as invalid when a mixed system
> is detected"
I think nobody is speaking against this possibility:
If it causes too much grief to the maintainer to list all blockers
explicitly, I think everybody can agree if he says that if it break
Rich Freeman posted on Wed, 13 Nov 2013 08:37:51 -0500 as excerpted:
> On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle wrote:
>> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
>>> On Wed, 13 Nov 2013 10:28:02 + (UTC)
>>> Martin Vaeth wrote:
>>>
Hello.
The new "features" use.stable.m
Dnia 2013-11-13, o godz. 10:28:02
Martin Vaeth napisał(a):
> As I understand, it tries to solve a "social" issue
> (that an ARCH user might set a USE-flag which eventually
> pulls in an ~ARCH package) on a technical level
> (by forcibly disabling the USE-flag for the user).
> Solving social probl
Tom Wijsman wrote:
>> The new "features" use.stable.mask and package.use.stable.mask
>> have turned maintaining systems with mixed ARCH and ~ARCH keywords
>> into a nightmare:
>
> They are considered unsupported by many
We can make a vote, but I would be very surprised if there are
many stable us
On Wed, 13 Nov 2013 08:37:51 -0500
Rich Freeman wrote:
> That said, your original email contained a few separate issues and
> they're probably best dealt with individually.
Just to set things straight: Note that these were different authors.
> We're not going to have a common solution for multi
On Wed, 13 Nov 2013 14:25:11 +0100
Thomas Kahle wrote:
> Hi,
>
> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
> > On Wed, 13 Nov 2013 10:28:02 + (UTC)
> > Martin Vaeth wrote:
> >
> >> Hello.
> >>
> >> The new "features" use.stable.mask and package.use.stable.mask
> >> have turned maintaining
On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle wrote:
> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
>> On Wed, 13 Nov 2013 10:28:02 + (UTC)
>> Martin Vaeth wrote:
>>
>>> Hello.
>>>
>>> The new "features" use.stable.mask and package.use.stable.mask
>>> have turned maintaining systems with mixed
Hi,
On 11/13/2013 12:39 PM, Tom Wijsman wrote:
> On Wed, 13 Nov 2013 10:28:02 + (UTC)
> Martin Vaeth wrote:
>
>> Hello.
>>
>> The new "features" use.stable.mask and package.use.stable.mask
>> have turned maintaining systems with mixed ARCH and ~ARCH keywords
>> into a nightmare:
>
> They ar
On Wed, 13 Nov 2013 10:28:02 + (UTC)
Martin Vaeth wrote:
> Hello.
>
> The new "features" use.stable.mask and package.use.stable.mask
> have turned maintaining systems with mixed ARCH and ~ARCH keywords
> into a nightmare:
They are considered unsupported by many; so, going down that path you
Hello.
The new "features" use.stable.mask and package.use.stable.mask
have turned maintaining systems with mixed ARCH and ~ARCH keywords
into a nightmare:
Similarly to the (fortunately dropped) concept of forcing
useflags if certain packages are installed this forces a
magic on the user which can
Hi all,
as you might or might not be aware of, elibtoolize() originally was for applying
patches to ltmain.sh, but now also applies patches to configure scripts.
The problem is that finding configure scripts to be patched is based on where
ltmain.sh is found in ${S}, wild guessing that ltmain.sh
43 matches
Mail list logo
