April 2020 - Arch-general - lists.archlinux.org

[arch-general] Packages "jami-gnome" and "libjamiclient" out of date
by Friedrich Strohmaier 24 Oct '20

24 Oct '20

Hi archers, Packages "jami-gnome" and "libjamiclient" are flagged out of date since 2019-11-16 / 2019-11-20. There are two new releases in place. I tried to contact the maintainer twice but nothing happened. I retrieved the maintainers (Bruno Pagani) mail adress from this mailinglist. I suspect the mails didn't ever get there. Any hints how to proceed? -- Friedrich

3 5

Re: [arch-general] NFS "updates"?
by Amin Vakil 06 May '20

06 May '20

> >> But to tell the users to discuss this upstream is bad advice. This is a >> situation where a distribution should take corrective action by >> reverting this configuration. This would add value and remove some >> useless code from the kernel. > No. If you want a distribution whose maintainers think it is a good > think to "correct" upstream decisions, you should use not Arch. > So there isn't a single package in Arch Linux which trusted users have changed them in order to fix an issue which they thought it's better this way? If there is/was a package what is/was it and why?

2 1

[arch-general] [Re: arch-general] Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
by Lone_Wolf 30 Apr '20

30 Apr '20

On 30-04-2020 09:56, Anatol Pomozov wrote: > Hi Morten > > On Sun, Apr 19, 2020 at 3:32 PM Morten Linderud via arch-dev-public > <arch-dev-public(a)archlinux.org> wrote: >> Yo! >> >> After being lazy for a few weeks, I got around to writing the new guidelines for >> Go packages. Currently it's a draft and I'd love if people read through it and >> ack/nacked >> >> https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines > Thank you for coming up with this document. > > Go is a fantastic language and I would love to see more people using > it. Having things documented will help our users to get more > comfortable with the golang packaging. > >> The current changes is dropping anything pre-1.11 completely. I don't see the >> need to detail the GOPATH hacks as new packages should be using go modules, and >> existing packages is moving to go modules. > +1. The current "go modules" implementation is so much more superior > to what Golang had before. "go modules" is the default option > nowadays. > >> The other changes is explicitly listing up the needed CGO_* variables needed. >> Levente pointed out CGO_CFLAGS is still needed for FORTIFY_SOURCE, so for the >> sake of completeness it's all listed. >> >> I have also removed `-mod=vendor` from the default listing in `prepare()` as >> Anatol wasn't fond of the idea. I'm still unsure if we really want this as we >> would be willynilly downloading sources in `build()` and `check()` during >> packaging. > My concern was related to use of vendorized sources. "-vendor" was not > created for the cache management. If one wants to warmup the gomodules > download cache then "go mod download" should be used. See more info > about this tool here https://github.com/golang/go/issues/26610 > > And if we plan to encourage adding the cache warmup to all golang > PKGBUILD (that's gonna be thousands of packages) then this extra > complexity need be justified. Anyone who wants to follow our advise > needs to have clear answers to following questions: Is this feature > solely to avoid the download during the build() step or there is > something else? Why downloading in build() is bad, does it hurt the > users? What use-cases does show an advantage of the cache warmup.. > etc.. Answering on arch-general as only devs can post on arch-dev-public. (hope I haven't broken the mail thread) TL;DR : yes, downloading in build hurts users. downloads during build() using gomodules are - unpredictable as packager has no control over what is downloaded - break reproducible builds because of their unpredictable nature. Some other comments - arch-meson disables downloads by default. - most (all ?) packagers that use meson directly use --nowrap to prevent downloads. - in the past VCS sources were downloaded in build() . pacman devs invested lots of time and effort to allow controlling them through source array. - git submodules work in a similar way . The VCS packaging guidelines wiki page describes how to download the submoduile sources through source array and add them manually in prepare(). This allows packagers to follow upstream intent but stay in control. - gomodules are source files. If they need to be downloaded that should happen in prepare() , not build() . Lone_Wolf

1 0

[arch-general] NFS "updates"?
by Hauke Fath 30 Apr '20

30 Apr '20

All, we have a group of Arch desktop clients that mount their user homes and group shares through nfsv3 over udp from an OmniOS server. After today's update (the last one was on 9 Mar) the machine will not nfs-mount, complaining about illegal udp, grpid, int mount options, and the kernel spits out a NFSV4: Unsupported transport protocol udp although nothing on this installation anywhere ever has used nfsv4 until now, and /etc/default/autofs explicitly specifies nfsv3. Editing /etc/nfsmount.conf (which was in default state until now) accordingly did not make a difference. I couldn't find any nfs related Arch news items. What did I miss? Cheerio, Hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344

6 16

[arch-general] foldingathome-beta almost working
by Jude DaShiell 24 Apr '20

24 Apr '20

The beta runs and complains it can't find opencl driver running on slot 1. Entirely reasonable since the computer foldingathome uses is running on slot 2. Does a way exist to redirect opencl to run on slot 2 where foldingathome can use it and return a status report with no failures and no errors in it? Me using a screen reader I don't have much occasion to do things with video drivers. The monitor I use is compatible with opencl-mesa not nvidia if that helps. --

