- Arch-general - lists.archlinux.org

[arch-general] archlinux-java script in java-common package
by 山田ハヤオ 30 Sep '21

30 Sep '21

The archlinux-java script in the java-common package has a lot of code that is inappropriate as a Bash script. (ShellCheck prints a lot of errors.) I have created a patch that fixes these errors with minimal changes. I put the patch on GitHub Gists because it collapses for some reason when I send the patch by email. all.patch is a patch that contains all the changes, and the other files split the changes by function. This is my first time sending a patch to a mailing list, so there may be something wrong with the way it is sent. Patch https://gist.github.com/Hayao0819/bacccc3eebeab73159001f60c9d35a43

3 4

[arch-general] fluxbox update loses wallpaper setting
by David C. Rankin 28 Sep '21

28 Sep '21

All, Really strange. Update to fluxbox 1.3.7+205 out earlier today cased fluxbox to not find the current wallpaper. It appeared to have reverted to an ancient wallpaper no longer on the system. What changed. I've updated fluxbox dozens of times and never seen this before? -- David C. Rankin, J.D.,P.E.

1 0

[arch-general] bug on systemd-cryptenroll
by David Cohen 28 Sep '21

28 Sep '21

Hi, systemd-cryptenroll has a known issue where it may fail if used with fido2. This issue was fixed on upstream, but it was not ported to systemd-stable. Hence we currently have this bug on arch: https://github.com/systemd/systemd/issues/20664 What is the proper way to propose a patch to fix that issue on Arch's systemd? FWIW I tested the patch below on current systemd v249.4 and it fixes the bug. diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD index e4c867f..351ac12 100644 --- a/trunk/PKGBUILD +++ b/trunk/PKGBUILD @@ -7,7 +7,7 @@ pkgname=('systemd' 'systemd-libs' 'systemd-resolvconf' 'systemd-sysvcompat') _tag='91ea8d825553fc1ecfc19448be24a4da56b13d00' # git rev-parse v${_tag_name} _tag_name=249.4 pkgver="${_tag_name/-/}" -pkgrel=1 +pkgrel=2 arch=('x86_64') url='https://www.github.com/systemd/systemd' makedepends=('acl' 'cryptsetup' 'docbook-xsl' 'gperf' 'lz4' 'xz' 'pam' 'libelf' @@ -64,6 +64,8 @@ sha512sums=('SKIP' '825b9dd0167c072ba62cabe0677e7cd20f2b4b850328022540f122689d8b25315005fa98ce867cf6e7460b2b26df16b88bb3b5c9ebf721746dce4e2271af7b97') _backports=( + # fix systemd-cryptenroll using fido2 + 'b6aa89b0a399992c8ea762e6ec4f30cff90618f2' ) _reverts=( Regards, David

1 0

[arch-general] ndiswrapper-dkms: v1.63 with patches and notes
by David Wang 14 Sep '21

14 Sep '21

Greetings, I apologise in advance if this email was sent in the wrong area as I am not familiar with where this should be directed to. ndiswrapper-dkms has been flagged out of date for quite awhile, https://archlinux.org/packages/community/x86_64/ndiswrapper-dkms/ and there has been no updates/news with regards to it. So I decided to tackle the issue. The upstream source indicates v1.63 has been released, https://sourceforge.net/projects/ndiswrapper/files/stable/ however it does not compile against kernel 5.8 or later (as of writing, Arch Linux is up to 5.14.2-arch1-2); https://sourceforge.net/p/ndiswrapper/bugs/272/ and https://sourceforge.net/p/ndiswrapper/discussion/323168/thread/17c9cdb567/?… Initially, I have located a patch from a repository for another Linux distribution, Fedora, https://lists.rpmfusion.org/archives/list/rpmfusion-commits@lists.rpmfusion… Though getting this to work via dkms has been rather tricky, and in my case I have found that the only way to get it compiled was to fully disable NX bit (both 64bit and 32bit), https://en.wikipedia.org/wiki/NX_bit Thereafter, I have noticed another patch, https://github.com/pgiri/ndiswrapper/issues/6#issuecomment-784579834 This patch does not appear to require disabling of NX bit during kernel module compile time, but it probably does require NX bit disabled when loading the compiled kernel module. I do not have any 64bit windows driver that I could use to test against the network hardware that I have. Other than that, it does compile with v1.63 and with kernel 5.14.2-arch1-2. Attached below includes an updated but hackish PKGBUILD, the initial patch, as well as relevant logs. The latter patch can be easily obtained, therefore it is not included. Best regards, David

