Re: [gentoo-dev] Race condition in Netfilter triggered by glibc 2.9
Hi! On Thu, 29 Jan 2009, Tobias Klausmann wrote: I tried understanding what glibc 2.9 does regarding dns lookups, but since it involves a rather complex (and probably quite clever) queueing mechanism, I'm not quite sure I wouldn't break more than I fix in doing so. Apparently, it's enough to not export gethostbyname4() to fix this. I'll try building a glibc-2.9_p20081201-r1 plus this patch: http://pasky.or.cz/~pasky/dev/glibc/glibc-2.10-dns-no-gethostbyname4.diff If it works, I'll test drive it for a while and report back. Regards, Tobias -- if(ct0) ct=2;/* Shit happens.. */ linux-2.6.6/drivers/net/wan/z85230.c
[gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'd like to add a new metadata cache value called DIGESTS which will contain a space separated list of digests which can be used to validate the metadata cache. Like INHERITED and DEFINED_PHASES [1], it will be automatically generated. The first digest in the list will correspond to the ebuild. If there are any inherited eclasses, the digests of those eclasses will follow in a space separated list, in the same order that they occur in the INHERITED variable. The value of the DIGESTS variable will be on line 18 of the metadata cache (just after DEFINED_PHASES). For the digest format, I suggest that we use the leftmost 10 hexadecimal digits of the SHA-1 digest. The rationale for limiting it to 10 digits (out of 40) is to save space. Due to the avalanche effect [2], 10 digits should be sufficient to ensure that problems resulting from hash collisions are extremely unlikely. The primary reason to use a digest for cache validation instead of a timestamp is that it allows the cache validation mechanism to work even if the tree is distributed with a protocol that does not preserve timestamps, such as git or subversion. This would make it possible to distribute metadata cache directly from git and subversion repositories (among others). Since a digest is inherently more expensive to obtain than a timestamp, package managers may use the Manifest entries as a digest cache, in order to avoid the need to compute digests of ebuilds during dependency calculations. Does the suggested approach seem reasonable? Would anybody like to suggest any changes? [1] http://archives.gentoo.org/gentoo-dev/msg_8c34d8efbc0d31ab28c517403dc83f62.xml [2] http://en.wikipedia.org/wiki/Avalanche_effect - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmHWOQACgkQ/ejvha5XGaOJeQCgouZGO+pbOgJYkzssRVhzMDwt Cq4AoN6NG7SmJ6XjEked1WnZ+CJPXVWj =JSDL -END PGP SIGNATURE-
Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)
Norberto Bensa wrote: Excuse me for thread hijack. Would it make sense to add (for example): kde-games gnome-games I'm afraid not. ? Or the other way around. Move kde-base/kmail to mail-client/kmail ? not sure how useful could be but could make more sense even if right now kde-base contains everything comes from the main kde distribution. What about both ways using symlinks: kde-games/ksudoku - games-puzzle/ksudoku ? No symlinks and no aliases please. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)
On Mon, Feb 2, 2009 at 7:15 PM, Luca Barbato lu_z...@gentoo.org wrote: Norberto Bensa wrote: What about both ways using symlinks: kde-games/ksudoku - games-puzzle/ksudoku ? No symlinks and no aliases please. Ok. My idea, if someone is wondering, was asnwer the questions: what email clients are available? and which one is for kde? A simple ls -l /usr/portage/mail-client/ would show which ones. I thought it could be useful. Regards, Norberto
Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)
On Monday 02 of February 2009 22:15:53 Luca Barbato wrote: not sure how useful could be but could make more sense even if right now kde-base contains everything comes from the main kde distribution. To be more specific, kde-base contains everything (and only) that is distributed as KDE stable release (no extragear included). And it causes confusion as when packages are dropped from KDE release schedule (so they usually go back to extragear to release when they want), one needs to look to new place for them (in kde-misc or somewhere else). Actually categories are bad idea imho. I was thinking, maybe it would be possible to drop categories completely in the future (maybe keeping symlinks for compatibility and to ease migration) and to put *all* packages in one directory - that would require making all names unique of course. Categorization could be provided for user/search tools as tag clouds being defined in metadata.xml as vector of tag:weight values where tag would be some word from defined dictionary (word like mail client kde dns or sth) and weight - real value [0,1] defining how relevant is that tag. For compatibility's sake symlinks could be provided, in.ex. sys-devel/gcc - all/gcc. But that's just an off-topic. -- regards MM -- Nie boj sie przyszlosci! Zapytaj wrozke http://link.interia.pl/f2049
[gentoo-dev] ebuild for x11-libs/qt-3.3.8-r3 is missing after portage update but required by the system configuration
Hello, After updating portage via emerge --sync, I tried to perform world update issuing the following command: emerge -DupvN world The command ended with the following message: These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds to satisfy =x11-libs/qt-3.3.8-r3. (dependency required by net-wireless/kdebluetooth-1.0_beta1-r2 [installed]) (dependency required by world [argument]) So, what seems to be the problem? Is it my system configuration or is it a portage issue? TIA Dimitris
Re: [gentoo-dev] ebuild for x11-libs/qt-3.3.8-r3 is missing after portage update but required by the system configuration
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dimitris Kavadas wrote:
Hello,
After updating portage via emerge --sync, I tried to perform world
update issuing the following command:
emerge -DupvN world
The command ended with the following message:
These are the packages that would be merged, in order:
Calculating dependencies... done!
emerge: there are no ebuilds to satisfy =x11-libs/qt-3.3.8-r3.
(dependency required by net-wireless/kdebluetooth-1.0_beta1-r2 [installed])
(dependency required by world [argument])
So, what seems to be the problem?
Is it my system configuration or is it a portage issue?
Both of those versions are no longer in the main tree. I suggest you sync again
and that should do it.
These kinds of questions aren't appropriate for gentoo-dev btw.
Good luck,
Marijn
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmHfpgACgkQp/VmCx0OL2xfzQCfbnkX50IbVvU6eXTMUBPfCUpG
vwwAnRROnCVtdwZJ0SMfIO4AIFQmrVn8
=mjpq
-END PGP SIGNATURE-
Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)
On Sun, 2009-02-01 at 19:58 +0100, Rémi Cardona wrote: Le 01/02/2009 18:32, Norberto Bensa a écrit : Excuse me for thread hijack. Would it make sense to add (for example): gnome-games gnome-games is already the name of a package that contains all official GNOME games. Only a handful are also released and packaged separately. Useless for us IMHO. That said, I'm still threatening to split gnome-games up to individual packages one rainy day. But if that goes through (time-wise and has team agreement), the individual games would be in the suitable games-* category (games-arcade, games-board, etc) with a gnome-extra/gnome-games still in place (one day gnome-base/) - newer versions being meta packages pulling in the individual official games. And not in a gnome-games/ category. Then you can find gnome-games meta package from gnome-*/ category and individual games in their suitable category (glchess is a cool board game, etc).. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] Category tags on packages (was: new categories:)
On Mon, 2009-02-02 at 23:10 +0100, Maciej Mrozowski wrote: On Monday 02 of February 2009 22:15:53 Luca Barbato wrote: not sure how useful could be but could make more sense even if right now kde-base contains everything comes from the main kde distribution. To be more specific, kde-base contains everything (and only) that is distributed as KDE stable release (no extragear included). And it causes confusion as when packages are dropped from KDE release schedule (so they usually go back to extragear to release when they want), one needs to look to new place for them (in kde-misc or somewhere else). Actually categories are bad idea imho. I was thinking, maybe it would be possible to drop categories completely in the future (maybe keeping symlinks for compatibility and to ease migration) and to put *all* packages in one directory - that would require making all names unique of course. Categorization could be provided for user/search tools as tag clouds being defined in metadata.xml as vector of tag:weight values where tag would be some word from defined dictionary (word like mail client kde dns or sth) and weight - real value [0,1] defining how relevant is that tag. For compatibility's sake symlinks could be provided, in.ex. sys-devel/gcc - all/gcc. But that's just an off-topic. I agree that a tag kind of approach would be nice. Someone should actually do work on it. Here's a random similar idea that I think might work well as a GLEP proposition, that I was about to reply to a different subthread before noticing this post: Packages metadata.xml can be extended with an unlimited amount of tag elements, whose #text can be a tag string, but one that is limited to a given list in some other place - to have a list of existing tags and not just randomly have tags for everything. Make an effort to populate all packages with sensible tags. Then write tools around it that can show you all packages with a given tag or tags, what tags exist, etc. Those will be your new categories that answer the question of what mail clients are there (mail-client tag) or what mail clients are there using GTK+, well suited for a GNOME environment (mail-client and gnome tags). Keep categories in place for repository tree sanity (not a huge amount of directories with all packages being sibling dirs) and easier implementation of it all. No-one really types in the categories anyway, and with a tool that deals with the tags, you don't look at the subdirs either - so categories for the user just become a way to differentiate packages with the same name for the few cases there are equal names. However those that prefer the categories approach, can keep using it. Developers also deal with categories, but that's easy enough to keep going as is. Less radical, less controversial, better viability to actually get done. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Category tags on packages (was: new categories:)
On Tue, Feb 3, 2009 at 6:47 AM, Mart Raudsepp l...@gentoo.org wrote:
I agree that a tag kind of approach would be nice. Someone should
actually do work on it.
Here's a random similar idea that I think might work well as a GLEP
proposition, that I was about to reply to a different subthread before
noticing this post:
snip random idea :p
The simplest method I can think of is:
${PORTDIR}/tags/games/puzzles/ksudoku - ../../../kde-base/ksudoku
Yes, that's a symlink inside a new root-directory tags where games
is a tag and puzzles is a sub-tag. If for some reason we get an
explosion in sudoku games in portage (with weird names), we can make a
new sub-tag games/puzzles/sudoku/
${PORTDIR}/tags/games/puzzles/sudoku/ksudoku - ../../../../kde-base/ksudoku
And this won't cause any problems since higher tags are inherited.
Another usage of tagging could be marking packages as deprecated to
ease out removal of old packages.
${PORTDIR}/tags/dying/amarok - ../media-sound/amarok
/me hides from the amarok lovers.
Symlinking has the advantage of being a natural extension of our
favourite flat-file db[1] to tagging. Having a new folder instead of
symlinking inside other categories has the advantage of being
backwards-compatible, and will also prevent an explosion in the number
of categories in the root dir.
FWIW, git (atleast) preserves symlinks in source trees, so once the
move to git is complete, there will be no obstacles left in this
thing's implementation ;)
1. That's the portage tree, btw :p
--
~Nirbheek Chauhan
Re: [gentoo-dev] new categories:
Maciej Mrozowski wrote: I was thinking, maybe it would be possible to drop categories completely in the future (maybe keeping symlinks for compatibility and to ease migration) and to put *all* packages in one directory - that would require making all names unique of course. Tags for packages are not a new idea; it's been brought up on this list before. But I really, really, don't like the idea of renaming packages. So, what, we're turning into Debian? Arbitrary package (re)naming? Yuck! Our current policy is to call the package what upstream calls it. We can do this largely *because* of categories. There are a few noncompliant packages, but the system generally works pretty well. signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] [Fwd: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation]
---BeginMessage--- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'd like to add a new metadata cache value called DIGESTS which will contain a space separated list of digests which can be used to validate the metadata cache. Like INHERITED and DEFINED_PHASES [1], it will be automatically generated. The first digest in the list will correspond to the ebuild. If there are any inherited eclasses, the digests of those eclasses will follow in a space separated list, in the same order that they occur in the INHERITED variable. The value of the DIGESTS variable will be on line 18 of the metadata cache (just after DEFINED_PHASES). For the digest format, I suggest that we use the leftmost 10 hexadecimal digits of the SHA-1 digest. The rationale for limiting it to 10 digits (out of 40) is to save space. Due to the avalanche effect [2], 10 digits should be sufficient to ensure that problems resulting from hash collisions are extremely unlikely. The primary reason to use a digest for cache validation instead of a timestamp is that it allows the cache validation mechanism to work even if the tree is distributed with a protocol that does not preserve timestamps, such as git or subversion. This would make it possible to distribute metadata cache directly from git and subversion repositories (among others). Since a digest is inherently more expensive to obtain than a timestamp, package managers may use the Manifest entries as a digest cache, in order to avoid the need to compute digests of ebuilds during dependency calculations. Does the suggested approach seem reasonable? Would anybody like to suggest any changes? [1] http://archives.gentoo.org/gentoo-dev/msg_8c34d8efbc0d31ab28c517403dc83f62.xml [2] http://en.wikipedia.org/wiki/Avalanche_effect - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmHWOQACgkQ/ejvha5XGaOJeQCgouZGO+pbOgJYkzssRVhzMDwt Cq4AoN6NG7SmJ6XjEked1WnZ+CJPXVWj =JSDL -END PGP SIGNATURE- ---End Message---
