[06:42] good morning [07:06] good morning [07:14] hey fgimenez: I think I've tried it all to get this working: https://code.launchpad.net/~elopio/snappy/go-tests5/+merge/262418 [07:14] no luck. [07:14] elopio, hey still around? np, i'll take a look [07:22] elopio, the first time i tried i was getting http://paste.ubuntu.com/11739031/ did you get something like that? [07:31] elopio, i'll merge your changes and we can work from there [07:38] fgimenez: yes, I can't sleep when I get stuck. [07:38] and yes, that's what I get when I try to sbuild. [07:56] elopio, nw, i'll give it another try, go and get some sleep! :) === mvo_ is now known as mvo [08:34] Good morning all; happy Friday, and happy Sauntering Day! 😃 [08:42] * Chipaca saunters off to get coffee [08:57] fgimenez: yes, I'm going to sleep now. [08:57] I got adt-run working on my beagle. The tests don't pass, but they run. [09:03] elopio, awesome!! thx a lot, we'll talk later [09:30] * Chipaca now in wily \o/ [09:30] crazy [09:33] Chipaca: yay! [09:33] Chipaca: its much more fun this way, isn't it :-D [09:36] well, awesome changed its configuration in incompatible ways (new lua, i guess), so that was fun [09:36] but at least it wasn't xmonad :) [09:39] ogra_: not at all crazy; if i didn't do this, how could i be condescending to people running old software? [09:39] in bad faith, that's how [09:39] lol [09:40] hmm [09:40] so how does snappy work [09:40] how do you build the os snap [09:40] is it based on debootstrap [09:40] followed by rm -rf /var/lib/dpkg [09:40] or is it something entirely different [09:41] live-build builds it [09:41] I'm trying to understand if contributions to ubuntu archive have an impact on spappy [09:41] based on config and extra scripts that live in livecd-rootfs [09:41] ahh [09:41] offspring lives forever, it seems ;-) [09:42] is that stable or constantly evolving? [09:42] http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ [09:42] like the scripts that do magic after the base packages are installed [09:42] no, luckily it isnt offspring or anyhow related [09:42] sadly though to make parts of it offspring compatible we had to re-write the whole infra around it in python ... since then it got really hard to maintain [09:43] * ogra_ is still grumpy about that after years ... makes life so much harder ... [09:43] ogra_: is there a high-level description of what goes into the os snap? [09:43] * ogra_ shakes his fist at cody-sommerville in absence [09:43] ogra_: (what was it written in originally?) [09:43] ;D [09:44] * zyga still has that memory of cody [09:44] driking only after you are 21 and all that ;-) [09:44] fun days [09:44] yeah, he was nagfging about the re-write for two years or so ... then the rewrite itself took about 6 months ... and just as it was done he left ! [09:44] ogra_: I'm trying to picture this against debootstrap [09:45] live-build uses debootstrap [09:45] ogra_: to understand where my assumptions are wrong, etc, [09:45] for the initial chroot ... [09:45] ogra_: is there any input to the whole process other then the packages? [09:45] and then installs/removes and modifys packages as needed [09:45] "modifies"? [09:45] yes, there are chroot hooks that get run [09:46] sure [09:46] (it doesnt modify anything for the deb based images indeed, only for stuff that doesnt use dpkg at the enduser) [09:48] ogra_: thanks [09:48] ogra_: so the os snap is a preinstalled chroot [09:48] ogra_: with some cherries on top [09:50] zyga: also keep in mind the split between os, kernel and device snap [09:50] so not the whole chroot [09:51] zyga, apt-get source livecd-rootfs ... live-build/auto/build and live-build/auto/config have the generic build parts ... live-build/ubuntu-core/hooks has the extra scripts [09:51] for some value of "generic" [09:51] (SCNR) [09:52] * Chipaca always thinks of french trains when he reads SCNR [09:53] zyga, and built in a special way (i think we use --buildd-minimal or some such for deboostrap, the apt policy doesnt install recommends and so on) [09:55] Chipaca: s/device/gadget/ right [09:55] zyga: yes indeed [09:56] right [09:58] * ogra_ wonders if bug 1466672 isnt actually a feature :) [09:58] bug 1466672 in Snappy "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,New] https://launchpad.net/bugs/1466672 [09:59] though i guess it should print some meaningful error message in the log [09:59] "cant run network service with no network attached" or some such === devil is now known as Guest90150 [10:03] ogra_: hmm, why should webm not start? [10:03] zyga, it runs an avahi daemon ... what should that attach to with no network up ? [10:21] ogra_: nothing, but then the avahi daemon will attach to each network as it shows up [10:22] ogra_: one of the bad things about many linux gizmos is that they misbehave if you boot without network and plug network later [10:34] yep [11:41] Chipaca: quick brainstorm - what additional meta/meta.yaml do we need that is not part of the package.yaml. I have "origin" (mvo, sideloaded) on my list right now, what else will we want to store here? === dholbach_ is now known as dholbach [11:45] snap masters, do we have some documentation how to "debug" in snappy... tools but also "strategies", i.e. how to check whether it's an app vs system issue etc [11:47] olli: unfortunately not, its complicated by the fact that we do not have snaps for many of the useful tools (like strace) :/ - do you have a specific example where you need debugging help? maybe that could be the start of such a doc :) [11:48] mvo, mterry & kgunn were holding my hand when creating a qmlscene snap [11:48] got issues loading a lib at runtime [11:48] which is there, suppose the preloader doesn't catch it [11:49] olli: anything in the usual places (dmesg, syslog) - might be somethin with appamror/seccomp [11:49] alrighty [11:52] mvo, are there any existing pointers / docs how to deal with confinement issues, i.e. I see a apparmor denial, what's next? [11:59] olli: could you pastebinit === erkules_ is now known as erkules [11:59] olli: maybe jdstrand has pointeres to the security wiki [12:00] olli, syslog is your best bet [12:00] ogra_, I see the issue, just don't know what to do with it ;) [12:01] mvo, http://paste.ubuntu.com/11739849/ [12:01] olli, you could indee dship things like strace and such in a special version of your snap ... i.e. $app-debug.snap ... so that you could have these tools apply to the startup wrappers [12:01] that's the runtime err [12:02] and that's dmesg | tail -n 10 http://paste.ubuntu.com/11739855/ [12:04] olli, well, your app should ship its own /usr/share/applications ... or wait until that setup can be provided by some framework [12:04] (wrt the DENIED messages there) [12:04] ogra_, don't even know what it's trying to access there [12:04] what's the best strategy to figure out what it's trying to access so I can bundle that stuff? [12:05] well, you likely want to look at the code of your app then :) [12:05] it might just want to read the .desktop file [12:05] (which usually live in that dir) [12:07] you are suggesting I read all of Qt? [12:07] mvo: i'm afraid i didn't pay too much attention, but (or because) sergio did :) [12:07] all of qmlscene code i guess [12:08] Chipaca: what did I do again? [12:08] should kvm be bringing up an eth0? [12:08] sergiusens: what additional meta/meta.yaml do we need that is not part of the package.yaml. I have "origin" (mvo, sideloaded) on my list right now, what else will we want to store here? [12:08] Chipaca: I had this problem with latest wily too, no eth0 [12:08] sergiusens: ^^ that was mvo asking, earlier today [12:08] Chipaca: rollback to a previous version worked [12:08] Chipaca: part of meta/package.yaml? [12:09] Chipaca, sergiusens: maybe its not relevant anymore my question, I'm drafting the FHS [12:09] sergiusens: i think he's asking about _$version [12:09] * Chipaca translates [12:09] mvo: if Chipaca's idea flies wrt dynamic creation f manifest.yaml from store data we need... [12:11] Chipaca: mvo video and screenshot url (and maybe even the shots), release is rather important (to deal with upgrades), icon downloaded, binary_filesize (which is the download size), developer name, company name, website, price, publish date, download sha [12:11] mvo: Chipaca and reviews would be one of those on demand queries [12:12] download sha is of little sense if we explode the package and expose hashes.yaml [12:12] oh, and changelog [12:13] and one of the bigger things coming our way, the translations entry [12:13] sergiusens: indeed [12:13] * sergiusens feels he just made too much words to just say everything [12:14] mvo: Chipaca I think we will be putting this in _$versions initially and then move over to the dynamically created manifest.yaml [12:15] we can have a hangout to go over it and get the big picture [12:15] I just need to cut off 30' after standup today though and then I'll be back by your bed/beer o clock ;-) [12:16] who's working on translations? i'd like to add my 2¢ to that work [12:16] Chipaca: the store already has that option [12:16] on the client [12:17] i don't mind if the store loads all translations in memory [12:17] Chipaca: and then you get a translations entry in the json [12:17] because it's the store :) [12:17] Chipaca: no one is yet [12:17] Chipaca: there's only mvo's branches which I'll look at again now [12:17] sergiusens, mvo, hey, maybe you know, but how/when is the "cdimage build" to "channel image" conversion done? is that a cron job? or does it trigger when need cdimage build are done? [12:17] seb128: all of Ubuntu's infra is poll based :) [12:17] seb128: system-image.u.c is doing that, its a cron job that runs every 5min [12:18] that was a snarky smiley [12:18] seb128: but it can run for a long time [12:18] seb128: so the 5min is not accurate [12:18] Chipaca: what specifically do you have in mind? other than adding gettext ? how to requested the languages from the store? [12:18] mvo, it's like the publisher, 5 minutes if there are not previous job overunning right? [12:18] sergiusens, mvo, thanks [12:18] seb128, see the crontab on nusakan [12:18] seb128: btw, I still get reboot loops with amd64 and i386 just stalls during boot [12:19] seb128, last line ... [12:19] seb128: and the personal branch made it to trunk btw [12:19] ogra_, thanks [12:19] (well, the crontab of the cdimage user that is) [12:19] sergiusens, \o/ for personal to trunk [12:19] mvo: translations of snappy itself i'm less worried about; gettext already uses one-file-per-language and is (or was when i looked at it) fairly smart wrt not using more memory than it had to to hold unused translations [12:19] sergiusens, amd64 boots since yesterday for me, it just loops on lightdm [12:19] sergiusens, oh, you need to pick the "ubuntu" entry in grub [12:20] mvo: my fear is if we dump app-side translations into a single json or yaml or what have you, we'll load it all in memory all the time always [12:20] not the snappy system-a one [12:20] sergiusens, unsure why there are those different ones [12:20] sergiusens, I hope that with this morning fixes and the new image build we get lightdm to work [12:20] * ogra_ glares at jonos last blog post ... [12:20] ... insane [12:21] (he suggests we rebase ubuntu on android) [12:21] seb128: we are working on getting rid of update-grub fwiw and have very fine tuned grub.cfg's [12:21] ogra_: oh no! the person we were taking technical leadership from has lost their mind! what can we do?!? [12:21] ogra_: oh, wait [12:21] haha [12:21] well, we'd finally get all the great android security ! [12:22] and their battery life too ... [12:22] and their juicy, juicy init system [12:22] oh, yeah ! [12:22] Chipaca: I prefer manifest_en-ES.yaml or something like that [12:22] or dir separated [12:22] bright the future would be [12:22] Chipaca: yeah, good point [12:22] :) [12:22] whatever makes sense [12:22] * sergiusens wants the init system [12:23] uuuh [12:23] and the on disk initrd [12:23] thats the only one thing i like in android [12:23] (though there is prior art to that in the terminal server area) [12:23] sergiusens, so for your reboot loop, what grub item do you select? [12:23] seb128: I just let the first one to go and go and go, didn't do any manual selection [12:24] sergiusens, btw I keep hitting the loop partition error, unsure why, I need to reboot and retry, it works like 1 every 10 tries, same on my 2 machines :-/ [12:24] sergiusens, k, you need to pick "ubuntu" in the list, that's not the top one [12:24] seb128: did you try the losetup -d command? [12:25] yes [12:25] but I had deleted the .img when I tried [12:25] and losetup -d didn't seem to work [12:25] loop0 was still listing the deleted image [12:25] kpartx ;) [12:26] and dmsetup ... [12:26] and users should have to do that [12:26] it defaults to a device-manager setup iirc [12:26] the tools should do it for them if that's needed [12:26] ogra_: yeah dmsetup clear /dev/mapper/loop0p* ; kpartx -ds /dev/loop0; losetup -d /dev/loop0 [12:26] right [12:26] seb128: the dmsetup and kpartx parts are done [12:27] seb128, yeah, it is a bug that the tool does stop before being able to cleanup [12:27] seb128: the losetup isn't, which is why I asked if it helped [12:27] * ogra_ hugs the trap function in shell [12:27] ogra_: it is being run, if it was mapped, the unmapping always runs [12:27] seb128 try trunk [12:28] well, it didnt for me when we had the issue recently [12:28] sergiusens, k, going to try in a bit [12:28] sergiusens, but no, losetup didn't help when I tried [12:28] i had to use dmsetup each time after the error [12:28] but typically I used the tools, hit the error, rm-ed the .img [12:28] ogra_: hmm, sometimes dmsetup doesn't work for me either [12:28] in which point loop0 is blocked on the deleted img and losetup seems to do nothing [12:29] ogra_, the same invalid partition count loop error? [12:29] ogra_: and I indeed need to reboot and there is no way out of it that I know of [12:29] k, so I'm not alone in the situation ;-) [12:29] for me dmsetup always worked after making sure i loosely unmounted [12:29] loosely unmounted what? [12:29] how? [12:30] umount -l [12:30] (the image) [12:30] k, I guess my error was to delete the buggy img [12:30] to run the command again [12:30] then reboot is needed [12:30] ah, yeah, but umount -l should still work, ebven with the image gone [12:30] I'm going to try next time [12:31] but why are we hitting those issues in the first place? [12:31] was is flacky? [12:31] (it will just alter mtab and /proc/mounts ... ) [12:52] ogra_: you know how the latest wily things aren't bringing up network in kvm? [12:52] ogra_: it's because eth0 is now ens3 [12:52] Chipaca, nope, havent heard of that [12:52] ah, blame pitti ! [12:52] yep yep [12:52] i already do [12:52] always [12:53] ogra_: i'm not sure why i pinged you, but i thought maybe you'd have ideas as to how to fix it :) [12:53] the problem is, of course, that we ship an eth0 interfaces file [12:53] when it should be ... something else, i presume [12:53] mvo: the good news is, there's an easy workaround to get your kvm wily image working again wrt network [12:54] elopio: ^ et vous [12:54] Chipaca, well, if i knew where that file comes from ... [12:55] sergiusens: /etc/network/interfaces.d/eth0 is written by u-d-f [12:55] ogra_: ^ i mean you [12:55] no way for u-d-f to know the name of the device though [12:58] Chipaca: huh? [12:58] Chipaca: are you not reading code used by the ubuntu-emulator by any chance? [12:58] sergiusens: goget-ubuntu-touch/diskimage/customization.go [12:59] Chipaca: yeah, that's ubuntu-emulator [12:59] ah [12:59] sorry then :) [12:59] where does that eth0 file come from then? [13:00] Chipaca: on a kvm image? [13:00] sergiusens: yes [13:00] i would suspect something like ubuntu-core-config [13:00] or a systemd unit thats shipped somewhere [13:01] ogra_: Chipaca doesn't look lke ucc http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/ubuntu-core-config/wily/files/head:/etc/ [13:02] Chipaca: ogra_ dpkg -S says no one owns it [13:02] sergiusens, Chipaca: so gdoc looks mostly sane? I'm a bit torn on /data for system data vs /home/system/data [13:02] live-build/ubuntu-core/hooks/04-configure_network.chroot [13:03] there is is i think [13:03] http://paste.ubuntu.com/11740076/ [13:03] mvo: I don't like either; it seems /writable/data works better and rids us of a bind mount [13:04] * sergiusens wants to just move all refs to /writable [13:05] sergiusens: hm, we would still need the bind mount, unless we move /home/* to /writable/user-data/* (which is probably a good idea in itself) [13:06] Chipaca, hmm, i fear we need to move that to the boot somehow to detect the actual interface names now [13:06] * Chipaca wonders why /writable isn't /var [13:06] mvo: I don't mind /writable/home either ;-) [13:06] Chipaca: because /var has a lot of read only stuff :-P [13:07] maybe /therealvar works bettwe [13:07] *better even [13:07] sergiusens: it doesn't have that much read only stuff that we don't want to get rid of [13:08] Chipaca, hyterical raisins ... on android we have /userdata and needed to use that due to not being able to change partitioning on some devices [13:08] it's 14M, of which 12M is dpkg/info [13:09] Chipaca: that can be killed, we could do that right now via livecd-rootfs [13:09] (and we need to share the writable bits with the android container since many bits need to be accessibe by both OSes) [13:09] anyway, in the sense that /writable is /var without the things that shouldn't be in /var anyway, we wouldn't be the first unix-like people to put homes in var anyway [13:09] s/neede/need/ [13:09] * ogra_ always has home in var on his servers [13:09] since over a decade :) === Guest90150 is now known as devil__ === devil__ is now known as devil_ [13:10] Chipaca: ogra_ fwiw, latest images left me without networking on kvm as well [13:10] ogra_: i don't know if that should be seen as encouragement or a sign of trouble [13:10] but that wouldnt help the HW requirements android puts upon us on personal [13:10] sergiusens: yes, because of the above [13:10] sergiusens: you do have networking, you just don't know it :-p [13:10] or rather the setup reqs. not the HW reqs [13:10] we cant change paths of binary blobs [13:10] sudo sed -i -e "s/eth0/$(ls /sys/class/net/ | grep -vx lo | head -n1)/g" /etc/network/interfaces.d/eth0 [13:10] sergiusens: ^ [13:10] sergiusens: and reboot [13:11] mvo: Chipaca let's do that now (remove /var/lib/dpkg) before more people exploit it and then becomes a req to have [13:11] sergiusens: or restart networking, but reboot is quicker without ocmpletion :-p [13:11] sergiusens: +1.33 [13:11] sergiusens, yes, we hardcode the interface name in livecd-rootfs (pretty bad idea) [13:11] * Chipaca is going to run out of .33's if people carry on having good ideas [13:11] Chipaca: oh, the iface name change reached us [13:11] cant we remove dpkg altogether ? [13:12] even the binary [13:12] the whole thing, afaik [13:12] ogra_: yes we CAN! [13:12] although elopio will be sad [13:12] JUST DOIT ! [13:12] we can even remove dpkg-deb [13:12] JUST DOIT ! [13:12] :) [13:12] fuck yeah! break things on fridays! [13:12] Chipaca: right, but the reason we can't remove it on the phone is beacuase QA became entrenched with it [13:12] and it isn't even beer o'clock [13:12] on edge ... [13:13] remove it yesterday, then [13:13] living on the edge you can fall at times :) [13:13] * Chipaca puts on a bit of aerosmith [13:13] there https://www.youtube.com/watch?v=7nqcL0mjMjw [13:13] * ogra_ headbangs [13:15] pitti: you around? wondering if you have bright ideas wrt figuring out the name of the first network device now that it's not static [13:15] pitti: currently we have a (now non-functional) static file that brought up eth0 with dhcp [13:16] Chipaca: dmesg|grep eth [13:16] mvo: see above for sed that works :) [13:16] Chipaca: oh, sorry [13:17] Chipaca: what is "static" in this context? [13:17] mvo: asking because we can't be the first ones, so maybe there's already a known-good soltion [13:17] mvo: otherwise we can cook :) [13:17] * mvo nods [13:17] mvo, livecd-rootfs http://paste.ubuntu.com/11740076/ ... [13:17] but interface names are dynamic now ... on boot ... [13:17] pitti: livecd-rootfs writes /etc/network/interfaces.d/eth0 with allow-hotplug eth0\niface eth0 inet dhcp [13:18] pitti: see ogra's pastebin for the code that writes it out [13:18] Chipaca: I think apparmor may break without dpkg, the aa-clickhook was iirc calling dpkg for something [13:18] so we need to move the file cration somewhere into the boto process [13:18] *boot [13:18] after we know the name [13:18] ogra_: no, no boto! jdstrand will get upset [13:18] Chipaca: and what is "first"? [13:18] haha [13:18] Chipaca: for ethernet, pick any match in /sys/class/net/en* [13:18] Chipaca: I guess in many cases there will be just one, but as the old persistant-net-generator just randomly picked one to become eth0, you can also just pick the asciibetically first one [13:18] i. e. ls /sys/class/net | head -n1 [13:18] ? [13:19] pitti: good to know they're en* [13:19] pitti, is that generator gone ? [13:19] just out of curiosity, why is it erenamd in the first place? [13:20] dmesg tells me it was eth0 before and then got renamed [13:20] * ogra_ wonders if we could abuse it to create an alias name for the moment ... as quick fix) [13:20] Chipaca: yes, and wlan is wl* [13:20] mvo: i assume, because it's fake anyways, and at least this way it's consistent and you can find it in /sys/ and elsewhere, but i don't know :) [13:20] i think there are three different names for the device? or something like that [13:20] but only one that works with ifconfig it seems [13:21] sergiusens, mvo, so we had a new build on https://launchpadlibrarian.net/209509553/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz a bit over an hours ago [13:21] ogra_: yes, see https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038786.html [13:21] I just created a personal image using udf, but that seems to have given me an outdated version [13:21] like ubuntu-core-config was not at 0.22 which it is in this log ^ [13:21] is that normal? [13:21] mvo: i mean, the same device is called (potentially) different things in different parts of the system [13:21] pitti, "this wont affect upgrades" ... also on readonly system-image installs ? :) [13:22] is there a way to check if there a channel image update ongoing and what's the status? [13:22] Chipaca: your sed will also catch wlan, wwan, vlan, and other devices -- I suppose you don't want that, or do you? (I said en* as you had eth0 before) [13:22] (where the upgrade is actually replacing bits of the system instead of using dpkg) [13:22] pitti: the sed was strictly just for our images, running in kvm [13:22] pitti: not a general solution [13:22] ogra_: well, upgrades in the apt sense :) [13:22] pitti, right [13:22] seb128: there are logs on nusakan, but I don't recall where to find them [13:22] so it will break phones and snappy [13:22] we can't have maintscripts on s-i upgrades [13:22] we need to take that into account i guess [13:22] mvo: fyi, click-apparmor doesn't care about anything dpkg-y per se. we have this (rather crappy) mechanism for system-image based systems to discover when click-apparmor (and apparmor and ubuntu-core-snappy-apparmor and apparmor-easyprof-ubuntu) is updated that looks at the dpkg debsums [13:23] ogra_, you might know (logs on nusakan) [13:23] ogra_: how so? there we wouldn't have a writable /etc/ anyway, do we? i. e. we couldn't write the persistant rules? [13:23] seb128, rootfs build ? [13:23] or firewall rules and stuff which refer to the names? [13:24] pitti, well, on phones it might not be an issue ... NM cares for the interfaces [13:24] ogra_, no, wondering how to know when the image from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next is going to make it into the personal channel [13:24] mvo: the idea is that goes away when snappy stops using aa-clickhook, but we need to figure out another mechanism for detecting these things [13:24] seb128, /srv/cdimage.ubuntu.com/log/ [13:24] ogra_, it built over an hour ago and I just use udf to build and image but get the old content [13:24] ogra_: right, and NM doesn't care about the name [13:24] ogra_, in fact I don't have ssh access to that box so nevermind, I can't look there [13:24] seb128, there is no logging for system-image [13:25] (at all) [13:25] I guess I just have to wait and retry? [13:25] only for cdimage and livefs builds [13:26] version is at 10, I guess I need a 11... [13:26] sergiusens, mvo, you are sure channel images are autoupdated? [13:26] seb128: well, slangasek said he added it to the list [13:27] seb128: once it's in the list for consumption, it's automatic; only reason it failed could be due to an error [13:27] slangasek, hey [13:27] seb128: import-image is still running [13:27] mvo, how long does that take? [13:27] mvo, is there some UI where I can see the status? [13:27] seb128: TMPDIR=/srv/system-image.ubuntu.com/tmp /srv/system-image.ubuntu.com/bin/import-images -vvvv [13:27] 2015-06-19 13:27:14,522 INFO Something else holds the global lock. exiting. [13:27] seb128: from http://system-image.ubuntu.com/ubuntu-personal/rolling/edge/generic_amd64/index.json it seems it was last updated today [13:27] sergiusens, today this morning or today an hour ago? [13:27] seb128: lsof -p 4196 tells me there is no log [13:28] seb128: very early Fri Jun 19 06:02:00 UTC 2015 [13:28] sergiusens, k, so likely the daily build, no the retry with the fixes from this morning [13:28] maybe the phone guys are fooling around with s-i? [13:28] mvo, is that lock warning something I should be concerned about? ;-) [13:28] seb128: no, it means its working [13:29] k [13:29] seb128: ls -lh /srv/system-image.ubuntu.com/tmp/tmpSW4IWr/ [13:29] total 3.2G [13:29] -rw-rw-r-- 1 cdimage cdimage 1.8G Jun 19 13:20 source.tar [13:29] -rw-rw-r-- 1 cdimage cdimage 1.4G Jun 19 13:28 target.tar [13:29] * seb128 waits then [13:29] seb128: that might help [13:29] big images with s-i :) [13:29] mvo, thanks [13:29] * seb128 would like to see an image booting before eow! [13:29] seb128: but I share your pain, +1 for logs [13:29] and super tight xz compression levels [13:29] seb128: you have 2.5 more days ;) [13:30] mvo, lol [13:31] 4196 ? R 28:56 /usr/bin/python /srv/system-image.ubuntu.com/bin/import-images [13:31] runs since 30min [13:32] (or rather "had 30min f CPU cycles) [13:32] *of [13:33] f works too [13:34] short for the same thing as it was in fvwm [13:35] mvo: golang-gettext-dev is not in the archives yet [13:36] sergiusens: I guess some archive admin needs to get active [13:36] sergiusens: like seb128 … [13:36] heh :-P [13:36] lol [13:36]