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.
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)