[03:38] <robert_ancell> bregma, I'm updating the metacity package and it changes the soname for libmetacity-private. This means compiz-gnome needs to be rebuilt. Have you done a migration like this before?
[03:45] <robert_ancell> bregma, bug 1463645
[04:20] <pitti> Good morning
[05:56] <didrocks> good morning
[06:14] <RAOF> pitti: Good morning! We seem to have some SRU autopkgtests failing due to test environment changes.
[06:15] <RAOF> I understand that you're on the hook for doing something about that? :)
[06:15] <pitti> RAOF: in trusty mostly, right?
[06:15] <RAOF> pitti: Yah.
[06:15] <pitti> RAOF: yeah, some of the tests fail because they expect their build dependencies to be installed
[06:15] <RAOF> Right.
[06:15] <pitti> we could fix them in trusty by SRUing the fixed tests if we care, but for the user that'd be a no-op update
[06:16] <pitti> we don't have the old infrastructure any more which ran tests with the null runner
[06:18] <RAOF> There was another one that seemed odd; “failed to find parent run by non-root” seemed to be the relevant output.
[06:18] <RAOF> But I can't remember which particular adt job that was.
[06:19] <pitti> RAOF: haven't seen that one -- is that a jenkins or a test error message?
[06:19] <RAOF> It looked like it was an test runner error message.
[06:19] <RAOF> It didn't look like it had actually started running the tests.
[06:20] <pitti> RAOF: then these should just be retried; might be just another jenkins glitch?
[06:20] <RAOF> Might be? It was one of the gvfs rdepend failures, which seemed to have hung around for some time.
[06:26] <pitti> RAOF: looking at the trusty gtk+3.0 rdeps
[06:27] <pitti> deja-dup: missing dbus-x11 test dep
[06:27] <pitti> notify-osd: doesn't say (darn parallel test runner), but presumably missing xvfb or something such (also fixed in utopic and later)
[06:29] <pitti> ubuntu-release-upgrader> not sure, there are multiple errors there; "None is not true" doesn't help much
[06:29] <pitti> perhaps due to missing at-spi-core or so ("The name org.a11y.Bus was not provided by any .service files", but that's just a warning)
[06:30] <pitti> update-manager> 'HTTP Error 405: Method Not Allowed'
[06:30] <pitti> may be due to changed proxy settings; we can't just switch that back either
[06:30] <RAOF> Oooh, I downloaded the log!
[06:31] <RAOF> http://paste.ubuntu.com/11688382/ is the log with the weird non-root message.
[06:32] <RAOF> http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-gvfs/lastBuild/ARCH=amd64,label=adt/
[06:32] <pitti> apport> not sure about that, but it never succeeded in trusty with teh current infrastructure either; needs a test fix backport and closer investigation
[06:32] <RAOF> trusty-gvfs
[06:32] <sarnold> that's a string from gvfs
[06:33] <pitti> gvfs> "Did not find a parent process that runs as non-root"> that was fixed in gvfs-testbed in utopic, needs backport
[06:33] <RAOF> Ah, good.
[06:33] <pitti> RAOF: ah, so that's what you saw, right
[06:33] <RAOF> Yeah.
[06:33] <RAOF> It didn't look like it actually got to running a test, but clearly it did.
[06:33] <pitti> so, we could fix the tests if/when we SRU these packages, but not sure if we should do SRUs *just* for test fixes
[06:34] <pitti> there's loads of them; the current infrastructure wasn't really meant to run trusty tests; we knew that a lot of the ones in trusty were broken and only worked due to the deficiencies of the null runner
[06:35] <RAOF> So, we can basically ignore trusty SRU adt failures, then?
[06:36] <pitti> the ones which never succeeded since we turned on SRU testing for trusty, yes
[06:36] <seb128> good morning desktopers
[06:36] <seb128> hey pitti RAOF
[06:36] <pitti> or, we have to fix them all, but that's a rather large undertaking
[06:36] <pitti> bonjour seb128
[06:36] <RAOF> Hey seb128
[06:37] <RAOF> pitti: Can we detect those never-passed ones, and not show them on pending-sru as regressions?
[06:38] <didrocks> re seb128
[06:40] <seb128> re didrocks ;-)
[06:42] <pitti> RAOF: replied to the ML
[06:43] <pitti> RAOF: yes; preferably through the britney override branch (I think slangasek and bdmurray discussed that yesterday, not sure of the outcome), and if that doesn't work, we can hack the history file
[06:43] <RAOF> infinity was also talking about it this morning.
[06:43] <pitti> RAOF: e. g. http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-click/ looks like an "honest" regression somewhere
[06:44] <pitti> vivid regressions should be fairly real; utopic still has some infrastructure related regressions, trusty's are mostly due to a completely different infra
[07:22] <willcooke> morning
[07:23] <didrocks> hey willcooke
[07:26] <seb128> hey willcooke
[07:26] <didrocks> seb128: 32 bits of visual studio code coming in next ubuntu make release
[07:26] <seb128> didrocks, oh, nice ;-)
[07:28] <larsu> bonjour!
[07:29] <seb128> hey larsu
[07:29] <didrocks> morning larsu
[07:31] <larsu> hi seb128, didrocks! Ça va?
[07:34] <pitti> hey willcooke, hello larsu
[07:38] <larsu> hi pitti :)
[07:38] <larsu> morning willcooke
[07:38] <seb128> larsu, oui, et toi ?
[07:39] <larsu> seb128: nickel, merci!
[08:02] <Laney> hey hey
[08:02] <larsu> morning Laney!
[08:03] <Laney> yo dawg
[08:03] <Laney> what is up?
[08:03] <larsu> sun!
[08:03] <larsu> very up
[08:04] <Laney> not here
[08:04] <larsu> :/
[08:04] <Laney> lend me a bit
[08:04] <larsu> come on over
[08:04] <Laney> oh yeah good plan
[08:04] <Laney> brb plane
[08:04] <willcooke> goodly morloade Laney
[08:04]  * larsu makes some tea for Laney 
[08:04] <Laney> ahoy willcooke
[08:05] <seb128> hey Laney
[08:05] <didrocks> hey Mr Laney
[08:08] <larsu> pitti: what's responsible for mounting the filesystem writable when /userdata/.writable_image is there?
[08:08] <larsu> booting with systemd makes it ro for me again
[08:12] <ogra_> larsu, the initrd
[08:12] <larsu> hm, that shouldn't have changed though, right
[08:12] <ogra_> but !
[08:12] <ogra_> i'm not sure core allows that at all :)
[08:13] <ogra_> your desktop-next is based on core, not touch
[08:13] <larsu> talking about tough
[08:13] <larsu> *touch
[08:13] <ogra_> ah, k
[08:13] <ogra_> yeah, thats the phone initrd
[08:14] <larsu> weird
[08:15] <ogra_> the initrd does the low level partition mounting and feeds all writable paths into fstab ... the boind mounting of the writable b its then happens from whatever processes fstab (mountall, systemd-fstab)
[08:15] <Laney> it puts something in kmsg
[08:15] <Laney> mounting or mounting in developer mode or something
[08:15] <Laney> so you can see if it reads the file right
[08:15] <ogra_> so i guess systemd-fstab behaves a little different to mountall here
[08:16] <ogra_> (or you end uzp with the writable partition in fstab, which shouldnt be the case)
[08:19] <ogra_> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/initramfs-tools-ubuntu-touch/wily/view/head:/scripts/touch#L316
[08:20] <larsu> ogra_: thanks! fstab lists the rootfs as ro, even though writable_image is there
[08:20] <larsu> Laney: nothing of the sort..
[08:21] <ogra_> larsu, with a partition name ?
[08:21] <larsu> no, /dev/root
[08:21] <ogra_> /dev/root / rootfs defaults,ro 0 0 is fine
[08:22] <larsu> but then there should be something mounting / as rw?
[08:22]  * ogra_ must admit he hasnt used writable by default in ages ... remounting rw for the moment i need it feels a lot cleaner
[08:22] <larsu> fair enough :)
[08:23] <ogra_> but our tests that run for every build are all on writable devices
[08:23] <ogra_> (the CI automation stuff too)
[08:24] <larsu> ya, it worked fine until I linked /sbin/init to systemd
[08:24]  * larsu is trying to find the cause now
[08:24] <ogra_> as Laney said, check dmesg for "initrd: mounting system.img (image developer mode)"
[08:24] <ogra_> to make sure the initrd side is fine
[08:25] <larsu> ya, it doesn't say this
[08:25] <ogra_> wow, thats weird
[08:25] <ogra_> what phone is that ?
[08:25] <Laney> "(user mode)" seems to be the other case
[08:25] <larsu> nexus 4
[08:26] <ogra_> /sbin/init doesnt have any effect at that point in the boot
[08:26] <pitti> larsu: hm, I don't know I'm afraid
[08:26] <ogra_> (or, well, shouldnt have :P )
[08:27] <larsu> ogra_: I did a dist-upgrade as well, maybe this isn't init's fault. let me check
[08:27] <ogra_> urgh
[08:34] <larsu> so ya, I get that message in dmesg now
[08:36]  * larsu <- confused
[09:26] <Laney> pitti: have you seen the chromium-browser autopkgtest failure (ENOSPC)? any way the node can get some more space?
[09:26] <pitti> Laney: FYI, for your upower build, I'm on the broken umockdev
[09:26] <Laney> hah
[09:26] <Laney> hello!
[09:27] <Laney> I'm fixing the gjs (real) failure right now, F*Y*I :)
[09:27] <pitti> I'm waiting on LP to import 0.8.10-2 from Debian, then I'll sync, and the tests should be happy again
[09:27] <pitti> Laney: LibO fails on that as well, looking
[09:27]  * Laney blehs at people disabling testsuites
[09:27] <Laney> s/disabling/|| true-ing/
[09:28] <seb128> libO keeps sending "dual jenkins emails"
[09:28] <seb128> it fails
[09:28] <seb128> or it's fixed
[09:28] <seb128> it fails
[09:28] <seb128> oh it's fixed
[09:28] <seb128> ...
[09:28] <pitti> hm, neither / nor /run/shm is full on alderamin
[09:29] <Laney> it's failed on wazn and aldebaran too
[09:29] <Laney> seems systemic
[09:29] <pitti> perhaps they have finally exceeded our default VM size of 10G
[09:30] <pitti> err, 50G
[09:30] <Laney> surely not
[09:30] <pitti> but that would be gross
[09:31] <pitti> hm, wait
[09:31] <pitti> none             16G  200M   16G   2% /run/shm
[09:31] <pitti> jibel: ^ didn't these machines use to have 64G?
[09:33] <pitti> Laney: ok, that might be it; running locally to confirm, but it seems somehow these machines lost a lot of RAM
[09:33] <pitti> Laney: so I guess I'll invent an override mechamism to run these big packages on an overlay in /tmp/ instead of /run/shm/
[09:33] <davmor2> pitti: did you repartition?
[09:34] <pitti> davmor2: no, I don't have root on these machines, and partitions are fine
[09:34] <davmor2> pitti: meh sorry something else all together
[09:35] <pitti> hah, we already have that mechanism
[09:35] <pitti> ./etc/adt.d/linux:USESHM=false
[09:35] <pitti> ./etc/adt.d/libreoffice:USESHM=false
[09:36]  * pitti will enable that for chromium-browser then; but why did libo fail then
[09:36] <pitti> http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/job/wily-adt-chromium-browser/lastBuild/ARCH=i386,label=adt/consoleText definitively has -o /run/shm
[09:36] <pitti> but http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/job/wily-adt-libreoffice/lastBuild/ARCH=i386,label=adt/consoleText doesn't
[09:40] <pitti> jibel: ah, wazn and albali do have a 32 G /run/shm, so I guess alderamin just never had
[10:00] <jibel> pitti, yeah, alramin was the only machine with only 32G of RAM
[10:00] <jibel> alderamin*
[10:01] <pitti> jibel: I added USESHM=no for chromium-browser and re-ran; stil not sure about libo, I'm investigating
[10:01] <pitti> bah
[10:01] <pitti> http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/job/wily-adt-chromium-browser/39/ARCH=amd64,label=adt/consoleFull
[10:02] <pitti> same "disk full" without /run/shm/, so that isn't it
[10:02] <pitti> and running this locally on alderamin works fine
[10:04] <jibel> pitti, with the same base VM?
[10:04] <pitti> yes; re-running the exact command from the jenkins run now, with -proposed
[10:04] <pitti> and watching df in the VM
[10:05] <pitti> tmpfs           2.0G   69M  1.9G   4% /tmp
[10:06] <pitti> hah! that would be it
[10:07] <pitti> Laney: ack, looking at that; auto-mounting /tmp as tmpfs seems to be from systemd 220, seems our patch to not do that doesn't work any more
[10:28] <Laney> pitti: ah, right, so it's at least a real regression somewhere
[10:28]  * Laney wonders why shotwell started failing in the same way again
[10:28] <Laney> passes on my real system :(
[10:28] <pitti> Laney: umockdev
[10:28] <pitti> Laney: libudev 220 changed behaviour a bit, umockdev needs to follow along
[10:28] <Laney> ah
[10:28] <pitti> Laney: should reproduce with --apt-pocket=proposed -U
[10:29] <Laney> probably; I just ran d/t/...
[10:29] <Laney> is that breaking gvfs too?
[10:31] <Laney> I wish adt-run would say in which way test-deps are unsatisfiable
[10:42] <pitti> Laney: it usually does
[10:42] <pitti> Laney: well, it calls apt-get with Debug::pkgProblemResolver
[10:42] <pitti> that isn't very readable I'm afraid
[10:42] <pitti> but at least it's there
[10:42] <pitti> Laney: gvfs> yes, the Gphoto test uses umockdev too
[10:43] <pitti> Laney: and ubuntu-drivers-common
[10:43] <Laney> pitti: ah, right, yes - the output is further up
[10:44] <Laney> it's readable if you know how - for kde-gtk-config it's quite simple looking anyway. :)
[11:20] <seb128> Laney, can you retry desktopnext cdimage build?
[11:20] <Laney> ok
[11:20] <seb128> thanks
[11:20] <Laney> I'm goign to set up this team
[11:20] <Laney> (later)
[11:30] <seb128> Laney, thanks
[11:54] <seb128> Laney, oh, I forgot to follow up after the meeting yesterday about those gnome-shell-extensions/gtk, what was that?
[11:55] <seb128> Laney, also you retried desktop-next on amd64 only?
[11:56] <seb128> mvo, livecd-rootfs 500-move-kernel-to-device-tar.binary has its name on it ... maybe you can help there :-)
[11:56] <seb128> mvo, " cp -ar boot/vmlinu?-* $TMPDIR/assets/vmlinuz", where is that boot/ coming from?
[11:57] <seb128> it fails on amd64 for desktop-next with
[11:57] <seb128> "+ cp -ar boot/vmlinuz-3.19.0-20-generic boot/vmlinuz-3.19.0-20-generic.efi.signed /tmp/tmp.WKlc3yv5h0/assets/vmlinuz
[11:57] <seb128> cp: target '/tmp/tmp.WKlc3yv5h0/assets/vmlinuz' is not a directory
[11:57] <seb128> E: config/hooks/500-move-kernel-to-device-tar.binary failed (exit non-zero). You should check for errors."
[11:57] <seb128> I guess there is a /boot/vmlinuz, should we mkdir mkdir -p $TMPDIR/assets/vmlinuz before the cp then?
[11:58] <seb128> hum, that's a stupid suggestion :p
[11:58] <seb128> I guess that's not mean to be a dir
[11:58] <seb128> so the issue is likely that we have several matches for vmlinu?-*
[11:59] <Laney> seb128: the others are going to fail no?
[11:59] <seb128> likely due to the uefi variant
[11:59] <Laney> oh wait, it'is i386 that works
[11:59] <seb128> Laney, yes
[11:59] <Laney> teehee
[11:59] <seb128> Laney, i386 is the one I'm interested in ;-)
[11:59] <seb128> that's the one that builds
[11:59] <Laney> gtk> test regressions to fix first
[11:59] <seb128> k
[11:59] <Laney> that's what I was talking about with p itti
[11:59] <Laney> great fun
[11:59] <mvo> seb128: from the kernel we install in our livecd-rootfs
[12:00] <mvo> seb128: do you guys install a kernel too?
[12:00] <Laney> ok i386 going
[12:00] <seb128> Laney, thanks :-)
[12:01] <seb128> mvo, I guess we do :-) unsure why/how though, that image should be similar to ubuntu-core, just with extra seeded binaries
[12:01] <seb128> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop#L64 doesn't include linux-*
[12:02] <mvo> seb128: I think we don't do it via the seeds, irrc its black magic
[12:02] <mvo> seb128: hold on a sec
[12:03] <seb128> mvo, yeah, I just don't understand that magic, I'm a muggle ;-)
[12:05] <mvo> seb128: I think you need to set KERNEL_FLAVOURS some lines earlier, I can add that for you
[12:06] <ogra_> yeah, it isnt handled by seeds
[12:06] <ogra_> comes from a live-build var
[12:06] <seb128> mvo, ogra_, how/why is that different between ubuntu-core and ubuntu-desktop-next?
[12:06] <seb128> they have the same livecd-rootfs hooks basically
[12:06] <ogra_> seb128, not sure, let me take a look
[12:06] <seb128> ogra_, thanks
[12:06] <ogra_> (i havent touched core before)
[12:06] <ogra_> (at least on that level)
[12:07] <mvo> seb128: I don't know, I don't know why it wasn't added it to desktop-next
[12:07] <seb128> well, for sure they are different
[12:07] <seb128> mvo, is it in ubuntu-core?
[12:07] <mvo> seb128: but really, this code-duplication that we need is bothering me (quite a lot)
[12:07] <mvo> seb128: one sec, let me point you at the code line
[12:07] <seb128> mvo, yeah, me too, I tried to symlink those hooks yesterday but build failed then
[12:07] <seb128> "cp: cannot stat 'config/hooks/03-boot_with_systemd.chroot': No such file or directory"
[12:08] <mvo> seb128: well, its ok for now, but longer^Wshoter term this is becoming a nightmare
[12:08] <seb128> right
[12:08] <seb128> need to fix that
[12:08] <mvo> seb128: not blaming you :)
[12:08] <mvo> seb128: don't get me wrong, the tools just have not kept up with the task we now throw at them
[12:08] <seb128> I've to admit I didn't sit down trying to understand the livecd-rootfs details
[12:08] <seb128> I'm just poking around
[12:08] <mvo> seb128: *cough* I doubt many people do
[12:09] <ogra_> seb128, line 412 in live-build/auto/config adds the kernel
[12:09] <ogra_> OPTS="${OPTS:+$OPTS }--linux-packages=linux-image"
[12:10] <ogra_> seb128, i guess you want to add "ubuntu-desktop-next" to the case in line 368
[12:12] <seb128> ogra_, ok, good spot, thanks
[12:12] <seb128> mvo, thanks as well ;-)
[12:12] <ogra_> :)
[12:14] <mvo> ogra_: well, if we do that they will not install recommends anymore
[12:14] <ogra_> oh, right
[12:14] <mvo> ogra_: so we need another if ! ubuntu-core
[12:14] <ogra_> then you want to duplicate the whole thing or some such
[12:14] <mvo> ogra_: which is frankly all terrible and spahgeetty
[12:14] <seb128> ogra_, mvo: in fact it seems didrocks did that
[12:14] <seb128> ogra_, mvo, http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/config#L206
[12:15] <seb128> l220
[12:15] <seb128> 			OPTS="${OPTS:+$OPTS }--linux-packages=linux-image"
[12:15] <mvo> seb128: I'm not sure thats enough, it may need KERNEL_FLAVOURS, but again I don't know the ins/outs
[12:16] <seb128> mvo, so adding a "                        KERNEL_FLAVOURS=generic" line?
[12:16] <ogra_> it definitely needs more additions now that you are snappy based
[12:16] <mvo> ogra_: meh, sorry, I don't want to come across negative, the or thing is probably a good start, we could move the other ubuntu-desktop-next after ubuntu-core and override the apt recommends to true again
[12:16] <seb128> ogra_, like?
[12:17] <mvo> still not great but if its close together and we add a comment it would be ok I guess?
[12:17] <ogra_> seb128, look at the ubuntu-core stuff ...
[12:17] <ogra_> while you dont want the dropping of recommends it adds a ton of extra packages etc
[12:17] <seb128> ogra_, well, it mostly install packages, that we don't need because our seed is complete/has recommends
[12:18] <mvo> I really wish we had somthing declarative where you can say "project ubuntu-desktop-next(ubuntu-core):\n  apt_recommends = true\nextra_package += ["foo", "bar"]
[12:18] <ogra_> seb128, add_package install ubuntu-snappy ... and the like
[12:19] <ogra_> also enabling universe for system-image-cli
[12:19] <ogra_> etc etc
[12:19] <seb128> ogra_, but ubuntu-snappy is installed, https://launchpadlibrarian.net/208626439/livecd.ubuntu-desktop-next.manifest
[12:19] <ogra_> ah, k
[12:19] <ogra_> well, all i mean is you should go over all the lines there and see that you end up with the same bits installed
[12:19] <seb128> right, we added those to our desktop seed
[12:20] <seb128> unsure why core is not doing that
[12:20] <seb128> like
[12:20] <seb128> "
[12:20] <seb128>                         # some workarounds because the seeds are not quite
[12:20] <seb128>                         # corrent at the moment
[12:20] <seb128> 		        add_package install dbus"
[12:20] <Laney> seems to just be the flavour thing
[12:20] <seb128> I don't understand why that needs to be there as a hack
[12:21] <ogra_> dropped recommends ?
[12:21] <ogra_> though yeah, one could have seeded that :)
[12:21] <seb128> couldn't dbus be seeded?
[12:21]  * ogra_ has no idea why it wasnt 
[12:21] <seb128> yeah :-)
[12:21] <ogra_> perhaps because you dont want it in certain images
[12:21] <ogra_> cloud ?
[12:22] <ogra_> hmm, no, its in the generic part of the code
[12:23] <Laney> is there an ubuntu-core seed?
[12:23] <Laney> I think this SUBPROJECT thing is because there is ubuntu-core and ubuntu-core-system-image
[12:24] <Laney> yes indeed, there is
[12:24] <Laney> so maybe this can be cleaned up now?
[12:25] <Laney> also the broken indentation in that block makes me twitch
[12:25] <ogra_> well, ubuntu-core still builds the ubuntu-core tarballs on cdimage
[12:26] <ogra_> which are used by many projects as cheap chroots
[12:26] <Laney> yes
[12:27] <ogra_> (and i agree about the indendation)
[12:28] <seb128> Laney, it's a vcs and you have commit access, feel free to fix the indent ;-)
[12:29] <Laney> I am doing
[12:29] <seb128> cool
[12:32] <Laney> done, please pull
[12:37] <Laney> mvo: It looks like you've not got LP generating Task: for your seed - intentional?
[12:37] <Laney> I think it'd be feasible to move those manual installations there and then we could merge the desktop-next and core bits
[12:37] <Laney> at least that block
[12:38] <Laney> Maybe there's a project I can file a bug on? :)
[12:49] <mvo> Laney: hm, I have Task headers for some bits, no? what am I missing :) ?
[12:58] <Laney> mvo: e.g. http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-core.wily/view/head:/core-libs-dev don't have them
[12:59] <mvo> Laney: oh,core-libs-dev will go away, sorry. task: ubuntu-core is the one we use
[12:59] <Laney> Maybe so, but those packages don't have Task headers which indicates that ubuntu-core isn't being processed
[13:00] <mvo> Laney: a while ago there was this idea to have core-libs/core-libs-dev so just like ubuntu-sdk-libs/ubuntu-sdk-libs-dev so that we can re-use the click chroots environment. but that never got enaywhere
[13:00] <Laney> it needs to be in lp:ubuntu-archive-publishing scripts/cron.germinate
[13:00] <mvo> Laney: there are a bunch of packages with a ubuntu-core header, no?
[13:00]  * mvo is probably confused
[13:04] <Laney> mvo: Seems to come from ubuntu.wily/system-image seed
[13:04] <Laney> is that your thing?
[13:22] <rickspencer3> didrocks, so, ironically, I think I am getting punished for not using umake
[13:23] <rickspencer3> I tried writing some Go code and go build kept complaining that certain members weren't in a certain class
[13:23] <rickspencer3> I assume this is because I have an out of date Go from the archives and need to use ubuntu make to get the fresh stuff ;)
[13:25] <didrocks> rickspencer3: not sure if I should \o/ in some way :p
[13:25] <rickspencer3> lol
[13:26] <rickspencer3> didrocks, brace yourself, I may come back and ask for help with umake :)
[13:26]  * didrocks is away for a long long time ;)
[13:28] <davmor2> didrocks: not sure that's what rickspencer3 meant when he said brace yourself :p
[13:28] <didrocks> davmor2: I will argue "ENOTNATIVESPEAKER"
[13:30] <davmor2> hahaha
[13:30] <Sweet5hark1> didrocks: that one is always helpful
[13:31] <davmor2> didrocks: you speak better English than I do French so that doesn't wash sorry ;)
[13:32] <mvo> Laney: yes
[13:33] <mvo> Laney: sorry for the delay, meeting
[13:33] <Laney> no worries
[13:33] <didrocks> davmor2: what do you mean? j/k ;)
[13:39] <Laney> larsu: do you want to try to get https://code.launchpad.net/~larsu/ubuntu-themes/overlay-scrollbars in?
[13:39]  * Laney hasn't tried it yet, mind
[13:40] <seb128> Laney, that has issues, progressbar have no bg with it
[13:40]  * seb128 tried it
[13:40] <Laney> oh right, did you report that already?
[13:40] <seb128> IRC report :p
[13:40] <seb128> larsu confirmed/said he would have a look
[13:41] <Laney> ok
[13:44] <larsu> what seb128 said
[13:45] <seb128> oh, other gtk316 issue
[13:46] <seb128> in nautilus sidebar, the equivalent of ~1.3 rows of space is empty at the bottom
[13:47] <seb128> http://people.canonical.com/~seb128/nautilus.png
[13:47] <seb128> oh, also
[13:47] <seb128> gnome-tetravex: /usr/@DATADIRNAME@
[13:48] <seb128> wth!
[13:48]  * seb128 looks at that
[13:51] <larsu> looks like the undershoot rule doesn't apply there...
[13:51] <seb128> larsu, speaking about which issue?
[13:51] <seb128> weird, the gnome-tetravex debs in Debian don't have the issue and we are in sync
[13:52] <seb128> different intltool or something?
[13:52] <larsu> seb128: nautilus
[13:53] <seb128> larsu, undershoot, is that having to do with the scrolling overshoot?
[13:53] <seb128> or...?
[13:53] <seb128> do you see the issue as well?
[13:54] <larsu> seb128: yes, undershoot is when there's more content at an edge. I see the issue too (haven't until now because my nautilus is usually large enough)
[13:54] <Laney> seb128: can you file a "gtk316" bug so it doesn't get lost?
[13:54]  * Laney has trying the 3.16 update on the list
[13:54] <larsu> gtk316 assignee:larsu :(
[13:54] <Laney> maybe that fixes it :)
[13:55] <Laney> jhbuild run nautilus doesn't work :(
[13:56] <larsu> Laney: is the nautilus on your system still running?
[13:56] <seb128> larsu, Laney, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1463848
[13:57] <larsu> seb128: thanks
[13:57] <Laney> thx
[13:58] <seb128> yw!
[13:58] <Laney> larsu: I quit it first, it's an assertion failure
[13:58] <larsu> uh oh
[13:59]  * Laney tries the 3-16 branch
[13:59] <seb128> is calling nautilus -q or nautilus from a command line also giving you
[13:59] <seb128> gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
[13:59] <seb128> GLib-GObject-WARNING **: invalid (NULL) pointer instance
[13:59] <seb128> g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
[14:00] <Laney> no
[14:01] <seb128> :-/
[14:57] <seb128> Laney, can you retry deskotp-next on amd64? want to see if the livecd-rootfs update made a difference there
[15:10] <seb128> Laney, I see what you are trying to do :p
[15:10] <seb128> thanks
[15:10] <Laney> fail
[15:10] <Laney> I guess I have to still do it >:(
[15:11] <seb128> meanwhile can you start a build? I would like to see the result before going off for tennis in ~1.5 hours
[15:11] <Laney> running
[15:11] <seb128> thanks
[15:18] <popey> willcooke: in your mail you suggested installing unity8 on desktop, what method would you recommend? (I'm on Wily on my Intel laptop)
[15:19] <popey> willcooke: tbh I'd rather not install on my main machine simply because then it means flip / flopping between two sessions (unity7 and 8)
[15:19] <popey> willcooke: would way rather have a machine dedicated to this so I can continue working / file bugs / build clicks etc on main machine while doing testing on second machine.
[15:19] <willcooke> and we'd rather not rework everything we've done to get the U8 snappy image out ;)
[15:20] <popey> well it was clearly prematurely expired, surely? given we have a requirement for click based desktop
[15:21] <willcooke> who is we?
[15:21] <willcooke> How about this:  https://wiki.ubuntu.com/Unity8inLXC
[15:21] <popey> that is broken here :(
[15:22] <popey> i get a blank screen when i login to that unity8 session
[15:23] <willcooke> is blank screen this:  https://bugs.launchpad.net/ubuntu/+source/unity8-lxc/+bug/1383497
[15:23] <seb128> popey, we never had a click based desktop and I don't see how that would work, click is a good simplified format to distribute apps, it's not something you build a desktop from
[15:23] <popey> I dont mean click distributed desktop
[15:23] <popey> I mean, a desktop build which is similar in setup to the phone build
[15:23] <popey> which is based off debian packages and click packages
[15:24] <popey> which I truncated as "click based" sorry.
[15:24] <seb128> desktop-next was not different from install unity-desktop-session-mir on your normal wily and logging into that from the login manager
[15:24] <seb128> why can't you just do that?
[15:24] <seb128> installing*
[15:37] <willcooke> qengho, you around?
[16:16] <seb128> mvo, same error with the kernel flavor set :-/
[16:16] <seb128> https://launchpadlibrarian.net/208754412/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz
[16:16] <seb128> cp: target '/tmp/tmp.nawPuZ1kD7/assets/vmlinuz' is not a directory
[16:17] <seb128>  cp -ar boot/vmlinu?-* $TMPDIR/assets/vmlinuz
[16:17] <seb128> wonder if the *uefi/signed variants don't make several matches to "boot/vmlinu?-*"
[16:18] <seb128> should have added a ls debug line in there, I was pondering doing that for that upload
[17:37]  * willcooke -> EOD 
[18:22] <mvo> seb128: meh, :( is the script run with set -ex ? but I guess thats not helpful
[18:22] <mvo> seb128: we really need a livecd-rootfs that can run locally
[18:22] <mvo> (IMNSHO)
[18:26] <ogra_> mvo, i was pondering to update rootstock-ng ... that runs it locally
[18:27] <mvo> ogra_: I wonder if there is anything that blocks getting that support for upstream livecd-rootfs
[18:28] <ogra_> mvo, it is a complex setup if you want to do the same as the buildd does (stacked chroots in onion model)
[18:28] <mvo> ogra_: right, still…
[18:30] <ogra_> mvo, well, there is the BuildLiveCD.sh script upstream
[18:30] <mvo> ogra_: aha, part of live-build?
[18:30] <ogra_> which is essentially the thing that gets executed on the buildd
[18:30] <ogra_> no, part of livecd-rootfs
[18:31] <ogra_> but that doesnt help you since you need to first get the setup in place that LP does when provisioning the buildd
[18:31] <ogra_> (which is what rootstock-ng does)
[18:32] <mvo> ogra_: yeah, I write some code for this a long time ago and then it didn't get anywhere and I lost interesst :/ but everytime I need to debug a failure I whish I hadn't
[18:33] <ogra_> mvo, well, as i said, its probably just 10min of work to update rootstock-ng and make it build wily images (and to build core instead of the hardcoded touch)
[18:33] <ogra_> i wrote it in a way (explicitly) to not be a generic tool
[18:33] <ogra_> would just need some generalizing again
[18:49] <rsalveti> "funny" how we keep having this same issue over and over and over
[18:58] <ogra_> yeah
[20:49] <Noskcaj> Laney, Would you mind syncing gjs from exp now you've uploaded it to there?
[20:49] <Laney> I'm certainly going to do that, can't right now though
[20:50] <Noskcaj> ok
[20:52] <Laney> LP needs to know about it first
[23:32] <robert_ancell> Laney, I was about to track down how to sort out the libpeas / Debian Python issue - thanks for doing that.