Re: [arch-general] Thunderbird 78
On August 15, 2020 3:27:50 AM UTC, karx via arch-general wrote: >couldn't we package thunderbird 78 in >the AUR for people who absolutely need 78, Sure, go ahead and do that if you want. signature.asc Description: PGP signature
Re: [arch-general] Thunderbird 78
On Fri, Aug 14, 2020, 9:45 PM mpan wrote: > > Is there any reason the package is stuck to version 68? > The reason is given on the very top of the page you have linked. > Correct me if I'm wrong, but couldn't we package thunderbird 78 in something like testing or the AUR for people who absolutely need 78, and then keep the stable version how it is? Yash >
Re: [arch-general] Thunderbird 78
> Is there any reason the package is stuck to version 68? The reason is given on the very top of the page you have linked. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Thunderbird 78
On 2020-08-14 21:12 -0400, M Piles wrote: | | | | OpenPGP functionality for | | | Thunderbird 78 is still work in | | | progress, and is disabled by | | | default in the initial 78.0 | | | release. | | | | 78+ versions do not support Enigmail | | anymore it seems... | | Looking at the release notes for | 78.1.1 | (https://www.thunderbird.net/en-US/thunderbird/78.1.1/releasenotes/) | it looks like they've gotten OpenPGP | working but they're still testing it. | It should be fine in later versions. Posteo said something about this back in July: https://posteo.de/en/blog/enigmail-users-do-not-update-to-thunderbird-78 signature.asc Description: PGP signature
Re: [arch-general] Thunderbird 78
>> At this time, users of the Enigmail Add-on should not update to Thunderbird >> 78. >> OpenPGP functionality for Thunderbird 78 is still work in progress, and is >> disabled by default in the initial 78.0 release. See the wiki for how to >> enable and help with testing. > I heavily rely on gpg, and getting something still work in progress doesn't > sound good. Not sure if the OpenPGP functionality on 78.1.1 (current > release) offers something more mature, because 78+ versions do not support > Enigmail anymore it seems... > > Looking at the release notes for 78.1.1 (https://www.thunderbird.net/en-US/thunderbird/78.1.1/releasenotes/) it looks like they've gotten OpenPGP working but they're still testing it. It should be fine in later versions. -SilkDragon signature.asc Description: OpenPGP digital signature
Re: [arch-general] Thunderbird 78
On 8/14/20 4:41 PM, Xorg via arch-general wrote: > Hi, > > Thunderbird 78 is available since 1 month > (https://www.thunderbird.net/en-US/thunderbird/78.0/releasenotes). > Is there any reason the package is stuck to version 68? Can someone update > this package? > > Thank in advance. BTW, by looking at the release notes shared, I don't like the note about OpenPGP: > At this time, users of the Enigmail Add-on should not update to Thunderbird > 78. > OpenPGP functionality for Thunderbird 78 is still work in progress, and is > disabled by default in the initial 78.0 release. See the wiki for how to > enable and help with testing. I heavily rely on gpg, and getting something still work in progress doesn't sound good. Not sure if the OpenPGP functionality on 78.1.1 (current release) offers something more mature, because 78+ versions do not support Enigmail anymore it seems... Thanks, -- Javier signature.asc Description: OpenPGP digital signature
[arch-general] Thunderbird 78
Hi, Thunderbird 78 is available since 1 month (https://www.thunderbird.net/en-US/thunderbird/78.0/releasenotes). Is there any reason the package is stuck to version 68? Can someone update this package? Thank in advance.
[arch-general] R: openvpn-client@ takes long time to start
Em agosto 14, 2020 9:57 Riccardo Paolo Bestetti escreveu: The output from OpenVPN indicates that the client is started within the first few seconds from when I give the `systemctl start openvpn-client@whatever` command (see previous email). The tun interface is created, opened, the routes are received and added to the routing table. All the usual stuff. Of course, I can also reach remote hosts through the VPN after that. The exact same thing (& output) happens if I try to start OpenVPN manually from the command line. Minus, of course, the two-minutes wait before the command returns. Again, use the openvpn log capabilities. I'd recommend a verbose of at least 3, for starters. I also forgot to specify it also happens when the system has been up for hours. It really can't be that the network is not ready. Are you using --daemon on your openvpn config file? I don't think there's anything much that could be disturbing it. I'm using systemd-networkd for everything + iwd for wireless. Well, you can paste your configuration (minus keys and user/auth). Regards, Giancarlo Razzolini pgpO5qaX1fB9h.pgp Description: PGP signature
[arch-general] R: openvpn-client@ takes long time to start
Da: Giancarlo Razzolini Inviato: Venerdì, 14 Agosto, 2020 13:29 A: General Discussion about Arch Linux Cc: Riccardo Paolo Bestetti Oggetto: Re: [arch-general] openvpn-client@ takes long time to start Em agosto 14, 2020 3:58 Riccardo Paolo Bestetti via arch-general escreveu: >> After a reboot, the first openvpn-client@ instance I try to start takes >> almost exactly two minutes to start. The instances before that one start >> just fine in a few seconds. >> > Guess you meant: "The instances *after* ..." Yes I did. :) >> When that happens, I can see from journalctl that the client actually starts >> in the first few seconds after the systemctl command. But then, the command >> doesn't terminate for two more minutes (with no further journal entries). >> > Openvpn has quite good logging capabilities that you can put to use here. The output from OpenVPN indicates that the client is started within the first few seconds from when I give the `systemctl start openvpn-client@whatever` command (see previous email). The tun interface is created, opened, the routes are received and added to the routing table. All the usual stuff. Of course, I can also reach remote hosts through the VPN after that. The exact same thing (& output) happens if I try to start OpenVPN manually from the command line. Minus, of course, the two-minutes wait before the command returns. >> Has anyone seen this before? What could it be? >> > Without knowing more, my first guess is that you still don't have > connectivity when that first openvpn client starts. > 2 minutes matches exactly the 120 seconds default ping-restart parameter. So, > > what happens is, the client starts, you have > no connectivity then, after two minutes, ping-restart kicks in, and your > connection gets through. > So, get a network manager that can properly trigger network-online.target. > Or, if your network manager is triggering it, then > it means your network is not quite ready when it does. See above. I also forgot to specify it also happens when the system has been up for hours. It really can't be that the network is not ready. I don't think there's anything much that could be disturbing it. I'm using systemd-networkd for everything + iwd for wireless. Riccardo > Regards, > Giancarlo Razzolini
Re: [arch-general] openvpn-client@ takes long time to start
Em agosto 14, 2020 3:58 Riccardo Paolo Bestetti via arch-general escreveu: After a reboot, the first openvpn-client@ instance I try to start takes almost exactly two minutes to start. The instances before that one start just fine in a few seconds. Guess you meant: "The instances *after* ..." When that happens, I can see from journalctl that the client actually starts in the first few seconds after the systemctl command. But then, the command doesn't terminate for two more minutes (with no further journal entries). Openvpn has quite good logging capabilities that you can put to use here. Has anyone seen this before? What could it be? Without knowing more, my first guess is that you still don't have connectivity when that first openvpn client starts. 2 minutes matches exactly the 120 seconds default ping-restart parameter. So, what happens is, the client starts, you have no connectivity then, after two minutes, ping-restart kicks in, and your connection gets through. So, get a network manager that can properly trigger network-online.target. Or, if your network manager is triggering it, then it means your network is not quite ready when it does. Regards, Giancarlo Razzolini pgpcTqzO7iz2h.pgp Description: PGP 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
[arch-general] openvpn-client@ takes long time to start
After a reboot, the first openvpn-client@ instance I try to start takes almost exactly two minutes to start. The instances before that one start just fine in a few seconds. When that happens, I can see from journalctl that the client actually starts in the first few seconds after the systemctl command. But then, the command doesn't terminate for two more minutes (with no further journal entries). Has anyone seen this before? What could it be? Riccardo
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
