devel August 2020

devel@lists.fedoraproject.org

217 participants
358 discussions

Searching a new home for my packages
by Thomas Spura 03 Sep '20

03 Sep '20

Hi all, unfortunately, I don't find much time anymore to look for my packages .. Due to that, I would like to step down as the primary maintainer and am searching for a new home for my packages! On most of them, I am co-maintainer and the following are the ones, where I am maintainer (and hope I didn't forget one, if so, please let me know): - python-jupyter-client - python-jupyter-core - python-matplotlib - python-tornado - ipython - mpi4py - php-zmq - pynac Feel free to let me know, if you are interested in taking any of those packages. Best, Thomas -- Fedora: https://fedoraproject.org/wiki/User:Tomspur

8 15

Fwd: Re: CppunitTest_sw_htmlexport failing due to zlib variation?
by Stephan Bergmann 03 Sep '20

03 Sep '20

All, The below question came up in the context of a LibreOffice unit test, where LibreOffice writes out a PNG image (involving zlib for compression) and the test checked the exact sequence of bytes, which failed on aarch64 when using Fedora's zlib. (Though the resulting images look rather identical. Full thread starting at <https://lists.freedesktop.org/archives/libreoffice/2020-August/085792.html> "CppunitTest_sw_htmlexport failing due to zlib variation?") Given the Fedora zlib aarch64 optimization patches quoted below: Does anybody know whether it is indeed the case that the above scenario (client code using zlib to generate a PNG image) can legitimately generate varying output depending on zlib implementation details? Or would that rather indicate a bug somewhere? Thanks, Stephan -------- Forwarded Message -------- Subject: Re: CppunitTest_sw_htmlexport failing due to zlib variation? Date: Wed, 26 Aug 2020 08:37:15 +0200 From: Stephan Bergmann <sbergman(a)redhat.com> To: libreoffice(a)lists.freedesktop.org On 25/08/2020 11:07, Stephan Bergmann wrote: > At least when building recent master on recent Fedora rawhide aarch64 > with (among others) --with-system-zlib, CppunitTest_sw_htmlexport fails > with [...] > The base64-encoded payload apparently is a PNG image. And from what > little I know about PNG, it looks plausible to me that there can be > different (compressed) PNG content that decompress to identical raw > data, and that the LibreOffice code would be allowed to generate > differing (compressed) PNG content for the above data:image/png URL > payload. What supports the theory that "the LibreOffice code would be allowed to generate differing (compressed) PNG content" is the Fedora zlib commit <https://src.fedoraproject.org/rpms/zlib/c/25e9802713484882c27c1f979a6610a42…> "aarch64 optimizations", adding lots of code that presumably is only relevant for aarch64 and presumably changes details of the compression algorithm.

4 4

services impact on startup times
by Chris Murphy 03 Sep '20

03 Sep '20

Hi, These are based on Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso in a VM. The numbers are different on bare metal but correlate. The only standout is rngd.service. That's a pretty big single hit, percentage wise. And I don't know if we even need it anymore. Among the rest, perhaps atd.service and crond.service could be disabled by default on new installations, in favor of systemd timers. Startup finished in 1.320s (kernel) + 1.344s (initrd) + 7.727s (userspace) = 10.392s disable atd.service Startup finished in 1.308s (kernel) + 1.310s (initrd) + 7.557s (userspace) = 10.176s disable dbxtool.service Startup finished in 1.302s (kernel) + 1.291s (initrd) + 7.527s (userspace) = 10.120s disable import-state.service Startup finished in 1.308s (kernel) + 1.326s (initrd) + 7.410s (userspace) = 10.044s disable iscsi.service Startup finished in 1.316s (kernel) + 1.303s (initrd) + 7.177s (userspace) = 9.797s disable libvirtd.service Startup finished in 1.316s (kernel) + 1.266s (initrd) + 6.779s (userspace) = 9.361s disable lvm2-monitor.service Startup finished in 1.315s (kernel) + 1.323s (initrd) + 6.750s (userspace) = 9.389s disable mdmonitor.service Startup finished in 1.316s (kernel) + 1.350s (initrd) + 6.675s (userspace) = 9.342s disable ModemManager.service Startup finished in 1.270s (kernel) + 1.305s (initrd) + 7.052s (userspace) = 9.629s disable nfs-convert.service Startup finished in 1.312s (kernel) + 1.343s (initrd) + 6.958s (userspace) = 9.614s disable rngd.service Startup finished in 1.308s (kernel) + 1.277s (initrd) + 5.247s (userspace) = 7.833s disable switcheroo-control.service Startup finished in 1.308s (kernel) + 1.334s (initrd) + 5.223s (userspace) = 7.867s disable vboxservice.service Startup finished in 1.301s (kernel) + 1.302s (initrd) + 5.176s (userspace) = 7.780s disable crond.service Startup finished in 1.310s (kernel) + 1.278s (initrd) + 5.076s (userspace) = 7.665s preset-all Startup finished in 1.316s (kernel) + 1.312s (initrd) + 7.869s (userspace) = 10.498s ##stopwatch 11.35 disable atd.service crond.service iscsi.service rngd.service vboxservice.service Startup finished in 1.305s (kernel) + 1.294s (initrd) + 5.505s (userspace) = 8.105s ##stopwatch 8.89 All of these times are based on 'systemd-analyze'. The stopwatch method is less precise but still demonstrates the difference is real. It may not be a big enough deal to do anything about it this cycle, but could be something to look at for the next. Maybe more opportunities are available. -- Chris Murphy

9 13

Switching package to fragmented default configuration
by Miroslav Lichvar 02 Sep '20

