Unresponsive Maintainer: brouhaha
by John Dulaney
The maintainer for python-cairocffi has been non-responsive for some
time. For example, I opened 1249821 in early August; never received a
response; adamw finally did the deed for me. I opened 1273567 in
October, and have still not received a single response. 1288627 was
opened in early December by someone else, and has not received a
response.
In October, I requested commit acls to the package so as to resolve
these outstanding issues and possibly move things forward in the future.
I have not received a response.
I opened 1299042 for unresponsive maintainer, and still have not received
a response.
John.
8 years, 2 months
IceCat-38.6 and GCC-6.0
by Antonio Trande
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 01/29/2016 11:41 AM, Antonio Trande wrote:
Hi all.
Latest IceCat-38.6.0 does not compile with GCC-6.0:
> ... In file included from
> ../../dist/include/mozilla/MathAlgorithms.h:15:0, from
> /builddir/build/BUILD/icecat-38.6.0/xpcom/glue/nsTArray.h:14, from
> /builddir/build/BUILD/icecat-38.6.0/xpcom/glue/nsStringAPI.h:25,
> from
> /builddir/build/BUILD/icecat-38.6.0/xpcom/glue/nsStringGlue.h:21,
> from ../../dist/include/mozilla/AppData.h:12, from
> /builddir/build/BUILD/icecat-38.6.0/xpcom/glue/AppData.cpp:7, from
>
> /builddir/build/BUILD/icecat-38.6.0/icecat-objdir/xpcom/glue/Unified_cpp_xpcom_glue0.cpp:2:
>
>
> /usr/include/c++/6.0.0/cmath:615:11: error: '::isinf' has not
> been declared using ::isinf; ^~~~~
> /usr/include/c++/6.0.0/cmath:640:11: error: '::isnan' has not been
> declared using ::isnan; ^~~~~
> /builddir/build/BUILD/icecat-38.6.0/config/rules.mk:930: recipe for
> target 'Unified_cpp_xpcom_glue0.o' failed
>
Do you know how to fix this issue?
Full build log:
https://kojipkgs.fedoraproject.org//work/tasks/2975/12712975/build.log
- --
Antonio Trande
mailto: sagitter 'at' fedoraproject 'dot' org
http://fedoraos.wordpress.com/
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: 0x565E653C
Check on https://keys.fedoraproject.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEbBAEBCAAGBQJWq2j3AAoJEF5tK7VWXmU83XkH9R3Wag608RLvidia1ZzqTCr4
1IoWEjy8+2+HvEsLIJbZCD1SGfHRyjENazJ5nr/JetdGJbXmLmENcjsnU+H07jSc
9Uk2K5Cldb+PnMpqAVdyGcpGzsIszqFGnB1FZT6isLCwnAvC9pObOZu8TJdvHq9R
Q5xWHhtYutk3/xoAj4YCSCB+N+RZgGGm9w8eNy532XuyDd2btzmK3DhUXIEu80hD
COv6wG7OJP8NjCmUDEsPfHCKdHw+ydUW8fy3BE2UTvFCZjiIpCN8ZHM+r3YYDM4c
yZ7MQIhlL8SGVQkW/uZzUUTKWDJOlVHhOb+rC7yzkStTZQ6lvR24LFsEM3O7tQ==
=HiT9
-----END PGP SIGNATURE-----
8 years, 2 months
Gnome always broken in Rawhide
by Vít Ondruch
Hi everybody,
I am wondering why the Gnome updates in Rawhide has to be always broken?
Today I updated my computer just to find out that my gnome-shell is
crashing instantly. As it turned out, majority of Gnome components were
at 3.19.4 version but gnome-shell was at 3.19.3. Yes, there is already
gnome-shell 3.19.4 in Koji, which fixes the crashes, but I really don't
understand, why you don't build the Gnome in a side tag or why the
dependencies are not more strict to prevent the broken update?
I am not even mentioning that gnome-shell now consumer like 18% of my
CPU, probably due to the constant spamming of my journal:
Jan 22 10:29:26 localhost org.gnome.Shell.desktop[2270]:
(gnome-shell:2270): Gdk-WARNING **: gdk-frame-clock: layout continuously
requested, giving up after 4 tries
Jan 22 10:29:26 localhost org.gnome.Shell.desktop[2270]:
(gnome-shell:2270): Gdk-WARNING **: gdk-frame-clock: layout continuously
requested, giving up after 4 tries
Jan 22 10:29:26 localhost org.gnome.Shell.desktop[2270]:
(gnome-shell:2270): Gdk-WARNING **: gdk-frame-clock: layout continuously
requested, giving up after 4 tries
Jan 22 10:29:26 localhost org.gnome.Shell.desktop[2270]:
(gnome-shell:2270): Gdk-WARNING **: gdk-frame-clock: layout continuously
requested, giving up after 4 tries
Jan 22 10:29:26 localhost org.gnome.Shell.desktop[2270]:
(gnome-shell:2270): Gdk-WARNING **: gdk-frame-clock: layout continuously
requested, giving up after 4 tries
Jan 22 10:29:26 localhost org.gnome.Shell.desktop[2270]:
(gnome-shell:2270): Gdk-WARNING **: gdk-frame-clock: layout continuously
requested, giving up after 4 tries
Could you Gnome guys please be more kind to the Rawhide users?
Thank you.
Vít
8 years, 2 months
F24 System Wide Change: Mono 4.2
by Jan Kurik
= Proposed System Wide Change: Mono 4.2 =
https://fedoraproject.org/wiki/Changes/Mono4.2
Change owner(s):
* Claudio Rodrigo Pereyra Diaz <elsupergomez AT fedoraproject DOT org>
Update the Mono stack in Fedora to 4.2 aca Cyle 6
== Detailed Description ==
Mono 4.2 is the last release of Cycle 6 from Xamarin. See more details
at Mono 4.2.1: http://www.mono-project.com/docs/about-mono/releases/4.2.1/
== Scope ==
Proposal owners:
* Mono 4.2 is in rawhide now. Most of the application must work fine
with this update. See [1]
Other developers:
* Need check proper build on alternative platforms like ppc64 and s390
Release engineering: N/A
List of deliverables: N/A
Policies and guidelines: N/A
Trademark approval: N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
8 years, 2 months
Bodhi error: security updates stuck with no way to request stable
by Jamie Nguyen
Hi,
This update for 3 Nginx CVEs was auto-submitted to stable yesterday:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-fd3428577d
I got this error message:
nginx-1.8.1-1.fc23 ejected from the push because 'Request --RAW HTML
NOT ALLOWED-- inconsistent with mash request --RAW HTML NOT ALLOWED--'
Now there isn't an option for me to request a push to stable. I notice
that this also happened for the Firefox 44 security update that's
currently in testing.
How do I push this and get these CVEs fixed?
(Meanwhile, I also have F22/EL7 updates for the same CVEs that are still
waiting to hit testing after 72 hours.)
Kind regards,
Jamie
8 years, 2 months
[design-suite] Broken packages
by Luya Tshimbalanga
Checking the nightly compose from Design Suite Lab[1], these packages
are currently broken according to root.log[2] : Blender,
LuxRender-Blender, Synfig, Calligra-Krita
synfig-0.64.3-8.fc24.x86_64 requires libboost_program_options.so.1.59.0()(64bit)
DEBUG util.py:399: 1:blender-2.76-4.fc24.x86_64 requires libboost_system.so.1.59.0()(64bit)
DEBUG util.py:399: 1:blender-2.76-4.fc24.x86_64 requires libboost_locale.so.1.59.0()(64bit)
DEBUG util.py:399: 1:blender-2.76-4.fc24.x86_64 requires libboost_thread.so.1.59.0()(64bit)
DEBUG util.py:399: 1:blender-2.76-4.fc24.x86_64 requires libboost_date_time.so.1.59.0()(64bit)
DEBUG util.py:399: LuxRender-blender-1.3.1-27.fc24.x86_64 requires blender(ABI) = 2.75
DEBUG util.py:399: calligra-krita-libs-2.9.10-3.fc24.x86_64 requires libboost_system.so.1.59.0()(64bit)
DEBUG util.py:399: calligra-krita-2.9.10-3.fc24.x86_64 requires libboost_system.so.1.59.0()(64bit)
DEBUG util.py:399: 1:blender-2.76-4.fc24.x86_64 requires libboost_regex.so.1.59.0()(64bit)
DEBUG util.py:399: 1:blender-2.76-4.fc24.x86_64 requires libboost_filesystem.so.1.59.0()(64bit)
Can these maintainers fix these dependencies issues please? Thanks.
Reference
--------------
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=12667958
[2]
http://koji.fedoraproject.org/koji/getfile?taskID=12667958&name=root.log&...
--
Luya Tshimbalanga
Graphic & Web Designer
E: luya(a)fedoraproject.org
W: http://www.coolest-storm.net
8 years, 2 months
Request for advice: Major version update of Nginx on EL5/6/7
by Jamie Nguyen
Hi,
Distributions like RHEL and Debian have a very strict update policy (for
good reason). People expect stability and don't want surprises.
When CVEs arise, patches can often be backported. Nginx 1.8.1 recently
fixed three CVEs and I've backported to Nginx 1.6.x on EL7.
Unfortunately, Nginx 1.0.x on EL6 is too old; I gave it a good shot but
backporting the patches reliably without creating new CVEs is beyond my
expertise. Nginx 0.8.x on EL5 is prehistoric.
I've had a couple of bug reports recently suggesting that I rebase Nginx
to 1.8.1 on all branches. On the one hand, I want to avoid causing
surprises and breaking somebody's website. On the other hand, these
vulnerabilities do need to be fixed. (The approach I took with the Tor
package is to always use the latest stable release on all branches,
which is working well.)
What do people think? Should I go ahead and update all branches (with
appropriate migration notes)?
Kind regards,
Jamie
8 years, 2 months