[05:11] <zyga> o/
[05:39] <zyga> good morning
[05:39]  * zyga tracks a small anomaly
[05:40] <zyga> in other news everything is hard
[05:44] <mborzecki> morning
[05:44] <zyga> hey
[05:45] <zyga> somehow 16.04 can do things 18.04 cannot
[05:57] <zyga> I think I just learned something new
[06:00] <zyga> session startup, you'd think stuff would wait
[06:04] <zyga> mborzecki: how are you feeling today?
[06:04] <mborzecki> zyga: meh, tired, i should go for a bike ride or sth
[06:06] <zyga> yeah
[06:06] <zyga> I feel the same
[06:06] <zyga> but also this damn allergy
[06:06] <zyga> I need to go to a pharmacy today
[06:09] <zyga> heh
[06:10] <zyga> I think I start to understand
[06:16] <mup> PR snapd#8546 closed: seccomp: add get_tls, io_pg* and *time64/*64 variants for existing syscalls <⚠ Critical> <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8546>
[06:17] <zyga> So we will have another point release
[06:40] <zyga> ok, breakfast and one more patch
[06:40] <zyga> and it is ready
[06:43] <mup> PR snapd#8496 closed: interfaces/apparmor: use differently templated policy for non-core bases <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8496>
[07:02] <mborzecki> mvo: hey, can you take a look at https://github.com/snapcore/snapd/pull/8543 ?
[07:02] <mup> PR #8543: overlord/devicestate: preserve the current model inside ubuntu-boot <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8543>
[07:02] <mvo> mborzecki: sure
[07:02] <pstolowski> morning
[07:02] <mvo> pstolowski: good morning
[07:02] <mvo> happy release day
[07:03] <pstolowski> ha, likewise :)
[07:06] <pedronis> mborzecki: mvo: hi, #8513 needs another review
[07:06] <mup> PR #8513: snap-bootstrap: lock access to sealed keys <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8513>
[07:06] <mborzecki> pedronis: i'll take a look
[07:07] <mborzecki> looks like uboot.env is still a mess
[07:07] <pedronis> mborzecki: in which sense?
[07:08] <mborzecki> pedronis: looking at ijohnson's standup notes, he wrotne we cannot have /uboot.env (?)
[07:08] <pedronis> mborzecki: yes, it's complicated, but we have a plan
[07:09] <mvo> pedronis: yeah, saw your push there, thanks for this
[07:11] <mborzecki> pedronis: i see, /uboot/ubuntu/uboot.sel, should be rather simple, i can work on a pr
[07:11] <pedronis> mborzecki: mvo: I think we should try to finish the tpm stuff
[07:11] <mvo> +1
[07:12] <mborzecki> ok
[07:12] <pedronis> mborzecki: I think Ian's might have work in progress on the uboot stuff
[07:12] <pedronis> not sure
[07:12] <pedronis> mborzecki: mvo: now secboot should have all the helpers we need
[07:13] <pedronis> mborzecki: #8464 is still not working, right?
[07:13] <mup> PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
[07:14] <mborzecki> pedronis: yeah, i see some wip commits with /uboot/ubuntu in one of the new branches in ian's repo
[07:16] <mup> PR snapd#8543 closed: overlord/devicestate: preserve the current model inside ubuntu-boot <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8543>
[07:16] <mborzecki> yay
[07:17] <mborzecki> btw. have you guys noticed that there's like 2-3 emails when tests finish per pr now?
[07:18] <pedronis> yes, we something fails
[07:18] <pedronis> s/we/if/
[07:19] <pedronis> mborzecki: actually, you didn't push master to #8464 again yet? it has conflicts atm btw
[07:19] <mup> PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
[07:19] <mborzecki> pedronis: heh, right, i merged and fixed conflicts yesterday but forgot to push
[07:19] <mborzecki> pedronis: anyways, ther's new conflicts to fix today
[07:20] <pedronis> there might be more conflicts now
[07:30] <pedronis> mvo: have you played with calling bootstrap.Run directly ? we need to decide what to do with #8531
[07:30] <mup> PR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>
[07:35] <mvo> pedronis: I did, I can create a proper pr, the most simple version that just moved bootstrap.run into overlord and leave strange imports is very small
[07:36] <pedronis> mvo: we have the spread tests though
[07:36] <mvo> pedronis: right, we could build the needed command for testing in the spread test
[07:37] <pedronis> yea, that sounds reasonable
[07:37] <mvo> I can poke at this now, I just did half a review of 8513 but this PR seems equally important
[07:38] <pedronis> mvo: please finish 8513
[07:38] <pedronis> it's kind of hard to progress on that side before it is in
[07:38] <pedronis> because of code placement questions
[07:40] <mvo> pedronis: https://paste.ubuntu.com/p/yr8zqHPyqK/ is the absolute minimium without tests to call run directly
[07:40] <mvo> pedronis: sure, will do the 8513 now
[07:43] <pedronis> mvo: that looks reasonable, we'll need a way to mock it
[07:43] <pedronis> instead of the command as we do now
[07:43] <mvo> pedronis: yeah, that should be easy as it's pratcially the same as the commdnline
[07:43] <mvo> pedronis: but yeah, will work on it right after 8513 - should I try to move the imports too ?
[07:45] <pedronis> mvo: no, not right now, we have both boostrap and partition to deal with, and I'm not sure what to do exactly atm
[07:46] <mvo> ok
[07:49] <zyga> is master green now (is it worth merging master to unstuck PRs)?
[08:01] <pedronis> zyga: i'ts better but still lots of weird failure, I just got failures on amazon linux, not sure about what
[08:04] <mborzecki> can we trim the standup doc? it's 148p long atm
[08:09] <ijohnson> hey folks
[08:11] <ijohnson> mborzecki: I see you found my wip branch for "text" ubootenv stuff, are you working on that now? I think it was mostly there except for tests and some changes to bootloader.Find sprinkled around
[08:12] <mborzecki> ijohnson: no, looking at some PRs atm
[08:12] <ijohnson> mborzecki: ok I will finish that up now then
[08:16] <mvo> ijohnson: good morning! isn't it like terrible early?
[08:17] <ijohnson> good morning mvo
[08:17] <ijohnson> it is fairly early yes, but I didn't finish everything yesterday so I wanted to wrap it up now
[08:17] <ijohnson> it's a bit quieter in the house now :-)
[08:18]  * mvo hugs ijohnson
[08:18] <mvo> ijohnson: woah!
[08:18] <mvo> ijohnson: thanks so much!
[08:20] <mborzecki> pedronis: i suppose next step is adding MeasureSnapModelToTPM for run mode?
[08:20] <mborzecki> and https://github.com/snapcore/snapd/pull/8531 ?
[08:20] <mup> PR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>
[08:22] <pedronis> mborzecki: yes, but we need the lock keys one landed to have a place for the first thing
[08:22] <pedronis> mborzecki: also we need to write model to modeenv still, right?
[08:22] <mborzecki> pedronis: this landed already
[08:22] <mborzecki> pedronis:  i mean model to modeenv
[08:23] <pedronis> mborzecki: really ?
[08:23] <pedronis> I'm confused
[08:24] <mborzecki> pedronis: hm both #8542 #8543 landed
[08:24] <mup> PR #8542: boot: store model model and grade information in modeenv <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8542>
[08:24] <mup> PR #8543: overlord/devicestate: preserve the current model inside ubuntu-boot <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8543>
[08:24] <mborzecki> i think we should have everything we need now
[08:38] <mborzecki> zyga: hey, can you take a look at https://github.com/snapcore/snapd/pull/8520/checks?check_run_id=611343459 wth happened there?
[08:38] <mup> PR snapd#8513 closed: snap-bootstrap: lock access to sealed keys <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8513>
[08:38] <mup> PR #8520: data: fix shellcheck warnings in snapd.sh.in <Created by jelovac> <https://github.com/snapcore/snapd/pull/8520>
[08:39] <zyga> sure, looking
[08:39] <zyga> mborzecki: I think jamesh knows this issue
[08:39] <zyga> mborzecki: the check is wrong, it assumes a specific history
[08:39] <mborzecki> why isn't gh actions merging the branch to master or master to the branch?
[08:39] <zyga> jamesh: ^ can you explain what's the problem with the CLA check
[08:41] <zyga> the action checks out the code as is
[08:41] <zyga> the cla check workflow is different as it gets more history IIRC
[08:41] <jamesh> zyga, mborzecki: I think the problem is that the revision under test is a merge that allows fast forwards.  So the assumption that it has two parents is wrong
[08:41] <zyga> mborzecki: we could code an action that merges first
[08:42] <jamesh> in the fast forward case, we can't determine the base revision from the head revision
[08:44] <mborzecki> jamesh: i have this pr open: https://github.com/snapcore/snapd/pull/8455 maybe you know the proper way to pass the commit range from github context
[08:44] <mup> PR #8455: tests/lib/cla_check: expect explicit commit range <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8455>
[08:45] <jamesh> mborzecki: I think we'd need an additional step to fetch the github.base_ref branch into the local repo
[08:49] <zyga> mborzecki: did MATCH NOT get merged?
[08:49] <mborzecki> zyga: hm?
[08:49] <zyga> jamesh: the checkout action has some options
[08:49] <zyga> jamesh: perhaps we could use something it already offers
[08:49] <zyga> mborzecki: the spread MATCH extension you proposed
[08:49] <mborzecki> idk
[08:50] <mborzecki> zyga: i think someone else proposed that
[08:50] <zyga> ah
[08:50] <zyga> it's NOMATCH
[08:50] <zyga> thanks !
[08:55] <jamesh> mborzecki: I've added a comment to your PR with a possible solution
[08:57] <mborzecki> jamesh: thanks, let me check that
[09:00] <mborzecki> zyga: jamesh: btw the checkout action does something weird, in one PR it's doing: `/usr/bin/git checkout --progress --force refs/remotes/pull/8455/merge`, in one from a contributor it does `/usr/bin/git checkout --progress --force -B master refs/remotes/origin/master`
[09:01] <mborzecki> in the first case it's using that magical ref that github has for 'merged' PR
[09:01] <mborzecki> no clue why it's not used in the 2nd case
[09:01] <jamesh> mborzecki: check the source maybe?
[09:04] <jamesh> mborzecki: looks like it treats "refs/heads/**" references different to "refs/pull/**" ones: https://github.com/actions/checkout/blob/master/src/ref-helper.ts#L29
[09:04] <mborzecki> jamesh: heh, that's what, the magic happens here i'm doing https://github.com/actions/checkout/blob/master/src/ref-helper.ts#L8-L58
[09:04] <mborzecki> ah, so we're reading the same code ;)
[09:07] <mborzecki> anyways, more important stuff to deal with atm :/
[09:13] <mborzecki> https://news.ycombinator.com/item?id=22953506 quite a bit of comments from people not so happy about snaps
[09:14] <jamesh> Just tell them that snapd is written in Lisp.   Then they'll love it
[09:15] <zyga> and it's a lisp VM implementing haskel
[09:15] <zyga> then they will die with a smile on their faces
[09:15] <jamesh> snapd has all of the parentheses
[09:19] <mborzecki> all you parens belong to us
[09:19] <zyga> on the upside, all my tests now pass on core and classic
[09:19] <zyga> and I found something I don't know the answer for yet
[09:19] <zyga> jdstrand: app tracking works on 16.04, doesn't work on 18.04 (for the non-root user) - I presume it is the kernel version responsible
[09:20] <zyga> jdstrand: and that 18.04 kernel has the extra hardening on cgroups that 16.04 lacks
[09:22] <zyga> mborzecki: I replied to some comments there, it's not that negative actually
[09:25] <zyga> (and for context, it works on 16.04+ but in the desktop session)
[09:25] <zyga> my comment was not about the desktop session
[09:26] <mup> PR snapd#8547 opened: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
[09:34] <zyga> jamesh: FYI, core-* doesn't have dbus.socket for users
[09:34] <zyga> jamesh: perhaps it should?
[09:34] <zyga> it kind of cripples user sessions
[09:35] <mvo> pedronis: 8547 is the minimal move we talked about for snap-bootstrap create-paritions, I look at the tests now
[09:35] <mvo> (spread tests)
[09:38] <pedronis> mvo: thanks, afk for a bit, but I will look soon
[09:50] <mup> PR snapd#8548 opened: cmd/snap-bootstrap: cleanups, naming tweaks <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8548>
[10:01] <pedronis> mvo: thank you, did a pass on #8547, some small comments
[10:01] <mup> PR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
[10:06] <mup> PR snapcraft#3083 opened: repo: revert logic to get deb_arch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3083>
[10:07] <pedronis> mborzecki: thanks, some comments on #8548, a comment got messed up there
[10:07] <mup> PR #8548: cmd/snap-bootstrap: cleanups, naming tweaks <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8548>
[10:09] <zyga> mvo: can you merge 8515 please
[10:13] <caribou> Hello everyone, I'm hitting a rather peculiar situation with snapd initialization on first boot from a Focal Ubuntu Cloud Image.
[10:13] <caribou> If I copy files in /usr/local/bin in the QCOW2 prior to booting, everything works fine. If I untar the same files in the images, snapd is unable to complete its seeding
[10:15] <zyga> caribou: can you please share the state of the system when snapd tries to seed
[10:15] <zyga> but also this is not the best moment, everyone is swamped with work :/
[10:15] <caribou> zyga: very first boot off a slightly modified UCI
[10:15] <jamesh> zyga: perhaps, but 16.04 classic also doesn't ship those units (it has the session bus managed by a user instance of Upstart)
[10:15] <caribou> zyga: I'm aware of that
[10:16] <zyga> jamesh: indeed
[10:16] <caribou> so don't hesite to overlook the request for now
[10:16] <jamesh> zyga: it would be pretty easy to add to core (install dbus-user-session), but it might not be worth it.
[10:17] <zyga> jamesh: FYI, I pushed this test
[10:17] <zyga> https://github.com/snapcore/snapd/pull/7825/files#diff-61f3c400c3c80345d518c7ff0d0b3953R1
[10:17] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[10:17] <zyga> jamesh: this feature is really really really hairy
[10:17] <zyga> "what could go wrong" :|
[10:17] <zyga> I will run a smoke test to see what happens if it's on by default
[10:18] <caribou> zyga: don't bother with my request, I'm working on figuring out a workaround. I'll come back on calmer days :)
[10:18] <zyga> ok
[10:19] <zyga> caribou: sorry and thank you for understanding
[10:19] <jamesh> zyga: I doubt it would break anything: it would have zero effect on classic systems, and I doubt anyone starts systemd user sessions on Ubuntu Core 16 devices
[10:19] <zyga> I agree
[10:20] <mborzecki> is vendor.json showing up as modified for you guys, despite calling govendor sync?
[10:20] <mborzecki> it's like govendor does not know about git reset or sth
[10:21] <zyga> mborzecki: nope?
[10:21] <zyga> what does it show
[10:22] <jamesh> zyga: looking at that spread test, is the plan to continue using adding processes to the freezer cgroup on v1 systems?
[10:22] <zyga> yes because that is done for different reasons (mount raciness)
[10:23] <zyga> though we could probably invest in the new mount APIs at some point
[10:23] <zyga> where we could drop that
[10:24] <jamesh> zyga: so I guess the check would be to look for the substring "/snap." in the empty and name=systemd cgroups, or starting with "/snap."  in freezer cgroup?
[10:25] <zyga> mmm, sorry, got distracted
[10:25] <zyga> can you expand on this?
[10:25] <jamesh> zyga: this is for a quick "is this process a snap?" check
[10:25] <zyga> ahhh
[10:25] <zyga> yes
[10:25] <zyga> I will send a small patch here to reverse the UUID and security tag bits
[10:26] <zyga> as jamie asked for that and I think -- at this point -- this branch can take anything
[10:26] <jamesh> could I skip the name=systemd group?
[10:26] <jamesh> or would it be good to continue including that?
[10:26] <zyga> I would not skip it, you should look at freezer (on v1), at name=systemd or at v2 pure cgroup,
[10:27] <zyga> either freezer or pure v2 will always be reliable
[10:27] <jamesh> right.  That's why I was wondering if I could ignore name=systemd
[10:28] <zyga> ah, I see
[10:28] <zyga> I guess... yeah
[10:28] <zyga> but I would check all three
[10:28] <zyga> until phase out of v1 is more better understood
[10:28] <zyga> in case there's a future window where freezer is gone
[10:28] <zyga> but we are still on v1
[10:28] <jamesh> fair enough.
[10:29] <jamesh> including all three is not much of a problem
[10:37] <mup> PR snapd#8549 opened: tests: fix a typo in nested.sh helper <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8549>
[10:38] <mup> PR snapd#8515 closed: testutil: add NewDBusTestConn <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8515>
[10:38] <zyga> ta!
[10:41] <ijohnson> pedronis: so I have the ubootenv + bootloader changes finished with tests (still need full system test on my pi which I will do in a moment), do you want me to split it up to propose just the "text" format support, then a followup using that format, or shall I just bundle them all together?
[10:44] <zyga> brb, neet to stretch back
[10:44] <zyga> the full run of refresh-app-awareness enabled by default is progressing and seems to be all good for now (fingers crossed)
[10:45] <zyga> I don't anticipate anything specific but I wanted to give it some broader check, even if it's disabled now
[10:46] <pedronis> ijohnson: how big it the diff?
[10:47] <ijohnson> 461 lines added, 334 removed
[10:48] <ijohnson> pedronis: ^
[10:49] <pedronis> ijohnson: seems fine as one PR, unless you think some bits are potential controversial
[10:49] <pedronis> mborzecki: I have govendor messing with vendor.json too, I didn't dig though
[10:50] <ijohnson> pedronis: mmm my ubootenv changes could be contraversial but hell let's give it a shot I'll open it all in 1 PR, give me a moment
[10:53] <mborzecki> pedronis: does git diff show that checksumSHA1 is changed in your system too?
[10:53] <mborzecki> (in vendor.json file)
[10:53] <pedronis> mborzecki: yes
[10:54] <pedronis> mborzecki: for secboot and x/sys/unix
[10:54] <mborzecki> pedronis: yup, same here
[10:54] <mup> PR snapd#8550 opened: ubootenv, uboot: support new uc20 style text bootenv <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8550>
[10:54] <ijohnson> pedronis: opened at ^
[10:54] <mborzecki> maybe they changed what goes into the checksum
[10:54]  * ijohnson takes a break for a bit
[10:54] <pedronis> mborzecki: what does govendor --version prints for you?
[10:54] <mborzecki> oh and https://github.com/kardianos/govendor is marked as archived
[10:55] <mborzecki> pedronis: 1.0.9
[10:55] <pedronis> same
[10:55] <pedronis> yea, we should move to modules but need to consider when
[10:55] <pedronis> it terms of options and go we need to support
[10:56] <pedronis> ijohnson: can you set milestone 2.45, that's the way we/I track beta (UC20+2.45)
[10:56] <ijohnson> pedronis: sure
[10:57] <pedronis> ijohnson: thx, its in my queue now, I'll look in a bit, kind of finishing lunch break
[10:57] <pedronis> *it's
[11:00] <pedronis> mvo: good news #8547 passed on core 20 but lots of "random" red
[11:00] <mup> PR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
[11:00] <mvo> pedronis: good and bad
[11:01] <mvo> pedronis: I will address your point in a wee bit, just pushed the test update
[11:01] <mup> PR snapd#8551 opened: snap-bootstrap: remove create-partitions and update tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/8551>
[11:06] <pedronis> mvo: actually is not random
[11:06] <pedronis> mvo: we have the issues of build on any distro but ubuntu
[11:06] <pedronis> we need the nosecboot tags
[11:06] <pedronis> used properly for this
[11:07] <pedronis> mvo: snap-boostrap was built only on ubuntu, but of course snapd is built everywhere
[11:10] <pedronis> mvo: do you need help with that?
[11:12] <mvo> pedronis: uh, yes please
[11:12] <mvo> pedronis: that will be a bit annyonig and I need to get lunch in a wee bit
[11:12] <pedronis> mvo: I'll see what I can do there
[11:13] <mborzecki> hm maybe we shouldn't build s-b on non ubuntu at all and skip the tests that fail?
[11:17] <mvo> pedronis: thank you!
[11:18] <pedronis> mborzecki: we don't build s-b, on non-ubuntu, but mvo has moved a bunch of it inside snapd
[11:18] <pedronis> now
[11:18] <pedronis> that's the issue
[11:18] <pedronis> I'll work on it
[11:46] <pedronis> mvo: not at simple as adding tags, there is something else going on with the build
[11:47] <pedronis> blargh, we rm  cmd/snap-bootstrap in some build
[11:48] <mup> PR snapd#8548 closed: cmd/snap-bootstrap: cleanups, naming tweaks <Skip spread> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8548>
[11:57] <mup> PR snapcraft#3083 closed: repo: revert logic to get deb_arch <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3083>
[12:13] <pedronis> ijohnson: have you forgotten to add some files?  I see a openNativeFormat that is not defined
[12:14] <pedronis> ijohnson: I also if possible would try to minize the diff
[12:14] <pedronis> of env.go, it's fairly unreadable atm
[12:20] <pedronis> mvo: I pushed fixes for fedora etc, but debian is a bit messy and needs more work
[12:31] <mvo> pedronis: ok, I have a look
[12:31] <pedronis> mvo: I'm actually trying a fix, maybe it works
[12:32] <jdstrand> zyga: I tested it on 18.04 and saw that the scope was being created and pids added to it?!?
[12:32] <zyga> jdstrand: hey!
[12:32] <jdstrand> zyga: note, my testing was done via terminal cli commands and not things launched from a desktop file, but that shouldn't matter
[12:32] <zyga> jdstrand: I just pushed a little bit of an update that adds some more explanation
[12:32] <jdstrand> zyga: hey :)
[12:32] <zyga> jdstrand: how do you like the -failure test?
[12:34] <zyga> jdstrand: please check the new pair of XXX comments starting at https://github.com/snapcore/snapd/pull/7825/files#diff-61f3c400c3c80345d518c7ff0d0b3953R184
[12:34] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[12:35] <zyga> jdstrand: I will take the deb and play with it on VMs representing each desktop and server
[12:35] <zyga> jdstrand: I also did an experiment to see what would happen to our test suite if this was enabled out of the box, the results were interesting, there were some failures but they are all legitimate change in behavior (we refuse to refresh or install snaps while there are apps running)
[12:35] <jdstrand> zyga: I've not looked at it yet. I've got several meetings this morning but will look at this today. I'll try to peek now real quick
[12:35] <zyga> jdstrand: nothing failed in ways that would not be sensible IMO
[12:36] <zyga> jdstrand: thank you!
[12:36] <jdstrand> zyga: that's cool :)
[12:36] <zyga> jdstrand: just two theories, I'll explore this interactively now
[12:36] <zyga> jdstrand: I _hope_ it will be green and I can merge it
[12:36] <zyga> I have some follow ups to do
[12:37] <jdstrand> zyga: ahhh! you weren't talking about new failures (phew), you were talking about explaining the existing failure
[12:37] <zyga> yes!
[12:37]  * jdstrand gives a sigh of relief
[12:38] <jdstrand> zyga: my whole body tensed up for a second ;)
[12:38] <oSoMoN> pedronis, can you hide/delete an offensive bug comment? https://bugs.launchpad.net/snapd/+bug/1776873/comments/39
[12:38] <mup> Bug #1776873: Whitelisted allowedURLschemes breaks some desktop apps <snapd:Triaged> <chromium-browser (Ubuntu):Confirmed> <https://launchpad.net/bugs/1776873>
[12:39] <pedronis> oSoMoN: not afaik,  mvo do you know ^
[12:40] <jdstrand> zyga: imho, you could land the PR with the cgroup-tracking-failure as a followup. based on what you said about wanting understand all of this before updating features.go for what is supported/not supported at this time, that could also be in the same followup. I'll leave that up to you
[12:40] <jdstrand> but yes, I'll be looking at this today
[12:41] <pedronis> mvo: seems I fixed debian too, the fix is ugly but is like the code already there
[12:41] <mvo> oSoMoN: I'm afaraid not, I guess someone in #launchpad might be able to help
[12:41] <mvo> pedronis: removing files?
[12:41] <pedronis> yes
[12:41] <oSoMoN> pedronis, mvo: I asked there first, and c_j_watson suggested that being the project bug supervisor, you have powers to do that yourself
[12:41] <jdstrand> zyga: Conversation: 201. Commits: 123. Files changed: 25. Impressive! (7825)
[12:41] <mvo> pedronis: it's all because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956783
[12:42] <mvo> oSoMoN: oh, let me try to figure out how then, I never used that feature
[12:42] <oSoMoN> mvo, pedronis is the project bug supervisor, so I guess only him can do that
[12:42] <mvo> oSoMoN: aha, ok - I was wondering, I can't see the right button :)
[12:43]  * zyga runs to check some family hurdle at home
[12:43] <pedronis> mvo: https://paste.ubuntu.com/p/CPvpyJQnjV/ is the diff, good enough?
[12:46] <mvo> pedronis: totally
[12:46] <pedronis> oSoMoN: I don't see any button either
[12:46] <pedronis> I'm maybe looking at the wrong place
[12:46] <mvo> pedronis: push away
[12:46] <oSoMoN> cjwatson, can you advise how to hide a comment for a project bug supervisor? ^
[12:47] <cjwatson> pedronis: There should be a green "Hide" button at the bottom right of the comment
[12:47] <cjwatson> pedronis: Oh, but you need to look at https://bugs.launchpad.net/snapd/+bug/1776873, not on the /comments/39 page
[12:47] <mup> Bug #1776873: Whitelisted allowedURLschemes breaks some desktop apps <snapd:Triaged> <chromium-browser (Ubuntu):Confirmed> <https://launchpad.net/bugs/1776873>
[12:48] <cjwatson> (I'm suggesting that it be hide + explicit warning to user, btw)
[12:48] <pedronis> cjwatson: not seeing green buttons either place
[12:49] <cjwatson> Ugh
[12:49] <cjwatson> Well, if I hide it could you warn them?
[12:49] <cjwatson> Some kind of code of conduct warning
[12:50] <cjwatson> I've hidden it now
[12:50] <pedronis> cjwatson: you mean in the bug comments, or over email? (sorry my brain is very partionated in its capabilities today)
[12:51] <cjwatson> In the bug comments
[12:51] <pedronis> ok
[12:51] <cjwatson> That would be my suggestion anyway, since the bug comment will have been emailed to subscribers
[12:51] <cjwatson> And it's good to be public about what the societal expectations are
[12:53] <jdstrand> mvo: thank you for merging the base policy PR :)
[12:53] <jdstrand> and thanks to all for the reviews :)
[12:54] <mup> PR snapd#8552 opened: cmd/snap-bootstrap: measure epoch and model before unlocking encrypted data <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8552>
[12:56] <jdstrand> mvo: I don't know if you are doing another 2.44 point release (thought I saw that in reference to my syscalls PR), but if so, can you also cherry-pick https://github.com/snapcore/snapd/pull/8544 ?
[12:56] <cmatsuoka> cachio: is the uc20 test working now?
[12:56] <mup> PR #8544: interfaces/firewall-control: allow -legacy and -nft for core20 <Simple 😃> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8544>
[12:56] <mvo> jdstrand: we don't plan another 2.44 but happy to cherrypick just in case
[12:59] <jdstrand> mvo: ack, thanks again :)
[12:59] <cachio> cmatsuoka, I am running right now
[13:00] <pedronis> mvo: I pushed btw
[13:01] <pedronis> mborzecki: thanks, can you mark that PR UC20 and 2.45
[13:01] <mborzecki> ah forgot
[13:06] <abeato> sil2100, hey, I was wondering, do you have an example on how the --cloud-init option in u-i can be used? what would it be used for?
[13:06] <mvo> pedronis: \o/
[13:09] <oSoMoN> cjwatson, pedronis: thanks for handling this
[13:12]  * ijohnson pedronis: sorry I forgot to commit those files, added them to the PR now
[13:19] <mup> PR # opened: snapd#5822, snapd#6258, snapd#7129, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7728, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8123, snapd#8143,
[13:19] <mup> snapd#8247, snapd#8271, snapd#8301, snapd#8317, snapd#8334, snapd#8340, snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8400, snapd#8414, snapd#8424, snapd#8436, snapd#8455, snapd#8464, snapd#8468, snapd#8475, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8528,
[13:19] <mup> snapd#8531, snapd#8532, snapd#8533, snapd#8536, snapd#8537, snapd#8539, snapd#8541, snapd#8547, snapd#8549, snapd#8550, snapd#8551, snapd#8552
[13:19] <mup> Issue # opened: core20#12, core20#32, core20#34, core20#48
[13:19] <mup> PR # opened: core20#11, core20#43, core20#45, core20#46, core20#49
[13:20] <ogra> ah, it isnt only me having issues with github today ...
[13:20]  * ogra hugs mup
[13:26] <stgraber> anyone has an idea of what's going on here? https://discuss.linuxcontainers.org/t/snap-lxd-snap-hooks-configure-snapctl-not-found/7525
[13:30]  * ogra shakes fist towards github and goes to take a break .... too many gateway timeouts :(
[13:33] <ogra> stgraber, smells like a bug in the archlinux package or so ...
[13:43] <mborzecki> stgraber: replied in the snapcraft forum topic
[13:59] <ogra> who is doing the snap translations ? i noticed in focal i actually get german strings but they often look/feel like google translation ones
[13:59] <ogra> s/snap/snapd/
[14:09] <zyga> ogra: anyone can
[14:09] <ogra> heh ... well i was wondring "who does" :)
[14:09] <zyga> there are no curated translations that we merge back to snapd
[14:09] <zyga> ogra: my point is that nobody curates this
[14:10] <ogra> right, so it isnt going through rosetta (launchpad) as all our other translations (which get peer reviews)
[14:10] <ogra> i'm just noticing it shows ...
[14:10] <zyga> I think it does
[14:10] <zyga> but we never merge them to snapd, verify, alter or anything
[14:11] <zyga> we have 0% translations in tree
[14:11] <zyga> but actually
[14:11] <zyga> you gave me a crazy idea
[14:11] <zyga> gettext that google-translates each string
[14:11] <zyga> MASHIN LERNIN ;)
[14:11] <ogra> yeah, that will surely improve the quality !
[14:12] <zyga> and consistency ;)
[14:12] <ogra> but i think it should be a two step thing ... first translate to xhosa ... then to the target language ...
[14:12] <ogra> that definitely gets the funnier outcome
[14:15] <pstolowski> cachio: can you take a look at https://github.com/snapcore/snapd/pull/8549 ?
[14:17] <cachio> pstolowski, sure
[14:19] <zyga> ##[warning]Failed to download action 'https://api.github.com/repos/actions/checkout/tarball/v2'. Error Response status code does not indicate success: 500 (Internal Server Error).
[14:19] <zyga> must be a good day to release
[14:20] <ogra> yeah GH is stuttery today
[14:20] <ogra> it is intermittent though ... so restarting the build/test/whatever eventually works
[14:21] <ogra> i havent seen a 500 yet though ... only lots of 504's
[14:21] <ogra> (GW timeout)
[14:28]  * zyga breaks for some time then
[14:28] <zyga> jdstrand: I have a patch piled that reverses the UUID as you wanted
[14:28] <zyga> jdstrand: but I will not send it to this branch, it's extra huge already
[14:28] <zyga> jdstrand: I'll start piling fixes, tests and stuff into a new one
[14:30] <mup> PR # closed: core#38, core#107, core#108, core#110, core#111
[14:31] <mup> PR # opened: core#38, core#107, core#108, core#110, core#111
[14:35] <pedronis> mvo: can you work more on #8547 or should cmatsuoka pick it up? either way maybe cmatsuoka can review it
[14:36] <mup> PR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
[14:37] <cachio> xnox, I see these errors on uc20 https://paste.ubuntu.com/p/SKBqVNyyMN/
[14:37] <cachio> xnox, lines 693 and 1340
[14:37] <cachio> xnox, it could be related to the removal of the snapd-shutdown helper
[14:38] <cachio> xnox, could you please take a quick look?
[14:38] <jdstrand> zyga: sounds great
[14:41] <mvo> pedronis: I'm not working on it right now, I think you raised some points that still need adressing. I can probably work on those in a couple of minutes, just de-conflicting 8541
[14:44] <mvo> pedronis: either way is fine, I need to take a 15min break now though
[14:45] <cmatsuoka> fyi I just built an image from that branch and partitions are created correctly
[14:45] <xnox> cachio:  they are not errors
[14:45] <xnox> cachio:  it's confirmation that finalrd is doing the shutdown correctly
[14:45] <xnox> cachio:  and that the bad snapd shutdown hook is correctly disabled
[14:46] <cmatsuoka> mvo: and ssh works
[14:47] <cachio> xnox, ok, thanks
[14:53] <cachio> cmatsuoka, I see this message in the log Please enter the recovery key for disk /dev/disk/by-label/ubuntu-data-enc: (press TAB for no echo)
[14:54] <cmatsuoka> cachio: you shouldn't see that, let me try to reproduce here...
[14:55] <pedronis> cmatsuoka: great, please do a review of the PR itself
[14:56] <ijohnson> pedronis: I added a response to your point on my ubootenv PR re Recovery in InstallBootConfig, it does mean something different but we don't currently have a real use case for that yet so I could just drop that tbh
[14:57] <cmatsuoka> pedronis: already did a pass, it seems that there are many things to do to have it done properly but functionally it works, will add some notes there
[14:58] <pedronis> ijohnson: the issue is that afaik we might still have to write a boot.sel or not
[14:58] <pedronis> we don't know, depends what's inside that uboot.env
[14:58] <ijohnson> pedronis: good point, I think that ideally we should still write a boot.sel in this case in addition to the uboot.env from the gadget we install
[14:59] <pedronis> ijohnson: it might be easier if we don't have a use case to return an error for now, and do something when we have a use case
[14:59] <cachio> cmatsuoka, if you run spread -debug google-nested:ubuntu-20.04-64:tests/nested/core20/
[14:59] <cachio> you will see that
[14:59] <ijohnson> pedronis: sure that would be easiest
[14:59] <cachio> once the test fails
[15:00] <ijohnson> pedronis: also I forgot to write this in the PR I think, but we still have a need for the gadget.yaml in the 20 pi snap to install boot.sel onto ubuntu-boot, because otherwise bootloader.Find() in makeBootable20RunMode won't recognize any uboot bootloader on ubuntu-boot
[15:00] <ijohnson> pedronis: I think that's fine, it's pretty similar to what we do for grub too, but it's a bit unexpected / weird given that snapd writes the file for ubuntu-seed, but the gadget has to create the file for ubuntu-boot
[15:00] <ijohnson> pedronis: I wasn't sure how better to handle it though without adding methods to the bootloader interface somehow
[15:00] <pedronis> ijohnson: yes, I think we are a bit carrying on with legacy logic
[15:01] <ijohnson> yeah
[15:01] <pedronis> ijohnson: in a sense we should pick a bootloader kind based on seed and apply it to boot
[15:01] <ijohnson> mmm that's a good idea
[15:01] <pedronis> but it might not be the right time to change
[15:01] <pedronis> I mean, for sure not in that PR
[15:01] <ijohnson> agreed now is not the right time to do this change
[15:02] <ijohnson> pedronis: do you think it's fine for beta to have the gadget snap install boot.sel onto ubuntu-boot ?
[15:03] <pedronis> ijohnson: it's ok, but it sound weird at face value, but let's get everything else working first
[15:03] <ijohnson> ack
[15:08] <cmatsuoka> cachio: running it
[15:08] <cachio> cmatsuoka, nice
[15:08] <cachio> I am having lunch now
[15:08] <cmatsuoka> cachio: ok, I'll leave comments here if I find something
[15:10] <pedronis> ijohnson: I understand the cleanliness of introducing nativeenv.go, but I think it would be maybe quicker to do just have env.go with the interface at the top and trying to keep as much of the rest as possible and textenv and do the splitting in a 2nd PR
[15:10] <ijohnson> pedronis: you mean just puteverything in the same file?
[15:10] <pedronis> ijohnson: no, have two files
[15:10] <pedronis> keep most of env , and Env there
[15:11] <pedronis> have the new stuff in textenv.go
[15:11] <ijohnson> ah ok
[15:11] <ijohnson> sure I can do that, give me a bit though trying to get this pi test running, needs a bit of hand holding
[15:11] <pedronis> ijohnson: at the moment the diff of env.go is horrible, and nativenv.go is kind look I need to review code tha is actually old code
[15:11] <ijohnson> I see
[15:12] <pedronis> ijohnson: in general in this kind of situation is best to either do splitting before (if possible) and/or minimize the diff, and do renames or splits as a separate step
[15:13]  * cachio lunch
[15:18] <mvo> pedronis: when you have a moment, is https://github.com/snapcore/snapd/pull/8547#discussion_r413680649 what you have in mind?
[15:18] <mup> PR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
[15:20] <pedronis> mvo: I would say no
[15:20] <mvo> pedronis: ok, it did not feel right so I wanted to ask, what am I missing ?
[15:20] <mvo> (and sorry to burden you with this :(
[15:20] <pedronis> mvo: have you done more in that PR or just started there?
[15:21] <mvo> pedronis: I updated the other bits, let me push
[15:21] <mvo> pedronis: the other comments where clear, this one I had a bit of trouble
[15:27] <pedronis> mvo: something like this https://paste.ubuntu.com/p/xyRmBhjwrX/  (the other change is optional)
[15:30] <mvo> pedronis: aha, I see. feel free to commit, I have a meeting now, otherwise I will commit when the meeting is done
[15:33] <pedronis> mvo: pushed
[15:34] <mvo> pedronis: thanks!
[15:39] <cmatsuoka> cachio: it failed here in a NOMATCH line in core20/basic/task.yaml (which should now be a not MATCH I believe) but otherwise it seemed to run ok. I'll break for lunch now and bbl
[15:41] <cachio> cmatsuoka, in that case it was fixed with a new pc-kernel or gadget
[15:41] <cachio> cmatsuoka, thanks
[15:52] <pedronis> cmatsuoka: so we should base #8531 on #8547 now, Options should contain directly a Model *asserts.Model ... the command can take a --model <model> and read it
[15:52] <mup> PR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>
[15:52] <mup> PR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
[15:53] <cmatsuoka> pedronis: ack, will do that after lunch
[15:54] <pedronis> cmatsuoka: thank you
[15:55] <pedronis> cmatsuoka: asserts.Decode can be used to make an assertion out of []byte, then you can check the Type() and then cast
[16:12] <mup> PR snapd#8541 closed: devicestate: add support for cloud.cfg.d config from the gadget <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8541>
[16:16] <pedronis> so #8464 failed on core 20 still
[16:16] <mup> PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
[16:18] <pedronis> we are also having failures because of GH atm
[16:22] <mup> PR snapd#8553 opened: github: use "continue-on-error" for the spread-unstable systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/8553>
[16:23] <mvo> zyga: did the bit-cacher got restarted? I guess there were some restarts since this was last installed :/
[16:28] <mup> PR snapd#8549 closed: tests: fix a typo in nested.sh helper <Simple 😃> <Skip spread> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8549>
[16:29] <zyga> mvo: yes, I rebooted the system once since installation
[16:30] <zyga> We maybe basic persistency?
[16:30] <mvo> zyga: maybe, given that the cache fix is on the usptream radar, maybe it's not urgent
[16:31]  * mvo gets dinner - please let me know if there is anything I should merge
[16:31]  * mvo will read backlog
[16:32] <ijohnson> pedronis: I did as requested in 8550 and disabled for now the traditional uboot.env that we don't have clear idea on yet, and I also move nativeenv.go back into env.go
[16:40] <cmatsuoka> pedronis: thanks, will use that
[16:41] <pedronis> ijohnson: did we lose import tests for native ? or am I confused by the diff?
[16:42] <ijohnson> uhh I don't think so? I literally just moved all the stuff in nativeenv.go to the bottom of env.go
[16:42] <ijohnson> let me look again, but to confirm you are looking at the full diff in the github view?
[16:42] <ijohnson> also seems I forgot to update the prepare-image tests in image_test.go, I'm doing that now too
[16:48] <pedronis> ijohnson: there was a thing called Import that seems to be gone
[16:48] <pedronis> tbh it was not used
[16:48] <ijohnson> pedronis: that function is now in textenv.go
[16:48] <ijohnson> sorry maybe I should move that one back to env.go too
[16:48] <pedronis> I don't know
[16:48] <ijohnson> the tests are the only thing that used Import, and I refactored it slightly so that Import is now called ImportTextReader
[16:48] <pedronis> was it a test helper?
[16:49] <ijohnson> yes it's a test helper
[16:49] <ijohnson> well sorry let me clarify
[16:49] <ijohnson> it was a pure test helper and had a separate implementation from everything else
[16:49] <ijohnson> I re-wrote it to share the actual implementation in parseData
[16:49] <pedronis> but it was exported
[16:49] <ijohnson> and now it is used by textEnv
[16:50] <ijohnson> and it is exported in export_test.go now because it's not used directly anywhere other than the tests for ubootenv
[16:51] <pedronis> ijohnson: as far as I can on master is not a test helper, it's an actual method of envs
[16:52] <pedronis> that nothing uses
[16:52] <ijohnson> yes
[16:52] <ijohnson> that's my point is that nothing actually used it outside of tests
[16:52] <pedronis> it's not used by tests
[16:52] <ijohnson> I don't know why it was originally written as a method on env and not just a test helper
[16:52] <pedronis> it's tested by tests
[16:52] <pedronis> on master
[16:52] <pedronis> to me that's two different things
[16:53] <ijohnson> mmm I see your point
[16:53] <ijohnson> I guess I didn't quite grok that, and since nothing actually uses it outside of tests I didn't think it necessary to keep the method around
[16:53] <ijohnson> do you want me to resurrect it as a method in the Env interface?
[16:54] <pedronis> I would like to drop, but maybe somebody has a tool around using it
[16:55] <ijohnson> I'd say let's drop and if someone has a dire need for it, it's easy enough to resurrect
[16:56] <pedronis> that's fine, maybe mvo know more, apparently this all code lived somewehre else
[16:56] <pedronis> and was ported into snapd at some point
[17:02] <ijohnson> right
[17:12] <ijohnson> pedronis: ok sorry that took longer than expected to fix that image test, I was very confused about it, but all clear now
[17:16] <ijohnson> jdstrand: any idea where to put this bug? I don't know where the ubuntu security tips this is referring to comes from tbh https://bugs.launchpad.net/snappy/+bug/1874156
[17:17] <mup> Bug #1874156: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1874156>
[17:18] <cjwatson> https://docs.ubuntu.com/core/en/guides/intro/security
[17:18] <cjwatson> (I just web-searched for some of the quoted text)
[17:19] <ijohnson> ah thanks cjwatson
[17:19] <cjwatson> That links to https://bugs.launchpad.net/snappy/+bugs?field.tag=snap-docs for reporting bugs on the docs
[17:19] <cjwatson> Which is exactly where this bug is :)
[17:19] <ijohnson> haha so it seems I am exactly in the same place to fix this as the reporter
[17:20] <ijohnson> degville: would you know where issues for https://docs.ubuntu.com/core/en/guides/intro/security should get forwarded to?
[17:20] <ijohnson> I feel like this is now on github somewhere iirc
[17:22] <degville> ijohnson: https://github.com/canonical-web-and-design/ubuntu-core-docs/issues
[17:22] <ijohnson> thanks degville!
[17:23] <ijohnson> maybe we should also file an issue there for fixing the "report an issue on the docs" button too
[17:23] <degville> ijohnson: good point.
[17:23] <degville> ijohnson: It's me that will try and fix these things though, as they're the core docs I'm trying to update.
[17:24] <jdstrand> ijohnson: I do and I know where and how to fix it. it is on my todo to fix. feel free to assign to me
[17:24] <ijohnson> degville: right I realized that after looking at the url, I just have never seen the security tips page before so I didn't realize this is part of the core docs :-p
[17:24] <ijohnson> cool, jdstrand I'll assign the LP bug to you
[17:25] <jdstrand> degville: I may ask for review/etc, but I'll take care of it. it should be coming from a forum doc that I wrote
[17:26] <om26er> What are the chances for a snap to be allowed auto-connect permissions for raw-usb interface. It is required by https://e.foundation/ project to flash Android devices and adb-support interface is not sufficient in that case
[17:27] <degville> jdstrand: thank you, that would be a huge help!
[17:28] <pedronis> ijohnson: if you could move back parseData and iterEnv around where they were original it would be best, you can move them in a follow up
[17:28] <ijohnson> pedronis: ok, give me a minute I can do that right now
[17:29] <pedronis> ijohnson: let's also drop Import as discussed
[17:30] <ijohnson> pedronis: do you mean drop importTextReader ?
[17:30] <pedronis> yes
[17:30] <ijohnson> ok
[17:31] <pedronis> the thing that is not quite what it was, and anyway the thing that was wasn't used
[17:31] <pedronis> (or so we hope)
[17:33] <pedronis> ijohnson: and sorry, but my goal is to make reviewing the diff as much as a no-brainer as possible
[17:33] <ijohnson> no problem I understand
[17:36] <zyga> re
[17:38] <ijohnson> pedronis: done (and I even ran the static-checks this time BEFORE I pushed, how good am I?)
[17:38] <pedronis> :)
[17:41] <pedronis> ijohnson: thanks, looking in a sec
[17:45] <pedronis> ijohnson: thanks, I'll do the proper review now, thanks for bearing with me about making the diff small and obvious
[17:45] <ijohnson> no problem, I am about to break for lunch, so be back in a little bit
[18:01] <mup> PR snapcraft#3084 opened: repo: fix for multi-arch virtual-packages <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3084>
[18:08]  * mvo heard his name and wonders if he can be helpful?
[18:11] <mup> PR snapd#8553 closed: github: use "continue-on-error" for the spread-unstable systems <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8553>
[18:16] <mup> PR snapcraft#3085 opened: build providers: dist-upgrade the environment on bootstrap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3085>
[18:19] <pedronis> ijohnson: reviewed
[18:20] <ijohnson> cool let me look
[18:21] <mvo> cachio: I think I have an idea why sbuild fails, testing the fix now
[18:21] <cachio> mvo, great!!
[18:22] <cachio> thanks for digging
[18:50] <cachio> cmatsuoka, can't connect through ssh sometimes to the uc20 vm
[18:51] <cachio> cmatsuoka, you said you had a similar problem right?
[18:51] <cmatsuoka> cachio: yes, but it doesn't seem to be deterministic
[18:51] <cachio> cmatsuoka, right
[18:51] <cachio> same happening here
[18:51] <cmatsuoka> cachio: I saw it happening a few days ago then this morning
[18:51] <cachio> sometimes work sometimes not
[18:52] <cmatsuoka> cachio: did you report it to dimitri?
[18:53] <cachio> cmatsuoka, no
[18:55] <mup> PR snapd#8554 opened: packaging: add "$TAGS" to dh_auto_test for debian packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/8554>
[18:55] <cmatsuoka> cachio: ok, I pinged him
[19:00] <mvo> cachio: the pr 8554 is the one that should fix the nightly sbuild
[19:00] <mup> PR #8554: packaging: add "$TAGS" to dh_auto_test for debian packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/8554>
[19:00] <cmatsuoka> cachio: I just tried to reproduce here but it's starting correctly, if it fails for you try to preserve a log
[19:01] <mvo> happy release day, lot's of 403 from the store it seems :/
[19:02] <zyga> mvo: indeed
[19:03] <zyga> mvo: I'm sure while we are stressed on release features the store team is scrambling to make it all work today :)
[19:07] <mvo> zyga: yeah, it's not meant in a bad way, it just shows how popular ubuntu is
[19:08] <zyga> happy release day mvo :)
[19:08] <zyga> remember command-not-found?
[19:08] <zyga> long way eh?
[19:16] <cmatsuoka> good news everyone! it seems that #8547 + #8531 + #8552 is working end-to-end
[19:16] <mup> PR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
[19:16] <mup> PR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>
[19:16] <mup> PR #8552: cmd/snap-bootstrap: measure epoch and model before unlocking encrypted data <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8552>
[19:18]  * cmatsuoka is really not used to things working that easily so he will test it again
[19:23] <oSoMoN> pedronis, another candidate for the "hide comment" feature: https://bugs.launchpad.net/snapd/+bug/1776873/comments/43
[19:23] <mup> Bug #1776873: Whitelisted allowedURLschemes breaks some desktop apps <snapd:Triaged by pedronis> <chromium-browser (Ubuntu):Confirmed> <https://launchpad.net/bugs/1776873>
[19:24] <mvo> zyga: totally remember it, I still maintain the thing that build the db :)
[19:25] <pedronis> cmatsuoka: sounds great news though :) , let me know when I should re-review 8531
[19:26] <pedronis> 8552 needs tweaks but is good to know things work together
[19:26] <cmatsuoka> pedronis: will push soon, I'm just running a test commenting out the model measurement to make sure it's working :)
[19:26] <mvo> pedronis: can I land 8547 to unblock people? just looking at the failures, looks like it's a bad case of "search" failing with 403, nothing real
[19:27] <pedronis> mvo: I gave my +1 no? or you asking if you can override ?
[19:27] <mvo> pedronis: yeah, if you are ok with landing it, I take that as a yes
[19:27] <mvo> pedronis: I review the failures, so far all "failing search"
[19:27] <pedronis> mvo: if you looked at the errors and seem unrelated, yes happy for it to land
[19:29] <xnox> cachio:  cmatsuoka: please file bug reports on github.com/snapcore/core20
[19:31] <mup> PR snapd#8547 closed: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8547>
[19:33] <cmatsuoka> pedronis: pushed to 8531, with master already merged in
[19:34] <pedronis> cmatsuoka: thanks, will look in a little bits
[19:35] <cmatsuoka> pedronis: thanks
[19:38] <cmatsuoka> cachio: could you file a bug for xnox? I'm not being able to reproduce the problem here
[19:40]  * cmatsuoka will take a 30min break
[19:40] <mup> PR snapcraft#3085 closed: build providers: dist-upgrade the environment on bootstrap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3085>
[19:43] <mvo> fwiw, I updated 8551
[19:43] <mvo> (but not in the critical path)
[19:47] <pedronis> cmatsuoka: reviewed
[19:48] <pedronis> mvo: yea, we should land 8531 before 8551
[19:48] <pedronis> mvo: if you are still around can you look also at 8531 ?
[19:49] <pedronis> ah, actually you reviewed it already
[19:53] <mvo> pedronis: yeah, your input on my points would be great
[19:53] <mvo> pedronis: maybe I went over-the-top a bit
[19:53] <mvo> (if so, appologizes)
[19:53] <pedronis> mvo: 8531 ?
[19:53] <pedronis> or somewhere else?
[19:53] <mvo> pedronis: yes, the question about if we want cmd_create_partitions changes and if we do I think we want to add them to the spread tests, no?
[19:55] <pedronis> mvo: we can pass a model in the spread test, it will mostly test that is accepted and nothing explodes
[19:55] <pedronis> but the test doesn't really check the policy as such because there is no unsealing
[19:55] <pedronis> mvo: the e-2-e uc20 tests with secboot, tpm will test this
[19:56] <pedronis> but I don't think we have one yet
[19:57] <mvo> ok
[19:57] <pedronis> mvo: sorry, that was vague
[19:57] <pedronis> mvo: I think we want the spread test mostly because the coverage of bootstrap is very low atm
[19:58] <pedronis> and because it tests actual partition level stuff
[19:58] <pedronis> not so much sealing details
[19:58] <mvo> pedronis: ok, then we should probably update it, it's not updated to test the model yet
[19:58] <pedronis> snap model --assertion > model  and use that I suppose
[19:59] <pedronis> or whatever way works to get a model really
[19:59] <mvo> ok
[19:59]  * mvo looks at this
[19:59] <pedronis> mvo: ah, no, we need a model with a grade
[19:59] <pedronis> maybe
[19:59] <pedronis> should work without but maybe saner with one that has grade
[20:00]  * pedronis break
[20:01] <cmatsuoka> pedronis, mvo: thanks for the review, I'll check/fix
[20:01] <mvo> cmatsuoka: ok, let me quickly push my first tiny tweak
[20:02] <cmatsuoka> mvo: sure
[20:02] <mvo> cmatsuoka: I will leave the other bits to you then :) sorry for being pushy. once the spread bits are added I will updated 8551 but it's not in the critical path
[20:02] <mvo> cmatsuoka: done, it's all yours again :)
[20:03] <cmatsuoka> mvo: thanks!
[20:03] <cmatsuoka> mvo: and thanks for 8551 too, it will make things much cleaner
[20:04] <mvo> cmatsuoka: thank you
[20:12] <mvo> cmatsuoka: actually, don't worry about the spread test in 8531, just fix the cosmetic bits from samuele, we can add the spread thing in 8551
[20:12]  * mvo takes a break now too
[20:12] <mvo> cmatsuoka: unless you have it already or it's almost done or trivail etc :)
[20:13] <pedronis> mvo: it's tests/nested/manual/uc20-create-partitions-encrypt
[20:13] <cmatsuoka> mvo: I only have the cosmetic bits so I'll stop there
[20:14] <pedronis> cmatsuoka: also it's still marked draft
[20:14] <pedronis> you should switch that
[20:14] <cmatsuoka> pedronis: will unmark it, I forgot that, thanks
[20:14] <pedronis> np
[20:15] <mvo> pedronis: yeah, I will add the test as part of 8551 in my morning
[20:15]  * mvo will stay around a bit to help landing 8531
[20:19] <ijohnson> pedronis: the ubootenv PR is ready again with your comments addressed, and I confirmed that it now works properly on the pi
[20:20] <ijohnson> pedronis: I didn't go through the full battery of trying failing kernel snap upgrades etc. but I was able to upgrade the kernel perfectly fine
[20:21] <ijohnson> pedronis: the one thing that I'm just now realizing however is that we need to truncate the boot.sel file when we write it since it could be smaller (and in practice it will end up being smaller after a successful upgrade), which it seems like is less than ideal for robustness against fs corruption
[20:22] <cmatsuoka> mvo: pushed
[20:58] <pedronis> ijohnson: yes, any suggestion?
[20:59] <ijohnson> pedronis: well tbh I'm starting to think maybe we should just use the normal native uboot format instead of the text one precisely because it's fixed size :-/
[20:59] <ijohnson> pedronis: the other thing we could do is pad the file with newlines or whitespace, as the parser currently ignores empty lines without any flags
[21:00] <pedronis> ijohnson: is that true for uboot itself though?
[21:00] <ijohnson> pedronis: mmm good point I could test it later tonight
[21:01] <ijohnson> I need to step out shortly to go get groceries before the store closes
[21:01] <pedronis> ijohnson: anyway,  can we specify a size for the native format? like 4096 instead of 128k , is the 128k only for the main uboot.env ?
[21:02] <ijohnson> pedronis: yes 128k is only for the main uboot.env, this other one could be whatever size we want, as long as it's not _too_ big for some definition of too big
[21:02] <ijohnson> but I think the "too big" comment is like in megabytes
[21:02] <mvo> +1
[21:02] <pedronis> ijohnson: I suppose for this dave's script just need small tweaks ?
[21:03] <ijohnson> pedronis: yes it would just be like 1-2 lines change to not drop the \0 anymore, otherwise the boot.scr looks exactly the same cause it's the same commands afaict
[21:03] <pedronis> ijohnson: what are the -t on env import ?
[21:07] <ijohnson> pedronis: I can't seem to find exactly what that flag does, waveform what does the `-t` flag do for `env import` ?
[21:07] <ijohnson> oh he's not here
[21:08] <pedronis> it's quite late for him, I wonder if it means -t"ext"
[21:08] <pedronis> or something else
[21:09] <ijohnson> pedronis: I was just talking to him in the other channel
[21:09] <ijohnson> I don't think it's ext format because the fs isn't ext
[21:10] <pedronis> ijohnson: no, I mean -t as contraction for -text
[21:10] <ijohnson> ah could be ys
[21:10] <ijohnson> *yes
[21:10] <ijohnson> this is all the usage command says: `env import [-d] [-t [-r] | -b | -c] addr [size] [var ...] - import environment`
[21:10]  * mvo really needs to leave, I will land 8531 in my morning
[21:12] <pedronis> ijohnson: anyway it also means we don't need to support text format, which maybe is a plus
[21:12] <pedronis> (less code)
[21:13] <pedronis> bit of a roundabout adventure
[21:14] <ijohnson> pedronis indeed it is a bit of a circular adventure
[21:14] <ijohnson> It would be a lot less code however that we need to merge now
[21:15] <pedronis> ijohnson: yes, I said this: (less code)
[21:15] <ijohnson> I really need to get to the store now but I will start early tomorrow again if you want to discuss options
[21:16] <ijohnson> A bit sad we probably won't be able to land everything today and build tomorrow but oh well
[21:16] <ijohnson> Maybe builds can happen over the weekend
[21:16] <ijohnson> If we land tomorrow that is
[21:17] <ijohnson> I'll try to open a branch later tonight that does everything with native and maybe you and mvo can pick what to do tomorrow
[21:55] <mup> PR snapcraft#3084 closed: repo: fix for multi-arch virtual-packages <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3084>
[22:17] <mup> Issue core20#50 opened: Ssh server fails to start after core snap refresh <Created by cmatsuoka> <https://github.com/snapcore/core20/issue/50>


