- Arch-general - lists.archlinux.org

colored prompt in early userspace
by lacsaP Patatetom 28 Mar '23

28 Mar '23

hi, when you add the `break` parameter to the list of parameters passed when the system boots, you find yourself in an interactive shell that allows you to issue commands, perform tests, and so on... the shell is apparently provided by `ash`. how to have a colored prompt (which visually helps to detach the prompt from the rest) ? the `~/.profile` file mentioned here and there does not seem to be read/used. `/.profile` and `/etc/profile` don't do much better. `ashrc` also tested without success. if the prompt offered at this level can be colored, I think it would not be a luxury to implement it directly in mkinitcpio ;-) regards, lacsaP.

1 1

Re: nginx TLS 1.3 doesn't seem to work
by Polarian 28 Mar '23

28 Mar '23

> So you know how to quote, but choose to never give even the tiniest bit of context when you reply because you think we all keep an entire archive of arch-general locally and never delete anything, just so we can follow your blank replies to threads? When something is a straight forward reply to the previous email, there is no need to quote, because you are replying directly to the email. And yes, I expect you store the email for longer than 2 seconds after reading it, this is not 1980s, you have a few kb of storage spare! > I've been on this list for years, and while I don't participate much, I do read everything. But I don't keep it all, as I expect most people don't. I never said keep it all, I said keep the recent conversations so you know what is going on. > Your attitude sucks. Subjective! Now can we please go back on topic, I would rather my nginx instance supports tlsv1.3, than arguing about when and when not to quote, and also how long we should store emails for! Thank you! -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

2 1

nginx TLS 1.3 doesn't seem to work
by Polarian 28 Mar '23

28 Mar '23

Hello, I was browsing https://onedev.polarian.dev while diagnosing the other SSL issue I was having, and I ave realised that it only supports TLS 1.2, even though I have 1.3 enabled and loaded (confirmed with nginx -t) When I use curl: ~ on ☁ took 2s ❯ curl -vI https://onedev.polarian.dev * Trying 81.187.86.85:443... * Connected to onedev.polarian.dev (81.187.86.85) port 443 (#0) * ALPN: offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: none * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN: server accepted http/1.1 * Server certificate: * subject: CN=onedev.polarian.dev * start date: Mar 14 07:49:09 2023 GMT * expire date: Jun 12 07:49:08 2023 GMT * subjectAltName: host "onedev.polarian.dev" matched cert's "onedev.polarian.dev" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. * using HTTP/1.1 > HEAD / HTTP/1.1 > Host: onedev.polarian.dev > User-Agent: curl/8.0.1 > Accept: */* > < HTTP/1.1 200 OK HTTP/1.1 200 OK < Server: nginx/1.22.1 Server: nginx/1.22.1 < Date: Fri, 24 Mar 2023 12:03:18 GMT Date: Fri, 24 Mar 2023 12:03:18 GMT < Content-Type: text/html;charset=utf-8 Content-Type: text/html;charset=utf-8 < Connection: keep-alive Connection: keep-alive < X-FRAME-OPTIONS: SAMEORIGIN X-FRAME-OPTIONS: SAMEORIGIN < Set-Cookie: JSESSIONID=node0ksf08v71egm01j4p388blz4e012.node0; Path=/; HttpOnly; SameSite=Lax Set-Cookie: JSESSIONID=node0ksf08v71egm01j4p388blz4e012.node0; Path=/; HttpOnly; SameSite=Lax < Expires: Thu, 01 Jan 1970 00:00:00 GMT Expires: Thu, 01 Jan 1970 00:00:00 GMT < Pragma: no-cache Pragma: no-cache < Cache-Control: no-cache, no-store Cache-Control: no-cache, no-store < * Connection #0 to host onedev.polarian.dev left intact I can see that TLS 1.3 is supported, but for some reason during the handshake it settles on TLS 1.2, why? Thank you, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

6 14

IPv6 packet loss issue
by Polarian 28 Mar '23

28 Mar '23

