Re: [gentoo-dev] new categories:

[Josh Saddler]

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

Re: [gentoo-dev] Category tags on packages (was: new categories:)

[Nirbheek Chauhan]

On Tue, Feb 3, 2009 at 6:47 AM, Mart Raudsepp  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:


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

[gentoo-dev] Category tags on packages (was: new categories:)

[Mart Raudsepp]

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 
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] new categories: (was: Last Rites: games-puzzle/ksudoku)

[Mart Raudsepp]

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

Re: [gentoo-dev] ebuild for x11-libs/qt-3.3.8-r3 is missing after portage update but required by the system configuration

[Marijn Schouten (hkBst)]

-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
, #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-

[gentoo-dev] ebuild for x11-libs/qt-3.3.8-r3 is missing after portage update but required by the system configuration

[Dimitris Kavadas]

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] new categories: (was: Last Rites: games-puzzle/ksudoku)

[Maciej Mrozowski]

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 

Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)

[Norberto Bensa]

On Mon, Feb 2, 2009 at 7:15 PM, Luca Barbato  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)

[Luca Barbato]

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

[gentoo-dev] [RFC] DIGESTS metadata variable for cache validation

[Zac Medico]

-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] Race condition in Netfilter triggered by glibc 2.9

[Tobias Klausmann]

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(ct<0)
ct=2;/* Shit happens.. */
linux-2.6.6/drivers/net/wan/z85230.c