= 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.
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.
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.
As I am working on bringing pagure as a front-end to our dist-git, a question is
Currently ACLs are stored in pkgdb, it allows having a per-branch ACL model,
which in itself is quite cool, but I wonder: is it that useful?
I know pkgdb brings us other things too and I am explicitely ignoring them here
because I think we can find solutions for them, which may even have benefits
over our current processes.
So, does per-branch ACLs make sense to you? Have you had cases where you thought
it was good/bad? More importantly, have you had cases where you would want to give
someone access to just one branch and really really do *not* want them to have
access to the other branches?
Of course, EPEL vs Fedora comes to mind here, but I wonder: if the EPEL maintainer
has also commit on the Fedora branches, is it really that much of a big deal?
Before I investigate what it would take to drop pkgdb entirely and let pagure
handle the ACLs, I wanted to hear from you if you think this is a terrible idea
or worth investigating.
Thanks in advance for your feedbacks and ideas,
PS: for full disclosure: pagure does not support per branch ACLs at the moment
and in the current way we are syncing information from pkgdb to pagure, we are
only taking rawhide into account. So if you have commit on rawhide, you will
have commit access on pagure to all branches, if you do not have commit access
on rawhide, you won't have commit access on pagure.
Note that this concerns only commit access via the UI and the ability to merge
PR as gitolite underneath (used when doing git push via ssh) still per branch
PS2: I am also considering this question having in mind the change in branching
model the modularity work will bring (ie: branch no longer tied to a Fedora
version but rather to upstream's version)
There was an issue with GCC7 during the mass-rebuild. Despite the Fedora-wide
setting of -Werror=format-security, GCC did not process its command-line
properly and an unknown number of packages were built without this flag
appropriately set. As a result, all of those packages built successfully during
the mass-rebuild, where many should in fact have reported compilation errors and
As part of the modular builds that the Base Runtime is performing, we need to
rebuild all packages that are going into the base runtime (as well as the set of
packages required to self-host the base runtime). Because GCC has been updated
to properly handle the CLI arguments, somewhere between two and three dozen
packages now throw errors on building.
Because we are under time-constraints, Petr Šabata and myself will be using our
provenpackager privileges to apply patches to these packages without waiting for
maintainer correspondence. The patches will be very simple, as the fix for this
issue will be in most cases the equivalent of replacing printf(variable) with
In very rare cases where the fix is non-obvious, we may take the short-term
solution of setting -Wno-format-security for that package and open a Bugzilla
for the maintainer to fix it properly (or engage upstream to do the same).
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org