packaging September 2021

packaging@lists.fedoraproject.org

21 participants
18 discussions

Self Introduction: Eric Curtin
by Eric Curtin 21 Sep '21

21 Sep '21

Hi Guys, As per: https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Packag… here is my introduction. I am the upstream maintainer of inotify-tools and recent hire at Red Hat. I would like to join the Fedora Package Maintainers. Is mise le meas/Regards, Eric Curtin

5 5

Schedule for Thursday's FPC Meeting (2021-09-16 16:00 UTC)
by James Antill 16 Sep '21

16 Sep '21

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2021-09-16 16:00 UTC in #fedora-meeting-1 on irc.libera.chat. Local time information (via. uitime): ================= Day: Thursday ================== 2021-09-16 09:00 PDT US/Pacific 2021-09-16 12:00 EDT --> US/Eastern <-- 2021-09-16 16:00 UTC UTC 2021-09-16 17:00 BST Europe/London 2021-09-16 18:00 CEST Europe/Berlin 2021-09-16 18:00 CEST Europe/Paris 2021-09-16 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2021-09-17 00:00 HKT Asia/Hong_Kong 2021-09-17 00:00 +08 Asia/Singapore 2021-09-17 01:00 JST Asia/Tokyo 2021-09-17 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followup Actions = #topic #pr-814 * mhroncok talk to authors again, having a working example might help a lot = Followup Issues = #topic #886 Enable BRP for detecting RPATH .fpc 886 https://pagure.io/packaging-committee/issue/886 #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #1058 How to handle %lang files in package owned directories? .fpc 1058 https://pagure.io/packaging-committee/issue/1058 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 #topic #pr-1045 WIP: Add discussion of macro names beginning with underscores. https://pagure.io/packaging-committee/pull-request/1045 #topic #pr-1064 Update PIE section https://pagure.io/packaging-committee/pull-request/1064 #topic #pr-1071 Overhaul the RPATH section of the guidelines. https://pagure.io/packaging-committee/pull-request/1071 #topic #pr-1074 Require deleting unused bundled libraries during %prep https://pagure.io/packaging-committee/pull-request/1074 #topic #pr-1077 Introduce %sysusers_create https://pagure.io/packaging-committee/pull-request/1077 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

1 0

Multi-version and review exception
by Remi Collet 08 Sep '21

08 Sep '21

Hi, From Guidelines: > Note that some new packages may be exempt from the review process. > The package is being created so that multiple versions of the same package can coexist in the distribution ... We already have lot of packages in the PHP stack which seems to apply to this exception (all have been reviewed) And some other are mostly ready, examples: php-cs-fixer3 from php-cs-fixer (v2) php-doctrine-cache2 from php-doctrine-cache (v1) php-monolog2 from php-Monolog (v1) php-phpseclib3 from php-phpseclib3 (v2) Can you please confirm that the exception apply here and that I can use the fedpkg with --exception flag ? Remi

2 3

Re: Wine MinGW system libraries
by Richard W.M. Jones 07 Sep '21

07 Sep '21

On Tue, Sep 07, 2021 at 06:13:32PM +0200, Ondrej Mosnacek wrote: > On Tue, Sep 7, 2021 at 5:45 PM Zebediah Figura <zfigura(a)codeweavers.com> wrote: > > On 9/7/21 2:12 AM, Richard W.M. Jones wrote: > > > On Mon, Sep 06, 2021 at 05:59:41PM -0500, Zebediah Figura wrote: > > >> Thanks everyone for their input. > > >> > > >> There seems to be a consensus that Fedora would prefer that we use > > >> their MinGW dynamic libraries. However, this leaves a couple of > > >> questions: > > >> > > >> * As I described in [1], we *may* be able to hack things in the Wine > > >> loader such that we can use unmodified dynamic libraries. However, > > >> it's not fully clear yet that it's feasible. If it turns out to be > > >> infeasible, what preferences does Fedora have? (Renamed dynamic > > >> libraries shipped separately, shipped as part of Wine, static > > >> libraries, etc...) > > > > > > Adding -static subpackages is the easiest option from our point of > > > view. As I mentioned in the previous email this would mean adjusting > > > an existing spec such as: > > > https://src.fedoraproject.org/rpms/mingw-gnutls/blob/rawhide/f/mingw-gnutls… > > > so that it builds the static library. It's a simple and obvious > > > change. > > > > > > But can Wine use the static library built this way unmodified? > > > And are there any other implications versus using a DLL? > > > > I believe we should be able to use unmodified static libraries, yes. > > > > There are the usual implications—more space on disk and in memory; in > > Wine's case it doesn't really matter a lot, but we do still have cases > > of multiple DLLs that use the same library. It may be possible to use > > helper DLLs to avoid that in most cases. > > > > And, of course, I hate developing with static libraries :-( > > Could you perhaps just build a new dynamic library (with the adjusted > name) by linking an empty/dummy object with the Fedora-provided static > library? (Not sure if that's possible, but it's what came to my mind > when reading this thread.) I doubt this is going to be possible. Windows PE DLLs have some complicated machinery for declaring exported symbols. Plus (like ELF) I imagine the compiler needs to generate quite different code for static vs dynamic. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v

