[05:20] <alkisg> Hi, the latest netplan broke ltsp booting; we mark the boot interface as "manual" in /etc/network/interfaces (and I tried marking it manual in network manager too), but netplan now somehow manages to remove its ip while the computer netboots
[05:20] <alkisg> `rm /lib/systemd/system-generators/netplan` bypasses the problem; but what would be the correct way to tell netplan not to touch the netboot interface?
[05:23] <alkisg> I think the relevant SRU that caused the regression was this one: https://bugs.launchpad.net/netplan/+bug/1763608
[05:23] <ubottu> Launchpad bug 1763608 in netplan "Netplan ignores Interfaces without IP Addresses" [Undecided,Fix committed]
[05:26] <alkisg> cyphermox: ? (sorry for the ping, please ignore me if busy or if it's inappropriate)
[05:31] <alkisg> Netplan generates this file, while AFAIK it shouldn't, as enp0s3 is declared manual in /etc/network/interfaces:  /run/systemd/network/10-netplan-enp0s3.network ==> https://termbin.com/51oc
[05:47] <alkisg> I commented in https://bugs.launchpad.net/netplan/+bug/1763608/comments/43
[05:47] <ubottu> Launchpad bug 1763608 in netplan "Netplan ignores Interfaces without IP Addresses" [Undecided,Fix committed]
[11:58] <tkamppeter> seb128, thanks, have already seen the posts from slangasek on the bugs yesterday.
[11:59] <seb128> tkamppeter, np
[12:00] <tkamppeter> seb128, kenvandine, looks a little bit like that the upstream version update from 1.10.6 to 1.10.14 is of too high impact (whereas a raise of only the micro release number should only add bug fixes).
[12:01] <tkamppeter> Seems we need to carefully select the upstream commits which only fix the bugs the users have complained about and make an SRU out of these.
[12:01] <seb128> tkamppeter, it's trying to address difficult problems, we did discuss other ways but those were not easier
[12:01] <seb128> I don't think that's true
[12:01] <seb128> we need to figure out that specific regression and sort it out and try again
[12:02] <Laney> yep
[12:02] <seb128> upstream seems supportive/ready to help but we need someone who understands the topic to have the conversation
[12:03] <seb128> dwmw2 seems to be engaged and to understand the problem, so maybe he's that person
[12:03] <seb128> but we should still engage/worth with him/them
[12:05] <tkamppeter> seb128, I have also tried one thing: I have asked the posters of the regression whether it helps to also install the systemd SRU (which I have therefore uploaded to my PPA), but got two negative answers on that (was simply trying a low-hanging fruit).
[12:06] <seb128> tkamppeter, you should probably be on #nm btw, that's the upstream channel
[12:06] <seb128> they discussed it a bit earlier and said that
[12:06] <seb128> "<thaller> dwmw2_gone, bengal, the discussion there is long and not clear (to me). Also, there is a lack of logfiles to even understand what is actually happening. Anyway, to my understanding, setting "dns-priority=-1,dns-search=~." is not a "workaround". By default, NM's VPN profiles want to do split-dns and not full-tunnel. So, you need to explicitly configure avoiding "dns leaks". Whether that default is good or not is a separate question he
[12:06] <seb128> re."
[12:08] <seb128> anyway, I think what we lack at this point is someone on our side who understands the topic/components and can figure out what's going on exactly and talk with upstream
[12:08] <seb128> I'm not sure how we solve that gap
[12:09] <seb128> either by doing the needed studying or by involving people on our side who have the expertise I guess
[12:09] <seb128>  
[12:09] <seb128> is error.u.c timing out for others?
[12:09] <seb128> ah, it's back
[12:10] <seb128> I just had to ask, it was failing to load for 10 min or so :p
=== ricab is now known as ricab|lunch
=== ricab|lunch is now known as ricab
=== gusnan is now known as Guest54496
=== gusnan_ is now known as gusnan
[18:38] <rbalint> juliank, i think apt should tell me if i just ran apt update or apt upgrade on a release which left the standard support period
[18:38] <rbalint> juliank, i think it would be helpful on systems not showing motd, such as docker or wsl
[18:38] <juliank> ack
[18:38] <juliank> we can add that to ua client
[18:39] <juliank> I think
[18:39] <juliank> It's a bit tough to figure out if you're unsupported or not
[18:39] <juliank> (from C++)
[18:40] <juliank> oh hang on
[18:41] <juliank> With trusty esm it basically hints very strongly after upgrade, as it will tell you there are ESM updates
[18:41] <juliank> It might be worth telling people there release is in ESM now, or especially if it is EOL
[18:41] <rbalint> juliank, i think we should cover interim releases, too
[18:42] <rbalint> juliank, and clearly telling it is maybe better than just hinting it
[18:45] <rbalint> juliank, on zesty i see ... old-releases.ubuntu.com ... in apt update's log which is a hint, but i share rcj's concern that some users are still left on unsupported releases because the did not notice the hints
[18:47] <rcj> rbalint: how did you get that?  shouldn't it just try archive.ubuntu.com and fail due to lack of Release files?  What changed your zesty machine to old-releases.ubuntu.com?
[18:50] <rbalint> rcj, maybe me, just forgot that :-)
=== gusnan is now known as Guest30687
=== gusnan_ is now known as gusnan