[00:09] <rafaeldtinoco> lol
[00:10] <rafaeldtinoco> i was going to ask if you were aware that dnsmasq doesnt provide a leases file for uv-kvt so uv-kvt ssh <machine> is broken (at least in disco). im thinking fixing it by using nss_libvirt_guest for nsswitch
[00:10] <rafaeldtinoco> no rush though
[00:31] <rbasak> I tested uvtool against Eoan recently when doing the Python 3 porting work. It seemed to work there.
[00:33] <rbasak> uvtool reads from either /var/lib/libvirt/dnsmasq/virbr0.status or /var/lib/libvirt/dnsmasq/default.leases
[00:33] <rbasak> See uvtool/libvirt/__init__.py in the source
[00:33] <rbasak> Start from the mac_to_ip function
[07:31] <ailion> Hello, every one.
[07:32] <ailion> I have followed this tutorial: https://help.ubuntu.com/community/LiveCDCustomizationFromScratch
[07:32] <ailion> and also this one: https://help.ubuntu.com/community/InstallCDCustomization
[07:34] <ailion> Now I am trying to combine these two together.
[07:35] <ailion> Instead of `apt-get install ubiquity-frontend-gtk`, I use `apt-get install subiquity`.
[07:36] <ailion> After rebooting, subiquity runs but stucks at `Network Connections`.
[07:37] <ailion> Is there any tutorial on this topic?
[07:37] <ailion> Thank you!
[10:23] <cpaelzer> rbasak: was it you that had come up with a helper to check the d/copyright information or was that ahasenack?
[10:23] <cpaelzer> I only want to make sure d/copyright in a package is up to date
[10:23] <rbasak> 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] <cpaelzer> ok using the common tools then
[10:24] <rbasak> cpaelzer: I think lintian checks for files not covered in a dep-5 copyright file
[10:24] <cpaelzer> I think they all use https://wiki.debian.org/CopyrightReviewTools
[10:24] <rbasak> We get that happening in new MySQL upstream releases quite a bit
[10:24] <cpaelzer> but I'll run a pedantic lintion to be sure
[11:37] <rafaeldtinoco> ls
[11:37] <rafaeldtinoco> ops
[12:34] <rbasak> 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] <rbasak> This is currently holding up proposed migration of lz4
[12:35] <rbasak> 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] <mdeslaur> rbasak: I just uploaded a mysql to fix that issue, and am about to upload a fix to the fix
[13:40] <mdeslaur> Skuggen: ^
[13:40] <mdeslaur> wait a few minutes, and I'll let you know
[14:02] <rbasak> mdeslaur: ah. Thanks!
[14:03] <rbasak> 2>&1 > $LZ4_EXEC_LOG
[14:03] <rbasak> Hmm
[14:03] <rbasak> Shouldn't that be the other way roun?
[14:04] <rbasak> Or are you intentionally outputting stderr to stdout and leaving only stdout to go to the log file?
[14:05] <rbasak> In this case it'll work either way I think
[14:05] <rbasak> Since stderr presumably no longer outputs anything
[14:05] <rbasak> But it won't work with older versions of lz4
[14:06] <mdeslaur> 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] <mdeslaur> I keep inverting it, and I keep using 2&>1 by mistake
[14:10] <mdeslaur> I suck :)
[14:24] <cpaelzer> kanashiro: squid LGTM and got sponsored, as usual please track migration in a few hours please
[14:25] <cpaelzer> mdeslaur: those who do nothing do no mistakes :-)
[14:31] <kanashiro> cpaelzer, ack, thanks for reviewing and sponsoring :)
[14:33] <cpaelzer> rafaeldtinoco: I have fixed the qa-regression-tests for strongswan
[14:34] <cpaelzer> rafaeldtinoco: I have lnked the MP and with the change the test completes as expected
[14:34] <rafaeldtinoco> cool!
[14:34] <cpaelzer> so this part of your feedback is handled
[14:34] <rafaeldtinoco> finishing up
[14:34] <cpaelzer> rafaeldtinoco: continue to come up with whatever you find
[14:38] <rafaeldtinoco> cpaelzer: on the Breaks:
[14:39] <rafaeldtinoco> we have 5.7.2-1ubuntu2 and ubuntu3
[14:39] <rafaeldtinoco> wouldn't those be broken as well ?
[14:39] <rafaeldtinoco> trongswan-tnc-ifmap (<< 5.7.2-1ubuntu1)
[14:39] <rafaeldtinoco> hum.. << and not <=
[14:42] <rafaeldtinoco> ah ok.. got it #)
[14:42] <cpaelzer> this is of Eoan
[14:42] <rafaeldtinoco> yep
[14:42] <rafaeldtinoco> from eoan and on
[14:42] <cpaelzer> yes
[14:42] <rafaeldtinoco> transitional pkg for 1 release
[14:42] <cpaelzer> for LTS->LTS upgraders it will trigger with 20.04
[14:42] <rafaeldtinoco> yep
[14:42] <cpaelzer> for 19.10->20.04 it already happened
[14:43] <rafaeldtinoco> yep, this type of concern is new to me
[14:43] <rafaeldtinoco> thats why I ask
[14:43] <rafaeldtinoco> makes snese
[14:46] <cpaelzer> I made snese, snot all around - I'll get you rafaeldtinoco
[14:46] <rafaeldtinoco> :P
[14:52] <rafaeldtinoco> cpaelzer: +1 for u
[14:52] <rafaeldtinoco> i think there is still a merge left
[14:52] <rafaeldtinoco> from the 4 you mentioned yesterday
[14:52]  * rafaeldtinoco checks
[14:54] <rafaeldtinoco> nope, i think libseccomp was done already
[14:54] <rafaeldtinoco> let me know if i missed a MR you'd like a review of
[14:58] <cpaelzer> rafaeldtinoco: I'm good  for now, thank you
[15:18] <seb128> hum
[15:18] <seb128> are autosync happening atm?
[15:19] <seb128> I was looking at fontforge that got an update in Debian 2 days ago, should it have been synced since?
[15:36] <cjwatson> [Updating] fontforge (1:20170731~dfsg-2build1 [Ubuntu] < 1:20190801~dfsg-2 [Debian])
[15:36] <cjwatson>  * Trying to add fontforge ...
[15:36] <cjwatson> I: fontforge -> fontforge_1:20170731~dfsg-2build1.
[15:36] <cjwatson> I: fontforge -> fontforge-nox_1:20170731~dfsg-2build1.
[15:37] <cjwatson> I: fontforge -> fontforge-common_1:20170731~dfsg-2build1.
[15:37] <cjwatson> I: fontforge -> libfontforge-dev_1:20170731~dfsg-2build1.
[15:37] <cjwatson> I: fontforge -> fontforge-doc_1:20170731~dfsg-2build1.
[15:37] <cjwatson> fontforge_1:20190801~dfsg-2 is trying to override modified binary fontforge-extras_0.3-4ubuntu1.  OK (y/N)?  n
[15:37] <cjwatson> [Updating] fontforge (1:20170731~dfsg-2build1 [Ubuntu] < 1:20190801~dfsg-2 [Debian])
[15:37] <cjwatson>  * Trying to add fontforge ...
[15:37] <cjwatson> Oops, sorry for second bit
[15:37] <cjwatson> https://people.canonical.com/~ubuntu-archive/auto-sync/current.log
[15:37] <cjwatson> 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] <cjwatson> 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] <cjwatson> So IMO you could sync that manually and disregard the Ubuntu modification
[15:39] <cjwatson> seb128: ^-
[15:40] <seb128> 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] <cjwatson> 15:37 <cjwatson> https://people.canonical.com/~ubuntu-archive/auto-sync/current.log
[15:41] <cjwatson> :-)
[15:43] <seb128> arg, can't read, sorry :(
[15:43] <seb128> cjwatson, thanks!
[15:44] <cjwatson> np :)
[15:54] <rbasak> xnox: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853164 looks right to me. Please could you take a look?
[15:54] <seb128> next 'reports" question, sorry channel :/
[15:54] <seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
[15:54] <seb128> has
[15:54] <seb128> glib2.0 (2.62.1-1 to 2.63.1-2) in proposed for 0 days
[15:54] <seb128>     Regressions
[15:54] <seb128>  pango1.0/1.42.4-7: amd64 (log, history)
[15:55] <seb128> but http://autopkgtest.ubuntu.com/packages/p/pango1.0/focal/amd64 has no failure
[15:55] <seb128> does anyone know what's going on?
[15:57] <seb128> I guess maybe they don't refresh real time and I need to wait a bit longer...
[16:07] <rbasak> rafaeldtinoco: https://bazaar.launchpad.net/~uvtool-dev/uvtool/trunk/revision/93 was the fix I'm referring to
[16:08] <rafaeldtinoco> great. let me re-check
[16:09] <rafaeldtinoco> $ uvt-kvm ssh strongswan-test-1
[16:09] <rafaeldtinoco> uvt-kvm: error: no IP address found for libvirt machine 'strongswan-test-1'. Has it had time to boot yet?
[16:10] <rafaeldtinoco> $ virsh net-dhcp-leases default
[16:10] <rafaeldtinoco>  Expiry Time           MAC address         Protocol   IP address        Hostname   Client ID or DUID
[16:10] <rafaeldtinoco> ---------------------------------------------------------------------------------------------------------------------------------------------
[16:10] <rafaeldtinoco>  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] <rafaeldtinoco>  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] <rafaeldtinoco> the hostnames are ubuntu because of cloud-init (as these 2 machines were just provisioned)
[16:11] <rafaeldtinoco> let me check after a reboot
[16:14] <rafaeldtinoco> I have no /var/lib/libvirt/dnsmasq/default.leases file
[16:14] <rafaeldtinoco> all leases are queried by libvirt but no leases file
[16:14] <rafaeldtinoco> is that expected ?
[16:15] <rbasak> rafaeldtinoco: do you have a /var/lib/libvirt/dnsmasq/virbr0.status file?
[16:15] <rafaeldtinoco> not
[16:15] <rafaeldtinoco> nope
[16:15] <rbasak> Are you using a virbr0 bridge with dnsmasq?
[16:15] <rafaeldtinoco> nope
[16:15] <rafaeldtinoco> kvm.status
[16:15] <rbasak> OK so that's why
[16:15] <rafaeldtinoco> kvm is my default
[16:15] <rafaeldtinoco> ah
[16:16] <rbasak> uvtool doesn't have support for that configuration
[16:16] <rafaeldtinoco> alright, makes sense now
[16:16] <rafaeldtinoco> not a bug
[16:16] <rbasak> So "uvt-kvm ip" and therefore "uvt-kvm ssh" won't work.
[16:16] <rafaeldtinoco> yep
[16:16] <rbasak> If you can implement something more generic, then I'll happily accept a patch
[16:16] <rafaeldtinoco> yep
[16:16] <rbasak> This is all about uvt-kvm's capability of guessing heuristically
[16:16] <rafaeldtinoco> perhaps a query for the default
[16:17] <rafaeldtinoco> $ virsh net-dumpxml default | grep bridge
[16:17] <rafaeldtinoco>   <bridge name='kvm' stp='off' delay='0'/>
[16:17] <rafaeldtinoco> rbasak: ^ something like it
[16:17] <rafaeldtinoco> will give it a try
[16:17] <rafaeldtinoco> let me open a bug for not to forget
[16:17] <rafaeldtinoco> ill flag it as a wishlist
[16:17] <xnox> rbasak:  tagged for foundations to pick up
[16:17] <rbasak> xnox: thanks!
[16:18] <rbasak> 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] <rafaeldtinoco> #1609072 uvt-kvm assumes network is on virbr0
[16:31] <gpiccoli> Hi rbasak, how are you doing? Were you able to check LP #1847924 ?
[16:31] <gpiccoli> We are waiting on a consensus to move forward hehe
[16:55] <rbasak> gpiccoli: sorry I was out last week and have barely caught up
[16:59] <gpiccoli> no problem rbasak =)
[17:29] <rbasak> gpiccoli: I replied in the bug
[17:30] <gpiccoli> THanks Robie =)
[17:33] <rbasak> 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] <rbasak> (which is why I want a second SRU team member opinion)
[17:34] <rbasak> It is only just on the right side of the line to qualify for an SRU IMHO
[17:35] <gpiccoli> ok rbasak, thank you !
[18:05] <Son_Goku> cyphermox, could you please look at doing this soon? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1824245
[19:19] <cyphermox> 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] <Son_Goku> cyphermox, let me see if I can make a test case for this
[19:26] <Son_Goku> 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] <Son_Goku> but I'll try
[19:26] <cyphermox> Son_Goku: if there is no test case, this won't pass for SRU.
[19:28] <Son_Goku> hmm
[19:28] <Son_Goku> 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] <blahdeblah> 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:53] <RAOF> blahdeblah: Hm. My guess would be mesa (since I've seen there's a critical regression there).
[20:53] <RAOF> Ah, no, different version.
[20:55] <RAOF> But trying with the disco version of mesa would be a fine start.
[20:55] <tjaalton> or kernel
[20:56] <blahdeblah> So downgrading just mesa packages might be a viable option?
[20:56] <tjaalton> it's more messy to downgrade mesa than to try an older kernel
[20:56] <blahdeblah> tjaalton: indeed
[20:56] <blahdeblah> 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] <blahdeblah> I'd guess that most of the old advice about acceleration options doesn't apply on modern systems anyway.
[20:57] <tjaalton> right
[20:57] <mwhudson> how much ram do buildds have? (arm64)
[21:19] <bdmurray> cpaelzer: Where did "we agreed to regularly backport those to the latest LTS." from bug 1844834
[21:42] <blahdeblah> thanks tjaalton & RAOF - I'll make sure the bug gets updated with things tried.