[00:46] <jamesh> ijohnson: thanks for the suggestion.  It looks like security.syscalls.intercept.mknod was enough for my use case, so I might try getting that upstream into Snapcraft
[00:46] <jamesh> ijohnson: might be worth seeing if that works for you in CI too
[00:46] <ijohnson> jamesh: interesting, how did you use that with lxc ?
[00:47] <jamesh> ijohnson: I failed to build my project, stopped the container and ran "lxc config set snapcraft-core20-gdm security.syscalls.intercept.mknod=true"
[00:47] <jamesh> and tried again
[00:48] <jamesh> ijohnson: with this configuration, LXD allows a few mknod syscalls it considers safe
[00:48] <jamesh> enough for the small number of bootstrap device files I needed in the base snap
[00:48] <ijohnson> nice, yeah I'll give that a try then
[00:48] <jamesh> ijohnson: more details at https://linuxcontainers.org/lxd/docs/master/syscall-interception#mknod-mknodat
[00:49] <jamesh> it will let you create /dev/null, but not /dev/sda1 :-)
[00:50] <ijohnson> right :-)
[02:33] <mup> PR snapcraft#3218 opened: WIP: support some mknod calls in LXD builds <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/3218>
[05:23] <mborzecki> morning
[06:36] <mborzecki> mvo: hey
[06:38] <mvo> hey mborzecki
[06:44] <mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/9006 ?
[06:45] <mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
[06:56] <mvo> mborzecki: yeah, need to work a bit on packaging but will look while things are building etc
[06:56] <mborzecki> mvo: thanks!
[07:03] <pstolowski> morning
[07:09] <mvo> good morning pstolowski
[07:10] <mborzecki> pstolowski: heya
[07:15] <pstolowski> o/
[07:39] <zyga> good morning
[07:41] <mvo> zyga: good morning
[07:41] <zyga> somewhat better night
[07:41] <zyga> still 4AM-7AM hole is not great
[07:42] <zyga> today will be the more traditional snapd hacking day
[07:43] <mup> PR snapd#9008 closed: boot/initramfs_test.go: add Commentf to more Assert()'s <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9008>
[07:44] <mvo> ijohnson: should we ask dimitri to review 9010 ?
[08:13] <mborzecki> mvo: pushed your suggestion from https://github.com/snapcore/snapd/pull/9006#discussion_r454847330 with some tweaks, please take a look, it's a regex so extra pair of eyes won'thurt
[08:13] <mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
[08:29] <ogra_> ogra@pi4:~$ snap connect node-red-rpi:gpio  pi4-devel😛cm-gpio-14
[08:29] <ogra_> error: cannot perform the following tasks:
[08:29] <ogra_> - Connect node-red-rpi:gpio to pi4-devel😛cm-gpio-14 (cannot obtain systemd services for snap "pi4-devel": interface requires conflicting system needs)
[08:29] <zyga> ogra_: nice error message you have there
[08:29] <ogra_> hrm ... emojis ...
[08:29] <ogra_> yeah, my hexchat emoji plugin is a bit dumb
[08:30] <ogra_> zyga, so what is that ? what am i missing ? (my pi3 image works, my locally built pi4 one doesnt anymore)
[08:30] <zyga> it's a very specific error, it means that more than one thing would like to export the same GPIO IIRC
[08:30] <ogra_> seems that's new with yesterdays core release
[08:30] <zyga> are the GPIO slots defined correctly?
[08:31]  * zyga looks at snapd source
[08:31] <zyga> so
[08:31] <zyga> it's when an interface defines a systemd service
[08:31] <zyga> like we do for GPIO
[08:31] <ogra_> https://paste.ubuntu.com/p/yXCtRqP6QJ/
[08:31] <ogra_> thats my snap.yaml ...
[08:32] <zyga> and there's a service with a name but different definition
[08:32] <ogra_> shoudl eb identical to our std ones
[08:32] <mvo> mborzecki: heh, nice - sure, I have a look. don't get me wrong, I'm usually not a let's-use-regex type but this seemed appropriate
[08:33] <zyga> ogra_: weird, I mean the error does look valid unless we are missing something
[08:33] <ogra_> zyga, well i was indeed trying to get multiple apps read info from the same GPIO ... one is managing it, the other is monitoring it ...
[08:33] <mvo> mborzecki: looks great
[08:33] <mborzecki> mvo: heh, i still think adding regex is adding yet another problem, but yeah, this one seemed ok
[08:33] <zyga> ogra_: look at /etc/systmed/system/
[08:34] <ogra_> but since that error started occuring i cant connect/disconnect *and* GPIO interfaces anymore
[08:34] <ogra_> *any
[08:34] <zyga> for .service files named after the slot snap name (gadget here)
[08:34] <zyga> and gpio-NNN
[08:34] <zyga> maybe there's some bug there
[08:34] <ogra_> gra@pi4:~$ ls -l /etc/systemd/system/|grep gpio
[08:34] <ogra_> -rw-r--r-- 1 root root  264 Jun 20 10:41 snap.pi4-devel.interface.gpio-14.service
[08:34] <ogra_> -rw-r--r-- 1 root root  260 Jul 13 13:25 snap.pi4-devel.interface.gpio-4.service
[08:35] <zyga> this error is reported when the same file name has two differing definitions
[08:35] <ogra_> interestingly i'm pretty sure i have never connected gpio-4
[08:36] <ogra_> ogra@pi4:~$ snap connections node-red-rpi|grep gpio
[08:36] <ogra_> gpio                     node-red-rpi:gpio                     pi4-devel😛cm-gpio-4    manual
[08:36] <ogra_> gpio-memory-control      node-red-rpi:gpio-memory-control      :gpio-memory-control    manual
[08:36] <ogra_> and ...
[08:36] <ogra_> ogra@pi4:~$ snap disconnect node-red-rpi:gpio  pi4-devel😛cm-gpio-4
[08:36] <ogra_> error: cannot perform the following tasks:
[08:36] <ogra_> - Disconnect node-red-rpi:gpio from pi4-devel😛cm-gpio-4 (cannot obtain systemd services for snap "pi4-devel": interface requires conflicting system needs)
[08:36] <ogra_> (sorry for the smileys)
[08:38] <ogra_> oh, WOW
[08:38] <ogra_> ogra@pi4:~$ snap stop node-red-rpi
[08:38] <ogra_> Stopped.
[08:38] <ogra_> ogra@pi4:~$ snap disconnect node-red-rpi:gpio  pi4-devel😛cm-gpio-4
[08:38] <ogra_> error: cannot disconnect node-red-rpi:gpio from pi4-devel😛cm-gpio-4, it is not connected
[08:40] <ogra_> ogra@pi4:~$ snap connections |grep gpio
[08:40] <ogra_> gpio                   node-red-rpi:gpio                   pi4-devel😛cm-gpio-4    manual
[08:40] <ogra_> what a mess
[08:41] <zyga> pstolowski: ^^ hmm
[08:44] <pstolowski> could be the undo bug i fixed recently
[08:45] <ogra_> and funnily enough, the app can read the gpio state now
[08:45] <ogra_> (along with the other app managing it )
[08:46] <pstolowski> there were 2 bugs around this area where under certain circumstances security profile wouldn't reflect disconnected state
[08:47] <pstolowski> ogra_: can you restart snapd and re-try?
[08:48] <ogra_> pstolowski, funny ... that works ... i had rebooted inbetween
[08:49] <ogra_> i mean i had rebooted anmd it still did not work ...
[08:49] <ogra_> the manual snapd restart lets me disconnect now
[08:49] <pstolowski> ogra_: weird.. restart (reboot as well) would work around that bug
[08:49] <ogra_> yes, very curious ...
[08:50] <pstolowski> the problem was caused by inconsistent in-memory state of snapd after undo of a failed operation
[08:50] <ogra_> i can still not connect two apps to the same gpio interface though
[08:51] <pstolowski> ogra_: because of that "interface requires conflicting system .." error?
[08:51] <ogra_> yep
[08:51]  * ogra_ arghs ... i forgot i have a meeting in 10min ...
[08:52] <pstolowski> ok, i don't know about that, would need investigation
[08:52] <pstolowski> ogra_: perhaps report a bug with all the details of these snaps
[08:52] <ogra_> will do
[08:52] <pstolowski> thanks\
[09:19]  * zyga is really close to putting his x240 into the bin
[09:19] <zyga> linux runs well on thinkpads my ass
[09:21] <pstolowski> hmm
[09:23] <mborzecki> zyga: what's the problem?
[09:23] <zyga> suspend resume is broken
[09:23] <zyga> input stops working
[09:23] <zyga> past my level of accepting broken stuff
[09:24] <zyga> too tired
[09:25] <zyga> as much as I like native linux stuff like that makes me question sensibility of spending $$$ on new linux portables
[09:33] <mvo> zyga: my x250 is doing fine since forever and my t460s too
[09:33] <zyga> oh well
[09:33] <zyga> draw a lottery
[09:33] <mvo> zyga: and the x220 in the house too, the t400 too, they all suspend/resume all the time
[09:33] <zyga> it suspends allright ;)
[09:34] <mvo> zyga: yeah, looks like you got a bad lot :(
[09:34] <zyga> just on resume there's no input
[09:34] <zyga> and the log is full of errors
[09:36] <ijohnson> mvo: morning! yes we will want dimitri to look at it eventually I'm pretty sure, not sure if that point is now or not
[09:37] <mvo> +1
[09:37] <mvo> ta
[09:54] <mborzecki> ijohnson: hey, looking at your feedback in #9005, bootloader.Options is too confusing :/
[09:54] <mup> PR #9005: boot: support setting extra command line argument, bootloader interface tweaks <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9005>
[09:55] <pedronis> mborzecki: I asked a question there
[09:55] <pedronis> and hi
[09:55] <mborzecki> pedronis: hey
[09:58] <zyga> hey, welcome back pedronis :)
[10:03] <ijohnson> Welcome back pedronis
[10:03] <ijohnson> mborzecki: mmm you mean my feedback is confusing or it's too confusing to pass Options there?
[10:04] <mborzecki> pedronis: yeah, that's why i used InitramfsUbuntuBootDir there, should give us ubuntu-boot in install mode and run mode
[10:04] <mborzecki> ijohnson: options has become a bit confusing
[10:05] <pedronis> we need to fix the names of things
[10:08] <ijohnson> ah yes options is rather confusing now with all the different names and implications
[10:09] <mborzecki> ijohnson: pedronis: anyways i did not add a helper for setting extra args in recovery mode, as we can do it directly in makeBootable20
[10:09] <mborzecki> s/in/for/
[10:21] <pedronis> I I have updated my review queue, but not started on reviews yet, maybe this afternoon, I still have some catch up to do and also quite a few meetings in the afternoon
[10:21]  * pedronis but lunch first
[10:42] <zyga> uh, some annoying pain
[11:08] <mborzecki> uhh, managers tests are mocking/state setup heavy
[11:33] <ijohnson> mborzecki: haha yes indeed they are :-)
[11:35] <ijohnson> mborzecki: so I'm reviewing your code for setting up the cmdline for grub.cfg when managed by snapd PR's and I just want to take a step back and wonder why we need to have the static cmdline args inside the grub.cfg inside snapd at all? Why don't we have some other kind of internal asset setting which is just a list of strings (or a map[string]string) for the static / extra cmdline parameters separate from the grub.cfg
[11:36] <ijohnson> then we would not need to parse out the grub.cfg's setting of the cmdline from the grub.cfg at all, we would just compose it easily using go list of strings (or again a map) and then paste it into the grub.cfg when it is generated and written out to disk
[11:36] <ijohnson> that also seems like what we will end up doing when the gadget.yaml grows language to tell snapd about what kernel command line should be used
[11:36] <pedronis> ijohnson: the last part is horrible
[11:36] <ijohnson> woah sorry what is horrible
[11:36] <pedronis> composing grub.cfg
[11:36] <pedronis> doesn't seem we need to parse it
[11:37] <pedronis> I don't have a preference on that
[11:37] <ijohnson> it's literally just fmt.Sprintf with `cmdline=%s` ?
[11:37] <ijohnson> well seems it's slightly more complicated than that
[11:37] <pedronis> ijohnson: yes, but the edition inside it loses any meaning
[11:37] <pedronis> that's why I used the word horrible
[11:38] <ijohnson> so how will this work when the gadget.yaml wants to tell snapd what kernel command line to use ?
[11:38] <mborzecki> pedronis: ijohnson: maybe we should ahve another chat about cmdline wrt the doc that we discussed?
[11:38] <ijohnson> maybe I need to read your doc again
[11:38] <pedronis> ijohnson: the plan is to use the envs to convey that
[11:38] <pedronis> not the cfg
[11:38] <pedronis> maybe that isn't clear from the current code
[11:38] <mborzecki> ijohnson: hence snapd_extra_cmdline_args
[11:39] <pedronis> anyway none of this particularly means we should parse something out of the cfgs, I don't have a strong peference there
[11:39] <pedronis> given how actually this is used is slightly misleading
[11:39] <pedronis> in fact
[11:41] <pedronis> mborzecki: ijohnson: yes, I think another chat might be appropriate
[11:41] <pedronis> not sure we can fit it today though
[11:43] <ijohnson> sure I think a chat would be good
[11:43] <mborzecki> pedronis: maybe right before/after the standup?
[11:43] <pedronis> before could work
[11:43] <ijohnson> works for me
[11:44] <ijohnson> but in case it is an easy answer, which direction is snapd_extra_cmdline_args used? is that set by the gadget on image build time into the bootenv and then read by install mode snapd to then be used in writing the run mode bootloader config / env ?
[11:45] <pedronis> ijohnson: it's never read, it meant to be only written to
[11:45] <ijohnson> oh actually now I've gone and confused myself between the extra and static args
[11:45] <pedronis> I mean is read by the cfg but snapd code should always only write it
[11:46] <ijohnson> pedronis: so extra is always written by snapd out of thin air, and static is always coming entirely from the bootenv / gadget ?
[11:46] <mborzecki> pedronis: it's read when we want to compose what the command line will look like
[11:46] <pedronis> mborzecki: ?
[11:46] <pedronis> sorry something is very wrong then
[11:46] <ijohnson> mborzecki: but it's "read" from inside snapd though right ?
[11:46] <ijohnson> it's not read from the system / bootloader
[11:46] <ijohnson> iiuc
[11:47] <pedronis> ijohnson: mborzecki: it should be read from the gadget, never from the env by snapd
[11:47] <ijohnson> pedronis: when you say "it" just now, which one do you mean ?
[11:48] <pedronis> the extra args
[11:48] <pedronis> if I remember what was discussed
[11:48] <pedronis> I haven't looked at the code
[11:48] <pedronis> maybe we need pseudo code hre
[11:48] <ijohnson> yes what's confusing me is the ownership / reading direction of the env vars
[11:49] <pedronis> it should be very clear when you consider the security implication what should and shouldn't happen
[11:49] <pedronis> but I don't know what the current code is doing
[11:49] <ijohnson> yes, let's ignore the current code for now (sorry mborzecki :-) )
[11:50] <mborzecki> pedronis: hmm right, but we don't have the gadget part yet because it was not discussed, so the code is reading it from the env until we figure out the gadget.yaml
[11:50] <pedronis> mborzecki: it shouldn't do anything
[11:50] <pedronis> then
[11:50] <pedronis> this has all security implications
[11:50] <pedronis> we cannot half build pieces
[11:50] <pedronis> without thinking through the consequences
[11:51] <mborzecki> pedronis: yes, the same as reading static from disk, ok, let me drop that for now and leave a todo about gadget there
[11:51] <ijohnson> iiuc snapd should own the "static" env var and that should be entirely written by snapd for run/recover mode, and the gadget should own the "extra" part by writing into it's default bootenv for install mode, which snapd then just copy pastes from install bootenv into the run/recover boot env
[11:51] <ijohnson> is that understanding what you expect pedronis?
[11:51] <pedronis> sounds about right
[11:51] <ijohnson> ok
[11:52] <ijohnson> I think I understand what the design is then
[11:53] <mborzecki> and i need to update the doc then
[11:54] <pedronis> ijohnson: actually, no, the copy from install bootenv sounds wronng
[11:55] <ijohnson> oh
[11:55] <pedronis> snapd should read this info out of the gadget
[11:55] <pedronis> never the env
[11:55] <ijohnson> ah yes that was what I thought the original design was supposed to be
[11:55] <ijohnson> by read out of the gadget, do you mean read the bootenv out of the gadget snap, or do you mean read something like the gadget.yaml ?
[11:55] <pedronis> it then should write to env and use the pieces it built to know what to put as expectzed in the fde policy
[11:56] <pedronis> ijohnson: there's not bootenv in the gadget
[11:56] <pedronis> afair
[11:56] <pedronis> not for grub
[11:56] <pedronis> or maybe there is
[11:56] <pedronis> anyway, some info out of gadget.yaml or a .txt file
[11:56] <mborzecki> iirc we discussed gadget.yaml the last time
[11:56] <ijohnson> pedronis: for grub there is not
[11:57] <ijohnson> alright that all makes more sense and is closer to what I expected
[11:57] <mborzecki> fwiw, whether gadget or txt file is fetching it should be trivial
[11:59] <ijohnson> right
[12:23] <pedronis> ijohnson: mborzecki: do we still need a meeting?
[12:23] <ijohnson> I think it would still be nice even if just for 10-15 minutes
[12:23] <mborzecki> pedronis: ijohnson: 5-10 minute one right before the standup maybe? so that we're on the same page
[12:23] <pedronis> ok
[12:23] <ijohnson> sounds good to me
[12:24] <pedronis> let's do 10 mins
[12:24] <ijohnson> k
[12:50] <mup> PR snapd#9011 opened: release: merge 2.45.2 into release/2.45 <Created by mvo5> <https://github.com/snapcore/snapd/pull/9011>
[12:51] <sdhd-sascha> Is "MicroStack" worth a look? Or should i go another way?
[12:52] <sdhd-sascha> okay,
[12:53] <sdhd-sascha> ```
[12:53] <sdhd-sascha> error: cannot install "microstack": cannot query the store for updates: got unexpected HTTP status
[12:53] <sdhd-sascha>        code 503 via POST to "https://api.snapcraft.io/v2/snaps/refresh"
[12:53] <sdhd-sascha> ```
[12:54] <sdhd-sascha> I think is not you ;-) Is my LAN ;-)
[13:04] <mup> PR snapcraft#3216 closed: build providers: tweak environment clean detection and logging <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3216>
[13:04] <mup> PR snapcraft#3217 closed: cmake v2 plugin: add stage to CMAKE_PREFIX_PATH <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3217>
[13:54]  * zyga breaks for 15 minutes and then back to branches
[13:55] <mup> PR snapcraft#3218 closed: lxd: enable security.syscalls.intercept.mknod if supported to allow snaps to create some device nodes <bug> <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3218>
[13:57] <ijohnson> sdhd-sascha: the snap store is a bit under load right now, you might have difficulty installing snaps for a little bit today, but give it an hour or two and itshould be back to normal I think
[13:57] <ijohnson> cmatsuoka: regarding your comment here https://github.com/snapcore/snapd/pull/9010#discussion_r455026520, what do you mean archive and snap versions? of govendor?
[13:57] <mup> PR #9010: cmd/snap-bootstrap/initramfs-mounts: call systemd-mount instead of the-tool <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9010>
[14:03] <cmatsuoka> ijohnson: govendor, I remember I had a problem with mismatched hashes some time ago and I think it was caused by using a different govendor version
[14:04] <ijohnson> mmm I only have govendor from $GOBIN
[14:04] <cmatsuoka> ijohnson: now I'm using the focal deb which seems to be working well
[14:05] <ijohnson> mmm, perhaps I could try that, seems the focal version is 1.0.9 which is the same as my local $GOBIN, but I will look at what happens with the deb to see if that explains the SHA difference
[14:07] <cmatsuoka> or your new hash is right and the previous one was computed with a different version?
[14:11] <mborzecki> mvo: there's a conflict in https://github.com/snapcore/snapd/pull/9011
[14:11] <mup> PR #9011: release: merge 2.45.2 into release/2.45 <Created by mvo5> <https://github.com/snapcore/snapd/pull/9011>
[14:11] <mvo> mborzecki: will fix after the meeting
[14:41] <ijohnson> cmatsuoka: actually with the focal version of govendor I see the same diff, I did a clean checkout of snapd into a separate GOPATH, and only had govendor from apt on my $PATH and running get-deps still makes that checksumSHA1 change
[14:42] <ijohnson> cmatsuoka: so I'm really confused what's up here
[14:42] <ijohnson> cmatsuoka: are you on focal and using the deb ?
[14:42] <cmatsuoka> let me double check here
[14:43] <cmatsuoka> mm, yes, version 1.0.9+ds1-1
[14:43] <ijohnson> yeah same here
[14:44] <cmatsuoka> perhaps the previous hash is old, and the one you're computing now is what it should be?
[14:44] <zyga> isn't govendor using the stuff from your gopath?
[14:44] <zyga> (as in, it can put stuff from gopath into vendor)
[14:45] <mup> PR snapd#9011 closed: release: merge 2.45.2 into release/2.45 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9011>
[14:45] <ijohnson> zyga: yes but I have a new clean gopath with nothing in it except a fresh snapd master clone
[14:45] <zyga> ah
[14:45] <zyga> hmmmm
[14:45] <zyga> no idea then
[14:46] <zyga> could it be looking at more than gopath?
[14:46] <zyga> e.g. goroot?
[14:47] <ijohnson> cmatsuoka: are you using go from the snap or from the debian package ?
[14:47]  * ijohnson only uses go from snap
[14:48] <cmatsuoka> mm, mine is from the deb, 2:1.13~1ubuntu2
[14:48] <ijohnson> cmatsuoka: what is `go version` for you ?
[14:49] <cmatsuoka> go version go1.13.8 linux/amd64
[14:49] <ijohnson> mine is `go version go1.14.4 linux/amd64`
[14:50] <cmatsuoka> I used to use the snap version then switched to the deb version at some point
[14:50] <mup> PR snapd#9012 opened: release: merge 2.45.2 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/9012>
[14:51] <zyga> that's one unusual diff ;)
[14:55] <mup> PR snapd#9013 opened: many: merge 2.45.2 fixes back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/9013>
[15:05]  * cachio lunch
[15:16] <ijohnson> cachio: when you are back can you explain to me the early config test failure ?
[15:17] <mborzecki> store seems to be under load, spread jobs are failing
[15:19] <ijohnson> yes
[15:22] <mborzecki> hmm something odd happening with github, i've pushed changes to a branch, but the PR was not updated
[15:25] <ijohnson> github under load too ?
[15:25] <mborzecki> ijohnson: can you take a look at https://github.com/snapcore/snapd/pull/9006 later during your day? i've pushed the changes but the PR was not updated yet (hopefully it will be soon)
[15:25] <mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
[15:25] <ijohnson> sure
[15:25] <mup> PR snapd#9014 opened: [RFC] snapshotstate: move sizer to osutil.Sizer() <Created by mvo5> <https://github.com/snapcore/snapd/pull/9014>
[15:29] <mborzecki> ijohnson: thanks
[15:30] <mborzecki> closed and reopened, and now the commits show up, wtf
[15:31]  * ijohnson afk little bit
[15:51] <mup> PR snapd#9015 opened: cmd/snap-preseed: handle relative chroot path <Bug> <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9015>
[15:58] <cachio> ijohnson, hi
[15:58] <ijohnson> hi
[15:59] <cachio> ijohnson, so, the problem is that when we create the image and tehn try to connect the user created through cloud init is not sudoer
[15:59] <ijohnson> mmm
[15:59] <cachio> this is the log I got from the cloud init https://paste.ubuntu.com/p/McnFjkHBVh/
[15:59] <ijohnson> cachio: what specific test failed with what backend ?
[15:59] <cachio> ijohnson, it is happening 100% of the time
[15:59] <cachio> just sometimes
[16:00] <cachio> spread -debug google-nested:ubuntu-20.04-64:tests/nested/manual/core20-early-confi
[16:00] <ijohnson> cachio: sorry you mean that it is _not_ happening 100% ?
[16:00] <cachio> ijohnson, sometimes works well
[16:00] <cachio> but sometimes it doesn't
[16:00] <cachio> this is the weird part
[16:01] <cachio> so if you run this test 3/4 times you will reproduce it for sure
[16:01] <zyga> cachio what's the username you were expecting to see?
[16:01] <cachio> user1
[16:01] <zyga> do you have a log from a successful run?
[16:02] <cachio> zyga, no
[16:03] <cachio> zyga, I can generate one
[16:03] <zyga> maybe if we compare them something will show up
[16:03] <zyga> 18:00, time for meds
[16:03] <cachio> zyga, yes
[16:03] <cachio> agree
[16:03] <zyga> ouch, brb
[16:17] <ijohnson> cachio: ah now I can't reproduce that because store woes
[16:17] <ijohnson> cachio: I will try to reproduce again in a bit
[16:40] <cachio> ijohnson, this is the log when it works well https://paste.ubuntu.com/p/zWdn8kjb8Q/
[16:40] <cachio> perhaps it contains usefull data
[16:40] <cachio> I am taking a loog
[16:40] <cachio> look
[16:42] <ijohnson> cachio: looking
[16:42] <cachio> take a lok to line 460
[16:42] <cachio> the it adds the user
[16:42] <cachio> but in the other one that line does not appear
[17:00] <cachio> ijohnson, the weird part is that in both cases the user is created
[17:58] <cachio> ijohnson, could you reproduce it?
[18:01] <cachio> I triggered it again
[18:01] <cachio> I'll give you access if it fails
[18:05] <ijohnson> cachio I'll try again this morning the store was acting up for me
[18:05] <ijohnson> Err rather, I'll try again right now
[18:31] <mup> PR snapd#8972 closed: gadget/install,secboot: use snapcore/secboot luks2 api <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8972>
[18:43]  * cachio -> kinesiologist
[20:19] <ijohnson> diddledan: when you tried etrace and it didn't automatically close the window, were you using wayland ?
[21:12] <mup> PR snapd#9016 opened: secboot: improve key sealing tests <Test Robustness> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9016>
[22:02] <mup> PR snapd#9009 closed: tests/cmd/snap-bootstrap/initramfs-mounts: rm duplicated env ref kernel tests <Simple 😃> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9009>
[22:26] <cachio> ijohnson, hi
[22:26] <cachio> there?
[22:28] <cachio> ijohnson, could be affecting that rsyslog configuration in cloud init?
[22:28] <cachio> stages.py[DEBUG]: Running module rsyslog (<module 'cloudinit.config.cc_rsyslog' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_rsyslog.py'>) with frequency once-per-instance
[22:28] <cachio> in this test we update the gadget configuration and disable rsyslog by default
[22:29] <cachio> I see that when it fails to created the user1 is when this line "Running module rsyslog" is executed early
[22:29] <cachio> before than the user
[22:30] <cachio> could that be affecting?
[22:32] <cachio> cmatsuoka, hey
[22:32] <cmatsuoka> cachio: hi
[22:32] <cachio> could you give me the details about the test on uc20?
[22:32] <cachio> so I add that
[22:32] <cachio> I was a bit delayed today with other stuff and couldnt start yet
[22:33] <cmatsuoka> cachio: no worries, I'm testing my updates manually. The idea is to start with a beta system, update snapd, and it should still work after rebooting
[22:34] <cmatsuoka> because something can break in the TPM parameters
[22:34] <cmatsuoka> until now it worked normally after the update
[22:34] <cachio> cmatsuoka, ok, so snapd from beta to edge
[22:35] <cachio> right?
[22:35] <cachio> cmatsuoka, so I could run that when we have a new instance on edge
[22:35] <cmatsuoka> yes, but on the beta image
[22:35] <cmatsuoka> with only snapd being updated
[22:36] <cmatsuoka> it's not exactly from beta to edge, it's from beta to the current branch being tested
[22:36] <cmatsuoka> (which is not edge because it's not published yet)
[22:37] <cachio> cmatsuoka, so, from beta to master
[22:38] <cachio> right?
[22:38] <cachio> this should be executed on each pr?
[22:38] <cachio> or nightly is ok?
[22:39] <cmatsuoka> hm, I think nightly could be ok because very few PRs will touch TPM
[22:39] <ijohnson> cachio I don't think rsyslog would affect sudo user from cloud-init but unfortunately I've already EOD'd so I'll have to look tomorrow
[22:40] <cachio> cmatsuoka, nice, I'll do it
[22:40] <cmatsuoka> cachio: is it costly to do for every PR? if it's not so costly, maybe we could do it
[22:41] <cmatsuoka> we'll have changes in boot and bootloader too
[22:41] <cmatsuoka> so maybe it could be interesting to have it for every PR
[22:41] <cachio> cmatsuoka, I think initially I would add it to the nightly suite
[22:41] <cmatsuoka> cachio: ok!
[22:41] <cachio> and then to the regular
[22:42] <cachio> because we need a new system with tpm and uc20 on each pr
[22:42] <cachio> and this could be a bit more complicated
[22:42] <cmatsuoka> cachio: thanks! it will help us to ensure that beta can be upgraded
[22:43] <cachio> cmatsuoka, sure
[22:43] <cmatsuoka> cachio: ah ok, then nighly is fine
[22:43] <cachio> tomorrow I'll give you the update
[22:43] <cmatsuoka> cachio: thanks!
[22:46] <cachio> cmatsuoka, yaw


[02:36] <smartboyhw> Noskcaj, how's Testdrive?
[02:36] <Noskcaj> smartboyhw, A minor bugfix went to the tree yesterday, other than that it's just wait for DanChapman to finish gtk3
[02:37] <smartboyhw> Noskcaj, OK
[05:06] <DanChapman> morning all
[05:10] <Noskcaj> hey DanChapman
[05:14] <DanChapman> morning Noskcaj how are you?
[05:15] <Noskcaj> good. You?
[05:16] <DanChapman> yeah good thanks. :-)
[05:17] <Noskcaj> Have you had any progress on testdrive?
[05:22] <DanChapman> Noskcaj, I'm afraid not sorry, I've been a bit bogged down with Uni the last couple of weeks and also trying to get new Ubiquity tests created for all flavors
[05:22] <Noskcaj> That's fine, and ubiquity tests are higher priority
[05:22] <DanChapman> I will try and make some time this week though
[05:23] <Noskcaj> great
[19:03] <thomi> morning


[00:18]  * thumper proposes IsTrue and IsFalse in a separate branch for wallyworld_
[00:18] <wallyworld_> \o/
[00:19] <thumper> wallyworld_: I'll collect that beer sometime
[00:19] <wallyworld_> ok
[00:20] <thumper> wallyworld_: I'm trying to think how to test the error conditions better
[00:20] <wallyworld_> which branch?
[00:23] <wallyworld_> thumper: afk for a few minutes, bathroom guy arrived
[00:23] <thumper> ack
[00:23] <thumper> wallyworld_: Rietveld: https://codereview.appspot.com/10395044 this one
[00:24] <thumper> davecheney: how do I create an inline []interface{} containing strings
[00:24] <thumper> ?
[00:25] <davecheney> inline interface{} ?
[00:25] <thumper> nm
[00:25] <thumper> []interface{}{"foo", "bar"}
[00:25] <thumper> I was missing the first {}
[00:51] <wallyworld_> thumper: when you are free, i'd like to hear about the outcome of your deliberations regarding the lxc branch. but don't interrupt your current work
[00:55] <thumper> wallyworld_: I'm just making some lunch
[00:55] <thumper> but can talk soon
[00:55] <wallyworld_> no hurry, whenever
[00:55] <wallyworld_> now you've made me hungry
[01:02]  * thumper is making pizza
[01:13] <thumper> wallyworld_: chat now while the pizza cools?
[01:19] <wallyworld_> thumper: i'm free now but feel free to eat first
[01:21]  * thumper is munching now
[01:21] <thumper> wallyworld_: I'll ping you when not chewing
[01:21] <wallyworld_> sure
[01:29]  * thumper goes to make a coffee, then let the dog in
[01:40] <thumper> wallyworld_: now?
[01:40] <wallyworld_> ok
[01:40] <wallyworld_> i'll make a url
[01:40] <wallyworld_> thumper: https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
[03:55]  * thumper needs another +1
[03:55] <thumper> davecheney: you around?
[03:56] <thumper> bigjools: I wonder if your +1 is good enough :)
[03:57] <thumper> I think if I tried to propose this branch now, it'd shit itself
[03:57] <thumper> because I added a dependency
[03:59]  * thumper does it anyway to see what it looks like
[04:21] <jam> thumper: +1 on what?
[04:21] <thumper> hi jam
[04:21] <thumper> jam: https://codereview.appspot.com/10395044/
[04:22] <jam> thumper: my immediate thought is, do we need 'testing/checkers' vs just having the checkers in the 'testing' package? (given the earlier conversations about this).
[04:22] <jam> *I* like modules, but I recognize it doesn't always need to be separated.
[04:22] <thumper> jam: yes...
[04:22] <thumper> because
[04:22] <thumper> import . "launchpad.net/juju-core/testing/checkers"
[04:22] <thumper> as it brings them into the current namespace
[04:22] <thumper> normally with the testing functions, we don't want that
[04:23] <thumper> only checkers are in the testing/checkers
[04:23] <thumper> so you shouldn't be bringing in other functions
[04:23] <thumper> means our checkers can be used just like the normal gocheck ones
[04:23] <jam> (I don't think it would be terrible to have c.Assert(foo, testing.IsTrue) but I'll live with that)
[04:24] <thumper> jam: that makes it longer than c.Assert(foo, Equals, true)
[04:24] <thumper> :)
[04:24] <thumper> trying to make the tests more readable
[04:24] <jam> thumper: I type at about 60wpm :). I would hope the point of IsTrue is to give better messages.
[04:24] <thumper> by having meaningful checkers wthout package prefixes
[04:25] <thumper> me too
[04:25] <thumper> I'm more about the readability of the code
[04:25] <thumper> and I think without the package prefix reads more nicely
[04:25] <thumper> jam: however there are also some we work with that don't seemed to have learned to type :-)
[04:26] <davecheney> thumper: ack
[04:26] <davecheney> sorry, was at lunch
[04:26] <thumper> davecheney: that's ok
[04:27] <davecheney> and when I say 'was at lunch'
[04:27] <davecheney> i was in my kitchen eating a sausage
[04:32] <jam> thumper: reviewed https://codereview.appspot.com/10395044/
[04:32] <thumper> davecheney: sounds healthy
[04:32] <thumper> jam: ta
[04:36] <thumper> jam: did switch ever get to the state where it could remove directories that were added  in the other branch, and only contain ignored files?
[04:37] <jam> thumper: vila had a patch which moved ignored files into a lost-and-found instead of marking it conflicted.
[04:37] <thumper> jam: now, I tend to go "clean-tree", followed by "resolve --all"
[04:39] <jam> thumper: I think you have to turn it on with a config setting (tell it to treat ignored as lost and put them there, but I don't remember the exact syntax)
[04:40]  * thumper nods
[04:48] <jam> thumper: bzr.transform.orphan_policy=move
[04:48] <jam> will put them in `bzr-orphans'
[04:49] <jam> thanks to spiv in #bzr
[05:37] <thumper> jam: changed the file test functions into checkers
[05:37] <thumper> jam: have many more tests now
[05:40] <thumper> ok, and now I'm off
[05:40] <thumper> see y'all tomorrow
[07:47] <rogpeppe> mornin' all
[08:08] <TheMue> morning guys
[08:09] <TheMue> phew, what a start. had to fetch our daughter from work due to circulation problems. weather is extreme close and will go up to 34° today.
[09:42] <jam> rogpeppe1: I'm looking at https://code.launchpad.net/%7Erogpeppe/juju-core/312-alt-api-jobs/+merge/170135
[09:42] <jam> your cover letter sounds like you were moving code
[09:42] <jam> but I only see addition of code.
[09:42] <jam> Am I missing something?
[09:43] <rogpeppe1> jam: looking
[09:43] <rogpeppe1> jam: state/apiserver/machine/machiner.go has moved from state/apiserver/machiner
[09:44] <rogpeppe1> jam: the machine agent API is new
[09:45] <rogpeppe1> jam: (as per the CL description)
[09:45] <rogpeppe1> jam: (well, CL title anyway)
[09:48] <jam> rogpeppe1: https://codereview.appspot.com/10398043/ I guess codereview doesn't show renames very well. The only '-' lines I see are really machine_test.go
[09:49] <jam> it would appear Launchpad was unable to produce a diff
[09:49] <rogpeppe1> jam: no, it doesn't know about renames at all
[09:50] <rogpeppe1> jam: if you look at https://codereview.appspot.com/10398043/diff/2001/state/apiserver/machine/machiner.go - all that "unchanged" code is moved from a different directoryu
[09:50] <rogpeppe1> jam: (note the package name change at the top)
[09:51] <jam> rogpeppe1: well "machiner" vs "machine" is a bit hard to spot. You can actually see the rename in the unified diff mode.
[09:52] <jam> rogpeppe1: is there more than just mechanical changes here?
[09:52] <rogpeppe1> jam: yes
[09:52] <jam> rogpeppe1: any chance you can point them out, because most of the diff is just renaming stuff
[09:53] <rogpeppe1> new code:
[09:53] <rogpeppe1> https://codereview.appspot.com/10398043/diff/2001/state/api/params/params.go
[09:53] <rogpeppe1> https://codereview.appspot.com/10398043/diff/2001/state/apiserver/machine/agent.go
[09:54] <rogpeppe1> https://codereview.appspot.com/10398043/diff/2001/state/apiserver/machine/agent_test.go
[09:54] <jam> rogpeppe1: what is the difference between GoStringer and Stringer? (I realize what the actual attribute difference means, but what is the functional difference between having a String method and a GoString method) ?
[09:54] <jam> Is that %v vs %#v ?
[09:54] <rogpeppe1> jam: yes
[09:54] <rogpeppe1> jam: see the fmt docs for details
[09:55] <rogpeppe1> jam: that's all the significant new code. there are a few other tweaks here and there, which should be evident
[09:56] <rogpeppe1> jam: sorry for the confusion. i should probably have split it up into about 4 small CLs
[09:56] <rogpeppe1> jam: but i thought it was probably ok as is
[09:56] <jam> rogpeppe1: it probably would have been a bit easirer to review. Mixing mechanical renames with functional changes takes different mindsets to review.
[09:56] <rogpeppe1> jam: agreed
[09:57] <jam> The former is "is this a reasonable rename to do, yes/no" and the latter takes thinking about what the code is trying to doe.
[09:57] <jam> do
[09:57] <rogpeppe1> jam: i was trying to make a CL that would be a replacement for an earlier CL with similar intent in the another pipeline
[09:58] <rogpeppe1> jam: but i totally failed to merge it
[10:00] <jam> mgz, danilos: I'll definitely miss the standup today, have a kid's-friend's-birthday party to attend.
[10:00] <jam> I've been mostly doing reviews, my code to mgo landed, though.
[10:00] <mgz> jam: okay
[10:04] <jam> rogpeppe1: reviewed
[10:04] <jam> LGTM
[10:04] <rogpeppe1> jam: thanks
[10:11] <fwereade> jam, last night go-bot complained that I'd approved a branch without getting it re-reviewed... and then it somehow got magically merged by tim overnight
[10:11] <fwereade> jam, what did tim do, and what should I do to induce the same thing to happen?
[10:15] <danilos> jam: ok
[10:16] <danilos> jam: don't drink too much with those kids, though :)
[10:25] <wallyworld> fwereade: hi, you up for a chat sometime?
[10:25] <fwereade> wallyworld, sure, would you start one?
[10:25] <wallyworld> ok
[10:25] <wallyworld> fwereade: https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
[10:27] <rogpeppe3> danilos: any chance of a review of https://codereview.appspot.com/10398043/ please?
[10:27] <danilos> rogpeppe3, sure, taking a look
[10:28] <rogpeppe3> danilos: thanks
[10:50] <danilos> rogpeppe3, LGTM, minor comments on your comments only :)
[10:51] <rogpeppe3> danilos: tyvm
[10:51] <danilos> rogpeppe3, I like it how your code looks nice and clean, good job :)
[10:51] <rogpeppe3> danilos: thanks
[10:53] <rogpeppe3> danilos: re the bulk API call - it purports to allow you to get information for many machines at once. but we only allow a single machine to be got (the machine agent's own machine instance)
[10:53] <rogpeppe3> danilos: so there's no possible latency to be saved AFAICS
[10:54] <rogpeppe3> danilos: we can only ever usefully pass a single id to GetMachines
[11:00] <danilos> rogpeppe3, right, I'd say the API call names are a bit misleading then
[11:00] <danilos> rogpeppe3, I was thinking of something like juju-gui using a call like this to get information on all the machines
[11:01] <rogpeppe3> danilos: we are directed to make bulk API entry points for every single API call, regardless of whether it's actually appropriate to have one
[11:01] <rogpeppe3> danilos: i must obey :-)
[11:01] <danilos> rogpeppe3, ah, I see your point: you are complaining about the policy in that comment, understood :)
[11:01] <danilos> rogpeppe, ok then, keep the 'utter maddness' in :P
[11:03] <rogpeppe> danilos: the madness remains :-)
[11:33] <danilos> mgz, hey-hey, joining us?
[11:33] <mgz> danilos: want to talk? I'd need to reboot to do g+
[11:33] <mgz> had, same time
[11:34] <mgz> can you guys do mumble for today?
[11:34] <wallyworld__> ok
[11:34] <danilos> mgz, coming
[11:36] <fwereade> TheMue, ping
[11:36] <danilos> wallyworld__, can you hear me?
[11:45] <mgz> doh!
[11:45] <mgz> I'd left it on push to tal
[11:47] <mgz> danilos, wallyworld__: my audio was working fine the whole time, I just didn't look at the right setting till just after we'd finished :)
[11:53] <TheMue> fwereade: pong
[11:53] <fwereade> TheMue, tyvm for sync-tools work; can I ask for a little followup though?
[11:53] <TheMue> fwereade: sure, just proposed the resumer with better testing ;)
[11:54] <fwereade> TheMue, please delete the dead source environment config, and move the storage reader into environs/ec2 (actual location open to discussion, but it shouldn't be in juju/cmd)
[11:55] <fwereade> TheMue, (moving the actual syncing off somewhere different should also be done soon, but that's not what I'm talking about today)
[11:55] <TheMue> fwereade: ok, but in ec2 it will be public
[11:56] <TheMue> fwereade: thought i had the source stuff removed everywhere *sigh* will cleanup a bit :D
[11:56] <fwereade> TheMue, I want it to be public, it's a perfectly good StorageReader ;p
[11:56] <fwereade> TheMue, I think it's just one var :)
[11:56] <TheMue> fwereade: fine
[11:59] <danilos> mgz, heh, that only means you could have replied to all of our trash talk, but you missed it :P
[12:00] <fwereade> TheMue, btw, I redid https://codereview.appspot.com/10302043 to be simpler, would you take a quick look please?
[12:00] <TheMue> fwereade: *click*
[12:04] <rvba> danilos: Hi, would you mind having a look at jtv's branch (https://codereview.appspot.com/10367045/) when you get a chance?  Jeroen is off today but he will be back tomorrow and this is an important building block for our work on the Azure provider.
[12:05] <TheMue> fwereade: nice, looks better that way
[12:08] <danilos> rvba, sure
[12:08] <rvba> ta
[12:43] <rogpeppe> right, away with dodgy phone connections; i now have wired ether to the garden!
[13:08]  * rogpeppe goes for some lunch
[13:18] <ahasenack> hey guys, got this error updating trunk just now:
[13:18] <ahasenack> 	imports launchpad.net/juju-core/state/apiserver/machiner: import "launchpad.net/juju-core/state/apiserver/machiner": cannot find package
[13:22] <ahasenack> now it's working again, nm then
[13:44] <benji> gary_poster: I'll see if I can help him.
[13:45] <gary_poster> benji, oh ye of the jumping channels, thank you very much!
[13:45] <benji> gary_poster: it's confusing being omnipresent
[13:45] <gary_poster> lol
[14:06] <TheMue> fwereade: ping, hangout
[14:11] <niemeyer> jam: ping
[14:13] <mgz> niemeyer: jam probably won't be around this afternoon now
[14:16] <niemeyer> mgz: Cool, thanks
[14:16] <niemeyer> rogpeppe: ping
[14:16] <rogpeppe> niemeyer: in a call right now
[14:16] <niemeyer> rogpeppe: Cool, cheers
[14:16] <rogpeppe> niemeyer: i'll be with you in a bit
[14:17] <niemeyer> rogpeppe: Thanks, not in a hurry
[14:35] <rogpeppe> niemeyer: hiya
[14:35] <rogpeppe> niemeyer: call done
[14:35] <niemeyer> rogpeppe: Heya
[14:36] <niemeyer> rogpeppe: Would you mind to have a quick look at https://codereview.appspot.com/10366044/
[14:36] <rogpeppe> niemeyer: looking
[14:36] <niemeyer> rogpeppe: It's a simple change to implement ,inline in goyaml
[14:36] <niemeyer> rogpeppe: It's pretty much copied from mgo/bson
[14:36] <niemeyer> rogpeppe: There's a second part that I didn't do yet, to support inlining of maps
[14:36] <niemeyer> rogpeppe: I'll do that as well, but that will require some additional time
[14:38] <niemeyer> rogpeppe: I've just submitted https://codereview.appspot.com/10417043 as well, which is an obvious fix
[14:43] <rogpeppe> niemeyer: what happens if there are field conflicts?
[14:43] <niemeyer> rogpeppe: The same thing that happens currently: an error
[14:43] <niemeyer> rogpeppe: I know that's unlike the json API.. but it's okay, we can improve it later in a compatible way
[14:43] <rogpeppe> niemeyer: sounds like a good way forward
[14:45] <niemeyer_> Erm
[14:45] <niemeyer_> Weird those harsh disconnections
 niemeyer: sounds like a good way forward
[14:46] <niemeyer_> rogpeppe: That was the last thing I saw
[14:46] <rogpeppe> niemeyer_: that's the last thing i said :-)
[14:46] <niemeyer_> Cool
[14:49] <rogpeppe> niemeyer_: do anonymous struct members work essentially the same way as "inline" struct members?
[14:49] <niemeyer__> WTF?
[14:51] <rogpeppe> [15:49:08] <rogpeppe> niemeyer_: do anonymous struct members work essentially the same way as "inline" struct members?
[14:52] <rogpeppe> niemeyer__: i don't seem to see any code that understands about anonymous struct members, so perhaps not?
[14:52] <niemeyer__> rogpeppe: No, the only way to inline is with ,inline
[14:52] <rogpeppe> niemeyer__: ah
[14:52] <niemeyer__> rogpeppe: They are orthogonal concerns
[14:52] <rogpeppe> niemeyer__: encoding/json doesn't seem to think so
[14:53] <niemeyer__> rogpeppe: mgo/bson seems to think so, though :)
[14:53] <niemeyer__> rogpeppe: It's a departure from the standard behavior for sure, and a good one IMO
[14:54] <rogpeppe> niemeyer__: i'm wondering when you wouldn't want an embedded struct member to be treated as inline
[14:54] <niemeyer__> rogpeppe: They are orthogonal concerns
[14:54] <rogpeppe> niemeyer__: they *can* be orthogonal, sure. i'm just wondering if there's a particular benefit in having things that way
[14:54] <niemeyer__> rogpeppe: Whether you want to handle something in your code as inlined or not is an independent concern of whether you want it to look like being in a single block in a file
[14:55] <niemeyer__> rogpeppe: This *is* the benefit
[14:56] <rogpeppe> niemeyer__: perhaps so. i'm happy to see how it pans out.
[14:57] <niemeyer__> rogpeppe: Either way, we don't really have to debate this
[14:57] <niemeyer__> rogpeppe: We can't do anything else wihtout breaking compatibility
[14:57] <rogpeppe> niemeyer__: good point
[14:58] <rogpeppe> niemeyer__: i think you should be able to inline a *struct too
[14:59] <rogpeppe> niemeyer__: ha
[14:59] <rogpeppe> [15:57:49] <rogpeppe> niemeyer__: good point
[14:59] <rogpeppe> [15:58:31] <rogpeppe> niemeyer__: i think you should be able to inline a *struct too
[15:30] <rogpeppe> niemeyer__: reviewed, BTW
[15:57] <rogpeppe> fwereade_: ping
[16:05] <fwereade_> rogpeppe, pong
[16:05] <rogpeppe> fwereade_: i was just looking at this line in state/api/state.go:
[16:06] <rogpeppe> func (st *State) Machiner() (*machiner.Machiner, error)
[16:06] <rogpeppe> fwereade_: and thinking about future developments.
[16:06] <fwereade_> rogpeppe, oh yes
[16:06] <rogpeppe> fwereade_: i'm wondering about something like this instead: func (st *State) Machiner() *machiner.State
[16:07] <rogpeppe> fwereade_: reasoning that making a dummy request to check if we're allowed access isn't really that important
[16:07] <rogpeppe> fwereade_: and that from a client's point of view, it really looks like a kind of state object
[16:07] <fwereade_> rogpeppe, assuming that's all handled by the root swapping, yeah
[16:07] <rogpeppe> fwereade_: then we can have machineagent.State, upgrader.State etc etc
[16:08] <fwereade_> rogpeppe, it kinda does, yeah, I'm still thinking though
[16:08] <rogpeppe> fwereade_: well, you'll still be able to call State.Machiner even if you're not a machine agewnt
[16:08] <rogpeppe> fwereade_: but i don't think it matters much if we don't get an error until we make the first request
[16:09] <rogpeppe> fwereade_: because it's something that should never happen in practice anyway
[16:09] <fwereade_> rogpeppe, sure; and that leaves us open to construct agent-specific facades if we decide we have leisure to be clever in the future
[16:09] <rogpeppe> fwereade_: yeah
[16:10] <rogpeppe> fwereade_: i might be heading in that direction anyway
[16:10] <fwereade_> rogpeppe, I'm kinda +1 on having a common name, so the shapes of the packages are nice and clear and consistent
[16:11] <fwereade_> rogpeppe, but I'm not quite sure it should be State
[16:11] <fwereade_> rogpeppe, machiner.API, for example, feels closer than machiner.State
[16:11] <rogpeppe> fwereade_: using the name "State" means that we won't have to rename all the existing variables in the agent code
[16:11] <fwereade_> rogpeppe, ha, good point :)
[16:12] <fwereade_> rogpeppe, ok, sgtm, with an option on a future declaration (once I've forgotten this discussion) that it's a silly name and we should do a global replace ;p
[16:13] <rogpeppe> fwereade_: i think that from a client point of view, it's actually a perfectly sensible name - that's how you talk to the state
[16:13] <rogpeppe> fwereade_: the API is just a window onto the state
[16:13] <fwereade_> rogpeppe, you may very well be right
[16:13] <fwereade_> rogpeppe, cheers
[16:13]  * fwereade_ is off for a bit now, probably back later at some point
[16:14] <rogpeppe> fwereade_: ok, thanks
[17:32] <rogpeppe> time to stop and enjoy the sunshine with a cold drink
[17:33] <rogpeppe> g'night all
[20:34] <thumper> I'm going to be starting a little late today as I have to take kids to the dentist
[22:16] <dpb1> Hi folks: found one that might be low-hanging-fruit: https://bugs.launchpad.net/juju-core/+bug/1192728
[22:16] <_mup_> Bug #1192728: differing behavior with pyjuju: config-get all json <juju-core:New> <https://launchpad.net/bugs/1192728>
[23:44] <jtv> jam: since you commented on my branch, would you be willing to vote for landing?  It's this one: https://codereview.appspot.com/10367045/
[23:45] <jtv> If so, I can apply your generic version of the locking-test pattern in a follow-up branch.
[23:45] <jtv> (For now, we're rather blocked on this branch)


[12:08] <Dr_willis> the extensions do not change the data in the file.
[12:08] <tmdx120> Ash-Fox: i get can't find /hda4 in /etc/fstab or /etc/mtab
[12:08] <poisonborz> (can you multitask between questions? :) I've just installed dapper, and there's no display module... I would love to explore dapper, but not in 60mhz...)
[12:08] <Dr_willis> Open office files under windows work under linux, as do images and so forth.
[12:09] <Dr_willis> poisonborz,  heh - the wiki/forums got all sorts of X cofiguration  howto/guides.  may need to read the "!fixres" bot factoid.
[12:09] <Dr_willis> !fixres
[12:09] <ubotu> x is the X Window System; it's the part of your system that's responsible for graphical output. To restart your X, type this in a console: sudo /etc/init.d/?dm restart  -  To fix screen resolution or other X problems: http://help.ubuntu.com/community/FixVideoResolutionHowto
[12:10] <Ash-Fox> tmdx120, GRUB uses the BIOS boot order to detect which partitinos and harddrives, so (HD0,0) is the first harddrive, first partition, if it's the second harddrive detected where your data has been moved you need to change it to HD1,0 in /boot/grub/menu.lst
[12:10] <poisonborz> thx ubotu...
[12:10] <Dr_willis> ubotu,  is a bot. :P
[12:10] <Dr_willis> !bot
[12:10] <ubotu> I am ubotu, all-knowing infobot. You can browse my brain at http://bots.ubuntulinux.nl Usage info: http://wiki.ubuntu.com/UbuntuBots
[12:10] <locustwar> ok, so for example, if i create a 3d model with blender on linux, i will be able to read it with blender on windows ?


[01:40] <krabador> paultag, hi , some day ago we're talking about wiimote on linux, are you here?
[02:29] <hajour> good night all
[03:27] <benpowers23> ive downloaded maverick disk image and followed all the instructions on this page https://help.ubuntu.com/community/How%20to%20install%20Ubuntu%20on%20MacBook%20using%20USB%20Stick     But for the life of me i cannot get the macbook to boot off the usb.
[03:29] <benpowers23> can anyone help me, or atleast point me to the right room
[03:29] <benpowers23> ?
[03:30] <UndiFineD> sorry, no experiance with mac here
[04:25] <solomonhomicz> anybody know how to get a broadcom wireless to cooperate?
[04:26] <solomonhomicz> mine works every other restart
[04:27] <MrAnthrope> Hello everyone.
[04:31] <solomonhomicz> Hello, my Dell laptop won't find a wireless network when I log in, I activate the wifi button, everything turns on appears to work but no networks, if I restart, hit the button it hooks right up and sees all available networks
[08:55] <UndiFineD> is there an organisation that will sign ssl keys for free for use, instead of using self signed ?
[12:39] <ali_but> hello the room
[12:42] <ali_but> bye!
[13:09] <hajour> phillw, what they mean with challange by the personas?
[13:10] <hajour> phillw, already have get answer.:)
[13:37] <drrfrost> I have ubuntu installed and it was working perfectly. Now, I can't connect and the network icon has disappeared. I have installed a second ubuntu partition with very little memory that is working.
[14:42] <drrfrost> Is this the best room to post a connection problem?
[14:53] <UndiFineD> I have no idea how yo fix your network icon, but it should be available in the menu too
[14:54] <UndiFineD> system -> preferences -> network connections
[14:55] <drrfrost> I have gone that route "system -> preferences -> network connections" but it did not help.
[14:56] <pedro3005> drrfrost, is it a wired connection?
[14:56] <drrfrost> wireless
[14:56] <pedro3005> output of iwconfig ?
[14:58] <drrfrost> I will have to restart in the other partition. I will be tied up for the next two hours. Thank you and if you are still online I will post the output to you.
[14:59] <pedro3005> I won't be :(
[15:06] <seidos> nm-applet is running?
[15:28] <ali_but> not much going on here?
[15:28] <ali_but> Bye room
[16:17] <shahan> I need to change permission of a directory
[16:17] <shahan> As I am going to install Drupal
[16:19] <pedro3005> shahan, man chmod
[16:37] <CancerBat> hi
[17:11] <CMJones> hello, is anyone familiar with ubuntu, winxp, dual boot, installation, scanning hardware - "common cd rom drive undetected' when ubuntu installer is running off same cd rom
[17:17] <MrMintanet> Hey, how do you enable "ADD" mode in Compiz?
[17:26] <CMJones> hello, is anyone familiar with ubuntu, winxp, dual boot, installation, scanning hardware - "common cd rom drive undetected' when ubuntu installer is running off same cd rom
[17:28] <UndiFineD> !dualboot
[17:28] <ubot2> Dual boot instructions: x86/AMD64: https://help.ubuntu.com/community/WindowsDualBootHowTo - MACs: https://help.ubuntu.com/community/MacBookPro https://help.ubuntu.com/community/YabootConfigurationForMacintoshPowerPCsDualBoot
[18:06] <pizza_the_hut> Hey all
[18:07] <bioterror> spaceballs <3 ;)
[18:07] <pizza_the_hut> yup! hehe
[18:22] <karthick87> hello cprofitt :)
[18:30] <karthick87> cprofitt: Are you busy??
[18:48] <cprofitt> karthick87: I am in and out...
[18:48] <cprofitt> but free right now
[20:41] <tec-joc> Hello all
[20:42] <tec-joc> I want to buy motherboard, but do not know which one, saying the Biostar vs. Asrock
[20:43] <bioterror> I would buy the one with dual sockets for Intel Xeon ;)
[20:46] <tec-joc> Asrock or Biostar?