[00:39] <israeldahl> cjwatson can I ask you where your genisoimage stuff is for ppc?
[07:09] <dholbach> good morning
[08:50] <Laney> mvo: hi, nobody knows how to update changelogs.ubuntu.com, any chance you can teach? :)
[08:50] <Laney> and hi!
[08:52] <Laney> 1. bzr up; 2. cp; seems to be it
[08:52] <seb128> Laney, what is to update on there?
[08:53] <seb128> Laney, ignore that
[08:53] <pitti> seb128: point to the update tarball in wily-updates
[08:53] <seb128> yeah, stupid question :p
[08:53] <pitti> we really don't want to respin for that
[09:02] <mvo> Laney: sure! bdmurray also knows
[09:02] <mvo> Laney: but yeah, its just that, update branch, cp in place (diff before for good karma) :)
[09:02] <Laney> mvo: I'm guessing bdmurray is in bed now. :P
[09:02] <Laney> mvo: how's it going, btw?
[09:02] <mvo> Laney: indeed
[09:03] <mvo> Laney: good, snappy is planed to release today as well
[09:03] <mvo> Laney: so I'm excited about two releases at the same day!
[09:03] <Laney> nice
[09:03] <Laney> twins!
[09:03] <mvo> lol
[09:03] <mvo> Laney: and you? all good?
[09:03] <mvo> 15.10 looks great on my machines so far
[09:04] <Laney> yep, I'm in BF now rounding off the last corners
[10:05] <rbasak> So I got bitten by a missing lvm2 after I do-release-upgraded to Wily yesterday, making my system unbootable.
[10:06] <rbasak> I thought it got autoremoved, but now I'm wondering if I ever had lvm2 installed in the first place. I have been using cryptsetup on disk block devices directly for years. So device mapper but no LVM.
[10:06] <rbasak> Is it possible that I never had lvm2 installed, it worked before, but latest cryptroot now requires lvm2 to be installed so that's why I broke? And could that apply to others?
[10:07] <rbasak> No sign of lvm2 in /var/log/apt/ except when I installed it to fix the issue.
[10:10] <infinity> rbasak: Are you saying cryptsetup and/or dmsetup has an undeclared dep on lvm2?
[10:10] <rbasak> Maybe, yes. Although I can't find it in the code right now, my system seemed to be broken until I installed lvm2.
[10:10] <rbasak> I did have another issue though so I'm not absolutely sure.
[10:11] <rbasak> (and that wone was my fault)
[10:11] <pitti> rbasak: and it wasn't just that this triggered an initramfs rebuild or the like?
[10:11] <pitti> I just did like 10 test installs with encrypted swap at least, which does need a good chunk of the cryptsetup stuff
[10:11] <pitti> (without LVM)
[10:11] <infinity> A failed upgrade may have also failed to run update-initramfs, this is a fair point.
[10:11] <rbasak> Hmm.
[10:12] <rbasak> My upgrade did also fail because of the invoke-rc.d issue.
[10:12] <pitti> a week or so ago I installed the wily daily with encrypting / and /home partitions, without LVM
[10:12] <pitti> (i. e. manual partitioning), which worked fine too
[10:12] <rbasak> So my case muddled multiple issues up so I'm not entirely clear on the individual issues.
[10:12] <pitti> (as part of investigating bug 1506139)
[10:12] <rbasak> Also I failed to mount /boot on my first attempt to run update-initramfs on the failed booted system so that confused things further.
[10:13] <pitti> rbasak: so if you can reproduce this somehow, running update-initramfs -u instead of installing lvm might be insightful
[10:13] <pitti> rbasak: or, do you still have that system? does it still boot after purging lvm again?
[10:13] <pitti> rbasak: invoke-rc.d issue is fixed now, btw
[10:13] <rbasak> It's my main system.
[10:14] <rbasak> I could try removing lvm2, making sure update-initramfs has run and then see what happens.
[10:14] <pitti> rbasak: keep an ubuntu live system usb stick around, just in case :)
[10:14] <rbasak> pitti: :)
[10:14] <pitti> this do-release-upgrade bug was quite a bummer indeed :/
[10:14] <rbasak> pitti: I have an external USB drive caddy thing that can make .iso files on it pretend to be USB CDROMs.
[10:15] <rbasak> It has a menu thing on it so I can select what to boot. Very handy.
[10:15] <infinity> rbasak: Neat.
[10:16] <rbasak> So when I traced the problem yesterday, I was getting the error "cryptsetup: lvm is not available" sent to plymouth. I tracked that down in my initramfs to be coming from cryptroot, IIRC, after a test for /sbin/lvm.
[10:17] <rbasak> But now I don't see that code at all, nor that string.
[10:17] <pitti> wow
[10:17] <rbasak> So I think I might have just had an out-of-date initramfs
[10:17] <rbasak> Possibly caused by the invoke-rc.d failure? Though I did do an "apt-get -f install" afterwards so I'm surprised update-initramfs didn't run then.
[10:17] <pitti> rbasak: how did you fix the upgrade, btw? apt-get -f install and another dist-upgrade?
[10:17] <rbasak> Yes, which actually did nothing.
[10:18] <rbasak> I did an autoremove after that, which removed a ton of things, but not lvm2 according to my logs.
[10:18] <pitti> rbasak: apt-get -f install ought to have done a lot of stuff; it didn't?
[10:18] <pitti> dist-upgrade, maybe not
[10:19] <rbasak> Not that I recall
[10:21] <rbasak> Logs say otherwise
[10:21] <rbasak> No that's September. Hmm.
[10:22] <rbasak> Yeah no sign of dist-upgrade having run in my logs. Presumably because it did nothing as I recall?
[10:22] <rbasak> Anyway, I don't think that's related.
[10:26] <rbasak> OK I figured it out
[10:27] <rbasak> It's a useless error message, that's all.
[10:27] <rbasak> If cryptroot can't find the source block device, it tries to activate LVM vgs. If that fails because lvm2 wasn't installed, then it prints "cryptsetup: lvm is not available".
[10:27] <rbasak> Even though the root cause is that the block device doesn't exist rather than LVM not being available (which was irrelevant in my case)
[10:28] <rbasak> Only after I installed lvm2 and re-ran update-initramfs did I see the real issue, which was that /dev/sda3 (or whatever) was missing because my printer made it become /dev/sdb3.
[10:29] <cjwatson> your *printer*?
[10:29] <cjwatson> please feed paper with printed bootloader to boot.
[10:29] <rbasak> I didn't switch to UUIDs yesterday incidentally. I have no idea what to do about cswap because presumably the UUID will change every boot.
[10:29] <rbasak> Yep. My printer.
[10:29] <rbasak> Apparently it presents a disk.
[10:29] <rbasak> I presume that disk has drivers for Windows or something.
[10:29] <cjwatson> awesome.
[10:30] <cjwatson> (or maybe you can send files to it that way?)
[10:30] <cjwatson> it would make sense for a scanner.
[10:30] <rbasak> My solution for now (because I don't know what to do with crypted swap) is to turn off the printer before booting.
[10:30] <rbasak> It is also a scanner.
[10:31] <rbasak> SO yeah, maybe.
[10:31] <cjwatson> there's a luksUUID which can go in crypttab
[10:31] <cjwatson> I think
[10:31] <cjwatson> cryptsetup luksUUID thingy
[10:31] <rbasak> Will that change every time if I used /dev/random for the swap key, though?
[10:31] <cjwatson> then that goes as the second field in crypttab
[10:31] <rbasak> And the "swap" option?
[10:31] <cjwatson> I don't *think* so ...
[10:31] <rbasak> Thanks! I'll try that.
[10:32] <cjwatson> this is all vague memory though I'm afraid
[10:32] <rbasak> Not now though. It's a pain to recover and it's my main machine so I'll be offline for too long I think.
[10:32] <pitti> rbasak: you either use luks or you use /dev/random as a key, you can't have both
[10:32] <rbasak> There is a bug in the cryptroot initramfs script I should report about the misleading error message though.
[10:33] <cjwatson> ah I forgot /dev/random was non-luksy
[10:33] <pitti> rbasak: but ecryptfs-setup-swap now uses an offset=1024 for a "random key" swap partition to preserve the partition type header and UUID
[10:33] <pitti> rbasak: so you can use UUID= in crypttab, and it'll stay around
[10:33]  * rbasak wonders what that has to do with ecryptfs
[10:33] <pitti> this was one of the ancient bugs in ecryptfs which only got uncovered in vivid
[10:34] <pitti> rbasak: ecryptfs-setup-swap is being used if you choose to encrypt your home dir, and that sets up a randomized encrypted swap partition
[10:34] <pitti> rbasak: i. e. it's what the installer uses
[10:34] <pitti> if you do this by hand, you can do whatever schema, of course
[10:34] <rbasak> Ah. I'm not using ecryptfs
[10:34] <pitti> but I recommend sticking to UUIDs, for the non-reliable names you mentioned
[10:36] <rbasak> pitti: so with a crypttab of: cswap		/dev/sda1		/dev/random	swap
[10:36] <pitti> rbasak: yeah, no uuids with that
[10:36] <rbasak> I can made sda1 UUID and it'll work?
[10:36] <rbasak> Because it does the offset thing?
[10:36] <pitti> rbasak: /dev/random'izing the entire  partition doesn't leave anything stable behind
[10:37] <pitti> rbasak: the approach of e-setup-swap is to mkswap on the partition normally, and use offset=1024 in crypttab to keep the first 1 KiB intact
[10:37] <pitti> rbasak: then you can use the UUID of sda1 instead
[10:38] <rbasak> So: cswap UUID=... /dev/random offset=1024,swap?
[10:38] <pitti> yes
[10:38] <rbasak> Got it. Thanks!
[10:39] <pitti> rbasak: you can also literally use ecryptfs-setup-swap (after creating an unencrypted swap), that'll set up everything
[10:41] <rbasak> Hmm.
[10:41] <rbasak> I'm not keen on it using /dev/urandom.
[10:41] <rbasak> Very little entropy available at boot. Many people's swap keys might end up the same.
[10:41] <rbasak> (or from a limited set)
[10:41] <rbasak> Maybe not so bad for bare metal. I don't know.
[10:42] <rbasak> Anyway, thank all. I can make many improvements based on this.
[10:43]  * pitti found http://www.2uo.de/myths-about-urandom/ an interesting read
[10:46] <rbasak> "Linux's /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer."
[10:46] <rbasak> That's the bit I mean.
[10:46] <rbasak> After a while it's fine. But I'm not convinced about the entropy available in initramfs.
[10:47] <pitti> rbasak: right, I wasn't saying you were wrong, just that it's an interesting read (I happened to remember while we were talking about it)
[10:47] <rbasak> Ah OK, sorry.
[10:47] <pitti> but nevertheless, hanging eternally in initramfs doesn't sound appealing either
[10:47] <rbasak> It doesn't seem to hang much for me.
[10:47] <pitti> and if it rarely/never hangs, then urandom is just as good as random
[10:48] <rbasak> Agreed. I guess it depends on what failure case you want. I want hang rather than boot with poor swap key entropy :)
[10:48] <pitti> rbasak: but yeah, feel free to talk kirkland into changing it to /dev/random (but I'm not convinced that this is a good idea especially for virtual envs)
[10:49] <pitti> rbasak: well, what *I* really want is to stop creating swap partitions by default
[10:49] <pitti> it's IMHO so utterly EBW
[10:49] <pitti> if you set them up manually, fine
[10:50] <rbasak> Why? EBW?
[10:52] <rbasak> You want swap files instead, or no swap at all?
[10:54] <pitti> rbasak: on machines with reasonaly much RAM, no swap at all; or at most dynamic swap files, yes
[10:55] <pitti> rbasak: because they are usually just a waste of space, and we managed to screw them up for many years
[10:55] <rbasak> A property of swap I like is that memory leaks or forgotten background process data ends up in swap, leaving my system RAM more available for buffers and cache (and less likely to OOM). Convenient on long lived systems.
[10:56] <pitti> i. e. due to at least three different bugs we managed to set up systems without swap space since pre-trusty, and nobody complained :)
[10:56] <rbasak> A property of swap I don't like is that thrashing happens instead of OOM in various error conditions.
[10:57] <rbasak> I'd like some swap thrash detection that activates the oom killer.
[10:58] <rbasak> I was surprised to see that my Ubuntu phone has swap in it.
[10:59] <rbasak> I have a slow disk (never bought an SSD) so having plenty of RAM available for caching is important to me.
[10:59] <popey> rbasak: I'd rather the shell and indicators were swapped out when webbrowser eats ram, than the shell getting oomkilled repeatedly
[10:59] <popey> (obv I'd rather browser didn't eat ram, but hey, can't have it all)
[11:00] <rbasak> popey: that's just a case of tuning the oom parameters and limiting memory available to apps though, right?
[11:00] <rbasak> A swapped out shell and indicators reflects badly on the performance of the phone as a whole.
[11:00] <popey> depends how quick you can swap them back in
[11:00] <rbasak> And makes it difficult to kill the browser if I want, too.
[13:06] <xnox> how to correctly mark upgrade bugs, to be flagged up?
[13:06] <xnox> https://bugs.launchpad.net/ubuntu/+source/libsolv/+bug/1508921
[13:08] <Laney> upload in the unapproved queue? :)
[13:11] <xnox> Laney: hehe
[13:12] <xnox> Laney: i would like to trow a toy out of my crib and claim i'm a customer =))))))))))))))
[13:12] <xnox> anyway 1.2k packages to upgrade still
[13:19] <doko> seb128, Laney: looks like a regression introduced with glib2.0? https://launchpadlibrarian.net/221953895/buildlog_ubuntu-wily-amd64.ubuntu-app-launch_0.5%2B15.10.20150817-0ubuntu1_BUILDING.txt.gz
[13:20] <Laney> in what way?
[13:20] <Laney> looks like a function which returns a bool is not doing so to me
[13:21] <doko> well, it built before, now fails
[13:21] <seb128> doko, seems like a but in ubuntu-app-launch bug
[13:21] <seb128> yeah
[13:21] <Laney> because they fixed g_return_if_fail to work
[13:22] <seb128> doko, remember the bug I pinged you about recently that turned out to be a glib one
[13:22] <seb128> that's what fixed that error to work
[13:22] <seb128> doko, https://git.gnome.org/browse/glib/commit/?h=glib-2-46&id=ab26dd54337544275ff8bb61eb227aed83a8ed80
[13:25] <doko> ohh, that one
[13:25] <doko> hmm, didn't touch doxygen, but https://launchpadlibrarian.net/221968264/buildlog_ubuntu-wily-amd64.xorg-gtest_0.7.1-0ubuntu1_BUILDING.txt.gz ...
[13:27] <doko> tjaalton, could you have a look at https://launchpadlibrarian.net/221956818/buildlog_ubuntu-wily-amd64.xorg-server_2%3A1.17.2-1ubuntu9_BUILDING.txt.gz ? this is with the binutils from the ubuntu-toolchain-r/power8 PPA
[13:42] <tjaalton> doko: so it's not powerpc or ppc64el?
[13:43] <tjaalton> hmm no, I see the bug now
[13:43] <tjaalton> guess it has never built?
[13:49] <tjaalton> oh amd64 too, I'm blind
[13:50] <tjaalton> so why is it checking for Xmir twice?
[13:58] <tjaalton> ..because it runs configure for two targets in parallel
[13:58] <tjaalton> dunno why it fails, tbg
[13:58] <tjaalton> *tbh
[14:00] <tjaalton> can't find libmirclient, though it's installed
[14:01] <tjaalton> I'll let ancell figure this out..
[14:05] <smoser> anyone want to ack or violently nack my suggested patch https://code.launchpad.net/~smoser/ubuntu-dev-tools/lp1508948-rmadison-sid-is-unstable/+merge/275351
[14:06] <rbasak> smoser: ah, you pinned that down in the end? Good job.
[14:06] <smoser> \o/
[14:07] <smoser> now i can use rbasak's git workflow without dget :)
[14:07] <xnox> dget is dead =) use dgit!
[14:07]  * xnox giggles
[14:09] <smoser> we should improve https://github.com/basak/ubuntu-git-tools to just automatically do the imports.
[14:09] <rbasak> Yes.
[14:09] <rbasak> Though I also want to have a central place for imported git trees
[14:10] <rbasak> And I think the plan is that eventually LP will have a git tree available for every package
[14:10] <rbasak> At which point no need to import
[14:12] <cjwatson> yes we definitely want to do dgit on LP
[14:13] <cjwatson> including with default package repository locations so that it's lp:ubuntu/+source/SRC
[14:13] <cjwatson> but I need to fix dgit to handle LP first
[14:27] <xnox> \o/
[14:42] <disposable> ls
[14:51] <infinity> xnox: Going to come to the office to visit and pat us all on the back?
[14:52] <xnox> infinity: today? tomorrow? =)
[14:53] <infinity> xnox: In a couple of hours.
[14:53] <Laney> Come help us open Xenial
[14:56] <xnox> infinity: i am busy between 5:30 and 6:30. Coming before is cutting it close, so can come in after =)
[14:57] <xnox> infinity: i'll text Laney
[15:34] <pitti> pete-woods: released/uploaded dbusmock 0.16.1, and uploaded backports to vivid+wily overlay PPA
[15:35] <pitti> pete-woods: sorry for the delay, release week "fun" and all that
[15:37] <doko> barry, make python3.5 the default from the start, or wait until later?
[15:58] <pete-woods> pitti: no worries. I understand you have a very busy role. thanks very much! :)
[16:09] <doko> tvoss, great, the last MIR updated dropped the mir-client-platform-mesa-dev file ...
[16:15] <doko> tjaalton, it's https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1509005
[16:15] <tjaalton> doko: ah :)
[16:16] <seb128> kgunn, ^
[16:18] <kgunn> seb128: doko tjaalton ack, getting someone from mir team to hop on that
[16:27] <barry> doko: i'd opt for the sooner the better.  do you think we should wait for uos or the sprint?
[16:28] <doko> barry, I'm fine with it, but we probably need some quick fixing tomorrow and next week
[16:29] <barry> doko: will you do an archive rebuild afterward making it default?  yes, let's get fixes in asap
[16:32] <doko> barry, take this one, from yesterday, with 3.5 as the default: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20151021-wily.html  main only
[16:33] <barry> doko: doesn't look too bad.  let's wait on django until 1.8 hits unstable
[16:38] <doko> barry, why? it's in experimental, you could it sync from there too
[16:40] <barry> doko: that's true.  i think there's still some question about the django stack compatibility w/1.8, but django itself won't be 3.5 compatible if we don't sync it.  let's do it
[16:40] <barry> and we'll just follow debian during this transition
[16:40] <doko> ok
[16:51] <barry> doko: what's the eta for xenial opening?
[16:52] <doko> should be ready tonight for toolchain uploads
[16:53] <barry> doko: +1
[17:33] <doko> barry, http://people.canonical.com/~ubuntu-archive/transitions/html/python3.5.html
[17:35] <barry> doko: ack
[18:39] <Luke> alesage: ping
[18:39] <alesage> Luke hi
[18:39] <Luke> did you take the picture on your G+ background?
[18:39] <Luke> of chicago
[18:40] <alesage> Luke no I didn't
[18:40] <Luke> do you know who did?
[18:40] <Luke> looks awesome btw
[18:40] <alesage> Luke hmm good q, might be able to trace
[18:40] <alesage> Luke, glad you like it
[18:40] <Luke> reverse search? yeah
[18:47] <alesage> Luke, I must've encountered it here (reverse-search FTW) https://www.reddit.com/r/chicago/comments/2e51og/tilt_shift_of_downtown/
[18:48] <Luke> cool thanks
[19:02] <rcj> How do I make LP aware of the upstream git tree for a package such that MoM will take over and keep things fresh?
[19:03] <rcj> Specifically http://pad.lv/u/keychain needs to know about https://github.com/funtoo/keychain
[19:41] <sarnold> infinity: (from dasjoe in #ubuntu-server) is http://cdimage.ubuntu.com/releases/wily/release/ supposed to have only ppc64el and powerpc images? thanks  :)
[21:04] <knome> slangasek, heya! thought i'd ping you about the xubuntu core merge proposals now; we'd totally prefer to merge the patches now without needing to rebase. and congrats for the release! :)
[21:40] <cjwatson> rcj: MoM has no awareness of upstream trees, nor of upstream in general.  Its purpose is to merge things from Debian.
[21:40] <cjwatson> rcj: And even then it's only informational, it won't do things for you.
[21:40] <jgjl> Hi, yay for 15.10!
[21:41] <jgjl> any hints where to find the poll mode drivers for DPDK?
[21:41] <rcj> cjwatson, thanks for clearing that up