devel March 2022

devel@lists.fedoraproject.org

191 participants
388 discussions

nodejs-electron
by Andreas Schneider 15 Sep '22

15 Sep '22

Hello! Over the past 8 month, I've been working on getting Electron [1] built on Fedora. Yesterday I was finally able to do the first working build for Fedora Rawhide [2]. This was possible because we finally have ffmpeg [3] in Fedora. My use for Electron is that I want to run signal-desktop [4] on Fedora. You can get electron and signal-packages packages for it at [5]. Is there interest to bring nodejs-electron into Fedora and if yes, would someone be interested to maintain it? I don't have the time to maintain it but I'm happy to help as a co-maintainer. Best regards Andreas [1] https://www.electronjs.org/ [2] https://build.opensuse.org/package/show/network:im:signal/nodejs-electron [3] https://src.fedoraproject.org/rpms/ffmpeg/ [4] https://build.opensuse.org/package/show/network:im:signal/signal-desktop [5] https://download.opensuse.org/repositories/network:/im:/signal/ Fedora_Rawhide/x86_64/

8 25

Planning to start unifying native and mingw packages
by Sandro Mani 03 Sep '22

03 Sep '22

Hi Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants: eigen3 mingw-eigen3 enchant2 mingw-enchant2 freeimage mingw-freeimage gdal mingw-gdal GeographicLib mingw-GeographicLib geos mingw-geos giflib mingw-giflib gtkspell3 mingw-gtkspell3 gtkspellmm30 mingw-gtkspellmm30 jxrlib mingw-jxrlib leptonica mingw-leptonica libgeotiff mingw-libgeotiff libimagequant mingw-libimagequant libkml mingw-libkml librttopo mingw-librttopo libspatialite mingw-libspatialite libwebp mingw-libwebp openjpeg2 mingw-openjpeg2 OpenSceneGraph mingw-OpenSceneGraph osgearth mingw-osgearth podofo mingw-podofo proj mingw-proj python-pillow mingw-python-pillow qtspell mingw-qtspell shapelib mingw-shapelib svg2svgt mingw-svg2svgt tesseract mingw-tesseract uriparser mingw-uriparser I'm performing test builds here [1]. Once I've got them all building there, if there are no objections, I plan to push to F37 and retire all the corresponding mingw repos. Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/

7 27

F37 Change: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards (System-Wide Change)
by Ben Cotton 13 Jul '22

13 Jul '22

https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs == Summary == java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk and java-latest-openjdk packages will no longer build i686 subpackages == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: <jvanek(a)redhat.com> * Product: java and java stack * Responsible WG: java-sig (java and java-maint)(which no longer exists) === Expected schedule === * during march, drop i686 builds from all jdks in fedora rawhide == Detailed Description == Fedora currently ships: * java-1.8.0-openjdk (LTS) * java-11-openjdk (LTS) * java-17-openjdk (LTS) * java-latest-openjdk (STS, jdk18). All those builds on all architectures except jdk8, where arm32 with jit is built by different package. Unluckily, the i686 bit builds of jdk are rotten in upstream. The recent breakage of i686 JIT just before branching nearly killed jdk17 as system jdk feature. The rotting have main visibility with newer GCCs. If GCC bump, and it does, it always triggers new issues in i686 JIT, and there is less and less people to somehow workaround them. Unluckily, there is probably no longer anyone willing to really fix them == Benefit to Fedora == The i686 builds are rotten in usptream, and to patch them localy had become pain. We may be introducing very bugy i686 jdk. Better then to do so, we would rather not ship that at all. This will untie hands of both JDK and GCC developers, who will no longer need to dive into nasty legacy code. == Scope == ==== Change owners ==== * we will simiply stop building i686 pkg in rawhide ==== Other developers ==== * may notice the multilib i686 java missing. * it is up to them to drop i686 builds or to povide workaround (if possible) ==== Other ==== * Release engineering: https://pagure.io/releng/issue/10686 * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * The upgrade on multilib systems will lead to autoremoval of i686 javastack * which should be minimum - 99% of javastack is noarch == How To Test == install i686 java will result to not packages found == User Experience == User experience on multilib systems will be bad. Bad reasonable. == Dependencies == There are is unknown number of multilib java consumers. I expect some of them may rise voice, but that will have to handled one by one. == Contingency Plan == * Contingency mechanism: return i686 packages * Contingency date: (not provided) == Documentation == Will be neded... == Release Notes == None yet... -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

8 13

Claim delve
by Alejandro Saez Morollon 29 Jun '22

29 Jun '22

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

2 2

[HEADS UP] -Wl,--as-needed is added in rawhide
by Igor Gnatenko 26 Jun '22

26 Jun '22

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

4 4

Wine MinGW system libraries
by Zebediah Figura 11 Jun '22

11 Jun '22

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

9 28

What to do with packages that fail to install since Fedora 34 but BZs are ASSIGNED?
by Miro Hrončok 10 Jun '22

10 Jun '22

