Re: olpc components in x86/x86_64 repo
On 10/06/2009 05:35 PM, Jon Ciesla wrote: > Additionally, having OLPC-specific RPMS in mainline Fedora helps with > the end goal that is , as I understand it, to have OLPC's OS be > essentially a Spin of stock Fedora. It also helps OLPC devs who don't > necessarily have XOs. IIRC, they already are shipping stock Fedora in their latest builds except for the kernel. They are also responsible for the largest amount of Fedora deployments in the world. So it is all mutually beneficial. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: olpc components in x86/x86_64 repo
On Wed, Oct 7, 2009 at 8:12 AM, Rahul Sundaram wrote: > On 10/06/2009 05:35 PM, Jon Ciesla wrote: > >> Additionally, having OLPC-specific RPMS in mainline Fedora helps with >> the end goal that is , as I understand it, to have OLPC's OS be >> essentially a Spin of stock Fedora. It also helps OLPC devs who don't >> necessarily have XOs. > > IIRC, they already are shipping stock Fedora in their latest builds > except for the kernel. They are also responsible for the largest amount > of Fedora deployments in the world. So it is all mutually beneficial. That is correct, we're all upstream now with no weird branches for core packages :-) Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: olpc components in x86/x86_64 repo
2009/10/7 Peter Robinson : > On Wed, Oct 7, 2009 at 8:12 AM, Rahul Sundaram > wrote: >> On 10/06/2009 05:35 PM, Jon Ciesla wrote: >> >>> Additionally, having OLPC-specific RPMS in mainline Fedora helps with >>> the end goal that is , as I understand it, to have OLPC's OS be >>> essentially a Spin of stock Fedora. It also helps OLPC devs who don't >>> necessarily have XOs. >> >> IIRC, they already are shipping stock Fedora in their latest builds >> except for the kernel. They are also responsible for the largest amount >> of Fedora deployments in the world. So it is all mutually beneficial. > > That is correct, we're all upstream now with no weird branches for > core packages :-) Thats great to hear and interesting information. In no way the question was meant as criticism. Basically i was just curious if the packages are hardware related to the olpc hw or generally useful. Thanks for your answer. Best wishes for the olpc/sugar developers. More knowledge and therefor power to the poor kids. kind regards, Rudolf Kastl > > Peter > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
On Tue, Oct 06, 2009 at 03:05:27PM -0800, Jeff Spaleta wrote: > On Tue, Oct 6, 2009 at 2:34 PM, Richard W.M. Jones wrote: > > which is that we should avoid making permanent optimizations, and > > instead try to do runtime tests wherever possible. This is because > > P2V, V2V and virtual machine migration makes it more likely that > > CPU features such as SSE* can change unexpectedly. > > This is going to be pretty important for scientific workloads where > atlas is going to be used. I've eavesdropped on several conversations > where people were talking about being able to run off-the-shelf > science code virtual appliance in order to reduce the environment > configuration workload for an individual researcher. Yup. The really fun starts when you do live migration. The processor literally changes underneath the running programs. If you thought you had SSE3 one minute, then the next you don't, or vice versa. No one has to my knowledge come up with a good way to deal with this. But it probably involves signalling the kernel and processes so that they can redo processor detection. You can see why that is not going to be pleasant. At the moment it's done by masking out processor flags or by limiting migrations to known good combinations of hardware. However that reduces the utility of the hardware and makes system administration more complex. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: preupgrade from f11 to rawhide broken? python traceback
On Thu, Oct 01, 2009 at 10:51:36PM +0300, Pasi Kärkkäinen wrote: > > >Traceback (most recent call last): > > > File "/usr/share/preupgrade/preupgrade-cli.py", line 305, in > > > pu.main(myrelease) > > > File "/usr/share/preupgrade/preupgrade-cli.py", line 270, in main > > > self.generate_repo(cachedir, comps) # TODO: callback? > > > File "/usr/lib/python2.6/site-packages/preupgrade/__init__.py", line 651, > > > in generate_repo > > > misc.generate_repodata(dir,comps,callback) > > > File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 131, in > > > generate_repodata > > > generate_repodata(dir, comps, callback) > > > File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 148, in > > > generate_repodata_f9 > > > mdgen.doRepoMetadata() > > > File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 829, > > > in doRepoMetadata > > > rp.getPrimary(complete_path, csum) > > > File "/usr/lib64/python2.6/site-packages/sqlitecachec.py", line 45, in > > > getPrimary > > > self.repoid)) > > >TypeError: Parsing primary.xml error: attributes construct error > > > > > > > > >Known problem? How to fix it? > > > > this is the second time I've seen this one - if you can find > > the primary.xml in /var/cache/yum/anaconda* directory, I'd appreciate > > seeing it. > > > > # ls /var/cache/yum > fedora preupgrade updates > > # cd /var/cache/yum > > # find -iname '*primary*' > ./updates/77201d8b7218d4edb8d0762c1aa1cbbe5975fdc571d0787f1920a0a204b1188d-primary.sqlite > ./preupgrade/f854960bfcacf06e2a8cb03cf3928a38c8e4e2fa860bed984a0edb89555600cf-primary.sqlite > ./preupgrade/.repodata/primary.xml.gz > ./preupgrade/.repodata/primary.xml.gz.sqlite > ./fedora/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite > > > I put it available online here: > http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz > > Firefox complains about it btw.. > > XML Parsing Error: not well-formed > Location: http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz > Line Number 42622, Column 68: >ver=""Saslauthd"/> > ---^ > Does this help? Did you have time to take a look at it? Other people seem to be having the same problem.. -- Pasi -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: preupgrade from f11 to rawhide broken? python traceback
On Wed, 7 Oct 2009, Pasi Kärkkäinen wrote: On Thu, Oct 01, 2009 at 10:51:36PM +0300, Pasi Kärkkäinen wrote: Traceback (most recent call last): File "/usr/share/preupgrade/preupgrade-cli.py", line 305, in pu.main(myrelease) File "/usr/share/preupgrade/preupgrade-cli.py", line 270, in main self.generate_repo(cachedir, comps) # TODO: callback? File "/usr/lib/python2.6/site-packages/preupgrade/__init__.py", line 651, in generate_repo misc.generate_repodata(dir,comps,callback) File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 131, in generate_repodata generate_repodata(dir, comps, callback) File "/usr/lib/python2.6/site-packages/preupgrade/misc.py", line 148, in generate_repodata_f9 mdgen.doRepoMetadata() File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 829, in doRepoMetadata rp.getPrimary(complete_path, csum) File "/usr/lib64/python2.6/site-packages/sqlitecachec.py", line 45, in getPrimary self.repoid)) TypeError: Parsing primary.xml error: attributes construct error Known problem? How to fix it? this is the second time I've seen this one - if you can find the primary.xml in /var/cache/yum/anaconda* directory, I'd appreciate seeing it. # ls /var/cache/yum fedora preupgrade updates # cd /var/cache/yum # find -iname '*primary*' ./updates/77201d8b7218d4edb8d0762c1aa1cbbe5975fdc571d0787f1920a0a204b1188d-primary.sqlite ./preupgrade/f854960bfcacf06e2a8cb03cf3928a38c8e4e2fa860bed984a0edb89555600cf-primary.sqlite ./preupgrade/.repodata/primary.xml.gz ./preupgrade/.repodata/primary.xml.gz.sqlite ./fedora/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite I put it available online here: http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz Firefox complains about it btw.. XML Parsing Error: not well-formed Location: http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz Line Number 42622, Column 68: ---^ Does this help? Did you have time to take a look at it? Other people seem to be having the same problem.. update to yum from f11-updates (3.2.24) and the problem goes away. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: didn't see "md5 mismatch" error on today's Rawhide noarch packages
Rahul Sundaram wrote: > XZ upstream was informed of this problem and we have now inherited the > fix. > > --- > > Wed Oct 07 2009 Jindrich Novy > 4.999.9-0.1.20091007.beta > - update to 4.999.9beta > - sync with upstream to generate the same archives on machines with > different > endianess > --- That fix is not tagged into the release yet. The noarch packages which didn't generate the error just happened to be built on x86 (~50% probability). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: olpc components in x86/x86_64 repo
Rudolf Kastl wrote: 2009/10/7 Peter Robinson : On Wed, Oct 7, 2009 at 8:12 AM, Rahul Sundaram wrote: On 10/06/2009 05:35 PM, Jon Ciesla wrote: Additionally, having OLPC-specific RPMS in mainline Fedora helps with the end goal that is , as I understand it, to have OLPC's OS be essentially a Spin of stock Fedora. It also helps OLPC devs who don't necessarily have XOs. IIRC, they already are shipping stock Fedora in their latest builds except for the kernel. They are also responsible for the largest amount of Fedora deployments in the world. So it is all mutually beneficial. That is correct, we're all upstream now with no weird branches for core packages :-) Thats great to hear and interesting information. In no way the question was meant as criticism. Basically i was just curious if the packages are hardware related to the olpc hw or generally useful. Thanks for your answer. Best wishes for the olpc/sugar developers. More knowledge and therefor power to the poor kids. My thanks to all concerned. kind regards, Rudolf Kastl Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On 10/04/2009 04:05 PM, John Reiser wrote: The title says it all. How about that? We really need it for old intel h/w such as an i855 for example. Enumerate the reasons, please. Which _specific_ bugs or features have been improved elsewhere but not in F11? Why are they important to you and others? The graphics system in F11 is horribly broken for 3D, at least on Intel 845, ATI 200 and ATI 300 chipsets. Certainly the Blender program will not run on any of my computers (5 different graphics hardware versions). I have been using drm/mesa/xf86-video-ati code from GIT to get around this, but now the XServer is out of date so it has got difficult. A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the new 1.7 XServer and 7.6 mesa would be very useful. I understand that changing the Graphics system could break many users systems, so maybe a build of all the necessary packages could be put into the testing repository or perhaps a special graphics-testing repository could be added. This would help get the graphics issues fixed prior to F12's release ... It would be good to have a Linux system that could actually to 3D with the major applications by the end of 2009 ! Cheers Terry -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091007 changes
Compose started at Wed Oct 7 06:15:12 UTC 2009
Broken deps for ppc64
--
python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot
New package fped
A footprint editor used by openmoko developers
New package geda-gaf
Design Automation toolkit for electronic design
New package oflb-smonohand-fonts
A handwritten monospace font
New package windowlab
Small and Simple Amiga-like Window Manager
Updated Packages:
PackageKit-0.5.3-1.fc12
---
* Mon Oct 05 2009 Richard Hughes - 0.5.3-1
- Update to 0.5.3.
- Fix double free in pk-gstreamer-install which causes a crash. Fixes #526600
- Exit pk-command-not-found with 127 when we have not run a program. Fixes
#527044
- Fix crash in notification daemon under some conditions due to non-resident
GTK module.
- Don't explicitly download the file lists when using pk-command-not-found
* Tue Sep 29 2009 Richard Hughes - 0.5.3-0.2.20090928git
- Do not build smart support on RHEL.
* Mon Sep 28 2009 Richard Hughes - 0.5.3-0.1.20090928git
- Update to a newer git snapshot from the 0.5.x series.
- Fixes command-not-found functionality
- Lots of updated translations
- Lots of updates and bugfixes to the experimental glib2 library
R-nws-2.0.0.3-1.fc12
* Mon Oct 05 2009 Tom "spot" Callaway - 2.0.0.3-1
- update to 2.0.0.3
Terminal-0.4.2-1.fc12
-
* Tue Oct 06 2009 Christoph Wickert - 0.4.2-1
- Update to 0.4.2
- Update icon cache scriptlets
asymptote-1.88-1.fc12
-
* Mon Oct 05 2009 Tom "spot" Callaway - 1.88-1
- update to 1.88
control-center-2.28.0-15.fc12
-
* Tue Oct 06 2009 Matthias Clasen 2.28.0-15
- Fix a crash in the about-me capplet (#525590)
crypto-utils-2.4.1-24
-
* Sun Oct 04 2009 Elio Maldonado - 2.4.1-24
- Retagging for a Fedora-12 build (#526720)
* Thu Oct 01 2009 Elio Maldonado - 2.4.1-23
- Fix genkey to produce CSRs, certs, and key in ascii PEM format (#526720)
digikam-1.0.0-0.7.beta5.fc12
* Tue Oct 06 2009 Rex Dieter - 1.0.0-0.7.beta5
- digikam-1.0.0-beta5
- tweak marble deps (again)
dracut-002-12.git8f397a9b.fc12
--
* Tue Oct 06 2009 Harald Hoyer 002-12
- add missing loginit helper
- corrected dracut manpage
gdm-2.28.0-6.fc12
-
* Mon Oct 05 2009 Matthias Clasen - 1:2.28.4-6
- Fix the autostart file for at-spi-registryd
* Thu Oct 01 2009 Matthias Clasen - 1:2.28.4-5
- Handle keyboard layout variants
gnome-utils-2.28.0-2.fc12
-
* Mon Oct 05 2009 Matthias Clasen - 1:2.28.0-2
- Move the usermode dep to the gnome-system-log package (#527295)
gtk2-2.18.2-1.fc12
--
* Mon Oct 05 2009 Matthias Clasen - 2.18.2-1
- Update to 2.18.2
hyphen-kn-0.20090924-1.fc12
---
* Thu Sep 24 2009 Parag - 0.20090924-1
- update to 20090924
hyphen-pa-0.20090924-1.fc12
---
* Thu Sep 24 2009 Parag - 0.20090924-1
- update to 20090924
libbonobo-2.24.2-2.fc12
---
* Tue Oct 06 2009 Matthias Clasen - 2.24.2-2
- Fix a use-after-free in the mime code
libburn-0.7.0-1.fc12
* Wed Sep 30 2009 Denis Leroy - 0.7.0-1
- Update to upstream 0.7.0
- Fixed binary installation
- Removed rpath
libvirt-0.7.1-10.fc12
-
* Tue Oct 06 2009 Mark McLoughlin - 0.7.1-9
- Change logrotate config to weekly (#526769)
* Tue Oct 06 2009 Mark McLoughlin - 0.7.1-10
- Create /var/log/libvirt/{lxc,uml} dirs for logrotate
- Make libvirt-python dependon on libvirt-client
- Sync misc minor changes from upstream spec
ltsp-5.1.91-1.fc12
--
* Tue Oct 06 2009 Warren Togami - 5.1.91-1
- 5.1.91 fixes install of chroots
nss-3.12.4-14.fc12
--
* Tue Oct 06 2009 Elio Maldonado - 3.12.4-14
- Fix bug where user was prompted for a password when listing keys on an empty
system database (#527048)
- Fix setup-nsssysinit to handle more general flags formats (#527051)
nwsclient-1.6.4-1.fc12
--
* Mon Oct 05 2009 Tom "spot" Callaway - 1.6.4-1
- update to 1.6.4
nwsserver-2.0.0-1.fc12
--
* Mon Oct 05 2009 Tom "spot" Callaway 2.0.0-1
- update to 2.0.0
plymouth-0.8.0-0.2009.29.09.3.fc12
--
* Mon Oct 05 2009 Ray Strode 0.8.0-0.2009.29.09.2
- Fix --show-splash after --hide-splash (bug 527299)
* Mon Oct 05 2009 Ray Strode 0.8.0-0.2009.29.09.3
- Fix crasher in text plugin after password prompt (bug 526652)
- Actually apply the patch mentioned in 2009.29.09.2
qemu-0.11.0-4.fc12
--
* Mon Oct 05 2009 Mark McLoughlin - 2:0.11.0-4
- Use rtl8029 PXE rom for ne2k_pci, not ne (#526777)
- Also, replace the gpxe-roms-qemu pkg requires with file-based requires
readahead-1.5.3-1.fc12
--
* Tue Oct 06 2009 Harald
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Wed, Oct 07, 2009 at 15:15:06 +0100, Terry Barnaby wrote: > The graphics system in F11 is horribly broken for 3D, at least on Intel 845, > ATI 200 and ATI 300 chipsets. Certainly the Blender program will not run > on any of my computers (5 different graphics hardware versions). 3d seems to be working better on ATI r530 very recently. (I was finally able to get glest to run.) I am upgrading my last F11 machine now to try to get working 3d on my ATI rv280 even though it will mean a hassle to try to get dahdi-linux working. The yum update just started, so I might not have the answer to whether or not 3d is working on that card until tomorrow, but I'll followup when it is done to indicate whether or not it worked. I'd really like to be able to test glest without needing a proprietary driver. (I have some other scrounged machines that have nvidia cards, but am using them for rawhide testing (including nouveau) and don't want to mess them up by installing the nvidia drivers. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Wed, Oct 07, 2009 at 03:15:06PM +0100, Terry Barnaby wrote: > A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the > new 1.7 XServer and 7.6 mesa would be very useful. No, not really. > I understand that changing the Graphics system could break many > users systems, so maybe a build of all the necessary packages could be put > into the testing repository or perhaps a special graphics-testing repository > could be added. This would help get the graphics issues fixed prior to > F12's release ... Actually, installing rawhide or the F-12 Beta (or using a livecd) would help get the graphics issues fixed prior to F-12 release. That is going to help much more than wasting the developer's time trying to backport everything to F-11, pushing it to updates-testing, and dealing with all the fallout. > It would be good to have a Linux system that could actually to 3D with the > major applications by the end of 2009 ! Fortunately, F-12 is scheduled for release by then! josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
Richard W.M. Jones (rjo...@redhat.com) said: > > This is going to be pretty important for scientific workloads where > > atlas is going to be used. I've eavesdropped on several conversations > > where people were talking about being able to run off-the-shelf > > science code virtual appliance in order to reduce the environment > > configuration workload for an individual researcher. > > Yup. The really fun starts when you do live migration. The processor > literally changes underneath the running programs. If you thought you > had SSE3 one minute, then the next you don't, or vice versa. > > No one has to my knowledge come up with a good way to deal with this. > But it probably involves signalling the kernel and processes so that > they can redo processor detection. You can see why that is not going > to be pleasant. Surely the way to do this is to know what your workload is doing, and not do live migration to random hardware? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Distro Summit 2010: call for papers extended until 18 Oct 2009
Forwarding this to the list for Martin, who isn't subscribed. Please reply to him, not me with any comments. kevin From: martin f krafft To: fedora-devel-list@redhat.com Subject: Distro Summit 2010: call for papers extended until 18 Oct 2009 Date: Wed, 07 Oct 2009 12:05:05 +0200 Reply-To: c...@distrosummit.org Please redistribute this call for papers. The deadline has been extended to 18 Oct 2009. === CALL FOR PAPERS === Distro Summit 2010 is a one-day technical conference with a strong focus on collaboration between Free Software distributions hosted at the linux.conf.au 2010. We are looking for proposals from any Free Software distribution, from the typical full distributions (both linux and non-linux) to the niche market derivatives. In spite of the strong focus on collaboration between Free Software distributions, topics may include packaging, maintenance, relationship with upstream developers, release management and QA. For more informtion, please visit: http://distrosummit.org. Important dates === * Call for papers ends: Wednesday 18 October 2009 * Announcing the schedule: Friday 2 October 2009 * Conference begins: Monday 18 January 2010 Presentation types == We will accept proposals for: * 25 minute standard-length presentations; * 50 minute long presentations. Session lengths include time for audience questions. We intend for standard-length presentation to make up the vast majority of our presentations. If you plan on submitting a proposal for a long presentation, a willingness to present a standard-length presentation will impact positively on your proposal. Submit a proposal = To submit your proposal, we'll need the following information: * Your name, contact details and a short biography; * Your proposal title; * Intended audience; * An abstract; * Presentation outline; * Presentation type (standard-length or long). To submit a proposal, or get more information, please write to c...@distrosummit.org. Unfortunately, we cannot offer sponsorship for speakers. About the Distro Summit === The Distro Summit 2010 is a one-day developer conference with a strong focus on collaboration between free software distributions hosted at the linux.conf.au 2010 (http://www.lca2010.org.nz). In addition to a schedule of technical, social and policy talks, the Distro Summit provides an opportunity for developers, contributors and other interested people to meet in person and work together more closely. Previous similar events have featured speakers from around the world. They have also been extremely beneficial for developing key free software software components and for improving collaboration and sharing between the different distributions. Target Audience === The Distro Summit is (mainly) a technical event, but this does not mean that the only target audience are developers and maintainers of free software distributions: the event will feature talks that range from the development to real-world use cases, going through marketing and the social aspects of the maintenance of free software distributions. -- Martin Krafft on the behalf of the Distro Summit organizers signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
On Wed, Oct 07, 2009 at 11:29:11AM -0400, Bill Nottingham wrote: > Richard W.M. Jones (rjo...@redhat.com) said: > > Yup. The really fun starts when you do live migration. The processor > > literally changes underneath the running programs. If you thought you > > had SSE3 one minute, then the next you don't, or vice versa. > > > > No one has to my knowledge come up with a good way to deal with this. > > But it probably involves signalling the kernel and processes so that > > they can redo processor detection. You can see why that is not going > > to be pleasant. > > Surely the way to do this is to know what your workload is doing, > and not do live migration to random hardware? But we're talking -- in this very thread -- about the case where core programs are starting to use SIMD instructions. This is only going to get more common because the only way to use a large proportion of the compute power of modern processors is to use these instructions. And in any case, the kernel is using them for checksumming and so on, even if you can be absolutely sure your workload isn't. As I said in my earier reply: > > However that reduces the utility of the hardware and makes system > > administration more complex. OR we can use all the power of modern hardware and make system administration easier. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
On Wed, Oct 7, 2009 at 7:29 AM, Bill Nottingham wrote: > Surely the way to do this is to know what your workload is doing, > and not do live migration to random hardware? I think random hardware is going to be exactly what you will see a lot of scientific research appliances being thrown at. There are groups interested in offering off the shelf appliances for some complex computational codes meant to be run on private/academic/national lab infrastructure to make it easier for scientific users to run the codes correctly. It's pretty pedantic stuff, and you can really screw up the build configuration when you are trying to build your own instances (DYI kernel compiles can be refreshingly less complicated sometimes) Live migrating appliances across those boundaries will undoubtedly be desired. National Lab run "clouds" are going to be well defined hardware targets but academic clouds are going to be all over the place. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
On Wed, Oct 07, 2009 at 11:29:11AM -0400, Bill Nottingham wrote: > Richard W.M. Jones (rjo...@redhat.com) said: > > > This is going to be pretty important for scientific workloads where > > > atlas is going to be used. I've eavesdropped on several conversations > > > where people were talking about being able to run off-the-shelf > > > science code virtual appliance in order to reduce the environment > > > configuration workload for an individual researcher. > > > > Yup. The really fun starts when you do live migration. The processor > > literally changes underneath the running programs. If you thought you > > had SSE3 one minute, then the next you don't, or vice versa. > > > > No one has to my knowledge come up with a good way to deal with this. > > But it probably involves signalling the kernel and processes so that > > they can redo processor detection. You can see why that is not going > > to be pleasant. > > Surely the way to do this is to know what your workload is doing, > and not do live migration to random hardware? Or just apply a CPUID mask to the guest, so it sees a constant set of features no matter where its migrated to. This is what Xen, VMWare, QEMU/KVM all do for this problem. Trying to make the guest re-detect, while nice in theory, is just not something people are going to bother doing - witness the death of pure paravirt, since fullyvirt is 'good enough' for most people - the same is true of CPUID masking to make hardware appear homogeneous Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
Hi. On Wed, 7 Oct 2009 11:29:11 -0400, Bill Nottingham wrote > Surely the way to do this is to know what your workload is doing, > and not do live migration to random hardware? Redetection of CPU features in a live system is complete madness. The virt-infrastructure has to make sure that the system migrated to has a superset of features of the machine migrated from. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
On Wed, Oct 7, 2009 at 4:29 PM, Bill Nottingham wrote: > Richard W.M. Jones (rjo...@redhat.com) said: >> > This is going to be pretty important for scientific workloads where >> > atlas is going to be used. I've eavesdropped on several conversations >> > where people were talking about being able to run off-the-shelf >> > science code virtual appliance in order to reduce the environment >> > configuration workload for an individual researcher. >> >> Yup. The really fun starts when you do live migration. The processor >> literally changes underneath the running programs. If you thought you >> had SSE3 one minute, then the next you don't, or vice versa. >> >> No one has to my knowledge come up with a good way to deal with this. >> But it probably involves signalling the kernel and processes so that >> they can redo processor detection. You can see why that is not going >> to be pleasant. > > Surely the way to do this is to know what your workload is doing, > and not do live migration to random hardware? In fact the proper way to do this it to have the same hardware in the group of servers that VMs might be live migrated between so that its not an issue. Then the only time this would then come into play is when you are upgrading the group/cluster of machines to newer hardware and that shouldn't be an issue as the newer hardware should have more features in the CPU and not less. This is the way we do it in the Enterprise hosting company that I work for which has a VM environment over around 250 hosts runninng around 2500 VMs. We have a few disparate clusters with different devices using different HW but in that case we use the CPU masking features of the main proprietary product that is in use in that particular case. Cheers, Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Retiring ksensors, possibly id3lib as well?
Greetings all... I believe the time has come to retire ksensors. The last update/release was 18/08/2004, and it appears upstream has been defunct since at least that time. Unless there are objections voiced and/or a maintainer steps forward before Oct 9 (Friday), I will go ahead and retire this package. id3lib also needs to be looked at, as it's upstream has been defunct since March 2 2003. This one might hurt more than ksensors will, since several programs depend on id3lib. This is a list of the programs that require id3lib: audio-convert-mod easytag tagtool id3lib-devel id3v2 gmediaserver liblicense-modules kid3 grip The list is alot shorter than I thought it would be, but it's still enough to cause problems. Is there anyone willing to take up upstream development of id3lib? Is there a possible (more active) replacement for id3lib? Is there a valid reason for continuing to carry such a defunct package in Fedora? I'm more than happy to continue maintaining id3lib if there is a valid reason to do so, but my reasons are more sentimental than valid logical reasoning. So I turn to you to answer that question: Is there valid, logical, reasoning to continue to support such old code? Lyos Gemini Norezel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
On Wed, Oct 07, 2009 at 06:40:38PM +0200, Ralf Ertzinger wrote: > Hi. > > On Wed, 7 Oct 2009 11:29:11 -0400, Bill Nottingham wrote > > > Surely the way to do this is to know what your workload is doing, > > and not do live migration to random hardware? > > Redetection of CPU features in a live system is complete madness. > The virt-infrastructure has to make sure that the system migrated to > has a superset of features of the machine migrated from. Difficult, surely. Madness, possibly. I really meant from this thread that these are a list of things that Linux distros should keep in mind. If it's possible to build distro packages so that detection happens at boot time, instead of installing hardware-specific packages, then please try to use the boot-time method. If it's possible to detect hardware availability when a program starts up, rather than hard-coding it into the binary, please use that method. If it's possible to write programs and shared library loaders so that redetection can be performed mid-execution, then prefer that method over one which only detects hardware when the program starts up. http://rwmj.wordpress.com/2009/10/06/what-things-make-p2vv2v-conversion-hard/ Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crypto consolidation status?
On 09/28/2009 10:27 PM, Ken Dreyer wrote: > On Mon, Sep 28, 2009 at 4:12 PM, Robert Relyea wrote: > >> Currently there are also a half dozen features in mod_nss that aren't in >> mod_ssl. SNI is definately something that would be welcomed in NSS, and >> would probably be implemented by the NSS team itself if it's not >> contributed first;), particularly if it got added to the list of >> impediments. >> > How does one add to this impediments list? I wasn't sure from the wiki page. > Basically it's bug tracking. Which bugs get pushed depends on how many packages are affected and the 'importance' of the package (and the missing feature). bob > It is not just the scorecard that's unclear - it was also confusing to > see Apache marked as "Done (mod_nss ) ".[1] If that's true, what do > all of these open httpd/apr bugs ([2],[3],[4],[5]) mean? No, it means the mod_nss has been ported. These fixes are relatively high on the list, but not yet at the top. bob > On a related > note, Joe didn't seem too enthusiastic about PHP, either [6]. > > - Ken > > [1] https://fedoraproject.org/wiki/FedoraCryptoConsolidation > [2] https://bugzilla.redhat.com/show_bug.cgi?id=347181 > [3] https://bugzilla.redhat.com/show_bug.cgi?id=347601 > [4] https://bugzilla.redhat.com/show_bug.cgi?id=346541 > [5] https://bugzilla.redhat.com/show_bug.cgi?id=346551 > [6] https://bugzilla.redhat.com/show_bug.cgi?id=347911 > > smime.p7s Description: S/MIME Cryptographic Signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
Hi. On Wed, 7 Oct 2009 19:10:28 +0100, Richard W.M. Jones wrote > If it's possible to write programs and shared library loaders so that > redetection can be performed mid-execution, then prefer that method > over one which only detects hardware when the program starts up. I have no qualms whatsoever with hardware changing between boots. Network cards, hard disks, CPU features, you name it. But having CPU features change from one instruction to the other (which the above would suggest, correct me if I'm wrong)... how do you suggest this would work? Testing for the feature before using it (every time? That should nullify any speedup gained by using the features in the first place) does not work, because the machine may move between the test and the instruction (maybe there's a way around this). Catching SIGILL? What about the data that was in the registers that are suddenly no longer there? And it's not only userspace, the kernel can use SSE, too (at least it did, once, for RAID checksumming at least). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Wed, 2009-10-07 at 10:44 -0400, Josh Boyer wrote: > On Wed, Oct 07, 2009 at 03:15:06PM +0100, Terry Barnaby wrote: > > A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the > > new 1.7 XServer and 7.6 mesa would be very useful. > > No, not really. > > > I understand that changing the Graphics system could break many > > users systems, so maybe a build of all the necessary packages could be put > > into the testing repository or perhaps a special graphics-testing repository > > could be added. This would help get the graphics issues fixed prior to > > F12's release ... > > Actually, installing rawhide or the F-12 Beta (or using a livecd) would help > get the graphics issues fixed prior to F-12 release. That is going to help > much more than wasting the developer's time trying to backport everything to > F-11, pushing it to updates-testing, and dealing with all the fallout. In fact, the major reason for not backporting the intel driver to F11 is that it requires a bunch of kernel changes that no one really has time for. Among other things, 830 through 865 require GEM in the intel 2.9, which we have disabled for the F11 kernel for those chips because (as shipped) it's utterly broken. - ajax signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
On Wed, Oct 07, 2009 at 08:19:07PM +0200, Ralf Ertzinger wrote: > Hi. > > On Wed, 7 Oct 2009 19:10:28 +0100, Richard W.M. Jones wrote > > > If it's possible to write programs and shared library loaders so that > > redetection can be performed mid-execution, then prefer that method > > over one which only detects hardware when the program starts up. > > I have no qualms whatsoever with hardware changing between boots. > Network cards, hard disks, CPU features, you name it. But having > CPU features change from one instruction to the other (which the > above would suggest, correct me if I'm wrong)... how do you suggest > this would work? Testing for the feature before using it (every time? > That should nullify any speedup gained by using the features in > the first place) does not work, because the machine may move between > the test and the instruction (maybe there's a way around this). I didn't say I had a way to do it, but in my earlier post I said perhaps one could send a special migration signal to the process. I've honestly no idea if that would work. https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00305.html No one has to my knowledge come up with a good way to deal with this. But it probably involves signalling the kernel and processes so that they can redo processor detection. You can see why that is not going to be pleasant. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: > Is there valid, logical, reasoning to continue to support such old code? Are there any bugs that are so severe that we can't continue using the software? If not: Why throw out working software just because it's old? Björn Persson 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: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: ... id3lib also needs to be looked at, as it's upstream has been defunct since March 2 2003. This one might hurt more than ksensors will, since several programs depend on id3lib. This is a list of the programs that require id3lib: audio-convert-mod easytag tagtool id3lib-devel id3v2 gmediaserver liblicense-modules kid3 grip The list is alot shorter than I thought it would be, but it's still enough to cause problems. Is there anyone willing to take up upstream development of id3lib? Is there a possible (more active) replacement for id3lib? Is there a valid reason for continuing to carry such a defunct package in Fedora? s/defunct/old/ - and yes there is a valid reason - 8 or so at least, see your list of packages above ;) I'm more than happy to continue maintaining id3lib if there is a valid reason to do so, but my reasons are more sentimental than valid logical reasoning. So I turn to you to answer that question: Is there valid, logical, reasoning to continue to support such old code? Yes, because other useful packages depend on it IMHO. I'll take it if you don't want to keep it, I think that library needs to live on in Fedora. -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
Peter Robinson wrote: > In fact the proper way to do this it to have the same hardware in the > group of servers that VMs might be live migrated between so that its > not an issue. Then the only time this would then come into play is > when you are upgrading the group/cluster of machines to newer hardware > and that shouldn't be an issue as the newer hardware should have more > features in the CPU and not less. Unless you upgrade from old PowerPC Macs to new Intel Macs. :-) Björn Persson 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: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: > I believe the time has come to retire ksensors. ksensors never sensed anything it is an old kde3 program that has been superseded by a nice kde4 system monitor plasmoid keeping kde3 programs that aren't absolutely essential, for which a kde4 program already exists, is very confusing and causes for things not to work -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Interesting post on future RPM changes
Hope I'm not pre-empting Seth or anyone here, but I thought it worth pointing out a very interesting blog post on planned future changes to RPM: http://stick.gk2.sk/blog/2009/10/rpm-summit-at-the-opensuse-conference-2009/ it lists several changes that were agreed in principle at a conference between several Novell and Red Hat people. There's some stuff in there which looks like it will likely lead to changes in Fedora packaging policies once it's implemented, so if you want to get ahead of the future it's a useful read =) -- 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: Interesting post on future RPM changes
On Wed, 7 Oct 2009, Adam Williamson wrote: Hope I'm not pre-empting Seth or anyone here, but I thought it worth pointing out a very interesting blog post on planned future changes to RPM: http://stick.gk2.sk/blog/2009/10/rpm-summit-at-the-opensuse-conference-2009/ it lists several changes that were agreed in principle at a conference between several Novell and Red Hat people. There's some stuff in there which looks like it will likely lead to changes in Fedora packaging policies once it's implemented, so if you want to get ahead of the future it's a useful read =) Pre-empting me for what? Nothing there is implemented as yet and I suspect it is not going to be implemented tomorrow. When it is likely to land in rpm it'll come up. Until then it's just potential. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interesting post on future RPM changes
On Wed, 2009-10-07 at 15:40 -0400, Seth Vidal wrote: > > On Wed, 7 Oct 2009, Adam Williamson wrote: > > > Hope I'm not pre-empting Seth or anyone here, but I thought it worth > > pointing out a very interesting blog post on planned future changes to > > RPM: > > > > http://stick.gk2.sk/blog/2009/10/rpm-summit-at-the-opensuse-conference-2009/ > > > > it lists several changes that were agreed in principle at a conference > > between several Novell and Red Hat people. There's some stuff in there > > which looks like it will likely lead to changes in Fedora packaging > > policies once it's implemented, so if you want to get ahead of the > > future it's a useful read =) > > Pre-empting me for what? Nothing there is implemented as yet and I suspect > it is not going to be implemented tomorrow. Pre-empting you talking about it is all I meant. > When it is likely to land in rpm it'll come up. Until then it's just > potential. Understood - as I said I just found it interesting from a 'what's (possibly) coming down the pipe in future' perspective, that's all. -- 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: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 03:19 PM, Björn Persson wrote: Lyos Gemini Norezel wrote: Is there valid, logical, reasoning to continue to support such old code? Are there any bugs that are so severe that we can't continue using the software? No, actually. Surprisingly enough... there are no current bugs open against id3lib. If not: Why throw out working software just because it's old? Don't security risks grow exponentially as software 'bit rots'? Björn Persson Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 03:25 PM, Eric Sandeen wrote: Lyos Gemini Norezel wrote: ... id3lib also needs to be looked at, as it's upstream has been defunct since March 2 2003. This one might hurt more than ksensors will, since several programs depend on id3lib. This is a list of the programs that require id3lib: audio-convert-mod easytag tagtool id3lib-devel id3v2 gmediaserver liblicense-modules kid3 grip The list is alot shorter than I thought it would be, but it's still enough to cause problems. Is there anyone willing to take up upstream development of id3lib? Is there a possible (more active) replacement for id3lib? Is there a valid reason for continuing to carry such a defunct package in Fedora? s/defunct/old/ - and yes there is a valid reason - 8 or so at least, see your list of packages above ;) Heh... sure, but surely such software could be made to work with a piece of code that's more recent than id3lib? I'm more than happy to continue maintaining id3lib if there is a valid reason to do so, but my reasons are more sentimental than valid logical reasoning. So I turn to you to answer that question: Is there valid, logical, reasoning to continue to support such old code? Yes, because other useful packages depend on it IMHO. I'll take it if you don't want to keep it, I think that library needs to live on in Fedora. I'm happy to maintain it... though I could definitely use a coder as a co-maintainer, or, really, anyone who wishes to help. The problem I have with continuing such code, is both the lack of an upstream... and the potential for security risks as this piece of code is left to rot. I have neither the skills, nor the time to take over upstream, and software cannot last/stay compatible forever. -Eric Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On Wednesday 07 October 2009 12:55:10 pm Lyos Gemini Norezel wrote: > On 10/07/2009 03:19 PM, Björn Persson wrote: > > Lyos Gemini Norezel wrote: > >> Is there valid, logical, reasoning to continue to support such old code? > > > > Are there any bugs that are so severe that we can't continue using the > > software? > > No, actually. > > Surprisingly enough... there are no current bugs open against id3lib. > > > If not: Why throw out working software just because it's old? > > Don't security risks grow exponentially as software 'bit rots'? Is it possible that id3lib is 'complete'? The id3 format isn't extremely complicated, it may just be a completely finished library. (Keep in mind, though, that I'm not familiar with the code.) As far as being a security risk... it's not a network daemon, and there's no reason it should have suid root or anything like that. I imagine the worst you could do is throw a malformed media file at it. Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 03:37 PM, Petrus de Calguarium wrote: Lyos Gemini Norezel wrote: I believe the time has come to retire ksensors. ksensors never sensed anything it is an old kde3 program that has been superseded by a nice kde4 system monitor plasmoid keeping kde3 programs that aren't absolutely essential, for which a kde4 program already exists, is very confusing and causes for things not to work LOL... I find it to still be fully functional on the rare occasions I actually fire it up . Of course... I actually use gnome ;-) . At any rate, since it has been 'superseded', as you say, I'm going to guess there's not going to be any objection to retiring ksensors. Never-the-less, I will wait until Friday, like I said, to actually retire it. Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 04:04 PM, Conrad Meyer wrote: Is it possible that id3lib is 'complete'? The id3 format isn't extremely complicated, it may just be a completely finished library. (Keep in mind, though, that I'm not familiar with the code.) I suppose it's possible, but even 'finished' software should have bug fixes and compatibility updates. As far as being a security risk... it's not a network daemon, and there's no reason it should have suid root or anything like that. I imagine the worst you could do is throw a malformed media file at it. LOL... makes sense. Regards, Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: On 10/07/2009 03:25 PM, Eric Sandeen wrote: Lyos Gemini Norezel wrote: ... Is there a valid reason for continuing to carry such a defunct package in Fedora? s/defunct/old/ - and yes there is a valid reason - 8 or so at least, see your list of packages above ;) Heh... sure, but surely such software could be made to work with a piece of code that's more recent than id3lib? Is there a more recent id3 library? I dunno. If there is, and all the packages you mentioned can find/use it, then sure I'm more than happy to continue maintaining id3lib if there is a valid reason to do so, but my reasons are more sentimental than valid logical reasoning. So I turn to you to answer that question: Is there valid, logical, reasoning to continue to support such old code? Yes, because other useful packages depend on it IMHO. I'll take it if you don't want to keep it, I think that library needs to live on in Fedora. I'm happy to maintain it... though I could definitely use a coder as a co-maintainer, or, really, anyone who wishes to help. The problem I have with continuing such code, is both the lack of an upstream... and the potential for security risks as this piece of code is left to rot. I have neither the skills, nor the time to take over upstream, and software cannot last/stay compatible forever. I'd say that if/when problems crop up you could revisit it. Maybe the reason it's been idle for so long is that it's simple/done/perfect and could just stay that way. :) If you have any need for a comaintainer I'd be glad to though in any case. -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On Wed, 2009-10-07 at 16:29 -0400, Lyos Gemini Norezel wrote: > On 10/07/2009 04:04 PM, Conrad Meyer wrote: > > Is it possible that id3lib is 'complete'? The id3 format isn't extremely > > complicated, it may just be a completely finished library. (Keep in mind, > > though, that I'm not familiar with the code.) > > > > I suppose it's possible, but even 'finished' software should have bug fixes > and compatibility updates. Compatibility with what? As noted, the IDv3 format hasn't changed. There are some open bugs, though: http://sourceforge.net/tracker/?limit=10&func=&group_id=979&atid=100979&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter so it seems it's not quite complete. taglib is probably the best actively-developed modern alternative. -- 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: Retiring ksensors, possibly id3lib as well?
On Wed, 2009-10-07 at 13:40 -0700, Adam Williamson wrote: > There are some open bugs, though: > > http://sourceforge.net/tracker/?limit=10&func=&group_id=979&atid=100979&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter > > so it seems it's not quite complete. > > taglib is probably the best actively-developed modern alternative. There's also an Ubuntu bug report indicating the use of id3lib causes some problems: https://bugs.launchpad.net/ubuntu/+source/tagtool/+bug/180110 That bug report also points out that id3lib is optional for easytag. -- 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: Retiring ksensors, possibly id3lib as well?
On Wednesday 07 October 2009, Adam Williamson wrote: > taglib is probably the best actively-developed modern alternative. I might not apply to all cases - kid3 for example uses both. Based on a brief look in the code and http://kid3.sourceforge.net/kid3_en.html#settings-menu, id3lib is used for ID3 2.3.0 tags and taglib for 2.4.0 ones, e.g. when converting from 2.4.0 to 2.3.0. I don't know why though, I'm not sufficiently familiar with either. Nor am I sure why one would convert from 2.4.0 to 2.3.0, maybe for compatibility reasons with $something. And yes, this is quite a corner case. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: > Don't security risks grow exponentially as software 'bit rots'? If someone finds and publishes a security hole, and no one tries to fix it, then the risk increases dramatically. If no holes are published and the software doesn't change, then I'd say the risk is fairly constant. There is always the possibility that some bad guy finds a hole that the good guys haven't found and fixed yet. The bad guy can then use the hole in a few directed attacks against selected targets. (In the case of id3lib he could for example send a malformed MP3 file to the victim by email.) In that case you're at risk only if you are the bad guy's target. He can also use the hole in a large-scale attack against the entire userbase (for example publish a malformed MP3 file on some popular file sharing networks), but only once, because then the hole will become publicly known and presumably fixed, and after that the risk is the same as for any other published hole. All of this is true both for stable software and for software in active development, and although the developers in an active project may occasionally find a hole and fix it, they may also introduce a new hole at any time. I'm much more nervous over programs like Squirrelmail, Firefox and Thunderbird, for which there is a steady stream of security fixes, because it indicates that the code is of low quality or that the design is fundamentally flawed. Björn Persson 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: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 04:40 PM, Adam Williamson wrote: On Wed, 2009-10-07 at 16:29 -0400, Lyos Gemini Norezel wrote: On 10/07/2009 04:04 PM, Conrad Meyer wrote: Is it possible that id3lib is 'complete'? The id3 format isn't extremely complicated, it may just be a completely finished library. (Keep in mind, though, that I'm not familiar with the code.) I suppose it's possible, but even 'finished' software should have bug fixes and compatibility updates. Compatibility with what? As noted, the IDv3 format hasn't changed. Kernel changes, soname changes, api changes, etc. The IDv3 format is not the only thing this program needs to be compatible with. There are some open bugs, though: http://sourceforge.net/tracker/?limit=10&func=&group_id=979&atid=100979&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter so it seems it's not quite complete. taglib is probably the best actively-developed modern alternative. Hmmm... might be worth looking into... if taglib is still being actively developed. Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-10-02
On Friday 02 October 2009 01:56:21 pm Jon Stanley wrote: > Meeting summary > --- > * incomplete features (jds2001, 17:04:12) > * AGREED: Lower Process Capabilities is retained, dbus changes are > being committed to complete the feature. (jds2001, 17:38:58) I'm wondering if this is still in work? I just checked koji and dbus was rebuilt today, but without applying the patch here: https://bugzilla.redhat.com/show_bug.cgi?id=518541 I really want to mark this feature 100% done. All that needs to be done is change the BuildRequires to libcap-ng-devel and apply the attached patch. Thanks, -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 04:48 PM, Adam Williamson wrote: On Wed, 2009-10-07 at 13:40 -0700, Adam Williamson wrote: There are some open bugs, though: http://sourceforge.net/tracker/?limit=10&func=&group_id=979&atid=100979&assignee=&status=1&category=&artgroup=&submitter=&keyword=&artifact_id=&submit=Filter so it seems it's not quite complete. taglib is probably the best actively-developed modern alternative. There's also an Ubuntu bug report indicating the use of id3lib causes some problems: https://bugs.launchpad.net/ubuntu/+source/tagtool/+bug/180110 That bug report also points out that id3lib is optional for easytag. Nice. Good to know I'm not the only one pondering dropping id3lib from a modern distro, also... these Ubuntu bugs/issues should be investigated on Fedora. It's possible they've caught a bug we have not, though it could be Ubuntu specific (granted, not likely). Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: > I believe the time has come to retire ksensors. > > The last update/release was 18/08/2004, and it appears upstream has been > defunct since at least that time. > > Unless there are objections voiced and/or a maintainer steps forward > before Oct 9 (Friday), I will go ahead and retire this package. Here's an objection! I still use KSensors all the time, it still works perfectly fine and it presents the information in a better way than the plasmoids. (For example, you can have actual numbers for the temperature in the systray as opposed to some funky curves or analog indicators which are hard to read on my small panel.) The plasmoids also seem not to display hddtemp information. But I'm willing to pick up KSensors maintainership if you want to orphan it. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 05:00 PM, Ville Skyttä wrote: On Wednesday 07 October 2009, Adam Williamson wrote: taglib is probably the best actively-developed modern alternative. I might not apply to all cases - kid3 for example uses both. Based on a brief look in the code and http://kid3.sourceforge.net/kid3_en.html#settings-menu, id3lib is used for ID3 2.3.0 tags and taglib for 2.4.0 ones, e.g. when converting from 2.4.0 to 2.3.0. I don't know why though, I'm not sufficiently familiar with either. Nor am I sure why one would convert from 2.4.0 to 2.3.0, maybe for compatibility reasons with $something. And yes, this is quite a corner case. That's odd. Surely a modern ID3 tag program should support all of the IDv3 formats/versions? Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 04:39 PM, Eric Sandeen wrote: I'd say that if/when problems crop up you could revisit it. Maybe the reason it's been idle for so long is that it's simple/done/perfect and could just stay that way. :) If you have any need for a comaintainer I'd be glad to though in any case. Need? Not really. Though I would love to have another set of eyes on this program. So in this case '$want = yes, while $need = no' ;-) -Eric Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
On Wed, 2009-10-07 at 17:10 -0400, Lyos Gemini Norezel wrote: > > Compatibility with what? As noted, the IDv3 format hasn't changed. > > > > Kernel changes, soname changes, api changes, etc. > The IDv3 format is not the only thing this program needs to be > compatible with. id3lib depends on very little else, only very low-level libraries which very rarely change API. Probably the last one to do so was libstdc++ , and that was years ago. As it works perfectly fine in current Rawhide, it would seem apparent that none of these changes has been needed. :) -- 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: Retiring ksensors, possibly id3lib as well?
On 10/07/2009 05:13 PM, Kevin Kofler wrote: Lyos Gemini Norezel wrote: I believe the time has come to retire ksensors. The last update/release was 18/08/2004, and it appears upstream has been defunct since at least that time. Unless there are objections voiced and/or a maintainer steps forward before Oct 9 (Friday), I will go ahead and retire this package. Here's an objection! I still use KSensors all the time, it still works perfectly fine and it presents the information in a better way than the plasmoids. (For example, you can have actual numbers for the temperature in the systray as opposed to some funky curves or analog indicators which are hard to read on my small panel.) The plasmoids also seem not to display hddtemp information. I don't use KDE... so I cannot comment there. However... have you considered trying gnome-applet-sensors? But I'm willing to pick up KSensors maintainership if you want to orphan it. It seems odd to continue such a package despite upstream being defunct. As I no longer use ksensors, if you wish to maintain this package... I will happily surrender maintainership to you. Kevin Kofler Lyos Gemini Norezel <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-10-02
On Wed, 2009-10-07 at 17:11 -0400, Steve Grubb wrote: > On Friday 02 October 2009 01:56:21 pm Jon Stanley wrote: > > Meeting summary > > --- > > * incomplete features (jds2001, 17:04:12) > > > * AGREED: Lower Process Capabilities is retained, dbus changes are > > being committed to complete the feature. (jds2001, 17:38:58) > > I'm wondering if this is still in work? I just checked koji and dbus was > rebuilt today, but without applying the patch here: > > https://bugzilla.redhat.com/show_bug.cgi?id=518541 > > I really want to mark this feature 100% done. All that needs to be done is > change the BuildRequires to libcap-ng-devel and apply the attached patch. I just asked Colin, who looked at the patch. There must have been some miscommunication, since he had expected you to do the build for F12...let me do a build now. Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora 12 Beta Blocker Meeting :: 2009-10-09 @ 15:00 UTC (11 AM EDT)
When: Friday, 2009-10-09 @ 15:00 UTC (11 AM EDT) Where: #fedora-bugzappers on irc.freenode.net Join us Friday for what we hope is the LAST blocker bug review meeting for the Fedora 12 Beta. On Friday we will review the unresolved bugs on https://bugzilla.redhat.com/showdependencytree.cgi?id=507678&hide_resolved=1 517260 [ASSIGNED - medium - dleh...@redhat.com - --- - Reopened] liveinst fails at partitioning screen https://bugzilla.redhat.com/show_bug.cgi?id=517260 526208 [ASSIGNED - low - skvi...@sethdot.org - --- -] preupgrade failed from old release(f10, f11) https://bugzilla.redhat.com/show_bug.cgi?id=526208 526470 [MODIFIED - medium - har...@redhat.com - --- -] NFSv3 mounting broken in dracut netboot https://bugzilla.redhat.com/show_bug.cgi?id=526470 526842 [MODIFIED - urgent - xgl-ma...@redhat.com - --- - Desktop] Firstboot not run after installation https://bugzilla.redhat.com/show_bug.cgi?id=526842 If you are aware of any bugs you think should block the Beta, please set them to block 'F12Beta'. If you are able, please come to the meeting as well to help guide the discussion. We will also start reviewing the Fedora 12 Blocker Bugs--current count == 67! https://bugzilla.redhat.com/showdependencytree.cgi?id=473303&hide_resolved=1 Thanks for your help and time, John -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On 10/07/2009 02:26 PM, Adam Jackson wrote: > In fact, the major reason for not backporting the intel driver to F11 is > that it requires a bunch of kernel changes that no one really has time > for. Among other things, 830 through 865 require GEM in the intel 2.9, > which we have disabled for the F11 kernel for those chips because (as > shipped) it's utterly broken. > > - ajax > I dont have this hardware - but just a question - why not just upgrade to upstream (2.6.32 would be nice in a couple of days ... ) ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: > However... have you considered trying gnome-applet-sensors? gnome-applet-* doesn't work under KDE, that stuff only works in gnome-panel. > It seems odd to continue such a package despite upstream being defunct. > > As I no longer use ksensors, if you wish to maintain this package... I > will happily > surrender maintainership to you. I picked it up, thanks! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
