I'm trying to build the latest Asterisk sounds package, but I'm
getting the following error:
error: Recognition of file
failed: mode 100444 zlib: invalid stored block lengthsempty (gzip
compressed data, reserved method, encrypted, last modified: Tue Nov 9
20:48:48 2010, max speed)
The full build log is here:
The build fails in mock locally as well but koji actually gives me a
better error message. The file in question isn't gzip compressed,
it's an audio file compressed with G.729 audio compression. Can
anyone help me out here?
I am working on packaging pagedgeometry and I noticed that when building
on gcc it passes -msse which I am guessing says to use sse instructions.
I think that even in F12 we can't assume these instructions are available.
The package may gain a lot of benefit from using those instructions.
(I haven't tested that yet as I am still pretty early in the process.)
Is there some relatively standard way to handle something like this?
since a year or so the AMD K10 thermal sensors module (k10temp) seems to
be floating around the web. I would appreciate some kernel packager
integrating it into the fedora 11 stock kernel - since without it I can
not build (and trust!) a silent cooling system.
Any plans on this issue?
> Hi all.
> I want to add to comps.xml for F10-F13 some optional packages which I not
> To kde-desktop group:
> To graphical-internet group:
> To text-internet group:
> To system-tools group:
> To sound-and-video group:
> To printing group:
> To web-server group:
> To engineering-and-scientific group:
> Is there any objections to do this?
> Should packages maintainers add this packages or I can do this?
No objectiion, thanks for the comps' love.
Normally, this is something maintainers should do, but as they've not
done so yet, maybe it was oversight or an error. To simplify matters
and minimize confusion, I'd say "just do it".
I plan to disable the internal crash handler in wxGTK for the the
devel/F13 branch so we can use ABRT to report crashes. This will mean a
rebuild of wxGTK with --disable-catch_segvs. This change affects all
applications linked with wxGTK, because one symbol is removed from the
"base" library. I will take care of rebuilding the packages, but the
package owners should still check what is their implementation of the
wxApp::OnFatalExpection() virtual method doing, because it will not be
called anymore. Usually it is used to display the wxGTK-based crash
report. Please let me know if you want to rebuild the package yourself
or if you have some questions.
This is the list of packages that are linked with the base
wxWidgets/wxGTK library (libwx_baseu-2.8.so.0):
this is just an announce that finally we will make a new rawhide
release tomorrow with udev support enabled in device-mapper and LVM2
packages (upcoming device-mapper-1.02.39-2, lvm2-2.02.54-2).
This is a scratch you can check and test if you would like to:
We will provide the rules as well as the udev synchronisation
feature (udev_sync) in libdevmapper directly. We have extended its
interface so it's possible to wait for udev to process the events
that are related to actions done on DM devices (create, rename,
resume, remove). This way we can prevent races between libdevmapper
and udev itself.
However, we had to change the layout in /dev based on comments from
- /dev/mapper directory is now filled with symlinks (not nodes)
with names given by actual DM device names
- these symlinks point to /dev/dm-X nodes, X is a number. This is
an internal kernel name that should not be visible in userspace,
but there's this udev requirement that node names must match the
kernel names so...
- as for LVM - we use symlinks in /dev/<vgname> but now these ones
point to /dev/dm-X not /dev/mapper/<actual_dm_name>
Any other software using libdevmapper should work without any
problems while still not using udev_sync feature (libdevmapper
will detect this and it will fallback to old way of node creation
under /dev - that is by libdevmapper itself, the rules will
be selectively switched off automatically in these situations).
However, we expect that everybody using libdevmapper will switch
to using udev_sync interface as well gradually.
There were some problems last time we brought this into the F12 rawhide
a month ago (the most critical were dracut and anaconda). We have
identified these problems and everything should be fixed now (there
are proper hooks in dracut to install the new rules and we provided
a quick workaround in libdevmapper for parted utility that caused
the anaconda to fail, there's also a fix on its way to parted upstream
Maybe I should mention other known problems we track and we know about:
- mount utility uses inappropriate DM names in mtab (because it follows
the symlinks and takes the internal dm-X names). The consequence is
that utilities reading mtab will show these dm-X names instead of
actual DM names (like the output of "df"). The fix is in upstream
util-linux-ng already (as of 26th October) so I hope it will
propagate into rawhide soon.
- since we create the nodes on "change" udev event (and we have to!)
and suppress the node creation on "add" event, there's a problem
while using "udevadm trigger". The trigger generates "add" events
by default and when called, the DM nodes are removed (because
of the node suppression on add and udev removes the nodes if we
use the suppression and the nodes exist already). We have to work out
a proper solution with udev team here, but if you run into this
problem, you can have those DM nodes back by calling:
udevadm trigger --action=change --property-match=DM_UDEV_RULES_VSN=*
or (but this works for kernels >= 2.6.29 only):
udevadm trigger --action=change --attr-match=dm/name
udevadm control --env=STARTUP=1
udevadm control --env=STARTUP=
- there's a problem with GRUB2 that can't deal with the symlinks in
/dev/mapper (it's the grub-probe that fails iirc). Since there are
more things to fix in grub2 with respect to DM devices, we have
to work more closely with grub team to solve this issue and other
Hopefully I've mentioned eveything that's important. If you have any
questions, please, feel free to raise your comments here. The plan is
to switch this on tomorrow, but if there's anyone who sees a problem
here and who would like to test it more and needs more time, please,
let me know.
I want to add to comps.xml for F10-F13 some optional packages which I not
To kde-desktop group:
To graphical-internet group:
To text-internet group:
To system-tools group:
To sound-and-video group:
To printing group:
To web-server group:
To engineering-and-scientific group:
Is there any objections to do this?
Should packages maintainers add this packages or I can do this?