=== c74d is now known as Guest62930 [02:09] sergiusens: what is the current process to release a new webdm version? === c74d3 is now known as c74d [02:11] beuno: is the store fully back already? [04:59] ogra_: to avoid confusion, are you looking into fixing mountall to create a symlink instead of writing mtab? === c74d3 is now known as c74d [06:02] lool: re serial port support for grub - could we simply enable this why default? or is there a (security) risk here? [06:11] pitti: one issue I noticed while writing upgrade/failover tests is that systemd will drop me into a emergency shell sometimes. I would prefer it to log and reboot, can I simply provide my own "emergency.service" unit that will override the default one (sorry if thats a silly question)? [06:47] mvo: what would make serial different from a screen and keyboard in terms of security? If you have physical access to a system, security is toast. [06:47] * tbr was unhappy that he had to screw around with grub configs and uefi to get snappy working on real embedded intel hardware [06:48] tbr: I agreee but wanted to double check if there is something I might have missed [06:48] if there is no risk I'm much in favor of just enalbing it by default [06:49] mvo: yes, that should work fine; i. e. adding an /etc/systemd/system/emergency.service -> /lib/systemd/system/systemd-reboot.service ought to work [06:50] pitti: sweet, thanks [06:50] mvo: (warning, haven't tested -- but I see no reason why it shouldn't work) [06:50] thats fine, I will test, just wanted to double check if its a valid assumption or not [06:50] mvo: oh, for testing you probably want to put it into /run/, not /etc ? [06:51] mvo: or is that something which should be done in snappy in general, not just for testing? [06:51] pitti: in general [06:51] mvo: if so, it shoudl be done differently to avoid /etc/ [06:51] mvo: ah ok, then I misunderstood you [06:51] pitti: the idea is that it should auto-reboot if its in "try" mode at least so that it can fallback to the "good" partition [06:52] mvo: so then snappy.deb could ship a /lib/systemd/system/emergency.service.d/snappy.conf with something like [06:52] [Service] [06:52] pitti: aha, nice [06:52] ExecStartPre= [06:52] ExecStart= [06:52] ExecStart=/bin/systemctl --force reboot [06:52] Type=oneshot [06:53] mvo: i. e. rip out the parts from emergency.service which you don't want (reset the ExecStart* commands), and then call what you do want (from systemd-reboot.service) [06:53] mvo: that can be shipped in a deb, statically, without having to touch /etc/ [06:54] pitti: cool [06:54] pitti: I will do that then [06:54] mvo: foo.service.d/something.conf is like upstart's *.override files [06:54] (add it to the relevant bugreport for now and later to it to be precise :) [06:54] mvo: see man systemd.unit, grep for foo.service.d/ [06:54] thanks === erkules_ is now known as erkules [07:23] good morning [07:43] mvo: so I suspect the serial port name might differ (e.g. ttyS0 and ttyS1) and that people might want to disable that if they actually need the serial port for something else [07:44] mvo: it kind of feel like a deployment option to me: headless servers where you want to use an existing serial port, but some platforms wont have it; perhaps there's a smart way to detect it though, like "press space now to enable serial console" during grub startup? [08:01] morning [08:04] mo'in [08:26] dholbach, morning, just a heads up that the doc diff I was hoping for in my script is not possible, django cms is doing way too many annoying things when publishing. Well, it's possible of course, but at this point, that would just be a waste of time :) [08:29] ok... let's have a chat in a bit :) [08:40] Good morning all; happy Friday, and happy Learn About Composting Day! 😃 [08:54] mvo: you around? [08:56] Chipaca: yes [08:56] Chipaca: working on a fix for -lp1449032- [08:56] Chipaca: what can I do for you? [08:57] mvo: silly question: any reason why we're using “setActive/unsetActive” instead of “activate”/“deactivate” ? [08:57] Chipaca: none really, go for the new name [08:57] k [08:58] regen is basically unsetactive/setactive, hence why i'm in that code [08:58] it's painfully obvious i haven't looked into this bit of code before :) [08:58] heh :) is it that simple? thats very cool [08:59] Chipaca: meh, I hope its not too terrible :/ [08:59] that thing about us not parsing yaml twice? all lies as soon as we look at these [08:59] what's mroe [08:59] we parse the yaml inside (un)setActive [08:59] and then parse the click manifest [08:59] to get the package type [08:59] which is in the yaml [08:59] ohh [08:59] uff [08:59] we win some kind of award for that [08:59] not sure it's a good award :) [08:59] but at least we're consistent :) [09:00] * mvo hands Chipaca a broom stick and a janitor award [09:00] Chipaca: lol@consistent [09:00] Chipaca: well, time to kill that click compat stuff entirely, oh well [09:00] Chipaca: thanks a lot for going into these stables of augean [09:01] heh. 's not that bad :) [09:25] should i label "webdm front end stuff" as webdm or webdm client? [09:26] * beowulf thinks 'webdm' === fgimenez_ is now known as fgimenez [09:48] augh! bad branch [09:48] * Chipaca aborts it [10:03] mvo: Alas! Needs fixing. Inline. [10:06] hi, I'm following https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/, I installed the hello-world snap but when I execute it I get: [10:06] (BeagleBoneBlack)ubuntu@localhost:~$ hello-world.echo [10:06] mkdir: cannot create directory ‘/tmp/snaps/hello-world.sideload’: Permission denied [10:06] any ideas? [10:06] zyga: yes [10:06] zyga: there's a bug :) [10:07] zyga: or :-/ depending on your lookout [10:07] zyga: easy to workaround [10:07] Chipaca: thanks, what should I do? [10:07] zyga: sudo chmod 01777 /tmp/snaps [10:07] thanks [10:07] Chipaca: any chance for the update to the core snap? [10:08] zyga: and, if you want, edit snappyd in /apps/webdm/current/snappyd and add -m01777 to the mkdir [10:08] Chipaca: oh, I removed webdm [10:08] zyga: 15.04.1 is in progress [10:08] zyga: ah, ok :) [10:08] * zyga just rebooted [10:08] let's see how that works [10:08] zyga: then the error should go away on its own in a bit [10:09] heh, ok [10:09] zyga: let me know how it goes [10:09] zyga: there might be other bits still making that directory with the wrong permissions [10:09] zyga: in rolling the whole thing is avoided because you have private tmps [10:09] thanks [10:09] zyga: but that's still WIP a bit [10:10] while we're talking, how reliable is deb2snap in practice? I read the code so I kind of know how it works, I want to try taking a big/complex set of debian packages and making them available in a snap [10:10] zyga: thank you! and if anything seems wrong or inconvenient please do let us know [10:10] Chipaca: (works after reboot, so that's good) [10:10] zyga: I have not looked at at deb2snap, tbh [10:10] Chipaca: thanks, I'll let you know after I try :) [10:11] zyga: mterry is your guy for that, but he's not around right now [10:11] zyga: or vanvugt [10:12] zyga: (look at "top contributors" on https://launchpad.net/deb2snap ) [10:12] yep, I'll stay in touch [10:39] rsalveti, downloads yes, uploads are working but I need to check if they are autonatically scanned === Guest53 is now known as clurrrr === leandrosansilva_ is now known as leandrosansilva2 [12:11] beowulf: around? [12:12] beowulf: what am I to expect from https://code.launchpad.net/~stephen-stewart/webdm/repent-harlequin-said-the-ticktockman/+merge/260120 ? [12:12] sergiusens: magic [12:13] beowulf: because I don't see the description, download_size or installed_size anywhere [12:13] sergiusens, isnt that clear from the url ? [12:13] s/url/branch name/ [12:13] ogra_: yeah, but it doesn't do that ;-) [12:13] sergiusens: one sec, context switch [12:14] beowulf: ok [12:14] * sergiusens notices that at least a second has already pass [12:14] asac: ogra_: the problem is that services don't have something mkdir'ing /tmp/snaps for them, and so some of them do it themselves, and they don't all set the right permissions to then allow other apps to create subdirs of /tmp/snaps [12:14] sergiusens: so you are the ticktockman! [12:15] asac: ogra_: for webdm, it's fixed on trunk i think, but not released yet [12:15] asac: ogra_: snappy itself fixes it in a better way, again on trunk [12:15] Chipaca, yeah [12:15] Chipaca: was going to release yesterday, but hell came [12:15] releasing today would hide the issue for people using webdm at least [12:15] sergiusens: we call him "beuno" when he's in the room [12:16] * beuno lols but opts-in Chipaca into "experimental" features [12:16] * Chipaca hugs beuno [12:19] sergiusens: updated the mp, it gives snap icons a label if they aren't 'app' types and adds the download size to the descriptions [12:19] sergiusens: the next branch allows you to then sort by download size [12:21] beowulf: problem is, I don't see a description or any other text [12:21] sergiusens: do you mean on lp, or in webdm? [12:22] beowulf: there, browser was caching the css it seems [12:23] sergiusens: yeah, i will add some cache busting tokens to the js and css urls [12:23] beowulf: the ubuntu-core installed size is whack, maybe it should be hidden? [12:23] beowulf: for now at least [12:23] sergiusens: yeah, i can hide it or make it "n/a" or something (which i'd prefer to do for symmetry) [12:24] sergiusens: but i wanted you to see and fix it :) [12:24] beowulf: n/a is fine [12:24] sergiusens: i think if we're showing ubuntu-core as an installed snap it should have the same info (and it would be useful to see that, imo) [12:27] beowulf: I already said that I agreed! :-) [12:28] fix it fix it fix it [12:29] beowulf: also, in the column view I see the installed sizes but not the download_size, but what irks me is the column alignment or lack of ;-) [12:30] sergiusens: i think i fix that in the next branch [12:30] beowulf: ah, k [12:32] sergiusens: fwiw, i'm not using download size at all until i get some time to think a bit more about how the store should look and work [12:33] Hey sergiusens, what is your websocket vision for webdm? [12:33] morning [12:34] kyrofa: that is a broad question! [12:35] kyrofa: not sure if I want to do something restful over a websocket or use it as a complimentary data channel for the http/rest stuff [12:35] jdstrand, davidcalle just made lp:~ubuntudeveloperportal-editors/+junk/snappy-docs available which should help us keep the site up to date [12:35] kyrofa: I need to discuss with beowulf as well [12:35] mvo: more bad news :( [12:35] jdstrand, I'm looking at meta.md right now - it's where you said yesterday: [12:35] for example: 'security-template' should be a subpoint of 'caps' [12:36] dholbach: yeah, that was the one to forget :) [12:36] ok [12:36] I was being silling on security-template and caps [12:36] beowulf: it is in Details though [12:36] dholbach: but notice that services doesn't have subpoints [12:36] sergiusens: ah [12:36] beowulf: can I add one more critique, can the snappy package type be left aligned? [12:37] jdstrand, ok cool - looking [12:37] sergiusens, Haha, I can be less broad! We have a specific use-case I wanted to discuss [12:37] dholbach: same with binaries [12:37] jdstrand, and binaries as well [12:37] sergiusens: in grid style? [12:37] dholbach: I haven't reviewed all of it, but those two for sure [12:37] kyrofa: want to set something up for later today? [12:37] beowulf: in row style [12:38] Sure! What time works best? [12:38] kyrofa: 1:30 PM ART? [12:38] sergiusens: yes, the row isn't in good shape and i want to tidy it up, these mps are mostly about grid style though [12:38] jdstrand, dholbach, I'm trying to figure out why [12:38] ogra_: nice [12:39] sergiusens, sounds great! I'll make an invite [12:39] davidcalle: I thought I saw some django things mentioned in lp:snappy for the docs. does snappy/15.04 need similar changes? [12:39] kyrofa: sergiusens: webdm client would probably benefit more from server sent events that websockets [12:39] something about spacing the indents right [12:40] beowulf... how do you do that without something like websockets? [12:40] jdstrand, hmm... [12:40] * davidcalle is afk for a moment, brb [12:40] if that is needed, then I imagine everything in docs/* should be looked at in both snappy and snappy/15.04 [12:40] beowulf, do you maintain the web interface then? [12:41] jdstrand: that might have been me? django vrs githubmarkdown flavours? [12:41] Chipaca: heh, thanks! looks like its not my day today [12:41] kyrofa: i do yes, with sergiusens and others here [12:42] beowulf, want to be included in our HO? [12:42] kyrofa: yeah, add him if the time works [12:42] mvo: it isn't often i suggest more tests in an MP. I feel dirty. [12:42] beowulf: maybe? this is developer.ubuntu.com/snappy vs docs/* [12:43] jdstrand: yeah, i tried to fix some issues with list indentation which i think were caused by people using github markdown, whereas developer.u.c uses django which uses a different flavour [12:44] davidcalle: also another data point-- the services/binaries thing in meta.md on the website is the same sort of issue that security.md on the website had: subpoints weren't being indented correctly. you fixed the latter on your end iirc [12:44] ah [12:44] Chipaca: pretty please https://code.launchpad.net/~sergiusens/webdm/metaupdate/+merge/260579 [12:44] davidcalle: see what beowulf said ^ [12:44] we should probably document that and have a linter for docs/* [12:45] sergiusens: s/Ubuntu Core Snappy/Snappy Ubuntu Core/ I guess? [12:45] * sergiusens wants to kill readme.md and add a description entry in package.yaml [12:45] also, an end to the name/title/description nonsense [12:45] Chipaca: hmm, I think not, I conciously wrote it like that Ubuntu Core uses Snappy and this allow device management [12:46] sergiusens: +1'ed, then [12:46] Chipaca: thanks [12:46] kyrofa: not sure what your HO is about, but sure, why not :) [12:47] sergiusens: ma che grazie, go do some reviews yourself now :) [12:47] beowulf: websockets and the rest of the snappy vision [12:47] * sergiusens tries to find inspiration and write something up before then [12:48] beowulf, might be at the tail end of your day, so no pressure. [12:48] beowulf, I'm writing the Unity8 scope for installing/uninstalling/launching snaps [12:48] beowulf, like... the local version of the webdm web interface [12:49] davidcalle, looks like it works with the markdown command [12:49] kyrofa: have you looked at sse's? [12:50] davidcalle, at least for the type: app / oem / framework case [12:50] beowulf, no I didn't know someone else was working on this [12:51] kyrofa: i looked briefly a while back, websockets might be a bit overkill and are reportedly a pain to work with [12:53] beowulf, oh haha-- I thought you were saying someone named sse was making a unity8 scope, but you're talking about server-sent events... sorry [12:53] for webdm, it's mostly responding to events, what it sends to the server is occasional and regular xhr is fine for that [12:53] hi, i've built a snappy ubuntu image for the raspberry pi 2 with the image by lool and for some reason, it only shows 128 MB RAM available although there should be 1 GB - how can i adjust that? [12:53] beowulf, still early in the morning for me :P [12:53] kyrofa: haha [12:53] D_Cent, that seems to be an issue with the bootloader files used on that image ... [12:54] beowulf, I've not actually looked into SSEs. Let me read a little [12:54] kyrofa: so for install, you're mainly listening for progress or success events, but you only send one 'install' event [12:54] beowulf, see, this is good! You and I need to talk more often [12:54] kyrofa: try this too http://chimera.labs.oreilly.com/books/1230000000545/ch16.html#EVENTSOURCE_API [12:55] kyrofa: downside (for me, not you, i think) is sse's are not available on IE [12:55] ogra_: is there a quick way to fix it myself? [12:55] * beowulf breaks for lunch [12:55] beowulf, not to mention I'm interacting with the API from Go. DOM manipulation may not help us there [12:56] D_Cent, not that i know of ... there were suspicions that it works if you replace start.elf with one from an official RPi2 image [12:56] D_Cent, i'm tasked to look into that but wont manage to do so before monday i fear [12:57] sergiusens, I sent the invite-- did I get the time right? [12:57] ogra_: okay thank you :) then i'll check back on monday [13:00] kyrofa: yes, it could be 1h earlier if it help beowulf [13:01] beowulf, ah, but behind the scenes it just keeps the SSEs just keep the TCP socket open, huh? I can probably work with that [13:01] sergiusens, alright, I'll wait to hear what beowulf thinks after his lunch and modify if necessary [13:11] D_Cent: that's a known bug; ogra is looking into it; Paolo's image doesn't have this issue; we'll soon have this fixed [13:12] yeah, i'll merge paolos stuff in [13:22] jdstrand, beowulf, django isn't involved in the current issue, the cms only takes html and docs are converted locally before uploading [13:27] mvo: sergiusens: when regenerating systemd and binary wrappers and such, i should only look at frameworks and apps, not other types of packages, yes? [13:27] Chipaca: seems correct [13:28] do we have other types ? [13:28] (yet) [13:28] ogra_: gadget, os and kernel [13:28] ogra_: as part of yet, we have oem [13:28] ah, i thought they dont exist yet [13:28] ah, right [13:31] jdstrand, you were right, snappy trunk is fine, snappy 15.04 is not (https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md VS http://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/meta.md) [13:32] Indentation issue in 15.04 markdown [13:32] interesting [13:32] I just use the 'markdown' command to see if there are errors. clearly it is not enough [13:33] or at least in the way that I invoke it [13:33] * jdstrand notes he did not write meta.md, but imagines others are doing something similar) [13:33] davidcalle: i made those changes, fwiw [13:33] jdstrand, for the moment, are you aware of any changes between trunk and 15.04 for this file? [13:34] beowulf, the bad ones or good ones ? ;) [13:34] davidcalle: https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md is me [13:34] davidcalle: when I merged my 1 char MP yesterday, there was a conflict [13:35] beowulf, ok, thanks to you we have found the issue then [13:35] I can't comment on the rest of the doc (I don't really modify too often) [13:35] davidcalle: without the correct indentation the list wasn't appearing in the guides, which made it hard to understand [13:36] beowulf, indeed [13:36] davidcalle: i thought it was because the markdown in django needs 4 spaces not 2 [13:36] beowulf: is there a tool you use to make sure it will display well in django? [13:36] jdstrand: i don't know of one [13:37] * davidcalle replaces current guide with one from trunk, text is identical [13:38] kyrofa: sergiusens: if you could move the ho an hour forward I would be grateful :) [13:39] beowulf, done! [13:39] beowulf, by the way, looks like libs exist to polyfill SSEs into IE. I'm sure you're aware? [13:40] kyrofa: yeah, my first thought was if we had everything working in webdm with hr polling, we'd add sse support as a conditional [13:40] s/hr/xhr [13:40] don't want to poll hr [13:41] beowulf, hr may not give you what you're looking for [13:41] kyrofa: true [13:45] lool: thank you for letting me know! [13:46] kyrofa: have you seen the latest webdm, it has install/uninstall progress (more correctly, it's download progress in the install phase) [13:46] I think so, via polling yes? [13:46] kyrofa: yes [13:47] kyrofa: is polling not a option for a scope, or not a good option? [13:49] beowulf, sort of. It's a bit of a long-winded discussion, perhaps best saved for the HO :) [13:49] kyrofa: np [13:51] beowulf, thanks for coming, it'll be a good conversation! I'm looking forward to hearing another "client"s view [14:09] sergiusens: hey, i created a snap with no icon, sideloaded it, and the packages api has a value for the icon attribute (name + sideloaded + version) [14:09] sergiusens: this means that the browser shows a broken image, rather than, if it were empty, a default image [14:10] pitti: you around perchance? [14:10] sergiusens: i can look for a file extension in the client, but maybe this is something to fix in the api results? [14:10] hello Chipaca [14:10] pitti: hello hello! i've got systemd questions, i think [14:11] beowulf: I'll fix that, care to log a bug or task? [14:11] sergiusens: happy to, any preference? [14:11] beowulf: non at all [14:11] pitti: I'm wanting to have a thing (unit?) that runs on boot that regenerates the service unit files (for frameworks and apps) [14:12] sergiusens: bug it is [14:12] pitti: the code i have, with no extra work, will try to start the unit after creating the unit file [14:12] pitti: so I'm thinking that maybe there's a way to tell systemd not to try to start things itself, given i'll be doing so manually [14:13] sergiusens: https://bugs.launchpad.net/webdm/+bug/1460085 [14:13] Ubuntu bug 1460085 in webdm "snaps with no icon should not have a value for the icon attribute in the api" [Undecided,New] [14:13] Chipaca: "things" that synthesize unit files during boot from configuration are called "generators" [14:13] pitti: ok :) [14:13] pitti: i have generators! woo [14:13] * Chipaca feels all sophisticated now [14:13] Chipaca: see http://www.freedesktop.org/wiki/Software/systemd/Generators/ ; we have a few, look at some shell ones how they work: /lib/systemd/system-generators/openvpn-generator [14:13] Chipaca: or the one from postgresql-common [14:14] * Chipaca reads systemd.generator [14:14] Chipaca: essentially, they create units in /run/systemd/generator.. somewhere, which systemd will then pick up [14:14] Chipaca: they go well together with template units (but they don't necessarily have to use them) [14:14] hmmm [14:15] making snappy use these will take more work [14:15] Chipaca: yes, whether or not, or when/how to start units is entirely up to you [14:15] Chipaca: by default, a unit never gets started -- you have to make it a requires/wants of another unit; that's part of what the generator has to do [14:16] pitti: will systemd then keep it running if i manually start it? [14:16] Chipaca: sure [14:16] that is: [14:16] ping fgimenez: I've been playing with rewriting the tests in go, like http://paste.ubuntu.com/11433366/ [14:16] now I'm not sure if we should rewrite all of them, or leave them alone and work in tests with a controlled and deterministic environment. [14:16] like: instead of matching edge|stable, run the tests once for edge and once for stable. [14:16] Chipaca: it's nothing too magic -- it's just an unit which is in /run (thus doesn't survive a reboot), which happesn to be generated by a program called early at boot [14:16] what do you think? [14:17] pitti: ok [14:17] pitti: but i should leave the requires bits in place so if a user manually restarts a framework, apps will restart appropriately [14:18] Chipaca: ^ I don't understand what that has to do with generators? [14:19] pitti: I think I *don't* want generators [14:19] pitti: because if I use generators, unless i'm misunderstanding [14:19] Chipaca: restarting dependencies when you restart a unit is done with PartOf= [14:19] beuno: interesting: https://public.apps.ubuntu.com/download/com.ubuntu.snappy/docker/com.ubuntu.snappy.docker_1.5.0.002_all.snap - I thought all the old snaps were removed? [14:19] pitti: a daemon-reload regenerates them [14:19] Chipaca: correct [14:19] pitti: which would cause snappy to restart everything [14:19] beuno: https://public.apps.ubuntu.com/download/com.ubuntu.snappy/go-example-webserver/com.ubuntu.snappy.go-example-webserver_1.0.4_multi.snap too [14:19] Chipaca: err, no, why? [14:20] and then systemd will try to start them, and snappy will have started them [14:20] and everything will get in a fight [14:20] Chipaca: is snappy inotifying /run/systemd/generators/ or something such and restart stuff on file changes? [14:20] pitti: so, as I said perhaps too succinctly, i'd have to do more work to do this with generators [14:20] jdstrand, not removed, but filtered out because they don't have a release. I can remove them if needed [14:20] (that would be crazy -- don't do that!) [14:20] pitti: no! no, it's that [14:21] pitti: the generation of the unit files [14:21] pitti: is done by snappy [14:21] pitti: and the easy way to do them [14:21] pitti: is to just deactivate and then reactivate the snap [14:21] Chipaca: a generator should *never ever* start stuff by its own -- perhaps that's the confusion? [14:21] pitti: and that causes the services to be (re)started [14:21] pitti: i get that [14:21] beuno: I see. I don't think they have to be removed on my account (I am just fetching everything and can fix the script here), but it feels a little odd that they are in there [14:22] beuno: so, up to you :) [14:22] pitti: that's why i say, if i wanted to use generators i'd have to do more work [14:22] Chipaca: hm, the only "generated" unit files that I saw were in /etc/, i. e. the units which get build as a "transformation" of the yaml [14:22] elopio, i'd prefer to run the tests for each environment, with the state as controlled as possible and with concrete regex's [14:22] Chipaca: I still think we misunderstand each other in a major way [14:22] pitti: perhaps :) [14:22] pitti: let me start from the top [14:22] Chipaca: daemon-reload will not restart units [14:22] generators don't stop/start units [14:23] pitti: wait [14:23] pitti: let me start over [14:23] ack [14:23] pitti: snappy has this idea of "activating" and "deactivating" snaps [14:23] pitti: when it activates a snap, it creates a bunch of files, including the unit files [14:23] pitti: and then the services are started [14:24] pitti: this is done as part of an install, for example [14:24] ack; but that happens in /etc/systemd, right? [14:24] pitti: the old version is deactivated, the new version is activated [14:24] pitti: correct [14:24] pitti: that is as things are right now, and it works just fine [14:24] pitti: now [14:24] fgimenez: so, I propose to write one simple test that installs a package and confirms it works. 04_test_install_hello sounds like a good candidate for a controlled environment. [14:24] maybe we can have two versions, one that installs it from a snap we keep in our branch, and one that installs it from the store. [14:24] pitti: we're wanting to regenerate those unit files on boot (or on os update, which is essentially the same thing) [14:25] Chipaca: oh, that'd be a rather major difference design-wise [14:25] pitti: the *easiest* way to do that, is to grab a list of all "active" snaps [14:25] pitti: deactivate them [14:25] pitti: and then reactivate them [14:25] Chipaca: (I mentioned the possibility of building them at boot time in Austin, using a generator and /run -- that would avoid having to write into /etc/ entirely) [14:25] evereything would get generated, services started, all fine [14:25] Chipaca: but ok, let's follow along with the /etc/ approach for now [14:26] Chipaca: ok, understood [14:27] elopio, sounds great, the one that installs the local version could run in ci too, should we check for internet access at the first stages? [14:27] pitti: so, to make this work, i *think* all i've got to do is remove the bits that makes systemd start the services automatically [14:28] ogra_: hi, i'm trying to debug a nodejs snap, where does log output go? [14:28] pitti: is that right? [14:28] beowulf, nowhere by default ... you can hack the start script and put some env var in place [14:28] * ogra_ checks the var name [14:28] Chipaca: i. e. the "systemctl start" after you install a snap, generate the unit? :-) [14:28] Chipaca: sure; you can rewrite units in /etc/ all the time, that won't affect running ones [14:29] fgimenez: not sure how to handle that. For the experiments we did with the click store, we passed an environment variable, like: CLICK_STORE_URL=fake [14:29] it defaulted to being not set, which would use the real store. [14:29] pitti: no, i mean the requires or whatever it was in the unit files that causes them to be started on boot [14:29] Chipaca: if you want to do this rewriting at runtime [14:29] pitti: (because snappy would be starting them as part of the 'activate' dance) [14:29] fgimenez: maybe we can make it smarter. It will default to fake if there is no internet connection. But we should still be able to specify if we want to run the tests with or without the real store. [14:29] pitti: what does "at runtime" mean? [14:30] pitti: just to be clear :) [14:30] Chipaca: right; as I said, unit changes will only become active at boot in general; you can "force" the stopping/starting of new/old units with "systemd default", but that's a rare (and not widely known) operation [14:30] Chipaca: well, not at early boot time or image build time; i. e. "while the system is running" [14:31] pitti: not early boot; this would be a snappy command run from an ad-hoc systemd .. unit? target?, once "everything else" is up (ie, i want it to run more or less where ubuntu-snappy.frameworks-pre.target is today) [14:31] beowulf, i think it is just DEBUG=* ... or alternatively call node with the --debug option ... then logging should go to syslog [14:32] fgimenez: actually, we can start even more simple. We need a test to check that a snap can be installed from the .snap file. Lets write that, package it, put it to run on CI. And then we figure out how to solve the one from the store. [14:32] Chipaca: terminology: everything is a "unit", a target (or a service) is a particular type of unit [14:32] Chipaca: right [14:32] pitti: services stick around, targets come and go? [14:32] Chipaca: so if I got your question right: systemd by itself will not stop/start stuff automatically when you change unit files on disk; you have to manually do that [14:32] ogra_: thanks, will try [14:33] pitti: but nothing breaks if i create unit files from a unit file [14:33] backjlack, ah, found it ... NODE_DEBUG=* [14:33] Chipaca: no; services start processes, targets are a kind of "meta-service" to provide synchronization points for services or group related services; but a target doesn't start processes by itself [14:33] http://www.juliengilli.com/2013/05/26/Using-Node.js-NODE_DEBUG-for-fun-and-profit/ [14:33] fgimenez: do you know about debian packaging for go? [14:33] Chipaca: in sysvinit terms: service == init.d script, target == runlevel [14:33] elopio, ok [14:33] pitti: gotcha [14:34] Chipaca: right; dynamically createing unit files from an unit file is unusual and brittle, but as long as you only expect them to become active at the next boot, it's all fine [14:34] Chipaca: brittle in the sense of "it might not do what you think it does" [14:35] i'll need to test it then :) [14:35] elopio, not used it before, i've seen that dh-golang manages it [14:35]