Re: [gentoo-dev] RFC: package.use.stable.mask
On Sat, 10 Oct 2009 22:04:50 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Hi, lately I spoted that quite few packages have optional parts bit unstable (KDE parts, boinc [i wont stable it until the cuda is, i wont do the work explained bellow :)], kipi,...). I really don't like the shebang about doing -r1 and -r50 so we keep 2 revisions where one is stableable and second is not. So how about having this nice file (topic), it quite self-explainable by the name. Also syntax would be same as for package.use.mask and same goes for placement Don't take this too harshly, but doing it this way seems entirely bass-ackwards to me. Why not just do one of the following: 1. Stabilize the dependencies. Make 'em all the same level. I went through this the other from the other side when trying to get RedNotebook stabilized: I couldn't do so until pyyaml, one of its dependencies, had libyaml stabilized, since libyaml is an optional USE dependency for pyyaml. By forcing all three packages to be stable, *we prevented breakage to users' systems from the beginning.* No need to mess with complicated stable/unstable dependency relationships. 2. Don't mark the origin package stable in the first place! If its dependencies aren't stable, then you cannot in good conscience declare that the original package should be stable, and then let the dependencies sort themselves out . . . weeks or months down the line. Just let it *and* its deps remain in ~arch. What's so wrong with that? * * * Again, I really think it's bad QA and bad practice to mismatch stable packages with unstable dependencies. Please tell us why 1. and 2. don't work for you. signature.asc Description: PGP signature
[gentoo-dev] Last rites: media-gfx/autopano-sift
# Markus Meier mae...@gentoo.org (11 Oct 2009) # mask media-gfx/autopano-sift for removal in 30 days # use media-gfx/autopano-sift-C instead media-gfx/autopano-sift signature.asc Description: PGP signature
[gentoo-dev] Moving real multilib support into main tree portage with request for council decision
Hi together, as announced in a previous mail, i created a fork of portage, which has support to create 32bit libs during compile phase for 64bit platforms (currently amd64 tested, ppc64 untested). In short, it does execute every src_* phase twice with keeping a workdir for every ABI and saving some default environment vars (like *FLAGS). Since the current ABI is the last one in this order, the 64bit phase will overwrite everthing from 32bit phase except those parts, which have a different install location, so mostly libs, which go in lib32 instead of lib64. A current ebuild and docs for using it are currently in the portage-multilib branch of the multilib overlay. I asked zmedico about inclusion into the main svn tree of portage, but he requested a council ok before he would be accepting it. So this is my request for discussion and ok (in tomorrows or the following meeting) from the council. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving real multilib support into main tree portage with request for council decision
Thomas Sachau wrote: Hi together, as announced in a previous mail, i created a fork of portage, which has support to create 32bit libs during compile phase for 64bit platforms (currently amd64 tested, ppc64 untested). In short, it does execute every src_* phase twice with keeping a workdir for every ABI and saving some default environment vars (like *FLAGS). Since the current ABI is the last one in this order, the 64bit phase will overwrite everthing from 32bit phase except those parts, which have a different install location, so mostly libs, which go in lib32 instead of lib64. A current ebuild and docs for using it are currently in the portage-multilib branch of the multilib overlay. I asked zmedico about inclusion into the main svn tree of portage, but he requested a council ok before he would be accepting it. So this is my request for discussion and ok (in tomorrows or the following meeting) from the council. I won't have enough time to investigate this before the meeting tomorrow so I won't be putting up a vote for it on the agenda. We can discuss it during the open floor if there's time. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: USE=qa-test
Sorry for reviving an old thread, but was there any progress on this topic? With packages as dbus that breaks with FEATURES/USE=test hand in hand with packages like dev-libs/gmp[1] there would really be nice to know if you are supposed to be screwed or helped by FEATURES/USE=test... [1](from http://gmplib.org/) IMPORTANT INFORMATION FOR ALL GMP USERS: GMP is very often miscompiled! Please never use your newly compiled libgmp.a or libgmp.so without first running make check. If it doesn't complete without errors, don't trust the library. Please try another compiler release, or change optimisation flags until it works. If you don't have the skill to isolate the problem, please report it to us as if it was a GMP bug; else to the compiler vendor. (The compilers that cause most problems are HP's unbundled compilers and gcc, in particular Apple's gcc releases.) N.B. gcc 4.3.2 miscompiles GMP 4.3.x on 64-bit machines.
Re: [gentoo-dev] [RFC] new global useflags: static-libs and dbi
On Sun, Oct 11, 2009 at 6:40 AM, Markus Meier mae...@gentoo.org wrote: I'm trying to clean up use.local.desc a bit, so here we go: static-libs (used 10 times): Build static libraries dbi (used 7 times): Enable dev-db/libdbi (database-independent abstraction layer) support In my seemingly long running request for library rationality / maximal usefulness, I would like to comment that a needed general trend is towards *all* packages (at least nearly all) that use configure as it is commonly distributed and install libraries in /usr/lib) should have a static-libs build option which determines whether or not the configure option --enable-static / --disable-static is used. Gentoo systems have ~1000 static (.a) libraries in /usr/lib which on most systems are *never* used. One could probably even get rid of the glibc static libraries unless one is building the /bin, /sbin, /etc core and admin programs in static mode. This is because almost all system programs use the shared libraries (in spite of the delay it will generally impose on program startup time) and the risk it imposes for fault tolerant system operations (corrupt a disk block in a shared library and you may have to re-install the entire system rather than simply rebuild a package). Needless to say these libraries under normal conditions increase the size of installs, download times for distributions and slow operations (by increasing seek times on /usr). Which is not to say that static libraries are useless. Indeed for creating program images where one wants robust regression testing across versions (e.g. browser evolution across years) or scientific programs where a static image is essential for the verification or reproduction of results the static libraries (and the building of static programs) is essential. As the current gentoo release sits, libraries/packages are almost always effectively configured as --enable-static --enable-shared [1]. The problem with this is that for a majority of users they do not need --enable-static and that for developers who would really like to build static programs (see the above paragraph) that option is currently unavailable [2] using the emerge process. So this is my vote for improving this situation over time, esp. with respect to adding static-libs to all of the X library ebuilds. The gradual migration of the distributed system to a -static-libs state is highly desirable as well. I note, because I happen to have it handy, that Ubuntu, as installed is almost completely in a -static-libs state with the exception of glibc (i.e. only 20 .a files in /usr/lib). Robert Bradbury 1. It is worth noting in my experience there is some variation across packages as to what the default library build option is and one doesn't know this unless one examines the configure file carefully or attempts to build the packages (usually bypassing the emerge process) all 3 ways. 2. The most glaring example being the glib and gtk+ packages where the lack of static libraries prevents the building of static programs, e.g. firefox, chrome, etc. which use X windows.
[gentoo-dev] Re: gentoo-x86 commit in net-mail/getmail: ChangeLog getmail-4.9.2.ebuild
* Fabian Groffen (grobian) grob...@gentoo.org:
grobian 09/10/11 15:04:33
Modified: ChangeLog getmail-4.9.2.ebuild
Log:
Use ED for Prefix compatability, marked ~ppc-macos and ~x64-solaris
(Portage version: 2.2.00.14552-prefix/cvs/Darwin powerpc, RepoMan options:
--force)
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild?rev=1.2view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild?rev=1.2content-type=text/plain
diff :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild?r1=1.1r2=1.2
Index: getmail-4.9.2.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- getmail-4.9.2.ebuild 23 Jul 2009 19:27:29 - 1.1
+++ getmail-4.9.2.ebuild 11 Oct 2009 15:04:33 - 1.2
@@ -1,6 +1,6 @@
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild,v
1.1 2009/07/23 19:27:29 tove Exp $
+# $Header: /var/cvsroot/gentoo-x86/net-mail/getmail/getmail-4.9.2.ebuild,v
1.2 2009/10/11 15:04:33 grobian Exp $
inherit distutils
@@ -10,7 +10,7 @@
LICENSE=GPL-2
SLOT=4
-KEYWORDS=~alpha ~amd64 ~ppc ~sparc ~x86
+KEYWORDS=~alpha ~amd64 ~ppc ~sparc ~x86 ~ppc-macos ~x64-solaris
IUSE=
DEPEND==dev-lang/python-2.3.3
@@ -19,14 +19,15 @@
PYTHON_MODNAME=getmailcore
src_install() {
+ [[ -z ${ED} ]] local ED=${D}
distutils_src_install
# handle docs the gentoo way
- rm ${D}/usr/share/doc/${P}/COPYING || die
+ rm ${ED}/usr/share/doc/${P}/COPYING || die
if [[ ${P} != ${PF} ]] ; then
- mv ${D}/usr/share/doc/${P} ${D}/usr/share/doc/${PF} || die
+ mv ${ED}/usr/share/doc/${P} ${ED}/usr/share/doc/${PF} || die
fi
dodir /usr/share/doc/${PF}/html
- mv ${D}/usr/share/doc/${PF}/*.{html,css}
${D}/usr/share/doc/${PF}/html || die
+ mv ${ED}/usr/share/doc/${PF}/*.{html,css}
${ED}/usr/share/doc/${PF}/html || die
}
Can you please explain these changes? What is ED? Why does it need
changes in the ebuild at all?
Where is the documentation?
Re: [gentoo-dev] Moving real multilib support into main tree portage with request for council decision
Thomas Sachau wrote: Hi together, as announced in a previous mail, i created a fork of portage, which has support to create 32bit libs during compile phase for 64bit platforms (currently amd64 tested, ppc64 untested). In short, it does execute every src_* phase twice with keeping a workdir for every ABI and saving some default environment vars (like *FLAGS). Since the current ABI is the last one in this order, the 64bit phase will overwrite everthing from 32bit phase except those parts, which have a different install location, so mostly libs, which go in lib32 instead of lib64. A current ebuild and docs for using it are currently in the portage-multilib branch of the multilib overlay. I asked zmedico about inclusion into the main svn tree of portage, but he requested a council ok before he would be accepting it. So this is my request for discussion and ok (in tomorrows or the following meeting) from the council. An important thing to note is that there are necessary changes to emul-* ebuilds that are technically an EAPI change, since they won't work with old package managers that don't have support for lib32 USE flags. -- Thanks, Zac
Re: [gentoo-dev] Moving real multilib support into main tree portage with request for council decision
Zac Medico schrieb: Thomas Sachau wrote: Hi together, as announced in a previous mail, i created a fork of portage, which has support to create 32bit libs during compile phase for 64bit platforms (currently amd64 tested, ppc64 untested). In short, it does execute every src_* phase twice with keeping a workdir for every ABI and saving some default environment vars (like *FLAGS). Since the current ABI is the last one in this order, the 64bit phase will overwrite everthing from 32bit phase except those parts, which have a different install location, so mostly libs, which go in lib32 instead of lib64. A current ebuild and docs for using it are currently in the portage-multilib branch of the multilib overlay. I asked zmedico about inclusion into the main svn tree of portage, but he requested a council ok before he would be accepting it. So this is my request for discussion and ok (in tomorrows or the following meeting) from the council. An important thing to note is that there are necessary changes to emul-* ebuilds that are technically an EAPI change, since they won't work with old package managers that don't have support for lib32 USE flags. I currently have emul-* ebuilds in my branch, which use lib32 usedeps, but ebuilds could instead just use something like || ( emul-linux-qtlibs qt-core[lib32] ). So this part should be no drawback for actually adding multilib support to main tree portage. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving real multilib support into main tree portage with request for council decision
On Sunday 11 October 2009 06:21:14 Thomas Sachau wrote: as announced in a previous mail, i created a fork of portage, which has support to create 32bit libs during compile phase for 64bit platforms (currently amd64 tested, ppc64 untested). In short, it does execute every src_* phase twice with keeping a workdir for every ABI and saving some default environment vars (like *FLAGS). Since the current ABI is the last one in this order, the 64bit phase will overwrite everthing from 32bit phase except those parts, which have a different install location, so mostly libs, which go in lib32 instead of lib64. A current ebuild and docs for using it are currently in the portage-multilib branch of the multilib overlay. your git instructions are overly complicated (doc/portage-multilib- instructions). your two checkouts and .git/config edit are one command: git checkout -b portage-multilib origin/portage-multilib you really should line wrap that file too I asked zmedico about inclusion into the main svn tree of portage, but he requested a council ok before he would be accepting it. So this is my request for discussion and ok (in tomorrows or the following meeting) from the council. getting review + approval in a day or two is pretty unreasonable, especially when info as to what is being changed/proposed isnt well documented. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay
On Sunday 16 August 2009 08:37:37 Thomas Sachau wrote: -for the portage version: It is also in the multilib overlay, but in a different branch called portage-multilib. To use this, you should read the instructions at [1] (doc/portage-multilib-instructions). This one should also mainly work, but there is probably a good amount of packages in the main tree, which may refuse to work with it. the abi-wrapper doesnt look terribly appealing. why dont we use broken/custom -config handling as incentive to convert packages to .pc files. pkg-config handles ABI/cross-compile splitting cleanly and transparently. bash-4 is stable, so we could start depending on it. you dont save/restore CPPFLAGS is there documentation that covers the proposed changes/design to portage ? i'm not looking for high level (it runs src_compile twice). i dont recall seeing details posted to the portage or gentoo mailing lists ... it's hard to review `git diff portage-svn..master`. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: Monolithic KDE 3.5.9 packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Jonathan Callen a...@gentoo.org (11 Oct 2009) # Old KDE 3.5.9 monolithic ebuilds. Replaced by kde*-meta. # Masked for removal in 30 days kde-base/kdeaccessibility kde-base/kdeaddons kde-base/kdeadmin kde-base/kdeartwork kde-base/kdebase kde-base/kdeedu kde-base/kdegames kde-base/kdegraphics kde-base/kde kde-base/kdemultimedia kde-base/kdenetwork kde-base/kdepim kde-base/kdesdk kde-base/kdetoys kde-base/kdeutils kde-base/kdewebdev -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrSTOYACgkQOypDUo0oQOrQywCfXqypmrGr9S/XzezA1/kA1bwF 88oAn0TLo+Lm3f+re5ac785EtMkBGhun =O+Nj -END PGP SIGNATURE-
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-10-11 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-10-11 23h59 UTC. Removals: net-im/twinkle 2009-10-06 02:52:54 dragonheart games-fps/doom3-dungeon 2009-10-08 00:24:17 nyhm app-dicts/ebview2009-10-08 09:03:12 flameeyes app-i18n/minichinput2009-10-08 09:03:13 flameeyes app-text/omegat 2009-10-08 09:03:14 flameeyes dev-db/sqsh 2009-10-08 09:03:14 flameeyes dev-dotnet/ml-pnet 2009-10-08 09:03:15 flameeyes dev-dotnet/pnet 2009-10-08 09:03:15 flameeyes dev-dotnet/pnetc2009-10-08 09:03:16 flameeyes dev-dotnet/pnetlib 2009-10-08 09:03:16 flameeyes dev-java/rjava 2009-10-08 09:03:17 flameeyes dev-libs/libexploit 2009-10-08 09:03:18 flameeyes dev-python/pyzzub 2009-10-08 09:03:18 flameeyes dev-tinyos/ncc 2009-10-08 09:03:19 flameeyes dev-tinyos/tos-apps 2009-10-08 09:03:19 flameeyes dev-tinyos/tos-make 2009-10-08 09:03:20 flameeyes dev-tinyos/tos-scripts 2009-10-08 09:03:20 flameeyes dev-tinyos/tos-uisp 2009-10-08 09:03:21 flameeyes dev-util/cweb 2009-10-08 09:03:21 flameeyes dev-util/pilrc 2009-10-08 09:03:22 flameeyes media-libs/libmovtar2009-10-08 09:03:23 flameeyes media-libs/libzzub 2009-10-08 09:03:24 flameeyes media-sound/aldrin 2009-10-08 09:03:24 flameeyes net-analyzer/trafd 2009-10-08 09:03:25 flameeyes net-dialup/isdn4k-utils 2009-10-08 09:03:25 flameeyes net-dialup/isdndump 2009-10-08 09:03:26 flameeyes net-dialup/kisdndial2009-10-08 09:03:27 flameeyes net-dialup/raccess4vbox32009-10-08 09:03:27 flameeyes net-dialup/vbox32009-10-08 09:03:28 flameeyes net-firewall/tuxfrw 2009-10-08 09:03:29 flameeyes net-fs/am-utils 2009-10-08 09:03:30 flameeyes net-irc/mistbot 2009-10-08 09:03:31 flameeyes net-misc/bo2k_console 2009-10-08 09:03:31 flameeyes net-misc/bo2k_plugins 2009-10-08 09:03:32 flameeyes net-misc/ndtpd 2009-10-08 09:03:32 flameeyes net-misc/slidentd 2009-10-08 09:03:33 flameeyes sci-chemistry/maid 2009-10-08 09:03:34 flameeyes sys-fs/ocfs2-tools 2009-10-08 09:03:34 flameeyes games-fps/quake4-deltactf 2009-10-08 13:59:31 nyhm games-fps/doom3-opencoop2009-10-08 15:10:32 nyhm net-zope/zcbuildout 2009-10-10 17:06:21 arfrever Additions: media-plugins/gst-plugins-schroedinger 2009-10-05 10:35:32 ssuominen sys-devel/llvm 2009-10-05 13:10:54 voyageur sys-devel/llvm-gcc 2009-10-05 13:11:12 voyageur sys-devel/clang 2009-10-05 13:19:28 voyageur dev-python/mock 2009-10-05 22:06:00 patrick net-voip/twinkle2009-10-06 02:47:02 dragonheart x11-libs/hippo-canvas 2009-10-06 08:13:24 elvanor mail-filter/opendkim2009-10-06 09:10:43 dragonheart media-sound/mac 2009-10-06 14:13:16 ssuominen dev-perl/Class-XSAccessor 2009-10-06 19:02:05 tove dev-python/subvertpy2009-10-06 19:37:37 pva dev-util/bzr-svn2009-10-06 19:46:37 pva dev-perl/Mouse 2009-10-06 20:51:43 tove dev-perl/Any-Moose 2009-10-06 20:57:37 tove media-video/parole 2009-10-06 23:23:28 ssuominen media-plugins/ladspa-bs2b 2009-10-07 03:50:25 sping net-zope/zope-exceptions2009-10-07 21:28:57 arfrever media-plugins/vdr-svdrposd 2009-10-08 08:30:17 zzam app-admin/eselect-nxserver 2009-10-08 19:21:02 voyageur net-im/kopete-facebook 2009-10-09 09:55:11 alexxy media-gfx/psftools 2009-10-09 11:14:54 pva sys-auth/pam_keystore 2009-10-09 14:23:21 flameeyes sys-libs/talloc 2009-10-09 17:18:07 patrick sys-libs/tevent 2009-10-09 17:18:32 patrick sys-libs/tdb2009-10-09 17:18:57 patrick virtual/talloc
