Re: [gentoo-dev] EAPI 2 policy for portage tree
Robert R. Russell [EMAIL PROTECTED] writes: 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg). Another reason for preferring option 3 for bug fix (but not for 'cosmetic' changes or ones which prevent some users from installing the package) is that (~arch) users will already have the pre-bug fixed version installed and portage will not install the bug fix unless either the version is bumped or USE flags have changed and the --newuse emerge option is used.
[gentoo-dev] Re: Digest of gentoo-dev@lists.gentoo.org issue 653 (33679-33728)
[EMAIL PROTECTED][EMAIL PROTECTED]
[gentoo-dev] Re: Digest of gentoo-dev@lists.gentoo.org issue 653 (33679-33728)
blah (switching emails, sorry for that) On Tue, Dec 9, 2008 at 7:14 PM, Douglas Anderson [EMAIL PROTECTED] wrote: [EMAIL PROTECTED][EMAIL PROTECTED]
[gentoo-dev] Re: app-admin/eselect needs YOUR help
Donnie Berkholz wrote: Ciaran McCreesh wrote: Donnie Berkholz wrote: I hadn't heard of it before, thanks for the ref. What was the reason for forking the codebase? It gets pretty annoying to copy across useful changes, especially while eselect is stuck in svn. Ease of getting things done. Going through Gentoo requires finding a Gentoo maintainer, endless bikeshed arguments about how to implement things like the new alternatives framework and then months of waiting for approval. Open and public debate about the right way to do things does take longer, and it's something you certainly participate in quite frequently so I'm surprised to hear you badmouth it when it comes to your own ideas. You should have posted this to -project imo, as it's not about any technical points, but rather about non-technical aspects of development.
Re: [gentoo-dev] Proposal: disable python and perl USE flags in profile
On Tue, 2008-12-09 at 04:09 +0200, Petteri Räty wrote: Maciej Mrozowski wrote: Following advise from https://bugs.gentoo.org/show_bug.cgi?id=250179, I'm bringing it here. I think this is probably a good idea after EAPI 2 is stable and we eliminate built_with_use usage from the tree. I think having stuff build out of the box instead of dying in the middle of emerge outweighs pulling in some extra stuff with default settings. Regards, Petteri +1 Daniel
Re: [gentoo-dev] EAPI 2 policy for portage tree
Jean-Marc Hengen wrote: tree and my policies (more precisely: I can't keep current stable portage and cmake-2.6.2). My solution to the problem, was to copy the ebuild in /var/db/pkg to my local overlay and I'm fine with it for now. The drawback of this workaround is, I could miss important fixes, like security fixes. [snip] the cmake-2.6.2 ebuild. This has the advantage, that people with a setup like mine can continue to use, what they already use and work on the cmake ebuild can continue in the new revision. If the new revision fixes a security issue, one can mask the old version, with a message with bug telling this. Just FYI, there's no difference -- when you've chosen to use the ~arch version, you *have* to follow any updates to it as soon as possible if you want to be reasonably sure you aren't affected by a security bug, as our security team doesn't issue GLSAs for ~arch packages. Sticking with a version that works for you doesn't mean you're somehow protected form security bugs. So to put this into perspective with cmake -- if there was a security bug in current version (which you'd keep as you don't want to upgrade Portage) and the fix for this bug would be using EAPI=2 (which is not an unrealistic situation), you'd be affected. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
Should be able to find which gcc was used by checking LDPATH in the environment.bz2. I believe it is about the only gcc version information recorded in /var/db/pkg/category/package/ though. Gordon Malm (gengor) On Monday, December 8, 2008 16:44:16 Federico Ferri wrote: Hello, today I hit this annoyance, because my laptop hung in the middle of an 'emerge -e @world' (checking that my world set compiles with gcc-4.3... stopped at ~ 300 of 700 :S ) I was looking for an entry in /var/db/pkg/cat/pkg/ that could have told me the compiler used to build the package, but couldn't find any. indeed it would be a fairly useful feature to have, both for testing purposes, and for user's everyday maintenance. please criticize this with anything constructive you can think of. thanks
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/xf86-input-synaptics: xf86-input-synaptics-0.99.2-r1.ebuild ChangeLog
On 16:18 Tue 09 Dec , Tony Vroon (chainsaw) wrote: chainsaw08/12/09 16:18:50 Modified: ChangeLog Added:xf86-input-synaptics-0.99.2-r1.ebuild Log: More helpful FDI file comments by Bernard Cafarelli [EMAIL PROTECTED] so users can modify the FDI file easier. Removed the HAL USE-flag, upstream behaviour changes mean you need it now. Added messages to that effect. Revision bumped. (Portage version: 2.1.6/cvs/Linux 2.6.28-rc7-00200-gf7a8db8-dirty x86_64) Bernard/Tony, Have you sent the comments upstream? -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpXTGplT5cWL.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for flag-o-matic.eclass (append-ldflags)
On 10:33 Mon 08 Dec , Jeremy Olexa wrote:
Hello,
I am seeking a positive code review on the following change to
flag-o-matic.eclass, diff is below (reasons are below that):
%% cvs diff
Index: flag-o-matic.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/flag-o-matic.eclass,v
retrieving revision 1.126
diff -u -r1.126 flag-o-matic.eclass
--- flag-o-matic.eclass 3 Nov 2008 05:52:39 - 1.126
+++ flag-o-matic.eclass 25 Nov 2008 18:36:04 -
@@ -417,7 +417,8 @@
x=
for x in $@ ; do
- test-flag-${comp} ${x} flags=${flags}${flags:+ }${x}
+ test-flag-${comp} ${x} flags=${flags}${flags:+ }${x}
|| \
+ ewarn removing ${x} because ${comp} rejected it
done
echo ${flags}
@@ -656,7 +657,7 @@
ewarn Appending a library link instruction
(${flag}); libraries to link to should not be passed through LDFLAGS
done
- export LDFLAGS=${LDFLAGS} $*
+ export LDFLAGS=${LDFLAGS} $(test-flags $@)
return 0
}
I like the consistency with other flags:
comet $ grep FLAGS.*test-fl /usr/portage/eclass/flag-o-matic.eclass
export CFLAGS=$(test-flags-CC ${CFLAGS})
export CXXFLAGS=$(test-flags-CXX ${CXXFLAGS})
export FFLAGS=$(test-flags-F77 ${FFLAGS})
export FCFLAGS=$(test-flags-FC ${FCFLAGS})
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgp6M0nR59bhQ.pgp
Description: PGP signature
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
On 01:44 Tue 09 Dec , Federico Ferri wrote: today I hit this annoyance, because my laptop hung in the middle of an 'emerge -e @world' (checking that my world set compiles with gcc-4.3... stopped at ~ 300 of 700 :S ) I was looking for an entry in /var/db/pkg/cat/pkg/ that could have told me the compiler used to build the package, but couldn't find any. indeed it would be a fairly useful feature to have, both for testing purposes, and for user's everyday maintenance. please criticize this with anything constructive you can think of. As I mentioned on IRC, I think this isn't a very general use case (given the existence of --resume, --keep-going, etc.) so code to accomplish it would be better put into a custom portage bashrc than into portage proper. ISTR that you could no longer resume for some reason. Perhaps what you really wanted was a way to save the resume list across multiple emerges? -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpMHDY75zXCf.pgp Description: PGP signature
Re: [gentoo-dev] EAPI 2 policy for portage tree
Robert R. Russell wrote: My personal opinion on this matter is pick one of the following: 1) perform the bugfix without a version bump and remain at the current EAPI version 2) perform the bugfix with a version bump and remain at the current EAPI version 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. The current policy states that ebuilds should only be bumped if the installed files change. Changing EAPI from 1 to 2 has no effect outside the vdb so the current policy means developers should use option 3. There was a bug in stable Portage when EAPI 2 went in the tree that made Portage stack trace but that's a problem with Portage not with the policy in general. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg). Why should we prefer making it a little bit easier for stable users over making ~arch users needlessly recompile stuff? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: Federico Ferri wrote: Hello, today I hit this annoyance, because my laptop hung in the middle of an 'emerge -e @world' (checking that my world set compiles with gcc-4.3... stopped at ~ 300 of 700 :S ) Consider using emerge --keep-going next time. I was looking for an entry in /var/db/pkg/cat/pkg/ that could have told me the compiler used to build the package, but couldn't find any. indeed it would be a fairly useful feature to have, both for testing purposes, and for user's everyday maintenance. But the idea isn't that bad imfo. Maybe save the output of emerge --info in general and it could be easily made available for bug filing. If it was a while since you emerged the package your emerge --info could now be different from the merge time and now for example reflect your use flags. nice point! I didn't see the whole potential of my proposal :-D - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk+11kACgkQV/B5axfzrPvq4QCgvs5zVMieQADGfdq8DcJZSNzK +3QAoKmH/TzzJ/9ZmqgWrXK5C9jINsI3 =/qv2 -END PGP SIGNATURE-
Re: [gentoo-dev] Linux 2.6.27 stabilisation plans
Daniel Drake wrote: I'm tentatively planning to request that gentoo-sources-2.6.27 gets marked stable on x86+amd64 on December 15th, assuming we have fixed all regressions (we have some open, which will hopefully be fixed soon). We're still on track for December 15th stabling, so please make sure your package is tested and fixed in the stable tree: Kernel-dependent packages that are broken by this upgrade are tracked at https://bugs.gentoo.org/show_bug.cgi?id=242708 Please help us fix these in the stable tree in advance of the stabling date.
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gordon Malm wrote:
Should be able to find which gcc was used by checking LDPATH in the
environment.bz2. I believe it is about the only gcc version
information recorded in /var/db/pkg/category/package/ though.
$ find /var/db/pkg -name environment.bz2 | wc
- -l
747
$ find /var/db/pkg -name environment.bz2 -exec bzgrep -q LDPATH '{}'
';' -print | wc -l
11
sorry, that appears to be of little help
- --
Federico Ferri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkk+7uUACgkQV/B5axfzrPsaJwCdFVpGO3fYAMcyhRTN2QdRuZkH
2CsAniO7oZCxZSC6lt/j/+PRmrgyCyuI
=5mFz
-END PGP SIGNATURE-
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: On 01:44 Tue 09 Dec , Federico Ferri wrote: today I hit this annoyance, because my laptop hung in the middle of an 'emerge -e @world' (checking that my world set compiles with gcc-4.3... stopped at ~ 300 of 700 :S ) I was looking for an entry in /var/db/pkg/cat/pkg/ that could have told me the compiler used to build the package, but couldn't find any. indeed it would be a fairly useful feature to have, both for testing purposes, and for user's everyday maintenance. please criticize this with anything constructive you can think of. As I mentioned on IRC, I think this isn't a very general use case (given the existence of --resume, --keep-going, etc.) so code to accomplish it the point was not resuming my emerge because the laptop hung. was more like: tracking which compiler built which package or vice-versa would be better put into a custom portage bashrc than into portage proper. yes, that makes sense. it could be an external tool, like revdep-rebuild is, which queries compiler by pkg, and eventually rebuilds packages (not) matching a certain compiler. but to accomplish this, an information about the compiler (in the pkg record) should be there. something like /var/db/pkg/cat/pkg/COMPILER - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk+8qQACgkQV/B5axfzrPs9BwCbBmbU3HVY0i6bqljlx3yZqICk nT8AoJpgTbcNc/UOirCrPRw3zTOlxI5G =uWSJ -END PGP SIGNATURE-
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
On Tue, 9 Dec 2008 11:21:24 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
On 01:44 Tue 09 Dec , Federico Ferri wrote:
today I hit this annoyance, because my laptop hung in the middle of
an 'emerge -e @world' (checking that my world set compiles with
gcc-4.3... stopped at ~ 300 of 700 :S )
I was looking for an entry in /var/db/pkg/cat/pkg/ that could have
told me the compiler used to build the package, but couldn't find
any. indeed it would be a fairly useful feature to have, both for
testing purposes, and for user's everyday maintenance.
please criticize this with anything constructive you can think of.
As I mentioned on IRC, I think this isn't a very general use case
(given the existence of --resume, --keep-going, etc.) so code to
accomplish it would be better put into a custom portage bashrc than
into portage proper.
ISTR that you could no longer resume for some reason. Perhaps what
you really wanted was a way to save the resume list across multiple
emerges?
For the given use case it might also be an option to use the AgeSet
handler in portage-2.2, e.g.
emerge -p '@old{class=dbapi.AgeSet,age=2}'
to list all installed packages that have been installed more than two
days ago.
Marius
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-text/antixls: ChangeLog antixls-0.3b.ebuild
On 22:37 Sun 07 Dec , Patrick Lauer (patrick) wrote:
1.1 app-text/antixls/antixls-0.3b.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-text/antixls/antixls-0.3b.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-text/antixls/antixls-0.3b.ebuild?rev=1.1content-type=text/plain
src_install() {
mv ${DISTDIR}/${P}.perl ${PN}
dobin ${PN}
You probably want to die if these fail.
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpS0zHV4WmRP.pgp
Description: PGP signature
