[00:35] <mup> Bug #1677417 opened: /etc/ld.so.conf.d/conjure-up.conf breaks apt on host system <Snappy:New> <conjure-up (Ubuntu):New for adam-stokes> <https://launchpad.net/bugs/1677417>
[07:17] <mwhudson> who can help me with tracks in the store?
[07:22] <zyga> mwhudson: maybe open a store side question on the forum?
[07:23] <mwhudson> zyga: did the forum get mentioned on the mailing list yet?
[07:23] <zyga> mwhudson: it's metioned in the topic here :)
[07:23] <mwhudson> yes, that's the only place i've seen it mentioned
[07:23] <zyga> mwhudson: I think it will replace the mailing list entirely
[07:23]  * mwhudson gives an old man sign
[07:23] <mwhudson> *sigh
[07:29] <mwhudson> https://forum.snapcraft.io/t/can-someone-set-up-guardrails-for-the-go-snaps-tracks/72
[07:29] <mwhudson> also autopublishing to tracks from launchpad would save me a lot of effort :)
[07:31] <morphis> mwhudson: ping
[07:32] <mwhudson> morphis: hi
[07:32] <morphis> mwhudson: hey! how are things? :-)
[07:32] <mwhudson> morphis: not bad!
[07:33] <morphis> mwhudson: sounds good, I saw you're one of the maintainers of snapd in debian
[07:33] <mwhudson> morphis: yeah
[07:33] <morphis> mwhudson: any concrete plans to update the package real soon?
[07:33] <mwhudson> morphis: no, debian is in freeze
[07:33] <morphis> don't we have a package in unstable too?
[07:33] <mwhudson> morphis: i thought re-execing in the core snap mostly meant i didn't have to
[07:34] <mwhudson> well yeah but life is easier if stable and unstable don't diverge aiui
[07:34] <zyga> mwhudson: I think we could file an RC bug because we need to ship something or the package is totally broken :/
[07:34] <mwhudson> i could upload a newer one to experimental
[07:34] <mwhudson> zyga: right, if we need to fix this core snap hanging thing with a new package, we need to do that
[07:34] <morphis> mwhudson: we had a few serious issues recently which are now patched in snapd 2.23.6, though I didn't checked yet if debian is affected
[07:35]  * zyga reboots to try new pulseaudio
[07:36] <morphis> mwhudson: let me try the current snapd package in testing
[07:37] <mwhudson> morphis: i've not dealt with the politics of getting a release exception in debian
[07:37] <morphis> mwhudson: ok, so lets see if we an avoid this :-)
[07:37] <mwhudson> morphis: but it's at least possible that targeted fixes will be an easier sell than a wholesale upgrade
[07:37] <mwhudson> or not, i don't know
[07:38] <morphis> mwhudson: I think if there are single fixes needed to get snapd in debian re-exec into the one coming from the core snap we can do that
[07:43] <morphis> zyga: https://bugzilla.opensuse.org/show_bug.cgi?id=1031501#c3
[07:48] <zyga> morphis: looking
[07:48] <zyga> morphis: so 1) this will only work if home interface is connected (it doesn't even have to be used)
[07:48] <zyga> morphis: why does every non-snap app work?
[07:49] <zyga> morphis: there must be a different auth mechanism that is being tried
[07:49] <zyga> morphis: it fails and xauthority is a workaround
[07:49] <morphis> maybe
[07:49] <morphis> that is what I am currently looking into
[07:49] <morphis> zyga: it wouldn't even work with the home interface connected as it doesn't allow you to use .XAuthority
[07:50] <morphis> it only works in this case because we have no confinement at all
[07:56] <zyga> morphis: ah, right
[08:07] <morphis> zyga: ok, it gets interesting, XAUTHORITY is set to /tmp/xauth-1000-_0 in KDE on suse
[08:07] <morphis> zyga: are we doing any processing of the env vars when we spawn up the snap environment?
[08:08] <morphis> no, as it seems, it ends up the snap in the snap env
[08:09] <zyga> morphis: aha
[08:09] <zyga> morphis: see
[08:09] <zyga> morphis: it is /tmp related :)
[08:09] <morphis> zyga: flatpak is doing some extra stuff here
[08:09] <morphis> see https://sources.debian.net/src/flatpak/0.8.4-3/common/flatpak-run.c/?hl=1944#L1924
[08:09] <zyga> morphis: yes, I think we need to extra stuff for x11 and pulseaudio
[08:10] <zyga> morphis: that feels like snap-confine's work
[08:10] <zyga> morphis: you could read the xauth config on startup
[08:10] <zyga> morphis: and after dropping privs write the file into the fresh /tmp
[08:11] <zyga> morphis: (remember that tmp is empty)
[08:11] <morphis> zyga: right
[08:11] <morphis> similar to what flatpak does
[08:14] <zyga> morphis: yeah
[08:14] <zyga> morphis: right now I'd code it in C directly
[08:14] <zyga> morphis: but I sooomewhat worry about how many hacks like this we'll need
[08:14] <zyga> morphis: I suspect that a bound set so this is oK
[08:14] <zyga> morphis: if it starts to look like each new interface needs this we may have to think about snapd assisting via a backend
[08:14] <morphis> zyga: right
[08:15] <morphis> zyga: lets start with a hack into snap-confine
[08:15] <morphis> actually this is kind of a problem and wondering if the KDE guys didn't experienced this problem with their snaps
[08:16] <morphis> zyga: let me take this problem as part of my cross-distro work
[08:26] <morphis> Son_Goku: ping
[08:26] <Son_Goku> pong
[08:26] <Son_Goku> :/
[08:30] <morphis> Son_Goku: you saw the PR for the missing not upstream patch?
[08:30] <Son_Goku> yes
[08:30] <Son_Goku> I already added the comment to my spec
[08:30] <morphis> good
[08:30] <Son_Goku> I'm rebasing to 2.23.6, since you guys released that yesterday :/
[08:30] <morphis> Son_Goku: :-)
[08:31] <Son_Goku> and I've already been bitten patchwise
[08:31] <morphis> in which way?
[08:31] <Son_Goku> the systemd unit template PR doesn't apply cleanly onto 2.23.6
[08:31] <Son_Goku> the rules file hunks all fail
[08:31] <Son_Goku> so I've been purging those manually from the patch
[08:32] <morphis> yeah those things are nasty
[08:32] <morphis> Son_Goku: so really time to get them all dropped :-)
[08:32] <morphis> Son_Goku: I am trying to get that solved with 2.24
[08:35] <Son_Goku> is seccomp still broken for 2.23.6?
[08:36] <Son_Goku> morphis ^
[08:38] <morphis> Son_Goku: we have fixed one bug but I fear there might be more
[08:38] <Son_Goku> so still broken, yay :(
[08:38] <morphis> not directly broken
[08:39] <morphis> but as AppARmor is disabled we may run into situatuions where things would have been blocked already by AppArmor and not run into seccomp denials which lead to hanging processes like we had for snapctl
[08:39] <morphis> Son_Goku: once we're done with the basic packaging bits I will start working on getting proper CI up for fedora/debian/suse/..
[08:40] <morphis> then we have a much safer way of handling and testing those things and can ensure they keep working
[08:40] <Son_Goku> I feel like banging my head into the ground with all this shit... :/
[08:40] <Son_Goku> alright, I'm turning back on seccomp and damn the consequences
[08:41] <morphis> Son_Goku: things will be much easier once we have all patches upstream
[08:42] <morphis> and confinement is on my list too
[08:42] <Son_Goku> I hate golang so much
[08:42] <Son_Goku> it just adds so much complication to things
[08:42] <morphis> :-)
[08:43] <Son_Goku> I used to merely dislike golang, now I hate it
[08:45] <seb128> hey morphis, sorry I was not around when you pinged yesterday and it was a contentless ping so couldn't reply when I came back ... I guess it was about that KDE/opensuse issue you are discussing on the list and now here?
[08:46] <morphis> seb128: right, I thought you might be one who knows what is going on but I've figured the real problem already: https://bugs.launchpad.net/snapd/+bug/1677513
[08:46] <mup> Bug #1677513: snap-confine does not pass file referenced by XAUTHORITY env variable into the snap environment <snapd:Confirmed for morphis> <https://launchpad.net/bugs/1677513>
[08:47] <morphis> seb128: didn't checked KDE on Ubuntu yet but they might set XAUTHORITY to something in /run or /home too
[08:47] <morphis> seb128: but thanks for the late pong :-)
[08:47] <seb128> np, glad that you figured it out :-)
[08:52] <Son_Goku> well, here we go...
[08:53] <Son_Goku> morphis: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678557
[08:53] <morphis> Son_Goku: awesome!
[08:54] <pedronis> mvo: #3109 is mergeable, no?
[08:54] <morphis> Son_Goku: will give this some testing once ready
[08:55] <Son_Goku> oh crap
[08:55] <Son_Goku> I just realized something
[08:55] <morphis> ?
[08:57] <Son_Goku> I need to pull in my snapctl patch
[08:57] <Son_Goku> for selinux
[08:57] <Son_Goku> that was almost certainly not merged back in to 2.23.6
[08:58] <Son_Goku> not knocking on mvo, but this was not exactly something he cared about for merging back into releases before
[08:58] <morphis> Son_Goku: ah, is that one already in master?
[08:58] <Son_Goku> yes
[08:58] <morphis> ok, another one we can drop with 2.24 then..
[08:58] <Son_Goku> since the debubuntu packages don't ship the selinux module as a subpackage yet, he has no way of knowing or caring about changes to it
[08:59] <morphis> right
[08:59] <morphis> Son_Goku: this will get better once we have CI also caring about fedora
[08:59] <Son_Goku> I doubt it
[09:00] <Son_Goku> it'll be hard to spot selinux backport things because the domain is in permissive mode
[09:01] <morphis> I see
[09:01] <morphis> something I need to dive into at a later point
[09:02] <Son_Goku> generally, selinux policy module changes should be assumed to be backported, I think
[09:03] <Son_Goku> as they are generally reactive from when you guys change something, rather than proactive
[09:07] <mvo> Son_Goku: hey, sorry that some bits did not get backported, we want to do a 2.24 soon though. we did the 2.23.6 mostly to ensure we have some important bugfixes out before moving on. once 2.24 lands things should move more normal again, i.e. things in master also go into the release etc
[09:08] <Son_Goku> mvo: no worries
[09:08] <Son_Goku> I blame morphis anyway :P
[09:08] <Son_Goku> (not really!)
[09:08] <morphis> Son_Goku: :-D
[09:09] <Son_Goku> anyway, I expect that this will get better, vis-a-vis the selinux module, once someone adds the packaging for it to debubu packaging
[09:10] <Son_Goku> what I'm going to hate doing is packaging DNF debian-style for snapcraft
[09:10] <Son_Goku> I despise Debian-style packaging (I consider it way more complicated than it should be)
[09:10] <Son_Goku> it's not that I don't know how to do it... I certainly do
[09:11] <Son_Goku> after all, I used to use Ubuntu for years and almost became a Debian/Ubuntu contributor many years ago
[09:13] <Son_Goku> fuck
[09:14] <Son_Goku> snapd FTBFS on i686
[09:14] <Son_Goku> and ppc64
[09:15] <Son_Goku> well, at least it built on ppc64le
[09:15] <Son_Goku> https://koji.fedoraproject.org/koji/taskinfo?taskID=18678723
[09:17] <morphis> Son_Goku: ah, I have a fix for that one
[09:18]  * Son_Goku groans
[09:18] <morphis> Son_Goku: https://github.com/snapcore/snapd/pull/3094
[09:18] <mup> PR snapd#3094: cmd: rework header check for xfs/xqm.h <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3094>
[09:18] <Son_Goku> yay
[09:18] <Son_Goku> more patches
[09:18] <morphis> Son_Goku: with that everything should build fine, verified with https://copr.fedorainfracloud.org/coprs/mrmorph/snapcore/
[09:18] <Son_Goku> you don't have a fix for ppc64, though
[09:19] <morphis> which doesn't build for ppc but for i386
[09:19] <morphis> yeah looking into that one ..
[09:20] <morphis> Son_Goku: can I easily cross build with mock?
[09:20] <Son_Goku> no
[09:20] <Son_Goku> mock does not support foreign arches like that yet
[09:20] <Son_Goku> BUT
[09:20] <Son_Goku> Fedora offers contributors access to ppc64 VMs
[09:20] <morphis> ah
[09:21] <Son_Goku> morphis: I suggest hopping into #fedora-ppc and asking about it
[09:23] <morphis> Son_Goku: will do, need to care about a few other things first
[09:27] <morphis> pedronis: what retry interval do we have in snapd currently to reach the serial-vault as configured from the prepare-device hook?
[09:30] <pedronis> morphis: 1 minutes for dynamic errors,  for things that look like the vault is not understanding a back off starting from 5 minutes and then doubling up to a max
[09:31] <Son_Goku> morphis: and joy of joys
[09:31] <Son_Goku> armv7hl failed too
[09:31] <morphis> pedronis: ok, but we don't block the further first-boot process when we can't the server, right?
[09:31] <morphis> Son_Goku: wonderful ..
[09:31] <Son_Goku> full list of failures: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678723
[09:31] <pedronis> morphis: first boot is completely independent, they are even two different changes
[09:31] <pedronis> morphis: what we block is the fist refresh for a bit
[09:32] <pedronis> we try to refresh witha serial if possible
[09:32] <pedronis> but after a while try anyway
[09:32] <Son_Goku> morphis: it looks like arm failed because of same issue with i686
[09:32] <morphis> pedronis: ok, just wanted a confirmation on this
[09:32] <morphis> Son_Goku: yeah, which is a "good" thing :-)
[09:38] <Son_Goku> morphis: added patch, and trying again: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678977
[09:38] <morphis> Son_Goku: great
[09:46] <zyga> mvo: can you please have a 2nd look at https://github.com/snapcore/snapd/pull/3102
[09:46] <mup> PR snapd#3102: interfaces/mount: add function for parsing mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3102>
[09:46] <Son_Goku> morphis: now i686 just fails to compile :(
[09:47] <Son_Goku>   /usr/include/xfs/xfs.h:51:12: error: size of array 'xfs_assert_largefile' is too large
[09:47] <Son_Goku>  extern int xfs_assert_largefile[sizeof(off_t)-8];
[09:47] <Son_Goku> morphis: you need to go back to the drawing board on this
[09:48] <zyga> I see you two are having fun :)
[09:48]  * Son_Goku groans
[09:48] <Son_Goku> I wanted this to be released already
[09:48] <Son_Goku> I want the buildsys to stop telling me that snapd-glib is broken
[09:48] <zyga> I start to see light at the end of my tunnel
[09:49] <zyga> with the move to go the coding moves faster than before
[09:49] <morphis> Son_Goku: hm, this worked for me well in Yocto ..
[09:49] <Son_Goku> I see crushing sadness and dispair
[09:49] <Son_Goku> morphis: Yocto is bullshit
[09:49] <morphis> Son_Goku: lets not get into this discussion, please :-)
[09:49] <Son_Goku> Yocto can be whatever you want, so it doesn't really serve as a great means of comparison
[09:50] <morphis> Son_Goku: you have a link to the last build?
[09:50] <zyga> Son_Goku: I think the more interesting fact is that it built on 32bit debian
[09:50] <Son_Goku> zyga: Debian has older compiler
[09:50] <zyga> Son_Goku: sid?
[09:51] <zyga> Son_Goku: very doubtful
[09:51] <Son_Goku> has debian moved onto GCC 7 yet?
[09:51] <Son_Goku> as far as I knew, they were still on 6.3.x
[09:51] <zyga> Son_Goku: yes
[09:52] <Son_Goku> are you using hardened build flags there?
[09:52] <zyga> https://packages.debian.org/experimental/gcc-7
[09:52] <Son_Goku> because Fedora does by default
[09:52] <zyga> Son_Goku: I don't know
[09:52] <Son_Goku> I know Debian does not
[09:52] <zyga> but dones't look like related to what the error above says
[09:52] <zyga> it does look like the size of off_t is the relevant factor here
[09:52] <zyga> but TBH
[09:52] <zyga> this is all load of BS
[09:52] <Son_Goku> zyga: anyway, gcc-defaults in sid is gcc6
[09:52] <zyga> because we should just check if that header file exists
[09:52] <Son_Goku> https://packages.debian.org/sid/gcc
[09:53] <zyga> all we need are _constants_
[09:53] <zyga> morphis: feel free to hardcode those as those are kernel constants and kernel is not insane to change
[09:53] <zyga> morphis: and drop libxfsprogs-devel from dependencies
[09:53] <Son_Goku> morphis, zyga: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678977
[09:53] <Son_Goku> the green, orange, and red links are clickable :)
[09:54] <zyga> the ppc one is interesting, checking
[09:54] <morphis> zyga: you propose that as an upstream change? :-)
[09:54] <Son_Goku> here's a previous failed build, too, prior to adding snap-confine patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678723
[09:54] <zyga> morphis: as a distro change and upstream change later
[09:54] <zyga> morphis: I see no reason to check linkability or work around this issue
[09:54] <zyga> morphis: if we care about a hanful of constants
[09:55] <morphis> Son_Goku: ok, this looks different now
[09:55] <Son_Goku> the failures are possibly caused by newer libxfs
[09:55] <morphis> maybe
[09:56] <Son_Goku> Fedora has xfsprogs 4.10.0
[09:56] <Son_Goku> Debian has xfsprogs 4.9.0
[09:56] <Son_Goku> since we update the kernel, we also update the tools too
[10:01] <morphis> Son_Goku: my guess is that we should get this building with add -D_FILE_OFFSET_BITS=64 to CFLAGS
[10:01] <Son_Goku> patch?
[10:03] <morphis> Son_Goku: something like https://paste.ubuntu.com/24280132/ but didn't tested it yet
[10:04] <Son_Goku> easy to test, I can just fire off a scratch build for it
[10:04] <Son_Goku> okay, I'm getting super sick of this
[10:04] <Son_Goku> someone needs to turn off OpenID auth on raw pastes
[10:04] <Son_Goku> morphis: if no one fixes that, please stop using paste.ubuntu.com
[10:05] <morphis> :-)
[10:06] <zyga> Son_Goku: I bet there's a reason for that
[10:06] <Son_Goku> zyga: I don't care
[10:06] <Son_Goku> it's stupid and aggravating and I can't curl anything
[10:06] <Son_Goku> morphis: please use paste.fedoraproject.org, if you need an alternative
[10:07] <Son_Goku> there's also a handy fpaste utility for pasting from the CLI :)
[10:07] <Son_Goku> https://pagure.io/fpaste
[10:07]  * zyga wonders why not pastebinit + config
[10:08] <Son_Goku> well, I didn't know about pastebinit :)
[10:08] <zyga> it supports many paste services
[10:09] <zyga> simple python script AFAIR
[10:09] <Son_Goku> it has a fpaste config
[10:10] <Son_Goku> though I don't know if it works with the new pastebin software fedora deployed recently: https://fedoramagazine.org/hello-modern-paste/
[10:11] <morphis> Son_Goku: looks nice
[10:12] <zyga> Son_Goku: I honestly don't like the new paste, there was a looot of negative feedback after it was rolled out
[10:12] <zyga> Son_Goku: I need to try it again though, I think/hope some of that feedback was addressed
[10:12] <Son_Goku> I don't care for it's look and the superlong URLs
[10:13] <zyga> Son_Goku: the URLs were totally broken wrt basic usaility
[10:13] <zyga> *usability
[10:16] <Son_Goku> morphis: trying a scratch build with your diff: https://koji.fedoraproject.org/koji/taskinfo?taskID=18679354
[10:16] <morphis> ok
[10:17] <morphis> ah
[10:17] <morphis> it wont work
[10:17] <morphis> needs to be = instead of +=
[10:17] <morphis> Son_Goku: sorry for that
[10:18] <morphis> Son_Goku: https://paste.fedoraproject.org/paste/-NaL-TKvNct9~lx1tvVDdl5M1UNdIGYhyRLivL9gydE=
[10:18] <Son_Goku> does that mean all the hardening flags are clobbered?
[10:20] <morphis> no
[10:20] <morphis> if we add AM_CFLAGS then they are there
[10:21] <morphis> Son_Goku: so something like https://paste.fedoraproject.org/paste/k6OU-DUhS5tSIQ5cglQP7F5M1UNdIGYhyRLivL9gydE= is more correct
[10:21] <morphis> Son_Goku: this fork functionality is quite nice
[10:21] <Son_Goku> yes, it is
[10:22] <zyga> ogra: how do you reply with a quote on discourse?
[10:22] <ogra> zyga, just mark something in the text then a "quote" thing pops up
[10:22] <ogra> you also earn a new badge with it ;)
[10:22] <zyga> aah, nice!
[10:22] <zyga> thanks!
[10:25] <Son_Goku> morphis: take 2: https://koji.fedoraproject.org/koji/taskinfo?taskID=18679427
[10:25] <morphis> Son_Goku: lets hope this now works ..
[10:25] <Son_Goku> since arm takes too long, I'm going to assume it works if i686 does
[10:26] <Son_Goku> then you can prepare a formal PR and I can have a formal patch and we can try again for all arches
[10:26] <zyga> ogra: heh, my quote didn't really work :)
[10:27] <Son_Goku> I wish our discourse supported social sign on
[10:27] <zyga> fixed now
[10:27] <zyga> ogra: have a look at https://github.com/snapcore/core-build
[10:27] <Son_Goku> (not Ubuntu SSO, but normal SSO, like Google, Twitter, GitLab, GitHub, etc.)
[10:27] <zyga> ogra: what else do we need there?
[10:28] <zyga> Son_Goku: I think it doesn't upstream and that's why we don't have it here
[10:28] <Son_Goku> weird
[10:28] <zyga> Son_Goku: and as a plugin it is not supported from what I heard
[10:28] <zyga> Son_Goku: I think there's a thread about that actually
[10:28] <Son_Goku> hm
[10:28] <zyga> Son_Goku: no, let's start one
[10:28] <Son_Goku> the Rust forum uses social sign-on, I think
[10:29] <Son_Goku> yeah, Rust uses GitHub
[10:29] <zyga> https://forum.snapcraft.io/t/support-for-sso-on-forum-snapcraft-io/75
[10:29] <Son_Goku> one of the other ones I know of uses Google
[10:29] <morphis> Son_Goku: looks like the patch apply failed this time
[10:30] <Son_Goku> :/
[10:34] <zyga> ogra: https://forum.snapcraft.io/t/gardening-in-github-com-snapcore-core-build/76
[10:36] <Son_Goku> morphis: fixed the patch, but it didn't work
[10:36] <morphis> Son_Goku: you have the full patchset somewhere?
[10:36] <morphis> let me create the patch on top of that
[10:38] <Son_Goku> morphis: the patch set is http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/ + https://da.gd/qUH4P
[10:43] <morphis> Son_Goku: https://paste.fedoraproject.org/paste/AFR94F40CNQwmk3eFcy4Rl5M1UNdIGYhyRLivL9gydE= should cleanly apply on top of the patchset
[10:44] <Son_Goku> yes, but it still doesn't fix the problem
[10:44] <Son_Goku> oh wait
[10:44] <Son_Goku> la
[10:44] <ogra> zyga, if you mention me in the post you dont need to ping on IRC ;)
[10:45] <ogra> (was already writing an answer when you pinged)
[10:46] <zyga> ogra: aha, you get destkop notifications on @-mentions?
[10:47] <Son_Goku> morphis: take 4: https://koji.fedoraproject.org/koji/taskinfo?taskID=18679552
[10:47] <ogra> zyga, yeah
[10:49] <morphis> Son_Goku: we're coming closer :-)
[10:50] <morphis> Son_Goku: ok, this didn't help
[10:51] <morphis> Son_Goku: need to scratch my head around this when I am done with my meetings
[11:17] <mup> PR snapd#3113 opened: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Created by pedronis> <https://github.com/snapcore/snapd/pull/3113>
[11:30] <pedronis> Chipaca: you might want to look at snapd#3113 when one have a moment, it's not big, it's the changes about locking discussed yesterday
[11:30] <mup> PR snapd#3113: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Created by pedronis> <https://github.com/snapcore/snapd/pull/3113>
[11:30] <Chipaca> pedronis— looking
[11:32] <mvo> pedronis: yes, 3109 is mergable
[11:32] <mvo> zyga: sure, I have a look at the fstab thing
[11:34] <mup> PR snapd#3109 closed: Merge 2.23.6 release back into master <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3109>
[11:35] <pedronis> mvo: done
[11:35] <ogra> zyga, https://github.com/snapcore/core-build/pull/1
[11:35] <mup> PR core-build#1: adjust README file to proper reflect repo content <Created by ogra1> <https://github.com/snapcore/core-build/pull/1>
[11:37] <mvo> pedronis: ta
[11:38] <zyga> ogra: +1
[11:57] <Chipaca> pedronis— +1; lgtm and good start
[11:58] <zyga> Chipaca: care to do a 2nd review of https://github.com/snapcore/snapd/pull/3102
[11:58] <mup> PR snapd#3102: interfaces/mount: add function for parsing mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3102>
[11:58] <Chipaca> zyga— nah
[11:58]  * Chipaca grins
[11:58] <zyga> Chipaca: et tu Brutus?
[11:58] <zyga> ;-)
[11:59] <Chipaca> zyga— et ideam habent quam multa.
[11:59] <jdstrand> morphis, Son_Goku: things will also get much better when we don't kill the process for a seccomp denial and instead return something like EPERM. this is in progress
[12:00] <morphis> jdstrand: yeah, that would help
[12:00] <morphis> jdstrand: however I still fear we will run into multiple bugs with just seccomp and no AppArmor
[12:00] <morphis> so having some extensive testing before we enable this would be good
[12:01] <jdstrand> morphis: the sandbox is definitely designed for both to be enabled. enabling seccomp without apparmor isn't really gaining you much
[12:01] <morphis> jdstrand: right
[12:01] <jdstrand> morphis: I mean, sure, you can't load a kernel module, but you can write a file to /etc/modules.d
[12:01] <morphis> jdstrand: so for other systems we need SELinux + Seccomp or nothing
[12:02] <jdstrand> /etc/modules-load.d
[12:03] <Chipaca> zyga— +1 (with a comment)
[12:03] <jdstrand> morphis: re selinux> yes, though selinux only has rudimentary dbus mediation compared to apparmor
[12:03] <morphis> jdstrand: yeah sadly, but this is something we need to talk in the near future
[12:03] <morphis> jdstrand: having this on my road map for cross-distro after I am through all the others things :-)
[12:04] <jdstrand> morphis: this was actually discussed a good bit in the Hague
[12:04] <zyga> jdstrand: FYI, overlayfs got good selinux support lately, is that because LSMs got improved or and so apparmor "groks" overlayfs automatically or is that selinux specific, do you know?
[12:04] <morphis> jdstrand: oh great, seems like I missed that session :-)
[12:04] <morphis> jdstrand: are there any notes available?
[12:04] <jdstrand> morphis: I suspect that the list of interfaces available will need to be different for an apparmor enabled system vs an selinux system
[12:05] <morphis> jdstrand: yeah, maybe
[12:05] <jdstrand> morphis: it was inconclusive. various problems were identified because of the capabilities of each system and how they both approach MAC differently
[12:06] <zyga> Chipaca: thanks for the hint, applied!
[12:06] <jdstrand> morphis: when you are starting to write selinux policy, you'll want to do a hangout with at least me, Tyler and jj
[12:06] <morphis> jdstrand: absolutely
[12:06] <Chipaca> zyga— as i said the compiler is probably good enough nowadays to not make it necessary, but sometimes (like here) it's probably clearer anyways
[12:07] <zyga> Chipaca: yeah, I really like it, feels pythonic in good way :)
[12:07] <Chipaca> :-)
[12:07] <morphis> jdstrand: this is currently somewhere on the horizon but I want to have proper CI for those systems in place first
[12:07] <Chipaca> zyga— yeah
[12:07] <zyga> morphis: I think you could start by trying to run unit tests on snapd build on fedora
[12:07] <zyga> morphis: that will show looooots of red because of /snap shift
[12:07] <morphis> zyga: yeah :-)
[12:08] <zyga> morphis: niemeyer suggested that we add a mock call so that those tests assume /snap is still in place
[12:08] <zyga> morphis: for spread you will need a different tactics I fear, as those are integration tests
[12:08] <jdstrand> morphis: it is possible to do things like: the process with this label can talk to the process with that label over dbus with selinux (eg, I can talk to all of network-manager or I can't talk to network-manager at all), but for carving out parts of the dbus api-- no
[12:08] <zyga> morphis: while not perfect, I had an idea with snapd-fhs package that puts a /snap -> /var/lib/snapd/snap symlink in place
[12:08] <morphis> zyga: yeah, mock call sounds good, will need to look into that once we're through the current phase of getting distros into shape
[12:08] <zyga> morphis: as a $0.01 solution
[12:08] <morphis> zyga: depends if we can that approved by the other distros
[12:09] <jdstrand> morphis: but there are other issues that aren't at the top of my head
[12:09] <jdstrand> (even with dbus)
[12:09] <zyga> jdstrand: are you sure? I saw some fine-grained mediation for dbus + selinux lately (but maybe I was confused)
[12:09] <zyga> morphis: for spread testing
[12:09] <zyga> morphis: not for anything else
[12:09] <morphis> jdstrand: I think we should come together at some point and just brainstorm to see what problems we have and to guess possible solutions
[12:09] <jdstrand> zyga: patches to dbus deamon?
[12:10] <morphis> zyga: flatpak uses a proxy for that, maybe they added selinux to that
[12:10] <zyga> jdstrand: I think to selinux, I saw policy language that was referring to specific methods
[12:10]  * zyga googles
[12:10] <jdstrand> if you're talking flatpak, they either write services where the whole api is safe or use a proxy
[12:11] <morphis> jdstrand: right
[12:11] <zyga> jdstrand: no, not flatpak
[12:11] <zyga> jdstrand: I know they use a proxy, it's a different approach altogether
[12:12] <pedronis> fgimenez: mvo: we are hitting /dev/ram0 issues now in the spread tests
[12:13] <zyga> pedronis: https://forum.snapcraft.io/t/spread-tests-fail-on-lack-of-dev-ram0/77
[12:14] <zyga> jdstrand: I cannot find it, all I can find now confirms what you said earlier (no per-method control)
[12:14] <zyga> it would be nice if selinux supported that actually
[12:15] <jdstrand> zyga: indeed it would :)
[12:15] <zyga> jdstrand: the proxy based approach has one advantage, it can be rolled out on any old kernel
[12:15] <zyga> jdstrand: (and any old dbus)
[12:15] <zyga> jdstrand: do you think we should write such proxy?
[12:15] <jdstrand> zyga: but the kdbus discussions showed that people weren't really interested in it
[12:16] <zyga> jdstrand: in selinux over dbus?
[12:16] <zyga> jdstrand: I saw that kdbus disposed the xml language too
[12:16] <zyga> jdstrand: but I wasn't aware of any other details
[12:17] <jdstrand> zyga: I can't make that recommendation. putting a proxy in front of dbus-daemon would slow things down. it would have to be measured. it is certainly possible
[12:17]  * Chipaca ~> lunch
[12:18] <jdstrand> zyga: the gist of the kdbus conversations was that "selinux doesn't do interface/path/member mediation, why should we allow apparmor to do that? either the service is safe or it isn't"
[12:19] <zyga> jdstrand: hmm, who expressed this view? kernel developers or kdbus developers?
[12:20] <jdstrand> it's an interesting argument that has merit, but we fell on different sides. we felt it was useful to go to that depth, they (kdbus guys) did not
[12:20] <jdstrand> zyga: yes
[12:20] <jdstrand> if you recall, the kdbus discussions were lennart, kay and greg
[12:21] <zyga> jdstrand: well, I think I agree with kdbus developers for _new_ services written by security aware developers but that's not a good coverage of the software people want to use
[12:21] <jdstrand> Dan got into it a little bit, but not too much
[12:21] <zyga> jdstrand: what was his view?
[12:22] <zyga> (and the flatpak dbus proxy is a perfect example of that)
[12:22] <jdstrand> you should read the thread
[12:22] <zyga> jdstrand: is that the kdbus thread? any hints on what to google?
[12:25] <zyga> mvo: I applied your feedback on https://github.com/snapcore/snapd/pull/3102
[12:25] <mup> PR snapd#3102: interfaces/mount: add function for parsing mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3102>
[12:25] <zyga> mvo: if we could merge that I have two more proposals to do on top
[12:25] <jdstrand> zyga: apparmor and kdbus
[12:26] <zyga> OK
[12:26] <zyga> thanks!
[12:30] <cachio> jdstrand, hey, fyi https://bugs.launchpad.net/apparmor/+bug/1677587
[12:31] <mup> Bug #1677587: apparmor is denying access to executables shared through content interface <AppArmor:New> <https://launchpad.net/bugs/1677587>
[12:39] <Son_Goku> jdstrand: there's already a bit of a rudimentary selinux policy in data/selinux
[12:39] <Son_Goku> it needs beefing up, but at least it's enough to get snapd working
[12:39] <Son_Goku> snapd can't yet run properly confined :(
[12:45] <mvo> zyga: looking now, sorry for the delay
[12:47] <zyga> no worries
[12:47]  * zyga is a sad panda
[12:47] <zyga> can't load package: package github.com/snapcore/snapd/cmd/snap-update-ns: use of cgo in test /home/zyga/go/src/github.com/snapcore/snapd/cmd/snap-update-ns/bootstrap_test.go not supported
[12:49] <mup> PR snapd#3102 closed: interfaces/mount: add function for parsing mount entries <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3102>
[12:50] <Chipaca> mvo, niemeyer, I'll be missing the standup today
[12:50] <mvo> Chipaca: no worries
[12:52] <fgimenez> ogra: snap kernel on edge is ok again \o/ https://travis-ci.org/snapcore/spread-cron/builds/216734158
[12:53] <mvo> fgimenez: what happend? how did it get fixed?
[12:53] <zyga> mvo: it was reverted
[12:53] <zyga> mvo: look at this thread: https://forum.snapcraft.io/t/spread-tests-fail-on-lack-of-dev-ram0/77/16
[12:54] <zyga> mvo: specifically this https://forum.snapcraft.io/t/spread-tests-fail-on-lack-of-dev-ram0/77/13
[12:55] <mvo> ta
[12:59] <jdstrand> cachio: thanks, responded
[13:00] <jdstrand> Son_Goku: yeah, I was talking about the steps after that-- snap confinement and snap to snap communications
[13:00] <fgimenez> mvo: yep, it was finally fixed, i'll file a bug about the problem, ogra where should i report it?
[13:00] <ogra> fgimenez, against linux i guess
[13:01] <fgimenez> ogra: ok thanks
[13:02] <sergiusens> stgraber: hey, `lxc image list ubuntu:` doesn't return any 16.04 image (and it seems the aliases are all wonky too)
[13:04] <jdstrand> roadmr: hi! can you pull r865? this isn't urgent and has code changes (tested of course :). I suggest not rolling out before weekend (ie, follow whatever staging procedures you'd normally use for code changes)
[13:04] <niemeyer> Chipaca: Ack, thanks for the note
[13:05] <niemeyer> Hello all
[13:05] <roadmr> jdstrand: sure! ok, let me check the commit log to see what the changes are about. But I'll have it in SCA trunk in a sec.
[13:09] <jdstrand> roadmr: code changes aren't extensive, it is just more than the last few pulls I've requested,
[13:19] <mup> PR snapd#3114 opened: interfaces/mount: add function for saving fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3114>
[13:26] <morphis> Son_Goku: hm, when I try to build snapd with mock for rawhide, shouldn't it fetch the golang-* packages we already pushed there?
[13:26] <morphis> always fails with saying it can't find those deps
[13:26] <Son_Goku> mirror sync is not complete, I suspect
[13:27] <Son_Goku> you can create custom mock targets to use
[13:27] <Son_Goku> I have a fedora-rawhide-x86_64-koji config that I use to access Koji's internal repos, since they are publicly accessible
[13:27] <Son_Goku> I'll paste it for you
[13:28] <morphis> thanks
[13:28] <Son_Goku> morphis: https://da.gd/Oh2U
[13:29] <Son_Goku> save it as "fedora-rawhide-x86_64-koji.cfg"
[13:29] <Son_Goku> then do "mock -r </path/to/fedora-rawhide-x86_64-koji.cfg> </path/to/package.src.rpm>"
[13:29] <morphis> ok
[13:32] <zyga> Chipaca: hey
[13:32] <zyga> Chipaca: you around?
[13:32] <Chipaca> zyga— with some latency yes
[13:33] <zyga> Chipaca: can you please eyeyball https://github.com/snapcore/snapd/pull/3103/files
[13:33] <mup> PR snapd#3103: interfaces/mount: add function for parsing fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3103>
[13:33] <zyga> Chipaca: if not too inconvenient
[13:33] <Chipaca> no probs
[13:38] <fgimenez> hey pstolowski during the 2.23.6 candidate validation vigo got this error on dragonboard http://paste.ubuntu.com/24281125/ afaik you have been working in this area, could you please take a look when you have a moment?
[13:41] <zyga> niemeyer: do you think we should have a "casual" category for posts that would not be related to snaps in any way?
[13:44] <ogra> "gossip"
[13:44] <ogra> :)
[13:45] <niemeyer> Hmm.. not sure.. problem is that they'd show in forum.snapcraft.io nevertheless..
[13:45] <niemeyer> Let me see if there's some sort of "only inside category" setting
[13:45] <zyga> niemeyer: https://forum.snapcraft.io/t/should-we-have-category-casual-for-daily-chatter/80/1
[13:45] <zyga> niemeyer: I see longue
[13:45] <zyga> niemeyer: but not sure if that's one post
[13:45] <zyga> niemeyer: or a category
[13:47] <Chipaca> zyga— +1'ed, with two ignorable notes
[13:49] <pedronis> niemeyer: I added the comment blocked to snapd#3113 if you want to review
[13:49] <mup> PR snapd#3113: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3113>
[13:50] <pedronis> niemeyer: I put the PR link also in the forum
[13:50] <pedronis> s/blocked/block/
[13:56] <fgimenez> ogra: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677622
[13:56] <mup> Bug #1677622: missing ramdisks in latest amd64 kernel snap <linux (Ubuntu):New> <https://launchpad.net/bugs/1677622>
[13:57] <ogra> fgimenez, great, thx
[14:11] <niemeyer> pedronis: Ack, thanks
[14:18] <pstolowski> fgimenez, sorry, i was in another meeting and missed your message. will take a look
[14:19] <fgimenez> pstolowski: np thanks
[14:31] <mup> PR snapd#3115 opened: interfaces/unity7: support unity messaging menu <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3115>
[14:34] <King_InuYasha> zyga: morphis: make sure you guys give feedback on tomb updates: https://bodhi.fedoraproject.org/updates/?packages=golang-github-go-tomb-tomb
[14:35] <King_InuYasha> morphis: ahh, I see you did
[14:35] <pstolowski> fgimenez, this is super weird, I don't see a reason for it too fail on one arch and not others. any chance the tests were executed against an older revision of snapd for some reason?
[14:35] <King_InuYasha> zyga: please do so, so that it'll sync out to stable
[14:36] <pstolowski> vigo, ^ ?
[14:36] <fgimenez> pstolowski: i don't think so, dragonboard is notably slower than other platforms, afaik is the only diference, vigo can give you more details
[14:36] <pstolowski> fgimenez, ah, interesting
[14:37] <ogra> oh ? dragonboard is slower ?
[14:37] <ogra> (nobody told me yet)
[14:38] <vigo> pstolowski, my mistake I though I switched to the new branch
[14:43] <pstolowski> vigo, ah, so all good?
[14:43] <vigo> pstolowski, re-running spread tests
[14:47] <roadmr> hey folks, who can help me with the discourse.snapcraft.io forum? I tried signing up but it's not sending me the confirmation e-mail, so I can't really use it yet :(
[14:47] <ogra> niemeyer, is the admin ^^^
[14:48] <roadmr> thanks!
[14:53] <niemeyer> roadmr: Heya
[14:53] <niemeyer> roadmr: Let me test the email sending
[14:54] <roadmr> thanks niemeyer!
[14:54] <roadmr> let me know if you need me to do anything
[14:56] <niemeyer> roadmr: Problem is in the system.. I'm probably blowing some quota
[14:56] <roadmr> oops :(
[15:05] <stgraber> sergiusens: that would be a CPC problem, the LXD team doesn't control the ubuntu: remote
[15:08] <mup> PR snapd#3116 opened: interfaces: allow executing ld.so (needed with new AppArmor base abstraction) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3116>
[15:09] <mup> PR snapd#2833 opened: many: allow core refresh.schedule setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/2833>
[15:12] <vigo> pstolowski, ping
[15:12] <vigo> I ran again against current branch in i386 and failed again
[15:13] <vigo> https://pastebin.canonical.com/184322/
[15:14] <niemeyer> roadmr: Looks like it was actually my own provider that crashed.. they have a critical announcement saying they're working on it
[15:14] <niemeyer> roadmr: I've shifted it to Canonical's SMTP.. can you please give it a try now?
[15:14] <roadmr> oh whoops :)
[15:15] <roadmr> niemeyer: sure thing, here I go
[15:15] <niemeyer> roadmr: You _migth_ have received the email already, actually
[15:17] <roadmr> niemeyer: none of the previous attempts have arrived, I just requested a new one, will wait a bit for it
[15:17] <niemeyer> roadmr: Thanks
[15:23] <pstolowski> vigo, hmm ok let me try it locally
[15:25] <roadmr> niemeyer: still nothing. ~10 mins feels slowish for an e-mail, right?
[15:28] <ogra> niemeyer, is there a setting in discourse that would open links in additional tabs or new windows ? currently a link i click replaces the forum ....
[15:28] <ogra> would be nice to have that opening in external pages
[15:30] <niemeyer> roadmr: Yeah
[15:30] <pstolowski> vigo, I just run this specific test against master and it passed here; are you running it against current master or a tagged version?
[15:31] <niemeyer> roadmr: There's definitely something broken, and I'm having  a slightly harder time debugging because my own email is broken due to the provider
[15:31] <niemeyer> roadmr: Or there's just a big queue
[15:31] <vigo> pstolowski, np I updated to a non existing branch and lacked tests
[15:31] <vigo> it is correctly set now
[15:31] <roadmr> maybe queue + retries
[15:32] <niemeyer> kyrofa: Did you just get an email from the forum?
[15:32] <pstolowski> vigo, hmm ok I'm confused now :), so is it all good and passing now after all?
[15:32] <kyrofa> niemeyer, just now? No
[15:33] <niemeyer> popey: What about you?
[15:34] <niemeyer> According to the logs the queue is slowly going out.. but I'm not sure about whether the SMTP host from Canonical has any constraints in terms of origin, etc
[15:36] <popey> hmm?
[15:37] <niemeyer> Yep, there we go..
[15:37] <niemeyer> 	[Sender] 550 relay not permitted
[15:37] <roadmr> oops :)
[15:37] <niemeyer> Will need to do something else
[15:37] <popey> yeah, I have no emails for a while
[15:37] <popey> I'd recommend using a cloud email provider. flexiondotorg has done this at scale, and knows a good option
[15:37] <ogra> niemeyer, google smtp ...
[15:38] <flexiondotorg> No, don't use Google SMTP. Bad thing _will_ happen.
[15:38] <ogra> oh ?
[15:38] <flexiondotorg> I use Sendgrid. It's brilliant.
[15:38] <popey> yeah, you get blocked from google for using it too much
[15:38] <ogra> what are these bad things ?
[15:38] <popey> they have very strict limits
[15:38] <niemeyer> ogra: What is the password there?
[15:38] <ogra> oh
[15:39] <flexiondotorg> Google rejects lots of mail.
[15:39] <flexiondotorg> So the mailing list features of Discourse become unreliable and notifications don't work properly.
[15:39] <ogra> niemeyer, well, obviously gmail is a bad idea ...
[15:39] <niemeyer> flexiondotorg: Yeah, that was my idea too (sendgrid), except they deactivated my account for inactivity
[15:39] <flexiondotorg> Sendgrid is the way to go.
[15:39] <flexiondotorg> I have tried them all with Discource.
[15:39] <niemeyer> and guess what, I need email to re-activate it.. #FML
[15:39] <ogra> lol
[15:41] <roadmr> hehe :)
[15:41] <morphis> Pharaoh_Atem, King_InuYasha: lets give https://paste.fedoraproject.org/paste/DMpW-ZW11QIB76FA9DBnEF5M1UNdIGYhyRLivL9gydE= a try
[15:47] <lool> cjwatson: Hey
[15:47] <lool> cjwatson: I hope you had a good leave (if you're not back ignore this)
[15:48] <lool> cjwatson: I had a "store upload failed" for one snap build out of 4, I pressed "Retry" button, upload worked, but snap wasn't published to the channels it was supposed to be published in
[15:48] <lool> cjwatson: really minor but thought I'd mention it; would you like me to report this somewhere?
[15:49] <ogra> lool, are you sure it wasnt published ? note there is quite a delay
[15:49]  * ogra fell for that multiple times in the past
[15:49] <lool> ogra: it passed review, and then was ready to publish
[15:49] <lool> I just clicked in the web UI to do so
[15:49] <ogra> right, and then between 10 and 20min later it publishes ...
[15:49] <lool> it had the "thumb up" icon
[15:49] <ogra> yeah
[15:50] <lool> and no channel selected
[15:50] <ogra> i see that at times for the core snap daily build ... but as i said, afetr a while it publishes then
[15:51] <cjwatson> lool: sure, report that as a Launchpad bug
[15:51] <kyrofa> ogra, lool I've seen the same 10 minute delay or so
[15:51] <lool> cjwatson: ok, seems to be normal; perhaps I only saw it because of the retry
[15:54] <roadmr> jdstrand: hello! oops, "unexpected output" from tools r865...
[15:54] <cjwatson> lool: so I mean there's the standard problem that we currently have to poll the store to find out when it's done with processing the actual upload, and we don't want to lock up a worker waiting for it, so we poll every so often
[15:55] <morphis> Pharaoh_Atem, King_InuYasha: lets see how it goes: https://koji.fedoraproject.org/koji/taskinfo?taskID=18684002
[15:55] <lool> cjwatson: fine with me; I thought I had uncovered a weird case
[15:56] <jdstrand> roadmr: how did you invoke it?
[15:56] <jdstrand> roadmr: (I think I know the issue though)
[15:56] <roadmr> jdstrand: from latest trunk: $ PYTHONPATH=$PWD ./bin/click-review /tmp/hello-classic-tomechangosubanana-1_foo48_amd64.snap
[15:56] <roadmr> jdstrand: maybe you forgot to bzr add overrides?
[15:57] <roadmr> because "ImportError: No module named 'clickreviews.overrides'"
[15:57] <Pharaoh_Atem> morphis: you've already started a scratch build?
[15:57] <morphis> Pharaoh_Atem: yes
[15:57] <roadmr> jdstrand: (and I guess the trace is what the store is complaining about).
[15:58] <morphis> Pharaoh_Atem: tried to a local vm for i386 up but failed .. somehow vbox doesn't want to boot the fedora i386 images
[15:58] <jdstrand> did I forget to bzr add the file?
[15:58] <morphis> Pharaoh_Atem: and mock doesn't want to work on lxd
[15:58] <Pharaoh_Atem> morphis: you could have just done a mock build for i386 on x86_^4
[15:58] <Pharaoh_Atem> *x86_64
[15:58] <jdstrand> crap I did
[15:58] <roadmr> jdstrand: maybe :( so it'd work locally...
[15:58] <morphis> Pharaoh_Atem: tried this but failed :-)
[15:59] <morphis> Pharaoh_Atem: need to play a little bit more and look at what I am doing than just doing it next to a meeting
[16:00] <jdstrand> roadmr: r866. sorry
[16:00] <roadmr> jdstrand: no problem, at least we caught it quickly :)
[16:15] <morphis> Pharaoh_Atem: we're coming closer: https://koji.fedoraproject.org/koji/taskinfo?taskID=18684268
[16:18] <morphis> Pharaoh_Atem: for the ppc64 build I don't have any idea yet
[16:21] <Pharaoh_Atem> morphis: did you ask for a VM in #fedora-ppc yet?
[16:23] <morphis> Pharaoh_Atem: not yet
[16:24] <morphis> mvo, zyga: are we building snapd in ubuntu for ppc64?
[16:27] <Pharaoh_Atem> morphis: you're not in Debian
[16:27] <Pharaoh_Atem> but in Ubuntu, you're building against powerpc and ppc64el
[16:27] <morphis> yeah, just saw that
[16:27] <morphis> just want to get a baseline for things to look in
[16:28] <Pharaoh_Atem> I'm *guessing* that powerpc is the < POWER 7 big endian architectures
[16:28] <Pharaoh_Atem> aka, the 32-bit ones
[16:28] <nacc> Pharaoh_Atem: yes, BE power
[16:29] <Pharaoh_Atem> old BE POWER, but yes
[16:29] <Pharaoh_Atem> morphis: so endianness shouldn't break it :/
[16:30] <morphis> Pharaoh_Atem: it shouldn't
[16:30] <morphis> but also we have go 1.6 vs. 1.8
[16:30] <Pharaoh_Atem> right
[16:30] <morphis> latest we have in ubuntu is 1.7 in zesty
[16:31] <morphis> Pharaoh_Atem: sad that the build log doesn't give any error
[16:35] <morphis> Pharaoh_Atem: also interesting is that this (if the log can be trusted) fails when building golang.org/x/net/context/ctxhtt
[16:42] <Pharaoh_Atem> well, time to test a theory, I guess
[16:43] <morphis> Pharaoh_Atem: drop the guy (sharkcz) a mail to get VM access
[16:46] <Pharaoh_Atem> morphis: you mean you sent him an email
[16:46] <morphis> yes
[16:46] <morphis> s/drop/dropped/
[16:56] <zyga> morphis: yes we do build snapd for ppc64
[16:57] <morphis> zyga: any idea why https://kojipkgs.fedoraproject.org//work/tasks/4273/18684273/build.log fails?
[16:57] <morphis> zyga: our last issue on the way to have snapd in rawhide :-)
[16:57] <renatu> jdstrand, could you please :D? https://myapps.developer.ubuntu.com/dev/click-apps/6676/rev/2/
[16:59] <zyga> morphis: checking
[16:59] <zyga> morphis: sorry, where is the error there?
[17:00] <zyga> that's pretty uncomprehensible to me
[17:00] <morphis> zyga: that is the question :-)
[17:00] <zyga> it looks like /usr/lib/golang/pkg/tool/linux_ppc64/compile -o $WORK/golang.org/x/net/context/ctxhttp.a -trimpath $WORK -p golang.org/x/net/context/ctxhttp -complete -buildid dd5b033021ca065fee8c7c29c22a9306c1500731 -D _/usr/share/gocode/src/golang.org/x/net/context/ctxhttp -I $WORK -I /usr/share/gocode/pkg/linux_ppc64 -pack ./ctxhttp.go fails to compile
[17:00] <morphis> yeah, trying to add a -v to that right now to get more details
[17:01] <zyga> i'd add --quiet to see less noise
[17:01] <zyga> and see just "this is what failed"
[17:01] <morphis> Pharaoh_Atem: did you saw this with your bundled builds too?
[17:01] <jdstrand> renatu: done
[17:02] <Pharaoh_Atem> the patches don't apply
[17:02] <morphis> Pharaoh_Atem: ah
[17:02] <zyga> why would that be only on one arch?
[17:03] <Pharaoh_Atem> it's the only big endian arch
[17:03] <morphis> "patch unexpectedly ends in middle of line"
[17:03] <morphis> but if something wouldn't apply it would fail the build
[17:03] <renatu> jdstrand, thanks
[17:03] <zyga> Pharaoh_Atem: how does that matter for patches?
[17:03] <renatu> jdstrand, did you add it to whitelist?
[17:04] <zyga> Pharaoh_Atem: note that this builds on ubuntu, we don't know what really fails as that log is garbage-ish
[17:04] <jdstrand> renatu: yes
[17:04] <Pharaoh_Atem> zyga: since the systemd unit patches fail to apply, the build stops
[17:05] <zyga> Pharaoh_Atem: aha, do we have any arch-specific patches?
[17:05] <renatu> jdstrand, thanks twice ;)
[17:05] <Pharaoh_Atem> nope
[17:05] <Pharaoh_Atem> the patch that failed was the one that rewrites the systemd unit files to use templates
[17:05] <Pharaoh_Atem> apparently it couldn't find the location to apply the files
[17:06] <zyga> Pharaoh_Atem: I still don't understand how that only fails on ppc64
[17:06]  * Pharaoh_Atem shrugs
[17:06] <zyga> Pharaoh_Atem: I bet I'm missing something :/
[17:06] <morphis> Pharaoh_Atem: where do you see that in the logs?
[17:06] <morphis> + /usr/bin/cat /builddir/build/SOURCES/PR3084-packaging-use-templates-for-systemd-units.patch
[17:06] <morphis> doesn't give any error
[17:07] <Pharaoh_Atem> https://koji.fedoraproject.org/koji/taskinfo?taskID=18685116
[17:07] <Pharaoh_Atem> https://kojipkgs.fedoraproject.org//work/tasks/5116/18685116/build.log
[17:07] <morphis> ah, that is a different build
[17:07] <Pharaoh_Atem> it fails because mvo strips .gitignore
[17:08] <morphis> ah so you're talking about the vendorized build?
[17:08] <Pharaoh_Atem> yes
[17:08] <morphis> ah :-)
[17:08] <morphis> that confused zyga I guess
[17:08] <Pharaoh_Atem> you asked about bundled/vendorized build
[17:08] <morphis> yeah I know
[17:09] <morphis> however close to EOD, will look again into this tomorrow morning
[17:09] <zyga> morphis: you know, just kill ppc64
[17:09] <zyga> and revisit next time
[17:09] <morphis> Pharaoh_Atem: ^^
[17:10] <Pharaoh_Atem> fine
[17:10] <Pharaoh_Atem> I'll do that for now
[17:10] <morphis> zyga: you know, I am pragmatic, I am all in for those things :-)
[17:10] <zyga> while I'd like to see ppc64 flourish the arch is dead dead dead and will stay dead unless something happens
[17:12] <morphis> :-)
[17:13] <Pharaoh_Atem> zyga: we do not support s390x, I guess?
[17:13] <Pharaoh_Atem> or mips?
[17:13] <zyga> Pharaoh_Atem: s390x is "supported"
[17:13] <zyga> Pharaoh_Atem: I think at least
[17:13] <zyga> Pharaoh_Atem: mips no because there's no mips build of ubuntu
[17:14] <zyga> Pharaoh_Atem: mips would be cool but it seems to be dominated by 4MB flash crap devices
[17:17] <Pharaoh_Atem> zyga: Fedora is in the middle of a MIPS bootstrap, which is why I asked
[17:18] <zyga> Pharaoh_Atem: do you know what kind of hardware is used?
[17:18] <Pharaoh_Atem> not yet, no
[17:18] <Pharaoh_Atem> I've not talked to Michel about it
[17:19] <zyga> Pharaoh_Atem: I have a ci20 but I must sadly say it's crap
[17:19] <zyga> Pharaoh_Atem: the kernel crashes in minutes
[17:19] <mup> PR snapd#3116 closed: interfaces: allow executing ld.so (needed with new AppArmor base abstraction) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3116>
[17:25] <Pharaoh_Atem> zyga: I need you to retire snap-confine for me
[17:26] <zyga> Pharaoh_Atem: how do I do that?
[17:27] <Pharaoh_Atem> zyga: fedpkg co snap-confine && fedpkg switch-branch f24 && fedpkg retire "Merged into snapd" && fedpkg switch-branch f25 && fedpkg retire "Merged into snapd" && fedpkg switch-branch f26 && fedpkg retire "Merged into snapd" fedpkg switch-branch master && fedpkg retire "Merged into snapd"
[17:27] <Pharaoh_Atem> err
[17:27] <Pharaoh_Atem> fedpkg co snap-confine && cd snap-confine && fedpkg switch-branch f24 && fedpkg retire "Merged into snapd" && fedpkg switch-branch f25 && fedpkg retire "Merged into snapd" && fedpkg switch-branch f26 && fedpkg retire "Merged into snapd" fedpkg switch-branch master && fedpkg retire "Merged into snapd"
[17:27] <zyga> Pharaoh_Atem: thanks!
[17:27] <zyga> Pharaoh_Atem: I'll do that shortly :)
[17:27] <Pharaoh_Atem> actually, need to change command slightly
[17:27] <Pharaoh_Atem> one second
[17:29] <Pharaoh_Atem> I'm going to merge the commit I already made to all branches
[17:30] <morphis> Pharaoh_Atem: you're going to trigger new builds for snapd now or is that a thing for tomorrow?
[17:30] <Pharaoh_Atem> I'm doing it now, yes
[17:32] <morphis> Pharaoh_Atem: great, then we can call out for testing in the community tomorrow
[17:32] <Pharaoh_Atem> zyga: pkgdb-cli orphan --retire snap-confine f24 && pkgdb-cli orphan --retire snap-confine f25 && pkgdb-cli orphan --retire snap-confine f26
[17:32] <Pharaoh_Atem> zyga: run this asap
[17:39] <zyga> Pharaoh_Atem: ack
[17:39] <Pharaoh_Atem> zyga: I've already retired it from rawhide, and you're the only person who can run it for the older branches
[17:40] <Pharaoh_Atem> building F26 package now
[17:40] <Pharaoh_Atem> at least now the buildsystem will stop bitching about the snapd-glib broken dep
[17:40] <zyga> 60 seconds
[17:42] <zyga> Pharaoh_Atem: it said I must use fedpkg retire first
[17:42] <Pharaoh_Atem> then do that
[17:43] <zyga> ay
[17:43] <zyga> Pharaoh_Atem: push got rejected
[17:43] <zyga> hmmm
[17:44] <zyga> Pharaoh_Atem: hook declined update
[17:44] <Pharaoh_Atem> did you do it with a fresh checkout?
[17:44] <zyga> Pharaoh_Atem: no, with one I had on disk
[17:44] <Pharaoh_Atem> it should already have "dead.package" files on every branch from f24 on up
[17:44] <zyga> Pharaoh_Atem: shall I try with a fresh one?
[17:44] <Pharaoh_Atem> yes
[17:44] <zyga> ok
[17:44] <Pharaoh_Atem> actually a fresh checkout may let you just use pkgdb CLI
[17:44] <Pharaoh_Atem> but try with fedpkg retire
[17:45] <Pharaoh_Atem> if fedpkg retire works, more power to us :)
[17:46] <zyga> Pharaoh_Atem: said I'm not allowed to retire f25
[17:46] <zyga> hmmm
[17:46] <zyga> trying pkgdb
[17:46] <zyga> nope
[17:46] <zyga> any ideas?
[17:47] <Pharaoh_Atem> zyga: pop into #fedora-releng and ask about it
[17:47] <zyga> Pharaoh_Atem: "dead.package found" but then says "no `dead.package' for snap-confine on f24"
[17:47] <zyga> OK
[17:50] <jdstrand> ogra: can you kick off a build for linux-generic-bbb?
[17:54] <Pharaoh_Atem> morphis, zyga: snapd FTBFS on F24 and F25
[17:54] <Pharaoh_Atem> oh wait, I know why
[17:54] <Pharaoh_Atem> because I need buildroot overrides
[17:54] <Pharaoh_Atem> duh
[17:57] <Pharaoh_Atem> zyga: drop your watch commits and approvacls here: https://admin.fedoraproject.org/pkgdb/package/rpms/snap-confine/
[17:57] <zyga> Pharaoh_Atem: trying
[18:00] <zyga> Pharaoh_Atem: I managed to orphan in f24/25
[18:01] <zyga> Pharaoh_Atem: can you check
[18:01] <zyga> Pharaoh_Atem: I'm not sure what to do
[18:01] <Pharaoh_Atem> change your watchcommits to obsolete here: https://admin.fedoraproject.org/pkgdb/package/rpms/snap-confine/acl/watchcommits/
[18:02] <zyga> that's done
[18:03] <Pharaoh_Atem> there, that's taken care of
[18:04] <niemeyer> roadmr: Should be all sorted out, btw
[18:04] <niemeyer> ogra: core-build reporting here too
[18:16] <Pharaoh_Atem> zyga: could you give positive karma on https://bodhi.fedoraproject.org/updates/?packages=golang-github-go-tomb-tomb ?
[18:16] <Pharaoh_Atem> that way it'll cycle out to stable quickly?
[18:17] <zyga> sure
[18:17] <Pharaoh_Atem> all the ones with +2 need good karma
[18:18] <Pharaoh_Atem> that way, they'll sync out with stable updates push in an hour or so
[18:18] <Pharaoh_Atem> at least, I think it's in an hour
[18:18] <Pharaoh_Atem> then I don't have to do too many buildroot overrides
[18:21] <zyga> Pharaoh_Atem: done
[18:21] <zyga> Pharaoh_Atem: gee, I should manage something myself, this feels good
[18:22] <zyga> Pharaoh_Atem: just golang packages are not very interesting "works for me" is hard to tes
[18:22] <zyga> test
[18:57] <jdstrand> kyrofa: to save you time: https://github.com/snapcore/snapd/pull/3112#discussion_r109008576
[18:57] <mup> PR snapd#3112: interfaces: add a joystick interface <Created by kyrofa> <https://github.com/snapcore/snapd/pull/3112>
[18:57] <kyrofa> jdstrand, hahaha, right after I commented, I saw "AppArmor pcre syntax (currently not supported)" in the reference
[18:57] <kyrofa> Felt dumb
[18:58] <kyrofa> jdstrand, the "Documentation of language syntax" above is what misled me
[18:58] <jdstrand> no worries. it looks like regex sometimes, but it isn't
[18:59] <zyga> jdstrand: could you do a quick review for getmntent replacement?
[18:59] <zyga> https://github.com/snapcore/snapd/pull/3103#discussion_r108927742
[18:59] <mup> PR snapd#3103: interfaces/mount: add function for parsing fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3103>
[19:01] <jdstrand> zyga: I cannot, I'm time-shifting today and will be on the road in a few minutes. if you need it today, perhaps ask tyhicks to see if he can put someone on it, otherwise it will have to wait
[19:01] <kyrofa> jdstrand, wait, I'm a little confused. The PR in its current state will allow /dev/input/js. Is your snippet different?
[19:01] <zyga> jdstrand: OK
[19:01] <zyga> jdstrand: it's okay, it's not urgent
[19:01] <kyrofa> jdstrand, you say "if you want to support /dev/js"
[19:02] <zyga> kyrofa: maybe you? it's super short and I have one review already
[19:03] <jdstrand> kyrofa: sorry I wrote the comment too fast. I meant to have input/ in all reference to /dev/js
[19:03] <kyrofa> jdstrand, I know what you meant-- I'm really talking about js with no numbers following
[19:04] <jdstrand> kyrofa: do you want no numbers to be supported too?
[19:04] <kyrofa> jdstrand, at least in my experimentation, it always has a number
[19:05] <jdstrand> kyrofa: then leave it as is. reading https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/devices.txt it seems it always has a number
[19:05] <kyrofa> jdstrand, good deal
[19:06] <zyga> jdstrand: note that update-ns is not setuid root
[19:06] <zyga> jdstrand: it's just a program
[19:06] <Pharaoh_Atem> zyga: I'm sure you have some other interesting software you'd like in Fedora :)
[19:06] <zyga> jdstrand: if someone makes it crash, well, fine (though I think the current code is written in a way that won't easily crash)
[19:06] <jdstrand> kyrofa: actually in reading that I'm reminded that you also want: /run/udev/data/c13:{[0-9],[12][0-9],3[01]} r,
[19:06] <kyrofa> zyga, sorry man, I have no context for that review, I couldn't do it justice
[19:06] <zyga> Pharaoh_Atem: I'll think of something, maybe made in C, without many deps
[19:07] <zyga> kyrofa: no worries, thanks
[19:07] <kyrofa> jdstrand, whoa :P
[19:07] <zyga> kyrofa: I think your brain just exploded
[19:08] <jdstrand> zyga: I know it isn't setuid root. but if an unprivileged user can make snapd call update-ns with arbitrarily controlled arguments, then the unpriv user can try to attack update-ns
[19:08] <kyrofa> zyga, he says it so casually. "By the way, I should probably mention you need this insane glob in there"
[19:08] <zyga> jdstrand: update-ns is only called when we connect/disconnect content
[19:08] <zyga> jdstrand: and the argument is always just the snap name
[19:08] <zyga> jdstrand: no input
[19:10] <kyrofa> jdstrand, is that just where udev places the in-affect rules?
[19:11] <jdstrand> kyrofa: no, that is just some udev info on the device that some libraries like to read. go ahead and cat /run/udev/data/c13:0 if js0 is plugged in
[19:11] <jdstrand> zyga: can you add a comment to the PR that the arguments to update-ns are not user-controllable (like you just did here)
[19:12] <kyrofa> jdstrand, huh, neat
[19:12] <jdstrand> ok, heading out, 'see' you monday :)
[19:12] <zyga> yes
[19:12] <zyga> o/
[19:13] <jdstrand> thanks
[19:22] <pedronis> niemeyer: have you looked at snapd#3113 ?
[19:22] <mup> PR snapd#3113: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3113>
[19:23] <niemeyer> pedronis: Not yet.. after solving a couple of details in the forum, I'm now running through the new threads and opening the PR review requests I found there in new tabs.. then will look through them all
[19:23] <niemeyer> pedronis: I can look at that one now if you can make good use of immediate feedback
[19:26] <JamieBennett> niemeyer: can we please enable other forms of auth on the forum for new users? Apparently its pretty easy to do.
[19:26] <niemeyer> JamieBennett: https://forum.snapcraft.io/t/support-for-sso-on-forum-snapcraft-io/75/5
[19:27] <JamieBennett> Right but it would be good to enable that early no?
[19:27] <pedronis> mvo: there's a bunch of autopkgtest failing with something like: 2017/03/30 18:00:26 Discarding autopkgtest:ubuntu-16.04-amd64, cannot connect: cannot connect to autopkgtest:ubuntu-16.04-amd64: ssh: must specify HostKeyCallback
[19:43] <roadmr> thanks niemeyer ! I just got the confirmation e-mail. Awesome :)
[19:59] <niemeyer> pedronis: Reviewed, if you're not watching the forum
[20:04] <pedronis> niemeyer: yes, answered you concerens in the review and the forum
[20:04] <niemeyer> pedronis: vvv
[20:04] <niemeyer> Man.. that never works well.. it's merged.
[20:04] <mup> PR snapd#3113 closed: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3113>
[20:05] <niemeyer> mup: You're late!
[20:05] <mup> niemeyer: Roses are red, violets are blue, and I don't understand what you just said.
[20:07] <pedronis> niemeyer: thanks, was about to merge it
[20:13] <pedronis> niemeyer: about the aliases gdoc, I was a bit confused by your comments, are you planning to move to a wiki entry in the forum? or something I shoul do?
[20:13] <niemeyer> pedronis: I will.. I have it half-way done and ended up being distracted by other concerns yesterday
[20:13] <niemeyer> pedronis: Should be there by tomorrow
[20:13] <pedronis> ok
[20:13] <pedronis> np
[21:27] <pedronis> niemeyer: I updated snapd#3044 to follow current direction
[21:27] <mup> PR snapd#3044: snapstate: more helpers to work with alias states (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3044>
[21:27]  * pedronis calls it a day
[21:27] <niemeyer> pedronis: Sweet, thanks!
[21:28] <niemeyer> I'm going to (try to) step out as well.. haven't had much sleep lately
[22:09] <cachio> jdstrand, do you know if there is a way to uninstall + install thte same snap without download it again?
[22:15] <kyrofa> cachio, snap download it first
[22:16] <kyrofa> cachio, that will obtain both the snap and its assertion. If you `snap ack` the assertion before installing it, you don't need --dangerous and it'll still update from the store
[22:16] <cachio> kyrofa, awesome, I'll try that, thanks
[22:17] <kyrofa> cachio, I believe you'll only need to `snap ack` once, and install however many times, but don't quote me on that. Removing the snap could possibly remove the assertion
[22:18] <cachio> kyrofa, ok
[22:23] <mwhudson> i don't think assertions are removed at all currently?
[22:24] <mwhudson> not sure either
[22:24] <kyrofa> mwhudson, I suspect you're right, just unverified
[22:26] <mwhudson> what's the easiest way to set up a daily build of a snap in launchpad?
[22:26] <mwhudson> in the case where the branch containing the snapcraft.yaml does not change
[22:27] <mwhudson> presumably i could call the launchpad api from a cronjob but wondering if there is anything neater
[22:29] <kyrofa> mwhudson, I use Travis daily jobs to make a new commit to change the version and force-push to a branch in LP which has a snap building/publishing on changes
[22:29] <kyrofa> mwhudson, gnarly
[22:29] <mwhudson> kyrofa: yeah, that doesn't sound much better than what i said
[22:30] <kyrofa> mwhudson, in fact, I prefer your solution


