I see 4.1b1 pushed in rawhide. As 4.0.4 globally is a sort of beta itself (in my preliminary opinion of course: I'm using it in f9 starting 2 weeks ago and somehow in rawhide pre-f9), couldn't be positive to have 4.0.80 also in f9 and so tested from a wider user base and not only in rawhide? Is it planned, or only the final 4.1 will converge in f9? Thanks and anyway keep on with the good work, Gianluca
Gianluca Cecchi <gianluca.cecchi <at> gmail.com> writes:
As 4.0.4 globally is a sort of beta itself (in my preliminary opinion of course: I'm using it in f9 starting 2 weeks ago and somehow in rawhide pre-f9), couldn't be positive to have 4.0.80 also in f9 and so tested from a wider user base and not only in rawhide? Is it planned, or only the final 4.1 will converge in f9?
The plan is to push the final 4.1 when it is released, but not betas or RCs.
We trust upstream to know what they're doing when they label their releases "beta".
Kevin Kofler
Kevin Kofler wrote:
Gianluca Cecchi <gianluca.cecchi <at> gmail.com> writes:
As 4.0.4 globally is a sort of beta itself (in my preliminary opinion of course: I'm using it in f9 starting 2 weeks ago and somehow in rawhide pre-f9), couldn't be positive to have 4.0.80 also in f9 and so tested from a wider user base and not only in rawhide? Is it planned, or only the final 4.1 will converge in f9?
The plan is to push the final 4.1 when it is released, but not betas or RCs.
We trust upstream to know what they're doing when they label their releases "beta".
Yes.
When they pronounce "final," that's the time to wonder:-)
On Fri, 2008-05-30 at 07:14 +0200, Gianluca Cecchi wrote:
I see 4.1b1 pushed in rawhide. As 4.0.4 globally is a sort of beta itself (in my preliminary opinion of course: I'm using it in f9 starting 2 weeks ago and somehow in rawhide pre-f9), couldn't be positive to have 4.0.80 also in f9 and so tested from a wider user base and not only in rawhide? Is it planned, or only the final 4.1 will converge in f9? Thanks and anyway keep on with the good work, Gianluca -- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
you might find it in Development but it will not be official so you use it at your own risk in F9 KDE4.1 Beta1
Gianluca Cecchi wrote:
On Fri, 30 May 2008 16:46:31 +1000 Greg wrote:
you might find it in Development but it will not be official so you use it at your own risk in F9 KDE4.1 Beta1
Thanks Greg. Any simple way to enable devel repository in yum but only for kde4 related packages?
Gianluca
yum --enablerepo=development update
but that you'll get FC10 packages. i dunno if they have FC9 packages as yet,, unless there in the redhat-kde-org repo ..
On Fri, 30 May 2008 18:53:03 +1000, Greg wrote:
Gianluca Cecchi wrote:
On Fri, 30 May 2008 16:46:31 +1000 Greg wrote:
you might find it in Development but it will not be official so you use it at your own risk in F9 KDE4.1 Beta1
Thanks Greg. Any simple way to enable devel repository in yum but only for kde4 related packages?
Gianluca
yum --enablerepo=development update
That doesn't answer the question, because once the devel repo is enabled, yum would pull in non-KDE4 packages, too, if they are required as dependencies. You could try to cherry-pick individual package names, and that will work as long as there are no strict dependencies on other stuff in devel.
2008/5/30 Michael Schwendt mschwendt.tmp0701.nospam@arcor.de:
That doesn't answer the question, because once the devel repo is enabled, yum would pull in non-KDE4 packages, too, if they are required as dependencies. You could try to cherry-pick individual package names, and that will work as long as there are no strict dependencies on other stuff in devel.
Cherry-picking works quite well, in fact.
Try roughly as follows:
qt*, akonadi kdelibs-common, kdelibs kdebase*, ksysguardd, extragear-plasma "everything else"
Bill Crawford <billcrawford1970 <at> gmail.com> writes:
Cherry-picking works quite well, in fact.
But be warned that cherry-picking from Rawhide is COMPLETELY UNSUPPORTED and may break at any moment. For example, if a central library like openssl or openldap gets a soname bump, everything will get rebuilt against it, and then the new KDE will drag in the new library, which will replace the old version, and the removal of the old version of the library will drag in all the other rebuilds. Moreover, there's no way we can test all arbitrary combinations of Rawhide and F9 packages. Rawhide packages are set up to work well with other Rawhide packages, not necessarily F9 ones.
Kevin Kofler
Kevin Kofler wrote:
Bill Crawford <billcrawford1970 <at> gmail.com> writes:
Cherry-picking works quite well, in fact.
But be warned that cherry-picking from Rawhide is COMPLETELY UNSUPPORTED and may break at any moment. For example, if a central library like openssl or openldap gets a soname bump, everything will get rebuilt against it, and then the new KDE will drag in the new library, which will replace the old version, and the removal of the old version of the library will drag in all the other rebuilds. Moreover, there's no way we can test all arbitrary combinations of Rawhide and F9 packages. Rawhide packages are set up to work well with other Rawhide packages, not necessarily F9 ones.
Kevin Kofler
Building it yourself has better prospects. Not necessarily good prospects, just better.
On Fri, 2008-05-30 at 11:05 +0200, Michael Schwendt wrote:
That doesn't answer the question, because once the devel repo is enabled, yum would pull in non-KDE4 packages, too, if they are required as dependencies. You could try to cherry-pick individual package names, and that will work as long as there are no strict dependencies on other stuff in devel.
Why not 'yum --enablerepo=rawhide groupupdate "KDE (K Desktop Environment)"
On Fri, 30 May 2008 09:14:57 -0400, Jesse Keating wrote:
On Fri, 2008-05-30 at 11:05 +0200, Michael Schwendt wrote:
That doesn't answer the question, because once the devel repo is enabled, yum would pull in non-KDE4 packages, too, if they are required as dependencies. You could try to cherry-pick individual package names, and that will work as long as there are no strict dependencies on other stuff in devel.
Why not 'yum --enablerepo=rawhide groupupdate "KDE (K Desktop Environment)"
Would just be another method to get a list of packages to update with the same caveat: dependencies can lead to updates of non-KDE packages.
On Fri, 2008-05-30 at 15:35 +0200, Michael Schwendt wrote:
Would just be another method to get a list of packages to update with the same caveat: dependencies can lead to updates of non-KDE packages.
Well sure, you're not going to get around that no matter what you do. It's just a much easier method to "cherry pick" the KDE contents from rawhide.
2008/5/30 Jesse Keating jkeating@redhat.com:
Well sure, you're not going to get around that no matter what you do. It's just a much easier method to "cherry pick" the KDE contents from rawhide.
Except by the time you've added all the "--excludes kdepim,kdepim-libs" and stuff ... :o)
Good point though. If you know you want to try it "all" out, that would probably help. So far the only deps I saw dragged in were akonadi and ksysguardd (which I'd forgotten to mention on the command line the first time).
The openssl dependency bit me when I went f8 -> cherry-picked rawhide, but I just force-installed the newer openssl with rpm *runs away and hides before he gets pelted with don't-do-thats*.
2008/5/30 Bill Crawford billcrawford1970@gmail.com:
So far the only deps I saw dragged in were akonadi and ksysguardd (which I'd forgotten to mention on the command line the first time).
Forgetting to mention I included some manually in the update command, ... kipi-plugins, libkdcraw.
Jesse Keating wrote:
On Fri, 2008-05-30 at 11:05 +0200, Michael Schwendt wrote:
That doesn't answer the question, because once the devel repo is enabled, yum would pull in non-KDE4 packages, too, if they are required as dependencies. You could try to cherry-pick individual package names, and that will work as long as there are no strict dependencies on other stuff in devel.
Why not 'yum --enablerepo=rawhide groupupdate "KDE (K Desktop Environment)"
Sounds like a sensible way to get a list of packages. Then pick some cherries, download their source and build them.
Gianluca Cecchi wrote:
I see 4.1b1 pushed in rawhide. As 4.0.4 globally is a sort of beta itself (in my preliminary opinion of course: I'm using it in f9 starting 2 weeks ago and somehow in rawhide pre-f9), couldn't be positive to have 4.0.80 also in f9 and so tested from a wider user base and not only in rawhide?
On Fri, 2008-05-30 at 07:14 +0200, Gianluca Cecchi wrote:
I see 4.1b1 pushed in rawhide. As 4.0.4 globally is a sort of beta itself (in my preliminary opinion of course: I'm using it in f9 starting 2 weeks ago and somehow in rawhide pre-f9), couldn't be positive to have 4.0.80 also in f9 and so tested from a wider user base and not only in rawhide? Is it planned, or only the final 4.1 will converge in f9? Thanks and anyway keep on with the good work,
Check out http://etotheipiplusone.com/kde4daily/docs/kde4daily.html#Included_Modules
This is a virtual machine image (for qemu, though there's also a VirtualBox version) based on Kubuntu and updated daily.
poc