There is a proposal in upstream GlusterFS to drop 32-bit arches.
The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will
land in Fedora 31/rawhide soon. More than likely though it will not be
official until GlusterFS-8, which will probably land, accordingly, after
Fedora 31 GA in Fedora 32/rawhide.
I just git a "broken dependencies" notice for a package that I maintain.
The reason is that "pdftk" got retired just the other day.
I may have missed a corresponding post on fedora-devel, but I think a
heads up notice to maintainers of depending packages may be in order
before you retire a package, as a general idea.
You see, unretiring a package is so much more work than changing
As for pdftk: I see 2 failed builds for version 1.45 and none for the
current version 2.02 (which probably breaks the api anyways). What are
the plans? Retire pdftk completely? Start fresh with pdftk2?
pdflabs, the maker of pdftk, provide binary as well as source rpms for
pdftk 2.02, by the way. I might even look into packaging it but don't
want to duplicate any existing efforts.
Recently I've reported some Big Endian related test failures to an
upstream project .
I was asked by an upstream project maintainer, whether I know some free
Continuous Integration services where they can easily run their
testsuite on Big Endian.
* Upstream uses Travis CI to test on x86_64 Linux (Ubuntu)
* Upstream uses AppVeyor to test on Microsoft Windows
* It's a pure Python project, noarch, but some changes need to be done
when loading/saving binary data (LE) with NumPy on BE system.
What I've considered:
* COPR (but there is no big endian arch)
* (Ab)using Koji (I guess that would be considered a bad practice?)
* using QUEMU on Travis CI 
Any better tips? Thanks
I just had to setup a new machine, and new ssh keys.
I chose my new id_rsa.pub to upload.
But I get:
git push --verbose
Pushing to ssh://firstname.lastname@example.org/mercurial
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
After review, Fedora has determined that the Server Side Public License
v1 (SSPL) is not a Free Software License.
It is the belief of Fedora that the SSPL is intentionally crafted to be
aggressively discriminatory towards a specific class of users.
Additionally, it seems clear that the intent of the license author is to
cause Fear, Uncertainty, and Doubt towards commercial users of software
under that license. To consider the SSPL to be "Free" or "Open Source"
causes that shadow to be cast across all other licenses in the FOSS
ecosystem, even though none of them carry that risk.
It is also worth nothing that while there is a draft for a "v2" of the SSPL:
A) It is not final.
B) It is not in use anywhere at this time (as far as we know).
C) The intent of the v2 draft text is not changed from the v1 license
currently in use.
We have updated our "Bad License" list to include SSPLv1. No software
under that license may be included in Fedora (including EPEL and COPRs).
On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
> > I'd like to get this package reviewed please:
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> > Would anyone like to swap reviews?
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
Time zone: Europe/London
Just a quick headsup for users following Fedora 29, the
dbus 1.12.10-1.fc29 build is missing the systemd dbus.service
file, breaking almost everything.
Instead it contains a dbus-daemon.service file, but the
dbus.socket file expects a matching dbus.service, not
So either hold of on applying updates until this is fixed
or exclude dbus.
I know how important RPM is to the Fedora Project, but it breaks
everything downstream and we'd be better off using DPKG as we should
have from day one.
I'm calling this initiative fedpkg: Fedora Embraces DPKG.
A bit of background here: I build both RPMs and DEBs for $DAYJOB and
until recently my workflow was quite painful because I needed extra steps
between git checkout and git push that involves a VM, because what we
ship as apt is in reality apt-rpm.
It finally got enough on my nerves to locally build the things I needed and
after a month I have already amortized my efforts with the time I save not
having to deal with needless extra hoops.
In order to successfully build debs on Fedora I needed 4 packages that
I'm now submitting for review:
I need more than reviews here.
Three of those packages are heavy on Perl code, and I'm not a Perl
Monk. I tried to CC perl-sig as per the guidelines  (also tried with
the mailing list address) but bugzilla replied kindly:
CC: perl-sig did not match anything
Apt is a mix of C, Perl and C++ code, so I would be reassured if I
could have a C++ co-maintainer too. I'm only a C developer so if
something goes wrong outside of the C realm that would be helpful.
Two of those packages should be runtime dependencies of debhelper.
The current apt package should be renamed to apt-rpm, I will look up
the procedure for that to happen. I understand that when someone sees
they should run "apt-get install foo" somewhere on the web it's
helpful for non-savvy users that this JustWorks(tm) , but apt-rpm is
dead upstream and it shouldn't be advertised as apt.
I hope I CC'd everyone that should get this heads up, and hope to find
help for the reviews and co-maintainership. The packaging does nothing
fancy, there are quirks here and there but overall it was rather easy
to put together. And of course I would be happy to help with reviews
too in exchange.
And thanks again to the mock developers, its design is so much better
than either sbuild or pdebuild that I barely have pain points left when it
comes to RPM packaging.
 I'm not against apt-rpm in the base install for example
writing to general devel list intentionally. No idea if all members of lxqt-sig list can read here, too and especially @zsun.
Is there any sense why @lxqt-sig is member of packaging for featherpad? LXQt SIG decided to have enki in the spin as the default editor. Featherpad is not part of LXQt upstream.
@lupinix Could you remove lxqt-sig from the members in pagure?