[02:41] <darkxst> jbicha, what are your thoughts on the packagekit stuff? i.e. should we fix it or just revert to standard ubuntu update stack
[02:44] <jbicha> well like I said for bug 1071008 I'm not sure about how fix the updates problem yet
[02:44] <jbicha> Wheezy is shipping gpk by default too though
[02:45] <darkxst> I think can fix the automatic updates, but not sure about dist upgrades
[02:45] <jbicha> yeah I didn't know a good way to test dist-upgrades until raring got going
[02:46] <darkxst> I think we can't do dist-upgrades at all until we are an official flavour though
[02:46] <jbicha> we could have people upgrade from the command line or we could include update-manager
[02:47] <jbicha> we need update-notifier for apport to work properly but unfortunately update-notifier depends on update-manager in quantal
[02:47] <darkxst> anyway I think gnome-software-manager is pretty hopeless
[02:47] <jbicha> I'd prefer to use GNOME's tools if they work close enough
[02:48] <jbicha> I've got a patch for https://bugzilla.gnome.org/show_bug.cgi?id=682696 but that's a raring fix
[02:49] <jbicha> people don't read every line in the release notes and can't figure out how to install updates
[02:50] <darkxst> well people don't read until they have a problem, and by then they have probably forgotten about the release notes
[02:51] <jbicha> gnome-packagekit is in "core GNOME" so we kinda have to ship it http://git.gnome.org/browse/jhbuild/plain/modulesets/gnome-suites-core-3.6.modules
[02:52] <jbicha> but then again so is Epiphany and many GNOME distros don't include it by default
[02:53] <darkxst> but that is the dbus stuff
[02:53] <darkxst> (gnome-packagekit)
[02:53] <jbicha> the way I see it, if something is a 50/50 decision then we'll go with the GNOME choice
[02:54] <jbicha> but I'm not the only one who decides the direction of this project
[02:55] <darkxst> ubuntu patch g-c-c with a hard link to update manager
[02:56] <darkxst> and I havent looked at the source, but pretty certain software properties is hardcoded against update-manger
[02:57] <jbicha> I think the g-c-c patch is only for the Details panel but I think it's rather uncommon that people look there for software updates
[02:57] <jbicha> we had to include software properties for quantal because that's where Additional Drivers moved, but gpk has its own config dialog
[02:58] <darkxst> gpk-prefs on ubuntu has no update tab
[02:59] <jbicha> we probably need to get update-notifier to Ubuntu GNOME users on quantal
[03:00] <jbicha> I don't know what the side effects of that would be
[03:00] <darkxst> gpk-prefs is also set to NoDisplay also
[03:01] <jbicha> yeah, I'm not so sure that those changes were a good idea http://git.gnome.org/browse/gnome-packagekit/commit/?id=3c7585
[03:01] <jbicha> it definitely was bad without adding the keywords "breadcrumbs" so that people would know where stuff went
[03:02] <darkxst> gpk-prefs, not gpk-update-viewer
[03:02] <jbicha> yeah, that was the next commit
[03:09] <jbicha> maybe Debian will revert the NoDisplay changes and then we can just sync from Debian...
[03:10] <darkxst> how about we swap out gnome-update-viewer with update-manager
[03:11] <darkxst> and a small patch against gnome-software-manager menu to launch update-manager instead
[03:11] <jbicha> we could add a dependency on update-manager to ubuntu-gnome-desktop for quantal
[03:11] <jbicha> no I don't want to patch that
[03:12] <darkxst> well its better than having duplicated prefs tools
[03:13] <darkxst> so far we have GOA/UOA, software-prefs/gpk-prefs
[03:13] <darkxst> and I suppose there could be others
[03:13] <jbicha> I don't want to patch that for quantal because I'm not convinced update-manager is what we want to ship for raring or sparky
[03:15] <darkxst> and I don't want to see what happens when we semi-invent our own dist-upgrade process
[03:15] <jbicha> do-release-upgrade works fine
[03:16] <jbicha> update-notifier might take care of that; I need to look into splitting update-notifier away from update-manager
[03:20] <jbicha> so the updater is one question; the software installer is the other
[03:21] <darkxst> yeh, they are basically independant from my quick look
[03:21] <jbicha> gpk is better than I remember it being; and someday they're supposed to be doing their fancy overhaul to make it more directly competitive with USC
[03:21] <darkxst> really? I nearly cry every time I have to use it
[03:22] <jbicha> I think Synaptic is out of the question; we should stick with USC or Software
[03:22] <darkxst> I would probably take aptitude or even dselect over the gpk one
[03:23] <darkxst> USC will never *fit* in a gnome-ish distro
[03:23] <jbicha> but think, if you improve gpk then you help virtually every GNOME distro
[03:24] <darkxst> not me, programmers don't make good UI's last time I checked
[03:25] <jbicha> USC includes screenshots, ratings and reviews, paid app support, and even support for -backports
[03:26] <darkxst> yeh I think USC is awesome for end (non-technical) users, but the only time I use it is to sync package lists to U1
[03:26] <darkxst> oh and the odd humble bundle
[03:27] <darkxst> I suppose we could re-skin it, to fit. if/when we have a design team atleast..
[03:28] <jbicha> USC has got too much attention from the designers though, custom widgets & webkit
[03:29] <darkxst> well I dont know what designers do
[03:30] <jbicha> at least it's not as bad as the Ubuntu One design :)
[03:31] <jbicha> I filed some specific design bugs for U1 right after the Qt switch that have been basically ignored
[03:33] <darkxst> yeh its pretty bad, but I am mostly dependant on dropbox here...
[03:34] <darkxst> and I gave up submitting patches against core ubuntu stuff...
[03:35] <darkxst> trivial bug fixes would just be ignored or otherwise marked invalid
[04:43] <darkxst> everaldo, how did you go with the 'participating' article?
[04:47] <everaldo> darkxst, hey :)
[04:47] <darkxst> hey
[04:47] <everaldo> darkxst, writing in my language...
[04:47] <everaldo> I think that I will have it on english tomorow night
[04:47] <everaldo> I mean, 18 hours from now ;-)
[04:48] <darkxst> haha ok, I dont understand your language!
[04:48] <everaldo> to be honest, most people here don't understand a "good" portuguese too :-)
[04:50] <everaldo> darkxst, do we have a place and a domain if we found someone to make us a website?
[04:50] <darkxst> well we have http://gnomebuntu.org/
[04:51] <darkxst> not sure we can really use that domain though
[04:51] <darkxst> might have to register something else (gnome don't want us to mash their trademarks)
[04:52] <everaldo> darkxst, they explicity told us that?
[04:52] <darkxst> everaldo, yes
[04:52] <everaldo> oh, did not know that
[04:53] <darkxst> well they said would need board approval, not actually sure if we asked for that
[04:53] <everaldo> I man, my understand of their guidelines is that we can use "gnome" if we want to spread gnome
[04:53] <everaldo> so, maybe we can ask then
[04:53] <darkxst> yeh we can use gnome
[04:53] <darkxst> but not mashed words like gnomebuntu
[04:54] <darkxst> gnome <space> ubuntu
[04:54] <darkxst> is ok, I believe
[04:54] <everaldo> did you think that gubuntu is bad just because theres goobuntu ?
[04:54] <everaldo> I mean, it is just a internal google version
[04:54] <everaldo> that nobody outside of Google uses
[04:55] <darkxst> lol, nobody outside of google even knows about
[04:55] <darkxst> Gubuntu would be the obvious chouce
[04:55] <darkxst> but that said I do like ubuntu GNOME edition
[04:55] <everaldo> I really like the idea of use gubuntu
[04:56] <everaldo> and we don't even need to care about gnome trademarks
[04:57] <darkxst> yeh I don't really get the whole fuss over that
[04:57] <darkxst> i would thing Gubuntu be pronoucned with a hard G
[04:57] <darkxst> Goobuntu with a soft G
[04:58] <everaldo> exactly
[04:58] <everaldo> and the owner of gubuntu.org is<EMAIL_ADDRESS>[04:59] <darkxst> who is that?
[04:59] <everaldo> don't know but seaching on google looks to be a postgres/debian/python guy
[05:00] <everaldo> so, we will probably can get success to have his domain
[05:00] <everaldo> Created On:06-Nov-2010 12:30:01 UTC
[05:00] <everaldo> Last Updated On:31-Oct-2011 22:28:55 UTC
[05:00] <everaldo> Expiration Date:06-Nov-2012 12:30:01 UTC
[05:00] <everaldo> and he is not using it
[05:00] <everaldo> let me send him a mail
[05:01] <darkxst> lol, I have a bad focus bug again... can really check much!
[05:02] <everaldo> our bug man!
[05:02] <everaldo> bugman...that sounds nice
[05:03] <darkxst> lol, no one will want a distro with 'bug' in the name
[05:03] <everaldo> yeah, and it also looks like a porn actor name :(
[05:05] <everaldo> darkxst, is this ok?
[05:05] <everaldo> "My name is Everaldo and I am one of the guys working on GNOME based variation of Ubuntu. We just want to know if you are willing to provide us the domain gubuntu.org and in which terms."
[05:07] <darkxst> everaldo, I would wait until we decide if we actually want it!
[05:07] <everaldo> darkxst, we are just asking
[05:08] <everaldo> it is much better to know before decide right?
[05:08] <darkxst> but at this point we are not actually going to use gubuntu, perhaps we should contact google!
[05:09] <everaldo> humm
[05:09] <everaldo> ubuntu-ge.org  (maybe gnome edition)
[05:09] <everaldo> the owner is... Canonical :)
[05:10] <everaldo> I like how GNOME Edition sounds
[05:10] <darkxst> but I have no contacts a google apart from a few guts that work in maps at Sydney
[05:10] <darkxst> s/guts/guys/
[05:10] <everaldo> darkxst, ask then
[05:10] <everaldo> them
[05:10] <darkxst> they won't be able to help
[05:11] <everaldo> Domain ID:D105610408-LROR
[05:11] <everaldo> Domain Name:UBUNTU-GE.ORG
[05:11] <everaldo> Created On:21-Jan-2005 12:57:38 UTC
[05:11] <everaldo> Last Updated On:24-May-2011 00:26:11 UTC
[05:11] <everaldo> Expiration Date:21-Jan-2014 12:57:38 UTC
[05:11] <darkxst> perhaps thats a country code
[05:11] <darkxst> ???
[05:12] <everaldo> don't know
[05:12] <everaldo> jbicha just sugested "Ubuntu GNOME Edition"
[05:12] <everaldo> looks nice... but again we need to use "GNOME" word
[05:13] <darkxst> that is fine I believe
[05:13] <darkxst> GE Georgia (Republic Of)
[05:20] <everaldo> hatochna.org is available
[05:21] <everaldo> HArd TO CHoose a NAme
[05:21] <everaldo> :D
[05:22] <darkxst> I think we have to have buntu if we want to be official flavour
[05:22] <everaldo> yes, I was just kiding
[05:24] <everaldo> fubunutu, nubuntu and mubuntu... all registered
[05:24] <everaldo> mubuntu owner is also canonical
[05:25] <everaldo> obuntu.org is available
[05:25] <everaldo> gnOme
[05:26] <everaldo> darkxst, whats about obuntu.org ?
[05:26] <darkxst> seems a bit unrelated
[05:27] <everaldo> well, the only really related good name is gubuntu :(
[05:29] <everaldo> gnubuntu is also nice but... you know... gnu
[05:29] <darkxst> yeh like, we need stallman on our case!
[05:31] <darkxst> uge.org
[05:32] <everaldo> I like it
[05:32] <everaldo> but is already registered
[05:32] <everaldo> and it is used since 2002
[05:32] <everaldo> oh, "this domain is for sale"
[05:32] <everaldo> 35% off :)
[05:33] <darkxst> 35% off what? some rip off scammer
[05:33] <darkxst> ?
[05:34] <everaldo> hahaha
[05:34] <everaldo> Buy this great domain today for only $9,888.00 (USD)!..
[05:36] <darkxst> seems like uge.fm or uge.net.au
[05:36] <darkxst> is all thats available?
[05:37] <everaldo> yes
[05:38] <everaldo> ok, go sleep a little
[05:38] <darkxst> net au probably has rules
[05:38] <everaldo> be back later
[05:38] <darkxst> atleast had to provide an ABN for org.au adresses
[05:38] <everaldo> yes
[05:39] <everaldo> bye
[05:39] <darkxst> I suppose canoconical might have a ABN


[01:51] <geofft> So I'm trying to run upstart in an schroot on a non-upstart (Debian) system
[01:51] <geofft> is there a documented right way to make this work?
[01:52] <geofft> well s/documented/recommended/
[01:55] <geofft> should I be using LXC or somesuch to force this into being pid 1?
[19:55] <jsonperl> im trying to run upstart on debian, just uninstalled sysvinit and installed upstart and seems to work fine
[19:56] <jsonperl> but i can seem to tell my script to run only after the network is up
[19:56] <jsonperl> "start on local-filesystems and net-device-up IFACE!=lo" doesn't seem to work
[19:56] <jsonperl> im assuming because networking etc… are all controlled by old sysv init scripts
[19:56] <jsonperl> any suggestions?
[20:18] <jsonperl> anyone?
[22:19] <jsonperl> anyone around?
[22:20] <jsonperl> trying to figure out a debian / upstart boot issue


[14:52] <ssarah> hei guys
[14:53] <ssarah> i want to ask, i wana use upstart instead of node forever. How can i make it that upstart only tries to restart a process a number of times before calling for support?
[14:58] <ssarah> anyone? =O
[17:06] <slangasek> ssarah: what do you mean by "calling for support"?
[17:07] <slangasek> you can use the "respawn limit" command to control how many times upstart will retry a failing process; but I'm not sure if that's what you're asking for
[18:01] <ssarah> slangasek: i mean, that after failing for several times, it does a custom command
[18:02] <ssarah> get it? :)
[18:02] <slangasek> ok
[18:02] <slangasek> upstart is certainly flexible enough that this should be possible, but I can't point to a ready-made example of someone doing this before
[18:03] <slangasek> in fact I think you probably would need to keep a counter, outside of upstart itself, unless the failures are immediate and could be done through 'respawn limit'
[18:12] <xnox> ssarah: i'd recommend use existing monitoring to monitor that service is up, when upstart gives up restarting it the status will change to "stop/waiting" and your monitoring system (nagios, check-mk, etc) can take appropriate action for automated recovery and/or further escalation.
[18:12] <xnox> ssarah: at least, in my previous sys-admin days that's what we did. Since nagios already does smart escalation notification and has appropriate means to encode shifts and rotas.
[18:13] <ssarah> xnox: what status changes to "stop/waiting"
[18:13] <ssarah> ?
[18:17] <xnox> ssarah: of your job. If you start it, it becomes "$ status your-job" will say start/running. And would stay like that, and respawned as needed.
[18:18] <xnox> ssarah: when it fails permamently, it will change status to "$ status your-job" will become "stop/waiting", and thus your nagios monitoring can be checking that.
[18:19] <ssarah> im sorry if this sounds too basic but that variable is something i can see where?
[18:30] <xnox> ssarah: type on the command line: $ sudo status tty2
[18:30] <xnox> ssarah: $ sudo stop tty2
[18:30] <xnox> ssarah: $ sudo status tty2
[18:30] <xnox> ssarah: $ sudo start tty2
[18:30] <xnox> ssarah: $ sudo status tty2
[18:30] <xnox> ssarah: $ cat /etc/init/tty2.conf
[18:31] <xnox> ssarah: for more about jobs, their states, what states they transition through and how to control/inspect/observe that see http://upstart.ubuntu.com/cookbook/
[18:31] <xnox> ssarah: for more control you can add your custom jobs, or e.g. monitor signals, events and notifications on the DBUS interface