[00:00] <Noldorin> lifeless, that's not expected behaviour surely?
[00:00] <Noldorin> hmm
[00:39] <Noldorin> wgz, any ideas about that either?
[02:59] <lifeless> Noldorin: cygdrive should tell you a little about what is up
[03:22] <Noldorin> lifeless, hmm?
[04:15] <Noldorin> lifeless, i don't know what you mean by cygdrive in this context.
[05:02] <lifeless> Noldorin: thats cygwins mapping tool
[05:02] <lifeless> Noldorin: or you can just run mount I guess :P
[05:19] <Noldorin> lifeless, still, how about thev
[05:19] <Noldorin> url?
[06:15] <lifeless> Noldorin: the mount table controls what / is in cygwin
[16:20] <Noldorin> hi lifeless
[17:10] <lifeless> Noldorin: hi
[17:40] <Noldorin> lifeless, sorry, was late yesterday and had to go
[17:40] <Noldorin> what were you saying lastly?
[17:41] <lifeless> I had nothing more to add
[17:41] <lifeless> I'd described how you can address the url length
[17:42] <lifeless> and you asked why / in cygwin was your home dir, so I pointed you at the cygwin mount table
[17:44] <Noldorin> lifeless, oh, i didn't see that. you probably replied after i left
[17:44] <Noldorin> mind briefly repeating both of those points please? :-P
[17:44] <Noldorin> copy and paste will do
[17:50] <lifeless> pasted the transcript (with very minor skipping) to you
[18:09] <Noldorin> ok
[18:09] <Noldorin> cheers
[22:00] <Noldorin> hey lifeless. do you have much experience on windows?


[03:52] <duflu> RAOF: I've landed as much as I safely can, manually. But there's reasonable evidence people stop doing reviews when Jenkins gives spurious "Needs fixing"... https://code.launchpad.net/mir/+activereviews
[03:52] <RAOF> duflu: Yeah, I'm on it.
[03:52] <duflu> Although presently the problem might not be spurious. It might be our fault
[04:20] <rsalveti> AlbertA: https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1359530
[04:29] <RAOF> BAH!
[04:29] <RAOF> Commit before pushing, push before rerunning the tests!
[05:23]  * RAOF does his bit to ensure that the mako test devices stay nice and warm
[06:28]  * RAOF decides that actually landing privatise-all-the-things so that libmirserver25 is coinstallable with libmirserver24 is a better use of time than futzing with mir_install_packages.sh to work around that problem.
[08:53] <alan_g> duflu: @~vanvugt/mir/revert-to-r1831 we think alike - that was the next thing I was going to try. Bisecting via CI is going to be slow though.
[08:53] <duflu> alan_g: Faster than not doing it I guess
[08:55] <alan_g> yeah
[08:56] <duflu> Huh. We release Mir debs for arm64. Is there any hardware other than the build machine we could run these on?
[09:02] <alan_g> Not in my office but I get the impression that we default to releasing for any platform that exists in archive.
[09:11] <alan_g> duflu: I've worked out a way to replicate the symptoms. Just not sure how it can be affecting CI. Got headspace to listen?
[09:14] <alan_g> I start by removing the libmirplatformgraphics.so in lib
[09:14] <alan_g> Then when running e.g. mir_integration_tests the ambient version of libmirplatformgraphics.so is picked up.
[09:14] <alan_g> So mir_integration_tests links to a local libmircommon.so.2
[09:14] <alan_g> But the ambient version of libmirplatformgraphics.so links to a global libmircommon.so.1
[09:14] <alan_g> And and two different libmircommon.so.* both tryt to register wit libprotobuf
[09:15] <alan_g> And that gives us "libprotobuf ERROR..."
[09:16] <alan_g> The question therefore is: could we pick up the wrong libmirplatformgraphics.so in CI?
[09:16] <duflu> alan_g: Sounds obvious then if there are two libmircommon.so*
[09:16] <duflu> alan_g: Oh, ambient means system installed?
[09:17] <alan_g> yea
[09:18] <duflu> alan_g: This sounds like a continuation of that "how did USC build when it should have failed" discussion. The CI system is probably using too much of the installed system over the new Mir being built and tested.
[09:18] <alan_g> I'm tempted to revert -c 1846 to see if that picks up the new libmircommon
[09:18] <duflu> Can we force the environment of phablet-test-thingy to look in the newly built lib/ first?
[09:18] <duflu> Because it really should
[09:19]  * duflu is distracted exploring the bleeding edge phone image
[09:19] <alan_g> I'm sure we can. (Might need to bully ci-eng)
[09:20] <duflu> alan_g: Similarly, teach them to set up PKG_CONFIG_PATH environment correctly for USC/qtmir silo builds
[09:20] <duflu> If that is them
[09:21]  * alan_g isn't sure if there is a "them" and not loads of well meaning passers by
[09:27]  * duflu assumes there are CI Gnomes somewhere who know how things work
[09:29]  * alan_g used to think that until he went spelunking through some build problems
[09:30] <alan_g> Anyway, I've got my day ahead to pursue this idea. Thanks for listening
[10:37]  * alan_g decides trying to dlopen "libmirplatformgraphics.so" is probably a bad idea when we ought to care about getting the one we're testing.
[12:22] <anpok_> alan_g: i was just able to reproduce the issue
[12:22] <anpok_> .. well .. i did not try to ..
[12:25] <anpok_> and in my case it is caused by broken relative link support.. so it cannot pick libmirplatformgraphics.so so i guess it takes the older one in /usr/lib ..
[12:32] <anpok_> alan_g: just as you said because it opens libmirplatformgraphics.so and failes to do because of the broken link it pulls in the systems libmircommon: http://paste.ubuntu.com/8105879/
[12:51] <alan_g> anpok_: That gives the same symptoms - I've yet to prove it is the same thing as happens in CI.
[12:52] <anpok_> hmm yes .. it could be because, as you said link against the system mircommon .. or like in the vm load the wrong platformgraphics.so hmm
[12:53] <alan_g> anpok_: it is a very plausible theory. (And I believe it.) But I'm awaiting proof from CI before claiming it as a solution.
[13:04] <alan_g> anpok_: this "broken relative link support" - is that specific to the emulator, or could it be affecting phone images?
[13:04] <alan_g> Specifically the makos in CI
[13:11] <anpok_> alan_g: special to the 9p virtual file system.. it seems to fail exposing links to the virtual machine
[13:13] <alan_g> Thanks. I'm still trying to understand the exact failure mechanism in CI.
[14:53] <robotfuel> kgunn: can you have someone look at this mir bug, I am not sure if it's qtubuntu, mir, or platform api https://bugs.launchpad.net/mir/+bug/1358874
[14:55] <kgunn> AlbertA2: camako either of you wanna have some pointer tracking "fun" :)
[14:56] <kgunn> or anpok_ even ^
[14:56] <kgunn> volunteers ?
[14:57] <kgunn> robotfuel: so that error report says ubuntu-system-settings, but do we know anything more ? like what was happening? opening or closing or just using settings at the time ?
[14:58] <camako> kgunn, sure
[14:59] <kgunn> camako: looks like the startup phase of u-s-s....
[15:00] <robotfuel> kgunn: no I'll get video of it today
[15:00] <kgunn> robotfuel: cool...the trace suggests startup of settings...but video would be awesome
[15:14] <robotfuel> kgunn: I also have this one that needs someone assigned to it. I am not sure who it should be. https://bugs.launchpad.net/barajas/+bug/1359270
[15:17] <AlbertA2> robotfuel: I can take a look at that
[15:25] <robotfuel> AlbertA2: what's your launchpad id?
[15:32] <AlbertA2> albaguirre
[15:42] <mibofra> AlbertA2, hi. I think that more or less my setup it's like an unflipped image of utouch, so everything have to work ok. At this point I think it's a driver issue.
[15:43] <AlbertA2> mibofra: umm any idea which driver call maybe causing the segfault?
[15:43] <AlbertA2> or which opengl/egl call?
[15:45] <mibofra> no I've to debug it AlbertA2. Think about that I'm on the cm11, as I can see on the porting guide the android base used it's an essential cm10.1
[15:46] <AlbertA2> mibofra: which android version do you have?
[15:46] <AlbertA2> 4.4.1? 4.2?
[15:46] <mibofra> 4.4.4
[15:47] <mibofra> yeah the 4.4.4 I've checked
[15:47] <AlbertA2> I wonder if they have changed the opengl dispatcher table again...
[15:48] <AlbertA2> there could be subtle TLS bugs
[15:48] <AlbertA2> when using gnulibc vs bionic
[15:52] <mibofra> AlbertA2, it's to be checked
[16:05] <kgunn> thanks AlbertA2 for diving in on that one
[16:47] <mibofra> AlbertA2, I've an idea, or well I think it was activated but It's deactivated every reboot of the phone
[16:48] <mibofra> the trace of opengl on logcat on the dev options
[16:53] <mibofra> ok AlbertA2 there is anything new
[17:07] <mibofra> ok AlbertA2 I've asked, maybe you're write, there is the probability that the table from cm10.1 to 11 was changed
[17:14] <mibofra> AlbertA2, (I'm controlling the code on github) if the problem is the opengl dispatcher table, do you (the devs/engineers of the mir team) can do anything or do you can do nothing because officially you're using as base cm10.1?
[17:23] <anpok_> re
[17:24] <anpok_> kgunn: saw my nick hilighted, have I been volunteered?
[17:39] <AlbertA2> mibofra: we are officially using 4.4.1 now
[17:39] <mibofra> ok
[17:49] <mibofra> anyway AlbertA2 if the dispatcher table of opengl?
[17:49] <AlbertA2> the main thing there is the optimization
[17:49] <AlbertA2> where they use TLS to store the pointer and hardcode it
[17:50] <AlbertA2> you can check
[17:50] <AlbertA2> if the TLS is being corrupted
[17:51] <AlbertA2> but I doubt it, since you can get the driver working on the server side...
[17:51] <AlbertA2> but I don't know if there's some interplay in the client thread context with TLS that we are missing
[17:52] <camako> anpok, it was about https://bugs.launchpad.net/mir/+bug/1358874 ... I took it on. No action on your part.
[18:18] <mibofra> AlbertA2, I'm going to have dinner, cm10.1 https://github.com/CyanogenMod/android_frameworks_native/blob/cm-10.1/opengl/libs/EGL/egl_tls.h https://github.com/CyanogenMod/android_frameworks_native/blob/cm-10.1/opengl/libs/EGL/egl_tls.cpp , cm11 https://github.com/CyanogenMod/android_frameworks_native/blob/cm-11.0/opengl/libs/EGL/egl_tls.h https://github.com/CyanogenMod/android_frameworks_native/blob/cm-11.0/opengl/libs/EGL/egl_tls.cpp I've made
[18:18] <mibofra> 2 diffs: egl_tls.cpp diff http://paste.ubuntu.com/8108125/ egl_tls.h diff http://paste.ubuntu.com/8108127/ . See you after dinner.
[18:26] <kgunn> anpok_: nah, you're good
[18:30] <AlbertA2> mibofra: https://code-review.phablet.ubuntu.com/gitweb?p=aosp/platform/frameworks/native.git;a=blob;f=opengl/libs/GLES2/gl2.cpp;h=3134e568fe984315dae7bf3c1fd4714359b7b7ba;hb=refs/heads/phablet-4.4.1_r1
[18:31] <AlbertA2> mibofra: we are using aosp: https://code-review.phablet.ubuntu.com/#/admin/projects/
[18:33] <AlbertA2> mibofra: https://wiki.ubuntu.com/Touch/AndroidDevel
[18:33] <AlbertA2> basically this is the android base we use:
[18:34] <AlbertA2> "repo init -u https://code-review.phablet.ubuntu.com/p/aosp/platform/manifest.git -b phablet-4.4.2_r1"
[18:35] <AlbertA2> that's for the dev version of ubuntu touch
[19:10] <mibofra> AlbertA2, I've to confront. So maybe it's the different base the problem
[19:18] <mibofra> AlbertA2, from the source you're using and cm11 I've only this diff: http://paste.ubuntu.com/8108505/
[19:18] <mibofra> for gl2.cpp
[19:19] <AlbertA2> interesting...
[19:20] <mibofra> let's try the egl_tls
[19:25] <mibofra> uhm AlbertA2 there are no differences for egl_tls


[14:12] <bregma> any idea if the daily release builds are going to return soon?
[17:45] <drfaustus> hi
[17:46] <drfaustus> is this a support channel?
[18:13] <PrideAndSorrow> hi
[18:14] <PrideAndSorrow> marlinc
[18:14] <PrideAndSorrow> r u there,marlinc?


[12:23] <Xenocide> no nasty blue people either
[12:24] <Xenocide> so much smoother than edgy
[12:24] <majoridiot> vg
[12:24] <majoridiot> :)
[12:31] <Xenocide> ah crap
[12:31] <Xenocide> im getting that stretched TV problem
[12:49] <Xenocide> had to disable xV overlay
[12:49] <Xenocide> majoridiot, might want to add that to your guide
[12:50] <Xenocide> for ati cards that are missing half the screen reconfigure with "aticonfig --overlay-type=opengl or aticonfig --overlay-type=disable"
[12:51] <majoridiot> k
[12:51] <majoridiot> ty
[12:54] <majoridiot> Xenocide: that aticonfig is a sudo, correct?
[02:58] <williammanda> hey major
[02:58] <majoridiot> hola
[02:59] <williammanda> i just finished adding more to the remote....
[03:00] <williammanda> added mouse function....and some more programs
[03:00] <majoridiot> excellent
[03:01] <majoridiot> i've never played with the mouse function... how's that work out?
[03:01] <williammanda> I couldn't get to work for mplayer..like you did...had to use dcop
[03:01] <williammanda> the mouse was as easy to setup as mythtv
[03:01] <majoridiot> it wouldn't work at all for mplayer?
[03:01] <williammanda> i posted it on ubuntu
[03:01] <williammanda> no...mplayer
[03:02] <williammanda> http://ubuntuforums.org/showthread.php?t=405009
[03:02] <williammanda> i attached my files in the thread
[03:03] <williammanda> brb..going to blockbuster
[03:30] <williammanda> back
[03:30] <majoridiot> try the reply
[03:30] <majoridiot> ;)
[03:31] <williammanda> ok
[03:47] <williammanda> no luck major
[03:48] <majoridiot> none of the keys work?
[03:48] <williammanda> nope
[03:48] <majoridiot> wtf?
[03:49] <williammanda> this was one of the first programs i tried to use the remote with....
[03:49] <majoridiot> those entries are from my working mplayer entries
[03:49] <williammanda> it drove me crazy for 2 nights
[03:49] <majoridiot> how are you launching mplayer?
[03:49] <williammanda> i'm using mepis 6.5...which uses kde
[03:50] <williammanda> i use the gui..kmplayer...
[03:50] <williammanda> then i can select either mplayer or xine
[03:50] <majoridiot> ah
[03:50] <majoridiot> i thought you were using mplayer with mythvideo
[03:51] <williammanda> sorry
[03:51] <majoridiot> sec...
[03:51] <majoridiot> lemme order a pizza...
[03:51] <williammanda> sure
[03:55] <majoridiot> hm
[03:56] <majoridiot> i just launched gmplayer, which is the gnome frontend and it worked fine.
[03:57] <williammanda> where did you get the "mPlayer" from?
[03:58] <majoridiot> from another lircrc when i was putting mine together
[03:58] <majoridiot> it's always worked.
[03:58] <majoridiot> ok...
[03:58] <majoridiot> look in ~/.mplayer
[03:58] <majoridiot> see if there is anything in the config file
[04:00] <williammanda> nope
[04:00] <majoridiot> ok
[04:00] <majoridiot> and your .lircrc file is in ~
[04:00] <majoridiot> ?
[04:00] <williammanda> /home/william/
[04:01] <williammanda> or ~/.lircrc
[04:01] <majoridiot> hm
[04:01] <majoridiot> this makes no sense.
[04:02] <majoridiot> that is where mplayer looks for it by default
[04:05] <majoridiot> ok, try this...
[04:06] <majoridiot> from a terminal"
[04:06] <williammanda> k
[04:08] <majoridiot> sorry... tested it first
[04:08] <majoridiot> mplayer -vo xv <path to a video file>
[04:10] <williammanda> played the video file
[04:11] <majoridiot> remote work at all?
[04:11] <majoridiot> play/pause?
[04:12] <williammanda> yes..looks like they all work
[04:12] <majoridiot> :)
[04:12] <majoridiot> it's the launcher
[04:12] <majoridiot> (btw... mplayer or mPlayer... doesn't seem to be case sensitive)
[04:13] <majoridiot> but the commands were, etc.
[04:13] <williammanda> k...good to know
[04:13] <majoridiot> see if there are mplayer launch options you can set in the launcher prefs
[04:16] <william> this what is in the kde menu for lauching mplayer....
[04:16] <william> kmplayer -caption "%c" %i %m %U
[04:17] <william> had to change computers
[04:18] <majoridiot> gotta read up... not familiar with it at all.  sec.
[04:23] <majoridiot> try this:
[04:23] <majoridiot> open up the config file in ~/.mplayer
[04:23] <majoridiot> and enter
[04:24] <majoridiot> lircconf=/home/william/.lircrc
[04:24] <majoridiot> and try running it from kmplayer
[04:26] <william> nothing
[04:26] <majoridiot> it was a shot
[04:26] <william> or no remote functions
[04:26] <majoridiot> well.. you need to read the kmplayer docs to figure out why it's not launching with lirc
[04:27] <william> kde 3.5.3
[04:27] <william> ok i will
[04:33] <majoridiot> do you have/need kdelirc installed?
[04:35] <william> not this computer
[04:35] <majoridiot> dunno
[04:35] <majoridiot> well, at least you know it will work... once you figure you how to force it to.
[04:36] <majoridiot> ;)
[04:37] <william> yes...the quest goes on!
[05:13] <william> is this an error to get concerned with?
[05:13] <william> 2007-04-13 23:05:02.607 DVBChan(0) Warning: Symbol Rate setting (0) is out of range (min/max:5056941/10762000)
[05:13] <william> i get this in the console for the backend
[05:18] <majoridiot> looks like a database error


