[06:22] <ThatGraemeGuy> mornings
[06:27] <mazal> Morning ThatGraemeGuy , morning everyone
[06:50] <Kilos> hi mazthaand others
[06:50] <Kilos> ai!
[06:50] <Kilos> mazal  ThatGraemeGuy
[06:51] <ThatGraemeGuy> 'lo :)
[07:03] <inetpro> good mornings
[07:03] <Kilos> morning inetpro
[07:15] <mazal> hmm , I see my auto-away is broken
[07:17] <mazal> and now I can't find that setting again
[07:17] <Kilos> lol
[07:17] <mazal> Ok , found it under identities and not under settings
[07:17] <Kilos> i have given up with that
[07:17] <mazal> Was already on though
[07:18] <mazal> But not working
[07:18] <ThatGraemeGuy> i think znc sets me away if i disconnect
[07:20] <Kilos> new venture here. looking at repacking a laptop battery
[07:20] <ThatGraemeGuy> repacking? :-o
[07:20] <ThatGraemeGuy> that sounds dangerous
[07:20] <Kilos> http://www.notebookreview.com/news/diy-laptop-battery-rebuild/
[07:21] <Kilos> will be very much cheaper than having it done
[07:21] <ThatGraemeGuy> good luck with that
[07:21] <Kilos> http://www.engadget.com/2005/06/28/how-to-rebuild-your-laptop-battery/
[07:21] <ThatGraemeGuy> lithium-based batteries are the last thing on the planet I'd be attempting DIY on
[07:22] <Kilos> oh
[07:22] <Kilos> well just looking atm
[07:24] <Kilos> oh ThatGraemeGuy i hit a luck with the T410, everything works with 14.04 kde alongside win7
[07:24] <ThatGraemeGuy> yeah
[07:25] <Kilos> so just a battery replace/repair and all good to go for loadshedding
[07:25] <ThatGraemeGuy> you have an SSD in there?
[07:25] <Kilos> no but will save for one
[07:26] <Kilos> but its quite a bit faster than my dual core here so thats good
[07:26] <ThatGraemeGuy> CPU is irrelevant, have you not learned anything?
[07:26] <ThatGraemeGuy> and good luck getting 2 hours of battery with spinning rust HDD
[07:27] <Kilos> they have same ram and its faster but maybe because of less stuff installed
[07:27] <Kilos> oh my, only 2 hours
[09:17] <pieter2627> hi all
[09:33] <ronaldm> pieter2627: morning
[09:38] <pieter2627> this is the first time i have seen you around ronaldm (or i might be paying enough attention again)
[09:39] <ronaldm> pieter2627: I have been hanging around since end of last week. I am out of Harare
[09:41] <pieter2627> ah, yeah i have not been here since early last week. Welcome to ubuntu-za thu
[09:42] <ronaldm> pieter2627: thanks for the warm welcome
[10:25] <Kilos> hi pieter2627
[10:25] <Kilos> hi ronaldm
[10:26] <ronaldm> Kilos: I am good and u?
[10:26] <Kilos> good ty
[10:26] <Kilos> oh ronaldm have you joined the africa group on launchpad
[10:27] <ronaldm> Kilos: yes I did, I have to check if the request was accepted
[10:27] <Kilos> https://launchpad.net/~ubuntu-africa
[10:28] <Kilos> then join the mailing list as well from there
[10:35] <Kilos> i normally accept requests within minutes or the next morning if im asleep already
[11:27] <Kilos> welcome to africa SubOracle
[11:27] <SubOracle> Haha
[11:27] <Kilos> lol
[11:49] <Squirm> Morning
[11:50] <mazal> Lo Squirm
[11:50] <Squirm> Hmm
[11:50] <Squirm> Rather, good afternoon
[11:51] <mazal> I was just wondering where in the world you are where it's morning :)
[12:00] <Kilos> sjoe somehow i turned konversation off
[12:00] <Kilos> or killed it should i say
[12:00] <mazal> oom Kilos , mus we ZA peeps also join the Africa group ?
[12:01] <stickyboy> mazal: "must"? ;)
[12:01] <stickyboy> Don't be elitist now.
[12:01] <Kilos> no must its just peeps that want to mazal
[12:01] <mazal> ok
[12:02] <mazal> Wasn't sure if that group is "rest of africa" only
[12:02] <stickyboy> I'm a US person from the Nairobi LUG and here I am in ZA channel. ;)
[12:03] <stickyboy> We are global... don't limit yoursefl.
[12:03]  * stickyboy dreams of eating pahlava in Uzbekistan.
[12:04] <mazal> That was easy , why can't all things be like that :P
[12:08] <Squirm> lol stickyboy
[12:13] <Kilos> all things arent make by peeps that have the ability to think
[12:13] <Kilos> i go lie down a bit
[12:30] <mazal> l8tr all , have a nice afternoon
[15:05] <Kilos> hi Arcanum_za
[15:09] <Kilos> afternoon inetpro
[16:10] <Squirm> Good eve
[16:10] <Kilos> hi Squirm
[16:10] <Squirm> Good eve
[16:10] <Kilos> that too ya
[16:23] <Kilos> hi Tonberry
[17:25] <Kilos> h ya Arcanum_za is trixie
[17:32] <superfly> Afternoon
[17:32] <Kilos> evening superfly
[17:33] <Kilos> you also losing time now
[17:33] <Kilos> getting like the pro
[17:35] <superfly> Huh? Oh, sorry. Good morning.
[17:35] <Kilos> hahaha
[18:45] <inetpro> superfly: Happy Birthday!!!
[18:46] <inetpro> oh and a good evening to everyone
[18:46] <inetpro> Kilos: and to you as well
[18:47] <Kilos> hi inetpro
[18:47] <Kilos> oho happy birthday superfly
[18:48] <superfly> ohi
[18:52] <mazal> Woot !
[18:52] <inetpro> superfly: did I get the date wrong?
[18:52] <mazal> Happy birthday superfly
[18:53] <superfly> inetpro: no
[18:54] <inetpro> ah :-)
[18:54] <inetpro> well I hope you had a great day sir
[18:54] <inetpro> and many more to come
[18:54] <Kilos> we all do
[18:54] <Kilos> oh supposed to say ditto
[18:55] <Kilos> we must learn to do what them boards and things do
[18:55] <Kilos> i had a good laugh
[18:56] <mazal> ?
[18:56] <Kilos> one syas happy birthday to you and the next one carries on with the song each one singing 1 line
[18:57] <Kilos> s/syas/says
[18:58] <Kilos> im ready for bed now
[18:59] <mazal> me too
[18:59] <mazal> Sleep well everyone
[18:59] <mazal> night
[18:59] <Kilos> sleep tight all of ya
[18:59] <Kilos> see ya tomorrow
[19:00] <Kilos> will kill T410 soon as well. so if ya wanna say something say it quick
[19:01] <inetpro> hmm...
[20:32] <magespawn> 7~/exit


[06:14] <jlj2> Loved Columbo, as a kid
[14:42] <penguin42> why would you even try and auction: https://simoncharles-auctioneers.co.uk/lots/3747057/aoc-e2270swhn-215-inch-tn-led-monitor?showNextLot=false
[14:45] <zxmpi> because someone out there has one where the panel is fine but the electronics are fried?
[14:45] <penguin42> yeh pretty rare to get the right combo for a display though
[14:47] <zxmpi> people can get creative
[14:49] <zxmpi> was reading recently of cia sourcing soviet helicopters to arm afghanistan army. he found one and flew in it to a base to see if it was worth purchasing. it sounded 'funny' when they landed he found it had engine from different model helicopter powering it :-)
[14:49] <penguin42> haha
[14:49] <zxmpi> pilot was so proud of his own work :-)
[17:58] <daftykins> happy weekend, gents
[18:01] <zxmpi> happy weekending
[18:04] <daftykins> i tried to pop by an electrical wholesalers today to pick up a bunch of data socket faceplates and what not, but they were shut! D: google's opening hours lied to me once again!
[18:04] <zxmpi> but did you not go to the shops web site?
[18:05] <daftykins> it's so close it was a good excuse to get out of the house and on the bike
[18:06] <daftykins> back soon, chicken kiev o'clock!
[18:06] <zxmpi> niceish weather here today for biking overcast not too sunny
[20:11] <daftykins> nn!


