[00:27] <mup> PR snapcraft#1805 opened: lifecycle: use the -no-fragments mksquashfs option <Created by tyhicks> <https://github.com/snapcore/snapcraft/pull/1805>
[02:44] <mup> PR snapd#4396 opened: snap: use the -no-fragments mksquashfs option <Created by tyhicks> <https://github.com/snapcore/snapd/pull/4396>
[06:39] <mborzecki> morning
[06:56] <mup> PR snapd#4395 closed: update HACKING.md for distro build dependencies <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4395>
[08:03] <kalikiana> good morning
[08:08] <mborzecki> kalikiana: morning
[09:03] <Chipaca> mborzecki: o/
[09:03] <mborzecki> Chipaca: hey
[09:03] <Chipaca> mborzecki: would now be a good time to rant about the insanity of signed st_size
[09:04] <mborzecki> hahaha :) that's the ParseInt() thing?
[09:05] <Chipaca> mborzecki: yeah
[09:05] <Chipaca> mborzecki: stat64's st_size is a long long
[09:06] <Chipaca> mborzecki: stat's st_size is unsigned long (not unsigned long long)
[09:07] <Chipaca> (it's just an unsigned int on 64 bits, in fact; it's unsigned long on i386)
[09:07] <mborzecki> Chipaca: fair enough
[09:08] <Chipaca> mborzecki: and golang's os.FileInfo's Size() returns an int64
[09:08] <Chipaca> mborzecki: and i it bothers me _every_ _time_
[09:08] <Chipaca> like, who's this person going around creating negative-sized files
[09:08] <Chipaca> i'd like a word
[09:10] <pedronis> Chipaca: is there some call that returns size_t directly, usually the reason is to mark errors as -1
[09:10] <mborzecki> Chipaca: can you add a comment there in the code? just in case someone stubles on it in the future
[09:10] <Chipaca> pedronis: getuid reutrns unsigned ints, and uses -1 as a flag value
[09:11] <Chipaca> mborzecki: psh. comments. what's next, *tests*?
[09:11] <Chipaca> pedronis: but, yeah, probably
[09:11] <mborzecki> Chipaca: nah, tests you can skip
[09:11] <Chipaca> pedronis: and I guess the feeling is if reaching the limit of 63 bits is close, 64 bits is just as close
[09:11] <Chipaca> mborzecki: :-D
[09:11] <Chipaca> mborzecki: i'm quoting you on that one
[09:13]  * Chipaca looks forward to having 20EB sd cards
[09:15] <pedronis> Chipaca: also defining off_t would be hard
[09:16] <mborzecki> Chipaca: i'm doing a meetup on go at my local group today, will reference both golang bugs that you found (geteuid and syscalls that must fail, even if they don't)
[09:16] <Chipaca> mborzecki: heh
[09:17] <Chipaca> mborzecki: those are mundane compared to the threading one :-) but ok!
[09:17] <mborzecki> i'll be showing the actual bits of go's asm that are responsible
[09:18] <Chipaca> pedronis: are you reviewing that PR? just asking to know if i should wait before pushing the changes
[09:18] <pedronis> Chipaca: no, I don't even know what PR you are talking about, I need a belated breakfast actually :)
[09:19] <Chipaca> pedronis: breakfast >> reviews
[09:32]  * kalikiana coffee break
[09:38] <JamieBennett> Any idea why none of my snaps can save settings? Happening with Corebird and Mailspring. I'll change settings, they will be reflected in the UI but not saved. When I go back to the settings of the app the old values are still there.
[09:51] <pstolowski> JamieBennett, any denials in the logs?
[09:56] <sergiusens> JamieBennett check ownership of files/dirs in ~/snap
[09:57] <JamieBennett> pstolowski: Only denial I see is this but it looks unrelated: Dec 13 09:37:00 ubik kernel: [ 1876.976847] audit: type=1107 audit(1513157820.788:1187): pid=1834 uid=106 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=10850
[09:57] <JamieBennett> label="snap.mailspring.mailspring" peer_pid=1820 peer_label="unconfined"
[09:57] <pstolowski> right, seems unrelated
[09:58] <JamieBennett> sergiusens: permissions looks OK too
[09:58] <JamieBennett> It's strange
[10:00] <pstolowski> JamieBennett, also, does it create any (possibly hidden) files in ~/snap/.. as you modify & save settings? 'find ~/snap` before and after might give a clue
[10:00] <mborzecki> hmm corebird seems to work just fine here, the settings are preserved and i can actually see then on d-conf
[10:01] <JamieBennett> Seems I am getting quite a few denied messages for dbus
[10:02] <JamieBennett> http://paste.ubuntu.com/26175781/
[10:02] <mborzecki> JamieBennett: anything with ca.desrt.dconf ?
[10:08] <JamieBennett> Even stranger, if I change settings then close Corebird and reopen, the new settings are there.
[10:08] <mborzecki> JamieBennett: stat `dconf watch /org/baedert/corebird/` and run corebird, change some settings, you should see dconf watch listing updaated keys
[10:08] <Chipaca>  if [ ! -e $(ls -1 /var/lib/snapd/snaps/ubuntu-core_*.snap | tail -1) ]; then exit 1; fi
[10:08]  * Chipaca wonders
[10:09] <JamieBennett> mborzecki: nothing
[10:10] <JamieBennett> Chipaca: ls: cannot access '/var/lib/snapd/snaps/ubuntu-core_*.snap': No such file or directory
[10:10] <Chipaca> ogra_: you're my favourite sh expert: does the above make any sense to you? as opposed to just [ -e /var/lib/snapd/snaps/ubuntu-core_*.snap ] ?
[10:10] <Chipaca> JamieBennett: uh, sorry, this's unrelated to your woes
[10:10] <JamieBennett> lol
[10:12] <pedronis> Chipaca: I think you get an error from -e  if there is more than one argument
[10:12] <Chipaca> hm, probably
[10:13] <Chipaca> just the ls, then :-)
[10:13] <pedronis> but yes, it's a weird way to check
[10:14] <JamieBennett> mborzecki: do external links in tweets work for you?
[10:14] <JamieBennett> (in Corebird)
[10:14] <Chipaca> JamieBennett: are the corebird interfaces connected?
[10:15] <JamieBennett> Chipaca: yes, gsettings, home, network, ...
[10:15] <mborzecki> JamieBennett: yes (note, i'm running latest snapd master)
[10:15] <Chipaca> JamieBennett: dbus?
[10:16]  * JamieBennett cannot see a dbus interface
[10:16] <pedronis> have we got any green runs in the last days?   all the recent PRs seem red
[10:16] <JamieBennett> what is the exact name? Should it be dbus?
[10:16] <Chipaca> pedronis: my pr was green yesterday
[10:16] <Chipaca> pedronis: first try, too
[10:16] <pedronis> impressive
[10:17] <Chipaca> pedronis: and finishing at ~5pm which is peak SF
[10:17] <JamieBennett> Chipaca: https://pastebin.ubuntu.com/26175847/
[10:17] <mborzecki> pedronis: and timing out
[10:18] <Chipaca> JamieBennett: 'snap interfaces corebird' would've been nicer :-D
[10:18] <Chipaca> JamieBennett: corebird:dbus-corebird           -
[10:18] <JamieBennett> Chipaca: well, I'm having issues with snaps all round so pasted them all
[10:19] <Chipaca> JamieBennett: output of 'snap version'?
[10:19] <JamieBennett> https://www.irccloud.com/pastebin/I1GemYmg/
[10:22]  * mborzecki restarting master branch travis job for the 4th time
[10:23] <Chipaca> JamieBennett: so, about corebird, if you even get a window you're ahead of me
[10:24] <JamieBennett> Mailspring was the other that is not saving settings for me
[10:24] <Chipaca> oh it took ages but finally popped up
[10:24] <Chipaca> it tried to download and bunzip an h264 decoder (wat)
[10:25] <Chipaca> JamieBennett: but, the link on "Create one" worked, so that works
[10:25] <JamieBennett> Chipaca: What I tried to do was turn autoscroll on in settings, close the settings window, then go back and see if it is still enabled
[10:27] <Chipaca> JamieBennett: in corebird?
[10:28] <JamieBennett> yes
[10:29] <Chipaca> JamieBennett: how do i get to settings?
[10:29] <JamieBennett> The cog in the titlebar
[10:30] <Chipaca> JamieBennett: i have no cog in my titlebar
[10:30] <JamieBennett> next to minimise?
[10:31] <Chipaca> JamieBennett: https://i.imgur.com/tXRVd4A.png
[10:31] <JamieBennett> Ah, you have a different theme too, everything is on the left, I'm on 17.10 and everything is on the right
[10:32] <Chipaca> JamieBennett: this is sparta^W16.04
[10:33] <JamieBennett> https://usercontent.irccloud-cdn.com/file/F4QDY6Gw/Screenshot%20from%202017-12-13%2010-32-40.png
[10:33] <JamieBennett> Chipaca: I think there is a more general problem as no snaps seem to be able to save settings, external links in snaps do not work e.t.c.
[10:33]  * JamieBennett keeps digging
[10:34] <Chipaca> JamieBennett: it does sound like something is broken
[10:34] <Chipaca> JamieBennett: have you tried seeing if running core from stable fixes things?
[10:35] <JamieBennett> no, lets try that
[10:36] <JamieBennett> Chipaca: nope, that wasn't it
[10:42] <Chipaca> JamieBennett: I don't have many ideas. I'd normally point you at zyga...
[10:45] <JamieBennett> np, just debugging dbus at the moment, it definitely looks like something is wonky there
[10:58] <pedronis> Chipaca: we will have to turn off some suites or something until we decide what to do, I really would like to merge a couple small PRs before leaving
[10:59] <pedronis> for the holidays
[11:07] <sergiusens> JamieBennet Chipaca snap run --shell corebird ... then touch $SNAP_USER_COMMON/stub and verify that works
[11:08]  * sergiusens is on his phone warming up on a static bike to get started with physiotherapy 
[11:09] <Chipaca> pedronis: i'm trying something that might make a difference (maybe too small to be noticeable though, will see if it works at all first)
[11:16] <Chipaca> pedronis: the biggest issue seems to be i/o timeouts from linode :-/
[11:17] <Chipaca> the second issue seems to be that the images haven't been refreshed in too long (or could use some love to be quicker)
[11:18] <Chipaca> (locally in my qemu images i cut down the time by ~15 minutes for 14.04 just by doing all the setup faff beforehand
[11:18] <Chipaca> )
[11:18] <pedronis> I'm sure, I'm looking for a remedy for the next 3 days that doesn't need Gustavo though
[11:19] <Chipaca> yeah
[11:20]  * pedronis lunch
[11:20] <Chipaca> pedronis: that's what i'm trying out: i have a branch that does a single apt-get for distro_install_package instead of one per package
[11:20] <Chipaca> pedronis: and replaces all -comp xz with -comp gzip in ~5 mksquashfs calls we have in tests
[11:20] <Chipaca> between them it might shave 10 minutes or more, depending
[11:20] <Chipaca> testing it now
[11:24] <mborzecki> Chipaca: are msquashfs calls done in prepare?
[11:26] <Chipaca> mborzecki: in core, yes, one
[11:27] <Chipaca> mborzecki: and in the prepare of cmd/snap-confine/spread-tests/regression/lp-1599608/task.yaml
[11:27] <Chipaca> mborzecki: and tests/main/ubuntu-core-custom-device-reg-extras/task.yaml
[11:28] <Chipaca> mborzecki: and tests/main/confinement-classic/test-snapd-hello-classic/Makefile
[11:28] <Chipaca> mborzecki: and tests/main/ubuntu-core-custom-device-reg/task.yaml
[11:28] <Chipaca> mborzecki: and tests/main/ubuntu-core-gadget-config-defaults/task.yaml
[11:28] <mborzecki> ah, right, the ones that were in the pr
[11:29] <Chipaca> mborzecki: </ul>
[11:29] <Chipaca> :)
[11:29] <mborzecki> one thing I observed while browsing logs today: https://paste.ubuntu.com/26176245/
[11:29] <mborzecki> this is right before the timeout
[11:30] <mborzecki> tests/main/lxd task
[11:30] <Chipaca> mborzecki: yeah
[11:31] <mborzecki> any idea what's the size of this rootfs?
[11:31] <Chipaca> mborzecki: it should be possible to do that beforehand also :-/
[11:32] <mborzecki> 10+ minutses of project prepare, blazing fast download and we're pushing the job timeout limit
[11:38] <Chipaca> ummm
[11:39] <Chipaca> i just got green on my pr again
[11:39] <Chipaca> dunnno what y'awl are moanin' about
[11:39] <Chipaca> :-p
[11:39]  * Chipaca is sure to be run over by a bus after this amount of good luck
[11:45] <pedronis> Chipaca: this 2 lines PR takes regularly 49+ mins:  https://github.com/snapcore/snapd/pull/4388
[11:45] <mup> PR #4388: overlord/snapstate: fix auto-refresh summary for 2 snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/4388>
[11:50] <mup> PR snapd#4397 opened: tests/main/lxd: temporarily switch to manual <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4397>
[11:50] <mborzecki> another experiment, trying to see if this is the culprit
[11:53] <Chipaca> my test run is dying a death of a thousand "no powered off servers in Linode account exceed halt-timeout" :-/
[12:03] <Chipaca> still seeing ~10 min prepares though
[12:27] <mup> PR snapd#4398 opened: overlord/auth,daemon: introduce an explicit auth.ErrInvalidUser <Created by pedronis> <https://github.com/snapcore/snapd/pull/4398>
[12:28] <pedronis> Chipaca: mborzecki: simple PR (split out from my larger one) ^
[12:43]  * Chipaca ~> lunch
[12:57] <Vamsi> Hello, is it possible for me to license snaps that I build? Is there an online documentation where I can read more on this?
[12:59] <Chipaca> Vamsi: license in what sense?
[13:01] <jdstrand> JamieBennett (cc pstolowski): that is definitely unrelated
[13:02] <Chipaca> pedronis: standup?
[13:02] <jdstrand> JamieBennett (cc pstolowski): (bluez)
[13:02] <JamieBennett> jdstrand: thanks for confirming
[13:04] <Vamsi> Chipaca: such that I can make my snap a paid snap without falling into trouble.
[13:06] <Chipaca> Vamsi: support for for-pay snaps isn't there yet -- JamieBennett or noise][ might have more detail
[13:07] <jdstrand> JamieBennett: you should connect screen-inhibit-control for irccloud
[13:07] <Vamsi> So no snap crurrently is a paid snap? All are free?
[13:07] <jdstrand> JamieBennett: there are a couple also unrelated denials in there that I'll investigate
[13:07] <JamieBennett> Vamsi: that is correct, the service has not been launched yet
[13:09] <Vamsi> okay. thanks :)
[13:14] <pstolowski> jdstrand, thanks for checking
[13:23] <mborzecki> hm looking at some logs from ubuntu-14.04 and analyzing them with mvo's script, there's 13 minutes of prepare time, then the top tests take ~7 minutes, leaving us with 29 minutes for ~237 tests
[13:24] <mborzecki> that's 120ms per test :)
[13:28] <Chipaca> mborzecki: https://github.com/snapcore/snapd/compare/master...chipaca:dumb-spread-tweaks
[13:29] <Chipaca> mborzecki: that's why we have multiple workers (and why prepare time is so crucial)
[13:32] <pedronis> most systems have 4 workers
[13:34] <mborzecki> Chipaca: pushed your commit to #4393 and #4391
[13:34] <mup> PR #4393: travis: separate unit tests into separate build matrix jobs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4393>
[13:34] <mup> PR #4391: travis, run-checks: split travis job into build matrix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4391>
[13:35]  * kalikiana time for lunch!
[13:39] <pedronis> Chipaca: also afaiu  we run 3 travis jobs and have 80 machines,  atm all workers for a job = 27 (6*4+3),  27*3 = 81, so we are a tiny bit overallocated as well
[13:42] <Chipaca> pedronis: ooh, that'll be biting at least 1/3 of our jobs when we're busy :-(
[13:43] <Chipaca> can that be dropped to 2, or does that also need gustavo?
[13:45] <mup> PR snapd#4398 closed: overlord/auth,daemon: introduce an explicit auth.ErrInvalidUser <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4398>
[13:45] <pedronis> Chipaca: that can be changed in travies I think
[13:45] <Chipaca> ah yes
[13:45] <Chipaca> should I?
[13:46] <pedronis> Chipaca: we can do that, or disable one of the distros
[13:47] <pedronis> temporarely  (though suse has been disabled temporarly for a long time now)
[13:47] <Chipaca> pedronis: i've set it to 2 for now
[13:47] <Chipaca> pedronis: let's see with mborzecki's matrix how things look
[13:51] <mborzecki> pedronis: i suppose you can find a time scale where 'long time' feels temporary :)
[13:53] <Chipaca> mborzecki: is 9.5 minutes prepare for 14.04 an improvement?
[13:54] <mborzecki> yup
[14:10] <mborzecki> Chipaca: 14.04 finished in 34 minutes
[14:10] <Chipaca> mborzecki: so not necessarily better, but not necessarily worse
[14:11] <mborzecki> in previous run of #4393, ubuntu-14.04 finished in 24 minutes
[14:11] <mup> PR #4393: travis: separate unit tests into separate build matrix jobs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4393>
[14:13] <Chipaca> mborzecki: but also timed out at 49+?
[14:13] <mborzecki> 16.04 hit a timeout in that build
[14:14] <pedronis> well if we were overallocated, each run might have depended on when it got the last worker (unless it simply died unable to get it at all within allowed time)
[14:14] <pedronis> I don't know how retrying spread does to get machines
[14:14] <pedronis> *how much
[14:23] <jdstrand> kyrofa: hey, I think zyga was looking at the lxc snaps not updating with priority last week. I believe he has vacation to burn and is not around a lot atm
[14:38] <kalikiana> ^^ zyga eoy'ed already
[14:38] <kalikiana> re
[14:45] <anddam> hello
[14:45] <Chipaca> anddam: hello
[14:47] <daniellimws> hi how can I run the scripts in tools/travis locally?
[14:49] <kalikiana> daniellimws: you'll probably want to have a chat with elopio about that
[14:49] <daniellimws> ok it is regarding this task http://paste.ubuntu.com/26171261/
[14:56] <daniellimws> from the conversation above, I probably should not send this to travis untested, to avoid eating up resources right?
[14:57] <kalikiana> daniellimws: yes and no... I believe there was another task to make it possible to run it locally as you're asking, but it's not possible right now
[15:00] <daniellimws> kalikiana: Well I suppose I'll just commit it then, since there's nothing running now it seems. If it's faulty it will die very quickly.
[15:01] <kalikiana> daniellimws: Yeah. I'd say go ahead. And otherwise leo should be around soon
[15:02] <anddam> is snappy a Canonical's project?
[15:06] <mup> PR snapcraft#1806 opened: ci: transfer generated snapcraft snap to transfer.sh <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1806>
[15:18] <pedronis> mborzecki: what's the difference between #4391 and #4393  ?  given that John reduced the travis jobs they will eat even more travis chances
[15:18] <mup> PR #4391: travis, run-checks: split travis job into build matrix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4391>
[15:18] <mup> PR #4393: travis: separate unit tests into separate build matrix jobs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4393>
[15:18] <pedronis> can one be closed?
[15:18] <mborzecki> pedronis: 4393 has unit tests as a separate job
[15:19] <mborzecki> afaiu, travis is gating job execution already, so those should not eat up all the nodes
[15:20] <pedronis> they don't eat nodes, they eat travis jobs
[15:20] <pedronis> exactly
[15:20] <pedronis> to be clear I'm not against the experiment, I'm against having the experiment twice
[15:20] <pedronis> given our current constraints
[15:20] <mborzecki> also, unit tests were supposedly taking quite long, so the idea was to see whether moving those to separate jobs has a positive effect on the build time
[15:21] <mborzecki> hm i guess, i can cancel 4393 job for now, and i'll restart it in the evening
[15:22] <pedronis> Chipaca reduced travis jobs to 2 thinking about other stuff, that approach would need more jobs (if possible) instead :/
[15:22] <mborzecki> and i've canceled the jobs that were not started yet in 4391
[15:23] <mborzecki> pedronis: yeah, we need to find a sweet spot, or write a spread job runner :P
[15:24] <mup> PR snapcraft#1793 closed: project: refactor storeapi <Created by daniellim2000> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1793>
[15:24] <pedronis> yea, except that one of the motivation of spread was indeed not to be on task of running a permanent service :/
[15:25] <pedronis> trade-offs
[15:58] <Chipaca> anddam: what do you mean?
[16:01] <Chipaca> pedronis: how are your jobs faring with the new limit? any further luck?
[16:16] <Chipaca> should we make snapcraft or the store discourage people from calling something "foo-snap"?
[16:16] <Chipaca> sergiusens: ^ wdyt?
[16:17] <niemeyer> Hey folks
[16:17] <niemeyer> I'm in NY and headed to the hotel
[16:17] <niemeyer> A bit tired but can probably try to help moving a few things forward when I get a room
[16:17] <niemeyer> cc pedronis Chipaca
[16:18] <Chipaca> niemeyer: ack
[16:18] <Chipaca> niemeyer: tests are unhappy (lots of timeouts/errors/out-of-machines with linode cascading into timeouts in travis)
[16:19] <niemeyer> If there are any fires, please drop me a note about them in the forum so I start there
[16:19] <Chipaca> niemeyer: ratcheted travis down to 2 runs max
[16:19] <Chipaca> niemeyer: not sure whether it's helped
[16:19] <niemeyer> Ack
[16:19] <niemeyer> It should help
[16:19] <Chipaca> niemeyer: mborzecki has a couple of PRs to play with splitting spread runs into N, per arch, which might make things easier
[16:19] <niemeyer> I'm planning a revamp of our runs so we allocate systems dynamically
[16:20] <niemeyer> That might help making it cheaper and faster at the same time
[16:20] <niemeyer> Saviq needs this too
[16:20] <Chipaca> niemeyer: but when possible there's a bunch of tweaks we should probably do to the images to make them prepare quicker (and some tests hit the network less)
[16:21] <Chipaca> niemeyer: but, worst case, we'll sort it out in the new year :-)
[16:21] <niemeyer> Agreed
[16:21] <niemeyer> And agreed :)
[16:24]  * Chipaca ~> bbl
[16:38] <kalikiana> elopio: hey. could we chat about the yaml for integration tests in snapcraft#1639?
[16:38] <mup> PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>
[16:39] <elopio> kalikiana: sure.
[16:40] <elopio> kalikiana: this is the closest I got to what I would like to see, but still not 100% happy: https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/fixture_setup.py#L939
[16:42] <kalikiana> elopio: mind joining me in the weekly?
[16:45] <sborovkov_> how can I enable core dump generation on ubuntu core?
[16:47] <elopio> kalikiana: sure, give me a second.
[16:48] <kalikiana> Aye
[16:58] <hurricanehrndz> what kernel modules are required for the build tests to pass?
[16:59] <hurricanehrndz> I keep seeing issues with the seccomp test when testing setuid
[17:03] <hurricanehrndz> specifically can: request_module (can-proto-0)
[17:17] <pedronis> Chipaca: I got again a timeout (49+ mins)
[17:18] <pedronis> Chipaca: https://travis-ci.org/snapcore/snapd/builds/315911230?utm_source=github_status&utm_medium=notification
[17:20] <kalikiana> elopio: sent you my notes. it's probably easiest if I update my branch first, and you can look into removing update_part later since I'll be adding the parts arguments anyway
[17:21] <kalikiana> now time to head out, for drinks and dinner
[17:24] <mup> PR snapcraft#1805 closed: lifecycle: use the -no-fragments mksquashfs option <Created by tyhicks> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1805>
[17:27] <brunosfer> Hi guys, is it possible to specify the architecture of a snap when downloading it? e.g. sudo snap download <snap name> --armhf
[17:32] <pedronis> brunosfer: not super official but UBUNTU_STORE_ARCH=armhf snap download   ... should work
[17:45] <gsilvapt> elopio, you around?
[18:02] <Chipaca> hurricanehrndz: which test suite?
[18:06] <hurricanehrndz> Chipaca: One sec, I think I might have figured it out. I'm going to run one more test, and I'llreport back
[18:06] <Chipaca> hurricanehrndz: ok (but also report which test suite you're talking about -- there're several, and who knows to help varies)
[18:07] <hurricanehrndz> Chipaca: sounds good
[18:13] <pedronis> Chipaca: it's about to fail again with a timeout :/
[18:15] <brunosfer> pedronis: Thank you. It works, however when I do in a amd64 system the UBUNTU_STORE_ARCH=amd64 sudo snap download <snap name> it downloads a different version of the snap then it does in an amrhf with the exact same command.
[18:16] <brunosfer> pedronis: Do you have any idea why this happens?
[18:19] <pedronis> brunosfer: not sure,  best to try to pass a channel --stable or something explicitly
[18:20] <brunosfer> pedronis: I will give it a shot. Thankx
[18:21] <hurricanehrndz> Chipaca: yup, figured out the seccomp test, it had already been fixed in master
[18:22] <Chipaca> brunosfer: er, you mean UBUNTU_STORE_ARCH=armhf right?
[18:23] <brunosfer> pedronis: Doesn't work with the --stable flag. I could try to specify the version, however my intention is to get the latest version regardless of the architecture downloading the snap
[18:23] <brunosfer> Chipaca: I mean UBUNTU_STORE_ARCH=amd64
[18:23] <Chipaca> brunosfer: but that's telling it to download the amd64 snap, don't you want the armhf one?
[18:24] <brunosfer> Chipaca: but could also be armhf, I just want consistency on the version I download regardless of the architecture downloading the snap
[18:24] <Chipaca> brunosfer: that sounds like a strange requirement to me, could you explain further?
[18:24] <pedronis> notice that different arch different revision
[18:24] <Chipaca> pedronis: let _me_ press the 'restart' button this time; it likes me :-p
[18:24] <brunosfer> Chipaca: I want to make the download of the snap to send it oflfline to another device that has a different architecture.
[18:25] <pedronis> for the version you need to look at snap info *.snap
[18:25] <brunosfer> pedronis: You mean that the snap I'm trying to download might have different versions for different architectures...
[18:25] <Chipaca> brunosfer: I understand that, but then you compare what you download with “UBUNTU_STORE_ARCH=amd64 snap download thesnap” with what you install on an armhf system with “snap install thesnap”; those are different things
[18:25] <Chipaca> brunosfer: revisions, not versions
[18:27] <pedronis> Chipaca: I already did :/
[18:27] <brunosfer> Chipaca: in this case, I'm downloading the nmap (because it's small) for testing purposes, but the version is in the name of the snap when I download the file right?
[18:27] <pedronis> no
[18:27] <pedronis> that's the revision
[18:28] <pedronis> the files produced by snap download have the revision in them
[18:28] <pedronis> I mean the file names of the files
[18:28] <brunosfer> pedronis: Ok, thankx, my mistake then, I will install them and check the version. They should be the same then :)
[18:28] <Chipaca> brunosfer: in "snap info nmap" (on amd64), the (29) is the revision; 7.12SVN-0.6 is the version
[18:28] <Chipaca> awww they're still using svn
[18:28] <Chipaca> :-)
[18:28] <pedronis> brunosfer: snap info  <snapfile>  can give you the version without installing first
[18:28] <brunosfer> Chipaca: Thanks for the help ;)
[18:28] <brunosfer> pedronis: Thanks for the help ;)
[18:28] <pedronis> in case
[18:29] <brunosfer> pedronis: Yes, but I was being mislead by the name of the snap. Thanks for the help ;)
[18:53] <sergiusens> elopio kyrofa snapcraft#1801 has no reviews yet, being pretty simple it should go fast
[18:53] <mup> PR snapcraft#1801: lifecycle: detect docker to auto setup core <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1801>
[18:56] <Saviq> is it possible to limit the architectures the snap is built for on build.snapcraft.io ?
[19:17] <sergiusens> Saviq not today, not yet
[19:21] <Saviq> ok, let's see what happens then
[19:22] <mup> PR snapcraft#1806 closed: ci: transfer generated snapcraft snap to transfer.sh <Created by daniellim2000> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1806>
[19:24] <Wulong> How do I install a snapshot in a custom directory? its size exceed /
[19:25] <mup> PR snapcraft#1801 closed: lifecycle: detect docker to auto setup core <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1801>
[19:42] <mup> PR snapd#4388 closed: overlord/snapstate: fix auto-refresh summary for 2 snaps <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4388>
[19:47] <Chipaca> Wulong: pardon?
[19:51] <tyhicks> jdstrand: what's your advice on the test errors in https://github.com/snapcore/snapd/pull/4396 ?
[19:51] <mup> PR #4396: snap: use the -no-fragments mksquashfs option <Created by tyhicks> <https://github.com/snapcore/snapd/pull/4396>
[19:51] <tyhicks> jdstrand: they're due to http requests with the store timing out
[19:51] <tyhicks> (unrelated to my changes0
[19:53] <Wulong> Chipaca: how can I install a snap to a custom dir. Eg. snap install vlc --store-to-some-custom-path=/some/custom/path
[19:54] <tyhicks> it doesn't look like I have the ability to restart the tests
[19:54] <Chipaca> Wulong: currently you can't, but if you have a single location that could hold all the snaps you need, you can mount that
[19:55] <Chipaca> Wulong: what sizes are we talking?
[19:55] <Wulong> 30 GB
[19:55] <Chipaca> Wulong: the .snap is 30GB?
[19:56] <Wulong> Not sure if its the snap or its data.
[19:56] <Wulong> Probably the latter.
[19:56] <Chipaca> Wulong: the snap is heavily compressed, so it might be significantly smaller
[19:56] <Chipaca> Wulong: and, it's mounted compressed; you don't need space for more than just the snap
[19:58] <Chipaca> Wulong: but if you do need more space, /var/lib/snapd/snaps/ is where you need to put the space (but you need to mount it before installing any snaps...)
[19:59] <Wulong> Ok, I'll give it another shot. Must have been application error or config issue.
[19:59] <Wulong> Yea I know, but I don't have a free partition :|
[19:59] <Chipaca> Wulong: then where were you going to put the snap?
[19:59] <Wulong> Thanks for the help Chipaca
[19:59] <Wulong> In /home
[20:00] <Chipaca> Wulong: mount --bind is your friend
[20:00] <Wulong> Ah, of course. Forgot abotu that one.
[20:01] <Wulong> Linux has become too easy. Makes me lazy
[20:01] <Chipaca> Wulong: :-)
[20:29] <jdstrand> tyhicks: let me look
[20:31] <Chipaca> tyhicks: jdstrand: we're having issues with spread and linode and travis
[20:32] <jdstrand> Chipaca (cc tyhicks): whoops too late. I clicked 'restart build'
[20:32] <jdstrand> tyhicks: if this build fails, I would comment in the PR that the test failures are unrelated
[20:32] <Chipaca> jdstrand: 👌
[20:33] <tyhicks> ack, thanks
[20:37] <pedronis> Chipaca: I managed to merge some stuff, but maybe master is red for all I know
[20:38] <Chipaca> pedronis: when is it you're off?
[20:48] <sergiusens> elopio look at this error, wrong snapcraft is being called https://travis-ci.org/snapcore/snapcraft/jobs/316053900
[20:51] <sergiusens> ohh nvm
[21:02] <lundmar> hmm, isn't --devmode and --classic supposed to disable confinement? I have a tool that still gets permission denied when writing on NFS shares despite being installed with --devmode and --classic.
[21:03] <lundmar> I'm running 2.29.4.2
[21:05] <kyrofa> lundmar, yes, although you still may be hitting traditional permissions
[21:11] <mup> PR snapd#4399 opened: rewrite snappy-app-dev <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4399>
[21:57] <pedronis> Chipaca: Friday is eoy for me
[22:05] <Chipaca> pedronis: ah ok, same here