1 0

[arch-general] dkms (2.8.5-1 -> 2.8.6-1) now old directories left under /var/lib/dkms/vboxhost/?
by David C. Rankin 11 Sep '21

11 Sep '21

All, After upgrade of dkms (2.8.5-1 -> 2.8.6-1), it failed to erase the old directory entries each time a new module was built. In my case with virtualbox, I ended up with: drwxr-xr-x 4 root root 4096 Sep 3 16:00 6.1.24_non_OSE drwxr-xr-x 6 root root 4096 Sep 10 10:42 6.1.26_non_OSE drwxr-xr-x 4 root root 4096 Sep 11 02:29 6.1.27_non_OSE The old entries would cause dkms status to fail with: Error! Could not locate dkms.conf file. File: /var/lib/dkms/vboxhost/6.1.24_non_OSE/source/dkms.conf does not exist. I had to manually remove the 6.1.24_non_OSE and 6.1.26_non_OSE. What happened and what should I check to fix this? -- David C. Rankin, J.D.,P.E.

2 1

[arch-general] Wine MinGW system libraries
by Zebediah Figura 07 Sep '21

07 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? 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 may 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. (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. (Arch does not ship this, although it's available in the AUR [2].) 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] 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. [2] https://aur.archlinux.org/packages/mingw-w64-pkg-config/

1 0

[arch-general] Possible to rebuild a standard package?
by Peter Nabbefeld 05 Sep '21

05 Sep '21

Hello, I'd like to re-build (not just re-install) pyside2 and python-shiboken2 locally. As PKGBUILD (at least for shiboken2) contains cmake instructions, I'd guess this should be easy, but I cannot figure out, how. Kind regards, Peter

4 6

[arch-general] Is it possible to download only one single update from community-testing?
by Peter Nabbefeld 04 Sep '21

04 Sep '21

Hello, I noticed an update on community-testing which is not (yet) available in community repository. Is it possible to download this single package, without downloading full repository index and probably even updating everything to community-update? I looked at https://wiki.archlinux.org/title/Pacman, https://wiki.archlinux.org/title/Frequently_asked_questions#Package_managem…, https://wiki.archlinux.org/title/Pacman/Tips_and_tricks, but it seems I missed sth. Kind regards Peter

5 9

[arch-general] pacman: dvzrv.db 404 error (fwd)
by Jeanette C. 01 Sep '21

01 Sep '21

Hey hey, trying to update/install packages, I encountered this error. I definitely noticed it yesterday night, I can't say when I installed the last package successfully though. pacman -Syyu [...] multilib 149.4 KiB 1572 KiB/s 00:00 [######################] 100% error: failed retrieving file 'dvzrv.db' from pkgbuild.com : The requested URL returned error: 404 error: failed to update dvzrv (failed to retrieve some files) error: failed to synchronize all databases I found similar issues online, but they related to bad mirrors, which pkgbuild.com should not be. Or should it? Anyway, I just updated my mirrorlist, possibly the first time since changing to the 64bit architecture and I did include two pkkgbuild.com mirrors. Does anyone have a suggestion, please? Best wishes, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c Can't make you love me I'm just a girl with a crush on you <3 (Britney Spears)

4 5

[arch-general] Does Blender really (optionally) depends on CUDA?
by Ali Emre Gülcü 01 Sep '21

01 Sep '21

Hello dear Arch community, Blender <https://archlinux.org/packages/community/x86_64/blender/> package in official repositories lists CUDA <https://archlinux.org/packages/community/x86_64/cuda/> as BOTH optional and make dependency, the optional one described as "cycles renderer cuda support". However, Cycles CUDA support is already present even without explicitly installing CUDA package, as long as you have the proprietary NVIDIA <https://archlinux.org/packages/extra/x86_64/nvidia/> drivers installed (don't know the situation with nouveau). As far as I know, CUDA package is only needed while building Blender yourself from the source, hence the make dependency. So my question is, does Blender really depend on CUDA for any additional feature? Or is it simply a legacy dependency or a mistake on packagers' end? Does it serve a purpose that I'm missing? Thanks, Ali Emre Gülcü

1 0