[05:41] <zyga> Good morning
[06:31] <mborzecki> morning
[06:39] <zyga> Hey mborzecki :-)
[06:45] <mborzecki> zyga: hey
[06:46] <mborzecki> zyga: simple review ? https://github.com/snapcore/snapd/pull/6596
[06:46] <mup> PR #6596: spread: restore SELinux context when we mess with system files <SELinux> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6596>
[06:50] <zyga> On it
[06:52] <zyga> Done
[06:52] <mborzecki> zyga: thanks
[07:15] <zyga> Hello mvo
[07:19] <mvo> hey zyga
[07:24] <mborzecki> mvo: hey
[07:25] <zyga> じゃあまた
[07:25] <zyga> That was what you asked about last time
[07:26] <mvo> hey mborzecki
[07:26] <mvo> zyga: !!!
[07:26] <mvo> zyga: amazing
[07:26] <mvo> zyga: looking forward for you teaching me some more
[07:29] <zyga> I’ll be around shortly
[07:43] <mvo> hey sil2100 ! quick question - can we get https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd into core18 via your foundations ppa maybe? this way we can run our regression test (and full suite) with the fix just like we did with xenial
[08:04] <pstolowski> morning
[08:04] <mvo> hey pstolowski
[08:14] <zyga> Hey Pawel
[08:22] <mborzecki> mvo: https://www.viva64.com/en/b/0600/
[08:22] <mborzecki> zyga: ^^
[08:22] <mborzecki> pstolowski: hey
[08:23] <mvo> mborzecki: looks good, we should try it
[08:27] <zyga> Applied
[08:27] <zyga> Thank you
[08:37] <pedronis> mvo: couple of Q/comments on 6401  , I didn't notice but we are trying not to add anymore to api.go, see recent work by Chipaca and me
[08:39] <mvo> pedronis: oh, ok. I have a look, I missed that. thank you
[08:42] <Chipaca> mvo: i'd gladly pick that up if you're otherwise busy
[08:42]  * Chipaca dreading the merge-the-health-checks work
[08:42] <Chipaca> :-)
[08:42] <mvo> Chipaca: yeah, that is welcome
[08:42] <Chipaca> ok
[08:42] <mvo> Chipaca: \o/
[08:43]  * mvo tries to tame wait-chains right now
[08:44] <pedronis> Chipaca: did you update the Reason: scheduled one?
[08:44] <pedronis> and morning
[08:44] <Chipaca> first i'll address pedronis's comment on #6598
[08:44] <mup> PR #6598: overlord/snapstate, store: set a header when auto-refreshing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6598>
[08:44] <Chipaca> pedronis: morning
[08:44] <Chipaca> pedronis: i'd written up to # and went looking for the number :-)
[08:45] <Chipaca> pedronis: it's just the flag -> opt thing, right?
[08:45] <pedronis> Chipaca: there's a suggested if reorg as well
[08:45] <Chipaca> pedronis: or do you want me to also do the cleanups of things that were already there?
[08:45] <pedronis> Chipaca: ideally also the cleanups, yes
[08:46] <Chipaca> (that'll make the diff bigger, meaning less chance convincing pedronis it's minimal and can go in 2.38 :-p)
[08:46] <pedronis> Chipaca: you can do a follow up instead
[08:47] <pedronis> but it would be good to address them
[08:47] <Chipaca> pedronis: your call, I don't mind if this doesn't make 2.38 :-)
[08:50] <pedronis> Chipaca: either maybe the if, but the rename should be rather innocuous
[08:50] <pedronis> Chipaca: I mean, I don't think the diff will be that much bigger
[08:50] <pedronis> the biggest addition are the tests in fact
[08:50] <Chipaca> i wonder why we decided rate limit would be an int64 (and not a uint64)
[08:51] <pedronis> Chipaca: no clue, I don't think I reviewed that code
[08:52] <pedronis> Chipaca: it starts with ParseByteSize returning int64
[08:52] <pedronis> (but that doesn't support -5b)
[08:53] <pedronis> Chipaca: anyway that is a bigger change
[08:53] <pedronis> not for this one
[08:53] <pedronis> Chipaca: but yes, it makes one wonder if rateLimit can be -128
[08:53] <Chipaca> totally
[08:54] <Chipaca> I'll change things around a little, hopefully for the better, and push a change to make the rate thing not be negative separately
[08:54] <Chipaca> ParseByteSize doesn't support negative numbers more by accident than by design i fear
[08:54] <pedronis> Chipaca: do negative sizes make sense though?
[08:54] <Chipaca> no
[08:55] <Chipaca> I mean, they might be used in the kernel or something to indicate errors
[08:55] <Chipaca> but for our use, no
[08:55] <Chipaca> (and our use of ParseByteSize is purely about rate limiting)
[09:04]  * dot-tobias waves hello
[09:10] <Chipaca> pedronis: reqOptions() -> downloadReqOpts() ok with you?
[09:11] <pedronis> Chipaca: yes, it is used in download and connectivity check, right?
[09:13] <Chipaca> pedronis: yes, and in conn check it's used for the download endpoint
[09:13] <pedronis> yup
[09:17] <zyga> hey Chipaca :)
[09:17]  * zyga is happy despite the rainy day
[09:18] <Chipaca> zyga: morning sah :-)
[09:23] <zyga> Chipaca: brexit makes my sleeping pattern erratic
[09:23] <Chipaca> zyga: welcome to my world
[09:23] <zyga> Chipaca: on the up side, the current state, as chaotic as it is, feels like an improvement over last few weeks
[09:24] <zyga> Chipaca: at least from far away here, I don't know how it feels to be directly affected
[09:24] <Chipaca> zyga: I'm refusing to get my hopes up, but my favourite outcome is still in the race
[09:24] <mvo> Chipaca: I did an unrelated change (unrelated to the api layout we discussed) you may need to git pull for 6401
[09:24] <Chipaca> mvo: will do
[09:33] <pedronis> mvo: thank you for adding that check
[09:34] <mvo> my pleasure
[09:44] <Chipaca> pedronis, mvo, pushed to 6401
[09:44] <Chipaca> maybe i should've pushed two commits
[09:44] <mvo> Chipaca: thank you!
[09:44] <Chipaca> instead of one with two changes
[09:44] <Chipaca> hm
[09:45] <Chipaca> pedronis: again not daemon_test package because apiBaseSuite is a beast
[09:45] <pedronis> Chipaca: that's ok, we can look into that at some point
[09:45] <pedronis> but at least the beasts are not growing
[09:45] <Chipaca> y
[09:45] <Chipaca> yes
[10:07] <Chipaca> ogra: you around?
[10:07] <mborzecki> #6596 is one unlucky PR
[10:07] <mup> PR #6596: spread: restore SELinux context when we mess with system files <SELinux> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6596>
[10:08] <mborzecki> the travis job just keeps on failing and failing, either github, or store timeout, or some from-repo package installation taking too long
[10:08] <ogra> Chipaca, in a meeting, so half way ...
[10:15] <ackk> hi, I'm trying to build a core18 snap with multipass, but it seems to just hang there after starting the vm. if I "multipass shell" in it, I don't see anything running. how can I debug this?
[10:15] <mvo> pedronis: quick question (if you have a moment) - in doUpdate we merge a bunch of taskSets and the "edge" information (DownloadAndChecksDoneEdge) gets lot - one approach would be to transfer edges in ts.AddAll(anotherTs), I drafted this in http://paste.ubuntu.com/p/tDJf9XbTGg/ would love to hear your thoughts http://paste.ubuntu.com/p/tDJf9XbTGg/
[10:16] <mvo> (ups, sorry for the same url twice)
[10:23] <mborzecki> guys, so how about we land https://github.com/snapcore/snapd/pull/6270 ?
[10:23] <mup> PR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6270>
[10:24] <pedronis> mvo: Chipaca: I made a help suggestion in 6401
[10:24] <pedronis> mvo: it's a bit problematic because some edges might not make sense in the larger task set
[10:24] <mvo> pedronis: I can also just transfer the edge over in doUpdate explicitely
[10:25] <mvo> pedronis: thats the simplest one
[10:25] <mvo> pedronis: its slightly annoying that this area of code has to have knowledge about this though
[10:25] <mvo> pedronis: or I can try to rework the way doUpdate is using []*TaskSet but that seems to be hard
[10:26] <mvo> pedronis: anyway, would love some ideas :)
[10:26] <pedronis> mvo: let me look at the code
[10:26] <mborzecki> pedronis: updated #6593
[10:26] <mup> PR #6593: sandbox/seccomp: a helper package wrapping calls to snap-seccomp <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6593>
[10:32] <pedronis> mvo: I think it would be fine to have  separate AddAllWithEdges (my point is mostly tha whether to copy them over, rename them around etc needs to be conscious decision)
[10:35] <mvo> pedronis: ok - with the same error handling as is in there already? i.e. error on dupes?
[10:35] <pedronis> mvo: yes
[10:35] <mvo> pedronis: great, thank you! I make this happen
[10:35] <Chipaca> pedronis: a problem with that help message is that AIUI it breaks https://forum.snapcraft.io/t/convention-for-command-help-text/1856
[10:36] <pedronis> Chipaca: fix it
[10:36] <Chipaca> :-)
[10:36] <Chipaca> pedronis: the docs, or the help message :-D
[10:36] <pedronis> Chipaca: I mean the original was saying too little
[10:36] <Chipaca> a'ight
[10:36] <pedronis> we need something that respect the style guide
[10:37] <pedronis> but also tells more
[10:38] <pedronis> mborzecki: what's the difference between InternalToolPath and the helper? I'm obtuse
[10:39] <mborzecki> pedronis: in that PR none, in the final one InternalToolPath won't work because it assumes it's either distro libexecdir or a path under snap-mount-dir
[10:39] <mborzecki> pedronis: and in bootstrap the mount path is none of the 2 locations
[10:41] <pedronis> mborzecki: does it mean InternalToolPath is broken?
[10:41] <pedronis> I mean are we sure it doesn't it this issue in some cases
[10:43] <mborzecki> pedronis: i wouldn't say it's broken, it's more like there is an assumption that snapd is installed in the system in some way, which is true in general, but not true during bootstrap
[10:44] <Chipaca> huh, Nonce is missing or invalid
[10:44] <ackk> does snapcraft keep any state other than the usual (parts/ stage/ prime/) dirs when run in --destructive-mode ?
[10:46] <pedronis> mborzecki: are we failing generate key during bootstrap, I see similar code
[10:46] <pedronis> there
[10:47] <pedronis> mborzecki: findSnapdPath
[10:48] <mborzecki> pedronis: that code is correct
[10:49] <mborzecki> pedronis: it does not fall back to filepath.Join(dirs.DistroLibexecDir,...)
[10:49] <mborzecki> pedronis: perhaps an update to InternalToolPath would make sense
[10:50] <mborzecki> pedronis: after all if the tool is 'internal' it's supposed to be where snapd binary is
[10:50] <pedronis> afaict it does fallback
[10:50] <pedronis> maybe I'm reading it wrong
[10:50] <pedronis> anyway I'm a bit worried about all this places doing slightly different with self/exe
[10:53] <Chipaca> pedronis: I just split it :-)
[10:54]  * Chipaca context-switches pedronis for fun & profit
[10:54] <mborzecki> haha
[10:54] <pedronis> mborzecki: if I read correctly we do a full seeding with snapd running from the tmp dir
[10:54] <mborzecki> pedronis: yes
[10:54] <pedronis> so any place is potentially buggy
[10:54] <mborzecki> yup, fortunately it's only system key and seccomp at this point
[10:54] <pedronis> well, no
[10:55] <pedronis> there's a place using InternalToolPath
[10:55] <pedronis> maybe it's buggy
[10:55] <pedronis> or not
[10:55] <dot-tobias> Can I somehow check how snapd reads my gadget.yaml by invoking some CLI command? I have a default configuration that has to be fed to the configure hook as a string, but it really is a YAML file thus should preserve line breaks.
[10:56] <mborzecki> pedronis: haha :P
[10:56] <Chipaca> dot-tobias: have you looked at what the online yaml parser makes of it?
[10:56] <Chipaca> (was it you i showed that one to yesterday?)
[10:57] <mborzecki> pedronis: i'd say that in the general case we should just do filepath.Dir(Readlink("/proc/self/exe")) and use that
[10:57] <pedronis> mborzecki: interfaces/mount/ns.go
[10:57] <mborzecki> pedronis: unless realdink fails, in which case fallback to distro libexecdir may be ok
[10:58] <pedronis> mborzecki: the code is not like that though, in most of these places
[10:58] <pedronis> they all check mount dir
[10:59] <dot-tobias> Chipaca: Yes, I was the one from yesterday 😊 I checked and it preserves line breaks as \n, but feeding this to mir-kiosk (display-config can be set as a string) results in an erroneous miral-kiosk.display file with newline printed as literal \n
[10:59] <Chipaca> dot-tobias: can you show me?
[11:00] <mborzecki> pedronis: at least for the seccomp tool, I updated this here https://github.com/snapcore/snapd/pull/6485/files#diff-a5ed6485262fae2e80ad61a8b843504eR68
[11:00] <Chipaca> dot-tobias: to answer your question directly, there isn't a way to do that right now
[11:00] <mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
[11:01] <pedronis> mborzecki: I have a bit lost track of why the check
[11:01] <dot-tobias> Chipaca: Sure, here's the current gadget.yaml: https://gitlab.com/glancr/gadget-snap-pi-kiosk/blob/master/gadget.yaml#L12
[11:01] <pedronis> we probably need to talk with mvo
[11:01] <mborzecki> pedronis: a chat then?
[11:01] <pedronis> yes
[11:01] <mborzecki> mvo: ^^
[11:02] <mborzecki> pedronis: mvo: HO?
[11:02] <mvo> mborzecki: in a meeting right now
[11:02] <mborzecki> mvo: ok, once you're finished then?
[11:02] <dot-tobias> Chipaca: If I run "snap set mir-kiosk display-config="$(cat a config file with the exact same contents)", everything works fine. But I suspect the multiline string from gadget.yaml is mangled somewhere.
[11:05] <dot-tobias> Chipaca: I can't really check what the actual result is from the device intialization as snapd errors (mir-kiosk configure hook can't parse the mess it gets from the yaml default) and rolls back. I occasionally check on-device but I'm always either too early or too late to see the actual file created 😞
[11:06] <Chipaca> dot-tobias: which 'actual file created'?
[11:06] <Chipaca> dot-tobias: (i'm not super familiar with this part of the code :) )
[11:08] <dot-tobias> Chipaca: mir-kiosk's configure hook saves display-config to a file in $SNAP_DATA/miral_kiosk.display (cf. https://github.com/MirServer/mir-kiosk/blob/ad041e6b19205acacaf9881568061d8fd5a5742e/snap/hooks/configure#L29).
[11:08] <Chipaca> right, but the first boot config isn't done from the file
[11:08] <Chipaca> it's done from reading the snap.yaml
[11:09] <Chipaca> dot-tobias: let me load and dump that yaml file and see what snapd makes of it
[11:12] <dot-tobias> Chipaca: That would be great, thank you. Correct me if wrong, but I thought that the gadget setup was roughly this: boot > mir-kiosk snap is installed from prefetched .snap, including any default config > gadget.yaml is read for default settings > snapd basically runs “snap set snap-name some-setting=specified-value-from-gadget.yaml – if that's the case, I don't quite follow your statement about first boot config
[11:12] <Chipaca> dot-tobias: snapd does basically run snap set …
[11:13] <Chipaca> dot-tobias: but the file comes after 'snap set', not before
[11:13] <Chipaca> dot-tobias: so if the file has mangled \n's, it's because whatever called the equivalent of 'snap set' did it wrong
[11:14] <Chipaca> dot-tobias: and the codepath is simple enough that it's _probably_ reading it wrong in the first place but idunno
[11:14] <Chipaca> getting there
[11:14] <Chipaca> dot-tobias: the problematic config is display-config, yes?
[11:14] <dot-tobias> Chipaca: I guess we're talking about the same thing, but not sure 😄
[11:15] <dot-tobias> Chipaca: yes, display-config is the one I'm trying to set.
[11:16] <Chipaca> the config is loaded jus' fine
[11:16] <Chipaca> so the problem is in the setting of it
[11:16] <Chipaca> hmm
[11:17] <Chipaca> oh wait what is this normalize code
[11:18] <dot-tobias> Chipaca: Yes, I suspect that the gadget.yaml multiline string is parsed somewhere and passed to “snap set” with literal \n newlines, which mir-kiosk's configure hook does not further parse or validate (just echoes the passed string to miral-kiosk.display) – thus resulting in one long string with literal \n instead of a valid YAML dict
[11:19] <Chipaca> indeed
[11:22] <dot-tobias> Chipaca: And that's the part where I don't know if “I'm holding it wrong” or if preserving a config file with implicit newlines (dunno if that's the correct term) through this whole YAML parsing is currently just not possible. 😊
[11:23] <Chipaca> dot-tobias: so, there's a bug, this should work
[11:23] <Chipaca> dot-tobias: we should fix it
[11:23] <Chipaca> dot-tobias: but that doesn't unblock you
[11:23] <Chipaca> dot-tobias: however, there's a way out for you
[11:23] <Chipaca> i hope
[11:23] <Chipaca> dot-tobias: but it's a bit nasty
[11:24] <dot-tobias> Chipaca: I'm all for nasty workarounds if they do the job until the elegant way is possible 😊
[11:26] <Chipaca> dot-tobias: rewrite the config file yaml using the json-like syntax
[11:26] <Chipaca> dot-tobias: gimme a sec i'll do it for you
[11:26] <mup> PR snapd#6596 closed: spread: restore SELinux context when we mess with system files <SELinux> <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6596>
[11:29] <Chipaca> dot-tobias: layouts: {normal: {cards: [{card-id: 0, HDMI-A-1: null}]}, right: {cards: [{card-id: 0, HDMI-A-1: {orientation: right}}]}, left: {cards: [{card-id: 0, HDMI-A-1: {orientation: left}}]}, inverted: {cards: [{card-id: 0, HDMI-A-1: {orientation: inverted}}]}}
[11:29] <Chipaca> dot-tobias: no comments in this format :-/
[11:30] <Chipaca> pedronis: pstolowski: we have some issue with spurious escaping of config values coming from gadget.yaml
[11:30] <dot-tobias> Chipaca: Can live without comments for now. Thank you very much! So I put that into gadget.yaml > defaults > display.config as a string?
[11:30] <Chipaca> dot-tobias: yes
[11:31] <Chipaca> dot-tobias: let me know if it actually works of course :-)
[11:31] <Chipaca> pedronis: pstolowski: meaning the snaps get \\n instead of \n for ex
[11:32] <dot-tobias> Chipaca: Will do, thank you!
[11:32] <pedronis> Chipaca: escaping where?
[11:33] <mborzecki> pedronis: mvo: can we land #6270?
[11:33] <mup> PR #6270: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6270>
[11:33] <Chipaca> pedronis: the Configure hook that's run using the values from the gadget.yaml
[11:34] <pedronis> Chipaca: yes
[11:34] <pedronis> Chipaca: where is the escaping,   snapctl get? or before?
[11:35] <pedronis> or it's misunderstanding about what the result is
[11:35] <Chipaca> pedronis: the loading seems to be fine, no spurious escaping
[11:35] <Chipaca> pedronis: I don't know where it's happening, don't have an easy way to repro
[11:36] <pedronis> we do need a repro
[11:36]  * pedronis lunch
[11:36] <Chipaca> pedronis: I mean, dot-tobias was hitting this IRL
[11:37] <Chipaca> pedronis: I mean I don't have a _minimal_ way to reproduce it that doesn't involve a gadget and a device and first-booting it
[11:37] <Chipaca> fortunately there's a workaround for them, as it's yaml so you can just scrunch it up (ewww), but if it'd been an .ini file we would've been SOL
[11:37] <pedronis> Chipaca: we do have spread test like that
[11:38] <pedronis> I mean we should be able to write a spread test
[11:38] <Chipaca> I know :-) i'm saying I haven't -- I was trying to make it SEP
[11:42] <pedronis> Chipaca: did we learn anything more about the 19.40 seeeding woes?
[11:42] <pedronis> 19.04
[11:42]  * pedronis really lunch
[11:43] <Chipaca> pedronis: I'm trying to reproduce them locally
[11:43] <Chipaca> s/them/it/
[11:43] <Chipaca> them == the woes, clearly
[11:45] <Chipaca> right now I'm struggling to get a new disco install to _boot_, let alone be snappy
[11:46] <Chipaca> two different icons for installation, with arrows pointing different ways
[11:49] <ogra> Chipaca, so what was that ping about ?
[11:53] <Chipaca> ogra: who knows :-)
[11:53] <ogra> heh
[11:55] <mvo> hrm, hrm, whats up with tests
[11:55] <mvo> ogra: while you are here - you probably like https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd
[11:56] <mvo> ogra: we just need to convince someone from the sru team to actually approve :)
[11:56] <ogra> YAY !!!
[11:56] <mvo> mborzecki: you wanted to talk about something earlire? sorry was in a meeting and then forgot
[11:57] <mborzecki> mvo: yes, we need pedronis too
[11:57] <mvo> hey sil2100 ! quick question - can we get https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd into core18 via your foundations ppa maybe? this way we can run our regression test (and full suite) with the fix just like we did with xenia
[11:57] <mvo> mborzecki: probably after lunch, what was the question?
[11:57] <mvo> and why are tests unhappy currently :( ?
[11:58] <mborzecki> mvo: some concerns about finding internal tools
[11:59] <mvo> mborzecki: ok, so - for snapd its easy, just os.dirname(os.link("/proc/self/exe"))
[12:00] <mvo> mborzecki: but for the "snap" binary its not
[12:00] <mvo> mborzecki: I think we need to lookup something (snap-exec?) there
[12:01] <mvo> mborzecki: maybe the answer is that the toolpath is also just relative for the snap binary "../lib/snapd"
[12:01] <mvo> mborzecki: am I actually speaking about the right question or am I lost in something else :) ?
[12:01] <mborzecki> mvo: ../lib{exec}/snapd
[12:02] <mborzecki> mvo: right, we were discussing the case of 'snapd' and cmd.InternalToolPath which does not work for boostrap environment
[12:02] <mvo> mborzecki: yeah, for snapd my suggestion is to always look into the same dir
[12:03] <mvo> mborzecki: and maybe (to support running from a git tree) to fallback to /usr/lib{,exec}/snapd
[12:03] <mvo> mborzecki: but for snap its slightly more complicated
[12:04] <sil2100> mvo: hey! Let me take a look
[12:05] <mup> PR snapd#6599 opened: snapstate,state: add TaskSet.AddAllWithEdges() and use in doUpdate <Created by mvo5> <https://github.com/snapcore/snapd/pull/6599>
[12:05] <sil2100> mvo: hm, I can review it today for -proposed and then copy it over to the PPA for testing (with a lower version)
[12:06] <mvo> sil2100: cool, let me know if I can help in any way (but I probably don't have the right permissions)
[12:10] <mborzecki> mvo: i can try and open a PR cleaning up cmd.InternalToolPath/findSnapdPath/seccompToBpfPath to be consistent
[12:12] <pedronis> Chipaca: do we understand enough from dot-tobias situation to make a LP bug?
[12:12] <mvo> mborzecki: I think that would be good
[12:12] <mvo> mborzecki: maybe a separate PR?
[12:12] <Chipaca> pedronis: I think so yes
[12:12] <mborzecki> mvo: right
[12:12] <Chipaca> dot-tobias: could you do that? file an lp bug about this
[12:12] <pedronis> Chipaca: could you make one?
[12:12] <pedronis> or dot-tobias
[12:12] <Chipaca> pedronis: trying to punt it :-)
[12:12] <pedronis> mborzecki: yes, simplifiying would be good
[12:13] <pedronis> mborzecki: mvo: do we compute  system key from snap ? or only from snapd?
[12:13] <mborzecki> pedronis: only snapd apparently
[12:13] <pedronis> ok
[12:15] <pedronis> mborzecki: no, both, snap run uses SystemKeyMismatch
[12:15] <pedronis> so findSnapdPath is abit more delicate
[12:15] <pedronis> afaict
[12:16] <mborzecki> pedronis: right, but only snapd build-id is used in the system key data
[12:16] <pedronis> mborzecki: well and snap-seccomp output in your PRs? no?
[12:16] <mborzecki> yes
[12:24]  * pstolowski lunch
[12:25] <sil2100> mvo: ok, bionic looks good, accepted for bionic-proposed
[12:25] <seb128> Chipaca, where do you see those inconsistant arrows for installation?
[12:26] <Chipaca> heh
[12:26] <sil2100> I will copy it to the PPA but please please please shepherd the bionic-proposed systemd upload
[12:26] <Chipaca> seb128: https://snapforum.s3.amazonaws.com/original/2X/6/6db33b0da7456be46210985f939a0e2040284e6b.jpg
[12:26] <seb128> Chipaca, did you sort out your non booting image? maybe worth mentioning on #ubuntu-desktop
[12:26] <seb128> if you need help figuring it out
[12:26] <sil2100> mvo: systemd uploads trigger a lot of tests and a lot of failures and the uploader needs to make sure they pass and/or are identified as flaky
[12:26] <Chipaca> seb128: it was booting, just not doing anything graphic
[12:26] <jdstrand> pedronis: can you advise on what to do about https://travis-ci.org/snapcore/snapd/jobs/505983378?
[12:26] <sil2100> Wouldn't want this upload to be stuck in bionic forever
[12:26] <seb128> Chipaca, ah, thx
[12:26] <Chipaca> seb128: -vga qxl fixed that
[12:27] <seb128> Chipaca, ah, good
[12:27] <Chipaca> seb128: https://forum.snapcraft.io/t/no-more-preinstalled-snap-on-ubuntu-19-04/10339/49?u=chipaca
[12:27] <jdstrand> pedronis: hello btw :)
[12:27] <Chipaca> (just writing random stuff there as i try to repro the issue at hand)
[12:28] <jdstrand> pedronis: sergiusens said something about a rebase, but I thought that would confuse github
[12:28] <pedronis> jdstrand: did you see my comment on why it's blocked?  (it was about the tests, I think we talked about it but I forgot to write the reason in the PR)
[12:28] <seb128> Chipaca, ah, tb didn't charge the image from the email for some reason, I see it now, the 'other arrow' on the desktop is because it's a symlink, it's a bit unfortunate how it 'conflicts' with the icon own arrows placed in the same corner
[12:29]  * jdstrand doesn't have 'zyga@xenial' anywhere in the tree
[12:29] <Chipaca> seb128: if it didn't, then it'd have two opposite arrows :-)
[12:29] <seb128> Chipaca, Ken didn't get the issue every time, might be racy, so I guess "how you reproduce' is by trying a new install again
[12:29] <zyga> jdstrand: does git log do?
[12:29] <zyga> jdstrand: it's the history
[12:29] <Chipaca> seb128: yep
[12:29] <jdstrand> pedronis: I thought you said it could go in so long as tests came later. you want the tests now?
[12:29] <seb128> Chipaca, right :)
[12:29] <pedronis> jdstrand: sorry, it was not about the tests
[12:29] <pedronis> jdstrand: please read the comment in the PR
[12:30] <jdstrand> zyga: 'does git log do'? can you rephrase?
[12:30] <pedronis> and answer there
[12:30] <zyga> jdstrand: run git log | grep zyga@xenial
[12:30] <jdstrand> pedronis: "I agree though with niemeyer comments regarding the summaries, we probably want to change those before merging." I did that
[12:31] <jdstrand> zyga: yes, I have that:
[12:31] <jdstrand> Author: zyga <zyga@xenial-server>
[12:31] <jdstrand>     Signed-off-by: zyga <zyga@xenial-server>
[12:31] <zyga> the author needs to be changed
[12:31] <Chipaca> every time I try gnome shell i miss the keyboard-friendliness of unity :-(
[12:31]  * Chipaca hugs his 16.04 to his chest
[12:32] <pedronis> jdstrand: this comment: https://github.com/snapcore/snapd/pull/5644#issuecomment-472723883
[12:32] <mup> PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <⛔ Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
[12:32] <pedronis> from this morning
[12:32] <jdstrand> zyga: uhh, everyone has to do this?
[12:32] <zyga> jdstrand: perhaps I misunderstand but this is in an incoming PR?
[12:32] <zyga> jdstrand: if so,  just that needs to change
[12:33] <dot-tobias> Chipaca / pedronis : I'll open a LP bug (for snapd?) and try to describe the problem as detailed as possible; Chipaca feel free to make amends if I misunderstood the actual issue (but at least I can describe what the outcome is)
[12:33] <pedronis> jdstrand: we can work on landing it on our side
[12:33] <Chipaca> dot-tobias: thanks!
[12:33] <pedronis> jdstrand: I'm still interested if what I described is a blocker or not
[12:36] <jdstrand> pedronis: I answered in the PR. I don't consider it a blocker since at worst I will see things come into the queue and manually approve them/grant the snap decl while I'm working through all the grants
[12:37] <jdstrand> pedronis: but if you do, then I can try to get to it. it's several hundred so it will take me a while
[12:37] <pedronis> jdstrand: what I'm worried is if somebody installs with snapd beta one of the affected snaps before the declaration is changed
[12:38] <jdstrand> zyga: it isn't a new PR, it is an ancient PR at this point that all of a sudden started failing that cause I did a git fetch/merge
[12:38] <pedronis> will not the install fail?
[12:38] <pedronis> well, not fail
[12:38] <pedronis> but not work until it connects things manually
[12:38] <pedronis> which is not expected
[12:39] <jdstrand> yes, that would happen
[12:39] <jdstrand> that is a fair point
[12:41]  * jdstrand doesn't understand how all of a sudden 92a096278e040b452125260b00742ae6e62caf2c from October is now causing me problems
[12:41] <ackk> Saviq, hi, how can I debug what snapcraft is doing inside a multipass vm?
[12:42] <ackk> Saviq, I'm trying to figure out why a snapcraft build seems to hang after having launched the vm
[12:42] <jdstrand> zyga: ^ why am I seeing this now and why doesn't master change it so that no one else will be affected?
[12:43] <zyga> jdstrand: I don't understand, can you tell me where exactly are you seeing it?
[12:43] <jdstrand> zyga: https://travis-ci.org/snapcore/snapd/jobs/505983378
[12:43] <zyga> jdstrand: I see your ping now, sorry for the interrupt
[12:45] <zyga> jdstrand: wow, no idea now
[12:45] <jdstrand> perhaps tests/lib/cla_check.py should ignore that email if people don't want to rewrite history. how is this passing for anyone?
[12:45] <zyga> no idea, it's odd
[12:46] <jdstrand> pedronis: oh, this is all set for 2.39 anyway. that's right. I was thinking as soon as it was committed, I'd get started, do 50 a day or something
[12:47] <jdstrand> Chipaca: hey, you seem to have written ./tests/lib/cla_check.py
[12:48] <zyga> jdstrand: sorry I was not of much help
[12:48] <jdstrand> Chipaca: after a recent fetch/merge with master for an existing PR, I started seeing https://travis-ci.org/snapcore/snapd/jobs/505983378
[12:48] <zyga> jdstrand: perhaps do a test: rebase and open a new PR
[12:48] <zyga> jdstrand: if that passes it's a data point
[12:48] <Chipaca> jdstrand: huh
[12:49] <jdstrand> Chipaca: the email address that is failing is from 92a096278e040b452125260b00742ae6e62caf2c october
[12:49] <Chipaca> jdstrand: should be easy to fix
[12:49] <Chipaca> jdstrand: somehow :-|
[12:50] <Chipaca> jdstrand: I mean, should be easy to fix the script to catch that exception
[12:50] <jdstrand> Chipaca: I mean, I can adjust the author with a git rebase, but is that the right thing to do? why aren't others seeing this? (granted, my pr started before october, so maybe the check was added after that and I'm only seeing this cause I'm the only one with commits that stretch that far back?)
[12:50] <Chipaca> jdstrand: I don't know why it's trying to verify an email already on master though
[12:50] <Chipaca> hmm
[12:51] <Chipaca> oh
[12:51] <zyga> this branch predates october
[12:51] <zyga> is that the reason?
[12:51] <Chipaca> jdstrand: there's been a change in travis.yaml that might be relevant
[12:51] <Chipaca> or was that in snapcraft
[12:51] <Chipaca> looks like it was just in snapcraft
[12:52] <jdstrand> Chipaca: at this point I'm happen to be told what to do and I'll mash buttons like a monkey :)
[12:52] <jdstrand> happy*
[12:53] <Chipaca> jdstrand: http://paste.ubuntu.com/p/QdXzftpW3b/
[12:53] <Chipaca> jdstrand: that might help
[12:53] <jdstrand> pedronis: please advise since this is for 2.39 if I need to slog though all of them or can go at my own pace
[12:54]  * Chipaca ⇝ lunch
[12:54] <pedronis> jdstrand: I would recommend to start
[12:55] <jdstrand> pedronis: well there is starting and there is slogging so the PR is unblocked. it sounds like you mean the latter
[12:56] <sergiusens> jdstrand: we rebase all the time in snapcraft, github is really saavy, it even mentions you rebased in the  PR... the only drawback is when you amend new code from the PR (problem for the reviewer, not github), but stuff that is in master is usually fine
[12:56] <jdstrand> Chipaca: that shange seems unrelated to my PR and should be in a separate PR. I don't know why that is fixing things or what side effects it may have so am uncomfortable proposing it
[12:57] <jdstrand> sergiusens: when you say rebase, what are you saying, change the order so the merges happen before my stuff?
[12:58] <jdstrand> sergiusens: or are you saying change the author
[12:58] <jdstrand> ?
[12:58] <sergiusens> git rebase origin/master (it will even remove the merge commit)
[12:58] <pedronis> jdstrand: sorry, I would prefer not to buy a conscious regression, we already have our fair share of unconscious ones
[12:59] <jdstrand> pedronis: well, since it is for 2.39, I don't need to drop everything, so I'll go at whatever pace works for me and that makes it commitable for 2.39
[12:59] <sergiusens> jdstrand: here's an example of a rebase https://github.com/snapcore/snapcraft/pull/2479 (search for force-pushed)
[13:00] <mup> PR snapcraft#2479: store: support registering to a specific store <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2479>
[13:00] <pedronis> jdstrand: that sounds good
[13:07] <pedronis> mborzecki: btw to be clear I don't thik that cleanup should block 6593 but is good to have a plan forward for that area
[13:09] <mborzecki> off to pick up the kids
[13:10] <jdstrand> sergiusens: that's fine, and I use rebase all the time. I was wondering what you were specifically suggesting since I have gotten several suggestions. I think I know what to try
[13:17] <dot-tobias> Chipaca / pedronis: Filed https://bugs.launchpad.net/snapd/+bug/1820060 → let me know if it's clear enough
[13:18] <mup> Bug #1820060: multiline strings in gadget.yaml defaults are mangled <snapd:New> <https://launchpad.net/bugs/1820060>
[13:19] <ackk>  sergiusens, hi, I have a snapcraft build that's been stuck for ages at "Launched: <vm>", it seems nothing is happening in the VM itself, how can I debug that?
[13:19] <mup> PR snapd#6600 opened: timings: add new helpers, Measurer interface and DurationThreshold <Created by stolowski> <https://github.com/snapcore/snapd/pull/6600>
[13:25] <dot-tobias> Is there a command I can run to retry a failed change? My system init change (gadget snap) is failing and I want to retry so that I can inspect some files which are deleted as soon as it err's
[13:29] <jdstrand> pedronis, Chipaca, zyga, sergiusens: ok, just a simple rebase was enough to put the PRs changes on top (and after the problematic commit) and make cla check happy
[13:35] <zyga> woot :)
[13:42] <Chipaca> zyga: just seen news that A50 is blocked
[13:42] <Chipaca> zyga: thought you might like to hear that
[13:43] <kenvandine> Chipaca: well... today's iso seems fixed!
[13:43] <willcooke> Chipaca, using the great troubleshooting method of "maybe it will just fix itself" kenvandine and I have tested with today's ISO and everything is back to normal.
[13:43] <kenvandine> no idea what the hell was up with the past few days
[13:43] <willcooke> II'll keep testing and make sure it's reliable
[13:43] <willcooke> Sorry for the wild goose chase
[13:43] <kenvandine> i noticed the iso size is a little different
[13:43] <Chipaca> kenvandine: willcooke: from the description it was a race, so i'd expect it to come back in the same way
[13:44] <mvo> sil2100: thanks for accepting
[13:44] <mvo> sil2100: I will watch out for it
[13:44] <Chipaca> kenvandine: willcooke: I have been trying to reproduce it, and only saw it happen once in ~20 installs so far
[13:44] <willcooke> using todays iso?
[13:44] <Chipaca> kenvandine: willcooke: of course that was before i had debug logs so i leraned nothing :-(
[13:44] <kenvandine> Chipaca: oh... so you have reproduced it?
[13:45] <Chipaca> kenvandine: or something very much like it
[13:45] <Chipaca> willcooke: yes
[13:45] <willcooke> nod
[13:46] <Chipaca> willcooke: it _might_ have been something different, but it looked the same :-)
[13:46] <willcooke> :)
[13:46] <Chipaca> this was before I got systematic about it, after which nothing
[13:46] <willcooke> Heisenbug
[13:46] <Chipaca> do we still have the iso that _did_ have the issue? maybe i should use that one
[13:47]  * willcooke checks his trash
[13:47] <kenvandine> so... can we increase the log verbosity in the devel images?
[13:47] <Chipaca> kenvandine: yes, easily
[13:47] <kenvandine> Chipaca: yes
[13:47] <willcooke> I have it
[13:47] <willcooke> the ISO that is
[13:47] <kenvandine> it's still up on cdimage
[13:47] <willcooke> oh, even better
[13:47] <kenvandine> grab 20190313
[13:48] <Chipaca> kenvandine: When installing, once it prompts you to restart, before clicking restart edit /target/etc/environment and add SNAPD_DEBUG=1
[13:48] <Chipaca> kenvandine: that will give you debug logs in the install
[13:48] <willcooke> I did that yesterday on the broken image and it didnt seem to work
[13:48] <Chipaca> willcooke: disco seems to rotate journal a lot more aggressively
[13:48] <Chipaca> willcooke: so you need to look in /var/log/syslog
[13:49] <willcooke> ooooooooh
[13:49] <willcooke> thanks
[13:49] <kenvandine> Chipaca: i meant in the future, during the devel cycle we should just turn up the verbosity in the images
[13:49] <Chipaca> (which is a pain btw)
[13:49] <kenvandine> maybe up until RC or something
[13:49] <Chipaca> kenvandine: i'd like that :-)
[13:49] <kenvandine> just so when things like this happen we have a means to debug it
[13:49] <Chipaca> <3
[13:50] <kenvandine> ok, i've done 2 installs of today's image and both worked fine
[13:50] <kenvandine> and booted the live session 3 times
[13:50] <kenvandine> all good
[13:50] <kenvandine> :/
[13:50] <Chipaca> kenvandine: did you ever get this in the live session itself?
[13:51] <kenvandine> yes
[13:51] <Chipaca> nice
[13:51] <Chipaca> (for negative values of nice)
[13:52] <Chipaca> kenvandine: dropping "[Service]\nEnvironment=SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7\n" into /etc/systemd/system/snapd.service.d/debug.conf would do that fwiw
[13:53] <mup> PR snapd#6601 opened: errortracker: fix panic in Report if db cannot be opened <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6601>
[14:01] <zyga> joinign
[14:05] <dot-tobias> Chipaca: re: Workaround for mir-kiosk config: While JSON-like syntax seems to make it through snapd, mir-kiosk's configure hook expects exactly two spaces (== yaml indentation) and fails otherwise: https://github.com/MirServer/mir-kiosk/blob/ad041e6b19205acacaf9881568061d8fd5a5742e/snap/hooks/configure#L62
[14:06] <dot-tobias> Chipaca: So I'm running from one issue into the next 😄 Will now try if creating the whole file via clout-init happens at the right time (i.e. after the snap has been installed)
[14:06] <Chipaca> dot-tobias: maybe that one can be fixed from mir-kiosk
[14:10] <dot-tobias> Chipaca: I'll open a PR there once I figure out how to check for JSON-like syntax without breaking their (surely sensible) strict grep line in the YAML case. Thanks again so far!
[14:16] <seb128> kenvandine, willcooke, I would strongly recommend against thinking around the line of 'oh, we did nothing, it's fixed in today's daily, let's move on', that's going to bite us back in release week
[14:16] <kenvandine> seb128: i agree
[14:17] <mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502,
[14:17] <mup> snapd#6541, snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6597, snapd#6598, snapd#6599, snapd#6600, snapd#6601
[14:17] <kenvandine> i'm trying to see what's different in the isos
[14:17] <seb128> it doesn't matter, does it?
[14:17] <seb128> if it's timing and something changed it's not going to tell us anything on fixing
[14:17] <seb128> imho someone from the snappy team needs to do an install which has the issue and debug snapd
[14:17] <seb128> anything else is a waste of effort
[14:18] <mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502,
[14:18] <mup> snapd#6541, snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6597, snapd#6598, snapd#6599, snapd#6600, snapd#6601
[14:18] <kenvandine> seb128: you're probably right
[14:18] <kenvandine> Chipaca: are you trying the 20190313 iso?
[14:18] <Chipaca> kenvandine: y
[14:18] <Chipaca> kenvandine: yes
[14:18] <kenvandine> great
[14:36] <diddledan> does the desktop team have a channel I can discuss desktop non-snap issues?
[14:39] <mup> PR snapd#6270 closed: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6270>
[14:45] <mborzecki> btw. if you want to see the tests break and get weird errors like "Settle is not converging" you need to build an image with yocto
[15:17] <mup> PR pc-i386-gadget#8 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/8>
[15:17] <mup> PR pc-i386-gadget#9 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/9>
[15:17] <mup> PR snapd#6602 opened: [RFC] cmd, interfaces: replace local helpers with cmd.InternalToolPath() <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6602>
[15:17] <Chipaca> kenvandine: willcooke: walk with me please
[15:18] <Chipaca> kenvandine: willcooke: remember when I asked you if any of the seeded snaps were 'base: core18', and you assured me they weren't?
[15:18]  * willcooke puts his shoes obn
[15:18] <mup> PR pc-i386-gadget#8 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/8>
[15:18] <mup> PR pc-i386-gadget#9 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/9>
[15:18] <Chipaca> kenvandine: willcooke: this is true of today's image: snap info --verbose /var/lib/snapd/seed/snaps/*  shows no base: core18
[15:18] <Chipaca> kenvandine: willcooke: this is, however, _not_ true of the 20190313 image
[15:19] <Chipaca> kenvandine: willcooke: gnome-system-monitor and gnome-calculator in yesterday's image use core18
[15:19] <Chipaca> so you need to seed core18 as well, or, well, not :-)
[15:20] <mvo> 6401 needs a second review
[15:21] <kenvandine> Chipaca: oh... but the revisions of those that were on the iso did not use core18
[15:21] <mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502, snapd#6541,
[15:21] <mup> snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6597, snapd#6598, snapd#6599, snapd#6600, snapd#6601, snapd#6602
[15:22] <kenvandine> i confirmed that, they were the old revision
[15:22] <mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6502, snapd#6541,
[15:22] <mup> snapd#6553, snapd#6559, snapd#6564, snapd#6575, snapd#6577, snapd#6583, snapd#6588, snapd#6591, snapd#6592, snapd#6593, snapd#6594, snapd#6595, snapd#6597, snapd#6598, snapd#6599, snapd#6600, snapd#6601, snapd#6602
[15:22] <Chipaca> kenvandine: as I say, in yesterday's iso, the snaps in seed are base:core18
[15:23] <Chipaca> kenvandine: 'snap info --verbose' on the file says as much
[15:23] <pedronis> some of them at least
[15:23] <Chipaca> two of 'em
[15:23] <pedronis> yup
[15:23] <Chipaca> gnome-calculator and gnome-system-monitor
[15:23] <kenvandine> Chipaca: what revision of gnome-calculator was it?
[15:24] <Chipaca> kenvandine: the file says 335
[15:24] <kenvandine> that was core18
[15:24] <kenvandine> sigh...
[15:24] <pedronis> 335
[15:24] <kenvandine> i was checking those revisions... but that might have been when i was using the iso from 20190309
[15:24] <kenvandine> which was the iso the original reported used
[15:24] <kenvandine> but... i could never reproduce this problem on that iso
[15:25] <kenvandine> :/
[15:25] <mup> PR snapd#6603 opened:  snapstate: add new NoReRefresh flag and use in Remodel() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6603>
[15:25] <Chipaca> kenvandine: I'll comment on the forum, see if it's just been that they downloaded a different one or something
[15:26] <Chipaca> kenvandine: does an iso 'know' when it was made, anywhere?
[15:26] <kenvandine> i think that original report for 20190309 had some other issue...
[15:26] <kenvandine> and started misleading us
[15:26] <kenvandine> probably
[15:26] <Chipaca> kenvandine: perhaps, although by comment #3 it looks a lot like this one
[15:28] <Chipaca> kenvandine: I'm going to explain what we know so far, and see if that explains the whole thing
[15:30] <kenvandine> Chipaca: we are going to be publishing the seeded snaps based on core18 to stable in the next couple days :)
[15:30] <kenvandine> so we'll need to update the seed
[15:31] <pedronis> kenvandine: have you tested the upgrade from old base to new base, somebody reported issues with that (changing the base of a snap over refresh), zyga can tell more
[15:32] <kenvandine> i actually just tested that on xenial
[15:32]  * cachio lunch
[15:32] <kenvandine> refreshed from stable to candidate
[15:32] <kenvandine> candidate now has base: core18
[15:32] <kenvandine> worked fine
[15:33] <Chipaca> kenvandine: did you have core18 before refreshing
[15:33] <zyga> kenvandine: there's a bug where changing bases runs the new revision on the old base
[15:34] <kenvandine> i probably did have the old base
[15:34] <kenvandine> but i can test right now
[15:38] <kenvandine> Chipaca zyga: started out with no core18, refreshed candidate which did pull down core18
[15:39] <kenvandine> still installing :)
[15:39] <kenvandine> Chipaca zyga: works fine!
[15:40] <kenvandine> on disco, installed from today's iso
[15:40] <Chipaca> GREAT SUCCESS
[15:40] <kenvandine> :)
[15:42] <Chipaca> pedronis: mvo: should I squash-merge #6598 then?
[15:42] <mup> PR #6598: overlord/snapstate, store: set a header when auto-refreshing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6598>
[15:43] <mvo> Chipaca: last I looked it was two commits, I can cherry pick two :)
[15:43] <mvo> Chipaca: so either way is fine
[15:43] <Chipaca> just regular merge, then
[15:43] <Chipaca> :-)
[15:43] <mup> PR snapd#6598 closed: overlord/snapstate, store: set a header when auto-refreshing <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6598>
[15:51] <mvo> 6401 needs a second review
[15:56] <Chipaca> jdstrand: when you have a sec, could you tell me if I did something wrong wrt icdiff such that I can't install the version from candidate?
[15:56] <Chipaca> mvo: would it be very cheeky if I reviewed that myself?
[15:57] <mvo> Chipaca: its fine, I can review your bits
[15:57] <Chipaca> mvo: ok, i +1'ed your bits :-p
[16:07] <mvo> Chipaca: thank you!
[16:08] <mvo> Chipaca: I did the same
[16:08] <Chipaca> mvo: also i restarted spread because it hates you
[16:08]  * mvo nods
[16:08] <mvo> I wonder if I need to merge master
[16:08] <mvo> or if it just hates me regardless
[16:12] <pedronis> mvo: Chipaca: seems we have forgotten about ForSnapSetup  (noticed when looking at the NoReRefresh PR)
[16:12] <Chipaca> pedronis: ?
[16:12] <Chipaca> pedronis: in what sense?
[16:13] <mvo> what is ForSnapSetup?
[16:13] <pedronis> Chipaca: we have added flags that are not used in handlers, and we are not clearing them
[16:13] <pedronis> in it
[16:13] <Chipaca> mvo: a method on flags that drops things in flags that are for snapstate and not snapsetup
[16:13] <Chipaca> pedronis: ah, in that sense
[16:13] <Chipaca> pedronis: maybe we should turn it around
[16:14] <Chipaca> pedronis: less likely to forget to add things to it that are needed
[16:14] <pedronis> Chipaca: maybe
[16:14] <pedronis> Chipaca: mvo: anyway afaict only Amend has this problem
[16:14] <pedronis> but the new flag would as well
[16:15] <pedronis> (not deep consequences just a bit more unused data in the state)
[16:15]  * mvo nods
[16:17] <pstolowski> mvo, cachio can https://github.com/snapcore/snapd/pull/6553 land?
[16:17] <mup> PR #6553: tests: enable opensuse tumbleweed back <Created by stolowski> <https://github.com/snapcore/snapd/pull/6553>
[16:28] <cachio> pstolowski, checking
[16:30] <cachio> pstolowski, done
[16:30] <cachio> pstolowski, thanks!!
[16:31] <mup> PR snapd#6553 closed: tests: enable opensuse tumbleweed back <Created by stolowski> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6553>
[16:38] <cachio> mvo, ./run-checks --static
[16:41] <jdstrand> pedronis: there is something not right with icdiff. I thought I got the declaration right: https://paste.ubuntu.com/p/sBYQd2PWCB/ based on your comment in https://bugs.launchpad.net/snapstore/+bug/1814592/comments/6
[16:42] <mup> Bug #1814592: cannot compile personal-files/system-files snap declaration constraints <Snap Store:Invalid> <https://launchpad.net/bugs/1814592>
[16:43] <pedronis> jdstrand: no, you really need to squash them into one regexp with |
[16:43] <pedronis> jdstrand: otherwise one of the two entries will fail
[16:44] <pedronis> for one of the side of your ORed plug-attributes
[16:44] <pedronis> jdstrand: I said as much:  For the multiple entries in read/write so you need to use a regexp with | and quoting/() as needed
[16:44] <jdstrand> pedronis: well, that is what I thought until I read your "For the multiple entries in read/write so you need to use a regexp with | and quoting/() as needed." comment
[16:45] <jdstrand> what did you mean by multiple entries there?
[16:45] <jdstrand> for say, different snap ids?
[16:45] <pedronis> jdstrand: the multiple entries in the attribute in the snap.yam plug
[16:45] <pedronis> the rule matches for a list if each entry in the list matches the regexp
[16:46] <pedronis> for a list in the attribute in the plug/slot
[16:46] <jdstrand> you mean that read and write need the | cause they are different
[16:46] <pedronis> jdstrand: there's no write here?
[16:46] <jdstrand> no
[16:47] <jdstrand> but I'm trying to parse "the multiple entries in the attribute in the snap.yam plug"
[16:47] <pedronis> I mean you need  "read": "\\$HOME/\\.gitconfig|\\$HOME/\\.config/git/config" in the rule
[16:47] <jdstrand> I get the bit about all the entries in the list need to match the regex
[16:47] <jdstrand> pedronis: sure, I get that. I need to fix that
[16:48] <pedronis> jdstrand: ok
[16:48] <jdstrand> pedronis: but I want to understand when I am supposed to use |
[16:48] <jdstrand> oh duh
[16:49] <jdstrand> I got a wire crossed. this whole time I was interpreting '|' as a shorthand for alternate constraints. jeez
[16:49] <pedronis> np
[16:49] <jdstrand> you meant in the regex of course
[16:49] <pedronis> yes
[16:49]  * jdstrand shakes head
[16:50] <pedronis> and the entries refered to the entries in the list value of the plug attribute
[16:50] <pedronis> not rule side entries
[16:50] <jdstrand> yes
[16:50] <cachio> mvo
[16:56] <jdstrand> Chipaca: ok, it installs and it should continue to pass automated review
[16:57] <jdstrand> pedronis: thank you again. I need to make a small tweak for the alternate constraints bit in the review-tools cause of my misinterpretation of the LP comment, but that's fine
[16:57]  * jdstrand continues to shake head
[16:57] <jdstrand> it shouldn't be this hard :)
[17:01] <Chipaca> jdstrand: huh, it installs here too, now
[17:01] <Chipaca> i wonder what i'd broken before
[17:02] <Chipaca> jdstrand: anyway i'm blaming you for it working: thanks!
[17:03] <sil2100> mvo: hey! So apparently I don't have the permissions to push to the snapcore/pi-gadget branch still
[17:03] <sil2100> mvo: can you add foundations to it?
[17:04] <sil2100> mvo: since I'm in the middle of changing the branch ownership back from CanonicalLtd to snapcore
[17:05] <mvo> sil2100: let me try
[17:06] <mvo> sil2100: I think I added you now, please check
[17:06] <jdstrand> Chipaca: what broke was it had the wrond snap decl (see conversation with pedro nis ^)
[17:06]  * Chipaca reads up
[17:06] <jdstrand> Chipaca: well, you should blame me for it not working and then fixing it with pedro nis help
[17:08] <Chipaca> jdstrand: tomahto/tomeito
[17:08] <Chipaca> it works now \o/
[17:08] <Chipaca> now i need to figure out why it doesn't build on ppc64el
[17:08] <Chipaca> :-P
[17:09] <jdstrand> Chipaca: heh, well, it is hard for me to accept the gratitue since this is like the 3rd time I got this bit wrong. 4th times the charm?
[17:09] <jdstrand> pedronis may have a higher tally. we will be there today, finally! :)
[17:10] <sil2100> mvo: yay, works! Thanks! Did you add the foundations group (or whatever that is) or just me?
[17:10] <sil2100> Since I guess the more the merrier :)
[17:11] <sil2100> mvo: hm, I still don't seem to have full github powers on the branch like on the others
[17:12] <sil2100> (like settings etc.)
[17:13] <mvo> sil2100: the foundations group
[17:13] <mvo> sil2100: aha, let me see
[17:13] <sil2100> (git push worked though)
[17:13] <mvo> sil2100: try now
[17:14] <mvo> sil2100: this failure on trusty is mysterious, even the LP generated debdiff shows no packaging changes
[17:17] <sil2100> mvo: works now, thanks!
[17:17] <sil2100> hmmm
[17:17] <sil2100> mvo: let me take a look at trusty as well
[17:21]  * sil2100 checks his trusty schroot
[17:22] <sil2100> oh, components mismatch maybe? However, this built fine before
[17:23] <sil2100> mvo: so golang-1.6 is in universe while snapd is in main, but the previous version didn't have a problem with that
[17:24] <Chipaca> sil2100: snapd uses -1.10
[17:24] <mvo> Chipaca: that 2.38
[17:24] <Chipaca> ah
[17:24] <Chipaca> oh
[17:24] <Chipaca> uh
[17:24] <Chipaca> eh
[17:24] <mvo> Chipaca: in 2.37.4 we should still be fine .)
[17:24] <mvo> sil2100: yeah, what can we do? demote snapd to universe?
[17:27] <mup> PR pc-amd64-gadget#12 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <Merged by sil2100> <https://github.com/snapcore/pc-amd64-gadget/pull/12>
[17:27] <mup> PR pc-amd64-gadget#13 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <Merged by sil2100> <https://github.com/snapcore/pc-amd64-gadget/pull/13>
[17:28] <mvo> sil2100: I need to run for lunch
[17:28]  * zyga waves from school meeting
[17:30] <mup> PR pc-i386-gadget#8 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <Merged by sil2100> <https://github.com/snapcore/pc-i386-gadget/pull/8>
[17:30] <mup> PR pc-i386-gadget#9 closed: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <Merged by sil2100> <https://github.com/snapcore/pc-i386-gadget/pull/9>
[17:32] <sil2100> mvo: can we actually demote snapd to universe?
[17:32] <sil2100> mvo: anyway, first I'd like someone else confirm that's the problem, let me poke someone
[17:32] <sil2100> vorlon: maybe you have an idea? Is this the problem? ^
[17:33] <sil2100> vorlon: context: snapd in trusty doesn't build at all, dep-waits on packages even though no new dependencies have been added
[17:34] <sil2100> vorlon: I was suspecting a component-mismatch here as golang-1.6 is in universe in trusty, but it was building fine in the past
[17:34]  * sil2100 AFK for a bit
[18:03] <Chipaca> pedronis: I marked #1819427 as invalid, and also marked the forum topic as solved
[18:03] <mup> Bug #1819427: Disco daily install doens't include the snaps <ubiquity (Ubuntu):Invalid by chipaca> <ubiquity (Ubuntu Disco):Invalid by chipaca> <https://launchpad.net/bugs/1819427>
[18:03] <pedronis> thx
[18:07] <vorlon> sil2100: demote snapd to universe> ... no?
[18:15] <cachio> niemeyer, hey, I have created a small PR on spread https://github.com/snapcore/spread/pull/74 to enable travis
[18:16] <mup> PR spread#74: Add .travis.yaml file <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/74>
[18:16] <cachio> it is the initial step
[18:16] <cachio> niemeyer, could you please take a look
[18:16] <cachio> ?
[18:18] <niemeyer> cachio: That doesn't look very useful :)
[18:18] <cachio> niemeyer, I know, it is just to have a .tavis.yaml file
[18:19] <niemeyer> cachio: Right, that's what I'm talking about
[18:19] <cachio> I already have a set of changes to run the tests
[18:19] <kenvandine> zyga: i'm having a layouts problem
[18:19] <cachio> niemeyer, but I need to start running the builds on travis
[18:19] <niemeyer> cachio: Sorry, I really don't get it
[18:19] <kenvandine> zyga: specifically refreshing from a snap without the layout to  a snap using layouts
[18:19] <kenvandine> https://paste.ubuntu.com/p/fVp6Tjd5vb/
[18:19] <niemeyer> cachio: Running "echo" on Travis is not very useful
[18:20] <niemeyer> cachio: What am I missing?
[18:20] <kenvandine> zyga: it seems to only happen if i run the non-layouts revision first
[18:20] <cachio> niemeyer, I need a way to see in github the execution of the change
[18:20] <cachio> niemeyer, currently it is not running nothing
[18:21] <niemeyer> cachio: I consider not running nothing a good thing
[18:21] <cachio> niemeyer, I already created a change #73 on spread and it didnt trigger the tests
[18:21] <mup> PR #73: fix a bug in lightweights that set the wrong type for frameworks found by AllPartBags that were lexicographically greater than the oem part <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/73>
[18:21] <cachio> niemeyer, https://github.com/snapcore/spread/pull/73/files
[18:22] <mup> PR spread#73: Run tests on travis <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/73>
[18:22] <cachio> niemeyer, how should I do to start running on travis?
[18:22] <cachio> do you need to configure that?
[18:23] <niemeyer> cachio: Michael's point in that PR is that your change is huge
[18:23] <cachio> or I could add the unit tests execution as part of the change https://github.com/snapcore/spread/pull/74 if you think it is good idea
[18:23] <mup> PR spread#74: Add .travis.yaml file <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/74>
[18:23] <niemeyer> cachio: We don't want to review that
[18:23] <niemeyer> cachio: Instead, the PR should introduce testing with less boilerplate
[18:23] <niemeyer> cachio: We already have tests in spread
[18:24] <niemeyer> cachio: Running those in Travis would be nice, and hopefully not as complex
[18:24] <niemeyer> cachio: What's the minimum we can do for that?
[18:25] <cachio> niemeyer, ok, I can make a PR to run unit tests
[18:25] <cachio> then another to run spread tests
[18:25] <niemeyer> cachio: We already have tests in there
[18:25] <niemeyer> cachio: And they are not unittests
[18:25] <niemeyer> cachio: They are functional tests
[18:26] <kenvandine> zyga: i've reproduced that with both stable and edge channels of the core snap
[18:26] <cachio> niemeyer, I know, in that case the PR should include to run the spread tests
[18:26] <cachio> niemeyer, just that
[18:26] <cachio> niemeyer, does it make sense?
[18:27] <niemeyer> cachio: Yeah, even just one of those would be enough of a PR
[18:27] <cachio> niemeyer, great
[18:27] <cachio> I'll make that
[18:27] <niemeyer> Thanks!
[18:27] <cachio> yaw
[18:32] <cachio> niemeyer, we are going to need a new key to run the tests on google for the travis spread project
[18:33] <niemeyer> cachio: That's okay.. perhaps first get it working for you, which should work with your key, and once that's happy we can setup something more permanent
[18:35] <cachio> niemeyer, I already have that working
[18:35] <cachio> because I did it as part of the PR 73
[18:35] <mup> PR #73: fix a bug in lightweights that set the wrong type for frameworks found by AllPartBags that were lexicographically greater than the oem part <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/73>
[18:36] <cachio> I need just to get that part and create a new PR
[18:36] <niemeyer> cachio: Okay, so submit that alone so we can integrate first, and then submit the PR that enables that to run on Travis
[18:36] <niemeyer> cachio: and by "that alone" I mean just the changes necessary to make spread tests run on GCE
[18:36] <niemeyer> cachio: So anyone can fire those in their own environment
[18:36] <cachio> niemeyer, great, thanks
[18:37] <cachio> sure
[18:46] <mup> PR snapcraft#2479 closed: store: support registering to a specific store <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2479>
[19:00] <zyga> kenvandine: reproduced which issue sir? The one about base snap?
[19:00] <kenvandine> no
[19:00] <kenvandine> the layouts issue
[19:01] <kenvandine> zyga: https://paste.ubuntu.com/p/fVp6Tjd5vb/
[19:01] <kenvandine> gnome-characters in stable doesn't use layouts and in candidate it does
[19:01] <kenvandine> if i run gnome-characters from stable once
[19:01] <zyga> Let me look
[19:01] <kenvandine> then refresh candidate
[19:01] <kenvandine> it blows up on refresh
[19:02] <kenvandine> but it doesn't blow up if i never run it
[19:02] <zyga> Ahhh
[19:02] <zyga> Can you report that please
[19:02] <kenvandine> all the steps to reproduce it is in the pastebin :)
[19:02] <kenvandine> sure
[19:02] <zyga> And assign it to me
[19:02] <zyga> I will otherwise not track it very well
[19:02] <zyga> Thank you
[19:02] <zyga> I think I know why
[19:09] <kenvandine> zyga: what's your LP id?
[19:10] <kenvandine> LP search is failing me :)
[19:12] <roadmr> kenvandine: https://launchpad.net/~zyga ?
[19:12] <cachio> niemeyer, PR ready https://github.com/snapcore/spread/pull/75
[19:12] <mup> PR spread#75: Make spread tests run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75>
[19:12] <kenvandine> No items matched "zyga".
[19:12] <kenvandine> but you are right
[19:12] <kenvandine> i can't assign a bug to that though
[19:13] <kenvandine> zyga: bug 1820109
[19:13] <mup> Bug #1820109: refresh fails with layouts <snapd:New> <https://launchpad.net/bugs/1820109>
[19:13] <kenvandine> zyga: it won't let me assign it to you
[19:15] <roadmr> hn the snapd project must have funky bug assignment policies
[19:15] <kenvandine> yeah
[19:16] <kenvandine> zyga: i'd mark it as critical if i was allowed... we need to update all the seeded snaps to core18 based so we can seed the new content package at the same time we unseed the old one
[19:16] <kenvandine> so this is going to block that :/
[19:16] <roadmr> kenvandine: apparently it only allows assigning bugs to teams, not specific people
[19:16] <kenvandine> i see other bugs assigned to individuals though
[19:18] <roadmr> kenvandine: it won't let me select individuals (even me), but see at the top of the assignment window, it says "select a team of which you're a member" or somesuch
[19:18] <kenvandine> yeah
[19:18] <kenvandine> saw that
[19:18] <kenvandine> so i can't even assign it to the snappy team :/
[19:19] <roadmr> :(
[20:05] <mup> PR snapd#6401 closed: many: add /v2/model API, `snap remodel` CLI and spread test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6401>
[20:06] <pedronis> kenvandine: I assigned, I don't know if it has a quick/non risky fix, we'll need to see what zyga says
[20:08] <mup> PR snapcraft#2502 opened: meta: fix management of snap/local <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2502>
[20:13] <ogra> hmm, ouch ... core18 misses snapfuse ... so you cant run lxd on top of Ubuntu Core 18 images
[20:14] <ogra> (well, you can, but not install snaps in the container)
[20:14] <ogra> stgraber, pedronis ^^^ is that known ?
[20:49] <jdstrand> roadmr: hi! can you add a pull of r1208 to your queue?
[20:49] <jdstrand> roadmr: it isn't urgent
[20:50] <roadmr> jdstrand: pullity pull coming right up
[20:50] <jdstrand> thank you :)
[20:50] <roadmr> jdstrand: yep, I don't think we can deploy that before next week but it'll get queued
[20:50] <jdstrand> pedronis: fyi, that ^ has the small fix I referred to
[21:21] <Saviq> ackk: hey, sorry for the very late reply... I saw your ping but missed which channel it was on...
[21:22] <Saviq> ackk: that would be https://github.com/CanonicalLtd/multipass/issues/678 - it's fixed now in our master, but we've another issue we're fighting with on edge (https://github.com/CanonicalLtd/multipass/issues/677) so it's best to stick with --beta for a bit
[21:23] <stgraber> go get github.com/snapcore/snapd/i18n/xgettext-go: unzip<EMAIL_ADDRESS>malformed file path "cmd/snap-confine/spread-tests/distros/debian.": trailing dot in path element
[21:24] <stgraber> ^ that's go tip failing to "go get" the snapd repo due to something funky going on with unzip


