| dholbach | good morning | 06:42 |
|---|---|---|
| fgimenez | good morning | 07:06 |
| elopio | 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 |
| elopio | no luck. | 07:14 |
| fgimenez | elopio, hey still around? np, i'll take a look | 07:14 |
| fgimenez | elopio, the first time i tried i was getting http://paste.ubuntu.com/11739031/ did you get something like that? | 07:22 |
| fgimenez | elopio, i'll merge your changes and we can work from there | 07:31 |
| elopio | fgimenez: yes, I can't sleep when I get stuck. | 07:38 |
| elopio | and yes, that's what I get when I try to sbuild. | 07:38 |
| fgimenez | elopio, nw, i'll give it another try, go and get some sleep! :) | 07:56 |
| === mvo_ is now known as mvo | ||
| JamesTait | Good morning all; happy Friday, and happy Sauntering Day! 😃 | 08:34 |
| * Chipaca saunters off to get coffee | 08:42 | |
| elopio | fgimenez: yes, I'm going to sleep now. | 08:57 |
| elopio | I got adt-run working on my beagle. The tests don't pass, but they run. | 08:57 |
| fgimenez | elopio, awesome!! thx a lot, we'll talk later | 09:03 |
| * Chipaca now in wily \o/ | 09:30 | |
| ogra_ | crazy | 09:30 |
| mvo | Chipaca: yay! | 09:33 |
| mvo | Chipaca: its much more fun this way, isn't it :-D | 09:33 |
| Chipaca | well, awesome changed its configuration in incompatible ways (new lua, i guess), so that was fun | 09:36 |
| Chipaca | but at least it wasn't xmonad :) | 09:36 |
| Chipaca | ogra_: not at all crazy; if i didn't do this, how could i be condescending to people running old software? | 09:39 |
| Chipaca | in bad faith, that's how | 09:39 |
| ogra_ | lol | 09:39 |
| zyga | hmm | 09:40 |
| zyga | so how does snappy work | 09:40 |
| zyga | how do you build the os snap | 09:40 |
| zyga | is it based on debootstrap | 09:40 |
| zyga | followed by rm -rf /var/lib/dpkg | 09:40 |
| zyga | or is it something entirely different | 09:40 |
| ogra_ | live-build builds it | 09:41 |
| zyga | I'm trying to understand if contributions to ubuntu archive have an impact on spappy | 09:41 |
| ogra_ | based on config and extra scripts that live in livecd-rootfs | 09:41 |
| zyga | ahh | 09:41 |
| zyga | offspring lives forever, it seems ;-) | 09:41 |
| zyga | is that stable or constantly evolving? | 09:42 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ | 09:42 |
| zyga | like the scripts that do magic after the base packages are installed | 09:42 |
| ogra_ | no, luckily it isnt offspring or anyhow related | 09:42 |
| ogra_ | 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:42 |
| * ogra_ is still grumpy about that after years ... makes life so much harder ... | 09:43 | |
| zyga | 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 | |
| zyga | ogra_: (what was it written in originally?) | 09:43 |
| zyga | ;D | 09:43 |
| * zyga still has that memory of cody | 09:44 | |
| zyga | driking only after you are 21 and all that ;-) | 09:44 |
| zyga | fun days | 09:44 |
| ogra_ | 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 |
| zyga | ogra_: I'm trying to picture this against debootstrap | 09:44 |
| ogra_ | live-build uses debootstrap | 09:45 |
| zyga | ogra_: to understand where my assumptions are wrong, etc, | 09:45 |
| ogra_ | for the initial chroot ... | 09:45 |
| zyga | ogra_: is there any input to the whole process other then the packages? | 09:45 |
| ogra_ | and then installs/removes and modifys packages as needed | 09:45 |
| zyga | "modifies"? | 09:45 |
| ogra_ | yes, there are chroot hooks that get run | 09:45 |
| ogra_ | sure | 09:46 |
| ogra_ | (it doesnt modify anything for the deb based images indeed, only for stuff that doesnt use dpkg at the enduser) | 09:46 |
| zyga | ogra_: thanks | 09:48 |
| zyga | ogra_: so the os snap is a preinstalled chroot | 09:48 |
| zyga | ogra_: with some cherries on top | 09:48 |
| Chipaca | zyga: also keep in mind the split between os, kernel and device snap | 09:50 |
| Chipaca | so not the whole chroot | 09:50 |
| ogra_ | 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 |
| mvo | for some value of "generic" | 09:51 |
| mvo | (SCNR) | 09:51 |
| * Chipaca always thinks of french trains when he reads SCNR | 09:52 | |
| ogra_ | 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:53 |
| zyga | Chipaca: s/device/gadget/ right | 09:55 |
| Chipaca | zyga: yes indeed | 09:55 |
| zyga | right | 09:56 |
| * ogra_ wonders if bug 1466672 isnt actually a feature :) | 09:58 | |
| ubottu | bug 1466672 in Snappy "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,New] https://launchpad.net/bugs/1466672 | 09:58 |
| ogra_ | though i guess it should print some meaningful error message in the log | 09:59 |
| ogra_ | "cant run network service with no network attached" or some such | 09:59 |
| === devil is now known as Guest90150 | ||
| zyga | ogra_: hmm, why should webm not start? | 10:03 |
| ogra_ | zyga, it runs an avahi daemon ... what should that attach to with no network up ? | 10:03 |
| zyga | ogra_: nothing, but then the avahi daemon will attach to each network as it shows up | 10:21 |
| zyga | ogra_: one of the bad things about many linux gizmos is that they misbehave if you boot without network and plug network later | 10:22 |
| ogra_ | yep | 10:34 |
| mvo | 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? | 11:41 |
| === dholbach_ is now known as dholbach | ||
| olli | 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:45 |
| mvo | 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:47 |
| olli | mvo, mterry & kgunn were holding my hand when creating a qmlscene snap | 11:48 |
| olli | got issues loading a lib at runtime | 11:48 |
| olli | which is there, suppose the preloader doesn't catch it | 11:48 |
| mvo | olli: anything in the usual places (dmesg, syslog) - might be somethin with appamror/seccomp | 11:49 |
| olli | alrighty | 11:49 |
| olli | mvo, are there any existing pointers / docs how to deal with confinement issues, i.e. I see a apparmor denial, what's next? | 11:52 |
| mvo | olli: could you pastebinit | 11:59 |
| === erkules_ is now known as erkules | ||
| mvo | olli: maybe jdstrand has pointeres to the security wiki | 11:59 |
| ogra_ | olli, syslog is your best bet | 12:00 |
| olli | ogra_, I see the issue, just don't know what to do with it ;) | 12:00 |
| olli | mvo, http://paste.ubuntu.com/11739849/ | 12:01 |
| ogra_ | 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 |
| olli | that's the runtime err | 12:01 |
| olli | and that's dmesg | tail -n 10 http://paste.ubuntu.com/11739855/ | 12:02 |
| ogra_ | olli, well, your app should ship its own /usr/share/applications ... or wait until that setup can be provided by some framework | 12:04 |
| ogra_ | (wrt the DENIED messages there) | 12:04 |
| olli | ogra_, don't even know what it's trying to access there | 12:04 |
| olli | what's the best strategy to figure out what it's trying to access so I can bundle that stuff? | 12:04 |
| ogra_ | well, you likely want to look at the code of your app then :) | 12:05 |
| ogra_ | it might just want to read the .desktop file | 12:05 |
| ogra_ | (which usually live in that dir) | 12:05 |
| olli | you are suggesting I read all of Qt? | 12:07 |
| Chipaca | mvo: i'm afraid i didn't pay too much attention, but (or because) sergio did :) | 12:07 |
| ogra_ | all of qmlscene code i guess | 12:07 |
| sergiusens | Chipaca: what did I do again? | 12:08 |
| Chipaca | should kvm be bringing up an eth0? | 12:08 |
| Chipaca | 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 |
| mvo | Chipaca: I had this problem with latest wily too, no eth0 | 12:08 |
| Chipaca | sergiusens: ^^ that was mvo asking, earlier today | 12:08 |
| mvo | Chipaca: rollback to a previous version worked | 12:08 |
| sergiusens | Chipaca: part of meta/package.yaml? | 12:08 |
| mvo | Chipaca, sergiusens: maybe its not relevant anymore my question, I'm drafting the FHS | 12:09 |
| Chipaca | sergiusens: i think he's asking about _$version | 12:09 |
| * Chipaca translates | 12:09 | |
| sergiusens | mvo: if Chipaca's idea flies wrt dynamic creation f manifest.yaml from store data we need... | 12:09 |
| sergiusens | 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 |
| sergiusens | mvo: Chipaca and reviews would be one of those on demand queries | 12:11 |
| sergiusens | download sha is of little sense if we explode the package and expose hashes.yaml | 12:12 |
| sergiusens | oh, and changelog | 12:12 |
| sergiusens | and one of the bigger things coming our way, the translations entry | 12:13 |
| mvo | sergiusens: indeed | 12:13 |
| * sergiusens feels he just made too much words to just say everything | 12:13 | |
| sergiusens | mvo: Chipaca I think we will be putting this in _$versions initially and then move over to the dynamically created manifest.yaml | 12:14 |
| sergiusens | we can have a hangout to go over it and get the big picture | 12:15 |
| sergiusens | I just need to cut off 30' after standup today though and then I'll be back by your bed/beer o clock ;-) | 12:15 |
| Chipaca | who's working on translations? i'd like to add my 2¢ to that work | 12:16 |
| sergiusens | Chipaca: the store already has that option | 12:16 |
| Chipaca | on the client | 12:16 |
| Chipaca | i don't mind if the store loads all translations in memory | 12:17 |
| sergiusens | Chipaca: and then you get a translations entry in the json | 12:17 |
| Chipaca | because it's the store :) | 12:17 |
| sergiusens | Chipaca: no one is yet | 12:17 |
| sergiusens | Chipaca: there's only mvo's branches which I'll look at again now | 12:17 |
| seb128 | 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 |
| sergiusens | seb128: all of Ubuntu's infra is poll based :) | 12:17 |
| mvo | seb128: system-image.u.c is doing that, its a cron job that runs every 5min | 12:17 |
| sergiusens | that was a snarky smiley | 12:18 |
| mvo | seb128: but it can run for a long time | 12:18 |
| mvo | seb128: so the 5min is not accurate | 12:18 |
| mvo | Chipaca: what specifically do you have in mind? other than adding gettext ? how to requested the languages from the store? | 12:18 |
| seb128 | mvo, it's like the publisher, 5 minutes if there are not previous job overunning right? | 12:18 |
| seb128 | sergiusens, mvo, thanks | 12:18 |
| ogra_ | seb128, see the crontab on nusakan | 12:18 |
| sergiusens | seb128: btw, I still get reboot loops with amd64 and i386 just stalls during boot | 12:18 |
| ogra_ | seb128, last line ... | 12:19 |
| sergiusens | seb128: and the personal branch made it to trunk btw | 12:19 |
| seb128 | ogra_, thanks | 12:19 |
| ogra_ | (well, the crontab of the cdimage user that is) | 12:19 |
| seb128 | sergiusens, \o/ for personal to trunk | 12:19 |
| Chipaca | 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 |
| seb128 | sergiusens, amd64 boots since yesterday for me, it just loops on lightdm | 12:19 |
| seb128 | sergiusens, oh, you need to pick the "ubuntu" entry in grub | 12:19 |
| Chipaca | 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 |
| seb128 | not the snappy system-a one | 12:20 |
| seb128 | sergiusens, unsure why there are those different ones | 12:20 |
| seb128 | 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 | |
| ogra_ | ... insane | 12:20 |
| ogra_ | (he suggests we rebase ubuntu on android) | 12:21 |
| sergiusens | seb128: we are working on getting rid of update-grub fwiw and have very fine tuned grub.cfg's | 12:21 |
| Chipaca | ogra_: oh no! the person we were taking technical leadership from has lost their mind! what can we do?!? | 12:21 |
| Chipaca | ogra_: oh, wait | 12:21 |
| ogra_ | haha | 12:21 |
| ogra_ | well, we'd finally get all the great android security ! | 12:21 |
| ogra_ | and their battery life too ... | 12:22 |
| Chipaca | and their juicy, juicy init system | 12:22 |
| ogra_ | oh, yeah ! | 12:22 |
| sergiusens | Chipaca: I prefer manifest_en-ES.yaml or something like that | 12:22 |
| sergiusens | or dir separated | 12:22 |
| ogra_ | bright the future would be | 12:22 |
| mvo | Chipaca: yeah, good point | 12:22 |
| ogra_ | :) | 12:22 |
| sergiusens | whatever makes sense | 12:22 |
| * sergiusens wants the init system | 12:22 | |
| ogra_ | uuuh | 12:23 |
| sergiusens | and the on disk initrd | 12:23 |
| ogra_ | thats the only one thing i like in android | 12:23 |
| ogra_ | (though there is prior art to that in the terminal server area) | 12:23 |
| seb128 | sergiusens, so for your reboot loop, what grub item do you select? | 12:23 |
| sergiusens | seb128: I just let the first one to go and go and go, didn't do any manual selection | 12:23 |
| seb128 | 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 |
| seb128 | sergiusens, k, you need to pick "ubuntu" in the list, that's not the top one | 12:24 |
| sergiusens | seb128: did you try the losetup -d command? | 12:24 |
| seb128 | yes | 12:25 |
| seb128 | but I had deleted the .img when I tried | 12:25 |
| seb128 | and losetup -d didn't seem to work | 12:25 |
| seb128 | loop0 was still listing the deleted image | 12:25 |
| ogra_ | kpartx ;) | 12:25 |
| ogra_ | and dmsetup ... | 12:26 |
| seb128 | and users should have to do that | 12:26 |
| ogra_ | it defaults to a device-manager setup iirc | 12:26 |
| seb128 | the tools should do it for them if that's needed | 12:26 |
| sergiusens | ogra_: yeah dmsetup clear /dev/mapper/loop0p* ; kpartx -ds /dev/loop0; losetup -d /dev/loop0 | 12:26 |
| ogra_ | right | 12:26 |
| sergiusens | seb128: the dmsetup and kpartx parts are done | 12:26 |
| ogra_ | seb128, yeah, it is a bug that the tool does stop before being able to cleanup | 12:27 |
| sergiusens | seb128: the losetup isn't, which is why I asked if it helped | 12:27 |
| * ogra_ hugs the trap function in shell | 12:27 | |
| sergiusens | ogra_: it is being run, if it was mapped, the unmapping always runs | 12:27 |
| sergiusens | seb128 try trunk | 12:27 |
| ogra_ | well, it didnt for me when we had the issue recently | 12:28 |
| seb128 | sergiusens, k, going to try in a bit | 12:28 |
| seb128 | sergiusens, but no, losetup didn't help when I tried | 12:28 |
| ogra_ | i had to use dmsetup each time after the error | 12:28 |
| seb128 | but typically I used the tools, hit the error, rm-ed the .img | 12:28 |
| sergiusens | ogra_: hmm, sometimes dmsetup doesn't work for me either | 12:28 |
| seb128 | in which point loop0 is blocked on the deleted img and losetup seems to do nothing | 12:28 |
| seb128 | ogra_, the same invalid partition count loop error? | 12:29 |
| sergiusens | ogra_: and I indeed need to reboot and there is no way out of it that I know of | 12:29 |
| seb128 | k, so I'm not alone in the situation ;-) | 12:29 |
| ogra_ | for me dmsetup always worked after making sure i loosely unmounted | 12:29 |
| seb128 | loosely unmounted what? | 12:29 |
| seb128 | how? | 12:29 |
| ogra_ | umount -l | 12:30 |
| ogra_ | (the image) | 12:30 |
| seb128 | k, I guess my error was to delete the buggy img | 12:30 |
| seb128 | to run the command again | 12:30 |
| seb128 | then reboot is needed | 12:30 |
| ogra_ | ah, yeah, but umount -l should still work, ebven with the image gone | 12:30 |
| seb128 | I'm going to try next time | 12:30 |
| seb128 | but why are we hitting those issues in the first place? | 12:31 |
| seb128 | was is flacky? | 12:31 |
| ogra_ | (it will just alter mtab and /proc/mounts ... ) | 12:31 |
| Chipaca | ogra_: you know how the latest wily things aren't bringing up network in kvm? | 12:52 |
| Chipaca | ogra_: it's because eth0 is now ens3 | 12:52 |
| ogra_ | Chipaca, nope, havent heard of that | 12:52 |
| ogra_ | ah, blame pitti ! | 12:52 |
| Chipaca | yep yep | 12:52 |
| Chipaca | i already do | 12:52 |
| Chipaca | always | 12:52 |
| Chipaca | 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 |
| Chipaca | the problem is, of course, that we ship an eth0 interfaces file | 12:53 |
| Chipaca | when it should be ... something else, i presume | 12:53 |
| Chipaca | mvo: the good news is, there's an easy workaround to get your kvm wily image working again wrt network | 12:53 |
| Chipaca | elopio: ^ et vous | 12:54 |
| ogra_ | Chipaca, well, if i knew where that file comes from ... | 12:54 |
| Chipaca | sergiusens: /etc/network/interfaces.d/eth0 is written by u-d-f | 12:55 |
| Chipaca | ogra_: ^ i mean you | 12:55 |
| Chipaca | no way for u-d-f to know the name of the device though | 12:55 |
| sergiusens | Chipaca: huh? | 12:58 |
| sergiusens | Chipaca: are you not reading code used by the ubuntu-emulator by any chance? | 12:58 |
| Chipaca | sergiusens: goget-ubuntu-touch/diskimage/customization.go | 12:58 |
| sergiusens | Chipaca: yeah, that's ubuntu-emulator | 12:59 |
| Chipaca | ah | 12:59 |
| Chipaca | sorry then :) | 12:59 |
| Chipaca | where does that eth0 file come from then? | 12:59 |
| sergiusens | Chipaca: on a kvm image? | 13:00 |
| Chipaca | sergiusens: yes | 13:00 |
| ogra_ | i would suspect something like ubuntu-core-config | 13:00 |
| ogra_ | or a systemd unit thats shipped somewhere | 13:00 |
| sergiusens | ogra_: Chipaca doesn't look lke ucc http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/ubuntu-core-config/wily/files/head:/etc/ | 13:01 |
| sergiusens | Chipaca: ogra_ dpkg -S says no one owns it | 13:02 |
| mvo | sergiusens, Chipaca: so gdoc looks mostly sane? I'm a bit torn on /data for system data vs /home/system/data | 13:02 |
| ogra_ | live-build/ubuntu-core/hooks/04-configure_network.chroot | 13:02 |
| ogra_ | there is is i think | 13:03 |
| ogra_ | http://paste.ubuntu.com/11740076/ | 13:03 |
| sergiusens | mvo: I don't like either; it seems /writable/data works better and rids us of a bind mount | 13:03 |
| * sergiusens wants to just move all refs to /writable | 13:04 | |
| mvo | 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:05 |
| ogra_ | 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 | |
| sergiusens | mvo: I don't mind /writable/home either ;-) | 13:06 |
| sergiusens | Chipaca: because /var has a lot of read only stuff :-P | 13:06 |
| sergiusens | maybe /therealvar works bettwe | 13:07 |
| sergiusens | *better even | 13:07 |
| Chipaca | sergiusens: it doesn't have that much read only stuff that we don't want to get rid of | 13:07 |
| ogra_ | 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 |
| Chipaca | it's 14M, of which 12M is dpkg/info | 13:08 |
| mvo | Chipaca: that can be killed, we could do that right now via livecd-rootfs | 13:09 |
| ogra_ | (and we need to share the writable bits with the android container since many bits need to be accessibe by both OSes) | 13:09 |
| Chipaca | 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 |
| ogra_ | s/neede/need/ | 13:09 |
| * ogra_ always has home in var on his servers | 13:09 | |
| ogra_ | since over a decade :) | 13:09 |
| === Guest90150 is now known as devil__ | ||
| === devil__ is now known as devil_ | ||
| sergiusens | Chipaca: ogra_ fwiw, latest images left me without networking on kvm as well | 13:10 |
| Chipaca | ogra_: i don't know if that should be seen as encouragement or a sign of trouble | 13:10 |
| ogra_ | but that wouldnt help the HW requirements android puts upon us on personal | 13:10 |
| Chipaca | sergiusens: yes, because of the above | 13:10 |
| Chipaca | sergiusens: you do have networking, you just don't know it :-p | 13:10 |
| ogra_ | or rather the setup reqs. not the HW reqs | 13:10 |
| ogra_ | we cant change paths of binary blobs | 13:10 |
| Chipaca | sudo sed -i -e "s/eth0/$(ls /sys/class/net/ | grep -vx lo | head -n1)/g" /etc/network/interfaces.d/eth0 | 13:10 |
| Chipaca | sergiusens: ^ | 13:10 |
| Chipaca | sergiusens: and reboot | 13:10 |
| sergiusens | 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 |
| Chipaca | sergiusens: or restart networking, but reboot is quicker without ocmpletion :-p | 13:11 |
| Chipaca | sergiusens: +1.33 | 13:11 |
| ogra_ | 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 | |
| sergiusens | Chipaca: oh, the iface name change reached us | 13:11 |
| ogra_ | cant we remove dpkg altogether ? | 13:11 |
| ogra_ | even the binary | 13:12 |
| Chipaca | the whole thing, afaik | 13:12 |
| sergiusens | ogra_: yes we CAN! | 13:12 |
| Chipaca | although elopio will be sad | 13:12 |
| ogra_ | JUST DOIT ! | 13:12 |
| Chipaca | we can even remove dpkg-deb | 13:12 |
| ogra_ | JUST DOIT ! | 13:12 |
| ogra_ | :) | 13:12 |
| Chipaca | fuck yeah! break things on fridays! | 13:12 |
| sergiusens | Chipaca: right, but the reason we can't remove it on the phone is beacuase QA became entrenched with it | 13:12 |
| Chipaca | and it isn't even beer o'clock | 13:12 |
| ogra_ | on edge ... | 13:12 |
| Chipaca | remove it yesterday, then | 13:13 |
| ogra_ | living on the edge you can fall at times :) | 13:13 |
| * Chipaca puts on a bit of aerosmith | 13:13 | |
| sergiusens | there https://www.youtube.com/watch?v=7nqcL0mjMjw | 13:13 |
| * ogra_ headbangs | 13:13 | |
| Chipaca | 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 |
| Chipaca | pitti: currently we have a (now non-functional) static file that brought up eth0 with dhcp | 13:15 |
| mvo | Chipaca: dmesg|grep eth | 13:16 |
| Chipaca | mvo: see above for sed that works :) | 13:16 |
| mvo | Chipaca: oh, sorry | 13:16 |
| pitti | Chipaca: what is "static" in this context? | 13:17 |
| Chipaca | mvo: asking because we can't be the first ones, so maybe there's already a known-good soltion | 13:17 |
| Chipaca | mvo: otherwise we can cook :) | 13:17 |
| * mvo nods | 13:17 | |
| ogra_ | mvo, livecd-rootfs http://paste.ubuntu.com/11740076/ ... | 13:17 |
| ogra_ | but interface names are dynamic now ... on boot ... | 13:17 |
| Chipaca | pitti: livecd-rootfs writes /etc/network/interfaces.d/eth0 with allow-hotplug eth0\niface eth0 inet dhcp | 13:17 |
| Chipaca | pitti: see ogra's pastebin for the code that writes it out | 13:18 |
| mvo | Chipaca: I think apparmor may break without dpkg, the aa-clickhook was iirc calling dpkg for something | 13:18 |
| ogra_ | so we need to move the file cration somewhere into the boto process | 13:18 |
| ogra_ | *boot | 13:18 |
| ogra_ | after we know the name | 13:18 |
| Chipaca | ogra_: no, no boto! jdstrand will get upset | 13:18 |
| pitti | Chipaca: and what is "first"? | 13:18 |
| ogra_ | haha | 13:18 |
| pitti | Chipaca: for ethernet, pick any match in /sys/class/net/en* | 13:18 |
| pitti | 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 |
| pitti | i. e. ls /sys/class/net | head -n1 | 13:18 |
| pitti | ? | 13:18 |
| Chipaca | pitti: good to know they're en* | 13:19 |
| ogra_ | pitti, is that generator gone ? | 13:19 |
| mvo | just out of curiosity, why is it erenamd in the first place? | 13:19 |
| mvo | 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 | |
| pitti | Chipaca: yes, and wlan is wl* | 13:20 |
| Chipaca | 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 |
| Chipaca | i think there are three different names for the device? or something like that | 13:20 |
| mvo | but only one that works with ifconfig it seems | 13:20 |
| seb128 | 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 |
| pitti | ogra_: yes, see https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038786.html | 13:21 |
| seb128 | I just created a personal image using udf, but that seems to have given me an outdated version | 13:21 |
| seb128 | like ubuntu-core-config was not at 0.22 which it is in this log ^ | 13:21 |
| seb128 | is that normal? | 13:21 |
| Chipaca | mvo: i mean, the same device is called (potentially) different things in different parts of the system | 13:21 |
| ogra_ | pitti, "this wont affect upgrades" ... also on readonly system-image installs ? :) | 13:21 |
| seb128 | is there a way to check if there a channel image update ongoing and what's the status? | 13:22 |
| pitti | 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 |
| ogra_ | (where the upgrade is actually replacing bits of the system instead of using dpkg) | 13:22 |
| Chipaca | pitti: the sed was strictly just for our images, running in kvm | 13:22 |
| Chipaca | pitti: not a general solution | 13:22 |
| pitti | ogra_: well, upgrades in the apt sense :) | 13:22 |
| ogra_ | pitti, right | 13:22 |
| sergiusens | seb128: there are logs on nusakan, but I don't recall where to find them | 13:22 |
| ogra_ | so it will break phones and snappy | 13:22 |
| pitti | we can't have maintscripts on s-i upgrades | 13:22 |
| ogra_ | we need to take that into account i guess | 13:22 |
| jdstrand | 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:22 |
| seb128 | ogra_, you might know (logs on nusakan) | 13:23 |
| pitti | 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 |
| ogra_ | seb128, rootfs build ? | 13:23 |
| pitti | or firewall rules and stuff which refer to the names? | 13:23 |
| ogra_ | pitti, well, on phones it might not be an issue ... NM cares for the interfaces | 13:24 |
| seb128 | 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 |
| jdstrand | 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 |
| ogra_ | seb128, /srv/cdimage.ubuntu.com/log/ | 13:24 |
| seb128 | ogra_, it built over an hour ago and I just use udf to build and image but get the old content | 13:24 |
| pitti | ogra_: right, and NM doesn't care about the name | 13:24 |
| seb128 | ogra_, in fact I don't have ssh access to that box so nevermind, I can't look there | 13:24 |
| ogra_ | seb128, there is no logging for system-image | 13:24 |
| ogra_ | (at all) | 13:25 |
| seb128 | I guess I just have to wait and retry? | 13:25 |
| ogra_ | only for cdimage and livefs builds | 13:25 |
| seb128 | version is at 10, I guess I need a 11... | 13:26 |
| seb128 | sergiusens, mvo, you are sure channel images are autoupdated? | 13:26 |
| sergiusens | seb128: well, slangasek said he added it to the list | 13:26 |
| sergiusens | seb128: once it's in the list for consumption, it's automatic; only reason it failed could be due to an error | 13:27 |
| seb128 | slangasek, hey | 13:27 |
| mvo | seb128: import-image is still running | 13:27 |
| seb128 | mvo, how long does that take? | 13:27 |
| seb128 | mvo, is there some UI where I can see the status? | 13:27 |
| mvo | seb128: TMPDIR=/srv/system-image.ubuntu.com/tmp /srv/system-image.ubuntu.com/bin/import-images -vvvv | 13:27 |
| mvo | 2015-06-19 13:27:14,522 INFO Something else holds the global lock. exiting. | 13:27 |
| sergiusens | seb128: from http://system-image.ubuntu.com/ubuntu-personal/rolling/edge/generic_amd64/index.json it seems it was last updated today | 13:27 |
| seb128 | sergiusens, today this morning or today an hour ago? | 13:27 |
| mvo | seb128: lsof -p 4196 tells me there is no log | 13:27 |
| sergiusens | seb128: very early Fri Jun 19 06:02:00 UTC 2015 | 13:28 |
| seb128 | sergiusens, k, so likely the daily build, no the retry with the fixes from this morning | 13:28 |
| sergiusens | maybe the phone guys are fooling around with s-i? | 13:28 |
| seb128 | mvo, is that lock warning something I should be concerned about? ;-) | 13:28 |
| mvo | seb128: no, it means its working | 13:28 |
| seb128 | k | 13:29 |
| mvo | seb128: ls -lh /srv/system-image.ubuntu.com/tmp/tmpSW4IWr/ | 13:29 |
| mvo | total 3.2G | 13:29 |
| mvo | -rw-rw-r-- 1 cdimage cdimage 1.8G Jun 19 13:20 source.tar | 13:29 |
| mvo | -rw-rw-r-- 1 cdimage cdimage 1.4G Jun 19 13:28 target.tar | 13:29 |
| * seb128 waits then | 13:29 | |
| mvo | seb128: that might help | 13:29 |
| sergiusens | big images with s-i :) | 13:29 |
| seb128 | mvo, thanks | 13:29 |
| * seb128 would like to see an image booting before eow! | 13:29 | |
| mvo | seb128: but I share your pain, +1 for logs | 13:29 |
| sergiusens | and super tight xz compression levels | 13:29 |
| mvo | seb128: you have 2.5 more days ;) | 13:29 |
| seb128 | mvo, lol | 13:30 |
| ogra_ | 4196 ? R 28:56 /usr/bin/python /srv/system-image.ubuntu.com/bin/import-images | 13:31 |
| ogra_ | runs since 30min | 13:31 |
| ogra_ | (or rather "had 30min f CPU cycles) | 13:32 |
| ogra_ | *of | 13:32 |
| Chipaca | f works too | 13:33 |
| Chipaca | short for the same thing as it was in fvwm | 13:34 |
| sergiusens | mvo: golang-gettext-dev is not in the archives yet | 13:35 |
| mvo | sergiusens: I guess some archive admin needs to get active | 13:36 |
| mvo | sergiusens: like seb128 … | 13:36 |
| sergiusens | heh :-P | 13:36 |
| seb128 | lol | 13:36 |
| seb128 | I own you some... sure I can do that ;-) | 13:36 |
| * mvo hugs seb128 | 13:36 | |
| * seb128 hugs mvo back | 13:37 | |
| ogra_ | huggers | 13:37 |
| sergiusens | mvo: another reason to use http://getgb.io/ ;-) | 13:38 |
| mvo | sergiusens: haha, indeed, it would make all the packaging irrelevant | 13:38 |
| sergiusens | mvo: I might try and switch webdm given it's not even a debian package :-P | 13:39 |
| seb128 | sergiusens, mvo, NEWed, I'm going to watch for the build and NEW the binaries then | 13:41 |
| sergiusens | ty | 13:41 |
| seb128 | yw | 13:42 |
| mvo | \o/ | 13:42 |
| mterry | mvo, golang-gettext landed in wily | 13:46 |
| ogra_ | seb128, oh man, adding your gigantic image makes the system-image importer run forever ... | 13:49 |
| ogra_ | (still busy ... that used to be 10-15min max ... ) | 13:49 |
| * ogra_ thinks we'll need separate s-i servers soon ... image build times wont be bearable anymore at some point | 13:51 | |
| seb128 | mvo, read backlog :p | 13:52 |
| seb128 | ups | 13:52 |
| seb128 | mterry, read backlog :p | 13:52 |
| seb128 | ogra_, yeah, sorry about that ... | 13:52 |
| mvo | ogra_: once we move the os into a snap it will be a different system doing the imports | 13:52 |
| ogra_ | seb128, not your fault, our infra sucks on that level | 13:52 |
| ogra_ | mvo, sure ... but til then every new image and arch adds up | 13:52 |
| mterry | seb128, thanks! :) | 13:53 |
| seb128 | mterry, yw ;-) | 13:53 |
| seb128 | mterry, miiiike | 13:53 |
| seb128 | https://launchpad.net/ubuntu/+source/golang-gettext/0~git20130221-0ubuntu1 | 13:53 |
| ogra_ | mvo, and phone kind of needs more rapid turnaround time than waiting 3h for an image build | 13:53 |
| seb128 | ftbfs | 13:53 |
| seb128 | mvo, ^ fail to build | 13:53 |
| mterry | seb128, haha | 13:54 |
| mterry | seb128, guh those stupid tests | 13:54 |
| sergiusens | mterry: lol, funny how tests are always stupid when they fail :-) | 13:54 |
| sergiusens | especially on a Friday! | 13:55 |
| longsleep | Hey folks, is there a way to run my own image-server and have my images use that one? | 13:55 |
| sergiusens | longsleep: yes there is | 13:55 |
| mterry | sergiusens, it's not that they are stupid tests, they are just *being* stupid :) | 13:55 |
| longsleep | sergiusens: Ok great - then i have a project for the weekend :( | 13:55 |
| longsleep | wrong smily - meant :) | 13:56 |
| sergiusens | longsleep: https://wiki.ubuntu.com/ImageBasedUpgrades/ServerSetup | 13:56 |
| longsleep | sergiusens: awesome - thanks! | 13:56 |
| longsleep | currently my images pull generic_armhf - is there a way to make it pull say odroidc_armhf ? | 13:58 |
| longsleep | i mean i saw that config somewhere in /etc/system.. but can it be set from the oem snap or something? | 13:59 |
| sergiusens | longsleep: that's the leaf node in system image /etc/system-image/channel.ini | 14:09 |
| longsleep | sergiusens: Right, but how can it be changed automatically - like when building the image file? | 14:10 |
| sergiusens | longsleep: that's all part of the server setup, is it not there? if not it is described one level up | 14:11 |
| longsleep | longsleep: didn't see it - let me look again | 14:12 |
| ogra_ | it will stop working once we switch to snap only upgrades | 14:12 |
| ogra_ | (and away from s-i ) | 14:12 |
| ogra_ | no idea whats the ETA on this though | 14:12 |
| elopio | good morning. | 14:12 |
| longsleep | ogra_: right - but the base system still needs to come from some place? | 14:14 |
| ogra_ | longsleep, from a snap package ... | 14:15 |
| ogra_ | (in the future scenario) | 14:15 |
| longsleep | ogra_: mhm i fail to see how this is going to work - then that snap package is not mutch different from a tar.xz | 14:16 |
| ogra_ | it comes from a different place | 14:17 |
| longsleep | right now i am looking into possibilities how i can let people upgrade their ODROIDC's if i roll a new kernel without flashing | 14:17 |
| ogra_ | right, running your own s-i server is the solution then | 14:17 |
| sergiusens | elopio: u-d-f should test this combination release_used_to_build release_built release_built_revision $target_device | 14:17 |
| ogra_ | but it wont presist | 14:17 |
| ogra_ | *persist | 14:17 |
| longsleep | ogra_: right - i understand that - but how long would that actually be? Weeks, months? | 14:18 |
| ogra_ | at one point all three image parts are snaps ... and u-d-f will assemble the image from the store | 14:18 |
| ogra_ | see above: <ogra_> no idea whats the ETA on this though | 14:18 |
| ogra_ | it is on the roadmap ... but i dont know for when | 14:19 |
| ogra_ | (surely before april ... no idea if before october) | 14:19 |
| longsleep | ogra_: ok :) i see what i can do then with my own system-image-server and it becomes obsolete once its obsolete - i am fine with that | 14:19 |
| longsleep | the interesting question is if there will be a upgrade path from current system-image installs to store only installs | 14:20 |
| elopio | fgimenez: I'm joining the talky. | 14:21 |
| ogra_ | that i cant tell | 14:21 |
| * sergiusens takes a short break | 14:21 | |
| jdstrand | olli: re docs> https://developer.ubuntu.com/en/snappy/guides/security-policy/ (has Debugging at the end), https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Debugging, https://developer.ubuntu.com/en/snappy/guides/frameworks/ (discusses framework-policy), https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/DevelopingFrameworkPolicy (tips for framework authors) | 14:21 |
| fgimenez | elopio, ok, i'm already there | 14:22 |
| ogra_ | seb128, the importer seems to be done now | 14:23 |
| seb128 | ogra_, indeed, 11 on http://system-image.ubuntu.com/ubuntu-personal/rolling/edge/generic_amd64/ | 14:23 |
| seb128 | ogra_, thanks! | 14:23 |
| * seb128 starts udf build | 14:23 | |
| olli | jdstrand, thx! | 14:30 |
| elopio | Chipaca: I won't be sad if we can build the image with the ubuntu-snappy-tests deb. | 14:45 |
| Chipaca | elopio: i have no idea what a deb is. you're talking nonsense. | 14:45 |
| Chipaca | elopio: there has never been dpkg | 14:46 |
| elopio | Chipaca: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/integration-tests/selftest#L50 | 14:47 |
| elopio | that's the ugly workaround we need to solve in a clever way. | 14:48 |
| elopio | sergiusens: can we pass the ~/.ssh/id_rsa.pub to the image from ubuntu-device-flash ? | 14:51 |
| elopio | oh, that's --developer-mode. | 14:52 |
| rickspencer3 | jdstrand, I have a much smaller reproducer for the net_admin issue I hit | 14:56 |
| rickspencer3 | I think it might be from reading a yaml file locally | 14:56 |
| elopio | fgimenez: I was just saying that maybe we need to return to hangouts for the time being. | 14:59 |
| Chipaca | rickspencer3: i don't know if you saw, but tyhicks narrowed it down quite a lot more | 15:00 |
| rickspencer3 | I saw that | 15:00 |
| rickspencer3 | thanks Chipaca | 15:00 |
| Chipaca | rickspencer3: to the point there's a kernel patch and all | 15:00 |
| Chipaca | ah, k | 15:00 |
| rickspencer3 | I put my smaller listing in for good measure, though | 15:00 |
| Chipaca | rickspencer3: also, stop breaking the kernel :-p | 15:00 |
| rickspencer3 | if by that you mean, "stop using snappy" | 15:01 |
| rickspencer3 | no chance | 15:01 |
| rickspencer3 | I love this stuff | 15:01 |
| rickspencer3 | it's like developing for the phone, but on steroids | 15:01 |
| Chipaca | oooh, that's nice, kernel dumps on usb unplugs | 15:03 |
| seb128 | sergiusens, mvo, k, new personal build boots to a working unity-greeter ;-) | 15:03 |
| seb128 | with a guest session button | 15:04 |
| ogra_ | seb128, yay | 15:04 |
| seb128 | now I need to try out of a vm for the session because unity8 doesn't work in kvm | 15:04 |
| ogra_ | why didnt you copy the autologin logic from touch ? | 15:04 |
| seb128 | because we started from ubuntu-core | 15:05 |
| ogra_ | (i mean, i know you wont use that in the final thing ... but its likely helpful during porting) | 15:05 |
| seb128 | I should review the diff with touch now | 15:05 |
| ogra_ | yeah, you kind of do a three way merge | 15:05 |
| jdstrand | rickspencer3: thanks for the extra info | 15:07 |
| mvo | seb128: \o/ | 15:08 |
| Chipaca | why does eth0 say it's eating 14W when i'm not using it | 15:09 |
| * Chipaca 's seeing 40W drain on his laptop | 15:09 | |
| * Chipaca would recommend wily to people in colder seasons | 15:09 | |
| * longsleep 's laptop is currently using less power than Chipaca's eth0 | 15:09 | |
| Chipaca | :'( | 15:10 |
| longsleep | :) sorry | 15:10 |
| Chipaca | well, 18W of that is my hd webcam | 15:10 |
| sergiusens | seb128: yay | 15:13 |
| mvo_ | sergiusens: there will be conflicts with the noUpdate branc hand the snappy-improved-developer-mode branches - if the that could land I can help with the resolving of conflicts | 15:17 |
| sergiusens | mvo_: no worries | 15:18 |
| Chipaca | sergiusens: you're leaving for 5h really? | 15:27 |
| sergiusens | Chipaca: yes, doctor and errands | 15:28 |
| Chipaca | sigh | 15:28 |
| Chipaca | also, damn | 15:28 |
| ogra_ | stop being sick ! | 15:28 |
| sergiusens | Chipaca: 5hr is a stretch | 15:28 |
| Chipaca | sergiusens: i'll poke mvo, and then poke you | 15:28 |
| Chipaca | no worries | 15:28 |
| ogra_ | doctors earn enough without you supporting them ... | 15:28 |
| sergiusens | Chipaca: we can meet after standup | 15:28 |
| seb128 | is there a -v mode to "snappy"? | 15:31 |
| seb128 | "snappy internal-run-hooks" fails on personnal | 15:32 |
| mvo_ | seb128: on wily? that should provide the output of the failed hooks | 15:32 |
| seb128 | "hook command /usr/lib/ubuntu-push-client/click-hook failed with exit status 1 (output: "")" | 15:32 |
| seb128 | mvo_, ^ | 15:32 |
| bschaefer | hello is there a way to make the snappy core system writable to test some packages and doing session stuff? (such as touch /userdata/.writeable?) | 15:32 |
| seb128 | bschaefer, mount -o remount,rw / | 15:33 |
| bschaefer | seb128, cool thanks! | 15:33 |
| seb128 | yw | 15:33 |
| seb128 | if you want to use apt just rm /usr/local/bin/apt* | 15:33 |
| seb128 | that's handy for local debug | 15:33 |
| seb128 | I used that to install things on personal | 15:33 |
| bschaefer | o cool sweet! | 15:34 |
| Chipaca | seb128: bschaefer: but do know that's even less supported than on touch | 15:37 |
| seb128 | Chipaca, "supported"? it helped me to understand why lightdm doesn't start, then I threw away the image and uploaded the ubuntu-core-config fixes neded | 15:38 |
| seb128 | Chipaca, which is just what I needed | 15:38 |
| bschaefer | its mainly for debuging and to figure out if its possible or not | 15:38 |
| bschaefer | to do what im trying :) | 15:38 |
| Chipaca | seb128: yes. I'm wondering how much we learned from people breaking their phones because we publicized things like this. | 15:38 |
| seb128 | Chipaca, discussion development here is not really publicizing to users... | 15:39 |
| seb128 | discussing* | 15:39 |
| seb128 | Chipaca, btw, do you have any idea how to figure out why /usr/lib/ubuntu-push-client/click-hook fails on snappy personal/how to debug? | 15:39 |
| seb128 | it returns "1" | 15:40 |
| seb128 | but without any error/output | 15:40 |
| ogra_ | writability is sadly essential for porting ... on phones at least ... | 15:41 |
| ogra_ | but i agree, we should have never documented it at all | 15:41 |
| seb128 | right | 15:42 |
| seb128 | well, we are discussing on a dev channel | 15:42 |
| seb128 | it's not really documenting | 15:42 |
| ogra_ | well, mount -o remount,rw / is everywhere in phone blogs and docs | 15:42 |
| seb128 | that command existed before ubuntu ... | 15:43 |
| ogra_ | and it isnt hard to adapt that concept to snappy if you look close enough | 15:43 |
| ogra_ | heh, indeed | 15:43 |
| elopio | Chipaca: so, for when you have some time: http://paste.ubuntu.com/11740844/ | 15:56 |
| Chipaca | elopio: in a hangout right now, but on this right after (will ping you) | 15:59 |
| sergiusens | elopio: try making it a multi target | 16:09 |
| elopio | sergiusens: I need a for-dummies explanation of that. | 16:09 |
| elopio | what should be multi target? the chroot, or the deb, or the command? | 16:10 |
| mvo_ | mterry: is something like https://code.launchpad.net/~mvo/snappy/snappy-binary-ld-library-path-wrapper/+merge/252560 part of snapcraft now? or we just go ahead with that on the snappy side? | 16:14 |
| fgimenez | nice weekend everyone o/ | 16:17 |
| mterry | mvo_, we envisioned that as something snapcraft did | 16:19 |
| mterry | mvo_, and especially since we would probably have multiple, namespaced lib dirs | 16:20 |
| mterry | mvo_, I am also leery as sergiusens of hardcoding layout of a snap | 16:20 |
| mvo_ | mterry: thanks, thats great, if its on your radar thats good enough for me :) | 16:20 |
| sergiusens | elopio: Multi-Arch: same iirc | 16:27 |
| sergiusens | elopio: https://wiki.ubuntu.com/MultiarchCross | 16:27 |
| slangasek | seb128: I'm off today, but if you have a question ask and I'll try to answer :) | 16:30 |
| seb128 | slangasek, no, it's fine, enjoy your day off ... I was wondering if the s-i server would pick new tarballs from cdimage builds, it does | 16:31 |
| slangasek | seb128: yep, sure does :) | 16:31 |
| seb128 | slangasek, it just took ages | 16:31 |
| slangasek | ah, it should only take 5 minutes to pick it up, and sometime longer than that to process them | 16:31 |
| seb128 | where ages is like 3 hours | 16:31 |
| seb128 | right | 16:32 |
| slangasek | so maybe the importer was disabled at the time because of something happening for the phone | 16:32 |
| seb128 | seems like the s-i server mangling is having lot to chew with the personal image ;-) | 16:32 |
| seb128 | slangasek, <ogra_> 4196 ? R 28:56 /usr/bin/python /srv/system-image.ubuntu.com/bin/import-images | 16:33 |
| ogra_ | slangasek, when i last checked the process it had 48 min on the counter ... | 16:33 |
| seb128 | slangasek, well, maybe 3 hours is exagerated but it was easy > 1.5 hours, seems the imported was eating cpu for over half an hour | 16:33 |
| ogra_ | before it finished | 16:33 |
| slangasek | ok | 16:33 |
| slangasek | may not have been just because of the personal images, there may have been other images to import at the same time | 16:33 |
| ogra_ | i was wondering before if we could split phone and snappy imports somehow | 16:34 |
| seb128 | I guess adding the personal images doesn't help, they are not small | 16:34 |
| ogra_ | when we started it was under 10min | 16:34 |
| seb128 | slangasek, also I was unsure what was going on, there is no place to see if an import is ongoing and what's the status afaik | 16:34 |
| seb128 | slangasek, anyway, we eventually got the image out of it and it's booting to a working lightdm, so all good ;-) | 16:35 |
| ogra_ | and it grew by ~5 min for each phone arch we added, i imagine thats similar on the snappy side now | 16:35 |
| seb128 | next step is to test the session, but mir doesn't like my vm so need to switch to real hwd for that, it's for next week | 16:35 |
| slangasek | Well, yes. The server where this happens contains sensitive keys; not something that we'd be keen to add a webservice to to let people publically track the importer status | 16:35 |
| ogra_ | right, "ps ax|grep import" on nusakan is the best you can do ... | 16:36 |
| ogra_ | would eb nice to have a constant log from the importer though ... that sets a stamp or some such when itz starts and finishes a run | 16:36 |
| slangasek | however, any of sil2100, rsalveti, mvo, ogra, myself etc can check the status for you | 16:36 |
| ogra_ | hmm, i guess that would be easy to achieve by just adding -v >>$logfile to the crontab line | 16:38 |
| seb128 | slangasek, yeah, well now I know that it's reacting to new builds and that it takes some time, so it's fine | 16:39 |
| seb128 | slangasek, thanks for the reply, enjoy your day off work ;-) | 16:39 |
| elopio | not much luck using same. But with python3:any on the dependencies I got a little further. | 16:41 |
| elopio | http://paste.ubuntu.com/11741070/ | 16:41 |
| Chipaca | elopio: that looks like a bug in python3.4's packaging | 16:51 |
| Chipaca | elopio: maybe barry can confirm? | 16:51 |
| Chipaca | /var/lib/dpkg/info/python3.4-minimal.postinst: 46: /var/lib/dpkg/info/python3.4-minimal.postinst: python3.4: not found | 16:51 |
| Chipaca | barry: ^ | 16:51 |
| Chipaca | that's in wily | 16:51 |
| * longsleep wants to see Snappy to ship only a single Python and does not care if it is 2 or 3 | 17:05 | |
| olli | snappy gods... I am seeing the following issue - http://paste.ubuntu.com/11739849/ | 17:06 |
| olli | with that n dmesg | 17:06 |
| olli | http://paste.ubuntu.com/11739855/ | 17:06 |
| olli | mterry says access denial to /usr/share/applications might be a red herring however | 17:07 |
| ogra_ | olli, LD_LIBRARY_PATH not set ? | 17:07 |
| ogra_ | (for the first line in the first post) | 17:08 |
| olli | http://paste.ubuntu.com/11741043/ - line 5083 shows successful access to the library | 17:08 |
| olli | and the lib exists in the fs | 17:08 |
| ogra_ | /usr/lib/x86_64-linux-gnu/ is definitelky nothing you can ship in a snap | 17:08 |
| ogra_ | not without $SNAPP_APP_PATH prefix | 17:08 |
| olli | ah | 17:09 |
| olli | it's deb2snap where it's coming from | 17:09 |
| olli | but... | 17:09 |
| ogra_ | ah ... mterry terrytory then :) | 17:09 |
| olli | seems like qt assumes access to the lib in the standard path | 17:09 |
| ogra_ | yeah, while yu would want /apps/mir/snap1/debs/usr/lib/x86_64-linux-gnu | 17:10 |
| olli | the strace shows successful access due to deb2snap LDpreload magic | 17:10 |
| olli | ogra check the last pastebin | 17:10 |
| olli | line 5083 | 17:10 |
| olli | just seems that Qt is printing the err msg | 17:10 |
| olli | and the printf doesn't know about LDPRELOAD | 17:11 |
| ogra_ | yeah, butu i wonder what else internally doesnt :) | 17:12 |
| ogra_ | *but | 17:12 |
| olli | ogra_, all access to libdeclarative_multimedia is successful according to the lib | 17:12 |
| olli | s/lib/strace | 17:12 |
| ogra_ | i think for the /usr/share/application issue there is actually some XDG_* variable you can set to point to the prefixed versin of the dir ... | 17:14 |
| ogra_ | (if qmlscene accepts freedesktop standards :) ) | 17:15 |
| olli | right, not worried about that | 17:15 |
| mterry | olli, still no luck? | 17:42 |
| olli | mterry, I got the strace | 17:42 |
| === dpm is now known as dpm-afk | ||
| olli | shows access to the right .so | 17:42 |
| olli | so I am rtfc | 17:42 |
| olli | mterry, for the ldpreload redirections, shouldn't I be able to run that locally on my regular system | 18:06 |
| olli | assuming I am setting the Snappy env vars accordingly? | 18:06 |
| mterry | olli, I think so? | 18:07 |
| olli | then I could at least pretend to debug outside of the confined core system | 18:07 |
| mterry | should work.. | 18:07 |
| olli | will try | 18:07 |
| barry | Chipaca: i noticed some problems w/ py3.4 in armhf just earlier today and sent an email to doko | 18:12 |
| olli | does snappy allow me to install snaps outside of "core", eg into a chroot? | 18:22 |
| elopio | barry: thanks. Please keep me on posted if you get news so I can retry this. | 19:05 |
| barry | elopio: will do | 19:09 |
| skay | I think I flashed a beagleboneblack with snappy, and I'm wondering if I should see a new network interface show up when it's plugged in to my computer | 19:45 |
| === retrack is now known as Guest92142 | ||
| Nissyen | Hi, I filed a bug report, but I am not sure if I just rediscovered bug #1460152 . | 22:34 |
| nothal | Bug #1460152: apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates) <Snappy:Fix Committed> <apparmor (Ubuntu):New> <http://launchpad.net/bugs/1460152> | 22:34 |
| ubottu | bug 1460152 in apparmor (Ubuntu) "apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates)" [Undecided,New] https://launchpad.net/bugs/1460152 | 22:34 |
| Nissyen | The bug I filed was #1466682 | 22:34 |
| Nissyen | Does anyone know if a unix socket permission issue would be another manifestation of apparmor not rebuilding the cache? | 22:37 |
| jjohansen | Nissyen: maybe, is apparmor denying access to the socket | 22:40 |
| jjohansen | Nissyen: if the cache is out of date and you are using old policy it is possible | 22:40 |
| Nissyen | Yeah, the dmesg is: [ 72.230872] audit: type=1400 audit(1434397079.776:12): apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="docker_docker_1.6.1.002" name="run/docker.sock" pid=1025 comm="docker.x86_64" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0 | 22:40 |
| jjohansen | Nissyen: you can always just delete the cache and force a policy reload | 22:41 |
| Nissyen | I reloaded the framework in question, but actually let me try updating ubuntu-core from 2 to 3 on a VM and then rebuilding the cache and see if that fixes it. | 22:41 |
| jjohansen | Nissyen: I would have to see the policy, but my guess if this requires a policy update | 22:41 |
| Nissyen | It's the docker policy… I am unfortunately not that familiar with it. | 22:42 |
| jjohansen | Nissyen, I am not really familiar with the docker policy either | 22:42 |
| jjohansen | that being said, since this is failing with "Failed name lookup" the policy requires, flags=(attach_disconnected) in it | 22:43 |
| jjohansen | that would look something like | 22:43 |
| jjohansen | profile X flags=(attach_disconnected) { ... } | 22:43 |
| Nissyen | ok, I am setting up a new Vagrant snappy VM, let try to find the policy. | 22:44 |
| Nissyen | ir has a line "/eun/@{APP_PKGNAME}.sock rw, | 22:46 |
| Nissyen | sorry, The line is as follows: | 22:47 |
| Nissyen | /run/@{APP_PKGNAME}.sock rw, | 22:47 |
| Nissyen | let me try rebuilding and see what happens, I did a core update to cause the permission issue. | 22:48 |
| Nissyen | sudo apparmor_parser --skip-cache -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher did not resolve the issue. Maybe this is a new apparmor related bug | 22:54 |
| Nissyen | Aha! I found that running the command "sudo aa-clickhook -f" worked | 23:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!