devel February 2017

devel@lists.fedoraproject.org

242 participants
270 discussions

apitrace, bundled libbacktrace
by Sandro Mani 17 Dec '17

17 Dec '17

Hi, apitrace 5.0 bundles libbacktrace, which looks like is living within the gcc sources. libbacktrace is not build as a shared library from the gcc sources, and not packaged. Is it feasible to build libbacktrace as a shared library and ship it in a corresponding package? Or should I rather go for a bundling exception request? Thanks, Sandro

8 9

Reminder: upcoming retirement of webkitgtk and webkitgtk3 packages
by Michael Catanzaro 13 Dec '17

13 Dec '17

Hi, This is a reminder that the webkitgtk and webkitgtk3 packages will be retired from rawhide shortly after F26 is branched from rawhide. This is due to numerous security issues affecting those packages (I just counted 204 CVEs), many of which could allow remote code execution. Bugs have already been filed against all directly-affected packages [1]. Note: to count the vulnerabilities, I just manually added up the CVEs listed at [2], ignoring the oldest advisory WSA-2015-0001, and discounting five of the older vulnerabilities in WSA-2015-0002. Michael [1] https://bugzilla.redhat.com/show_bug.cgi?id=1375784 [2] https://webkitgtk.org/security.html

10 26

Two more concrete ideas for what a once-yearly+update schedule would look like
by Matthew Miller 03 Aug '17

03 Aug '17

Trying to make this idea a little more concrete. Here's two suggestions for how it might work. These are strawman ideas -- please provide alternates, poke holes, etc. And particularly from a QA and rel-eng point of view. Both of these are not taking modularity into account in any way; it's "how we could do this with our current distro-building process". Option 1: Big batched update 1. Release F26 according to schedule https://fedoraproject.org/wiki/Releases/26/Schedule 2. At the beginning of October, stop pushing non-security updates from updates-testing to updates 3. Bigger updates (desktop environment refreshes, etc.) allowed into updates-testing at this time. 4. Mid-October, freeze exceptions for getting into updates-testing even. 5. Test all of that together in Some Handwavy Way for serious problems and regressions. 6. Once all good, push from updates-testing to updates at end of October or beginning of November. Option 2: Branching! 1. Release F26 according to schedule. 2. July/August: branch F26.1 from F26 (not rawhide) 3. Updates to F26 also go into F26.1 (magic happens here?) 4. No Alpha, but do "Beta" freeze and validation as normal for release. 5. And same for F26.1 final 6. And sometime in October/November, release that (but without big press push). 7. GNOME Software presents F26.1 as upgrade option 8. F26 continues in parallel through December 9. In January, update added to F26 which activates the F26.1 repo. 10. And also in January updates stop going to F26. Some of this idea, by the way, is reminiscent of Spot's suggestions at FUDCon Lawrence in 2013. This is not completely coincidence - I always liked those ideas! -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

39 150

Xulrunner - intent to remove from Fedora 24
by Martin Stransky 27 Jun '17

27 Jun '17

Hi, does anyone use the xulrunner package? (and gecko-devel actually). Mozilla does not maintain it any more and the XUL as technology is going to be removed/deprecated. I'd like to remove the package from Fedora 24. ma.

21 30

F25 Self Contained Change: IBus Emoji Typing
by Jaroslav Reznik 09 May '17

09 May '17

= Proposed Self Contained Change: IBus Emoji Typing = https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing Change owner(s): * Takao Fujiwara <tfujiwar [at] redhat [dot] com> The IBus core will provide the Emoji Unicode typing with the IBus XKB engines. == Detailed Description == IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and now we think the similar implementation for the Emoji typging. With IBus XKB engines, Emoji typing will be provided with the Emoji annotations [1] following Ctrl- Shift-e. == Scope == * Proposal owners: - IBus core provide the dictionary of the Emoji typing. - IBus XKB engines load the Emoji dictionary. * Other developers: N/A * Release engineering: N/A - List of deliverables: N/A * Policies and guidelines: N/A * Trademark approval: N/A [1] http://unicode.org/emoji/charts/index.html#col-annotations

7 24

Any voluteers for maintaining xml-security-c?
by mihkel＠fedoraproject.org 30 Mar '17

30 Mar '17

Hey. I'm looking volunteers for maintaining xml-security-c package in Fedora. Current version is old in our repos and for example esteid (Estonian ID card) packages depend on newer xml-security-c (with openssl 1.1 support). I've already contacted anttix who is current package administrator to give committer rights to bruno and also contacted bruno to find out if he is still interested in maintaining it. Negative. And I'm also not too confident of maintaining it because of lack of in depth knowledge what I might end up with. So I'm seeking towards devel list to find out, are there any volunteers with enough courage to update and maintain it. https://admin.fedoraproject.org/pkgdb/package/rpms/xml-security-c/

4 8

Stuck maxima builds on aarch64
by Jerry James 24 Mar '17

24 Mar '17

