| rsalveti | sergiusens: sorry I forgot to put my test results at https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/beBetter/+merge/261804 | 00:24 |
|---|---|---|
| rsalveti | sergiusens: but yeah, it's a +1 for me as well | 00:24 |
| rsalveti | Chipaca is a review machine | 00:25 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| fgimenez | good morning | 07:00 |
| dholbach | good morning | 07:11 |
| mvo | Chipaca: hey, I think you had a idea how to make https://code.launchpad.net/~mvo/snappy/snappy-gettext nicer (?) i.e. how to get a import so that we can use G() or something similar short, or am I misremembering(?) | 08:36 |
| longsleep | sergiusens: Hey - do you have any update on the review process for the ODROIDC OEM snap? It seems like it's stuck and i got no reply to my latest comments. | 08:58 |
| JamesTait | Good morning all; happy Eat Your Vegetables Day! | 08:59 |
| Chipaca | mvo: hey | 09:05 |
| Chipaca | mvo: yes | 09:05 |
| Chipaca | mvo: but only if you promise it'll only export one function (and ideally not something as collisiony as G(), but maybe i'm overthinking it) :) | 09:05 |
| mvo | Chipaca: we need two :) G() (or L() i don't care) and NG() (ngettext) | 09:06 |
| Chipaca | mvo: fair enough | 09:07 |
| Chipaca | i guess G and LG don't clash with anything right now | 09:07 |
| Chipaca | mvo: very easy to do, tbh; just import it with a . as we do with gocheck in the tests | 09:07 |
| mvo | Chipaca: heh, sure! great suggestion, thanks! | 09:09 |
| mvo | Chipaca: its one of these ideas thats obvious *once* you had it | 09:09 |
| mvo | \o/ | 09:10 |
| Chipaca | tyhicks: love your work on the CAP_NET_ADMIN thing, thank you! | 09:36 |
| rsalveti | longsleep: dholbach might be able to help you with the review related questions | 09:49 |
| dholbach | rsalveti, hum... how=? | 09:51 |
| ogra_ | rsalveti, so mzanetti just asked me an interesting question ... how will phone devs develop system components on the phone once we have no dpkg support at all anymore ? | 09:51 |
| rsalveti | dholbach: store related review questions, thought you had review permission as well | 09:51 |
| dholbach | rsalveti, yes, I do - I just wasn't sure if we had a process figured out for reviewing OEM snaps already | 09:52 |
| rsalveti | hm, right, that I don't know | 09:52 |
| longsleep | dholbach: well i received some comments, but now the process seems to be stuck as nobody did answer lately :) | 09:52 |
| rsalveti | ogra_: I fail to related developing system components and dpkg here | 09:53 |
| rsalveti | *relate | 09:53 |
| dholbach | "Supported architectures:Architecture independent" is likely wrong | 09:53 |
| ogra_ | rsalveti, today you build your stuff in a silo and then install the debs | 09:53 |
| dholbach | let me take another look at the comments | 09:53 |
| longsleep | dholbach: the only request i got was to rename it to odroid-community - i renamed it in the store only and i am not sure if that is the correct way of action | 09:53 |
| ogra_ | or re-build the packages locally | 09:53 |
| rsalveti | ogra_: right, if an app I'd imagine it would just be a simple snap, if part of core, I'd imagine you'd need to rebuild/reinstall the framework | 09:54 |
| ogra_ | and then install them ... | 09:54 |
| ogra_ | rsalveti, if the phone bits including the UI are in the core image ? | 09:55 |
| ogra_ | (which is how i understood the planned setup) | 09:55 |
| mzanetti | rsalveti, so if I want to test a small patch on unity I need to rebuild the framework? | 09:55 |
| mzanetti | ok, the severity of that really depends on what the framework is :D | 09:55 |
| ogra_ | i dont think it will be a framework ... unless rsalveti knows something new ... | 09:55 |
| rsalveti | for personal you would indeed just follow the current dev steps you do for phone | 09:55 |
| rsalveti | dpkg will be available | 09:55 |
| dholbach | ah, "Architecture independent" might actually be right | 09:55 |
| ogra_ | rsalveti, so we will have special developer images that ship dpkg ? | 09:56 |
| rsalveti | once we move away from personal and get just core + snaps, then we'd need to find the right spot for your piece | 09:56 |
| ogra_ | i thought the masterplan was to completely get rid of it | 09:56 |
| mzanetti | can you elaborate on the "move away from personal" thing? | 09:56 |
| ogra_ | to me it looks like a dev changing core would have to re-build the whole image every time | 09:56 |
| rsalveti | ogra_: that is the masterplan, but I don't think that will be removed from personal | 09:57 |
| ogra_ | ok | 09:57 |
| ogra_ | as i understood some desktop discussions the plan was to only have dpkg fenced inside an lxc container we ship by default | 09:57 |
| rsalveti | mzanetti: so personal is a shortcut atm, since transforming everything into a snap (framework and apps), is a lot of work | 09:57 |
| dholbach | jdstrand, beuno, sergiusens: regarding the odroidc oem snap decision: are you aware of anything else that needs to be done? is "arch independent" correct in this case? | 09:58 |
| rsalveti | so instead of doing that now, we created another base image that includes everything | 09:58 |
| ogra_ | (so you wouldnt have it available on the actual core system) | 09:58 |
| ogra_ | but if we keep it i guess thats fine then | 09:58 |
| dholbach | longsleep, ^ I just went ahead and pinged some other folks who should know more | 09:58 |
| rsalveti | moving away from personal would mean start using the core + snaps (framework and apps) | 09:58 |
| dholbach | longsleep, sorry for not being of more help here | 09:58 |
| mzanetti | rsalveti, you mean converting unity into a snap itself? | 09:58 |
| rsalveti | mzanetti: yup | 09:58 |
| longsleep | dholbach: ok great thanks - no worries i am not really in any hurry as long as there is no way to handle the device part with the store. | 09:59 |
| rsalveti | mzanetti: how that will be done is not clear yet | 09:59 |
| mzanetti | rsalveti, ok. thanks for clarifying. | 09:59 |
| seb128 | rsalveti, but personnal is still a snappy image and ro, so you can't dpkg things there | 10:03 |
| rsalveti | seb128: right, but that restriction already exists on phone images | 10:07 |
| rsalveti | the use case is for people already remounting things with rw | 10:07 |
| seb128 | rsalveti, you can turn the phone rw by touching a file and rebooting, is that going to work on snappy? | 10:07 |
| rsalveti | seb128: that is still an open question (if we're going to offer something similar), but I'd imagine we don't want to do that | 10:08 |
| rsalveti | the logic is currently inside the initrd | 10:08 |
| rsalveti | not sure if for personal this is something you might want to offer | 10:08 |
| seb128 | rsalveti, but you can mount -o remount rw? | 10:09 |
| rsalveti | seb128: if you have sudo access, sure | 10:09 |
| ogra_ | seb128, sure, why not | 10:09 |
| ogra_ | seb128, the initial question was just "what do we do if dpkg is gone" .... in which case you would have to install binary tarballs or some such | 10:10 |
| seb128 | oh ok | 10:10 |
| Chipaca | mvo_: when tarmac complains about "there are additional revisions yadda yadda", it's the timestamp of the top-approval it's complaining about | 10:10 |
| seb128 | well the snappy image is still built from debs | 10:10 |
| seb128 | so no reason dpkg is gone | 10:10 |
| ogra_ | but since we will keep it for now even though the masterplan is to have it not in the images, we are fine | 10:10 |
| seb128 | do we plan to stop using debs to build the images? | 10:11 |
| ogra_ | long term it will be gone, but by that time the desktop/phone will have switched to frameworks and snaps | 10:11 |
| ogra_ | no | 10:11 |
| rsalveti | not necessarily, but there is no need for dpkg to be installed | 10:11 |
| ogra_ | but we will likely remove dpkg at the end of the build | 10:11 |
| rsalveti | if we're not using it | 10:11 |
| ogra_ | (and a lot more) | 10:11 |
| ogra_ | i would imagine out core image to have only a third of the current size once we are done | 10:12 |
| ogra_ | if not even less | 10:12 |
| rsalveti | right | 10:12 |
| rsalveti | there is a card to investigate that | 10:12 |
| rsalveti | https://trello.com/c/JdwIFPwn/57-investigate-if-we-can-remove-apt-dpkg-from-the-image | 10:12 |
| ogra_ | yeah | 10:12 |
| seb128 | rsalveti, right, it's just difficult to convince a deb system to remove dpkg :p | 10:12 |
| ogra_ | rm :) | 10:12 |
| seb128 | well then no need to debs anymore | 10:12 |
| seb128 | you can also cp | 10:13 |
| ogra_ | sure | 10:13 |
| ogra_ | perhaps we'll do that one day | 10:13 |
| ogra_ | but our infra is still built around packages today | 10:13 |
| seb128 | right | 10:13 |
| ogra_ | so why not use them | 10:13 |
| ogra_ | on an embedded system where you are only interested in getting enough OS to boot, you dont really want the bloat | 10:14 |
| seb128 | sure | 10:15 |
| ogra_ | the core image i envision will only have dash, systemd and a few snapp tools installed (and whatever is needed to make these run) | 10:15 |
| Chipaca | beuno: you around? | 10:15 |
| rsalveti | Chipaca: mvo_: I know sergiusens was having this issue the other day, but do you guys know why we cna't use --install=docker when creating images? looking at bug https://bugs.launchpad.net/snappy/+bug/1465879 | 10:17 |
| ubottu | Ubuntu bug 1465879 in Snappy "docker framework does not install via ubuntu-device-flash" [High,Confirmed] | 10:17 |
| Chipaca | rsalveti: check snappy-devel | 10:18 |
| Chipaca | rsalveti: or, https://bugs.launchpad.net/snappy/+bug/1464486 | 10:18 |
| ubottu | Ubuntu bug 1464486 in goget-ubuntu-touch (Ubuntu) "frameworks that install policies cannot be preinstalled" [Undecided,New] | 10:18 |
| Chipaca | rsalveti: we should confirm whether it happens with trunk snappy, as it's merged there | 10:19 |
| Chipaca | ah! maybe it's still needing u-d-f work | 10:20 |
| * rsalveti checks | 10:23 | |
| mvo_ | rsalveti, Chipaca: it may just need a rebuild of u-d-f against current snappy (shared libs ftw :/) | 10:24 |
| rsalveti | guess also backporting https://code.launchpad.net/~sergiusens/snappy/policyRoot/+merge/261802 ? | 10:25 |
| rsalveti | or just udf would be enough? (the rebuild) | 10:25 |
| gatisp | Hello, I think there is a mistake in https://developer.ubuntu.com/en/snappy/guides/porting/ under "Snappy enablement basics and the device tarball." | 10:33 |
| gatisp | it says: "system: directory shipping kernel modules that are only needed after the rootfs has been mounted;" | 10:33 |
| ogra_ | that is correct | 10:33 |
| ogra_ | what would you expect it to be ? | 10:34 |
| gatisp | shouldn't it say modules that are needed before mounting rootfs? | 10:34 |
| ogra_ | no, these have to go into the initrd | 10:34 |
| gatisp | ah, right | 10:34 |
| ogra_ | (though i'd always recommend that if you use a custom kernel you simply compile that stuff in, it is usually just something like ext4 support and the like) | 10:34 |
| ogra_ | The following packages have unmet dependencies: | 10:43 |
| ogra_ | ubuntu-snappy : Depends: ubuntu-snappy-cli (= 1.1.2-1+510~ubuntu15.10.1) but it is not going to be installed | 10:43 |
| ogra_ | E: Unable to correct problems, you have held broken packages. | 10:43 |
| ogra_ | ... from this mornings image build ... | 10:43 |
| ogra_ | did anyone look into that yet ? | 10:43 |
| ogra_ | (armhf and i386 images failed it seems) | 10:43 |
| sergiusens | rsalveti: it should work with the latest build already | 10:45 |
| sergiusens | rsalveti: or a rebuild of u-d-f I mean | 10:46 |
| rsalveti | sergiusens: morning :-) | 10:46 |
| sergiusens | we can check with Built-Using tags | 10:46 |
| sergiusens | good morning :-) | 10:46 |
| rsalveti | sergiusens: cool, guess we just need to upload a new udf and copy it over to our ppas | 10:46 |
| rsalveti | ogra_: hm, that version is in our ppa | 10:47 |
| ogra_ | https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image | 10:48 |
| rsalveti | sergiusens: care to upload a new version once https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/installYaml/+merge/261865 gets merged? | 10:48 |
| ogra_ | amd64 built fine | 10:48 |
| rsalveti | tarmac is currently complaining about it | 10:48 |
| ogra_ | probably a timing error where the arch all side had not migtared | 10:48 |
| rsalveti | ogra_: yeah | 10:48 |
| ogra_ | i guess someone should just trigger a new build | 10:48 |
| sergiusens | rsalveti: yeah, gofmt, no sure how it happened, but it happened | 10:48 |
| sergiusens | rsalveti: maybe due to the files I just rebased but did not edit (I have goimports run as a PreWrite or whatever it was called in vim) | 10:49 |
| rsalveti | hm, but amd64 is failing quite frequently | 10:49 |
| rsalveti | https://launchpadlibrarian.net/209210238/buildlog_ubuntu-wily-amd64.ubuntu-snappy_1.1.2-1%2B511~ubuntu15.10.1_BUILDING.txt.gz | 10:49 |
| rsalveti | FAIL: touch_test.go:30: HTestSuite.TestUpdateTimestamp | 10:49 |
| rsalveti | mvo_: seems those unstable tests showing up again | 10:49 |
| rsalveti | this time for amd64 | 10:50 |
| sergiusens | rsalveti: heh, time based test failures ftw | 10:50 |
| * ogra_ triggers a new image | 10:50 | |
| rsalveti | ogra_: amd64 is still ftbfs | 10:50 |
| ogra_ | sure, but that shouldnt make armhf and i386 fail | 10:50 |
| rsalveti | we we only care about armhf and amd64 atm | 10:50 |
| ogra_ | that package comes from the PPA ... | 10:50 |
| ogra_ | no proposed-migration there | 10:51 |
| rsalveti | so one of the main archs will fail | 10:51 |
| ogra_ | (or do we have it) | 10:51 |
| ogra_ | damn ! | 10:52 |
| * ogra_ read arm64 | 10:52 | |
| rsalveti | there is another build in progress | 10:52 |
| rsalveti | someone triggered it | 10:52 |
| ogra_ | silly silly silly naming !!!!! | 10:52 |
| rsalveti | haha, /me does that all the time | 10:52 |
| ogra_ | well, i triggered one ... might be me | 10:52 |
| rsalveti | :-) | 10:52 |
| ricmm | armd64 | 10:54 |
| ogra_ | well, at least they fail fast :) | 10:54 |
| ogra_ | (i386 is already done) | 10:55 |
| ogra_ | ricmm, on compiler level the naming is even worse ... | 10:55 |
| ogra_ | aargh64 | 10:55 |
| ogra_ | err | 10:55 |
| ogra_ | aarch64 | 10:55 |
| ogra_ | oh | 10:58 |
| ogra_ | amd64 succeeded | 10:58 |
| sergiusens | fgimenez: elopio where should I add an acceptance test for https://trello.com/c/PJE5oYAF/84-disabling-updates-and-auto-update-when-using-sideloaded-kernel-snaps ? | 11:39 |
| sergiusens | can any of you two help me get started? | 11:39 |
| ogra_ | sergiusens, oh, has that landed ? | 11:39 |
| * ogra_ needs to not forget to re-enable autopilot | 11:39 | |
| sergiusens | ogra_: in process of | 11:39 |
| ogra_ | k, thanks | 11:40 |
| sergiusens | ogra_: got stuck in the pipeline | 11:40 |
| === soee_ is now known as soee | ||
| fgimenez | sergiusens, currently we are adding them in _integration_tests/tests, see https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748 | 11:41 |
| fgimenez | sergiusens, i'll push changes shortly to allow adding more than one test file, all of them are now in snappy_test.go | 11:43 |
| sergiusens | fgimenez: this doesn't drive image creation though, right? | 11:45 |
| fgimenez | sergiusens, yes, calling it with "go run _integration_tests/main.go" should do it all, compile debs, create image and call adt-run on it | 11:47 |
| sergiusens | fgimenez: nice, I need to create the image in a different way though | 11:49 |
| sergiusens | fgimenez: hmm, maybe for E2E but I can tamper with the image to set what I need | 11:50 |
| fgimenez | sergiusens, yep, it's not very configurable atm :) | 11:50 |
| sergiusens | fgimenez: should I go with the half test? | 11:53 |
| sergiusens | I would like to have E2E eventually though | 11:53 |
| fgimenez | sergiusens, how could this be setup? | 11:56 |
| beuno | Chipaca, hola | 11:57 |
| Chipaca | beuno: hola! | 11:58 |
| Chipaca | beuno: in CPI, the description is described as “Full description of the app's functionality.”. Is that one of the things entered via the online form, or is it extracted from the package? | 11:59 |
| beuno | Chipaca, yes. | 12:00 |
| beuno | Chipaca, extracted from the package, can be edited in the form | 12:00 |
| Chipaca | beuno: i'm confused a little, then | 12:00 |
| Chipaca | beuno: where is it extracted from? | 12:01 |
| Chipaca | beuno: "snappy build" loads it with the description from the readme | 12:01 |
| Chipaca | beuno: that is, it sets the manifest's description entry to the readme | 12:02 |
| Chipaca | to the second+ line of the readme | 12:02 |
| beuno | Chipaca, it parses it from the json | 12:02 |
| Chipaca | to all the non-blank lines after the first non-blank line in the readme | 12:02 |
| Chipaca | beuno: from the json manifest, yes? | 12:02 |
| sergiusens | beuno: can we make it not editable? | 12:03 |
| Chipaca | beuno: same place you get all the other metadata from? | 12:03 |
| sergiusens | Chipaca: for when time happens https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/personalCmd/+merge/262174 | 12:03 |
| Chipaca | beuno: because i'm confused, therefore, by the results from the store which seem to prepend the title to the description in the description | 12:03 |
| beuno | sergiusens, no, because then you need to re-upload a 800mb snap to fix a typo in the description | 12:04 |
| beuno | Chipaca, same place, es | 12:04 |
| beuno | Chipaca, I think it might merge 2 fields into the description | 12:05 |
| beuno | jayteeuk knows the details | 12:05 |
| Chipaca | beuno: also the title is not the title, it's the name? | 12:05 |
| Chipaca | seriously confused :) | 12:05 |
| JamesTait | It wasn't me! | 12:05 |
| sergiusens | beuno: right, but then the data is inconsistent as well | 12:05 |
| Chipaca | JamesTait: ehlo :) | 12:06 |
| rsalveti | sergiusens: holy, there are at least 5 branches waiting to be merged in goget | 12:06 |
| Chipaca | if you GET 'https://search.apps.ubuntu.com/api/v1/search?fields=title%2Cdescription&q=hello-world' | 12:06 |
| rsalveti | ubuntu-touch | 12:06 |
| sergiusens | beuno: or in other words, the local data is useless | 12:06 |
| JamesTait | Chipaca, 501 Syntax: EHLO hostname | 12:06 |
| JamesTait | 😉 | 12:06 |
| rsalveti | sergiusens: can we have an upload after merging https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/installYaml/+merge/261865 ? | 12:06 |
| Chipaca | JamesTait: ehlo chipaca | 12:06 |
| rsalveti | to split the personal stuff in another upload | 12:06 |
| sergiusens | rsalveti: yeah, didn't I says yes already :-P ? | 12:07 |
| rsalveti | sergiusens: just wanted to double confirm :P | 12:07 |
| Chipaca | JamesTait: if you GET the above uri | 12:07 |
| beuno | sergiusens, correct | 12:07 |
| Chipaca | JamesTait: and look at hello-world.canonical | 12:07 |
| sergiusens | rsalveti: split is new though... so one sec I'll set to needs review | 12:07 |
| beuno | sergiusens, the idea always was to take whatever the store told you instead of what the package says | 12:07 |
| Chipaca | JamesTait: or any of the others really | 12:07 |
| sergiusens | beuno: so why do all this packaging format if we don't need it? | 12:07 |
| beuno | sergiusens, initial seeding of the information | 12:08 |
| sergiusens | let's just remove icon. description, title, readme.md from the packaging | 12:08 |
| Chipaca | JamesTait: it seems to be setting title to ... something? and description to something else, neither of which match the title and description in the click manifest as far as i can tell | 12:08 |
| sergiusens | beuno: we can seed with an external file | 12:08 |
| sergiusens | no need for it to be part of the packaging if it's going to be useless data | 12:08 |
| sergiusens | mvo_: ^ | 12:08 |
| JamesTait | Chipaca, without having clicked on those links, let me first put pad.lv/1303354 out there. | 12:08 |
| JamesTait | Now let me click on the links and see what else I can add. | 12:09 |
| JamesTait | Chipaca, so, "look at hello-world.canonical" where? | 12:10 |
| Chipaca | JamesTait: in particular, the title is ... dunno what; the description is the \n-glomming of title and description | 12:10 |
| Chipaca | JamesTait: http://pastebin.ubuntu.com/11730186/ | 12:11 |
| Chipaca | beuno: sergiusens: easy way to fix that is to "fix" the package when edited | 12:12 |
| JamesTait | Chipaca, right, so the latter part of that is addressed by the bug I pasted above. | 12:12 |
| JamesTait | Chipaca, do you have a devportal link to that package? | 12:13 |
| Chipaca | JamesTait: i'll believe you, but i have no idea what the "app summary" or the "tagline" is, in this context | 12:13 |
| beuno | Chipaca, ew ew ew | 12:14 |
| beuno | no! | 12:14 |
| beuno | ew | 12:14 |
| Chipaca | JamesTait: id 1999 <- is that good enough? | 12:14 |
| beuno | no touching the binaries! | 12:14 |
| Chipaca | beuno: you'd rather confuse the user by letting them download things that when downloaded do not describe themselves as the things they chose to download did? | 12:15 |
| JamesTait | Chipaca, indeed it is. ☺ | 12:15 |
| beuno | Chipaca, or, you download the store's json when downloading the app and use that to display | 12:15 |
| Chipaca | beuno: you don't have to edit the binary, of course; you can also modify it on the fly when the user downloads it :-p | 12:15 |
| * beuno dims his laptop's screen to the minimum | 12:16 | |
| JamesTait | The "Sorry, can't hear you!" approach. | 12:16 |
| Chipaca | beuno: that makes the client a lot harder, especially wrt uniformity of behaviour wrt sideloaded apps; it also n-uplicates information (we'd have the package.yaml, the click manifest, and the store manifest) | 12:18 |
| sergiusens | beuno: the data needs to be consistent though | 12:18 |
| sergiusens | I think it's bad design | 12:18 |
| Chipaca | beuno: and moves work to the client, which is underpowered and numerous | 12:18 |
| JamesTait | Chipaca, bear in mind that these models evolved from the old software centre ones, which were based on .deb packages. So tagline is the one-line description and app-summary is the full description. | 12:18 |
| Chipaca | JamesTait: http://www.brainlesstales.com/images/2013/Jul/bear-in-mind.jpg | 12:19 |
| JamesTait | Chipaca, in snap package terms, that maps to... hang on, checking. ☺ | 12:19 |
| Chipaca | deb-control(5) does not call it a tagline nor an app summary, either | 12:21 |
| beuno | Chipaca, so we make people upload 800mb to fix a typo or set a promo for their app? | 12:21 |
| Chipaca | short description and long description | 12:21 |
| sergiusens | beuno: we can also split the packaging if it's useless data as you said | 12:21 |
| sergiusens | the "metadata" doesn't need to be there | 12:22 |
| Chipaca | sergiusens: how is that different from downloading the store json? | 12:22 |
| sergiusens | beuno: but keep in mind the no caching rule, the store would be spammed by thousands of clients | 12:22 |
| sergiusens | Chipaca: oh, I'm talking about "on upload" | 12:22 |
| Chipaca | sergiusens: i'm talking about not understanding how that would be different for the client :) | 12:23 |
| sergiusens | Chipaca: the initial seeding problem | 12:23 |
| Chipaca | sergiusens: you mean the server would assemble the package from these bits? | 12:23 |
| sergiusens | Chipaca: oh, if the store stays this way the client gets more logic, and the store gets more load | 12:23 |
| Chipaca | ok, i'm going to move on for now, but this is a problem and needs addressing at some point | 12:24 |
| sergiusens | Chipaca: we'd download two bits; the store json (and icon) and the actual package (which would be a list of hashed files) | 12:24 |
| * Chipaca comes back | 12:24 | |
| Chipaca | sergiusens: k | 12:24 |
| sergiusens | Chipaca: but let's break the lie about package.yaml and readme.md if it is just to "seed" | 12:25 |
| Chipaca | sergiusens: i didn't quite follow you there | 12:29 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | beuno: tbh i'm starting to wonder whether having the click and snappy stores conjoined is still a good idea | 12:29 |
| Chipaca | we seem to be making things harder for ourselves as we go | 12:29 |
| beuno | Chipaca, I asked if I could double the team size and they counter-offered with taking away half | 12:30 |
| Chipaca | beuno: just in case it sounded that way, i'm not saying you or your team messed up; i do believe we've at each step collectively taken the shortest path to get places | 12:31 |
| Chipaca | as we should | 12:31 |
| beuno | Chipaca, :) | 12:32 |
| beuno | Chipaca, so what would you propose? | 12:32 |
| beuno | splitting away from parsing the json? | 12:32 |
| Chipaca | beuno: i'd propose coffee | 12:32 |
| Chipaca | :) | 12:32 |
| beuno | Chipaca, SOLD! | 12:32 |
| JamesTait | I like proposals like that. | 12:32 |
| Chipaca | beuno: wrt the store, is it the case that it and the cpi is getting riddled with click-vs-snappy complications? or is it still relatively unified? | 12:33 |
| Chipaca | JamesTait: ^ might be for you actually | 12:34 |
| * Chipaca puts on the kettle | 12:34 | |
| beuno | Chipaca, I haven't seen keeping that backwards compatibility force us to make compromises | 12:35 |
| beuno | but JamesTait and nessita would have a more boots-on-the-ground answer | 12:35 |
| JamesTait | I'm a little out of touch with the big picture, tbh, but unless things have changed drastically the differences between handling a click package and a snap package are miniscule. | 12:35 |
| === chihchun_afk is now known as chihchun | ||
| Chipaca | on the client side it is a little fiddly, and that's without trying to make the remote-vs-local thing go away | 12:36 |
| JamesTait | Like, we parse a yaml file instead of a json file, and we set the is_snap flag to True. | 12:36 |
| beuno | Chipaca, the phone went through the same remote-vs-local phase, FWIW | 12:36 |
| Chipaca | .... | 12:36 |
| Chipaca | JamesTait: you parse a yaml file? | 12:36 |
| beuno | JamesTait, we still parse the json | 12:36 |
| JamesTait | * May be simplifying slightly. | 12:36 |
| beuno | and snap packages copy over the yaml to json :) | 12:37 |
| Chipaca | “copy” | 12:37 |
| Chipaca | “yaml” | 12:37 |
| beuno | Chipaca, so, for the most part, we can't split the stores | 12:37 |
| beuno | because most of our deliverables apply to both | 12:37 |
| Chipaca | it sounds like the store is doing the least work, and we're all muddled on the client | 12:37 |
| Chipaca | which is not terrible, as long as we can resolve the local-vs-remote without further muddling (and which might explain why we didn't really jump at the download-another-json idea) | 12:38 |
| beuno | Chipaca, so I think the idea of downloadind a metadata blob from the store is a recurring thing | 12:38 |
| beuno | the flat namespace is a good example | 12:38 |
| beuno | another one will be the apparmor profile | 12:39 |
| beuno | which we'd like to split out and have the store attach to apps at some point | 12:39 |
| beuno | my guess is we'll end up downlading and storing a separate blob of metadata anyway | 12:40 |
| ogra_ | hello apt lists | 12:40 |
| ogra_ | :P | 12:41 |
| beuno | ogra_, you mean, parsing out of a file on one path instead of another? :) | 12:41 |
| ogra_ | well, i thought the scope of snappy was to get right of index files | 12:42 |
| beuno | also, if we're re-implementing apt, lets bring back dependencies! I think that's what makes it fun | 12:42 |
| ogra_ | *rid | 12:42 |
| Chipaca | beuno: i am not opposed to downloading and storing separate metadata*; i'm opposed to having three different metadata sources :) | 12:42 |
| beuno | ogra_, index files *with all apps in the archive* | 12:43 |
| beuno | ogra_, not the ones you have :) | 12:43 |
| beuno | Chipaca, SO PICKY! :) | 12:43 |
| beuno | Chipaca, agreed | 12:43 |
| Chipaca | * i'd quesiton whether it needs to be separate on disk, or could be on-the-fly glommed into an ar (to make debugging easier maybe) | 12:43 |
| sergiusens | +1 on having one source of information | 12:44 |
| beuno | Chipaca, so my naive mental model here is that you download the json blob from the store on download, refresh it every now and then, always query that for any metadata | 12:44 |
| mvo_ | fwiw, I dislike the idea of having metadata that is not reflected in the package. mostly on philosophical grounds right now (can not be version controlled for example and packages are no longer self-contained). but thats just me | 12:44 |
| mvo_ | plus its something we need to authenticated seperately, ideally having a gpg signature for the blob too | 12:45 |
| sergiusens | mvo_: that's why I asked for the store not to allow edits | 12:45 |
| Chipaca | beuno: "refresh it every now and then" is problematic | 12:45 |
| mvo_ | sergiusens: I like that better than the alternatives | 12:45 |
| Chipaca | beuno: otherwise, with you | 12:45 |
| sergiusens | beuno: mark said no caching | 12:45 |
| beuno | Chipaca, I'm sure cron accepts "now and then" as a parameter | 12:45 |
| mvo_ | especially since when we have delta downloads it won't matter if someone uploads a new version | 12:45 |
| Chipaca | mvo_: problem is delta uploads :) | 12:45 |
| beuno | sergiusens, I don't think he meant that. We've discussed downloading a metadata blob separate from the package many times | 12:46 |
| beuno | mvo_, it won't matter to the user | 12:46 |
| mvo_ | Chipaca: is it ;) we could make that work easily via snappy upload | 12:46 |
| beuno | mvo_, it'll matter to the developer uploading 800mb | 12:46 |
| sergiusens | beuno: right, but caching on the client he said no; ask lool ;-) | 12:46 |
| beuno | mvo_, and spamming 100k users with a no-op download to s/downlod/download | 12:46 |
| mvo_ | beuno: if we sign hashes.yaml thats a solvable problem | 12:46 |
| mvo_ | beuno: we spam even more users if we cron a apt-get update like snappy run | 12:47 |
| beuno | sergiusens, I'll bring it up, I think it will have been a different context | 12:47 |
| mvo_ | don't get me wrong I'm not totally opposed but I dislike it | 12:47 |
| Chipaca | i think there is a workable way | 12:47 |
| mvo_ | and I think it will come back and hunt is in bad ways | 12:47 |
| beuno | mvo_, I wouldn't cron, I'd update the list whenever you talk to the store, snappy update, etc | 12:47 |
| lool | there will always be metadata outside of the package though | 12:48 |
| lool | like reviews | 12:48 |
| beuno | right | 12:48 |
| beuno | and, again, we already have the flat namespace | 12:48 |
| lool | all the metadata that the client might require while offline needs ot be in the package | 12:49 |
| beuno | well | 12:49 |
| beuno | that's the issue here | 12:49 |
| beuno | we disagree on that | 12:49 |
| Chipaca | ummm | 12:49 |
| Chipaca | maybe :) | 12:50 |
| Chipaca | lool: there is metadata you don't have when you're offline | 12:50 |
| lool | Chipaca: yeah, like reviews, that's fine | 12:50 |
| Chipaca | yep, and all those don't need to live with the package | 12:50 |
| lool | but you need things like the icon, the translated name | 12:50 |
| Chipaca | on disc | 12:50 |
| Chipaca | however, the package when the user creates it is a series of metadata chunks, and the binary itself | 12:51 |
| Chipaca | that's then sliced and diced into a .snap file | 12:51 |
| Chipaca | and signed | 12:51 |
| sergiusens | webdm ad click scope see a lot of problems with the current model fwiw | 12:51 |
| Chipaca | so you have a file that is, conceptually at least, a series of blobs and their signatures | 12:51 |
| beuno | s/see a lot of problems/haven't implemented separate metadata storage | 12:52 |
| Chipaca | when you download the package, the blobs get put in certain places, and you get the original package back again | 12:52 |
| lool | maybe it's just confusing to have a general discussion on metadata and we only need to list the actual data and use cases | 12:52 |
| Chipaca | currently, the store treats the package itself as a single blob | 12:52 |
| Chipaca | however that does not need to stay that way | 12:52 |
| Chipaca | the store could treat it as a series of blob,sign pairs | 12:53 |
| Chipaca | and stream those | 12:53 |
| Chipaca | and then on unpack we'd put the metadata blob wherever, and would be none the wise | 12:53 |
| beuno | right | 12:53 |
| beuno | indeed we could | 12:53 |
| Chipaca | while on the server the metadata blob was stored in a database, instead of in disc, and editing happens right there | 12:53 |
| beuno | there is metadata that the store will provide that the package won't, like UUID | 12:53 |
| beuno | so the file you give the store might not match exact what is served back | 12:54 |
| Chipaca | and the overall signature also | 12:54 |
| Chipaca | but that gives an on-disc and on-the-wire format that are the same, and an in-store format that lets us edit metadata | 12:55 |
| * beuno nods | 12:55 | |
| Chipaca | and it's all *almost* there | 12:55 |
| sergiusens | beuno: it's fine for the store to provide more data; it's bad for it to modify provided data | 12:55 |
| Chipaca | we've just not been thinking about it in these terms | 12:55 |
| Chipaca | sergiusens: why is it bad? | 12:55 |
| beuno | sergiusens, it isn't, the user is! | 12:55 |
| Chipaca | gosh this coffee is strong :) | 12:56 |
| beuno | and I don't want to force the user to re-upload 800mb to fix a typo, or even generate a new file and upload that | 12:56 |
| beuno | there's a nice web ui for them to do that | 12:56 |
| sergiusens | Chipaca: the packaging layout is meant to be navigateable so the user can browse what's installed easily, if I look at package.yaml it will be all wrong | 12:56 |
| Chipaca | sergiusens: you weren't following me maybe | 12:56 |
| Chipaca | sergiusens: or maybe i wasn't clear | 12:57 |
| sergiusens | Chipaca: if we delete package.yaml (or most of it) then fine | 12:57 |
| sergiusens | and please lets get rid of readme.md | 12:57 |
| Chipaca | sergiusens: the on-disc (and on-the-wire) format of the snap package has all the metadata in one place; call it the package.yaml | 12:57 |
| sergiusens | Chipaca: that's _$version | 12:57 |
| sergiusens | which we talked about | 12:58 |
| Chipaca | sergiusens: the store streams out the package.yaml from the database, and the binary blob from wherever; the client just gets a stream with package.yaml in there | 12:58 |
| sergiusens | Chipaca: ok, and does that need constant updating? | 12:58 |
| Chipaca | sergiusens: that is a separate discussion i have no horse in | 12:59 |
| beuno | Chipaca, sergiusens, another example of out-of-package metadata is release | 12:59 |
| Chipaca | sergiusens: it could be, it could not be | 12:59 |
| Chipaca | sergiusens: also, this might make _$version not necessary | 12:59 |
| Chipaca | but we are talking something that is not jfdi-level of change | 13:00 |
| beuno | and one that is convenient, because we can re-target the same binary to newer releases without changing it | 13:00 |
| * JamesTait heads off for lunch | 13:00 | |
| sergiusens | beuno: I know of all these extras, I just don't like the sources being mangled with | 13:01 |
| Chipaca | beuno: while we're at it, if in the store a binary is a stream of (data,signature) pairs, you could store and stream deltas instead of whole packages | 13:01 |
| sergiusens | beuno: if the source is the store and the only reason we have a package.yaml is to seed, then it shouldn't be there at all | 13:01 |
| beuno | Chipaca, not sure I follow, deltas is still being pondered by mvo, on where to slice | 13:02 |
| beuno | per file, binary deltas, etc | 13:02 |
| Chipaca | beuno: i'm not sure we're talking of the same level of deltas; what i mean is you could xdelta v1 and v2 and only store/stream the xdelta between them (looking at the binary blob alone) | 13:06 |
| Chipaca | but that's probably exactly what mvo is looking at :) | 13:06 |
| Chipaca | and it's even more pie-in-the-sky than the rest of the above | 13:06 |
| Chipaca | sergiusens: i'm not sure i understand your "seeding" argument | 13:06 |
| sergiusens | Chipaca: that was martin's initial argument, package.yaml is in the package just to seed the initial store configuration. | 13:08 |
| sergiusens | Chipaca: and that it shouldn't be relied upon | 13:08 |
| Chipaca | sergiusens: but that's not where we finished, is it? | 13:09 |
| sergiusens | Chipaca: if we stream the files as you say, this may be not relevant but is considered "tampering" with the packaging | 13:09 |
| sergiusens | Chipaca: changing uploaded files is weird, but then again it's not as the same user is changing them from a webform | 13:09 |
| sergiusens | unless they do package signing themselves... | 13:10 |
| Chipaca | sergiusens: we could build and sign the binary blob (and by binary blob here i mean everything-user-provided-but-meta/) with the user's key, and sign the meta blob with our key | 13:11 |
| Chipaca | sergiusens: because meta is “ours” | 13:11 |
| Chipaca | that's the whole point | 13:11 |
| Chipaca | well, it's one of the whole points :-p | 13:12 |
| nessita | beuno, Chipaca , JamesTait: correct that the store treats snaps and clicks 95% equally. And yes, for now we only support .json files for the package metadata on upload | 13:12 |
| sergiusens | Chipaca: your idea makes me happy; well anything that gets us out of N sources of information makes me happy | 13:12 |
| Chipaca | sergiusens: note my idea is 95%* reinterpreting what we already have | 13:13 |
| Chipaca | * some statistics copied from nessita | 13:13 |
| sergiusens | lol | 13:13 |
| Chipaca | and then following up those reinterpretations, but nothing "new" really there | 13:13 |
| Chipaca | anyway, somebody should write this down before we forgot we agreed on something | 13:14 |
| sergiusens | Chipaca: that's why we have architects; let's leave that to th people about to sprint :-P | 13:14 |
| * beuno hits control + p > A4 > Print | 13:14 | |
| Chipaca | i'll send an email | 13:14 |
| Chipaca | beuno: +1 :) | 13:15 |
| sergiusens | Chipaca: I sent a short one to rsalveti to start discussing during the architecture meetings | 13:15 |
| sergiusens | Chipaca: before I thought the conversation would stop short (as it did most of the time) | 13:15 |
| * sergiusens now feels hungry after what just happened | 13:16 | |
| seb128 | sergiusens, hey, I saw that you have goget changes up for review for personnal, any idea when that should land? | 13:22 |
| sergiusens | seb128: in a bit | 13:29 |
| sergiusens | seb128: but the images I create go into a boot loop (kvm) | 13:29 |
| sergiusens | seb128: did you have a succesful build yet? | 13:29 |
| seb128 | sergiusens, yeah, I don't understand | 13:29 |
| seb128 | grub has 4 entries | 13:29 |
| seb128 | the first one which is snappy boot and goes back to grub | 13:29 |
| seb128 | the "ubuntu" one fails to boot/hang in the middle of init jobs | 13:30 |
| seb128 | I tried to boot on upstart, it stops on what seems like cloud-init's job having issues with the fs being ro | 13:30 |
| seb128 | exceptions about creating a dir | 13:30 |
| seb128 | sergiusens, yeah, I got it to work on amd64, doesn't work on i386 though (it's still giving me the partitions error, even with the 10G) | 13:31 |
| sergiusens | seb128: there shouldn't be differences there | 13:33 |
| sergiusens | seb128: also try sudo losetup -d /dev/loop[0-9] before starting | 13:34 |
| seb128 | sergiusens, thanks | 13:34 |
| seb128 | sergiusens, anyway the amd64 issue is having those boot issues, I'm trying to have a look but didn't find anything useful so far | 13:34 |
| seb128 | did you? | 13:34 |
| sergiusens | seb128: no, this was late last night | 13:35 |
| dholbach | hey JamesTait - I have a question :) | 13:37 |
| dholbach | JamesTait, if I use the app store APIs, can I filter for certain snap types? | 13:37 |
| JamesTait | dholbach, "certain snap types"? | 13:37 |
| dholbach | JamesTait, like a gadget snap, a framework snap, etc | 13:38 |
| dholbach | https://developer.ubuntu.com/en/snappy/guides/package-metadata/ → 'type' | 13:39 |
| JamesTait | dholbach, I don't know if we have that metadata available. The analogue in click packages would be content: app|scope I think. | 13:39 |
| sergiusens | JamesTait: we do | 13:40 |
| dholbach | JamesTait, can I filter for snaps right now, as opposed to clicks? | 13:40 |
| sergiusens | JamesTait: dholbach https://search.apps.ubuntu.com/api/v1/package/docker "content" in there | 13:41 |
| sergiusens | as an example | 13:41 |
| nessita | JamesTait, we do have it, in the same field | 13:41 |
| nessita | allowed types for far are application, framework | 13:41 |
| nessita | (for snaps) | 13:41 |
| sergiusens | nessita: and oem | 13:41 |
| JamesTait | nessita, right, I was just trying to find one. ☺ | 13:41 |
| sergiusens | here's an oem one https://search.apps.ubuntu.com/api/v1/package/beagleblack | 13:42 |
| sergiusens | dholbach: to filter pass X-Ubuntu-Framework: ubuntu-core-15.04-dev1 (when can we rid ourselves from this? :-P) | 13:42 |
| JamesTait | dholbach, https://search.apps.ubuntu.com/api/v1/search?q=content:"framework" | 13:43 |
| sergiusens | dholbach: and also X-Ubuntu-Release: [15.04-core|rolling-core|rolling-personal] | 13:43 |
| nessita | sergiusens, what do you mean with getting rid of the framework header? | 13:44 |
| sergiusens | JamesTait: can we do that with release and framework as well? | 13:44 |
| sergiusens | nessita: as in ubuntu-core-15.04-dev1 | 13:44 |
| sergiusens | nessita: it's a meta question, I know it was set back in due to some apparmor issues as well ;-) | 13:44 |
| === rickspencer3_ is now known as rickspencer3 | ||
| JamesTait | sergiusens, yes, you can. | 13:45 |
| sergiusens | kyrofa: do you have time to meet today? | 13:45 |
| sergiusens | JamesTait: neat, which is more efficient? as query param or http header? | 13:45 |
| sergiusens | rsalveti: https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.24-0ubuntu1 (why it is in no pocket I don't know) | 13:46 |
| JamesTait | sergiusens, they're slightly different. As an HTTP header makes it a filter, so the index will only return results that depend *only* on frameworks that are in your list. | 13:47 |
| rsalveti | sergiusens: in a vortex :-) | 13:47 |
| rsalveti | sergiusens: thanks | 13:47 |
| JamesTait | sergiusens, if you send "X-Ubuntu-Frameworks: ubuntu-core-15.04", then packages that declare 'framework: ["ubuntu-core-15.04", "docker-1.0"]' won't be returned. | 13:48 |
| JamesTait | sergiusens, whereas just putting it in the query string will return them regardless. | 13:48 |
| sergiusens | JamesTait: so http header is all or nothing? You make me ask questiong about our code base now :-P | 13:49 |
| JamesTait | sergiusens, HTTP header filters out stuff you can't install (due to missing frameworks). So phones don't see packages targered at core, for example. | 13:51 |
| JamesTait | Yet, anyway. | 13:51 |
| sergiusens | JamesTait: but it's an || and not and && right? | 13:53 |
| sergiusens | JamesTait: as in you have to satisfy at least one of the declared frameworks | 13:54 |
| === chihchun is now known as chihchun_afk | ||
| JamesTait | sergiusens, you have to satisfy all of the frameworks that the package declares. It's neither || nor && because you might have a bunch of other frameworks installed that make no difference to the package. As long as what's in the package metadata is a subset of what you send in the header, you'll see the package. | 13:56 |
| JamesTait | sergiusens, there's an example in https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex#Frameworks | 13:58 |
| elopio | fgimenez: meeting | 14:03 |
| fgimenez | elopio, omw | 14:04 |
| sergiusens | JamesTait: shouldn't this http://paste.ubuntu.com/11730647/ only return docker? | 14:07 |
| JamesTait | sergiusens, it should return packages where framework is one of: ["docker"] ["docker", "ubuntu-core-15.04-dev1"] ["ubuntu-core-15.04-dev1"] | 14:09 |
| sergiusens | JamesTait: ah, so that was an || in my mind :-P | 14:13 |
| fgimenez | sergiusens, adding a 'img' flag would help? something like 'go run _integration-tests/main.go -img /path/to/img' | 14:27 |
| sergiusens | fgimenez: well, I need to test the u-d-f output too | 14:29 |
| sergiusens | fgimenez: stdout should warn about --device | 14:29 |
| sergiusens | rsalveti: we need an ubuntu-snappy release and to rebuild u-d-f after that to allow --install docker :-/ | 14:33 |
| rsalveti | sergiusens: sure | 14:34 |
| rsalveti | sergiusens: anything waiting to be merged in ubuntu-snappy or can we just release current trunk? | 14:35 |
| sergiusens | @activereviews | 14:36 |
| nothal | sergiusens: No such command! | 14:36 |
| sergiusens | @activereview | 14:36 |
| nothal | sergiusens: No such command! | 14:36 |
| sergiusens | @help | 14:36 |
| nothal | "list" To see the available commands ; "help cmd" for specific command help | 14:36 |
| sergiusens | @list | 14:36 |
| nothal | The available commands are: ['bug', 'critical', 'help', 'last', 'list', 'more', 'ping', 'reviewlist', 'seen'] | 14:36 |
| sergiusens | @reviewlist | 14:36 |
| nothal | https://code.launchpad.net/~mvo/snappy/snappy-gettext/+merge/262202 | No reviews (less than a day old) | 14:36 |
| nothal | https://code.launchpad.net/~mvo/snappy/snappy-console/+merge/262061 | Approve: 1 (less than a day old) | 14:36 |
| nothal | https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748 | No reviews (5 days old) | 14:36 |
| nothal | https://code.launchpad.net/~mvo/snappy/snappy-verify/+merge/261718 | No reviews (5 days old) | 14:36 |
| nothal | https://code.launchpad.net/~mvo/snappy/snappy-improve-developer-mode-detection/+merge/261646 | No reviews (6 days old) | 14:36 |
| ogra_ | @tellsergiuenstostopplaying | 14:37 |
| nothal | ogra_: No such command! | 14:37 |
| sergiusens | ogra_: I was tied to lp speak | 14:37 |
| ogra_ | heh | 14:37 |
| sergiusens | rsalveti: no, nothing in queue | 14:37 |
| rsalveti | let me release that then | 14:39 |
| JamesTait | sergiusens, sorry to disappear; other people needing attention, school run, I need a clone. ☺ | 14:46 |
| JamesTait | sergiusens, so a query string like ?q=framework:ubuntu-sdk-15.04-dev1,framework:docker would give you an || | 14:47 |
| sergiusens | fgimenez: maybe update _integration-tests/README with the go run comment | 14:56 |
| rsalveti | sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.2-0ubuntu1 | 14:56 |
| sergiusens | rsalveti: thanks | 14:57 |
| JamesTait | Also, sergiusens, by default query-string search terms are analysed and do prefix matching, so ?q=framework:docker will also match packages with framework: ["docker-1.3"]. Wrapping the term in quotes should prevent that and make it a literal phrase search, but that doesn't seem to be the case any more. I'll need to dig a bit to work out why. | 15:01 |
| sergiusens | JamesTait: it does literals for package names at least as nessita showed me | 15:01 |
| sergiusens | JamesTait: so I want headers and not query strings for this and that last comment settles it | 15:02 |
| nessita | sergiusens, yes you do | 15:03 |
| sergiusens | nessita: err, what | 15:04 |
| * JamesTait grabs a drink | 15:04 | |
| sergiusens | nessita: in any case I know what I mean :-) | 15:05 |
| seb128 | sergiusens, I found issues on the iso build which explain the hang, fixing them in livecd-rootfs now | 15:05 |
| sergiusens | seb128: oh nice, any reason why the image is so big? | 15:05 |
| seb128 | sergiusens, define "so big"? | 15:06 |
| seb128 | it's 2.5G | 15:06 |
| ogra_ | compressed ?!? | 15:06 |
| seb128 | ogra_, well, the ubuntu desktop iso is likge 1G | 15:07 |
| sergiusens | ogra_: 2.5 uncompressed | 15:08 |
| seb128 | and the snappy image is x2 because of the a-b partitions | 15:08 |
| seb128 | so seems about right to me? | 15:08 |
| ogra_ | ah, uncompressed | 15:08 |
| ogra_ | that sounds rather sane | 15:09 |
| fgimenez | sergiusens, sure thx! elopio suggested changing the way we build images depending on the type of test being executed | 15:09 |
| kgunn | jdstrand: tyhicks thanks for help y'day, i made good progress....last thing i'm struggling with is a script that is part of the snap that launches the server | 15:09 |
| kgunn | i'm getting ubuntu-core-launcher:/apps/mir/snap1/bin/server.real pidof: Operation not permitted | 15:09 |
| fgimenez | sergiusens, elopio we still need to define how to group tests tough | 15:09 |
| kgunn | but i've already add /bin/pidof to may aa file, which took care of the denial | 15:09 |
| kgunn | any ideas? | 15:10 |
| kgunn | http://bazaar.launchpad.net/~kgunn72/mir/snappy-packaging-with-secprofile/view/head:/server | 15:11 |
| kgunn | that's the script ^ | 15:11 |
| kgunn | is it b/c it's outside of the mir binary itself ? | 15:11 |
| sergiusens | kgunn: add u or U (I forget which one is the more correct one) | 15:12 |
| sergiusens | kgunn: /bin/pidof Umrix, | 15:13 |
| kgunn | sergiusens: thanks! i'll try that | 15:13 |
| kgunn | sergiusens: i had added everything but that i think :) | 15:13 |
| sergiusens | kgunn: I have that a plenty; uU is for run unconfined | 15:14 |
| sergiusens | one cleans up the env while the other doesn't | 15:14 |
| tyhicks | Ux scrubs the environment | 15:17 |
| kgunn | tyhicks: what means "scrubs" | 15:17 |
| * kgunn grunts like caveman | 15:17 | |
| tyhicks | kgunn: it attempts to remove any risky environment variables | 15:18 |
| ogra_ | kgunn, audio or it didnt happen ! | 15:18 |
| kgunn | :) | 15:19 |
| ogra_ | :) | 15:19 |
| tyhicks | I don't like the idea of snaps being able to do unconfined transitions while calling out to external binaries | 15:19 |
| tyhicks | I'm not sure if that's what jdstrand has been recommending for situations like this or not | 15:20 |
| tyhicks | using Ux will get you unblocked for now but we may end up wanting to do something more secure | 15:21 |
| kgunn | tyhicks: no problem....i'm game to be a guinea pig | 15:21 |
| kgunn | i am getting a little heat to get mir in the store tho :) | 15:21 |
| mvo_ | mterry: my work on the debian stuff https://github.com/mvo5/gettext/tree/debian | 15:21 |
| kgunn | tyhicks: do you consider using u on pidof ok for store use ? | 15:22 |
| longsleep | Hey folks, can someone explain the strategy how snappy can use the full disk / resizing automatically on first boot or something? | 15:22 |
| tyhicks | kgunn: well, jdstrand is the one that has been defining those boundaries so I'll defer to him | 15:22 |
| mterry | mvo_, I don't have a branch for mine -- sorry we collided, I tried to ping you but I think I got a stale copy of your irc client (mvo__ with two underscores if I recall) | 15:23 |
| mterry | mvo_, we used the same source and binary names, so at least we won't get two copies | 15:23 |
| mterry | mvo_, I fixed the test issue though by copying example files into the obj-* dir | 15:24 |
| barry | mvo_: yep, i'm confused :) can you elaborate on what you want for LP: #1466124 ? | 15:25 |
| ubottu | Launchpad bug 1466124 in system-image (Ubuntu) "Please provide a way to get the progress in used from a plugin" [Undecided,New] https://launchpad.net/bugs/1466124 | 15:25 |
| mvo_ | mterry: oh, nice! I thanks for fixing the tests. lets just merge it together | 15:25 |
| mvo_ | barry: meh, I figured I did not express myself very well | 15:25 |
| mterry | mvo_, just add | 15:25 |
| mterry | override_dh_auto_test: | 15:25 |
| mterry | # copy data files in | 15:25 |
| mterry | cp -r examples/*/ obj-*/src/github.com/gosexy/gettext/examples/ | 15:25 |
| mterry | dh_auto_test | 15:25 |
| mterry | mvo_, to yours | 15:25 |
| barry | mvo_: s'okay :) | 15:25 |
| mvo_ | barry: once sec, I'm in a meeting right now, won't help with being consistent | 15:25 |
| mvo_ | eh or understandable or anything really | 15:25 |
| mvo_ | mterry: \o/ | 15:26 |
| mterry | mvo_, and then maybe switch your deletion of those files to dh_auto_install rather than dh_auto_build | 15:26 |
| jdstrand | sergiusens: your 'U's and 'u's are not necessarily recommended | 15:27 |
| jdstrand | kgunn: can you paste the full denial? | 15:27 |
| jdstrand | kgunn: can you use 'rmix' (ie, don't use 'U') and try again, showing me the denial? | 15:28 |
| jdstrand | kgunn: is this something that can run in a kvm ubuntu-core image? | 15:28 |
| tyhicks | note that pidoff isn't as innocent as it may seem, from the pidof(8) man page: | 15:30 |
| tyhicks | "pidof is actually the same program as killall5" | 15:30 |
| jdstrand | yes | 15:30 |
| jdstrand | so I'd prefer ix so we can then use signal mediation | 15:30 |
| tyhicks | agreed | 15:31 |
| mvo_ | tedg: hi, so what exactly is it you need? the uri of the source package? | 15:31 |
| * jdstrand notes this is a framework, but frameworks are privileged and we should stop using demo policy and do real policy for these things | 15:31 | |
| tedg | mvo_, This is what I did. Get from binary packages to the list of dev packages associated with them: http://paste.ubuntu.com/11731018/ | 15:32 |
| tedg | mvo_, The list is hardcoded in that example. | 15:32 |
| mvo_ | tedg: thanks, let me have a look | 15:32 |
| mvo_ | tedg: http://paste.ubuntu.com/11731045/ is slightly shorter but yeah, srcpkg stuff is not the strength of python-apt | 15:37 |
| mvo_ | tedg: this examle needs updating in the api docs :/ it does not reflect the latest features of python-apt. thanks for finding that | 15:37 |
| tedg | mvo_, The other example that is really bad is this one, as it is camel case and the functions aren't: https://apt.alioth.debian.org/python-apt-doc/library/apt_pkg.html#apt_pkg.PackageRecords.lookup | 15:39 |
| tedg | mvo_, That's where I came up with the stuff that you deleted :-) | 15:39 |
| mvo_ | mterry: hm, if your package has this already fixed, we could simply use your version? | 15:41 |
| mvo_ | tedg: uh, indeed, that needs fixing | 15:42 |
| mvo_ | barry: ok, so … let me try again. we "hook" into the upgrade (the apply hook) with our custom upgrader. when that is run we currently check the options if the user requested to use machine-readable output | 15:42 |
| mterry | mvo_, other differences I see: I add misc:Built-Using, and I do actually ship the examples folder (since go seems to like to ship the _test.go files, and they are needed to make it work | 15:43 |
| mvo_ | barry: our branch set this in the global config object | 15:43 |
| mterry | mvo_, but I'm not convinced the examples folder should be shipped, so yours might be doing the right thing there | 15:43 |
| mvo_ | mterry: right, lets keep yours if its actually more complete, or is there a downside? | 15:43 |
| mterry | mvo_, just the examples folder | 15:43 |
| mterry | mvo_, and no source tree | 15:44 |
| mterry | mvo_, in vcs that is | 15:44 |
| mvo_ | barry: but it seems like with the current 3.0 I can not get the information if the user has requested a machine-readable output | 15:44 |
| kgunn | jdstrand: hey, sorry, was on a HO... | 15:44 |
| kgunn | yeah so i ran last night with | 15:44 |
| mterry | mvo_, how would we stop one of our uploads? | 15:44 |
| kgunn | /bin/pidof mrix, | 15:44 |
| mterry | I'm not used to cancelling an upload | 15:44 |
| kgunn | and the error was ubuntu-core-launcher:/apps/mir/snap1/bin/server.real pidof: Operation not permitted | 15:45 |
| mvo_ | mterry: ok, no vcs is ok, mine is just a single commit so far. and if yours does not need further changes I'm in favour of keep it :) | 15:45 |
| mterry | mvo_, alright | 15:45 |
| jdstrand | kgunn: what is the apparmor denial? grep DEN /var/log/syslog | 15:45 |
| barry | mvo_: oh, do you just mean that the hook doesn't know whether --progress=json was provided on the cli? | 15:45 |
| kgunn | jdstrand: that's just it....there's not one | 15:45 |
| mvo_ | mterry: we can just reject my upload, I can ask the archive admins to do that | 15:45 |
| mvo_ | barry: yeah, exactly that | 15:45 |
| mvo_ | barry: so it might be as simple as setting it as a transient config in the global config object | 15:46 |
| mvo_ | barry: thats what I did in the fork we are currently using | 15:46 |
| barry | mvo_: ah, okay, that should be easy to expose in the global config | 15:46 |
| barry | yeah | 15:46 |
| jdstrand | kgunn: is there a seccomp denial? | 15:46 |
| kgunn | jdstrand: nope | 15:46 |
| barry | mvo_: thanks, i'll update the bug description. is it worth holding up 3.0.1 into wily to actually do a quick 3.0.2, or can i target that at 3.1? | 15:47 |
| jdstrand | kgunn: did you disable kernel rate limiting? | 15:47 |
| kgunn | jdstrand: nope, but i can try that now | 15:47 |
| mvo_ | barry: its not blocking us, I just always spit out json to stdout now | 15:47 |
| barry | mvo_: cool, thanks | 15:48 |
| mvo_ | barry: which is bad but its only snappy thats driving it right now, so its not too terrible | 15:48 |
| barry | mvo_: ack | 15:48 |
| mvo_ | thanks! and sorry that it was so confused | 15:48 |
| barry | no worries! | 15:49 |
| barry | mvo_: thanks. description updated. please sanity check | 15:50 |
| mvo_ | barry: yes, thats it | 15:51 |
| barry | mvo_: \o/ | 15:53 |
| kgunn | jdstrand: so diabled kernel rate limiting (with sudo sysctl -w kernel.printk_ratelimit=0) | 15:59 |
| kgunn | run via systemctl start mir-blah.service | 16:00 |
| kgunn | the syslog just shows | 16:00 |
| kgunn | "systemd started system compositor" | 16:01 |
| kgunn | no seccomp or aa denial error | 16:01 |
| kgunn | but...system compositor doesn't appear in process list | 16:01 |
| ogra_ | hack it to spit out more info ? | 16:01 |
| ogra_ | (the systemd unit i mean) | 16:02 |
| jdstrand | kgunn: does the service try to drop privs and then regain them? | 16:03 |
| kgunn | jdstrand: i don't think so, the system compositors run as root.... | 16:06 |
| kgunn | mterry: ^ any privlegde changes ? | 16:07 |
| jdstrand | kgunn: try using @unrestricted as the seccomp policy | 16:07 |
| mterry | kgunn, I don't think so | 16:07 |
| mterry | kgunn, is it waiting for agetty? | 16:07 |
| mterry | kgunn, or did the server shell script bail for some reason? | 16:08 |
| kgunn | mterry: sorry to bother you this is all about getting sec policy for mir correct (as fmwk) to get in store.... | 16:09 |
| mterry | kgunn, right (pidof stuff still?) | 16:09 |
| kgunn | worked through all the aa & seccomp errors, now stuck on pidof in the launching script | 16:09 |
| kgunn | brb | 16:10 |
| elopio | ogra_: do you want to top-approve? https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 | 16:22 |
| kgunn | jdstrand: ok, so running with bin/pidof & bin/sleep :q | 16:24 |
| ogra_ | elopio, done | 16:24 |
| kgunn | oops ignore the :q | 16:24 |
| kgunn | pidof and sleep with mrux, and syslog shows both "Opertation not permitted" just like before | 16:25 |
| kgunn | note, that was without the kernel rate liimiting denial disabled | 16:26 |
| rsalveti | ogra_: sergiusens_: mvo_: one interesting problem: http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/pending/ | 17:08 |
| rsalveti | the azure device tarball is not getting updated from the build, since 9-jun | 17:09 |
| rsalveti | but from the build log, it seems it was created | 17:09 |
| rsalveti | how to find out what is going on at the cdimage side of things? | 17:09 |
| ogra_ | there should be cdimage logs | 17:11 |
| ogra_ | http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/wily/ | 17:11 |
| ogra_ | hmm, no mention of azure in there at all | 17:12 |
| ogra_ | could it be that they need to have manual intervention ? | 17:12 |
| rsalveti | maybe we're not building it | 17:12 |
| rsalveti | # now build the azure device tarball by adding walinuxagent | 17:12 |
| rsalveti | if [ -e binary/boot/filesystem.dir/var/lib/dpkg/info/walinuxagent.list ]; | 17:12 |
| rsalveti | the check | 17:12 |
| rsalveti | this is for vivid | 17:13 |
| rsalveti | yeah, we're not building it | 17:13 |
| ogra_ | right | 17:14 |
| rsalveti | # now build the azure device tarball by adding walinuxagent | 17:14 |
| rsalveti | if [ -e binary/boot/filesystem.dir/var/lib/dpkg/info/walinuxagent.list ]; | 17:14 |
| rsalveti | argh | 17:14 |
| ogra_ | if it exists cdimage downloads it as seen in http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/wily/daily-preinstalled-20150609.log | 17:14 |
| rsalveti | daily-preinstalled-20150609.log | 17:14 |
| rsalveti | the last one that had it | 17:14 |
| rsalveti | yeah | 17:14 |
| rsalveti | daily-preinstalled-20150612.log already failed to generate it | 17:14 |
| * rsalveti looks for walinuxagent related changes | 17:15 | |
| ogra_ | hmm http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/wily/daily-preinstalled-20150610.log ... that downloaded it as well | 17:15 |
| rsalveti | ogra_: right, that's wily | 17:15 |
| rsalveti | for vivid we don't have 0610 | 17:15 |
| ogra_ | oh | 17:15 |
| rsalveti | http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/vivid/?C=M;O=D | 17:15 |
| ogra_ | right | 17:16 |
| ogra_ | i missed the "vivid" in the url above | 17:16 |
| rsalveti | https://launchpadlibrarian.net/209278613/buildlog_ubuntu_vivid_amd64_ubuntu-core-system-image_BUILDING.txt.gz | 17:16 |
| rsalveti | but it seems it was actually created ^ | 17:16 |
| rsalveti | + tar -c -z -f /build/device.tar.gz system assets hardware.yaml | 17:17 |
| rsalveti | this from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/ | 17:17 |
| rsalveti | checking the latest amd64 image | 17:17 |
| jdstrand | kgunn: can you try with seccomp policy as @unrestricted? | 17:19 |
| jdstrand | kgunn: (sorry, been in a meeting) | 17:19 |
| * jdstrand is still in the meeting | 17:19 | |
| sergiusens_ | rsalveti: ogra_ we are probably not building it for wily and porbably don't want it either (to be replaced with gadget snaps) | 17:21 |
| rsalveti | sergiusens_: right, wily is fine to not build it | 17:22 |
| rsalveti | my concerned is that we're not building it for vivid | 17:22 |
| rsalveti | *concern | 17:22 |
| rsalveti | launchpad says we're building it, but the cdimage log is not showing that it copied it over | 17:22 |
| sergiusens_ | rsalveti: but, but, but we released a few weeks ago | 17:22 |
| rsalveti | sergiusens_: yeah, failed the next day | 17:22 |
| rsalveti | after the release | 17:22 |
| rsalveti | since the release day, we didn't get any other update | 17:23 |
| rsalveti | and nothing really changed on our side | 17:23 |
| sergiusens_ | rsalveti: system image's index says something different http://system-image.ubuntu.com/ubuntu-core/15.04/edge/azure_amd64/index.json | 17:24 |
| sergiusens_ | last entry, version_detail | 17:24 |
| rsalveti | sergiusens_: right, that is fine, since cdimage is publishing the tarball, but the older one | 17:24 |
| sergiusens_ | ah, the device tarball is stuck | 17:24 |
| rsalveti | that's the usual issue with the cdimage side | 17:24 |
| rsalveti | if something fails, it will just copy the older ones | 17:24 |
| rsalveti | http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/pending/ | 17:24 |
| rsalveti | sergiusens_: check the date ^ | 17:25 |
| sergiusens_ | rsalveti: let's blame ogra! | 17:25 |
| sergiusens_ | rsalveti: yeah, that's why I said device tarball is stuck :-P | 17:25 |
| sergiusens_ | I'll brb | 17:25 |
| ogra_ | yeah, just blame me | 17:25 |
| rsalveti | ogra_: where can I find the previous live-build logs? | 17:28 |
| rsalveti | since we moved that to launchpad | 17:29 |
| rsalveti | slangasek: maybe you can help with this ^? | 17:33 |
| rsalveti | basically I'm trying to figure out why device-azure.tar.gz wasn't published as part of cdimage for the last few images | 17:34 |
| slangasek | rsalveti: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core for instance? | 17:34 |
| rsalveti | slangasek: I'm looking at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/ | 17:34 |
| rsalveti | but I can only see a few | 17:34 |
| rsalveti | and not easily go back in time | 17:34 |
| slangasek | ah | 17:35 |
| slangasek | rsalveti: if you know which build you're looking for (from cdimage's POV), you can find the url to the exact build log in the log on nusakan | 17:35 |
| rsalveti | would be 20150609 | 17:36 |
| rsalveti | slangasek: do you know where to look? | 17:36 |
| slangasek | rsalveti: /srv/cdimage.ubuntu.com/log/ubuntu-core/wily/daily-preinstalled-20150609.log | 17:37 |
| slangasek | ubuntu-core-system-image-amd64 on Launchpad starting at 2015-06-09 04:56:02 | 17:37 |
| slangasek | ubuntu-core-system-image-amd64: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image/+build/29185 | 17:37 |
| rsalveti | slangasek: awesome, thanks! | 17:38 |
| rsalveti | yeah, build seems fine | 17:39 |
| * rsalveti looks for the cdimage cdo | 17:39 | |
| rsalveti | code | 17:39 |
| ogra_ | slangasek, any idea why we stopped mirroring them to http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ ? | 17:41 |
| ogra_ | it is quite handy to have all of them in one place | 17:41 |
| slangasek | no idea, no | 17:41 |
| rsalveti | ogra_: slangasek: so there is no 'azure' at all in the cdimage code | 17:42 |
| rsalveti | and the only update, that happened at last 11, was to add the personal | 17:42 |
| rsalveti | and that probably caused a sync | 17:43 |
| rsalveti | who added the azure logic in there? | 17:43 |
| ogra_ | well, i had the impression the cloud stuff was some manual process | 17:43 |
| seb128 | hum, so I got an image to boot in kvm | 17:43 |
| ogra_ | seb128, yay | 17:43 |
| seb128 | lightdm fails to start though | 17:43 |
| ogra_ | oooh :( | 17:43 |
| rsalveti | ogra_: the manual part is after it gets in system-image | 17:43 |
| ogra_ | rsalveti, ah, k | 17:43 |
| seb128 | "Error using VT_ACTIVATE 7 on /dev/console: Inappropriate ioctl for device" | 17:43 |
| seb128 | does that ring a bell to anyone? | 17:43 |
| slangasek | rsalveti: I don't think there were any changes required to the cdimage code for the azure device tarball. I thought the changes were only in livecd-rootfs | 17:44 |
| seb128 | I can starts gallery-app with xinit though :p | 17:44 |
| seb128 | so xorg is working | 17:44 |
| ogra_ | seb128, kgunn had fun with agetty and mir wrangling around a tty all day i think | 17:44 |
| rsalveti | slangasek: was thinking about cdimage because we need to copy the tarball over | 17:44 |
| rsalveti | after it gets published | 17:44 |
| rsalveti | if config.project in ("ubuntu-core", "ubuntu-desktop-next"): | 17:44 |
| rsalveti | device = "%s.device.tar.gz" % live_prefix | 17:44 |
| slangasek | rsalveti: right; so I never made any changes to the cdimage code to accomodate this, and if I had it would have been in the bzr branch | 17:44 |
| rsalveti | if os.path.exists(device): | 17:44 |
| rsalveti | shutil.copy2( | 17:44 |
| rsalveti | device, "%s.device.tar.gz" % output_prefix) | 17:44 |
| rsalveti | this is the piece that copy it over | 17:45 |
| rsalveti | live_prefix = os.path.join(live_dir, arch) | 17:45 |
| rsalveti | rootfs = "%s.rootfs.tar.gz" % live_prefix | 17:45 |
| rsalveti | so unless I'm not reading it right, there is indeed nothing copying it around | 17:46 |
| ogra_ | well, that code is pretty generic | 17:46 |
| ogra_ | do we perhaps have an architecture called "amd64.azure" ? | 17:47 |
| ogra_ | (would be odd to have a dot in there, but who knows) | 17:48 |
| rsalveti | right | 17:48 |
| rsalveti | ogra_: slangasek: I fail to see how this ever worked =\ | 18:01 |
| slangasek | rsalveti: indeed, I don't know either. I think mvo_ may have been the one doing the work on the azure device tarball at the time, maybe he remembers something? | 18:01 |
| rsalveti | https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/29944 | 18:01 |
| rsalveti | the tarball is there | 18:01 |
| rsalveti | mvo_: if still around ^? | 18:02 |
| rsalveti | at least the problem is consistent with both vivid and wily, and also started at last 11 | 18:09 |
| ogra_ | rsalveti, asac, some clarification about the support status in the RPi thread "Snappy RPi2 stable image #3 now available" would be appreciated ... | 18:12 |
| ogra_ | (seems he is rather grumpy about our communication and marketing) | 18:12 |
| sergiusens_ | rsalveti: azure is built from livecd-rootfs | 18:13 |
| rsalveti | sergiusens_: right, and it's there | 18:14 |
| rsalveti | just not imported/copied in cdimage | 18:14 |
| rsalveti | ogra_: sure | 18:14 |
| ogra_ | sergiusens_, and how is it getting onto cdimage.u.c ? | 18:14 |
| sergiusens_ | ogra_: that's all black magic and I only wish someone explained it so we could simplify it ;-) | 18:14 |
| rsalveti | for some reason I only had your reply and not the original email, which is now there (and was unread) | 18:14 |
| * sergiusens_ winks | 18:14 | |
| rsalveti | my gmail is kind of going crazy lately | 18:15 |
| sergiusens_ | ogra_: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/500-move-kernel-to-device-tar.binary | 18:15 |
| ogra_ | sergiusens_, ha, wishful thinking | 18:15 |
| sergiusens_ | rsalveti: I started using mutt again | 18:15 |
| rsalveti | sergiusens_: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/29944 | 18:15 |
| rsalveti | right, see the azure is there | 18:15 |
| rsalveti | sergiusens_: mutt + google imap? | 18:15 |
| sergiusens_ | I only go to gmail to search | 18:15 |
| sergiusens_ | rsalveti: yup, offlineimap | 18:15 |
| rsalveti | right, might be better indeed | 18:15 |
| ogra_ | evolution FTW :) | 18:15 |
| ogra_ | has still the fastest search tools | 18:16 |
| sergiusens_ | rsalveti: searching is good in gmail; organizing and cleaning up the queue and not missing content is better in a proper MUA | 18:16 |
| sergiusens_ | ogra_: makes you need a revolution in RAM though | 18:16 |
| ogra_ | my XPS copes fine with its 8G | 18:16 |
| ogra_ | and i dont have any device in use with less anymore | 18:17 |
| ogra_ | (for desktop that is) | 18:17 |
| sergiusens_ | rsalveti: so the build is there; what is missing? | 18:17 |
| ogra_ | sergiusens_, the code in cdimage that copies it | 18:17 |
| ogra_ | we dont know how it got from here to there | 18:17 |
| ogra_ | (the logs show it gets copied) | 18:17 |
| ogra_ | http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/vivid/daily-preinstalled-20150609.log | 18:17 |
| ogra_ | 2015-06-09 14:18:50 URL:https://launchpadlibrarian.net/208661665/livecd.ubuntu-core.azure.device.tar.gz [142562062/142562062] -> "/srv/cdimage.ubuntu.com/scratch/ubuntu-core/vivid/daily-preinstalled/live/amd64.azure.device.tar.gz" [1] | 18:18 |
| rsalveti | yeah, was looking at the code, but can't see to find how it was copying ti before | 18:18 |
| rsalveti | sergiusens_: check lp:ubuntu-cdimage | 18:18 |
| rsalveti | grep for "Downloading live filesystem images" | 18:18 |
| rsalveti | that is where the magic happens | 18:18 |
| ogra_ | ogra@styx:~/Devel/branches/cdimage$ grep -r azure * | 18:19 |
| ogra_ | ogra@styx:~/Devel/branches/cdimage$ | 18:19 |
| ogra_ | thats the weird part | 18:19 |
| rsalveti | that copy the files from launchpad into /srv/cdimage.ubuntu.com/scratch/ubuntu-core/vivid/daily-preinstalled/live | 18:19 |
| rsalveti | which is the missing link, because it's not copying over the azure tarball | 18:19 |
| ogra_ | well, i dont get how it would even know about azure at all | 18:20 |
| mvo_ | rsalveti: let me read scrollback and look at the code. so the problem started on the 11th this month? | 18:20 |
| ogra_ | given it is neither mentioned in the code nor in the config | 18:20 |
| rsalveti | mvo_: yes | 18:20 |
| ogra_ | (or in any bzr changelog) | 18:20 |
| mvo_ | how confusing, my first guess is a livecd-rootfs upload | 18:20 |
| rsalveti | mvo_: it's not livecd-rootfs, since it's there: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/29944 | 18:20 |
| mvo_ | I'm sure the ubuntu-personal guys broke it | 18:20 |
| ogra_ | mvo_, not really, livecd-rootfs does what it should | 18:20 |
| rsalveti | the device tarball was built | 18:20 |
| mvo_ | meh | 18:20 |
| ogra_ | cdimage doesnt import it | 18:21 |
| mvo_ | there goes my theory and the blame I wanted to assign :/ | 18:21 |
| ogra_ | i got blamed already, find someone else :P | 18:21 |
| * ogra_ only takes the blame once a day | 18:21 | |
| rsalveti | mvo_: so it might be connected with personal | 18:21 |
| rsalveti | mvo_: there was a personal change in cdimage at 11 | 18:21 |
| rsalveti | which would probably cause a sync in the bzr repo | 18:22 |
| rsalveti | so if the azure change was done outside trunk, then it would be lost | 18:22 |
| ogra_ | uh | 18:22 |
| ogra_ | but who would do that | 18:22 |
| ogra_ | https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup ... | 18:22 |
| rsalveti | that's just a theory | 18:22 |
| ogra_ | (in case people dont use that way ... ) | 18:23 |
| rsalveti | unless I'm missing some magic in lp:ubuntu-cdimage | 18:23 |
| seb128 | mvo_, nice blame try! | 18:24 |
| * mvo_ hugs seb128 | 18:24 | |
| * seb128 hugs mvo_ back ;-) | 18:24 | |
| ogra_ | and so subtle :) | 18:24 |
| rsalveti | yeah, the branch was pushed at 11 by Laney | 18:27 |
| rsalveti | reflecting the personal changes, but that has nothing to do with azure | 18:27 |
| slangasek | rsalveti: we wouldn't normally do a 'bzr pull --overwrite'; if someone did that, that's quite bad | 18:27 |
| ogra_ | right, makes your theory more plausible | 18:27 |
| slangasek | the usual protocol is 'bzr pull'; notice conflicts; yell at cowboys | 18:27 |
| rsalveti | right | 18:28 |
| ogra_ | and the branches are bound you wouldnt ever be able to commit | 18:29 |
| ogra_ | OH ! | 18:29 |
| ogra_ | but perhaps the config is in debian-cd, not cdimage | 18:29 |
| * ogra_ goes checking | 18:29 | |
| ogra_ | hmm, no | 18:30 |
| ogra_ | ogra@styx:~/Devel/branches/debian-cd$ grep -r azure * | 18:30 |
| ogra_ | ogra@styx:~/Devel/branches/debian-cd$ | 18:30 |
| rsalveti | another funny thing I noticed because of this | 18:35 |
| rsalveti | the kernel config seems to be available via the rootfs | 18:35 |
| rsalveti | after creating the azure image I had vmlinuz-3.19.0-18-generic and config-3.19.0-21-generic | 18:35 |
| rsalveti | at /boot | 18:35 |
| ogra_ | yeah | 18:36 |
| mvo_ | rsalveti: yeah, we keep it in /boot because our grub needs it this way, we want to consolidate this | 18:36 |
| ogra_ | well, we dont have /proc/config.gz enabled | 18:36 |
| ogra_ | they are on the arm images too | 18:36 |
| ogra_ | needs cleanup ... | 18:36 |
| rsalveti | mvo_: right, but why is this part of the rootfs? | 18:36 |
| rsalveti | yeah, will open a bug in a few | 18:36 |
| mvo_ | rsalveti: oh, right, we don't want it there | 18:37 |
| sergiusens_ | mvo_: ogra_ rsalveti so is this what is needed? http://paste.ubuntu.com/11731958/ | 18:43 |
| sergiusens_ | I just blindly added that | 18:43 |
| mvo_ | sergiusens_: could well be, I'm trying to understand why it worked before :/ | 18:43 |
| ogra_ | not sure you want azure hardcoded there | 18:43 |
| rsalveti | sergiusens_: something similar to that is what I had in mind, but the question is indeed what mvo_ just said | 18:43 |
| rsalveti | for now I just manually copied over the new tarball and triggered a new image | 18:44 |
| rsalveti | see if it will show up at system-image, so I can unblock people (that were waiting for an updated initrd) | 18:44 |
| mvo_ | rsalveti, sergiusens_: it seems like your change is exactly what was there and is no longer, the logs even have "Publishing amd64 azure device tarball " (I guess you know that already). really strange | 18:50 |
| rsalveti | yeah | 18:51 |
| rsalveti | too bad this is not git | 18:51 |
| rsalveti | git reflog would explain it all | 18:51 |
| ogra_ | rsalveti, even if someone forcefully overwrote it ? | 18:52 |
| rsalveti | ogra_: yup | 18:52 |
| ogra_ | (including history) | 18:52 |
| ogra_ | interesting | 18:52 |
| sergiusens_ | rsalveti: mvo_ a bzr push --overwrite to lp or a bzr pull --overwrite on the client explains most of this to me | 18:52 |
| rsalveti | it's my solution when I do git reset --hard HASH | 18:52 |
| * ogra_ guesses some day he wont get around looking at git :P | 18:52 | |
| sergiusens_ | ogra_: as soon as we move to it ;-) | 18:52 |
| rsalveti | and then omg omg omg I forgot to save a patch | 18:52 |
| ogra_ | (i must admit i'm surprised that i still do :) ) | 18:52 |
| rsalveti | git reflog gives me the complete history | 18:52 |
| rsalveti | sergiusens_: yeah | 18:53 |
| mvo_ | sergiusens_: yeah, I think thats it | 18:53 |
| mvo_ | and someone *cough* *cough* cowboyed it in | 18:53 |
| mvo_ | before without a proper branch | 18:53 |
| * mvo_ hides in shame | 18:53 | |
| mvo_ | but to be fair, that azure enablement was really on a super tight deadline | 18:54 |
| ogra_ | mvo_, https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup ... for next time :) | 18:54 |
| ogra_ | though still, while you cowboyed it in, someone overwrote it ignoring the error | 18:55 |
| ogra_ | bzr definitely complained | 18:55 |
| mvo_ | sergiusens_: this may need a additional download_live_items() in lib/cdimage/livefs.py | 18:55 |
| mvo_ | ogra_: indeed | 18:56 |
| * ogra_ blames Laney in absence :) | 18:56 | |
| ogra_ | finally we can pass on the blame :) | 18:56 |
| rsalveti | yeah, the push --overwrite was even worse | 18:58 |
| sergiusens_ | mvo_: like http://paste.ubuntu.com/11732046/ ? | 19:01 |
| sergiusens_ | I don't really follow this code base :-P | 19:01 |
| ogra_ | i still think it should somehow be injected into source_prefix instead of hardcoding it | 19:02 |
| mvo_ | sergiusens_: yeah, I think something like this | 19:02 |
| sergiusens_ | ogra_: I would leave that to you :-P | 19:03 |
| sergiusens_ | well I pushed here: lp:~sergiusens/ubuntu-cdimage/azure | 19:03 |
| * rsalveti hands the cowboy hat to mvo_ | 19:03 | |
| mvo_ | sergiusens_: \o/ | 19:03 |
| sergiusens_ | in case you want to merge | 19:03 |
| * sergiusens_ wants the cowboy hat | 19:03 | |
| ogra_ | sergiusens_, noh, go ahead if we need it now ... i'm being "studio_'ed" and annoyed enough to not want to write on code ... | 19:04 |
| sergiusens_ | will use it Clint Eastwood style | 19:04 |
| ogra_ | (i can take annother look tomorrow to see if i find another way) | 19:05 |
| sergiusens_ | ogra_: heh, so I don't mind this azure device as it will go away as soon as we solve the update-grub issue | 19:05 |
| mvo_ | sergiusens_: heh, so you cowboy^Wmerge it for testing? | 19:05 |
| ogra_ | sergiusens_, ah, well, then leave it ... | 19:05 |
| sergiusens_ | mvo_: do I have permissions? I forget :-P | 19:05 |
| ogra_ | mvo_, sergiusens_, make sure to follow the wiki doc though (./run-tests etc) | 19:05 |
| mvo_ | sergiusens_: I think so, but I know that I have | 19:06 |
| ogra_ | sergiusens_, you do | 19:06 |
| ogra_ | you got them together with rsalveti back then | 19:06 |
| sergiusens_ | ogra_: heh, I was playing dumb :-P | 19:07 |
| ogra_ | yeah, cant cheat me :P | 19:07 |
| sergiusens_ | ogra_: the tests fail here even without my changes! | 19:07 |
| mvo_ | sergiusens_: lol | 19:07 |
| ogra_ | oh man | 19:07 |
| ogra_ | Laney, !!! | 19:07 |
| mvo_ | his change does not look like it would break tests | 19:08 |
| mvo_ | but who knows | 19:08 |
| * mvo_ does not | 19:08 | |
| sergiusens_ | mvo_: coincidentally I have | 19:08 |
| sergiusens_ | mvo_: http://paste.ubuntu.com/11732086/ | 19:08 |
| sergiusens_ | but there are 4 failures regardless | 19:08 |
| jdstrand | kgunn_: did it work with @unrestricted? | 19:09 |
| mvo_ | sergiusens_: http://paste.ubuntu.com/11732091/ <- this is what I had to do back in the day to add support for device.tar.gz | 19:09 |
| mvo_ | sergiusens_: oh, I mean the changes that Laney did do not look like they would break stuff, but again, who knows | 19:10 |
| mvo_ | sergiusens_: it seems like item in live_item_path() might also want .azure in there :/ | 19:13 |
| sergiusens_ | mvo_: let me check; but I do have test parity now | 19:16 |
| kgunn_ | jdstrand: i definitely get some app armor denials..but the way the script is written is kinda spins outta control...so i'm gonna fix that real quick and run again | 19:16 |
| sergiusens_ | mvo_: I have a good feeling about this one http://paste.ubuntu.com/11732146/ thanks for your base branch for device | 19:19 |
| mvo_ | sergiusens_: yay, lets give it a try! | 19:20 |
| sergiusens_ | mvo_: ok, let me do an actual checkout | 19:20 |
| Chipaca | sergiusens_: mvo_: when can we have a coven about changes to snaps for 16.04? | 19:23 |
| sergiusens_ | tomorrow? | 19:23 |
| mvo_ | yep | 19:23 |
| ogra_ | 16.04 ? thats so far out ! | 19:23 |
| Chipaca | ogra_: far out, man! | 19:24 |
| Chipaca | sergiusens_: mvo_: +1 | 19:24 |
| sergiusens_ | ogra_: I don't need to pull -d debian-cd nor production, right? | 19:24 |
| ogra_ | sergiusens_, if you didnt make any changes to it, no | 19:24 |
| ogra_ | only cdimage should be enough | 19:24 |
| sergiusens_ | ogra_: just in case; gets out of the server asap | 19:24 |
| * mvo_ is very curious | 19:25 | |
| sergiusens_ | ogra_: mvo_ that's all I did http://paste.ubuntu.com/11732185/ | 19:26 |
| fikse | is there an argument for snappy ubuntu + consule + ... | 19:26 |
| fikse | vs coreos? | 19:26 |
| Chipaca | mvo_: about changes to snaps? | 19:26 |
| sergiusens_ | so I guess we can trigger a build now | 19:26 |
| fikse | consul, not consule | 19:26 |
| Chipaca | fikse: what's consul? | 19:26 |
| ogra_ | sergiusens_, perfect | 19:26 |
| sergiusens_ | consult maybe? | 19:26 |
| fikse | a tool for service discovery https://consul.io/ | 19:27 |
| mvo_ | Chipaca: about changes to snaps? | 19:27 |
| Chipaca | mvo_: * mvo_ is very curious | 19:27 |
| mvo_ | sergiusens_: now its time to run a build, no? | 19:27 |
| sergiusens_ | mvo_: yup | 19:28 |
| mvo_ | Chipaca: mostly about if sergiusens_ saved the day, I think he did! | 19:28 |
| sergiusens_ | is that nusakan? | 19:28 |
| mvo_ | Chipaca: but the snap stuff is interessting as well | 19:28 |
| mvo_ | sergiusens_: yes | 19:28 |
| * sergiusens_ logs back in | 19:28 | |
| * sergiusens_ gets goosebumps | 19:28 | |
| * ogra_ grins | 19:28 | |
| sergiusens_ | mvo_: last time I was in there we were fixing that crazy system image server indexing problem :-P | 19:28 |
| Chipaca | fikse: depending on what you do, it might be perfect, or it might be too early for snappy :) | 19:31 |
| sergiusens_ | ogra_: mvo_ which one should we try wily or vivid? | 19:31 |
| * sergiusens_ goes for wily | 19:31 | |
| ogra_ | yeah | 19:32 |
| mvo_ | +1 | 19:32 |
| fikse | Chipaca: i'm afraid it might be too early | 19:33 |
| elopio | sergiusens_: can you get your server running the snapcraft tests? | 19:34 |
| sergiusens_ | too early it is then | 19:34 |
| sergiusens_ | elopio: if it's in the .tarmac.sh, yes | 19:34 |
| ogra_ | geez, we have tests already ? | 19:34 |
| ogra_ | snapcraft doesnt even exist ! | 19:34 |
| ogra_ | you guys are so ahead | 19:34 |
| * ogra_ makes a note to check the test code to know what he will develop in a few months | 19:35 | |
| elopio | tdd baby! | 19:35 |
| elopio | sergiusens_: yes, there's a .tarmac.sh. | 19:35 |
| sergiusens_ | elopio: just add it there | 19:35 |
| sergiusens_ | ogra_: I don't see the build here https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image | 19:36 |
| ogra_ | whats the line you ran ? | 19:36 |
| sergiusens_ | ogra_: SUBPROJECT=system-image EXTRA_PPAS=snappy-dev/image for-project ubuntu-core cron.daily-preinstalled | 19:36 |
| ogra_ | hmm, looks fine | 19:36 |
| sergiusens_ | ogra_: generally do crontab -l |grep something | 19:37 |
| ogra_ | oh | 19:37 |
| ogra_ | --live | 19:37 |
| Chipaca | fikse: give it a try if you want; there's a couple of non-framework services (e.g. the xkcd-webserver) in lp:~snappy-dev/snappy-hub/snappy-examples | 19:37 |
| sergiusens_ | ogra_: I thought you told me way back not to use that :-P | 19:37 |
| ogra_ | you should always use whats in the crontab | 19:37 |
| sergiusens_ | ogra_: ok; but I'll search for that conversation :-P | 19:37 |
| kgunn_ | ubuntu | 19:38 |
| kgunn_ | oops | 19:38 |
| kgunn_ | ww | 19:38 |
| ogra_ | now change your password | 19:38 |
| sergiusens_ | kgunn_: we now know your password! | 19:38 |
| ogra_ | quick ! | 19:38 |
| ogra_ | (make it ubuntu1 ... nobody will guess that) | 19:38 |
| sergiusens_ | ogra_: mvo_ rsalveti ok, building here now https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image | 19:38 |
| sergiusens_ | ubuntu123 | 19:38 |
| ogra_ | yay | 19:38 |
| sergiusens_ | ubuntu123! | 19:38 |
| sergiusens_ | or maybe password :-) | 19:38 |
| ogra_ | nah, i use that already ... he cant take that | 19:39 |
| mvo_ | sergiusens_: ooooohhhh | 19:39 |
| sergiusens_ | ogra_: where is our powerpc build? :-) | 19:39 |
| ogra_ | sergiusens_, you just changed the cdimage code ... why didnt you add it ! | 19:39 |
| fisch246 | will snappy personal eventually merge back to the current branch of Ubuntu Desktop when it's deemed ready? | 19:45 |
| ogra_ | merge back ? | 19:45 |
| fisch246 | so for example when 16.10 comes out for example, and everyone decides snappy and unity8 is ready, everyone running Ubuntu desktop will upgrade to snappy and unity8 in 16.10 | 19:46 |
| ogra_ | you mean if there will be a deb based desktop install with unity8 ? | 19:46 |
| * ogra_ guesses thats a question for #ubuntu-desktop actually | 19:47 | |
| fisch246 | nah it would be snappy | 19:47 |
| ogra_ | i suspect though that we wont auto-migrate users from deb based systems to snappy | 19:47 |
| fisch246 | so basically would the deb based version be dropped | 19:47 |
| fisch246 | ah okay | 19:47 |
| fisch246 | so if people want to stick with deb they will stay deb for good if they wish | 19:47 |
| ogra_ | no, there are too many people using the deb archive ... (flavours and such) ... | 19:47 |
| fisch246 | well for now at least | 19:48 |
| ogra_ | for a snappy install you will most likely do an install from scratch | 19:48 |
| fisch246 | cool thanks that answers my question :) | 19:48 |
| sergiusens_ | ogra_: I wasn't thinking straight, we need powerpc urgently for the device I don't have! | 19:48 |
| sergiusens_ | :-D | 19:48 |
| ogra_ | and also snappy is built from debs from the archive | 19:48 |
| ogra_ | sergiusens_, well, its a one line change in the config :) | 19:49 |
| ogra_ | (modulo image build failures etc indeed) | 19:49 |
| * rsalveti reads backlog (back from a meeting) | 19:58 | |
| DarwinF | what's the process for adding/removing/modifying users? | 19:58 |
| ogra_ | DarwinF, there is no proper process yet ... /var/lib/extrausers/ has the user data though | 20:00 |
| sergiusens_ | rsalveti: btw https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.24-0ubuntu2 | 20:01 |
| ogra_ | sergiusens_, your images are done btw | 20:01 |
| ogra_ | well, the livefs build | 20:02 |
| DarwinF | ogra_: thanks | 20:02 |
| rsalveti | sergiusens_: nice, so you fixed cdimage? | 20:02 |
| rsalveti | fixededed | 20:03 |
| sergiusens_ | rsalveti: I'm not sure yet :-P | 20:03 |
| ogra_ | rsalveti, but he forgot to add powerpc while doing that | 20:03 |
| rsalveti | lol, alright | 20:03 |
| rsalveti | that's super important | 20:03 |
| * rsalveti hands a few beers to sergiusens_ | 20:04 | |
| ogra_ | hmm | 20:04 |
| sergiusens_ | rsalveti: http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/pending still shows June 11 for azure | 20:04 |
| ogra_ | daily | 20:04 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/20150617.3/ | 20:04 |
| sergiusens_ | not sure if I need to wait for all builds to finish here | 20:04 |
| sergiusens_ | ogra_: wily-preinstalled-core-amd64.azure.device.tar.gz 11-Jun-2015 05:13 140M | 20:05 |
| ogra_ | no, thats up to date i think | 20:05 |
| sergiusens_ | 11 and not 17 | 20:05 |
| ogra_ | yes | 20:05 |
| ogra_ | before it was 09 | 20:05 |
| rsalveti | wily was 11 | 20:05 |
| rsalveti | 09 was vivid | 20:05 |
| ogra_ | oh | 20:05 |
| rsalveti | and for vivid I manually replaced earlier today http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/pending/ | 20:05 |
| === j12t_ is now known as j12t | ||
| rsalveti | as a workaround | 20:05 |
| rsalveti | but, it seems the importer still didn't see the new image | 20:06 |
| sergiusens_ | ogra_: where is that "Publishing " message supposed to be logged? | 20:06 |
| rsalveti | which is super annoying | 20:06 |
| rsalveti | http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/20150617.2/ | 20:06 |
| sergiusens_ | rsalveti: I suspect that, but I don't know :-) | 20:06 |
| kgunn_ | jdstrand: ok...sorry, wanted to make sure and double check everything...so yeah, with @unrestricted i see aa denial for /sbin/killall5 | 20:07 |
| rsalveti | man, so many paths | 20:07 |
| kgunn_ | which makes sense based on what tyler said earlier | 20:07 |
| kgunn_ | e.g. pidof is actually part of killall5 | 20:07 |
| rsalveti | yeah, for wily it's still not there http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/pending/ | 20:07 |
| ogra_ | http://paste.ubuntu.com/11732394/ | 20:07 |
| ogra_ | sergiusens_, /srv/cdimage.ubuntu.com/log/ubuntu-core/wily/daily-preinstalled-20150617.3.log on nusakan | 20:08 |
| rsalveti | http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/wily/?C=M;O=D | 20:08 |
| rsalveti | yeah, more up-to-date log | 20:08 |
| ogra_ | no trace of azure there :( | 20:08 |
| rsalveti | no azure | 20:08 |
| jdstrand | kgunn_: ok, so use /sbin/killall5 ixr, | 20:09 |
| rsalveti | ogra_: how many hours is the importer taking nowadays? | 20:09 |
| ogra_ | the "publishing" actually comes from debian-cd i think | 20:09 |
| kgunn_ | ack, was doing as you typed | 20:09 |
| ogra_ | rsalveti, not long for core | 20:09 |
| rsalveti | seems there is one importer running atm | 20:10 |
| kgunn_ | jdstrand: so i should revert the /bin/pidof and bin/sleeps to ix as well ? (as i have them ux atm) | 20:10 |
| sergiusens_ | ogra_: I added Publishing logs in ubuntu-cdimage | 20:10 |
| ogra_ | yeah, and the word doesnt appear in a grep in debian-cd | 20:10 |
| ogra_ | only in cdimage | 20:10 |
| sergiusens_ | ogra_: something tells me this doesn't seem to be working if os.path.exists("%s.azure.device.tar.gz" % source_prefix) | 20:14 |
| ogra_ | yeah, i guess source_prefix is somehow a bit different | 20:15 |
| sergiusens_ | ogra_: different? livecd.ubuntu-core.azure.device.tar.gz vs livecd.ubuntu-core.device.tar.gz | 20:16 |
| ogra_ | i think it is more than just livecd.ubuntu-core ... moght be a full path | 20:17 |
| ogra_ | *might | 20:17 |
| jdstrand | kgunn_: yes please. we want to get rid of any ux's | 20:18 |
| jdstrand | kgunn_: is this something I could run in a vm? | 20:18 |
| sergiusens_ | ogra_: I grabbed those names from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image/+build/29997 | 20:18 |
| ogra_ | well, if you look at http://paste.ubuntu.com/11732394/ ... source_prefix might have a stamp and all | 20:19 |
| kgunn_ | jdstrand: yeah it is | 20:19 |
| ogra_ | https://launchpadlibrarian.net/209363495/livecd.ubuntu-core.rootfs.tar.gz ... | 20:19 |
| sergiusens_ | ogra_: oh, I found an issue in my diff | 20:21 |
| jdstrand | kgunn_: if you give me instructions, then I can maybe expedite this | 20:21 |
| kgunn_ | jdstrand: sure....let me clean up and push and i'll share | 20:21 |
| jdstrand | that said, I do have something I'm working on atm and won't be able to get to it for a little while | 20:22 |
| jdstrand | but certainly full-force in the morning if not later today | 20:22 |
| kgunn_ | jdstrand: i'm making some headway now...but i'll share later | 20:22 |
| jdstrand | kgunn_: ok, however you want to do it | 20:23 |
| kgunn_ | i think the tricky bit was not realizing that @unrestricted would lead to more aa denials to add | 20:23 |
| sergiusens_ | ogra_: http://paste.ubuntu.com/11732451/ | 20:24 |
| ogra_ | sergiusens_, uuuh | 20:24 |
| ogra_ | yeah :) | 20:24 |
| sergiusens_ | ogra_: I could just make that amd64 as well :-P | 20:24 |
| ogra_ | haha | 20:25 |
| ogra_ | yeah | 20:25 |
| sergiusens_ | ogra_: is that an ack? | 20:25 |
| ogra_ | well it is only temporary anyway | 20:25 |
| ogra_ | sure, do it | 20:25 |
| sergiusens_ | ogra_: so just like http://paste.ubuntu.com/11732463/ | 20:26 |
| sergiusens_ | ? | 20:26 |
| ogra_ | yup, looks fine | 20:26 |
| sergiusens_ | ogra_: rsalveti ok, new build triggered | 20:27 |
| * ogra_ crosses fingers | 20:28 | |
| * sergiusens_ takes a break to walk the dogs | 20:28 | |
| rsalveti | sergiusens_: awesome | 20:33 |
| rsalveti | importer still not finished | 20:34 |
| rsalveti | wtf | 20:34 |
| mvo_ | sergiusens_: good luck, I need to go to bed, if it still not workss, please let me know by mail and I continue in the morning | 20:35 |
| sergiusens_ | rsalveti: build not done yet (I think all builds need to finish) | 20:47 |
| rsalveti | no, this was one importer from more than one hour ago | 20:47 |
| rsalveti | that was still running | 20:47 |
| rsalveti | sergiusens_: importer is another cronjob | 20:48 |
| rsalveti | everything is pull based | 20:48 |
| rsalveti | :-) | 20:48 |
| kgunn_ | Jun 17 20:33:59 localhost kernel: [ 1905.624951] audit: type=1400 audit(1434573238.995:14269): apparmor="DENIED" operation="ptrace" profile="mir_system-compositor_snap1" pid=4484 comm="pidof" requested_mask="trace" denied_mask="trace" peer="unconfined" | 20:51 |
| kgunn_ | jdstrand: so this is one i'm confuddled about ^ | 20:51 |
| kgunn_ | denied mask "trace" ? | 20:52 |
| ogra_ | sergiusens_, rsalveti still 11th | 20:53 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/20150617.4/ | 20:53 |
| Laney | ogra_: what I do? :) | 20:54 |
| ogra_ | Laney, how did you make your changes to cdimage ? | 20:55 |
| ogra_ | did you follow https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup ? | 20:55 |
| Laney | more or less | 20:55 |
| ogra_ | seems there was some cowboyed code in there and it was overwritten | 20:55 |
| ogra_ | and usually cdimage screams loudly if thats the case to prevent you from merging | 20:56 |
| Laney | well maybe someone ran bzr revert or whatever | 20:56 |
| Laney | it'll only complain if there are conflicts, not sure I touched the same areas | 20:56 |
| ogra_ | yeah | 20:57 |
| kgunn_ | reading, this looks related... | 20:57 |
| kgunn_ | https://github.com/docker/docker/issues/7276 | 20:57 |
| ogra_ | Laney, thanks ... | 20:57 |
| Laney | sorry if it was me, didn't do it on purpose | 20:57 |
| Laney | is the code still alive? | 20:58 |
| ogra_ | no, seemingly not ... well, not the code we need | 20:58 |
| ogra_ | and nobody seems to have a backup | 20:58 |
| ogra_ | sergio is just trying his best and i dont feel awake enough to hack into it right now (i'll do it in my morning if there is no solution over night though) | 20:58 |
| jjohansen | kgunn_: what confuses you about it? mir_system-compositor_snap1 is trying to trace an unconfined peer process | 21:02 |
| kgunn_ | jjohansen: i'm quite new to these concepts, and i'm going through the process of getting the security profile correct for | 21:03 |
| kgunn_ | mir in order to be able to upload it to the store, so in my caveman brain i think "how can i make this go away" | 21:04 |
| jjohansen | kgunn_: well, generally speaking we don't allow a confined process to trace unconfined | 21:05 |
| jjohansen | kgunn_: do you know what it is trying to trace? | 21:05 |
| kgunn_ | jjohansen: yeah, so this stems from some mir weirdness where there's a race between it and agetty, so there's a script that handles the race... | 21:06 |
| kgunn_ | it's using pidof | 21:06 |
| kgunn_ | that's where this is coming from | 21:06 |
| jjohansen | kgunn_: hrmm, so my initial reaction is don't do that :) | 21:08 |
| jjohansen | kgunn_: it can be worked around by giving the ptrace peer=(label=unconfined), rule to the profile but I'm not sure what is required to get that kind of rule into the store | 21:09 |
| kgunn_ | jjohansen: :) i just found the line in docker | 21:09 |
| jjohansen | jdstrand: ^ any suggestions | 21:09 |
| sergiusens_ | rsalveti: yeah :/ | 21:09 |
| sergiusens_ | oops, ogra_ :-P | 21:09 |
| kgunn_ | jjohansen: i'm sure jamie will spank me :) | 21:09 |
| ogra_ | sergiusens_, rsalveti ... erm ... | 21:10 |
| jjohansen | :) | 21:10 |
| ogra_ | sergiusens_, so your cdimage code is fine, it actually copied it over ... but i suspect livecd-rootfs isnt rebuilding it actually | 21:10 |
| sergiusens_ | ogra_: progress http://paste.ubuntu.com/11732678/ | 21:10 |
| ogra_ | 2015-06-17 20:50:58 URL:https://launchpadlibrarian.net/209366564/livecd.ubuntu-core.azure.device.tar.gz [147294112/147294112] -> "/srv/cdimage.ubuntu.com/scratch/ubuntu-core/wily/daily-preinstalled/live/amd64.azure.device.tar.gz" [1] | 21:10 |
| sergiusens_ | ogra_: heh, shared the same :-P | 21:11 |
| ogra_ | yeah :) | 21:11 |
| ogra_ | great minds and all that ;) | 21:11 |
| ogra_ | i see "+ tar -c -z -f /build/device-azure.tar.gz system assets hardware.yaml" in the build log | 21:12 |
| ogra_ | and no error | 21:12 |
| sergiusens_ | ogra_: well, it's getting the wrong link from librarian | 21:13 |
| ogra_ | hmm | 21:13 |
| sergiusens_ | ogra_: latest build is https://launchpadlibrarian.net/209363535/livecd.ubuntu-core.azure.device.tar.gz | 21:13 |
| ogra_ | ah, ok | 21:13 |
| sergiusens_ | slangasek: do you know why that can be? ^ | 21:14 |
| * ogra_ wishes back the days where cdimage was shell :/ | 21:14 | |
| ogra_ | find_live_filesystem() was so much easier | 21:14 |
| sergiusens_ | ogra_: heh | 21:15 |
| ogra_ | it is all cody-summervilles fault ! | 21:15 |
| jdstrand | jjohansen, kgunn_: sorry, reading backscroll | 21:16 |
| rsalveti | just check the lp job, it should tell if the azure tarball is in there | 21:16 |
| ogra_ | rsalveti, yeah, that bit is fine | 21:17 |
| sergiusens_ | rsalveti: it's there, the librarian link is wrong | 21:17 |
| ogra_ | but we're not finding the right url | 21:17 |
| rsalveti | how that | 21:17 |
| sergiusens_ | rsalveti: well it's logged now ;-) | 21:17 |
| sergiusens_ | rsalveti: http://paste.ubuntu.com/11732678/ but the latest build's link is https://launchpadlibrarian.net/209363535/livecd.ubuntu-core.azure.device.tar.gz | 21:18 |
| rsalveti | but https://launchpadlibrarian.net/209366564/livecd.ubuntu-core.azure.device.tar.gz is also valid (just not the one you're looking for) | 21:18 |
| ogra_ | it is not publishing it though | 21:19 |
| ogra_ | according to the log | 21:19 |
| kgunn_ | hmmm, but now i hit trace denied for all sorts of bespoke peers (webdm, docker, mir itself) | 21:20 |
| rsalveti | ogra_: sergiusens_: /srv/cdimage.ubuntu.com/scratch/ubuntu-core/wily/daily-preinstalled/live | 21:20 |
| sergiusens_ | ogra_: rsalveti I think I found one more location | 21:20 |
| rsalveti | it's there | 21:20 |
| ogra_ | yes, it is not publishing it | 21:20 |
| rsalveti | -rw-r--r-- 1 cdimage cdimage 147294112 Jun 17 20:34 amd64.azure.device.tar.gz | 21:20 |
| ogra_ | right | 21:20 |
| rsalveti | well, takes a while for it to be public | 21:20 |
| * ogra_ was just looking at the same file :) | 21:20 | |
| ogra_ | rsalveti, cdimage logs when it publishes it | 21:21 |
| ogra_ | there is no azure in the log | 21:21 |
| ogra_ | /srv/cdimage.ubuntu.com/log/ubuntu-core/wily/daily-preinstalled-20150617.4.log | 21:21 |
| rsalveti | yeah | 21:21 |
| rsalveti | not at /srv/cdimage.ubuntu.com/www/full/ubuntu-core/daily-preinstalled/pending | 21:21 |
| rsalveti | man, this is so much more complicated than it should be | 21:22 |
| ogra_ | yep | 21:22 |
| ogra_ | i want shell back ! | 21:22 |
| rsalveti | involves 3, 4 different servers | 21:22 |
| ogra_ | would have taken me minutes | 21:22 |
| jjohansen | kgunn_: sure, ptrace is dangerous. you will need specify each of them | 21:23 |
| jjohansen | kgunn_: and the reverse relation as well, that is those apps have to declare the relationship as well | 21:23 |
| jdstrand | kgunn_: so, yes, use the rule jjohansen mentioned for now, but I'm pretty uncomfortable with the technique and the rule. I think we should figure out something better. the docker policy is not something to model your policy after, btw :) | 21:23 |
| sergiusens_ | ogra_: rsalveti http://paste.ubuntu.com/11732716/ | 21:24 |
| jjohansen | this prevents an attacker app being able to declare its allowed to ptrace without the peers saying yeah we know and trust him | 21:24 |
| jdstrand | kgunn_: the problem is that if you you are allowed to trace unconfined, unconfined allows anything to trace it | 21:24 |
| rsalveti | sergiusens_: looks ok | 21:24 |
| jjohansen | jdstrand: right, so no better suggestion for now | 21:24 |
| ogra_ | sergiusens_, yeah | 21:25 |
| jjohansen | jdstrand: really we need to fix that | 21:25 |
| jdstrand | jjohansen: fix the mir policy or that unconfined allows tracedby? | 21:25 |
| jdstrand | or both :) | 21:25 |
| jjohansen | both :) | 21:26 |
| jdstrand | so, I will probably make this a little better with a child profile for pidof | 21:26 |
| jdstrand | that way even if mir has an issue, it would need pidof to allow something unexpected | 21:27 |
| jdstrand | once kgunn_ gets through the initial policy, he'll give it to me to review and I can play with it | 21:28 |
| sergiusens_ | ogra_: rsalveti ok, this one is the one | 21:28 |
| stgraber | jdstrand: hey, so what do I need to do for a snappy binary to be able to write to its user data dir (HOME)? | 21:28 |
| ogra_ | building ? | 21:28 |
| sergiusens_ | ogra_: yes | 21:29 |
| ogra_ | yay | 21:29 |
| * sergiusens_ starts to use http://whatthecommit.com/ again | 21:29 | |
| rsalveti | lol | 21:29 |
| === sergiusens_ is now known as sergiusens | ||
| stgraber | jdstrand: I was hoping I wouldn't have to also make our client tool unconfined :) | 21:29 |
| jdstrand | stgraber: it should be allowed by the policy. You need to look in SNAP_APP_USER_DATA_PATH | 21:29 |
| ogra_ | stgraber, snappy binaries can not write to $HOME ... | 21:29 |
| ogra_ | right | 21:29 |
| stgraber | error: mkdir /root/apps/lxd/0.11-0/.config: permission denied | 21:29 |
| ogra_ | SNAP_APP_USER_DATA_PATH is a subdir for the app in $HOME | 21:30 |
| jdstrand | yes | 21:30 |
| rsalveti | sergiusens: seems we're good regarding the --install=docker issue: https://bugs.launchpad.net/snappy/+bug/1465879/comments/5 | 21:30 |
| ubottu | Ubuntu bug 1465879 in Snappy "docker framework does not install via ubuntu-device-flash" [High,Confirmed] | 21:30 |
| jdstrand | you don't get all of home, you get SNAP_APP_USER_DATA_PATH | 21:30 |
| sergiusens | Chipaca: http://whatthecommit.com/bf057fb0e2e7a4450250ebf7d6e1d084 :-P | 21:30 |
| stgraber | sure sure, but clearly I don't even get write access to SNAP_APP_USER_DATA_PATH | 21:30 |
| rsalveti | lol | 21:30 |
| jdstrand | stgraber: is that an apparmor denial? | 21:30 |
| ogra_ | stgraber, because /root is readonly perhaps ? ;) | 21:30 |
| stgraber | ogra_: isn't | 21:31 |
| jdstrand | and then there is that :) | 21:31 |
| stgraber | [94170.804198] audit: type=1400 audit(1434576560.135:55): apparmor="DENIED" operation="mkdir" profile="lxd_lxc_0.11-0" name="/root/apps/lxd/0.11-0/.config/" pid=6085 comm="lxc" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 | 21:31 |
| Chipaca | sergiusens: ? | 21:31 |
| sergiusens | Chipaca: I am just fooling around :-) | 21:31 |
| Chipaca | sergiusens: http://whatthecommit.com/0041a2c1bcc6d21895a46d0b92f64a88 then :) | 21:31 |
| sergiusens | \o/ | 21:32 |
| ogra_ | heh | 21:32 |
| jdstrand | stgraber: oh, that is because we are using @{HOMEDIRS}/*/ instead of @{HOME}. @{HOMEDIRS}/*/ does not include /root. | 21:32 |
| jdstrand | stgraber: I remember I asked other snappy devs about this | 21:32 |
| stgraber | that probably ought to be fixed :) | 21:32 |
| jdstrand | and it was decided that /root/ was not needed. apparently that needs to be revisited | 21:32 |
| jdstrand | stgraber: before I fix it, I think there might need to be a discussion. can you file a bug agount snappy, the project? | 21:34 |
| jdstrand | stgraber: you can add an ubuntu-core-security task | 21:34 |
| jdstrand | stgraber: I have questions around /root, the FHS, rollbacks, etc | 21:34 |
| stgraber | jdstrand: says that ubuntu-core-security doesn't use LP for bugs so can't add a task | 21:36 |
| stgraber | jdstrand: anyway, bug 1466234 | 21:36 |
| ubottu | bug 1466234 in Snappy "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Undecided,New] https://launchpad.net/bugs/1466234 | 21:36 |
| jdstrand | stgraber: sorry, snappy the project and ubuntu-core-security under Ubuntu | 21:36 |
| jdstrand | I can add it | 21:37 |
| stgraber | ah, done | 21:37 |
| jdstrand | stgraber: ok, I asked my questions. if the snappy devs are comfortable with it and respond in the bug, I'll adjust the policy | 21:40 |
| stgraber | jdstrand: next question for you :) | 21:43 |
| stgraber | (amd64)root@localhost:~# /usr/bin/ubuntu-core-launcher lxd lxd__0.11-0 /apps/lxd/0.11-0/bin/lxd.start | 21:43 |
| stgraber | aa_change_onexec failed with -1 | 21:43 |
| stgraber | . errmsg: No such file or directory | 21:43 |
| stgraber | what does that mean? ^ | 21:43 |
| jdstrand | stgraber: it couldn't find the profile 'lxd__0.11-0' | 21:43 |
| jdstrand | 'lxd__0.11-0' is not formatted well btw' | 21:43 |
| jdstrand | so either the yaml has an issue or the launcher isn't calculating the appname part correctly | 21:44 |
| jdstrand | there should be something between the '__' | 21:44 |
| jdstrand | it should be the name of the service (from services) or the binary (from binaries) | 21:45 |
| stgraber | oh, also, that thing is a framework, not sure if that's relevant | 21:45 |
| jdstrand | it isn't relevant to what should be happening. it might be a contributing factor to a bug | 21:45 |
| jdstrand | stgraber: can you paste /apps/lxd/current/meta/package.yaml? | 21:46 |
| stgraber | oh, I think I know what's wrong in the yaml, testing | 21:46 |
| stgraber | jdstrand: so a missing name attribute on the service was the source of the problem. Kinda surprised the tool isn't validating this though. | 21:48 |
| stgraber | now to figure out the next problem | 21:49 |
| Chipaca | tedg: your opinion wrt SNAP_APP_USER_DATA_PATH might be relevant to #1466234 | 21:49 |
| Chipaca | bug #1466234 that is | 21:49 |
| nothal | Bug #1466234: Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root <Snappy:New> <ubuntu-core-security (Ubuntu):Incomplete> <http://launchpad.net/bugs/1466234> | 21:49 |
| ubottu | bug 1466234 in ubuntu-core-security (Ubuntu) "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Undecided,Incomplete] https://launchpad.net/bugs/1466234 | 21:49 |
| jdstrand | stgraber: yes, the review tools are currently disabled (they would have caught) | 21:51 |
| stgraber | jdstrand: so, http://paste.ubuntu.com/11732810/, any idea why I'm getting apparmor denials with that for the service? | 21:51 |
| stgraber | Jun 17 21:50:22 localhost.localdomain audit[787]: <audit-1400> apparmor="DENIED" operation="pivotroot" profile="lxd_lxd_0.11-0" name="/run/cgmanager/root/" pid=787 comm="cgmanager" srcname="/run/cgmanager/root/" | 21:52 |
| stgraber | doesn't look unconfined to me :) | 21:52 |
| jdstrand | Chipaca: is there a bug to re-enable the review tools? | 21:52 |
| ogra_ | Wed Jun 17 21:53:12 UTC 2015 | 21:53 |
| ogra_ | Publishing amd64 ... | 21:53 |
| ogra_ | Publishing amd64 live manifest ... | 21:53 |
| ogra_ | Publishing amd64 device tarball ... | 21:53 |
| ogra_ | Publishing amd64 azure device tarball ... | 21:53 |
| ogra_ | \o/ | 21:53 |
| ogra_ | sergiusens, rsalveti ^^^ | 21:53 |
| sergiusens | \o/ | 21:53 |
| sergiusens | ogra_: it just just just finished :-P | 21:53 |
| ogra_ | i was tailing the log :=) | 21:53 |
| sergiusens | ogra_: http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/20150617.5/ is up to date as well | 21:54 |
| jdstrand | stgraber: the unconfined template isn't trruly unconfined. http://bazaar.launchpad.net/~ubuntu-security/ubuntu-core-security/trunk/view/head:/data/apparmor/templates/ubuntu-core/15.04/unconfined | 21:54 |
| ogra_ | yippiie | 21:54 |
| jdstrand | stgraber: it is missing a 'pivot_root,' rule | 21:54 |
| stgraber | jdstrand: ah, what do I do to get something that's completely unconfined? | 21:54 |
| * kgunn realizes no one likes being confined | 21:55 | |
| stgraber | because no pivot_root is going to be a bit of a problem for us :) | 21:55 |
| jdstrand | stgraber: I can add that | 21:55 |
| stgraber | jdstrand: anyway I can easily do that locally so I can see what fails next? | 21:56 |
| Chipaca | jdstrand: nope | 21:56 |
| jdstrand | stgraber: in the mean time you can either just add the rule to /var/lib/apparmor/profiles/... or you can use 'security-policy' (https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/DevelopingFrameworkPolicy) and use the unconfined template with pivot_root added | 21:56 |
| stgraber | jdstrand: ok, I'll add the rule locally for now | 21:57 |
| jdstrand | kgunn: well, yes, but lxd is quite a different beast :) | 21:57 |
| kgunn | :) | 21:57 |
| stgraber | jdstrand: will that profile with this addition let me switch profile, specifically to real unconfined? | 21:57 |
| kgunn | jdstrand: quick one i hope, so i worked through to the point now where i need to add "binaries" to my yaml for the actual mir-demo-server | 21:58 |
| kgunn | and the question is about paths... | 21:58 |
| ogra_ | E=mc² | 21:58 |
| ogra_ | ;) | 21:58 |
| kgunn | since mir-demo-server is actually in debs/usr/bin | 21:58 |
| ogra_ | (all relative to your SNAP_APP_PATH) | 21:59 |
| kgunn | ogra_: ta | 21:59 |
| kgunn | see i knew it was easy | 21:59 |
| kgunn | jdstrand: ok, and with aa profile on this binary...since it's part of the framework, do i also need to do a seperate security pollicy on it ? | 22:01 |
| elopio | I need some go help in here. When I run go test ./... I get cmd/snappy/common.go:28: undefined: priv.WithMutex | 22:01 |
| elopio | but it is defined, and I don't get that error from my desktop. | 22:01 |
| kgunn | since it needs some paths not needed by the main service | 22:02 |
| elopio | go is drunk. | 22:02 |
| Chipaca | elopio: tell me more | 22:07 |
| Chipaca | elopio: i have a good guess as to what's happening | 22:07 |
| Chipaca | elopio: in whatever you're running this, this not-your-desktop environ, has the GOPATH pointing at a snappy different from the one you're running the tests on | 22:08 |
| elopio | Chipaca: I don't know what else to tell you. I've pulled trunk and ran the tests. | 22:08 |
| Chipaca | elopio: because you're running the tests with ./... you're not picking up that snappy for the test runner | 22:08 |
| rsalveti | ogra_: sergiusens: lovely | 22:08 |
| Chipaca | elopio: but the imports in files under test use absolute paths | 22:08 |
| Chipaca | elopio: e.g. launchpad.net/snappy/potato | 22:08 |
| Chipaca | elopio: so those are coming from your GOPATH | 22:08 |
| jdstrand | kgunn: this is where framework-policy comes into play I think, or maybe not | 22:10 |
| kgunn | well, i see i can add the client policies that the framework publishes | 22:11 |
| kgunn | for use as a cap by the binaries | 22:11 |
| kgunn | but, don't want to expose more through that than is needed.... | 22:11 |
| elopio | Chipaca: it works now ¬¬ | 22:12 |
| Chipaca | elopio: 🙌 | 22:13 |
| jdstrand | kgunn: right. so we want to expose the minimum in the framework-policy. are you saying that the mir-demo-client binary needs more than the minimum? | 22:13 |
| elopio | I removed my link from the GOPATH to my workspace. Then made it again... | 22:13 |
| elopio | Chipaca: how do you handle different branches in src/launchpad.net/snappy ? Do you use ln ? | 22:13 |
| Chipaca | elopio: you use a pipeline? | 22:14 |
| kgunn | jdstrand: nope, sorry... so there's a binary mir-demo-server which is launched by (the service) mir-compositor | 22:14 |
| Chipaca | elopio: bzr gets confused by symlinks | 22:14 |
| jdstrand | kgunn: if it can use the minimum with the default template, then you can refer to your framework-policy | 22:14 |
| kgunn | this is before clients actually show up... | 22:14 |
| jdstrand | kgunn: ok, in that case, you need to write "security-policy" for your binary | 22:14 |
| elopio | Chipaca: no, I have a workspace with all the branches as dirs. I put a link in src/launchpad.net to the one I want to test. | 22:14 |
| kgunn | jdstrand: ok, so follow the same construct/form... | 22:15 |
| kgunn | ta | 22:15 |
| jdstrand | kgunn: yes | 22:15 |
| Chipaca | elopio: ok | 22:15 |
| kgunn | jdstrand: frighteningly i may understand this before i'm all done :) | 22:15 |
| Chipaca | elopio: that'll confuse either go or bzr, depending how you're doing it | 22:15 |
| Chipaca | elopio: you can make it work if you're careful | 22:16 |
| jdstrand | kgunn: I'll also (hopefully) helpfully remind you that https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/DevelopingFrameworkPolicy has boilerplate | 22:16 |
| Chipaca | elopio: me, i gave up using symlinks and just move stuff around | 22:16 |
| Chipaca | elopio: when i'm not using pipelines that is | 22:16 |
| elopio | this is the first time it failed, so I guess I wasn't careful. | 22:16 |
| elopio | Chipaca: do you mean http://wiki.bazaar.canonical.com/BzrPipeline ? | 22:16 |
| Chipaca | elopio: yes | 22:16 |
| kgunn | yessir | 22:16 |
| elopio | ok, I'll try that. | 22:16 |
| kgunn | ok...nuff for now, maybe more later | 22:17 |
| Chipaca | elopio: and in bazar.conf, | 22:17 |
| Chipaca | n = swp :next | 22:17 |
| Chipaca | p = swp :prev | 22:17 |
| Chipaca | ps = pipes | 22:17 |
| elopio | Chipaca: those are alias, right? | 22:18 |
| Chipaca | elopio: in [aliases] i mean | 22:18 |
| Chipaca | yes | 22:18 |
| elopio | cool. Sounds less insane than links. | 22:18 |
| Chipaca | elopio: until it throws a stacktrace at you, sure :) | 22:19 |
| sergiusens | heh | 22:20 |
| sergiusens | I recall those | 22:20 |
| sergiusens | del-pipe has some issues | 22:20 |
| Chipaca | sergiusens: just switching with new files added but not committed seems to tickle it | 22:21 |
| Chipaca | anyway | 22:21 |
| sergiusens | Chipaca: oh, that works fine for me | 22:21 |
| Chipaca | elopio: everything is terrible. | 22:21 |
| Chipaca | elopio: we're moving back to C, and CVS | 22:22 |
| slangasek | sergiusens: sorry, I have no brain state relevant to the azure files/builds/downloads. If you're stuck I'd suggest tagging the launchpad team | 22:29 |
| elopio | :) let me first hate pipeline before making the move. | 22:29 |
| sergiusens | slangasek: fixed 30' ago, but thanks :-) | 22:31 |
| slangasek | sergiusens: hah, ok | 22:31 |
| sergiusens | rsalveti: do you plan to copy https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.24-0ubuntu2 to tools-proposed? | 23:05 |
| rsalveti | sergiusens: already there | 23:06 |
| rsalveti | sergiusens: and utlemming just confirmed that it worked for him | 23:06 |
| rsalveti | so all good | 23:06 |
| sergiusens | rsalveti: oh neat :-) | 23:06 |
| sergiusens | one more thing to cross off the list :-) | 23:06 |
| sergiusens | rsalveti: are you moving it to tools per se? | 23:06 |
| sergiusens | or waiting on that one? | 23:06 |
| rsalveti | sergiusens: not now, want to migrate things at the same time we get to test our next stable image | 23:07 |
| rsalveti | so we can all be testing the same thing all together | 23:07 |
| sergiusens | rsalveti: sounds good | 23:08 |
| sergiusens | elopio: btw, the bzr bd command there doesn't play nice with my --builder option in bazaar.conf | 23:08 |
| elopio | sergiusens: we initially copied bzr-buildpackage from the original script, but it didn't work for me. | 23:09 |
| elopio | sergiusens: can you try that? | 23:09 |
| sergiusens | Building the package in /home/sergiusens/go/src/launchpad.net/build-area/ubuntu-snappy-1.1.2, using sbuild -d wily --arch=amd64 -c wily-amd64 -j9 -uc -us | 23:09 |
| sergiusens | Unknown option: u | 23:09 |
| sergiusens | I'm on trusty | 23:10 |
| sergiusens | oh, being called for dinner | 23:10 |
| * elopio goes to watch the game. | 23:19 | |
| stgraber | [ 5298.277754] audit: type=1400 audit(1434583615.201:38): apparmor="DENIED" operation="change_profile" profile="lxd_lxd_0.11-0" pid=4690 comm="lxd" target="lxc-container-default" | 23:27 |
| stgraber | jdstrand: should be added to the unconfined profile too ^ | 23:27 |
| jdstrand | hmm | 23:27 |
| jdstrand | I'll add it to the list | 23:28 |
| * jdstrand heads out | 23:28 | |
| * rsalveti also heads out, dinner and football | 23:29 | |
| === ManikTaneja is now known as manik_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
