[05:05] <zyga> good morning
[05:10] <zyga> hey mborzecki
[05:11] <mborzecki> zyga: morning
[05:11] <zyga> I have some changes to make in https://github.com/snapcore/snapd/pull/7400
[05:11] <mup> PR #7400: cmd/snap-update-ns: don't propagate detaching changes <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
[05:11] <zyga> and then another round ad 2.41 suse package
[05:12] <mborzecki> zyga:  yeah, i saw jstrand's review
[05:52] <mborzecki> mvo: morning
[05:53] <mvo> mborzecki: goooood morning! how are you?
[05:54] <mborzecki> mvo: cold ;) +11C outside
[05:54] <mvo> mborzecki: yeah, same here. but much better than the ~40 before :)
[05:54] <mvo> (at least IMO)
[05:57] <zyga> good morning mvo
[05:58] <zyga> mborzecki: +11 wow
[05:59] <mvo> hey zyga
[05:59] <zyga> I'm debugging something that I changed that causes seeding to fail
[06:00] <zyga> it's pretty frustrating because there's no output
[06:00] <mvo> mborzecki: hm, I think we have +9 outside
[06:00] <zyga> I'll try to de-focus and advance some other stuff later, maybe around noon
[06:00] <mborzecki> mvo: wow, my preference is +20 all day round :P
[06:00] <zyga> mborzecki: check out spain ;)
[06:24] <zyga> mvo: do we have any stats on spread usage?
[06:25] <mvo> zyga: stats in what sense?
[06:25] <zyga> mvo: number of vm/hours used per account
[06:25] <zyga> something like that
[06:26] <zyga> just as trivia
[06:26] <zyga> I wonder what's our record
[06:26] <mvo> zyga: I'm sure gustavo has them, maybe sergio - I don't
[06:35] <mup> PR snapd#7158 closed: tests: part5 making tests work on ubuntu-core-18 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7158>
[06:37] <mborzecki> off to take my son to school and take some paperwork to my accountant
[06:37] <mborzecki> bbl
[06:51] <zyga> o/
[07:03] <pstolowski> morning
[07:03] <zyga> good morning pawel
[07:29] <mup> PR snapd#7418 closed: many: pass the rootdir and options to bootloader.Find <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7418>
[07:43] <zyga> wow, small success
[07:43]  * zyga tries the other test now
[07:47] <zyga> I'm on the way towards addressing the thing that made MS_SHARED bugfix be more complex in tests
[07:47] <zyga> caused by particular core16 behavior
[07:48] <mborzecki> re
[07:48] <zyga> mborzecki: hey
[07:49] <zyga> mborzecki: I added syslog to snap-confine
[07:49] <zyga> it helps when things faily mysteriously
[07:49] <zyga> added some draft code to unmap /writable from snaps POV
[07:50] <zyga> that could be the thing to cut the duplicated mount entries on core16 upsetting tests
[07:53] <mborzecki> zyga: syslog? as in syslog(3)?
[07:53] <zyga> yes
[07:53] <zyga> it shows up even if the invocation is otherwise hidden
[07:53] <zyga> made me realize a mistake earlier
[07:56] <mborzecki> zyga: got some cleanups in s-c unit tests
[07:58] <zyga> mborzecki: send them over and ping me
[08:18] <pedronis> mvo: morning, I looked at #6404 again
[08:18] <mup> PR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
[08:30] <mvo> pedronis: thanks, I check it out
[08:30] <mvo> pedronis: I updated the LK one, let me know if you want to go one step further
[08:31] <pedronis> mvo: I answered, yes, I think we should, but the change is smaller than what you thought I think
[08:31] <pedronis> mvo: we don't use InstallBootConfig at runtime
[08:31] <pedronis> I can look myself in a little bit
[08:32] <mvo> pedronis: also 7181 is green, I think we can merge it, yes?
[08:32] <pedronis> mvo: you mean 7381 ?
[08:33] <pedronis> yes I will merge it and make 7416 smaller
[08:34] <mup> PR snapd#7381 closed: seed,image,o/devicestate: extract seed loading to seed/seed16.go <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7381>
[08:34] <zyga> yay
[08:34] <zyga> I identified the core16 + core16 but that duplicated some entries that caused the MS_SLAVE test to fail originally
[08:35] <zyga> the fix is super easy and obviously so
[08:35] <zyga> coming up in 30-60 minutes after some more testing
[08:36] <mvo> pedronis: ok, I will leave the LK one for you then, thank you :) and yes, I did mean 7381
[08:36] <mvo> (fat fingers)
[08:36] <zyga> it's almost over, the whole thing is aligning :)
[08:37] <pedronis> mvo: done, now #7416 is it's proper size (still big, again because tests), also is not the whole thing as I said, more like ~1/3 maybe
[08:37] <mup> PR #7416: seed/seedwriter: start of Writer and internal policy16/tree16 <Created by pedronis> <https://github.com/snapcore/snapd/pull/7416>
[08:37] <pedronis> *its
[08:38] <mvo> pedronis: ok, I try to get to it soon
[08:46] <zyga> mborzecki: it passed :D
[08:46] <zyga> mborzecki: mwahaha, the bug is fixed
[08:47] <zyga> running full run across all systems on that test
[08:47] <zyga> I'll start polishing the patch for submission
[09:20] <pedronis> mvo: I pushed changed to the LK PR, please have a look when you can
[09:20] <pedronis> *changes
[09:20] <mup> PR snapd#7419 opened: cmd/snap-confine: add unit tests for sc_invocation, cleanup memory leaks in tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7419>
[09:21] <mborzecki> zyga: ^^
[09:21] <mborzecki> zyga: tried to use glib goodies in test_argc_argv() and fix memory leaks there, but gave up eventually as we modify the resulting argv in sc_nonfatal_parse_args()
[09:22] <pstolowski> pedronis: i'm cleaning up per-revision config stuff a bit and add some more tests
[09:23] <pedronis> pstolowski: ok, thx
[09:24] <mborzecki> ok, heading back home
[09:37] <mup> PR snapd#7420 opened: cmd/snap-confine: fix /snap duplication in legacy mode <Created by zyga> <https://github.com/snapcore/snapd/pull/7420>
[10:04] <pstolowski> pedronis: i thought i found a bug in that we only restore revision config on revert but not on refresh; but we explicitely test this behavior in config-revisions spread test. i'm not sure why we wanted that
[10:12] <pedronis> pstolowski: you mean a refresh to old revision?
[10:13] <pedronis> it makes sense to me though that we don't reapply old config in that case
[10:13] <pstolowski> pedronis: yep, snap refresh --revision=.. foo
[10:14] <pedronis> pstolowski: we don't go find the old data either I think
[10:14] <pedronis> revert is really the only op that says please get me back in time
[10:14] <pstolowski> pedronis: ah i see what you mean
[10:15] <pstolowski> thanks, all clear
[10:15] <pstolowski> good i had a spread test; i've added explicit unit test now
[10:17] <mborzecki> re
[10:28] <mborzecki> zyga:  updated #7419
[10:28] <mup> PR #7419: cmd/snap-confine: add unit tests for sc_invocation, cleanup memory leaks in tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7419>
[10:31] <zyga> mborzecki: thank you
[10:33] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7420
[10:33] <mup> PR #7420: cmd/snap-confine: fix /snap duplication in legacy mode <Created by zyga> <https://github.com/snapcore/snapd/pull/7420>
[10:40] <zyga> mborzecki: +1, can you please push a change to include it in the new format
[10:40] <zyga> and reformat
[10:40] <zyga> it will have clang formatting (the -test.c file) so it will be a little bit nicer
[10:40] <mborzecki> zyga: in the same PR?
[10:40] <zyga> yeah, the -test file is new
[10:41] <mborzecki> ok
[10:42] <mborzecki> hmm we should be putting emacs formatting spec in *.[ch] files like systemd does
[10:43] <mborzecki> fwiw emacs and vim
[10:48] <zyga> mborzecki: +1
[10:49] <zyga> thoguh I'm not using emacs, not sure if that is picked up universally
[10:57] <zyga> mvo: I need to do an errand downtown today, I will bring my laptop with me but not sure if I will have conditions for the call
[10:57] <zyga> mvo: my update is that I'm zeroing on the re-submission of MS_SHARED bug fix
[10:57] <zyga> mvo: I identified two causes of the failure of the integration test in the original pull request
[10:57] <zyga> mvo: one is under review now
[10:58] <zyga> mvo: the other was sent yesterday and +1'd but -1'd by jamie (code ok, comment tweaks requested)
[10:58] <zyga> mvo: I'll address those and try to propose the fix for MS_SHARED later today if I can
[11:07] <mvo> thanks for the update zyga
[11:39] <Psil0Cybin> cans omeoenm help me get snap working on kali linux?
[11:40] <zyga> Psil0Cybin: hey, perhaps
[11:40] <zyga> we did this enough times to have some experience
[11:41] <mup> PR snapd#7421 opened: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
[11:41] <zyga> mborzecki: one more https://github.com/snapcore/snapd/pull/7421
[11:41] <mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
[11:41] <zyga> I made it a draft as it will be probably discussed longer and I want  to perform some more analysis
[11:47] <Psil0Cybin> zyga, tank you becasue i was having problems that my home directory is in /username and not in /home/username
[11:47] <Psil0Cybin> and it would not let me run any appliations installed etc
[11:47] <zyga> Psil0Cybin: that's a known limitation and it is not supported
[11:47] <Psil0Cybin> shojld i provide the erorr logs?
[11:48] <zyga> it's not related to the distribution
[11:48] <Psil0Cybin> so how do i go bout gtting snap.d packages
[11:48] <zyga> Psil0Cybin: no need, we know about this and there is no solution now
[11:48] <Psil0Cybin> installed
[11:48] <Psil0Cybin> dang
[11:48] <zyga> you must use the regular location
[11:48] <Psil0Cybin> so im completely out of luck
[11:48] <zyga> that's the only outcome
[11:48] <zyga> no, just put it in /home/username
[11:48] <zyga> it's not a big deal, is it?
[11:48] <Psil0Cybin> should not be i just installed kali and created a non root account as per guide
[11:49] <Psil0Cybin> so what would i do now?
[11:49] <zyga> Psil0Cybin: I don't know much about kali
[11:49] <zyga> I cannot help with that directly
[11:49] <zyga> so what's your actual username?
[11:49] <zyga> and user home directory on the system?
[12:10] <cmatsuoka> mvo: I see in the spike code that ubuntu-image is actually installing the recovery bootloader files, is it supposed to work that way in the final code, or prepare-image should do that?
[12:11] <zyga> jdstrand: good day
[12:11] <zyga> jdstrand: I have updated the comment and replied tyo your question on https://github.com/snapcore/snapd/pull/7400
[12:12] <mup> PR #7400: cmd/snap-update-ns: don't propagate detaching changes <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
[12:12] <zyga> jdstrand: I also opened two additional PRs as we discussed
[12:12] <zyga> jdstrand: only one is something I'd like you to review
[12:12] <zyga> jdstrand: it is https://github.com/snapcore/snapd/pull/7420
[12:12] <cmatsuoka> mvo: I'm playing with snap-image to generate an image, after patching prepare-image to generate recovery (mostly from the spike code)
[12:12] <mup> PR #7420: cmd/snap-confine: fix /snap duplication in legacy mode <Created by zyga> <https://github.com/snapcore/snapd/pull/7420>
[12:12] <zyga> jdstrand: the other one is something that I want to experiment more with, you can see it in https://github.com/snapcore/snapd/pull/7421 if you are curious
[12:12] <mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
[12:13] <zyga> as soon as 7400 and 7420 land I will propose a v2 of the MS_SHARED fix
[12:14] <zyga> mborzecki: if you can, please do a pass over  7420
[12:14] <cmatsuoka> mvo: (also checking snap-image details with mborzecki)
[12:14] <zyga> mvo: perhaps as well, it's something you should know about
[12:24] <mup> PR snapd#7422 opened: interfaces: allow reading mutter Xauthority file <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7422>
[12:35] <mup> PR snapd#7423 opened: overlord/snapstate: config revision code cleanup and extra tests <Created by stolowski> <https://github.com/snapcore/snapd/pull/7423>
[12:43] <pstolowski> zyga: https://bugs.launchpad.net/snapd/+bug/1828354 didn't have solution, right? or was it fixed elsewhere?
[12:43] <mup> Bug #1828354: mount event propagation on snapd-mounted tmpfs is incorrect <snapd:In Progress by zyga> <https://launchpad.net/bugs/1828354>
[12:48] <mup> PR snapd#7415 closed: tests: fix mountinfo-tool filtering when used with rewriting <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7415>
[12:52] <zyga> pstolowski: it has a solution but we were unable to land it, my update above (for mvo) was about that
[12:52] <zyga> pstolowski: this is the MS_SHARED bug
[12:52] <zyga> pstolowski: it's close to being fixed now
[12:52] <zyga> pstolowski: I need to land two prerequisites and I can reopen the fix
[12:54] <pstolowski> zyga: ok, thanks
[12:55] <pstolowski> zyga: i'm keeping the bug 'in progress' then
[13:28] <tomwardill> hello! store team here, we've got some slowness issues that are causing timeouts, etc. Info will be here: https://status.snapcraft.io/
[13:28] <zyga> thank you for sharing tomwardill
[13:32] <zyga> thank you jdstrand!!!
[13:35] <jdstrand> np
[13:36] <zyga> I'll adjust the git commit message and the comment before landing
[13:40] <zyga> jdstrand: adjusted and squashed for simplicity
[13:50] <jdstrand> mvo, cachio: thanks for 7288, 7346 and 7350 (system-usernames cleanups)! sorry they were needed
[13:50] <cachio> jdstrand, looking
[13:50] <mvo> jdstrand: no worries, the world is complicated
[13:50] <cmatsuoka> mvo: I thought you would stay a bit to discuss snap-image details?
[13:50] <mvo> jdstrand: thank you for making the system-user happen, 2.41 will make a few teams quite happy
[13:50] <mvo> cmatsuoka: yes
[13:50] <mvo> cmatsuoka: sorry, brain
[13:51] <jdstrand> mvo: 7346 was a particularly nice one
[13:51] <jdstrand> (validate before create)
[13:51] <mvo> cmatsuoka: I'm back again
[13:51] <jdstrand> mvo, cachio: hope it didn't cause too much trouble
[13:52] <jdstrand> cachio: no need to look them up. just you two working through testsuite issues after the feature landed
[13:52] <cachio> jdstrand, everything merged :) snap_daemon did not you
[13:52] <cachio> troubles
[14:18] <pstolowski> jdstrand: thanks for looking at my apparmor backend PR!
[14:20] <pstolowski> (k
[14:20] <pstolowski> ijohnson and pedronis  - thank you too!
[14:21] <pstolowski> i think with the general approval for the direction of this PR i'll work on new tests & the feedback
[14:35] <ackk> hi, out of curiosity, why is that any user can call "snapctl set-health"?
[14:48] <ijohnson> pstolowski: you're welcome :-)
[14:48] <pstolowski> ackk: i think that's because any app can set health status of own snap (and doesn't need euid 0 to do that). note you cannot do anything useful by running snapctl set-health manually because of missing context
[14:49] <ackk> pstolowski, you mean it would only show up in snap info?
[14:56] <pstolowski> ackk: it would show in snap info, yes (not sure why "only"?) - see https://forum.snapcraft.io/t/health-checks/10605
[14:58] <ackk> pstolowski, I see thanks
[14:58] <ackk> pstolowski, fwiw I meant, if you run it manually from a snap run --shell, you can still set it so that it shows in the status
[15:00] <mup> PR snapd#7270 closed: overlord/snapstate: save disabled snap svcs on unlink snap tasks <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7270>
[15:00] <ackk> pstolowski, what would be the context you're referring to?
[15:02] <pstolowski> ackk: yes. but that's interesting case, i didn't think about it
[15:03] <ackk> pstolowski, I was wondering a malicious user could just snap set-health error "everything is broken"
[15:03] <pstolowski> ackk: yes i see what you mean
[15:10]  * cachio lunch
[15:14] <zyga> re
[15:14]  * zyga reads backlog
[15:14] <zyga> ackk: snap run --shell gives you a cookie
[15:15] <roadmr> 🍪
[15:15] <zyga> ackk: snap run --shell
[15:15] <zyga> echo $SNAP_COOKIE
[15:15] <zyga> AFAIR
[15:16] <ackk> zyga, indeed
[15:17] <mup> PR snapd#7420 closed: cmd/snap-confine: fix /snap duplication in legacy mode <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7420>
[15:23] <mup> PR snapd#7422 closed: interfaces: allow reading mutter Xauthority file <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7422>
[15:25] <zyga> master moved by 64 revisions
[15:25] <zyga> man, today is busy
[15:30] <mvo> zyga: oh yes!
[15:31] <jdstrand> pstolowski: you're welcome!
[15:39] <mvo> code review for https://github.com/snapcore/spread/pull/69 would be great, probably needs some tweaks but a early test would be amazing
[15:40] <mup> PR spread#69: Manage pagination retrieving images from google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/69>
[15:43] <pedronis> ijohnson: are you are aware of this bit of code: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/backend/link.go#L152
[15:43] <pedronis> ? (I was almost forgetting myself)
[15:43] <pedronis> it's called by link-snap
[16:33] <mup> PR snapcraft#2703 opened: build provider: allow configuration of primary apt mirror <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2703>
[17:25] <pedronis> ijohnson: I left this comment: https://github.com/snapcore/snapd/pull/7270#issuecomment-528941176
[17:25] <mup> PR #7270: overlord/snapstate: save disabled snap svcs on unlink snap tasks <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7270>
[18:09] <mup> PR snapd#6697 closed: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
[18:17] <ardaguclu_> run_checks first executes gofmt and in my local machine each time it returns "formatting wrong in following lines;..."
[18:18] <ardaguclu_> Am I doing something wrong, because each time I manually run gofmt to complete run_checks and see results
[18:20] <ardaguclu_> I am running it 1.13, is it something because of that?
[18:32] <zyga> ardaguclu_: it's a known flaw
[18:33] <zyga> ardaguclu_: ignore it
[18:33] <zyga> ardaguclu_: you can go test ./...
[18:33] <zyga> and that's just as good
[18:33] <zyga> ardaguclu_: there's a few things it doesn't do but you can check the script to see what's that
[18:33] <mup> PR snapcraft#2703 closed: build provider: allow configuration of primary apt mirror <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2703>
[18:33] <zyga> ardaguclu_: go fmt has changed behavior across versions
[18:37] <ardaguclu_> zyga: thanks, I am going to check it.
[18:39] <mup> PR snapcraft#2704 opened: extensions: create the gnome-platform directory <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2704>
[18:39] <mup> PR snapcraft#2705 opened: extensions: rename extension classes to known names <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2705>
[18:43] <ijohnson> thanks pedronis, sorry was afk for a bit, that makes sense
[18:54] <mup> PR snapcraft#2706 opened: extensions: improve docsting (used in the cli) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2706>
[18:54] <mup> PR snapd#7400 closed: cmd/snap-update-ns: don't propagate detaching changes <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7400>
[19:04] <mup> PR snapd#7424 opened: fixme: move snapfrompid into osutils <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7424>
[19:10] <mup> PR snapd#7425 opened: channel: introduce Resolve and ResolveLocked <Created by pedronis> <https://github.com/snapcore/snapd/pull/7425>
[19:15]  * ijohnson reboots
[19:40] <jdstrand> ijohnson: I went to update trello for the "rainy day list" to add 6697 and recalled from my notes something: https://github.com/snapcore/snapd/pull/6697#issuecomment-528987808
[19:40] <mup> PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
[19:41] <ijohnson> thanks jdstrand I'll take a look
[20:59]  * cachio EOW
[22:01] <mup> PR snapd#7426 opened: cmd/snap-update-ns: clarify sharing comment <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7426>
[22:20]  * zyga goes to sleep


