devel May 2020

devel@lists.fedoraproject.org

246 participants
393 discussions

Fedora-Cloud-32-20200520.0 compose check report
by Fedora compose checker 20 May '20

20 May '20

No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 601107 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/601107 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Fedora-Cloud-31-20200520.0 compose check report
by Fedora compose checker 20 May '20

20 May '20

No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Fedora 31->32 dnf system-update experience
by Richard Shaw 20 May '20

20 May '20

Not that it's a huge deal for me but I wouldn't call the upgrade smooth. There were a bunch of python2 packages that needed to be removed which necessitated --allowerasing which I've never had to do before. Now this, which I'm guessing is a packaging issue which a user shouldn't have to deal with: Error: Transaction test error: file /usr/lib/firmware/intel/sof-tplg from install of alsa-sof-firmware-1.4.2-5.fc32.noarch conflicts with file from package alsa-firmware-1.2.1-4.fc31.noarch Thanks, Richard

10 18

Getting deprecation warning about hawkey.Repo class
by Aleksandra Fedorova 20 May '20

20 May '20

Hi, all, I am looking for some background and info on this deprecation warning: /usr/lib64/python3.8/site-packages/hawkey/__init__.py:348: DeprecationWarning: The class hawkey.Repo is deprecated. Please use dnf.repo.Repo instead. The class will be removed on 2019-12-31. I have found this mail [1] from 18 March 2019. It says in Fedora 32 hawkey subpackages will be removed from libdnf. But we have rpmdeplint running on Fedora 32, which gets this message, see [2]. Koschei service also seems to have the same issue [3] What is the latest status of this? Has the deprecation happened? Is it still planned? Are there any tips for tool maintainers, how to deal with it? [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… [2] https://bugzilla.redhat.com/show_bug.cgi?id=1832171 [3] https://github.com/fedora-infra/koschei/issues/292 -- Aleksandra Fedorova bookwar

1 0

Fedora-Cloud-30-20200520.0 compose check report
by Fedora compose checker 20 May '20

20 May '20

No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Modularity survey - results
by Daniel Mach 20 May '20

20 May '20

Hello everyone, We have finally evaluated all of your responses to the Modularity survey. You can find the results posted on the Fedora community blog[1]. Thanks to all of you who filled the survey and provided detailed explanation of what works and what not. [1] https://communityblog.fedoraproject.org/modularity-survey-results/

5 6

i3wm for EPEL8
by Eric Mesa 20 May '20

20 May '20

Hey there, I noticed that the i3 window manager wasn't available in EPEL8. Before trying to go through the process of becoming a package maintainer I decided to try and run it via copr to see how much modification was needed. For EPEL8 (as opposed to 7) I was able to take the current spec file and, after creating an EPEL8 copr repo for xcb-util-xrm ( https://copr.fedorainfracloud.org/coprs/djotaku/xcb-util-xrm/), it would build. But it wouldn't install for it needed some perl packages. So I set about building those. You can see how far I got in ( https://copr.fedorainfracloud.org/coprs/djotaku/i3wm/packages/), but each one had one or more dependencies. So I was rapidly along a path towards having to recreate nearly all of Perl for EPEL8. (Only a slight exaggeration). Unfortunately, for those, I couldn't just bum the spec file because they each had a patch that needed to be applied. So I had to download the repo from pagure, use spectool and mock to create the srpm and then load that into copr. Quite tedious. However, the good news is that I never had to make any mods to the spec files to get them to work for EPEL8. Everything just worked. So...what is the proper path to get the perl folks to create epel8 branches in their repos (again, there isn't any additional work needed - at least at this point in time)? In the long run, I'd definitely like to be a co-maintainer for i3 for epel8. Thanks, -- Eric Mesa <http://about.me/ericmesa>http://www.ericmesa.com

5 4

No more automagic Python bytecompilation - phase 3
by Lumir Balhar 19 May '20

19 May '20

Hello. We plan to continue on our plan to disable automagic Python bytecompilation so I'd like to summarize what you can expect. If you don't know what I am talking about, please read this change [0] and its second phase [1]. Currently, we have 130 packages with `%global _python_bytecompile_extra 1` in their specfiles [2] but suprisingly only 42 of them (listed below) actually ship any .pyc files outside the standard location "/usr/lib(64)?/python[0-9]\.[0-9]+". That might be caused by either of the following: A) there is nothing to byte-compile -- the statement is a leftover to be removed B) The automagic bytecompilation uses /usr/bin/python by default (for historical reasons) but /usr/bin/python is not present in the buildroot by default. Those 42 packages should switch to explicit `%py_byte_compile` [3], for example: /%py_byte_compile %{python3} %{buildroot}%{_datadir}/mypackage/bar/ Remember that this has something to do only for importable Python modules and only outside the standard location. I'll prepare a Fedora change proposal for this but I wanted to inform maintainers in advance. The new RPM macros will raise an error if _python_bytecompile_extra will be defined to 1. Package maintainers should switch to %py_byte_compile or just remove it from the specfile if it's not needed. I'll definitely help with this transition as much as I can. Have a nice day. Lumír [0] https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompila… [1] https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompila… [2] https://bugzilla.redhat.com/show_bug.cgi?id=1721147#c10 [3] https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#… Packages using extra byte compilation: cinnamon-screensaver edk2 eog-plugins fish gaupol gdb gedit gedit-latex gedit-plugins glusterfs gnome-code-assistance gtk-doc ibus ibus-anthy ibus-hangul ibus-libpinyin ibus-libzhuyin ibus-pinyin ibus-table ibus-typing-booster ibus-uniemoji kajongg kdevelop-python libsmbios libunity lirc lyx mingw-glib2 pcs pygobject2 pygtk2 rhythmbox sigul soundconverter sugar system-config-repo system-switch-mail texlive totem transmageddon ufw-kde virt-manager

