[arch-general] Any arch-general changes since 9/24 -- I get no messages (but I see my messages in the archive)?
Archdevs, Were there any mailing list changes since 9/24 that would explain why I no longer get any arch related messages delivered to my inbox? The last message I received was "Abuse of arch wiki" on 9/24. I see other messages in https://lists.archlinux.org/pipermail/arch-general/ as well as the pacman suggestion I sent, but I get nothing on my end. Suddenlink ISP issue? -- David C. Rankin, J.D.,P.E.
[arch-general] Belated Arch-Conf pacman improvement suggestion
Allan, While the pacman part of the conference is over, I just ran into an issue that would fit the pacman improvement segment. When updating, if on the first repo, the first mirror selected times-out, then mark that repo failed for the remaining repo checks so you don't sit through two more timeouts on a repo that is known failed at that point. If arch.mirror.constant.com was down yesterday, I could have made the segment :) -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Abuse of arch wiki?
On 9/24/20 1:55 PM, Eli Schwartz via arch-general wrote: > Mirroring a really old copy of the wiki is kind of unethical because > they're spreading ancient out of date knowledge pretending to be modern, > but I don't see how it's a problem for attribution. > > Moreover, they're not the only ones doing similar, see for example > https://aur.tuna.tsinghua.edu.cn/ Seems a diplomatic cease-and-desist letter is in order giving them the opportunity to bring the mirror current if they choose that course and that is acceptable to arch. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
[arch-general] Tbird 78.2 enable Master Password of GPG keys stored in profile unencrypted
All, Just a heads up. SuSE has been doing work with Thunderbird 78.2 trying to prepare for a move to it with the openPGP replacement for Enigmail. One issue that has come from that is the realization that unless you enable a Master Password for thunderbird passwords, once you import your GPG keys, they will be stored unencrypted in your thunderbird profile. If you have never set a mater password for thunderbird before (I haven't), it looks like that will be required with 78.2 hits. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] pam_faillock -- can we just remove it from /etc/pam.d/login?
On 9/12/20 1:48 AM, Jan Alexander Steffens wrote: > Succeeding even once should clear the log of failures, thus giving you > another three attempts. This seems reasonable to me. Is this not > working as advertised? I didn't lock the box to check. I was going though faillock.conf to determine if it would allow some setting that would do just that. (the notes didn't indicate a clearing on success). If it works that way, then it would be fine. I have had times when I am using sudo heavily (several times a minute) and if the fails were cumulative over the default period that would be a problem. I'll check that this works on a local box, I didn't want to risk a test on a remote box. -- David C. Rankin, J.D.,P.E.
[arch-general] pam_faillock -- can we just remove it from /etc/pam.d/login?
Following the [arch-dev-public] Pam lockout thread, Can we just remove the faillock entries from /etc/pam.d/login without breaking anything if we don't need it at all (like for home computers, etc..) The any 3 attempts in 15 minutes which is the default under faillock.conf: # The default is 900 (15 minutes). # fail_interval = 900 means that if I mistype a password on login, then 10 minutes later mess up with sudo, and then 14 minutes later have another slip with sudo, I'm locked out by faillock. That seems like overkill for home users. It should be limited to 3 failed logins at a single prompt, not any 3 in 15 minutes. # admin_group = is another option -- but at this point, I'd rather just remove it from the pam stack. Is that doable? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] brltty - Detected unsafe path transition /etc → /etc/brlapi.key Howto Fix?
On 05-09-2020 22:44, David C. Rankin wrote: > All, > >On system update, I get the following related to the brltty[1] package: > > (2/7) Creating temporary files... > Detected unsafe path transition /etc → /etc/brlapi.key during canonicalization > of /etc/brlapi.key. > error: command failed to execute correctly > > Apparently this package was installed as a dependency of qemu. > >I generally do not want to ignore errors on update, so how do I fix this > problem? The package was updated August 29, but the issue continues. Should I > just delete the key and let qemu start over with a new one in a new location? > Checked https://wiki.archlinux.org/index.php/QEMU, but nothing noted. > > [1] https://www.archlinux.org/packages/extra/x86_64/brltty/ > cc'ing David, if everything works as intended he should see this message twice. I have that file also. its content is a number in ASCII text. https://github.com/archlinux/svntogit-packages/blob/packages/brltty/trunk/brltty.tmpfiles is what triggers that message . Does that match the permissions of the file on your system ? Lone_Wolf === Yes, thank you for pointing the permissions out, but they are 0640, e.g. $ l /etc/brlapi.key -rw-r- 1 root brlapi 33 Oct 19 2016 /etc/brlapi.key Seems like this message popped up in the last couple of weeks.
[arch-general] arch-general list down?
All, I have no posts from arch-general since 8/30. I have tried to post related to a pacman update issue, but the posts are not getting though?? -- David C. Rankin, J.D.,P.E.
[arch-general] brltty - Detected unsafe path transition /etc → /etc/brlapi.key Howto Fix?
All, On system update, I get the following related to the brltty[1] package: (2/7) Creating temporary files... Detected unsafe path transition /etc → /etc/brlapi.key during canonicalization of /etc/brlapi.key. error: command failed to execute correctly Apparently this package was installed as a dependency of qemu. I generally do not want to ignore errors on update, so how do I fix this problem? The package was updated August 29, but the issue continues. Should I just delete the key and let qemu start over with a new one in a new location? Checked https://wiki.archlinux.org/index.php/QEMU, but nothing noted. [1] https://www.archlinux.org/packages/extra/x86_64/brltty/ -- David C. Rankin, J.D.,P.E.
[arch-general] arch-dev-public Re: Bug tracker migration
On 8/29/20 6:02 PM, Frederik Schwan via arch-dev-public wrote: > Please make sure you all have a working account at our Gitlab instance. > If this change is 2-weeks away, shouldn't there be a note at least at the following existing sites informing folks that a new gitlab account will be needed? Site where notice of the change would make sense: bugs.archlinux.org or https://wiki.archlinux.org/index.php/Getting_involved#Fix_and_report_bugs -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman -Syu -- Applying kernel sysctl settings... Not setting ... Worry?
On 8/22/20 3:16 AM, Daan De Meyer via arch-general wrote: > I fixed a bug in systemd where its binaries would output to the journal > instead of stdout when invoked as a child process by pacman. This output > was always there, you just didn't see it until now because it went to the > journal instead of stdout. I get the same messages so I wouldn't worry > about it. Thank you Daan, That is all I needed to know. -- David C. Rankin, J.D.,P.E.
[arch-general] pacman -Syu -- Applying kernel sysctl settings... Not setting ... Worry?
Arch devs, For the past several updates, I have noticed the kernel sysctl settings messages saying: ( 5/17) Applying kernel sysctl settings... Not setting net/ipv4/conf/all/rp_filter (explicit setting exists). Not setting net/ipv4/conf/default/rp_filter (explicit setting exists). Not setting net/ipv4/conf/all/accept_source_route (explicit setting exists). Not setting net/ipv4/conf/default/accept_source_route (explicit setting exists). Not setting net/ipv4/conf/all/promote_secondaries (explicit setting exists). Not setting net/ipv4/conf/default/promote_secondaries (explicit setting exists). After the recent netctl message issue, I want to nail down what set these in /proc and whether it is something I need to do something about. I didn't set any of these specifically, so I presume they are either explicit settings made during the kernel build or they were set somewhere long ago by some previous Arch default. In either case, if there were no issues, I wouldn't expect pacman to go out of its way to tell me about them if nothing needs to be done. Though I can also see the messages just being some default behavior of whatever the kernel sysctl hook is warning about choices that are explicitly set. Do I need to do anything about these? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] netcl leaves network down until reenable performed - do we need note?
On 8/21/20 12:25 AM, Eli Schwartz via arch-general wrote:
>> That might have been an interesting precautionary measure for netctl
>> 1.18, at least for printing a message advising people to reenable the
>> service.
> Oh, for the record -- it looks like netctl already did this:
>
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/netctl.install?h=packages/netctl
>
> post_upgrade() {
> if [[ $(vercmp 1.18 "$2") -gt 0 ]]; then
> grep -ls '^.include ' /etc/systemd/system/netctl@*.service | \
> while read -r unit; do
> profile=$(systemd-escape --unescape "${unit:27:-8}")
> echo ":: The unit for profile '$profile' uses deprecated
> features."
> echo " Consider running: netctl reenable $(printf '%q'
> "$profile")"
> done
> fi
> }
The fallibility of human infallibility...
You can lead a horse to water, but you can't make 'em drink :)
Thank you Eli, at least we know now the distribution was 1-step ahead.
--
David C. Rankin, J.D.,P.E.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] No login after update
On 8/20/20 3:52 PM, Damjan Georgievski via arch-general wrote: > Now I don't understand all the defensiveness - let's all work together > to improve things. This is not a non-issue. That's the Arch I fondly remember. You are on this list either because (1) you want to help, or (2) you need help. Both are best accomplished with courtesy and civility and nothing more. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Gaetan Bisson Resignation
On 8/20/20 4:24 AM, Amin Vakil via arch-general wrote: > Hello, > > I'm not an Arch Linux Developer myself, so I'm not allowed to reply to > this email on arch-dev-public. > Gaetan began at a time when things were different at Arch, there was just arch-dev, and it was open to community posts under Allan's stewardship. That transparency and community involvement served Arch well and served as a moderating influence on the direction of Arch. He will be missed and we wish him well in his future endeavors. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
[arch-general] netcl leaves network down until reenable performed - do we need note?
Archdevs, I have two computers using netctl, one for a static and one for a dhcp address. After the last update on May, 3, netctl (1.22-1 -> 1.23-1) all remained fine and old profiles generated as subservices in /etc/systemd/system, such as: netctl\@rlf_network\\x2dstatic.service continued to bring the network up. However within the past week there was a change, likely to systemd 246, that no longer respects the subservices originally created by netctl. Now attempting at reboot causes the network to fail completely. Not good for remotely adminned boxes. What is required is a "reenable" of the netctl profile. Doing so will remove the old subservice and symlinks and replace then with a directory in /etc/systemd/system of same name as the old subservice, but with a ".d" appended that now contains a "profile.conf", e.g. netctl@rlf_network\x2dstatic.service.d/ └── profile.conf However, there is no note or warning during update that any manual intervention will be needed. That will leave anyone adminning a remote arch install with netctl with a box that is unreachable and has no network. Shouldn't there be a warning about this change generated on update? Arch is always pretty good about warning when manual interaction is required -- and this is a biggie. Couldn't there also be a post install that does a reenable for each netctl profile found in /etc/systemd/system as another option to avoid this SNAFU? -- David C. Rankin, J.D.,P.E.
[arch-general] AUR - Best Practices when Package no longer Supported for Linux upstream but LTS fine?
Arch devs, Quick AUR question. The virtualbox 5.2 branch is unsupported as of July 2020. Oracle continues to put out testbuilds for 5.2, but currently it does not build with 5.8 (LTS is fine). I am still awaiting answers on the vbox-end-users list as to whether anything compatible will be released either as a testbuild case or as a release (Oracle seems a bit undecided) If 5.2.44 was the last release and there will be no update to support Linux 5.8 -- what do I do with the package? Do I mark it LTS only in some way, or just have it removed? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
On 8/15/20 3:07 AM, ProgAndy wrote: > It was mentioned on arch-dev-public: > > https://lists.archlinux.org/pipermail/arch-dev-public/2020-March/029895.html > > There were no maintainers that were able to test the legacy nvidia packages > anymore, so they had to be dropped. > > Unofficial binary packages are available in the disastrousaur[1] and jlk[2] > repositories. > The AUR package is mostly repackaging the upstream binaries anyways, only the > kernel module is built from source. > So I don't think it would be too bad to install it from the AUR. > > [1]: > https://wiki.archlinux.org/index.php/Unofficial_user_repositories#disastrousaur > > [2]: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#jlk Thank you, Yes, when you build the nvidia-390xx from AUR you have the option of installing nvidia-390xx or nvidia-390xx-dkms which is as you explain handles the rebuild of the kernel modules. My only concern there, as with the 5.2 branch of VirtualBox I package for AUR, builds break on kernel update. The vbox 5.2.45 (testbuild 139677) still fails to build the kernel modules for 5.8. If something like that were to happen with the nvidia driver, then you would simply break X on all affected laptops until the AUR maintainer could update the package. AUR is good, but it certainly is no where near as reliable as having a maintained package for critical drivers. Moreover, with vbox, your guest may be offline until an update is provided, but your computer still works. With graphics driver -- you are not as lucky. I'm sure the testing could have been arranged to preserve the 390xx driver -- I would have been more than happy to do it. We will see how it goes, but I'm not going to update to 5.8 and roll the dice yet. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
On 8/14/20 3:18 AM, David C. Rankin wrote: > Additionally, I've done a completely additional reinstall: > > # pacman -Qqn | pacman -S - > > All goes well, no errors, but the boot still hangs on tty1 and no GUI or X is > every started though sddm says it is running. > > I think it is time to wipe the slate clean and reinstall unless anyone has a > better idea? GAH The original reinstall would have solved everything -- but for Arch removing the nvidia-390xx packages, WTF?? There were no new ones there so the 390.116 packages installed on my Laptop were never updated causing boot to hang. That is a shame. You just can't pull a videocard out of your i7 laptop to update for fun, and you sure can't run desktop effects in KDE without it. I'm not sure I understand the logic in Arch dropping the 390xx drivers relegating a host of laptops Quadro cards to trying to build the nvidia-390xx, the utils and settings package. Even following the list, I don't recall a discussion about the discontinuation and there was no warning on update or error on reinstall. But, it is done, and aside from the netctl SNAFU and the nvidia surprise, the update from 6/19 to 8/20 worked just fine -- which is pretty amazing. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
On 8/14/20 1:04 AM, David C. Rankin wrote: > I have no clue what this assignment outside of section is telling me. I > haven't changed the wireless config at all. Any idea on this or the boot hang > issue? What to check? > I fixed the netctl issue. It seems the netctl interface with systemd changed and the normal subsystem service file has been turned into a service.d directory containing 'profile' files. A reenable of the profile removed the old symlinks and service file and replaced them with the service.d directory using # netctl reenable the_profile Network is up and happy again. Additionally, I've done a completely additional reinstall: # pacman -Qqn | pacman -S - All goes well, no errors, but the boot still hangs on tty1 and no GUI or X is every started though sddm says it is running. I think it is time to wipe the slate clean and reinstall unless anyone has a better idea? The original install was from 2016 so it was a bit old, but still working well before the ill-fated update. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
On 8/10/20 11:00 PM, Eli Schwartz via arch-general wrote: >> pacman is fully updated now, right? So if I take that list and go back and >> try re-running the hooks -- that may be one way to fix it? Worse come to >> worse, I'll just wipe /root and reinstall... > Depends on the hook. Some of them use NeedsTargets, so the Exec command > needs to receive the list of triggering files on stdin. > > Reinstalling all currently installed packages would have the same > effect, no need to wipe anything. If you have the list of packages which > were updated at that time, you could just update them alone. > > Otherwise it might take a bit of fiddling to ensure every hook runs > correctly. > >> So for my edification -- what happened was after update, the new pacman was >> installed along with the new hooks, but since the pacman I ran the update >> from >> was too old, it croaked trying to run the new hooks from the updated pacman? >> >> Will we give it a go. > Correct. > > Again, using > https://aur.archlinux.org/packages/pacman-static#pinned-666894 renders > this concern irrelevant since you'd end up running the most recent > pacman in order to perform the update and run hooks. Well... I booted, and reinstalled all 1568 files and all 28 hooks ran successfully: # cd /var/cache/pacman/pkg # pacman -U $(find . -type f -newermt 20190627 -printf " %f) Everything completed successfully, all dkms drivers rebuilt for 5.7.12, all appears to be working fine -- except the network and the boot hangs at the exact same place on tty1, but login is fine on tty2, sddm is started, but there is no graphical display. I wonder if the network is causing the hang with boot on tty1. When I manually try and restart the wireless card, I get: Aug 14 00:38:46 seidr systemd[1]: /etc/systemd/system/netctl@wlo1_wireless_skyline.service:1: Assignment outside of section. Ignoring. Aug 14 00:41:34 seidr systemd[1]: Starting (Re)store the netctl profile state... Aug 14 00:41:35 seidr netctl[553]: Could not read state file '/var/lib/netctl/netctl.state' Aug 14 00:41:35 seidr systemd[1]: Finished (Re)store the netctl profile state. The service file is the same as it has been: # cat /etc/systemd/system/netctl@wlo1_wireless_skyline.service .include /usr/lib/systemd/system/netctl@.service [Unit] Description=A wpa_supplicant configuration file based wireless connection BindsTo=sys-subsystem-net-devices-wlo1.device After=sys-subsystem-net-devices-wlo1.device I have no clue what this assignment outside of section is telling me. I haven't changed the wireless config at all. Any idea on this or the boot hang issue? What to check? -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
On 8/10/20 10:10 PM, Eli Schwartz via arch-general wrote: > After that many errors, why did you try rebooting without fixing things > first? The obvious first step is to try rerunning all of those hooks > using a modern pacman. > > (Do not do a year's worth of updates in one go like that, it's not > tested and might break. It is preferred instead to do incremental > updates via https://wiki.archlinux.org/index.php/Arch_Linux_Archive in > e.g. monthly increments, but if you insist on doing the whole thing in > one shot then at least use the latest version of pacman via my > pacman-static binaries, or the install media + pacman --sysroot /mnt -Syu) Thank you Eli, Well, to be honest, I knew pacman had been updated and I thought rebooting would fix it :) -- Oh well, maybe not pacman is fully updated now, right? So if I take that list and go back and try re-running the hooks -- that may be one way to fix it? Worse come to worse, I'll just wipe /root and reinstall... So for my edification -- what happened was after update, the new pacman was installed along with the new hooks, but since the pacman I ran the update from was too old, it croaked trying to run the new hooks from the updated pacman? Will we give it a go. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
[arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
file /etc/xdg/autostart/klipper.desktop is marked executable. Please remove executable permission bits. Proceeding anyway. Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No such file or directory Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No such file or directory Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No such file or directory Aug 10 17:13:20 seidr systemd[500]: Not generating service for XDG autostart app-at\x2dspi\x2ddbus\x2dbus-autostart.service, startup phases are not supported. Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No such file or directory Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No such file or directory Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No such file or directory Aug 10 17:13:20 seidr systemd[500]: Not generating service for XDG autostart app-kaccess-autostart.service, only Type=Application is supported. Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No such file or directory Aug 10 17:13:20 seidr systemd[500]: Not generating service for XDG autostart app-pulseaudio-autostart.service, startup phases are not supported. Aug 10 17:13:20 seidr systemd[500]: Not generating service for XDG autostart app-powerdevil-autostart.service, only Type=Application is supported. Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No such file or directory Aug 10 17:13:20 seidr systemd[495]: Queued start job for default target Main User Target. Aug 10 17:13:20 seidr systemd[495]: Reached target Paths. Aug 10 17:13:20 seidr systemd[495]: Reached target Timers. But tty1 is still hung -- no display manager is loaded and I'm stuck on tty2. I'm not sure what is stuck or what to kill to try and fix it. Before the update sddm was fine and I loaded fluxbox to do the update rather than doing it from within KDE. What do I check to try and bring the system back to a working state? What to check? -- David C. Rankin, J.D.,P.E.
[arch-general] Estimate on when 5.8 will hit core? - (Virtualbox Still Won't Build)
Devs, Just a quick check on when 5,8 is going from testing to core? I ask because Virtualbox still is not ready for 5.8: https://www.virtualbox.org/ticket/19644 -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Why bind-tools was merged into bind package?
On 7/20/20 2:15 AM, Óscar García Amor via arch-general wrote: > The problem is. Where is the limit? The whole distribution in one > package? The argument is the same, if you don't need it simply don't > use it. If you read the git-commit regarding the change, the packages were combined because there is no longer any significant install size saving splitting the package. The libraries used by the bind-tools apps (1.7M) is not 8X larger than the dns daemon (0.2M) so it no longer made sense to split the package from a size-saving standpoint: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/bind=c688d695dc4e82aad9a7ec546bc47e4b5fe5c447 -- David C. Rankin, J.D.,P.E.
Re: [arch-general] What do you do with pacman.log? Periodically archive? Delete?
On 06/18/2020 02:03 AM, Andy Pieters wrote: > On Thu, 18 Jun 2020 at 07:51, Ralf Mardorf via arch-general < > arch-general@archlinux.org> wrote: > >> annoying to use search with 'grep'. However, since the file is that >> small and the complete history could become important, I don't remove it. >> > Same here, I made some awk scripts to format it but I will never ever > delete it. Why would you want to delete a log of what packages were > installed and removed? Thanks Ralf, Andy, I didn't go looking to delete or remove anything. I went to fix grep reporting pacman.log as binary data due to the html/UTF-8 '→' that was written to the log numerous time during the late 2017 - 2018 timeframe. After fixing the log, then I wondered if there was anything I should do with it since it went back to 7 years. Storage isn't an issue: # df -h Filesystem Size Used Avail Use% Mounted on /dev/md1 50G 23G 27G 47% / tmpfs16G 4.0K 16G 1% /tmp /dev/md0469M 106M 351M 24% /boot /dev/md2865G 510G 355G 59% /home /dev/md42.7T 945G 1.8T 35% /home/data So for know -- we will just do nothing with it. If push came to shove either writing a quick wrapper to pacman to xz unzip/zip or splitting it by year, or some other sane criteria may be an option. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] What do you do with pacman.log? Periodically archive? Delete?
On 06/18/2020 01:12 AM, Eli Schwartz via arch-general wrote: > Among other things, it serves as a handy way to tell when you first > installed the system. :) > > I have so many better places to save 5mb of disk space, this doesn't > even register in the top 400. Gotcha -- and so it shall be stricken from my list of concerns :) -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
[arch-general] What do you do with pacman.log? Periodically archive? Delete?
This is more of what is the recommended practice ... for handling pacman.log? Strange question, yes, but pacman.log is one of those that never gets rotated, etc.. The information in it isn't useful after a few upgrade cycles. So what is the general practice for dealing with it? o Periodically delete it? o Split it by year with awk and compress it for?? Historical reasons? o Keep the last year? It not one of those things I've ever thought about before, but grepping (after cleaning up the wide-character right-arrow from 2017/18 timeframe), I checked and I have 5M of log dating back to 2013. It's not hurting anything, but that got me thinking? What do others do with it, and is there any recommended manner for dealing with it? I don't see any reason for keeping much of it beyond what you may be asked to post as part of a bug-report, etc.. which usually wouldn't be more than the last couple of months for most packages.. man 8 pacman doesn't provide any options for dealing with how much to keep or to truncate. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] dash as default shell?
On 06/17/2020 01:18 PM, Piscium via arch-general wrote: > Today I set dash as my default shell [1] on two PCs. We will see if I > get into trouble. > > This question was asked years ago but maybe good to ask again. Could > dash be made the default shell in Arch? Please NO. Bash has been the default, and while there is nothing wrong with a Bourne-again (or Debian Almquist) type shell, it would break more than a decade of setups... If you want Dash, make the change after install. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Keyboard Problem in Mate Arch Linux for the Last Few Days
On 06/13/2020 04:04 AM, das via arch-general wrote: > > And, as you said, I will upload those three small PNG files somewhere > and post the links here as soon as I can. > As a general note, http://paste.opensuse.org/ provides a quick pastebin type site for temporary uploads where you can limit the lifetime for 1-week, 1-month, etc... Image uploads and language syntax highlighting is provided for code/text. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] pacman system update - Why am I prompted to import a specific key?
On 06/12/2020 09:24 PM, mpan wrote: >> On update today (yesterday's updates went fine), I am prompted to approve >> import of the following key a number of times: […] >> :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) […] > Oh, “the heftig bug” ;). While Simon Wilper has provided the solution, > here is some background: > > “[…] I replaced it to get a clean break for a new key, which I'm > treating more securely from the beginning (no secret keys on the > laptop, just subkeys on a yubikey and the master key on a few > backups)” —heftig > > -Syu often to avoid problems. > Oh So there was a private key that escaped into the wild... That would be a big bug... Thank you for the background. I generally -Syu daily (at most every few days) -- which is why this event immediately jumped out as not normal. I hope he got the laptop back :p -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman system update - Why am I prompted to import a specific key?
On 06/12/2020 01:23 PM, Simon Wilper wrote: > Hello David, > >> On update today (yesterday's updates went fine), I am prompted to approve >> import of the following key a number of times: > > doesn't this happen when the package archlinux-keyring got updated? So > doing a pacman -Sy archlinux-keyring first and then the -Su worked for me. > > > Simon > Strange, Since 2009, and thousands up updates over 1/2 dozen boxes, this is the only time this has happened using simply pacman -Syu -- David C. Rankin, J.D.,P.E.
[arch-general] pacman system update - Why am I prompted to import a specific key?
All, On update today (yesterday's updates went fine), I am prompted to approve import of the following key a number of times: (108/108) checking keys in keyring [##] 100% downloading required keys... :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] Y :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] Is this normal? (email address intentionally truncated) -- David C. Rankin, J.D.,P.E.
[arch-general] pacman system update - Why am I prompted to import a specific key?
All, On update today (yesterday's updates went fine), I am prompted to approve import of the following key a number of times: (108/108) checking keys in keyring [##] 100% downloading required keys... :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] Y :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] :: Import PGP key 3B94A80E50A477C7, "Jan Alexander Steffens (heftig) "? [Y/n] Is this normal? (email address intentionally truncated) -- David C. Rankin, J.D.,P.E.
Re: [arch-general] community/NUT access cgi in /usr/share/nut/cgi without FollowSymLinks?
On 06/05/2020 04:04 AM, Maxime Gauduin via arch-general wrote: > > Hi David, > > I haven't used apache in years so please take this with a grain of > salt. On nginx I'm using the alias directive, restricting access to > the upsset.cgi to my local network [0], as suggested by the nut > documentation in /etc/upsset.conf. It seems apache has a similar alias > directive so you may be able to achieve the same without using any symlink > [1]. > > [0] https://paste.xinu.at/BNUJFeuBycXUw8fB/ > [1] https://httpd.apache.org/docs/2.4/mod/mod_alias.html#alias > > Cheers, > Thanks for the reply, I already use the alias for the html directory, but the problem is with the cgi scripts since the default cgi-bin directory is /srv/http/cgi-bin, you cannot declare a second alias for cgi-bin to /usr/share/nut/cgi -- apache will fail to start due to conflicting aliases. Currently I have: ## nut directory Alias /nut/ "/usr/share/nut/html/" Alias /nut "/usr/share/nut/html/" ... Options +ExecCGI The problem is that the link in the nut files is hardwired to, e.g.: http://yourdomain.tld/cgi-bin/nut/upsstats.cgi so it looks for the cgi-bin directory off of the document root not under /usr/share/nut/cgi and you can't alias to /cgi-bin/nut to /usr/share/nut/cgi because /cgi-bin/nut will never match due to the default alias of /cgi-bin. So it looks like the way I have it will have to work, otherwise we have to hack the urls in the nut/html files to look for the cgi scripts in /usr/share/nut/cgi instead of under /cgi-bin/nut -- David C. Rankin, J.D.,P.E.
[arch-general] community/NUT access cgi in /usr/share/nut/cgi without FollowSymLinks?
All / Maxime, With the nut build option setting: --with-cgipath=/usr/share/nut/cgi \ when using apache with the default /srv/http/cgi-bin location, how are you supposed to access the cgi files in /usr/share/nut/cgi "Safely"? I have the entire /usr/share/nut/html directory protected by a dbm database file manipulated with dbmmanage, so to reach the you must authenticate. That said, the only way I can make the cgi scripts work is by setting Options FollowSymLinks in the for "/srv/http/cgi-bin" after symlinking (e.g. ln -s /usr/share/nut/cgi /srv/http/cgi-bin/nut) Is this safe? Is this intended way to provide access to the cgi scripts? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Arch should be apolitical
On 06/01/2020 07:57 PM, Kevin Dodd via arch-general wrote: > The FOSS movement was called a "movement" for a reason. It was always about > giving power to the people who would otherwise have none, and getting the > boots of the powerful off of their backs. Pride month fits that ethos > perfectly. > > If you don't want to see the logo, you can either use custom CSS or simply > ignore it. This is such a non-problem. I'm sorry Kevin, You misinterpreted my reply. I know FOSS well, from before the time of NCSA Mosaic. The intent was, regardless of what is depicted, it doesn't impact adversely impact another. I'm more than happy to see pride month celebrated or supported and whether Arch chooses to participate or not isn't something I see as political. (thus the "It isn't hurting me [or anyone else] at all" comment) So I apologize if the intent you gleaned differed from that intended conveyed. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Arch should be apolitical
On 06/01/2020 07:57 PM, Kevin Dodd via arch-general wrote: > The FOSS movement was called a "movement" for a reason. It was always about > giving power to the people who would otherwise have none, and getting the > boots of the powerful off of their backs. Pride month fits that ethos > perfectly. > > If you don't want to see the logo, you can either use custom CSS or simply > ignore it. This is such a non-problem. I'm sorry Kevin, You misinterpreted my replay. I know FOSS well, from before the time of NCSA Mosaic. The intent was, regardless of what is depicted, it doesn't impact adversely impact another. I'm more than happy to see pride month celebrated or supported and whether Arch chooses to participate or not isn't something I see as political. (thus the "It isn't hurting me [or anyone else] at all" comment) So I apologize if the intent you gleaned differed from that intended conveyed. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Arch should be apolitical
On 06/01/2020 06:18 PM, Amir Fletcher via arch-general wrote: > Arch Linux is a fantastic distribution. It should remain exactly that: a > computer operating system for technical users. Politics should not be part > of the project. > > Recently, the Arch reddit logo was changed to a rainbow. This is for "pride > month". It is forcing a political view on all of the users who did not ask > for this. Many of us don't care about the views of the developers or > moderators as long as we continue to enjoy Arch. > > When this was brought up, the moderator silenced the criticism and deleted > the thread. > > https://old.reddit.com/r/archlinux/comments/gutcxb/is_arch_gay/ > > https://archive.is/Y9Ni1 Just ignore it. If it makes some feel better, so be it. It isn't hurting me at all... and whatever the intent, it doesn't have a deleterious effect on Arch. Rainbows, ponies, penguins, geckos, hats, all just nice decorations. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] community/NUT replacing Network-UPS-Tools -- won't start.
On 05/29/2020 05:29 AM, Maxime Gauduin via arch-general wrote: > Hi David, > > The configuration for nut is now in `/etc/nut` as it should be, instead > of `/etc/ups`. You will need to migrate your previous configuration. > Modified the wiki to reflect that. > > Cheers, Uugh... Thank you! -- David C. Rankin, J.D.,P.E.
[arch-general] community/NUT replacing Network-UPS-Tools -- won't start.
On upgrade I agreed to: :: Replace network-ups-tools with community/nut? [Y/n] network-ups-tools-2.7.4-5 [removal] nut-2.7.4-1 (both same version of package) However, after install, the nut-server.service would not start. Here are the logs for the last start before update and then the failure after the update: -- Reboot -- May 23 03:00:55 2pi systemd[1]: Starting Network UPS Tools - power devices information server... May 23 03:00:56 2pi upsd[474]: fopen /var/state/ups/upsd.pid: No such file or directory May 23 03:00:56 2pi upsd[474]: listening on 127.0.0.1 port 3493 May 23 03:00:56 2pi upsd[474]: listening on 127.0.0.1 port 3493 May 23 03:00:56 2pi upsd[474]: listening on ::1 port 3493 May 23 03:00:56 2pi upsd[474]: listening on ::1 port 3493 May 23 03:00:56 2pi upsd[474]: Connected to UPS [stp_ups]: usbhid-ups-stp_ups May 23 03:00:56 2pi upsd[474]: Connected to UPS [stp_ups]: usbhid-ups-stp_ups May 23 03:00:56 2pi upsd[475]: Startup successful May 23 03:00:56 2pi systemd[1]: Started Network UPS Tools - power devices information server. May 29 03:55:42 2pi upsd[475]: mainloop: Interrupted system call May 29 03:55:42 2pi upsd[475]: Signal 15: exiting May 29 03:55:42 2pi systemd[1]: Stopping Network UPS Tools - power devices information server... May 29 03:55:42 2pi systemd[1]: nut-server.service: Succeeded. May 29 03:55:42 2pi systemd[1]: Stopped Network UPS Tools - power devices information server. -- Reboot -- May 29 03:58:08 2pi systemd[1]: Starting Network UPS Tools - power devices information server... May 29 03:58:08 2pi upsd[480]: fopen /run/nut/upsd.pid: No such file or directory May 29 03:58:08 2pi upsd[480]: /etc/nut/upsd.conf is world readable May 29 03:58:08 2pi upsd[480]: /etc/nut/upsd.conf is world readable May 29 03:58:08 2pi upsd[480]: listening on 127.0.0.1 port 3493 May 29 03:58:08 2pi upsd[480]: listening on ::1 port 3493 May 29 03:58:08 2pi upsd[480]: listening on 127.0.0.1 port 3493 May 29 03:58:08 2pi upsd[480]: listening on ::1 port 3493 May 29 03:58:08 2pi upsd[480]: Warning: no UPS definitions in ups.conf May 29 03:58:08 2pi upsd[480]: Fatal error: at least one UPS must be defined in ups.conf May 29 03:58:08 2pi upsd[480]: Network UPS Tools upsd 2.7.4 May 29 03:58:08 2pi upsd[480]: Warning: no UPS definitions in ups.conf May 29 03:58:08 2pi upsd[480]: Fatal error: at least one UPS must be defined in ups.conf May 29 03:58:08 2pi systemd[1]: nut-server.service: Control process exited, code=exited, status=1/FAILURE May 29 03:58:08 2pi systemd[1]: nut-server.service: Failed with result 'exit-code'. May 29 03:58:08 2pi systemd[1]: Failed to start Network UPS Tools - power devices information server. May 29 04:09:14 2pi systemd[1]: Starting Network UPS Tools - power devices information server... May 29 04:09:14 2pi systemd[1]: nut-server.service: Control process exited, code=exited, status=1/FAILURE May 29 04:09:14 2pi systemd[1]: nut-server.service: Failed with result 'exit-code'. May 29 04:09:14 2pi systemd[1]: Failed to start Network UPS Tools - power devices information server. There is the very same definition of the ups in ups.conf, e,g, [stp_ups] driver = usbhid-ups port = auto desc = "stp CP825 UPS" Removing the community package and reinstalling the old package works fine, e,g, 04:16 2pi:~/.../pkg/x86_64/nut> sc restart nut-server 04:17 2pi:~/.../pkg/x86_64/nut> upsc stp_ups battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 20 battery.mfr.date: CPS battery.runtime: 3180 battery.runtime.low: 300 battery.type: PbAcid battery.voltage: 13.4 battery.voltage.nominal: 12 device.mfr: CPS device.model: UPS CP825 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.data: CyberPower HID 0.4 driver.version.internal: 0.41 input.transfer.high: 140 input.transfer.low: 100 input.voltage: 122.0 input.voltage.nominal: 120 output.voltage: 122.0 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.load: 15 ups.mfr: CPS ups.model: UPS CP825 ups.productid: 0501 ups.realpower.nominal: 450 ups.status: OL ups.test.result: Done and passed ups.timer.shutdown: -60 ups.timer.start: 0 ups.vendorid: 0764 Why doesn't the new nut from community work? -- David C. Rankin, J.D.,P.E.
[arch-general] How will Arch handle systemd 245 and homed?
All, I just read the article about the major change coming to systemd 245 at: https://www.techrepublic.com/article/linux-home-directory-management-is-about-to-undergo-major-change/?ftag=TRE475558a=12825460=12819432=712355268 What is terrifying is the SSH Problem. 9/10 hosts I interact with I do via ssh. And do we really need LUKS encrypted volumes for every user's $HOME directory? Sure for enterprise setups, etc.. but will there be a way to simply keep a normal unencrypted /home. How would scripts be able to backup certain work locations from user directories if the user is logged out? -- David C. Rankin, J.D.,P.E.
[arch-general] Inkscape 1.0 toolbar icon size, padding, margin fix?
All, With the update to inkscape 1.0, the toolbars no longer fit on the screen and ellipsize reducing the number of toolbar icons by 1/3 (from 24 to 17 visible on laptop display). Is there any way to reduce the space between the icons or the space between the toolbars to be similar to 0.92.5? -- David C. Rankin, J.D.,P.E.
[arch-general] Dynamic IPs change after reboot when dhcpcd-9.0.1-2 installed?
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=dhcpcd=dateopened=desc 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.
[arch-general] How to show USB insertion in journal without audit enabled?
All, I'm not sure when this changed, but in the past when I plugged in a USB flash drive, I could just watch a tail of the journal to see the connection and device details. I tried that again today and nothing appeared in the journal, though the device was seen and assigned /dev/sde (and /dev/sde1) which I got from cat /proc/partitions. I have also added the kernel parameter audit=0 per https://wiki.archlinux.org/index.php/Audit_framework to disable the audit messages in the journal. I don't recall the USB messages being audit messages before (they could have been, I just don't remember), but now nothing is shown. Is the lack of output in the journal on USB drive plug-in due to the audit=0 parameter, and if so, is there any way to restore the journal messages on USB plug-in without enabling audit? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Problems with files creation / copy with Samba 4.12.x and SMB1 only device.
On 03/31/2020 04:49 PM, fredbezies via arch-general wrote: > Hello. > > Before all, thanks to David C. Radkin for the tweak related to SMB1 > activation. > > After installing Samba 4.12.x, I added only this in [global] section of > /etc/samba/smb.conf to get access to one of my old SMB1 only network based > HDD: > > server min protocol = CORE > client min protocol = CORE > > After a reboot, I got access to my share, but every single time I want to > copy / create a new file, a folder is created! > > Of course, I cannot delete this folder. > > Here is an error log I had in /var/log/everything.log: > > Mar 31 23:28:40 fredo-arch-mate gvfsd[1096]: Kerberos auth with > 'fred@WORKGROUP' (WORKGROUP\fred) to access '192.168.1.254' not possible > > Any idea? Thanks! > I've got no rabbit to pull out of the hat for that one. I would post this exact message to the SAMBA list sa...@lists.samba.org Things move pretty fast in samba development, and the older standalone fileserver setups don't get much development work compared to ActiveDirectory, etc.. The samba list is very responsive and they will be able to diagnose the issue. I'll look for your post there. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Samba is broken on stable repositories since March 28th, 2020.
On 03/29/2020 11:39 AM, fredbezies via arch-general wrote: > Hello. > > Last update of samba, pushed on extra - instead of testing - is breaking > share access. > > Commit: > https://lists.archlinux.org/pipermail/arch-commits/2020-March/727612.html > > See this thread: https://bbs.archlinux.org/viewtopic.php?id=254083 > > Only fix for now? Downgrading samba. > This is one of those rare occurrences when an update breaks critical server functionality for some older environments. Samba 4.11 disables SMB1 by default for the first time. I have old clients in backoffice roles that still use it. Edit /etc/samba/smb.conf and add client min protocol = NT1 server min protocol = NT1 to the global section to restore workgroups and SMB1 -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Python2-gimp - what functionality was lost?
On 03/19/2020 10:32 PM, Eli Schwartz via arch-general wrote: > This is purely related to the pygtk-based plugin support. (Plugins that > use C, scheme, etc. are not affected.) > >> Seems strange the AUR package was posted and orphaned on 2020-03-18? > The person who uploaded it was interested in providing a solution for > the forum user whose python/pygtk based plugin no longer worked -- and > in demonstrating how that solution could be achieved in the general case. > > The person who uploaded it was not interested in providing long-term > maintenance of that AUR package, therefore, it was immediately orphaned. > > Seems pretty clear-cut to me. Thank you Eli -- it clear now. From an overview I deduced as much but didn't have the back-story. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
[arch-general] Python2-gimp - what functionality was lost?
All, I updated gimp tonight and received: ( 6/19) upgrading gimp [##] 100% > The python2 plugin support is disabled, you will need to install this > separately if you need it, e.g. the python2-gimp package in the AUR. Looking at several bugs about python2 and gimp and it seem that gimp is not removing python2 during gimp 2.10: https://bugzilla.redhat.com/show_bug.cgi?id=1737933 Do we know what functionality was lost when we removed python2 support for it? I don't use it that often, but do use it fairly thoroughly when I do. From that standpoint, is there a list of what now isn't part of gimp without python2? That would help in knowing whether the AUR package is needed. Seems strange the AUR package was posted and orphaned on 2020-03-18? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] 5.5 kernel - Latest virtualbox testcase build for 5.2.37 fails to start Arch guest on Arch host
On 02/14/2020 03:00 AM, David C. Rankin wrote: > A bug (https://www.virtualbox.org/ticket/19311) was opened with Oracle > concerning this issue that has broken the AUR package > https://aur.archlinux.org/packages/virtualbox-bin-5/ Just a follow-up advising that the AUR virtualbox-bin-5 package updated to 5.2.38 is fine and all bugs related to apparent issues with the Linux 5.4 to 5.5 update are resolved. (the last issue, high io_wait between host and guest was due to high waits on an underlying disk in the array providing guest storage - no errors in journal and mdadm reported all disks in the array good, but /dev/sdc was beginning to die -- once a scrub of the array started, the estimated 26 days to complete the scrub on a 3T array was a dead giveaway...) -- David C. Rankin, J.D.,P.E.
Re: [arch-general] 5.5 kernel - Latest virtualbox testcase build for 5.2.37 fails to start Arch guest on Arch host
On 02/06/2020 01:17 AM, David C. Rankin wrote: > On 02/05/2020 10:01 AM, Ralph Corderoy wrote: >> Hi David, >> >>> There must be another package that was updated that comes into play >>> (python?). >> How about restoring all packages to an earlier date? >> https://wiki.archlinux.org/index.php/Arch_Linux_Archive#How_to_restore_all_packages_to_a_specific_date > > > It's almost like some module or config was updated that broke something on the > guest, so now it doesn't matter whether I downgrade or not, the problem > remains. Most amazing frustrating problem I run into in a while. I was able to > grad a dmesg output and the last 1000 lines of the packman.log, but I'm > stumped. > A bug (https://www.virtualbox.org/ticket/19311) was opened with Oracle concerning this issue that has broken the AUR package https://aur.archlinux.org/packages/virtualbox-bin-5/ If any of the devs have any idea what could have impacted Host/Guest I/O to the point it takes 10 minutes to boot a Archlinux guest to a simple text console, I would welcome your input here or on the bug report. Let me know if there is any reason to open an Arch bug -- doubtful since it is an AUR package that is impacted. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] "date" C++ library packaging
On 02/13/2020 02:24 AM, Morten Linderud via arch-general wrote: > On Thu, Feb 13, 2020 at 12:09:27AM -0800, Brett Cornwall via arch-general > wrote: >> Waybar [1] just had an update where it pulled in a project called "date" >> [2]. I'm hesitant to package this under the name "date" since GNU coreutils >> shares a binary with that name. But this isn't a totally obscure library. >> >> Should I persuade upstream to change the name? Should I package it under >> another name? Or should I lay claim to the unused "date" package name and go >> on with my life? > > "chrono-date" could maybe work as an alternative name? > > I'm unsure why this is in [arch-general] and not [arch-dev-public] :) > And with the note that much of Howard Hinnant's date/time library is being incorporated into the next C++ standard. Quite a feather in anyone's cap. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] 5.5 kernel - Latest virtualbox testcase build for 5.2.37 fails to start Arch guest on Arch host
On 02/04/2020 04:18 AM, David C. Rankin wrote: > lAll, > > After update to 5.5 kernel and rebuild of virtualbox from the 5.2.36 and the > latest testcase build for 5.2.37 (all kernel modules build and load fine) > > https://www.virtualbox.org/download/testcase/VirtualBox-5.2.37-135942-Linux_amd64.run > > Arch guests fail to run on Arch host. network device enp0s3 not found, udev > kernel rules fail, and the boot never complete. > > All fine with the 5.4 kernel. I've posted to the vbox-users list, but if > anyone here has additional information I would appreciate it. > This explains Virtualbox does not support the 5.5 kernel -- no fix yet: Ticket #19145 (accepted defect) Opened 8 weeks ago linux: kernel 5.5-rc1/rc2 - we need changes https://www.virtualbox.org/ticket/19145 -- David C. Rankin, J.D.,P.E.
[arch-general] 5.5 kernel - Latest virtualbox testcase build for 5.2.37 fails to start Arch guest on Arch host
lAll, After update to 5.5 kernel and rebuild of virtualbox from the 5.2.36 and the latest testcase build for 5.2.37 (all kernel modules build and load fine) https://www.virtualbox.org/download/testcase/VirtualBox-5.2.37-135942-Linux_amd64.run Arch guests fail to run on Arch host. network device enp0s3 not found, udev kernel rules fail, and the boot never complete. All fine with the 5.4 kernel. I've posted to the vbox-users list, but if anyone here has additional information I would appreciate it. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Mouse freezes
On 01/19/2020 03:28 AM, Ralf Mardorf via arch-general wrote: > I experienced the same issue many years ago and got rid of it by > removing some laptop related package from my non-laptop desktop Linux > PC. I experienced the same issue a month ago, the mouse would disconnect from the USB bus, then a moment or two later reconnect, then disconnect again, rinse, repeat. Turns out the 10 year old mouse suffered a stroke and died... Plug in another mouse and see if the problem goes away. -- David C. Rankin, J.D.,P.E.
[arch-general] Network UPS Tools (AUR) using usbhid
Archdevs, Have there been any changes to startup that would impact the Network UPS Tools startup using the usbhid device? I ask because the nut-server.service that has worked for years, is now failing to come up in the normal boot process. $ upsc phoinix_ups Error: Driver not connected However restarting the service after the system is up and running everything works fine. So it's like there is a new depends for the usbhid driver startup that means it has to wait until something else is now started before it can initialize properly. Any idea what could be causing that or what nut-server.service needs to wait on before it tries to start? After kernel update, the failed log messages are: -- Reboot -- Jan 13 11:06:31 phoinix systemd[1]: Starting Network UPS Tools - power devices information server... Jan 13 11:06:32 phoinix upsd[541]: fopen /var/state/ups/upsd.pid: No such file or directory Jan 13 11:06:32 phoinix upsd[541]: /etc/ups/upsd.conf is world readable Jan 13 11:06:32 phoinix upsd[541]: /etc/ups/upsd.conf is world readable Jan 13 11:06:32 phoinix upsd[541]: listening on 127.0.0.1 port 3493 Jan 13 11:06:32 phoinix upsd[541]: listening on ::1 port 3493 Jan 13 11:06:32 phoinix upsd[541]: listening on 127.0.0.1 port 3493 Jan 13 11:06:32 phoinix upsd[541]: listening on ::1 port 3493 Jan 13 11:06:32 phoinix upsd[541]: Can't connect to UPS [phoinix_ups] (usbhid-ups-phoinix_ups): No such file or directory Jan 13 11:06:32 phoinix upsd[541]: Can't connect to UPS [phoinix_ups] (usbhid-ups-phoinix_ups): No such file or directory Jan 13 11:06:32 phoinix upsd[561]: Startup successful Jan 13 11:06:32 phoinix systemd[1]: Started Network UPS Tools - power devices information server. Jan 13 11:11:32 phoinix upsd[561]: Can't connect to UPS [phoinix_ups] (usbhid-ups-phoinix_ups): No such file or directory Then the restart works fine: Jan 13 11:19:20 phoinix systemd[1]: Stopped Network UPS Tools - power devices information server. Jan 13 11:19:20 phoinix systemd[1]: Starting Network UPS Tools - power devices information server... Jan 13 11:19:20 phoinix upsd[823]: fopen /var/state/ups/upsd.pid: No such file or directory Jan 13 11:19:20 phoinix upsd[823]: /etc/ups/upsd.conf is world readable Jan 13 11:19:20 phoinix upsd[823]: /etc/ups/upsd.conf is world readable Jan 13 11:19:20 phoinix upsd[823]: listening on 127.0.0.1 port 3493 Jan 13 11:19:20 phoinix upsd[823]: listening on 127.0.0.1 port 3493 Jan 13 11:19:20 phoinix upsd[823]: listening on ::1 port 3493 Jan 13 11:19:20 phoinix upsd[823]: listening on ::1 port 3493 Jan 13 11:19:20 phoinix upsd[823]: Connected to UPS [phoinix_ups]: usbhid-ups-phoinix_ups Jan 13 11:19:20 phoinix upsd[823]: Connected to UPS [phoinix_ups]: usbhid-ups-phoinix_ups Jan 13 11:19:20 phoinix upsd[824]: Startup successful Jan 13 11:19:20 phoinix systemd[1]: Started Network UPS Tools - power devices information server. Any ideas what to check? This just started within the last month or two. -- David C. Rankin, J.D.,P.E.
[arch-general] Failed to start Spamassassin daemon -- after update to spamassassin-3.4.3-1?
warning: /etc/mail/spamassassin/local.cf installed as /etc/mail/spamassassin/local.cf.pacnew Detected compiled rules, running sa-compile... Checking a diff on local.cf and local.cf.pacnew, the only non-comment changes was that the razor config isn't present in the new config (which would be expected) Spamassassin was running fine prior to update: sc status spamassassin ● spamassassin.service - Spamassassin daemon Loaded: loaded (/etc/systemd/system/spamassassin.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2019-12-12 11:30:58 CST; 13h ago Main PID: 695 (spamd) Tasks: 3 (limit: 38474) Memory: 95.0M CGroup: /system.slice/spamassassin.service ├─695 /usr/bin/perl -w /usr/bin/vendor_perl/spamd -x -u spamd -g spamd ├─833 spamd child └─834 spamd child Dec 12 11:30:58 valkyrie systemd[1]: Started Spamassassin daemon. Dec 12 11:31:05 valkyrie spamd[695]: spamd: server started on IO::Socket::IP [::1]:783, IO::Socket::IP [127.0.0.1]> Dec 12 11:31:05 valkyrie spamd[695]: spamd: server pid: 695 Dec 12 11:31:05 valkyrie spamd[695]: spamd: server successfully spawned child process, pid 833 Dec 12 11:31:05 valkyrie spamd[695]: spamd: server successfully spawned child process, pid 834 Dec 12 11:31:05 valkyrie spamd[695]: prefork: child states: IS Dec 12 11:31:05 valkyrie spamd[695]: prefork: child states: II Following update and systemctl daemon-reload, and restart of spamassassin, spamassassin fails to start: sc status spamassassin ● spamassassin.service - Spamassassin daemon Loaded: loaded (/etc/systemd/system/spamassassin.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2019-12-13 01:18:23 CST; 1s ago Process: 6849 ExecStart=/usr/bin/vendor_perl/spamd -x -u spamd -g spamd (code=exited, status=255/EXCEPTION) Main PID: 6849 (code=exited, status=255/EXCEPTION) Dec 13 01:18:23 valkyrie systemd[1]: spamassassin.service: Scheduled restart job, restart counter is at 5. Dec 13 01:18:23 valkyrie systemd[1]: Stopped Spamassassin daemon. Dec 13 01:18:23 valkyrie systemd[1]: spamassassin.service: Start request repeated too quickly. Dec 13 01:18:23 valkyrie systemd[1]: spamassassin.service: Failed with result 'exit-code'. Dec 13 01:18:23 valkyrie systemd[1]: Failed to start Spamassassin daemon. Has anyone else seen this? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Wifi challenge with new Lenovo Yoga C740
On 12/05/2019 01:50 PM, L. Rose wrote: > did you check "ip l" when booting the arch live image, to see if the interface > is really not detected? Did you try unblocking it with rfkill? Maybe there is > a hardware switch on your device, or a key combination with fn + f8 or > similar? I would second this. Many newer laptops have soft-buttons for wifi/sound/etc.. that traditionally would just save states between boots. I have 2 SSDs in my laptop, one with the original W10, the other with Arch. I've noticed the soft-buttons are configured differently depending on whether I boot windows (once a month for updates) or a normal boot of Arch. (behaves the same with openSUSE as well) I wouldn't be surprised if the wifi soft-button defaults to off. I have a light within 4 independent buttons that show the state of wifi, sound, etc... Double-check yours when you boot the Arch installer. With the arch installer, if the wifi chip is enable, it should be picked up and enabled automatically. As others have said, save the output of lspci -v (write it to a usb drive or something) and post the output just to confirm that there isn't some left-field chipset used (doubt it, but that would confirm) If you have a RJ45 connection for a wired connection, that's always an option. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Virtualbox Models for 5.2.34 (supported) Fail to Build against Linux 5.4
On 12/02/2019 10:49 PM, David C. Rankin wrote: > On 12/02/2019 07:36 PM, David C. Rankin wrote: >> All, >> >> Heads up to anyone still running Virtualbox 5.2.34 due to issues with >> headless clients in Virtualbox 6.x, the kernel modules for 5.2.34 will not >> build against Linux-5.4. >> >> Build failure details at: >> >> https://sourceforge.net/p/vbox-users/mailman/vbox-users-community/?viewmonth=201912 >> > > Oracle testcase build does work fine with Linux-5.4 > > https://www.virtualbox.org/download/testcase/VirtualBox-5.2.35-135095-Linux_amd64.run > https://www.virtualbox.org/download/testcase/VirtualBoxSDK-5.2.35-135095.zip > https://www.virtualbox.org/download/testcase/Oracle_VM_VirtualBox_Extension_Pack-5.2.35-135095.vbox-extpack > Already fixed, just waiting on upcoming 5.2.36 release: Ticket #18945 (closed defect: fixed) Linux 5.4: no more arbitrary executable pages and more changes https://www.virtualbox.org/ticket/18945 -- David C. Rankin, J.D.,P.E.
Re: [arch-general] 11/23 update caused httpd to coredump?
On 12/03/2019 11:28 AM, Genes Lists via arch-general wrote: > 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. Nope, now wsgi... Funny thing is for 10 years I though all updates I have never had any problems with httpd. The whatever changed in the 11/23 updates it was segfaulting/coredumping repeatedly. I thought the follow-up updates solved it, but then found both servers websites down again. Restarting httpd brings the server back up, but it was shocking to look at the logs and see on one server: -rw-r--r-- 1 root root 71509927 Dec 2 19:22 error_log -rw-r--r-- 1 root root 24306916 Dec 1 00:00 error_log.1 -rw-r--r-- 1 root root 625 Nov 24 00:00 error_log.2 -rw-r--r-- 1 root root 1742 Nov 21 13:19 error_log.3 -rw-r--r-- 1 root root 504 Nov 10 00:00 error_log.4 and then on the other: -rw-r--r-- 1 root root 73141520 Dec 2 19:15 error_log -rw-r--r-- 1 root root 25049886 Dec 1 00:00 error_log.1 -rw-r--r-- 1 root root 1137 Nov 24 00:00 error_log.2 -rw-r--r-- 1 root root 1752 Nov 17 00:01 error_log.3 -rw-r--r-- 1 root root 504 Nov 10 00:00 error_log.4 Yikes! -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Virtualbox Models for 5.2.34 (supported) Fail to Build against Linux 5.4
On 12/02/2019 07:36 PM, David C. Rankin wrote: > All, > > Heads up to anyone still running Virtualbox 5.2.34 due to issues with > headless clients in Virtualbox 6.x, the kernel modules for 5.2.34 will not > build against Linux-5.4. > > Build failure details at: > > https://sourceforge.net/p/vbox-users/mailman/vbox-users-community/?viewmonth=201912 > Oracle testcase build does work fine with Linux-5.4 https://www.virtualbox.org/download/testcase/VirtualBox-5.2.35-135095-Linux_amd64.run https://www.virtualbox.org/download/testcase/VirtualBoxSDK-5.2.35-135095.zip https://www.virtualbox.org/download/testcase/Oracle_VM_VirtualBox_Extension_Pack-5.2.35-135095.vbox-extpack -- David C. Rankin, J.D.,P.E.
[arch-general] Virtualbox Models for 5.2.34 (supported) Fail to Build against Linux 5.4
All, Heads up to anyone still running Virtualbox 5.2.34 due to issues with headless clients in Virtualbox 6.x, the kernel modules for 5.2.34 will not build against Linux-5.4. Build failure details at: https://sourceforge.net/p/vbox-users/mailman/vbox-users-community/?viewmonth=201912 -- David C. Rankin, J.D.,P.E.
Re: [arch-general] 11/23 update caused httpd to coredump?
On 11/27/2019 06:45 PM, David C. Rankin wrote: > On 11/24/2019 03:57 PM, David C. Rankin wrote: >> Dev, >> >> This is a strange one. After updates on 11/23, httpd began segfaulting -- >> repeatedly: >> >>> l /var/log/httpd/error_log* >> -rw-r--r-- 1 root root 24306171 Nov 24 14:48 /var/log/httpd/error_log >> -rw-r--r-- 1 root root 625 Nov 24 00:00 /var/log/httpd/error_log.1 >> -rw-r--r-- 1 root root 1742 Nov 21 13:19 /var/log/httpd/error_log.2 >> -rw-r--r-- 1 root root 504 Nov 10 00:00 /var/log/httpd/error_log.3 >> -rw-r--r-- 1 root root 1754 Nov 3 00:00 /var/log/httpd/error_log.4 >> >> I have a second server that confirms this exact same behavior: >> >>> l /var/log/httpd/error_log* >> -rw-r--r-- 1 root root 25049142 Nov 24 14:48 /var/log/httpd/error_log >> -rw-r--r-- 1 root root 1137 Nov 24 00:00 /var/log/httpd/error_log.1 >> -rw-r--r-- 1 root root 1752 Nov 17 00:01 /var/log/httpd/error_log.2 >> -rw-r--r-- 1 root root 504 Nov 10 00:00 /var/log/httpd/error_log.3 >> -rw-r--r-- 1 root root 1754 Nov 3 00:01 /var/log/httpd/error_log.4 >> >> >> The log file size jumped from 625 bytes to 24306171 bytes (1137->25049142 on >> the other server) in just a matter of hours. The old log contains, in its >> entirety: >> > > > Just a follow-up, all is back to normal since the 11/24 update: > > [Sun Nov 24 14:48:40.734427 2019] [core:notice] [pid 898] AH00051: child pid > 1128862 exit signal Segmentation fault (11), possible coredump in /etc/httpd > [Sun Nov 24 14:48:40.734535 2019] [core:notice] [pid 898] AH00051: child pid > 1128863 exit signal Segmentation fault (11), possible coredump in /etc/httpd > [Sun Nov 24 14:48:41.876097 2019] [mpm_prefork:notice] [pid 898] AH00170: > [Mon Nov 25 12:12:22.566164 2019] [core:notice] [pid 677] AH00094: Command > line: '/usr/bin/httpd -D FOREGROUND' > > No clue what happened with the 11/23 updates that originally caused the issue. > Gremlins... > Damn, Whatever it is came back after updates on 12/1 -rw-r--r-- 1 root root 71509927 Dec 2 19:22 error_log -rw-r--r-- 1 root root 24306916 Dec 1 00:00 error_log.1 -rw-r--r-- 1 root root 625 Nov 24 00:00 error_log.2 -rw-r--r-- 1 root root 1742 Nov 21 13:19 error_log.3 -rw-r--r-- 1 root root 504 Nov 10 00:00 error_log.4 Same error both server and server is down until reloaded, e.g. [Mon Dec 02 19:22:36.265040 2019] [core:notice] [pid 677] AH00051: child pid 3290821 exit signal Segmentation fault (11), possible coredump in /etc/httpd [Mon Dec 02 19:22:36.265147 2019] [core:notice] [pid 677] AH00051: child pid 3290823 exit signal Segmentation fault (11), possible coredump in /etc/httpd [Mon Dec 02 19:22:36.265255 2019] [core:notice] [pid 677] AH00051: child pid 3290824 exit signal Segmentation fault (11), possible coredump in /etc/httpd Any idea on on what is triggering this? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] 11/23 update caused httpd to coredump?
On 11/24/2019 03:57 PM, David C. Rankin wrote: > Dev, > > This is a strange one. After updates on 11/23, httpd began segfaulting -- > repeatedly: > >> l /var/log/httpd/error_log* > -rw-r--r-- 1 root root 24306171 Nov 24 14:48 /var/log/httpd/error_log > -rw-r--r-- 1 root root 625 Nov 24 00:00 /var/log/httpd/error_log.1 > -rw-r--r-- 1 root root 1742 Nov 21 13:19 /var/log/httpd/error_log.2 > -rw-r--r-- 1 root root 504 Nov 10 00:00 /var/log/httpd/error_log.3 > -rw-r--r-- 1 root root 1754 Nov 3 00:00 /var/log/httpd/error_log.4 > > I have a second server that confirms this exact same behavior: > >> l /var/log/httpd/error_log* > -rw-r--r-- 1 root root 25049142 Nov 24 14:48 /var/log/httpd/error_log > -rw-r--r-- 1 root root 1137 Nov 24 00:00 /var/log/httpd/error_log.1 > -rw-r--r-- 1 root root 1752 Nov 17 00:01 /var/log/httpd/error_log.2 > -rw-r--r-- 1 root root 504 Nov 10 00:00 /var/log/httpd/error_log.3 > -rw-r--r-- 1 root root 1754 Nov 3 00:01 /var/log/httpd/error_log.4 > > > The log file size jumped from 625 bytes to 24306171 bytes (1137->25049142 on > the other server) in just a matter of hours. The old log contains, in its > entirety: > Just a follow-up, all is back to normal since the 11/24 update: [Sun Nov 24 14:48:40.734427 2019] [core:notice] [pid 898] AH00051: child pid 1128862 exit signal Segmentation fault (11), possible coredump in /etc/httpd [Sun Nov 24 14:48:40.734535 2019] [core:notice] [pid 898] AH00051: child pid 1128863 exit signal Segmentation fault (11), possible coredump in /etc/httpd [Sun Nov 24 14:48:41.876097 2019] [mpm_prefork:notice] [pid 898] AH00170: caught SIGWINCH, shutting down gracefully [Sun Nov 24 14:48:41.978494 2019] [suexec:notice] [pid 1128921] AH01232: suEXEC mechanism enabled (wrapper: /usr/bin/suexec) [Sun Nov 24 14:48:41.996637 2019] [lbmethod_heartbeat:notice] [pid 1128921] AH02282: No slotmem from mod_heartmonitor [Sun Nov 24 14:48:42.011618 2019] [mpm_prefork:notice] [pid 1128921] AH00163: Apache/2.4.41 (Unix) OpenSSL/1.1.1d PHP/5.6.40 configured -- resuming normal operations [Sun Nov 24 14:48:42.011659 2019] [core:notice] [pid 1128921] AH00094: Command line: '/usr/bin/httpd -D FOREGROUND' [Mon Nov 25 12:11:23.505137 2019] [mpm_prefork:notice] [pid 1128921] AH00170: caught SIGWINCH, shutting down gracefully [Mon Nov 25 12:12:20.422676 2019] [suexec:notice] [pid 677] AH01232: suEXEC mechanism enabled (wrapper: /usr/bin/suexec) [Mon Nov 25 12:12:20.520933 2019] [lbmethod_heartbeat:notice] [pid 677] AH02282: No slotmem from mod_heartmonitor [Mon Nov 25 12:12:22.566075 2019] [mpm_prefork:notice] [pid 677] AH00163: Apache/2.4.41 (Unix) OpenSSL/1.1.1d PHP/5.6.40 configured -- resuming normal operations [Mon Nov 25 12:12:22.566164 2019] [core:notice] [pid 677] AH00094: Command line: '/usr/bin/httpd -D FOREGROUND' No clue what happened with the 11/23 updates that originally caused the issue. Gremlins... -- David C. Rankin, J.D.,P.E.
[arch-general] 11/23 update caused httpd to coredump?
t being available, run nvidia-modprobe first. [2019-11-24T14:40:39-0600] [ALPM] upgraded eglexternalplatform (1.0+3+g7c8f8e2-1 -> 1.1-1) [2019-11-24T14:40:39-0600] [ALPM] upgraded egl-wayland (1.1.4-1 -> 1.1.4-2) [2019-11-24T14:40:39-0600] [ALPM] upgraded faad2 (2.9.1-1 -> 2.9.1-2) [2019-11-24T14:40:39-0600] [ALPM] upgraded graphviz (2.42.2-6 -> 2.42.3-1) [2019-11-24T14:40:40-0600] [ALPM] upgraded lapack (3.8.0-2 -> 3.9.0-2) [2019-11-24T14:40:41-0600] [ALPM] upgraded libmagick6 (6.9.10.71-1 -> 6.9.10.74-1) [2019-11-24T14:40:41-0600] [ALPM] upgraded libwpe (1.4.0-1 -> 1.4.0.1-1) [2019-11-24T14:40:41-0600] [ALPM] upgraded man-pages (5.03-2 -> 5.04-1) [2019-11-24T14:40:41-0600] [ALPM] upgraded perl-libwww (6.41-1 -> 6.42-1) [2019-11-24T14:40:41-0600] [ALPM] upgraded python-pyasn1 (0.4.7-3 -> 0.4.8-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded python-setuptools (1:41.4.0-1 -> 1:41.6.0-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded python2-pyasn1 (0.4.7-3 -> 0.4.8-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded python2-setuptools (1:41.4.0-1 -> 1:41.6.0-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded qhull (2019.1-1 -> 2019.1-2) [2019-11-24T14:40:42-0600] [ALPM] upgraded tcl (8.6.9-2 -> 8.6.10-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded tk (8.6.9.1-2 -> 8.6.10-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded vte-common (0.58.2-1 -> 0.58.3-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded vte3 (0.58.2-1 -> 0.58.3-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded wpebackend-fdo (1.4.0-1 -> 1.4.0-2) [2019-11-24T14:40:42-0600] [ALPM] upgraded xorg-server-devel (1.20.5-4 -> 1.20.6-1) [2019-11-24T14:40:42-0600] [ALPM] upgraded yelp-xsl (3.34.0-1 -> 3.34.2-1) [2019-11-24T14:40:43-0600] [ALPM] transaction completed [2019-11-24T14:40:43-0600] [ALPM] running '20-systemd-sysusers.hook'... [2019-11-24T14:40:43-0600] [ALPM] running '30-systemd-daemon-reload.hook'... [2019-11-24T14:40:43-0600] [ALPM] running '30-systemd-udev-reload.hook'... [2019-11-24T14:40:43-0600] [ALPM] running '30-systemd-update.hook'... [2019-11-24T14:40:43-0600] [ALPM] running 'detect-old-perl-modules.hook'... Nothing really looks like it should directly implicate httpd. But after the first graceful restart of the server after the 5 packages were updated on 11/23 cause httpd to go haywire. Just thought I would pass it along. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Many timers now running at boot. How to make them run later?
On 11/21/2019 01:01 PM, Christian Hesse wrote:
> "David C. Rankin" on Thu, 2019/11/21 12:13:
>> I wonder why systemd doesn't do this by default?
>
> It's not systemd to blame. The timer unit files are shipped by the respective
> projects, like util-linux, man-db, mlocate, shadow, logrotate, ...
>
That makes perfect sense...
I'll have to look back at what the scheme was when things would just get
dropped in /etc/cron.daily {.hourly, .monthly, .weekly}, etc.. It really has
been until the last 9-12 months or so that I've notice the delays growing at
boot.
It would really be nice if there was a setting in /etc/systemd/system.conf (or
one of the other .conf file) that would simply let you set the hour of the day
for the default timers of this type to run. That way you could just set
something like 0400 and solve the problem for not only current timers, but all
future ones as well.
I'll drop a note if I find anything else that may be helpful as I paw my way
though the documentation.
--
David C. Rankin, J.D.,P.E.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Many timers now running at boot. How to make them run later?
On 11/21/2019 05:53 AM, Christian Hesse wrote: > I've created systemd configuration overlay snippets for this, for example > /etc/systemd/system/man-db.timer.d/RandomizedDelaySec.conf: > > [Timer] > RandomizedDelaySec=30min > > Create a file for every timer you want to delay. Thank you Ralph & Christian, I'll do that. Something to just keep them all from firing when I boot would be nice. I wonder why systemd doesn't do this by default? As more an more things have been turned over to systemd timer, it should have become evident that they were all going to start stacking up on boot Bad Juju... Logrotate and man-db can be run at 4:00 am and be fine. If I update a slew of man-pages, I'll call it directly. I see what I can do with RandomizedDelaySec=. Thanks again. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
[arch-general] Many timers now running at boot. How to make them run later?
After not booting an Arch box for several days, the first few minutes seem quite MS like lately with a flurry of processes running to the point after I enter my username at the console, it may be 10-20 sec before the password prompt is displayed. Since it's all timers now and not cron running things quietly at 4:00 am, this loads sever processes right at boot that cause the problem. For example, boot just now was crawling and checking systemctl timers shows: (leading columns snipped) LAST PASSEDUNIT ACTIVATES n/a n/a systemd-tmpfiles-clean.timer systemd-t> Thu 2019-11-21 03:33:43 CST 11min ago logrotate.timer logrotate> Thu 2019-11-21 03:33:43 CST 11min ago man-db.timer man-db.se> Thu 2019-11-21 03:33:43 CST 11min ago shadow.timer shadow.se> 4 timers listed. Pass --all to see loaded but inactive timers, too. This impacts being able to get thins from a computer in a hurry and reminds me of the unpleasant waits waiting for windows to run all of its on-boot checks. What is the best way to modify this scheme to prevent, e.g. logrotate.time, man-db.timer and shadow.timer all trying to run on boot? I'd rather set them up to run a 5:00 localtime as I would with cronnie. But I do want to use the systemd timer, so what is the best way to configure the systemd timer to schedule these things to run at a convenient time instead of all firing on boot? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] New kernel packages and mkinitcpio hooks? What does this mean to the average user?
On 11/11/2019 04:54 AM, Christian Hesse wrote: > That is a change back from March 2017 and appeared in mkinitcpio v24: POSIX list/bash array ... meh.. both work :) So I guess the rest of the answer would be that normal users won't have anything they need to do differently to manage their current hooks as this change plays out? -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
[arch-general] New kernel packages and mkinitcpio hooks? What does this mean to the average user?
All, I have read the latest note from 11-10-19 at archlinux.org, e.g. New kernel packages and mkinitcpio hooks https://www.archlinux.org/news/new-kernel-packages-and-mkinitcpio-hooks/ However, I'm still left confused exactly "What this means to the average user?" When I read: All our official kernels: linux, linux-lts, linux-zen and linux-hardened, do not install the actual kernel to /boot anymore. The installation is done by mkinitcpio hooks and scripts, as well as removals. There is no need for any manual intervention. ... That tells me that I am not going to have to change the way I update kernels and that I won't have to do anything special to ensure all current hooks are run (mdadm_udev, etc...). The only changes I see in the mkinitcpio.pacnew file is that all double-quotes have been replaced by parenthesis, e.g. HOOKS="base udev autodetect modconf block mdadm_udev filesystems keyboard fsck" to HOOKS=(base udev autodetect modconf block mdadm_udev filesystems keyboard fsck) Which appears to effectively turn HOOKS into a bash array instead of a simple list/string. But beyond that I don't see anything that will have an impact on how kernels are installed or removed on update. Am I missing something there? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/01/2019 05:06 PM, Eli Schwartz via arch-general wrote: > Our dracut packager tried to get in touch with the dracut developer, > after a lack of success for quite some time it seems that the individual > in question was on... parental leave, IIRC? I'm not sure what the > current status is. Now that does not bode well as something to build your setup around. I have dracut working fine on openSUSE, so I know it will work, but I sure haven't had any problems with the current way Arch does it. Unless there is a reliable (and responsive) upstream, I don't see the benefit (or wisdom) of patching a project that is somewhat "on-hold" just to say we have dracut and moving to it. SuSE has a lot of resources to direct toward the issue. Personally I've always found the Arch KISS philosophy the better approach. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 10/31/2019 01:30 PM, Giancarlo Razzolini via arch-general wrote: > Em outubro 31, 2019 15:11 Geo Kozey escreveu: >> >> What was the reason for not using kernel-install[1] standard instead of >> all of those Arch's exclusive hooks again?? >> >> https://www.freedesktop.org/software/systemd/man/kernel-install.html >> >> Yours sincerely >> >> G. K. >> > > There are several reasons for not using it. It's overly complex, it does a > lot of assumptions for you, among other things. That doesn't mean it > *can't* be used by the users. We are taking baby steps on making the > booting process on Arch overall more flexible. > > You can *right now* completely override the mkinitcpio hooks and, install > and deal with the kernel *any* way you want. Want to not use /boot? Can do. > Want to stuff everything on /efi? Can do. Want a hook that will build your > efistub and update entries? Can do. This update opens up lots of > possibilities, while also maintaining (some) backward compatibility. > As long as my mdadm arrays continue to assemble and I don't end up with a dead remote-supported box on reboot -- I'm all for it. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/08/2019 01:33 PM, Eli Schwartz via arch-general wrote:
> Because this is not about containers. There are tons of things in the
> old base group which I don't want installed on my heavyweight X11
> desktop which is used for media consumption.
>
> I don't need netct (because networkmanager is love), s-nail (unuseful in
> practice) or vi (symlink to vim) as a baseline fact.
>
> I don't need cryptsetup or device-mapper if I'm not opting into an
> encrypted filesystem, but this does not matter as I cannot get rid of
> either one due to systemd performing shared library links to
> libcryptsetup.so and therefore also having a depends+=('cryptsetup')
>
> I do not need mdadm or lvm2, because I don't use RAID or lvm, so why do
> you think my system is unusable without it? Note: in practice, both are
> required by libblockdev, which means if you use udisks2 you have both
> installed anyway.
As long at it passes the Allan test, then so be it. I do use mdadm, netctl,
s-nail (mailx) but agree with vim as baseline. The point being no kernel? So
now a 'base' install does not result in a running system? It seems like
forcing the install of `base` + (a list of other packages) just to result in a
bootable system will create more problems then it solves. At least a meta of
'base-legacy' would provide the same install capability. As for the argument
advances that this was due to those looking for a container install, why not
create a 'base-container' or 'base-minimal' and leave the traditional 'base'
alone?
--
David C. Rankin, J.D.,P.E.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/06/2019 11:22 PM, Giancarlo Razzolini via arch-general wrote: > Yes, this was discussed over the years in several threads. The most recent > being [0]. > > Lacking a kernel is mainly for container based environments. And some > superfluous > packages were also removed from the group, like an editor. > > The necessary changes to the installation guide were already made [1]. All of this seems like a lot of unnecessary shuffling to what has been a reliable base install for the past decade. Why on earth no simply create a 'base-container' group to provide the install for those desiring an install to support containers and leave the traditional base group alone. The lack cryptsetup, device-mapper, dhcpcd, mdadm, netctl, s-nail, vi and which in base seems to leave a 'base' install very unusable. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
[arch-general] pacman -Syu - Running post-transaction hooks... error: command failed to execute correctly
All, Not sure if this is important or not, but I thought I would pass it along. During update tonight, when the post-transaction hooks ran, I received the following related to creating temporary files: :: Running post-transaction hooks... ( 1/16) Creating system user accounts... ( 2/16) Reloading system manager configuration... ( 3/16) Creating temporary files... error: command failed to execute correctly ( 4/16) Arming ConditionNeedsUpdate... ( 5/16) Updating linux-lts module dependencies... There is nothing in /var/log/pacman.log related to this error. Is it important? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] ArchLinux in Open Invention Network
On 09/27/2019 02:44 PM, Jackie Harper via arch-general wrote: > Hello, > > Open Invention Network (OIN) is a patent non-aggression community that > supports freedom of action in Linux as a key element of open source software. > > I've seen that the OIN includes several different distributions (Gentoo, > Ubuntu derivatives etc). Would ArchLinux benefit from inclusion in this set? > It looks like joining is as simple as filling out a form, no money needed and > royalty-free. > > The full list of members is at: > https://www.openinventionnetwork.com/community-of-licensees/ > > J. > For open-source software, what possible benefit is there for distributions like Archlinux to "sign up" to some represented patent non-aggression pact pushed by some Virginia marketing group (atigro.com)? -- David C. Rankin, J.D.,P.E.
[arch-general] SOLVED Re: Aur push error, now can't fix -- need help? [was Re: Linux 5.3 - Virtualbox 5.2.32 modules fail to build - upstream bug opened]
On 09/21/2019 03:24 AM, David C. Rankin wrote: > I updated virtualbox-bin-5 and it builds and runs with 5.2.X & 5.3. However I > forgot to add a patch to the git repo before pushing and now I can't figure > out how to undo (I have since added the patch to git). The error is: > > git push > Enumerating objects: 10, done. > Counting objects: 100% (10/10), done. > Delta compression using up to 8 threads > Compressing objects: 100% (7/7), done. > Writing objects: 100% (7/7), 1.92 KiB | 1.92 MiB/s, done. > Total 7 (delta 4), reused 0 (delta 0) > remote: error: The following error occurred when parsing commit > remote: error: 3d54a4581d3c0731c53c5cc6b232c2d58864f6e1: > remote: error: missing source file: 015-linux-5-3.patch > remote: error: hook declined to update refs/heads/master > To ssh://aur.archlinux.org/virtualbox-bin-5 > ! [remote rejected] master -> master (hook declined) > error: failed to push some refs to > 'ssh://a...@aur.archlinux.org/virtualbox-bin-5' > > What do I do to tell it to forget about that commit and let me try again? I got it sorted, I just reset to head and did the commit again after adding the new file. -- David C. Rankin, J.D.,P.E.
[arch-general] Aur push error, now can't fix -- need help? [was Re: Linux 5.3 - Virtualbox 5.2.32 modules fail to build - upstream bug opened]
On 09/21/2019 01:03 AM, David C. Rankin wrote: > Thank you Ralf, > > I have the kernel modules building with a combination of the following > patches: > > 009-include-path.patch > 015-linux-5-3.patch > > The 013-Makefile patch must be specific to 6.X as on 5.2.32 is throws an > error: > > Reversed (or previously applied) patch detected! Skipping patch. > > Still have testing, but it looks promising. I updated virtualbox-bin-5 and it builds and runs with 5.2.X & 5.3. However I forgot to add a patch to the git repo before pushing and now I can't figure out how to undo (I have since added the patch to git). The error is: git push Enumerating objects: 10, done. Counting objects: 100% (10/10), done. Delta compression using up to 8 threads Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 1.92 KiB | 1.92 MiB/s, done. Total 7 (delta 4), reused 0 (delta 0) remote: error: The following error occurred when parsing commit remote: error: 3d54a4581d3c0731c53c5cc6b232c2d58864f6e1: remote: error: missing source file: 015-linux-5-3.patch remote: error: hook declined to update refs/heads/master To ssh://aur.archlinux.org/virtualbox-bin-5 ! [remote rejected] master -> master (hook declined) error: failed to push some refs to 'ssh://a...@aur.archlinux.org/virtualbox-bin-5' What do I do to tell it to forget about that commit and let me try again? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Linux 5.3 - Virtualbox 5.2.32 modules fail to build - upstream bug opened
On 09/20/2019 11:57 AM, Ralf Mardorf via arch-general wrote:
> virtualbox-bin from AUR is already patched with a fix.
> https://aur.archlinux.org/cgit/aur.git/commit/?h=virtualbox-bin=83f1870f15d86179a665dc0c6b36815a385f6fbe
>
> You could try to adapt it to your virtualbox-bin-5 tarball from AUR without
> much editing...
>
> $ wget -q
> https://aur.archlinux.org/cgit/aur.git/snapshot/virtualbox-bin{,-5}.tar.gz
> $ tar xf virtualbox-bin.tar.gz; tar xf virtualbox-bin-5.tar.gz
> $ diff -r virtualbox-bin virtualbox-bin-5
> [snip]
>
> ...perhaps you have good luck. Sometimes patches apply with an offset and
> work out of the box.
>
Thank you Ralf,
I have the kernel modules building with a combination of the following
patches:
009-include-path.patch
015-linux-5-3.patch
The 013-Makefile patch must be specific to 6.X as on 5.2.32 is throws an
error:
Reversed (or previously applied) patch detected! Skipping patch.
Still have testing, but it looks promising.
--
David C. Rankin, J.D.,P.E.
Re: [arch-general] Linux 5.3 - Virtualbox 5.2.32 modules fail to build - upstream bug opened
On 09/20/2019 11:13 AM, David C. Rankin wrote: > On 09/20/2019 12:48 AM, Christian Hesse wrote: >> We had to patch VirtualBox 6.0.12 as well. Probably you need something >> like this: >> https://git.archlinux.org/svntogit/community.git/tree/trunk/015-linux-5-3.patch?h=packages/virtualbox > > Thank you Christian and Ralf, I'll see if I can draw from that and make things > work. > > Also, apparently Virtualbox.org has fixes available in their test-builds page: https://www.virtualbox.org/wiki/Testbuilds The bug (mine was a duplicate of) that they are working both the 6.x and 5.x kernel issue through is: https://www.virtualbox.org/ticket/18911 -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Linux 5.3 - Virtualbox 5.2.32 modules fail to build - upstream bug opened
On 09/20/2019 12:48 AM, Christian Hesse wrote: > We had to patch VirtualBox 6.0.12 as well. Probably you need something > like this: > https://git.archlinux.org/svntogit/community.git/tree/trunk/015-linux-5-3.patch?h=packages/virtualbox Thank you Christian and Ralf, I'll see if I can draw from that and make things work. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
[arch-general] Linux 5.3 - Virtualbox 5.2.32 modules fail to build - upstream bug opened
All, Note to anyone is still using Virtualbox 5.2.32 (that can't move to Ver. 6 due to headless behavior with Windows guests), on update to Linux 5.3, virtualbox models fail to build using dkms. Upstream bug filed: https://www.virtualbox.org/ticket/18949 (make.log attached to bug report) -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Bios Raid (Fake Raid) and Virtual Raid (Software Raid)
On 09/02/2019 08:07 AM, Kelly Rogers via arch-general wrote: > Hi, > Can you tell me what is capable to do Arch Linux: Bios Raid (Fake Raid) and > Virtual Raid (Software Raid)? > Thank you! Forget fake-raid -- dmraid (though I have used it for years), just use Linux software RAID (mdadm). Far more flexible and a guaranteed migration path forward. The overhead for software raid was negligible on on single-core 486 machines, it isn't even in the noise anymore. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Ubunto to Arch complete data migration
On 08/12/2019 02:02 PM, Matt Zand via arch-general wrote: > I want to move all my files, localhost services like Apache configuration > and application (web server) files and folders from a Ubuntu laptop to > another brand new computer (Arch OS). > Whoa.. Before you just start moving things, make sure the version of the server you are moving from is the same as you will have on Arch (Arch will be current with the upstream released version and can be several versions ahead of what you are used to) Assuming your versions of apache, etc.. are the same, copy your existing config to a temporary directory on your new Arch box. I would recommend starting with the default config provided by Arch and ADDING your specific config items to the default config while you have the wiki page open, e.g. Apache HTTP Server https://wiki.archlinux.org/index.php/Apache_HTTP_Server That way if there are any differences in the Arch config due to the way things are packaged or the way the config is split between the main file in /etc/httpd/conf/ and files included from /etc/httpd/conf/extra/ you will automatically incorporate the changes by starting with the default config provided. > My questions > 1- what is the easiest way to do this? Move your content from your Ubuntu laptop to your new Arch install. Do not blindly copy server config files, copy your existing config to a temp directory and incorporate any specific config in the default config files provided by Arch (while you have the appropriate wiki.archlinux.org page open) > 2- do I need to partition hard-drive of new PC exactly as old one? No, how things are partitioned does not matter to the various servers. > 3- will root and other user credentials stay the same? No, you will need to create the Linux root and other users on you Arch box. You may also need to add, map or adjust GID (group ID numbers) as the group and GID the server runs under on Arch may not match what it ran under on Ubuntu. > > Any other suggestion appreciated, The Arch wiki page for each utility or server are probably some of the best on the net -- use them to help you accomplish whatever you are doing on Arch. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] pango 1:1.44-1 Renders Bitmap Fonts as Boxes.
On 07/28/2019 06:49 AM, Ralph Corderoy wrote: > Hi, > > To save others' time, on upgrading to pango 1:1.44-1 today my terminal > emulator and other programs displayed empty boxes instead of bitmap-font > glyphs. This is due to deliberate dropping of support by Pango. > https://gitlab.gnome.org/GNOME/pango/issues/386 > > I don't think xterm(1) uses Pango given ldd(1)'s output, and it's > happily displaying nice crisp glyphs. > So Gnome just KDE4'ed pango Type 1 support. It is bewildering why support simply can't remain. Nothing like pacman -Syu and having things break -- things that have been working -- forever. Whatever the fight between Cairo and Pango over FC_face locking -- that seems like what needs to be fixed instead of simply dropping support for an entire class of fonts. Progress. Oh well. -- David C. Rankin, J.D.,P.E.
[arch-general] 5.2 kernel, Virtualbox console takes on video-mode size -- nice.
All, With the 5.2 kernel, virtualbox no longer boots to the GRUB_GFXMODE, but instead boots to the video-mode-hint given to virtualbox. That is a welcomed change. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] External monitors are no longer detected (Intel graphics)
On 07/02/2019 01:01 AM, Bennett Piater wrote: > Hi, > I'm using a Thinkpad T450s with Intel graphics. > > Yesterday, I could no longer connect external monitors via miniDP. > They were not detected at all, either by xrandr in i3 or by sway (wayland). > I didn't have time to dig out a VGA cable and try that, so I cannot rule out > physical damage yet - I did try 2 monitors with different cables, both of > which work with my wife's Thinkpad. > > Since wayland doesn't make a difference, I'm thinking maybe something broke > with the (my?) drivers? > Is there any other possibility apart from physical damage, and what do I try > next? > > Cheers, > Bennett Have you checked the troubleshooting options on https://wiki.archlinux.org/index.php/Intel_graphics. I also recall an intel issue with recent kernels, but can't put my hand on a link. The problems experienced with some are listed in the wiki. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] PCYNLITX project and its innovations ( for multi-threading )
On 06/28/2019 02:18 PM, Erkam Murat Bozkurt via arch-general wrote: > PCYNLITX platform offers completely new programming technology which can be > named as Programmable Meta-Programming System and PCYNLITX platform is just > a particular application of this new programming methodology. This seems to have spammed every list available, Ubuntu, ACCU-general, Arch-general, etc.. with the same base64 encoded self-promotion. Any way to cut down on this? -- David C. Rankin, J.D.,P.E.
[arch-general] Mariadb Tables Still Compatible with Backup Server Running Earlier Version?
This is more a general question following the mariadb feature update to 10.4.6-1. Do the tables remain compatible with servers running earlier versions of mariadb? What happens if a backup from an earlier version has to be rolled into the new version? Or more importantly, can a backup from the new version be used to update servers running earlier versions of mariadb? (I have the same database running on Arch with backup handled by openSuSE, still running 10.0.35) https://wiki.archlinux.org/index.php/MariaDB doesn't mention anything special. Nor does https://mariadb.com/kb/en/library/changes-improvements-in-mariadb-104/ Any help or comment would be appreciated. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] CVE-2019-11477 (/proc/sys/net/ipv4/tcp_sack)
On 06/21/2019 01:44 AM, Levente Polyak via arch-general wrote: > I guess you mean 5.1.12 as long as you are not a visitor from the future. > > 5.1.11 was the upstream fix version for the SACK issues, you can use our > Arch Linux specific security tracker to get this information: > > > https://security.archlinux.org/CVE-2019-11477 > https://security.archlinux.org/CVE-2019-11478 > https://security.archlinux.org/CVE-2019-11479 > > which lists all affected and fixed variants/versions. > > there have been advisories published on the tracker and via our sec > announcements ML. > > > So as long as you are running latest kernels, no other mitigation is needed. > > cheers, > Levente Thank you Levente Not from the future, just a notorious bass-ackwards typist. Perhaps a dumb question, but where would I find (other than the security.archlinux.org page the cross-reference that tells me CVE-XXX is in group, e.g. AVG-986? -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
[arch-general] CVE-2019-11477 (/proc/sys/net/ipv4/tcp_sack)
After 5.12.1 is there any further mitigation needed for: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11477 related: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11478 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11479 Suggested work-around: echo 0 > /proc/sys/net/ipv4/tcp_sack or iptables -A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP Are either needed after latest kernel, or is this resolved? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] How to name a package for the drm-openchrome tree?
On 06/15/2019 09:53 PM, Marc Ranolfi via arch-general wrote: > I wonder if the following is acceptable: > > pkgname = linux-drm-openchrome-git > pkgdesc = The Linux kernel and modules from the drm-openchrome tree - git > version > That seems to meet all normal naming conventions and the description is fine. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] perl update leaves glade-perl unused, but glade-perl still a dependency of qemu-launcher?
On 06/11/2019 03:23 PM, Tinu Weber wrote: > On Wed, Jun 12, 2019 at 08:10:19 +1200, Joel Teichroeb via arch-general wrote: >> qemu-launcher is in the AUR, so it doesn't look like it has been updated yet. > > qemu-launcher probably doesn't even need an update. > > David, glade-perl is an AUR package; the rebuild is your own > responsibility. > > Best, > --Tinu > Uugh! Sorry for the noise. After the install message, along with the dependency I checked: pacman -Qi glade-perl, and saw ... Required By : qemu-launcher Optional For: None Conflicts With : None Replaces: None Installed Size : 41.00 KiB Packager: Evangelos Foutras Build Date : Wed 01 Aug 2018 07:18:12 AM CDT Install Date: Mon 06 Aug 2018 12:22:50 PM CDT Install Reason : Installed as a dependency for another package Install Script : No Validated By: Signature and I never snapped to the fact it was AUR... (pointy hat placed on own head and will turn and face the corner) -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
[arch-general] perl update leaves glade-perl unused, but glade-perl still a dependency of qemu-launcher?
Archdevs, After latest perl update, the following message is displayed: -> Run the following command to get a list of affected packages: pacman -Qqo '/usr/lib/ So we did, and it flagged glade-perl, but checking, glade-perl was still a dependency of qemu-launcher. I don't know if this is just a lucky timing issue in between when qemu-launcher will be updated, but I thought I would pass it along if this presents a problem. -- David C. Rankin, J.D.,P.E.
[arch-general] perl update leaves glade-perl unused, but glade-perl still a dependency of qemu-launcher?
Archdevs, After latest perl update, the following message is displayed: -> Run the following command to get a list of affected packages: pacman -Qqo '/usr/lib/ So we did, and it flagged glade-perl, but checking, glade-perl was still a dependency of qemu-launcher. I don't know if this is just a lucky timing issue in between when qemu-launcher will be updated, but I thought I would pass it along if this presents a problem. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 05/22/2019 11:41 AM, Eli Schwartz via arch-general wrote: > I would rather avoid such bundles at all costs, it sounds like someone > saw a problem named bootctl and decided to create even more problems in > the name of a solution. I've always respected the Arch KISS approach. The further we stay into the ... what was the word? ... "byzantine", the further away from KISS Arch migrates. But, somehow, those charged with the stewardship of Arch seem to always make solid choices for the distro going forward. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Arch on NVMe ssd
On 05/22/2019 10:12 PM, Ram Kumar via arch-general wrote: > Nice, > Thanks a lot guys. My first job for tomorrow will be to install Arch on my > laptop. > > can you explain me a little detail on that rewrite stuff?, i am slightly > confused Sure, here is a good article that explains it: How Long do SSDs Really Last? https://www.ontrack.com/blog/2018/02/07/how-long-do-ssds-really-last/ You can find many more similar articles, and if you find the old (pre-2015) ones, you will see the fear they had on exceeding the cell write limits. SSD's have improved significantly, and the cell re-write issue has gone away for the most part. As mentioned in the article to hit the lifetime of a 250GB drive in one year, you would need to re-write 190GB per-day, every day, for the entire year. In normal desktop/laptop use, you rarely write more than 1-2GB a day on average -- so that would translate into a 190-95 year wear-life for the drive under normal use. Even at 10GB a day, that would be a 19 year life for the drive. So based on those figures, you would install Arch with your choice of desktop, use it for the day, delete everything and repeat the install/delete every day for 10 years and still be fine. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Arch on NVMe ssd
On 05/22/2019 10:27 AM, Ram Kumar via arch-general wrote: > I bought a new laptop that has NVMe ssd on it. I would like to install Arch > on that, is there any precautions that i need to take? Also i would like to > get feedback from Archers who already tried this. Drive it like you stole it! No special precautions needed for SSD anymore. The old write-limitations have all but disappeared. Samsungs 3/5 year warranties presume a 60% daily rewrite of the drive (so for a 1T drive, that's 600GB of daily writes assumed) Like 11 sec boots from OFF to Full Desktop? They are pretty amazing compared to platter. Have large builds (like rebuilding php or KDE). Compile times now a fraction of what they were with platter drives. See https://wiki.archlinux.org/index.php/Solid_state_drive for TRIM or fstrim configs/consideration. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] [arch-dev-public] Mkinitcpio replacement with Dracut
On 05/21/2019 12:06 PM, Giancarlo Razzolini via arch-general wrote: > I'll stress this, dracut and mkinitcpio will co-exist for a *long* time. So, > each will have their own hooks for updating the images. > Thank you. mkinitcpio isn't broken and using both SuSE with dracut and Arch with mkinitcpio -- I prefer the Arch mkinitcpio approach. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] js60 update -- reveals older packages installed as deps not updated and left on system
On 05/18/2019 04:45 AM, Bruno Pagani wrote: > Yes, this is the standard case of old dependencies becoming unneeded, it > just seems strange to you because all those packages are js*, but if > they have a different name and don’t upgrade over the previous one > that’s for a good reason. Thank you Bruno, That's all I needed to know. I just couldn't immediately see what that 'provides()', 'conflicts()' or 'replaces()' PKGBUILD contents would have needed to be to prevent it. The answer of "it shouldn't" because they are not direct upgrades makes sense now. -- David C. Rankin, J.D.,P.E.
