| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 06:24 |
|---|---|---|
| tasdomas | morning | 06:34 |
| tasdomas | if a service requires access to a device, does it need to be restarted after hw-assign? | 06:35 |
| tasdomas | or is there a more elegant solution? | 06:36 |
| tasdomas | I noticed that the webcam-demo basically runs an executable periodically to retrieve an image, so I guess it does not have that problem | 06:37 |
| fgimenez | good morning | 07:03 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mvo | Chipaca: hi, a quick question about the rest api, i remember in some versions the ubuntu-core snap was not displayed, there was a question about this and I wonder if I misremember and if not if its fixed ? | 07:55 |
| tasdomas | does a service need to be restarted after running hw-assign for its package? | 08:19 |
| mvo | tasdomas: yes, this needs to be done manually at this point iirc | 08:22 |
| tasdomas | mvo, I see - thanks | 08:22 |
| tasdomas | mvo, took me a while to figure out why the webcam-demo does not need this | 08:23 |
| mvo | tasdomas: sorry, bug #1484645 (https://bugs.launchpad.net/snappy/+bug/1484645) | 08:26 |
| ubottu | Launchpad bug 1484645 in Snappy "Snappy hw-assign doesn't restart affected services" [Medium,Triaged] | 08:26 |
| mvo | maybe we need to raise the priority of this one | 08:27 |
| mvo | or at least print some warning as a stop-gap | 08:27 |
| JamesTait | Good morning all; happy Wednesday, and happy World Maths Day! 😃 | 08:33 |
| Chipaca | mvo: core is always displayed in the rest api, afaik | 08:39 |
| Chipaca | mvo: i believe the question was about when it would be displayed in the CPI | 08:39 |
| mvo | Chipaca: ok, in this case the question needs more context | 08:39 |
| mvo | Chipaca: aha, sorry, then I misread it, you should be in the CC so feel free to correct that :) | 08:40 |
| === davidcalle_ is now known as davidcalle | ||
| Guest42341 | omg how do i end up on this channel??? | 08:47 |
| tasdomas | is the source for the snappy mqtt package available anywhere? | 08:58 |
| Chipaca | what do you call a thing that looks like a mutex, but whose lock/unlock methods take a string and it only locks things with the same string? | 10:21 |
| Chipaca | i'd call it a mutex tree, except it's not a tree, it's more like a bush :) | 10:22 |
| mvo | Chipaca: sounds like a MutexManager to me | 10:23 |
| mvo | Chipaca: if I don't know what its good for I call it a manager :P | 10:23 |
| Chipaca | noted :) | 10:24 |
| mvo | Chipaca: you could of course make it something like a factory, i.e. GiveMeMutex(string) and it either gives you a ref for a new one or a existing one | 10:24 |
| Chipaca | mvo: yes, but there's a two-level thing going on that i'd lose | 10:25 |
| Chipaca | um, maybe | 10:25 |
| Chipaca | hm | 10:25 |
| Chipaca | mvo: some operations mutate the state of everything, so they need to lock a "root" mutex, whereas most things just read or mutate things on a leaf, so they *rlock* the root mutex and lock/rlock the leaf mutex | 10:28 |
| Chipaca | mvo: i'll push it as is, you tell me if a name pops out at you :) | 10:29 |
| Chipaca | mvo: http://bazaar.launchpad.net/~chipaca/snappy/lock-ness/revision/771#daemon/mutex/mutex.go | 10:31 |
| beuno | jdstrand, ack | 11:46 |
| popey | dholbach: heya, do we have a simple snapcraft example which caters for the "I have a simple C / C++ program I want to build and package as a snap? | 11:54 |
| dholbach | popey, https://bazaar.launchpad.net/~snappy-dev/snapcraft/core/files/head:/examples/libpipeline/ | 11:55 |
| popey | ta! | 11:55 |
| dholbach | sergiusens, tedg: about the Snappy Clinic? | 11:57 |
| dholbach | what do you think? | 11:57 |
| dholbach | I mean on Friday | 11:57 |
| sergiusens | dholbach, didn't I reply for Monday? :-) | 11:58 |
| dholbach | oh? | 11:59 |
| dholbach | sergiusens, ok... shall we have a chat on Friday then to talk about a propoer script? | 12:00 |
| dholbach | tedg, ^ | 12:00 |
| sergiusens | dholbach, that sounds like a good plan | 12:00 |
| dholbach | awesome... which time? 14 UTC? | 12:00 |
| sergiusens | dholbach, 14 sounds good | 12:01 |
| dholbach | rock and roll - I'll pencil something into the calendar | 12:01 |
| sergiusens | dholbach, I might have a baby in arms potentially crying at that time, but for something private should be fine ;-) | 12:01 |
| dholbach | :-) | 12:02 |
| * dholbach hugs sergiusens | 12:02 | |
| ogra_ | must be the mate overdose if it cries :) | 12:02 |
| * sergiusens feels the hug and hugs back | 12:03 | |
| sergiusens | ogra_, probably, but from the mother ;) | 12:04 |
| ogra_ | haha | 12:04 |
| rickspencer3 | mvo, did I see "hw-assign" fixes in your snappy stable release announcement? ;) | 12:04 |
| mvo | rickspencer3: yes, the override bug should be fixed in r7 | 12:09 |
| rickspencer3 | mvo, is that the one that made me have to edit the apparmor profile? | 12:09 |
| mvo | rickspencer3: yes, I believe that this one is fixed | 12:11 |
| rickspencer3 | \o/ | 12:11 |
| * Chipaca -> lunch | 12:13 | |
| === chihchun is now known as chihchun_afk | ||
| dholbach | mvo, ogra: got much to discuss for the call today - if not, I guess we can skip it? | 12:27 |
| ogra_ | dholbach, nothing from me atm | 12:28 |
| dholbach | all right, let's skip it then | 12:28 |
| dholbach | from what I gathered mvo is going to be busy as well :) | 12:29 |
| ogra_ | nah, he just pretends to :P | 12:29 |
| * ogra_ upgrades to snapcraft 0.3 ... lets see if my snaps still build | 12:30 | |
| ogra_ | ogra@styx:~/Devel/branches/ircproxy$ snapcraft | 12:33 |
| ogra_ | DEPRECATED: Use "plugin" instead of "type" | 12:33 |
| ogra_ | Pulling ircproxy | 12:33 |
| ogra_ | ... | 12:33 |
| ogra_ | Staging ircproxy | 12:33 |
| ogra_ | Snapping ircproxy | 12:33 |
| ogra_ | Generated 'ircproxy_0.1_amd64.snap' snap | 12:33 |
| ogra_ | ogra@styx:~/Devel/branches/ircproxy$ | 12:33 |
| ogra_ | \o/ | 12:33 |
| * ogra_ changes "type" to "plugin" | 12:34 | |
| mvo | dholbach: skip | 12:34 |
| ogra_ | sergiusens, well done !! | 12:34 |
| sergiusens | ogra_, lol, at least that works :-P | 12:34 |
| === chihchun_afk is now known as chihchun | ||
| * sergiusens wonders where zyga is | 12:35 | |
| sergiusens | it is the perfect moment to switch to git | 12:35 |
| ogra_ | oh, is that better to do if zyga isnt around ? | 12:36 |
| * ogra_ didnt know | 12:36 | |
| sergiusens | lol | 12:36 |
| sergiusens | ogra_, he said he'd help with all the automation :-) | 12:36 |
| ogra_ | ah | 12:36 |
| tedg | dholbach: sergiusens: sounds good | 12:37 |
| dholbach | cool cool | 12:37 |
| dholbach | sergiusens, tedg: at which time on Monday do you think we should do the Clinic? | 12:38 |
| dholbach | shall we maybe announce it a bit in advance? | 12:38 |
| tedg | If we go too early, people have an opportunity to think up hard questions. | 12:38 |
| tedg | Need to keep them on the edge. | 12:38 |
| dholbach | I'm not sure if that should be a real concern. :-) | 12:39 |
| tedg | Heh | 12:39 |
| dholbach | we're going to get those hard questions soon enough anyway :) | 12:39 |
| tedg | So I'm not particular on time. I guess it'd depend on who we expect the audience to be. | 12:40 |
| tedg | 1400UTC is a bit early for the West Coast US. | 12:40 |
| dholbach | ok | 12:40 |
| tedg | But, not sure if we're looking to include those folks or not. | 12:40 |
| dholbach | the latest I could offer (if you want me in there as well) is 16 UTC | 12:41 |
| dholbach | that's EOD (or near-EOD) for most Europeans, but I guess we could do that | 12:42 |
| tedg | dholbach: I think you'd have a better feel for what works than me or sergiusens | 12:42 |
| tedg | You choose, we'll follow :-) | 12:43 |
| sergiusens | dholbach, 16 utc seems like a good compromise catch all | 12:44 |
| dholbach | ok, let's try it - if it doesn't work, we'll do something different | 12:44 |
| dholbach | I'll send out the announce Thu or Fri - that should be good enough | 12:44 |
| sergiusens | dholbach, we should bounce the times so eventually everyone can join | 12:44 |
| dholbach | nice one! let's talk about that on Friday too then | 12:45 |
| * ogra_ has lannding meeting on mondays at 16:00 UTC | 12:45 | |
| sergiusens | ogra_, you still go to those? | 12:45 |
| ogra_ | yes | 12:45 |
| sergiusens | ogra_, wow, why? :-P | 12:46 |
| ogra_ | to help out with image build issues etc | 12:46 |
| ogra_ | (and answer questions about plumbing which nobody else can answer anymore) | 12:47 |
| sergiusens | dholbach, btw, did you do your snapcraft dput magic? | 12:54 |
| dholbach | oh ok, no - will do | 12:54 |
| tedg | Did we ever add a logs command to snappy? | 12:57 |
| dholbach | sergiusens, https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text=snapcraft | 12:59 |
| dholbach | sitting in the queue for the release admins | 12:59 |
| ogra_ | hmm, what is "snappy man" and why does it spill formatting chars to my console ? | 13:00 |
| dholbach | fgimenez, elopio: do we know why http://autopkgtest.ubuntu.com/packages/s/snapcraft/ is failing? | 13:07 |
| dholbach | will 0.3 fix it? :) | 13:07 |
| sergiusens | ogra_, that is what olli wanted, the man page (troff) | 13:15 |
| olli | sergiusens, I never said man or troff | 13:16 |
| ogra_ | well, it would be nice if it was actually readable :) | 13:16 |
| olli | I want documentation to go to a website | 13:16 |
| olli | automatically | 13:16 |
| fgimenez | dholbach, according to this https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/s/snapcraft/20151005_190657@/log.gz there's a problem with the unit tests, let me check | 13:16 |
| ogra_ | the funniest is that i have "snappy man" but not "snappy help" :) | 13:17 |
| sergiusens | fgimenez, did we disable unit test running from debian/rules? | 13:17 |
| fgimenez | sergiusens, no idea, currently in trunk there's no override there for the tests | 13:19 |
| Chipaca | ogra_: it's because you didn't want to ship troff in core. See what you've done? | 13:20 |
| ogra_ | owww ... i didnt realize its my fault ... really sorry then | 13:20 |
| * ogra_ seeds man :P | 13:20 | |
| Chipaca | :-p | 13:21 |
| fgimenez | sergiusens, the failures are for 0.2.1 http://autopkgtest.ubuntu.com/packages/s/snapcraft/wily/amd64/ no override there either | 13:21 |
| ogra_ | we just need to tell people to then run: snappy man|man | 13:21 |
| Chipaca | |man -l - | 13:21 |
| ogra_ | yeah | 13:21 |
| sergiusens | fgimenez, you are talking about autopackage tests, I'm talking about the regular debuild | 13:23 |
| fgimenez | sergiusens, yes, in debian/rules there's only an override for dh_compress http://bazaar.launchpad.net/~snappy-dev/snapcraft/0.2/view/head:/debian/rules, the tests are not disabled there, but you are right, the errors in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/s/snapcraft/20151005_190657@/log.gz come from adt-run while executing runtests | 13:29 |
| sergiusens | fgimenez, dholbach so unit tests aren't running from package build, I fixed it and reproduced the error | 13:29 |
| sergiusens | fails during package build, works fine outside of it | 13:29 |
| plars | ogra_: I'm bulding rolling/edge images for rpi2 with something like: "core rolling --oem pi2.canonical --device raspi2_armhf --enable-ssh --developer-mode --channel edge" and they seem to stop working at ubuntu-core rev 9, but 8 worked. Any idea what changed between those two that might have broken things? | 13:31 |
| fgimenez | sergiusens, great, thx :) | 13:31 |
| plars | ogra_: similarly, on generic_armhf, 186 works but 187 does not | 13:33 |
| ogra_ | plars, rpi started using the new uboot setup between 8 and 9 | 13:34 |
| plars | ogra_: what's different about it? | 13:34 |
| ogra_ | http://system-image.ubuntu.com/ubuntu-core/rolling/edge/raspi2_armhf/version-8.json (device=0.16 ...) http://system-image.ubuntu.com/ubuntu-core/rolling/edge/raspi2_armhf/version-9.json (device=0.16-1 ...) | 13:34 |
| ogra_ | i have to look that up | 13:35 |
| ogra_ | oh, that was just the addition of linux-fiirmware i think | 13:35 |
| ogra_ | shouldnt affect booting | 13:35 |
| ogra_ | and it wouldnt affect amd64 indeed | 13:35 |
| plars | ogra_: it will very likely affect things for me - remember how I have to boot the test images from usb? | 13:36 |
| plars | ogra_: so I'll likely need to make similar changes to uboot that boots from the mmc on our rpi2 | 13:36 |
| ogra_ | well. i was wrong the uboot change was in 0.15 already | 13:36 |
| ogra_ | when we dropped all txt files | 13:36 |
| plars | ogra_: right, this problem is just affecting rpi2, nothing else | 13:36 |
| ogra_ | so between 8 and 9 there were only minor kernel adjustments | 13:36 |
| plars | I'm gussing 187 for generic_armhf got the same kernel adjustments? | 13:37 |
| plars | *guessing | 13:37 |
| ogra_ | no idea, i dont touch amd64 usually | 13:37 |
| plars | ogra_: I'm not saying amd64 | 13:37 |
| ogra_ | oh, generic_armhf, sorry, i misread | 13:38 |
| ogra_ | might be, i didnt look at BBB for a long time either | 13:38 |
| plars | :) | 13:38 |
| plars | something in those changes broke rpi2 for us | 13:38 |
| ogra_ | (last time for the uboot changes but they were far before that) | 13:38 |
| plars | ogra_: bbb works fine | 13:38 |
| plars | rpi2 is completely busted for the way we have to automate it though | 13:38 |
| ogra_ | well, both are identical on the uboot level | 13:39 |
| ogra_ | both dont use txt files anymore and require editing of uboot.env | 13:39 |
| plars | so either we need some other options for automating (unlikely unless they release a rev of the board with better hardware) or we need to figure out what changed and roll it back | 13:39 |
| ogra_ | and both use the same kernel ... with RPi having a set of extra HW patches on top | 13:39 |
| plars | ogra_: I don't expect bbb to break here, we don't have to do this trick to make bbb boot | 13:40 |
| plars | ogra_: bbb boots off the sd card, just as if you had flashed it, because we can boot a stable image off of emmc | 13:40 |
| ogra_ | http://people.canonical.com/~ogra/core-image-stats/20151002.changes thats the rootfs changes of 187 | 13:40 |
| plars | ogra_: rpi only has one place to boot from, so we have to resort to pushing the new image to usb - did anything with usb perhaps? | 13:40 |
| ogra_ | plars, yes, i know, i'm working on a netboot setup for the Pi as discussed with the CI team last week | 13:41 |
| ogra_ | hopefully ready on friday | 13:41 |
| plars | ogra_: oh? I didn't hear about this | 13:41 |
| plars | ogra_: they don't tell me anything anymore :) | 13:41 |
| ogra_ | you will still need the boot partition intact ... but it then should completely operate from ram and be able to dd a remote image from network | 13:41 |
| ogra_ | plars, blame ursual and celso :P | 13:42 |
| ogra_ | *ursula | 13:42 |
| Ursinha | me | 13:42 |
| ogra_ | plars, anyway, the 187 changes show a new systemd and udev | 13:42 |
| ogra_ | perhaps your issue is related to that | 13:42 |
| Ursinha | plars: we can't advertise features other people are working on :P | 13:42 |
| plars | ogra_: hah, I thought that changelog looked familiar | 13:44 |
| ogra_ | plars, so the idea is to have a script that itercepts the uboot boot via the serial port, then dumps a netboot config in place, pulls a remote kernel and initrd ... that initrd has dd and wget inside and writes that image to SD | 13:44 |
| plars | ogra_: it's the same point that bbb stopped getting ipv4 addresses on boot | 13:44 |
| plars | ogra_: I'm not sure that this is the same bug on rpi2 though, iirc when we looked at it with serial, it's just not getting past loading the kernel | 13:45 |
| ogra_ | yes, probably a systemd regression | 13:45 |
| ogra_ | i think pitti actually made some changes to networking that we perhaps need to adapt to | 13:45 |
| * ogra_ remembers seeing a mail | 13:45 | |
| plars | ogra_: where does it boot from though? the sd that it's about to dd over the top of? what happens if something goes wrong or if the new image that you dd is bad? | 13:46 |
| plars | ogra_: also, we've been down the path of trying to drive uboot automatically over serial before... it's bad | 13:46 |
| ogra_ | you are screwed if the boot partition is broken indeed | 13:46 |
| plars | ogra_: isn't that exactly what we're trying to avoid? | 13:46 |
| ogra_ | you cant avoid that | 13:46 |
| plars | :( | 13:46 |
| ogra_ | as you know already :) | 13:47 |
| ogra_ | i'm doing the best we can under the restrictions we have ... nothing more ... i cant magically swing my want and make an eMMC appear on the devic | 13:47 |
| ogra_ | e | 13:47 |
| ogra_ | *wand | 13:47 |
| plars | ogra_: yeah, I know... I think the way I already use is still better when it works though | 13:48 |
| ogra_ | plars, do cprov and Ursinha know your way ? | 13:48 |
| plars | ogra_: yes | 13:48 |
| * ogra_ wonders if it makes sense that he works on this then | 13:49 | |
| jdstrand | mvo: is there something like this http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/ for snappy? | 13:49 |
| jdstrand | mvo: and hello :) | 13:49 |
| ogra_ | plars, the requirement was to dd a full image to the SD | 13:49 |
| plars | ogra_: I think they have different needs, and can more easily tolerate needing to reflash the sd if things go bad though | 13:49 |
| ogra_ | i assume thats will be a very rare case anyway | 13:50 |
| Ursinha | plars: for us it'd be to reset the device to run new tests | 13:50 |
| plars | Ursinha: when ev talked to me about it, it sounds like you can handle needing to reflash a few by hand every day | 13:50 |
| plars | Ursinha: that's harder for me | 13:50 |
| plars | I need to be able to automatically reset it to a stable condition | 13:51 |
| ogra_ | you will only need to manually re-flash if the dd actually failed to write the first megabytes of the img... as long as the first partition ends up on the SD you should be fine | 13:51 |
| Ursinha | plars: that's sort what we need, but we need a specific stable condition :) | 13:51 |
| ogra_ | i wouldnt expect that to be "a few per day" ... rather a few per month if at all | 13:52 |
| plars | ogra_: I'd be willing to give it a try | 13:52 |
| ogra_ | i'll hand it to you once i'm done :) | 13:52 |
| ogra_ | jdstrand, indeed there is ;) the original of that stuff ... http://people.canonical.com/~ogra/core-image-stats/ | 13:54 |
| jdstrand | I was thinking you might've had it. thanks! | 13:55 |
| ogra_ | jdstrand, iirc lukasz uses my logs as input, i guess he can do the same for snappy too | 13:55 |
| ogra_ | in case you need more details | 13:55 |
| jdstrand | I don't, no | 13:56 |
| mvo | jdstrand: what ogra_ said, plus there is a script https://code.launchpad.net/~mvo/+junk/compare-channels that can be used to compare channels, e.g. "compare-channels.py ubuntu-core edge alpha". its slow though needs to download images | 14:03 |
| mvo | jdstrand: and hello to you as well :) | 14:03 |
| jdstrand | interesting, thanks :) | 14:03 |
| ogra_ | mvo, why do you need images to compare channels ? manifests should be enough | 14:16 |
| mvo | ogra_: patches welcome :P | 14:16 |
| ogra_ | well, just curious | 14:17 |
| ogra_ | do yoou actually unpack them and compare contents ? | 14:17 |
| mvo | I don't know, I did that a long while ago, maybe I could not find the right manifests? sorry, I really don't remember | 14:17 |
| ogra_ | fair enough | 14:19 |
| sergiusens | ogra_, mvo I bet it is because the channels don't have manifests, only cdimage has manifests | 14:35 |
| ogra_ | sergiusens, well, index.json has all info about which manifest to look for | 14:35 |
| ogra_ | which is what my script does | 14:35 |
| * ogra_ makes a note to actiually store the manifests under http://people.canonical.com/~ogra/core-image-stats/ so we have the history for them | 14:36 | |
| sergiusens | ogra_, ah, doesn't cdimage roll over though, faster than system image at least? | 14:36 |
| ogra_ | yeah | 14:36 |
| elopio | sergiusens: could you please upload teh licensed snap example to the store? | 14:36 |
| ogra_ | which is fine if you generate the changelog immediately after build | 14:36 |
| ogra_ | but doesnt work when trying to go backwards | 14:36 |
| sergiusens | ogra_, that is the reason ;-) when mvo did this it was reactive to figure out something that couldn't use the sources you use ;-) | 14:37 |
| ogra_ | i'll add some backup code to my script | 14:37 |
| ogra_ | so we have the manifests for older images too | 14:37 |
| === Guest77290 is now known as balloons | ||
| dholbach | sergiusens, snapcraft 0.3 is in wily :) | 14:41 |
| dholbach | https://launchpad.net/ubuntu/+source/snapcraft/ | 14:41 |
| sergiusens | dholbach, great, I already fixed that test thing, we can dilute it to 0.4 now I hope | 14:51 |
| dholbach | nice! | 14:51 |
| sergiusens | dholbach, thanks a bunch | 14:51 |
| dholbach | let's open 0.4 then ;-) | 14:51 |
| jdstrand | mvo: fyi, I reviewed snappy-debug. please see my response to the email thread | 14:55 |
| sergiusens | elopio, fgimenez Chipaca I need one QA and one Chipaca to look at this :-) https://code.launchpad.net/~sergiusens/snapcraft/1506096/+merge/274418 | 15:00 |
| Chipaca | chipaca levels are running rather low today | 15:00 |
| Chipaca | we'll see if we can scrounge one up for you | 15:00 |
| Chipaca | mvo: what's the state of https://code.launchpad.net/~mvo/snappy/snappy-snapfs-mount/+merge/273883 ? | 15:34 |
| mvo | Chipaca: no change yet, sorry. I need to address the comments and thing some more about your other alternative | 15:56 |
| Chipaca | no worries | 15:56 |
| mvo | Chipaca: I kind of like the property of rm -rf /apps/$name/$ver | 15:56 |
| mvo | Chipaca: I would like to preserve this, but maybe thats all mood with all-snap anyway because once something is mounted there the rm -rf will not work anymore anyway | 15:57 |
| sergiusens | mvo, btw, are we keeping SNAP_APP_DATA_PATH and others or are we going to be bind mounting that into /apps/$name/$ver/data ? | 15:57 |
| sergiusens | we can keep the var too ;-) | 15:57 |
| Chipaca | mvo: it's not strictly true anyway; there's a bunch of odds and ends in the system as well | 15:57 |
| Chipaca | mvo: like apparmor, seccomp, and systemd chunks | 15:58 |
| mvo | Chipaca: yeah | 15:58 |
| mvo | sergiusens: hm, once we mount the snap we could bind mount too indeed. I have no immediate plans for this though | 15:59 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| sergiusens | fgimenez, can you try real quick changing the port to 9999? | 16:05 |
| fgimenez | sergiusens, sure, give me a second | 16:05 |
| sergiusens | fgimenez, I don't know why it is going to a proxy since I added 'NO_PROXY' for 127.0.0.1 :-( | 16:06 |
| === chihchun is now known as chihchun_afk | ||
| fgimenez | sergiusens, it seems to work with lower case os.environ['no_proxy'] = '127.0.0.1' :) | 16:12 |
| === wesleyma` is now known as wesleymason | ||
| mhall119 | asac: ping | 19:27 |
| sergiusens | olli, ^ | 19:30 |
| olli | mhall119, wazzup | 19:49 |
| mhall119 | olli: Hi, earlier this year we printed some appdev flyers to give away at conferences, they highlight the developer portal and the scopes, apps and web sections, We have a space available to add something about Snappy and a link to it's section on the devportal, I just need someone to tell me what words to use | 19:52 |
| mhall119 | olli: see https://docs.google.com/document/d/1EQ3Dm-lMMxEY584_vX10ESBlxVxin8RgIHHpPCpgtns/edit towards the bottom I have a comment for this | 19:52 |
| mhall119 | I'd like to get snappy stuff added before asking for another batch to be printed | 19:53 |
| olli | mhall119, what's your timeline? | 19:58 |
| olli | I don't think I will get to this this week | 19:58 |
| mhall119 | olli: if we can get it early next week, I'm going ot try and have them printed in time for FOSSETCON next month | 20:03 |
| olli | mhall119, I added a reminder for Mo | 20:04 |
| mhall119 | thanks | 20:04 |
| === manik_ is now known as manik | ||
| manik | hey guys | 23:23 |
| manik | anyone around? | 23:23 |
| manik | how do i generate a device tarball for a particular platform? | 23:23 |
| tedg | I'm around, but I don't know how to do that :-) | 23:27 |
| manik | tedg: is there any way to tell where a device tarball came from in a given image? | 23:30 |
| manik | or what version it is? | 23:30 |
| manik | or really get any information about it? | 23:30 |
| manik | also, is there a way to access the contents of a .snap? | 23:33 |
| sergiusens | manik, your questions are rather broad | 23:35 |
| sergiusens | manik, there is no supported way to create a tarball | 23:35 |
| manik | sergiusens: thanks | 23:35 |
| manik | is there a way to see the snap contents? | 23:36 |
| sergiusens | manik, instructions on how to get started with one are here though https://developer.ubuntu.com/en/snappy/guides/porting/ | 23:36 |
| sergiusens | manik, but to have it supported is another story | 23:36 |
| sergiusens | manik, to list contents of a .snap that has not been installed just dpkg -c [file.snap] | 23:37 |
| sergiusens | subject to change with all snaps | 23:38 |
| manik | ok | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!