Re: [arch-general] darktable libavif libyuv update and undefined symbol
On 12/22/20 10:55 AM, Juergen Werner via arch-general wrote: ... Try libyuv-r2212+dfaf7534-2. Looks like that might fix your problem. Yes indeed I just got it - thanks - and all looks fine now. gene
[arch-general] darktable libavif libyuv update and undefined symbol
Todays update[1] of darktable along with libavif / libavif led to this message: (5/7) Probing GDK-Pixbuf loader modules... g_module_open() failed for /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-avif.so: /usr/lib/libyuv.so: undefined symbol: jpeg_read_raw_data I have libjpeg-turbo installed and confirme that the function is available in the library: % objdump -T /usr/lib/libjpeg.so |egrep read_raw_data 00017950 gDF .text 00df LIBJPEG_8.0 jpeg_read_raw_data Anyone have ideas how to resolve this? Is it benig, or a problem on my end? thanks. [1] Updated to: darktable 2:3.2.1-3 libavif-0.8.3-1 libyuv-r2212+dfaf7534-1
Re: [arch-general] A few out of date packages
On 2/12/20 3:27 AM, Jelle van der Waa wrote: > Be aware that packagers might be busy, have limited time or various > rebuilds need to happen. For samba for example there is an updated > version in [testing]. For libelf, a rebuild is required which might make > sense to wait until binutils has support for debuginfod so we don't have > to rebuild it twice. [1] > > https://bugs.archlinux.org/task/65406 > Thanks for the comments Jelle For libelf - very valid - and it's also not much out of date either. The version of samba in testing is 4.11.2 and it has been there since last November and is now also behind current version (4.11.6). Understand folks being busy for sure. In case of samba and refind-efi perhaps the packager could use some additional help? thanks again! gene
[arch-general] A few out of date packages
Hi Thank you again for all the great work managing and keeping packages up to date. It is a significant amount of work and continues to make Arch a really standout distro. That said, periodically I check the repos for out of date packages. I've selected a few to highlight based on age and my own view of importance (no claim its a good view). So, here's a few that might benefit from an update: Cal Pkg NameVers Updt Flag CVers DateAge Age Pkger --- -- -- --- -- --- - thunderbird 68.4.2 200126 200211 68.5.0 200210 16 15 LP bash5.0.011 191118 200208 5.0.016 200207 85 81 EF fail2ban0.10.5 200112 200112 0.11.1 200111 30 -1 FY ipset 7.4 191202 200109 7.5 200109 71 38 SL samba 4.10.10 191114 191101 4.11.6 200128 89 75 TP smbclient 4.10.10 191114 191101 4.11.6 200128 89 75 TP ebtables2.0.10_4 181113 191203 2.0.11 190212 455 384 EF biber 1:2.13 191101 191202 2.14191201 102 30 RO diffstat1.62 190106 191130 1.63191129 401 327 AW libelf 0.177191118 191128 0.178 191126 85 8 EF elfutils0.177191118 191128 0.178 191126 85 8 EF refind-efi 0.11.3 180723 181119 0.11.4 191112 568 112 TP [1] [1] 0.11.5 looks to be coming out soon Cal Age = days since last update Pkg Age = days between current and arch release Cvers = Current version Packagers EF Evangelos Foutras FY Felix Yan SL Sébastien Luttringer TP Tobias Powalowski AW Alad Wenter RO Rémy Oudompheng LP Levente Polyak The packages that really standout to me are refind-efi and samba. Hopefully this is useful. Thanks and happy updating! gene
Re: [arch-general] Iptables
Hi Silvio One general comment - your script uses the iptables command for each rule - this is extremely inefficient. This is probably not a big deal in your case but I'll mention it anyway. Far better way is to output the firewall in the same format as iptables-save uses, then simply use iptaples-restore to load the firewall rules - this reads the entire set of rules and ask the kernel to install them all in one shot. This is essentially just dropping the '$IPT' part for each rule plus a slightly different way to define chains and set the default policies. One way to see the format is simply to use iptables-save on existing firewall. This is the format used by iptables to save / restore rules. best gene
Re: [arch-general] ssh askpass problem after todays updates to qt 5.14.1 - closed
On 1/27/20 8:19 AM, Genes Lists via arch-general wrote: Thank you - this was fixed with the updated plasma-integration-5.17.5-2. All fine now.
Re: [arch-general] ssh askpass problem after todays updates to qt 5.14.1
On 1/27/20 10:18 AM, Neven Sajko wrote: >> Wonder if the latter really is qt4 or just needs to be renamed. > > Perhaps ldd could help you to check? Just run "ldd ... Thanks 1) I did run ldd on ksshaskpass and indeed it shows only qt5 libs. Since I'm not familiar with these libs, I cannot tell if they are providing backward compatibility or if the client is updated to qt5 or perhaps no updates are actually needed. I also ran 'objdump -T' to get the list of external symbols, but while that showed Qt5 libs only as well, it didn't help me differentiate as the names contain things like Qstring etc ... without explicit refs to Qt5 or Qt4. So I just wasn't sure. I suppose either way the "name" should be changed from qt4. Also not sure if this is an arch thing or upstream. 2) Also, running ksshaskpass in gdb shows its crashing in /usr/lib/qt/plugins/styles/breeze.so regards gene
[arch-general] ssh askpass problem after todays updates to qt 5.14.1
After the recent updates to qt 5.14.1, both ksshaskpass as well as qt4-ssh-askpass (provided by openssh-askpass) programs dump core. Perhaps these need to be recompiled against the newer qt libraries? Wonder if the latter really is qt4 or just needs to be renamed. thanks. gene
Re: [arch-general] Status of WPA3
On 1/22/20 7:49 AM, Bjoern Franke via arch-general wrote: > Hi, > > recently AVM provided a beta-Firmware for Fritzboxes which support WPA3. ... In addition to above, iwd has support for WPA3 - may be worth switching over from wpa_supp to iwd and see if it works for you (i've been using it for some time now and it's been working well, though I have no access to test WPA3 Using it with network manager is very easy to turn on - just create: cat /etc/NetworkManager/conf.d/wifi_backend.conf [device] wifi.backend=iwd And restart nm. Let us know if you get it working.
Re: [arch-general] 11/23 update caused httpd to coredump?
On 12/3/19 5:36 AM, Andy Pieters wrote: > > I have experienced this last year and when I recompiled both apache > and wsgi with debugging symbols to find out what's what, it suddenly > worked again and has since! > That sounds like use of variable before set - as debugging initializes variables to 0 (in C, C++ ... ). Could be buggy code.
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 11:27 PM, Giancarlo Razzolini wrote: > > > xz is much slower than gzip, and the kernel does not support zstd. > Right - facebook brought it up again a few months ago, thread went quiet and I incorrectly assumed it was actually mainlined - but you're right it isn't. https://lkml.org/lkml/2019/6/10/725 Thanks!
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 11:16 PM, Genes Lists via arch-general wrote: > > gene > Clearly image size and compression both likely impact boot time. An interesting comparison might be running systemd-analyze blame after booting with and with hostonly and with and without compression. Anyone have a comparison handy?
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 10:59 PM, Genes Lists via arch-general wrote: > > Not sure what value a fallback image actualy provides at this point? > It takes more space and I don't see it adding much value. > Didn't think enough - the host only image might well be faster to boot (being smaller) - but I have not benchmarked the benefit. Be curious how much faster booting with the host-only image would be. Anything else I've missed for having this? gene
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 7:31 PM, Giancarlo Razzolini wrote: > That would require having dracut depend on mdadm. I think this is something > to be done by the user. I plan a simple config/preset per kernel that > will be Yeh, that makes sense - plus its very easy to add to dracut.conf > called twice, once with -H and once without, to create the > regular/fallback images. Been thinking about that - I've switched to building without -H and not creating a fallback image - I've also switched to signing all modules (in and out of tree). Not sure what value a fallback image actualy provides at this point? It takes more space and I don't see it adding much value. > > Also, I've found out that, for some reason, dracut defaults to creating > non-compressed > images when nothing is passed, so I'll probably add arguments to make > sure they are compressed. Good catch - i missed that. I that that we would be better with compression being put in dracut.conf. Be more flexible that way than the command line which I assume overides dracut.conf - so a lot less flexible. Also, is it time to switch from gzip to xz or even to zstd yet? gene > > Regards, > Giancarlo Razzolini
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 7:05 PM, Genes Lists via arch-general wrote: > Only suggestion I'd make is adding "--mdadmconf" perhaps by default - To clarify, I mean in dracut.conf - so I should probably have said mdadmconf="yes" ... anyway, thanks again. gene
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 4:02 PM, Giancarlo Razzolini wrote: > > I'm as of now writing hooks for dracut to be able to install the kernel, as > mkinitcpio does, and I'm considering have a preset config, like mkinicpio, > so it gives the user the ability to decide how dracut is ran. > > Other than that, given that dracut is slightly different than mkinitcpio, I > don't think these hooks should be overworked. On the other hand, the kernel > installation will be somewhat inflexible if done only to /boot. > > I think initially it'll be like that, but then we can use dracut's > configuration > for this. > > Regards, > Giancarlo Razzolini Thank you ... I really like dracut - it works well. Only suggestion I'd make is adding "--mdadmconf" perhaps by default - though I can see it both ways for those who don't use RAID - if its easy to add that would also be totally fine. Thanks again. gene
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 10/31/19 2:30 PM, Giancarlo Razzolini via arch-general wrote: ... > ... Also, as I've mentioned, dracut should receive > soon, hooks similar to those mkinitcpio did, with a few differences of > course. Since Giancarlo brought up dracut in May this year, I've been using this successfully to boot custom built upstream kernels on about 8 different systems, including servers running soft RAID. And it works very, very well - thank you for driving this forward. Giancarlo is there anything that may need changing to boot using dracut going forward?
[arch-general] SIgned Kernel Modules - new wiki page
Since the kernel now separates verification of signed modules from the enforcement policy whether to allow unverified modules to be loaded or now I thought it's time to explore. The enforcement policy can be compiled in or turned on at run time via boot option to kernel. I now have it working to sign all the in tree modules as well as the out of tree modules. In my case I'm signing virtualbox and wireguard. In case it's helpful I created a wiki page outlining what I did to get this working. Hope it's useful. https://wiki.archlinux.org/index.php/Signed_kernel_modules gene
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/9/19 10:11 AM, Tinu Weber wrote: > > https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/x86_64/base/ > Perfect - thank you!
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/9/19 6:15 AM, mar77i via arch-general wrote: >...What problem are we solving, really? Problem: - there was a change - but the "diff" is not (obviously) visible, though I may have not looked in all the right places. The 'base' package has no history [1] - it came into existence 3 days ago. My view - be helpful to have a list of packages no longer in base. A list of what changed is needed so users can add whatever they deem appropriate (presumably a kernel is one) to their own personal install package and ensure installations proceeed as usual. So, if somone can provide a complete list of no-longer included packages that would be super helpfui so we can all adjust as needed. thanks. [1] https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/base
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/8/19 4:34 PM, Eli Schwartz via arch-general wrote: > Really, I wish we would do as I'd wanted and transfer the "essential > packages" which aren't actually essential and were thus not included in > base.. to a new *group* called "base-extras", which would reflect its > status as being mere recommendations, while providing a convenient way > to choose to interactively install them, and allowing the Installation > Guide to transition from: Sounds good to me - do you have a suggested list of packages for base-extras or at least the list of what was pulled from the old base. Might be good for folks to add those to private install script / meta package until such time as base-extras may be available. Thanks for mentioning linux-firmware - I just added kernels and a few other items to my own, but I missed that one
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
May I offer a suggestion and you may already be doing thi; its what I do to create Arch installs customized to my own needs. Either: a) Create a simple script with installs a list of packages you want. Can be as simple as a shell script with a list of commands like: pacman -S --needed linux linux-custom mdadm lvm2 pacman -S --needed networkmanager pacman -S --needed vi etc Adjust pacman options to taste or if you're a little more energetic and looking for a bit more fun: (b) create one or more personal meta packages which you can then simply pacman -U. Every install you do, just copy the script or package file(s) to new install and you get standard install just the way you want it. I suspect many arch users do something like this anyway. gene
Re: [arch-general] High lag in graphical applications
On 9/17/19 12:48 PM, Yurii Kolesnykov wrote: > Hello Lukas, > > Firstly, could you provide output of the following command (requires > mesa-demos): > > `glxinfo|grep Rendering` > Or possibly glxinfo|grep rendering
Re: [arch-general] New install second drive issue
What tool is being used to boot (grub, refind, etc)? Should we assume this is UEFI? And if so, what are UEFI Bios settings possibly relevant (like a boot manager setting for example which "can" choose disks oher than your preference).
Re: [arch-general] NFS server question
On 7/21/19 8:28 PM, Genes Lists via arch-general wrote: > All: > > For client tracking and recovery on reboots NFS provides some mechanisms. > > My understanding is that nfsdcld is considered replaced by nfsdcltrack. Following up on self: (1) nfsdcld is what is still provided by upstream (nfs-utils) as of 2.4.1 from Aug 2019. (2) Newer kernels now report: kernel: NFSD: Using old nfsdcld client tracking operations. (3) Support for nfsdcld was added back to kernel in May 2019 [1] So, clearly nothing to do in Arch land - just wait and keep following upstream as usual. So just an FYI in case others notice the new message in logs. gene [1] https://lkml.org/lkml/2019/5/15/1480
[arch-general] Recommend new package : Postfix and MTA-STS (RFC8461)
Topic: Email Suggest: New package for officia repo [2] MTA-STS is taking off and the major email providers are supporting it. Details are described in RFC8461 [1] from Sep 2018. As of now it has support by Google (gmail), yahoo, comcast, hotmail and others. MTA-STS is a new standard that aims to improve the security of SMTP by enabling domain names to opt into strict transport layer security mode that requires authentication (with valid public certificates) and encryption (TLS). There are 2 components to this (a) Sending: Making email server advertise mta-sts (b) Receivng: Postfix needs policy daemon (a) is pretty straightforward to set up, (b) requires a daemon to support the policy for incoming mail. It would be pretty awesome if someone would think about an offocial postfix-mta-sts-resolve package [2]. Postfix can use this daemon - see some discussion on this here [5] where Wietse got involved as well. There is an AUR package but it is quite out of date and I think this would actually be better to be in the official repos if someone was interested in taking it on. Probably as an optional package for postfix This is important for any business use and of course for anyone running their own mail server on Arch. Over time it is likely that any server which does not turn this on at least for sending may find their email being disadvantaged. There are several places where this is discussed in more detail - here's a couple for convenience [3]. Thanks, gene [1] https://tools.ietf.org/html/rfc8461 [2] https://github.com/Snawoot/postfix-mta-sts-resolver [3] https://weekly-geekly.github.io/articles/424961/index.html https://www.hardenize.com/blog/mta-sts https://www.uriports.com/blog/mta-sts-explained/ https://starttls-everywhere.org/ [5] http://postfix.1071664.n5.nabble.com/MTA-STS-when-td95086.html
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 8/22/19 3:36 PM, Giancarlo Razzolini via arch-general wrote: > Em agosto 22, 2019 16:29 Damjan Georgievski via arch-general escreveu: ... > > On the other hand, I have been using dracut for months now without any > issues. > > Regards, > Giancarlo Razzolini I too have been using it for months by packaging hooks to use dracut instead of mkinitrd with my custom kernel builds. The only issue I had early on was with raid, as explained in my post of june 15th - the solution was to ensure that the initrd is built with --mdadmconf. Since then it's been rock solid on several computers includng 2 running raid 6. Anyway - works like a champ.Thanks for taking this on Giancarlo.
Re: [arch-general] Opening a document with unicode in path
On 8/2/19 12:23 PM, John Z. wrote: ... >> I don't have a direct answer, but check the version(s) of LibreOffice, There might also be a difference between libreoffice-fresh and libreoffice-still which is quite a bit behind fresh.
[arch-general] NFS server question
All: For client tracking and recovery on reboots NFS provides some mechanisms. My understanding is that nfsdcld is considered replaced by nfsdcltrack. However, while there is a system service unit for nfsdcld there is nothing for nfsdcltrack. The binary for both is available. Only the systemd service file is missing. Further nfs-server service file hardcodes nfsdcld with no option to use nfsdcltrack instead. What is the modern preferred way for the server to do client tracking? Thanks, gene
Re: [arch-general] External monitors are no longer detected (Intel graphics)
On 7/3/19 9:31 AM, Bennett Piater wrote: > I was talking about external monitors not working, you are talking about wifi > cards. You're right sorry - I replied to wrong email - meant to be to this. It should have been a new thread as different topic. On 7/2/19 12:25 PM, Stanislav N. aka pztrn via arch-general wrote: > Not only GPUs, but also WiFi cards. Got 8265 on Thinkpad T480 and 5G > speeds are awful. When you're trying to download via 5G network > something big - connection interrupts and won't come back until > NetworkManager is restarted, also there are plenty of errors in dmesg. > All fine on 5.0.x and LTS kernel (4.19.x), only 5.1.x are affected.
Re: [arch-general] External monitors are no longer detected (Intel graphics)
On 7/3/19 3:58 AM, Bennett Piater wrote: > > > To clarify: I did not find an upstream bug, and I don't know that this > is an upstream issue. It is an upstream bug - peraps my previous email didn't get through - will quote it again - sorry if its a dup: --- On 7/2/19 1:48 PM, Genes Lists via arch-general wrote:> Check youor mesages and look for EDC asset. There is a fix teed up which may help your case. I have seen this "EDC assert" issue with 8265 [1] and the fix is given in comment #42. I have tested it on kernel 5.2-rc7 and works fine. This impacts all pre-9000 intel wifi cards. This will NOT make it into 5.2, as Emmanual G points out, as its late in the cycle; presumably will be in 5.2.1 and 5.3. A work around you might try is to add this iwlwifi option - then reboot. # cat >> /etc/modprobe.d/iwlwifi.conf options iwlwifi swcrypto=1 regards, gene [1] https://bugzilla.kernel.org/show_bug.cgi?id=203315 ---
Re: [arch-general] External monitors are no longer detected (Intel graphics)
> Not only GPUs, but also WiFi cards. Got 8265 on Thinkpad T480 and 5G > speeds are awful. When you're trying to download via 5G network > something big - connection interrupts and won't come back until > NetworkManager is restarted, also there are plenty of errors in dmesg. > All fine on 5.0.x and LTS kernel (4.19.x), only 5.1.x are affected. Check youor mesages and look for EDC asset. There is a fix teed up which may help your case. I have seen this "EDC assert" issue with 8265 [1] and the fix is given in comment #42. I have tested it on kernel 5.2-rc7 and works fine. This impacts all pre-9000 intel wifi cards. This will NOT make it into 5.2, as Emmanual G points out, as its late in the cycle; presumably will be in 5.2.1 and 5.3. A work around you might try is to add this iwlwifi option - then reboot. # cat >> /etc/modprobe.d/iwlwifi.conf options iwlwifi swcrypto=1 regards, gene [1] https://bugzilla.kernel.org/show_bug.cgi?id=203315
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 6/15/19 5:12 PM, Genes Lists via arch-general wrote: ... > > I need to do more work ... perhaps test with the --madadmconf flag when > building the initrd is next step. > I confirm that building the initrd with --mdadmconf fixes the problem assembling the raid disks using dracut - this happens fine now. In my case the /etc/mdadm.conf has RRAY /dev/md0 metadata=1.2 name=xxx ... where xxx is the hostname which is also in the RAID superblock. I would therefore recommend that the pacman hook file which is used to build the initrd use the --mdadmconf option. I will note that the file is not included even with -H or --include /etc/mdadm.conf. best gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
I now understand why this works with mkinitrd - it's because this approach does not assemble the array until -after- the pivot root - and the hostname is now the real hostname and this matches what's in the raid superblock. dracut attempts to assemble the array(s) before - in this case the hostname is the fake hostname. In neither case is /etc/mdadm.conf included - tho nkinitrd approach its not needed. I need to do more work ... perhaps test with the --madadmconf flag when building the initrd is next step. gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
> Giancarlo Razzolini Found this (very) old thread [1] - and tried the suggesion - removed name= from mdadm.conf, rebuilt the initrd and rebooted but had same problem. Booted from mkinitrd and still works. May be i need to learn more about raid Will need to get back to this. [1] https://ubuntuforums.org/showthread.php?t=1764861
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
> Speculation - this may be related to the kernel config which has CONFIG_DEFAULT_HOSTNAME="archlinux" for arch kernels and i use a different name (saplinux) In either case, in the boot logs the hostame shown before the pivot root is that default as compiled into thekernel - but after the switch root the actual hostname for the server is used. Since raid uses the real hostname (cat /proc/mdstat for example shows the real hostname on the raid server) - that since the hostnames doesn't match. Before the switchroot the raid is assembled but at md127 instead of md0 - after the pivot root all hell breaks loose as there is no md0 only md127. Clearly dracut must be used for raid - so whats the right way to do this? thanks.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 6/4/19 4:53 PM, Genes Lists via arch-general wrote: Forgot to post the boot the boot log which shows the problem occurs after switching the pivot root: ... saplinux kernel: md/raid:md127: raid level 6 active with 6 out of 6 devices, algorithm 2 saplinux kernel: md127: detected capacity change from 0 to 12001828929536 saplinux systemd[1]: Started dracut initqueue hook. ... saplinux systemd[1]: Switching root. ... kernel: EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: data=ordered systemd[1]: dev-md0.device: Job dev-md0.device/start timed out. systemd[1]: Timed out waiting for device /dev/md0. systemd[1]: Dependency failed for File System Check on /dev/md0. systemd[1]: Dependency failed for /mnt/md0. systemd[1]: Dependency failed for /srv/nfs4/install. systemd[1]: Dependency failed for Local File Systems. systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'. systemd[1]: local-fs.target: Triggering OnFailure= dependencies. ...
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 6/4/19 12:07 PM, Genes Lists via arch-general wrote: > FYI - I have switched my custom kernel builds to use dracut by default Ug take it back - i have one problem - a big problem. On a computer using md RAID-6 the raid disks are not assembled at boot - and the boot fails. Works fine switching back to mkinitcpio. Is there anything special we need to do with dracut to make md raid work at boot? The raid array is for data only not root which is a separate disk. dracut docs suggest nothing is needed to assemble raid arrays at boot. Perhaps this is incorrect? Thanks.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
FYI - I have switched my custom kernel builds to use dracut by default now - tested on 8 machines with no issues. Very supportive of switching to dracut. thank you. gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/27/19 2:07 PM, Genes Lists via arch-general wrote: Likely the same issue https://lkml.org/lkml/2019/5/28/812 Thanks, gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/27/19 2:07 PM, Genes Lists via arch-general wrote: > Hi > > I've come across a possible issue which related to usb keyboard/mouse > device. > > Quick follow up. I have this issue on 2 machines I've tested. (i) vendor_id : GenuineIntel cpu family : 6 model : 78 model name : Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz stepping: 3 (ii) vendor_id : GenuineIntel cpu family : 6 model : 158 model name : Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz stepping: 9 gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Hi I've come across a possible issue which related to usb keyboard/mouse device. I notice that booting using dracut initramfs with kernel 5.2-rc2 that as soon as it boots it shows on the console: stopping job udev Kernel Device Manager with red spinner. This times out and boot continues fine - once the system has booted I check the boot log and included interesting part of logs below. Keyboard and mouse are both working and the relevant hid modules are loaded fine - and xinput shows all looking normal. Interesingly, using mkinitcpio initrd with same 5.2 kernel- the system comes up with no keyboard or mouse (it uses logitech wireless kbd/mouse). The hid_logitech modules seem not to have been loaded at all. So something in the newer kernel is leading to this issue but dracut manages to pull through anyway while mkinitcpio does not. Obviously anyone experiencing this might be quite taken aback. Also, everythign works fine with 5.1.5 kernel with both dracut and mkinitcpio. the hid modules are all fine for that test case. udev is a bit of a mystery to me - but thought I'd best mention the problem. gene --- boot journal with 5.2 with dracut saplinux systemd[1]: systemd-udev-trigger.service: Succeeded. saplinux systemd[1]: Stopped udev Coldplug all Devices. saplinux systemd[1]: dracut-pre-trigger.service: Succeeded. saplinux systemd[1]: Stopped dracut pre-trigger hook. saplinux systemd[1]: Stopping udev Kernel Device Manager... ... saplinux systemd-udevd[386]: Giving up waiting for workers to finish. saplinux systemd-udevd[386]: Event loop failed: Connection timed out saplinux systemd[1]: systemd-udevd.service: Main process exited, code=exited, status=1/F> saplinux systemd[1]: systemd-udevd.service: Killing process 459 (systemd-udevd) with sig> saplinux systemd[1]: systemd-udevd.service: Killing process 480 (systemd-udevd) with sig> saplinux systemd[1]: systemd-udevd.service: Killing process 482 (systemd-udevd) with sig> saplinux kernel: input: Logitech USB Receiver as /devices/pci:00/:00:14.0/usb1/1> saplinux kernel: hid-generic 0003:046D:C52B.0001: input,hidraw0: USB HID v1.11 Keyboard > saplinux kernel: input: Logitech USB Receiver Mouse as /devices/pci:00/:00:14.0/> saplinux kernel: input: Logitech USB Receiver Consumer Control as /devices/pci:00/00> saplinux kernel: input: Logitech USB Receiver System Control as /devices/pci:00/> saplinux kernel: hid-generic 0003:046D:C52B.0002: input,hiddev0,hidraw1: USB HID v1.11 M> saplinux kernel: hid-generic 0003:046D:C52B.0003: hiddev1,hidraw2: USB HID v1.11 Device > saplinux kernel: usbcore: registered new interface driver usbhid saplinux kernel: usbhid: USB HID core driver saplinux systemd[1]: systemd-udevd.service: Failed with result 'exit-code'. saplinux systemd[1]: Stopped udev Kernel Device Manager. saplinux systemd[1]: systemd-tmpfiles-setup-dev.service: Succeeded.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/21/19 12:24 PM, Genes Lists via arch-general wrote: > 1) Feedback: > Tested one computer and it worked fine. Working fine on a couple more I tested. Also for my custome kernel builds, I added a libalpm hook to create the dracut initrd - makes it easier for me to test. Thank you for doing this - based on the list volume, looks like there's significant interest. thanks again, gene
Re: [arch-general] A few out of date packages
On 5/19/19 6:08 PM, Genes Lists via arch-general wrote: Firstly, a big thank you for those who updated their packages :) (By the way, The age column is the number of days between the current available release and the version we have in the repo. ) Given the work needed to explore possible use of the lsof fork - i've removed it from here as well. Docbook I can't follow the versioning/dates clearly but sure does seem like we're a bit behind. If the primary maintainer(s) are too busy I wonder if someone else could update to newer packages? refind-efi, efibootmgr and autofs in particular could use a refresh - right! thanks again. gene > > RepoCurrent > Package VersDateVersDateAge > -- -- > usbutils 0.10201805150.1220190507357 > refind-efi11.32018072211.420181112113 > efibootmgr16 2018040917 20180610 62 > autofs5.1.4 201712195.1.5 20181030315 > cifs-utils6.8 201803136.9 20190405388 > Docbook-xml 4.5 5.1 ? > gradle5.2.1 201902085.4.1 20190426 77 >
Re: [arch-general] Arch on NVMe ssd
On 5/22/19 11:27 AM, Ram Kumar via arch-general wrote: I have been using arch on laptops with SSDs for a few years with no issues whatsoever. Other than the UEFI vfat partition I use ext4 for everything. It "just works" with no problems at all. gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/21/19 1:21 PM, Giancarlo Razzolini wrote: >> Got text prompt for passphrase not graphical - think there is a way to >> get graphical as well but need to read further how to do that. I prefer >> text as I also can see the boot progress details which is helpful. >> Still, be good to know how to get the graphical prompt anyway. >> > > I suppose as more and more people start using it, we'll eventually have > instructions on how to do these more custom environments. > Definitely - getting dracut in first then later on it should not be too hard to add a plymouth[1] package if there's interest in a more graphical boot. thanks again for doing this. gene [1] https://github.com/freedesktop/plymouth/tree/master/src
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/21/19 2:48 PM, Giancarlo Razzolini wrote: > Em maio 21, 2019 15:42 Genes Lists via arch-general escreveu: ... > > Loading the microcode before will probably always work and should > continue to be the desirable solution. .. Funnily enough, while I do have intel-ucode package installed I don't have amd-ucode. The dracut script seems to have found it somewhere I suppose - not sure where yet. thank you. gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
Early Microcode and initrd. I notice that the AMD microcode is [1] in the initrd while the intel microcode is not. Booting with option: initrd=/boot/intel-ucode.img to get the microcode installed early works fine with dracut as it always has. Is this something that will remain the same as now or does this potentially change under dracut? thanks gene [1] lsinitrd shows: Early CPIO image drwxr-xr-x 3 root root0 May 21 11:48 . -rw-r--r-- 1 root root2 May 21 11:48 early_cpio drwxr-xr-x 3 root root0 May 21 11:48 kernel drwxr-xr-x 3 root root0 May 21 11:48 kernel/x86 drwxr-xr-x 2 root root0 May 21 11:48 kernel/x86/microcode -rw-r--r-- 1 root root30546 May 21 11:48 kernel/x86/microcode/AuthenticAMD.bin
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/21/19 12:41 PM, Doug Newgard via arch-general wrote: > > > Since ln won't work on vfat, that's not really an option for a lot of people. > Ah thanks and good point. While it would actualy work with refind ( as the images are on ext4 /boot partition and only the refind efi images sit in the ESP partition) the solution should be agostic to boot manager. So that means no links; easy enough and same as we do now anyway. Thank you. gene
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
1) Feedback: Tested one computer and it worked fine. Used refind to boot - it has encrytped /home but not root. Got text prompt for passphrase not graphical - think there is a way to get graphical as well but need to read further how to do that. I prefer text as I also can see the boot progress details which is helpful. Still, be good to know how to get the graphical prompt anyway. Created initrd using # dracut --kver xxx This seems to contain pretty much everything best I can tell 2) Question: Arch typically has used unversioned initrd images which has the convenience that the boot standzas don't need updating on new kernel. Which is preferable way to deal with this with dracut: 1) Unversioned: # dracut initramfs-linux.img --kver 5.1.3-arch1-1-ARCH 2) Keep version but link to unnamed: # dracut --kver 5.1.3-arch1-1-ARCH # ln /boot/initramfs-5.1.3-arch-1-ARCH.img initramfs-linux.img or perhps soft link (ln -s)? thanks.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 5/20/19 10:41 PM, Giancarlo Razzolini via arch-dev-public wrote: > Hi All, > ... > > In this initial phase I want to ask as many of you to test this as a > replacement to mkinitcpio in your setups, > as many as possible, and in as many scenarios as possible. We will ... I'm an arch tester and I'd be happy to test dracut. It would be helpful if you could create a little write-up on 'how to switch' from mkinitcpio to dracut. Its straightforward for me to add a boot stanza to refind to use the dracut img. And I assume modules now in HOOKS would move to /etc/dracut.conf.d/hooks.conf or similar. All being well, the kernel package will need to be modified to update /usr/share/libalpm/hooks/60-linux.hook to now call dracut. Thanks for working on this. gene
Re: [arch-general] A few out of date packages
On 5/19/19 6:16 PM, Anatol Pomozov via arch-general wrote: ... >> lsof4.91201804044.93.2 20190508399 > > Where did you find lsof version 4.93.2?> > The official website does not mention current version. And the mirror > Arch uses hosts 4.91 only ftp://ftp.fu-berlin.de/pub/unix/tools/lsof/ That .de site looked pretty dead to me. So I searched around a bit; And I found this though I'm not 100% convinced this isn't a fork ... but hoped you'd know the right thing to do :D https://github.com/lsof-org/lsof/releases Debian has 4.91 also Ubunti has 4.91 Fedora rawhide has 4.91 So ... thats why I was a bit confused and figured I'll mention it and let the experts advise on the best way to proceed. ... >> alsa-lib1.1.8 201901071.1.9 20190510123 >> Alsa-plugins1.1.8 201901071.1.9 20190510123 >> Alsa-utils 1.1.8 201901071.1.9 20190510123 > > alsa packages version 1.1.9 are in [testing] for a week now. They will > be moved to stable in a few days. > Sorry about that - I meant to exclude that for that exact reason. > > Thank you for the feedback! Really appreciate it. >
[arch-general] A few out of date packages
Hi - First a thank you for all the great work managing and keeping packages up to date. It can a significant amount of work. That said, periodically I check the repos for out of date packages. I've selected a few to highlight based on age and my own view of importance (no claim its a good view). There are also some packages which have been languishing in testing for a while (not sure the reason - I chose to ignore those here.). Here's a few that might benefit from an update: RepoCurrent Package VersDateVersDateAge -- -- dkms2.5 201711302.7.1 20190512528 usbutils0.10201805150.1220190507357 refind-efi 11.32018072211.420181112113 efibootmgr 16 2018040917 20180610 62 autofs 5.1.4 201712195.1.5 20181030315 lsof4.91201804044.93.2 20190508399 cifs-utils 6.8 201803136.9 20190405388 chrony 3.4 201809193.5 20190514237 Docbook-xml 4.5 5.1 ? alsa-lib1.1.8 201901071.1.9 20190510123 Alsa-plugins1.1.8 201901071.1.9 20190510123 Alsa-utils 1.1.8 201901071.1.9 20190510123 gradle 5.2.1 201902085.4.1 20190426 77 Hope this is helpful, thank you! gene
Re: [arch-general] HTTP spam from China - CIDR compacting tool
On 2/28/19 9:21 AM, DcUK wrote: .. > > The aur/iprange package is another alternative for manipulating IP lists. > > It can optimize/merge/compare/convert in pretty much any way you like. Thanks - wasn't aware of this one either. A quick glance at source and it seems to be IPV4 only with no IPV6 support. I may have missed it I only glanced at the C code briefly. The python library does have the advantage of handling IPV6 as well. gene
Re: [arch-general] /var/run vs /run in systemd unit files
On 2/27/19 7:37 PM, Eli Schwartz via arch-general wrote: . > > If there are any remaining packages where the Arch packager has added > his/her own systemd files that contain "/var/run", you are welcome to > file a bug report at https://bugs.archlinux.org > Thanks that is helpful - I'll certainly follow your suggestions. Also a big thanks for all the effort you put in (on many things not just this topic) - much appreciated. I'm so glad I switched away from fedora a long time back! gene
[arch-general] /var/run vs /run in systemd unit files
I've noticed warnings from systemd about changing systemd files to reference /run instead of /var/run. I'm not sure if this is upstream or arch or both? I see it for things like: rpc-statd (from nfs-utils) dovecot saslauthd chronyd There may well be more. gene
Re: [arch-general] HTTP spam from China - CIDR compacting tool
On 2/26/19 4:01 PM, brent s. wrote: ... > > You can (Gene, you may find this particularly useful since you feed to > ipset) use the pyroute2.IPSet() function to actually manage the live > Great thank you - I wasn't aware of this capability. I really like python! ipset made a huge difference - major benefit I agree. The other thing I do in my firewall script is I write the rules in iptables-save format. Many guides continue to use the iptables executable in their examples rather than directly writing into a file in iptables-save format. I haven't read any guides for a long time, so perhaps there are better ones now which speak to this. Rather than invoking iptables repeatedly on each rule, i write an iptables-save formatted file and then use iptables-restore to install the entire firewall in one shot. thank you brent ... gene
Re: [arch-general] HTTP spam from China - CIDR compacting tool
On 2/26/19 1:13 PM, Juha Kankare via arch-general wrote: > On 26/02/2019 20:11, Genes Lists via arch-general wrote: ... > > My current script is just pulling cn.zone from ipdeny.com. This looks > super useful, I'm saving it. Thank you dude! > You're welcome. I just ran it on cn.zone and it reduces the number of lines from 8,337 to 5,120. It can make a significant difference. best, gene
Re: [arch-general] HTTP spam from China - CIDR compacting tool
Just an FYI if you pull cidr blocks by country, either doing it yourself directly from arin et al or by using someone elses list like ipdeny.com the CIDR blocks are not necessarily compacted. i.e. it is often not the most minimal CIDR representation. I use is this little python script, which works on list of CIDR blocks of IPV4 or IPV6, to compact the list of cidr blocks. I feed the output compacted CIDR blocks to the firewall ipset script. In case anyone finds this useful here is my CidrMerge.py : UseageL - cut here - #!/usr/bin/python # # Read from stdin a list of cidr blocks and compacts them if possible # Resulting compacted CIDR blocks are written to stdout. # Works on any file with IPV4 or IPV6 cidr blocks. # # Usage : CidrMerge.py < file # # Gene C. # # 20180503 # import sys import netaddr def main(): num_args = len(sys.argv) # # Open file - read one line at a time and output # lines=sys.stdin.readlines() if len(lines) == 1: lines = lines[0].split() # # create merged set of entire input lines # set1 = netaddr.IPSet(lines) # # Write them out # for cidr in set1.iter_cidrs() : print (cidr) return # - if __name__ == '__main__': main() # # All Done
Re: [arch-general] circular self-dependency removing evolution-data-server
-R folks evolution-data-server or use -Rc evolution-data-server [warning], may remove more than intended, read the output before you press Y/enter Well duh on me for being silly. I read that as a "folksy" message instead of as a package - happy new year lol. Thank you for fixing my error. Sorry for noise. gene
Re: [arch-general] circular self-dependency removing evolution-data-server
Ignore the evolution line, bad paste - i tried to remove them both which failed as above, then I removed evolution which worked. I subsequently tried to remove evolution-data-server alone and got: # pacman -R evolution-data-server checking dependencies... error: failed to prepare transaction (could not satisfy dependencies) :: folks: removing evolution-data-server breaks dependency 'evolution-data-server'
[arch-general] circular self-dependency removing evolution-data-server
What am I doing wrong? # pacman -R evolution-data-server checking dependencies... error: failed to prepare transaction (could not satisfy dependencies) :: evolution: removing evolution-data-server breaks dependency 'evolution-data-server' :: folks: removing evolution-data-server breaks dependency 'evolution-data-server' # pacman -Q pacman evolution-data-server pacman 5.1.2-2 evolution-data-server 3.30.4-1
Re: [arch-general] pambase in testing breaks email - *resolved*
Requires adding files (if you haven't already got them) for both dovecot and postfix and not relying on the old 'other' catchall pam file. This is described in more detail in the forum posts [1]. Hoever I'm as yet not sure of the best postfix pam file. Perhaps others can comment. thank you. gene [1] https://bbs.archlinux.org/viewtopic.php?pid=1824850
Re: [arch-general] pambase in testing breaks email
The problem stems from change to: /etc/pam.d/other which replaced password requiredpam_unix.so with password required pam_deny.so I wonder if this means that things like dovecot and postfix need to have explicit additional files in /etc/pam.d so that email authentication work without relying on the catch all "other" file? thank you. gene
Re: [arch-general] pambase in testing breaks email
Forgot to mention the perhaps obvious that postfix subsequently logs: warning: SASL authentication failure: Password verification failed Thank you.
[arch-general] pambase in testing breaks email
pambase 20190105.1-1 caused bad failure for email. The error I saw immediately was from postfix failing to authenticate users via saslauthd which in turn blames pam. Downgrading back to 20171006-1 restores email funtioning ok. Logs say: saslauthd[22214]: pam_warn(smtp:auth): function=[pam_sm_authenticate] flags=0x8000 service=[smtp] terminal=[] user=[lists] ruser=[] rhost=[] saslauthd[22214]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure saslauthd[22214]: do_auth : auth failure: [user=lists] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Re: [arch-general] Wireguard
To help us understand, On the wireguard server what is the output of iptables --list-rules thanks, gene
Re: [arch-general] Wireguard
On 1/1/19 10:46 AM, siefke_lis...@web.de wrote: > Forwarding is enabled like it stand in tutorial of Arch and Firewall > only must open the port I used for wireguard? > There are 3 of cases that come to mind. (a) you're testing on internal network (b) you're using external and wireguard is running on firewall and (c) you're using external and wireguard is running behind your firewall. In all cases, on the server running wireguard, you need iptables rules to managing forwarding in addition to having net.ipv4.ip_forward = 1 to enable forwarding in /etc/systctl.d/syscttl.conf and reload sysctl. I'd recommend getting things working on (a) inside your network first, then deal with packets going through your internet facing firewall. So in summary, I'd ensure your iptables rules on the VPN server are correct and working testing purely inside your network.
Re: [arch-general] Wireguard
On 1/1/19 9:49 AM, Jelle van der Waa wrote: had someone run wireguard?`I have read today about it and try to run it through the Tutorial Yes I run it as well. Works really well, is easy to configure. I use a QR code to configure android phones using the beta app. This is discussed in the wiki that Jelle referenced.
Re: [arch-general] syslinux: out of date - or not?
On 12/21/18 10:38 AM, Eli Schwartz via arch-general wrote: ... Debian has patches for both -- neither of which the syslinux developer community has responded to, though given that they've only committed 2 patches in the last year, both of which were in response to a syslinux thread entitled "Is syslinux still worked on? No new commits in git for about one year", things are looking... gloomy. Based on Eli's above comment it sounds like syslinux may not be a good choice. Its such a critical component of the system, that having a well maintained tool is important. I chose to use refind (arch package refind-efi) which I've found to work well for my use cases. For my very old computer without EFI I use grub2. Of the 2, IMHO, refind is the superior tool. Thanks for sharing. gene
Re: [arch-general] mariadb package outdate for over a month
On 12/18/18 3:54 PM, Christian Hesse wrote: The remaining issue is that zerofill support in libmariadb is broken. Thanks Christian: I certainly assume you're all making sound decisions on holding off on 10.3.11 - but it would be helpful, if you you wouldn't mind, sharing a little more info about that. Are we waiting for fixes to client apps (which ones) or further fixes to mariadb server or mariadb client lib or something else? Sounds like the client library from above? What client apps are affected and how badly - i.e. what would break if we did update. I do note that there are a lot of security fixes in the newer mariadb [1] (12 CVEs alone in 10.3.11). I also note that fedora has included 10.3 and marked it as a security update [2] (or at least its in Bodhi)- does that mean fedora doesn't support those client apps that prevent updates like we do? Debian seems also seems to not ship 10.3 as far as I can tell and neither does ubuntu nor Opensuse (not sure about tumbleweed). So we're clearly not alone here. Thanks for your work keeping Arch the best!! regards gene [1] https://mariadb.com/kb/en/library/mariadb-10311-release-notes/ [2] https://bodhi.fedoraproject.org/updates/?packages=mariadb=1
Re: [arch-general] Unbound
Yeh the defaults were changed a while ago ... Try add this to your unbound.conf do-daemonize: no See if that fixes things. On 10/31/18 4:41 PM, siefke_lis...@web.de wrote:
Re: [arch-general] MariaDB package version
On 9/27/18 7:04 AM, leoutat...@gmx.fr wrote: If you have further news, feel free to share. :) Mariadb 10.2 and 10.3 are available in all distro except Arch https://downloads.mariadb.org/mariadb/repositories/#mirror=cnrs The link Eli provided references lots of client programs having problems - but I didn't find a list of which client programs. Given how long this has been, I would like to suggest that the problem lies with the clients at this juncture and not with mariadb. I see 3 basic options to choose from for each offending client package: (i) Drop client (ii) Compile the client statically linked ( removes the need to provide and older mariadb. ) (iii) Provide 2 mariadb packages Current and the older one needed for the clients to run using shared libraries. Hard to say without knowing which clients. And I don't know how much work keeping both versions might be. This seems a bit similar to the python situation where we still seem to have couplings to python 2. Does anyone have a list of the 'problematic clients' so a reasonable decision can be made how to move forward and update mariadb? Eli how do you think we should proceed at this point? thanks! gene
[arch-general] konsole 17.12.1-2 question
Not sure when this started but seems to be after the last update. Everything works normally and then at some point, somehow Ctrl-P + Enter becomes a shortcut for a new konsole tab. You can see this in settings->manage profiles (shortcuts). I have 2 profiles - my own plus the default. It is the active one that now has the new shortcut. OF course this means that instead of command history from bash the window appears to freeze when typing Ctrl-P and then pressing enter creates a new tab. I have to manage profiles and then delete the shortcut and close and restart konsole. I am completely unable to find any shortcut/keyboard to make typing Ctrl-P become a konosole shortcut rather than passed through to bash editing. There is no documented shortcut to 'manage profiles' that I can find and it only started happening recently. Any suggestions how I can prevent this from happening? Thanks, gene
Re: [arch-general] Is linux extramodules dir named most appropriately?
On 1/11/18 12:39 PM, Bruno Pagani wrote: ... ... because the new version of those packages won’t have the dir anymore. Regards, Bruno Ding ... duh of course ... thank you both for your patience ...
Re: [arch-general] Is linux extramodules dir named most appropriately?
On 1/11/18 12:15 PM, Eli Schwartz via arch-general wrote: .. *What* directory removal logic??? pacman -Qo /usr/lib/modules/extramodules-4.14-ARCH/ Anyway, see how Red Hat uses "weak modules" in much the same way. When linux is updated to 4.15 the old 4.14.13-1-ARCH modules directory will be removed and I assumed (possibly incorrectly) that the same is true for the extramodules-4.14 directory. I guessed, perhaps wrongly, that both of these were mediated by pacman hooks in /usr/share/libapm/hooks/xxx. Otherwise we'd have a slew of unused directories building up in /usr/lib/modules. In fact this did happen I believe a long time back. Thanks for explanations. gene
Re: [arch-general] Is linux extramodules dir named most appropriately?
On 1/11/18 9:45 AM, Eli Schwartz via arch-general wrote: ... Because the extramodules directory is designated for thirdparty modules that are believed to be compatible with any kernel patch release of the same major.minor version. If the module needs to be recompiled with patch releases, it should be installed to the "main" modules directory. Terrific thank you. Do you know where the directory removal logic is managed? /usr/share/libalpm/60-linux.hook doesn't seem reveal much to my eye - it treats 4.14.13-1-ARCH and extramodules-4.14-ARCH indistinguishably. When linux is updated to 4.15 extramodules gets removed somehow but not with a minor update. Thanks. gene
[arch-general] Is linux extramodules dir named most appropriately?
The linux package creates 2 directories; for example: /usr/lib/modules/4.14.13-1-ARCH /usr/lib/modules/extramodules-4.14-ARCH Question - Why is the latter not named extramodules-4.14.13-1-ARCH? Both are owned by the linux-4.14.13 package - and extramodules-4.14-ARCH will also be owned by the next linux-4.14.14 package and so on. Perhaps it is something to do with 3rd party packages which install things in extramodules? thanks. gene
Re: [arch-general] kernel bug in 4.13.3 related to wireless?
On Sat, 2017-10-07 at 21:03 +0200, Frank Zimmermann wrote: > > 4.13.4 - have you tried 4.13.4 from testing? > > So this kernel does not provide an improvement 2 Other threads that may be relevant - do these seem relevant for your case? 4.13 http://lists.infradead.org/pipermail/ath10k/2017-October/010190.html 4.14 http://lists.infradead.org/pipermail/ath10k/2017-October/010189.html -- Gene li...@sapience.com
Re: [arch-general] kernel bug in 4.13.3 related to wireless?
Could be related https://lkml.org/lkml/2017/8/14/682 Not sure if this was in 4.13.3 but looks like it should be fixed in 4.13.4 - have you tried 4.13.4 from testing? -- Gene li...@sapience.com
Re: [arch-general] kernel bug in 4.13.3 related to wireless?
I note that there are some atheros (and intel) wifi fixes in 4.13.4 which you can try from testing repo. I think original poster may be using Ath based on the logs. Don't know if it addresses this (these) particular issue(s). Are you also using Ath by any chance? -- Gene li...@sapience.com
Re: [arch-general] [arch-dev-public] removed mariadb 10.1.27 from [testing]
On Tue, 2017-09-26 at 23:06 +0200, Christian Hesse wrote: > ... > We tried to upgrade to MariaDB 10.2.6, which ended in a disaster. The > client > library has been renamed from libmysqlclient to libmariadb and it has > seen > structural changes for data types. Programs fail to link or - if they > do > link - crash or misbehave, including data corruption. > > I do not see any way to upgrade any time soon. IMHO data structures > have to > be made opaque in favor of accessing data via functions. > Thanks - so it's clear - are you saying that the recommended method of running[1] mysql_upgrade does not in fact work properly? [1] https://mariadb.com/kb/en/library/upgrading-from-mariadb-101-to-mar iadb-102/ -- Gene li...@sapience.com
Re: [arch-general] [arch-dev-public] removed mariadb 10.1.27 from [testing]
On Tue, 2017-09-26 at 21:28 +0200, Christian Hesse wrote: > Hello everybody, > > after the release of 10.1.27 upstream was made aware of a regression, > so > the release has been pulled from the downloads system. The fix will > be > in 10.1.28. > I removed mariadb 10.1.27 packages from [testing]. Thank you Christian - related note - can you share thoughts around 10.2? thanks. -- Gene li...@sapience.com
Re: [arch-general] New - systemd 234 - luks partition fails to ask for password - workaround
On Mon, 2017-07-17 at 06:38 +0200, SanskritFritz wrote: > On Sat, Jul 15, 2017 at 6:21 PM, Genes Lists via arch-general ene...@archlinux.org> wrote: > > I have a work around which is to add timeout=90 > > Where to add this? > > in /etc/crypttab at the end of the line -- Gene li...@sapience.com
Re: [arch-general] New - systemd 234 - luks partition fails to ask for password - workaround
Could wel be related: https://github.com/systemd/systemd/pull/6264 -- Gene li...@sapience.com
Re: [arch-general] New - systemd 234 - luks partition fails to ask for password - workaround
I have a work around which is to add timeout=90 It seems the timeout=0, which is the default) and is supposed to mean wait indefinitely) is now treated as dont prompt or wait at all. I cannot say if this is a change in behavior which is intentional and the man pages need to be updated (man crypttab) or a bug causing the change - but changing to use a non-zero timeout does now prompt for password. -- Gene li...@sapience.com
[arch-general] New - systemd 234 - luks partition fails to ask for password
This has been working for years - starting on recent reboots systemd is failing to ask for password for luks encrypted /home partition and boot halts. Fully updated from testing repos - when I reboot now, systemd no longer asks for password to unlock luks partition. There is no hesitation at all and no password prompt at all. The boot runs through and gives an error that crypt set up failed. Root is not encrypted just /home. I'm then prompted to press Ctl D or give root password and drop to single user mode - doing that then I can manually do: cryptsetup open /dev/sdxx home which prompts for password and succeeds After I do above, then the error goes away evidenced by: systemctl status systemd-cryptsetup@home.service shows all is normal - exiting from single user 'repair' mode - then boot continues and completes normally. And /home gets mounted via /dev/mapper as normal The issue is with latest systemd that I no longer get prompted for a password for the luks encrypted partition. Thoughts: systemd password agents: running systemd-ask-password by hand does indeed ask for password in the console. /run/systemd/ask-password is empty directory. the journal contains this: systemd-cryptsetup[316]: Failed to query password: Timer expired systemd[1]: Failed to start Cryptography Setup for home. (Its possible that the bug is in systemd-cryptsetup in latest release?) Versions: # pacman -Q linux systemd linux 4.12.1-2 systemd 234.0-2 cryptsetup 1.7.5-1 I googled but was no able to find any relevant bugs - checked systemd github issues but found nothing similar. thanks. -- Gene li...@sapience.com
Re: [arch-general] Tobias Powalowski and his nonsensical maintenance decisions
1) Tobias: Thank you for doing a terrific and diligent job packaging and testing kernels and, which come into testing in short order. 2) Florian: Thank you for your comments - agree completely. 3) Adding to what Florian said - Testing also allows Arch users to signoff after performing their own testing which strengthens the program by adding broader testing across different systems. -- Gene li...@sapience.com
Re: [arch-general] [arch-dev-public] OpenSSL 1.1.0
May want to warn anyone running dovecot that sslv2 is no longer supported in openssl 1.1. And so if conf.d/10-ssl.conf has this line: ssl_protocols = !SSLv2 !SSLv3 this will lead to error and mail not working - change to: ssl_protocols = !SSLv3 -- Gene li...@sapience.com
Re: [arch-general] About linux 4.8 and 4.9...
On Tue, 2017-01-10 at 16:55 +, Mike Cloaked via arch-general wrote: > On Tue, Jan 10, 2017 at 1:53 PM, Carsten Mattner via arch-general < > arch-general@archlinux.org> wrote: > > > ... > > > > Looks like there are some patches to try and are being tested for > kernel > 4.9 - see https://bugzilla.kernel.org/show_bug.cgi?id=191121 > For me this is an EFI issue introduced in 4.9-rc1 - as described in https://bugzilla.kernel.org/show_bug.cgi?id=191801 https://bugzilla.kernel.org/show_bug.cgi?id=191121 the EFI patch applied to 4.10-rc3 is now bootable again. I need to test 4.9.2 as well but am pretty sure this will work too. I will note that not everyone having issues is using efi - so there could well be more than one issue involved here. regards, -- Gene li...@sapience.com
Re: [arch-general] Getting freeze on early start with linux 4.9-1 kernel.
On Fri, 2016-12-23 at 13:59 +0100, fredbezies via arch-general wrote: > Hello. > > I'm facing an annoying bug with linux 4.9-1 kernel on my 6 or 7 years > old Toshiba Laptop. When I try to make it boot on with linux 4.9-1 > kernel, it freeze right after loading initramfs. Please add to this bug report: https://bugzilla.kernel.org/show_bug.cgi?id=191801 > > > -- Gene li...@sapience.com
Re: [arch-general] Getting freeze on early start with linux 4.9-1 kernel.
On Fri, 2016-12-23 at 13:59 +0100, fredbezies via arch-general wrote: > ... > > I opened a bug : https://bugs.archlinux.org/task/52246 I added a comment to your bug report. I have one computer which doesn't boot under 4.9 - this started with 4.9-RC1 ( i build and test all kernels) and still have same problem with 4.9 final. As I asked in your bug report, can you identify the processor as well. Here is what I am seeing as of now - one Ivy Bridge laptop does not boot. Lenovo Laptop W540 Ivy Bridge i7-4700 MQ - Boot Failed Lenovo Laptop W520 Sandy Bridge i7-2720QM - OK Desktop Ivy Bridge I7-4770 - OK Desktop Ivy Bridge i7-4790 - OK Desktop Ivy Bridge i7-4771 - OK Desktop Core i7 Lynnfield (860) - OK Desktop Ivy Bridge i7-4770K - OK Desktop Skylake i5-6260U- OK (except i do have continued graphis Display port Problems - have to reboot 1 - 10 times before it works - true in 4.8.x as well). gene -- Gene li...@sapience.com
Re: [arch-general] out of date packages - an observation
On Thu, 2016-09-08 at 10:15 +0200, Jelle van der Waa wrote: > > > Not sure what you are trying to achieve with this email, but it's My point was just that by focussing on the more important packages, it seems to me Arch is doing pretty well in my view - the glass is half full so to speak. > actually a bit worse. We have 189 (i686/x86_64 included) packages which Yep indeed - I did the count approach as well at first - but I found it more helpful to poke around a little more and try to take into consideration importance, don't double count different arch's, dont double count related packages (e.g. gambas*, util-linux and libutil- linux etc). My goal was to tease apart the raw counts into something I found more meaningful. It is certainly true that different folks will lkely view importance differently or have different perspectives to my own. I'm only speaking for myself here. As an aside - both the 4.7.3 kernel and util-linux are already up to date :-) gene > -- Gene li...@sapience.com
[arch-general] out of date packages - an observation
After the recent dicsussion(s) around this topic I thought it worthwhile to go through where things stand. I went through all the packages flagged out of date on the website and focused on what I viewed as the "more important" ones (this is IMHO of course ... I'm sure others have differnt views). Regardless of how out of date a package is, if a new package was in testing I did not include it here. Of those that passed my sufficiently important filter: I found only 2 packages more than 1 week old and 3 less than a week - 2 of which were released upstream today. One is more than 9 months out of date (refind-efi). Here's what I found orderd most out of date at the top.. refind-efi - Arch vesion 0.9.2 as of 9/22/2015 - Upstream has 0.10.3 from 4/24/2016 - this one is very out of date - - be good to have this updated. openssl - Arch has 1.0.2.h - Out of date as of 8/25/2016 - 1.1.0 was released upstream on 8/25/2016 dkms - Out of date as of 9/1/2016 - Arch Package website refers to dell.com should be changed to https://github.com/dell/ util-linux - 2.28.2 was released today - - arch has 2.28.1 released 8/11/2016 linux - 4.7.3 is out of date as of today -- Gene li...@sapience.com
Re: [arch-general] [arch-dev-public] Signoff report for [testing] - KDE pacman install errors
> On Sun, 2016-08-21 at 10:09 -0400, Genes Lists via arch-general wrote: > Tried to update today but I am getting the following errors: This has been resolved and the error has gone (stale mirror perhaps?) Anyay - sorry for noise. -- Gene li...@sapience.com
Re: [arch-general] [arch-dev-public] Signoff report for [testing] - KDE pacman install errors
On Sun, 2016-08-21 at 08:07 +, Arch Website Notification wrote: > === Signoff report for [testing] === > https://www.archlinux.org/packages/signoffs/ > > There are currently: > * 402 new packages in last 24 hours > * 0 known bad packages > * 0 packages not accepting signoffs > * 12 fully signed off packages > * 414 packages missing signoffs > * 4 packages older than 14 days > > Tried to update today but I am getting the following errors: :: Starting full system upgrade... :: Replace akonadi-contact with testing/akonadi-contacts? [Y/n] :: Replace kdegraphics-kolourpaint with testing/kolourpaint? [Y/n] :: Replace kdesdk-cervisia with testing/cervisia? [Y/n] :: Replace kdeutils-kdf with testing/kdf? [Y/n] resolving dependencies... looking for conflicting packages... :: kldap and kio-pim are in conflict. Remove kio-pim? [y/N] y error: failed to prepare transaction (could not satisfy dependencies) :: kde-meta-kdegraphics: removing kdegraphics-kolourpaint breaks dependency 'kdegraphics-kolourpain t' :: kde-meta-kdesdk: removing kdesdk-cervisia breaks dependency 'kdesdk- cervisia' :: kde-meta-kdeutils: removing kdeutils-kdf breaks dependency 'kdeutils-kdf' Trying to say 'no' to kde-pim leads to this error: :: kldap and kio-pim are in conflict. Remove kio-pim? [y/N] error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: kldap and kio-pim are in conflict -- Gene li...@sapience.com
Re: [arch-general] very out of date packages
On Sun, 2016-08-14 at 15:27 -0500, Dutch Ingraham wrote: > > I would argue it is not the raw number or percentage of packages that > are out of date, but *which* packages are out of date. For example, > I > wouldn't place equal weight on pychess as I would glibc. Agree with this completely - some packages in core are more 'tier 1' ... others. We should focus on the more important ones - of which there a small number based on my quick scan. We are a volunteer org and overall things are PDG (pretty damn good) :-) - and we are all very grateful for the time put in by those who are helping making Arch a premier distro. Thank you! gene -- Gene li...@sapience.com
[arch-general] very out of date packages
refind-efi has been flagged out of date for 9 months. Are there any packagers who would be willing to take this one over? It is not the most out of date even ... but it's an important component for those who boot with it. There are plenty of others which are also very out of date. I counted over 220 packages marked out of date. Of those nearly 20 were flagged in 2015 or earlier. Some of them have newer versions in AUR; but it would be good to try get at least some of these updated. What's the best way to tackle this issue? -- Gene li...@sapience.com
[arch-general] texlive-bin 2016.41290-2.1
There is a little noise on install Are these fixable - or benign? (9/9) upgrading texlive- bin [] 100% >>> texlive: updating the filename database... recreating all formats...fmtutil [WARNING]: inifile aleph.ini for aleph/aleph not found. fmtutil [WARNING]: inifile lambda.ini for lamed/aleph not found. done.
Re: [arch-general] [arch-dev-public] signoffs are dead
On Sat, 2016-07-02 at 09:16 +1000, Allan McRae wrote: > > This sounds like the Fedora policy where packages have to surpass a > certain karma level to move into the main repositories. I'm not sure > who gets to vote for that though. > > A I would suggest allowing any Arch user vote yay or nay (with comments) - I believe this is what fedora did - only requirement was to be a registered user of the website. I don't imagine significantly more information will be obtained beyond the issues raised now in the mail list and forum. However, it does have the advantage of putting it in a single place for the packager. gene
