8:44 a.m.
Hi,
This morning I checked rawhide. My x86_64 machine has no 386 packages on it.
Doing yum update suddenly wanted to pull in 386 packages to my system. I
updated packages 1 by 1 until I was down to updating NetworkManager.x86_64.
If I type "yum update NetworkManager.x86_64" or "yum update
NetworkManager",
I get only 64 bit packages. If I type "yum update", it pulls in the 386
version of NetworkManager and all its dependencies.
So, those of you with pristine 64 bit machines, watch out for this or 32 bit
packages will start creeping back into your system. Is this a known problem
or should a bz be filed?
Thanks,
-Steve
9:30 a.m.
On Sat, 2007-09-22 at 09:44 -0400, Steve Grubb wrote:
Hi,
This morning I checked rawhide. My x86_64 machine has no 386 packages on it.
Doing yum update suddenly wanted to pull in 386 packages to my system. I
updated packages 1 by 1 until I was down to updating NetworkManager.x86_64.
If I type "yum update NetworkManager.x86_64" or "yum update
NetworkManager",
I get only 64 bit packages. If I type "yum update", it pulls in the 386
version of NetworkManager and all its dependencies.
So, those of you with pristine 64 bit machines, watch out for this or 32 bit
packages will start creeping back into your system. Is this a known problem
or should a bz be filed?
what ver of yum is this?
and can you post to a bug the yum -d 6 update
output?
-sv
10:04 a.m.
On Saturday 22 September 2007 10:30:24 seth vidal wrote:
what ver of yum is this?
current rawhide: 3.2.5-3
and can you post to a bug the yum -d 6 update
output?
Sure, bz 301661. One thing I found, its related to dhcdbd getting deleted. If
you delete by hand, it works fine. If yum does the delete, it pulls in 386
packages.
-Steve
4:14 p.m.
On Sat, 22 Sep 2007 11:04:34 -0400
Steve Grubb <sgrubb(a)redhat.com> wrote:
Sure, bz 301661. One thing I found, its related to dhcdbd getting
deleted. If you delete by hand, it works fine. If yum does the
delete, it pulls in 386 packages.
Ah right, it's being obsoleted by multiple packages in the repo, both
the x86_64 versions and the i386 versions.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
6:33 p.m.
On Sat, 2007-09-22 at 17:14 -0400, Jesse Keating wrote:
On Sat, 22 Sep 2007 11:04:34 -0400
Steve Grubb <sgrubb(a)redhat.com> wrote:
> Sure, bz 301661. One thing I found, its related to dhcdbd getting
> deleted. If you delete by hand, it works fine. If yum does the
> delete, it pulls in 386 packages.
Ah right, it's being obsoleted by multiple packages in the repo, both
the x86_64 versions and the i386 versions.
Ding- you got it - well done.
Steve,
If you want to avoid this behavior in the future add: exclude=*.?86 to
your yum.conf.
-sv
6:42 p.m.
On 9/22/07, seth vidal <skvidal(a)fedoraproject.org> wrote:
If you want to avoid this behavior in the future add: exclude=*.?86
to
your yum.conf.
Is this something that anaconda should add to all x86_64 installations
or is this just a workaround that might hide bugs and prevent Steve
from being the canary in the coal mine?
/Mike
6:44 p.m.
On Sat, 2007-09-22 at 19:42 -0400, Michael Wiktowy wrote:
On 9/22/07, seth vidal <skvidal(a)fedoraproject.org> wrote:
> If you want to avoid this behavior in the future add: exclude=*.?86 to
> your yum.conf.
Is this something that anaconda should add to all x86_64 installations
or is this just a workaround that might hide bugs and prevent Steve
from being the canary in the coal mine?
There isn't a bug here.Yum is doing exactly what it says to do. If steve
wants an x86_64-pure system then in order to avoid obsoletes coming in
like this he needs to add an exclude.
-sv
6:55 p.m.
On Sat, Sep 22, 2007 at 07:44:19PM -0400, seth vidal wrote:
There isn't a bug here.Yum is doing exactly what it says to do.
If steve
wants an x86_64-pure system then in order to avoid obsoletes coming in
like this he needs to add an exclude.
The problem comes in when people want a mostly-pure system. The current
infrastructure isn't designed to handle that.
There's a simple plugin in yum-utils to work towards this behavior, but it
needs a lot of work. People who are interested in this should work on it.
(yum-basearchonly).
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
7:14 p.m.
On 9/22/07, Matthew Miller <mattdm(a)mattdm.org> wrote:
On Sat, Sep 22, 2007 at 07:44:19PM -0400, seth vidal wrote:
> There isn't a bug here.Yum is doing exactly what it says to do. If steve
> wants an x86_64-pure system then in order to avoid obsoletes coming in
> like this he needs to add an exclude.
The problem comes in when people want a mostly-pure system. The current
infrastructure isn't designed to handle that.
There's a simple plugin in yum-utils to work towards this behavior, but it
needs a lot of work. People who are interested in this should work on it.
(yum-basearchonly).
I am now just starting to administer x86_64 arch boxen and not finding
much info (or rather a lot of very sparce info) after Googling around
on what the pros and cons are of having a "pure" x86_64 system vs.
installing a mix with i?86 packages. So while yum is blameless here, I
thought that the package obsoletes were the bug here. Or is the only
con here wasted disk space?
/Mike
3:48 a.m.
On Sat, 2007-09-22 at 19:44 -0400, seth vidal wrote:
On Sat, 2007-09-22 at 19:42 -0400, Michael Wiktowy wrote:
> On 9/22/07, seth vidal <skvidal(a)fedoraproject.org> wrote:
> > If you want to avoid this behavior in the future add: exclude=*.?86 to
> > your yum.conf.
That doesn't work when you want _some_ i386 packages which you specify
explicitly. Or on ppc64/sparc64 where you do want the 64-bit kernel but
all userspace can be 32-bit. It's just a fairly dodgy workaround.
> Is this something that anaconda should add to all x86_64
installations
> or is this just a workaround that might hide bugs and prevent Steve
> from being the canary in the coal mine?
There isn't a bug here.Yum is doing exactly what it says to do.
"it says to do"? I'm not quite sure of your meaning there -- I think
you're really saying "yum is doing exactly what yum does". Which is
true, but not really relevant.
I consider yum's behaviour buggy, as do many others. Arguing over
whether to call bug #235756 a bug or an RFE doesn't really buy us
anything. It's just bug #235756. All bug reports are really requests for
enhancement at some level, aren't they?
If I say 'yum install foo', I just want _one_ version of foo installed
-- the 32-bit PPC version that I actually intend to use.
I don't want a pointless 64-bit version installed, and I don't want an
i386 version installed for qemu to use under /usr/qemu-i386 either. If I
want those, I'll ask for them.
Neither do I want yum to search for ssh sessions where I am logged in as
root to other boxes, and install 'foo' there too.
Although 'install foo' is, when you think about it, a fairly vague
command and can be wilfully misinterpreted to mean any of the above, it
really _ought_ to be interpreted with a little bit of common sense. By
doing _any_ but the first of the operations above, yum would be
exceeding its mandate; doing something I didn't _really_ ask it to do.
It's supposed to be a useful piece of software, for $DEITY's sake -- not
a genie in a bottle trying to distort my wishes.
It would be really nice if we had a proper fix for this misbehaviour
before F8.
--
dwmw2
6:15 a.m.
On Sun, 23 Sep 2007 09:48:32 +0100
David Woodhouse <dwmw2(a)infradead.org> wrote:
"it says to do"? I'm not quite sure of your meaning
there -- I think
you're really saying "yum is doing exactly what yum does". Which is
true, but not really relevant.
Yum is doing what Fedora has asked for a multilib strategy all the way
up to Fedora 8. No matter how much you bitch whine moan complain call
things bugs whatever doesn't change the fact that we have a current
strategy for multilib and yum is following that strategy. When the
strategy changes, yum will change to. If yum were acting out of spec
with that strategy then that would be a bug. Please stop accusing
software of doing what the project is asking of it.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
11:30 a.m.
On Sun, 2007-09-23 at 07:15 -0400, Jesse Keating wrote:
Yum is doing what Fedora has asked for a multilib strategy all the
way
up to Fedora 8.
That strategy is, quite simply, wrong. In all other cases we call an
implementation of such a misguided strategy a 'bug'. If you want me to
call it a 'fish' in this case, then by all means I'll do so.
If you can make this URL work, all the better:
https://fishzilla.redhat.com/showdependencytree.cgi?id=multilib
:)
--
dwmw2
2:28 p.m.
On Sunday 23 September 2007, David Woodhouse wrote:
On Sun, 2007-09-23 at 07:15 -0400, Jesse Keating wrote:
> Yum is doing what Fedora has asked for a multilib strategy all the way
> up to Fedora 8.
That strategy is, quite simply, wrong. In all other cases we call an
implementation of such a misguided strategy a 'bug'.
I tend to agree. Is the strategy documented somewhere so one can educate
oneself and verify that this indeed is the desired behaviour that follows
from it? I'm having hard time coming up with any arguments that would
support the way things currently work, but would be interested in finding out
if I've missed something.
3:28 p.m.
On Sun, Sep 23, 2007 at 10:28:34PM +0300, Ville Skyttä wrote:
On Sunday 23 September 2007, David Woodhouse wrote:
> That strategy is, quite simply, wrong. In all other cases we
call an
> implementation of such a misguided strategy a 'bug'.
I tend to agree. Is the strategy documented somewhere so one can educate
oneself and verify that this indeed is the desired behaviour that follows
from it? I'm having hard time coming up with any arguments that would
support the way things currently work, but would be interested in finding out
if I've missed something.
Also, thy explanation that yum exactly does what the intended strategy
for Fedora is, is not very satisfying... Yum should ideally implement
various strategies (maybe via plugins), and Fedora can then be configured
by default for "the intended strategy". If Fedora changes strategies,
there should be no need to adapt the software (only its configuration).
People wanting to use other strategies (a few have already passed in
this thread) should be able to do so.
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
6:17 a.m.
On Sun, 23 Sep 2007 22:28:35 +0200
Jos Vos <jos(a)xos.nl> wrote:
Also, thy explanation that yum exactly does what the intended
strategy
for Fedora is, is not very satisfying... Yum should ideally implement
various strategies (maybe via plugins), and Fedora can then be
configured by default for "the intended strategy". If Fedora changes
strategies, there should be no need to adapt the software (only its
configuration).
People wanting to use other strategies (a few have already passed in
this thread) should be able to do so.
This is the plan for Fedora 9.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
6:23 a.m.
On Sun, 23 Sep 2007 22:28:34 +0300
"Ville Skyttä" <ville.skytta(a)iki.fi> wrote:
I tend to agree. Is the strategy documented somewhere so one can
educate oneself and verify that this indeed is the desired behaviour
that follows from it? I'm having hard time coming up with any
arguments that would support the way things currently work, but would
be interested in finding out if I've missed something.
Jeremy was working on documenting it. It is a strategy that has been
developed over a period of releases that offered multilib.
Quite simply, we want both runtime library and development package
availability of the secondary arch installed by default. To accomplish
this we use the existence of a -devel subpackage to trigger selection
as a multilib package. We then require the package that holds the
symlink destination of any .so files in the -devel subpackage. We then
depsolve that to make sure all the secondary arch deps are resolved.
There are a few more things going on, a few whitelists, a bare minimum
blacklist.
http://git.fedoraproject.org/?p=hosted/mash;a=blob_plain;f=mash/multilib.... has
the gory details. This is the method by which we select which packages are multilib
(finally a programatic way instead of a hand generated list we had before). The second
part of the strategy was that tools like yum will install the available packages by
default if simply asked to 'install foo' and "foo" wasn't arch
specified.
Yes, some of us would like to change this around a bit in Fedora 9, by
making it configurable client side which strategy to follow, and to
determine at install time which compat arch packages to pull in based
on configured strategy. This would eliminate the need to pre-populate
the repos with secondary arch content at compose time.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
8:26 a.m.
On Mon, 2007-09-24 at 07:23 -0400, Jesse Keating wrote:
Quite simply, we want both runtime library and development package
availability of the secondary arch installed by default.
We missed a step here. Why on earth would we want this? Users _don't_
seem to want this.
As far as I can tell, the only time this is useful is to work around the
fact that RPM dependencies aren't arch-specific.
That is: at the moment, if I want to build foo.i386 and it says
'BuildRequires: bar-devel', that requirement will be 'satisfied' by the
existence of bar-devel.x86_64. And my 'foo' package won't actually
build. That's also on the multilib tracker bug, btw -- bug #235755.
With RPM fixed so that Requires and BuildRequires can actually pull in
the package which is _needed_, I don't see any benefit of having all the
secondary-arch stuff installed by default.
When you install Skype.i386.rpm on an x86_64 box, the dependencies will
work and you'll get the libraries you want.
When you want to build evolution.i386 on an x86_64 box, you'll probably
have to install a bunch of xxx-devel.i386 packages -- but that's fine.
Unless we're going to have a policy of "install _every_ -devel package
in every available flavour", you're often going to have to install a few
packages to satisfy dependencies. There's no problem with that.
With RPM bugs out of the way, there just isn't a viable reason for
wanting all the secondary-arch stuff installed by default.
I could see an argument for the "install everything" case -- you have
infinite disk space and you don't ever want to have to manually install
something for dependencies, and you want to use software which isn't
RPM-packaged. But "install everything which for the secondary arch which
happens to be installed for the primary" is just weird.
--
dwmw2
8:48 a.m.
On Monday 24 September 2007 09:26:01 David Woodhouse wrote:
> Quite simply, we want both runtime library and development
package
> availability of the secondary arch installed by default.
We missed a step here. Why on earth would we want this? Users _don't_
seem to want this.
+1
I can't see why anyone would want this. 2 years ago when open office was not
64 bit safe and several other high profile apps were still working out the 64
bit issues, I could see why we wanted this. Its different today. The fact is
that we cause people to download way more updates for libraries that are
completely unneeded. It affects people doing the mirroring, ISP's having
bandwidth consumed, and users that have issues related to failed updates
causing mismatching versions of 32 and 64 bit packages (with no good way to
fix it) and less available diskspace.
If you are a developer and *want* the ability to do cross compiling, then I
could see those people wanting multilib. I think the common case is people
want a pure 64 or 32 bit machine so they have more free diskspace and quicker
updates and less hassle when it goes wrong.
-Steve
8:52 a.m.
On Mon, 2007-09-24 at 09:48 -0400, Steve Grubb wrote:
If you are a developer and *want* the ability to do cross
compiling,
then I could see those people wanting multilib.
Note that we're not talking about "multilib or not". We're talking
about
whether to install a bunch of packages for the secondary architecture by
_default_.
If you want to build a package (other than in mock), then you have to
install its dependencies -- a bunch of -devel packages.
Would you expect those packages to be installed for you automatically,
just in _case_ you need them? That's the kind of thinking that leads to
wanting an 'Everything' install, isn't it?
--
dwmw2
9:47 a.m.
On Monday, 24 September 2007 at 15:52, David Woodhouse wrote:
On Mon, 2007-09-24 at 09:48 -0400, Steve Grubb wrote:
> If you are a developer and *want* the ability to do cross compiling,
> then I could see those people wanting multilib.
Note that we're not talking about "multilib or not". We're talking
about
whether to install a bunch of packages for the secondary architecture by
_default_.
If you want to build a package (other than in mock), then you have to
install its dependencies -- a bunch of -devel packages.
Would you expect those packages to be installed for you automatically,
just in _case_ you need them? That's the kind of thinking that leads to
wanting an 'Everything' install, isn't it?
Indeed. +1 to turning this off by default. In fact, +1 to installing
only 64bit packages on x86_64 install (while keeping the i386 versions
in the repository, of course).
Regards,
R.
--
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
9:54 a.m.
Once upon a time, Dominik 'Rathann' Mierzejewski <dominik(a)greysector.net>
said:
Indeed. +1 to turning this off by default. In fact, +1 to installing
only 64bit packages on x86_64 install (while keeping the i386 versions
in the repository, of course).
Why keep the i386 versions in the repo? It would be better to write
down the rules that are used to pull i386 packages into the x86_64 repo
and then make a yum plugin that can point to the i386 repo and follow
the rules (when enabled).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
10:20 a.m.
On Mon, 2007-09-24 at 09:54 -0500, Chris Adams wrote:
Why keep the i386 versions in the repo? It would be better to write
down the rules that are used to pull i386 packages into the x86_64
repo and then make a yum plugin that can point to the i386 repo and
follow the rules (when enabled).
There's a lot of sense in this. One of the options being discussed is to
ship _nothing_ of the secondary arch (or almost nothing) in the primary
repository, and allow yum to be pointed at the basic i386 repo.
Of course, that means we've suddenly got a whole load of i386 packages
visible to x86_64 yum which weren't there before; with the current
install-both behaviour that wouldn't work too well. But as part of a
more coherent approach, I think it's the way forward.
Note that for some 64-bit architectures like sparc64/ppc64 we run mostly
32-bit userspace, because 64-bit userspace just isn't worth the bloat
(the only reason it's worth the bloat for x86 is because you actually
get a sane number of _registers_ that way). So the 32-bit tree would
probably still carry a _few_ 64-bit packages there (kernel, gdb,
systemtap, etc.).
--
dwmw2
10:59 a.m.
On Mon, 2007-09-24 at 16:20 +0100, David Woodhouse wrote:
On Mon, 2007-09-24 at 09:54 -0500, Chris Adams wrote:
> Why keep the i386 versions in the repo? It would be better to write
> down the rules that are used to pull i386 packages into the x86_64
> repo and then make a yum plugin that can point to the i386 repo and
> follow the rules (when enabled).
There's a lot of sense in this. One of the options being discussed is to
ship _nothing_ of the secondary arch (or almost nothing) in the primary
repository, and allow yum to be pointed at the basic i386 repo.
One problem with this is that many arch-specific packages contain 1)
arch-neutral resources in them (like documentation, data files and
arch-neutral scripts) and 2) some binaries in /usr/bin that collide with
each other. Ideally, a solution like that would allow installing of
packages from any arbitrary architecture (say, ppc and i386) without
there every being any collisions. Unfortunately, neither the
alternatives system nor FHS supports multi-arch installs.
Even the current i386-x86_64 installs aren't perfect. The library
separation and linking works alright, but the executable programs
in /usr/bin don't (e.g. /usr/bin/soundstretch installed in both
soundtouch.x86_64 and soundtouch.i386 is x86_64 only).
Does anyone see /usr/(bin|lib).(i386|i686|x86_64|ppc|ppc64) in the
future? :-)
--
Richi Plana
1:08 p.m.
On Monday, 24 September 2007 at 17:59, Richi Plana wrote:
[...]
Even the current i386-x86_64 installs aren't perfect. The
library
separation and linking works alright, but the executable programs
in /usr/bin don't (e.g. /usr/bin/soundstretch installed in both
soundtouch.x86_64 and soundtouch.i386 is x86_64 only).
Then the libs need to be moved to a separate package, but the fact that
64bit binaries silently overwrite 32bit ones on x86_64 is a feature,
not a bug.
Does anyone see /usr/(bin|lib).(i386|i686|x86_64|ppc|ppc64) in the
future? :-)
Let's just NOT go there again, please.
Regards,
R.
--
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:09 p.m.
On Mon, 2007-09-24 at 09:59 -0600, Richi Plana wrote:
On Mon, 2007-09-24 at 16:20 +0100, David Woodhouse wrote:
> On Mon, 2007-09-24 at 09:54 -0500, Chris Adams wrote:
> > Why keep the i386 versions in the repo? It would be better to write
> > down the rules that are used to pull i386 packages into the x86_64
> > repo and then make a yum plugin that can point to the i386 repo and
> > follow the rules (when enabled).
>
> There's a lot of sense in this. One of the options being discussed is to
> ship _nothing_ of the secondary arch (or almost nothing) in the primary
> repository, and allow yum to be pointed at the basic i386 repo.
One problem with this is that many arch-specific packages contain 1)
arch-neutral resources in them (like documentation, data files and
arch-neutral scripts) and 2) some binaries in /usr/bin that collide with
each other. Ideally, a solution like that would allow installing of
packages from any arbitrary architecture (say, ppc and i386) without
there every being any collisions. Unfortunately, neither the
alternatives system nor FHS supports multi-arch installs.
That's kind of an orthogonal point -- yes, it's an issue with our
existing multilib setup, but it's not directly related to the question
at hand, of which packages should be installed by default for the
secondary arch and how they should get there. And it's made neither
better nor worse by what Chris proposed.
It's also something which is partially addressed by something on the
multilib tracker bug. Have you looked at that?
Even the current i386-x86_64 installs aren't perfect. The
library
separation and linking works alright, but the executable programs
in /usr/bin don't (e.g. /usr/bin/soundstretch installed in both
soundtouch.x86_64 and soundtouch.i386 is x86_64 only).
This is bug #235757 (ignore the temporary bit for F7 to prefer 32-bit).
Does anyone see /usr/(bin|lib).(i386|i686|x86_64|ppc|ppc64) in the
future? :-)
No. :)
--
dwmw2
11:08 a.m.
Steve Grubb wrote:
If you are a developer and *want* the ability to do cross compiling,
then I
could see those people wanting multilib. I think the common case is people
want a pure 64 or 32 bit machine so they have more free diskspace and quicker
updates and less hassle when it goes wrong.
-1
no if someone wants a pure 64 bit system he should have a option to do
that. multilib is not a bad thing but it just lets you install and run
32bit apps on your 64bit system.
please don't go down to no multilib and start using chroot hacks...
thats WRONG ...
the only thing that needs to be fixed here is dont install both archs
when somebody wants to install an app.
yum install foo -> install the default arch only
yum install foo.i386 install foo.i386 and its deps (may also be 32 bit
or noarch).
11:11 a.m.
On Mon, 2007-09-24 at 18:08 +0200, dragoran wrote:
no if someone wants a pure 64 bit system he should have a option to
do
that. multilib is not a bad thing but it just lets you install and run
32bit apps on your 64bit system.
please don't go down to no multilib and start using chroot hacks...
I don't think anybody is suggesting that we ditch multilib altogether.
We are suggesting only that the i386 packages should not be installed by
_default_ -- they should be installed only when they're actually needed.
--
dwmw2
11:32 a.m.
David Woodhouse wrote:
On Mon, 2007-09-24 at 18:08 +0200, dragoran wrote:
> no if someone wants a pure 64 bit system he should have a option to do
> that. multilib is not a bad thing but it just lets you install and run
> 32bit apps on your 64bit system.
> please don't go down to no multilib and start using chroot hacks...
>
I don't think anybody is suggesting that we ditch multilib altogether.
We are suggesting only that the i386 packages should not be installed by
_default_ -- they should be installed only when they're actually needed.
I don't disagree with you on that ;)
but as I said I am against killing multilib.
2:03 p.m.
On Mon, 2007-09-24 at 18:32 +0200, dragoran wrote:
I don't disagree with you on that ;)
but as I said I am against killing multilib.
That's fine, but in that case I refer you to mailing list etiquette --
if you want to start a thread on a completely separate topic, please
don't do it by replying to this thread.
--
dwmw2
11:34 a.m.
On Mon, 2007-09-24 at 18:08 +0200, dragoran wrote:
Steve Grubb wrote:
> If you are a developer and *want* the ability to do cross compiling, then I
> could see those people wanting multilib. I think the common case is people
> want a pure 64 or 32 bit machine so they have more free diskspace and quicker
> updates and less hassle when it goes wrong.
>
-1
no if someone wants a pure 64 bit system he should have a option to do
that. multilib is not a bad thing but it just lets you install and run
32bit apps on your 64bit system.
please don't go down to no multilib and start using chroot hacks...
thats WRONG ...
THAT'S the kind of thinking I like! Where people don't bash other
people's preferences but instead leave them options. It's good for a
distro like Fedora to choose one default since it simplifies things for
the majority of people, but care should be taken to leave things open
for other options and, at times, to even aid in the selection of other
options. Sometimes it's just so easy to fall into the exclusive
way-of-thinking, particularly when either a personal preference is
perceived to be threatened or if there's pressure to get something out
and the easy choice seems so attractive.
the only thing that needs to be fixed here is dont install both archs
when somebody wants to install an app.
yum install foo -> install the default arch only
yum install foo.i386 install foo.i386 and its deps (may also be 32 bit
or noarch).
Agree with there being a "default" during install and when no arch is
specified, but read my previous post on existing problems with
multi-arch installs.
Besides ... going back to i386-x86_64 installs specifically ... I think
it has always been the idea to eventually drop the default install of
i386 packages. Having them there would just ease transitions ...
particularly with many i386, binary-only packages. At least that was my
impression. After having used Fedora x86_64 for the last year or so, I
can say that I can live with just an x86_64-install only and add
packages when needed (nspluginwrapper and maybe SDL libstdc++ for some
games for me).
--
Richi Plana
6:24 a.m.
On Sun, 23 Sep 2007 17:30:05 +0100
David Woodhouse <dwmw2(a)infradead.org> wrote:
That strategy is, quite simply, wrong.
Then work to fix the strategy, don't shoot the tools for following the
requested script. Dropping snide comments about them doesn't make
anybody any more eager to listen to you.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
8:21 a.m.
On Mon, 2007-09-24 at 07:24 -0400, Jesse Keating wrote:
Then work to fix the strategy, don't shoot the tools for
following the
requested script.
But there is no actual script -- the only place this is written down is
in yum's implementation. Hence wanting it fixed in yum's implementation.
Dropping snide comments about them doesn't make anybody any more
eager
to listen to you.
You make it sound like I'm not actively working on a strategy for
improving multilib, despite the existence of
http://bugzilla.redhat.com/showdependencytree.cgi?id=multilib and the
(minor) progress we've already made on it.
--
dwmw2
8:35 a.m.
On Mon, 24 Sep 2007 14:21:08 +0100
David Woodhouse <dwmw2(a)infradead.org> wrote:
But there is no actual script -- the only place this is written down
is in yum's implementation. Hence wanting it fixed in yum's
implementation.
It's also in mash, and in pungi. It may not be "written down"
anywhere, but it is a script that we're all playing by.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
8:41 a.m.
On Mon, 2007-09-24 at 09:35 -0400, Jesse Keating wrote:
On Mon, 24 Sep 2007 14:21:08 +0100
David Woodhouse <dwmw2(a)infradead.org> wrote:
> But there is no actual script -- the only place this is written down
> is in yum's implementation. Hence wanting it fixed in yum's
> implementation.
It's also in mash, and in pungi.
The multilib tracker bug has RFEs for that too.
It may not be "written down" anywhere, but it is a script
that we're
all playing by.
OK, so how do we fix it? I _thought_ that the best option was what I'd
already done -- file individual enhancement requests as part of a
coherent plan to get us to a better place. But you don't like those. So
what now?
--
dwmw2
8:51 a.m.
On Mon, 24 Sep 2007 14:41:12 +0100
David Woodhouse <dwmw2(a)infradead.org> wrote:
OK, so how do we fix it? I _thought_ that the best option was what
I'd
already done -- file individual enhancement requests as part of a
coherent plan to get us to a better place. But you don't like those.
So what now?
I've been planning for some time now a get together of sorts in person
to hash this out. The basic idea I'm thinking of is a runtime
configuration in yum that lets you adhere to whatever multilib strategy
you want on that particular system. You point at both full repos and
let yum figure out, based on requested strategy, what to do on
install/update/obsolete/whatever actions. Composing exploaded repos is
easy, no cross pollination. Composing DVDs is easy (but bloaty) you
just put both repos in whole on the media (or opt out of the secondary
arch all together on the media).
My plan for the get together is to hash out what each of these
strategies are, get out and understood why we're at where we are at
today (I'm told time and time again that there are real good
reasons...), determine the best default strategy going forward, and
work out what happens when users do silly things like change strategies
mid stream or whatever.
I wanted to do this near the time that F9 development starts, unknown
if it will happen or not.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
9:25 a.m.
On Mon, 2007-09-24 at 09:51 -0400, Jesse Keating wrote:
On Mon, 24 Sep 2007 14:41:12 +0100
David Woodhouse <dwmw2(a)infradead.org> wrote:
> OK, so how do we fix it? I _thought_ that the best option was what I'd
> already done -- file individual enhancement requests as part of a
> coherent plan to get us to a better place. But you don't like those.
> So what now?
I've been planning for some time now a get together of sorts in person
to hash this out. The basic idea I'm thinking of is a runtime
configuration in yum that lets you adhere to whatever multilib strategy
you want on that particular system. You point at both full repos and
let yum figure out, based on requested strategy, what to do on
install/update/obsolete/whatever actions. Composing exploaded repos is
easy, no cross pollination. Composing DVDs is easy (but bloaty) you
just put both repos in whole on the media (or opt out of the secondary
arch all together on the media).
My plan for the get together is to hash out what each of these
strategies are, get out and understood why we're at where we are at
today (I'm told time and time again that there are real good
reasons...),
There are reasons, certainly. I'm not sure all of them are _good_
reasons :)
One of the reasons I see for the 'install both' strategy is the lack of
arch-specific dependencies in RPM.
I tried building evolution.ppc64 recently, having purged my system of
all ppc64 userspace. It was not fun, because the BuildRequires were all
satisfied by the existence of the 32-bit packages, which weren't
actually what was needed. But as I said, there's a bug on the tracker
for that one too. "Just Install Everything" isn't really a good
workaround, although it does work.
I wanted to do this near the time that F9 development starts,
unknown
if it will happen or not.
Who do we need that isn't based around Boston? I seem to spend half my
life on planes at the moment, and come through Boston relatively
frequently. Should I just try to give you a bit of warning each time I
fly in, to see if we can all find some time?
I should probably be out there next week or so, hopefully.
--
dwmw2
9:30 a.m.
On Mon, 24 Sep 2007 15:25:34 +0100
David Woodhouse <dwmw2(a)infradead.org> wrote:
Who do we need that isn't based around Boston? I seem to spend
half my
life on planes at the moment, and come through Boston relatively
frequently. Should I just try to give you a bit of warning each time I
fly in, to see if we can all find some time?
Seth Vidal and Bill Nottingham at least.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
9:45 a.m.
On Mon, 2007-09-24 at 10:30 -0400, Jesse Keating wrote:
On Mon, 24 Sep 2007 15:25:34 +0100
David Woodhouse <dwmw2(a)infradead.org> wrote:
> Who do we need that isn't based around Boston? I seem to spend half my
> life on planes at the moment, and come through Boston relatively
> frequently. Should I just try to give you a bit of warning each time I
> fly in, to see if we can all find some time?
Seth Vidal and Bill Nottingham at least.
Ah, of course. Sorry -- I keep forgetting that not _everyone_ has been
sucked into the Westford black hole yet :)
--
dwmw2
10:19 a.m.
Jesse Keating wrote:
On Sun, 23 Sep 2007 17:30:05 +0100
David Woodhouse <dwmw2(a)infradead.org> wrote:
> That strategy is, quite simply, wrong.
Then work to fix the strategy, don't shoot the tools for following the
requested script. Dropping snide comments about them doesn't make
anybody any more eager to listen to you.
The point is that in fact yum is the problem (not the only one). Yum - as an
updating tool - should honor the user's previously made decisions as much as
possible. To be able to do that on a multilib system yum needs to take arch
into account for more or less every decision (especially the arch of the
already installed packages). As yum didn't do that in the past introducing
multilib would have required to rewrite all package selection code within
yum (and some other parts of the tool chain). Instead people came up with
the "install everything" policy with the hope this would hide most problems
of the non multilib aware tools. As we all known this only works for the
simplest cases - not to mention all the other drawbacks that come up on this
list every week (as in this thread).
So it is not about changing the "default policy" but about having a sane
behavior in our tools that do not depend on any policy but just work [1].
When it comes to that current case: This is an bug! Obsoletes have to be
seen as updates which additionally involve a name change. Yes, obsoletes do
not have an arch assosiated with them - as updates also do not. The updating
tool (yum) has to decide what updates/obsoleting packages to install. And of
course it has to take the archs of the already installed packages into
account. No one would suggest to update foo-1-1.i368 to foo-2-1.i386 and
foo-2-1.x86_64 although both have higher version numbers and the names also
match. The same logic applies to obsoletes.
Florian
[1] tbh: some of the most hurting cases have been fixed in yum but large
parts of the code are still arch agnostic.
10:23 a.m.
On Tue, 2007-09-25 at 17:19 +0200, Florian Festi wrote:
Jesse Keating wrote:
> On Sun, 23 Sep 2007 17:30:05 +0100
> David Woodhouse <dwmw2(a)infradead.org> wrote:
>
>> That strategy is, quite simply, wrong.
>
> Then work to fix the strategy, don't shoot the tools for following the
> requested script. Dropping snide comments about them doesn't make
> anybody any more eager to listen to you.
The point is that in fact yum is the problem (not the only one). Yum - as an
updating tool - should honor the user's previously made decisions as much as
possible. To be able to do that on a multilib system yum needs to take arch
into account for more or less every decision (especially the arch of the
already installed packages). As yum didn't do that in the past introducing
multilib would have required to rewrite all package selection code within
yum (and some other parts of the tool chain). Instead people came up with
the "install everything" policy with the hope this would hide most problems
of the non multilib aware tools. As we all known this only works for the
simplest cases - not to mention all the other drawbacks that come up on this
list every week (as in this thread).
Umm, you have it backward. When I was originally writing in the multilib
support I asked how it should be done and was told, at the time, by
Jeremy that it should install both of them b/c that's what users would
want/expect. At least, that's what I vaguely recall. This has been about
3 years, now.
So it is not about changing the "default policy" but about having a sane
behavior in our tools that do not depend on any policy but just work [1].
Wrong. It's about the policy.
-sv
4:24 p.m.
seth vidal <skvidal(a)fedoraproject.org> writes:
Umm, you have it backward. When I was originally writing in the
multilib
support I asked how it should be done and was told, at the time, by
Jeremy that it should install both of them b/c that's what users would
want/expect. At least, that's what I vaguely recall. This has been about
3 years, now.
Well, I think it was like that 3 years ago.
Now it seems users want x86_64 only, they don't want i386-devel,
they maybe want i386 Firefox (can the Flash be used with some 32->64
wrapper?) and a couple of other things (32-bit gcc code generation,
if the respective optional 32-bit libs are installed).
Yes, some users need all i386 they can have (such as devel).
I fully agree it would be great if we had _no_ i386 packages in
x86_64, and if the right way to get 32-bit packages was just pointing
yum etc. to the 32-bit repository.
Wrong. It's about the policy.
Ok, then the policy should be fixed.
--
Krzysztof Halasa
4:29 p.m.
On Tuesday, 25 September 2007 at 23:24, Krzysztof Halasa wrote:
seth vidal <skvidal(a)fedoraproject.org> writes:
> Umm, you have it backward. When I was originally writing in the multilib
> support I asked how it should be done and was told, at the time, by
> Jeremy that it should install both of them b/c that's what users would
> want/expect. At least, that's what I vaguely recall. This has been about
> 3 years, now.
Well, I think it was like that 3 years ago.
Now it seems users want x86_64 only, they don't want i386-devel,
they maybe want i386 Firefox (can the Flash be used with some 32->64
wrapper?)
nspluginwrapper works quite well.
Regards,
R.
--
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
4:03 a.m.
tir, 25 09 2007 kl. 23:29 +0200, skrev Dominik 'Rathann' Mierzejewski:
On Tuesday, 25 September 2007 at 23:24, Krzysztof Halasa wrote:
> seth vidal <skvidal(a)fedoraproject.org> writes:
>
> > Umm, you have it backward. When I was originally writing in the multilib
> > support I asked how it should be done and was told, at the time, by
> > Jeremy that it should install both of them b/c that's what users would
> > want/expect. At least, that's what I vaguely recall. This has been about
> > 3 years, now.
>
> Well, I think it was like that 3 years ago.
>
> Now it seems users want x86_64 only, they don't want i386-devel,
> they maybe want i386 Firefox (can the Flash be used with some 32->64
> wrapper?)
nspluginwrapper works quite well.
I've never personally had any kind of success with it
- David
5:14 a.m.
On Wed, 2007-09-26 at 11:03 +0200, David Nielsen wrote:
tir, 25 09 2007 kl. 23:29 +0200, skrev Dominik 'Rathann'
Mierzejewski:
> nspluginwrapper works quite well.
I've never personally had any kind of success with it
Really? At one point (with a bit of qemu hacking) I even had the i386
flash plugin running with nspluginwrapper+qemu-i386 in my PowerPC
firefox. I wouldn't _recommend_ it, and there was a bit more
thread-related qemu hacking to be done before it worked _well_, but it
was definitely working.
--
dwmw2
2:44 p.m.
ons, 26 09 2007 kl. 11:14 +0100, skrev David Woodhouse:
On Wed, 2007-09-26 at 11:03 +0200, David Nielsen wrote:
> tir, 25 09 2007 kl. 23:29 +0200, skrev Dominik 'Rathann' Mierzejewski:
> > nspluginwrapper works quite well.
>
> I've never personally had any kind of success with it
Really? At one point (with a bit of qemu hacking) I even had the i386
flash plugin running with nspluginwrapper+qemu-i386 in my PowerPC
firefox. I wouldn't _recommend_ it, and there was a bit more
thread-related qemu hacking to be done before it worked _well_, but it
was definitely working.
Ah it turns out that nspluginwrapper does not work when you are using
Epiphany, even if they are using the same gecko backend.
So I have the option of using gnash and my favorite browser or be forced
to use Firefox (which I loath) and then have the option of using the
official flash plugin. Gnash fortunately has been quite good to me, sure
once in a while I have to reload a youtube page to get the videos
playing and it doesn't really support anywhere near the full range of
flash sites but it's shaping up very nicely.
- David
6:13 a.m.
On Wed, 26 Sep 2007 11:03:14 +0200
David Nielsen <david(a)lovesunix.net> wrote:
I've never personally had any kind of success with it
I'm happily using nspluginwrapper.i386 + adobe flash to be able to view
flash things in my x86_64 browser. Of course this will be made moot
when gnash starts working better (:
--
Jesse Keating
Fedora -- All my bits are free, are yours?
6:47 a.m.
On Wed, 2007-09-26 at 07:13 -0400, Jesse Keating wrote:
I'm happily using nspluginwrapper.i386 + adobe flash to be able
to
view flash things in my x86_64 browser. Of course this will be made
moot when gnash starts working better (:
To be fair, hnash in rawhide _is_ a lot better... although perhaps still
not 'good'. At least I'm kind of getting out of the habit of just typing
'killall -9 gnash' whenever X or the system starts crawling.
--
dwmw2
7:12 a.m.
On Wed, 26 Sep 2007 12:47:11 +0100
David Woodhouse <dwmw2(a)infradead.org> wrote:
To be fair, hnash in rawhide _is_ a lot better... although perhaps
still not 'good'. At least I'm kind of getting out of the habit of
just typing 'killall -9 gnash' whenever X or the system starts
crawling.
Last time I tried it in rawhide it kept booting me right out of X :/
--
Jesse Keating
Fedora -- All my bits are free, are yours?
8:15 p.m.
On Tue, 2007-09-25 at 23:24 +0200, Krzysztof Halasa wrote:
seth vidal <skvidal(a)fedoraproject.org> writes:
> Umm, you have it backward. When I was originally writing in the multilib
> support I asked how it should be done and was told, at the time, by
> Jeremy that it should install both of them b/c that's what users would
> want/expect. At least, that's what I vaguely recall. This has been about
> 3 years, now.
Well, I think it was like that 3 years ago.
Now it seems users want x86_64 only, they don't want i386-devel,
they maybe want i386 Firefox (can the Flash be used with some 32->64
wrapper?) and a couple of other things (32-bit gcc code generation,
if the respective optional 32-bit libs are installed).
Yes, some users need all i386 they can have (such as devel).
I fully agree it would be great if we had _no_ i386 packages in
x86_64, and if the right way to get 32-bit packages was just pointing
yum etc. to the 32-bit repository.
> Wrong. It's about the policy.
Ok, then the policy should be fixed.
Right - which is what Jesse is trying to get organized. A meeting, a
whiteboard, a plan.
-sv
4 a.m.
On Sunday 23 September 2007, seth vidal wrote:
On Sat, 2007-09-22 at 19:42 -0400, Michael Wiktowy wrote:
> On 9/22/07, seth vidal <skvidal(a)fedoraproject.org> wrote:
> > If you want to avoid this behavior in the future add: exclude=*.?86 to
> > your yum.conf.
>
> Is this something that anaconda should add to all x86_64 installations
> or is this just a workaround that might hide bugs and prevent Steve
> from being the canary in the coal mine?
There isn't a bug here.Yum is doing exactly what it says to do. If steve
wants an x86_64-pure system then in order to avoid obsoletes coming in
like this he needs to add an exclude.
I don't think it's an acceptable solution for the very common case where you
want some ix86 packages on an x86_64 system. FWIW, smart seems to do the
right thing out of the box (which is one of the few remaining reasons I
personally still prefer it over yum).
8:55 p.m.
On Saturday 22 September 2007 19:33:30 seth vidal wrote:
If you want to avoid this behavior in the future add: exclude=*.?86
to
your yum.conf.
Doesn't "yum update" mean update the packages I have installed? I do not
have
i386 packages installed. No packages selected REQUIRES 32 bit only packages.
Typing "yum update NetworkManager" selected only x64_64 packages even though
I didn't specify an architecture. Why can't "yum update" follow the same
behavior? Why does the obsolete cause it to decide to pull in 32 bit
packages? If I do the delete, "yum update" changes behavior and only selects
64 bit packages. Something is wrong here.
I also have the exactarch=1. If that doesn't mean x86_64, what does it mean?
-Steve
9:35 p.m.
On Sat, 2007-09-22 at 21:55 -0400, Steve Grubb wrote:
On Saturday 22 September 2007 19:33:30 seth vidal wrote:
> If you want to avoid this behavior in the future add: exclude=*.?86 to
> your yum.conf.
Doesn't "yum update" mean update the packages I have installed? I do not
have
i386 packages installed. No packages selected REQUIRES 32 bit only packages.
Typing "yum update NetworkManager" selected only x64_64 packages even though
I didn't specify an architecture. Why can't "yum update" follow the
same
behavior? Why does the obsolete cause it to decide to pull in 32 bit
packages? If I do the delete, "yum update" changes behavior and only selects
64 bit packages. Something is wrong here.
I also have the exactarch=1. If that doesn't mean x86_64, what does it mean?
obsoletes are allowed to cross arch boundaries. In fact, there's no way
to specify otherwise in an rpm
-sv
7:48 a.m.
On Sat, Sep 22, 2007 at 10:35:03PM -0400, seth vidal wrote:
obsoletes are allowed to cross arch boundaries. In fact, there's
no way
to specify otherwise in an rpm
Hmmm. In other cases where two packages obsolete one installed one, do they
both get installed, or is there some "best fit" attempt?
Conversely, if a package of one arch tries to obsolete a package which
previously had two archs installed, are they both cleaned up? (In previous
versions of yum, I believe only the one matching the new package was
removed. Haven't tested recently.)
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
10:14 a.m.
On Sat, 2007-09-22 at 09:44 -0400, Steve Grubb wrote:
Hi,
This morning I checked rawhide. My x86_64 machine has no 386 packages on it.
Doing yum update suddenly wanted to pull in 386 packages to my system. I
updated packages 1 by 1 until I was down to updating NetworkManager.x86_64.
If I type "yum update NetworkManager.x86_64" or "yum update
NetworkManager",
I get only 64 bit packages. If I type "yum update", it pulls in the 386
version of NetworkManager and all its dependencies.
So, those of you with pristine 64 bit machines, watch out for this or 32 bit
packages will start creeping back into your system. Is this a known problem
or should a bz be filed?
Hm, how did you get a pristine 64-bit machine? Did bug #235756 get
fixed?
--
dwmw2
11:14 a.m.
On Saturday 22 September 2007 11:14:02 David Woodhouse wrote:
> So, those of you with pristine 64 bit machines, watch out for
this or 32
> bit packages will start creeping back into your system. Is this a known
> problem or should a bz be filed?
Hm, how did you get a pristine 64-bit machine?
One day a couple months ago, I noticed I was about to download > 100 Mb of
packages that I would never use (I think it was all the 386 kde packages), so
I did a yum remove of every 386 or 686 package I could find. Doing "yum
update" has not pulled any 386 packages back in until today.
Did bug #235756 get fixed?
no idea....
-Steve
11:40 a.m.
On Sat, 2007-09-22 at 12:14 -0400, Steve Grubb wrote:
On Saturday 22 September 2007 11:14:02 David Woodhouse wrote:
> > So, those of you with pristine 64 bit machines, watch out for this or 32
> > bit packages will start creeping back into your system. Is this a known
> > problem or should a bz be filed?
>
> Hm, how did you get a pristine 64-bit machine?
One day a couple months ago, I noticed I was about to download > 100 Mb of
packages that I would never use (I think it was all the 386 kde packages), so
I did a yum remove of every 386 or 686 package I could find. Doing "yum
update" has not pulled any 386 packages back in until today.
Yeah, I think the bug only trips when you pull in something by name. If
you invoke 'yum install foo' that will pull in both versions, and I
think it also happens if some package is listed in Requires: by name.
> Did bug #235756 get fixed?
no idea....
Evidently not. It would be _really_ good if we could get that fixed for
F8.
--
dwmw2
5:37 p.m.
On Sat, 2007-09-22 at 17:40 +0100, David Woodhouse wrote:
Yeah, I think the bug only trips when you pull in something by name.
If
you invoke 'yum install foo' that will pull in both versions, and I
think it also happens if some package is listed in Requires: by name.
I've been using "exclude=*.i386" in my /etc/yum.conf for a while, but I
DO have nspluginwrapper (and it's requirements) installed. So "yum
update"s would miss updates to that.
--
Richi Plana
3:58 a.m.
David Woodhouse wrote:
On Sat, 2007-09-22 at 12:14 -0400, Steve Grubb wrote:
> On Saturday 22 September 2007 11:14:02 David Woodhouse wrote:
>
>>> So, those of you with pristine 64 bit machines, watch out for this or 32
>>> bit packages will start creeping back into your system. Is this a known
>>> problem or should a bz be filed?
>>>
>> Hm, how did you get a pristine 64-bit machine?
>>
> One day a couple months ago, I noticed I was about to download > 100 Mb of
> packages that I would never use (I think it was all the 386 kde packages), so
> I did a yum remove of every 386 or 686 package I could find. Doing "yum
> update" has not pulled any 386 packages back in until today.
>
Yeah, I think the bug only trips when you pull in something by name. If
you invoke 'yum install foo' that will pull in both versions
yum install
yum-basearchonly will do exactly that (only pull in foo if
you want foo.i386 you have to ask for it).
7:49 a.m.
On Sun, Sep 23, 2007 at 10:58:57AM +0200, dragoran wrote:
yum install yum-basearchonly will do exactly that (only pull in foo
if
you want foo.i386 you have to ask for it).
I think that it likely doesn't cover this particular case. It's got some
other bugs too.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
8:02 a.m.
Matthew Miller wrote:
On Sun, Sep 23, 2007 at 10:58:57AM +0200, dragoran wrote:
> yum install yum-basearchonly will do exactly that (only pull in foo if
> you want foo.i386 you have to ask for it).
>
I think that it likely doesn't cover this particular case. It's got some
other bugs too.
true in this case (obsolutes) it does exactly nothing...
what are the other bugs you are refering too?
6056
days inactive
6061
days old
59 comments
15 participants
participants (15)
-
Chris Adams -
David Nielsen -
David Woodhouse -
Dominik 'Rathann' Mierzejewski -
drago01 -
Florian Festi -
Jesse Keating -
Jos Vos -
Krzysztof Halasa -
Matthew Miller -
Michael Wiktowy -
Richi Plana -
Seth Vidal -
Steve Grubb -
Ville Skyttä