[15:11] <fujisan> i only know the date on which it occured i don't know if the channel was logged only log i have of it is in comic chat unfortunately
[15:11] <fujisan> @ LjL
[15:12] <fujisan> if it's a big issue with comic chat logs i will just file a complaint with the anti-discrimination authorities
[15:12] <fujisan> i should have done it straight away
[15:12] <LjL> fujisan: please tell your story from the beginning. i'm not in the IRC Council myself, but the IRC Council will see this (this channel is logged). you may want to take some time to get your logs together. #ubuntu-nl is, i believe, also publicly logged.
[15:12] <LjL> !logs
[15:12] <fujisan> this happened in ubuntu-nl-offtopic which isn't logged unfortunately
[15:13] <fujisan> i am not disputing my ban there btw
[15:13] <fujisan> just this incidence
[15:13] <fujisan> the ban is a result of them hating me for taking racism serious
[15:14] <fujisan> it's all a big joke to them alas and i want to send a message
[15:14] <fujisan> that there is zero tolerance for racism
[15:15] <fujisan> incident*
[15:17] <fujisan> http://imgur.com/dOl1x << this is all i have of it no official looking log unfortunately
[15:17] <fujisan> i can translate what he said
[15:21] <fujisan> it's about the city of Rotterdam in the Netherlands, and many black people, and people of other cultures, and races live there.So he says:" I am afraid to go to Rotterdam with my car", and then the other guy asked: "Why did you go there?" and then the guy says: "Watching Monkeys." and then the other guy says: "Did you laugh at them." and then the other guy says: "I am careful not too they were carrying so many knifes in their pockets the
[15:22] <fujisan> that's basically it i am not an official translator
[15:22] <fujisan> but i think this is pure racism and uncalled for
[15:22] <fujisan> and it's all a big joke to them
[15:23] <fujisan> that's the worst part
[15:25] <fujisan> and the admin JanC he didn't flinge or nothing
[15:25] <fujisan> and he left when he saw i came in
[15:25] <popey> he pung out
[15:25] <fujisan> ye afterwards i was so angry that i couldnt behave normal anymore in their
[15:25] <fujisan> there*
[15:26] <fujisan> and i have a bad history of being a troll but i am in therapy and doing better and was getting along fine in there and then this happened
[15:26] <fujisan> but if you guys dont take it serious i can understand i will go to the authorities
[15:28] <fujisan> the admin banned me cause i was using someone elses 2nd nick btw the guy who made the comments i was seeking for my own justice i guess
[15:28] <fujisan> but the admin is really to blame here for doing nothing about it
[15:29] <fujisan> i asked him when this happened to ban me for life because the way they all saw this was like some big joke
[15:30] <fujisan> and being light brown myself i know what racism feels like so i had to speak out against it
[15:30] <fujisan> maybe too little to late
[15:32] <fujisan> i always felt safe from racism in the ubuntu channels but now not anymore i will just stick to the macosx channel where i never ever experienced racism
[15:33] <fujisan> thanks for letting me tell the story
[15:33] <fujisan> i hope you guys will take this serious
[15:33] <fujisan> and not like some joke because i am dead serious
[15:36] <fujisan> bu bye
[17:49] <JanC> ah, fujisan has been spamming here too...  :P
[17:49] <Pici> Yeah.
[17:53] <JanC> he has been spamming some #ubuntu-nl* regulars too  :-(
[17:53] <Pici> Any truth to his claims?
[17:56] <JanC> somebody said something he claims was racist, but IIRC it was just something he misunderstood
[17:58] <JanC> in any case, he has been banned for repeated trolling, ban evading, insulting people and a number of other things
[17:59] <JanC> and this is about the 50th time he got banned for all those  ;)
[17:59] <jussi> JanC: sounds similar to the story in other ubuntu channels.
[19:27] <ubot4> In #ubuntu-bugs, Fvic said: ubot4, yes the bug is same.i read theory.but havenot actually triaged any bug.can you please help me to start.?
[21:19] <fujisan> oops now you know my real identity :)
[21:20] <fujisan> thanks again folks
[21:20] <fujisan> i had a good day today after i got it of my chest
[21:20] <fujisan> :)
[22:33] <hypatia> glad to hear, fujisan
[22:33]  * hypatia offers tea and cupcakes
[22:36] <fujisan> :) thanks
[23:35] <Logan_> rww: I would recommend removing Guarddog from !firewall because it doesn't exist in the repo for natty
[23:36] <rww> !-firewall
[23:36] <rww> !firewall =~ s/or Guarddog \(KDE\) /
[23:36] <rww> !firewall =~ s/or Guarddog \(KDE\) //
[23:36] <rww> !firewall
[23:36] <Logan_> thanks :)
[23:36] <rww> !firewall =~ s/Gnome/GNOME/


