Drive-by trolling comment but I wish the effort to keep porkage alive would have instead been directed towards pkgcore.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/01/14 09:39, C. Bergström wrote:
Drive-by trolling comment but I wish the effort to keep porkage
alive would have instead been directed towards pkgcore.
Realistically, we have to keep updating them both in parallel. pkgcore
needs to be
On Mon, Jan 13, 2014 at 9:39 AM, C. Bergström cbergst...@pathscale.com wrote:
Drive-by trolling comment but I wish the effort to keep porkage alive would
have instead been directed towards pkgcore.
If you know your email is going to be drive-by trolling, maybe just
hold it in next time?
On 01/13/14 03:43 PM, Alexander Berntsen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/01/14 09:39, C. Bergström wrote:
Drive-by trolling comment but I wish the effort to keep porkage
alive would have instead been directed towards pkgcore.
Realistically, we have to keep
On Mon, Jan 13, 2014 at 10:15 AM, C. Bergström
cbergst...@pathscale.com wrote:
On 01/13/14 03:43 PM, Alexander Berntsen wrote:
Where I work uses pkgcore[1], but not the areas which are generally
beneficial to the whole community. (We use it as part of a web application
to handle testsuites
On 01/13/14 04:31 PM, Fabio Erculiani wrote:
On Mon, Jan 13, 2014 at 10:15 AM, C. Bergström
cbergst...@pathscale.com wrote:
On 01/13/14 03:43 PM, Alexander Berntsen wrote:
Where I work uses pkgcore[1], but not the areas which are generally
beneficial to the whole community. (We use it as part
On Mon, Jan 13, 2014 at 04:15:37PM +0700, C. Bergström wrote:
On 01/13/14 03:43 PM, Alexander Berntsen wrote:
Realistically, we have to keep updating them both in parallel. pkgcore
needs to be brought up to portage-level functionality,
Yeah but it already outshines under the hood: all you're
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/01/14 12:02, Steven J. Long wrote:
Yeah but it already outshines under the hood: all you're talking
about is EAPI and radhermit is working on it; I'm sure he and
dol-sen would be happy for more help as well, so long as it's
supportive.
Am Montag 13 Januar 2014, 13:28:13 schrieb Alexander Berntsen:
Updating both in parallel isn't hard: once pkgcore is up to EAPI-5,
EAPI-6 isn't that much work (mostly bash afair.)
So far, I dont know of any work on the exact EAPI-6 feature set yet. We should
maybe open a new thread on
On Mon, 13 Jan 2014, Andreas K Huettel wrote:
So far, I dont know of any work on the exact EAPI-6 feature set yet.
We should maybe open a new thread on that, *if* there is already
something.
I've started collecting things already some months ago:
On Mon, 13 Jan 2014 15:39:17 +0700
C. Bergström cbergst...@pathscale.com wrote:
Drive-by trolling comment but I wish the effort to keep porkage alive
would have instead been directed towards pkgcore.
If we still have users left by the time pkgcore is finished...
Moving the work efforts from
On Mon, 13 Jan 2014 16:15:37 +0700
C. Bergström cbergst...@pathscale.com wrote:
Long term the API to pkgcore could be beneficial, but
again I'm not sure it's a game changer for users.
Long term, we should have an independent API backend that tools can
query; not rewrite our tools every time
Tom Wijsman wrote:
So, yes, we need more people on pkgcore; no, we can't just leave
Portage behind, as it still is the beating heart of Gentoo for now.
I guess the point is that it might continue beating long enough mostly
on its own.
//Peter
pgp_E4oOCUrAm.pgp
Description: PGP signature
On Mon, 13 Jan 2014 16:15:37 +0700
C. Bergström cbergst...@pathscale.com wrote:
At the end of the day we have one codebase which is
engineered and another which has evolved.
Too broad generalization, too much assumption; both can be held as
meaning nothing compared to what engineered and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/01/14 09:46 AM, Tom Wijsman wrote:
On Mon, 13 Jan 2014 16:15:37 +0700 C. Bergström
cbergst...@pathscale.com wrote:
Long term the API to pkgcore could be beneficial, but again I'm
not sure it's a game changer for users.
Long term, we
On Mon, 13 Jan 2014 10:31:56 +0100
Fabio Erculiani lx...@gentoo.org wrote:
Portage can still take *minutes* to calculate the merge queue of a
pkg with all its deps satisfied.
Half a minute if you disable backtracking which you don't need. :)
Ironically, launching the same emerge command
On Mon, 13 Jan 2014 11:02:10 +
Steven J. Long sl...@rathaus.eclipse.co.uk wrote:
Yeah but it already outshines under the hood: all you're talking
about is EAPI and radhermit is working on it;
pkgcore's response to EAPI 6 is something to hold your breath for.
I'm sure he and dol-sen would
On Mon, 13 Jan 2014 14:50:44 +0100
Ulrich Mueller u...@gentoo.org wrote:
On Mon, 13 Jan 2014, Andreas K Huettel wrote:
So far, I dont know of any work on the exact EAPI-6 feature set yet.
We should maybe open a new thread on that, *if* there is already
something.
I've started
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 13 Jan 2014 09:56:13 -0500
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/01/14 09:46 AM, Tom Wijsman wrote:
On Mon, 13 Jan 2014 16:15:37 +0700 C. Bergström
cbergst...@pathscale.com
On Mon, 13 Jan 2014 15:46:12 +0100
Peter Stuge pe...@stuge.se wrote:
Tom Wijsman wrote:
So, yes, we need more people on pkgcore; no, we can't just leave
Portage behind, as it still is the beating heart of Gentoo for now.
I guess the point is that it might continue beating long enough
On Mon, 13 Jan 2014 15:58:13 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 10:31:56 +0100
Fabio Erculiani lx...@gentoo.org wrote:
Portage can still take *minutes* to calculate the merge queue of a
pkg with all its deps satisfied.
Half a minute if you disable
On Mon, 13 Jan 2014 16:38:59 +0100
Luis Ressel ara...@aixah.de wrote:
On Mon, 13 Jan 2014 15:58:13 +0100
Tom Wijsman tom...@gentoo.org wrote:
Half a minute if you disable backtracking which you don't need. :)
Which sadly also means that some updates get skipped silently. (Those
which
On Mon, Jan 13, 2014 at 7:38 AM, Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 15:46:12 +0100
Peter Stuge pe...@stuge.se wrote:
Tom Wijsman wrote:
So, yes, we need more people on pkgcore; no, we can't just leave
Portage behind, as it still is the beating heart of Gentoo for
On Mon, Jan 13, 2014 at 7:38 AM, Luis Ressel ara...@aixah.de wrote:
On Mon, 13 Jan 2014 15:58:13 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 10:31:56 +0100
Fabio Erculiani lx...@gentoo.org wrote:
Portage can still take *minutes* to calculate the merge queue of a
On Mon, 13 Jan 2014 16:46:08 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 16:38:59 +0100
Luis Ressel ara...@aixah.de wrote:
On Mon, 13 Jan 2014 15:58:13 +0100
Tom Wijsman tom...@gentoo.org wrote:
Half a minute if you disable backtracking which you don't need. :)
On Mon, Jan 13, 2014 at 5:49 PM, Alec Warner anta...@gentoo.org wrote:
[...]
This is not meant to imply that portage is always fast; there are plenty of
other modules (such as the aforementioned backtracking) that can take a long
time to find solutions. That is partially why you see Tomwij
On Mon, Jan 13, 2014 at 04:15:37PM +0700, C. Bergström wrote:
At the end of the day we have one codebase which is engineered and
another which has evolved.
I'll take an evolved codebase over engineered anyday.
You do realize that is exactly why Linux has succeeded, right? The
kernel has
On Mon, 13 Jan 2014, Tom Wijsman wrote:
I've started collecting things already some months ago:
http://wiki.gentoo.org/wiki/Future_EAPI/EAPI_6_tentative_features
Just for reference: https://bugs.gentoo.org/show_bug.cgi?id=174380
According to [1] there are besides the tracker a 78 bugs
On Tue, Jan 14, 2014 at 12:42:00AM +0700, C. Bergström wrote:
On 01/14/14 12:37 AM, Greg KH wrote:
On Mon, Jan 13, 2014 at 04:15:37PM +0700, C. Bergström wrote:
At the end of the day we have one codebase which is engineered and
another which has evolved.
I'll take an evolved codebase over
On 01/14/14 12:37 AM, Greg KH wrote:
On Mon, Jan 13, 2014 at 04:15:37PM +0700, C. Bergström wrote:
At the end of the day we have one codebase which is engineered and
another which has evolved.
I'll take an evolved codebase over engineered anyday.
You do realize that is exactly why Linux has
On Mon, 13 Jan 2014 16:46:08 +0100
Tom Wijsman tom...@gentoo.org wrote:
Rebuilds don't cause a different solution in the graph afaik; so, I
wouldn't see how that would form a big problem. I also think this
would still be covered by preserved-rebuild and/or revdep-rebuild
afterwards.
There
On Mon, 2014-01-13 at 15:46 +0100, Tom Wijsman wrote:
On Mon, 13 Jan 2014 16:15:37 +0700
C. Bergström cbergst...@pathscale.com wrote:
Long term the API to pkgcore could be beneficial, but
again I'm not sure it's a game changer for users.
Long term, we should have an independent API
On Mon, 13 Jan 2014 15:46:59 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 16:15:37 +0700
C. Bergström cbergst...@pathscale.com wrote:
Long term the API to pkgcore could be beneficial, but
again I'm not sure it's a game changer for users.
Long term, we should have an
On Mon, 13 Jan 2014 18:03:31 +0100
Luis Ressel ara...@aixah.de wrote:
No, the problem wasn't that rebuilds weren't done (btw: this is not
about @preserved-rebuilds, but about subslot dependencies), but that
updates which would trigger such rebuilds are silently ignored. This
happened to me
On Mon, 13 Jan 2014 08:49:17 -0800
Alec Warner anta...@gentoo.org wrote:
The caching may not be of use, depending on your configuration. (For
example, if you use a gentoo-x86 checkout as your main repo, you will
probably want to run generate cache entries whenever you cvs up.) It
is there to
On Mon, 13 Jan 2014 18:05:21 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 13 Jan 2014 16:46:08 +0100
Tom Wijsman tom...@gentoo.org wrote:
Rebuilds don't cause a different solution in the graph afaik; so, I
wouldn't see how that would form a big problem. I also think
On Mon, 13 Jan 2014 19:16:45 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 08:49:17 -0800
Alec Warner anta...@gentoo.org wrote:
The caching may not be of use, depending on your configuration. (For
example, if you use a gentoo-x86 checkout as your main repo, you
will
On Mon, 13 Jan 2014 18:07:39 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 13 Jan 2014 15:46:59 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 16:15:37 +0700
C. Bergström cbergst...@pathscale.com wrote:
Long term the API to pkgcore could be
On Mon, 13 Jan 2014 18:21:58 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 13 Jan 2014 19:16:45 +0100
Tom Wijsman tom...@gentoo.org wrote:
On Mon, 13 Jan 2014 08:49:17 -0800
Alec Warner anta...@gentoo.org wrote:
The caching may not be of use, depending on your
On Mon, 13 Jan 2014 19:27:36 +0100
Tom Wijsman tom...@gentoo.org wrote:
Not an API. APIs are bad. What we should have is a good set of
lightweight Unix-friendly command line tools. See, for example, the
Scripting Commands section of man cave.
It still is an API that way, just expressed
On 11:02 Mon 13 Jan , Steven J. Long wrote:
On Mon, Jan 13, 2014 at 04:15:37PM +0700, C. Bergström wrote:
Realistically, we have to keep updating them both in parallel.
pkgcore needs to be brought up to portage-level functionality,
Yeah but it already outshines under the hood: all
On 01:53 Sun 12 Jan , Ryan Hill wrote:
fortran:
Do we want to keep enabling fortran by default? The majority of users
will never get the urge to install a fortran package, and the fortran
eclass handles those that do. I think it should be treated as all the
other optional languages
On 19:59 Sat 11 Jan , Peter Stuge wrote:
Duncan wrote:
Michał Górny wrote:
INSTALL_MASK=systemd bash-completion
What are your thoughts?
It seems like this will generally duplicate all -USE flags.
Would it make sense to instead have a single setting which changes
On 01/13/2014 10:58 PM, Tom Wijsman wrote:
On Mon, 13 Jan 2014 10:31:56 +0100
Fabio Erculiani lx...@gentoo.org wrote:
Portage can still take *minutes* to calculate the merge queue of a
pkg with all its deps satisfied.
Half a minute if you disable backtracking which you don't need. :)
Or
On Tue, 14 Jan 2014 07:22:25 +0800
Patrick Lauer patr...@gentoo.org wrote:
On 01/13/2014 10:58 PM, Tom Wijsman wrote:
On Mon, 13 Jan 2014 10:31:56 +0100
Fabio Erculiani lx...@gentoo.org wrote:
Portage can still take *minutes* to calculate the merge queue of a
pkg with all its deps
On Sunday 12 January 2014 02:53:47 Ryan Hill wrote:
While I'm adding USE defaults to toolchain.eclass and moving them out of
the profiles, I thought now would be a good time to review a couple
default flag settings.
mudflap:
This is currently enabled by default but I'd like to disable it.
On Mon, Jan 13, 2014, Alexander Berntsen wrote:
Updating both in parallel isn't hard: once pkgcore is up to EAPI-5,
EAPI-6 isn't that much work (mostly bash afair.)
If it is trivial: show us the code.
Ah that old canard. Tell you what: I hereby undertake to deliver
everything currently
On Mon, Jan 13, 2014, Ciaran McCreesh wrote:
On Mon, 13 Jan 2014 19:27:36 +0100
Tom Wijsman tom...@gentoo.org wrote:
Not an API. APIs are bad. What we should have is a good set of
lightweight Unix-friendly command line tools. See, for example, the
Scripting Commands section of man cave.
On Friday 10 January 2014 22:07:52 Chris Reffett wrote:
Attached is a patch to test if Portage is going to write to a
read-only filesystem and print out the list of filesystems that need
to be remounted RW. This leaves ${D} intact rather than having some
files moved before hitting the RO
people have been using pyflakes of late. not that i'm against adding this.
we should have a wrapper script:
$ cat pylint
#!/bin/sh
exec pylint --rcfile ${0%/*}/pylintrc $@
-mike
signature.asc
Description: This is a digitally signed message part.
cnf/make.conf.example.source_test| 7 +++
cnf/make.conf.example.source_test_after | 8
i don't think test files belong in cnf/. keep them in the same dir as the test
that uses them.
-mike
signature.asc
Description: This is a digitally signed message part.
On Monday 13 January 2014 19:08:30 creff...@gentoo.org wrote:
From: Chris Reffett creff...@gentoo.org
you might want to set ~/.gitconfig to have your name/email so that git
sendemail uses the right info in the actual e-mail From: field
+ undefined_phases_re =
On Mon, 13 Jan 2014 19:50:44 -0500
Mike Frysinger vap...@gentoo.org wrote:
On Monday 13 January 2014 19:08:30 creff...@gentoo.org wrote:
From: Chris Reffett creff...@gentoo.org
Subject: [gentoo-portage-dev] [PATCH] Add repoman check to warn if
src_prepare/src_configure are used in EAPI 0/1
seems reasonable, although i haven't used the shlex module myself before
-mike
signature.asc
Description: This is a digitally signed message part.
On Mon, 2014-01-13 at 23:59 -0500, Mike Frysinger wrote:
On Monday 13 January 2014 22:23:01 Tom Wijsman wrote:
On Mon, 13 Jan 2014 19:50:44 -0500 Mike Frysinger wrote:
On Monday 13 January 2014 19:08:30 creff...@gentoo.org wrote:
From: Chris Reffett creff...@gentoo.org
Subject:
55 matches
Mail list logo
