devel December 2019

devel@lists.fedoraproject.org

196 participants
271 discussions

Server Side Public License (SSPL) v1
by Tom Callaway 21 Jan '21

21 Jan '21

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). Thanks, Tom Callaway Fedora Legal

4 6

Re: NeuroFedora review swaps
by Ankur Sinha 12 Jan '21

12 Jan '21

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: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_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. -- Thanks, Regards, Ankur Sinha https://ankursinha.in Time zone: Europe/London

6 27

Reproducible builds/bootstrap
by Pablo Greco 09 Oct '20

09 Oct '20

I'm starting to work on a project to make Fedora fully reproducible and bootstrappable from scratch. I know it is a long term plan and still working on the steps, but it would be good to know the current status, if there is an internal interest in this, if someone is already working (or planning to). Thanks for the info. Pablo

8 11

Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything
by Hans de Goede 04 Aug '20

04 Aug '20

Hi All, 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 dbus-daemon.service. So either hold of on applying updates until this is fixed or exclude dbus. Regards, Hans

17 28

Ditch RPM in favor of DPKG
by Dridi Boukelmoune 19 Jul '20

19 Jul '20

Greetings packagers, 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: https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism https://bugzilla.redhat.com/show_bug.cgi?id=sbuild https://bugzilla.redhat.com/show_bug.cgi?id=apt 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 [1] (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) [2], 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. Thanks, Dridi [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig [2] I'm not against apt-rpm in the base install for example

17 44

Default editor for LXQt spin
by Raphael Groner 25 Jun '20

25 Jun '20

Hi, 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? Regards, Raphael

3 2

Adding Obsoletes to generated -debuginfo packages ?
by Daniel P. Berrangé 04 Jun '20

04 Jun '20

In libvirt we recently deleted a driver for the legacy Xen toolstack. This was shipped in a libvirt-daemon-driver-xen RPM. I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0" line to the libvirt-daemon-driver-libxl RPM, which gives clean upgrade path for users. If they have the libvirt-daemon-driver-xen-debuginfo RPM installed though that still breaks the upgrade. How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0" statement ? It seems impossible, meaning users with debuginfo have a broken upgrade path. An unfortunate consequence of switching to seprate -debuginfo per sub-RPM. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

7 12

New set of questions for FESCo candidates?
by Zbigniew Jędrzejewski-Szmek 14 May '20

14 May '20

Dear all, the semiannual exercise is upon us. FESCo candidates must submit an "interview" in which they answer a set of questions (but can also add whatever they want). The question whether we should have a new set of questions needs to be answered. Currently we have the following: Mandatory Question #1: Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues? Mandatory Question #2: What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development? Mandatory Question #3: What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those "trouble spots"? Please answer with any proposals. If there is sufficient support for change, I'll gather a list and submit this for some kind of poll (details to be figured out...). Zbyszek

13 24

python-pep8 is orphaned
by iliana weller 03 May '20

03 May '20

Hello, I've orphaned python-pep8. pep8 was renamed to pycodestyle in 2016; it received its last release in 2017. It should be removed from Fedora in a future release. I unfortunately don't have time to proceed with the full retirement process myself. If somebody would like to pick it up: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#C… $ dnf repoquery --whatrequires python2-pep8 python2-autopep8-0:1.2.4-9.fc29.noarch python2-pytest-pep8-0:1.0.6-15.fc29.noarch python2-spyder-0:3.3.1-3.fc29.noarch $ dnf repoquery --whatrequires python3-pep8 python3-autopep8-0:1.2.4-9.fc29.noarch python3-hacking-0:1.1.0-3.fc29.noarch python3-pytest-pep8-0:1.0.6-15.fc29.noarch python3-spyder-0:3.3.1-3.fc29.noarch See also https://bugzilla.redhat.com/show_bug.cgi?id=1667200's dependent bugs. (Please CC me on replies that need my attention.) -- iliana weller <ilianaw(a)buttslol.net>

7 9

orphaning bleachbit
by Mukundan Ragavan 02 May '20

02 May '20

I intend to orphan bleachbit soon. If anyone is interested please let me know and I will transfer the package. https://src.fedoraproject.org/rpms/bleachbit Mukundan.

15 30

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel December 2019