[06:03] <mborzecki> morning
[06:05] <mvo> hey mborzecki
[06:06] <mborzecki> mvo: hey
[06:07] <mup> PR snapd#7782 closed: osutil: handle "rw" mount flag in ParseMountEntry <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7782>
[06:09] <mup> PR snapd#7778 closed: seccomp: allow chown 'snap_daemon:root' and 'root:snap_daemon' <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7778>
[06:34] <zyga> good morning
[06:34] <zyga> wow, everyone is up early
[06:39] <mvo> hey zyga - welcome to the right TZ!
[06:41] <zyga> mvo: ... :D
[06:41] <zyga> mvo: I took Bit for a walk at 1:30AM
[06:41] <zyga> mvo: but I feel okay now
[06:42] <zyga> mvo: I try to take a nap mid-day to compensate
[06:42] <zyga> mvo: I'll jump into the fray soon
[06:43] <mborzecki> zyga: hah 1:30am ;P sounds like a different tz to time
[06:43] <mvo> zyga: cool
[06:45] <mborzecki> mvo: regarding https://github.com/snapcore/snapd/pull/7772#pullrequestreview-322085662 maybe something the generators could do, but those run before local fs mounts, so it'd have to be in the core snap if i understand it correctly
[06:45] <mup> PR #7772: wrappers: write and undo snapd services on core <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7772>
[06:53] <mvo> mborzecki: aha, interessting idea
[07:29] <pedronis> mborzecki: mvo: hi, should we have a chat about the snapd configure issues?
[07:30] <mborzecki> pedronis: hi, sure
[07:31] <pedronis> mborzecki: mvo: standup?
[07:32] <mvo> pedronis: ok
[08:02] <pstolowski> morning
[08:09] <mborzecki> pstolowski: hey
[08:28] <mup> PR snapd#7765 closed: boot,bootloader: make MakeBootable() uc20 aware <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7765>
[08:44] <pedronis> mvo: I did a pass on #7746
[08:44] <mup> PR #7746: snap-bootstrap: implement "snap-bootstrap initramfs-mounts" <Needs Samuele review> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7746>
[08:54] <mup> PR snapd#7789 opened: bootloader: add new bootloader.InstallBootConfig() <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7789>
[08:59] <tomwardill> hi all, store team here. Downloads might see some errors atm, we're working on it
[09:00] <pstolowski> tomwardill: hi, thanks for heads up!
[09:02] <mvo> pedronis: thank you!
[09:10] <BjornT> mvo: hi! how can i try out this snapfuse fix on bionic? https://bugs.launchpad.net/snapd/+bug/1817276
[09:10] <mup> Bug #1817276: snapfuse use a lot of CPU inside containers <maas> <snapd:Fix Released by mvo> <https://launchpad.net/bugs/1817276>
[09:11] <BjornT> mvo: it seems like the snapfuse binary comes from the snapd deb, which is still 2.40
[09:15] <mvo> BjornT: we have a updated it in bionic-proposed
[09:16] <mvo> BjornT: I think the sru was actually validated so it's mostly a matter of getting this released
[09:16] <mvo> BjornT: I can poke foundatoins
[09:21] <BjornT> mvo: cool, i'll install it from -proposed then
[09:26] <mborzecki> mvo: pedronis well, the spread test seems to be working now with the tweaks in configstate
[09:28] <BjornT> mvo: nice. confirmed that the fix is a major improvement. after upgrading snapd to 2.42, my load average isn't constantantly growing anymore and back to normal levels
[09:29] <mvo> BjornT: yay! if you could give me numbers from your workload that would be awesome
[09:31] <BjornT> mvo: what kind of numbers? i haven't done any performance tests yet. but before snapfuse was taking 100% constantly, probably while syncing images, which requires a lot of writing. now it still can burst up to 90%, but it quickly goes down again.
[09:32] <BjornT> mvo: and the load average just kept growing. it was up to 900 before i upgraded snapd
[09:33] <zyga> 900?!
[09:34] <mvo> BjornT: thanks, that was what I was looking for, some details :)
[09:35] <pedronis> mborzecki: great
[09:41] <pedronis> mvo: reviewed 7789
[09:52] <pedronis> pstolowski: thanks for the review, I applied the suggestion
[09:52] <pstolowski> yw
[09:53] <mvo> pedronis: thank you!
[09:57] <pedronis> Chipaca: is #7671 ready for review ?
[09:57] <mup> PR #7671: overlord/patch: normalize tracking channel in state <Channels 🏷> <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7671>
[09:58] <Chipaca> pedronis: AFAIK :)
[09:58] <pedronis> Chipaca: ok :)
[10:05] <pedronis> mvo: now that I remembered how the current bootloader.Options flag is used by lk, I think we do want a 2nd flag, probably just InstallMode bool (would be false for UC 16 / 18)
[10:06] <pedronis> mvo: doesn't block the current PR but would be relevant for next step
[10:07] <mvo> pedronis: I was thinking about a "Recovery" flag that could be used by "bootloader.Find()" and "InstallBootConfig()" to tell the system to install bootconfig for recovery or real-boot. That should also address this, but I'm happy with InstallMode as well
[10:07] <pedronis> mvo: that works too, Recover = true = InstallMode
[10:07] <pedronis> Recovery
[10:08] <mup> PR snapd#7746 closed: snap-bootstrap: implement "snap-bootstrap initramfs-mounts" <Needs Samuele review> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7746>
[10:08] <pedronis> Chipaca: does #7671 need a master merge?
[10:09] <mup> PR #7671: overlord/patch: normalize tracking channel in state <Channels 🏷> <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7671>
[10:09] <Chipaca> pedronis: ah, maybe; i'll look in a bit
[10:11] <pedronis> Chipaca: I see things that I thought I reviewed already, but maybe I'm confused (that's possible)
[10:20] <zyga> sil2100, ogra: do you know who is maintaining the pi gadgets today
[10:22] <zyga> degville: I was looking at https://snapcraft.io/docs/gadget-boot-assets and noticed it's not linked from https://snapcraft.io/docs/gadget-snap - just wanted to check with you if I should edit and make the connection or is there another path somewhere
[10:23] <degville> zyga: I think you're right - I'd not added the link yet pending the boot assets edits and final changes, but it makes better sense to link it now.
[10:24] <degville> (as doc and boot assets are in pretty good shape)
[10:45] <mup> PR snapd#7787 closed: many: share single implementation to list needed default-providers <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7787>
[10:52] <mup> PR snapd#7790 opened: boot: add boot.Modeenv that can read/write the UC20 modeenv files <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7790>
[10:53] <mup> PR snapd#7789 closed: bootloader: add new bootloader.InstallBootConfig() <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7789>
[10:53] <mvo> pedronis_: hopefully simple and then I can build on top of this
[10:55] <pedronis> mvo: commented
[10:59] <mvo> pedronis: thank you!
[11:18] <Chipaca> pedronis: ok if i rebase 7671?
[11:23] <Chipaca> pedronis: i've rebased 7671
[11:24] <Chipaca> pedronis: it looks a lot more like a patch patch now
[11:32] <mvo> pedronis: addressed your comments, thanks again
[11:35] <sil2100> zyga: hey! That's us (foundations), but it's basically waveform mostly
[11:39] <zyga> sil2100: thanks, I'll reach out to him
[11:44] <pedronis> Chipaca: thx, I will look in a bit
[11:44] <pedronis> mvo: that's not the rename I proposed, I proposed to match what we use in the file (up to format)
[11:44] <pedronis> :)
[11:45] <pedronis> mvo: ah, not the code is right, but the commit says another thing
[11:51] <pedronis> mvo: +1 with some more comments, mostly about the tests
[11:53] <mvo> pedronis: thank you, on it!
[11:53] <mup> PR snapd#7791 opened: snap-bootstrap: make cmdline parsing robust <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7791>
[12:05] <mborzecki> mvo: pedronis: i've updated #7788 please take a look
[12:05] <mup> PR #7788: overlord/snapstate: pick up system defaults when seeding the snapd snap <⚠ Critical> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
[12:05] <mborzecki> need to sort out my flights
[12:06] <pedronis> mborzecki: thanks, will look in a bit
[12:07] <pedronis> Chipaca: reviewed, maybe pstolowski can give a look too
[12:07] <zyga> mborzecki: about flights, I looked at trains
[12:08] <zyga> mborzecki: but it's a no-go because it's impossible to get tickets for a ride this distant
[12:08] <zyga> mborzecki: assuming that train schedules don't change it's a whole-day trip with one stop in Berlin
[12:08] <mborzecki> zyga: and it's probably half a day
[12:08] <zyga> mborzecki: and the price is very competitive with flying
[12:08] <zyga> mborzecki: even if you consider first class actually
[12:09] <zyga> mborzecki: but I decided not to use it because << 2 hours is meh-good-enough
[12:09] <pstolowski> pedronis, Chipaca will do
[12:09] <zyga> mborzecki: there are a number of connections, some take over half a day and involve many stops, some are fast
[12:15] <pedronis> mborzecki: done, thank you
[12:16] <pedronis> mborzecki: have you looked at the other issue (installing core on a snapd-only system with defaults) or not yet?
[12:17] <mborzecki> pedronis: not yet, spent silly amount of time fighting the configstate handlers test
[12:18] <mvo> 7790,7791 should be simple reviews and unblock some more of the early boot work
[12:18]  * mvo considers lunch
[12:18] <pedronis> mborzecki: lots of setup needed
[12:18] <mborzecki> pedronis: might have overdone it a little
[12:18] <zyga> jdstrand: good morning
[12:20] <mup> PR snapd#7759 closed: devicestate: add reading of modeenv to uc20 firstboot code  <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7759>
[12:24] <pstolowski> pedronis, Chipaca will do
[12:25] <pstolowski> ups, wrong window
[12:40] <zyga> mborzecki: 2nd +1 on https://github.com/snapcore/snapd/pull/7788#pullrequestreview-322948196
[12:40] <mup> PR #7788: overlord/snapstate: pick up system defaults when seeding the snapd snap <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
[12:41] <mborzecki> zyga: thanks
[12:50] <zyga> I'll make coffee and resume patches
[12:59] <mborzecki> cmatsuoka: hi, quick question about #7743, in the real world scenario, we wouldn't need sfdisk --force, because snap-bootstrap will be running off initramfs right?
[12:59] <mup> PR #7743: snap-bootstrap: force partition table operations <Simple 😃> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>
[13:07] <cmatsuoka> mborzecki: it's likely that it will be needed in the real case, I added snap-bootstrap to the spike and it required --force
[13:08] <cmatsuoka> mborzecki: --force was completely under my radar until I tested it in a real scenario
[13:09] <cmatsuoka> mborzecki: the same happened with the udev node creation, for some reason partx -u triggers node creation but blockdev --rereadpt doesn't
[13:10] <cmatsuoka> mborzecki: I started to check the partx source code to see what exactly it's doing there, but it does quite a lot
[13:13] <mborzecki> cmatsuoka: interesting, i would guess that sfdisk handles that when it triggers the kernel to reread the partition table
[13:14] <mborzecki> cmatsuoka: afaiu that's what partx does by doing a bunch of ioctls() though it passes an actual partition number there
[13:15] <mborzecki> cmatsuoka: either way, this goes through the kernel -> devfs, and in parallel to udev which does symlinking under /dev/disk/by-*/, that's probbaly why the extra delay is needed
[13:15] <cmatsuoka> I also tried to manually run udevadm trigger but it didn't do anything
[13:16] <mborzecki> cmatsuoka: was any paritition from taht device mounted at the time when sfdisk ran?
[13:16] <cmatsuoka> According to a comment in the partx source code, it needs a few ms to settle after the operation
[13:18] <cmatsuoka> mborzecki: hmm, yes, it's possible that we had partitions mounted in initramfs
[13:18] <cmatsuoka> mborzecki: ah, I guess core was mounted from seed directly at that point
[13:18] <mborzecki> cmatsuoka: that would explain why the disk was seen as 'used'
[13:19] <cmatsuoka> mborzecki: yes, indeed. but we can't unmount everything, we need seed an boot
[13:19] <cmatsuoka> and boot
[13:22] <mborzecki> cmatsuoka: right, i guess there's no way around that, so --force seems ok
[13:22] <mborzecki> cmatsuoka: perhaps that's why you needed to call partx
[13:23] <cmatsuoka> mborzecki: about the partx -u, I don't like the idea that we're relying on a side effect of a specific utility -- ideally I'd like to redo whatever partx is doing there
[13:23] <cmatsuoka> but that would take some time to analyse
[13:23] <mborzecki> cmatsuoka: was there any mesage from fdisk? specificaly thinking https://github.com/karelzak/util-linux/blob/master/libfdisk/src/context.c#L833-L840
[13:25] <cmatsuoka> mborzecki: no such message, the PT re-read was apparently successful
[13:25] <mborzecki> heh, fun ;)
[13:26] <cmatsuoka> those real life problems are very annoying!
[13:27] <cmatsuoka> also I hope that kernel 5.4 doesn't crash in firstboot, 5.3 did but I still didn't check why
[13:31] <cmatsuoka> mborzecki: I think I should add an XXX note there
[13:32] <mborzecki> cmatsuoka: yup, sounds like a good idea
[13:32] <cmatsuoka> mborzecki: doing that
[14:23] <mup> PR snapd#7790 closed: boot: add boot.Modeenv that can read/write the UC20 modeenv files <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7790>
[14:35] <mborzecki> anyone know of a tool that lists what desktop files are visible?
[14:41] <mup> PR snapd#7760 closed: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7760>
[14:47] <zyga> pedronis, mvo: I'll check if there are any open bugs that are related to nested mimics and see if they have regression tests
[14:49] <mup> PR snapd#7792 opened: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7792>
[14:58] <mup> PR snapd#7671 closed: overlord/patch: normalize tracking channel in state <Channels 🏷> <Needs Samuele review> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7671>
[14:59] <Chipaca> *gasp* i was supposed to wait for pstolowski :-(
[14:59] <mvo> pedronis: 7792 should also be easy hopefully
[14:59] <pstolowski> Chipaca: i'm finishing it atm..
[14:59] <Chipaca> pstolowski: please tell me it's not on fire :-|
[15:01] <mborzecki> mvo: pedronis: #7788 is green
[15:01] <mup> PR #7788: overlord/snapstate: pick up system defaults when seeding the snapd snap <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
[15:18]  * cachio lunch
[15:21] <thresh> hi.  cant launch chromium anymore, on debian: https://paste.debian.net/1118076/
[15:21] <thresh> installed:   78.0.3904.108            (958) 160MB -
[15:22] <thresh> any ideas? thank you.
[15:23] <Chipaca> thresh: can you pastebin 'snap version' please?
[15:24] <Chipaca> who was it that was looking at the /sys/kernel/mm/transparent_hugepage/hpage_pmd_size thing
[15:24] <thresh> sure thing.  there you go Chipaca: http://paste.debian.net/1118077/
[15:24] <Chipaca> mvo: you do remember, offhand?
[15:24] <Chipaca> yeah, 42 on a 5.3
[15:25] <Chipaca> there was somebody looking at this, but i don't remember what the conclusion was
[15:26] <Chipaca> jdstrand: is it expected that chromium tries to do things that would require hardware-observe?
[15:26] <pedronis> Chipaca: I saw some chromium related stuff in some of recent jdstrand PRs
[15:27] <pedronis> not sure it relates or not
[15:27] <pedronis> maybe he can say
[15:27] <jdstrand> Chipaca: what things?
[15:27] <Chipaca> jdstrand: looks like it's trying to read /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
[15:27] <Chipaca> as per the pastebin above
[15:27] <Chipaca> jdstrand: https://paste.debian.net/1118076/
[15:28] <zyga> mvo: can you double check https://github.com/snapcore/snapd/pull/7773 please
[15:28] <mup> PR #7773: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Needs Samuele review> <Squash-merge> <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7773>
[15:28] <zyga> mvo: it has +2 and as soon as it's green I'd like to merge it and open a backport for 2.42.3
[15:29] <jdstrand> Chipaca: seems like we need something added to PR 7779
[15:29] <mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
[15:29] <jdstrand> Chipaca: I'll do that in a bit
[15:29] <Chipaca> jdstrand: is there something thresh can do to get unblocked?
[15:30] <Chipaca> i'm guessing 'reboot into pre-5.3 kernel' would work but not be a nice way out
[15:30] <jdstrand> Chipaca: oh, actually, that is snap-update-ns.chromium
[15:30] <zyga> o/
[15:30] <thresh> It's not a big deal.  I use firefox mainly anyway.  Just something that is probably best reported & fixed :)
[15:30] <Chipaca> thresh: <3
[15:31] <pedronis> jdstrand: mvo is looking at doing a 2.42.3, it would be good to know if we need things in it for this
[15:32] <jdstrand> I'll look into that access. one could modify /var/lib/snapd/apparmor/profiles/snap-update-ns.chromium
[15:32] <jdstrand> thresh: ^
[15:33] <jdstrand> eg, add '/sys/kernel/mm/transparent_hugepage/hpage_pmd_size r,' then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-update-ns.chromium'
[15:33] <jdstrand> that only works until snapd refreshes the policy of course (then you'd have to do it again)
[15:33] <jdstrand> pedronis: ack
[15:35] <Chipaca> jdstrand: thank you
[15:35] <thresh> jdstrand, huh.  well that worked to remove the apparmor denial line from dmesg indeed.
[15:35] <thresh> but chromium still crashes with the same message
[15:35] <thresh> so maybe those are not related.
[15:36] <Chipaca> oSoMoN: ^ is that a 'you' thing?
[15:37] <Chipaca> thresh: at this point i'd say it's probably best to open a topic in forum.snapcraft.io, so it can be looked at async
[15:37] <thresh> right
[15:37] <Chipaca> either that or a good ol' bug :)
[15:38] <Chipaca> but forum is probably easier
[15:38] <thresh> I'm going to try a different user / clean profile etc
[15:38] <oSoMoN> thresh, mind filing a bug at https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+filebug ?
[15:38] <mup> PR snapd#7793 opened: devicestate: read modeenv early and store in devicestate <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7793>
[15:39] <oSoMoN> Chipaca, the chromium snap is a 'me' thing indeed
[15:39] <thresh> oSoMoN, I will, thanks!
[15:39] <mup> PR snapd#7791 closed: snap-bootstrap: make cmdline parsing robust <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7791>
[15:39] <Chipaca> oSoMoN: :)
[15:39] <mvo> zyga: sure, looking now
[15:39]  * Chipaca grabs a cuppa tea and tries to stop eating biscuits
[15:40] <Chipaca> I visited my mum on sunday and cam back with a metric ton of chocolate chip
[15:40] <Chipaca> send help
[15:42] <mup> PR snapd#7773 closed: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Needs Samuele review> <Squash-merge> <⚠ Critical> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7773>
[15:42] <zyga> Chipaca: send chocolate :)
[15:43] <zyga> Chipaca: we should take preorders on treats for Fra
[15:43] <Chipaca> Fra is three months away
[15:43] <zyga> Chipaca: with everyone taking trains we can bring anything :)
[15:44] <Chipaca> in fact, fra is two weeks before i run the lisbon half
[15:44] <Chipaca> so no treats!
[15:47] <mvo> mborzecki: I think we can merge 7788 - do you want to squash merge or do you prefer the commits and then we open a 2.42 version ? either way is fine with me. if squash I think it would be great if you could do it yourself so that you can decide on the commit message
[15:49] <zyga> mvo: https://github.com/snapcore/snapd/pull/7794
[15:49]  * zyga goes for lunch
[15:50] <mup> PR #7794: many: backport pull request #7773 from zyga/fix/lp-1852361 <Created by zyga> <https://github.com/snapcore/snapd/pull/7794>
[15:50] <mup> PR snapd#7788 closed: overlord/snapstate: pick up system defaults when seeding the snapd snap <Squash-merge> <⚠ Critical> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
[15:50] <mup> PR snapd#7794 opened: many: backport pull request #7773 from zyga/fix/lp-1852361 <Created by zyga> <https://github.com/snapcore/snapd/pull/7794>
[15:55] <mup> PR snapd#7795 opened: overlord/snapstate: pick up system defaults when seeding the snapd snap (2.42) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7795>
[15:57] <mborzecki> mvo: ^^
[15:58] <ackk> zyga, hi, I just ran again into the issue with the maas snap reporting that the command is not there, when the snap is installed. this time it happened right after installing the snap from the store
[15:58] <ackk> zyga, any useful info I can gather ?
[16:03] <zyga> ackk: oh my :D
[16:03] <zyga> ackk: what what the exact error message?
[16:04] <ackk> $ maas
[16:04] <ackk> execv failed: No such file or directory
[16:04] <zyga> ackk: this is worrying, so it was not a "snap try" version
[16:04] <ackk> zyga, it's odd because every time I've seen it happen, it was just after I ran maas init
[16:04] <zyga> ackk: did you have a snap-try version before though?
[16:04] <zyga> and then installed from the store on top of that?
[16:05] <ackk> zyga, that's a good question, I'm not sure
[16:05] <mvo> mborzecki: \o/
[16:05] <zyga> ackk: that might explain why
[16:05] <mvo> pedronis: you mentioned another potential thing we need for .3 ?
[16:05] <zyga> ackk: we actually landed a feature that might help
[16:05] <ackk> zyga, can I check somehow?
[16:05] <zyga> ackk: it fixes a whole class of issues
[16:05] <zyga> ackk: try edge when it builds please,
[16:06] <ackk> zyga, I would have an x1 dir if I had upgraded from try right?
[16:06] <zyga> yes
[16:06] <zyga> or x$something
[16:06] <ackk> zyga, then no, I only have one revision
[16:06] <ackk> /o\
[16:06] <zyga> ackk: any ideas on how to reproduce are welcome
[16:07] <zyga> ackk: to finish that thought though: https://github.com/snapcore/snapd/pull/7773 is what I was referring to
[16:07] <mup> PR #7773: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Needs Samuele review> <Squash-merge> <⚠ Critical> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7773>
[16:07] <zyga> ackk: it introduces snap set core experimental.robust-mount-namespace-updates=true
[16:07] <zyga> ackk: which changes how mount namespace is updated
[16:07] <ackk> zyga, that's not yet in edge though?
[16:07] <zyga> ondra: ^ btw, it landed, we're going to be good for release soon
[16:07] <zyga> ackk: no, it's just in for a few minute
[16:08] <ackk> zyga, so, snapd edge ?
[16:08] <ondra> zyga cool, I will run edge on one of the devices and confirm it is updating ( and I will also give customer heads up)
[16:08] <ackk> zyga, and that snap set
[16:08] <ackk> zyga, is that valid for core18 as well?
[16:09] <zyga> ackk: snapd edge or core edge once it builds
[16:09] <zyga> ackk: it works across all versions
[16:09] <ackk> cool
[16:10] <mborzecki> pedronis: mvo: yeah, looks like we have a problem with subsequent install of core on a core18 device
[16:10] <mvo> thanks zyga and mborzecki
[16:10] <mvo> mborzecki: meh, do you have more details?
[16:11] <zyga> oh
[16:11] <zyga> mborzecki: so more fixes for 2.42.x required?
[16:11] <zyga> mvo: do you want to cherry-pick any of jdstrand's recent interface fixes?
[16:11] <zyga> mvo: I can cherry-pick them back to offload you
[16:11] <mborzecki> mvo: pedronis: https://paste.ubuntu.com/p/mpV9Nr8v9H/
[16:11] <mborzecki> zyga: yes, think so
[16:12] <mup> PR snapd#7761 closed: devicestate: make /var/lib/snapd/seed available in install mode <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7761>
[16:13] <zyga> ijohnson: hey
[16:13] <zyga> ijohnson: I'd like to land https://github.com/snapcore/snapd/pull/7783
[16:13] <mup> PR #7783: osutil/mount: add {Unm,M}outFlagsToOpts helpers <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7783>
[16:13] <zyga> ijohnson: I explained why the suggestion doesn't work (ordering)
[16:14] <ijohnson> sure let me take a look
[16:14] <zyga> ijohnson: I'm happy to iterate on ideas but I'd like to merge this and unblock another PR
[16:14] <zyga> ijohnson: so that the useful improved debug output from snap-update-ns doesn't get stuck/lost
[16:16] <mup> PR snapd#7796 opened: tests/main/ubuntu-core-config-defaults-once: make sure configuration defaults are applied once <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7796>
[16:21] <zyga> dot-tobias: hey
[16:21] <zyga> dot-tobias: please check out updates to https://bugs.launchpad.net/snapd/+bug/1844496
[16:21] <mup> Bug #1844496: “Device or resource busy” error during snap refresh when using layout with variable <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1844496>
[16:22] <mup> PR snapd#7797 opened: devicestate: make /var/lib/snapd/seed available in install mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7797>
[16:23] <mvo> zyga: only if we really need them for .3
[16:23] <zyga> mvo: ok
[16:24] <mvo> mborzecki: aha, so this is the defaults that get reapplied?
[16:31] <pedronis> mborzecki: bad but expected
[16:31] <pedronis> the fix should be simple as discussed
[16:31] <pedronis> in snapstate
[16:32] <mvo> pedronis: that's not .3 criticial, is it?
[16:32] <ijohnson> zyga: approved, but please note my response :-) thanks
[16:32] <zyga> looking
[16:32] <zyga> and thank you :)
[16:32] <mvo> pedronis: did you mention earlier anything else criticial for .3?
[16:34] <pedronis> mvo: jdstrand was looking into chromium failing in some places with denials
[16:34] <jdstrand> mvo: when do you expect 2.43 to go out? I ask cause ondra needs raw-volume soon and PR 7779 is also interesting
[16:34] <mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
[16:34] <jdstrand> mvo: (these might be candidates for .3)
[16:35] <mvo> jdstrand: we do a .3 today/early tomorrow, once that is in candidate I will branch 2.43
[16:36] <jdstrand> mvo: so, a couple of weeks?
[16:36] <jdstrand> mvo: https://github.com/snapcore/snapd/pull/7777 would be nice for people to have
[16:36] <mup> PR #7777: snap-confine: suppress noisy classic snap file_inherit denials <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7777>
[16:36] <jdstrand> mvo: that is a real clean cherrypick
[16:37] <mup> PR snapd#7783 closed: osutil/mount: add {Unm,M}outFlagsToOpts helpers <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7783>
[16:37] <mvo> jdstrand: 2.43 is ~4 weeks away
[16:37] <zyga> ijohnson, mborzecki: https://github.com/snapcore/snapd/pull/7784 is no longer stacked. It's not urgent though
[16:37] <mup> PR #7784: cmd/snap-update-ns: adjust debugging output for usability <Created by zyga> <https://github.com/snapcore/snapd/pull/7784>
[16:38] <ijohnson> zyga: yes will review after I submit a PR changing that to a list for you :-)
[16:38] <mvo> jdstrand: 7777 is merged
[16:38] <zyga> ijohnson: sounds great :)
[16:38] <zyga> mvo: let's cherry pick it
[16:39] <jdstrand> mvo: ah, cool
[16:39] <mvo> zyga: cherry pick which one?
[16:39] <mvo> zyga: I cherry picked 7777
[16:39] <jdstrand> pedronis: I added the comment to https://github.com/snapcore/snapd/pull/7779
[16:39] <mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
[16:40] <zyga> mvo: ah, perfect
[16:40] <zyga> yeah, that one
[16:40] <zyga> it's just a pair of denials for something that is not allowed
[16:40] <jdstrand> pedronis: assuming you are happy with it, this would be a candidate for 2.42.3 for mvo imho
[16:40] <zyga> mvo: and cuts logging
[16:41] <pedronis> jdstrand: which one?
[16:41] <pedronis> 7779 ?
[16:41] <jdstrand> ondra: how fast can you switch over to raw-volume in that snap? trying to figure out if this must be in 2.42.3 or waiting for 2.43 as planned (at least a week more if 2.43)
[16:42] <jdstrand> pedronis: 7779 has the comment change, yes. that I think would be good in .3 and is ready to go once you do final review (you have a request changes)
[16:42] <ondra> jdstrand it's not time critical as they are using system-files. And switching would need to be added to customers dev cycle
[16:42] <ondra> jdstrand so I'd not gate 2.43 with it
[16:43] <jdstrand> pedronis: I also updated PR 7768 (raw-volume), but per ondra, this is not critical for 2.42.3
[16:43] <mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
[16:43] <ondra> jdstrand and thank you for working on it. I really like the PR
[16:45] <jdstrand> ondra: cool, yw
[16:45] <pedronis> jdstrand: looking at 7779 in a short bit, having parallel discussions
[16:45] <jdstrand> mvo: I'm investigating thresh' denial, but it isn't critical and will be in a separate PR
[16:46] <jdstrand> mvo: ie, I might have a small PR. I'm not changing 7779
[16:46] <jdstrand> mvo: in case it wasn't clear. ignore PR 7768 (raw-volume) for 2.42.3
[16:46] <mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
[16:47] <pedronis> jdstrand: done with 7779, it's ok for .3 for me, if you are comfortable with that yourself
[16:49] <mvo> jdstrand: thanks! ok, please tag everything you want for 2.42 with the 2.42 milestone
[16:49] <pedronis> jdstrand: thanks for the work on raw-volume, I will re-review it,  not today though given is not a blocker
[16:50] <jdstrand> mvo: ok, https://github.com/snapcore/snapd/pull/7779 updated, though it has to run through spread for the comment update that was requested
[16:50] <jdstrand> (that is happening now)
[16:50] <mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
[16:57] <mup> PR snapcraft#2822 opened: xattrs: ignore errors if SNAPCRAFT_BUILD_INFO is unset <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2822>
[16:57] <mup> PR snapcraft#2823 opened: xattrs: switch to python's os package for reading/writing xattrs <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2823>
[17:01] <mup> PR snapd#7798 opened: interfaces/browser-support: allow reading status of huge pages <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7798>
[17:01] <jdstrand> mvo: ok, PR 7798 milestoned for 2.42.3
[17:01] <mup> PR #7798: interfaces/browser-support: allow reading status of huge pages <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7798>
[17:02] <zyga> jdstrand: FYI, there's a corresponding launchpad milestone, if there are bugs you can have them target that release
[17:03] <jdstrand> zyga: ack
[17:04] <mvo> jdstrand: thank you
[17:08] <zyga> brb, tea
[17:11] <pedronis> mvo: what are the next UC20 PRs that need review?
[17:15] <mvo> pedronis: 7792 should be an easy one
[17:15] <mvo> pedronis: then 7793 which is also easy
[17:15] <mvo> pedronis: and 7797 should also be easy, I tried to make them all bite-size :)
[17:16] <mvo> pedronis: once 7793 is in I will do one more and then help with 7762
[17:21] <pedronis> mvo: thanks, not sure how much more I will do tonight, but at least I know where to start tomorrow
[17:31] <mup> PR snapd#6436 closed: interfaces: add system-backup interface <Needs Samuele review> <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/6436>
[17:40] <ijohnson> zyga: alright here you go https://github.com/snapcore/snapd/pull/7799 I even benchmarked it for you :-)
[17:40] <mup> PR snapd#7799 opened: osutil/mount: de-duplicate code to use a list <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7799>
[17:40] <mup> PR #7799: osutil/mount: de-duplicate code to use a list <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7799>
[17:58] <jdstrand> degville: hey, fyi, I took a crack at https://forum.snapcraft.io/t/the-system-backup-interface/14348 and updated https://forum.snapcraft.io/t/supported-interfaces/7744
[18:21] <mup> PR snapd#7800 opened: tests: add Ubuntu Eoan to google-sru backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7800>
[18:34] <jdstrand> ogra: hey, are there some official (or at least, something you use) docs for booting a rpi off of usb hard drive?
[18:34] <jdstrand> ogra: googling finds me stuff, but I don't know if I should trust it
[18:39] <zyga> ijohnson: how would it perform if you added a break on flags == 0?
[18:39] <ijohnson> zyga: hmm, let me see
[18:40] <ijohnson> zyga: well looking at it before I even write the code, none of the benchmarks I have will result in that because flags isn't 0 with any of the test cases
[18:41] <ijohnson> zyga: is 0 a common case for mounts we do? if so I can add it to the test case, but it feels like that wouldn't happen "in the wirld"
[18:41] <ijohnson> s/wirld/wild/
[18:42] <zyga> ijohnson: zero mid-loop
[18:42] <zyga> It will usually have one or two flags
[18:42] <ijohnson> ah I see what you mean
[18:44] <zyga> ijohnson: we could even reorder flags to put most common first
[18:44] <zyga> ijohnson: thank you for doing that
[18:44] <ijohnson> yes good point if we are going to break early then putting most common flags first makes a lot of sense
[18:45] <zyga> ijohnson: sorry for being absent
[18:45] <zyga> ijohnson: I'll show you what I was doing
[18:45] <ijohnson> zyga: don't worry about it
[18:46] <thresh> oSoMoN, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1854091 there you go
[18:46] <mup> Bug #1854091: [snap] traps on start <chromium-browser (Ubuntu):New> <https://launchpad.net/bugs/1854091>
[18:46] <thresh> oSoMoN, let me know if I can provide any more information.  thank you!
[18:46] <zyga> ijohnson: https://twitter.com/zygoon/status/1199399096399859712
[18:47] <ijohnson> :-) seems like a better use of time than looking ay my silly optimizations of a couple nanoseconds
[18:52] <mvo> pedronis: thank you!
[18:53] <zyga> mvo: gadget update pc fails on the release branch
[18:53] <zyga> mvo: I think we need to backport the fix for that one first
[18:53] <mvo> zyga: uh, right. are you on this or shall I have a look?
[18:53] <zyga> I'll find it and send it
[18:53] <zyga> mvo: just woke up :)
[18:56] <zyga> done
[18:56] <mup> PR snapd#7801 opened: tests/main/gadget-update-pc: use a program to modify gadget yaml (#7785) <Created by zyga> <https://github.com/snapcore/snapd/pull/7801>
[19:01] <murthy> why mojo video decoder is not enabled for chromium snap?
[19:13] <mvo> zyga: thank you!
[19:26] <mup> PR snapd#7802 opened: update system-backup tests to not check for sanitize errors related to os <Simple 😃> <⚠ Critical> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7802>
[19:27] <jdstrand> mvo: erf, ^ needed for master
[19:29] <jdstrand> mvo: basically, something changed out from under the system-backup PR and the tests weren't re-run before committing. this fixes that
[19:31] <murthy> Reference article: https://www.phoronix.com/scan.php?page=news_item&px=Chrome-73-Linux-Mojo-Video-Dec
[19:32] <murthy> according to the above article chromium has enabled mojo video decoder by default on windows
[19:33] <murthy> and chromium provides hardware acceleration for video playback via mojo video decoder
[19:33] <murthy> This is the bug tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=522298
[19:35] <murthy> According to the Comment 51 in the bug tracker you can enable mojo decoder by setting the gn arg of "use_vaapi" to true
[19:35] <murthy> during compilation I mean
[19:35] <Chipaca> oSoMoN: ^
[19:39] <pedronis> jdstrand: yes, our CI is fragile to that, it's a good idea to merge master in any long lived PR
[19:40] <jdstrand> pedronis: yeah, that is what I was thinking :\
[19:45] <oSoMoN> thresh, Chipaca: thanks
[19:48] <mvo> jdstrand: thank you
[19:49] <mup> PR snapcraft#2824 opened: Support for go.mod <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2824>
[19:49] <mvo> thanks zyga for 7801
[19:49] <zyga> :)
[19:52] <ijohnson> oh zyga btw adding a check in the loop slows everything down oddly enough :-(
[19:53] <ijohnson> https://www.irccloud.com/pastebin/F2LyBHTL/
[19:55] <vidal72[m]> murthy: do you know any distro that enabled that option? I assume it's disabled for a reason
[19:57] <murthy> vidal72[m]: probably fedora
[19:58] <vidal72[m]> murthy: nope, see comment https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec#_1810
[19:58] <vidal72[m]> https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec#_23
[20:00] <vidal72[m]> I don't think it's worth hitting all regressions others had with vaapi
[20:00] <vidal72[m]> without upstream support this is hopeless
[20:04] <vidal72[m]> murthy: Arch linux also disabled vaapi after trying it https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/chromium&id=493cb5bf7b8453f628ee74ae75add8699ad244f0
[20:04] <murthy> vidal72[m]: It only enables mojo video decoder, users have to enable the "Override software rendering list" flag to enable hardware acceleration using vaapi
[20:05] <murthy> checking
[20:09] <murthy> It seems they had specifically reverted that patch
[20:09] <vidal72[m]> heh
[20:10] <vidal72[m]> RIP vaapi :(
[20:10] <murthy> Its just that I tried a chromium build from an an unofficial ppa and it seems stable
[20:10] <murthy> vidal72[m]: Intel is not doing a good job for Linux
[20:10] <vidal72[m]> I think it depends on hardware
[20:11] <murthy> right
[20:11] <murthy> Mine is a kabylake
[20:11] <vidal72[m]> intel is still miles ahead of amd and nvidia :)
[20:11] <murthy> what?
[20:12] <vidal72[m]> I heard that most vaapi issues come from amd
[20:13] <murthy> vidal72[m]: also downstream packaging restrictions
[20:14] <murthy> This is the article that said vaapi was enabled in fedora https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Snaps-Chromium-VA-API
[20:14] <murthy> phoronix fellows know how to get the clicks
[20:14] <vidal72[m]> murthy: then enabled it then disabled, same as Arch
[20:14] <vidal72[m]> *they
[20:14] <murthy> ya
[20:16] <murthy> Do you know this ppa? Can I trust it? https://launchpad.net/~saiarcot895/+archive/ubuntu/chromium-beta
[20:16] <vidal72[m]> I don't know it
[20:18] <murthy> ok
[20:18] <murthy> vidal72[m]: Thanks for the support
[20:33] <zyga> mvo: is master still broken
[20:34] <zyga> I can jump into that
[20:35]  * zyga checks
[20:38] <zyga> heh
[20:38] <zyga> funny
[20:42] <mvo> zyga: didn't jamie fix this?
[20:42] <zyga> ah, I see
[20:42] <mvo> zyga: unit test failure it seems, fun
[20:42] <zyga> I'll send a useful patch nonetheless
[20:43] <zyga> we have some leftover junk
[20:43] <mvo> zyga: invalid title
[20:43] <mvo> zyga: fun!
[20:43] <mvo> zyga: restarted the build
[20:43] <zyga> eh
[20:43] <zyga> :D
[20:43] <zyga> must be OMG RELEASE DAY
[20:44] <mvo> zyga: haha yes
[20:49] <zyga> mvo: https://github.com/snapcore/snapd/pull/7803
[20:49] <mup> PR #7803: interfaces: remove reservedForOS from commonInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/7803>
[20:49] <mvo> zyga: nice, thank you
[20:49] <mup> PR snapd#7803 opened: interfaces: remove reservedForOS from commonInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/7803>
[20:50] <zyga> mvo: meanwhile https://github.com/snapcore/snapd/pull/7801 is still yellow
[20:50] <mup> PR #7801: tests/main/gadget-update-pc: use a program to modify gadget yaml (2.42) <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/7801>
[20:50] <mvo> zyga: yeah, it's a bit sad
[20:50] <zyga> about 20 minutes left
[20:51] <zyga> if it passes
[20:51] <mvo> zyga: I call it a day, hopefully in 8h when I'm up again the world is less red
[20:51] <zyga> yeah
[20:51] <zyga> I'll merge and restart anything I can
[20:51] <zyga> mvo: can I merge stuff into the release branch with one review?
[20:51] <zyga> mvo: it could be all merged for you in the morning
[20:51] <mvo> zyga: I think that's fine, strict backports just need one review
[20:51] <zyga> ok
[20:51] <zyga> technically https://github.com/snapcore/snapd/pull/7801 is not reviewed
[20:52] <zyga> that's the fix to unbreak others :)
[20:52] <mup> PR #7801: tests/main/gadget-update-pc: use a program to modify gadget yaml (2.42) <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/7801>
[20:52] <mvo> zyga: refresh please
[20:52] <zyga> \o/
[20:52] <zyga> thanks!
[20:52] <zyga> I had a nap so I can work for the next 45 minutes
[20:53] <zyga> if that helps tomorrow that's useful
[20:53] <zyga> tomorrow I'm back to feature work
[20:53] <zyga> I have some follow ups for the update-ns that pedronis suggested
[20:53] <zyga> but we have enough open PRs now
[20:53] <mvo> zyga: thank you ! much appreciated. just make sure you don't overdo it, if you feel sleepy/want-to-do-something-else just do it :)
[20:53] <zyga> yeah
[20:53] <zyga> I totally will :)
[20:54]  * mvo hugs zyga and vanishes
[20:54] <zyga> o/
[21:03] <sdhd-sascha> Chipaca: i have trouble with upload to the store. But yesterday i could start sway in classic mode. It's on github
[21:17]  * cachio afk
[21:31] <zyga> oh for crying out loud ....
[21:32] <zyga> timeout
[21:39] <ijohnson> hey zyga, looks like I missed some stuff that happened while out to lunch, what can I help review to unbreak master/critical things?
[21:40] <zyga> ijohnson: it's all fixed now, jdstrand sent a followup PR
[21:40] <zyga> we're just waiting for things to be less red
[21:40] <ijohnson> zyga: ack ok
[21:50] <zyga> another one failed
[21:50] <zyga> I'll call it a day
[21:52] <ijohnson> good night zyga, see you tomorrow
[22:25] <mup> PR snapd#7802 closed: interfaces: update system-backup tests to not check for sanitize errors related to os <Simple 😃> <⚠ Critical> <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/7802>
[22:25] <jdstrand> ijohnson: ^
[22:26] <ijohnson> Right, nice
[23:04] <cmatsuoka> devicestate tests are very intersting, but it's time to call it a day


