Problem with latest F12 updates
Anybody has the same (or similar) problem with latest F12 updates (Package deb vs. perl-5.8.6)? sudo yum update Loaded plugins: presto, refresh-packagekit Setting up Update Process Resolving Dependencies -- Running transaction check --- Package acl.i686 0:2.2.49-2.fc12 set to be updated --- Package foomatic-db.noarch 0:4.0-8.20091126.fc12 set to be updated --- Package foomatic-db-filesystem.noarch 0:4.0-8.20091126.fc12 set to be updated --- Package foomatic-db-ppds.noarch 0:4.0-8.20091126.fc12 set to be updated --- Package gnome-user-share.i686 0:2.28.2-1.fc12 set to be updated --- Package gtk-vnc.i686 0:0.3.10-2.fc12 set to be updated --- Package libacl.i686 0:2.2.49-2.fc12 set to be updated --- Package microcode_ctl.i686 1:1.17-1.57.fc12 set to be updated --- Package netpbm.i686 0:10.47.07-1.fc12 set to be updated --- Package perl.i686 4:5.10.0-87.fc12 set to be updated --- Package perl-Compress-Raw-Zlib.i686 0:2.023-87.fc12 set to be updated --- Package perl-Compress-Zlib.i686 0:2.008-87.fc12 set to be updated --- Package perl-ExtUtils-CBuilder.i686 1:0.24-87.fc12 set to be updated --- Package perl-ExtUtils-Embed.i686 0:1.28-87.fc12 set to be updated --- Package perl-ExtUtils-MakeMaker.i686 0:6.36-87.fc12 set to be updated --- Package perl-ExtUtils-ParseXS.i686 1:2.18-87.fc12 set to be updated --- Package perl-IO-Compress-Base.i686 0:2.015-87.fc12 set to be updated --- Package perl-IO-Compress-Zlib.i686 0:2.015-87.fc12 set to be updated --- Package perl-IPC-Cmd.i686 1:0.42-87.fc12 set to be updated --- Package perl-Locale-Maketext-Simple.i686 1:0.18-87.fc12 set to be updated --- Package perl-Module-Load.i686 1:0.12-87.fc12 set to be updated --- Package perl-Module-Load-Conditional.i686 0:0.30-87.fc12 set to be updated --- Package perl-Module-Pluggable.i686 1:3.90-87.fc12 set to be updated --- Package perl-Object-Accessor.i686 1:0.32-87.fc12 set to be updated --- Package perl-Params-Check.i686 1:0.26-87.fc12 set to be updated --- Package perl-Pod-Escapes.i686 1:1.04-87.fc12 set to be updated --- Package perl-Pod-Simple.i686 1:3.07-87.fc12 set to be updated --- Package perl-Test-Harness.i686 0:3.16-87.fc12 set to be updated --- Package perl-devel.i686 4:5.10.0-87.fc12 set to be updated --- Package perl-libs.i686 4:5.10.0-87.fc12 set to be updated --- Package perl-version.i686 3:0.74-87.fc12 set to be updated --- Package smartmontools.i686 1:5.39-1.fc12 set to be updated --- Package tzdata.noarch 0:2009u-1.fc12 set to be updated --- Package tzdata-java.noarch 0:2009u-1.fc12 set to be updated --- Package webkitgtk.i686 0:1.1.15.4-1.fc12 set to be updated --- Package wpa_supplicant.i686 1:0.6.8-8.fc12 set to be updated --- Package xkeyboard-config.noarch 0:1.7-2.fc12 set to be updated --- Package xorg-x11-drv-evdev.i686 0:2.3.2-2.fc12 set to be updated --- Package xorg-x11-drv-synaptics.i686 0:1.2.1-1.fc12 set to be updated --- Package xorg-x11-font-utils.i686 1:7.2-11.fc12 set to be updated -- Finished Dependency Resolution Dependencies Resolved PackageArch VersionRepository Size Updating: acli686 2.2.49-2.fc12 updates 74 k foomatic-dbnoarch 4.0-8.20091126.fc12updates 1.0 M foomatic-db-filesystem noarch 4.0-8.20091126.fc12updates 4.4 k foomatic-db-ppds noarch 4.0-8.20091126.fc12updates 19 M gnome-user-share i686 2.28.2-1.fc12 updates 599 k gtk-vnci686 0.3.10-2.fc12 updates 93 k libacl i686 2.2.49-2.fc12 updates 23 k microcode_ctl i686 1:1.17-1.57.fc12 updates 423 k netpbm i686 10.47.07-1.fc12updates 802 k perl i686 4:5.10.0-87.fc12 updates 9.7 M perl-Compress-Raw-Zlib i686 2.023-87.fc12 updates 73 k perl-Compress-Zlib i686 2.008-87.fc12 updates 38 k perl-ExtUtils-CBuilder i686 1:0.24-87.fc12 updates 39 k perl-ExtUtils-Embedi686 1.28-87.fc12 updates 24 k perl-ExtUtils-MakeMakeri686 6.36-87.fc12 updates 280 k perl-ExtUtils-ParseXS i686 1:2.18-87.fc12 updates 38 k perl-IO-Compress-Base i686 2.015-87.fc12 updates 61 k perl-IO-Compress-Zlib i686 2.015-87.fc12 updates 129 k perl-IPC-Cmd i686 1:0.42-87.fc12 updates 33 k perl-Locale-Maketext-Simplei686 1:0.18-87.fc12 updates 24 k perl-Module-Load i686 1:0.12-87.fc12 updates 21 k perl-Module-Load-Conditional
Re: Problem with latest F12 updates
Joachim Backes wrote: Anybody has the same (or similar) problem with latest F12 updates snip ERROR with rpm_check_debug vs depsolve: perl = 5.8.6 is needed by (installed) deb-1.10.27-3.i586 Complete! (1, [u'Please report this error in http://yum.baseurl.org/report']) -- if you log yum.baseurl.org, and enter; ERROR with rpm_check_debug vs depsolve: in search bar, you will get 272 hits. Installed perl on my box: perl-5.10.0-82.fc12.i686 before or after getting error message? if your error is unique, did you report error as asked to do? i had a similar error during update and found solution in second hit from yum.baseurl.org. later. -- peace out. tc,hago. g . in a free world without fences, who needs gates. ** help microsoft stamp out piracy - give linux to a friend today. ** to mess up a linux box, you need to work at it. to mess up an ms windows box, you just need to *look* at it. ** learn linux: 'Rute User's Tutorial and Exposition' http://rute.2038bug.com/index.html 'The Linux Documentation Project' http://www.tldp.org/ 'LDP HOWTO-index' http://www.tldp.org/HOWTO/HOWTO-INDEX/index.html 'HowtoForge' http://howtoforge.com/ signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Problem with latest F12 updates
Joachim Backes wrote: Anybody has the same (or similar) problem with latest F12 updates (Package deb vs. perl-5.8.6)? Total size: 42 M Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug ERROR with rpm_check_debug vs depsolve: perl = 5.8.6 is needed by (installed) deb-1.10.27-3.i586 Complete! (1, [u'Please report this error in http://yum.baseurl.org/report']) -- Installed perl on my box: perl-5.10.0-82.fc12.i686 What is deb? I could not find that in any of the fedora repositories that I've enabled. -- A snake lurks in the grass. -- Publius Vergilius Maro (Virgil) Guess Who! http://tinyurl.com/mc4xe7 signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Problem with latest F12 updates
Ed Greshko wrote: What is deb? I could not find that in any of the fedora repositories that I've enabled. http://yum.baseurl.org/search?q=deb-1.10.27-3.wiki=onchangeset=onticket=on -- peace out. tc,hago. g . in a free world without fences, who needs gates. ** help microsoft stamp out piracy - give linux to a friend today. ** to mess up a linux box, you need to work at it. to mess up an ms windows box, you just need to *look* at it. ** learn linux: 'Rute User's Tutorial and Exposition' http://rute.2038bug.com/index.html 'The Linux Documentation Project' http://www.tldp.org/ 'LDP HOWTO-index' http://www.tldp.org/HOWTO/HOWTO-INDEX/index.html 'HowtoForge' http://howtoforge.com/ signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Problem with latest F12 updates
g wrote: Ed Greshko wrote: What is deb? I could not find that in any of the fedora repositories that I've enabled. http://yum.baseurl.org/search?q=deb-1.10.27-3.wiki=onchangeset=onticket=on Too bad that doesn't answer my question -- Q: How did you get into artificial intelligence? A: Seemed logical -- I didn't have any real intelligence. Guess Who! http://tinyurl.com/mc4xe7 signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Problem with latest F12 updates -solved-
On 01/08/2010 10:54 AM, Ed Greshko wrote: Joachim Backes wrote: Anybody has the same (or similar) problem with latest F12 updates (Package deb vs. perl-5.8.6)? Total size: 42 M Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug ERROR with rpm_check_debug vs depsolve: perl = 5.8.6 is needed by (installed) deb-1.10.27-3.i586 Complete! (1, [u'Please report this error in http://yum.baseurl.org/report']) -- Installed perl on my box: perl-5.10.0-82.fc12.i686 What is deb? I could not find that in any of the fedora repositories that I've enabled. My mistake - deb was a suse package I had installed some months ago. -- Joachim Backes joachim.bac...@rhrk.uni-kl.de http://www.rhrk.uni-kl.de/~backes smime.p7s Description: S/MIME Cryptographic Signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Problem with latest F12 updates
Ed Greshko wrote: Too bad that doesn't answer my question correct, you are. i sent wrong link. this describes it's use, and probably why op installed it; http://rpmfind.rediris.es/rpm2html/suse-9.3-i586/deb-1.10.27-3.i586.html -- peace out. tc,hago. g . in a free world without fences, who needs gates. ** help microsoft stamp out piracy - give linux to a friend today. ** to mess up a linux box, you need to work at it. to mess up an ms windows box, you just need to *look* at it. ** learn linux: 'Rute User's Tutorial and Exposition' http://rute.2038bug.com/index.html 'The Linux Documentation Project' http://www.tldp.org/ 'LDP HOWTO-index' http://www.tldp.org/HOWTO/HOWTO-INDEX/index.html 'HowtoForge' http://howtoforge.com/ signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Latest updates broke KDE sound
I just updated two systems. They use different hardware, but I run primarily KDE in both. One system updated and sound worked fine. The second system lost sound in KDE. I can delete ~/.pulse and .pulse-cookie, log out, log in and have sound for that session. I can play music, get system sounds, etc. Once I log out, and back in, no sound. I can tap on the microphone and hear that in the speakers. I can run aplay /usr/share/sounds/purple/login.wav and hear that. If I log out of KDE and into GNOME, I can run any application with sound and they work fine. All sound worked fine prior to today's updates, which included the latest pulse updates. lspci: 00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2) I checked alsamixer and nothing is muted. Checked Pulse Audio Volume Control and everything looks OK there. Again, I want to emphasize that (other than no login sounds in GNOME, which I believe is a known issue) all the applications play sounds fine in GNOME. I have rebooted several times. No change to KDE. Switch back and forth with KDE, and GNOME, everything is fine in GNOME, but no login/logout sounds, or system sounds, or application sounds in KDE. Since sound is fine in GNOME, I would guess that it is some sort of configuration problem in KDE. Although I try to set up both my systems, to be indentical, within the constraints of the hardware, and sound is fine in KDE on the other system. If anyone has an idea what I can try next, please let me know. Meanwhile, I can at least run in GNOME. Thank you for any help. Lloyd -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Latest updates broke KDE sound
First let me apologize for not doing a direct reply to your email. I don't seem to be getting the mail forwarded from the list, even though I re-enabled it in my profile. So I'm hacking this to your reply. NOW, let me express my sincere appreciation to you for solving my problem. I don't know why Xine backend no longer works, but gstreamer fixed it. I added this problem to BZ #551496. I'll update that bug, with your solution. I have checked the other machine and it has Xine as the backend. Maybe after another set of updates, either to KDE or pulse, I will try switching it back. Even after 20 years of *NIX, and 10 of Linux, I keep learning. I don't mind the occasional problems, as long as there is a solution. Gotta love Linux! Thank you again, Lloyd -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Latest updates broke KDE sound
I just updated two systems. They use different
hardware, but I run
primarily KDE in both. One system updated and
sound worked fine. The
second system lost sound in KDE. I can delete
~/.pulse and .pulse-cookie,
log out, log in and have sound for that session.
I can play music, get
system sounds, etc. Once I log out, and back in,
no sound. I can tap on
the microphone and hear that in the speakers. I
can run
aplay /usr/share/sounds/purple/login.wav and hear
that. If I log out of
KDE and into GNOME, I can run any application with
sound and they work
fine. All sound worked fine prior to today's
updates, which included the
latest pulse updates.
Hi;
this happened to me.
I only run KDE, so did not test gnome.
F - apps - multimedia - pulse volume control
click the config tab.
In my case PA found my Radeon Video card and chose HDMI
I changed it back and all was ok.
I have a Radeon HD 3450 PCI Express, with NO HDMI.
Mick M
Standard guarantee applies - 30 feet or 30 seconds, whichever comes first.
# find / -name *your base* -exec chown us:us {} \;
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: How to handel spinning when i686 versions of packages don't make it into the updates repo?
On Mon, 4 Jan 2010, Mike McLean wrote: On 12/30/2009 02:05 AM, William F. Acker WB2FLW +1 303 722 7209 wrote: I've always noticed that when a package is updated, sometimes the i686 version isn't put into the x86_64 repo for updates. As a workaround, I Can you give some examples? If multilib content is inconsistent across updates then we really ought to sort that out. Just since F12: java-1.6.0-openjdk, gcc, gcc-gfortran, libgfortran, libgomp and cpp More to come, I'm sure. -- Bill in Denver -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: How to handel spinning when i686 versions of packages don't make it into the updates repo?
On 12/30/2009 02:05 AM, William F. Acker WB2FLW +1 303 722 7209 wrote: I've always noticed that when a package is updated, sometimes the i686 version isn't put into the x86_64 repo for updates. As a workaround, I Can you give some examples? If multilib content is inconsistent across updates then we really ought to sort that out. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: How to handel spinning when i686 versions of packages don't make it into the updates repo?
On 01/04/2010 11:32 AM, Jesse Keating wrote: Multilib set is dynamically determined each compose. If the package itself changes in a way that no longer triggers the multilib algorithm, then it will fall out of being multilib. Is there a mechanism to remove 'fallen' multilib packages? If not, couldn't there be update errors? For that matter, what if the lingering older multilib package contains a security flaw? My apologies if this has been discussed to death elsewhere. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
i386 yum update download stops: updates/filelists_db
Trying to do a yum makecache on my fedora 12 i386 machine and it starts downloading updates/filelists_db and the download rate gets slower and slower, from 100s of KBs/second to KBs to 100s of B/s to Bytes/seccond to 0 B/s - basically stopping. I can Control-C to restart but the same happens again. After a couple of Control-C's it switches mirrors but it still happens. Whats up? Thanks. Richard -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: i386 yum update download stops: updates/filelists_db
On Wed, Dec 30, 2009 at 1:28 PM, Rich Emberson emberson.r...@gmail.comwrote: Trying to do a yum makecache on my fedora 12 i386 machine and it starts downloading updates/filelists_db and the download rate gets slower and slower, from 100s of KBs/second to KBs to 100s of B/s to Bytes/seccond to 0 B/s - basically stopping. I can Control-C to restart but the same happens again. After a couple of Control-C's it switches mirrors but it still happens. Whats up? Just for giggles, try turning off iptables (#service iptables stop). There's some rule in the default iptables that causes FTP downloads to crawl after a while. It's bitten me before doing FTP software fetches and it's possible that one or more of the repos you have uses FTP. I've never had the time to figure out which iptables rule is causing the issue, I just disable iptables, fetch stuff and turn iptables back on. Perhaps when I'm not so busy... -- Rick Stevens, Nerd Manifique -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: i386 yum update download stops: updates/filelists_db
--- On Wed, 12/30/09, Rich Emberson emberson.r...@gmail.com wrote: Trying to do a yum makecache on my fedora 12 i386 machine and it starts downloading updates/filelists_db and the download rate gets slower and slower, from 100s of KBs/second to KBs to 100s of B/s to Bytes/seccond to 0 B/s - basically stopping. I can Control-C to restart but the same happens again. After a couple of Control-C's it switches mirrors but it still happens. Whats up? I got the same behavior with just a normal yum update on my 64-bit system. Solved it with: yum install yum-plugin-fastestmirror. Also check to see if you have yum-presto installed, too. This link will help. http://www.mjmwired.net/resources/mjm-fedora-f12.html#yum B -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Why no Samba updates?
Due to the continuing problems I'm having with Samba on my F11 box I looked to see if there are any updates, seems there are, but its not reflected in the official Fedora repo's. The latest version of one RPM I see, using yumexm, is samba-3.4.2-0.42.fc11. However there appears to be a newer one samba-3.4.3-0.44.fc11 on this site: http://rpm.pbone.net/index.php3?stat=26dist=68size=5059432name=samba-3.4.3-0.44.fc11.i586.rpm So what is going on here? The updated packages not getting into the official repo's now? I really don't want to have to chase down individual packages and install them manually when the system should be doing it for me. Regards; Leland C. Scott KC8LDO -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Why no Samba updates?
On 24/12/09 09:43, KC8LDO wrote: Due to the continuing problems I'm having with Samba on my F11 box I looked to see if there are any updates, seems there are, but its not reflected in the official Fedora repo's. The latest version of one RPM I see, using yumexm, is samba-3.4.2-0.42.fc11. However there appears to be a newer one samba-3.4.3-0.44.fc11 on this site: http://rpm.pbone.net/index.php3?stat=26dist=68size=5059432name=samba-3.4.3-0.44.fc11.i586.rpm So what is going on here? Patience http://koji.fedoraproject.org/koji/buildinfo?buildID=138883 or d\l from Koji -- Regards, Frank Murphy UTF_8 Encoded. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Why no Samba updates?
On Thu, 24 Dec 2009 09:50:50 +, Frank wrote: On 24/12/09 09:43, KC8LDO wrote: Due to the continuing problems I'm having with Samba on my F11 box I looked to see if there are any updates, seems there are, but its not reflected in the official Fedora repo's. The latest version of one RPM I see, using yumexm, is samba-3.4.2-0.42.fc11. However there appears to be a newer one samba-3.4.3-0.44.fc11 on this site: http://rpm.pbone.net/index.php3?stat=26dist=68size=5059432name=samba-3.4.3-0.44.fc11.i586.rpm So what is going on here? See yourself in the Fedora Updates System: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10966 That package is still in the updates-testing repo. Nobody has given any feedback about it yet, btw. The update description is empty. Patience http://koji.fedoraproject.org/koji/buildinfo?buildID=138883 or d\l from Koji -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Firefox not working after on line updates
On 22Dec2009 08:24, Ed Greshko ed.gres...@greshko.com wrote: | Frank Cox wrote: | On Mon, 2009-12-21 at 16:31 -0600, Brian Wood wrote: | I downloaded/built/installed a new version of sqlite, but that hasn't | helped. | | This is likely your problem. Firefox probably expects to find sqlite | installed from a Fedora rpm and not a homebuilt one. | | All this is rather strange since I did a | rpm --test -e sqlite | | There is no is needed by (installed) firefox but there is is needed | by (installed) thunderbird. | | So, it would not appear that firefox is dependent on sqlite. Well, its rpm isn't; bad rpm spec file? The bookmarks/places stuff uses an sqlite db, so firefox definitely does need sqlite from somewhere. -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Never was so much owed by so many to so few.- Winston Churchill He must have been thinking of our liquor bills. - Unknown RAF Pilot -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Firefox not working after on line updates
Cameron Simpson wrote: On 22Dec2009 08:24, Ed Greshko ed.gres...@greshko.com wrote: | Frank Cox wrote: | On Mon, 2009-12-21 at 16:31 -0600, Brian Wood wrote: | I downloaded/built/installed a new version of sqlite, but that hasn't | helped. | | This is likely your problem. Firefox probably expects to find sqlite | installed from a Fedora rpm and not a homebuilt one. | | All this is rather strange since I did a | rpm --test -e sqlite | | There is no is needed by (installed) firefox but there is is needed | by (installed) thunderbird. | | So, it would not appear that firefox is dependent on sqlite. Well, its rpm isn't; bad rpm spec file? The bookmarks/places stuff uses an sqlite db, so firefox definitely does need sqlite from somewhere. After a bit of research it doesn't appear that firefox is dependent on sqlite. However, it is dependent on xulrunner which is dependent on sqlite. FWIW, when one downloads the source of FF from mozilla.org the necessary xulrunner and sqlite components are embedded/included in the source. It seems the build rpm process for FF uses xulrunner-devel-unstable but takes the necessary sqlite bits from its own source. In other words...for file manipulation of cookies.sqlite and other db files it uses a static built sqlite. For xulrunner functions it uses dynamic libs. (Or words to that effecttoo earlyno coffee) -- Everything should be made as simple as possible, but not simpler. -- Albert Einstein Guess Who! http://tinyurl.com/mc4xe7 signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Firefox not working after on line updates
| On Mon, 2009-12-21 at 16:31 -0600, Brian Wood wrote: | I downloaded/built/installed a new version of sqlite, but that hasn't | helped. Sounds like the same problem I encountered ( https://bugzilla.redhat.com/show_bug.cgi?id=520339 ). For the time being, you can revert to the older version like so: sudo rpm -e --nodeps firefox xulrunner sudo yum install -y --disablerepo=updates firefox xulrunner ...note you'll be running Firefox w/o the latest updates, but some people need Firebug (like me). -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Updates to the F13 Marketing schedule
Hi, John! Can you (at some point - not terribly vital and can wait until after the holidays) make these changes to the Marketing schedule (http://poelstra.fedorapeople.org/schedules/f-13/f-13-marketing-tasks.html)? 1. Delete tasks 13 and 15, which refer to a deliverable (the tour) we've deprecated in favor of the one-page release notes (which serve the same intended purpose). 2. Add a task called Brief Ambassadors on upcoming release to start on 3/30 and end on 4/6. I think this should pretty much take care of the we must do them! task list for Marketing for F13 - there's a much longer log detailing more plans for the release cycle at http://meetbot.fedoraproject.org/fedora-mktg/2009-12-22/fedora-mktg.2009-12-22-20.49.html, but they're more in the area of areas of opportunity we want to keep an eye on at these points in time, so I think we'd rather keep the Marketing schedule relatively sparse for the time being. Once we finish the SOPs for each deliverable, and pick the talking points and feature profiles, we might want to add more detail for the middle month (between Alpha release and Beta release), but this is what we have for now. Thanks, --Mel -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Firefox not working after on line updates
Yesterday I allowed the system to install some security updates. Since then when I've tried to start Firefox, I get The application has been updated, but your version of SQLite is too old and the application cannot run. I downloaded/built/installed a new version of sqlite, but that hasn't helped. Any suggestions on how to resolve this? I installed lynx and tried using that to download Chrome, but ran into a problem with javascript not being supported (possibly) by lynx. tia. -- Brian Wood Ebenezer Enterprises http://www.webEbenezer.net -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Firefox not working after on line updates
On Mon, 2009-12-21 at 16:31 -0600, Brian Wood wrote: I downloaded/built/installed a new version of sqlite, but that hasn't helped. This is likely your problem. Firefox probably expects to find sqlite installed from a Fedora rpm and not a homebuilt one. -- MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Firefox not working after on line updates
Frank Cox wrote: On Mon, 2009-12-21 at 16:31 -0600, Brian Wood wrote: I downloaded/built/installed a new version of sqlite, but that hasn't helped. This is likely your problem. Firefox probably expects to find sqlite installed from a Fedora rpm and not a homebuilt one. All this is rather strange since I did a rpm --test -e sqlite There is no is needed by (installed) firefox but there is is needed by (installed) thunderbird. So, it would not appear that firefox is dependent on sqlite. -- A day without orange juice is like a day without orange juice. Guess Who! http://tinyurl.com/mc4xe7 signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
no kernel in updates-testing?
How come I don't see fresh kernel versions in updates-testing? Should I be looking elsewhere? -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: no kernel in updates-testing?
On 15/12/09 17:42, Konstantin Svist wrote: How come I don't see fresh kernel versions in updates-testing? Should I be looking elsewhere? The infrastructure just moved house. Give them a chance. -- Regards, Frank Murphy UTF_8 Encoded. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: no kernel in updates-testing?
On 12/15/2009 09:44 AM, Frank Murphy (Frankly3D) wrote: On 15/12/09 17:42, Konstantin Svist wrote: How come I don't see fresh kernel versions in updates-testing? Should I be looking elsewhere? The infrastructure just moved house. Give them a chance. Sorry, I must've missed that. What's the new infrastructure? -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: no kernel in updates-testing?
On 15/12/09 17:56, Konstantin Svist wrote: On 12/15/2009 09:44 AM, Frank Murphy (Frankly3D) wrote: On 15/12/09 17:42, Konstantin Svist wrote: How come I don't see fresh kernel versions in updates-testing? Should I be looking elsewhere? The infrastructure just moved house. Give them a chance. Sorry, I must've missed that. What's the new infrastructure? https://fedorahosted.org/fedora-infrastructure/ticket/1845 -- Regards, Frank Murphy UTF_8 Encoded. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
updates for wireless on f12 and f11 ?
There are some good wireless changes/fixes in 2.6.32 which would be
very worthwhile having in both f12 and f11. I assume it will be pushed
to f12 - yes ?
But, are there plans to make 2.6.32.1 available for f11 ?
If (yes) {
Great!!
} else {
Would it make sense to consider making the compat-wireless
package [#] available on f11 ?
}
-
[#] As posted in linux-wireless/linux-kernel
2.6.32 went out last week, based on this release we now have a
compat-wireless release [1]. You can find the wireless specific
ChangeLog at orbit [2]. This package enables usage of the 2.6.32
wireless subsystem on older kernels. For more information please refer
to its upstream wiki [3]. If you find any issues with wireless on this
package please report them [4] ASAP.
Luis
[1]
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.32/compat-wireless-2.6.32.tar.bz2
[2]
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.32/ChangeLog-2.6.32-wireless
[3] http://wireless.kernel.org/en/users/Download/stable
[4] http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
-
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Bug 546490] fontconfig updates changes my emacs font from DejaVu Sans Mono to Baekmuk Gulim
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=546490 --- Comment #6 from Jens Petersen peter...@redhat.com 2009-12-13 23:25:25 EDT --- (In reply to comment #5) How about removing baekmuk*fonts? I'm not sure what you are asking me here. Well I was mostly wondering why you have font installed. Did you install Korean support? I meant you could remove baekmuk-ttf-gulim-fonts as root with yum remove baekmuk-ttf-gulim-fonts even all baekmuk*fonts. (For Korean un-core actually provides better fonts.) That doesn't solve any supposed problem of course but might be a workaround at least. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 546490] fontconfig updates changes my emacs font from DejaVu Sans Mono to Baekmuk Gulim
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=546490 --- Comment #7 from Joseph Shraibman j...@iname.com 2009-12-14 00:14:03 EDT --- I'm not sure why the fonts are installed. This computer has been upgraded from one Fedora version to another for a long time. I just removed the fonts and remmed out the part of my .emacs that set the font and the problem went away. I then reinstalled them and the problem came back. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Re: 1 update available and no updates available
As root you can try: # yum clean all # yum check-update # yum update -- -- Grzegorz Witkowski :: gesli...@gmail.com :Gadu-Gadu: 5942122 :ICQ: 427096157 :Skype: gesirl -- 01000111 01100101 01110011 01100011 0111 0111 01100101 http://counter.li.org #239224 Registration 2001-10-29 07:19:32 -= GNU/Linux - The Experience of Freedom =- -Original Message- From: Allan Dreyer Andersen sw...@swoop.dk Reply-to: Community assistance, encouragement, and advice for using Fedora. fedora-list@redhat.com To: fedora-list@redhat.com Subject: Re: 1 update available and no updates available Date: Sun, 29 Nov 2009 23:25:15 +0100 On Sun, 29 Nov 2009 16:13:10 -0600 Hi Steve Try yum clean metadata then yum update (not upgrade). Thank you for quick answer. Clean metadate gives: Indlæste udvidelsesmoduler: presto, refresh-packagekit 32 metadata filer slettet 17 sqlite filer slettet 0 metadata filer slettet And the 'yum update' gives no update available but the little orange star still apears on my menu. -- Venlig hilsen / Best regards Allan Dreyer Andersen -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: f12 updates kernel nomodeset option breaks radeon
Hi John, My F12 worked perfectly on my ATI Technologies Inc RV350 AS [Radeon 9550] with no xorg.conf from the first day. After couple of updates compiz started crashing and xrandr stopped recognizing settings properly. I used xorg.conf for a while only as a work around. Now after couple of recent udpates, I found that it works fine again with no xorg.conf except I need to xrandr -s 0 to restore settings for my display and I had to edit settings for compiz to make it work properly again. -- -- Grzegorz Witkowski :: gesli...@gmail.com :Gadu-Gadu: 5942122 :ICQ: 427096157 :Skype: gesirl -- 01000111 01100101 01110011 01100011 0111 0111 01100101 http://counter.li.org #239224 Registration 2001-10-29 07:19:32 -= GNU/Linux - The Experience of Freedom =- -Original Message- From: Skunk Worx skunkw...@verizon.net Reply-to: Community assistance, encouragement, and advice for using Fedora. fedora-list@redhat.com To: For users of Fedora Core releases fedora-list@redhat.com Subject: f12 updates kernel nomodeset option breaks radeon Date: Sun, 29 Nov 2009 16:27:59 -0800 After updates today my radeon driver does not start properly if the kernel nomodeset option is used. The X log has a message : Couldn't find valid PLL dividers Good news though in other areas : --I can shell into the machine with ssh, it's not a hard crash. --If I set up the kernel with rhgb quiet and do not use the nomodeset option X starts up normally. --I no longer need an xorg.conf with XAA accel enabled to prevent X crashes. EXA seems to be working reliably now. (I previously reported that www.newegg.com and wiki.centos.org were crashing X with EXA enabled.) EXA seems stable with kernel modesetting though...great! Smolt : http://www.smolts.org/client/show/pub_2eb94c68-e819-4003-aa96-47783092c4ab --- John -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
After Fedora 12 kernel updates, grub doesn't remember previous settings
After each new kernel update in Fedora 12 x86_64 , default time out is reset to 15secs and freshly installed kernel is set as default. Since the proprietary WLAN drivers from RPMFusion comes one or two days after each kernel update, after each kernel update I have to manually edit settings for grub bootloader. In Fedora 11 I did not have this issue. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Bug 546490] fontconfig updates changes my emacs font from DejaVu Sans Mono to Baekmuk Gulim
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=546490
--- Comment #4 from Joseph Shraibman j...@iname.com 2009-12-11 09:38:58 EDT
---
yum.log:
Dec 10 15:27:07 Updated: fontconfig.x86_64 2.8.0-1.fc11
Dec 10 15:27:08 Updated: net-snmp-libs.x86_64 1:5.4.2.1-13.fc11
Dec 10 15:27:10 Updated: kernel-firmware.noarch 2.6.30.9-102.fc11
Dec 10 15:27:13 Updated: net-snmp.x86_64 1:5.4.2.1-13.fc11
Dec 10 15:27:14 Updated: ntfs-3g.x86_64 2:2009.11.14-2.fc11
Dec 10 15:27:15 Updated: rsync.x86_64 3.0.6-1.fc11
Dec 10 15:28:19 Installed: kernel-devel.x86_64 2.6.30.9-102.fc11
Dec 10 15:29:15 Updated: kernel-doc.noarch 2.6.30.9-102.fc11
Dec 10 15:29:16 Updated: flash-plugin.i386 10.0.42.34-release
Dec 10 15:29:21 Updated: kernel-headers.x86_64 2.6.30.9-102.fc11
Dec 10 15:29:21 Updated: mobile-broadband-provider-info.noarch
1.20090918-1.fc11
Dec 10 15:30:17 Installed: kernel.x86_64 2.6.30.9-102.fc11
Dec 10 15:30:21 Updated: fontconfig.i586 2.8.0-1.fc11
Dec 10 15:30:22 Installed: kmod-kqemu-2.6.30.9-102.fc11.x86_64.x86_64
1.4.0-0.2.pre1.fc11.23
Dec 10 15:30:23 Installed: kmod-nvidia-2.6.30.9-102.fc11.x86_64.x86_64
190.42-1.fc11.3
Dec 10 15:30:26 Updated: fontconfig-devel.x86_64 2.8.0-1.fc11
Dec 10 15:30:26 Updated: kmod-nvidia.x86_64 190.42-1.fc11.3
Dec 10 15:30:27 Updated: kmod-kqemu.x86_64 1.4.0-0.2.pre1.fc11.23
Dec 10 15:30:33 Erased: kmod-nvidia-2.6.30.9-90.fc11.x86_64
Dec 10 15:30:45 Erased: kmod-kqemu-2.6.30.9-90.fc11.x86_64
[...@jks-desktop ~]{f11}$ fc-match -v monospace
Pattern has 33 elts (size 48)
family: DejaVu Sans Mono(s)
familylang: en(s)
style: Book(s)
stylelang: en(s)
fullname: DejaVu Sans Mono(s)
fullnamelang: en(s)
slant: 0(i)(s)
weight: 80(i)(s)
width: 100(i)(s)
size: 12(f)(s)
pixelsize: 12.5(f)(s)
spacing: 100(i)(s)
foundry: unknown(s)
antialias: FcTrue(w)
hintstyle: 2(i)(w)
hinting: FcTrue(w)
verticallayout: FcFalse(s)
autohint: FcFalse(s)
globaladvance: FcTrue(s)
file: /usr/share/fonts/dejavu/DejaVuSansMono.ttf(s)
index: 0(i)(s)
outline: FcTrue(s)
scalable: FcTrue(s)
dpi: 75(f)(s)
rgba: 5(i)(w)
scale: 1(f)(s)
charset:
: 7fff
0001: e00f
f371ffcf
0002: fff3 3033 fbff 7fcf33c3
000843ff
0003: 0108 4432 d7f0 fffb 7fff
0003
0004: 000c 0fff 0c0ffc0c 999f
03ff
0005: 3c03
0006: 882016c0 07fe 043f ce103fff 010200d9 40008210 1000
03ff
000e: fef02596 1bffecae 3f00
0010:
1fff
001d: e0d00304 dfff7000 0fff 0980003c f820 feff
001e: ff0f 3fff fff00fff f00f 8bff 33c33003 3f003cc0
033fcf3f
001f: 3f3f aaff3f3f 3fff ffdf efcfffdf
7fdc
0020: ffbf07ff 76ff804f 83e0 fff3 001f7fff 003f
0021: 26e0e024 4c54 fff8
0022: ffaebfff 3f003f81 fffe e3ff ffe78fff 0003 fc002060
83ff
0023: f33fff7f 7fa009e3 df9d3b9e 27f9fb39 f8200f0f 7fff c000
0024: 0008
Reminder: Tomorrow is the last F10 updates push
Hi All, Just a friendly reminder that Dec 11 00:00:00 UTC is the cutoff for F10 updates submission. Ideally these would just be the final stable updates, as pushes to updates-testing would basically be stuck there forever. Please take a few moments to review your pending requests, add any final stable updates you'd like pushed, and clear out any update requests that don't make much sense for a soon to be EOL'd distro. josh ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Wed, 2009-12-09 at 12:20 -0700, Linuxguy123 wrote: On Wed, 2009-12-09 at 18:36 +0100, Kevin Kofler wrote: Linuxguy123 wrote: I have logged 2 bugs that are possibly related to this. https://bugzilla.redhat.com/show_bug.cgi?id=528188 https://bugzilla.redhat.com/show_bug.cgi?id=525767 Huh? One of these is a Nouveau bug, the other is a bug in the proprietary nvidia driver, both of them already happened with F12 as released, so these have absolutely nothing to do with this thread. That is what you say. How exactly did you determine that ? OR are you guessing ? The fact that it only broke for the reporter with an update from three days ago, but you had those problems in September and October. Seems pretty clear. It's not even the same problem description. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Wed, 9 Dec 2009 11:12:07 +0200 (EET) Pekka Savola wrote: Now gdm login however doesn't show my username and fingerprint login is no longer an option Looks like the issue with hal-0.5.14-1: https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12840 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Wed, 2009-12-09 at 10:36 +0100, Michal Schmidt wrote: On Wed, 9 Dec 2009 11:12:07 +0200 (EET) Pekka Savola wrote: Now gdm login however doesn't show my username and fingerprint login is no longer an option Looks like the issue with hal-0.5.14-1: https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12840 I think it has something to do with display power management and the monitor brightness level. I can replicate the behavior by simply adjusting the display brightness in a KDE session. I have logged 2 bugs that are possibly related to this. https://bugzilla.redhat.com/show_bug.cgi?id=528188 https://bugzilla.redhat.com/show_bug.cgi?id=525767 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Wed, 2009-12-09 at 06:27 -0700, Linuxguy123 wrote: On Wed, 2009-12-09 at 10:36 +0100, Michal Schmidt wrote: On Wed, 9 Dec 2009 11:12:07 +0200 (EET) Pekka Savola wrote: Now gdm login however doesn't show my username and fingerprint login is no longer an option Looks like the issue with hal-0.5.14-1: https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12840 I think it has something to do with display power management and the monitor brightness level. I can replicate the behavior by simply adjusting the display brightness in a KDE session. I have logged 2 bugs that are possibly related to this. https://bugzilla.redhat.com/show_bug.cgi?id=528188 https://bugzilla.redhat.com/show_bug.cgi?id=525767 I recommend connecting an external monitor to see if the issue is display specific and have you tried ctrl-alt-F6 to get to a console at login and then going back to the X session with ctrl-alt-F1 ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
Linuxguy123 wrote: I have logged 2 bugs that are possibly related to this. https://bugzilla.redhat.com/show_bug.cgi?id=528188 https://bugzilla.redhat.com/show_bug.cgi?id=525767 Huh? One of these is a Nouveau bug, the other is a bug in the proprietary nvidia driver, both of them already happened with F12 as released, so these have absolutely nothing to do with this thread. These bugs filed by Rex Dieter about issues caused by HAL 0.5.14 are probably more relevant: https://bugzilla.redhat.com/show_bug.cgi?id=545258 https://bugzilla.redhat.com/show_bug.cgi?id=545639 Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Wed, 2009-12-09 at 18:36 +0100, Kevin Kofler wrote: Linuxguy123 wrote: I have logged 2 bugs that are possibly related to this. https://bugzilla.redhat.com/show_bug.cgi?id=528188 https://bugzilla.redhat.com/show_bug.cgi?id=525767 Huh? One of these is a Nouveau bug, the other is a bug in the proprietary nvidia driver, both of them already happened with F12 as released, so these have absolutely nothing to do with this thread. That is what you say. How exactly did you determine that ? OR are you guessing ? I say they have similar symptoms. I said they *might* be related. I bet my bugs have nothing to do with the nouveau or nvidia drivers. I've been saying that all along. I guess we will find out. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
F12 updates-testing issue: X flickers and fails to start
Hi, On my laptop, after F12 updates-testing update today, after reboot F logo shows but then the screen goes dark and starts flickering between various shades of dark (changing modes?) with intel graphics chipset (GM965/GL960). I'm only using 1024x768 resolution. Nomodeset or using a previous kernel didn't help. Booting to runlevel 3 and running system-config-display (--reconfig) resulted in the same. I've worked around the issue by yum history undo 1 which rolled back a couple of hundred packages. Any idea which package could be the culprit and I should file a bug against or to isolate it? Somehow I don't think this is necessarily an Xorg base or driver issue. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Tue, 2009-12-08 at 10:33 +0200, Pekka Savola wrote: Hi, On my laptop, after F12 updates-testing update today, after reboot F logo shows but then the screen goes dark and starts flickering between various shades of dark (changing modes?) with intel graphics chipset (GM965/GL960). I'm only using 1024x768 resolution. Nomodeset or using a previous kernel didn't help. Booting to runlevel 3 and running system-config-display (--reconfig) resulted in the same. I've worked around the issue by yum history undo 1 which rolled back a couple of hundred packages. Any idea which package could be the culprit and I should file a bug against or to isolate it? Somehow I don't think this is necessarily an Xorg base or driver issue. I'd start with xorg-x11-drv-intel. Update to the package set that caused the problem, then for the bug report attach the output of 'dmesg', your entire /var/log/Xorg.0.log file, and the output of 'lspci -nv'. Also indicate your kernel version, the version of xorg-x11-server-Xorg, and the version of xorg-x11-drv-intel. Dan -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Tue, 2009-12-08 at 01:50 -0800, Dan Williams wrote: On Tue, 2009-12-08 at 10:33 +0200, Pekka Savola wrote: Hi, On my laptop, after F12 updates-testing update today, after reboot F logo shows but then the screen goes dark and starts flickering between various shades of dark (changing modes?) with intel graphics chipset (GM965/GL960). I'm only using 1024x768 resolution. Nomodeset or using a previous kernel didn't help. Booting to runlevel 3 and running system-config-display (--reconfig) resulted in the same. I've worked around the issue by yum history undo 1 which rolled back a couple of hundred packages. Any idea which package could be the culprit and I should file a bug against or to isolate it? Somehow I don't think this is necessarily an Xorg base or driver issue. I'd start with xorg-x11-drv-intel. Update to the package set that caused the problem, then for the bug report attach the output of 'dmesg', your entire /var/log/Xorg.0.log file, and the output of 'lspci -nv'. Also indicate your kernel version, the version of xorg-x11-server-Xorg, and the version of xorg-x11-drv-intel. kernel is probably first up nowadays to blame for GPU bugs. File bugs against the X drivers generally though is easier for us to find them, kernel bug triage can be a long process. Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Thu, 2009-12-03 at 06:51 +0100, Ralf Corsepius wrote: We wouldn't be talking about removing the original GA set - just adding updated pkgs into the path. Woa!!! With all due respect, but this would seem an stupid and silly plan to me. The only way not to do that would be to maintain yet another directory of packages that matches the GA set, for GPL compliance. Now we're just getting silly. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/03/2009 07:22 AM, Jesse Keating wrote: On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: People doing network installs can either add the updates repo to their kickstart, or check the box in the anaconda UI, so that the updates repos are considered at install time. No download of duplicate data. Yes, for people who are doing full featured networked installs w/ custom kickstart files. I've never met such a person. Really? I meet people who use kickstart all the time. May-be internal at RH? Any sizable deployment of Fedora/RHEL uses or should use kickstart. And those that don't aren't afraid to check that little 'updates' box at the software selection screen. You seemed to have ignored that part of my point. No, I didn't. It's just that unless this little check button is the default, many users will ignore it or as in my case ... I am normally yum-upgrading between distros and rarely use anaconda. In fact, having separate repos would likely cost less bandwidth. If we only had one combined repo, there would be many duplicate packages, Where? Unlike now, where you have each package twice (in Everything and updates), you would have each package only once: In Everything. That assumes we purge anything but the latest version of a package, Correct. which as noted in other parts of this thread gets complicated with GPL compliance. Not necessarily - E.g. it would be GPL compliant to store purged packages outside of the current repos. And whether spins and the way they currently are implemented is good/feasible/reasonable is a different question. = An estimate for the increase in downloaded files's sizes you are talking about is ca. factor 2, from 18.2M (current updates) to 32.8M+ (current Everything+newly introduced packages) Whether this increase in download-size is significant is up to the beholder. For me, it gets lost in the noise of accessing a good or a bad connection to a mirror and in the time required to download packages from mirrors. 33~ megs downloaded every single time an update is pushed is a significant hit for a fair number of people. Yes, but ... some more figures: The same figures as above for FC10: = Everything: 25.8M = updates: 18.5M = A rough estimate for sizes of repodata for a near EOL'ed Fedora: 70% of the size of Everything's repodata. I.e. should this estimate apply to later Fedoras, Fedora 11 users are likely to see 70% of 33MB = 23MB near EOL of Fedora 11. That was why it was important to make yum not re-fetch that repodata every time, and use a cached version of it. Yes, the keys to minimize bandwidth demands would be * to shink the size of the repodata/-files * to shink the size of changes to them. Besides obvious solutions, such as using a different compression (e.g. xz instead of bz2) and minimizing their contents, one could ship repodata/-files in chunks. What I mean: In theory, one could * update repodata/-files incrementally by shipping some kind of deltas. * split repodata/-files into several, e.g. sorted by some other criteria, i.e. to provide several sets of *-[primary,filelist,other] files. One package push, then would only affect a subset of the files, but not all. - This is very similar to what (IIRC) Seth had proposed (Split the repo into several repos, alphabetically), except that the split would happen inside of repodata and thus be transparent to users. I am not sure how difficult to implement this would be. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Fri, December 4, 2009 9:20 pm, Ralf Corsepius wrote: On 12/03/2009 07:22 AM, Jesse Keating wrote: On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: Yes, for people who are doing full featured networked installs w/ custom kickstart files. I've never met such a person. Really? I meet people who use kickstart all the time. May-be internal at RH? I do every install via kickstart - small company with 30-50 machines. Been doing fedora+everything+updates installs for many releases now. In fact - every upgrade is a fresh kickstart install + restore critical files from backup. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/05/2009 06:22 AM, Orion Poplawski wrote: On Fri, December 4, 2009 9:20 pm, Ralf Corsepius wrote: On 12/03/2009 07:22 AM, Jesse Keating wrote: On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: Yes, for people who are doing full featured networked installs w/ custom kickstart files. I've never met such a person. Really? I meet people who use kickstart all the time. May-be internal at RH? I do every install via kickstart - small company with 30-50 machines. Been doing fedora+everything+updates installs for many releases now. OK, then it's likely a full time professional admins vs. part time/side-job admins and home-users thing. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
UPDATE: Final F-10 updates push date revised
On Tue, Nov 24, 2009 at 08:31:35PM -0500, Josh Boyer wrote: Hi All, Fedora 10 will go EOL on December 17th. The final day for updates to be submitted will be December 14th. Please make sure any final updates you want pushed to the F10 repos are submitted by this date. Due to the infrastructure outage that has been scheduled for this timeframe, the final F10 updates push has now been rescheduled for December 11th, 2009. Please make sure any final updates you want pushed to the F10 repos are submitted by the revised date of December 11th, 2009. Apologies for the confusion and change in schedule. We will work more closely with the Infrastructure team in the future to avoid a similar situation. josh ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Thu, 2009-12-03 at 00:32 -0500, Seth Vidal wrote: We wouldn't be talking about removing the original GA set - just adding updated pkgs into the path. So you'd still have the number of pkgs -just all in one repo, that you have to download all of the metadata for all of the more often, despite that 15K of them don't CHANGE. I don't think that was actually made clear in the initial proposal. I'd been assuming that the proposal was _exactly_ to remove the GA set. Usually, when a newer package shows up in any given repository, we don't keep the previous version of the package, do we? So I assumed the proposal was expecting that behaviour for the combined repository. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
* Adam Williamson [03/12/2009 10:10] : I don't think that was actually made clear in the initial proposal. I'd been assuming that the proposal was _exactly_ to remove the GA set. No can do. People who install from the netinst CD or do PXE installs without adding the updates repo during the installation would be unable to finish it. Emmanuel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
Le Mer 2 décembre 2009 23:56, Matt Domsch a écrit : On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) Sorry, I don't understand this. Can you elaborate? That would help me scope the impact to MirrorManager. Right now the same package moves from master URL to master URL as it is pushed from testing to updates to GA to whatever. That means the same package gets downloaded many times over because it changed URL (and browsers, proxies, etc understand new url = new file) My proposal is to never move a package, put it in a single unchanging place after a koji build, and just index it or not in the relevant repodata when it gets promoted or demoted. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Thu, 3 Dec 2009, Adam Williamson wrote: On Thu, 2009-12-03 at 00:32 -0500, Seth Vidal wrote: We wouldn't be talking about removing the original GA set - just adding updated pkgs into the path. So you'd still have the number of pkgs -just all in one repo, that you have to download all of the metadata for all of the more often, despite that 15K of them don't CHANGE. I don't think that was actually made clear in the initial proposal. I'd been assuming that the proposal was _exactly_ to remove the GA set. Usually, when a newer package shows up in any given repository, we don't keep the previous version of the package, do we? So I assumed the proposal was expecting that behaviour for the combined repository. From a QA standpoint I'd think you'd want at least one known-installable set of pkgs. Since everything after the original GA set is a giant questionmark. Not to mention that removing all the old pkgs would more or less make deltarpms very difficult. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Thu, 2009-12-03 at 10:29 +0100, Nicolas Mailhot wrote: Le Mer 2 décembre 2009 23:56, Matt Domsch a écrit : On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) Sorry, I don't understand this. Can you elaborate? That would help me scope the impact to MirrorManager. Right now the same package moves from master URL to master URL as it is pushed from testing to updates to GA to whatever. That means the same package gets downloaded many times over because it changed URL (and browsers, proxies, etc understand new url = new file) It only moves once, at least in the vast majority of cases. My proposal is to never move a package, put it in a single unchanging place after a koji build, and just index it or not in the relevant repodata when it gets promoted or demoted. One problem is that atm. when it moves from testing to updates, or rawhide to GA, it also gets resigned with a different key ... so the bits are not the same. Having the URL be the same will not be helpful until that changes. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
I think that idea maybe isn't benefit with repository. If updates repository is merged into Everything repository, Will metadata files become too large? I know that the size of metadatas on updates and everything are more than 30 megabytes. If these two repositories compose, We will need download more than 30MB files before updating. I believe that it will decrease the advantage of delrarpm update. It will increase more time to download the files. Is there any way to make createrepo generate delta metadata files? Just like delta rpm, we just need to get what meta files are changed, then yum generates the entire metadata files. We exactly not need and want to download the big files. Additionally, if an user is far away from repository server, though ISP provides quite a good 10Mbps connection, it is still quite slow to install some big applications, such OpenOffice.org, Eclipse, Netbeans, KOffice and some 3D games. Does yum allow to download more than one rpm files with only one thread per files after checking dependencies? Or using a yum plugin to replace yum default downloader by axel to download one rpm files with multi threads. I ever found out this kind of plugin, but I can assure it can run in Fedora 12. -- My Page: http://www.liangsuilong.info Fedora Project Contributor -- Packager Ambassador https://fedoraproject.org/wiki/User:Liangsuilong -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Dec 3, 2009, at 5:28, James Antill ja...@fedoraproject.org wrote: On Thu, 2009-12-03 at 10:29 +0100, Nicolas Mailhot wrote: Le Mer 2 décembre 2009 23:56, Matt Domsch a écrit : On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) Sorry, I don't understand this. Can you elaborate? That would help me scope the impact to MirrorManager. Right now the same package moves from master URL to master URL as it is pushed from testing to updates to GA to whatever. That means the same package gets downloaded many times over because it changed URL (and browsers, proxies, etc understand new url = new file) It only moves once, at least in the vast majority of cases. My proposal is to never move a package, put it in a single unchanging place after a koji build, and just index it or not in the relevant repodata when it gets promoted or demoted. One problem is that atm. when it moves from testing to updates, or rawhide to GA, it also gets resigned with a different key ... so the bits are not the same. Having the URL be the same will not be helpful until that changes. -- That is no longer true. We used a single key for all of f11 and a single key for all of f12. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Thu, 2009-12-03 at 08:20 -0500, Seth Vidal wrote: We wouldn't be talking about removing the original GA set - just adding updated pkgs into the path. So you'd still have the number of pkgs -just all in one repo, that you have to download all of the metadata for all of the more often, despite that 15K of them don't CHANGE. I don't think that was actually made clear in the initial proposal. I'd been assuming that the proposal was _exactly_ to remove the GA set. Usually, when a newer package shows up in any given repository, we don't keep the previous version of the package, do we? So I assumed the proposal was expecting that behaviour for the combined repository. From a QA standpoint I'd think you'd want at least one known-installable set of pkgs. Since everything after the original GA set is a giant questionmark. Not to mention that removing all the old pkgs would more or less make deltarpms very difficult. I'm not saying I support the proposal, I don't, I think it's a waste of effort for no benefit. I was just clarifying the initial characterization. Actually I think the initial proposer _was_ expecting to remove initial packages when updates become available, because they keep saying stuff like 'only historians are interested in the GA packages'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/03/2009 12:24 AM, Ralf Corsepius wrote: On 12/02/2009 06:40 PM, Jesse Keating wrote: People doing network installs can either add the updates repo to their kickstart, or check the box in the anaconda UI, so that the updates repos are considered at install time. No download of duplicate data. Yes, for people who are doing full featured networked installs w/ custom kickstart files. I've never met such a person. Really? This very much seems to me like it's a vast majority of kickstarts that happen. -- Peter Power corrupts. Absolute power is kind of neat. -- John Lehman, Secretary of the Navy, 1981-1987 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/03/2009 08:20 AM, Seth Vidal wrote: On Thu, 3 Dec 2009, Adam Williamson wrote: On Thu, 2009-12-03 at 00:32 -0500, Seth Vidal wrote: We wouldn't be talking about removing the original GA set - just adding updated pkgs into the path. So you'd still have the number of pkgs -just all in one repo, that you have to download all of the metadata for all of the more often, despite that 15K of them don't CHANGE. I don't think that was actually made clear in the initial proposal. I'd been assuming that the proposal was _exactly_ to remove the GA set. Usually, when a newer package shows up in any given repository, we don't keep the previous version of the package, do we? So I assumed the proposal was expecting that behaviour for the combined repository. From a QA standpoint I'd think you'd want at least one known-installable set of pkgs. Since everything after the original GA set is a giant questionmark. Not to mention that removing all the old pkgs would more or less make deltarpms very difficult. Well, if we're talking about removing them from Fedora/ but leaving them in Everything/ (am I understanding the current form of the proposal correctly?), then it's not really significantly more difficult, but it is one more process that needs modification in order to enact such a plan. -- Peter If the facts don't fit the theory, change the facts. -- Einstein -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 09:12 PM, Kevin Kofler wrote: Seth Vidal wrote: If you're looking for perfect division, sure - but the reality is this: 19K items in a single dir and ext3 and nfs and many many other things crap themselves returning that list. If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for producing the same list of files. The problem is, a few of those starting letters still correspond to A LOT of packages, e.g. p* matches perl-*, python-* and php-* and that's a lot of stuff (especially Perl and Python). And adding python3-* (and perl6-*, or are we going to use the rakudo-* namespace there?) won't make it any less. Even still, separating p out to a subdirectory means that subdirectory has an order of magnitude fewer files than the previous way. That's a really big difference. -- Peter If the facts don't fit the theory, change the facts. -- Einstein -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Proposed F13 feature: drop separate updates repository
The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. The package set at release time is only interesting to historians. If any of them are really that bothered, I'm sure somebody can come up with a yum module which finds the oldest available version of a package in a repo. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. The package set at release time is only interesting to historians. If any of them are really that bothered, I'm sure somebody can come up with a yum module which finds the oldest available version of a package in a repo. Matt Would not this also provide the minor added benefit that there could now be a drpm for the first update for a package? -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 03:39 PM, Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. The package set at release time is only interesting to historians. If any of them are really that bothered, I'm sure somebody can come up with a yum module which finds the oldest available version of a package in a repo. So your proposal is to drop updates, but to add updates to Everything? In this case, I am all for it. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 09:00:53AM -0600, Jon Ciesla wrote: Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. The package set at release time is only interesting to historians. If any of them are really that bothered, I'm sure somebody can come up with a yum module which finds the oldest available version of a package in a repo. Matt Would not this also provide the minor added benefit that there could now be a drpm for the first update for a package? We already have that if the update is done after GA. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. And how do you propose to do that? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 02/12/09 15:26, Josh Boyer wrote: On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. And how do you propose to do that? Unfortunately I'm not intimately familiar with Fedora infrastructure under-the-hood. However, I would hope that, technically at least, it wouldn't be much more than a systematic removal of all updates repositories and redirecting files which would have gone into them into the main repositories instead. This stems from the observation that if you copied everything from the main repository into updates you would have created the repository which people unfamiliar with the history would expect. The infrastructure side of this, on the face of it, sounds very simple. More involved would be: 1. Updating all packages which expect 2 repos to only expect 1. 2. Communicating the change effectively. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
Josh Boyer wrote: On Wed, Dec 02, 2009 at 09:00:53AM -0600, Jon Ciesla wrote: Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. The package set at release time is only interesting to historians. If any of them are really that bothered, I'm sure somebody can come up with a yum module which finds the oldest available version of a package in a repo. Matt Would not this also provide the minor added benefit that there could now be a drpm for the first update for a package? We already have that if the update is done after GA. josh If that's the case, then good. In that case, I see no huge benefit to leaving it or changing it. -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 03:44:08PM +, Matthew Booth wrote: On 02/12/09 15:26, Josh Boyer wrote: On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. And how do you propose to do that? Unfortunately I'm not intimately familiar with Fedora infrastructure under-the-hood. However, I would hope that, technically at least, it wouldn't be much more than a systematic removal of all updates repositories and redirecting files which would have gone into them into the main repositories instead. This stems from the observation that if you copied everything from the main repository into updates you would have created the repository which people unfamiliar with the history would expect. The infrastructure side of this, on the face of it, sounds very simple. What you describe is effectively how the development repository is built, so it's certainly a technical possibility. It does have implications though. Off the top of my head, I can think of: 1) Composing a new everything tree for updates would lead to larger compose times. That could possibly mean that getting updates out would take 1 day per 'push'. We've been trying to improve updates push times so it would be a bit detrimental to that goal. 2) There might be GPL compliance issues 3) You would still need an 'updates-testing' repository given that this is a supposedly stable release. So there is still going to be at least one additional repo regardless. However, other than 'browsing manually for packages', I'm not really sure what problem you are trying to solve by getting rid of the updates repository. It would seem like this has quite a bit of cost for relatively little to no real gain? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
2009/12/2 Justin M. Forbes jmfor...@linuxtx.org The only downside to merging updates into the main repository... I would also assume that the repo data will need to be regenerated and often be much larger than the one that is for the updates only repository, so there will be acost to end users with this proposed change? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 10:01:51AM -0600, Justin M. Forbes wrote: On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. The only downside to merging updates into the main repository is that network installs from the repository will no longer install the release they will install the updated release. QA that goes into that first impression is no longer there, and your installs are not repeatable because installing system A on one day and system B on another could end up with different versions of packages. Of course you can always install from the ISOs to avoid these problems. As things are, you have the choice of the release as it was, or the updated release at install time. I am not saying that this is a bad idea, in fact I rather like it, but there are things to consider. I think this is quite a compelling reason not to touch it. Much as we'd like the updates repository to always be perfectly stable, there are still plenty of occassions when we hit problems with updates. Being able to reliably install the release at all times is pretty critical saying we should install off ISO if we want a reliable install is not really an acceptable alternative since many people do all their installs straight off the network. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote: Matthew Booth (mbo...@redhat.com) said: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. The package set at release time is only interesting to historians. If any of them are really that bothered, I'm sure somebody can come up with a yum module which finds the oldest available version of a package in a repo. The separate Everything tree that does not get obsoleted is required in some form for GPL compliance, with respect to the ISO images that we ship. Any new solution would have to preserve this. Might there also be export compliance implications too? -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 02 Dec 2009 17:27:17 +0100 Ralf Corsepius rc040...@freenet.de wrote: On 12/02/2009 05:09 PM, Bill Nottingham wrote: Matthew Booth (mbo...@redhat.com) said: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. The package set at release time is only interesting to historians. If any of them are really that bothered, I'm sure somebody can come up with a yum module which finds the oldest available version of a package in a repo. The separate Everything tree that does not get obsoleted is required in some form for GPL compliance, with respect to the ISO images that we ship. Isn't this the Fedora repo? To my knowledge the Fedora repos corresponds 1:1 to the isos. To the DVD iso, yes. To any of the spins/desktop/live... nope. They use packages from Everything/ kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
Ralf Corsepius (rc040...@freenet.de) said: Does the FSF/GPL demand to keep a repo around for ISOs? A rolling Everything would not touch the ISOs. They would still be around. The LiveCD/spins satisfy their source requirements via the source repositories; they do not compose separate live source images. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 11:28:24AM -0500, Paul W. Frields wrote: The separate Everything tree that does not get obsoleted is required in some form for GPL compliance, with respect to the ISO images that we ship. Any new solution would have to preserve this. Might there also be export compliance implications too? What manner of export issues? This change doesn't, afaik, affect where export-restricted software appears in any way. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 11:06:22AM -0500, Josh Boyer wrote: 1) Composing a new everything tree for updates would lead to larger compose times. That could possibly mean that getting updates out would take 1 day per 'push'. We've been trying to improve updates push times so it would be a bit detrimental to that goal. This might be a good opportunity to look at some way of pushing incremental sets of packages rather than re-building the entire yum repo each time. Mashing is not a cheap operation. 2) There might be GPL compliance issues 3) You would still need an 'updates-testing' repository given that this is a supposedly stable release. So there is still going to be at least one additional repo regardless. We have tags for updates that mark them as bugfix/feature/security. Maybe we could have one for testing which would keep yum from installing the package unless explicitly asked or specially configured. However, other than 'browsing manually for packages', I'm not really sure what problem you are trying to solve by getting rid of the updates repository. It would seem like this has quite a bit of cost for relatively little to no real gain? This is true. I don't know that manual package browsing is a use case we've ever been interested in, and if we're going to be interested in it there's probably a better way (search engine in the Fedora community portal comes to mind). josh You owe me $5. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2 Dec 2009, Paul W. Frields wrote: On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote: we ship. Any new solution would have to preserve this. Might there also be export compliance implications too? A larger isssue is constantly having the repodata for the everything repo be: 1. growing 2. changing So now instead of having a 15K pkg repo that never changes you have an ever-growing repo that never shrinks in size that changes what? 3 times a week? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 06:01 PM, Casey Dahlin wrote: On Wed, Dec 02, 2009 at 11:06:22AM -0500, Josh Boyer wrote: However, other than 'browsing manually for packages', I'm not really sure what problem you are trying to solve by getting rid of the updates repository. It would seem like this has quite a bit of cost for relatively little to no real gain? This is true. It is not true. * It shifts costs from users to vendor and from mirrors to master. * It helps users who are using networked installs to spare bandwidth (avoids downloading obsolete packages from Everything/Fedora). Admitted, for most users, it would change almost nothing. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 02/12/09 16:01, Justin M. Forbes wrote: On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. The only downside to merging updates into the main repository is that network installs from the repository will no longer install the release they will install the updated release. QA that goes into that first impression is no longer there, and your installs are not repeatable because installing system A on one day and system B on another could end up with different versions of packages. Of course you can always install from the ISOs to avoid these problems. As things are, you have the choice of the release as it was, or the updated release at install time. I am not saying that this is a bad idea, in fact I rather like it, but there are things to consider. That's not a bug, it's a feature! Seriously, wasn't it a specific F10 or F11 feature that anaconda allowed the user to specify that updates be installed at installation time? Certainly I used to have Debianites crow at me that my installation was vulnerable until I updated it. Not only that, but I had to download updated packages twice. These days I always install with updates. I find the installation argument dubious at best. Still, we could rename the main repo the 'installation' repo, and nothing but anaconda would ever look at it. Everything else would look at the main repo, which would be the same as the current updates repo except with everything in it from the start. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 02/12/09 16:09, Bill Nottingham wrote: Matthew Booth (mbo...@redhat.com) said: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. The package set at release time is only interesting to historians. If any of them are really that bothered, I'm sure somebody can come up with a yum module which finds the oldest available version of a package in a repo. The separate Everything tree that does not get obsoleted is required in some form for GPL compliance, with respect to the ISO images that we ship. Any new solution would have to preserve this. This argument sounds weird to me. However, there no reason you can't keep around as many repositories as you like as long as the One True Repository exists and people can use it exclusively. Currently it doesn't exist. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
Once upon a time, Matthew Booth mbo...@redhat.com said: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. Are these really significant issues for a significant number of users? Not many people go looking manually for packages, since there are many tools to do it easier (yum, PK, repoquery, etc.). The repos are automatically configured with fedora-release; how often are you configuring yum? The only time I have to care about this is if I'm writing a kickstart file, but it is one extra line (and then I copy the same kickstart base over and over). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2 Dec 2009, Nicolas Mailhot wrote: Since people are posting wishes, here is mine: 1. stop shuffling packages from directory to directory as they get promoted/demoted from release to release we sort of do this now with hardlinks - the problem is when we have to resign the pkgs. 2. have a single authoritative URL for each package packagedb... 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) I don't think that would work fine with a lot of our mirrors. 4. generate indexes of the kojipkgs.fedoraproject.org tree that represent Fedora X, Fedora X + updates, Fedora X + testing, etc. this is intriguing but expensive on kojipkgs. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote: Isn't this, eventually, what the packagedb is supposed to be able to do? I gather it's a ls in a directory kind of thing, not an interface to one tool or another kind of thing. But I could be wrong. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
Dne 2.12.2009 17:06, Josh Boyer napsal(a): However, other than 'browsing manually for packages', I'm not really sure what problem you are trying to solve by getting rid of the updates repository. It would seem like this has quite a bit of cost for relatively little to no real gain? I am usually too lazy, so I use yumdownloader anyway. So, I really don't see any real use case covered. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC If Patrick Henry thought that taxation without representation was bad, he should see how bad it is with representation. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
(on my on tangent...) On 12/02/2009 12:48 PM, Jesse Keating wrote: I hypothesize that we could place all rpms for a given release in a single directory (seth will hate this as he wants to split them up based on first letter of their name for better filesystem performance), Ugh, first letter isn't really a great plan anyway. First (few) letters of a hash of the filename is much better, but obviously hurts browsability. Next best is probably something like how a dead-tree dictionary index works; list everything, split the list up by starting letters evenly, so the directories (given a really unlikely hypothetical package set) are 0/ # contains packages named 0 through 3* 4/ # 4 through 9* a/ # a through ay* az/ # az through bw* bx/ # bx through cz* da/ # da through whatever's next ... so that every directory has about the same number of things. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 05:03 PM, Jesse Keating wrote: On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote: Isn't this, eventually, what the packagedb is supposed to be able to do? I gather it's a ls in a directory kind of thing, not an interface to one tool or another kind of thing. But I could be wrong. Sure, but the better optimization for this is don't do it. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 03:53 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) I don't think that would work fine with a lot of our mirrors. I think it probably /could/ if we put some (relatively major) work in on the server side to make it look like the directories it isn't. Not that I'm endorsing such a plan. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 02:03:51PM -0800, Jesse Keating wrote: On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote: Isn't this, eventually, what the packagedb is supposed to be able to do? I gather it's a ls in a directory kind of thing, not an interface to one tool or another kind of thing. But I could be wrong. We're at a point where 'ls in a directory' is becoming difficult even; you can't glob 15k package names in a shell. find . is your friend. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) Sorry, I don't understand this. Can you elaborate? That would help me scope the impact to MirrorManager. Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2 Dec 2009, Peter Jones wrote: (on my on tangent...) On 12/02/2009 12:48 PM, Jesse Keating wrote: I hypothesize that we could place all rpms for a given release in a single directory (seth will hate this as he wants to split them up based on first letter of their name for better filesystem performance), Ugh, first letter isn't really a great plan anyway. First (few) letters of a hash of the filename is much better, but obviously hurts browsability. Next best is probably something like how a dead-tree dictionary index works; list everything, split the list up by starting letters evenly, so the directories (given a really unlikely hypothetical package set) are 0/ # contains packages named 0 through 3* 4/ # 4 through 9* a/ # a through ay* az/ # az through bw* bx/ # bx through cz* da/ # da through whatever's next ... so that every directory has about the same number of things. If you're looking for perfect division, sure - but the reality is this: 19K items in a single dir and ext3 and nfs and many many other things crap themselves returning that list. If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for producing the same list of files. I tested it on our backend to be sure. getting the complete pkglist goes from taking 5 minutes to take 30s. yes, I said 5 minutes. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote: The separate Everything tree that does not get obsoleted is required in some form for GPL compliance, with respect to the ISO images that we ship. Any new solution would have to preserve this. ? We provide Fedora-*-source-disc*.iso and Fedora-*-source-DVD.iso images on the mirrors already. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2 Dec 2009, Peter Jones wrote: On 12/02/2009 03:53 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) I don't think that would work fine with a lot of our mirrors. I think it probably /could/ if we put some (relatively major) work in on the server side to make it look like the directories it isn't. Not that I'm endorsing such a plan. we'd have to make all our mirrors use that. not gonna fly. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 05:58 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Peter Jones wrote: On 12/02/2009 03:53 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) I don't think that would work fine with a lot of our mirrors. I think it probably /could/ if we put some (relatively major) work in on the server side to make it look like the directories it isn't. Not that I'm endorsing such a plan. we'd have to make all our mirrors use that. not gonna fly. Well, you just wouldn't get the benefits of this if you're using a mirror. Which, yes, is pretty lame. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 05:58 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Peter Jones wrote: (on my on tangent...) On 12/02/2009 12:48 PM, Jesse Keating wrote: I hypothesize that we could place all rpms for a given release in a single directory (seth will hate this as he wants to split them up based on first letter of their name for better filesystem performance), Ugh, first letter isn't really a great plan anyway. First (few) letters of a hash of the filename is much better, but obviously hurts browsability. Next best is probably something like how a dead-tree dictionary index works; list everything, split the list up by starting letters evenly, so the directories (given a really unlikely hypothetical package set) are 0/# contains packages named 0 through 3* 4/# 4 through 9* a/# a through ay* az/# az through bw* bx/# bx through cz* da/# da through whatever's next ... so that every directory has about the same number of things. If you're looking for perfect division, sure - but the reality is this: 19K items in a single dir and ext3 and nfs and many many other things crap themselves returning that list. If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for producing the same list of files. I tested it on our backend to be sure. getting the complete pkglist goes from taking 5 minutes to take 30s. yes, I said 5 minutes. Yeah, I buy that. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2 Dec 2009, Peter Jones wrote: On 12/02/2009 05:58 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Peter Jones wrote: On 12/02/2009 03:53 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) I don't think that would work fine with a lot of our mirrors. I think it probably /could/ if we put some (relatively major) work in on the server side to make it look like the directories it isn't. Not that I'm endorsing such a plan. we'd have to make all our mirrors use that. not gonna fly. Well, you just wouldn't get the benefits of this if you're using a mirror. Which, yes, is pretty lame. we won't get the benefits in fedora then. Our mirror infrastructure is a HUGE reason why we can do what we do. If we can't farm things out to our mirrors then we might as well go home b/c our users will NEVER be able to get our bits. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2009-12-02 at 17:46 -0500, Peter Jones wrote: (on my on tangent...) On 12/02/2009 12:48 PM, Jesse Keating wrote: I hypothesize that we could place all rpms for a given release in a single directory (seth will hate this as he wants to split them up based on first letter of their name for better filesystem performance), Ugh, first letter isn't really a great plan anyway. It's not great but it's better than the current all in one dir. and easy to do, and I haven't heard of any downsides (that aren't applicable to all in one dir.). First (few) letters of a hash of the filename is much better, but obviously hurts browsability. Right, which is important enough to not do that IMO. I'm sure Jesse wouldn't like finding packages to mean using find. Next best is probably something like how a dead-tree dictionary index works; list everything, split the list up by starting letters evenly, so the directories (given a really unlikely hypothetical package set) are 0/# contains packages named 0 through 3* 4/# 4 through 9* a/# a through ay* az/ # az through bw* bx/ # bx through cz* da/ # da through whatever's next ... so that every directory has about the same number of things. This should be fairly easy to code, but has a big downside: Packages will move directories. 1. This will upset yum (old repo. MD == no packages download). 2. This might upset mirrors. 3. This will probably upset users: i. URLs will only be safe until the next mash, they won't even be able to bookmark prefix/y if they just want to see yum each time. ii. Users have to look/parse the directory layout each time they visit to see what blah is. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 06:05 PM, James Antill wrote: On Wed, 2009-12-02 at 17:46 -0500, Peter Jones wrote: so that every directory has about the same number of things. This should be fairly easy to code, but has a big downside: Packages will move directories. 1. This will upset yum (old repo. MD == no packages download). 2. This might upset mirrors. 3. This will probably upset users: i. URLs will only be safe until the next mash, they won't even be able to bookmark prefix/y if they just want to see yum each time. ii. Users have to look/parse the directory layout each time they visit to see what blah is. Yeah. Seth makes a good point - first letter is such vast improvement that we probably don't need to worry about doing better - at least for now. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2009-12-02 at 16:58 -0600, Matt Domsch wrote: On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote: The separate Everything tree that does not get obsoleted is required in some form for GPL compliance, with respect to the ISO images that we ship. Any new solution would have to preserve this. ? We provide Fedora-*-source-disc*.iso and Fedora-*-source-DVD.iso images on the mirrors already. As stated elsewhere, that doesn't carry the packages found on all the live images we produce. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