[00:23] <lutostag> on my rpi3 after I snap install pulseaudio I don't see any cards/sinks, anything I need to do to set that up?
[01:05] <Son_Goku> morphis: I think I'll crash and burn if someone suggests double LSM again as a solution
[01:37] <ngaio> Is anyone interested in helping me create a snap for Rapid Photo Downloader?
[01:40] <Croepha> perhaps if you ask a specific question :)
[01:41] <Croepha> but im actually about to go for the day
[01:43] <ngaio> Croepha, I'm a bit confused about the relationship between getting something from pip via the requirements.txt and that thing requiring dependencies to be present beforehand
[01:44] <ngaio> outside of a snap environment, one has to apt install all the build requirements first, naturally
[01:44] <Croepha> are you using the python plugin in snapcraft?
[01:44] <ngaio> I don't know if I should be or not
[01:45] <ngaio> it's a python program, but it's dependencies are not trivial
[01:46] <Croepha> if you want to do the equivalent of an apt-install for a snap, you can do something called "stage-packages"
[01:47] <Croepha> but, that usually isn't the best for python requirements
[01:48] <Croepha> im not very familiar with the python plugin, but I think it expects a properly structured python package source, and it will bundle requirements that are specified in the setup.py
[01:48] <gregl> One thing i can't get a handle on is how do you make changes to a snap app? I i'll use Hexchat as an example,I usually change the colors in it by changing some config files. Snap is a read only file system,so i am a bit lost here..
[01:49] <Croepha> gregl: everything that needs to be variable, should be located in one of the writable directories
[01:49] <ngaio> ok thanks Croepha I'll look into it some more
[01:50] <Croepha> gregl: use https://snapcraft.io/docs/reference/env
[01:50] <Croepha> gregl: you could also look at the users home directory for settings files, but that isn't a snap supported thing to do
[01:50] <Croepha> but it works
[01:51] <gregl> Croepha, Ok thanks,I did find the writeable folders..
[01:51] <gregl> Cool .I will look a bit more..
[02:57] <nacc> ok, i must be doing something obviously wrong. given the following yaml: http://paste.ubuntu.com/24364688/ i want the run.sh in snap/run.sh in the same git repository as the main part to be included in the built snap as the application. Basically, add a custom wrapper that is in the same repository
[03:05] <mup> PR snapcraft#1250 opened: Fixed links to doc <Created by andyli> <https://github.com/snapcore/snapcraft/pull/1250>
[03:06] <nacc> but when i use the builders on launchpad, i just get errors consistently about being unable to find run.sh
[03:58] <nacc> ah, i might be being bit by LP: #1663534 ... i wonder why `snapcraft cleanbuild` on my 17.04 machine at home doesn't complain, though?
[03:58] <mup> Bug #1663534: Dump plugin can't copy files from snap/ <Snapcraft:Confirmed> <https://launchpad.net/bugs/1663534>
[05:12] <mup> PR snapcraft#1251 opened: internal: remove empty lines in the unclean parts message <Created by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1251>
[05:46] <stub> I've got revision 9 of a snap published in the stable channel in the store that I can install with 'sudo snap install wal-e --classic'. However, doing that in an lxd container on the same box is getting revision 6.
[05:47] <stub> I suspect it is a permissions issue, and the difference is the lxd container is not logged on at all. But I can't see where it is screwed up.
[05:49] <stub> oh, got it. The scripted install in the container was using the wrong channel.
[05:53]  * stub wonders if 'snap list' and 'snap refresh' should mention channels
[06:09] <mup> PR snapd#3178 closed: Release 2.24 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3178>
[06:14] <morphis_> Son_Goku: you mean AppArmor and SELinux in parallel?
[06:32] <mup> PR snapd#3180 opened: many: fixes for `go vet` in go 1.7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3180>
[06:51] <mvo> jdstrand: hey, I heard rumors that there is an issue with the renamed snap-confine apparmor profile in 2.24/2.23.6 - if you have more details I would love to hear them
[06:55] <sbeattie> mvo: it looked like the ADT tests for the kernel would uninstall the 2.22.6 snapd (without purging and without uninstalling snap-confine) and then later install snapd 2.23.6. Because of that, I think the postrm bit to remove the old snap-confine profile wouldn't get triggered.
[06:56] <sbeattie> So both versions of the profile would exist after the "upgrade".
[06:58] <mvo> sbeattie: aha, thank you. let me try that
[06:59] <mvo> sbeattie: do you happen to know if there is a log or a bug available for this?
[07:00] <sbeattie> mvo, jdstrand: I'm not sure a bug got filed for it
[07:00] <sbeattie> mvo: log is at<EMAIL_ADDRESS>[07:01] <mvo> sbeattie: ta!
[07:01] <sbeattie> mvo: I'm not honestly sure if it's a snapd bug or an ADT bug.
[07:02] <sbeattie> but I can file one in case you decide to upload something on the snapd side to fix/work around it.
[07:02] <mvo> sbeattie: definitely worth persuing, I suspect that we left a file behind (/etc/apparmor.d/usr.lib.snapd.snap-confine) in some upgrade screnario
[07:06] <zyga> good morning
[07:06] <pstolowski> hey zyga, morning!
[07:09] <zyga> hey hey
[07:09] <zyga> sorry, overslept
[07:09] <zyga> how's everything?
[07:09] <sbeattie> mvo: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1682023
[07:09] <mup> Bug #1682023: snapd/snapd-confine leaves behind /etc/apparmor.d/usr.lib.snapd.snap-confine on upgrade <snapd (Ubuntu):New> <https://launchpad.net/bugs/1682023>
[07:11] <mvo> thanks sbeattie
[07:11] <mvo> hey zyga and pstolowski
[07:11] <mvo> and good morning fgimenez_ :)
[07:12] <mvo> fgimenez_: I added a forum topic and invited for you, not sure if that works
[07:12] <fgimenez_> mvo: zyga pstolowski good morning
[07:12] <fgimenez_> mvo: sure, already ack'ed with a hearth :)
[07:13] <mvo> sbeattie: apw figured out that on purge the apparmor profile is removed from disk but not unloaded from the kernel. not sure if that is expected behaviour ? maybe a precaution to ensure that running binaries that are removed from disk but still in memory are still protected? in any case it explains the error but its a bit unclear what we can do about it
[07:13] <fgimenez_> mvo: i'm currently involved in core validation at candidate too, as soon as that is sorted i'll put hands on the sru
[07:14] <mvo> fgimenez_: thank you, no problem, I just got asked about it via irc and with a forum topic its much easier for me, I can just point people to that :)
[07:14] <zyga> sbeattie: if you purge snap-confine does that go away?
[07:15] <fgimenez_> mvo: totally, the forum is a huge improvement for that
[07:15] <zyga> aha
[07:15] <zyga> it didn't purge
[07:16] <pstolowski> o/
[07:16] <mvo> zyga: yeah, I suspect we need a dpkg-mainthelper to remove the conffile on the snap-confine package as well
[07:17] <zyga> mvo: the package gets removed on purge
[07:17] <zyga> mvo: I tested this when we were working on the .real workaround
[07:18] <apw> i think the suggestion is you have old snapd + fat snap-confine installed
[07:19] <apw> you now purge snapd only
[07:19] <apw> and then install the -updates snapd
[07:19] <apw> i am trying to get into that situation here
[07:21] <mvo> zyga, apw: http://paste.ubuntu.com/24365745/ might be all we need -  but first we need to reproduce :)
[07:22]  * zyga looks
[07:22] <zyga> mvo: thank you
[07:22]  * zyga is still sleepy
[07:22]  * mvo hugs zyga
[07:28] <apw> mvo, ok reproduced
[07:29] <mvo> apw: I think I did so as well and the mainthelper did help me, could you pastebin your steps so that I can double check?
[07:30] <apw> mvo, just doing it again with a transcript to be sure i did it sane
[07:32] <mup> PR snapd#3181 opened: debian: add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/3181>
[07:43] <apw> mvo, ok reproduced and documented: http://paste.ubuntu.com/24365841/
[07:43] <apw> mvo, shall i add that to the bug as well
[07:44] <mup> PR snapd#3182 opened: store: tests for unexpected EOF <Created by stolowski> <https://github.com/snapcore/snapd/pull/3182>
[07:46] <mvo> apw: \o/ #3181 should help, I wonder what the easiest way for you to double check might be (if you are still interessted). I could do a PPA build for you? or I just reproduce all your steps once its in master and it gets into our daily edge ppa.
[07:47] <mbriza> when trying to run the anbox snap in fedora, i get "execv failed: No such file or directory" - is that a problem of snapd or the snap?
[07:47] <apw> mvo, if you have a .deb set i thnk i can legitimatly test those by hand to confirm
[07:50] <apw> all this because people are not doing upgrades right, sigh
[07:51] <mvo> apw: http://people.canonical.com/~mvo/tmp/for-andy/
[07:51] <mvo> apw: this one is hopefully good
[07:53] <zyga> mbriza: hey, perhaps snapd, can you please tell me which release are you on?
[07:54] <apw> Removing obsolete conffile /etc/apparmor.d/usr.lib.snapd.snap-confine ...
[07:54] <apw> mvo, ^ i assume that is a good sign
[07:54] <apw> and i have only the .real
[07:55] <apw> so i call that fixed in your packages
[07:55] <morphis_> zyga: looks like today is happy we-update-all-distros-with-2.24-day :-)
[07:57] <zyga> morphis_: indeed
[07:57] <zyga> morphis_: congratulations on android box :)
[07:57] <zyga> morphis_: did you try it on fedora, mbriza above said there is something fishy
[07:57] <morphis_> zyga: thanks, that was a long overdue thing
[07:57] <morphis_> zyga: no, not yet but I know people tried
[07:58] <morphis_> zyga: it will be a bit harder as we don't have dkms packages for the binder/ashmem kernel drivers there yet
[07:58] <zyga> morphis_: aha
[07:59] <zyga> morphis_: how does the snap work?
[07:59] <morphis_> zyga: devmode-only :-D
[07:59] <morphis_> zyga: and https://github.com/anbox/anbox/blob/master/scripts/container-manager.sh#L31
[08:00] <zyga> aha
[08:00] <zyga> morphis_: I think you could detect if you have apparmor around you and skip aa-exec
[08:00] <zyga> morphis_: but I bet this will come with time
[08:00] <zyga> mbriza: ^^
[08:01] <morphis_> zyga: yes, for non-apparmor enabled systems we have
[08:01] <morphis_> zyga: https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1647168
[08:01] <mup> Bug #1647168: /dev/ashmem and /dev/binder not usable inside confinement <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1647168>
[08:02] <morphis_> that was the initial reason for the aa-exec call
[08:02] <morphis_> didn't investigated that further yet
[08:02] <mvo> apw: \o/
[08:03] <mvo> apw: if you could comment in https://github.com/snapcore/snapd/pull/3181 that would be great
[08:03] <mup> PR snapd#3181: debian: add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/3181>
[08:07] <apw> mvo, am just making sure i did the test right (i am sure i did) and scipting it
[08:07] <apw> mup, ok that worked and i am happy i am sure it did :)
[08:07] <mup> apw: I apologize, but I'm pretty strict about only responding to known commands.
[08:07] <apw> mvo, ok that worked and i am happy i am sure it did :)
[08:08] <mvo> \o/ again!
[08:10] <apw> mvo, is that sufficient (as a comment)
[08:10] <mvo> apw: absolutely, thank you
[08:17] <abeato> ogra_, I have flashed latest rpi3 image, but I am not able to connect to the store from console-conf, is that a known issue? It hangs in "Contacting store..."
[08:17] <ogra_> abeato, Bug #1638537
[08:17] <mup> Bug #1638537: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0 <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1638537>
[08:19] <abeato> ogra_, not sure if it is the same, I can enter console-conf, it fails when trying to contact the store
[08:21] <ogra_> like ... with an error ?
[08:21] <ogra_> or does it just sit there ?
[08:22] <ogra_> if the latter ... give it time ... if not, thats something different then
[08:22] <abeato> ogra_, sits there, although it has just entered in the end... took really long :/
[08:22] <ogra_> yep, there is a fix ... but not landed yet
[08:22] <abeato> weird...
[08:22] <abeato> ok, good to know
[08:22] <ogra_> it generates the device gpg key
[08:23] <abeato> ogra_, another thing, which is the recommended way to get wifi working on rpi3?
[08:23] <ogra_> and go's routine for that is extremely resource consuming ...
[08:23] <ogra_> configure with wired ... ssh in, run: sudo console-conf ... disable wired, enabled wlan, reboot
[08:24] <ogra_> the wlan only has issues on the very first boot
[08:24] <abeato> ogra_, hm, is disabling wired needed?
[08:24] <ogra_> not really ... just the german in me that wants it cleaned up :P
[08:25] <abeato> lol
[08:25] <abeato> thanks!
[09:02] <pstolowski> zyga, hey, do you have a moment to review #3182? it's just a test and I need 2nd review
[09:04] <zyga> pstolowski: yes, looking
[09:10] <zyga> pstolowski: stopped mid-way, brb
[09:20] <zyga> re
[09:21] <zyga> pstolowski: so, not sure I understand what's going on there, I'll ask a few questions if that's okay
[09:23] <nottrobin> how do I get the ownership of a snap transferred to a different user/namespace?
[09:24] <zyga> nottrobin: I think you can file a bug in the store
[09:24] <zyga> http://launchpad.net/snapstore
[09:24] <nottrobin> ta
[09:25] <zyga> fun fact: scaleway offers ubuntu without 'updates' repository enabled
[09:25] <zyga> so just security
[09:25] <zyga> and main
[09:26] <zyga> I just installed snapd 2.0.2 /o\
[09:26] <nottrobin> bug filed: https://bugs.launchpad.net/snapstore/+bug/1682063
[09:26] <mup> Bug #1682063: Transfer documentation-builder from nottrobin to canonicalwebteam <Snap Store:New> <https://launchpad.net/bugs/1682063>
[09:27] <ogra_> zyga, hmm, we should probably make a deal with the security team to push it to -security in parallel (like kernels) ... that setup is surely not uncommon
[09:32] <zyga> pstolowski: commented
[09:32] <zyga> ogra_: yes, I agree
[09:32] <zyga> ogra_: but I also wonder if ubuntu is certified there
[09:37] <pstolowski> zyga, thanks!
[09:38] <ogra_> zyga, well, disabling updates and leaving security on is not uncommon on servers i think
[09:43] <sbeattie> ogra_: we only push kernels to security when we know of security issues fixed in them; alas, that happens 90% of the time. But we do push non-security toolchain things to security (to fix security builds or boot issue breakages), I suspect snapd would fall under this area.
[09:44] <ogra_> sbeattie, yeah
[09:44] <ogra_> given the amount of apparmor and seccomp changes each release has :)
[09:44] <zyga> ogra_: aha, I didn't know that
[09:45] <zyga> ara: hey, certification question, do we (as canonical) give any guarantee what it means to run "ubuntu" wrt updates? are you expected to have updates disabled when you install ubuntu?
[09:46] <ara> zyga, not sure I understand the question
[09:46] <zyga> ara: the case is that scaleway offers xenial images but the sources.list file only lists xenial-security and custom scaleway repo
[09:46] <zyga> ara: you boot an ubuntu xenial instance from some cloud provider
[09:46] <ogra_> zyga, by default they are always on ... but you can indeed preseed installs
[09:46] <zyga> ara: is it still ubuntu if they disabled updates by default?
[09:47] <ara> zyga, well, I think you are able to just keep xenial-security (kernel udpates go to the security pocket)
[09:47] <ara> zyga, that's why those are different pockets
[09:47] <ara> zyga, in case you just want security-updates but not bug fixes
[09:48] <ara> zyga, so I guess the answer might be "yes, that's still 'ubuntu'"
[09:48] <zyga> ara: aha, I see, thanks for clarifying that
[09:48] <zyga> ara: do you know if we certify scaleway images?
[09:49] <ara> zyga, no idea, you can ask that question to patricia, she may know
[09:49] <ara> zyga, (Gaughen)
[09:49] <zyga> thank you! :)
[09:50] <zyga> gaughen: do you know if we certify scaleway xenial images?
[09:50] <Chipaca> this multiple-services-in-one-snap demo thing is proving to be a trove of fails
[09:51] <Chipaca> e.g., install it, installation fails because one of the services doesn't start, installation undoes, random services left running
[09:52] <zyga> Chipaca: smells like 2.25 bugfix
[09:52] <Chipaca> if i can get to the bottom of it all in time, sure
[09:52] <Chipaca> :-)
[09:52] <Chipaca> those two random branches yesterday were a part of it
[09:52] <Chipaca> (and there's more weirdness in 'snap try', but i'm leaving that for later)
[09:54] <zyga> Chipaca: I kind of like EnsureDir approach
[09:54] <zyga> Chipaca: so we "ensure" service files are in place
[09:54] <zyga> Chipaca: or that they are fully gone
[09:54] <zyga> Chipaca: problem with stranded services is also interesting but separate
[09:55] <zyga> Chipaca: did we forget to kill them
[09:55] <zyga> Chipaca: or did they just refuse to die for some reason?
[09:55] <Chipaca> the service files go away as is appropriate
[09:55] <Chipaca> the services themselves don't
[09:55] <Chipaca> if i had answers to your questions i'd be a day ahead of where i am :-)
[09:56] <zyga> Chipaca: :-)
[10:00] <pedronis> Chipaca: we have a few things that have an undo, but not a undo what we did if we fail in the middle
[10:00] <pedronis> Chipaca: you can look at doLinkSnap for something that tries to do that properly
[10:01] <zyga> pedronis: idea
[10:01] <zyga> pedronis: not sure if good but still
[10:01] <zyga> pedronis: let's add a "cleanup stack" to a change
[10:02] <zyga> pedronis: any task can register cleanup actions that only get ran if we fail
[10:02] <pedronis> ?
[10:02] <zyga> pedronis: then if we fail we run the undo handlers and the cleanup list
[10:02] <pedronis> well we have cleanup
[10:02] <pedronis> nowadays for some stuff
[10:02] <zyga> pedronis: the reason is that this way each task can have fine-grained elements that get added as the task progresses
[10:02] <zyga> oh?
[10:02] <Chipaca> there's a cleanup task
[10:02] <zyga> so something like this exists?
[10:02] <pedronis> not like this
[10:02] <zyga> aha
[10:03] <zyga> I was thinking along the lines of:
[10:03] <pedronis> I'm mostly worried about the multiplication of concepts
[10:03] <zyga> (inside one task)
[10:03] <zyga> doA()
[10:03] <pedronis> we have undos
[10:03] <zyga> if not error, cleanupOnFailure(undoA)
[10:03] <zyga> doB()
[10:03] <zyga> if not error, cleanupOnFailure(undoB)
[10:03] <zyga> ...
[10:03] <pedronis> what we are not good at is dealing with the task that errored itself
[10:03] <zyga> aha
[10:03] <pedronis> but there's defer and stuff for that in theory
[10:03] <zyga> well
[10:04] <zyga> I worry that some of those concepts span one task
[10:04] <zyga> so a chain of tasks in one change assumes some structure
[10:04] <zyga> well
[10:04] <zyga> anyway, just an idea
[10:04] <zyga> I'm looking forward to see what Chipaca comes up with
[10:04] <pedronis> well if undoing one error span tasks
[10:04] <pedronis> then those tasks are not quite right
[10:05] <zyga> pedronis: I think we are in this situation now still
[10:05] <pedronis> that's a different kind of bug
[10:05] <pedronis> not a reason to add complexity
[10:06] <mup> PR snapd#3174 closed: interfaces,overlord: log interface auto-connection failures <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3174>
[10:06] <zyga> right, I agree
[10:06] <zyga> thank you mvo!
[10:06]  * zyga considers upgrading to 17.04 to run polaris as IRC client
[10:06] <zyga> anyone doing that
[10:06] <zyga> it has nice UI and nice notification
[10:07] <pstolowski> zyga, refactored 3182 test per your commnet
[10:07] <pedronis> Chipaca: that's that don't manipulate state too much can usually be fixed by calling their undo manually on their failure path
[10:07] <pedronis> s/that's/tasks/
[10:07] <mvo> zyga: 17.04 ftw!
[10:08] <zyga> mvo: are you on it?
[10:09] <pedronis> assuming they are correctly idempotent
[10:11] <pedronis> Chipaca: we basically need quite a few integration undo tests
[10:12] <pedronis> mmh, not undo
[10:12] <pedronis> error and undo to be precise
[10:12] <mvo> zyga: my workstation, works very well
[10:12] <Son_Goku> morphis_: yes
[10:14] <zyga> pstolowski: thank you!
[10:14] <zyga> pstolowski: checking
[10:17] <zyga> pstolowski: commented
[10:18] <pstolowski> zyga, looking, thanks
[10:23] <Chipaca> mvo— on unity 8? :-)
[10:29] <mvo> Chipaca: *cough*
[10:31] <pstolowski> zyga, ok, updated
[10:38] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/3183 :)
[10:38] <mup> PR snapd#3183: interfaces/mount: add parser for mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3183>
[10:38] <zyga> pstolowski: (replied to your PR, just add a comment there and +1)
[10:38] <zyga> pstolowski: have a look, you reviewed -1 in this series already
[10:39] <mup> PR snapd#3104 closed: tests: fix unity test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3104>
[10:39] <mup> PR snapd#3183 opened: interfaces/mount: add parser for mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3183>
[10:39] <zyga> pstolowski: not sure if I should parse mount and super-block options or optional fields deeply
[10:39] <zyga> Chipaca: go-ness review appreciated ^^
[10:43] <Son_Goku> mvo: you have a typo in your release notes
[10:43] <Son_Goku> I think you mean "joystick" instead of "joystrick"
[10:43] <mvo> Son_Goku: autsch, thank you! I will fix it
[10:44] <Son_Goku> mvo: The 2.24 packages should synchronize out to updates-testing in Fedora in a few hours, so you can probably simultaneously mention Fedora and Ubuntu in the 2.24 release announcement
[10:46] <mvo> Son_Goku: awesome! you rock!
[10:46] <zyga> Son_Goku: awesome work! :)
[10:47]  * zyga might consider switching to Fedora 25 for daily work
[10:47] <Son_Goku> mvo: I don't know if you make the release announcement usually before or after it is approved to go into ubuntu updates, so if you usually do it after, then I think we should probably push for people to test the Fedora package updates first
[10:47] <Son_Goku> zyga: :D
[10:47] <Son_Goku> Fedora master race :D
[10:48] <mvo> Son_Goku: I draft the release annoucement (its in the forum) and JamieBen_ is now handling the announcing, but usually we announce when its in -proposed
[10:49] <Son_Goku> speak of the devil :P
[10:49] <JamieBennett> :)
[10:50] <Son_Goku> but yeah, I submitted the updates to be released to updates-testing yesterday
[10:50] <zyga> (especially if someone asks me to work on selinux)
[10:50] <zyga> I need to spend some time at the forum today
[10:50] <Son_Goku> so they should go out in a couple hours or so
[10:50] <Son_Goku> people are also now asking about being able to craft Fedora-based snaps too
[10:54] <zyga> Son_Goku: this is a compound question, we can craft a snap that uses fedora bits on top of the current ubuntu-based core snap or a fully fedora based "base" snap that we don't support yet
[10:54] <Son_Goku> yeah, I know
[10:54] <zyga> Son_Goku: I think we should get base snaps first
[10:54] <sborovkov> Hello. I am building gadget snap myself. One of the things I modify is few options of config.txt (gpu_mem and couple of other options). But when I run the resulting image all my options are commented out in config.txt. What does that and how do I prevent that behavior?
[10:54] <morphis_> Son_Goku: btw. you want to push 2.24 to stable already now?
[10:55] <Son_Goku> zyga: well we can't do either right now, because snapcraft needs work
[10:55] <zyga> Son_Goku: then we will be able to do what people are really asking for: snapd not tied to ubuntu "base"
[10:55] <Son_Goku> zyga: yes
[10:55] <zyga> Son_Goku: note that snapcraft is not the only way to make snaps
[10:55] <Son_Goku> I know, but it's what we're pushing
[10:55] <zyga> Son_Goku: I think initially it is fine to just hand-craft snaps :)
[10:55] <zyga> (I love that hame)
[10:55] <zyga> name*
[10:55] <morphis_> Son_Goku: one thing I talked with zyga about earlier today was that we wait for the official release date as everyone is having it just as candidate right now
[10:55] <zyga> Son_Goku: I think snapcraft can only really be done when we have base snaps
[10:55] <Son_Goku> yes
[10:56] <Son_Goku> morphis_: what *is* the official release date?
[10:56] <morphis_> 4/24
[10:56] <Son_Goku> April 24?!
[10:56] <Son_Goku> for 2.24?
[10:56] <morphis_> yes
[10:56] <morphis> yes
[10:56] <Son_Goku> wow, that's two weeks from now
[10:56] <zyga> Son_Goku: that's confusing
[10:56] <morphis> Son_Goku: that is the regular candence time period for a snapd release
[10:56] <zyga> the reality is this:
[10:56] <zyga> 2.24 is in candidate/beta channel now
[10:56] <morphis> through those two weeks it goes through all kinds of QA
[10:56] <zyga> it's not a stable release
[10:57] <zyga> it's a source tarball release
[10:57] <zyga> + invitation to test the binary
[10:57] <zyga> since we have channels and are actively using them
[10:57] <zyga> the term "release" is not the same
[10:57] <zyga> as we traditionally are used to
[10:57] <zyga> I think we need to write this down
[10:57] <zyga> and use clear terminology all the time
[10:57] <morphis> zyga: but if you take the original "release" term, the release date is April 24 and what we have today is more of a 2.24-rc1
[10:58] <zyga> and attach a short summary to each announcement
[10:58] <Son_Goku> wow, there was literally no point in me pushing 2.24 at all, then
[10:58] <morphis> Son_Goku: there is!
[10:58] <zyga> morphis: exactly so
[10:58] <morphis> Son_Goku: we need to send calls out for testing in the community
[10:58] <Son_Goku> morphis: the problem is that if I'm ahead of Ubuntu, things are going to be broken
[10:58] <Son_Goku> VERY broken
[10:58] <morphis> a bodhi request is fine but it should land until th real 2.24 is out
[10:58] <Son_Goku> Ubuntu moves too slowly in almost every regard when it comes to this
[10:59] <Son_Goku> but if we're going to hold back the final release, I better turn off the autopush
[10:59] <zyga> Son_Goku: why would they be broken?
[10:59] <zyga> Son_Goku: yes, please turn off autopush for this
[11:00] <Son_Goku> because the core snap is always broken on classic distros when it has an older snapd than what I run
[11:00] <zyga> Son_Goku: are you sure/
[11:00] <zyga> Son_Goku: why would it be broken?
[11:00]  * Son_Goku shrugs
[11:00]  * zyga tries to understand
[11:00] <zyga> Chipaca: thanks for the feedback
[11:00] <zyga> Chipaca: I think I'll leave the int parsing asis
[11:00] <Son_Goku> it's not worth debugging because it's a spaghetti of interface things and weird errors
[11:01] <zyga> Chipaca: but I was wondering about OptinalFlds
[11:01] <zyga> Chipaca: and mount and super-block option
[11:01] <zyga> Son_Goku: I mean, what error did you see
[11:01] <Son_Goku> mainly non-existent interface errors
[11:01] <zyga> Chipaca: should I call it OptionalFields and make it []string that I really parse?
[11:01] <Son_Goku> they have no practical effect on Fedora now, since interfaces mean nothing
[11:01] <zyga> Son_Goku: which interface specifically?
[11:01] <zyga> Son_Goku: this may be an unrealted bug that I need to fix
[11:01] <zyga> (same happens on ubuntu now)
[11:02] <Son_Goku> well, I don't remember, since this was a week ago
[11:02] <zyga> is it about network-bind or core-support?
[11:02] <Chipaca> zyga— ah, i might be the wrong person to talk with about names. OptionalFields is probably better than OptionalFlds though
[11:02] <Son_Goku> core-support, I think
[11:02] <zyga> if so this is a harmless note and I do need to correct that
[11:02] <zyga> there's a branch that's pending merge and it will be in 2.25
[11:02] <Chipaca> zyga— about whether to leave it as an array, depends what you use it for
[11:02] <Son_Goku> though it might have also been network stuff *shrugs*
[11:02] <Son_Goku> in any case, it has no appreciable affect in Fedora
[11:02] <zyga> Son_Goku: both are expected
[11:02] <Son_Goku> since confinement is broken
[11:02] <zyga> Son_Goku: it's not really related to confinement this time :)
[11:03] <zyga> Son_Goku: it is the thing where we renamed plugs and there's no nice method to forget old connection
[11:03] <Son_Goku> well, the interface/plug stuff is enforced through AppArmor
[11:03] <zyga> Chipaca: ok, let's review/land this and I'll follow up with better names and perhaps deeper parsing
[11:03] <zyga> mvo: can you review/land https://github.com/snapcore/snapd/pull/3183 for further iteration?
[11:03] <mup> PR snapd#3183: interfaces/mount: add parser for mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3183>
[11:04] <Son_Goku> zyga, mvo, morphis: Bodhi's auto push on +3 stable karma is disabled
[11:04] <morphis> Son_Goku: good!
[11:04] <zyga> Son_Goku: thank you!
[11:04] <Son_Goku> now it's basically up to me to push if no one tests after 7 days
[11:05] <zyga> mvo: maybe we can edit the forum post here to indicate when we expect to release it in binary form and when was the source tarball released
[11:05] <pedronis> zyga: Chipaca: yes, Opts is kind of common, Flds not as much
[11:05] <zyga> https://github.com/snapcore/snapd/pull/3183
[11:05] <mup> PR snapd#3183: interfaces/mount: add parser for mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3183>
[11:05] <zyga> pedronis: +1
[11:05] <Son_Goku> morphis, zyga<EMAIL_ADDRESS>[11:05] <zyga> pedronis: I'm inclined to spell it Options as that matches mount.Entry for fstab
[11:06] <morphis> Son_Goku: nice!
[11:06] <mvo> zyga: sure, go ahead, its a wiki (I think)
[11:08] <Son_Goku> zyga, since we're going to have Fedora in parallel to Ubuntu, might as well make the announcement reflect that
[11:08] <zyga> mvo: can you push the 2.24 tag to master?
[11:09] <zyga> mvo: ah, I see it now
[11:09] <zyga> sorry
[11:10] <mvo> zyga: :)
[11:10] <zyga> mvo: edited
[11:11] <mvo> ta
[11:14] <sborovkov> Hello. I am building gadget snap myself. One of the things I modify is few options of config.txt (gpu_mem and couple of other options). But when I run the resulting image all my options are commented out in config.txt. What does that and how do I prevent that behavior? Is that done by configure hook or what?
[11:15] <morphis> sborovkov: sounds more like the wrong config.txt gets copied into place
[11:15] <mvo> sborovkov: I think its done by the configure hook, it will unset things that it has not in the internal snapd config iirc
[11:16]  * zyga switches gears for a moment
[11:16] <morphis> mvo: isn't that coming with 2.24 or is already part of 2.23?
[11:16] <mvo> morphis: 2.23.6 has a bug so yeah, only in 2.24
[11:16] <sborovkov> mvo: any idea how to change that? I mean I could set those config options myself but that would require additional restart
[11:16] <morphis> sborovkov: so from which channel is your core snap coming?
[11:17] <sborovkov> edge
[11:17] <morphis> ah
[11:17] <sborovkov> morphis: can't be wrong config.txt - otherwise all my options would not be in there even commented out
[11:17] <morphis> sborovkov: any specific reason to use edge?
[11:17] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/3184
[11:17] <mup> PR snapd#3184: store: misc cleanups in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3184>
[11:17] <zyga> sborovkov: maybe bug in ubuntu-image
[11:18] <zyga> sborovkov: wrt channels
[11:18] <sborovkov> morphis: yes. because it has a bunch of resloved bugs that are blockers
[11:18] <zyga> I think it handles that poorly now
[11:18] <mup> PR snapd#3184 opened: store: misc cleanups in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3184>
[11:18] <morphis> sborovkov: ah I see
[11:18] <sborovkov> also a bit annoying that you can't make ubuntu-image to use your snap for instance from edge channel but core snap from the beta
[11:19] <morphis> sborovkov: you can manually add snaps to your resulting image
[11:19] <mvo> sborovkov: we could change the configure hook code to simply ignore anything that is not set. the downside is of course that if you snap core set pi-config.something="" that would go directly into config.txt, i.e. there is no way anymore to uncomment things. but maybe thats ok
[11:19]  * mvo is away for lunch
[11:20] <sborovkov> mvo: I am ok with everything. Though just for my case since I build gadget snap myself can't I set those options manually somewhere? So it does not unset them.
[11:20] <morphis> sborovkov: https://gist.github.com/morphis/abdc1e83ba0578e756073bd89fa128ed
[11:20] <morphis> sborovkov: especially https://gist.github.com/morphis/abdc1e83ba0578e756073bd89fa128ed#file-create-image-sh-L225
[11:21] <morphis> sborovkov: if you download the snap before together with its assertion via snap download you can drop the unasserted: true
[11:22] <zyga> morphis: scaleway arm servers use patched non ubuntu kernel
[11:22] <zyga> morphis: no chance for apparmor
[11:22] <zyga> morphis: I don't think it's worth pursuing yet
[11:23] <morphis> zyga: ah
[11:23] <morphis> zyga: the better go with what plars is building
[11:23] <zyga> morphis: yes
[11:23] <zyga> morphis: I'll check their x86 VMs out of curiosity
[11:23] <morphis> :-)
[11:24] <renat> Hi, guys=) It's Renat from Screenly=)
[11:24] <renat> Hi, sborovkov=)
[11:27] <morphis> renat: hey!
[11:27] <renat> I have just a small question - snappy core doesn't ship with udisks2 installed, and I should install udisks2 into my snap, is it correct?
[11:27] <morphis> renat: we have a udisks2 snap in the store you can
[11:27] <morphis> renat: you wont be able to get udisks2 into your own snap
[11:28] <pstolowski> Chipaca, hey, are you working on any of this https://forum.snapcraft.io/t/easy-way-to-get-last-change/246 ?
[11:28] <renat> morphis, thanks! That's exactly what I need!
[11:28] <Chipaca> pstolowski— negatory
[11:28] <morphis> renat: there is upcoming documentation for that snap which is currently available here: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/udisks2/tree/docs
[11:29] <morphis> renat: but the same will be soon on docs.ubuntu.com
[11:29] <pstolowski> Chipaca, ok. bonus question then
[11:29] <renat> Thanks, morphis!
[11:29] <Chipaca> I should charge for these
[11:29] <morphis> davidcalle: you know when a new deployment of the docs will happen?
[11:29] <morphis> davidcalle: especially for https://github.com/CanonicalLtd/ubuntu-core-docs/pull/29 ?
[11:29] <mup> PR CanonicalLtd/ubuntu-core-docs#29: Enable udisks2 documentation and fix up broken links <Created by jhodapp> <Merged by caldav> <https://github.com/CanonicalLtd/ubuntu-core-docs/pull/29>
[11:31] <pstolowski> Chipaca, yesterday on the standup we discussed making "task" alias for "change" command (and make the latter hidden but still supported), but reading that forum topic makes me think that perhaps I missed something
[11:31] <Chipaca> the other way around, making change alias for task
[11:31] <Chipaca> i did not update the forum after the meeting
[11:31] <Chipaca> also, tasks, not task
[11:31] <davidcalle> morphism: later today
[11:31] <pstolowski> Chipaca, ah!
[11:31] <Chipaca> 1 change -> multiple tasks
[11:32] <davidcalle> morphis
[11:32] <sborovkov> mvo: I am still a bit confused. On the first boot pi-config is not actually set. But it's not like it removes kernel, dtparam and so on and so on from config.txt? Or is it not touching them because they can't be changed via configure hook?
[11:32] <pstolowski> chihchun, "tasks" yes. suddenly it all makes more sense and you will not get any more bonus questions, i'm sorry
[11:32] <Chipaca> pstolowski— and it wouldn't be an alias in the sense that go-flags supports aliases; it'd be a separate hidden command that just calls the other one
[11:32] <pstolowski> uh, Chipaca ^
[11:32] <pstolowski> Chipaca, yes yes sure
[11:33] <Chipaca> woah, you need four chars to get my name
[11:33] <__chip__> there
[11:33] <__chip__> now i'm special
[11:33] <zyga> morphis: can we relase 2.24 jointly to suse too?
[11:33]  * __chip__ looks at _28Kb
[11:33] <pstolowski> in fact I did this change already in cmd, it just felt strange.. "tasks" it's then
[11:33] <__chip__> pstolowski— how does it feel strange?
[11:34] <Son_Goku> davidcalle: can we have snappy-docs move to the snapcore org?
[11:34] <pstolowski> __chip__, only in that's mutiple tasks realy, plural
[11:34] <morphis> zyga: yes, working on that
[11:34] <__chip__> pstolowski— ah :-)
[11:35] <ogra_> ooh .... Chipaca has wings!
[11:36] <jdstrand> mvo: not sure if you saw, but fyi https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1682023
[11:36] <mup> Bug #1682023: snapd/snap-confine leaves behind /etc/apparmor.d/usr.lib.snapd.snap-confine on upgrade <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1682023>
[11:36] <zyga> morphis: sounds good
[11:38] <jdstrand> mvo: at, it looks like you probably did see it now that I am reading backscroll
[11:45] <mup> PR snapcraft#1247 closed: Fixing Store integration tests <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1247>
[11:45] <jdstrand> mvo: responded in 3181
[11:47] <zyga> jdstrand: hey
[11:48] <zyga> jdstrand: can you have a look at https://github.com/snapcore/snapd/pull/3138 -- it is a tiny RFC branch about mounting
[11:48] <mup> PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138>
[11:50] <pstolowski> http://www.omgubuntu.co.uk/2017/04/use-snap-fedora
[12:08] <zyga> mvo: can you have a 2nd look to ensure that we want to land https://github.com/snapcore/snapd/pull/3160/files
[12:08] <mup> PR snapd#3160: overlord/ifacestate: automatically rename connections on core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3160>
[12:09] <mup> PR snapd#3182 closed: store: tests for unexpected EOF <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3182>
[12:09] <pstolowski> zyga, ^ you will probably need to merge master into 3184
[12:10] <zyga> pstolowski: looking
[12:10] <zyga> aha
[12:10] <zyga> thanks!
[12:11]  * zyga is a bit hungry and parched, sounds like a time for a break
[12:12] <zyga> done
[12:12] <zyga> see you at the stand-up
[12:13] <zyga> niemeyer: please have a look at https://github.com/snapcore/snapd/pull/3138 -- it is on the critical path for update-ns now
[12:13] <mup> PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138>
[12:16] <morphis> zyga, mvo: looks like spread tests are a bit flawky today, is that known?
[12:20] <zyga> morphis: URL please
[12:20] <zyga> morphis: I didn't see any failures
[12:21] <morphis> https://s3.amazonaws.com/archive.travis-ci.org/jobs/221306064/log.txt
[12:21] <morphis> linode:ubuntu-14.04-64:tests/main/refresh-delta-from-core is failing here
[12:21] <morphis> zyga: that is for https://github.com/snapcore/snapd/pull/3170
[12:21] <mup> PR snapd#3170: interfaces/builting: allow read-only access to /sys/module <Created by morphis> <https://github.com/snapcore/snapd/pull/3170>
[12:23] <mup> PR snapd#3185 opened: snap: added tasks subcommand <Created by stolowski> <https://github.com/snapcore/snapd/pull/3185>
[12:24] <mvo> morphis: https://forum.snapcraft.io/t/autopkgtest-failues-with-master/260 - I think its because of the interfaces change but I did not look deeper
[12:25] <morphis> mvo: hm ok
[12:25] <morphis> then let me don't count on this and I will wait until the dust settles :-)
[12:25] <zyga> morphis: just merge master
[12:26] <zyga> aha
[12:26] <zyga> the failure is in delta-from-core
[12:30] <zyga> morphis: you just joined and disconnected
[12:57] <mup> PR snapcraft#1252 opened: ci: split plugin integration tests out <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1252>
[13:21] <Son_Goku> zyga, morphis: https://lists.fedoraproject.org/admin/lists/ci.lists.fedoraproject.org/
[13:22] <zyga> Son_Goku: I got 503
[13:23] <Son_Goku> hmm, Postorius seems to be down
[13:23] <zyga> aha
[13:23] <zyga> what was the thing behind the URL?
[13:24] <zyga> ah, it's up now
[13:24] <Son_Goku> the mailing list for Fedora CI
[13:25] <morphis> ah :-)
[13:25] <morphis> 403 forbidden for me
[13:27] <morphis> zyga: btw. did you manage to file all bugs for the SELinux denials on Fedora?
[13:27] <zyga> morphis: I filed two
[13:27] <zyga> morphis: I didn't file more as we need to check if it makes sense
[13:27] <morphis> zyga: have those two on my list
[13:27] <morphis> good
[13:27] <zyga> morphis: and I think we need to see if the format is right
[13:28] <zyga> morphis: I can file the rest
[13:30] <morphis> zyga: lets wait with that
[13:31] <morphis> I will look first and then we can decide
[13:44] <Chipaca> niemeyer— want me to open a topic about snap service?
[13:44] <niemeyer> Chipaca: Almost done with it already
[13:44] <Chipaca> niemeyer— :-D
[13:44]  * zyga goes to eat that lunch he was meant to earlier
[13:45] <zyga> I'll focus on focum / email after that
[13:45] <zyga> enjoy easter holidays o/
[13:53] <niemeyer> Chipaca: https://forum.snapcraft.io/t/command-line-interface-to-manipulate-services/262
[13:56] <Pharaoh_Atem> zyga, morphis, sergiusens: don't forget to respond to mattdm's email :)
[13:56] <sergiusens> Pharaoh_Atem: yeah, I'll reply with what I know, but leave the other paragraphs we discussed to zyga or morphis
[13:59] <Pharaoh_Atem> sergiusens: that's fine
[13:59] <ogra_> hah ... the right keyboard for core developers ... finally ... https://www.massdrop.com/buy/vortex-core-47
[14:00] <Chipaca> ogra_— what, no GOTO key?
[14:00] <ogra_> probably at the bottom :)
[14:00] <Chipaca> ogra_— http://4.bp.blogspot.com/-lUibvtAqm2E/UYVrSpG_4MI/AAAAAAAAAxE/oov7bXRCLw4/s1600/keyboard.jpg
[14:01] <ogra_> !
[14:01] <Chipaca> ogra_— or, rather, http://images.eurogamer.net/2013/articles/1/6/5/1/7/8/3/139143204009.jpg/EG11/resize/600x-1/quality/80/format/jpg
[14:01] <ogra_> yeah, i think popey raved about that one before on G+
[14:01] <Chipaca> heh
[14:02] <Chipaca> massdrop is so expensive from uk though
[14:02] <Chipaca> also, i can't really justify another keyboard
[14:02] <Chipaca> it is a beaut tho
[14:02] <ogra_> heh, yeah, i ddint mean to push you towards buying it ...
[14:02] <jdstrand> niemeyer: fyi, I plan to start an 'ownership' topic today. I can layout the various use case that have been accumulating as well as what we discussed yesterday
[14:03] <jdstrand> cases*
[14:03] <ogra_> i'm typing on the pok3er ... next bigger model with 67 keys
[14:03] <jdstrand> niemeyer: and hi!
[14:03] <jdstrand> niemeyer: I figured it might be easier this way since I've thought about this for a while (ie, if I lay it out rather than responding with other use cases)
[14:04] <niemeyer> jdstrand: Sounds great, thank you!
[14:04] <jdstrand> np
[14:10] <Chipaca> cuppa tea anyone?
[14:10]  * Chipaca goes
[14:12]  * tvoss tea, earl grey, hot
[14:13]  * genii hugs his pot of coffee instead
[14:14]  * ogra_ joins genii in huggung coffee pots
[14:18] <morphis> zyga: the export_test.go trick is good, but how can I share the best way a Mock* method across modules?
[14:19] <morphis> adding it to testsutils?
[14:21] <tvoss> niemeyer: hey, https://github.com/snapcore/snapd/pull/3130 just went green :) would be great if you could have a look
[14:21] <mup> PR snapd#3130: overlord/devicestate: switch to ssh-keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
[14:23] <niemeyer> tvoss: WIll do.. a bit busy this morning, but will do in the afternoon
[14:23] <tvoss> niemeyer: great, thank you
[14:24]  * tvoss goes to build docker snaps with configurable cert directory
[14:24] <ogra_> would be awesome if that finally landed
[14:24] <ogra_> so much back and forth ...
[14:25] <Chipaca> tvoss— now rewrite it using libressl
[14:25]  * Chipaca hides
[14:26] <tvoss> Chipaca: I would rather look at golang's BigInt and optimize that a little ;)
[14:26] <ogra_> make it EvenBiggerInt
[14:27] <bspock> Which folder should be added in my $PATH in order to run the installed snaps?
[14:28] <ogra_> bspock, the snapd package adds that autiomatically ...
[14:28] <ogra_> (you need to log out and back in if you only just installed snapd though)
[14:28] <bspock> ogra_: Ah, that's probably my problem. Will try that, thanks
[14:28] <ogra_> your path should then have /snap/bin at the end
[14:29] <Chipaca> tvoss— just math/big.divWVW
[14:29] <Chipaca> tvoss— although math/big.bitLen probably also
[14:29] <tvoss> yup, gcd might be candidate as well, haven't look further, though
[14:29] <tvoss> looked
[14:46] <sborovkov> mvo: btw why does rpi-config has _ converted to '-'. But not everywhere? :) Like here - framebuffer-ignore_alpha
[14:50] <kyrofa> sborovkov, OCD sniping?
[14:50] <kyrofa> I'm unhappy you even typed it here :P
[14:51] <kyrofa> ogra_ might have an idea
[14:53] <Chipaca> sborovkov, kyrofa, different things
[14:53] <Chipaca> _ is within a name
[14:53] <Chipaca> - is between scopes
[14:53] <Chipaca> levels
[14:53] <Chipaca> whatever you want to call them :-)
[14:53] <kyrofa> Ah, thanks Chipaca :)
[14:53] <Chipaca> there's a hierarchy in there
[14:53] <stub> -_-
[14:54] <Chipaca> totally (-_-)
[14:54] <Chipaca> (i wasn't saying it was a *good* reason :) )
[14:58] <sborovkov> Hmm, alright. It's just not very convenient when you have a list of config.txt options you want to actually set
[14:58] <sborovkov> Because they all need converted according to different rules then
[15:00] <Chipaca> sborovkov— do you think you could raise the issue on the forum?
[15:00] <Chipaca> sounds like something that needs to be spelled out in more detail
[15:00] <sborovkov> Chipaca: sure, what forum are you talking about
[15:01] <Chipaca> sborovkov— forum.snapcraft.io
[15:01] <ogra_> sborovkov, see topic :)
[15:01] <Chipaca> :-)
[15:01] <sborovkov> Damn, did not think of that
[15:01] <sborovkov> Like that's just a bit inconvenient. Can't even replace dashes with underscores. Because there gpu-mem-256. Need to have 2 maps to convert it.
[15:11] <mup> PR snapd#3186 opened: tests: allow installing snapd from -proposed for SRU validation <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3186>
[15:12] <t-mon> Hi everyone! I'wanted to ask how I can access gpio's from my snap since the gpio interface is missing on my system. I'm using snapd on a debian. Is there any other way how I can workaround this for development?
[15:13] <t-mon> Should I move this question to the forum?
[15:15] <Nicolino_> hi all : i don't find a command for producing a list of all avalaible revision of a snap on the store
[15:15] <Chipaca> Nicolino_— snapcraft history, i think?
[15:15] <Nicolino_> thanks
[15:15] <Nicolino_> also fot the core?
[15:15] <sborovkov> Chipaca: according to this hierarchy how are those options called? config_hdmi_boost, hdmi_force_hotplug (I am not sure how to query all supported names...)
[15:16] <Chipaca> Nicolino_— "for the core"? you mean for the core snap?
[15:16] <Chipaca> Nicolino_— you can only get the list of revisions of the snaps you have dev rights to
[15:16] <Chipaca> i mean upload privs
[15:16] <Nicolino_> yes  i mean core snap
[15:16] <ogra_> well ... there is "snap info core"
[15:17] <ogra_> but that only shopws current versions
[15:17] <Chipaca> Nicolino_— you can't get a list of all revisions
[15:17] <Chipaca> Nicolino_— you can get a list of published revisions, via 'snap info'
[15:17] <Nicolino_> i would test my uboot setting with a core upgrade
[15:18] <Nicolino_> i create an device image right now Chipaca
[15:18] <ogra_> Nicolino_, just switch channels then
[15:18] <Chipaca> Nicolino_— you could `snap refresh --beta core`, starting from stable
[15:18] <Chipaca> yeah
[15:18] <ogra_> snap refresh core --edge
[15:18] <Nicolino_> thanks a lot to all :D
[15:18] <ogra_> (and to switch back later just replace --edge with --stable)
[15:27] <Chipaca> ogra_— http://i.imgur.com/XbjbHlM.jpg
[15:27] <ogra_> :D
[15:49] <mup> PR snapd#3183 closed: interfaces/mount: add parser for mountinfo entries <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3183>
[15:56] <Croepha> anyone know off hand an easy way to get usb keyboard in the initramfs shell?
[15:58] <pstolowski> it would be great to get 2nd review for 3184 and land it quickly, a trivial MP
[16:33] <Chipaca> Croepha— ogra_, if anyone
[16:33] <mup> PR snapd#3184 closed: store: misc cleanups in tests <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3184>
[16:33] <mup> PR snapcraft#1252 closed: ci: split plugin integration tests out <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1252>
[16:40] <mvo> sborovkov: autsch, if it does not do it everywhere that is a bug
[16:52] <sborovkov> mvo:  IS there a way to query all  supported keys? I was checking the names from your post actually https://forum.snapcraft.io/t/configuration-options-for-core-snap/87 - specifically framebuffer-ignore_alpha
[16:52] <ogra_> Croepha, no easy way i fear ... you would have to re-pack it and add the respective modules (or simply use a serial console)
[16:54] <Croepha> ogra_, ok thanks, this is a custom kernel I made 6 months ago, I just finished downloading the Intel NUC image for 16, hopefully that will work, if not I'll rebuild
[16:54] <sborovkov> mvo: or was that typo in the post and I can just replace underscores with dashes? :-)
[16:54] <ogra_> well, that wont have hid modules either in the initrd
[16:55] <Croepha> for the record, im actually using the intel compute stick, and several months ago, the kernel that shipped with didn't have good support for the hardware
[16:55] <ogra_> we are very explicit to only include drivers that are needed to find the rootfs
[16:55] <Croepha> ogra_: ok good to know, im hoping that maybe the new kernel might fix another problem and make the initramfs KB driver unessasary
[16:56] <Croepha> but if it doesn't, then I might pop open the device physically and look for serial headers
[16:56] <ogra_> that could well be, i remember adding some modules on request of the team that was working with the NUC
[16:56] <Croepha> that might be easier then using a custom kernel
[16:56] <ogra_> afaik the normal pc-kernel snap should now work
[16:57] <Croepha> btw, is the NUC image the same as the regular amd64 image?
[16:57] <Croepha> like, is it a generic kernel?
[16:57] <ogra_> not sure ... there might be additional snaps in it by defult
[16:58] <ogra_> the kernel is definitely the same though
[16:58] <Croepha> ok good to know
[16:58] <Croepha> thanks
[16:58] <ogra_> that got fixed between 15.04 and 16 snappy images
[17:00] <Croepha> I just got a USB 3 thumb-drive, eager to see the perf differences first hand
[17:00] <Croepha> I wanted to try the new image, but didn't want to overwrite the image that kinda works on my other thumbdrive
[17:06] <Croepha> ehh, a bit underwhelming
[17:08] <niemeyer> tvoss: reviewed, thanks for all the work there!
[17:30] <sborovkov> mvo: yeah, it was typo in your post. Nice. Cause I was already doing 2 maps to convert back and forth :-)
[17:46] <Croepha> ogra_ im assuming that the serial interface for the initramfs requires a real BIOS serial port, i.e. a USB to serial wont work?
[17:46] <ogra_> USB to serial would be exactly the opposite
[17:46] <ogra_> so no, i dont think it would
[17:47] <Croepha> right, thanks, figured Id ask
[18:10] <jdstrand> morphis: I want to think about your bug #1647168 more but will ask here, quickly, snap-confine 1.0.43? shouldn't you be on at least 2.22.6 if not 2.23.6 (proposed)?
[18:10] <mup> Bug #1647168: /dev/ashmem and /dev/binder not usable inside confinement <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1647168>
[18:25] <morphis> jdstrand: that bug is quite old but thanks for looking into that!
[18:26] <morphis> jdstrand: need to see if I can still reproduce this with the latest snapd/snap-confine
[18:26] <morphis> jdstrand: http://anbox.io/ is the application I was experiencing this with
[18:58] <pompomJuice> hi
[18:58] <kyrofa> Hey there pompomJuice, welcome
[19:01] <Croepha> it appears that the pc-kernel rev 60 doesn't support HDMI audio on the intel compute stick
[19:02] <pompomJuice> How do I get snappy install to install my locally made snapcraft packages? the unauthorized setting does not work?
[19:02] <pompomJuice> Installing my-open-vm-tools_0.1_amd64.snap Signature verification failed with exit status 14
[19:02] <kyrofa> pompomJuice, what do you mean mine "unauthorized setting?"
[19:02] <kyrofa> s/mine/by/
[19:03] <kyrofa> pompomJuice, ah, installing local snaps requires you to use the --dangerous flag
[19:03] <pompomJuice> kyrofa: snappy install --allow-unauthenticated my-open-vm-tools_0.1_amd64.snap
[19:03] <pompomJuice> none of those things work with snappy
[19:03] <pompomJuice> just snap
[19:03] <kyrofa> pompomJuice, ah, that's snappy 15 speak
[19:03] <kyrofa> pompomJuice, it's changed a bit since then
[19:03] <pompomJuice> So are these snappy cloud images usable?
[19:04] <Croepha> so, what is the appropriate bug tracker for getting patches into the core kernel?
[19:04] <pompomJuice> I cannot change the channel and I cannot install dangerous modes
[19:04] <kyrofa> pompomJuice, https://askubuntu.com/questions/822765/snap-install-failure-error-cannot-find-signatures-with-metadata-for-snap
[19:04] <kyrofa> pompomJuice, is that what you're seeing?
[19:05] <pompomJuice> kyrofa: Yes know about those options. The problem I have is I am trying to use the ubuntu core cloud image. It does not comes with snapd. Rather with "snappy"... a front end of sorts for snap
[19:06] <kyrofa> pompomJuice, that sounds wrong
[19:06] <pompomJuice> it has different options
[19:06] <kyrofa> ogra_, do you know anything about that ^^ ?
[19:06] <pompomJuice> it does sound wrong!
[19:06] <pompomJuice> I want snapd
[19:06] <pompomJuice> it has what I need
[19:06] <kyrofa> pompomJuice, yeah, the command called "snappy" is very old. It sounds like you're using a distro based on 15.04
[19:06] <pompomJuice> but this cloud image comes with a noob mode snappy so I was wondering what is going on
[19:07] <kyrofa> pompomJuice, what cloud image are we talking about? Do you have a link?
[19:08] <pompomJuice> kyrofa: http://cloud-images.ubuntu.com/snappy/devel/core/current/
[19:08] <kyrofa> pompomJuice, whoa, super old
[19:09] <kyrofa> That is indeed 15.04
[19:10] <pompomJuice> ok lol
[19:10] <pompomJuice> no wonder I am getting nowhere with this
[19:10] <pompomJuice> thanksman
[19:14] <jdstrand> morphis: oh weird that it is quite old, I only just saw it recently
[19:17] <zyga> hey guys
[19:18] <morphis> jdstrand: you think it could have been a bug in snap-confine?
[19:18] <morphis> zyga: hey! :-)
[19:19] <jdstrand> morphis: there is a lot going in with bind mounts. I'm not prepared to say what the problem is
[19:19] <zyga> what are you chatting about?
[19:19] <jdstrand> though I have a lot of concerns regarding /dev/binder
[19:19] <morphis> jdstrand: ok, then let me try that again and see if is still a problem
[19:19] <jdstrand> going on*
[19:19] <morphis> zyga: https://launchpad.net/bugs/1647168
[19:19] <mup> Bug #1647168: /dev/ashmem and /dev/binder not usable inside confinement <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1647168>
[19:20] <zyga> aha
[19:20] <zyga> This is with snap-confine 1.0.43 on Ubuntu 16.04
[19:20] <jdstrand> hey zyga
[19:20] <zyga> snap-confine 1.0.43
[19:20] <jdstrand> yeah, that was what I mentioned
[19:20] <jdstrand> too old
[19:20]  * zyga reads the bug
[19:21] <jdstrand> zyga: fyi, I'm not actively looking at it atm. it is on my list to circle back to cause I have some pretty strong opinions about /dev/binder
[19:21] <zyga> morphis: do you have the apparmor denials at hand?
[19:21] <zyga> jdstrand: binder is the android RPC-like IPC right?
[19:21] <jdstrand> yes
[19:21] <zyga> you syscall and start executing in the same time slice, in another process
[19:22] <jdstrand> it is a window to a whole new, glorious attack sruface... err... world
[19:23] <morphis> zyga: it is, not I don't that is quite a long time ago
[19:23] <morphis> jdstrand: :-)
[19:23] <zyga> aha
[19:23] <zyga> jdstrand: is binder now in the kernel? I didn't know this
[19:23] <zyga> and ashmem
[19:23] <zyga> wow
[19:23] <morphis> jdstrand: guess what, we need a binder interface :-)
[19:23] <morphis> zyga: its in staging but disable by default in the std. Ubuntu kernel
[19:24] <zyga> morphis: aha
[19:24] <morphis> I have dkms packages for both
[19:24] <zyga> well, I'd say, letem have it for android-support interface
[19:24] <zyga> and just grant it to this snap
[19:24] <zyga> it's all software
[19:24] <zyga> and you know
[19:24] <morphis> or something like this
[19:24] <zyga> windows xp wasn't exactly safe
[19:24] <zyga> ;-)
[19:27] <morphis> far from :-)
[19:28] <jdstrand> zyga: no, this would have to be on an android kernel
[19:29] <jdstrand> morphis: I know you said that, but that is a *lot* more complicated than just saying 'yes, you can use /dev/binder'
[19:30] <morphis> jdstrand: yeah :-)
[19:30] <morphis> jdstrand: that is one of the cases why anbox will be devmode-only for quite some time
[19:30] <jdstrand> zyga: I'm going to pretend your argument was a joke :)
[19:32] <zyga> jdstrand: well, it was a joke but I was actually serious about it as well, if we don't provide it as an interface everyone will just use devmode; is that better?
[19:33] <jdstrand> I don't want to have this conversation :)
[19:34] <jdstrand> really, it depends on what is running on the other side
[19:34] <jdstrand> if it is like on Touch, then the services are pruned and hardened
[19:35] <jdstrand> it we are exposing the whole android service set, then, no, it probably isn't terribly better than devmode
[19:35] <morphis> jdstrand: in this case it would be more granting a single which isn't used outside of the snap
[19:36] <morphis> jdstrand: actually I have patches to make binder namespace aware
[19:36] <jdstrand> well, let's not distract ourselves atm :)
[19:36] <morphis> absolutely not :-)
[19:37] <morphis> just thinking out loud
[19:37] <jdstrand> I just wanted to put forth that devmode may work better with a newer snapd/snap-confine
[19:37]  * jdstrand nods
[19:40] <jdstrand> zyga: "Once Linux 4.13 is released any distribution can choose to enable apparmor and get complete confinement without rebuilding most of snapd" - where did you get 4.13?
[19:45] <Erix> hi
[19:46] <Erix> i installed nextcloud snap on ubuntu server 16.10
[19:46] <Erix> cannot find a2ensite for apache2
[19:46] <nacc> kyrofa: --^ redirected them from #ubuntu-server
[19:46] <kyrofa> nacc, ah, thank you
[19:46] <Erix> thanks nacc
[19:46] <kyrofa> Erix, nextcloud embeds upstream apache within it. There is no a2ensite
[19:46] <nacc> np, figured you'd be able to answer quicker than I :)
[19:47] <kyrofa> Erix, it ships pre-configured and ready to go, but it's not a general purpose apache
[19:47] <kyrofa> Its sole purpose is to serve Nextcloud
[19:47] <Erix> kyrofa, I'm kind of newbie about this
[19:47] <redpill> are snaps supposed to mount on /snap/bin  ?
[19:47] <kyrofa> Erix, oh that's okay, let's back up a little :)
[19:48] <kyrofa> Erix, is this the first time you've setup Nextcloud?
[19:48] <Erix> I'm trying to edit a virtualhost config file
[19:48] <kyrofa> Erix, what is your end goal?
[19:48] <Erix> Actually I edited but guides tell me to run a2ensite
[19:48] <Erix> direct http to https
[19:49] <Erix> I'm following nextcloud guide about https
[19:49] <nacc> redpill: i think they are mounted on /snap/<snapname>/<rev>
[19:49] <nacc> redpill: based upon what i see in my test VM :)
[19:49] <kyrofa> Erix, there's a huge difference between setting Nextcloud up by installing apache, choosing a database, etc. and just installing the snap
[19:50] <kyrofa> Erix, the snap takes care of all that stuff for you (but limits your power a bit as a result), whereas if you want to setup it all up yourself you can't use the snap
[19:50] <redpill> odd my are not
[19:50] <Erix> kyrofa, I get that
[19:50] <kyrofa> Erix, if you want to set it up yourself you need to use the Nextcloud release tarball
[19:50] <Erix> it was just too easy
[19:50] <Erix> :)
[19:50] <Erix> I'm running nextcloud with my little linux knowledge
[19:50] <kyrofa> Erix, enabling HTTPS using the snap is easy, and you don't need to play with Apache configs to get there
[19:51] <nacc> redpill: iiuc, /snap/bin is now just a place for symlinks to /usr/bin/snap to live (for each snapped application) -- based upon the one snap i have installed :)
[19:51] <kyrofa> Erix, assuming you still want to use the snap, what documentation are you following so I can know what you've done?
[19:51] <nacc> redpill: since /snap/bin is on PATH
[19:51] <Erix> kyrofa, https://docs.nextcloud.com/server/11/admin_manual/configuration_server/harden_server.html#use-https-label
[19:52] <redpill> ty that helps
[19:52] <redpill> nacc: ^
[19:52] <nacc> redpill: i'm not an expert, but that's what i see in my 16.04 vm
[19:52] <kyrofa> Erix, and what vhost are you editing?
[19:52] <Erix> kyrofa, nextcloud.enable-https: section on your snap site is about this also?
[19:52] <nacc> redpill: you should be able to see what's mounted where with `mount | grep squashfs`
[19:53] <kyrofa> Erix, indeed
[19:53] <nacc> kyrofa: is there a general "I installed this snap, how do I use it" functionality? (or even just for nextcloud)?
[19:53] <Erix> kyrofa, BTW thanks for the great work
[19:53] <nacc> kyrofa: i'm thinking similar to regular manpages, but specific to the snap's quirks
[19:53] <Erix> it was not poosible for me to install nextcloud without your snap
[19:54] <kyrofa> nacc, this pretty much: https://github.com/nextcloud/nextcloud-snap#how-to-use
[19:54] <nacc> kyrofa: ack, just wondering how a user should go from `snap install nextcloud` to that URL without coming here :)
[19:54] <nacc> kyrofa: i guess `snap info nextcloud` has the url
[19:54] <kyrofa> nacc, yeah, that's the idea
[19:54] <kyrofa> nacc, still not super friendly, but I'm not sure how to make it better
[19:55] <nacc> kyrofa: duly noted for when i see that kind of question in the future, thanks
[19:55] <nacc> kyrofa: yeah, i was just thinking -- given that you know which commands you are exposing in the yaml, it'd be nice for there to be  blurb for each
[19:55] <kyrofa> Erix, so: is the snap actually working for you, then? You just want to enable HTTPS?
[19:55] <nacc> kyrofa: in they yaml, then you could in theory do `snap man nextcloud` and it'd just spit out those fields, if there
[19:56] <kyrofa> nacc, in the `snap info` output?
[19:56] <nacc> kyrofa: not "great", but it'd be a bit more user-friendly then "go to this URL"
[19:56] <nacc> kyrofa: i think it'd be a separate command, or maybe a flag?
[19:56] <kyrofa> nacc, yeah, best I can do as a snap author is add `-h` options to my commands :P
[19:56] <nacc> kyrofa: yeah -- i guess we also have to get used to doing <snap_name>[tab] to see the commands
[19:56] <kyrofa> nacc, indeed. At least for now, yeah
[19:57] <Erix> kyrofa, yes
[19:57] <Erix> kyrofa, everything works as I like
[19:58] <kyrofa> Erix, oh, did you figure out how to use `enable-https`?
[19:58] <Erix> I just want to force every connection to https
[19:58] <kyrofa> Ah, okay, sorry. Happy to walk you through if you like
[20:00] <kyrofa> Erix, `nextcloud.enable-https -h` might be helpful
[20:00] <Erix> kyrofa, just reading the -h output
[20:00] <kyrofa> Great minds
[20:00] <mcphail> A solution for man pages and bash compketion is needed
[20:00] <kyrofa> Erix, it really comes down to "how do you want to get your cert/do you already have a cert"
[20:01] <kyrofa> mcphail, yeah I think both are in the works
[20:01] <mcphail> great
[20:02] <Erix> kyrofa, self-signed seems easier option for me
[20:02] <Erix> going with that
[20:03] <kyrofa> Erix, yeah that's pretty easy. Easy to change to something like let's encrypt later if you want
[20:04] <Erix> kyrofa, restarted apache
[20:04] <Erix> is it done?
[20:04] <kyrofa> Erix, yep
[20:05] <kyrofa> Erix, just visit it again and you'll see http redirect to https
[20:05] <Erix> kyrofa, I see https but its red and labeled not secure by chrome
[20:05] <kyrofa> Erix, yeah, because it's self-signed
[20:05] <Erix> ok. I guessthat
[20:06] <Erix> but it is secure connection
[20:06] <kyrofa> Erix, you'll need to use Let's Encrypt (or another CA) if you want web browsers to be happy
[20:06] <kyrofa> Indeed, it's encrypted
[20:06] <zyga> re
[20:06] <zyga> jdstrand: from jjohansen
[20:06] <Erix> kyrofa, it was so easy also
[20:06] <Erix> thanks again
[20:06] <Erix> very much
[20:07] <kyrofa> Erix, my pleasure, any time
[20:07] <kyrofa> Erix, FYI, I also idle in #nextcloud if you ever run into issues
[20:08] <Erix> ok. I'm there also
[20:08] <Erix> Although I read as much as needed but
[20:08] <Erix> is this right;
[20:09] <Erix> snaps are combinations of pre configured software for a specific target in mind
[20:09] <Erix> thats is what I understood
[20:09] <jjohansen> zyga: that is the goal, it is possible I want get everything landed by then, especially if some of it gets stuck for testing in the -next tree
[20:10] <jdstrand> zyga: hmm, I thought that was an estimation, not a hard date, but I don't know
[20:10] <jdstrand> it's super important to be sure
[20:10] <jjohansen> jdstrand: yeah, that is the goal
[20:11] <jjohansen> I do have some concerns around the extended network mediation, which unix sockets are the first of
[20:17] <zyga_> re
[20:18] <zyga_> sorry, network
[20:18] <tvoss> niemeyer: thanks for the review :) let me get to your final remarks
[20:21] <jdstrand> zyga_: in case you missed it:
[20:21] <jdstrand> 15:09 < jjohansen> zyga: that is the goal, it is possible I want get everything
[20:21] <jdstrand>                    landed by then, especially if some of it gets stuck for testing
[20:21] <jdstrand>                    in the -next tree
[20:21] <zyga_> aha
[20:21] <jdstrand> 15:10 < jdstrand> zyga: hmm, I thought that was an estimation, not a hard date, but
[20:21] <jdstrand>                   I don't know
[20:21] <zyga_> thank you jdstrand
[20:21] <jdstrand> 15:10 < jdstrand> it's super important to be sure
[20:21] <jdstrand> 15:10 < jjohansen> jdstrand: yeah, that is the goal
[20:21] <jdstrand> 15:11 < jjohansen> I do have some concerns around the extended network mediation,
[20:21] <jdstrand>                    which unix sockets are the first of
[20:21] <jdstrand> np
[20:21] <zyga_> jjohansen: do you think there will be any pushback?
[20:22] <jjohansen> ugh, now you have sent /me into panic mode, my deadline is only 7-8 weeks out
[20:23]  * jjohansen so prefers to ignore reality
[20:23] <zyga_> hard time to
[20:23] <jjohansen> yeah
[20:24] <zyga_> in case we get hit, I really enjoy working with you
[20:26] <kyrofa> Erix, sorry I missed your question. Yeah, that seems like a reasonable way to think of them
[20:27] <Croepha> does there exist a snap for the 4.11 kernel?
[20:27] <tvoss> niemeyer: done and pushed
[20:29] <stokachu> facubatista: around?
[20:29] <stokachu> getting a proxy error trying to upload to the store
[20:30] <facubatista> stokachu, here
[20:30] <facubatista> stokachu, "proxy error"?
[20:30] <stokachu> yea
[20:30] <facubatista> stokachu, using snapcraft?
[20:30] <stokachu> yep
[20:30] <Erix> kyrofa, thanks
[20:30] <stokachu> facubatista: http://paste.ubuntu.com/24369710/
[20:31] <stokachu> facubatista: http://paste.ubuntu.com/24369715/ in its entirety
[20:31] <facubatista> stokachu, looks like a generic server error, will take a look
[20:31] <stokachu> thanks, a kubernetes release for juju is blocked on us
[20:33] <facubatista> stokachu, did you retry?
[20:33] <stokachu> just twice
[20:33] <stokachu> you want me to try again?
[20:35] <stokachu> facubatista: ^
[20:35] <facubatista> stokachu, 1'
[20:42] <facubatista> stokachu, mind to try once again? thanks
[20:43] <stokachu> ok
[20:45] <stokachu> facubatista: looks like it went through
[20:45] <facubatista> stokachu, oh, ok
[20:46] <stokachu> facubatista: what was the issue?
[20:46]  * facubatista has mixed feelings in this situations.. glad it worked, but sad the original problem couldn't be debugged further
[20:46] <facubatista> stokachu, we were experiencing some storage issues, I just tried to confirm if it was the case here... but now it worked :/
[20:46] <stokachu> facubatista: ah ok
[20:47] <stokachu> facubatista: ill let you know on the next issue :D
[20:47] <facubatista> stokachu, thanks :)
[20:49] <facubatista> stokachu, how big is your snap file?
[20:50] <stokachu> facubatista: 92.5MB
[20:51] <facubatista> stokachu, thanks! (collecting info for people that also studied these transient errors)
[20:51] <stokachu> anytime
[21:09] <mup> PR snapcraft#1245 closed: nodejs plugin: add support for yarn <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1245>
[21:33] <gregl> If I install a snap of a running program (plexmediaserver),will it mess up my running version??
[23:16] <mcphail> Can anyone point me to a Rails application which has been snapped? Wondering if I should try to tackle snappificating Mastodon
[23:41] <mwhudson> so something in snapd is filtering out the TMPDIR environment var
[23:41] <mwhudson> any ideas where? grepping isn't finding anything
[23:55] <oky> mwhudson: do you need to set it?
[23:55] <mwhudson> a user of my classic snap wants to set it, yes


