Announcing Fedora 12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm proud to announce the release of Fedora 12, the latest innovative Linux distribution from the Fedora Project, a global, collaborative partnership of free software community members sponsored by Red Hat. If you can't wait to get the distribution, simply visit: http://get.fedoraproject.org If you want a quick tour of highlights in this release, check out: http://fedoraproject.org/wiki/Fedora_12_one_page_release_notes You can also find this announcement text at: http://fedoraproject.org/wiki/Fedora_12_Announcement Or read on for loads of information about the new release and all the leading edge technologies we've packed into it. More links are available at the end of this message, too. Enjoy! * * * Fedora is a leading edge, free and open source operating system that continues to deliver innovative features to many users, with a new release about every six months. We bring to you the latest and greatest release of Fedora ever, Fedora 12! Join us and share the joy of Free software and the community with friends and family. We have several major new features with special focus on desktops, netbooks, virtualization and system administration. == What's New in Fedora 12? == * Optimized performance - All software packages on 32-bit (x86_32) architecture have been compiled for i686 systems, with special optimization for the Intel Atom processors used in many netbooks, but without losing compatibility with the overwhelming majority of CPUs. * Smaller and faster updates - In Fedora 11, the optional yum-presto plugin, developed by Fedora contributor Jonathan Dieter, reduced update size by transmitting only the changes in the updated packages. Now, the plugin is installed by default. Also, RPMs now use XZ rather than gzip for compression, providing smaller package sizes without the memory and CPU penalties associated with bzip2. This lets us fit more software into each Fedora image, and uses less space on mirrors, making their administrators' lives a little easier. Thanks to the Fedora infrastructure team for their excellent work in setting up the infrastructure to generate delta RPMs on the fly for all the updates. * NetworkManager broadband and other enhancements - NetworkManager, originally developed by Red Hat's Dan Williams, was introduced in Fedora 7 and has become the de facto network configuration solution for distributions everywhere. Enhancements to NetworkManager make both system-wide connections and mobile broadband connections easier than ever. Bluetooth PAN support offers a simple click through process to access the Internet from your mobile phone. NetworkManager can now configure always-on and static address connections directly from the desktop. PolicyKit integration has been added so configuration management can be done via central policy where needed. IPv6 support has also been improved. * Next-generation (Ogg) Theora video - For several years, Theora, the open and free format not encumbered by known patents has provided a way for freedom-loving users to share video. Fedora 12 includes the new Theora 1.1, which achieves very high quality comparable to H.264, meeting the expectations of demanding users with crisp, vibrant media in both streaming and downloadable form. Thanks to the work of the Xiph.Org Foundation's Christopher Monty Montgomery, sponsored by Red Hat, other Xiph developers and the contribution of Mozilla.org, Theora videos now deliver much better quality primarily via enhancements in the encoder without any change in the format, making it available to all Theora users. Using Theora video and Vorbis audio formats, Firefox 3.5 and applications using the Gstreamer multimedia framework can deliver free media on the web out of the box even better than the previous release of Fedora. Theora is being rapidly adopted by several popular websites including Wikipedia, VideoPress and DailyMotion. Fedora Project is proud to support communities of free culture and open content as part of our mission. More details at http://hacks.mozilla.org/2009/09/theora-1-1-released/ * Graphics support improvements - Fedora 12 introduces experimental 3D support for AMD Radeon HD 2400 and later graphics cards. To try it out, install the mesa-dri-drivers-experimental package. On many cards, this support should allow desktop effects to be used. Kernel mode setting (KMS) support, which was introduced on AMD hardware in Fedora 10 and extended to Intel hardware in Fedora 11, is now extended to NVIDIA hardware as well, meaning the great majority of systems now benefit from the smooth, fully-graphical startup sequence made possible by KMS. The Fedora graphical startup sequence now works better on systems with multiple monitors. Also on multiple monitor systems, the desktop will now automatically be spread across all monitors by default, rather than
RPM Fusion free and nonfree repositories for Fedora 12 (Constantine) now available
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The RPM Fusion team is proud to announce the public availability of our
''free'' and ''nonfree'' package repositories for Fedora 12 (Constantine). The
repositories contain multimedia applications, kernel drivers, games and other
software the Fedora Project doesn't want to ship for various reasons.
RPM Fusion repositories give Fedora 12 the ability to play all kinds of audio
and video formats -- including, but not limited to MP3s or video files in MPEG
or Xvid formats.
You can browse the repository contents for the ix86 (sometimes also called x86,
i386, i686 or x86-32) architecture via these URLs
http://download1.rpmfusion.org/free/fedora/releases/12/Everything/i386/os/repoview/index.html
http://download1.rpmfusion.org/nonfree/fedora/releases/12/Everything/i386/os/repoview/index.html
Note that x86-64, ppc and ppc64 are supported by RPM Fusion as well.
To make RPM Fusion repositories available on a freshly installed Fedora 12
system run the following command:
{{{
su -c 'rpm -ivh \
http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm
\
http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm'
}}}
(Reminder: You need to cut'n'paste all three lines)
More details and a GUI based way how to configure and use RPM Fusion can be
found in our wiki at
http://rpmfusion.org/Configuration
You can also enable RPM Fusion while installing Fedora 12 -- details and some
screenshots that should give you an idea how everything works can be found at
http://rpmfusion.org/EnablingRpmFusionDuringFedoraInstall
Please note that the graphics drivers from AMD are not available in the
repositories right now as they are not compatible with the X-Server that is
used in Fedora 12. Note that the Nvidia drivers are available via the
updates-testing repos only at this time as they require some manual steps to
make them work; see the howto for details:
http://rpmfusion.org/Howto/nVidia
There is still a lot of room for a whole lot of improvements in RPM Fusion. If
you want to help then join us! Our mailing lists can be found at
http://lists.rpmfusion.org/mailman/listinfo
Thanks for you interest in RPM Fusion.
~The RPM Fusion Team (http://rpmfusion.org)
== More details ==
=== Reminder for the folks that plan to yum-update to Fedora 12 ===
If you have RPM Fusion packages installed on your system already and plan to
live-update to Fedora 12 using yum then please leave the RPM Fusion
repositories enabled for the big yum update run. Only then you'll get all the
updated packages from RPM Fusion as well, which is important, as their
dependencies get fulfilled by the Fedora 12 packages. That's not the case for
the old packages that are on your system right now -- those in fact have
dependencies on the packages from the Fedora release you are about to update,
which will lead to a lot of trouble.
=== Examples to get the most important bits from RPM Fusion ===
Once you installed the release rpm you can install software using the graphical
software installation tools which are part of Fedora. As root-user you can also
use yum on a command line to install packages; for example:
~ * PackageKit will normally install all codecs on demand for GNOME and KDE
apps that use gstreamer as backend; if you want to get them manually ahead of
tine run this command as root:
{{{
yum install gstreamer-ffmpeg gstreamer-plugins-bad \ gstreamer-plugins-ugly
}}}
~ * if you want to use mplayer, run one ofthe following commands
{{{
# yum install mplayer-gui
# yum install gnome-mplayer
}}}
~ * if you prefer VLC, run
{{{
# yum install vlc
}}}
~ * want to PGP sign or encrypt your mails using thunderbird? Then run:
{{{
# yum install thunderbird-enigmail
}}}
=== Problems? ===
Let us know via http://bugzilla.rpmfusion.org/
=== Need support? ===
Many people in #fedora on freenode as well as subscribers on fedora-list [AT]
redhat.com and rpmfusion-users-lists [AT] rpmfusion.org know how to help.
=== Developer contact ===
Meet us in #rpmfusion on freenode or join the developers mailing list at
http://lists.rpmfusion.org/mailman/listinfo
EOF
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAksCq60ACgkQUjQh93TopkE0cwCgoT4IFzm42dhC6yWihrlujtTh
634An3APFcd2+ZqDLt3jZsbIbDTACP98
=FDsR
-END PGP SIGNATURE-
--
fedora-announce-list mailing list
fedora-announce-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-announce-list
Announcing Fedora Electronic Lab 12
Hello there, On behalf of Fedora Electronic Lab team, I have the pleasure to announce the fifth consecutive release of the Fedora Electronic Lab 12 Livedvd. This Livedvd is available for download at http://spins.fedoraproject.org/fel#downloads This release highlights Fedora's commitment in strengthening the electronic hardware communities with an advanced Electronic Design Automation (EDA) environment. The latter * was optimized to support OpenMoko development team. * entails a peer review solution for hardware design. * has Eclipse 3.5 series for VHDL/Verilog IPCores development and documentation. * entails the latest gEDA/gaf release, openocd, simulators for 8051 microcontrollers,... * Please find in-depth details in the Release Notes: http://chitlesh.fedorapeople.org/papers/FEL12ReleaseNotes.pdf Flyer: http://chitlesh.fedorapeople.org/papers/fel-flyer-f12.pdf Website : http://chitlesh.fedorapeople.org/FEL/ Mailing list : fedora-electronic-lab-list [AT] redhat DOT com Developers : https://fedorahosted.org/fedora-electronic-lab Kind regards, Chitlesh Goorah -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
Postgresql Database Error
hello, fedora-buildsys-list: when I requset a build task for pakcage anaconda to koji, one errie error come out. It detailed as follow: pg.DatabaseError: error ' ERROR: new row for relation task violates check constraint task_weight_check ' in ' UPDATE task SET weight=-0.9838856091396 WHERE id = 16296 ' I'm sure that the source rpm of anaconda is OK,because I succed to build it in local mock environment. and the repo is the same as the koji build server. hope you do me a favor sincerely! -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: A silly question about our FC tag
On 11/17/2009 09:08 AM, Thorsten Leemhuis wrote: Henrique Junior wrote on 16.11.2009 23:57: I have a question that may sound a little stupid, but that came as I write a short article about some Fedora's curiosities. Why are our packages still using the tag f*c*X, f*c*Y, f*c*W since Fedora does not use “*Core*” in his name anymore? I know it's an almost irrelevant question, but the article is just about small curiosities and I could not think in a better place to ask. I don't care much about the c, but we IMHO really should get rid of a disttag in rawhide that is related to the release cycle when a package got build. Only then we can avoid confusion like why are there packages with .fc11 on my F12 machine/in the F12 repos which IMHO come up way to often and seem to highly confuse people. I still vote for using .1 as %dist in rawhide all the time(¹), as that is higher then (for example) .fc12(²). But that suggestion was shot down last time I brought it up one or two years ago. IMO, this proposal is silly and was shot down for valid reasons. Has anybody any better idea? Keep things as they are. I don't see any reason for any change. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More broken deps for F11 texlive-2009
On Tuesday 17 November 2009 02:27:08 Matthew Saltzman wrote: Latest F11 texlive-2009 update complains about dependencies of the new packages (which have .fc12 version suffixes!) on libpoppler.so.5()(64bit). The same complain happens on F12 (on a x86_64 no less). :-) -- José Abílio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More broken deps for F11 texlive-2009
On Mon, Nov 16, 2009 at 09:27:08PM -0500, Matthew Saltzman wrote: Latest F11 texlive-2009 update complains about dependencies of the new packages (which have .fc12 version suffixes!) on libpoppler.so.5()(64bit). It is now fixed. Jindrich -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More broken deps for F11 texlive-2009
On Tue, Nov 17, 2009 at 08:47:16AM +, José Matos wrote: On Tuesday 17 November 2009 02:27:08 Matthew Saltzman wrote: Latest F11 texlive-2009 update complains about dependencies of the new packages (which have .fc12 version suffixes!) on libpoppler.so.5()(64bit). The same complain happens on F12 (on a x86_64 no less). :-) It could happen only on x86_64 and F11 repo because I forgot to remove the F12 packages created in local build from the repo directory before createrepo. Do you see anything broken on non-x86_64 arches? I checked the F12 repo and everything looks sane to me. Jindrich -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 texlive-Asana-Math conflict
On Sun, Nov 15, 2009 at 07:37:54PM -0500, Neal Becker wrote: -- Processing Dependency: texlive-Asana-Math = 2009 for package: texlive- collection-fontsextra-2009-2.13989.fc12.noarch --- Package texlive-asana-math-fedora-fonts.noarch 0:2009-2.0.926.15878.fc12 set to be updated -- Finished Dependency Resolution texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has depsolving problems -- Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Fixed. -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive-2009 update dependency failure in F11
Hi, On Sun, Nov 15, 2009 at 07:23:10PM -0500, Matthew Saltzman wrote: From today's F11 texlive-2009 update: Setting up Update Process Resolving Dependencies -- Running transaction check -- Processing Dependency: libkpathsea.so.4()(64bit) for package: evince-dvi-2.26.2-1.fc11.x86_64 --- Package texlive-kpathsea-doc.noarch 0:2009-2.15842.1.fc12 set to be updated -- Finished Dependency Resolution evince-dvi-2.26.2-1.fc11.x86_64 from installed has depsolving problems -- Missing Dependency: libkpathsea.so.4()(64bit) is needed by package evince-dvi-2.26.2-1.fc11.x86_64 (installed) Error: Missing Dependency: libkpathsea.so.4()(64bit) is needed by package evince-dvi-2.26.2-1.fc11.x86_64 (installed) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest Thanks for any suggestions. This one is actually unfixable without a new tag in koji so that I can rebuild evince against the new libkpathsea. For now, I suggest to remove evince-dvi, install TeX Live and rebuild evince locally from fedora CVS. Then you can install evince-dvi from your local build which will be linked against the TeX Live 2009's kpathsea. Jindrich -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Issue with F13 dracut/kernel/selinux
I just went to rawhide over the last day and am not able to boot into kernel 2.6.32-0.48.rc7.git1.fc13 unless selinux is disabled. (permissive isn't good enough). I can boot into my old kernel 2.6.31.5-127.fc12 which had a dracut generated image from before the upgrade. The error occurs when udev is trying to unlock my nonroot partitions. I get an error message refering to filesetcon not working on a /dev/mapper file. I get asked for passwords again (since all of the file systems have the same luks password I normally don't have to do this) and the correct password doesn't work. If I boot with selinux=0, the system boots with the 2.6.32-0.48.rc7.git1.fc13 kernel (but then I have to relabel the next time I boot without that option). I am using selinux-policy-targeted-3.6.33-1.fc13. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
2009/11/16 Rahul Sundaram sunda...@fedoraproject.org On 11/17/2009 04:27 AM, Henrique Junior wrote: Hello, * I have a question that may sound a little stupid, but that came as I write a short article about some Fedora's curiosities. Why are our packages still using the tag f*c*X, f*c*Y, f*c*W since Fedora does not use “*Core*” in his name anymore? I know it's an almost irrelevant question, but the article is just about small curiosities and I could not think in a better place to ask. When Fedora 7 was about to be released, there was a long and serious discussion about how to rename it but we took the easy way out and decided to call it Fedora Package Collection along the lines of GCC being called GNU Compiler Collection. Dropping the C would have broken the upgrade path for RPM. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Thank you for the answers, they were very enlightening. -- Henrique LonelySpooky Junior http://www.lonelyspooky.com - In a world without walls and fences, who needs windows and gates?! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dbus bug when writing with dvd+rw
Maybe it should be reported in bugzilla: https://bugzilla.redhat.com/ This might be useful too: https://fedoraproject.org/wiki/Bugs 2009. 11. 16, hétfő keltezéssel 11.12-kor Tamas Hoppar ezt írta: Hi everybody, I get a dbus error after blanking a dvd+rw and start to write an ISO, using brasero. Get http://www.hugos.hu/uploads/bug.png to see the error msg. The hungarian message says: I can not mount empty optical disc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
po2sgml no longer exists in translate-toolkit ?
Hello, I can't find po2sgml installed in the latest translate-toolkit package. Has it been removed ? Is there any other package that provides it ? Regards, Amit. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Mon, 2009-11-16 at 19:55 -0500, Chris Ball wrote: Hi, I've written up a draft of an F13 filesystem rollback feature using Btrfs snapshots that are automatically created by yum: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs It'd be great to get feedback on whether this is the right idea, and how exactly the UI interaction should work, before submitting this formally. See also: http://blogs.sun.com/erwann/entry/zfs_on_the_desktop_zfs http://blogs.sun.com/erwann/entry/time_slider_screencast http://blogs.sun.com/erwann/entry/new_time_slider_features_in It was mentioned in the past that we'd want to have this ported to using btrfs snapshots. Cheers -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
abrt bugzilla reporting - does it work?
Hi, I just wanted to report an evolution crash report with abrt. All I get (besides a stacktrace) is libcurl failed HTTP Post. Since I suspect that libcurl generally can handle HTTP posts, I wonder if this is some general bug in abrt? Did anybody submit bugs successfully using this tool? regards Christoph signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt bugzilla reporting - does it work?
Am Dienstag, den 17.11.2009, 11:33 +0100 schrieb Christoph Höger: Since I suspect that libcurl generally can handle HTTP posts, I wonder if this is some general bug in abrt? It's a problem with libcurl's resolver. Did anybody submit bugs successfully using this tool? Yes I did. However I had to add bugzilla.redhat.com to my /etc/hosts After that it worked. Felix -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
texlive 2009 massive dep problem today
Lots of errors like these: Error: Missing Dependency: libc.so.6(GLIBC_2.11)(64bit) is needed by package texlive-luatex-bin-2009-2.15878.fc12.x86_64 (texlive) Error: Missing Dependency: libpoppler.so.5()(64bit) is needed by package texlive-jadetex-bin-2009-2.15878.fc12.x86_64 (texlive) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Issue with F13 dracut/kernel/selinux
On 11/17/2009 04:12 AM, Bruno Wolff III wrote: I just went to rawhide over the last day and am not able to boot into kernel 2.6.32-0.48.rc7.git1.fc13 unless selinux is disabled. (permissive isn't good enough). I can boot into my old kernel 2.6.31.5-127.fc12 which had a dracut generated image from before the upgrade. The error occurs when udev is trying to unlock my nonroot partitions. I get an error message refering to filesetcon not working on a /dev/mapper file. I get asked for passwords again (since all of the file systems have the same luks password I normally don't have to do this) and the correct password doesn't work. If I boot with selinux=0, the system boots with the 2.6.32-0.48.rc7.git1.fc13 kernel (but then I have to relabel the next time I boot without that option). I am using selinux-policy-targeted-3.6.33-1.fc13. I have not made the leap yet to F13 to see what the problems are. I will look into this. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 texlive-Asana-Math conflict
Jindrich Novy wrote: On Sun, Nov 15, 2009 at 07:37:54PM -0500, Neal Becker wrote: -- Processing Dependency: texlive-Asana-Math = 2009 for package: texlive- collection-fontsextra-2009-2.13989.fc12.noarch --- Package texlive-asana-math-fedora-fonts.noarch 0:2009-2.0.926.15878.fc12 set to be updated -- Finished Dependency Resolution texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has depsolving problems -- Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Fixed. texlive-Asana-Math-fedora-fonts-2009-2.0.926.15878.fc12.noarch from installed has depsolving problems -- Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-Asana-Math-fedora-fonts-2009-2.0.926.15878.fc12.noarch (installed) texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has depsolving problems -- Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Skip-broken could not solve problems Error: Missing Dependency: texlive-linearA = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, Nov 17, 2009 at 2:48 AM, Jeff Garzik jgar...@pobox.com wrote: On 11/17/2009 02:43 AM, nodata wrote: Am 2009-11-17 01:55, schrieb Chris Ball: Hi, I've written up a draft of an F13 filesystem rollback feature using Btrfs snapshots that are automatically created by yum: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs It'd be great to get feedback on whether this is the right idea, and how exactly the UI interaction should work, before submitting this formally. Thanks! - Chris. So this will confuse things a lot if the user doesn't have only rpm stuff on one partition, and everything else on another. This is potentially a major risk. How would that be handled? Mr. nodata, As the URL notes under Detailed Description, that is not handled at all. It wraps all file I/O, yum or not, into the snapshot. A bloody awful solution, especially when you consider that btrfs' maintainer Chris Mason is adding support for real userland transactions (via some additional ioctls). Yeah but you can't roll back userland transactions. Not to mention you are talking about an interface that may change quite a bit over the next year. We have snapshotting abilities now, and yes it's a big hammer, but just because its a bit of a blunt instrument doesn't mean we shouldn't take advantage of it. Thanks, Josef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken deps for rawhide the past few days
On Mon, Nov 16, 2009 at 7:22 PM, Jesse Keating jkeat...@redhat.com wrote: Many of you received emails over the weekend and this morning regarding broken deps in rawhide. If these emails mentioned that the deps were broken on ppc or ppc64 they can be ignored. We are no longer producing ppc/ppc64 as a primary arch, however we forgot to tag the config change that enacted this on our compose tools. We were attempting to compose ppc(64) trees with only noarch packages, and well things didn't work so hot. We should have this fixed today so that future emails about broken deps will be about actual broken deps, not broken configurations. Sorry for the mailbombing. Seems its underway again today for the ppc/ppc64. Cheers, Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken deps for rawhide the past few days
On 11/16/2009 08:22 PM, Jesse Keating wrote: Many of you received emails over the weekend and this morning regarding broken deps in rawhide. If these emails mentioned that the deps were broken on ppc or ppc64 they can be ignored. We are no longer producing ppc/ppc64 as a primary arch, however we forgot to tag the config change that enacted this on our compose tools. We were attempting to compose ppc(64) trees with only noarch packages, and well things didn't work so hot. We should have this fixed today so that future emails about broken deps will be about actual broken deps, not broken configurations. Sorry for the mailbombing. Seems as if you once more failed to fix this. The 4th flood of mail (ca. 1200 each) seems to be underway. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, 2009-11-17 at 08:10 -0500, Josef Bacik wrote: On Tue, Nov 17, 2009 at 2:48 AM, Jeff Garzik jgar...@pobox.com wrote: As the URL notes under Detailed Description, that is not handled at all. It wraps all file I/O, yum or not, into the snapshot. Yeah but you can't roll back userland transactions. Not to mention you are talking about an interface that may change quite a bit over the next year. That seems like a significant limitation, I'm also not sure that the current transaction API would be usable by rpm. Anyway... We have snapshotting abilities now, and yes it's a big hammer, but just because its a bit of a blunt instrument doesn't mean we shouldn't take advantage of it. This implies that all you have is a hammer but you can already run yum history undo. -- James Antill - ja...@fedoraproject.org I'd just like to see a realistic approach to updates via packages. -- Les Mikesell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken deps for rawhide the past few days
On Mon, 2009-11-16 at 11:22 -0800, Jesse Keating wrote: Many of you received emails over the weekend and this morning regarding broken deps in rawhide. If these emails mentioned that the deps were broken on ppc or ppc64 they can be ignored. We are no longer producing ppc/ppc64 as a primary arch, however we forgot to tag the config change that enacted this on our compose tools. We were attempting to compose ppc(64) trees with only noarch packages, and well things didn't work so hot. We should have this fixed today so that future emails about broken deps will be about actual broken deps, not broken configurations. Sorry for the mailbombing. *sigh* While we were successful in building a new mash package that would avoid making ppc repos, we forgot to update one of the rawhide creation configs so that it used dist-f13 content as opposed to dist-f12. So the rawhide creation process has been using dist-f12 content all this time to build up the chroot, which would then compose dist-f13 content. This means that the dist-f12 version of mash was used, not the dist-f13 version we built to disable ppc. I've corrected that. Third try to kill the ppc deps should be the charm. -- 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-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: RFC: Btrfs snapshots feature for F13
Hi all, It'd be great to get feedback on whether this is the right idea, and how exactly the UI interaction should work, before submitting this formally. Some off-list feedback so far: * People want independent active snapshots per filesystem (i.e. btrfs /home is the live filesystem, and btrfs / is an older snapshot), which makes sense but makes the UI more complex since it'll have to show a list of (filesystem, snapshot) tuples. * Ray says not to invent a new system-config-blah, and instead to talk with davidz about Palimpsest. David, what do you think? * Several people think that the ZFS Time Slider patches to nautilus¹ look good, and want that for btrfs. Sounds plausible², but I'm personally less interested in file versioning via snapshots and more interested in working on ways to let developers feel comfortable upgrading to Rawhide daily, for the next release. * Someone on the feature's Talk Page suggests that we should encourage people using anaconda to create a btrfs rootfs separate to their /home, so that they can rollback rootfs snapshots without affecting their homedir. Could work; maybe an anaconda dialog that says hey, I see you're choosing btrfs, we're going to turn on snapshots and we suggest you use a separate /home partition. Any more thoughts? Thanks! - Chris. ¹: http://blogs.sun.com/erwann/entry/zfs_on_the_desktop_zfs http://blogs.sun.com/erwann/entry/time_slider_screencast http://blogs.sun.com/erwann/entry/new_time_slider_features_in ²: It's a bit awkward; you have to do a mount on each snapshot to be able to show the directory listing for it, but it appears that's what ZFS/Time Slider does already, so it won't be any worse.. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 texlive-Asana-Math conflict
On Tue, Nov 17, 2009 at 08:09:38AM -0500, Neal Becker wrote: Jindrich Novy wrote: On Sun, Nov 15, 2009 at 07:37:54PM -0500, Neal Becker wrote: -- Processing Dependency: texlive-Asana-Math = 2009 for package: texlive- collection-fontsextra-2009-2.13989.fc12.noarch --- Package texlive-asana-math-fedora-fonts.noarch 0:2009-2.0.926.15878.fc12 set to be updated -- Finished Dependency Resolution texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has depsolving problems -- Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Fixed. texlive-Asana-Math-fedora-fonts-2009-2.0.926.15878.fc12.noarch from installed has depsolving problems -- Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-Asana-Math-fedora-fonts-2009-2.0.926.15878.fc12.noarch (installed) texlive-collection-fontsextra-2009-2.13989.fc12.noarch from installed has depsolving problems -- Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Skip-broken could not solve problems Error: Missing Dependency: texlive-linearA = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Error: Missing Dependency: texlive-Asana-Math = 2009 is needed by package texlive-collection-fontsextra-2009-2.13989.fc12.noarch (installed) Old yum metadata. yum clean all, yum update resolves that. Note that texlive-linearA and texlive-Asana-Math are no more present in the repository and are replaced by texlive-asana-math and texlive-lineara which correctly obsoletes the old ones. This is because of the font guidelines which require packages containing fonts to be lower case. Please report further problems to: http://bugzilla.redhat.com/488651 in order to not to spam fedora-devel list. Thanks, Jindrich -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, 17 Nov 2009, James Antill wrote: On Tue, 2009-11-17 at 08:10 -0500, Josef Bacik wrote: On Tue, Nov 17, 2009 at 2:48 AM, Jeff Garzik jgar...@pobox.com wrote: As the URL notes under Detailed Description, that is not handled at all. It wraps all file I/O, yum or not, into the snapshot. Yeah but you can't roll back userland transactions. Not to mention you are talking about an interface that may change quite a bit over the next year. That seems like a significant limitation, I'm also not sure that the current transaction API would be usable by rpm. Anyway... We have snapshotting abilities now, and yes it's a big hammer, but just because its a bit of a blunt instrument doesn't mean we shouldn't take advantage of it. This implies that all you have is a hammer but you can already run yum history undo. which works up to a point. If the older pkgs you had prior to an update are not available anywhere history undo isn't going to be able to 'undo' but so much. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Hi, This implies that all you have is a hammer but you can already run yum history undo. which works up to a point. If the older pkgs you had prior to an update are not available anywhere history undo isn't going to be able to 'undo' but so much. And of course, it's not going to work if Rawhide's broken something anywhere in the yum/rpm/*kit/etc stack, or if prelink's hosed every binary on your system again, or so on. But this would. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On 11/17/2009 02:48 AM, Jeff Garzik wrote: On 11/17/2009 02:43 AM, nodata wrote: Am 2009-11-17 01:55, schrieb Chris Ball: Hi, I've written up a draft of an F13 filesystem rollback feature using Btrfs snapshots that are automatically created by yum: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs It'd be great to get feedback on whether this is the right idea, and how exactly the UI interaction should work, before submitting this formally. Thanks! - Chris. So this will confuse things a lot if the user doesn't have only rpm stuff on one partition, and everything else on another. This is potentially a major risk. How would that be handled? Mr. nodata, As the URL notes under Detailed Description, that is not handled at all. It wraps all file I/O, yum or not, into the snapshot. A bloody awful solution, especially when you consider that btrfs' maintainer Chris Mason is adding support for real userland transactions (via some additional ioctls). Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. If they do, that'd be really interesting for upgrades. -- Peter If you're not part of the solution, then you're part of the precipitate. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 massive dep problem today
Jindrich Novy jn...@redhat.com writes: On Tue, Nov 17, 2009 at 06:53:25AM -0500, Neal Becker wrote: Lots of errors like these: Error: Missing Dependency: libc.so.6(GLIBC_2.11)(64bit) is needed by package texlive-luatex-bin-2009-2.15878.fc12.x86_64 (texlive) Error: Missing Dependency: libpoppler.so.5()(64bit) is needed by package texlive-jadetex-bin-2009-2.15878.fc12.x86_64 (texlive) This one looks serious. Are you using the f12/rawhide TL repo on a rawhide system? If so, I need to separate the F12/rawhide repositories because of the glibc change in rawhide. So F12 and rawhide binary packages are no more compatible. libc.so.6(GLIBC_2.11)(64bit) is provided by both f12 and rawhide glibc. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, Nov 17, 2009 at 10:36 AM, David Zeuthen da...@fubar.dk wrote: (I'm not subscribed to fedora-devel-list so if you expect an answer please Cc me) On Tue, 2009-11-17 at 09:52 -0500, Chris Ball wrote: * Ray says not to invent a new system-config-blah, and instead to talk with davidz about Palimpsest. David, what do you think? Yep, we're planning to add support to DeviceKit-disks for exposing the (privileged) operations that btrfs may expose (locked down by polkit, etc etc). There are also plans to expose these operations in the UI in Palimpsest and/or Nautilus. I don't think snapshots is going to have any Palimpsest UI (it belongs in Nautilus I think) but the multi-disk stuff definitely will. Talking about sliders and various btrfs bits in Nautilus, I would just like to point out that there are other desktops and file managers to consider. It should be possible to perform the same operations via GUI in KDE or xfce. Whether this means keeping stuff in a seperate, desktop agnostic, application (like a system-config or Palimpset) or making changes to Dolphin, etc as well I don't know. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Peter Jones pjo...@redhat.com writes: Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term commit than is standard to database people. regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Drop wodim, use cdrskin instead?
Contrary to what the man page says, wodim doesn't automatically format DVD+RWs, so you have to fully format the disc in advance before using wodim to write it. https://bugzilla.redhat.com/show_bug.cgi?id=519465 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: Package name conflict: eina, the media player or optimized data types and useful tools for e-17.
On 11/12/2009 12:06 AM, Ding Yi Chen wrote: Hi, I've tried to build e-17 by hand. When I try to build from eina from e-17, however, I found that the package name, eina, is already been taken by eina, the media player. How should I do with them? Off the top of my head, I'd suggest naming it libeina. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: id3lib stack smashing
On 11/12/2009 01:39 PM, Adrian Reber wrote: There is ubuntu bug report against id3lib libid3 crashes (stack smashing) when reading VBR MP3 file[1]. I am able to reproduce this on ubuntu but not on Fedora and I do not understand why. The patch[2] looks like it is doing the right thing but there is not stack smashing detected using the Fedora version (even on ubuntu). I have looked at the ubuntu build logs[3] and it uses completely different compiler flags. Is one of those flags the reason for not seeing the stack smashing on Fedora? It's possible, but that patch looks obviously correct. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ilbsndfile update!
On 11/14/2009 05:59 AM, Orcan Ogetbil wrote: Hi folks, After getting okays from a few folks I decided to fix the long standing libsndfile bugs. One of these was a request [1] to split the utilities that come with libsndfile into a utils subpackage. I did this only for F-13. Since libsndfile is used by so many other software, it is impractical for me to check all of these software to see if any of them depends on these command line utilities. If you have a package that depends on libsndfile, it would be good to check whether it uses these utilities. Then you'll need to require libsndfile-utils directly. If your package just needs the library there is nothing to worry about. Again, the utils split is only made in F-13. Other than that, libsndfile is updated to 1.0.20 in F-10+. Also, now it has the libvorbis support enabled. Thanks for taking care of this. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, 2009-11-17 at 11:48 -0500, Tom Lane wrote: Peter Jones pjo...@redhat.com writes: Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term commit than is standard to database people. No it's just a new definition of rollback than is standard. The idea is that _ideally_ people seem to _want_ to be able to do: 1. update to new foo 2. run random other things that alter data. 3. update to new bar 4. run random other things that alter data. 5. run new foo, which alters it's data. 6. run random other things that alter data. 7. run new bar, which alters it's data. 8. run random other things that alter data. 9a. Decide foo is bad and thus. rollback just #1 and #5. 9b. Decide bar is bad and thus. rollback just #3 and #7. ...so all solutions tend to be exercises in randomly picking the features you think they really want, from what is desired. Yum history assumes you are happy with just #1 and/or #3. Snapshots assume you are happy to take a lot of collateral damage to get #5 and/or #7. -- 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: RFC: Btrfs snapshots feature for F13
tis 2009-11-17 klockan 02:48 -0500 skrev Jeff Garzik: A bloody awful solution, especially when you consider that btrfs' maintainer Chris Mason is adding support for real userland transactions (via some additional ioctls). Yes. But the draft proposal is presented as tools for experienced people rather than cool feature for all, so I don't see the harm. (Check the uses cases under Benefit to Fedora.) /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 massive dep problem today
On Tue, Nov 17, 2009 at 05:37:32PM +0100, Andreas Schwab wrote: Jindrich Novy jn...@redhat.com writes: On Tue, Nov 17, 2009 at 06:53:25AM -0500, Neal Becker wrote: Lots of errors like these: Error: Missing Dependency: libc.so.6(GLIBC_2.11)(64bit) is needed by package texlive-luatex-bin-2009-2.15878.fc12.x86_64 (texlive) Error: Missing Dependency: libpoppler.so.5()(64bit) is needed by package texlive-jadetex-bin-2009-2.15878.fc12.x86_64 (texlive) This one looks serious. Are you using the f12/rawhide TL repo on a rawhide system? If so, I need to separate the F12/rawhide repositories because of the glibc change in rawhide. So F12 and rawhide binary packages are no more compatible. libc.so.6(GLIBC_2.11)(64bit) is provided by both f12 and rawhide glibc. Andreas. Thanks. In that case it is not a problem on the TeX Live side. Just to be sure have just created a new repository solely for F13 to avoid such surprises. Jindrich -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On 11/17/2009 11:48 AM, Tom Lane wrote: Peter Jones pjo...@redhat.com writes: Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term commit than is standard to database people. Yes, that's why I included the extra words. -- Peter If you're not part of the solution, then you're part of the precipitate. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 massive dep problem today
Jindrich Novy wrote: On Tue, Nov 17, 2009 at 06:53:25AM -0500, Neal Becker wrote: Lots of errors like these: Error: Missing Dependency: libc.so.6(GLIBC_2.11)(64bit) is needed by package texlive-luatex-bin-2009-2.15878.fc12.x86_64 (texlive) Error: Missing Dependency: libpoppler.so.5()(64bit) is needed by package texlive-jadetex-bin-2009-2.15878.fc12.x86_64 (texlive) This one looks serious. Are you using the f12/rawhide TL repo on a rawhide system? If so, I need to separate the F12/rawhide repositories because of the glibc change in rawhide. So F12 and rawhide binary packages are no more compatible. Jindrich No, that was just F11. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, Nov 17, 2009 at 1:33 PM, James Antill ja...@fedoraproject.org wrote: On Tue, 2009-11-17 at 11:48 -0500, Tom Lane wrote: Peter Jones pjo...@redhat.com writes: Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term commit than is standard to database people. No it's just a new definition of rollback than is standard. The idea is that _ideally_ people seem to _want_ to be able to do: 1. update to new foo 2. run random other things that alter data. 3. update to new bar 4. run random other things that alter data. 5. run new foo, which alters it's data. 6. run random other things that alter data. 7. run new bar, which alters it's data. 8. run random other things that alter data. 9a. Decide foo is bad and thus. rollback just #1 and #5. 9b. Decide bar is bad and thus. rollback just #3 and #7. ...so all solutions tend to be exercises in randomly picking the features you think they really want, from what is desired. Yum history assumes you are happy with just #1 and/or #3. Snapshots assume you are happy to take a lot of collateral damage to get #5 and/or #7. Sure, this isn't a perfect solution, it's just a nice to have feature if you care for it. It's nice to take a complete snapshot of your system right before you update just in case something goes horribly wrong and you lose say configuration files or some such. If you modified other things and have to rollback, you can always just mount the newer snapshot when you boot into the old snapshot and copy the new data that you want back. This isn't for the faint of heart, I envisioned it really for people who want to play the rawhide game with less exposure to its instability. Thanks, Josef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, 2009-11-17 at 14:05 -0500, Josef Bacik wrote: On Tue, Nov 17, 2009 at 1:33 PM, James Antill ja...@fedoraproject.org wrote: On Tue, 2009-11-17 at 11:48 -0500, Tom Lane wrote: Peter Jones pjo...@redhat.com writes: Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term commit than is standard to database people. No it's just a new definition of rollback than is standard. The idea is that _ideally_ people seem to _want_ to be able to do: 1. update to new foo 2. run random other things that alter data. 3. update to new bar 4. run random other things that alter data. 5. run new foo, which alters it's data. 6. run random other things that alter data. 7. run new bar, which alters it's data. 8. run random other things that alter data. 9a. Decide foo is bad and thus. rollback just #1 and #5. 9b. Decide bar is bad and thus. rollback just #3 and #7. ...so all solutions tend to be exercises in randomly picking the features you think they really want, from what is desired. Yum history assumes you are happy with just #1 and/or #3. Snapshots assume you are happy to take a lot of collateral damage to get #5 and/or #7. Sure, this isn't a perfect solution, it's just a nice to have feature if you care for it. It's nice to take a complete snapshot of your system right before you update just in case something goes horribly wrong and you lose say configuration files or some such. If you modified other things and have to rollback, you can always just mount the newer snapshot when you boot into the old snapshot and copy the new data that you want back. This isn't for the faint of heart, I envisioned it really for people who want to play the rawhide game with less exposure to its instability. Thanks, Josef It also works well for people who have things like homedir backup going nightly, but not full system backup. Restore to the way it was before the last yum update, recover important things from backup. It's an oh shit handle that has saved my bacon on other platforms before. -- 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: RFC: Btrfs snapshots feature for F13
On 11/17/2009 11:48 AM, Tom Lane wrote: Peter Jones pjo...@redhat.com writes: Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term commit than is standard to database people. So, I guess I should expand some more on what I'm saying. The problem here is that normal database-like transactions don't help an upgrade much, because you don't really know whether you want to commit the changes until you've rebooted the machine and poked around for a bit. Or, put another way, what you basically want is: 1 create an fs snapshot 2 do an upgrade 3 reboot machine 4 poke around 5 decide if it's good (6a) or bad (6b) 6 act on #5 a - remove snapshot b - abandon all changes after the snapshot And if you're talking about implementing that with database-like semantics, then you want something non-traditional such as: 1 start transaction 2 upgrade 3 tentatively commit transaction 4 reboot machine 5 poke around 6 decide if it's good (6a) or bad (6b) 7 act on #6 a - fully commit transaction b - roll back These obviously aren't the traditional semantics, hence I'm asking if it has semantics like that, because if it doesn't, then I don't really see Jeff's point. -- Peter If you're not part of the solution, then you're part of the precipitate. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, Nov 17, 2009 at 2:09 PM, Peter Jones pjo...@redhat.com wrote: On 11/17/2009 11:48 AM, Tom Lane wrote: Peter Jones pjo...@redhat.com writes: Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term commit than is standard to database people. So, I guess I should expand some more on what I'm saying. The problem here is that normal database-like transactions don't help an upgrade much, because you don't really know whether you want to commit the changes until you've rebooted the machine and poked around for a bit. Or, put another way, what you basically want is: 1 create an fs snapshot 2 do an upgrade 3 reboot machine 4 poke around 5 decide if it's good (6a) or bad (6b) 6 act on #5 a - remove snapshot b - abandon all changes after the snapshot And if you're talking about implementing that with database-like semantics, then you want something non-traditional such as: 1 start transaction 2 upgrade 3 tentatively commit transaction 4 reboot machine 5 poke around 6 decide if it's good (6a) or bad (6b) 7 act on #6 a - fully commit transaction b - roll back These obviously aren't the traditional semantics, hence I'm asking if it has semantics like that, because if it doesn't, then I don't really see Jeff's point. It doesn't. Userspace transactions are _only_ to make sure that a set of operations go to disk at the same time. The original reason this was implemented was for ceph, a distributed filesystem that has a client that runs in userspace and needs to write to an inode and update an xattr on that inode at the same time in order to maintain filesystem consistency. Nowadays there is _no_ guarantee that the write to the inode and the write to the xattr will go into the same transaction, so the userspace transaction just makes sure that they do happen in the same transaction. It's not a snapshot or anything like that, its just a way to guarantee ordering. Thanks, Josef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On 11/17/2009 02:15 PM, Josef Bacik wrote: On Tue, Nov 17, 2009 at 2:09 PM, Peter Jones pjo...@redhat.com wrote: On 11/17/2009 11:48 AM, Tom Lane wrote: Peter Jones pjo...@redhat.com writes: Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term commit than is standard to database people. So, I guess I should expand some more on what I'm saying. The problem here is that normal database-like transactions don't help an upgrade much, because you don't really know whether you want to commit the changes until you've rebooted the machine and poked around for a bit. Or, put another way, what you basically want is: 1 create an fs snapshot 2 do an upgrade 3 reboot machine 4 poke around 5 decide if it's good (6a) or bad (6b) 6 act on #5 a - remove snapshot b - abandon all changes after the snapshot And if you're talking about implementing that with database-like semantics, then you want something non-traditional such as: 1 start transaction 2 upgrade 3 tentatively commit transaction 4 reboot machine 5 poke around 6 decide if it's good (6a) or bad (6b) 7 act on #6 a - fully commit transaction b - roll back These obviously aren't the traditional semantics, hence I'm asking if it has semantics like that, because if it doesn't, then I don't really see Jeff's point. It doesn't. Userspace transactions are _only_ to make sure that a set of operations go to disk at the same time. The original reason this was implemented was for ceph, a distributed filesystem that has a client that runs in userspace and needs to write to an inode and update an xattr on that inode at the same time in order to maintain filesystem consistency. Nowadays there is _no_ guarantee that the write to the inode and the write to the xattr will go into the same transaction, so the userspace transaction just makes sure that they do happen in the same transaction. It's not a snapshot or anything like that, its just a way to guarantee ordering. Thanks, Okay, so then I definitely don't see what jgarzik was getting at. -- Peter If you're not part of the solution, then you're part of the precipitate. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On 11/17/2009 12:05 PM, Josef Bacik wrote: Sure, this isn't a perfect solution, it's just a nice to have feature if you care for it. It's nice to take a complete snapshot of your system right before you update just in case something goes horribly wrong and you lose say configuration files or some such. If you modified other things and have to rollback, you can always just mount the newer snapshot when you boot into the old snapshot and copy the new data that you want back. This isn't for the faint of heart, I envisioned it really for people who want to play the rawhide game with less exposure to its instability. Thanks, I've long wanted to help with fedora rawhide a bit more but only really have it on the one computer I work on. So this would make it possible for me to do that. I think that's great. I have a few questions. Suppose I do an update, and it breaks X or some other important piece for me. I reboot into my previous snapshot. From there I continue to work. Do I have to remove the 'future' snapshot I came back from to continue working in that snapshot? Or is that just best practice. If I move forward, I'd have to move all the work I did in that snapshot to the head/snapshot that just got fixed with an update... Just thinking out loud here. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ilbsndfile update!
On Sat, Nov 14, 2009 at 10:59 AM, Orcan Ogetbil oget.fed...@gmail.com wrote: Hi folks, After getting okays from a few folks I decided to fix the long standing libsndfile bugs. One of these was a request [1] to split the utilities that come with libsndfile into a utils subpackage. I did this only for F-13. Since libsndfile is used by so many other software, it is impractical for me to check all of these software to see if any of them depends on these command line utilities. If you have a package that depends on libsndfile, it would be good to check whether it uses these utilities. Then you'll need to require libsndfile-utils directly. If your package just needs the library there is nothing to worry about. Again, the utils split is only made in F-13. Other than that, libsndfile is updated to 1.0.20 in F-10+. Also, now it has the libvorbis support enabled. Any chance of getting the jack-audio-connection-kit dependency split out into a sub package? Cheers, Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Questions sent (was: What questions would you like to ask the Candidates for the Fedora Board, FESCo, and FAMSCO?)
On 17.11.2009 07:54, Thorsten Leemhuis wrote: Thorsten Leemhuis wrote on 11.11.2009 22:30: As you may have heard already, several seats of the Fedora Board, FESCo, and FAMSCO are up for election soon(¹). Right now we are in the nomination period, which will be followed by a Candidate Questionnaire. That means we'll give candidates a list of questions to answer by private mail within one week after the nomination period closed; the results will be publish soon after that to make sure they are available to the public before the Town Hall meetings on IRC happen. [...] If you have one or more questions you'd like to send to the candidates simply go and add them to: https://fedoraproject.org/wiki/Elections/F13_Questionnaire I did some cleanups and added a few more question from the last questionnaire. Find below what I plan to sent to the candidates this evening at something like 19:00 UTC. If you dislike something please comment until then in a way to make sure we don't further delay things (yes, I know, that is a tight schedule, but I thought a RFC period of 12 hours is better then none). tia! Nobody yelled, so I sent the questions to the people that are running in the elections by mail to the address from FAS. If you are one of those that are running and didn't get my mail please let me know asap. Deadline for answers: 20091124-06:00 UTC (the easier to remember date variant: have them finished by next Monday before midnight). I'll soon afterwards will try compile some documents that allow easy comparison of the answers. Cu knurd -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ilbsndfile update!
On Tue, Nov 17, 2009 at 2:38 PM, Peter Robinson wrote: On Sat, Nov 14, 2009 at 10:59 AM, Orcan Ogetbil wrote: Hi folks, After getting okays from a few folks I decided to fix the long standing libsndfile bugs. One of these was a request [1] to split the utilities that come with libsndfile into a utils subpackage. I did this only for F-13. Since libsndfile is used by so many other software, it is impractical for me to check all of these software to see if any of them depends on these command line utilities. If you have a package that depends on libsndfile, it would be good to check whether it uses these utilities. Then you'll need to require libsndfile-utils directly. If your package just needs the library there is nothing to worry about. Again, the utils split is only made in F-13. Other than that, libsndfile is updated to 1.0.20 in F-10+. Also, now it has the libvorbis support enabled. Any chance of getting the jack-audio-connection-kit dependency split out into a sub package? I think that the jack dependency comes from one of the command line utilities of libsndfile which are now separated into the libsndfile-tools package. Note that here now means F-13+. I didn't want to make the split on F-12 and before as it might break potential direct dependencies on these utilities. This will give packagers a full release cycle to find regressions if there are any. Or am I too paranoid? Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On 11/17/2009 02:07 PM, Jesse Keating wrote: It also works well for people who have things like homedir backup going nightly, but not full system backup. Restore to the way it was before the last yum update, recover important things from backup. It's an oh shit handle that has saved my bacon on other platforms before. I'm not sure how much of this can/should be automated. From the way btrfs snapshots work the ideal workflow should be: 1) /user/ takes a snapshot. 2) user runs yum 3) rebooting/poking/(possibly) restoring I think the best value add to this would be a yum plugin that simply emits a warning along the lines of Your last snapshot is ### hours old. Are you sure you want to continue? This also keeps us out of the dangerous territory that comes with using non-ubiquitous FS features (your boot is on ext3, your root is on btrfs, your etc is on xfs and your usr is on jfs. What do you snapshot and how?) --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ilbsndfile update!
On Tue, Nov 17, 2009 at 8:15 PM, Orcan Ogetbil oget.fed...@gmail.com wrote: On Tue, Nov 17, 2009 at 2:38 PM, Peter Robinson wrote: On Sat, Nov 14, 2009 at 10:59 AM, Orcan Ogetbil wrote: Hi folks, After getting okays from a few folks I decided to fix the long standing libsndfile bugs. One of these was a request [1] to split the utilities that come with libsndfile into a utils subpackage. I did this only for F-13. Since libsndfile is used by so many other software, it is impractical for me to check all of these software to see if any of them depends on these command line utilities. If you have a package that depends on libsndfile, it would be good to check whether it uses these utilities. Then you'll need to require libsndfile-utils directly. If your package just needs the library there is nothing to worry about. Again, the utils split is only made in F-13. Other than that, libsndfile is updated to 1.0.20 in F-10+. Also, now it has the libvorbis support enabled. Any chance of getting the jack-audio-connection-kit dependency split out into a sub package? I think that the jack dependency comes from one of the command line utilities of libsndfile which are now separated into the libsndfile-tools package. Note that here now means F-13+. I didn't want to make the split on F-12 and before as it might break potential direct dependencies on these utilities. This will give packagers a full release cycle to find regressions if there are any. Or am I too paranoid? F-13+ is just fine. Cheers, Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Status of maven 2.2.1 update in rawhide
Hi Everyone, Sorry for the cross-list posting, but the matter is of interest to both lists afaict, as I have seen messages related to maven on both. As some of you might know, we intend to put maven 2.2.1 in rawhide. The new maven will be a completely re-written rpm, one that should be a lot easier to maintain, and much more stable. All progress related to this upgrade is now on the wiki: https://fedoraproject.org/wiki/MavenUpdate Updates/new packages for dependencies will be a significant effort. Once we (Andrew Overholt, Alexander Kurtakov and myself) start work on that, we will need all the help we can get :) So if you are interested in helping, or just tracking progress -- that is the page to subscribe to/check out! I'll send one more mail to this list when work on dependencies starts. Cheers, Deepak -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Hi, I'm not sure how much of this can/should be automated. Sorry, not quite following -- what is the caution around automatically creating a new snapshot before each yum transaction? Why shouldn't it be automated? This also keeps us out of the dangerous territory that comes with using non-ubiquitous FS features (your boot is on ext3, your root is on btrfs, your etc is on xfs and your usr is on jfs. What do you snapshot and how?) This feature would snapshot the btrfs / only, but that doesn't matter, because snapshots don't do anything until the user chooses to initiate a rollback. The user who chooses a btrfs / and a jfs /usr knows what happens when they rollback only the btrfs filesystem. (And we can print a warning to make sure of that if we decide it's necessary.) Thanks, - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On 11/17/2009 03:56 PM, Chris Ball wrote: Hi, I'm not sure how much of this can/should be automated. Sorry, not quite following -- what is the caution around automatically creating a new snapshot before each yum transaction? Why shouldn't it be automated? I somewhat read the initial suggestion as trying to implement transactional behavior via snapshot. Just creating one shouldn't hurt. This also keeps us out of the dangerous territory that comes with using non-ubiquitous FS features (your boot is on ext3, your root is on btrfs, your etc is on xfs and your usr is on jfs. What do you snapshot and how?) This feature would snapshot the btrfs / only, but that doesn't matter, because snapshots don't do anything until the user chooses to initiate a rollback. The user who chooses a btrfs / and a jfs /usr knows what happens when they rollback only the btrfs filesystem. (And we can print a warning to make sure of that if we decide it's necessary.) We've now created a useless and slightly dangerous object though. Regardless of the competence of the user who's problem that is, better to avoid it if we can. Thanks, - Chris. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [SoaS] Booting Fedora live USB on MacBookPro
On 2009/11/16 10:56 AM, Peter Jones wrote: On 11/11/2009 01:30 AM, Stewart Adam wrote: On 2009/11/10 5:41 PM, Peter Jones wrote: On 11/10/2009 05:37 PM, Caryl Bigenho wrote: Hi, My MacBook is a 4,1. Will it work on my machine? A 64-bit EFI image should work on a MacBook4,1 . A 32-bit EFI image won't. If the silver MBP is also a 4,1 model, there may be complications... There are some video initialization problems [1] when booting EFI kernels. Stewart [1] https://bugzilla.redhat.com/show_bug.cgi?id=496134 Yeah. If somebody had one of these machines at FudCon in Toronto, I could probably knock this out in relatively short time. I know that it can be harder to debug if you're not at the machine, but if I can provide you with any info I'll be happy to do so - just let me know what I need to do. Stewart -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Hi, We've now created a useless and slightly dangerous object though. Regardless of the competence of the user who's problem that is, better to avoid it if we can. Okay. Perhaps the automated snapshot creation algorithm should be amended to something like: check /proc/mounts for at least one btrfs, and zero other non-btrfs filesystems, except for /boot which can be anything. Thanks, - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Hi, I somewhat read the initial suggestion as trying to implement transactional behavior via snapshot. Just creating one shouldn't hurt. Ah. Yeah, not at all. I fail to understand how a snapshot would differentiate between yum related changes and other changes that occur by an otherwise normally operating daemon (logs for example). If someone wanted to use whole-fs snapshots for yum transactions (which I don't) the way to do it would be to only rollback changes made to files that are present in either of the RPM manifests. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Am 2009-11-17 19:33, schrieb Alexander Boström: tis 2009-11-17 klockan 02:48 -0500 skrev Jeff Garzik: A bloody awful solution, especially when you consider that btrfs' maintainer Chris Mason is adding support for real userland transactions (via some additional ioctls). Yes. But the draft proposal is presented as tools for experienced people It has a gui... rather than cool feature for all, so I don't see the harm. (Check the uses cases under Benefit to Fedora.) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [SoaS] Booting Fedora live USB on MacBookPro
On 11/17/2009 04:17 PM, Stewart Adam wrote: On 2009/11/16 10:56 AM, Peter Jones wrote: On 11/11/2009 01:30 AM, Stewart Adam wrote: On 2009/11/10 5:41 PM, Peter Jones wrote: On 11/10/2009 05:37 PM, Caryl Bigenho wrote: Hi, My MacBook is a 4,1. Will it work on my machine? A 64-bit EFI image should work on a MacBook4,1 . A 32-bit EFI image won't. If the silver MBP is also a 4,1 model, there may be complications... There are some video initialization problems [1] when booting EFI kernels. Stewart [1] https://bugzilla.redhat.com/show_bug.cgi?id=496134 Yeah. If somebody had one of these machines at FudCon in Toronto, I could probably knock this out in relatively short time. I know that it can be harder to debug if you're not at the machine, but if I can provide you with any info I'll be happy to do so - just let me know what I need to do. There's nothing to /debug/. Somebody needs to figure out where the framebuffer is and what it's dimensions are, and then it needs to be added to the table. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Drop wodim, use cdrskin instead?
Contrary to what the man page says, wodim doesn't automatically format DVD+RWs, so you have to fully format the disc in advance before using wodim to write it. https://bugzilla.redhat.com/show_bug.cgi?id=519465 Thanks. :) As I know that's not the only thing that's not fixed in Wodim and fixed in Cdrskin.. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken deps for rawhide the past few days
On Tuesday 17 November 2009 06:50:58 am Jesse Keating wrote: On Mon, 2009-11-16 at 11:22 -0800, Jesse Keating wrote: Many of you received emails over the weekend and this morning regarding broken deps in rawhide. If these emails mentioned that the deps were broken on ppc or ppc64 they can be ignored. We are no longer producing ppc/ppc64 as a primary arch, however we forgot to tag the config change that enacted this on our compose tools. We were attempting to compose ppc(64) trees with only noarch packages, and well things didn't work so hot. We should have this fixed today so that future emails about broken deps will be about actual broken deps, not broken configurations. Sorry for the mailbombing. *sigh* While we were successful in building a new mash package that would avoid making ppc repos, we forgot to update one of the rawhide creation configs so that it used dist-f13 content as opposed to dist-f12. So the rawhide creation process has been using dist-f12 content all this time to build up the chroot, which would then compose dist-f13 content. This means that the dist-f12 version of mash was used, not the dist-f13 version we built to disable ppc. I've corrected that. Third try to kill the ppc deps should be the charm. Could we just not send emails tomorrow, double check that it produces the correct result, and re-enable them for the next day? In case there's something else we-shouldn't-have-missed-but-we-did? -- Conrad Meyer ceme...@u.washington.edu -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken deps for rawhide the past few days
On Nov 17, 2009, at 14:47, Conrad Meyer ceme...@u.washington.edu wrote: On Tuesday 17 November 2009 06:50:58 am Jesse Keating wrote: On Mon, 2009-11-16 at 11:22 -0800, Jesse Keating wrote: Many of you received emails over the weekend and this morning regarding broken deps in rawhide. If these emails mentioned that the deps were broken on ppc or ppc64 they can be ignored. We are no longer producing ppc/ppc64 as a primary arch, however we forgot to tag the config change that enacted this on our compose tools. We were attempting to compose ppc(64) trees with only noarch packages, and well things didn't work so hot. We should have this fixed today so that future emails about broken deps will be about actual broken deps, not broken configurations. Sorry for the mailbombing. *sigh* While we were successful in building a new mash package that would avoid making ppc repos, we forgot to update one of the rawhide creation configs so that it used dist-f13 content as opposed to dist-f12. So the rawhide creation process has been using dist-f12 content all this time to build up the chroot, which would then compose dist-f13 content. This means that the dist-f12 version of mash was used, not the dist-f13 version we built to disable ppc. I've corrected that. Third try to kill the ppc deps should be the charm. Could we just not send emails tomorrow, double check that it produces the correct result, and re-enable them for the next day? In case there's something else we-shouldn't-have-missed-but-we-did? That's one of the changes I made today. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xorg and multitouch
On Tue, 2009-11-17 at 22:44 +, Ikem Krueger wrote: Some news? Planned for Fedora 13? The X level support is already in F12 - see http://fedoraproject.org/wiki/Features/XI2 . Application level support will come later -- 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: Xorg and multitouch
Am 2009-11-18 00:19, schrieb Adam Williamson: On Tue, 2009-11-17 at 22:44 +, Ikem Krueger wrote: Some news? Planned for Fedora 13? The X level support is already in F12 - see http://fedoraproject.org/wiki/Features/XI2 . Application level support will come later Is multi-touch the same as gesture support? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review request...
On Tue, 2009-11-17 at 16:10 -0700, Nathanael D. Noblet wrote: Hello, I just posted my first review request a few days ago. I think someone has been trying to help me through that process. Up to now I've felt like I've been following instructions. Could someone please review the information in the following (not necessarily review the request), to see if I've completely lost it and am not understanding what is being requested of me? I feel like I'm complying but got some odd message about not following instructions and so won't be helped. When I think I'm doing what they ask. Anyway a total packaging noob (for fedora atleast, we maintain a bunch of software in RPM format for CentOS and Fedora workstations inhouse). I've read the guidlines as best I can, and responded to requests on the review so I'm just wondering what I may be missing... https://bugzilla.redhat.com/show_bug.cgi?id=537587 Thanks, Nathanael Hm... on a very quick first look, you obviously don't follow https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Release Your release should look something like 0.x.BETA4, not just BETA4. Plus every time you update the SPEC, you should also increase the x ;-) I'm not sure if it's explicitly in the guidelines somewhere or not (haven't ever used this kind of thing myself), but you appear to generate subpackages based on some build time conditionals -- (at least IMHO) it's not a good approach. Do you really need these conditionals anyway? Why not just build all the subpackages that are worth building? Martin 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: Review request...
On Tue, 2009-11-17 at 21:45 -0200, Itamar Reis Peixoto wrote: Can you post this info in the bug report ? I was just about to at your request (I think one of the two places is enough ;-) but noticed that Nathan was faster in applying relevant changes. Note that I haven't done a throughout check, only pointed what I noticed on quick look, so there *might* be more problems. Supposing I'll take a closer look at it tomorrow (no promises though), I'll point out anything other that I find in the bug report itself. Martin 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: Name of the 'chess' package
On Mon, Nov 16, 2009 at 12:36:02 -0600, Bruno Wolff III br...@wolff.to wrote: We currently have a 3d chess game packaged as chess. I want to ask for fedora hosted space for it sop that we can be upstream for some modernization (with regard to ogre and gcc) changes. However it strikes me that the package name probably shouldn't have been 'chess' as that is a generic name. Before officially asking for fedora hosted space I wanted to see if there is sentiment to making some name change for F13+ and fedora hosted. Possibilities would be 3dchess (possibly still too generic), ogrechess (possibly misleading, as people might think it had ogres for pieces), chess-ogre or ? As a followup, I have opened a ticket (https://fedorahosted.org/fedora-infrastructure/ticket/1822) to request a project for this under the name ogrechess. I expect eventually to want to change the package name to match, but there isn't a hurry. I might end up treating it as a new package (after getting most of the cleanup done) and obsoleting the old one. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review request...
On Tue, Nov 17, 2009 at 04:10:48PM -0700, Nathanael D. Noblet wrote: Hello, I just posted my first review request a few days ago. I think someone has been trying to help me through that process. Up to now I've felt like I've been following instructions. Could someone please review the information in the following (not necessarily review the request), to see if I've completely lost it and am not understanding what is being requested of me? I feel like I'm complying but got some odd message about not following instructions and so won't be helped. When I think I'm doing what they ask. Anyway a total packaging noob (for fedora atleast, we maintain a bunch of software in RPM format for CentOS and Fedora workstations inhouse). I've read the guidlines as best I can, and responded to requests on the review so I'm just wondering what I may be missing... He is wanting you to increment Release each time you change something, and post a URL to the updated SRPM. There is a language barrier issue here, and the reviewer could have had a bit more patience. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xorg and multitouch
Hi, Multitouch means, several mousepointers and you can move them all seperately. No, that's what multi-pointer means. Multi-Pointer X is already in F12. Gesture support is, you make a certain sign with a mousepointer, and a certain action is triggered. Would be cool to see both together. I mean, several independent mousepointers, with each you can make a different gesture and different actions are triggered. ^^ I'm sure you can achieve this gesture support today, again using MPX in F12. Multitouch refers to technologies that involve extrapolating from motion of finger-shaped blobs on your input device to the idea that a user has performed some continuous motion with said finger(s), and reacting appropriately. It's not the same as multi-pointer X, but it does use the same core technology. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: intent to retire: kudzu
On Mon, Nov 16, 2009 at 10:58:24AM -0500, Peter Jones wrote: Really, temporarily removing this is more desirable than merely passing maintainership of kudzu around. Kudzu needs to actually go away. Yay! -- Matthew Miller mat...@mattdm.org Senior Systems Architect Cyberinfrastructure Labs / Instructional Research Computing Computing Information Technology Harvard School of Engineering Applied Sciences -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Hi David, thanks for the reply. Yep, we're planning to add support to DeviceKit-disks for exposing the (privileged) operations that btrfs may expose (locked down by polkit, etc etc). There are also plans to expose these operations in the UI in Palimpsest and/or Nautilus. I don't think snapshots is going to have any Palimpsest UI (it belongs in Nautilus I think) but the multi-disk stuff definitely will. I don't think it makes sense for the filesystem-level snapshot operations I describe in the feature proposal to be in Nautilus: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs The proposal is about system-administrator decisions on what your root directory on btrfs will look like at next boot; they should only be performed by someone deep into I am modifying the mount behavior of my fs mode. (It does make sense for a Time Slider port to Btrfs, working with file-level operations on snapshots, to live inside Nautilus. That's not part of this proposal, but would be very useful work.) Given the above, do you think you'd be okay with having: Filesystem snapshot that will be active on next boot: drop-down and Create new whole-filesystem snapshot now: label apply in a Btrfs-specific section in Palimpsest? That's all that's needed for the UI component of this feature. As always, DKD and Palimpsest is supposed to be complementary to the command-line tools. So all this is only relevant for creating nice UIs for managing btrfs. Yup, that's the case. (Oh, and if it turns out that creating/destroying btrfs snaphots isn't a privileged operation (I can't remember at this point) it would probably make sense for Nautilus to just use the btrfs tools directly instead of going through a system daemon. There's just no need to overcomplicate things.) Creating a new snapshot is unprivileged, but mounting an old one (which nautilus would need to do in order to show you the contents of a previous snapshot, so that you can decide which files you want to restore from it) requires a mount(8) call for each snapshot. Thanks, - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
On Tue, Nov 17, 2009 at 10:18 AM, Jesse Keating wrote: On Mon, 2009-11-16 at 17:11 -0600, Jason L Tibbitts III wrote: Actually not if done in conjunction with a release bump, such as we do with a mass rebuild. Only if we make a promise to never use the same base n-v-r across the releases until whichever release we did the mass rebuild on is retired. You are correct in that if we did a mass rebuild in dist-f13, we could move to .f##, but consider 3 days later a maintainer wants to push a new upstream release across the branches: foo-1.2-1.fc11 foo-1.2-1.fc12 foo-1.2-1.f13 We're back in the same boat where the fc packages will be n-v-r higher. Is RPM so hard to hack to work this around? Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
2009/11/17, Itamar Reis Peixoto ita...@ispbrasil.com.br: because renaming it will cause problems, for example. foo-1.0.fc10 foo-1.0.fc11 foo-1.0.fc11 foo-1.0.fc10 foo-1.0.fc10 foo-1.0.f11 foo-1.0.f11 foo-1.0.fc10 rpmdev-vercmp foo-1.0.f11 foo-1.0.fc10 0:foo-1.0.fc10 is newer Imho your argument is obsolete, because we rebuild all Packages for Massbranching, so the release is in every new branch higher, than in the branch before! -- Josephine Fine Tannhäuser 2.6.18-164.2.1.el5 2.6.30.9-90.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
On Nov 17, 2009, at 21:21, Josephine Tannhäuser josephine.tannhau...@googlemail.co m wrote: 2009/11/17, Itamar Reis Peixoto ita...@ispbrasil.com.br: because renaming it will cause problems, for example. foo-1.0.fc10 foo-1.0.fc11 foo-1.0.fc11 foo-1.0.fc10 foo-1.0.fc10 foo-1.0.f11 foo-1.0.f11 foo-1.0.fc10 rpmdev-vercmp foo-1.0.f11 foo-1.0.fc10 0:foo-1.0.fc10 is newer Imho your argument is obsolete, because we rebuild all Packages for Massbranching, so the release is in every new branch higher, than in the branch before! Only temporarily. Quite frequently all branches of a package willsync up and be the same n-v-r where only the dist tag sets them apart. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
On Wed, Nov 18, 2009 at 12:08:15AM -0500, Orcan Ogetbil wrote: On Tue, Nov 17, 2009 at 10:18 AM, Jesse Keating wrote: On Mon, 2009-11-16 at 17:11 -0600, Jason L Tibbitts III wrote: Actually not if done in conjunction with a release bump, such as we do with a mass rebuild. Only if we make a promise to never use the same base n-v-r across the releases until whichever release we did the mass rebuild on is retired. You are correct in that if we did a mass rebuild in dist-f13, we could move to .f##, but consider 3 days later a maintainer wants to push a new upstream release across the branches: foo-1.2-1.fc11 foo-1.2-1.fc12 foo-1.2-1.f13 We're back in the same boat where the fc packages will be n-v-r higher. Is RPM so hard to hack to work this around? There's many things that need to be changed in rpm but IMHO this isn't one of them. RPM produces predictable versioning. Hacking it up with special cases will lead nowhere but pain. -Toshio pgpy6hyyMSjM5.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Promoting i386 version over x86_64?
I noticed that http://fedoraproject.org/get-fedora appears to be strongly promoting i386 Fedora over x86_64. Is this intentional or an oversight? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 11/18/2009 01:32 AM, Gregory Maxwell wrote: I noticed that http://fedoraproject.org/get-fedora appears to be strongly promoting i386 Fedora over x86_64. Is this intentional or an oversight? I agree, that was my first impression as well. However, if you just want a single download now button, 32-bit would get you the widest hardware coverage. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
I think this is a script which reads your currently used architecture and provide a dl link. please insert a x86_64 livecd and try it again! 2009/11/18, Gregory Maxwell gmaxw...@gmail.com: I noticed that http://fedoraproject.org/get-fedora appears to be strongly promoting i386 Fedora over x86_64. Is this intentional or an oversight? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Josephine Fine Tannhäuser 2.6.18-164.2.1.el5 2.6.30.9-90.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Tuesday 17 November 2009 10:55:22 pm Josephine Tannhäuser wrote: I think this is a script which reads your currently used architecture and provide a dl link. please insert a x86_64 livecd and try it again! That doesn't appear to be true. I double checked that the user agent string Firefox is sending includes x86_64, and I still get the 32-bit version suggested. Regards, -- Conrad Meyer ceme...@u.washington.edu -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Issue 105084] OpenSymbol font: Math related changes
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=105084 User tl changed the following: What|Old value |New value OtherIssuesDependingOnTh|50314,53223,69108,75472,79|50314,53223,69108,75472,79 is|037,93925,105085,106815 |037,92203,93925,105085,106 | |815 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: oflb-prociono-fonts
oflb-prociono-fonts has broken dependencies in the development tree: On ppc: oflb-prociono-fonts-20090715-2.fc13.noarch requires /bin/sh oflb-prociono-fonts-20090715-2.fc13.noarch requires /bin/sh On ppc64: oflb-prociono-fonts-20090715-2.fc13.noarch requires /bin/sh oflb-prociono-fonts-20090715-2.fc13.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: serafettin-cartoon-fonts
serafettin-cartoon-fonts has broken dependencies in the development tree: On ppc: serafettin-cartoon-fonts-0.5.1-3.fc12.noarch requires /bin/sh serafettin-cartoon-fonts-0.5.1-3.fc12.noarch requires /bin/sh On ppc64: serafettin-cartoon-fonts-0.5.1-3.fc12.noarch requires /bin/sh serafettin-cartoon-fonts-0.5.1-3.fc12.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: lcdf-typetools
lcdf-typetools has broken dependencies in the development tree: On ppc: lcdf-typetools-2.79-2.fc12.ppc requires libm.so.6(GLIBC_2.1) lcdf-typetools-2.79-2.fc12.ppc requires libc.so.6(GLIBC_2.4) lcdf-typetools-2.79-2.fc12.ppc requires libc.so.6 lcdf-typetools-2.79-2.fc12.ppc requires libc.so.6(GLIBC_2.1) lcdf-typetools-2.79-2.fc12.ppc requires libm.so.6(GLIBC_2.0) lcdf-typetools-2.79-2.fc12.ppc requires rtld(GNU_HASH) lcdf-typetools-2.79-2.fc12.ppc requires libc.so.6(GLIBC_2.1.3) lcdf-typetools-2.79-2.fc12.ppc requires libc.so.6(GLIBC_2.0) lcdf-typetools-2.79-2.fc12.ppc requires libkpathsea.so.4 lcdf-typetools-2.79-2.fc12.ppc requires libc.so.6(GLIBC_2.3) lcdf-typetools-2.79-2.fc12.ppc requires libm.so.6 On ppc64: lcdf-typetools-2.79-2.fc12.ppc64 requires libm.so.6()(64bit) lcdf-typetools-2.79-2.fc12.ppc64 requires libc.so.6()(64bit) lcdf-typetools-2.79-2.fc12.ppc64 requires libkpathsea.so.4()(64bit) lcdf-typetools-2.79-2.fc12.ppc64 requires rtld(GNU_HASH) lcdf-typetools-2.79-2.fc12.ppc64 requires libm.so.6(GLIBC_2.3)(64bit) lcdf-typetools-2.79-2.fc12.ppc64 requires libc.so.6(GLIBC_2.4)(64bit) lcdf-typetools-2.79-2.fc12.ppc64 requires libc.so.6(GLIBC_2.3)(64bit) Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: gdouros-aegean-fonts
gdouros-aegean-fonts has broken dependencies in the development tree: On ppc: gdouros-aegean-fonts-3.01-2.fc13.noarch requires /bin/sh gdouros-aegean-fonts-3.01-2.fc13.noarch requires /bin/sh On ppc64: gdouros-aegean-fonts-3.01-2.fc13.noarch requires /bin/sh gdouros-aegean-fonts-3.01-2.fc13.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: cjkuni-fonts
cjkuni-fonts has broken dependencies in the development tree: On ppc: cjkuni-fonts-ghostscript-0.2.20080216.1-31.fc13.noarch requires ghostscript = 0:8.63-4 On ppc64: cjkuni-fonts-ghostscript-0.2.20080216.1-31.fc13.noarch requires ghostscript = 0:8.63-4 Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: apanov-heuristica-fonts
apanov-heuristica-fonts has broken dependencies in the development tree: On ppc: 1:apanov-heuristica-fonts-0.2-4.fc13.noarch requires /bin/sh 1:apanov-heuristica-fonts-0.2-4.fc13.noarch requires /bin/sh On ppc64: 1:apanov-heuristica-fonts-0.2-4.fc13.noarch requires /bin/sh 1:apanov-heuristica-fonts-0.2-4.fc13.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: fonts-ISO8859-2
fonts-ISO8859-2 has broken dependencies in the development tree: On ppc: fonts-ISO8859-2-75dpi-1.0-22.fc12.noarch requires /bin/sh fonts-ISO8859-2-75dpi-1.0-22.fc12.noarch requires mkfontdir On ppc64: fonts-ISO8859-2-75dpi-1.0-22.fc12.noarch requires /bin/sh fonts-ISO8859-2-75dpi-1.0-22.fc12.noarch requires mkfontdir On ppc: fonts-ISO8859-2-100dpi-1.0-22.fc12.noarch requires /bin/sh fonts-ISO8859-2-100dpi-1.0-22.fc12.noarch requires mkfontdir On ppc64: fonts-ISO8859-2-100dpi-1.0-22.fc12.noarch requires /bin/sh fonts-ISO8859-2-100dpi-1.0-22.fc12.noarch requires mkfontdir On ppc: fonts-ISO8859-2-1.0-22.fc12.noarch requires /bin/sh fonts-ISO8859-2-1.0-22.fc12.noarch requires mkfontdir On ppc64: fonts-ISO8859-2-1.0-22.fc12.noarch requires /bin/sh fonts-ISO8859-2-1.0-22.fc12.noarch requires mkfontdir Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: vollkorn-fonts
vollkorn-fonts has broken dependencies in the development tree: On ppc: vollkorn-fonts-1.008-4.fc12.noarch requires /bin/sh vollkorn-fonts-1.008-4.fc12.noarch requires /bin/sh On ppc64: vollkorn-fonts-1.008-4.fc12.noarch requires /bin/sh vollkorn-fonts-1.008-4.fc12.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: ns-tiza-chalk-fonts
ns-tiza-chalk-fonts has broken dependencies in the development tree: On ppc: ns-tiza-chalk-fonts-20080210-2.fc13.noarch requires /bin/sh ns-tiza-chalk-fonts-20080210-2.fc13.noarch requires /bin/sh On ppc64: ns-tiza-chalk-fonts-20080210-2.fc13.noarch requires /bin/sh ns-tiza-chalk-fonts-20080210-2.fc13.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: lohit-gujarati-fonts
lohit-gujarati-fonts has broken dependencies in the development tree: On ppc: lohit-gujarati-fonts-2.4.4-1.fc13.noarch requires /bin/sh lohit-gujarati-fonts-2.4.4-1.fc13.noarch requires /bin/sh On ppc64: lohit-gujarati-fonts-2.4.4-1.fc13.noarch requires /bin/sh lohit-gujarati-fonts-2.4.4-1.fc13.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: bpg-fonts
bpg-fonts has broken dependencies in the development tree: On ppc: bpg-nino-medium-fonts-4.005-7.fc12.noarch requires /bin/sh bpg-nino-medium-fonts-4.005-7.fc12.noarch requires /bin/sh On ppc64: bpg-nino-medium-fonts-4.005-7.fc12.noarch requires /bin/sh bpg-nino-medium-fonts-4.005-7.fc12.noarch requires /bin/sh On ppc: bpg-sans-regular-fonts-1.005-7.fc12.noarch requires /bin/sh bpg-sans-regular-fonts-1.005-7.fc12.noarch requires /bin/sh On ppc64: bpg-sans-regular-fonts-1.005-7.fc12.noarch requires /bin/sh bpg-sans-regular-fonts-1.005-7.fc12.noarch requires /bin/sh On ppc: bpg-courier-fonts-4.002-7.fc12.noarch requires /bin/sh bpg-courier-fonts-4.002-7.fc12.noarch requires /bin/sh On ppc64: bpg-courier-fonts-4.002-7.fc12.noarch requires /bin/sh bpg-courier-fonts-4.002-7.fc12.noarch requires /bin/sh On ppc: bpg-serif-modern-fonts-2.028-7.fc12.noarch requires /bin/sh bpg-serif-modern-fonts-2.028-7.fc12.noarch requires /bin/sh On ppc64: bpg-serif-modern-fonts-2.028-7.fc12.noarch requires /bin/sh bpg-serif-modern-fonts-2.028-7.fc12.noarch requires /bin/sh On ppc: bpg-sans-medium-fonts-1.005-7.fc12.noarch requires /bin/sh bpg-sans-medium-fonts-1.005-7.fc12.noarch requires /bin/sh On ppc64: bpg-sans-medium-fonts-1.005-7.fc12.noarch requires /bin/sh bpg-sans-medium-fonts-1.005-7.fc12.noarch requires /bin/sh On ppc: bpg-elite-fonts-3.000-7.fc12.noarch requires /bin/sh bpg-elite-fonts-3.000-7.fc12.noarch requires /bin/sh On ppc64: bpg-elite-fonts-3.000-7.fc12.noarch requires /bin/sh bpg-elite-fonts-3.000-7.fc12.noarch requires /bin/sh On ppc: bpg-chveulebrivi-fonts-3.002-7.fc12.noarch requires /bin/sh bpg-chveulebrivi-fonts-3.002-7.fc12.noarch requires /bin/sh On ppc64: bpg-chveulebrivi-fonts-3.002-7.fc12.noarch requires /bin/sh bpg-chveulebrivi-fonts-3.002-7.fc12.noarch requires /bin/sh On ppc: bpg-serif-fonts-1.005-7.fc12.noarch requires /bin/sh bpg-serif-fonts-1.005-7.fc12.noarch requires /bin/sh On ppc64: bpg-serif-fonts-1.005-7.fc12.noarch requires /bin/sh bpg-serif-fonts-1.005-7.fc12.noarch requires /bin/sh On ppc: bpg-sans-modern-fonts-2.025-7.fc12.noarch requires /bin/sh bpg-sans-modern-fonts-2.025-7.fc12.noarch requires /bin/sh On ppc64: bpg-sans-modern-fonts-2.025-7.fc12.noarch requires /bin/sh bpg-sans-modern-fonts-2.025-7.fc12.noarch requires /bin/sh On ppc: bpg-glaho-fonts-9.000-7.fc12.noarch requires /bin/sh bpg-glaho-fonts-9.000-7.fc12.noarch requires /bin/sh On ppc64: bpg-glaho-fonts-9.000-7.fc12.noarch requires /bin/sh bpg-glaho-fonts-9.000-7.fc12.noarch requires /bin/sh On ppc: bpg-courier-s-fonts-4.000-7.fc12.noarch requires /bin/sh bpg-courier-s-fonts-4.000-7.fc12.noarch requires /bin/sh On ppc64: bpg-courier-s-fonts-4.000-7.fc12.noarch requires /bin/sh bpg-courier-s-fonts-4.000-7.fc12.noarch requires /bin/sh On ppc: bpg-nino-medium-cond-fonts-4.005-7.fc12.noarch requires /bin/sh bpg-nino-medium-cond-fonts-4.005-7.fc12.noarch requires /bin/sh On ppc64: bpg-nino-medium-cond-fonts-4.005-7.fc12.noarch requires /bin/sh bpg-nino-medium-cond-fonts-4.005-7.fc12.noarch requires /bin/sh On ppc: bpg-ingiri-fonts-4.000-7.fc12.noarch requires /bin/sh bpg-ingiri-fonts-4.000-7.fc12.noarch requires /bin/sh On ppc64: bpg-ingiri-fonts-4.000-7.fc12.noarch requires /bin/sh bpg-ingiri-fonts-4.000-7.fc12.noarch requires /bin/sh On ppc: bpg-sans-fonts-1.005-7.fc12.noarch requires /bin/sh bpg-sans-fonts-1.005-7.fc12.noarch requires /bin/sh On ppc64: bpg-sans-fonts-1.005-7.fc12.noarch requires /bin/sh bpg-sans-fonts-1.005-7.fc12.noarch requires /bin/sh On ppc: bpg-excelsior-fonts-2.025-7.fc12.noarch requires /bin/sh bpg-excelsior-fonts-2.025-7.fc12.noarch requires /bin/sh On ppc64: bpg-excelsior-fonts-2.025-7.fc12.noarch requires /bin/sh bpg-excelsior-fonts-2.025-7.fc12.noarch requires /bin/sh On ppc: bpg-algeti-fonts-2.005-7.fc12.noarch requires /bin/sh bpg-algeti-fonts-2.005-7.fc12.noarch requires /bin/sh On ppc64: bpg-algeti-fonts-2.005-7.fc12.noarch requires /bin/sh bpg-algeti-fonts-2.005-7.fc12.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: lohit-kannada-fonts
lohit-kannada-fonts has broken dependencies in the development tree: On ppc: lohit-kannada-fonts-2.4.4-2.fc12.noarch requires /bin/sh lohit-kannada-fonts-2.4.4-2.fc12.noarch requires /bin/sh On ppc64: lohit-kannada-fonts-2.4.4-2.fc12.noarch requires /bin/sh lohit-kannada-fonts-2.4.4-2.fc12.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: sj-fonts
sj-fonts has broken dependencies in the development tree: On ppc: sj-delphine-fonts-2.0.2-5.fc12.noarch requires /bin/sh sj-delphine-fonts-2.0.2-5.fc12.noarch requires /bin/sh On ppc64: sj-delphine-fonts-2.0.2-5.fc12.noarch requires /bin/sh sj-delphine-fonts-2.0.2-5.fc12.noarch requires /bin/sh On ppc: sj-stevehand-fonts-2.0.2-5.fc12.noarch requires /bin/sh sj-stevehand-fonts-2.0.2-5.fc12.noarch requires /bin/sh On ppc64: sj-stevehand-fonts-2.0.2-5.fc12.noarch requires /bin/sh sj-stevehand-fonts-2.0.2-5.fc12.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: smc-fonts
smc-fonts has broken dependencies in the development tree: On ppc: smc-meera-fonts-04.2-2.fc13.noarch requires /bin/sh smc-meera-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc64: smc-meera-fonts-04.2-2.fc13.noarch requires /bin/sh smc-meera-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc: smc-suruma-fonts-04.2-2.fc13.noarch requires /bin/sh smc-suruma-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc64: smc-suruma-fonts-04.2-2.fc13.noarch requires /bin/sh smc-suruma-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc: smc-kalyani-fonts-04.2-2.fc13.noarch requires /bin/sh smc-kalyani-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc64: smc-kalyani-fonts-04.2-2.fc13.noarch requires /bin/sh smc-kalyani-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc: smc-anjalioldlipi-fonts-04.2-2.fc13.noarch requires /bin/sh smc-anjalioldlipi-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc64: smc-anjalioldlipi-fonts-04.2-2.fc13.noarch requires /bin/sh smc-anjalioldlipi-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc: smc-dyuthi-fonts-04.2-2.fc13.noarch requires /bin/sh smc-dyuthi-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc64: smc-dyuthi-fonts-04.2-2.fc13.noarch requires /bin/sh smc-dyuthi-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc: smc-raghumalayalam-fonts-04.2-2.fc13.noarch requires /bin/sh smc-raghumalayalam-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc64: smc-raghumalayalam-fonts-04.2-2.fc13.noarch requires /bin/sh smc-raghumalayalam-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc: smc-rachana-fonts-04.2-2.fc13.noarch requires /bin/sh smc-rachana-fonts-04.2-2.fc13.noarch requires /bin/sh On ppc64: smc-rachana-fonts-04.2-2.fc13.noarch requires /bin/sh smc-rachana-fonts-04.2-2.fc13.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: sazanami-fonts
sazanami-fonts has broken dependencies in the development tree: On ppc: sazanami-mincho-fonts-0.20040629-9.fc13.noarch requires /bin/sh sazanami-mincho-fonts-0.20040629-9.fc13.noarch requires /bin/sh On ppc64: sazanami-mincho-fonts-0.20040629-9.fc13.noarch requires /bin/sh sazanami-mincho-fonts-0.20040629-9.fc13.noarch requires /bin/sh On ppc: sazanami-gothic-fonts-0.20040629-9.fc13.noarch requires /bin/sh sazanami-gothic-fonts-0.20040629-9.fc13.noarch requires /bin/sh On ppc64: sazanami-gothic-fonts-0.20040629-9.fc13.noarch requires /bin/sh sazanami-gothic-fonts-0.20040629-9.fc13.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: lohit-bengali-fonts
lohit-bengali-fonts has broken dependencies in the development tree: On ppc: lohit-bengali-fonts-2.4.3-3.fc12.noarch requires /bin/sh lohit-bengali-fonts-2.4.3-3.fc12.noarch requires /bin/sh On ppc64: lohit-bengali-fonts-2.4.3-3.fc12.noarch requires /bin/sh lohit-bengali-fonts-2.4.3-3.fc12.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: lohit-maithili-fonts
lohit-maithili-fonts has broken dependencies in the development tree: On ppc: lohit-maithili-fonts-2.4.3-2.fc12.noarch requires /bin/sh lohit-maithili-fonts-2.4.3-2.fc12.noarch requires /bin/sh On ppc64: lohit-maithili-fonts-2.4.3-2.fc12.noarch requires /bin/sh lohit-maithili-fonts-2.4.3-2.fc12.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Broken dependencies: silkscreen-fonts
silkscreen-fonts has broken dependencies in the development tree: On ppc: silkscreen-expanded-fonts-1.0-4.fc12.noarch requires /bin/sh silkscreen-expanded-fonts-1.0-4.fc12.noarch requires /bin/sh On ppc64: silkscreen-expanded-fonts-1.0-4.fc12.noarch requires /bin/sh silkscreen-expanded-fonts-1.0-4.fc12.noarch requires /bin/sh On ppc: silkscreen-fonts-1.0-4.fc12.noarch requires /bin/sh silkscreen-fonts-1.0-4.fc12.noarch requires /bin/sh On ppc64: silkscreen-fonts-1.0-4.fc12.noarch requires /bin/sh silkscreen-fonts-1.0-4.fc12.noarch requires /bin/sh Please resolve this as soon as possible. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
