=== mup_ is now known as mup
morphis_Pharaoh_Atem: ping06:10
=== JanC is now known as Guest29977
=== JanC_ is now known as JanC
zygagood morning06:59
fgimenezgood 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 goes07:13
fgimenezhey pstolowski07:13
mupPR 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
mupPR snapcraft#1341 closed: Release changelog for 2.30.1 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1341>07:13
mvofgimenez: great, thank you07:15
fgimenezpstolowski: 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 error07:16
zygamwhudson: hey07:18
zygamwhudson: still around by any chance?07:18
pstolowskifgimenez, hi! yes, i saw this and yes, it's jut the warning. it's ok07:18
zygamwhudson: 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
fgimenezpstolowski: 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 empty07:21
pstolowskifgimenez, is this with all my changes from that branch, or did you comment the SNAP_CONTEXT compatibility line out?07:23
fgimenezthe context seems to be correctly set map[yltR4VFx0ryHTjNpvGVHmvHbpvsg47sv5M7S7JtmTtkm:core]07:23
fgimenezpstolowski: with all the changes in your branch and removing the compatibility line07:23
mupPR snapd#3427 opened: interfaces/builtin: silence ptrace denial for network-manager <Created by morphis> <https://github.com/snapcore/snapd/pull/3427>07:27
fgimenezpstolowski: probably that "get service.ssh.disable" comes from the core's configure hook itself https://github.com/snapcore/core/blob/master/hooks/configure#L11107:35
pstolowskifgimenez, yes, this failure is expected then without that compatibility line; lack of this line causes all hooks to fail07:44
pstolowskifgimenez, 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
fgimenezpstolowski: 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 installed07:47
pstolowskifgimenez, 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
fgimenezpstolowski: 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 machine07:52
fgimenezpstolowski: 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
pstolowskifgimenez, 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
fgimenezpstolowski: 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 enough07:58
mupPR 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
pstolowskifgimenez, 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
zygamorphis_: you got reply on the factory ML08:05
zygamorphis_: I spoke with jjohansen yesterday and upstreaming is his sole focus08:06
zygamorphis_: 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
fgimenezpstolowski: 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 already08:08
morphis_zyga: but feel free to reply as well08:08
fgimenezpstolowski: not sure if just the binaries would include all your changes though08:09
zygamorphis_: thank you!08:09
morphis_zyga: you submitted all PRs we talked about yesterday?08:14
zygamorphis_: no, working on them08:14
zygamorphis_: I've started with a regression test before I start to meddle there08:14
morphis_zyga: can you note them on the forum topic once done?08:14
zygamorphis_: then the refactor08:14
zygamorphis_: and then comments08:15
zygamorphis_: on https://forum.snapcraft.io/t/including-snapd-in-the-opensuse-factory-branch/863/5 ? yes sure!08:15
zygaI commented briefly just now but I will refer to each PR as they show up08:17
pedroniszyga: 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
zygapedronis: looking08:49
zygapedronis: thanks, I'll handle that08:51
jjohansenzyga: not only are we upstreaming, we have made the switch to an upstream first policy. So we won't get in this position again08:57
pstolowskifgimenez, with SPREAD_MODIFY_CORE_SNAP_FOR_REEXEC=0, it's expected some tests to fail (such as reexec-test), right?09:03
mupPR snapcraft#1346 opened: Multi arch build deps <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1346>09:04
fgimenezpstolowski: 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-checks09:06
zygajjohansen: thank you for re-affirming that! :)09:07
pstolowskifgimenez, i see, thanks09:07
mupPR snapcraft#1347 opened: cli: do not duplicate errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1347>09:07
mupPR snapcraft#1348 opened: Foreign arch src <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1348>09:07
sil2100Hello! I have some questions regarding classic confinement09:10
ogra_it is awful, dont use it :P09:10
ogra_sil2100, i guess caused by my bug ?09:10
sil2100ogra_: yeah, I just don't seem to understand classic confinement at all09:10
ogra_sil2100, it is like a deb just differently packaged in the end09:11
sil2100ogra_: as per your bug, for instance, libparted is present in the snap but it's just not visible09:11
sil2100ogra_: as everything seems to just look for the libraries in the standard directories, not in the snap ones09:11
ogra_sil2100, righrt, you would need to hack up wrappers that make the shipped libs used in LD_LIBRARY_PATH09:11
sil2100This is just silly09:12
ogra_(or just switch back to proper strict confinement ;) )09:12
sil2100Yeah, I seriously don't think that doing wrapper hacks is what I would like to have, I guess barry wasn't aware of that09:12
ogra_it is for special cases where snaps cant really achieve their goal with any of the existing interfaces09:12
ogra_editors that need access to all of the system for example ...09:13
ogra_or compilers09: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 etc09:14
sil2100That's a bit too simplistic for our usecase, I'll bring this up at our sprint next week09: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 correct09:15
sil2100I 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 well09:16
ogra_sil2100, http://paste.ubuntu.com/24746613/ is an example09:18
Chipacazyga: an apparmor DENIED from core's configure related to mounting etc/ssl is probably version skew, yes?09:38
zyga_let me check but I think so09:38
zyga_apparmor mismatch vs binary09:39
zyga_hacking or production?09:39
Chipaca(i always run snapd with _TESTING so you won't see this in errors)09:40
Chipacawell, always, always on this machine09:40
zygadh_install: usr/bin/uboot-go exists in debian/tmp but is not installed to anywhere09:43
mupPR 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 home09:47
zyga_we're moving TOMORROW09:48
pstolowskizyga, back to Poland?09:56
Chipacazyga_: <gif of that guy waving his arms around in panic>09:58
zyga_pstolowski: yes09:58
pstolowskigood :)09:58
zyga_pstolowski: we just ordered the transport as it is in the town next to us and the price is very competetive09:58
zyga_Chipaca: that'd be my wife09:58
zyga_we have to pack everything that won't fit into the car now09:58
zyga_like ... now09:58
mvozyga_: woah, goooooood luck!09:59
pstolowskifgimenez, 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 feature10:02
kunalHello community10:07
ogra_hey kunal10:07
kunalI have a problem... I am trying to build a snap for python script / app10:07
kunalI have read alot of documents but still unable to figure out the solution for some problems10:08
kunaldear community, please help10:09
kunalI need your help10: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 easy10:09
kunalI 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 folder10:11
zyga_kunal: read-only data that is distributed with your snap?10:12
zyga_kunal: just add a part that contains this data10:12
ogra_have a look at the dump plugin10:12
kunalhow to add it in the snap folder10:13
kunalI 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 folder10:14
zyga_kunal: no worries, look at the dump plugin and experiment10:14
pstolowskizyga, 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
zygapstolowski: can people revert from the new feature back to previous release?10:15
zygapstolowski: I'm mainly asking if this is a flag day change or not10:15
kunalFolder name is dataFolder. So where should I place my dataFolder. Should it be there in src folder or in the top or parent folder10:15
zygakunal: in your source tree it can be anywhere10:16
zygakunal: but your snapcraft.yaml must say that it must be installed into the snap10:16
zygakunal: ogra_'s advice was correct, look at examples of dump plugin10:17
zygakunal: also if this is a python appication you should be able to install the data throuh python10:17
zygakunal: good luck10:17
kunalThanks. But how to point the folder in yaml file so that it can be included in snap10:17
zygakunal: using a part and the dump plugin, is one way, there are others that may be more straightforward, depending on other parts you use10:18
pstolowskizyga, 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 featue10:18
zygapstolowski: that's fine10:18
zygapstolowski: we have some tests missing in revert10:18
zygapstolowski: when is this scheduled to land? 2.27?10:19
pstolowskizyga, 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 proposed10:21
pstolowskizyga, not scheduled really, but soon once the rename of env var is addressed10:21
kunalDear Sir,  should I write plugin: dump source: .10:23
kunalWhat 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 script10:24
zygakunal: https://snapcraft.io/docs/reference/plugins/dump10:26
zygakunal: but if you have a correctly written python app you don't need dump10:26
zygakunal: your python's setup.py should install data10:26
kunalhow to do it, dear Sir, in setup.py to instruct system to install data files properly at desired place. Please help sir10:27
zygakunal: this is widely documented on python setuptools project, please look there10:28
zygakunal: if you have a free software project or wish to share your setup.py that might help10:28
zygakunal: but I cannot help you in detail today (look above, I'm moving my life to another country)10:28
zygakunal: needles to say there are 100s of examples of python projects shipping data files around10:28
zygakunal: and accessing them irrespectively to how they are installed (which is a nice advantage)10:29
zygakunal: I recommend you to look that up10:29
kunalThank you so much dera Sir. Thanks alot for giving me your precious time to guide in right direction. Thanks alot dear sir!10:30
zygagood luck :)10:30
zygaand note that you may also try the forum (forum.snapcraft.io) as there are plenty of people snapping software that can help you out10:30
zygaand it works somewhat better across timezones than IRC10:30
zygamany of the snapcraft developers are in the US timezne10:30
kunalThank you so much sir. Thanks alot.....10:31
kunalSir, 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 variable10:39
kunalso how will it look for the data folder. Will the data folder be also variable at runtime along with its executables10:41
zyga_what is "the data folder?"10:41
kunalFolder that contain data required by the python script at runtime10:43
Chipacakunal: for reading, or for reading and writing?10:44
* zyga_ hugs Chipaca10:44
Chipacazyga_: go pack :-)10:44
ogra_geez, is he traveleing *again* ?10:45
kunalSir for both the purpose10:45
Chipacakunal: is this your python code, or are you snapping somebody else's?10:45
kunalMy own code.10:46
Chipacakunal: and is it a daemon (a service), or is it a standalone executable?10:46
kunalI wrote a piece of code used setup.py and made it work . Dear Sir, Its a standalone executable.10:47
Chipacakunal: 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
kunalYes sir10: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
kunali need these data files at runtime.10:49
Chipacakunal: so, os.getenv("SNAP_USER_DATA") will give you a directory you can read and write to, which is intended for this sort of thing10: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_DATA10:50
zyga_kunal: if you have a service it can keep its mutable state in $SNAP_DATA10:50
zyga_kunal: and all of those can obviously access anything they want (immutable code and data) stored in $SNAP10:50
kunalDear sir, May I know , how to set it up to be used by script10:50
kunalHow should I add Data Files and Folder to this location while writing yaml file . How to point to these locations10:51
zyga_kunal: if you struggle with this I'd suggest going through the snapcraft tutorial10:53
zyga_kunal: as I mentioned the dump plugin is a very simple way of doing what you want10: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 data10: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 variables10:54
zyga_kunal: I suggest that you install hello-world10:54
zyga_kunal: and play around in the shell, look at where those variables point10:54
zyga_kunal: good luck :)10:54
kunalOk sir. Thanks. Now every doubt is clear. Thank you so much sir. and thanks community ... Open Source Community . Thanks alot10:55
mupPR 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
mupPR 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 PR11:26
morphis_zyga_: nice!11:26
Son_Gokuzyga, morphis_, for snapd 2.27, I'm considering flattening the packaging some more in Fedora11:45
Son_Gokuthe original reason I kept snap-confine and snapd separate was because there was a separation of C and golang code11:45
Son_Gokubut as zyga rewrites more bits from C to Go, it makes less sense11:45
morphis_Son_Goku: you mean droping the snap-confine package?11:46
morphis_Son_Goku: btw. if you submit those changes first upstream we can review them together11:47
morphis_want to do the same with the suse bits in the future11:47
Son_GokuSUSE already works this way11:47
morphis_it doesn't11:48
Son_Gokuit doesn't generate a snap-confine subpackage11:48
morphis_will still maintain the real .spec file on OBS and have no backported a few changes11:48
morphis_ah, we're talking about different things :-)11:48
Son_Gokualso, the SUSE changes I will submit to OBS first11:48
Son_Gokuthere's no value in doing it in snapd git11:49
Son_Gokuas it does no testing of packaging11:49
morphis_there is, there we have the entire test suite running11:49
zyga_Good idea, what do you have in mind specifically?11:49
Son_Gokunot helpful when the goal is to change the snapd packaging11:49
morphis_Son_Goku: we have such upgrade tests for .deb11:49
Son_GokuI'm not touching the debian crap11:49
morphis_that is not what I mean11:49
Son_Gokuit's impossible to figure out what that stuff even does11:49
Son_Gokulook, my fixes for the SUSE spec are small things to enable some of the tests that are already enabled in the Fedora package11: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 tests11: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 bits11:51
Son_Gokumorphis_: I'm not worried about Fedora upgrade tests, and I'm not even sure I'm going to do it yet11:51
morphis_we can then push from there to fedora/obs/..11:51
Son_Gokufirst of all, for that to be possible, we need the first class packaging tests for fedora, suse, etc.11:51
Son_Gokuwe don't yet11:51
Son_Gokusecond, snapd git is BROKEN for all distributions except Ubuntu11:51
Son_Gokuand I don't foresee that getting fixed soon11:52
Son_Gokumaybe in 2.2811:52
Son_Gokuwhich is a couple of months out11:52
morphis_Son_Goku: what is broken in master?11:52
Son_Gokuseccomp, for one11:53
Son_Gokuunless a proper fix was merged in recently11:53
morphis_what exactly do you mean?11:53
Son_Gokuthat ^11:53
morphis_Son_Goku: you saw https://github.com/snapcore/snapd/pull/3394 ?11:53
mupPR 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_Gokuwell, no11:54
morphis_so what else is broken? :-)11:54
pedronismvo: should snapd#3446 be merged?11:54
Son_GokuI guess at that point nothing that isn't already broken11:55
Son_GokuI'm also not doing the golang flags override in Fedora11:55
morphis_which one do you mean?11:55
mupPR 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
pedronismvo: sorry, should snapd#3426 be merged?11:56
mupPR snapd#3426: release: 2.26.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3426>11:56
mvopedronis: yes11: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_GokuI'm aware11:57
Son_Gokuif you want, you can switch spread to fedora-2611:57
Son_Gokuthen you can drop that11:57
morphis_we will add a f26 instance too11:57
morphis_Son_Goku: we could make this conditional for f25 too if you want11:58
Son_Gokuit'd be F25 and lower, actually11:58
Son_Gokubut yes11:58
morphis_Son_Goku: it's better than keeping this libtool patch11:58
Son_Goku0%{?fedora} && 0%{?fedora} < 2611:58
Son_Gokumeh, the libtool patch is easy to rebase11:58
pedronisfgimenez: snapd#3414 has 2 +1 but the spread tests have failed11:58
mupPR 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 master11:59
morphis_however if you want to keep it I am fine11:59
morphis_we should just try to avoid that snapd git and fedora git get out of sync for the .spec file11:59
morphis_as as soon all changes for the spread setup land developers will be required to touch the .spec file too11:59
Son_Gokuyou think they will?11:59
morphis_otherwise CI will break :-)12:00
Son_GokuI'd be surprised to see mvo generating changelogs for the spec files in parallel to the debian/changelog file12:00
morphis_Son_Goku: I am not talking about changelogs12:00
morphis_but all the other packaging bits12:00
Son_GokuI know12:00
Son_Gokubut it'd be surprising if that happened too ;)12:01
pedronismvo: also snapd#3413 could go in with a 2nd pass from you (if the tests pass)12:01
Son_GokuI'd initialize the repository with tito if tito supported spec files in subdirs :/12:01
mupPR 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
fgimenezpedronis: thx, looking12:05
fgimenezpedronis: 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#L128112:07
pedronissome test not restoring something properly and order issues?12:08
pstolowskifgimenez, I've pushed one more compatibility workaround to my branch (the one mentioned earlier).12:10
fgimenezpedronis: 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 changed12:15
fgimenezpstolowski: 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 scratch12:16
fgimenezpstolowski: 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 set12:19
fgimenezdoesn't fail in your branch12:19
pedroniswell edge has something that understand only SNAP_CONTEXT12:20
fgimenezpedronis: but in prepare we modify the core snap and put in place the outer binaries, maybe i'm missing something12:21
pstolowskifgimenez, but we modify it too late12:23
pedronisfgimenez: yes, but  as pstolowski explained before we do that we do snap install --"$CORE_CHANNEL" core12:23
pedronisthat ends up using the snapctl from edge core I think (because of the configure hook)12:24
fgimenezpstolowski: i'm trying locally modifying it before calling "snap set core.." and the error is the same12:24
pedronisinstall core will call the hook already12:24
pedronisnot need to do a set12:24
pedronisto trigger that12:25
pstolowskifgimenez, yes, as pedronis says12:25
pedroniswhich thinking of it is all a bit weird12:25
fgimenezpedronis: yes, but that doesn't trigger the error, the errors on install seem to be ignored12:27
pedronisthat doesn't make sense to me12:27
pedroniswe don't ignore configure errors12:28
pstolowskifgimenez, 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 break12:28
fgimenezpedronis: the error happens only after snap set from what i'm seeing here, let me paste a log12:28
pstolowskifgimenez, I saw prepare failed12:28
abeatohey, is it possible to specify a concrete core snap revision in "snap prepare-image"? or to use a local core snap?12:31
fgimenezpedronis: 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
pedronisabeato: 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-image12:33
abeatopedronis, ok, 2nd option is good enough for me, thanks!12:34
pedronissorry what I meant the version of snap (the binary) shipped with ubuntu-image needs to be recent enough12:34
fgimenezpedronis: 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
abeatopedronis, but if I use a local fine, there will be any issue with assertions? as you get some of them when dowloading from the store12:35
abeato*local file12:35
pedronisabeato: well, it wil be unasserted so no updates12:35
abeatopedronis, ok, I see12:35
pedronisunelss as I said the .snap came from the store then ubuntu-image finds the assertions anyway12:35
abeatoah, good12:36
pedronisbut this is implemented by snap prepare-image only recently12:36
pedronisand I lost a bit track what is shipped where12:36
abeatook, I will just try, thanks12:36
pedronisfgimenez: something seems really weird, I don't understand why we don't die on that first error12:38
pstolowskifgimenez, can you share the log too?12:40
fgimenezpstolowski: sure, this is spread's log http://paste.ubuntu.com/24748076/12:42
fgimenezand the corresponding journalctl (the other one was from a previous execution) http://paste.ubuntu.com/24748082/12:44
pedronisanyway a --debug run one test should show where we die12:46
fgimenezpedronis: looks like the "ERROR ignoring failure in hook "configure"" comes from https://github.com/snapcore/snapd/blob/master/overlord/hookstate/hookmgr.go#L24312:48
pstolowskifgimenez, right.. i see we set ignoreerror flag for configure hook depending on some state flags12:50
mupPR 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
pedronisah, yes12:51
pedronisonly for core12:51
pedronisbecause confgure hook of core gave us so much grief trying to update core12:52
mvothanks pedronis12:55
pstolowskifgimenez, ok.. i don't understand why it's failing after you copied new binaries into core12:56
fgimenezpstolowski: 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 same12:58
pstolowskifgimenez, 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
fgimenezpstolowski: sure 1sec13:01
pstolowskifgimenez, after standup is ok ;)13:01
zyga_Chipaca: standup?13:01
mupPR 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
mupPR 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_hangouts froze for me13:30
pstolowskizyga, for me tto13:31
pstolowskizyga, i can't reconnect...13:31
Chipacaoh nice13:31
Chipacanow it kicked me13:31
Chipacais it sso o'clock13:31
pstolowskino sso prompt, just spinning13:32
mupPR 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
pedronisniemeyer: is this one snapd#341813:53
mupPR snapd#3418: tests: prefer ipv4 over ipv6 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3418>13:53
pedronisneeds 2nd review and now it's green finally, well or green enough at least13:53
mupPR snapd#3430 opened: tests: modify core before calling set <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3430>13:55
fgimenezpstolowski: 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_COOKIE14:03
niemeyerpedronis: Cheers!14:03
pstolowskifgimenez, thanks, i'll look into it14:04
niemeyerfgimenez: Why the full block instead of just echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf?14:04
fgimenezthank you pstolowski14:04
pedronisniemeyer: because that's what "man gai.conf" tells to do14:04
pedronisit doesn't add , it replaces the whole table14:05
niemeyerpedronis: That doesn't sound like a good reason :)14:05
fgimenezniemeyer: 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
pedronisniemeyer: because the RFC also suggested the change in terms of an update table14:05
fgimenezniemeyer: and we just want to change one of them?14:05
pedronisand just putting in a single precedence doesn't produce that14:06
pedroniss/update table/updated table/14:06
niemeyerpedronis: I'm not reading that there14:07
niemeyerpedronis: Specifically, "Complete absence of data of one kind causes the appropriate default information to be used."14:08
pstolowskifgimenez, can you give me last commit id you're using? git log -n1 ?14:08
niemeyerpedronis: Note the "of one kind"14:08
fgimenezpstolowski: the last two are merges and conflic resolutions, the next is 5da6cd162745d96120fa2dadc2beba4e3dbeba93 "Further compatibilty changes to support SNAP_CONTEXT in transition period."14:09
pedronisniemeyer:   Once again, the presence of a single precedence line in the configuration file causes the default table to not  be14:09
pedronis              used.14:09
niemeyerpedronis: You said this was in the manual.. I can't find it..14:09
pedronisthat line is in man of gai.conf14:10
niemeyerpedronis: What I'm reading, also from the documentation, is what I pasted above, which means something else14:10
pedronisniemeyer: are we reading different versions of the docs14:11
pedronisbecause I don't see that "one kind" bit14:11
niemeyerpedronis: Maybe.. can you paste what yours says?14:11
niemeyerpedronis: THis is in the docs in the configuration file14:11
pedronisniemeyer: ?14:12
niemeyerpedronis: Sorry, I don't know what the question is14:12
pedronisniemeyer: why you think your sentence help14:12
pedronisif one present in there then the info is not missing14:12
Chipacamwhudson: 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 other14:12
pedronisso the default table is not used14:12
Chipacamwhudson: (this confirms the original hypothesis about why those eagains were happening, fwiw)14:13
pedronisniemeyer: also see  https://www.rfc-editor.org/rfc/rfc3484.txt   "10.3. Configuring Preference for IPv6 or IPv4"14:13
niemeyerpedronis: Because so far I found nothing saying "the default is not used"14:13
pedronisniemeyer: man gai.conf14:13
niemeyerpedronis: The RFC is irrelevant.. this is a configuration file which modifies an implementation detail14:13
niemeyerpedronis: There's a default table in glib proper14:13
pedronis       precedence netmask precedence14: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  be14:14
pedronis              used.14:14
pedronisthis is compatible also with the the first lines in gai.conf which sort of refers to the reverse14:14
niemeyerpedronis: Ok, thanks.. I missed that part..14:15
niemeyerpedronis: I was basing my assumption on the documentatino provided in gai.conf itself14:15
niemeyerand in my own experience doing the simple addition, which does work14:15
niemeyerPerhaps for non-obvious reasons14:15
pedronisit's all a bit unclear14:15
pedronisit's a bit bad that there's no command to print the actual table14:16
pedronisthat will be used14:16
pedronisbut the full table should be good because is also what's listed in the RFC14:16
pedronisto achieve this14:16
niemeyerpedronis: It's probably safer as well considering we're dealing with mulitple images14:16
niemeyer(which might have different values)14:16
niemeyerpedronis: Anyway, thanks, learned something14:17
pedronisyes, 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 scratch14:19
pedroniss/or the/the/14:19
mupPR snapd#3418 closed: tests: prefer ipv4 over ipv6 <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3418>14:24
mvopedronis: if someone can ack 3426 we can merge that one too14:27
mupPR 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
mupPR snapcraft#1350 opened: Rust rust: Add support for cross-compilation <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1350>14:29
mupPR snapd#3426 closed: release: 2.26.4 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3426>14:30
abeatozyga, finally got a good test run for https://github.com/snapcore/snapd/pull/3353 , time for merging?14:32
mupPR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>14:32
fgimenezpedronis: mvo niemeyer snapd#3408 is only missing one review (green with some autopkgfailures)14:32
mupPR snapd#3408: tests: add alsa interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3408>14:32
fgimenezand it would be great to have snapd#3348 landed too, so that we can put in place the spread-cron branches for executing it14:34
mupPR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>14:34
mupPR 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
dakerhey popey, can i PM you (snap testing)?14:35
popeyof course, anytime14:36
morphis_niemeyer: do you have time for another look at https://github.com/snapcore/snapd/pull/3365 ?14:42
mupPR 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
niemeyermorphis_: Yep14:42
morphis_niemeyer: awesome! I have a few more you had comments on but lets start with that one14:43
mupPR snapd#3408 closed: tests: add alsa interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3408>14:43
aisraelI 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
mupPR snapcraft#1351 opened: cli: remove double congrats messaging <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1351>14:53
niemeyermorphis_: Are there tests enabled?14:53
niemeyermorphis_: For fedora?14:53
morphis_niemeyer: a single one14:53
morphis_enabling a lot more is another PR14:53
mupPR 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
niemeyermorphis_: I'd prefer to invert the logic then: whitelist the one test14:54
niemeyermorphis_: Instead of blacklisting every single one14:54
morphis_niemeyer: how? when I tried to blacklist the suite none of the suite tests were considered no matter if whitelisted or not14:54
niemeyermorphis_: That'd be a bug in spread.. let me try to reproduce14:55
fgimenezpstolowski: 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#r11901284814:57
mupPR 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
pstolowskifgimenez, great! thanks for checking that14:57
morphis_niemeyer: that is what I get with the suite blacklisted and a single test below whitelisted14:58
pstolowskifgimenez, btw, i've reproduced the failure with your diff and investigating it14:58
fgimenezpstolowski: 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
fgimenezpstolowski: great thanks!14:58
niemeyermorphis_: Worked fine here15:01
morphis_niemeyer: hm, you have a newer spread version?15:01
morphis_hm, spread -v does not exist15:01
mvoChipaca: can you walk me through the process of contributing to go? https://github.com/golang/go/issues/20556 is what I need15:01
morphis_niemeyer: 2017.01.30 is what I used15:02
niemeyermorphis_: That sounds super old15:03
niemeyermorphis_: Most likely the issue15:03
morphis_niemeyer: that is what is in the store .. :-)15:03
niemeyermorphis_: Let me update that then15:04
niemeyerInteresting that my snapcraft.yaml says 2017.04.25, which is up-to-date.. I probably screwed up by not uploading15:04
morphis_niemeyer: time to use build.snapcraft.io :-)15:05
morphis_then we have at least an up to date version in edge15: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 kvm15:05
morphis_form the host15:05
niemeyermorphis_: Might be a good idea15:06
niemeyermorphis_: Ok, rev 28 is up15:06
niemeyermorphis_: Please give it a shot and let me know15:06
morphis_niemeyer: will do15:06
morphis_niemeyer: ok, then you vote for changing that, fine for me15:06
morphis_niemeyer: any other comments?15:06
niemeyermorphis_: Yeah, it makes more sense for that status of the PR15:07
niemeyermorphis_: Otherwise you'll immediately break every other spread PR that is up for review, for example15:07
pedronismvo: interesting  x/net, might take a while15:07
pstolowskifgimenez, 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 error15:07
niemeyermorphis_: No, I think we're aligned about the rest15:07
morphis_good, so can you approve based on that or do you want to review again on Monday?15:08
mvopedronis: 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 myself15:10
fgimenezmvo: 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 great15:18
mupPR 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
mvofgimenez: woah15:18
mvofgimenez: 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 one15:19
fgimenezmvo: the execution hasn't finished yet, let me check on another session15:20
mvofgimenez: 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 it15:20
fgimenezmvo: http://paste.ubuntu.com/24749363/15:25
mvofgimenez: do you see an apparmor denial in syslog?15:26
mvofgimenez: 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
fgimenezmvo: seems to be empty now, the suite is still running...15:27
mvofgimenez: with correct quoting15:27
mvo(sorry for that paste error)15:27
fgimenezmvo: yep, i've tried, complains about elevated permissions, let me paste the output15:28
mvofgimenez: ok, strange, could you re-run this test once the suite finished?15:28
fgimenezmvo: http://paste.ubuntu.com/24749391/ sure, will let you know how it goes, thx!15:29
mvofgimenez: this looks ok, odd15:30
mvojdstrand: 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
jdstrandmvo: I do not. I saw the forum post. tyhicks or sbeattie might have an idea16:06
jdstrandtyhicks, sbeattie: https://forum.snapcraft.io/t/build-failure-for-2-26-4-on-artful-on-arm-arm64/86616:07
jdstrandotoh idk if new defaults are being used in artful that would trigger that16:08
pstolowskifgimenez, that error you found is curious, still haven't found what's causing it16:08
jdstrandtyhicks: if you need me to dig into that instead of you or Steve, let me know and I can take a look after appt/lunch16:08
tyhickssbeattie: 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
fgimenezthank you pstolowski, don't spend too much time on it, maybe somehting is wrong with the tests, i'll take a look on monday16:16
pstolowskifgimenez, 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 work16:16
tyhickssbeattie: I followed up in the forum - please post there if you have any corrections to make to my advice16:16
fgimenezpstolowski: yep, it's super weird16:17
zygajdstrand: 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
mupPR snapd#3428: tests: add snap-confine privilege test <Created by zyga> <https://github.com/snapcore/snapd/pull/3428>16:24
mvotyhicks: 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
tyhicksmvo: feel free to do a quick no-change yourself once sbeattie chimes in16:32
* Chipaca out17:20
Chipacao/ EOW \o/17:21
om26erHi! Is there a way for my code to check if its running inside a snap ?18:53
naccom26er: i'm not sure. Why do you want that? Sort of defeats the purpose/goal it seems :)18:54
om26ernacc, 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/except18:55
mupPR snapd#3432 opened: tests: clean journalctl logs on trusty <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3432>18:56
naccom26er: 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
om26ernacc, right, the former18:58
naccom26er: i don't know, sorry -- i'm not sure there is a way to detect 'in a snap' explicitly19:01
ogra_om26er, chek your env ;)19:02
ogra_there is tons of things19:02
naccogra_: that does make sense, even for things like SNAP_19:03
naccogra_: but is there a 'canonical' (little c) way?19:03
naccogra_: 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 way19:04
nacci guess om26er could do ... try / except, in the except check if SNAP_ is defined and then assuem it's a snap19:04
om26erogra_, 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 set19:05
ogra_you can easily take a look by "snap install hello-world; hello-world|grep SNAP"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 snap19:06
naccor there was another one that told you you were in a VM19:06
ogra_in-container ?19:06
ogra_or some such19:06
om26eron a different note, is there a way to read /var/lib/dbus/machine-id inside a confined snap ?19:06
naccogra_: yeah that sounds familiar19:06
naccom26er: are you able to if you connect to the dbus interface?19:07
om26ernacc, do you mean "you are able to if you connect dbus interface" ?19:07
naccom26er: 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
naccom26er: it was a question, honestly -- i don't know (and can't tell immediately from reading the snapcraft docs)19:08
om26erof the top of my head, I think that path should not be available to a confined snap, but maybe ogra_ can confirm.19:09
naccom26er: right it won't be, i agree -- but if you connect to an interface that allows it, maybe it would be19:09
om26er*even with dbus interface connected. But that's just my limited understanding of Ubuntu Core.19:09
naccom26er: 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
naccom26er: do you use this file to generate a unique key or something?19:10
naccogra_: oh i see, it's for registering to be on/listen on dbus19:10
om26ernacc, 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-id19:11
naccom26er: right -- that still doesn't tell me why you need it? :)19:11
om26ernacc, reason: http://0pointer.de/blog/projects/ids.html19:11
naccom26er: 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 build19:13
ogra_ogra@styx:~$ LC_ALL=C ls -l /snap/core/current/var/lib/dbus/19:13
ogra_total 019:13
naccogra_: ah interesting19:13
naccogra_: why is that? (if you know)19:13
ogra_(else all core snaps would have the same ID)19:13
naccogra_: ah right19:14
naccogra_: probably similar to containers issue19:14
om26erapparently  /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 startup19:14
om26erin a python/dbus way19:14
naccogra_: that makes sense19:15
ogra_yeah, you can probably use the dbus to actually query for it19:15
naccyeah, i wonder if you can use the API (or do what the API does) to query dbus19: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 ID19:17
ogra_(while the file would never be visible even if you run unconfined)19:17
naccogra_: yep, that's the right abstraction to operate at, it seems19:18
naccom26er: with, based upon that post, maybe a fallback to the filesystem if that dbus query fails (for some reason)19:18
om26erogra_, making it a strict snap is the aim.19:19
ogra_i was assuming so :)19:19
FlagadaHello I'm Trying to install Ubuntu Core 16 with KVM.  I got a "Creating user failed" when I enter my SSO email adress19:22
om26erogra_, is the behaviour going to be the same on Ubuntu Core and classic ubuntu install with snapd ?19:22
FlagadaSomeone can help me with that?19:22
om26ernacc, I guess that's what I'd have to go for.19:23
ogra_om26er, yep19:23
cachioniemeyer, 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 i/o timeout19:37
cachioniemeyer, it just happened19:37
cachiothe machine is lost19:38
cachiono ping no ssh19:38
cachioniemeyer, seem to be a problem of linode19:38
cachioniemeyer, perhaps spread could allocate another machine when that happens or move the current task to another one19:45
=== nacc_ is now known as ancc
=== ancc is now known as nacc
mupPR 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
pmatulishow does one specify what "track" to install?20:47
om26erassuming track == channel, use --track_name e.g. snap install hello-world --edge. If otherwise, please ignore my comment.20:49
om26erpmatulis, ^20:49
naccpmatulis: track/channel, iirc20:50
naccpmatulis: down in the "installing a snap" section, first example20:50
naccom26er: tracks are new20:51
om26ernacc, thanks, reading into it now.20:52
naccom26er: np, niemeyer's forum post (looking for it now to share) is pretty helpful too20:53
nacc    GitUbuntuRepository: optimize treeishs_identical20:53
nacc    20:53
nacc    If we can peel() to treeishs, we can just compare the hashes.20:53
pmatulisi thought *channels* and *tracks* were distinct20:54
pmatuliswhere a channel was akin to a series (2.0, 2.1) and a track was the level of development (experimental, devel, stable)20:55
naccpmatulis: they are distinct20:56
nacctrack/risk/branch is what niemeyer's post says20:56
pmatulisi still don't know how to specify the channel21:04
naccpmatulis: i told you above? (and it was in the link)21:04
pmatulisnot really21:05
naccsnap install <snap> --channel=<track/channel>21:05
pmatuliswhere is that in the page you linked to?21:05
naccpmatulis: as i said, "down in the "installing a snap" section, first example"21:06
naccpmatulis: on https://snapcraft.io/docs/reference/chan21:06
naccpmatulis: on https://snapcraft.io/docs/reference/channels, rather21:06
pmatulisi was looking at the other one21:06
pmatulisforum whatever21:06
naccpmatulis: ah sorry, two different links21:07
pmatulisit's odd. i think it depends how some snaps are actually made21:10
pmatulisfor instance, this doesn't work:21:10
pmatulissudo snap install maas --channel=latest/stable21:11
pmatuliseven though:21:11
pmatulissnap info maas | grep latest/stable21:11
pmatulis  latest/stable: 2.2.0+bzr6057-snap (91)  98MB -21:11
naccpmatulis: interesting, '--channel=stable' does work though21:12
naccpmatulis: i *wonder* if the snap we are running isn't aware of tracks?21:12
pmatulisthat's the thing. it depends on how it's made21:13
pmatuliswhich isn't great at all21:13
naccpmatulis: i think it (obviously) depends on `snap` support21:15
naccpmatulis: is that what you mean by 'it'?21:15
naccpmatulis: 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
naccpmatulis: i also wonder, if (*big* if) that if there's only one track -- that it doesn't work21:18
naccpmatulis: to specify a track, i mean21:18
pmatulisright, no idea21:19
naccpmatulis: i'd file a bug or forum post21:19
pmatulisi would also like to know how to query for extra options. the maas snap, for instance, accepts '--devmode'. is that standard?21:20
pmatulisthis snap will not install without it21:20
naccpmatulis: well the snap doesn't accept that, `snap` does21:20
naccpmatulis: right, the default is `snap install` tries to install a confined snap21:20
naccpmatulis: with the name provided21:20
naccpmatulis: in the `snap info` output for maas, you can see that one mentions devmode21:20
naccpmatulis: that means it's a devmode snap (not confined)21:21
pmatulisoh it mentions it?21:21
nacchttp://paste.ubuntu.com/24752362/ is what i get from `snap info maas`21:21
naccpmatulis: stable is not a devmode snap, but edge is21:22
pmatulisno, i installed stable with devmode21:22
naccpmatulis: 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
naccpmatulis: hrm, let me let it complete here21:23
naccpmatulis: did you get this: http://paste.ubuntu.com/24752396/ ?21:26
pmatulisnacc, yes, you need --devmode22:19
naccpmatulis: right, i think it's a bug in the snap22:21
naccpmatulis: they aren't declaring you need devmode for the stable snap22:21
naccpmatulis: you might file a bug with maas22:21
pmatulisnacc, ah ok22:23
naccpmatulis: i think they 'fixed' this in edge (hence it asks for devmoe) and maybe just haven't updated stable yet -- i've asked them22:25
naccpmatulis: but EOD on a friday, so probably won't hear back :)22:25
pmatulisnacc, you've asked them where?22:25
naccpmatulis: internal IRC :)22:26
naccpmatulis: you might ask in #maas, though, i guess22:26
pmatulisnacc, right, but i'm in the maas channels. there must be one i'm not aware of22:27
=== ejat is now known as fenris
=== fenris is now known as ejat
=== Saviq_ is now known as Saviq
naccpmatulis: apparently, this was done so that the snap could be published in stable at all (which doesn't allow devmode)22:44
naccpmatulis: but it still needs devmode ...22:44
naccpmatulis: not a great UX :)22:45
=== stgraber_ is now known as stgraber
Chipacaniemeyer: (and for zyga, but he's not here): from HN: https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix23:47
niemeyerChipaca: Oh, handy23:47
Pharaoh_AtemI'm really not surprised by that23:48
niemeyerChipaca: Ah, uh23:48
niemeyerChipaca: That sounds like the basic issue we're aware off23:48
ChipacaPharaoh_Atem: heh23:48
niemeyerChipaca: That's why we have the C hackery in e.g. snap-update-ns23:48
Pharaoh_Atemwait, what23:49
niemeyerChipaca: Trick is to basically switch namespaces before Go has a chance to screw up23:49
* Pharaoh_Atem smacks himself23:49
Pharaoh_Atemof course I remember when that happened23:49
Chipacasame for a bunch of things like setuid, drop privs, etc23:49
Pharaoh_Atemit was switched from C to Go with Cgoop23:49
niemeyerChipaca: Note that this is not true of all namespaces23:49
Pharaoh_Atemstuff like this makes me wonder if Go is really a good idea for a lot of this stuff...23:50
niemeyerWhich I think the article fails to point out23:50
niemeyerPharaoh_Atem: There's basically a cost benefit to be measured for sure23:50
niemeyerPharaoh_Atem: The amount of C in snap-update-ns is minimal, so worth it23:51
ChipacaHN discussion is here: https://news.ycombinator.com/item?id=14470231 fwiw23:51
Chipacaanyway, thought you'd enjoy / find it interesting23: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
niemeyerPersonally, I wish people wouldn't be so superficial and one-sided.. :P23:54
niemeyerChipaca: The hnews discussion is much more interesting than the article itself23:55
niemeyerStill, even there, there's a lot of "editor wars" conversation23:55
Chipacarah rah c++ rah rah nim23:55
niemeyerPeople get too passionate about the tools..23:55
Pharaoh_AtemI like C++23:56
Pharaoh_Atemat least modern C++ (C++11)23:56
niemeyerHah, they even managed to bring up Go generics into the conversation.. :)23:56
ChipacaPharaoh_Atem: the big c++ abi brouhaha a couple of years back makes me uneasy about supporting it for things meant to live a long time23:57
niemeyerMe, 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 etc23:57
Pharaoh_AtemChipaca: I think it practice, it doesn't matter23:58
niemeyerThe cost of picking something else needs to account for that23:58
niemeyerI wouldn't pick Rust either, though, most probably at least23:58
Pharaoh_AtemRust is a bit on the young side right now23:58
niemeyerI think Rust is going the C++ route a bit too early23:58
Pharaoh_Atemhow so?23:58
ChipacaPharaoh_Atem: I agree it doesn't matter; in 40 years time all this will be dust23:59
Pharaoh_AtemChipaca: well, I mean that usually ABI changes are system wide, and c++stdlib supports both anyway23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!