[05:23] <mborzecki> morning
[06:11] <mborzecki> xdg mime handling feels like a maze
[06:46] <mup> PR snapd#6709 closed: release: 2.38.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6709>
[06:49] <mborzecki> mvo: hi
[06:50] <mborzecki> mvo: can you upload 2.38.1 source packages to the releases page?
[06:55] <zyga> Good morning
[06:55] <zyga> A bit sleepy today
[06:56] <zyga> I stayed way too long hacking on snap confine last night
[07:00] <mborzecki> zyga: hey
[07:01] <mup> PR snapd#6661 closed: data/selinux, tests/main/selinux-clean: fine tune the policy, make sure that no denials are raised <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6661>
[07:05] <pstolowski> morning
[07:08] <mborzecki> pstolowski: hey
[07:08] <mborzecki> zyga: btw. tried 19.04 with my gt1030 and did not run into any problems (at least with proprietary drivers)
[07:14] <mup> PR snapd#6711 opened: tests/main/selinux-lxd: make sure LXD from snaps works cleanly with enforcing SELinux <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6711>
[07:18] <mup> PR snapd#6238 closed: [WIP] many: add minimal SELinux support, refactor the policy <SELinux> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6238>
[07:19] <mborzecki> #6692 is super simple and needs a 2nd review
[07:19] <mup> PR #6692: interfaces: cleanup internal tool lookup in system-key <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6692>
[07:26] <mup> PR snapd#6707 closed: overlord: factor out mocking of device service and gadget w. prepare-device for registration tests  <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6707>
[07:28] <zyga> mborzecki: curious why it didn’t work for popey
[07:29] <mborzecki> zyga: do you know if there was a specific snap that failed for him?
[07:30] <zyga> No, I don’t recall
[07:41] <mborzecki> zyga: to be exact, there's 418 nvidia drivers installed on the host, my graphics-debug-tools-bboozzoo snap seems to work fine with core and core18 bases
[07:41] <mborzecki> hm maybe it's godot specific
[07:42] <mborzecki> zyga: fwiw godot is classic :/
[07:44] <mborzecki> zyga: aand it doesn't work
[07:50] <mvo> mborzecki: hey, sorry for the delay, had a meeting
[07:50] <mvo> mborzecki: 2.38.1 is not really needed outside of ubuntu/debian, its only packaging changes
[07:59] <zyga> mborzecki: great, so it's consistent
[07:59] <zyga> mborzecki: so what did work and what did not work and what are the symptoms of not working?
[08:00] <zyga> man, it's cold today
[08:00] <mborzecki> zyga: confined snaps worked (core, core18), classic does not
[08:00] <zyga> mborzecki: that's most curious
[08:01] <zyga> mborzecki: if yo want to learn more please do, I'm going to keep pushing on bugfixes from last weeks
[08:08] <zyga> mborzecki: arguably
[08:08] <zyga> mborzecki: once we have the support for classic mount namespaces
[08:08] <zyga> mborzecki: we could enable driver support for classic snaps as well
[08:20]  * zyga is gardening email
[08:54] <pstolowski> hmmmmm
[08:55] <pstolowski> why do we update fc-cache twice in LinkSnap - before and after changing current symlink?
[08:56] <mborzecki> pstolowski: the after part is bc you may be updating from pre-fc-cache version of core/snapd
[08:56] <pstolowski> (the second is probably a no-op if fc-cache finds all the files in place)
[08:57] <mborzecki> pstolowski: the before part will make sure the cache was updated before the snap is runnable
[08:58] <pstolowski> mborzecki: ah, i see, the logic there is a bit subtle
[09:10]  * Chipaca is having a paperwork-y kind of day
[09:38] <pedronis> Chipaca: we never did but at this point we could remove the code about AnonymousDownloadURL from store, right?
[09:39] <Chipaca> pedronis: we have AnonymousDownloadURL code?
[09:39] <pedronis> Chipaca: we do
[09:39] <Chipaca> ah, AnonDownloadURL
[09:48] <kjackal> Hi snappy people, I am not able to connect to kubernetes-support https://pastebin.ubuntu.com/p/ZhdT3gPvgD/  "Multiple definitions for hat systemd_run in profile (null) exist,bailing out." is the error. ANy hints?
[09:54] <zyga> kjackal: hey, looks like a bug in snapd
[09:54] <zyga> kjackal: can you please report it
[09:55] <kjackal> Sure, seem like I cannot do two connections in the kubernetes support interface
[09:56] <zyga> can you tell me more how you got the two connections?
[09:58] <kjackal> sure
[09:58] <kjackal> let me push the yaml
[10:00] <Chipaca> pedronis: we'd have to check that in all cases the other url is populated though
[10:01] <kjackal> zyga: Here are the two flavors of the kube-support interface https://github.com/ubuntu/microk8s/blob/feature/strict-v2/snapcraft.yaml#L21
[10:01] <kjackal>
[10:01] <kjackal> The second connect is failing:
[10:01] <kjackal> > sudo snap connect microk8s:k8s-kubeproxy  :kubernetes-support
[10:01] <kjackal>  > sudo snap connect microk8s:k8s-kubelet :kubernetes-support
[10:01] <kjackal> error: cannot perform the following tasks:
[10:01] <kjackal> zyga: ^
[10:02] <zyga> kjackal: the reason for the failure is as follows:
[10:02] <zyga> kjackal: the definitions are mutually exclusive
[10:02] <zyga> kjackal: the plug definitions  at the top of the snap yaml are global
[10:02] <zyga> kjackal: if an app has no plugs or slots defined it gets access to *all* plugs and slots defined at the global level
[10:03] <zyga> kjackal: the ctr app is one example in your yaml
[10:03] <zyga> it will get access to docker-privileged, k8s-kubelet  and k8s-kubeproxy
[10:03] <zyga> kjackal: snapd does not detect mutually exclusive plugs or slots from being connected
[10:03] <zyga> kjackal: apparmor parser detects the conflicting permissions granted and rejects the generated apparmor profile
[10:04] <zyga> kjackal: that is all
[10:05] <kjackal> thank you zyga I will need some time to ingest exactly what you said, and I will get back to you
[10:05] <kjackal> brb
[10:06] <zyga> kjackal: I encourage you to seek clarifications for any of the items I listed at any time
[10:25] <zyga> brb
[10:57] <mborzecki> cachio: hi, can we update fedora & centos images?
[10:58] <mborzecki> cachio: seems like there,s a bunch of pending updates that have not been applied yet
[11:06] <cachio> mborzecki: hi, yes, I just reviewed that because both have been updated but seems to be an error during the process
[11:06] <cachio> https://travis-ci.org/snapcore/spread-cron/builds/517200642#L2633
[11:06] <cachio> I'll fix that and recreate the images
[11:07] <mup> PR snapd#6712 opened: overlord/snapstate: add timings to critical task handlers and the backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/6712>
[11:10] <mborzecki> cachio: ah, so it's not related to fedora/centos running tests, but rather a problem with gcp project config
[11:13] <cachio> mborzecki: yes
[11:14] <cachio> It failed to create the image but the build is in green
[11:14] <cachio> I'll retrigger the image and poke this issue
[11:17] <mborzecki> spread does not build anymore, golang.org/x/net dropped the context package
[11:17] <cachio> niemeyer:  hey,  seems to be a permissons issue on gce, I wuold need this one https://paste.ubuntu.com/p/CHYvrgDnvC/
[11:24] <cachio> mborzecki: we are not creating any image because a change in the permissions
[11:24] <cachio> mborzecki: we need gustavo for this
[11:25] <cachio> mborzecki: I am trying to workaround that untils we fix the permissons issue
[11:35] <zyga> mborzecki: thank you
[11:40] <mup> PR snapd#6713 opened: tests/upgrade/basic: restore SELinux context of /var/cache/fontconfig <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6713>
[11:41] <mborzecki> pstolowski: if you could ^^
[11:41] <mborzecki> zyga:  do you know of other classic snaps that may want to use opengl?
[11:41] <zyga> no
[11:44]  * pstolowski lunch
[11:45] <mup> PR snapd#6714 opened: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>
[11:46]  * cachio afk
[11:51] <Girtablulu|Away> is it possible to set the value refresh.retain while packaging snapd and not just after it?
[11:57] <zyga> mborzecki: godot uses locally embedded libGL.so
[11:57] <zyga> Girtablulu|Away: no, not at present
[11:58] <Girtablulu|Away> thanks for the answer
[11:59] <mborzecki> zyga: duh, why would they do that?
[11:59] <zyga> mborzecki: it's one of the problems with snapcraft and GL today
[11:59] <zyga> we need to change that across the ecosystem to fix the problem
[12:00] <zyga> ldd of godot https://www.irccloud.com/pastebin/0Y1v1Jfc/
[12:00] <zyga> this is not sustainable: we cannot expect to support new hardware when everything is frozen like  that
[12:00] <zyga> mborzecki: I'm thinking of several solutions, happy to discuss
[12:00] <zyga> mborzecki: one of those elements is to package a new shim gl library that snapcraft will use instead of the real libraries
[12:01] <zyga> the shim gl is just there to satisfy dependencies, it does not actually contain any gl system
[12:01] <zyga> at runtime it would always be supplied by snapd, even for things like mesa
[12:01] <zyga> the problem is that this is complex to execute
[12:01] <zyga> at the same time I don't see anything that doesn't involve fixing snaps
[12:02] <jdstrand> zyga (cc kjackal): I think you mispoke
[12:03] <zyga> oh?
[12:03] <jdstrand> zyga: the plugs at the top are only global if there are no plugs down below
[12:03] <zyga> not quite, if an app has zero plugs or slots defined, it does get all globally defined plugs and slots
[12:03] <zyga> I don't know if we have a way to say "I want none"
[12:03] <zyga> like plugs: []
[12:04] <zyga> or if snapcraft would not remove that
[12:04] <zyga> "down below" I assume you mean at app level?
[12:04] <jdstrand> yes
[12:04] <jdstrand> also, I used the pasted snap.yaml and there were no issues
[12:05] <jdstrand> https://paste.ubuntu.com/p/sRcydgPNhb/
[12:05] <zyga> hmmm
[12:05] <zyga> that's odd
[12:05] <jdstrand> zyga, kjackal: ^
[12:06] <zyga> jdstrand: offtopic: https://github.com/snapcore/snapd/pull/6714
[12:06] <mup> PR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>
[12:06] <kjackal> yes... it is failing over here... jdstrand how do you connect the two interfaces?
[12:07] <jdstrand> zyga: also, 'enable' has no plugs and it didn't get both interfaces. it got precisely 0
[12:07] <zyga> hmm
[12:07]  * zyga checks stuff
[12:07] <jdstrand> zyga: so it is operating how I understand it, not how you described it
[12:08] <zyga> that code was changed a while ago to fix a related bug
[12:08] <zyga> perhaps there were some unexpected consequences or perhaps I just plain misremember how it is supposed to work
[12:08] <zyga> aha, I see
[12:09] <zyga> so a plug or slot defined at top level is only added to apps or hooks if it is not bound to any app or hook
[12:09] <zyga> that's actually sensible and less surprising
[12:09] <zyga> jdstrand: thank you for correcting me
[12:09] <zyga> kjackal: jdstrand is correct, my previous explanation is invalid
[12:10] <jdstrand> kjackal: https://paste.ubuntu.com/p/BpGjHgmfmj/
[12:10] <zyga> jdstrand: I'm working on https://github.com/snapcore/snapd/compare/master...zyga:fix/suse-audit-4?expand=1
[12:10] <zyga> jdstrand: I will add some spread tests for how this behaves before opening the PR though
[12:10] <kjackal> jdstrand: then why am I getting this: https://pastebin.ubuntu.com/p/ZxTF2j4tyg/
[12:11] <jdstrand> zyga: I'm going to pick daemon user today
[12:11] <zyga> jdstrand: on top of that I will add packaging changes to make the snapd socket and key executables owned and only executable by the new snapd group
[12:11] <zyga> pick?
[12:11] <kjackal> Sorry I am very new to the strict confinement
[12:11] <zyga> jdstrand: one thing that I'm worried about, with regards to the snapd group, is that we have no stable GIDs across distributions
[12:11] <zyga> jdstrand: therefore it is unclear to me what should be placed in the core/snapd snaps
[12:11] <jdstrand> kjackal: what is the output of 'snap version'
[12:11] <zyga> jdstrand: perhaps, however ugly, that should be checked inside the snap* commands
[12:12] <kjackal> jdstrand: http://paste.ubuntu.com/p/MdR8yPmzYc/ 2.38
[12:12] <jdstrand> zyga: if you set daemon user aside, the concept as a whole is that snapd has a predictable mapping
[12:12] <zyga> (so they remain being root-owned and root-group-owned and executable by all but perform an explicit check at runtime)
[12:12] <jdstrand> zyga: let me rephrase, if you set system users aside, there is a predicatable mapping
[12:12] <zyga> jdstrand: I'm not sure I follow
[12:14] <jdstrand> zyga: it would take a lot to explain in irc. it is in the spec. I'll attempt to summarize. there are several types of these things. for 'shared-users' (aka 'global-ids' in the spec), the store maintains the uid/gid and username/group mappings so it is global across the ecosystem
[12:14] <jdstrand> zyga: same is true for private-users (aka private-ids)
[12:15] <zyga> jdstrand: perhaps I misunderstand how that answers one question: what is the GID of /usr/lib/snapd/snap-confine in the core snap
[12:15] <jdstrand> zyga: let me finish summarizing
[12:16] <jdstrand> zyga: with shared-users and private-users, they are prefixed with snap_
[12:16] <jdstrand> zyga: so claim a uid/gid range that is high and create the users/groups everywhere predictably
[12:17] <zyga> jdstrand: hmmm
[12:17] <zyga> jdstrand: I see
[12:17] <zyga> initially I was assuming that the "snapd" GID would be < 1000
[12:17] <jdstrand> zyga: for 'system-users' (aka system-global-ids) there is no snap_ prefix, so we can't guarantee that the username, group isn't taken
[12:17] <zyga> so a typical system gid value
[12:17] <zyga> jdstrand: so the new group would be snap_snapd?
[12:17] <zyga> with some high value?
[12:18] <jdstrand> so we would create these users on the fly if they don't exist, just like traditional packaging
[12:18] <jdstrand> then snapd does a lookup and injects the gid for that system into the policy
[12:19] <jdstrand> zyga: hold on
[12:19] <jdstrand> zyga: oh wait, this whole time you are talking about the setgid user
[12:19] <zyga> correct
[12:19] <jdstrand> zyga: I thought you were questioning the daemon user
[12:19] <zyga> ah, no
[12:19] <jdstrand>  /o\
[12:19] <zyga> sorry, maybe I was not clear about that
[12:19] <jdstrand> ok, please restate your concern
[12:20] <zyga> ok
[12:20]  * jdstrand flushes cache
[12:20] <zyga> given that the core snap is shared by all systems alike
[12:20] <zyga> the same applies to snapd snap
[12:20] <zyga> I was wondering what we should do about the value of GID on key executables like snap-confine and snap inside said snaps
[12:20] <zyga> my starting point was that I was trying to add a typical system group that has GID < 1000
[12:20] <jdstrand> kjackal: can you unsquashfs the snap you are trying to install and paste the squashfs-root/meta/snap.yaml
[12:20] <zyga> but coordinating that in the ecosystem is hard
[12:21] <zyga> jdstrand: perhaps there's a better way, I just started thinking about this
[12:22] <jdstrand> zyga: ok right, that is likely a sisyphean task (trying to coordinate a low gid)
[12:22] <ogra> jdstrand, would you mind letting https://dashboard.snapcraft.io/snaps/smart-ad-demo/revisions/1/ pass ? (it is gone into manual review, being a kiosk daemon using the x11 plug/slot combo for xwayland)
[12:22] <jdstrand> zyga: I'm not even sure the line of demarcation (1000) can be depended upon everywhere
[12:23] <jdstrand> ogra: sure. I think I have an idea about how to fix that in the base declaration
[12:23] <ogra> lovely !
[12:23] <zyga> jdstrand: perhaps the solution then is to not use the actual value
[12:23] <kjackal> jdstrand: Here it is: http://paste.ubuntu.com/p/hTWhshW239/ (learning new tricks)
[12:24] <jdstrand> ogra: can you create a forum topic, then I can express my idea?
[12:24] <zyga> jdstrand: but instead query if the calling user is a member of the snapd group
[12:24] <zyga> whatever that value is
[12:24] <zyga> and then deny or allow
[12:24] <ogra> jdstrand, willcooke do
[12:24] <ogra> HAHA
[12:24] <ogra> *will do
[12:24] <willcooke> :D
[12:24]  * willcooke does too
[12:24] <ogra> one tab too much
[12:24] <jdstrand> hehehe
[12:24]  * zyga notices a joke fly past him
[12:25] <jdstrand> that is probably the most humorous tab complete fail I've seen (at least in recent memory :)
[12:25] <ogra> :D
[12:27] <jdstrand> kjackal: that seems like a different snap.yaml from what you posted earlier
[12:28]  * jdstrand will examine it
[12:28] <jdstrand> zyga: yes, I think that is what you must do
[12:28] <zyga> jdstrand: thank you, I think, while unfortunate, it is unavoidable
[12:29] <zyga> hmm, mount-observe is not working?
[12:29] <zyga> https://paste.ubuntu.com/p/fpFsX36ZCb/
[12:29] <jdstrand> zyga: ie, yoy make it build time configurable what group snap-confine will verify. then the packager ensure that group exists
[12:29] <zyga> jdstrand: how does that help?
[12:29] <jdstrand> zyga: it actually is ok. this is how lots of stuff works like this. eg, libvirt, lxd, docker, etc on their socket
[12:29] <zyga> I mean, are you aiming for names other than "snapd"
[12:30] <jdstrand> zyga: something like this:
[12:30] <jdstrand> ./configure --with-group=whatever
[12:31] <jdstrand> then for that build it is hardcoded to use 'whatever'
[12:31] <jdstrand> then the suse packager does 'addgroup whatever'
[12:32] <jdstrand> then it is all fine
[12:32] <zyga> right, I understand that
[12:32] <zyga> I'm seeing to understand why we want that to be configurable
[12:32] <zyga> I assume that "whatever" is a string, not an int
[12:32] <jdstrand> zyga: yes, precisely
[12:32] <jdstrand> not a string
[12:32] <zyga> ooh
[12:32] <zyga> hmmmm
[12:33] <zyga> so how does this help with the core snap
[12:33] <zyga> how will the shared snap-confine be configured?
[12:33] <jdstrand> of course, that only works with the non-rexec snap-confine
[12:33] <zyga> or are you saying that the shared one should not enforce this check?
[12:33] <zyga> I see now
[12:33] <zyga> hmm hmm
[12:33] <zyga> I would rather do something that works in both cases
[12:33] <jdstrand> you can
[12:34] <jdstrand> --with-group=snapd
[12:34] <jdstrand> but then you'd want to make it so that if the group doesn't exist, use old behavior
[12:34] <zyga> indeed
[12:34] <jdstrand> otherwise new. that is a little weird
[12:35] <zyga> also sometimes snap-confine starts on the inside of a mount namespace
[12:35] <zyga> so all a bit more complex
[12:35] <jdstrand> suse doesn't want re-exec anyway afaik
[12:35] <zyga> but yeah, I think that's workable
[12:35] <jdstrand> a first step might be just to support non-rexec using --with-user
[12:35] <zyga> yes, that's right, but I prefer to create features that don't impede global reexec as a _technical_ possiblity
[12:35] <jdstrand> zyga: /etc always comes through though
[12:35] <zyga> oh, /etc
[12:36] <zyga> how I hate that we did that
[12:36] <jdstrand> cause this is in /etc/group
[12:36] <zyga> we should have not done that and instead forge special /etc
[12:36] <jdstrand> in this case it is a good thing :)
[12:36] <zyga> I think we should explore /etc being an empty tmpfs managed with mount backend
[12:36] <zyga> it could ship symlinks for the 5-6 files we want
[12:36] <jdstrand> well, in this case it doesn't have to be a bad thing
[12:36] <zyga> (those would go to hostfs)
[12:37] <zyga> yes, I agree, it's just something that I recalled now that you mentioned it
[12:37] <zyga> (in context of the opencl test snap)
[12:37] <jdstrand> zyga: that's not going to work for people. there is a *ton* of stuff in /etc that snaps want. not least of which system-file
[12:37] <zyga> jdstrand: but the things in /etc are not consistent
[12:38] <zyga> I know what you are saying but we should work towards *predictable* and managed /etc
[12:38] <zyga> many things will need to alter what /etc contains
[12:38] <zyga> currently this is hard
[12:38] <zyga> and it is done so in a way that is not benefiting from snap-update-ns features
[12:38] <jdstrand> zyga: true, but that's life. people configure host certs, nss, users, groups, etc, etc, etc, etc
[12:38] <zyga> ssl certs don't work fully, it only works on ubuntu and debian AFAIK
[12:39] <jdstrand> anyway. I have other things to do. we can discuss something like that over a beer sometime
[12:39] <zyga> yeah :)
[12:39] <zyga> I think we're in agreement
[12:39] <zyga> and I think I broke gid restore somehow
[12:39]  * zyga debugs
[12:39] <ogra> jdstrand, for later ... https://forum.snapcraft.io/t/kiosk-apps-with-xwayland-kiosk-launch-needing-an-x11-slot-that-makes-them-go-into-manual-review/10892
[12:40] <kjackal> jdstrand: I see you are using a test-k8s, is there a repository for this? Is it a fork of microk8s?
[12:42] <jdstrand> kjackal: I just took the yaml you pasted and changed the name and the 'command' lines
[12:42] <jdstrand> it isn't a thing
[12:43] <jdstrand> I'm now looking at your unsquashed one
[12:43] <kjackal> thanks
[12:47] <jdstrand> ogra: I did smart-ad-demo
[12:48] <ogra> thx !
[12:48] <jdstrand> kjackal: I can't reproduce
[12:49] <jdstrand> kjackal: did you snap try or use a different snapd or anything else that might be relevant?
[12:50] <jdstrand> kjackal: can you perhaps try to install and connect everything in a clean vm?
[12:50] <kjackal> I am doing a snapcraft cleanbuild on the branch I pasted above and then snap install ./microk8s_latest.snap --dangerous
[12:50] <jdstrand> kjackal: what does 'snap list microk8s' say?
[12:52] <kjackal> jdstrand: http://paste.ubuntu.com/p/b4jKFyB2Y7/
[12:54] <jdstrand> kjackal: please 'snap remove microk8s' then paste: ind /var/lib/snapd -name "*microk8s*"
[12:54] <kjackal> jdstrand: I now see that the error I get is presents on any interface i am trying to connect https://pastebin.ubuntu.com/p/vVx8ZppVJX/
[12:54] <jdstrand> s/ind/find/
[12:56] <Chipaca> profile (null) for life
[12:58] <kjackal> jdstrand: here is the find in /var/lib/snapd
[12:58] <kjackal> https://pastebin.ubuntu.com/p/jTRkZYFPW2/
[12:59] <mup> PR snapd#6715 opened: interfaces/builtin/desktop: fonconfig v6/v7 cache handling on Fedora <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6715>
[12:59] <kjackal> https://pastebin.ubuntu.com/p/3ggcdDVFvq/
[12:59] <jdstrand> kjackal: ok, good. now install and do the snap connects one by one until you see the first error, then show me that series of commands
[13:02] <kjackal> jdstrand: Here it is https://pastebin.ubuntu.com/p/wgg7qsfyJq/
[13:04] <jdstrand> kjackal: can you paste /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet
[13:05] <andyrock> Hi! Is there a way to manually put snapd in the status that triggers https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bug/1824188 ?
[13:05] <mup> Bug #1824188: Software tab is empty on clean 19.04 install <amd64> <apport-bug> <disco> <rls-dd-incoming> <gnome-initial-setup (Ubuntu):Confirmed> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1824188>
[13:05] <kjackal> jdstrand: here it is http://paste.ubuntu.com/p/VMVTNpm4CW/
[13:05] <andyrock> otherwise debugging a fix is a mess
[13:06] <jdstrand> kjackal: ok, the profile looks ok. let me try to parse that in different place. gimme a minute
[13:07] <jdstrand> kjackal: this is just a standard bionic system. not in a container or anything?
[13:07] <kjackal> no, that is my 18.04 laptop
[13:08] <kjackal> I have a Vm on aws running if you want me to try
[13:09] <jdstrand> no
[13:11] <mup> PR snapcraft#2526 closed: Release changelog for 3.4 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2526>
[13:18] <jdstrand> kjackal: ok, please remove microk8s, then install, then do:
[13:18] <jdstrand> sudo snap connect microk8s:k8s-kubeproxy :kubernetes-support
[13:19] <jdstrand> then: /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet /tmp/before
[13:19] <jdstrand> sudo snap connect microk8s:k8s-kubelet :kubernetes-support
[13:19] <jdstrand> then:
[13:19] <jdstrand> cp /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet /tmp/after
[13:19] <jdstrand> kjackal: I missed the 'cp' in the 'before'
[13:21] <kjackal> trying it now
[13:22] <jdstrand> kjackal: fyi, I can't reproduce in my bionic vm either
[13:22] <jdstrand> kjackal: once you have before and after, please paste: diff -Naur /tmp/before /tmp/after
[13:26] <kjackal> Yes I understand jdstrand, no worries. I might have something wron on my system. Here is the diff: https://pastebin.ubuntu.com/p/TXpxKVm9X4/
[13:27] <jdstrand> kjackal: ok, can you paste both before and after?
[13:28] <kjackal> jdstrand: Here is the before: http://paste.ubuntu.com/p/qqcFm9Zxqk/
[13:29] <kjackal> jdstrand: here is the after: http://paste.ubuntu.com/p/HZFTPFmxk5/
[13:29] <jdstrand> ok
[13:29] <jdstrand> the profile looks fine
[13:30] <jdstrand> can you make the snap available to me? perhaps via wormhole?
[13:30] <jdstrand> (snap install wormhole ; wormhole send /path/to/thing)
[13:30] <dot-tobias> kyrofa / jdstrand : I'd like to use MySQL in a snap and found https://kyrofa.com/posts/snapping-nextcloud-mysql incredibly helpful (thanks kyrofa!) Just before I start adapting the conf files and pull all the customizations + patches in my snap: Is it still the case that snapd prevents setpriority calls, or does process-control (https://github.com/snapcore/snapd/blob/da75b241f517d11d38f620e1d71a899e36f2c037/interfaces/builtin/process_control.
[13:30] <dot-tobias> go#L50) work for this?
[13:31] <jdstrand> kjackal: if using wormhole, privmsg me the code
[13:32] <jdstrand> dot-tobias: by default a snap may setpriority to >= 0
[13:32] <jdstrand> dot-tobias: if it tries < 0, the call is denied but the application is not killed or anything
[13:32] <jdstrand> dot-tobias: process-control allows for < 0
[13:34] <jdstrand> kjackal: ok, downloading. it'll be ~10 minutes
[13:36] <jdstrand> kjackal: while we are waiting, what is 'apt-cache policy apparmor'
[13:36] <roadmr> jdstrand: so a question - if there's no explicit slot configuration, a snap will allow any autoconnection from same-publisher snaps. But if there's explicit "allow-auto-connection" configuration, then it will only allow the explicit ones and deny anything else, even from same publisher. Does this sound correct?
[13:37] <jdstrand> roadmr: it depends on the interface. that is how content is setup, yes
[13:37] <roadmr> jdstrand: yes, the interface in question is content
[13:38] <jdstrand> roadmr: if the snap decl says anything about the constraint (in this case auto-connection), only the snap declaration is used. there is no merging or falling back to the base decl
[13:38] <kjackal> jdstrand: Here is the apt apparmor policy http://paste.ubuntu.com/p/6dkCJmxNgf/
[13:39] <roadmr> jdstrand: ah, got it - that explains it very clearly
[13:39] <dot-tobias> jdstrand: Ok, thanks. So for me (with next-to-none knowledge about this) this means that mysql-server should work OOTB without the patch that kyrofa applies for the Nextcloud snap: https://github.com/kyrofa/mysql-server/commit/dd0e4e497794da2650536097655f4bf732b261a9 (you added the process-control ~ 1 month after kyrofa's blog post which stated that there is no suitable interface for setpriority calls – or did snapd's behavior change from
[13:39] <dot-tobias>  kill to a mere denial?)
[13:39] <jdstrand> roadmr: it is very easy to get the content stuff wrong. perhaps privmsg me and describe what you are trying to do?
[13:39] <roadmr> jdstrand: so this snap has 10 content interface slots, we added config for 4 of them which a cross-pub snap needs; and of course per the above,it means in order to allow same-publisher snaps to auto-conn to the other 6 interfaces I'll need to add those explicitly too, even though they weren't needed before
[13:40] <roadmr> jdstrand: sure! I'll hit you in a sec
[13:41] <cwayne> sorry we make things so tricky :)
[13:41] <jdstrand> dot-tobias: I don't have the dates at hand, but yes we changed from kill to just EPERM. whether mysql works depends on how it handles the error condition
[13:59] <pedronis> mvo: cachio: this one I reviewed a while ago, it just needs some tweaks: https://github.com/snapcore/snapd/pull/6594
[13:59] <mup> PR #6594: [RFC] tests: run smoke tests on (almost) pristine systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/6594>
[14:02] <cachio> pedronis: sure, I'll take a look, thanks
[14:03] <mup> PR snapd#6716 opened: store: serialize the acquisition of device sessions <Created by pedronis> <https://github.com/snapcore/snapd/pull/6716>
[14:10] <mborzecki> heh, so i could not build spread, because context was removed from my tree of golang.org/x/net :/
[14:12] <jdstrand> kjackal: ok, with your snap in a vm, I am able to reproduce
[14:12] <mup> PR snapd#6643 closed: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6643>
[14:13] <kjackal> jdstrand: I will not be surprised if its something wrong I am doing
[14:14] <jdstrand> I'm not convined it is you
[14:14] <jdstrand> but now I can debug
[14:15] <jdstrand> the hooks
[14:15] <jdstrand> the hooks are getting the profiles added
[14:15] <jdstrand> both of them
[14:16] <jdstrand> zyga: ^
[14:16] <zyga> ah
[14:16] <zyga> indeed!
[14:16] <zyga> the question is, why should the hooks behave differently from apps that have no plugs assigned
[14:16] <jdstrand> kjackal: for now, you can workaround this be removing the hooks. this is a bug in snapd
[14:16] <zyga> I would argue they should not, rigth?
[14:16] <zyga> pstolowski: ^ remember the hooks and interfaces?
[14:16] <jdstrand> zyga: they 100% should not imo
[14:17] <zyga> jdstrand: I'll look now
[14:17] <kjackal> ok, jdstrand, I will see what i can do, thanks
[14:17] <zyga> I see the bug
[14:17] <zyga> man
[14:18] <jdstrand> zyga: hooks can plugs stuff, they need to behave like apps
[14:18] <jdstrand> I think we agree
[14:18] <zyga> yes
[14:19] <jdstrand> fyi, this is what I saw: https://paste.ubuntu.com/p/WhJQpHjKVQ/
[14:19] <jdstrand> after I connected the second one
[14:19] <jdstrand> snap.microk8s.daemon-kubelet and snap.microk8s.daemon-proxy correctly only have the one systemd_run, but all the hooks have two
[14:21] <pstolowski> zyga: what about them?
[14:21] <zyga> pstolowski: wait a sec
[14:21] <zyga> patch upcoming
[14:22] <jdstrand> zyga: heh, I was gonna ask if you or someone else would work on it cause kjackal needs it, but hey, you answered that :)
[14:23] <zyga> yep
[14:23] <zyga> it's in my head
[14:23] <jdstrand> zyga: thank you :)
[14:23] <zyga> jdstrand: I was working on uid/gid restore but that's more of a maze than I wanted
[14:23] <zyga> because of random places we raise/lower privs
[14:23] <jdstrand> zyga: oh yes-- that is very deliberately setup
[14:24] <zyga> yes
[14:24] <zyga> but a bit mysterious where we drop permanently
[14:24] <kjackal> jdstrand zyga: Thank you. I have to admit I kind of understand how profiles are used in the high level but I do not know how snapd manipulates them. Where should I go to learn more about the internals? Look at the snapd code?  Which snap would you consider the cleanest one?
[14:24] <zyga> currently seccomp code does that
[14:24] <zyga> anyway, you will surely review the patch
[14:24] <zyga> kjackal: read snapd code
[14:24] <zyga> kjackal: specifically interfaces/*
[14:24] <zyga> kjackal: I'm happy to answer questions
[14:24] <jdstrand> zyga: well, that is at the finish line :) note that my daemon user branch changes this a little
[14:24] <kjackal> cool, thanks zyga
[14:25] <ijohnson> hey zyga, any chance you or someone else could take another look at https://github.com/snapcore/snapd/pull/6697 ?
[14:25] <mup> PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
[14:25] <zyga> kjackal: the general idea is that snapd collects pieces of information in Specification objects, one for each security backend; each backend knows how to materialize a specification into a set of files that govern the sandbox
[14:25]  * zyga afk for a sec, sorry
[14:25] <zyga> ijohnson: queued
[14:25] <jdstrand> ijohnson: fyi, that is in my queue. I have rather strong opinions on it
[14:25] <ijohnson> zyga: thanks!
[14:26] <jdstrand> ijohnson: but I have to dig up all the reasons why I dislike it so much
[14:26] <jdstrand> zyga: fyi ^
[14:26] <ijohnson> jdstrand: :-( but okay
[14:26] <ijohnson> jdstrand: thanks for taking a look at it
[14:27] <jdstrand> it isn't so much the PR as the feature in general
[14:27]  * Chipaca looks forward to jdstrand's Sonnet 43
[14:27] <jdstrand> I mean, the PR too, but the PR insofar as what systemd requires I don't like
[14:30] <jdstrand> Chipaca: hehe. Sometimes I feel more Faulkner than Shakespeare
[14:30]  * ijohnson returns the systemd-notify themed gift bask bought for jdstrand
[14:30] <ijohnson> *basket
[14:31] <jdstrand> ijohnson: :) I'm not going to get to it today, but I will get to it. I want to be able to provide a path forward which requires a bit of study and archaeology
[14:32] <ijohnson> jdstrand: thanks for the due diligence
[14:33] <jdstrand> kjackal: I suggest as a user, reading the forum 'doc' category for things interface related
[14:33] <kjackal> thanks
[14:34] <jdstrand> kjackal: eg https://forum.snapcraft.io/search?q=interfaces%20category%3A15
[14:35] <jdstrand> kjackal: also, again, if you remove your hooks for now, you can proceed with your work. watch for zyga's PR and when it is committed, the fix should be in edge in the next day or so after. then you can 'snap refresh core --edge' and add back your hooks
[14:35] <zyga> IRL interrupt
[14:36] <zyga> looking after Lucy
[14:36] <zyga> (baby)
[14:36] <jdstrand> zyga: cute name :)
[14:52] <Chipaca> jdstrand: it's short for Lucifer
[14:52] <Chipaca> (probably)
[14:59] <zyga> jdstrand: Łucja :)
[14:59] <zyga> lol Chipaca
[15:02] <zyga> back now, she's no longer crying :)
[15:03] <zyga> back to that hook bug
[15:05] <jdstrand> hehe
[15:11] <mvo> pstolowski: want to join #ubuntu-desktop ? the topic of fc-cache came up
[15:12] <pstolowski> mvo: sure
[15:13] <mvo> Chipaca: the desktop team is asking if we can reply to queries while seeding like get the list of categories
[15:13] <Chipaca> mvo: yes we can
[15:13] <Chipaca> mvo: as long as they retry
[15:13] <mvo> Chipaca: aha, so they try to early?
[15:14] <Chipaca> mvo: the problem isn't their querying while seeding (although "list of installed snaps" when it's in the middle of installing will be racy)
[15:14] <mvo> Chipaca: want to join #ubuntu-desktop as well :)
[15:14] <Chipaca> sure
[15:17] <mup> Bug #1823988 changed: CAP_NET_ADMIN not being provided with the recommended plugs <Snappy:Invalid> <https://launchpad.net/bugs/1823988>
[15:26] <cachio> pedronis: PR updated
[15:34] <zyga> kjackal: hey, would you mind reporting the bug please
[15:34] <zyga> kjackal: I'm just working on the commit message and I'd love to reference a bug number
[15:35] <kjackal> ok LP zyga?
[15:35] <zyga> kjackal: please :-)
[15:35] <zyga> on snapd
[15:36]  * cachio lunch
[15:44] <kyrofa> dot-tobias, I'm sorry for the delay. Indeed, as jdstrand mentions, they've changed from kill to errno. However, my understanding is that it depends on kernel features that aren't available everywhere, and the Nextcloud snap is used on a number of operating systems, so I chose not to rely on that behavior
[15:45] <jdstrand> kyrofa: almost. the we do errno always. what is dependent on kernel features is logging with errno
[15:45] <jdstrand> kyrofa: hi btw :)
[15:46] <jdstrand> we don't kill anymore anywhere
[15:46] <kyrofa> jdstrand, hey! So to clarify, the behavior should be consistent across distros, but the denial itself may not show up in the syslog?
[15:46] <jdstrand> kyrofa: exactly
[15:46] <kyrofa> That's good to know, I'm tired of maintaining that patch
[15:47] <jdstrand> kyrofa: I didn't look at the patch. please note if they fail on errno != 0, a patch is still needed
[15:48] <jdstrand> that seems pretty unusual with setpriority though
[15:51] <zyga> kjackal: bug number? :)
[15:51] <kyrofa> jdstrand, it just calls setpriority and then getpriority to see if the setting took. If not, it whines and moves on
[15:54] <kyrofa> dot-tobias, note that it tries to use -20 as the priority
[15:54] <roadmr> why is snap sign being a jerk to me :(
[15:54] <roadmr> error: cannot sign assertion: cannot sign using GPG: /usr/bin/gpg --personal-digest-preferences SHA512 --default-key 0x65A81F29127BF1AC94AA1A4B735216CA804762D0 --detach-sign failed: exit status 2 ("gpg: signing failed: No such file or directory\ngpg: signing failed: No such file or directory\n")
[15:54] <roadmr> cat whatever.json | snap sign -k my-key-id
[15:56] <Chipaca> roadmr: hmm
[15:56] <Chipaca> roadmr: do you have /usr/bin/gpg?
[15:56] <roadmr> $ which gpg
[15:56] <roadmr> /usr/bin/gpg
[15:56] <Chipaca> actually the 'gpg: signing failed' thing seems to be from gpg itself
[15:56] <Chipaca> hm
[15:56] <Chipaca> roadmr: do you have ~/.snap/gnupg/ ?
[15:58] <kjackal> zyga: just came out of a meeting, opening the bug now
[15:58] <roadmr> Chipaca: yes, there it is
[15:58] <roadmr> Chipaca: funny part is - this worked like 30 minutes ago
[15:59] <roadmr> a case of run it once, it works, run it again, it fails
[15:59] <roadmr> ah but interestingly - that key (--default-key 0x65A81F29127BF1AC94AA1A4B735216CA804762D0) does NOT exist
[16:01] <roadmr> oh I lie, there it is
[16:01] <Chipaca> roadmr: you can poke into it by hand using gpg --homedir ~/.snap/gnupg
[16:01] <Chipaca> roadmr: maybe it's expired or sth?
[16:01] <roadmr> Chipaca: I did, I can see the key; not expired, just created it 1 hour ago
[16:01] <Chipaca> roadmr: are you secretly time-traveling
[16:02] <roadmr> busted :(
[16:02] <Chipaca> roadmr: can you try strace'ing it?
[16:03] <Chipaca> roadmr: 'snap sign' is client-side only, so just strace the snap process should give you results
[16:03] <zyga> kjackal: even a small report, we can expand on it later
[16:04] <roadmr> cat pi3.json | strace -o ouch snap sign -k what201904122
[16:04] <kjackal> zyga: here it is https://bugs.launchpad.net/snapd/+bug/1824557
[16:04] <mup> Bug #1824557: Apparmor "Multiple definitions for hat systemd_run" in kubernetes-support interface <snapd:New> <https://launchpad.net/bugs/1824557>
[16:05] <zyga> thank you
[16:06] <roadmr> Chipaca: http://paste.ubuntu.com/p/2nmbnJwDhW/ makes no sense to me
[16:06] <zyga> kjackal, jdstrand: https://github.com/snapcore/snapd/pull/6717
[16:06] <mup> PR #6717: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>
[16:07] <mup> PR snapd#6717 opened: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>
[16:08] <Chipaca> roadmr: is that with -f ?
[16:09] <roadmr> Chipaca: nope; just ran with -f and it's stuck now haha
[16:10] <Chipaca> roadmr: ah, yes it gets stuck unless you tell it not to trace select iirc
[16:11] <Chipaca> roadmr: -e '!select,pselect6,_newselect,clock_gettime'
[16:11] <roadmr> Chipaca: http://paste.ubuntu.com/p/dzsDWwRhw4/
[16:13] <Chipaca> roadmr: i see something about pinentry telling gpg 'no such file or directory'
[16:13] <roadmr> whats pinentry? :)
[16:14] <Chipaca> roadmr: the thing gpg talks to to prompt you for keys
[16:14] <roadmr> Chipaca: ah, let me try using --passphrase to bypass that
[16:14] <roadmr> again, weird because it worked fine (tm) the first time
[16:15] <roadmr> oh I can't use --passphrase when invoking snap sign :(
[16:15] <Chipaca> roadmr: maybe seahorse went away?
[16:15] <roadmr> whats seahorse :)
[16:15] <Chipaca> roadmr: (it might be called something else now)
[16:15] <Chipaca> roadmr: the gnome pinentry
[16:15] <roadmr> that's the graphical key thingy, right?
[16:15] <Chipaca> y
[16:15] <roadmr> shouldn't, I'm SSHing into a headless box
[16:16] <roadmr> let me try disabling x forwarding just in case
[16:16] <roadmr> Chipaca: yay it worked with x forwarding disabled \o/
[16:16] <Chipaca> roadmr: magic
[16:17] <roadmr> Chipaca: sorry then, it appears it was my weird env :( mystified that it worked the first time
[16:17] <roadmr> thanks so much Chipaca !
[16:17] <Chipaca> roadmr: depending on how it worked the first time, maybe the remote agent broke, or maybe agent forwarding died
[16:17] <Chipaca> maybe when you first connected you didn't have a remote agent and then you did
[16:18]  * Chipaca is just pulling guesses out anatomically improbably places
[16:18] <Chipaca> improbable*
[16:18] <roadmr> all these things talking to each other can fail in intesting ways
[16:19] <Chipaca> with non-obvious silent fallbacks
[16:20] <pedronis> gpg could at least print the relevant file name :/
[16:22] <roadmr> my thought exactly pedronis  :) having to strace to figure that out was interesting
[16:28] <Chipaca> pedronis: but it wasn't a file name that failed; it's the agent saying "yes i launched pinentry" and then "nope"
[16:28] <Chipaca> pedronis: lines 5713-5716 in http://paste.ubuntu.com/p/dzsDWwRhw4/
[16:30] <Chipaca> (no i don't know that protocol well enough to know if that was even close to an accurate rendition of what went down)
[16:32] <pedronis> Chipaca: didn't gpg print a ENOENT without the filename
[16:32] <Chipaca> pedronis: it looked like it but wasn't
[16:32] <Chipaca> (bad on gpg yes)
[16:36] <jdstrand> kjackal: zyga's PR shows another workaround: you can define your hooks explicitly in the yaml instead of implicitly. this would also workaround the issue
[16:36] <jdstrand> (according to the PR)
[16:49] <zyga> jdstrand: good observation, correct!
[16:50] <zyga> jdstrand: I'm reworking the PR a little, fixed the bug that pedronis showd, adding tests now
[16:58]  * jdstrand nods
[17:45] <zyga> pedronis: re, I pushed a fix and the updated test
[18:31] <fluut> I'm trying to run a snap and I get "cannot move to directory with preserved namespaces: Permission denied" The only place that string exists, according to google, is in the code. Any ideas?
[18:32] <xnox> Chipaca, was it you who asked about user sessions being allowed the other day? the unit is called systemd-user-sessions.service
[18:32] <xnox> it was something about snapd
[18:42] <kjackal> thanks zyga
[18:42] <kjackal> thanks jdstrand
[19:02] <zyga> re
[19:02] <zyga> fluut: hey
[19:02] <zyga> fluut: I can help, please tell me more
[19:02] <zyga> fluut: start with snap version output, also if you can, run dmesg | grep DENIED and show me what it prints
[19:08] <zyga> fluut: or if you can, report a bug with that information and hand me the URL, you can do that on https://bugs.launchpad.net/snapd/+filebug
[19:36]  * cachio afk
[19:52] <zyga> jdstrand: hey, if still around, could you please look at https://github.com/snapcore/snapd/pull/6714/files
[19:52] <mup> PR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>
[19:52] <zyga> it's +89,-64, mostly a test revamp but really crucial permission tweak
[20:09]  * zyga EODs
[20:25] <Chipaca> xnox: I didn't ask, per se, but yes it was me :-)
[20:25] <Chipaca> xnox: thanks


[01:31] <stgraber> hmm http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/edubuntu-dvd/latest/livecd-20110223-amd64.out is still failing though I can't reproduce the issue on my laptop
[01:31] <stgraber> anyone knows what's wrong ? (doing an apt-get install with all the mentioned packages work fine on up to date natty amd64)
[01:36] <stgraber> hmm, actually I can reproduce the ghostscript part of it, but not the rest
[02:10] <stgraber> nevermind, it's fixed
[02:11] <stgraber> for some reason we had two packages in our seeds that came are in multiverse
[02:12] <stgraber> I just removed them, daily should be fine again tomorrow, though it'd be nice if we could get a respin so we can test our new installer plugin :)
[17:09]  * ogra tickles skaet_
[17:09]  * skaet_ giggles
[17:10] <ogra> skaet_, when do you plan to make FF take effect tomorrow ?
[17:10] <ogra> the unity-2d guys just let me know they might be late with their last upstream version tomorrow (and i then still need to package it)
[17:12] <ogra> (taking about UTC times here)
[17:12] <skaet_> ogra,  I was planning to send it out around my lunch time, which should be the end of your day.
[17:12] <ogra> ah, perfect, that should fit fine then, thanks
[17:13] <skaet_> :)
[17:43] <hggdh> may I get anyone interested in https://bugs.edge.launchpad.net/ubuntu/+source/mountall/+bug/723482 ?
[17:43] <ubot4> Launchpad bug 723482 in mountall (Ubuntu) "system hangs on boot after updates from 2011-02-22 (affects: 2) (heat: 14)" [High,New]
[17:49] <ev> robbiew, skaet_ feature freeze exception request: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/723849
[17:49] <ubot4> Launchpad bug 723849 in ubiquity (Ubuntu) "Feature freeze exception for ask page remodeling and package preservation option (affects: 1) (heat: 8)" [Undecided,New]
[17:50] <robbiew> ev: ack
[18:17] <ScottK> ev: It would be useful to know when you think you can land the changes you're requesting FFe for (best to put it in the bug).
[18:21] <ev> ScottK: updated
[18:30] <skaet_> ev, which milestone are you targetting with this?  alpha 3 or beta?
[18:50]  * cjwatson would appreciate NEWage of libpci3-udeb and biosdevname, if anyone has some time
[19:13] <skaet_> reminder:  Feature Freeze for Natty will be at 1600 UTC on Feb 24th.
[19:14] <skaet_> s/1600/1800/
[19:14] <skaet_> ev,  by the way,  very nice new interface for the partitioner.   :)


[01:34] <leftyfb> sarnold: told you ;)
[01:35] <sarnold> leftyfb: yup :) it sure smelled trolly but I wanted to believe. sigh.
[01:36] <leftyfb> I've been dealing with these people for over 20 years. I literally have a troll on another network still at it after 20+ years, though not nearly as much as back in the day
[01:37] <leftyfb> they're pretty easy to spot
[01:37] <leftyfb> sometimes they get clever and pretend for a while. But it always comes out in the end
[01:37] <leftyfb> as you saw
[03:34] <lotuspsychje> good morning


[22:19] <oerheks> [20:43:19] * ChanServ removes channel operator status from catties
[22:19] <oerheks> oops


[08:01] <dholbach> good morning
[08:11] <MooDoo> morning all
[08:17] <elfy> morning peeps
[11:16] <dholbach> dpm, do we need to start to do uos planning soon?
[11:17] <dpm> dholbach, probably. Did we set up the dates already?
[11:17] <dholbach> yes
[11:17] <dholbach> 2015-05-05 to 2015-05-07
[11:17] <dholbach> so still 8 weeks


[00:19] <DanaG> Ooh, finch uses the unicode ☎ for status.
[01:17] <calc> tytso is here at UDS telling us about ext4 :-)
[01:25] <calc> now talking about the bugs still in ext4
[01:29] <RAOF> calc: Oooh.  Any doosies?
[01:30] <calc> RAOF: some data corruption issues in some cases with sparse files like with bittorrent, bdb, etc
[01:30] <calc> but they are working on them
[01:31] <RAOF> Sounds fun!  Every one loves data corruption in their fs :)
[01:31] <calc> yea, heh
[01:33] <crimsun> RAOF: what?  no reiserfs on your woody box?
[01:34] <calc> he also does not recommend mounting ext3 with ext4 driver
[01:34] <calc> since its not tested well yet
[01:36]  * RAOF doesn't /have/ a woody box.
[01:37] <RAOF> Marvelous!
[01:38] <calc> but it appears that ubuntu will allow installing with ext4 in jaunty but not the default
[01:38] <calc> so anyone who wants to play with fire can get burned ;-)
[01:41] <RAOF> Nifty.  It's already possible to format and mount ext4, but a little installer love will let more people get burned!
[01:42] <calc> yea :)
[01:44] <calc> there is actually better support for SSD in ext4 also
[01:45] <calc> it tells the SSD that the block is no longer used so it can reuse it for wear leveling
[04:42] <karlp> wait not supported? as in i can't ask for help in this channel?
[04:42] <karlp> or as in not supported for #ubuntu ? (which is obvious)
[04:51] <karlp> when i start kdm, my usb {keyboard and mouse} are completely unusable
[04:52] <karlp> but on the console, it's perfectly fine
[04:52] <karlp> i'll updating+upgrading again
[04:55] <RAOF> karlp: Sounds like an X input-hotplug issue
[04:56] <karlp> RAOF: how would i fix it? it worked fine with intrepid and i, out of the blue, decided to update to jaunty, against better judgement
[04:57] <RAOF> It'd be useful to see your /var/log/Xorg.0.log
[04:57] <RAOF> And your xorg.conf while you're at it.
[04:58] <karlp> grep '(EE)' /var/log/Xorg.0.log outputs just: (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[04:58] <karlp> ah, but the WW is where it's out
[04:58] <karlp> for some reason it disables it
[04:59] <karlp> AllowEmptyInput is on
[05:02] <karlp> serverflags section... going to change it to false
[05:02] <karlp> rather add it to say it's false
[05:02] <karlp> i didn't add that in but i suspect the update must have
[05:03] <RAOF> The actual files would be useful :)
[05:04] <RAOF> pastebinit can be your friend.
[05:05] <karlp> yeah, well i sort of half-asked the question. i'm going to try to figure it out first before i bother you further
[05:05] <karlp> i just expected it's a package problem and didn't even think it could be a configuration file issue
[05:05] <karlp> i guess technically the configuration file is part of the package....
[05:05] <RAOF> Ish.  It's a bit tricky.
[05:07] <karlp> man, you ubuntu devs are insane. working non-stop... i just updated less than 5 minutes ago and it's already got more than a few megabytes worth of updates grabbed
[05:09] <karlp> fixed it :D
[05:09] <karlp> later
[07:03] <histo> think flash 64bit will maek it in to juanty?
[07:04] <rww> histo: it's in jaunty. It's just broken right now due to a bug involving a missing copy of libuuid1
[07:04] <histo> ahh Haven't yet installed jaunty maybe on a virtual machine for testing .
[07:04] <andersk> No, that's 32-bit flash with nspluginwrapper that's broken by the libuuid1 bug.
[07:04] <andersk> Adobe released a native 64-bit plugin that hasn't made it into Jaunty yet.
[07:05] <rww> andersk: oh, really? huh, i need to keep up better with my non-free stuff
[07:06] <andersk> http://blogs.adobe.com/penguin.swf/2008/11/now_supporting_16_exabytes.html
[07:08] <rww> heh, interestinfg
[07:10] <stdin> it's pre-release, so it won't be in jaunty until it's officially released
[08:30] <BUGabundo_work> I know this is stupid to ask
[08:30] <BUGabundo_work> but did any one here installed todays KDEPIM updates?
[09:11] <BUGabundo_work> humm even with a Nvidia Compiz efects seem slow and dragging!
[09:16] <lemonade_> which effects?
[09:20] <BUGabundo_work> several... windows transition, cube, etc
[11:11] <BUGabundo_work> and you lemonade?
[16:06] <Le-Chuck_ITA1> Hi there. I am testing jaunty and I noticed that the upgraded xorg and kernel are much slower than the ones provided on the cds. Is this considered normal or is it a bug? Moreover, I can use the previous kernel but how can I revert to the xorg that is provided on the cds'
[16:06] <Le-Chuck_ITA1> ?
[16:13] <BUGabundo_work> hi Le-Chuck_ITA1
[16:13] <BUGabundo_work> I mention exactly that today here in the #
[16:13] <Le-Chuck_ITA1> very good so it's not only my problem
[16:13] <BUGabundo_work> my guess: it aint finned tuned yet
[16:13] <Le-Chuck_ITA1> is it fundamentally newer than the xorg on the cds?
[16:14] <Le-Chuck_ITA1> cd
[16:15] <Le-Chuck_ITA1> A question to everybody: is it actually feasible to install some snapshotting system (LVM snapshots???) and then just try to upgrade, and revert if something goes wrong? What are the practical problems?
[16:15] <BUGabundo_work> I don't understand your question
[16:15] <BUGabundo_work> Le-Chuck_ITA1: most of the people here are at UDS-Jaunty
[16:15] <Le-Chuck_ITA1> BUGabundo_work: it seems to me that the version of xorg on the jaunty alpha1 image is faster than the one
[16:16] <BUGabundo_work> so don't count on getting much atteion
[16:16] <Le-Chuck_ITA1> ok so the simplest question is: "is the version on the installation cd faster for you?"
[16:16] <BUGabundo_work> do know
[16:16] <BUGabundo_work> I've been using jaunty eversince the tool chains were open
[16:16] <Le-Chuck_ITA1> yes and was it faster then?
[16:17] <IdleOne> Le-Chuck_ITA1, best thing would be to run new "snapshots" in VM and see if it works for you but I am not sure that is what you want
[16:18] <Le-Chuck_ITA1> IdleOne: hmm I would not test hardware drivers then
[16:24] <Le-Chuck_ITA1> well, I will reinstall hardy for now :)
[16:27] <BUGabundo_work> why not ibex?
[16:28] <Le-Chuck_ITA1> BUGabundo_work: actually I wanted to say intrepid, I already have hardy which is the latest version that works well
[16:28] <Le-Chuck_ITA1> intrepid was my "beta testing"
[16:28] <BUGabundo_work> ibex is the latest stable version
[16:28] <BUGabundo_work> jaunty is development
[16:28] <Le-Chuck_ITA1> Yes I know, but it does not work so well for me in some respect :)
[16:28] <BUGabundo_work> file bugs for it!
[16:28] <BUGabundo_work> let the devs know about them
[16:29] <Le-Chuck_ITA1> BUGabundo_work: I have a hundred of open bugs :P
[16:29] <Le-Chuck_ITA1> but if they aren't closed I can't work well, you know. In any case I am using ibex on two other machines where it's just working fine
[16:30]  * Le-Chuck_ITA1 thinks usb-creator is a great tool
[16:33] <Le-Chuck_ITA1> BUGabundo_work: do you remember if the system was faster when you started using jaunty?
[16:33] <BUGabundo_work> humm
[16:33] <BUGabundo_work> back then the nvidia driver didn't work
[16:34] <BUGabundo_work> so I can compare my experince with Compiz
[16:34] <BUGabundo_work> which is the single thing that I find slower!
[16:40] <Le-Chuck_ITA1> BUGabundo_work: I thought so but also using metacity X is slo
[16:40] <Le-Chuck_ITA1> w
[16:40] <Le-Chuck_ITA1> the rest of the system is very fast especially if compared to hardy
[16:40] <Le-Chuck_ITA1> but it's time to reboot now :) I just upgraded some X libraries
[16:40] <Le-Chuck_ITA1> bye and see you
[17:02] <FFForever> how bad do things get broken =D
[17:12] <FFForever> any news on but 272247 and jaunty?
[17:26] <ikonia> FFForever check the bug report in stead of asking someone to check it for you
[17:26] <ikonia> FFForever: you know the bug report so look it up
[17:27] <FFForever> ikonia, i did look it up there is nothing that says it still affects jaunty or not =( ive been reading it over and over =(
[17:27] <ikonia> possibly because it doesn't or it would be logged, or maybe it's not been tested on jaunty yet as it's still in heavey flux
[17:28] <ikonia> FFForever: it's not going to say "doesn't effect jaunty" it will only say "does effect jaunty" if it does
[17:29] <FFForever> how stable is jaunty i know there are package problems but they normally get cleared up in a day or 2 right?
[17:29] <ikonia> no
[17:29] <ikonia> they don't get cleared up in a day or two
[17:29] <ikonia> it's in a state of flux
[17:29] <ikonia> could work today, break tommorow, broke for a week, fixed for 2 days, broke for a day etc - it's unknown
[17:30] <FFForever> how long normally till ubuntu+1 reaches some sort of beta/stableness?
[17:30] <BUGabundo_work> eheh FFForever only one week past release!
[17:30] <BUGabundo_work> LOL
[17:30] <ikonia> when the "beta" or Release candidate are out
[17:31] <FFForever> BUGabundo_work, lol....
[17:39] <genii> I wonder why people run pre-releases of intermediate versions anyhow
[17:40] <genii> (as main OS, not on seaparete partition or sandboxed somehow)
[17:40] <BUGabundo_work> genii: Full Time testing??
[17:42] <ikonia> genii: because they are foolish
[17:43] <BUGabundo_work> oh come on ikonia... didn't expect that from you!
[17:44] <ikonia> what ?
[17:44] <ikonia> BUGabundo_work: people running development releases and expecting it to work or not break as their main OS are being foolish
[17:44] <ikonia> more so when the releases are not even at a beta stage
[17:44] <BUGabundo_work> hey...
[17:45] <BUGabundo_work> that's another thing!
[17:45] <BUGabundo_work> I know that running alpha it can and WILL break...
[17:45] <ikonia> that's what I said, it's a foolish thing to do
[17:45] <BUGabundo_work> no
[17:45] <ikonia> BUGabundo_work: I didn't say you, I said people who run it as a main release
[17:45] <BUGabundo_work> what you said is that running it is foolish
[17:45] <ikonia> you've been quite open that you'll happy trash and burn your builds
[17:45] <BUGabundo_work> eheh
[17:45] <ikonia> BUGabundo_work: in response to genii's comment
[17:46] <ikonia> which I have just clarified
[17:46] <BUGabundo_work> I run it, I know they break
[17:46] <BUGabundo_work> I help fixing
[17:46] <ikonia> I didn't say you -
[17:46] <ikonia> I've just clarified
[17:46] <BUGabundo_work> and make every release a little bit better for those using a stable!
[17:46] <genii> I did qualify "as their main OS"  etc
[17:47] <BUGabundo_work> I know from experience that any MAJOR changes/fix must be done before beta
[17:47] <genii> I like to have a separate partition for dev releases, myself
[17:47] <BUGabundo_work> complaining that "oh my Ubuntu has this bug" two weeks after Release will do no good
[17:47] <BUGabundo_work> genii: it is MY MAIN and ONLY OS on my laptop!
[17:47] <genii> BUGabundo_work: You live dangerously :)
[17:47] <BUGabundo_work> if it breaks, I just boot via network to a daily or stable release!
[17:48] <BUGabundo_work> or if without network, liveUSB
[17:48] <BUGabundo_work> been doing so ever since I started using ubuntu full time
[17:48] <BUGabundo_work> with 6.10 alpha6 or something
[17:48] <BUGabundo_work> tried 6.06 and it missed something so I just dist upgraded!
[17:49] <BUGabundo_work> won't stay on stable more then a few weeks
[17:49] <BUGabundo_work> usually by alpha 1 or 2, I'm using the devel version
[17:49] <BUGabundo_work> it feels strange not having HUGE amounts of updates!
[17:49] <BUGabundo_work> lol
[17:50] <genii> BUGabundo_work: Your average user has no clue of network booting or so on (or even "backups", depressingly), and so it always amazes me when someone is using it as their main desktop and then so surprised when suddenly something makes it inoperable
[17:53] <BUGabundo_work> lol
[17:53] <BUGabundo_work> I know
[17:53] <BUGabundo_work> I guess I been doing this for so long that I don't even bother
[17:53] <BUGabundo_work> and I know my ways around
[17:54]  * BUGabundo_work reminds ikonia that some day we will have to try that kdepim compile
[17:57] <ikonia> BUGabundo_work: happy to do so
[17:57] <ikonia> BUGabundo_work: the cmake method is new to me so I'm interested
[18:04] <BUGabundo_work> but not today
[18:04] <BUGabundo_work> I'm super huber late for group work!
[18:04] <BUGabundo_work> maybe tomorrow
[18:04] <BUGabundo_work> if I have some free time here at work
[18:04] <BUGabundo_work> and you are available
[18:04] <BUGabundo_work> I'll ping you
[18:43] <raymears> hi everyone. here's a kubuntu related question, if i may: is there any possibility of using the plasmoids from jaunty (beta) - which i've installed alongside intrepid -  in intrepid?
[19:04] <ikonia> raymears: nope
[19:04] <ikonia> raymears: don't swap distro packages
[19:43] <raymears> ikonia: damn and blast. ok. 'keep it clean' seems to be the motto here. another question: where can i find the source code of the plasmoids included in jaunty beta? i tried kde-look, websvn.kde.org and google... and found nothing.
[19:43] <ikonia> raymears: pull it out otf the jaunty repo
[19:44] <raymears> ikonia: you mean download the deb and extract things out of it?
[19:44] <ikonia> raymearchange your repo to the jaunty one, do apt-get source $package
[19:44] <ikonia> change the repo back
[19:44] <ikonia> diry but gives you the exact jaunty source package
[19:46] <raymears> heh. didn't think of that. any chance of breaking plasma?
[19:46] <raymears> now that i think of it.. no
[19:47] <raymears> stupid question. thanks
[22:09] <DanaG> grargh, Catalyst 8.12 doesn't work with Jaunty, either.
[23:26] <naught1017> anyone know what version of kdebase the jaunty alpha 1 ISO has on it?
[23:30] <naught1017> and there are no kubuntu dailies now? none since 3 weeks ago?
[23:33] <naught1017> maybe alternate will have to do :)
[23:34] <naught1017> http://cdimage.ubuntu.com/kubuntu/ports/ < what does "ports" mean?
[23:38] <naught1017> nm
[23:48] <DanaG> !find gnomeapplet.so
[23:48] <DanaG> "A required python module is missing! No module named gnomeapplet"
[23:49] <DanaG> yeah... file is missing.
[23:50] <DanaG> Time for me to file a bug, I guess.
[23:50] <DanaG>  dpkg -S gnomeapplet.so           --           dpkg: *gnomeapplet.so* not found.
[23:52] <DanaG> In fact.. a LOT of files are missing.


[00:07] <DarthFrog> Hi folks.  Today, I've been trying to get a Hauppauge HD-PVR 1212 (with firmware updated) to work with Mythbuntu (MythTV 0.26).  trying to watch Live TV, Mythfrontend reports "Error opening jump program file buffer" and /var/log/mythbackend.log reports: http://pastebin.com/CdA8LE66
[00:08] <DarthFrog> It was working earlier with a digital box, using the front panel composite input.  Now I'm trying to use the rear panel component input with S/PDIF audio and an HD terminal.
[00:10] <DarthFrog> Can anyone help me with this?
[16:14] <DarthFrog> tgm4883: Thank you.  The update script works again after your fix to the mythbuntu-testing-quantal PPA yesterday.
[16:24] <tgm4883> DarthFrog, :)
[16:25] <DarthFrog> tgm4883:  Did you happen to see the request for help I made yesterday regarding the problems I was having with a Hauppage HD-PVR?
[16:26] <tgm4883> nope
[16:26] <DarthFrog> [January 28, 2013] [04:07:51 PM] <DarthFrog> Hi folks.  Today, I've been trying to get a Hauppauge HD-PVR 1212 (with firmware updated) to work with Mythbuntu (MythTV 0.26).  trying to watch Live TV, Mythfrontend reports "Error opening jump program file buffer" and /var/log/mythbackend.log reports: http://pastebin.com/CdA8LE66
[16:26] <DarthFrog> [January 28, 2013] [04:08:51 PM] <DarthFrog> It was working earlier with a digital box, using the front panel composite input.  Now I'm trying to use the rear panel component input with S/PDIF audio and an HD terminal.
[16:43] <tgm4883> DarthFrog, when you switched to component, did you remove and readd it? or did you just change the input?
[16:44] <DarthFrog> Changed the input.
[16:45] <tgm4883> DarthFrog, I assume it's showing up as /dev/videoX?
[16:45] <DarthFrog>  /dev/video0
[16:46] <DarthFrog> I'll try removing the "card" from Myth and re-add it.
[16:46] <tgm4883> DarthFrog, ok
[16:48] <DarthFrog> tgm4883:  I bow before your wisdom. :-)
[16:48] <tgm4883> DarthFrog, :)
[16:49] <tgm4883> DarthFrog, do you have other /dev/videoX devices?
[16:49] <DarthFrog> Yes, a web cam on /dev/video1
[16:49] <tgm4883> DarthFrog, is it possible they switched numbers on boot?
[16:50] <tgm4883> when I used my HDPVR, I had udev symlink it to /dev/hdpvr
[16:50] <tgm4883> then told mythtv to use that
[16:50] <DarthFrog> the webcam used to be /dev/video0 but connecting the HDPVR booted it to /dev/video1
[16:50] <tgm4883> ok
[16:51] <DarthFrog> But once I get this working (on my desktop machine), I'll be putting a couple of HD-PVRs on a dedicated backend machine and they will be the only video devices.
[16:52] <DarthFrog> Are you using the IR blaster that the HD-PVR provides to change channels on a cable box?
[16:52] <tgm4883> I don't use my HDPVR anymore, but I used firewire for changing channels when I didn
[16:52] <tgm4883> did
[16:54] <DarthFrog> Once again, many thanks for your most excellent help.  If you're ever in the Vancouver, BC, region I owe you multiple beers! :-)
[16:54] <tgm4883> heh, not too far off
[16:54] <tgm4883> Oregon, USA
[16:55] <DarthFrog> Whereabouts?     The HDPVR is recording in fits & spurts.  A few seconds of recording, then stops for a few more.  The mythbackend log is still reporting the inability to set video recording rates due to bad file descriptors. :-(
[17:06] <Zinn> DarthFrog: Please watch your language.
[17:06] <DarthFrog> Sorry Botty.
[17:06] <tgm4883> DarthFrog, what firmware you have on there?
[17:06] <DarthFrog> Oh flaming nuisance, I meant. :-)
[17:07] <DarthFrog> tgm4883:  The latest.  I updated it a few days ago.
[17:07] <tgm4883> rhpot1991, do you still use your hdpvr? ^
[17:07] <tgm4883> DarthFrog, probably worth checking if a 'cat /dev/video0 > test.mpg' for a few seconds/minutes produces no issues
[17:08] <DarthFrog> OK, I'll give it a shot.  BRB
[17:09] <DarthFrog> It worked for about ten seconds then died.
[17:10] <DarthFrog> Nice picture for that 10 seconds, though. :-)
[17:16] <tgm4883> hmm
[17:16] <tgm4883> DarthFrog, are you plugged into a USB2 port?
[17:16] <tgm4883> and not USB1.1
[17:17] <DarthFrog> Yes, USB2.    I could go into a USB3.
[17:17] <tgm4883> that shouldn't be necessary
[17:17] <tgm4883> anything in dmesg/syslog?
[17:19] <DarthFrog> Nothing in dmesg.  Syslog only has entries for the logserver.
[17:20] <DarthFrog> http://pastebin.com/5tJmrYrS
[17:21] <DarthFrog> the segfault in mythlogserver probably came about from me killing myth-backend to do the video capture.
[17:26] <tgm4883> rhpot1991, superm1 thoughts ^
[17:26] <tgm4883> one of you had a HDPVR, i'm pretty sure
[17:29] <DarthFrog> tgm4883:  Thanks for your help.  I'm thinking that this is a HD-PVR driver issue and not a Mythbuntu issue.  So I'm thinking that I'll reboot and see if the problem re-occurs.  If it does, as I suspect it will, I'll ask for help in #mythtv-users.
[17:31] <tgm4883> DarthFrog, ok
[20:44] <rhpot1991> tgm4883: is he gone?
[20:44] <rhpot1991> I still have my hdpvr
[20:44] <tgm4883> rhpot1991, yea, but he is usually around
[22:03] <sabhain> has gnome3 fixed the mouse focus thing yet?
[22:03] <sabhain> .. rather .. has it be restored as an option?