Re: Review swap / python
> Hey, I'll review web-eid in coming week. > Could you take a look at python-ownet review? > https://bugzilla.redhat.com/show_bug.cgi?id=2256125 Sure! Thank you very much -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review swap / python
Ops I did not notice that python-pyxlsb2 review was already taken care by another person -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review swap / python
> Bug 2246454 - Review Request: python-pyxlsb2 - Excel 2007+ Binary Workbook > (xlsb) parser > https://bugzilla.redhat.com/show_bug.cgi?id=2246454 I will take this one. Can you please review this package? web-eid - Web eID browser extension helper application https://bugzilla.redhat.com/show_bug.cgi?id=2298838 Thank you -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Java related] packaging Italian ID card middleware
I submitted the message at https://github.com/italia/cie-middleware-linux/issues/80 I suggest we can continue the discussion there. Thank you everybody for your support -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Java related] packaging Italian ID card middleware
Marián Konček wrote: [...]Note that my commits are dirty and I am not proposing them as changes, they show that it is possible to adopt Maven. So according to this, what would you recommend me to change in the point n.1 of my draft letter https://germano.fedorapeople.org/canc/cie_middleware.md = 1. please switch to CMake build system completely: some parts of the software need to be built through Eclipse, I.E. cie-pkcs11. CMake should be the only build system in the project. CMake will also enable CIE Middleware being built for all Linux distributions, Mac OS, Windows; = ?-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Java related] packaging Italian ID card middleware
It worths also mentioning that both the Windows and Mac OS versions do not contain any Java source. Moreover, the Windows version contains some C# sources https://github.com/italia/cie-middleware and the Mac OS version contains some Objective C sources https://github.com/italia/cie-middleware-macos They should have just used Qt libraries like the Estonian ID card software stack https://github.com/open-eid -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Java related] packaging Italian ID card middleware
Hello, I discussed the feasibility of packaging https://github.com/italia/cie-middleware-linux in Fedora devel Matrix channel with Cristian Le and xvitaly. With the help of Cristian Le I wrote the following [1] draft that will be used to open an upstream ticket to request various improvements to make it possible to include the software in the Fedora repository. We ended up needing the comment from Java package maintainers, if they see any other no-go. I am in particular concerned about https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_pre_built_dependencies Thank you [1]: https://germano.fedorapeople.org/canc/cie_middleware.md -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Oliver Steffen
Hi Oliver! Welcome! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: on dnf autoremove aggressive behaviour
I am resuming this discussion because today I was about to run such command on another machine and in the preview of packages that would have been removed there were important packages like: - firefox - ffmpeg - libreoffice suite and many others. It's a pretty destructive behaviour for such command Full dnf output https://germano.fedorapeople.org/bugreport/autoremove.txt -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
feedback about adding obsoletes/provides
A long time ago upstream keepassxc obsoleted upstream keepassx. I now added obsoletes/provides [1] to the former spec file, following Fedora packaging guidelines [2] and I would like to ask for your feedback about the correctness of the commit. Thank you [1]: https://src.fedoraproject.org/rpms/keepassxc/c/6cf8701145d737e893722f2bbe58128d9e79002d?branch=rawhide [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
Il 30/03/24 23:12, Sandro ha scritto: From what I understood, F40 Beta, the official Beta release, available from the website as of March 26, has updates-testing disabled by default. That was confirmed by several people in #devel yesterday when the Fedora Magazine article was still being worked on. I updated ~3 days ago from F39 to F40 and I got *-testing repositories enabled -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
regarding sabotaged Landlock sandbox https://mastodon.social/@dander...@hachyderm.io/112185746170709381 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
It would be interesting to study how SELinux would have reacted to such kind of attack against sshd -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
on dnf autoremove aggressive behaviour
I recently updated to F40 KDE, but Jami software [1] bundled Qt6 RPM package messed up with system Qt6 (see later fix at [2]), so I had to run: # dnf autoremove # dnf reinstall $(rpm -qa) I have noticed an aggressive packaging removal behaviour from "dnf autoremove", indeed it removed various essential packages, some of them even installed by default during Fedora installation (complete list at [3]) For example: - gdisk - openssl - lz4 - java-21-openjdk dnf man page, says: dnf [options] autoremove Removes all "leaf" packages from the system that were originally installed as dependencies of user-installed packages, but which are no longer required by any such package. Packages listed in installonlypkgs are never automatically removed by this command. I wonder: 1) where installonlypkgs is defined, I could not find it in /etc/dnf 2) why it removed also packages that are shipped by default during a Fedora installation, like gdisk and openssl [1]: https://en.wikipedia.org/wiki/Jami_(software) [2]: https://review.jami.net/c/jami-project/+/27951/2/packaging/rules/rpm/jami-libqt.spec [3]: https://paste.centos.org/view/ec0ae480 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Announcement: Retiring zlib and minizip-compat from Rawhide
I hope this is the last time I have to deal with minizip invasive changes (both upstream and downstream). With the new keepassxc release, I had to test it against all minizip* packages on all active branches https://src.fedoraproject.org/rpms/keepassxc/c/3ec631d9175e82d9d8320374037e3d78bf7e190d?branch=rawhide -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
What does it mean that FESCo is applying an injunction? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What is Fedora?
22/06/23 11:06, Matthew Miller wrote: On Thu, Jun 22, 2023 at 08:44:13AM -, Michael J Gruber wrote: In the specific case of RHEL srpms, it makes life harder for EPEL packagers because you can't look at the source easily when they are problems between RHEL and EPEL packages. It matches well with RH's standard of shipping libraries without headers etc - it is easier for them and limits the scope of support contracts but makes upstream's life harder. EPEL packagers should have easy access to RHEL through the no-cost subscription program. Why should we keep contributing to EPEL? To be forced to use 16 free RHEL instances maximum? What is the advantage for us volunteer contributors? I mean, we did not do it for personal advantage, we did it to help us each other within the Enterprise Linux distros community, but this Red Hat move will kill the Enterprise Linux distros community, leaving only with RHEL, which is mostly a paid subscription distribution, let's call things with their proper name ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
adding GCC Toolset usage docs
Hello, in my opinion we should add to Fedora Packaging Guidelines, a paragraph concerning GCC Toolset usage. I recently experienced some problems in building darktable for epel8/epel8-next due bad configuration of gcc-toolset-11 in the spec file. In a few words, gcc-toolset-11 was not really enabled, so the builder was still using GCC 8.5. The build failure led me to open a bugreport against gcc-toolset-11 [1], but it turned out to not be a bug Dan Horák fixed the problem with pull requests [3] and [4] This problem was caused because I had misinterpreted official Red Hat configuration [2]. Also other developers in #fedora-devel IRC channel that I contacted for help, have misinterpreted it too. Adding such new paragraph in the guidelines would help the packaging activity of the whole set of EPEL branches. If you agree with such proposal I am willing to help Cheers [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2074663 [2]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/developing_c_and_cpp_applications_in_rhel_8/additional-toolsets-for-development_developing-applications [3]: https://src.fedoraproject.org/rpms/darktable/pull-request/6 [4]: https://src.fedoraproject.org/rpms/darktable/pull-request/7 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ppc64le build failure on F34 and EPEL8, EPEL8-next only
I confirm Dan's analysis. Problem solved. All details at https://bugzilla.redhat.com/show_bug.cgi?id=2074663#c7 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ppc64le build failure on F34 and EPEL8, EPEL8-next only
Il 12/04/22 20:59, Dan Horák ha scritto: On Tue, 12 Apr 2022 18:20:25 +0200 Germano Massullo wrote: Hello, a new kind of failure is happening, still on same package and CPU arch https://koji.fedoraproject.org/koji/taskinfo?taskID=85563318 Maybe an OpenMP bug? so now it chokes on inlined functions from src/common/fast_guided_filter.h that use multi-version feature via the target_clones() attribute something similar is being solved in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 Thank you, I will mention it in the bugreport I opened https://bugzilla.redhat.com/show_bug.cgi?id=2074663 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ppc64le build failure on F34 and EPEL8, EPEL8-next only
Hello, a new kind of failure is happening, still on same package and CPU arch https://koji.fedoraproject.org/koji/taskinfo?taskID=85563318 Maybe an OpenMP bug? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: boinc-client build failure on non x86 architectures F>35
Thank you very much Mamoru! Why don't you submit your patch to upstream repository, so you get the credit? We will need to patch such thing upstream anyways! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
boinc-client build failure on non x86 architectures F>35
Hello, on Fedora > 35 I am experiencing build failures on boinc-client on non x86 architectures. I do not understand the reason https://koji.fedoraproject.org/koji/taskinfo?taskID=85413241 F35 instead builds correctly https://koji.fedoraproject.org/koji/taskinfo?taskID=85413347 Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FESCo wants to know what you use i686 packages for
All these are somehow related to Steam and x86 32 bit games # rpm -qa | grep 686 | sort alsa-lib-1.2.6.1-3.fc35.i686 atk-2.36.0-4.fc35.i686 at-spi2-atk-2.38.0-3.fc35.i686 at-spi2-atk-debuginfo-2.38.0-3.fc35.i686 at-spi2-atk-debugsource-2.38.0-3.fc35.i686 at-spi2-core-2.42.0-1.fc35.i686 avahi-libs-0.8-14.fc35.i686 bluez-libs-5.63-1.fc35.i686 bzip2-libs-1.0.8-9.fc35.i686 cairo-1.17.4-4.fc35.i686 cairo-gobject-1.17.4-4.fc35.i686 colord-libs-1.4.5-3.fc35.i686 cups-libs-2.3.3op2-16.fc35.i686 cyrus-sasl-lib-2.1.27-14.fc35.i686 dbus-libs-1.12.22-1.fc35.i686 dconf-0.40.0-5.fc35.i686 elfutils-debuginfod-client-0.186-1.fc35.i686 elfutils-libelf-0.186-1.fc35.i686 elfutils-libs-0.186-1.fc35.i686 expat-2.4.4-1.fc35.i686 fdk-aac-free-2.0.0-7.fc35.i686 flac-libs-1.3.4-1.fc35.i686 fontconfig-2.13.94-5.fc35.i686 freetype-2.11.0-3.fc35.i686 fribidi-1.0.10-5.fc35.i686 gamemode-1.6-3.fc35.i686 gdbm-libs-1.22-1.fc35.i686 gdk-pixbuf2-2.42.6-2.fc35.i686 gdk-pixbuf2-modules-2.42.6-2.fc35.i686 glib2-2.70.5-1.fc35.i686 glibc-2.34-29.fc35.i686 glibc-gconv-extra-2.34-29.fc35.i686 glib-networking-2.70.1-1.fc35.i686 gmp-6.2.0-7.fc35.i686 gnutls-3.7.2-3.fc35.i686 graphite2-1.3.14-8.fc35.i686 gsm-1.0.19-6.fc35.i686 gstreamer1-1.20.0-1.fc35.i686 gtk2-2.24.33-5.fc35.i686 gtk3-3.24.31-2.fc35.i686 harfbuzz-2.9.1-1.fc35.i686 inih-49-4.fc35.i686 jasper-libs-2.0.33-1.fc35.i686 jbigkit-libs-2.1-22.fc35.i686 json-glib-1.6.6-1.fc35.i686 keyutils-libs-1.6.1-3.fc35.i686 krb5-libs-1.19.2-2.fc35.i686 lcms2-2.12-2.fc35.i686 libasyncns-0.8-21.fc35.i686 libatomic-11.2.1-9.fc35.i686 libblkid-2.37.4-1.fc35.i686 libbrotli-1.0.9-6.fc35.i686 libcanberra-0.30-27.fc35.i686 libcanberra-gtk2-0.30-27.fc35.i686 libcanberra-gtk3-0.30-27.fc35.i686 libcap-2.48-3.fc35.i686 libcloudproviders-0.3.1-4.fc35.i686 libcom_err-1.46.3-1.fc35.i686 libcurl-7.79.1-1.fc35.i686 libdatrie-0.2.13-2.fc35.i686 libdb-5.3.28-50.fc35.i686 libdbusmenu-16.04.0-18.fc35.i686 libdbusmenu-gtk3-16.04.0-18.fc35.i686 libdrm-2.4.110-1.fc35.i686 libedit-3.1-40.20210910cvs.fc35.i686 libepoxy-1.5.9-1.fc35.i686 libevent-2.1.12-4.fc35.i686 libffi-3.1-29.fc35.i686 libgcc-11.2.1-9.fc35.i686 libgcrypt-1.9.4-1.fc35.i686 libglvnd-1.3.4-2.fc35.i686 libglvnd-glx-1.3.4-2.fc35.i686 libgpg-error-1.43-1.fc35.i686 libgusb-0.3.9-1.fc35.i686 libICE-1.0.10-7.fc35.i686 libicu-69.1-2.fc35.i686 libidn2-2.3.2-3.fc35.i686 libjpeg-turbo-2.1.0-3.fc35.i686 libldac-2.0.2.3-9.fc35.i686 libmodman-2.0.1-25.fc35.i686 libmount-2.37.4-1.fc35.i686 libnghttp2-1.45.1-1.fc35.i686 libnsl-2.34-29.fc35.i686 libogg-1.3.5-2.fc35.i686 libpciaccess-0.16-5.fc35.i686 libpng12-1.2.57-14.fc35.i686 libpng-1.6.37-11.fc35.i686 libproxy-0.4.17-3.fc35.i686 libpsl-0.21.1-4.fc35.i686 libsbc-1.5-2.fc35.i686 libselinux-3.3-1.fc35.i686 libsepol-3.3-2.fc35.i686 libSM-1.2.3-9.fc35.i686 libsndfile-1.0.31-6.fc35.i686 libsoup-2.74.2-1.fc35.i686 libssh-0.9.6-1.fc35.i686 libstdc++-11.2.1-9.fc35.i686 libstemmer-0-17.585svn.fc35.i686 libtasn1-4.16.0-6.fc35.i686 libtdb-1.4.4-3.fc35.i686 libthai-0.1.28-7.fc35.i686 libtiff-4.3.0-4.fc35.i686 libtool-ltdl-2.4.6-50.fc35.i686 libtracker-sparql-3.2.1-1.fc35.i686 libunistring-0.9.10-14.fc35.i686 libunwind-1.5.0-1.fc35.i686 libusb1-1.0.24-4.fc35.i686 libuuid-2.37.4-1.fc35.i686 libva-2.13.0-3.fc35.i686 libvdpau-1.5-1.fc35.i686 libverto-0.3.2-2.fc35.i686 libvorbis-1.3.7-4.fc35.i686 libwayland-client-1.20.0-1.fc35.i686 libwayland-cursor-1.20.0-1.fc35.i686 libwayland-egl-1.20.0-1.fc35.i686 libwebp-1.2.2-1.fc35.i686 libX11-1.7.3.1-1.fc35.i686 libX11-xcb-1.7.3.1-1.fc35.i686 libXau-1.0.9-7.fc35.i686 libxcb-1.13.1-8.fc35.i686 libXcomposite-0.4.5-6.fc35.i686 libxcrypt-4.4.28-1.fc35.i686 libxcrypt-compat-4.4.28-1.fc35.i686 libXcursor-1.2.0-6.fc35.i686 libXdamage-1.1.5-6.fc35.i686 libXext-1.3.4-7.fc35.i686 libXfixes-6.0.0-2.fc35.i686 libXft-2.3.3-7.fc35.i686 libXi-1.7.10-7.fc35.i686 libXinerama-1.1.4-9.fc35.i686 libxkbcommon-1.3.1-1.fc35.i686 libxml2-2.9.13-1.fc35.i686 libXrandr-1.5.2-7.fc35.i686 libXrender-0.9.10-15.fc35.i686 libXScrnSaver-1.2.3-9.fc35.i686 libxshmfence-1.3-9.fc35.i686 libXtst-1.2.3-15.fc35.i686 libXxf86vm-1.1.4-17.fc35.i686 libzstd-1.5.2-1.fc35.i686 lilv-0.24.10-4.fc35.i686 llvm-libs-13.0.0-4.fc35.i686 lz4-libs-1.9.3-3.fc35.i686 mesa-dri-drivers-21.3.7-1.fc35.i686 mesa-filesystem-21.3.7-1.fc35.i686 mesa-libGL-21.3.7-1.fc35.i686 mesa-libglapi-21.3.7-1.fc35.i686 mesa-vulkan-drivers-21.3.7-1.fc35.i686 ncurses-libs-6.2-8.20210508.fc35.i686 nettle-3.7.3-2.fc35.i686 nspr-4.32.0-5.fc35.i686 nss-3.75.0-1.fc35.i686 nss-softokn-3.75.0-1.fc35.i686 nss-softokn-freebl-3.75.0-1.fc35.i686 nss-util-3.75.0-1.fc35.i686 openldap-2.4.59-3.fc35.i686 openssl-libs-1.1.1l-2.fc35.i686 openssl-pkcs11-0.4.11-4.fc35.i686 opus-1.3.1-9.fc35.i686 p11-kit-0.23.22-4.fc35.i686 pango-1.50.4-1.fc35.i686 pcre2-10.39-1.fc35.i686 pcre-8.45-1.fc35.i686 pipewire-0.3.48-1.fc35.i686 pipewire-alsa-0.3.48-1.fc35.i686 pipewire-debuginfo-0.3.48-1.fc35.i686 pipewire-debugsource-0.3.48-1.fc35.i686 pipewire-libs-0.3.48-1.fc35.i686 pixman-0.40.0-4.fc35.i686 pulseaud
Re: GNOME only: KeepassXC quirks
Il 24/02/22 00:25, Germano Massullo ha scritto: This problem should have been fixed with commit https://code.qt.io/cgit/qt/qtbase.git/commit/?id=dda7dab8274991e4a61a97c352d4367f8f815bb9 after checking which Qt version includes such commit, I will remove xcb.patch [1] and release a new keepassxc release to test its behaviour [1]: https://src.fedoraproject.org/rpms/keepassxc/blob/rawhide/f/xcb.patch In the previously mentioned Qt code URL, there is a "Pick-to: 6.2" attribute that means that it has been included only in Qt >= 6.2. Therefore the bug is very likely to be still present in all applications that use Qt 5 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
This problem should have been fixed with commit https://code.qt.io/cgit/qt/qtbase.git/commit/?id=dda7dab8274991e4a61a97c352d4367f8f815bb9 after checking which Qt version includes such commit, I will remove xcb.patch [1] and release a new keepassxc release to test its behaviour [1]: https://src.fedoraproject.org/rpms/keepassxc/blob/rawhide/f/xcb.patch ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
ZFS
After having dealt for the n-th time with libvirt dependencies messing up [1] with zfs packages installed from ZFS On Linux repository, I wondered if we could just include them in Fedora repository. They are not in the Fedora Forbidden Items [2] list. Fedora Wiki ZFS page [3] says: "Fedora releases don't ship proper ZFS support included to kernel because its license CDDL (Common Development and Distribution License)[...]" but since ZFS On Linux provide zfs-dkms package, I think this should avoid any possible legal trouble between Linux kernel licence and ZFS licence. What do you think about? [1]: libvirt-daemon-driver-storage installs libvirt-daemon-driver-storage-zfs which requires zfs-fuse (from Fedora repo. A package no longer upgraded by upstream dev). The latter has Provides:/sbin/zfs, /sbin/mount.zfs that IMHO is the cause of the conflict with the ZFS packages from ZFS On Linux. The only way to solve the problem is to use "dnf swap zfs-fuse zfs" [2]: https://fedoraproject.org/wiki/Forbidden_items [3]: https://fedoraproject.org/wiki/ZFS ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ppc64le build failure on F34 and EPEL8, EPEL8-next only
Il 10/01/22 00:30, Germano Massullo ha scritto: Thank you, and what about EPEL8 build failure? Such branch is not affected by that bug https://koji.fedoraproject.org/koji/taskinfo?taskID=81021476 Thank you new darktable release build failure on EL8 ppc64le https://koji.fedoraproject.org/koji/buildinfo?buildID=1916506 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedora-review bugreport 2038828
the problem was fedora-review not properly supporting tmpfs. All infos in the bugreport Best regards ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
fedora-review bugreport 2038828
Hello, a month ago I opened a bugreport against fedora-review https://bugzilla.redhat.com/show_bug.cgi?id=2038828 Today I tried to clean up mock build with various command, and at the end I also tried to delete the content of folder /var/lib/mock/ but I am still experiencing the problem. Since it is blocking a review that I should complete as soon as possible, does anybody know if I can apply any kind of workaround? Using another machine would require me to move all certs, etc. so it's not my preferred option Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: search among all spec files
Thank you everybody for your suggestions! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
search among all spec files
Good day. I have to search gcc-toolset among all Fedora packages specs files, in order to read some example of usage. Is that possible? For example cloning the whole git repository. Best regards ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ppc64le build failure on F34 and EPEL8, EPEL8-next only
Thank you, and what about EPEL8 build failure? Such branch is not affected by that bug https://koji.fedoraproject.org/koji/taskinfo?taskID=81021476 Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
ppc64le build failure on F34 and EPEL8, EPEL8-next only
Good day. darktable maintainer here. I am experiencing a ppc64le build failure on F34 and EPEL8, EPEL8-next only. https://koji.fedoraproject.org/koji/taskinfo?taskID=81021540 https://koji.fedoraproject.org/koji/taskinfo?taskID=81021476 On F34 the error is /builddir/build/BUILD/darktable-3.8.0/src/iop/channelmixerrgb.c: In function '_convert_GUI_colors.part.0.constprop': /builddir/build/BUILD/darktable-3.8.0/src/iop/channelmixerrgb.c:3085:1: internal compiler error: in patch_jump_insn, at cfgrtl.c:1299 3085 | } | ^ Please submit a full bug report, with preprocessed source if appropriate. Other branches can successfully build on aarch64, x86_64, pcc64le. Do you know what can be the problem? Thank you___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: (Quite?) OT Question: Is still relevant Software RAID?
Il giorno gio 2 dic 2021 alle ore 12:20 Björn Persson ha scritto: > But the licensing situation makes ZFS painful, and BTRFS seems to take > forever to mature, so it should be expected that many people will choose > software RAID No The. ZFS licensing problems you mentioned have nothing to do with users. Cheers An OpenZFS user. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proven packagers breaking EPEL branches
I apologize, previous message was not meant to be sent on the mailing list ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proven packagers breaking EPEL branches
Moreover it does not even compile on Fedora https://kojipkgs.fedoraproject.org//work/tasks/7311/71287311/mock_output.log file /usr/lib64/python3.10/site-packages/imath.so conflicts between attempted installs of python3-openexr-2.5.5-2.fc35.x86_64 and python3-imath-3.0.2-4.fc35.x86_64 file /usr/lib64/libImath.so conflicts between attempted installs of openexr-devel-2.5.5-2.fc35.x86_64 and imath-devel-3.0.2-4.fc35.x86_64 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Proven packagers breaking EPEL branches
I maintain one single spec file for all branches (Fedora + EPEL) by using spec file macros. The majority of times a proven packager offers his help on packages I maintain, he breaks the EPEL branch. Proven packagers, if you see macros of EPEL branches could you please take care of testing them too? Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
I opened ticket "revert Qt Wayland By Default On Gnome" https://bugzilla.redhat.com/show_bug.cgi?id=1965539 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
Il 01/05/21 21:01, Jan Grulich ha scritto: > Hi, > > pá 30. 4. 2021 v 12:30 odesílatel Germano Massullo > mailto:germano.massu...@gmail.com>> napsal: > > KeepassXC comaintainer here. > > There are many Fedora GNOME Wayland users experiencing quirks in > using KeepassXC. Textboxes not showing text that is being written, > other quirks with GNOME, etc. > > Upstream developers said many times that this only happen with > Fedora users. > > Myself I do use KDE Spin and I do not experience these issues > (tested on Wayland too) > > I don't paste bugs titles since they are misleading > > https://bugzilla.redhat.com/show_bug.cgi?id=1925130 > <https://bugzilla.redhat.com/show_bug.cgi?id=1925130> > > > I haven't seen any other application having this issue and I've been > using lots of Qt/KDE apps under GNOME. It might be an issue in > KeepassXC as they have some custom theme. Not KeePassXC bug because: - as I said, upstream devels confirmed that all strange quirks bugreports they are receiving since a while, are from Fedora GNOME (Wayland) only - I received various feedbacks [1] [2] of problems disappearing as soon I introduced this patch https://src.fedoraproject.org/rpms/keepassxc/blob/rawhide/f/xcb.patch [1] https://bugzilla.redhat.com/show_bug.cgi?id=1925130#c13 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1954742#c10 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
Il 01/05/21 12:40, Vitaly Zaitsev via devel ha scritto:
> On 01.05.2021 11:44, Germano Massullo wrote:
>> Let's wait also for Jan Grulich. He should be back next days/weeks
>
> Yes, but my simple workaround works fine. We need to add a new method:
>
> ```c++
> #ifdef Q_OS_LINUX
> void wayland_hacks()
> {
> // Workaround to https://github.com/ksnip/ksnip/issues/416
> QByteArray currentDesktop = qgetenv("XDG_CURRENT_DESKTOP").toLower();
> QByteArray sessionDesktop = qgetenv("XDG_SESSION_DESKTOP").toLower();
> QByteArray sessionType = qgetenv("XDG_SESSION_TYPE").toLower();
> if (sessionType.contains("wayland") &&
> (currentDesktop.contains("gnome") || sessionDesktop.contains("gnome")))
> {
> qputenv("QT_QPA_PLATFORM", "xcb");
> }
> }
> #endif
> ```
>
> Then call it in main(), just before the QApplication initialization:
>
> ```c++
> int main(int argc, char** argv)
> {
> #ifdef Q_OS_LINUX
> wayland_hacks();
> #endif
> QApplication app(argc, argv);
> }
> ```
>
https://src.fedoraproject.org/rpms/keepassxc/blob/rawhide/f/xcb.patch
https://bodhi.fedoraproject.org/updates/?packages=keepassxc
Any KeePassXC karma feedback is welcomed
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: nokey warning during F33->F34 upgrade (fstrm package)
Il 01/05/21 20:41, Samuel Sieb ha scritto: > On 2021-05-01 2:42 a.m., Germano Massullo wrote: >> Il 30/04/21 18:33, Kevin Fenzi ha scritto: >>> On Fri, Apr 30, 2021 at 02:19:31PM +0200, Germano Massullo wrote: >>>> After running >>>> dnf system-upgrade download --releasever=34 >>>> and downloading all files, I got the following warning >>>> warning: >>>> /var/lib/dnf/system-upgrade/fedora-e21c25ac3662d294/packages/fstrm-0.6.0-4.fc34.x86_64.rpm: >>>> >>>> Header V4 RSA/SHA256 Signature, ID key 45719a39: NOKEY > > Wasn't there a prompt after that to import the key? As far I can see from this my (old) bugreport yes https://bugzilla.redhat.com/show_bug.cgi?id=1286652 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: nokey warning during F33->F34 upgrade (fstrm package)
Il 01/05/21 19:49, Kevin Fenzi ha scritto: > On Sat, May 01, 2021 at 11:42:52AM +0200, Germano Massullo wrote: >> Il 30/04/21 18:33, Kevin Fenzi ha scritto: >>> On Fri, Apr 30, 2021 at 02:19:31PM +0200, Germano Massullo wrote: >>>> After running >>>> dnf system-upgrade download --releasever=34 >>>> and downloading all files, I got the following warning >>>> warning: >>>> /var/lib/dnf/system-upgrade/fedora-e21c25ac3662d294/packages/fstrm-0.6.0-4.fc34.x86_64.rpm: >>>> Header V4 RSA/SHA256 Signature, ID key 45719a39: NOKEY >>>> >>>> Why this package does not have a key? >>> That is in fact the f34 key and the package is signed with it. >>> >>> You don't have that key in your rpmdb (which is why it says NOKEY). >> Mmh why it says that only for that package? > Don't know. ;( Do you still have that file? Or it's gone with the > upgrade? What file? >>> There was a fedora-release for f33/f32 that had this key in it, if you >>> updated to that it should have been able to correctly import it. >> I always upgrade from N to N+1 Fedora versions >> >>> Hard to say whats going on without more info. >>> What version is there? what version of fedora-release do you have >>> installed? >> From dnf system upgrade logs I see a >> fedora-release-common-33-4.noarch > Yeah, that should definitely have the key in it and if the rest worked I > don't see why that one package would be singled out... > > Perhaps file a bug on dnf system-upgrade plugin and see if they can > figure it out? Ah I found out this my old bugreport https://bugzilla.redhat.com/show_bug.cgi?id=1286652 which leads to "Feature request: make clear RPM to trigger key import is signed" https://bugzilla.redhat.com/show_bug.cgi?id=1293882 that is a bugreport where people already started to work on it years ago ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
Il 01/05/21 12:56, Germano Massullo ha scritto: > Il 30/04/21 19:11, Vitaly Zaitsev via devel ha scritto: >> On 30.04.2021 16:09, Germano Massullo wrote: >>> Could you please suggest me how I could implement a patch? >> https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workaround.patch >> > I have a question: > https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workaround.patch#_26 > wouldn't be better to remove the reference to gnome? So that it the > patch will work for all Wayland sessions, like KDE Plasma, etc? Since > the root problem is on Qt not the specific desktop environment My fault, I did not notice that the downstream qt patch was gnome oriented https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/qtbase-use-wayland-on-gnome.patch ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
Il 30/04/21 19:11, Vitaly Zaitsev via devel ha scritto: > On 30.04.2021 16:09, Germano Massullo wrote: >> Could you please suggest me how I could implement a patch? > > https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workaround.patch > I have a question: https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workaround.patch#_26 wouldn't be better to remove the reference to gnome? So that it the patch will work for all Wayland sessions, like KDE Plasma, etc? Since the root problem is on Qt not the specific desktop environment ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
Il 30/04/21 19:11, Vitaly Zaitsev via devel ha scritto: > On 30.04.2021 16:09, Germano Massullo wrote: >> Could you please suggest me how I could implement a patch? > > https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workaround.patch > > >> Would you do it in the .desktop file? > > Patching desktop file is not a good idea. It can break lots of things > and custom themes. > Let's wait also for Jan Grulich. He should be back next days/weeks ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: nokey warning during F33->F34 upgrade (fstrm package)
Il 30/04/21 18:33, Kevin Fenzi ha scritto: > On Fri, Apr 30, 2021 at 02:19:31PM +0200, Germano Massullo wrote: >> After running >> dnf system-upgrade download --releasever=34 >> and downloading all files, I got the following warning >> warning: >> /var/lib/dnf/system-upgrade/fedora-e21c25ac3662d294/packages/fstrm-0.6.0-4.fc34.x86_64.rpm: >> Header V4 RSA/SHA256 Signature, ID key 45719a39: NOKEY >> >> Why this package does not have a key? > That is in fact the f34 key and the package is signed with it. > > You don't have that key in your rpmdb (which is why it says NOKEY). Mmh why it says that only for that package? > There was a fedora-release for f33/f32 that had this key in it, if you > updated to that it should have been able to correctly import it. I always upgrade from N to N+1 Fedora versions > Hard to say whats going on without more info. > What version is there? what version of fedora-release do you have > installed? From dnf system upgrade logs I see a fedora-release-common-33-4.noarch Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
Il 30/04/21 16:23, Hans de Goede ha scritto: > I tend to agree, it seems this downstream patch breaks at least 3 apps: > > 1. KeepassXC > 2. calibre > 3. audacious I think also nextcloud-client. I have been receiving bugreports about quirks on GNOME ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
Il 30/04/21 15:33, Vitaly Zaitsev via devel ha scritto: > On 30.04.2021 12:23, Germano Massullo wrote: >> There are many Fedora GNOME Wayland users experiencing quirks in >> using KeepassXC. Textboxes not showing text that is being written, >> other quirks with GNOME, etc. > > There are a lot of issues with Mutter and Qt5[1]. That's why the Qt > upstream forces XCB backend for the Gnome 3, but Fedora removes it in > downstream[2], as approved by the system-wide proposal[3]. > > Please try the following: > QT_QPA_PLATFORM=xcb /usr/bin/keepassxc > > I think this downstream patch should be dropped from Fedora. > > See also: > > [1]: https://bugreports.qt.io/browse/QTBUG-88293 > [2]: > https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/qtbase-use-wayland-on-gnome.patch > [3]: > https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome > Thank you so much Vitaly, your infos are very precious. Many users reported to have fixed their problems by using xcb platform. Could you please suggest me how I could implement a patch? Would you do it in the .desktop file? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
nokey warning during F33->F34 upgrade (fstrm package)
After running dnf system-upgrade download --releasever=34 and downloading all files, I got the following warning warning: /var/lib/dnf/system-upgrade/fedora-e21c25ac3662d294/packages/fstrm-0.6.0-4.fc34.x86_64.rpm: Header V4 RSA/SHA256 Signature, ID key 45719a39: NOKEY Why this package does not have a key? Cheers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
Il 30/04/21 14:11, Robert Marcano via devel ha scritto: > The bug about input fields not able to take text input happen > occasionally on passwords fields on XCA. What is XCA? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
GNOME only: KeepassXC quirks
KeepassXC comaintainer here. There are many Fedora GNOME Wayland users experiencing quirks in using KeepassXC. Textboxes not showing text that is being written, other quirks with GNOME, etc. Upstream developers said many times that this only happen with Fedora users. Myself I do use KDE Spin and I do not experience these issues (tested on Wayland too) I don't paste bugs titles since they are misleading https://bugzilla.redhat.com/show_bug.cgi?id=1925130 https://bugzilla.redhat.com/show_bug.cgi?id=1941731 (CentOS 8) https://bugzilla.redhat.com/show_bug.cgi?id=1954742 https://github.com/keepassxreboot/keepassxc/issues/5608 plus others that I cannot find again at the moment I would like to ask if you have any idea about why this happens on GNOME only (and not on other distros too) Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: memleax spec file and review
Done! Review Request: memleax - Debugs memory leak of a running process - https://bugzilla.redhat.com/1946499 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: memleax spec file and review
Il 04/04/21 23:55, Ian McInerney ha scritto: > > On Sun, 4 Apr 2021, 21:53 Germano Massullo, > mailto:germano.massu...@gmail.com>> wrote: > > Good day, I am creating a spec file [0] for memleax memory leaks > analyzer [1], but during build [2] I am getting error "invalid option: > --build=x86_64-redhat-linux-gnu.". Where can be the problem? > Thank you > > [0]: https://pagure.io/memleax/blob/master/f/memleax.spec > <https://pagure.io/memleax/blob/master/f/memleax.spec> > [1]: https://github.com/WuBingzheng/memleax > <https://github.com/WuBingzheng/memleax> > [2]: > https://copr.fedorainfracloud.org/coprs/germano/memleax/build/2114611/ > <https://copr.fedorainfracloud.org/coprs/germano/memleax/build/2114611/> > > > The GitHub repo you linked at [1] doesn't seem to have any > autotools-based build systems, so you shouldn't use the %configure > macro. It looks like it uses CMake, so you should instead use the > %cmake_* macros to configure/build/install. The tar.gz only contains configure.ac, that is not included in master branch. Also, CMakeLists.txt included in master branch, is not included in tar.gz file. I now added the latter as Source1 and I am working on let RPM use such file, I just have to find out how to properly place the cp command in the spec file [0]: https://pagure.io/memleax/blob/master/f/memleax.spec <https://pagure.io/memleax/blob/master/f/memleax.spec> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
memleax spec file and review
Good day, I am creating a spec file [0] for memleax memory leaks analyzer [1], but during build [2] I am getting error "invalid option: --build=x86_64-redhat-linux-gnu.". Where can be the problem? Thank you [0]: https://pagure.io/memleax/blob/master/f/memleax.spec [1]: https://github.com/WuBingzheng/memleax [2]: https://copr.fedorainfracloud.org/coprs/germano/memleax/build/2114611/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proven Packagers: update Audacity
Il 09/02/21 19:06, Gwyn Ciesla via devel ha scritto: > I'll take care of it. Thank you! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Proven Packagers: update Audacity
Can anybody please help updating Audacity package? I cannot help this time. Despite this package has 2 maintainers, the software is no up-to-date and is highly unstable and crashes every time you use it https://bugzilla.redhat.com/show_bug.cgi?id=1836497 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage
Also this build seems to be related to this problem https://koji.fedoraproject.org/koji/taskinfo?taskID=61482059 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Help for FTBFS packages: apcupsd and firefox-pkcs11-loader
Il giorno dom 31 gen 2021 alle ore 01:38 Robert-André Mauchin
ha scritto:
> It seems out of tree builds are not supported by the build script.
> Just copy the xpi to the build directory to make it work:
>
> cp -a *.xpi %{_vpath_builddir}/
>
> (after the %cmake call)
Thank you, it worked!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Help for FTBFS packages: apcupsd and firefox-pkcs11-loader
apcupsd package has been fixed by Jason L Tibbitts III ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Help for FTBFS packages: apcupsd and firefox-pkcs11-loader
I tried fixing apcupsd and firefox-pkcs11-loader that started to fail after introduction of "CMake to do out-of-source builds", but I got some errors about missing files, that is strange since package structure has not changed, it's the same that built successfully on older Fedora branches problems. So I am writing this message to ask for your help. Details at following bugzilla comments firefox-pkcs11-loader https://bugzilla.redhat.com/show_bug.cgi?id=1863558#c7 apcupsd https://bugzilla.redhat.com/show_bug.cgi?id=1863218#c4 Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: runtime dependencies not in Requires spec section
Jerry James wrote: > RPM can query ELF objects (executables and shared libraries) to find > DT_NEEDED fields. That gives it a list of libraries that are depended > on directly. It generates Requires for those dependencies > automatically; see /usr/lib/rpm/find-requires. So the keepassxc > package does contain Requires, they just don't appear explicitly in > the spec file (and shouldn't). So this explains the difference with Python packages that instead many times need Requires. Vitaly Zaitsev wrote: > On 30.12.2020 23:01, Jerry James wrote: >> RPM can query ELF objects (executables and shared libraries) to find >> DT_NEEDED fields. That gives it a list of libraries that are depended >> on directly. > > Except for Qt5Svg, because it is a Qt runtime plugin. Actually Qt5Svg does not need Requires https://bugzilla.redhat.com/show_bug.cgi?id=1911210#c1 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
runtime dependencies not in Requires spec section
I am one of the keepassxc maintainers. Bugreport "Missing dependency: qt5-qtsvg libQt5Svg.so.5" https://bugzilla.redhat.com/show_bug.cgi?id=1911210 made me wonder about the following thing: I just installed a basic Fedora server to do a test concerning keepassxc libs. Keepassxc spec file [1] does not contain any Requires dependency, but when I install it, it triggers the installation of these libraries [2] that are needed at runtime. My question is: how can keepassxc trigger the installation of such libraries if the spec file does not contain any Requires dependency that should be the attribute to identify runtime dependencies that are needed by the package? Thank you [1]: https://src.fedoraproject.org/rpms/keepassxc/blob/master/f/keepassxc.spec [2]: fontconfig freetype glx-utils graphite2 harfbuzz langpacks-core-font-en libICE libSM libX1 libX11-common libX11-xcb libXau libXdamage libXext libXfixes libXi libXtst libXxf86vm libdrm libevdev libglvnd libglvnd-egl libglvnd-glx libinput libjpeg-turbo libpciaccess libsodium libwacom libwacom-data libwayland-client libwayland-server libxcb libxkbcommon-x11 libxshmfence libyubikey llvm-libs mesa-filesystem mesa-libEGL mesa-libGL mesa-libgbm mesa-libglapi mtdev pcre2-utf16 qt-settings qt5-qtbase qt5-qtbase-common qt5-qtbase-gui qt5-qtsvg qt5-qtx11extras quazip-qt5 xcb-util xcb-util-image xcb-util-keysyms xcb-util-renderutil xcb-util-wm xml-common ykpers Weak dependencies: mesa-dri-drivers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
ganglia builds on mock/copr, fails on koji
ganglia EPEL 7 successfully builds on mock and copr [1] but fails on koji [2], complaining about a missing close in a %if block. By seeing the spec file I don't see any missing closure in the block, and I don't understand this different behaviour between copr and koji What do you think about? Thank you [1]: https://copr.fedorainfracloud.org/coprs/germano/ganglia/build/1700857/ [2]: https://koji.fedoraproject.org/koji/taskinfo?taskID=53026497 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: fedbot spamming in #fedora
https://pagure.io/irc-support-sig/issue/200 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: fedbot spamming in #fedora
Il 06/09/20 23:03, Kevin Fenzi ha scritto: > On Sat, Sep 05, 2020 at 12:54:34AM +0200, Germano Massullo wrote: >> Il 19/07/20 19:41, Kevin Fenzi ha scritto: >>> On Fri, Jul 17, 2020 at 05:34:13PM +0200, Germano Massullo wrote: >>>> Is it necessary to have in #fedora IRC channel, fedbot spamming 48 times >>>> per day about Fedora respins update? >>>> >>>> [16:51] *** F32-20200715 updated lives available: >>>> https://tinyurl.com/Live-respins2 Built by the Fedora Respin Sig more >>>> info #fedora-respins *** >>> Copying jbwilla on this for comment. >>> >>> kevin >> Any news? > Nope, I mentioned it to him again... > > do note that you can /ignore it it most IRC clients if it bothers you. > > kevin I use fedbot, I don't want to put it in ignore list ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Please update Darktable to latest stable on Fedora 33
Il 26/09/20 03:03, Luya Tshimbalanga ha scritto: > > On 2020-09-25 12:53 p.m., Germano Massullo wrote: >> I apologize, this happened because F33 was branched in the same days I >> was building darktable. I must have missed the announcement. >> Anyways for any problem related to a package users should leave a >> comment on bugzilla rather than the mailing list >> ___ > > It is all good. As explained on other post, an automatic bug report in > that regards was already submitted: > > https://bugzilla.redhat.com/show_bug.cgi?id=1863394 Yes but in any case, the way to deal with those kind of problems is to leave a message in already existing (or not) bugreports and/or send e-mails to maintainers, since it may happen that we don't read every single thread in the mailing list. Indeed a friend alerted me about this discussion, since I did not notice it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Please update Darktable to latest stable on Fedora 33
I apologize, this happened because F33 was branched in the same days I was building darktable. I must have missed the announcement. Anyways for any problem related to a package users should leave a comment on bugzilla rather than the mailing list ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: fedbot spamming in #fedora
Il 19/07/20 19:41, Kevin Fenzi ha scritto: > On Fri, Jul 17, 2020 at 05:34:13PM +0200, Germano Massullo wrote: >> Is it necessary to have in #fedora IRC channel, fedbot spamming 48 times >> per day about Fedora respins update? >> >> [16:51] *** F32-20200715 updated lives available: >> https://tinyurl.com/Live-respins2 Built by the Fedora Respin Sig more >> info #fedora-respins *** > Copying jbwilla on this for comment. > > kevin Any news? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora official kernel build fails to compile on Copr
I solved the previous error about macros expanded in comments, and now the build fails for other strange reasons. https://copr.fedorainfracloud.org/coprs/germano/kernel_204253_comment_14_patch/build/1616496/ By the way by commenting my patch on spec file, the kernel builds successfully https://copr.fedorainfracloud.org/coprs/germano/kernel_fedora_vanilla/build/1616497/ therefore the problem maybe my patch not being in git patch format Instead of using "git format-patch" against branches, I wanted to use it against two local folders like I do with "diff" command during my packaging activity, so I tried git format-patch --dirstat=linux-5.7-orig,linux-5.7 and ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
GCC "-fparallel-jobs" up to ~1.9x speedup when compiling individual files in parallel
I think soon we will have a big boost in Koji performances thanks to Giuliano Belinassi and his work on addressing GCC parallelization bottlenecks. According to Phoronix, compiling individual files in parallel may have up to ~1.9x speedup: https://www.phoronix.com/scan.php?page=news_item&px=GCC-fparallel-jobs-Patches ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora official kernel build fails to compile on Copr
I solved the previous error about macros expanded in comments, and now the build fails for other strange reasons. https://copr.fedorainfracloud.org/coprs/germano/kernel_204253_comment_14_patch/build/1616496/ By the way by commenting my patch on spec file, the kernel builds successfully https://copr.fedorainfracloud.org/coprs/germano/kernel_fedora_vanilla/build/1616497/ therefore the problem maybe my patch not being in git patch format Instead of using "git format-patch" against branches, I wanted to use it against two local folders like I do with "diff" command during my packaging activity, so I tried git format-patch --dirstat linux-5.7-orig linux-5.7 but it did not return anything. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora official kernel build fails to compile on Copr
Il 18/08/20 09:40, Fabio Valentini ha scritto: > On Tue, Aug 18, 2020, 02:15 Laura Abbott <mailto:la...@labbott.name>> wrote: > > On 8/17/20 7:36 PM, Germano Massullo wrote: > > Hi there, I would need help in understanding why this kernel > build failed. > > > > > > https://copr.fedorainfracloud.org/coprs/germano/kernel_204253_comment_14_patch/build/1613735/ > > > > 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 > > From your log: > > Applying: PCI: Add MCFG quirks for Tegra194 host controllers > Applying: Work around for gcc bug > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377 > Applying: > error: Bad exit status from /var/tmp/rpm-tmp.FxtIcw (%prep) > > > That `Applying :` with nothing after it is suspicious. I'm guessing > the patch isn't being specified correctly in the .spec file. > > > Looks like git is used to apply the patches, but the new patch file is > missing "Subject" and "From" headers, as they would be generated by > git format-patch. > Is there a way to create such git format without having to create git branches, etc.? Using diff is much quicker. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Fedora official kernel build fails to compile on Copr
Hi there, I would need help in understanding why this kernel build failed. https://copr.fedorainfracloud.org/coprs/germano/kernel_204253_comment_14_patch/build/1613735/ 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Remove all non UK/USA English spell checker variants from default Fedora installation
All desktop oriented Fedora installers install on the system packages: hunspell hunspell-en hunspell-en-GB hunspell-en-US When a user opens the language list of the spell checker, is has ~24 different English options, like English (Antigua and Barbuda), English (Australia), English (Bahamas), English (Belize), etc. (See screenshot [1]) People who are not native English speakers have this list even bigger because they will have their own language entry, plus others. Since the huge list is brought by hunspell-en, can we just ship Fedora with hunspell-en-GB and hunspell-en-US ? Another option could be to move all non GB/USA English variants to other hunspell-en-* packages as I said in ticket [2] [1]: https://bugzilla.redhat.com/attachment.cgi?id=1701536 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1858241 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
fedbot spamming in #fedora
Is it necessary to have in #fedora IRC channel, fedbot spamming 48 times per day about Fedora respins update? [16:51] *** F32-20200715 updated lives available: https://tinyurl.com/Live-respins2 Built by the Fedora Respin Sig more info #fedora-respins *** ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Self Introduction: Stefano Figura (returntrip)
Hi Stefano, welcome among Fedora contributors! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
bug 1767576 in fedora-review / mock and relative workarounds
Hello, in comment
https://bugzilla.redhat.com/show_bug.cgi?id=1767576#c7
I wrote my experience about fedora-review / mock bug that returns message
%{python3_pkgversion} expanded too early.
As workaround I renamed
python3-dateutil-2.8.0-2.fc30.src.rpm
to
pythonX-dateutil-2.8.0-2.fc30.src.rpm
but fedora-review fails and mock instead works. How can this happen?
fedora-review -rn pythonX-dateutil-2.8.0-2.el7.src.rpm -m epel-7-x86_64
messages:
=
$ cat /home/user/pythonX-dateutil/results/build.log
Mock Version: 1.4.21
Mock Version: 1.4.21
Mock Version: 1.4.21
ENTER ['do_with_status'](['bash', '--login', '-c', '/usr/bin/rpmbuild
-bs --target x86_64 --nodeps
/builddir/build/SPECS/pythonX-dateutil.spec'],
chrootPath='/var/lib/mock/epel-7-x86_64/root'env={'TERM': 'vt100',
'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf
"\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ',
'LANG': 'it_IT.UTF-8'}shell=Falselogger=timeout=0uid=1000gid=135user='mockbuild'nspawn_args=['--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0e2zp7jw:/etc/resolv.conf']unshare_net=TrueprintOutput=False)
Using nspawn with args ['--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0e2zp7jw:/etc/resolv.conf']
Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M',
'6a93f12b99554f5187ca6634dde022d3', '-D',
'/var/lib/mock/epel-7-x86_64/root', '-a', '--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0e2zp7jw:/etc/resolv.conf',
'--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash',
'--setenv=HOME=/builddir', '--setenv=HOSTNAME=mock',
'--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin',
'--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"',
'--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=it_IT.UTF-8',
'-u', 'mockbuild', 'bash', '--login', '-c', '/usr/bin/rpmbuild -bs
--target x86_64 --nodeps /builddir/build/SPECS/pythonX-dateutil.spec']
with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir',
'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin',
'PROMPT_COMMAND': 'printf "\\033]0;\\007"', 'PS1':
' \\s-\\v\\$ ', 'LANG': 'it_IT.UTF-8'} and shell False
Creazione piattaforme target in corso: x86_64
Creazione per il target x86_64 in corso
Scritto: /builddir/build/SRPMS/pythonX-dateutil-2.8.0-2.el7.src.rpm
Child return code was: 0
ENTER ['do_with_status'](['bash', '--login', '-c', '/usr/bin/rpmbuild
-bb --target x86_64 --nodeps
/builddir/build/SPECS/pythonX-dateutil.spec'],
chrootPath='/var/lib/mock/epel-7-x86_64/root'env={'TERM': 'vt100',
'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf
"\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ',
'LANG': 'it_IT.UTF-8'}shell=Falselogger=timeout=0uid=1000gid=135user='mockbuild'nspawn_args=['--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0e2zp7jw:/etc/resolv.conf']unshare_net=TrueprintOutput=False)
Using nspawn with args ['--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0e2zp7jw:/etc/resolv.conf']
Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M',
'7fc50fbdd7ad47258797050e5baf2177', '-D',
'/var/lib/mock/epel-7-x86_64/root', '-a', '--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0e2zp7jw:/etc/resolv.conf',
'--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash',
'--setenv=HOME=/builddir', '--setenv=HOSTNAME=mock',
'--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin',
'--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"',
'--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=it_IT.UTF-8',
'-u', 'mockbuild', 'bash', '--login', '-c', '/usr/bin/rpmbuild -bb
--target x86_64 --nodeps /builddir/build/SPECS/pythonX-dateutil.spec']
with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir',
'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin',
'PROMPT_COMMAND': 'printf "\\033]0;\\007"', 'PS1':
' \\s-\\v\\$ ', 'LANG': 'it_IT.UTF-8'} and shell False
Creazione piattaforme target in corso: x86_64
Creazione per il target x86_64 in corso
Esecuzione(%prep) in corso: /bin/sh -e /var/tmp/rpm-tmp.7EW5sc
+ umask 022
+ cd /builddir/build/BUILD
+ cd /builddir/build/BUILD
+ rm -rf python-dateutil-2.8.0
+ /usr/bin/gzip -dc /builddir/build/SOURCES/python-dateutil-2.8.0.tar.gz
+ /usr/bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd python-dateutil-2.8.0
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ iconv --from=ISO-8859-1 --to=UTF-8 NEWS
+ mv NEWS.new NEWS
+ exit 0
Esecuzione(%build) in corso: /bin/sh -e /var/tmp/rpm-tmp.nhj7aB
+ umask 022
+ cd /builddir/build/BUILD
+ cd python-dateutil-2.8.0
+ %py3_build
/var/tmp/rpm-tmp.nhj7aB: line 29: fg: no job control
Errori di compilazione RPM:
errore: Stato d'uscita errato da /var/tmp/rpm-tmp.nhj7aB (%build)
Stato d'uscita errato da /var/tmp/rpm-tmp.nhj7aB (%build)
Child return code was: 1
EXCEPTION: [Error()]
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/mockbuild/trace_decorator.py",
line 95, in trace
result = func(*args, **kw)
File "/usr/lib/python3.7/site-packages/mockbuild/util.py", lin
Re: Please welcome Julen (@jlanda) to the packager group
Welcome and thank you for your future contributions! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Packaging OnlyOffice Desktop Editors
Il dom 6 ott 2019, 10:09 Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> ha scritto: > On 06.10.2019 09:08, Germano Massullo wrote: > > I would like to package OnlyOffice Desktop Editors [1] > > Packaging of Electron is not allowed: > https://fedoraproject.org/wiki/Electron The webpage should be improved because it does not contain the reasons why packaging of Electron is not allowed > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Packaging OnlyOffice Desktop Editors
I would like to package OnlyOffice Desktop Editors [1], but since it is the first time I see a Github tree very particular like this one, I don't know what effort would be required for packaging. What do you think about? [1]: https://github.com/ONLYOFFICE/DesktopEditors ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Missing debuginfos on service crash
Hello, BOINC client maintainer here. I made a new package version containing a patch. When I run BOINC client as system service, I will get crash errors on journalctl, errors like boinc[2543]: /usr/bin/boinc(+0x8b894)[0x5572ee5ac894]. By the way there are not symbols, like it does not care about installed debuginfo. What could I do? Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Writing C/C++ code to detect running desktop environment
Il giorno mar 4 giu 2019 alle ore 19:00 Björn Persson ha scritto: I'll be surprised if you can do that > to another user's session without help from some privileged service. That is a very good question, thank you for pointing it out. I will let you know ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Writing C/C++ code to detect running desktop environment
Il giorno mar 4 giu 2019 alle ore 17:31 Björn Persson ha scritto: > So the question isn't what desktop the user is using, but rather what > desktops, if any, other users on the machine are using. Well when I started the thread I had not thought that BOINC client service is running on a confined user. > Have you confirmed that you're able to query another user's desktop session > once > you know which desktop it is? I cannot read XDG_CURRENT_DESKTOP of other users. I am actually wondering if checking for specific executables [1] [2] would be the best idea [1]: like for example /usr/bin/plasmashell [2]: or scanning running processes ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Writing C/C++ code to detect running desktop environment
A dubt about XDG_CURRENT_DESKTOP. Since boinc-client runs as a service with its own user, I don't think it will be able to read XDG_CURRENT_DESKTOP defined in other users sessions. Therefore IMHO I need another kind of solution ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Writing C/C++ code to detect running desktop environment
Il giorno mer 29 mag 2019 alle ore 22:12 Stephen Gallagher ha scritto: > > On Wed, May 29, 2019 at 1:16 PM Kalev Lember wrote: > I realize you said that the reasons are off-topic, but in general I'd > recommend not making desktop-specific decisions at a high-level I need to retrieve user idle time. To achieve this I was using GDbus API of GLib/GIO to retrieve the systemd-logind IdleSinceHint DBus property, but I have been told that logind relies on desktop environment to pass the information to update this property. None of main desktop environments does it, so I am writing code that will interact with specific d.e. to retrieve user idle time. More infos at "[systemd-devel] interacting with logind to detect user idle time"[1] [1]: https://lists.freedesktop.org/archives/systemd-devel/2019-May/042496.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Writing C/C++ code to detect running desktop environment
I am working on implementing a piece of code that allows BOINC client [1] to detect the desktop environment used by the user (mainly GNOME, KDE Plasma, XFCE, LXDE/LXQT). This feature will be needed for various reason that are off topic. One idea is to use GDBus to scan DBus to detect the running d.e. What do you think about? Thank you [1]: https://github.com/BOINC/boinc/tree/master/client ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Nextcloud-client testers wanted
Hi Radka, could you please try using a new ~/.config/Nextcloud/ folder and see if this happens again? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Nextcloud-client testers wanted
Hello, I need some testers for getting karma feedbacks about nextcloud-client 2.5.2 that is in updates-testing https://bodhi.fedoraproject.org/updates/?packages=nextcloud-client Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fixing Wireguard spec file
Joe, I found a machine on which I can reproduce the problem. I installed wireguard-dkms-0.0.20190123-2.fc29.noarch on top of wireguard-dkms-0.0.20190123-1.fc29.noarch but the machine while running # dkms autoinstall still returns Error! Could not locate dkms.conf file. File: /var/lib/dkms/wireguard/0.0.20181218/source/dkms.conf does not exist. Actually I am leaving this place, so I will have no longer access to this machine for a certain amount of time ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fixing Wireguard spec file
Il giorno gio 31 gen 2019, 00:15 Joe Doss ha scritto: > Hey Germano, > > I have a working RPM that does not error out with Error! Could not locate > dkms.conf file if you want to test it out before I push it to copr. > Hi Joe, I can test it on next Wireguard snapshot release, actually I cannot reproduce an update action > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: exiv2-0.27.0 coming to rawhide
Thank you Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fixing Wireguard spec file
Il giorno mar 29 gen 2019 alle ore 17:39 Nicolas Chauvet ha scritto: > There is a wireguard package maintained by Robert-André Mauchin on RPM > Fusion that at least... works. Ah I did not know that, thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fixing Wireguard spec file
This [1] is the Wireguard spec file from upstream Copr repo [2]. Wireguard will be included in kernel 5.0, but meanwhile we are using it as dkms. The only problem is that at every Wireguard upgrade, a manual action is required. For example now that I have installed 0.0.20190123, I have to remove the old /var/lib/dkms/wireguard/0.0.20181218/ folder in order to let # dkms autoinstall work. Otherwise I will get a === # dkms status Error! Could not locate dkms.conf file. File: /var/lib/dkms/wireguard/0.0.20181218/source/dkms.conf does not exist. === and wg-quick service unable to start. Do you have any idea about how the Wireguard spec file could be fixed in order to avoid this action having to be runned at every package update? Thank you [1]: https://copr-be.cloud.fedoraproject.org/results/jdoss/wireguard/fedora-29-x86_64/00839061-wireguard-dkms/wireguard-dkms.spec [2]: https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemd unit file not updated on new package update
Ok now everything it is clear. Thank you very much to everybody ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemd unit file not updated on new package update
I reply to your message in the bottom part, just let me explain how I got this situation, because my previous message lacked of informations. I have built and installed a new BOINC release with a systemd unit file patch, and I have noticed that the service behaviour has not changed. Therefore I runned # systemctl edit --full boinc-client and I have noticed that the BOINC systemd unit file has not been updated. So if I recall correctly, I searched for boinc-client.service file, and found it in /etc/systemd/system/boinc-client.service and /usr/lib/systemd/system/boinc-client.service then I remved the former, then runned # dnf reinstall boinc-client.rpm and everything seemed to be okay on both # systemctl edit --full boinc-client and general service behaviour. > First, packages should install unit files into /usr/lib/systed/systemd/. > Units in /etc are for system administrators and shouldn't be touched > by packages. BOINC client spec file should be okay https://src.fedoraproject.org/rpms/boinc-client/blob/master/f/boinc-client.spec I haven't installed the unit file under /etc. Perhaps this happened after # systemctl edit --full boinc-client usage? > Second, if the unit file is marked in .spec as %config(noreplace), > then it won't be touched/replaced on package upgrade. %config(noreplace) is not used for the systemd unit file > Third, you need to do `systemctl daemon-reload` when changing unit > files. Yes I know, I use it everytime I run # systemctl edit --full boinc-client Do you know if it should be runned also after BOINC package update (obviously a machine reboot will make this useless) > Manual edits as in `systemctl edit --full`? Plain `systemctl edit` > only creates addon snippets and does not copy the unit. Yes I know, I only used # systemctl edit --full boinc-client > Nevertheless, if admin placed unit in /etc, this unit has a priority > over the one in /lib installed by package. This is by design. I have never placed BOINC systemd unit file in /etc/systemd/system but I am wondering if "systemctl edit --full" can trigger the creation of such files under this folder ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: AMD ROCm
Andreas Schneider [1] that is aware of Fedora community work on packaging ROCm stack, showed me his pending pull request [2] that "cleans up cmake so that the library can be correctly packaged for distributions. It also cleans up cmake as there are several things which should not be done in cmake." You may want to give a look to it. Best regards [1]: https://github.com/cryptomilk [2]: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/pull/25 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
systemd unit file not updated on new package update
Hello, I am testing various changes in boinc-client systemd unit file. At every RPM package update, it happens really often that on a machine that installs the new RPM version, does not get the new systemd unit file version, so it is not updated. To successfully update the file, I have to remove the old one from /etc/systemd/system/ and reinstall the RPM file. How can this happen? Perhaps manual edits (on localhost) can prevent the file to be updated? Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
AMD ROCm
Hello, AMD ROCm - Open Source Platform for HPC and Ultrascale GPU Computing[1] is packaged by upstream only for RHEL/CentOS and Ubuntu. Is anybody working on packaging it for Fedora? If not, is anybody interested in setting up a team to work on it? Have a nice day [1]: https://rocm.github.io/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Valgrind and Fedora debuginfo: best GUI
I have to debug certain BOINC Manager problems (C++ language), and instead of importing and building the whole source tree in a project in a SDK like Eclipse, I want to simply use the debuginfos already available in Fedora repository. Concerning GDB usage I can do that with QtCreator. It attaches to and external running program, and I can easly see the sources. This seems to not happen with Valgrind on QtCreator: I can manage to start Valgrind and BOINC Manager, but I don't see anything. What do you suggest me to do to achieve using Valgrind in a GUI in a quick way? Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
