[01:02] i'm trying to create a snap for a raspberry pi but it seems crosscompiling is not supported yet. i created a classic environment on my pi but i can't install snapcraft in it, the .deb package is not found. this is the procedure recommended for cross compiling but it's not working, am i missing something? [02:21] anyone having issues with discord not starting back up once you reboot? === chihchun_afk is now known as chihchun === JanC is now known as Guest87372 === JanC_ is now known as JanC === mup_ is now known as mup === chihchun is now known as chihchun_afk [07:20] o/ [08:05] Chipaca: o/ [08:05] \o [08:06] Chipaca: what do you think about https://github.com/snapcore/snapd/pull/3410 [08:06] PR snapd#3410: cmd/hotfix: add hotfix tool [08:06] (just the concept, not the code) [08:10] zyga: I'm not sure about it at all [08:25] zyga: that's not a roundabout way of saying I don't like it; I honestly am not sure [08:26] zyga: on the one hand I understand why it'd be useful; on the other I don't know how it'd be packaged, and I wonder how it'd be misused, and why we need it as opposed to having a web doc or something [08:50] Chipaca: yeah, I agree on packaging [08:50] Chipaca: I was thinking about providing a double-click unwedge.sh to download that does everything automatically [08:50] Chipaca: but not sure if there's actual demand [08:51] Chipaca: I jumped on this because initially it was apparently urgent [09:06] hey pstolowski, i've worked a little bit more on the weird issue with snapctl called from the hook, i've checked that with our current setup it is indeed the old one (the one that comes with the core snap and not the one built from the branch) [09:07] pstolowski: i've also checked that SNAP_COOKIE is correctly set in the configure hook environment but snapctl doesn't understand it; its md5sum is different from /usr/bin/snapctl and /snap/core/current/usr/bin/snapctl (the latter two are equal after the hook execution) [09:07] I wonder whether 'snap run' could catch errors in a snap' apps and push them (a snap hook or in its absence) to errors.u.c [09:08] fgimenez, hey! oh, that's interesting. are you sure it's old snapctl? they look the same to me, yet for reasons I don't understand it seems as if old one was run [09:09] pstolowski: yep, it turns out that calling "systemctl daemon-reload" after modifying the core snap and before starting the daemin again fixes the issue, somehow the snapctl binary used by the hook is cached, if you could give it a try that would be great to confirm, something like this https://github.com/snapcore/snapd/pull/3430/files#diff-556bb7431481e375713ea3e0883a771aR139 [09:09] PR snapd#3430: tests: modify core before calling set [09:09] fgimenez, and yes, I modified core manually and added debug to configure hook, it gets SNAP_COOKIE env var [09:09] fgimenez, ah! [09:09] can I get a 2nd look on a new test? https://github.com/snapcore/snapd/pull/3428 [09:09] PR snapd#3428: tests: add snap-confine privilege test [09:09] fgimenez, bummer, thanks for finding! i was pulling my hair already [09:10] pstolowski: yep :) for debugging, given that we already unpack core, i modified the configure hook to write out info to files, it's been quite helpful [09:12] pstolowski: what i don't understand yet is why the snapctl used is always the one from core, and never outer [09:12] never the outer [09:13] fgimenez, that's "by design", our PATH setup afair [09:14] zyga, hey, moved yet? [09:14] pstolowski: aha, great thanks, good to know [09:15] pstolowski: half way [09:15] pstolowski: most of our things have arrived an hour ao [09:15] ago* [09:15] fgimenez, I'm not sure if that's good or bad, we may want to change that soon [09:16] fgimenez: this is caused by us mounting the core snap [09:16] fgimenez: changing it [09:16] zyga, sounds like fun :) [09:16] fgimenez: and unmounting it [09:16] fgimenez: but exsting mount namespace may be kept [09:16] fgimenez: and is reused [09:16] fgimenez: this is a variant of this bug: [09:16] fgimenez: https://bugs.launchpad.net/snapd/+bug/1667479 [09:16] Bug #1667479: mount namespace is not discarded when core snap changes revision [09:17] zyga: thx! looking === chihchun_afk is now known as chihchun === Mirv__ is now known as Mirv [09:35] fgimenez, hmm daemon-reload doesn't seem to make difference here [09:41] pstolowski: let me doublecheck, maybe i had yet in place the code for modifying the configure hook in place when it succeeded [09:56] pstolowski: indeed, it was passing because of the modified configure hook, given zyga's comments above we need to discard the previous namespace before remounting, this is working here https://github.com/snapcore/snapd/pull/3430/files#diff-556bb7431481e375713ea3e0883a771aR60 [09:56] * zyga has another crazy day [09:56] PR snapd#3430: tests: modify core before calling set [09:57] fgimenez, I see. many thanks for figuring that out! [09:57] fgimenez, are you going to propose this change to prepare.sh independet of my PR? [09:57] pstolowski: np, thanks to zyga :) if you could confirm that would be great [09:58] FWIW what daemon-reload does it tells systemd that a file (e.g. a unit file, but also maybe a config file like e.g. timesyncd.conf) has changed, and it should re-read them [09:58] pstolowski: i've already proposed it, but yes, makes sense to add it to your PR, i can retarget to it [09:59] fgimenez, no no [09:59] fgimenez, I think it makes sense to land it immediately [09:59] fgimenez, not sure how long before my PR lands [10:00] pstolowski: ok, it is snapd#3430 [10:00] PR snapd#3430: tests: modify core before calling set [10:00] * zyga looks at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170605_085919_dd5dc@/log.gz trying to figure out why we didn't re-execute [10:03] zyga: we are getting quite a few "DEBUG: re-exec disabled by user" errors lately, not sure what's going on [10:04] fgimenez: aha, I see this as well in this log [10:04] I was confused about this because AFAIR we re-pack the core snap and *not* disable re-exec, right? [10:04] zyga: yes, by default it is enabled [10:05] we disable it for specific tests, but at the beginning of each test it is, or should be, enabled [10:05] fgimenez: maybe a restore bug somewhere? [10:05] fgimenez: anyway, thank you, this looks like a sequence bug [10:05] I'll try to debug it [10:06] zyga: np, yep maybe something is left behind [10:07] afaik this started happening about 1w ago, snapd-reexec and snap-confine-from-core fail randomly in different systems [10:08] fgimenez: I think we could use a feature in spread that tries to run a command before and after [10:08] fgimenez: and ensures that the output is the same (like run md5sum of some files) [10:08] fgimenez: I bet we are still missing something but it's not breaking all the tests so we didn't stop the line [10:10] zyga: sounds good, it could be helpful in cases like this [10:10] fgimenez, I can confirm discard-ns fixes the issue \o/ [10:10] pstolowski: \o/ [10:11] fgimenez: indeed, I made a similar (like) patch earlier but I think we could learn from it [10:11] fgimenez: I added a way to snapshot a manifest (whatever the spread.yaml says) [10:11] fgimenez: and diff that (or analyze in way way) after the test [10:12] fgimenez: but the size of the manifest was pretty significant so I think we'd like to just process the tests in flight and not keep all the manifests during the duration of the test (it would fill in the storage on travis and locally easily) [10:13] dh_install: usr/bin/uboot-go exists in debian/tmp but is not installed to anywhere [10:13] do i need to merge something? [10:13] Chipaca: I saw that too [10:13] Chipaca: I forgot TBH [10:13] Chipaca: but I think it was in mvo's branch somewhere [10:13] Chipaca: I remember commenting on that as I didn't know debian/noinstall (or something like that) is a thing [10:13] zyga: yes, do it just for one test at a time if needed [10:14] Chipaca: "rm -rf vendor/*/" fixes it here [10:14] Chipaca: ah, right [10:14] Chipaca: stale govendor [10:14] Chipaca: mvo added his uboot code so we don't need to vendor it anymore [10:15] ah, ok [10:15] fgimenez, zyga: thanks! === ogra_ is now known as ogra [11:35] PR snapcraft#1351 closed: cli: remove double congrats messaging [11:38] PR snapcraft#1347 closed: cli: do not duplicate errors === chihchun is now known as chihchun_afk [11:46] https://goplay.space/ looks interesting [11:49] Chipaca: interesting [11:49] snappable, also :-) [12:08] PR snapcraft#1352 opened: Allow source-type to specify local [12:15] is there an interface that lets you read the MSRs, /proc/$pid/net/psched, and other juicy /proc and /sys stuff? [12:16] Chipaca: let me check [12:16] Chipaca: it doesn't look like it [12:16] - Setup snap "powertop" (unset) security profiles (cannot update mount namespace of snap "powertop": cannot update preserved namespace of snap "powertop": cannot update snap namespace: cannot switch mount namespace: invalid argument) [12:17] ^ 'make hack' time? [12:17] mmmmm [12:17] it looks like something else [12:17] glad i asked first :-) [12:17] setns fails with EINVAL [12:17] oh boy [12:17] man setns [12:17] look for EINVAL [12:17] gee, than you for being specific linux [12:17] (error reporting on linux is utterly terrible) [12:17] anything in your syslog? [12:18] [269732.013362] audit: type=1400 audit(1496664970.988:633): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.powertop.powertop" pid=4654 comm="apparmor_parser" [12:18] that is ok [12:18] yeah [12:20] but that's odd [12:20] maybe make hack will fix it [12:20] because EINVAL is just "let's not do anything" in snap-update-ns === mhall119_ is now known as mhall119 === JanC_ is now known as JanC [13:12] zyga: related to this i now have a left-behind mount: none on /tmp/snap.rootfs_HcWPu8 type tmpfs (rw,relatime) [13:32] PR snapcraft#1353 opened: cli: default options for the implicit snap command [13:43] Chipaca: hmmmmm [13:43] Chipaca: so that says that snap-confine failed mid-way [13:44] Chipaca: there's a small window where certain operations are not undone if things fail as they normally should not fail and we may do more damage trying to fix that [13:44] Chipaca: can you still reproduce that? [13:44] Chipaca: and can you do so with SNAP_CONFINE_DEBUG=yes [13:44] zyga: I can try [13:45] zyga: that env, in snapd, or in snap? [13:45] Chipaca: snap [13:45] Chipaca: well, just set it in your shel [13:45] Chipaca: it's read by snap-confine [13:46] right, but they're different shells, snapd and snap :-) [13:46] zyga: where does snap-confine come into running 'snap try'? [13:46] Chipaca: it doesn't, snap try is just that [13:46] Chipaca: but then you may run configure hooks [13:47] Chipaca: are you on encrypted fs? [13:47] no [13:47] I installed a snap, removed it; try'd it, removed it, try'd it with --devmode; the last one is upset [13:47] Chipaca: interesting, well, let's see what you get [13:47] zyga: already did that, got nothing [13:48] there is no configure hook in the snap fwiw [13:48] no interface hooks :) ? (just kidding) [13:48] what does the last one say? [13:49] zyga: http://pastebin.ubuntu.com/24783714/ [13:49] zyga: that's snapd [13:50] snap just prints the two errors you see in the log anyway [13:50] hmm hmm hmm [13:51] nothing rings a bell [13:51] but it looks like update-snap-ns is old [13:51] look at cmd/snap-update-ns/bootstrap.go [13:52] it maps EINVAL to "nothing to do" [13:52] (well that's in main.go) [13:52] but you get the idea [13:52] this should not happen [13:54] sigh [13:54] ok [13:55] * Chipaca does 'make hack' [13:55] * Chipaca does 'reboot' [13:59] fwupd uses 100% cpu, hmmmm [14:00] hello folks, quick one about the maven plugin, if you have a multi module maven build any one know how to tell it where to find the jars? [14:03] magicaltrout: sergiusens or kyrofa might know [14:23] zyga, /etc/systemd/system/snapd.service.d/ and /etc/environment are the places where we should clean? [14:23] zyga, is there any other place? [14:25] cachio: I think we should look at all the .service units, just in case a test modifies it [14:26] all? [14:26] zyga, ok [14:26] cachio: well, just in case [14:26] cachio: all the snap services for sure [14:27] zyga, ok, I'll start with the snap ones [14:47] thanks zyga...... sergiusens or kyrofa any idea if maven multimodule support exists? [14:48] magicaltrout: what is maven multi module? Can you post on forum.snapcraft.io with an introduction and some flow, if this is not implemented we can work on it from that post and keep everyone updated [14:50] thanks sergiusens, in a nutshell its where you have a parent pom file that controls a bunch of different maven modules in a tree beneath it. The build works fine, but snapcraft then doesn't seem to know where to find jars cause they aren't in the top level /target directory [14:50] anyway, i'll stick something on the forums [15:00] other stupid question for snaps, if I push something to the store, is there an website version of the snap store page that I can point people to rather than just `snap find` on the cli? [15:01] magicaltrout: not officially [15:01] for people who don't know or have snappy installed it would be nice to be able to point them somewhere [15:01] magicaltrout: but there's the uxexplorer [15:02] but I cannot find it now :/ [15:03] oh well thanks zyga [15:03] https://uappexplorer.com/ [15:04] https://uappexplorer.com/apps?type=snappy [15:04] magicaltrout: ^ [15:04] nice [15:04] thanks! === bladernr` is now known as bladernr === sergiusens_ is now known as sergiusens [15:26] zyga, hey, any stopper for merging https://github.com/snapcore/snapd/pull/3353 ? [15:26] PR snapd#3353: Add support for reboot parameter [15:28] abeato: looking [15:29] merged [15:29] zyga, nice, thanks! [15:29] PR snapd#3353 closed: Add support for reboot parameter [15:45] Chipaca: question [15:45] other random question, if you have 2 parts can a file from part 2 see the file in part 1? [15:45] zyga: cryptic answer [15:45] Chipaca: open api.go please, go to getSnapInfo, look at the first InternalError there [15:45] Chipaca: what is the variable name there? [15:46] zyga: err? [15:47] Chipaca: let me show you in github [15:47] ohh [15:47] weird [15:47] * zyga looks at local code [15:47] zyga: it's err on github too :-D [15:47] ah [15:47] zyga: what's going on? [15:47] sorry :D [15:47] I pasted something in my tree that confused me [16:02] snapcraft validation file is missing from installation path <- snapcraft seems to have ground to a halt [16:02] is it possible to flush it without restarting my laptop? [16:09] Chipaca: still there? [16:09] zyga: yes [16:10] Chipaca: is muxVars the right way to get at variables encoded in the path of the URL? [16:10] zyga: it is the way that gorilla affords us [16:10] I have my reservations about it being "right" [16:10] right [16:10] hmmm [16:10] I must be doing something wrong [16:10] zyga: whacha doin'? [16:10] the code works (uses muxVars) in practice [16:10] but my tests gives me "" as the value [16:11] (unit tests) [16:11] req, err := http.NewRequest("GET", "/v2/interface/test", nil) [16:11] c.Assert(err, check.IsNil) [16:11] rec := httptest.NewRecorder() [16:11] interfaceDetailCmd.GET(interfaceDetailCmd, req, nil).ServeHTTP(rec, req) [16:11] zyga: are you setting s.muxVars? [16:11] and the "test" thing gets empty [16:11] no, should I? [16:11] ah, see, no, that doesn't go via gorilla [16:11] zyga: yeah [16:11] ahh [16:12] weird [16:12] zyga: look for s.muxVars in api_test.go [16:12] come the revolution, … :-) [16:12] just one hit [16:13] ah [16:13] s.vars [16:13] thanks!! [16:13] (ugly but well :) [16:13] * zyga is spoiled by djanog [16:13] django [16:14] s.muxVars; where is it s.vars? [16:17] Chipaca: in many places, just look [16:17] assert tests [16:17] state change [16:17] etc etc [16:17] PR snapcraft#1333 closed: state: search for the dependencies in the archive [16:22] Chipaca: is that a bug? [16:23] zyga: in many places that aren't apiBaseSuite or that embed abiBaseSuite? [16:23] oh wait [16:23] zyga: sorry, i was confused [16:23] zyga: it's totally .vars [16:24] niemeyer: https://forum.snapcraft.io/t/rest-service-endpoint/892 <- for your consideration [16:26] Looking [16:29] Yeah, interesting.. thinking [16:31] niemeyer: no hurry to it, as the rest of the work remains unchanged [16:31] Chipaca: I can't avoid punning "the rest of the work" [16:32] niemeyer: i'll allow it [16:36] Chipaca: question, spread test that runs a command and ensures that the output matches a canned text? [16:36] Chipaca: multi-line [16:37] Chipaca: can MATCH -F do it? [16:41] zyga, snapd is reading just the local.conf file? or it is reading any conf file in the /etc/systemd/system/xxunit/? [16:42] dunno [16:42] probably both [16:43] ok [16:43] cachio: snapd reads systemd conf files? [16:43] zyga: MATCH -z lets you do that; probably zF would work but let me check [16:44] Chipaca: I'll check, I'm looking for recommendation [16:44] zyga: you can't use -F and -E together [16:44] ah [16:45] Chipaca: I'll use diff [16:45] -z works though [16:45] Chipaca: no worries, the canned output will be better even [16:45] Chipaca, no [16:45] zyga: -z and $'multi-\nline\nstuff\n' works, even [16:45] thanks [16:46] I mean, but I does through systemd [16:47] Chipaca, is it right? [16:47] Chipaca, because in the local.conf can be set environment=xxxxx [16:48] cachio: I'm afraid I don't know what local.conf is [16:50] Chipaca, it is just a confiig file for the service unit that the tests are creating [16:52] ah! found it [16:53] I think it all works now [16:53] just spread run and I'll push [16:53] cachio: so yes if that file is created, and systemd gets daemon-reload'ed after its creation, snapd will have whatever extra environ is set in there [16:54] Chipaca, yes [16:55] so [16:55] I have a small thing to fix in other places, but finally feel like I climb out of a focus hole [17:08] git push [17:09] cannot push to joke/master, humor exhausted [17:13] gosh my network is slow today [17:13] core 8.42 MB / 80.45 MB 10.47% 30.50 KB/s 40m17s46s [17:13] I want a store proxy [17:13] I cannot work like that [17:13] * zyga looks at store proxy === koza is now known as koza|away [17:36] Chipaca: I know nothing about the store, I'm going to write a store proxy for caching core downloads and what not, is this insane? [17:36] Chipaca: or should I be able to do it? [17:42] zyga: uhmmm [17:42] zyga: it isn't insane [17:43] zyga: but you will have to write an application-level proxy [17:43] zyga: because the download url is returned in the json response itself, so you'll need to modify those as they go past [17:44] hmm [17:44] cannot I just cache everything blindly? [17:44] maye my questions make no sense yet, I'm still trying to grok how things work [17:45] zyga: if you're willing to tinker with certificates, you can probably get it to work as a proxy [17:45] ok [17:45] yeah [17:46] zyga: otherwise, an app-level proxy should be reasonably straightforward [17:46] as in, "i could probably write one in two about an hour if it weren't past my EOD" :-) [17:47] Chipaca: I think it's badly needed [17:47] but let me play around [17:47] you know this better [17:47] but for me it will be a learning exericse [17:47] zyga: OTOH, making snapd itself cache things could work :-) [17:48] and I can grok our store interactions more [17:48] it's probably dropping one os.Remove :-) [17:49] Chipaca: perhaps but it would not help testing mcuh [17:49] Chipaca: I want spread + qemu to be mostly offline [17:49] if not fully (I understand it will go to github to fetch things) [17:49] ah so not just downloads but the whole thing [17:49] Chipaca: I want to "freeze" the world and then have tests talk to a very agressive proxy [17:49] yes [17:50] sounds more like a recorder of sorts [17:50] anyway, sgtm [17:50] [17:50] https://search.apps.ubuntu.com/api/v1/snaps/details/snapd-hacker-toolbelt?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ccontact%2Ctitle%2Ccontent%2Cversion%2Corigin [17:50] %2Cdeveloper_id%2Cprivate%2Cconfinement%2Cchannel_maps_list: [17:50] x509: certificate signed by unknown authority [17:50] a bit mouthful error [17:52] zyga: https://forum.snapcraft.io/t/network-ish-error-messages/862?u=chipaca [17:52] niemeyer: you too ^ :-) [17:52] * niemeyer looks [17:53] mmm [17:55] * zyga has 18MB of traffic left [17:55] well [17:55] that explains things [18:05] * zyga EODs [18:05] no network, no way to work until wifi is back [18:05] which might as well be tomorrow [18:18] niemeyer: hey [18:19] niemeyer: can you please make me an editor on the forum? [18:19] niemeyer: I'd like to fix syntax / quoting in a post (*the* post I'd say) [18:24] zyga: o/ need me to do something? === bschaefer_ is now known as bschaefer [18:26] zyga: You're now a moderator.. please use it with moderation :) [18:28] lazyPower: hey [18:28] niemeyer: thank you! [18:28] lazyPower: I replied on the forum [18:28] lazyPower: I'd like to know where your lxd is coming from and which kernel is this running on [18:29] ah just got your reply on the forum, will keep the thread there [18:29] lazyPower: lastly is this your laptop/device or some specialized cloud environment, I'm just asking because I want to reproduce everything [18:29] zyga: Thanks for caring! [18:29] its my laptop zyga . i installed ubuntu desktop 16.04.2 this weekend, and have run apt-get update && apt-get upgrade. So the packages i have should be coming from archive, not from ppa's. [18:30] let me sort through the feedback and add more details [18:30] lazyPower: can you apt-cache policy lxd [18:30] I'm also on 16.04 and I don't see the same version [18:30] oh snap [18:31] http://paste.ubuntu.com/24785892/ [18:31] aha [18:31] i didnt explicitly enable a ppa, i'm curious how that got there now [18:31] ok, this should be enough, let me fire a VM for experiments and I'll get back to you! [18:31] ty zyga i appreciate you taking a look [18:45] zyga: yeah, looks like that lxd from ppa came from the conjure-up snap package in the stable channel. thats where the mixup in lxd versions came from and how i got seated on the ppa. [18:50] interesting [18:50] thanks [19:00] * zyga has working eGPU for testing nvidia/amd on *distro for snapd! [19:00] not perfect but... works [19:36] Pharaoh_Atem: hey [19:36] Pharaoh_Atem: any advice on nvidia on F26? [19:37] on what? [19:38] I got a card I can use on my fedora box [19:38] ah [19:38] but performance is beyond terrible, I cannot even run terminal comfortably [19:38] I found https://negativo17.org/nvidia-driver/ [19:38] but nothing official (fedora/nvidia0 [19:39] negativo17 or rpmfusion are both options for the nvidia driver [19:40] why aren't those in Fedora proper? [19:40] because it is against the ethos of Fedora [19:40] which is? === verterok` is now known as verterok [19:41] Fedora only ships free and open source software that isn't impaired by software patents or other legal encumberences [19:42] hmm, too bad there's no place for official but "external" things like thiat [19:43]