[04:34] <mithrison> hi
[04:34] <mithrison> I'm having problem running snap and snapcraft on ubuntu 18 server on raspberry pi.. details and logs --> https://forum.snapcraft.io/t/multipass-on-raspberry-pi-3b/12162/2
[04:40] <amurray> mithrison: looks like this is a known issue https://github.com/CanonicalLtd/multipass/issues/770
[04:42] <mithrison> amurray Is it an issue with Ubuntu 18 specifically?
[04:42] <amurray> mithrison: the ubuntu 18.04 raspberry pi kernel does not support kvm - see https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1783961 for more info
[04:44] <mithrison> So use 16? amurray
[04:45] <mithrison> the proper way to enable KVM support on any pi is to set:dtoverlay=vc4-kms-v3din the config.txt file of the bootloader, the kernel is specifically set up for this via the included raspberry pi foundation patches.
[04:45] <mithrison> That's exactly what I did BTW
[04:46] <amurray> mithrison: hmm ok - sorry I am not sure (am not a rpi expert) ogra ^^^ ?
[05:19] <mborzecki> morning
[06:00] <zyga> Hey
[06:01] <mborzecki> zyga: hey hey
[06:53] <zyga> mborzecki: I have an errand in the morning
[06:53] <zyga> I sent a small python PR
[06:53] <zyga> I have more on GH but after this one
[06:53] <zyga> I will be online in about an hour
[06:53] <mborzecki> zyga: i reviewed 2 python prs from you, is that something new?
[07:00] <mvo> hey hey, what did I miss yesterday?
[07:01] <mborzecki> mvo: hey, probably not much, thursday felt a bit slow
[07:01] <mvo> mborzecki: 'k
[07:02] <mvo> mborzecki: I think I owe you a review, what was the PR again?
[07:02] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/7041 :)
[07:03] <mvo> aha, yes
[07:03] <mvo> doing that now before anything else gets in the way
[07:10] <mborzecki> mvo: thank you!
[07:25] <pstolowski> mornings!
[07:27] <mvo> hey pstolowski, good morning
[07:27] <mborzecki> pstolowski: hey
[07:48] <mborzecki> mvo: about post staging callback, for instance i'm using it to copy bootenv files generated by snap prepare-image to the structure that contains system-boot data
[08:05] <zyga> re
[08:05] <zyga> mborzecki: looking now, sorry, some stuff took longer than we expected
[08:09] <zyga> mborzecki: replied to both https://github.com/snapcore/snapd/pull/7065 and https://github.com/snapcore/snapd/pull/7068
[08:09] <zyga> hey mvo
[08:11] <mvo> hey zyga - in a meeting right now
[08:12] <zyga> mvo: hey, nothing urgent, just wanted to say hi :)
[08:12] <zyga> pstolowski, mborzecki: if you guys +1 https://github.com/snapcore/snapd/pull/7068 I will open a small follow-up and then we have the path towards those namespace tests :)
[08:13] <zyga> there are two more python changes needed but they are much simpler than even this simple pr :)
[08:26] <mborzecki> mvo: https://github.com/bboozzoo/snapd/blob/bboozzoo/gadget-update-wip
[08:27] <mborzecki> mvo: https://github.com/bboozzoo/snapd/blob/bboozzoo/gadget-update-wip/c
[08:27] <mborzecki> mvo: 3rd time's the charm: https://github.com/bboozzoo/snapd/tree/bboozzoo/gadget-update-wip
[08:36] <zyga> pstolowski: https://bugs.launchpad.net/snappy/+bug/1835342
[08:36] <zyga> what do you think?
[08:37] <pstolowski> zyga: woah, let me take a look
[08:38] <zyga> pstolowski: I guess that now with snap connections we  just show something we  always had and did
[08:40] <pstolowski> hmm, our parsing errors aren't very nice: error: cannot pack "/home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/snap-failing-interface-hooks": cannot parse snap.yaml: yaml: unmarshal errors:
[08:40] <pstolowski>   line 3: cannot unmarshal !!seq into map[string]interface {}
[08:42] <zyga> yeah
[08:42] <zyga> what is !!seq?
[08:43] <zyga> https://github.com/snapcore/snapd/pull/7065 is green, just needs reviews
[08:43] <zyga> +52,-1, all python test code
[08:45] <pstolowski> zyga: probably the array: "plugs: [home,network]"
[08:48] <pstolowski> zyga: re that bug, i suspect on refresh we don't remove obsolete plugs from conn state (only from the repo), and 'snap connections' shows conns from state; reloadConnections bites again
[08:50] <zyga> pstolowski: that's correct
[08:50] <zyga> pstolowski: on rollback we'd not restore connections otherwise
[08:50] <zyga> pstolowski: perhaps we should allow snap disconnect to remove stale connections that are not represented in the repo?
[08:51] <pstolowski> zyga: +1. also, i wonder if restart cures it (stray connections cleanup logic)
[08:51] <zyga> pstolowski: hmm, indeed
[08:52] <pstolowski> zyga: and maybe that's the explanation of entire stray connections issue that this cleanup was made for
[08:53] <pstolowski> we blamed some unknown bug in old snapd
[08:53] <zyga> I think we always knew this  part
[08:53] <zyga> that snaps can change interfaces over revisions
[08:53] <zyga> and  we don't do anything about the connections
[08:53] <zyga> we chose not to remove them early on
[08:53] <zyga> and  later on did
[08:54] <pstolowski> zyga: ah, we simply never shown them
[08:54] <zyga> until we grew snap connections
[08:54] <pstolowski> yes
[08:55] <zyga> brb, moving
[09:03] <pstolowski> zyga: i can take this bug after i finish current work on connects
[09:03] <zyga> yeah, no rush
[09:13] <pstolowski> zyga: updated the bug report
[09:20] <zyga> thanks
[09:28] <zyga> re
[09:28] <zyga> ondra: thanks for the call, I learned useful things
[09:29] <ondra> zyga and thank you for looking into this :)
[09:30] <mborzecki> zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1726382#c6
[09:30] <zyga> looking
[09:32] <zyga> mborzecki: it is helpful to the  reporter but I think we will eventually entirely do runtime detection or static declaration that must be provided by the distribution
[09:32] <zyga> mborzecki: in either case it is useful to the reporter, thank you
[09:33] <zyga> I need a 2nd review (thanks mborzecki) for simple python function https://github.com/snapcore/snapd/pull/7065
[09:37] <pstolowski> looking
[09:39] <zyga> pstolowski: thank you!
[09:43] <zyga> eh, travis has stale state
[09:46] <zyga> pstolowski: thank you!
[09:47] <zyga> pstolowski: would you mind doing another one in the same file: https://github.com/snapcore/snapd/pull/7068
[09:48] <pstolowski> zyga: sure. has conflicts though
[09:48] <zyga> aww, one sec
[09:52] <zyga> pstolowski: resolved
[09:55] <zyga> mborzecki: wow https://github.com/rswier/c4
[09:56] <pstolowski> zyga: 1-1 in a moment, will take a look afterwards
[09:56] <zyga> thank you
[09:56] <mborzecki> zyga: reads like an entry to ioccc
[09:59] <pstolowski> zyga: i'm working on a spread test with a failing connect- hook (just exit 1); what's the reason i see multiple debug messages like this in the failing task log: https://paste.ubuntu.com/p/M3J7gVrDjX/
[09:59] <pstolowski> ?
[10:00] <zyga> you must have SNAPD_DEBUG=1 or SNAP_CONFINE_DEBUG=yes  set
[10:29] <zyga> brb
[10:31] <pstolowski> zyga: got it; i think it would make sense to give more context in that message, and if possible show it just once
[10:31] <zyga> pstolowski: it cannot be shown once
[10:31] <zyga> pstolowski: each one is a real mount happening
[10:31] <zyga> pstolowski: it's spread all over the code
[10:31] <pstolowski> zyga: ah, got it
[10:31] <zyga> pstolowski: I lament that we cannot show you what is going on
[10:31] <zyga> pstolowski: but i fought that battle and lost
[10:31] <zyga> pstolowski: and we only show what is mounted when we die :/
[10:32] <zyga> pstolowski: or when we run debug build
[10:33] <mborzecki> zyga: hm mountsnoop maybe? it's from bcc
[10:34] <mborzecki> zyga: uh, nvm, thought you wanted to track all the mounts ;)
[10:35] <zyga> Nah, just print a debug message
[10:43] <zyga> pstolowski: replied, thanks for looking
[10:52] <pstolowski> zyga: one more comment
[10:52] <zyga> looking
[10:56] <zyga> pstolowski: fixed! thank you
[10:57] <pstolowski> zyga: should we have a simple test for that?
[10:57] <zyga> pstolowski: main is untested but now we can add actual tests easily, yeah
[11:07] <zyga> pstolowski: pushed  :)
[11:08] <pstolowski> ty
[11:09] <pstolowski> +1
[11:13] <zyga> pstolowski: thanks, I'll add more tests in a separate PR
[11:55]  * zyga goes for lunch
[12:20] <vidal72[m]> is this being worked on? https://bugzilla.redhat.com/show_bug.cgi?id=1438079
[12:26] <sergiusens> zyga: hye, do you still want review? got your notification as I was taking off flying over to my parents with my eldest for the winter break
[12:31] <zyga> re
[12:31] <zyga> sergiusens: thank you, it's all good
[12:31] <zyga> vidal72[m]: checking
[12:32] <zyga> vidal72[m]: no, not at present
[12:32] <zyga> vidal72[m]: we don't have anyone idle that can jump into it, we have other commitments first
[12:32] <zyga> pstolowski: more tests https://github.com/snapcore/snapd/pull/7069
[12:33] <zyga> vidal72[m]: I will likely work on it but I don't control my work queue directly
[12:36] <zyga> mborzecki, pstolowski: essential but simple https://github.com/snapcore/snapd/pull/7070
[12:36] <zyga> just use what we've built
[12:38] <zyga> I tried to explain why this is useful for the upcoming namespace tests
[12:41] <zyga> I only have one more branch to propose for mountinfo-tool (that I know of) for the test branch to be useful
[12:41] <zyga> but we are super close now
[13:43] <ogra> mvo, i seem to remember you had a patch to timedated that prevented the symlink issues we had with it ... couold it be that this patch got lost ? (seems abeato is running into the issues we had before that again)
[13:58] <mvo> ogra: possible, I resurrected two patches around this area but maybe I missed one
[13:59] <ogra> yeah, they are quite old (from pitti originally i think ... around 15.04)
[14:01] <zyga> mvo: second review for https://github.com/snapcore/snapd/pull/7069 pretty please?
[14:02] <zyga> just unit tests for python
[14:04] <mvo> zyga: in a meeting right now
[14:04] <zyga> mvo: no worries, thanks
[14:04] <zyga> mborzecki, pstolowski: https://github.com/snapcore/snapd/pull/7071 one more python renumbering pR
[14:05] <zyga> this time with tests up front :)
[14:06] <zyga> oh, sergio is off?
[14:06] <zyga> ah right I remember now
[14:14] <zyga> actually
[14:15] <zyga> ijohnson: can you look at https://github.com/snapcore/snapd/pull/7071 and https://github.com/snapcore/snapd/pull/7069
[14:15] <zyga> I think you will use this tool a lot
[14:15] <ijohnson> zyga: sure
[14:15] <zyga> mountinfo-tool is a bit like findmnt, but more tailored to what we do
[14:15] <zyga> the context is that I'm extending it to propose a new spread test that measures the configuration of the mount namespace
[14:16] <zyga> and the extensions are mainly to build a deterministic view of the mount table
[14:16] <zyga> with things like memory size or boot ordering of cgroup mount units neutered
[14:16] <zyga> the tool started without any tests so I'm also adding some small unit tests as I go
[14:16] <ijohnson> zyga: interesting yes that sounds very useful I will look into mountinfo-tool today
[14:17] <zyga> in spread debug shell it is on path
[14:17] <zyga> and works on each os
[14:17] <zyga> well, each distro
[14:18] <Laney> hi
[14:19] <Laney> using snapcraft, is it possible to natively build for i386 on my amd64 machine?
[14:19] <Laney> launching an i386 multipass VM or lxd container should work, but I don't see an option for it, only --target-arch which says it's going to cross compile
[14:28] <zyga> Laney: I don't know of any option, perhaps sergiusens can help?
[14:29] <zyga> wow, I just did something cool
[14:29] <zyga> I don't know which key I hit
[14:29] <zyga> but I got a cool tab completion I never saw before:
[14:30] <zyga> zyga@yantra:~/snapd/tests/lib/bin> {.m{ountinfo-tool.swp,ypy_cache},M{ATCH,akefile},REBOOT,any-python,cleanup{,-frames},host,mountinfo-tool,not,snap-tool,unshared{,-slave}} ^C
[14:30] <zyga> how do I do that?
[15:01] <mvo> cmatsuoka: just fyi, I created a "uc20" branch for snapd and added a PR with your changes. I will do the same for our other git repos and update spike-tools. this way we should have a bit more consistency :)
[15:03] <zyga> https://github.com/snapcore/snapd/pull/7071 is green
[15:04] <cmatsuoka> mvo: excellent, this should make things easier
[15:06] <cmatsuoka> mvo: uc20 meaning the uc20 spike, right? we'll probably have to start over for the "real" uc20
[15:06] <mvo> cmatsuoka: yeah, for the real uc20 we need a new name :) maybe just 20?
[15:07] <cmatsuoka> mvo: could be, did we use just 18 for core 18?
[15:07] <mvo> cmatsuoka: yes
[15:08] <cmatsuoka> mvo: 20 for the real thing then :D
[15:45] <ogra> ppisati, have you seen https://forum.snapcraft.io/t/how-do-i-add-support-for-a-custom-touch-screen-on-my-raspberry-pi/12148 ?
[15:45] <ogra> (i'm a bit out of ideas here)
[15:50] <Laney> I ended up making an i386 VM myself with multipass (passing it the URL to a cloud image!) and then using --destructive-mode or whatever it is, since we apparently don't produce minimal cloud images for anything other than amd64 & snapcraft uses cloud-images.u.c rather than the ubuntu: remote built into lxd
[15:52] <zyga> https://github.com/snapcore/snapd/pull/7071 anyone?
[15:53] <zyga> Laney: I have https://spread.zygoon.pl
[15:53] <zyga> not sure if that helps you with an image
[15:53] <zyga> it's a qemu vm with ubuntu/ubuntu credentials
[15:55] <Laney> zyga: thx, what I needed in this case was the ability to tell multipass and snapcraft to launch i386 images, guess I should be a good citizen and file bugs really
[15:55] <zyga> yeah
[15:55] <zyga> I *think* it should be supported
[15:55] <zyga> Saviq: ^ ?
[15:56]  * zyga fires another round of spread
[15:56] <Saviq> zyga, Laney: yeah we could certainly launch CPU-compatible images, what we've so far said we did not want to do was emulation (i.e. arm on x86)
[15:57] <Saviq> but we may have to revisit that, especially if that would mean you could run/build arm on x86 Windows/macOS
[15:58] <Saviq> I was worried about the state of qemu's emulation support, remembering our phone times and virt Launchpad builders
[15:58] <Laney> Saviq: hey there
[15:58] <Laney> my bug's not going to be about emulation or anything, but by all means feel free to do that too :D
[15:59] <cjwatson> zyga: that's complete-into-braces, M-{
[16:10] <zyga> cjwatson: thank you!
[16:20] <zyga> mvo: schema anyone https://github.com/cuelang/cue
[16:20] <mvo> zyga: nice
[16:21] <zyga> niemeyer: ^^ cue for schema
[16:21] <zyga> and maybe for data too
[16:28] <ogra> Laney, simply dont use VMs at all ... create a conventioanl i386 lxd container, install snapcraft in it and "export SNAPCRAFT_BUILD_ENVIRONMENT=host" ... then just build (no --target-arch or any other options)
[16:29] <Laney> ogra: sure, that seems to be more or less what --destructive-mode does too
[16:30] <ogra> thats how i (have to ) use snapcraft for arm and arm64 too ... multipass is just getting in the way if you are not always using amd64
[16:30] <ogra> yeah, --destructive-mode is similar to that
[16:30] <Laney> but I think the situation could be improved a bit, that's what my requests are about :)
[16:31] <ogra> by making multipass optional ;)
[16:31] <Laney> no way, the multipass exprience is great
[16:31] <ogra> or rather have it detect if its on non amd64/non-windows/non-macos
[16:31] <ogra> and fall back to lxd
[16:32] <ogra> as someone who 90% of the time builds for non x86 i find the multipass experience most awful
[16:32] <Laney> there's no reason it couldn't launch an i386 vm for me (in fact it can if you go find the .img yourself)
[16:32] <Laney> dunno if there's any big blockers on arm tho
[16:32] <ogra> no kvm/qemu would be the first one ;)
[16:33] <Laney> hmm
[16:33] <Laney> how do the clouds work?
[16:33] <ogra> aarch64 ...
[16:33] <ogra> (that has kvm and spins up armhf VMs i think)
[16:34] <Laney> oh right, yes, I meant arm64
[16:34] <Laney> we make armhf containers indeed
[16:34] <ogra> but most our arm devs dont have fancy arm64 machines at home
[16:34] <ogra> they want to quickly build snaps for/on their Rpi
[16:34] <ogra> (many of our customers too sadly)
[16:36] <Laney> nod
[16:36] <Laney> I think they and you would appreciate a slick experience there too, either great cross compilation support or emulation
[16:36]  * Laney simply hasn't used that himself
[16:37] <ogra> we had that with snapcraft 2.0
[16:37] <ogra> even fancy cross building in lxd
[16:40] <zyga> mvo: any chance for a review today?
[16:43] <sergiusens> Laney: your request seems doable, but perhaps not this cycle as we are really underpowered for any extra load now
[16:43] <Laney> hey sergiusens!
[16:43] <Laney> it's ok, no particular priority from me
[16:46] <sergiusens> great, there are plans in the air, but nothing that can be done short term and wouldn't be a hack
[16:53] <mvo> zyga: not looking great, already relatively late - which one is the most important one you need?
[17:05] <zyga> mvo: this one  https://github.com/snapcore/snapd/pull/7071
[17:06] <zyga> just test tool tweaks (with tests)
[17:07] <zyga> mvo: I have some more state on top but it will be in separate PRs, sorting for determinism and small tweak to renumbering that shrinks delta between unrelated options
[17:25]  * ijohnson relocates to coffee shop
[17:43]  * zyga fights non-reproducible output
[17:57] <Eickmeyer> With Chromium moving to snap-only in Ubuntu, I'd like to get this issue moved along as quickly as possible for users of Ubuntu Studio: https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/issues/13
[17:57] <Eickmeyer> How can I get this going? I don't know much about how to work with snaps.
[18:15] <ardaguclu_> Could you please review?, https://github.com/snapcore/snapd/pull/7050. I made a dummy mistake by sending this PR from master branch and now I can not continue other issues.
[18:46] <zyga> ardaguclu_: hey
[18:47] <zyga> ardaguclu_: you can always close it and reopen  anew one
[18:47] <ardaguclu_> zyga: hey
[18:47] <zyga> ardaguclu_: I think this is something for pstolowski|afk to review next week
[18:47] <zyga> I'm not familiar with that part to review it
[18:47] <ardaguclu_> zyga: thanks, that would be better closing and opening again
[18:47] <zyga> it's really tricky and I tried recently and spectacularly failed to fix that
[18:49] <ardaguclu_> after looking at issues at launchpad, is it ok directly solving or asking here before that
[18:50] <zyga> ardaguclu_: it's best to talk but trying does not hurt
[18:50] <zyga> some issues are harder than others
[18:51] <zyga> this one is particularly complex as behavior differs across host system and go version
[18:51] <ardaguclu_> ok, thanks
[18:51] <zyga> it requires careful analysis of behavior to  come up with reasonable patches
[18:51] <zyga> I failed at that btw
[18:51] <ardaguclu_> I tried it 18.04 and 16.04
[18:51] <zyga> thank you for contributing though, perhaps  there is something  else you want to look at?
[18:52] <zyga> ardaguclu_: our spread suite runs on centos, amazon linux, fedora and many others
[18:52] <ardaguclu_> but you are right, there are lots of different versions
[18:52] <zyga> yeah
[18:52] <zyga> some build with gccgo
[18:52] <zyga> some with go
[18:52] <zyga> 1.9, 1.10, 1.12
[18:52] <zyga> etc etc
[18:52] <ardaguclu_> yeah definitely
[18:52] <zyga> then depedning on what is happening on the host network, the errors are somehow conveyed to go
[18:53] <zyga> so (go-version, glibc-version, go-resover-vs-libc-resolver, network behavior) => (error object)
[18:53] <ardaguclu_> what is the approaches such problems in our case
[18:53] <zyga> the trick is to map the error object to a should-we-rertry flag
[18:53] <ardaguclu_> trying at whole versions
[18:54] <zyga> we don't have the  set of tuples that  describe possiblities
[18:54] <zyga> so changes are kind of ad-hoc
[18:54] <zyga> we need data first
[18:54] <ardaguclu_> ok, thank you very much
[18:54]  * zyga makes the final coffee of the day to work on another bug
[18:55] <zyga> ardaguclu_: thank you! :)
[18:55] <ardaguclu_> I really like snap, that's why, I will continue contribution :)
[18:55] <zyga> ardaguclu_: do stick around, it's great to have contributions
[18:59] <zyga> jjohansen: hey, do you have a second for a quick question
[19:00] <jjohansen> zyga: uhmmm, never :)
[19:00] <jjohansen> what is it?
[19:00] <zyga> jjohansen: what is the difference beween network and  network_v8/
[19:00] <jjohansen> zyga: may I ask why you are messing around in the packed protocol?
[19:00] <jjohansen> :)
[19:01] <zyga> jjohansen: I'm not but we look for both and some kernels have v8 but not the other one
[19:03] <zyga> jjohansen: (what I mean by "look  for both" is snapd checks advertised kernel features)
[19:03] <zyga> jjohansen: is v8 enough if present?
[19:04] <jjohansen> zyga: v8 requires the yet to be released apparmor 3
[19:04] <zyga> I see
[19:04] <zyga> should we look for v8 then?
[19:04] <jjohansen> its a clean abi break that came about from Linus's revert it 4.15
[19:04] <zyga> mmm
[19:04] <zyga> I recall that, yes
[19:05] <jjohansen> yes, upstream and debian will only ever have v8
[19:05] <jjohansen> we will carry a compat patch in ubuntu/suse for several years to support old userspaces
[19:05] <zyga> jjohansen: aha,  I understand now
[19:05] <zyga> jjohansen: and is the  apparmor_parser in ubuntu today using  network or networkv8?
[19:06] <zyga> 2.13* AFAIR
[19:06] <jjohansen> it is using network
[19:06] <zyga> ok
[19:06] <jjohansen> you will require abi rules in policy to get network_v8
[19:06] <zyga> so perhaps we don't need to check for network_v8
[19:06] <zyga> until we do
[19:07] <jjohansen> sure, looking for it atm won't get you anything
[19:07] <zyga> thank you, that was what I was curious about
[19:07] <zyga> I'll adjust snapd next week when jdstrand can review it
[19:09] <zyga> jjohansen: speaking of which, is the  packing protocol documented? I tried to "reverse" it at one point by going through the kernel sources and  compiling various crafted profiles but I failed to decompile the packed state machine
[19:10] <jjohansen> zyga: I have some documentation started but its certainly not any even close to reasonable shape
[19:10] <jjohansen> zyga: there are some tools coming that will help with the whole thing
[19:10] <zyga> jjohansen: would you be interested if I tried to help in that  in small capacity?
[19:11] <jjohansen> They can handle the unpacking and output in clean text the state machine
[19:11] <zyga> interesting, that's what I was looking for at the time
[19:12] <jjohansen> zyga: I am always interested in help, as long as the help doesn't take more effort than I get back out
[19:13] <jjohansen> zyga: ping me in a couple of weeks, next week is bad for me
[19:13] <zyga> jjohansen: gladly
[19:13] <zyga> jjohansen: if you send me any git places to look, I can try to  familiarize myself with what is being made
[19:14] <jjohansen> zyga: I have to dig for it, the work is pre our move to git
[19:15] <zyga> jjohansen: no rush, I mainly follow apparmor from linus tree
[19:15] <zyga> (though that's usually "late")
[19:15] <jjohansen> ah, yeah this is userspace stuff so it will be landing in the gitlab side of things
[19:16] <jjohansen> I'll see if I can't get a branch up as a WIP pull request
[19:16] <zyga> jjohansen: which repo holds the userspace stuff?
[19:16] <jjohansen> https://gitlab.com/apparmor/apparmor/
[19:17] <jjohansen> zyga: and if you want to go a little broader https://gitlab.com/apparmor/
[19:18] <jjohansen> we are going to start moving to doing kernel dev in gitlab side of things and the sync it to the kernel.org tree instead of directly commiting
[19:19] <zyga> jjohansen: thanks, understood
[19:46]  * zyga found a bug in the ref code, finally
[22:07]  * zyga EOWs


[14:43] <mhcerri> hwpplayer1, you can always submit patches to<EMAIL_ADDRESS>[14:43] <mhcerri> are you asking about something more specific?


[06:36] <flocculant> knome: having trouble logging into x.org - torrent links are wrong on getxubuntu
[06:36] <flocculant> Unit193: no I wasn't :p
[06:41] <flocculant> knome: forget that - seems login is jittery ... all done
[07:06] <Unit193> flocculant: Got an email about -core.
[07:07] <Unit193> There's the link.
[07:58] <knome> flocculant, okay, i'll forget :P
[11:31] <flocculant> knome: if I get the same again I guess I ought to go to IS
[13:55] <knome> flocculant, try cleaning cache first if it reappears
[16:00] <flocculant> knome: I tried logging right out of sso - seems to have sorted it
[16:24] <flocculant> ochosi: just a mention here cos I know how you are with how things look ... grabbed new tbird from yak -proposed and it looks like this > http://i.imgur.com/Ikwp9uR.png
[16:25] <flocculant> which isn't dissimilar from the LO stuff you replaced with 'elementary'
[16:28] <flocculant> knome: ok - so the community council have now had 4 weeks, we've heard nothing since one said they were looking in the 3rd week
[16:28] <flocculant> !team | I think we should just move on with the council idea now
[16:29] <flocculant> the hard bit's done - all we need to do now is change the section of strategy doc and then get a council sorted
[16:31] <flocculant> to be honest I only thought we should cc the CC in because it was called a council - they had no input on xpl
[16:31] <flocculant> and trying to be polite :)
[16:31] <Unit193> Problem?
[16:38] <flocculant> Unit193: not at all - just think we should move it all along now
[16:38] <flocculant> they've had long enough to at least comment :)
[16:39] <pleia2> it is disappointing that it's taking so long :(
[16:39] <flocculant> pleia2: yup
[16:40] <pleia2> I'm not looped in, but maybe one final email saying we're moving forward?
[16:40] <flocculant> a response other than 'we're looking' 3 weeks ago
[16:40] <flocculant> pleia2: as long as that doesn't then entail waiting another month ;)
[16:40] <flocculant> at least it's the post-lts cycle \o/
[16:42] <flocculant> mhall119: ^^
[16:42] <flocculant> there - that's as good as an e-mail :D
[16:42] <Unit193> They're all on IRC, poke 'em all. :P
[16:42] <davmor2> flocculant: do you know how hard it is to find a distant star that hasn't been name it takes a while of looking ;)
[16:42] <flocculant> Unit193: yup - but one is in here :D
[16:42] <flocculant> davmor2: heh
[16:43] <davmor2> Unit193: this isn't pokemon go you know
[16:43] <flocculant> phew
[16:44]  * flocculant had an idjit walk in front of him doing that stupid
[16:44] <flocculant> davmor2 should remember we do have an -offtopic to take the mickey :p
[16:46] <mhall119> flocculant: sorry, we did a round of email-voting, I think we haven't heard from all members yet, but those that did respond were all +1
[16:46] <mhall119> so I think we can all start planning the steps for implementing this change
[16:46] <flocculant> mhall119: thanks for responding :)
[16:46]  * davmor2 take the mickey I've never been so offended.........wait is that the right word........no...........pleased with myself in a long time ;)
[16:47] <mhall119> flocculant: I'll send out a formal email, where do you want it sent?
[16:47] <flocculant> mhall119: frankly our plan is now to transfer the wording from the mail lists to replace the XPL section of http://docs.xubuntu.org/contributors/xsd.html
[16:48] <flocculant> mhall119: send it to pasi, CC me please
[16:48] <flocculant> then we'll do the next bits
[16:48] <mhall119> ack
[16:48] <flocculant> thanks Michael
[16:49] <flocculant> mhall119: basically we'll be replacing that xpl bit with council bit
[16:50] <flocculant> mhall119: it would help us enormously if CC realises that once we've done that, if you want some sort of change - we are also wanting to replace XPL asap - as we don't really have one currently
[16:50] <flocculant> although ochosi is listed - he's doing that so we have someone in control - what he really wants is the council sorted out
[16:51] <mhall119> flocculant: not sure I follow, do you need the CC's help in replacing the XPL? Or in recruiting members to the new council?
[16:54] <flocculant> mhall119: no not at all - we just need the CC to read and respond sooner rather than after we ping people :)
[16:54] <flocculant> all the real stuff is done :)
[16:56] <mhall119> flocculant: email sent
[16:56] <flocculant> cheers
[20:04] <ochosi> flocculant: that looks ok, no? or what would be the problem..?
[20:15] <knome> just forwarded mhall119's mail to the devel list as i see no reason not to
[20:17] <knome> mhall119, as i see it, i don't think we need any help from CC in the practical side of it, just the ack
[21:14] <flocculant> ochosi: that's fine then - just thought I would mention it - looks to me much the same as the thinh which was default in LO for a while
[21:16] <flocculant> sifr
[21:18] <flocculant> http://i.imgur.com/4nRN6E3.png
[21:23] <flocculant> which we didn't like ;)
[21:38] <ochosi> oh right, well i think thunderbird has its own icon themes and i don't use it personally, so i have extremely little incentive to make one :)
[21:39] <ochosi> i also thought it had looked like that for a while already, but then again i don't use thunderbird anymore
[21:40] <ochosi> flocculant: ^
[21:52] <flocculant> ochosi: works for me - I just thought I would tell you is all :)
[21:53] <flocculant> I've really got no bones in this fire at all
[22:04] <flocculant> mail to list just setting out what's needed for pleia2's archive
[22:12] <flocculant> imo of course
[22:51] <Unit193> ochosi: You still there, sparky?
[22:56] <Unit193> ochosi: Not sure you've seen Debian 829155, but very related.


