Updated Packages:
firefox-2.0.0.3-2.fc7 --------------------- * Sun Mar 25 2007 Christopher Aillon caillon@redhat.com 2.0.0.3-2 - Fix the symlink to default bookmarks - Use mktemp for temp dirs
hal-0.5.9-0.git20070326.fc7 --------------------------- * Mon Mar 26 2007 David Zeuthen davidz@redhat.com - 0.5.9-0.git20070326 - Update to hal 0.5.9rc2 and hal-info-20070326 - Bring back Fedora eject patch (#231459) - Build docs and put them in new subpackage hal-docs
* Sun Mar 25 2007 Matthias Clasen mclasen@redhat.com - 0.5.9-0.git20070304.fc7.1 - Fix directory ownership issues (#233840)
* Sun Mar 04 2007 David Zeuthen davidz@redhat.com - 0.5.9-0.git20070304 - Update to 0.5.9rc1; notable user visible changes: - New /sbin/umount.hal helper (#188193) - Slow down polling if no session is non-idle (#204969) - Refuse to eject busy devices (#207177) - Don't mount noexec unless requested - Use inotify to watch for new fdi files - Support for new Firewire stack - BT killswitch for Sony laptops (hadess) - Pass suspend quirks to pm-utils (need new pm-utils release to use it)
kernel-2.6.20-1.3023.fc7 ------------------------ * Sun Mar 25 2007 Dave Jones davej@redhat.com - 2.6.21-rc5
* Sun Mar 25 2007 Dave Jones davej@redhat.com - 2.6.21-rc4-git11
* Sun Mar 25 2007 David Woodhouse dwmw2@redhat.com - Use /sys/power/state for suspend to RAM on PowerMac
policycoreutils-2.0.7-5.fc7 --------------------------- * Fri Mar 23 2007 Dan Walsh dwalsh@redhat.com 2.0.7-5 - Change location of audit2allow and sepol-ifgen to sbin - Updated version of sepolgen
selinux-policy-2.5.10-2.fc7 --------------------------- * Fri Mar 23 2007 Dan Walsh dwalsh@redhat.com 2.5.10-2 - Allow samba to run groupadd
* Thu Mar 22 2007 Dan Walsh dwalsh@redhat.com 2.5.10-1 - Update to upstream
* Thu Mar 22 2007 Dan Walsh dwalsh@redhat.com 2.5.9-6 - Allow mdadm to access generic scsi devices
Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11
On Tue, 2007-03-27 at 06:03 -0400, buildsys@redhat.com wrote:
hal-0.5.9-0.git20070326.fc7
- Mon Mar 26 2007 David Zeuthen davidz@redhat.com -
0.5.9-0.git20070326
- Update to hal 0.5.9rc2 and hal-info-20070326
These *need* to be split into separate SRPMS. I don't mind co-maintaining these if you want, but if we are updating machine quirks once a month or so, then we should be able to update one 100k no-arch package, rather than 4 or 5 multi-megabyte architecture specific packages.
Sorry to harp on about this, but F7T3 is getting closer.
Richard.
On 27.03.2007 12:08, Richard Hughes wrote:
On Tue, 2007-03-27 at 06:03 -0400, buildsys@redhat.com wrote:
hal-0.5.9-0.git20070326.fc7
- Mon Mar 26 2007 David Zeuthen davidz@redhat.com -
0.5.9-0.git20070326
- Update to hal 0.5.9rc2 and hal-info-20070326
These *need* to be split into separate SRPMS. I don't mind co-maintaining these if you want, but if we are updating machine quirks once a month or so, [...]
BTW regarding all those machine quirks to make suspend "simply work":
- is there any coordination with the people behind s2ram?
- for the video related quirks: are you differentiating if the systems where those quirks got tested run -- vesa framebuffer -- chip-specific framebuffer driver -- plain vga (vga=0) on the console and -- free X drivers -- proprietary display drivers in X? Especially using plain VGA or framebuffer seems to influence the options that are needed to bring the video device back to work a lot in my experience. Side note: Ubuntu and Suse both use framebuffer, Fedora a plain text console normally; so a quirk that works on Fedora maybe doesn't help on Suse (or the other way around).
Just wondering. I like the idea to make suspend "simply work" a lot ;-)
CU thl
On Tue, 2007-03-27 at 12:35 +0200, Thorsten Leemhuis wrote:
On 27.03.2007 12:08, Richard Hughes wrote:
On Tue, 2007-03-27 at 06:03 -0400, buildsys@redhat.com wrote:
hal-0.5.9-0.git20070326.fc7
- Mon Mar 26 2007 David Zeuthen davidz@redhat.com -
0.5.9-0.git20070326
- Update to hal 0.5.9rc2 and hal-info-20070326
These *need* to be split into separate SRPMS. I don't mind co-maintaining these if you want, but if we are updating machine quirks once a month or so, [...]
BTW regarding all those machine quirks to make suspend "simply work":
- is there any coordination with the people behind s2ram?
Well, the DMI whitelist is based on the s2ram whitelist. We're hoping to standardise on XML descriptions for both s2ram and HAL.
- for the video related quirks: are you differentiating if the systems
where those quirks got tested run -- vesa framebuffer -- chip-specific framebuffer driver -- plain vga (vga=0) on the console and -- free X drivers -- proprietary display drivers
Yes we can, as we can match the driver in the HAL fdi. As for the other stuff, I don't know. We can tweak this stuff easily with a hal-info update.
in X? Especially using plain VGA or framebuffer seems to influence the options that are needed to bring the video device back to work a lot in my experience.
That's the plan. Without X we are sunk.
Side note: Ubuntu and Suse both use framebuffer, Fedora a plain text console normally; so a quirk that works on Fedora maybe doesn't help on Suse (or the other way around).
Well, all this is very new. The very least we will achieve is to get screens to turn back on when they come back from suspend, i.e. to DPMS on where needed, and to poke vbetool and restore vbestate. Some other odd quirks like radeontool are present, but completely untested.
Just wondering. I like the idea to make suspend "simply work" a lot ;-)
You and me both ;-)
Richard.
On 27.03.2007 12:46, Richard Hughes wrote:
in X? Especially using plain VGA or framebuffer seems to influence the options that are needed to bring the video device back to work a lot in my experience.
That's the plan. Without X we are sunk.
/me wonders who'll be the first that says "X is overrated; 80 colums and 24 (25?) lines is more then enough to run irssi"
Side note: Ubuntu and Suse both use framebuffer, Fedora a plain text console normally; so a quirk that works on Fedora maybe doesn't help on Suse (or the other way around).
Well, all this is very new. The very least we will achieve is to get screens to turn back on when they come back from suspend, i.e. to DPMS on where needed, and to poke vbetool and restore vbestate. Some other odd quirks like radeontool are present, but completely untested.
Well, we'll see how it evolves. Anyway: thx for your great work Richard!
[...]
CU thl
On Tue, 2007-03-27 at 13:06 +0200, Thorsten Leemhuis wrote:
Well, all this is very new. The very least we will achieve is to get screens to turn back on when they come back from suspend, i.e. to
DPMS
on where needed, and to poke vbetool and restore vbestate. Some
other
odd quirks like radeontool are present, but completely untested.
Well, we'll see how it evolves. Anyway: thx for your great work Richard!
No problem. I'm hoping to write a tutorial at some stage (after my finals!) showing how this all works, i.e. adding simple xml file to add stuff like vbestate and vbepost to make resume work.
The idea is that people who can't suspend get the systems to work using pm-suspend with the --quirk options, and then send a report (automatically?) so we can add the DMI data in hal-info for the next update.
Richard.
On Tue, Mar 27, 2007 at 11:08:31AM +0100, Richard Hughes wrote:
On Tue, 2007-03-27 at 06:03 -0400, buildsys@redhat.com wrote:
hal-0.5.9-0.git20070326.fc7
- Mon Mar 26 2007 David Zeuthen davidz@redhat.com -
0.5.9-0.git20070326
- Update to hal 0.5.9rc2 and hal-info-20070326
These *need* to be split into separate SRPMS. I don't mind co-maintaining these if you want, but if we are updating machine quirks once a month or so, then we should be able to update one 100k no-arch package, rather than 4 or 5 multi-megabyte architecture specific packages.
Sorry to harp on about this, but F7T3 is getting closer.
I have also asked it in the merge review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225880#c5
-- Pat
Hi.
On Tue, 27 Mar 2007 11:08:31 +0100, Richard Hughes wrote:
These *need* to be split into separate SRPMS. I don't mind co-maintaining these if you want, but if we are updating machine quirks once a month or so, then we should be able to update one 100k no-arch package, rather than 4 or 5 multi-megabyte architecture specific packages.
Errr.. yum tells me that the hal update is 440k. Where does that multi-meg number come from?
On Tue, 2007-03-27 at 11:08 +0100, Richard Hughes wrote:
On Tue, 2007-03-27 at 06:03 -0400, buildsys@redhat.com wrote:
hal-0.5.9-0.git20070326.fc7
- Mon Mar 26 2007 David Zeuthen davidz@redhat.com -
0.5.9-0.git20070326
- Update to hal 0.5.9rc2 and hal-info-20070326
These *need* to be split into separate SRPMS. I don't mind co-maintaining these if you want, but if we are updating machine quirks once a month or so, then we should be able to update one 100k no-arch package, rather than 4 or 5 multi-megabyte architecture specific packages.
Sorry to harp on about this, but F7T3 is getting closer.
One, this bug is not a feature and that's why I've been punting it since I'd rather spend my time getting features done before feature freeze. Second, the hal and hal-info tarballs needed fixing
http://lists.freedesktop.org/archives/hal/2007-March/007799.html
to actually sanely do this. Third, I'd be happy to see you co-maintain the hal-info package and I think I even suggested you should submit the hal-info SRPM for Fedora Extras. If it's in Extras already, it's simpler to do the switch once the merge is complete. HAL will need a rebuild _anyway_ to take advantage of libsmbios for backlight and rfkill on Dell laptops.
David
On Tue, 2007-03-27 at 10:16 -0400, David Zeuthen wrote:
On Tue, 2007-03-27 at 11:08 +0100, Richard Hughes wrote:
On Tue, 2007-03-27 at 06:03 -0400, buildsys@redhat.com wrote:
hal-0.5.9-0.git20070326.fc7
- Mon Mar 26 2007 David Zeuthen davidz@redhat.com -
0.5.9-0.git20070326
- Update to hal 0.5.9rc2 and hal-info-20070326
These *need* to be split into separate SRPMS. I don't mind co-maintaining these if you want, but if we are updating machine quirks once a month or so, then we should be able to update one 100k no-arch package, rather than 4 or 5 multi-megabyte architecture specific packages.
Sorry to harp on about this, but F7T3 is getting closer.
One, this bug is not a feature and that's why I've been punting it since I'd rather spend my time getting features done before feature freeze.
Ahh, I figured it was a new feature, apologies.
Second, the hal and hal-info tarballs needed fixing http://lists.freedesktop.org/archives/hal/2007-March/007799.html
Yes agreed, cheers for doing this.
to actually sanely do this. Third, I'd be happy to see you co-maintain the hal-info package and I think I even suggested you should submit the hal-info SRPM for Fedora Extras. If it's in Extras already, it's simpler to do the switch once the merge is complete. HAL will need a rebuild _anyway_ to take advantage of libsmbios for backlight and rfkill on Dell laptops.
Sure, I do enough shouting on this list to put my money where my mouth is... ;-) I'll happily co-maintain hal-info. I'll read up on how to do so tonight.
Richard.
On Tue, 2007-03-27 at 10:08 -0400, Jesse Keating wrote:
no. I hope the golden tree has been spun for Test3.
Ick. So the crasher bug fixed in gnome-power-manager 2.18.1 isn't going to be included? I cc'd redhat maintainers about a week ago when doing the release announcement. This means I'll continue to get circa 10 bugs a day about crashing gnome-power-statistics.
Richard.
On Tuesday 27 March 2007 10:16:18 Richard Hughes wrote:
Ick. So the crasher bug fixed in gnome-power-manager 2.18.1 isn't going to be included? I cc'd redhat maintainers about a week ago when doing the release announcement. This means I'll continue to get circa 10 bugs a day about crashing gnome-power-statistics.
I'm sorry, nobody asked for a build of it to be included in the test release. The package changelog has nothing more than "Update to 2.18.1" so I don't really have a way of knowing what it fixes or introduces, so I wasn't about to tag it all on my own.
Thankfully it'll be available as an update. Also thankfully once we merge you can take over gnome-power-manager and maintain it yourself within Fedora (:
On Tue, 2007-03-27 at 14:13 +0100, Richard Hughes wrote:
On Tue, 2007-03-27 at 06:03 -0400, buildsys@redhat.com wrote:
Updated Packages:
Also, are we going to rebuild dbus without asserts for F7T3?
To be determined; I'd rather like to see bad apps getting (like HAL; git20070304 had issues that are hopefully resolved by git20070326) fixed before applying a such a band aid.
David
On Tue, Mar 27, 2007 at 12:16:05PM -0400, David Zeuthen wrote:
On Tue, 2007-03-27 at 14:13 +0100, Richard Hughes wrote:
On Tue, 2007-03-27 at 06:03 -0400, buildsys@redhat.com wrote:
Updated Packages:
Also, are we going to rebuild dbus without asserts for F7T3?
To be determined; I'd rather like to see bad apps getting (like HAL; git20070304 had issues that are hopefully resolved by git20070326) fixed before applying a such a band aid.
Maybe what could be done would be to rebuild dbus without asserts for the final version only?
-- Pat
On Tue, 2007-03-27 at 19:14 +0200, Patrice Dumas wrote:
On Tue, Mar 27, 2007 at 12:16:05PM -0400, David Zeuthen wrote:
On Tue, 2007-03-27 at 14:13 +0100, Richard Hughes wrote:
On Tue, 2007-03-27 at 06:03 -0400, buildsys@redhat.com wrote:
Updated Packages:
Also, are we going to rebuild dbus without asserts for F7T3?
To be determined; I'd rather like to see bad apps getting (like HAL; git20070304 had issues that are hopefully resolved by git20070326) fixed before applying a such a band aid.
Maybe what could be done would be to rebuild dbus without asserts for the final version only?
Yeah, that was my plan. If it turns out that disabling asserts will improve the quality of the Fedora 7 release, I'll do it. But right now I want to get people to fix their apps and disabling the asserts right now will work against that goal.
David
-
Build System -
David Zeuthen -
Jesse Keating -
Patrice Dumas -
Ralf Ertzinger -
Richard Hughes -
Thorsten Leemhuis