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