[02:50] <RoadRunner> where can I get "simple" instructions on how to build Pidgin 2.13.0 from source for xubuntu 16.04 and xubuntu 18.04?
[05:51] <pragomer> hi. does xubuntu 18.04 support secure-boot?
[06:30] <pmjdebruijn> pragomer: IIRC it should
[06:30] <pmjdebruijn> probably all ubuntu derivatives
[06:31] <pmjdebruijn> since a few years
[06:31] <pmjdebruijn> pragomer: trivial to test of course :)
[06:46] <pragomer> ok thank you very muc
[07:56] <Nikola_88> hi guys i've installed xubuntu on a macbook pro 3.1. I have a problem with the keyboard: i can't use symbols like the "at" key. I tried to search on web but nothing helps me.
[08:05] <Nikola_88> someone can help me?
[08:10] <pmjdebruijn> presumably you didn't select the correct keymap during the install?
[08:10]  * pmjdebruijn is just guessing
[08:16] <Nikola_88> yes this is the problem: what is the correct keymap to use? i tried generic 104 keys PC, Apple, Macbook/macbookpor (intel)
[08:16] <Nikola_88> but nothings seems to work properly
[08:17] <pmjdebruijn> no clue sorry I never had any Macs
[09:09] <jimini> Hello everyone. I installed Xubuntu 18.04 yesterday and I am running kernel <IP_ADDRESS>. Since this morning, the screen stays black wheen I boot up the system - before, I enter the passphrase to decrypt my disk and afterwards, the screen stays black. The system is reachable via SSH. Xorg.0.log shows the following errors: (EE) modeset(G0): eglGetDisplay() failed; (EE) modeset(G0): glamor initialization failed; (EE) NVIDIA(0): Failed
[09:09] <jimini> to initiate mode change.; (EE) NVIDIA(0): Failed to complete mode change. What is the problem here? With <IP_ADDRESS> the system boots up fine
[09:10] <pmjdebruijn> no clue
[09:10] <pmjdebruijn> NVIDIA blobs drivers are prone to random failures
[09:10] <pmjdebruijn> you could try reinstalling the nvidia driver package
[09:11] <pmjdebruijn> but stick around, maybe someone else has a better idea
[09:34] <bluesabre> FurretUber: Parole doesn't do anything specific for video proportions. If you're seeing an issue, it's likely a GStreamer bug. Can you also test with totem (GNOME Videos)?
[12:54] <FurretUber> bluesabre: I have installed Totem and it is able to find the correct proportion of the videos. As what I've seen so far, this problem is exclusive to Parole. I have tested with VLC, MPV, FFplay, Totem and Parole. I reported a bug (against Cosmic) about this before: https://bugs.launchpad.net/ubuntu/+source/parole/+bug/1778153
[19:36] <tribal_zen> Good afternoon everyone.
[19:39] <diogenes_> hi
[19:40] <tribal_zen> Have a quick question, i'm noticing a lot of lag, sometimes stuttering and screen tears when running normal tasks. Web surfing, mostly. I keep checking for updates and proprietary drivers, everything is up to date.
[19:42] <diogenes_> what gpu?
[19:43] <tribal_zen> AMD Radeon R6
[19:43] <tribal_zen> Running a HP 17-g121wm laptop
[19:44] <tribal_zen> 8GB RAM, Quad-Core 3.2GHz CPU
[19:45] <diogenes_> could try Option "TearFree" "on"
[19:46] <tribal_zen> No idea where to find that. Kinda new to the Xubuntu DE. Also wouldn't help the other issues i seem to be having.
[19:47] <diogenes_> open the terminal
[20:24] <drleviathan> tribal_zen, the load on your laptop is low?  did you try running 'top' or some top-util alternative to see if there is a process consuming CPU/memory?
[20:26] <drleviathan> tribal_zen, try turning off xfce eye candy.  That is, disable: Settings --> Window Manager Tweaks --> Compositor --> Enable display compositing
[20:33] <n-iCe> hi
[23:53] <kumool> how to restart the xfwm?