02 Sep '20

I'm considering to split the default configuration file in the chrony package to make it easier for vendors, products, and configuration tools to override some specific settings (like the default NTP servers) by dropping a file into a directory, instead of having to modify a packaged config file. It seems to be a modern trend, used by many packages in Fedora, and I have received some RFEs to adopt in chrony. The default /etc/chrony.conf would just have a single directive loading configuration fragments from /etc/chrony.d and /var/lib/chrony.d (and maybe also /var/run/chrony.d). My concern is that it will basically break all existing tools that need to check and/or modify the configuration (e.g. anaconda). They will need to know the naming of the files which have specific settings in order to override them, or implement a parser duplicating the chronyd logic to figure out which files are loaded from where. Also, I'm not sure how user-friendly this is for regular users who modify the configuration manually. Are there any recommendations for switching an existing single-config package to a fully fragmented configuration? Is it worth the trouble, or do you have any other suggestions? Thanks, -- Miroslav Lichvar

9 16

Fedora Jam 33 Beta - Possible Blocker?
by Erich Eickmeyer 02 Sep '20

02 Sep '20

HI all, Since the release of Koji 1.22, there has been a bug [1] blocking any Fedora Jam 33 or Rawhide iso images from being spun. As you can imagine, this is making me quite nervous. As it turns out, I'm waiting for Koji 1.22 to be released so that images can start building again. If this isn't done in time for beta, then that means Fedora Jam will be unable to participate in beta testing. The issue in question is caused because Jam adds "threadirqs" as a boot argument in addition to the normal boot arguments. This is a way to add some low-latency characteristics to a kernel that isn't otherwise a lowlatency kernel and is known to cut-down on xruns in audio production. However, one question came up as to if threadirqs is a default in the kernel configuration, but nobody could answer that. I was wondering if anyone on this list knew? I'm also going to be a little more intentional with working with the pipewire developers on figuring out jack compatibility issues during the F34 release cycle. Thanks, Erich [1] https://pagure.io/koji/issue/2437 -- Erich Eickmeyer Maintainer Fedora Jam

6 10

Fedora official kernel build fails to compile on Copr
by Germano Massullo 02 Sep '20

02 Sep '20

Hi there, I would need help in understanding why this kernel build failed. https://copr.fedorainfracloud.org/coprs/germano/kernel_204253_comment_14_pa… The SRPM is the same of Fedora repository except for a small patch file that I have added to run some tests against blk-mq scheduler https://bugzilla.kernel.org/show_bug.cgi?id=204253#c14 The only errors I can see are like "Macro expanded in comment", but as I said, these expanded macros were already present in official Fedora build, so I don't understand why the build fails on my Copr repository. Thank you

4 6

python-versioneer: no version information in github archives?
by Ankur Sinha 01 Sep '20

01 Sep '20

Hiya, Is anyone working with python packages that use versioneer[1]? My primary issue here is that upstream does not include tests in the pypi tars, but because they use versioneer and it does all sorts of "magic": - it is non trivial to figure out what untagged commit on Github matches the latest pypi tar release - even if one does manage to locate the commit, if we use the GitHub archives, versioneer cannot get the version information from them: https://github.com/warner/python-versioneer/issues/140#issuecomment-2927464… Does any one have any ideas here? I've requested upstream to include tests in the pypi tars[2], but a way of forcing versioneer to provide the correct version would be really nice. [1] https://github.com/warner/python-versioneer [2] https://github.com/BlueBrain/eFEL/issues/181 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London

2 2

[golang packaging] how to get files from source tarball
by Zdenek Dohnal 01 Sep '20

01 Sep '20

Hi, I'm trying to package ipp-usb project (https://github.com/OpenPrinting/ipp-usb) which is written in Go. I generated spec file via go2rpm, but several files from source tarball which supposed to be packaged is not packaged e.g. systemd unit file ipp-usb.service or udev rule file 71-ipp-usb.rules. I managed to package those files with following install command e.g.: install -m 0644 -vp %{gobuilddir}/src/github.com/OpenPrinting/ipp-usb/systemd-udev/*.rules %{buildroot}%{_udevrulesdir} but '%{gobuilddir}/src/github.com/OpenPrinting/ipp-usb' is quite ugly - is there a predefined golang macro for such path? Or a best practice? Thank you in advance, Zdenek -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C

3 2

fedora-review fails with "warning: line 16: Possible unexpanded macro in: Requires .."
by Martin Gansser 01 Sep '20

01 Sep '20

Hi, when I want to do a review with: fedora-review -m fedora-rawhide-x86_64 -b 1873407 i get this error message: warning: line 16: Possible unexpanded macro in: Requires: vdr(abi)(x86-64) = %{vdr_apiversion} Building target platforms: x86_64 Building for target x86_64 setting SOURCE_DATE_EPOCH=1598313600 Wrote: /builddir/build/SRPMS/vdr-skinelchihd-0.5.0-1.fc34.src.rpm Child return code was: 0 Mock Version: 2.4 .. that's all I get in the build.log How can i solve this ? Regards Martin

5 7

Can a bugzilla issue be locked because of spam?
by Christopher 31 Aug '20

31 Aug '20

This old issue (https://bugzilla.redhat.com/show_bug.cgi?id=1177202) keeps receiving spam every couple of weeks from a different account. I've been trying to flag the spam comments as spam, and remove the flags they keep setting, and remove their CC as well, so they don't get follow-ups and get encouraged to continue spamming. However, they keep doing it. It's really quite annoying. Is there any way it can be locked or restricted to committers?

5 6

← Newer
1
2
3
4
5
6
7
...
36
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 August 2020