I corrected license declaration in perl-Encode and perl-Encode-devel
packages from (GPL+ or Artistic) to ((GPL+ or Artistic) and UCD) because
there are Unicode tables transformed into the executable code. I did it
in all supported Fedoras.
= Proposed Self Contained Change: Xfce412 =
Change owner(s): Kevin Fenzi <kevin(a)scrye.com>, Mukundan Ragavan
<nonamedotc(a)fedoraproject.org>, Christoph Wickert <cwickert(a)fedoraproject.org>
Update Xfce to the new 4.12 release with a number of bugfixes and improvements.
* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *
== Detailed Description ==
Upstream Release Date: 2015-02-28
This release will have a number of bugfixes and improvements, but no radical
== Scope ==
* Proposal owners: Update Xfce packages. Update Xfce spin with any needed
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
devel-announce mailing list
Dear perl-List-AllUtils users, a review discovered perl-List-AllUtils
uses Artistic 2.0 license since 0.04 version. (The old license was (GPL+
or Artistic).) Fixed RPM packages have been built for Fedora 21 and
Hi, folks! Time (and past time) for a Fedora 22 blocker status review.
Sorry this is late; we've been fighting fires for the last week :(
Here are your outstanding blockers requiring attention from test,
devel, or both:
"network spoke listed as not connected despite having assigned IP and
hostname" - anaconda team have the impression that this is an ARM-
specific kernel issue to do with renaming of ethernet devices on ARM;
could do with input from ARM folks.
crash during kickstart" - this needs re-testing with the fixed
anaconda, except the 'fixed' anaconda is DOA due to other issues; I've
alerted the anaconda team to the issues.
cloud builds fail to boot with kernel panic" - this could do with a
status update; I get the impression it may be a bit out of date, but
as of now it shows as NEW. Could cloud folks please review?
FREEIPA / SSSD: https://bugzilla.redhat.com/show_bug.cgi?id=1197218
"Add missing dependencies into freeipa packages" - this still appears
to need attention, but it may no longer block release as
https://bugzilla.redhat.com/show_bug.cgi?id=1014594has been pulled in
as a freeze exception. It would be good to get clarification on the
current status - sgallagh?
FREEIPA: https://bugzilla.redhat.com/show_bug.cgi?id=1195811"PKI fails
to install, missing support for Tomcat 8.0" - the Tomcat 7 revert is
built and in updates-testing thanks to sgallagh, we will need to test
it now, whether with scratch images or by rolling a TC9 tomorrow.
"dhclient is started by NetworkManager at disconnection instead of at
connection time" - this seems to be a straight-up NM bug affecting
wired network connections on some hardware (at least recent Thinkpads)
that still requires developer attention.
XORG: https://bugzilla.redhat.com/show_bug.cgi?id=1196676"X fails to
start when booting x86_64 netinst on basic graphic mode (nomodeset)" -
this requires developer attention; it's been discussed on the list
already, but a fix hasn't appeared yet.
For testers, the list of builds requiring karma is quite light right
now. As anaconda is currently known to be broken, it's really only the
https://admin.fedoraproject.org/updates/tomcat-7.0.59-3.fc22. It would
help a lot if folks who are able to test FreeIPA deployments can test
with that Tomcat and confirm that FreeIPA works with it. We will
probably want to roll a new compose tomorrow, ideally with an updated
anaconda, but we cannot roll an RC yet due to several blockers still
being outstanding (most of the above).
As Go/No-Go is scheduled for Thursday we're unfortunately very likely
to slip Alpha at this point :( Despite our attempts to test earlier in
the cycle, many late-landing changes caused problems, and we were not
able to test the flavor/Product-ized images until the first TC landed.
The GCC rebuild certainly seems to have caused its fair share of havoc
:(. Aside from the bugs listed above we have a near-blocker for the
KDE images - https://bugzilla.redhat.com/show_bug.cgi?id=1194682-
which is still being worked on.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
test-announce mailing list
On Sun, Mar 1, 2015 at 10:31 PM, Christopher Meng <cickumqt(a)gmail.com> wrote:
> I encountered this when I distro-synced my f21 non-product to rawhide
> and kernel updated to 4.0 in this morning.
> Now no matter which kernel the system runs under, all couldn't start
> X, with these in Xorg.0.log:
> Loading /usr/lib64/xorg/modules/libvbe.so
> [ 99.976] (EE) Failed to load /usr/lib64/xorg/modules/libvbe.so:
> /usr/lib64/xorg/modules/libvbe.so: undefined symbol: xf86int10Addr
> [ 99.976] (II) UnloadModule: "vbe"
> [ 99.976] (II) Unloading vbe
> [ 99.976] (EE) VESA: Failed to load module "vbe" (loader failed, 7)
> [ 99.976] (II) UnloadModule: "vesa"
> [ 99.976] (EE) Screen(s) found, but none have a usable configuration.
> [ 99.976] (EE)
> Fatal server error:
> [ 99.976] (EE) no screens found(EE)
> [ 99.976] (EE)
> Full log: http://pastebin.com/8XbhFU1T
> The system is virtualized by Parallels.
> Yours sincerely,
> Christopher Meng
> devel mailing list
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
What happens when you use the latest build:
As described here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
We've been working on making xorg-x11-drv-libinput the default input driver for the Xorg xserver under Fedora 22. All the necessary changes for this are in place for the GNOME and KDE desktops. So starting with the next Fedora 22 compose new Fedora 22 Workstation installations will be using xorg-x11-drv-libinput instead of the -evdev and -synaptics drivers.
For existing installations the move to libinput will not happen automatically, as we have not added a hard dependency on xorg-x11-drv-libinput so the XFCE, LXDE, etc. spins can keep using the old drivers until they have adopted their mouse/touchpad configuration settings tools to also work with xorg-x11-drv-libinput.
If you're running F-22 with GNOME or KDE, please do the following to switch to the new driver:
"sudo dnf install xorg-x11-drv-libinput"
And let us know if you experience any issues while using the new driver.