I fixed the mass rebuild FTBFS errors for clisp and ecl yesterday, and started a build of maxima due to changes in both clisp and ecl. Something is afoot. There are two previous builds for maxima that both claim to be in the building state, but were started quite a long time ago: 19 Dec 2016: https://koji.fedoraproject.org/koji/buildinfo?buildID=826479 12 Jan 2017: https://koji.fedoraproject.org/koji/buildinfo?buildID=833415 Then there is my attempt from yesterday: https://koji.fedoraproject.org/koji/buildinfo?buildID=861874 In all 3 cases, the build finished successfully on all architectures except aarch64. But I'm puzzled as to what is going on with my latest build attempt. The build log for aarch64 says, in its entirety: Mock Version: 1.3.3 Mock Version: 1.3.3 ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target aarch64 --nodeps /builddir/build/SPECS/maxima.spec'], logger=<mockbuild.trace_decorator.getLog object at 0xffff7e8c3390>user='mockbuild'printOutput=Falseshell=Falseuid=1000env={'HOME': '/builddir', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'SHELL': '/bin/bash', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'TERM': 'vt100', 'LANG': 'en_US.UTF-8', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'HOSTNAME': 'mock'}gid=425chrootPath='/var/lib/mock/f26-build-7778919-700214/root'timeout=172800) Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target aarch64 --nodeps /builddir/build/SPECS/maxima.spec'] with env {'HOME': '/builddir', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'SHELL': '/bin/bash', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'TERM': 'vt100', 'LANG': 'en_US.UTF-8', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'HOSTNAME': 'mock'} and shell False sh: ecl: command not found Building target platforms: aarch64 Building for target aarch64 Wrote: /builddir/build/SRPMS/maxima-5.39.0-4.fc26.src.rpm Child return code was: 0 So ... the source RPM was built successfully, even though ecl was not found. Then why wasn't the build launched? Looking at root.log, it looks like a dnf transaction has stalled. The last lines are: DEBUG util.py:435: Total 7.7 MB/s | 32 MB 00:04 DEBUG util.py:435: Running transaction check DEBUG util.py:435: Transaction check succeeded. DEBUG util.py:435: Running transaction test DEBUG util.py:435: Transaction test succeeded. DEBUG util.py:435: Running transaction Except the transaction is not running. I guess that "sh:ecl: command not found" is due to this line in the spec file: %global ecllib %(ecl -eval "(princ (SI:GET-LIBRARY-PATHNAME))" -eval "(quit)") but that doesn't seem to have been fatal for the SRPM building step, and should evaluate just fine during the actual build. So what's going on? -- Jerry James http://www.jamezone.org/

5 12

fedora-review complains about gschema files in an RPM package
by Andrew Toskin 24 Mar '17

24 Mar '17

I'm a new Fedora packager; my very first packages have not yet been accepted. I'm working on RPM packages for a few GNOME Shell extensions. Things are mostly going well, except that `fedora-review` complains about gschemas in the packages, and I'm not entirely sure what this is supposed to be telling me. Issues: ======= - glib-compile-schemas is run in %postun and %posttrans if package has *.gschema.xml files. Note: gschema file(s) in gnome-shell-extension-activities-configurator See: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GSettings_Schema I've read the linked wiki page, and I still don't understand what I'm supposed to *do*. At first, I thought maybe I'm not supposed to do `glib-compile-schemas` myself, because rpmbuild will take care of it? Except one of my packages gets this fedora-review message, and the `glib-compile-schemas` command does not appear anywhere in my spec. And the source does not have a Makefile, nor any other build scripts which might sneakily compile schema files without my noticing. I've checked. Then I thought maybe I'm just not supposed to include .gschema.xml files in the package at all? But that doesn't seem right either, because there are plenty of other GNOME Shell extensions in the Fedora repos that also include .gschema.xml files. dnf repoquery --list "gnome-shell-extension-*" | grep -i gschema

6 13

-Wno-format vs. -Werror=format-security
by Jakub Jelinek 16 Mar '17

16 Mar '17

Hi! As you might know, redhat-rpm-config is adding -Wall -Werror=format-security into $RPM_OPT_FLAGS/%{optflags} by default. I've recently fixed a bug #1425825 where -Wall -Werror=format-security -Wall or -Wall -Werror=format-security -Wformat etc. actually disabled the -Wformat-security warning (unlike -Wall -Wformat-security -Wall etc. that behaved as intended before). Now, this change might have a consequence on some packages, in particular e.g. if you append -Wno-format to the standard optflags in some Makefile, you might get errors because -Wno-format doesn't disable the explicitly specified suboptions like -Wformat-security and having -Wformat-security enabled and -Wno-format is an error. The fix is if you really need to add -Wno-format, also add -Wno-format-security to cancel the default -Werror=format-security provided by redhat-rpm-config. Jakub

2 1

iproute package update policy
by Phil Sutter 14 Mar '17

14 Mar '17

Hi, So far my idea of maintaining Fedora's iproute package was to do full version updates only in Rawhide and backport patches selectively to stable versions on behalf of bug reports. But since stable versions indeed receive full kernel updates (not just backported patches), there is an understandable amount of frustration amongst users when the shiny new kernel that comes with e.g. F22 provides features userspace does not support. Especially since upstream iproute2 does not really have a concept of stable versions, I'm in a bit of a dilemma here: update to keep in sync with the kernel or not update to not unnecessarily destabilize the system? Any comments/advice are highly appreciated. Thanks, Phil

7 13

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel February 2017