Re: [arch-general] Thunderbird 78
Am 15.08.20 um 05:39 schrieb Kusoneko: > 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. > There is thunderbird-bin in the AUR which repackages the official upstream release of version 78.*
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
