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
Option 1: Big batched update
1. Release F26 according to 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
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
5. And same for F26.1 final
6. And sometime in October/November, release that (but without big
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!
Fedora Project Leader
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
Note: to count the vulnerabilities, I just manually added up the CVEs
listed at , ignoring the oldest advisory WSA-2015-0001, and
discounting five of the older vulnerabilities in WSA-2015-0002.
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.
= Proposed Self Contained Change: IBus Emoji Typing =
* 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  following Ctrl-
== 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
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.
I thought I would toss this out in case anyone was looking for things to
Many fonts these days (the google ones at least) are shipping .glyphs
files as source.
The origin of this format seems to be a non free binary only macos app
However, there's two open source projects who have added or are working
on adding support:
https://github.com/trufont/trufont a python based font editor
https://github.com/metapolator/metapolator/ a nodejs based editor
Additionally, google has made available 'fontmake' which builds the
actual binary fonts from the .glyphs files:
https://github.com/googlei18n/fontmake - a python based font compiler.
This all came up for me when someone pointed out there was a newer
version of a font I maintain ( levien-inconsolata-fonts ) available, but
there's no longer a sfd file to build from, just a glyphs source. I
don't really have time to package up fontmake (and I think that would be
somewhat useless without an editor, so we would need one of the other
two also). In the mean time I will probibly just update with the
upstream ttf, but that makes me sad. :(
So, if anyone wants to take on packaging these up, that would be lovely.
I'd be happy to try and help as time permits doing reviews, co-
I am Bart Kessels and I'm a developer from the Netherlands.
Right now I'm still in college studying computer science and I'd
like to experience the open source development world. I've only
worked for closed source companies so I can't link to any of the
project I've worked on but I'd like to get more involved in the
open source community (so far I've been only using it).
I've spend most of that time working on Android apps (using Java) and
right now I'm learning Gtk with Python and a bit of C++.
I've just submitted my first project, GetIt, which is a HTTP request
application, like PostMan but opensource.
kde-sig members imported Qt 5.8 into git over the weekend (kudos to
heliocastro for initial packaging/copr and kkofler for merging import), and
bootstrap builds are under way. I'm hoping to have the whole stack done by
tomorrow (Tue Mar 28).
This is all after a fair amount of pre-testing in copr.
That said, if anything breaks or have any comments, please let me or kde-sig
know (here, bugzilla, whatever).
I wonder if it's just me or others also have problems with performance
of Pagure. Pagure is always slower for me than e.g. Github, but it's
bearable. However, there are times when I have to wait easily 30-60 sec
to load a page which makes Pagure almost impossible to work with.