rsalvetisergiusens: sorry I forgot to put my test results at https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/beBetter/+merge/26180400:24
rsalvetisergiusens: but yeah, it's a +1 for me as well00:24
rsalvetiChipaca is a review machine00:25
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
fgimenezgood morning07:00
dholbachgood morning07:11
mvoChipaca: 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
longsleepsergiusens: 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
JamesTaitGood morning all; happy Eat Your Vegetables Day!08:59
Chipacamvo: hey09:05
Chipacamvo: yes09:05
Chipacamvo: 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
mvoChipaca: we need two :) G() (or L() i don't care) and NG() (ngettext)09:06
Chipacamvo: fair enough09:07
Chipacai guess G and LG don't clash with anything right now09:07
Chipacamvo: very easy to do, tbh; just import it with a . as we do with gocheck in the tests09:07
mvoChipaca: heh, sure! great suggestion, thanks!09:09
mvoChipaca: its one of these ideas thats obvious *once* you had it09:09
Chipacatyhicks: love your work on the CAP_NET_ADMIN thing, thank you!09:36
rsalvetilongsleep: dholbach might be able to help you with the review related questions09:49
dholbachrsalveti, 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
rsalvetidholbach: store related review questions, thought you had review permission as well09:51
dholbachrsalveti, yes, I do - I just wasn't sure if we had a process figured out for reviewing OEM snaps already09:52
rsalvetihm, right, that I don't know09:52
longsleepdholbach: well i received some comments, but now the process seems to be stuck as nobody did answer lately :)09:52
rsalvetiogra_: I fail to related developing system components and dpkg here09:53
dholbach"Supported architectures:Architecture independent" is likely wrong09:53
ogra_rsalveti, today you build your stuff in a silo and then install the debs09:53
dholbachlet me take another look at the comments09:53
longsleepdholbach: 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 action09:53
ogra_or re-build the packages locally09:53
rsalvetiogra_: 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 framework09: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
mzanettirsalveti, so if I want to test a small patch on unity I need to rebuild the framework?09:55
mzanettiok, the severity of that really depends on what the framework is :D09:55
ogra_i dont think it will be a framework ... unless rsalveti knows something new ...09:55
rsalvetifor personal you would indeed just follow the current dev steps you do for phone09:55
rsalvetidpkg will be available09:55
dholbachah, "Architecture independent" might actually be right09:55
ogra_rsalveti, so we will have special developer images that ship dpkg ?09:56
rsalvetionce we move away from personal and get just core + snaps, then we'd need to find the right spot for your piece09:56
ogra_i thought the masterplan was to completely get rid of it09:56
mzanettican 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 time09:56
rsalvetiogra_: that is the masterplan, but I don't think that will be removed from personal09:57
ogra_as i understood some desktop discussions the plan was to only have dpkg fenced inside an lxc container we ship by default09:57
rsalvetimzanetti: so personal is a shortcut atm, since transforming everything into a snap (framework and apps), is a lot of work09:57
dholbachjdstrand, 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
rsalvetiso instead of doing that now, we created another base image that includes everything09: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 then09:58
dholbachlongsleep, ^ I just went ahead and pinged some other folks who should know more09:58
rsalvetimoving away from personal would mean start using the core + snaps (framework and apps)09:58
dholbachlongsleep, sorry for not being of more help here09:58
mzanettirsalveti, you mean converting unity into a snap itself?09:58
rsalvetimzanetti: yup09:58
longsleepdholbach: 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
rsalvetimzanetti: how that will be done is not clear yet09:59
mzanettirsalveti, ok. thanks for clarifying.09:59
seb128rsalveti, but personnal is still a snappy image and ro, so you can't dpkg things there10:03
rsalvetiseb128: right, but that restriction already exists on phone images10:07
rsalvetithe use case is for people already remounting things with rw10:07
seb128rsalveti, you can turn the phone rw by touching a file and rebooting, is that going to work on snappy?10:07
rsalvetiseb128: that is still an open question (if we're going to offer something similar), but I'd imagine we don't want to do that10:08
rsalvetithe logic is currently inside the initrd10:08
rsalvetinot sure if for personal this is something you might want to offer10:08
seb128rsalveti, but you can mount -o remount rw?10:09
rsalvetiseb128: if you have sudo access, sure10:09
ogra_seb128, sure, why not10: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 such10:10
seb128oh ok10:10
Chipacamvo_: when tarmac complains about "there are additional revisions yadda yadda", it's the timestamp of the top-approval it's complaining about10:10
seb128well the snappy image is still built from debs10:10
seb128so no reason dpkg is gone10:10
ogra_but since we will keep it for now even though the masterplan is to have it not in the images, we are fine10:10
seb128do 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 snaps10:11
rsalvetinot necessarily, but there is no need for dpkg to be installed10:11
ogra_but we will likely remove dpkg at the end of the build10:11
rsalvetiif we're not using it10: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 done10:12
ogra_if not even less10:12
rsalvetithere is a card to investigate that10:12
seb128rsalveti, right, it's just difficult to convince a deb system to remove dpkg :p10:12
ogra_rm :)10:12
seb128well then no need to debs anymore10:12
seb128you can also cp10:13
ogra_perhaps we'll do that one day10:13
ogra_but our infra is still built around packages today10:13
ogra_so why not use them10:13
ogra_on an embedded system where you are only interested in getting enough OS to boot, you dont really want the bloat10:14
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
Chipacabeuno: you around?10:15
rsalvetiChipaca: 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/146587910:17
ubottuUbuntu bug 1465879 in Snappy "docker framework does not install via ubuntu-device-flash" [High,Confirmed]10:17
Chipacarsalveti: check snappy-devel10:18
Chipacarsalveti: or, https://bugs.launchpad.net/snappy/+bug/146448610:18
ubottuUbuntu bug 1464486 in goget-ubuntu-touch (Ubuntu) "frameworks that install policies cannot be preinstalled" [Undecided,New]10:18
Chipacarsalveti: we should confirm whether it happens with trunk snappy, as it's merged there10:19
Chipacaah! maybe it's still needing u-d-f work10:20
* rsalveti checks10:23
mvo_rsalveti, Chipaca: it may just need a rebuild of u-d-f against current snappy (shared libs ftw :/)10:24
rsalvetiguess also backporting https://code.launchpad.net/~sergiusens/snappy/policyRoot/+merge/261802 ?10:25
rsalvetior just udf would be enough? (the rebuild)10:25
gatispHello, 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
gatispit says: "system: directory shipping kernel modules that are only needed after the rootfs has been mounted;"10:33
ogra_that is correct10:33
ogra_what would you expect it to be ?10:34
gatispshouldn't it say modules that are needed before mounting rootfs?10:34
ogra_no, these have to go into the initrd10:34
gatispah, right10: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 installed10: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
sergiusensrsalveti: it should work with the latest build already10:45
sergiusensrsalveti: or a rebuild of u-d-f I mean10:46
rsalvetisergiusens: morning :-)10:46
sergiusenswe can check with Built-Using tags10:46
sergiusensgood morning :-)10:46
rsalvetisergiusens: cool, guess we just need to upload a new udf and copy it over to our ppas10:46
rsalvetiogra_: hm, that version is in our ppa10:47
rsalvetisergiusens: 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 fine10:48
rsalvetitarmac is currently complaining about it10:48
ogra_probably a timing error where the arch all side had not migtared10:48
rsalvetiogra_: yeah10:48
ogra_i guess someone should just trigger a new build10:48
sergiusensrsalveti: yeah, gofmt, no sure how it happened, but it happened10:48
sergiusensrsalveti: 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
rsalvetihm, but amd64 is failing quite frequently10:49
rsalvetiFAIL: touch_test.go:30: HTestSuite.TestUpdateTimestamp10:49
rsalvetimvo_: seems those unstable tests showing up again10:49
rsalvetithis time for amd6410:50
sergiusensrsalveti: heh, time based test failures ftw10:50
* ogra_ triggers a new image10:50
rsalvetiogra_: amd64 is still ftbfs10:50
ogra_sure, but that shouldnt make armhf and i386 fail10:50
rsalvetiwe we only care about armhf and amd64 atm10:50
ogra_that package comes from the PPA ...10:50
ogra_no proposed-migration there10:51
rsalvetiso one of the main archs will fail10:51
ogra_(or do we have it)10:51
ogra_damn !10:52
* ogra_ read arm64 10:52
rsalvetithere is another build in progress10:52
rsalvetisomeone triggered it10:52
ogra_silly silly silly naming !!!!!10:52
rsalvetihaha, /me does that all the time10:52
ogra_well, i triggered one ... might be me10:52
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_amd64 succeeded10:58
sergiusensfgimenez: 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
sergiusenscan 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
sergiusensogra_: in process of11:39
ogra_k, thanks11:40
sergiusensogra_: got stuck in the pipeline11:40
=== soee_ is now known as soee
fgimenezsergiusens, currently we are adding them in _integration_tests/tests, see https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/26174811:41
fgimenezsergiusens, i'll push changes shortly to allow adding more than one test file, all of them are now in snappy_test.go11:43
sergiusensfgimenez: this doesn't drive image creation though, right?11:45
fgimenezsergiusens, yes, calling it with "go run _integration_tests/main.go" should do it all, compile debs, create image and call adt-run on it11:47
sergiusensfgimenez: nice, I need to create the image in a different way though11:49
sergiusensfgimenez: hmm, maybe for E2E but I can tamper with the image to set what I need11:50
fgimenezsergiusens, yep, it's not very configurable atm :)11:50
sergiusensfgimenez: should I go with the half test?11:53
sergiusensI would like to have E2E eventually though11:53
fgimenezsergiusens, how could this be setup?11:56
beunoChipaca, hola11:57
Chipacabeuno: hola!11:58
Chipacabeuno: 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
beunoChipaca, yes.12:00
beunoChipaca, extracted from the package, can be edited in the form12:00
Chipacabeuno: i'm confused a little, then12:00
Chipacabeuno: where is it extracted from?12:01
Chipacabeuno: "snappy build" loads it with the description from the readme12:01
Chipacabeuno: that is, it sets the manifest's description entry to the readme12:02
Chipacato the second+ line of the readme12:02
beunoChipaca, it parses it from the json12:02
Chipacato all the non-blank lines after the first non-blank line in the readme12:02
Chipacabeuno: from the json manifest, yes?12:02
sergiusensbeuno: can we make it not editable?12:03
Chipacabeuno: same place you get all the other metadata from?12:03
sergiusensChipaca: for when time happens https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/personalCmd/+merge/26217412:03
Chipacabeuno: because i'm confused, therefore, by the results from the store which seem to prepend the title to the description in the description12:03
beunosergiusens, no, because then you need to re-upload a 800mb snap to fix a typo in the description12:04
beunoChipaca, same place, es12:04
beunoChipaca, I think it might merge 2 fields into the description12:05
beunojayteeuk knows the details12:05
Chipacabeuno: also the title is not the title, it's the name?12:05
Chipacaseriously confused :)12:05
JamesTaitIt wasn't me!12:05
sergiusensbeuno: right, but then the data is inconsistent as well12:05
ChipacaJamesTait: ehlo :)12:06
rsalvetisergiusens: holy, there are at least 5 branches waiting to be merged in goget12:06
Chipacaif you GET 'https://search.apps.ubuntu.com/api/v1/search?fields=title%2Cdescription&q=hello-world'12:06
sergiusensbeuno: or in other words, the local data is useless12:06
JamesTaitChipaca, 501 Syntax: EHLO hostname12:06
rsalvetisergiusens: can we have an upload after merging https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/installYaml/+merge/261865 ?12:06
ChipacaJamesTait: ehlo chipaca12:06
rsalvetito split the personal stuff in another upload12:06
sergiusensrsalveti: yeah, didn't I says yes already :-P ?12:07
rsalvetisergiusens: just wanted to double confirm :P12:07
ChipacaJamesTait: if you GET the above uri12:07
beunosergiusens, correct12:07
ChipacaJamesTait: and look at hello-world.canonical12:07
sergiusensrsalveti: split is new though... so one sec I'll set to needs review12:07
beunosergiusens, the idea always was to take whatever the store told you instead of what the package says12:07
ChipacaJamesTait: or any of the others really12:07
sergiusensbeuno: so why do all this packaging format if we don't need it?12:07
beunosergiusens, initial seeding of the information12:08
sergiusenslet's just remove icon. description, title, readme.md from the packaging12:08
ChipacaJamesTait: 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 tell12:08
sergiusensbeuno: we can seed with an external file12:08
sergiusensno need for it to be part of the packaging if it's going to be useless data12:08
sergiusensmvo_: ^12:08
JamesTaitChipaca, without having clicked on those links, let me first put pad.lv/1303354 out there.12:08
JamesTaitNow let me click on the links and see what else I can add.12:09
JamesTaitChipaca, so, "look at hello-world.canonical" where?12:10
ChipacaJamesTait: in particular, the title is ... dunno what; the description is the \n-glomming of title and description12:10
ChipacaJamesTait: http://pastebin.ubuntu.com/11730186/12:11
Chipacabeuno: sergiusens: easy way to fix that is to "fix" the package when edited12:12
JamesTaitChipaca, right, so the latter part of that is addressed by the bug I pasted above.12:12
JamesTaitChipaca, do you have a devportal link to that package?12:13
ChipacaJamesTait: i'll believe you, but i have no idea what the "app summary" or the "tagline" is, in this context12:13
beunoChipaca, ew ew ew12:14
ChipacaJamesTait: id 1999 <- is that good enough?12:14
beunono touching the binaries!12:14
Chipacabeuno: 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
JamesTaitChipaca, indeed it is. ☺12:15
beunoChipaca, or, you download the store's json when downloading the app and use that to display12:15
Chipacabeuno: you don't have to edit the binary, of course; you can also modify it on the fly when the user downloads it :-p12:15
* beuno dims his laptop's screen to the minimum12:16
JamesTaitThe "Sorry, can't hear you!" approach.12:16
Chipacabeuno: 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
sergiusensbeuno: the data needs to be consistent though12:18
sergiusensI think it's bad design12:18
Chipacabeuno: and moves work to the client, which is underpowered and numerous12:18
JamesTaitChipaca, 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
ChipacaJamesTait: http://www.brainlesstales.com/images/2013/Jul/bear-in-mind.jpg12:19
JamesTaitChipaca, in snap package terms, that maps to... hang on, checking. ☺12:19
Chipacadeb-control(5) does not call it a tagline nor an app summary, either12:21
beunoChipaca, so we make people upload 800mb to fix a typo or set a promo for their app?12:21
Chipacashort description and long description12:21
sergiusensbeuno: we can also split the packaging if it's useless data as you said12:21
sergiusensthe "metadata" doesn't need to be there12:22
Chipacasergiusens: how is that different from downloading the store json?12:22
sergiusensbeuno: but keep in mind the no caching rule, the store would be spammed by thousands of clients12:22
sergiusensChipaca: oh, I'm talking about "on upload"12:22
Chipacasergiusens: i'm talking about not understanding how that would be different for the client :)12:23
sergiusensChipaca: the initial seeding problem12:23
Chipacasergiusens: you mean the server would assemble the package from these bits?12:23
sergiusensChipaca: oh, if the store stays this way the client gets more logic, and the store gets more load12:23
Chipacaok, i'm going to move on for now, but this is a problem and needs addressing at some point12:24
sergiusensChipaca: 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 back12:24
Chipacasergiusens: k12:24
sergiusensChipaca: but let's break the lie about package.yaml and readme.md if it is just to "seed"12:25
Chipacasergiusens: i didn't quite follow you there12:29
=== chihchun is now known as chihchun_afk
Chipacabeuno: tbh i'm starting to wonder whether having the click and snappy stores conjoined is still a good idea12:29
Chipacawe seem to be making things harder for ourselves as we go12:29
beunoChipaca, I asked if I could double the team size and they counter-offered with taking away half12:30
Chipacabeuno: 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 places12:31
Chipacaas we should12:31
beunoChipaca, :)12:32
beunoChipaca, so what would you propose?12:32
beunosplitting away from parsing the json?12:32
Chipacabeuno: i'd propose coffee12:32
beunoChipaca, SOLD!12:32
JamesTaitI like proposals like that.12:32
Chipacabeuno: 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
ChipacaJamesTait: ^ might be for you actually12:34
* Chipaca puts on the kettle12:34
beunoChipaca, I haven't seen keeping that backwards compatibility force us to make compromises12:35
beunobut JamesTait and nessita would have a more boots-on-the-ground answer12:35
JamesTaitI'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
Chipacaon the client side it is a little fiddly, and that's without trying to make the remote-vs-local thing go away12:36
JamesTaitLike, we parse a yaml file instead of a json file, and we set the is_snap flag to True.12:36
beunoChipaca, the phone went through the same remote-vs-local phase, FWIW12:36
ChipacaJamesTait: you parse a yaml file?12:36
beunoJamesTait, we still parse the json12:36
JamesTait* May be simplifying slightly.12:36
beunoand snap packages copy over the yaml to json  :)12:37
beunoChipaca, so, for the most part, we can't split the stores12:37
beunobecause most of our deliverables apply to both12:37
Chipacait sounds like the store is doing the least work, and we're all muddled on the client12:37
Chipacawhich 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
beunoChipaca, so I think the idea of downloadind a metadata blob from the store is a recurring thing12:38
beunothe flat namespace is a good example12:38
beunoanother one will be the apparmor profile12:39
beunowhich we'd like to split out and have the store attach to apps at some point12:39
beunomy guess is we'll end up downlading and storing a separate blob of metadata anyway12:40
ogra_hello apt lists12:40
beunoogra_, 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 files12:42
beunoalso, if we're re-implementing apt, lets bring back dependencies!  I think that's what makes it fun12:42
Chipacabeuno: i am not opposed to downloading and storing separate metadata*; i'm opposed to having three different metadata sources :)12:42
beunoogra_, index files *with all apps in the archive*12:43
beunoogra_, not the ones you have  :)12:43
beunoChipaca, SO PICKY!  :)12:43
beunoChipaca, agreed12: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 information12:44
beunoChipaca, 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 metadata12: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 me12:44
mvo_plus its something we need to authenticated seperately, ideally having a gpg signature for the blob too12:45
sergiusensmvo_: that's why I asked for the store not to allow edits12:45
Chipacabeuno: "refresh it every now and then" is problematic12:45
mvo_sergiusens: I like that better than the alternatives12:45
Chipacabeuno: otherwise, with you12:45
sergiusensbeuno: mark said no caching12:45
beunoChipaca, I'm sure cron accepts "now and then" as a parameter12:45
mvo_especially since when we have delta downloads it won't matter if someone uploads a new version12:45
Chipacamvo_: problem is delta uploads :)12:45
beunosergiusens, I don't think he meant that. We've discussed downloading a metadata blob separate from the package many times12:46
beunomvo_, it won't matter to the user12:46
mvo_Chipaca: is it ;) we could make that work easily via snappy upload12:46
beunomvo_, it'll matter to the developer uploading 800mb12:46
sergiusensbeuno: right, but caching on the client he said no; ask lool ;-)12:46
beunomvo_, and spamming 100k users with a no-op download to s/downlod/download12:46
mvo_beuno: if we sign hashes.yaml thats a solvable problem12:46
mvo_beuno: we spam even more users if we cron a apt-get update like snappy run12:47
beunosergiusens, I'll bring it up, I think it will have been a different context12:47
mvo_don't get me wrong I'm not totally opposed but I dislike it12:47
Chipacai think there is a workable way12:47
mvo_and I think it will come back and hunt is in bad ways12:47
beunomvo_, I wouldn't cron, I'd update the list whenever you talk to the store, snappy update, etc12:47
loolthere will always be metadata outside of the package though12:48
loollike reviews12:48
beunoand, again, we already have the flat namespace12:48
loolall the metadata that the client might require while offline needs ot be in the package12:49
beunothat's the issue here12:49
beunowe disagree on that12:49
Chipacamaybe :)12:50
Chipacalool: there is metadata you don't have when you're offline12:50
loolChipaca: yeah, like reviews, that's fine12:50
Chipacayep, and all those don't need to live with the package12:50
loolbut you need things like the icon, the translated name12:50
Chipacaon disc12:50
Chipacahowever, the package when the user creates it is a series of metadata chunks, and the binary itself12:51
Chipacathat's then sliced and diced into a .snap file12:51
Chipacaand signed12:51
sergiusenswebdm ad click scope see a lot of problems with the current model fwiw12:51
Chipacaso you have a file that is, conceptually at least, a series of blobs and their signatures12:51
beunos/see a lot of problems/haven't implemented separate metadata storage12:52
Chipacawhen you download the package, the blobs get put in certain places, and you get the original package back again12:52
loolmaybe it's just confusing to have a general discussion on metadata and we only need to list the actual data and use cases12:52
Chipacacurrently, the store treats the package itself as a single blob12:52
Chipacahowever that does not need to stay that way12:52
Chipacathe store could treat it as a series of blob,sign pairs12:53
Chipacaand stream those12:53
Chipacaand then on unpack we'd put the metadata blob wherever, and would be none the wise12:53
beunoindeed we could12:53
Chipacawhile on the server the metadata blob was stored in a database, instead of in disc, and editing happens right there12:53
beunothere is metadata that the store will provide that the package won't, like UUID12:53
beunoso the file you give the store might not match exact what is served back12:54
Chipacaand the overall signature also12:54
Chipacabut that gives an on-disc and on-the-wire format that are the same, and an in-store format that lets us edit metadata12:55
* beuno nods12:55
Chipacaand it's all *almost* there12:55
sergiusensbeuno: it's fine for the store to provide more data; it's bad for it to modify provided data12:55
Chipacawe've just not been thinking about it in these terms12:55
Chipacasergiusens: why is it bad?12:55
beunosergiusens, it isn't, the user is!12:55
Chipacagosh this coffee is strong :)12:56
beunoand I don't want to force the user to re-upload 800mb to fix a typo, or even generate a new file and upload that12:56
beunothere's a nice web ui for them to do that12:56
sergiusensChipaca: 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 wrong12:56
Chipacasergiusens: you weren't following me maybe12:56
Chipacasergiusens: or maybe i wasn't clear12:57
sergiusensChipaca: if we delete package.yaml (or most of it) then fine12:57
sergiusensand please lets get rid of readme.md12:57
Chipacasergiusens: the on-disc (and on-the-wire) format of the snap package has all the metadata in one place; call it the package.yaml12:57
sergiusensChipaca: that's _$version12:57
sergiusenswhich we talked about12:58
Chipacasergiusens: 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 there12:58
sergiusensChipaca: ok, and does that need constant updating?12:58
Chipacasergiusens: that is a separate discussion i have no horse in12:59
beunoChipaca, sergiusens, another example of out-of-package metadata is release12:59
Chipacasergiusens: it could be, it could not be12:59
Chipacasergiusens: also, this might make _$version not necessary12:59
Chipacabut we are talking something that is not jfdi-level of change13:00
beunoand one that is convenient, because we can re-target the same binary to newer releases without changing it13:00
* JamesTait heads off for lunch13:00
sergiusensbeuno: I know of all these extras, I just don't like the sources being mangled with13:01
Chipacabeuno: 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 packages13:01
sergiusensbeuno: 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 all13:01
beunoChipaca, not sure I follow, deltas is still being pondered by mvo, on where to slice13:02
beunoper file, binary deltas, etc13:02
Chipacabeuno: 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
Chipacabut that's probably exactly what mvo is looking at :)13:06
Chipacaand it's even more pie-in-the-sky than the rest of the above13:06
Chipacasergiusens: i'm not sure i understand your "seeding" argument13:06
sergiusensChipaca: that was martin's initial argument, package.yaml is in the package just to seed the initial store configuration.13:08
sergiusensChipaca: and that it shouldn't be relied upon13:08
Chipacasergiusens: but that's not where we finished, is it?13:09
sergiusensChipaca: if we stream the files as you say, this may be not relevant but is considered "tampering" with the packaging13:09
sergiusensChipaca: changing uploaded files is weird, but then again it's not as the same user is changing them from a webform13:09
sergiusensunless they do package signing themselves...13:10
Chipacasergiusens: 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 key13:11
Chipacasergiusens: because meta is “ours”13:11
Chipacathat's the whole point13:11
Chipacawell, it's one of the whole points :-p13:12
nessitabeuno, 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 upload13:12
sergiusensChipaca: your idea makes me happy; well anything that gets us out of N sources of information makes me happy13:12
Chipacasergiusens: note my idea is 95%* reinterpreting what we already have13:13
Chipaca* some statistics copied from nessita13:13
Chipacaand then following up those reinterpretations, but nothing "new" really there13:13
Chipacaanyway, somebody should write this down before we forgot we agreed on something13:14
sergiusensChipaca: that's why we have architects; let's leave that to th people about to sprint :-P13:14
* beuno hits control + p > A4 > Print13:14
Chipacai'll send an email13:14
Chipacabeuno: +1 :)13:15
sergiusensChipaca: I sent a short one to rsalveti to start discussing during the architecture meetings13:15
sergiusensChipaca: before I thought the conversation would stop short (as it did most of the time)13:15
* sergiusens now feels hungry after what just happened13:16
seb128sergiusens, hey, I saw that you have goget changes up for review for personnal, any idea when that should land?13:22
sergiusensseb128: in a bit13:29
sergiusensseb128: but the images I create go into a boot loop (kvm)13:29
sergiusensseb128: did you have a succesful build yet?13:29
seb128sergiusens, yeah, I don't understand13:29
seb128grub has 4 entries13:29
seb128the first one which is snappy boot and goes back to grub13:29
seb128the "ubuntu" one fails to boot/hang in the middle of init jobs13:30
seb128I tried to boot on upstart, it stops on what seems like cloud-init's job having issues with the fs being ro13:30
seb128exceptions about creating a dir13:30
seb128sergiusens, 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
sergiusensseb128: there shouldn't be differences there13:33
sergiusensseb128: also try sudo losetup -d /dev/loop[0-9] before starting13:34
seb128sergiusens, thanks13:34
seb128sergiusens, anyway the amd64 issue is having those boot issues, I'm trying to have a look but didn't find anything useful so far13:34
seb128did you?13:34
sergiusensseb128: no, this was late last night13:35
dholbachhey JamesTait - I have a question :)13:37
dholbachJamesTait, if I use the app store APIs, can I filter for certain snap types?13:37
JamesTaitdholbach, "certain snap types"?13:37
dholbachJamesTait, like a gadget snap, a framework snap, etc13:38
dholbachhttps://developer.ubuntu.com/en/snappy/guides/package-metadata/ → 'type'13:39
JamesTaitdholbach, I don't know if we have that metadata available. The analogue in click packages would be content: app|scope I think.13:39
sergiusensJamesTait: we do13:40
dholbachJamesTait, can I filter for snaps right now, as opposed to clicks?13:40
sergiusensJamesTait: dholbach https://search.apps.ubuntu.com/api/v1/package/docker "content" in there13:41
sergiusensas an example13:41
nessitaJamesTait, we do have it, in the same field13:41
nessitaallowed types for far are application, framework13:41
nessita(for snaps)13:41
sergiusensnessita: and oem13:41
JamesTaitnessita, right, I was just trying to find one. ☺13:41
sergiusenshere's an oem one https://search.apps.ubuntu.com/api/v1/package/beagleblack13:42
sergiusensdholbach: to filter pass X-Ubuntu-Framework: ubuntu-core-15.04-dev1 (when can we rid ourselves from this? :-P)13:42
JamesTaitdholbach, https://search.apps.ubuntu.com/api/v1/search?q=content:"framework"13:43
sergiusensdholbach: and also X-Ubuntu-Release: [15.04-core|rolling-core|rolling-personal]13:43
nessitasergiusens, what do you mean with getting rid of the framework header?13:44
sergiusensJamesTait: can we do that with release and framework as well?13:44
sergiusensnessita: as in ubuntu-core-15.04-dev113:44
sergiusensnessita: 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
JamesTaitsergiusens, yes, you can.13:45
sergiusenskyrofa: do you have time to meet today?13:45
sergiusensJamesTait: neat, which is more efficient? as query param or http header?13:45
sergiusensrsalveti: https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.24-0ubuntu1 (why it is in no pocket I don't know)13:46
JamesTaitsergiusens, 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
rsalvetisergiusens: in a vortex :-)13:47
rsalvetisergiusens: thanks13:47
JamesTaitsergiusens, 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
JamesTaitsergiusens, whereas just putting it in the query string will return them regardless.13:48
sergiusensJamesTait: so http header is all or nothing? You make me ask questiong about our code base now :-P13:49
JamesTaitsergiusens, 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
JamesTaitYet, anyway.13:51
sergiusensJamesTait: but it's an || and not and && right?13:53
sergiusensJamesTait: as in you have to satisfy at least one of the declared frameworks13:54
=== chihchun is now known as chihchun_afk
JamesTaitsergiusens, 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
JamesTaitsergiusens, there's an example in https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex#Frameworks13:58
elopiofgimenez: meeting14:03
fgimenezelopio, omw14:04
sergiusensJamesTait: shouldn't this http://paste.ubuntu.com/11730647/ only return docker?14:07
JamesTaitsergiusens, it should return packages where framework is one of: ["docker"] ["docker", "ubuntu-core-15.04-dev1"] ["ubuntu-core-15.04-dev1"]14:09
sergiusensJamesTait: ah, so that was an || in my mind :-P14:13
fgimenezsergiusens, adding a 'img' flag would help? something like 'go run _integration-tests/main.go -img /path/to/img'14:27
sergiusensfgimenez: well, I need to test the u-d-f output too14:29
sergiusensfgimenez: stdout should warn about --device14:29
sergiusensrsalveti: we need an ubuntu-snappy release and to rebuild u-d-f after that to allow --install docker :-/14:33
rsalvetisergiusens: sure14:34
rsalvetisergiusens: anything waiting to be merged in ubuntu-snappy or can we just release current trunk?14:35
nothalsergiusens: No such command!14:36
nothalsergiusens: No such command!14:36
nothal"list" To see the available commands ; "help cmd" for specific command help14:36
nothalThe available commands are: ['bug', 'critical', 'help', 'last', 'list', 'more', 'ping', 'reviewlist', 'seen']14:36
nothalhttps://code.launchpad.net/~mvo/snappy/snappy-gettext/+merge/262202 | No reviews (less than a day old)14:36
nothalhttps://code.launchpad.net/~mvo/snappy/snappy-console/+merge/262061 | Approve: 1 (less than a day old)14:36
nothalhttps://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748 | No reviews (5 days old)14:36
nothalhttps://code.launchpad.net/~mvo/snappy/snappy-verify/+merge/261718 | No reviews (5 days old)14:36
nothalhttps://code.launchpad.net/~mvo/snappy/snappy-improve-developer-mode-detection/+merge/261646 | No reviews (6 days old)14:36
nothalogra_: No such command!14:37
sergiusensogra_: I was tied to lp speak14:37
sergiusensrsalveti: no, nothing in queue14:37
rsalvetilet me release that then14:39
JamesTaitsergiusens, sorry to disappear; other people needing attention, school run, I need a clone. ☺14:46
JamesTaitsergiusens, so a query string like ?q=framework:ubuntu-sdk-15.04-dev1,framework:docker would give you an ||14:47
sergiusensfgimenez: maybe update _integration-tests/README with the go run comment14:56
rsalvetisergiusens: https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.2-0ubuntu114:56
sergiusensrsalveti: thanks14:57
JamesTaitAlso, 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
sergiusensJamesTait: it does literals for package names at least as nessita showed me15:01
sergiusensJamesTait: so I want headers and not query strings for this and that last comment settles it15:02
nessitasergiusens, yes you do15:03
sergiusensnessita: err, what15:04
* JamesTait grabs a drink15:04
sergiusensnessita: in any case I know what I mean :-)15:05
seb128sergiusens, I found issues on the iso build which explain the hang, fixing them in livecd-rootfs now15:05
sergiusensseb128: oh nice, any reason why the image is so big?15:05
seb128sergiusens, define "so big"?15:06
seb128it's 2.5G15:06
ogra_compressed ?!?15:06
seb128ogra_, well, the ubuntu desktop iso is likge 1G15:07
sergiusensogra_: 2.5 uncompressed15:08
seb128and the snappy image is x2 because of the a-b partitions15:08
seb128so seems about right to me?15:08
ogra_ah, uncompressed15:08
ogra_that sounds rather sane15:09
fgimenezsergiusens, sure thx! elopio suggested changing the way we build images depending on the type of test being executed15:09
kgunnjdstrand: 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 server15:09
kgunni'm getting ubuntu-core-launcher:/apps/mir/snap1/bin/server.real pidof: Operation not permitted15:09
fgimenezsergiusens, elopio we still need to define how to group tests tough15:09
kgunnbut i've already add /bin/pidof to may aa file, which took care of the denial15:09
kgunnany ideas?15:10
kgunnthat's the script ^15:11
kgunnis it b/c it's outside of the mir binary itself ?15:11
sergiusenskgunn: add u or U (I forget which one is the more correct one)15:12
sergiusenskgunn: /bin/pidof Umrix,15:13
kgunnsergiusens: thanks! i'll try that15:13
kgunnsergiusens: i had added everything but that i think :)15:13
sergiusenskgunn: I have that a plenty; uU is for run unconfined15:14
sergiusensone cleans up the env while the other doesn't15:14
tyhicksUx scrubs the environment15:17
kgunntyhicks: what means "scrubs"15:17
* kgunn grunts like caveman15:17
tyhickskgunn: it attempts to remove any risky environment variables15:18
ogra_kgunn, audio or it didnt happen !15:18
tyhicksI don't like the idea of snaps being able to do unconfined transitions while calling out to external binaries15:19
tyhicksI'm not sure if that's what jdstrand has been recommending for situations like this or not15:20
tyhicksusing Ux will get you unblocked for now but we may end up wanting to do something more secure15:21
kgunntyhicks: no problem....i'm game to be a guinea pig15:21
kgunni 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/debian15:21
kgunntyhicks: do you consider using u on pidof ok for store use ?15:22
longsleepHey folks, can someone explain the strategy how snappy can use the full disk / resizing automatically on first boot or something?15:22
tyhickskgunn: well, jdstrand is the one that has been defining those boundaries so I'll defer to him15:22
mterrymvo_, 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
mterrymvo_, we used the same source and binary names, so at least we won't get two copies15:23
mterrymvo_, I fixed the test issue though by copying example files into the obj-* dir15:24
barrymvo_: yep, i'm confused :)  can you elaborate on what you want for LP: #1466124 ?15:25
ubottuLaunchpad 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/146612415:25
mvo_mterry: oh, nice! I thanks for fixing the tests. lets just merge it together15:25
mvo_barry: meh, I figured I did not express myself very well15:25
mterrymvo_, just add15:25
mterry# copy data files in15:25
mterrycp -r examples/*/ obj-*/src/github.com/gosexy/gettext/examples/15:25
mterrymvo_, to yours15:25
barrymvo_: s'okay :)15:25
mvo_barry: once sec, I'm in a meeting right now, won't help with being consistent15:25
mvo_eh or understandable or anything really15:25
mvo_mterry: \o/15:26
mterrymvo_, and then maybe switch your deletion of those files to dh_auto_install rather than dh_auto_build15:26
jdstrandsergiusens: your 'U's and 'u's are not necessarily recommended15:27
jdstrandkgunn: can you paste the full denial?15:27
jdstrandkgunn: can you use 'rmix' (ie, don't use 'U') and try again, showing me the denial?15:28
jdstrandkgunn: is this something that can run in a kvm ubuntu-core image?15:28
tyhicksnote 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
jdstrandso I'd prefer ix so we can then use signal mediation15:30
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 things15:31
tedgmvo_, 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
tedgmvo_, The list is hardcoded in that example.15:32
mvo_tedg: thanks, let me have a look15:32
mvo_tedg: http://paste.ubuntu.com/11731045/ is slightly shorter but yeah, srcpkg stuff is not the strength of python-apt15:37
mvo_tedg: this examle needs updating in the api docs :/ it does not reflect the latest features of python-apt. thanks for finding that15:37
tedgmvo_, 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.lookup15:39
tedgmvo_, 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 fixing15: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 output15:42
mterrymvo_, 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 work15:43
mvo_barry: our branch set this in the global config object15:43
mterrymvo_, but I'm not convinced the examples folder should be shipped, so yours might be doing the right thing there15:43
mvo_mterry: right, lets keep yours if its actually more complete, or is there a downside?15:43
mterrymvo_, just the examples folder15:43
mterrymvo_, and no source tree15:44
mterrymvo_, in vcs that is15: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 output15:44
kgunnjdstrand: hey, sorry, was on a HO...15:44
kgunnyeah so i ran last night with15:44
mterrymvo_, how would we stop one of our uploads?15:44
kgunn/bin/pidof mrix,15:44
mterryI'm  not used to cancelling an upload15:44
kgunnand the error was ubuntu-core-launcher:/apps/mir/snap1/bin/server.real pidof: Operation not permitted15: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
mterrymvo_, alright15:45
jdstrandkgunn: what is the apparmor denial? grep DEN /var/log/syslog15:45
barrymvo_: oh, do you just mean that the hook doesn't know whether --progress=json was provided on the cli?15:45
kgunnjdstrand: that's just it....there's not one15:45
mvo_mterry: we can just reject my upload, I can ask the archive admins to do that15:45
mvo_barry: yeah, exactly that15:45
mvo_barry: so it might be as simple as setting it as a transient config in the global config object15:46
mvo_barry: thats what I did in the fork we are currently using15:46
barrymvo_: ah, okay, that should be easy to expose in the global config15:46
jdstrandkgunn: is there a seccomp denial?15:46
kgunnjdstrand: nope15:46
barrymvo_: 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
jdstrandkgunn: did you disable kernel rate limiting?15:47
kgunnjdstrand: nope, but i can try that now15:47
mvo_barry: its not blocking us, I just always spit out json to stdout now15:47
barrymvo_: cool, thanks15:48
mvo_barry: which is bad but its only snappy thats driving it right now, so its not too terrible15:48
barrymvo_: ack15:48
mvo_thanks! and sorry that it was so confused15:48
barryno worries!15:49
barrymvo_: thanks.  description updated.  please sanity check15:50
mvo_barry: yes, thats it15:51
barrymvo_: \o/15:53
kgunnjdstrand: so diabled kernel rate limiting (with sudo sysctl -w kernel.printk_ratelimit=0)15:59
kgunnrun via systemctl start mir-blah.service16:00
kgunnthe syslog just shows16:00
kgunn"systemd started system compositor"16:01
kgunnno seccomp or aa denial error16:01
kgunnbut...system compositor doesn't appear in process list16:01
ogra_hack it to spit out more info ?16:01
ogra_(the systemd unit i mean)16:02
jdstrandkgunn: does the service try to drop privs and then regain them?16:03
kgunnjdstrand: i don't think so, the system compositors run as root....16:06
kgunnmterry: ^ any privlegde changes ?16:07
jdstrandkgunn: try using @unrestricted as the seccomp policy16:07
mterrykgunn, I don't think so16:07
mterrykgunn, is it waiting for agetty?16:07
mterrykgunn, or did the server shell script bail for some reason?16:08
kgunnmterry: sorry to bother you this is all about getting sec policy for mir correct (as  fmwk) to get in store....16:09
mterrykgunn, right (pidof stuff still?)16:09
kgunnworked through all the aa & seccomp errors, now stuck on pidof in the launching script16:09
elopioogra_: do you want to top-approve? https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/26183316:22
kgunnjdstrand: ok, so running with bin/pidof & bin/sleep :q16:24
ogra_elopio, done16:24
kgunnoops ignore the :q16:24
kgunnpidof and sleep with mrux, and syslog shows both "Opertation not permitted" just like before16:25
kgunnnote, that was without the kernel rate liimiting denial disabled16:26
rsalvetiogra_: sergiusens_: mvo_: one interesting problem: http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/pending/17:08
rsalvetithe azure device tarball is not getting updated from the build, since 9-jun17:09
rsalvetibut from the build log, it seems it was created17:09
rsalvetihow to find out what is going on at the cdimage side of things?17:09
ogra_there should be cdimage logs17:11
ogra_hmm, no mention of azure in there at all17:12
ogra_could it be that they need to have manual intervention ?17:12
rsalvetimaybe we're not building it17:12
rsalveti# now build the azure device tarball by adding walinuxagent17:12
rsalvetiif [ -e binary/boot/filesystem.dir/var/lib/dpkg/info/walinuxagent.list ];17:12
rsalvetithe check17:12
rsalvetithis is for vivid17:13
rsalvetiyeah, we're not building it17:13
rsalveti# now build the azure device tarball by adding walinuxagent17:14
rsalvetiif [ -e binary/boot/filesystem.dir/var/lib/dpkg/info/walinuxagent.list ];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.log17:14
rsalvetithe last one that had it17:14
rsalvetidaily-preinstalled-20150612.log already failed to generate it17:14
* rsalveti looks for walinuxagent related changes17:15
ogra_hmm http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/wily/daily-preinstalled-20150610.log ... that downloaded it as well17:15
rsalvetiogra_: right, that's wily17:15
rsalvetifor vivid we don't have 061017:15
ogra_i missed the "vivid" in the url above17:16
rsalvetibut it seems it was actually created ^17:16
rsalveti+ tar -c -z -f /build/device.tar.gz system assets hardware.yaml17:17
rsalvetithis from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/17:17
rsalvetichecking the latest amd64 image17:17
jdstrandkgunn: can you try with seccomp policy as @unrestricted?17:19
jdstrandkgunn: (sorry, been in a meeting)17:19
* jdstrand is still in the meeting17: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
rsalvetisergiusens_: right, wily is fine to not build it17:22
rsalvetimy concerned is that we're not building it for vivid17:22
rsalvetilaunchpad says we're building it, but the cdimage log is not showing that it copied it over17:22
sergiusens_rsalveti: but, but, but we released a few weeks ago17:22
rsalvetisergiusens_: yeah, failed the next day17:22
rsalvetiafter the release17:22
rsalvetisince the release day, we didn't get any other update17:23
rsalvetiand nothing really changed on our side17:23
sergiusens_rsalveti: system image's index says something different http://system-image.ubuntu.com/ubuntu-core/15.04/edge/azure_amd64/index.json17:24
sergiusens_last entry, version_detail17:24
rsalvetisergiusens_: right, that is fine, since cdimage is publishing the tarball, but the older one17:24
sergiusens_ah, the device tarball is stuck17:24
rsalvetithat's the usual issue with the cdimage side17:24
rsalvetiif something fails, it will just copy the older ones17:24
rsalvetisergiusens_: 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 :-P17:25
sergiusens_I'll brb17:25
ogra_yeah, just blame me17:25
rsalvetiogra_: where can I find the previous live-build logs?17:28
rsalvetisince we moved that to launchpad17:29
rsalvetislangasek: maybe you can help with this ^?17:33
rsalvetibasically I'm trying to figure out why device-azure.tar.gz wasn't published as part of cdimage for the last few images17:34
slangasekrsalveti: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core for instance?17:34
rsalvetislangasek: I'm looking at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/17:34
rsalvetibut I can only see a few17:34
rsalvetiand not easily go back in time17:34
slangasekrsalveti: 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 nusakan17:35
rsalvetiwould be 2015060917:36
rsalvetislangasek: do you know where to look?17:36
slangasekrsalveti: /srv/cdimage.ubuntu.com/log/ubuntu-core/wily/daily-preinstalled-20150609.log17:37
slangasekubuntu-core-system-image-amd64 on Launchpad starting at 2015-06-09 04:56:0217:37
slangasekubuntu-core-system-image-amd64: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image/+build/2918517:37
rsalvetislangasek: awesome, thanks!17:38
rsalvetiyeah, build seems fine17:39
* rsalveti looks for the cdimage cdo17: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 place17:41
slangasekno idea, no17:41
rsalvetiogra_: slangasek: so there is no 'azure' at all in the cdimage code17:42
rsalvetiand the only update, that happened at last 11, was to add the personal17:42
rsalvetiand that probably caused a sync17:43
rsalvetiwho added the azure logic in there?17:43
ogra_well, i had the impression the cloud stuff was some manual process17:43
seb128hum, so I got an image to boot in kvm17:43
ogra_seb128, yay17:43
seb128lightdm fails to start though17:43
ogra_oooh :(17:43
rsalvetiogra_: the manual part is after it gets in system-image17:43
ogra_rsalveti, ah, k17:43
seb128"Error using VT_ACTIVATE 7 on /dev/console: Inappropriate ioctl for device"17:43
seb128does that ring a bell to anyone?17:43
slangasekrsalveti: 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-rootfs17:44
seb128I can starts gallery-app with xinit though :p17:44
seb128so xorg is working17:44
ogra_seb128, kgunn had fun with agetty and mir wrangling around a tty all day i think17:44
rsalvetislangasek: was thinking about cdimage because we need to copy the tarball over17:44
rsalvetiafter it gets published17:44
rsalveti                if config.project in ("ubuntu-core", "ubuntu-desktop-next"):17:44
rsalveti                    device = "%s.device.tar.gz" % live_prefix17:44
slangasekrsalveti: 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 branch17:44
rsalveti                    if os.path.exists(device):17:44
rsalveti                        shutil.copy2(17:44
rsalveti                            device, "%s.device.tar.gz" % output_prefix)17:44
rsalvetithis is the piece that copy it over17:45
rsalveti            live_prefix = os.path.join(live_dir, arch)17:45
rsalveti            rootfs = "%s.rootfs.tar.gz" % live_prefix17:45
rsalvetiso unless I'm not reading it right, there is indeed nothing copying it around17:46
ogra_well, that code is pretty generic17: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
rsalvetiogra_: slangasek: I fail to see how this ever worked =\18:01
slangasekrsalveti: 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
rsalvetithe tarball is there18:01
rsalvetimvo_: if still around ^?18:02
rsalvetiat least the problem is consistent with both vivid and wily, and also started at last 1118: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-rootfs18:13
rsalvetisergiusens_: right, and it's there18:14
rsalvetijust not imported/copied in cdimage18:14
rsalvetiogra_: sure18: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
rsalvetifor some reason I only had your reply and not the original email, which is now there (and was unread)18:14
* sergiusens_ winks18:14
rsalvetimy gmail is kind of going crazy lately18: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.binary18:15
ogra_sergiusens_, ha, wishful thinking18:15
sergiusens_rsalveti: I started using mutt again18:15
rsalvetisergiusens_: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/2994418:15
rsalvetiright, see the azure is there18:15
rsalvetisergiusens_: mutt + google imap?18:15
sergiusens_I only go to gmail to search18:15
sergiusens_rsalveti: yup, offlineimap18:15
rsalvetiright, might be better indeed18:15
ogra_evolution FTW :)18:15
ogra_has still the fastest search tools18:16
sergiusens_rsalveti: searching is good in gmail; organizing and cleaning up the queue and not missing content is better in a proper MUA18:16
sergiusens_ogra_: makes you need a revolution in RAM though18:16
ogra_my XPS copes fine with its 8G18:16
ogra_and i dont have any device in use with less anymore18: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 it18:17
ogra_we dont know how it got from here to there18:17
ogra_(the logs show it gets copied)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
rsalvetiyeah, was looking at the code, but can't see to find how it was copying ti before18:18
rsalvetisergiusens_: check lp:ubuntu-cdimage18:18
rsalvetigrep for "Downloading live filesystem images"18:18
rsalvetithat is where the magic happens18:18
ogra_ogra@styx:~/Devel/branches/cdimage$ grep -r azure *18:19
ogra_thats the weird part18:19
rsalvetithat copy the files from launchpad into /srv/cdimage.ubuntu.com/scratch/ubuntu-core/vivid/daily-preinstalled/live18:19
rsalvetiwhich is the missing link, because it's not copying over the azure tarball18:19
ogra_well, i dont get how it would even know about azure at all18: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 config18:20
rsalvetimvo_: yes18:20
ogra_(or in any bzr changelog)18:20
mvo_how confusing, my first guess is a livecd-rootfs upload18:20
rsalvetimvo_: it's not livecd-rootfs, since it's there: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/2994418:20
mvo_I'm sure the ubuntu-personal guys broke it18:20
ogra_mvo_, not really, livecd-rootfs does what it should18:20
rsalvetithe device tarball was built18:20
ogra_cdimage doesnt import it18:21
mvo_there goes my theory and the blame I wanted to assign :/18:21
ogra_i got blamed already, find someone else :P18:21
* ogra_ only takes the blame once a day18:21
rsalvetimvo_: so it might be connected with personal18:21
rsalvetimvo_: there was a personal change in cdimage at 1118:21
rsalvetiwhich would probably cause a sync in the bzr repo18:22
rsalvetiso if the azure change was done outside trunk, then it would be lost18:22
ogra_but who would do that18:22
ogra_https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup ...18:22
rsalvetithat's just a theory18:22
ogra_(in case people dont use that way ... )18:23
rsalvetiunless I'm missing some magic in lp:ubuntu-cdimage18:23
seb128mvo_, nice blame try!18:24
* mvo_ hugs seb12818:24
* seb128 hugs mvo_ back ;-)18:24
ogra_and so subtle :)18:24
rsalvetiyeah, the branch was pushed at 11 by Laney18:27
rsalvetireflecting the personal changes, but that has nothing to do with azure18:27
slangasekrsalveti: we wouldn't normally do a 'bzr pull --overwrite'; if someone did that, that's quite bad18:27
ogra_right, makes your theory more plausible18:27
slangasekthe usual protocol is 'bzr pull'; notice conflicts; yell at cowboys18:27
ogra_and the branches are bound you wouldnt ever be able to commit18:29
ogra_OH !18:29
ogra_but perhaps the config is in debian-cd, not cdimage18:29
* ogra_ goes checking18:29
ogra_hmm, no18:30
ogra_ogra@styx:~/Devel/branches/debian-cd$ grep -r azure *18:30
rsalvetianother funny thing I noticed because of this18:35
rsalvetithe kernel config seems to be available via the rootfs18:35
rsalvetiafter creating the azure image I had vmlinuz-3.19.0-18-generic and config-3.19.0-21-generic18:35
rsalvetiat /boot18:35
mvo_rsalveti: yeah, we keep it in /boot because our grub needs it this way, we want to consolidate this18:36
ogra_well, we dont have /proc/config.gz enabled18:36
ogra_they are on the arm images too18:36
ogra_needs cleanup ...18:36
rsalvetimvo_: right, but why is this part of the rootfs?18:36
rsalvetiyeah, will open a bug in a few18:36
mvo_rsalveti: oh, right, we don't want it there18:37
sergiusens_mvo_: ogra_ rsalveti so is this what is needed? http://paste.ubuntu.com/11731958/18:43
sergiusens_I just blindly added that18:43
mvo_sergiusens_: could well be, I'm trying to understand why it worked before :/18:43
ogra_not sure you want azure hardcoded there18:43
rsalvetisergiusens_: something similar to that is what I had in mind, but the question is indeed what mvo_ just said18:43
rsalvetifor now I just manually copied over the new tarball and triggered a new image18:44
rsalvetisee 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 strange18:50
rsalvetitoo bad this is not git18:51
rsalvetigit reflog would explain it all18:51
ogra_rsalveti, even if someone forcefully overwrote it ?18:52
rsalvetiogra_: yup18:52
ogra_(including history)18:52
sergiusens_rsalveti: mvo_ a bzr push --overwrite to lp or a bzr pull --overwrite on the client explains most of this to me18:52
rsalvetiit's my solution when I do git reset --hard HASH18:52
* ogra_ guesses some day he wont get around looking at git :P18:52
sergiusens_ogra_: as soon as we move to it ;-)18:52
rsalvetiand then omg omg omg I forgot to save a patch18:52
ogra_(i must admit i'm surprised that i still do :) )18:52
rsalvetigit reflog gives me the complete history18:52
rsalvetisergiusens_: yeah18:53
mvo_sergiusens_: yeah, I think thats it18:53
mvo_and someone *cough* *cough* cowboyed it in18:53
mvo_before without a proper branch18:53
* mvo_ hides in shame18:53
mvo_but to be fair, that azure enablement was really on a super tight deadline18: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 error18:55
ogra_bzr definitely complained18:55
mvo_sergiusens_: this may need a additional download_live_items() in lib/cdimage/livefs.py18:55
mvo_ogra_: indeed18:56
* ogra_ blames Laney in absence :) 18:56
ogra_finally we can pass on the blame :)18:56
rsalvetiyeah, the push --overwrite was even worse18:58
sergiusens_mvo_: like http://paste.ubuntu.com/11732046/ ?19:01
sergiusens_I don't really follow this code base :-P19:01
ogra_i still think it should somehow be injected into source_prefix instead of hardcoding it19:02
mvo_sergiusens_: yeah, I think something like this19:02
sergiusens_ogra_: I would leave that to you :-P19:03
sergiusens_well I pushed here: lp:~sergiusens/ubuntu-cdimage/azure19:03
* rsalveti hands the cowboy hat to mvo_ 19:03
mvo_sergiusens_: \o/19:03
sergiusens_in case you want to merge19:03
* sergiusens_ wants the cowboy hat19: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 style19: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 issue19: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 :-P19: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 have19:06
ogra_sergiusens_, you do19:06
ogra_you got them together with rsalveti back then19:06
sergiusens_ogra_: heh, I was playing dumb :-P19:07
ogra_yeah, cant cheat me :P19:07
sergiusens_ogra_: the tests fail here even without my changes!19:07
mvo_sergiusens_: lol19:07
ogra_oh man19:07
ogra_Laney, !!!19:07
mvo_his change does not look like it would break tests19:08
mvo_but who knows19:08
* mvo_ does not19:08
sergiusens_mvo_: coincidentally I have19:08
sergiusens_mvo_: http://paste.ubuntu.com/11732086/19:08
sergiusens_but there are 4 failures regardless19:08
jdstrandkgunn_: 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.gz19:09
mvo_sergiusens_: oh, I mean the changes that Laney did do not look like they would break stuff, but again, who knows19: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 now19: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 again19:16
sergiusens_mvo_: I have a good feeling about this one http://paste.ubuntu.com/11732146/ thanks for your base branch for device19:19
mvo_sergiusens_: yay, lets give it a try!19:20
sergiusens_mvo_: ok, let me do an actual checkout19:20
Chipacasergiusens_: mvo_: when can we have a coven about changes to snaps for 16.04?19:23
ogra_16.04 ? thats so far out !19:23
Chipacaogra_: far out, man!19:24
Chipacasergiusens_: mvo_: +119: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, no19:24
ogra_only cdimage should be enough19:24
sergiusens_ogra_: just in case; gets out of the server asap19:24
* mvo_ is very curious19:25
sergiusens_ogra_: mvo_ that's all I did http://paste.ubuntu.com/11732185/19:26
fikseis there an argument for snappy ubuntu + consule + ...19:26
fiksevs coreos?19:26
Chipacamvo_: about changes to snaps?19:26
sergiusens_so I guess we can trigger a build now19:26
fikseconsul, not consule19:26
Chipacafikse: what's consul?19:26
ogra_sergiusens_, perfect19:26
sergiusens_consult maybe?19:26
fiksea tool for service discovery https://consul.io/19:27
mvo_Chipaca: about changes to snaps?19:27
Chipacamvo_: * mvo_ is very curious19:27
mvo_sergiusens_: now its time to run a build, no?19:27
sergiusens_mvo_: yup19: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 well19:28
mvo_sergiusens_: yes19:28
* sergiusens_ logs back in19:28
* sergiusens_ gets goosebumps19:28
* ogra_ grins19:28
sergiusens_mvo_: last time I was in there we were fixing that crazy system image server indexing problem :-P19:28
Chipacafikse: 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 wily19:31
fikseChipaca: i'm afraid it might be too early19:33
elopiosergiusens_: can you get your server running the snapcraft tests?19:34
sergiusens_too early it is then19:34
sergiusens_elopio: if it's in the .tarmac.sh, yes19:34
ogra_geez, we have tests already ?19:34
ogra_snapcraft doesnt even exist !19:34
ogra_you guys are so ahead19:34
* ogra_ makes a note to check the test code to know what he will develop in a few months 19:35
elopiotdd baby!19:35
elopiosergiusens_: yes, there's a .tarmac.sh.19:35
sergiusens_elopio: just add it there19:35
sergiusens_ogra_: I don't see the build here https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image19: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-preinstalled19:36
ogra_hmm, looks fine19:36
sergiusens_ogra_: generally do crontab -l |grep something19:37
Chipacafikse: 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-examples19:37
sergiusens_ogra_: I thought you told me way back not to use that :-P19:37
ogra_you should always use whats in the crontab19:37
sergiusens_ogra_: ok; but I'll search for that conversation :-P19:37
ogra_now change your password19: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-image19:38
sergiusens_or maybe password :-)19:38
ogra_nah, i use that already ... he cant take that19:39
mvo_sergiusens_: ooooohhhh19: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
fisch246will snappy personal eventually merge back to the current branch of Ubuntu Desktop when it's deemed ready?19:45
ogra_merge back ?19:45
fisch246so 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.1019: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 actually19:47
fisch246nah it would be snappy19:47
ogra_i suspect though that we wont auto-migrate users from deb based systems to snappy19:47
fisch246so  basically would the deb based version be dropped19:47
fisch246ah okay19:47
fisch246so if people want to stick with deb they will stay deb for good if they wish19:47
ogra_no, there are too many people using the deb archive ... (flavours and such) ...19:47
fisch246well for now at least19:48
ogra_for a snappy install you will most likely do an install from scratch19:48
fisch246cool 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
ogra_and also snappy is built from debs from the archive19: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
DarwinFwhat'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 though20:00
sergiusens_rsalveti: btw https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.24-0ubuntu220:01
ogra_sergiusens_, your images are done btw20:01
ogra_well, the livefs build20:02
DarwinFogra_: thanks20:02
rsalvetisergiusens_: nice, so you fixed cdimage?20:02
sergiusens_rsalveti: I'm not sure yet :-P20:03
ogra_rsalveti, but he forgot to add powerpc while doing that20:03
rsalvetilol, alright20:03
rsalvetithat's super important20:03
* rsalveti hands a few beers to sergiusens_ 20:04
sergiusens_rsalveti: http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/pending still shows June 11 for azure20:04
sergiusens_not sure if I need to wait for all builds to finish here20:04
sergiusens_ogra_: wily-preinstalled-core-amd64.azure.device.tar.gz 11-Jun-2015 05:13  140M20:05
ogra_no, thats up to date i think20:05
sergiusens_11 and not 1720:05
ogra_before it was 0920:05
rsalvetiwily was 1120:05
rsalveti09 was vivid20:05
rsalvetiand 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
rsalvetias a workaround20:05
rsalvetibut, it seems the importer still didn't see the new image20:06
sergiusens_ogra_: where is that "Publishing " message supposed to be logged?20:06
rsalvetiwhich is super annoying20: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/killall520:07
rsalvetiman, so many paths20:07
kgunn_which makes sense based on what tyler said earlier20:07
kgunn_e.g. pidof is actually part of killall520:07
rsalvetiyeah, for wily it's still not there http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/pending/20:07
ogra_sergiusens_, /srv/cdimage.ubuntu.com/log/ubuntu-core/wily/daily-preinstalled-20150617.3.log on nusakan20:08
rsalvetiyeah, more up-to-date log20:08
ogra_no trace of azure there :(20:08
rsalvetino azure20:08
jdstrandkgunn_: ok, so use /sbin/killall5 ixr,20:09
rsalvetiogra_: how many hours is the importer taking nowadays?20:09
ogra_the "publishing" actually comes from debian-cd i think20:09
kgunn_ack, was doing as you typed20:09
ogra_rsalveti, not long for core20:09
rsalvetiseems there is one importer running atm20: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-cdimage20:10
ogra_yeah, and the word doesnt appear in a grep in debian-cd20:10
ogra_only in cdimage20: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 different20:15
sergiusens_ogra_: different? livecd.ubuntu-core.azure.device.tar.gz  vs livecd.ubuntu-core.device.tar.gz20:16
ogra_i think it is more than just  livecd.ubuntu-core ... moght be a full path20:17
jdstrandkgunn_: yes please. we want to get rid of any ux's20:18
jdstrandkgunn_: 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/2999720:18
ogra_well, if you look at http://paste.ubuntu.com/11732394/ ... source_prefix might have a stamp and all20:19
kgunn_jdstrand: yeah it is20:19
ogra_https://launchpadlibrarian.net/209363495/livecd.ubuntu-core.rootfs.tar.gz ...20:19
sergiusens_ogra_: oh, I found an issue in my diff20:21
jdstrandkgunn_: if you give me instructions, then I can maybe expedite this20:21
kgunn_jdstrand: sure....let me clean up and push and i'll share20:21
jdstrandthat said, I do have something I'm working on atm and won't be able to get to it for a little while20:22
jdstrandbut certainly full-force in the morning if not later today20:22
kgunn_jdstrand: i'm making some headway now...but i'll share later20:22
jdstrandkgunn_: ok, however you want to do it20:23
kgunn_i think the tricky bit was not realizing that @unrestricted would lead to more aa denials to add20:23
sergiusens_ogra_: http://paste.ubuntu.com/11732451/20:24
ogra_sergiusens_, uuuh20:24
ogra_yeah :)20:24
sergiusens_ogra_: I could just make that amd64 as well :-P20:24
sergiusens_ogra_: is that an ack?20:25
ogra_well it is only temporary anyway20:25
ogra_sure, do it20:25
sergiusens_ogra_: so just like http://paste.ubuntu.com/11732463/20:26
ogra_yup, looks fine20:26
sergiusens_ogra_: rsalveti ok, new build triggered20:27
* ogra_ crosses fingers20:28
* sergiusens_ takes a break to walk the dogs20:28
rsalvetisergiusens_: awesome20:33
rsalvetiimporter still not finished20: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 morning20:35
sergiusens_rsalveti: build not done yet (I think all builds need to finish)20:47
rsalvetino, this was one importer from more than one hour ago20:47
rsalvetithat was still running20:47
rsalvetisergiusens_: importer is another cronjob20:48
rsalvetieverything is pull based20: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 11th20:53
Laneyogra_: 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
Laneymore or less20:55
ogra_seems there was some cowboyed code in there and it was overwritten20:55
ogra_and usually cdimage screams loudly if thats the case to prevent you from merging20:56
Laneywell maybe someone ran bzr revert or whatever20:56
Laneyit'll only complain if there are conflicts, not sure I touched the same areas20:56
kgunn_reading, this looks related...20:57
ogra_Laney, thanks ...20:57
Laneysorry if it was me, didn't do it on purpose20:57
Laneyis the code still alive?20:58
ogra_no, seemingly not ... well, not the code we need20:58
ogra_and nobody seems to have a backup20: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
jjohansenkgunn_: what confuses you about it? mir_system-compositor_snap1 is trying to trace an unconfined peer process21:02
kgunn_jjohansen: i'm quite new to these concepts, and i'm going through the process of getting the security profile correct for21: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
jjohansenkgunn_: well, generally speaking we don't allow a confined process to trace unconfined21:05
jjohansenkgunn_: 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 pidof21:06
kgunn_that's where this is coming from21:06
jjohansenkgunn_: hrmm, so my initial reaction is don't do that :)21:08
jjohansenkgunn_: 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 store21:09
kgunn_jjohansen:  :) i just found the line in docker21:09
jjohansenjdstrand: ^ any suggestions21:09
sergiusens_rsalveti: yeah :/21:09
sergiusens_oops, ogra_ :-P21:09
kgunn_jjohansen: i'm sure jamie will spank me :)21:09
ogra_sergiusens_, rsalveti ... erm ...21:10
ogra_sergiusens_, so your cdimage code is fine, it actually copied it over ... but i suspect livecd-rootfs isnt rebuilding it actually21: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 :-P21: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 log21:12
ogra_and no error21:12
sergiusens_ogra_: well, it's getting the wrong link from librarian21:13
sergiusens_ogra_: latest build is https://launchpadlibrarian.net/209363535/livecd.ubuntu-core.azure.device.tar.gz21:13
ogra_ah, ok21: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 easier21:14
sergiusens_ogra_: heh21:15
ogra_it is all cody-summervilles fault !21:15
jdstrandjjohansen, kgunn_: sorry, reading backscroll21:16
rsalvetijust check the lp job, it should tell if the azure tarball is in there21:16
ogra_rsalveti, yeah, that bit is fine21:17
sergiusens_rsalveti: it's there, the librarian link is wrong21:17
ogra_but we're not finding the right url21:17
rsalvetihow that21: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.gz21:18
rsalvetibut 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 though21:19
ogra_according to the log21:19
kgunn_hmmm, but now i hit trace denied for all sorts of bespoke peers (webdm, docker, mir itself)21:20
rsalvetiogra_: sergiusens_: /srv/cdimage.ubuntu.com/scratch/ubuntu-core/wily/daily-preinstalled/live21:20
sergiusens_ogra_: rsalveti I think I found one more location21:20
rsalvetiit's there21:20
ogra_yes, it is not publishing it21:20
rsalveti-rw-r--r-- 1 cdimage cdimage 147294112 Jun 17 20:34 amd64.azure.device.tar.gz21:20
rsalvetiwell, takes a while for it to be public21:20
* ogra_ was just looking at the same file :) 21:20
ogra_rsalveti, cdimage logs when it publishes it21:21
ogra_there is no azure in the log21:21
ogra_ /srv/cdimage.ubuntu.com/log/ubuntu-core/wily/daily-preinstalled-20150617.4.log21:21
rsalvetinot at /srv/cdimage.ubuntu.com/www/full/ubuntu-core/daily-preinstalled/pending21:21
rsalvetiman, this is so much more complicated than it should be21:22
ogra_i want shell back !21:22
rsalvetiinvolves 3, 4 different servers21:22
ogra_would have taken me minutes21:22
jjohansenkgunn_: sure, ptrace is dangerous. you will need specify each of them21:23
jjohansenkgunn_: and the reverse relation as well, that is those apps have to declare the relationship as well21:23
jdstrandkgunn_: 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
jjohansenthis prevents an attacker app being able to declare its allowed to ptrace without the peers saying yeah we know and trust him21:24
jdstrandkgunn_: the problem is that if you you are allowed to trace unconfined, unconfined allows anything to trace it21:24
rsalvetisergiusens_: looks ok21:24
jjohansenjdstrand: right, so no better suggestion for now21:24
ogra_sergiusens_, yeah21:25
jjohansenjdstrand: really we need to fix that21:25
jdstrandjjohansen: fix the mir policy or that unconfined allows tracedby?21:25
jdstrandor both :)21:25
jjohansenboth :)21:26
jdstrandso, I will probably make this a little better with a child profile for pidof21:26
jdstrandthat way even if mir has an issue, it would need pidof to allow something unexpected21:27
jdstrandonce kgunn_ gets through the initial policy, he'll give it to me to review and I can play with it21:28
sergiusens_ogra_: rsalveti ok, this one is the one21:28
stgraberjdstrand: 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_: yes21:29
* sergiusens_ starts to use http://whatthecommit.com/ again21:29
=== sergiusens_ is now known as sergiusens
stgraberjdstrand: I was hoping I wouldn't have to also make our client tool unconfined :)21:29
jdstrandstgraber: it should be allowed by the policy. You need to look in SNAP_APP_USER_DATA_PATH21:29
ogra_stgraber, snappy binaries can not write to $HOME ...21:29
stgrabererror: mkdir /root/apps/lxd/0.11-0/.config: permission denied21:29
ogra_SNAP_APP_USER_DATA_PATH is a subdir for the app in $HOME21:30
rsalvetisergiusens: seems we're good regarding the --install=docker issue: https://bugs.launchpad.net/snappy/+bug/1465879/comments/521:30
ubottuUbuntu bug 1465879 in Snappy "docker framework does not install via ubuntu-device-flash" [High,Confirmed]21:30
jdstrandyou don't get all of home, you get SNAP_APP_USER_DATA_PATH21:30
sergiusensChipaca: http://whatthecommit.com/bf057fb0e2e7a4450250ebf7d6e1d084 :-P21:30
stgrabersure sure, but clearly I don't even get write access to SNAP_APP_USER_DATA_PATH21:30
jdstrandstgraber: is that an apparmor denial?21:30
ogra_stgraber, because /root is readonly perhaps ? ;)21:30
stgraberogra_: isn't21:31
jdstrandand 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=021:31
Chipacasergiusens: ?21:31
sergiusensChipaca: I am just fooling around :-)21:31
Chipacasergiusens: http://whatthecommit.com/0041a2c1bcc6d21895a46d0b92f64a88 then :)21:31
jdstrandstgraber: oh, that is because we are using @{HOMEDIRS}/*/ instead of @{HOME}. @{HOMEDIRS}/*/ does not include /root.21:32
jdstrandstgraber: I remember I asked other snappy devs about this21:32
stgraberthat probably ought to be fixed :)21:32
jdstrandand it was decided that /root/ was not needed. apparently that needs to be revisited21:32
jdstrandstgraber: before I fix it, I think there might need to be a discussion. can you file a bug agount snappy, the project?21:34
jdstrandstgraber: you can add an ubuntu-core-security task21:34
jdstrandstgraber: I have questions around /root, the FHS, rollbacks, etc21:34
stgraberjdstrand: says that ubuntu-core-security doesn't use LP for bugs so can't add a task21:36
stgraberjdstrand: anyway, bug 146623421:36
ubottubug 1466234 in Snappy "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Undecided,New] https://launchpad.net/bugs/146623421:36
jdstrandstgraber: sorry, snappy the project and ubuntu-core-security under Ubuntu21:36
jdstrandI can add it21:37
stgraberah, done21:37
jdstrandstgraber: ok, I asked my questions. if the snappy devs are comfortable with it and respond in the bug, I'll adjust the policy21:40
stgraberjdstrand: 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.start21:43
stgraberaa_change_onexec failed with -121:43
stgraber. errmsg: No such file or directory21:43
stgraberwhat does that mean? ^21:43
jdstrandstgraber: it couldn't find the profile 'lxd__0.11-0'21:43
jdstrand'lxd__0.11-0' is not formatted well btw'21:43
jdstrandso either the yaml has an issue or the launcher isn't calculating the appname part correctly21:44
jdstrandthere should be something between the '__'21:44
jdstrandit should be the name of the service (from services) or the binary (from binaries)21:45
stgraberoh, also, that thing is a framework, not sure if that's relevant21:45
jdstrandit isn't relevant to what should be happening. it might be a contributing factor to a bug21:45
jdstrandstgraber: can you paste /apps/lxd/current/meta/package.yaml?21:46
stgraberoh, I think I know what's wrong in the yaml, testing21:46
stgraberjdstrand: 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
stgrabernow to figure out the next problem21:49
Chipacatedg: your opinion wrt SNAP_APP_USER_DATA_PATH might be relevant to #146623421:49
Chipacabug #1466234 that is21:49
nothalBug #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
ubottubug 1466234 in ubuntu-core-security (Ubuntu) "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Undecided,Incomplete] https://launchpad.net/bugs/146623421:49
jdstrandstgraber: yes, the review tools are currently disabled (they would have caught)21:51
stgraberjdstrand: so, http://paste.ubuntu.com/11732810/, any idea why I'm getting apparmor denials with that for the service?21:51
stgraberJun 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
stgraberdoesn't look unconfined to me :)21:52
jdstrandChipaca: is there a bug to re-enable the review tools?21:52
ogra_Wed Jun 17 21:53:12 UTC 201521: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_sergiusens, rsalveti ^^^21:53
sergiusensogra_: it just just just finished :-P21:53
ogra_i was tailing the log :=)21:53
sergiusensogra_: http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/20150617.5/ is up to date as well21:54
jdstrandstgraber: 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/unconfined21:54
jdstrandstgraber: it is missing a 'pivot_root,' rule21:54
stgraberjdstrand: ah, what do I do to get something that's completely unconfined?21:54
* kgunn realizes no one likes being confined21:55
stgraberbecause no pivot_root is going to be a bit of a problem for us :)21:55
jdstrandstgraber: I can add that21:55
stgraberjdstrand: anyway I can easily do that locally so I can see what fails next?21:56
Chipacajdstrand: nope21:56
jdstrandstgraber: 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 added21:56
stgraberjdstrand: ok, I'll add the rule locally for now21:57
jdstrandkgunn: well, yes, but lxd is quite a different beast :)21:57
stgraberjdstrand: will that profile with this addition let me switch profile, specifically to real unconfined?21:57
kgunnjdstrand: 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-server21:58
kgunnand the question is about paths...21:58
kgunnsince mir-demo-server is actually in debs/usr/bin21:58
ogra_(all relative to your SNAP_APP_PATH)21:59
kgunnogra_: ta21:59
kgunnsee i knew it was easy21:59
kgunnjdstrand: 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
elopioI need some go help in here. When I run go test ./... I get cmd/snappy/common.go:28: undefined: priv.WithMutex22:01
elopiobut it is defined, and I don't get that error from my desktop.22:01
kgunnsince it needs some paths not needed by the main service22:02
elopiogo is drunk.22:02
Chipacaelopio: tell me more22:07
Chipacaelopio: i have a good guess as to what's happening22:07
Chipacaelopio: 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 on22:08
elopioChipaca: I don't know what else to tell you. I've pulled trunk and ran the tests.22:08
Chipacaelopio: because you're running the tests with ./... you're not picking up that snappy for the test runner22:08
rsalvetiogra_: sergiusens: lovely22:08
Chipacaelopio: but the imports in files under test use absolute paths22:08
Chipacaelopio: e.g. launchpad.net/snappy/potato22:08
Chipacaelopio: so those are coming from your GOPATH22:08
jdstrandkgunn: this is where framework-policy comes into play I think, or maybe not22:10
kgunnwell, i see i can add the client policies that the framework publishes22:11
kgunnfor use as a cap by  the binaries22:11
kgunnbut, don't want to expose more through that than is needed....22:11
elopioChipaca: it works now ¬¬22:12
Chipacaelopio: 🙌22:13
jdstrandkgunn: 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
elopioI removed my link from the GOPATH to my workspace. Then made it again...22:13
elopioChipaca: how do you handle different branches in src/launchpad.net/snappy ? Do you use ln ?22:13
Chipacaelopio: you use a pipeline?22:14
kgunnjdstrand: nope, sorry... so there's a binary mir-demo-server which is launched by (the service) mir-compositor22:14
Chipacaelopio: bzr gets confused by symlinks22:14
jdstrandkgunn: if it can use the minimum with the default template, then you can refer to your framework-policy22:14
kgunnthis is before clients actually show up...22:14
jdstrandkgunn: ok, in that case, you need to write "security-policy" for your binary22:14
elopioChipaca: 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
kgunnjdstrand: ok, so follow the same construct/form...22:15
jdstrandkgunn: yes22:15
Chipacaelopio: ok22:15
kgunnjdstrand: frighteningly i may understand this before i'm all done :)22:15
Chipacaelopio: that'll confuse either go or bzr, depending how you're doing it22:15
Chipacaelopio: you can make it work if you're careful22:16
jdstrandkgunn: I'll also (hopefully) helpfully remind you that https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/DevelopingFrameworkPolicy has boilerplate22:16
Chipacaelopio: me, i gave up using symlinks and just move stuff around22:16
Chipacaelopio: when i'm not using pipelines that is22:16
elopiothis is the first time it failed, so I guess I wasn't careful.22:16
elopioChipaca: do you mean http://wiki.bazaar.canonical.com/BzrPipeline ?22:16
Chipacaelopio: yes22:16
elopiook, I'll try that.22:16
kgunnok...nuff for now, maybe more later22:17
Chipacaelopio: and in bazar.conf,22:17
Chipacan = swp :next22:17
Chipacap = swp :prev22:17
Chipacaps = pipes22:17
elopioChipaca: those are alias, right?22:18
Chipacaelopio: in [aliases] i mean22:18
elopiocool. Sounds less insane than links.22:18
Chipacaelopio: until it throws a stacktrace at you, sure :)22:19
sergiusensI recall those22:20
sergiusensdel-pipe has some issues22:20
Chipacasergiusens: just switching with new files added but not committed seems to tickle it22:21
sergiusensChipaca: oh, that works fine for me22:21
Chipacaelopio: everything is terrible.22:21
Chipacaelopio: we're moving back to C, and CVS22:22
slangaseksergiusens: sorry, I have no brain state relevant to the azure files/builds/downloads.  If you're stuck I'd suggest tagging the launchpad team22:29
elopio:) let me first hate pipeline before making the move.22:29
sergiusensslangasek: fixed 30' ago, but thanks :-)22:31
slangaseksergiusens: hah, ok22:31
sergiusensrsalveti: do you plan to copy https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.24-0ubuntu2 to tools-proposed?23:05
rsalvetisergiusens: already there23:06
rsalvetisergiusens: and utlemming just confirmed that it worked for him23:06
rsalvetiso all good23:06
sergiusensrsalveti: oh neat :-)23:06
sergiusensone more thing to cross off the list :-)23:06
sergiusensrsalveti: are you moving it to tools per se?23:06
sergiusensor waiting on that one?23:06
rsalvetisergiusens: not now, want to migrate things at the same time we get to test our next stable image23:07
rsalvetiso we can all be testing the same thing all together23:07
sergiusensrsalveti: sounds good23:08
sergiusenselopio: btw, the bzr bd command there doesn't play nice with my --builder option in bazaar.conf23:08
elopiosergiusens: we initially copied bzr-buildpackage from the original script, but it didn't work for me.23:09
elopiosergiusens: can you try that?23:09
sergiusensBuilding 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 -us23:09
sergiusensUnknown option: u23:09
sergiusensI'm on trusty23:10
sergiusensoh, being called for dinner23: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
stgraberjdstrand: should be added to the unconfined profile too ^23:27
jdstrandI'll add it to the list23:28
* jdstrand heads out23:28
* rsalveti also heads out, dinner and football23:29
=== ManikTaneja is now known as manik_

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!