1 0

Re: Wine MinGW system libraries
by Zebediah Figura 07 Sep '21

07 Sep '21

Thanks everyone for their input. There seems to be a consensus that Fedora would prefer that we use their MinGW dynamic libraries. However, this leaves a couple of questions: * As I described in [1], we *may* be able to hack things in the Wine loader such that we can use unmodified dynamic libraries. However, it's not fully clear yet that it's feasible. If it turns out to be infeasible, what preferences does Fedora have? (Renamed dynamic libraries shipped separately, shipped as part of Wine, static libraries, etc...) * Since most other distributions don't ship any mingw libraries (yet), and since Fedora doesn't ship all of the libraries we need yet either, we will probably need to include code in wine to fall back to imported sources or submodules. Is this acceptable to be used in Fedora, at least on a temporary basis? [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…

3 5

Wine MinGW system libraries
by Zebediah Figura 03 Sep '21

03 Sep '21

Hello all, I'm a contributor to the Wine project. To summarize the following mail, Wine needs special versions of some of its normal dependencies, such as libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm sending out a mail to major distributions in order to get some feedback from our packagers on how these should be built and packaged. For a long time Wine has built all of its Win32 libraries (DLLs and EXEs) as ELF binaries. For various reasons related to application compatibility, we have started building our binaries as PE instead, using the MinGW cross-compiler. It is our intent to expand this to some of our dependencies as well. The list of dependencies that we intend to build using MinGW is not quite fixed yet, but we expect it to include and be mostly limited to the following: * libvkd3d * libFAudio * libgnutls * zlib (currently included via manual source import) * libmpg123 * libgsm * libpng * libjpeg-turbo * libtiff * libfreetype * liblcms2 * jxrlib and dependencies of the above packages (not including CRT dependencies, which Wine provides). There is currently some internal discussion about how these dependencies should be built and linked. There are essentially three questions I see that need to be resolved, and while these resolutions have a significant impact on the Wine building and development process, they also have an impact on distributions, and accordingly I'd like to get input from our packagers to ensure that their considerations are accurately taken into account. (1) Should we build via source import, or link statically, or dynamically? Static linking and source imports are dispreferred by Fedora [1] [2], as by many distributions, on the grounds that they cause duplication of libraries on disk and in memory, and make it harder to update the libraries in question (see also question 2). They also make building and bisecting harder. Note however that if they are linked dynamically, we need to make sure that we load our packages instead of MinGW builds of open-source libraries with applications ship with. Accordingly we need each library to be renamed, and to link to renamed dependencies. For example, if application X ships with its own copy of libfreetype-6.dll, we need to make sure that our gdi32.dll links to libwinefreetype-6.dll instead, and that libwinefreetype-6.dll links to libwineharfbuzz-0.dll and winezlib.dll. I think, although I haven't completely verified yet, that this can be done just with build scripts (i.e. no source patches), by using e.g. --with-zlib=/path/to/winezlib.dll. Accordingly, although static linking and source imports are generally disprefered, it may quite likely be preferable in our case. We don't get the benefits of on-disk deduplication, since Wine is essentially the only piece of software which needs these libraries. (2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately? This is mostly a question for packagers, although it also relates to (3). I expect that Fedora (and most distributions) want to answer "packaged separately" here, on the grounds that this lets them update (say) Wine's libgnutls separately, and in sync with ELF libgnutls, if some security fix is needed. There is a snag, though: we need libraries to be copied into the prefix (there's some internal effort to allow using something like symlinks instead, but this hard and not done yet). Normally we perform this copy every time Wine is updated, but if Wine and its dependencies aren't updated on the same schedule, we may end up loading an old version of a dependency in the prefix, thus missing the point of the update. (3) If dependencies are packaged separately, should Wine build them as part of its build tree (e.g. using submodules), or find and link (statically or dynamically) to existing binaries? Linking to existing binaries is generally preferable: it avoids duplication on disk; it reduces compile times when compiling a single package from source (especially the first time). However, we aren't going to benefit from on-disk duplication. And, most importantly, unlike with ELF dependencies, there is no standardized way to locate MinGW libraries—especially if it comes to Wine-specific libraries. We would need a way for Wine's configure script to find these packages—and ideally find them automatically, or else fall back to a submodule-based approach. If we rely on distributions to provide our dependencies, the best idea I have here would be something like a x86_64-w64-mingw32-pkg-config. And if we use shared libraries rather than static, things get worse: we need to know the exact path of each library and its dependencies so that we can copy (or symlink) them into a user's WINEPREFIX. For what it's worth, the current proposed solution (which has the support of the Wine maintainer) involves source imports and submodules. There's probably room for changing our approach even after things are committed, but I'd still like to get early feedback from distributions, and make sure that their interests are accurately represented, before we commit. In short, it's not clear whether distributions want their no-static-library policies to apply to us as well, or whether we're enough of a special case and would be enough of a pain to package that they'd rather we deal with the hard parts, and I don't want us to make any assumptions. ἔρρωσθε, Zebediah [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static… [2] https://fedoraproject.org/wiki/Bundled_Libraries

6 13

Schedule for Thursday's FPC Meeting (2021-09-02 16:00 UTC)
by James Antill 02 Sep '21

02 Sep '21

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2021-09-02 16:00 UTC in #fedora-meeting-1 on irc.libera.chat. Local time information (via. uitime): ================= Day: Thursday ================== 2021-09-02 09:00 PDT US/Pacific 2021-09-02 12:00 EDT --> US/Eastern <-- 2021-09-02 16:00 UTC UTC 2021-09-02 17:00 BST Europe/London 2021-09-02 18:00 CEST Europe/Berlin 2021-09-02 18:00 CEST Europe/Paris 2021-09-02 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2021-09-03 00:00 HKT Asia/Hong_Kong 2021-09-03 00:00 +08 Asia/Singapore 2021-09-03 01:00 JST Asia/Tokyo 2021-09-03 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followup Actions = #topic #pr-814 * mhroncok talk to authors again, having a working example might help a lot = Followup Issues = #topic #886 Enable BRP for detecting RPATH .fpc 886 https://pagure.io/packaging-committee/issue/886 #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #1058 How to handle %lang files in package owned directories? .fpc 1058 https://pagure.io/packaging-committee/issue/1058 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 #topic #pr-1045 WIP: Add discussion of macro names beginning with underscores. https://pagure.io/packaging-committee/pull-request/1045 #topic #pr-1064 Update PIE section https://pagure.io/packaging-committee/pull-request/1064 #topic #pr-1066 Update compiler guidelines for compiler policy change https://pagure.io/packaging-committee/pull-request/1066 #topic #pr-1071 Overhaul the RPATH section of the guidelines. https://pagure.io/packaging-committee/pull-request/1071 #topic #pr-1074 Require deleting unused bundled libraries during %prep https://pagure.io/packaging-committee/pull-request/1074 #topic #pr-1077 Introduce %sysusers_create https://pagure.io/packaging-committee/pull-request/1077 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

2 1

Wiki Package:SourceURL needs the OldGuidelinePage tag
by Otto Urpelainen 02 Sep '21

02 Sep '21

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging September 2021