[06:59] Richard Wilbur still active? [07:00] looks like it https://bugs.launchpad.net/bzr/+bug/1572314 [07:00] Launchpad bug 1572314 in Bazaar "--profile-imports crashes with relative imports in plugin" [Undecided,Incomplete] [07:01] Guess he's just not active where I was looking nor on IRC anymore, meh. Thanks. [07:06] FWIW, I've poked berry a couple time about bzr-fastimport fixes, poked the Debian maintainer, and understandably they want it fixed upstream/are pending on his review, which was done a year ago. [07:24] Good morning === michal_ is now known as Saviq === Saviq_ is now known as Saviq [08:35] pitti: Is the init-system-helpers upload in the xenial queue still relevant? The yakkety changelog makes it seem like perhaps it isn't? [08:36] infinity: it is, and it is still applied to yakkety too [08:37] pitti: Ahh, the xenial upload is the combination of all the yakkity uploads, then? [08:37] infinity: the thing we introduced and reverted in yakkety was a check for `runlevel` failing, but that was something else (and I never intended to SRU that) [08:38] infinity: yakkety had two fixes, one of which got reverted again in y, and the other (the important one) stayed and got SRUed [08:38] pitti: *nod* [08:38] pitti, can you maybe review/approve the gstreamer-vaapi update? you approved the rest of the gst stack but they need to go together or things get uninstallable (like currently vaapi needs to be removed if you want to try the 1.8.1 update) [08:38] infinity: are you doing SRUs? thanks (cloud folks are waiting for this fix) [08:39] seb128: ack, will do [08:39] danke [08:40] pitti: Minor nitpick. Given that the default RL in Debian (under sysv) has always been 2, it would seem that would be the better RL to "fake" there, not 5. Especially if it's later used to validate/call rc?.d/Sblah, where a local admin may have only bothered to add an rc2.d link. [08:40] infinity: hm, it's been 5 since vivid [08:40] pitti: Note I said "under sysv". [08:40] pitti: Yes, it's been 5 since the systemd switch. :) [08:40] infinity: but this check isn't actually used to determine whether a service is enabled, it just checks whether the corresponding symlink is broken [08:41] so it really doesn't matter that much [08:41] * infinity shrugs. [08:41] I can change it to 2 if you prefer [08:41] Don't really care deeply. I think this affected Debian more than Ubuntu, and would have mattered more if this was happening during the jessie release. [08:41] at some point I'll throw out that entire `runlevel` parsing thing under !sysv, it's completely irrelevant [08:41] By now, people are sort of upgraded to the new world order already. [08:43] Hi! $ grep ID_FOR_SEAT /lib/udev/rules.d/71-seat.rules [08:43] TAG=="seat", ENV{ID_FOR_SEAT}=="", ENV{ID_PATH_TAG}!="", ENV{ID_FOR_SEAT}="$env{SUBSYSTEM}-$env{ID_PATH_TAG}" [08:43] This rule makes my second GPU get ID_FOR_SEAT=drm-pci-0000_01_00_0, while the fbdev for the same GPU gets a different ID_FOR_SEAT=graphics-pci-0000_01_00_0 [08:43] I.e. drm belongs to a different seat than fbdev! Is that a bug that I should file against udev, or did I understand something wrong? [08:46] alkisg: I'm not familiar with that rule really; it would be great if you could file this at https://github.com/systemd/systemd/issues so that we can discuss it there with upstream? [08:48] pitti: thanks, I'll check if it originates from upstream and file it there [08:48] alkisg: it does [08:49] seb128: done [08:49] pitti, danke [08:52] could somebody on SRU shift look at network-manager? [08:52] there is a 7 days verified version in xenial-proposed [08:52] and a new cherry pick bugfix on top of that in the queue [08:53] that fixes wifi reconnect not working for quite some users and it's flagged by the oem team as something they need to see resolved [08:53] so would be nice to get it in proposed today if possible [08:53] either by copying the previous to update/accepting the new one [08:53] or just accepting it in top of the current one [08:56] happyaron: That network-manager patch needs to go to xenial too, I assume. [08:56] yes please! [08:56] happyaron: Err, yakkety. I just accepted it in xenial, but it needs to go to yakkety. :P [08:56] infinity: I commented on the openstack SRU diff, please don't accept it for now [08:56] happyaron: Pretty please. [08:56] (commented in the bug) [08:57] infinity: will do, :) [08:57] pitti: I'm not really processing the full queue, just cherry-picking here and there cause I can't sleep. Openstack wasn't on the list. ;) [08:57] infinity: heh, ok; I guess I can't talk you into reviewing systemd, as I can't review that myself? :-) [08:58] pitti: I just opened the diff to decide if I care. [08:58] + * Revert "enable TasksMax= for all services by default, and set it to 512". [08:58] pitti: Was that an upstream commit, or a Debian local thing? [08:59] pitti: FWIW, I agree wholeheartedly with reverting it. A system with only systemd-init and no fancy session management (ie: libpam-systemd) should, IMO, default to no limits. [08:59] infinity: it was committed upstream in version 228, and reverted downstream [09:00] infinity: upstream discussion is still ongoing, but people run into this with xenial so I'd like to SRU it now-ish [09:00] pitti: Right, we tried to "fix" it with making sure libpam-systemd is everywhere, but... [09:00] pitti: Wide open just feels like the right default, in the absense of fanciness. [09:01] infinity: that's one aspect, but things like mysql seem to run a gazillion threads even on moderate workloads, so 512 is not enough for them [09:01] arguably these shoudl specify their own resource limit over time, but not for 16.04 [09:04] pitti: They should specify a limit, sure, but the system limit still shouldn't be crap. [09:05] infinity: yes, agreed [09:05] infinity: I meant that it's still beneficial to add resource limits to units one by one, and then doing it properly [09:05] like also adding some file system protection, removing capabilities, and similar [09:09] pitti: Accepted. [09:10] cheers [09:10] pitti, hey, you being the resident systemd expert, I've a similar bug to #1438612 (and there are actually others reporting it in there as well) - I've nfsroot on one machine and network gets torn down too early, making anything trying to access rootfs hang - any pointers on what to collect to debug? [09:10] infinity, thanks for the nm review [09:10] bug #1438612 [09:10] bug 1438612 in dbus (Ubuntu) "remote file systems hang on shutdown, D-BUS stops too early" [High,Fix released] https://launchpad.net/bugs/1438612 [09:11] pitti, I've debug shell enabled, but by the time this issue happens I can't do anything since any access to / results in a hang [09:11] seb128: NP. Just make sure happyaron gets the same patch in yakkety too. :P [09:11] Saviq: nfs-root does not sound related to dbus stopping too early, this is almost surely a different bug [09:12] pitti, yeah I'm quite certain it has nothing to do with dbus, but the symptoms are similar [09:12] Saviq: things that are useful is your /etc/network/interfaces*, /etc/fstab, and a jouranl output which includes the shutdown bits [09:12] I suppose network is just taken down too early (with nfs-root, is it ever *not* too early)? [09:13] Saviq: which I realize is a bit tricky as the journal lives on NFS (or do you have a local /var?) [09:13] Saviq: right, network should not get stopped at all with root on NFS [09:13] Saviq: the initrd brings it up, and ifupdown should not touch it at all then [09:14] Saviq: does your /e/n/i refer to the net interface that NFS is on? [09:14] pitti: thanks, I filed it under https://github.com/systemd/systemd/issues/3243, hopefully it's a real issue and not some misunderstanding of mine [09:14] pitti, yeah, I do have dhcp on it, otherwise resolvconf and NM are messing with things - should I just drop NM and resolvconf and pop it from /e/n/i ? [09:14] pitti: Wow. I shouldn't have read that bug log. "I'm not sure if root on nfs was ever supported". And now I have more people to be grumpy with. :P [09:15] Saviq: err yes, you can't have ifupdown mess with the interface that NFS is on [09:16] Saviq: otherwise ifupdown will shut down the interface during shutdown if it's anything but "manual" [09:16] You should list it as manual to avoid NM touching it, probably. [09:16] Saviq: something like "iface eth0 manual" should hide it from NM? [09:16] Jinx. [09:17] pitti, right, it does mean a bit more manual config (resolv.conf) than I'd like, but oh well [09:18] Saviq: well, that's the bit where I said "you need half an OS in initrd" [09:18] which effectively makes the initrd your root fs :) [09:18] infinity: I'm *still* not sure whether we ever officially supported root on NFS :) [09:19] pitti: Well, Linux clearly does. Debian does. Ubuntu might? :P [09:19] our installer doesn't offer it, so my inclination was and would be "no" [09:19] and we don't have a test plan for it either, otherwise things like the above would have popped up much earlier [09:19] so it's well in the "you break it, you get to keep both halves" territory [09:20] infinity: same for Debian really [09:20] pitti: I wouldn't mind testing it more, only because it's a good test of boot/shutdown being otherwise sane. [09:20] people have a gazillion different configs, but that doesn't mean that it's reasonable to support the combinatorial explosion of them [09:21] pitti: The DHCP handoff bit seems to have bitrotted, though. I vaguely recall this working better. [09:21] i. e. we get bug reports here and there and fix some of them, but without putting some efforts into installer and CI this will just keep breaking [09:21] But, instead of poring over that, I think I'll go back to bed. [09:21] (don't get me wrong, I don't object to fixing things of course -- just that this has bitrotted more than once) [09:22] and without installer support, everyone will configure it differently wrong [09:22] pitti: Sure. That quote was from the upstream bug report, not from you. My complaint was people saying "well, Linux can't do that, because I'm 12 and I forget that people have been using computers in a certain way for the last two decades". :P [09:22] s/forget/don't know/ [09:23] Basically, I'm just a grumpy old man. [09:23] infinity: I think it actually was from me [09:24] pitti: Oh. In that case, nevermind. If the "we" in the sentence was "Ubuntu", I agree (except in the ltsp case, but I suspect it hasn't been tested thoroughly since the systemd switch). [09:24] Especially given Edubuntu not releasing this cycle. [09:25] infinity: nfs rw root has been working fine for ages, with "manual" in ifupdown [09:25] ltsp supported it until overlayfs broke nfs submounts [09:25] I *think* ltsp was the only place where we ever claimed to "support" nfs-root, any other attempt was best-effort. [09:25] right, I think ltsp sets up a "manual" stanza [09:25] and that's correct [09:25] it STFUs ifupdown and NM [09:25] alkisg: Yeah, manual should DTRT indeed. [09:25] Well, it'll do a thing. [09:25] I question if it's right. [09:25] But it sort of works. ;) [09:26] The right thing is more complicated, and maybe I never wrote it. [09:26] I thought I did, but I can find no evidence. [09:26] * infinity shrugs. [09:26] Saviq: so, if it still hangs with "manual", please let me know and file a bug with the journal, fstab, and /e/n/i [09:27] (Details: LTSP doesn't support rw NFS, only ro + aufs or overlayfs, it still works fine with systemd and aufs, but not with overlayfs. Unrelated to LTSP, NFS rw still works fine afaik) [09:27] pitti: When you and stgraber decide to tear out our network stack and jam a new one in, remind me that I sort of care about nfsroot, and maybe I can make it a bit more Just Works) [09:28] pitti: initramfs-tools is entirely missing the code I wrote in my head a few years ago, which implies that it stayed in my head, cause I'm a tool. :P [09:28] infinity: NM will stay as it is, so we'll have to keep hiding it from it (but we can move that blacklisting into some NM config) [09:28] infinity: networkd does not touch interfaces that are not explicitly configured, but neither does ifupdown, so that's the same [09:28] Dracut also supports nfs4 for nfs root afaik [09:29] i. e. we mostly need to teach people and installers to *not* create a network config for the thing that NFS is on [09:29] pitti: Right, NM needs blacklisting, but that's not the real concern, the real concern is that we should be transferring control from initrd to userspace (or, alternately, forwarding more config info), so manual configuration of any sort isn't needed. [09:29] We've been doing this wrong for ages, and it kinda works, but is fiddly. [09:29] * infinity shrugs. [09:30] yeah [09:30] infinity: my idea in some related bug report is that the boot interface is marked and saved somewhere in /run, and all the tools respect that automatically and never bring it down... [09:30] Saviq: how did that /e/n/i config for the ethernet interface get into your system anyway? did you add that manually? [09:30] Saviq: or was that some installer thing? [09:31] pitti, no, my doing [09:34] pitti, I added it so that resolvconf gets the DNS, but you're right I probably shouldn't have - not sure if resolvconf has a way to get it from when initrd asked dhcp [09:35] Saviq: no, you really shouldn't re-run dhclient on that interface, you might get a different IP and break NFS again [09:35] pitti, right, of course (well, it's a static lease in my case but you're still right) :) [09:35] Saviq: so I guess one takeaway from this is that the initrd's dhclient should haul the DNS/NTP information into userspace/resolvconf [09:35] I think that would make a fine request/bug report [09:36] and it shouldn't actually be that difficult, the initrd just needs to drop a file into /run/resolvconf/ ideally [09:36] pitti, ack - will file one [09:37] Saviq: against resolvconf or initramfs-tools, but I think the former [09:37] i-t should not really know about resolvconf, but then again its NFS hook might not be sufficiently extensible [09:37] well, we can reassign [09:37] initrd has `ipconfig`, not dhclient, by default [09:37] ack [09:38] It doesn't have the concept of leases [09:38] So, APT 1.2.12 is in yakkety now. If someone can lead me through what is needed to get that into xenial as a new upstream microrelease (I suppose it's appending some ~ubuntu something changelog entry), or wants to do it themselves (I can't upload anyway!), please do. [09:38] We should also upgrade yakkety to apt 1.3~exp1 from experimental [09:39] (probably) [09:39] juliank: If we'd done the latter, we wouldn't have to do the former. ;) [09:39] (ie: we could just sync 1.2.12 from unstable to xenial) [09:39] But, too late. [09:40] infinity: Yeah, next time. Both releases were uploaded the same time, and the auto sync catched the 1.2.12 release early on. I set up a PPA for future 1.2 releases at https://launchpad.net/~deity/+archive/ubuntu/apt-1.2 which will then see 1.2.13 and so on. [09:41] juliank: Anyhow, ideally what we want is a bug filed against apt/xenial with a changelog dump of changes between xenial and 1.2.12, a short explanation of why this is all sane and happy, and then a changelog entry for 1.2.12~ubuntu16.04.1 with "Backport 1.2.12 to xenial (LP: #1234)" [09:41] Launchpad bug 1234 in Launchpad itself "Gina is an unmaintainable mess of command line options, environment variables and shell scripts" [Medium,Fix released] https://launchpad.net/bugs/1234 [09:41] Ish. [09:41] ubottu: Oh, shut it. [09:41] infinity: I am only a bot, please don't think I'm intelligent :) [09:42] juliank: If future 1.2.x releases will be xenial-only, the LP: closure should just be in the upstream changelog, so we don't have to bother with the "backport" entry. [09:44] Well, I suppose even if they're not xenial-only. I do a lot of LP closures in Debian uploads too. [09:46] infinity: poke on bug 1571174 (please!) [09:46] bug 1571174 in squid3 (Ubuntu) "package squid3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [High,Triaged] https://launchpad.net/bugs/1571174 [09:47] sil2100, robru, infinity: how do we review https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=libhybris ? [09:47] rbasak: If you want a quick workaround, just SRU squid to Breaks: ufw (<< 0.35-0ubuntu2) [09:47] it was a sync from a landing PPA which already got repurposed and does not have the package any more [09:47] rbasak: I'm sitll pondering a more sane global solution. [09:47] so we don't have a .changes, a .diff, nor links to SRU bugs etc. [09:47] infinity: OK, I'll go and write a bug [09:47] pitti: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-029/+packages?field.name_filter=libhybris&field.status_filter=&field.series_filter= [09:48] infinity: ah, thanks; so no SRU bugs, you lose ? [09:48] or do we accept touch things without the SRU process? [09:48] pitti: I'd reject. [09:49] pitti: Both because of the lack of bugs, *and* the deleting the silo before it landed (which they're not meant to do). Both those things kinda imply they don't actually care about that SRU (or maybe it was unintentional). [09:49] not sure if we even build touch products out of xenial, or how that triple landing is supposed to work, but it doesn't seem to get along well with our normal stable process [09:49] infinity: ack [09:50] rejected [09:50] pitti: Touch is meant to move to Xenial any day now, but landing to xenial would follow the same SRU rules as anyone else, they don't get to be special. [09:51] pitti: Unfortunately, rejects from silos end up in an email blackhole, so you might want to poke Simon directly and tell him about it, though. :P [09:52] infinity: squid3/ufw> thanks, I'll go ahead and do that. [09:52] infinity: I assume we want an upload to Yakkety with the same Breaks first? [09:52] rbasak: No. [09:53] rbasak: It's unnecessary in yakkety, since we don't support upgrading to yakkety from << xenial. [09:53] Oh, because all upgrade paths togo through Xenial? [09:53] OK. [09:53] * rbasak ponders how to test this [09:53] morphis: hey! I rejected libhybris from the xenial SRU queue; the silo is already gone and the upload did not refer to any LP bugs (which we need for SRUs) [09:53] Can one get do-release-upgrader to use a PPA? [09:55] I guess I could just use dist-upgrade if it reproduces. [09:57] rbasak: Yeah, reproduces here. [09:58] apt-get install ufw squid && sed -i -e 's/wily/xenial/g' /etc/apt/sources.list && apt-get update && apt-get dist-upgrade [09:58] Obviously, starting with a clean wily schroot. [09:58] Yeah, trying it now. [09:58] * rbasak is using lxd [09:58] Potayto potahto. [09:59] schroot could do with a lxd backend incidentally. That's be nice. [09:59] And it exploded. Great! [10:01] infinity: Does this look sensible for the first part (without the Ubuntu changelog entry for now, this has yet to be generated...): https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1580952 [10:01] Launchpad bug 1580952 in apt (Ubuntu) "[SRU] Update apt/xenial to 1.2.12" [Undecided,New] [10:01] I'll pop a Breaks in dpkg too (which is actually where it belongs, but upgrade order isn't guaranteed here). [10:01] pitti: why was it pushed into the SRU queue? I thought all xenial uploads are going to the overlay ppa [10:01] sil2100: ^^ [10:01] morphis: We can't answer the why. [10:02] morphis: (Well, pitti and I can't) [10:02] morphis: ah, so it was misdirected after all; no idea why [10:02] pitti: yeah [10:02] was never meant to be SRU'ed [10:03] juliank: Looks quite sensible to me. [10:03] Mirv: ^ on that note, was https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=qtbase meant to be an SRU, or an overlay PPA upload? [10:04] morphis: So, on the one hand, I'm glad that was just a misfire we rejected. On the other hand, there was meant to be a point in time where the phone played more nicely with the distro and the overlay PPA stopgap could be used less and less (and eventually die). [10:04] morphis: That upload looked like it *could* have been suitable for an SRU, had a bug been attached to it. [10:07] pitti: it's meant for SRU, it has several xcb fixes [10:10] infinity: I should really request upload permissions for APT at some point... Needs some endorsements on https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU2 first (the 2 is there because of a wiki bug), though [10:11] (that are already in yakkety) [10:11] Mirv: thanks [10:14] doko, could you review for sanity? https://launchpadlibrarian.net/259134650/gcc-5.debdiff [10:14] did a test build in ppa:xnox/nonvirt, builds everywhere. [10:14] juliank: Uploaded. [10:15] pitti: If you're feeling reviewy, apt/xenial could use some love. Diff against yakkety is more obvious than diff against xenial, though both are useful. [10:17] infinity: ack [10:17] * infinity goes back to bed. [10:24] bdmurray: I'd like to join bug control so I can set importance and stuff on APT bugs (and other packages I maintain in Debian or develop) - I'd consider that the "If you are an upstream developer or bug triager for an upstream project contact Brian Murray" part of the wiki :D [10:25] xnox, looks good [10:25] I don't have a particular short list of bugs, though... [10:25] doko, ok. I want to upload that into security ppa, then publish into -proposed, then eventually migrate to -updates&-security [10:42] pitti: dpkg/xenial too, while you're at it, s'il vous plait. And now really bed. [10:45] infinity, juliank: bug 1562733 and bug 1562733 need an SRU test case; I figure the former is mostly to do some dist-upgrades and package installs, but some formal procedure is needed to verify this [10:45] bug 1562733 in apt (Ubuntu) "apt signature requierements prevent updates from some repositories" [High,In progress] https://launchpad.net/bugs/1562733 [10:46] pitti: That was the same paste twice. ;) [10:46] pitti: I don't really see that as closing 1562733, but just a comment in there that affects appstream [10:46] Otherwise I'd have closed the bug itself in the changelog [10:46] err, bug 1580952 [10:46] bug 1580952 in apt (Ubuntu Xenial) "[SRU] Update apt/xenial to 1.2.12" [Undecided,In progress] https://launchpad.net/bugs/1580952 [10:47] 1562733 is actually pretty clear [10:47] adding google talkplugin source already does that [10:48] pitti: 1580952 needs a test case? It's an MRE upload. The test case is "upload it and check the testsuite". [10:48] pitti: 1562733 is really more about allowing to fetch from such repositories, which I did not do; I just changed the hooks to also run if some repositories failed, but that's not really the main point of the bug. [10:48] And 1562733 isn't closed by this upload, unless I'm blind... [10:48] pitti: FWIW, there's a regression test case in the upload that runs on autopkgtest. [10:49] ah, good [10:49] Test case would be: Have a repository that you cannot fetch from due to errors -> Post-Invoke-Success scripts still run [10:49] hmm, why did sru-review open that bug then [10:49] AKA https://anonscm.debian.org/cgit/apt/apt.git/tree/test/integration/test-apt-update-hooks?id=35664152e47a1d4d712fd52e0f0a2dc8ed359d32 [10:51] pitti: Anyhow, I'll let you and juliank sort out if his bug is short on info. I think I'm finally tired enough to sleep. [10:51] infinity: You could syncpackage apt 1.3~exp1 to yakkety before you go to sleep [10:51] pitti: I guess I should update that squid/ufw bug with a test case too, so you don't reject my dpkg. :P [10:52] I didn't reject apt, I accepted it, but for testing it we still need to know *what* to test :) [10:56] pitti: Bug updated, bedifying. [10:56] infinity: sleep well! [11:04] infinity, pitti: "Should succeed if either squid or dpkg have been updated for the Breaks. [11:04] " - so do I still want the squid SRU? [11:04] I'm getting an even bigger explosion in testing the squid SRU Breaks BTW. [11:04] rbasak: I think probably. It's hard to guarantee that dpkg will be upgraded first. And, oh? [11:05] infinity: http://paste.ubuntu.com/16374154/ - haven't really looked at it yet. [11:05] This is with my proposed squid SRU, and without xenial-proposed I think. [11:06] rbasak: Gross. But not related to what you're doing, at least. [11:07] Oddly I wasn't getting this before though. [11:08] Well, you wouldn't have gotten that far before. [11:09] Hmm, OK. [11:13] I think I have a problem getting sponsor endorsments on https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU - almost everything I do is synced automatically, only sometimes do I have to manually request a sync. [11:16] juliank: I'm happy to endorse. Ask me again tomorrow when I'm not pretending to sleep, though. [11:16] so much for "really sleep" :) [11:17] infinity: looks like a lxd/systemd interaction. The service is failed on a xenial instance, too. [11:17] pitti: I'M SLEEPING SO HARD. [11:17] ZZZZZZ [11:17] * rbasak tests harder, as infinity would say. === hikiko is now known as hikiko|ln === _salem is now known as salem_ [11:48] chrisccoulson, hey, do you know how firefox determine what handler to use to open files? [11:48] I'm trying to figure out why it tries to open launchpad .tar.xz with gedit [11:49] the dialog sttes that it's of type "archive XZ" so it seems to get that right? [11:49] I don't see a Content-Type info if I capture packets using wireshark [11:49] though I wonder if that could be bug #645924 [11:49] bug 645924 in Launchpad itself ".tar.xz files are served with text/plain content-type by launchpadlibrarian" [Low,Triaged] https://launchpad.net/bugs/645924 [11:50] but the firefox dialog states the type is "archive XZ" so it somewhat knows the type === hikiko|ln is now known as hikiko [12:18] rbasak: Confirmed that the dpkg fix worked for me. But I can't guarantee that dpkg will always configure before squid3, so fixing both won't hurt. [12:24] infinity: ack === freyes__ is now known as freyes [13:03] cyphermox: cjwatson: do you think there's a solution possible at some point in the future for bug #1530530 ? comment #13 has the useful information of SeaBIOS reusing existing framebuffer. removing gfxboot from Ubuntu image makes it possible to boot & install Ubuntu. [13:03] bug 1530530 in gfxboot-theme-ubuntu (Ubuntu) "Installer doesn't show up on some Chromebook" [Medium,Confirmed] https://launchpad.net/bugs/1530530 [13:03] Mirv: sorry, not me [13:03] cjwatson: no problem [13:08] infinity, hi [13:12] not sure if anyone is familiar with gfxboot initialization code [13:27] Mirv: pretty sure that system should be booting EFI, not BIOS. [13:28] cyphermox: I think by design it's not possible to boot other than via the SeaBIOS payload currently. there's no EFI, only coreboot. [13:29] I thought all chromes enforced and used EFI [13:30] anyway, it's definitely possible to look through the gallium gfxboot code and see if there's anything we can steal from it [13:30] well where it's possible to choose the boot option, that's before EFI. and there one can select the legacy boot option where it's possible to install SeaBIOS. other parts of the flash are more proteced. but I'm no expert. [13:30] oh, if galliumos is using gfxboot, they'd definitely have some trick probably then [13:30] but I can't exactly say I know very well how it all works. gfxboot is the kind of thing you want to tiptoe around very carefully [13:31] cyphermox: do you know if it's easy to what unetbootin used to do, ie remove gfxboot from existing image and add dummy boot option instead? I could write a wiki page about modifying ubuntu image to boot without gfxboot. [13:31] I have no idea what it does [13:32] ok. it has a text menu that works, it's just unetbootin has bitrotted enough not to handle newer images. [13:33] I would usually recommend people don't modify the images, that's easy to get wrong too especially if you're playing in the syslinux code. I guess it just runs syslinux with fewer options maybe? [13:33] it sounds like according to bug #1530530 that gallium uses grub instead [13:33] bug 1530530 in gfxboot-theme-ubuntu (Ubuntu) "Installer doesn't show up on some Chromebook" [Medium,Confirmed] https://launchpad.net/bugs/1530530 [13:33] pitti: I just uploaded the squid3 half of the SRU in bug 1571174 if you don't mind reviewing please. [13:33] bug 1571174 in squid3 (Ubuntu Xenial) "package squid3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [High,In progress] https://launchpad.net/bugs/1571174 [13:34] Mirv: ok [13:36] trevinho: do you have time to look at my new compiz merge proposals? [13:36] Mirv: I don't know if we have gfxboot just for the prettiness or if it's because it works better on some systems. If it's just for the prettiness, we can maybe look into using grub everywhere, I have been playing with the grub graphical menu a few weeks ago [13:37] muktupavels: ok [13:39] cyphermox: I agree it's a change that's hard to validate to be bullet proof, although great that we've just done an LTS... grub everywhere could make sense but only if the graphical mode does not bring problems that can't be fixed with some fallback === JanC is now known as Guest15251 === JanC_ is now known as JanC [13:54] cjwatson: do you recall if there is another immediate impact of replacing gfxboot with grub, or if it's just that gfxboot is shiny and was there first? [13:55] not that I'd really want to change this just for the sake of change [13:56] cyphermox: it's just that we never worked out how to replace the interface [13:56] ok, thanks [13:56] it was always something we wanted to do, just hard work [13:56] Mirv: ah, indeed this would mean no keyboard/language selection at boot [13:57] yeah [14:08] cyphermox: right, similar to how we don't have that selection in EFI mode already [14:10] cyphermox: ubiquity does have language selection on bootup if one doesn't enter the gfxboot menu to select it. EFI/grub mode doesn't currently have a default that would boot into that graphical language selection / live-or-install. [14:11] it could all use some more coherence, like always booting to the ubiquity language / mode selection menu. [14:11] now bios gfxboot vs efi grub boot experiences are quite far from each other [14:32] question, should we still disable dns caching in dnsmasq by default (for NetworkManager)? [14:35] happyaron: the privacy issue on multiuser systems remains, so yes [14:35] hi folks, anyone here around? I’ve discovered that some non-upstream (Ubuntu/debian-specific)patches to Xorg cause it to segfault on start-up on Book-E PowerPC64 (big endian) machines. Simply commenting out most of the patches that do not apply to non-x86_64 machines seems to resolve the problem. [14:36] I’d like to know how to file this ticket such that it gets fixed in the next point release of Xenial [14:36] MrBIOS: https://help.ubuntu.com/community/ReportingBugs [14:37] yes, I know *how* to file bugs [14:37] but not how to get them actually acted on by someone within the Ubuntu Xorg server team, who actually gives a shit [14:37] MrBIOS: beyond filing the bug, there's no way to expedite it in rapid motion [14:38] mdeslaur: so the only way for enabling dns caching is to have something like per-user dnsmasq? [14:38] MrBIOS: as teward said. Once you've filed the bug, you can paste it in #ubuntu-x and see if someone bites. [14:38] happyaron: per-user dnsmasq, or dnsmasq gains per-user caching, yes [14:39] ic [14:39] MrBIOS: but in supplement to what mdeslaur said, there's no guarantee someone'll bite and rapid-expedite it to the top of the list of things needing fixed by point release [14:39] happyaron: I believe there's a plan underway to replace dnsmasq with systemd [14:39] happyaron: but I don't know the details === marcusto_ is now known as marcustomlinson_ [14:39] ok [14:40] bdmurray: Thanks! [14:40] well, if “Xorg crashes, and I know how to fix it” isn’t something y’all care about, good luck with your distro :)0 [14:40] MrBIOS: if you have a fix, you can subscribe ubuntu-sponsors to your bug and get it sponsored === marcustomlinson_ is now known as marcustomlinson [14:47] pitti: yes if there's a train item in the upload queue but the silo has been deleted, please just reject with extreme prejudice. 99% of the time the silo was misconfigured as an SRU, published, reconfigured to point at overlay PPA and republished / merged / deleted. [14:47] mdeslaur: the “fix” is to simply not apply some patches that are N/A to PowerPC, when xorg-server is built. [14:52] juliank: no problem [14:53] happyaron: I don't know that you should waste too much time on NM+dnsmasq, we might want to instead revisit whether we still want to use dnsmasq as the local caching server, and it's quite possible that we don't; and quite possible that we'd want to use systemd-resolved instead [14:55] cyphermox: yeah I've refreshed the patch and continued the merge, ty! [14:56] what merge? [14:56] AFAIK NM is at 1.2 for both xenial-proposed and yakkety, that should be good for now [14:56] bdmurray: Do you happen to remember enough interactions from last year (python-apt IIRC) to add something nice to https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU? [14:56] tjaalton: ^- perhaps you could sort MrBIOS's issue out? [14:57] cyphermox: 1.2.2 for yakkety, a trival one [14:57] cjwatson: tjaalton, I just filed https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1581076 [14:57] Launchpad bug 1581076 in xorg (Ubuntu) "Xorg segfaults on start-up on Big Endian PPC hardware" [Undecided,New] [14:57] ah, there we go, thanks bot [14:57] cyphermox: but need some time for me as there are background/historical issues I need to read through [14:58] MrBIOS: so I know nothing much about X myself, but it strikes me that you have an obvious target for bisection here if you wanted to make it quicker for the relevant developer [14:59] cjwatson: yeah, I have it narrowed down to one of ~19 small, non-upstreamed patches [14:59] right, so that would be at worst five builds to determine exactly which one [15:00] at which point I think you're a lot more likely to get somebody to bite [15:01] it's not clear why e.g. "190_cache-xkbcomp_output_for_fast_start_up.patch" shouldn't apply to powerpc for instance, so this isn't just a pile of obviously x86-specific patches [15:01] yes, some of them can likely be safely applied [15:04] 190 is disabled because it broke [15:05] MrBIOS: you need to narrow it down to whatever breaks it for you [15:07] heh, I love how 227_null_ptr_midispcur.patch has been “waiting for review from upstream” since 2009 [15:07] yeah [15:07] last comment on https://bugs.freedesktop.org/show_bug.cgi?id=24181 was over three years ago [15:07] Freedesktop bug 24181 in Server/General "Reproducible segfault in miPointerUpdateSprite()" [Major,New] [15:12] MrBIOS: maybe try without just 188 [15:14] tjaalton: building [15:14] The next nginx upload which is a merge from Debian is going to be introducing 9 additional binary packages, which are dynamically-built modules and are not static-compiled into the nginx flavors. nginx-core, a binary we created to include in Main, includes 5 of the 9 binaries as dependencies, in order to provide those modules as part of the core feature set (none of those are third party modules). [15:14] also, for things like 08_xfree86_fix_ia64_inx_outx.diff, why should that even be applied at all? [15:14] Where my confusion now is, is Main / Universe for those 9 new binaries [15:14] there is no IA64 Ubuntu flavor, is there? [15:15] there used to be [15:15] teward: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.xenial/view/head:/supported-misc-servers [15:15] as a result of the 5 being install-depends for nginx-core, do those 5 dynamic module binary packages need to be in Main? [15:15] teward: nginx is in there [15:15] rbasak: ack [15:15] MrBIOS: it's not applied as you can see from the series file.. [15:16] teward: the 5 will appear in component mismatches if nginx-core depends on them I think. [15:16] yep just realized that, it actually fails to apply if you try to apply it, probably should just be removed completely. [15:16] rbasak: that's what I thought, then those 5 would then need Main inclusion I presume? [15:16] (assuming nginx depends on nginx-core). [15:16] MrBIOS: it comes from debian [15:16] sufficient codebase drift since it was written [15:16] tjaalton: yes I understand [15:16] teward: right. Assuming the existing approved nginx MIR still applies, an archive admin should just move them over. [15:16] it can come from Debian and still be totally broken, those two things are not mutually exclusive :P [15:17] rbasak: nginx metapackage depends on the following in this order: nginx-core OR nginx-full OR nginx-light OR nginx-extras [15:17] rbasak: which has been the case since the initial MIR which put nginx-core in Main [15:17] rbasak: the rest of the flavors are in Universe [15:17] teward: OK, that should be fine then. [15:17] rbasak: that's what I thought, I'm still finishing up getting a Yakkety system in place to test upgrading, installation, etc. [15:18] so nothing's been uploaded yet [15:22] MrBIOS: dropped it from git === MrBIOS_ is now known as MrBIOS [18:36] bdmurray: i got an email that fwupd upload might have caused regressions but I can't access anything about what happened. do these get turned into launchpad bugs? [18:37] given the nature of the upload that was made i highly doubt they were bugs caused by that upload, but likely existing issues that were just uncovered as people updated [18:39] superm1: Oh, you don't have access to crashes at the Error Tracker? that might be useful. Regardless those crashes are not regressions, I'll get it sorted out. [18:40] i used to have access a long time ago, but it looks a lot different now than when i remember accessing it last [18:40] so things have probably changed === mnepton is now known as mneptok [20:20] bdmurray: thanks for adding me. could those crash reports be accessed somehow? will the retracer run on them? i'm guessing this is related to some USB device plugged into the system crashing the DFU provider but the crash reports appear to not be showing up. [20:37] superm1: they were just package install failures, not crashes per se [20:37] bdmurray: oh but i saw .crash files listed in their crash reports list [20:38] but i guess that's what these were? [20:38] superm1: everything has a .crash extension ProblemType distinguishes the type of crash / error [20:39] bdmurray: oh. so https://errors.ubuntu.com/oops/d55f4d9c-1868-11e6-b85f-fa163e8d4bab having 3 files really doesn't tell me anything than those 3 were being configured when there was a failure [20:40] superm1: the Error Tracker isn't really well suited for package install failures yet [20:40] ah darn [20:41] it looks like this is probably a firefox postinst problem, but would be nice to know for usre [20:42] package install failures like this still go to Launchpad even for stable releases [20:45]