[06:45] <emdash_> nn/win 10
[06:45] <emdash_> gar
[07:36] <slavik> UVF = Upstream Version Freeze?
[07:36] <cjracker> iirc
[07:37] <ScottK> slavik: Yes.
[07:37] <slavik> k
[07:37] <slavik> I had an idea ... dunno if it was though of, but what about alsa-oss package by default and also software mixing for all devices that don't support it?
[08:00] <c1|freaky> if i reported a bug for kernel 2.6.20 on feisty, i upgraded to gutsy now theres 2.6.22 - the bug is about cpu frequency scaling which doesnt work - and i now want to report that this is still not working, can i just post a comment under the bug for 2.6.20 ? or should i file a new bugreport?
[08:02] <slavik> hmm, cpu scaling works here ... (feisty)
[08:02] <slavik> I am on c2q though
[08:03] <c1|freaky> <-- amilo M 1437G gutsy
[08:04] <slavik> what cpu?
[08:04] <c1|freaky> Intel Pentium M - Dothan i think
[08:04] <c1|freaky> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/93331
[08:04] <ubotu> Launchpad bug 93331 in linux-source-2.6.20 "Kernel doesn't scale my CPU." [Medium,Fix released]
[10:46] <\sh> hmmm...does anyone know what this error message could be?
[10:46] <\sh> Rejected:
[10:46] <\sh> Attempt to upload binaries specifying build 375243, where they don't fit.
[10:46] <siretart> any archive admins around?
[10:46] <siretart> hi \sh!
[10:47] <\sh> moins siretart
[10:49] <Kopfgeldjaeger> hi
[10:51] <siretart> \sh: do you remember who this guy was that was interested in fai in ubuntu?
[10:51] <siretart> avinc something, but I don't remember exactly
[10:52] <\sh> logfiles....
[10:53] <\sh> siretart, when was it?
[10:53] <\sh> alvinc was the nic
[10:53] <siretart> ah, thanks
[10:54] <siretart> do you know him? do you have his email adress?
[10:54] <\sh> http://people.ubuntu.com/~fabbione/irclogs/ubuntu-motu-2007-09-05.html
[10:54] <\sh> nope..
[10:54] <siretart> hm.
[10:55] <siretart> seems to be his lp id as well
[10:55] <siretart> thanks
[11:08] <\sh> hmmm...sending a window to virtual desktop no. doesn't work with compiz...but moving it right or left works...do I miss something?
[11:12] <kylem> win 27
[01:11] <TomaszD> hi. Is it me or is bluez-gnome in gutsy completely different from the standard one? If so, where is the translation for this thing? It seems like a cruel joke when people struggle to keep the standard thing up-to-date and all of a sudden I see a different bluetooth-properties applet where everything is in English despite the fact that bluez-gnome is fully translated into Polish.
[01:12] <TomaszD> Rosetta shows that bluez-gnome is fully translated and that's true, I maintain it upstream.
[01:14] <\sh_away> keescook, thanks for the upload
[01:14] <gnomefreak> noticed gb mirror is down/not grabbing packages
[01:18] <Kmos> TomaszD: I think you need to talk to carlos about that on #launchpad
[01:19] <TomaszD> Kmos, ok thanks
[01:46] <\sh_away> anyone who wants to sponser bug 47232? ;)
[01:46] <ubotu> Launchpad bug 47232 in redland-bindings "example file provided in /usr/share/doc/python2.4-librdf doesn't work" [Medium,New]  https://launchpad.net/bugs/47232
[04:03] <siretart> any ftp-archive admin around? there are some packages in universe which aren't supposed to be there :/
[05:30] <__pablo__> hello world
[05:30] <__pablo__> exist a plugin in dev for rhytmbox to use tap_eq?
[05:35] <finalbeta> tap_eq?
[05:36] <finalbeta> I'll assume you need equalizing, and thus no
[05:36] <__pablo__> yes
[05:36] <__pablo__> i use it as a plugin for ladspa
[05:36] <__pablo__> but i don't set it in simple way
[05:37] <__pablo__> but in ~/.asoundrc
[05:37] <__pablo__> manually
[05:37] <__pablo__> ps:: excuse me for my english
[05:38] <__pablo__> i think that a plugin to set tap_eq will be very usefull... now my linux box sound very well... but if i need to modify the eq set is problematic
[05:39] <finalbeta> I'm sure everyone agrees to you, and this feature has been requested for years now. Someday...
[05:40] <__pablo__> audacius had this feature... i don't think that is very difficult port it to rhytmbox
[06:26] <ace_suares> Dear ppl, I have severe problems with OO in Kubuntu Feisty. I asked in openoofice.org-devel but they point me back to ubuntu
[06:26] <Hobbsee> !weekend
[06:26] <ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
[06:26] <ace_suares> I reported the problem extensivly in launchpad but hitherto no answers...
[06:27] <ace_suares> hi Hobbsee
[06:27] <Hobbsee> hi
[06:27] <ace_suares> yes it is weekend....
[06:27] <ace_suares> sweet saturday and my machine hangs and i need to reboot :-(
[06:27] <ace_suares> it seems to be difficult to pinpoint this problem
[06:28] <ace_suares> since it's OO interacting with what not (X ? KDE ?)
[06:28] <ace_suares> and maybe it's a freak thing only to be seen on multihead machines and not all developers have multihead
[06:28] <Riddell> ace_suares: you are yet to say what the problem is
[06:29] <Riddell> calc is the dude for openoffice though
[06:29] <ace_suares> I will paste about 7 lines...
[06:29] <ace_suares> calc: (Thanks ridell)
[06:30] <ace_suares> My openoffice on ubuntu feisty crashes whenver I touch the menu (for instance file) but I can't see how to debug this
[06:30] <ace_suares> it hangs the entire machine and only reboot can save me
[06:30] <ace_suares> I have to to the reboot from another machine via ssh
[06:30] <ace_suares> because everyting hangs, and I can't use my keyboard anymore
[06:30] <ace_suares> furthermore, as soon as the screensaver kicks in, I loose an entore screen on my 3-head machine
[06:30] <ace_suares> and X is just working around it by only using the two screens that did NOT have OO running
[06:31] <ace_suares> ridell: hope this makes sense
[06:51] <FoxII> woo! I'm in
[06:51] <FoxII> Any high up devs here? As In those that are 'permenantly' involved with ubuntu?
[06:53] <keescook> \sh_away: you bet.  thanks for the patches.  :)
[06:54] <Hobbsee> !weekend | FoxII
[06:54] <ubotu> FoxII: It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
[06:54] <FoxII> Thank you Hobbsee :)
[06:57] <FoxII> My question is (and I'm willing to wait. I know the time that developers put into this project); The relationship between developers and members who are testing and how the development between the both is not hindered by flaming and/or complaints. I understand fully that both are viable and likely to happen, but I would like to know how this is limited and how the developers keep the testers happy with regard to devel
[06:57] <FoxII> opment, even with development of 'back-end' parts which are not initially included in global updates.
[06:58] <Hobbsee> oh, you're from the forums arent you?
[06:58] <FoxII> If that makes sense. I will try to explain further if possible.
[06:58] <FoxII> yes, Hobbsee, it was suggested to try here for my question to be answered. I hope that is okay :)
[06:59] <Hobbsee> hardly anyone here at this time of night
[06:59] <Hobbsee> it is a weekend, after all
[07:00] <FoxII> Ihm, I understand fully for those that are left. hehe. I can wait for a reply. :)
[07:51] <Doctor_Nick> hey, apparently there was a demo yesterday about using launchpad to create and submit packages, does anyone know where i might find that
[07:54] <beuno> Doctor_Nick, https://help.launchpad.net/PPA101/20070913
[07:55] <Doctor_Nick> thanks
[07:56] <beuno> :D
[10:22] <pygi> siretart, ping if you're here
[10:25] <pygi> ok, you're not :p
[11:19] <okaratas> hello
[11:23] <okaratas> ompaul, hello
[11:25] <ompaul> hi
[12:05] <gnomefreak> will /etc/gdm get regenerated if i rm it when gdm starts after reboot?
[12:09] <mjg59> gnomefreak: No?
[12:09] <gnomefreak> the setting look right but i am still missing gdm menu
[12:10] <gnomefreak> looking to start with clean conf
[12:10] <wasabi> So reinstall the config file.
[12:10] <mjg59> If you delete files in /etc, then in most cases the packaging system will assume that you've done it deliberately and not recreate them
[12:11] <gnomefreak> using --purge didnt change it in any way
[12:11] <wasabi> Uh huh. dpkg -i --force-conf or something
[12:11] <wasabi> --force-confmiss
[12:12] <gnomefreak> said it wasnt empty so not removing so im looking for other choices atm
[12:12] <wasabi> missconf. one of those. it's in the man page, plain as day
[12:26] <gnomefreak> options was there just the screen is too big for the monitor screen, that would explain why xubuntu's login screen worked


[01:02] <sney> I have a new upload for hexchat that will satisfy LP:1396871, but I'm splitting up the package layout and apparently that means it'll have to go through NEW. I've heard that's slow currently - is that accurate, and is there any way to expedite the process?
[01:03] <tumbleweed> sney: any reason that can't go through Debian?
[01:04] <sney> erm, probably not. brain fart
[01:04] <tumbleweed> (experimental, presumably)
[01:04] <tumbleweed> NEW is currently not that pretty https://ftp-master.debian.org/stat.html :(
[01:15] <Noskcaj> sney, You may as well make a merge request for ubuntu, but try for debian experimental too
[11:49] <Mirv> Debian's NEW has often been understaffed, but still that should not usually be too much of a reason to do Ubuntu-only upload
[11:51] <Mirv> hmm, well, another small obstacle is that hexchat is not LowNMU and has only a single maintainer, not a team (packages in Debian tend to be more strongly attached to specific maintainers than in Ubuntu)
[11:51] <Mirv> ah, but, hexchat is at least in collab-maint git in Debian which is nice
[12:24] <Unit193> Mirv: sn ey is that one maintainer though. ;)
[12:24] <Mirv> Unit193: ok, that changes the picture somewhat :D