I am trying to package the following from github for fedora. (Actually, I have been using my own RPM for years so it is hopefully not a major task).
https://github.com/maitra/thaali
Anyway, I wanted to ask how I should put the Source code from there
The source is at:
https://github.com/maitra/thaali/archive/master.zip
but that does not give me the version, etc number to build from the spec file.
So, what should I do?
Thanks again!

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.

= Proposed System Wide Change: Rsyslog log format change proposal =
https://fedoraproject.org/wiki/Changes/RsyslogLogFormat
Change owner(s):
* Radovan Sroka <rsroka AT redhat DOT com>
* Roman Pavelka <rpavelka AT redhat DOT com>
Currently Fedora uses RSYSLOG_TraditionalFileFormat as a default
format for timestamps in its logs. There is missing year and timezone.
This proposal aims to change this by adopting ISO 8601 and RFC 3339
compliant timestamp format known as RSYSLOG_FileFormat instead of
current RSYSLOG_TraditionalFileFormat.
== Detailed Description ==
Currently Fedora, RHEL and CentOS use RSYSLOG_TraditionalFileFormat
for log’s timestamp, so timestamps in files like /var/log/messages,
/var/log/cron and /var/log/secure looks like e.g.:
May 29 13:37:50 localhost systemd: Starting Fingerprint Authentication Daemon...
This format has few disadvantages
* Does not include year which sometimes may be needed, mostly when
doing long term analysis or some investigation.
* Does not include timezone which may be important piece when working
with system scattered around the globe.
* It is not standard format. Standards are ISO 8601 and more strict RFC 3339
We would propose to change this to defaults to standard format with
timezone included. We are suggesting new RSYSLOG_FileFormat that looks
like e.g.:
2017-05-29T13:40:50.976409+02:00 localhost systemd: Stopping System
Logging Service...
== Scope ==
* Proposal owners:
- commit necessary changes
- create rsyslog build
* Other developers:
none
* Release engineering:
Releng#6818 https://pagure.io/releng/issue/6818
* List of deliverables:
Not affected
* Policies and guidelines:
Not affected
* Trademark approval:
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

Hi,
I think we need to retire git-annex from Fedora (the current version is
very old and has security issues), since to build current versions needs
adding a lot of new Haskell dependencies to Fedora.
Currently noone has expressed interested in doing this... I plan to make a
copr repo later at some point. So unless someone wants to help do a lot of
package reviews, I think it is better just to retire git-annex from Fedora
for now.
I will do that next week unless someone volunteers to do all the work to
update.
I am writing on behalf of Ben who is on away and the Haskell SIG.
Thanks, Jens

= Proposed Self Contained Change: Making sudo pip Safe (Again) =
https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
Change owner(s):
* Michal Cyprian <mcyprian AT redhat DOT com>
* Petr Viktorin <pviktori AT redhat DOT com>
* Tomas Orsava <torsava AT redhat DOT com>
* Miro Hroncok <mhroncok AT redhat DOT com>
At the present time, running sudo pip3 in Fedora is not safe. Pip
shares its installation directory with dnf, can remove dnf-managed
files and generally break the Python 3 interpreter. We propose a
series of measures that will make it safe to use.
== Detailed Description ==
The danger of using sudo pip3 stems from the fact that both Python dnf
packages and sudo pip3 install modules to the same location, namely
/usr/lib/pythonX.Y/site-packages.
We aim to move the working directory for sudo pip3 to a more
appropriate location: /usr/local/lib/pythonX.Y/site-packages, and
modify the Python 3 interpreter in Fedora to scan both above mentioned
locations when importing modules. In addition, system-python—a
stripped down version of Python 3 for use by system tools—will not
read the sudo pip3 install location, making it more secure by being
less susceptible to interference by user-downloaded modules.
From the technical standpoint, this will be accomplished by changing
the install prefix setting of the distutils install command in the
/usr/bin/python3 executable from /usr/ to /usr/local. pip3 and
distutils will thereafter use this prefix when determining where to
install modules. In addition, the paths
/usr/local/lib/pythonX.Y/site-packages and
/usr/local/lib64/pythonX.Y/site-packages will be added to the front of
the sys.path variable so that modules are imported preferentially from
there. These settings, however, will not be modified for the
system-python binary, the /usr/bin/python3 executable when running
with -I option specified, nor when an RPM build is detected.
Therefore, Python RPM packages will continue to be built with the
correct installation path for system modules.
The purpose of this change is not to make sudo pip a standard way to
install Python packages. Virtual environments and pip3 install --user
should still be the prefered options. Nevertheless, sudo pip is far
too prevalent an instruction in various guides and installation notes
throughout the Internet that there is little hope of changing users'
behaviour in this regard.
== Scope ==
* Proposal owners:
Modify the distutils install command as described above.
Modify the site.py script to add additional paths to sys.path when it is needed.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
https://pagure.io/releng/issue/6820
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
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

Hello!
I had an idea for a summer internship project, but I wanted to ask my
fellow Fedora devs if something like this already exists so it doesn't
get created as a duplicate project.
The idea is to create a dnf plugin that would allow you to do this:
$ sudo dnf upgrade FEDORA-2017-30604deb62
That update is a Gnome update, and likely has packages in it that you
don't use, but others that you do. The plugin would compare the
packages in the update against your installed set of packages to form
and execute the true dnf update command that should be run without
installing new packages (unless they are required). It would also
enable updates-testing of course. It could even be written to pull the
rpms from Koji if the update hasn't hit testing yet.
I've found that it is a little painful for me to test multi-package
updates when I don't use all the RPMs and I don't keep updates-testing
enabled on my system, so that's my motivation behind the idea. Does
anything like this already exist? If not, does it sound like a useful
tool to others?
It could also support the install command, in which case it would just
install all the RPMs from the update.

Hello.
Due to many CVEs and low quality/security of these packages as well as Windows oriented upstream I'm going to orphan both jbig2dec and mupdf packages in Fedora/EPEL.
Sometimes the build doesn't reach stable branch just because it's deprecated by new build with new CVE.
Feel free to take them.
--
Pavel

Hello all,
I have a fairly large package that needs review:
https://bugzilla.redhat.com/show_bug.cgi?id=1415612
and I've been offered a few review swaps for it, but the trouble is, I
don't really feel well qualified to review packages yet. I only
maintain one other package (a pre-requisite for that one above) and it's
super simple.
Should I just jump in anyway? How is this kind of thing usually resolved?
Thanks,
David
david.muse(a)firstworks.com