[09:15]  * ara resyncs some i386 images
[11:20] <davmor2> jibel, ara: probably won't be able to help you too much this cycle I have a fair amount on and my boss is off to :(
[13:18] <charlie-tca> I will be testing hardware only this time. VirtualBox 4.0 in Natty is broken again
[13:18] <jibel> charlie-tca, what is broken ?
[13:18] <jibel> they uploaded a fix 2 day ago.
[13:18] <charlie-tca> can't install with the -38 kernel
[13:19] <jibel> are you sure ? virtualbox-ose has been upgraded to 4.0
[13:19] <jibel> you should uninstall the version from oracle and install this one instead.
[13:19] <charlie-tca> heh, I'm sure. There is a bug on virtualbox tracker for it
[13:19] <jibel> charlie-tca, it's running in front of me on i386 and amd64 :-)
[13:20] <jibel> Linux black 2.6.38-1-generic
[13:20] <charlie-tca> i'm waiting to do anything. Last night the updates wanted to remove all my X Server stuff completely
[13:20] <jibel> yeah, X needs fix
[13:20] <charlie-tca> maybe it is in that mess, now, but I can wait
[13:21] <jibel> charlie-tca, vbox was fixed on Sat, 29 Jan 2011 20:13:14 +0100 to build with kernel -38
[13:23] <charlie-tca> I removed and reinstalled it yesterday and got the same errors
[13:24] <jibel> charlie-tca, ose or oracle ?
[13:25] <charlie-tca> oracle
[13:25] <charlie-tca> still shows 3.2 for -ose in synaptic
[13:25] <jibel> charlie-tca, uninstall it, and install the ose version from the ubuntu rep instead.
[13:26] <jibel> charlie-tca,
[13:26] <jibel> $ apt-cache policy virtualbox-ose
[13:26] <jibel> virtualbox-ose:
[13:26] <jibel>   Installed: 4.0.2-dfsg-1ubuntu1
[13:26] <jibel>   Candidate: 4.0.2-dfsg-1ubuntu1
[13:26] <jibel>   Version table:
[13:26] <jibel>  *** 4.0.2-dfsg-1ubuntu1 0
[13:26] <jibel>         500 http://archive.ubuntu.com/ubuntu/ natty/universe i386 Packages
[13:26] <charlie-tca> I see it today. I will try it
[13:27] <charlie-tca> Thanks, jibel
[13:27] <charlie-tca> jibel: does -ose give you 3d now?
[13:28] <jibel> charlie-tca, yes
[13:28] <charlie-tca> doing it
[13:29] <jibel> charlie-tca, that's the same version than upstream without the proprietary extension packs  (no usb, no e1000 pxe)
[13:29] <charlie-tca> possible power failures today; -18 C today
[13:29] <charlie-tca> It will work for testing then
[13:29] <jibel> oh nice, sunny at least ?
[13:29] <charlie-tca> no, cloudy
[13:30] <jibel> too bad :(
[13:30] <charlie-tca> with 22 mile per hour winds
[13:30] <jibel> it looks like a nice place to avoid ;-)
[13:31] <charlie-tca> I wish :-)
[13:38] <jibel> ara, can you update the topic of the channel please, even if there's no a2 candidate yet ?
[13:44] <ara> jibel, I always forget how to set myself as operator :D
[13:44] <ara> pedro_, ^?
[13:45] <pedro_> ara  /msg  chanserv op #channel
[13:45] <ara> pedro_, thanks
[13:45] <pedro_> you're welcome
[13:53] <jibel> thanks ara
[14:07] <jibel> Hi all,
[14:07] <jibel> thanks for being there to help testing alpha 2 candidates.
[14:08] <charlie-tca> we just keep trying :-)
[14:08] <jibel> unfortunately, X needs fixes and alpha 2 images are not published yet, but that should be done very soonish
[14:09] <jibel> Stay tune folks !
[14:11] <alourie> hello
[14:12] <stgraber> hopefully I'll have my new kvm machine setup by then ;) Nice i7 server with 8GB of RAM and 100Mb/s internet access, that'll make testing a lot faster ;)
[14:13] <alourie> alpha2 images are not up yet, right?
[14:21] <hggdh> jibel, morning, sir. I updated the iso-testing packages, and they are building now for lucid and maverick (natty is already available)
[14:25] <jibel> Good afternoon hggdh, thanks for doing this. I'll think I'll need to update my tests for lucid at least.
[14:25] <jibel> alourie, hello, you're right!
[14:28] <jibel> alourie, we are waiting for new X packages.
[14:31] <hggdh> jibel, no problem. Actually,we need to split it between versions (right now, at least for the server, it is all the same thing...)
[14:42] <alourie> jibel: ah, great
[14:42] <alourie> thanks
[14:47] <tim__> hi guys
[14:47] <jibel> Hi tim__
[14:48] <tim__> im new to testing so how do i get started?
[14:49] <jibel> tim__, thanks for your help. Well at the moment we are waiting for new images, so we are a bit stuck.
[14:50] <tim__> do they release today?
[14:50] <jibel> tim__, during that time if you've not already done so, you can read https://wiki.ubuntu.com/Testing/ISO/Procedures which explains how to test and report results.
[14:50] <tim__> thank you
[14:50] <jibel> tim__, the images to test will be released today, but alpha 2 will be released on thursday.
[14:50] <hggdh> tim__, yes, they will be released today
[14:52] <jibel> tim__, you can also start syncing the current images, this way, once the latest images will be out, you'll just have to sync the difference.
[14:52] <tim__> do you know the percific time because im still in college :)
[14:56] <tim__> i didnt think the alpha 2 would be released today i thought it was half way through it was in middle of febuary
[14:56] <tim__> i just re-read that sentace i fail *face palm*
[15:04] <highvoltage> hey, http://iso.qa.ubuntu.com/ still shows natty alpha 1, shouldn't that be updated for alpha 2 images?
[15:06] <charlie-tca> we don't have alpha2 images yet
[15:08] <jibel> highvoltage and all, the first isos should be available in a bit over an hour and a half.
[15:08] <highvoltage> ok
[15:09] <jibel> during that time you can always sync maverick images to test upgrade test cases once it's ready.
[15:14] <tim__> i have time to get home then :D
[15:20] <tim__> have the important debian freeze been fixed?
[15:20] <tim__> on alpha 1
[15:47] <hggdh> jibel, will the server ISO be reimaged, or just desktop?
[15:51] <jibel> hggdh, cjwatson told me that he would update the tracker when there's something ready for testing.
[15:51] <jibel> and at the moment there's nothing new.
[15:52] <hggdh> jibel, roger, thanks.
[18:19] <charlie-tca> okay, going out for while. will test when I get back.
[18:46] <tim_> hi where can i get the alpha 2?
[18:52] <patrickmw> tim_ alpha 2 candidate is not released yet
[18:52] <tim_> oww
[18:52] <patrickmw> tim_ you can get the latest dev release here though http://cdimages.ubuntu.com/daily-live/current/
[19:25] <skaet> jibel,  cjwatson's just posted ubuntu server images for testing
[19:32] <jibel> hggdh, ^
[19:35] <hggdh> jibel, thanks
[19:36] <hggdh> jibel, Hudson is already on them :-)
[19:36] <jibel> hggdh, you've got a cool job ;-)
[19:36] <hggdh> :-)
[19:37] <hggdh> jibel, now, it just has to work :-)
[19:37] <jibel> hggdh, you could create a hudson job that monitor the server testing jobs, you won't even have to look at the hudson console.
[19:38] <hggdh> jibel, indeed... good idea
[19:48] <jibel> patrickmw, there is a tool called dl-ubuntu-test-iso in the package ubuntu-qa-tools which makes syncing the test images much easier.
[19:49] <patrickmw> jibel, i think you showed me that before
[19:49] <patrickmw> jibel i've been using TestDrive too which has been working ok
[19:50] <jibel> for example to download the xubuntu images on i386 only its: dl-ubuntu-test-iso --flavor=xubuntu --arcg=i386
[19:50] <patrickmw> nice
[19:50] <jibel> you don't have to know the urls on cdimage.u.c
[19:51] <jibel> *--arch
[19:51] <patrickmw> i like how easily we can script the use of the tool
[19:52] <jibel> patrickmw, why do you want to script the use of the tool, it's already a script, if there are missing features you can contribute.
[19:54] <patrickmw> I meant to automation on the greater scheme.. setting up images then automating the config
[19:54] <patrickmw> then running tests, etc
[19:55] <jibel> patrickmw, yeah, you can look at the work from the server team, they are using something similar to sync the images from a hudson job, then run the tests automagically.
[19:56] <patrickmw> :)
[20:21] <jibel> Hey all, kubuntu desktop and alternate posted
[20:21] <jibel> sync and test, go go go
[20:28] <jibel> Who's ready to test kubuntu ?
[20:32]  * fader cranks up the ol' ISO syncing machine.
[20:38] <jibel> I've started kubuntu desktop i386 and amd64
[20:48] <jibel> kubuntu desktop amd64 failed with a ubiquity crash. i386 ok
[20:48] <jibel> starting kubuntu alternate i386 and amd64
[20:49] <pedro_> i'm doing kubuntu alt 386
[20:50] <jibel> okay, since we don't have other images right now, i'll do other test cases for kubuntu desktop
[21:53] <charlie-tca> hm, I'm back. Did I miss anything yet?
[21:59] <jibel> welcome back charlie-tca
[21:59] <jibel> you didn't miss a lot. Still waiting for desktop images.
[22:38] <skaet> xubuntu images have now emerged, and have been pushed out.
[22:41] <charlie-tca> thanks, skaet
[22:44] <fader> Syncing xubuntu desktop amd64 and will start testing it shortly
[22:44]  * fader welcomes any respite from shoveling snow.
[22:45] <charlie-tca> I am syncing too, will start with 386
[22:46] <jibel> thanks skaet
[22:47]  * jibel syncing xubuntu and will test amd64
[22:50] <fader> I'm guessing it's not really worth filing a bug that the wallpaper on the live image says "10.10" yet :)
[22:53] <charlie-tca> won't change until mid march anyway
[22:54] <charlie-tca> but you should have grey panels, xubuntu splash screens, new launcher panel
[22:56] <fader> charlie-tca: Yeah, I figured it wouldn't be until closer to artwork freeze :)
[22:56] <charlie-tca> and I haven't seen it yet, we made the changes, and never got an image since
[22:56] <fader> The new panels and look are really slick though!
[22:56] <charlie-tca> thanks
[22:56] <fader> I like it (except for the part about ubiquity crashing on me twice now :/ )
[22:57] <charlie-tca> hm, yeah, that is not good.
[22:58] <fader> Yeah, reporting a bug now and I'll see if I can narrow down anything that's causing it
[22:58] <charlie-tca> okay
[22:59] <skaet> fader,  can you tell me what version of glew is on the image?
[23:02] <fader> skaet: Sure, one moment
[23:03] <fader> skaet: Nothing matching the string *glew* seems to be installed
[23:03] <fader> libglew1.5 is available but not installed
[23:03] <skaet> fader,  thanks.   my theory isn't valid then.
[23:10] <fader> Hmm, it appears that "shut down" and "reboot" also don't work from the live session... anybody have any idea what package I should tell apport to grab data from to report a bug on that?
[23:10] <fader> (They work from gdm, just not the desktop.)
[23:11] <jibel> fader, gnome-session ?
[23:12] <fader> jibel: That makes sense, thanks
[23:14] <charlie-tca> no
[23:15] <charlie-tca> it's xubuntu, we don't use gnome-session
[23:15] <charlie-tca> let me look it up
[23:15] <charlie-tca> you can always report agains xubuntu-meta  or   xfcd4-session
[23:16] <charlie-tca> s/xfcd4-session/xfce4-session
[23:17] <fader> D'oh, I'll invalidate that one and report it against the right package
[23:17] <fader> Thanks, charlie-tca
[23:17] <charlie-tca> thanks
[23:17] <charlie-tca> it makes it easier to get the xubuntu devs to look if they can find it
[23:18] <fader> Hehe indeed :)
[23:21] <fader> Launchpad, why you got to make me hit you?
[23:23] <skaet> ubuntu alternate is up on the iso tracker now
[23:27] <fader> skaet: If the same bug is breaking multiple test cases do you want it marked in the tracker multiple times?
[23:27] <fader> (E.g. ubiquity is crashing which pretty well kills all the test cases)
[23:27] <skaet> fader, no point in multiple.
[23:27] <fader> I think it might be useful data to see that it's affecting multiple test cases but if that gets in the way I won't do it
[23:28] <fader> skaet: Roger, thanks
[23:28] <skaet> fader: do you have a bug number?   might want to get the dx folk looking at it now.
[23:28] <jibel> fader, bug number ?
[23:28] <fader> skaet: Hmm, there's one I can't go back and clear that I already put in, sorry :(
[23:29] <fader> skaet: bug 711557
[23:29] <ubot4> Launchpad bug 711557 in ubiquity (Ubuntu) "ubiquity crashed with TypeError in changed(): value is of wrong type for this column (dup-of: 702898)" [Undecided,New] https://launchpad.net/bugs/711557
[23:29] <ubot4> Launchpad bug 702898 in ubiquity (Ubuntu) "ubiquity crashed with TypeError in changed(): value is of wrong type for this column (affects: 18) (dups: 7) (heat: 84)" [High,New] https://launchpad.net/bugs/702898
[23:29] <skaet> fader, no worries.  :)
[23:30]  * fader starts syncing ubuntu alternate amd64.
[23:30] <hggdh> ah hell. Eucalyptus fails on every instance startup
[23:30] <fader> :(
[23:31] <fader> hggdh: I blame the koalas.
[23:33] <charlie-tca> I really am syncing my image... really
[23:33] <hggdh> fader, bloody koalas
[23:37] <charlie-tca> finally, got the 386 desktop image starting to test
[23:47] <charlie-tca> fader: did you find the hidden panel at the bottom of the desktop?
[23:47] <fader> charlie-tca: Yep, totally by accident :)
[23:51] <charlie-tca> hm, 386 live cd shut down after showing the error
[23:51] <charlie-tca> (on hardware)