[00:03] -queuebot:#ubuntu-release- New binary: golang-pault-go-ykpiv [arm64] (hirsute-proposed/universe) [1.3.4-1] (no packageset)
[00:04] -queuebot:#ubuntu-release- New binary: golang-pault-go-ykpiv [armhf] (hirsute-proposed/universe) [1.3.4-1] (no packageset)
[00:36] <vorlon> mwhudson: librsvg :/
[00:36] <mwhudson> vorlon: oh rite
[00:37] <vorlon> (I didn't remember, just looked at https://people.canonical.com/~ubuntu-archive/germinate-output/i386.hirsute/i386+build-depends)
[00:38] <mwhudson> i guess if we didn't build it for devel on i386 i'd just get to find out about this stuff when sruing it anyway
[00:38] <mwhudson> which is probably worse
[00:49] <mwhudson> uh how does this test work at all
[00:50] -queuebot:#ubuntu-release- New binary: rustc [s390x] (hirsute-proposed/universe) [1.45.0+dfsg1+llvm-2ubuntu1] (i386-whitelist)
[01:32] -queuebot:#ubuntu-release- New binary: rustc [amd64] (hirsute-proposed/universe) [1.45.0+dfsg1+llvm-2ubuntu1] (i386-whitelist)
[01:37] -queuebot:#ubuntu-release- New binary: rustc [ppc64el] (hirsute-proposed/universe) [1.45.0+dfsg1+llvm-2ubuntu1] (i386-whitelist)
[01:41] -queuebot:#ubuntu-release- New binary: rustc [i386] (hirsute-proposed/universe) [1.45.0+dfsg1+llvm-2ubuntu1] (i386-whitelist)
[03:41] <vorlon> oh look, britney found another blocker for python3-defaults.
[03:41] <vorlon> roling back deal.ii, which apparently synced 16h ago :P
[03:54] <teward> cjwatson: RE: why that package needs nuitka, ask Eickmeyer[m]
[03:54] <teward> :p
[03:54] <teward> i think it's because it's using nuitka in the upstream Makefile :p
[04:35] <xnox> can someone with powers please create 20.04.2 milestone in launchpad?
[04:39] -queuebot:#ubuntu-release- Unapproved: u-boot (focal-proposed/main) [2020.10+dfsg-1ubuntu0~20.04.1 => 2020.10+dfsg-1ubuntu0~20.04.2] (core)
[06:12] -queuebot:#ubuntu-release- New binary: rustc [armhf] (hirsute-proposed/universe) [1.45.0+dfsg1+llvm-2ubuntu1] (i386-whitelist)
[06:24] -queuebot:#ubuntu-release- New: accepted golang-pault-go-ykpiv [arm64] (hirsute-proposed) [1.3.4-1]
[06:24] -queuebot:#ubuntu-release- New: accepted libavif [armhf] (hirsute-proposed) [0.8.4-1]
[06:24] -queuebot:#ubuntu-release- New: accepted golang-pault-go-ykpiv [armhf] (hirsute-proposed) [1.3.4-1]
[06:24] -queuebot:#ubuntu-release- New: accepted golang-pault-go-ykpiv [amd64] (hirsute-proposed) [1.3.4-1]
[06:24] -queuebot:#ubuntu-release- New: accepted golang-pault-go-ykpiv [riscv64] (hirsute-proposed) [1.3.4-1]
[06:24] -queuebot:#ubuntu-release- New: accepted libavif [amd64] (hirsute-proposed) [0.8.4-1]
[06:25] -queuebot:#ubuntu-release- New: accepted libavif [ppc64el] (hirsute-proposed) [0.8.4-1]
[06:25] -queuebot:#ubuntu-release- New: accepted libavif [s390x] (hirsute-proposed) [0.8.4-1]
[06:25] -queuebot:#ubuntu-release- New: accepted golang-pault-go-ykpiv [ppc64el] (hirsute-proposed) [1.3.4-1]
[06:25] -queuebot:#ubuntu-release- New: accepted libavif [arm64] (hirsute-proposed) [0.8.4-1]
[06:25] -queuebot:#ubuntu-release- New: accepted telepathy-haze [riscv64] (hirsute-proposed) [0.8.0-3]
[06:25] -queuebot:#ubuntu-release- New: accepted golang-pault-go-ykpiv [s390x] (hirsute-proposed) [1.3.4-1]
[06:25] -queuebot:#ubuntu-release- New: accepted libavif [riscv64] (hirsute-proposed) [0.8.4-1]
[06:25] -queuebot:#ubuntu-release- New: accepted q2-types [amd64] (hirsute-proposed) [2020.11.0-1]
[06:25] -queuebot:#ubuntu-release- New: accepted ruby-azure-storage-blob [amd64] (hirsute-proposed) [2.0.0-2]
[06:25] -queuebot:#ubuntu-release- New: accepted telepathy-haze [arm64] (hirsute-proposed) [0.8.0-3]
[06:25] -queuebot:#ubuntu-release- New: accepted telepathy-haze [ppc64el] (hirsute-proposed) [0.8.0-3]
[06:25] -queuebot:#ubuntu-release- New: accepted q2cli [amd64] (hirsute-proposed) [2020.11.0-1]
[06:25] -queuebot:#ubuntu-release- New: accepted telepathy-haze [armhf] (hirsute-proposed) [0.8.0-3]
[06:25] -queuebot:#ubuntu-release- New: accepted telepathy-haze [amd64] (hirsute-proposed) [0.8.0-3]
[06:25] -queuebot:#ubuntu-release- New: accepted telepathy-haze [s390x] (hirsute-proposed) [0.8.0-3]
[06:25] <vorlon> xnox: done
[06:27] -queuebot:#ubuntu-release- New: accepted rustc [amd64] (hirsute-proposed) [1.45.0+dfsg1+llvm-2ubuntu1]
[06:27] -queuebot:#ubuntu-release- New: accepted rustc [i386] (hirsute-proposed) [1.45.0+dfsg1+llvm-2ubuntu1]
[06:27] -queuebot:#ubuntu-release- New: accepted rustc [s390x] (hirsute-proposed) [1.45.0+dfsg1+llvm-2ubuntu1]
[06:27] -queuebot:#ubuntu-release- New: accepted rustc [armhf] (hirsute-proposed) [1.45.0+dfsg1+llvm-2ubuntu1]
[06:27] -queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (hirsute-proposed) [1.45.0+dfsg1+llvm-2ubuntu1]
[06:37] -queuebot:#ubuntu-release- New: accepted linux-signed-gkeop [amd64] (focal-proposed) [5.4.0-1006.7]
[06:37] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.10 [amd64] (focal-proposed) [5.10.0-1006.7]
[06:38] -queuebot:#ubuntu-release- New: accepted linux-signed-azure-4.15 [amd64] (bionic-proposed) [4.15.0-1101.112]
[06:38] -queuebot:#ubuntu-release- New: accepted linux-signed-gkeop-5.4 [amd64] (bionic-proposed) [5.4.0-1006.7~18.04.1]
[06:38] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1075.80]
[06:38] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1104.115]
[06:38] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1101.112~16.04.1]
[06:38] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-127.130~16.04.1]
[06:38] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-127.130~16.04.1]
[08:01] <cpaelzer> ubuntu-archive: hi I've seen bug 1906673 on triage triggered by the SRU of bug 1868703. I have no further insight yet (we need to wait on the Author) but I wanted to ask if you think we should remove this from -updates&-security until solved?
[08:02] <cpaelzer> I beg your pardon, but I can't yet tell you if this is more like "one special setup breaks" or "tonigh after auto-updates most of sssd's will hang"
[08:30] <vorlon> cpaelzer: well, by this point almost everyone will have picked it up from security via unattended-upgrades so there's not much point
[08:35] <doko> finally, perl & python email spam
[08:41] <rbasak> I don't understand why that sssd update went to -security
[08:42] <rbasak> Surely with it being opt-in and the actual hardening being at the AD end, users could have opted in via -updates instead? Then we'd have had phasing.
[08:44] <LocutusOfBorg> yay!
[08:45] <LocutusOfBorg> auto sync on again?
[08:50] <cpaelzer> vorlon: yeah I have expected that after 21h (now almost 23h) - just wanted to be sure to ping and ask if there are corner cases that could ahve been benefitting a lot
[08:51] <cpaelzer> we'll see what mruffell uncovers when looking deeper into it
[08:52] <LocutusOfBorg> vorlon, mariadb-10.3 kick out from hirsute please?
[08:56] <rbasak> I didn't think mysql-defaults was switched over yet?
[08:57] <rbasak> Or maybe that doesn't matter on Ubuntu
[09:04] <LocutusOfBorg> rbasak, in ubuntu we still use mysql, I don't think mariadb has any effect?
[09:05] <rbasak> Yes hence my correction of myself. The change that Debian gets for mysql-defaults won't be needed on Ubuntu I think
[09:05] <rbasak> https://salsa.debian.org/mariadb-team/mysql/-/commit/e17ff57d72f5bfe90c27fc8fbdb9420f75cb23a3
[09:06] <rbasak> Since we have a delta that replaces that anyway
[09:06] <Laney> wee, looks like perl+python3-defaults went
[09:07] <Laney> auto-sync is on
[09:14] -queuebot:#ubuntu-release- New binary: q2-cutadapt [ppc64el] (hirsute-proposed/universe) [2020.11.0-1] (no packageset)
[09:14] -queuebot:#ubuntu-release- New binary: q2-metadata [ppc64el] (hirsute-proposed/universe) [2020.11.0+dfsg-1] (no packageset)
[09:15] <Laney> what did we need to restore, libcbor-xs-perl and ?
[09:15] -queuebot:#ubuntu-release- New binary: q2-feature-table [amd64] (hirsute-proposed/universe) [2020.11.0+dfsg-1] (no packageset)
[09:17] -queuebot:#ubuntu-release- New binary: q2-demux [amd64] (hirsute-proposed/universe) [2020.11.0-1] (no packageset)
[09:17] -queuebot:#ubuntu-release- New binary: q2-metadata [arm64] (hirsute-proposed/universe) [2020.11.0+dfsg-1] (no packageset)
[09:17] -queuebot:#ubuntu-release- New binary: q2-metadata [amd64] (hirsute-proposed/universe) [2020.11.0+dfsg-1] (no packageset)
[09:17] -queuebot:#ubuntu-release- New binary: q2-quality-filter [amd64] (hirsute-proposed/universe) [2020.11.0-1] (no packageset)
[09:18] -queuebot:#ubuntu-release- New binary: linux-signed-bluefield [arm64] (focal-proposed/universe) [5.4.0-1007.10] (no packageset)
[09:21] -queuebot:#ubuntu-release- New binary: q2-cutadapt [arm64] (hirsute-proposed/universe) [2020.11.0-1] (no packageset)
[09:25] <cjwatson> teward: my question was directed at upstream, not at the packaging :)
[09:25] <cjwatson> teward: I could see for myself that it was how the upstream Makefile was written, but that doesn't make it immune to reasonable questioning
[09:26] <LocutusOfBorg> Laney, I did borgbackup and I'm doing deal.ii
[09:26] <Laney> 👍
[09:28] -queuebot:#ubuntu-release- New binary: q2-cutadapt [amd64] (hirsute-proposed/universe) [2020.11.0-1] (no packageset)
[09:28] <LocutusOfBorg> according to the logs here we should be fine
[09:29] <LocutusOfBorg> I think libusrsctp removal on i386 failed...
[09:31] <ginggs> LocutusOfBorg: what are you doing to deal.ii?
[09:32] <LocutusOfBorg> I'm restoring the version that was kicked out from proposed
[09:32] <LocutusOfBorg> deal.ii 9.2.0-3
[09:32] <ginggs> LocutusOfBorg: ack
[09:33] <LocutusOfBorg> it was resetting python migration so it has been removed to let the transition finish :(
[09:33] <ginggs> deal.ii needs to go in big_packages now
[09:34] <LocutusOfBorg> that is probably the reason for the failures of yesterday
[09:34] <LocutusOfBorg> will you ask a mr?
[09:35] <ginggs> LocutusOfBorg: yes
[09:47] -queuebot:#ubuntu-release- Unapproved: sssd (bionic-updates/main) [1.16.1-1ubuntu1.7 => 1.16.1-1ubuntu1.6] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
[09:58] -queuebot:#ubuntu-release- Unapproved: accepted sssd [sync] (bionic-updates) [1.16.1-1ubuntu1.6]
[10:10]  * enyc meows
[10:33] -queuebot:#ubuntu-release- New binary: linux-signed-gcp-4.15 [amd64] (bionic-proposed/universe) [4.15.0-1089.102] (no packageset)
[10:33] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1060.66~16.04.1] (kernel)
[10:33] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1089.102~16.04.1] (kernel)
[10:34] -queuebot:#ubuntu-release- New: accepted linux-signed-bluefield [arm64] (focal-proposed) [5.4.0-1007.10]
[10:34] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp-4.15 [amd64] (bionic-proposed) [4.15.0-1089.102]
[10:34] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1060.66~16.04.1]
[10:34] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1089.102~16.04.1]
[10:55] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [ppc64el] (bionic-proposed/main) [5.4.0-57.63~18.04.1] (no packageset)
[10:56] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [s390x] (bionic-proposed/main) [5.4.0-57.63~18.04.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [amd64] (bionic-proposed/main) [5.4.0-57.63~18.04.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1060.66] (kernel)
[10:58] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [arm64] (bionic-proposed/main) [5.4.0-57.63~18.04.1] (no packageset)
[11:00] <Laney> runtime of proposed-migration is down by half between the last two runs (migrating perl & python3-defaults and the one after)
[11:09] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [amd64] (bionic-proposed) [5.4.0-57.63~18.04.1]
[11:09] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [ppc64el] (bionic-proposed) [5.4.0-57.63~18.04.1]
[11:09] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1060.66]
[11:09] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [arm64] (bionic-proposed) [5.4.0-57.63~18.04.1]
[11:09] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [s390x] (bionic-proposed) [5.4.0-57.63~18.04.1]
[12:01] -queuebot:#ubuntu-release- New binary: magma [ppc64el] (hirsute-proposed/multiverse) [2.5.4+ds-1] (no packageset)
[12:19] -queuebot:#ubuntu-release- Unapproved: accepted libevdev [source] (groovy-proposed) [1.9.1+dfsg-1ubuntu0.1]
[12:21] -queuebot:#ubuntu-release- Unapproved: accepted libevdev [source] (focal-proposed) [1.9.0+dfsg-1ubuntu0.1]
[12:22] <LocutusOfBorg> ubuntu-archive: ldc transition is holding because of glib-d not built everywhere
[12:22] <LocutusOfBorg> debian already dropped the same binaries rmadison -u debian libglibd-2.0-0
[12:23] -queuebot:#ubuntu-release- New binary: clickhouse [ppc64el] (hirsute-proposed/universe) [18.16.1+ds-7.2] (no packageset)
[12:23] <LocutusOfBorg> is it possible to kick armhf riscv64 s390x out so we can have the migration?
[12:25] <LocutusOfBorg> the very same should happen to gir-to-d
[12:29] -queuebot:#ubuntu-release- New binary: magma [amd64] (hirsute-proposed/multiverse) [2.5.4+ds-1] (no packageset)
[13:39] -queuebot:#ubuntu-release- New binary: clickhouse [amd64] (hirsute-proposed/universe) [18.16.1+ds-7.2] (no packageset)
[14:23] -queuebot:#ubuntu-release- Unapproved: accepted libevdev [source] (bionic-proposed) [1.5.8+dfsg-1ubuntu0.1]
[14:44] -queuebot:#ubuntu-release- New: accepted clickhouse [amd64] (hirsute-proposed) [18.16.1+ds-7.2]
[14:44] -queuebot:#ubuntu-release- New: accepted magma [amd64] (hirsute-proposed) [2.5.4+ds-1]
[14:44] -queuebot:#ubuntu-release- New: accepted clickhouse [ppc64el] (hirsute-proposed) [18.16.1+ds-7.2]
[14:44] -queuebot:#ubuntu-release- New: accepted magma [ppc64el] (hirsute-proposed) [2.5.4+ds-1]
[14:45] -queuebot:#ubuntu-release- New: accepted q2-demux [amd64] (hirsute-proposed) [2020.11.0-1]
[14:45] -queuebot:#ubuntu-release- New: accepted q2-metadata [amd64] (hirsute-proposed) [2020.11.0+dfsg-1]
[14:45] -queuebot:#ubuntu-release- New: accepted q2-metadata [ppc64el] (hirsute-proposed) [2020.11.0+dfsg-1]
[14:45] -queuebot:#ubuntu-release- New: accepted q2-feature-table [amd64] (hirsute-proposed) [2020.11.0+dfsg-1]
[14:45] -queuebot:#ubuntu-release- New: accepted q2-quality-filter [amd64] (hirsute-proposed) [2020.11.0-1]
[14:45] -queuebot:#ubuntu-release- New: accepted q2-metadata [arm64] (hirsute-proposed) [2020.11.0+dfsg-1]
[14:45] -queuebot:#ubuntu-release- New: accepted q2-cutadapt [amd64] (hirsute-proposed) [2020.11.0-1]
[14:45] -queuebot:#ubuntu-release- New: accepted q2-cutadapt [ppc64el] (hirsute-proposed) [2020.11.0-1]
[14:45] -queuebot:#ubuntu-release- New: accepted q2-cutadapt [arm64] (hirsute-proposed) [2020.11.0-1]
[14:47] -queuebot:#ubuntu-release- Unapproved: accepted libinput [source] (groovy-proposed) [1.16.2-1ubuntu0.1]
[14:54] -queuebot:#ubuntu-release- Unapproved: accepted libinput [source] (focal-proposed) [1.15.5-1ubuntu0.2]
[14:56] -queuebot:#ubuntu-release- Unapproved: accepted libinput [source] (bionic-proposed) [1.10.4-1ubuntu<IP_ADDRESS>]
[15:02] <tjaalton> tseliot: hi, you have a new ubuntu-drivers-common on the sru queue for groovy, but there's another version in proposed since quite a while and it hasn't been verified yet
[15:05] <tjaalton> and it's basically blocking the uploads for f/b as well (nvidia-prime too)
[15:06] -queuebot:#ubuntu-release- Unapproved: rejected borgbackup [source] (xenial-proposed) [1.0.13-0ubuntu<IP_ADDRESS>]
[15:06] -queuebot:#ubuntu-release- Unapproved: rejected borgbackup [source] (bionic-proposed) [1.1.14-2ubuntu<IP_ADDRESS>]
[15:07] -queuebot:#ubuntu-release- Unapproved: rejected borgbackup [source] (focal-proposed) [1.1.14-2ubuntu<IP_ADDRESS>]
[15:46] <vorlon> LocutusOfBorg: mariadb-10.3 kicked out
[15:47] <vorlon> LocutusOfBorg: libusrsctp removal> lol apparently I had neutered my script and it was echoing commands instead of doing actual removals
[15:53] <vorlon> LocutusOfBorg: really removed now
[16:05] -queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (focal-proposed) [6.1.16-dfsg-4ubuntu<IP_ADDRESS>]
[16:05] -queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (focal-proposed) [6.1.16-dfsg-4~ubuntu<IP_ADDRESS>]
[16:06] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.48]
[16:17] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.63]
[16:17] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.64]
[16:21] <tjaalton> vorlon: you started going through sru's?
[16:21] <vorlon> tjaalton: well, I'm taking livecd-rootfs per request; I'm not going through others just yet
[16:21] <tjaalton> ah ok
[16:22] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.60 => 2.408.64] (desktop-core)
[16:32] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.64]
[16:58] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (groovy-proposed) [<IP_ADDRESS>]
[17:11] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.8 => 2.664.10] (desktop-core, i386-whitelist)
[17:34] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (focal-proposed) [<IP_ADDRESS>]
[17:44] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (bionic-proposed) [<IP_ADDRESS>]
[17:49] <bdmurray> rbasak: Was that the right one for focal?
[17:50] <LocutusOfBorg> thanks vorlon !
[17:56] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (xenial-proposed) [3.168.12]
[18:05] <rbasak> bdmurray: no that's the one that did a whole bunch of extra stuff I don't think was intended to be SRU'd.
[18:06] <rbasak> bdmurray: eg:
[18:06] <rbasak> -               autotools-dev,
[18:06] <rbasak> -X-Python3-Version: >= 3.2
[18:06] <bdmurray> rbasak: that's the one you accepted https://launchpad.net/ubuntu/+source/update-notifier/<IP_ADDRESS>
[18:07] <rbasak> +rm_conffile /etc/update-motd.d/20-cpu-checker 0.110.1ubuntu1
[18:07] <rbasak> etc
[18:07] <rbasak> I didn't accept anything
[18:07] <rbasak> Ah I thought that was you
[18:07] <rbasak> tjaalton: ^
[18:07] <bdmurray> vorlon: ?
[18:08] <rbasak> I discussed with blackboxsw earlier and was going to finish reviewing on Monday
[18:09] <rbasak> tjaalton: I think the Focal SRU is wrong and should be deleted from proposed. It'll need replacing
[18:10] <blackboxsw> rbasak: .... so "it'll need replacing" does that mean we need to reperform a dput of update-notifier?
[18:10] <blackboxsw> for Unapproved: accepted update-notifier [source] (focal-proposed) [<IP_ADDRESS>]   ?
[18:11] <rbasak> blackboxsw: it will now, since the version number is burned
[18:11] <rbasak> I can clean this up on Monday if needed, but if someone can coordinate with tjaalton and an AA to get the Focal one deleted please - as I'm EOD already.
[18:15] <blackboxsw> thx rbasak.   hrm, so, bdmurray what shall we do here? Shall we just uprev focal and drop the cron -> systemd changes in a new focal <IP_ADDRESS>. Do we want to try to solve this -proposed upload/rejection by working on a potential solution for the migration from disabled cron -> systemd timer and maybe add that to to hirsute and add it to the  focal <IP_ADDRESS> rev (and groovy).
[18:15] <tjaalton> rbasak: oh dang
[18:15] <tjaalton> vorlon: ^ care to delete it?
[18:16] <bdmurray> blackboxsw: we should just drop the cron -> systemd changes
[18:17] <blackboxsw> right, but we also just burned the focal version <IP_ADDRESS> right?
[18:17] <blackboxsw> because it got accepted and will be deleted now
[18:18] <rbasak> Yes but I can just fix that up on Monday, re-"sponsor" the upload and SRU accept in one go, so don't worry about that part.
[18:18] <blackboxsw> so my question is, don't we now have to upload a version <IP_ADDRESS> for focal which would back out those cron -> systemd timer changes because <IP_ADDRESS> was burned
[18:22] <blackboxsw> ok I think that last comment from robie means nothing else to do here.
[18:22]  * blackboxsw stands down
[18:24] <tjaalton> or apw, you still around? update-notifier in focal-proposed should be removed
[18:40] <vorlon> tjaalton: that's update-notifier/focal-proposed?
[18:41] <tjaalton> vorlon: yes
[18:43] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.10]
[18:44] <vorlon> tjaalton: done
[18:45] <tjaalton> great, thanks
[18:54] <ginggs> ubuntu-release: should I ask for MR reviews here, or is requesting it in launchpad enough?
[18:56] <ginggs> vorlon: thanks :)
[18:56] <vorlon> ginggs: heh :)
[19:20] <vorlon> Laney: schleuder autopkgtest fails on armhf because the daemon binds to [::1]:4443, and then tries to connect to <IP_ADDRESS>:4443.  This is a bad test because it shouldn't assume things about the host's setting of /proc/sys/net/ipv6/bindv6only, but do you know why the behavior is different on the armhf runners? (FTR /proc/sys/net/ipv6/bindv6only within the container looks correct)
[19:20]  * ogra wonders if vorlon has already considered asking for budget for an intern to keep the bug status of lp #1871268 intact
[19:21] <vorlon> ogra: >_< what is it with all these people assigning the bug to themselves
[19:21] <ogra> yeah, its insane ... i really feel pity for you guys
[19:27] -queuebot:#ubuntu-release- Unapproved: ceph (groovy-proposed/main) [15.2.5-0ubuntu1.1 => 15.2.7-0ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[19:41] -queuebot:#ubuntu-release- Unapproved: ceph (focal-proposed/main) [15.2.5-0ubuntu<IP_ADDRESS> => 15.2.7-0ubuntu<IP_ADDRESS>] (desktop-core, ubuntu-server)
[19:50] <coreycb> vorlon: hi, would you or someone else from ubuntu-sru be able to take a look at ceph 15.2.7 in the focal and groovy unapproved queue? I've just recently uploaded. it has a critical fix for a data loss issue that at least one of our users has hit.
[19:51] <bdmurray> coreycb: I can look once I kick off a build
[19:51] <coreycb> bdmurray: thanks :)
[19:52] <coreycb> bdmurray: hirsute is still building for this but s390 has completed successfully
[19:54] <vorlon> stgraber: ^^ or maybe I should be asking you why the bindv6only behavior is silently different in our container-based runners vs VM-based :)
[19:54] <vorlon> bdmurray: do you want to leave it to me since it's my SRU day?
[19:55] <bdmurray> vorlon: okay
[20:03] <vorlon> coreycb: https://wiki.ubuntu.com/OpenStackUpdates
[20:03] <vorlon> coreycb: note that this is now a redirect
[20:04] <coreycb> vorlon: noted, thanks
[20:05] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (groovy-proposed) [15.2.7-0ubuntu<IP_ADDRESS>]
[20:05] <vorlon> Laney: https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/394906 for your consideration
[20:06] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (focal-proposed) [15.2.7-0ubuntu<IP_ADDRESS>]
[20:10] -queuebot:#ubuntu-release- New source: openstack-release (hirsute-proposed/primary) [1.0ubuntu1]
[20:12] <vorlon> mm how do I tell if a sync in a queue is a binary sync or a source sync?
[20:13] <vorlon> I guess by downloading it :P
[20:15] <vorlon> kenvandine: hi, what is https://launchpad.net/~ahayzen/+archive/ubuntu/flatpak-manual-uploads-1-8-3-clean-1-groovy and why are you doing a binary sync from it instead of building in the main archive?
[20:15] -queuebot:#ubuntu-release- New: rejected mfgtools [sync] (groovy-proposed) [1.3.191-1]
[20:29] -queuebot:#ubuntu-release- Unapproved: rejected flatpak [sync] (groovy-proposed) [1.8.3-0ubuntu0.1]
[20:38] <kenvandine> vorlon: oh, sorry that should not have been a binary copy.
[20:38] <kenvandine> I'll copy the source only properly
[20:47] <vorlon> kenvandine: ok, cheers.  also, I marked the SRU bug incomplete because I'm looking for a clearer justification for the SRU
[20:48] <vorlon> RikMills: not a blocker for the SRU, but you might be interested in dh --with-quilt as a cleaner approach to the build system changes
[20:49] <RikMills> vorlon: ok. noted
[20:49] <vorlon> RikMills: ah, though you didn't do the upload I guess :)
[20:49] <RikMills> vorlon: no, I will pass that on
[20:50] -queuebot:#ubuntu-release- Unapproved: accepted signon [source] (groovy-proposed) [8.59+17.10.20170606-0ubuntu<IP_ADDRESS>]
[20:51] -queuebot:#ubuntu-release- Unapproved: accepted signon [source] (focal-proposed) [8.59+17.10.20170606-0ubuntu<IP_ADDRESS>]
[20:52] <RikMills> thank you :)
[20:59] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu27.14]
[21:00] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (groovy-proposed) [2.20.11-0ubuntu50.3]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (bionic-proposed) [2.20.9-0ubuntu7.21]
[21:02] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (xenial-proposed) [2.20.1-0ubuntu2.28]
[21:10] <vorlon> LocutusOfBorg: /var/run/vboxweb-service.sh - /var/run is an obsolete symlink to /run and should be removed everywhere, this virtualbox-hwe SRU contains a regression
[21:10] <LocutusOfBorg> mmm will fix
[21:11] <LocutusOfBorg> but it was broken before, so who cares?
[21:11] <LocutusOfBorg> I mean, it does work, right?
[21:13] <vorlon> LocutusOfBorg: the previous text listed /run, the new text lists /var/run, /var/run is a plague :)
[21:13] <LocutusOfBorg> I uploaded in debian, will upload in groovy
[21:13] <LocutusOfBorg> hirsute I mean, and then groovy
[21:55] <vorlon> hmm so rails autopkgtests appear to now depend on qunit-selenium -> chromium-driver, so that's not going to work anymore on ppc64el or s390x
[23:11] -queuebot:#ubuntu-release- Unapproved: adcli (bionic-proposed/universe) [0.8.2-1ubuntu1 => 0.8.2-1ubuntu1] (no packageset) (sync)
[23:11] -queuebot:#ubuntu-release- Unapproved: adcli (focal-proposed/main) [0.9.0-1ubuntu<IP_ADDRESS> => 0.9.0-1ubuntu<IP_ADDRESS>] (no packageset) (sync)
[23:12] -queuebot:#ubuntu-release- Unapproved: accepted adcli [sync] (bionic-proposed) [0.8.2-1ubuntu1]
[23:12] -queuebot:#ubuntu-release- Unapproved: adcli (groovy-proposed/main) [0.9.0-1ubuntu1.2 => 0.9.0-1ubuntu1.2] (ubuntu-desktop, ubuntu-server) (sync)
[23:12] -queuebot:#ubuntu-release- Unapproved: accepted adcli [sync] (focal-proposed) [0.9.0-1ubuntu<IP_ADDRESS>]
[23:12] -queuebot:#ubuntu-release- Unapproved: accepted adcli [sync] (groovy-proposed) [0.9.0-1ubuntu1.2]
[23:54] -queuebot:#ubuntu-release- New binary: libexadrums [amd64] (hirsute-proposed/universe) [0.5.2-1] (no packageset)
[23:55] -queuebot:#ubuntu-release- New binary: libgit2 [ppc64el] (hirsute-proposed/universe) [1.0.1+dfsg.1-3] (kubuntu)
[23:55] -queuebot:#ubuntu-release- New binary: nifticlib [ppc64el] (hirsute-proposed/universe) [3.0.1-1] (no packageset)
[23:55] -queuebot:#ubuntu-release- New binary: nifticlib [amd64] (hirsute-proposed/universe) [3.0.1-1] (no packageset)
[23:55] -queuebot:#ubuntu-release- New binary: antlr4-cpp-runtime [amd64] (hirsute-proposed/universe) [4.9+dfsg-1] (no packageset)
[23:55] -queuebot:#ubuntu-release- New binary: gvm-libs [amd64] (hirsute-proposed/universe) [20.8.0-1] (no packageset)
[23:55] -queuebot:#ubuntu-release- New binary: pg-wait-sampling [amd64] (hirsute-proposed/universe) [1.1.2-2] (no packageset)
[23:55] -queuebot:#ubuntu-release- New binary: appstream [ppc64el] (hirsute-proposed/main) [0.13.1-1] (core)
[23:55] -queuebot:#ubuntu-release- New binary: nuspell [amd64] (hirsute-proposed/universe) [4.1.0-1] (no packageset)
[23:56] -queuebot:#ubuntu-release- New binary: antlr4-cpp-runtime [s390x] (hirsute-proposed/universe) [4.9+dfsg-1] (no packageset)
[23:56] -queuebot:#ubuntu-release- New binary: pg-wait-sampling [ppc64el] (hirsute-proposed/universe) [1.1.2-2] (no packageset)
[23:56] -queuebot:#ubuntu-release- New binary: libexadrums [ppc64el] (hirsute-proposed/universe) [0.5.2-1] (no packageset)
[23:56] -queuebot:#ubuntu-release- New binary: umtp-responder [amd64] (hirsute-proposed/universe) [1.3.10-1] (no packageset)
[23:56] -queuebot:#ubuntu-release- New: accepted antlr4-cpp-runtime [amd64] (hirsute-proposed) [4.9+dfsg-1]
[23:56] -queuebot:#ubuntu-release- New: accepted appstream [ppc64el] (hirsute-proposed) [0.13.1-1]
[23:56] -queuebot:#ubuntu-release- New: accepted libexadrums [ppc64el] (hirsute-proposed) [0.5.2-1]
[23:56] -queuebot:#ubuntu-release- New: accepted nuspell [amd64] (hirsute-proposed) [4.1.0-1]
[23:56] -queuebot:#ubuntu-release- New: accepted pg-wait-sampling [ppc64el] (hirsute-proposed) [1.1.2-2]
[23:56] -queuebot:#ubuntu-release- New binary: antlr4-cpp-runtime [ppc64el] (hirsute-proposed/universe) [4.9+dfsg-1] (no packageset)
[23:56] -queuebot:#ubuntu-release- New binary: libgit2 [amd64] (hirsute-proposed/universe) [1.0.1+dfsg.1-3] (kubuntu)
[23:56] -queuebot:#ubuntu-release- New: accepted antlr4-cpp-runtime [s390x] (hirsute-proposed) [4.9+dfsg-1]
[23:56] -queuebot:#ubuntu-release- New: accepted libgit2 [ppc64el] (hirsute-proposed) [1.0.1+dfsg.1-3]
[23:56] -queuebot:#ubuntu-release- New: accepted umtp-responder [amd64] (hirsute-proposed) [1.3.10-1]
[23:56] -queuebot:#ubuntu-release- New: accepted gvm-libs [amd64] (hirsute-proposed) [20.8.0-1]
[23:56] -queuebot:#ubuntu-release- New binary: appstream [s390x] (hirsute-proposed/main) [0.13.1-1] (core)
[23:56] -queuebot:#ubuntu-release- New: accepted pg-wait-sampling [amd64] (hirsute-proposed) [1.1.2-2]
[23:57] -queuebot:#ubuntu-release- New: accepted libexadrums [amd64] (hirsute-proposed) [0.5.2-1]
[23:57] -queuebot:#ubuntu-release- New: accepted nifticlib [ppc64el] (hirsute-proposed) [3.0.1-1]
[23:57] -queuebot:#ubuntu-release- New binary: fis-gtm [amd64] (hirsute-proposed/universe) [6.3-014-1] (no packageset)
[23:57] -queuebot:#ubuntu-release- New binary: nuspell [ppc64el] (hirsute-proposed/universe) [4.1.0-1] (no packageset)
[23:57] -queuebot:#ubuntu-release- New: accepted nifticlib [amd64] (hirsute-proposed) [3.0.1-1]
[23:57] -queuebot:#ubuntu-release- New binary: libexadrums [s390x] (hirsute-proposed/universe) [0.5.2-1] (no packageset)
[23:57] -queuebot:#ubuntu-release- New binary: appstream [armhf] (hirsute-proposed/main) [0.13.1-1] (core)
[23:57] -queuebot:#ubuntu-release- New binary: qpdfview [amd64] (hirsute-proposed/universe) [0.4.18-3] (lubuntu)
[23:57] -queuebot:#ubuntu-release- New binary: umtp-responder [ppc64el] (hirsute-proposed/universe) [1.3.10-1] (no packageset)
[23:58] -queuebot:#ubuntu-release- New binary: libgit2 [s390x] (hirsute-proposed/universe) [1.0.1+dfsg.1-3] (kubuntu)
[23:58] -queuebot:#ubuntu-release- New binary: nuspell [s390x] (hirsute-proposed/universe) [4.1.0-1] (no packageset)
[23:58] -queuebot:#ubuntu-release- New binary: nifticlib [s390x] (hirsute-proposed/universe) [3.0.1-1] (no packageset)
[23:58] -queuebot:#ubuntu-release- New binary: pg-wait-sampling [s390x] (hirsute-proposed/universe) [1.1.2-2] (no packageset)
[23:58] -queuebot:#ubuntu-release- New binary: appstream [arm64] (hirsute-proposed/main) [0.13.1-1] (core)
[23:58] -queuebot:#ubuntu-release- New binary: qpdfview [ppc64el] (hirsute-proposed/universe) [0.4.18-3] (lubuntu)
[23:59] -queuebot:#ubuntu-release- New binary: antlr4-cpp-runtime [arm64] (hirsute-proposed/universe) [4.9+dfsg-1] (no packageset)
[23:59] -queuebot:#ubuntu-release- New binary: qpdfview [s390x] (hirsute-proposed/universe) [0.4.18-3] (lubuntu)
[23:59] -queuebot:#ubuntu-release- New binary: umtp-responder [riscv64] (hirsute-proposed/universe) [1.3.10-1] (no packageset)
[23:59] -queuebot:#ubuntu-release- New binary: appstream [amd64] (hirsute-proposed/main) [0.13.1-1] (core)
[23:59] -queuebot:#ubuntu-release- New binary: umtp-responder [s390x] (hirsute-proposed/universe) [1.3.10-1] (no packageset)


