Ciaran McCreesh [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Fri, 13 Jun
2008 06:26:12 +0100:
On Fri, 13 Jun 2008 09:30:54 +0530
Arun Raghavan [EMAIL PROTECTED] wrote:
And why do you have to be plain insulting about it? Nobody can
magically spot every single bug in any
On Fri, 13 Jun 2008 08:16:57 + (UTC)
Duncan [EMAIL PROTECTED] wrote:
I agree entirely. Why the pkgcore people refuse to do basic
automated tests is completely beyond me.
That may or may not be, but it's beside the point. The point is that
a bug was found, that fact was stated, and
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 21:40:28 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
* ordering for _pre is wrong.
hm?
foo-0.26-live would become foo-0.26_pre1, which would be 0.26. This
is clearly wrong.
No, it is correct and what you want. Upstream is aiming for 0.26, once
On 13 Jun 2008, at 10:43, Luca Barbato wrote:
* What's the filename for live ebuild for SVN trunk/? What about
foo-${version inside trunk}.live?
And when trunk is unversioned?
Upstream has an issue, still you know which is the version they aim.
Wrong. Your GLEP has an issue because it
On Fri, 13 Jun 2008 10:43:39 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 21:40:28 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
* ordering for _pre is wrong.
hm?
foo-0.26-live would become foo-0.26_pre1, which would be 0.26.
This is clearly
Ciaran McCreesh wrote:
On Fri, 13 Jun 2008 09:30:54 +0530
Arun Raghavan [EMAIL PROTECTED] wrote:
And why do you have to be plain insulting about it? Nobody can
magically spot every single bug in any piece of code presented to
them. In fact it's why the given enough eyes ... adage is one of
On 13 Jun 2008, at 11:01, Patrick Lauer wrote:
Ciaran McCreesh wrote:
On Fri, 13 Jun 2008 09:30:54 +0530
Arun Raghavan [EMAIL PROTECTED] wrote:
And why do you have to be plain insulting about it? Nobody can
magically spot every single bug in any piece of code presented to
them. In fact it's
On Fri, 13 Jun 2008 11:01:19 +0200
Patrick Lauer [EMAIL PROTECTED] wrote:
Just to pour some oil on the flames -
Y'all are aware that paludis can't parse a valid make.conf and does
ignore package.keywords at times, yes?
Yep. We don't claim to or aim to completely support Portage configs.
Ciaran McCreesh wrote:
On Fri, 13 Jun 2008 10:43:39 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 21:40:28 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
* ordering for _pre is wrong.
hm?
foo-0.26-live would become foo-0.26_pre1, which would
Fernando J. Pereda wrote:
Just to pour some oil on the flames -
Then don't do it. You are doing a very bad marketing for the pkgcore
guys with your whinnings.
Dude. Shut up.
I'm not a pkgcore guy. If anything I'm a portage supporter. That I
accidentally host pkgcore.org doesn't mean I'm
Ciaran McCreesh wrote:
On Fri, 13 Jun 2008 10:43:39 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 21:40:28 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
* ordering for _pre is wrong.
hm?
foo-0.26-live would become foo-0.26_pre1, which would
On Fri, 13 Jun 2008 11:14:49 +0200
Tiziano Müller [EMAIL PROTECTED] wrote:
How does your proposal handle this?
s/_pre/_p ?
Collides with existing use of _p. It means you can't use _p for manual
snapshots if there's also a live ebuild, since foo-1.2_p3 (from a live
ebuild) would incorrectly
On Fri, 13 Jun 2008 11:16:31 +0200
Patrick Lauer [EMAIL PROTECTED] wrote:
Yes, we are aware of that bug in a feature we consider highly
experimental.
Hmm, I'd have guessed config files are moderately relevant.
You didn't notice the large warning telling you not to use Portage
config files?
Tiziano Müller wrote:
@lu_zero: I don't think we can get away without having the pm know what a
live-ebuild exactly is and when to re-install it.
a live ebuild is a template, every time it has to be evaluated it acts
as a normal ebuild with the version mentioned and _preN+1 postponed,
preN
Thank you for your reply.
Christian Faulhammer wrote:
Yes! Always. Maybe test stabilisation requests for packages. See
the archtester programs of amd64 or x86 how that works.
Hmm, archtester seems to be good for my first aim as a role.
I will be on IRC as the faq says( Though, No one in
On 13 Jun 2008, at 11:16, Patrick Lauer wrote:
Then don't do it. You are doing a very bad marketing for the
pkgcore guys with your whinnings.
I'm not a pkgcore guy. If anything I'm a portage supporter. That I
accidentally host pkgcore.org doesn't mean I'm one of them.
Were you able to
Ciaran McCreesh wrote:
On Fri, 13 Jun 2008 11:16:31 +0200
Patrick Lauer [EMAIL PROTECTED] wrote:
Yes, we are aware of that bug in a feature we consider highly
experimental.
Hmm, I'd have guessed config files are moderately relevant.
You didn't notice the large warning telling
On Friday 13 June 2008 03:20:23 Brian Harring wrote:
1) http://bugs.gentoo.org/show_bug.cgi?id=171291
metadata/cache (hence labeled flat_list cache format) mtime
requirements.
The current spec attempts to handle things as well as possible on the package
manager side. If you'd like it to be
Luca Barbato wrote:
Tiziano Müller wrote:
@lu_zero: I don't think we can get away without having the pm know what a
live-ebuild exactly is and when to re-install it.
a live ebuild is a template, every time it has to be evaluated it acts
as a normal ebuild with the version mentioned and
On Fri, 13 Jun 2008 11:53:02 +0200
Patrick Lauer [EMAIL PROTECTED] wrote:
You didn't notice the large warning telling you not to use Portage
config files?
I did. But how else can I compare things or move back to portage if I
don't like it?
You can set up a Paludis config. It's nice
On Fri, Jun 13, 2008 at 2:52 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
And why don't y'all fix a bug like that?
We do what PMS requires regarding handling of inline comments (which is
the same as what some EAPI 0 accepting Portage versions do, so PMS
can't allow inline comments), and
On Fri, 13 Jun 2008 15:40:46 +0530
Nirbheek Chauhan [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 2:52 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
And why don't y'all fix a bug like that?
We do what PMS requires regarding handling of inline comments
(which is the same as what some
Hi,
Takashi Yoshii [EMAIL PROTECTED]:
Christian Faulhammer wrote:
Yes! Always. Maybe test stabilisation requests for packages. See
the archtester programs of amd64 or x86 how that works.
Hmm, archtester seems to be good for my first aim as a role.
I will be on IRC as the faq says(
On Fri, Jun 13, 2008 at 3:27 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
Where possible, we exclude things that break Portage. Are you
suggesting that we should instead ignore what EAPI-0-supporting Portage
does and does not handle and just document things the way we'd like
them to be?
Wait,
On Friday 13 June 2008 11:10:46 Nirbheek Chauhan wrote:
Interesting to note, however, that Paludis doesn't accept inline
comments, and this behaviour predates PMS.
There's a reason for Paludis not accepting them, and the same reason applies
to the question of allowing them in PMS or not,
On Fri, Jun 13, 2008 at 3:44 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
But some EAPI-0 accepting Portage versions don't accept inline
comments. Using inline comments in the tree will break those Portage
versions.
This one's especially an issue when you consider how long it's been
since
On Friday 13 June 2008 11:18:53 Nirbheek Chauhan wrote:
Wait, what?
Where possible ?
You'd prefer us to do impossible things too?
PMS is supposed to be a specification which is as close to Gentoo's
Official Package manager's behaviour as possible while (preferably)
leaving out deprecated
David Leverton wrote:
On Friday 13 June 2008 11:10:46 Nirbheek Chauhan wrote:
Interesting to note, however, that Paludis doesn't accept inline
comments, and this behaviour predates PMS.
There's a reason for Paludis not accepting them, and the same reason applies
to the question of allowing
On Fri, Jun 13, 2008 at 3:49 PM, David Leverton
[EMAIL PROTECTED] wrote:
On Friday 13 June 2008 11:10:46 Nirbheek Chauhan wrote:
Interesting to note, however, that Paludis doesn't accept inline
comments, and this behaviour predates PMS.
There's a reason for Paludis not accepting them, and the
On Fri, 13 Jun 2008 15:48:53 +0530
Nirbheek Chauhan [EMAIL PROTECTED] wrote:
PMS is supposed to be a specification which is as close to Gentoo's
Official Package manager's behaviour as possible while (preferably)
leaving out deprecated behaviour. But right now you're saying:
We're writing a
On 13 Jun 2008, at 12:18, Nirbheek Chauhan wrote:
We're writing a spec that's somewhat like Portage, but where it
breaks Paludis, we prefer to get Portage to change it's behaviour
instead. Don't crib about this however. We could just have easily have
created a whole new spec which broke Portage
Tiziano Müller wrote:
Luca Barbato wrote:
Tiziano Müller wrote:
@lu_zero: I don't think we can get away without having the pm know what a
live-ebuild exactly is and when to re-install it.
a live ebuild is a template, every time it has to be evaluated it acts
as a normal ebuild with the
On Fri, 13 Jun 2008 15:52:30 +0530
Nirbheek Chauhan [EMAIL PROTECTED] wrote:
Interesting to note, however, that Paludis doesn't accept inline
comments, and this behaviour predates PMS.
Paludis behaviour there matches Portage behaviour at the time it was
written, except that instead of
On Friday 13 June 2008 11:23:29 Nirbheek Chauhan wrote:
On Fri, Jun 13, 2008 at 3:49 PM, David Leverton
There's a reason for Paludis not accepting them, and the same reason
applies to the question of allowing them in PMS or not, therefore PMS
doesn't allow them. There's no evil conspiracy
On Fri, Jun 13, 2008 at 11:32:20AM +0100, David Leverton wrote:
On Friday 13 June 2008 11:23:29 Nirbheek Chauhan wrote:
On Fri, Jun 13, 2008 at 3:49 PM, David Leverton
There's a reason for Paludis not accepting them, and the same reason
applies to the question of allowing them in PMS or
On Fri, Jun 13, 2008 at 10:43:39AM +0200, Luca Barbato wrote:
Anyway pkgcore and portage devs, I'd like your opinion on this point.
Custom repository is how I intended to implement this; the upshot of
the version translation is that the resultant vdb version is managable
by any PM, regardless
On Fri, 13 Jun 2008 04:14:38 -0700
Brian Harring [EMAIL PROTECTED] wrote:
One other thing that needs discussion imo, is how such a scheme would
work for non integer based revnos- git for example, which is reliant
on a hash (just the hash, afaik).
Neither Luca's proposal nor -scm even
Brian Harring wrote:
Custom repository is how I intended to implement this; the upshot of
the version translation is that the resultant vdb version is managable
by any PM, regardless if they support -live, which 'generated' the
ebuild.
Presuming svn python bindings aren't as sucky as I
On Fri, 13 Jun 2008 13:32:47 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
The revision has to be stored inside the generated ebuild so all you
need to have is:
- a way to know the revision you are checking out
- a way to store such revision withing the ebuild
- a way of doing this cheaply
On Thu, 12 Jun 2008 11:05:01 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Piotr Jaroszyński wrote:
Hello,
looks like every nominee wants the council to be more technical so I
have a few technical questions for you:
1. GLEP54
Just for fun I took some of the ideas about alternative
Nirbheek Chauhan [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted
below, on Fri, 13 Jun 2008 15:52:30 +0530:
Well, then it should be updated to match current Portage behaviour. PMS
is not supposed to document How portage worked at one point of time or
The intersection of the capabilities
Hi all,
As discussed in bug #222721, portage has changed the execution order
of phases. It seems the change was introduced in portage-2.1.5 and it
makes that, when upgrading a package, pkg_postinst is run after the
old version has been removed. This breaks packages which use
has_version in
On Fri, 13 Jun 2008 13:35:52 +0200
Marius Mauch [EMAIL PROTECTED] wrote:
Ignoring possible semantic issues for the moment, I'd be against this
simply because it would require the PM to be aware of the current
revision of the repository and to transform it into a integer value
(trivial for
43 matches
Mail list logo
