/srv/irclogs.ubuntu.com/2017/11/27/#snappy.txt

mborzeckimorning05:57
mupPR snapd#4269 closed: timeutil: new refresh timer parser <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4269>06:06
mborzeckimvo: morning06:45
mvohey mborzecki, good morning!06:47
mborzeckimvo: did you have your morning coffee? because I need some help right here https://github.com/snapcore/snapd/pull/4296#discussion_r15311617906:48
mupPR #4296: packaging/arch: pre-create snapd directories when packaging <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4296>06:48
mvomborzecki: sure, let me have a look. I had my cup of morning tea (Hainan Bai Cha Lu which I can hightly recommend ;)06:49
mvomborzecki: haha, yeah, its confusing because snapd creates dirs on demand so if we don't update the dirs files we don't notice06:50
mvomborzecki: I think you are on the right track, i.e. lets make sure we get it right at least once06:50
mborzeckihaha06:50
mborzeckiare any of the directories listed specific for ubuntu package only?06:51
mborzeckiumm, and /var/snap, it holds SNAP_DATA or SNAP_USER_COMMON?06:53
mvomborzecki: yeah, we want this too06:55
mvomborzecki: the dirs/dirs.go is the best source I think06:55
mvomborzecki: because we use it for mocking in the tests pretty much everything is listed there06:55
mborzeckiok, i'll update the list for arch then along with some other fixes06:56
mvomborzecki: sounds good, bonus points for a PR that also updates the other packaging :)06:56
mborzeckispread tests actually caught stuff like a missing manpage for snap, some missing dirs in /var/lib/snap06:56
mvomborzecki: nice!06:58
mvomborzecki: thanks again for doing those new arch tests06:58
mupPR snapd#4300 opened: packaging/arch: install missing directories, manpages and version info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4300>07:16
ogra_cjwatson, does LP snap building have a network prob ? https://launchpad.net/~snappy-hwe-team/+snap/wifi-connect-daily (seems there are proxy errors for git.lp.net)08:06
mborzeckipushed another set of fixes for spread with Arch, let's see how far we get this time08:07
mborzeckipstolowski: morning08:11
pstolowskimborzecki, hey!08:11
zyga-solushello08:16
zyga-solusmvo: sorry for being late, my daughter is sick and I'm the parent that says at home08:16
zyga-solusthings are under control now so I'll get to work08:16
mborzeckizyga-solus: hey, sorry to hear about your daughter, hope she recovers quickly08:22
zyga-solusmborzecki: just some fever08:23
zyga-solusmborzecki: she wasn't sick in years so it's an event :)08:23
zyga-solusmborzecki: it started (obviously) on Friday after the swimming pool, she's much better now08:24
mborzeckii suppose one of the downsices of coming back to polish climate08:24
zyga-solusindeed08:24
zyga-solusbut they'd love to see some snow again08:24
zyga-solusso the mood is very good08:25
mborzeckii remember i used to like playing in snow when i was a child08:25
mupPR snapd#4300 closed: packaging/arch: install missing directories, manpages and version info <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4300>08:26
mborzeckithen i grew up and had to commute to work in the morning, in the snow:/08:26
zyga-solusmborzecki: she saw snow when she was maybe 6 or 508:26
zyga-solusmborzecki: we went to a valley in the pyrenees :)08:27
mborzeckihahah08:27
zyga-solusshe cut her arm on some sharp ice08:27
zyga-solusand keeps recalling that whenever we mention winter again :)08:28
mborzeckiouch08:28
mupPR snapd#4294 closed: Mount with x-gdu.hide option <Created by azzar1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4294>08:28
zyga-solusman, we're rocking at 20 PRs08:28
zyga-solusand many more to land soon08:28
zyga-solushttps://github.com/snapcore/snapd/pull/4281 needs a 2nd review and is green08:28
mupPR #4281: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281>08:28
* ikey will be sending more once he's alive again..08:28
zyga-solusikey: hey, thank you :)08:29
zyga-solusyour PRs are always welcome :)08:29
ikeymerci :]08:29
ikeygotta work out how to get fedora nvidia happy08:29
ikeythe new glvnd stuff08:29
zyga-solusmvo: I wonder what to do about https://github.com/snapcore/snapd/pull/4140 -- I'll ask jdstrand for a look but it "feels" ready otherwise08:30
mupPR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140>08:30
zyga-solusikey: I think (fortunately) everyone will use it eventually08:30
zyga-solus(much better than dpkg alternatives or other voodoo)08:31
ikeyyeah we have an open issue in solus for it too08:31
ikeywe also have to do similar levels of magic filesystem butchery to make GL work08:31
ikeyi.e. /usr/lib64/libGL.so.1: symbolic link to /usr/lib64/glx-provider/nvidia/libGL.so.384.9808:31
ikeybut we live in a post update-alternatives world :p08:32
ikeyspeaking of jdstrand - around today?08:32
zyga-solusikey: I cannot say, let me check08:33
ikeymerci08:33
zyga-solusikey: he seems to be around today08:36
ikeyah cool08:36
ikeythere is light at the end of the tunnel then ^^08:36
zyga-solusikey: and it says "choooo chooo"08:38
ikeylol yeah08:38
mvozyga-solus: yeah, I think we need a security review but I would love to merge it08:39
zyga-solusmvo: indeed, I would like to wait for jdstrand08:39
mvozyga-solus: re late> no worrie08:39
mvos08:39
* ikey blinks at the external repos forum thread08:42
ikeynitrux reasoning is uh, off, to say the least08:42
ikeythey're insinuating that snapd-glib{,qt} isnt maintained08:43
zyga-solusikey: which thread is that?08:45
ikeyhttps://forum.snapcraft.io/t/external-repositories/1760/14408:46
mborzeckiinteresting, anyone used nitrux? what's special about this one?08:47
ikeyit uses not-a-budgie08:47
ikey(the desktop looks like a qt/kde budgie)08:47
ikeyand i think they do hardware stuff?08:47
mborzeckiinteresting08:47
mborzeckitheir page has some issues in ff through :(08:48
zyga-solusmvo: do you know what is the status of https://github.com/snapcore/snapd/pull/3998 -- it feels like that's something on our plate now09:27
mupPR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>09:27
zyga-solusmvo: let's talk about that at the standup perhaps?09:28
zyga-solusmvo: and on the same vein: https://github.com/snapcore/snapd/pull/4049 -- this is clearly our game but I'd like to know your plans for it09:28
mupPR #4049: debian,vendor: import github.com/snapcore/squashfs and use <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4049>09:28
mvozyga-solus: iirc one blocker is that the downstreams need an updated seccomp golang09:29
mvozyga-solus: but yeah, we need to talk about it09:29
mvozyga-solus: iirc the code itself (without our libseccomp etc) is fine now, I updated the tests ages ago09:29
cjwatsonogra_: Thanks, something does seem to be badly wrong with the snap-proxy.  Investigating09:30
ogra_thx09:30
cjwatsonogra_: Should be fine now09:57
cjwatson(restarted squid)09:57
ogra_cjwatson, thanks a lot10:01
mupPR snapd#4301 opened: interfaces: small helpers <Created by stolowski> <https://github.com/snapcore/snapd/pull/4301>10:03
=== chihchun is now known as chihchun_afk
mupPR snapd#4302 opened: timeutil, overlod/snapstate: cleanup remaining pieces of timeutil weekday support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4302>10:04
zyga-soluspstolowski: reviewed10:07
pstolowskizyga-solus, that was quick, thanks! will move the test into separate method10:08
zyga-solusthanks10:08
zyga-solusmborzecki: same, though asked a small uncomfortable question10:08
=== chihchun_afk is now known as chihchun
pstolowskizyga-solus, done10:16
mborzeckizyga-solus: thanks, and mvo thanks for addressing zyga's comment :)10:20
mvoyw10:21
mborzeckipstolowski: added some reflect magic in the comments to your PR10:54
pstolowskimborzecki, I saw that, thanks! i like that, let's see if anyone opposes it, if not this is going to simplify some of the changes i'm doing right now, actually10:59
mborzeckipstolowski: i'm quite sure it works for simple assignable types, haven't checked slices or functions11:00
zyga-solusmborzecki: I think we try to avoid reflection in non-test code11:03
mvomeh, tests are hitting the timeouts pretty consistently currently :(11:05
pstolowskiah, here you go11:05
mborzeckizyga-solus: you mean hand written reflection? because json de/encoding does the same (just in more horrid way)11:05
mvomborzecki: 4285 has conflicts (in case you haven't seen that already)11:07
mborzeckimvo: thaks, i'll take a look later, hopefully nothing too complicated11:09
zyga-solusmborzecki: I mean "import reflect" in general, that was my experience at least11:12
zyga-solusmborzecki: but we'll see, I'm don't know :-)11:12
zyga-solusmvo: store woes or things we're not re-trying?11:12
mvozyga-solus: not sure11:16
mvomborzecki: yeah, probably small stuff, I also added some comments, a bit drive-by, sorry for that, will do a more systematic one too11:16
mupPR snapd#4303 opened: interfaces: use ConnectedPlug/ConnectedSlot types (step 1) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4303>11:28
pedronismvo: hi, I did a final pass on a couple of your open PRs11:29
pedronisnow lunch11:29
mvopedronis: \o/ thank you11:35
mvopedronis: I check it out11:35
=== chihchun is now known as chihchun_afk
cachiomvo, hey, I'll be 5 minutes late for the standup11:50
mvocachio: no problem11:50
cachiomvo, tx11:50
niemeyerHellos11:50
mvopstolowski: woah, 4303 looks like you had a lot of work with that one11:50
niemeyerGood mondays11:50
mvogood morning niemeyer, happy monday!11:51
pstolowskimvo, it was a pleasure11:51
pstolowskimvo, just kidding ;)11:51
mvopstolowski: rotfl11:51
mvopstolowski: it looks impressive in any case :)11:52
pstolowskihey niemeyer! any thoughts on the suggestion from mborzecki here in the comments: https://github.com/snapcore/snapd/pull/4301 ?11:56
mupPR #4301: interfaces: small helpers <Created by stolowski> <https://github.com/snapcore/snapd/pull/4301>11:56
zyga-soluspstolowski: OMG 4303 is monumental12:00
pstolowskizyga-solus, it would be 2x more if I didn't artificially split it (with the hack mentiond in the desc)12:01
pstolowskiyeah, these kind of changes are pain..12:01
niemeyerpstolowski: Looking12:02
pstolowskiniemeyer, zyga-solus was saying we don't want to use reflection in the code?12:03
niemeyerpstolowski, mborzecki: That's quite nice12:04
niemeyerpstolowski: I don't see why.. we're using reflection like this all the time because we use json12:04
pstolowskigood12:04
niemeyerjdstrand: ping12:36
pedronisniemeyer: hi, could you look at #4281  it looks sane to me, but I wasn't there when the details of it where discussed12:37
mupPR #4281: snapstate: support for pre-refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/4281>12:37
niemeyerpedronis: On it12:38
mupPR snapd#4302 closed: timeutil, overlod/snapstate: cleanup remaining pieces of timeutil weekday support <Created by bboozzoo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4302>12:40
niemeyerpedronis, pstolowski: Sent some questions about the details there12:46
zyga-solusmborzecki: trivial conflict on 428512:50
niemeyerzyga-solus: Coming?13:02
sergiusenszyga-solus remind me again, when using a non ubuntu kernel on ubuntu, but having confinement enabled, how do I tell snap-confine to behave? http://pastebin.ubuntu.com/26057979/13:02
zyga-solusniemeyer: yes, just 2fa woes13:02
zyga-solussergiusens: I think this is fixed in master now13:04
sergiusensmpt hey there, mind reviewing the wording on this PR? https://github.com/snapcore/snapcraft/pull/1634/files13:06
mupPR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634>13:06
mptsure13:06
sergiusensmpt thanks!13:06
sergiusensmpt if you think of a better "command name" don't hesitate to bring it up :-)13:07
Facumpt, sergiusens, thanks13:07
sergiusenszyga-solus to use master, do I just bring it in? As in, is snap-confine going to be executed host side or from "core/base" if I build a package from master and install?13:08
zyga-solussergiusens: you just use edge, hopefully that should be enough13:09
sergiusenszyga-solus ah, that's risky business :-P13:09
sergiusenszyga-solus might it be in beta or candidate?13:09
* sergiusens refreshes to edge13:10
sergiusensI hope that going to candidate eventually (to a past revision) won't ruin up all the apparmor or seccomp profiles created13:11
* lundmar looks around pondering how to speed up his alias request for lxi-tools :)13:11
sergiusenszyga-solus do I need to reboot?13:18
sergiusensif the answer is no, the fix does not seem to be in master13:18
lundmarHmm, I've granted build.snapcraft.io access to the repositories in one of my organizations. However, now I need to grant access to other repositories in a different organization but I can't find or reopen the interface for doing that at build.snapcraft.io ?13:18
lundmarOh never mind, I've found it.13:19
mptsergiusens, I think it would take a long time for me to learn enough to have a useful opinion on that PR, so I’ll stay out of it. Sorry. :-)13:20
sergiusensmpt how about if I just ask you to look at this https://forum.snapcraft.io/t/mechanisms-for-converging-store-and-snap-metadata/2200 ?13:22
sergiusensmpt  oh, you already have13:22
sergiusensmpt Facu instead of `snapcraft update-metadata` what about `snapcraft push-metadata` which has a more consistent feel to the default `push` or do we want to keep the word "update" in there?13:24
mptsergiusens, that seems reasonable to me13:25
lundmarno more update, upload, just push please :)13:25
Facusergiusens, not following you... currenct command is `snapcraft push <snap> --only-metadata`13:40
Facusergiusens, no "update" at all13:40
sergiusensmpt Facu sorry my head works in mysterious ways... I don't know where I got my references from; but starting from scratch, does `snapcraft push-metadata` feel more straightforward and understandable than `snapcraft push --only-metadata`?13:43
mptsergiusens, to me, yes13:43
sergiusensthanks for the feedback mpt13:45
Facusergiusens, `snapcraft push-metadata <snap> [--force]` ?13:47
sergiusensyes13:47
sergiusensmvo zyga-solus help, I cannot come back to stable after going to edge it seems http://pastebin.ubuntu.com/26058202/13:50
sergiusensit is stuck there13:50
mvosergiusens: yes, its a known issue, the fix is in an open PR. in the meantime, please run `snap changes` and check the change in "do" start and `snap abort <nr>` it13:50
mvosergiusens: that should unbreak you13:51
mvosergiusens: this https://github.com/snapcore/snapd/pull/4298 is the fix13:51
mupPR #4298: many: remove configure-snapd task again and handle internally <Created by mvo5> <https://github.com/snapcore/snapd/pull/4298>13:51
mvosergiusens: once it lands things are good again13:51
sergiusensmvo ok, thanks13:51
sergiusensso I get to stay on edge until this gets there :-P13:52
mvosergiusens: :) yes13:52
mvosergiusens: hopefully this lands today13:52
sergiusensif I become unresponsive everyone should know why ;-)13:52
sergiusensgreat13:52
mvosergiusens: heh13:53
sergiusensmvo I kid thought, I have my wifes computer close by ;-)13:53
sergiusenszyga-solus bottom line, edge does not have the fix which makes me boot with `apparmor=0` and I am totally confused as why that would be more secure :-/13:54
zyga-solussergiusens: to the best of my knowledge, yes14:02
zyga-solussergiusens: what are you getting?14:02
* zyga-solus lunches14:05
sergiusenszyga-solus same message as before and snap-confine going dead14:34
zyga-solussergiusens: hmm, "not confined but should be"?14:41
lundmarQuestion, why is it that some use "description: |" and some simply "description:" ? It seems to make no difference.14:41
sergiusenslundmar multiline is easier with `description: |`14:42
mupPR snapd#4304 opened: debian: demote gnupg from dependencies to recommends <Created by mvo5> <https://github.com/snapcore/snapd/pull/4304>14:42
sergiusense.g.; for writing paragraphs14:42
lundmarsergiusens: But even without | paragraphs seems to work just fine14:43
sergiusenszyga-solus yes14:43
zyga-solussergiusens: what does `aa-enabled` say?14:43
sergiusenslundmar I'd have to check the yaml spec to get a better answer to this one14:43
lundmarsergiusens: fyi - this works fine: https://github.com/lxi/lxi-tools.snapcraft/blob/master/snap/snapcraft.yaml14:44
sergiusenszyga-solus exactly what I shared on the first pastebin; I am now running disabled to get work done14:44
zyga-solushmm hmm14:44
zyga-solus(that's not good)14:44
sergiusenszyga-solus exactly, I am about to "distro patch" that check out of the code base to be able to enable apparmor again14:45
zyga-solussergiusens: how do I run a mailine kernel like you do?14:45
lundmarsergiusens: If it is perfectly fine to not use | then I think it should not be encouraged to use it - it simply becomes noise/clutter.14:46
sergiusenslundmar can you check the spec and make sure that is the case? It might as well be, but we initially had problems when we didn't14:47
lundmarperhaps it has been improved since14:47
sergiusenszyga-solus you can use the one the kernel team provides or use https://github.com/jakeday/linux-surface which is what I have14:47
sergiusenszyga-solus https://wiki.ubuntu.com/Kernel/MainlineBuilds14:49
zyga-solussergiusens: let me try those and get back to you14:49
lundmarthe only place I can find a doc reference to | is https://docs.snapcraft.io/build-snaps/your-first-snap14:51
lundmarHowever, it seems to work just fine without so I guess recent snapd supports not using the odd |14:52
lundmar*snapcraft14:52
=== cachio is now known as cachio_LUNCH
=== cachio_LUNCH is now known as cachio_lunch
sergiusenskyrofa are you up and about? How was the weekend?15:21
mupPR snapd#4305 opened: snapd.dirs: add var/lib/snapd/lib/gl32 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4305>15:27
kyrofasergiusens, I am, good morning15:28
sergiusenskyrofa good afternoon then :-P15:28
kyrofaYeah, good weekend. The rest of the hardware for my series arrived, so I took some of my intro footage before I needed to poke holes in the box15:29
kyrofaYou?15:30
pstolowskiniemeyer, the question you raised on 4281 wrt running pre-refresh hook if snap is not active is an interesting problem. the short answer is no, I should prevent this, because it won't work. but the question is what's the right thing to do. the fact that we will not execute this hook on refresh just because the user has disabled the snap seems a but questionable15:34
pedronispstolowski: let me check something15:39
pedronispstolowski: we don't refresh inactive snaps atm (we said it the past that we should reconsider that decision, but that's the current status)15:41
pstolowskipedronis, hmm how is it the case? we do have logic around isActive in doInstall (update)? or do we cut this off somewhere else?15:42
pedronispstolowski: look at Update and refreshCandidates15:42
pstolowskipedronis, aha!15:43
pedronis// FIXME: snaps that are not active are skipped for now15:43
pedronis//        until we know what we want to do15:43
pedronisif !snapst.Active {15:43
pstolowskipedronis, thanks!15:43
pstolowskithat answers it15:43
niemeyerpstolowski: Yeah, I don't quite understand the question, probably based on pedronis' feedback15:45
niemeyerpstolowski: Inactive snaps are equivalent to not being there at all in many senses15:45
niemeyerpstolowski: We definitely don't want logic running on them15:45
pedronisyea, I think the current decision is probably right in retrospect, and will be even saner with epoch support15:46
pstolowskiniemeyer, yes. but the bottom line (as far as I understand this) is the logic wouldn't be fired anyway in this case. i'm adding isActive check anyway15:47
niemeyerpstolowski: I don't understand the point.. the check there which was omitted is meant to check for exactly this, right?15:48
pedronispstolowski: notice that that check about Active in doInstall is probably just a historical spelling of IsInstalled I think15:50
pedronisit would also support refreshing an inactive snap (which we don't do though)15:51
pstolowskiokay, not doing anything about that then. the problem of running after stop-services is fixed now. the post-refresh hook already runs before start-snap-services, so nothing to fix there15:55
pstolowskiniemeyer, ^15:55
niemeyerpstolowski: Sounds good, let me know when it's ready for another round please15:56
sergiusenskyrofa did you catch my comment on the `init` PR?15:58
pstolowskiniemeyer, it is now16:00
kyrofasergiusens, init? Are you talking about the tuple one?16:00
=== cachio_lunch is now known as cachio}
=== cachio} is now known as cachio
sergiusenskyrofa yeah16:01
kyrofasergiusens, I did, and you're right, considering that's on our roadmap anyway implementing the SNAPCRAFT_ARCH_TRIPLET seems the proper fix. However, do we want to add gcc as a required build-package for everything?16:04
kyrofaWe could go the other way and use the map we already have16:05
kyrofasergiusens, note that I'm working on the macaroon at the moment. Would you like me to give this priority?16:07
sergiusenskyrofa yeah, use the map; macaroon stuff can go first too16:08
kyrofaYou got it16:08
lundmarI assume it is still the correct procedure to request aliases in the snapcraft forum or has procedure changed? (alias vs declarations?)16:16
kyrofalundmar, indeed, that's correct16:19
lundmarkyrofa: ok, so I just have to be patient :)16:24
lundmarfyi - I've put an alias request in the "store" forum channel.16:24
kyrofalundmar, can you provide a link here?16:32
kyrofalundmar, oh, found it16:32
lundmarok thanks16:32
lundmarthe lxi-tools one16:33
kyrofalundmar, note that there's a waiting period for comments (a week I think)16:35
kyrofaThere was a document about the process, but I think the forum swallowed it16:35
kyrofaA topic, rather16:35
lundmaroh. Wau thats quite some time :/16:37
lundmarWouldn't it be easier for everyone if you guys only have to address and vote to solve alias conflicts instead of voting all alias requests?16:38
sergiusenskyrofa a final ack on snapcraft#1759 would be nice :-)16:43
mupPR snapcraft#1759: many: ensure classic confined binaries use the correct interpreter <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1759>16:43
kyrofaAh, the docs were updated, nice16:43
kyrofasergiusens, yep, excellent16:45
kyrofasergiusens, I suppose I need to make a forum proposal if I actually want to write a command to save the macaroon, huh?16:45
kyrofalundmar, yes, agreed, we just don't quite have the infrastructure for that in place just yet16:46
sergiusenskyrofa a forum post would be ideal, yes16:47
kyrofaOkay I've got this mostly done, that's the last step. Let me write it up16:48
mupIssue snapcraft#1662 closed: patchelf with ld-linux <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1662>16:48
mupPR snapcraft#1759 closed: many: ensure classic confined binaries use the correct interpreter <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1759>16:48
sergiusenskyrofa great16:50
sergiusenskyrofa, btw it is just me and you this week16:50
kyrofasergiusens, oh good to know16:50
kyrofaI knew elopio was out16:50
* sergiusens starts getting ready for physiotherapy 16:50
jdstrandzyga-solus: still slogging through holiday backlog. PR 4100 added to list16:56
mupPR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4100>16:56
jdstrandzyga-solus: err, it was always on the list. I mean it is on my list for this week, assuming it doesn't get preempted16:57
jdstrandzyga-solus: pr 4140 is also on the list. that requires some investigating from me17:01
mupPR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140>17:01
jdstrandniemeyer: hey, pong17:02
niemeyerjdstrand: Heya17:03
niemeyerjdstrand: Have you seen the follow ups on ikey's thread re. the base image?17:03
niemeyerErm17:03
niemeyerbase snap17:03
jdstrandniemeyer: I saw them in my inbox but put them to the side until I could review them more carefully. I'm about to go back to them (various pings/meetings/etc this morning)17:04
niemeyerjdstrand: Ack, just wanted to make sure it was back on your upcoming list, thanks!17:05
jdstrandyep17:05
jdstrandnp17:05
jdstrandniemeyer: and sorry I missed the hongout last week, was on holiday and missed the emails/etc17:07
niemeyerjdstrand: np, and sorry for pinging while you were on holiday, it was not intended to take you out of them :)17:07
lundmarkyrofa: I've put a forum post regarding the alias vote suggestion: https://forum.snapcraft.io/t/suggestion-only-vote-to-resolve-alias-conflicts/296617:07
niemeyerpstolowski, pedronis: Shouldn't the pre-refresh hook also be gated by isActive?17:13
pedronisniemeyer: I think we talked past each other,  yes to be correct if we allow refreshing inactive snaps, but we don't do that atm. we have a similar check already in doInstall, we probably need to decide one way or another at some point17:14
pedronisI think we want to keep things as they are (no refreshes for inactive snaps) and then probably checks in doInstall would need to be different17:15
pedronisbut I suppose for this PR the most consistent thing is to add an isActive guard17:15
pstolowskiindeed, i wanted it for clarity but afaiu it's not going to be effective atm, since refresh will not be performed17:15
niemeyerpstolowski, pedronis: The logic there just tastes wrong in either of those cases17:16
niemeyerWe *are* checking if the snap is active before performing certain things17:17
niemeyerSo we need to make up our minds: do we assume that never happens, and really fail upfront if that does happen, or we continue to be mindful of the fact it might not be active17:17
niemeyerWhat makes no sense to me unless I'm missing something, is to pretend it can happen, and code the logic incorrectly for that situation17:18
pedronisI think we should fail upfront (the more things can happen when refreshing a snap the less it makes sense to support for refreshing inactive ones)17:18
pedronisniemeyer: I think the current code is just a result of history, we never committed one way or another so far17:19
niemeyerpedronis: That's fine.. I just don't want to have logic in place that is clearly wrong and we do know it's wrong17:20
niemeyerpedronis: I would like to eventually support that use case, so one can install something without having it enabled right off17:20
niemeyerpedronis: But there's no pressure to do that now17:20
pedronisthat's a bit different though17:21
pedronisI mean the check I would add wouldn't involve that case directly17:21
niemeyerpedronis: Actually, it does sound a bit awkward to *not* support it17:22
pedronissnapst.IsInstalled && !snapst.Active => error17:22
niemeyerpedronis: Just considering the case: there's something wrong with the current version, we disable it so it stops creating havoc17:23
niemeyerpedronis: We want to enable it, but update it first17:23
niemeyerpedronis: That's exactly that situation, I think17:23
niemeyerpedronis: Unfortunately, that means the pre-hook could not run, which might be a real issue17:24
pedroniswe need custom logic17:24
pedronisconsider that pre-refresh could explode17:24
niemeyerpedronis: So +1 on simply forbidding for now17:24
niemeyerpstolowski: Are you with us?17:24
pstolowskiniemeyer, yes. so that's the kind of doubts I had with my original question way above, although phrased in a different way.17:25
pedronislet me check quickly if I'm off and lots of tests explode17:25
pedronisif we do that17:25
pedroniswhich probably means it needs to be its own PR17:25
niemeyerpstolowski: Sure, we're exploring and discussing..17:25
niemeyerpstolowski: and we reached an agreement.. do you understand it/agree?17:26
pstolowskiniemeyer, you want to support refresh on disabled snap, but not run the pre-refresh hook if snap is not active, is that it?17:29
pedronispstolowski: no,   for now we want to forbid it17:30
niemeyerpstolowski: No.. we want to forbid the situation upfront, and remove traces of that logic17:30
niemeyerpstolowski: The code in the PR is still bogus if the situation happens, and while we can fix it to make non-bogus, we don't currently do that, and we have no tests making sure that will continue to work17:31
niemeyeror even that it works at all17:31
niemeyerpstolowski: So we either fix it for real, or we stop pretending, basically17:32
pedronisI did the change locally here17:32
pedronistest seems still happy17:32
niemeyerThat's awesome, so let's just kill it for now17:32
niemeyerExplicitly, and with guards17:32
pedronispstolowski: I can give you a sketch diff in a sec17:34
pedronispstolowski: something like this I suppose:  http://pastebin.ubuntu.com/26059429/  (given that we already have guards a level up)17:35
pstolowskipedronis, I see17:38
brunosferHi guys, I'm struggling a bit here. I'm trying to compile a go file to further develop a snap, but go tools require the go compiler and the go compiler requires gcc for ARM (in my case) and in ubuntu snap core I can't find any gcc snap. How do you guys do this? Thanks17:39
cjwatsonThe existing go snap should include everything you need, shouldn't it?17:43
pedronispstolowski: there's some argument to produce a nice error even there, but that's the main change I think17:46
Facusergiusens, mpt, pushed the changes to PR with the paradigm change you requested today: https://github.com/snapcore/snapcraft/pull/163417:46
mupPR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634>17:46
Facuroadmr, matiasb ^17:46
matiasbgreat, thx17:47
niemeyerI need to step out for a while to run an errand.17:48
roadmrFacu: yay thanks17:55
roadmrhopefully sergiusens will have a moment to review that :)17:56
pstolowskipedronis, okay, added to my PR17:57
pstolowskithinking about test now, but i don't see how to provoke it (we cut that case off at higher level)17:58
pstolowskipedronis, ok, pushed a simple test, can you take a look?18:15
lundmarIs there a public online directory of all the snaps in the global store somewhere?18:32
pedronispstolowski: looks ok18:33
lundmarI mean, a browsable/searchable directory.18:34
lundmarThis is the only online snap searcher/browser I can find: https://uappexplorer.com/snaps18:40
kyrofalundmar, yeah that's it (it's unofficial)18:48
pstolowskieod, cu!19:00
zyga-solusre19:01
* zyga-solus finally doesn't have to look after kids, straps for an late-night coding session19:01
* ikey sends broken update to zyga-solus's machine19:05
ikey>_>19:05
ikey<_<19:05
zyga-solusikey: btw, did you hear that tubmleweed added "snapshots"19:09
zyga-solusso that you can update and keep a given snapshot19:09
zyga-solusand rollback19:09
ikeyoh cute19:09
ikeybtrfs ?19:09
zyga-solusI didn't read more, they mentioned "copying all the packages"19:09
ikey._.19:09
zyga-solusOMG HI_TEH19:10
ikeyoh btw i wrote that hashmap in the end :p19:10
zyga-solusikey: nice! :)19:10
zyga-solusikey: I'll show you some of my stuff once it brews to usability19:10
ikeylook forward to it :]19:11
ikeymy current (early) map https://github.com/ikeydoherty/libuf/blob/master/src/map.c19:11
ikeyneeds iter apis but it'll do the job for now19:11
sergiusensFacu roadmr matiasb approved with a minor comment if you don't mind addressing19:11
mupPR snapd#4305 closed: snapd.dirs: add var/lib/snapd/lib/gl32 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4305>19:16
zyga-solusjdstrand: can you please look at 4306, it's the #include vs include bug19:21
mupPR snapd#4306 opened: cmd/snap-confine: use #include instead of bare include <Created by zyga> <https://github.com/snapcore/snapd/pull/4306>19:22
mupPR snapd#4292 closed: snapstate: store userID in snapstate <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4292>19:25
ikeyjdstrand, ty for review!19:39
* ikey whacked the magical edge release thingy19:39
sergiusenskyrofa can you think of a better name than snapcraft#1755 ? the "save them to git part". Also, our first liners are getting too long to have a pleasant view after committing20:09
mupPR snapcraft#1755: tests: collect the autopkgtest results and save them in git  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1755>20:09
mupPR snapd#4306 closed: cmd/snap-confine: use #include instead of bare include <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4306>20:10
mupPR snapcraft#1742 closed: lxd: always remove tmp_dir after execution <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1742>20:16
jdstrandikey: thanks for the snap :)20:27
Facusergiusens, pushed the change20:36
sergiusensFacu thanks, as soon as that is green I will merge; thanks again!20:50
Facusergiusens, thank you20:52
sergiusenskyrofa mind reviewing/testing snapcraft#1762 ?20:54
mupPR snapcraft#1762: lxd: delete container only if parts is empty <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1762>20:54
kyrofaSure thing20:55
kyrofasergiusens, mind taking a look at my forum proposal?21:20
=== petevg_afk is now known as petevg
jdstrandroadmr: hi! can you sync r950 of the review tools?22:38
roadmrjdstrand: sure! thanks!22:40
jdstrandthank you :)22:40
roadmrjdstrand: if that addresses https://bugs.launchpad.net/snapstore/+bug/1733699 could you link the bug to the branch please?22:45
mupBug #1733699: invalid snaps that trigger 'runtime-errors' json output are not correctly processed by the store <Snap Store:In Progress by jdstrand> <https://launchpad.net/bugs/1733699>22:45
jdstrandroadmr: I already added a reference to that in the comments22:51
roadmrthanks :)22:51
jdstrandroadmr: it wasn't a branch-- I gave a link to the commit22:51
roadmroh that works well too22:51
jdstrandroadmr: https://bugs.launchpad.net/snapstore/+bug/1733699/comments/522:51
mupBug #1733699: invalid snaps that trigger 'runtime-errors' json output are not correctly processed by the store <Snap Store:In Progress by jdstrand> <https://launchpad.net/bugs/1733699>22:51
roadmroh I missed that22:52
* roadmr subs to the bug22:52
mupPR snapcraft#1634 closed: Push metadata to the Store <Created by facundobatista> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1634>23:41
mupPR snapcraft#1762 closed: lxd: delete container only if parts is empty <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1762>23:41
mupIssue snapcraft#1703 closed: Generate a list of error messages for design <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1703>23:47
lundmarhmm, looks like the avahi-daemon is not accessible for snaps on Ubuntu 17.1023:54
lundmaravahi clients fail to see avahi-daemon when using avahi-observe plug23:55

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