On Mon, Jan 13, 2014, Ciaran McCreesh wrote:
> On Mon, 13 Jan 2014 19:27:36 +0100
> Tom Wijsman 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 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 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
On Tue, 14 Jan 2014 07:22:25 +0800
Patrick Lauer wrote:
> On 01/13/2014 10:58 PM, Tom Wijsman wrote:
> > On Mon, 13 Jan 2014 10:31:56 +0100
> > Fabio Erculiani wrote:
> >
> >> Portage can still take *minutes* to calculate the merge queue of a
> >> pkg with all its deps satisfied.
> >
> > Half
On 01/13/2014 10:58 PM, Tom Wijsman wrote:
> On Mon, 13 Jan 2014 10:31:56 +0100
> Fabio Erculiani 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 if you d
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
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 languag
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 h
On Mon, 13 Jan 2014 19:27:36 +0100
Tom Wijsman 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 differen
On Mon, 13 Jan 2014 18:21:58 +
Ciaran McCreesh wrote:
> On Mon, 13 Jan 2014 19:16:45 +0100
> Tom Wijsman wrote:
> > On Mon, 13 Jan 2014 08:49:17 -0800
> > Alec Warner wrote:
> > > The caching may not be of use, depending on your configuration.
> > > (For example, if you use a gentoo-x86 che
On Mon, 13 Jan 2014 18:07:39 +
Ciaran McCreesh wrote:
> On Mon, 13 Jan 2014 15:46:59 +0100
> Tom Wijsman wrote:
>
> > On Mon, 13 Jan 2014 16:15:37 +0700
> > "C. Bergström" wrote:
> >
> > > Long term the API to pkgcore could be beneficial, but
> > > again I'm not sure it's a game changer
On Mon, 13 Jan 2014 19:16:45 +0100
Tom Wijsman wrote:
> On Mon, 13 Jan 2014 08:49:17 -0800
> Alec Warner 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 cach
On Mon, 13 Jan 2014 18:05:21 +
Ciaran McCreesh wrote:
> On Mon, 13 Jan 2014 16:46:08 +0100
> Tom Wijsman 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 preserve
On Mon, 13 Jan 2014 08:49:17 -0800
Alec Warner 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 cache ebuild me
On Mon, 13 Jan 2014 18:03:31 +0100
Luis Ressel 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 yesterday whil
On Mon, 13 Jan 2014 15:46:59 +0100
Tom Wijsman wrote:
> On Mon, 13 Jan 2014 16:15:37 +0700
> "C. Bergström" 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 to
On Mon, 2014-01-13 at 15:46 +0100, Tom Wijsman wrote:
> On Mon, 13 Jan 2014 16:15:37 +0700
> "C. Bergström" 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 tool
On Mon, 13 Jan 2014 16:46:08 +0100
Tom Wijsman 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 used to be a "fea
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 "evolve
> 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
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
kerne
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 Li
On Mon, Jan 13, 2014 at 5:49 PM, Alec Warner 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 turning off
> that
On Mon, 13 Jan 2014 16:46:08 +0100
Tom Wijsman wrote:
> On Mon, 13 Jan 2014 16:38:59 +0100
> Luis Ressel wrote:
>
> > On Mon, 13 Jan 2014 15:58:13 +0100
> > Tom Wijsman wrote:
> >
> > > Half a minute if you disable backtracking which you don't need. :)
> >
> > Which sadly also means that som
On Mon, Jan 13, 2014 at 7:38 AM, Luis Ressel wrote:
> On Mon, 13 Jan 2014 15:58:13 +0100
> Tom Wijsman wrote:
>
> > On Mon, 13 Jan 2014 10:31:56 +0100
> > Fabio Erculiani wrote:
> >
> > > Portage can still take *minutes* to calculate the merge queue of a
> > > pkg with all its deps satisfied.
>
On Mon, Jan 13, 2014 at 7:38 AM, Tom Wijsman wrote:
> On Mon, 13 Jan 2014 15:46:12 +0100
> Peter Stuge 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
On Mon, 13 Jan 2014 16:38:59 +0100
Luis Ressel wrote:
> On Mon, 13 Jan 2014 15:58:13 +0100
> Tom Wijsman 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 would trigger rebuilds of o
On Mon, 13 Jan 2014 15:58:13 +0100
Tom Wijsman wrote:
> On Mon, 13 Jan 2014 10:31:56 +0100
> Fabio Erculiani 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.
On Mon, 13 Jan 2014 15:46:12 +0100
Peter Stuge 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 mostly
> on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 13 Jan 2014 09:56:13 -0500
Ian Stakenvicius 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"
> > wrote:
> >
> >> Long term the API
On Mon, 13 Jan 2014 14:50:44 +0100
Ulrich Mueller 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 collecti
On Mon, 13 Jan 2014 11:02:10 +
"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;
pkgcore's response to EAPI 6 is something to hold your breath for.
> I'm sure he and dol-sen would be happy for more help
On Mon, 13 Jan 2014 10:31:56 +0100
Fabio Erculiani 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 twice, will take m
-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"
> 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 16:15:37 +0700
"C. Bergström" 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 "evolved" could
real
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" 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 users want to use them
On Mon, 13 Jan 2014 15:39:17 +0700
C. Bergström 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 one PM to another and ex
> 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:
http://wiki.gentoo.org/wiki/Future_EAP
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 t
-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
> supportiv
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
On 01/13/14 04:31 PM, Fabio Erculiani wrote:
On Mon, Jan 13, 2014 at 10:15 AM, "C. Bergström"
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
On Mon, Jan 13, 2014 at 10:15 AM, "C. Bergström"
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 which have build depen
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 updating
On Mon, Jan 13, 2014 at 9:39 AM, C. Bergström 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?
-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 bro
Drive-by trolling comment but I wish the effort to keep porkage alive would have instead been directed towards pkgcore.
48 matches
Mail list logo