[14:58] <tmkt> Anyone have any issues with the release of last weeks updates?
[14:58] <tmkt> My myth box has been hard freezing since the install
[18:18] <louisdk> What happens if I force a recording and then have planned two recordings and the same time with only one tuner?
[19:31] <tgm4883> louisdk, I'm guessing here, but it probably depends. I would think that either A) the forced recording would record and the other recording would be rescheduled if possible, or B) It would try to schedule both if it could (moving one of them to a later time) and if not possible revert to A
[19:31] <tgm4883> louisdk, I think A is more likely
[19:31] <tgm4883> louisdk, this is something you could test by forcing a recording and looking at mythweb
[19:41] <louisdk> tgm4883: Okay. I'll look at that. Thanks :)


  Do you know that?
[09:42] <gluttony> yeah, sd1
[09:42] <jrib> sd1?
[09:42] <jrib> you sure?
[09:42] <jrib> sdb1 maybe?
[09:43] <gluttony> sda1, sorry
[09:44] <jrib> and what is your / now?
[09:44] <gluttony> my what?
[09:44] <gluttony> hda3
[09:44] <gluttony> /dev/hda3 to be exact
[09:44] <jrib> ok so here is how to move your home:
[09:45] <jrib> 1. reboot in recovery mode
[09:45] <jrib> 2. mount /dev/sdb1 somewhere
[09:45] <gluttony> youve lost me already
[09:45] <jrib> 3. mv /home/* /place/you/mounted/sdb1
[09:45] <jrib> ok I'll go over each one you have questions on at the end
[09:46] <jrib> 4. edit fstab to mount sdb1 as /home
[09:46] <jrib> 5. reboot
[09:46] <jrib> gluttony: ok what's the first thing you are unsure of?
[09:47] <gluttony> pretty much each step, cept 5
[09:47] <jrib> :)
[09:47] <gluttony> like, i dont even have a sdb1
[09:47] <jrib> ok, 1. recovery mode is a choice from the grub menu when you boot
[09:47] <jrib> sorry, sda1
[09:48] <jrib> gluttony: so 1 should make sense now?
[09:48] <gluttony> the grub menu, thats that list ok stuff at boot to pick from, right?
[09:48] <jrib> right
[09:49] <gluttony> is it suppoed to have a bunch of entries?
[09:49] <jrib> yes
[09:49] <gluttony> ok. because when i first installed ubuntu, it didnt have so many choices
[09:49] <jrib> "recovery mode" should definitely be there
[09:50] <gluttony> ok
[09:50] <jrib> alright, so 2. now
[09:50] <gluttony> just to clairfy, this is the list that has windows on it too,right?
[09:50] <jrib> yep
[09:51] <gluttony> ok
[09:51] <jrib> gluttony: what happens to sda1 now?  does it get automatically mounted somewhere?
[09:51] <gluttony> hell if i know
[09:52] <gluttony> i guess it does
[09:52] <jrib> gluttony: pastebin your /etc/fstab
[09:53] <gluttony> pastbin? not certain of that terminology
[09:53] <jrib> !pastebin
[09:53] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[09:55] <gluttony> http://paste.ubuntu-nl.org/21602/
[09:55] <gluttony> ubotu: thanks
[09:55] <ubotu> You're welcome! But keep in mind I'm just a bot ;-)
[09:56] <jrib> gluttony: hmm sda1 seems to be being used as /usr already
[09:56] <gluttony> really?
[09:57] <jrib> yep
[09:58] <gluttony> im cnfused about how all of this works. what is kept in /usr?
[09:58] <jrib> gluttony: most of the stuff you install ends up somewhere in /usr
[09:58] <jrib> !fhs
[09:58] <ubotu> The files and directories on an Ubuntu system are organized according to a standard, see http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard - file permissions are explained at https://help.ubuntu.com/community/FilePermissions - All filenames and directory names (and many other things) are case sensitive in Linux
[09:59] <gluttony> ok
[09:59] <gluttony> so, where is my home? is home usr or what?
[10:00] <jrib> home is /home and usr is /usr
[10:00] <jrib> your /usr is on a seperate partition
[10:00] <jrib> everyting else is /hda3
[10:00] <jrib> then you have a seap at hda2 and some windows partition on hda1
[10:01] <jrib> s/seap/swap
[10:01] <gluttony> ive tried creating folders in usr, but it didt work
[10:02] <jrib> you usually do not want to modify anything outside your home
[10:02] <gluttony> so i dont want to save stuff to usr?
[10:03] <jrib> no
[10:03] <gluttony> damn, then i made my /usr too big
[10:03] <jrib> pastebin:  df -h
[10:03] <gluttony> and /home too small
[10:05] <gluttony> http://paste.ubuntu-nl.org/21604/
[10:06] <jrib> gluttony: what sda2 for?
[10:08] <gluttony> windows
[10:08] <jrib> well I guess you could move /usr back to hda3 and then move home there
[10:08] <jrib> "there" being sda1
[10:09] <gluttony> but sda2 is in use
[10:09] <jrib> sda1
[10:09] <gluttony> they both are in use
[10:09] <jrib> right but sda1 is being used as /usr, so just move /usr to hda3
[10:10] <gluttony> will it fit?
[10:10] <jrib> yeah
[10:10] <jrib> it's only using 3GB
[10:11] <gluttony> ok, how do i do that
[10:11] <jrib> and you have 10GB free on /
[10:12] <gluttony> ok, so what do i do to move home to sda1, and usr to hda3?
[10:14] <gluttony> and what goes in usr?
[10:14] <jrib>  /usr has most of the stuff you install
[10:15] <gluttony> well, will those 10 gigs be able to hold any app installs?
[10:15] <jrib> gluttony: it's probably a good idea to copy /usr over to / first
[10:15] <jrib> gluttony: definitely
[10:15] <gluttony> ok
[10:16] <jrib> sudo cp -a /usr /usr.backup
[10:16] <jrib> that's a command
[10:16] <gluttony> can i put home and user on the same drive?
[10:17] <jrib> if you create two partitions I guess
[10:17] <gluttony> so i can resize an existing partion in Gparted? without deleting it
[10:17] <jrib> 20gb is plenty for stuff other than /home.  Remember that you are moving your /home out so you'll get more space
[10:18] <gluttony> ok
[10:18] <gluttony> ok, i gave the command. if theres any future command, i need sudo to use them, fyi.
[10:19] <jrib> is it still going?
[10:20] <gluttony> it hasnt even started. the cursor is just blinking
[10:20] <jrib> yeah it will take a while
[10:20] <gluttony> ok
[10:20] <gluttony> after that, what do i do?
[10:20] <jrib> edit your fstab
[10:20] <jrib> I guess we can do that now
[10:21] <gluttony> can you step by step help me?
[10:22] <jrib> gluttony: do you still have your fstab open?
[10:22] <gluttony> no
[10:22] <jrib> gluttony: gksudo gedit /etc/fstab
[10:23] <gluttony> whats the gk mean?
[10:24] <jrib> !gksudo
[10:24] <ubotu> If you need to run graphical applications as root, use  gksudo , as it will set up the environment more appropriately. Avoid ever using  sudo <GUI-application>
[10:24] <gluttony> ok
[10:24] <gluttony> i have fstab open now
[10:25] <jrib> put a  #  in front of a line 10
[10:25] <gluttony> ok, whats that do?
[10:25] <jrib> it comments that line so it doesn't get read
[10:26] <gluttony> sudo cp .... is done by the way
[10:26] <jrib> k
[10:26] <jrib> no errrors right?
[10:26] <gluttony> im just curious why that line needs to not be read
[10:26] <gluttony> right, no errors
[10:27] <jrib> gluttony: ok done with fstab?
[10:27] <gluttony> yeah, i put in the comment
[10:27] <gluttony> what did sudo cp do?
[10:28] <jrib> it copied your /usr on sda1 to /usr/backup on hda3
[10:28] <gluttony> ok
[10:28] <jrib> ok, now I think the next step will probably fail, but we'll try...
[10:28] <jrib> sudo umount /dev/sda1
[10:29] <gluttony> command not found
[10:29] <jrib> what is the full error output?
[10:29] <gluttony> sudo: unmount: command not found
[10:29] <jrib> "umount" not "unmount"
[10:30] <gluttony> umount: /dev/sda1: not mounted
[10:31] <jrib> hmm
[10:31] <jrib> type "mount"
[10:31] <jrib> or did you use the command twice?
[10:31] <gluttony> nope
[10:32] <gluttony> ok, i ran mount
[10:32] <jrib> gluttony: do:  sudo umount /usr
[10:32] <gluttony> umount: /usr: device is busy
[10:32] <gluttony> umount: /usr: device is busy
[10:32] <jrib> yeah okay
[10:32] <jrib> you'll have to reboot in recovery mode
[10:33] <gluttony> ok, i can still use xchat right?
[10:33] <jrib> no
[10:33] <jrib> it's one command that you need to do:  sudo mv /usr.backup /usr
[10:33] <jrib> then reboot
[10:33] <jrib> if you run into trouble boot windows and come here :)
[10:41] <gluttony> ok, how do i check that i worked?
[10:41] <jrib> it worked
[10:42] <gluttony> ok
[10:42] <jrib> you can type "mount" and check if /usr is on sda1 or not if you want
[10:43] <gluttony> i cant tel
[10:43] <jrib> pastebin
[10:44] <gluttony> http://paste.ubuntu-nl.org/21610/
[10:45] <jrib> pastebin your fstab
[10:45] <gluttony> whats the fstab open command again?
[10:45] <jrib> gedit /etc/fstab
[10:46] <gluttony> http://paste.ubuntu-nl.org/21612/
[10:46] <jrib> line 10 isn't commented
[10:46] <gluttony> i know i put it there earlier
[10:47] <jrib> you must not have saved
[10:47] <gluttony> oh, lol, i didnt save it.....
[10:47] <gluttony> it wont let me save. i can only do save as
[10:47] <jrib> close it
[10:48] <jrib> then: gksudo gedit /etc/fstab
[10:49] <gluttony> ok
[10:49] <gluttony> saved do i need to recovery again?
[10:49] <jrib> just reboot
[10:56] <jrib> guess something went wrong...
[10:57] <jrib> oh wait I know what happened
[10:57] <jrib> when he booted in recovery mode he did mv /usr.backup /usr   which put everything back in sda1...
[11:05] <jrib> neversfelde: here to stay?
[11:10] <jrib> I'm going to be afk for a bit... if gluttony returns on windows, tell him about the windows driver so he can edit files (!ext3) and have him uncomment line 10 in his fstab that will get him back to step 1
[11:14] <gluttony> jrib: that didnt work
[11:15] <gluttony> jrib: im running off the live cd right now
[11:16] <jrib> I'm going to be afk for a bit... if gluttony returns on windows, tell him about the windows driver so he can edit files (!ext3) and have him uncomment line 10 in his fstab that will get him back to step 1
[11:17] <jrib> gluttony: yeah, error in my logic
[11:17] <jrib> not saving fstab before made the mv command do something else
[11:17] <gluttony> ok, so what do i do to fix it?
[11:17] <jrib> gluttony: open a terminal
[11:17] <jrib> sudo mkdir /media/linux
[11:18] <gluttony> will this work on the live cd?
[11:18] <jrib> yes
[11:18] <jrib> sudo mount /dev/hda3 /media/linux
[11:18] <jrib> does that work?
[11:18] <jrib> actually
[11:18] <jrib> now that you are on the live cd we can do the whole thing from here
[11:19] <gluttony> ok
[11:19] <jrib> gluttony: do you have a bunch of file if you go to /media/linux now?
[11:19] <gluttony> still run the command?
[11:19] <jrib> sudo mkdir /media/linux
[11:19] <gluttony> how do i check?
[11:19] <jrib> sudo mount /dev/hda3 /media/linux
[11:19] <jrib> "nautilus /media/linux"
[11:20] <gluttony> pop up said "counld not find
[11:21] <jrib> gluttony: ok
[11:21] <jrib> run this command: sudo mkdir /media/linux
[11:21] <jrib> tell me any output
[11:23] <jrib> gluttony: are you there?
[11:23] <gluttony> sorry,
[11:24] <gluttony> mkdir: cannot create directory `media/linux': No such file or directory
[11:24] <jrib> did you type "sudo mkdir /media/linux"  with two '/' in there?


[06:56] <dholbach> good morning
[07:35] <bkerensa> dholbach: top of the morning
[07:35] <dholbach> hey
[09:07] <effiejayx> Hello all


[02:47] <XDevHald> Rocket2DMn: Did you have anything you wanted me to do?
[02:50] <Rocket2DMn> XDevHald, there are some suggested pages remaining from the BT's summer of documentation here - https://help.ubuntu.com/community/Beginners/Development
[02:50] <Rocket2DMn> I'll be workingon putting together a page like that for the doc team directly
[02:50] <Rocket2DMn> otherwise, there are pages that are tagged - https://help.ubuntu.com/community/Tag
[02:51] <XDevHald> Thanks Rocket
[02:51] <starcraftman> Rocket2DMn, hey rocket, we still got no huc page specifically for GRUB2 right?
[02:52] <Rocket2DMn> starcraftman, that's right, i just set a redirect to the team wiki's documentation
[02:53] <Rocket2DMn> it would be good to get some real documentation there soon
[02:53] <starcraftman> Rocket2DMn, drs just pointed me to this > https://wiki.ubuntu.com/Grub2
[02:53] <Rocket2DMn> yea starcraftman that's where the community doc pages redirects right now
[02:53] <starcraftman> Rough, but someone with more knowledge than I on grub2 should clean it up and convert.
[02:53] <starcraftman> Ah, ok, just making sure.
[02:54] <Rocket2DMn> yeah, somebody may need to get down and dirty with grub2 here.  i'll be willing if i can find the time, though i'm not sure if i can find that time
[02:54] <starcraftman> I'll add it to beginners dev list of things to do.
[02:54] <Rocket2DMn> however, it doesn't need to be an all-or-nothing approach at first
[02:54] <Rocket2DMn> start with the basics, and if the page is structured well, it should be easy to expand
[03:03] <starcraftman> Rocket2DMn, k, added to list for creation. I'll have a look at it on friday, got time. Though I haven't really played with grub2 at all.
[03:08] <Rocket2DMn> cool starcraftman , thanks
[15:33] <Zachk18> starcraftman!
[15:34] <starcraftman> wahhhhhhhhhhh
[15:34] <starcraftman> yes?
[15:35] <Zachk18> starcraftman, oh nothing...just sayin hey dude
[15:35] <starcraftman> hehe


[15:28] <micahf> hi, i'm having trouble with multi-touch in chrome.  two finger gestures (sorta) work, but i can't get multiple touch events!
[15:28] <micahf> i have a tablet laptop (lenovo x220)
[15:29] <micahf> i used to be able to get multiple touch events in ubuntu 13.10 with an acer w700 tablet


[00:58] <tlevine> autopsy: thanks for the suggestions but I'm not planning on using syslinux
[00:58] <tlevine> "really good" takes much longer 😄
[03:14] <lupino2b> ls-remote did not returned anything
[03:14] <lupino2b> (the `result` isn't important, say it's just `id input`)
[06:44] <Unit193> bashfulrobot: Still here?
[09:14] <Truk> Dual physical Sim is CN only.
[09:14] <Truk> leftyfb: should it be sda8?
[10:42] <sklgrome1> It is true that only rich people buy iPhones in Asia
[10:42] <sklgrome1> freakynl, after it gets answer of course
[15:24] <bashfulrobot> Unit193: yes I am.
[19:06] <Unit193> bashfulrobot: Was reminded of your request, checked in and looked like you folks were still having spam.  IRC Council was on the list, so I've set +r for now.
[19:07] <bashfulrobot> Unit193: I appreciate that.
[19:07] <bashfulrobot> Unit193: it seems like overall IRC has been overridden with spam in general lately.
[19:10] <Unit193> bashfulrobot: Yeah there's been more.  I noticed only one user wasn't identified, and you folks will want to use SASL so as to avoid hitting +r.
[19:11] <bashfulrobot> Unit193: pretty sure I am (should be) using SASL. I appreciate your assistance.


[07:41] <handsome_feng>  Hi, Would someone please upload the new packages? They have been approved: LP: #1792261 LP: #1792265 LP: #1792267 LP: #1792269 Thanks in advance!


[06:00] <studio-user646> hi
[21:07] <studio-user083> Hi Ubuntu land, is anyone out there? I've a question about adb list of attached devices saying unauthorized
[21:53] <OvenWerks> studio-user083: Can I assume you are trying to talk to an android device?
[21:54] <OvenWerks> If so, the android device has to give permission for whatever kind of access this requires
[21:55] <OvenWerks> gone...