[01:15] <mup> PR snapcraft#3314 closed: schema: add missing name item in package-repositories <Created by jc-lab> <Closed by jc-lab> <https://github.com/snapcore/snapcraft/pull/3314>
[05:40] <mborzecki> morning
[06:03] <mborzecki> mvo: hey
[06:08] <mvo> good morning mborzecki
[06:22] <mborzecki> mvo: do you recall vfat corruption when we got uboot.env and UBOOT.ENV in the same fs?
[06:23] <mborzecki> mvo: do you have any tooling to corrupt the vfat from that investigation? i was able to find https://gist.github.com/bboozzoo/e68254507eef4673dd8c6f9b82f65d92 with the hope it can used in #9499
[06:23] <mup> PR #9499: tests: add tests for fsck <Created by zyga> <https://github.com/snapcore/snapd/pull/9499>
[06:31] <mvo> mborzecki: I found some go libraries to directly access fat that can probably be used for this
[06:31] <mvo> mborzecki: let me look at your stuff
[06:31] <mborzecki> mvo: fatcat?
[06:32] <mborzecki> mvo: i have a vague recollection we tried to do something with https://github.com/Gregwar/fatcat/
[06:32] <mvo> mborzecki: I don't remember exactly, let me try to look
[06:35] <mvo> mborzecki: https://github.com/mvo5/go-fs
[06:36] <mborzecki> mvo: interesting, thanks!
[06:38] <mvo> mborzecki: if you want fat32 and lfn support you will need my version but it does not do much, maybe it's actually not that great
[06:39] <zyga> good morning
[06:39] <zyga> mvo: hey!
[06:39] <mvo> good morning zyga
[06:39] <mborzecki> mvo: i was thinking that maybe we could break one of the entries, or a superblock
[06:39] <mvo> mborzecki: +1
[06:39] <mborzecki> zyga: morning, left some comments in 9499
[06:40] <zyga> thanks
[06:40] <zyga> I'm looking at those now
[06:40] <zyga> it was late so maybe a typo crept in?
[06:40] <mvo> mborzecki: we could experiment with corrupting a cluster too, up to you, I follow with popcorn from the sideline :)
[06:41] <zyga> I'll check the offsets first
[06:41] <zyga> mborzecki: I replied
[06:42] <zyga> I really think it's a separate test
[06:42] <zyga> and I think the core16 / core18 situation is unclear, for the reason I outlined in my own comments
[06:42] <zyga> so I'll start by expanding that test not to rely on early-boot kernel messages
[06:42] <zyga> mborzecki: still, we don't fsck on core20 so ... bummer
[06:42] <zyga> I suspect we have to explicitly at the level we are at now
[06:43] <mborzecki> zyga: yeah, i recall ian mentioning something about fsck when he worked on snap-bootstrap
[06:43] <zyga> mborzecki: the good thing is - we know :)
[06:43] <zyga> the bad thing is, it's not good :)
[06:45] <zyga> mborzecki: separately I think we should consider re-mouting vfat as read only
[06:45] <zyga> ubuntu-seed is writable and we mount snaps from there
[06:45] <zyga> it's just waiting to corrupt and die
[06:45] <zyga> we could really keep it read only for most of the runtime of a device
[06:45] <zyga> and only remount to writable when we need to perform a specific operation
[06:45] <zyga> read-only fat doesn't corrupt on power loss
[06:47] <mborzecki> zyga: yeah, it was raised for uc20
[06:56] <zyga> mmm, good
[06:56] <zyga> today is a weird day, no school for kids, wife sick and back from work
[06:56] <zyga> feels like back to quarantine
[07:00] <pstolowski> morning
[07:00] <pstolowski> zyga: hey, i think we forgot to mount boot back after fsck yesterday, that's why core18 failed to refresh :)
[07:01] <zyga> pstolowski: hmmm, could be but I don't recall
[07:01] <zyga> pstolowski: we can look at that again
[07:01] <pstolowski> yes i just checked
[07:01] <zyga> pstolowski: maybe at ... 9:30?
[07:01] <pstolowski> ok
[07:01] <zyga> I need to move back to the office and grab coffee (still upstairs in the kitchen)
[07:01] <pstolowski> that's also an interesting material for spread test
[07:01] <zyga> pstolowski: unmounted boot?
[07:01] <amurray> zyga: hey so I tried your approach but I am not having much success (I think I am not using the right path for the core snap or perhaps am missing something else) - is this about what you had in mind? https://pastebin.ubuntu.com/p/2FXrMhN2Ck/
[07:01] <pstolowski> zyga: yes, but just to provoke failure of refresh
[07:02] <zyga> pstolowski: indeed
[07:02] <zyga> amurray: hey!
[07:02] <zyga> amurray: looking
[07:03] <zyga> amurray: it looks semi okay, I think the current symlink may be a problem, we code defensively and we avoid mounting over symlinks
[07:03] <zyga> what happens in your case?
[07:03] <amurray> zyga: this results in the following: https://pastebin.ubuntu.com/p/mf8fGRW6dr/ so I think it is on the right track
[07:03] <zyga> yeah
[07:03] <zyga> that definitely looks good
[07:03] <amurray> ahh current symlink... do you know how I could know what the actual path would be then to the core snap?
[07:04] <amurray> *or should I say whatever the base snap would be?
[07:04] <zyga> amurray: this _may_ be a little more complex, I came to realize, because we cannot easily capture the base revision
[07:04] <zyga> amurray: so without checking I suspect this is good on paper but breaks because snap-update-ns doesn't want to mount with a source /snap/core/current
[07:05] <zyga> but it also shows a deeper problem, that now the snap has an explicit relationship to the base snap
[07:05] <zyga> amurray: so when the base revision changes, ... what then?
[07:05] <zyga> amurray: normally we have some logic to re-create the mount namespace in that case
[07:05] <amurray> zyga: also do you know how I can debug what snap-update-ns is doing...?
[07:05] <amurray> ah right.. so on base refresh...
[07:05] <zyga> amurray: yes, export SNAP_DEBUG or SNAPD_DEBUG and run it by hand
[07:05] <zyga> you can actually do something simpler
[07:06] <zyga> just set SNAP_CONFINE_DEBUG=1 and snap run --shell docker
[07:06] <zyga> this will give you a lot of details
[07:06] <zyga> it's a bit complex
[07:06] <zyga> because those snaps have services
[07:06] <zyga> it may be better to start with a fake-docker snap that just has the interface
[07:06] <zyga> connect it
[07:06] <zyga> and then see what happens
[07:06] <zyga> otherwise the mount namespace is created by the service app they contain
[07:06] <zyga> and you don't see everything
[07:07] <zyga> by using a new fake snap you can run it by hand with more exact control
[07:07] <zyga> amurray: my advice is to see exactly what happens in snap-update-ns first
[07:07] <zyga> amurray: and then consider two options:
[07:08] <zyga> amurray: special-case /snap/$name/current as source and de-reference that in snap-update-ns
[07:08] <zyga> amurray: explicitly teach snap-update-ns about $BASE_SNAP_NAME $BASE_SNAP_REVISION
[07:08] <zyga> (those variables are made up)
[07:08] <zyga> snap-update-ns could expand those variables and we could use those variables in the mount profile
[07:08] <zyga> then we don't need to special case a path
[07:09] <zyga> and the feature may be useful for other things
[07:09] <zyga> amurray: how does that sound?
[07:11] <amurray> it sounds a lot harder than the snap-confine approach... but if it is the better solution then I'll keep plugging away at it - you said 'see exactly what happens in snap-update-ns' - I am still not sure how to see that.. .I tried running snapd manually with SNAP_DEBUG etc but it didn't seem to show anything relevant
[07:12] <zyga> amurray: don't run snapd with debug
[07:12] <zyga> amurray: run snap run with debug
[07:12] <zyga> snap run invokes snap-confine which invokes snap-update-ns
[07:12] <zyga> if you enable debug there you will see that
[07:13] <zyga> one sec
[07:14] <amurray> hmm https://pastebin.ubuntu.com/p/mDGTJp7GCH/ - I think the 'DEBUG: joined preserved mount namespace docker' means it is not showing what is actually happening
[07:14] <zyga> amurray: zyga@x240:~$ SNAPD_DEBUG=yes snap run gimp
[07:14] <zyga> amurray: exactly, because the service has constructed the mount namespace and you are not seeing that anymore
[07:14] <zyga> amurray: you can work around that without a new snap though
[07:14] <zyga> amurray: just stop all docker services
[07:14] <zyga> amurray: discard the mount namespace with sudo /usr/lib/snapd/snap-discard-ns docker
[07:15] <zyga> and then run
[07:15] <zyga> SNAPD_DEBUG=yes snap run --shell docker
[07:15] <zyga> that will give you the full output
[07:15] <zyga> amurray: snap-confine-based approach is possible too but it would be coarse and unable to handle interfaces
[07:15] <zyga> I'd prefer to avoid that
[07:16] <zyga> and it's a step in the wrong direction in a way, as we want to avoid sharing /etc over time, and have less rigid set of mounts there
[07:17] <amurray> yep that did it (snap-discard-ns) - https://pastebin.ubuntu.com/p/Nx3C4VgCPt/ - ok I gotta run to pick up my daughter but will check back with you later tonight - thanks again for your help :)
[07:19] <zyga> amurray: ack
[07:23]  * zyga improved the fsck test and is running it to see if core16 really fscks or not
[07:23] <zyga> mborzecki: I need a review for https://github.com/snapcore/snapd/pull/9446
[07:23] <mup> PR #9446: overlord,usersession: initial notifications of pending refreshes <Created by zyga> <https://github.com/snapcore/snapd/pull/9446>
[07:23] <zyga> mvo: ^ and perhaps you since ian is off this week?
[07:24] <zyga> mborzecki:     - google:fedora-31-64:tests/main/sudo-env is that due to sudo changes in fedora?
[07:25] <zyga>     - google:arch-linux-64:tests/main/snapshot-cross-revno failed on unrelated pr
[07:26] <zyga> pstolowski: ok, I'll set what I'm doing aside and prep for our session
[07:26] <mvo> zyga: yes, it's on my list but I suck and have not managed to get to it :/ need to do the 360 and an interview prep and then will hpoefully get to it
[07:26] <mvo> zyga: I really want this to land asap
[07:29] <mborzecki> zyga: yes, most likely due to sudo changes
[07:29] <mborzecki> zyga: i'll open a PR with the fix
[07:29] <zyga> mborzecki: superb
[07:29] <zyga> ok
[07:29] <zyga> coffee
[07:29] <zyga> pstolowski: give ma 3 minutes
[07:33] <zyga> pstolowski: just warming stuff up
[07:33] <pstolowski> ok
[07:33] <zyga> pstolowski: do you have the session?
[07:34] <pstolowski> zyga: i've now
[07:45] <zyga> mvo: drat, we don't fsck on core16 or core18
[07:45] <zyga> the test is now improved and fails everywhere
[07:45] <zyga> so .. well :)
[07:46] <mborzecki> zyga: w8, what?
[07:47] <mborzecki> aah, core16 and core18 don't use systemd in initrd, so fsck is not automagic
[07:47] <zyga> mborzecki: yep
[07:47] <zyga> mborzecki: I have a test
[07:49] <pstolowski> rogpeppe: hi
[07:49] <zyga> mborzecki: the previous test was flawed because core16 and core18 did not have systemd forwarding messages from early boot
[07:50] <zyga> anyway, I'll push the test
[07:50] <rogpeppe> pstolowski: hello!
[07:51] <pstolowski> rogpeppe: hey, we have mounted /boot back and managed to refresh core18 and everything looked ok, but unfortunately after reboot it didn't come back, cannot ssh anymore :(
[07:51] <rogpeppe> pstolowski: ok, i'll ask it to be power-cycled
[07:51] <pstolowski> rogpeppe: looks like we need a manual restart of your pi3
[07:52] <rogpeppe> pstolowski: that's what always happens, unfortunately
[07:52] <zyga> mborzecki: pushede
[07:52] <rogpeppe> pstolowski: which is a bit of a shame, because it makes the whole thing somewhat unreliable
[07:52] <pstolowski> rogpeppe: yeah, no denying, hopefully we will get to the bottom of this
[07:53] <zyga> rogpeppe: please let us know when you can power cycle it, we will try to understand what's going on
[07:53] <rogpeppe> pstolowski: i suspect that snappy will sometimes try to reboot itself to update system s/w, and this causes the machine to go down
[07:53] <zyga> mborzecki: please look at my logic in https://github.com/snapcore/snapd/pull/9499
[07:53] <mup> PR #9499: tests: add tests for fsck <Created by zyga> <https://github.com/snapcore/snapd/pull/9499>
[07:54] <zyga> mborzecki: I really would like to know if we fsck
[07:54] <zyga> and the test is wrong
[07:54] <zyga> or if we just don't fsck
[07:54] <zyga> and the test is sadly right
[07:57] <zyga> rogpeppe: pstolowski and me will resume debugging once you give us a note that the power cycle occurred
[08:00] <rogpeppe> zyga: should happen in the next 5 minutes or so; i'll let you know
[08:00] <zyga> rogpeppe: great, thank you
[08:03] <mup> PR snapd#9500 opened: tests/main/sudo-env: snap bin is avaialble on Fedora <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9500>
[08:03] <mborzecki> zyga: ^^
[08:03] <zyga> superb
[08:04] <zyga> +1
[08:08] <rogpeppe> zyga, pstolowski: ok, it's back up now. it took two power-cycles as usual.
[08:08] <zyga> rogpeppe: thank you
[08:08] <zyga> two? as in yank cable twice?
[08:09] <zyga> interesting
[08:09] <zyga> pstolowski: can you connect?
[08:10] <pstolowski> checking
[08:10] <pstolowski> zyga: yes, i can
[08:10] <zyga> pstolowski: ok, let's examine the boot partition again
[08:10] <zyga> and maybe snap changes
[08:10] <zyga> and journal?
[08:10] <zyga> shall we get back to the HO?
[08:11] <pstolowski> zyga: yes, give me 5
[08:11] <zyga> sure
[08:15] <pstolowski> ok rdy
[08:18] <zyga> we were just talking with pawel that maybe the second reboot is because we fail to do the initial reboot at all
[08:19] <mborzecki> mvo: per monday's discussion i've updated https://github.com/snapcore/snapd/pull/9420 to use 384MB for UC20
[08:19] <mup> PR #9420: tests/nested/manual/minimal-smoke: use 384MB of RAM for nested UC20 <Run nested> <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9420>
[08:31] <mvo> mborzecki: thanks! (in a meeting)
[08:33] <zyga> rogpeppe: does the device reboot correctly if you just "sudo reboot"?
[08:33] <zyga> rogpeppe: or is it also going into this weird state that requires more than one reboot to complete?
[08:34] <rogpeppe> zyga: i don't know... i'd presume not, otherwise it wouldn't have gone down last night
[08:34] <rogpeppe> zyga: shall we try?
[08:34] <zyga> mmm
[08:34] <zyga> we're still coming up with options, we may decide to try that to learn more
[08:34] <zyga> we'll let you know for sure
[08:34] <rogpeppe> zyga: ta
[08:35] <zyga> rogpeppe: no chance of a serial log? :D
[08:36] <rogpeppe> zyga: nope, i'm afraid not. i've never worked out how to get serial output from the pi.
[08:37] <rogpeppe> zyga: don't you have to solder something onto the board or something like that?
[08:40] <zyga> rogpeppe: no, just a pair of wires and a computer with usb port to capture the log
[08:41] <rogpeppe> zyga: presumably you need some kind of connector for the wires, and a serial port adaptor
[08:42] <rogpeppe> zyga: not sure my dad has either of those things around currently (actually, he _may_ have a serial port adaptor, but i'm not sure i want to get him to do all this remotely :) )
[08:42] <zyga> rogpeppe: yeah, those are super common on ebay and amazon and go for a few pounds
[08:42] <zyga> I was more of a joking, it'd be ideal for debugging
[08:42] <zyga> we're eliminating possibilities
[08:43] <rogpeppe> zyga: yeah, i've thought that before, but thought it would be too much hassle
[08:51] <zyga> rogpeppe: ok, we'd like to reboot the device without any changes
[08:51] <zyga> we have some ideas but we'd be much faster if we can do some reboots
[08:51] <zyga> without going through refresh
[08:51] <zyga> rogpeppe: is it okay if we reboot the device now?
[08:51] <rogpeppe> zyga: please do
[08:52] <zyga> ok
[08:52] <rogpeppe> zyga: let me know if you need it power-cycling again
[08:52] <rogpeppe> zyga: although i'm in a meeting in 8 minutes
[08:53] <zyga> ok
[08:53] <zyga> we are back
[08:53] <zyga> thank you!
[09:00] <zyga> rogpeppe: it rebooted successfully
[09:00] <rogpeppe> zyga: yay!
[09:01] <mborzecki> quick errand, brb
[09:21] <mborzecki> re
[09:42] <mvo> zyga: \o/ you rock!
[09:42] <zyga> mvo: we're not done, it's not over yet
[09:42] <zyga> and it's pawel and maciek :)
[09:57]  * mvo hugs mborzecki and pstolowski
[09:57] <pstolowski> mvo: yeah it just survived manual reboot, but not reboot after refresh; we're seeing 'rollback across reboot'
[10:17] <mvo> quick question: do we have an example gadget with cloud init configuration?
[10:18]  * zyga doesn't remember one
[10:18] <mvo> that's fine, I will just create one I think
[10:21] <zyga-mbp> not a good store day
[11:13] <zyga> rogpeppe: we did lots of analysis but ultimately reboot just failed
[11:14] <zyga> rogpeppe: if you can power cycle (once for now), that would be great
[11:14] <rogpeppe> zyga: ok :\
[11:14] <zyga> let us know when ready
[11:18] <zyga-mbp> rogpeppe: so, it would be amazing if you could eventually get this
[11:18] <zyga-mbp> https://www.amazon.co.uk/UART-CP2102-Module-Serial-Converter/dp/B00AFRXKFU/ref=sr_1_7?dchild=1&keywords=USB+TTL+serial&qid=1602674287&sr=8-7
[11:19] <zyga-mbp> rogpeppe: let us know when the 1st power-cycle had occurred
[11:19] <zyga-mbp> if you already did that you can go ahead with the second one (2nd power cycle)
[11:19] <zyga-mbp> 1st power cycle did not (as expected, though unclear why) recover the device
[11:22] <zyga> ogra: do you have the permission to download pi-kernel revno 44?
[11:45] <zyga-mbp> mvo: do you have access to core18 snap?
[11:45] <zyga-mbp> I could use revision 1076 with assertions
[11:45] <zyga-mbp> similarly to pi-kernel at revision 44
[11:45] <zyga-mbp> and pi gadget revision 17
[11:59] <ogra> zyga-mbp, let me try ...
[11:59] <zyga-mbp> thank you!
[12:00] <ogra> $ snap download --revision=44 pi-kernel
[12:00] <ogra> Fetching snap "pi-kernel"
[12:00] <ogra> error: cannot download snap "pi-kernel": Access by specifying a revision is not allowed for this Snap.
[12:00] <ogra> nope
[12:00] <zyga-mbp> oh well
[12:00] <ogra> i fear only the kernel team can ...
[12:01] <ogra> (i can download the current revision for each track/channel but not specify --revision)
[12:01] <zyga-mbp> yeah, same here
[12:02] <ogra> also 44 is pretty old .. we're at 200 currently
[12:02] <zyga-mbp> I know, we are trying to reproduce a peculiar failure
[12:02] <ogra> (for armhf that is)
[12:27] <mborzecki> cmatsuoka: hi, can you take a look at https://github.com/snapcore/snapd/pull/9474 ? it's been +1'ed by pedronis
[12:27] <mup> PR #9474: boot, overlord/devicestate: list trusted and managed assets upfront <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9474>
[12:28] <cmatsuoka> mborzecki: already looking, was about to +1 it
[12:29] <mborzecki> cmatsuoka: cool thanks!
[12:29] <mborzecki> cmatsuoka: fwiw https://github.com/snapcore/snapd/pull/9443 could use your review too :)
[12:29] <mup> PR #9443: gadget, gadget/install: support for ubuntu-save, create one during install if needed <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9443>
[12:36] <cmatsuoka> mborzecki: ah yes, I started reviewing it a few days ago and didn't finish it, resuming now
[12:44] <mborzecki> cmatsuoka: thank you
[12:53] <cmatsuoka> mborzecki: done
[12:54] <mborzecki> cmatsuoka: yay, now if only testing was green
[12:55] <jibel> Hi, I cannot launch any snap on groovy. When I launch a command from the terminal, it waits for a moment then I get this error:
[12:55] <jibel> $ matterhorn
[12:55] <jibel> cannot stat /var/lib/snapd/seccomp/bpf/snap.matterhorn.matterhorn.bin: No such file or directory
[12:56] <jibel> is there a knows issue?
[12:56] <jibel> $ snap version
[12:56] <jibel> snap    2.47.1+20.10
[12:56] <jibel> snapd   2.47.1+20.10
[12:56] <jibel> series  16
[12:56] <jibel> ubuntu  20.10
[12:56] <jibel> kernel  5.8.0-22-generic
[12:58] <zyga-mbp> jibel hi
[12:58] <zyga-mbp> hmm
[12:58] <mborzecki> interesting
[12:58] <zyga-mbp> I assume the referenced file does not exist
[12:58] <zyga-mbp> can you run snap list without failure?
[12:59] <jibel> yes
[12:59] <jibel> no failure
[12:59] <mborzecki> jibel: yeah, can you also do `ls -l /var/lib/snap/seccomp/bpf` ?
[12:59] <zyga-mbp> and if you run "snap changes" do you see any errors?
[12:59] <jibel> and the snaps I cannot launc hare listed
[13:00] <jibel> ah
[13:00] <jibel> 65   Error   today at 13:04 CEST  today at 13:06 CEST  Auto-refresh snaps "snapd"
[13:00] <jibel> and the error
[13:00] <jibel> 2020-10-14T13:04:37+02:00 ERROR cannot compile /var/lib/snapd/seccomp/bpf/snap.dl-ubuntu-test-iso.dl-ubuntu-test-iso.src: fork/exec /snap/snapd/8790/usr/lib/snapd/snap-seccomp: no such file or directory
[13:01] <jibel> log of change 65 https://paste.ubuntu.com/p/MKWRHhZpX4/
[13:01] <jibel> upgrade of snapd didnt go well apparently
[13:02] <mvo> zyga-mbp: I can give you core18 r1076 - give me 1min
[13:02] <zyga-mbp> mvo thank you
[13:02] <zyga-mbp> jibel we have a standup call now
[13:02] <zyga-mbp> I'll get back to you after that
[13:02] <jibel> np
[13:05] <jibel> zyga-mbp, for some reason auto-refresh of snapd failed, I re-refreshed snapd manually and it fixed $world
[13:05] <jibel> weird
[13:08] <zyga-mbp> jibel could you look for system logs from that moment
[13:08] <zyga-mbp> perhaps there are clues there?
[13:19] <jibel> here it is https://paste.ubuntu.com/p/ZSRcqbsVCM/
[13:28] <zyga-mbp> jibel thank you
[13:28] <zyga-mbp> jibel very interesting
[13:38] <zyga-mbp> jibel let me read the log quickly
[13:38] <zyga-mbp> jibel can you ls -ld /snap/snapd/8790/usr/lib/snapd/snap-seccomp
[13:38] <zyga-mbp> and report a bug with this log, snap changes and snap tasks NNN where NNN is the change that failed
[13:38] <zyga-mbp> I need to get my dog to the vet in a moment and I don't want to lose a chance to see the state your system was in right now
[13:40] <zyga-mbp> jibel: ^
[13:40] <jibel> zyga-mbp, version 8790 has been removed from the system, I've only 9279 and 9607
[13:40] <zyga-mbp> that explains a lot
[13:40] <zyga-mbp> thank you!
[13:40] <jibel> $ ls -ld /snap/snapd/*/usr/lib/snapd/snap-seccomp
[13:40] <zyga-mbp> so snap changes
[13:41] <jibel> -rwxr-xr-x 1 root root 2306928 sept.  4 18:33 /snap/snapd/9279/usr/lib/snapd/snap-seccomp
[13:41] <jibel> -rwxr-xr-x 1 root root 2306928 sept. 30 06:59 /snap/snapd/9607/usr/lib/snapd/snap-seccomp
[13:41] <jibel> -rwxr-xr-x 1 root root 2306928 sept. 30 06:59 /snap/snapd/current/usr/lib/snapd/snap-seccomp
[13:41] <zyga-mbp> and snap tasks for the last few changes that happened
[13:41] <zyga-mbp> I really need to go now
[13:41] <jibel> I'll report a bug
[13:41] <zyga-mbp> mborzecki, pstolowski: ^ perhaps something you can pick up to the extent that the relevant data is collected in a bug
[13:43]  * zyga-mbp goes
[13:46] <mborzecki> jibel: can you find the pid of `snapd` and then run `sudo ls -l /proc/<pid>/exe` ?
[13:47] <cachio> mvo, could you find the error for sbuild?
[13:51] <mborzecki> cachio: got log of that failure?
[13:51] <cachio> mborzecki, which failure?
[13:52] <cachio> the sbuild on?
[13:52] <mborzecki> cachio: yes, the sbuild one
[13:53] <cachio> mborzecki, https://paste.ubuntu.com/p/f9MJNgc6r9/
[13:54] <jibel> mborzecki, lrwxrwxrwx 1 root root 0 oct.  14 15:02 /proc/70906/exe -> /usr/lib/snapd/snapd
[13:54] <jibel> mborzecki, zyga-mbp bug 1899794
[13:54] <mup> Bug #1899794: snapd error during refresh <snapd (Ubuntu):New> <https://launchpad.net/bugs/1899794>
[13:58] <mborzecki> jibel: can you attach the output of journalctl -u snapd.failure.service too?
[14:00] <jibel> done
[14:03] <mborzecki> jibel: thanks, this looks very interesting, can you also grab the output of `journalctl -u snapd.service` from before oct 12?
[14:05] <mborzecki> jibel: looks like something happend on oct 12 ~7:03 and the failure handler got started, so maybe a complete log of the snapd.service would be even better
[14:09] <jibel> mborzecki, attached
[14:09] <mborzecki> jibel: thanks
[14:09] <jibel> I'm wondering if it could be related to bug 1871538 where systemd brings the entire session down
[14:09] <mup> Bug #1871538: dbus timeout-ed during an upgrade, taking services down including gdm <amd64> <apport-bug> <champagne> <focal> <id-5e988df7fb344884f67bc04f> <rls-ff-incoming> <systemd:New> <accountsservice (Ubuntu):Invalid> <dbus (Ubuntu):Incomplete> <gnome-shell (Ubuntu):Invalid> <accountsservice
[14:09] <mup> (Ubuntu Focal):Invalid> <dbus (Ubuntu Focal):Incomplete> <gnome-shell (Ubuntu Focal):Invalid> <https://launchpad.net/bugs/1871538>
[14:17] <mborzecki> jibel: not sure, looks like there were 2 instances of snapd service running one point
[14:30] <mborzecki> jibel: was there a package update sometime ~7:00 on oct 12?
[14:32] <jibel> mborzecki, yes among other there was snapd:amd64 (2.46.1+20.10, 2.47.1+20.10)
[14:32] <mborzecki> jibel: around that time?
[14:33] <jibel> from 07:01:25 to 07:03:53
[14:33] <mborzecki> jibel: cool, thanks
[14:44] <mborzecki> jibel: ok, added more comments to the bug, a nice one
[14:45] <mborzecki> mvo: pedronis: i've added some comments to https://bugs.launchpad.net/snapd/+bug/1899794 looks like a real problem
[14:45] <mup> Bug #1899794: Error during refresh of snapd leads to unusable system <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1899794>
[14:46] <mborzecki> errands
[14:49] <jibel> mborzecki, ta
[15:23] <pedronis> mvo: I did a pass in #9469
[15:23] <mup> PR #9469: snapshots: import of a snapshot set <Created by mvo5> <https://github.com/snapcore/snapd/pull/9469>
[15:25] <pedronis> mborzecki: thx, snap-failure /revert logic needs improvements
[15:35] <mvo> pedronis: awesome, thank you!
[15:36] <cachio>  /me lunch
[15:36]  * cachio lunch
[16:30] <mup> PR snapd#9501 opened: [RFC] wrappers: do not error out on read-only /etc/dbus-1/session.d filesystem on core18 <Created by stolowski> <https://github.com/snapcore/snapd/pull/9501>
[17:31] <mvo> cachio: I did not even look at the sbiuld error, so sorry! had meeting, an interview and 360
[17:32] <cachio> mvo, np, I'll take a look
[17:33] <cachio> mvo, is it failing to build https://paste.ubuntu.com/p/hdxvkmrRVG/
[17:33] <cachio> mvo, is it any way to show more info about what failed?
[17:34] <mvo> cachio: yeah, the error as is is really not helpful
[17:34] <mvo> cachio: there should be maybe a sbuild.log with more info?
[17:34] <cachio> mvo, nice, thanks
[17:41] <zyga> re
[17:50] <mvo> cachio: if you don't find anything, please remind me tomorrow, my day should be a bit less crazy tomorrow :)
[17:50] <cachio> mvo, sure, thanks!
[17:53] <zyga> sorry, this was a long visit
[17:53] <zyga> I'll grab some food and do reviews for cachio
[17:53] <zyga> and then try to install the kernel and core mvo shared
[18:03] <mvo> zyga \o/
[18:04] <zyga> :)
[18:13] <mvo> pedronis: I addressed the snapshot import feedback, will ask pawel tomorrow
[18:13] <mvo> pedronis: for a second review
[18:13] <mvo> pedronis: will call it a day now
[18:23] <mup> PR snapcraft#3317 opened: plugin handler: properly handle snapcraftctl errors <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3317>
[18:46]  * cachio -> kinesiologist
[19:38]  * zyga picks up zyga:tweak/ignore-running aka https://github.com/snapcore/snapd/pull/9406
[19:38] <mup> PR #9406: many: allow ignoring running apps for specific request <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/9406>
[19:53] <mup> PR snapcraft#3318 opened: plugin handler: set -x for scriptlets <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3318>
[20:36] <mup> PR snapd#9502 opened: tests: more output for sbuild test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9502>
[20:39]  * zyga made some progress and calls it a day
[20:49] <zyga> ok one more patch
[20:49] <zyga> pushed some tests to https://github.com/snapcore/snapd/pull/9406
[20:49] <mup> PR #9406: many: allow ignoring running apps for specific request <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/9406>
[21:03] <mup> PR snapcraft#3319 opened: [RFC] plugin handler: use bash with additional error checking for core20 scripts <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3319>
[21:31] <mup> PR snapd#9503 opened: tests: use tests.backup tool <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9503>


[05:16] <libben> installing alternate Lubuntu 15.10 on an HP Stream 7 to avoid having to install grub, which I don't want. I have a usb hub attached with my Edimax EW-7811Un dongle, but it is missed at the hardware detection phase. What can I do?
[05:18] <libben> ^ It's recognized perfectly in the regular Lubuntu live environment, but again that forces me to install grub.
[05:20] <tsimonq2> libben: why don't you want GRUB?
[05:26] <libben> tsimonq2: Ok, so my partition scheme is {[300mb EFI Paritition][30gb ext4 partition mounted at root]}; since the device I'm using has 32-bit eufi the install fails at GRUB-install, leaving some steps undone. After the install failed, I was able to correctly configure grub from the commandline. THe system boots, but I notice it has some weird errors I attribute to not being able to finish installing. So, since I already have grub, I want to
[05:26] <libben> reinstall Lubuntu on my root partition and leave the installation of GRUB alone; once the system installs correctly I'll boot to a live environment, chroot into my system, and update GRUB's boot options once more.
[05:26] <libben> *the install of Lubuntu
[05:32] <libben> Ok, just attempted the alternate install again. It failed at "select and install software". Gonna go with this post https://askubuntu.com/questions/461499/error-installing-ubuntu-14-04-the-failing-step-is-select-and-install-software and try to format and re-attempt the operation
[07:10]  * EminentLemniscat bows and salutes all: Hello World!
[07:13] <peaceful> Hi i have problems with sound, it appears and disappears
[07:14] <peaceful> problems started when i installed pulseaudio
[07:14] <peaceful> now i remve purged it but i still encounter these problems
[07:20] <EminentLemniscat> did you try tge answers from the following post: http://goo.gl/D0z15z
[08:57] <gnu_d> Hi, I got intel hd graphics, but when booting normally, it can't find the screen (says in the xorg logs), and the font is distorted, returns to the text login. When I try to boot with recovery mode and use the first option that is normal boot, it works, but that's bad way to start the computer.
[09:13] <Mux4> If i dont have internet when installing what thing is needed ? Will lubuntu extras give me all i need ?
[09:17] <Mux4> Is there any problem with install lubuntu if i forgot a sd card inserted ? Some readers can not be used when install drivers.
[13:51] <KindSnoo> hi??
[13:52] <damascene> Hi KindSnoo
[13:53] <KindSnoo> i have a slow old thinkpad laptop
[13:53] <KindSnoo>  currently runs windows 7
[13:53] <KindSnoo> do you think i could grt lubuntu on it?
[13:53] <damascene> if it runs windows 7 I think it can run Lubuntu very easily
[13:54] <KindSnoo> ill be using it for reddit, google docs, wikipedia, and canva.com
[13:54] <KindSnoo> maybe like inkscape or something
[13:54] <KindSnoo>  light graphic design
[13:55] <damascene> when it comes to graphics there are many factors that you should take into account. I think it would be OK if it's just a light things
[13:56] <KindSnoo> flag design and such
[13:56] <KindSnoo> will i be able to get latest version of firefox?
[13:57] <KindSnoo> ?
[14:02] <damascene> KindSnoo, I think so. firefox is always the latest version on all the Ubuntu flavors that I tried
[14:31] <Wox4> If i dont have internet when i am installing what will missing ? Can i install rest of it later and how ? Lubuntu extras ?
[14:45] <Wox4> Someone here ?
[15:46] <Aks> does anyone know why my lubuntu installer always gets stuck on setting the sizes for the partition of lubuntu?
[15:48] <Aks> Guys?
[15:49] <damascene> Aks, which version of Lubuntu?
[15:49] <Aks> pretty sure its 14.03
[15:49] <Aks> LTS
[15:51] <Aks> its 14.04.3
[15:51] <Aks> LTS
[15:56] <Aks> I'm trying it again
[16:02] <Aks> should I choose something other than install Lubuntu alongside Windows? Apart from erase disk
[16:03] <damascene> Aks, you can manually configure it but that require some experience with partitioning
[16:04] <Aks> Which I don't have...but I can try. I know Windows is only taking up 11gb so I plan to give Lubuntu 18
[16:11] <Aks> 12gb is 1200mb, right guys?
[16:12] <Aks> its 12000 actually
[16:17] <damascene> right
[16:26] <Aks> does anyone know why my mouse cursor disappears after a while during install?
[16:27] <damascene> Aks, I had similar problem but in virtual machine but restart fixed it
[16:27] <Aks> The thing is this is the 4th time I've tried to install
[16:27] <Aks> each time with the same problem
[16:33] <Aks> So I've set the windows partition to 12gb...will that take a long time?
[16:54] <oskar> hello
[16:54] <oskar> i just downloaded lubuntu
[16:54] <oskar> my password is not working
[16:54] <oskar> is there a way to reset it?
[16:54] <oskar> im using lubuntu lts 14.04
[16:57] <oskar> hi
[16:57] <oskar> i just downloaded lubuntu, but my password is not working
[16:57] <oskar> is there a way to reset it??
[16:57] <oskar> i'm using lubuntu LTS 14.04
[17:00] <Mark1_> I am not sure here are talking peoples to day. I have ben here twice before.
[17:01] <oskar> oh okay
[17:02] <Mark1_> We have to be very patient maybe.
[17:07] <damascene> 😊
[19:29] <peaceful> Hi, i have problems with wifi BCM4311 i installed Linux Broadcom STA driver and i try to load it with sudo modprobe wl but it doesnt work.
[19:34] <peaceful> this is the error i found in dmesg:
[19:34] <peaceful> [   14.251260] wl: module license 'MIXED/Proprietary' taints kernel. [   14.251266] Disabling lock debugging due to kernel taint [   14.259933] wl: module verification failed: signature and/or  required key missing - tainting kernel
[21:44] <oskar> anyone here?


[00:01] <qwebirc24999> it is automated by configure_networking though
[00:01] <qwebirc24999> how do I make it so that it'd work properly
[00:06] <qwebirc24999> alright, so if I manually fix the DNS I now get a curl 60 error (SSL certificate problem: unabel to get local issuer certificate). I have the certificates in /etc/ssl/certs. What is wrong?
[00:09] <sarnold> did you run update-ca-certificates?
[00:34] <qwebirc24999> yes
[00:34] <qwebirc24999> sarnold
[00:35] <sarnold> hmm, I don't know what to suggest next
[08:44] <lordievader> Good morning
[12:00] <kstenerud> I have some questions about the MIR process
[12:00] <kstenerud> A package I want promoted depends on just a few other packages, but some of them are pretty big
[12:01] <kstenerud> so is there some rule of thumb over what gets in and what remains out?
[12:01] <kstenerud> Or are there any packages that should simply be dismissed out of hand?
[12:21] <rbasak> kstenerud: importance gets weighed against difficulty
[12:21] <kstenerud> OK. In this case it's a command line tool that would pull in python-tornado and ruby-sinatra
[12:22] <kstenerud> So now I'm wondering... will this become an uphill battle? Should I reconsider?
[12:23] <kstenerud> er python3-tornado that is
[12:34] <rbasak> Both of those seem really major to me. For Ubuntu, Ruby is particularly painful as we don't have most of that stack in main currently.
[12:34] <rbasak> Why are they needed by the tool? Are they really mandatory?
[12:42] <kstenerud> rbasak I haven't dug in too deeply yet. It looks like it produces a command line tool, and a web API server. If these can somehow be split out, that could work... I'm trying to decide if this has a realistic chance of being a MIR or not
[12:43] <kstenerud> what I'd been hoping for was just a command line tool that people use to configure pacemaker/corosync. This web stuff being mixed in was a nasty surprise
[12:45] <kstenerud> I'd still need to dig deeper to see if the cmdline tool is just a web client in disguise, which would kybosh the whole thing I imagine. But even if it can be standalone, would a split in theory be feasible>
[12:48] <rbasak> kstenerud: there aren't any rules precluding a split. A single source package can produce multiple binary packages, some of which we can move to main and some of which can remain in universe. The only feasibility question is how involved the packaging work and maintaining that delta would be.
[12:48] <kstenerud> ah ok, cool. I'll do some more digging then
[15:13] <evit> Anyone know why the https://usn.ubuntu.com/ website and mailing list are always behind the release of patches. Seems like they should be in sync
[15:13] <lotuspsychje> evit: wich patch are you talking about?
[15:13] <evit> The patch comes and then it isn't announced for a whole day some times
[15:14] <evit> The patch will be available but people might not know cuz its not on the https://usn.ubuntu.com/ or announced via the mailing list
[15:14] <evit> for nearly a day sometimes
[15:14] <evit> Seems like that should be more 'realtime'
[15:14] <tomreyn> evit: smtp does not guarantee instant message delivery. a mailing list with thousands of users can take days until messages to all recipients were distributed.
[15:15] <evit> tomreyn, I'm aware. That's not why
[15:15] <tomreyn> have you tried the newsfeeds (RSS+ Atom), are those also behind?
[15:17] <evit> tomreyn, no but all sources should be updated as soon as possible
[15:18] <tomreyn> evit: maybe bring it up in #ubuntu-hardened once you have specific observations (with timestamps) you can share.
[15:18] <lotuspsychje> evit: whats your end goal with this anyway? if a security flaw comes out, the flaw is being worked on to fix
[15:19] <lotuspsychje> when the fix is there, the system updates
[15:20] <tomreyn> it's relevant in companies where security updates are managed.
[15:20] <tomreyn> or any form of organozations
[15:20] <evit> lotuspsychje, Not my point. We know about vulns but need good info on when patches are available to mitigate them
[15:21] <evit> lotuspsychje, Time is of the essence in many cases. The longer its not patched the more likely it is to be exploited
[15:21] <lotuspsychje> we have seen in the past the hardened guys where behind of work..its human to get work done too right
[15:22] <Odd_Bloke> I don't know any details, but I wouldn't be surprised if the usn.u.c updates can't start until embargo is lifted in some cases.
[15:22] <evit> lotuspsychje, I'm not blaming anyone I'm just suggesting it should be more synced up and done in a more coordinated/timely fashion for the sake of the security of the community
[15:23] <Odd_Bloke> So the update goes out to the archive as the notification process starts.
[15:23] <lotuspsychje> yeah i think Odd_Bloke is right
[15:23] <evit> I hear you both
[15:24] <lotuspsychje> perhaps as tomreyn suggest talk to the hardened guys about it evit ?
[15:24] <evit> lotuspsychje, Yes, I will. Thanks to you all
[15:26] <tomreyn> you're welcome. ;)
[17:00] <lauren> who would I talk to to argue for zstd and brotli, both very small binaries, being installed by default in the base server install? it would be cool to be able to distribute things as .tar.brotli or .tar.zstd, and the main bottleneck for this being useful is brotli or zstd being installed by default
[17:02] <teward> lauren: a bit late in the dev cycle for this discussion.
[17:03] <lauren> I don't really care which iteration it makes it into. I just realized it was something that would make sense in the future, and someone had to bring it up, so i might as well
[17:03] <teward> getting it included into the main server images would require us syncing in the Security team and the SEcurity team doing analysis on zstd and brotli to determine if there's any major issues with the package(s) which would fail to land in Main
[17:03] <lauren> :)
[17:03] <teward> try reading https://wiki.ubuntu.com/MainInclusionProcess though
[17:05] <teward> because Main Inclusion is... tricky
[17:08] <sarnold> both brotli and libzstd are in main
[17:08] <teward> they are?
[17:08] <teward> sarnold: then why does rmadison say they aren't?
[17:09] <teward>  brotli | 1.0.7-2                | disco/universe           | amd64, arm64, armhf, i386, ppc64el, s390x
[17:09] <sarnold> teward: http://paste.ubuntu.com/p/J9Zk8J2Jfn/
[17:09] <teward> hmm
[17:09] <sarnold> teward: probably usual source / binary things
[17:10] <rbasak> lauren: what's the full justification for why it'd be useful, please, for someone who doesn't know much about this area?
[17:12] <rbasak> (I understand the default part)
[17:29] <lauren> rbasak: brotli and zstd are the current state of the art open source lossless compressors; I'm not sure who zstd was originally by, but it's now permissively licensed and maintained by Facebook, and brotli is permissively licensed by Google. both are already in universe as of xenial. both brotli and zstd can reach much higher compression rates than nearly anything else, and can do it at much higher throughput than anything else open
[17:29] <lauren> source; the only exceptions seem to be lzma which gets just barely better compression in the very best case, which is also not installed by default and is much slower on compress
[17:29] <lauren> https://quixdb.github.io/squash-benchmark/#results https://sites.google.com/site/powturbo/home/benchmark
[17:32] <teward> > maintained by Facebook
[17:32] <teward> given their current Security track record I'd call that a negative impacting factor
[17:32] <lauren> the relevant use case for me is I'd like to be able to distribute software brotli-compressed; brotli seems to average 2x or so smaller file size for binary data than bzip2, in the powturbo benchmark
[17:32] <teward> just saying
[17:32] <lauren> ah pretty good point
[17:32] <sarnold> rbasak: zstd's --adapt feature is pretty neat; folks like using it with eg zfs send ... | zstd --adapt | ssh remote@host zfs recv ...
[17:33] <sarnold> rbasak: .. if the network's really fast, it'll compress very fast; if the network is very slow, it'll spend more time compressing
[17:33] <sdeziel> wow, that's interesting ^
[17:33] <supaman> no matter who the developers are (google, facebook, kaspersky ... ) everything should be vetted right?
[17:33] <sarnold> lauren: for "offline" use cases like that, be sure to compare against xz; xz is slow as sin to compress but gets great ratios
[17:34] <lauren> for sure, guessing inclusion by developer is just a heuristic
[17:35] <lordcirth> adaptive streaming compression? Ok that's really cool
[17:35] <lauren> and fair enough. is xz installed by default? if not maybe I just want to suggest that be included by default
[17:35] <lordcirth> By the way, I hear you can also speed up those sorts of ssh-piping things by including | buffer | on one or both ends
[17:35] <sarnold> lordcirth: did you mean mbuffer?
[17:35] <lauren> obviously since these are in the repos, it doesn't make that big of a difference
[17:36] <lordcirth> sarnold, nope, the command is just 'buffer', also apt install buffer
[17:36] <lordcirth> It just buffers pipes
[17:36] <lordcirth> Ah, it seems mbuffer is an upgraded version?
[17:36] <lauren> huh good to know. I assumed ssh would be reasonable internally
[17:38] <lordcirth> lauren, it is reasonable in the sense of being safe and not using 500MB of RAM.
[17:39] <lordcirth> Most unix tools, especially older ones, will err on the side of using less resources.
[17:39] <lordcirth> For example, dd uses 512b blocks by default, and you can often get a big speed boost by specifying bs=1M
[17:40] <lauren> ah makes sense. I always do something like that with dd yup
[17:42] <sdeziel> lordcirth: I've reduced my use of dd after reading https://www.vidarholen.net/contents/blog/?p=479 which I found interesting
[17:43] <lordcirth> sdeziel, cool, thanks
[17:44] <sdeziel> lordcirth: I still use dd when I need to seek/skip though
[17:44] <sarnold> I'm pretty sure that cp behaviour is pretty new..
[17:45] <lordcirth> sarnold, which cp behaviour?
[17:45] <sarnold> cp foo /dev/sdb
[17:46] <sarnold> Once Upon A Time it would just unlink sdb and then put the data there. as you asked.
[17:46] <lordcirth> Yeah, that was my first thought too
[17:47] <lordcirth> sarnold, but old cat would work, right?
[17:47] <tomreyn> there are pitfalls in working with raw devices like this
[17:47] <tomreyn> some aren't block special but symlinks
[17:48] <tomreyn> also accessing them will often require root / sudo, which makes piping and redirecting a tid bit more difficult than this blog post suggests
[17:48] <sdeziel> tomreyn: symlinks should be resolved so that cp ends up writing to the real destination
[17:48] <sarnold> lordcirth: yeah I'd expect cat to work. but then you've got to use a root shell rather than just using sudo on dd ..
[17:49] <lordcirth> I've used sudo tee > /dev/null, but that's maybe slow for ISOs?
[17:50] <tomreyn> i remember that i ended up replacing a symlink in /dev/mapper by a file when using .. i don't know what tool exactly in the past.
[17:50] <rbasak> lauren: thanks, that's useful to know. Can I suggest that you file a bug (a single bug for both should be fine) with that justification?
[17:50] <rbasak> I wonder what the longevity of this stuff will be (so we don't end up with a big pile of them that we can't remove0
[17:50] <rbasak> )
[17:50] <sdeziel> sarnold: this old cp behaviour you describe sounds like "cp --remove-destination", I am a bit surprised it ever was the default
[17:51] <lauren> oh hmm longevity is a good point
[17:51] <sarnold> rbasak: what, you don't love having compress and gzip and bzip2 and lz4 and brotli and zstd and xz all installed at once because once upon a time each one was the best tool available? :)
[17:52] <rbasak> :)
[17:52] <lordcirth> I've personally seen zstd referenced many more times than brotli, anecdotally.
[17:52] <rbasak> Perhaps we should operate a one in one out policy :)
[17:52] <sdeziel> considering that zstd can be used with btrfs, that pretty much guaranty it needs to remain supported forever
[17:52] <lauren> nah, none of them are dead, it's a great criticism
[17:52] <sarnold> sdeziel: the difference between in-kernel implementation vs userspace utilities..
[17:53] <sarnold> though I haven't actually seen a compress file in AGES
[17:53] <sdeziel> ah right
[17:53] <lordcirth> 'compress' isn't installed in my 18.04 Xubuntu?
[17:53] <lauren> maybe compress could be removed from default by now, but someone is going to be irritated and need to install it
[17:53] <lauren> oh nice!
[17:53] <lordcirth> Or on my 18.04 server
[17:53] <sarnold> wow :)
[17:53] <sarnold> I sure didn't expect that
[17:54] <lordcirth> It hints to install 'ncompress' as it should, of course.
[17:54] <sdeziel> gunzip  can currently decompress files created by gzip, zip, compress, compress -H or pack
[17:54] <teward> sarnold: well given ncompress is in Universe I"m not surprised it's not a default :p
[17:54] <teward> (yay for umt search!)
[17:54] <sarnold> hahaha
[17:56] <lauren> ahh interesting. so maybe the reasonable thing is just to tell users to install one. I expect both zstd and brotli to have solid longevity, because if I understand correctly, both have a lot of room for improvement in terms of more efficient compressors without changing the protocol
[17:56] <rbasak> Do zstd and brotli have different use cases?
[17:56] <lauren> I don't think so. I just don't want to pick sides.
[17:57] <sdeziel> I've only heard of brotli being used for web stuff (browsers, libs, servers)
[17:58] <sarnold> yeah brotli seems to be used with webfonts or something similar
[17:58] <rbasak> Part of Ubuntu's purpose, for defaults, at least, _is_ to pick sides, to help us focus rather than dilute attention to detail. Perhaps that means we should wait until there's a clear winner between the two then. I don't have a strong feeling in any direction right now - just conscious that it's hard to go back once we do put something in.
[17:58] <sarnold> zstd's adaptive compression feature is nice for some potentially-network-bound usecases
[17:59] <sdeziel> sarnold: Firefox nowadays sends Accept-Encoding: gzip, deflate, br
[18:00] <sdeziel> same for Chromium
[18:00] <sarnold> gah why would it not put br first?
[18:01] <sdeziel> oh, I didn't know the ordering played a role in the preference
[18:01] <sarnold> oh well. web is their own world
[18:01] <sarnold> they do what they do :)
[18:07] <sdeziel> I bet the reason was because some middle boxes would exploded if gzip and deflate were not seen first
[18:08] <lordcirth> Ah, middleboxes. Breaking compatibility since forever
[18:13] <sarnold> heh :( probably true
[19:40] <tomreyn> s/(compatibility)/\1 and encryption/


[04:03] <ra1v3n> Hello all
[05:07] <superfly> Good evening
[05:08] <superfly> Maaz: tell Kilos don't forget to eat your oats this morning, other side you won't grow up to be a big strong man
[05:08] <Maaz> superfly: Okay, I'll tell Kilos on freenode
[05:09] <superfly> Maaz: tell Kilos *otherwise
[05:09] <Maaz> superfly: Sure, I'll tell Kilos on freenode
[05:48] <magespawn> good morning
[06:55] <thatgraemeguy> morning peoples
[06:55] <Maaz> thatgraemeguy: By the way, magellanic on freenode told me "tell ThatGraemeGuy thanks bro, appreciate the message. yes hetzner support are the best, that particular issue was sorted" 10 hours, 52 minutes and 42 seconds ago
[07:03] <magespawn> hey thatgraemeguy
[07:05] <inetpro> goeie more mense
[07:43] <ra1v3n> Good mornin
[07:55] <chesedo> good morning superfly thatgraemeguy magespawn inetpro
[07:56] <thatgraemeguy> Hiiiii
[08:09] <magespawn> hi inetpro chesedo
[08:17] <paddatrapper> Hello everyone
[08:27] <andrewlsd> Morning everyone
[13:02] <paddatrapper> Well part my old high school burnt down this morning... It was quite a way to wake up!
[13:32] <superfly> paddatrapper: Muizenberg High?
[13:32] <superfly> Where's Kilos today?
[13:41] <magespawn> superfly he said something about going for his pension today so would lnly be online tonight
[13:41] <superfly> magespawn: ah
[13:42] <superfly> it's quiet without him here
[13:51] <Kilos> afternoon everyone
[13:51] <Kilos> hahaha @ superfly
[13:56] <magespawn> Speak of the devil...
[13:56] <Kilos> haha
[13:56] <magespawn> superfly: you should have said something earlier
[13:56] <Kilos> hi magespawn
[13:56] <Kilos> im gazausted
[13:56] <Kilos> what a mess up things are
[13:58] <Kilos> go for pension, guy there checks all info and fills in the relevanted form then says go have it certified and come back monday
[13:59] <Kilos> miss the 10.15 bus by 10 minutes so wait for 12.10 bus
[13:59] <superfly> Kilos: ai :-(
[14:00] <Kilos> which at 12.30 isnt there yet, so after walk to square to enquire get told drivers inna meeting anfd on strike
[14:00] <Kilos> so took  one of them other taxis half way and got a lift from a friend to plot
[14:00] <Kilos> holy moly
[14:01] <Kilos> hehe what will be will be
[14:01] <Kilos> ke sera sera
[14:02] <paddatrapper> superfly: Wynberg Boys'
[14:02] <Kilos> hi paddatrapper superfly
[14:02] <Kilos> what did i miss
[14:03] <paddatrapper> Hey Kilos
[14:03] <Kilos> seems etihad has free wifi on planes so i can be online here with the lappy if i can find the right power adapter before it flies
[14:05] <superfly> Kilos: paddatrapper's school is burning, or something... these kids, always making up stories to impress people
[14:05] <Kilos> oh my
[14:06] <paddatrapper> One block burned down this morning
[14:06] <Kilos> sjoe
[14:07] <Kilos> stay safe frog boots
[14:08] <paddatrapper> Kilos: http://m.news24.com/news24/SouthAfrica/News/wynberg-boys-high-closed-after-fire-20160804
[14:08] <paddatrapper> My brothers think it's Christmas - no school for a week in the middle of the term
[14:09] <Kilos> ai!
[14:15] <andrewlsd> ai. your poor parents ;-)
[14:20] <Kilos> hehe
[16:32] <Langjan> Hi Kilos het jy al jou tandeborsel ingepak?
[17:04] <Kilos> hi Langjan ja man
[17:04] <Kilos> wat pla jou met tande
[17:04] <Kilos> my tande dra ek net as ek uit gaan
[17:04] <Kilos> en haal uit om te eet
[17:04] <Kilos> hehe
[17:07] <Langjan> Lmga, myne lyk onder netso, daar is darem nog 'n paar mieliepitte bo
[17:08] <Kilos> haha
[17:10] <Langjan> Ons gesels effe later, moet eers gaan eet en tande borsel!
[17:11] <Kilos> lol geniet
[18:04] <magespawn> home time chat later all
[18:04] <Kilos> go safe magespawn
[18:06] <Kilos> inetpro how can you lest bus drivers strike the first time i need to use a bus in about 50 years
[18:16] <Kilos> s/lest/let
[18:32] <Symmetria> lo all
[18:32] <Symmetria> anyone awake?
[18:33] <Kilos> hi Symmetria
[18:33] <Kilos> whats news
[18:33] <Symmetria> Kilos you ever compiled a debian package from source using fakeroot etc?
[18:33] <Kilos>  nope
[18:33] <Symmetria> damn :) I need someone who has
[18:33] <Symmetria> because I'm missing something
[18:33] <Kilos> thats for clever people
[18:34] <Kilos> then hope the right person sees your message tonight
[18:34] <Kilos> maybe ask paddatrapper
[18:34] <Kilos> or fly
[18:34] <Kilos> or theblazehen
[18:35] <Kilos> or chesedo
[18:36] <theblazehen> hi
[18:36] <theblazehen> Symmetria: check out https://github.com/jordansissel/fpm, I hear it's good
[18:39] <tumbleweed> you won't hear that from anyone who regularly works with debian packages :P
[18:39] <Kilos> hi tumbleweed
[18:40] <tumbleweed> fpm reimplements everything, which saves you learning all those things. But means you have to re-implement everything :P
[18:44] <Symmetria> tumbleweed
[18:45] <Symmetria> how the hell do I pass a configure option
[18:45] <Symmetria> to a package when I'm rebuilding it
[18:45] <Symmetria> from source
[18:45] <tumbleweed> Symmetria: you edit debian/rules
[18:45] <tumbleweed> which package?
[18:46] <tumbleweed> how you do it will depend on which build system they are using
[18:47] <tumbleweed> but there are only a small handful of possibilities
[18:48] <Symmetria> trying to rebuild bind
[18:48] <Symmetria> to enable with-tuning=large
[18:48] <Symmetria> think I may have figured it out but will find out in a second, this is driving me nuts ;p
[18:49] <Symmetria> ok its rebuilding, and I THINK its got the option enabled
[18:49] <Symmetria> ;p
[18:49] <Symmetria> heh as a note - bind without serious tweaking really doesnt like insane load on DNS queries
[18:49] <tumbleweed> right, it already has lots of configure args in there, so you just add to the list
[18:49] <Symmetria> it kinda chokes when you start hitting around 4k queries a second
[18:57] <Langjan> Hi Kilos , slaap jy nog nie?
[18:57] <Kilos> haha amper
[18:57] <Kilos> baie moeg na vandag
[18:58] <Langjan> Waar was jy?
[18:58] <Langjan> Hosp toe?
[18:58] <Kilos> gaan aansoek doen vir pensioen
[18:58] <Langjan> Hoe het dit gegaan?
[18:59] <Kilos> hulle vat al jou goed en vul in n form en gee dit vir jou en se vat dit na die poloisie en kom maandag terug
[18:59] <Langjan> Eish!  Daar in Oz is nie ID's nie, jou woonadres is jou ID
[19:08] <Kilos> en dis R12 van bloed straat en van der walt tot by hercules
[19:08] <Kilos> haha
[19:08] <Langjan> So as jy toer is jou adres jou woonwa
[19:09] <Kilos> lmga
[19:09] <magellanic> greets
[19:09] <Kilos> hi magellanic
[19:09] <Langjan> En die bis is groot, die kuslyn is 60 000 km lank en daar is net 21 miljoen mense in die hele Oz
[19:09] <theblazehen> Did I mention how I can do `make clean; make -j` on the linux kernel in around 5 min? Kinda cool
[19:10] <Kilos> lol
[19:10] <theblazehen> Used to take around 3 hours on netbook
[19:12] <Langjan> Kilos, is there some trick re jumpers or similar to combining an SSD with a second hard drive in the same box?
[19:12] <Kilos> hdd must be slave
[19:13] <Kilos> or on another cable completely
[19:13] <Langjan> ok thks, either or
[19:13] <Kilos> lol
[19:14] <Langjan> serious
[19:14] <Langjan> slave or separate cable
[19:14] <Kilos> if you use and ide cable
[19:14] <Kilos> then you can plug hdd on end plug but must be slave then
[19:14] <Kilos> thats with thick ide cable
[19:14] <Langjan> its 4-pin cable socket is blanked off
[19:15] <Langjan> which is ide?
[19:15] <Kilos> on thin sata cable it shouldnt matter
[19:15] <Langjan> small or wide cable?
[19:15] <Langjan> ok tks
[19:15] <Kilos> ide is broad ribbon cable
[19:15] <Kilos> sata narrow on
[19:15] <Kilos> one
[19:16] <Langjan> and the small cable is power supply?
[19:16] <Kilos> ill be here tomorrow if you battle
[19:16] <Kilos> no man
[19:16] <Kilos> ai!
[19:16] <Kilos> drive cables come in ide which is broad ribbon
[19:16] <Langjan> both have two cables, a wider and a smaller one
[19:16] <Kilos> or sata which is narrow cable
[19:17] <Kilos> sata is maybe 1/2 inch
[19:17] <Kilos> ide is maybe 2 inches
[19:17] <Kilos> lemme measure
[19:18] <Langjan> were at cross purposes
[19:18] <Kilos> oh
[19:18] <Langjan> I understand the diff,
[19:18] <Langjan> between sata and ide
[19:18] <Kilos> explain then what you need to know
[19:18] <Langjan> but both have a wider and a smaller cable
[19:19] <Kilos> no man
[19:19] <Langjan> yes man
[19:19] <Kilos> the sata drive uses a broader plug for power
[19:19] <Langjan> not the cable, the plug
[19:19] <Kilos> ide uses the 4 pin power connector
[19:20] <Kilos> sata are skinny plugs
[19:20] <Kilos> one narrow one wider
[19:20] <Kilos> wider one is power
[19:20] <Langjan> yes but one is much wider than the other
[19:20] <Langjan> oh
[19:21] <Langjan> wider is power in both sata and ide?
[19:21] <Kilos> no
[19:21] <Kilos> ide use wide plug for data and narrow 4 pin for power
[19:22] <Kilos> you unnerstand
[19:22] <Langjan> Yes. This one has a plastic cover over 4 pin plug
[19:23] <Kilos> power ide
[19:23] <Langjan> so it has two places for power
[19:23] <Kilos> and a many pin section for wide ide cable for data
[19:23] <Kilos> no man
[19:23] <Langjan> and one for data
[19:24] <Kilos> take a pic of the drive on the plugs end
[19:24] <Kilos> then ill explain
[19:25] <Kilos> one section is where you set master/slave/cable thing
[19:25] <Kilos> where the jumpers go
[19:26] <Langjan> Yes I know where the jumpers go
[19:26] <Kilos> only those 4 fatpins are for power
[19:27] <Langjan> Mine has 4 fatpins and sata connector
[19:27] <Langjan> for power
[19:28] <Kilos> take a pic of it
[19:28] <Langjan> sending pic
[19:31] <Langjan> But we can chat tomorrow, jy moet slaap
[19:32] <Kilos> lemme just see
[19:34] <Langjan> I sent another pic with plug cover on over 4-pin
[19:34] <Kilos> bit blury but looks like it can take the power plugs of either type
[19:35] <Langjan> yes but that really confused me especially when you said the sata has power on the wide plug
[19:37] <Kilos> yesd very left is sata power
[19:37] <Kilos> the sata data
[19:37] <Kilos> some power supplies dont have sata power plugs so maybe they made that drive so it could use both
[19:38] <Kilos> try first using only sata cables
[19:38] <Kilos> then in home you should see it if its working
[19:39] <Langjan> I have but will have to get another cable, had to use the one from the cd drive
[19:39] <Langjan> to test
[19:40] <Kilos> if it shows then get other cable for cd
[19:40] <Kilos> with some playing you can make the hdd your /home
[19:40] <Kilos> or storage
[19:41] <Langjan> Yes but thats for another day, OK nou moet jy gaan slaap seuntjie
[19:41] <Kilos> lol ok dankie oom
[19:41] <Kilos> lekker slaap julle ook
[19:41] <Langjan> its 160 Gb nice clean drive
[19:41] <Kilos> great
[19:42] <Langjan> ok jy moet ook lekker slaap
[19:42] <Kilos> dankie
[19:42] <Langjan> will put kde on there for the kids to play with
[19:42] <Kilos> lol
[19:42] <Kilos> yes
[19:42] <Kilos> let them teach the old man
[19:42] <Langjan> lmga, lekker slaap en hoop jy is more goed uitgerus
[19:42] <Langjan> yes
[19:42] <Kilos> dankie my vriend
[19:43] <Langjan> always ready to learn
[19:43] <Kilos> haha
[19:43] <Kilos> nono you forget too quick
[19:43] <Kilos> oh
[19:43] <Kilos> wait
[19:43] <Kilos> listen carefully
[19:43] <Kilos> are you listening Langjan
[19:43] <Langjan> ja man
[19:43] <Kilos> ??
[19:43] <Langjan> in spanning
[19:43] <Kilos> turmeric poder
[19:43] <Kilos> borrie
[19:44] <Langjan> ja?
[19:44] <Langjan> goeie goed
[19:44] <Kilos> meng in of vet of um
[19:44] <Langjan> maar sleg, uggggh
[19:44] <Kilos> daai ander olie
[19:45] <Langjan> flaxseed?
[19:45] <Kilos> olive oil
[19:45] <Kilos> or coconut oil
[19:45] <Kilos> then add black pepper
[19:45] <Kilos> rejuvenates memmory
[19:45] <Kilos> you need lots
[19:45] <Langjan> kick on the ass does the same
[19:45] <Kilos> you too far to kick
[19:46] <Kilos> it works
[19:46] <Langjan> lucky me
[19:46] <Langjan> yes its good stuff
[19:46] <Kilos> black pepper increases the turmeric power by 10 times
[19:46] <Langjan> you really need it if you use kde
[19:46] <Langjan> I can do without
[19:47] <Kilos> turmeric must have fat or those 2 oils to be able to get past guts
[19:47] <Langjan> interesting
[19:47] <Kilos> ok i treid
[19:47] <Kilos> tried
[19:47] <Kilos> i dont sit all day fixing kde which doesnt break
[19:47] <Langjan> well done! I'll make a note and get my cook onto it
[19:48] <Kilos> i do research to use up all my free data
[19:48] <Kilos> ok sir . have a good night
[19:48] <Langjan> researching sheep
[19:48] <Kilos> ai!
[19:48] <Langjan> tel lekker skape tot jy slaap
[19:48] <Langjan> chat again tomorrow
[19:49] <Langjan> groete van Chris Dames
[19:49] <Kilos> dankie baie
[19:49] <Kilos> selle terug
[19:50] <Langjan> Sal doen dankie rustige nag Kilos
[19:50] <Kilos> dankie
[20:21] <andrewlsd> Night all
[20:47] <chaos505> hello


[05:13] <nog> .
[23:46] <klingo> hello, is it possible to use yours modified fglrx drivers in existing ubuntu + gnome install ?