Hello, during the Fedora 34 development cycle a year ago, I've reported the following buzgillas about packages that don't install: https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED&f1=blocked&f2=b… They were set to ASSIGNED by their maintainers but since then, they still don't install on Fedora 34, Fedora 35 or Fedora 36. I see no point in keeping such packages in the repositories, yet the policy does not currently allow to do anything other than keep them. Should I take some steps, or do we keep building and shipping the broken packages forever? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

5 8

OpenJDK and unremoved directories
by Vitaly Zaitsev 25 May '22

25 May '22

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)

2 1

RHEL moving to issues.redhat.com only long term
by Josh Boyer 18 May '22

18 May '22

Hi Fedora, CentOS, and EPEL Communities! As part of our continued 3 year major Red Hat Enterprise Linux release cadence, RHEL 9 development is starting to wrap up with the spring 2022 release coming soon. That means planning for the next release will start in earnest in the very near future. As some of you may know, Red Hat has been using both Bugzilla and Jira via issues.redhat.com for RHEL development for several years. Our intention is to move to using issues.redhat.com only for the major RHEL releases after RHEL 9. What does this mean for Fedora and CentOS? This discussion is in part to figure that out. Based on some very brief analysis, the following should hold: - RHEL customers should continue to file support cases through the Red Hat Customer portal, which will remain consistent regardless of the backend tooling used. - There is no imminent retirement of the Red Hat Bugzilla instance being planned at this time. RHEL 7, 8, and 9 will continue to use bugzilla in some form and RHEL 9 has a very long lifecycle. - Fedora Linux and EPEL have their own Bugzilla product families and are not directly impacted in their own workflows by the choice to use only issues.redhat.com for RHEL. - There will be impacts on existing documentation that provide guidance on requesting things from RHEL in various places like EPEL. We will be happy to help adjust these. - CentOS Stream contribution and bug reporting workflows will be adjusted to use issues.redhat.com instead of bugzilla in the relevant places. This should apply to all versions of CentOS Stream for a unified contributor workflow. This will happen gradually as we discover the best workflow to use. If there are other impacts that you can think of, please raise them on this thread. We’d like to ensure we’re covering as much as possible as this rolls out. josh

19 32

Uninitialized variables and F37
by Steve Grubb 16 May '22

16 May '22

Hello, This is a continuation of the discussion from F36 Change: GNU Toolchain Update. Uninitialized variables are a big problem. They can be sources of information exposure if parts of a buffer are not initialized. They can also cause unexpected execution paths if the attacker can groom the memory to a value of their choosing. If the variable is a pointer to heap, this can cause free to corrupt memory under certain circumstances. If the uninitialized memory is part of user input, this can lead to improper input validation. This is not hypothetical. All of these come from a paper doing an emprical study of android flaws. [1] The data used in the paper is here. [2] Part of the problem is that compilers and static analysis tools can't always find them. I created a test program that has 8 uses of unintialized variables. Gcc 11 misses all of them. Gcc 12 finds 2. Clang 13 finds 1. cppcheck finds 2 or 3 - but does so much complaining you'd think it found all. Valgrind finds 2. Flexelint, a commercial linter, finds 1. Since tools can't always find them, the only option we have right now is force initialization to something the attacker cannot control. Kees Cook started a discussion on the llvm developers mail list a while back. He makes a very clear argument. I would be repeating his points, so please read the original discussion here (also read the replies): https://lists.llvm.org/pipermail/cfe-dev/2020-April/065221.html He talks about -ftrivial-auto-var-init=zero being used for production builds and -ftrivial-auto-var-init=<pattern> being used for debug builds. The use is not just the kernel. Consider a server that returns data across the network to a client. It could possibly leak crypto keys or passwords if the returned data structure has uninitialized memory. For more background, the creator of this technology for LLVM presented a talk about this feature at a past LLVM developer conference: https://www.youtube.com/watch?v=I-XUHPimq3o He said this would have prevented over 900 fixed CVE's in Chrome and 12% of all Android CVE's. From deep inside the LLVM thread above, comes this nugget: --- To add in, we (Microsoft) currently use zero initialization technology in Visual Studio in a large amount of production code we ship to customers (all kernel components, a number of user-mode components). This code is both C and C++. We already have had multiple vulnerabilities killed because we shipped this technology in production. We received bug reports with repros that worked on older versions of Windows without the mitigation and new versions of Windows that do have it. The new versions don't repro, the old ones do. --- Microsoft is also digging in to uninitialized variables. They have a lengthy blog post that talks about extending this to heap memory. [3] I think this would be an important step forward to turn this on across all compilations. We could wipe out an entire class of bugs in one fell swoop. But then, what about heap allocations? Calloc has existed for a long time. It might be worthwhile to have a CFLAG that can tell glibc (or other allocators) to substitute something like calloc for malloc. Cheers, -Steve [1] - https://picture.iczhiku.com/resource/paper/shkeTWJEaFUuWCMc.pdf [2] - http://ml-papers.gitlab.io/android.vulnerabilities-2017/appendix/ MSR2017/vulnerabilitiesList.html [3] - https://msrc-blog.microsoft.com/2020/07/02/solving-uninitialized-kernel-poo…

17 39

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel March 2022