[00:00] <vorlon> ahasenack: hmm nevermind, wouldn't help because postgresql-server-dev-12 also Depends: clang-9 and I don't know that this could be made :any (but also, what's with dev packages specifying a compiler :P)
[00:02] <WoC> Could be worse, it could be demanding cobol 1.0.1, which may be tricky to find ;)
[12:18] <AsciiWolf> I have noticed that "info" package that is preinstalled on Ubuntu Focal contains a desktop file (/usr/share/applications/info.desktop) that adds a "TeXInfo" desktop entry that is shown among other (GUI) apps in Shell Overview
[12:18] <AsciiWolf> this desktop item opens a terminal window with the info program
[12:19] <AsciiWolf> I don't think it is a good idea to have something like this showing on a clean system installation since it is confusing for many (regular) users
[12:20] <AsciiWolf> adding something like NotShowIn=GNOME; to the desktop file would solve this
[12:20] <AsciiWolf> but I am not sure if info has an active maintainer in Ubuntu or is just synced from Debian
[12:26] <AsciiWolf> I have made a Launchpad ticket for this: https://bugs.launchpad.net/ubuntu/+source/texinfo/+bug/1859963
[13:19] <rbasak> ahasenack: import complete for netcfg
[13:19] <rbasak> But it looks like it hasn't changed since Feb 2019
[13:19] <rbasak> So I'm not sure it actually did anything
[13:19] <ahasenack> ok
[13:20] <rbasak> Maybe it updated the branch pointers only
[13:41] <juliank> AsciiWolf: I feel like GNOME should just hide applications with Terminal=true in a subfolder
[13:41] <juliank> e.g. "Terminal applications"
[13:54] <AsciiWolf> juliank, hmm, I am not sure... however the info.desktop does not have Terminal=true
[13:54] <juliank> AsciiWolf: Well sure it has
[13:54] <juliank> It's Exec=info\n[...]\nTerminal=true
[13:55] <AsciiWolf> juliank, really? that's weird
[13:56] <AsciiWolf> then I am not sure why it shows on latest Ubuntu Focal among other apps
[14:00] <ahasenack> rbasak: hi, could you please give me some help in figuring out why bind9 is stuck in migration?
[14:00] <ahasenack> I rebuilt every reverse-deps I could find
[14:00] <ahasenack> the only ones I can't really test are the udeb ones
[14:00] <ahasenack> but I did upload debian-installer, which is all that it took in the previous bind9 soname bumps I have done
[14:01] <ahasenack> but now some guestfs packages are showing up in update_output.txt
[14:01] <ahasenack> I installed all os those in amd64 and s390x, then removed all previous bind9 libs, and nothing else was removed. The old bind9 libs were even in the autoremove suggestion list
[14:02] <ahasenack> I'm also trying now on s390x, which has nbdkit-plugin-guestfs
[14:02] <ahasenack> (not available in amd64)
[14:02] <ahasenack> but that also installs fine
[14:03] <ahasenack> and I don't see how that relates to the bind libs
[14:03] <ahasenack> or isc libs
[14:05] <ahasenack> maybe it's debian-installer-udebs on s390x
[14:07]  * ahasenack starts downloading individual udeb packages
[14:08] <rbasak> Looking
[14:10] <rbasak> Yeah I think it's udeb related
[14:11] <rbasak> But amd64 also, not just s390x
[14:11] <ahasenack> ok
[14:14] <ahasenack> rbasak: do you know of any way to easily check udebs, other than downloading them and dpkg -i each one?
[14:14] <ahasenack> i.e., something apt related
[14:15] <rbasak> I was just looking in to that.
[14:15] <rbasak> I want to add debian-installer to chdist
[14:15] <ahasenack> I'm using pull-lp-udebs for now
[14:15] <rbasak> I haven't found a way yet
[14:18] <rbasak> isc-dhcp-client-udeb is one
[14:18] <ahasenack> one what?
[14:18] <rbasak> That'll need rebulding I think. It needs libdns-export1104-udeb for example but the new bind9 is making libdns-export1107-udeb
[14:19] <ahasenack> I did rebuild isc-dhcp, isn't that where the udeb comes from?
[14:19] <rbasak> Ah maybe I'm looking at the release pocket
[14:19] <ahasenack> https://launchpad.net/ubuntu/+source/isc-dhcp/4.4.1-2ubuntu6 is the rebuild
[14:19] <ahasenack> ubuntu6
[14:26] <rbasak> ahasenack: I'm not sure if I'm just catching up with your understanding here
[14:26] <rbasak> debian-installer-udebs in focal-proposed still depends on libdns-export1104-udeb and libisc-export1104-udeb
[14:27] <rbasak> (amd64)
[14:27] <ahasenack> hm
[14:27] <ahasenack> let me see the rebuild logs
[14:27] <rbasak> And also libisc-export1100-udeb
[14:29] <ahasenack> maybe I uploaded it too soon :/
[14:29] <rbasak> I did work out how to get chdist working with debian-installer
[14:29] <rbasak> http://paste.ubuntu.com/p/WJF4SZgJHQ/ for example works
[14:29] <ahasenack> Get:9 http://ftpmaster.internal/ubuntu focal/main/debian-installer amd64 isc-dhcp-client-udeb amd64 4.4.1-2ubuntu5 [210 kB]
[14:30] <ahasenack> it grabbed the old one indeed
[14:30] <ahasenack> same for bind
[14:30] <ahasenack> ok, that explains it
[14:30] <ahasenack> I'll upload again
[14:30] <ahasenack> rbasak: thanks!
[14:31] <rbasak> https://pastebin.ubuntu.com/p/CpKH2dYYMq/ is what gave me the answer in the end
[14:31] <rbasak> You're welcome!
[14:31] <ahasenack> what's chdist-if-migrated?
[14:32] <rbasak> ahasenack: http://paste.ubuntu.com/p/M57JwfjFFW/
[14:33] <ahasenack> cool
[14:34] <AsciiWolf> juliank, I just re-checked it on latest Ubuntu Focal, TeXInfo is showing in Shell Overview although it's desktop file contains "Terminal=true"
[14:34] <AsciiWolf> are you sure that desktop files for terminal applications are normally not showing in GNOME?
[14:36] <juliank> AsciiWolf: No, I meant that GNOME should stop showing them
[14:37] <AsciiWolf> ah :-)
[14:37] <AsciiWolf> I agree
[16:13] <ahasenack> rbasak: bind9 migrated, thanks again for your help
[17:16] <tjaalton> I have a (non-root) zfs mirror on focal, and need to import it after each reboot.. how to fix that?
[17:29] <tjaalton> seems it's bug 1850130
[17:46] <ahasenack> rbasak: hi, quick help again if you are still around
[17:46] <ahasenack> I think doko removed nut from the archive
[17:46] <ahasenack> see https://launchpad.net/ubuntu/+source/nut/+publishinghistory and the output of "rmadison nut"
[17:46] <ahasenack> that only shows nut in focal-proposed
[17:47] <ahasenack> which was kanashiro's upload
[17:47] <ahasenack> we didn't know nut was removed
[17:47] <ahasenack> it's a server package :/
[17:47] <doko> ahasenack: let me look ...
[17:48] <ahasenack> k
[17:53] <doko> both nut and net-snmp are valid candidates
[17:53] <ahasenack> I'm troubleshooting the net-snmp migration, and found this oddity about nut
[17:53] <ahasenack> that is't not in the release pocket
[17:53] <ahasenack> can't say yet it's what is causing the migration to fail, I just spotted it
[17:54] <ahasenack> it's built with the right libsnmp35 lib, so that's good
[17:54] <doko> needs a rebuild
[17:54] <doko> no
[17:55] <ahasenack> nut-snmp has Depends: nut (>= 1.4.1-pre1), libc6 (>= 2.28), libsnmp35 (>= 5.8+dfsg)
[17:55] <doko> ok, you're right
[17:56] <ahasenack> ok, and I think I found the culprit
[17:56] <ahasenack> libsane
[17:57] <doko> ahasenack: looking at the last occurrence of net-snmp in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt shows you that nut is not blocking
[17:57] <doko> yes, libsane is among those
[18:00] <ahasenack> and it all boils down to a dep8 failure in arm64 for gscan2pdf which blocked sane-backends in proposed (which is built with the right libsnmp35)
[18:00] <ahasenack> ok
[18:00] <ahasenack> what a rabbit hole
[18:00] <ahasenack> sorry for the nut alarm
[18:01] <doko> nuts
[18:04] <ginggs> sounds more like a squirrel hole
[18:07] <ahasenack> nuts at the end
[18:08] <ahasenack> man, that test passed just once in 13 runs
[18:08] <ahasenack> http://autopkgtest.ubuntu.com/packages/g/gscan2pdf/focal/arm64
[18:08] <ahasenack> even worse if I count all runs in that page
[18:08] <ahasenack> sea of red
[18:10] <doko> ahasenack: the problem is the amount of triggers you need ... and all-proposed=1 doesn't work because the current arm64 kernel is broken because it was built with a bad binutils
[18:11] <ahasenack> you think gscan2pdf/arm64 is failing because it needs selected packages from proposed?
[18:12] <doko> hmm, no, looks more like a perl package
[18:34] <ahasenack> doko: I can reproduce that hang in gscan2pdf/arm64
[18:35] <ahasenack>   54751 pts/0    Sl+    0:01                                                      \_ /usr/bin/perl t/06190_Dialog_Scan_Image_Sane.t
[18:35] <ahasenack>  (the next test to be run) is stuck
[18:35] <ahasenack> t/0618_Dialog_Scan_Image_Sane.t ............... ok <-- last one logged in the output
[18:35] <ahasenack> I can work with this, maybe even disable just that one test if it comes to it
[19:21] <allquixotic> In terms of testing and bug reports, what is needed for Focal right now? I'm a developer (though not a current contributor to Ubuntu, I have an LP.net account, etc.) and I just updated my laptop from 19.10 to the latest 20.04 packages. I know testing week happened recently but I'm happy to give my 2 cents now as well, and will be on the hunt for obvious bugs while using the system.
[19:24] <sarnold> allquixotic: I think it's probably a bit underwhelming as an answer -- use your system and report bugs as you find them :)
[19:54] <ddstreet> rbasak any change you could import ubuntu-dev-tools into git-ubuntu?  doesn't seem to be there currently
[20:56] <zyga> focal updates crash on ubuntu-release-upgrader: https://pastebin.ubuntu.com/p/zj92spzYNF/
[21:00] <ahasenack> zyga: worth a bug against the release upgrader?
[21:00] <zyga> yeah, I think so
[21:02] <mwhudson> xnox: 57pollinate is not +x in the casper in bionic proposed :(
[21:02] <zyga> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1860606
[21:03] <bryce> allquixotic, apart from finding new bugs, as a tester another great way to help any open source project is to review existing bug reports and see if you can reproduce them, and if so add your findings to the existing bug report.  If there's patches or ppas proposed, verifying those fixes can be super helpful.
[21:03] <sarnold> mdeslaur, juliank, ^^ -- this feels ever so vaguely like this may be a regression https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1860606
[21:03] <mwhudson> oh well easy to fix
[21:07] <allquixotic> bryce: Sure thing. So far things seem _really_ smooth on KDE Plasma. The only thing I had to go off the rails to support is my external GPU; I am using a PPA for egpu-switcher that runs on boot, detects whether the eGPU is attached, and symlinks in an appropriate Xorg.conf. Not sure if eGPU support is planned for Ubuntu-Gnome3 or KDE Plasma for 20.04.
[21:08] <allquixotic> It's "supported" at a hardware level for sure, as I can get it working without issue once egpu-switcher puts in the right Xorg.conf -- my GPUs are an Intel IGP, an Nvidia dGPU in the laptop, and an Nvidia eGPU -- but there's no nice GUI for switching/selecting the GPU. I think pop! OS has that.
[21:11] <mdeslaur> juliank: looks like you forgot to fix aptdaemon in focal
[21:11] <mdeslaur> sarnold: fyi ^
[21:11] <sarnold> mdeslaur: is this running focal code? or eoan code?
[21:12] <zyga> sdhd-sascha: eoan updating to focal
[21:12] <zyga> er
[21:12] <mdeslaur> sarnold: focal, and I confirmed atdaemon isn't patched in focal
[21:12] <zyga> sarnold:
[21:12] <zyga> sarnold: I was running eaon at the time, focal update was initiated with do-release-upgrade -d
[21:12] <zyga> (when it crashed and burned I did it manually)
[21:13] <sdhd-sascha> hey, zyga :-)
[21:13] <zyga> hey :)
[21:13] <mdeslaur> sarnold: I think /me shrugs
[21:14] <mdeslaur> or perhaps eoan wasn't updated before the update to focal
[21:14] <zyga> eoan was freshly updated all the way
[21:14] <zyga> I was going from 19.04 to 19.10 (fully including reboot)
[21:14] <zyga> then to 20.04
[21:15] <sdhd-sascha> zyga: hmm ... what should a distributor do... support all ... or give for each hardware, a branch....
[21:15] <zyga> sdhd-sascha: ?
[21:16] <sdhd-sascha> zyga: well, then all ;-)
[21:16] <sarnold> the other user in #ubuntu who is reporting this same problem also said that python-apt was updated just before starting the do-release-upgrade
[21:16] <sdhd-sascha> sarnold: what problem ?
[21:17] <sdhd-sascha> i'm new here... and can test...
[21:17] <sarnold> sdhd-sascha: when upgrading from eoan to focal, this error message https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1860606
[21:19] <sdhd-sascha> hey, of course. But the message says, that it's sure that one argument is missing ;-
[21:19] <sdhd-sascha> )
[21:19] <mdeslaur> oh right, looks like ubuntu-release-upgrader needs a fix
[21:19] <mdeslaur> juliank: ^
[21:19] <zyga> "run focal they said"
[21:20] <sarnold> still gotta admit it found a bug, right quick too :)
[21:20] <mdeslaur> this is going to fail on every release
[21:20] <sdhd-sascha> zyga: thank you ... really, i like to test the next version ;-)
[21:21] <sdhd-sascha> zyga: but i don't remember what this python library calls... (ncurses thing)
[21:21] <zyga> sdhd-sascha: I don't know what you mean
[21:21] <sdhd-sascha> ...widget...
[21:21] <sdhd-sascha> wait...
[21:24] <bryce> allquixotic, external GPU sounds like something that would best be worked on directly upstream
[21:30] <sdhd-sascha> hey, folks... how can ubuntu in future installed without be hardware aware ?
[21:30] <sdhd-sascha> i don't nknow.
[21:33] <sdhd-sascha> i try to build a limited snap... with seccomp and apparmor... but didn't know if the user had nvidia or amd... what should i limit or do ?
[21:41] <juliank> mdeslaur: oh yes
[21:41] <juliank> mdeslaur: I forgot to fix aptdaemon in focal
[21:41] <mdeslaur> juliank: yeah, but unrelated in this specific issue
[21:45] <sdhd-sascha> hey, i wonder, is mesa packages better - or non mesa ?
[21:51] <sdhd-sascha> zyga: you can ask tomorrow. it's not your timezone;-) what version could land into 20.04?
[21:54] <sdhd-sascha> hey, should i upgrade tomorrow ? or will the new kernel .... ...
[21:54] <sdhd-sascha> ...
[21:55] <sdhd-sascha> (i'm not kernel .. but developer)
[23:59] <CarlFK> a while ago I brought up  bug #1807047
[23:59] <CarlFK> someone said something like "ubuntu is moving away from di"