packaging

packaging@lists.fedoraproject.org

1 participants
2878 discussions

How to proceed if a PR remains open for a long time?
by Ali Gholami 06 Sep '24

06 Sep '24

I opened a PR to bump version of async-timeout https://src.fedoraproject.org/rpms/python-async-timeout/pull-request/4 which solves this bug https://bugzilla.redhat.com/show_bug.cgi?id=2231324 but it didn't get any response and not merged yet. How would you proceed in such situation? Thank you.

1 0

Who to Require (google-noto-sans-cjk-fonts if langpacks-fonts-whatnot)
by Miro Hrončok 21 Aug '24

21 Aug '24

Hello, a package I co-mainatin bundles google-noto-sans-fonts and google-noto-sans-cjk-fonts upstream. The fonts are removed from the package. We want to add a dependency on them, like this: Requires: google-noto-sans-fonts Requires: google-noto-sans-cjk-fonts However, it was pointed out in [1] that the cjk fonts are quire large and probably no use for non-APAC users. (CJK is the shorthand collective name for the Chinese, Japanese, and Korean writing systems.) We could do: Requires: google-noto-sans-fonts Recommends: google-noto-sans-cjk-fonts But that still installs it to everybody by default. I was wondering if there is a rich dep magic I could use. E.g. Requires: google-noto-sans-fonts Requires: (google-noto-sans-cjk-fonts if langpacks-fonts-...) However, there seem to be no general langpack for cjk. I could try to reverse engineering all the langpacks that need cjk fonts from, the code [2], but perhaps there is a more general way? I see that langpacks-fonts-ja/ko/zh_* Requires google-noto-sans-mono-cjk-vf-fonts and google-noto-serif-cjk-vf-fonts. So I can do: Requires: (google-noto-sans-cjk-fonts if google-noto-serif-cjk-vf-fonts) But can I assume this will always be the case? [1] https://bugzilla.redhat.com/show_bug.cgi?id=2281392#c12 [2] https://github.com/prusa3d/PrusaSlicer/blob/version_2.8.0/src/slic3r/GUI/Im… -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

2 4

Mismatch between versions reported in packages.fedoraproject.org and bodhi updates status for python-valkey
by Matteo Centenaro 13 Aug '24

13 Aug '24

Hello everyone! I'm not sure if something went wrong with the last update I did for python-valkey. The stable version reported in https://packages.fedoraproject.org/pkgs/python-valkey/python3-valkey/ is 5.1.0b7-4, while looking at the package builds packages for 6.0.0b1 are marked as stable (https://bodhi.fedoraproject.org/updates/?packages=python-valkey) Is there something I should do to fix this? Thank you, Matteo.

3 4

Summary should not end with dot?
by Miroslav Suchý 23 Jul '24

23 Jul '24

I am doing package review and there is a summary that ends with a dot. I am sure that for long time we had in packaging guidelines that summary should be max 80 characters and should not end with dot. I cannot find the reference to the dot now https://docs.fedoraproject.org/en-US/packaging-guidelines/#_summary_and_des… Was this intentional change? -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys

3 3

RFC: Virtual Provides for commands in PATH
by Yaakov Selkowitz 13 Jul '24

13 Jul '24

