The rawhide kernel has been rebased to the initial wave of commits that
will eventually become Linux 3.2. I haven't built the kernel in koji
yet, but I will probably do so tomorrow or Monday, depending on how well
a local build works when I test it.
There was a large driver movement in the ethernet drivers that caused a
bunch of config option changes. I think I got them all right and we
should still have all of the ethernet drivers we had enabled before
still being built. However, if you upgrade and notice a driver you were
using is now missing please file a bug and let us know!
Aside from the ethernet driver movement, there are of course a wide
variety of changes and fixes coming in. The linux-next tree for 3.2
submission was the second largest ever, weighing in around 11,000
commits that need to get merged. This is mostly due to the kernel.org
compromise causing the 3.1 release to drag on. Fortunately, Linus is
being a bit of a stickler on what he will pull for 3.2 for a variety of
reasons. Hopefully that helps us as we continue to bring in snapshots
of the merge.
Hang on, it might be a bit of a bumpy ride :).
-----BEGIN PGP SIGNED MESSAGE-----
is it just me or is java-1.7.0-openjdk breaking LibreOffice java
On my machine LO only found java-1.5.0 after installing
java-1.7.0-openjdk. Neither java-1.6.0 nor java-1.7.0 were found by
LO. After removing java-1.7.0-openjdk LO found java-1.5.0 as well as
Mit freundlichen Grüßen/Regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
I posted this on the main mailing list but didn't get any hits.
Hopefully I'll have better luck here.
I found the following thread but I don't think mine is the same problem:
I am, however, running BTRFS on main main partitions on top of LVM
(since anaconda as of F15 still creates an LVM setup regardless of
This is the only thing I can think of that's causing the problem.
$ systemd-analyze blame | head
boot.mount I assume just remounts the boot partition as read-write, so
I think it's just waiting on fedora-storage-init.service.
Today I updated my F16 to latest version. After a while I noticed some
problems with network, I rebooted system and after this my network on
this box doesn't work anymore.
I use NetworkManager and dhcp. During the update NetworkManager and
NetworkManager-glib was updated from 1:0.9.1.90-3.git20110927 to
1:0.9.1.90-4.git20110927, dhclient, dhcp-libs and dhcp-common was
updated from 12:4.2.2-9 to 12:4.2.3-1.
I downgraded NetworkManager and dhcp packages to previous versions,
but my network still doesn't work. I guess that one of other updates
broke it. I see in history:
cronie-* - unlikeley
kernel - I tried previous version - stil no network
perl-* - many packages
ifconfig doesn't show information about inet address so I guess that
it is not obtained from dhcp. When I try to run dhclient manualy it
can obtain data from dhcp, but it works really slow. When I strace it
"wait4(-1, Warning: cannot bind to specific iface, falling back:
Operation not permited"
Does anyone have any idea what should I downgrade to fix my network?
It was pointed out that some changes in GLib 2.31 may cause some fallout
and may be worth calling out explicitly:
- it is no longer possible to include individual headers. If your
package runs into this problem, just replace the problematic includes
with #include <glib.h>
- a number of thread-related apis have been rewritten and some have been
deprecated. if you are affected by this, building without
-DG_DISABLE_DEPRECATED in CFLAGS should help you along.
- gobject-2.0.pc no longer requires gthread-2.0.pc. This might affect
you in that the linker might complain about g_thread_init. There's two
possible fixes: a) remove the call to g_thread_init(), it is no longer
needed with glib 2.31 or b) explicitly add gthread-2.0 to the list of pc
files in configure.ac.
(Cc'ed to devel list to see if anybody else has suggestions).
As you've noted libgnomeuimm has been obsoleted in f16 and higher, and
referencer doesn't look like it's ported to use anything else. I filed
a bug in what appears to be a (potentially) active (but slow) upstream
to get some feedback about whether referencer could be built in the
future, before we retire the package completely:
There is a branch that was started back in February to port to gio
and away from libgnomemm:
There was a commit to it in August, but looks the mm dep is still there
in the configure.ac:
Since I haven't had any responses on my launchpad bug report, I'm
going to reluctantly agree that we'll have to retire this package.
If development does restart, we can always revive the package.
Any other suggestions from the rest of the Fedora community?
----- Original Message -----
> I was looking at Fedora 16 broken deps report and referencer is one of
> the apps listed as still needing old mm libraries that were retired a
> while ago. You are listed as a co-maintainer for referencer; do you
> think it should also be retired in F16?
> referencer-1.1.6-17.fc16.i686 requires libpoppler.so.14
> referencer-1.1.6-17.fc16.i686 requires libgnomevfsmm-2.6.so.1
> referencer-1.1.6-17.fc16.i686 requires libgnomeuimm-2.6.so.1
> referencer-1.1.6-17.fc16.i686 requires libgnomemm-2.6.so.1
> referencer-1.1.6-17.fc16.i686 requires libboost_regex.so.1.46.1