- Arch-general - lists.archlinux.org

[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. 02 Sep '21

02 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

[arch-general] Bluetooth no more working after update
by Peter Nabbefeld 30 Aug '21

30 Aug '21

Hello, after updating my arch installation, bluetooth stopped working. "systemctl status bluetooth" shows the service is active, but when I try to power on or list my bluetooth device using bluetoothctl, no device is found. Head lines of dmesg output: [ 2951.799457] usb 3-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 2953.533019] usb 3-4: USB disconnect, device number 75 [ 2953.811506] Bluetooth: hci0: command 0x0c03 tx timeout [ 2956.823879] audit: type=1131 audit(1629640847.196:664): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 2961.918096] Bluetooth: hci0: sending initial HCI reset command failed (-110) [ 2961.926281] audit: type=1130 audit(1629640852.299:665): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 2962.174751] usb 3-4: new full-speed USB device number 76 using xhci_hcd [ 2962.298118] usb 3-4: device descriptor read/64, error -71 [ 2962.528098] usb 3-4: device descriptor read/64, error -71 [ 2962.761408] usb 3-4: new full-speed USB device number 77 using xhci_hcd [peter@tuchola ~]$ sudo dmesg | head -n 20 [ 2999.934381] usb 3-4: new full-speed USB device number 88 using xhci_hcd [ 3000.057683] usb 3-4: device descriptor read/64, error -71 [ 3000.287770] usb 3-4: device descriptor read/64, error -71 [ 3000.517708] usb 3-4: new full-speed USB device number 89 using xhci_hcd [ 3000.641059] usb 3-4: device descriptor read/64, error -71 [ 3000.871018] usb 3-4: device descriptor read/64, error -71 [ 3000.977743] usb usb3-port4: attempt power cycle [ 3001.381075] usb 3-4: new full-speed USB device number 90 using xhci_hcd [ 3001.381293] usb 3-4: Device not responding to setup address. [ 3001.587720] usb 3-4: Device not responding to setup address. [ 3001.794365] usb 3-4: device not accepting address 90, error -71 [ 3002.124364] usb 3-4: new full-speed USB device number 91 using xhci_hcd [ 3002.142567] usb 3-4: New USB device found, idVendor=8087, idProduct=07dc, bcdDevice= 0.01 [ 3002.142573] usb 3-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 3003.876301] usb 3-4: USB disconnect, device number 91 [ 3004.157679] Bluetooth: hci0: command 0x0c03 tx timeout [ 3007.165585] audit: type=1131 audit(1629640897.539:672): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 3012.264321] Bluetooth: hci0: sending initial HCI reset command failed (-110) [ 3012.273674] audit: type=1130 audit(1629640902.646:673): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 3012.520945] usb 3-4: new full-speed USB device number 92 using xhci_hcd My bluetooth device: Bus 003 Device 103: ID 8087:07dc Intel Corp. Bluetooth wireless interface "lsusb -v" shows lots of details, e.g. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth bMaxPacketSize0 64 idVendor 0x8087 Intel Corp. idProduct 0x07dc Bluetooth wireless interface bcdDevice 0.01 iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1 ... but ends with the following lines: can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable cannot read device status, No such device (19) I guess there's sth. broken with the driver (or now driver assigned at all). When looking into /usr/lib/firmware, I see many if not all updates of August, 18th, and especially many files with pattern "iwlwifi-*.ucode", which might related to my problem. I already searched the internet, but couldn't find anything useful :-/ However, I found this: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1591167 While it seems not to be the same, it led me to looking for ibt-*.* and especially to https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git… I found those files locally in /usr/lib/firmware/intel, same date for latest update as for "iwlwifi-*.ucode", so everything should usually be fine. How can I check, if the firmware has been installed/loaded properly? How can I find out, which is the correct firmware? Kind regards Peter

3 9

[arch-general] Fluidsynth Plugin for VLC media player
by 山田ハヤオ 26 Aug '21

26 Aug '21

Add --enable-fluidsynth to PKGBUILD in the vlc package in the official repository. Consider adding the FluidSynth plugin to support Midi playback in the official repository. If you can't do that, please tell me why.

3 4

[arch-general] PyJWT 2.0+
by Marcus Hoffmann 21 Aug '21

21 Aug '21

Hi, I wanted to ask if anyone knows what's up with updating https://archlinux.org/packages/?q=python-pyjwt to v2.0+. v2.0 has been released last December, and there's been a bunch of minor versions since. I realize this has a bunch of dependent packages, is there anything in particular blocking this? Mostly asking because I adopted python-social-auth-core in the AUR which depends on pyjwt 2.0+ since January this year. (others say it works fine for them with the older version, but I'm hesitant to ignore upstreams version range suggestion.) Best, Marcus

2 1