[10:18] <nixternal> if anyone here speaks with Ronnie, please inform him to try and not use Automatix in the magazine articles. he stated that "thanks to the fantastic automatix script, Ubuntu took the cake." I am getting sick of hearing and seeing Automatix...I can't wait for the article that shows granny choking a penguin because of f'n automatix
[10:18] <nixternal> kthxbye->g'nite
[10:45] <jenda> O_O
[09:22] <beuno> jenda,  :D
[09:24] <juliux> beuno,
[09:25] <juliux> ;)
[09:25] <beuno> hey juliux!
[09:25] <beuno> how's it going?
[09:25] <juliux> good
[09:25] <juliux> i hope we have some good weather on friday
[09:27] <beuno> juliux: I've been in the UK for almos 3 weeks, ANY weather will be good weather for me   :D
[09:28] <juliux> heh
[09:28] <juliux> e
[09:30] <beuno> who else is going to be in dresden besides yourself?  I think I heard that there was going to be someone else
[10:38] <jenda> beuno: :D :D :D
[10:39] <jenda> beuno: pitti
[10:39] <jenda> (martin pitt)
[10:39] <beuno> jenda: hey!
[10:39] <beuno> right, that's it
[10:39] <beuno> I confirmed my arrival time is local
[10:40] <jenda> coolio :)
[10:40] <jenda> I'll try to leave the pub in time ;)
[10:40] <jenda> I do have to clean up at home first, though ;)
[10:41] <beuno> jenda: I'll make sure to have a nice book with me, just in case
[10:41] <jenda> The exams cause a terrible disorder in my room, for some reason ;)
[10:41] <beuno> yeah, I've heard of that phenomenon
[10:41] <beuno> but again, I don't mind the mess, so please don't bother
[10:45] <jenda> beuno: sure, as long as it's possible to reach the bed through it :)
[10:45] <jenda> And mind, your bed is further from the door than mine.
[10:46] <beuno> jenda: lol, I have a bed?
[10:46] <jenda> Well, sorta :)
[10:46] <beuno> I'm sleeping on the floor here in london, so that would be an improvement!
[10:46] <jenda> It's one of those fold-out couches
[10:47] <jenda> I have a bed, a fold-out couch, a fold-out armchair and two matresses.
[10:47] <jenda> that's up to 5 sleeping spots, but 2 of the people have to like each other ;)
[10:47] <jenda> (five + mine ;))
[10:48] <beuno> wow, you really have a lot of sleeping space!
[10:48] <jenda> The problem is that when you fold out the fold-outs, there's no more room in the room (oh, the puns :D) for the mattresses.
[10:48] <beuno> hahah
[10:48] <beuno> right
[10:48] <beuno> it's going to be interesting
[10:48] <jenda> No, not really - fortunately, there's only one of you ;)
[10:48] <jenda> You have the fold-out couch ;)
[10:49] <beuno> if I can find it  :p
[10:49] <jenda> If I was intending to have 4 other strangers sleeping at my place at the same time, I suspect i wouldda mentioned it ;)
[10:49] <jenda> hehe
[10:49] <jenda> I'll put some of those runway lights on it :)
[10:51] <beuno> hahahah
[10:51] <beuno> jenda: how much was the beer over there again?
[10:54] <jenda> beuno: hehe :)
[10:54] <jenda> 1 USD in a pub, half that in a bottle.
[10:54] <beuno> I've been paying like 5 euros
[10:54] <beuno> aaaaaaaaaargh}
[10:54] <jenda> aaaaaargh
[10:54] <jenda> :D
[10:54] <beuno> I'm going to be so drunk...
[10:55] <beuno> sooooooooo druuuuuuuunk
[10:55] <jenda> Don't worry, we're so close to downtown it's comfortably walkable...
[10:55] <jenda> ...but you have to be able to walk.
[10:55] <jenda> :)
[10:55] <beuno> jenda: did you say "dragable"?
[10:57] <jenda> Weeell
[10:57] <jenda> It's uphill.
[10:57] <jenda> So I don't think I could do it in one piece.
[10:58] <beuno> right, so maybe we sould buy a pair of skateboards
[11:04] <jenda> hmm
[11:04] <jenda> beuno: Did I say it was uphill? ;)
[11:04] <jenda> You'd likely end up in the river.
[11:05] <beuno> jenda: and a long rope?
[11:05] <beuno> maybe we should look for bars that are uphill to your place?
[11:05] <jenda> Well, that could help conquering the 4 floors you have to climb :)
[11:05] <jenda> When they built apartment buildings in 1911, they didn't exactly think much of equipping them with elevators.
[11:09] <beuno> jenda: I'll make sure I take my sleeping bag with me then
[11:09] <jenda> :
[11:09] <jenda> :D
[11:09] <jenda> yeah, there's a basement, too.
[11:12] <beuno> it's a but weird I'll be in prague meeting you tomorrow, isn't it?
[11:16] <jenda> hehe :)
[11:17] <beuno> but then again, it's also weird to have met mark shuttleworth and about 100 debian developers
[11:17] <beuno> and I'm actually staying at the house of one of them
[11:17] <beuno> :p
[11:17] <jenda> Well, I suppose it could be weird to you... but I just came back from the pub, and everything seems just fine :)
[11:17] <jenda> hehe :)
[11:18] <jenda> That is pretty neat :)
[11:18] <beuno> :D
[11:18] <beuno> haha
[11:18] <beuno> I should get some beers...
[11:19] <jenda> beuno: I believe you'll have enough of them tomorrow :)
[11:19] <jenda> wel,l you'll be coming late..
[11:19] <jenda> Depends.
[11:19] <beuno> lol, right
[11:19] <jenda> If we manage the airport annoyances quick enough, we could go straigh back to the pub I'll be coming from :)
[11:20] <beuno> actually, I have a picture with mark actually..
[11:20] <jenda> Cool :)
[11:20] <beuno> jenda: that seems like a great plan
[11:20] <beuno> or
[11:20] <jenda> got a link?
[11:20] <jenda> "Got Link?"
[11:20] <jenda> haha
[11:20] <beuno> but beer on the way to your house  :p
[11:20] <jenda> I like that :)
[11:20] <jenda> hehe
[11:20] <jenda> I'll be sure to stock some up on the balcony.
[11:20] <jenda> The balcony is great for that.
[11:20] <beuno> jenda: http://beuno.com.ar/random/IMG_5392.JPG
[11:21] <beuno> jenda: buahahah
[11:21] <beuno> is it that cold?
[11:21] <jenda> It's not even too hot anymore, so they should be just fine in the evening.
[11:22] <jenda> IT's not american-beer cold, but you can get it to some 10 degrees out there, which is very comfortable drinking-temperature.
[11:22] <jenda> Trust me ;)
[11:22] <tsmithe> beuno, lol at the picture
[11:22] <beuno> jenda: I do,  :
[11:22] <beuno> :p
[11:22] <beuno> tsmithe: heh, that's why I haven't published it too much  :
[11:23] <tsmithe> haha
[11:24] <jenda> beuno: I'll have backups in the fridge in case it's a warm night :)
[11:25] <jenda> beuno: in the picture, your expression hints approximately how interesting Mark's monologue is ;)
[11:25] <beuno> jenda: I like the way you think...
[11:25] <jenda> :)
[11:25] <beuno> jenda: lol, it's actually because the person speaking is an ass
[11:25] <beuno> and I was pretty mad at what he was saying
[11:25] <jenda> hahaha
[11:25] <beuno> mark was asnwering in the best way possible
[11:25] <jenda> You should put that as a caption
[11:25] <jenda> "The person speaking is an ass"
[11:25] <beuno> there should be a link to that talk too...
[11:26] <jenda> a picture with you bored and Mark talking ;)
[11:26] <jenda> Don't worry, I get what you mean :)
[11:26] <jenda> I can imagine it was an Ubuntu corner there, and Mark was the one fighting the right cause :)
[11:26] <beuno> http://beuno.com.ar/uploads/115_Twobuntu.ogg
[11:27] <beuno> it's an hour of an ex-microsoft employee talking about open source and how debian and ubuntu should be the same
[11:27] <beuno> I just kept the video because I actually talk too at some point  :p
[11:27] <jenda> yuck
[11:27] <jenda> (at the MS guy, not you talking ;))
[11:27] <beuno> matt zimmerman was a bit less diplomatic luckily
[11:27] <jenda> how long is it?
[11:27] <jenda> 150 M!
[11:27] <jenda> My life's too short for that ;)
[11:28] <beuno> haha
[11:28] <beuno> it should be an hour or so
[11:28] <jenda> Beuno: just one more thing about my apartment: you will have trouble the constant sound of jazz outta the speakers ;)
[11:28] <beuno> jazz?  cool, I like jazz
[11:29] <jenda> But I've been known to turn it down (or off) when friends sleep over :)
[11:29] <beuno> heh, don't worry about it, I can sleep in almost any condition
[11:30] <jenda> :)
[11:30] <jenda> I actually do turn it off for the night.
[11:30] <jenda> "sleep 1200 ; amarok -s" is my recipe :)
[11:30] <beuno> hahaha
[11:31] <jenda> Well, I think I should get back to studying for a tiny bit more ;)
[11:31] <jenda> I have covered about 16 pages outta 47 for tomorrow's exam...
[11:31] <beuno> jenda: not the best ratio
[11:31] <jenda> hehe :)
[11:32] <jenda> Bah, the last 5 hours before the exam are the most productive ;)
[11:32] <beuno> go, and I'll literally see you tomorrow  :D
[11:32] <jenda> and the exam is 16:00 ;)
[11:32] <jenda> Yep :)
[11:32] <jenda> See ya
[11:32] <jenda> I'll be back for a bit before I tuck in.
[11:32] <beuno> good luck in the exam
[11:32] <jenda> thx
[11:32] <tsmithe> jenda, isn't it like midnight where you are?
[11:32] <tsmithe> you're insane!! :p
[11:33] <beuno> 11:30 is it?
[11:33] <beuno> an hour more then in UK?
[11:33] <tsmithe> well yea :p
[11:33] <tsmithe> *like* midnight
[11:33] <jenda> tsmithe: yep
[11:33] <jenda> ideal studying time :)
[11:33] <beuno> well, it's early somewhere in the worl...  :p
[11:34] <tsmithe> beuno, lol
[11:34] <beuno> that's what gets me through long nights
[11:36] <tsmithe> well, after the long night, it is early in your part of the world
[11:37] <beuno> tsmithe: normally when it's 3am in bsas, it's 8am in spain, so that helps  :D
[11:37] <tsmithe> ahh ok


