Re: Kernel / utils-linux update breaks nvidia 390.xx driver dkms build - Any ideas what changed?
On 5/8/24 19:23, Doug Newgard wrote: It's the GCC update, the driver will need patched Thank you Doug! I figured it was something along those lines. It would have taken me a lot more digging to narrow it down! -- David C. Rankin, J.D.,P.E.
Re: Kernel / utils-linux update breaks nvidia 390.xx driver dkms build - Any ideas what changed?
On Wed, 8 May 2024 19:03:33 -0500 "David C. Rankin" wrote: > AUR folks, > >This is a general question that may catch others off guard. Having patch > for the 6.8 changes when the kernel was release and having no issues through > 6.8.9-Arch1, I was very surprised to see build failures in the nvidia-utils > 390.xx package after the today's update. For both Linux and Linux-LTS: It's the GCC update, the driver will need patched
Kernel / utils-linux update breaks nvidia 390.xx driver dkms build - Any ideas what changed?
AUR folks, This is a general question that may catch others off guard. Having patch for the 6.8 changes when the kernel was release and having no issues through 6.8.9-Arch1, I was very surprised to see build failures in the nvidia-utils 390.xx package after the today's update. For both Linux and Linux-LTS: ( 8/13) Install DKMS modules ==> dkms install --no-depmod nvidia/390.157 -k 6.6.30-2-lts Error! Bad return status for module build on kernel: 6.6.30-2-lts (x86_64) Consult /var/lib/dkms/nvidia/390.157/build/make.log for more information. ==> WARNING: `dkms install --no-depmod nvidia/390.157 -k 6.6.30-2-lts' exited 10 ==> dkms install --no-depmod vboxhost/6.1.50_non_OSE -k 6.6.30-2-lts ==> dkms install --no-depmod nvidia/390.157 -k 6.8.9-arch1-2 Error! Bad return status for module build on kernel: 6.8.9-arch1-2 (x86_64) Consult /var/lib/dkms/nvidia/390.157/build/make.log for more information. ==> WARNING: `dkms install --no-depmod nvidia/390.157 -k 6.8.9-arch1-2' exited 10 ==> dkms install --no-depmod vboxhost/6.1.50_non_OSE -k 6.8.9-arch1-2 ==> depmod 6.6.30-2-lts ==> depmod 6.8.9-arch1-2 The actual errors seem like regressions somewhere as similar bugs were fixed in the past 3-4 years for both Nvidia and Vbox. The errors are: In file included from /var/lib/dkms/nvidia/390.157/build/common/inc/conftest.h:5, from /var/lib/dkms/nvidia/390.157/build/common/inc/nv_stdarg.h:29, from /var/lib/dkms/nvidia/390.157/build/common/inc/os-interface.h:27, from /var/lib/dkms/nvidia/390.157/build/nvidia/nv-frontend.c:12: /var/lib/dkms/nvidia/390.157/build/conftest/functions.h:76:2: error: #error wait_on_bit_lock() conftest failed! 76 | #error wait_on_bit_lock() conftest failed! ... /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h: In function ‘nv_ioremap_nocache’: /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h:568:17: error: implicit declaration of function ‘ioremap_nocache’; did you mean ‘ioremap_cache’? [-Wimplicit-function-declaration] 568 | void *ptr = ioremap_nocache(phys, size); | ^~~ /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h:568:17: error: initialization of ‘void *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h: In function ‘nv_ioremap_nocache’: /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h:568:17: error: implicit declaration of function ‘ioremap_nocache’; did you mean ‘ioremap_cache’? [-Wimplicit-function-declaration] 568 | void *ptr = ioremap_nocache(phys, size); | ^~~ | ioremap_cache /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h: In function ‘nv_is_dma_direct’: /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h:1297:9: error: implicit declaration of function ‘dma_is_direct’; did you mean ‘d_is_dir’? [-Wimplicit-function-declaration] 1297 | if (dma_is_direct(get_dma_ops(dev))) | ^ | d_is_dir All of these seem similar to earlier errors from the Linux 5.6 days. Anybody have a guess in what changed in either the new gcc or new util-linux or others that has cause all this fun? -- David C. Rankin, J.D.,P.E.
Re: Package Maintainer application - Bert Peters
Hi Robin, On Wed, 2024-05-08 at 12:30 +0200, Robin Candau wrote: > Nice journey, congrats! Thanks! > > > Yet another Rust fan, they are everywhere! /o\ I'd say there are literally dozens of us, but I just spent the past two days at a conference with a few hundred, so the lower bound needs to be a bit higher. > the only things I can raise at first glance is that some > packages are still using `md5sums` or `sha1sums` where we now > usually prefer a stronger hash algorithm (but here again, that's a > detail) Fixed for everything but 1. git packages as they don't have checksums anyway, and 2. trang, as upstream specifically published SHA1 hashes for release artefacts. > and that the migrant PKGBUILD is skipping checksums because > it is using a git source while makepkg can now generate checksums for > such sources :) (You might as well switch from `commit=commit_hash` > to > `tag=$pkgver`). That's only one of very many issues the migrant package had, and I submitted PRQ#58526 [1] to delete it, though I forgot to remove it from my repo. Did that now! Jakub did point out to me that git sources support checksums now while discussing the plotly PKGBUILD. [2] > I think Bert would be a great addition to the team! Appreciate the reception so far :) Bert. [1]: https://lists.archlinux.org/archives/list/aur-reque...@lists.archlinux.org/message/TTY76AGIK3RCEULJZP6FX277QNURALIU/ [2]: https://aur.archlinux.org/packages/python-plotly signature.asc Description: This is a digitally signed message part
Re: Package Maintainer application - Bert Peters
On 5/5/24 2:18 PM, Bert Peters wrote: Hi all, Hey! My name is Bert Peters, or bertptrs on IRC and various other places, and I'm applying to become a package maintainer for Arch Linux. My application is sponsored by Christian Heusel (gromit) and Jakub Klinkovský (lahwaacz). Thanks for applying, good luck! I started using Linux in 2011 as I started my degree in Computer Science with OpenSuse as that happened to be installed on the computers in the lab, but soon moved to Ubuntu and, after a few false starts in 2014, moved to Arch at the tail end of 2015 by spending most of 33C3 getting things to work just the way I like it and never looked at anything else. Ever since, I've been using it as my daily driver, though I'm also using other distros professionally, currently mainly Ubuntu. Professionally I work as a DevOps engineer, mostly writing yaml, bash, and Python, occasionally wrangling Nix and Ubuntu, and doing packaging for the latter two. I've also previously done RPM packaging for CentOS when I managed my university's data science lab servers. Nice journey, congrats! Privately I'm a big fan of Rust, which I moderate the unofficial channels (##rust, ##rust-offtopic) for on Libera, and I dabble in Ruby because once upon a time I made the decision to write my website in Jekyll. On that website, I try to write the kind tech blog articles that I like to read, explaining a varying collection of things I happened to find interesting at the time. Yet another Rust fan, they are everywhere! /o\ As for existing Arch involvement, I have long been maintaining packages in the AUR, and have been a tester for the last few years. All AUR packages I currently maintain (and that have needed an upgrade somewhere in the last three years) I keep in a Git repository [1] which I manage with aurpublish. I very recently discovered pkgctl how useful pkctl can be, so I started implementing nvchecker recently to automate the maintenance further. My github profile is also a decent record I have of OSS work I did. The PKGBUILDs generally look good! Apart from some really minor things (that are more about "styling" than anything), the only things I can raise at first glance is that some packages are still using `md5sums` or `sha1sums` (e.g. [1]) where we now usually prefer a stronger hash algorithm (but here again, that's a detail) and that the migrant PKGBUILD [2] is skipping checksums because it is using a git source while makepkg can now generate checksums for such sources :) (You might as well switch from `commit=commit_hash` to `tag=$pkgver`). But once again, the PKGBUILDs generally look good! In the time I spend away from keyboard, I do bouldering a lot and I have been teaching windsurfing for the past 15 years. If I were to be voted in as a Package Maintainer, I'd like to move the following packages to \[extra\]: - cargo-cache - jekyll (and deps) - python-plotly In addition, I looked over what current orphans I have installed and I feel confident I know enough about the following to adopt them, though I'm open to more suggestions. - java-commons-lang - libvdpau - lsb-release I'd also like to help out as a co-maintainer on packages I previously maintained in the AUR that have since been adopted into [extra]: - cargo-geiger - cargo-license - nix - nlohmann-json - spotifyd - rust (previously maintained rust-src which was merged into it) - various ruby packages and while I'm at it, I'd like to help out with the Ruby packaging in general, to bring it up to date with Ruby 3.2 and figure out a consistent way to handle Ruby's propensity for very tight version bounds. With that, I hope to have given you a good introduction of myself and my work, where I intend to start packaging, and that there's a good starting point for discussion. Thanks for reading! Nice application! I had the chance to interact with Bert quite a few times on IRC and the interactions always were quite nice. Bert is active in the AUR and testing team as well as in the #archlinux-aur IRC channel, helping others with packaging matters. I think Bert would be a great addition to the team! Bert. P.s. To get ahead of one question, no, the ptrs in my nickname are unrelated to pointers; I got this nickname before I knew what those were. It's just my name with vowels removed. [1]: https://github.com/bertptrs/aur [1] https://github.com/bertptrs/aur/blob/master/netctl2iwd/PKGBUILD#L13 [2] https://github.com/bertptrs/aur/blob/master/migrant/PKGBUILD#L15 -- Regards, Robin Candau / Antiz OpenPGP_0xFDC3040B92ACA748.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
