Re: [gentoo-dev] Stats test server running, please check it out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Pipping wrote: Federico Ferri wrote: FEATURES can link feature to make.conf man page: http://linuxreviews.org/man/make.conf/ (unfortunately this man page is rendered with no anchors over variable/features, so you could do better ^__^ the output of neither # man2html -r make.conf.5 make.conf.5.html nor # groff -man -Thtml make.conf.5 make.conf.5.html make me really happy do you know any alternative coming with more anchors and external CSS support? # nope for css, but you could do something like this: # imagine you have the feature list in a file # (I don't know how to extract it automatically, but perhaps someone does) $ cat featurelist assume-digests buildpkg buildsyspkg ... userpriv usersandbox usersync webrsync-gpg $ bzcat /usr/share/man/man5/make.conf.5.bz2 | man2html -r make.html # basically now you have to match DTBfeaturename/B # and add a anchor tag to it: $ eval `echo sed; cat featurelist | sed 's,^\(.*\),-e '\''s:DTB\1/B:DTBA NAME=feature_\1\1/A/B:'\'','; echo make.html` make_anchors.html this will give you anchor to features, e.g. make_anchor.html#feature_buildpkg a bit tricky the sed - could be easier, but this version is fast because it builds a giant sed expression instead of calling sed n times. - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqBqKwACgkQV/B5axfzrPsegwCdFo95i26IF9+jeUSLntVI4nhS msgAnRw4I4D1MwPUf1yBY8gJh3PHtX9S =cx8u -END PGP SIGNATURE-
Re: [gentoo-dev] Multimedia overlay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben de Groot wrote: We would like to invite anyone interested in developing and maintaining ebuilds related to multimedia in the wider sense: video, sound, tv, graphics and fonts. If you have any live ebuilds or otherwise bleeding edge packages, you can move them to the overlay for testing and shared maintenance. note that for sound-related packages there exists pro-audio overlay - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqAx3sACgkQV/B5axfzrPt0NQCfUGCrSkdRzldaAjhujsxoua6C wuoAoLWpX7Le62LOeANJLEYvJ9jDWSef =OEzv -END PGP SIGNATURE-
Re: [gentoo-dev] Stats test server running, please check it out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Pipping wrote: Hello again! I have set up a test server of the current stats code. If you have a minute to check it out that would rock. I'm very interested in overall feedback and bug reports. 1st: you could make an ebuild for it ;) 2nd: how to improve the output: you could make every data an hyperlink: that would help understand better the contents example: Archs: hyperlink arch name to wikipedia perhaps CFLAGS can link the flag name to GCC user guide relevant section, or to http://en.gentoo-wiki.com/wiki/CFLAGS#flagname same for other flags and MAKEOPTS FEATURES can link feature to make.conf man page: http://linuxreviews.org/man/make.conf/ (unfortunately this man page is rendered with no anchors over variable/features, so you could do better ^__^ USE flags can link to http://gentoo-portage.com/Search?search=use=useflagname (now appears down) System profiles: can link to profiles in cvs Package atoms can link to packages.g.o or to gentoo-portage.com those percentages are just funny: 33 (275.0 %)58 (483.3 %) 25 (208.3 %) Total 12 (100.0 %) [[ yeah, total is 100%, sometimes ]] kde 3 (25.0 %) others 554 (4616.67 %) Total 1066 (8883.33 %) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqAzOkACgkQV/B5axfzrPu9YwCfekbUmNJ0LfJ1PxqgAcCuFiD8 STYAn1xjdrMNmWusEV+EZlHPrL5Hr8gH =ZcgR -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-dev-announce] QA last rites for media-libs/libzzub and reverse dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I posted updated ebuilds for aldrin and armstrong (formerly libzzub). will sound keep maintaining it? Diego E. 'Flameeyes' Pettenò wrote: # Diego E. Pettenò flamee...@gentoo.org (8 Aug 2009) # on behalf of QA Team # +# libzzub: fails to build (bug #247149), lacking maintainer. +# others: need libzzub +# Removal on 2009-10-08 +media-libs/libzzub +media-sound/aldrin +dev-python/pyzzub + -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp+/+kACgkQV/B5axfzrPvwYgCdEEkcG4cdk84/MyD47IAHJFRj 51oAnRQw/aLM3wfcGfCbdoZX8wsxroLX =jXGj -END PGP SIGNATURE-
[gentoo-dev] work on Tcl-8.5 tracker - call for maintainers, reporters... or treecleaners
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tracker URL: https://bugs.gentoo.org/show_bug.cgi?id=173467 work for the tcl-8.5 tracker is reaching its end. there are few bugs still blocking the trackers. for every bug there is a solution (that is, for obsolete software, removal is a solution!) so, please, reporters and maintainers, do your job! I'll proceed with last rites as next action. summary of open bugs: media-tv/nxtvepg-2.7.7 fails with tcl-8.5.1 http://bugs.gentoo.org/show_bug.cgi?id=212682 status: version 2.8.0 works, waiting for maintainer sci-electronics/xcircuit doesn't run with tcl/tk 8.5 http://bugs.gentoo.org/show_bug.cgi?id=213852 status: fixed ebuild has been provided, waiting for maintainer x11-terms/clusterssh-3.22 doesn't work with tk-8.5 http://bugs.gentoo.org/show_bug.cgi?id=246950 status: version 3.26 works, waiting for maintainer dev-db/pgaccess-0.99.0.20040219 failed to start http://bugs.gentoo.org/show_bug.cgi?id=247210 status: unmaintained. remove? wait for maintainer net-dialup/isdn4k-utils-3.11_pre20071003: tcl dependency required? http://bugs.gentoo.org/show_bug.cgi?id=249311 status: invalid? wait for reply from reporter net-irc/quirc-0.9.84 doesn't emerge with tcl/tk 8.5 http://bugs.gentoo.org/show_bug.cgi?id=249468 status: fix provided. waiting for maintainer - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp9i/gACgkQV/B5axfzrPtCBQCgkzfAbalGVgtbUcVmPCT0Zu9A R84AoKFglh+jaR8KOq6ZvM0CB1umeeeN =tgq6 -END PGP SIGNATURE-
[gentoo-dev] portage and conflict resolutions!? (really is about =cat/pkg-${VER}* dependencies)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
{{sorry if you receive this message twice. I've got smtp problems and I
had to switch smtp, so please reply to THIS message only}}
there are pieces of software that consist of multiple packages (either
by upstream decision, or by a Gentoo dev that splits a package) and
have the additional restriction that every component must have the
exact same version (or in some case the exact major version).
examples are Qt, and SynCE (I'll take the latter as example, as it is
my area of competence).
SynCE requires the same major version of other synce packages to work.
so, inside synce ebuilds I do this:
synce_PV=$(get_version_component_range 1-2)
DEPEND= ... =app-pda/synce-libsynce-${synce_PV}* ...
I introduced this in synce 0.13 series, without thinking to what would
be happened (today) when a user (me) would have tried to upgrade from
synce 0.13 to synce 0.14 (in my overlay now)
portage can't resolve the conflict by itself, because, as it tries to
touch one of dependencies (upgrading 0.13 = 0.14), the currently
installed synce meta ebuild 0.13 [which depends on =0.13* deps too]
won't allow that (that is: block everything that is not 0.13*)
as a consequence, the multiple-packages-per-slot error is shown when
upgrading packages [1].
after exchanging a few words with some devs on IRC, I understand no
solution actually exists for this. :-(
but still, that ebuild snippet is a formally legal directive (?)
what I want to state is that the user has to have installed all synce
of the same major version (0.13.*) to properly work
I can see also why portage is failing:
when (trying to) upgrading the first package, the whole package set
enters into a *transient* state, which is not valid for normal usage
(that is: one 0.14 lib, and all other 0.13 libs), but still has to be
valid in order for portage being able to upgrade correctly all the
packages, because when portage will end [successfully!], the system
will be again in a valid state.
what I am going to propose here is a resolution strategy for this
(although this whole thing simply tells me that portage misses some
knowledge about the problem, like for example that dependencies should
be enforced only at transaction boundaries, or simply that we have a
class of dependencies that is irrelevant while system is in transient
state)
but, without trying to introduce overcomplicated solutions, as an
user, I could solve the initial problem very easily:
resolution strategy for it is to unmerge the old synce-0.13 packages,
then the user will be able to install 0.14 packages.
so, if the user can do it, why can't portage handle it? (so that even
a not-so-smart user could painlessly get out of this mess)
many devs pointed out how Qt works, that is, only depends on
=other-qt-library-${PV}, but that IMHO is an incomplete dep
specification (read: a workaround).
before I revert my changes to synce packages, are there any will to
change portage behavior in the near future to support and fix this?
[1]# emerge -auvDN world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] app-pda/synce-libsynce-0.14 [0.13] USE=hal 364 kB [0=1]
[ebuild U ] app-pda/synce-librapi2-0.14 [0.13.1] 483 kB [0=1]
[ebuild U ] app-pda/synce-librra-0.14 [0.13] 414 kB [0=1]
[ebuild U ] app-pda/synce-sync-engine-0.14 [0.13] 158 kB [0=1]
[ebuild U ] app-pda/synce-hal-0.14 [0.13] 314 kB [0=1]
[ebuild U ] app-pda/synce-kpm-0.14 [0.13] 90 kB [0=1]
[ebuild U ] app-pda/synce-trayicon-0.14 [0.13] USE=-debug 381 kB
[0=1]
[ebuild U ] app-pda/synce-gvfs-0.3 [0.2.1] USE=-debug 1,950 kB
[0=1]
[ebuild U ] app-pda/synce-0.14 [0.13] USE=gnome hal -kde -serial
0 kB [0=1]
Total: 9 packages (9 upgrades), Size of downloads: 4,151 kB
Portage tree and overlays:
[0] /usr/portage
[1] /usr/local/portage/synce
!!! Multiple package instances within a single package slot have been
pulled
!!! into the dependency graph, resulting in a slot conflict:
app-pda/synce-librapi2:0
('ebuild', '/', 'app-pda/synce-librapi2-0.14', 'merge') pulled in by
=app-pda/synce-librapi2-0.14* required by ('ebuild', '/',
'app-pda/synce-librra-0.14', 'merge')
=app-pda/synce-librapi2-0.14* required by ('ebuild', '/',
'app-pda/synce-hal-0.14', 'merge')
=app-pda/synce-librapi2-0.14* required by ('ebuild', '/',
'app-pda/synce-gvfs-0.3', 'merge')
(and 1 more)
('installed', '/', 'app-pda/synce-librapi2-0.13.1', 'nomerge')
pulled in by
=app-pda/synce-librapi2-0.13* required by ('installed', '/',
'app-pda/synce-gnomevfs-0.13', 'nomerge')
app-pda/synce-libsynce:0
('ebuild', '/', 'app-pda/synce-libsynce-0.14', 'merge') pulled in by
=app-pda/synce-libsynce-0.14* required by ('ebuild', '/',
'app-pda/synce-gvfs-0.3', 'merge')
=app-pda/synce-libsynce-0.14* required by ('ebuild', '/',
'app-pda/synce-hal-0.14', 'merge')
=app-pda/synce-libsynce-0.14* required by ('ebuild', '/',
Re: [gentoo-dev] Policy regarding enabling IUSE defaults application in ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maciej Mrozowski wrote: Hi I'd like to raise your attention on problem of in my opinion overusing IUSE defaults in various packages. Currently there seems to be no policy whatsoever at least advising when it's appropriate to add +useflag and when not, so it's just up to developer's taste. While it usually doesn't do any particular harm (but I guess security and prefix/alt team won't agree on this) - insanely enabling everything by default is not the best idea in my opinion. Of course we need an example. Let's have a look at latest stable media- video/mplayer-1.0_rc2_p20090322 ebuild: IUSE=3dnow 3dnowext +a52 +aac aalib +alsa altivec +amrnb +amrwb arts +ass bidi bindist bl +cddb +cdio cdparanoia -cpudetection -custom-cflags -custom-cpuopts debug dga +dirac directfb doc +dts +dv dvb +dvd +dvdnav dxr3 +enca +encode esd +faac +faad fbcon ftp gif ggi -gtk +iconv ipv6 jack joystick jpeg kernel_linux ladspa libcaca lirc +live lzo mad md5sum +mmx mmxext mng +mp2 +mp3 musepack nas +nemesi +network openal +opengl oss png pnm pulseaudio pvr +quicktime radio +rar +real +rtc -samba +schroedinger sdl +speex sse sse2 ssse3 svga teletext tga +theora +tremor +truetype +unicode v4l v4l2 vdpau vidix +vorbis -win32codecs +X +x264 xanim xinerama +xscreensaver +xv +xvid xvmc zoran moreover, there are certain USE flags that do not make sense in IUSE=+flag. for example alsa: if I use alsa, I want alsa globally enable in /etc/make.conf if I not use it (e.g. not in my profile) why should I explicitly put - -alsa in $USE? this may lead to an explosion of -flag flags in $USE. probably this example falls back into the flag which pulls dependencies case, but it is one more argument. configure scripts already have default values for the configure switches, and ebuilds should try to follow the defaults by putting +flag where needed, but with some exceptions (maybe on a flag-by-flag basis, or -more generally- by use-case, like you just wrote) - -- mescali...@g.o -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoz2rMACgkQV/B5axfzrPs1dACeKIfPZ6XMRlD4Nf6L5s9WyCw5 uukAoKVmF2OMSykUhKwQ7aR5vR4j/+Nz =LuUh -END PGP SIGNATURE-
Re: [gentoo-dev] Re: GLEP 55 Version 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ulrich Mueller wrote: On Sun, 07 Jun 2009, Steven J Long wrote: I'd just like to know what the implications would be for users if we kept the .ebuild extension, and a new PMS were rolled out stating that the mangler were allowed to find the EAPI without sourcing (and giving the restrictions) once portage 2.2 was stable, or the ability to handle this backported to 2.1.6, and issued in a release? Even if we do only a one-time change of the file extension, can we ever get rid of the old extension? unfortunately, no. Or are we then stuck with two extensions in the tree until the end of time? Let's assume for the moment that we change from .ebuild to .eb. better put this new ebuild type in a new tree; such a massive change to the tree its not recommended. Then we obviously cannot change all ebuilds in the tree to .eb, otherwise old Portage versions would see an empty tree and there would be no upgrade path. leaving actual .ebuilds as they are now (good healthy state :)) and making new development of .eb ebuilds happen in a new tree (I said new tree, but it could be any way that hides those new ebuild to OLD package managers) would help. only newer versions of package managers are required to support this, that is they will look for .eb (in new or current tree, not sure what's best) and then for .ebuilds, and ideally this should be transparent to old package managers and allow an upgrade path. - -- mescali...@g.o -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkortVIACgkQV/B5axfzrPsTiACeJCJb3F8Up/+CjHIwC3Slhn/6 yZgAoLcJgNn2d3W/JeZPkK85arUPW9vV =fR4T -END PGP SIGNATURE-
[gentoo-dev] Last rites: net-analyzer/ns and net-analyzer/nam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Federico Ferri mescali...@gentoo.org (26 May 2008) # Deprecated cause depending on unmaintained dev-tcltk/otcl. # Everything being moved to 'abandonware' overlay. # Possible replacement: net-misc/gns3 (sunrise overlay) # Going for removal in ~30 days if no one objects. # removal bug #271305 net-analyzer/ns net-analyzer/nam # Federico Ferri mescali...@gentoo.org (26 May 2008) # Unmaintained upstream. # Going for removal in ~30 days. # removal bug #271307 dev-tcltk/otcl dev-tcltk/tclcl -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkob8bEACgkQV/B5axfzrPvnFQCeId9Sg1yOsOPzqJjfAJZpWPBO hTkAnj8d5lpl/TvXMSF3KjxVXNyswKvA =tlPp -END PGP SIGNATURE-
Re: [gentoo-dev] New app-eselect category?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp Riegger wrote: Hello world! On Tue, 2009-05-26 at 16:24 +0200, Tiziano Müller wrote: Am Dienstag, den 26.05.2009, 09:04 +0200 schrieb Ulrich Mueller: As of today, app-admin contains 179 packages. We could move the 27 eselect-* packages to a new app-eselect category (eselect itself would stay in app-admin). Opinions? Yes in general. Maybe think about what happens when the Universal Select Tool gets released/used. Possible alternative: app-select? How will that tool be called? Maybe uselect? Another alternative: app-xselect. seems like here two-level categories are a limitation. if three-level categories were available, I'd say app-admin-xselect. since the last two levels make more sense, compared to the 1+3, if you believe the app-admin category is too crowded, why not just make a new category admin-XYZ, thus adding the missing third level? - -- Federico Ferri (mescalinum) Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkocAeQACgkQV/B5axfzrPv12gCeO8tVVCvJcqb0OK4qsFBxELe3 VuoAoKub0H7s1u0yvPR9n4DSNeKmN+rE =dovF -END PGP SIGNATURE-
Re: [gentoo-dev] New app-eselect category?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 AllenJB wrote: Fabian Groffen wrote: On 26-05-2009 09:04:46 +0200, Ulrich Mueller wrote: As of today, app-admin contains 179 packages. We could move the 27 eselect-* packages to a new app-eselect category (eselect itself would stay in app-admin). Opinions? I hate package moves, so is it really *really* necessary? I have to agree. app-admin is hardly among the largest categories. Perhaps we should consider splitting up the 400 odd packages in kde-base (kde-graphics, kde-admin, kde-games, etc) =P As for app-admin-eselect, I'd favor tags over increasing the category levels, tho I'm not the three-levels-category was an example. the realistic approach I proposed is splitting app-admin in many two-level categories: + admin-eselect + admin-sysconf + admin-www + admin-apache ... as it usually has been done in such cases. - -- Federico Ferri (mescalinum) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkocHNoACgkQV/B5axfzrPsCzgCeJZknEWRV1o2SjPpPc9HJ0k1u bUoAnRygFK/mRPfAguutyUmZWssnPyXh =hZFu -END PGP SIGNATURE-
[gentoo-dev] =dev-lang/{tcl,tk}-8.5* unmask
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It's been long time since tcl-8.5 is sitting in tree p.masked.
a number of bugs have been fixed in the past (last bugs I've fixed
this evening: itcl-3.3, tix, tclpython; one I can't fix is otcl -
moreover, it's damn obsolete (last commit 2 years ago))
the remaining bugs in the tracker [1] are mostly applications (not
tcltk's herd) with (mostly) no rdeps.
I think it's now safe for {tcl,tk}-8.5 to enter the testing branch.
I'll end my job in Anritsu on 30th April, so I'll have more time for
Gentoo project =) ...and for supporting this task.
if there are no objections, I'll unmask tcl/tk 8.5* (I've just bumped
the package to 8.5.7) by the next week.
[1] http://bugs.gentoo.org/show_bug.cgi?id=173467 - [Tracker]
dev-lang/{tcl,tk}-8.5 incompatible packages
Best regards,
Federico Ferri (mescalinum)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkno74AACgkQV/B5axfzrPt7agCfal4MSsx0sgT62Nbx4U98BAU7
RAAAoLxnkB/riD8DKyeafSn5uZeUjTD8
=oakn
-END PGP SIGNATURE-
Re: [gentoo-dev] Xorg 1.5.3 is going stable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rémi Cardona wrote: Hi all, This is just a quick announcement to let everyone know that Xorg 1.5.3 and pretty much all X libraries and apps which have been sitting in ~arch for months/years are finally going to go stable, replacing our old, rusty and busted 1.3 X server. Arch Teams have received the final package list just this afternoon. The Upgrade Guide is located at http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml perhaps you made a typo did you meant INPUT_DEVICES=evdev instead of INPUT_DRIVER=evdev, isn't it? bye - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknRLIIACgkQV/B5axfzrPvrgwCeJkfiypY9cO/i/LTTDh0Bjxjj cqcAn0DWEUIK9ftCstJFDZMr3NlA/NKH =6qxR -END PGP SIGNATURE-
Re: [gentoo-dev] Tcl/Tk multi-slot testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Volkov wrote: В Птн, 13/03/2009 в 19:09 +0100, Federico Ferri пишет: btw, on a different topic: the number of bugs on tcltk (8.5) has lowered a bit. maybe it's time to unmask it and have package maintainers fix the outdated apps? A number of packages depend on itcl which does not builds with 8.5. unfortunately itcl didn't seen a release since long time ago (but development happens in CVS) few weeks ago, Itcl/Itk 4.0_beta3 were released (requires Tcl 8.6, which is in beta1) you can find those fresh pkgs in my tcl-8.6 overlay (layman -a tcl-8.6) It is maintained by tcl/tk herd. What's your stance on this package? Same question about otcl, but less packages (the only net-analyzer/nam?) depend on it. I'm sorry, I tried but didn't succeed to fix otcl :-( I could report the issue upstream, and let things flow - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm9bNUACgkQV/B5axfzrPu1EACbB52ul7RKLFFkfzNT3yQuBVAT /CcAnR7oNqakXvgeham2afm3U8WV/5If =shj/ -END PGP SIGNATURE-
[gentoo-dev] Tcl/Tk multi-slot testing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've done some work on providing multi-slot Tcl and Tk packages.
you can find it on my overlay [1]
this work consists basiaclly of:
1) modifying tcl/tk ebuilds for install stuff with
- --prefix=/usr/tcl/${SLOT}
and merging all the ebuilds code into the tcltk eclass
2) provide a tcltk eselect module for switching the active tcltk version
pro:
this would allow less painful unmasking and stabilizing of tcl/tk
packages, so users can have a tcl runtime of the 21st century =))
tcltk apps that are less vital (i.e. have not ported to newer
runtimes) could still live on a system using the tcltk switcher
potential issues:
this could become troublesome if there is a tcl extension installed,
and is needed both for tcl 8.5 and tcl 8.6. it should be reinstalled
after each 'eselect tcltk set ...'
btw, on a different topic: the number of bugs on tcltk (8.5) has
lowered a bit.
maybe it's time to unmask it and have package maintainers fix the
outdated apps?
[1] http://overlays.gentoo.org/dev/mescalinum
* uninstall previous versions of tcl/tk if you are testing this, as
slotmoves are not possible for overlays
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm6oUgACgkQV/B5axfzrPvBWACffga+Jv3492sFXpojSChujoR4
/j8An1SNh/Ruwt3JMG7JWHfwCKj/2mJc
=5Q1Q
-END PGP SIGNATURE-
Re: [gentoo-dev] Category tags on packages (was: new categories:)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nirbheek Chauhan wrote:
${PORTDIR}/tags/games/puzzles/ksudoku - ../../../kde-base/ksudoku
${PORTDIR}/tags/games/puzzles/sudoku/ksudoku -
../../../../kde-base/ksudoku
${PORTDIR}/tags/dying/amarok - ../media-sound/amarok
- --
I like the tag idea.
I don't like tag as described above.
I feel having tags organized in hierarchical way is inappropriate.
that just makes another organization of packages in categories.
tags - packages is a many-to-many relation.
btw, if the DESCRIPTION field is well written, it functions as a tag.
e.g.:
$ eix -c -S dockapp -S net
[N] x11-plugins/allin1 (--): All in one monitoring dockapp: RAM, CPU,
Net, Power, df, seti
[N] x11-plugins/wmifinfo (0.09): a dockapp for monitoring network
interfaces.
[N] x11-plugins/wminet (3.0.0): dockapp for monitoring internet
connections to and from your computer.
[N] x11-plugins/wmitime (0.3): Overglorified clock dockapp w/time,
date, and internet time
[N] x11-plugins/wmnd (0.4.11-r1): WindowMaker Network Devices (dockapp)
[N] x11-plugins/wmnetload (1.3-r2): Network interface monitor dockapp
[N] x11-plugins/wmwifi (0.6): wireless network interface monitor dockapp
Found 7 matches.
although DESCRIPTION doesn't contain obvious tags.
perhaps it's worth the addition of a TAGS field (?) that has to be
searched just like DESCRIPTION
just my 2E-2
Federico Ferri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmPHZIACgkQV/B5axfzrPu9ewCgr2XRqbTy9XycR5g0KeFWtOnV
ou8An2WKDEeIsPioWHn/lVEtPrHF4QNg
=GvLh
-END PGP SIGNATURE-
Re: [gentoo-dev] Category tags on packages (was: new categories:)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nirbheek Chauhan wrote:
I like the tag idea. I don't like tag as described above. I feel
having tags organized in hierarchical way is inappropriate. that
just makes another organization of packages in categories.
KDE and OLPC are looking towards hierarchical tags as the future of
content management. People don't really use folders, they use
tags:
Holidays 2008 Switzerland Open Source Gentoo
portage
the above looks exactly like folders (unless you elaborate on that)
I don't know what KDE or OLPC are thinking. when I tag my stuff I'd
probably have:
photo001.jpg {2008,holidays,nature,switzerland}
photo002.jpg {2008,holidays,fun,switzerland,zurich}
photo158.jpg {2009,computer,me,misc}
(the order of tags here is alphabetical)
tags - packages is a many-to-many relation.
Aren't tags _made_ to be many-to-many?
ie, symlinking can allow that kind of relationship
can you show an example (of many-2-many relation, with symlinks)?
Federico Ferri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmPJHsACgkQV/B5axfzrPtbpACfcq8qpQdkneWplS8H3XgEiry1
1qUAoKZcMUGDyro8nHwrSvNwflm0nyGn
=PV0+
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: Category tags on packages (was: new categories:)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: I've always thought it would be cool to have user-created tag clouds, del.icio.us-style, on packages.g.o. I expect this would be a hell of a lot of work to set up however. initially, packages could be automatically tagges, based on the following criteria: - - category - - common* words found in $DESCRIPTION - - common* words found in metadata.xml:longdescription if any - - extend the above with description found on the net plus: - - a hidden tag to indicate that tags were assigned automatically, to be removed whenever the pkg tags are reviewed by a human += 2E-2 Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmPXfEACgkQV/B5axfzrPu46wCdFaTMWf4LSGCRHJJFB0xh0Vio yYwAn0siZ5oIaec3H2PfDEc6q/t02b6D =1Pjf -END PGP SIGNATURE-
Re: [gentoo-dev] Handling Launchpad SRC_URI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Josh Saddler wrote:
Right now, there's no canonical (heh) way of handling SRC_URI for
projects that have their files at launchpad.net. We need a standard way
of handling Launchpad SRC_URIs, similar to what we do with
mirror://sourceforge/ SRC_URIs.
1. Some packages use the launchpadlibrarian.net download redirect, which
results in a non-helpful server-generated number:
(gnome-catalog)
SRC_URI=http://launchpadlibrarian.net/11326737/${PN}_${PV}.orig.tar.gz
2. Some hack up interesting MY_P stuff:
(gnome-do-plugins)
MY_PN=do-plugins
PVC=$(get_version_component_range 1-2)
PVC2=$(get_version_component_range 1-3)
SRC_URI=https://launchpad.net/${MY_PN}/${PVC}/${PVC2}/+download/${P}.tar.gz;
(avant-window-navigator-extras)
MY_P=awn-extras-applets-${PV}
SRC_URI=https://launchpad.net/awn-extras/${PV%.*}/${PV}/+download/${MY_P}.tar.gz;
The AWN-extras ebuild is the closest to the right way of doing it, I
think.
So can we agree on a standard way of treating Launchpad SRC_URIs and get
the handler support into Portage?
3. (seq24-0.9.0)
SRC_URI=http://edge.launchpad.net/seq24/trunk/${PV}/+download/${P}.tar.bz2;
just another example of different SRC_URI
- --
FF
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkl8s0oACgkQV/B5axfzrPssBACffhjl4xMsQSGL8Ez6ngdlkH43
56MAoI9YIesKOrNMg5lYuJyR5xpKUVXP
=wLnZ
-END PGP 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] 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-
[gentoo-dev] Proposal: add a compiler-version entry to pkg db
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk9v14ACgkQV/B5axfzrPucugCfRN51KpJZ/HYCYA3v/Z2lAhaf 8eUAniZONnbWtN4f5CblJzaxEMbFWI3m =4l7H -END PGP SIGNATURE-
Re: [gentoo-dev] Re: GLEP 55
Joe Peterson ha scritto:
It was mentioned that comments are to be ignored, but you point out a
perfect and very fundamental example of where this is not true:
#!/usr/bin/env bash
Putting another line close to this one with:
#EAPI=42
or
#!EAPI=42
if you like (conforms more to the shell script specifier), is not too
muchh of a stretch.
The so-called shebang; very good in my opinion!
Works very well for true shell scripts. why it can't work for ebuilds?
First, I think of two alternatives:
1) the interpreter is the EAPI (with /usr/bin/ebuild being EAPI=0)
this will be the first line of a EAPI=0 ebuild:
#!/usr/bin/ebuild
this will be a EAPI=paludis ebuild:
#!/usr/bin/ebuild-paludis
apparently it's the same mechanism the shell uses to execute a shell
script, except for the fact that:
* ebuild is not an executable file
* an external program is used to determine the EAPI (i.e.: extract the
shebang)
2) fixed interpreter name, use arguments for switching EAPIs
this is another option, wich carries itself a GREAT power of leaving an
open door when in the future will happen something similar to what we
have now, where switching the EAPI (or replace EAPI with something else)
is critical and breaks compatibility.
example - EAPI=0:
#!/usr/bin/ebuild
...
another eapi:
#!/usr/bin/ebuild -eapi paludis
This allows virtually unlimited cases similar to this; for example when
switching to another-feature-that-breaks-things, another switch will
be used:
#!/usr/bin/ebuild -eapi foo -fluffy bar
Advantages of both solutions:
* easy to parse
* doesn't break compatibility
What it does not address:
* doesn't break compatibility
In fact, it should break compatibility.
again I can think of two solutions:
1) change the ebuild extension to a different value, once and
(hopefully) forever, e.g. from .ebuild to .xbuild, and leave the minimal
set of .ebuild-s for the upgrade path
2) use two repositories: the legacy one, needed for the upgrade path,
and the shyny-new-repository with the new ebuilds format
best regards,
Federico Ferri
--
#include stdio.h
main(){printf(%x,4275974592);}
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d-(--) a- C++$ UL+++$ L+++$ E--- W++@ w--@
PE PGP+ R- tv-- DI+ D++ h+
--END GEEK CODE BLOCK--
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Ciaran McCreesh ha scritto:
On Thu, 27 Dec 2007 18:03:27 +
Roy Marples [EMAIL PROTECTED] wrote:
Using your analogy you should then recognise that there is a strong
dislike for pink and should seek a new colour that allows the building
of said extensions.
And what colour would that be? We've already ruled out purple, brown
and yellow, and no-one has yet found any other colour of paint.
sorry if this has already suggested.
my idea is to use shebang; the advantage in using shebang is that file
doesn't need to be sourced or parsed by complex algorithms in order to
extract the necessary information.
an example:
#!/usr/bin/ebuild eapi=1
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
DESCRIPTION=My EAPI-1 ebuild
HOMEPAGE=http://www.gentoo.org/;
SRC_URI=
LICENSE=GPL-2
...
shebang's synopsis would look something like:
#!interpreter [key=value] [key=value] [...]
pros:
1) it's standard. shell scripts use it. why ebuilds shouldn't?
2) it's easy to parse:
eval `head -n1 $ebuild | cut -d\ -f2-`; echo $eapi
3) in the future, for any other situation analogous to this, you could
add another key=value to the ebuild's shebang
4) easily checked by repoman
cons:
?
just my two Eurocents.
since now you can bite me ;-)
--
#include stdio.h
main(){printf(%x,4275974592);}
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: new gnustep eclasses
Bernard Cafarelli ha scritto:
Hello all,
hi
that's a cool project you are working on!
I wish I could contribute actively in the future
Feedback, comments, suggestions, other ideas are welcome!
right now I found a problem (I wonder if it happens on others too) about
gnustep-back-art-0.12.0. unfortunately I don't figure how to fix it, so
I opened a bug at http://bugs.gentoo.org/show_bug.cgi?id=188044
I wish someone could help.
I'll ask to gnustep guys as soon as possible too
--
#include stdio.h
main(){printf(%x,4275974592);}
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] 2.6.22 stable plans
William L. Thomson Jr. ha scritto: This is for the very short term. I don't want to maintain a driver for hardware I don't own and never intend on purchasing. Well seems most AMD machines are likely to ship with ATI chipsets these days. For sure most lappies :) Interesting side note. Beryl/Xgl works on my laptop, ATI Xpress200m. cool... would you like to write a pair of lines describing the process, software (ebuilds) versions used, tips and quirks? cause I tried many time but always failes someway, so that I started to think ati-drivers for X200M are bork :S -- 0xff -- [EMAIL PROTECTED] mailing list
