[01:11] <ijohnson> sdhd-sascha: that's expected since if you copy cmd_sign.go to cmd_foo.go, then you're really just adding a `snap foo` command rather than a new command like `foo bar`
[01:12] <ijohnson> sdhd-sascha: as for what if you misspell something that's what code review is for :-)
[06:16] <mborzecki> morning
[06:26] <mborzecki> mvo: hey
[06:27] <mvo> mborzecki: good morning!
[07:09] <zyga> good morning!
[07:10] <mvo> zyga: good morning
[07:10] <zyga> just finishing my morning sandwich here
[07:10] <zyga> how are you guys?
[07:10] <zyga> I spent most of yesterday afternoon debugging issues related to gid dropping
[07:10] <zyga> (so snap-confine can stop being setgid root)
[07:10] <zyga> found a few things after sorting out the initial wave of mkdir problems
[07:11] <zyga> the spread test that finds wrong permissions on directories and files was invaluable
[07:11] <mvo> zyga: nice
[07:11] <zyga> one issue still remains, in snap-update-ns, it also creates some files
[07:11] <zyga> oh well :)
[07:11] <zyga> but today I should get through all of that
[07:11] <mvo> zyga: cool! I'm cleaning up boring spread tests :)
[07:11] <zyga> great
[07:12] <zyga> updating them to current standards?
[07:14] <mvo> zyga: nah, just updating the uc20 test so that it gets pass the review feedback :)
[07:15] <zyga> I see :)
[07:15] <zyga> well, not anywhere less noble :D
[07:19] <sdhd-sascha> good morning
[07:22] <zyga> hey sdhd-sascha, how are you doing?
[07:27] <mborzecki> zyga: 'standards'?
[07:27] <zyga> mborzecki: some tests are really quaint
[07:28] <zyga> the older the more likely you would rewrite it just after looking at it
[07:28] <mborzecki> hah i can imagine
[07:45] <sdhd-sascha> zyga: i'm fine. thank you :-) Hope you, too
[07:47] <mborzecki> something not right with apparmor spec in the desktop interface
[07:47] <mborzecki> Jan 08 07:35:17 jan080727-593014 dbus-daemon[18726]: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/org/freedesktop/portal/desktop" interface="org.freedesktop.portal.OpenURI" member="OpenURI" mask="send" name="org.freedesktop.portal.Desktop" pid=18835 label="snap.test-snapd-desktop.cmd"
[07:48] <zyga> mborzecki: did you change anything or can I just look at master?
[07:48] <zyga> mborzecki: (to look at the rules)
[07:48] <mborzecki> zyga: master is fine
[07:49] <zyga> huh
[07:49] <zyga> so
[07:50] <mborzecki> zyga: i mean looking at the code in master is fine, not that it works on master ;) the relevant bit https://github.com/snapcore/snapd/blob/master/interfaces/builtin/desktop.go#L189-L194
[07:50] <zyga> I wonder if this works at all
[07:50] <zyga> notice that we don't say member=...
[07:50] <zyga> maybe that means member=""
[07:50] <zyga> try adding that
[07:50] <zyga> member=OpenURI
[07:50] <zyga> and if this fixes it let's look at what else needs to be there
[07:50] <zyga> mborzecki: also check the confinement on the portal
[07:50] <zyga> maybe, by chance, it has a non-snap apparmor label
[07:51] <mborzecki> zyga: portal didn't even start, the request got blocked earlier
[07:51] <zyga> mborzecki: can you check that the relevant rule is really there in the apparmor profile?
[07:52] <mborzecki> zyga: unfortunately the rule is in the profile :/
[07:53] <zyga> hmm
[07:53] <zyga> so
[07:53] <zyga> I wonder if this is this:
[07:53] <zyga>     path=/org/freedesktop/portal/{desktop,documents}{,/**}
[07:54] <zyga> this can expand to path=/org/freedesktop/portal/desktop/**
[07:54] <mborzecki> zyga: as i udnersdtand, not specifying a member means to allow all members of the interface
[07:54] <zyga> what if that doesn't match /org/freedesktop/portal/desktop
[07:54] <zyga> mborzecki: try changing that regexp
[07:55] <zyga> mborzecki: to say path=...{,/,/**}
[07:55] <zyga> though perhaps I'm wrong
[07:55] <zyga> because it would probably match the plain expansion
[07:55] <zyga> without /**
[07:56] <mborzecki> hmm we have other spread tests for portals too and those are passing afaik, wonder what makes this one special
[07:56] <zyga> mborzecki: are you testing interactively or is there a spread test?
[07:57] <zyga> mborzecki: ha
[07:57] <zyga> mborzecki: one more idea
[07:57] <zyga> is this really true?
[07:57] <zyga> interface="org.freedesktop.portal.OpenURI"
[07:57] <mborzecki> zyga: spread test for snapctl user-open going to a desktop-portal rather than snap userd
[07:57] <zyga> is the interface really interface="org.freedesktop.portal.OpenURI"
[07:57] <zyga> or is OpenURI the method now (member)
[07:57] <zyga> if so the expression won't cover it
[07:57] <zyga> it requires portal.*
[07:58] <mborzecki> zyga: we have interface=org.freedesktop.portal.*
[07:58] <zyga> right
[07:58] <zyga> but what if the audit message is not really what it seems
[07:58] <zyga> I would say that the interface is org.freedesktop.portal - full stop there
[07:58] <zyga> and the member is OpenURI
[07:58] <zyga> see what I mean?
[07:59] <zyga> interface="org.freedesktop.portal.OpenURI"
[07:59] <zyga> er
[07:59] <zyga> https://www.irccloud.com/pastebin/As3p4zI1/
[08:00] <mborzecki> Jan 08 07:58:31 jan080727-593014 dbus-daemon[18726]: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/org/freedesktop/portal/desktop" interface="org.freedesktop.portal.OpenURI" member="OpenFile" mask="send" name="org.freedesktop.portal.Desktop" pid=19338 label="snap.test-snapd-desktop.cmd"
[08:00] <zyga> try this
[08:00] <mborzecki> opening a file gets blocked too :/
[08:00] <zyga> is this on arch?
[08:02] <mborzecki> 19.10
[08:04] <jamesh> zyga: there are multiple interfaces under org.freedesktop.portal
[08:04] <zyga> jamesh: hey :-)
[08:04] <zyga> jamesh: do you know if the OpenURI method is on the interface called OpenURI
[08:04] <jamesh> zyga: yes.  It is an OpenURI method on the o.f.p.OpenURI interface
[08:04] <zyga> aha
[08:05] <zyga> in that case I have no idea why there is a denial
[08:06] <pstolowski> mornings. i need to run an errand, will start for real a bit later (in ~1h)
[08:06] <zyga> good morning Pawel
[08:08] <mup> PR core-build#58 opened: initramfs: add neccessary modules for rockchip emmc and sdcard <Created by JeffyCN> <https://github.com/snapcore/core-build/pull/58>
[08:09] <jamesh> mborzecki: one idea: does it work if you manually start xdg-desktop-portal from outside of confinement first?
[08:09] <jamesh> I'm wondering if this is a "missing AssumedAppArmorLabel" problem
[08:10] <zyga> mmmm
[08:10] <zyga> good hunch
[08:11] <mborzecki> jamesh: good catch, yeah, it's different now, not getting blocked
[08:11] <zyga> ha
[08:11] <zyga> I wonder if we didn't notice that before
[08:11] <zyga> because snap run activates one of the portals on startup
[08:11] <zyga> so it would be activated by an unconfined program
[08:11] <jamesh> I am surprised we aren't hitting that denial in the other desktop-portal-* tests
[08:12] <jamesh> I don't see anything that would start it before hand
[08:12] <mborzecki> jamesh: not entirely sure, but test-snapd-portal-client activated the portal, but doing the same via xdg-open gets blocked
[08:14] <jamesh> mborzecki: the problem is that we don't know the AppArmor label xdg-desktop-portal will run with prior to it starting.  So the AppArmor rule allowing communication with peer=(label=unconfined) doesn't match
[08:15] <jamesh> mborzecki: are the interface plugs of test-snapd-portal-client different to whatever snap you're using to call xdg-open?
[08:16] <mborzecki> jdstrand: nope, they're the same, only desktop plug
[08:16] <mborzecki> jamesh: ^^
[08:17] <jamesh> mborzecki: is there any difference in the order of operations in preparing the test?
[08:19] <zyga> mborzecki: which other portal test passes?
[08:19] <jamesh> zyga: tests/main/desktop-portal-*
[08:19] <zyga> https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_run.go#L691
[08:20] <mborzecki> zyga: that's document portal
[08:20] <zyga> those tests are interesting
[08:20] <zyga> they set up fake portals up front
[08:20] <zyga> so the portal is never activated
[08:20]  * zyga checks to be sure
[08:21] <zyga> I take that back
[08:21] <zyga> the portal is fake
[08:21] <jamesh> if xdg-document-portal causes xdg-desktop-portal to start, then we wouldn't hit the activation problem
[08:21] <zyga> but seems to be activated
[08:21] <jamesh> hmm.  If portalsUnavailableFile has leaked from a previous test using the snap in mborzecki's test, then we might not try to start the document portal
[08:21] <zyga> where is that file stored?
[08:22] <jamesh> nothing outside of the desktop-portal-* tests use test-snapd-portal-client
[08:22] <jamesh> it would be $XDG_RUNTIME_DIR/snap.$SNAP_NAME/.portals-unavailable
[08:22] <zyga> I doubt we clean that up
[08:22] <zyga> perhaps we ought to
[08:22] <jamesh> and that would be XDG_RUNTIME_DIR for  uid 1000
[08:23] <mborzecki> jamesh: don't think it's the cause, i stop the deskto portal, then run test-snapd-portal-client open-uri and it gets activated, but doing the same with test-snapd-desktop.cmd xdg-oopen gets blocked
[08:23] <jamesh> uid 1234, even
[08:23] <mup> PR snapd#7943 closed: tests: add core20 tests <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7943>
[08:23] <sdhd-sascha> zyga: hey, what are you testing. And how can i reproduce it? Seems to be interresting for wayland-server snaps too
[08:24] <jamesh> mborzecki: does /run/user/1234/snap.test-snapd-desktop/.portals-unavailable exist?
[08:24] <zyga> sdhd-sascha: it's mborzecki, not me
[08:24] <zyga> sdhd-sascha: xdg portals and some apparmor interactions
[08:24] <sdhd-sascha> i see, is `test-snapd-desktop` in the store?
[08:25] <sdhd-sascha> or, in the tests?
[08:25] <mborzecki> jamesh: nope
[08:25] <zyga> sdhd-sascha: most of the snaps are in the snapd repo
[08:25] <jamesh> zyga: also: the tests are running against the real xdg-desktop-portal service: they're just faking the UI service that the snap doesn't communicate with
[08:25] <zyga> and only some are in the store, usually if they 1) require compilation 2) require being from the store
[08:25] <zyga> jamesh: I see
[08:44] <sdhd-sascha> Can i ask, if we could merge this #7927 ?
[08:44] <mup> PR #7927: interfaces: x11 allow apparmor on classic <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7927>
[08:50] <pstolowski> re
[09:00] <zyga> aha
[09:00] <zyga> I know what fails now
[09:00] <zyga> man
[09:00] <zyga> such a complex sooup
[09:00] <zyga> soup
[09:04] <mborzecki> jamesh: so it looks to me that the python dbus client actually starts the service https://paste.ubuntu.com/p/42ZWnBHwxN/
[09:08] <mborzecki> jamesh: looking at apparmor profile, sending org.freedesktop.DBus.StartServiceByName is allowed via included dbus-session-strict abstraction
[09:10] <jamesh> mborzecki: interesting.  That kind of makes the whole AssumedAppArmorLabel thing a bit pointless if you can arbitrarily start services anyway
[09:19] <mborzecki> jamesh: i've updated #7963, the spread test will fail atm until we figure out what's wrong
[09:19] <mup> PR #7963: xdgopenproxy: forward requests to the desktop portal <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7963>
[09:19] <jamesh> cool.  I'll have a look
[09:30] <zyga> brb
[09:42] <zyga> re
[09:43] <zyga> sdhd-sascha: it needs to be reviewed by jamie
[09:43] <zyga> and after xmas break we have a larger backlog of things to catch up with
[09:43] <zyga> expect maybe mid next week
[09:43] <zyga> perhaps earlier but I cannot speak for jamie's timetable
[09:44] <sdhd-sascha> zyga: it's not urgent. just saw the many PRs and thought this one, could be simple
[09:44] <zyga> sdhd-sascha: anything involving interfaces is tricky and needs to have a review from jamie
[09:45] <sdhd-sascha> ok
[09:50] <mvo> 7953 needs a second review (and is pretty trivial now)
[09:51] <zyga> let me look quicky
[09:51] <zyga> I resolved my blocker and now need to just code the solution
[09:51] <zyga> so good time to switch gears for a second
[09:52] <zyga> mvo: is that the right number? it has two +1s already
[09:53] <zyga> mvo: the commit and service name don't match
[09:53] <zyga> mvo: personally I prefer the shorter name (snapd.spread-tweaks.service)
[09:53] <zyga> mvo: but I think it's fine to just change the commit message to talk about snapd.spread-tests-run-mode-tweaks.service
[09:54] <zyga> mvo: I hope this makes sense
[09:54] <mvo> zyga: indeed, nice catch
[09:54] <mvo> zyga: thanks, I overlooked it had a second +1 already, silly me
[10:20] <mup> PR snapd#7962 closed: tests: cherry-pick fixes for  snap-set-core-config/ubuntu-core-config-defaults-once <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7962>
[11:05] <mborzecki> interesting but unrelated to 7953 https://paste.ubuntu.com/p/XG8tpZcG3s/
[11:13] <zyga> mborzecki: I saw that a number of times
[11:13] <zyga> at random
[11:13] <zyga> feels like something is racy
[11:26] <zyga> break
[11:34] <mup> PR core20#19 opened: static: add /etc/environment to writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/19>
[11:37] <mborzecki> cmatsuoka: hi, there were some conflicts in https://github.com/snapcore/snapd/pull/7958 i've merged master and pushed, can you double check it looks ok?
[11:37] <mup> PR #7958: snap-bootstrap: refactor partition creation <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7958>
[11:38] <cmatsuoka> mborzecki: thanks, checking...
[11:39] <mvo> ijohnson: hey, you asked about docker-smoke failing on uc20 the other day - here is the full log https://paste.ubuntu.com/p/Z2JStRP6sw/
[11:39]  * zyga takes the dog out
[11:39] <zyga> ttyl
[11:41] <cmatsuoka> mborzecki: it's good, thanks for resolving the conflict
[11:42] <mborzecki> cmatsuoka: cool, hope the travis job will be green :)
[11:53] <mup> PR snapd#7953 closed: tests: use new snapd.spread-tests-run-mode-tweaks.service unit <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7953>
[12:06] <zyga> back
[12:35] <mup> PR snapd#7966 opened: tests: first core20 test fixes <Created by mvo5> <https://github.com/snapcore/snapd/pull/7966>
[12:35] <cachio> Saviq, hey
[12:36] <cachio> I am trying to create some snaps with base: core20
[12:36] <cachio> and I am getting this error related to multipass
[12:36] <cachio> launch failed: Unable to find an image matching "core20"
[12:36] <Saviq> cachio: there wasn't a build environment for them last year ;)
[12:36] <cachio> any idea about when that image will be published or if is there any workaround for that?
[12:37] <cachio> ll
[12:37] <cachio> Saviq, any idea when it should be ready?
[12:38] <Saviq> sergiusens: got any pointers for cachio ^? Is there an image yet that we could hook up to core20 builds?
[12:39] <Saviq> cachio: you could try launching daily:20.04 named snapcraft-<yourproject>, but there's some setup you might need
[12:39] <Saviq> That, or upgrade the one snapcraft launches for you
[12:39] <cachio> Saviq, ok, I'll try that, thanks!!
[12:40] <mborzecki> cachio: hi, do we have regular updates of centos spread images?
[12:41] <cachio> mborzecki, yes
[12:41] <cachio> weekly
[12:41] <cachio> mborzecki, this is the last one 2 days ago
[12:41] <cachio> https://travis-ci.org/snapcore/spread-cron/builds/633276566
[12:44] <mborzecki> cachio: thanks, i was hoping some updates for systemd landed, but apaprently not
[12:45] <cachio> mborzecki, long time waiting for that landing :(
[12:47] <sergiusens> cachio: Saviq build-base is what you could use
[12:47] <Saviq> sergiusens: but that would only accept "core18" and "core16", right?
[12:48] <Saviq> I'm thinking we could have a Multipass branch that does have "snapcraft:core20"
[12:48] <sergiusens> Saviq: yes, but even if you provide a core20 base quickly for multipass our plugins would need to gain support for core20
[12:49] <sergiusens> Saviq: which is a task I am going to start next Monday
[12:50] <Saviq> sergiusens: ack, let me know if we can help
[12:50] <Saviq> I'll bake a Multipass that has a core20 pointing somewhere sane-ish
[12:51] <sergiusens> Saviq: if you add it to "mainline" multipass no harm should be done since snaps built with it will be marked grade devel
[12:52] <Saviq> sergiusens: yeah but it would suggest it's something real, which it's not atm :)
[13:05] <pedronis> mvo: when #7939 is green it can be landed, reminder about #7947 needing a pass from you
[13:06] <mup> PR #7939: boot,o/devicestate: refactor MarkBootSuccessful over bootState <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7939>
[13:06] <mup> PR #7947: boot/many: support new UC20 style kernel extraction <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7947>
[13:09] <sdhd-sascha> somewhere, i had a patch for meson and core20. Don't know why i have closed the PR 2797
[13:09] <mup> PR #2797: tests: stop tying setting up staging store access to the setup of the state tarball <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2797>
[13:10] <sdhd-sascha> i will recreate that PR. It was easy for meson to enable the plugin on core20
[13:18]  * zyga fires spread, hoping to see some progress
[13:21] <sdhd-sascha> i found my private changes - but i there is sure some refactor needed https://github.com/snapcore/snapcraft/pull/2854/commits
[13:21] <mup> PR snapcraft#2854: Core20 <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2854>
[13:21] <mup> PR snapcraft#2854 opened: Core20 <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2854>
[13:24] <mup> PR snapd#7958 closed: snap-bootstrap: refactor partition creation <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7958>
[13:25] <sdhd-sascha> zyga: "fires spread" - i didn't understand the context
[13:26] <zyga> niemeyer: hey, I'm sorry I haven't pinged you yet - still working on uid/gid bug
[13:26] <zyga> niemeyer: not sure how your day looks like with regards to meetings, I'll have the standup in half an hour
[13:27] <zyga> niemeyer: after that I'm free, we can quickly chat about snap run --explain either now or after if you have the time for that today
[13:27] <zyga> sdhd-sascha: as in run spread tests
[13:27] <zyga> sdhd-sascha: I'm chasing an annoying fix that takes some time to code right
[13:28] <sdhd-sascha> zyga: yeah - there i have to check if my local spread is working. Without time, i like to use my github repo and my patches for that ;-)
[13:29] <zyga> sdhd-sascha: I develop locally for most of the time but I run a specific set of tests to see if my understanding of the code matches reality
[13:31] <sdhd-sascha> zyga: yeah, i want to test locally too. But currently dive into so many git-repo's to understand Xwayland, ubuntu-image, ... And my wife... So i have still a todo on setting up the spread locally. (I know it's started last year, but it was so slow, so that i abort it before all tests was run...)
[13:32] <zyga> sdhd-sascha: my recommendation would be to start with small test that you can run via spread
[13:32] <zyga> sdhd-sascha: even if that test needs to pull snaps from the store or from other places
[13:33] <zyga> sdhd-sascha: this allows you to have some kind of reproducibility
[13:33] <zyga> sdhd-sascha: so you can be more sure about changes than "it worked on my $complex_local_setup yesterday"
[13:34] <sdhd-sascha> yes
[13:39] <zyga> brb, so cold, need to get something warm
[13:39] <zyga> see you at the standup
[13:55] <ijohnson> morning folks
[13:55] <zyga> hey Ian, how are you doing!
[13:56] <zyga> I miss snow, did you get any this winter?
[14:01] <niemeyer> zyga: I should be free around 4 UTC
[14:12] <mup> PR snapd#7967 opened: overlord/snapstate: improve snapd snap backend link unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7967>
[14:20] <mborzecki> cachio: do you have a debug shell to a node with arch image by any chance?
[14:24] <abeato> sergiusens, hi! I was wondering, is there a way to stage packages for a snap without the dependencies? (that is, to strictly stage only what is specified in stage-packages)
[14:24] <mup> PR snapcraft#2855 opened: project: remove unused errors <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2855>
[14:30] <sdhd-sascha> Hey, if someone is interested. I found why "ubuntu-image" always create a too small rootfs-partition on my system. https://github.com/CanonicalLtd/ubuntu-image/pull/182
[14:31] <mup> PR CanonicalLtd/ubuntu-image#182: rootfs: sync before measure size <Created by sd-hd> <https://github.com/CanonicalLtd/ubuntu-image/pull/182>
[14:31] <cachio> mborzecki, no
[14:32] <cachio> mborzecki, this is the erro https://travis-ci.org/snapcore/spread-cron/builds/633276548#L1446
[14:33] <mup> PR snapcraft#2855 closed: project: remove unused errors <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2855>
[14:34] <mborzecki> cachio: heh, so there's some changes in keys apparently, and it looks like the prompt doesn't work too well when input is not a tty
[14:35] <zyga> cachio: please ping me later about that machine state checker from before the break
[14:36] <Chipaca> mvo, degville: https://forum.snapcraft.io/t/behaviour-change-sticky-and-default-tracks/14970
[14:36] <zyga> I completely forgot about it but I did work on it a bit more to get to the point where it can ship a standalone version
[14:36] <cachio> zyga, sure
[14:36] <mborzecki> cachio: hm weird, i have pacman -Syu in spread prepare section for arch, and got a shell just fine, so an update must have been applied without problems
[14:36] <mup> PR snapcraft#2852 closed: wstool: don't rely on host git <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2852>
[14:37] <pedronis> Chipaca: mvo: also it seemed you didn't want to ship snap known --remote using snapd but not download, but that's the state in 2.43 I think, no?
[14:38] <cachio> mborzecki, this is the file which we use to update arch https://github.com/snapcore/spread-images/blob/master/tasks/google/update-arch-linux/task.yaml
[14:39] <cachio> mborzecki, could be caused by pacman-key --populate ??
[14:39] <mup> PR snapcraft#2842 closed: rust: add support for workspaces <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2842>
[14:42] <mup> PR snapcraft#2845 closed: remote-build: configurable timeout/deadline for starting and monitoring build <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2845>
[14:45] <mup> PR snapcraft#2767 closed: rust plugin: add rustup profile <Created by dalance> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2767>
[14:50] <mborzecki> cachio: hm i've never used it
[14:50] <mborzecki> cachio: what's the starting image that you use?
[14:50] <cachio> mborzecki, an old one
[14:50] <cachio> mborzecki, it is called arch-linux-64-base
[14:51] <cachio> mborzecki, I update it every 6 months aprox
[14:51] <mborzecki> cachio: ok, so the keys that are there may have expired
[14:52] <cachio> mborzecki, ok, I'll update the base image and try again
[14:53] <mborzecki> cachio: reading the manpage, --populate reloads the keys from keyring, but if those are expired, you still end up with outdated keys?
[14:53] <mvo> pedronis: uh, indeed
[14:53] <cachio> mborzecki, ah
[14:54] <mborzecki> cachio: could use just use the current image as base and update that to become the next snapshot?
[14:54] <cachio> mborzecki, well, I try to dont do it  because our current image has a lot a packages installed
[14:55] <cachio> I think best solution is to update weekly the base image
[14:55] <cachio> does it make sense?
[14:57] <cachio> currently we are updating the images using the bases
[14:57] <cachio> so, perhaps we should update the base image and then the test image
[14:58] <cachio> using the already updated image
[14:58] <cachio> the scripts that update the base images just make update/upgrade and reboot
[14:59] <cachio> the scripts that update hte test images so the same + creation ¿/deletion of users, management of service, etc
[14:59] <cachio> and install packages for snapd testing as well
[15:01] <cachio> mborzecki, the errror happens when we do this pacman -Suq --needed --noconfirm git jq python2 unzip wget
[15:01] <mborzecki> cachio: yeah, we should probably the base image and then the spread one using the new base
[15:02] <cachio> those are dependencies that we have for spread image project to run the scripts
[15:04] <cachio> mborzecki, I'll skipped those to see if it works
[15:05] <cachio> mborzecki, I am going to pick my daugther, I'll be back in 20 mins
[15:08]  * cachio afk
[15:08] <Chipaca> mvo: should we revert the 'known' change, then?
[15:08] <Chipaca> mvo: for .43 i mean
[15:09] <mborzecki> cachio: got it to work
[15:12] <mvo> Chipaca: yeah, I think that is sensible
[15:14] <mborzecki> cachio:  https://github.com/snapcore/spread-images/pull/24
[15:14] <mup> PR spread-images#24: tasks/google/update-arch-linux: update archlinux-keyring before other packages <Created by bboozzoo> <https://github.com/snapcore/spread-images/pull/24>
[15:32] <pedronis> Chipaca: given how far 2.44 is atm, this feels a bit premature to me: https://forum.snapcraft.io/t/behaviour-change-sticky-and-default-tracks/14970 , not sure if it was discussed at standup
[15:33] <Chipaca> pedronis: it does say TBC fwiw
[15:36] <pedronis> Chipaca: I got a bit worried about you liking sparkiegeek answer about how to set it now, which is kind of too early I feel
[15:37] <Chipaca> pedronis: ah
[15:38] <Chipaca> pedronis: it's useful if somebody wants to play with it
[15:39] <pedronis> Chipaca: anyway I clarified what will happen atm if they do that
[15:40] <Chipaca> you really didn't :) but now that you gave me extra context i understand what you meant
[15:42] <pedronis> Chipaca: feel free to incorporate my comment expanded at the top or something then
[15:43] <pedronis> Chipaca: it should probably say that snap where this is not set will still use latest, and snapd <2.44 will still ask for latest anyway
[15:47] <pedronis> zyga: mvo: I got weird failures here: https://api.travis-ci.org/v3/job/634225161/log.txt
[15:47] <zyga> looking
[15:48] <zyga> aha, I saw this like around 5 times maybe in total
[15:48] <zyga> I was never able to reproduce this with a shell
[15:48] <zyga> it seems that some of the setup, perhaps of just the test, is racy and the container runs before it can really execute
[15:49] <zyga> maybe just after we install snapd the profiles are not really ready yet
[15:49] <zyga> but the service is up
[15:49] <zyga> as in systemd thinks we are good
[15:49] <zyga> so we install a snap and that explodes
[15:49] <zyga> would be good to check if the first-setup we is done before or after systemd considers us to be up
[15:50] <ijohnson> pedronis: off-topic but I've seen that snapd-failover task fail before as well, I added an additional debug section to one of my PR'
[15:50] <ijohnson> s to see what the issue was with that
[15:50] <zyga> because if it is after then this is clearly racy in that regard
[15:50] <zyga> to be precise: the setup of the snap-confine profile happens as a side effect of getting core/snapd snaps
[15:51] <zyga> and snap-confine actively checks if it has a profile, this is the failure that was printed here:
[15:51] <zyga> + lxd.lxc exec my-ubuntu -- su -c '/snap/bin/test-snapd-sh.sh -c '\''echo from-the-inside'\''' ubuntu
[15:51] <zyga> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[15:53] <pedronis> zyga: we are up for systemd before we do various things
[15:53] <zyga> I see
[15:53] <zyga> hmm, that's not great
[15:53] <zyga> but it seems that there's a 2nd depth to explore here
[15:53] <zyga> because why would snap-confine from core execute
[15:53] <zyga> when snap-confine is not set up yet?
[15:53] <zyga> perhaps we do the switch over incorrectly
[16:06] <mvo> pedronis: hm, that log does not even download for me :/
[16:06] <zyga> mvo: I still have it in my browser
[16:06] <zyga> I can probably copy paste it
[16:11] <mvo> zyga: would be nice if you could paste relevant bits, it loads only until something like 2020-01-08 16:11:20 Executing google:ubuntu-16.04-32:tests/main/snap-run-hook:reexec1 (810/3347)... for me
[16:12] <zyga> sure
[16:12] <zyga> the lxd failure is
[16:13] <zyga> https://pastebin.ubuntu.com/p/C5Vp8N6zMR/
[16:13] <zyga> then the failover test
[16:13] <zyga> https://pastebin.ubuntu.com/p/bR5pfQDxgK/
[16:14] <zyga> there's one more failure but it looks like regular journal error
[16:14] <zyga> I need to take a break now
[16:15] <zyga> see you around chaps
[16:18] <niemeyer> zyga: How're things going there?
[16:28] <mup> PR snapd#7957 closed: snap-bootstrap: mount the correct snapd snap to /run/mnt/snapd <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7957>
[16:31] <mup> PR core20#19 closed: static: add /etc/environment to writable-paths <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/19>
[16:33] <mup> PR snapd#7939 closed: boot,o/devicestate: refactor MarkBootSuccessful over bootState <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7939>
[16:35] <zyga> niemeyer: Hey, I can have a quick call, just making coffee
[16:35] <niemeyer> zyga: https://meet.google.com/nej-iory-rpy
[16:40] <pedronis> ijohnson: mvo: #7940 is ready for review
[16:40] <mup> PR #7940: boot: implement SetNextBoot in terms of bootState.setNext <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7940>
[16:45] <ijohnson> pedronis: ack
[16:49] <mvo> pedronis: thanks, in a meetng right now, I will try to look at it
[16:50] <pedronis> mvo: please if you have time do first Ian's one
[16:51]  * mvo nods
[16:51] <pstolowski> pedronis: hey, i've made 2nd pass over #7934, would love to land it, a few small remarks
[16:52] <mup> PR #7934: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/7934>
[16:52] <pedronis> pstolowski: thx, I will look in my morning
[16:57] <pedronis> it might be time to start a new standup document, it's using 0.5G here
[16:57] <pstolowski> heh, +1
[17:11] <ijohnson> mvo: pedronis: having just finished a review of #7940, I think I'm ready to start working on uc20 implementation of all that, matching what's been done for uc16, is that okay?
[17:11] <mup> PR #7940: boot: implement SetNextBoot in terms of bootState.setNext <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7940>
[17:17] <ijohnson> on that topic, it feels like in bootStateFor we may need to know the model to tell if it's a grade unset model in order to figure out we should use the (as of yet non-existent) bootState20, is that logical ?
[17:17] <mvo> ijohnson: sounds good to me
[17:18] <zyga> niemeyer: summarized as https://github.com/snapcore/snapd/pull/7728#issuecomment-572169180
[17:18] <mup> PR #7728: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728>
[17:18] <zyga> niemeyer: thank you again :)
[17:18] <mvo> cachio: I uploaded a new systemd to focal and fixed the /etc/environment not writable, so hopefully a bunch of less failures with tomorrows uc20 core edge update
[17:28] <pedronis> ijohnson: yes, that's what my proposal mentions as adding a HasModeenv to boot.Device
[17:28] <ijohnson> pedronis: ah okay sorry I had forgotten about that proposal
[17:28] <ijohnson> sounds good!
[17:29] <pedronis> ijohnson: to be clear that can be implemented in terms of checking the model
[17:29] <ijohnson> right
[17:30] <pedronis> zyga: the plan to have a structured output api sounds good
[17:30] <zyga> I agree
[17:32] <pedronis> ijohnson: that will be implemented in devicestate/devicectx.go in the end
[17:32] <pedronis> plus a few test places
[17:32] <ijohnson> pedronis: yep that makes a lot of sense
[17:32] <ijohnson> will work on that after I finish up the tests for my kernel extraction PR
[17:33] <pedronis> ijohnson: great
[17:35] <pedronis> ijohnson: I answered mvo wonderined in your kernel PR, which relates to this work as well
[17:35] <pedronis> *wondering
[17:38] <ijohnson> pedronis: ah right I hadn't seen that mvo had reviewed the PR yet (thanks mvo!)
[17:39] <ijohnson> also I am going to merge in master to this PR since the uc20 spread tests are in master now so we have those tests too
[17:45] <cachio> mvo, nice, just saw the message
[17:50] <pedronis> ijohnson: yes, good idea. I added another comment there about the work
[17:56] <ijohnson> yes that's a good point, thanks
[18:03] <pedronis> ijohnson|lunch: we might not need though, because try-kernel is really relevant if try status is set
[18:03] <pedronis> we might just force disable things in some cases to cleanup
[18:03] <pedronis> but not sure
[18:04] <ijohnson|lunch> pedronis: I'll find out soon enough I think
[18:04] <pedronis> ijohnson|lunch: yes :)
[18:27]  * zyga made more progress and EODs
[19:16] <mup> PR snapcraft#2840 closed: plugs: plugs can have no element <Created by sd-hd> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2840>
[19:16] <mup> PR snapcraft#2853 closed: meta: do not set snapcraft-runner when adapter is "none" <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2853>
[19:20] <sdhd-sascha> sergiusens: hey, i come back later, and fix the comments about "core20"
[19:21] <pedronis> ijohnson: thinking a bit about the discussion in your kernel branch about the symlinks, it might be better if setNext in my PR taks a snap.PlaceInfo
[19:22] <mup> PR snapcraft#2856 opened: meta: convert Application's `adapter` from string to enum <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2856>
[19:23] <ijohnson> pedronis: hmm
[19:24] <pedronis> ijohnson: because that's what we use in the bootloader interfaces to refer to snaps
[19:25] <ijohnson> yes that makes sense now that I think about it
[19:25] <ijohnson> cause right now it's just a string
[19:25] <ijohnson> but it would be more meaningful as a snap.PlaceInfo
[19:25] <pedronis> ijohnson: yes, it can be parsed, but it's awkward
[19:25] <pedronis> and it's easy to get back that string
[19:25] <ijohnson> right
[19:25] <pedronis> if it's what is needed
[19:26] <pedronis> to be clear we didn't so far but if added some method to get the revision from PlaceInfo
[19:26] <pedronis> we could stop needing boot.NameAndRevision
[19:26] <pedronis> I'm tempted to finally do that, but that's not really an immediate concern
[19:26] <pedronis> but it's related
[19:27] <pedronis> ijohnson: I'm going to push the setNext change to my PR together with the comment fixes
[19:28] <ijohnson> pedronis: ok
[19:28] <pedronis> in a little bit
[19:28] <ijohnson> yeah I think it would be nice if we could use PlaceInfo instead of NameAndRevision, but looking at that interface it's a bit heavy for what we need in boot I think
[19:28] <ijohnson> maybe that's ok
[19:29] <pedronis> ijohnson: boot is taking it as input anyway
[19:29] <pedronis> and it's easy to make instances
[19:29] <ijohnson> right I was just thinking about places where we would need to construct a PlaceInfo in boot
[19:29] <ijohnson> perhaps it's not a big deal
[19:30] <ijohnson> ah well if it's easy enough to create a PlaceInfo instance then nvm
[19:30]  * ijohnson doesn't remember that code
[19:30] <pedronis> ijohnson: there's snap.MinimalPlaceInfo
[19:30] <pedronis> not any harder to make than NameAndRevision
[19:30] <pedronis> same input
[19:30] <ijohnson> ahhh perfect
[19:30] <pedronis> import wise nothing changes
[19:31] <ijohnson> if I had scrolled down from the file I literally had open I would have saw that :-)
[19:31] <pedronis> np, it's not used a lot to be fair
[19:31] <pedronis> ijohnson: the original purpose of PlaceInfo is mostly for remove-like operation in which we wanted to make sure we didn't assume we could get a lot of info on the snap
[19:32] <pedronis> because it might be broken to start with
[19:32] <ijohnson> I see
[19:35] <pedronis> ijohnson: if you are interested, that's why some methods in snapstate managerBackend interface take PlaceInfo vs Info
[19:35] <ijohnson> ijohnson: that makes sense
[19:35] <ijohnson> err
[19:35] <ijohnson> pedronis: that makes sense
[19:36] <pedronis> ijohnson: anyway a bit of context is probably useful now that you will work with this
[19:36] <ijohnson> yes, very much so thanks for sharing
[19:37] <mup> PR snapcraft#2857 opened: meta: enable Snap to be fully initialized with __init__ parameters <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2857>
[19:40] <mup> PR snapcraft#2821 closed: meta: remove __dict__ usage in Snap  <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2821>
[19:49] <mup> PR snapcraft#2838 closed: add support for system-usernames <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2838>
[19:49] <mup> PR snapcraft#2858 opened: schema: add support for system-usernames <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2858>
[19:53] <pedronis> ijohnson: pushed
[19:55] <ijohnson> pedronis: k, I'll take a look in a bit, in the middle of something right now
[19:55] <pedronis> ijohnson: np
[20:46] <cachio> cmatsuoka, hey
[20:46] <cmatsuoka> cachio: hello
[20:47] <cachio> cmatsuoka, do you know if the file /boot/efi/foo.cfg should exist on core20?
[20:49] <cachio> I have a test failing because of it is trying to read it
[20:49] <cmatsuoka> cachio: like grub.cfg? I think it should be in /EFI/ubuntu, let me check here...
[20:49] <cmatsuoka> ah, you mean literally foo.cfg?
[20:49] <cmatsuoka> maybe some test is creating it?
[20:50] <cachio> cmatsuoka, yes, the test is
[20:50] <cachio> gadget-update-pc
[20:50] <cachio> and it should leave that file
[20:50] <cachio> but is not doing that
[20:50] <cmatsuoka> hmm, let me check here...
[20:53] <cmatsuoka> cmatsuoka: I think we can leave this disabled until we check with mborzecki tomorrow
[20:53] <cmatsuoka> cachio: I think we can leave this disabled until we check with mborzecki tomorrow
[20:53] <cachio> ok
[20:53] <cachio> np
[20:54] <cachio> cmatsuoka, any idea why the file /var/lib/snapd/seed/seed.yaml does not exist on core20?
[20:54] <cachio> it is braking another test
[20:57] <cmatsuoka> there are things that are different there, I don't remember if this specific file should be there or not
[20:57]  * cmatsuoka checks the docs
[21:06] <cachio> ijohnson, hey
[21:06] <cachio> the netplan test is failing on core20
[21:06] <cachio> https://paste.ubuntu.com/p/fTcVRFPqdT/
[21:06] <cachio> the test is ubuntu-core-netplan
[21:06] <cachio> I have a debug session open if you want to take a look
[21:22] <cmatsuoka> cachio: yep, the structure is different
[21:23] <cachio> cmatsuoka, right
[21:23] <cmatsuoka> cachio: maybe you can check for something in /var/lib/snapd/seed/systems?
[21:24] <cachio> snap repair is failing because of this
[21:24] <cmatsuoka> cachio: hm, I think we can check this with mvo tomorrow
[21:24] <ijohnson> cachio: hey
[21:25] <cachio> cmatsuoka, yes
[21:25] <ijohnson> sorry I missed your ping
[21:25] <ijohnson> let me look
[21:25] <cachio> I'll leave a note in the doc with the details
[21:26] <cachio> ijohnson, do you want the credentials?
[21:27] <ijohnson> cachio: I'm kinda in the middle of working on other uc20 stuff, so I don't have the time to look into this, but I will look into it tomorrow
[21:27] <ijohnson> cachio: but out of curiosity are other dbus tests passing on uc20?
[21:27] <cachio> ijohnson, yes
[21:27] <cachio> many of tehm
[21:27] <cachio> them
[21:27] <ijohnson> cachio: that error message is from dbus and not specific to netplan (though the netplan test might have broken somehow)
[21:28] <ijohnson> cachio: okay that's what I would have thought from this error message
[21:28] <ijohnson> cachio: please just leave a note in the SU and I will look tomorrow if nobody else beats me in their AM
[21:28] <ijohnson> thanks
[21:28] <cachio> ijohnson, sure, thanks!!!
[21:31] <ijohnson> cachio: thanks
[23:02] <mup> PR snapcraft#2859 opened: meson plugin: add support for core20 <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2859>


 Awaiting now to know how it works on the real world .
[02:41] <lotuspsychje> yeah
[02:43]  * daftykins clicks to see what this one will be called from xorg's point of view
[02:44] <daftykins> is it 'amdgpu' ?
[02:45] <lotuspsychje> not sure
[02:45] <Bashing-om> daftykins: No idea .. I had for some reason expected " FGLRX-updates" .
[02:46] <daftykins> i guess time will tell
[02:48] <Bashing-om> The indications I understood, the fix was now in the repo .. lotuspsychje Ya booting 15.10 to see ?
[02:48] <lotuspsychje> Bashing-om: im on trusty and xenial upstairs :p
[02:50] <Bashing-om> lotuspsychje: daftykins Well ,, I guess we await another ginny pig to see .
[02:50] <lotuspsychje> lol
[02:51]  * daftykins grins widely, in a slightly concerning way
[02:52] <daftykins> amdgpu is going to have TearFree :O
[02:54] <lotuspsychje> !find xf86
[02:55] <Bashing-om> To this time I can not cross reference to see if the new driver is in the repo .
[02:55] <Bashing-om> shucks.
[02:55] <lotuspsychje> !find amdgpu
[02:56] <lotuspsychje> another source: http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-Xorg-1.0
[02:56] <daftykins> i think it'd need to be the long name
[02:57] <daftykins> maybe like a "xserver-xorg-video-amdgpu"
[02:58] <Bashing-om> thers a thought ..lemee see .
[02:59] <daftykins> but thenthe article said xf86-video-amdgpu so i'm not sure if they are renamed by Canonical
[02:59] <lotuspsychje> driver might be just named amdgpu perhaps
[02:59] <lotuspsychje> as radeon
[02:59] <daftykins> i think that's just the name as per you would configure in xorg.conf though
[02:59] <daftykins> radeon is still xserver-xorg-video-radeon in package form, no?
[02:59] <lotuspsychje> yeah
[03:01] <lotuspsychje> lotuspsychje@R00TB0X:~$ apt-cache policy xserver-xorg-video-radeon
[03:01] <lotuspsychje> xserver-xorg-video-radeon:
[03:01] <lotuspsychje>   Geïnstalleerd: 1:7.3.0-1ubuntu3.1
[03:03] <lotuspsychje> we findout soon on R9 users :p
[03:05] <daftykins> ok i'm going folks, g'night and i'll see you in the week :)
[03:06] <daftykins> next time on a whole new episode of... #ubuntu !
[03:06] <lotuspsychje> nite nite daftykins
[03:27] <cdshan> Hi!  Could some one help me out with the upgrade from Ubuntu 14.10 to 15.04? I had tried the documentation available on the net but am not able to succeed. some inputs would be very much appreciated!
[03:28] <lotuspsychje> cdshan: this is ubuntu discuss channel mate
[03:46] <cdshan> lotuspsychje: what is the right channel to discuss about this?
[03:48] <lotuspsychje> cdshan: thats not a discussion, but an ubuntu support question
[03:48] <lotuspsychje> cdshan: so in #ubuntu
[03:48] <cdshan> ok, thanks for  the info
[08:51] <lordievader> Good morning.
[12:53] <lotuspsychje> good afternoon TJ-
[12:53] <TJ-> hiya :)
[12:54] <lotuspsychje> http://news.softpedia.com/news/open-source-amdgpu-linux-driver-released-supports-the-latest-amd-gpus-496545.shtml
[12:57] <TJ-> About time - only 15 years late
[12:57] <lotuspsychje> :p
[12:59] <TJ-> Let's hope it has better quality than the fglxr
[12:59] <lotuspsychje> yeah, now to wait for R9 users :p
[13:18] <lotuspsychje> cfhowlett: http://news.softpedia.com/news/puppy-linux-based-studio-13-37-aims-to-be-the-ultimate-pro-audio-distro-gallery-496553.shtml
[13:19] <cfhowlett> ... cause ANOTHER linux audio distro is exactly what we need!  :)
[13:19] <lotuspsychje> :p
[13:20] <lotuspsychje> 'the best!'
[13:30] <lotuspsychje> hi lordievader
[13:32] <lordievader> o/
[14:02] <lotuspsychje> hey EriC^^
[14:02] <EriC^^> hey lotuspsychje
[14:02] <lotuspsychje> hows the tv doing?
[14:02] <EriC^^> it's good :P
[14:03] <lotuspsychje> movie overtime :p
[14:03] <lotuspsychje> did you see blackhat yet EriC^^ ?
[14:03] <EriC^^> nope
[14:03] <EriC^^> any good?
[14:03] <lotuspsychje> yeah very good
[14:04] <EriC^^> cool
[14:04]  * lotuspsychje throws a redhat to OerHeks
[14:04] <EriC^^> TJ-: how come we can upgrade releases to the current development one but not jump to previous ones?
[14:05] <EriC^^> TJ-: like bumbar upgraded from 14.04 to 15.10 using do-release-upgrade -d , users usually have to go to 14.10 then 15.04 then 15.10
[14:08] <lotuspsychje> EriC^^: -d, --devel-release
[14:08] <lotuspsychje>               Check if upgrading to the latest devel release is possible
[14:09] <lotuspsychje> dont think downgrade is possible on ubuntu
[14:09] <cfhowlett> it's not an option
[14:09] <EriC^^> yeah, i know, how come users can't jump from 14.04 to let's say 15.10 ( if it's not development )
[14:10] <lotuspsychje> lts and non-lts are divided
[14:10] <cfhowlett> EriC^^, because ubuntu only upgrades sequentially.  sole exception: LTS
[14:11] <EriC^^> cfhowlett: yeah, but with -d it upgraded from lts to non-lts skipping 3-4 releases
[14:11] <EriC^^> i mean what's the idea behind it
[14:12] <lotuspsychje> wrong command on the latest LTS
[14:12] <lotuspsychje> resulted badly
[14:14] <lotuspsychje> next in the row is 16.04 and 16.10
[14:14] <lotuspsychje> but as they dont exist yet...
[14:14] <lotuspsychje> EriC^^: i also used do-release-upgrade -d from 15.10 to next release 16.04
[14:14] <EriC^^> yeah
[14:15] <lotuspsychje> EriC^^: but i wanted the early stage testing
[14:17] <EriC^^> like in couples months 16.04 comes out, if somebody is using 14.10 right now, he can just jump to it if he wants
[14:17] <EriC^^> instead of going 14.10 > 15.04 > 15.10 > 16.04
[14:18] <lotuspsychje> i dont think so
[14:18] <EriC^^> was wondering why he can't just do that straight away when 16.04 comes out, unless using -d isn't recommended and it's dangerous or something
[14:18] <EriC^^> ( i mean it might break the system more than the usual 14.10 > 15.04 > 15.10 > 16.04 )
[14:19] <lotuspsychje> EriC^^: i think the normal way is do-release-upgrade
[14:20] <lotuspsychje> but the -d might force it
[14:21] <cfhowlett> I'd feel much safer doing a clean install
[14:22] <lotuspsychje> EriC^^: blueskaj might know more of this
[14:23] <EriC^^> lotuspsychje: xenial kernel is what?
[14:23] <EriC^^> i think bumbar is on xenial not 15.10
[14:24] <lotuspsychje> EriC^^: 4.2 and soon receive 4.3 i think
[14:24] <EriC^^> 4.2.0-19 is xenial?
[14:24] <EriC^^> !info linux-image-generic wily
[14:24] <lotuspsychje> !info linux-image-generic xenial
[14:25] <lotuspsychje> yeppers
[14:27] <EriC^^> he says he can't update
[14:27] <EriC^^> Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/xenial/InRelease
[14:27] <lotuspsychje> hmm
[14:27] <lotuspsychje> sudo apt-get update?
[14:27] <EriC^^> yeah, the file is there though just checked in a web browser
[14:27] <lotuspsychje> EriC^^: or maybe other ppa's installed for his previous ubuntu?
[14:27] <EriC^^> nope the xenial main stuff
[14:28] <lotuspsychje> weird
[14:28] <lotuspsychje> i recently updated on my xenial box
[14:28] <EriC^^> i guess he has connection issues
[14:30] <lotuspsychje> afternoon BluesKaj
[14:30] <BluesKaj> Hiyas all
[14:30] <BluesKaj> hey lotuspsychje
[14:31] <lotuspsychje> BluesKaj: eric just had a trusty user upgrade to 15.10 with do-release-upgrade -d
[14:31] <lotuspsychje> BluesKaj: can you explain the logic of this?
[14:31] <EriC^^> not me, he upgraded before we even met :P
[14:31] <cfhowlett> yeah that sounds way suspect ...
[14:34] <BluesKaj> nope, I can't, unless he upgraded to 16.04 from 15.10...he's mistaken I'm sure
[14:34] <lotuspsychje> ah
[14:34] <lotuspsychje> BluesKaj: so its not possible to upgrade lts to non-lts?
[14:34] <BluesKaj> -d is devel OS
[14:35] <EriC^^> i think cause he had 14.04 he went to 16.04
[14:35] <EriC^^> at first he said he was on 15.10 from 14.04 using -d
[14:35] <BluesKaj> of course it is , just disable the LTS only upgrade in the package manager
[14:35] <lotuspsychje> BluesKaj: but i upgraded also 15.10 to 16.04 with -d
[14:36] <BluesKaj> yes but -d mean developement OS , not official release OS
[14:36] <cfhowlett> that would be normal.
[14:36] <lotuspsychje> ah
[14:37] <lotuspsychje> ok teatime here
[14:37] <lotuspsychje> :p
[14:38] <BluesKaj> methinks there's some confusion or maybe some BS involved with your trusty user
[14:38] <BluesKaj> lotuspsychje,^
[14:42] <BluesKaj> if he used -d then he mostlikely received 16.04, not 15.10, if he left the "LTS only upgrade" enabled, which is the default status afaik
[14:43] <EriC^^> BluesKaj: yeah it turned out he had 16.04
[14:43] <BluesKaj> EriC^^, right
[14:43] <EriC^^> he said 15.10 at first, so i was wondering how could he jump from 14.04 to 15.10 without going through 14.10 and 15.04 by using -d , didn't make much sense
[14:44] <BluesKaj> exactly
[14:44] <EriC^^> like if someone had 13.10 and 16.04 is about to get released in a week they can just use -d and jump straight to that
[14:44] <EriC^^> but usually cant and have to go a bunch of releases up first
[14:45] <BluesKaj> dunno , never tried skipping releases with -d
[15:01] <TJ-> I recall doing some work with the release-upgrader-core some years ago. with 'do-release-upgrade --devel' it'll fetch http://changelogs.ubuntu.com/meta-release-development and take the latest "Supported: 1" entry
[16:53] <MonkeyDust> yes
[18:33] <lotuspsychje> good evening to all
[18:35] <lordievader> o/
[18:35] <daftykins> \o
[18:35] <lotuspsychje> hey lordievader i tested unity8/mir on xenial :p
[18:35] <lotuspsychje> hi daftykins
[18:35] <lordievader> Blegh Unity...
[18:35] <lotuspsychje> lol
[18:35] <lordievader> lotuspsychje: How was it? Horrible?
[18:36] <lotuspsychje> hehe shiny bling like ubuntu touch :p
[18:36] <lotuspsychje> but still shows as the phone version, alot of work needed until its desktop version
[18:37] <lordievader> Is it usable yet?
[18:37] <lotuspsychje> lordievader: mouse support works to slide the scopes and browsing works
[18:37] <lotuspsychje> lordievader: but again, it doesnt look like a desktop yet, much more phone
[18:38] <lordievader> Brr
[18:38] <lotuspsychje> lol
[18:39] <lotuspsychje> who knows what they will do with plasma in the future :p
[18:58] <daftykins> wow at 3x to ask 'which OS are you in?'
[18:59] <lotuspsychje> prrrt
 I installed Ubuntu GNOME 15.10 on my desktop with Asus Z170-K motherboard and legacy mode enabled. The drive is formatted with GPT and already has Windows on it.
[18:59] <lotuspsychje> thats his first question
[18:59] <lotuspsychje> how are we suppose to know
[19:00] <lordievader> How is that a question?
[19:00] <lordievader> It mises the question mark and the... uhh... question.
[19:04] <lotuspsychje> Bashing-om: hello mate
[19:04] <Bashing-om> lotuspsychje: O/ .. 'Nother lovely day in the neighborhood .
[19:04] <lotuspsychje> : )
[19:08] <lotuspsychje> i like uefi only when ubuntu boots it single :p
[19:09] <lotuspsychje> lucky for our users we have EriC^^ :p
[19:09] <OerHeks> i like uefa only when .... wait
[19:09] <lotuspsychje> hahaha
[19:09] <OerHeks> there are vendors that build their own uefi
[19:09] <lotuspsychje> ubuntu and football even dont match OerHeks
[19:09] <EriC^^> i wish tj was here
[19:09] <lotuspsychje> EriC^^: got a question?
[19:10] <EriC^^> i remember he had a bright idea about converting without booting into uefi mode
[19:10] <lotuspsychje> EriC^^: converting what
[19:10] <MonkeyDust> don't believe him
[19:10] <EriC^^> ah i remember
[19:10] <lotuspsychje> lol MonkeyDust
[19:11] <lotuspsychje> never saw you was here MonkeyDust
[19:11] <EriC^^> loading the efivars module or something so grub can access it from a legacy booted session
[19:11] <MonkeyDust> (have no clue what it's about)
[19:11] <lotuspsychje> MonkeyDust: there's a little button on your irc client, 'add to favorites' :p
[19:15] <lotuspsychje> we all have our talents here and crazy ideas
[19:15] <lotuspsychje> especially OerHeks is also crazy
[19:16] <daftykins> EriC^^: :D
[19:16] <MonkeyDust> i hate crazy people
[19:16]  * lotuspsychje hides
[19:16] <EriC^^> daftykins: i like this guy, he's quick! :D
[19:16] <daftykins> MonkeyDust: if so, why do you join us in #ubuntu ? :D
[19:16] <lotuspsychje> MonkeyDust: we need einsteins in this world!
[19:16] <daftykins> EriC^^: lol he took many minutes to even say which OS he was in before :(
[19:16] <daftykins> EriC^^: i guess i warmed him up for you :P
[19:17] <lotuspsychje> hahaha
[19:17] <EriC^^> haha
[19:17] <EriC^^> :D
[19:17] <lotuspsychje> warming up support
[19:17] <lotuspsychje> thats new :p
[19:17]  * lotuspsychje gonna warm up some trolls for OerHeks
[19:20] <lotuspsychje> ioria is a weird guy...oops shhhh
[19:20] <lotuspsychje> he's here
[19:20] <ioria> yes, i'm
[19:20] <lotuspsychje> :p
[19:21] <ioria> :þ
[19:23] <MonkeyDust> i hate weird guys
[19:24] <lotuspsychje> lol
[19:24] <ioria> indeed... i hate myself
[19:25] <lotuspsychje> ioria: ok give 50 euro for the psychological advise to me now :p
[19:26] <ioria> lotuspsychje,   come again , please  ????
[19:26] <lotuspsychje> lol
[19:26] <lotuspsychje> ioria: its a joke
[19:26] <ioria> oh, Crazy World ? my kingdom for an horse !
[19:27] <lotuspsychje> https://news.drweb.com/show/?i=9709&lng=en
[19:27] <daftykins> guruprased is another skylake upgrader then
[19:28] <daftykins> no doubt tripping up on early EFIs :D
[19:38] <EriC^^> man chkdsk sucks, this guy installed linux yesterday, windows somehow got corrupted wouldn't mount
[19:38] <lotuspsychje> windows 10 brrrr
[19:38] <EriC^^> ntfsfix said to use chkdsk, so he used chkdsk from a windows cd, today his partition mounted, except it only had System Volume Information in it
[19:39] <EriC^^> nothing in testdisk either
[19:39] <lotuspsychje> weird
[19:39] <EriC^^> he didn't have any stuff on it though, said it was from work
[19:39] <lotuspsychje> EriC^^: you sure he followed correct steps to install dualboot uefi?
[19:40] <EriC^^> he said he used the installer's other option to install to the empty space
[19:40] <EriC^^> i wanted to ask him how he shrunk the partition and if he booted into it after shrinking a couple times cause some people say it's recommended
[19:41] <EriC^^> didn't find out though if that's what got it corrupted, his smart data looked clean
[19:41] <EriC^^> i think it's a new 128gb ssd
[19:41] <lotuspsychje> ssd should be fine, but weird that windows is gone
[19:42] <lotuspsychje> if he's sure that he installed?
[19:42] <EriC^^> *shrug*
[19:42] <lotuspsychje> EriC^^: is it a hybrid ssd?
[19:42] <EriC^^> dunno, it was win7 fwiw
[19:47] <lotuspsychje> wb BluesKaj
[19:47] <BluesKaj> thanks lotuspsychje
[19:52] <daftykins> EriC^^: i think that user did more than you were told ;)
[19:52] <Bashing-om> EriC^^: I have learned to watch out : Intel Smart Response Technology - dual boot . embedded data .
[19:52] <OerHeks> maybe it had bitlocker
[19:53] <OerHeks> :-D
[19:53] <daftykins> i've had win7 installed beside a xubuntu install for ages, keep upgrading xubuntu... upgraded to win10 and installed several new builds since, not one hint of trouble
[19:53] <lotuspsychje> Bashing-om: i had a medion box once with weird intel setting blocking new Os install once
[19:53] <daftykins> ah the boot sector protection? :D
[19:54] <JanC> boot sector protection doesn't really work outside DOS, right?  :P
[19:54] <lotuspsychje> daftykins: keep forgetting its setting name
[19:54] <lotuspsychje> intel something something...
[19:55] <daftykins> intel break lotus' stuff, i think
[19:55] <daftykins> :D
[19:55] <daftykins> JanC: sure does
[19:55] <Bashing-om> Once upon a time in windows 7 with SSD and fast startup ... welp that was MS doing a raid thing .
[19:55] <lotuspsychje> lol
[19:55] <lotuspsychje> hehe daftykins
[19:56] <JanC> early boot sector protection worked purely at the BIOS level and modern OSs don't use that after boot
[19:59] <daftykins> my memory is hazy, it could've been as long ago as Windows XP that setup got booted by for trying to do it when that option was on
[20:58] <Kaosu> I was wondering if anyone might take a look a Ubuntu security guide I decided to write. Feel free to PM me with feedback. You can find the guide at: https://codezero.me/Ubuntu-Security-Guide/
[20:59] <lotuspsychje> Kaosu: looks good, but i would add some more stuff
[20:59] <Kaosu> Such as?
[20:59] <lotuspsychje> Kaosu: like intrusion detectors
[21:00] <lotuspsychje> Kaosu: fail2ban for ssh users
[21:00] <MonkeyDust> Kaosu  i scrolled quickly in your manual... there's this too... http://hardenubuntu.com/
[21:00] <lotuspsychje> !security | Kaosu and here
[21:00] <Kaosu> My plan was to split the guide up into two parts, but make them a complete guide when combined together. The first half would be focused on home users and the second half would be aimed at administrators/power users.
[21:01] <Kaosu> So, the second half would cover all of those suggested topics.
[21:01] <lotuspsychje> good idea
[21:01] <MonkeyDust> Kaosu  and add a short content list too, in the beginning of the document
[21:01] <lordievader> Perhaps a section about rkhunter too?
[21:02] <lotuspsychje> good idea lordievader
[21:03] <Kaosu> I made a note to add information about rkhunter in the "malware" section.
[21:03] <MonkeyDust> Kaosu  another thing: try sudo apt update, see what's different   <-- not apt-get
[21:03] <lotuspsychje> !usn | Kaosu yeah read here also
[21:05] <Kaosu> I might actually add a section to the guide like "Current Security Issues" and just grab the top entries from the USN
[21:05] <MonkeyDust> Kaosu  and avoid referring to yourself, as in 'I would prefer'
[21:06] <Kaosu> Monkey: Thanks for pointing that out. I will go through and fix the areas where I did that.
[21:06] <Kaosu> I'm not a very good writer, but I am getting better about not doing things like that.
[21:08] <lotuspsychje> nite nite all