Hello, So I am running Arch Linux on a server and on my laptop, both of which use network manager. Now when I ping, or send a http request to polarian.dev (my website) the first time it works just fine: ~ on ☁ ❯ ping -6 polarian.dev PING polarian.dev(2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa (2001:8b0:57a:2385::2)) 56 data bytes 64 bytes from 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa (2001:8b0:57a:2385::2): icmp_seq=1 ttl=63 time=0.506 ms 64 bytes from 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa (2001:8b0:57a:2385::2): icmp_seq=2 ttl=63 time=0.646 ms 64 bytes from 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa (2001:8b0:57a:2385::2): icmp_seq=3 ttl=63 time=0.512 ms 64 bytes from 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa (2001:8b0:57a:2385::2): icmp_seq=4 ttl=63 time=0.357 ms 64 bytes from 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa (2001:8b0:57a:2385::2): icmp_seq=5 ttl=63 time=0.509 ms ^C --- polarian.dev ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4007ms rtt min/avg/max/mdev = 0.357/0.506/0.646/0.091 ms If I then stop it (as you can see ^C) and then start it again, I get the following: ~ on ☁ took 7s ❯ ping -6 polarian.dev PING polarian.dev(2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa (2001:8b0:57a:2385::2)) 56 data bytes 64 bytes from 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa (2001:8b0:57a:2385::2): icmp_seq=27 ttl=63 time=0.399 ms 64 bytes from 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa (2001:8b0:57a:2385::2): icmp_seq=28 ttl=63 time=0.550 ms 64 bytes from 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa (2001:8b0:57a:2385::2): icmp_seq=29 ttl=63 time=0.357 ms 64 bytes from 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa (2001:8b0:57a:2385::2): icmp_seq=30 ttl=63 time=0.749 ms ^C --- polarian.dev ping statistics --- 30 packets transmitted, 4 received, 86.6667% packet loss, time 29345ms rtt min/avg/max/mdev = 0.357/0.513/0.749/0.153 ms The first 20-30 packets keep getting lost. When I tcpdump imcp6 during this issue, I get the following: 10:13:21.921967 IP6 _gateway > PolarianServer: ICMP6, redirect, 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa to 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa, length 320 10:13:23.958945 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 1, length 64 10:13:23.959028 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 1, length 64 10:13:24.978500 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 2, length 64 10:13:24.978569 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 2, length 64 10:13:25.991827 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 3, length 64 10:13:25.991917 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 3, length 64 10:13:27.005178 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 4, length 64 10:13:27.005270 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 4, length 64 10:13:28.018506 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 5, length 64 10:13:28.018596 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 5, length 64 10:13:29.031841 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 6, length 64 10:13:29.031929 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 6, length 64 10:13:30.045276 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 7, length 64 10:13:30.045408 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 7, length 64 10:13:31.058486 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 8, length 64 10:13:31.058577 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 8, length 64 10:13:32.071837 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 9, length 64 10:13:32.071923 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 9, length 64 10:13:33.085189 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 10, length 64 10:13:33.085258 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 10, length 64 10:13:34.098506 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 11, length 64 10:13:34.098598 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 11, length 64 10:13:35.111589 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 12, length 64 10:13:35.111684 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 12, length 64 10:13:36.124916 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 13, length 64 10:13:36.125009 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 13, length 64 10:13:37.138248 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 14, length 64 10:13:37.138332 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 14, length 64 10:13:38.151827 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 15, length 64 10:13:38.151918 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 15, length 64 10:13:39.165174 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 16, length 64 10:13:39.165270 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 16, length 64 10:13:40.178242 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 17, length 64 10:13:40.178313 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 17, length 64 10:13:41.191585 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 18, length 64 10:13:41.191719 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 18, length 64 10:13:42.205174 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 19, length 64 10:13:42.205266 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 19, length 64 10:13:43.218487 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 20, length 64 10:13:43.218576 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 20, length 64 10:13:44.231826 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 21, length 64 10:13:44.231912 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 21, length 64 10:13:45.245143 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 22, length 64 10:13:45.245253 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 22, length 64 10:13:46.258470 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 23, length 64 10:13:46.258560 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 23, length 64 10:13:47.271944 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 24, length 64 10:13:47.272033 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 24, length 64 10:13:47.272129 IP6 _gateway > PolarianServer: ICMP6, redirect, 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa to 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa, length 160 10:13:48.273793 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 25, length 64 10:13:48.273867 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 25, length 64 10:13:48.273969 IP6 _gateway > PolarianServer: ICMP6, redirect, 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa to 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa, length 160 10:13:49.275216 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 26, length 64 10:13:49.275288 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 26, length 64 10:13:49.275382 IP6 _gateway > PolarianServer: ICMP6, redirect, 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa to 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa, length 160 10:13:50.194693 IP6 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, neighbor solicitation, who has PolarianServer, length 32 10:13:50.194833 IP6 PolarianServer > 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, neighbor advertisement, tgt is PolarianServer, length 24 10:13:50.277192 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 27, length 64 10:13:50.277256 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 27, length 64 10:13:50.277347 IP6 _gateway > PolarianServer: ICMP6, redirect, 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa to 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa, length 160 10:13:51.279181 IP6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa > PolarianServer: ICMP6, echo request, id 4, seq 28, length 64 10:13:51.279255 IP6 PolarianServer > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa: ICMP6, echo reply, id 4, seq 28, length 64 10:13:51.279352 IP6 _gateway > PolarianServer: ICMP6, redirect, 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa to 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa, length 160 10:13:51.419764 IP6 PolarianServer > _gateway: ICMP6, neighbor solicitation, who has _gateway, length 32 10:13:51.419892 IP6 _gateway > PolarianServer: ICMP6, neighbor advertisement, tgt is _gateway, length 24 10:13:53.898667 IP6 _gateway > PolarianServer: ICMP6, redirect, 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa to 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa, length 136 The ICMP packets are definitely getting to my server, but for whatever reason my server does not respond, until about the 20-30th packet and then it finally responds back to my laptop. Does anybody have any clue why is is occurring? (This is done internally, feel free to ping polarian.dev externally to see if you can reproduce the issue). Thank you, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