[00:06] <falktx_> download complete!
[00:06] <falktx_> woot
[00:29] <falktx> video meta install fails :(
[00:30] <falktx> some ffmpeg and other lib errors
[00:30] <falktx> ubuntu's fault there, not US though
[00:31] <falktx> normal desktop fails too
[00:31] <falktx> we're depending on tango-icon-theme-common, which apparently doesn't exist anymore?
[01:30] <holstein> ScottL: we need the images built?
[01:31] <holstein> they are asking in -release...
[01:31] <holstein> not sure if thats what we need
[01:41] <ScottL> holstein, i'm not sure because charlie-tca already asked about the images to be rebuilt and i thought there were already
[01:42] <holstein> ScottL: i just say skaet asking
[01:42] <holstein> and wanted to be sure
[01:43] <ScottL> reading backscroll in -release now
[01:45] <ScottL> thanks holstein , skaet will have the images rebuilt now :)
[01:46] <holstein> :)
[01:46] <ScottL> falktx__, thanks for doing all that work to fix things earlier, i'm glad to see you and astraljava moving and shaking things up :)
[01:47] <falktx__> well, ScottL, I know you're a bit busy, so I went through with it
[01:47] <falktx__> oh, I wasn't able to install the latest image
[01:48] <falktx__> we're depending on tango-icon-theme-common, which apparently doesn't exist anymore?
[01:48] <falktx__> ScottL: ^
[01:52] <ScottL> falktx__, really?  that's interesting (that's it doesn't exist)
[01:52] <ScottL> i had recently updated the language packs shipped because _many_ of them don't existing anymore as well
[01:53] <ScottL> sounds like we have other areas that need clean up as well
[01:53] <falktx__> yep
[01:54] <falktx__> ScottL: we should investigate a bit though, cause tango is used by us icon theme
[01:55] <ScottL> falktx__, i found this though:  https://launchpad.net/ubuntu/+source/tango-icon-theme-common/0.7-0ubuntu1
[01:55] <ScottL> it looks like it is built for oneiric, just the source appears to be from feisty perhaps
[01:56] <falktx__> ScottL: you're right
[01:57] <falktx__> but somehow tango-icon-theme-common was marked as "not installable"
[01:57] <ScottL> the repos are flaky right now :/
[01:57] <falktx__> hm, it's installed on my system...
[01:57] <falktx__> ScottL: that is bad for testing images
[01:57] <ScottL> yes it is
[01:58] <falktx__> I don't remember having a single 11.10 US good image
[01:58] <falktx__> :(
[01:59] <falktx__> but now it's ubuntu's fault
[01:59] <charlie-tca> yup
[01:59] <charlie-tca> that tango-icon-theme was one of the fails earlier, when I asked for the re-spin it got fixed
[01:59] <ScottL> aye...we didn't due to much to make the transition to xfce so shame on us then, but man!, the repos are making it real hard to do anything now
[02:01] <holstein> w0w
[02:01] <holstein> i feel like we might make it :)
[02:03] <ScottL> holstein, if the repos get sorted and things built correctly ;)
[02:05] <falktx__> I believe US can get it right for 11.10
[02:06] <charlie-tca> by the way, this latest re-spin is for the parted errors when installing on mac systems. I don't think it is in the image yet.
[02:07] <charlie-tca> There is an advantage to Ubuntustudio doing the re-spin; that menu should go into it too
[02:44] <ScottL> i'm unsure how to take this:  https://bugs.launchpad.net/ubuntu-branding/+bug/838513
[02:44] <ScottL> apparently someone filed a bug against my "head shot" (which is a ubuntu studio logo i made) for the planet ubuntu page
[02:45] <holstein> mark it
[02:45] <holstein> mark it 8 dude
[02:46] <holstein> hey... i can mark it :)
[02:46] <holstein> ScottL: i'll comment that the logo is your peronal logo
[02:46] <holstein> ScottL: unless you are already doing that
[02:47] <ScottL> holstein, nah, i'm still scratching my head...go ahead :)
[02:49] <holstein> done
[02:53] <charlie-tca> new images are posted
[02:55]  * ScottL was doing the last dog walking for tonight
[02:55] <ScottL> holstein, i suppose it would be different perhaps if that planet ubuntu post was labeled as "ubuntu studio" instead of "scott lavender" ;)
[02:56] <holstein> ScottL: yeah... its an odd bug to *not* come and ask you about
[02:57] <ScottL> hehe, i appreciate that he is filing bugs though :-)
[02:57] <holstein> yeah... seems like a nice enough guy
[02:57] <holstein> prolly just on some theme team
[02:58] <holstein> yeah... ubuntu-branding
[03:27] <charlie-tca> astraljava: note comment on Bug 838434
[03:27] <charlie-tca> Good to go now!
[06:57] <astraljava> charlie-tca: Yea, noticed. Weird, cause I was notified a little differently elsewhere, but suits me fine.
[14:17] <astraljava> All amd64 tests done, will do i386 during the evening.
[14:21] <falktx> astraljava: are the images installable now?
[14:25] <scott-work> astraljava: awesome!
[14:25] <scott-work> i've downloaded the i386 image and can start testing this afternoon
[14:54] <astraljava> falktx: The amd64 one is for me, anyway. I could finish all the cases required in the tracker.
[14:55] <astraljava> Will just now start the i386 tests.
[14:56] <falktx> nice
[16:41] <astraljava> Okay, all tests done successfully.
[16:41] <astraljava> We're good to go.
[18:13] <scott-work> astraljava: did falktk's menu update make it into the image?
[18:13] <astraljava> Not yet.
[18:14] <scott-work> ah, okay
[18:14] <scott-work> i'm guessing we will be able to test this in a few days with a daily image
[18:14] <scott-work> i wonder if we need to update the meta packages lately as well, i don't know when the last time we update
[18:15] <astraljava> I don't think so, there's no new packages or anything.


