=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [05:33] PR snapcraft#1760 opened: tests: move the catkin integration tests to a separate suite === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:06] good morning [06:55] it's not possible to REBOOT in prepare in spread? [06:56] good morning [06:56] zyga-ubuntu: hey [06:56] I'm not working today, just doing some tax follow up [06:57] REBOOT is defined in spread as a bit of shell, I haven't tried it in prepare [06:57] i'm trying to upgrade arch in prepare && REBOOT, but got REBOOT: command not found instead [06:58] mborzecki: then it probably isnt [06:58] look at spread source code, it probably does something in sync with the host [06:59] zyga-ubuntu: thanks [07:38] omg i know, it's the refactor :) sorry zyga-ubuntu [07:55] o/ === chihchun is now known as chihchun_afk [08:12] mvo: do you know what might make snapd-notify and the classic-ubuntu-core-transition both fail [08:12] mvo: on my system snapd-notify fails reliably [08:20] Morning all [08:24] hey zyga-ubuntu [08:25] zyga-ubuntu: I'm not sure why this fails, can you pastebin the error [08:25] hey niemeyer ! good morning [08:26] morning! [08:27] PR snapd#4290 closed: snapstate: move autorefresh code into autoRefresh helper [08:28] Yos [08:29] I could swear it was Thursday.. I lost a day this week [08:30] mvo: http://pastebin.ubuntu.com/26032995/ [08:32] niemeyer: morning [08:32] you're up early [08:32] zyga: hm, strange. can you get into a debug shell? [08:33] I'm in one [08:33] zyga-ubuntu: xcould you please pastebin "journalctl -u snapd" [08:33] zyga-ubuntu: is this a regular ubuntu system? [08:33] mvo: yes, 16.04 [08:33] mvo: the pastebin above has the entire journal, there's nothing more [08:34] zyga-ubuntu: aha, no SNAPD_DEBUG=1 maybe? [08:34] no, but I can add that and re-run [08:35] zyga-ubuntu: that is the culprit, the message is only printed on debug [08:35] zyga-ubuntu: probably the smae for the other test [08:40] hmm, how to inject snapd debug [08:40] /etc/environment ? [08:40] or whatever you use in ubuntu [08:41] right but in this test we just look at syslog [08:41] and I don't want to inject it everywhere [08:41] * ikey just kills snapd and manually invokes it these days [08:41] sudo SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=3 SNAP_CONFINE_DEBUG=1 /usr/lib64/snapd/snapd does the job for me [08:41] zyga-ubuntu: you could add a file to /etc/systemd/system/snapd.service.d/debug.conf or something [08:42] zyga-ubuntu: just for this test, the restart. but why do you not want global debug enabled? its often very useful when inspecting why tests fail, no? === kira is now known as Guest13703 [08:42] hello all will my dell edge gateway support any sim [08:43] * ikey blinks [08:43] yeah, actualy [08:44] zyga-ubuntu: btw. weren't you supposed to be taking a day off today? :) [08:45] yes, just waiting for the traffic to go away :) [08:45] I was eating breakfast and doing some taxes [08:45] man knows how to start the day [08:45] xD [08:45] but you know, that debug machine is so tempting [08:45] * mvo hugs zyga-ubuntu [08:46] /nick zyga-ubuntu -> zyga-debugger [08:46] * ikey gets back to staring at prime numbers with contempt [08:59] PR snapd#4252 closed: store: fix download caching and add integration test [09:00] uhh i have a feeling that linode boots arch images with their kernel regarless of what's int the image [09:08] PR snapd#4259 closed: snapd: fix handling of undo in the taskrunner [09:11] hey pedronis, good morning. I'm just looking at 4292 and wonder if you think the right behavior is that the UserID is whoever installed it (and we keep it to that user) or whoever "touched it last"? [09:14] mvo: the latter has a better chance of making sure we are using workin creds, the former feels nice [09:16] another approach is to use for refresh the creds of the installer, not the refresher, which then would make no difference [09:16] pedronis: yeah, I currently went with the former but I'm sitting on the fence [09:16] I mean doing that even if the refresh is manual [09:16] pedronis: oh, interessting [09:17] we would still take the refresher though if UserID is currently 0 [09:17] right [09:18] pedronis: I think that sounds good, so it would be a) keep userID of installer b) on refresh, take userID from snapstate (regardless of who refreshes)? [09:18] yes, except if UserID is currently 0 [09:19] so that we have a way out of the current situation [09:19] pedronis: indeed, I like that [09:20] in practice for a system with one user it should create too many confusing situations [09:20] *it shouldn't [09:20] pedronis: :) [09:20] pedronis: yeah, I will go with this, I update the PR with the snapstate recording and then will look into configure task handlign first, then into auto-refresh with auth [09:21] pedronis: thanks (as always) for your input! [09:21] np [09:24] mvo: btw given that we are working in this area, it might make sense to capture somehow that a snap is paid (like we capture it's private atm) [09:31] mvo: so, I actuall _had_ SNAPD_DEBUG=1 set, that's what local.conf does [09:31] mvo: yet the logs are exactly the same as before [09:32] anyway, that's for next week [09:32] ttyl [09:36] hi can i use any sim module in ubuntu [09:36] And where can i get the settings [09:37] I am trying to install it on dell edge gateway [09:42] mvo: are we particularly tied to calling adduser in osutil/user.go? [09:44] mborzecki: I think not, what do you need to use for arch? [09:44] useradd .. [09:44] ok [09:44] think i broke snap [09:44] mborzecki: i think thats fine, however please note that the user adding stuff is mostly for core systems [09:45] mborzecki: which are ubuntu currently so it should not be urgent to change this (or do you have a different use case?) [09:45] mvo: great point, i'll disable the test then :) [09:45] https://hastebin.com/xibuyorobu.pl <- even after unsetting them all as reviewable i cant make the newest one reviewable.. [09:45] on the plus side my snapcraft segfault is gone [09:46] `Ready to release! [09:46] Revision 7 of 'linux-steam-integration' created. [09:46] ` [09:46] mvo: btw. the unit tests are only ran on debian and ubuntu, is this intentional? [09:46] ikey: autsch, sorry for that, that probably needs jdstrand but he is iirc not around today [09:46] yeah no worries [09:46] mborzecki: not intentional, I vaguely remember I enabled them everywhere at some point :/ [09:46] just managed to make the dashboard fart so i thought id headsup y'all [09:47] ikey: maybe the store people can help [09:47] ta [09:48] hm, found some missing libs with abireport [09:48] *fixes* === chihchun_afk is now known as chihchun [09:54] niemeyer, this is what i meant about the abireport stuff btw, highlighted missing libraries from the root: https://github.com/solus-project/runtime-snaps/blob/master/abi/abi_used_libs [09:54] * ikey is fixing ^^ [09:54] and the abi_symbols file is 5.23MB :p [09:54] ikey: hm, I don't see anything in the review queue, so it does look like somehting in the store is wonky, nessita can probably help with your https://hastebin.com/xibuyorobu.pl store issue, but she is in a .ar timezone [09:55] ok - gonna get another image uploaded first before i chase it further tbh [09:55] stabilise the ABI === chihchun is now known as chihchun_afk [10:09] ikey: Nice, that's exactly what we need I think [10:10] ikey: For the base-reviewing tasks [10:10] yeah [10:10] ikey: Probably also binaries that were removed, for similar reasons [10:10] warning 5MB: https://github.com/solus-project/runtime-snaps/blob/master/abi/abi_symbols [10:10] yeah ive just done the same, and ripped some systemd binaries out of the rootfs [10:11] it doesnt do c++filt mutations - they wouldn't let you know that ABI changed [10:11] just API really [10:11] besides nobody really cares *what* the symbols are as such, just that "oh crap I lost 4000 symbols on this change" [10:12] ikey: Right, spot on [10:13] fwiw we do this at the packaging level too, its great for an early warning that somethings amiss or pain is due ^^ === chihchun_afk is now known as chihchun === __chip__ is now known as Chipaca [10:59] ikey: if you want more certainty about ABI changes, check out Abigail: https://sourceware.org/libabigail/ [10:59] seen it, overkill :D [10:59] tis why i built abireport in the first place [10:59] its a high level overview basically [10:59] https://github.com/clearlinux/abireport [11:00] we can quickly track changes like so: https://dev.solus-project.com/R545:81e86e35ad503ce3df7387a3b9b6f17671a06b1a [11:00] all part of the build process [11:00] on a previous project we used abi-compliance-checker, but it is slow and hard to configure [11:01] ikey: there's so many ABI changes that won't show up in the symbol table though [11:01] sure - but it requires being a sensible distro dev [11:01] the vast majority of ABI-you-should-care-about will show up [11:02] sonames, linker versions and actual symbols [11:02] its more similar to nm -g --dynamic --defined-only [11:02] saved my backside more times than i care to count [11:03] the abi_used_libs{,32} files come from DT_NEEDED cruft [11:03] as solus forces -as-needed at the toolchain level (via binutils) [11:03] i.e. not via cflags [11:03] so does Ubuntu, IIRC [11:03] ah handy [11:04] it causes some problems for janky build systems that have link order incorrect [11:04] but we can unset LD_AS_NEEDED in environment to workaround it [11:04] btw nice work on the startup times for desktop snaps :D [11:04] well, the package build infrastructure. It doesn't change the behaviour of the tools you install on Ubuntu [11:04] right, our build stuff (ypkg) sets LD_AS_NEEDED in the environment [11:04] which triggers the change in binutils to force the behaviour [11:05] default user environment doesnt trigger it [11:05] so in the package.yml we'd just do: unset LD_AS_NEEDED [11:06] example: https://github.com/solus-project/runtime-snaps/blob/master/support_packages/mesa/package.yml#L48 [11:08] pstolowski: thanks for the review :) [11:16] PR snapd#4293 opened: snapstate: store if a snap is a payed snap in the sideinfo [11:18] surely we mean Paid? [11:18] >_> [11:22] ikey: yes [11:23] ikey: English is hard [11:23] cool - i just didnt know if i was misreading :p [11:24] ikey: maybe it's a typo and we're working on snaps reaching plaid speed [11:25] aha [11:25] mvo: thanks, I can pick up that PR after lunch, there's also a couple of places in store that can use that flag I think [11:26] mborzecki, np, still reviewing [11:27] any idea what might be the reason for 'stateengine.go:98: state ensure error: devicemgr: cannot find account (testrootorg)' ? [11:31] * sergiusens waves good morning === chihchun is now known as chihchun_afk [11:49] pedronis: sounds good, thank you [11:49] mborzecki: this error indicates the testrootorg account was not added in some test. where do you see that? [11:50] mvo: when running linode:arch-2017.07.01:tests/main/classic-custom-device-reg [11:51] mborzecki: is this snapd compiled with the "testkeys" option? [11:52] mborzecki: build tag for go is: "withtestkeys" [11:53] hmm that would explain it, the package is built without any additional tags passed to go [11:53] mborzecki: yeah, but I think you still found a bug :) [11:53] mborzecki: usually we ahve a if [ trusted keys ] guard for tests that need it [11:54] can't tell, i'm randomly jumping around asserts/database.go and overlord/assertstate :) [11:55] mborzecki: it seems like our code could be smarter that sets TRUST_TEST_KEYS [11:55] mborzecki: anyway, the error itself should go away if you build it with this flag [11:55] mvo, ikey checking [11:55] mvo: i think it's on me, the package that's built for arch does not have this tag set [11:55] mborzecki: (obviously this is only for testing) [11:55] i see now that the rpm built during tests sets this [11:55] checking what on the who now [11:56] mborzecki: cool, good luck [11:56] *squirrel* [12:02] mvo, ikey I moved revision 6 to manual review and then as reviewer I ran the automated checks agains, there is one failure [12:02] " [12:02] (NEEDS REVIEW) type 'base' not allowed lint-snap-v2_snap_type_redflag [12:02] " [12:03] yeah that one i know about :D [12:03] ikey: mborzecki: fyi the static checks caught the payed vs paid thing [12:03] the revision 7 review should start soon [12:03] i wouldnt bother nessita honestly [12:03] Chipaca: I'm taking up that PR [12:03] im building revision 8 [12:03] to fix one last issue with the runtime [12:03] then that'll be my final runtime for jdstrand to sign off on [12:03] "one last issue" <- lol [12:03] lol [12:03] it was missing libkmod [12:03] ikey, well but until revision 7 is reviewed, revision 8 will not be -- you can reject revision 7 yourself [12:04] sure but none of them will pass review right now anyway :D [12:04] they're all base [12:04] autoreject [12:04] ikey, kk [12:04] thanks though - i just wanted to unclog whatever it was i busted earlier xD [12:05] well im also compiling mesa + glibc again so it might take a small while before this snap is done.. >_> [12:05] * ikey adds weekend TODO about having caching for this process [12:49] we're setting LANG=C.UTF-8 in environment for the tests, would switching to LANG=C and probably LC_ALL=C be a big issue? [12:51] PR snapd#4294 opened: Mount with x-gdu.hide option [12:53] PR snapcraft#1761 opened: lxd: ContainerConnectionError on failed launch/ start [12:54] mborzecki: in what distro? [12:54] afaik c.utf-8 is a debianism [12:54] althouh i think redhat picked that up as well; not sure [12:55] mborzecki: we mostly use C.UTF-8 to avoid python3 exploding all over the place if it is not in a utf-8 locale (at least iirc) [12:55] mvo: Chipaca: I updated the paid PR [12:55] pedronis: \o/ [12:58] hm arch [12:58] yeah, it doesn't like C.UTF-8 at all [12:59] C.UTF-8 is non-standard [12:59] i've added an override LC_ALL=C in the test to workaround this [12:59] this will have to do probably :) [13:00] failing that, en_US.utf8 [13:11] while C.UTF-8 is non-standard, it might be worth generating it with localedef if it isn't there, because there's no standard way to get a UTF-8 locale and the tests probably do need one [13:11] PR snapd#4295 opened: tests/main/manpages: set LC_ALL=C as man may complain if the locale is unset or unsupported [13:11] I forget the exact invocation of localedef you need but it's not hard [13:17] there's an example at the end of locale(1) that'll probably get you most of the way there [13:18] hm snapcraft is being rather communicative [13:18] it likes you ! [13:18] https://ibin.co/3iOpZnKAHMIs.png <- is there an expectation that i have xdelta installed? [13:19] if oyu want to save bandwith you want xdelta [13:19] well xdelta3 [13:20] sure but im wondering if this needs to be in the snapcraft snap [13:20] because there are a lot of xdeltas [13:20] sounds reasonable that it ships it, yeah [13:20] i mean im happy to install ofc - just wondering about the intricacies of it [13:20] i like that i get the feedback in the terminal now [13:21] and i will reluctantly admit that its handy to select revisions for promotion from the cli [13:23] Chipaca: that's close to what I was thinking of, yes. In fact the specific invocation for C.UTF-8 should be in the Debian glibc packaging [13:23] debian/rules.d/build.mk:108: I18NPATH=$(CURDIR)/localedata GCONV_PATH=$(DEB_BUILDDIR)/iconvdata localedef --quiet -c -f UTF-8 -i C $(CURDIR)/build-tree/C.UTF-8 ; \ [13:23] should be able to drop I18NPATH and GCONV_PATH from that [13:25] right, so looks like localedef --quiet -c -f UTF-8 -i C ./C.UTF-8 would work, and then point LOCPATH to that === __chip__ is now known as Chipaca [13:37] cjwatson: thanks for the tips, that's something that could probably be applied to arch at disto level [13:38] Could just be done globally - no reason for that to be distro-specific I think [13:38] I mean, Debian-derived distros have a C.UTF-8, but you can generate another local version of it harmlessly [13:41] pedronis, the issue about gpg is that the dir "/root/.snap/gnupg/private-keys-v1.d" is missing [13:41] cachio: mmh [13:41] cachio: I need to dig, I have seen that dir sometimes, but I don't know why it's there/created [13:41] pedronis, I created this and the snap create-key started working [13:42] it's probably a really bug [13:42] *real bug [13:42] not a serious one but annoying [13:42] pedronis, but, the first time it works [13:43] I execute snap-create-key test alone and it pass [13:43] but if I use -repeat 2 the secont execution fails [13:44] mmh, no, I was confused [13:44] this is from gpg itself [13:45] or something else [13:45] I'm confused [13:47] pedronis, I am gonna run again and see it this fir exists the first time [13:48] cachio: there's some explanation about that dir here: https://www.gnupg.org/faq/whats-new-in-2.1.html , see Removal of the secret keyring [13:49] cachio: do we cleanup ~/.snap/gnupg between tests? [13:51] pedronis, I think so [13:52] pedronis, checking [13:53] in reset_classic we do: rm -rf /root/.snap/gnupg [13:54] yes [13:57] elopio: would you be familiar with the test failures in https://travis-ci.org/snapcore/snapcraft/jobs/306445933 ? locally it is passing, would you know how to reproduce it in xenial ? [14:09] PR snapd#4296 opened: packaging/arch: pre-create snapd directories when packaging [14:12] PR snapd#4108 closed: repo: ConnectedPlug and ConnectedSlot types [14:15] Lunch, biab [14:18] pedronis, I pushed the fix [14:18] pedronis, thanks for helping [14:21] cachio: ah [14:21] ikey it is in the snapcraft snap (xdelta3), you just found a bug that's all :-) [14:22] ah gotcha [14:23] cachio: wondering if we shouldn't stop/restart the agent instead ? [14:23] * kalikiana food [14:27] pedronis, testing that [14:27] pedronis, the change works [14:30] pedronis, In sid the agent is creating that dir in case it does not exist any more [14:30] pedronis, I supose they fixed after v 2.1.18 [14:30] pedronis, I'll take a look to che changelog [14:47] niemeyer, fedora 26 passed [14:47] cachio: \o/ [14:47] niemeyer, should I add this as manual execution? [14:47] cachio: Any reason not to do automatic, other than the extra worker? [14:48] niemeyer, no, just the workers needed [14:48] Son_Goku: Any ideas here? [14:48] niemeyer, then we will have fedora 27 [14:48] niemeyer: eh? [14:48] and rawhide [14:48] ideas for what? [14:49] Son_Goku: Value of running tests on Fedora 26 at all times.. we'll be working on 27 and rawhide next [14:49] well, 26 is a currently supported stable release for a year [14:49] but if you'd rather only support 27 and rawhide, that's fine [14:49] let's just not be in a position where we're stuck on an old version for too long [14:49] Son_Goku: Any stats on user base? Do we have a significant percentage of users there still? [14:50] no idea [14:50] Fedora doesn't collect stats [14:50] Son_Goku: Well, I'm sure file servers have logs [14:50] in the mirror network, probably [14:50] but the best way to figure this out would be the store side logs [14:51] Son_Goku: Good point [14:51] each snapd version is encoded with their package release version [14:51] which has the .fcXX suffix encoded [14:52] cachio: Ok, I suggest enabling 27 and rawhide first, and let's talk to the store team to see if we can figure out any hints of demand [14:52] so snapd 2.29.4 from Fedora 26 will say its version is 2.29.4-2.fc26 [14:52] cachio: We can keep manual meanwhile [14:52] niemeyer, sure [14:52] Son_Goku: Thanks for the details [14:52] np [14:53] niemeyer, I'll continue with fedora 27 [14:53] got at least 12 solus users with snapd [14:53] incidentally, I encode this data in the snapd version because from time to time, I do patches/backports that differ from you guys [14:53] makes it easier to identify where a breakage might happen (if it ever does) [14:53] ikey: It's a good start! :) [14:54] :D [14:54] there's *probably* more than 12 Fedora users :P [14:54] nah [14:54] never heard of it [14:54] >_> [14:55] Son_Goku: idk I stopped using it ~3 months ago :) [14:55] ... [14:55] :O [14:55] niemeyer, happy: https://github.com/solus-project/runtime-snaps/blob/master/abi/abi_used_libs [14:55] is empty ^_^ [14:55] * Son_Goku collapses in glum agony [14:56] yeah, got lazy at some point, didn't want to go through another upgrade and installed tumbleweed just for the lulz [14:56] when i move to implementing apparmor confinement (post snapd stable release and store inclusion of both edges) - then ill need to move stuff like theme assets from runtime to the lsi snap itself [14:56] mborzecki, they still got their sysvinit-on-top-of-systemd thing going on? [14:57] ikey: btw, are there any changes of yours left that aren't part of snapd 2.29.4? [14:57] that i dont know [14:57] I may want to cherry-pick those into Fedora snapd [14:57] maybe, can't tell, it was awkward, everything seemed broken, spent the last 3 months or so fighting with policykit as it kept asking me for root (yeah root) password to authorize any operation [14:58] i dont think i have pending PRs [14:58] mborzecki: with snapd? [14:58] on Fedora? [14:58] mborzecki, ah that reminds me i need to upstream my polkit patches this weekend.. [14:58] in solus we removed JS from polkit [14:58] >_> [14:58] mborzecki: I literally just fixed that last week [14:58] cachio: I'm seeing errors being reported about fedora-25 in travis [14:58] cachio: In unrelated PRs [14:58] Status code: 502 for https://mirrors.fedoraproject.org/metalink?repo=fedora-25&arch=x86_64 [14:59] this is our polkit policy definition :P https://dev.solus-project.com/source/gvfs/browse/master/files/org.gtk.vfs.file-operations.keyrules [14:59] cachio: Known? [14:59] Son_Goku: ^ [14:59] niemeyer: that's the Linode mirror being broken [14:59] Son_Goku: if it's any consolation, my wife, who's got nothing to do with IT whatsoever is runnig the latest fedora on her laptop and prefers it to any other distro i had installed her before [14:59] Son_Goku, i dont see any open PRs from me on github [14:59] Son_Goku: ;( [15:00] so my nvidia work is in [15:00] I believe Linode has a mirror override for their IP block (Fedora MirrorManager lets you register private and public mirrors in that manner) and their mirror is awful [15:00] we might want to flesh out desktop-helpers to support the new system though? [15:00] niemeyer: I have a similar override in place for my workplace for its local mirror [15:00] for vulkan + biarch nvidia.. [15:00] ikey: right === chihchun_afk is now known as chihchun [15:01] but RADV and Intel Vulkan should work, right? [15:01] wait i just said 'we' [15:01] y'all done stockholmed me [15:01] :P [15:01] Son_Goku, as long as they're present [15:01] and accessible in some fashion [15:01] f.e. solus-runtime-gaming ships a full weight mesa with the vulkan drivers [15:01] hmm [15:01] and can use the "host" vulkan for nvidia support [15:02] but it requires the icd loader inside the snap runtime or snap itself [15:02] i.e. libvulkan.so.1 [15:02] i suspect we've got some apparmor confinement nightmares to work out there [15:02] but lsi is a good place to debug that [15:02] as its a meaty runtime [15:02] uh oh [15:02] I fucked up [15:02] onoes [15:03] oh wait [15:03] panic averted [15:03] snapd-selinux is there [15:03] yeah tell that to golang [15:03] >_> [15:03] hahah [15:03] and now im making programming jokes [15:03] for a minute there, I thought I might have accidentally not built it [15:03] * ikey is taking himself out tonight [15:03] like, out to a pub [15:03] not gonna mobhit myself as i have dinner [15:03] haha [15:04] can't even begin to work out the logistics for having myself still surprised by the event *and* having meaningful last words.. [15:05]