Alexander Boström wrote:
Den 2009-06-25 13:07, Simon Andrews skrev:
If all anaconda upgrades are going to be online
Anaconda upgrades initiated through Preupgrade do not require a network
connection.
They will if one of the conditions for upgrading is going to be access
to the updates
On 06/26/2009 04:04 PM, Simon Andrews wrote:
Alexander Boström wrote:
Den 2009-06-25 13:07, Simon Andrews skrev:
If all anaconda upgrades are going to be online
Anaconda upgrades initiated through Preupgrade do not require a
network connection.
They will if one of the conditions for
On Fri, 2009-06-26 at 07:44 -0400, Seth Vidal wrote:
Preupgrade has access to the network BEFORE the anaconda run, that's the
whole point. It processes the pkg lists and downloads all the needed pkgs
beforehand.
So the anaconda run won't need network access b/c all the pkgs are taken
On Fri, 26 Jun 2009, Jesse Keating wrote:
On Fri, 2009-06-26 at 07:44 -0400, Seth Vidal wrote:
Preupgrade has access to the network BEFORE the anaconda run, that's the
whole point. It processes the pkg lists and downloads all the needed pkgs
beforehand.
So the anaconda run won't need
Kevin Kofler wrote:
Simon Andrews wrote:
I don't see the problem with forcing the use of these packages during an
upgrade regardless of what versions were on the original system. You'd
be left with a functional system
Not really. Things like KDE config files processed by kconf_update,
On 06/25/2009 01:37 PM, Simon Andrews wrote:
1) All of our servers have to access the internet via a proxy. At least
within the Anaconda UI there doesn't appear to be any support for
configuring proxies so I'm forced into kickstart / shells / extra boot
options to upgrade?
Do you have a
Le Jeu 25 juin 2009 10:07, Simon Andrews a écrit :
1) All of our servers have to access the internet via a proxy. At
least
within the Anaconda UI there doesn't appear to be any support for
configuring proxies so I'm forced into kickstart / shells / extra boot
options to upgrade?
BTW,
Once upon a time, Simon Andrews simon.andr...@bbsrc.ac.uk said:
1) All of our servers have to access the internet via a proxy. At least
within the Anaconda UI there doesn't appear to be any support for
configuring proxies so I'm forced into kickstart / shells / extra boot
options to
Once upon a time, Simon Andrews simon.andr...@bbsrc.ac.uk said:
Can anaconda handle wireless network connections for upgrades?
I think it can, for the NICs supported out-of-the-box. I haven't tried
it, but I know my wireless NIC shows up on my notebook.
--
Chris Adams cmad...@hiwaay.net
On Thu, 25 Jun 2009, Simon Andrews wrote:
Not really. Things like KDE config files processed by kconf_update, Firefox
profiles, Amarok databases etc. will have been converted to the format
expected by the new version, downgrading is not supported by upstream and
the old version may thus not
On Wed, 24 Jun 2009 01:02:18 +0200, Kevin wrote:
Michael Schwendt wrote:
Then with the switch to koji+bodhi a few package owners complained loudly
about false positives that were caused by pending builds, which were not
found in the master repo yet. A few other package owners jumped upon
Kevin Kofler wrote:
this time the DVD has become completely useless for upgrades,
unless you like having to fetch an updated yum by hand (which, if you are a
KDE user, you have to do from runlevel 3 because KDE (including KDM) is
also broken after the upgrade for basically the same reason yum is
Simon Andrews wrote:
I don't see the problem with forcing the use of these packages during an
upgrade regardless of what versions were on the original system. You'd
be left with a functional system
Not really. Things like KDE config files processed by kconf_update, Firefox
profiles, Amarok
Le Mer 24 juin 2009 12:01, Kevin Kofler a écrit :
Not really. Things like KDE config files processed by kconf_update,
Firefox
profiles, Amarok databases etc. will have been converted to the format
expected by the new version, downgrading is not supported by upstream
and
the old version
On Mon, 2009-06-22 at 09:31 +0200, Jesse Keating wrote:
If you have any ideas I'd like to hear them. A super epoch has already
been suggested but that just masks the problem and may cause unwanted
downgrades. Any solution either involves severly limiting what kind of
updates can be done
Michael Schwendt wrote:
Then with the switch to koji+bodhi a few package owners complained loudly
about false positives that were caused by pending builds, which were not
found in the master repo yet. A few other package owners jumped upon the
train and questioned the usefulness of the script,
On Jun 24, 2009, at 0:46, Adam Williamson awill...@redhat.com wrote:
On Mon, 2009-06-22 at 09:31 +0200, Jesse Keating wrote:
If you have any ideas I'd like to hear them. A super epoch has
already
been suggested but that just masks the problem and may cause unwanted
downgrades. Any
Nathanael D. Noblet wrote:
For example people with updates-testing enabled on fc10 got a
non-upgraded yum because the versions were the same (except for
fc10/fc11) and it stopped working because python went from 2.5 to
2.6 So to RPM the fc10/fc11 isn't being compared, at least not that
I
Jussi Lehtola wrote:
Does anaconda currently force installs of core packages such as yum?
No.
This is quite important if the version in the old distro is newer than
that on the DVD.
You just end up with a broken yum.
Kevin Kofler
--
fedora-devel-list mailing list
Rahul Sundaram wrote:
On 06/22/2009 12:54 PM, Jesse Keating wrote:
Not possible while we allow people to keep making updates to the older
releases. Those updates quickly become version ( not just release even
) higher than the static copies on the release medium and repos.
Is there any
On Jun 22, 2009, at 1:08, Dave Jones da...@redhat.com wrote:
On Sun, Jun 21, 2009 at 04:56:07PM -0600, Nathanael D. Noblet wrote:
I *wish* it made a difference. I did an upgrade am an left with a
host
of fc10 packages because the fc11 ones weren't considered newer.
For example people
On 06/22/2009 12:54 PM, Jesse Keating wrote:
Not possible while we allow people to keep making updates to the older
releases. Those updates quickly become version ( not just release even
) higher than the static copies on the release medium and repos.
Is there any proposed solution to this
On 22/06/09 08:24, Jesse Keating wrote:
That's messed up. We used to check just before release time that this
situation never occured. It should probably be added to the rel-eng
release checklist if it isn't there already.
Dave
Not possible while we allow people to keep making updates
On Jun 22, 2009, at 9:26, Rahul Sundaram sunda...@fedoraproject.org
wrote:
On 06/22/2009 12:54 PM, Jesse Keating wrote:
Not possible while we allow people to keep making updates to the
older
releases. Those updates quickly become version ( not just release
even
) higher than the
On Jun 22, 2009, at 9:29, Frank Murphy frankl...@gmail.com wrote:
On 22/06/09 08:24, Jesse Keating wrote:
That's messed up. We used to check just before release time that
this
situation never occured. It should probably be added to the rel-eng
release checklist if it isn't there
On Mon, 2009-06-22 at 09:31 +0200, Jesse Keating wrote:
On Jun 22, 2009, at 9:26, Rahul Sundaram sunda...@fedoraproject.org
wrote:
On 06/22/2009 12:54 PM, Jesse Keating wrote:
Not possible while we allow people to keep making updates to the
older
releases. Those updates quickly
On 22/06/09 08:32, Jesse Keating wrote:
Maybe, freeze all updates nearing a GA,
And keep them frozen indefinitely?
--
Jes
Duh!, forgot the coffee.
That would get the early adopters,
then nearing EOL of current eg 9.
Only allow updates for 11.
Same when 10 is EOL.
Just update most
On Jun 22, 2009, at 9:38, Frank Murphy frankl...@gmail.com wrote:
On 22/06/09 08:32, Jesse Keating wrote:
Maybe, freeze all updates nearing a GA,
And keep them frozen indefinitely?
--
Jes
Duh!, forgot the coffee.
That would get the early adopters,
then nearing EOL of current eg 9.
On 06/22/2009 01:01 PM, Jesse Keating wrote:
If you have any ideas I'd like to hear them. A super epoch has already
been suggested but that just masks the problem and may cause unwanted
downgrades. Any solution either involves severly limiting what kind of
updates can be done or requiring
On Mon, Jun 22, 2009 at 01:14:55PM +0530, Rahul Sundaram wrote:
On 06/22/2009 01:01 PM, Jesse Keating wrote:
If you have any ideas I'd like to hear them. A super epoch has already
been suggested but that just masks the problem and may cause unwanted
downgrades. Any solution either involves
On 06/22/2009 04:49 PM, Josh Boyer wrote:
I think you mean before pushing rather than signing, but this idea has been
suggested before.
Well, if you aren't going to push anyway, then signing it wouldn't be
that useful, right? A koji build can be a trigger for the script check
instead of a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There are still packagers who bump %version or %release
in old dist updates without considering the consequences with regard to
dist upgrades.
I think this is the real problem
If this hits yum or any package yum depends on you have no chance for
On Mon, Jun 22, 2009 at 04:53:10PM +0530, Rahul Sundaram wrote:
On 06/22/2009 04:49 PM, Josh Boyer wrote:
I think you mean before pushing rather than signing, but this idea has been
suggested before.
Well, if you aren't going to push anyway, then signing it wouldn't be
that useful, right?
On 06/22/2009 05:35 PM, Josh Boyer wrote:
Isn't the scripts Michael Schwendt refers to, not useful anymore? Even
It's useful. It's generally after the fact though, and in the long run I
think
we want to be proactive, not reactive.
I agree but we aren't even reacting much now. If the
On Mon, Jun 22, 2009 at 06:20:07PM +0530, Rahul Sundaram wrote:
On 06/22/2009 05:35 PM, Josh Boyer wrote:
Isn't the scripts Michael Schwendt refers to, not useful anymore? Even
It's useful. It's generally after the fact though, and in the long run I
think
we want to be proactive, not
Le Lun 22 juin 2009 15:26, Josh Boyer a écrit :
True. Care to file a rel-eng ticket suggesting we setup a cronjob to
do so?
The script will likely need some rework and it may take some time, but
the
ticket is a good starting point.
Can a ticket be opened to run other periodic checks for
On 06/22/2009 06:56 PM, Josh Boyer wrote:
On Mon, Jun 22, 2009 at 06:20:07PM +0530, Rahul Sundaram wrote:
On 06/22/2009 05:35 PM, Josh Boyer wrote:
Isn't the scripts Michael Schwendt refers to, not useful anymore? Even
It's useful. It's generally after the fact though, and in the long run I
On Mon, Jun 22, 2009 at 8:32 AM, Dave Jonesda...@redhat.com wrote:
Considering these updates are supposed to be for our 'stable' release,
having them be in $nextrelease first seems like a good idea anyway.
including rawhide?
Do you want security fix updates to block on rawhide not composing in
On Mon, 22 Jun 2009 14:18:39 -0400, Tom wrote:
Jeff Spaleta writes:
On Mon, Jun 22, 2009 at 8:32 AM, Dave Jones wrote:
Considering these updates are supposed to be for our 'stable' release,
having them be in $nextrelease first seems like a good idea anyway.
including rawhide?
Yes,
On Jun 22, 2009, at 18:32, Dave Jones da...@redhat.com wrote:
On Mon, Jun 22, 2009 at 09:31:32AM +0200, Jesse Keating wrote:
On Jun 22, 2009, at 9:26, Rahul Sundaram sunda...@fedoraproject.org
wrote:
On 06/22/2009 12:54 PM, Jesse Keating wrote:
Not possible while we allow people to
Hi all,
Why is necessary to have a particular package tagged as fc10 or fc11?? What
is the significance.? As it is, versions of the packages keep changing
independent of the Fedora versions.
For example :
kdebase-4.2.3-1.fc10.i386 is available for fc10
and the same version
I second this.
Can't we have only one stable repository which is for Fedora,
instead of one each FC10, FC11, ...?
development, testing and stable three repositories for Fedora
as a whole and snapshots of stable as releases?
That would make definitely user's life simple and I believe would make
On Sun, 2009-06-21 at 18:22 +0530, Prasad H. L. wrote:
I second this.
Can't we have only one stable repository which is for Fedora,
instead of one each FC10, FC11, ...?
development, testing and stable three repositories for Fedora
as a whole and snapshots of stable as releases?
That
On Sun, 21 Jun 2009 14:52:18 +0200, drago01 wrote:
On Sun, Jun 21, 2009 at 2:42 PM, Bharathajeetbhar...@gmail.com wrote:
Hi all,
Why is necessary to have a particular package tagged as fc10 or fc11?? What
is the significance.? As it is, versions of the packages keep changing
On Sun, Jun 21, 2009 at 04:56:07PM -0600, Nathanael D. Noblet wrote:
I *wish* it made a difference. I did an upgrade am an left with a host
of fc10 packages because the fc11 ones weren't considered newer.
For example people with updates-testing enabled on fc10 got a
non-upgraded yum
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nathanael D. Noblet wrote:
On 06/21/2009 09:14 AM, Michael Schwendt wrote:
Yes, and let me add that the .fc10 and .fc11 (the dist-
tag) is part
of the package Release value not just the package file
name.
That makes the .fc11 package newer
46 matches
Mail list logo
