Hard lockups with intel graphics since KMS was merged
Hi. I've been seeing hard lockups ever since KMS was merged. Originally I ended up with processes in uninterruptible sleep (most often evolution and bash) and then a hard lockup after a while. As of late I only get the hard lockup with no warning so it's harder to gather data. Bugreport is here: https://bugzilla.redhat.com/show_bug.cgi?id=492686 Anyone else experiencing this? The only way I can get a functioning system so far is to run with maxcpus=1. Cheers Kjartan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Is Fedora Hosted ok?
If so, could somebody have a look at https://fedorahosted.org/fedora-infrastructure/ticket/1662 for me? There are also older outstanding hosting requests than mine on there. Thanks, 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
Troubles running F9 mock chroot under F11
Hi, A number of difficulties/unfortunate circumstances are combining and causing me a headache. I'm looking for help/ideas on getting around these... I am trying to build a customized version of the OLPC XS school server for the OLPC deployment here in Nepal. The latest XS release is based on F9. An F11/F12 update is on the cards, but the XS development team is small and has more pressing priorities right now. The internet connection here at the office is too slow to make local builds, and also the power get turned off every night. We do have a F11 box at the ISP which has a satisfactory internet connection and reliable power, and we do have a speedy connection from the office to that box. This box is also used to build other software components for the deployment so there are multiple reasons why it makes sense for us to run the school server build there. The XS build system uses revisor and the upstream version is built on a F9 box. My problems originate from having to build our customized version from F11. We do not have the hardware or space to install a F9 box there, and we cannot downgrade our F11 system. The first thing I tried is to use the F11 revisor to build the F9 XS release. No luck - it fails on anaconda buildinstall due to big differences in the F11 anaconda on the host system vs the F9 anaconda in the target media. Not too surprising. I looked into using pungi instead, but the documentation states: Pungi needs to run on the arch it is composing, as root, and with an install of what it is composing, eg if you are composing Fedora 8, you need to be running Fedora 8. I then tried to create a F9 chroot using mock, with the intention of running revisor or pungi inside. This doesn't work, because mock creates a v9 berkeley DB inside the chroot, but the libraries/apps inside the chroot only support bdb v8. So running rpm -qa inside a fresh F9 chroot on F11 gives you these errors: mock-chroot rpm -qa rpmdb: /var/lib/rpm/Packages: unsupported hash version: 9 error: cannot open Packages index using db3 - Invalid argument (22) error: cannot open Packages database in /var/lib/rpm And revisor and pungi fail in the same way, even though the Pungi docs suggest this kind of thing should be possible: https://fedorahosted.org/pungi/wiki/PungiDocs/RunningPungiInMock Finally I tried to use db_dump on the F11 host to dump the database using the v9 tools, to go into the chroot and use db_load to import it using the v8 tools, but this also results in a v9 database being loaded :( Any further ideas or suggestions? Thanks, Daniel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Troubles running F9 mock chroot under F11
On Tue, Sep 15, 2009 at 12:02 PM, Daniel Drake d...@laptop.org wrote: I then tried to create a F9 chroot using mock, with the intention of running revisor or pungi inside. This doesn't work, because mock creates a v9 berkeley DB inside the chroot, but the libraries/apps inside the chroot only support bdb v8. So running rpm -qa inside a fresh F9 chroot on F11 gives you these errors: mock-chroot rpm -qa rpmdb: /var/lib/rpm/Packages: unsupported hash version: 9 error: cannot open Packages index using db3 - Invalid argument (22) error: cannot open Packages database in /var/lib/rpm I keep my build machine of F9 due to similar issues I saw building F7 from F9 -- however, ISTR there's been some discussion of this recently. Hmmm, a bit of googling leads to a nice thread http://www.mail-archive.com/fedora-buildsys-l...@redhat.com/msg02210.html which if you read in depth seems to indicate that either of: rm -f /var/lib/rpm/__db* /bin/rpm --rebuilddb fixes the problem. Probably either triggers the other. For obvious reasons I am interested in the results -- let me know if it works. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
Hey, I googled for it and found Karims blogpost and Simon aka kassamedias answer (comment 3) http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficiently/ -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: how to become a co-maintainer for an _existing_ RPM pkg
I want to become a maintainer too and I want to impress with some unofficial reviews. Don't really know if this is socially accepted to nag in other reviews without having an open review request -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: how to become a co-maintainer for an _existing_ RPM pkg
On 15/09/09 12:50, Josephine Tannhäuser wrote: I want to become a maintainer too and I want to impress with some unofficial reviews. Don't really know if this is socially accepted to nag in other reviews without having an open review request Go right ahead. A valid comment is a valid comment regardless of whether or not you have a review request open. Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090915 changes
Compose started at Tue Sep 15 06:15:09 UTC 2009 Broken deps for i386 -- anerley-0.0.20-3.fc12.i686 requires libmissioncontrol-client.so.0 anerley-devel-0.0.20-3.fc12.i686 requires pkgconfig(libmissioncontrol) clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) fillets-ng-0.9.1-1.fc12.i686 requires fillets-ng-data = 0:0.9.0 network-manager-netbook-1.2-5.fc12.i686 requires libnm_glib.so.0 python-sqlalchemy0.5-0.5.5-1.fc10.noarch requires python(abi) = 0:2.5 rygel-0.3-5.fc12.i686 requires libgee.so.0 rygel-tracker-0.3-5.fc12.i686 requires libgee.so.0 Broken deps for x86_64 -- anerley-0.0.20-3.fc12.i686 requires libmissioncontrol-client.so.0 anerley-0.0.20-3.fc12.x86_64 requires libmissioncontrol-client.so.0()(64bit) anerley-devel-0.0.20-3.fc12.i686 requires pkgconfig(libmissioncontrol) anerley-devel-0.0.20-3.fc12.x86_64 requires pkgconfig(libmissioncontrol) clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-gtk-0.9.so.0()(64bit) clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-glx-0.9.so.0()(64bit) clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) clutter-gtkmm-devel-0.9.4-1.fc12.x86_64 requires pkgconfig(clutter-gtk-0.9) fillets-ng-0.9.1-1.fc12.x86_64 requires fillets-ng-data = 0:0.9.0 network-manager-netbook-1.2-5.fc12.x86_64 requires libnm_glib.so.0()(64bit) python-sqlalchemy0.5-0.5.5-1.fc10.noarch requires python(abi) = 0:2.5 rygel-0.3-5.fc12.x86_64 requires libgee.so.0()(64bit) rygel-tracker-0.3-5.fc12.x86_64 requires libgee.so.0()(64bit) Broken deps for ppc -- anerley-0.0.20-3.fc12.ppc requires libmissioncontrol-client.so.0 anerley-0.0.20-3.fc12.ppc64 requires libmissioncontrol-client.so.0()(64bit) anerley-devel-0.0.20-3.fc12.ppc requires pkgconfig(libmissioncontrol) anerley-devel-0.0.20-3.fc12.ppc64 requires pkgconfig(libmissioncontrol) clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.ppc requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.ppc requires libclutter-glx-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.ppc64 requires libclutter-gtk-0.9.so.0()(64bit) clutter-gtkmm-0.9.4-1.fc12.ppc64 requires libclutter-glx-0.9.so.0()(64bit) clutter-gtkmm-devel-0.9.4-1.fc12.ppc requires pkgconfig(clutter-gtk-0.9) clutter-gtkmm-devel-0.9.4-1.fc12.ppc64 requires pkgconfig(clutter-gtk-0.9)
Re: Introduction to a new SIG for creation of Live DVD
On 09/14/2009 03:48 PM, Andre Robatino wrote:
On 09/14/2009 12:05 PM, John Reiser wrote:
Deltaisos are capable of saving roughly half the download size in
going from Fedora N to Fedora (N+1), but only work for installation
images, not live images. Is there any form of delta compression for
live images which is competitive with this?
It hasn't been productized, but approximately:
unsquashfs old-Live.img old-Live.tree # local (slave)
unsquashfs new-Live.img new-Live.tree # remote (master)
rsync remote:new-Live.tree local:old-Live.tree # delta
compression happens here
mksquashfs old-Live.tree new-Live.img # local
Has anyone tried this on existing live images to see how much is saved
(say going from a Fedora N to Fedora (N+1) Live CD)? I'm skeptical that
rsync, which is completely general, would be as efficient as something
specialized such as {make,apply}deltaiso. It may be necessary for
someone to create a specialized tool for delta compression between live
images, in order to be able to compress as well as deltaisos currently
do for the install images.
I tried doing this with the Live CDs for F10 and F11. Almost the entire
content is in a single file LiveOS/squashfs.img. Attempting to use
unsquashfs on this file gives
Parallel unsquashfs: Using 1 processor
FATAL ERROR aborting: failed to read fragment table
What am I doing wrong? (I'm using the i686 live CDs. I originally
tried it on an x86_64 host, then on an i686 host after reading somewhere
that might be the problem, but it made no difference.)
signature.asc
Description: OpenPGP digital signature
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Adding a new package to rawhide/F-12
On Tue, Sep 15, 2009 at 02:36:57PM +0100, Matthew Booth wrote: I'd like to add a new package (virt-v2v) to rawhide/F-12. Nothing depends on it. I don't appear to be able to do this, although I can add it to the supposedly stable F-11. This seems like an unlikely state of affairs. Am I missing something? Nothing to see here, move along. Matt was just trying todo 'make update' from F12 branch getting an error, because updates are not required for F12 branch yet. Regards, 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: status of forked zlibs in rsync and zsync
On 09/15/2009 04:44 AM, Josephine Tannhäuser wrote: Hey, I googled for it and found Karims blogpost and Simon aka kassamedias answer (comment 3) http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficiently/ I will note that the reply is not quite right. We can have zsync in Fedora but someone has to do some work to make that happen. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Server-devel] Troubles running F9 mock chroot under F11
On Tue, 2009-09-15 at 15:47 +0545, Daniel Drake wrote:
Hi,
A number of difficulties/unfortunate circumstances are combining and
causing me a headache. I'm looking for help/ideas on getting around
these...
I am trying to build a customized version of the OLPC XS school server
for the OLPC deployment here in Nepal. The latest XS release is based
on F9. An F11/F12 update is on the cards, but the XS development team
is small and has more pressing priorities right now.
I have an F11 iso you could test ;)
The internet connection here at the office is too slow to make local
builds, and also the power get turned off every night.
We do have a F11 box at the ISP which has a satisfactory internet
connection and reliable power, and we do have a speedy connection from
the office to that box. This box is also used to build other software
components for the deployment so there are multiple reasons why it
makes sense for us to run the school server build there.
The XS build system uses revisor and the upstream version is built on
a F9 box. My problems originate from having to build our customized
version from F11. We do not have the hardware or space to install a F9
box there, and we cannot downgrade our F11 system.
Are you just adding rpms to the install media? Or are you trying
something more difficult? I have a process in mind if you're just adding
rpms to the mix...
The first thing I tried is to use the F11 revisor to build the F9 XS
release. No luck - it fails on anaconda buildinstall due to big
differences in the F11 anaconda on the host system vs the F9 anaconda
in the target media. Not too surprising.
Revisor used to lie to buildinstall about the host environment, using
the version_from parameter, which just calls buildinstall based on your
target's version of Fedora (in /usr/lib/revisor/scripts)
from: /usr/lib/python2.6/site-packages/revisor/pungi.py
# setup the buildinstall call
if os.access(scripts/%s-buildinstall % self.cfg.version_from,
os.R_OK):
buildinstall.extend([os.path.abspath(scripts/%
s-buildinstall % self.cfg.version_from)])
elif os.access(/usr/lib/revisor/scripts/%s-buildinstall %
self.cfg.version_from, os.R_OK):
buildinstall.extend([/usr/lib/revisor/scripts/%
s-buildinstall % self.cfg.version_from])
else:
buildinstall.extend(['/usr/lib/anaconda-runtime/buildinstall'])
#buildinstall.append('TMPDIR=%s' % self.workdir) # TMPDIR broken
in buildinstall
# FIXME: Determine options from the anaconda-runtime version
if self.cfg.version_from in [ F9, F10, F11, DEVEL ]:
buildinstall.append('--debug')
However, I see that the older buildinstall(s) are not present any
more(?)! (File a bug I guess) If you were to add the buildinstall from
F9's anaconda in revisor's script directory as F9-buildinstall, then the
buildinstall from F9 should be used instead of the one on the host
system.
I looked into using pungi instead, but the documentation states:
Pungi needs to run on the arch it is composing, as root, and with an
install of what it is composing, eg if you are composing Fedora 8, you
need to be running Fedora 8.
Funny, how would you build a rawhide beta/preview release? ;) just
kidding... I've been able to build a lesser version of Fedora than what
is running on the build host in the past, but it has been awhile since I
tried.
I then tried to create a F9 chroot using mock, with the intention of
running revisor or pungi inside. This doesn't work, because mock
creates a v9 berkeley DB inside the chroot, but the libraries/apps
inside the chroot only support bdb v8. So running rpm -qa inside a
fresh F9 chroot on F11 gives you these errors:
mock-chroot rpm -qa
rpmdb: /var/lib/rpm/Packages: unsupported hash version: 9
error: cannot open Packages index using db3 - Invalid argument (22)
error: cannot open Packages database in /var/lib/rpm
And revisor and pungi fail in the same way, even though the Pungi
docs suggest this kind of thing should be possible:
https://fedorahosted.org/pungi/wiki/PungiDocs/RunningPungiInMock
Just spinning up a test release using F11 as the host to build
XS-server-f9, using revisor as used in the Makefile at:
http://dev.laptop.org/git/projects/xs-livecd/tree/
Finally I tried to use db_dump on the F11 host to dump the database
using the v9 tools, to go into the chroot and use db_load to import it
using the v8 tools, but this also results in a v9 database being
loaded :(
Any further ideas or suggestions?
Maybe, just need to know what your trying to do.
Jerry
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On Tue, 2009-09-15 at 08:55 -0600, Petrus de Calguarium wrote: Adam Williamson wrote: At present we are still in the contradictory and unsatisfactory position of shipping rsync with an internal forked zlib but refusing to accept zsync as a package because it does exactly the same thing. I hope this would not mean that rsync would be discontinued in favour of zsync. The zsync website states: [W]here rsync is designed for synchronising data from one computer to another..., zsync is designed for file distribution, with one file on a server to be distributed to thousands of downloaders. I use rsync every day for exactly its intended purpose, but I have NO use of the latter function. No, that's not the idea at all. As you say, it wouldn't make any sense. zsync isn't a replacement for rsync. -- 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: Introduction to a new SIG for creation of Live DVD
On Tue, Sep 15, 2009 at 6:22 PM, Dominik 'Rathann' Mierzejewski domi...@greysector.net wrote: What do you mean when you say it will only clutter the space? By this I mean to say that if we give 4 gb pre-installed stuff then menu and workspace will be too cluttered. It will be hard to find the application you want to work upon. It will be on the DVD anyway, either preinstalled or as RPMs. Yes, It will be on DVD but uninstalled packages will not show on main menu. What makes you say it will confuse the user? Have you actually tried giving users two DVDs, one with software preinstalled and one with RPMs in local repo and asking which they find less confusing or are you just guessing? A few months ago a local LUG here created a custom Live DVD from a mainstream Linux (wasn't fedora). The size was about 2gb. Although regular users managed but feedback from newbies wasn't so positive regarding the overall ease of use. -- Aditya Patawari Join Live DVD SIG : https://fedoraproject.org/wiki/SIGs/LiveDVD http://blog.adityapatawari.com/ https://fedoraproject.org/wiki/User:Adimania India -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petrus de Calguarium wrote: Adam Williamson wrote: At present we are still in the contradictory and unsatisfactory position of shipping rsync with an internal forked zlib but refusing to accept zsync as a package because it does exactly the same thing. I hope this would not mean that rsync would be discontinued in favour of zsync. The zsync website states: [W]here rsync is designed for synchronising data from one computer to another..., zsync is designed for file distribution, with one file on a server to be distributed to thousands of downloaders. I use rsync every day for exactly its intended purpose, but I have NO use of the latter function. FWIW, there's a project here that intends to replace rsync for all major distro mirrors. I can get more information then. I'll have him discuss here; he can discuss it's capabilities and internals much better than I can. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBAgAGBQJKr8XwAAoJEKaxavVX4C1XIHcQAOGEugPlMPL+GSN42d19UYbm Hu2ocCf9d4/Axi8wViTmB36g1V1g+huakP4SNi9dkDgqOxIVqmyhnkxt8TdupAWD Wrs6IFG9oAaN79W0QQGXZbbmTSTRe8WU2SYwIWqjQ+c9MExsDi5yNKw3qPWHORlE Y1Xzux1lo0qQ7eDvj5QamcvgaGlLIMZHL8Gx+prVV2KBRz2GZttL+MraGkqfhAor 3EkrZur1Nvpz52hYVpHJJBgIJchVnXiZlbucfdKC2A+0Pc7TckKGG3ZUqS099Omi dz7YMXUebphHxRYDVjqaiNb/bIqE7Qi4FTzO91fDdVzvf3kR8f17zsH2LHdg5bTt lzudkFfZ7UJ1HguQi3zH2yfD0bICJkaqld47nQelZ7DKHNVNcglBHKzuCwIg0xY+ 8FKmZlO6tUsocVeKgjjQiACAKm4+h5ZnFZP+F6OoOeEcAP5TTUjAJ0EPD8zzmLyE kJ2rGQKktAr+MfmTl+CqwvZAMy51m0tPzQC9vUaauTFO6r7egdWHVvdYeBcjw+gJ /pg7+phEmiV6Ghgs2+mCEoVthRSkjAc/2CfPglsQ0Rktk7Zq33wPnsxo9eY0j3Le cerb7i3uwHtwEmr2lfJM8xxBQnJwHRC1V26Hzp1ue0nhBI/UMpwWlGW4shmr2vPp NpVH1wnaSZvkpnrJg3vA =Da7h -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
I tried doing this with the Live CDs for F10 and F11: Parallel unsquashfs: Using 1 processor FATAL ERROR aborting: failed to read fragment table What am I doing wrong? (I'm using the i686 live CDs. What versions are involved? [unsquashfs -v -ll foo.img] unsquashfs version 4.0 works for me on F12-Snap2-i686-Live.iso/LiveOS/squashfs.img when run on either Fedora 11 or rawhide for Fedora 12. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
On 09/15/2009 01:15 PM, John Reiser wrote: I tried doing this with the Live CDs for F10 and F11: Parallel unsquashfs: Using 1 processor FATAL ERROR aborting: failed to read fragment table What am I doing wrong? (I'm using the i686 live CDs. What versions are involved? [unsquashfs -v -ll foo.img] unsquashfs version 4.0 works for me on F12-Snap2-i686-Live.iso/LiveOS/squashfs.img when run on either Fedora 11 or rawhide for Fedora 12. I'm using the latest F11 version of squashfs-tools on a fully updated x86_64 F11 box. Just discovered that it works on Fedora-11-i686-Live.iso, but fails with F10-i686-Live.iso. So the new question is, why doesn't it work with the F10 image? Also, after expanding squashfs.img for F11, it gives me another single huge (over 3 GB) file ext3fs.img. I know that rsync doesn't work particularly well between install images - going between the F11 Preview and Final DVDs required about half the full ISO size, while the deltaiso was more like 5%. It would be completely useless for the leap from Fedora N to (N+1). Unless there is a way to expand the Live image into a file tree where many of the files haven't changed, it looks like rsync won't be much help here. signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mouse pointer freezing in f12 and f11
On Thu, 2009-09-10 at 19:29 +1000, Rodd Clarkson wrote: I've had a problem with X in f12 or some time that sees the mouse pointer freezing. I'm now having the same issue in f11. I'm happy to file a bug in bugzilla, but I'm hoping someone mught be able to point me in the right direction. After some time after running X the mouse pointer will freeze. Switching to a VT doesn't help, but I can use the keyboard to close apps and do a little navigation. Also pushing the power button will see a dialog to allow me to shutdown, suspend, etc. I can suspend and resume and this fixes the problem. I'm not however convinced that it's an X bug. I think it might be related to bluetooth (I believe that my mouse and keyboard have something to do with bluetooth on this laptop) and that the suspend resume cycle restarts bluetooth and fixes the problem. You could verify this with DISPLAY=:0 xinput list when the mouse pointer stops. If you don't see the bluetooth mouse in the list, then the kernel is refusing to re-plug it right. If you _do_ see the mouse in the list, then X is confused somewhere. Does keyboard navigation still work when this happens? Does alt-tab switch windows, etc. - ajax 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: status of forked zlibs in rsync and zsync
On Tue, 2009-09-15 at 13:44 +0200, Josephine Tannhäuser wrote: Hey, I googled for it and found Karims blogpost and Simon aka kassamedias answer (comment 3) http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficiently/ If we _really_ cared about doing this OAOO, we could probably get the rsync package to drop out its own zlib copy as a shared lib, make that a subpackage, and link zsync against that. But, for 74k of shared library, I just don't care that much. This shouldn't block packaging zsync. - ajax 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
Default heuristics for variable-format displays
In attempting to document how displays are expected to work in F12 [1], I realized we still don't have a decent heuristic for some cases. Broadly, displays are either fixed-format or variable-format. FF means you have some set number of pixels, like an LCD. VF means you don't, like a CRT. (Projectors are often somewhere in between, we'll pretend they don't exist for a moment.) We get FF displays pretty much right, since they tend to describe themselves well enough in EDID to figure out what their native size is. Some VF displays are polite enough to define a preferred mode, and for that case we'll default to that. But, many VF displays don't define a preferred mode. How are we to choose? What's currently implemented will pick something along the lines of the largest available mode that matches our guess at the physical aspect ratio and that fits in the card's DAC and memory bandwidth limits. Which is awful. So I'm thinking something like (in wretched pseudopython): def mode_dpi_cmp(x, y): return cmp(abs(x.dpi - 96), abs(y.dpi - 96)) def mode_size_cmp(x, y): return cmp(x.width * x.height, y.width * y.height) def best_mode(modes, dpi_known = True): l = filter(lambda x: x.refresh = 72, modes) if l == []: l = modes if dpi_known: l.sort(cmp=mode_dpi_cmp) else: l.sort(cmp=mode_size_cmp) return l[0] Which is _pretty_ good, except you'd kinda like to match aspect ratio if you happen to know AR but not DPI. Which is trivial to add, but starts to be hard to read. If anyone has ideas I'm all ears, but I'd like to get this implemented sometime this week, so speak up. [1] https://fedoraproject.org/wiki/Desktop/Whiteboards/HardwareHandling - ajax 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: status of forked zlibs in rsync and zsync
On Tue, 2009-09-15 at 08:39 -0700, Adam Williamson wrote: On Tue, 2009-09-15 at 08:55 -0600, Petrus de Calguarium wrote: Adam Williamson wrote: At present we are still in the contradictory and unsatisfactory position of shipping rsync with an internal forked zlib but refusing to accept zsync as a package because it does exactly the same thing. I hope this would not mean that rsync would be discontinued in favour of zsync. The zsync website states: [W]here rsync is designed for synchronising data from one computer to another..., zsync is designed for file distribution, with one file on a server to be distributed to thousands of downloaders. I use rsync every day for exactly its intended purpose, but I have NO use of the latter function. No, that's not the idea at all. As you say, it wouldn't make any sense. zsync isn't a replacement for rsync. To clarify, we want to have zsync in the distribution as well as rsync, but it is being refused because it has an internal zlib (even though rsync has an internal zlib too, and _is_ in the distribution). zsync is orthogonal to rsync. they do not fight in any way. :) the ultimate resolution of this will be either to have rsync and zsync work with the system zlib package, or to ship the variant zlib as a separate package. i'm just trying to bump the process along. -- 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: Deltarpm xz problem with PPC generated rpms?
On Tue, 2009-09-15 at 01:27 -0400, Michel Alexandre Salim wrote: On Mon, Sep 14, 2009 at 1:28 PM, Seth Vidal skvi...@fedoraproject.org wrote: Boy, I'm so glad we decided to jump onto the xz ship. I take it it's too late to back out and stick to bzip2 until the situation stabilizes? I take it whatever solution ends up in F-12 is likely to be the one used by RHEL 6 when it comes out next spring. Between using more space on a distribution that's smaller than Fedora anyway, and having a rather uncertain compression tool... It's only 'uncertain' in the sense that it's not committed to always producing the same archive in future versions or on different architectures. As has been pointed out, this only has any relevance when it comes to delta RPMs, which are hardly a vital case (it's not catastrophic if they don't work). There's no suggestion that the tool is 'uncertain' in any more important sense (i.e. it doesn't actually compress / decompress properly). It isn't. -- 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: Default heuristics for variable-format displays
On Tue, 2009-09-15 at 12:06 -0400, Adam Jackson wrote: In attempting to document how displays are expected to work in F12 [1], I realized we still don't have a decent heuristic for some cases. Broadly, displays are either fixed-format or variable-format. FF means you have some set number of pixels, like an LCD. VF means you don't, like a CRT. (Projectors are often somewhere in between, we'll pretend they don't exist for a moment.) We get FF displays pretty much right, since they tend to describe themselves well enough in EDID to figure out what their native size is. Some VF displays are polite enough to define a preferred mode, and for that case we'll default to that. But, many VF displays don't define a preferred mode. How are we to choose? What's currently implemented will pick something along the lines of the largest available mode that matches our guess at the physical aspect ratio and that fits in the card's DAC and memory bandwidth limits. Which is awful. So I'm thinking something like (in wretched pseudopython): def mode_dpi_cmp(x, y): return cmp(abs(x.dpi - 96), abs(y.dpi - 96)) def mode_size_cmp(x, y): return cmp(x.width * x.height, y.width * y.height) def best_mode(modes, dpi_known = True): l = filter(lambda x: x.refresh = 72, modes) if l == []: l = modes if dpi_known: l.sort(cmp=mode_dpi_cmp) else: l.sort(cmp=mode_size_cmp) return l[0] Which is _pretty_ good, except you'd kinda like to match aspect ratio if you happen to know AR but not DPI. Which is trivial to add, but starts to be hard to read. If anyone has ideas I'm all ears, but I'd like to get this implemented sometime this week, so speak up. I know that, in the dinosaur days of CRT, I could 'see' flicker (and get flicker-generated headaches) at anything under 80Hz, and I know there are even more sensitive people than that. So 72Hz may be a bit of a low 'safe refresh rate' cutoff. I'd like it to be 80 at least. 72/75 were better than 65 for me, but definitely not acceptable for long-term work. (/me remembers the days when you could gain any office worker's everlasting friendship by changing their refresh rate from 60Hz to 85Hz...ahhh, good times.) -- 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: Deltarpm xz problem with PPC generated rpms?
On Tue, Sep 15, 2009 at 10:38:32AM -0700, Adam Williamson wrote: On Tue, 2009-09-15 at 01:27 -0400, Michel Alexandre Salim wrote: On Mon, Sep 14, 2009 at 1:28 PM, Seth Vidal skvi...@fedoraproject.org wrote: Boy, I'm so glad we decided to jump onto the xz ship. I take it it's too late to back out and stick to bzip2 until the situation stabilizes? I take it whatever solution ends up in F-12 is likely to be the one used by RHEL 6 when it comes out next spring. Between using more space on a distribution that's smaller than Fedora anyway, and having a rather uncertain compression tool... It's only 'uncertain' in the sense that it's not committed to always producing the same archive in future versions or on different architectures. As has been pointed out, this only has any relevance when Simple solution: Don't build the noarch RPMs on ppc. Why?: Because F12 is the last release that will have ppc be a primary arch and it is fairly arguable that you want to optimize for the future case going forward anyway. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Deltarpm xz problem with PPC generated rpms?
Josh Boyer (jwbo...@gmail.com) said: Simple solution: Don't build the noarch RPMs on ppc. Why?: Because F12 is the last release that will have ppc be a primary arch and it is fairly arguable that you want to optimize for the future case going forward anyway. I'm not sure how 'simple' that is in the koji configuration. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
On 09/15/2009 10:29 AM, Andre Robatino wrote: I'm using the latest F11 version of squashfs-tools on a fully updated x86_64 F11 box. Just discovered that it works on Fedora-11-i686-Live.iso, but fails with F10-i686-Live.iso. So the new question is, why doesn't it work with the F10 image? That's a bug, please file in bugzilla, with *specific* version info. Include the checksum of each *.iso, just to be sure. Also, after expanding squashfs.img for F11, it gives me another single huge (over 3 GB) file ext3fs.img. ext3fs.img is a complete, mountable filesystem. mount -o loop ext3fs.img /mnt/foo All the files are there with their actual names, actual contents, etc. So rsync will work on the tree /mnt/foo just as well as rsync works on any actual file system tree. The downside is each rsync session requires processor cycles on both ends. The drawing card of the new zsync tool is that the rsync CPU time on the master side need be done only once; the results are cached as a companion file to each existing file. The companion file contains the checksums for chunks of the [new] file. The master side http server just serves the companion file like any other file. The zsync tool retrieves the whole companion file, does the rsync checksum computations for the local old file, then asks the master for the appropriate partial content (HTTP code 206) of the chunks that the local side does not have already. The gain is that the companion file is smaller. The risk is that anybody who can manufacture collisions for the checksum can pollute the result. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Deltarpm xz problem with PPC generated rpms?
On Tue, Sep 15, 2009 at 01:56:55PM -0400, Bill Nottingham wrote: Josh Boyer (jwbo...@gmail.com) said: Simple solution: Don't build the noarch RPMs on ppc. Why?: Because F12 is the last release that will have ppc be a primary arch and it is fairly arguable that you want to optimize for the future case going forward anyway. I'm not sure how 'simple' that is in the koji configuration. It will have to be done anyway, yes? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Deltarpm xz problem with PPC generated rpms?
Josh Boyer (jwbo...@gmail.com) said: I'm not sure how 'simple' that is in the koji configuration. It will have to be done anyway, yes? Well, that would involve disabling all ppc builders for a release entirely, which is much simpler. But this isn't the right list anyway. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
On 09/15/2009 02:01 PM, John Reiser wrote: On 09/15/2009 10:29 AM, Andre Robatino wrote: I'm using the latest F11 version of squashfs-tools on a fully updated x86_64 F11 box. Just discovered that it works on Fedora-11-i686-Live.iso, but fails with F10-i686-Live.iso. So the new question is, why doesn't it work with the F10 image? That's a bug, please file in bugzilla, with *specific* version info. Include the checksum of each *.iso, just to be sure. https://bugzilla.redhat.com/show_bug.cgi?id=523504 signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Default heuristics for variable-format displays
On 09-09-15 12:06:54, Adam Jackson wrote: ... def mode_dpi_cmp(x, y): return cmp(abs(x.dpi - 96), abs(y.dpi - 96)) ... The names x and y suggest coordinates to me. I'd have read the code right the first time if the names had been a and b. def best_mode(modes, dpi_known = True): l = filter(lambda x: x.refresh = 72, modes) If the sort is stable, how about sorting by highest refresh rate first? That way an 85 Hz refresh (if available) would be preferred over a 75 Hz refresh rate. (I expect the 72 Hz is to separate out LCDs which usually have a fixed rate of about 60 Hz.) l = filter(lambda a: a.refresh = 72, modes).sorted( key=lambda a: -a.refresh ) (BTW, use key instead of cmp in the other cases as well.) if l == []: l = modes if dpi_known: l.sort(cmp=mode_dpi_cmp) else: l.sort(cmp=mode_size_cmp) return l[0] ... In any case, thank you for working on it (my bz is 522155 RFE choose sensible resolution during boot). -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Default heuristics for variable-format displays
On Tue, 2009-09-15 at 10:48 -0700, Adam Williamson wrote: I know that, in the dinosaur days of CRT, I could 'see' flicker (and get flicker-generated headaches) at anything under 80Hz, and I know there are even more sensitive people than that. So 72Hz may be a bit of a low 'safe refresh rate' cutoff. I'd like it to be 80 at least. 72/75 were better than 65 for me, but definitely not acceptable for long-term work. The struggle here is that you may not actually have any modes in the pool with refresh rates that high. I'm remembering 72Hz as some OSHA recommendation but I'm not able to find a reference to it quickly. Both the EU and EnergyStar seem to indicate that CRTs should be measured for power at the largest resolution supported at 75Hz, but that's a power recommendation, not an ergonomic one. There's also a (rather small) power usage argument here. Higher refresh rates require more memory bandwidth, which means more memory cycles, which means more power draw. It's linear on number of pixels, but the coefficient is pretty low, so maybe it's not worth worrying about. I suppose you could successively run the filter() step in the given algorithm until you get a non-empty list. Nggh though. - ajax 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: status of forked zlibs in rsync and zsync
Toshio Kuratomi wrote: This would be great if maintainers were willing to fix issues after the fact. Look at rsync -- there's no incentive to fix the library issue at this point because rsync is already in the distribution. We need to fix this lack of incentive for other reasons -- but we need to fix it before we start trying to get more packages into the distro with less initial quality. Not good at this point in the release cycle, but... an option is to block it from rawhide, until fixed/resolved. That'll light a fire to make things happen surely. -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/15/2009 01:10 PM, Rex Dieter wrote: Toshio Kuratomi wrote: This would be great if maintainers were willing to fix issues after the fact. Look at rsync -- there's no incentive to fix the library issue at this point because rsync is already in the distribution. We need to fix this lack of incentive for other reasons -- but we need to fix it before we start trying to get more packages into the distro with less initial quality. Not good at this point in the release cycle, but... an option is to block it from rawhide, until fixed/resolved. That'll light a fire to make things happen surely. That's an awfully big stick to wield. At some point we may need something like that. For instance, if we are serious about ever completing all of the merge reviews there will come a time when we have to think about how we can give people the incentive to do that. I keep looking for a carrot to use as incentive rather than a stick, though Regarding the timing, if this were to be the solution, it would be better to do it at the beginning of a development cycle than at the end. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Fedora-r-devel-list] Re: r2spec
José Matos jamatos-bxeiay08...@public.gmane.org writes: Just for curiosity, do you create the %test section on the first passage? I had to comment that section for bootstrap because I had cyclic dependencies where test section of package A would depend on package B, and the test of package B would depend on A. I'm hoping my previous message about dependencies has kind of answered this question. I've tried to be clear, but the topic is twisty and complex, and rife with politics. My branch (If I may so dignify it) is now doing the following: + Generating the specfiles for a broad dependency tree of a package + Generating a rpm build script which will go through the specs, and - build a RPM - install the RPM in an order which satisfies the narrow dependency tree. I'm currently testing that one, it built the 162-package tree for ggplot2 with a relatively small number of RPM build errors, which I haven't yet solved. I'm testing the r2spec package now, once I smack the bugs in my RPM of it I'll stick it up for kibitzing. Once _that_ is complete, I intend to automate the running of the R CMD CHECKs. - Allen S. Rout ___ Fedora-r-devel-list mailing list Fedora-r-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-r-devel-list
[Fedora-r-devel-list] R2spec kibitzing.
Sorry, those messages were supposed to have come out periodically over the last week or two. I've got the next version ready, tested as I had alluded to in my previous. http://nersp.osg.ufl.edu/~asr/media/R2spec-2.6.1-asr.src.rpm So, here's what I did to get more or less useful results out of it: After installing, I made a temp directory, /var/tmp/Rstuff. There, I ran (as root): # clear; R2spec -n Allen S. Rout -e a...@ufl.edu -c --force --suggests --verbose --package ggplot2 This downloaded the CRAN-like lists of packages, downloaded source tarballs, and built (and copied) the specfiles and source. It also generated a few dot files, including the broad and narrow dependency graphs for the requested package. It also generates a shell file: 'rpmbuild.sh'. This is intended to make all the RPMs you need for the broad graph. I haven't decided what the sane options are in terms of 'pwd' throughout all this process. At the moment, the next step is: # cd /usr/src/redhat/SPECS # sh /var/tmp/Rstuff/rpmbuild.sh This will build and install all of the RPMs in the broad graph. ... If the individual builds work. This script uses a tempdir extensively, again I'm not sure what the Right Way is to do this, I haven't thought about it too much yet. It's statically defined at the beginning of the script to be /var/tmp/Rstuff that's obviously inappropriate for release, but will do for the moment. The script drops a build log and an install log for every package addressed. Right now, for me to get the sysdeps to build and install all (most) of ggplot2's broad depgraph, I must: yum install openmpi openmpi-devel openmpi-libs unixODBC-devel pvm tcl tcl-devel perl-DateManip perl-Date-Calc perl-version and then install from EPEL: environment-modules-3.2.6-4.el5.x86_64.rpm mpich2-1.1.1-1.el5.x86_64.rpm perl-IO-stringy-2.110-5.el5.noarch.rpm perl-Jcode-2.06-6.el5.noarch.rpm perl-OLE-Storage_Lite-0.14-9.el5.noarch.rpm perl-Parse-RecDescent-1.96-1.el5.noarch.rpm perl-Spreadsheet-WriteExcel-2.18-1.el5.noarch.rpm perl-Unicode-Map-0.112-12.el5.x86_64.rpm and then install from the graphviz people: graphviz-2.24.0-1.el5.x86_64.rpm graphviz-devel-2.24.0-1.el5.x86_64.rpm With these things done, I still fail to build (and haven't investigated much yet): tcltk2: Fails to install: need tclsh8.3, not 8.4 ? multcomp: requires Survival = 2.35.7 ? ... flexmix: dep on multcomp R-RandomFields, R-MCMCpack: uncaught debug files in the build tree. MPI, sprng As threatened, my next step will be a similar shell script to R CMD CHECK all the packages, and populate yet another family of logfiles. Once that is complete, I will re-announce and go back to try to figure out why individual packages fail. - Allen S. Rout ___ Fedora-r-devel-list mailing list Fedora-r-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-r-devel-list