[02:03] <tenaciousmv> has anyone built snaps with private git/npm dependencies?
[04:18] <mup> Bug #1595987 changed: udev denials  <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1595987>
[06:04] <morphis_> mwhudson: ping
[06:23] <mwhudson> morphis_: hi
[06:24] <mwhudson> morphis_: sounds like you know more about wifi details than me, do you want to submit a probert pr?
[06:24] <morphis_> mwhudson: I could but not real soon
[06:25] <mup> PR snapd#1994 opened: snap: add `snap known --store` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1994>
[06:25] <morphis_> mwhudson: but I think using something like https://pypi.python.org/pypi/libnl/ to talk with the kernel would be a good thing
[06:25] <mwhudson> morphis_: huh hadn't seen that one
[06:26] <morphis_> mwhudson: however I think for the short term not breaking when the error occurs and requesting CONFIG_CFG80211_WEXT enabled in the kernel is a good start
[06:26] <mwhudson> morphis_: i guess the patch i added is at least better than doing nothing
[06:26] <morphis_> yeah
[06:26] <morphis_> mwhudson: but we shouldn't close the bug with this
[06:27] <mwhudson> exactly
[06:27] <mwhudson> netlink is so very ... the sort of api a kernel developer would think of, i guess
[06:27] <morphis_> yeah
[06:28] <mwhudson>     while RTA_OK(hdr, remaining):
[06:28] <mwhudson> also it's 1930 here and i'm going to try not to work every evening this week :-)
[06:29] <morphis_> mwhudson: yeah, I agree with that!
[06:29] <morphis_> mwhudson: just one last question
[06:30] <mwhudson> heh
[06:30] <morphis_> mwhudson: I am currently hitting the problem that I can't enter @ anymore in the "Profile setup" screen
[06:30] <morphis_> mwhudson: this is on the edge channel
[06:30] <mwhudson> morphis_: !
[06:30] <morphis_> on beta it works still
[06:30] <mwhudson> morphis_: it worked on an image i made today
[06:30] <mwhudson> 738
[06:30] <morphis_> hm
[06:30] <mwhudson> on a dragonboard
[06:30] <morphis_> then it must be my keyboard or so
[06:30] <morphis_> this is on a pi3
[06:31] <mwhudson> morphis_: over serial or usb?
[06:31] <mwhudson> i know some keymap related stuff was added to the image recently
[06:31] <mwhudson> but i didn't think we were doing anything with that yet
[06:31] <morphis_> its over a usb keyboard plugged into the dongle
[06:31] <morphis_> and having the pi on a hdmi screen
[06:32] <mwhudson> yeah, that's the setup i was using
[06:32] <morphis_> then it seems to be a image problem
[06:43] <mup> PR snapd#1995 opened: interfaces/builtin: fix resolvconf permissions for network-manager interface <Created by morphis> <https://github.com/snapcore/snapd/pull/1995>
[06:46] <morphis_> ogra_: ping
[06:47] <zyga> good mornign
[06:47] <zyga> *morning
[06:48] <dholbach> hey hey
[06:50] <didrocks> hey dholbach, zyga
[06:50] <didrocks> dholbach: snap-codelabs is available FYI
[06:51] <dholbach> wow wow wow
[06:51] <dholbach> nice work didrocks
[06:51] <dholbach> mhall119_, popey_: ^
[06:51] <didrocks> dholbach: based on mhall119_ first snapcraft.yaml, but quite tweaked to make it lightweight then :)
[06:52] <dholbach> well done!
[06:54] <dholbach> didrocks, hum, which port does it listen on?
[06:54] <didrocks> dholbach: see the snap long description :) 8123
[06:55] <dholbach> ah yes, of course
[06:55] <dholbach> great
[07:02] <liuxg> recently, I use nodejs to compile some project, in some cases, if I add some modules, the compilation fails. I am not sure whether this is related to our nodejs plugin or not. thanks
[08:04] <morphis_> pitti: I've updated https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 , can you have another look?
[08:05] <pitti> morphis_: I already did some minutes ago
[08:05] <pitti> morphis_: as I said, this is fine for a PoC in a PPA, but this is not a "solution"
[08:06] <pitti> packaging a leaf application might have this namespacing, but if you want to provide OS components as snaps they can't have the same restrictions
[08:07] <pitti> the idea was to isolate stuff, not hardcode alternate names for snap OS parts in a hundred places (plus breaking third-party stuff which we can't control)
[08:07] <morphis_> pitti: there needs to be a lot more love happening but I still think if netplan is included on ubuntu core it shouldn't come with not functional support for backends
[08:07] <morphis_> pitti: I totally agree with that
[08:10] <morphis_> pitti: but that is what is giving today with snaps and netplan is included as a first class citizen on Ubuntu Core so it should take care about what it supports today and ask for changes those things solved
[08:10] <morphis_> pitti: I see the risk that somebody doesn't know about that patch included in the ppa and then just release a new upstream release and overrides everything
[08:15] <popey_> didrocks: tried to find it on my pi, and it can't find codelabs, is that because it's amd64 only?
[08:15] <morphis_> ogra_, mvo: so are you guys accepting not-upstream-patches for the netplan debian package in the ppa which ends up in the OS snap? not sure how the maintenance goes here but there needs be some ensurance that those changes are not overriden by anyone trying to bring in a new release from upstream netplan
[08:15] <ogra_> morphis_, wll, they need to be gone from the PPA and landed in -updates before november
[08:16] <morphis_> pitti: ^^
[08:16] <didrocks> popey: yeah, I didn't build armhf binary (yet)
[08:16] <popey> ok
[08:16] <ogra_> if you guys think thats manageable, sure, lets have it in the PPA til then... the inal release must come from -updates
[08:16] <ogra_> *final
[08:17] <popey> didrocks: I can build it on my pi here if you want, where's the branch?
[08:17] <pitti> well, then you move it from being your responsibility to fix snaps to being my responsibility to ever get rid of this :)
[08:17] <morphis_> ogra_: the thing is pitti does not agree with https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 and does not want it in netplan upstream
[08:17] <pitti> and it's certaily not the only place that calls nmcli, like netplan isn't the only package that expects NetworkManager.service or bluez.service or cups.service or whatnot
[08:17] <ogra_> right, so the quetion is if it can be a distro patch in xenial ...
[08:17] <morphis_> ogra_: so if we can't keep the netplan package in the ppa after the final release then then this needs to be considered differently
[08:18] <ogra_> or if you guys find a proper solution before nov.
[08:18] <pitti> yes, a distro patch in the xenial backport would be more bearable
[08:18] <ogra_> we will keep it in the PPA, but th btea and stable images wont use the PPA
[08:18] <pitti> although it's still completely wrong
[08:18] <pitti> this has to be fixed properly anyway at some point..
[08:18] <morphis_> ogra_: what do you mean by beta images?
[08:18] <didrocks> popey: it's not just a question of snapcraft snap unfortunatly, you need to have a go env ready
[08:19] <didrocks> popey: I guess it's quicker if I do it, one sec
[08:19] <pitti> ogra_: ok, I'll start putting together a NetworkManager SRU for the netplan support patches then
[08:19] <ogra_> morphis_, https://wiki.ubuntu.com/QATeam/OSSnapPromotion
[08:19] <pitti> ogra_: I guess you currently have that in the PPA? (which one is that?)
[08:19] <ogra_> eventually only edge will use the PPA
[08:19] <ogra_> all other channels come from proposed or updatess later
[08:19] <ogra_> (later = by release)
[08:19] <pitti> not in https://launchpad.net/~snappy-dev/+archive/ubuntu/image
[08:19] <morphis_> ogra_: so the current beta images don't use the ppa?
[08:20] <ogra_> pitti, we have "a" netplan there
[08:20] <mup> PR snapd#1996 opened: daemon: add the actual ssh keys that got added to the create-user response <Created by mvo5> <https://github.com/snapcore/snapd/pull/1996>
[08:20] <didrocks> popey: can I fake a snapcraft snap on some arch?
[08:20] <popey> didrocks: when you say "long description" for the port number, where's that?
[08:20] <pitti> ogra_: right, but netplan does not work with xenial's NM
[08:20] <popey> didrocks: dunno
[08:20] <ogra_> morphis_, currently they do, but we are workibng on getting all the PPA changes into -updates before release
[08:21] <popey> didrocks: I just have classic on my pi, so can use it to snapcraft things, works fine
[08:21] <didrocks> popey: I think nothing apart from uappexplorer exposes it
[08:21] <popey> oh, okay
[08:21] <didrocks> popey: hum, ok, so, I will need you :)
[08:21] <didrocks> I can give you the binary
[08:21] <morphis_> ogra_, pitti: good then lets keep the patch as a distro one even for -updates
[08:21] <ogra_> morphis_, see the wikipage ... within the next two-three weeks wthis will be implemented
[08:21] <morphis_> pitti: I know that there will be a discussion to allow snaps shipping things like "nmcli" so they end up with a prefix "network-manager."
[08:21] <popey> didrocks: i installed it, and see nothing on that port
[08:22] <didrocks> popey: http://localhost:8123?
[08:22] <popey> yes
[08:22] <didrocks> weird, did it work for you dholbach?
[08:22] <ogra_> pitti, well, i guess it works with the snapped NM ...
[08:22] <dholbach> didrocks, yes
[08:22] <popey> ignore me didrocks
[08:22] <popey> pilot error
[08:22]  * didrocks ignores popey FOREVER!!! :)
[08:22] <popey> \o/
[08:22] <didrocks> ;)
[08:23] <didrocks> popey: so, git clone that branch: https://github.com/ubuntu/codelabs
[08:23] <popey> works now :)
[08:23] <morphis_> ogra_: it does
[08:23] <didrocks> I'll give you a binary to replace
[08:23] <didrocks> phew!
[08:23] <pitti> morphis_, ogra_: ah, ok; so you don't actually need these patches in xenial-updates then, it seems?
[08:23] <pitti> the NM ones, I mean
[08:23] <ogra_> we dont ?
[08:23] <morphis_> pitti: no, for the snap we don't need the nm patches in the deb package
[08:23] <ogra_> ah, right ... i guess we dont use the deb for packaging the snap
[08:23] <morphis_> pitti: we're not using the deb package for the snap at all
[08:24] <dz0ny_> btw, will you guys open source build server for snappys? currently it's a bit problematic building snaps for different platforms
[08:24] <morphis_> dz0ny_: you can already build snaps on launchpad for any architecture
[08:24] <dz0ny_> oh
[08:24] <dz0ny_> didn't know
[08:24] <didrocks> popey: take this binary and replace the one in the root dir with it: http://didrocks.fr/temp/codelabs
[08:25] <didrocks> popey: then, you should be able to build the snap
[08:25] <didrocks> (for armhf)
[08:25] <dz0ny_> morphis_: care to share link
[08:25] <popey> didrocks: ok
[08:25] <morphis_> dz0ny_: push a branch and look for a "Create snap package" on the overview site
[08:25] <morphis_> dz0ny_: like here: https://code.launchpad.net/~morphis/+junk/pi2-kernel-snap
[08:25] <ogra_> dz0ny_, upload your tree (bzr or git) to launchpad ... then you can pick "create snap"
[08:26] <popey> didrocks: what about "server" in that same directory, also an amd64 binary
[08:26] <dz0ny_> ah thx
[08:26] <didrocks> popey: silly me
[08:26] <didrocks> I didn't copy the right bin
[08:26] <popey> lulz
[08:27] <morphis_> ogra_: so can you upload a new netplan package then to the ppa if I give you one?
[08:27]  * ogra_ grins about mwhudson and cyphermox playing pingpong with bug 1621550
[08:27] <mup> Bug #1621550: Snappy should detect when running in KVM, specify correct ssh connection line <Snappy:New> <subiquity (Ubuntu):Triaged by cyphermox> <https://launchpad.net/bugs/1621550>
[08:27] <ogra_> morphis_, sure, who will work on getting it into update ? you or pitti ?
[08:27] <ogra_> *updates
[08:28] <didrocks> popey: so, the one you want is http://didrocks.fr/temp/server :)
[08:28] <didrocks> I didn't recompile the other one, it's not shipped in the snap
[08:28] <didrocks> (it's only to build the metadata)
[08:28] <morphis_> ogra_: don't know, I just care to have it in the beta image we're doing for our customer this week at the moment :-)
[08:28] <popey> :)
[08:28] <morphis_> pitti: can you take the -updates one?
[08:28] <ogra_> morphis_, well, i care to not lose it once we turn off the PPA :)
[08:28] <morphis_> yeah
[08:29] <pitti> morphis_: that's backport netplan with that PR?
[08:29] <morphis_> yes
[08:30] <ogra_> well, preferably get the one from the PPA into updates
[08:30] <ogra_> not ure if there are other changes
[08:30] <ogra_> *sure
[08:30] <ogra_> (i didnt put it thre)
[08:31]  * pitti creates an SRU bug
[08:31] <morphis_> pitti: thanks!
[08:36] <ogra_> ppisati, so i see an oops on the pi3 ... sadly only in the combo of having console=tty0 and HDMI enabld but i think it is somehow related to the wifi card
[08:37] <ogra_> i wonder if it is the same thing i saw on the bbb
[08:38] <ppisati> ogra_: can fill a bug with the cmdline used to provoke this?
[08:39] <ogra_> i can even give you an image that expoes it ... as long as you dont plug in a wire on first boot ... but it scrolls offscreen and there is no wayx to get proper logs before the user is set up ... which need working network
[08:39] <ogra_> *needs
[08:40] <ogra_> the pi3 image from http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has it ..
[08:40]  * ogra_ files bug
[08:43] <pitti> morphis_: tracking in bug 1627641
[08:43] <mup> Bug #1627641: Backport netplan to xenial <network-manager (Ubuntu):Fix Released> <nplan (Ubuntu):Fix Released> <network-manager (Ubuntu Xenial):Triaged by pitti> <nplan (Ubuntu Xenial):Triaged by pitti> <https://launchpad.net/bugs/1627641>
[08:44] <ogra_> ppisati, bug 1627643
[08:44] <mup> Bug #1627643: oops on pi3 (seemingly wlan related) <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1627643>
[08:44] <morphis_> pitti: ok, are you going to create a deb package with that patch now too?
[08:44] <morphis_> just that we do not do the same work twice
[08:45] <pitti> morphis_: yes; we eventually want to use netplan for cloud-images etc. as well, so at some point we'll need them; and I'd rather have the integration tests actually succeed
[08:45] <pitti> morphis_: (they cannot work without the NM patches)
[08:46] <morphis_> pitti: ok, can you hand that package to ogra_ then so that we can include it in the ppa real soon?
[08:47] <mup> Bug #1627643 opened: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1627643>
[08:49] <pitti> morphis_: why? AFAIK snappy edge is built with -proposed enabled, so it would suffice to just have it there? (which we can do today still)
[08:50] <pitti> morphis_: I suppose you just backported Read-config-from-run.patch and Read-system-connections-from-run.patch (I'm not aware of anything else that's needed, but I'll verify with nplan's test/integration.py)
[08:51] <ogra_> pitti, no, we turned off proposed (it caued skews)
[08:52] <ogra_> *caused
[08:52] <pitti> but if you aren't going to use the NM distro package, why do you need it in the PPA then?
[08:52] <ogra_> we need it on the image
[08:52] <ogra_> which means in the ubuntui-core snap
[08:52] <pitti> oh, nplan doesn't backport as-is, need a pep8 fallback for pycodestyle
[08:53] <pitti> still confused -- if you use an NM snap, you won't need the xenial-updates NM package with the /run patches in the snappy PPA
[08:53] <pitti> and if you use the distro package, then why bother with the snap and that ugly nplan patch?
[08:53] <ogra_> no, i will need the xenial-updatess nplan
[08:54] <pitti> oh, this was about nplan, not NM
[08:54] <ogra_> regarding NM we only care about the snap ... and that nplan doesnt break it when users install it by accident i guess
[08:54] <ogra_> break it -> the NM deb of xenial
[08:55] <ppisati> ogra_: i guess that is a 4.4 kernel, right?
[08:55] <ogra_> ppisati, whatever is recent in xenial, yeah
[08:55] <ogra_> 4.4.0-1023-raspi2
[08:55] <ppisati> ogra_: k
[09:02] <pitti> erk, NM is stuck in xenial-proposed (v-failed), pinging Aron
[09:17] <morphis_> pitti: as, those two patches are what we did
[09:17] <morphis_> pitti: in edge later today is fine through -proposed but we need it in beta by the end of the week
[09:18] <morphis_> pitti: if that is doable with the SRU, then I am fine, if not lets use the ppa
[09:18] <pitti> morphis_: oh, please do use the PPA; I just wanted to start the process for SRUing now
[09:18] <morphis_> pitti: ok, we can take the package you push to -proposed and copy it to the ppa
[09:18] <pitti> morphis_: there is a NetworkManager stuck in xenial-proposed (verification-failed), so we can't get NM into -proposed today
[09:19] <morphis_> ok
[09:19] <morphis_> pitti: can you ping me once the package is in -proposed?
[09:20] <pitti> morphis_: sure; I also subscribed you to the bug so you get updates from that too
[09:20] <morphis_> awesome!
[09:41] <mup> Bug #1624490 changed: Snap access to /dev/uinput <hardware> <snapd-interface> <uinput> <Snappy:New> <https://launchpad.net/bugs/1624490>
[11:25] <mup> PR snapd#1997 opened: tests: added install_local function <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1997>
[11:27] <ogra_> morphis, http://ubunt.eu/zQa7Xs definitelly needs aethercast so you can have it fly while working ;)
[12:24] <sborovkov> Hello. Anyone knows what's going on with ubuntu store? I can't submit any new snaps. getting unrecoverable error. And bunch of 503 when navigating the page.
[12:27] <cjwatson> sborovkov: There was a network issue recently, but if that was it it should be recovering now.
[12:27] <sborovkov> understood, thanks.
[13:00] <diddledan> random thinking which I'm sure has already been considered, but I wanted to mention it anyway: gui snaps can only display text using fonts installed in the snap when it was built from what I can tell with unofficial-hexchat. would be nice to share fonts between system and snaps
[13:02] <morphis_> pitti: looks like we should just update the exiting netplan package in the ppa rather than integrating recent new changes
[13:06] <pstolowski> jdstrand, hey! can you have another look at https://github.com/snapcore/snapd/pull/1832 ?
[13:06] <mup> PR snapd#1832: interfaces/builtin: support time and date settings via 'org.freedesktop.timedate1 <Created by stolowski> <https://github.com/snapcore/snapd/pull/1832>
[13:09] <jdstrand> pstolowski: yes
[13:21] <didrocks> popey: did you build the armhf snap for me to upload?
[13:21] <didrocks> I wonder if I can't otherwise, cheat with snapcraft ;)
[13:23] <popey> didrocks: I did, but I moved location and can't ssh to the pi now :)
[13:23] <popey> damn firewalls!
[13:23] <didrocks> haha! Who did this! :)
[13:24] <didrocks> popey: can wait tomorrow then, no worry ;)
[13:24] <popey> ta
[13:24] <popey> it installed but I didnt get an open port and didn't have time to check logs before I left, will take a look later
[13:24] <didrocks> oki!
[13:39] <mvo> ökt
[13:39] <mvo> pitti: hi! it looks like we may need sysfsutils as a snapd dependency
[13:40] <mvo> pitti: and therefore make it part of main, so that we can setup bits in /sys at boot time. or is there a different way to ensure /sys values are set on boot?
[13:40] <pitti> mvo: I'm sorry, do you REALLY mean sysfsutils?
[13:40] <mvo> pitti: maybe, so let me start differently. we need something that can set values in /sys
[13:40] <pitti> mvo: this is really not what you are looking for
[13:41] <mvo> pitti: oh, ok - glad I talked to you :)
[13:41] <mvo> pitti: what am I looking for?
[13:41] <pitti> mvo: man sysctl.d :)
[13:42] <pitti> mvo: *phew* :)
[13:42] <mvo> pitti: the man page talks about /proc/sys - it seems like we need /sys however. sorry, I'm sort of the messanger here only, zyga is working on gpio bits and we need to set some bits in /sys to control the right gpio
[13:44] <pitti> mvo: oh yes, that's sysctls for /proc/sys, I thought that's what you actually  meant
[13:44] <pitti> mvo: otherwise you want udev rules
[13:46] <mvo> pitti: aha, thanks, udev rules because /sys is too dynamic for the approvach that sysfsutils took?
[13:47] <mvo> zyga: you probably find the above useful -^ :)
[13:47]  * zyga looks
[13:47] <pitti> mvo: no, but sysfsutils was an evolutionary dead-end
[13:47] <zyga> oh, interesting, thank you pitti!
[13:48] <zyga> pitti: was it related to libsys2
[13:48] <pitti> mvo: it's completely useless and does not give you anything that you cannot already do with udev rules or just shell scripts, except for being racy
[13:48] <pitti> mvo: and it has been abandoned like 10 years ago
[13:48] <pitti> mvo: hence me being incredulous, sorry :)
[13:49] <zyga> it should be removed from the archive eventually :)
[13:49] <mvo> pitti: totally fine, I was earnest when I said "glad I talked to you" :)
[13:49] <zyga> but I'm also glad we talked, this is much easier
[13:52] <zyga> pitti: so a design question I have, perhaps: if snapd would like to generate such .conf files, should they live in /etc (which the man page reserves for the administrator) or in /run (which would require snapd to start and write them before stuff that may depend on it would)
[13:53] <zyga> pitti: hold that, I just realized I skipped the most essential message about using udev rules
[13:53] <zyga> pitti: so this is all irrelevant, thanks
[13:55] <pitti> zyga: yeah, there's always those two last crappy rdepends which keep it alive (FSVO "live")..
[13:56] <pitti> zyga: I dislike autogenerated files in /etc, as /etc should really/ideally be "settings that the admin did", not something fixed or derived
[13:57] <pitti> i. e. only "primary" configuration
[13:57] <pitti> zyga: so if these get derived from some other/primary config, putting them into /run is much better
[13:57] <pitti> zyga: it also eases your life as then it stays an internal implementation detail which you can change at any time
[13:57] <shuduo> mvo: hi, i'm trying to compile nextcloud snap target armhf on pc. then snapcraft --target-arch armhf complains "copy" plugin don't support cross compile. you have helped me on snapcraft 1.x. may i know any  solution for 2.x?
[13:57] <pitti> zyga: with /etc it never goes away and you need to deal with it on upgrades
[13:59] <mup> PR snapd#1998 opened: debian: re-add golang-github-gosexy-gettext-dev  <Created by mvo5> <https://github.com/snapcore/snapd/pull/1998>
[13:59] <zyga> pitti: is there a nice place we could put files in /run for udev to pick up?
[13:59] <pitti> zyga: /run/udev/rules.d/ ?
[14:00] <zyga> pitti: thanks, I see
[14:00] <pitti> zyga: but, maybe we sohuld take a step back and clarify what you want to do
[14:00] <zyga> pitti: right now I'm not going to change that but it seems like something we may want to explore down the line
[14:00] <pitti> zyga: i. e. which kind of sysfs attrs do you want to change, and at which point in time
[14:00] <zyga> pitti: well snapd has a way to influence various bits of the kernel
[14:00] <zyga> pitti: here we specifically want to export a GPIO pin to userspace
[14:00] <pitti> zyga: I mean, in the simplest case snapd could just open()/write() the attributes at startup and be done with it
[14:00]  * ogra_ wonders if you rather want a snippet in /etc/sysctl.d in your package
[14:01] <zyga> ogra_: no, because this is dynamic and it depends on interfaces
[14:01] <ogra_> ah, that GPIO thing again
[14:01]  * ogra_ remembers we talked abot it before
[14:01] <pitti> zyga: that doesn't sound like you would need to do that super-early in the boot sequence?
[14:01] <zyga> pitti: currently when an interface needs to use udev rules we just write them to /etc/udev.d/snap.* and reload udev
[14:01] <ogra_> but yeah, why not just write to /sys then ?
[14:01] <pitti> zyga: if you need to apply that to "any future hotplugs", then yes, let snapd put udev rules into /run/udev/rules.d/
[14:01] <zyga> pitti: well, before any snap apps start
[14:01] <ogra_> without udev
[14:02] <pitti> future hotplug events, I figure
[14:02] <zyga> pitti: I don't know if GPIO is very hotpluggable
[14:02] <pitti> if that's a thing, write temp udev rules, then trigger those in snapd, and let the rules take care of future events
[14:02] <zyga> pitti: this is more about having a way to influence bits in sysfs
[14:03] <morphis_> zyga: what is the problem with the current implementation of the GPIO iface in snapd?
[14:06] <zyga> morphis_: it doesn't work across reboots, it writes to sysfs whenever you ask for a snippet
[14:06] <morphis_> right
[14:07] <morphis_> zyga: should we add something like InitializeIfaceConnectionOnSnapdStartup()
[14:07] <morphis_> for an interface?
[14:07] <zyga> morphis_: for this case we should use udev rules for that
[14:07] <zyga> morphis_: everything else is persistent already
[14:07] <morphis_> how would udev rules apply to to sysfs nodes for GPIO's?
[14:08] <zyga> morphis_: 'echo' :)
[14:08] <zyga> morphis_: udev can just run any command
[14:08] <pitti> morphis_: erk, no
[14:08] <morphis_> zyga: sure but you need an event, right?
[14:08] <pitti> ATTR{yourattrname}="value"
[14:09] <pitti> yeah, you need to "coldplug" (udevadm trigger) them after writing to apply to existing devices
[14:09] <zyga> pitti: we already do that
[14:09] <pitti> "udevadm trigger --subsystem-match=gpio" or something suhc
[14:09] <zyga> pitti: well, we do a generic one
[14:10] <ogra_> dont ... that eats resources ... limit it to the subsystem
[14:11] <zyga> ogra_: we don't know this
[14:11] <ogra_> :)
[14:11] <zyga> ogra_: we cannot limit anything at this time
[14:11] <ogra_> now you do :)
[14:11] <ogra_> hmm
[14:11] <sil2100> Hey! I have a newbie problem in a quick python3-app snap I'm creating
[14:11] <zyga> ogra_: no, we don't know this in snapd, the udev code doesn't know what snippets are doing
[14:11] <zyga> ogra_: we'd have to provide richer data
[14:11] <zyga> ogra_: or parse existing data
[14:11] <ogra_> but your interface does, doesnt it ?
[14:11] <zyga> ogra_: no
[14:12] <zyga> ogra_: interface has no way to tell
[14:12] <ogra_> if i'm the gpio interface i know i want to act on gpio's ...
[14:12] <zyga> ogra_: the author might but the interface API would have to be changed in a somewhat major way to convey that today
[14:12] <pitti> or run it before systemd-udev-trigger.service, but then it must run really early, without many assumptions
[14:12] <zyga> ogra_: it's not something that's easy to change
[14:12] <zyga> ogra_: then you have to combine the  changed subsystems
[14:12] <zyga> ogra_: and in the end you might save some memory/whatever or get it wrong :/
[14:12] <zyga> ogra_: that's not something for this release
[14:13] <didrocks> sil2100: hey, what's up with it?
[14:13] <ogra_> ok ok
[14:13] <ogra_> :)
[14:13] <mup> PR snapcraft#828 opened: yaml xpath for errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/828>
[14:13] <sil2100> My snap is a standard python3 plugin-based snap, it installs some modules and a python script to /usr/bin/ as expected, but... after installing the snap and trying to run it, I em getting an 'exec: <command here>: not found'
[14:14] <sil2100> Even though when checking the /snap installation place, the script is in the usr/bin/ directory as expected, also the wrappers *should* set the PATH correctly
[14:14] <sil2100> But still, the launcher cannot find the script
[14:15] <didrocks> interesting… You should have a .wrapper script that the script in /snap/bin points to, correct?
[14:15] <didrocks> this is just shell, you can open it and look at what's added to your env
[14:15] <sil2100> Yes, examined the wrapper and everything seems to be ok there
[14:15] <didrocks> PATH is set?
[14:15] <didrocks> to your $SNAP/usr/bin ?
[14:16] <sil2100> I examined all the scripts that are executed on the way and it should be all good, with PATHs being set etc. but it doesn't seem to work
[14:16] <didrocks> you can try:
[14:16] <didrocks> snap run --shell <your command>
[14:16] <sil2100> Oh
[14:16] <didrocks> you will then be dropped in a shell, with the snap parameter
[14:16] <didrocks> just before the wrapper is run
[14:16] <ogra_> also ... snap install hello-world ...
[14:16] <didrocks> and maybe poke from there?
[14:16] <sil2100> Yeah, hello-world works fine
[14:16] <ogra_> then you can use helo-world.env to get info about the default vars
[14:16] <sil2100> Just my snap has some issues with the paths
[14:17] <ogra_> or hello-world.sh to spawn a shell inside the snap env
[14:17] <sil2100> Oh, ok, thanks for the pointers, let me dig further then
[14:17] <sil2100> :)
[14:17] <ogra_> :)
[14:20] <didrocks> I guess snap run --shell will land him in the right context for his snap, with his code nearby and such ;)
[14:21] <ogra_> all that new-world stuff ... pfft :P
[14:38] <morphis_> pitti: did you upload a new netplan package already somewhere?
[14:42] <sil2100> didrocks: this is really strange, I checked the environment variables when in --shell and the $SNAP variable is set correctly, I also hacked inside an echo $PATH right before the exec part in the final wrapper and the PATH also seems to be set correctly
[14:42] <pitti> morphis_: no, I didn't; still working on that networkd regression; but netplan itself needs no change other than adjusting the Breaks:
[14:43] <morphis_> pitti: I am going to create just an updated nplan package over the one we already have in ppa to cause no big regressions
[14:44] <sil2100> didrocks: and the /snap/landing-team-tools/x1/usr/bin dir has the binary as required, doing a simple PATH=/snap/landing-team-tools/x1/usr/bin:$PATH image-info (which is the command name) works in the same shell
[14:44] <mup> PR snapd#1999 opened: daemon: add REST API behind `snap get` <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1999>
[14:45] <sil2100> Let me try removing setting the LD_LIBRARY_PATH in the wrapper script
[14:47] <sil2100> hm, yeah, it seems that setting the LD_LIBRARY_PATH seems to somehow break the exec line, making it not find the binary
[14:50] <pitti> morphis_: sure; as I said, go wild with the PPA for now
[14:50] <morphis_> aye
[14:54] <didrocks> sil2100: interestingly weird
[15:08] <ogra_> asac, *sniff*
[15:16] <pitti> morphis_: I just figured out the necessary networkd fix (the previous one was a red herring)
[15:17] <pitti> morphis_: however, with LP (and other caonical services) being down I can't update/upload anything :(
[15:26] <morphis_> pitti: yeah!
[15:50] <zyga> oh, launchpad is down
[15:59] <modprobe__> Trying to create a snap, but after all of my parts finish priming, snapcraft just exists saying "[Errno 21] Is a directory: '/home/dev/swv/prime/.'" (where my snapcraft.yaml is in /home/dev/swv/)
[16:01] <modprobe__> I've got three different custom plugins in this snap, though. This project does not go into a snap without a fight.
[16:01] <modprobe__> But none of those plugins do anything unusual except during the build step
[16:06] <ogra_> slangasek, i assume you have seen my comment on bug 1627146 ?
[16:06] <mup> Bug #1627146: ubuntu-image creates 'small' ext4 filesystems, which take forever to resize <Ubuntu Image:Fix Committed by vorlon> <https://launchpad.net/bugs/1627146>
[16:16] <qengho> I sure wish something would warn me that my snap has a vulnerability in OpenSSL that was fixed today.
[16:18] <qengho> My snap was uploaded from a recipe in Launchpad. It could fire off builders, and then email me a link to upload the builder results to Edge channel, and another to upload to Stable channel.
[16:20] <qengho> I wonder how hard it would be to write a snap scanner that looked for patterns that suggest a vulnerable version of dependency. Like a virus-scanner pattern searcher.
[16:25] <slangasek> ogra_: yep - sorry, didn't get it fixed over the weekend because of final beta trubs, but will get that sorted today
[16:25] <ogra_> no hurry ... i run my own ubuntu-image meanwhile ...
[16:25]  * slangasek nods
[16:26] <ogra_> just wanted to make sure you didnt miss it
[16:31] <mup> PR snapd#1963 closed: daemon, overlord, store: add ReadyToBuy API to snapd <Reviewed> <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1963>
[17:31] <mup> PR snapd#1847 closed: many: discard preserved namespace after removing snap <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1847>
[17:55] <mup> PR snapcraft#829 opened: sources: fix type when calling with depth <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/829>
[18:10] <mup> PR snapcraft#830 opened: python plugin: only replace proper shebangs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/830>
[18:37] <mup> PR snapcraft#831 opened: 'sign-build' implementation <Created by cprov> <https://github.com/snapcore/snapcraft/pull/831>
[18:48] <mup> Bug #1627813 opened: AppArmor denies access to /etc/ld.so.preload on armhf <Snappy:New> <https://launchpad.net/bugs/1627813>
[18:56] <oparoz_> Is there an online interface for the snap store where we can find snaps? It seems each developer sees his own or we have to use snapweb which doesn't list everything
[19:01] <mup> PR snapcraft#795 closed: WIP: snap-build generation and pushing support <Created by caio1982> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/795>
[19:03] <kyrofa> ogra_, I'm confused. Why does this https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ recommend downloading ubuntu classic for rpi?
[19:30] <kyrofa> Right
[19:31] <ogra_> well, i think such pages should slowly start pointing to the betas ... i guess with the next beta release they might be good enough (the dailies have surely a lot bugs fixed now)
[20:01] <mup> PR snapcraft#830 closed: python plugin: only replace proper shebangs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/830>
[20:15] <mup> PR snapd#1922 closed: tests: use apt as compatible with trusty <Reviewed> <Created by vosst> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1922>
[20:28] <mup> PR snapcraft#828 closed: yaml xpath for errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/828>
[20:51] <Marcus> Hi
[20:52] <Guest8706> I just discovered Ubuntu Core, I would like to know which one is appropiate Ubuntu Core/Desktop/Server?
[20:52] <Guest8706> I want to program soft real time application using boost library
[20:52] <kyrofa> Guest8706, on what hardware will the program run?
[20:52] <Guest8706> anyone could help me? Thank you!
[20:53] <Guest8706> mini-PC
[20:53] <kyrofa> Guest8706, will it be headless? Or do you need a graphical interface?
[20:53] <Guest8706> industrial PC
[20:54] <Guest8706> for testing and validation ghapical interface would be useful but not main requirement
[20:54] <Guest8706> It would control cameras and laser, so sync is realy important
[20:55] <kyrofa> Guest8706, how do you envision updating it?
[20:55] <kyrofa> Guest8706, also, is this a one-off for your own use, or a product you intend on providing to others?
[20:56] <Guest8706> a product, for selling to another company
[20:56] <Guest8706> is a critical system, so we would not perform many updates
[20:58] <Guest8706> kyrofa, what do you recommend?
[20:59] <kyrofa> Guest8706, will it be connected to the internet?
[20:59] <Guest8706> VPN
[21:00] <kyrofa> Guest8706, what I'm really asking it, say you DO need to update it. Will it be able to retrieve the update via the internet, or will the user need to sideload it somehow?
[21:00] <Guest8706> It would be installed outside and connected by fiber optic to the local network
[21:00] <Guest8706> second option I guess
[21:01] <kyrofa> Guest8706, and last question: you say soft real time, i.e. you don't expect a real-time kernel?
[21:01] <Guest8706> real time is desirable, but I think I would think LinutRT or similar, is that ok?
[21:02] <Guest8706> So I need to be able to control priorities of threads
[21:02] <Guest8706> and make sure main process run smoothly
[21:02] <Guest8706> but I think I dont need a RT OS
[21:04] <Guest8706> One of my doubts is, Would i be able to use the same libraries? i.e boost library
[21:04] <Guest8706> I mean when using Core version
[21:06] <kyrofa> Guest8706, oh sure, the only thing special about ubuntu core is that you'd be required to use snaps
[21:06] <kyrofa> Guest8706, are you familiar with snaps?
[21:06] <Guest8706> Not at all
[21:07] <kyrofa> Guest8706, they're a new packaging format that bundle their dependencies and are transactionally updated (i.e. can rollback upon failure)
[21:08] <kyrofa> Guest8706, they're also strictly confined, which means they're more secure, but can also cause some challenges when creating the snap if your software it used to being able to walk all over the system
[21:08] <Guest8706> So, it could be more challeging to set up the system?
[21:09] <kyrofa> Guest8706, it also automatically updates (including the snap you put on there for your stuff), but if the device isn't connected to the internet that's not much of a win
[21:10] <kyrofa> Guest8706, are you familiar with debian packaging?
[21:10] <Guest8706> yes
[21:10] <kyrofa> Guest8706, particularly considering that being able to login and have a GUI would be useful to you, you might consider simply using ubuntu desktop
[21:11] <kyrofa> Guest8706, if, however, security is important, you might consider ubuntu core
[21:11] <Guest8706> ok, thank you Kyrofa
[21:11] <kyrofa> But without the internet, some of the ubuntu core advantages are negated
[21:12] <Guest8706> security is important but the local network would be "protected" and traffic limited so I guess it would be OK
[21:13] <kyrofa> Note that, if you play with the snap packaging format and like it, ubuntu server, desktop, and core can all use it
[21:13] <kyrofa> (as well as various other linux distributions)
[21:14] <Guest8706> ok, where could i start?
[21:14] <kyrofa> Guest8706, right here: http://snapcraft.io/
[21:14] <Guest8706> I can create snaps and test them on Desktop?
[21:14] <kyrofa> Guest8706, indeed
[21:17] <Guest8706> I have been about 10 years without using Linux, I am getting old, everything seems more difficult now, :)
[21:17] <Guest8706> Thank you very much for your help.
[21:32] <kyrofa> Guest8706, of course!
[21:35] <mup> PR snapd#1995 closed: interfaces/builtin: fix resolvconf permissions for network-manager interface <Critical> <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1995>
[21:36] <mup> PR snapd#1997 closed: tests: added install_local function <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1997>
[21:37] <mup> PR snapd#1998 closed: debian: re-add golang-github-gosexy-gettext-dev  <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1998>
[21:40] <mup> PR snapcraft#829 closed: sources: fix type when calling with depth <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/829>
[21:41] <andywork> i am using the dump plugin to copy something into my snap; i set the source property (which must be a directory), but how do I set what files to be dumped? currently all files in that source directory is being copied into the snap
[21:41] <andywork> (which I do not want)
[21:43] <kyrofa> andywork, that's how the dump plugin works-- it dumps everything in the directory into the snap. If you want to blacklist things, you can use the `stage` and `snap` keywords in the YAML
[21:44] <kyrofa> (or whitelist)
[21:46] <sergiusens> andyrock like in the `assets` part here https://github.com/snapcore/snapcraft/blob/master/demos/gopaste/snapcraft.yaml#L20
[21:46] <ogra_> kyrofa, do you know whats the reason for this horrid complexity (vs having the simple copy plugin syntax we had before)
[21:47]  * ogra_ never understood what was wrong with the copy plugin or why we had to drop it
[21:51] <andywork> kyrofta, sergiusens: thanks, I'll take a look
[22:01] <mup> Bug #1627860 opened: run fail at missing folder /lib/modules (eg. on a virtual host) <Snappy:New> <https://launchpad.net/bugs/1627860>
[22:16] <mup> PR snapcraft#810 closed: nodejs plugin: Add mechanism to run “npm run” commands <Created by RAOF> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/810>
[22:33] <mup> PR snapd#1999 closed: daemon: add REST API behind `snap get` <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1999>
[23:05] <mup> PR snapd#1996 closed: daemon: add the actual ssh keys that got added to the create-user response <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1996>
[23:40] <mup> Bug #1627893 opened: A daemon is denied to write to the home directory <Snappy:New> <https://launchpad.net/bugs/1627893>
[23:43] <mup> PR snapd#2000 opened: snap, daemon, store: pass through screenshots from store <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2000>