[07:46] -queuebot:#ubuntu-ci-eng- costamagnagianfranco, https://bileto.ubuntu.com/#/ticket/4880 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[07:56] -queuebot:#ubuntu-ci-eng- costamagnagianfranco, https://bileto.ubuntu.com/#/ticket/4880 Generating diffs
[10:01] -queuebot:#ubuntu-ci-eng- costamagnagianfranco, https://bileto.ubuntu.com/#/ticket/4880 Failed to build
[14:37] -queuebot:#ubuntu-ci-eng- slyon, https://bileto.ubuntu.com/#/ticket/4635 Generating diffs
[15:16] -queuebot:#ubuntu-ci-eng- slyon, https://bileto.ubuntu.com/#/ticket/4635 Pending binary packages (kinetic/isc-dhcp). Ready to build (kinetic/netplan.io)
[15:35] -queuebot:#ubuntu-ci-eng- slyon, https://bileto.ubuntu.com/#/ticket/4635 Ready to build (kinetic/netplan.io). Successfully built (kinetic/isc-dhcp)


[19:18] <Kilos> hi guys, i need everyones help again to support tara please
[19:18] <Kilos> https://www.youtube.com/watch?v=JDkAbiRzACA&app=desktop
[19:18] <Kilos> the final stage is by public vote
[19:19] <Kilos> share it as far as possible please
[19:20] <Kilos> i am not sure if it needs the facebook link to be fully active
[19:25] <Kilos> paddatrapper that includes you and everyone you can find
[19:25] <Kilos> and you please superfly , get the yanks to help
[19:25] <paddatrapper> Kilos: sure, will do!
[19:26] <Kilos> ty guys
[19:28] <Kilos> https://www.youtube.com/watch?v=JDkAbiRzACA&sns=fb
[19:28] <Kilos> that is the FB link i have.