1 0

F33 system wide change, java-11-openjdk as system jdk
by Jiri Vanek 19 May '20

19 May '20

Hello fellow java package maintainers! We are planning to bump the JDK from java-1.8.0-openjdk to java-11-openjdk for F33. Please see https://fedoraproject.org/wiki/Changes/Java11 Short Story: * if you have some java package, be aware that we are bumping JDK in rawhide * Ensure your package builds and runs fine with JDK11 (see the https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/) * there is special tooling ready for this, before mass rebuild is launched ** See https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild * If you do not want Fedora rotten with JDK8 for ever, continue reading Long Story: We ran a preliminary mass rebuild of javastack in copr repo https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ (select "all" instead of "25" at the bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy & comp for build. You can see, the result was quite dramatic: 1225 total; attempted to rebuild 483 failed; from those 191 are trivial failures (but if you fix it, there is no guarantee real troubles are not hidden behind that) 186 succeeded 556 orphans or dead or otherwise tragic so the build did not even start I would kindly ask you to search yourself in this list: https://jvanek.fedorapeople.org/java11/people If you are here, please check status of your package in https://jvanek.fedorapeople.org/java11/init (pain text of https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds). * If your package is "succeeded", congratulations nothing to do, and just keep en eye on JDK bump * If there is "failed" but contains "- -" then it is probably orphan. If you wish to resurrect it, please ensure it runs against JDK11 (see lower) * If there is "failed" but failed in "seconds", then those packages failed so quickly, that the build was in initial phases. That usually mean that you build with source/target lower then 1.6 JDK11 supports 1.6 and up. We recommend to bump the source/target to 1.8, to allow existence of compact 1.8 packages alongside main javastack. See https://fedoraproject.org/wiki/Changes/Java11#Wrong_source.2Ftarget_version. Don't forget to upstream the patch, or maybe it is enough to update to more fresh upstream release which supports JDK11? it may happen, that after the fix, your build will fail in more terrible way (see below) * If there is "failed", and its none of above, then your package simply failed. Very often the scary error may be fixed by bump to latest upstream version. JDK 11 is out for several years. Please, try to fix the package. Don't hesitate to ask on devel(a)fedoraproject.org or java-devel(a)fedoraproject.org or directly to me jvanek(a)redhat.com. If you fix the fail, feel free to share your fix, it may help others. We are trying to gather the most common issues at https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_f… . Feel free to enhance the page, or write us your case (possibly both with solution and without) so we can add it here. Debugging Your failures. The copr repo we maintain, contains builds of java-11-openjdk as system JDK, javapackages-tools honoring that, and java-1.8.0-openjdk as non system JDK. Also it contains successfully rebuilt packages. You can directly use this copr repo in several ways. * first glance on error. On https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ find your build (select "all" instead of "25" at the bottom), ** Click its number, select chroot (currently fedora-32-x86_64 ) and check the logs. Main log is build.log.gz. * anything you push to rawhide, will automatically rebuild here in f32 chroot (we have a JDK in rawhide broken a bit currently) ** It is the best approach. If you can fix your package in rawhide directly, without breaking the rawhide too much, go for it ** If yo need to experiment, I have a mock config for you (generated from copr-cli mock-config jvanek/java11 fedora-32-x86_64) which you can copy to your /etc/mock and use - https://jvanek.fedorapeople.org/java11/jvanek-java11-fedora-32-x86_64.cfg . Eg: sudo cp downloaded-fedora-32-x86_64.cfg /etc/mock/jvanek-java11-fedora-32-x86_64.cfg # change spec, bump sources, apply patches fedpkg srpm mock -r jvanek-java11-fedora-32-x86_64 *.src.rpm Or any other packaging workflow you use, and you can use against the copr repo. Thank you very much for your help, there are 500 failures, and 1000 java packagers, but only 2 active members of java sig. Without your help, the JDK bump will be very hard. Thank You! On behalf of Fedora java group J. _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…

5 10

FAS group as default assignee for Bugzilla?
by Felix Schwarz 19 May '20

19 May '20

Hi, it seems it is possible to use a -sig group as default bugzilla assignee but I don't know how to do it. If I go to pagure (src.fedoraproject.org) I can edit the bugzilla assignee but using "@certbot-sig" (or "certbot-sig") does not work (error message "Unable to update the bugzilla assignee(s)"). I guess getting that to work requires manual work from some infra folks? Background: I'm maintaining the "certbot" stack in Fedora/EPEL. There are ~20 different packages in the stack. In order to ease granting permissions for new packagers we have "@certbot-sig" group which has commit privileges for most of these packages. However new bugzilla tickets are assigned to the main package admins by default. These "main admins" is a group of maybe 5 people and none of them is really active in Fedora at the moment. I'd like to be aware of new bugzilla issues so I can help users more effectively. Therefore I'd like to set the sig as default bugzilla assignee. Felix

3 5

← Newer
1
...
15
16
17
18
19
20
21
...
40
Older →

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 May 2020