September 2021 - openSUSE Packaging - openSUSE Mailing Lists

factory-auto declines factory submission for no good reason
by Hans-Peter Jansen 17 Sep '21

17 Sep '21

[Sorry for cross post, disabled auto line breaks for beetter readability] Good morning, could some kind soul explain this current behavior of factory-auto: Original Subject: Re: Request 919620 changed from review to declined (submit openSUSE:Factory/freerdp) Am Freitag, 17. September 2021, 07:35:53 CEST schrieb Factory Auto: > Visit https://build.opensuse.org/request/show/919620 > > State of request 919620 was changed by factory-auto: > > review -> declined > > Comment: > Output of check script: > Attention, FreeRDP-2.4.0.tar.gz is not mentioned in spec files as source or > patch. Attention, freerdp-builtin-channels-off-link-fix.diff is not > mentioned in spec files as source or patch. Attention, freerdp-rpmlintrc is > not mentioned in spec files as source or patch. > > > Actions: > - submit X11:RemoteDesktop/freerdp => openSUSE:Factory/freerdp specifically since: * FreeRDP-2.4.0.tar.gz is mentioned in line 45: Source0: https://github.com/FreeRDP/FreeRDP/archive/%{version}.tar.gz#/FreeRDP-%{ver… * freerdp-builtin-channels-off-link-fix.diff is mentioned in line 48: # PATCH-FIX-UPSTREAM freerdp-channels-off-link-fix.diff -- based on https://github.com/FreeRDP/FreeRDP/pull/7235 Patch0: freerdp-builtin-channels-off-link-fix.diff * and finally freerdp-rpmlintrc in line 46: Source1: freerdp-rpmlintrc See: https://build.opensuse.org/package/view_file/X11:RemoteDesktop/freerdp/free… Guess, auto-factory needs new glasses from its optician of choice ;-) Best, Pete

3 2

python-singlespec - how to deal with scripts
by Axel Braun 14 Sep '21

14 Sep '21

Hi, I need some advise on how to deal with scrpits that come with a python package and are inteded to end up in %{_bindir} The package in question - python-relatorio 0.10.0 - is build for python2 and 3 1) How to deal with the shebang in the script, which is currently /usr/bin/env python ? 2) how to call the %files section properly? %{_bindir}/relatorio-render causes the rpm check to fail as it is packed three times (for python36, 38 and 39) %python_for_executables %{_bindir}/relatorio-render throws an error as well...... Hints welcome.....thank you!

2 2

Wine MinGW system libraries
by Zebediah Figura 10 Sep '21

