Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds
On 18 August 2011 11:53, Diego Elio Pettenò flamee...@gentoo.org wrote: Il giorno gio, 18/08/2011 alle 05.46 -0400, Anthony G. Basile ha scritto: What alternative are you proposing to mirror://gentoo/ if upstream doesn't provide a tarball, eg with large patchsets the maintainer constructs? Anticipating your answer might be keep them in your dev space, then what would be the deprecation policy for distfiles that are no longer used by ebuilds? If foresee a tension between keeping all the distfiles vs disk space, although Patrick's point of cheap hardware is well taken. Keep it in your dev space. As I said, the resources argument is only available for infra to complain about, and since last I knew from them was that it was not a problem right now... And what if the dev retires/is kicked out? -- Best Regards Piotr Jaroszyński
Re: [gentoo-dev] Please help us decide naming scheme for cmake use calls
as we discussed on scons.eclass thread at -dev ml we should have some nice naming scheme for use_xxx calls with cmake and scons. And it should be done in same fashion. for both So please head up to the formus poll [1] and vote for your favorite. Apparently I don't even have a dev forum account set up (and I don't care), but count my vote as who cares if there's such an option. -- Best Regards Piotr Jaroszyński
[gentoo-dev] Re: Council Agenda 20100809 rev 01
On 7 August 2010 15:16, Brian Harring ferri...@gmail.com wrote: I suspect we may not wind up being able to get to it in the coming meeting, but I'd like g55 sorted. Specifically, if the authors of it (cc'd) want it to move forward, request the council vote on it. If you don't want it voted on, mark it moribund. As I stated at the last meeting, go ahead and vote on it. I still think it would be very useful for Gentoo to accept it, I just kinda lost hope after 2 or 3 times when it was supposed to be voted upon already. -- Best Regards Piotr Jaroszyński
Re: [gentoo-dev] Re: Upcoming Council meeting on July 26th, 1900 UTC
On 19 July 2010 01:27, Duncan 1i5t5.dun...@cox.net wrote: Dale posted on Sun, 18 Jul 2010 12:43:43 -0500 as excerpted: It always seemed to me that people want to send threads to -project for them to just go away. Once a thread goes to -project, it just whithers on the vine and nothing much happens. There may be a need for -project but if almost no one is going to be there, there is no point sending threads to it. Maybe developers should be required to subscribe to -project so that even if a thread is sent there, they still get to see the postings and deal with the issues that are being raised. I think that was the point. Having the list and telling people the topic belongs there is the polite way of telling them their output's better directed to /dev/null (which is of course the the geeky *ix way of saying shutup already!), without actually restricting someone's right to make their point... just that they might as well be posting to their private diary for the number of others that'll actually read it. Yeah, that's exactly a thread that belongs to -project and not -dev. -- Best Regards Piotr Jaroszyński
Re: [gentoo-dev] are hardened-sources maintained?
On 1 April 2010 15:43, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Of course that would mean getting included in hardened-ker...@gentoo.org, but I guess it's the easiest part. Yes, you can do it yourself: woodpecker ~ $ echo $USER /var/mail/alias/misc/hardened-kernel -- Best Regards Piotr Jaroszyński
[gentoo-dev] Re: [gentoo-council] pkg_pretend USE validation and VALID_USE alternative
| Occasionally, ebuilds will have conflicting USE flags for | functionality. Checking for them and returning an error is not a | viable solution. Instead, you must pick one of the USE flags in | conflict to favour. [1] http://devmanual.gentoo.org/general-concepts/use-flags/ I honestly consider the ebuild silently making decisions on the user's behalf *worse*. Consider if openoffice silently made decisions like that- 4 hours later it'll wind up choosing the option you didn't really want and you'll be in a foul mood. I'm pretty sure it says that because there was no way to fail early before. And failing in the middle of 300 packages upgrade because some useflags are in conflict wasn't reasonable. -- Best Regards Piotr Jaroszyński
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
2009/6/1 Dawid Węgliński c...@gentoo.org: On Monday 01 of June 2009 06:25:06 Jorge Manuel B. S. Vicetto wrote: Hello fellow developers and users. I nominate: peper Thank you, I accept. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
2009/6/2 Doug Goldstein car...@gentoo.org: All, The current council meetings have gotten completely out of hand for weeks meetings have become nothing more then a continuation of the senseless bicker-fest that have become the e-mail threads on GLEP54, GLEP55, and EAPI-3 without any real progress or sense coming of them. It's taken me a little bit to step up and put a stop to it but I fully intend on putting a stop to it. The point of the council meetings is to bring up a topic and decide on its merits whether it should be brought into the Gentoo Project or not. I quote from the first line of the Gentoo Council website: I am the author of both mentioned GLEPs but I don't feel too guilty about that. Council had every opportunity to decide upon them , one way or another, or state clearly that they don't like this or that. Instead, there has been a pointless discussion each time (4c comes to mind here). Imho, council should be less afraid to make difficult decisions. The elected Gentoo Council decides on global issues and policies that affect multiple projects in Gentoo. We have all collectively failed the Gentoo Project since we have not been doing this for the past several weeks. I propose the following changes be instituted before the meeting and happen through the meeting: 1) Agenda Topics are posted to the appropriate mailing lists at a MINIMUM 7 days prior to the meeting. (That means the agenda must be formed by this Thursday). 1a) Any changes to the agenda should be ACK'd by the council members (off list via the council alias). Changes can not occur less than 48 hours from the meeting. Sounds good, but I would still allow some flexibility even during the meeting if no-one objects. 2) The #gentoo-council channel become moderated as we had discussed several times in the past. 2a) Topics will be brought up and people wishing to address the council and the developer body at large should speak to the day's appointed moderator. We can take turns or I can do it (maybe it'll keep my head from banging against the keyboard as it has in the past watching the various non-council members argue completely non-agenda items back and forth). 2b) Requests are made in tells and honored in turn. The moderator will announce to the channel who wishes to speak and the order they are in and will efficiently work through the list. If you can not remain on topic, you will lose your voice. I wouldn't be so strict here, use it as last resort. 3) Once discussion on the topic has concluded, the council members will vote on the actions requested by the developer body. That does not mean it is time for council members to concoct an entirely new plan by the seat of their pants... which leads me to the next topic. ++ 4) Council members will now be expected to ACK the agenda on the appropriate mailing lists at least 48 hours prior to the meeting. If you can't, let the council know. You should be able to do this without relying on your proxy, but your proxy may do this for you as well if you have an extended away. 4a) Failure to ACK the agenda will be noted on the meeting minutes. 4b) Council members will be expected to formulate their thoughts in reply to the agenda items and to research the discussion they wish to have on the mailing list PRIOR to the meeting and not fly by the seat of their pants. 4c) The first I heard of this and I need 4 weeks to research this. or any variation of the quoted statement is no longer a valid statement. The point of the meeting is to weigh and debate the items before us now. Do your research PRIOR to the meeting, not during. 4c) is the most important imho. Also, I think meetings shouldn't be limited to 1 hour. I would move the limit to at least 2 hours. Even if the process is improved, 1 hour is just not enough. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Re: RFC:sys-apps/portage @overlay atoms postfix support
2009/6/2 Duncan 1i5t5.dun...@cox.net: :: lacks that confusion. It does have the additional complication of needing quoted or escaped in the shell, but users are supposed to do a --pretend anyway, and after it doesn't output what's expected, a user of any shell experience at all should conclude with little delay that it /could/ be the escaping even if they aren't sure, and a quick suitably escaped trial will confirm it. Where/when does :: need escaping? -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] GLEP 54 and hyphens in PV
2009/5/28 Ulrich Mueller u...@gentoo.org:
On Thu, 28 May 2009, Tiziano Müller wrote:
${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
you probably mean:
${PORTDIR}/app-misc/foo-1a/foo-1a.live.ebuild
No, I mean what I had written, namely to use an underscore as
separator, i.e., _live. But when the version is just live alone,
one would suppress the underscore for aesthetic reasons, i.e. instead
of foo-1a-_live it would be foo-1a-live.
but how would their vdb or binpkg names be unique?
vdb for example:
app-misc/foo-1a_live for app-misc/foo
PN=foo, PV=1a_live = app-misc/foo-1a_live
app-misc/foo-1a_live for app-misc/foo-1a
PN=foo-1a, PV=live = app-misc/foo-1a-live
am I missing something?
Everything is easy, if you keep the following rule in mind:
With our current versioning scheme the rule is very simple: ${P} is
split into ${PN} and ${PV} at the last hyphen. This can be done in
a straight forward way by regexp matching, and I would really hate
to lose this nice property.
I don't understand why this property is important. Can you please
explain?
See above, it automatically avoids any ambiguities in splitting P into
PN and PV. And look at function pkgsplit in Portage: It can just
treat PV as an opaque string.
What would be the advantage to use a hyphen instead of an underscore?
Mainly the thing you observed yourself - foo_live is a bit
inconsistent with current versions.
The case you mention can be avoided with another restriction in PMS.
Buut we might as well go all the way and change the version separator
to -- or something, which would be the most flexible.
--
Best Regards,
Piotr Jaroszyński
Re: [gentoo-dev] GLEP 54 and hyphens in PV
2009/5/28 Marijn Schouten (hkBst) hk...@gentoo.org:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Piotr Jaroszyński wrote:
2009/5/28 Ulrich Mueller u...@gentoo.org:
On Thu, 28 May 2009, Tiziano Müller wrote:
${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
you probably mean:
${PORTDIR}/app-misc/foo-1a/foo-1a.live.ebuild
No, I mean what I had written, namely to use an underscore as
separator, i.e., _live. But when the version is just live alone,
one would suppress the underscore for aesthetic reasons, i.e. instead
of foo-1a-_live it would be foo-1a-live.
but how would their vdb or binpkg names be unique?
vdb for example:
app-misc/foo-1a_live for app-misc/foo
PN=foo, PV=1a_live = app-misc/foo-1a_live
app-misc/foo-1a_live for app-misc/foo-1a
PN=foo-1a, PV=live = app-misc/foo-1a-live
am I missing something?
Everything is easy, if you keep the following rule in mind:
With our current versioning scheme the rule is very simple: ${P} is
split into ${PN} and ${PV} at the last hyphen. This can be done in
a straight forward way by regexp matching, and I would really hate
to lose this nice property.
I don't understand why this property is important. Can you please
explain?
See above, it automatically avoids any ambiguities in splitting P into
PN and PV. And look at function pkgsplit in Portage: It can just
treat PV as an opaque string.
What would be the advantage to use a hyphen instead of an underscore?
Mainly the thing you observed yourself - foo_live is a bit
inconsistent with current versions.
Ulrich is proposing foo-live if live is the entire version, foo_live is not a
legal `package name and version'. (It could be a package name though.)
I know, it's also inconsistent. Anyway that's really not that
important. We could forbid package names that end with a -$PV where
$PV is a valid version spec. That would make package names like foo-1b
invalid (didn't see anything named like that in the tree anyway).
The case you mention can be avoided with another restriction in PMS.
Buut we might as well go all the way and change the version separator
to -- or something, which would be the most flexible.
That would also be a good solution though we don't seem to need it yet. It
would
also entail compatibility issues.
Not with g55.
--
Best Regards,
Piotr Jaroszyński
Re: [gentoo-dev] How not to discuss
2009/5/28 Joe Peterson lava...@gentoo.org: Alec Warner wrote: No, it's entirely objective. GLEP 55 clearly shows how the filename based options are objectively better than anything else. But the decision will not be based entirely on objective merits (although I will concede that EAPI in filename is the 'best' technical choice). (Jeez, I hate to add another to this thread, but this way of defining 'technical' bothers me) Along the lines of what Roy so eloquently expressed, I think it's important that we do not divorce *design* from *technical*. The decision of where to place the EAPI is a design issue, and many of us here clearly believe that it is *not* good design to put this kind of metadata in the filename. Therefore, the statement that it is the 'best' technical choice is not objectively true. Technical issues of performance and efficiency can be addressed when proper design has been done beforehand. Part of the purpose of the implementation (after proper design is in place) is to address performance and other related issues. And part of the design is how we define the *interface*. The filename is clearly part of the interface. It is part of how devs (and users) interact with portage when writing ebuilds. Much of the argument for EAPI in the filename has been motivated by a perceived implementation benefit of speed, as if there were no other solutions (which is naive). As Roy suggested, if all engineering decisions were based purely on pragmatic ease of implementation factors, we'd have a lot of ugly designs/interfaces out there. It may be easy (although incorrect) to dismiss elegance/design/interface issues as non-technical, but I maintain they actually *are* technical matters of great importance. I've been an engineer for over 20 years, and I have seen the pitfalls of taking the quick-and-dirty approach just to slap a new feature into a software app. I've seen how such hasty design mistakes can cause great pain and regret for a long time after. Let's get the design right, first. For what it's worth, GLEP 55 does now provide an option (#3: Easily fetchable EAPI inside the ebuild and one-time extension change) that demonstrates good design. I think what you are missing is that some people (me included) think that the in-file approach is the cleanest and most obvious solution (which also happens to not hurt performance). So if you want bad design to be an objective argument you need to back it up with something concrete. For example, could you foresee any actual problems of the in-filename approach? Cause all I was hearing was it doesn't look nice which now is oh no, don't expose metadata. The former is clearly subjective and the latter is already done ($PN-$PV) and doesn't seem to cause any problems. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Gentoo Council Reminder for May 28
2009/5/27 Patrick Lauer patr...@gentoo.org: On Wednesday 27 May 2009 22:57:25 Joe Peterson wrote: Gentoo should not repeat the VHS vs Betamax war. For those who do not remember, VHS was the better marketed but inferior technical solution that won the standards war for domestic Video recorders. :) Yep. And bad design decisions can haunt is for a long time. Actually, once we add the current-glep55 changes we have no way of sanely undoing them if we should realize that they don't work out for us ... ... unless we do horrible things like forbidding it, which would cause the same errors we are trying to hide now. So unless we have a plan for mid-term future changes I don't see why we would want the current GLEP55 - it's a one-way change in the current state. How is it one-way exactly? You can do pretty much anything you want in a new EAPI (that's the point). My preference is the one-time .ebuild-.eb change, and putting the EAPI on the first line, like a #!shebang. Very easy to extract, and good design. My preference is freezing the rsync tree, storing all referenced distfiles on at least one mirror, then change the rsync path. That way all old users get the last sane upgrade position (...) And bugs and security vulnerabilities too. Or do you propose maintaining multiple trees at the same time? I think one of the main points of EAPI was to avoid doing exactly that. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Gentoo Council Reminder for May 28
2009/5/28 Patrick Lauer patr...@gentoo.org:
On Thursday 28 May 2009 00:12:56 Piotr Jaroszyński wrote:
2009/5/27 Patrick Lauer patr...@gentoo.org:
On Wednesday 27 May 2009 22:57:25 Joe Peterson wrote:
Gentoo should not repeat the VHS vs Betamax war. For those who do not
remember, VHS was the better marketed but inferior technical solution
that won the standards war for domestic Video recorders.
:) Yep. And bad design decisions can haunt is for a long time.
Actually, once we add the current-glep55 changes we have no way of sanely
undoing them if we should realize that they don't work out for us ...
... unless we do horrible things like forbidding it, which would cause
the same errors we are trying to hide now.
So unless we have a plan for mid-term future changes I don't see why we
would want the current GLEP55 - it's a one-way change in the current
state.
How is it one-way exactly? You can do pretty much anything you want in
a new EAPI (that's the point).
You cannot undo it.
In other words, you'll have to allow stupid filenames until the end of times
even if you are quite positively sure that it is, right now, a bad idea.
What do you mean by allow exactly? You can put whatever filenames in
the tree currently and package managers ignore them, just as they
would ignore *.ebuild-$eapi where $eapi is unsupported. So should g55
be accepted, implemented and then undone you would lose only
*.ebuild-{EAPIs introduced before undoing}.
My preference is the one-time .ebuild-.eb change, and putting the EAPI
on the first line, like a #!shebang. Very easy to extract, and good
design.
My preference is freezing the rsync tree, storing all referenced
distfiles on at least one mirror, then change the rsync path.
That way all old users get the last sane upgrade position (...)
And bugs and security vulnerabilities too. Or do you propose
maintaining multiple trees at the same time? I think one of the main
points of EAPI was to avoid doing exactly that.
Not at all. Just an upgrade snapshot so you can get old users into a known
state, then let them upgrade at least the package manager to a point where
they can use the rest. That snapshot should be seen as a transient helper, not
as a release ...
So a user n snapshots behind would have to go through various upgrade
paths n times. And if she failed to do it all at once her system would
be left with known bugs and vulnerabilities. Sounds a bit messy to me,
especially as it can be easily avoided (with improved EAPIs - i.e.
g55).
--
Best Regards,
Piotr Jaroszyński
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009/5/20 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org: 2009-05-17 19:02:02 Piotr Jaroszyński napisał(a): 2009/5/17 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: 2009-05-17 18:37:32 Ciaran McCreesh napisał(a): On Sun, 17 May 2009 18:20:21 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). No good, for two reasons. First, this is a global scope change Why do you think that it is a global scope change? I have updated the glep, see how it breaks [1]. [1] - http://dev.gentoo.org/~peper/glep-0055.html#use-newer-bash-features This error occurs only when there is no up-to-date cache for given ebuild. rsync users would see only the usual masked by: EAPI 3 message. Relying on cache being valid is doomed to fail. Among other things, what about overlays? -- Best Regards, Piotr Jaroszyński
[gentoo-dev] GLEP 55 updated
Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I can live with any of these if that's what it takes to move forward. Imho, council should first vote on whether they see the problem described in the GLEP as real (do we all agree on that at least?) and then pick one of these solutions. P.S. I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. [1] - http://dev.gentoo.org/~peper/glep-0055.html (http://www.gentoo.org/proj/en/glep/glep-0055.html once it synces) -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009/5/17 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. This is glep 55 material. I will update it to reflect that. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009/5/17 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: 2009-05-17 18:37:32 Ciaran McCreesh napisał(a): On Sun, 17 May 2009 18:20:21 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). No good, for two reasons. First, this is a global scope change Why do you think that it is a global scope change? I have updated the glep, see how it breaks [1]. [1] - http://dev.gentoo.org/~peper/glep-0055.html#use-newer-bash-features -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Re: GLEP 55 updated
2009/5/17 Ryan Hill dirtye...@gentoo.org: On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I can live with any of these if that's what it takes to move forward. I'd like 2 if we could have multiple same-versioned ebuilds of different EAPI. 3 is good enough for me. That's covered in the GLEP: Note that it is still not permitted to have more than one ebuild with equal category, package name, and version. Although it would have the advantage of allowing authors to provide backwards compatible ebuilds, it would introduce problems too. The first is the requirement to have strict EAPI ordering, the second is ensuring that all the ebuilds for a single category/package-version are equivalent, i.e. installing any of them has exactly the same effect on a given system. I don't see a way to overcome these problems in a sensible way. -- Best Regards, Piotr Jaroszyński
[gentoo-dev] Re: GLEP 55 updated
Just a heads up that I wrote a more detailed description of the peformance hit that EAPI in the ebuild introduces. Might come up with some numbers later too. [1] - http://dev.gentoo.org/~peper/glep-0055.html#easily-fetchable-eapi-inside-the-ebuild -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009/5/17 Ben de Groot yng...@gentoo.org: Arfrever Frehtes Taifersar Arahesis wrote: 2009-05-17 18:37:32 Ciaran McCreesh napisał(a): On Sun, 17 May 2009 18:20:21 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). No good, for two reasons. First, this is a global scope change Why do you think that it is a global scope change? Because he wants to push GLEP 55. Would you care to look at [1] and see how it breaks first before posting BS like that? Better yet test it youtself. [1] - http://dev.gentoo.org/~peper/glep-0055.html#use-newer-bash-features -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] GLEP 55 updated
2009/5/17 Robert Buchholz r...@gentoo.org: On Sunday 17 May 2009, Piotr Jaroszyński wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change Judging from this list, fourth option present in the GLEP is unacceptable for you? I would like to avoid user-visible breakage as much as possible. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] GLEP54 vs. package.mask (was: Council meeting summary for meeting on May 14, 2009)
2009/5/17 Thomas de Grenier de Latour tom...@free.fr: On 2009/05/17, Thomas Anderson gentoofa...@gentoo.org wrote: - Vote on GLEP 54 This vote was called for by dertobi123. The vote was on whether to approve GLEP 54 conditional on whether GLEP 55 is passed. The reason for this is that GLEP 54 is unimplementable without the problems mentioned in GLEP 55 being solved. Conclusion: Conditionally approved on whether GLEP 55 is approved. Sorry if the question has already been raised (i would be surprised it was not), but... Back in january [1], it was decided that base profile (and thus package.mask) should stay in EAPI=0 syntax. So once you've approved GLEP55 (or an alternative) and introduced an EAPI with support for -scm suffix, how will you package.mask this new-style live ebuilds? You set KEYWORDS=. If you need to do something in profiles with it you can use profile eapis. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Re: A few questions to our nominees
Using live templates is something more ^^; For now it looks to me like it is only more work. Could you please clarify what new functionality they provide? -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Re: Re: GLEP 55
The simplest way is to change the syncpoint in the new package manager and leave the previous uri with a compatibility repo for the older ones. So we add a new repo each time a new EAPI comes out? Sounds like a big mess. -- Best Regards, Piotr Jaroszyński ���^�X��� ��(��j)b�b�
Re: [gentoo-dev] Re: Re: A few questions to our nominees
That's true, it has at least to be aware the there's an EAPI. But how does such a package manager handle .ebuild-0 files? Ignore them? Failing because of unknown files in a package-dir? Should we care about package managers not being aware of the existence of EAPI's? Current portage would simply ignore them, which allows to use them right away in the tree (we would only need to make sure that developers touching packages using new format have up to date tools). Future portage would handle them nicely w/o the risk of dying when trying to figure out ebuild's EAPI, which is the point here. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Re: Re: Re: A few questions to our nominees
2008/6/9 Tiziano Müller [EMAIL PROTECTED]: Ciaran McCreesh wrote: On Mon, 09 Jun 2008 10:27:56 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: No point. A 0 package manager still couldn't use a 0.1 ebuild. That's true, it has at least to be aware the there's an EAPI. But how does such a package manager handle .ebuild-0 files? Ignore them? Failing because of unknown files in a package-dir? Should we care about package managers not being aware of the existence of EAPI's? Package managers can't do *anything* with ebuilds with unsupported EAPIs anyway. Encouraging package managers to handle ebuilds with unsupported EAPIs in any way just massively limits what can be done in future EAPIs. Em, that's really not what I meant. The main problem GLEP 55 describes is that with the current system we're limited to changes which don't break sourcing the ebuild (since if it would break sourcing we couldn't even find out the ebuild's EAPI version and therefore not whether the currently used package manager can handle that ebuild). That package managers can't do anything else than masking ebuilds with unsupported EAPIs is clear. But what I wanted to say is: Having the EAPI versioned like this: X.Y where X is the postfix part of the ebuild (foo-1.0.ebuild-X) and Y the EAPI=Y in the ebuild itself we could increment Y in case the changes to the EAPI don't break sourcing (again: a package manager will have to mask those ebuilds) while changes breaking the sourcing of the ebuild need an increment of X to avoid that pm's not being able to even source such an ebuild still can mask it properly (or just ignore it). What's the point of sourcing an ebuild that cannot be used anyway? -- Best Regards, Piotr Jaroszyński
[gentoo-dev] A few questions to our nominees
Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 2. GLEP55 3. Most wanted changes in future EAPIs [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] [RFC] Reducing the size of the system package set
On Tuesday 08 of January 2008 02:02:56 Petteri Räty wrote: Diego 'Flameeyes' Pettenò kirjoitti: Here comes the official proposal, copy and paste from my blog with an extra post scriptum at the end. I already ranted about the fact that the dependency tree of our ebuilds is vastly incomplete, as many lack dependency on zlib; trying to get this fixed was impossible, as Donnie and other insisted that as zlib was in system, we shouldn’t depend on it at all. I disagree, and I would like to know why we can’t depend on a system package, but whatever. At least one reason is that otherwise lots of ebuild submissions would have coreutils/gcc/libc/whatever in DEPEND/RDEPEND. We could probably introduce some fancy virtuals like c-toolchain to reduce the bloat, but the transition would be somehow tricky... would probably need a list of already converted packages. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] USE flag documentation
On Wednesday 02 of January 2008 16:58:33 Mark Loeser wrote: Doug Klima [EMAIL PROTECTED] said: You're the one forcing people to remove overriding USE flags from use.local.desc when that's something that people have been doing for ages. The current Portage tools support that method. Because this behaviour is not documented anywhere It is documented in the PMS draft and imho it makes perfect sense (at least with current solution): Flags must be listed once for each package to which they apply, or if a flag is listed in both use.desc and use.local.desc, it must be listed once for each package for which its meaning differs from that described in use.desc. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Monday 31 of December 2007 15:33:51 Marius Mauch wrote: Still doesn't address my concerns, namely: - silently expands the scope of EAPI beyond ebuild contents (which is a blocker for me) And what is the reason for not doing exactly that? Seems logical to me. And btw. slot deps added in EAPI 1 seems to have similiar impact, you can't use them in ebuilds using EAPI 0 nor in profiles/. - doesn't mention compability issues on the dev side (minor) Aren't new EAPIs introducing the same problem already? Devs should use up to date tools, and especially the devs running some checks on the whole tree. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Saturday 22 of December 2007 09:09:27 Zhang Le wrote: Piotr Jaroszyński wrote: On Thursday 20 of December 2007 19:29:22 Zhang Le wrote: So please make those people understand, so they can comment usefully. Are we in the elementary school or something? This is really getting ridiculous. IMHO, what is more ridiculous is keeping ask other to be quiet in a discussion which is supposed to be open to everyone who cares about it. I am not asking anyone to be quiet, but it's probably the best way to go if one doesn't care enough to do own research before asking to be educated. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Saturday 22 of December 2007 12:03:33 Duncan wrote: I actually thought the point was pretty effective, given what it was in reply to. If it were me the elementary school reply was made to, I'd have felt it within my rights to ask for an apology. I therefore considered the ietf remark a rather clever reply to the innuendo, making the point delicately, while avoiding the loss of face challenge asking for an apology presents. How is it fair that some people do their own research and some ask to be educated and for the discussion to be delayed? -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
On Saturday 22 of December 2007 10:50:40 Jan Kundrát wrote: Piotr Jaroszyński wrote: The package manger would have to look for ebuilds in the main dir and all the subdirs in case it doesn't have/can't use the cache. No, it would have to check only for subdirectories named after known and supported EAPIs. Not really, we still want to show ebuilds with unsupported EAPI as being masked, but I agree it will have to check only eapiX subdirs. It's still a performance hit though. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Saturday 22 of December 2007 18:56:12 Daniel Drake wrote: Why (in terms of your GLEP) are you still allowing ebuilds to set EAPI inside the ebuild? It seems that one approach you might take is to move the EAPI selection into the filename and remove it from the ebuild itself, and it's not clear to me why your proposal isn't exactly that. That's the goal, yes. The Specification part shows how to do that in a backward compatible way and the Application part says how is the new format supposed to be used. But seeing it's not clear enough I will look into it. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Saturday 22 of December 2007 19:26:08 Duncan wrote: I made this suggestion earlier but it was deep in a subthread and perhaps missed. Else, maybe it didn't reach you in time for this update. Anyway, here it is again: (snip) Syntax: PF.ebuild[-EAPI] Thanks, added syntax specification for the ebuild filename extension. It may also be worthwhile to specifically note /somewhere/ that this only specifies *.ebuild* format, thus leaving other forms (say xbuild) for further changes, if it should ever be decided necessary. I think it will be the job of the xbuild GLEP to specify what from the ebuild format applies and what does not. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
On Saturday 22 of December 2007 02:41:02 Petteri Räty wrote: Piotr Jaroszyński kirjoitti: This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1). It seems many people don't like the idea of having it in the filename Seems you are counting the posts, not the people. but how about having subdirectories for different eapis. This should even be faster for the package manager as it can just ignore the directories it can't understand instead of having to parse the file names. It was already proposed, but didn't seem to get much support. It is equivalent to using the suffixes, but I see it rather as perfomarnce hit, not improvement. The package manger would have to look for ebuilds in the main dir and all the subdirs in case it doesn't have/can't use the cache. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wednesday 19 of December 2007 15:27:07 Luca Barbato wrote: Fernando J. Pereda wrote: On Tue, Dec 18, 2007 at 07:45:44PM +, Duncan wrote: 'app-shells/bash-3.2_p17-r1.ebuild-prefix 1 2 foo zork bar baz fa querty 3 8 4' (and that example uses no odd chars beyond the EAPI component space separator)? This is talking about something not covered by this GLEP so what is your point? I think the glep should try to address this concern... Mixing EAPIs can't work. Strange chars shouldn't be allowed for obvious reasons, [A-Za-z0-9+_-] would be fine by me. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wednesday 19 of December 2007 15:37:44 Luca Barbato wrote: How would it be different than having EAPI=string put in a defined position of the file? We wouldn't be able to take advantage of this GLEP for a year or so. But even putting that aside I still prefer the filename approach for its unambiguity. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tuesday 18 of December 2007 18:37:11 Ulrich Mueller wrote: One example was mentioned in this thread before: You cannot use find -name '*.ebuild' anymore. This should really be one of the last things to consider. And as we have now learned that EAPI strings are not limited to digits (see ciaranm's message) and may even contain blanks (see grobian's message), we would have ebuilds with very strange filenames. I think you misunderstood grobian's mail, which is how we do it in prefix anyway. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tuesday 18 of December 2007 19:51:54 Ulrich Mueller wrote: This should really be one of the last things to consider. On the contrary. If you want to force users to change their habits, then it should be one of the first things to consider if this is really necessary. Simple users don't play with ebuilds, others are well capable of adjusting their habits. And as we have now learned that EAPI strings are not limited to digits (see ciaranm's message) and may even contain blanks (see grobian's message), we would have ebuilds with very strange filenames. I think you misunderstood grobian's mail, There was nothing that could be misunderstood. The sentence in question was: | As a result I now have EAPI=prefix 1 ebuilds. Where he meant a combination of prefix and 1 EAPIs, which is prefix specific. Where is documented what characters are allowed in an EAPI string? Nowhere that I am aware of, but [A-Za-z0-9-_] sounds reasonable to me. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tuesday 18 of December 2007 20:45:44 Duncan wrote: How about when we have a dozen or so EAPIs active, several of which apply to a specific ebuild? Where is this idea of mixing EAPIs coming from? It really doesn't make much sense. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tuesday 18 of December 2007 22:08:52 Thomas de Grenier de Latour wrote: extensions for that. A single one is enough: just call files which use the rule i've proposed foo.gbuild instead of foo.ebuild, or .ebuild-ng. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Hello, attaching the GLEP. most current version: http://dev.gentoo.org/~peper/glep-0055.html http://dev.gentoo.org/~peper/glep-0055.txt -- Best Regards, Piotr Jaroszyński GLEP: 55 Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) Version: $Revision: $ Last-Modified: $Date: $ Author: Piotr Jaroszyński [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17-Dec-2007 Post-History: 17-Dec-2007 Abstract This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1). Motivation == Including EAPI in the ebuild file extension has the following advantages: * Possibility to extend the versioning rules in an EAPI, and to use them immediately in the Gentoo tree. For example, addition of the scm suffix - GLEP54 [#GLEP54]_. * Possibility to extend the behaviour of inherit and add new global scope functions (as a result of not sourcing ebuilds with unsupported EAPI). Specification = Let's call the EAPI included in the ebuild filename the pre-source EAPI, and the EAPI set inside the ebuild the post-source EAPI. Given these two, the final EAPI used by the ebuild can be established by following these steps: * If the pre-source EAPI is not set it defaults to 0. * If the pre-source EAPI is not recognised it is returned immediately. * If the post-source EAPI is not set, it defaults to the pre-source EAPI. * post-source EAPI is returned. The above process should be only used to generate the metadata cache. Should the pre-source EAPI be unsupported the cache entry cannot be generated. Ebuilds with unsupported EAPIs are masked. QA tools should consider it an error for both EAPIs to be set explicitly to different values. Package managers may warn, but must use the post-source EAPI in such cases. Examples: * ``pkg-1.ebuild``, no EAPI set inside the ebuild pre-source EAPI defaults 0, post-source EAPI defaults to pre-source EAPI. EAPI 0 is used. * ``pkg-2.ebuild-0``, no EAPI set inside the ebuild pre-source EAPI is 0, post-source EAPI defaults to pre-source EAPI. EAPI 0 is used. * ``pkg-3.ebuild-1``, no EAPI set inside the ebuild pre-source EAPI is 1, post-source EAPI defaults to pre-source EAPI. EAPI 1 is used. * ``pkg-4.ebuild``, ``EAPI=1`` pre-source EAPI defaults to 0, post-source EAPI is 1. EAPI 1 is used. * ``pkg-4.ebuild-2``, ``EAPI=1`` pre-source EAPI is 2, post-source EAPI is 1. EAPI 1 is used, but note that one should **never** explicitly set both EAPIs to different values. * ``pkg-5.ebuild-2``, no EAPI set inside the ebuild, package manager not supporting EAPI 2 pre-source EAPI is 2, post-source EAPI is never checked. ebuild masked because of the unsupported pre-source EAPI. * ``pkg-6.ebuild``, ``EAPI=2``, package manager not supporting EAPI 2 pre-source EAPI defaults to 0, post-source EAPI is 2. ebuild masked because of the unsupported post-source EAPI. Note that it is still not permitted to have more than one ebuild with equal category, package name, and version. Although it would have the advantage of allowing to provide backward compatible ebuilds, it would introduce problems too. The first is the requirement to have strict EAPI ordering, the second is ensuring that all the ebuilds for a single category/package-version are equivalent, i.e. installing any of them has exactly the same effect to the system. Backwards Compatibility === Currently ebuilds are recognised by the ``.ebuild`` file extension and hence EAPI-suffixed ebuilds are simply ignored by the package manager allowing their immediate usage in the Gentoo tree. References == .. [#GLEP54] GLEP 54, scm package version suffix (http://glep.gentoo.org/glep-0054.html) Copyright = This document has been placed in the public domain. .. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :
Re: [gentoo-dev] EAPI placement
On Wednesday 12 of December 2007 15:20:19 Ciaran McCreesh wrote: The .ebuild-eapi proposal didn't have this problem, but unfortunately it was rejected for political reasons... I wasn't around then, but the requirment of actually sourcing the ebuild to read the EAPI value is extremely stupid indeed. Let's change it... -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [GLEP] scm package version suffix
Hello, Attaching the GLEP source. Current html version available here: http://dev.gentoo.org/~peper/glep-0054.html -- Best Regards, Piotr Jaroszyński GLEP: 54 Title: scm package version suffix Version: $Revision: $ Last-Modified: $Date: $ Author: Piotr Jaroszyński [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 09-Dec-2007 Post-History: 09-Dec-2007 Abstract This GLEP proposes addition of a new special package version suffix - ``scm`` - for ebuilds checking out source directly from a source code management system. Motivation == Currently there is no standard way of marking SCM ebuilds. Using as the version is pretty common, but it is handled like any other ebuild and hence portage cannot provide any additional features for packages with such a version. Another way is adding separate package with -cvs suffix in its name, but that forces to use ``|| ( cat/pkg cat/pkg-cvs )`` dependencies. The closest to what is proposed in this GLEP is the ``cvs`` version part, but its implementation is of very limited use. It has strange comparison rules, no documentation, has never been used in the tree and has a misleading name. The possibility for package managers to recognise SCM ebuilds would allow them to add features dedicated specially to said ebuilds. One such feature could be automatic re-installation of SCM packages once a day or week, but that's beyond this GLEP. Specification = ``scm`` is a special suffix. It can be used on its own, but also in any other valid version spec, just before the place where revision would go. And just like revision it can be used only once in a version spec, e.g.: * ``cat/pkg-1.0_alpha0-scm`` * ``cat/pkg-1.0_alpha-scm`` * ``cat/pkg-1.0-scm-r3`` * ``cat/pkg-1-scm`` * ``cat/pkg-1-scm-r2`` * ``cat/pkg-scm`` These package atoms are sorted in ascending order (see `Version Comparison`_). Version Comparison == The addition of the scm suffix yields changes in version comparison: * When comparing version components from left to right the scm component has the highest priority. * Current suffixes with no number part no longer default to zero if they are followed by an scm suffix. If that's the case the number part is considered to be of a maximum value. Hence ``1_alpha2-scm 1_alpha-scm``, but still ``1_alpha == 1_alpha0``. Example parsing: * ``cat/pkg-scm cat/pkg-1`` When parsing from left to right the first difference is ``scm`` and ``1``. ``cat/pkg-scm`` wins. * ``cat/pkg-1-scm cat/pkg-1.0-scm`` When parsing from left to right the first difference is ``scm`` and ``0``. ``cat/pkg-1-scm`` wins. * ``cat/pkg-1_alpha-scm cat/pkg-1_alpha1-scm`` In the first package version ``alpha`` doesn't have a number part *and* is followed by an ``scm`` suffix, hence it is considered to have a maximum value as the number part. When parsing from left to right the first difference is the number part of the ``alpha`` suffix. Maximum value yielded by the following ``scm`` suffix wins with ``1``. List of version specs in ascending order: * ``1`` * ``1.1-scm`` * ``1.2_alpha-scm`` * ``1.2_beta_p`` * ``1.2_beta_p0-scm`` * ``1.2_beta_p1-scm`` * ``1.2_beta_p-scm`` * ``1.2_beta1_p-scm`` * ``1.2_beta10`` * ``1.2_beta10_p1-scm`` * ``1.2_beta10-scm`` * ``1.2_beta-scm`` * ``1.2`` * ``1.2-scm`` * ``1.2-scm-r1`` * ``1-scm`` * ``10`` * ``scm`` * ``scm-r3`` Backwards Compatibility === Portage versions prior to 2.1.2.12 (included in 2007.0) doesn't handle arbitrary version suffixes and die during various tasks making portage hard or impossible to use. Later versions just ignore them displaying warnings. Hence use of ``scm`` suffixes in gentoo-x86 tree will probably have to wait till 2008.0 release or later. Copyright = This document has been placed in the public domain. .. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :
Re: [gentoo-dev] [GLEP] scm package version suffix
On Sunday 09 of December 2007 17:18:08 Josh Sled wrote: Piotr Jaroszyński [EMAIL PROTECTED] writes: Current html version available here: http://dev.gentoo.org/~peper/glep-0054.html Until reading the abstract, I thought this was Scheme related. I'd suggest -vc (version controlled) or -vcs instead. $ wtf vc vc: nothing appropriate $ wtf vcs vcs (4) - virtual console memory $ wtf scm SCM: software configuration management source code management scm wins :) -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] scm package version suffix
On Sunday 09 of December 2007 18:52:22 Petteri Räty wrote: Portage versions prior to 2.1.2.12 (included in 2007.0) doesn't handle arbitrary version suffixes doesn't -- don't thanks, fixed. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] X drivers up for grabs
(Nelson impression...) haha, peper! Start checkin out Ubuntu... compnerd says they apply 120 patches to this driver.. Also, start fixing the issues it has with HAL 0.5.10 since that's going to hit the tree for real shortly. If you need a version to test against, try Gentopia's overlay. mmm fun. I will look into all that during the weekend and at least I know who to harass :) -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] X drivers up for grabs
On Tuesday 04 of December 2007 02:29:20 Donnie Berkholz wrote: evdev input driver I can take it unless someone else wants it more :) -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New eclass: emul-linux-x86.eclass
On Wednesday 14 of November 2007 11:31:13 Torsten Rehn wrote:
On Wednesday 14 November 2007, Mike Doty wrote:
S=${WORKDIR}
Shouldn't ${WORKDIR} be quoted here, too?
No need to quote in assignments.
--
Best Regards,
Piotr Jaroszyński
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Phase invariancy and exclusivity requirements
On Monday 12 of November 2007 13:26:46 Marijn Schouten (hkBst) wrote: What exactly is the difference between this valid situation and the previous invalid one? between | | are things that can be done in parallel. invalid: a_pkg_setup b_pkg_setup a_build b_build | a_merge | b_merge valid: a_pkg_setup b_pkg_setup a_build_binary b_build_binary | a_binary_pkg_setup | a_binary_merge | b_binary_pkg_setup | b_binary_merge Note that pkg_setup is run twice for the second case, so when the merge order is a then b, b_pkg_setup is aware of the changes that a_merge did, which is not the case in first situation. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/paludis: ChangeLog paludis-0.26.0_alpha3.ebuild
On 05/11/2007, Donnie Berkholz [EMAIL PROTECTED] wrote: Shouldn't need to create a user twice, and that quoting makes this a bit harder to read than it needs to be. Since which version of portage it's handled correctly? P.S. my $EDITOR shows quoted strings nicely. -- Best regards, Piotr Jaroszyński
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-plugins/vdr-extrecmenu: ChangeLog vdr-extrecmenu-1.0.ebuild
On Monday 08 of October 2007 11:22:42 Matthias Schwarzott wrote:
On Montag, 8. Oktober 2007, Donnie Berkholz wrote:
On 20:23 Sun 07 Oct , Joerg Bornkessel (hd_brummy) wrote:
This doesn't respect ROOT != / and it's also dependent on the build
system.
I guess ROOT-safeness here is irrelevant, as for vdr / vdr-plugin.eclass
there is yet no good solution to use the headers from
${ROOT}/usr/include/vdr for compiling.
How can this be converted to respect ROOT ?
$ROOT shouldn't be used in src_*
Most times the sources just do
#include vdr/timers.h
And this normally will find headers located under /usr/include.
And that's the way to go. When you build with ROOT=/foo DEPEND is installed
into / and only {R,P}DEPEND into /foo.
--
Best Regards,
Piotr Jaroszyński
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sci-mathematics/coq: ChangeLog coq-8.1_p1.ebuild
On Saturday 29 of September 2007 17:40:35 Markus Dittrich (markusle) wrote: - 02 Jul 2007; Piotr Jaroszyński [EMAIL PROTECTED] coq-8.0-r1.ebuild, + 02 Jul 2007; Piotr JaroszyÅski [EMAIL PROTECTED] coq-8.0-r1.ebuild, coq-8.0_p3.ebuild: (QA) RESTRICT clean up. Please use UTF-8 friendly stuff. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: gentoo-x86 commit in x11-wm/awesome: awesome-1.2.ebuild Manifest metadata.xml ChangeLog
On Sunday 30 of September 2007 00:54:29 Torsten Veller wrote: This fails if tc-getCC returns the path to the compiler It doesn't, see toolchain-funcs.eclass. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: gentoo-x86 commit in x11-wm/awesome: awesome-1.2.ebuild Manifest metadata.xml ChangeLog
On Sunday 30 of September 2007 02:53:47 Mike Frysinger wrote: On Saturday 29 September 2007, Piotr Jaroszyński wrote: On Sunday 30 of September 2007 00:54:29 Torsten Veller wrote: This fails if tc-getCC returns the path to the compiler It doesn't, see toolchain-funcs.eclass. it may, see toolchain-funcs.eclass $CC is respected from user env and nothing stops the user from doing CC=/moo/moo/mr/compiler (and in fact, users have) the generally accepted sed separator is :, not /, for specifically this reason ... your CFLAGS/LDFLAGS should also get changed as that prevents people from doing `-L/foo` or `-I /moo` or such things -mike right, sorry for the noise especially as it wasn't my commit in the first place :) -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New eclass: cmake-utils.eclass
if ! emake -j1 check; then hasq test $FEATURES die Make check failed. See above for details. hasq test $FEATURES || eerror Make check failed. See above for details. fi No reason to check for test in FEATURES, make it die uncodnitionally. btw. ebuilds shouldn't access FEATURES at all. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Friday 31 of August 2007 12:37:57 Matthias Schwarzott wrote: What do you think about adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK. That's what I did locally so fine by me. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] New PDEPEND behaviour.
Hello, As a result of bug #180045 PDEPENDs can be now merged even before the package that pulls them. Zmedico says that's intended behaviour and PDEPEND is really a RDEPEND, but with a ability to resolve circular deps: circular DEPEND - RDEPEND can't be resolved while circular DEPEND - PDEPEND can. Random behaviour occurs when there is a circular RDEPEND - PDEPEND, e.g. bug #186517. We need to update docs or harass zmedico to force PDEPEND to be pulled as soon as possible but not before the pkg that pulls it. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New PDEPEND behaviour.
On Wednesday 25 of July 2007 16:18:04 Ciaran McCreesh wrote: Give one example of a legitimate use of dependencies that will break by this change. In your answer, consider that someone might install the post package as a target without having its dependencies installed. I am not saying it's breaking something, I just wouldn't except such a behaviour after reading the docs. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
We're voting on this next council meeting so if you have input, now would be the time. It's like proctors, but worse. The only achievement will be another few devs retiring. Btw. I haven't seen any flamewars recently, have you? (probably except what this thread will become) -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites for x11-themes/gdm-themes
# Piotr Jaroszyński [EMAIL PROTECTED] (06 Jul 2007) # Masked for removal. bug #167379. x11-themes/gdm-themes -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [QA] RESTRICT clean up
On Sunday 01 of July 2007 01:35:58 Piotr Jaroszyński wrote: 2) clean up: we want to do global tree clean up after 1) is resolved, nofoo - foo, rest of the invalid values die. This is being done NOW. btw. note that RESTRICT=debug? ( strip ) doesn't make sense. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [QA] RESTRICT clean up
On Sunday 01 of July 2007 11:05:24 Marijn Schouten (hkBst) wrote:
I'm sorry, but I have no idea what `third party values' are.
./multilib.eclass: if hasq multilib-pkg-force ${RESTRICT} ||
--
Best Regards,
Piotr Jaroszyński
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [QA] RESTRICT clean up
On Sunday 01 of July 2007 15:27:21 Marijn Schouten (hkBst) wrote: Where is the (proposed) list of allowed values? What is the point of restricting to that list? man 5 ebuild. The point is that this variable is used by the package manager and adding third part values supported only by specific eclasses can mislead people into thinking that such third party value is supported by the package manager while it's not. Moreover the one example we have - multilib-pkg-force - doesn't really fit into RESTRICT, I still can't figure out what foo-force in RESTRICT was supposed to mean. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [QA] RESTRICT clean up
I am executing 1): RESTRICT=multilib-pkg-force - EMULTILIB_PKG=true. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [QA] RESTRICT clean up
Hello, 1) Should third party values be allowed? At first glance I have only found multilib.eclass, which is using multilib-pkg-force. Imho no, it can use some eclass specific var for that like EMULTILIB=pkg-force or whatever. If there is no objection QA will handle the tree transition. 2) clean up: we want to do global tree clean up after 1) is resolved, nofoo - foo, rest of the invalid values die. 3) repoman check: I have contributed a RESTRICT check(10 lines wow:), which will be in the next portage release. warning for now, error after 2) is done. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites for x11-drivers/mtxdrivers-pro
# Piotr Jaroszyński [EMAIL PROTECTED] (24 Jun 2007) # Masked for removal. bug #165898 x11-drivers/mtxdrivers-pro -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC - Moving categories around]
On Wednesday 09 of May 2007 08:04:44 Alec Warner wrote: The new layout would be: I would reserve the breakage for something more useful. Not that I don't like the idea, just imho such a layout change alone is not worth it. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Should _p0 be allowed as a version suffix?
On Sunday 06 of May 2007 10:59:01 Marius Mauch wrote: It's supposed to be 4 4_p == 4_p0 4_p1 now. And it's good as every other _suffix == _suffix0. No reason to make _p special. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why Glep42 news can't be used yet
On Sunday 06 of May 2007 15:40:23 Marius Mauch wrote: Apparently the `eselect news` module (which is the suggested default news reader) requires paludis to be installed and configured, a quick test resulted in errors when trying with a) paludis not installed b) paludis installed but not configured and the code doesn't seem to have any support for portage at this time (checked version was eselect-1.0.9). Well it's part of Paludis... Tbh, I expected a little more from portage support for news items than pointing to eselect module made for paludis. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why Glep42 news can't be used yet
On Sunday 06 of May 2007 16:49:37 Marius Mauch wrote: Out of those a) is IMO preferrably unless someone can come up with a better solution. At first glance(I don't know how eselect modules work internally yet) a) is cool and should be easy, just merge these two eselect modules and probably add an option to choose backend (portage or paludis). Btw, if you knew about this issue before (that's how your statement above sounds to me) then I'm somewhat irritated that you didn't consider it worth mentioning when you first brought the topic up. I have learned about that only after reading the bug you filled. Earlier I only had known that portage has support for news items. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [news-item] Paludis 0.24
To be honest I didn't expect so many comments here and as far as I believe in your sincerest intentions... err no I don't anymore. We have got input about this from many users and we have some experience in dealing with users problems in the past and we really know better what information paludis' users consider useful enough for a news item. P.S. If you read carefully enough you find one user's opinion in this thread... -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [news-item] Paludis 0.24
Hello, Thanks to zmedico we now have support for news items on infra-side and heck they are ready to use. And we should use them! Attaching news item for paludis 0.24. Justification: major config format change. -- Best Regards, Piotr Jaroszyński Title: Changes for Paludis 0.24 Author: Piotr Jaroszyński [EMAIL PROTECTED] Content-Type: text/plain Posted: 2007-03-25 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =sys-apps/paludis-0.24 As of Paludis 0.24, the use of '*' to match all packages in the Paludis configuration files 'use.conf', 'keywords.conf' and 'licenses.conf' is deprecated in favour of '*/*'. You should update your configuration files after upgrading.
Re: [gentoo-dev] [news-item] Paludis 0.24
On Friday 04 of May 2007 23:46:39 Thomas Rösner wrote: You mean Display-If-Installed: sys-apps/paludis-0.24, right? No, I want it displayed only after installation of the new version. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] tests
Hello, There was some discussion about forcing/not forcing tests in EAPI-1, but there was clearly no compromise. Imho, tests are very important and thus I want to discuss them a little more, but in more sensible fashion. Firstly each test can be(not all categories are mutually exclusive): - not existant - non-functional - not runnable from ebuild - useful but unreasonable resource-wise - useful and reasonable resource-wise - necessary - known to partially fail but with a way of skipping failing tests - known to partially fail but with no easy way of skipping failing tests Is that list comprehensive? Secondly we must answer the question how precisely we want to distinguish them, so users/dev can choose which categories of tests they want to run. What comes to mind is: - run all tests - run only necessary tests - run only reasonable tests - don't run tests at all Again, is that list comprehensive? Please don't post solutions unless we figure out which options we really want to deliver. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] tests
On Tuesday 01 of May 2007 19:18:28 Maurice van der Pot wrote: Isn't it easier to list a set of boolean properties of _individual_ tests? It was just a list of different test classes, which came to mind. The question, which still persist, was how precisely we want to divide them into groups as current boolean choice seems to be not enough. I'd say, let the user decide based on the properties, fex: It seems to be too early for that. Firstly we should figure out the properties and then we can think how to deliver them for end-users. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] tests
On Tuesday 01 of May 2007 21:53:36 Maurice van der Pot wrote: I'm not sure why this is a reply to my message instead of the message I replied to. They both provide more or less the same choice to the user. Err I wasn't providing any choices for users yet, I only thought about the below as things that can be wanted by users/devs and asked whether I missed something. How we will end up distinguishing them is another story... - run all tests - run only reasonable tests - run only necessary tests - don't run tests at all -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: tests
Firstly each test can be(not all categories are mutually exclusive): (...) How many of these we can find is not really that important. I mentioned the different categories just to show that tests are not black and white and we need more then boolean choice to make good use of them. What we need to figure out is the categories we want to distinguish between in ebuilds and *then* how to implement that sanely. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] tests
On Wednesday 02 of May 2007 00:28:42 Josh Saddler wrote: Not a knee jerk reaction, just a strong one. One of the key reasons why mandatory tests were not desired was the fact that sometimes much more stuff will be installed than what you'd normally get. Exhibit A: robbat2's message just sent on diradm that normally just needs openldap with USE=minimal, but building for tests requires all of openldap, samba, etc. Where did you read that this thread is about forcing tests? That was the black and white approach and we all know how it failed... The purpose of this discussion is to figure out a compromise between the current state and force all, because neither of them is good. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
On Tuesday 24 of April 2007 22:47:00 Jurek Bartuszek wrote: Let me see if I have this straight: suppose we have package foo-0.1_rc2 released (very outdated) and we're waiting for foo-0.1_rc3. Then example of something between those two would be foo-0.1_rc000220070313? Would that force portage to update to this version? Wouldn't that prevent portage from enforcing update to _rc3 when it's delivered? Of course I might be wrong and if this is the case then excuse me for the whole fuss ;) foo-0.1_rc2 foo-0.1_rc000220070313 foo-0.1_rc3 -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
On Tuesday 24 of April 2007 23:20:05 Piotr Jaroszyński wrote: foo-0.1_rc2 foo-0.1_rc000220070313 foo-0.1_rc3 err. foo-0.1_rc2 foo-0.1_rc000220070313 foo-0.1_rc000320070512 What I was trying to say is that once you change to the long versions you must stay with them. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Friday 20 of April 2007 14:22:42 Mike Frysinger wrote: does anyone actually find this useful ? i think ive used the value in there like once (when in reality a `md5sum` would have worked just as well) ... otherwise, from my perspective: - it causes annoying bogus hunks in diffs - not uncommon for people to contact me as the maintainer because i'm in that - wastes space (well, probably not a strong argument due to bytes vs blocks) - for mostly green users, it's confusing and they get it wrong ++ and it's a PITA for git(we should eventually switch to something sane, right?) and our commit system which must regenerate the Manifest only after commit so let's kill it. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sunday 25 of March 2007 16:58:10 Mike Frysinger wrote: Did you not say that finding alternatives to Portage is one of Gentoo's priorities? no i did not, nor does that apply here not to put anything in your mouth, but I am a little confused: http://article.gmane.org/gmane.linux.gentoo.devel/46648 -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ANN: PMS public release
Looks like a good job to me. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sunday 25 of March 2007 17:54:24 Andrew Gaffney wrote: Support for an alternative package manager != language bindings for said package manager :P heh, I just wanted a clarification of the Council standpoint in the matter of finding alternatives to portage, which became quite vague after reading two contrary answers to the same question. Anyway tbh I hoped to get some technical comments, but it seems most of the people haven't even read my application :/ At least no one is saying it would hurt Gentoo, which makes me partly happy. P.S. maybe we should start gathering project ideas for the next year already to not look so miserable in comparison with other orgs? -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Saturday 24 of March 2007 13:54:51 Michael Cummings wrote: Ditto. Gentoo SoC projects need to be for Gentoo developed and sponsored code/projects, not third party projects, no matter how much they would whither and die without a gentoo core. There was an example of gentoo+gnome integration (i think) in a previous email - that wouldn't be any more appropriate. Unless there's the Gentoo Inc copyright in the header, it isn't eligible in my opinion. Anant really meant his mail: https://wiki.ubuntu.com/GoogleSoC2007 - Revision-controlled home directories - we have the same idea for /etc - Python Basics Training Program - Math System for Children - Educational Apps - Tool for computer aided vocabulary learning - Gnome Media Center - G-Playah ... Also Google FAQ is worth reading: http://code.google.com/support/bin/answer.py?answer=60291 Google seems to concern more about the FOSS community than the organizations' copyright in the header and imho that's a good thing. Gentoo is supposed to be a _mentoring_ organization, so the only question is whether Gentoo mentors are capable of mentoring a project or not. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Saturday 24 of March 2007 17:30:55 Mike Doty wrote: Yes. pioto's proposal is weak. lu_zero's counterproposal for developing a method of having a package manager agnostic API is much more useful than developing one language binding for one package manager. 1. pioto is a mentor this year... ;] 2. hardly technical issue 3. see ciaran's post -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [soc] Python bindings for Paludis
Hello, I have already submitted my application, but want to advertise it over here too :] Comments are welcome! Summary: Create Python bindings, associated documentation and test cases for the Paludis public API, and allow subclassing of Paludis classes using Python. Detailed description: http://dev.gentoo.org/~peper/soc/application.txt P.S. I am aware of my imperfect English so will appreciate any grammar comments, preferably on irc. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] It seems our ChangeLogs are quite borked
It appears to be a problem with gentoolkit-dev-0.2.6.3. 0.2.6.2 produces proper changelogs. Same here. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] About testing applications
On Sunday 18 of March 2007 13:37:55 Jeff Rollin wrote: Also, if you have a .config directory to put all these files in, ~ becomes less cluttered but ~/.config becomes VERY cluttered! Nothing prevents from making appdirs in .config too. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gs use flag local - global
On Saturday 17 of March 2007 12:28:42 Steve Dibb wrote: Any objections to globalizing the 'gs' use flag on support for ghostscript? I have heard about the magic limit of 5, but whatever... -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Unused global useflags
Unused global useflags: dba - Enables dbm-compatible layers dio - Adds direct i/o support emacs-w3 - Add support for Emacs/W3 where applicable gb - Adds support for Gnome Basic to gnumeric hardenedphp - include the hardened php security patch for the php group of ebuilds ingres - Adds support for Ingres database msession - Adds support for msession daemon Any reason to keep them? -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] forwarding a video
a video sent to out by a good mate http://video.google.com/videoplay?docid=-4216011961522818645 ++ I think recruiters should keep this link in mind. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] forwarding a video
And do what? And hand it to the new devs. That's all I meant ;] -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dev Laptop Broken @ FOSDEM
Some evil person broke my laptop screen at FOSDEM. What about the FOSDEM insurance? Hope you get needed cash and fix it fast. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Manifest2 Transition -- remaining packages
I have fixed some more packages today and made a cron(run every hour) to generate transition status: http://dev.gentooexperimental.org/~peper/mf2/mf2-status.txt -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Packages not yet converted to Manifest2
pcheck -r $PORTDIR '*' -c Manifest2Transition I am trying to finish the transition: - cvs up a category - try(some of them are unfetchable) to fix all pkgs that pcheck reports Hope it goes smoothly. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New emul-libs.eclass
ALLOWED=${ALLOWED:-^${S}/etc/env.d}
If you are using regex here, why don't you use it in find?
find ${S} ! -type d ! -name '*.so*' ! -regex ${ALLOWED} -print0 |
xargs -0 /bin/rm -f
Note that you will need to change ^${S}/etc/env.d to ^${S}/etc/env\.d.* as it
needs to be a full match( btw. you are not escaping a . in your regex )
--
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list
