October 2021 - devel - Fedora Mailing-Lists

RISC-V -- are we ready for more, and what do we need to do it?

by Matthew Miller

Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk. In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck). So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that. But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time? * see http://fedora.riscv.rocks/koji/ -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

1 day, 18 hours

19
38
0 / 0

Conflicting build-ids in nekovm and haxe

by Andy Li

Hi list, Re. https://bugzilla.redhat.com/show_bug.cgi?id=1896901 Since haxe-4.1.3-4 and nekovm-2.3.0-4, both nekovm and haxe packages contains "/usr/lib/.build-id/b0/aed4ddf2d45372bcc79d5e95d2834f5045c09c". The nekovm one is a symlink to "/usr/bin/neko". The haxe one to "/usr/bin/haxelib". Both the neko and haxelib binaries are built with libneko, with a nearly identical main.c with the only difference of the present of neko bytecode embedded as a byte array (neko: the byte array is null; haxelib: the byte array is the haxelib neko bytecode). I'm not sure how to resolve it. Please advice. Best regards, Andy

3 weeks, 5 days

5
6
0 / 0

can't install package pipewire-jack-audio-connection-kit

by Martin Gansser

Hi, when trying to install pipewire-jack-audio-connection-kit i get this error message: # dnf -y install pipewire-jack-audio-connection-kit Last metadata expiration check: 1:39:52 ago on Thu Dec 31 14:10:39 2020. Error: Problem: problem with installed package jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - conflicting requests - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages) How can i fix this ? Regards Martin

2 months, 3 weeks

11
17
0 / 0

x86_64-v2 in Fedora

by Neal Gompa

Hey all, Earlier this week, I was helping with processing features for openSUSE Leap 15.4[1] and I discovered that they're planning on introducing x86_64-v2 to openSUSE soon. The reference for this change was that RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions have been considering bumping up to v2 or v3[3][4]. Some cursory examination of the new x86_64 sublevels seem to indicate that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the first couple of generations of x86_64 CPUs from Intel and AMD. I personally don't have any computers that don't have support for x86_64-v2 anymore. Does anyone know if anyone is planning to propose this for Fedora anytime soon, either as an addon architecture (like what Arch is doing) or an upgrade of our x86_64 baseline like RHEL is doing? [1]: https://en.opensuse.org/Feature_Planning_15.4 [2]: https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise... [3]: https://ml.mageia.org/l/arc/dev/2021-02/msg00583.html [4]: https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-x86-64-v3-... -- 真実はいつも一つ！/ Always, there's only one truth!

4 months

32
61
2 / 0

[apt-cacher-ng] Resurrect dead package

by Frédéric Pierret

Hi, I've resurrected `apt-cacher-ng` on my fork: https://src.fedoraproject.org/fork/fepitre/rpms/apt-cacher-ng/c/06340bafb... with successful builds on my testing COPR repository for F32+ and EPEL8: https://copr.fedorainfracloud.org/coprs/fepitre/fedora/build/1879178/. I plan to (already) use this package for my current work on reproducible builds. Is the procedure described in https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers... still available for such case? Thank you. Best regards, Frédéric Pierret

5 months, 1 week

3
3
0 / 0

fedpkg clone fails with Permission denied (publickey).

by Richard Shaw

Long story short I lost my home directory where I do all of my packager activities (separate from my main user) so I'm setting things up from scratch. I created new ssh keys and uploaded the public key to admin.fedoraproject.org and pasted into pagure.io. It's been over an hour and I'm still getting: $ fedpkg clone hamlib Cloning into 'hamlib'... hobbes1069(a)pkgs.fedoraproject.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Could not execute clone: Failed to execute command. I've also updated my API tokens, which is STILL not well documented. I pasted them in the appropriate spot in "/etc/rpkg/fedpkg.conf" which isn't real intuitive. Thanks, Richard

6 months, 1 week

5
10
0 / 0

Claim delve

by Alejandro Saez Morollon

