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, 8 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, 9 months
Locale setup for non-shells
by Nikolai Kondrashov
Hi everyone,
At the moment users logging into Fedora on a text terminal (console, SSH,
etc.) get their locale environment variables (LANG, LC_ALL, etc.) set up by
the shell they use. I.e. the shell ultimately sources the /etc/locale.conf
file. This works fine in most cases.
However, if the user has his/her "shell" set to any program that is not one of
the traditional shells, i.e. it doesn't source any shell profiles, or even
doesn't understand any shell language at all, then that program doesn't get
locale settings.
Theoretical examples can include captive portals on jump-hosts, or
special-purpose systems with dedicated TUI instead of a shell. A practical
example that concerns me is a user session recording program [1] which needs
to run before user shell, and intercept all I/O going to and from the
terminal.
I would like to know if it is possible to change Fedora to provide the locale
variables through the environment user "shell" inherits, instead of expecting
it to read /etc/locale.conf, which is distro-specific.
This is done in Debian already. During session setup in login/sshd/etc. they
use pam_env to read /etc/default/locale. Similar thing is possible to do in
Fedora too. E.g. just put this into /etc/pam.d/system-auth:
session required pam_env.so envfile=/etc/locale.conf
Nick
[1] Tlog - terminal I/O logger
https://github.com/Scribery/tlog
6 years, 11 months
F27 System Wide Change: Switch libidn-using applications to IDNA2008
by Jan Kurik
= Proposed System Wide Change: Switch libidn-using applications to IDNA2008 =
https://fedoraproject.org/wiki/Changes/IDNA2008
Change owner(s):
* Nikos Mavrogiannopoulos <nmav AT redhat DOT com>
* Robert Scheck <robert AT fedoraproject DOT org>
The proposed change is about deprecating libidn, which supports
IDNA2003, and switch all applications using libidn, to libidn2 2.0.0,
which supports IDNA2008.
== Detailed Description ==
Internationalized domain names exist for quite some time (IDNA2003),
although the protocols describing them have evolved in an incompatible
way (IDNA2008). These incompatibilities will prevent applications
written for IDNA2003 to access certain problematic domain names
defined with IDNA2008, e.g., faß.de is translated to domain
xn--fa-hia.de with IDNA2008, while in IDNA2003 it is translated to
fass.de domain. That not only causes incompatibility problems, but may
be used as an attack vector to redirect users to different web sites.
The proposed change is about deprecating libidn, which supports
IDNA2003, and switch all applications using libidn, to libidn2 2.0.0,
which supports IDNA2008. The switch should be transparent as the
libidn2 library is API compatible.
Note that even in the web browsers, field there is much confusion on
the topic. Chromium appears to use IDNA2008 transitional (i.e.,
IDNA2003 mapping for the problematic characters), while Firefox and
Safari have already moved to IDNA2008.
For more information see:
* http://nmav.gnutls.org/2017/04/the-mess-with-internationalized-domain.html
* https://www.plesk.com/blog/what-is-the-problem-with-s/
* http://unicode.org/faq/idn.html#6
== Scope ==
* Proposal owners:
The proposal owner is expected to co-ordinate and fill the required
bugs on the distribution.
* Other developers:
Maintainers, should
- Verify that their software is linked with the libidn library
- Update the software from upstream if it already has been converted to libidn2
- Check the libidn2 instructions on converting a package to libidn2.
- Propose patches (trivial task) to convert to libidn2, and notify
upstream about it.
In short switch software from libidn to libidn2, it is sufficient
replacing idna.h header with idn2.h.
* Release engineering:
This feature requires not action from release engineering.
* Policies and guidelines:
Currently Fedora has no guidelines for IDNA support. With this change
the recommended guideline for applications would be to support
IDNA2008 by default.
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 11 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, 11 months
Self Introduction: Travis Kendrick
by Pouar
Hi, I'm Travis (aka Pouar in the Furry Fandom) and I'm hoping to become
a package co-maintainer (assuming there are any packages needing one,
not sure where to find them so I might need help). If not there are a
few packages I could probably submit, but I'm not exactly available 24/7
atm. I've been using Linux since around 2010, although atm my primary
distro is Arch, but I still use Fedora on systems where I don't have the
time/motivation to setup Arch on (I like both distros). I haven't really
did very many big open source projects. On Github I have a heavily
modified branch of Cataclysm-DDA (custom tileset no longer works with
upstream due to an upstream bug and I haven't updated the branch since),
an example identicon generator based off of xxHash that generates
Fursonas (a C variant and a PHP variant). I also have a game written in
a subset of KornShell I was working on that I never released yet due to
me not finishing it. I've been wanting to become a Fedora contributor
for a while, but didn't really get the confidence until around now.
Being a co-maintainer for a package might be something I can actually
pull off, assuming any instructions given are specific enough as I'm not
exactly good at communicating with people. I'm also into death metal,
deathcore, and deathgrind.
--
Travis Kendrick
6 years, 11 months