[15:51] <jawn-smith> So hey waveform you haven't tested these images on a CM4 at all yet, right?
[15:51] <waveform> correct
[15:52] <waveform> I'm just finishing off the desktop tests, and will get to them after that if you haven't beaten me to it :)
[15:52] <jawn-smith> having an issue with USB inputs on arm64. config.txt looks reasonable to me, so I'm going to go get a different keyboard to try, and also try the armhf image
[15:52] <jawn-smith> hopefully this is PEBKAC
[15:52] <waveform> this on the official IO board?
[15:53] <jawn-smith> yes
[15:53] <waveform> (and yes, there should be a [cm4] section in config.txt that sets the dwc2 overlay into host mode, which is required for the USB2 ports on the IO board to operate)
[15:55] <jawn-smith> yeah that was the first thing I checked
[15:56] <jawn-smith> other keyboard didn't work, let's try flashing armhf
[15:57] <jawn-smith> I seem to recall this happening on a previous image
[15:58] <waveform> okay, all done with desktop testing, I'll dig out my CM4 and see if I can replicate
[15:59] <jawn-smith> I'm flashing armhf now but you know how slow this eMMC is...
[15:59] <waveform> oh yeaaaaah
[16:14] <jawn-smith> USB keyboards aren't working on armhf either. Gonna ssh in and poke around
[16:15] <jawn-smith> just as soon as I figure out which of the Pis on my home network this is...
[16:24] <waveform> okay, finished flashing my CM4, will fire it up and see if I can replicate
[16:25] <jawn-smith> let me know, I'm starting to wonder if my IO board is fried
[16:30] <jawn-smith> I'm gonna flash lunar as a baseline check
[16:30] <waveform> okay, working for me
[16:31] <waveform> (this is on arm64)
[16:32] <jawn-smith> huh
[16:33] <waveform> specifically, this is with an rpi keyboard (which has a USB hub in it, but nothing plugged into the hub)
[16:52] <waveform> jawn-smith, okay, I have to take a break from testing and go parent but if you can figure out what's up with the keyboard issue the armhf image on CM4 is the last thing I haven't certified yet (or either arch on the CM4 lite because I don't have one) so either of those is a priority. I think everything else I can do is now done though
[16:53] <waveform> jawn-smith, oh one other thing in case you have a 3B+ (specifically) lying around is any investigation (or replication of) LP: #2038964 is most welcome!
[16:53] <jawn-smith> Okay, I'm flashing lunar now. And I have plenty of 3B+ laying around
[18:02] <waveform> right, I'm back, taking another look at the 3B+ issue
[18:06] <waveform> oh ... there's two issues here. Firstly, that the 6.5 kernel seems to be re-initializing the lan78xx driver, where the 6.2 kernel didn't (per Juerg's addition to the issue) but secondly that this causes the device to rename (yet again). But ... oh no, I've got an idea how to fix this (or at least workaround it)
[18:06] <waveform> (I say "oh no" because if this work's the release team is liable to kill me :)
[18:07] <waveform> *works
[18:08] <waveform> the reason it's flip-flopping is that the end state of the rename ("eth0") no longer matches the required state to trigger the rename ("en*"), while the later rule to decide MAC-based naming *does* still match and so the system flip-flops between the two rules. If the first rule matched *both* states it won't flip-flop anymore
[18:12] <waveform> it works ... now I have to go talk to the release team ... >.<
[18:21] <waveform> jawn-smith, specific fix: in /lib/systemd/network/10-raspi-eth0.link OriginalName=en* eth0
[18:23] <jawn-smith> want me to jam that in to test it?
[18:28] <waveform> sure, can't hurt to double-check (I've just tried it on my 3B+ and it worked happily -- I *should* check it on other Pis as well, but I'll wait to hear from the release team is another re-spin is even possible at this stage)
[18:29] <waveform> proposed change is here: https://code.launchpad.net/~waveform/ubuntu/+source/ubuntu-settings/+git/ubuntu-settings/+merge/453340
[18:41] <jawn-smith> okay I'm in a meeting at the moment but will give it a spin after
[18:42] <waveform> ta -- I've got to go parent again for a while, will be back later


  I litterally searched around in your useless menu system for 45 minutes looking for specific application only to come up empty handed.
[01:58] <destructifier> Tutorials on the web explaining how to uninstall and switch back to gnome were completely useless. I'm guessing you guys had too many people jumping ship so you made it impossible to switch.  The option is simply not there.
[01:58] <destructifier> FUCKYOU AND YOUR SHITTY SOFTWARE
[01:59] <destructifier> TRIED UNINSTALLING YOUR SHIT AND IT COMPLETELY HOSED MY SYSTEM.
[02:14] <Daekdroom> I see so many things that guy did wrong in order to reach this point
[02:40] <ESphynx> Hey guys... Is it going to be possible to bring the dock to the RIGHT in Quantal? Please?
[02:40] <ESphynx> Simple reason why Right is that most people (probably including lefties) handle their mouse with their right hand, and to quickly access the dock you go far out to the end of the screen. Now obviously your wrist is more flexible rotating towards the right (and you are stuck with your keyboard on the left anyways).
[02:40] <ESphynx>  It'd also be really nice if by default when you click on the Launch button you could see the terminal, like, 'right there',  out of appreciation for the fact that Linux is traditionally a geek OS.
[02:46] <Daekdroom> You can always leave a terminal fixed in the 'dock'.
[02:47] <ESphynx> Daekdroom: you ca, but I'm talking about the very first Ubuntu impression.
[02:47] <ESphynx> can*
[02:47] <Daekdroom> I have the impression that Ubuntu does not want to give a first impression of a geek OS.
[02:47] <ESphynx> I had an extremely frustrating 2 minutes of searching for the terminal on my first try of Quantal.
[02:48] <ESphynx> but that is not good.
[02:48] <ESphynx> The non-geek user won't even notice the terminal there.
[02:48] <Daekdroom> How did it take you 2 minutes? Did you not see you can type "terminal"?
[02:48] <Daekdroom> (If you didn't see you can type it, then yeah, it's a problem)
[02:48] <ESphynx> no I expected an icon somewhere easy to find in that menu
[02:48] <ESphynx> and I did not.
[02:48] <ESphynx> I did not want to type, I wanted to click.
[02:49] <ESphynx> if I wanted to type, I would have just stayed in the virtual tty.
[02:49] <ESphynx> previous Ubuntu versions had a terminal icon right there... RedHat as a very obvious terminal icon
[02:50] <ESphynx> It's completely nice that Ubuntu wants to be user-friendly and an OS my grandma can use, but it's not good if power users don't find themselves at home anymore.
[02:51] <Daekdroom> I think it's fairly power-user friendly.
[02:51] <Daekdroom> I can do <Super> gnome-terminal <enter>
[02:51] <ESphynx> I personally hate the whole direction of Unity... but I'm hoping it could be made slightly better by these simple improvements.
[02:51] <ESphynx> that is not
[02:51] <ESphynx> friendly at all
[02:52] <Daekdroom> It's keyboard-only.
[02:52] <ESphynx> like, at all.
[02:52] <ESphynx> I know I can do term[enter]
[02:52] <ESphynx> which is already much better
[02:52] <ESphynx> but still.
[02:52] <ESphynx> I just want to do 2 clickst
[02:52] <ESphynx> to start a terminal
[02:52] <ESphynx> click, click. boom I'm in a terminal. that's how any Linux should be imo.
[02:53] <ESphynx> the whole Idea of categorization and recently used program I hate also... to actually find the terminal I have to go through that
[02:53] <ESphynx> and the terminal might be really far away, and I have to start thinking 'hmm, where would the terminal be?'
[02:53] <ESphynx> start/accesories/terminal ... is still reasonable
[02:54] <veebers> ESphynx: Once you've opened the terminal once you can lock it to the launcher so it's only 1 click :)
[02:54] <ESphynx> veebers: yes... but again it's that first impression .
[02:54] <veebers> ESphynx: also Ctrl-Alt t should open a terminal
[02:54] <ESphynx> I had a very bitter first impression.
[02:55] <ESphynx> yes... but there is no way to know that if you're a new power user on Ubuntu
[02:55] <ESphynx> I just wish to avoid the frustration of new power users trying out Quantal for the first time
[02:55] <Daekdroom> ESphynx, I think it's very unlikely for someone to be having their first impression and wanting to find the terminal.
[02:55] <ESphynx> Daekdroom: a terminal is the very first thing I want to see in a new OS.
[02:56] <veebers> ESphynx: Sure understood. but, by at least my own under standing of 'power user', a power user will find this out quickly and use it in the future
[02:56] <ESphynx> i'm trying out an OS. welcome screen, ok, where's my terminal?
[02:56] <Daekdroom> It's the first time I see someone complain about the terminal being too difficult to find at first..
[02:56] <ESphynx> well I raged in here once before! :P
[02:56] <ESphynx> guess you weren't around P
[02:56] <ESphynx> :P
[02:57] <veebers> ESphynx: there are also alot of people that would be turned off if the first thing they saw was a terminal
[02:57] <ESphynx> (at the time when I just had that 2 minute frustration :P)
[02:57] <ESphynx> veebers: are there? i'm talking about a terminal 'link', not the actual terminal :P
[02:57] <veebers> ESphynx: I love being able to hit <super> start typing <something> and hit enter
[02:58] <veebers> ESphynx: although i admit it wasn't the first thing I tried
[02:58] <veebers> ESphynx: ah ok understood
[02:58] <ESphynx> I'm okay with Linux becoming user friendly, but not OK with sacrificing pleasing power users for it...
[02:58] <ESphynx> I mean even on Windows 7
[02:58] <ESphynx> I can click Start, All programs, Accessories, and there's my Command Prompt
[02:59] <ESphynx> I hate how All programs became less obvious than Programs before...
[02:59] <ESphynx> All programs is so not in Focus... but to me that should be the menu that pops up, along with a type box (which I admit is nice)
[03:00] <ESphynx> You click Super, and you see your categories (Accessories, Development, Documents, whatever...) and then your type box active by defualt at the bottom
[03:00] <ESphynx> is how I would like to be.
[03:01] <ESphynx> anyway. just a suggestion :) I'd be very happy if the terminal was easier to find.
[03:01] <ESphynx> any chance to be able to move the dock to the right? :)
[03:02] <ESphynx> (I had a very rough start with Unity. Alt-Tab used to crash the system.)
[03:02] <ESphynx> i.e. in previous Ubuntu version. I believe that's no longer an issue :P
[06:37] <Mirv> anyone trying out compiz <IP_ADDRESS> will bump into this bug https://bugs.launchpad.net/ubuntu/+source/gsettings-desktop-schemas/+bug/1050216
[06:37] <Mirv> can be fixed manually by gsettings set org.gnome.desktop.wm.preferences button-layout 'close,minimize,maximize'
[06:53] <didrocks> Mirv: the default is 'close,minimize,maximize:'
[06:54] <didrocks> what did you test exactly?
[06:55] <Mirv> didrocks: ah, should be ":" in the end?
[06:56] <didrocks> Mirv: yeah, but that's the default
[06:56] <Mirv> didrocks: it's not after gtk-window-decorator starts using gsettings and the default from gsettings-desktop.schemas
[06:56] <Mirv> so if one upgrades to <IP_ADDRESS> from eg. ppa:timo-jyrinki/compiz-withoutgconf then buttons are on the right side
[06:56] <didrocks> Mirv: are you sure you had the default set?
[06:57] <Mirv> didrocks: what do you mean, where? the buttons are on the right side also in guest session.
[06:57] <didrocks> Mirv: I think your bug is different, the default is already close,minimize,maximize:
[06:57] <Mirv> didrocks: it's not in the schema file of gsettins-desktop-schemas
[06:57] <didrocks> so maybe compiz is not reading the real value
[06:57] <didrocks> Mirv: because it doesn't work like that, we don't sed the schemas
[06:57] <didrocks> we have overrides files
[06:58] <didrocks> try this:
[06:58] <didrocks> gsettings reset org.gnome.desktop.wm.preferences button-layout
[06:58] <didrocks> gsettings get org.gnome.desktop.wm.preferences button-layout
[06:58] <didrocks> what do you get?
[07:01] <Mirv> didrocks: on current quantal version, in guest session, :minimize,maximize,close
[07:01] <Mirv> with https://code.launchpad.net/~timo-jyrinki/ubuntu/quantal/gsettings-desktop-schemas/fix_button_layout/+merge/124106 , the correct one
[07:01] <didrocks> Mirv: do you have /usr/share/glib-2.0/schemas/10_ubuntu-default-settings.gschema.override installed?
[07:02] <Mirv> didrocks: no, it does not look so
[07:03] <didrocks> Mirv: so, this is your bug, you need to have ubuntu-default-settings installed
[07:03] <didrocks> it's a dep of ubuntu-desktop metapackage
[07:03] <Mirv> didrocks: ah.. suddenly things start to make sense. at some point I've lost ubuntu-desktop. marking bug as invalid
[07:04] <didrocks> Mirv: let me just paste the conversation here, maybe that can help other people :)
[07:04] <Mirv> :D
[07:05] <didrocks> Mirv: can you reject your merge request as well?
[07:05] <didrocks> Mirv: so, basically, as a rule of thumb: we don't patch gsettings values for GNOME components, but uses those overrides
[07:06] <didrocks> this enables us to:
[07:06] <didrocks> - not have yet another patch to rebase regularly
[07:06] <Mirv> sure
[07:06] <didrocks> - have some overrides with the ubuntu config just in one package
[07:06] <didrocks> - enable flavors to not install this package and have different config
[07:06] <didrocks> (like the GNOME remix one)
[07:12] <Mirv> we should have a functional session without ubuntu-default-settings though, too, but definitely not a bug in gsettings-desktop-schemas :)
[07:13] <didrocks> oh, you mean not having it -> the guest session doesn't start even?
[07:14] <Mirv> didrocks: it starts, but heavily broken. I'm filing a bug right now.
[07:15] <didrocks> Mirv: ok, let me know so that I can see the description :)
[07:15] <didrocks> Mirv: you should just have different settings, like "not ubuntu feeling", but it should be usuable
[07:22] <Mirv> didrocks: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1050237
[07:23] <Mirv> maybe simply a nautilus related problem instead of compiz, but if you can figure out more please change
[07:24] <Mirv> you should be able to reproduce it by simply removing ubuntu-default-settings and starting a guest session
[07:25] <Mirv> so moved to #ubuntu-desktop
[07:29] <duflu> Mirv, didrocks: The trails can probably only happen if the window on the desktop is broken. Because a working window will damage and redraw correctly. And no window will be shown as just wallpaper (drawn by compiz)
[07:30] <didrocks> duflu: not that complicated :)
[07:30] <didrocks> duflu: look my explanation on other channels :)
[07:30] <didrocks> it's not the desktop window which is broken
[07:30] <didrocks> it's just there is nothing handling it
[07:31] <didrocks> duflu: I also added some explanation on the bug report
[07:32] <Mirv> I'm so happy when things get a logical explanation... I started to be puzzled. it's quite many times when things not working is explained by ubuntu-desktop (and friends) missing.
[07:33] <didrocks> Mirv: yeah, I prefer as well having the precise ins and outs of an issue :)
[07:34] <didrocks> quite difficult sometimes for everyone as the stack and components interacting and quite… huge :)
[07:34] <didrocks> are*
[07:34] <Mirv> didrocks: with that, we'd finally also be back in business with compiz, but there is choice to be made - whether to start testing <IP_ADDRESS> as is or wait for FFe approval of bug #1047067? we'd now have a fixed expo patch available
[07:35] <didrocks> Mirv: try to ping some release team member to get the FFe acked
[07:35] <Mirv> didrocks: ok
[07:35] <didrocks> Mirv: it shouldn't be difficult IMHO as it's basically a regression fix :)
[07:38] <duflu> didrocks, Mirv: Sounds like bug 1050237 is out of the control of compiz. What project should it be?
[07:38] <didrocks> duflu: well, compiz should probably do as gnome-shell arguably: if nothing draws the desktop, handling it
[07:38] <duflu> didrocks: Already does
[07:38] <duflu> See the bug
[07:39] <didrocks> duflu: saw that, but it doesn't apparently?
[07:39] <duflu> What we cannot handle is some app creating a window over the desktop and then failing to draw to it
[07:39] <didrocks> at least for Mirv
[07:39] <didrocks> duflu: nautilus doesn't create a window AFAIK
[07:39] <didrocks> duflu: it does nothing here
[07:39] <duflu> didrocks: Yes it does
[07:39] <duflu> Just usually not visible cos it's the same as the default wallpaper
[07:39] <didrocks> ah, so it's a bug in nautilus, it shouldn't in that case
[07:40] <didrocks> duflu: with the option off?
[07:40] <didrocks> duflu: that's what you tried?
[07:40] <duflu> didrocks: I haven't tried anything, but I know from recent fixes how it gets drawn
[07:41] <duflu> At the bottom, compiz opengl plugin always paints the wallpaper
[07:41] <duflu> Next, usually, nautilus is running and repaints the wallpaper, plus icons etc
[07:41] <didrocks> duflu: so, here is what the bug is about
[07:42] <didrocks> duflu: I think you misread/I didn't explain it right
[07:42] <didrocks> duflu: in Mirv's case, without the override, the default is "nautilus don't draw the background"
[07:42] <didrocks> this is why you see this trail here
[07:42] <duflu> But it still creates a window
[07:42] <didrocks> that's my question, did you confirm this?
[07:42] <duflu> which is on top of what the opengl plugin paints
[07:43] <duflu> So the trails are still nautilus
[07:43] <didrocks> duflu: ^
[07:43] <duflu> didrocks: How? Just remove the package and log in guest?
[07:45] <didrocks> duflu: org.gnome.desktop.background show-desktop-icons, set that to false
[07:45] <didrocks> then, you can kill nautilus
[07:46] <Mirv> I re-tested it myself by apt-get remove ubuntu-default-settings and launching guest session
[07:51] <duflu> didrocks, Mirv: Nope, tried all that and still no bug :/
[07:56] <Mirv> :( still a mystery, then
[07:57] <Mirv> except for that like I said, on guest ps ax | grep nautilus shows nothing
[07:57] <Mirv> for me
[07:57] <didrocks> yeah, nautilus isn't started in that case
[07:57] <didrocks> so it seems compiz doesn't fallback
[07:57] <Mirv> unless ubuntu-default-settings is installed
[07:57] <didrocks> Mirv: right, and again, this is expected :)
[07:58] <Mirv> ok, good..
[12:07] <Mirv> didrocks: FFe approved, please merge lp:~timo-jyrinki/ubuntu/quantal/compiz/fix_expo to lp:ubuntu/compiz so we have the fixed expo in and enabled
[12:08] <didrocks> Mirv: sweet! done :)
[12:09] <Mirv> thanks!
[12:10] <didrocks> yw :)
[14:20] <tjaalton> is it possible to run compiz with GL on quantal, in order to verify drivers being broken/getting fixed?
[16:30] <davidcalle> JohnLea, ping?
[20:59] <mhr3_> bschaefer, ping?
[20:59] <bschaefer> mhr3_, a bit late for you isn't it?
[20:59] <mhr3_> oh yey :)
[20:59] <mhr3_> bschaefer, could you re-approve the branches we approved today but failed?
[20:59] <mhr3_> start light to see if the mergers work now :)
[21:00] <mhr3_> that's all :)
[21:00] <bschaefer> mhr3_, alright! They should be in my email :)
[21:00] <mhr3_> bschaefer, and thanks
[21:00] <bschaefer> or active reviews
[21:00] <mhr3_> ;)
[21:00] <bschaefer> np :)
[21:00] <bschaefer> have a good night!
[21:00] <mhr3_> thanks
[21:00]  * mhr3_ hopes to wake up to an awesome day where everything is merged :)