[01:25] <mup> PR snapd#5000 closed: errtracker: make TestJournalErrorSilentError work on gccgo <Critical> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5000>
[05:13] <zyga> Caelum: yeah, I'll ask for that now
[05:15] <mborzecki> morning
[05:16] <Caelum> zyga: ideally they'd have a nightly cron job or something
[05:16] <zyga> I just asked, not sure how it is set up
[05:16] <zyga> And we have another point release of snapd
[05:16] <Caelum> nice
[05:17] <zyga> I will prepare the build
[05:17] <zyga> And maybe, just maybe, work on features again
[05:17] <zyga> This week was tough
[05:18] <zyga> Useful, fantastic bug fixes, but tough
[06:21] <zyga> I have updated https://github.com/snapcore/snapd/releases/tag/2.32.3
[06:22] <zyga> Caelum: do you want to update the package to 2.32.3?
[07:14] <kalikiana> good morning
[07:22] <Caelum> zyga: sure I'll give it a go
[07:22] <zyga> thank you!
[07:24] <mup> PR snapd#4998 closed: release: 2.32.3 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4998>
[07:27] <pstolowski> mornings
[07:30] <zyga> hey pawel
[07:30] <Caelum> I figured out how to make my laptop not shutoff randomly so that should help
[07:36] <mborzecki> zyga: i left one comment in #4996
[07:36] <mup> PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
[07:36] <zyga> thanks
[07:36] <mborzecki> otherwise looks sane to me
[07:40] <zyga> fixed
[07:40] <zyga> the formatting
[07:40] <zyga> is the error really a problem?
[07:41] <mborzecki> zyga: it is in if/then/else block, the thing is if Get() fails, the err will be swallowed up, don't know if that's intended (maybe it is?)
[07:43] <zyga> which err is swallowed?
[07:43] <zyga> the one from Get or the one from setup affected tasks
[07:43] <mborzecki> zyga: one in line 206
[07:43] <zyga> the Get one is deliberate
[07:43] <zyga> yes
[07:43] <mborzecki> aah ok then
[07:43] <zyga> we don't want to err n that
[07:44] <zyga> ah
[07:44] <zyga> I misunderstood your comment then
[07:45] <mborzecki> all clear now
[07:45] <Caelum> zyga: do you know if we still even need the libtool patch?
[07:46] <zyga> I suspect it is needed
[07:46] <zyga> because there's some build flags that get injected in some odd way I don't understand
[07:46] <zyga> we will simplify the C build system soon
[07:46] <zyga> drop auto mess
[07:46] <zyga> and remove more (all) conditionals
[07:47] <Caelum> cool
[08:10] <zyga> popey: I reverted irccloud-desktop on my system as the latest revision is not working
[08:10] <zyga> revision 25 is ok
[08:10] <zyga> 41 doesn't start
[08:12] <popey> This is because you reverted snapd
[08:12] <popey> 2.31 breaks irccloud
[08:12] <popey> 2.32 fixes it.
[08:13] <popey> When will 2.32 come back to stable? (You could get core from beta to work around)
[08:17] <zyga> I see
[08:17] <zyga> I think next week
[08:17] <zyga> but I don't know for sure
[08:17] <zyga> we just released a new beta
[08:22] <tomwardill> i got core from beta due to the nvidia fixes, can confirm irccloud-desktop works
[08:23] <tomwardill> also the font issue I had in irccloud-desktop with twitter previews appears to have gone away, so thanks whoever fixed that! :)
[08:24] <popey> zyga: it broke other applications too, ones we were waiting for 2.32 for. Quite frustrating as I'm now being pinged everywhere that my applications are all broken
[08:25] <zyga> do you know which feature missing in 2.31 is key?
[08:25] <zyga> I hope we can update to 2.32.3
[08:26] <popey> It's the new stuff from jd strand to turn kernel errors into warnings.
[08:26] <popey> things that request process-control or try to chmod files break
[08:26] <popey> so games break, nodejs applications break. we waited for 2.32 before releasing them and making a splash, now we have to go and clear up that mess
[08:34] <Skuggen> I'm struggling a bit with updating an older snap (mysql). Paths for various library files and binaries are no longer loaded by default. Do I need to manually specify every path to LD_LIBRARY_PATH?
[08:34] <Skuggen> (snapcraft 2.39.2)
[08:36] <Chipaca> Skuggen: you're updating _the_ mysql snap?
[08:36] <Chipaca> Skuggen: or a snap that uses mysql?
[08:37] <pedronis> popey: 2.32 broke people doing snap install lxd though
[08:37] <Skuggen> Chipaca: The mysql snap
[08:37] <Chipaca> Skuggen: nice :-)
[08:37] <popey> Sure. I understand there was an issue. But we got a "surprise, we broke your apps to fix someone elses"
[08:37] <popey> I would like for there to be an incident report for this. Why was this not caught in QA?
[08:38] <pedronis> because basically    snap install lxd  only exercise core once its in stable
[08:38] <pedronis> we need to find a way to test that before
[08:38] <Skuggen> Chipaca: We were blocked by various missing features (privilege dropping, setting file ownership, etc.) so haven't looked at it for a while. I'm working on getting it updated so we can see what might still be missing for us to properly support it
[08:39] <Caelum> zyga: any new data files in .32 I should know about?
[08:39] <Chipaca> Skuggen: daemons still only run as root, that hasn't changed
[08:39] <Chipaca> fwiw
[08:39] <pedronis> popey: about  an IR, that's fair,  mvo should look into that
[08:40] <popey> Thanks
[08:44] <Skuggen> Chipaca: Yeah, that is an issue. We could have some limited support of it even so, though. But first I need to actually get it working again :)
[08:44] <Chipaca> :)
[08:44] <Chipaca> Skuggen: just the other day somebody was asking about using mysql in a snap, fwiw (via embedding), and looked at the mysql snap as an example
[08:45] <Chipaca> (and then looked away in haste)
[08:45] <Chipaca> Skuggen: https://forum.snapcraft.io/t/mysql-server/4877
[08:45] <Chipaca> just yesterday, in fact
[08:45] <zyga> Caelum: no, it's all the same
[08:46] <Caelum> awesome
[08:47] <Caelum> I need to redo it at some point to do a make install on data
[08:47] <Skuggen> Chipaca: Ah, can respond to that at least :)
[08:48] <Chipaca> Skuggen: do you know what version of snapcraft you used to build the snap before?
[08:49] <Skuggen> Hm, can you get that information from the snap itself?
[08:50] <Chipaca> Skuggen: I don't think you can
[08:50]  * Chipaca is not a snapcraft expert though
[08:50] <Chipaca> kalikiana: snapcraft doesn't record its version in the snap in any way, does it?
[08:51] <Skuggen> We used a xenial host, but don't know what version it had at the time
[08:52] <Skuggen> Submission date
[08:52] <Skuggen> 2017-01-27 08:18 - 1 year, 2 months ago
[08:52] <Skuggen> Oold
[08:52] <Skuggen> That's the one on the store
[08:54] <Chipaca> Skuggen: and the one in the 'latest' track is even older, 2016-12-19
[08:54] <Chipaca> that's latest/beta
[08:54] <zyga> Caelum: and I heard the install instructions are now live
[08:55] <Caelum> indeed they are, fantastic
[08:57] <Chipaca> popey: do you know if there's a guide or knowledge base or sth to update a snap that was created using snapcraft in the pleistocene?
[09:00] <Caelum> zyga: /usr/lib/udev/snappy-app-dev is gone, do we drop it or add it as a source
[09:00] <popey> Chipaca: wat
[09:00] <zyga> I think we want to copy snap-device-helper over as snappy-app-dev
[09:00] <zyga> Caelum: I think that's what we do for now, as there are still some transition complexities
[09:01] <kalikiana> Chipaca: Nope. Though you can use SNAPCRAFT_BUILD_INFO=1 to have it record manifest.yaml which contains Debian packages and snaps installed during the build.
[09:01] <kalikiana> And therefore indirectly Snapcraft's versions or revision
[09:01] <Caelum> zyga: got it
[09:01] <Chipaca> kalikiana: popey: Skuggen here is tasked with updating the mysql snap, and the newest revision is over a year old, and the snapcraft.yaml no longer works, and they don't know what snapcraft it was built with
[09:02] <Skuggen> Might be simplest to start over; It's not super complicated, but contains extra binaries and libraries that are accessed by shell scripts (to replicate some of the install logic of the regular deb packages so users don't need to manually initialize databases and such)
[09:02] <Chipaca> Skuggen: possibly, snapcraft's changed a lot, although i'm surprised a snap stopped building entirely (i thought it had tests for that)
[09:02] <Skuggen> e.g. I got it to build, but it has issues finding things like the libaio1.so we include
[09:02] <popey> Ah, understood.
[09:03] <kalikiana> Right. If the existing snap doesn't contain manifest.yaml I'm afraid that information won't be available.
[09:03] <Chipaca> Skuggen: so, that's one thing to do: for your future self, make sure SNAPCRAFT_BUILD_INFO=1 is set in the build environment
[09:03] <Chipaca> Skuggen: so you can answer 'what was this built with'
[09:04] <popey> Skuggen: I'm a touch busy today, but I think if you pasted the yaml in the forum we could mobilise some people to look
[09:05] <Chipaca> kalikiana: wait, can you drop SNAPCRAFT_BUILD_INFO into the snapcraft.yaml itself?
[09:05] <Skuggen> popey: Can do that, sure. Thanks
[09:06] <kalikiana> Chipaca: No, it's an envrionment variable.
[09:06] <Chipaca> kalikiana: and the environment: section of snapcraft.yaml is passed through to the snap, not acted on?
[09:06] <Chipaca> i thought it influenced the build
[09:08] <kalikiana> Chipaca: Right, those don't actually affect what Snapcraft will look at
[09:14] <Caelum> zyga: this test fails completely randomly on me, usually it passes but sometimes I get this: https://gist.github.com/rkitover/460ebe31c6bc3d7508ff584d505cdbce
[09:14] <zyga> hmmm
[09:14] <zyga> feels like a timing racy test
[09:16] <pedronis> those tests use settle
[09:16] <pedronis> so it's probably deeper
[09:16] <pedronis> a bit hard to tell from that error though
[09:22] <zyga> Caelum: has that happened before?
[09:22] <zyga> I suspect it's not new to this release
[09:38] <Chipaca> zyga: question about your lab
[09:38] <zyga> yes sir?
[09:38] <Chipaca> zyga: do you have an nfs mount in there
[09:38] <zyga> no, I'm afraid I don't
[09:38] <zyga> but it could be arranged
[09:38] <zyga> the pi3-1 machine has a HDD and we could arrange for NFS export there
[09:39] <zyga> do you want one on the ppc box or somewhere else? (client side)
[09:39] <Chipaca> zyga: I don't mind the arch for this
[09:40] <Chipaca> just need nfs
[09:40] <zyga> sure,
[09:40] <Chipaca> zyga: but if it's not set up i can probably do something at home instead
[09:40] <zyga> Chipaca: I just installed nfs server on pi3-1
[09:40] <zyga> can you ssh there?
[09:40] <Chipaca> i can
[09:40] <zyga> now it's just a matter of exporting something
[09:41] <Chipaca> zyga: I can't sudo there though
[09:41] <zyga> oh
[09:41] <zyga> let me fix that
[09:41] <Chipaca> zyga: because the password i have for the others doesn't work there
[09:41] <zyga> Chipaca: reset your password to your username and gave you sudo
[09:42] <zyga> feel free to export /home or something you want
[09:42] <zyga> I can stick another device if you want really networked NFS
[09:42] <zyga> I have a few more PIs and beagles
[09:43] <Chipaca> zyga: thanks
[09:45] <mborzecki> bash: line 3: cannot create temp file for here-document: No space left on device <--- 2018-04-06 11:42:41 Error preparing google:ubuntu-16.04-32:tests/main/
[09:45] <zyga> who used all the space? :)
[09:45] <Chipaca> hue hue hue
[09:45]  * Chipaca laughs in brazilian
[09:48] <pedronis> is resizing broken?
[09:48] <Caelum> zyga: yes it happened with .31 too
[09:49] <mup> PR snapd#4986 closed: snapstate: fix `snap refresh --amend` when the snap is not available in stable <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4986>
[09:49] <pedronis> zyga:  blargh
[09:49] <zyga> what's wrong?
[09:49] <pedronis> we don't want that fix
[09:49] <zyga> oh?!
[09:49] <pedronis> because is going to conflict with the new code
[09:49] <zyga> sorry, I can revert taht
[09:49] <pedronis> that just works
[09:50] <zyga> no worries, it's a revert away
[09:50] <pedronis> I'm going to merge 4900 today, once it's green
[09:50] <pedronis> it should have been marked blocked
[09:50] <pedronis> but lots of stuff going on yesterday
[09:51] <zyga> https://github.com/snapcore/snapd/pull/5001
[09:51] <mup> PR #5001: Revert "snapstate: fix `snap refresh --amend` when the snap is not av… <Created by zyga> <https://github.com/snapcore/snapd/pull/5001>
[09:52] <mup> PR snapd#5001 opened: Revert "snapstate: fix `snap refresh --amend` when the snap is not av… <Created by zyga> <https://github.com/snapcore/snapd/pull/5001>
[09:53] <zyga> pedronis: can you do a review of https://github.com/snapcore/snapd/pull/4996
[09:53] <mup> PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
[09:53] <zyga> and I guess we want to add gustavo to review list
[09:54] <pedronis> not sure I get to it today, more likely monday
[10:02] <Caelum> zyga: request sent
[10:02] <zyga> thanks, looking
[10:04] <zyga> i forgot the details but fair that symlink must be a real cop
[10:04] <zyga> copy
[10:05] <zyga> otherwise +1
[10:16] <Caelum> sure, one moment
[10:17] <Chipaca> mborzecki: setre[ug]id works \o/
[10:17] <mborzecki> Chipaca: yay :)
[10:17] <Chipaca> mborzecki: yes =)
[10:18] <mup> PR snapcraft#2053 opened: meta: implement pass-through of properties to snap.yaml <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2053>
[10:18] <mborzecki> Chipaca: nfs too?
[10:18] <Chipaca> mborzecki: that's what i was testing =)
[10:20] <mborzecki> Chipaca: great, so we can kill #4990 now
[10:20] <mup> PR #4990: many: implement a poor man's privileges drop, use for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4990>
[10:20] <Chipaca> mborzecki: with extreme prejudice
[10:20] <mborzecki> haha :)
[10:21] <kalikiana> greyback: I reckon you might wanna take a peek at snapcraft#2053 as you expressed your interest in the forum
[10:21] <mup> PR snapcraft#2053: meta: implement pass-through of properties to snap.yaml <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2053>
[10:21] <Chipaca> mborzecki: I'll tweak the code to retry a couple of times on EAGAIN before panic'ing
[10:21] <Chipaca> mborzecki: as we've learned that EAGAIN happens =)
[10:22] <Chipaca> mborzecki: also might as well move Sete[ug]id to sys
[10:22] <Chipaca> mborzecki: thank you again for reminding me about this =)
[10:24] <mup> PR snapd#4990 closed: many: implement a poor man's privileges drop, use for auth.json <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4990>
[10:24] <mup> PR snapd#4983 opened: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>
[10:25] <Caelum> zyga: fixed
[10:25] <zyga> thank you, looking
[10:26] <zyga> and sorry I didn't mention this
[10:26] <Caelum> you did say copy over
[10:26] <zyga> yes but I wasn't clear it is important :)
[10:26] <zyga> thank you for the work, it should be out soon :)
[10:27] <Caelum> nice
[10:29] <pstolowski> zyga: i've updated the tests of #4968 ; that got me thinking a bit about the old code of ubuntu-core -> core migration that's executed on startup; I remove stale connections *after* all the renaming in initialize. that's ok isn't it?
[10:29] <mup> PR #4968: RFC: ifacemgr: remove stale connections on startup <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>
[10:29] <zyga> interesting
[10:29]  * zyga thinks
[10:30] <pstolowski> zyga: question is if the core snap is alrady under new name, or is there a risk of considering the renamed connections "stale"
[10:31] <pstolowski> it's hard to reason about this based on unit tests
[10:32] <zyga> the transition is a task
[10:32] <zyga> it's not instant
[10:33] <pstolowski> zyga: right. but the renaming of conns happens on snapmgr init
[10:33] <pstolowski> zyga: so it kicks inafter re-exec, so we have new snap at hand correct?
[10:34] <zyga> yes
[10:34] <zyga> well, remember the is a version of this code that runs on ubuntu-core
[10:34] <zyga> that's not as up-to-date
[10:36] <zyga> I think this is ok
[10:36] <zyga> but more than happy we didn't do it earlier
[10:44] <zyga> pedronis: can you please merge https://github.com/snapcore/snapd/pull/5001
[10:44] <mup> PR #5001: Revert "snapstate: fix `snap refresh --amend` when the snap is not av… <Created by zyga> <https://github.com/snapcore/snapd/pull/5001>
[10:46] <popey> I have reverted back to core stable and now I get this when launching snaps:- failed to create prefix path: /tmp/snap.rootfs_M8USmi/var/lib/snapd/lib/vulkan/icd.d: Permission denied
[10:46] <zyga> popey: that's fixed in beta
[10:46] <zyga> stable is stable but buggy
[10:46] <popey> yeah, i am trying to use stable because that's what normal people use
[10:47] <zyga> I think this will be fixed once beta promotes
[10:47] <popey> we're lining up snaps to promote on the social media, but I can't tell what will and won't work for users
[10:47] <zyga> it's a bad week
[10:47] <zyga> we have nothing better
[10:47] <popey> ok
[10:47] <zyga> beta is most stable IMO
[10:47] <zyga> (today)
[10:59] <mup> PR snapd#5001 closed: Revert "snapstate: fix `snap refresh --amend` when the snap is not av… <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5001>
[10:59] <pedronis> zyga: done, thanks
[11:00] <zyga> thank you
[11:00] <pedronis> trying to get #4900 to green again and then will merge it
[11:00] <mup> PR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Blocked> <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>
[11:00] <pedronis> and prepare the backport, but the backport  is probably to merge once .3 is in stable
[11:00] <pedronis> and then we can do a .4 in beta
[11:00] <zyga> the backport will be for 2.32.4?
[11:00] <pedronis> yes
[11:01] <pedronis> thats' what I discussed with mvo
[11:01] <zyga> ack
[11:39] <zyga> are we doing standup at 14:00 or 15:00?
[11:39] <zyga> I need to leave in 40 minutes to go to school
[11:40] <mborzecki> 3pm i presume
[11:42] <mborzecki> heh, amazon linux 2 is 64bit only, they don't provide any *.i686 libs
[11:43] <mborzecki> this makes one of our unit tests to fail https://paste.ubuntu.com/p/JyqX9Wh9Rw/
[11:47] <pedronis> we should really add some sort of skip logic to that test
[11:47] <pedronis> it also fails if you don't have the right deps
[11:47] <pedronis> installed
[11:50] <Chipaca> it also fails if you try to run it on a banana
[11:50] <Chipaca> ¯\_(ツ)_/¯
[11:50]  * Chipaca is full of ¯\_(ツ)_/¯ today
[11:51] <pedronis> Chipaca: let put it this way, as written is not very friendly to porting to random other distro
[11:54] <Chipaca> pedronis: tbh i'm surprised multilib works at all
[11:54] <Chipaca> cross-distro i mean
[11:54] <Chipaca> but, yes, agreed
[11:54] <Chipaca> i'm being somewhat facetious
[11:56] <zyga> I need to go AFK
[11:56] <zyga> see you at the standup, from the phone
[11:57] <mup> Bug #1761253 changed: Installing a network-bind snap along with core fails results in incorrect permissions <Snappy:Fix Released> <https://launchpad.net/bugs/1761253>
[11:57] <zyga> Caelum: approved, it's out :)
[12:03] <mup> PR snapd#4900 closed: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4900>
[12:18] <Caelum> sweet!
[12:20]  * cachio afk
[12:22] <mup> PR snapd#5002 opened: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5002>
[12:38] <Chipaca> mborzecki: #4983 is green and happy as a bean
[12:38] <mup> PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>
[12:39]  * kalikiana lunch
[13:02] <pstolowski> Chipaca: standup?
[13:03] <Chipaca> pstolowski: yeah, was jiggering my camera
[13:04] <mup> PR snapd#5003 opened: cmd/snap-seccomp: graceful handling of non-multilib host <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5003>
[13:11] <eraserpencil> Hey guys! are snaps able to work with USB and serial devices well?
[13:12] <Chipaca> eraserpencil: yes :)
[13:12] <eraserpencil> thanks!
[13:12] <Chipaca> eraserpencil: only issue might be if it's a new flavour of serial, as they're whitelisted
[13:12] <Chipaca> ie if you start having /dev/ttyFunky0, it'll need a patch
[13:13] <Chipaca> (although that one in particular might not =) )
[13:13] <eraserpencil> nice
[13:14] <eraserpencil> like erm communicate with multiple USB ports and one serial connection whilst having web servers and processing algorithms?
[13:14] <eraserpencil> I'm looking at the ROS-Snap tutorial, not sure what the limits of snaps are
[13:23] <Chipaca> eraserpencil: probably a kyrofa question
[13:30] <pedronis> cachio: now I see, the issue is that secrets are encrypted per repository, you cannot reuse a snapd secret for snapd-cron
[13:31] <cachio> ahh
[13:31] <cachio> pedronis, that makes sense
[13:31] <pedronis> cachio: I'm not sure how gustavo created the key for snapd, but  we need to rencrypt it for snapd-cron, or create a new one and encrypt
[13:32] <pedronis> cachio: probably need to discuss with him
[13:32] <cachio> pedronis, yes, I'll wait until next week
[13:34] <zyga> pedronis, cachio: yes, I bumped into that as well
[13:34] <kalikiana> re
[13:34] <zyga> this prevents people from copy-pasting secrets around
[13:34] <zyga> but if you know the decrypted secret you can easily re-encrypt it and add it via travis
[13:35] <pedronis> yea, but we don't
[13:51] <eraserpencil> Chipaca: whats a kyrofa question
[13:52] <Chipaca> eraserpencil: 'multiple USB ports and one serial connection', in the context of ROS
[13:52] <Chipaca> eraserpencil: I see ROS, I defer to the kyrofa
[13:52] <Chipaca> :-)
[13:53] <mborzecki> off to pick up the kids
[13:59] <jdstrand> roadmr: hi! can you pull in r1018? (just a few more overrides)
[13:59] <roadmr> jdstrand: absolutely. Here I go!
[14:00] <jdstrand> roadmr: thanks! :)
[14:03] <zyga> jdstrand: hey
[14:08] <jdstrand> zyga: hi!
[14:09] <jdstrand> roadmr: fyi, snapcraft 2.40 is now in stable and -updates everwhere. this is what we were waiting on for the resquash tests. in the coming weeks I'm going to request an isolated pull to turn on enforcement
[14:10] <jdstrand> roadmr: we'll want to keep an eye on it though in case we want to back it out
[14:10] <roadmr> jdstrand: ok. How do we turn it on? set an env var?
[14:10] <jdstrand> roadmr: today, that is how. I'm going to flip the logic for that
[14:11] <jdstrand> and request a pull
[14:11] <roadmr> jdstrand: oh understood. Think we should put that behind a feature flag so we can have a panic switch in case it all goes awry?
[14:12] <jdstrand> roadmr: how do you envision implementing that? I figured that was what the env var would do
[14:15] <zyga> jdstrand: I'd like to deconflict and merge https://github.com/snapcore/snapd/pull/4868
[14:15] <mup> PR #4868: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868>
[14:15] <zyga> it's already reviewed just FYI
[14:15] <zyga> I picked up user mounts
[14:15] <zyga> expect useful stuff on ~Tuesday
[14:15] <jdstrand> zyga: well, it needs an additional comment
[14:16]  * zyga -> cooking
[14:16] <jdstrand> 4868
[14:16] <jdstrand> I owe the PR a response. I plan to do that today
[14:16] <zyga> aha
[14:16] <zyga> I will look for your response then
[14:16] <jdstrand> codewise it is fine. james and I disagreed on the phrasing of a comment
[14:17] <jdstrand> (a comment I suggested, so it wasn't added)
[14:17] <roadmr> jdstrand: yes but how do we set/unset the env var in the store? a feature switch is a thingy we can flip on/off in the django admin and that controls stuff in the code
[14:18] <roadmr> jdstrand: so something like if is_set('the_flag'): os.environ['RESQUASH_CHECK'] = "true"
[14:18] <roadmr> jdstrand: because otherwise, if we need to switch this on quickly, we'd need a redeploy or something
[14:18] <roadmr> s/on/off/
[14:18] <jdstrand> roadmr: ok, I wasn't sure where you wanted the feature
[14:18] <roadmr> jdstrand: well no matter, let me ponder and we'll implement this if needed
[14:19] <roadmr> jdstrand: I mean - it's fine that the tools themselves have a way to control this, but remember this lives on a production server where I have no direct access
[14:19] <jdstrand> roadmr: I think it sounds like a nice idea. the worst that can happen is things end up in manual review. but, that could be a big number so being able to stop the bleeding quickly would be good
[14:19] <roadmr> so I can't easily e.g. ssh in and set/unset that variable in /etc/environment
[14:19] <roadmr> jdstrand: ok so I'll look into doing that then
[14:20] <jdstrand> obviously tyhicks and I believe that things are all worked out, but, you never know :)
[14:22] <jdstrand> zyga: I was confused. the comment I owe is in pr 4957
[14:22] <mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
[14:23] <zyga> ahh
[14:23] <zyga> ok
[14:23]  * Chipaca hears rumours of cake and goes forth
[14:23] <jdstrand> also, the code in 4957 is also ok
[14:24] <jdstrand> I'll add my response to that so you can consider it too
[14:26] <jdstrand> zyga: what is the 'squash-merge' label?
[14:29] <Chipaca> jdstrand: PRs that are to be cherry-picked should be squashed before merging
[14:29] <Chipaca> jdstrand: so it's just the one cherry
[14:29] <jdstrand> Chipaca: does that remove all the comments/etc/etc that are in github?
[14:30] <Chipaca> jdstrand: not the comments on github, but it replaces all the commits with one (the default commit message is a summary of the commits it's squashing)
[14:30] <jdstrand> Chipaca: eg, for a commit that ends up squashed? it would be a shame if there was a ton of discussion on a particular point, then we resquash and it goes *poof*
[14:31] <jdstrand> I feel like this has happened in the past...
[14:31] <Chipaca> jdstrand: it only affects the git history, not the github discussion
[14:32] <jdstrand> interesting. since the git hub discussion is hidden based on certain commits
[14:32] <jdstrand> ok, well, if it is not supposed to remove anything, cool
[14:33] <Chipaca> jdstrand: do you have an example of a hidden discussion?
[14:35] <Chipaca> (that is, i'll admit, a bit like asking "can you show me what was stolen")
[14:36] <zyga> jdstrand: it's not really hiding it
[14:41] <pedronis> it's not something that happens to the PR, it happens on master
[14:42] <zyga> jdstrand: I merged master into 4868
[14:44] <zyga> jdstrand: if you want to make some comment changes please go ahead
[15:04]  * zyga is happy that latest core build is really just new snapd
[15:07] <cwayne> Me too :)
[15:16] <Chipaca> zyga: note #4999 is now green
[15:16] <mup> PR #4999: advisor: use json for package database <Created by mvo5> <https://github.com/snapcore/snapd/pull/4999>
[15:18] <zyga> thanks, looking
[15:47]  * Chipaca off for a while
[15:47] <Chipaca> have a good weekend all, if i don't see you before your eow
[15:48] <jdstrand> popey: btw, that request for a review tools sync has the emoj override
[15:48] <jdstrand> ^
[15:50] <popey> thanks!
[15:50] <popey> cjwatson: https://launchpadlibrarian.net/363464768/buildlog_snap_ubuntu_xenial_armhf_b69a088aa70edd446e36c2072b30e222-xenial_BUILDING.txt.gz
[15:51] <popey> something odd going on with this build - it's looping over a couple of files
[15:51] <popey> (giant log file, note)
[15:58] <popey> Wondered if this was something broken at the launchpad end as the yaml seems fine to me.
[15:58] <cjwatson> popey: is there any particular reason to believe it's a problem with LP rather than snapcraft?
[15:58] <popey> fair point, I'd just never seen that happen before.
[15:58] <cjwatson> popey: it would be pretty unusual for that to be caused by LP.
[15:58] <popey> Hmph. Ok. will dig more.
[15:59] <cjwatson> node-pre-gyp ERR! Tried to download(404): https://github.com/kelektiv/node.bcrypt.js/releases/download/v1.0.3/bcrypt_lib-v1.0.3-node-v57-linux-arm.tar.gz
[15:59] <cjwatson> node-pre-gyp ERR! Pre-built binaries not found for<EMAIL_ADDRESS>and<EMAIL_ADDRESS>(node-v57 ABI) (falling back to source compile with node-gyp)
[15:59] <cjwatson> so it's probably just failing to pass proxy parameters to some bit of the build.
[16:00] <popey> ah that url is 404
[16:00] <cjwatson> (unless it's a real 404, which it could be.  but there's an "undefined" error earlier.)
[16:00] <cjwatson> and then it loses its mind for many thousands of lines.
[16:01] <popey> ahh that project has no armhf builds.
[16:01] <popey> sorry for the noise.
[16:23] <mup> Issue snapcraft#1886 closed: Support for yarn --extra-args <bug> <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1886>
[16:23]  * zyga -> shopping, ttyl
[16:50] <mup> PR snapcraft#2054 opened: tests: extract sources suite from general suite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2054>
[16:56] <popey> jdstrand: will you have time today to sort the aliases for ruby please?
[16:56] <mup> PR snapcraft#2055 opened: python: bring back support for older versions of pip <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2055>
[17:07]  * kalikiana wrapping up for the week
[17:22] <jdstrand> popey: I can, sure. 7 days haven't passed...
[18:39] <mup> PR snapd#5004 opened: daemon,overlord/hookstate: stop/wait for running hooks before closing the snapctl socket <Created by pedronis> <https://github.com/snapcore/snapd/pull/5004>
[18:41] <mup> PR snapd#5005 opened: interfaces/hostname-control: allow setting the hostname via syscall and systemd <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5005>
[19:08] <mup> PR snapd#5006 opened: interfaces: misc updates for default, firewall-control, fuse-support and process-control <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5006>
[19:15] <mup> PR snapd#5007 opened: interfaces/desktop-legacy: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5007>
[19:17] <mup> PR snapd#5007 closed: interfaces/desktop-legacy: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/5007>
[19:24] <mup> PR snapd#5008 opened: interfaces: misc updates for default, firewall-control, fuse-support and process-control - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5008>
[19:57] <mup> PR snapcraft#2054 closed: tests: extract sources suite from general suite <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2054>
[20:21] <mup> PR snapcraft#2056 opened: Fix formatting of some store errors <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/2056>
[23:58] <mup> Issue snapcraft#1673 closed: Add pre-stage/stage/post-stage <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1673>
[23:58] <mup> PR snapcraft#2049 closed: many: add override-stage scriptlet <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2049>


[20:27] <AcePreshaw> heloe
[20:28] <AcePreshaw> cna i have a locoloco
[20:28] <max_> Hello everyone I'm trying to get my hands on a copy of the ubuntu-7.04-server-i386.iso but the link on the website is broken
[20:28] <max_> can anyone help me?
[20:28] <AcePreshaw> 7.04?
[20:28] <AcePreshaw> !ask
[20:28] <max_> Yes sir
[20:28] <ubot3> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
[20:28] <AcePreshaw> 1 min
[20:29] <AcePreshaw> http://www.ubuntulinux.org/getubuntu/download-server
[20:29] <AcePreshaw> is ok
[20:30] <max_> yes but what about 7.04?
[20:30] <AcePreshaw> IT IS 7.04 NOOB
[20:30] <AcePreshaw> !noob
[20:30] <ubot3> Acronyms or statements like noob, jfgi, stfu, or rtfm are not welcome in this channel. Period.
[20:31] <AcePreshaw> but i have call you it
[20:31] <max_> AcePreshaw, you just sent me the link to the 9.10 download
[20:31] <AcePreshaw> soz
[20:31] <AcePreshaw> no you cant get it
[20:32] <max_> ?
[20:32] <AcePreshaw> http://www.ubuntulinux.org/testing/lucid/beta2#Download          here max_ soz
[20:33] <AcePreshaw> the sver is here
[20:33] <AcePreshaw> http://releases.ubuntu.com/releases/10.04/
[20:34] <AcePreshaw> the link is for 9.10
[20:34] <max_> Do you speak english? I don't want to download the lucid version I need to get 7.04 which is Feisty not 10.04 or 9.10
[20:34] <AcePreshaw> yea im in ie
[20:34] <AcePreshaw> SORY CAN GET IT
[20:35] <AcePreshaw> max_: you cnat get it
[20:35] <AcePreshaw> soz
[20:36] <AcePreshaw> !ask max_
[20:36] <ubot3> Factoid ask max_ not found
[20:37] <AcePreshaw> max_: !ask
[20:52] <jpds> max_: Feisty is no longer supported.
[20:53] <AcePreshaw> jpds:fnax
[21:03] <AcePreshaw> ikonia: hey
[21:03] <cjohnston> 81
[21:03] <cjohnston> uggh
[21:04] <AcePreshaw> lol


[23:33] <Chwoka> am i taking the files being downloaded off the internet, or am i taking them off the .iso disc i made?
[23:33] <parapa> Jordan_U i'm sure when i try to use wine i get an error saying Failed to creat Direct3D and in console theres an error saying err:winediag:X11DRV_WineGL_InitOpenglInfo Direct rendering is disabled, most likely your OpenGL drivers haven't been installed correctly
[23:33] <racho> cypha, i don't know what else could it be. usually a missing sym lynk or lack of devel packages leads to these problems but we covered them both.
[23:33] <cypha> sym links in the correct place?
[23:33] <Jordan_U> parapa: OK, check the "Additional Drivers" tool.
[23:34] <parapa> Jordan_U how do i run/check that?
[23:34] <Jordan_U> parapa: Go to the power icon at the top right of the screen then select "System Settings".
[23:35] <racho> cypha, ldconfig dynamicaly links when needed. that's why we ran it. maybe the folks at the PIL channel or #python  can give you other options
[23:35] <cypha> #pil?
[23:35] <cypha> #python no one really knows
[23:36] <racho> cypha, i don't know if it is #pil. i suspect they should have a channel.
[23:37] <racho> i'm sorry i wasn't very much of a help. wish you luck. and goodnight everyone.
[23:39] <culinor> so shall we use Unity or Gnome in the next LTS release?
[23:39] <Chwoka> aw man, i thought it was just going to skip installing that one file.  but it skipped installing every file from 28 to 69 :(
[23:40] <Polah> culinor: Unity is the default, other environments can be downloaded and installed as usual.
[23:40] <parapa> Jordan_U it says no proprietary drivers are in use on this system
[23:40] <Chwoka> is that bad. i'm guessing that's bad and i need to go try to install it again
[23:40] <culinor> thank you
[23:40] <OerHeks> Unity uses Gnome3 by then, so yes
[23:40] <Chwoka> am i correct in that assumption?
[23:41] <culinor> I am not sure I will like Unity so I was wondering if I would have the alternative to choose amongst others
[23:41] <Jordan_U> parapa: Can you run "glxinfo" and pastebin the output? (you may need to install glxinfo as instructed)
[23:41] <tlambert> anyone know which source file contains the default usb keyboard driver? usbkbd.c is apparently not it.  I need to add a modifier bit hack for some badly behaved hardware.  Probably upstreamable since I've seen similar reports.
[23:42] <Polah> culinor: Kubuntu, Xubuntu and Lubuntu will most likely continue to exist. I expect there will be an offshoot for GNOME3 by default instead of Unity with regular Ubuntu. Regardless of which one you get, you can always install another DE through apt whenever you want.
[23:43] <Chwoka> am i invisible?
[23:43] <culinor> thanks for explaining Polah
[23:43] <Polah> Chwoka: Yes.
[23:44] <zromayn> is there any dhcp-3-server savvy around. I have a few questions about the "allow client-updates;" option
[23:45] <zromayn> I'm trying to get the dhcpd to update the DNS records automatically, and I don't seem to quite make it happen yet
[23:45] <parapa> Jordan_U pastebin.ubuntu.com/703666
[23:46] <basix-> what up
[23:47] <Jordan_U> parapa: According to that your graphics drivers are fine.
[23:47] <Jordan_U> parapa: Try asking about the error message you recieved in #winehq.
[23:49] <parapa> Jordan_U ok thanks
[23:49] <zromayn> hello all: is there anybody around with dhcp3-server experience to help me out. I'm trying to get the dhcp server to automatically update my DNS server PTR table and I don't seem to quite get it yet.
[23:49] <tlambert> zromayn also have to set the ddns-update-style parameter, and your DNS must support either RFC 2136 or ad-hoc update mode AND it must be enabled AND it must trust your DHCP server.
[23:49] <Jordan_U> parapa: You're welcome.
[23:49] <tlambert> If the DNS server won't play, game over.
[23:50] <zemo> i have followed whats here http://portforward.com/english/routers/port_forwarding/SMC/SMCWBR14S-N4/ABC.ht  but when i try to connect to that port with the public IP i get connection refused and also running telnet on tat port, any help?
[23:51] <tlambert> zromayn also ad-hoc is generally deprecated and won't work anyway.
[23:51] <zromayn> tlambert: I'm trying to get it working with "allow client-updates"
[23:52] <zromayn> tlambert: which is the THE INTERIM DNS UPDATE SCHEME, according to the ubuntu manpages http://manpages.ubuntu.com/manpages/natty/en/man5/dhcpd.conf.5.html but the thing is that the manpages doesn't specify which dhcp3-server file I need to modify :S
[23:53] <parapa> Jordan_U they said I need 32bit GL libraries working, where would i get those
[23:53] <djbpython1> how much disk space do i need for a typical ubuntu install?
[23:53] <tlambert> ddns-update-style interim; ddns-updates on; -- then configure your DNS server to accept updates from your DHCP server via RFC 2136.
[23:55] <tlambert> zromayn if you do not control your DNS server configuration, this will likely not help you.
[23:55] <catcher> is there any shorthand for climbing directories in bash?  I find myself wasting time typing ../../../../
[23:56] <zromayn> tlambert: thank you. so the ddns-update-style interim; parameter goes into my /etc/dhcp/db.* file?
[23:57] <jrib> catcher: probably easier to start at / :)  Some people make aliases like ... and ...., etc.
[23:57] <tlambert> zromayn it goes into your dhcpd.conf file in the scope you want it to apply, of if you have broken out config files per scope, in one or more of those.
[23:58] <SARMAD> hi
[23:58] <Monsterwizard> hi
[23:58] <SARMAD> how  r u?
[23:59] <zromayn> tlambert: thank you, let me play with it to see if it works. btw, how can I get the dhcp3-server service to bounce? i have tried different options such as sudo service dhcpd restart or sudo /etc/init.d/dhcpd restart with no avail


[12:00]  * gmb -> lunch
[13:28] <gary_poster> bac` benji gmb mumble/kanban in 2
[13:28] <gary_poster> & hi :-)
[13:28] <gmb> gary_poster: ok
[13:38] <gary_poster> btw, I have to take kids to school this morning, so will be out briefly for that
[13:41] <bac> hello.  test.  echo.
[13:45] <gary_poster> hello, test, echo, bac
[13:45] <bac> thank gary_poster
[13:45] <bac> s
[13:45] <gary_poster> :-)
[13:46] <bac> my long nightmare of moving servers seems to be over
[13:46] <bac> yay kvm
[13:46] <gary_poster> is there a quick description as to why you did so?
[13:47] <bac> yeah, i had an old box on LTS-1 that i've been "meaning to" set up a back up strategy.
[13:47] <bac> i decided it was easier to move its jobs over to my newer box in a VM and power off the other one
[13:47] <bac> my power bills are nuts and i'm trying to get rid of extra goo
[13:47] <gary_poster> ah, I gotcha
[13:47] <bac> and now my backup strategy will be to clone the VM once a week
[13:48] <gary_poster> makes sense to me
[13:48] <bac> wouldn't work for google but is good enough for me
[13:48] <gary_poster> :-)
[13:48] <gary_poster> FWIW, re power bill, we've been switching to LEDs where we can
[13:48] <gary_poster> they are expensive but for themselves...oh it's been a while since I did the math
[13:49] <gary_poster> quick enough
[13:49] <gary_poster> and lightbulbs add up on our power bill surprisingly quickly
[13:49] <bac> i installed four cree LEDs in the kitchen.  they replace the cans that were there and completely seal against air leaks too
[13:49] <gary_poster> cool
[13:49] <gary_poster> our kitchen has I dunno 18 r20s
[13:49] <bac> expensive but the light is fantastic
[13:50] <gary_poster> taht adds up wattage fast
[13:50] <gary_poster> yeah
[13:50] <gary_poster> I've been pleased, though some of them seem to hum
[13:50] <bac> CFLs are the biggest joke evar
[13:50] <gary_poster> :-) how so
[13:50] <gary_poster> compared to LEDs they are
[13:51] <gary_poster> but they seemed bettar than incandescents for some uses
[13:51] <gary_poster> heh, better
[13:51] <bac> well, the ones they sell at lowes, etc are just junk.  slow to light, only last 18-24 months, poor light
[13:51] <gary_poster> ah gotcha
[13:51] <gary_poster> yeah
[13:51] <bac> they give the industry a bad name
[13:51] <bac> i should've done more research
[13:52] <bac> and bought good ones
[13:52] <gary_poster> we ended up not using that many of them.  where we have them, they are not awful
[13:52] <gary_poster> I sure hope the LEDs last as long as they are said to
[13:52]  * gary_poster needs to go get ready for taking kids to school.  back soon
[16:28]  * gmb -> run
[16:52] <bac> gmb: ping me when you get back, please
[17:06] <gmb> bac: What can I do you for?
[17:07] <bac> gmb:  i was looking at test_bug_subscription_wizard and was confused until i realized this was the work you have stopped
[17:07] <bac> i've since sorted that out.  :)
[17:07] <gmb> Ha.
[17:07] <gmb> bac: Apologies; I thought I'd dumped that code.
[17:08] <gmb> Was that what I pointed you at on Friday?
[17:08] <bac> gmb: yes
[17:08] <gmb> Hahaha.
[17:08] <gmb> bac: I must've just gone "bac needs some example tests; these are tests therefore they serve as examples."
[17:08] <gmb> Sorry.
[17:08] <bac> it makes reasonable sense...just isn't wired to anything
[17:08] <gmb> Right.
[17:10] <gmb> bac: Unless you've done it already or have any objections, I'll land my code removal branch for that today.
[17:10] <bac> sounds good
[17:10] <gmb> Cool
[20:09] <benji> I /really/ need to reboot Firefox so I'm going to let my system update itself and reboot.  Hopefully I'll be back in a few minutes.
[21:52] <gary_poster> benji, fwiw, you might have already figured this out, but the last sentence of the second bullet of my cover letter ("I wrote some new tests for the method, which also prove that the function does what we want (TestGetStructuralSubscriptionsForPerson).") was supposed to apply to the third bullet point
[21:52] <gary_poster> (that is, it is about getStructuralSubscriptionsForPerson, not about getStructuralSubscribers)
[21:52] <gary_poster> Sorry for the confusion
[21:53] <benji> gary_poster: no problem, your explanation came about 45 seconds before I was going to be confused
[21:53] <gary_poster> :-) excellent
[22:01] <benji> gary_poster: review done (https://code.launchpad.net/~gary/launchpad/bug723999-2d/+merge/52478)
[22:04] <gary_poster> thank you benji!  Did I singlehandedly consume half your day? I appreciate it, in any case
[22:05] <benji> more or less :)
[22:05] <gary_poster> well, it was good stuff at least, I think
[22:05] <benji> I enjoyed it though.  It crossed my mind that I wouldn't mind being OCR more often.
[22:06] <gary_poster> :-) cool
[22:10] <gary_poster> night all