[06:50] <Dlareh> 'lo everyone, this a decent place to ask laptop buying advice?  I got a thinkpad configured: http://bayimg.com/image/fakjmaabc.jpg ... which I'm serously considering buying right now...
[06:51] <Dlareh> it has an Nvidia 9300M, and one particular thing I'd like to do is be able to play some relatively simple games like NWN2 and CIV IV under WINE.  But I'll be doing a lot of general-purpose work-and-school-related stuff as well, of course...so just looking for an overall good deal
[06:51] <Dlareh> I'm rather fond of thinkpads' sturdy keyboards and the iconic red trackpoint, but...any alternative suggestions?
[08:07] <landley> dlareh: I have one of the Dells that came preinstalled with ubuntu, and have been fairly happy with it.
[08:07] <landley> Unfortunately, Dell laid off around 5000 people over the past month.
[08:07] <Dlareh> what're the graphics on that system?
[08:07] <landley> Buying the extended warantee might not be the best move.
[08:07] <landley> Intel 945 I think.
[08:07] <landley> The new intel chip that the hired Keith Packard to write open source drivers for.
[08:08] <landley> (Where "new" hear is "last year". :)
[08:08] <Dlareh> hehe, well I don't think it's in the same league as the nvidia 9300m
[08:08] <landley> http://www.dell.com/content/topics/segtopic.aspx/linux_3x?c=us&cs=19&l=en&s=dhs
[08:09] <landley> Dlareh: A) nvidia is the only remaining 3D vendor to have closed source drivers.
[08:09] <landley> B) the strategy going forward for both Intel and AMD is to integrate 3D on the die with the processor.
[08:09] <landley> You know how everything's gone dual core?
[08:09] <landley> And they'd like to go quad core but most software won't take advantage of it?
[08:10] <landley> Well putting 3D acceleration on the die along with a couple cores is something most modern software _will_ take advantage of.
[08:10] <landley> It also means you can use 256 megs or so of L2 cache as texture memory shared with the CPU.
[08:10] <landley> The result is _fast_.
[08:10] <Dlareh> cool, this dell has an 8400M at a similar price...
[08:10] <landley> And it leaves nvidia with nowhere to go.
[08:10] <landley> They're trying to retreat into physics engines, but so far I haven't heard of anybody biting...
[08:11] <Dlareh> well, that's the future, right?
[08:11] <Dlareh> I'm looking for something I can buy before September ; )
[08:12] <landley> *shrug*  I tend to do new research when I need a new laptop.
[08:13] <landley> This one hasn't died yet, although an equivalent replacement (with twice the ram) is now about $550.
[08:13] <landley> The 3D is good enough to play world of warcraft and watch dvds, that's all I'm really looking for.
[08:13] <Dlareh> So I priced a dell xps m1330 with 4gb of ram for $1300
[08:14] <Dlareh> that's about the same as the thinkpad SL500 would cost once I add a 2gb stick to make it 3gb total
[08:14] <Dlareh> so it's comparable...
[08:14] <landley> Thinkpads are traditionally more durable.
[08:15] <Dlareh> one comes with ubuntu pre-installed...but I'm not sure how this dell keyboad compares, and doesn't have a trackpoint
[08:15] <landley> Although the failure mode of all my laptops so far has been "cat hair in keyboard" or "hard drive" or some such.
[08:15] <Dlareh> yeah, my last laptop was an x40, I loved its durability...
[08:15] <Dlareh> I put it through hell, finally crapped out on me a few months ago
[08:15] <landley> I killed a thinkpad by running it over with my car, their durability has limits.
[08:15] <Dlareh> lol, well I didn't quite do that...just treated it rough : )
[08:15] <landley> Non-thinkpad trackpoints can be a bit hard to come by, true.
[08:15] <landley> Touch pads are teh suck, and in many ways dell specializes in teh suck.
[08:16] <landley> The dell systems are a nice option to be aware of.  The tiny little part of Dell that's aware Linux exists does a good job supporting it.
[08:16] <landley> The rest of Dell is going down with the microsoft ship, and going out of business fairly quickly.
[08:17] <landley> As I said, 5000 layoffs in the past 2 weeks.  (i live in austin.)
[08:17] <landley> You'll notice that the main dell.com website does not mention dell.com/linux in any way.
[08:17] <Dlareh> going out of business? eh...downsizing isn't "out of business" ...
[08:18] <Dlareh> economy as a whole is slow, but I'm pretty sure dell is here to stay as a top tier OEM in terms of volume...
[08:18] <landley> When I say "going out of business" I mean the entire company is paralyzed, management is distracted by an SEC investigation, Apple's eating them alive...
[08:18] <landley> The layoffs are just a symptom.
[08:18] <landley> Dell was #1.  They're now #2 and next quarter may be #3.
[08:19] <Dlareh> I don't like apple keyboards at all
[08:19] <landley> (I forget if that's unit volume or dollars, I'd have to look it up...)
[08:19] <Dlareh> love the thinkpad ones...which is why I'm leaning towards the SL500
[08:19] <landley> Go for it.
[08:20] <landley> Keyboard/mouse/screen comfort are almost as important as the rest of the laptop combined.
[08:20] <landley> The processor/3d/ram/disk/memory are all commodity components.
[08:20] <landley> You get about the same stuff from each vendor on those fronts.
[08:20] <landley> None of 'em can write a bios to save their lives anymore...
[08:20] <landley> The smart ones are using open bios or whatever that "boot straight into linux, hand off to the next OS" thing is called.  I forget...
[08:42] <Dlareh> Hah, the network card on that XPS is only 10/100 ....welcome to 4 years ago, dell....
[09:00] <landley> My laptop has gigabit, and it's a year old dell from the same page...
[09:00] <Dlareh> the inspiron?
[09:01] <Dlareh> well the configured XPS just says "10/100"
[09:02] <landley> inspiron E1505.
[16:58] <Rigolo> good afternoon ....
[17:00] <Rigolo> does Ubuntu Mobile also work on generic x86 low powered (300Mhz P1) hardware? I have a Fujitsu lifebook B112 that I am trying to bring back to life
[17:27] <ian_brasil> Rigolo: did you see this https://wiki.ubuntu.com/CreatingAGenerici386PlaformForMIC ?
[17:27] <Rigolo> not yet ... lookin at it now
[17:30] <Rigolo> mmm looks interesting ... but why are these not standard in the Image Creator ... it is documented how to do it .. :-)
[17:31] <ian_brasil> because that is not the focus for the Image Creator
[17:32] <Rigolo> I see, just read the mailing list posts ...
[17:32] <Rigolo> well, here is an other project on my list then :-)
[17:33] <ian_brasil> I imagine the guys were pretty happy someone hacked the MIC for i386...if you have a go with this I would be interested in the results
[17:33] <Rigolo> would be cool if I can use this nice little notebook again with some nice GUI :-)
[17:34] <Rigolo> well, my "TODO" list is getting largeer each day ... first priority is getting my mythtv dvb-c backend up and running correctly with my cable provider ...
[17:34] <Rigolo> that will give me some extra room to play with other things ... like this
[17:35] <ian_brasil> OK, cool
[17:35] <Rigolo> saying this .. I hear it is time for me to cook dinner .. :-)
[17:35] <ian_brasil> good luck ;)
[17:36] <Rigolo> well, it is not so much luck ... I like cooking .. and the weekends are for me, the weekdays for my GF
[17:38] <Rigolo> today it is chicken teriyaki (http://www.cooks.com/rec/search/0,1-0,chicken_teriyaki,FF.html)
[18:12] <Alibb> hi there, is there a devlopment testing on Intel Xscale device of Ubuntu-mobile ?


[04:38] <mup> PR snapd#9299 closed: tests/core/uc20-recovery: fix check for at least specific calls to mock-shutdown <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9299>
[05:34] <mborzecki> morning
[05:56] <mvo> good morning mb
[05:56] <mvo> mborzecki: good morning
[06:06] <mborzecki> mvo: hey
[06:06] <mborzecki> mvo: i see the PRs have landed mostly, and claudio updated #9300
[06:06] <mup> PR #9300: boot: build bootchains data for sealing <Run nested> <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9300>
[06:07] <mvo> mborzecki: yeah
[06:08] <mvo> mborzecki: that's great, so just one more to go, right?
[06:10] <mborzecki> hopefully ;)
[06:11] <mvo> haha
[06:11] <mvo> yes
[06:24] <mup> PR snapd#9310 opened: tests: remove "set -e" from function only shell libs <Created by mvo5> <https://github.com/snapcore/snapd/pull/9310>
[06:56] <zyga-kaveri> good morning
[06:56] <zyga-kaveri> starting early although I'm still pretty sleepy
[06:56] <zyga-kaveri> today is a strong coffee day
[06:57] <mvo> good morning zyga-kaveri
[06:57] <mvo> and good morning pstolowski
[06:57] <zyga-kaveri> pstolowski: hey :)
[06:57] <pstolowski> hey, good morning!
[06:57] <zyga-kaveri> pstolowski: are you by any chance using vscode?
[06:58] <pstolowski> zyga-kaveri: yes
[06:58] <zyga-kaveri> pstolowski: I would like to try a code sharing session sometime today
[06:58] <pstolowski> zyga-kaveri: sure
[06:58] <zyga-kaveri> I have a question and I wanted to check how this works compared to screen sharing
[06:58] <zyga-kaveri> but please let me wake up first
[07:02] <zyga-kaveri> pstolowski: try https://prod.liveshare.vsengsaas.visualstudio.com/join?D184D6AF59242DB6AAB93D1D2585F4E2A08E
[07:04] <mborzecki> zyga-kaveri: pstolowski: hey
[07:05] <zyga-kaveri> hey :)
[07:05] <mborzecki> zyga-kaveri: hm interesting, i joined with a browser(?!)
[07:05] <zyga-kaveri> mborzecki: cool
[07:05] <zyga-kaveri> mborzecki: it's pretty neat
[07:05] <zyga-kaveri> did you have to log in?
[07:05] <zyga-kaveri> I've installed the audio sharing extension as well
[07:05] <mborzecki> zyga-kaveri: feels like it's pulling vs into firefox atm
[07:06] <zyga-kaveri> so I could talk to you if you did the same
[07:06] <pstolowski> zyga-kaveri: ok, i think i joined after a few hops
[07:06] <mborzecki> kinda flaky in firefox, let me try chromium instead
[07:08] <zyga-kaveri> mborzecki: try in vscode
[07:08] <zyga-kaveri> one sec guys
[07:08] <pstolowski> zyga-kaveri: i think you session died
[07:08] <pstolowski> *your
[07:08] <zyga-kaveri> yeah one sec :)
[07:09] <mborzecki> yeah. 404
[07:09] <zyga-kaveri> I had to reload to install the extension
[07:09] <zyga-kaveri> mborzecki: I sent you an invite by mail now
[07:10] <zyga-kaveri> https://prod.liveshare.vsengsaas.visualstudio.com/join?8A0945F1FF41E82128AF4EB5930C2A992FB4
[07:10] <zyga-kaveri> or try this
[07:11] <mborzecki> hahah working
[07:12] <zyga-kaveri> can you see the session chat?
[07:19] <mup> PR snapd#9311 opened: nested: add support to telnet to serial port in nested VM <Created by mvo5> <https://github.com/snapcore/snapd/pull/9311>
[07:22] <zyga-kaveri> woot
[07:22] <zyga-kaveri> that was quick and productive, thank you both
[07:22] <pstolowski> zyga-kaveri: yw
[07:23] <zyga-kaveri> how was the quality on your end?
[07:23] <zyga-kaveri> was it better than video share?
[07:23] <pstolowski> zyga-kaveri: you closed the session right? cause it said i left it
[07:23] <pstolowski> zyga-kaveri: yeah i think it's much better, no artifacts
[07:23] <mborzecki> zyga-kaveri: goot that at least it works in the browser
[07:23] <pstolowski> zyga-kaveri: plus the client controls the look/fonts etc
[07:23] <zyga-kaveri> I'm not sure, I sometimes hit a wrong key on my all-blank-keycaps keyboard
[07:24] <zyga-kaveri> could you see my three-tab view
[07:24] <pstolowski> zyga-kaveri: i think it makes sense for longer sessions
[07:24] <zyga-kaveri> I wonder how it adjusts from one screen size to another
[07:25] <zyga-kaveri> pstolowski: it also supports read/write editing
[07:25] <pstolowski> zyga-kaveri: yes i saw this
[07:25] <pstolowski> also terminal can be interactive
[07:26] <pstolowski> zyga-kaveri: i don't think i saw your three-tab view
[07:26] <pstolowski> but i'm unclear what you mean by that
[07:26] <zyga-kaveri> pstolowski: ah that's good, I have a wide monitor and I was worried that would not translate well to other aspect ratios
[07:26] <zyga-kaveri> pstolowski: three columns of text
[07:26] <zyga-kaveri> + terminal at the bottom
[07:27] <zyga-kaveri> mvo: do you need the run nested label?
[07:27] <pstolowski> zyga-kaveri: see the screenshot on mattermost
[07:27] <mvo> zyga-kaveri: yeah, probably. let me do that
[07:29] <zyga-kaveri> pstolowski: I see it
[07:29] <zyga-kaveri> so the editor layout is custom per participant
[07:30] <zyga-kaveri> ok
[07:30] <zyga-kaveri> now that I understand the problem all I need to do is to code the fix
[07:30] <zyga-kaveri> thank you again :)
[07:31] <pstolowski> great
[07:32] <pstolowski> i don't remember the exact reason it's done that way there. maybe we could have fixed auto-connect and make it smarter. but perhaps there was a good reason
[07:32] <pstolowski> i touched this line 2 years ago, amazing...
[07:32] <zyga-kaveri> it seems like an upgrade path for old systems
[07:33] <zyga-kaveri> that upgrade to new snapd and new snapd needs to run their tasks maybe?
[07:34] <pstolowski> zyga-kaveri: ah yes, there is a comment at the top
[07:47] <pedronis> mvo: did you see? we found the (one) issue with nested
[07:49] <mborzecki> pedronis: hi, shall we have a quick chat about 9300?
[07:49] <pedronis> mborzecki: yes
[07:50] <mborzecki> pedronis: ok, in 5/10 maybe?
[07:50] <pedronis> ok
[07:51] <mvo> pedronis: yes, I'm wrapping my tweaks up now right now
[07:52] <mvo> pedronis: good that it's not something deeper and that nested is back to function it seems
[07:52] <pedronis> mvo: yes, but annoying, one of those situation where splitting a PR created its own issues
[07:52] <mvo> pedronis: yeah, it's a combinations of issues it seems, the fact that the nested tests only run sometimes is also contributing to the issue
[07:53] <pedronis> mvo: yes, but otoh our tests are flaky and slow already :/
[07:53] <pedronis> even before nested
[07:53] <zyga-kaveri> mvo: we could add an action that runs nested every 12 hours
[07:53] <mvo> pedronis: yeah
[07:53] <zyga-kaveri> it gets reported in github pretty nicely
[07:53] <zyga-kaveri> (on master)
[07:54] <pedronis> mvo: I mean I had a very frustrating evening, staying around to force merge things
[07:54] <mvo> zyga-kaveri: as long as we make sure that each nested failure is considered high priority I think that's a good one
[07:54] <mvo> pedronis: .(
[07:54] <mvo> pedronis: what tests in particular ?
[07:54] <mvo> pedronis: or all over the place?
[07:54] <zyga-kaveri> mvo: I'll cook something today
[07:54] <pedronis> a bit all over the place
[07:54] <mvo> pedronis: the nested suite *should* be more robust, we only tests very robust stuff there
[07:54] <pedronis> one issue was uc20-recovery, but we have also random failures in ohter places
[07:55] <mvo> pedronis: well, "should"
[07:55] <mvo> pedronis: uc20-recover should now be fixed after merging ian PR
[07:55] <pedronis> like arch seems to fail on cgroup-tracking:root often but not always
[07:55] <mvo> pedronis: but yeah, I feel your pain :(
[07:55] <mvo> pedronis: I saw this one too!
[07:55] <pedronis> and then various interface-* tests failing sometimes
[07:56] <pedronis> and snap run timeouts sometimes but not always on strace
[07:56] <pedronis> I saw it on 18
[07:56] <pedronis> saw all over the place
[07:56] <pedronis> but in places that are required
[07:57] <mvo> :(
[07:58] <mborzecki> pedronis: joining standup
[07:58] <mvo> pedronis: sry! I will watch out for failures and see if I can fix them
[08:19] <pedronis> mborzecki: maybe I confused you:  https://github.com/snapcore/snapd/pull/9300#discussion_r486149013
[08:19] <mup> PR #9300: boot: build bootchains data for sealing <Run nested> <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9300>
[08:20] <pedronis> mborzecki: the Kernel BootFile should have full paths, it's the Kernel fields that should be ok with just names
[08:21] <pedronis> (it's not super deep, it's mostly for consistency)
[08:31]  * zyga-x240 caved and ran from the office upstairs
[08:31] <zyga-x240> it's so much warmer in the sun
[08:31] <zyga-x240> I'll go there later
[08:32] <zyga-x240> PT is at home today so I can get to the bottom of remaining tests :)
[08:44] <mup> PR snapd#9312 opened: o/snapstate: disk space check with snap update <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9312>
[08:57] <pedronis> mvo: I reviewed #9021, it needs a new 2nd review
[08:57] <mup> PR #9021: snap: implement new `snap reboot` command <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9021>
[08:59] <mvo> pedronis: \o/ thank you
[08:59] <mvo> pstolowski: are you up for a second review of 9021?
[09:00] <mvo> pedronis: I assume 9300 is not quite ready for a review yet(?)
[09:00] <pstolowski> mvo: sure. btw is #9284 now critical to unbreak something in nested?
[09:00] <mup> PR #9284: tests: some fixes and improvements for nested execution <Run nested> <⚠ Critical> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9284>
[09:00] <pedronis> mvo: mborzecki is working on it
[09:00] <mvo> pstolowski: I see failures with nested on master right now
[09:01] <mvo> pstolowski: and with 9284 it seems no failures anymore
[09:02] <mvo> I will also make the nested runs required, so that if they are activated we can only merge if they are green
[09:02] <pstolowski> +1
[09:02] <pstolowski> ok, i'll conclude my review of 9284 then
[09:05] <mup> PR snapd#9313 opened: boot: do not reorder boot assets when generating predictable boot chains <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9313>
[09:05] <mborzecki> pedronis: mvo: https://github.com/snapcore/snapd/pull/9313 a prerequisite
[09:05] <mup> PR #9313: boot: do not reorder boot assets when generating predictable boot chains <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9313>
[09:05] <mborzecki> skipped spread, so that we can land it quickly
[09:06] <mvo> mborzecki: thanks, checking
[09:09] <zyga-x240> I switched to a hybrid
[09:09] <zyga-x240> with tasks for the things where undo is easier as tasks (export, unexport)
[09:09] <pedronis> mborzecki: I am bit confused by tests there
[09:09] <zyga-x240> and a pointer helper for the link
[09:09] <zyga-x240> to avoid the complexity of link snap relationship
[09:09] <zyga-x240> making the changes now but I think this is best of both worlds
[09:12] <pedronis> mborzecki: I think the tests needs a cleanup, now that the assets are not ordered in themselves we don't need so many weird cases in them
[09:17] <pedronis> if I'm making sense
[09:45] <mborzecki> pedronis: i've updated #9300
[09:45] <mup> PR #9300: boot: build bootchains data for sealing <Run nested> <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9300>
[10:20] <pedronis> mborzecki: did you forget to push to 9313 ?
[10:23] <mborzecki> pedronis: #9313 is updated now too
[10:23] <mup> PR #9313: boot: do not reorder boot assets when generating predictable boot chains <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9313>
[10:42] <mvo> mborzecki, pedronis fwiw, I just merged 9284 and nested runs are green, I also made green nested runs a requirement for merging PRs (anything without the run-nested label gets an automatic green here)
[10:44] <mvo> mborzecki: thanks for the update on 9313 - fwiw, looks all right to me
[10:45] <mup> PR snapd#9284 closed: tests: some fixes and improvements for nested execution <Run nested> <⚠ Critical> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9284>
[11:00] <mup> PR snapd#9314 opened: o/snapstate: disk space check on UpdateMany <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9314>
[11:01] <mup> Issue core20#32 closed: The machine-id file should be writable <question> <Created by zyga> <Closed by xnox> <https://github.com/snapcore/core20/issues/32>
[11:01] <mup> Issue core20#72 closed: move docker user/group to extrausers <Blocked> <Created by anonymouse64> <Closed by xnox> <https://github.com/snapcore/core20/issues/72>
[11:01] <mup> PR core20#82 closed: [RFC] hooks: mv docker user/group definition to extrausers <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/core20/pull/82>
[11:01] <mup> PR core20#83 closed: static/writable-paths: make /etc/default/crda writable <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/core20/pull/83>
[11:01] <zyga-x240> pstolowski: do we need a check on remove?
[11:01] <zyga-x240> currently remove can fail if we have no space for the snapshot
[11:02] <pstolowski> zyga-x240: that's done and landed already
[11:02] <pstolowski> zyga: unless you found a bug
[11:03] <pstolowski> it's behind feature flag too
[11:03] <pedronis> mborzecki: thanks for the changes in 9300, there are probably some tweaks that can make it easier to reuse the bits for reseal
[11:05] <pstolowski> zyga-x240: correction, single snap remove does that already in master; remove-many is about to land
[11:05] <zyga-x240> pstolowski: ah, no I just realized this should be so while reading the other PR
[11:05] <zyga-x240> pstolowski: that's great
[11:05] <pstolowski> ok
[11:05] <pstolowski> zyga-x240: yeah i think all major ops are covered now
[11:27] <pedronis> mvo: mborzecki: I pushed some small tweaks/simplifcations to 9313
[11:28] <mborzecki> pedronis: thanks!
[11:29] <pedronis> I will look at 9300 again in a bit
[11:29] <mvo> pedronis: looking
[11:34] <mborzecki> pedronis: do you know whether #9032 is getting replaced by something else?
[11:34] <mup> PR #9032: secboot: add call to reseal an existing key <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9032>
[11:35] <pedronis> it's not afaik, it's used by #9287 which is the one to tweaks after we are happy with 9300
[11:35] <mup> PR #9287: secboot: reseal key to parameters specified in modeenv <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9287>
[11:40] <mborzecki> hmm wonder whether claudio has some unpushed merge with master in 9287
[11:47]  * pstolowski lunch
[11:49] <pedronis> mborzecki: anyway, I reviewed 9300, there are things to improve there
[11:50] <mborzecki> let me see
[12:03] <mborzecki> pedronis: tweaked buildRecoveryBootChain to actually takea list of systems, which in the initial install case will be just the current recovery system, or in a general case, the recovery systems we have
[12:14]  * zyga-x240 -> lunch
[12:21] <mborzecki> pedronis: ok, another push to #9300
[12:21] <mup> PR #9300: boot: build bootchains data for sealing <Run nested> <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9300>
[12:22] <mborzecki> cmatsuoka: hi, we've hijacked a bit your PRs :) please take a look at 9300 as well, hope i've not messed up something
[12:22] <cmatsuoka> mborzecki: thanks, I'm glad you're working on it
[12:24]  * zyga-x240 also errand
[12:24] <zyga-x240> mvo: my update in case I cannot connect for standup
[12:25] <zyga-x240> mvo: synced with pawel and maciek in the morning to debug issue from yesterday, guys solved it instantly!
[12:25] <pedronis> mborzecki: thanks
[12:25] <zyga-x240> mvo: split tasks so that export/unexport just handles files and not the "current" symlink
[12:25] <zyga-x240> mvo: used a hack to update current inside doLinkSnap, avoiding complex test failures related to task changes after link-snap
[12:26] <zyga-x240> mvo: tweaked description of the exported content so that undo path has no custom code left, just loads data from task state and calls the regular remove method
[12:27] <zyga-x240> mvo: I will tweak some tests and open a new PR today
[12:27] <zyga-x240> now everything should pass okay
[12:27]  * zyga-x240 runs to do the errand
[12:28] <mborzecki> pedronis: cmatsuoka: should we sync before the standup?
[12:32] <cmatsuoka> mborzecki: I can, SU room?
[12:39] <pedronis> cmatsuoka: mborzecki: I'm there
[12:40] <mborzecki> cmatsuoka: we're there
[12:55] <mup> PR snapd#9313 closed: boot: do not reorder boot assets when generating predictable boot chains and other small tweaks <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9313>
[13:01] <mup> PR snapd#9315 opened: tests: fix snap-routime-portal-info test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9315>
[13:35] <cachio> ijohnson, #9208 has conflicts
[13:35] <mup> PR #9208: tests/nested/core20/kernel-failover: add test for failed refresh of uc20 kernel <Run nested> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9208>
[13:38] <ijohnson> cachio: ack I see, I will resolve those now
[13:47] <cachio> ijohnson, nice, thanks
[14:06] <zyga-kaveri> re
[14:16] <mup> PR snapd#9021 closed: snap: implement new `snap reboot` command <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9021>
[14:16] <mup> PR snapd#9316 opened: tests: use full path to test-snapd-refresh.version binary <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9316>
[14:21] <mup> PR snapd#9317 opened: [RFC] devicestate: keep log from install-mode on installed system <Created by mvo5> <https://github.com/snapcore/snapd/pull/9317>
[14:29] <pedronis> mborzecki: cmatsuoka: 9300 seems to have passed all relevant tests, still needs the 2nd review
[14:34] <mborzecki> yay
[14:35] <mup> PR snapcraft#3278 closed: cli: client side check for setting default tracks <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3278>
[14:36] <mborzecki> pedronis: cmatsuoka: since it's green, and if 2nd review comments on cosmetics/messages, i think we should land it and do a simple followup with the tweka
[14:40] <mborzecki> s/tweka/tweaks/ ofc
[15:00] <mvo> pedronis, mborzecki, cmatsuoka I have one more meeting, then I should be able to have a look
[15:00] <mvo> (unless someone else beats me to it :)
[15:06] <cmatsuoka> mvo: thanks, it would be great if you could have a look
[15:11]  * cmatsuoka will return after lunch
[15:14] <ijohnson> one question on 9300
[15:14] <ijohnson> (left in the PR that is)
[15:16] <pedronis> ijohnson: I answered
[15:16]  * cachio lunch
[15:37] <ijohnson> pedronis: I +1d 9300, not sure if you still want someone else like mvo to +1 it, I have not kept up to date on all the resealing pr's this week
[15:40] <pedronis> at this point I think we should land it and cmatsuoka can work on the small follow ups, and the next ones. OTOH if mvo has time to post-review it that's also welcome
[15:41] <mvo> sure, let's land it
[15:46] <mup> PR snapd#9312 closed: o/snapstate: disk space check with snap update <Disk space awareness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9312>
[15:46] <mup> PR snapd#9314 closed: o/snapstate: disk space check on UpdateMany <Disk space awareness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9314>
[15:51] <mup> PR snapd#9300 closed: boot: build bootchains data for sealing <Run nested> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9300>
[15:51] <mup> PR snapd#9310 closed: tests: remove "set -e" from function only shell libs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9310>
[16:01] <mup> PR snapd#9294 closed: o/snapstate: check available disk space in RemoveMany <Disk space awareness> <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9294>
[16:06] <mup> PR snapd#9318 opened: .github/workflows/test.yaml: also run 20.04 nested tests with UC20 label <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9318>
[16:07] <mvo> pedronis: I get dinner now, please let me know if I can do anything after dinner, I will read backlog
[16:16] <pedronis> mvo: I think we need more code from cmatsuoka before anything else
[16:18] <mvo> pedronis: ok, thanks, I will just read backlog then :)
[16:24] <pedronis> cmatsuoka: I don't know if you noticed yet, but 9032 itself needs update because of the change to the params
[16:25] <pedronis> to support trees
[16:25] <cmatsuoka> pedronis: I'll check
[16:25] <pedronis> it's fascinating, it doesn't conflict, but then it gets unhappy about types
[16:26] <cmatsuoka> pedronis: ah yes, that's true, I'll open a PR with the small fixes for 9300 and fix 9032
[16:26]  * mvo hugs cmatsuoka and pedronis
[16:30] <zyga-mbp> I think pedronis deserves a day off, at least, for recent crunch
[16:30] <zyga-mbp> he seems to work in all the timezones at once
[16:31] <ijohnson> agreed
[16:31] <cmatsuoka> zyga-mbp: and all the complex subsystems
[16:31] <mup> PR snapd#9319 opened: seal: error message and function name adjusts <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9319>
[16:32] <zyga-mbp> that was a given
[16:33] <zyga-mbp> today is a bit more patchy, with errands and now remote school meeting
[16:33] <zyga-mbp> gosh if we ever complain about hangouts or anything like that
[16:33] <zyga-mbp> try putting 30 parents with poor tech know-how
[16:33] <zyga-mbp> and have them achieve anything
[16:33] <cmatsuoka> been there
[16:34] <ijohnson> #9208 is ready for a review, I de-conflicted it now
[16:34] <mup> PR #9208: tests/nested/core20/kernel-failover: add test for failed refresh of uc20 kernel <Run nested> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9208>
[16:34] <ijohnson> cachio: ^
[16:34] <cachio> ijohnson, tx
[16:41] <pedronis> #9319 should have had skip spread
[16:41] <mup> PR #9319: boot: in seal.go adjust error message and function names <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9319>
[16:50] <pedronis> ijohnson: ^ should be quick to review, and has the comment you asked now
[16:50]  * pedronis dinner
[16:50] <ijohnson> ok
[17:26] <pedronis> now GH is sending (resending?) old emails ??
[17:34] <cmatsuoka> hmm I didn't receive anything strange from GH recently
[17:35] <zyga-mbp> neither did I
[17:37] <mup> PR snapd#9320 opened: boot: group SealKeyModelParams by model <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9320>
[17:40] <cmatsuoka> afk for a short while, /me completely forgot to pay some bills yesterday
[17:42] <cachio> mvo, I see that is really weird
[17:42] <cachio> https://paste.ubuntu.com/p/3YQrFW6F22/
[17:43] <cachio> mvo, starting stopping many times until it reaches the limit
[18:02] <mup> PR snapd#9319 closed: boot: in seal.go adjust error message and function names <Skip spread> <UC20> <Created by cmatsuoka> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9319>
[18:08] <pedronis> cmatsuoka: I reviewed 9032, my remark can probably be addressed in a follow up
[18:09] <cmatsuoka> pedronis: thanks, I'll check
[18:22] <pedronis> cmatsuoka: are you assuming we land #9320 (I didn't think it was urgent) ?
[18:22] <mup> PR #9320: boot: group SealKeyModelParams by model <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9320>
[18:22] <mup> PR snapd#9321 opened: cmd/snap/model: specify grade in the model command output <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9321>
[18:22] <cmatsuoka> pedronis: not urgent, I prepared it because it looked easy enough
[18:23] <cmatsuoka> pedronis: now working on the new reseal call
[19:19] <mup> PR snapd#9032 closed: secboot: add call to reseal an existing key <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9032>
[19:38]  * zyga-mbp works on a few more tests
[19:44] <cachio> ijohnson, hey
[19:44] <ijohnson> Hi
[19:45] <cachio> I am checking basic20 test which fails
[19:45] <cachio> and see this
[19:45] <cachio> MATCH '# Snapd-Boot-Config-Edition: [0-9]+' < /run/mnt/ubuntu-seed/EFI/ubuntu/grub.cfg
[19:45] <cachio> the check fails
[19:46] <cachio> ijohnson, but, it metches
[19:46] <cachio> MATCH '# Snapd-Boot-Config-Edition: [0-9]+' < /boot/grub/grub.cfg
[19:48] <ijohnson> cachio those are two different files
[19:48] <ijohnson> One is /boot/grub/grub.cfg and the other is /run/mnt/ubuntu-seed/EFI/ubuntu/grub.cfg
[19:49] <ijohnson> cachio which test is this
[19:50] <cachio> core/basic20
[19:50] <cachio> the check for /run/mnt/ubuntu-seed/EFI/ubuntu/grub.cfg is failing
[19:50] <cachio> ijohnson, https://paste.ubuntu.com/p/25wQdj2qFW/
[19:51] <ijohnson> cachio so this test will only work if the image that was created was flashed with a new enough snapd used by ubuntu-image
[19:52] <ijohnson> cachio how was that image built?
[19:52] <cachio> ijohnson, I build that today, using beta
[19:52] <cachio> channel
[19:53] <cachio> ijohnson, should I update snapd?
[19:53] <ijohnson> cachio you need to point ubuntu-image to snapd from your system with an env var
[19:54] <ijohnson> cachio set UBUNTU_IMAGE_SNAP_CMD=$(which snap)
[19:54] <pedronis> cmatsuoka: how it's going? any problems?
[19:54] <ijohnson> Then call ubuntu-image
[19:55] <cachio> ijohnson, ahh, nice, I'll retry with that
[19:55] <cmatsuoka> pedronis: I did reseal, now I'm running a quick test before opening the PR
[19:55] <cachio> ijohnson, thanks
[19:56] <ijohnson> cachio just to be on the safe side try with snapd from edge or beta on your host too
[19:57] <cmatsuoka> and... it failed! for some reason
[19:57]  * cmatsuoka investigates
[20:00] <zyga-mbp> far fewer failures
[20:00] <zyga-mbp> but some bugs still remain,
[20:00] <zyga-mbp> I think snapstate.Info description is misleading
[20:00] <zyga-mbp> it doesn't work for snaps that are not in state
[20:02] <cmatsuoka> I think i just can't do what I'm trying to do (resealing just after sealing)
[20:03] <zyga-mbp> cmatsuoka: do you think the TPM does not support that?
[20:03] <cmatsuoka> zyga-mbp: I think we lock the tpm after we seal because reseal can't even open it
[20:04] <mup> PR snapd#9322 opened: boot: add call to reseal an existing key <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9322>
[20:05] <cmatsuoka> also closing the previous PR that did the same thing
[20:08] <zyga-mbp> brb, need to restart wifi
[20:09] <mup> PR snapd#9287 closed: secboot: reseal key to parameters specified in modeenv <UC20> <⛔ Blocked> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/9287>
[20:11] <cachio> ijohnson, I also see this change https://paste.ubuntu.com/p/Vft4S47VP4/
[20:11] <cachio> which fails
[20:11] <cachio> it should be fixed whith the new snapd?
[20:12] <ijohnson> cachio: no that test needs to be updated for external systems
[20:12] <cachio> or I need to update the test
[20:12] <ijohnson> cachio: that test depends on the image used
[20:12] <cachio> ijohnson, ok
[20:12] <cachio> yes, makes sense
[20:12] <cachio> thanks
[20:14] <zyga_> 2K insertions
[20:14] <zyga_> I need about 500 more to finish
[20:14] <mup> PR snapd#9248 closed: exportstate: add scaffolding for the export manager <Needs Samuele review> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/9248>
[20:14] <mup> PR snapd#9323 opened: snap/naming: upgrade TODO to TODO:UC20 <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/9323>
[20:16] <cachio> ijohnson, do you know where I can get the info to check snap recovery?
[20:16] <ijohnson> cachio: the info comes from the model assertion and the recovery system label
[20:19] <cachio> ijohnson, and do we store that in a file?
[20:19] <ijohnson> cachio: the 2nd column in the output of `snap recovery` will match the output of the brand from `snap model`
[20:19] <ijohnson> cachio: the 3rd column will match the output of `snap model | grep model`
[20:19] <cachio> ijohnson, nice
[20:20] <cachio> I'll get the info from there
[20:20] <cachio> thanks
[20:26] <cmatsuoka> zyga-kaveri: ha, the tpm device was left open after sealing
[20:28] <cmatsuoka> and now it works
[20:46] <zyga> time for spread
[20:46] <zyga> I have one unit test failure but debugging some of the state engine failures is a bit mysterious
[20:46] <zyga> but that's okay, let's see what spread shows
[20:47]  * cachio afk
[20:54] <mup> PR core18#169 opened: snapcraft.yaml: use build-base for modern snapcraft, and use lxd in travis to build the snap <Created by anonymouse64> <https://github.com/snapcore/core18/pull/169>
[21:04] <mup> PR snapd#9323 closed: snap/naming: upgrade TODO to TODO:UC20 <Simple 😃> <Skip spread> <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9323>
[21:04] <mup> PR snapd#9324 opened: secboot: adjust parameters to buildPCRProtectionProfile <Simple 😃> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9324>
[21:05] <zyga> thanks!
[21:05] <ijohnson> np, thanks for fixing it :-)
[21:13] <zyga> ah,
[21:13] <zyga> I know what to do next
[21:24] <mup> PR snapd#9325 opened: strutil: add SortedListsUniqueMerge <Created by pedronis> <https://github.com/snapcore/snapd/pull/9325>
[21:30] <zyga> ok, no unit test failures,
[21:30] <zyga> a few XXXes
[21:30] <zyga> running spread again
[21:30] <zyga> should be all green now
[21:34] <pedronis> ijohnson: cmatsuoka: I worked a bit more on #9320, it has more tests for some of things in the previous PRs, it needs #9325
[21:34] <mup> PR #9320: boot: group SealKeyModelParams by model, improve testing <Run nested> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9320>
[21:34] <mup> PR #9325: strutil: add SortedListsUniqueMerge <Created by pedronis> <https://github.com/snapcore/snapd/pull/9325>
[21:34] <cmatsuoka> pedronis: ack, checking
[21:35] <zyga> pedronis what does sh stand for?
[21:35] <zyga> size?
[21:35] <pedronis> where ?
[21:35] <zyga> line 79
[21:35] <zyga> https://github.com/snapcore/snapd/pull/9325/files#diff-342c12787e3c9ff0147933bb2fe7aa7fR79
[21:35] <mup> PR #9325: strutil: add SortedListsUniqueMerge <Created by pedronis> <https://github.com/snapcore/snapd/pull/9325>
[21:36] <pedronis> sz
[21:36] <pedronis> yes, size
[21:37]  * zyga reads sz as sh due to the pronounciation in his language which sometimes makes things confusing
[21:48] <zyga> pedronis why the else at the end
[21:48] <zyga> cannot we drain both lists?
[21:48] <zyga> oh
[21:48] <zyga> only one would be
[21:48] <zyga> right?
[21:51] <zyga> +1
[21:53] <zyga> I'll wait for tests to finish
[21:53] <zyga> and run one more overnight
[21:53] <zyga> I'm mainly interested in seeing core tests
[21:53] <zyga> tomorrow the last stretch to complete this
[21:54] <pedronis> zyga: yes, if they are both true we would still be in the previous loop
[21:54] <zyga> right
[21:54] <zyga> nice code :)
[22:02] <cmatsuoka> afk, phone call
[22:02] <pedronis> ijohnson: I commented on your note in the standup, the difference between snap recovery and snap model is expected
[22:03] <pedronis> we have the same difference in other places (is the difference between list vs info-like output)
[22:04] <pedronis> cmatsuoka: I missed you had opened #9322
[22:04] <mup> PR #9322: boot: add call to reseal an existing key <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9322>
[22:05] <mup> PR snapd#9326 opened: tests: fix for basic20 test running on external backend and rpi <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9326>
[22:05] <cmatsuoka> pedronis: and now I noticed it failed the macos test, probably something related to nosecboot
[22:07] <pedronis> cmatsuoka: looks good looking quickly, but one comment, I will look closer in the morning
[22:07] <cmatsuoka> pedronis: ok, thanks, I'll see the macos and the other issue you raised in a moment, I need to make a few phone calls first
[22:08] <pedronis> thx, calling it a day
[22:10] <zyga> good night pedronis