[00:02] <bdmurray> pitti: armhf ddebs of mir didn't make it on to the server
[06:45] <pitti> Good morning
[08:39] <dholbach> good morning
[10:01] <dholbach> diwic, happy birthday!
[10:01] <diwic> dholbach, thanks! :-)
[11:47] <pfSmorigo> hi, I'm using preseed but I'm stuck in "No root file system is defined."
[11:47] <pfSmorigo> my preseed has a "d-i partman-auto/disk string /dev/sdb"
[12:39] <pitti> stgraber, hallyn: is there a concrete attack scenario why /var/lib/lxc needs to be 700? or is this just an additional defense line in case of containers with broken permissions?
[12:40] <pitti> I mean, system root dirs are usually world readable, and secret stuff has appropriate permissions
[12:44] <mdeslaur> pitti: bug 1244635
[12:46] <jdstrand> hallyn, arges: fyi, https://chinstrap.canonical.com/~jamie/lp1292234/ has forhallyn-trusty-amd64.img.gz and forhallyn-trusty-amd64.img.corrupted.gz
[12:46] <jdstrand> hallyn, arges I couldn't reproduce it until last night
[12:47] <didrocks> pitti: if we separate upstart system services and upstart session only services, the number of packages to convert this cycles aren't horrible: http://people.canonical.com/~didrocks/systemd/packages-to-convert/2014-11-20.txt
[12:47] <jdstrand> let me double check the the hashes
[12:48] <pitti> mdeslaur: ah, thank you!
[12:48] <jdstrand> hallyn, arges: weird-- it is like a tenth of the size...
[12:48] <jdstrand> (compressed)
[12:49] <pitti> didrocks: yes, indeed! we don't need to convert the session ones, but we must replace any system upstart event that they listen to by something else
[12:49] <didrocks> pitti: yeah, that's why I still list them and counted them at the bottom
[12:49]  * didrocks waits for jhunt to merge his branch with those changes
[12:49] <pitti> didrocks: also, note that there are a lot of false postiives in that list too
[12:50] <didrocks> yeah, I know, I'm looking at why now
[12:51] <didrocks> pitti: actually, do you have an example of a false positive ones? The one I thought actually had some upstart session service in the end
[12:51] <pitti> didrocks: I mean hostname, mountall, upstart, upstart-bin, ureadahead
[12:51] <didrocks> ah that
[12:51] <didrocks> yeah
[12:51] <didrocks> not sure it worth a blacklist, we know about those
[12:51] <pitti> didrocks: yes, just pointing out that the list is even a bit shorter :)
[12:51] <didrocks> yeah :)
[12:56] <pitti> didrocks: oh, and rfkill too
[12:57] <didrocks> well, ok, let's build the blacklist then :)
[12:58] <pitti> didrocks: don't waste time on it -- apart from rfkill it's quite obvious, and I didn't spot others
[12:59] <didrocks> ok, I would totally have forgotten rfkill TBH
[13:08] <Saviq> pitti, hey, I was wondering, is it possible, using gdbserver or similar, to debug stuff on a remote host, while supplying symbols locally? I'm thinking being able to attach to a running process on the phone without having to install the symbols on it?
[13:31] <asac> whats the current best practice to record my desktop?
[13:31] <ogra_> use your phone ;)
[13:32] <Laney> I've used kazam recently with success
[13:35] <mitya57> There is a package named recordmydesktop, I think it worked fine when I tried to use it.
[13:35] <teward> any patch pilots awake to peek at a merge debdiff and maybe sponsor it?  i heard i might need a patch pilot to assist with that.
[13:41] <caribou> When upstream provides a new major version, what should I do about the Ubuntu version ? Directly sync it to Vivid ?
[13:42] <caribou> I mean, there is no longer any delta b/w Ubuntu & Debian
[13:43] <ScottK> teward: Subscribe ubuntu-sponsors to the bug with the debdiff in it.  That'll get someone to look at it.
[13:43] <teward> ScottK: did that - been almost 3 weeks
[13:43] <teward> ... with no movement
[13:43] <ScottK> Sometimes it goes like that.
[13:44] <ScottK> caribou: If the new version is in Debian and there's no remaining Ubuntu delta, yes.  It should be synced.
[13:45] <caribou> ScottK: yes that's the case (I maintain both debian & Ubuntu)
[13:45] <ScottK> caribou: Sync away then.
[13:46] <caribou> ScottK: any place to look to learn how it is done ?
[13:46] <caribou> first time I have to do it since I got PPU for that package
[13:53] <caribou> nm, I found it
[13:54] <caribou> ScottK: and what happens to the merge request on Merge-O-Matic ?
[14:00] <ScottK> caribou: Once the sync is done, it'll go away.
[14:00] <caribou> ScottK: ah, ok thanks
[14:05] <pitti> mvo: I suppose we want https://tracker.debian.org/news/585559 now? (new perl is already in vivid)
[14:06] <pitti> mvo: you are TIL, but I'm happy to merge it
[14:06] <pitti> (if you want)
[14:06] <mvo> pitti: cool, yes. go for it, I'm super busy
[14:06] <pitti> mvo: yeah, thought so :)
[14:06] <mvo> pitti: but its getting better :)
[14:07] <mvo> pitti: just don't make my image bigger ;)
[14:07] <davidak2> hello. i think i found a bug in ubuntu 14.04
[14:07] <davidak2> installed nginx from repo, it don't start at boot
[14:07] <pitti> mvo: well, that's now the proper fix for tha
[14:07] <pitti> t
[14:07] <davidak2>    /etc/rc3.d/S20nginx -> ../init.d/nginx
[14:08] <mvo> pitti: yeah
[14:08] <davidak2> if it is /etc/rc3.d/S21nginx it will work
[14:08] <mvo> pitti: how is it done (I'm curious), did all the required stuff move into perl-base?
[14:09] <pitti> mvo: https://tracker.debian.org/news/585385
[14:09] <davidak2> i think postfix, rsync, screen-cleanup or sysstat is a dependency and must start first
[14:09] <davidak2> where does the 20 come from?
[14:09] <mvo> ta
[14:10] <davidak2> maybe i can fix it but it would be my first time contributing to ubuntu and don't know what repository and how is the workflow
[14:18] <stgraber> pitti: there is
[14:19] <pitti> stgraber: mdeslaur already pointed to bug 1244635, that pretty much answers it
[14:19] <stgraber> right, that's why
[14:27] <caribou> ScottK: ok, before I go and make a big mistake (I hate the --force options) I suppose that it is normal to use --force since I'm overriding the ubuntu specific changes that are now in the new version
[14:27] <ScottK> caribou: That's normal if you're overriding changes.
[14:28] <caribou> ScottK: yes and I've just re-confirmed that everything ubuntu specific in 3.1 is now in 3.2
[14:28] <ScottK> Then go for it.
[14:28] <caribou> otherwise I'll blame the other schizophrenic side of me who is the debian maintainer
[14:28] <ScottK> Worst case it needs another upload later to add something back and that's not a big deal.
[14:31] <davidak2> isn't this the right place for my question?
[14:34] <caribou> davidak2: http://packaging.ubuntu.com/html/fixing-a-bug.html is a good start
[14:37] <caribou> davidak2: but that describes UDD which is not frequently used in fixing bugs on stable releases
[14:39] <caribou> davidak2: but I would say that the first thing to do is to create a bug that will describe the issue & how you think it can be fixed
[14:46] <davidak2> caribou: thanks.
[15:53] <pitti> bdmurray: libnih ddebs are all on http://ddebs.ubuntu.com/pool/main/libn/libnih/ except for i386, as that FTBFSed: https://launchpad.net/ubuntu/+source/libnih/1.0.3-4ubuntu27/+build/6576097
[15:53] <pitti> bdmurray: I retried the build, hoping for/looks like an unstable test
[15:55] <pitti> bdmurray: Mir seems complete? http://ddebs.ubuntu.com/pool/main/m/mir/
[15:55] <bdmurray> pitti: yeah, the armhf one just was slow to appear
[15:57] <pitti> bdmurray: about libudev1-dbgsym: "libudev1 has no unstripped objects, ignoring"
[15:57] <pitti> bdmurray: that's surprising indeed, I'll create a bug to check that
[15:58] <didrocks> jodh: hey, not sure if you noticed, but I've enhanced a little bit your detect upstart script to tell which packages contain upstart session jobs only (and we will only check for events in them, but won't convert them this cycle to systemd). I've run it and the output is http://people.canonical.com/~didrocks/systemd/packages-to-convert/2014-11-20.txt
[15:59] <pitti> bdmurray: filed bug 1394627
[15:59] <didrocks> jodh: my branch is at lp:~didrocks/+junk/separate-upstart-session-system if you want to give it a look and eventually pull the extra commit :)
[16:00] <bdmurray> pitti: thanks
[16:00] <jodh> didrocks: yes, thanks. maybe you could merge your changes into lp:~ubuntu-foundations-team/+junk/migration-to-systemd (or raise MP)?
[16:03] <didrocks> jodh: IIRC, you can't propose for merging into a +junk/ branch
[16:03] <Riddell> jdstrand: patches for your pleasure on bug 1393479
[16:03] <jodh> didrocks: ok, didn't know that - patch? :)
[16:04] <didrocks> jodh: hopefully, I just made it one commit, so easy for you to pull/push: http://bazaar.launchpad.net/~didrocks/+junk/separate-upstart-session-system/revision/7 :)
[16:04] <jdstrand> Riddell: thanks! I'm going to point mdeslaur at those since he is on community this week, but he may reassign
[16:12] <jodh> didrocks: thanks - merged and re-run for http://people.canonical.com/~jhunt/systemd/packages-to-convert/2014-11-20.txt
[16:12] <didrocks> jodh: nice, thanks! :)
[16:16] <ah> Hi. I'm wondering if anyone knows the status of migrating to bluez5 in ubuntu. As I understood it the main reason to hold back a while ago was because of bluetooth headset support. As I understand it now, this will be adressed with the upcoming pulseaudio release. Does anyone here know if there has been any discussions about going ahead with bluez5 some time in the future? (Sorry for being so out of touch
[16:16] <ah>  with whats ...
[16:16] <ah> ... happening in ubuntu.)
[16:17] <didrocks> ah: we discussed it at least UOS, you can see the hangout video here: http://summit.ubuntu.com/uos-1411/meeting/22332/update-to-bluez-5/
[16:17] <ah> didrocks: thanks. will check it out.
[16:18] <didrocks> ah: yw, you have a blueprint to track the progress: https://blueprints.launchpad.net/ubuntu/+spec/desktop-v-bluez5
[16:55] <bdmurray> zul: your upload of keystone to utopic proposed contains some extraneous changes, well I think at least you don't want to change the Vcs information. https://launchpadlibrarian.net/190573428/keystone_1%3A2014.2-0ubuntu1_1%3A2014.2-0ubuntu2.diff.gz
[16:57] <bdmurray> zul: and the related bug could use some updating for the SRU
[17:05] <zul> bdmurray:  reject it please
[18:23] <jdstrand> hallyn, arges, rharper: hey, did you guys see backscroll? I was able to upload a corrupted image last night: https://chinstrap.canonical.com/~jamie/lp1292234/
[18:24] <rharper> jdstrand: yeah, thanks!
[18:24] <jdstrand> it is curiously way smaller compressed than the other
[18:24] <jdstrand> but uncompressed it is the same size
[18:24] <rharper> mmmm zeros
[18:24] <jdstrand> rharper: cool
[18:24] <jdstrand> hopefully that will shed some light on it
[18:24] <rharper> jdstrand: du reports the same allocation ?
[18:25] <jdstrand> well, if I uncompress and use file, it tells me it is the same
[18:26] <jdstrand> QEMU QCOW Image (v2), 8589934592 bytes
[18:26] <jdstrand> that is corrupted ^
[18:26] <jdstrand> QEMU QCOW Image (v2), 8589934592 bytes
[18:26] <jdstrand> that is uncorrupted ^
[18:27] <jdstrand> qemu-img shows that the uncorrupted doesn't have a pristine snapshot. that should be correct
[18:28] <jdstrand> so, the 'disk size' is bigger with corrupted
[18:28] <jdstrand> (since it has an internal snapshot, that makes sense)
[18:28] <arges> jdstrand:oh awesome
[18:28] <jdstrand> but yean. going from 1.2G compressed to 104M, something is not right
[18:29] <jdstrand> yeah*
[18:29] <arges> jdstrand: i'll look at it after lunch
[18:31] <jdstrand> arges: one nice thing about it being smaller-- it is faster to download while at the sprint :)
[18:31] <jdstrand> arges: thanks!
[18:34] <jdstrand> rharper, arges, hallyn: oh, this came up before and might be helpful: sarnold and I both are using ext3 where the qcow2 are stored. I know there were some extant bugs with qcow2s that hallyn pointed us at, but I read the reports and commits and didn't think those fixes would tix our issue
[18:34] <jdstrand> that said, if you as experts thought otherwise, I'd be happy to try other things
[18:36] <jdstrand> sarnold: can you confirm I am remembering your system correctly?
[19:05] <bdmurray> chiluk: don't you men nfsv3 in the impact part of bug 1391662?
[19:05] <bdmurray> s/men/mean/
[19:23] <sarnold> arges,hallyn,jdstrand, I am using ext3 on my laptop where I've had the qcow2 corruption
[19:40] <chiluk> bdmurray, checking..
[19:40] <chiluk> bdmurray, correct... fixed
[19:51] <arges> sarnold: jdstrand good to know
[20:13] <chiluk> thanks bdmurray