Two more concrete ideas for what a once-yearly+update schedule would
look like
by Matthew Miller
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
6 years, 7 months
Xulrunner - intent to remove from Fedora 24
by Martin Stransky
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.
6 years, 8 months
F25 Self Contained Change: IBus Emoji Typing
by Jaroslav Reznik
= 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
6 years, 10 months
Any voluteers for maintaining xml-security-c?
by mihkel@fedoraproject.org
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/
6 years, 11 months
Stuck maxima builds on aarch64
by Jerry James
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/
6 years, 12 months
fedora-review complains about gschema files in an RPM package
by Andrew Toskin
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 years, 12 months
-Wno-format vs. -Werror=format-security
by Jakub Jelinek
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
7 years
iproute package update policy
by Phil Sutter
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 years
whatever happened to yum + btrfs snapshotting?
by Neal Becker
Some time back there was discussion of being able to rollback yum updates via
btrfs snapshotting. As I recall, it turned out that the default btrfs install
was not setup correctly to make this feasible (I had briefly tested it on my
machine). I haven't heard anything since - this seems like a great idea.
--
-- Those who don't understand recursion are doomed to repeat it
7 years
[Guidelines change] Changes to the packaging guidelines
by Jason L Tibbitts III
Here are the recent changes to the packaging guidelines.
-----
The systemd section of the scriptlet guidelines was updated to indicate
situations where the %systemd_ordering macro may be used instead of
%systemd_requires.
* https://fedoraproject.org/wiki/Packaging:Scriptlets#Systemd
* https://fedorahosted.org/fpc/ticket/644
-----
The guidelines for replacing existing packages have been updated with
mention of the "fedora-obsolete-packages" package:
* https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_...
* https://apps.fedoraproject.org/packages/fedora-obsolete-packages/overview/
* https://fedorahosted.org/fpc/ticket/645
-----
The guidelines for systemd scriptlets were updated with mention of the
macros to be used for systemd user units.
* https://fedoraproject.org/wiki/Packaging:Scriptlets#Systemd
* https://fedorahosted.org/fpc/ticket/647
-----
The SourceURL guidelines were updated to reflect a simpler method for
downloading tagged releases from Github.
* https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Tags
* https://fedorahosted.org/fpc/ticket/651
-----
The Tags and Sections section of the main guidelines was modified to
use "SHOULD" and "MUST" language throughout, and to either discourage
or prohibit the use of certain tags and sections. The section is short,
so I've included it below.
"
* The Copyright:, Packager:, Vendor: and PreReq: tags MUST NOT be used.
* The BuildRoot: tag and %clean section SHOULD NOT be used.
* The contents of the buildroot SHOULD NOT be removed in the first line
of %install.
* The Summary: tag value SHOULD NOT end in a period.
* The Source: tags document where to find the upstream sources for the
package. In most cases this SHOULD be a complete URL to the upstream
tarball. For special cases, please see the SourceURL Guidelines.
* The Group: tag is unnecessary.
"
* https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
* https://fedorahosted.org/fpc/ticket/652
-----
The File Permissions section was cleaned up somewhat, to use slightly
cleaner grammar, use "SHOULD" and "MUST" throughout and to remove
redundant information. In addition, the following sentence was added:
"The %defattr directive in the %files list SHOULD ONLY be used when
setting a non-default value, or to reset to the default value after
having set a non-default value."
* https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions
* https://fedorahosted.org/fpc/ticket/652
-----
The Python Egg guidelines were update to better match current Python
packaging and to mention the %py*_install_egg macros.
* https://fedoraproject.org/wiki/Packaging:Python_Eggs
* https://fedorahosted.org/fpc/ticket/663
-----
The example spec in the Python guidelines was modified to correspond to
the usual, "python3 is default" case where versioned executables are not
installed.
* https://fedoraproject.org/wiki/Packaging:Python
* https://fedorahosted.org/fpc/ticket/672
-----
The guidelines for using Alternatives have been better indicate the
situations where alternatives are and are not appropriate.
* https://fedoraproject.org/wiki/Packaging:Alternatives
* https://fedorahosted.org/fpc/ticket/673
-----
The guidelines for per-product configuration have been updated to allow
copying the config file instead of mandating symlinking and to specify
the location where the variant configurations should be stored.
* https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
* https://fedorahosted.org/fpc/ticket/675
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
7 years