Hi there, folks. Delve[0] (a Golang debugger) was retired due to the impossibility of building a new version of delve for dependencies issues. I would like to claim the package and fix the situation. I already have one of the dependencies[1] in the works. I already talked with the original maintainer (he's in cc) and he is OK with it. Thanks. [0] https://src.fedoraproject.org/rpms/delve [1] https://src.fedoraproject.org/rpms/golang-starlark

11 months, 1 week

2
2
0 / 0

[HEADS UP] -Wl,--as-needed is added in rawhide

by Igor Gnatenko

It's in redhat-rpm-config-118-1.fc30. If it causes any problems for you - let me know. In the meantime, you can use `%undefine _ld_as_needed` to disable it. Thanks for attention! -- -Igor Gnatenko

11 months, 1 week

4
4
0 / 0

Wine MinGW system libraries

by Zebediah Figura

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-stat... [2] https://fedoraproject.org/wiki/Bundled_Libraries

11 months, 3 weeks

9
28
0 / 0

OpenJDK and unremoved directories

by Vitaly Zaitsev

Hello. I have a lot of unremoved directories and files in /usr/lib/jvm/: $ ls -l /usr/lib/jvm/ total 140 drwxr-xr-x. 5 root root 4096 Sep 10 14:32 java-11-openjdk-11.0.12.0.7-4.fc34.x86_64 drwxr-xr-x. 3 root root 4096 Mar 14 2017 java-1.8.0-openjdk-1.8.0.121-10.b14.fc25.x86_64 drwxr-xr-x. 3 root root 4096 Apr 21 2017 java-1.8.0-openjdk-1.8.0.131-1.b12.fc25.x86_64 drwxr-xr-x. 3 root root 4096 Oct 25 2017 java-1.8.0-openjdk-1.8.0.151-1.b12.fc26.x86_64 drwxr-xr-x. 3 root root 4096 Oct 25 2017 java-1.8.0-openjdk-1.8.0.151-1.b12.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Jan 24 2018 java-1.8.0-openjdk-1.8.0.161-0.b14.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Feb 6 2018 java-1.8.0-openjdk-1.8.0.161-5.b14.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Mar 29 2018 java-1.8.0-openjdk-1.8.0.162-3.b12.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Apr 18 2018 java-1.8.0-openjdk-1.8.0.171-1.b10.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Apr 25 2018 java-1.8.0-openjdk-1.8.0.171-4.b10.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Apr 25 2018 java-1.8.0-openjdk-1.8.0.171-4.b10.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Jul 3 2018 java-1.8.0-openjdk-1.8.0.172-12.b11.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Jun 18 2018 java-1.8.0-openjdk-1.8.0.172-9.b11.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Jul 23 2018 java-1.8.0-openjdk-1.8.0.181-7.b13.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Sep 5 2018 java-1.8.0-openjdk-1.8.0.181.b15-0.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Oct 4 2018 java-1.8.0-openjdk-1.8.0.181.b15-5.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Oct 11 2018 java-1.8.0-openjdk-1.8.0.181.b15-6.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Oct 11 2018 java-1.8.0-openjdk-1.8.0.181.b15-6.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Nov 29 2018 java-1.8.0-openjdk-1.8.0.191.b12-11.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Nov 1 2018 java-1.8.0-openjdk-1.8.0.191.b12-8.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Jan 14 2019 java-1.8.0-openjdk-1.8.0.191.b13-0.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Feb 6 2019 java-1.8.0-openjdk-1.8.0.201.b09-2.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Mar 26 2019 java-1.8.0-openjdk-1.8.0.201.b09-6.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Apr 23 2019 java-1.8.0-openjdk-1.8.0.212.b04-0.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Apr 23 2019 java-1.8.0-openjdk-1.8.0.212.b04-0.fc30.x86_64 drwxr-xr-x. 3 root root 4096 Jul 31 2019 java-1.8.0-openjdk-1.8.0.222.b10-0.fc30.x86_64 drwxr-xr-x. 3 root root 4096 Oct 16 2019 java-1.8.0-openjdk-1.8.0.232.b09-0.fc30.x86_64 drwxr-xr-x. 3 root root 4096 Oct 16 2019 java-1.8.0-openjdk-1.8.0.232.b09-0.fc31.x86_64 drwxr-xr-x. 3 root root 4096 Jan 28 2020 java-1.8.0-openjdk-1.8.0.242.b08-0.fc31.x86_64 drwxr-xr-x. 3 root root 4096 Mar 23 2020 java-1.8.0-openjdk-1.8.0.242.b08-1.fc32.x86_64 drwxr-xr-x. 3 root root 4096 May 4 2020 java-1.8.0-openjdk-1.8.0.252.b09-0.fc32.x86_64 drwxr-xr-x. 3 root root 4096 May 22 2020 java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64 drwxr-xr-x. 3 root root 4096 Jul 17 2020 java-1.8.0-openjdk-1.8.0.262.b10-1.fc32.x86_64 drwxr-xr-x. 3 root root 4096 Jul 28 2020 java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64 drwxr-xr-x. 3 root root 4096 Oct 21 2020 java-1.8.0-openjdk-1.8.0.272.b10-0.fc32.x86_64 lrwxrwxrwx. 1 root root 21 Sep 10 14:32 jre -> /etc/alternatives/jre lrwxrwxrwx. 1 root root 24 Sep 10 14:32 jre-11 -> /etc/alternatives/jre_11 lrwxrwxrwx. 1 root root 32 Sep 10 14:32 jre-11-openjdk -> /etc/alternatives/jre_11_openjdk lrwxrwxrwx. 1 root root 41 Aug 31 18:50 jre-11-openjdk-11.0.12.0.7-4.fc34.x86_64 -> java-11-openjdk-11.0.12.0.7-4.fc34.x86_64 lrwxrwxrwx. 1 root root 29 Sep 10 14:32 jre-openjdk -> /etc/alternatives/jre_openjdk I think the OpenJDK's scriplets need to be adjusted to remove everything. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

1 year

2
1
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel October 2021