[10:21] <rmg51> Morning
[13:15] <teddy-dbear> Morning peoples,critters and everything else
[14:30] <jackson> morning


[14:31] <bencrisford> stgraber: ping
[18:01] <bencrisford> stgraber: Pingaling
[18:38] <stgraber> bencrisford: sort of there
[18:38] <bencrisford> my bug fix went a bit wrong stgraber :(
[18:39] <bencrisford> i changed added a dependency to fix a bug, then did dch -i and updated the changelog and then debuild -S
[18:39] <bencrisford> when i did my debdiff
[18:39] <bencrisford> all that appeared in there
[18:39] <bencrisford> was the changes to the changelog :'(
[18:39] <bencrisford> and ive tried and tried and tried
[18:39] <bencrisford> was up late last night fiddling around
[18:40] <bencrisford> and early this morning
[18:41] <stgraber> hmm, that's weird.
[18:41] <stgraber> so you:
[18:41] <stgraber>  - changed debian/control
[18:41] <stgraber>  - dch -i
[18:41] <stgraber>  - debuild -S -sa
[18:41] <stgraber>  - debdiff old.dsc new.dsc
[18:41] <stgraber> ?
[18:41] <bencrisford> -sa ?  nope
[18:41] <bencrisford> but i did the rest yeah
[18:42]  * LaserJock thinks he stepped into a debuild question
[18:42] <stgraber> you did :)
[18:42] <bencrisford> yeah
[18:42] <bencrisford> just after you went last night, my debdiff got totally screwed up
[18:42] <bencrisford> when i change the control file
[18:42] <bencrisford> all i get in my debdiff
[18:43] <bencrisford> is the changelog entry
[18:43] <bencrisford> :(
[18:43] <bencrisford> no matter what i do it seems
[18:43] <bencrisford> i was up late last night, and early this morning fiddling around
[18:43] <LaserJock> did you figure it out?
[18:43] <bencrisford> nope
[18:44] <LaserJock> my guess would be that you accidentally overwrote your original source package
[18:44] <LaserJock> so what you think is the pure Ubuntu package actually includes your control file changes
[18:45] <LaserJock> and so when you debdiff it, it doesn't see any difference there
[18:45] <bencrisford> ohhh crapppp
[18:45] <bencrisford> i might be able to fix this :/
[18:46] <LaserJock> just re-download the current Ubuntu source package and re-diff
[18:48] <bencrisford> i have done
[18:48] <bencrisford> seeeveral times
[18:49] <LaserJock> ok, so what steps do you do?
[18:50] <bencrisford> apt-get source pessulus
[18:50] <bencrisford> vi debian/control
[18:50] <bencrisford> dch -i
[18:50] <bencrisford> debuild -S
[18:50] <bencrisford> cd ..
[18:50] <bencrisford> debdiff old.dsc new.dsc > new.debdiff
[18:52] <LaserJock> well, that should do it
[18:53] <bencrisford> it doesnt =(
[18:53] <bencrisford> ill try again though
[18:56] <LaserJock> you might verify that your changes were actually saved in debian/control
[18:57] <LaserJock> there's got to be some simple thing
[18:57] <bencrisford> I did a few times :)
[18:59] <bencrisford> still dont work :(
[19:04] <LaserJock> bencrisford: what is the dependency you're adding?
[19:19] <LaserJock> bencrisford: I think I found your problem
[19:19] <LaserJock> :-)
[19:21] <nubae> hi LaserJock
[19:21] <LaserJock> hi nubae
[19:21] <nubae> did u get a chance to see Sugar?
[19:21] <LaserJock> not yet, no
[19:21] <LaserJock> I need to find some time to download it
[19:22] <nubae> ah... u should give it a spin... its really looking very nice now... its pushed the debian folks to get their ass in gear and get 0.84 working
[19:22] <LaserJock> bencrisford: couple things. 1) make sure you get the karmic source package, not the jaunty one and 2) you actually need to edit debian/control.in because that is used to automatically build the debian/control file when you run debuild -S
[19:22] <nubae> unfortunately, the ubuntu folks are just waiting to take what debian does, and aren't doing anything on their own initiative... I get the feeling the debian packager is resentful because of that
[19:23] <LaserJock> what Ubuntu folks?
[19:23] <nubae> heh, well those signed up as sugar team
[19:23] <LaserJock> bencrisford: so your debian/control file was getting overwritten each time you ran debuild -S
[19:23] <nubae> of which morgs was really the only one doing any work...
[19:23] <LaserJock> nubae: right
[19:23] <nubae> sounds familiar
[19:23] <nubae> ;-)
[19:23] <LaserJock> and he's not around anymore
[19:24] <nubae> right
[19:24] <LaserJock> so basically there are no Ubuntu folks
[19:24] <LaserJock> ergo they aren't waiting ;-)
[19:24] <nubae> well, I offered Jonas (debian packager) whatever help he needs
[19:24] <nubae> well, there are a bunch of folks claiming to be the ubuntu sugar team
[19:24] <nubae> and they are 'waiting to see what happens with debian'
[19:24] <nubae> ;-)
[19:27] <LaserJock> are you sure?
[19:27] <LaserJock> did they send an email somewhere?
[19:28] <nubae> in Sugar, lfaraone claims he, Sacha Silbe, and 3 others are the ubuntu sugar team
[19:28] <nubae> #sugar that would be
[19:28] <nubae> and that they made a decision to wait and see what happens with debian
[19:28] <nubae> I have a feeling this is because they simply have no idea what else todo
[19:29] <nubae> anyway, please do take a look at the suse offering so I can get going on working on the ubuntu side
[19:30] <LaserJock> why do I have to look at it?
[19:31] <nubae> cause u are edubuntu council and u make decisions on what goes in and what doesnt?
[19:31] <LaserJock> I'm certainly interested in what you've done, but I don't know why that'd block Ubuntu
[19:31] <nubae> I'm sure I can come up with other reasons...
[19:31] <LaserJock> well, is Debian getting back on track?
[19:31] <nubae> basically so u can discuss with me how we move forward with putting it into ubuntu
[19:31] <nubae> they are... like I said, I'd work with Jonas
[19:32] <nubae> but how its presented is an ubuntu thing
[19:32] <LaserJock> ok, well bottom line is if Debian get's things in order we mostly get things for free
[19:32] <LaserJock> ah
[19:32] <nubae> ie... how many/which activities to show, how to categorise
[19:32] <nubae> how to include in the cd/dvd
[19:32] <LaserJock> I think we might consider having an edubuntu-sugar metapackage
[19:32] <nubae> do we make a just sugar ubuntu cd/usb stick=
[19:32] <nubae> ?
[19:33] <nubae> yeah that goes without saying...
[19:33] <LaserJock> well
[19:34] <LaserJock> I can imagine having an official unofficial Sugar-on-a-Stick image
[19:34] <LaserJock> we're not going to have enough official hosting for it
[19:34] <LaserJock> we're going to be lucky if we get the DVD
[19:34] <nubae> yeah since the other distros do it, e/dubuntu kind has to too
[19:34] <nubae> it has a big advantage there
[19:35] <nubae> and that is that it can carry binary drivers
[19:35] <LaserJock> other distros as in? Fedora and openSUSE?
[19:35] <nubae> where Fedora and openSUSE cannot
[19:35] <nubae> I'm thinking about net connectivity here
[19:35] <nubae> its quite a pain on both Fedora and openSUSE...
[19:35] <LaserJock> ah, because Ubuntu has pretty good network/wifi hardware support?
[19:36] <nubae> yep
[19:36] <nubae> so that is a very big advantage, that might even tip the balance as to which SoaS is used
[19:36] <LaserJock> well, I would think as  long as we can find some hosting for it
[19:36] <LaserJock> and we say that we don't explicitly support the image itself
[19:36] <nubae> right now people are doing crazy stuff like virtualising Sugar on an ubuntu image
[19:37] <LaserJock> it would be really fairly easy for us to do
[19:37] <nubae> virtualising fedora on ubuntu to get networking working...
[19:37] <nubae> pretty crazy
[19:37] <LaserJock> I'm just not sure we have resources to have it as an official, fully supported offering, if that makes sense
[19:37] <LaserJock> yucky
[19:38] <nubae> yeah yucky but there is no other way.... this is where the entire policy crap shoots us linux users in the foot
[19:38] <LaserJock> so the things we'd want would be:
[19:38] <LaserJock> 1) metapackage that puts everything together
[19:38] <LaserJock> 2) image building script
[19:38] <nubae> and metapackages that seperate by subject perhaps
[19:38] <LaserJock> well
[19:38] <nubae> as in the next version of sugar, u can launch individual activities straight through gnome
[19:39] <LaserJock> Sugar on a Stick is a live version isn't it?
[19:39] <LaserJock> wouldn't we just want everything installed?
[19:39] <nubae> yeah
[19:39] <nubae> thats the question
[19:39] <LaserJock> what's the reason not to?
[19:39] <nubae> sugar 'policy' (I hate that term now) says users should only have the core activities
[19:40] <LaserJock> ah, I see
[19:40] <nubae> and that all the rest should be downloaded from activities.sugarlabs.org
[19:40] <nubae> I disagree completely
[19:40] <nubae> which is why I packaged all the activities
[19:40] <LaserJock> so in showing off Sugar we want to make sure to show off the official Sugar packages
[19:40] <nubae> I would say no... I would say we show off the best possible sugar
[19:40] <nubae> its up to us what we package
[19:41] <nubae> but thats why I want u to look at suse sugar
[19:41] <nubae> so u get an idea of what is packagable
[19:41] <LaserJock> but in the case of Sugar-on-a-Stick it's a demo'ing thing so you really want to show off the full capabilities
[19:41] <nubae> and from that we can choose what to do
[19:41] <nubae> yeah indeed, I think so too
[19:41] <nubae> but the sugar 'policy' is not that
[19:42] <LaserJock> well, we can do whatever we want
[19:42] <LaserJock> the sticking point would be if we wanted our image to be like officially blessed or something
[19:42] <nubae> by whom?
[19:42] <LaserJock> Sugar Labs or something
[19:42] <nubae> bah, they'd bless it regardless
[19:42] <LaserJock> ok, well then I don't see much of a problem
[19:43] <nubae> at least they did with opensuse, where that offering is currently considered to be the best ;-)
[19:43] <LaserJock> it's kinda like Ubuntu shipping Firefox extensions
[19:43] <nubae> or binary drivers
[19:43] <LaserJock> except more so in this case I think
[19:43] <LaserJock> as for sure for a image the usefulness of the image is in having everything there out of the box
[19:43] <nubae> yeah
[19:44] <nubae> actually activities.sugarlabs.org is based on mozilla extensions api
[19:44] <LaserJock> I need to run
[19:44] <nubae> yep
[19:44] <nubae> ok.. well take a look when u get a chance
[19:44] <LaserJock> but I think if you maybe could put together a "this is what needs to be done in order to produce a USB image" and send it to the list it'd help get the ball rolling
[19:49] <bencrisford> LaserJock: you're a ruddy genius!!!  it worked!!!
[19:49] <bencrisford> you should do like a phd or something ;P
[20:03] <nubae> a phd in package management... heh that would actually be quite an interesting position, with some possible job opportuntiies at the end of the line
[22:04] <compusec> does someone know how to fix the WIRELESS WEAK SIGNAL PROBLEM on ubuntu 9.04
[22:04] <compusec> ?
[22:05] <compusec> no
[22:05] <asanchez> compusec, do you mean Ralink problem?
[22:05] <compusec> i got
[22:05] <compusec> a problem with any wireless connection on any laptop that i install ubuntu 9.04
[22:06] <compusec> i have read that there are a lot of people with this problem, but i haven't found a solution yet
[22:07] <asanchez> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/293946
[22:08] <asanchez> a
[22:11] <compusec> yeah, alrealdy readed that, no help at all