[03:51] <entropico> Hi I am not the smartest guy in the world using linux and I am currently in China, so far, and with a different time zone, from friends that can support. I have a NAS (HP-NL54) that run on Xubuntu. Upgrading from 14 to 16.04 release there was a problem on the boot. I tried to use Repair Boot Disk  and this was the result: http://paste.ubuntu.com/23560391/ . Now the system does not boot and Repair Boot Disk cannot repair any furthe
[06:05] <AaronRaimist[m]> entropico: I don't think I can help you but you should create forum post on the Ubuntu Forums as described here: https://ubuntuforums.org/showthread.php?p=10871917#post10871917 More people will be able to assist you there.
[13:52] <cmb_> Has the behaviour of the middle mouse button changed recently? Up till yesterday I could double click with left mouse button to select some text, and paste it into another window by clicking once on the middle mouse button/wheel. Turned on the machine today and even 'xev' is not showing anything X events when I click the wheel. Driver change? Window manager change? Annoying!
[13:53] <cmb_> Mouse is a Microsoft Wireless Mouse 2000.
[13:53] <cmb_> I did install some updates, including latest kernel, late yesterday... connected?
[13:55] <cmb_> (Kernel is Linux 4.4.0-51-generic #72-Ubuntu SMP, on 16.04.1 LTS)
[14:44] <flocculant> cmb_: not seeing the same issue in updated 16.04 - maybe try another mouse?
[17:27] <cmb_> flocculant, thanks, will dig one out and have a compare.
[17:38] <LambdaComplex> Where can I find a list of what's installed on the images at https://xubuntu.org/getxubuntu/ ?
[17:39] <flocculant> LambdaComplex: go to one of the mirrors - find the release you're looking at - then check the manifest
[17:41] <flocculant> cmb_: though I don't have a wireless mouse here, so maybe something changed, if it did then it would have been a change in something *not* xubuntu - and you might be better asking in #ubuntu
[17:43] <xangua> Well now LibreOffice is included in xubuntu for example
[18:35] <GridCube> LambdaComplex: http://packages.ubuntu.com/yakkety/xubuntu-desktop
[18:53] <LambdaComplex> thanks, flocculant and GridCube
[19:52] <glitchd> how can i log into a machine and pass the login screen (lightdm) on a machine the has no physical keyboard, but i have ssh access to?
[19:59] <ikonia> glitchd: please stop cross-pasting
[19:59] <ikonia> you've used these channels enough to know that is not acceptable
[20:03] <cmb_> flocculant, I was asking here first because I wanted to rule out it being a UI/xfce issue rather than a Unity issue, which will be the first question asked over on #ubuntu...
[20:06] <flocculant> cmb_: yea understood
[20:06] <cmb_> flocculant, thanks for try a different mouse suggestion - another Microsoft Wireless mouse I have lying around works just fine... so may be the specific device/hardware. Looks like the software side hasn't changed.
[20:07] <flocculant> cool - if in doubt dig the old hardware out and check that :)
[20:13] <glitchd> ikonia, there is no rule about asking questions in different channels, even if it is the same question.
[20:13] <ikonia> glitchd: there is
[20:14] <ikonia> glitchd: it's called cross-posting, please don't do it
[20:16] <gr1dl0ck> glitchd: why not just ssh? What are you trying to do?
[20:17] <ikonia> it's a nonsense requirement list
[20:17] <gr1dl0ck> oh ok
[20:27] <glitchd> ikonia, its not nonsense. you just dont want to help me find an answer.
[20:30] <glitchd> maybe its above your pay grade, maybe not. nonetheless dont try to hamper my attempts at finding an answer just because you cant help.
[20:30] <glitchd> gr1dl0ck, still care to hear what im trying to achieve?
[20:33] <ikonia> glitchd: I've just put a lot of options for you
[20:33] <ikonia> glitchd: so it's a bit of a stupid thing to say I don't want to help you find an answer
[20:33] <ikonia> but your use case is nonsense, hence why I said, it's nonsense requirements
[20:33] <ikonia> but I've offered you 7 - 8 options to give you a solution, so please, don't make it sound like I'm not interested
[20:34] <ikonia> and don't try to be smart with me "above my pay grade"
[20:34] <glitchd> ikonia, yes, you did put out alot of options, however none of them were acceptable to my situation.
[20:34] <ikonia> you're the one asking for help - so have a bit of appreciation for those trying to guide you and help you
[20:34] <ikonia> none of them are acceptable because your requirements is a nonsense usecase
[20:34] <ikonia> with minor tweaks you'd be fine
[20:35] <glitchd> ikonia, i have show appreciation for the effort just to be told not to ask in differnt forums
[20:35] <ikonia> so again, you've just said I offered you a lot of options, yet a few lines up you said I didn't want to help you
[20:35] <ikonia> glitchd: yes, you where told not to cross-post, thats not showing appreciation
[20:35] <ikonia> thats just asking in multiple channels
[20:35] <ikonia> showing appreciation is not calling someone for trying to help and guide you and coming out with stupid sentences like "it's above your paygrade"
[20:36] <ikonia> more so when you say a few lines later "you offered lots of suggestions" and contridict yourselfd
[20:36] <ikonia> again, a few minor tweaks to your usecase and you'll be setup and running in minutes
[20:36] <glitchd> pretty sure i havent contradicted myself, but im not gonna sit here and split hairs with you.
[20:37] <ikonia> you said I didn't want to help you
[20:37] <ikonia> then you said I offered you lots of suggestions
[20:37] <ikonia> that seems pretty contradicatry
[20:40] <glitchd> yes i did say you didnt want to help, i guess that was a mistake on my part, my apologies for that.


