[00:08] <gsilvapt> kyrofa, about the command, the only way I can make them match is if I explicitly set the string to be "snapcraft, version xxx" in both commands. Is that okay?
[00:09] <kyrofa> gsilvapt, I'd leave the Click one `prog`
[00:09] <gsilvapt> kyrofa, sounds okay to me but the problem is that when you run the tests it does not print snapcraft. Instead it prints run, version xxx
[00:10] <gsilvapt> Maybe that is related with the tests, I do not know
[00:10] <kyrofa> gsilvapt, oh that's unfortunate indeed
[00:10] <kyrofa> gsilvapt, yeah, hardcode it then
[00:10] <gsilvapt> Ok, I will do that, verify again the tests and submit the changes
[00:10] <gsilvapt> kyrofa, thank you!
[00:50] <mup> Issue snapcraft#1666 closed: Refactor to support elf patching <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1666>
[00:50] <mup> PR snapcraft#1744 closed: elf: conversion from libraries <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1744>
[01:50] <mup> PR snapcraft#1725 closed: tests: share the cache in ros tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1725>
[05:56] <mborzecki> morning guys
[06:31] <mup> PR snapd#4264 closed: tests: force delete when tests are restore to avoid suite failure <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4264>
[06:39] <mup> PR snapd#4240 closed: spread.yaml: increase workers for opensuse to 3 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4240>
[06:53] <mup> PR snapd#4266 opened: snapstate: add new refresh-hints helper and use it <Created by mvo5> <https://github.com/snapcore/snapd/pull/4266>
[07:01] <zyga-ubuntu> good morning
[07:02] <mvo> hey zyga-ubuntu , good morning
[07:11] <zyga-ubuntu> :-)
[07:11] <zyga-ubuntu> I'm still in non-{wayland,x} text mode
[07:12] <zyga-ubuntu> using another computer for code reviews
[07:12] <zyga-ubuntu> this is particularly refreshin
[07:12] <zyga-ubuntu> lots of free memory and full-screen, single focus applications
[07:13] <mvo> zyga-ubuntu: haha, nice
[07:23] <zyga-ubuntu> I spent some time yesterday trying to untangle our prepare/restore code
[07:23] <zyga-ubuntu> if not permanantly then at least enough to get good measurements of what is changing
[07:23] <zyga-ubuntu> and I must say that code is complex and confusing
[07:24] <zyga-ubuntu> not just in the actions taken but in their placement and justification
[07:24] <zyga-ubuntu> (or lack or thereof)
[07:24] <mvo> zyga-ubuntu: yeah, its all over the place
[07:25] <zyga-ubuntu> I'll keep at it as it needs to be in proper shape to detect tests that change too much
[07:40] <mup> PR snapd#4267 opened: snapstate: move catalogRefresh into its own helper  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4267>
[07:46]  * kalikiana o/
[07:46] <zyga-ubuntu> mvo: review on 4266
[07:48] <mvo> zyga-ubuntu: ta
[07:50] <zyga-ubuntu> I marked it as changes requested but just midlly so, we can merge this quickly
[07:59] <mvo> zyga-ubuntu: thanks, the can-auto-refresh question is interessting as it raises a bigger questions
[08:01] <mvo> pedronis: do you think the new refresh-hints code should also consult "CanAutoRefresh", or should we do the refresh-hints even if the device is still bootstraping? I guess we want to honor CanAutoRefresh but I want to double check. I also think you are right about RefreshOptions:RefreshNop, I think we want this, I will followup on this
[08:03] <mvo> zyga-ubuntu: thanks again for the quick review :)
[08:03] <zyga-ubuntu> :-)
[08:26] <pedronis> mvo: yes, I think we want to consult CanAutoRefresh  (otherwise will just consider partial information or don't have a device session yet)
[08:28] <mvo> pedronis: +1 - thank you
[08:56]  * zyga-ubuntu tries something mergable instead
[09:00] <zyga-ubuntu> mvo: trivial merge on 4268
[09:00] <mup> PR snapd#4268 opened: spread.yaml: move prepare-each closer to restore-each <Created by zyga> <https://github.com/snapcore/snapd/pull/4268>
[09:11] <mup> PR snapd#4269 opened: timeutil: new refresh timer parser <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4269>
[09:13] <mup> PR snapd#4270 opened: timeutil: remove support to parse weekday schedules <Created by mvo5> <https://github.com/snapcore/snapd/pull/4270>
[09:16] <mvo> mborzecki: heh, looks like we need to solve conflicts here ;) either way is fine with me, I can wait for your merge or you can review mine and merge into yours (or wait until master is in)
[09:16] <mvo> mborzecki: should be very simple in any case
[09:17] <mborzecki> mvo: yup, i'm wiring a comment on gh
[09:18] <mborzecki> i'm actually using some of the pieces that you remove :)
[09:18] <mvo> mborzecki: yeah, happy to revert those bits
[09:19] <mvo> mborzecki: the key of the PR (I can make it smaller) is that the weekday parsing in v1 is not supported in snapstate so its dead code and caused one confusion in the validation already
[09:21] <mborzecki> hmm ok, i mean it's not a big problem, if it gets merged before 4269, i'll just bring back the missing pieces
[09:22] <mvo> mborzecki: no worries, I can do that now to make your life easier, its the weekday part of the struct and the weekdayMap that you need, right?
[09:23] <mborzecki> but i'm guessing 4269 will be a longer review, so I wouldn't want to block you
[09:23] <mvo> mborzecki: yeah, let me rework my PR (was not aware of yours) so that the impact for you is minimal
[09:24] <mborzecki> mvo: only if you have time for this, otherwise i can fix this myself in my PR
[09:25] <mborzecki> mvo: would appreciate you taking a look at 4269 BTW :)
[09:26] <mvo> mborzecki: re-added the weekday/weekday map now. I check the other one out once I finished my current PR. I glanced over it and it looked good from a very brief look
[09:34] <mborzecki> mvo: thanks
[09:49] <zyga-ubuntu> hmm
[09:50] <zyga-ubuntu> so, what does ${GOPATH%%:*} expand to?
[09:50] <zyga-ubuntu> because as far as I can see, to nothing at all
[09:51] <zyga-ubuntu> %% will strip the longest suffix of "*" which is everything
[09:51] <jamesh> it'll strip the suffix of ":*" -- not "*"
[09:52] <jamesh> so effectively remove everything including and after the first colon
[09:53] <zyga-ubuntu> are you sure?
[09:53] <zyga-ubuntu> ah
[09:53] <zyga-ubuntu> right, I made a typo in my tests
[09:53] <zyga-ubuntu> thanks!
[09:55] <zyga-ubuntu> :-)
[09:56] <zyga-ubuntu> mvo: can you please force-merge 4268
[09:57] <zyga-ubuntu> I could try again and waste an hour but I think the situation is riddiculus enough not to do that
[09:57] <zyga-ubuntu> and the error is clearly some store flue on refresh deltas
[09:59] <mup> PR snapd#4268 closed: spread.yaml: move prepare-each closer to restore-each <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4268>
[10:00] <zyga-ubuntu> thanks!
[10:01] <zyga-ubuntu> mvo: another quick PR to look at 4271
[10:01] <mvo> yw
[10:02] <mup> PR snapd#4271 opened: spread.yaml: fix shellcheck issues and trivial refactor <Created by zyga> <https://github.com/snapcore/snapd/pull/4271>
[10:17] <zyga-ubuntu> mborzecki: errors in your schedule PR
[10:18] <zyga-ubuntu> mborzecki: real unit tests failures in overlord/snapstate
[10:18] <mborzecki> zyga-ubuntu: thx, on it
[10:18] <zyga-ubuntu> mvo: btw, I'm on FF57 now (actually on nightly so 59) and I can use umatrix
[10:18] <zyga-ubuntu> mvo: try again, maybe your extension was fixed now
[10:19] <zyga-ubuntu> mvo: ff 59 with umatrix is the fastest browser on any system I used
[10:19] <zyga-ubuntu> (umatrix cutting the number of crap javascript from ads and tracking)
[10:22] <mvo> zyga-ubuntu: I have a bunch that I missed, but things are mostly good again. umatrix, cookie auto-delete, noscript are my essential ones, I also have a custom one that I need to port in time (based on the passhash extension)
[10:22] <mborzecki> mvo: things are fast again!
[10:23] <mup> PR snapd#4272 opened: snapstate: ensure RefreshSchedule() gives accurate results <Created by mvo5> <https://github.com/snapcore/snapd/pull/4272>
[10:25] <pedronis> mvo: ^  the description  there has "git push ..." in the middle, could you fix it
[10:25] <mvo> pedronis: autsch, sorry for that
[10:25] <pedronis> not sure if it lost bits or just need the bit removed
[10:27] <mvo> pedronis: apparently a wrongly focused window, the original commit message is correct
[10:27] <mvo> pedronis: most of the PRs this morning are based on what we talked about yesterday, I they capture your suggestions, they should make 4161 simpler
[10:33] <zyga-ubuntu> mvo: review on 4272
[10:33] <zyga-ubuntu> mborzecki: do you think 4269 can be split?
[10:34] <zyga-ubuntu> mborzecki: I'm often doing small reviews while waiting for local spread run to finish but 1K PR is not in that class
[10:34] <mborzecki> for sure i can put the first 2 patches in a separate pr
[10:34] <zyga-ubuntu> mborzecki: thank you, I'll gadly review that
[10:39] <mup> PR snapd#4273 opened: timeutil: introduce helpers for weekdays and TimeOfDay <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4273>
[10:39] <mborzecki> zyga-ubuntu: ^^
[10:41] <zyga-ubuntu> thanks
[10:43] <Chipaca> mborzecki: doesn't that TimeOfDay Add method mess up on DST change?
[10:43] <Chipaca> 11pm + 6h isn't always 5am
[10:43] <zyga-ubuntu> Chipaca: I commented on a similar aspect
[10:44] <zyga-ubuntu> mborzecki: commented
[10:44] <mborzecki> hmm not sure you can do anythign about this TimeOfDay as it's not aware of actual date
[10:45] <zyga-ubuntu> mborzecki: yeah, it depends on how it is used
[10:47] <Chipaca> zyga-ubuntu: i think we can ignore leap seconds though -- we're explicitly not supporting them as a valid time
[10:47] <zyga-ubuntu> Chipaca: +1
[10:47] <mup> PR snapd#4271 closed: spread.yaml: fix shellcheck issues and trivial refactor <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4271>
[10:47] <mborzecki> imo, it's the same way as time.Time.Add() is not aware of DST only until you do presentation
[10:48] <Chipaca> mborzecki: it all depends on how this is then used, though
[10:50] <zyga-ubuntu> Chipaca: trivial 4274
[10:50] <mup> PR snapd#4274 opened: spread.yaml: bump delta ref to 2.29 <Created by zyga> <https://github.com/snapcore/snapd/pull/4274>
[10:51] <Chipaca> that's a review size i can _do_
[10:51]  * Chipaca in pain and on pain meds -- not a good combo
[10:54] <pedronis> Chipaca: :(
[10:54] <Chipaca> pedronis: ¯\_(ツ)_/¯
[10:55] <mup> PR snapd#4275 opened: spread.yaml,tests: move most of project-wide prepare/restore to separate file <Created by zyga> <https://github.com/snapcore/snapd/pull/4275>
[10:55] <zyga-ubuntu> Chipaca: take care, I'm sorry for your pain :|
[10:55] <zyga-ubuntu> another small refactor for spread.yaml ^
[10:55] <zyga-ubuntu> 10% executed locally so I assume it's okay, rest will show up in real testing
[10:56] <Chipaca> zyga-ubuntu: this one is to work with your changes to spread?
[10:56] <zyga-ubuntu> Chipaca: this is all preparation work, I made so many changes trying to untangle and understand this it was impossible to review
[10:56] <zyga-ubuntu> Chipaca: I can propose the spread PR for reference
[10:56] <zyga-ubuntu> Chipaca: the problem is we don't really prepare/restore cleanly
[10:57] <zyga-ubuntu> Chipaca: and I will hopefully changed that by EOD, without introducing any extre time costs
[10:57] <zyga-ubuntu> Chipaca: have a look at spread#47 please
[10:57] <mup> PR spread#47: Add support for project-wide measure-each stanza <Created by zyga> <https://github.com/snapcore/spread/pull/47>
[10:57] <kalikiana> zyga-ubuntu: I'm getting this again :-( ` open /var/lib/snapd/hostfs/home/cris/snap/lxd/common/snapcraft9xy6a3v1/core_3440.assert: no such file or directory [...] subprocess.CalledProcessError: Command '['lxc', 'file', 'push', '/home/cris/snap/lxd/common/snapcraft9clif0ke/snapcraft_x1.snap', 'helga:snapcraft-multipass/run/snapcraft_x1.snap']' returned non-zero exit status 1.`
[10:58] <zyga-ubuntu> kalikiana: which of the files is missing? any denials?
[10:59] <zyga-ubuntu> Chipaca: in my approach the measure-each code ensures that files on / (and just that filesystem) and outside of /tmp don't change, mount table doesn't change, packages don't change and sysctl doesn't change
[10:59] <zyga-ubuntu> Chipaca: but it changes all the time as prepare/restore is a bit wonky and I need to clean it up before addressing some real problems
[11:01] <mup> PR snapd#4253 closed: task tunner: extended task runner test <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/4253>
[11:01] <kalikiana> zyga-ubuntu: not that I can see...
[11:02] <kalikiana> I'm trying again with `snappy-debug scanlog` open
[11:02] <kalikiana> zyga-ubuntu: this is btw snapcraft as a snap, with lxd from apt
[11:02] <zyga-ubuntu> mvo: approved 4272
[11:02] <mvo> zyga-ubuntu: ta
[11:02] <zyga-ubuntu> kalikiana: too many errors recently
[11:02] <zyga-ubuntu> kalikiana: I have LXD issues to address b
[11:03] <zyga-ubuntu> kalikiana: but our integration test suite is so unreliable I took a dive into it
[11:03] <mvo> zyga-ubuntu: thanks again for this review, that made things a lot better (checkRefreshSchedle was pretty terrible)
[11:03] <kalikiana> zyga-ubuntu: is there anything that changed in lxd recently? I'm quite sure snapcraft changed nothing
[11:03] <zyga-ubuntu> kalikiana: I don't know, sorry :/
[11:04] <mvo> kalikiana: there was a new stable lxd recently I think, but that is really all I know
[11:04] <mvo> stable channel lxd snap to be precise
[11:04] <mup> PR snapcraft#1750 closed: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1750>
[11:05] <mvo> kalikiana: yesterday to be precise. and also a new cnadidate a bit later
[11:05] <kalikiana> mvo: I guess I'll try if the snap suffers from the same issue - what I find super puzzling is that hostfs is in the path at all, and considering it's empty in the host that would easily explain why lxd can't access it
[11:07] <mup> PR snapcraft#1643 closed: tests: run daily autopkgtest in travis <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1643>
[11:08] <zyga-ubuntu> mborzecki: approved 4273
[11:08] <mborzecki> ta
[11:09] <mup> PR snapd#4267 closed: snapstate: move catalogRefresh into its own helper  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4267>
[11:09] <zyga-ubuntu> mvo: trivial comment on 4266 (from pedronis, not me), +2 otherwise and ready to land
[11:10] <zyga-ubuntu> mvo: thank you for updating 4262 :)
[11:11] <zyga-ubuntu> Chipaca: do you feel like reviewing 4254 from mvo (it's about SNAP_DID_REEXEC)
[11:11] <zyga-ubuntu> ?
[11:11] <mup> PR snapd#4256 closed: snap-confine: add workaround for snap-confine on 4.13/upstream <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4256>
[11:11] <mup> PR snapd#4262 closed: store: do not log the http body for catalog updates <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4262>
[11:11]  * Chipaca looks
[11:17] <zyga-ubuntu> mvo: we still ship a configure hook in core, is the plan to remove that entirely and switch to internally-handled configuration?
[11:27] <pedronis> zyga-ubuntu: the plan is to remove it, we still have more work to do to fix 2.30 to make that possible
[11:27] <pedronis> though
[11:27] <zyga-ubuntu> pedronis: I see
[11:28] <pedronis> https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774
[11:28] <zyga-ubuntu> pedronis: I just noticed we do something odd in prepare code
[11:28] <zyga-ubuntu> we enable refresh on external spread backends
[11:28] <zyga-ubuntu> but only if the configure hook exists
[11:31] <kalikiana> zyga-ubuntu: concerning denials: none, I'm only seeing unrelated ones eg. Telegram now
[11:31] <kalikiana> which makes sense if all it does is read an empty folder
[11:34] <zyga-ubuntu> kalikiana: is this locally or in some CI system?
[11:34] <zyga-ubuntu> kalikiana: do you have any changes on the system that is affected?
[11:35] <kalikiana> zyga-ubuntu: all local, xenial with backports
[11:41] <zyga-ubuntu> mborzecki: is 4270 safe to merge now?
[11:42] <mborzecki> zyga-ubuntu: yes
[11:42] <zyga-ubuntu> mvo: trivial comment on 4252
[11:42] <zyga-ubuntu> mvo: and more comments on 4272
[11:42] <mup> PR snapd#4270 closed: timeutil: remove support to parse weekday schedules <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4270>
[11:43] <zyga-ubuntu> 4263 needs a 2nd review
[11:43] <mup> PR snapd#4254 closed: cmd, errtracker: get rid of SNAP_DID_REEXEC environment <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4254>
[11:44] <zyga-ubuntu> mborzecki: can you finish your review o 4109, it's small and has been lingering for too long
[11:44] <mup> PR snapd#4171 closed: tests: adding test to test physical memory observe interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4171>
[11:46] <zyga-ubuntu> mborzecki: conflicts in 4273
[11:49] <pstolowski> mborzecki, .. and in 4269
[11:51] <niemeyer> cjwatson: Aww.. no more gimme?
[11:52] <niemeyer> Hellos!
[11:52] <cjwatson> niemeyer: thank you for the music
[11:53] <jamesh> zyga-ubuntu: hi.  I was wondering if you have any ideas about how to write a spread test for my user-mounts PR.  I haven't included any interface that add user mounts at this stage, so I'm not sure where to start
[11:56] <mborzecki> pushed an update to 4273, 4269 will be fixed later as currently it will conflict with 4273
[11:59] <zyga-ubuntu> jamesh: I think it should be a part of the desktop interface (right?)
[12:00] <zyga-ubuntu> jamesh: alternatively just use a test snap, install it, hack the profile and run update-ns
[12:00] <zyga-ubuntu> jamesh: (and, more importantly, hack the profile, discard the ns and run snap-confine again so that it sets up things)
[12:00] <jamesh> zyga-ubuntu: the desktop innnterface will use it for portals eventually, but that isn't part of the PR
[12:00] <zyga-ubuntu> jamesh: look at the advanced content interface test for inspiration
[12:01] <jamesh> zyga-ubuntu: also, what's the most convenient way to run a single spread test locally?
[12:01] <zyga-ubuntu> jamesh: look at tests/main/interfaces-content-mkdir-writable
[12:01] <zyga-ubuntu> jamesh: the qemu backend, you can iterate very quickly (ish)
[12:01] <zyga-ubuntu> jamesh: I'm running it all the time
[12:01] <zyga-ubuntu> jamesh: I pushed images to spread.zygoon.pl/images
[12:02] <zyga-ubuntu> jamesh: so pick one and look at spread docs on how to use
[12:02] <zyga-ubuntu> jamesh: (just put to ~/spread/qemu)
[12:02] <jamesh> thanks
[12:02] <zyga-ubuntu> jamesh: then SPREAD_DEBUG_EACH=0 spread qemu:ubuntu-16.04-64:tests/main/
[12:02] <zyga-ubuntu> jamesh: then SPREAD_DEBUG_EACH=0 spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/
[12:02] <zyga-ubuntu> (2nd line is better)
[12:03] <zyga-ubuntu> jamesh: the desire for the spread test is to see that this really really works with confinment and what not
[12:03] <zyga-ubuntu> jamesh: and weird kernels and other unexpected stuff
[12:04] <zyga-ubuntu> mvo: small typo in 4266
[12:04] <zyga-ubuntu> mvo: small tweak needed in 4252
[12:05]  * zyga-ubuntu is trying to get the PR page list down to one 
[12:06] <pedronis> #4158 needs a 2nd review
[12:06] <mup> PR #4158: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/4158>
[12:07] <zyga-ubuntu> looking
[12:07] <jamesh> zyga-ubuntu: okay.  fwiw, the unit tests in the PR are all passing now: it looks like the run yesterday hit some problem trying to talk to the VMs
[12:07] <zyga-ubuntu> jamesh: yeah, our perpetual problem of not having a batch system
[12:16] <cachio> mvo, hey
[12:16] <cachio> mvo, looking at the issue with "Job for snapd.service canceled"
[12:17] <cachio> mvo, any idea how to deal with it?
[12:17] <cachio> mvo, retrying in case of error could be a solution?
[12:27] <zyga-ubuntu> pstolowski: review on 4158
[12:27] <zyga-ubuntu> hmm, so MATCH is in the top-level spread context, this is a problem if we want to use it in scripts :/
[12:28] <mup> PR snapd#4274 closed: spread.yaml: bump delta ref to 2.29 <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4274>
[12:29] <zyga-ubuntu> hello niemeyer :)
[12:29] <zyga-ubuntu> thank!
[12:29] <zyga-ubuntu> thanks* :)
[12:29] <niemeyer> zyga-ubuntu: Hey!
[12:29] <niemeyer> zyga-ubuntu: Man, I found your brother last night
[12:30] <niemeyer> zyga-ubuntu: https://www.youtube.com/watch?v=cHjf-YmIBCs
[12:30] <zyga-ubuntu> niemeyer: oh?
[12:31] <zyga-ubuntu> hahaha
[12:31] <zyga-ubuntu> yeah, actually he even sounds similar in some way
[12:31] <zyga-ubuntu> I hit the case where spread tarball changes while we are making it, hmmm,
[12:31] <pedronis> that is a fun one :(
[12:32] <zyga-ubuntu> maybe once I'm done with refactoring/untangling it will become evident
[12:32] <zyga-ubuntu> I bet something is not done right somewhere
[12:32] <zyga-ubuntu> service lingers or something like that
[12:33] <niemeyer> zyga-ubuntu: Yeah, the voice tone, the looks, and even the shirt!
[12:33] <zyga-ubuntu> niemeyer: surreal a bit :)
[12:33] <niemeyer> :P
[12:33] <zyga-ubuntu> niemeyer: my accent is better though (haha, maybe)
[12:35] <niemeyer> zyga-ubuntu: Well, not better, but less german :-)
[12:36] <niemeyer> (I don't see accents as bad in general.. just means we speak another language too)
[12:39] <Son_Goku> accents don't necessarily imply another language
[12:39] <zyga-ubuntu> oh god yes
[12:39] <zyga-ubuntu> I watched a review of a game recently
[12:39] <zyga-ubuntu> and geez
[12:39] <zyga-ubuntu> this guy was unberable
[12:39] <Son_Goku> IMO, they tell a story of the person's origin and history
[12:40] <zyga-ubuntu> somewhere from US presumably but _MAN_
[12:40] <Son_Goku> I've intentionally smoothed out the accent and speech style I grew up with, because it can confuse people
[12:41] <Son_Goku> and even then, I don't have all of it out of my speech
[12:41] <zyga-ubuntu> ok, I'm done watching my weird mirror :)
[12:43] <kalikiana> Son_Goku: you're like Jack Barrowman :-D
[12:43] <kalikiana> although arguably his original accent is worse
[12:43] <Son_Goku> well, I'm not *quite* so flamboyant
[12:43] <Son_Goku> but yes
[12:43] <kalikiana> haha, yeah
[12:44] <Son_Goku> well, for the first half of my childhood was spent in Indiana (US Midwest) and the second half was in Mississippi (US South), so I have bits of both in my speech
[12:46] <zyga-ubuntu> afk, see you at the call
[12:48] <mvo> zyga-ubuntu: the plan is to not ship the configure hook in core, yes
[12:50] <mvo> cachio: hey, thanks for chasing the "job canceled" issue, I have no good answer, a retry is certainly not a bad idea, maybe this gives us even a better idea what exactly is causing this
[12:51] <mvo> zyga-ubuntu: thanks also for the reviews, I chase the open points now :)
[12:52] <cachio> mvo, I'll try it
[12:52] <zyga-ubuntu> mvo: thank you! :)
[12:58]  * kalikiana coffee break
[13:00] <Chipaca> mvo: should we ask systemd peeps about that?
[13:00] <zyga-ubuntu> I'll be late 2 min
[13:04] <zyga-ubuntu> hmm
[13:04] <zyga-ubuntu> some issues joining
[13:05] <zyga-ubuntu> hmm :/
[13:17] <mvo> Chipaca: its only on 14.04 and on our crufty backport
[13:38] <Chipaca> mwhudson: is the plan to have go 1.10 in B?
[13:44] <zyga-ubuntu> Chipaca: are you rejoining?
[13:48] <zyga-ubuntu> ok, I'll break for lunch and I'll push forward in a moment :)
[14:02] <Chipaca> zyga-ubuntu: question for you i think: why do osutil.Find[UG]id return a uint64?
[14:04] <zyga-ubuntu> Chipaca: I believe that is what the golang 1.9 code we borrowed did do
[14:04] <zyga-ubuntu> Chipaca: and we just ran along
[14:05] <Chipaca> hmm
[14:05]  * Chipaca looks
[14:05] <zyga-ubuntu> offtopic, 3C and rain, I really don't envy commuters
[14:05] <Chipaca> zyga-ubuntu: golang uses strings for uids and gids
[14:05] <Chipaca> zyga-ubuntu: in the os/user package
[14:05] <Chipaca> elsewhere it uses uint32's
[14:05] <Chipaca> (hilariously)
[14:06] <zyga-ubuntu> Chipaca: then I don't remember, I think there were two layers of this?
[14:06] <zyga-ubuntu> Chipaca: or maybe as simple and naive as what parseint returns
[14:07] <zyga-ubuntu> *uint
[14:08] <Chipaca> zyga-ubuntu: also: those functions return a 0 on error, which can be bad
[14:08] <Chipaca> but i don't know if i want to fix the in this pr
[14:08] <Chipaca> hmm
[14:17] <cachio> ogra_, hey
[14:18] <cachio> ogra_, https://paste.ubuntu.com/26020272/
[14:18] <cachio> the timexone in ubuntu core is n/a by defaulty
[14:18] <cachio> ogra_, is it a known issue?
[14:20] <Chipaca> zyga-ubuntu, mvo: in snap-seccomp/main.go's findGid we check a regexp, and then call osutil.FindGid which checks a regexp
[14:20] <Chipaca> zyga-ubuntu, mvo: those regexps differ
[14:20] <Chipaca> zyga-ubuntu, mvo: quoth the raven, "WAT"
[14:20] <Chipaca> zyga-ubuntu, mvo: ignore me, i got that wrong
[14:22] <ogra_> cachio, not that i'm aware ... file it ...
[14:22] <cachio> ogra_, ok tx
[14:22] <ogra_> cachio, is that x86 or arm ?
[14:23] <ogra_> (on arm the fixrtc script checks for n/a and sets it properly, on x86 we do not use the fixrtc script afaik)
[14:23] <zyga-ubuntu> mvo: the one with weirder features is probably correct
[14:23] <zyga-ubuntu> er
[14:23] <zyga-ubuntu> Chipaca: ^
[14:23] <zyga-ubuntu> Chipaca: can you paste them here please?
[14:24] <cachio> ogra_, all of them
[14:24] <cachio> ogra_, in the pi3 also
[14:24] <Chipaca> zyga-ubuntu: sorry, i got confused, but let me show you how
[14:25] <ogra_> cachio, ah, well ... we should set it to UTC as default at build time i guess
[14:25] <Chipaca> zyga-ubuntu: in snap-seccomp main: group must match "^[a-z][-a-z0-9_]*$"
[14:26] <zyga-ubuntu> that is probably incorrect (just too restrictive)
[14:28] <Chipaca> zyga-ubuntu: in snap-update-ns entry: x-snapd.gid must match "(^[0-9]+$)|(^[a-z_][a-z0-9_-]*[$]?$)"
[14:28] <zyga-ubuntu> this one is correct but also matches numbers (as just direct group i)
[14:29] <zyga-ubuntu> so if you want to take one, take the latter one and remove the number part
[14:29] <zyga-ubuntu> Chipaca: the 2nd one is correct, I looked at the spec and, weirdly enough, that's what valid names are
[14:31] <Chipaca> zyga-ubuntu: group names can end in $ but otherwise have no $ in them?
[14:31] <Chipaca> what does that $ mean? (i presume it's special somehow)
[14:31] <Chipaca> (i'm not changing that regexp in this round)
[14:31] <Chipaca> (next one? sure)
[14:32] <cachio> ogra_, it is set to UTC but the description is n/a
[14:32] <zyga-ubuntu> yes
[14:32] <cachio> Time zone: n/a (UTC, +0000)
[14:33] <zyga-ubuntu> Chipaca: it's special, it means
[14:33] <zyga-ubuntu> ...
[14:33] <zyga-ubuntu> man I should have commented that somewhere
[14:33] <ogra_> cachio, yes, i see that ... but if you set it manually the description says UTC as well
[14:33] <ogra_> Time zone: UTC (UTC, +0000)
[14:33] <Chipaca> zyga-ubuntu: yeah :-) a "where does this regexp come from" would be good
[14:33] <cachio> ogra_, yes
[14:33] <zyga-ubuntu> Chipaca: it should be in the git log
[14:33]  * zyga-ubuntu looks
[14:33] <ogra_> so we need to find how to set it like this during build and apply that
[14:34] <ogra_> cachio, can you check if /etc/timezone says n/a on an image that exposes the issue ?
[14:34] <zyga-ubuntu> Chipaca: man, I suck :/
[14:35] <ogra_> (i missed to check it before setting it ... )
[14:35] <zyga-ubuntu> Chipaca: probably in the PR then
[14:35] <zyga-ubuntu> Chipaca: I remember an URL with all the things explained
[14:35] <cachio> ogra_, Etc/UTC
[14:35] <ogra_> interesting
[14:35] <ogra_> it doesnt say Etc here
[14:35] <ogra_> ogra@pi3:~$ cat /etc/timezone
[14:35] <ogra_> UTC
[14:36] <cachio> I have an old image
[14:36] <cachio> let me check in a new one
[14:36] <ogra_> cachio, aha... setting it to Etc/UTC results in:
[14:36] <ogra_> Time zone: n/a (UTC, +0000)
[14:36] <ogra_> dropping the Etc/ fixes it
[14:36] <cachio> hehe
[14:37] <cachio> ogra_, checking in a new image for pi3
[14:37] <cachio> 1 minute
[14:38] <kalikiana> kyrofa: ping
[14:38] <mup> PR snapcraft#1754 opened: nodejs plugin: pass proxy configuration to yarn <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1754>
[14:38] <Chipaca> cachio: ogra_: Etc/ is a directory in tzdata
[14:38] <ogra_> Chipaca, tell that to systemd-timedated
[14:38] <ogra_> :)
[14:39] <ogra_> seems it expects not a path but a TZ name in /etc/timezone
[14:40] <ogra_> hmm, or not
[14:40] <ogra_> ogra@pi3:~$ cat /etc/timezone
[14:40] <ogra_> Europe/Berlin
[14:40] <ogra_> that works correctly
[14:40] <ogra_> only Etc/ doesnt
[14:40] <ogra_> i mean ... it shows the correct TZ (UTC) in brackets ...
[14:41] <ogra_> but n/a as description
[14:41] <Chipaca> ogra_: what does list-timezones give you?
[14:41] <ogra_> though ... perhaps the test should not use the description at all
[14:41] <ogra_> and instead look inside the brackets where the actual TZ name sits
[14:41] <Chipaca> ogra_: timedatectl list-timezones | grep -i etc
[14:42] <ogra_> nothing
[14:42] <ogra_> ogra@pi3:~$ sudo timedatectl list-timezones|grep -i utc
[14:42] <ogra_> UTC
[14:42] <Chipaca> so there you go
[14:42] <ogra_> ogra@pi3:~$ sudo timedatectl list-timezones|grep -i etc
[14:42] <ogra_> ogra@pi3:~$
[14:42] <ogra_> well, but thats technically correct
[14:42] <Chipaca> ogra_: and what happens if you try to set the timezone to something known-bad, e.g. "potato"
[14:42] <kalikiana> sergiusens: ping
[14:43] <mup> Bug #1733881 opened: timezone set to n/a on ubuntu core <Snappy:New> <https://launchpad.net/bugs/1733881>
[14:43] <ogra_> ogra@pi3:~$ sudo timedatectl |grep Time
[14:43] <ogra_>        Time zone: n/a (UTC, +0000)
[14:43] <ogra_> ogra@pi3:~$ cat /etc/timezone
[14:43] <ogra_> Etc/UTC
[14:43] <sergiusens> kalikiana just speak up
[14:43] <ogra_> Chipaca, it complains
[14:43] <Chipaca> ogra_: where did the Etc/UTC come from?
[14:43] <ogra_> Chipaca, my theor is that the test should really look inside the brackets
[14:44] <ogra_> Chipaca, a default
[14:44] <ppisati> $ ./runtests.sh static
[14:44] <ppisati> ./runtests.sh: line 49: mypy: command not found
[14:44] <ppisati> sergiusens: ^
[14:44] <ppisati> elopio: ^
[14:44] <ppisati> kyrofa: ^
[14:44] <ogra_> Chipaca, i think thats the default tzdata ships
[14:44] <ppisati> from origin/master at the time of this writing
[14:44] <sergiusens> ppisati pip install -r requirements-devel.txt
[14:44] <Chipaca> ogra_: maybe tzdata and timedatectl conflict?
[14:44] <ogra_> might be
[14:45] <ogra_> but there is no way to omit tzdata
[14:45] <ogra_> it is super essential
[14:45] <ppisati> sergiusens: ta
[14:45] <ogra_> we'd have to completely change debootstrap and the archive setup for the package (not making it essential)
[14:46] <kalikiana> sergiusens: do you know this code? I'm getting a failure in https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/sources/_local.py#L51 which uses https://github.com/snapcore/snapcraft/blob/master/snapcraft/file_utils.py#L86
[14:46] <Chipaca> ogra_: are you writing /etc/timezone, or /etc/localtime?
[14:46] <niemeyer> cachio: Getting an error on master while trying to run the snap-info spread test:
[14:46] <ogra_> Chipaca, only timezone ...
[14:46] <niemeyer> + apt install -y '/home/gopath/snapd_*.deb'
[14:47] <Chipaca> ogra_: might be relevant: #1554806
[14:47] <mup> Bug #1554806: Change of behavior: "dpkg-reconfigure -f noninteractive" unconditionally overwrites /etc/timezone now <tzdata (Ubuntu):Confirmed> <https://launchpad.net/bugs/1554806>
[14:47] <niemeyer> cachio: That's bogus indeed.. the quoting kills the wildcard
[14:47] <kalikiana> sergiusens: For some reason in the context of LXD on a remote machine and sshfs+sftp, it's not resolving symlinks
[14:47] <niemeyer> cachio: Curious that it's not being an issue?
[14:48] <sergiusens> kalikiana most likely related to the underlying filesystem, you might need to quirk it
[14:48] <cachio> niemeyer, mmmm, I'll fix it
[14:48] <ogra_> Chipaca, well ... more an issue with writable symlinking ...
[14:48] <ogra_> ogra@pi3:~$ ls -l /etc/localtime
[14:48] <ogra_> lrwxrwxrwx 1 root root 23 Nov 22 05:24 /etc/localtime -> /etc/writable/localtime
[14:48] <ogra_> ogra@pi3:~$ ls -l /etc/writable/localtime
[14:48] <ogra_> lrwxrwxrwx 1 root root 33 Nov 22 15:39 /etc/writable/localtime -> /usr/share/zoneinfo/Europe/Berlin
[14:48] <ogra_> ogra@pi3:~$
[14:48] <kalikiana> sergiusens: I noticed link_or_copy.follow_symlinks defaults to False, but shutil copytree is called with symlinks=True - that struck me as odd, but I also don't really know the code
[14:48] <cachio> niemeyer, just 1 min after I finish the fedora 27
[14:48] <ogra_> we have this multi staged symlinks there that always caused some issues
[14:48] <niemeyer> cachio: Thanks.. I really wonder how that's not affecting other runs
[14:48] <ogra_> to fix atomic writing ...
[14:49] <kalikiana> sergiusens: I exhausted sshfs' options more or less... it has 3 link-related options, none of which make that code path work
[14:49] <kalikiana> sergiusens: where I just want to understand why it breaks in the first place
[14:50] <kalikiana> if I manually poke the files in the container, all is fine
[14:50] <sergiusens> kalikiana we've had symlink issues when the underlying fs was hfs, what does, 'poke the files in the container' mean? Through python APIs?
[14:51] <Chipaca> ogra_: timedatectl will always print UTC when timezone is unset / unknown / bogus
[14:52] <ogra_> Chipaca, well, it works correct if the "Etc/" is dropped from /etc/timezone
[14:52] <ogra_> i.e. if the tz entry matches what list-timezones provides
[14:52] <ogra_> the easiest would simply be to put UTC into /etc/timezone at build time
[14:53] <kalikiana> sergiusens: I mean doing `ls -la` or `cat` on the files that give me "[Errno 2] No such file or directory" in Python
[14:53] <ogra_> but OTOH i still think the test is wrong to match the description and not the TZ
[14:53] <sergiusens> kalikiana broken symlinks do that in python
[14:53] <ogra_> it should look between the brackets, not at the descriptive name
[14:54] <ogra_> i.e.
[14:54] <ogra_> Time zone: Europe/Berlin (CET, +0100)
[14:54] <ogra_> you want to match CET here, not "Europe/Berlin"
[14:55] <ogra_> (since this will also be what date uses for example ... the rest is just nice to have but not technically relevant)
[14:55] <kalikiana> sergiusens: right, except I can access the very same files from the container through sshfs via ls and cat
[14:55] <kalikiana> I might be overlooking something here
[14:55] <kalikiana> sergiusens: if it's relevant, it's all relative links
[14:57] <sergiusens> kalikiana break the code in pieces by writing small implementations or activate the debugger (pdb)
[15:02] <kalikiana> yeah, that's what I'll do now, just wanted to query if there were any obvious gotcha's with the current code
[15:02] <kalikiana> thanks
[15:06] <niemeyer> I honestly don't understand.. it consistently fails every single time for me.. how come we don't have broken tests in travis
[15:08] <Chipaca> niemeyer: what fails for you?
[15:09] <niemeyer> Chipaca: + apt install -y '/home/gopath/snapd_*.deb'
[15:09] <niemeyer> Chipaca: This can't possibly work.. the quoting kills the wildcard
[15:10] <cjwatson> It probably turns into a regex interpreted by apt, so might work if it's actually called snapd.deb?
[15:10] <cjwatson> https://travis-ci.org/snapcore/snapcraft/jobs/305836865 doesn't obviously seem to be my problem (this is for https://github.com/snapcore/snapcraft/pull/1754, which doesn't change anything in that area) - known breakage?
[15:10] <mup> PR snapcraft#1754: nodejs plugin: pass proxy configuration to yarn <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1754>
[15:12] <Chipaca> niemeyer: where is that command coming from?
[15:12] <Chipaca> niemeyer: (grep doesn't find it here)
[15:13] <mvo> Chipaca: what command?
[15:13] <Chipaca> mvo: the apt install -y '...'
[15:14] <cjwatson> so set -x output is a bit misleading here
[15:14] <cg_> hey everyone. i'm new to snapcraft and trying to wrap my head around what are probably some simple concepts. right now, the issue is that i have two dependencies, currently defined as parts, and one needs to know the path of the other, or at least a path to some files that need to be shared so it can build.
[15:14] <cjwatson> tests/lib/prepare.sh:        distro_install_local_package "$GOHOME"/snapd_*.deb
[15:14] <cg_> could anyone help me figure this out?
[15:14] <niemeyer> Chipaca: Must be distro_install_build_snapd
[15:14] <cjwatson> it then gets quoted when distro_install_local_package calls   apt install $flags "$@"
[15:14] <Chipaca> cjwatson: niemeyer: but distro_install_local_package "$GOHOME"/snapd_*.deb <- the * isn't quoted
[15:14] <cjwatson> and set -x renders that as single-quotes, but that doesn't mean it was called that way
[15:14] <Chipaca> ah
[15:14] <cjwatson> the problem is that snapd_*.deb didn't exist so the glob didn't expand
[15:15] <cjwatson> and something didn't pick that up as a failure earlier when it would have been 90% less confusing
[15:15] <cjwatson> (or, yes, possibly from distro_install_build_snapd as the caller; same either way)
[15:16] <niemeyer> cjwatson: Yeah, that must be it
[15:16] <niemeyer> Either it's failing, or the prepare is just bogus and is not doing what it should
[15:17] <niemeyer> The only thing I'm doing special here is to try to run a single test instead of the whole suite
[15:17] <niemeyer> linode:ubuntu-16.04-64:tests/main/snap-info
[15:17] <mup> PR snapcraft#1749 closed:  tests: add a script to run autopkgtests in the ppa  <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1749>
[15:23]  * zyga-ubuntu is done with the kids and returns to work
[15:24] <mvo> zyga-ubuntu: hm, the debian-sid tests are slightly strange, it fails with "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks", I think I try to ssh into one
[15:26] <zyga-ubuntu> mvo: looks like snap-confine is built without apparmor
[15:26] <zyga-ubuntu> mvo: we may need to change the dpkg vendor test (remove it) in debian/rules
[15:27] <zyga-ubuntu> mvo: hmmm, actually
[15:27] <zyga-ubuntu> mvo: that probably makes no sense
[15:28] <mvo> zyga-ubuntu: I thought I had done that already
[15:29] <zyga-ubuntu> mvo: yeah, worth looking into for sure
[15:29]  * zyga-ubuntu listens to "not your kind people" today
[15:36] <mup> PR snapd#4263 closed: overlord/devicestate:  best effort to go to early full retries for registration on the like of DNS no host <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4263>
[15:38] <gsilva> kyrofa:  have you seen the PR? It failed for some reason but I can't tell why
[15:38] <gsilva> Hello all, by the way
[15:38] <mup> PR snapd#4109 closed: cmd/libsnap: fix parsing of empty mountinfo fields <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4109>
[15:42] <zyga-ubuntu> pedronis: posted question on 4260
[15:43] <cg_> Anyone available to help with what I'm gonna guess are some pretty basic questions?
[15:44] <zyga-ubuntu> cg_: just ask your questions please, we'll do our best
[15:45] <cg_> Yeah, tried that before but didn't want to just keep spamming...
[15:46] <cg_> Alright, so I'm building a ROS project. It has two dependencies that I've been installing outside of ROS: our ethercat kernel modules and a library that provides an interface to ethercat.
[15:46] <pedronis> zyga-ubuntu: that's auto-import, not the store,  not sure what those files are though
[15:46] <pedronis> left overs?
[15:47] <zyga-ubuntu> cg_: are you working on a classic or a core device? (classic = with typical package manager + snapd on the side; core = with just snapd)
[15:47] <pedronis> I would need to dig more
[15:47] <zyga-ubuntu> pedronis: aha
[15:47] <zyga-ubuntu> pedronis: my measurement code can capture that
[15:47] <zyga-ubuntu> pedronis: thanks for looking
[15:47] <zyga-ubuntu> pedronis: I'll untangle the restore code and will be able to find those (hopefully) quickly
[15:47] <zyga-ubuntu> cg_: btw, kyrofa here is a ros expert
[15:47] <zyga-ubuntu> cg_: for kernel modules on core device you will need your own kernel + gadget snap
[15:48] <kyrofa> kalikiana, pong
[15:48] <cg_> zyga-ubuntu: i'm working with classic right now, hoping to move to core
[15:48] <zyga-ubuntu> cg_: we may need a snapd interface for the ethercat but I don't know what this, just speculating so far
[15:48] <zyga-ubuntu> cg_: ok
[15:48] <zyga-ubuntu> cg_: that's fine, it's a well-defined move for this kind of thing
[15:50] <cg_> zyga-ubuntu: so before i even start dealing with the kernel nonsense, i'm trying to get my head around what feels like some real Snapcraft 101 crap. I need to provide the paths to different dependencies so they can install correctly. The interface that helps us communicate with our ethercat driver needs to know the path to the ethercat library, and then ROS needs to know the path to the interface.
[15:51] <kalikiana> kyrofa: Hey. Was wondering about file_utils.py / _local.py if you happend to know about its custom handling of symlinks. I'm doing some testing atm why the code would say "file not found" when ls and friends are happy with the files
[15:51] <cg_> zyga-ubuntu: In my manual install world, I'd just clone my repos into ~/, build from there, point to ~/EtherCAT_Master or whatever
[15:51] <zyga-ubuntu> cg_: path as in runtime path or build time?
[15:52] <kyrofa> kalikiana, I am familiar with it, could you give me more details?
[15:52] <zyga-ubuntu> cg_: suggestion: unless you absolutely must, try to snap hello world code first to see what you get and how it is built
[15:52] <cg_> zyga-ubuntu: I'm gonna need both. Totally hung up at build time right now.
[15:52] <zyga-ubuntu> cg_: and then how it operates (both are differnt)
[15:52] <zyga-ubuntu> cg_: I know ... little about ros (/me looks at ROS topic mug from roscon) but build time should be handled by snapcraft
[15:53] <cg_> zyga-ubuntu: these aren't ROS dependencies, as far as it is concerned. they're just C libraries that we reference, ROS has no idea what to do with them.
[15:53] <zyga-ubuntu> cg_: if not kyrofa or sergiusens can help you and make fixes to snapcraft; you can also ask on the forum (forum.snapcraft.io) or talk in rocket.ubuntu.com (snapcrafters hang out there routinely)
[15:53] <zyga-ubuntu> cg_: I'm mostly focused on runtime side of snapd
[15:54] <cg_> zyga-ubuntu: The ROS aspect of this really doesn't matter. If I install these dependencies manually, my ROS part builds happily, everything works great. I'm just trying to cut out the manual steps.
[15:54] <cg_> zyga-ubuntu: But yeah, right now, I'm hung up on building
[15:54] <zyga-ubuntu> cg_: are those things packaged in some way?
[15:55] <zyga-ubuntu> cg_: snapcraft has a concept of "build packages"
[15:55] <zyga-ubuntu> cg_: (with the usual meaning)
[15:56] <cg_> zyga-ubuntu: They are, but it feels sorta... hacky. Ignoring what they're actually called, Dependency 2 has the path to Dependency 1 hard-coded. I can feed it a path, I'm just lost RE: what that path should be in snapcraft world. Make sense?
[15:57] <mvo> Chipaca: hm, hm, all the except tests are failing in debian-sid. I have a look in a bit
[15:58] <Chipaca> mvo: expect*?
[15:58] <cg_> zyga-ubuntu: Normally, I can just point it at the repo that I've cloned to my home folder. With snapcraft handling it and each dependency broken into separate parts, I'm unsure of how to tell Dependency 2 how to find Dependency 1. It doesn't feel like a healthy practice but I'm unsure of how Snapcraft would prefer me to approach it.
[15:59] <kyrofa> Hey there cg_, are we talking about https://forum.snapcraft.io/t/part-referencing-other-part/2929/3 ?
[15:59] <mvo> Chipaca: eh, yes
[15:59] <Chipaca> mvo: :)
[15:59] <cg_> kyrofa: Hello! Yessir
[15:59] <mvo> Chipaca: anyway, just wanted to let you know, I need to take a break now
[15:59] <Chipaca> mvo: np
[16:00] <kalikiana> kyrofa: so this is with a LXD container and files served via sshfs/sftp, which means smylinks might work differently; the error I'm getting is at https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/sources/_local.py#L51 which uses https://github.com/snapcore/snapcraft/blob/master/snapcraft/file_utils.py#L86  -- it's giving me a shutil.Error with a list of files and [Errno 2] No such file or directory in the end
[16:00] <kalikiana> - all the given symlinks resolve  fine with ls or cat in a shell in the container, just the specific snapcraft code doesn't work
[16:00] <kyrofa> cg_, I asked a question there for you
[16:00] <cg_> kyrofa: Thanks, on it
[16:02] <zyga-ubuntu> 2PRs short of one page
[16:02] <zyga-ubuntu> some just wait for tests
[16:02] <zyga-ubuntu> mvo: can you please look at 4140
[16:02] <zyga-ubuntu> mvo: it's green and has +1 from me
[16:02] <zyga-ubuntu> mvo: with a quick look we can get down to 26 PRs
[16:02] <mup> PR snapd#4184 closed: tests: adding new test for uhid interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4184>
[16:03] <pedronis> Chipaca: anyway firt pass at that issue is probably remembering who did what,  unless the store apis change radically
[16:04] <Chipaca> pedronis: … which issue?
[16:04]  * Chipaca is lost
[16:04] <pedronis> Chipaca: us sending no auth with auto refreshes
[16:05] <Chipaca> pedronis: ah
[16:06] <zyga-ubuntu> pstolowski: 4218 needs a 2nd look from you
[16:07] <pstolowski> zyga-ubuntu, ok, looking
[16:07] <pedronis> mvo: do we run autopkgtest daily?
[16:17] <pstolowski> cachio, I think you forgot to push your changes to #4218
[16:17] <mup> PR #4218: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4218>
[16:18] <cachio> pstolowski, almost pushed
[16:18] <cachio> 1 min please
[16:18] <pstolowski> cachio, sure, np
[16:20] <zyga-ubuntu> cachio: comment son 4078
[16:21] <cachio> pstolowski, push donedone
[16:24] <pstolowski> ok
[16:26] <cachio> zyga-ubuntu, done
[16:26] <cachio> zyga-ubuntu, wait
[16:26] <cachio> zyga-ubuntu, now :)
[16:27] <mup> PR snapd#4273 closed: timeutil: introduce helpers for weekdays and TimeOfDay <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4273>
[16:27] <zyga-ubuntu> cachio: thank you!
[16:27] <zyga-ubuntu> cachio: I'm really curious what that about
[16:27] <cachio> zyga-ubuntu, yaw
[16:27] <cachio> zyga-ubuntu, yes, it is really weird, but I could reproduce it even manually
[16:28] <zyga-ubuntu> cachio: do you know if any snaps were installed after reboto?
[16:28] <zyga-ubuntu> *reboot
[16:29] <cachio> no, I just reproduces the test but manually
[16:29] <cachio> just to make sure the test was working properlyu
[16:29] <zyga-ubuntu> interesting
[16:29] <zyga-ubuntu> well, we'll keep digging
[16:30]  * ikey grins in advance of teaching niemeyer that rolling can be stable
[16:31] <mup> PR snapd#4275 closed: spread.yaml,tests: move most of project-wide prepare/restore to separate file <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4275>
[16:31] <pstolowski> niemeyer, pedronis updated 4259 with new test
[16:31] <zyga-ubuntu> Chipaca: if around, could you do 4276
[16:32] <mup> PR snapd#4276 opened: tests: document and slightly refactor prepare/restore code <Created by zyga> <https://github.com/snapcore/snapd/pull/4276>
[16:32] <zyga-ubuntu> cachio: can you also look please, there's one XXX thre I don't fully understand and I suspect you know
[16:32] <Chipaca> zyga-ubuntu: ◯
[16:33] <sergiusens> zyga-ubuntu we do not use rocket anymore
[16:33] <zyga-ubuntu> Chipaca: emoji don't show up in linux console
[16:33] <zyga-ubuntu> sergiusens: oh, I didn't know thanks for sharing that
[16:33] <zyga-ubuntu> I wish forum and rocket could merge shomehow
[16:33] <zyga-ubuntu> but IRC is just so darn immortal
[16:33] <niemeyer> ikey: I literally said "anyone publishing such snaps needs to understand and agree to preserve a stable API", to which you responded "that’s not gonna happen"
[16:33] <Chipaca> zyga-ubuntu: 💩
[16:33] <niemeyer> ikey: I never even touched the word "rolling"
[16:33] <ikey> woah woah
[16:33] <ikey> back up a bit there sham
[16:33] <ikey> im poking fun
[16:34] <ikey> didnt realise there was a bear on the end of it
[16:34] <ikey> the way you worded it was "frozen forever"
[16:34] <ikey> and thats not gonna happen
[16:34] <ikey> stable yes, locked, no
[16:34] <ikey> distinction. :]
[16:34] <niemeyer> ikey: I also didn't say "locked" either :-)
[16:34] <niemeyer> ikey: Or "frozen"
[16:35] <ikey> sure - i was replying to my interpretation based on the facts provided to me by you. notice i still agreed to a call as it was clear not all facts are present on both sides ;)
[16:35] <niemeyer> ikey: We just need it stable.. which means existing functionality cannot be removed or broken
[16:35] <zyga-ubuntu> ikey: where there's honey, there's bear ;-)
[16:35] <niemeyer> Including both APIs and ABIs
[16:35]  * zyga-ubuntu just makes up proverbs
[16:35] <ikey> ABIs *can* be changed
[16:35] <ikey> This is rolling, by design they need to
[16:36] <ikey> And this isn't a derivable snap, it exists purely to satisfy LSI :P
[16:36] <niemeyer> Sure.. then it can't be a base snap
[16:36] <ikey> well then ill fuck off and build a flatpak
[16:36] <ikey> cya
[16:36] <niemeyer> ikey: That's why a hangout is probably better :)
[16:37] <ikey> at this point niemeyer you insult me after having kept me waiting over a week with this tiresome review only to tell me what can and cant be in a base snap
[16:37] <ikey> without understanding the fundamentals of the situation
[16:37] <ikey> seriously i dont need snaps as much as snaps need external verification and technical acceptance
[16:37] <ikey> i dont need the politics and stress of it
[16:38] <kalikiana> sergiusens: did you see my email?
[16:39] <niemeyer> ikey: I'd still prefer to have this conversation on a hangout.. the few sentences I wrote aren't really personal at all.. I'm politely trying to explain the issues we're trying to address, and looking for help
[16:40] <ikey> as am - i cant word too good because im trying to stick a boot on at the same time
[16:40] <ikey> laces are hard
[16:40] <ikey> and fwiw im not personally insulted - there are levels :p
[16:40] <ikey> but im not against a phone call
[16:40] <niemeyer> ikey: https://hangouts.google.com/call/PwzjjN4oHDxFeAyGDiJ_AAEE
[16:40] <ikey> yeah gizza sec genuinely fighting with a boot here
[16:41] <sergiusens> kalikiana the one I replied to?
[16:41] <niemeyer> Will grab a cuppa coffee meanwhile... HO still open
[16:42] <mup> PR snapd#4266 closed: snapstate: add new refresh-hints helper and use it <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4266>
[16:42] <niemeyer> If anyone else closely involved with base snaps wants to join, that's welcome too
[16:42] <niemeyer> mvo, jdstrand ^
[16:43] <kalikiana> sergiusens: I don't see a reply... not on my phone either, in case this was tb being broken
[16:45] <zyga-ubuntu> cachio: you have comments on 4227
[16:45] <zyga-ubuntu> cachio: looks like super simple ones
[16:46] <cachio> zyga-ubuntu, ok, finishing fedora resizing
[16:46] <zyga-ubuntu> cachio: thank you
[16:47] <sergiusens> kalikiana check your spam and filters (look in AllMail)
[16:47] <kalikiana> sergiusens: I don't have any spam filters, this is good old canonical imap
[16:51] <ikey> o-o
[16:51] <ikey> call closed
[16:53] <zyga-ubuntu> ikey: what happened?
[16:54] <ikey> fixed ^^
[17:02] <sergiusens> kyrofa elopio can you join me on a hangout right now?
[17:02] <kyrofa> sergiusens, sure
[17:03] <sergiusens> kyrofa use the weekly
[17:04] <kyrofa> sergiusens, I'm there
[17:04] <elopio> sergiusens: on my way
[17:20] <zyga-ubuntu> 14.04 has something very very wrong
[17:20] <zyga-ubuntu> snapd starts randomly when it is supposed to be down
[17:20] <zyga-ubuntu> cannot wait to find the culprit
[17:25] <pedronis> that is interesting
[17:28] <cachio> niemeyer, I dont see dsingle cuotes use to install any package
[17:29] <cachio> niemeyer, while I try to see why the snap-info test failedf
[17:29] <cachio> niemeyer, do you have any log?
[17:41]  * zyga-ubuntu breaks for some rest, will return to push more branches 
[17:50] <zyga-ubuntu> so, why is main never failing
[17:50] <zyga-ubuntu> I'm running main all the time, almost, for the past two days
[17:50] <zyga-ubuntu> could it be that one of the "lesserly interesting" tests in other suites is messing things up
[17:51] <zyga-ubuntu> mvo: question, could we get a different entry in travis, one for running main and one for running all the things but main
[17:51] <zyga-ubuntu> mvo: we'd use more machines but they would also run much more quickly
[17:51] <zyga-ubuntu> mvo: and I suspect a pattern would emerge
[17:51] <zyga-ubuntu> mvo: (maybe even run suites independently from each other)
[17:51] <zyga-ubuntu> mvo: (like one status per suite)
[17:52] <zyga-ubuntu> mvo: this could have 3 advantages: restarts would be per suite, we'd get data about relative rate of random errors in each suite
[17:52] <zyga-ubuntu> mvo: and we could perhaps lower the number of workers
[17:52] <zyga-ubuntu> (or keep workers and get super-fast results)
[17:53] <zyga-ubuntu> if main is working on my "consumer" home network it should not fail any less on the fancy datacenter speedy network and CPUs
[17:54] <zyga-ubuntu> and meanwhile, I'll see what I get if I run other suites
[17:54] <zyga-ubuntu> I'd be really upset if it was like upgrade/basic killing our time by leaving junk
[17:58] <mup> PR snapd#4272 closed: snapstate: ensure RefreshSchedule() gives accurate results <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4272>
[17:58] <mup> PR snapd#4277 opened: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <https://github.com/snapcore/snapd/pull/4277>
[17:58] <Chipaca> 12 37 files changed, 741 insertions(+), 309 deletions(-)
[17:59] <Chipaca> s/^12//
[17:59] <Chipaca> :-/
[17:59] <Chipaca> anyway, EOD for me
[17:59] <zyga-ubuntu> Chipaca: hohoho
[17:59] <zyga-ubuntu> Chipaca: oooh
[17:59] <zyga-ubuntu> Chipaca: please please please
[17:59] <Chipaca> zyga-ubuntu: wut
[17:59] <zyga-ubuntu> Chipaca: 4276
[17:59] <zyga-ubuntu> Chipaca: just a look
[17:59]  * Chipaca justs a look
[18:00] <zyga-ubuntu> Chipaca: per commit diff is easier to read
[18:03] <Chipaca> zyga-ubuntu: nice
[18:04] <Chipaca> zyga-ubuntu: http://gph.is/QUEGv3
[18:04]  * zyga-ubuntu types the URL on another computer
[18:05] <zyga-ubuntu> LOL
[18:06] <zyga-ubuntu> Chipaca: thanks, enjoy your evening
[18:11] <zyga-ubuntu> Chipaca: should we retry 504s from the store?
[18:11] <zyga-ubuntu> snap install --channel=beta core
[18:11] <zyga-ubuntu> that just failed with received an unexpected http response code (504)
[18:16] <ikey> zyga-ubuntu, qemu-static arm64 for /bin/sh - go!
[18:16] <ikey> definitely the most evil idea ive had all year.
[18:17] <zyga-ubuntu> ikey: heh, that might actually work pretty well
[18:17] <zyga-ubuntu> *for some definition
[18:17] <ikey> XD
[18:17] <zyga-ubuntu> single threaded
[18:17] <zyga-ubuntu> and ... static
[18:17] <ikey> lol
[18:17] <zyga-ubuntu> (insert meme with dog and "LOL", "so static", "enterprise", "runs on RHEL6"
[18:18] <ikey> yeah but if its not running on btrfs..
[18:18] <zyga-ubuntu> oh, why?
[18:18] <ikey> idk you said lol and enterprise
[18:18] <ikey> felt relevant
[18:18] <zyga-ubuntu> ikey: RHEL defines enterprise as RHEL and they define btrfs as xfs (or something)
[18:18] <zyga-ubuntu> ;-)
[18:19] <zyga-ubuntu> I like the "runs on RHEL6" as a meme thing
[18:19] <ikey> lol
[18:19]  * ikey used to live by reiserfs
[18:19] <ikey> emphasis on used to
[18:22] <niemeyer> cachio_afk: There's some other bug
[18:23] <niemeyer> cachio_afk: You should be able to reproduce it by just running spread to run this one task: linode:ubuntu-16.04-64:tests/main/snap-info
[18:23] <niemeyer> cachio_afk: The bogus command line, as cjwatson mentioned, is just a side effect of snapd not being properly built
[18:23] <niemeyer> cachio_afk: The question is why it wasn't properly built
[18:25] <niemeyer> Taking a break.. back later to finish the images
[18:26] <zyga-ubuntu> niemeyer: o/
[18:26] <zyga-ubuntu> niemeyer: we're on one page now ^_^
[18:32] <ikey> https://github.com/solus-project/runtime-snaps/commit/f91097d47fc1fce231110c87c2469a3f74df0a37 <- better.
[18:35]  * zyga-ubuntu -> shopping
[19:51] <zyga-ubuntu> jdstrand: hey
[19:51] <zyga-ubuntu> jdstrand: not much updates today, I'm getting tea and I'll iterate on both interesting PRs
[19:51] <zyga-ubuntu> jdstrand: I'm pushing towards finding why test suite is so unreliable
[20:36] <niemeyer> cachio: We've got multiple issues in our suite apparently
[20:38] <niemeyer> cachio: One of them is prepare-project.sh seems to be missing set -e, which means it's not stopping on errors
[20:38] <cachio> niemeyer, let me see
[20:38] <niemeyer> The build procedure is also for some reason not building _build/snap, which is depended upon for building the man pages
[20:39] <niemeyer> That's the error that makes the snapd_*.deb not be generated
[20:41] <niemeyer> cachio: I got this sort of error by just trying to run the task mentioned above
[20:41] <niemeyer> cachio: Possibly means I have a dirty tree.. I'll try again with a clean tree, but we should at least ensure all our scripts have -e so they fail on problems
[20:42] <cachio> niemeyer, ok, I jast reviewed the log and "set -e" was not removed from prepare-project
[20:42] <cachio> niemeyer, at least during the last 6 months
[20:43] <niemeyer> cachio: Well, does that matter? :)
[20:43] <cachio> niemeyer, we should add it
[20:43] <niemeyer> Yeah
[20:43] <niemeyer> cachio: We can also take the chance to grep quickly and see if there are others missing
[20:44] <cachio> niemeyer, doing that
[20:45] <cachio> niemeyer, most of the scripts on tests/lib dont have "set -e"
[20:46] <niemeyer> cachio: Some of them are used as libraries, so that's less of an issue I *think*
[20:46] <niemeyer> cachio: Won't hurt to have it, though
[20:47] <cachio> niemeyer, agree
[20:47] <cachio> I'll create a PR with that
[20:47] <niemeyer> cachio: Thanks
[20:47] <cachio> niemeyer, by the way, snapd-vendor is being sync
[20:47] <niemeyer> cachio: Looking into Spread-46 now
[20:47] <cachio> niemeyer, ok, I am testing debian-9
[20:48] <cachio> I'll push the changes once there are not errors anymore
[20:54] <niemeyer> cachio: Spread-46 has *grown* since we last tried
[20:54] <niemeyer> cachio: It's now at 2.2GB
[20:54] <cachio> I removed about 200 MB
[20:54] <niemeyer> Did you try the zero trick?
[20:55] <cachio> yes
[20:55] <niemeyer> (after that)
[20:55] <cachio> yes
[20:55] <cachio> the last think I did
[20:55] <cachio> let me check again
[20:56] <niemeyer> Well.. something curious is happening.. it's now larger
[20:56] <niemeyer> cachio: I'm booting it back up.. should take a few seconds
[21:06] <cachio> niemeyer, I could remove some locales that are using more than 100MB
[21:11] <cachio> niemeyer, not sure if it could affect anything
[21:13] <niemeyer> cachio: It's certainly less wasted space in the image
[21:13] <niemeyer> cachio: But it still doesn't explain why removing data made the image larger
[21:13] <niemeyer> cachio: Something else must have happened there
[21:13] <niemeyer> cachio: Does it have auto-update on, maybe?
[21:15] <cachio> niemeyer, it just updates repo metadata
[21:15] <cachio> I could disable it but not sure if then it could cause any issue
[21:16] <cachio> niemeyer, well it is alreasy disabled
[21:21] <cachio> niemeyer, could you try again to build the image?
[21:21] <niemeyer> cachio: Sure, trying it now
[21:22] <cachio> niemeyer, the only thing that it missing is to remove the locales
[21:25] <niemeyer> cachio: It's back at 1.7GB
[21:25] <niemeyer> cachio: 1.76, to be more precise
[21:25] <niemeyer> cachio: What did you do there?
[21:26] <cachio> cleaned up again dnf and removed 1 pkg and the zyga magic
[21:26] <zyga-ubuntu> try e4defrag
[21:26] <zyga-ubuntu> that may clear extra blocks for zero
[21:26] <zyga-ubuntu> (zero after)
[21:27] <cachio> ok
[21:27] <cachio> niemeyer, could you please start the vm?
[21:28] <niemeyer> It's coming up
[21:43] <cachio> niemeyer, could you please try againdf
[21:43] <niemeyer> cachio: On it
[21:43] <cachio> 1gb of data used
[21:44] <cachio> locales removed
[21:46] <niemeyer> cachio: 1.6G image
[21:49] <cachio> niemeyer, how do you create the image? it is a linode api?
[21:50] <niemeyer> cachio: Using the console.. I don't think there's an API yet
[21:51] <niemeyer> cachio: copy the disk, shutdown the machine, attempt to shrink the disk
[21:51] <niemeyer> cachio: trash it, start over
[21:52] <cachio> the shrink is not so powerfull :)
[22:02] <niemeyer> cachio: It's just resize2fs
[22:04] <niemeyer> cachio: We can try e4defrag
[22:05] <cachio> I already did in the vm
[22:05] <cachio> niemeyer, not sure if you can do it from the console
[22:05] <niemeyer> cachio: Oh
[22:05] <niemeyer> cachio: Ok.. so really have no idea about why it's not getting down to more reasonable sizes
[22:06] <cachio> disk usage is less than 1.1 GB
[22:06] <cachio> niemeyer, I checked that at the end
[22:07] <niemeyer> cachio: Well, that's logical size
[22:07] <niemeyer> cachio: Image is block size
[22:07] <niemeyer> cachio: A 1 byte file still takes one block
[22:08] <niemeyer> Sort of.. file system pages vs. blocks..
[22:08] <gsilvapt> kyrofa, since you are around, could you please have a look PR 1746? The build failed but I don't think it is entirely related with poor software quality
[22:08] <mup> PR #1746: many: have AuthContext expose device store-id, serial and serial-proof signing to the store <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1746>
[22:09] <niemeyer> cachio: Can we take more data out of it?
[22:09] <kyrofa> gsilvapt, will do, working on something else at the moment but I'll take a look when I can
[22:09] <gsilvapt> kyrofa, of course, take your time! :-)
[22:10] <cachio> niemeyer, if you want I could create a new image from scratch
[22:10] <cachio> install deps and see the size
[22:13] <niemeyer> cachio: Sounds good.. another approach would be doing what I suggested yesterday, listing packages ordered by size and taking low hanging fruits out
[22:13] <niemeyer> cachio: Whatever you prefer
[22:14] <cachio> niemeyer, I already did that
[22:14] <cachio> I cleand 200MB doing this
[22:14] <cachio> cleaned
[22:14] <niemeyer> cachio: Yeah, so more of it? :)
[22:15] <cachio> niemeyer, well, the problem is that the bigger ones seem to be needed, I can make another try
[22:15] <cachio> and remove more pkgs
[22:17] <niemeyer> cachio: That's what I did when I got our images down to 600MB, but again any approach you prefer is fine by me
[22:18] <cachio> niemeyer, ok, I'll try it tomorrow morning
[22:18] <niemeyer> cachio: Thanks again
[22:21] <cachio> zyga-ubuntu, https://travis-ci.org/snapcore/snapd/builds/305892636#L1473
[22:22] <cachio> zyga-ubuntu, there it is the info for the "no interfaces found" issue
[22:30] <zyga-ubuntu> cachio: I'll check it out tomorrow, I'm sleeping here almost :)
[22:30] <cachio> zyga-ubuntu, sure, just I wanted to leave you a message for tomorrow
[22:31] <cachio> zyga-ubuntu, enjoy your dreams :)
[22:39] <sergiusens> kyrofa elopio kalikiana https://insights.ubuntu.com/2017/11/22/announcing-snapcraft-2-35/