[00:30] <b4r> hi
[00:31] <b4r> W: Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1.bin for module i915
[00:31] <b4r> is there a reason why kernel 4.7 is missing this module?
[00:31] <b4r> I'm stuck on 4.6 because all the RCs and latest don't have the i915 module
[00:34] <RAOF> I presume you're using the (unsupported ☺) kernel-team mainline build PPAish?
[00:35] <b4r> ok yes but why's the module removed? D:
[00:45] <b4r> RAOF: so unsupported means I don't get to ask questions, period?
[00:45] <RAOF> Oh, no.
[00:45] <RAOF> Just to calibrate your expectations :)
[00:46] <RAOF> That's not a module, either; it's some firmware data.
[00:46] <b4r> at any rate I'll just take the config from the kernel and add support for myself
[00:46] <b4r> just... unexpected :P since for kernels 4.6 and below it's been functioning just fine afaik
[00:46] <RAOF> The likely reason is that we ship firmware in a different package; linux-firmware, and if that's a new file the packaging may need to be updated to include it.
[00:47] <RAOF> Also: does that warning correspond to a problem you have? Because it's likely that the reason why 4.7 warns about it is that kernels prior to 4.7 didn't support that particular bit of thing.
[00:48] <b4r> well after booting grub and selecting the kernel plymouth or something has a problem displaying graphics
[00:48] <b4r> on my particular machine, actually what happened when I noticed the problem is I had ubuntu on a macbook and took the hdd from the macbook to a pc and the pc wouldn't display graphics
[00:49] <b4r> came to realize it was due to the i915 support removal
[00:50] <RAOF> Unless you've got a Kaby Lake Intel chip (which I think is as-yet unreleased?) that's not your problem.
[00:51] <b4r> Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
[00:51] <RAOF> Yeah, this is very definitely not your problem.
[00:51] <b4r> oh ok
[00:53] <RAOF> Again, that warning is telling you that some firmware file that the i915 module *might* look for is missing; the filename strongly suggests that it's firmware for some part of Kaby Lake, the codename for the Skylake successor which apparently started shipping to OEMs a couple of days ago.
[00:53] <b4r> dunno, I vaguely recall needed this particular thing (i915) support years ago when I was using gentoo and compiled kernels for this machine
[00:54] <RAOF> Oh, yes.
[00:54] <RAOF> You need the i915 kernel module.
[00:54] <RAOF> But you've *got* the i915 kernel module.
[00:54] <b4r> but why again cause that's where I'm lost
[00:54] <b4r> you mean the package?
[00:54] <b4r> I mean yes, it's installed
[00:55] <RAOF> The kernel you have installed has i915.ko - that's why update-initramfs can notice that you're missing a piece of firmware it may try to load (but won't on your system).
[00:55] <RAOF> It seems like you may have run into a kernel bug for old Intel graphics introduced in 4.7?
[00:56] <b4r> sweet, where do I claim my prize :3
[00:56] <b4r> I rarely find bugs, this is one of those times
[01:02] <RAOF> First check out bugs.freedesktop.org; see if someone else has already run into it :)
[01:31] <infinity> xnox: I'm not aware of anything doing so.
[05:21] <pitti> xnox: that rings a bell; smb reported the same problem a while ago, trying to remember/find the report
[05:21] <pitti> Good morning
[05:21] <pitti> xnox, infinity: ah! bug 1543025
[05:21] <ubottu> bug 1543025 in cloud-init "Wrong UTC zoneinfo in cloud-images" [High,Triaged] https://launchpad.net/bugs/1543025
[05:38] <tyhicks> pitti: I may be able to work on the apparmor merge from debian - can you remind me what it is that'll be blocking you if it isn't merged soon?
[05:39] <pitti> tyhicks: adding a native unit for it
[05:41] <tyhicks> pitti: ok, I'm working on a yakkety apparmor upload and will take a look at doing the merge, too
[05:41] <pitti> tyhicks: thanks, appreciated; this should hopefully reduce most of the delta
=== dpm is now known as dpm-afk
[05:59] <cpaelzer> good morning!
[06:01] <pitti> hey cpaelzer, wie gehts?
[06:12] <cpaelzer> pitti: gut, Umzug gemeistert und es ist keinem zu sehr aufgefallen
[06:15] <cpaelzer> pitti: Und irgendwie ist klassischer Montag - Ich brauch gefühlt Stunden um der Mails Herr zu werden :-)
[06:19] <pitti> cpaelzer: oh great -- moving on such a warm weekend doesn't sound like fun
[06:22] <cpaelzer> pitti: good planning and half a year of prework made it a swift move - excluded the half hour where showers tried to make it less successful :-)
=== dpm-afk is now known as dpm
[07:09] <smb> pitti, that tz file wrong was a result of cloud-init doing somethign
[07:11] <smb> cpaelzer, for a second I was wondering what went wrong with *the* shower but then realized it was raining :) morning
[07:11] <cpaelzer> smb: lol
[07:12] <cpaelzer> sorry still in Germen-English mode
[07:12] <cpaelzer> but most of those already awake will get it - to fill in for everyone rain-shower :-)
[10:39] <pitti> smoser, rharper, lool: https://launchpad.net/~pitti/+archive/ubuntu/ppa has first netplan packages now; I guess for MaaS/cloud-init integration you want it in Ubuntu proper?
[10:40] <pitti> ... except for a funny FTBFS, investigating
=== hikiko is now known as hikiko|ln
[11:10] <pitti> smoser, rharper, lool: ok, built now
[11:13] <doko> xnox, https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1603436 is this fixed in cassandra ?
[11:13] <ubottu> Launchpad bug 1603436 in python2.7 (Ubuntu Yakkety) "Regression in python2.7 SRU breaks python-cassandra" [High,Confirmed]
=== dpm is now known as dpm-lunch
[11:19] <xnox> doko, yakkety not-affected, test-building xenial package will throw it into the SRU queue in a second.
=== hikiko|ln is now known as hikiko
[12:02] <flexiondotorg> Afternoon.
[12:02] <flexiondotorg> mate-hud has been sitting in the NEW queue for a couple of weeks.
[12:03] <flexiondotorg> Any chance that can get promoted? We'd like to land it for 16.10 Alpha 2.
[12:03] <flexiondotorg> Actually, mate-hud is in the upload queue.
[12:04] <pitti> I'll have a look
[12:06] <flexiondotorg> pitti, ty
[12:06] <pitti> flexiondotorg: etc/X11/Xsession.d/99mate-hud → why such an uber-high prefix?
[12:08] <flexiondotorg> pitti, To ensure it follows 99mate-environment in the ubuntu-mate-default-settings package.
[12:08] <flexiondotorg> If those are too high, first comment I've had on that, I can change both.
[12:08] <flexiondotorg> But you it be possible to do that after Alpha 2?
[12:08] <pitti> well, it's just getting a little thin to squeeze anything in between that and 99upstart
[12:09] <pitti> most of these should come much earlier
[12:09] <flexiondotorg> In that, I am short on time. But can commit to changing both next week.
[12:09] <pitti> not a rejection argument, but changing existing conffiles is always a bit awkward
[12:09] <pitti> it just jumped my eye
[12:09] <pitti> flexiondotorg: well, the whole Xsession.d/ will go away at some point anyway :)
[12:10] <pitti> (not being used with upstart/systemd or Mir/Wayland)
[12:11] <flexiondotorg> pitti, Yep. I'm aware Xsession.d will go away. I've done my home homework on that.
[12:11] <Laney> 99upstart~mate-hud
[12:11] <flexiondotorg> I thik I'm ready to switch as the appropriate time.
[12:12] <pitti> flexiondotorg: LGTM otherwise, accepted
[12:12] <flexiondotorg> pitti, Thanks.
[12:12] <flexiondotorg> I've noted yours and Laney comments in our Trello. Will revisit that high prefixes.
=== _salem is now known as salem_
=== dpm-lunch is now known as dpm
[12:47] <ginggs> hi, can someone please tell me if there is anything more to be done for boost 1.60 transition? http://people.canonical.com/~ubuntu-archive/transitions/html/html/boost1.60.html ; supercollider seems to have built everywhere (despite what ben says), net-cpp FTBFS on armhf only
[12:52] <cyphermox> good morning!
[12:59] <ogra_> cyphermox, hey married man !
[12:59] <ogra_> (congrats etc ... )
[13:05] <cyphermox> hey ogra :)
[13:28] <pitti> heey cyphermox
[13:28] <pitti> cyphermox: how are you? had some nice honeymoon?
[13:29] <cyphermox> yup
[13:29] <seb128> oh, cyphermox got married?
[13:29] <Mirv> the sped up armhf builders are the best thing since sliced bread
[13:29] <cyphermox> doing well, just got through the mound of email
[13:29] <seb128> cyphermox, congrats ;-)
[13:29] <Mirv> oh wow, congrats cyphermox!
=== mterry_ is now known as mterry
[13:36] <cjwatson> Mirv: \o/
[13:36] <cjwatson> wow, epic queue though
[13:37] <cjwatson> I guess LP's queue estimates may still be based on older builders mind you
[13:54] <pitti> cjwatson: at some point I'd like to move https://git.launchpad.net/~ubuntu-desktop/+git/systemd-graphical-session/commit/?id=402f7b73 (a staging project) into the openssh-client package itself
[13:54] <pitti> cjwatson: however, this is still a bit in flux, it's not 100% guaranteed yet that it won't change again
[13:54] <pitti> cjwatson: would you prefer that I upload this to ubuntu for now, and I'll submit it to Debian and we re-sync once the dust settles? or do you want it in the debian git right away?
[13:55] <cjwatson> pitti: Would there be any compatibility concerns with having it in Debian?
[13:55] <pitti> cjwatson: it's the systemd counterpart of /usr/share/upstart/sessions/ssh-agent.conf; however, I took the liberty of not using -s but running it in the foreground and using XDG_RUNTIME_DIR instead of /tmp/, for better debuggability and easier restarts
[13:56] <cjwatson> pitti: (Also, I'd really prefer that to be an external script rather than a giant Exec...)
[13:57] <pitti> cjwatson: no, this only applies to graphical sessions which get started via (user) systemd, i. e. zero in Debian right now
[13:57] <cjwatson> pitti: Why do we need the "manual" override?  Presumably you're either using systemd as the session init, in which case this new service would be used, or upstart as the session init, in which case the old job would be ignored, not some mix of both?
[13:57] <pitti> cjwatson: i. e. similar to the upstart job -- these are both just dead weight in debian now
[13:57] <cjwatson> pitti: If we can have it in Debian without causing compat issues, I would rather take that road
[13:58] <pitti> cjwatson: when using sytsemd, we add /usr/share/upstart/systemd-session/ to the XDG config dirs, so that we can replace one upstart job after another step by step without having to do a giant lockstep transition
[13:58] <cjwatson> Oh, right, I see
[13:58] <pitti> cjwatson: so for every job that we port, we add an override for it so that we don't run both the upstart job and the unit
[13:59] <pitti> cjwatson: after we ported everything, we can then drop the upstart jobs and overrides of course; but TBH I'd keep it for a few months so that you can switch back and forth for debugging and in caes of regressions
[13:59] <cjwatson> Sure
[13:59] <pitti> cjwatson: ok, then I'll send a git format-patch against the debian packaging vcs to a debian bug at some point?
[14:00] <cjwatson> pitti: The initctl commands might want a bit more of a guard to avoid stderr noise if initctl doesn't exist at all
[14:00] <cjwatson> pitti: Yes please
[14:00] <pitti> cjwatson: right, should rather use [ -x ] for those
[14:00] <pitti> cjwatson: so you prefer breaking this out into an external shell script? ok (I thought 5 lines is some kinf of aesthetical limit)
[14:00] <cjwatson> my preferred idiom is "if which initctl >/dev/null 2>&1" to avoid path hardcoding, but whatever
[14:01] <pitti> *nod*
[14:01] <cjwatson> pitti: it's maybe just on the edge, but I prefer not having to deal with quoting issues
[14:01] <cjwatson> or even think about them :)
[14:01] <pitti> ack, I'll clean it up
[14:01] <cjwatson> like, I don't know the precise lexical rules for multi-line systemd unit directives OTTOMH
[14:03] <cjwatson> pitti: we have a few other things in /usr/lib/openssh/ for this kind of thing
[14:03] <pitti> I'll put it there
[14:09] <Mirv> pitti: could you override http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtcreator - src:qtcreator-plugin-ubuntu is being removed and there is a transitional binary package of a newer version in that qtcreator upload
[14:10] <pitti> Mirv: hmm, why doesn't that transitional package work then?
[14:10] <pitti> apparently this makes ubuntu-sdk uninstallable
[14:11] <Mirv> pitti: it does work butthat qtcreator-plugin-ubuntu autopkgtest is from the to-be-removed src? ubuntu-sdk is also likewise being removed in that ubuntu-touch-meta
[14:11] <Mirv> bug #1604744
[14:11] <ubottu> bug 1604744 in ubuntu-touch-meta (Ubuntu Xenial) "RM: src:qtcreator-plugin-ubuntu - SDK will be distributed separately" [Undecided,New] https://launchpad.net/bugs/1604744
[14:12] <pitti> so why wouldn't we remove qtcreator-plugin-ubuntu instead?
[14:12] <Mirv> new qtcreator conflicts with qtc-p-u and ubuntu-sdk
[14:12] <Mirv> pitti: well yes that's what the bug is about, removing src:qtcreator-plugin-ubuntu, but it hasn't been done yet
[14:12] <pitti> Mirv: I can do it now if you want
[14:12] <Mirv> pitti: ok, that would be nice
[14:16] <pitti> Mirv: removed qtcreator-plugin-ubuntu qtcreator-plugin-go
[14:16] <pitti> Mirv: the ubuntu-sdk binaries will become NBS after ubuntu-touch-meta lands, I'll remove them then
[14:17] <Mirv> pitti: thank you. yes, only the ubuntu-sdk-libs stays in ubuntu-touch-meta since it has other purposes
[14:17] <pitti> Mirv: I'll watch it and nudge it later if necessary, but removing the source should suffice
[14:34] <semiosis> infinity: good morning.  if you have a chance to look over bug 1605795 today I would appreciate any feedback.  it's my first SRU and I'd like to get it into shape for your team.  thanks!
[14:34] <ubottu> bug 1605795 in livecd-rootfs (Ubuntu) "[SRU] livecd-rootfs ubuntu-cpc vagrant image builder" [Undecided,New] https://launchpad.net/bugs/1605795
[14:38] <pitti> cjwatson: https://git.launchpad.net/~ubuntu-desktop/+git/systemd-graphical-session/commit/?id=289952  and we can use the same helper in the upstart job to avoid repeating the logic
[14:39] <cjwatson> pitti: looks plausible at a brief glance at least
[14:40] <pitti> cjwatson: I think I incorporated all your suggestions; thanks for the initial review!
[14:40]  * pitti re-tests with upstart and changing that .conf to use the helper
[15:26] <pitti> Mirv: ah, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtcreator landed now
[15:26] <pitti> Mirv: touch-meta too
[15:28] <Mirv> pitti: excellent, thank you
[15:30] <pitti> cjwatson: patches sent to Debian bug #832445 now, and tested with all four scenarios (keyring-ssh or ssh-agent, upstart or systemd)
[15:30] <ubottu> Debian bug 832445 in openssh-client "openssh: Rework upstart ssh-agent job and add systemd user unit" [Wishlist,Open] http://bugs.debian.org/832445
[15:42] <cjwatson> thanks
[15:57] <infinity> xnox:
[15:57] <infinity> Setting up s390-tools (1.34.0-0ubuntu8.2) ...
[15:57] <infinity> rmdir: failed to remove '/3770': No such file or directory
[15:57] <infinity> xnox: ^-- WAT?
[15:57] <pitti> isn't that 31337?
[15:58] <pitti> Mirv: ah, cleanup time! http://people.canonical.com/~ubuntu-archive/nbs.html
[15:58] <xnox> infinity, there is maintainer script to cleanup bogus /3770
[15:58] <pitti> Mirv: (removed)
[15:58] <xnox> infinity, i guess the maintainer script is bogus too.
[15:58] <infinity> xnox: I've heard good things about /dev/null
[15:59] <infinity> xnox: Especially since, due to the version comparison, that'll run on every s390-tools upgrade in xenial. :P
[16:00] <xnox> infinity, fail
[16:01] <xnox> infinity, i guess i should change that to lt-nl 1.34.0-0ubuntu8.1
[16:01] <infinity> xnox: And redirect the scary to /dev/null, yeah.
[16:02]  * infinity blames whoever reviewed your SRU.
[16:02]  * infinity hopes it wasn't him.
[16:03] <infinity> Oh, good.  It was Brian. ;)
=== andrewsh is now known as afk
=== afk is now known as andrewsh
=== gshereme is now known as gshereme|away
[16:19] <Mirv> pitti: thank you!
[16:35] <smoser> hey.
[16:36] <smoser> looking for input. i'm putting together a way to modify sources.list in ubuntu via cloud-init and curtin.
[16:37] <smoser> we use the word 'pockets' in ubuntu, but sources.list(5) uses the word 'Sources'.
[16:37] <smoser> are they 100% equivalent terms?  and if so, should i prefer the "official" word 'suites'
[16:37] <smoser> bay.... s/Sources/suites/
[16:41] <rbasak> I see suite as "series + pocket". I don't know if that is technically correct though.
[16:43] <rbasak> And sources.list(5)'s use of "source" seems to mean "url + suite + components".
[16:43] <rbasak> So I think all the terms mean different things.
[16:43] <smoser> right. i used 'Source' completely wrong there.
[16:43] <smoser> (see my s/Sources/suites/)
[16:44] <rbasak> Ah
[16:44] <smoser> it does seem more technically correct to use the word 'suite'
[16:45] <rbasak> For your purposes I'd use "suite", since that matches apt's documentation.
[16:45] <rbasak> And because it maps to a sources.list which you are generating.
[17:32] <infinity> smoser: As rbasak says, "suite" is "series-pocket".  The "pocket" nomenclature is meaningless outside the launchpad context, from the POV of an apt mirror, suites are distinct things.
[17:32] <smoser> right
=== salem_ is now known as _salem
=== _salem is now known as salem_
[18:49] <semiosis> infinity: hi again.  did you see my message from earlier this morning?  figured I'd address it to you since you're aware of the underlying bug/patch, and you're listed as the SRU vanguard for Monday (this is in re: bug 1605795)  thanks again!
[18:49] <ubottu> bug 1605795 in livecd-rootfs (Ubuntu) "[SRU] livecd-rootfs ubuntu-cpc vagrant image builder" [Undecided,New] https://launchpad.net/bugs/1605795
[18:50] <infinity> semiosis: Yeah, I've looked.  Someone should upload the SRU to the queue.
[18:51] <semiosis> infinity: ok great.  is there anything else I should do at this time?
[18:51] <infinity> semiosis: Find a sponsor to upload for you?
[18:52] <infinity> semiosis: I guess I could be that sponsor, but then I probably shouldn't also be the queue reviewer. :P
[18:54] <infinity> Odd_Bloke: Should https://bugs.launchpad.net/cloud-images/+bug/1581044 be fixed in xenial as well?
[18:54] <ubottu> Launchpad bug 1581044 in cloud-images "Images ship with modified conffiles" [Undecided,Fix committed]
[18:55] <infinity> Odd_Bloke: Possibly the sources.list fixups as well.
[18:56] <semiosis> infinity: Odd_Bloke asked me to open the SRU, so I think he's for it :) https://irclogs.ubuntu.com/2016/07/22/%23ubuntu-devel.html#t15:21
[18:56] <infinity> semiosis: Different bug. :)
[18:56] <semiosis> ah that's a different bug. so you're asking about increasing the scope.
[18:56] <semiosis> right
[18:57] <infinity> semiosis: I'm suggesting that CPC has been slack on backporting fixes to xenial in general, and if we're doing a cloudy SRU of livecd-rootfs, we may as well roll them all in. :P
[18:57] <semiosis> infinity: that sounds good to me if it doesn't take an eternity :)
[18:58] <semiosis> but then again idk if one big SRU is easier to get through than several small SRUs, so whatever you think is best
[18:58] <infinity> semiosis: The rcS and sources.list fixes would be trivial to test/validate, but I also understand the relative urgency of the vagrant thing, given the bad press (well, "press", social media anger, I guess) surrounding their breakage.
[18:59] <infinity> semiosis: But one big one with a few easy-to-validate bugs is usually preferable, it's when you have two+ big changes to make that doing them together can be painful.
[19:00] <infinity> semiosis: Anyhow, I'll see if I can get a yay/nay from Odd_Bloke, and then maybe do the backports myself, since he's off frolicking^Wworking in .nl.
[19:02] <semiosis> infinity: thank you.  should i try finding someone else to sponsor/review my SRU now?  i'm thinking maybe rbasak or slangasek
[19:02] <infinity> semiosis: Weeeeeell, I'm likely to do the backports from trunk to xenial, so once I've done that, I may as well upload.  I'll just nag someone else to do the queue review once I do.
[19:03] <semiosis> infinity: awesome!  thank you so much.  let me know if there's anything else i can do
[19:04] <infinity> semiosis: But normally, if the person you'd just nagged weren't so close to the project (ie: I own it upstream), the correct way to do this is to do the backports yourself, find a sponsor to do the upload, then talk to the SRU team once it's in the queue (or just be patient while we get to it).
[19:05] <semiosis> thanks for that info.  i've only contributed packages to upcoming releases (glusterfs, in a past life) but never worked on an SRU before
[19:06] <infinity> semiosis: Pretty much the same process as the devel series, really.  The only difference for an SRU is that every change needs to close a bug with the right SRU paperwork, and once it's uploaded, it gets stuck in a queue for review.
[19:07] <infinity> semiosis: But the rest is the same deal.  Do the fixes.  Find a sponsor.  Iterate until sponsor likes your package.  Sponsor uploads.  Profit.
[19:16] <semiosis> infinity: one thing i don't understand is how to backport changes to the version of livecd-rootfs in xenial... is there a specific bzr branch for that?  a different repository?
[19:17] <infinity> semiosis: There's a different branch, yes.
[19:17] <infinity> http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/xenial-proposed/changes
[19:18] <semiosis> infinity: ah!  thank you.
=== salem_ is now known as _salem
[22:35] <sarnold> pitti: hello :) the retracers seem stuck again, 1605954 still has a CoreDump.gz after ~two days