10 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 openSUSE [1] [2], on the grounds that they make it harder to handle security updates. They also take up more space on disk, and 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. There's some internal discussion about whether this is possible while using "stock" builds of MinGW libraries, but, due to the way the Win32 loader works, we will probably need to compile each library, and its dependencies, with a separate, wine-specific name, e.g. "libwinefreetype-6.dll" and "libwineharfbuzz.dll". For a detailed explantion see footnote [3]. Note that all we actually need to change is the name; we don't need to patch the source. 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). (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. There is a MinGW version of pkg-config shipped by many distributions, which lets us find libraries, but there's no standardized way to find them at runtime. (Also, as far as I can tell, openSUSE doesn't build MinGW pkg-config? I couldn't seem to find it anywhere. That could be trivially solved, though.) 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. ἔρρωσθε, Zebediah [1] https://en.opensuse.org/openSUSE:Packaging_guidelines#Bundling_of_multiple_… [2] https://en.opensuse.org/openSUSE:Packaging_guidelines#Static_Libraries [3] The basic problem is that applications can and often do ship with PE builds of cross-platform libraries. These libraries can be ahead of Wine's system libraries, behind them, or even built with custom patches. Accordingly we really don't want to load "our" freetype in place of "their" freetype, or "theirs" in place of "ours". But because of the way the Win32 loader works, you can generally only have one DLL of a given name loaded in a process, and further attempts to dlopen() [as it were] "libfreetype-6.dll" will return the handle to the already loaded library, potentially breaking either Wine or the application. There *may* be ways we can hack around this internally, but it's not clear that it's feasible yet, and so it's probably best to assume that we'll need special builds of dynamic libraries.

7 17

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

09 Sep '21

(Sorry, I accidentally hit send before I was done composing...) On 9/8/21 6:35 PM, Aaron Puchert wrote: >> The list of dependencies that we intend to build using MinGW is no > 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 > What puts a dependency on this list? Wine will typically also use the > graphics stack, typically provided by Mesa. Why is that not included? > > Here is my very limited understanding of Wine: the <arch>-windows > directory provides DLLs that a Windows application might need. These are > regular PE libraries so that Windows applications don't get confused. > Internally some of these libraries load libraries from <arch>-unix, but > these aren't exposed to the Windows application. So they can be ELF > executables, which in turn enables them to link system libraries, > including those from the above list. That seems like a pretty clean > design, although I don't know which problems it might produce. > > Now let's say we have something like libfreetype as PE, hence also most, > if not all libraries in <arch>-unix. Then we could use a unified loader, > but applications might see all these implementation details. > Additionally, you'll likely still need to load ELF libraries at some > point, because I don't think you'll want to build your own Mesa, LLVM, > and all that comes with it. > Yes, we still need to load actual ELF code. The determining questions are something like: (1) Is it easy to compile in PE format? (2) Does it need to interact with the host system, say, in terms of configuration files? (3) Does it need to call down into the OS at some level, in ways that Windows can't replicate? So anything that interacts with devices is right out (Mesa, audio libraries, libusb, udev, libSDL as used for gamepads, v4l2, gphoto2, cups, sane ...). fontconfig can be built PE (and I've seen applications in the wild use it) but we need it to detect *host* fonts. GStreamer can be built PE, but we want to use host codecs where possible (also, Wine will probably end up shipping statically compiled libraries if only as a fallback, and I think we don't want to distribute patent-encumbered codecs.)

1 0

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

09 Sep '21

On 9/8/21 6:35 PM, Aaron Puchert wrote: > Am 07.09.21 um 01:36 schrieb Zebediah Figura: >> For a long time Wine has built all of its Win32 libraries (DLLs and >> EXEs) as ELF binaries. > Wait, so I have two directories with libraries: > * /usr/lib64/wine/x86_64-unix/ containing according to "file": "ELF > 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked". > * /usr/lib64/wine/x86_64-windows/ containing according to "file": "PE32+ > executable (DLL) (console) x86-64, for MS Windows" plus some non-libraries. > > So I assume we're only talking about the <arch>-unix directory, right? Sort of. I'm mainly trying to give historical context in explaining why there are even PE-format DLLs, but I didn't explain well enough. Let me try to clarify. It used to be that all libraries were built in ELF format, and sort of converted to PE format in memory on the fly. They have an export table identical to their Windows counterpart, and are named with a ".dll.so" suffix. For reasons described in [1] from this thread, we started converting these DLLs into actual PE format, by compiling them with the MinGW cross-compiler, and loading them into memory the same way we load PE DLLs. Cross-compiled DLLs have the sufix ".dll". Most such DLLs could use Wine's CRT libraries (msvcrt.dll) and didn't need to call into Unix code. Some did need to call into Unix code (most of the core parts of the Windows kernel, but also stuff like GStreamer or 3D acceleration libraries). We can't just call Unix code from a DLL (for reasons I'll try to explain below) so these got split into two pieces, one ending in ".dll" and one ending in ".so". In this case the DLL loads the .so through some internal APIs and does what are essentially fake syscalls to it. Currently most, but not all, libraries have been converted or split in this way. The x86_64-unix directory holds both the libraries that haven't been split, and the .so parts of the libraries that have. I.e. it holds both .dll.so and .so files. The x86_64-windows directory holds the PE parts of the libraries that have been converted or split, i.e. it holds the .dll files. The PE system dependency question is what stands in the way of converting most of the libraries that haven't been split yet. [1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/… > >> The list of dependencies that we intend to build using MinGW is no > 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 > What puts a dependency on this list? Wine will typically also use the > graphics stack, typically provided by Mesa. Why is that not included? > > Here is my very limited understanding of Wine: the <arch>-windows > directory provides DLLs that a Windows application might need. These are > regular PE libraries so that Windows applications don't get confused. > Internally some of these libraries load libraries from <arch>-unix, but > these aren't exposed to the Windows application. So they can be ELF > executables, which in turn enables them to link system libraries, > including those from the above list. That seems like a pretty clean > design, although I don't know which problems it might produce. > > Now let's say we have something like libfreetype as PE, hence also most, > if not all libraries in <arch>-unix. Then we could use a unified loader, > but applications might see all these implementation details. > Additionally, you'll likely still need to load ELF libraries at some > point, because I don't think you'll want to build your own Mesa, LLVM, > and all that comes with it. Yes, we still need to load actual ELF code. The determining questions are something like: (1) Is it easy to compile in PE format? (2) Does it need to interact with the host system, say, in terms of configuration files? (3) Does it need to call down into the OS at some level, in ways that Windows can't replicate? So anything that interacts with devices is right out (Mesa, audio libraries,

1 0

python3-pip package
by Michael Kasimir 08 Sep '21

08 Sep '21

Hi all, within this e-mail I'd like to inquire why the actual available package: python-pip-10.0.1-lp152.4.6.1.src.rpm is completely outdated. An update fails with the message: You are using pip version 10.0.1, however version 21.2.4 is available. I could not find out under https://build.opensuse.org/search?search_text=python3-pip, any available update. Incomprehensible is also for me, why there is such a high difference in the release number (10.0.1 ---> 21.2.4), nor who is current maintainer for this package. Would it be possible to make an update for this package available? Kind regards M

4 17

graphics/blender has no bugowner
by Mathias Homann 07 Sep '21

07 Sep '21

Hi guys, could someone please define a bugowner for graphics/blender? factory-maintainers, if nothing else? Right now its impossible to file a big against the package from wihin OBS - there is no "report a bug" link. Cheers Mathias -- Mathias Homann Mathias.Homann(a)openSUSE.org telegram: https://telegram.me/lemmy98 irc: [lemmy] on freenode and ircnet obs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

3 2