[05:45] <Noskcaj> Ampelbein, Do you ever plan to upload the latest version of flatnuke? If not, i could try
[12:57] <Rhonda> Laney (or else), could you be convinced to do a wheezy-backport of ubuntu-dev-tools?
[12:58] <Laney> Rhonda: maybe bdrung or tumbleweed
[12:58] <Rhonda> The backport of devscripts breaks ubuntu-dev-scripts < 147~
[12:58] <Laney> tsk
[12:59] <Rhonda> Hmm, no mention for why in the manpage
[12:59] <Rhonda> Erm, changelog
[12:59] <Laney>  * Move add-patch, edit-patch, suspicious-source, what-patch, and wrap-and-sort from ubuntu-dev-tools into devscripts (Closes: #568481).
[12:59] <Laney> ?
[13:00] <Rhonda> That's too old
[13:00] <Rhonda> That was 2.11.0, and wheezy has 2.12.6
[13:00] <Laney> mmm
[13:00] <Rhonda> So that can't be the reason for the breaks < 147~
[13:01] <bdrung> hm, how does it break?
[13:01] <bdrung> is there a breaks in control?
[13:01] <Rhonda> yes
[13:01] <Rhonda> So devscripts from wheezy-backports currently would uninstall ubuntu-dev-tools
[13:03] <bdrung> ah, now i get it.
[13:03] <bdrung> * Convert Python scripts to python3 (Closes: #680313).
[13:03] <bdrung> ubuntu-dev-tools uses devscripts.logger and needs a Python 2 version of it
[13:03] <bdrung> so yes, we need to also backport ubuntu-dev-tools
[13:11] <Rhonda> That could have been more explicit in the changelog. :/
[13:15] <bdrung> Rhonda: the changelog of ubuntu-dev-scripts 0.147 is an indicator
[13:15] <bdrung> but you are right
[14:20] <Laney> bdrung: are you backporting it?
[15:28] <bdrung> Laney: i could, but feel free to do it
[15:29] <Laney> rather not :P
[15:30] <mfisch> dholbach: ping
[15:31] <dholbach> mfisch, in uds hangouts - how can I help?
[15:31] <mfisch> dholbach: yeah sorry, I'll email you later
[15:31] <dholbach> no worries
[19:09] <jtaylor> mh sweet ext4 data=writeback,commit=3600,nobarrier turns cowbuilder on disk almost into cowbuilder on ramdisk :D


[00:33] <MythbuntuGuest30> how can i get mythbuntu to rip dvds
[00:34] <MythbuntuGuest30> and play them
[00:34] <MythbuntuGuest30> I have installed the w32codecs and libdvdcss2 already
[00:35] <MythbuntuGuest30> !help
[00:35] <Zinn> !help For a  complete list of my knowledge visit: http://www.baablogic.net/Zinn.cgi  Other available commands: !status, !about, !bug [bug_number].
[00:38] <MythbuntuGuest30> !help ask how can i get mythbuntu to rip dvds
[00:38] <Zinn> !help ask how can i get mythbuntu to rip dvds For a  complete list of my knowledge visit: http://www.baablogic.net/Zinn.cgi  Other available commands: !status, !about, !bug [bug_number].
[00:38] <MythbuntuGuest30> !status
[00:38] <Zinn> I am alive.
[00:43] <MythbuntuGuest52> Anyone around? i am looking to setup a system where media is streamed from a backend server to a frontend, similar to how mythtv currently does, but i'm not interedted in recording live tv. I'm looking for a server setup where i can upload media files directly to the backend and have them streamed on demand to the frontend using a simple interface, is such thing possible with mythtv? or am I up the wrong tree on this one?
[00:49] <MythbuntuGuest30> yes you can do that with mythtv
[01:03] <MythbuntuGuest30> !ChanServ
[01:03] <Zinn> Sorry I don't know about ChanServ
[01:03] <MythbuntuGuest30> ! rip dvd
[01:03] <Zinn> Sorry I don't know about rip dvd
[01:04] <MythbuntuGuest30> !ask how to rip dvds
[01:04] <Zinn> Sorry I don't know about ask how to rip dvds
[01:04] <MythbuntuGuest30> !ask
[01:04] <Zinn> Please don't ask if anyone is around or if it is alright to ask a question.  Many people check back periodically and may answer your question when they see it.  IRC is not normally an instant fix so check back often for an answer.
[01:05] <MythbuntuGuest30> How can do i get mythbuntu to play dvd's and rip them to the HD? I've alreay installed the w32codecs and libdvdcss2.
[04:03] <hads> You could do that with mythtv but you're probably better off using something else.
[04:41] <abarbaccia> hey all - i botched the database on my mythbuntu ibex install and i want to restore a default one. can i just force a reconfigure of a package to do it?
[04:44] <hads> !database
[04:44] <Zinn> Sorry I don't know about database
[04:44] <hads> !help
[04:44] <Zinn> !help For a  complete list of my knowledge visit: http://www.baablogic.net/Zinn.cgi  Other available commands: !status, !about, !bug [bug_number].
[04:44] <hads> !mysql
[04:44] <Zinn> If you are having problems connecting to your mysql database, you can perform the following to reconfigure it: 1. sudo dpkg-reconfigure mysql-server-5.0 (pay attention to the root password you set, you will need it for the next step) 2. sudo dpkg-reconfigure mythtv-database 3. sudo dpkg-reconfigure mythtv-common
[11:42] <marsje> hi
[11:43] <marsje> I'm interested in building an energy efficient, quite HTPC
[11:43] <marsje> the AMD 780G chipset seems quite nice
[11:44] <marsje> how does it work with Mythbuntu?
[11:44] <marsje> will it use the hardware HD acceleration?
[13:28] <andy_js> Hi. Its it possible to have mythtv start when I boot my computer, without having XFCE running in the background?
[13:30] <MythbuntuGuest30> !dvd
[13:30] <Zinn> Sorry I don't know about dvd
[13:30] <MythbuntuGuest30> !rip
[13:30] <Zinn> Sorry I don't know about rip
[13:30] <MythbuntuGuest30> !play dvd
[13:30] <Zinn> Sorry I don't know about play dvd
[13:31] <MythbuntuGuest30> !play
[13:31] <Zinn> Sorry I don't know about play
[13:31] <andy_js> You need help playing a dvd?
[13:32] <gumpert345> hi I installed diskless-server on my hardy server and then tried to install diskless-server-client but I get a ltsp error: http://pastebin.com/d1f6b88eb its german, Im afraid, but I can try to translate it
[13:34] <gumpert345> and this is the next message I get: http://pastebin.com/d42dbc237 this time in english
[13:35] <gumpert345> !diskless
[13:35] <Zinn> Sorry I don't know about diskless
[14:24] <gumpert345> does someone know a better howto than this one: https://help.ubuntu.com/community/MythTV/Install/Hardy/Diskless it seems to be outdated and doesnt work for me?
[14:31] <rhpot1991> gumpert345: http://www.mythbuntu.org/installation_manual
[14:32] <rhpot1991> !help
[14:32] <Zinn> !help For a  complete list of my knowledge visit: http://www.baablogic.net/Zinn.cgi  Other available commands: !status, !about, !bug [bug_number].
[14:39] <gumpert345> rhpot1991 thanks for the link, but I run a server without xfce, kde or gnome,  and this pdf says Iam supposed to use the mythbuntu control centre, which I dont know how to do without a monitor
[14:42] <gumpert345> is there some way to access it via ssh or http?
[14:50] <rhpot1991> gumpert345: you can do it over ssh
[14:50] <rhpot1991> ssh -X ip
[14:50] <rhpot1991> will forward X apps
[14:54] <gumpert345> ah ok, so all I need to do is: sudo apt-get install myth-backend and sudo apt-get install myth-control-center and connect to it via ssh -X?
[14:56] <rhpot1991> gumpert345: yes, watch the dependencies though make sure X isn't in there
[14:57] <rhpot1991> it is required for the frontend
[14:57] <rhpot1991> might be for MCC, I'd have to check
[14:57] <gumpert345> sry I didnt understand the last part, do you mean I shall check that no X is installed?
[14:58] <rhpot1991> well I take it that you are running a cli server?
[14:58] <rhpot1991> no X interface
[14:58] <gumpert345> yes
[14:59] <rhpot1991> if you do sudo apt-get install -s myth-control-centre it will do a test run, and you can see all the packages that would get installed without actually installing
[14:59] <rhpot1991> just to make sure you don't pick up Xorg in the process
[15:00] <gumpert345> ah ok thx
[15:00] <gumpert345> I found this: mythweb do you think it can do the job too?
[15:01] <rhpot1991> mythweb can do a lot, but not everything MCC can, also mythweb doesn't have error checking in place so you can easily break things if you don't know what values should be in there
[15:02] <gumpert345> ah ok
[15:39] <gumpert345> rhpot 1991 http://pastebin.com/d36c1116 what do you think?
[15:49] <rhpot1991> gumpert345: should be good I think
[15:56] <gumpert345> I connected to the server using ssh -X ip on the mac osx terminal and a X11 window opened but all I can see is another terminal that says: bash-3.2
[15:57] <rhpot1991> gumpert345: I've never done x forwarding to osx sorry
[15:58] <gumpert345> I doubt its a mac problem
[15:58] <gumpert345> maybe its because there is no xserver on hardy?
[15:59] <gumpert345> http://pastebin.com/d1bd29ee2
[16:02] <rhpot1991> looks like it
[16:03] <gumpert345> sudo apt-get install xserver?
[16:03] <rhpot1991> gumpert345: before you do that what exactly are you trying to accomplish here?
[16:04] <rhpot1991> no need loading x on there if you can do it without
[16:05] <gumpert345> i want to run a diskless mythbuntu server on my fileserver so I wont need a HDD for my frontend
[16:10] <gumpert345> Id like to do it without, but if there is no other way. . .
[16:11] <rhpot1991> ah I'm not all that familiar with the diskless, but I'd venture you'd be better using MCC for it
[16:14] <gumpert345> as far as I can see, I need something like an xserver for mcc, right`?
[17:01] <MythbuntuGuest58> does anyone know of support for the JMicron JMB381 Firewire chip on the MSI P6NGM-FIH motherboard?  I havent been able to find information on it but mythbuntu 8.1 does at least recognize it but shows no Nodes under plugreport.
[17:03] <SgtP> <-- formerly MythbuntuGues58
[17:20] <superm1> SgtP, i'm doubtful you'll be finding an answer to your question unfortunately
[17:20] <superm1> at least in here
[17:20] <superm1> i'm assuming you have a device plugged in when you are looking for nodes on plugreport?
[17:23] <SgtP> Yes, I have a QIP 7100 (Fios STB) which isnt showing up so I took an old Firewire Ipod and tried that as well with no luck.
[17:24] <SgtP> The ipod did power up and act like it was connecting but still have nothing under plug report.
[17:25] <superm1> your best bet is to try to boot off of a 9.04 alpha disk
[17:25] <superm1> and see if it's more functional there
[17:25] <superm1> if not, you can at least try to get a more accurate bug report together
[17:27] <SgtP> Ok.. that sounds like a good starting point.. After that I may just pull an old card out of a desktop and try and use that..
[17:29] <superm1> well that or if it works with 9.04 stick with 9.04 :)
[17:30] <rhpot1991> you may have issues with firewire being active on that box as well
[17:31] <rhpot1991> I didn't think fios played nice with firewire, I'd be very interested if it did though :)
[17:31] <SgtP> yeah just planned to wait for the release.. Since this is something new trying to make it stable as I can for the Wife factor.. :)
[17:31] <tgm4883> ah superm1 knows all about that.  Jackie doesn't like it when the mythbox aint working ;)
[17:32] <rhpot1991> haha
[17:32] <rhpot1991> IIRC Jackie is the cause of it nor working sometimes, with wire eating and all
[17:32] <superm1> haha
[17:32] <SgtP> well there are at least 2 ppl who got it working (For channel change only).
[17:32] <franqus> hi there
[17:32] <superm1> !hi | franqus
[17:32] <Zinn> franqus: Hi $nick, how are you?  Something we can help you with today?
[17:33] <franqus> i got trouble setting up my lirc with imon pad remote control
[17:33] <SgtP> http://rocketmonkeys.com/index.php  <-- Blog about using the FIOS box.  Has his ch6100 script up there now too..
[17:33] <franqus> is there a  lirc chan on irc?
[17:34] <superm1> franqus, #lirc i thinks
[17:34] <franqus> :D
[17:34] <franqus> thx
[17:34] <rhpot1991> SgtP: that is one bright site
[17:35] <MythbuntuGuest16> whoops..
[17:35] <SgtP> yeah its bright.. but has some good info on the Fios setup.
[17:36] <rhpot1991> thats a shame its channel changing only
[17:37] <franqus> any lirc-users in here using soundgraph's imon remote control?
[17:46] <SgtP> yeah I would like to get the video out of it but at least I can get something.  I have the HDHomerun for the OTA stuff.  so that just leaves Discovery channel as far as I care.. :)
[17:48] <superm1> gee wouldn't it be nice if those tuning boxes you got from Verizon for FIOS and AT&T for uverse would spit out QAM streams
[17:48] <superm1> imagine how this world would be :)
[17:48] <Batshua> Does anyone know if the Hauppauge 1192 HDTV Tuner/Video Recorder is sufficient for my needs?
[17:48] <Batshua> The 1212 was suggested, but the 1192 is less expensive.
[17:51] <SgtP> Superml:  Yeah would be nice.. Has anyone tried the whole FCC useful firewire port thing?  I just read about it yesterday.  So far I have been happyy with the tech support at Verizon but who knows how far that would go.
[17:52] <superm1> SgtP, at best you might get ota channels over firewire if you tried to do it with verizon i thinks
[17:54] <SgtP> Yeah might give it a try once I get firewire working on the box at least.  Ill stay in contact with the guy at rocketmonkey and see if he has tried as well..
[17:55] <SgtP> Batshua: Dont know if the 1192 would work but they are completly different animals. One is HD the other isnt.  So it depends what you are trying to accomplish I would think.
[17:59] <SgtP> I take that back a bit I guess the 1192 has a tuner etc.  The 1212 doesnt have a tuner etc it will just take the raw component output into H.264 . So you would have to use a STB for tuning.
[17:59] <Batshua> It looked like they were both HD.
[17:59] <Batshua> This is why I asked.
[18:01] <SgtP> well someone at newegg says it working in Myth/linux well..
[18:01] <SgtP> what are you trying to connect to the tuner?
[18:38] <rhpot1991> SgtP: FCC only requires OTA channels I believe
[18:39] <rhpot1991> some people get lucky and can get others


[01:05] <Mundus2018> What flags would I use with sort to sort this by largest size to smallest? http://termbin.com/ahcu
[01:07] <crazyadm> how do i make a service to start at bootup
[01:10] <crazyadm> anyone know
[01:11] <pmatulis> Mundus2018, change the unit from human readable to kb, then pipe it through the 'sort' command
[01:14] <pmatulis> crazyadm, what release of ubuntu are you using?
[01:14] <Mundus2018> ok
[01:16] <patdk-lap> du -s | sort -nr
[01:20] <Mundus2018> thanks man
[01:32] <crazyadm> pmatulis: Linux ubuntuacer 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:41:41 UTC 2016 i686 i686 i686 GNU/Linux
[01:34] <crazyadm> is there general solution to make services start at bootup
[01:41] <crazyadm> pmatulis?
[02:02] <pmatulis> crazyadm, use the init system that your OS is using. you have kernel 4.4. that sounds like xenial. so systemd
[02:06] <crazyadm> yes what's the command?
[02:06] <crazyadm> turn on and off services at bootup
[02:06] <crazyadm> i don't need details
[02:06] <crazyadm> i don't really care about details, you know
[02:07] <crazyadm> some use init.d some systemd, some systemctl
[02:07] <crazyadm> some rc.d
[02:07] <crazyadm> means nothing to me
[02:18] <pmatulis> i don't know offhand. i would need to google for it. so i won't google for you crazyadm
[02:20] <crazyadm> ok thanks
[02:21] <arrrghhh> hey all.  I had /var mounted on a separate disk, and upon reboot it seems this disk is now not mounting.  I managed to comment out the line in fstab and get the server to boot, but of course basically every application is broken... is it possible to fix this, or is a reinstall my only recourse?
[04:21] <tikund> wtf... I just updated the kernel on my server and it remapped/changed every hard drive dev name
[04:21] <tikund> thankfully I have LOM configured
[04:27] <tikun> ls
[04:44] <tarpman> tikun: that's why it's so strongly recommended to configure everything with uuids these days instead of device paths ... that can happen
[04:45] <tikun> yeah..... that is very true.
[05:10] <krupke> tikun: do you have an LSI hba in your server?
[05:11] <tikun> hp smart array p410
[05:12] <tikun> and an external drive connected via usb, tacky I know but eh. fits the rest of the data center with MyCloud's all over the place.
[05:13] <krupke> does the controller load mpt3sas module?
[05:14] <tikun> it does not
[05:17] <krupke> i upgraded to 4.4.0 kernel and same thing happened.
[05:17] <tikun> looks like it is using hpsa
[05:17] <tikun> really?
[05:17] <tikun> oh wait
[05:17] <tikun> a second
[05:17] <tikun> even the uuid changed!
[05:18] <tikun> even >A< uuid changed
[05:18] <tikun> root partition would have been sdb from the install, but it became sda
[05:18] <tikun> but it is listed in the fstab as a uuid
[05:18] <tikun> so yeah, that's odd. lol
[05:21] <krupke> fstab maps uuid to mountpoint so dev name becomes irrelevant
[05:21] <krupke> still, it's annoying
[05:23] <tikun> it took me a bit to figure out what was even going on, apache wasn't running at first.. I thought it was some networking issue at first, then noticed it couldn't load log paths/www_root paths, then my backup drive was mounted as /, my main raid volume was mounted as my backup drive, it was all messed up
[07:21] <cpaelzer> jamespag`: fyi I found a way to do the l2fwd test in dpdk without killing the network
[07:21] <cpaelzer> jamespag`: I now spawn two virtual non connected networks for a KVM guest and run the test in there connecting the two virtual networks
[07:22] <cpaelzer> test works fine as it was, and no more kills our network by running "too good" doing L2 forwarding from/to the same network
[15:51] <lunaphyte> i'm trying to upgrade from 15.04.  for some reason, do-release-upgrade finds 16.04 [xenial] instead of 15.10 [wily], and then refuses to upgrade.  i don't understand why it's not finding 15.10.  how can i troubleshoot why this is happening and/or how can i tell the system to upgrade to 15.10 instead 16.04?
[15:51] <lunaphyte> http://dpaste.com/1ZJCXR0.txt
[15:51] <nacc> !eol | lunaphyte
[15:51] <nacc> lunaphyte: that's probably why, as 15.10 is also eol
[15:52] <lunaphyte> this must be some new behavior?
[15:52] <nacc> lunaphyte: only update to 15.10 if you intend to immediately update to 16.04
[15:52] <lunaphyte> yes, that's the plan
[15:52] <ogra_> not new, no
[15:52] <nacc> lunaphyte: i don't think it's new behavior at all
[15:52] <nacc> lunaphyte: you are on an eol release trying to upgrade to an eol release
[15:53] <nacc> lunaphyte: the release tools only allow upgrading to released versions
[15:53] <lunaphyte> it sure is.  i've upgraded countless computers over the years many versions behind, by iterating t hrough the upgrade to each successive version
[15:54] <nacc> lunaphyte: possibly using the eol upgrade path?
[15:54] <nacc> lunaphyte: that ubottu provided a link to
[15:54] <nacc> lunaphyte: why are you letting countless computers fall out of support?
[15:56] <lunaphyte> support for what?
[15:59] <lunaphyte> when i point sources.list to old-releases, apt-get update returns a bunch of 404/not found errors
[16:00] <lunaphyte> presumably this is because vivid is not currently provided for at the old-releases url.
[16:03] <lunaphyte> and do-release-upgrade still tries to upgrade to xenial
[16:04] <lunaphyte> i guess it's possible this is a timing thing, and i've just coincidentally never run into it until now
[16:05] <lunaphyte> but that would be a little surprising
[16:08] <tarpman> lunaphyte: could be this is the first time you've been bitten by the support duration dropping from 18 months to 9
[16:08] <lunaphyte> i don't get it though
[16:08] <lunaphyte> so 15.04 is an old release - that's fine.
[16:08] <lunaphyte> then why are there no package repos at old-releases?
[16:09] <lunaphyte> yet they are still listed, and still fully functional at us.archive.ubuntu.com - so which is it, you know?
[16:10] <tarpman> moving them to old-releases is a manual thing. I guess no one got around to it yet
[16:10] <tarpman> no idea about why your do-release-upgrade isn't cooperating though, sorry :|
[16:12] <lunaphyte> it's all good.  i'll see if anyone in #ubuntu-release has any thoughts
[17:01] <hdon> hi all :) does xenial put mysqld's lock file somewhere weird? or does it tell mysqld to use a specific configuration file? i can't start mysqld from the command-line the way i normally would (say, to reset root password)
[17:23] <Braven> I have a multihone server. I only want one of the IF to register in DNS. Is there a way to prevent a IF from registering


[00:17] <mup> PR snapd#2404 opened: interfaces/builtin: updates to dcdbas-control interface <Created by tonyespy> <https://github.com/snapcore/snapd/pull/2404>
[10:40] <Guest86497> Hi I just install the handbrake snap package, but Handbrake doesn't have access to my DVD drive!
[11:45] <mup> Bug #1647139 opened: CalledProcessError: Command '['/usr/bin/sudo', '/usr/sbin/chroot', '/home/buildd/build-SNAPBUILD-12520/chroot-autobuild', 'linux64', '/bin/sh', '-c', 'cd /build/qucs-spice && env LANG=C.UTF-8 https_proxy=http://snap-proxy.launchpad.net:3128
[11:45] <mup> http_proxy=http://snap-proxy.launchpad.net:3128 SNAPCRAFT_LOCAL_SOURCES=1 snapcraft pull']' returned non-zero exit status 1 <build> <lp> <Snappy:New> <https://launchpad.net/bugs/1647139>
[12:40] <TMiguelT> Is there a command to list the files in a .snap?
[12:49] <bartbes> unsquashfs -l
[12:52] <TMiguelT> Ooh nice, thanks!
[13:09] <TMiguelT> If I have an `organise: {usr/bin: bin}` in my snapcraft file, will it physically move all the binaries from usr/bin to bin? How come that doesn't seem to work?
[13:36] <TMiguelT> Actually it seems that that configuration moves some of the files but not all.
[13:37] <TMiguelT> I wonder how that is
[16:14] <mup> Bug #1647169 opened: Oneshot services with start/stop commands need RemainAfterExit=yes <Snappy:New> <https://launchpad.net/bugs/1647169>
[19:27] <Zap123> Hello, I'm trying to package as a snap my favourite music player https://github.com/gnumdk/lollypop for a while, but I can't manage to make it work because the python directory during ./configure is set to a path different than the one in the snap container. Can someone have a look at it? http://pastebin.com/GX4hZwfM The author made a flatpack but they doesn't seem similar to snap packages to gain any insight
[19:45] <mup> Bug #1647200 opened: xdg-open does not open link when java is staged <snap> <xdg-open> <yakkety> <Snappy:New> <https://launchpad.net/bugs/1647200>
[19:46] <ZenHarbinger> Yesterday I asked about xdg-open and how it wasn't working for me.  I located a couple of issues where it doesn't work and submitted a bug.
[19:46] <ZenHarbinger> https://bugs.launchpad.net/snappy/+bug/1647200
[19:46] <mup> Bug #1647200: xdg-open does not open link when java is staged <snap> <xdg-open> <yakkety> <Snappy:New> <https://launchpad.net/bugs/1647200>


[06:04] <valorie> signing off for a couple of weeks -- I will have telegram as well as signal
 OK
 https://lists.ubuntu.com/archives/kubuntu-devel/2018-July/011683.html
 On the plane to Amsterdam!
 @acheronuk awwww, no reply yet


[02:46] <guiverc> Well done kc2bez in https://www.youtube.com/watch?v=WH-wCfo8R5c  (Community Office hours 10/June/2021) & way to represent :) (see Lenny t-shirt @ 4:33)
[02:48] <guiverc> Channel op (teward), I think the topic should include/mention Lubuntu Support ...  it used to be "Topic for #lubuntu is: Lubuntu Support | About: https://lubuntu.me | Docs: https://manual.lubuntu.me | Lubuntu 21.04 released! https://lubuntu.me/hirsute-released/ | Offtopic: #lubuntu-offtopic | Contribute: #lubuntu-devel | Español: #lubuntu-es | Mailing list: https://lists.ubuntu.com/lubuntu-users | Telegram: https://telegram.lubuntu.me/support"
[12:15] <Jamiro> hi all
[22:49] <Sopitas72> hi everyone!
[22:50] <Sopitas72> im trying to install lubuntu in an old pc I had that already has windows xp on it. Since its discontinued id like to install this in order to make it usable again
[22:50] <Sopitas72> im having trouble figuring out what version of the software I need
[22:51] <Sopitas72> and if it is possible to make it work again or not
[22:54] <guiverc> Sopitas72, https://manual.lubuntu.me/stable/1/Installing_lubuntu.html is the manual section for installing Lubuntu.   (stable in the URL implies latest release being 21.04.  If you use LTS just change 'stable' to say LTS)
[22:55] <guiverc> The choice of which release is up to you.   I prefer the latest (Lubuntu 21.04 or 2021-April release)...  but that also means you need to release-upgrade every 6-9 months which many don't like doing, thus prefer the LTS release; latest LTS is Lubuntu 20.04 (ie. 2020-April release)
[22:55] <Sopitas72> oh, remember im talking about a really old pc
[22:55] <guiverc> 'old' is vague so I don't know what to do with that... I'm on a 2009 dell & don't consider it old personally as it still runs
[22:56] <Sopitas72> oh and it supports 64bits?
[22:56] <guiverc> I used boxes as old as 2003 in QA-testing Lubuntu in the last 18 months... but 'old' means how old?
[22:57] <guiverc> boxes as old as from 2000 are amd64 (high-end enterprise geared boxes are)...  cheap consumer grade 32-bit were made into 2011; but amd64 exists from 2000 onwards
[22:58] <kc2bez> Sopitas72: maybe just let us know what your pc has for a processor and RAM and we can go from there.
[22:59] <Sopitas72> its an acer aspire 3690 series model no bl50
[22:59] <Sopitas72> it currently has no os since the owner erased it
[23:01] <kc2bez> That might be an issue, a quick websearch show that to have a 32bit processor.
[23:01] <guiverc> Celeron is cheap/consumer grade; I don't know your cpu but I see https://ark.intel.com/content/www/us/en/ark/products/27145/intel-celeron-m-processor-370-1m-cache-1-50-ghz-400-mhz-fsb.html (32-bit only) for one model you mention (there were 3 cpus available)
[23:02] <guiverc> the last Lubuntu that runs on x86/i386 (32-bit) is Lubuntu 18.04 which we don't support any longer.. it had 3 years of support ending 2021-April (3 years from release 2018-April).   Some packages are still security-upgraded
[23:04] <guiverc> Our download page is https://lubuntu.me/downloads/ which has a 'graphic' showing support; 18.04 is off our support you'll note, but you can download it from https://cdimage.ubuntu.com/lubuntu/releases/18.04/release/ but note as we dont' support it, we won't help you with it if you decide to use it.
[23:04] <Sopitas72> what about a different OS?
[23:05] <guiverc> We support Lubuntu
[23:05] <Sopitas72> someone recommended me debian lxqt
[23:05] <Sopitas72> oh right
[23:05] <Sopitas72> my bad
[23:06] <guiverc> I'll say that I Lubuntu 18.04 LTS performed better on one 2003 HP I tested with than Debian Buster (10) with LXDE  (I test Debian too regularly)
[23:07] <guiverc> on most boxes the difference was minor, but on 1 really lower powered device Lubuntu outperformed Debian  (it was a celeron; only celeron I tested with)
[23:08] <guiverc> Debian has support though, though Debian LTS is only certain packages just like Lubuntu 18.04 LTS now is...  Your choice
[23:10] <Sopitas72> ive already tried installing the lubuntu 18.
[23:10] <Sopitas72> 04 and had some issues
[23:10] <Sopitas72> but just now I realised I was installing the alternate version
[23:11] <Sopitas72> so im going to give it a try with the desktop version
[23:11] <guiverc> the alternate ISO was for boxes with ~700MB of ram or less; was NOT an ideal installer unless you had to use it
[23:12] <Sopitas72> it would regularly state that my cd-room was corrupted even thou i was installing it with an usb bootable
[23:13] <guiverc> the installation media is called CD regardless of what you write it to, meaning your ISO was corrupted (did you verify it before writing to media) or your write failed (did you verify it?)
[23:13] <Sopitas72> oh I didnt know I had to verify it
[23:13] <Sopitas72> how do i do that?
[23:14] <guiverc> the Lubuntu manual pages provide some details of how to verify, but links for 18.04 will be https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify-ubuntu#0 and https://help.ubuntu.com/community/Installation/CDIntegrityCheck  (the Lubuntu manual is easier but relates to later releases that verify media differently)
[23:14] <guiverc> the Lubuntu manual maybe easier for ISO validation though
[23:19] <guiverc> key to verify ISO is the download link I provided has two methods, SHA256SUMS file which contains filename & checksum.. You verify the (sha356) checksum of your download ISO matches the one in that file.. other method has a command do it for you (.gpg file in link); refer manual links I provided with instructions (which mention Ubuntu, Windows & OSX)
[23:43] <Sopitas72> If I download the torrent of the lubuntu 18.04 desktop i dont have to verify it. right?
[23:44] <kc2bez> The torrent should take care of the verification of the download.
[23:46] <kc2bez> I'd probably still look at the CD integrity check to make sure it was written to the USB correctly.
[23:46] <kc2bez> (That is the second link guiverc gave above)
[23:49] <guiverc> https://help.ubuntu.com/community/Installation/CDIntegrityCheck
[23:49] <kc2bez> Yup, that one.
[23:49]  * guiverc gave many links..  as he is prone to do..