[01:10] <titan_king> Hello, anybody tried installing snappy in Fedora?
[01:12] <titan_king> The copr repo for feodra , Zyngacore/snapcraft does not work
[04:58] <Rumple> What's the deal with --classic snaps on the stable branch? Is there any other way to access /sys/ without --classic?
[07:11] <titan_king2> Does snapcraft support Fedora?
[07:12] <titan_king2> The copr seems to be down
[08:01] <pshod> http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
[08:01] <pshod> used the pi3 image from here
[08:01] <pshod> cannot get the bluetooth to work
[08:02] <pshod> help help help!
[08:10] <pshod> bluetotooth service not found
[08:10] <pshod> when ran systemctl bluetooth status
[08:10] <mup> PR snapd#2975 closed: overlord/snapstate: small cleanup of ensureForceDevmodeDropsDevmodeFromState <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2975>
[09:26] <mup> PR snapd#2951 closed: interfaces: use seccomp specs <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2951>
[09:35] <pshod> running core on pi3
[09:35] <pshod> unable to get the bluetooth working
[09:35] <pshod> http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
[09:35] <pshod> using the img from here.
[09:35] <pshod> help!
[09:55] <soffokl_> Hello everyone. Can someone point me to the description of installation Ubuntu Core on Google Compute Engine?
[09:56] <soffokl_> Is it really possible to make such installation?
[09:57] <soffokl_> On AWS EC2 found image ubuntu-core16, but failed to find something similar on GCE :(
[10:05] <mup> PR snapd#2984 opened: interfaces: seccomp test helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/2984>
[10:19] <pshod> how to load a service in core env?
[10:19] <pshod> installed classic env in it
[10:19] <kalikiana_> soffokl_: Unfortunately the instructions that existed seem to have disappeared from the snappy websites. But you can use a custom image.
[10:20] <kalikiana_> (There was https://www.ubuntu.com/desktop/snappy#snappy-google in a previous iteration)
[11:28] <pshod> NEED TO MAKE BLUETOOTH WORK ON CORE NOW!
[11:28] <pshod> help help help!
[11:31] <mup> PR snapd#2985 opened: hookstate: disable configure hook for core on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/2985>
[12:03] <caribou> Hello, what is the best approach to copy a file from the parts/{part}/build directory to the parts/{part}/install directory using an install scriptlet ?
[12:04] <caribou> I wanted to use the $SNAPCRAFT_PART_INSTALL as a target but I can't figure out if there is the equivalent source environment variable
[12:21] <caribou> nevermind, found it
[13:01] <popey> caribou: i use "cp -a * $SNAPCRAFT_PART_INSTALL" in my scriptlet, what did you decide on?
[13:16] <Son_Goku> is zyga back from the grave yet?
[13:17] <Son_Goku> mvo: hey, the 2.23 release tag doesn't match what you did last week
[13:17] <Son_Goku> it's way older
[13:26] <cachio> jdstrand, hi
[13:30] <Son_Goku> mvo: please fix, because there's tons of stuff missing in the 2.23 download I get from GitHub :(
[13:31] <mvo> Son_Goku: in a meeting right now, but what is going wrong?
[13:31] <Son_Goku> mvo: the 2.23 tag published on GitHub is invalid
[13:31] <mvo> Son_Goku: I check in a little bit
[13:31] <Son_Goku> it's over two weeks old
[13:31] <Son_Goku> whereas you just committed 2.23 a few days ago
[13:32] <Son_Goku> so things like my SELinux policy and whatnot are missing
[13:32] <mvo> Son_Goku: yes, definitely wrong, sorry for that, let me fix
[13:32] <Son_Goku> as well as all of zyga's merged fixes for CentOS/Fedora
[13:34] <mvo> Son_Goku: sorry for that! please checkout 2.23 again
[13:36] <Son_Goku> mvo: yay, thanks
[13:36] <Son_Goku> looks right now
[13:36] <Son_Goku> mvo: is the vendored tarball supposed to have an inner directory "snappy.upstream"?
[13:36] <Son_Goku> I would have figured it'd be snapd-2.23
[13:37] <mvo> Son_Goku: yeah, its an artifcat of the way dpkg-buildpackage did it, I really should fix that, can do after the meeting :)
[13:37] <Son_Goku> mvo: do you know when zyga will get back?
[13:38] <mvo> Son_Goku: I think 2 more days
[13:38] <Son_Goku> okay, thanks
[13:38] <Rumple> What's the deal with --classic snaps on the stable branch? Is there any other way to access /sys/ without --classic?
[13:44] <didrocks> cjwatson: hey! it seems that all my npm install --global are failing in launchpad (while they do pass on my machine). Can be that I have some in a local cache, but I don't know if there can be some proxy issue IS-side. (https://launchpadlibrarian.net/309867959/buildlog_snap_ubuntu_xenial_amd64_chuck-norris-webserver_BUILDING.txt.gz) (Note that the same package did build successfully on the 27th FYI)
[13:45] <cjwatson> (the snap proxy isn't IS-side)
[13:46] <didrocks> ah ok :)
[13:46] <cjwatson> didrocks: I dunno, a chmod ENOENT doesn't seem very snap proxy-ish, and it does manage to download other files
[13:46] <cjwatson> have you tried snapcraft cleanbuild?
[13:47] <didrocks> cjwatson: sorry, yeah, I didn't scroll high enough, I was stuck in the "npm install"
[13:47] <didrocks> cjwatson: it's probably my side, need to try in cleanbuild, I always forget about this option as my lxd container was broken for a while. Sorry to have bothered you :)
[13:48] <cjwatson> np - let me know if you still can't get it to work, but it looks more likely to be a bug in the package's build system to me
[13:49] <didrocks> cjwatson: agreed
[13:53] <mvo> Son_Goku: should be fixed now
[14:06] <jdstrand> cachio: hey
[14:07] <cachio> jdstrand, I was creating some performance tests for dbus
[14:07] <cachio> jdstrand, trying to validate dbus performance, then I found something interesting
[14:08] <cachio> jdstrand, I created some scripts in python and one snap which is running these scripts
[14:08] <cachio> when I run the python scripts I get about 50% more of performance compared with the snap execution
[14:09] <cachio> both are executing the same scripts
[14:09] <Son_Goku> mvo: much better :D
[14:09] <jdstrand> cachio: this is testing the performance of starting a script?
[14:10] <cachio> jdstrand, no, it is measuring the bandwidth when I sent 20k signals
[14:11] <cachio> jdstrand, I is creating a client and a server and the client is creating the signals and the server is counting all the signals that are arriving to the specific address
[14:11] <jdstrand> cachio: did you factor out the startup cost of starting the snap command?
[14:12] <cachio> jdstrand, no, how can I do that?
[14:13] <cachio> I am not sure if I should
[14:13] <cachio> because the test start when the first message arrives to the server
[14:14] <cachio> the server is getting metrics from the first message to the last
[14:15] <caribou> popey: well, I just realized that the file I had to copy was in the . directory so cp sos.conf $SNAPCRAFT_PART_INSTALL/etc did the trick
[14:15] <jdstrand> cachio: I'm asking all this for two reasons. 1) tyhicks did extensive testing of dbus performance with the apparmor patches and found performed extremely well for normal and beyond use cases and 2) launching a snap command is not lightwight-- there is ipc to snapd involved, an exec(), reading several files, setting up a seccomp filter, setting up namespaces, etc, etc, then another exec()
[14:16] <jdstrand> cachio: ok, so if the test is first message to last, that should be ok. if it includes time to get to first message, then it is measuring too much
[14:17] <jdstrand> cachio: I don't know your test, but if it is waiting for the first message and that appears in the results, a simple way to adjust that would be to starting your timing on the 2nd message
[14:18] <jdstrand> cachio: and to be clear-- your test is a) start command b) send messages c) stop command and *not* a) start command b) send message c) stop command d) goto 'a'
[14:19] <cachio> jdstrand, the tests are:
[14:20] <mup> Bug #1670371 opened: Configure hook breaks content interface plug <Snappy:New> <https://launchpad.net/bugs/1670371>
[14:20] <cachio> 1- start command  in parallel(2- spammer will send x signals 3- handler will receive those signals and report metrics) 3- stop command
[14:21] <cachio> jdstrand, so the start should not interfere in the tests results
[14:23] <caribou> oops, I think I may have run into a bug with the --classic confinement :
[14:23] <jdstrand> cachio: to be 100% sure, we can avoid the launcher and isolate apparmor
[14:23] <caribou> if I run the cmd, it appends the same argument over and over (see http://pastebin.ubuntu.com/24124987/)
[14:24] <caribou> I don't get that in --devmode
[14:24] <jdstrand> cachio: you can do: aa-exec <name of profile> -- /path/to/script <args>
[14:24] <cachio> jdstrand, sure
[14:24] <jdstrand> cachio: aa-exec is sufficiently lightweight to not skew the results. <name of profile> would be snap.name.command
[14:25] <caribou> could be tied to a denied AppArmor profile request to rw on /dev/tty
[14:25] <jdstrand> cachio: and also to be 100% clear-- you comparisons are all on the same machine, correct?
[14:26] <cachio> jdstrand, yes
[14:26] <cachio> real hardware
[14:27] <jdstrand> caribou: the /dev/tty denial is likely harmless, but you can add '/dev/tty rw,' to /var/lib/snapd/apparmor/profiles/nap.your.profile and reload with 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/nap.your.profile'
[14:27] <jdstrand> er, snap.your.profile
[14:28] <caribou> jdstrand: yeah, was reading on of your comment on a previous bug
[14:28] <caribou> jdstrand: so might not be tied to the CLI option repeating itself forever like the pastebin shows
[14:28] <caribou> jdstrand: let me try that first
[14:29] <jdstrand> caribou: it wouldn't be impossible that it is tied to it, would just be surprised
[14:30] <caribou> jdstrand: looks quite similar to LP: #1664427
[14:30] <mup> Bug #1664427: thefuck snap gets an apparmor denial even in classic confinement <classic> <Snappy:Incomplete> <https://launchpad.net/bugs/1664427>
[14:31] <jdstrand> cachio: fyi, the tests tyhicks did were several years ago, and it was a similar test iirc (he would have the details)-- thousands and thousands in a short time span. iirc it was around 1% overhead, but I could be making that up
[14:34] <caribou> jdstrand: well, it's the snap-confine profile that rejects it
[14:34] <jdstrand> caribou: ah, well, then yes, add it there
[14:35] <jdstrand> caribou: but, are you running from your snap a command in /snap/bin?
[14:35] <jdstrand> caribou: cause that is allowed in classic but not devmode or strict
[14:36] <jdstrand> caribou: I also think that is the problem in bug #1664427
[14:36] <mup> Bug #1664427: thefuck snap gets an apparmor denial even in classic confinement <classic> <Snappy:Incomplete> <https://launchpad.net/bugs/1664427>
[14:36] <caribou> jdstrand: well, that's a python script I just invoke it as "command: sosreport"
[14:37] <caribou> jdstrand: and that's the classic mode that is failing, not devmode
[14:39] <mup> PR snapd#2986 opened: tests: specify the core version to be unsquashfs'ed in the failover tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2986>
[14:39] <jdstrand> oh right, 1664427 was also with classic. any way, feel free to add that rule to /etc/apparmor.d/usr.lib.snapd.snap-confine. I suspect it won't fix the issue
[14:43] <cachio> jdstrand, http://paste.ubuntu.com/24125055/
[14:44] <cachio> jdstrand, I ran in my machine the tests, using aa-exec, running the snap command and running python
[14:45] <cachio> I see like a 20% of difference if yo usee the metric 'messages_sec'
[14:46] <caribou> jdstrand: you're right, has nothing to do with it
[14:47] <jdstrand> cachio: at this point I'm going to point you at tyhicks for historical context. he may bounce it back to me
[14:47] <jdstrand> cachio: he should be online in a few minutes
[14:51] <cachio> jdstrand, sure, tx
[14:55] <popey> jdstrand: you just rejected my ffscreencast snap - can I point you to https://bugs.launchpad.net/snapcraft/+bug/1670162 ? I don't believe it needs a .desktop file.
[14:55] <mup> Bug #1670162: publish complains about desktop file un-necessarily <Canonical Click Reviewers tools:New> <Snapcraft:Triaged> <Software Center Agent:New> <https://launchpad.net/bugs/1670162>
[14:56] <jdstrand> popey: if it is a cli tool, why does it need x11?
[14:57] <popey> jdstrand: it's a screen capture tool.
[14:57] <popey> uses x11 utils etc
[14:59] <cjwatson> kyrofa: snap proxy timeout is now two hours rather than one
[15:03] <mup> PR snapd#2592 closed: many: add support for session dbus services via snaps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2592>
[15:04] <jdstrand> popey: can you request for manual review?
[15:05] <mup> Bug #1670384 opened: refresh to same revision yields broken SNAP_USER_DIR <Snappy:New> <https://launchpad.net/bugs/1670384>
[15:12] <popey> jdstrand: done
[15:16] <mup> PR snapd#2987 opened: store: download from authenticated URL if there is a device session set <Created by matiasb> <https://github.com/snapcore/snapd/pull/2987>
[15:29] <mup> Bug #1670397 opened: On Debian Stretch (9) /snap/bin is not added to path <Snappy:New> <https://launchpad.net/bugs/1670397>
[15:33] <popey> thanks jdstrand
[15:52] <tyhicks> hi cachio
[15:52] <tyhicks> cachio: I'm not sure if I still have my old performance testing data
[15:53] <jdstrand> pmcgowan: hey, do you have a branch with snapcraft.yaml for your webdemo snap?
[15:53] <tyhicks> cachio: what does messages_sec represent?
[15:54] <pmcgowan> jdstrand, I do, I havent pushed the latest but could
[15:54] <pmcgowan> jdstrand, which bug you interested in
[15:55] <mup> PR snapd#2980 closed: client, daemon: move "snap list" name filtering into snapd <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2980>
[15:56] <barry> i'm trying to build a snap out of only ubuntu packages (mostly a custom command around nmap).  i'm running into trouble with missing shared libraries.  is there some snapcraft plugin that would automatically include dependent libraries or do i have to code that up myself?  i was thinking an 'apt' plugin might be nice for use cases like that
[15:57] <jdstrand> pmcgowan: the denials included in bug #1667480
[15:57] <mup> Bug #1667480: browser-support needs to be an implicit interface, not implicit classic <snapd-interface> <snapd (Ubuntu):Fix Committed by jdstrand> <https://launchpad.net/bugs/1667480>
[15:58] <jdstrand> pmcgowan: I fixed all of those already, but then I was wanting to test on dragonboard and saw some other stuff I want to investigate
[15:58] <jdstrand> pmcgowan: I have r19 from the store
[15:59] <pmcgowan> ok the last branch is ok then, https://code.launchpad.net/~pat-mcgowan/+junk/webdemo
[15:59] <pmcgowan> jdstrand, ^
[16:00] <jdstrand> pmcgowan: thanks!
[16:14] <mup> Bug #1670397 changed: On Debian Stretch (9) /snap/bin is not added to path <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1670397>
[16:18] <tyhicks> cachio: I found my old benchmarks
[16:18] <tyhicks> cachio: they were done on a nexus 7 phone
[16:19] <tyhicks> cachio: at that time, the focus was click confinement and we expected that the common case would be a confined click application (client) talking to an unconfined trusted helper (daemon/service)
[16:19] <tyhicks> cachio: measured overhead using the dbus-ping-pong test was steady at about 10%
[16:20] <tyhicks> cachio: it sounds like you're confining both the client and the server in your benchmarks so that may explain the additional overhead
[16:21] <cachio> tyhicks, in some machines I got the 50% of overhead
[16:21] <cachio> tyhicks, i am not sure it is known
[16:22] <cachio> I mean, if this overhead is what you expect or it is so much
[16:23] <cachio> tyhicks, do you want to see the test code?
[16:23] <cachio> just to verify the tests are ok ¡
[16:23] <cachio> ifconfig
[16:24] <tyhicks> cachio: yes, please share the test code with me
[16:24] <tyhicks> cachio: 50% overhead should definitely not be happening
[16:25] <tyhicks> cachio: I landed that code years ago and haven't been involved since so something may have changed
[16:25] <cachio> tyhicks, http://paste.ubuntu.com/24125526/
[16:25] <cachio> I have a snap here
[16:25] <cachio> http://bazaar.launchpad.net/~sergio-j-cazzolato/ubuntu-performance-tests/trunk/files/head:/resources/apps/kpi-dbus-tests/
[16:25] <cachio> tyhicks, the snap uses these py files
[16:26] <cachio> tyhicks, the I run the tests running python3 <script> <params> and through the snap
[16:27] <cachio> if you want to install the snap it is stored in edge
[16:29] <tyhicks> cachio: thanks - I have to run off to a meeting now but will try take a closer look by tomorrow
[16:30] <cachio> tyhicks, sure
[16:30] <tyhicks> cachio: is this just something interesting that you noticed or is there a real world snap that is affected by the performance?
[16:32] <cachio> thibautr__, well I did similar tests for python code and external libraries, to see if the confinment was affecting its performance, and in that case the results are pretty similar running with and without confinment
[16:32] <cachio> tyhicks,  well I did similar tests for python code and external libraries, to see if the confinment was affecting its performance, and in that case the results are pretty similar running with and without confinment
[16:33] <timothy> hi, why did you MOVED a git tag? =.=
[16:33] <cachio> tyhicks, so I am trying to measure and detect where the performance is degraded
[16:35] <tyhicks> cachio: got it - I think you've narrowed in on it and, to some point, the degradation is expected
[16:35] <tyhicks> cachio: we just want to make sure that the degradation is still within the acceptable bounds
[16:36] <cachio> tyhicks, exactly
[16:36] <timothy> the "new" tag of release 2.23 is not releaseable on archlinux :(
[16:36] <timothy> since we don't have libcap static
[16:37] <timothy> neither fedora
[16:48] <BjornT> hi. could someone please unblock my snap bjornt-prometheus-node-exporter? it says it's pending review
[16:59] <kyrofa> timothy, that might be worth a mailing list post
[17:04] <mup> PR snapd#2988 opened: tests: do *not* nuke the entire /etc/systemd/system/snapd.conf.d dir when changing store settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/2988>
[17:37] <Pharaoh_Atem> timothy: the tag was a mistake and should have been deleted weeks ago
[17:37] <Pharaoh_Atem> it was just fixed this morning
[18:06] <mup> PR snapd#2988 closed: tests: do *not* nuke the entire /etc/systemd/system/snapd.conf.d dir when changing store settings <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2988>
[18:41] <cholcombe> so i'm building a Go snap for the first time and it's complaining about some package context stuff
[18:43] <cholcombe> http://paste.ubuntu.com/24126216/
[18:43] <cholcombe> i have no idea what i'm doing :) any help is appreciated
[18:53] <kyrofa> cholcombe, looks like it's coming from the vendored gorilla
[18:54] <kyrofa> cholcombe, are you using godep?
[18:55] <kyrofa> cholcombe, because it looks like it wants you to use a Makefile
[18:56] <kyrofa> cholcombe, maybe one of their standalone tarballs would be better: https://github.com/heketi/heketi/wiki/Standalone-Installation
[19:05] <cholcombe> kyrofa: hmm ok
[19:05] <cholcombe> yeah i saw that Makefile
[19:06] <cholcombe> they've got a dockerfile also that i can follow
[19:06] <cholcombe> kyrofa: no i wasn't using godep.  let me paste my snapcraft file
[19:07] <cholcombe> kyrofa: http://paste.ubuntu.com/24126310/
[19:07] <kyrofa> cholcombe, yeah I suggest you follow their README and wiki for installation guides
[19:08] <cholcombe> kyrofa: not a good candidate for a snap?
[19:08] <kyrofa> cholcombe, not necessarily, just saying you're not building it in a manner they suggest
[19:08] <cholcombe> sure
[19:09] <kyrofa> cholcombe, nowhere do they say `go get` will work
[19:09] <cholcombe> that's true
[19:09] <kyrofa> The fact that they use a Makefile typically implies to me that `go get` will _not_ work
[19:09] <cholcombe> the docker file does a go get it looks like
[19:09] <cholcombe> ok
[19:09] <cholcombe> kyrofa: https://hub.docker.com/r/heketi/heketi/~/dockerfile/
[19:10] <cholcombe> if i remember correctly this is just a gluster CLI wrapper
[19:10] <kyrofa> cholcombe, they're go-getting godep; they clone heketi
[19:10] <cholcombe> oh yeah i see it.  they call make
[19:11] <cholcombe> crap
[19:11] <kyrofa> cholcombe, welcome to go
[19:11]  * kyrofa runs
[19:11] <cholcombe> i heard it was a mess
[19:11] <kyrofa> Yeah, not my favorite
[19:12] <cholcombe> that reminds me.  i wonder if that snapcraft release has been made that allows you to install a snap to build a snap
[19:14] <jdstrand> ogra_: hey, so I installed 'classic' on the dragonboard, but apt-get update gives me: http://paste.ubuntu.com/24126359/
[19:15] <jdstrand> ogra_: apt-key and gnupg are present. I can kinda workaround this by using 'sudo apt-get -o APT::Sandbox::User=root ...' but that is icky. is this known?
[19:24] <kyrofa> jdstrand, what revision of the core snap was used when `sudo classic` was first run?
[19:24] <jdstrand> r397
[19:24] <jdstrand> that's too low
[19:24] <jdstrand> hmm
[19:25] <kyrofa> That seems super old...
[19:25] <kyrofa> 1337 is stable amd64, I'd expect a number closer to that
[19:25] <jdstrand> yeah. I though I snap refershed
[19:25] <jdstrand> thought*
[19:25] <jdstrand> $ sudo snap refresh
[19:25] <jdstrand> All snaps up to date.
[19:25] <kyrofa> ...
[19:26]  * kyrofa fires up my dragonboard
[19:26] <jdstrand> $ sudo snap refresh core --stable
[19:26] <jdstrand> that pulled down 1268
[19:26] <jdstrand> weird
[19:26] <kyrofa> Oh, dang. That seems like a bug
[19:27] <kyrofa> Unless you were on a channel that for some reason never was updated?
[19:28] <jdstrand> I just pulled it down from cdimage based on https://developer.ubuntu.com/core/get-started/dragonboard-410c
[19:28] <jdstrand> and it didn't update automatically
[19:29] <kyrofa> Huh... weird
[19:29] <jdstrand> indeed
[19:29] <kyrofa> That might be worth trying again
[19:29] <jdstrand> well, I'm updated now
[19:29] <kyrofa> Hahaha
[19:29] <kyrofa> I just mean to figure out if there's a bug there
[19:30] <kyrofa> If you have time
[19:30] <jdstrand> I've added a todo
[19:47] <jdstrand> kyrofa (cc ogra_): looks like if I upgrade the core snap, then install classic, then install classic from --edge, 'sudo apt-get update' still has an issue. I'll file a bug
[19:47] <kyrofa> jdstrand, after you updated the core snap, you removed the classic snap?
[19:48] <kyrofa> (and then re-installed it)
[19:48] <jdstrand> yep
[19:48] <jdstrand> and it unshashfs'd, etc
[19:48] <kyrofa> Yeah sounds like a bug then
[19:56] <jdstrand> kyrofa (cc ogra_): fyi, https://bugs.launchpad.net/snappy/+bug/1670475
[19:56] <mup> Bug #1670475: apt-secure complaints with classic snap <Snappy:New> <https://launchpad.net/bugs/1670475>
[19:58] <mup> Bug #1670475 opened: apt-secure complaints with classic snap <Snappy:New> <https://launchpad.net/bugs/1670475>
[21:16] <kyrofa> jdstrand, does snap-confine set things up such that the snap is mounted in /snap/<name>/<revision> even if in reality (e.g. fedora) it's not mounted there?
[21:16] <kyrofa> Wow that was a terribly-phrased question
[21:16] <kyrofa> jdstrand, I mean in the snap's execution context, does it appear there even if it isn't actually there on the host?
[21:18] <jdstrand> kyrofa: I've not played with fedora at all. my understanding is that the snap will see a consistent runtime. on fedora, you could install the hello-world snap then do 'hello-world.env|grep SNAP' and see what snapd is exporting
[21:18] <kyrofa> jdstrand, alright. I don't have an install handy, but perhaps Pharaoh_Atem is around?
[21:18] <Pharaoh_Atem> ?
[21:19] <kyrofa> Pharaoh_Atem, snapd doesn't actually mount snaps in /snap on fedora, right?
[21:19] <Pharaoh_Atem> absolutely not
[21:19] <Pharaoh_Atem> it better not
[21:19] <kyrofa> Pharaoh_Atem, does it appear like it from the snap's perspective?
[21:19] <Pharaoh_Atem> it should look like any other snap from the inside
[21:19] <kyrofa> Pharaoh_Atem, any chance you're in a position to install the `hello` snap and run the test jdstrand just suggested?
[21:20] <Pharaoh_Atem> with the latest snapd?
[21:20] <kyrofa> It doesn't have to be latest, but post November would be ideal
[21:21] <jdstrand> kyrofa: it looks like snap confine honors a configure option, SNAP_MOUNT_DIR and so it would *not* be /snap/foo/current/... but instead /wherever/it/is/on/fedora/snap/foo/current
[21:22] <Pharaoh_Atem> latest I've got is snapd 2.16 with snap-confine 1.0.44
[21:22] <Pharaoh_Atem> only started working on getting new snapd working today
[21:22] <Pharaoh_Atem> since mvo tagged it properly today
[21:22] <kyrofa> Pharaoh_Atem, good enough for me if you don't mind
[21:22] <Pharaoh_Atem> sure, give me a sec
[21:22]  * jdstrand isn't sure it is good enough, but I guess we'll see
[21:22] <jdstrand> 1.0.44 is Oct/Nov iirc
[21:23] <kyrofa> jdstrand, yeah that makes sense. I knew that it supported mounting in other areas, my real question is: what does that look like to the snap?
[21:25] <Son_Goku> jdstrand, kyrofa: what do you want me to do?
[21:26] <Son_Goku> I have my Fedora system with snapd 2.16 and snap-confine 1.0.44
[21:26] <kyrofa> Son_Goku, install the `hello` snap, and run `hello.env | grep SNAP` and pastebin the output
[21:27] <jdstrand> it looks like SNAP_MOUNT_DIR is only for finding the core snap. snap-confine builds up the runtime environment from the core snap. I see that it will mount on /snap in the runtime environment but that what is mounted is configrable based on SNAP_MOUNT_DIR
[21:28] <jdstrand> kyrofa: ^
[21:28] <jdstrand> we'll know if my quick read is correct soon enough :)
[21:28] <Son_Goku> hello.env doesn't exist?
[21:28] <Son_Goku> I see hello and hello.universe
[21:28] <kyrofa> Wha...
[21:29] <jdstrand> it's hello-world
[21:29] <kyrofa> jdstrand, oh darnit
[21:29] <kyrofa> Son_Goku, sorry, I lied
[21:29] <kyrofa> Son_Goku, try hello-world :P
[21:30] <Son_Goku> kyrofa, jdstrand: https://paste.fedoraproject.org/paste/idScR6VoZkXLzjq21KyatV5M1UNdIGYhyRLivL9gydE=
[21:31] <kyrofa> Son_Goku, thank you very much :)
[21:31] <Son_Goku> no problem
[21:31] <Son_Goku> also keep in mind that snapd and snap-confine are permanently in devmode
[21:31] <jdstrand> Son_Goku: that is with snap-confine 1.0.44 and snapd 2.16?
[21:31] <Son_Goku> yes
[21:32] <jdstrand> kyrofa: I think newer code will do something different
[21:32] <Son_Goku> sources here: http://pkgs.fedoraproject.org/cgit/rpms/snap-confine.git/tree/
[21:32] <kyrofa> jdstrand, what do you think... too old to be a valid test?
[21:32] <Son_Goku> http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/
[21:32] <kyrofa> jdstrand, fair enough
[21:32] <Son_Goku> well, I'm working on snapd 2.23
[21:32] <Son_Goku> without zyga, I have to kinda do it myself :/
[21:32] <kyrofa> Son_Goku, if you get that to a working point, I'd be curious to see the same test if you're able
[21:32] <Son_Goku> sure
[21:33] <jdstrand> kyrofa: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L356
[21:33] <Pharaoh_Atem> back to my workstation
[21:33] <kyrofa> jdstrand, indeed, that does look relevant
[22:05] <erimsa> Hello
[22:06] <kyrofa> Hello erimsa, welcome!
[22:07] <erimsa> I have lots of questions about snappy and ubuntu core
[22:08] <erimsa> but I think it is too new using for a commercial product
[22:08] <kyrofa> erimsa, please ask away :)
[22:08] <erimsa> thanks
[22:09] <erimsa> I want to use it for industrial batch controllers
[22:10] <erimsa> a headless system a webserver in
[22:10] <erimsa> it
[22:10] <kyrofa> Sure
[22:11] <erimsa> First, Can I create a snap package from existing executables ?
[22:11] <kyrofa> erimsa, definitely
[22:11] <kyrofa> erimsa, snaps are just squashfs images. They can contain whatever you like, organized however you like
[22:11] <erimsa> I couldnt find any documentation for that
[22:12] <erimsa> Ahh ok then
[22:12] <kyrofa> erimsa, do you have just a tarball or binaries/libraries, then?
[22:12] <erimsa> Yes, binaries
[22:13] <erimsa> I have to run Codesys "PLC runtime"
[22:13] <nacc> the dump plugin?
[22:13] <erimsa> in Ubuntu Core
[22:13] <erimsa> OK I see
[22:13] <nacc> erimsa: was just a thought, for copying binaries into the snap -- kyrofa knows way more than I :)
[22:14] <kyrofa> nacc, yeah I'm throwing a quick example together using just that
[22:14] <erimsa> You are saying use "dump plugin"
[22:14] <erimsa> for that
[22:14] <kyrofa> erimsa, yeah I'll show you
[22:14] <erimsa> OK Im waiting
[22:14] <nacc> erimsa: right, the 'dump' plugin takes a source (as defined in the snapcraft.yaml) and verbatim copies it into the snap squashfs
[22:15] <kyrofa> erimsa, take a look at this: http://pastebin.ubuntu.com/24127222/
[22:15] <kyrofa> erimsa, of specific note, the last four lines
[22:16] <kyrofa> erimsa, there you see `plugin: dump` as nacc is suggesting
[22:16] <kyrofa> erimsa, that will download the tarball (assuming it's a URL) and extract it into the snap
[22:16] <erimsa> Ok I will try it in a few days
[22:16] <erimsa> In beagle bone black
[22:16] <nacc> erimsa: and to be clear, that does assume the tarball's binaries have no dependencies themselves in the snap -- if they do, then you need to have those specified in your snapcraft.yaml
[22:16] <kyrofa> erimsa, you need a little more metadata there to actually expose a binary to be callable (add the `apps` section that you'll see in the docs/tutorials)
[22:17] <kyrofa> nacc, good catch
[22:17] <erimsa> I think I getting to close to understand
[22:17] <erimsa> Im
[22:17] <kyrofa> erimsa, if for example your tarball depends on some debian packages, you can add them there using `stage-packages` (which you'll also see in the docs/tutorials)
[22:18] <erimsa> Can you send me link for that tutorials ?
[22:18] <erimsa> There are lots web page
[22:18] <erimsa> s
[22:18] <nacc> http://snapcraft.io/
[22:18] <nacc> probably docs -> build snaps
[22:19] <erimsa> Second Question
[22:19] <erimsa> We need our own Custom Store
[22:20] <erimsa> for snap packages
[22:20] <erimsa> Is that possible ?
[22:21] <kyrofa> erimsa, there are a few possibilities for that. Can you explain what you're trying to accomplish with that? Or just a "we want it under our own roof" type of thing?
[22:24] <erimsa> Im working for a company that produces industrial controllers for food,chemisty,textile industries
[22:24] <erimsa> And using Debian Linux as OS for devies
[22:25] <erimsa> We have really problems with package versioning and installing in fields
[22:25] <erimsa> I m trying to solve kind of problems
[22:26] <kyrofa> erimsa, sure-- I mean specifically what you're looking for/trying to accomplish with a "custom store"
[22:27] <erimsa> Lets say I decided to use Ubuntu Core and Snap technology
[22:28] <erimsa> Our Snap packages should not be open for everyone
[22:28] <erimsa> Publicly
[22:28] <erimsa> It should be private to keep them
[22:29] <kyrofa> erimsa, first of all, you can have private packages in the official store
[22:29] <erimsa> I didnt know that
[22:30] <erimsa> Official means Canonical Store ?
[22:30] <kyrofa> Indeed, the Ubuntu Store
[22:30] <erimsa> I see
[22:31] <erimsa> We have lots of devices around the world ,
[22:31] <kyrofa> erimsa, if you need more control than that we do have an "on-premises store" offering, but I'm not the guy to talk to about that. I can put you in touch with the people who are, though
[22:31] <erimsa> Yes definitly
[22:32] <erimsa> If you can give me email address I can write then
[22:33] <kyrofa> erimsa, if you shoot me your email address in a private message I can send an introduction if you like
[22:33] <erimsa> OK
[22:40] <mup> PR snapd#2989 opened: many: some opensuse patches that are ready to go into master <Created by zyga> <https://github.com/snapcore/snapd/pull/2989>
[22:50] <mup> PR snapd#2990 opened: cmd: link libcap dynamically <Created by zyga> <https://github.com/snapcore/snapd/pull/2990>
[22:55] <mup> PR snapd#2991 opened: packaging: add opensuse permissions files <Created by zyga> <https://github.com/snapcore/snapd/pull/2991>