5:03 a.m.
Updated Packages:
firefox-2.0.0.3-2.fc7
---------------------
* Sun Mar 25 2007 Christopher Aillon <caillon(a)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(a)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(a)redhat.com> - 0.5.9-0.git20070304.fc7.1
- Fix directory ownership issues (#233840)
* Sun Mar 04 2007 David Zeuthen <davidz(a)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(a)redhat.com>
- 2.6.21-rc5
* Sun Mar 25 2007 Dave Jones <davej(a)redhat.com>
- 2.6.21-rc4-git11
* Sun Mar 25 2007 David Woodhouse <dwmw2(a)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(a)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(a)redhat.com> 2.5.10-2
- Allow samba to run groupadd
* Thu Mar 22 2007 Dan Walsh <dwalsh(a)redhat.com> 2.5.10-1
- Update to upstream
* Thu Mar 22 2007 Dan Walsh <dwalsh(a)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
5:08 a.m.
On Tue, 2007-03-27 at 06:03 -0400, buildsys(a)redhat.com wrote:
hal-0.5.9-0.git20070326.fc7
---------------------------
* Mon Mar 26 2007 David Zeuthen <davidz(a)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.
5:35 a.m.
On 27.03.2007 12:08, Richard Hughes wrote:
On Tue, 2007-03-27 at 06:03 -0400, buildsys(a)redhat.com wrote:
> hal-0.5.9-0.git20070326.fc7
> ---------------------------
> * Mon Mar 26 2007 David Zeuthen <davidz(a)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
5:46 a.m.
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(a)redhat.com wrote:
>> hal-0.5.9-0.git20070326.fc7
>> ---------------------------
>> * Mon Mar 26 2007 David Zeuthen <davidz(a)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.
6:06 a.m.
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
6:14 a.m.
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.
6:13 a.m.
On Tue, Mar 27, 2007 at 11:08:31AM +0100, Richard Hughes wrote:
On Tue, 2007-03-27 at 06:03 -0400, buildsys(a)redhat.com wrote:
> hal-0.5.9-0.git20070326.fc7
> ---------------------------
> * Mon Mar 26 2007 David Zeuthen <davidz(a)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
8:53 a.m.
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?
9:16 a.m.
On Tue, 2007-03-27 at 11:08 +0100, Richard Hughes wrote:
On Tue, 2007-03-27 at 06:03 -0400, buildsys(a)redhat.com wrote:
> hal-0.5.9-0.git20070326.fc7
> ---------------------------
> * Mon Mar 26 2007 David Zeuthen <davidz(a)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
9:20 a.m.
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(a)redhat.com wrote:
> > hal-0.5.9-0.git20070326.fc7
> > ---------------------------
> > * Mon Mar 26 2007 David Zeuthen <davidz(a)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.
9:16 a.m.
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.
9:28 a.m.
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 (:
--
Jesse Keating
Release Engineer: Fedora
11:16 a.m.
On Tue, 2007-03-27 at 14:13 +0100, Richard Hughes wrote:
On Tue, 2007-03-27 at 06:03 -0400, buildsys(a)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
12:14 p.m.
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(a)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
3:13 p.m.
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(a)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
6249
days inactive
6249
days old
19 comments
7 participants
participants (7)
-
Build System -
David Zeuthen -
Jesse Keating -
Patrice Dumas -
Ralf Ertzinger -
Richard Hughes -
Thorsten Leemhuis