Re: Automated Mirror Selection [Re: Worst experience with Up2Date ever.]
by Fulko.Hew@sita.aero
Jeff Spaleta <jspaleta(a)gmail.com>@redhat.com on 09/29/2004 05:01:18 PM
wrote:
> On Wed, 29 Sep 2004 14:41:17 -0400 <fulko.hew(a)sita.aero> wrote:
> > The list of mirrors should/could at the very least be a package that
> > we can download to get the 'latest set' of behaving mirrors.
>
> you create a server that holds a 'latest set' of behaving
> mirrors...and keep that server running for people to use...and im sure
> people will use it.
It seems that the main server already has this list
(because its not a local config (that I can find)).
> > Can the master server check the mirrors to see if (all of) their
transfers
> > have been completed, and only then re-add that mirror to the list of
> > candidates?
>
> Why does the master server have to do this. If you think this will
> work...you create a seperate server, that tries to detect which
> mirrors are synced. Read my rules of engagement in this discussion.
Sorry, I just went back to find them, and read them
> If you think you can get this to work...set it up on a community site and
> host a list of 'good' mirrors. Show it works independant of the main
> site.
After trying to figure out why the 'package size' info reported by up2date
is now broken, I don't have the time to figure out how its supposed to
work. Since I haven't found any design notes or documentation on the
communication process, or message flow used by up2date et.al., I gave
up in frustration when faced with the massive amounts of reverse
engineering that would be required.
In this case I was complaining about a blatently 'dead' site, and to
the best of my knowledge, has never worked since it was added to the
master list. I know its manual, but the list of hosts that the master site
maintains (and distributes) could easily, manually, be updated to remove
this entry. One person, one time, 15 seconds, and the community would
have one less thing to grip about. Give me access to that site, and I'll
do it!
> > Sure, it would be nicer if the mirror could just 'tell' the master,
rather
> > than
> > have the master poll...
>
> Read my rules of engagement for this discussion. Sure it would be
> nicer...but its not reality...its not going to happen..you arent going
> to be able to demand this of mirrors and still expect as many mirror
> admins with high bandwidth to volunteer to be a part of the official
> mirror list.
The reality of networking is that: a mirror isn't a mirror, unless its
accessible, and it actually _is_ a mirror... volunteer or not.
Wrong information is worse than no information.
> > PITA scripts should be a prerequisite to becomming a mirror, or at the
very
> > least to be a mirror that gets put into the mirror list.
>
> shoulda,woulda,coulda... you clearly didn't read my ground rules for
> participating in this discussion. And as promised I'm now going to
> point and laugh at you.
> <point and laugh mode>
> HaHa look at the funny person HeHe
> </point and laugh mode>
You can laugh all you want, but that makes you part of the problem
and not part of the solution. I'm sorry if you are not open to
constructive criticism.
... snip ...
> Face facts, you up the
> maintainership burden to be a fedora official mirror and you will drop
> the number of mirrors listed in the official list, since it really
> makes no difference to most mirror admins if they are on the official
> fedora list or not.
See my statement above... If your not accessible, or not mirroring,
then you are NOT a mirror, and shouldn't be on the official (communicated)
list.
> > I think thats too complicated. Something that notifies when the rsync
is
> > done is better.
> Flying cars are better than cars with wheels....so what...you aren't
> going to mandate that we all start using flying cars. Just like you
> are not going to mandate to the mirrors that volunteer their bandwidth
> to run addition services to make it easier for user to know when the
> sync is done...it just isnt going to happen.
Compared to the bandwidth used to actually mirror the sites, and to supply
the
mirror to the world, the notification process is a trial amount of
bandwidth
or effort.
> There are political and
> technical realities that must be considered and you aren't considering
> them. Let me take a quick moment to point and laugh at you again.
> HaHa...HeHe...
Your laugh indicates your immaturity, and your reluctance to solve the
problem. Your 'rules of engagement' provide a number of restrictions,
but without justification. Given them, it is impossible to provide a
usable environment.
I contend that your rules are un-realistic.
If the mirrors are using rsync, then there has to be a cron job (or
equivalent)
set up on the mirror to perform the sync. The mirror administrator has
already
committed to setting that up... and maintaining it. That cron job could
easily be extended to perform its rsync in two stages, to address the
headers versus RPMs issue, and to add an rsync that pushes back a nodeName,
date stamp file back to the master site. Anyone, (and I'll volunteer, if
the appropriate access rights and design information are given) can write
the
simple script that checks these files and builds the master list from it.
19 years, 6 months
openoffice.org copy/paste in sheet broken; ooo 1.9.x
by Marius Andreiana
With default fc3t2, having openoffice.org-1.1.2-3, copy-paste in
spreadsheet (keyboard shortcuts or Edit menu) doesn't work. In Writer it
works.
There's no bug about this:
https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora
+Core&version=fc3test1&version=fc3test2&component=openoffice&component=openoffice.org&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&Search=Search
Fortunately, ooo 1.9.x is available as RPMS from openoffice.org and they
are working quite nice usually. I encourage people on the test list to
use it by default (ooo 1.1.x works too, one can choose what to launch
from menu) and help find the last bugs. Please check on ooo's issuezilla
first before filling new bugs.
--
Marius Andreiana
Galuna - Solutii Linux in Romania
http://www.galuna.ro
19 years, 6 months
can't edit crontab?
by Joe Borne
For some reason I can't edit crontab even if I am root? Is anyone else
seeing this behavior?
19 years, 6 months
yum not updating fc3t1 to fc3t2
by Wood David
I've been using yum for ages, but failed to get yum 2.1.3 to update fc3t1
to fc3t2 because ...
$yum update
Setting up Update Process
Setting up Repo: base
repomd.xml 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
base : ################################################## 2665/2665
Excluding Packages
Excluding Incompatible Archs
Finished
Excluding Packages from Fedora Core 2.90 - i386 - Base
Resolving Dependencies
a2ps-4.13b-40.i386.rpm 100% |=========================| 1.1 MB 00:02
Traceback (most recent call last):
File "/usr/share/yum-cli/yummain.py", line 139, in ?
main(sys.argv[1:])
File "/usr/share/yum-cli/yummain.py", line 94, in main
(result, resultmsgs) = base.buildTransaction()
File "/usr/lib/python2.3/site-packages/yum/__init__.py", line 131, in
buildTransaction
(rescode, restring) = self.resolveDeps()
File "/usr/lib/python2.3/site-packages/yum/depsolve.py", line 151, in
resolveDeps
self.populateTs(test=1)
File "/usr/lib/python2.3/site-packages/yum/depsolve.py", line 115, in
populateTs
hdr = po.getHeader()
File "/usr/lib/python2.3/site-packages/yum/packages.py", line 272, in
getHeader
hdr = hlist[0]
IndexError: list index out of range
My hopes that 2.1.4 would fix it have been dashed ...
$ yum update
Setting up Update Process
Setting up Repo: base
repomd.xml 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
base : ################################################## 2665/2665
Resolving Dependencies
a2ps-4.13b-40.i386.rpm 100% |=========================| 1.1 MB 00:01
Fedora/RPMS/a2ps-4.13b-40.i386.rpm: [Errno -1] Header is not complete.
Error: failure: Fedora/RPMS/a2ps-4.13b-40.i386.rpm from base: [Errno 256] No
more mirrors to try.
Any ideas? I completely deleted the /var/cache/yum directory first to see
if that helped.
The Information contained in this E-Mail and any subsequent correspondence
is private and is intended solely for the intended recipient(s).
For those other than the recipient any disclosure, copying, distribution,
or any action taken or omitted to be taken in reliance on such information
is prohibited and may be unlawful.
Emails and other electronic communication with QinetiQ may be monitored.
Calls to QinetiQ may be recorded for quality control,
regulatory and monitoring purposes.
19 years, 6 months
RE: Yum update...only one at a time?
by Mike Loiterman
Mike Loiterman <mailto:mike@ascendency.net> wrote:
> Michal Jaegermann <mailto:michal@harddata.com> wrote:
>> On Thu, Sep 30, 2004 at 12:45:43AM -0400, seth vidal wrote:
>>> On Wed, 2004-09-29 at 23:45 -0500, Mike Loiterman wrote:
>>>> I'm doing yum update, but its only doing one package at a
>>>> time...any idea why?
>>>>
>>>> I've done a yum clean all and I'm using version 2.1.4
>>>
>>> What do you mean one package at a time?
>>
>> It seems to me that something went haywire with a dependency
>> resolution and not really in yum but somewhere in rpm libraries.
>> An attempt to use directly 'rpm -Fvh ...' with a bunch of packages
>> from the current updates ends up with:
>>
>> error: Failed dependencies:
>> linc >= 0.1.6 is needed by (installed) pyorbit-2.0.0-3.1
>> linc = 1.0.3 is needed by (installed) linc-devel-1.0.3-6
>>
>> while 'rpm -q linc' responds with 'linc-1.0.3-6' and
>> 'rpm -q linc-devel' with 'linc-devel-1.0.3-6'. This appears to trip
>> yum.
>>
>> It seems that the real culprit is ORBit2, though, but why it
>> triggers this problem is far from clear to me. Still, when other
>> packages are updated then ORBit2, and ORBit2-devel, can be updated
>> as well but only then.
>>
So what is the exact command sequence you used to update?
------------------------------
Mike Loiterman
grantADLER
Tel: 630-302-4944
Fax: 773-442-0992
Email: mike(a)ascendency.net
PGP Key: 0xD1B9D18E
GPG Key: 0x661D0518
19 years, 6 months
RE: start_udev and X crashing after latest FC3T2 update
by Ernest L. Williams Jr.
-----Original Message-----
From: fedora-test-list-bounces(a)redhat.com on behalf of Gabriel Moreno
Sent: Thu 9/30/2004 3:31 AM
To: For testers of Fedora Core development releases
Subject: Re: start_udev and X crashing after latest FC3T2 update
I have the exact same problem. Updated this morning. Tonight I
rebooted and when it tries to switch to graphical mode it seems to
stop booting up. No HD activitiy. Will most likely have to
re-install bummer. You atleast can see your logs. Maybe you should
bugzilla it.
The above happened to me as well.
Do the udev downgrade and all should be well.
that is go back to "udev-032-2"
On Wed, 29 Sep 2004 11:29:35 -0400, Clyde Kunkel
<clydekunkel7734(a)cox.net> wrote:
> Finished updated FC3T2 this AM and get error msg unexpected } in line 79
> of /sbin/start_udev. Never get graphical login screen. Can blindly
> login in, open tty2 and reboot.
>
> Anyone else having these probs? I am not an expert by any means and
> appreciate any help anyone can provide?
>
> This is a multi-boot machine and am able to look at FC3T2 messages after
> booting into FC2 and see the following about X crashing (partial
> listing):
>
> Sep 29 10:08:10 localhost kernel: ACPI: PCI interrupt 0000:01:00.0[A] ->
> GSI 16 (level, low) -> IRQ 169
> Sep 29 10:08:10 localhost kernel: [drm] Initialized radeon 1.11.0
> 20020828 on minor 0:
> Sep 29 10:08:10 localhost kernel: agpgart: Found an AGP 3.0 compliant
> device at 0000:00:00.0.
> Sep 29 10:08:10 localhost kernel: agpgart: Putting AGP V3 device at
> 0000:00:00.0 into 4x mode
> Sep 29 10:08:10 localhost kernel: agpgart: Putting AGP V3 device at
> 0000:01:00.0 into 4x mode
> Sep 29 10:08:10 localhost kernel: [drm] Loading R200 Microcode
> Sep 29 10:08:10 localhost udev: creating device node '/dev/radeon'
> Sep 29 10:08:11 localhost gdm[4115]: gdm_slave_xioerror_handler: Fatal X
> error - Restarting :0
> Sep 29 10:08:11 localhost udev: removing device node '/dev/vcs7'
> Sep 29 10:08:11 localhost udev: removing device node '/dev/vcsa7'
> Sep 29 10:08:14 localhost udev: creating device node '/dev/vcs7'
> Sep 29 10:08:15 localhost kernel: agpgart: Found an AGP 3.0 compliant
> device at 0000:00:00.0.
> Sep 29 10:08:15 localhost kernel: agpgart: Putting AGP V3 device at
> 0000:00:00.0 into 4x mode
> Sep 29 10:08:15 localhost kernel: agpgart: Putting AGP V3 device at
> 0000:01:00.0 into 4x mode
> Sep 29 10:08:15 localhost kernel: [drm] Loading R200 Microcode
> Sep 29 10:08:15 localhost udev: creating device node '/dev/vcsa7'
> Sep 29 10:08:15 localhost udev: creating device node '/dev/vcs8'
> Sep 29 10:08:15 localhost udev: removing device node '/dev/vcs8'
> Sep 29 10:08:15 localhost udev: creating device node '/dev/vcsa8'
> Sep 29 10:08:15 localhost udev: removing device node '/dev/vcsa8'
> Sep 29 10:08:16 localhost udev: creating device node '/dev/vcs8'
> Sep 29 10:08:16 localhost udev: creating device node '/dev/vcsa8'
> Sep 29 10:08:16 localhost gdm[4608]: gdm_slave_xioerror_handler: Fatal X
> error - Restarting :0
> Sep 29 10:08:16 localhost udev: removing device node '/dev/vcs8'
> Sep 29 10:08:16 localhost udev: removing device node '/dev/vcsa8'
> Sep 29 10:08:16 localhost udev: removing device node '/dev/vcs7'
> Sep 29 10:08:16 localhost udev: removing device node '/dev/vcsa7'
> Sep 29 10:08:19 localhost udev: creating device node '/dev/vcs8'
> Sep 29 10:08:19 localhost udev: creating device node '/dev/vcsa8'
> Sep 29 10:08:19 localhost udev: creating device node '/dev/vcs7'
> Sep 29 10:08:19 localhost udev: removing device node '/dev/vcs7'
> Sep 29 10:08:20 localhost udev: creating device node '/dev/vcs7'
> Sep 29 10:08:20 localhost kernel: agpgart: Found an AGP 3.0 compliant
> device at 0000:00:00.0.
> Sep 29 10:08:20 localhost kernel: agpgart: Putting AGP V3 device at
> 0000:00:00.0 into 4x mode
> Sep 29 10:08:20 localhost kernel: agpgart: Putting AGP V3 device at
> 0000:01:00.0 into 4x mode
> Sep 29 10:08:20 localhost kernel: [drm] Loading R200 Microcode
> Sep 29 10:08:20 localhost udev: creating device node '/dev/vcsa7'
> Sep 29 10:08:20 localhost udev: removing device node '/dev/vcsa7'
> Sep 29 10:08:21 localhost udev: creating device node '/dev/vcsa7'
> Sep 29 10:08:21 localhost gdm[4732]: gdm_slave_xioerror_handler: Fatal X
> error - Restarting :0
> Sep 29 10:08:21 localhost udev: removing device node '/dev/vcs7'
> Sep 29 10:08:21 localhost udev: removing device node '/dev/vcsa7'
> Sep 29 10:08:21 localhost gdm[3846]: deal_with_x_crashes: Running the
> XKeepsCrashing script
> Sep 29 10:08:21 localhost udev: removing device node '/dev/vcs8'
> Sep 29 10:08:21 localhost udev: removing device node '/dev/vcsa8'
> Sep 29 10:08:21 localhost udev: creating device node '/dev/vcs7'
> Sep 29 10:08:21 localhost udev: creating device node '/dev/vcsa7'
> Sep 29 10:08:22 localhost udev: creating device node '/dev/vcsa8'
> Sep 29 10:08:22 localhost udev: creating device node '/dev/vcs8'
>
> --
> fedora-test-list mailing list
> fedora-test-list(a)redhat.com
> To unsubscribe:
> http://www.redhat.com/mailman/listinfo/fedora-test-list
>
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
http://www.redhat.com/mailman/listinfo/fedora-test-list
19 years, 6 months
Yum update...only one at a time?
by Mike Loiterman
I'm doing yum update, but its only doing one package at a time...any idea
why?
I've done a yum clean all and I'm using version 2.1.4
------------------------------
Mike Loiterman
grantADLER
Tel: 630-302-4944
Fax: 773-442-0992
Email: mike(a)ascendency.net
PGP Key: 0xD1B9D18E
GPG Key: 0x661D0518
19 years, 6 months
RE: yum not updating fc3t1 to fc3t2
by Wood David
> On Thu, Sep 30, 2004 at 01:34:10PM +0100, Wood David wrote:
> > I've been using yum for ages, but failed to get yum 2.1.3
> to update fc3t1
> > to fc3t2 because ...
>
> Use a mirror like zeniiia.linux.org.uk, update yum specifically first
>
> > Resolving Dependencies
> > a2ps-4.13b-40.i386.rpm 100% |=========================|
> 1.1 MB 00:01
> > Fedora/RPMS/a2ps-4.13b-40.i386.rpm: [Errno -1] Header is
> not complete.
> > Error: failure: Fedora/RPMS/a2ps-4.13b-40.i386.rpm from
> base: [Errno 256] No
> > more mirrors to try.
>
> The primary download site is a little loaded 8)
That doesn't solve the problem :(
Here is my yum.conf (excluding commented out lines):
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
tolerant=1
exactarch=1
retries=20
[base]
name=Fedora Core $releasever - $basearch - Base
baseurl=http://zeniiia.linux.org.uk/pub/distributions/fedora/linux/core/test
/2.91/i386/os/
The Information contained in this E-Mail and any subsequent correspondence
is private and is intended solely for the intended recipient(s).
For those other than the recipient any disclosure, copying, distribution,
or any action taken or omitted to be taken in reliance on such information
is prohibited and may be unlawful.
Emails and other electronic communication with QinetiQ may be monitored.
Calls to QinetiQ may be recorded for quality control,
regulatory and monitoring purposes.
19 years, 6 months