[00:00] <nacc> niedbalski: --^ maybe you're already working on this, as well
[00:38] <Umeaboy> Hi!
[00:38] <Umeaboy> I forgot what package to translate for the installation process. Which one is it?
[00:38] <Umeaboy> ubiquity is the name of the installer, right?=
[00:40] <sarnold> yes; there's also debian-installer
[00:40] <Umeaboy> OK.
[00:41] <Umeaboy> There are some parts of it that's not translated into Swedish that I want to correct.
[01:12] <krytarik> Umeaboy: More specifically, https://translations.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu
[01:13] <Umeaboy> krytarik: Thank you very much. :)
[01:13] <krytarik> You are welcome.
[01:15] <Umeaboy> Hmmmmmmmmm. Swedish seems to be fully translated and still I see some things missing at the start of the installation when you click F3.
[01:15] <Umeaboy> How can that be?
[01:20] <sarnold> was it perhaps -in- an image? I'd be surprised if images are translated
[01:52] <Umeaboy> Never mind.
[01:53] <Umeaboy> What about the text in the window for Version facts?
[01:53] <Umeaboy> When upgrading Ubuntu 16.04 to 16.10.
[03:07] <fo0bar> [test public message for ubuntulog, please ignore the lurker]
[08:04] <dholbach> hey hey
[08:13] <me_irl> join #wordpress
[08:21] <rbasak> nacc: good point, and yes please.
[09:17] <caribou> nacc: yes, this is indeed the situation; we're working on identifying the root cause
[09:43] <rbasak> nacc, caribou: ah, so was I wrong in marking bug 1644428 Invalid for the development release? If the regression also exists in Zesty?
[09:44] <caribou> rbasak: I need to double-check on that
[09:46] <caribou> rbasak: yes, it still affects Zesty as well, I'll change that
[09:46] <rbasak> Thanks! Sorry, I didn't consider that case before.
[09:47] <caribou> rbasak: I should also revert that fix before it causes grief
[09:50] <rbasak> ack
[11:11] <rbasak> cyphermox, lamont: in bug 1621507's test cases, we had previous reported regressions with ip="" and ip=:::::eth0:dhcp. Those should be in the test plan, IMHO.
[11:13] <rbasak> cyphermox: lamont: what are "jderose's use cases"?
[11:15] <rbasak> cyphermox: lamont: also, under "Non-MAAS test cases", will it matter what the network responds with? In the IPv4 cases, we need to make sure that behaviour doesn't change whether or not IPv6 DHCP and/or radvd are present, so the status of the network should be part of the test case.
[11:16] <rbasak> For ip6= I'm not so bothered, since existing users won't be using that.
[11:22] <rbasak> cyphermox, lamont: final two points. 1) are the review fixes we landed in proposed in Xenial in Zesty yet? If not, they should be, and I expect to block release of the SRUs on this. I gave a pass at accepting into proposed only because we were so delayed already; we have time now.
[11:23] <rbasak> cyphermox, lamont: 2) who's actually going to do all the verifications here? It seems to be that nobody is nominated right now, so I'm expecting it to run past the seven days right now, and I know lamont is in a hurry, so you should probably resolve that now.
[14:22] <brendand> what exactly is the analog of --unbuilt-tree in latest versions of autopkgtest?
[14:22] <brendand> is it just that i have to point to the debian directory itself rather than a directory that might contain one?
[14:42] <tjaalton> mterry: could you test xvfb with bitdepth 16, if the qt tests would work then. proposed has xserver with modified xvfb-run, this fixed gtk apps at least
[14:43]  * mterry tries
[14:47] <mterry> tjaalton: I must be doing it wrong, I can't get -depth 16 to work with server-args -- what is the command line for xvfb-run?
[14:48] <mterry> And should I upgrade to proposed xserver before testing?
[14:49] <lamont> rbasak: from chatting with cyphermox yesterday, I was planning to do all the MAAS cases, and we were hoping to pick up some testing by some of the server team -- I expect I'll be doing some testing in those cases today, depending on all the various priorities.
[14:49] <tjaalton> no need to upgrade
[14:49] <tjaalton> mterry: -s "-screen 0 640x480x16"
[14:50] <mterry> ah that last x
[14:50] <mterry> Was x24 for me
[14:50] <mterry> tjaalton: still segfaults if I switch it to x16 (from x24)
[14:52] <tjaalton> hmm ok
[14:52] <tjaalton> was 24 where?
[14:53] <lamont> rbasak: radvd is kinda out-of-scope for the ipv4 testing, since (1) it's outside of the code we're changing, and (2) already changes behavior if present on an otherwise ipv4 network
[14:53] <mterry> tjaalton: how we run the unity8 tests -- -screen 0 1024x768x24"
[14:53] <tjaalton> alright
[14:53] <tjaalton> i thought it used xvfb-run
[14:53] <tjaalton> with it's defaults
[14:54] <mterry> tjaalton: it does use xvfb-run but not with defaults
[14:54] <mterry> tjaalton: I'm happy to set you up to run the failing test, if you want to reproduc
[14:56] <lamont> rbasak: I'll be walking through the final (now in -proposed) changeset and making sure it's properly reflected in zesty, possibly via nagging :D
[14:57] <tjaalton> mterry: there is a mesa commit bisected which is what made gtk apps fail, not sure if it'd help here. and i'm afk :)
[14:57] <rbasak> lamont: I'm not aware of the server team having committed to doing any testing. We're all going on vacation over the next week or two.
[14:57] <lamont> rbasak: it was more of a plea...
[14:58] <rbasak> lamont: radvd> as long as it doesn't change behaviour differently in this SRU. If a user is using ipv4 but has radvd enabled, then does the SRU change that at all?
[14:58] <mterry> tjaalton: ok then.  But maybe the segfault we're seeing now is a different bug than the gtk one?
[14:58] <lamont> no change
[14:58] <rbasak> lamont: zesty> thanks!
[14:58] <rbasak> lamont: no change> have you tested that? :-)
[14:58] <rbasak> lamont: you may alternatively convince me that it's not possible with this change. I'm open to that.
[14:58] <lamont> if radvd is telling ipv6 to autoconf, then it autoconfs.  if it's not, and the machine has no non-link-local ipv6 address, then any side effect radvd may have is moot (ipv6 routes with no ipv6 source address is boring)
[14:59] <tjaalton> mterry: yep, i believe it is
[14:59] <lamont> that is, adding radvd to the network is a prereq for ipv6 netboot, but is otherwise completely orthogonal to the issues
[15:00] <mterry> tjaalton: right, so when you're back at keyboard I can help you reproduce this specific, potentially new, issue
[15:01] <lamont> having said that, the dual-stack (v4dhcponly) test has radvd running (and with autoconf) and the ipv4 test has no radvd and no dhcp6
[15:02] <lamont> rbasak: if you insist, I'll do the test on the dual stack with dhcp4only and radvd not doing autoconf, but ...
[15:02] <rbasak> lamont: sorry, otp
[15:02] <lamont> np
[15:04] <lamont> rbasak: (queuing things up again...) I'm not expecting testing to be complete today, and fridays seem to have a ban on SRUs hitting -updates, so it looks more like a monday landing, assuming the tests are all done, yes?
[15:04]  * lamont laggy
[15:06] <tjaalton> mterry: in about 6h, can write an email too
[15:51] <rbasak> lamont: yes. If everything's done, then I can land first thing my time on Monday.
[16:20] <chiluk> SRU Approval needed: arges, or any other SRU approver. it looks like my recent sru for virt-manager was applied to zesty and xenial, but forgetten yakkety. https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text=virt-manager
[16:26] <nacc> rbasak: caribou: thanks for the confirmation!
[16:27] <caribou> nacc: rbasak: there is no work being queued on the zesty version so I think we should just revert it there too
[16:34] <nacc> caribou: sounds good -- i was looking at the merge, will keep that in mind
[16:42] <slashd> rbasak, I have share on the LP the work I have done so far, and here is the PPA "https://launchpad.net/~slashd/+archive/ubuntu/dhclientnoddns" if you are interested to test it... still looking at the release upgrade portion, again if you have any idea, let me know meanwhile I'm still looking
[16:43] <rbasak> slashd: ack. otp right now. I have a note to look into this.
[16:43] <slashd> rbasak, tks
[16:43] <rbasak> slashd: and good job asking me on a public channel :-)
[16:45] <lamont> rbasak: and confirmed that radvd interaction is as I stated
[16:50] <lamont> rbasak: open-iscsi fix is present in x-p, and zesty... and waiting on an accept in y-p :p
[16:50] <lamont> rbasak: it's a ways down the list, since it's 6 days old now.
[17:00] <nacc> doko: are you planning on merging ldb? samba is going to depend on a newer version if we merge it, it seems
[20:23] <fossfreedom> sil2100: Hi - I have fixed the failed ./run-tests on the merge request for lp:ubuntu-cdimage
[22:08] <pdeee> RAOF, sorry it took a while, but we have proposed Xenial SRU packages for Certbot 0.9.3
[22:08] <pdeee> https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1640978
[22:53] <tjaalton> mterry: hi, got your email, thanks. one question, have you tried with the old libgl somewhere and modifying LD_PRELOAD to match?
[22:54] <mterry> tjaalton: no...
[22:55] <tjaalton> mterry: maybe double-check that so that we're not chasing the wrong thing :)
[22:55] <tjaalton> I haven't built it yet
[22:55] <mterry> tjaalton: I'm not sure I understand how to do what you're asking
[22:55] <tjaalton> grab the old pkg, unpack it in /tmp or something
[22:56] <mterry> ah
[22:56] <tjaalton> libgl1-mesa-glx
[22:56] <mterry> tjaalton: I'm EOD in a minute, but I can try tomorrow
[22:56] <tjaalton> ok, I can try it tomorrow
[22:57] <foli> This it to notify the we are beginning maitenance on Canonical data centre firewalls.