[04:42] gcr-viewer.desktop:X-GNOME-Bugzilla-Component=gcrX-Ubuntu-Gettext-Domain=gcr that looks correct! :D [08:48] xnox: o/ [08:50] xnox: wearing my server team hat, rather than my SRU hat: how do you plan to proceed with intel-microcode please? [09:08] rbasak, yo. it's in the unapproved queue. Waiting for accept or a reject with a snarky comment. [09:08] which is the usual responses i get with most of my sru upload. [09:09] (then again maybe snarky comments are only from a pw & i nfinity.... and maybe only for me....) [09:11] xnox: I hadn't rejected in case SRU consensus was the opposite of my opinion. [09:12] xnox: but I've had +1 and no opinion from anyone else. [09:12] rbasak, my expectation is for SRU review be more trigger happy - one way or the other. [09:12] Fair enough [09:12] * rbasak pulls the trigger [09:17] Laney: based on touched-it-last do you want to figure out why session-migrate ftbfs with python 3.6? [09:17] Laney: https://launchpadlibrarian.net/324067009/buildlog_ubuntu-artful-amd64.session-migration_0.3_BUILDING.txt.gz [09:18] (or decide it's irrelevant now and remove it from the archive) [09:18] didrocks: you too? ^^ [09:18] haha [09:18] it's certainly not irrelevant [09:20] boo! [09:21] rbasak, awww my proposed srus got rejected. But i think what i have prepared was right. I have no other updates to propose for this package to upload. Removing assignee. [09:21] hasn't built since y so let's see if it's broken in artful already [09:21] yes it is [09:23] * Laney nods [09:23] the failure is not very transparent [09:28] it's complaining about the " somehow [09:30] xnox: you want me to ask my manager to ask the foundations manager to assign someone as I think it's important for server users? [09:30] rbasak, i believe intel-microcode is not actually subscribed by any team =/ and there was confusion whether kernel, foundations or server should be taking care of it. [09:31] xnox: Zesty would be OK, but then it'd be inconsistent with the other upcoming SRUs. [09:31] xnox: understood. I think one of those three teams needs to start taking care of it. I'll ask my manager to hammer it out with the other teams. [09:31] rbasak, at least zesty can be used as a canary to check this microcode doesn't kill puppies. [09:33] Laney: yeah [09:33] xnox: I don't like it, but OK. [09:33] Laney: some unicode nonsense? [09:37] no the stderr really does contain ? not " [09:37] why would that be... [09:46] xnox: do you know if microcode updates are persistent or do they need re-application on every reboot? [09:47] Laney: looks like glib changed: [09:47] mwhudson@aeglos:/opt/opensource/deb/py36$ grep "Failed to exec" -r glib2.0-2.*/glib/gspawn.c [09:47] glib2.0-2.48.2/glib/gspawn.c: _("Failed to execute child process \"%s\" (%s)"), [09:47] glib2.0-2.53.3/glib/gspawn.c: _("Failed to execute child process “%s” (%s)"), [09:47] Laney: not sure why that's getting mangled to ? though [09:47] that's not a ? though [09:47] :) [09:47] jinx [09:50] mwhudson: maybe a missing setlocale(LC_ALL, "")? [09:50] yeah something like that maybe [09:50] and setting of a UTF-8 locale [09:50] in session-migrate itself [09:50] ? [09:50] in main, yeah [09:51] the tests are decoding things to UTF-8 so probably running in C.UTF-8 would be expected? [09:55] rbasak, they are not persistent. On each boot stock microcode is loaded, then uefi firmware may update the microcode, then we get a chance to update the microcode in the initramfs, and then on recent kernels microcode can be updated at runtime, and then all of that is lost on reboot. [09:56] Laney: sounds plausible at least, i have an anglophone's confusion when it comes to locales [09:56] rbasak, hence e.g. in the SRU bug i'm asking for journalctl -k / dmesg output, it should be similar to http://paste.ubuntu.com/24971121/ when a relevant microcode has been applied. [09:56] mwhudson, it's mostly s/s/z/ [09:58] xnox: thanks, that's very useful to know. What's the the difference between early initramfs and normal runtime from the kernel/hardware perspective? I didn't think there was any distinction? But there has been talk of Trusty not having early initramfs support. I don't follow why that's a thing. [09:59] rbasak, early micocode loading means that microcode is appended to the initramfs as an extra cpio archive. The kernel looks at the initramfs, notices there is microcode appended, and then it loads the microcode before executing init of the initramfs. [09:59] rbasak, meaning that microcode is loaded "early", before any userspace process is started. [10:00] rbasak, this is relevant in the context of e.g. lock ellision where microcode update _removes CPU instructions_ [10:00] Ah. That makes sense - thanks! [10:00] and e.g. loaded shared libraries already did the checks if they can use something, continue to try to use them, and segfault. [10:04] didrocks: mwhudson: something like https://paste.debian.net/973679/ ? [10:08] Laney: +1 (is the "Run the tests in C.UTF-8" part really necessary, it's not in my sbuild at least...) [10:08] mwhudson: I don't know what you're guaranteed [10:08] when I entered an schroot I was in the POSIX locale [10:08] Laney: belt and braces it is then! [10:09] and it fails there obvs [10:09] it's didrocks project really so I'll wait for his review [10:16] Laney: ok [10:45] xnox: are you going to end up looking at botch for the ocaml transition? [10:49] mwhudson, yes. it is a lie that it is in the second round, as it clearly fails to install things from like round six. [10:49] mwhudson, i still have a bit to do to get there http://people.canonical.com/~ubuntu-archive/transitions/html/html/ocaml.html [10:50] xnox: ok [10:50] sorry level 7, as botch wants dose3 to be installable. [10:50] i have been uploading level 3 fixes today [10:50] xnox: python 3.6 does something odd to it but i can't look into that until it's build-deps install again :) [10:51] mwhudson, its build-deps should be installable in the -release pocket; e.g. you should be able to install botch and all the build-deps in the release pocket without -proposed. [10:51] mwhudson, and then get python 3.6 into there. No? [10:51] ah yea that might work [10:51] i also have a lot of other things i could look at first [10:51] that is also true [11:00] xnox: i owe you an email about subiquity stuff, will have to be tomorrow now [11:00] xnox: was going to suggest maybe implementing vlan support first [11:02] mwhudson, could do. [11:03] mwhudson, at the moment i'm fixing livecd-rootfs to give me something sensible on s390x. At the moment build success; no contents. As the binary hooks ignore errors from snap download =) [11:03] ha [11:03] mwhudson, i, at the moment, still have plenty of things i could be doing with subiquity. [11:04] mwhudson, any tips / documentation on how you rebuild subiquity and re-run it in development would be helpful. So far I am improvising as I go along. [11:04] xnox: there is an inscrutable script in installer/geninstaller [11:04] but it's very different from the livecd-rootfs process so yeah [11:04] mwhudson, tah! will look. [11:05] * xnox picked the devil i know - livecd-rootfs path =) [11:05] this area is not really idea [11:05] if you can come up with instructions to make an image with livecd-rootfs on my machine, that'd be great [11:06] i am using launchpad builders at the moment, but it should be possible to use Odd_Bloke's cloud builder to do a completely local build with local shnaps and local livecd-rootfs === JanC is now known as Guest24635 === JanC_ is now known as JanC === Sir_Gallantmon is now known as Son_Goku [13:30] Laney: sorry, having water infiltration and a specialist came, checking in [13:38] Hi [13:38] Is there any way one can pass DKMS module for my storage RAID controller card using live PXE environment [13:46] Laney: mwhudson: ok, the patch looks good to me, and indeed, C.UTF-8 fun :) mind doing a PR against https://code.launchpad.net/~ubuntu-desktop/session-migration/trunk ? (you can even upload it yourself if you want, I don't mind) [14:04] didrocks: oh dear [14:17] Any idea how can one pass DKMS driver during the PXE boot installation [14:17] Ubuntu trusty lacks RAID controller driver and I need to pass it during the installation phase [14:18] usually I use driver disk to pass it [14:18] But now I have Live PXE boot environment [15:05] doko, this is known / transient? [15:05] dpkg: error processing archive /tmp/apt-dpkg-install-VAxZ47/32-gcc-6_6.3.0-20ubuntu1_ppc64el.deb (--unpack): [15:05] trying to overwrite '/usr/lib/gcc/powerpc64le-linux-gnu/6/liblto_plugin.so.0.0.0', which is also in package cpp-6 6.3.0-14ubuntu3 [15:46] apt 1.5~alpha1 should hit artful tomorrow, making libgnutls28 a dependency of the apt package, because the http method gains native https support. [15:47] That's still very early now, so it's opt-in (set dir::bin::methods::https to "http") [15:47] Very early as in: I wrote this yesterday [16:02] in anticipate it becoming the default in a few weeks, though, so please test :) [and I forget to syncpackage it from experimental it would be great if somebody else does] [16:03] Once the new https method is default, apt-transport-https will then install an curl+https variant or something [16:04] and we drop it next release cycle [16:04] so 18.04 LTS is a test monkey for bustler?! =) [16:05] xnox: Yeah. Like 16.04 is for stretch, mostly :) [16:06] stretch was the first time apt > 1.1 was shipped in Debian, I'm not sure when we started shipping that in Ubuntu [16:06] "buster" not "bustler" :D [16:07] we started with xenial, 16.04 [16:07] 1.2.10-1.2.20 [16:07] Did willy still have 1.0.something? [16:07] ehm, wily, and yes [16:08] So, we put one of the biggest releases in APT's history into an LTS release without even having a single test release before it.... [16:08] https://launchpad.net/ubuntu/+source/apt/+publishinghistory?batch=75&direction=backwards&memo=150&start=75 [16:08] Luckily that went well [16:08] xenial I would say [16:08] with a shiny 1.1.3 [16:09] LocutusOfBorg: I just looked at https://launchpad.net/ubuntu/wily/+source/apt, and that was 1.0.10.2ubuntu1 [16:09] so, yes, xenial [16:09] publishinghistory keeps tracks also of removals [16:09] in case some AA removed it after being copied from unstable/experimental or whatever [16:09] but who would remove that lovely apt 1.1? :D [16:11] 1.5 will be artful's series, and it surely will be artful. [16:14] infinity: I just disabled test-apt-download-progress in my master branch, I thought you'd like to know [16:18] laughing as we mangle each other's release code names [16:45] juliank: Just gave up trying to make it reliable? :P [17:03] infinity: Too annoyed that 1.4.6 has not migrated yet [17:03] Can make it more reliable later, but want to have reasonable situation now [17:07] juliank: Oh. Let me bump that hint for 1.4.6 :P [17:08] juliank: (But yay if I never have to hint that test again) [17:08] Do we have https enabled Ubuntu mirrors? [17:09] juliank: None that Canonical hosts. [17:09] juliank: We do, however, rely heavily on apt-transport-https for private PPAs. [17:09] juliank: (1.4.6 hinted) [17:10] Of course, won't migrate until the alpha freeze is lifted tomorrow. [17:10] infinity: But that's not a huge set of users to test the new https method, then :) [17:10] infinity: thx [17:10] juliank: It's not an insignificant number, but certainly not as huge as https-everywhere mirrors would be, no. [17:11] juliank: OTOH, I'm fundamentally opposed to people who think bulk traffic should go over https "just because" :P [17:11] "I don't want the gubmint to spy on me and know that I install moon-buggy on all my servers." [17:12] infinity: Ah, not just because, people want to make it harder to figure out which packages you download, so they don't know which software versions you have installed. [17:12] or even which packages [17:12] juliank: Yeah, I covered that. ;) [17:12] juliank: And yes, it's a plausible attack vector, sort of, except that people who are that paranoid should also be installing the latest security updates ANYWAY. [17:12] juliank: So, it kinda negates itself. [17:13] infinity: Not sure. But I guess it also helps with some "helpful" firewalls [17:13] Unless they are too "helpful" [17:14] juliank: Unless what they're really saying is "I don't want people to know that it takes me three months to evaluate a security update before rolling it out" in which case, I think they get to keep aaaaaall the pieces left to them from their inevitable intrusion. [17:14] xnox: can I retry your systemd upload builds? I'm running artful :-/ [17:14] infinity: And well, there are also https proxies, which we'll soon be able to support :) [17:15] I have my experiences with https proxies.... [17:15] Oh look, doko broke gcc. [17:16] never [17:16] has anyone tried to use the autopkgtest-virt backends with sbuild successfully? Specifically trying ot use autopkgtest-virt-lxd [17:16] juliank: Right. So, none of the above was in any way meant to discourage you from improving https support. Just a bit of a tangential rant about https archives. [17:16] Unpacking gcc-6 (6.3.0-20ubuntu1) over (6.3.0-14ubuntu3) ... [17:16] dpkg: error processing archive /tmp/apt-dpkg-install-OLqr6Z/37-gcc-6_6.3.0-20ubuntu1_amd64.deb (--unpack): [17:16] trying to overwrite '/usr/lib/gcc/x86_64-linux-gnu/6/liblto_plugin.so.0.0.0', which is also in package cpp-6 6.3.0-14ubuntu3 [17:16] dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) [17:16] doko: ^ [17:17] doko: I'm going to delete it from proposed, so it stops breaking builds. [17:17] Ta [17:17] ok [17:17] hmm, it should have a replaces ... [17:17] infinity: Would be good if we can drum up some people that check over the code from a security perspective, it's only about 300 lines of gnutls calling now, that seems a bit easy. [17:18] That's the TLS support: https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=2851ec6cf037d552118b885be0dd7796d74730c6 [17:18] juliank: You might see if sarnold (or someone else from his team) is down to do a review/audit for you. [17:19] rbasak: I'll retry all the builds that broke when it's gone. [17:19] Thanks! [17:19] Eww, I accidentally squashed the SOCKS refactoring in there [17:19] So, only below the whole socks part [17:20] If somebody wants to be silly, we can run SOCKS on TLS if there is demand. [17:21] infinity: do you have a binary package, or a build log? can't find it in lp [17:21] doko: https://launchpadlibrarian.net/325906551/buildlog_ubuntu-artful-amd64.systemd_233-8ubuntu2_BUILDING.txt.gz [17:21] doko: Can't find what in LP? [17:21] infinity: no, the gcc-6 build log [17:21] doko: https://launchpad.net/ubuntu/+source/gcc-6/6.3.0-20ubuntu1 [17:22] ok, that link doesn't exist anymore from the gcc-6 page [17:22] doko: Indeed, because I deleted the package. [17:24] doko: So, indeed, there's no Replaces there. [17:52] infinity: uploaded -21. the patch backported from gcc-7 applied to the wrong chunk :-/ [17:54] doko: Oops. [17:56] doko: "cpp-6 (<< 7.1.1-8)" <-- Shouldn't that be 6.3.0-20 for cpp-6? Using a 7 version there means you'll have that Replaces "active" for the life of gcc-6. [17:57] ohh, sure. I'll fix that. but that shouldn't hurt for the upload [17:57] xnox: Ubuntu's systemd has been kept in sync, so have you discussed your change with Debian? https://bugs.debian.org/761658 [17:57] Debian bug 761658 in systemd "Please do not default to using Google nameservers" [Wishlist,Open] [17:57] doko: Yeahp, should be fine for now. [18:34] jbicha, xnox: Debian's position is clear, no? What is there to discuss? Note that they justify their position in part by systemd-resolved not being enabled by default. I think it is in Ubuntu now? [18:36] rbasak: maybe resolved would be enabled in unstable too? I think it's at least polite to let the Debian maintainer know when Ubuntu intends to diverge [18:37] it's about communication; I'm not saying Ubuntu shouldn't diverge when it makes sense [18:40] IIRC mbiebl wasn't interested in changing the setting since it didn't seem to be a practical problem since nobody used resolved; that basis is no longer true now [18:40] oh, I didn't realize he was in this channel, hi! [18:41] IMO it's the person who makes the change who should start the conversation :) [19:07] jbicha: can you give me some context? [19:08] mbiebl: https://launchpad.net/ubuntu/+source/systemd/233-8ubuntu2 [19:14] xnox: I assume if no fallback server is defined, the DNS servers acquired via dhcp are tried again (in order)? [19:15] not sure if I understand https://github.com/systemd/systemd/issues/5755 correctly, but it seems, resolved switches to alternative DNS servers (and the fallback) very quickly [19:15] and sticks with them [19:16] i.e. it doesn't retry the servers in order like defined in /etc/resolv.conf on a new request [19:17] in light of that, it seems resolved uses the google name servers more often then necessary === rekoil_ is now known as rekoil [20:20] Hmm, so looking at bug 1522675, AFAICT all that needs to happen is for update-notifier to Pre-Depend on apt (>= 1.1~) and then change the owner of /var/lib/update-notifier/package-data-downloads/partial/ to _apt [20:20] bug 1522675 in update-notifier (Ubuntu) "Warning messages about unsandboxed downloads" [Medium,Triaged] https://launchpad.net/bugs/1522675 [20:22] Or is that owned by update-notifier-common [20:23] I'm not entirely sure where the dir is created [20:23] nvm [20:39] juliank: I'm annoyed that I see the warning when I use "apt install ./foo.deb" as a subsitute for "dpkg -i" or gdebi [20:40] you can do that? o_O [20:41] the ./ is a bit annoying too but that's a different issue [20:41] jbicha: The ./ is really annoying IMO [20:41] But not my decision [20:42] Well, I did not make the decision [20:42] jbicha: I hope we can drop the ./ when we turn of regex and glob matching, and switch to a stricter CLI [20:44] jbicha: Where do you see that, I don't see that in zesty [20:45] Hmm, but I guess _apt seems to have read access to my files [20:45] Now [20:46] jbicha: It's fairly silly for file:/, I agree [20:46] Or well, there is no download at all I think [20:46] juliank: https://paste.debian.net/973798/ [20:47] I did mention this on that LP bug :) would you like me to file a new bug somewhere? [20:53] jbicha: Well, this issue was "scary message" and that's "solved" [20:53] So yes, another issue might be a good idea [20:54] Anyhow, let's hope I did not break update-notifier-common :) [20:55] I tested it, and it seems fine, but there might be issues [20:55] The diff is tiny: https://launchpadlibrarian.net/325943314/update-notifier_3.180_3.181.diff.gz [20:57] * juliank used the same setup apt uses, so he's hopeful it works out