[00:09] lol [00:10] i was going to ask if you were aware that dnsmasq doesnt provide a leases file for uv-kvt so uv-kvt ssh is broken (at least in disco). im thinking fixing it by using nss_libvirt_guest for nsswitch [00:10] no rush though [00:31] I tested uvtool against Eoan recently when doing the Python 3 porting work. It seemed to work there. [00:33] uvtool reads from either /var/lib/libvirt/dnsmasq/virbr0.status or /var/lib/libvirt/dnsmasq/default.leases [00:33] See uvtool/libvirt/__init__.py in the source [00:33] Start from the mac_to_ip function === jamesh_ is now known as jamesh [07:31] Hello, every one. [07:32] I have followed this tutorial: https://help.ubuntu.com/community/LiveCDCustomizationFromScratch [07:32] and also this one: https://help.ubuntu.com/community/InstallCDCustomization [07:34] Now I am trying to combine these two together. [07:35] Instead of `apt-get install ubiquity-frontend-gtk`, I use `apt-get install subiquity`. [07:36] After rebooting, subiquity runs but stucks at `Network Connections`. [07:37] Is there any tutorial on this topic? [07:37] Thank you! [10:23] rbasak: was it you that had come up with a helper to check the d/copyright information or was that ahasenack? [10:23] I only want to make sure d/copyright in a package is up to date [10:23] cpaelzer: it was a task for me to write up a spec, but that never bubbled up to the top of my TODO [10:24] ok using the common tools then [10:24] cpaelzer: I think lintian checks for files not covered in a dep-5 copyright file [10:24] I think they all use https://wiki.debian.org/CopyrightReviewTools [10:24] We get that happening in new MySQL upstream releases quite a bit [10:24] but I'll run a pedantic lintion to be sure [11:37] ls [11:37] ops [12:34] Skuggen: could you take a look at bug 1853144 please? I think this needs an upstream fix, and in the meantime a patch to the test should be fairly trivial in a distro patch. [12:35] bug 1853144 in mysql-8.0 (Ubuntu) "main.mysqlpump_basic_lz4 dep8 test fails with a false positive" [Undecided,Triaged] https://launchpad.net/bugs/1853144 [12:35] This is currently holding up proposed migration of lz4 [12:35] Which we could force since it's not a regression in lz4, but we'd still be stuck with mysql failing dep8 in the future so it would be easier to just fix it :) [13:40] rbasak: I just uploaded a mysql to fix that issue, and am about to upload a fix to the fix [13:40] Skuggen: ^ [13:40] wait a few minutes, and I'll let you know [14:02] mdeslaur: ah. Thanks! [14:03] 2>&1 > $LZ4_EXEC_LOG [14:03] Hmm [14:03] Shouldn't that be the other way roun? [14:04] Or are you intentionally outputting stderr to stdout and leaving only stdout to go to the log file? === ricab is now known as ricab|bbl [14:05] In this case it'll work either way I think [14:05] Since stderr presumably no longer outputs anything [14:05] But it won't work with older versions of lz4 [14:06] rbasak: yes, I inverted it by mistake, so it only worked with the new version...with it inverted it should work with both versions [14:10] I keep inverting it, and I keep using 2&>1 by mistake [14:10] I suck :) [14:24] kanashiro: squid LGTM and got sponsored, as usual please track migration in a few hours please [14:25] mdeslaur: those who do nothing do no mistakes :-) [14:31] cpaelzer, ack, thanks for reviewing and sponsoring :) [14:33] rafaeldtinoco: I have fixed the qa-regression-tests for strongswan [14:34] rafaeldtinoco: I have lnked the MP and with the change the test completes as expected [14:34] cool! [14:34] so this part of your feedback is handled [14:34] finishing up [14:34] rafaeldtinoco: continue to come up with whatever you find [14:38] cpaelzer: on the Breaks: [14:39] we have 5.7.2-1ubuntu2 and ubuntu3 [14:39] wouldn't those be broken as well ? [14:39] trongswan-tnc-ifmap (<< 5.7.2-1ubuntu1) [14:39] hum.. << and not <= [14:42] ah ok.. got it #) [14:42] this is of Eoan [14:42] yep [14:42] from eoan and on [14:42] yes [14:42] transitional pkg for 1 release [14:42] for LTS->LTS upgraders it will trigger with 20.04 [14:42] yep [14:42] for 19.10->20.04 it already happened [14:43] yep, this type of concern is new to me [14:43] thats why I ask [14:43] makes snese [14:46] I made snese, snot all around - I'll get you rafaeldtinoco [14:46] :P [14:52] cpaelzer: +1 for u [14:52] i think there is still a merge left [14:52] from the 4 you mentioned yesterday [14:52] * rafaeldtinoco checks [14:54] nope, i think libseccomp was done already [14:54] let me know if i missed a MR you'd like a review of [14:58] rafaeldtinoco: I'm good for now, thank you [15:18] hum [15:18] are autosync happening atm? [15:19] I was looking at fontforge that got an update in Debian 2 days ago, should it have been synced since? [15:36] [Updating] fontforge (1:20170731~dfsg-2build1 [Ubuntu] < 1:20190801~dfsg-2 [Debian]) [15:36] * Trying to add fontforge ... [15:36] I: fontforge -> fontforge_1:20170731~dfsg-2build1. [15:36] I: fontforge -> fontforge-nox_1:20170731~dfsg-2build1. [15:37] I: fontforge -> fontforge-common_1:20170731~dfsg-2build1. [15:37] I: fontforge -> libfontforge-dev_1:20170731~dfsg-2build1. [15:37] I: fontforge -> fontforge-doc_1:20170731~dfsg-2build1. [15:37] fontforge_1:20190801~dfsg-2 is trying to override modified binary fontforge-extras_0.3-4ubuntu1. OK (y/N)? n [15:37] [Updating] fontforge (1:20170731~dfsg-2build1 [Ubuntu] < 1:20190801~dfsg-2 [Debian]) [15:37] * Trying to add fontforge ... [15:37] Oops, sorry for second bit [15:37] https://people.canonical.com/~ubuntu-archive/auto-sync/current.log [15:37] i.e. the new source is taking over a binary package that currently has Ubuntu modifications. This needs a developer to check it [15:38] Though that modification is a bit odd. There's no need for a source change to change the section of a binary package - that's done via overrides anyway [15:38] So IMO you could sync that manually and disregard the Ubuntu modification [15:39] seb128: ^- [15:40] cjwatson, ah, thanks for checking! can you remind me where is the log for the autosyncs so I can maybe try to look myself before asking next time [15:41] 15:37 https://people.canonical.com/~ubuntu-archive/auto-sync/current.log [15:41] :-) [15:43] arg, can't read, sorry :( [15:43] cjwatson, thanks! [15:44] np :) [15:54] xnox: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853164 looks right to me. Please could you take a look? [15:54] Launchpad bug 1853164 in systemd (Ubuntu) "systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error" [Undecided,New] [15:54] next 'reports" question, sorry channel :/ [15:54] https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages [15:54] has [15:54] glib2.0 (2.62.1-1 to 2.63.1-2) in proposed for 0 days [15:54] Regressions [15:54] pango1.0/1.42.4-7: amd64 (log, history) [15:55] but http://autopkgtest.ubuntu.com/packages/p/pango1.0/focal/amd64 has no failure [15:55] does anyone know what's going on? [15:57] I guess maybe they don't refresh real time and I need to wait a bit longer... [16:07] rafaeldtinoco: https://bazaar.launchpad.net/~uvtool-dev/uvtool/trunk/revision/93 was the fix I'm referring to === ricab|bbl is now known as ricab [16:08] great. let me re-check [16:09] $ uvt-kvm ssh strongswan-test-1 [16:09] uvt-kvm: error: no IP address found for libvirt machine 'strongswan-test-1'. Has it had time to boot yet? [16:10] $ virsh net-dhcp-leases default [16:10] Expiry Time MAC address Protocol IP address Hostname Client ID or DUID [16:10] --------------------------------------------------------------------------------------------------------------------------------------------- [16:10] 2019-11-19 13:52:38 52:54:00:3a:02:05 ipv4 172.16.0.139/24 ubuntu ff:b5:5e:67:ff:00:02:00:00:ab:11:13:da:41:eb:da:62:95:19 [16:10] 2019-11-19 13:52:47 52:54:00:dd:ca:94 ipv4 172.16.0.186/24 ubuntu ff:b5:5e:67:ff:00:02:00:00:ab:11:95:f1:d8:ff:c1:31:e8:5f [16:11] the hostnames are ubuntu because of cloud-init (as these 2 machines were just provisioned) [16:11] let me check after a reboot [16:14] I have no /var/lib/libvirt/dnsmasq/default.leases file [16:14] all leases are queried by libvirt but no leases file [16:14] is that expected ? [16:15] rafaeldtinoco: do you have a /var/lib/libvirt/dnsmasq/virbr0.status file? [16:15] not [16:15] nope [16:15] Are you using a virbr0 bridge with dnsmasq? [16:15] nope [16:15] kvm.status [16:15] OK so that's why [16:15] kvm is my default [16:15] ah [16:16] uvtool doesn't have support for that configuration [16:16] alright, makes sense now [16:16] not a bug [16:16] So "uvt-kvm ip" and therefore "uvt-kvm ssh" won't work. [16:16] yep [16:16] If you can implement something more generic, then I'll happily accept a patch [16:16] yep [16:16] This is all about uvt-kvm's capability of guessing heuristically [16:16] perhaps a query for the default [16:17] $ virsh net-dumpxml default | grep bridge [16:17] [16:17] rbasak: ^ something like it [16:17] will give it a try [16:17] let me open a bug for not to forget [16:17] ill flag it as a wishlist [16:17] rbasak: tagged for foundations to pick up [16:17] xnox: thanks! [16:18] xnox: I pinged because the bug report claim seemed correct in principle, and it's a trivial fix, patch provided. Not checked the patch itself for correctness or anything. [16:18] #1609072 uvt-kvm assumes network is on virbr0 [16:31] Hi rbasak, how are you doing? Were you able to check LP #1847924 ? [16:31] Launchpad bug 1847924 in mdadm (Ubuntu Focal) "Introduce broken state parsing to mdadm" [Medium,In progress] https://launchpad.net/bugs/1847924 [16:31] We are waiting on a consensus to move forward hehe [16:55] gpiccoli: sorry I was out last week and have barely caught up [16:59] no problem rbasak =) [17:29] gpiccoli: I replied in the bug [17:30] THanks Robie =) [17:33] gpiccoli: I also want really hard testing for this SRU. I don't think causing users hassle because of a regression in the process of landing this will be very excusable. [17:34] (which is why I want a second SRU team member opinion) [17:34] It is only just on the right side of the line to qualify for an SRU IMHO [17:35] ok rbasak, thank you ! [18:05] cyphermox, could you please look at doing this soon? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1824245 [18:05] Launchpad bug 1824245 in grub2 (Ubuntu Xenial) "Can't create a bootable disk by doing image creation on a loop device" [Medium,Triaged] [19:19] Son_Goku: ok, looking now; but could you please follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure to make sure the bug includes test cases? I don't know what steps need to be taken precisely to verify this; it would be best if it was clearly described [19:25] cyphermox, let me see if I can make a test case for this [19:26] I don't know if I can guarantee that I can make one, given the logic is kinda tangled in an internal business tool :( [19:26] but I'll try [19:26] Son_Goku: if there is no test case, this won't pass for SRU. [19:28] hmm [19:28] let me see if I can make a minimal test case [19:28] * Son_Goku grumbles at the fact this tool is written in spaghetti PHP code [20:23] RAOF: Hi - any chance you can give some general advice on https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1852170 ? It is a regression from disco to eoan, and the wiki doesn't really give much guidance on how to troubleshoot. [20:23] Launchpad bug 1852170 in xorg (Ubuntu) "Severe screen corruption" [Undecided,New] [20:53] blahdeblah: Hm. My guess would be mesa (since I've seen there's a critical regression there). [20:53] Ah, no, different version. [20:55] But trying with the disco version of mesa would be a fine start. [20:55] or kernel [20:56] So downgrading just mesa packages might be a viable option? [20:56] it's more messy to downgrade mesa than to try an older kernel [20:56] tjaalton: indeed [20:56] I have vague memories of a really old wiki page or similar which used to recommend different acceleration options to start disabling to see where the problem lies, but the current state of the X troubleshooting page on the wiki doesn't seem to include anything about display corruption. [20:57] I'd guess that most of the old advice about acceleration options doesn't apply on modern systems anyway. [20:57] right [20:57] how much ram do buildds have? (arm64) [21:19] cpaelzer: Where did "we agreed to regularly backport those to the latest LTS." from bug 1844834 [21:19] bug 1844834 in open-vm-tools (Ubuntu Eoan) "open-vm-tools 11.0.0 released" [Undecided,Triaged] https://launchpad.net/bugs/1844834 [21:42] thanks tjaalton & RAOF - I'll make sure the bug gets updated with things tried.