| gsilvapt | Anyway, here's my understanding: | 00:00 |
|---|---|---|
| gsilvapt | The @click.version_option() command should be like @click.version_option(message.format(snapcraft.__version__)) | 00:01 |
| gsilvapt | This get the version number and plugs it in the variable string | 00:01 |
| gsilvapt | The same goes in the version module. click.echo(message.format(snapcraft.__version__)) | 00:01 |
| gsilvapt | kyrofa, is this correct so far? | 00:02 |
| kyrofa | Essentially. The question is: where does `message` come from? | 00:03 |
| gsilvapt | Yes | 00:04 |
| kennyloggins | how do you ensure that the Mp3 or whatever you are sending is seen in servicesID ? | 00:07 |
| kyrofa | Hmm. Anyone run into this before? https://forum.snapcraft.io/t/raspberry-pi-2-edge-core-snap-seems-broken/3061/2 | 00:08 |
| gsilvapt | Yes, that is essentially the question, kyrofa | 00:09 |
| kyrofa | gsilvapt, you've been right so far, can you continue? | 00:09 |
| gsilvapt | I tried adding in version module, before click statement and didn't work. Tried adding to group section, not worked either | 00:09 |
| gsilvapt | kyrofa, not really. The question is where should I define that variable | 00:10 |
| kyrofa | gsilvapt, take a look at snapcraft/cli/store.py | 00:10 |
| kyrofa | gsilvapt, notice the `_MESSAGE_REGISTER_PRIVATE` definition | 00:11 |
| gsilvapt | kyrofa, yes, I'm trying to follow the example | 00:11 |
| kyrofa | gsilvapt, the module-level definitions (like the variable) are accessible from __init__ because we have an "import versioncli" there, right? | 00:12 |
| kyrofa | Which means you can access stuff via `versioncli.<variable>` | 00:12 |
| kyrofa | Uh, no sorry | 00:12 |
| kyrofa | Haha | 00:12 |
| kyrofa | Rather, the module-level definitions are available in the `.version` import | 00:13 |
| kyrofa | Note how in __init__.py we're using `from .version import versioncli` | 00:13 |
| kyrofa | All we need to do is also import the variable you define in there | 00:13 |
| kyrofa | It works the same way | 00:13 |
| gsilvapt | kyrofa, so I added from .version import _MESSAGE_SNAPCRAFT_VERSION and I am able to use the command again without any errors | 00:15 |
| gsilvapt | now I have to properly define the string to get prog name and version number | 00:16 |
| gsilvapt | Right now the version command is always retrieving ($prog) and ($version) | 00:16 |
| kyrofa | There you go. Although since you've created it for use for other modules I wouldn't use an underscore at the beginning (that indicates that it's mean to be private) | 00:16 |
| gsilvapt | Oh right, this is different in Python. A global variable does not take any underscore, right? | 00:17 |
| kyrofa | Well, it can, it depends on its usage | 00:17 |
| gsilvapt | kyrofa, how about this case? | 00:18 |
| kyrofa | Python has very little rules, but lots of conventions | 00:18 |
| kyrofa | I would call it `SNAPCRAFT_VERSION_TEMPLATE` | 00:18 |
| gsilvapt | I'm more used to work in Java and this stuff is specific anyway :P | 00:18 |
| gsilvapt | Well, it's late again and I need to sleep. I hope we can work on this together some time soon. I think it is working now but the string is poorly defined. I need to tell Python where to get the variable values ($prog) and ($version) | 00:20 |
| gsilvapt | %(prog) and %(version) instead of what I wrote before, lol | 00:20 |
| kyrofa | Yeah that's not too hard, happy to work on it later with ya | 00:23 |
| gsilvapt | Thank you! Have a good night folks o/ | 00:23 |
| kennyloggins | o/ | 00:23 |
| kyrofa | Night gsilvapt | 00:24 |
| mup | PR snapcraft#1728 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1728> | 00:35 |
| sergiusens | elopio kyrofa snapcraft#1781 is updated | 02:42 |
| mup | PR snapcraft#1781: many: set rpath for elf files for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781> | 02:42 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| mborzecki | morning | 07:26 |
| mborzecki | sorry i'm later than usual, had to drive the kids to school & kindergarten | 07:27 |
| mvo | hey mborzecki, good morning! | 07:27 |
| mvo | mborzecki: no worries | 07:27 |
| mborzecki | mvo: thanks for the review & suggestions btw | 07:28 |
| mvo | mborzecki: your welcome, but I may have been to simplistic, I think there are more cyclic case | 07:29 |
| mvo | mborzecki: something like "a: after-b, b: after-c, c: before-a | 07:30 |
| mvo | mborzecki: which I guess (I need to look again) your code addressed but mine did not | 07:30 |
| mborzecki | zyga suggested trying to do topo sorting on a graph, so i tried to play with this yesterday, but the naiive approach that i did over the weekend beat the 'smart' in all the cases i tried | 07:30 |
| mvo | mborzecki: heh :) yeah, our inputs are pretty small | 07:31 |
| mvo | mborzecki: I will look at this again with a fresh mind today | 07:31 |
| mborzecki | the benchmarks would suggest that we're loosing on doing extra allocations when creating the 'extra' data structures either dfs or khan may need | 07:33 |
| mborzecki | mvo: one thing that bugs me, is that if you add 'after' does that imply 'Requires=' in the service file? | 07:34 |
| mvo | mborzecki: I think it does not imply this, one is about ordering, the other about dependencies, they are often used together but orthogonal. i.e. you can express "if this thing.service is installed I want to start before. without the requires it also says: but I don't care if it is there or not" | 07:37 |
| mborzecki | this post mentions 'with' https://forum.snapcraft.io/t/snap-service-start-ordering/1470/13 this might map to Requires | 07:38 |
| mvo | mborzecki: yeah, I think there is language in there (as a next step) to express these dependeices as well | 07:38 |
| mborzecki | let's land this one first and we'll know if there's need for more ways to express dependencies | 07:40 |
| kalikiana | good morning folks | 07:58 |
| mborzecki | kalikiana: morning | 07:59 |
| mup | PR snapd#4361 opened: devicestate: fix misbehaving test when using systemd-resolved <Created by mvo5> <https://github.com/snapcore/snapd/pull/4361> | 08:06 |
| jamesh | mvo: I uploaded a new version of the test-snapd-gnome-online-accounts snap (the original wouldn't run due to library incompatibility), which seems to have been held up by the automatic review process. Are you able to do anything about that? | 08:36 |
| mvo | jamesh: probably, let me check | 08:41 |
| mvo | jamesh: did you request a manual review? | 08:43 |
| mvo | jamesh: if not, please do | 08:43 |
| jamesh | mvo: I've done that now | 08:44 |
| mvo | jamesh: approved | 08:45 |
| jamesh | thanks | 08:45 |
| mvo | jamesh: yw, shall I pushlish it as well? | 08:45 |
| jamesh | mvo: I think I've got it published right now | 08:46 |
| jamesh | thanks for the help | 08:47 |
| mvo | great, your welcome | 08:47 |
| pedronis | mvo: is edge building still broken? afaict current edge doesn't contain yet the configure-snapd fix | 09:04 |
| mvo | pedronis: let me check, I though I triggered a manual build the other day. auto-building is broken | 09:06 |
| mvo | pedronis: let me trigger it now | 09:06 |
| zyga-ubuntu | o/ | 09:19 |
| zyga-ubuntu | man, I overslept | 09:20 |
| Chipaca | I ended up poking at spread in qemu until way too late :-) | 09:25 |
| Chipaca | but, now i'm off to physio gym thing, so it evens out | 09:26 |
| zyga-ubuntu | Chipaca: what did you find? | 09:26 |
| Chipaca | o/ | 09:26 |
| zyga-ubuntu | ah, ttyl | 09:26 |
| Chipaca | zyga-ubuntu: i found that it's weird :-) | 09:26 |
| zyga-ubuntu | pfff, we all knew that | 09:26 |
| zyga-ubuntu | ;-) | 09:26 |
| zyga-ubuntu | enjoy; let's talk soon | 09:26 |
| Chipaca | zyga-ubuntu: i've got two straces, one that dies and one that doesn't | 09:26 |
| Chipaca | zyga-ubuntu: I don't see the difference | 09:27 |
| zyga-ubuntu | pastebin thenm | 09:27 |
| zyga-ubuntu | them* | 09:27 |
| mvo | +1 | 09:27 |
| zyga-ubuntu | o/ mvo | 09:27 |
| zyga-ubuntu | I have a pastebin I'm chewing through since yesterday, today I need to do some practical experiments on non-test machines | 09:27 |
| mvo | cachio_: fwiw, trying to reproduce the install-cache test failure you mentioned on ubuntu-core-16-64 seems to be ok for | 09:27 |
| zyga-ubuntu | well, on non-spread test machines running core | 09:27 |
| mvo | cachio_: I try harder | 09:28 |
| mvo | hey zyga-ubuntu | 09:28 |
| zyga-ubuntu | we are doing some very weird things on core | 09:28 |
| zyga-ubuntu | (lots of red lights in my mind) | 09:28 |
| zyga-ubuntu | the failure of those tests I mentioned yesterday, with the stale core detection, is deeper | 09:28 |
| zyga-ubuntu | even if we reboot the system is really broken IMO | 09:28 |
| mvo | zyga-ubuntu: oh | 09:28 |
| Chipaca | http://paste.ubuntu.com/26123959/ and http://paste.ubuntu.com/26123957/ | 09:29 |
| mvo | zyga-ubuntu: tell me more? | 09:29 |
| mvo | zyga-ubuntu: please | 09:29 |
| zyga-ubuntu | mvo: the pastebin I sent you pics of yesterday was from the console of a core system | 09:29 |
| zyga-ubuntu | mvo: it seems that we mount / twice | 09:29 |
| zyga-ubuntu | mvo: with a load of things in between | 09:29 |
| zyga-ubuntu | mvo: my understanding of how this works means that _all_ of the things we mounted before 2nd / are just wasted memory and hidden entries | 09:30 |
| zyga-ubuntu | mvo: I don't yet know why we do that | 09:30 |
| mvo | zyga-ubuntu: could it be a pivot root thing going on? | 09:30 |
| zyga-ubuntu | mvo: it might be but pivot root would leave / mounted elsewhere | 09:30 |
| zyga-ubuntu | you cannot pivot root / / | 09:30 |
| zyga-ubuntu | (no op) | 09:30 |
| mvo | zyga-ubuntu: well, we need to work on this for base-18 anyway, so a good time to cleanup | 09:30 |
| zyga-ubuntu | http://pastebin.ubuntu.com/26118789/ | 09:30 |
| zyga-ubuntu | mvo: good to hear | 09:30 |
| zyga-ubuntu | mvo: I'll poke at a real pi3 device and see if this is consistent | 09:31 |
| mvo | zyga-ubuntu: have you looked at the initramfs code? the writable path things makes it messy, I'm all for a cleanup | 09:31 |
| mvo | (and historic baggage) | 09:31 |
| Chipaca | ok, i'm off for real now. I'll leave you guys to ponder which one of those two traces is the one that kills the whole session. | 09:32 |
| Chipaca | to me they look identical | 09:33 |
| zyga-ubuntu | Chipaca: ha, good plan :) | 09:33 |
| Chipaca | (but yes, i know which is which) | 09:33 |
| Chipaca | it's as if one of them closed stdout, or stderr, or stdin, or whatever it is | 09:34 |
| Chipaca | hmm | 09:34 |
| * zyga-ubuntu hates pastebein with moronic need to auth | 09:34 | |
| zyga-ubuntu | no wget | 09:34 |
| mvo | zyga-ubuntu: I'm looking at the pictures you pasted, I see core_ mounted twice on / is that what you are concerend about? | 09:34 |
| zyga-ubuntu | mvo: yes | 09:34 |
| zyga-ubuntu | mvo: IMO that is wrong | 09:34 |
| Chipaca | zyga-ubuntu: blame spammers | 09:34 |
| mup | PR snapd#4362 opened: interfaces: update fixme comments <Created by stolowski> <https://github.com/snapcore/snapd/pull/4362> | 09:34 |
| * Chipaca runs off before he gets sucked in again | 09:35 | |
| pstolowski | zyga-ubuntu, ^ hey, one of the changes you requested - just an update of comments, no code change | 09:35 |
| mvo | zyga-ubuntu: yeah, let me wander into initramfs land again /me puts on asbestos cloth | 09:35 |
| zyga-ubuntu | mvo: yeah | 09:35 |
| mwhudson | zyga-ubuntu: did i ever tell you about debugging docker on arm64 where cloneflags was ignored so pivot_root was called in the default namespace | 09:35 |
| zyga-ubuntu | mvo: I'll gladly work on fixing this | 09:35 |
| mwhudson | zyga-ubuntu: that was quite confusing :) | 09:35 |
| zyga-ubuntu | mwhudson: haha, that must have been quite the alice in wonderland moment | 09:36 |
| mwhudson | especially as the host system didn't have an awful lot on it to distinguish it from the docker image i was testing with | 09:36 |
| mvo | zyga-ubuntu: we need to be careful this sh code is undertested | 09:36 |
| mvo | mwhudson: woah :) | 09:36 |
| mwhudson | i run docker run foo ... and docker itself disappears? | 09:36 |
| zyga-ubuntu | mvo: I'm acutely aware of that :/ | 09:38 |
| mvo | zyga-ubuntu: I know :) | 09:39 |
| mvo | zyga-ubuntu: I may have found the bug already and its amazingly stupid | 09:40 |
| mvo | zyga-ubuntu: my conservative self is not wanting me to say this, but: I really want to write the initramfs stuff in something sane that is not sh | 09:40 |
| zyga-ubuntu | !!! | 09:40 |
| zyga-ubuntu | that was quick | 09:41 |
| zyga-ubuntu | mvo: skunkworks project to rewrite that +1 | 09:41 |
| zyga-ubuntu | mvo: just not in go (we cannot) | 09:41 |
| mvo | zyga-ubuntu: no go because of the setns issues? | 09:41 |
| zyga-ubuntu | mvo: so, this is interesting: on bare metal I don't see that problem: http://pastebin.ubuntu.com/26123995/ | 09:41 |
| mvo | with threading and all that | 09:42 |
| zyga-ubuntu | mvo: not only setns but yes | 09:42 |
| zyga-ubuntu | mvo: 1thread requirement | 09:42 |
| zyga-ubuntu | mvo: the fact that / is mounted from initramfs and then core is mounted again from userspace is also a bit annoying but I don't know if it's worth fixing | 09:43 |
| zyga-ubuntu | http://pastebin.ubuntu.com/26123999/ <- core snap mounted twice | 09:43 |
| mvo | zyga-ubuntu: yes | 09:43 |
| mvo | pedronis: new core snap in edge should have the configure-snapd fix now, I did a bit of manual handholding | 09:44 |
| zyga-ubuntu | mvo: also interesting: http://pastebin.ubuntu.com/26124012/ the two snaps we mount from initramfs are mounted as _writable_ and not as auto-clear | 09:45 |
| zyga-ubuntu | mvo: the auto clear is probably irrelevant but the writable bit should have never been set | 09:45 |
| zyga-ubuntu | mvo: this allows an attacker to write to loop0 and change the squashfs bits | 09:45 |
| mvo | zyga-ubuntu: aha, that should be an easy fix, one minute | 09:47 |
| mvo | zyga-ubuntu: http://paste.ubuntu.com/26124029/ | 09:48 |
| zyga-ubuntu | mvo: +1 | 09:49 |
| zyga-ubuntu | mvo: every time I look at that pile if shell I feel bad | 09:50 |
| mvo | zyga-ubuntu: yeah, makes me want to scrub myself | 09:51 |
| zyga-ubuntu | mvo: can you fix inconsistent tabs/spaces | 09:51 |
| mvo | zyga-ubuntu: anyway, lets see what we can do to fix things | 09:51 |
| zyga-ubuntu | mvo: if you are going to make changes there | 09:51 |
| pedronis | mvo: thank you, refresh to it now worked | 09:51 |
| zyga-ubuntu | mvo: I'll check other systems, I don't understand if the brokenness I saw is specific to spread | 09:51 |
| mvo | pedronis: yay | 09:52 |
| mup | Issue snapcraft#1702 closed: Apply guidelines from design to error messages with reasons for errors <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1702> | 09:52 |
| mup | PR snapcraft#1640 closed: cli: add what, why, and how to fix to the common errors <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1640> | 09:52 |
| pstolowski | pedronis, hey, can you take a look and weight on #4301? I've addressed the last bit from Gustavo (AttrGetter -> Attrer renaming), but aparently he didn't manage to re-review yesterday, would be good to land it as it's a prerequisite for others | 09:52 |
| mup | PR #4301: interfaces: PlugInfo/SlotInfo/ConnectedPlug/ConnectedSlot attribute helpers <Created by stolowski> <https://github.com/snapcore/snapd/pull/4301> | 09:52 |
| zyga-ubuntu | mvo: and btw, I don't see any use of pivot_root | 09:52 |
| zyga-ubuntu | mvo: is it hidden somewhere or are we just missing it? | 09:52 |
| mvo | zyga-ubuntu: I think I may misrember actually | 09:53 |
| mvo | zyga-ubuntu: now that I look at the code its less clear to me what is going on | 09:53 |
| pedronis | pstolowski: will look in a bit | 09:53 |
| zyga-ubuntu | mvo: I'll check dragon and I'll get an amd64 image for qemu | 09:53 |
| mup | PR core-build#24 opened: ubuntu-core-rootfs: mount os/kernel snaps RO <Created by mvo5> <https://github.com/snapcore/core-build/pull/24> | 09:54 |
| mup | Issue snapcraft#1663 closed: patchelf with common rpath (not runpath) <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1663> | 09:55 |
| mup | PR snapcraft#1781 closed: many: set rpath for elf files for classic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781> | 09:55 |
| zyga-ubuntu | mvo: can you test your PR in practice and see that losetup --json shows it's correct then? | 09:55 |
| zyga-ubuntu | mvo: a manual test if you can do that | 09:55 |
| zyga-ubuntu | mvo: I approved the PR already | 09:56 |
| zyga-ubuntu | mvo: we really have to rewrite mount units | 09:57 |
| zyga-ubuntu | mvo: on dragon I see three generation of mount files we write | 09:57 |
| zyga-ubuntu | mvo: a simple rewrite that fixes things for next boot would be good | 09:58 |
| zyga-ubuntu | mvo: uh, my mistake, I was blinded by odd double-sided print | 10:05 |
| zyga-ubuntu | mvo: stop looking for double / :) | 10:05 |
| zyga-ubuntu | mvo: so now I'm back to square one, what is wrong there :/ | 10:05 |
| mvo | zyga-ubuntu: rewrite fix is still needed? or should I also scratch that? | 10:06 |
| mup | PR snapd#4363 opened: cmd/snap-mgmt: add more directories for cleanup and refactor purge() code <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4363> | 10:06 |
| mvo | zyga-ubuntu: rewriting with the before=snapd.servie? | 10:07 |
| zyga-ubuntu | mvo: no, that is still needed | 10:07 |
| zyga-ubuntu | mvo: that should have been there forever | 10:07 |
| mvo | zyga-ubuntu: ok, but "just" that - or do we need more rewrite? | 10:08 |
| zyga-ubuntu | mvo: not sure I understand the difference; we need to be able to rewrite mount units and and we ought to rewrite mount units in the field to correct for past mistakes | 10:08 |
| mvo | zyga-ubuntu: we are in agreement, I was wondering if there is a new bug that requires us to rewrite them | 10:10 |
| zyga-ubuntu | aha, sorry for being confusing then | 10:10 |
| mvo | zyga-ubuntu: I will have a look. no worries, communication is hard :) | 10:10 |
| mvo | (it always is!) | 10:10 |
| zyga-ubuntu | mvo: the pastebin I sent you, I was holding it wrong, litteraly :) | 10:10 |
| zyga-ubuntu | I looked at head of both inside and outside parts | 10:10 |
| mvo | zyga-ubuntu: heh | 10:11 |
| mvo | zyga-ubuntu: we have 256 files in etc and var in my base-18 WIP snap :/ there is quite some work to get rid of those if we want to get rid of the writable-path magic | 10:11 |
| * mvo gets to work | 10:12 | |
| zyga-ubuntu | mvo: where do you do this work? | 10:12 |
| zyga-ubuntu | mvo: I'd love a new repo for base-18 | 10:12 |
| mvo | zyga-ubuntu: lp:snap-base-18 | 10:13 |
| mvo | zyga-ubuntu: so far very minimal/experimental/WIP but its a start | 10:13 |
| zyga-ubuntu | bzr or git? | 10:14 |
| mvo | zyga-ubuntu: git | 10:14 |
| mvo | zyga-ubuntu: what is bzr? | 10:14 |
| zyga-ubuntu | hhaha | 10:14 |
| * zyga-ubuntu checks how to clone from launchpad | 10:14 | |
| mvo | zyga-ubuntu: https://github.com/snapcore/base-18 :P | 10:14 |
| * mvo is afk for some minutes | 10:15 | |
| zyga-ubuntu | mvo: so is it on launchpad or github? | 10:15 |
| zyga-ubuntu | mvo: I've started sending PRs | 10:21 |
| brunosfer | Hi guys, does anyone know how can I enable the driver from bluetooth on the Raspberry Pi with Ubuntu snappy core? | 10:36 |
| zyga-ubuntu | brunosfer: it should already be enabled, | 10:40 |
| mvo | zyga-ubuntu: github | 10:40 |
| zyga-ubuntu | ok | 10:40 |
| zyga-ubuntu | mvo: I send one trivial PR | 10:40 |
| zyga-ubuntu | mvo: how do you test/use this? | 10:40 |
| zyga-ubuntu | mvo: one more | 10:41 |
| mvo | zyga-ubuntu: well, I build a snap :) thats all there is for tests so far | 10:42 |
| mvo | zyga-ubuntu: good stuff, thank you! | 10:43 |
| zyga-ubuntu | mvo: ha, well, I didn't think of that :) | 10:43 |
| mvo | zyga-ubuntu: but yeah, its a good question, we need more automation and travis and all that here | 10:43 |
| zyga-ubuntu | mvo: snapcraft fails, did you run it via fakeroot? | 10:43 |
| mvo | zyga-ubuntu: yes, it needs to run as root currently, I think fakeroot will work | 10:44 |
| mvo | zyga-ubuntu: the LP builder runs it as real root | 10:44 |
| * zyga-ubuntu tries fakeroot snapcraft | 10:44 | |
| mvo | zyga-ubuntu: what is annoying is that in order to get to an empty /etc we need to undo the alternatives system i.e. awk which is provided via an alternative | 10:45 |
| mvo | (and more, w, pager) | 10:45 |
| zyga-ubuntu | hmm, we need real real root | 10:46 |
| mvo | zyga-ubuntu: ok, I need to look into why, iirc because of chroot, right? | 10:46 |
| mvo | zyga-ubuntu: *maybe* fakechroot works | 10:46 |
| zyga-ubuntu | mvo: no, because of chroot | 10:47 |
| zyga-ubuntu | mvo: anyway, that's fine, | 10:47 |
| mvo | zyga-ubuntu: fakechroot may work | 10:47 |
| zyga-ubuntu | mvo: just trying to see where this is going and what's in the snap | 10:47 |
| mvo | zyga-ubuntu: I hope it goes into a minimal base that can boot and that works with an empty /etc/ /var so that we can do factory reset easily and don't need the writable-path hacks | 10:48 |
| ogra_ | why dont you just grab an ubuntu-base tarball from cdimage and modify it as needed ... | 10:48 |
| mvo | ogra_: that would also be an option, right now it is using debootstrap to get that | 10:48 |
| ogra_ | (with a bit of fiddling oyu can even do that completely without chroot calls) | 10:48 |
| ogra_ | mvo, yeah i was guessing that ... | 10:49 |
| ogra_ | ubuntu-base is pretty much a minbase debootstrap though | 10:49 |
| zyga-ubuntu | mvo: there's some things that should be easy to kill | 10:51 |
| mvo | ogra_: indeed, interessting | 10:51 |
| zyga-ubuntu | mvo: etc/selinux | 10:51 |
| mvo | zyga-ubuntu: yeah /etc/{apt,dpkg} | 10:51 |
| zyga-ubuntu | mvo: /etc/apt | 10:51 |
| zyga-ubuntu | yeah | 10:51 |
| zyga-ubuntu | mvo: /etc/kernel/install.d | 10:52 |
| mvo | zyga-ubuntu: and some stuff we need to look at and upstream, i.e. if adduser.conf has different defaults than adduser itself we should ensure that gets fixed | 10:52 |
| ogra_ | just dont kill /usr/share/doc/<pkg>/copyrights.gz ... | 10:52 |
| zyga-ubuntu | ogra_: make that a fuse https FS | 10:52 |
| zyga-ubuntu | ;-) | 10:52 |
| mvo | ogra_: yeah, no worries :) | 10:52 |
| ogra_ | :) | 10:52 |
| mvo | ogra_: its mostly based on the current livecd-rootfs scripts | 10:53 |
| mvo | ogra_: the new skeleton | 10:53 |
| mvo | ogra_: but using a different "base" | 10:53 |
| ogra_ | yeah .. many of these scripts can also be dropped | 10:53 |
| ogra_ | we (I) didnt do a good job of throwing away old stuff thats not needed anymore | 10:53 |
| ogra_ | and some bits that live in ubuntu-core-config should rather move to the build scripts ... and vice versa ... someone should do an audit of all this | 10:54 |
| mvo | ogra_: yeah, the work on this is (slowly) starting with base-18. unfortuantely quite a bit of work but at the same time exciting because of the cleanup potential | 10:55 |
| ogra_ | yep | 10:55 |
| mvo | /etc/bindresvport.blacklist <- why do i have this file in /etc :( | 10:56 |
| ogra_ | i'm still curious how it will work out ... but looking massively forward to have bases for commercial projects ... they will massively solve issues i'm running into since i started in the new team | 10:56 |
| mvo | anyway, | 10:56 |
| mvo | ogra_: fingers crossed, but I'm excited aboutt the opportunities, all sorts of crazy bases | 10:57 |
| ogra_ | yeah | 10:57 |
| zyga-ubuntu | mvo: some more stuff in 3 | 11:02 |
| zyga-ubuntu | https://github.com/snapcore/base-18/pull/3 | 11:13 |
| mup | PR base-18#3: Document how to build the project locally, trim /etc, ignore build artefacts <Created by zyga> <https://github.com/snapcore/base-18/pull/3> | 11:13 |
| zyga-ubuntu | mvo: do we need /etc/init.d? | 11:14 |
| zyga-ubuntu | mvo: /etc/ld.so.conf.d/libc.conf also looks like something to remove | 11:15 |
| zyga-ubuntu | mvo: /etc/logrotate.d/{alternatives,dpkg} | 11:16 |
| zyga-ubuntu | mvo: /etc/profile.d | 11:16 |
| zyga-ubuntu | mvo: /etc/rc[0-6S].d | 11:16 |
| zyga-ubuntu | mvo: anyway, I think it would be fantastic if we had a way to kvm-boot this for testing | 11:17 |
| zyga-ubuntu | mvo: take a kernel snap, base-18 and gadget and boot it some way for very fast iteration | 11:17 |
| * kalikiana coffee break | 11:25 | |
| kalikiana | okay, that was a lie, I ended up making tea | 11:36 |
| * zyga-ubuntu wonders when we will see snaps on windows 3.11 http://assets.metacade.com/emulators/win311vr.html | 11:38 | |
| cachio_ | mvo, hey | 11:38 |
| cachio_ | mvo, The changelog for 2.30 rc2 doesn't contain the 2.29.4.2 changes | 11:40 |
| cachio_ | mvo, is it ok? are those changes included? | 11:40 |
| mvo | cachio_: thanks for catching that, I will double check | 11:48 |
| cachio_ | mvo, apart of that I have seen some issues during the execution | 11:49 |
| mvo | zyga-ubuntu: thanks! yeah, I think that must be the goal, right now the initramfs stuff cannot boot bases - just core | 11:49 |
| mvo | cachio_: tell me more, you mentioned yesterday that the install-cache test fails ? | 11:49 |
| cachio_ | mvo, yes | 11:50 |
| cachio_ | and the error seems to be genuine | 11:50 |
| cachio_ | mvo, similar issue for catalog-update | 11:51 |
| cachio_ | mvo, https://paste.ubuntu.com/26120827/ | 11:52 |
| cachio_ | this is a reexec in pi3 for all the errors that I saw | 11:52 |
| cachio_ | some of them are test errors, I am working on fixing them | 11:53 |
| mvo | cachio_: for the cache-install failure, does that happen just on arm or on any core device? | 11:55 |
| cachio_ | mvo, it was in any core device | 11:55 |
| cachio_ | both tests failed in any core device | 11:55 |
| cachio_ | the install-cache and the catalog-update | 11:55 |
| cachio_ | mvo, I have to go to the doc now | 11:56 |
| cachio_ | I'll be back for the standup | 11:56 |
| mvo | cachio_: thanks, I need to dig into this then, I was not able to reproduce it from a release/2.30 git checkout and running spread from there, sounds like I need to create an image first | 11:56 |
| mvo | cachio_: sure, see you. and thanks for the update | 11:56 |
| cachio_ | mvo, np | 11:56 |
| sergiusens | hello everyone | 11:57 |
| zyga-ubuntu | hey sergiusens | 11:59 |
| zyga-ubuntu | sergiusens: what's the weather like where you live? | 11:59 |
| mborzecki | i bet it's better than here | 11:59 |
| mvo | zyga-ubuntu: why do you ask? | 11:59 |
| zyga-ubuntu | mvo: ? | 12:00 |
| zyga-ubuntu | just curious | 12:00 |
| mvo | zyga-ubuntu: I was wondering if you want to fly there ;) | 12:00 |
| sergiusens | zyga-ubuntu non deterministic | 12:00 |
| ogra_ | zyga-ubuntu, definitely better than yours :) | 12:02 |
| sergiusens | zyga-ubuntu https://www.facebook.com/photo.php?fbid=10159702028205367&set=a.10154038137770367.1073741826.844960366&type=3&theater | 12:03 |
| sergiusens | it might rain, it might not; it might get cooler (like 18), it is 25 now, and it might also go up to 39 | 12:04 |
| ogra_ | what did you do to your knee ? | 12:04 |
| sergiusens | depends on if i decides to rain | 12:04 |
| sergiusens | ogra_ https://en.wikipedia.org/wiki/Chondromalacia_patellae | 12:04 |
| ogra_ | ouch | 12:05 |
| Chipaca | sergiusens: nene, eso no se hace! :-( | 12:09 |
| mborzecki | hmm tarvis jobs mostly timing out today? | 12:15 |
| zyga-ubuntu | mborzecki: sad travis day | 12:18 |
| zyga-ubuntu | I'm working entirely locally | 12:18 |
| kalikiana | btw sergiusens I tried out the slot feature in the calendar. Can you see any difference on your end? I'm not sure if it handles regular appointments correctly. You should see at least one 'unavailable' slot tomorrow. | 12:21 |
| mup | PR snapd#4362 closed: interfaces: update fixme comments <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4362> | 12:25 |
| mup | PR snapd#4301 closed: interfaces: PlugInfo/SlotInfo/ConnectedPlug/ConnectedSlot attribute helpers <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4301> | 12:28 |
| mborzecki | #4354 needs a 2nd review | 12:30 |
| mup | PR #4354: tests/lib: introduce helpers for setting up /dev/random using /dev/urandom in project prepare <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4354> | 12:30 |
| mcphail | hi. does the automated github build service only build from the master branch, or do all branches get built? | 12:58 |
| zyga-ubuntu | mcphail: hey, do you mean on build.snapcraft.io? | 12:59 |
| mcphail | yes, zyga-ubuntu | 13:02 |
| kalikiana | lunch time | 13:02 |
| zyga-ubuntu | mcphail: ah, I don't know what's the state of that, sorry | 13:04 |
| mcphail | zyga-ubuntu: ok, thanks | 13:04 |
| sergiusens | ogra_ is there an amd64 Ubuntu Core image for download? | 13:10 |
| ogra_ | sure | 13:10 |
| zyga-ubuntu | sergiusens: yes | 13:10 |
| ogra_ | sergiusens, http://cdimage.ubuntu.com/ubuntu-core/16/ | 13:10 |
| ogra_ | pick your channel | 13:10 |
| zyga-ubuntu | sergiusens: http://paste.ubuntu.com/26125012/ | 13:11 |
| sergiusens | kalikiana slots are interesting new concept in the calendar, but I think it is more of a thing for another person to click to get a slice of your time | 13:11 |
| ogra_ | note that this is zero padded for better use with kvm though (unlike the other arches) | 13:11 |
| zyga-ubuntu | sergiusens: make boot; make login | 13:11 |
| sergiusens | kind of like a doctor's appointment thing | 13:11 |
| sergiusens | ogra_ zyga-ubuntu thanks, I won't be needing any of the automation, it is for a potential demo at the IoT meetup I am presenting at today | 13:12 |
| zyga-ubuntu | sergiusens: this is not much automation, just remembers the URL and the long command | 13:13 |
| zyga-ubuntu | mvo: btw, why are you using >100 hook numbers? | 13:16 |
| zyga-ubuntu | mvo: sad | 13:18 |
| zyga-ubuntu | zyga@kaedwen:~/snap-base-18$ grep -R bindresvport.blacklist . | 13:18 |
| zyga-ubuntu | Binary file ./prime/lib/x86_64-linux-gnu/libc-2.26.so matches | 13:18 |
| zyga-ubuntu | Binary file ./prime/lib/x86_64-linux-gnu/libc.so.6 matches | 13:18 |
| mvo | zyga-ubuntu: well, we can patch that | 13:26 |
| zyga-ubuntu | mvo: yes but I find it just sad | 13:26 |
| mvo | zyga-ubuntu: +100 | 13:26 |
| zyga-ubuntu | mvo: /etc/letmecallthisfilethatIreallylikeanduseitfromlibc | 13:26 |
| sergiusens | zyga-ubuntu I just noticed it is a makefile, it does look useful! | 13:26 |
| zyga-ubuntu | :) | 13:26 |
| sergiusens | ogra_ zyga-ubuntu does stable have subiquitty and all that or should I go and get something like candidate or edge? | 13:27 |
| zyga-ubuntu | sergiusens: it has all that stsuff | 13:28 |
| zyga-ubuntu | *stuff | 13:28 |
| ogra_ | all of them have subiquity | 13:28 |
| Chipaca | mvo: http://paste.ubuntu.com/26123959/ and http://paste.ubuntu.com/26123957/ | 13:31 |
| zyga-ubuntu | mvo: https://github.com/snapcore/base-18/pull/5 | 13:32 |
| mup | PR base-18#5: More etc cleanups and reporting <Created by zyga> <https://github.com/snapcore/base-18/pull/5> | 13:32 |
| zyga-ubuntu | ls | 13:32 |
| zyga-ubuntu | mvo: do we need to keep empty things for later bind mounts or can this be added at a later stage | 13:33 |
| zyga-ubuntu | mvo: I'd like to make it so that we know we're done with /etc cleanups | 13:33 |
| zyga-ubuntu | mvo: and that the rest is actually desired | 13:33 |
| mvo | zyga-ubuntu: lets kill the empty ones too | 13:37 |
| mvo | zyga-ubuntu: if we are successful there will be no bind mounts | 13:37 |
| zyga-ubuntu | mvo: I'll tweak things so that we can boot-test this | 13:42 |
| mup | PR snapd#4359 closed: interfaces/many: misc updates for default, browser-support, opengl, desktop, unity7, x11 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4359> | 13:42 |
| mup | PR snapd#4350 closed: debian: make "gnupg" a recommends <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4350> | 13:43 |
| mvo | zyga-ubuntu: sounds good, maybe its enough to make it "type: os" to be able to test install it | 13:44 |
| mvo | zyga-ubuntu: it will not properly run because it lacks snapd but its might be enough to get to the console | 13:44 |
| mvo | zyga-ubuntu: but probably some initrd hacking is required, hopefully not much | 13:44 |
| zyga-ubuntu | mvo: yes | 13:44 |
| zyga-ubuntu | mvo: fingers crossed | 13:44 |
| zyga-ubuntu | mvo: actually may be even easier | 13:44 |
| sergiusens | elopio already around? | 13:49 |
| zyga-ubuntu | mvo: some progress, getting over last initrd hurdle | 13:55 |
| kalikiana | sergiusens: Yeah, I might just go back to using regular events. It looked like slots would help with scheduling meetings, but it doesn't seem to be meant for that | 13:55 |
| * kalikiana back from lunch | 13:55 | |
| cachio_ | jdstrand, hey, the test security-device-cgroups-serial-port is failing in the pi2 and 3 | 14:17 |
| cachio_ | jdstrand, I am researching a bit to understand why | 14:17 |
| cachio_ | jdstrand, hey, the test security-device-cgroups-serial-port is failing in the pi2 and 3 | 14:19 |
| cachio_ | jdstrand, https://paste.ubuntu.com/26125367/ | 14:19 |
| cachio_ | jdstrand, any idea what I can't get info from /dev/ttyS4? | 14:20 |
| mup | PR core#66 opened: 500-create-xdg.binary: use "set -o pipefail" <Created by mvo5> <https://github.com/snapcore/core/pull/66> | 14:27 |
| mup | PR snapd#4364 opened: interfaces: added Ref() helpers, restored more detailed error message on spi iface <Created by stolowski> <https://github.com/snapcore/snapd/pull/4364> | 14:30 |
| mborzecki | cachio_: maybe there is no device behind /dev/ttyS4, even though the node is there | 14:31 |
| pstolowski | zyga-ubuntu, ^ this is the other follow-up that addresses your comment from previous PR | 14:31 |
| zyga-ubuntu | pstolowski: thanks; looking | 14:31 |
| zyga-ubuntu | pstolowski: why not pass the slot directly? | 14:32 |
| zyga-ubuntu | pstolowski: not a big deal, just curiou | 14:32 |
| pstolowski | zyga-ubuntu, because the function is used for both SlotInfo and ConnectedSlot | 14:32 |
| zyga-ubuntu | ahh | 14:32 |
| zyga-ubuntu | ok | 14:32 |
| zyga-ubuntu | +1 | 14:32 |
| pstolowski | thx | 14:32 |
| Chipaca | grmbl! | 14:37 |
| mborzecki | cachio_: there seem to be only 2 serial ports listed in rpi3 dts files, these should map to /dev/ttyS0 and S1 and udev should list those, 2 and above have no real devices so even if the node is there it won't work and udev will now know about it | 14:38 |
| mborzecki | s/now/not/ | 14:38 |
| zyga-ubuntu | Chipaca: hmm? | 14:38 |
| * zyga-ubuntu moves an inch foward | 14:38 | |
| Chipaca | zyga-ubuntu: I just lost the output of half an hour of debugging this because for some reason the fiddling around that spread does results in the thing not letting you ssh in | 14:39 |
| Chipaca | nor log in at all actually | 14:39 |
| zyga-ubuntu | Chipaca: is that locally or over linode? | 14:41 |
| Chipaca | locally | 14:41 |
| Chipaca | qemu | 14:41 |
| zyga-ubuntu | hmm | 14:41 |
| zyga-ubuntu | on core? | 14:41 |
| Chipaca | zyga-ubuntu: classic | 14:42 |
| zyga-ubuntu | and you don't have qemu console, do you? | 14:42 |
| Chipaca | zyga-ubuntu: yes i do | 14:42 |
| Chipaca | you can telnet to it | 14:42 |
| Chipaca | e.g. 2017-12-06 14:38:43 Serial and monitor for qemu:ubuntu-14.04-64 available at ports 59479 and 59579. | 14:42 |
| * mvo added those | 14:43 | |
| Chipaca | (the serial has a getty, but that didn't let me log in once spread had started) | 14:43 |
| Chipaca | i need to ssh in before the 'preparing' phase is done | 14:43 |
| zyga-ubuntu | Chipaca: hmm | 14:43 |
| zyga-ubuntu | sorry :/ | 14:44 |
| zyga-ubuntu | I was thinking about saving a snapshot | 14:44 |
| zyga-ubuntu | and extracting stuff from that image | 14:45 |
| Chipaca | zyga-ubuntu: tried that, but apparently snapshot_blkdev doesn't work well together with -snapshot | 14:46 |
| Chipaca | Could not open '/var/tmp/vl.MGVYHB': No such file or directory | 14:46 |
| zyga-ubuntu | Chipaca: you can save that snapshot | 14:47 |
| zyga-ubuntu | Chipaca: it is documented in the qemu manual somewhere | 14:47 |
| zyga-ubuntu | Chipaca: it talks about running qemu with -snapshot and then giving it a real name in the monitor | 14:47 |
| Chipaca | ah, buh | 14:48 |
| Chipaca | i'll try that if i get stuck like this again | 14:48 |
| cachio_ | mborzecki, well the test is creating this device in case there is not one | 14:48 |
| cachio_ | mborzecki, perhaps for the pi3 we shuould create it in a different way | 14:49 |
| mborzecki | cachio_: it's creating a node, that does not mean yet there's a device, and udev knows about devices only | 14:49 |
| mborzecki | can you try ttyS1 on rpi? | 14:49 |
| mvo | Chipaca: did you try to login via test:ubuntu? | 14:49 |
| Chipaca | mvo: ubuntu:ubuntu | 14:50 |
| cachio_ | mborzecki, in my pi3 there is not a /dev/ttyS1 | 14:50 |
| mvo | Chipaca: you said the getty wouldn't let you login after spread has started, iirc we change the setup and add test:ubuntu as a user. I was wondering if that might work to login in the getty | 14:51 |
| cachio_ | I created a node for /dev/ttyS1 | 14:51 |
| Chipaca | mvo: i'll try | 14:51 |
| cachio_ | mborzecki, and I have the same problem when I do "udevadm info --path=/dev/ttyS1" | 14:51 |
| cachio_ | I get syspath not found | 14:51 |
| Chipaca | mvo: ubuntu:ubuntu logs in and is immediately logged out again | 14:52 |
| Chipaca | mvo: test:ubuntu gets login incorrect | 14:52 |
| mvo | Chipaca: :( ok | 14:55 |
| Chipaca | but thanks to zyga mentioning auditd, i now have logs that are different \o/ | 14:56 |
| Chipaca | http://pastebin.ubuntu.com/26125591/ | 14:56 |
| zyga-ubuntu | woot! | 14:56 |
| Chipaca | jdstrand: hiya. I have some rather messed up shenanigans going on in 14.04 that i'd like to understand if possible | 14:56 |
| cachio_ | mborzecki, which pi do you have? | 14:56 |
| mborzecki | cachio_: you can try dumping udev db and checking if there's anything suitable | 14:56 |
| cachio_ | mborzecki, sure | 14:57 |
| mborzecki | cachio_: i fried the last one i had :) | 14:57 |
| Chipaca | jdstrand: i now have an audit log :-) in both the "everything dies" case, and the less interesting "everything abstains from dying"; the difference is the existence of a file, and the thing that triggers the dying is doing ls on the directory that contains the file, as a user that shouldn't be able to list that directory | 14:58 |
| cachio_ | mborzecki, https://paste.ubuntu.com/26125620/ | 14:58 |
| mborzecki | cachio_: where can i find the dtb that you use? | 15:00 |
| cachio_ | mborzecki, dtb? | 15:01 |
| mborzecki | cachio_: what image do you have installed there and can i get it somewhere? | 15:01 |
| cachio_ | device tree? | 15:01 |
| cachio_ | mborzecki, you need to build it | 15:02 |
| cachio_ | mborzecki, download https://github.com/sergiocazzolato/validator | 15:02 |
| cachio_ | and then you do "./create.sh beta pi3" | 15:03 |
| cachio_ | it is gonna create the beta image | 15:03 |
| cachio_ | if you have pi2, "./create.sh beta pi2" | 15:04 |
| cachio_ | mborzecki, then you can use that image that is the same we use for beta validation | 15:04 |
| mborzecki | cachio_: it is pi2 or pi3 you're using now? | 15:06 |
| cachio_ | pi3 | 15:11 |
| cachio_ | mborzecki, I am gonna lunch now, I'll be back | 15:11 |
| cachio_ | mborzecki, export SPREAD_EXTERNAL_ADDRESS=<device ip> | 15:12 |
| cachio_ | spread -v -debug external:ubuntu-core-16-arm-32:tests/main/security-device-cgroups-serial-port | 15:13 |
| cachio_ | this is to reproduce the issue | 15:13 |
| mup | Issue snapcraft#1733 closed: Apply guidelines from design to error messages with commands that fix <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1733> | 15:14 |
| mup | PR snapcraft#1790 closed: cli: include consistent commands to fix error conditions <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1790> | 15:14 |
| mvo | zyga-ubuntu: review for https://github.com/snapcore/core/pull/66 would be great | 15:15 |
| mup | PR core#66: 500-create-xdg.binary: use "set -o pipefail" <Created by mvo5> <https://github.com/snapcore/core/pull/66> | 15:15 |
| zyga-ubuntu | mvo: sure | 15:16 |
| zyga-ubuntu | done | 15:18 |
| zyga-ubuntu | also restarted tests | 15:18 |
| mvo | zyga-ubuntu: ta | 15:20 |
| jdstrand | cachio_: so, you are do a mknod, but that isn't sufficient to make the device show up to udev and be exposed in sysfs | 15:20 |
| ikey | jdstrand, sorry for not replying to your apparmor comments there the other day - just letting you know i saw em, cheers :] | 15:21 |
| jdstrand | cachio_: there is no hardware behind that device file, so the kernel didn't do a uevent for udev to do its thing | 15:21 |
| jdstrand | ikey: cool! I also mentioned it to jj, so if he didn't followup, feel free to ping him directly | 15:21 |
| ikey | aye :] | 15:22 |
| ikey | had a mild rebase to do today with 4.14.4 due to some audit.h changes | 15:22 |
| ikey | nothing too difficult tho | 15:22 |
| jdstrand | cachio_: and therefore nothing works | 15:22 |
| jdstrand | ikey: cool | 15:23 |
| mup | PR snapcraft#1796 opened: Changelog for release 2.37 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1796> | 15:23 |
| jdstrand | Chipaca: hey. I understood what you communicated, but don't feel like I have enough context to effectually respond | 15:25 |
| jdstrand | Chipaca: do you have a snap and instructions that demonstrates the issue? | 15:26 |
| zyga-ubuntu | mvo: what is going on here: https://travis-ci.org/snapcore/core/builds/312446771?utm_source=github_status | 15:36 |
| mborzecki | cachio_: iirc both 2 and 3 have 2 uarts, i tried to download the kernel you might use (4.4.0-1009-raspi2?), then dtb for rpi2 lists the 2nd uart as disabled, the one for rpi3 lists both uarts as ok, IMO it's best if you check dmesg and look in /sys/devices/platform to see if the devices are there | 15:37 |
| Chipaca | jdstrand: I haven't been able to reproduce it outside of a in-progress branch (it's up as a PR, but fails) | 15:37 |
| mvo | zyga-ubuntu: I don't know :/ | 15:37 |
| zyga-ubuntu | what is /var/lib/snapd/environment? | 15:38 |
| Chipaca | zyga-ubuntu: a directory (?) | 15:42 |
| zyga-ubuntu | sure but what is it for? | 15:43 |
| Chipaca | zyga-ubuntu: I hope it's something we no longer use, as opposed to a random directory | 15:43 |
| Chipaca | i'm seeing it in the packaging but have no idea | 15:43 |
| zyga-ubuntu | yeah | 15:43 |
| zyga-ubuntu | I'm seeing it in booted images | 15:43 |
| mup | PR snapcraft#1797 opened: tests: update the snap name already registered for store tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1797> | 15:50 |
| mup | PR snapd#4365 opened: interfaces/mir: allow Wayland socket and non-root sockets <Created by gerboland> <https://github.com/snapcore/snapd/pull/4365> | 15:56 |
| cachio_ | jdstrand, ok, so we should skeep the test execution in that case | 15:59 |
| cachio_ | I mean, in case "udevadm info /dev/ttyS4" failes | 16:00 |
| cachio_ | jdstrand, then we exit | 16:00 |
| cachio_ | jdstrand, is it ok if I make that change? | 16:00 |
| geekgonecrazy | Hey guys, Is anyone aware of any issues with the node part? Have our rocketchat-server snap setup to build on launchpad, but keeps failing after downloading node part. Only thing that has changed between last version and this the location we download our rocket.chat bundle - https://launchpadlibrarian.net/347779291/buildlog_snap_ubuntu_xenial_amd64_stable_BUILDING.txt.gz Any ideas? | 16:01 |
| geekgonecrazy | Looks like its failing right as it finishes downloading the part | 16:04 |
| geekgonecrazy | ``` | 16:04 |
| geekgonecrazy | Downloading '' 0% Traceback (most recent call last): File "/usr/bin/snapcraft", line 9, in <module> | 16:05 |
| Chipaca | geekgonecrazy: the error is “IsADirectoryError: [Errno 21] Is a directory: '/build/stable/parts/rocketchat-server/src/'” | 16:06 |
| Chipaca | geekgonecrazy: looks like it expects a file but it's a directory | 16:07 |
| geekgonecrazy | Chipaca: yeah I see that, but seems to happen after the initial exception. | 16:07 |
| geekgonecrazy | Has something changed in snapcraft? Here is my changeset between versions. Why would this start now? https://git.launchpad.net/rocket.chat/commit/?h=stable&id=6682e7d79762d4cd1f0957845f35932fea563a92 | 16:07 |
| Chipaca | geekgonecrazy: that's the last line of the initial exception, ie the bit that triggered it (the rest is the stack) | 16:07 |
| Chipaca | it goes up, not down | 16:08 |
| geekgonecrazy | i'm used to js stacks hehe. My python experience is probably enough to be dangerous :D | 16:08 |
| Chipaca | if that's the diff between your thing not working and your thing working, i think you're right to suspect snapcraft itself | 16:09 |
| Chipaca | sergiusens, ^ | 16:10 |
| geekgonecrazy | Chipaca: Yeah that's why I wondered if the part was messed up mainly because it stops right there. But if the workers are using newer versions of snapcraft that change could be the fault as well | 16:11 |
| mup | PR snapd#4366 opened: interfaces/removable-media: also allow 'k' (lock) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4366> | 16:14 |
| mup | PR snapd#4367 opened: interfaces/removable-media: also allow 'k' (lock) for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4367> | 16:19 |
| geekgonecrazy | spinning up a clean VM, i'll see if I can hack past it locally. We cut release a few days back and hadn't had time to debug it. Hoped it was a launchpad issue that would resolve its self :P | 16:20 |
| kalikiana | kyrofa: would you be up for a hangout? to talk about the unmet dependencies | 16:25 |
| kyrofa | kalikiana, yep, perfect timing | 16:25 |
| jdstrand | cachio_: sounds reasonable to me | 16:26 |
| kyrofa | geekgonecrazy, to be clear, you only see that in LP? Not locally? | 16:26 |
| cachio_ | jdstrand, ok, I'll create a PR for that | 16:26 |
| kyrofa | kalikiana, want to just use the weekly? | 16:26 |
| kalikiana | kyrofa: sure | 16:26 |
| geekgonecrazy | kyrofa: i'm double checking to see if that's the case now. Gotten spoiled by launchpad and our ci just working. :) | 16:29 |
| geekgonecrazy | kyrofa: ok I suppose good news is it happens locally. :) | 16:36 |
| mup | PR snapd#4368 opened: tests: fix security-device-cgroups-serial-port test for rpi and db <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4368> | 16:37 |
| geekgonecrazy | kyrofa: might it have something to do with there being a redirect involved in the file download? | 16:37 |
| zyga-ubuntu | woot | 16:38 |
| zyga-ubuntu | fafasafafsaj | 16:43 |
| zyga-ubuntu | my keyboard has gone crazy | 16:43 |
| zyga-ubuntu | mvo: we ccccccccccccc | 16:43 |
| zyga-ubuntu | anc now test ocre rsnaps | 16:43 |
| zyga-ubuntu | faak | 16:43 |
| * zyga-ubuntu reboots | 16:44 | |
| mup | PR snapd#4369 opened: add write permission to optical-drive interface <Created by diddledan> <https://github.com/snapcore/snapd/pull/4369> | 16:52 |
| diddledan | aww, and here I was thinking someone wanted me :-p | 16:52 |
| zyga-ubuntu | diddledan: +1 | 16:53 |
| diddledan | thankyou :-) | 16:53 |
| * diddledan feels clever now that I've looked at snapd code | 16:53 | |
| kyrofa | geekgonecrazy, sorry, was in a meeting there for a few minutes | 16:54 |
| kyrofa | Yes, the fact that you get it locally is good indeed! Troubleshooting on LP is no fun :D | 16:55 |
| diddledan | and then I feel less clever now I spot I wrote BluRay differently each time I said it | 16:55 |
| zyga-ubuntu | mvo: I can now boot our base-18 snaps | 16:55 |
| zyga-ubuntu | mvo: it says "welcome to ubuntu core 18" :-) | 16:55 |
| kyrofa | geekgonecrazy, being due to a redirect seems odd | 16:56 |
| zyga-ubuntu | mvo: I think we need to drop a rule that gives us a getty on tty2 | 16:56 |
| kyrofa | That would surprise me | 16:56 |
| zyga-ubuntu | mvo: anyway, let me clean this up and send a PR | 16:56 |
| kyrofa | geekgonecrazy, I suspect now that you're able to reproduce locally you'll be able to figure out the cause, but do let me know if you want some help | 16:58 |
| kalikiana | diddledan: clearly you need to open lots more snapd PRs and feel the love of snapd's attention :-D | 17:00 |
| diddledan | :-) | 17:01 |
| geekgonecrazy | kyrofa yup seems due to redirect. :( wonder if it only follows certain redirects? I now have a very ugly looking prepare statement | 17:01 |
| kyrofa | geekgonecrazy, any chance you could share the URL? | 17:01 |
| geekgonecrazy | `prepare: curl -SLf "https://releases.rocket.chat/0.59.6/download/" -o rocket.chat.tgz; tar xvf rocket.chat.tgz --strip 1; cd programs/server; npm install; cd npm/node_modules/meteor/rocketchat_google-vision; npm install grpc` is what my prepare now looks like o.O | 17:01 |
| kyrofa | geekgonecrazy, also, I assume this is something that's changed recently? | 17:02 |
| kyrofa | Yikes | 17:02 |
| * kalikiana preparing to wrap up for the day | 17:02 | |
| kyrofa | geekgonecrazy, so to be clear: you're saying using source: https://releases.rocket.chat/0.59.6/download is what breaks? | 17:02 |
| geekgonecrazy | kyrofa: we've had a redirect of some sort in place for a good while I think... i'll have to look back and verify | 17:03 |
| geekgonecrazy | kyrofa: yes fails fast and hard with that as source and source-type: tar | 17:03 |
| kyrofa | geekgonecrazy, huh. This works for me: http://paste.ubuntu.com/26126334/ | 17:04 |
| kyrofa | Although I'm on snapcraft master. What are you using locally? | 17:05 |
| geekgonecrazy | kyrofa: snapcraft, version 2.35 | 17:08 |
| cachio_ | mvo, the snapd.refresh.timer does not exist on pi3, https://paste.ubuntu.com/26126388/ | 17:08 |
| kyrofa | geekgonecrazy, and does that YAML I pasted break for you? | 17:08 |
| cachio_ | it is making the test ubuntu-core-services fail | 17:08 |
| geekgonecrazy | kyrofa: it downloads, throws exception at the end i'm guessing because it doesn't know source type is a tar | 17:11 |
| geekgonecrazy | here is what our snapcraft yaml looked like before my hack around: https://git.launchpad.net/rocket.chat/tree/snapcraft.yaml?h=stable&id=945e4f912f0d5d9dc7416e2998f710da46f1755c | 17:11 |
| geekgonecrazy | might be related to the prepare there? | 17:11 |
| kyrofa | geekgonecrazy, huh, interesting. No exception for me. I'll try 2.35 | 17:12 |
| kyrofa | geekgonecrazy, prepare effects the build step, not pull | 17:13 |
| kyrofa | I still get no issues with 2.35 | 17:15 |
| geekgonecrazy | kyrofa: thats what I thought. :D | 17:16 |
| zyga-ubuntu | mvo: https://github.com/snapcore/base-18/pull/8 | 17:16 |
| mup | PR base-18#8: Add rudimentary testing infrastructure <Created by zyga> <https://github.com/snapcore/base-18/pull/8> | 17:16 |
| diddledan | zyga-ubuntu: base-18 sounds like weird counting to me.. base-16 works well with computers :-p | 17:17 |
| zyga-ubuntu | diddledan: wait till base-20 | 17:17 |
| diddledan | :-o | 17:17 |
| geekgonecrazy | kyrofa: interesting.. Some how I get same error as launchpad and launchpad I assume is building in lxd for clean builds | 17:17 |
| diddledan | so with base-16 we count 0 thru F. what are we gonna do with base-20?! | 17:17 |
| Chipaca | diddledan: base-85 is a thing | 17:19 |
| Chipaca | jus' sayin' | 17:19 |
| diddledan | drak me | 17:19 |
| diddledan | frak* | 17:19 |
| diddledan | that's crazy numbers | 17:20 |
| Chipaca | diddledan: also called Ascii85, it's in python and go's stdlibs | 17:20 |
| diddledan | ee gads | 17:20 |
| diddledan | avoid it like the plague! | 17:21 |
| diddledan | I'm guessing it's used for crypto symbolism | 17:21 |
| diddledan | similarly to base64 | 17:21 |
| Chipaca | diddledan: PDFs use it | 17:21 |
| Chipaca | diddledan: as does Postscript | 17:21 |
| diddledan | oh, well when Adobe are involved all bets are off :-p | 17:22 |
| Chipaca | diddledan: also ZeroMQ and ZMODEM | 17:22 |
| Chipaca | there's also an ascii85 representation of ipv6 addresses | 17:23 |
| Chipaca | (just, what, no) | 17:23 |
| diddledan | if 0mq uses it then I guess htey've ported it to many programming languages | 17:23 |
| zyga-ubuntu | so | 17:24 |
| Chipaca | when you see “4)+k&C#VzJ4br>0wv%Y” on your terminal your first thought is "oh crap something bought it", not "ah, good old 1080:0:0:0:8:800:200C:417A" | 17:24 |
| zyga-ubuntu | I need a hand | 17:24 |
| zyga-ubuntu | how do add a simple root shell systemd unit? | 17:24 |
| zyga-ubuntu | no login, just # | 17:24 |
| zyga-ubuntu | on tty2 ideally | 17:24 |
| Chipaca | zyga-ubuntu: don't you want the emergency shell? | 17:24 |
| zyga-ubuntu | Chipaca: I want _a_ shell | 17:24 |
| diddledan | zyga-ubuntu: get it to run getty? | 17:24 |
| zyga-ubuntu | whatever you do :) | 17:24 |
| Chipaca | zyga-ubuntu: that gives you a root shell on tty9 (iirc), from early boot | 17:25 |
| zyga-ubuntu | I need an answer in terms on systemd units | 17:25 |
| Chipaca | zyga-ubuntu: systemd.debug-shell=1 on the kernel commandline | 17:25 |
| zyga-ubuntu | ahh | 17:25 |
| zyga-ubuntu | perfect | 17:26 |
| Chipaca | zyga-ubuntu: or systemctl enable debug-shell.service if you'd rather that | 17:26 |
| zyga-ubuntu | now | 17:27 |
| zyga-ubuntu | how do I move ttys in qemu? | 17:27 |
| Chipaca | zyga-ubuntu: ctrl-alt-left or -right | 17:27 |
| Chipaca | is the easiest way imo | 17:27 |
| zyga-ubuntu | nope | 17:27 |
| zyga-ubuntu | doesn't work | 17:27 |
| zyga-ubuntu | do I need some fancy option for GUI? | 17:27 |
| zyga-ubuntu | Chipaca: I clicked on the qemu window | 17:28 |
| Chipaca | zyga-ubuntu: you're in the gui, yes? | 17:28 |
| zyga-ubuntu | (so that it woud catch my input) | 17:28 |
| zyga-ubuntu | then tried the combo | 17:28 |
| zyga-ubuntu | maybe it uses it to release | 17:28 |
| Chipaca | zyga-ubuntu: does it say your keyboard is captured? | 17:28 |
| zyga-ubuntu | the title changes | 17:28 |
| Chipaca | ah | 17:28 |
| zyga-ubuntu | says use alt-ctrl to escape | 17:28 |
| Chipaca | 1 sec | 17:28 |
| zyga-ubuntu | (ctrl-alt) | 17:28 |
| Chipaca | zyga-ubuntu: i had to bring a qemu up to remember | 17:29 |
| Chipaca | it's in muscle memory | 17:29 |
| Chipaca | zyga-ubuntu: just alt-left or -right | 17:29 |
| Chipaca | no ctrl | 17:29 |
| diddledan | if you do need to build one yourself, the exec= line would be `getty -n tty2` | 17:29 |
| zyga-ubuntu | Chipaca: no change | 17:29 |
| zyga-ubuntu | Chipaca: I don't get anything | 17:29 |
| Chipaca | zyga-ubuntu: lies | 17:29 |
| Chipaca | :-) | 17:29 |
| zyga-ubuntu | Chipaca: wanna see? | 17:29 |
| Chipaca | zyga-ubuntu: yes | 17:30 |
| zyga-ubuntu | I'll gladly hangout it | 17:30 |
| zyga-ubuntu | one sec | 17:30 |
| zyga-ubuntu | Chipaca: in standup | 17:31 |
| Chipaca | omw | 17:31 |
| Chipaca | reasons wayland is not "there" yet #(++n) | 17:36 |
| Chipaca | zyga-ubuntu: that's from https://freedesktop.org/wiki/Software/systemd/Debugging/#earlydebugshell FWIW | 17:37 |
| zyga-ubuntu | Chipaca: thanks | 17:38 |
| zyga-ubuntu | if anyone wonders what was wrong, wayland and qemu still don't work well | 17:38 |
| Chipaca | zyga-ubuntu: <Chipaca> reasons wayland is not "there" yet #(++n) | 17:38 |
| Chipaca | (from just before you logged back on) | 17:39 |
| Chipaca | n-- | 17:39 |
| Chipaca | :-) | 17:39 |
| zyga-ubuntu | hehe | 17:40 |
| zyga-ubuntu | mvo: teaser https://twitter.com/zygoon/status/938464408610754562 | 17:45 |
| sergiusens | geekgonecrazy are you behind a proxy? kyrofa I assume you are not | 17:56 |
| kyrofa | Indeed I am not | 17:56 |
| kyrofa | But LP is, of course | 17:56 |
| sergiusens | kyrofa yeah, that might be the commonality | 17:58 |
| kyrofa | Yeah interesting idea | 17:58 |
| zyga-ubuntu | kyrofa: when does a make plugin detect that it is out of date | 18:13 |
| zyga-ubuntu | kyrofa: I have a make-based project | 18:13 |
| zyga-ubuntu | kyrofa: I keep changing things and snapcraft thinks it's all up-to-date | 18:13 |
| kyrofa | zyga-ubuntu, only when something in the yaml changes | 18:14 |
| zyga-ubuntu | kyrofa: and then re-squahses stuff | 18:14 |
| zyga-ubuntu | kyrofa: why? you can ask make | 18:14 |
| zyga-ubuntu | kyrofa: you have all the part lifecycle stuff | 18:14 |
| zyga-ubuntu | kyrofa: make -n | 18:14 |
| zyga-ubuntu | or perhaps -q | 18:14 |
| zyga-ubuntu | (yes -q) | 18:14 |
| zyga-ubuntu | given that this is a network-heavy part I just keep wasting time because it's too silly to make again | 18:14 |
| kyrofa | zyga-ubuntu, a few different reasons. First of all, snapcraft doesn't build the source you hand it directly. During the pull step it copies it into the area it controls. So make doesn't see any changes | 18:15 |
| cachio_ | pedronis, we have a test failing in rpi | 18:15 |
| cachio_ | pedronis, it fails doing > snap ack "$TESTSLIB/assertions/testrootorg-store.account-key" | 18:15 |
| cachio_ | error: cannot assert: assert failed: cannot find account (testrootorg) | 18:16 |
| pedronis | it's probably missing a skip | 18:16 |
| pedronis | we cannot run some tests if it's a real snapd | 18:16 |
| cachio_ | any idea why it could fail just on rpi and dragonboards? | 18:16 |
| pedronis | (no test keys) | 18:16 |
| pedronis | it's telling you this a real snapd, not a test build one | 18:16 |
| sergiusens | kyrofa elopio I haven't seen any comment on https://github.com/snapcore/snapcraft/pull/1796 | 18:16 |
| mup | PR snapcraft#1796: Changelog for release 2.37 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1796> | 18:16 |
| pedronis | s/real/prod/ | 18:16 |
| kyrofa | zyga-ubuntu, also, while make supports discovering changes, not all build systems are as nice, as we haven't developed a generic method that works for all plugins | 18:16 |
| cachio_ | pedronis, ah, ok | 18:17 |
| cachio_ | what should I check to skip it? | 18:17 |
| kyrofa | zyga-ubuntu, that's not to say we don't want to get there, but it's a good chunk of work | 18:17 |
| pedronis | cachio_: well we have TRUST_TEST_KEYS or something like that? | 18:17 |
| pedronis | maybe you are not setting it properly? | 18:17 |
| kyrofa | Also, snapcraft is a packaging tool. It isn't best-suited to being so tightly in the development loop | 18:17 |
| pedronis | or the test doesn't have the check yet | 18:17 |
| cachio_ | TRUST_TEST_KEYS are true | 18:17 |
| pedronis | cachio_: you cannot set it to true if you are using a prod snapd | 18:18 |
| pedronis | it doesn't have the keys | 18:18 |
| zyga-ubuntu | kyrofa: this makes sense, thank you for explaining | 18:18 |
| cachio_ | pedronis, mmm, well something else is setting that var to true | 18:18 |
| cachio_ | pedronis, I am not setting it | 18:18 |
| kyrofa | Of course | 18:19 |
| kyrofa | sergiusens, oh man, I missed it go up! | 18:19 |
| pedronis | cachio_: true is the default | 18:19 |
| pedronis | you need to set to false yourself | 18:19 |
| pedronis | if I understand | 18:19 |
| zyga-ubuntu | kyrofa: is there some way to ask snapcraft to use fast compression? | 18:19 |
| pedronis | SPREAD_TRUST_TEST_KEYS=false | 18:19 |
| zyga-ubuntu | kyrofa: especially for test snaps | 18:19 |
| zyga-ubuntu | kyrofa: that are not sent anywhere | 18:20 |
| cachio_ | pedronis, ok, I'll take a look to that | 18:20 |
| kyrofa | zyga-ubuntu, honestly I'm not sure what that means :P | 18:20 |
| kyrofa | zyga-ubuntu, you mean for the squashfs image? | 18:20 |
| zyga-ubuntu | kyrofa: call mksquashfs without compression | 18:20 |
| cachio_ | pedronis, in the spread.yaml it is using TRUST_TEST_KEYS: "false" | 18:20 |
| kyrofa | zyga-ubuntu, no, it's hard-coded to xz etc. to make the store happy | 18:20 |
| cachio_ | but just for ubuntu-core-16-64 and ubuntu-core-16-32 | 18:21 |
| kyrofa | zyga-ubuntu, but you could hack it pretty easily if you wan | 18:21 |
| cachio_ | pedronis, in this case, for pi3 we use system: ubuntu-core-16-arm-32 | 18:21 |
| pedronis | cachio_: ah | 18:21 |
| cachio_ | pedronis, so, should I change it? | 18:21 |
| pedronis | they all need to be the same | 18:21 |
| kyrofa | zyga-ubuntu, snapcraft/internal/lifecycle/_packer.py for your reference | 18:21 |
| geekgonecrazy | sergiusens: nope not behind proxy (though I know launchpad is) | 18:21 |
| pedronis | cachio_: this is the external backends ? | 18:22 |
| zyga-ubuntu | kyrofa: thank you! | 18:22 |
| cachio_ | pedronis, yes | 18:22 |
| cachio_ | pedronis, external | 18:22 |
| pedronis | cachio_: yes, they all need the same config | 18:22 |
| pedronis | not sure why some have the false and some not | 18:22 |
| cachio_ | pedronis, ok, makes sense | 18:22 |
| cachio_ | thanks, I'll check that | 18:22 |
| pedronis | I wasn't really paying attention to that part of spread.yaml | 18:22 |
| geekgonecrazy | kyrofa: https://launchpadlibrarian.net/348314093/buildlog_snap_ubuntu_xenial_amd64_stable_BUILDING.txt.gz got one successful doing the curl in the prepare step. o.O Not pretty but gets the release where I can push it out to the impatient users :D | 18:22 |
| cachio_ | pedronis, I do :) | 18:23 |
| cachio_ | pedronis, I use it a lot | 18:23 |
| kyrofa | Hey jdstrand, I'm playing with another joystick lib, and finding our joystick interface lacking a bit. I'd like to be able to access /dev/input/event* for the joystick... but it's entirely unclear to me how we can determine which events are tied to the joystick | 18:29 |
| kyrofa | jdstrand, https://pastebin.ubuntu.com/26126996/ | 18:29 |
| kyrofa | jdstrand, note how js0 and event17 are pretty clearly provided by the same device | 18:30 |
| kyrofa | jdstrand, think that's possible? | 18:30 |
| jdstrand | kyrofa: can you paste 'udevadm info /dev/input/event17'? | 18:33 |
| kyrofa | jdstrand, here's both event17 as well as js0: https://pastebin.ubuntu.com/26127016/ | 18:34 |
| kyrofa | I don't know much about this-- they both seem to be an interface to the same data. Is one just a newer/different API? | 18:35 |
| jdstrand | I think so, yes | 18:36 |
| jdstrand | kyrofa: so, I do think this is possible. what you would need to do is interrogate udev to map the thing you know (/dev/input/js0) to the thing you don't (/dev/input/event17) then add the device access for event17 | 18:37 |
| kyrofa | Quick research leads me to believe js is old, event is newer | 18:37 |
| kyrofa | jdstrand, can we do things like that in an interface? | 18:37 |
| jdstrand | kyrofa: that is accurate | 18:37 |
| kyrofa | So far I've just been adding static ones | 18:38 |
| jdstrand | kyrofa: well, it is something I always hoped we could do for all sysfs entries. Ie, we assign js0 and then allow the precise sysfs entries for that device | 18:38 |
| jdstrand | kyrofa: this isn't that different | 18:38 |
| jdstrand | kyrofa: the problem is this is related to hotplug | 18:39 |
| kyrofa | Say no more... | 18:39 |
| kyrofa | jdstrand, would I be correct to assume that whitelisting /dev/input/event* in joystick is a bad idea? | 18:40 |
| jdstrand | kyrofa: so we could come up with a way to look at udev (or possibly more simply, various symlinks), but interfacec connections happen at specific points in time, but reboots, plug/unplug, etc would change the paths | 18:41 |
| jdstrand | kyrofa: oh gosh yes. that would grant anything that plugged the interface the ability to spy and spoof input events | 18:41 |
| jdstrand | *all* input events | 18:42 |
| kyrofa | Heh | 18:42 |
| kyrofa | Yeah and profile generation only happens at install/upgrade time, right? | 18:42 |
| jdstrand | connect/disconnect (obviously) | 18:43 |
| kyrofa | Right, that's more specific. And THAT is what causes them to happen at install/upgrade time I suppose | 18:43 |
| jdstrand | interestingly, also on reboot if the policy is different on disk from what snapd generates | 18:43 |
| kyrofa | Oh, hmm | 18:44 |
| jdstrand | I mention that last point cause you could get there crudely on reboot if snapd did its interrogating to come up with different policy | 18:44 |
| kyrofa | Exactly my thought | 18:44 |
| jdstrand | so js0 -> event17 might be js0 -> event16 | 18:44 |
| jdstrand | snapd would detect that | 18:45 |
| jdstrand | but snapd would have to tie into the uevent kernel framework to get notifications on hotplug/unplug | 18:45 |
| kyrofa | Right, and then in order to get new devices into the profile, one would need to reboot, or disconnect/connect the interface | 18:46 |
| kyrofa | Meh | 18:46 |
| jdstrand | there is another way to deal with this: static file labels with apparmor. the idea is that you create a udev rule that statically labels the device based on the snap's label | 18:47 |
| jdstrand | but apparmor doesn't support that yet | 18:47 |
| jdstrand | (that incidentally would get rid of the need for device cgroups, which would be great) | 18:47 |
| jdstrand | kyrofa: exactly (hence the 'crudely' and why this is tied to hotplug) | 18:48 |
| jdstrand | all of this is doable, but as you know, hotplug is on the roadmap but not prioritized for the short term | 18:49 |
| kyrofa | Indeed. Okay, I'll hold off further investigation into this, and look for a python lib that uses the older interface. Very educational, thank you! | 18:49 |
| kyrofa | Indeed | 18:49 |
| jdstrand | np | 18:49 |
| mup | PR snapcraft#1796 closed: Changelog for release 2.37 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1796> | 18:57 |
| sergiusens | kyrofa elopio don't merge anything until further notice please | 18:57 |
| kyrofa | ack | 18:57 |
| elopio | ok | 18:58 |
| mup | PR snapd#4370 opened: tests: set TRUST_TEST_KEYS=false for all the external backends <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4370> | 19:14 |
| kyrofa | Hey cjwatson, I'm curious: why, if LP supports all these architectures in the builders, does build.snapcraft.io only support a few of them? | 19:51 |
| cjwatson | kyrofa: mainly because we want to have the facility to select specific architectures in snapcraft.yaml or similar (as we talked about at the rally, if you remember) before we enable more architectures by default that many developers won't care about without offering them a way to shut up the build failures | 19:59 |
| cjwatson | kyrofa: also, s390x needs to have the new scalingstack region finished off before we can offer it in BSI | 20:00 |
| mup | PR snapd#4364 closed: interfaces: added Ref() helpers, restored more detailed error message on spi iface <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4364> | 20:02 |
| kyrofa | Ah, makes sense thank you :) | 20:15 |
| === mcphail_ is now known as mcphail | ||
| sergiusens | cjwatson seems something hit kyrofa on the head, we were just discussing this on Monday ;-) | 20:55 |
| kyrofa | sergiusens, we didn't discuss that it was preventing more arch support in build.snapcraft.io | 20:55 |
| sergiusens | kyrofa oh, I am talking about the flashback to the rally conversation :-) | 20:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!