2 3

gui network icon not connected
by alistair cookie 25 Mar '23

25 Mar '23

hello. from CLI, if i do "ip addr show" and "ping google.com" it definitely shows me i'm connected to my network and the Internet. but looking at my network icon on the system tray it says i'm not connected to any AP. a bug?

6 5

TeXLive 2023 update
by Rémy Oudompheng 24 Mar '23

24 Mar '23

Hello Texlive packages have been updated to 2023 version in [testing]. Important caveat: these packages do not include the luametatex program. The 'context' command remains mapped to the standard luatex, meaning that (as far as I understand, Context LMTX will not be usable, but Context MkII and MkIV should be fine). luametatex sources are not included in TeXLive sources (there is an AUR package if you want to try it). Regards, Rémy.

2 1

Keep getting SSL certificate failures
by Polarian 24 Mar '23

24 Mar '23

Hello, I did not notice this issue at first, but reflecting back on it now there seems to be a serious issue with my SSL on my laptop. When I was speaking to Erus about a "rotted link" within the AUR, I could not access the website as it kept throwing TLS errors, he could. I assumed it was just because of more strict firefox settings. I have now realised that this plays more of an issue, I am constantly getting errors such as: SSL_ERROR_ACCESS_DENIED_ALERT on firefox, and ERR_SSL_PROTOCOL_ERROR on chromium. This happens to multiple sites, but only to some, there seems to be no link between them. For example: https://web.archive.org/web/20130824024508/http://www.baycom.org/~tom/ham/s… is one such website I am not able to visit on any browser on my laptop. I assume this is an issue with the certificate verification on my laptop or maybe even openssl? I guess you could consider this karma for using packages within testing :P (but hey at least I am testing) If anyone has any ideas on how to diagnose the issue, on what the issue here is, or links to sources I can look into, please let me know. Have a good night, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

6 14

X application preferences
by lacsaP Patatetom 24 Mar '23

24 Mar '23

hi, I would like the `lxtask` application (LXDE task manager) to open systematically in "always on top" mode : is it possible to do this in the `~/.Xresources` file ? otherwise, where can it be configured ? regards, lacsaP.

5 9

Fwd: Spring cleanup '23
by David C. Rankin 23 Mar '23

23 Mar '23

Just a note, I would be nice if the members of the general list could see which packages are orphaned. Currently a developer sign-in is needed. -------- Forwarded Message -------- Subject: Spring cleanup '23 Date: Wed, 22 Mar 2023 19:08:40 +0100 From: Antonio Rojas <arojas(a)archlinux.org> To: arch-dev-public(a)lists.archlinux.org Hello, It is that time of the year again: time for our yearly orphans cleanup. Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and adopt packages that you'd like to keep in the repos. This is also a good opportunity to disown any packages you no longer want to maintain, so others can adopt them or they can be properly maintained in AUR if nobody is interested. If any non-dev TU wants to maintain some orphan in [extra], reply here and I'll move it to [community]. I will start dropping the leftovers to AUR on April 1st. -- David C. Rankin, J.D.,P.E.

2 1

/dev/stderr in early userspace
by lacsaP Patatetom 23 Mar '23

23 Mar '23

hi, I recently noticed that `/dev/stderr` was not present at the very beginning of the boot, in early userspace. if I add `break` parameter to have control during this step and do a `ls` test, this is what I get: ``` [rootfs ]# ls -l /dev/std* ls: /dev/std*: No such file or directory ``` Is there anything special to add/do to get these special devices ? nothing special in my `mkinitcpio.conf`, `base` and `udev` hooks installed/used. just note that the image is made from a chroot with `arch-chroot` with no error/warning. regards, lacsaP.

2 2