| === mup_ is now known as mup | ||
| morphis_ | Pharaoh_Atem: ping | 06:10 |
|---|---|---|
| === JanC is now known as Guest29977 | ||
| === JanC_ is now known as JanC | ||
| zyga | good morning | 06:59 |
| pstolowski | morning | 07:13 |
| fgimenez | good morning mvo, i saw your post on the forum about 2.26.4 and have already started the beta validation, will let you know how it goes | 07:13 |
| fgimenez | hey pstolowski | 07:13 |
| mup | PR snapcraft#1327 closed: tests: small updates for manual kernel tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1327> | 07:13 |
| mup | PR snapcraft#1341 closed: Release changelog for 2.30.1 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1341> | 07:13 |
| mvo | fgimenez: great, thank you | 07:15 |
| fgimenez | pstolowski: i had a chance yesterday to have a look at the snapctl test issue, fwiw it looks to me that we are disabling autorefresh before putting the outer binaries in the core snap, IMO this https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L139 shoulb be done after the update_core_snap_for_classic_reexec call, anyway that only explains the warning messages we get and not the actual error | 07:16 |
| zyga | mwhudson: hey | 07:18 |
| zyga | mwhudson: still around by any chance? | 07:18 |
| pstolowski | fgimenez, hi! yes, i saw this and yes, it's jut the warning. it's ok | 07:18 |
| zyga | mwhudson: https://forum.snapcraft.io/t/build-failure-for-2-26-4-on-artful-on-arm-arm64/866 does this error ring any bells? | 07:18 |
| fgimenez | pstolowski: yep, if i change the order and reexecute the test i still get the same error, you are probably aware but putting in place some debug info it seems that it keeps failing after "snap set core refresh.schedule=Sun@12:00-14:00" but the actual failure happens in the daemon when it gets "get service.ssh.disable" (not sure why it gets this after trying to set another property), in that case the cookieID received is empty | 07:21 |
| pstolowski | fgimenez, is this with all my changes from that branch, or did you comment the SNAP_CONTEXT compatibility line out? | 07:23 |
| fgimenez | the context seems to be correctly set map[yltR4VFx0ryHTjNpvGVHmvHbpvsg47sv5M7S7JtmTtkm:core] | 07:23 |
| fgimenez | pstolowski: with all the changes in your branch and removing the compatibility line | 07:23 |
| mup | PR snapd#3427 opened: interfaces/builtin: silence ptrace denial for network-manager <Created by morphis> <https://github.com/snapcore/snapd/pull/3427> | 07:27 |
| fgimenez | pstolowski: probably that "get service.ssh.disable" comes from the core's configure hook itself https://github.com/snapcore/core/blob/master/hooks/configure#L111 | 07:35 |
| pstolowski | fgimenez, yes, this failure is expected then without that compatibility line; lack of this line causes all hooks to fail | 07:44 |
| pstolowski | fgimenez, how can I test all possible scenarios (with re-exec disabled)? is setting this env var before running spread locally with qemu enough? | 07:45 |
| fgimenez | pstolowski: yes, just export SPREAD_SNAP_REEXEC=0 before executing, there's also export SPREAD_MODIFY_CORE_SNAP_FOR_REEXEC=0 if you want the core snap to be untouched, and also SPREAD_CORE_CHANNEL for selecting the channel from which core is going to be installed | 07:47 |
| pstolowski | fgimenez, nice, thank you. do we have any tests that need to be run manually (e.g. expensive tests?) and are not normally executed on travis? | 07:50 |
| fgimenez | pstolowski: anyway, executing from the branch will give you always an outer version higher than the inner one and the reexec is not going to happen, it would be better IMO to use the external backend and execute against a running machine | 07:52 |
| fgimenez | pstolowski: yes, we are triggering manually tests executed on ubuntu-core systems (this will be done soon on jenkins for most of the archs) | 07:53 |
| pstolowski | fgimenez, yes, i understand the re-exec will not be triggered becuase of that. what do you mean with 'external backend and execute against a running machine'? | 07:53 |
| fgimenez | pstolowski: the external backend lets you connect to an external machine and excute the tests there https://github.com/snapcore/snapd/blob/master/tests/external-backend.md, but if you need your changes in places that wouldn't help (or putting your changes in places could be hard)... i think that just export SPREAD_SNAP_REEXEC=0 is enough | 07:58 |
| mup | PR snapd#3417 closed: httputil,store: extract retry code to httputil, reorg usages <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3417> | 08:00 |
| pstolowski | fgimenez, is there any semi-automatic way of creating a core image with my changes in it, and then simulatic a system with old binaries + this new core and re-exec disabled? | 08:05 |
| pstolowski | s/simulatic/simulating/ | 08:05 |
| zyga | morphis_: you got reply on the factory ML | 08:05 |
| zyga | morphis_: I spoke with jjohansen yesterday and upstreaming is his sole focus | 08:06 |
| zyga | morphis_: but let's make it clear that snapd can work in development mode without strong security, and it is no worse than appimage so we'd like to pursue on all fronts (kernel and userspace) | 08:06 |
| fgimenez | pstolowski: not that i know, you could begin with a image generated with ubuntu-image, copy the binaries built from your branch to it and bind mount them, run the tests and find a way to re bind mount them early enough if any of the tests you run involve a reboot :) | 08:08 |
| morphis_ | zyga: I've answered already | 08:08 |
| morphis_ | zyga: but feel free to reply as well | 08:08 |
| fgimenez | pstolowski: not sure if just the binaries would include all your changes though | 08:09 |
| zyga | morphis_: thank you! | 08:09 |
| morphis_ | zyga: you submitted all PRs we talked about yesterday? | 08:14 |
| zyga | morphis_: no, working on them | 08:14 |
| morphis_ | ok | 08:14 |
| zyga | morphis_: I've started with a regression test before I start to meddle there | 08:14 |
| morphis_ | zyga: can you note them on the forum topic once done? | 08:14 |
| zyga | morphis_: then the refactor | 08:14 |
| zyga | morphis_: and then comments | 08:15 |
| zyga | morphis_: on https://forum.snapcraft.io/t/including-snapd-in-the-opensuse-factory-branch/863/5 ? yes sure! | 08:15 |
| morphis_ | yes! | 08:15 |
| morphis_ | thanks | 08:15 |
| zyga | I commented briefly just now but I will refer to each PR as they show up | 08:17 |
| pedronis | zyga: have you seen this https://forum.snapcraft.io/t/problem-with-installing-canonical-livepatch-service/850 (it doesn't seem specific to livepatch) | 08:46 |
| zyga | pedronis: looking | 08:49 |
| zyga | pedronis: thanks, I'll handle that | 08:51 |
| jjohansen | zyga: not only are we upstreaming, we have made the switch to an upstream first policy. So we won't get in this position again | 08:57 |
| pstolowski | fgimenez, with SPREAD_MODIFY_CORE_SNAP_FOR_REEXEC=0, it's expected some tests to fail (such as reexec-test), right? | 09:03 |
| mup | PR snapcraft#1346 opened: Multi arch build deps <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1346> | 09:04 |
| fgimenez | pstolowski: if you don't combine it with SPREAD_SNAP_REEXEC=0 yes, we use it for instance in SRU validations https://github.com/snapcore/spread-cron/blob/snapd-xenial-sru/run-checks | 09:06 |
| zyga | jjohansen: thank you for re-affirming that! :) | 09:07 |
| pstolowski | fgimenez, i see, thanks | 09:07 |
| mup | PR snapcraft#1347 opened: cli: do not duplicate errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1347> | 09:07 |
| mup | PR snapcraft#1348 opened: Foreign arch src <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1348> | 09:07 |
| sil2100 | Hello! I have some questions regarding classic confinement | 09:10 |
| ogra_ | it is awful, dont use it :P | 09:10 |
| ogra_ | sil2100, i guess caused by my bug ? | 09:10 |
| sil2100 | ogra_: yeah, I just don't seem to understand classic confinement at all | 09:10 |
| ogra_ | sil2100, it is like a deb just differently packaged in the end | 09:11 |
| sil2100 | ogra_: as per your bug, for instance, libparted is present in the snap but it's just not visible | 09:11 |
| sil2100 | ogra_: as everything seems to just look for the libraries in the standard directories, not in the snap ones | 09:11 |
| ogra_ | sil2100, righrt, you would need to hack up wrappers that make the shipped libs used in LD_LIBRARY_PATH | 09:11 |
| sil2100 | ... | 09:11 |
| sil2100 | This is just silly | 09:12 |
| ogra_ | (or just switch back to proper strict confinement ;) ) | 09:12 |
| sil2100 | Yeah, I seriously don't think that doing wrapper hacks is what I would like to have, I guess barry wasn't aware of that | 09:12 |
| ogra_ | it is for special cases where snaps cant really achieve their goal with any of the existing interfaces | 09:12 |
| ogra_ | editors that need access to all of the system for example ... | 09:13 |
| ogra_ | or compilers | 09:13 |
| ogra_ | by default a classic snap will simply get executed like it was a deb ... using the whole rootfs as is ... if you want your libs found you need to specifically mangle LD_LIBRARY_PATH ... prehaps also the python path etc | 09:14 |
| sil2100 | That's a bit too simplistic for our usecase, I'll bring this up at our sprint next week | 09:15 |
| ogra_ | this is alsoo one of the reasons classic only works on ubuntu based distros atm ... else you cant be sure the paths are correct | 09:15 |
| sil2100 | I knew about having access to the whole system, yes, but I thought it's still working similarily to all other snaps by mangling the library paths to point at the snap as well | 09:16 |
| ogra_ | sil2100, http://paste.ubuntu.com/24746613/ is an example | 09:18 |
| Chipaca | zyga: an apparmor DENIED from core's configure related to mounting etc/ssl is probably version skew, yes? | 09:38 |
| zyga_ | hmm | 09:38 |
| zyga_ | let me check but I think so | 09:38 |
| zyga_ | yes | 09:39 |
| zyga_ | apparmor mismatch vs binary | 09:39 |
| Chipaca | ok | 09:39 |
| zyga_ | hacking or production? | 09:39 |
| Chipaca | (i always run snapd with _TESTING so you won't see this in errors) | 09:40 |
| Chipaca | well, always, always on this machine | 09:40 |
| zyga | hmm | 09:43 |
| zyga | dh_install: usr/bin/uboot-go exists in debian/tmp but is not installed to anywhere | 09:43 |
| mup | PR snapcraft#1349 opened: Clarify wording of cross-compilation unsupported error <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1349> | 09:46 |
| * zyga_ has some hectic stuff at home | 09:47 | |
| zyga_ | we're moving TOMORROW | 09:48 |
| pstolowski | zyga, back to Poland? | 09:56 |
| Chipaca | zyga_: <gif of that guy waving his arms around in panic> | 09:58 |
| zyga_ | pstolowski: yes | 09:58 |
| pstolowski | good :) | 09:58 |
| zyga_ | pstolowski: we just ordered the transport as it is in the town next to us and the price is very competetive | 09:58 |
| zyga_ | Chipaca: that'd be my wife | 09:58 |
| Chipaca | :-) | 09:58 |
| zyga_ | we have to pack everything that won't fit into the car now | 09:58 |
| zyga_ | like ... now | 09:58 |
| zyga_ | well | 09:58 |
| mvo | zyga_: woah, goooooood luck! | 09:59 |
| pstolowski | fgimenez, i found out I need compatibility fix also in snap-confine (and in snapctl as discussed yesterday in standup), otherwise those other combinations we test are failing on my new spread test which checks the new feature | 10:02 |
| kunal | Hello community | 10:07 |
| ogra_ | hey kunal | 10:07 |
| kunal | I have a problem... I am trying to build a snap for python script / app | 10:07 |
| kunal | I have read alot of documents but still unable to figure out the solution for some problems | 10:08 |
| kunal | dear community, please help | 10:09 |
| kunal | I need your help | 10:09 |
| zyga_ | pstolowski: apart from the fix, how will people upgrade or downgrade? | 10:09 |
| zyga_ | pstolowski: we learned the hard way that changing formats in snap-confine is not nice or easy | 10:09 |
| kunal | I want to know how to add data folder in snap for my python app because it requires data to run. And all the data is collected in a single folder | 10:11 |
| zyga_ | kunal: read-only data that is distributed with your snap? | 10:12 |
| zyga_ | kunal: just add a part that contains this data | 10:12 |
| ogra_ | have a look at the dump plugin | 10:12 |
| kunal | how to add it in the snap folder | 10:13 |
| kunal | I am sorry to disturb you by asking such kind of stupid questions, but I have already tried that dump plugin and unable to understand how to add the folder | 10:14 |
| zyga_ | kunal: no worries, look at the dump plugin and experiment | 10:14 |
| pstolowski | zyga, for the new feature (snapctl usable not only in hooks) they need latest everything. the second change related to this feature is reanaming of SNAP_CONTEXT var to SNAP_COOKIE. I made compatibility fixes to basically set both and check of existience of either, so that hooks are not affected if re-exec is disabled. does that answer your question? | 10:14 |
| zyga | pstolowski: can people revert from the new feature back to previous release? | 10:15 |
| zyga | pstolowski: I'm mainly asking if this is a flag day change or not | 10:15 |
| kunal | Folder name is dataFolder. So where should I place my dataFolder. Should it be there in src folder or in the top or parent folder | 10:15 |
| zyga | kunal: in your source tree it can be anywhere | 10:16 |
| zyga | kunal: but your snapcraft.yaml must say that it must be installed into the snap | 10:16 |
| zyga | kunal: ogra_'s advice was correct, look at examples of dump plugin | 10:17 |
| zyga | kunal: also if this is a python appication you should be able to install the data throuh python | 10:17 |
| zyga | kunal: good luck | 10:17 |
| kunal | Thanks. But how to point the folder in yaml file so that it can be included in snap | 10:17 |
| zyga | kunal: using a part and the dump plugin, is one way, there are others that may be more straightforward, depending on other parts you use | 10:18 |
| pstolowski | zyga, yes, with the compatibility workarounds I made it's ok to revert. of course a snap which uses the new functionality and calls snapctl from an app will fail and not be able to use the new featue | 10:18 |
| zyga | pstolowski: that's fine | 10:18 |
| zyga | pstolowski: we have some tests missing in revert | 10:18 |
| zyga | pstolowski: when is this scheduled to land? 2.27? | 10:19 |
| pstolowski | zyga, I think it would be pretty useful to have a matrix of all upgrade (and revert) paths that takes snapd + snapctl + snapconfine into account.. i find it difficult to think of these scenarios. and it seems that our recent issues show it's generally hard not to forget about something. perhaps we could have such a matrix as a template to fill in when a new feature is proposed | 10:21 |
| pstolowski | zyga, not scheduled really, but soon once the rename of env var is addressed | 10:21 |
| kunal | Dear Sir, should I write plugin: dump source: . | 10:23 |
| kunal | What should be the destination if I want to keep executable and data folder at the same place so that it can use it as per reference in python script | 10:24 |
| zyga | kunal: https://snapcraft.io/docs/reference/plugins/dump | 10:26 |
| zyga | kunal: but if you have a correctly written python app you don't need dump | 10:26 |
| zyga | kunal: your python's setup.py should install data | 10:26 |
| kunal | how to do it, dear Sir, in setup.py to instruct system to install data files properly at desired place. Please help sir | 10:27 |
| zyga | kunal: this is widely documented on python setuptools project, please look there | 10:28 |
| zyga | kunal: if you have a free software project or wish to share your setup.py that might help | 10:28 |
| zyga | kunal: but I cannot help you in detail today (look above, I'm moving my life to another country) | 10:28 |
| zyga | kunal: needles to say there are 100s of examples of python projects shipping data files around | 10:28 |
| zyga | kunal: and accessing them irrespectively to how they are installed (which is a nice advantage) | 10:29 |
| zyga | kunal: I recommend you to look that up | 10:29 |
| kunal | Thank you so much dera Sir. Thanks alot for giving me your precious time to guide in right direction. Thanks alot dear sir! | 10:30 |
| zyga | good luck :) | 10:30 |
| zyga | and note that you may also try the forum (forum.snapcraft.io) as there are plenty of people snapping software that can help you out | 10:30 |
| zyga | and it works somewhat better across timezones than IRC | 10:30 |
| zyga | many of the snapcraft developers are in the US timezne | 10:30 |
| kunal | Thank you so much sir. Thanks alot..... | 10:31 |
| kunal | Sir, One last question, Please tell me the location where the python executable script or app be installed in snap so that I may take proper reference . | 10:38 |
| zyga_ | kunal: it's variable at runtime, the snap content is mounted in some place and you can look that up via the $SNAP environment variable | 10:39 |
| kunal | so how will it look for the data folder. Will the data folder be also variable at runtime along with its executables | 10:41 |
| zyga_ | what is "the data folder?" | 10:41 |
| kunal | Folder that contain data required by the python script at runtime | 10:43 |
| Chipaca | kunal: for reading, or for reading and writing? | 10:44 |
| * zyga_ hugs Chipaca | 10:44 | |
| Chipaca | zyga_: go pack :-) | 10:44 |
| ogra_ | geez, is he traveleing *again* ? | 10:45 |
| kunal | Sir for both the purpose | 10:45 |
| ogra_ | :) | 10:45 |
| Chipaca | kunal: is this your python code, or are you snapping somebody else's? | 10:45 |
| kunal | My own code. | 10:46 |
| Chipaca | kunal: and is it a daemon (a service), or is it a standalone executable? | 10:46 |
| kunal | I wrote a piece of code used setup.py and made it work . Dear Sir, Its a standalone executable. | 10:47 |
| Chipaca | kunal: and is this data needed across revisions? i.e. if you have revision 1, and refresh to revision 2, do you need to still have that data accessible from revision 2 as it was when last modified by revision 1? | 10:47 |
| kunal | Yes sir | 10:47 |
| zyga_ | Chipaca: I'd not confuse this with data-common-across-revisions (remember that we copy data around so it's fine to just use $SNAP_DATA / $SNAP_USER_DATA for everything) | 10:48 |
| Chipaca | true | 10:48 |
| kunal | i need these data files at runtime. | 10:49 |
| Chipaca | kunal: so, os.getenv("SNAP_USER_DATA") will give you a directory you can read and write to, which is intended for this sort of thing | 10:49 |
| zyga_ | kunal: snaps differentiate immutable "data" that is shipped with the snap and updated with the snap from the writable data (either global or per-user) | 10:49 |
| zyga_ | kunal: e.g. app icon is the former and just goes anywhere in $SNAP (into your snap image) | 10:49 |
| zyga_ | kunal: user preferences are writable and should go to $SNAP_USER_DATA | 10:50 |
| zyga_ | kunal: if you have a service it can keep its mutable state in $SNAP_DATA | 10:50 |
| zyga_ | kunal: and all of those can obviously access anything they want (immutable code and data) stored in $SNAP | 10:50 |
| kunal | Dear sir, May I know , how to set it up to be used by script | 10:50 |
| kunal | How should I add Data Files and Folder to this location while writing yaml file . How to point to these locations | 10:51 |
| zyga_ | kunal: if you struggle with this I'd suggest going through the snapcraft tutorial | 10:53 |
| zyga_ | kunal: as I mentioned the dump plugin is a very simple way of doing what you want | 10:53 |
| zyga_ | kunal: I also suggested that for python you may not need the dump plugin as python plugin can install both code and read-only data | 10:53 |
| zyga_ | kunal: as for writeable data your application must create it relative to the directory pointed by the $SNAP_DATA or $SNAP_USER_DATA environment variables | 10:54 |
| zyga_ | kunal: I suggest that you install hello-world | 10:54 |
| zyga_ | kunal: and play around in the shell, look at where those variables point | 10:54 |
| zyga_ | kunal: good luck :) | 10:54 |
| kunal | Ok sir. Thanks. Now every doubt is clear. Thank you so much sir. and thanks community ... Open Source Community . Thanks alot | 10:55 |
| mup | PR snapcraft#1334 closed: tests: use the fake apt cache in deb unit tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1334> | 11:13 |
| mup | PR snapd#3428 opened: tests: add snap-confine privilege test <Created by zyga> <https://github.com/snapcore/snapd/pull/3428> | 11:18 |
| zyga_ | jdstrand: ^^ | 11:19 |
| zyga_ | morphis_: ^ first PR | 11:26 |
| morphis_ | zyga_: nice! | 11:26 |
| Son_Goku | zyga, morphis_, for snapd 2.27, I'm considering flattening the packaging some more in Fedora | 11:45 |
| Son_Goku | the original reason I kept snap-confine and snapd separate was because there was a separation of C and golang code | 11:45 |
| Son_Goku | but as zyga rewrites more bits from C to Go, it makes less sense | 11:45 |
| morphis_ | Son_Goku: you mean droping the snap-confine package? | 11:46 |
| Son_Goku | yes | 11:47 |
| morphis_ | +1 | 11:47 |
| morphis_ | Son_Goku: btw. if you submit those changes first upstream we can review them together | 11:47 |
| morphis_ | want to do the same with the suse bits in the future | 11:47 |
| Son_Goku | SUSE already works this way | 11:47 |
| morphis_ | it doesn't | 11:48 |
| Son_Goku | it doesn't generate a snap-confine subpackage | 11:48 |
| morphis_ | will still maintain the real .spec file on OBS and have no backported a few changes | 11:48 |
| morphis_ | ah, we're talking about different things :-) | 11:48 |
| Son_Goku | also, the SUSE changes I will submit to OBS first | 11:48 |
| Son_Goku | there's no value in doing it in snapd git | 11:49 |
| Son_Goku | as it does no testing of packaging | 11:49 |
| morphis_ | there is, there we have the entire test suite running | 11:49 |
| zyga_ | Good idea, what do you have in mind specifically? | 11:49 |
| Son_Goku | not helpful when the goal is to change the snapd packaging | 11:49 |
| morphis_ | Son_Goku: we have such upgrade tests for .deb | 11:49 |
| Son_Goku | I'm not touching the debian crap | 11:49 |
| morphis_ | that is not what I mean | 11:49 |
| Son_Goku | it's impossible to figure out what that stuff even does | 11:49 |
| Son_Goku | look, my fixes for the SUSE spec are small things to enable some of the tests that are already enabled in the Fedora package | 11:50 |
| morphis_ | Son_Goku: I simply mean we have an entire spread test suite which verifies a lot of things and once the Fedora spread setup lands you can easily craft your own rpm upgrade tests | 11:50 |
| morphis_ | Son_Goku: great, IMHO it would make sense much easier if we keep the snapd git repo the central place for the suse, fedora, deb packaging bits | 11:51 |
| Son_Goku | morphis_: I'm not worried about Fedora upgrade tests, and I'm not even sure I'm going to do it yet | 11:51 |
| morphis_ | we can then push from there to fedora/obs/.. | 11:51 |
| Son_Goku | hardly | 11:51 |
| Son_Goku | first of all, for that to be possible, we need the first class packaging tests for fedora, suse, etc. | 11:51 |
| Son_Goku | we don't yet | 11:51 |
| Son_Goku | second, snapd git is BROKEN for all distributions except Ubuntu | 11:51 |
| Son_Goku | and I don't foresee that getting fixed soon | 11:52 |
| Son_Goku | maybe in 2.28 | 11:52 |
| Son_Goku | which is a couple of months out | 11:52 |
| morphis_ | Son_Goku: what is broken in master? | 11:52 |
| Son_Goku | seccomp, for one | 11:53 |
| Son_Goku | unless a proper fix was merged in recently | 11:53 |
| morphis_ | what exactly do you mean? | 11:53 |
| Son_Goku | http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd-2.26.1-interfaces-seccomp-allow-bind-for-Fedora.patch | 11:53 |
| Son_Goku | that ^ | 11:53 |
| morphis_ | Son_Goku: you saw https://github.com/snapcore/snapd/pull/3394 ? | 11:53 |
| mup | PR snapd#3394: interfaces/seccomp: add bind() syscall for forced-devmode systems <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3394> | 11:53 |
| Son_Goku | well, no | 11:54 |
| morphis_ | so what else is broken? :-) | 11:54 |
| pedronis | mvo: should snapd#3446 be merged? | 11:54 |
| Son_Goku | I guess at that point nothing that isn't already broken | 11:55 |
| Son_Goku | I'm also not doing the golang flags override in Fedora | 11:55 |
| morphis_ | which one do you mean? | 11:55 |
| Son_Goku | https://github.com/snapcore/snapd/pull/3365/commits/4942a9f9e7c570a44b554d8cc924c9343331ca16 | 11:56 |
| mup | PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365> | 11:56 |
| pedronis | mvo: sorry, should snapd#3426 be merged? | 11:56 |
| mup | PR snapd#3426: release: 2.26.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3426> | 11:56 |
| mvo | pedronis: yes | 11:56 |
| morphis_ | Son_Goku: then you can't drop that single patch, but you know this is a bug only on F25 which is coming from the rpm macros, right? | 11:56 |
| Son_Goku | I'm aware | 11:57 |
| morphis_ | good | 11:57 |
| Son_Goku | if you want, you can switch spread to fedora-26 | 11:57 |
| Son_Goku | then you can drop that | 11:57 |
| morphis_ | we will add a f26 instance too | 11:57 |
| morphis_ | Son_Goku: we could make this conditional for f25 too if you want | 11:58 |
| Son_Goku | it'd be F25 and lower, actually | 11:58 |
| Son_Goku | but yes | 11:58 |
| morphis_ | yes | 11:58 |
| morphis_ | Son_Goku: it's better than keeping this libtool patch | 11:58 |
| Son_Goku | 0%{?fedora} && 0%{?fedora} < 26 | 11:58 |
| Son_Goku | meh, the libtool patch is easy to rebase | 11:58 |
| pedronis | fgimenez: snapd#3414 has 2 +1 but the spread tests have failed | 11:58 |
| mup | PR snapd#3414: tests: show available entropy on error <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3414> | 11:58 |
| morphis_ | it is, but it separates us from what happens in master | 11:59 |
| morphis_ | however if you want to keep it I am fine | 11:59 |
| morphis_ | we should just try to avoid that snapd git and fedora git get out of sync for the .spec file | 11:59 |
| morphis_ | as as soon all changes for the spread setup land developers will be required to touch the .spec file too | 11:59 |
| Son_Goku | you think they will? | 11:59 |
| morphis_ | otherwise CI will break :-) | 12:00 |
| Son_Goku | I'd be surprised to see mvo generating changelogs for the spec files in parallel to the debian/changelog file | 12:00 |
| morphis_ | Son_Goku: I am not talking about changelogs | 12:00 |
| morphis_ | but all the other packaging bits | 12:00 |
| Son_Goku | I know | 12:00 |
| Son_Goku | but it'd be surprising if that happened too ;) | 12:01 |
| pedronis | mvo: also snapd#3413 could go in with a 2nd pass from you (if the tests pass) | 12:01 |
| Son_Goku | I'd initialize the repository with tito if tito supported spec files in subdirs :/ | 12:01 |
| mup | PR snapd#3413: tests: fix for econnreset test checking that the download already started <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3413> | 12:01 |
| morphis_ | zyga_: joining us? | 12:02 |
| fgimenez | pedronis: thx, looking | 12:05 |
| fgimenez | pedronis: yes, not related to this PR but we are getting quite a few errors related to reexec lately "re-exec disabled by user" https://travis-ci.org/snapcore/snapd/builds/237854333#L1281 | 12:07 |
| pedronis | some test not restoring something properly and order issues? | 12:08 |
| pstolowski | fgimenez, I've pushed one more compatibility workaround to my branch (the one mentioned earlier). | 12:10 |
| fgimenez | pedronis: no idea, we are getting those random errors, i've checked some reexec variants and they happen after reexec0 and reexec1, maybe there's another place where this is changed | 12:15 |
| fgimenez | pstolowski: ok thanks, btw let me know how can i help with the testing matrix you mentioned, we have some scenarios for reexec currently being executed in spread-cron and maybe we could extend them with more checks, or create new ones from scratch | 12:16 |
| fgimenez | pstolowski: tbh i still don't understand why the test prepare doesn't fail in your when SNAP_CONTEXT is set, the inner and outer binaries should understand SNAP_COOKIE and ignore SNAP_CONTEXT, not sure what is left behind that makes things go well when SNAP_CONTEXT is set | 12:19 |
| fgimenez | doesn't fail in your branch | 12:19 |
| pedronis | well edge has something that understand only SNAP_CONTEXT | 12:20 |
| pedronis | atm | 12:20 |
| fgimenez | pedronis: but in prepare we modify the core snap and put in place the outer binaries, maybe i'm missing something | 12:21 |
| pstolowski | fgimenez, but we modify it too late | 12:23 |
| pedronis | fgimenez: yes, but as pstolowski explained before we do that we do snap install --"$CORE_CHANNEL" core | 12:23 |
| pedronis | that ends up using the snapctl from edge core I think (because of the configure hook) | 12:24 |
| fgimenez | pstolowski: i'm trying locally modifying it before calling "snap set core.." and the error is the same | 12:24 |
| pstolowski | yes | 12:24 |
| pedronis | install core will call the hook already | 12:24 |
| pedronis | not need to do a set | 12:24 |
| pedronis | to trigger that | 12:25 |
| pstolowski | fgimenez, yes, as pedronis says | 12:25 |
| pedronis | which thinking of it is all a bit weird | 12:25 |
| pedronis | anyway | 12:26 |
| fgimenez | pedronis: yes, but that doesn't trigger the error, the errors on install seem to be ignored | 12:27 |
| pedronis | that doesn't make sense to me | 12:27 |
| pedronis | we don't ignore configure errors | 12:28 |
| pedronis | afaik | 12:28 |
| pstolowski | fgimenez, about the upgrade path matrix.. one scenario that would be nice to test is: old versions in the system, newest versions shipped with core, but re-exec disabled. the new feature will not work but hooks shouldn't break | 12:28 |
| fgimenez | pedronis: the error happens only after snap set from what i'm seeing here, let me paste a log | 12:28 |
| pstolowski | fgimenez, I saw prepare failed | 12:28 |
| abeato | hey, is it possible to specify a concrete core snap revision in "snap prepare-image"? or to use a local core snap? | 12:31 |
| fgimenez | pedronis: i'm using a prepare.sh like this one http://paste.ubuntu.com/24748009/ to make sure that update_core_snap_for_classic_reexec is called before "snap set" (around line 140) | 12:32 |
| pedronis | abeato: yes, to the 2nd just --extra-snaps core.snap , to the first kind of , if you have it around already and it came from the store then you can again using --extra-snap core.snap with a recent enough snap which IÂ don't know if it's the case or not with ubuntu-image | 12:33 |
| abeato | pedronis, ok, 2nd option is good enough for me, thanks! | 12:34 |
| pedronis | sorry what IÂ meant the version of snap (the binary) shipped with ubuntu-image needs to be recent enough | 12:34 |
| fgimenez | pedronis: with that in place i get a log like this after the error http://paste.ubuntu.com/24748007/ (with some additional debug info added) the configure hooks errors on install doesn't make the test to stop, the final error at the end is after "snap set core refresh.schedule="$(date +%a --date=2days)@12:00-14:00"" | 12:35 |
| abeato | pedronis, but if I use a local fine, there will be any issue with assertions? as you get some of them when dowloading from the store | 12:35 |
| abeato | *local file | 12:35 |
| pedronis | abeato: well, it wil be unasserted so no updates | 12:35 |
| abeato | pedronis, ok, I see | 12:35 |
| pedronis | unelss as I said the .snap came from the store then ubuntu-image finds the assertions anyway | 12:35 |
| abeato | ah, good | 12:36 |
| pedronis | but this is implemented by snap prepare-image only recently | 12:36 |
| pedronis | and IÂ lost a bit track what is shipped where | 12:36 |
| abeato | ok, I will just try, thanks | 12:36 |
| pedronis | fgimenez: something seems really weird, IÂ don't understand why we don't die on that first error | 12:38 |
| pstolowski | fgimenez, can you share the log too? | 12:40 |
| fgimenez | pstolowski: sure, this is spread's log http://paste.ubuntu.com/24748076/ | 12:42 |
| fgimenez | and the corresponding journalctl (the other one was from a previous execution) http://paste.ubuntu.com/24748082/ | 12:44 |
| pedronis | anyway a --debug run one test should show where we die | 12:46 |
| fgimenez | pedronis: looks like the "ERROR ignoring failure in hook "configure"" comes from https://github.com/snapcore/snapd/blob/master/overlord/hookstate/hookmgr.go#L243 | 12:48 |
| pstolowski | fgimenez, right.. i see we set ignoreerror flag for configure hook depending on some state flags | 12:50 |
| mup | PR snapd#3413 closed: tests: fix for econnreset test checking that the download already started <Created by sergiocazzolato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3413> | 12:51 |
| pedronis | ah, yes | 12:51 |
| pedronis | only for core | 12:51 |
| pedronis | because confgure hook of core gave us so much grief trying to update core | 12:52 |
| mvo | thanks pedronis | 12:55 |
| pstolowski | fgimenez, ok.. i don't understand why it's failing after you copied new binaries into core | 12:56 |
| fgimenez | pstolowski: no idea, i've double checked that the only snapctl files in the testbed are the inner and outer ones, and that the md5sum is the same | 12:58 |
| pstolowski | fgimenez, just to double-check, what's the latest commit id from my branch you're testing? can you push the changes you made to the scripts or send me a diff? | 13:00 |
| fgimenez | pstolowski: sure 1sec | 13:01 |
| pstolowski | fgimenez, after standup is ok ;) | 13:01 |
| zyga_ | Chipaca: standup? | 13:01 |
| Chipaca | yeap | 13:02 |
| mup | PR snapd#3392 closed: interfaces: add minimal seccomp resolver to avoid backward compatiblity issues <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3392> | 13:17 |
| mup | PR snapd#3407 closed: interfaces: move seecomp profiles to /var/lib/snapd/seccomp/profiles-v2/ <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3407> | 13:17 |
| zyga_ | hmmm | 13:30 |
| zyga_ | hangouts froze for me | 13:30 |
| pstolowski | zyga, for me tto | 13:31 |
| pstolowski | zyga, i can't reconnect... | 13:31 |
| Chipaca | oh nice | 13:31 |
| Chipaca | now it kicked me | 13:31 |
| Chipaca | is it sso o'clock | 13:31 |
| pstolowski | no sso prompt, just spinning | 13:32 |
| mup | PR snapd#3429 opened: interfaces/snapd-control: also allow use of /usr/bin/snap <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3429> | 13:42 |
| pedronis | niemeyer: is this one snapd#3418 | 13:53 |
| mup | PR snapd#3418: tests: prefer ipv4 over ipv6 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3418> | 13:53 |
| pedronis | needs 2nd review and now it's green finally, well or green enough at least | 13:53 |
| mup | PR snapd#3430 opened: tests: modify core before calling set <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3430> | 13:55 |
| fgimenez | pstolowski: this is the patch http://paste.ubuntu.com/24748672/, i've executed after pulling again your branch (and removing the compatibility changes) and got the same error, somehow snapctl still doesn't understand SNAP_COOKIE | 14:03 |
| niemeyer | pedronis: Cheers! | 14:03 |
| pstolowski | fgimenez, thanks, i'll look into it | 14:04 |
| niemeyer | fgimenez: Why the full block instead of just echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf? | 14:04 |
| fgimenez | thank you pstolowski | 14:04 |
| pedronis | niemeyer: because that's what "man gai.conf" tells to do | 14:04 |
| pedronis | it doesn't add , it replaces the whole table | 14:05 |
| niemeyer | pedronis: That doesn't sound like a good reason :) | 14:05 |
| fgimenez | niemeyer: yep pedronis suggested it "the presence of a single precedence line in the configuration file causes the default table to not be used" | 14:05 |
| pedronis | niemeyer: because the RFC also suggested the change in terms of an update table | 14:05 |
| fgimenez | niemeyer: and we just want to change one of them? | 14:05 |
| pedronis | and just putting in a single precedence doesn't produce that | 14:06 |
| pedronis | s/update table/updated table/ | 14:06 |
| niemeyer | pedronis: I'm not reading that there | 14:07 |
| niemeyer | pedronis: Specifically, "Complete absence of data of one kind causes the appropriate default information to be used." | 14:08 |
| pstolowski | fgimenez, can you give me last commit id you're using? git log -n1 ? | 14:08 |
| niemeyer | pedronis: Note the "of one kind" | 14:08 |
| fgimenez | pstolowski: the last two are merges and conflic resolutions, the next is 5da6cd162745d96120fa2dadc2beba4e3dbeba93 "Further compatibilty changes to support SNAP_CONTEXT in transition period." | 14:09 |
| pedronis | niemeyer: Once again, the presence of a single precedence line in the configuration file causes the default table to not be | 14:09 |
| pedronis | used. | 14:09 |
| niemeyer | pedronis: You said this was in the manual.. I can't find it.. | 14:09 |
| pedronis | that line is in man of gai.conf | 14:10 |
| niemeyer | pedronis: What I'm reading, also from the documentation, is what I pasted above, which means something else | 14:10 |
| pedronis | niemeyer: are we reading different versions of the docs | 14:11 |
| pedronis | ? | 14:11 |
| pedronis | because IÂ don't see that "one kind" bit | 14:11 |
| niemeyer | pedronis: Maybe.. can you paste what yours says? | 14:11 |
| niemeyer | pedronis: THis is in the docs in the configuration file | 14:11 |
| pedronis | niemeyer: ? | 14:12 |
| niemeyer | pedronis: Sorry, I don't know what the question is | 14:12 |
| pedronis | niemeyer: why you think your sentence help | 14:12 |
| pedronis | if one present in there then the info is not missing | 14:12 |
| Chipaca | mwhudson: BTW, the locks around clone/exec make the EAGAIN not happen, for me. If you (or anybody) can confirm this, and you backport this, you can probably un-backport the other | 14:12 |
| pedronis | so the default table is not used | 14:12 |
| Chipaca | mwhudson: (this confirms the original hypothesis about why those eagains were happening, fwiw) | 14:13 |
| pedronis | niemeyer: also see https://www.rfc-editor.org/rfc/rfc3484.txt "10.3. Configuring Preference for IPv6 or IPv4" | 14:13 |
| niemeyer | pedronis: Because so far I found nothing saying "the default is not used" | 14:13 |
| pedronis | niemeyer: man gai.conf | 14:13 |
| niemeyer | pedronis: The RFC is irrelevant.. this is a configuration file which modifies an implementation detail | 14:13 |
| niemeyer | pedronis: There's a default table in glib proper | 14:13 |
| niemeyer | glibc | 14:13 |
| pedronis | precedence netmask precedence | 14:14 |
| pedronis | This keyword is similar to label, but instead the value is added to the precedence table as specified in RFC 3484. | 14:14 |
| pedronis | Once again, the presence of a single precedence line in the configuration file causes the default table to not be | 14:14 |
| pedronis | used. | 14:14 |
| pedronis | this is compatible also with the the first lines in gai.conf which sort of refers to the reverse | 14:14 |
| niemeyer | pedronis: Ok, thanks.. I missed that part.. | 14:15 |
| niemeyer | pedronis: I was basing my assumption on the documentatino provided in gai.conf itself | 14:15 |
| niemeyer | and in my own experience doing the simple addition, which does work | 14:15 |
| niemeyer | Perhaps for non-obvious reasons | 14:15 |
| pedronis | it's all a bit unclear | 14:15 |
| pedronis | it's a bit bad that there's no command to print the actual table | 14:16 |
| pedronis | that will be used | 14:16 |
| pedronis | afaict | 14:16 |
| pedronis | but the full table should be good because is also what's listed in the RFC | 14:16 |
| pedronis | to achieve this | 14:16 |
| niemeyer | pedronis: It's probably safer as well considering we're dealing with mulitple images | 14:16 |
| pedronis | yes | 14:16 |
| niemeyer | (which might have different values) | 14:16 |
| niemeyer | pedronis: Anyway, thanks, learned something | 14:17 |
| pedronis | yes, it would best if you could do punctual changes, but the explanation for the docs sounds like is not possible, is either or the defaults or start from scratch | 14:19 |
| pedronis | s/or the/the/ | 14:19 |
| mup | PR snapd#3418 closed: tests: prefer ipv4 over ipv6 <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3418> | 14:24 |
| mvo | pedronis: if someone can ack 3426 we can merge that one too | 14:27 |
| mup | PR snapcraft#1329 closed: tour: use https for source urls <Created by tim-sueberkrueb> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1329> | 14:29 |
| mup | PR snapcraft#1350 opened: Rust rust: Add support for cross-compilation <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1350> | 14:29 |
| mup | PR snapd#3426 closed: release: 2.26.4 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3426> | 14:30 |
| abeato | zyga, finally got a good test run for https://github.com/snapcore/snapd/pull/3353 , time for merging? | 14:32 |
| mup | PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353> | 14:32 |
| fgimenez | pedronis: mvo niemeyer snapd#3408 is only missing one review (green with some autopkgfailures) | 14:32 |
| mup | PR snapd#3408: tests: add alsa interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3408> | 14:32 |
| niemeyer | Looking | 14:33 |
| fgimenez | and it would be great to have snapd#3348 landed too, so that we can put in place the spread-cron branches for executing it | 14:34 |
| mup | PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348> | 14:34 |
| mup | PR snapcraft#1344 closed: git: don't use --remote for updating submodules <Created by Saviq> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1344> | 14:35 |
| daker | hey popey, can i PM you (snap testing)? | 14:35 |
| popey | of course, anytime | 14:36 |
| morphis_ | niemeyer: do you have time for another look at https://github.com/snapcore/snapd/pull/3365 ? | 14:42 |
| mup | PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365> | 14:42 |
| niemeyer | morphis_: Yep | 14:42 |
| morphis_ | niemeyer: awesome! I have a few more you had comments on but lets start with that one | 14:43 |
| mup | PR snapd#3408 closed: tests: add alsa interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3408> | 14:43 |
| aisrael | I could use a sanity check. I'm trying to get an Adafruit PiTFT touchscreen working with Ubuntu Core. It looks like I need to build a kernel snap to pull in Adafruit's PiTFT kernel. Does that sound right, or am I overlooking another solution? | 14:51 |
| mup | PR snapcraft#1351 opened: cli: remove double congrats messaging <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1351> | 14:53 |
| niemeyer | morphis_: Are there tests enabled? | 14:53 |
| niemeyer | morphis_: For fedora? | 14:53 |
| morphis_ | niemeyer: a single one | 14:53 |
| morphis_ | tests/main/help | 14:53 |
| morphis_ | enabling a lot more is another PR | 14:53 |
| morphis_ | https://github.com/snapcore/snapd/pull/3411 | 14:54 |
| mup | PR snapd#3411: tests/main: enable a first set of test cases for Fedora and openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3411> | 14:54 |
| niemeyer | morphis_: I'd prefer to invert the logic then: whitelist the one test | 14:54 |
| niemeyer | morphis_: Instead of blacklisting every single one | 14:54 |
| morphis_ | niemeyer: how? when I tried to blacklist the suite none of the suite tests were considered no matter if whitelisted or not | 14:54 |
| niemeyer | morphis_: That'd be a bug in spread.. let me try to reproduce | 14:55 |
| fgimenez | pstolowski: fwiw the debs built from your branch (including the compatibility changes) work great on classic xenial (with a previous core from stable) http://paste.ubuntu.com/24749105/ | 14:57 |
| morphis_ | niemeyer: https://github.com/snapcore/snapd/pull/3365/files#r119012848 | 14:57 |
| mup | PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365> | 14:57 |
| pstolowski | fgimenez, great! thanks for checking that | 14:57 |
| morphis_ | niemeyer: that is what I get with the suite blacklisted and a single test below whitelisted | 14:58 |
| pstolowski | fgimenez, btw, i've reproduced the failure with your diff and investigating it | 14:58 |
| fgimenez | pstolowski: without the compatibility changes i get this error http://paste.ubuntu.com/24749114/ (even when it seems to not being reexec-ing, snap version seems to report the outer) | 14:58 |
| fgimenez | pstolowski: great thanks! | 14:58 |
| niemeyer | morphis_: Worked fine here | 15:01 |
| morphis_ | niemeyer: hm, you have a newer spread version? | 15:01 |
| morphis_ | hm, spread -v does not exist | 15:01 |
| mvo | Chipaca: can you walk me through the process of contributing to go? https://github.com/golang/go/issues/20556 is what I need | 15:01 |
| morphis_ | niemeyer: 2017.01.30 is what I used | 15:02 |
| niemeyer | https://www.irccloud.com/pastebin/dPGI43zd/ | 15:02 |
| morphis_ | hm | 15:03 |
| niemeyer | morphis_: That sounds super old | 15:03 |
| niemeyer | morphis_: Most likely the issue | 15:03 |
| morphis_ | niemeyer: that is what is in the store .. :-) | 15:03 |
| niemeyer | morphis_: Let me update that then | 15:04 |
| niemeyer | Interesting that my snapcraft.yaml says 2017.04.25, which is up-to-date.. I probably screwed up by not uploading | 15:04 |
| morphis_ | niemeyer: time to use build.snapcraft.io :-) | 15:05 |
| niemeyer | Yes! | 15:05 |
| morphis_ | then we have at least an up to date version in edge | 15:05 |
| morphis_ | niemeyer: btw. what about moving the spread snap to be a classic snap? | 15:05 |
| morphis_ | that way we could easily use it together with kvm | 15:05 |
| morphis_ | form the host | 15:05 |
| niemeyer | morphis_: Might be a good idea | 15:06 |
| morphis_ | great | 15:06 |
| niemeyer | morphis_: Ok, rev 28 is up | 15:06 |
| niemeyer | morphis_: Please give it a shot and let me know | 15:06 |
| morphis_ | niemeyer: will do | 15:06 |
| morphis_ | niemeyer: ok, then you vote for changing that, fine for me | 15:06 |
| morphis_ | niemeyer: any other comments? | 15:06 |
| niemeyer | morphis_: Yeah, it makes more sense for that status of the PR | 15:07 |
| niemeyer | morphis_: Otherwise you'll immediately break every other spread PR that is up for review, for example | 15:07 |
| pedronis | mvo: interesting x/net, might take a while | 15:07 |
| pstolowski | fgimenez, right. this is because without these compatibility fixes we don't have env variable set. i may need to think if this shouldn't lead to some ohter error | 15:07 |
| niemeyer | morphis_: No, I think we're aligned about the rest | 15:07 |
| morphis_ | good, so can you approve based on that or do you want to review again on Monday? | 15:08 |
| mvo | pedronis: yeah, need to sign the CLA there I guess, anyways, it took me a little bit to figure this one out, I though I just did the byte packing wrong myself | 15:10 |
| fgimenez | mvo: i just got this error on pi2 http://paste.ubuntu.com/24749264/ (test scenario beginning with stable, refreshing to beta and excuting the suite) if you could take a look that would be great | 15:18 |
| mup | PR snapd#3431 opened: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431> | 15:18 |
| mvo | fgimenez: woah | 15:18 |
| mvo | fgimenez: are you in the machine? if so, what does "ls -l /snap/core/current/usr/lib/snapd/snap-confine" show? maybe there is a refresh going on at the same time and current is not valid? that is a bit of a strange one | 15:19 |
| fgimenez | mvo: the execution hasn't finished yet, let me check on another session | 15:20 |
| mvo | fgimenez: thank you, strange that /snap/core/current/usr/lib/snapd/snap-confine is not there. the logs do not indicate a refresh so that is porbably not it | 15:20 |
| fgimenez | mvo: http://paste.ubuntu.com/24749363/ | 15:25 |
| mvo | fgimenez: do you see an apparmor denial in syslog? | 15:26 |
| mvo | fgimenez: what happens if you run on this shell su test -c 'sh -c "SNAP_NAME=test-snapd-tools /snap/core/current/usr/lib/snapd/snap-confine snap.test-snapd-tools.cmd /bin/true " ? | 15:26 |
| fgimenez | mvo: seems to be empty now, the suite is still running... | 15:27 |
| mvo | fgimenez: with correct quoting | 15:27 |
| mvo | (sorry for that paste error) | 15:27 |
| fgimenez | mvo: yep, i've tried, complains about elevated permissions, let me paste the output | 15:28 |
| mvo | fgimenez: ok, strange, could you re-run this test once the suite finished? | 15:28 |
| fgimenez | mvo: http://paste.ubuntu.com/24749391/ sure, will let you know how it goes, thx! | 15:29 |
| mvo | fgimenez: this looks ok, odd | 15:30 |
| mvo | jdstrand: I get a build failure of snap-confine on arm on artful, https://launchpadlibrarian.net/322177974/buildlog_ubuntu-artful-armhf.snapd_2.26.4+17.10_BUILDING.txt.gz - it looks like /lib/arm-linux-gnueabihf/libapparmor.a have changed and no longer allow static linking. do you happen to know anything about this? | 15:50 |
| jdstrand | mvo: I do not. I saw the forum post. tyhicks or sbeattie might have an idea | 16:06 |
| jdstrand | tyhicks, sbeattie: https://forum.snapcraft.io/t/build-failure-for-2-26-4-on-artful-on-arm-arm64/866 | 16:07 |
| jdstrand | otoh idk if new defaults are being used in artful that would trigger that | 16:08 |
| pstolowski | fgimenez, that error you found is curious, still haven't found what's causing it | 16:08 |
| jdstrand | tyhicks: if you need me to dig into that instead of you or Steve, let me know and I can take a look after appt/lunch | 16:08 |
| tyhicks | sbeattie: your wiki page (https://wiki.ubuntu.com/SecurityTeam/PIE) suggests to me that apparmor simply needs a no-change rebuild now that PIE is enabled by default on armhf/arm64 - does that sound right to you? | 16:11 |
| tyhicks | (specifically, the "Relocation Linking Failure" section) | 16:11 |
| fgimenez | thank you pstolowski, don't spend too much time on it, maybe somehting is wrong with the tests, i'll take a look on monday | 16:16 |
| pstolowski | fgimenez, no no, thank YOU! I want to understand why this is happening. maybe it's a sign of a bug. all binaries the same, should work | 16:16 |
| tyhicks | sbeattie: I followed up in the forum - please post there if you have any corrections to make to my advice | 16:16 |
| fgimenez | pstolowski: yep, it's super weird | 16:17 |
| zyga | jdstrand: I commented on https://github.com/snapcore/snapd/pull/3428 and fixed it on Debian (secure path doesn't have /snap/bin, bummer) | 16:24 |
| mup | PR snapd#3428: tests: add snap-confine privilege test <Created by zyga> <https://github.com/snapcore/snapd/pull/3428> | 16:24 |
| mvo | tyhicks: thanks a bunch, if a rebuild would be enough, that sounds great. if sbeattie is of the same opinion I can do a no-change build1 upload if wanted (or let you guys handle it, either way works for me :) | 16:31 |
| tyhicks | mvo: feel free to do a quick no-change yourself once sbeattie chimes in | 16:32 |
| * Chipaca out | 17:20 | |
| Chipaca | o/ EOW \o/ | 17:21 |
| om26er | Hi! Is there a way for my code to check if its running inside a snap ? | 18:53 |
| nacc | om26er: i'm not sure. Why do you want that? Sort of defeats the purpose/goal it seems :) | 18:54 |
| om26er | nacc, our code reads /var/lib/dbus/machine-id on a normal linux system but inside a snap that path is not available, we have a fallback mechanism, but I want to do something better than just a try/except | 18:55 |
| mup | PR snapd#3432 opened: tests: clean journalctl logs on trusty <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3432> | 18:56 |
| nacc | om26er: try/except seems totally reasonable (to handle an assumed path not existing). or do you mean the try/except is too broad and reflects only that path not existing, not whether you are in a snap or not? | 18:57 |
| om26er | nacc, right, the former | 18:58 |
| nacc | om26er: i don't know, sorry -- i'm not sure there is a way to detect 'in a snap' explicitly | 19:01 |
| ogra_ | om26er, chek your env ;) | 19:02 |
| ogra_ | *check | 19:02 |
| ogra_ | there is tons of things | 19:02 |
| nacc | ogra_: that does make sense, even for things like SNAP_ | 19:03 |
| ogra_ | yep | 19:03 |
| nacc | ogra_: but is there a 'canonical' (little c) way? | 19:03 |
| nacc | ogra_: checking the env seems ... iffy, only because the env can be manipulated (it's more of a hint than an assertion to me) | 19:04 |
| ogra_ | true ... | 19:04 |
| ogra_ | dunno if there is a more canonical way | 19:04 |
| nacc | i guess om26er could do ... try / except, in the except check if SNAP_ is defined and then assuem it's a snap | 19:04 |
| om26er | ogra_, its a production software so which the most reliable (not likely to change) env var, if you were to suggest ? | 19:04 |
| ogra_ | i'd just check if $SNAP is set | 19:05 |
| ogra_ | you can easily take a look by "snap install hello-world; hello-world|grep SNAP" | 19:05 |
| ogra_ | err | 19:05 |
| ogra_ | "snap install hello-world; hello-world.env|grep SNAP" | 19:06 |
| * nacc wonders if one days we'll have a snap-ok command like kvm-ok to tell us we are in a snap | 19:06 | |
| nacc | or there was another one that told you you were in a VM | 19:06 |
| ogra_ | in-container ? | 19:06 |
| ogra_ | or some such | 19:06 |
| om26er | on a different note, is there a way to read /var/lib/dbus/machine-id inside a confined snap ? | 19:06 |
| nacc | ogra_: yeah that sounds familiar | 19:06 |
| nacc | om26er: are you able to if you connect to the dbus interface? | 19:07 |
| om26er | nacc, do you mean "you are able to if you connect dbus interface" ? | 19:07 |
| nacc | om26er: i meant, (sorry for the bad typing) -- if you connect to the dbus interface, are you able to read /var/lib/dbus/machine-id ? | 19:08 |
| nacc | om26er: it was a question, honestly -- i don't know (and can't tell immediately from reading the snapcraft docs) | 19:08 |
| om26er | of the top of my head, I think that path should not be available to a confined snap, but maybe ogra_ can confirm. | 19:09 |
| nacc | om26er: right it won't be, i agree -- but if you connect to an interface that allows it, maybe it would be | 19:09 |
| om26er | *even with dbus interface connected. But that's just my limited understanding of Ubuntu Core. | 19:09 |
| nacc | om26er: but i dont' know what the dbus interface exposes exactly :) | 19:10 |
| ogra_ | https://github.com/snapcore/snapd/blob/master/interfaces/builtin/dbus.go doesnt give any file access it seems ... only actual bus access ... | 19:10 |
| nacc | om26er: do you use this file to generate a unique key or something? | 19:10 |
| nacc | ogra_: oh i see, it's for registering to be on/listen on dbus | 19:10 |
| ogra_ | yep | 19:11 |
| om26er | nacc, that file is automatically generated with a unique ID, when the system starts for the first time, doesn't change during the lifetime of an install as I understand. | 19:11 |
| ogra_ | and no, a snap can not see /var/lib/dbus/machine-id | 19:11 |
| nacc | om26er: right -- that still doesn't tell me why you need it? :) | 19:11 |
| om26er | nacc, reason: http://0pointer.de/blog/projects/ids.html | 19:11 |
| nacc | om26er: fwiw, on ubuntu that file is just a symlink to /etc/machine-id :) | 19:12 |
| ogra_ | also note that the /var/lib/dbus/machine-id gets explicitly removed from the core snap at build | 19:13 |
| ogra_ | ogra@styx:~$ LC_ALL=C ls -l /snap/core/current/var/lib/dbus/ | 19:13 |
| ogra_ | total 0 | 19:13 |
| nacc | ogra_: ah interesting | 19:13 |
| nacc | ogra_: why is that? (if you know) | 19:13 |
| ogra_ | (else all core snaps would have the same ID) | 19:13 |
| nacc | ogra_: ah right | 19:14 |
| nacc | ogra_: probably similar to containers issue | 19:14 |
| om26er | apparently /etc/machine-id comes from systemd, so maybe I could somehow ask it. | 19:14 |
| ogra_ | if the core snap is not used as rootfs, the file wont be there .... on an ubuntu core image it gets created on first dbus startup | 19:14 |
| om26er | in a python/dbus way | 19:14 |
| om26er | hmmm.. | 19:15 |
| nacc | ogra_: that makes sense | 19:15 |
| ogra_ | yeah, you can probably use the dbus to actually query for it | 19:15 |
| nacc | yeah, i wonder if you can use the API (or do what the API does) to query dbus | 19:16 |
| ogra_ | if your snap is actually confined that would in any case be the better way ... the snap is executed on top of the core snap ... but the dbus you connect to is the actual hosts dbus ... and *that* has a mschine ID | 19:17 |
| ogra_ | (while the file would never be visible even if you run unconfined) | 19:17 |
| nacc | ogra_: yep, that's the right abstraction to operate at, it seems | 19:18 |
| nacc | om26er: with, based upon that post, maybe a fallback to the filesystem if that dbus query fails (for some reason) | 19:18 |
| om26er | ogra_, making it a strict snap is the aim. | 19:19 |
| ogra_ | i was assuming so :) | 19:19 |
| Flagada | Hello I'm Trying to install Ubuntu Core 16 with KVM. I got a "Creating user failed" when I enter my SSO email adress | 19:22 |
| om26er | ogra_, is the behaviour going to be the same on Ubuntu Core and classic ubuntu install with snapd ? | 19:22 |
| Flagada | Someone can help me with that? | 19:22 |
| om26er | nacc, I guess that's what I'd have to go for. | 19:23 |
| ogra_ | om26er, yep | 19:23 |
| cachio | niemeyer, 2017-06-02 19:29:33 Error preparing linode:ubuntu-core-16-64:tests/main/ : kill-timeout reached, cannot reconnect to linode:ubuntu-core-16-64 (Spread-09) after reboot: dial tcp 50.116.46.101:22: i/o timeout | 19:37 |
| cachio | niemeyer, it just happened | 19:37 |
| cachio | the machine is lost | 19:38 |
| cachio | no ping no ssh | 19:38 |
| cachio | niemeyer, seem to be a problem of linode | 19:38 |
| cachio | niemeyer, perhaps spread could allocate another machine when that happens or move the current task to another one | 19:45 |
| === nacc_ is now known as ancc | ||
| === ancc is now known as nacc | ||
| mup | PR snapcraft#1338 closed: go plugin: Add support for cross-compilation <enhancement> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1338> | 20:14 |
| pmatulis | how does one specify what "track" to install? | 20:47 |
| om26er | assuming track == channel, use --track_name e.g. snap install hello-world --edge. If otherwise, please ignore my comment. | 20:49 |
| om26er | pmatulis, ^ | 20:49 |
| nacc | pmatulis: track/channel, iirc | 20:50 |
| nacc | https://snapcraft.io/docs/reference/channels | 20:50 |
| nacc | pmatulis: down in the "installing a snap" section, first example | 20:50 |
| nacc | om26er: tracks are new | 20:51 |
| om26er | nacc, thanks, reading into it now. | 20:52 |
| nacc | om26er: np, niemeyer's forum post (looking for it now to share) is pretty helpful too | 20:53 |
| nacc | GitUbuntuRepository: optimize treeishs_identical | 20:53 |
| nacc | 20:53 | |
| nacc | If we can peel() to treeishs, we can just compare the hashes. | 20:53 |
| nacc | bah | 20:53 |
| nacc | https://forum.snapcraft.io/t/channel-terminology-and-policy/551 | 20:53 |
| pmatulis | i thought *channels* and *tracks* were distinct | 20:54 |
| pmatulis | where a channel was akin to a series (2.0, 2.1) and a track was the level of development (experimental, devel, stable) | 20:55 |
| nacc | pmatulis: they are distinct | 20:56 |
| nacc | track/risk/branch is what niemeyer's post says | 20:56 |
| pmatulis | i still don't know how to specify the channel | 21:04 |
| pmatulis | :( | 21:04 |
| nacc | pmatulis: i told you above? (and it was in the link) | 21:04 |
| pmatulis | not really | 21:05 |
| nacc | snap install <snap> --channel=<track/channel> | 21:05 |
| pmatulis | where is that in the page you linked to? | 21:05 |
| nacc | pmatulis: as i said, "down in the "installing a snap" section, first example" | 21:06 |
| nacc | pmatulis: on https://snapcraft.io/docs/reference/chan | 21:06 |
| nacc | pmatulis: on https://snapcraft.io/docs/reference/channels, rather | 21:06 |
| pmatulis | ohh | 21:06 |
| pmatulis | i was looking at the other one | 21:06 |
| pmatulis | forum whatever | 21:06 |
| nacc | pmatulis: ah sorry, two different links | 21:07 |
| pmatulis | it's odd. i think it depends how some snaps are actually made | 21:10 |
| pmatulis | for instance, this doesn't work: | 21:10 |
| pmatulis | sudo snap install maas --channel=latest/stable | 21:11 |
| pmatulis | even though: | 21:11 |
| pmatulis | snap info maas | grep latest/stable | 21:11 |
| pmatulis | latest/stable: 2.2.0+bzr6057-snap (91) 98MB - | 21:11 |
| nacc | pmatulis: interesting, '--channel=stable' does work though | 21:12 |
| pmatulis | yeah | 21:12 |
| nacc | pmatulis: i *wonder* if the snap we are running isn't aware of tracks? | 21:12 |
| pmatulis | that's the thing. it depends on how it's made | 21:13 |
| pmatulis | which isn't great at all | 21:13 |
| nacc | pmatulis: i think it (obviously) depends on `snap` support | 21:15 |
| nacc | pmatulis: is that what you mean by 'it'? | 21:15 |
| nacc | pmatulis: oddly, the changelog for snapd in 17.04 (what i'm on) only mentions: | 21:17 |
| nacc | - many: show available "tracks" in `snap info` | 21:17 |
| nacc | pmatulis: i also wonder, if (*big* if) that if there's only one track -- that it doesn't work | 21:18 |
| nacc | pmatulis: to specify a track, i mean | 21:18 |
| pmatulis | right, no idea | 21:19 |
| nacc | pmatulis: i'd file a bug or forum post | 21:19 |
| pmatulis | i would also like to know how to query for extra options. the maas snap, for instance, accepts '--devmode'. is that standard? | 21:20 |
| pmatulis | this snap will not install without it | 21:20 |
| nacc | pmatulis: well the snap doesn't accept that, `snap` does | 21:20 |
| nacc | pmatulis: right, the default is `snap install` tries to install a confined snap | 21:20 |
| nacc | pmatulis: with the name provided | 21:20 |
| nacc | pmatulis: in the `snap info` output for maas, you can see that one mentions devmode | 21:20 |
| nacc | pmatulis: that means it's a devmode snap (not confined) | 21:21 |
| pmatulis | oh it mentions it? | 21:21 |
| nacc | http://paste.ubuntu.com/24752362/ is what i get from `snap info maas` | 21:21 |
| nacc | pmatulis: stable is not a devmode snap, but edge is | 21:22 |
| pmatulis | no, i installed stable with devmode | 21:22 |
| nacc | pmatulis: given the security implications (and trust implications) of not using confined snaps, you have to tell `snap` to install it in anything other confined mode (e.g., --classic, --devmode). | 21:23 |
| nacc | pmatulis: hrm, let me let it complete here | 21:23 |
| nacc | pmatulis: did you get this: http://paste.ubuntu.com/24752396/ ? | 21:26 |
| pmatulis | nacc, yes, you need --devmode | 22:19 |
| nacc | pmatulis: right, i think it's a bug in the snap | 22:21 |
| nacc | pmatulis: they aren't declaring you need devmode for the stable snap | 22:21 |
| nacc | pmatulis: you might file a bug with maas | 22:21 |
| pmatulis | nacc, ah ok | 22:23 |
| nacc | pmatulis: i think they 'fixed' this in edge (hence it asks for devmoe) and maybe just haven't updated stable yet -- i've asked them | 22:25 |
| nacc | pmatulis: but EOD on a friday, so probably won't hear back :) | 22:25 |
| pmatulis | nacc, you've asked them where? | 22:25 |
| nacc | pmatulis: internal IRC :) | 22:26 |
| nacc | pmatulis: you might ask in #maas, though, i guess | 22:26 |
| pmatulis | nacc, right, but i'm in the maas channels. there must be one i'm not aware of | 22:27 |
| === ejat is now known as fenris | ||
| === fenris is now known as ejat | ||
| === Saviq_ is now known as Saviq | ||
| nacc | pmatulis: apparently, this was done so that the snap could be published in stable at all (which doesn't allow devmode) | 22:44 |
| nacc | pmatulis: but it still needs devmode ... | 22:44 |
| nacc | pmatulis: not a great UX :) | 22:45 |
| === stgraber_ is now known as stgraber | ||
| pmatulis | yeah | 22:49 |
| Chipaca | niemeyer: (and for zyga, but he's not here): from HN: https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix | 23:47 |
| niemeyer | Chipaca: Oh, handy | 23:47 |
| Pharaoh_Atem | I'm really not surprised by that | 23:48 |
| niemeyer | Chipaca: Ah, uh | 23:48 |
| niemeyer | Chipaca: That sounds like the basic issue we're aware off | 23:48 |
| Chipaca | Pharaoh_Atem: heh | 23:48 |
| niemeyer | Chipaca: That's why we have the C hackery in e.g. snap-update-ns | 23:48 |
| Pharaoh_Atem | wait, what | 23:49 |
| niemeyer | Chipaca: Trick is to basically switch namespaces before Go has a chance to screw up | 23:49 |
| Chipaca | yeap | 23:49 |
| Pharaoh_Atem | grossness | 23:49 |
| * Pharaoh_Atem smacks himself | 23:49 | |
| Pharaoh_Atem | of course I remember when that happened | 23:49 |
| Chipaca | same for a bunch of things like setuid, drop privs, etc | 23:49 |
| Pharaoh_Atem | it was switched from C to Go with Cgoop | 23:49 |
| niemeyer | Chipaca: Note that this is not true of all namespaces | 23:49 |
| Pharaoh_Atem | stuff like this makes me wonder if Go is really a good idea for a lot of this stuff... | 23:50 |
| niemeyer | Which I think the article fails to point out | 23:50 |
| niemeyer | Pharaoh_Atem: There's basically a cost benefit to be measured for sure | 23:50 |
| niemeyer | Pharaoh_Atem: The amount of C in snap-update-ns is minimal, so worth it | 23:51 |
| Chipaca | HN discussion is here: https://news.ycombinator.com/item?id=14470231 fwiw | 23:51 |
| Chipaca | anyway, thought you'd enjoy / find it interesting | 23:53 |
| niemeyer | "Personally I really wish people had just gone with Rust earlier on rather than implementing everything in Go. I've had nothing but pain from Go." | 23:54 |
| niemeyer | Personally, I wish people wouldn't be so superficial and one-sided.. :P | 23:54 |
| niemeyer | Chipaca: The hnews discussion is much more interesting than the article itself | 23:55 |
| niemeyer | Still, even there, there's a lot of "editor wars" conversation | 23:55 |
| Chipaca | rah rah c++ rah rah nim | 23:55 |
| niemeyer | People get too passionate about the tools.. | 23:55 |
| Pharaoh_Atem | I like C++ | 23:56 |
| Pharaoh_Atem | at least modern C++ (C++11) | 23:56 |
| niemeyer | Hah, they even managed to bring up Go generics into the conversation.. :) | 23:56 |
| Chipaca | Pharaoh_Atem: the big c++ abi brouhaha a couple of years back makes me uneasy about supporting it for things meant to live a long time | 23:57 |
| niemeyer | Me, I would definitely not choose Go for this stuff, but the point is that the whole project is in Go, which means all of our libraries are in Go, and our testing infra, and etc etc | 23:57 |
| Pharaoh_Atem | Chipaca: I think it practice, it doesn't matter | 23:58 |
| niemeyer | The cost of picking something else needs to account for that | 23:58 |
| niemeyer | I wouldn't pick Rust either, though, most probably at least | 23:58 |
| Pharaoh_Atem | Rust is a bit on the young side right now | 23:58 |
| niemeyer | I think Rust is going the C++ route a bit too early | 23:58 |
| Pharaoh_Atem | how so? | 23:58 |
| Chipaca | Pharaoh_Atem: I agree it doesn't matter; in 40 years time all this will be dust | 23:59 |
| Pharaoh_Atem | Chipaca: well, I mean that usually ABI changes are system wide, and c++stdlib supports both anyway | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!