Re: [gentoo-dev] Last rites: app-emacs/ngnus
On Thu, 19 Nov 2009, James Cloos wrote: The app-emacs/ngnus- ebuild is in active use and should not go away. It also should remain in the main tree. (A rename to app-emacs/gnus- is OK, Done so. Thanks for the feedback. provided it gets mentioned in profiles/updates.) It's technically not possible to do a partial package move. But I'd expect users of live ebuilds to be able to figure things out by themselves. Ulrich
Re: [gentoo-dev] Stabilisation plans for boinc 6.6.40
On Wed, 18 Nov 2009 19:50:45 +0100 Tomáš Chvátal scarab...@gentoo.org wrote: Hi guys, I know it is not exactly common to ask for help with pre-stabilisation testing on -dev, but i think this b*** needs more attention than usuall package. Would those of you that use the package try to break it as-much-as-possible and report all bugs they encounter on during the hammering. All relevant issues should block [1]. Thanks for help Tom [1] http://bugs.gentoo.org/show_bug.cgi?id=293640 For what it's worth , sci-misc/boinc-6.6.40-r2 has been working fine for a while for me. Regards, Víctor signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds
On Sun, Oct 18, 2009 at 2:11 AM, Fabian Groffen grob...@gentoo.org wrote: This is a formal apology for springing that onto you. Thanks a lot. Not everybody can do such a thing as a public apology. I will nonetheless ask the council to vote on the following during next meeting: Ask Fabian to change his signature from: Gentoo on a different level To: Failure in a different level ;o) 2009/10/18 Tomáš Chvátal scarab...@gentoo.org: Why on earth portage simply does not detect the prefix enviroment is being run and then INTERNALY switch D-ED and other variables. If that means we can get away without touching ebuilds, apart from changing their EAPI variable, then that's absolutely what we have to do. I'd like things to be done the right way though (see below). On Fri, Nov 13, 2009 at 4:43 AM, Ulrich Mueller u...@gentoo.org wrote: However, there is need for additional discussion. From the council meeting log I could extract the following open questions: It would be preferable for the discussion to happen on this list before the meeting or we'll end up postponing again due to having more questions coming up at that time. 2. Should the Prefix team be allowed to do the necessary changes to ebuilds themselves, or should it be done by the respective maintainers? I think here it's obvious that anybody who is an ebuild dev and sees anything to fix (prefix or else) is encouraged to go ahead and do it, as we've always done. The recommendation is and will always be to talk to the current maintainers out of politeness and to be extra careful (i.e. usually letting the maintainers do it) in case of system/tricky/exotic package. We don't give full cvs access to the whole tree to all ebuild devs for nothing. 4. EAPI numbering: Would this simply be added as an additional feature to EAPI 3? Or should we have an intermediate EAPI slot, e.g. 2.1 or 3 (and current EAPI 3 renamed to 4 in the latter case)? Here I'd add to the choices: why not release an intermediate EAPI with the prefix stuff and whatever that has already been done for EAPI3? The exact name of a potential intermediate EAPI is a non-problem. However I would prefer if it were a number like 2.1 or 2.5 or even 3, because although we currently treat the EAPI variable as a simple string we may change our mind later and find it handy someday to use operators on them such as =2.1. 5. Who is going to write the exact specification (PMS patch) for this EAPI feature? I thought I asked Fabian to work on that at the end of the meeting. In case I didn't then consider this as me officially asking him if he can take care of it. Fabian is this OK with you? Also I think it would be nice if somebody took care of a portage patch, since I hear it is rather simple. Fabian again? Or Zac? Any other volunteers? I would prefer to have all the pieces in places before the next meeting so that we can vote on the real thing and have prefix implemented the right way before the end of the year. 6. (Any question that I've missed?) Here are a few that I gathered from others (my comments are between parentheses): How are dynamically linked set*id programs going to work? How are scripts using #!shebangs going to work? You write an ebuild, and you DEPEND upon =foo-3, because the build process includes some foo code. The foo code is executed via scripts using #!/usr/bin/foo. Normally, this is fine. But on prefix, /usr/bin/foo might be a crappy, OS X mangled foo-2 that's no good. So even though you've got the foo-3 dep met, it'll be met in /opt/Gentoo/blah, so your package will fail. How are ebuilds to be marked as supporting prefix or not? (Here I'm guessing that changing the EAPI variable will do) Why is there only a single permitted installation path? (I'm under the impression this is a limitation of the windows installer but not of prefix itself. So patching the installer would fix that) What exactly is expected from a prefix-compliant package manager to support full prefix installs, as opposed to just supporting installs to / with prefix-aware ebuilds? (The PMS patch should answer that) Denis.
Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds
Some questions answered. snipped the rest.
Denis Dupeyron wrote:
2009/10/18 Tomáš Chvátal scarab...@gentoo.org:
Why on earth portage simply does not detect the prefix enviroment is being run
and then INTERNALY switch D-ED and other variables.
If that means we can get away without touching ebuilds, apart from
changing their EAPI variable, then that's absolutely what we have to
do. I'd like things to be done the right way though (see below).
When you change econf to do --prefix=${EPREFIX}/usr then you cannot
simply s/D/ED/ for everything. I hope this makes sense when you think
about it. ;)
src_install() {
emake DESTDIR=${D} install || die
mv ${ED}/usr/bin/{,exuberant-}ctags || die
}
But then again, some ebuilds need no changing once you fix econf to do
the work, which is nice.
On Fri, Nov 13, 2009 at 4:43 AM, Ulrich Mueller u...@gentoo.org wrote:
However, there is need for additional discussion. From the council
meeting log I could extract the following open questions:
It would be preferable for the discussion to happen on this list
before the meeting or we'll end up postponing again due to having more
questions coming up at that time.
We are willing to talk, but it always seems like the Council is not
prepared no matter what we do. Hope everyone involved can change that.
2. Should the Prefix team be allowed to do the necessary changes to
ebuilds themselves, or should it be done by the respective
maintainers?
I think here it's obvious that anybody who is an ebuild dev and sees
anything to fix (prefix or else) is encouraged to go ahead and do it,
as we've always done. The recommendation is and will always be to talk
to the current maintainers out of politeness and to be extra careful
(i.e. usually letting the maintainers do it) in case of
system/tricky/exotic package. We don't give full cvs access to the
whole tree to all ebuild devs for nothing.
It is quite obvious that we are not trying to make trouble. Talk is
cheap, so we prefer that. But, we see no need to ask permission to add
~prefix keywords, same as other arch teams.
Currently, 'repoman -d full' will fail in some packages. We are fixing this.
Also I think it would be nice if somebody took care of a portage
patch, since I hear it is rather simple. Fabian again? Or Zac? Any
other volunteers?
I would prefer to have all the pieces in places before the next
meeting so that we can vote on the real thing and have prefix
implemented the right way before the end of the year.
portage devs and prefix devs have agreed that it is rather 'easy' to
merge the prefix-portage branch. Just waiting.. ;) We have access to
check into the portage repo, so this should not hold anything up
regarding any decisions.
6. (Any question that I've missed?)
How are scripts using #!shebangs going to work?
You write an ebuild, and you DEPEND upon =foo-3, because the build
process includes some foo code. The foo code is executed via
scripts using #!/usr/bin/foo. Normally, this is fine.
But on prefix, /usr/bin/foo might be a crappy, OS X mangled foo-2
that's no good. So even though you've got the foo-3 dep met, it'll be
met in /opt/Gentoo/blah, so your package will fail.
The prefix-portage branch has a nice feature that fixes shebangs
automatically to be ${EPREFIX}/foo instead of /foo. It has even caught
some Gentoo Linux bugs.
How are ebuilds to be marked as supporting prefix or not?
(Here I'm guessing that changing the EAPI variable will do)
Gentoo Prefix has keywords. So if EAPI 3 has ED/EROOT support but the
ebuild doesn't use them then the ebuild does not need an EAPI bump. In
this case, please rephrase your question to be How are ebuilds to be
marked as working on a prefix arch or not? and then it is clear that it
is the same as Gentoo Linux.
Why is there only a single permitted installation path?
(I'm under the impression this is a limitation of the windows
installer but not of prefix itself. So patching the installer would
fix that)
My installation path on my 6-8 prefix arches is in my NFS home. If you
are referring to the Windows special installation package, well..that is
just a stage4 installer with binary packages. The windows installer is
no where near the heart of Gentoo Prefix, instead it is a product of
Gentoo Prefix and a convenience factor offered by another Prefix dev. It
showcases the possibilities quite well, IMO.
You can set EPREFIX to anything. One of our users even set it to / -
which we don't endorse but it is possible. :)
What exactly is expected from a prefix-compliant package manager to
support full prefix installs, as opposed to just supporting installs
to / with prefix-aware ebuilds?
(The PMS patch should answer that)
Denis.
Re: [gentoo-portage-dev] sets remove support replacement?
Duncan wrote: Now remove sets don't work. What are the options? The most direct is to simply create my own set listing everything I want, but that won't account for anything added to the sets as they appear upstream over time. What to do about that? I suppose I could create an update script that diffs the new kde-testing set against a copy I stashed somewhere, thus showing me the differences, and that I could then update my own set and the stashed copy of the upstream set accordingly. Is that the best option under the circumstances, or does portage provide some other replacement for the functionality I just lost in that regard, with the loss of remove set functionality? There's no replacement for it yet, so yes, for now that seems like the best option if you need such fine-grained control. -- Thanks, Zac
[gentoo-portage-dev] Re: sets remove support replacement?
Zac Medico posted on Wed, 18 Nov 2009 23:36:28 -0800 as excerpted: There's no replacement for it yet, so yes, for now that seems like the best option if you need such fine-grained control. Thanks. Done. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