1 0

[arch-general] Hibernation Failure
by Paul Dann 23 Apr '20

23 Apr '20

I'm having trouble getting hibernation to work on my new Dell Inspiron 7590. It seems that the image is stored correctly (onto LUKS+LVM thin-lv), but resume fails, with the following left in the kernel logs: --- PM: Image signature found, resuming PM: resume from hibernation Freezing user space processes ... (elapsed 0.001 seconds) done. OOM killer disabled. PM: Marking nosave pages: [mem 0x00000000-0x00000fff] PM: Marking nosave pages: [mem 0x0009e000-0x0009efff] PM: Marking nosave pages: [mem 0x000a0000-0x000fffff] PM: Marking nosave pages: [mem 0x40000000-0x403fffff] PM: Marking nosave pages: [mem 0x66797000-0x66798fff] PM: Marking nosave pages: [mem 0x761f7000-0x791fefff] PM: Marking nosave pages: [mem 0x79200000-0xffffffff] PM: Basic memory bitmaps created PM: Using 3 thread(s) for decompression PM: Loading and decompressing image data (1343374 pages)... PM: Image loading progress: 0% PM: Image loading progress: 10% PM: Image loading progress: 20% PM: Image loading progress: 30% PM: Image loading progress: 40% PM: Image loading progress: 50% PM: Image loading progress: 60% PM: Image loading progress: 70% PM: Image loading progress: 80% PM: Image loading progress: 90% PM: Invalid LZO compressed length PM: Read 5373496 kbytes in 6.35 seconds (846.21 MB/s) PM: Error -1 resuming PM: Failed to load hibernation image, recovering. PM: Basic memory bitmaps freed OOM killer enabled. Restarting tasks ... done. PM: resume from hibernation failed (-1) --- And then the system boots fresh. An internet search revealed absolutely nothing about the "Invalid LZO compressed length", and I've no idea why the image would be corrupt. I'd appreciate any ideas. Paul

3 8

[arch-general] Dynamic IPs change after reboot when dhcpcd-9.0.1-2 installed?
by David C. Rankin 23 Apr '20

23 Apr '20

I have noticed an issue that update of dhcpcd in the past day or two causes the server running dhcpd to hand out a different IP. The resolv.conf is unchanged - unlike the bug https://bugs.archlinux.org/task/66313?project=1&string=dhcpcd&order=dateope… The fact that the IP changes isn't itself a problem, the fact that it has not behaved like this before is. The side-effect impacts updating Arch boxes across a LAN. You may find yourself unable to connect after a kernel update and reboot when the box comes back up with a different IP. The problem being any local IP caching on the machine being used to do remote updates won't see the change until the lease expires. (or the local nameresolution cache is flushed/restarted -- depends on box and distro used to access the remote Arch box). Has anybody else seen this? Also, if you know, is this just a one-off change with the new package that won't repeat each time dhcpcd or the kernel is updated going forward? -- David C. Rankin, J.D.,P.E.

1 0

[arch-general] foldingathome-beta fails
by Jude DaShiell 20 Apr '20

20 Apr '20

The packagebuild does not download and install all dependencies for foldingathome-client so cannot operate on systems that have used foldingathome predecessor software like foldingathome-noroot. I figured it might work since I had configured foldingathome-client earlier and had a valid configuration but no such luck. So I will be cleaning this package and all predecessor packages and associated data from this system. --

1 0

[arch-general] hostapd and systemd-networkd ordering cycle
by Joan Aymà 19 Apr '20

19 Apr '20

Hi, I have a bridge configured through systemd-networkd and a wifi AP with hostpad. The wifi AP interface is attached to the bridge by systemd-networkd. There is a ordering cycle that is: network.target -> systemd-networkd.service -> hostapd.service -> network.target (btw I used https://github.com/jantman/misc-scripts/blob/master/dot_find_cycles.py to helpful debug it.) The unit file of the hostapd has (only pasted relevant info): [Unit] *After=network.target* [Install] WantedBy=multi-user.target That's it. Bu if I create a /etc/systemd/system/hostapd.service.d/after.conf with: [Unit] After= *After=network-pre.target* It never overrides the cycle (it's read but the After is not overridden). If I create a /etc/systemd/system/hostapd.conf with the difference above the it works fine and no ordering cycle. Should I open a PR to fix the /lib/systemd/system/hostapd.service? How? Thanks, Joan.

2 1

[arch-general] Warning: both linux 5.6.5 and linux 5.4.33 LTS are broken for AMD users.
by fredbezies 19 Apr '20

19 Apr '20

Hello. If you're using an AMD GPU, you won't be able to shutdown or reboot correctly your computer. This is a known issue on kernel bug tracker : https://bugzilla.kernel.org/show_bug.cgi?id=207331 And I reported it on Archlinux bug tracker too: https://bugs.archlinux.org/task/66305 I tested proposed patch, and it works. So let's hope for a fixed kernel either from kernel hackers or Archlinux maintainers. -- Frederic Bezies fredbezies(a)gmail.com

1 0