[07:07] good morning [07:31] good morning === ezobn1 is now known as ezobn === Chipaca` is now known as Chipaca [08:16] * ogra_ tickles seb128 [08:16] seems someone found my G+ post about personal ... [08:16] https://lists.ubuntu.com/archives/snappy-devel/2015-September/001033.html [08:16] https://lists.ubuntu.com/archives/snappy-devel/2015-September/001036.html [08:17] seb128, i assume nobody is interested in getting bugs yet for this ? [08:17] hey ogra_ [08:17] not that I know of, no [08:31] Good morning all; happy Monday, and happy Eat a Hoagie Day! 😃 [08:39] Good morning [08:46] JamesTait: what's a hoagie? [08:46] Chipaca: I reviewed your branches, I guess next step is to get them onto the 15.04 image or is something pending from your side [08:47] Chipaca, https://en.wikipedia.org/wiki/Submarine_sandwich#Hoagie [08:48] mvo: we need to decide what to do about activation in 15.04 [08:48] * Chipaca hugs JamesTait for not sending him to lmgtfy [08:49] mvo: also maybe we don't need to backport to 15.04 if we don't want to ship these there and instead ship trunk to 15.04? [08:49] Chipaca, nah, enough people have asked that I realise not everyone watches Man vs Food. 😉 [08:49] mvo: next step for _me_ is thinking a little bit about services, and implementing the fruit of my thinkage [08:50] JamesTait: that looks like a sandwich you can't eat politely :) [08:51] Oh, definitely. [08:51] Chipaca: re trunk> https://bugs.launchpad.net/snappy/+bug/1493706 worried me a bit about that (I still think its a good idea in general, but this worried me about regressions) [08:51] Launchpad bug 1493706 in Snappy "side-loading frameworks broken" [Critical,Triaged] [08:51] Chipaca: activation? what has changed here (pardon my ignorance) [08:52] mvo: oh, maybe you didn't notice? the coreos activation doesn't build on 15.04 [08:52] mvo: it uses os.Unsetenv, which wasn't it go 1.3 [08:52] Chipaca: oh, this activation, sorry, was confused [08:52] mvo: stgraber's activation patch/fork fixes that [08:52] mvo: so we need to decide whether to ship his fork, or his patch :) [08:52] or whether we give up and vendor [08:53] yeah, let me deal with that then [08:53] mvo: and that's one we need to fix independently of backporting or not [08:53] yep [08:54] mvo, the snappy config output if you just call it vs if you change a value look very different now ... if you chnage a value it prints all of the ppp values afterwards, if you just call the config command without setting anything the ppp values are omitted [08:55] setting a value: http://paste.ubuntu.com/12395367/ vs calling snappy config http://paste.ubuntu.com/12395393/ [08:55] ogra_: hm, that looks like a bug :/ [08:55] mvo: you need to stop apologizing to me for the state of the codebase, already; i've been here long enough :) [08:57] mvo, note i also seeded libnss-myhostname on the weekend for bug 1495058 and bug 1464396 [08:57] Chipaca: sorry [08:57] bug 1495058 in Snappy "updating the hostname via snappy config does not update /etc/hosts" [Undecided,New] https://launchpad.net/bugs/1495058 [08:57] Chipaca: :P [08:57] bug 1464396 in Snappy ""sudo: unable to resolve host ..." when custom hostname is used." [Critical,Triaged] https://launchpad.net/bugs/1464396 [08:57] Chipaca: ok, I will try to stop [08:57] mvo: :D [08:57] (just as a FYI) [08:57] Chipaca: do you have a link to the build failure btw? [08:58] Chipaca: because the version of golang-systemd in the archive does not use os.Unsetenv so I'm a bit puzzled [08:58] mvo: https://code.launchpad.net/~chipaca/snappy/serve/+merge/270372 [08:58] ta [08:58] Chipaca: heh, its just our CI that is confused [09:07] Chipaca: I commented in the MP === Chipaca is now known as Chipakeitor === Chipakeitor is now known as __chip__ === __chip__ is now known as Chipaca [09:13] mvo: so with that change to dependencies it'll be happy again? [09:13] ogra_: hm, I just upgraded to ubuntu-core 147 and I do see the ppp config stuff, anything unusual aobut your image? [09:13] Chipaca: I think so, I tested locally and it looked happy [09:14] (ie. checked out the right revno and there was no os.Unsetenv() anywhere) [09:14] mvo: your diff failed here, though [09:14] :( [09:14] I will redo it with a proper branch instead of a inline diff [09:14] it needs tabs [09:14] not sure why [09:14] ah [09:14] maybe LP ate them [09:15] mvo: nah, i can patch by hand [09:16] let's see if this works now :) [09:16] mvo, nope, nothing unusual [09:17] that was a plain install of 145 and i saw/see the same on 146 and 147 [09:18] ogra_: ok, I will try harder to reproduce [09:19] hmm, the machine doesnt boot anymore after auto upgrade :/ [09:19] and indeed i have no serial board for that HW :/ [09:20] well, or it doesnt bring up the static network setup [09:43] serve landed \o/ [09:43] \o/ [09:44] sergiusens: mo'in! [09:44] Chipaca, serve me a beer [09:44] :-P [09:44] Chipaca, good morning [09:44] $ GET http://localhost:8080//1.0/packages/beer [09:44] {"metadata":null,"status":"Not Found","status_code":404,"type":"error"} [09:45] Chipaca, bummer :-) [09:45] sergiusens: easy enough to fix though [09:54] Chipaca, yeah, extend and serve myself :-P [10:06] hmm, so after autopilot upgrade it seems my static network doesnt come up anymore [10:08] mvo, does snappy config apply the /etc/network/interfaces.d file on every boot ? [10:09] Sep 14 09:18:00 aleph2 systemd[1]: ifup-wait-all-auto.service start operation timed out. Terminating. [10:09] Sep 14 09:18:00 aleph2 systemd[1]: Failed to start Wait for all "auto" /etc/network/interfaces to be up for network-online.target. [10:09] Sep 14 09:18:00 aleph2 systemd[1]: Unit ifup-wait-all-auto.service entered failed state. [10:09] * ogra_ sees that in syslog of the failed machine [10:10] oha ! [10:10] Sep 14 09:16:01 aleph2 kernel: [ 43.590490] r8169 0000:01:00.0 eth3: renamed from eth0 [10:10] thats bad [10:14] ogra_: what happened to stable network interface names? [10:14] shouldn't that be ens3 or sth [10:14] 15.04 [10:14] should it there ? [10:14] I don't know [10:14] my brain no longer supports 15.04 [10:14] * ogra_ is running 15.04 edge here [10:14] :) [10:15] it should definitely never rename it [10:15] no matter oif the name is foople0 or eth0 :) [10:17] wow and in /writable/system-data/etc/udev/rules.d i have the persistent-net.rules file with two different entries for the same MAC [10:18] thats gross [10:26] mvo, bug 1495452 [10:26] bug 1495452 in Snappy "auto upgrade unintentionally updates /etc/udev/rules.d/70-persistent-net.rules" [Undecided,New] https://launchpad.net/bugs/1495452 [10:27] pitti, is there a way to prevent this ? ^^^ [10:28] (why would it add a device at all if there is a MAC existing for it in that file already) [10:28] ogra_: that sounds like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765577 [10:28] Debian bug 765577 in udev-udeb "netboot install writes duplicates to 70-persistent-net.rules" [Serious,Fixed] [10:29] ogra_: is that vivid? [10:29] pitti, yeah, the 15.04 edge image that we want to release this week [10:29] (as the entire 70-persistent generator is completely gone from wily) [10:30] not sure we could drop the generator since 15.04 still seems to use the old way of naming devices [10:31] ogra_: could you clean up the file, apply http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/diff/?id=f9cb380a, and see if that helps: [10:31] ? [10:31] if so, we can SRU that [10:31] ok [10:31] Chipaca, mvo can I get an ack on https://code.launchpad.net/~sergiusens/snapcraft/collisions/+merge/270942 ? [10:31] well, i'm not really sure how to trigger it again now :( [10:32] to verify it wouldnt do that again [10:33] removing the line manually brings it up normally again ... it doesnt add it anew [10:33] ogra_: nevermind, vivid already does have that thing [10:33] well, then it doesnt help obviously :) [10:34] (teh immage build is actually from yesterday so everything in -security and -updates should be in it [10:34] ogra_: but what's weird is that the file header exists multiple times too [10:34] ) [10:34] it's actually not wrong -- there are three MACs with different names, and the rules are just duplicate, not contradicting AFAICS [10:35] oh, :f8 is eth0 and eth3 [10:35] well, except that the second entry for eth0 is named eth3 [10:35] right :) [10:36] and i also got: Sep 14 09:16:01 aleph2 kernel: [ 43.590490] r8169 0000:01:00.0 eth3: renamed from eth0 [10:36] on the first boot after the auto-upgrade [10:37] sergiusens: I have a look now [10:37] mvo, thank you very much [10:38] ……………………[ -e "$RULES_FILE" -o -e "$tmp_rules_file" ] || PRINT_HEADER=1 [10:38] ogra_: ^ hm, it shouldn't print the header again if the file already exists [10:38] ogra_: could it be that /etc/udev/rules.d/ (or the actual file) is a bind mounted dir/file, which isn't bound in initramfs already? [10:39] i. e. the generator would race with bind-mounting the file? [10:39] pitti, yeah, could be, i have to check the inird script [10:42] pitti, but would the generator run from initrd ? [10:43] the bind mount is definitely done via fstab processing [10:44] ogra_: AFAICS 70-persistent-net.rules gets copied into initramfs, but not the 75-persistent-net-generator.rules -- that shold only happen in the "real" fs [10:45] right and we cant generate the initrd on the device so the file should be either empty or not exist at all [10:45] ogra_: "lsinitramfs -l /initrd.img |grep net-gen" to double-check? [10:45] right [10:45] but if you fstab-mount it, you have a race [10:45] GEEZ ! [10:45] where does lsinitramfs come from and why dont i know about it !!! [10:47] gzip: /boot/initrd.img-3.19.0-28-generic: not in gzip forma [10:47] t [10:47] bah [10:49] (amd64)ogra@aleph2:~$ lzcat /boot/initrd.img-3.19.0-28-generic |cpio --extract --quiet --list|grep net-gen [10:49] (amd64)ogra@aleph2:~$ [10:49] nope, not there [10:50] and the 70-persistent-net.rules file would also just vanish after the bind mount anyway [10:50] it wouldnt be mangled [10:52] pitti, this is clearly triggered only by an upgrade of the readonyl image part ... so i wonder if anything in there triggers it [10:53] * ogra_ tries a snappy rollback and snappy update loop again ... [10:55] rollback comes up fine again [10:56] * ogra_ updates and reboots again [10:58] upgraded fine, didnt change the rules file [10:59] * ogra_ rolls back again and waits tile the autopilot kicks off the upgrade ... probably that causes a race [10:59] ogra_: the ppp issue you see is on arm? or in a vm? [10:59] mvo, on x86 hardware [10:59] sergiusens: the config branch as well? [10:59] ogra_: real hw? interessting, I poke some more [10:59] mvo, config branch is not done yet :-) the previous ones if you want you can review :-) [11:00] mvo, OOOH ! [11:00] mvo, I ran into collision problems when working on config (more complex and multiple parts al including ubuntu packages) [11:00] mvo, sudo vs no sudo makes the difference [11:00] ogra_: oh, of course :/ [11:02] (amd64)ogra@aleph2:~$ snappy config ubuntu-core |grep timezone [11:02] timezone: Europe/Berlin [11:02] (amd64)ogra@aleph2:~$ date [11:02] Mon Sep 14 11:01:59 UTC 2015 [11:02] ogra_, for snappy config? I thought we had 'am I root' detection there [11:02] bah, that doesnt look right either [11:02] sergiusens: yeah, I started but then got distracted [11:03] mvo ogra_, we also need input hand holding in our config for ubuntu-core [11:03] specially with ogra who typos a lot ;-) [11:03] haha [11:03] well, for configuring i used http://paste.ubuntu.com/12396598/ for this particular install [11:04] if you see any typos, please tell me :) [11:05] that the timezone doesnt get set is worrying :/ [11:08] ogra_, I don't see anything wrong, maybe check if /usr/share/zoneinfo/Europe/Berlin exists on the system? [11:08] ogra_, it works fine for me for America/Cordoba [11:08] it exists [11:09] and /etc/writable/timezone is also set correctly [11:09] sergiusens, is that on 15.04 ? [11:09] (where America/Cordoba works) [11:10] ah, now autopilot rebooted it ... /me waits if the interface gets renamed this time [11:11] bah, came up fine [11:12] ogra_, seems it doesn't work anymore http://paste.ubuntu.com/12407670/ [11:12] yeah, bad [11:13] but i wonder why ... the files are all correct [11:13] ogra_, /etc/timezone has the correct data [11:13] right, here as well [11:13] ogra_, did we drop some dependency? [11:13] ogra_, I can be blind and just blame systemd :-P [11:13] not that i'm aware of [11:14] aha [11:14] /etc/localtime points to UTC [11:15] something didnt update it along [11:15] due to the snappy config changes ? [11:15] ogra_, no, this is older [11:15] ogra_, snappy config only ever updated /etc/timezone [11:17] and that worked ? [11:17] ogra_, yeah [11:17] (just asking because the hostname update only worked half) [11:18] ogra_, hostname update has a bug logged somewhere; want to fix? shouldn't be complicated ;-) [11:18] sergiusens, fixed it on the weekend :) [11:18] * sergiusens finds ogra_ fixes things fast to scratch his itches ;-) [11:19] hey guys [11:19] so lets see what happens if i properly update /etc/localtime [11:20] (amd64)ogra@aleph2:~$ sudo cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime [11:20] [sudo] password for ogra: [11:20] (amd64)ogra@aleph2:~$ date [11:20] Mon Sep 14 13:20:06 CEST 2015 [11:20] sergiusens, i cant really belive that ever worked correctly ... (i rather guess nobody wimply noticed) [11:20] *simply [11:21] these files always need to be updated alongside [11:24] mvo, do you know if meta/hooks/config can be a symlink? [11:28] sergiusens, bug 1495474 [11:28] bug 1495474 in Snappy "setting the timezone via snappy config does not actually update the time zone" [Undecided,New] https://launchpad.net/bugs/1495474 [11:31] sergiusens: I think it can and its probably a good idea too, if it does not work there might be a bug [11:32] mvo, great, because I'm working on having snapcraft just symlink ;-) [11:33] pitti, ouch ... [11:33] (amd64)ogra@aleph2:~$ mount|grep -c etc [11:33] 18 [11:33] pitti, dont you think we could simply make the generator run later ... mounting everyting of /etc in initrd sounds wrong [12:09] ppisati, hey, sorry, I lost track, when do you think I'll be able to use pwm on my rpi2? [12:11] rickspencer3: latest kernel has it working (both 3.19 and 4.2) [12:11] rickspencer3: if you are willing to do some manual hacking, you can test it right now [12:11] ppisati, can I just install rolling? [12:11] ppisati, actually, let me ask differently ... [12:12] could you send detailed instructions to the snappy mailing list on how to test it? [12:12] rickspencer3: ok, i'll do [12:13] thanks ppisati [12:13] I'm looking forward [12:21] ogra_: well, you'll just keep running into races like this [12:22] pitti, hmm, yeah :( [12:22] this is like the 10th time this issue bubbles up [12:23] ogra_: you could restart udev once again after mounting everything, but you'd need to do "start udev", "stop udev", "mount everything in /etc", "restart udev" [12:23] well, i guess that needs some discussion first ... i can add a function that parses out all the /etc dirs and mounts them indeed [12:23] do we actually restart it at all ? i thought we carry the running daemon binary over from the initrd [12:24] no, we restart it [12:24] rickspencer3, you will need a device tarball ... i'll roll one durign the week anyway for the 15.04.3 image that is planned this week [12:24] otherwise we'd keep the initramfs-tools' libc6 (and all libs) in RAM [12:24] also, the i-t udev has only a minimal set of rules [12:24] rickspencer3, we dont have automated builds for RPi yet, so there is no specific tarball for the rolling images [12:25] ogra_, ok, noted [12:25] I think if ppisati emails directions to the list, that is the best way forward [12:25] pitti, yeah, i always thought we onyl re-process the rules and keep the daemon running ... but indeed that would keep libc and friends in ram too [12:25] I have all these servos and motors and rgb leds that are hungry for some pwm [12:25] rickspencer3, not if he doesnt use the exact same setup the device tarball will use [12:26] ogra_, um, then he should do that? [12:26] I don't mind updating the image later if necessary [12:26] I would just like to be unblocked [12:26] well, why not just wait a day til i get to it and can offer the ready made tarball for testing [12:27] ogra_, if that's what ppisati's directions say to do, that is fine with me [12:27] * ogra_ is just currently busy with x86 since we have to have a specific release ready for this for 15.04.3 [12:28] (and i run into bugs over and over with nearly everything atm :/ ) [12:30] ogra_: rickspencer3 well, my directions would be how to manually install a kernel, update the dtb, etc [12:30] that's how i test new kernels [12:32] just cp'ing over the binary ? [12:32] yeah, that would work for testing indeed [12:33] ogra_: yep, literally [12:33] and the dtb too [12:33] and the modification to config.txt [12:33] i'm writing it now [12:34] cool, yeah, thats good [12:57] sergiusens: hey, there's no schema support for per-part properties [12:57] sergiusens: would you like a patch for that? [12:57] sergiusens: so that a given part type can be validated [12:57] zyga, the only reason that isn't there is because there is an alternate thing in place for that (which I want to get rid of) plugins/*.yaml [12:58] sergiusens: hmm? [12:58] sergiusens: do you want to remove all the plugin/part types? [12:58] it uses a custom rule engine to support plugins/extensions [12:58] zyga, no, I don't want to get rid of that [12:58] sergiusens: ah, sorry, I misunderstood [12:58] sergiusens: where is that thing then? [12:58] sergiusens: in other words, when adding a new plugin type, where do I patch the schema? [12:58] zyga, in the path I just gave you ;-) [12:59] zyga, it's separate [12:59] ah, that was a path, /me looks [12:59] hmm I don't see plugins/extensions [13:02] sergiusens: did you paste anything I've missed? [13:03] zyga, http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/files/head:/plugins/ [13:04] sergiusens: right but that's not a json schema [13:04] sergiusens: (I know about this part) [13:04] sergiusens: if that's all then it's fine, I'm just looking around to see what to patch [13:05] zyga, how would you support a 3rd party type with the schema? [13:05] sergiusens: well, you can put all of that in the master schema [13:05] sergiusens: assuming all plugins are in trunk [13:05] sergiusens: and none are installed from a 3rd party add-on [13:05] sergiusens: with add-ons you'd have to use some more nifty features but I think it's also possible [13:05] zyga, none that you know of ;-) [13:05] sergiusens: (I wrote json-schema-validator, which we're not using) [13:06] sergiusens: my json schema is rusty but not that rusty :) [13:06] sergiusens: so with all of them in trunk you can use specific property schemas [13:06] and conditional parts [13:06] zyga, right, we'd have to hack in local references; AFAIK, jsonschema only supports http [13:06] sergiusens: it's all doable with pure json schema [13:06] sergiusens: no, I don't think you need that [13:06] sergiusens: what I was thinking of is.... [13:08] sergiusens: https://github.com/zyga/json-schema-validator/blob/master/json_schema_validator/tests/test_validator.py#L733 [13:08] sergiusens: something like this [13:08] sergiusens: you can validate per-plugin type [13:08] sergiusens: using requires you can look at the outer object [13:08] sergiusens: this is a random code example, the key idea is requires [13:09] sergiusens: https://github.com/zyga/json-schema-validator/blob/master/schema-spec/draft-zyp-json-schema-03.txt#L564 [13:09] using the 03 draft wording [13:09] zyga, I know about requires [13:09] sergiusens: anyway, this is just an optional thing [13:09] zyga, but this would only work for 'built' in plugins [13:09] sergiusens: yes [13:10] sergiusens: if the design requires 3rd party plugins then it won't work this wy [13:10] way* [13:10] (without a way to let each plugin ship any object) [13:10] zyga, exactly, it supports 3rd party plugs [13:10] sergiusens: and having a custom sub-schema for it [13:10] sergiusens: ah, I see, thanks [13:10] zyga, so we'd need schema snippets and load the references befor sending t to the validator [13:11] sergiusens: you could just validate the generic schema and then sub-validate each plugin specifically [13:11] zyga, sure, if you want to extend the schema, go ahead, I don't mind, right now all parts are part of a pattern properties [13:13] Hey zyga, can we talk about pip and checkbox? [13:13] zyga: It seems that checkbox is using multiple requirements files? [13:14] tedg: yes, we sure can [13:14] tedg: checkbox is not using requirements files the way you think [13:14] zyga: I couldn't see a way they got consolidated. [13:14] tedg: everything important is specified by setup.py meta-data [13:14] Oh, okay. [13:14] * tedg stops thinking [13:14] tedg: if you get plainbox to work then checkbox is easier :) [13:14] pitti, oh ... [13:15] zyga: So how do I know the requirements? [13:15] tedg: if I can give you a bit of advice on requirement files: follow what travis-ci allows [13:15] tedg: it's spelled in setup.py [13:15] tedg: install_requires [13:15] tedg: the standard way [13:15] pitti, i just noticed that i didnt remove "allow-hotplug eth0" from my /e/n/i setup, could that confuse the generator ? [13:15] tedg: if you do what travis-ci allows then any python project will be snappy buildable [13:15] (does it check for that in any way ?) [13:15] tedg: most projects just setup.py develop / install their deps [13:15] ogra_: no, it doesn't look at that at all [13:16] ok [13:16] zyga: I find "the standard way" doesn't really exist anywhere :-) [13:16] tedg: and using wheels is the current hotness to make that easier to do [13:16] tedg: I disagree [13:16] tedg: setuptools is the way [13:16] tedg: requirements are for separate concerns [13:16] tedg: like deployment or other weird web scenarios [13:17] tedg: if you setup.py install is broken then users complain (if they care) [13:17] tedg: but it's definitely the standard way [13:18] zyga: Travis CI just allows you to run binaries. We're not interesting in providing a bunch of scripts... [13:18] zyga: http://docs.travis-ci.com/user/languages/python/ [13:18] tedg: yes but it supports certain things for free out of the box: like using setuptools without asking [13:19] zyga: So like what we do with the python3-project plugin? [13:19] tedg: yes, except right now that implementation is broken [13:20] tedg: (for the same reasons I said earlier) [13:20] zyga: So I think there's a patch for that, we just need to work out the details. [13:20] zyga: But, to be clear, you don't want or use a requirements.txt file. [13:21] tedg, if we accept the fix from BjornT I think zyga's problem would be a non issue [13:21] tedg: it'd be nice if we support it if people want to use it (for version pinning) [13:21] tedg: but it should be optional IMHO [13:21] sergiusens: I think so too, but I haven't pinged you about your brainstorming weekend yet :-) [13:21] tedg, hasn't happened :-/ [13:21] sergiusens: Start your weekend now! ;-) [13:22] tedg, good idea [13:22] sergiusens: btw, I failed with my .run() cleanup, it's utterly hard to clean up run to be space free and run without shell [13:22] sergiusens: I will rescue a few patches from that but the whole patchset has failed (too many changes, tests change, etc) [13:23] sergiusens: So let's take BjornT's patch for now and then we'll fix it later. I think it's more important to provide features today than provide smaller snaps. [13:23] Hate taking on technical debt, but adoption is more important. [13:23] tedg, certainly [13:24] how else would the duct tape producing industry survive ? [13:25] So then elopio if you could look at my pip branch and tell me how to format the long lines in python compatible way I think it's ready too. [13:25] ogra_: I believe there is a pact between the WD-40 industry and the duct tape industry. An evil, evil pact. [13:27] elopio, sergiusens: I put pip tests in the integration suite. Is that where we want them? They take longer because they download stuff. [13:27] tedg, lol [13:29] tedg: can I review it it as well? [13:29] zyga: sure! [13:30] tedg: ok, I'll check it out now [13:30] * zyga cries for clean, logical commits :| [13:33] tedg: there's no chance to squash those commits into separate changes? [13:34] zyga: Eh, plastic surgery makes you look more beautiful, but hides who you really are :-) [13:34] tedg: well, reading a merge commit to see why it's there really is bad for review [13:34] tedg: and reviewing the whole change in one commit is not so nice [13:36] tedg: can you have a more realistic requirements please? argparse is hardly good (bundled with 3), something that has deps of its own perhaps? [13:36] zyga: You're not going to get me excited about the difficulty of reading a 200 line diff. [13:37] zyga: We're not testing PIP here, just that PIP gets called. [13:37] tedg: that's not useful [13:38] tedg: the test doesn't check that what you do works in pratice IMHO [13:38] tedg: especially that it does work if you have argparse installed on the host [13:38] tedg: or if you have something it depends on installed is also present [13:38] rickspencer3: sent [13:38] zyga: ? We're not looking at the host installation. [13:39] thanks ppisati [13:39] zyga: We're testing that it gets downloaded and installed into the part. If it's in the host the test will fail. [13:39] tedg: does it work if you use this plugin to install plainbox? [13:40] tedg: (since plainbox is installed most of the time, that's an interesting test in itself) [13:41] rickspencer3: it's a bit long and hackish, but i tested every step on a clean snappy instalation, so it should just work [13:41] (last famous words...) [13:41] haha [13:41] zyga: I looked at plainbox and it seemed to have multiple requirements files, which it doesn't support. But you said that you don't use requirements files, which is what this branch supports. [13:41] tedg: hmm [13:41] zyga: So I think the answer is no. [13:41] tedg: but what about _no_ requirements [13:41] tedg: and just "get this thing from pypi" [13:42] tedg: which is akin to pip install $stuff [13:42] zyga: No, didn't add that. I think that people mostly do that in their setup.py. No? [13:43] tedg: hmm, but then they cannot use this part, right? [13:43] tedg: or am I missing something [13:43]