The packaging guidelines currently allow file dependencies in /etc, /usr/bin, and /usr/sbin to be used in spec files. However, this can pose a problem for Fedora Flatpak builds, where an ever-growing number of packages are being built for flatpaks in /app which breaks such file dependencies. (A separate problem is posed by the use of installation path macros in file dependencies, but that is already disallowed; see further discussion in https://pagure.io/packaging-committee/pull-request/1346 ) Regarding /usr/bin and /usr/sbin file dependencies, generally the intention is "require whichever package that installs this command in $PATH". In such a case, it doesn't really matter if it's in /usr/bin (for normal RPM builds, or for packages in the flatpak runtime, or for flatpak buildroot-only dependencies) or in /app/bin (from packages built for flatpaks). While the package name providing that command could be used, package contents can vary over time, and maintainers want to avoid having to track that. Common examples are /usr/bin/groff (groff-base) and /usr/bin/pod2man (perl-podlators), both of which are now built in /app to support perl for flatpak apps. Option 1 would be for either rpm or redhat-rpm-config to generate e.g. cmd(foo) virtual provides for /usr/bin/foo or /usr/sbin/foo (and for flatpaks, also for /app/bin/foo or /app/sbin/foo). Packages would then [B]R: cmd(foo), and (eventually) file dependencies in /usr could be dropped entirely. (The "cmd" name is just an example and could of course be changed.) The major disadvantage of this approach is the implementation time involved. Even if it were to be implemented prior to the F41 mass rebuild, it would not be usable across all stable Fedora versions until the middle of F43 development (after F40 EOL), and wouldn't be compatible with EPEL for a long time (although that could be shortened somewhat if it gets into c10s before the last mass rebuild). It would also create a lot more virtual provides, but would be a big step closer to dropping file dependencies entirely. Option 2 would be to boolean dependencies, e.g.: [Build]Requires: (/usr/bin/foo or /app/bin/foo) This would avoid the implementation delay but is much more verbose. Thoughts? -- Yaakov Selkowitz Principal Software Engineer - Emerging RHEL Red Hat, Inc.

4 4

Question about binary firmware/SDK
by Mattia Verga 07 Jul '24

07 Jul '24

I'm currently packaging indi-3rdparty-libraries by stripping out sources from binary SDKs provided upstream. That means only a few devices are actually supported to work in Fedora. I'm now getting interest in adding support for some cameras I'm about to buy, probably from Player One. Fedora Packaging Guidelines says it's ok to have binary firmware packages when this is required to have hardware function properly. indi-3rdparty includes [1] the Player One SDK to make those cameras work. Now, I'm a bit confused: are those SDK binary files considered as firmware to make hardware function properly? The license under which they are distributed is MIT, so it would be ok... [1] https://github.com/indilib/indi-3rdparty/tree/master/libplayerone

2 1

laurel
by Oden Eriksson 27 Jun '24

27 Jun '24

Hello boys, girls and what nots, I'm an old fart that used to maintain 1/3 of the Mandriva Linux distribution back in the day, and other stuff. That was pretty wild! I've been lurking around here in the background for some years trying to find something useful to do and to contribute with. I tried with maxscale in 2016 but that failed due to a license change. I thought it would be great to break out libinjection from mod_security but then I realized it's pretty much dead. So, now I found laurel that is not packaged yet (besides debian?). My first ever rust package :-) My status as an active fedora maintainer surely must have expired by now but maybe I can get a sponsor to help me activate this again and get me going?. Anyways, the laurel stuff is here: https://repo.nux.se/laurel/ It builds on FC40 and RHEL 9, probably for RHEL 8 as well but I haven't tried that yet. I have probably made a lot of mistakes in the spec file, but consider it as a first take. I really hope laurel is not needed and it's just a matter of cooking up some some voodoo magic sauce to make it work in your SIEM platform. Please enlighten me if that's the case. Happy midsummer eve! -- Regards // The penguin whisperer

3 4

Tmp files created between %install and %check in a python package in rawhide
by Sergio Pascual 20 Jun '24

20 Jun '24

Hi, I was fixing a FTBFS https://bugzilla.redhat.com/show_bug.cgi?id=2291622 in the package python-astroquery The reason of the failure were two files, installed but unpackaged, both in python3_sitelib named: astroquery/ipac/irsa/tests/data/.#.MOST_full_with_tarballs.html.tmp astroquery/ipac/irsa/tests/data/.#.MOST_regular.html.tmp These two files are not in the tarball and I have checked that they appear after %install and before %check The package has files named MOST_full_with_tarballs.html and MOST_regular.html in the same folder as well as other files that seem unaffected. The same package builds in fedora 40 without problems. Any idea of what is happening? Regards, Sergio

3 2

The VCS RPM tag in Fedora packages
by Miro Hrončok 11 Jun '24

11 Jun '24

Hi, I accidentally realized today (in [1]), that RPM has a VCS tag. 396 Fedora packages use it, yay \o/ The tag is described (at [2]) as: """ (Public) upstream source code VCS location. Format <vcs>:<address> with <vcs> being the VCS command used (e.g. git, svn, hg, …) and <address> being the location of the repository as used by the VCS tool to clone/checkout the repository (e.g. https://github.com/rpm-software-management/rpm.git) """ My understanding is the tag should look like this: VCS: git:https://github.com/fedora-python/marshalparser.git However, the 396 Fedora packages use it very weirdly. 268 packages omit the <vcs>: prefix (and the .git suffix, but most of the forges redirect without it, so it's likely moot): VCS: https://github.com/zenon-prover/zenon or VCS: %{forgeurl} 109 packages add an extra scm: prefix (why?): VCS: scm:git:https://github.com/SIPp/sipp.git 5 packages use git+ssh://: VCS: git+git@github.com:ryncsn/memstrack.git 4 of them with a hardcoded commit hash: VCS: git+https://pagure.io/rpm-git-tag-sort.git#0b8afd628229a41858f24692946e3b905d6e46c6: 2 packages use git://: VCS: git://git.kernel.org/pub/scm/linux/kernel/git/colyli/bcache-tools.git Only 11 packages use git:, all of them with %{forgeurl0}: VCS: git:%{forgeurl0} or Vcs: git:%{forgeurl0} Are the 396-11 packages wrong? [1] https://src.fedoraproject.org/rpms/python-BTrees/c/b13e97f40b840a21efddfa3f… [2] https://rpm-software-management.github.io/rpm/manual/tags.html -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 3

rpmlint errors/warnings while reviewing a package
by Mattia Verga 10 Jun '24

10 Jun '24

I'm performing a package review [1] for which I get some rpmlint errors and warnings, but I'm unsure how to proceed... > > - rpmlint errors > > supernovas-solsys2.x86_64: E: undefined-non-weak-symbol > > /usr/lib64/libsolsys2.so.1.0.1 jplint_ (/usr/lib64/libsolsys2.so.1.0.1) > > supernovas-solsys2.x86_64: E: undefined-non-weak-symbol > > /usr/lib64/libsolsys2.so.1.0.1 jplihp_ (/usr/lib64/libsolsys2.so.1.0.1) > > However, the missing `jplint_` and `jplihp_` are an intended feature of the > `solsys2` plugin. As the description of this sub-package implies this plugin > requires user-supplied code to work, and these functions are exactly the > ones that must be defined by the user when using the `libsolsys2` plugin > library. This whole subpackages is aimed for supporting legacy code only, > for people who have existing code that define those `jplint_` and `jplihp_` > symbols, and want to compile their code with supernovas. I can think of 3 > ways to address this: > > 1. Let it be as such, if that's OK. (The Debian package has passed the > initial reviews and is moving to testing with the same setup.) > 2. I can define weak dummy implementations of the `jplint_` and `jplihp` > symbols that simply return an error. That would cure the rpmlint errors, but > it would also hide the fact that the `solsys2` plugin really requires these > symbols be defined by the user-code. This would probably also mean that I'd > have to create a new upstream branch/tag (e.g. 1.0.1-3) to distinguish it > from the one used by the Debian package. > 3. Drop providing the `solsys2` plugin as a library altogether, and supply > the source code as documentation (examples) only. This is fine, but it > requires a bit of extra work for people who want to link their existing > (old) code with the `solsys2` functionality. > > What would be your solution? I suppose we can ignore those errors, as they are just expected? > > - rpmlint warning > > supernovas-cio-data.x86_64: W: only-non-binary-in-usr-lib > > Is the cio_ra.bin an executable? Or it's just a resource? If the latter, > > maybe it can be moved under %{_datadir}/%{name}? > > It is a resource but it is a platform-dependent one -- so it has an 'arch' > dependence. %{_datadir} has no arch-dependence, but %{_libdir} does, which > is why I thought this resource might fit there best. Or do you think it's > better to put arch-dependent data into {%_datadir}, perhaps under a > %{name}/%{_isa} directory instead? I'm not sure here: is it expected that {%_datadir} should not contain arch dependent code? Where it is best to provide such resources? Thanks Mattia [1] https://bugzilla.redhat.com/show_bug.cgi?id=2283055

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging