[15:33] <Tm_T> hi all
[15:33] <MTecknology> MenZa: perhaps ops should be required to idle here as well?
[15:33] <MenZa> MTecknology: Absolutely. :)
[15:33] <MTecknology> it would take away the purpose of idling in -ops
[15:33] <MenZa> MTecknology: As I just said in -ops, I have far too many channels on autojoin, so it leaves a few out :(
[15:34] <MTecknology> any irc related discussion could probably take place here instead; leave -ops strictly for issues in core channels
[15:34] <MTecknology> Tm_T: hi
[15:34] <Pici> People come here to ask questions, like asking for Ubuntu cloaks.
[15:35] <Tm_T> MTecknology: well, -ops can be used between ops, but all important information should be told here too
[15:35] <MenZa> MTecknology: Or, create a lounge similar to what Pricey suggested on the ML; leave this for international and team coordination, and let ops be dispute resolution.
[15:35] <Pici> Theres no reason why a non IRCC person can't triage those questions.
[15:36] <MTecknology> MenZa: the lounge idea sounds a lot like -offtopic which is an ugly channel
[15:36] <MenZa> MTecknology: See the ML.
[15:36] <MenZa> (I also disagree on -ot, but that's because it's my primary hangout :))
[15:37] <Tm_T> MenZa: for me it's the ugliest channel I'm in (:)
[15:37] <MenZa> :P
[15:37] <Tm_T> not saying it's unbearable, just pure nonsense to me for most of the time
[15:37] <MenZa> hehehe
[15:38] <MTecknology> I can't join it longer than a few minutes at a shot
[15:39] <bazhang> should be shut imo
[15:39] <MenZa> wat
[15:39] <MTecknology> but random chit chat among ops may as well exist in -offtopic; and that would perhaps entice 'a certain some' ops to clean it up a little
[15:40] <Pici> Ops have lives and jobs and can't be watching all channels all the time.  If theres something that needs our attention then call ! ops or message one of us who isn't /away or join -ops and tell us.
[15:42] <MTecknology> I never said they need to watch all channels
[15:43] <Pici> MTecknology: I'm replying to your claim that -offtopic needs to be cleaned up.
[15:43] <MTecknology> oh
[15:44] <MTecknology> well - my point was that if ops use that as the 'lounge' then if they can handle the way the channel is going then it just stays as is; if they don't see it as a fit place to chit chat then perhaps it should be cleaned up until it is suitible for that
[15:45] <MTecknology> after all - that's what the point of -offtopic is; it's for random chit chat in the spirit of ubuntu
[15:45] <Pici> I don't think that it would be a fun place to be if we were constantly discussing operator stuff.
[15:46] <MTecknology> you didn't say op related
[15:47] <MTecknology> you said along the lines of asking about the weather, how the day is going, etc
[15:48] <MTecknology> apparently irssi sucks to deal with so I don't have that log to reference...
[15:49] <MTecknology> I'm sure I know where my thoughts wind up, especially with certain ops; so I'll take off and go take my shower now..
[16:15] <MTecknology> is it ok if I idle in -ops to watch the discussion?
[16:20] <MTecknology> MenZa: ?
[16:24] <Pici> There is no discussion going on there currently.
[16:25] <bazhang> dont jinx it :)
[18:36] <m4v> study! i'm off
[18:49] <topyli> MTecknology, the discussion takes place (officially) on the mailing list instead of the channel because mailing list archives are better than irc logs
[18:50] <topyli> also, everyone doesn't have to wake up, stop working, put their babies in front of the TV etc. at the same time in order to take part in email discussion
[18:51] <Pici> I don't have any babies, should I find one and put it front of a tv?
[18:52] <topyli> Pici, you don't, because we're using email! :)
[18:52] <Pici> Oh, okay.
[18:52] <topyli> you can wake up and stop working if you like though
[19:42] <Pricey> MTecknology: the idea of having some "ops related, relaxed, all welcome if you smile" channel would only work if the management took an active role in shaping it and encouraging good discussions.
[19:43] <Pricey> notice "encouraging", not "enforcing rules"
[19:47] <Pici> managment?
[19:49] <Pricey> Sorry Pici, in  a 'playful' mood.
[19:55] <Myrtti> heads up, there's some mirc kiddies joining #ubuntu, they might get ideas
[20:01] <Tm_T> Pricey: reason why this channel doesn't work for it?
[20:50] <Philip5> hi guys! i just got ubuntu membership and am wondering who could help me change my cloak?
[20:53] <Pici> Philip5: Whats your launchpad id?
[20:54]  * Pici requests launchpad ids from people who were just approved as members and want cloaks
[20:54] <qense> Pici: I'm one of them: qense
[20:54] <Philip5> https://launchpad.net/~philip5
[20:55] <Philip5> qense: so it's you and me then ;)
[20:55] <qense> just the two of us?
[20:55] <Philip5> qense: congrats for passing the test ;)
[20:55] <qense> What about toabclt
[20:55] <Philip5> i think so or maybe one more
[20:55] <qense> Philip5: congrats to you to
[20:56] <Pici> niko: Around?
[20:56] <Pici> Or Pricey?
[20:57] <Pici> qense, Philip5: Just looking for a freenode staffer to apply the cloak at this point.
[20:57] <Philip5> Pici: nice
[20:57] <qense> Pici:ok, thanks
[20:58] <Philip5> qense: looks like it's only the 3 of us this time then... of 10 applicants
[20:59] <qense> Yes
[20:59] <qense> I'm not sure if that's normal, but it seems a bit disappointing to me.
[21:00] <Pici> Which board?
[21:00] <qense> EMEA
[21:00] <qense> regular membership
[21:01] <Pici> Ah.
[21:02] <qense> am being cloaked right now
[21:02] <Pici> Great, congrats :)
[21:03] <Pici> Remember to identify to freenode or else the cloak will not be applied.
[21:03] <qense> again?
[21:04] <Pici> qense: identify, not register.
[21:04] <Pici> Like you probably already do every time you connect.
[21:04] <qense> yes, I already do
[21:08] <Pici> KB1JWQ should be cloaking you two, I need to run, so please ping me if it doesn't get done.
[21:09] <niko> ok
[21:10] <niko> Philip5: congrats
[21:11] <Philip5> niko: thanks :)
[21:15] <toabctl> hi
[21:15] <toabctl> Just join #ubuntu-irc and ask, giving a link to your Launchpad profile and make sure you have set up your account as per these steps.
[21:16] <toabctl> ^^ here's my lp-id: https://launchpad.net/~thomasbechtold     can somebody help?:-)
[21:24] <MenZa> toabctl: hang in there, someone should help you shortly. :)
[21:33] <ubot4> In #ubuntu-si, miha said: !troll is <alias> offtopic


[11:39] <jorgg> clear
[11:42] <jorgg> ops .. :)
[16:23] <wildcard> Hi. I've got an D945GCLF board with an Atom cpu. Almost everything works.
[16:23] <wildcard> But the frequency scaling does not work properly
[16:24] <wildcard> Does somebody has got a working setup??


[03:11] <chai_sangeen> hello everyone..
[05:53] <virtualroadside> my icons disappeared on the last update, any thoughts?
[06:20] <inkynoob> I installed Ubuntu Mobile on my eeePC and it starts when I log in, but there are no icons on the desktop. Should the ubuntu-mobile package pull in a certain set of apps?
[07:16] <inkynoob> There aren't any icons on my desktop, does anyone have any suggestions for what I should try?
[07:41] <dholbach> good morning
[07:55] <dholbach> who takes care of bluetooth stuff?
[08:01] <StevenK> dholbach: In terms of the bluez-utils sponsorship?
[08:01] <StevenK> dholbach: If that's what you're asking, it's in the unapproved queue
[08:01] <dholbach> oh? the --enable-pand and --enable-hidd upload?
[08:01] <StevenK> Right
[08:02] <dholbach> ah good then
[08:02] <dholbach> cheers
[08:05] <inkynoob> Good morning :-)
[08:07] <inkynoob> It looks like this is why I don't have icons on my desktop : https://bugs.launchpad.net/ubuntu/+source/hildon-desktop/+bug/219041 -- I didn't file the bug, but I'm Michael Moore that replied to it
[08:07] <ubotu> Launchpad bug 219041 in hildon-desktop "No icons on UME desktop" [Undecided,New]
[10:25] <heno> from today's testing by davmor2: http://www.davmor2.pwp.blueyonder.co.uk/20080418menlow.png
[10:26] <davmor2> morning people I got issues with this mornings image in that it looks like this in xephyr link above
[10:26] <heno> amitk, StevenK ^
[10:30] <amitk> lool_: ^
[10:33] <davmor2> sorry about that hard freeze
[10:33] <davmor2> someone ask something?
[10:42] <Hobbsee> davmor2: no
[13:01] <lool_> davmor2: You can check what was uploaded recently in the ppa; the page doesn't load for me though
[13:02] <agoliveira> lool_: You mean you can't open or PPA page? Is working fine from here.
[13:02] <agoliveira> s/or/our
[13:03] <lool_> I can't load https://edge.launchpad.net/~ubuntu-mobile/+archive nor without edge
[13:03] <lool_> But then my connection was cut multiple time this morning locally; perhaps my ISP has issues too
[13:04]  * lool_ returns to building his menlow and packing
[13:04] <agoliveira> lool_: Probably. Here is working nicely.
[13:04] <lool_> agoliveira: Could you check what was uploaded recently?
[13:04] <lool_> I don't know of an easy way to be notified of ppa uploads; all I get are build failures
[13:04] <lool_> I'd actually like to know when people upload stuff
[13:05] <cprov> lool_: the page works fine here.
[13:05] <lool_> It works from a hosted server too
[13:06] <lool_> Looks like a rooting issue somewhere
[13:06] <lool_> telnet launchpad.net 443 gets stuck waiting for a connection
[13:06] <agoliveira> lool_:   cairo - 1.6.0-0ubuntu2~804um1,           libdrm - 2.3.0-4ubuntu4~804um3               linux-ubuntu-modules-2.6.24 - 2.6.24-16.23+804ume1               moblin-applets - 0.55               pango1.0 - 1.20.1-1ubuntu1~804um1               ubuntu-meta - 1.101~804um1               ume-config-common - 0.10+upstream-0ubuntu1~804um2               xserver-xorg-video-psb - 0.2.8-0ubuntu1~804um1
[13:07] <lool_> cprov: while you're around, do you happen to know whether the pagination issue with ppa pages is pending resolution?   O:-)
[13:08] <lool_> It doesn't respond to pings from here either
[13:08] <lool_> Uhoh nor does archive.ubuntu.com
[13:08] <cprov> lool_: the edge PPA overview is now paginated by default.
[13:08] <lool_> That's not going to be fun
[13:08] <lool_> cprov: Excellent!
[13:09] <lool_> cprov: You mean with a mean to access the other pages, right?
[13:09] <cprov> lool_: yes, that's much better.
[13:09] <lool_> Cause at some point, the list of packages was cut, but there was no link to the next page
[13:10]  * lool_ jumps on IS to check whether it's "only me"
[13:10] <cprov> lool_: yes, you had to click the 'Search' button to get the pagination rendered for PPAs with more than 50 packages published.
[13:11] <lool_> cprov: And that's fixed?  Cool, that's what I was wondering about
[13:12] <cprov> lool_: yup, you would know if your ISP allows you to get into edge.l.n ;)
[13:17] <lool_> Seems it's my ISP; traceroute ends at <IP_ADDRESS>
[13:27] <virtualroadside> yeah, launchpad has been really slow for me the last few weeks
[13:29] <virtualroadside> inkynoob: i filed that bug. good thought to run that from the command line
[14:02] <davmor2> lool_: sorry I was away from the keyboard
[14:02] <virtualroadside> hey, you wouldn't happen to know how to tell gdb to display what module is being executed, given a memory location of the function?
[14:03] <davmor2> no
[14:04] <virtualroadside> hmm.
[14:09] <lool_> virtualroadside: "x" + address should give you the name of the function if the debugger knows it
[14:09] <lool_> (gdb) x 0x08067e3e
[14:09] <lool_> 0x8067e3e <main+14>:    0x3156ff31
[14:09] <lool_> (gdb) bt
[14:09] <lool_> #0  0x08067e3e in main ()
[14:12] <virtualroadside> lool_: tnx
[14:42] <inkynoob> Hello, did anyone else have all their icons disapear with the updates today?
[14:49] <agoliveira> inkynoob: It went fine here.
[14:55] <inkynoob> agoliveira, which package provides the icons? Is it hildon-desktop?
[14:55] <agoliveira> inkynoob: I don't know, sorry.
[14:58] <inkynoob> agoliveira, you're from Brazil?
[14:58] <agoliveira> inkynoob: Yes, I am.
[14:59] <inkynoob> what part? I lived in Minas for a year, and in Sao Paulo for 2
[15:03] <agoliveira> inkynoob: Joinville, SC.
[15:04] <inkynoob> Cool, I always wanted to visit SC, I've got a good friend in Lages
[15:40] <heno> agoliveira: seems inkynoob may have reproduced this http://www.davmor2.pwp.blueyonder.co.uk/20080418menlow.png
[15:41] <agoliveira> heno: Weird... let me see something...
[15:41] <davmor2> heno: I confirmed bug 219041
[15:47] <heno> davmor2: thanks
[15:47] <agoliveira> heno: I can't confirm this. If you saw the same effect, just file a bug please.
[15:47] <davmor2> I've added the link to the image on the bug report
[15:48] <davmor2> agoliveira: check out bug 219041 there has been some work done on it already IIRC
[15:48] <ubotu> Launchpad bug 219041 in ubuntu-mobile "No icons on UME desktop" [Undecided,Confirmed] https://launchpad.net/bugs/219041
[15:50] <agoliveira> davmor2: Oh, I've seem it. Thanks.
[16:06] <doko> StevenK, lool: mobile-basic-flash contains some flash blobs without source code. how is other flash code handled in mobile packages?
[16:06] <StevenK> lool: ^]
[16:06] <StevenK> s/]//
[16:14] <lool> doko: These are actually the files which are being opened in the GUI to edit these
[16:14] <lool> doko: So this is the preferred form of modification and use and these files were made under the same license
[16:15] <doko> lool: ohh, really? point taken
[16:15] <lool> doko: Nobody likes the files, and they are said to have some bugs; it would be best to move to something else, but we also use the package for pure html UIs
[16:16] <doko> lool: did somebody look at the source code? I can't review this :-/
[16:17] <lool> doko: Consider them like .pngs
[16:17] <doko> ok
[16:18] <lool> Sorry about this situation; it's not easy to solve the problem of providing flash files in source form; it's really the way they are edited in the editor and all and just like data files we have to provide the license outside of them
[16:26] <Adri2000> lool: re: tasks, so build log says "intltool-update: POTFILES.in not found.
[16:27] <lool> Adri2000: Does it cd to po?
[16:27] <Adri2000> in the source package, po/ contains a POTFILES.in
[16:27] <Adri2000> I think that's the problem, because it cd to /build/buildd/tasks-0.13/debian/build/standard/po
[16:27] <lool> Yeah
[16:28] <lool> Probably due to DEB_BUILDDIR hacks in deed
[16:30] <lool> Adri2000: Will likely affect dates as well
[16:31] <Adri2000> dates?
[16:31] <lool> Adri2000: dates/dates-hildon just like tasks
[16:32] <Adri2000> ah
[16:34] <lool> Adri2000: I'm trying to think of the proper fix, but I can hint you on the work around
[16:36] <lool> Adri2000: The short term workaround would be to call intltool-update manually in a similar way
[16:36] <Adri2000> the workaround I'm trying right now is to manually copy the POTFILES.in where it expects it to be
[16:49] <lool> Adri2000: Would be an option
[16:49] <lool> (Sorry was having a phone call)
[16:50] <lool> Adri2000: Otherwise, I think flipping if grep -q intltool $(DEB_BUILDDIR)/po/Makefile* with elif [ -e $(DEB_BUILDDIR)/po/Makefile ]; then \ might work
[16:51] <lool> Adri2000: I'll have to leave you now; I have other things to complete tonight and not much time left; I'm happy to sponsor a patch over the WE if it's still possible in terms of freezes and the like
[16:51] <lool> Adri2000: Thanks for your work :)
[16:52] <Adri2000> lool: ok, will try to get a patch working, thanks for your help
[17:09] <doko> StevenK: moblin-applets is a bit messy ...
[17:10] <ToddBrandt> doko: what about moblin-applets is messy?
[17:12] <doko> ToddBrandt: https://bugs.edge.launchpad.net/ubuntu/+source/moblin-applets/+bug/219087/comments/2
[17:12] <ubotu> Launchpad bug 219087 in moblin-applets "MIR for moblin-applets" [Undecided,Incomplete]
[17:13] <ToddBrandt> doko: good comments, I'll take care of them
[17:13] <ToddBrandt> launcher is no longer needed anyway
[17:14] <doko> ToddBrandt: thanks!
[17:14] <ToddBrandt> we're still waiting for Inuka to update the ppa repo, so I may not be able to push the changes til next week though, however they will be in 0.56 when it comes out
[17:26] <StevenK> doko: You want libmokoui2's debian/control to be universe/<blah> for vala?
[17:26] <StevenK> doko: Or just add X[BS]-PythonVersion, and you're fine?
[17:26] <doko> StevenK: no, that will be done by archive admins
[17:27] <StevenK> doko: Mmmmm. I didn't think it was necessary, which is why I skipped it
[17:27] <doko> it *is not* necessary
[17:29] <StevenK> doko: Okay, if it isn't, why do I need to add it? I've never been clear on the fields.
[17:30] <doko> StevenK: you don't need it. just add the X[BS]-PythonVersion. that's the only thing to be done
[17:30] <StevenK> doko: Sorry, I know about universe/, what I'm asking about is X[BS]-PythonVersion.
[17:30] <StevenK> doko: The necessary bit was about X[BS]-PythonVersion too
[17:32] <doko> StevenK: yes, we need it to know when we have to rebuild the binary.
[17:33] <StevenK> doko: Okay, I'll sort out X[BS]-PythonVersion.
[17:34] <StevenK> doko: Quite happy for vala to be universe.
[18:57] <ToddBrandt> tonyespy: in bug https://bugs.launchpad.net/acton/+bug/188168 are they talking about gaston or hardy?
[18:58] <ubotu> Launchpad bug 188168 in acton "Wifi - cannot establish connection after cancelling dialog" [High,In progress]
[19:01] <pmcgowan> ToddBrandt, all bugs are against hardy
[19:01] <ToddBrandt> ok, that's what I thought
[19:01] <ToddBrandt> I'm having trouble getting the gnome-keyring manager to work on the latest hardy image
[19:02] <ToddBrandt> so I can't reproduce alot of these bugs against the "Moblin Network Profile Manager"
[19:02] <pmcgowan> ToddBrandt, do you have the latest UME image for CB?
[19:03] <ToddBrandt> pmcgowan: I have the latest for samsung actually, are these all on CB?
[19:03] <ToddBrandt> that would change things a bit
[19:04] <pmcgowan> ToddBrandt, well, they are all on menlow of course
[19:04] <pmcgowan> both CB and target MIDs
[19:04] <pmcgowan> Q1 testing should be ok though
[19:04] <pmcgowan> at least for these issues
[19:05] <ToddBrandt> pmcgowan: hmm, I'm seeing behavioral differences between the menlow and mccaslin target builds with MIC
[19:06] <pmcgowan> ToddBrandt, I can believe that
[19:10] <tonyespy> ToddBrandt: sorry was away from my desk.
[19:10] <tonyespy> ToddBrandt: yes, gnome-keyring-manager is messed up...
[19:10] <tonyespy> ToddBrandt: we got around this by shipping a default.keyring that's cleartext
[19:11] <tonyespy> ToddBrandt: our customer didn't like being prompted for a keyring password, so by including a default.keyring w/no password, problem solved
[19:12] <tonyespy> ToddBrandt: there is a bug i gnome-keyring where the ask process crashes on Hardy.  I never quite nailed the problem, and then decided to skip it once I figured out the password-less keyring change
[20:04] <ToddBrandt> tonyespy: ok, thanks


[01:20] <mwhudson> yay spammers found the forum
[01:32] <Pharaoh_Atem> murr
[05:09] <mup> PR snapd#3413 opened: tests: fix for econnreset test checking that the download already started <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3413>
[05:46] <luk3yx> I'm having an issue with building a snap.
[05:46] <luk3yx> snapcraft doesn't copy the '.desktop' files across with the 'dump' plugin like it used to.
[06:43] <zyga> morphis_: hey
[06:43] <zyga> morphis_: just running tumbleweed here, I noticed that none of the desktop launchers work
[06:43] <morphis_> zyga: which desktop launchers do you mean?
[06:43] <morphis_> the ones you get in the gnome shell dash?
[06:43] <zyga> morphis_: any made by snaps
[06:43] <zyga> morphis_: yes
[06:44] <morphis_> hm, I tried this with krita and I could start
[06:44] <zyga> morphis_: we just set PATH
[06:44] <zyga> morphis_: in which DE and suse release?
[06:44] <zyga> anyway, running gnome tumbleweed, it doesn't work
[06:44] <zyga> looking at why now
[06:45] <morphis_> I hope this didn't broke recently, let me check
[06:45] <zyga> I don't see the extra variable that points to /var/lib/snapd/desktop
[06:46] <morphis_> ah!
[06:46] <morphis_> could have been that I fixed that locally but never pushed the fix
[06:46] <morphis_> actually this works pretty well on Fedora
[06:47] <morphis_> zyga: I wonder if the profile.d handling is different or has changed
[06:47] <zyga> morphis_: what do you have in /etc/profile.d?
[06:48] <zyga> I have snapd.sh that has one line (except comments): PATH=$PATH:/snap/bin
[06:48] <morphis_> powering up my suse VM, on Fedora I have what should be there
[06:48] <zyga> the 65snappy Xsession thing is not around
[06:48] <luk3yx> Why doesn't snapcraft put .desktop files in correctly?
[06:49] <zyga> luk3yx: no idea, sorry
[06:49] <luk3yx> Okay.
[06:51] <morphis_> zyga: the interesting thing is that the same file on Fedora has the proper XDG_DATA_DIRS vars set
[06:51] <zyga> morphis_: separate file
[06:51] <morphis_> nope
[06:51] <zyga> morphis_: I think we don't have one thing across the trees
[06:51] <morphis_> /etc/profile.d/snapd.sh sets XDG_DATA_DIRS on Fedora
[06:51] <zyga> morphis_: look at etc/X11 in the source tree
[06:51] <zyga> right
[06:52] <zyga> because that's not the same file
[06:52] <morphis_> on Suse it doesn't
[06:52] <zyga> in the source tree we have two files
[06:52] <zyga> and in Fedora we use entirely different one (because /snap I suspect)
[06:52] <morphis_> http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd.spec#n421
[06:52] <zyga> morphis_: exactly
[06:52] <zyga> morphis_: and on ubuntu/debian/suse we take etc from the source package
[06:52] <zyga> see?
[06:53] <morphis_> that is nasty, we should't differentiate what is in these files across distros
[06:53] <zyga> I think it is also somewhat incorrect, that's why we did it this way
[06:53] <zyga> someone reported a bug on XDG_DATA_DIRS, let me try to find it
[06:54] <morphis_>  /etc/x11/XSession.d isn't support on Suse as it seems
[06:54] <zyga> I can only find https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1554563
[06:54] <mup> Bug #1554563: Please support /var/lib/snappy/desktop as an additional desktop directory <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1554563>
[06:54] <zyga> yeah, I see
[06:55] <morphis_> ah it's /etc/X11/xinit/xinitrc.d/ instead
[06:55] <zyga> heh
[06:55] <zyga> shall I prepare a patch?
[06:56] <morphis_> I am on it already
[06:57] <zyga> this is what I made
[06:58] <zyga> https://paste.opensuse.org/30238446
[06:59] <abeato> zyga, hey, mind taking a look when possible at https://github.com/snapcore/snapd/pull/3353 ?
[06:59] <mup> PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>
[06:59] <zyga> abeato: yes, certainly
[06:59] <zyga> well
[06:59] <zyga> not mind :)
[06:59] <morphis_> zyga: yeah, same here
[06:59] <abeato> :)
[07:00] <zyga> abeato: can you please ensure that every if / else uses braces fully
[07:01] <abeato> zyga, also one-liners?
[07:01] <zyga> yes
[07:01] <abeato> ok
[07:04] <zyga> thank you, sorry for the nitpick but this is the coding style we're using everywhere else
[07:07] <abeato> zyga, done
[07:07] <morphis_> zyga: btw. there will be a blog post later this week telling about working lxd/docker on Suse/Fedora
[07:07] <abeato> zyga, sure, I had not noticed
[07:07] <zyga> abeato: thank you, looking
[07:08] <zyga> morphis_: nice, thank you :)
[07:09] <zyga> abeato: looks nice, I'll comment in a sec
[07:09] <abeato> zyga, great
[07:19] <morphis_> zyga: btw. what do you think about doing an Ubuntu Testing day for snaps on Fedora/Suse?
[07:23] <zyga> morphis_: I think this is a good idea
[07:23] <zyga> morphis_: we could do a converged one for a few distributions
[07:23] <morphis_> then let me organize that
[07:23] <morphis_> yes!
[07:23] <zyga> morphis_: but only those under CI today
[07:23] <zyga> we can split responsibilities
[07:23] <zyga> I can show suse (natively) and fedora (natively)
[07:24] <morphis_> what means natively?
[07:24] <morphis_> in a non-vm environment?
[07:24] <zyga> running on metal
[07:24] <zyga> yes
[07:24] <zyga> I shun VMs recently
[07:24] <zyga> because we're mot using them daily for real stuff
[07:24] <zyga> just for fire&forget
[07:25] <zyga> (e.g. the desktop issue)
[07:27] <zyga> mvo: hey
[07:28] <zyga> mvo: did you see  PR 3410
[07:33] <mup> PR snapcraft#1320 closed: store: send X-Ubuntu-Series, not X-Ubuntu-Release <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1320>
[07:36] <mup> PR snapcraft#1336 closed: HACKING: make running from virtualenv more obvious <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1336>
[07:37] <mvo> zyga: yeah, I noticed it, need to look in detail, was a bit distracted with the other things going on
[07:39] <mup> PR snapcraft#1300 closed: tools: add a script to install autopkgtest dependencies <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1300>
[07:48] <zyga> morphis_: hmm,not sure what happened
[07:48] <morphis_> yeah, not sure too
[07:49] <zyga> oh man
[08:00] <zyga> morphis_: can you hear me?
[08:00] <zyga> morphis_: seems like google hangouts armageddon
[08:05]  * zyga does code reviews
[08:05] <zyga> mvo: please pull me out of this if you need my help with release blockers
[08:09] <NicolinoCuralli> hi all: i need to delete a snap  in  brand store : who can help me?
[08:34] <kyrofa> Hey zyga, did you solve the snap-confine in lxc issue?
[08:34] <zyga> kyrofa: nope, I didn't have time to explore that yet
[08:36] <kyrofa> zyga, huh... you may not need to. I just updated a few different containers to 2.25 now (snap-confine also updated) and things seem to be working
[08:36] <zyga> oh, that's good news :)
[08:37] <morphis_> zyga: https://build.opensuse.org/request/show/500035
[08:37] <zyga> sorry for being passive about that, I think it will only be fixed once I actively try LXD and we have CI
[08:37] <zyga> morphis_: approved, thank you
[08:39] <kyrofa> zyga, yeah we really need lxd in CI
[08:40] <morphis_> zyga: had to use /etc/profile.d in the end but it works now
[08:41] <zyga> morphis_: what happend when you tried xinitrd.d?
[08:41] <zyga> morphis_: just wasn't picked up?
[08:41] <zyga> or didn't export the environment back to other processes?
[08:41] <morphis_> zyga: yes
[08:42] <morphis_> it wasn't loaded for the DE nor for any shell
[08:42] <morphis_> so not picked up at all
[08:44] <NicolinoCuralli> hi all: i have some difficulties with review process in the brand store : can someone help me ?  I don't find on the store the place where paste the Snap declarations
[09:02] <abeato> ogra_, hey, I had to do a small correction in https://github.com/snapcore/core-build/pull/13
[09:02] <mup> PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
[09:02] <abeato> (see last commit)
[09:03] <ogra_> abeato, approved ... how could i miss that!
[09:04] <abeato> :)
[09:04] <abeato> ogra_, do we need some other approval or is it ready to be merged?
[09:04] <ogra_> abeato, you need two people to approve
[09:04] <NicolinoCuralli> hi guys : someone can help me to find the person tha can help me to solve my problem?
[09:04] <abeato> ogra_, ok, who do I need to annoy? ;)
[09:05] <ogra_> abeato, dunno ... someone from the snapd core team
[09:05] <abeato> ogra_, maybe mvo? https://github.com/snapcore/core-build/pull/13 ? :)
[09:05] <mup> PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
[09:07] <mvo> abeato: sure, I have a look
[09:07] <abeato> mvo, thanks!
[09:08] <mvo> zyga: re release> after a bit of thinking I will just revert the syntax change and the new symbols and go ahead with only that, then we are not under pressure for the profile-digest changes
[09:09] <zyga> OK
[09:10] <mvo> zyga: I also played a bit more with seccomp->bpf and ran into a strange apparmor/seccomp interation. when I load the bpf directly and run e.g. hello I get an EPERM when execve(snap-exec). however when I unload the apparmor profile of snpa-confine this is gone, syslog has something that looks like an oops from paparmor
[09:10] <zyga> log?
[09:11] <zyga> mvo: did you change the moment when you load the profile in snap-confine?
[09:11] <zyga> note that seccomp applies instantly
[09:11] <mvo> zyga: sure, here is the log http://paste.ubuntu.com/24724666/
[09:12] <zyga> mvo: which kernel was this on?
[09:12] <mvo> zyga: and the full branch (slightly long and unfinished) https://github.com/snapcore/snapd/compare/master...mvo5:seccomp-bpf?expand=1 - the key is sc_apply_seccomp_bpf(security_tag);
[09:12] <mvo> zyga: 4.4.0-78
[09:12] <zyga> hmm
[09:12] <mvo> zyga: do you think I should try a different one?
[09:13] <zyga> no, the kernel looks fine
[09:13] <mvo> zyga: the profile is loaded at the same point as the old sc_load_seccomp_context(seccomp_ctx);
[09:13] <mvo> zyga: whats puzzling is that its apparmor, the execve from seccomp would get killed (SIGSYS) but I get a EPERM
[09:15] <mvo> zyga: I guess I wait for jamie to see if he has some ideas
[09:16] <zyga> mvo: just curious, the sc_prepare_seccomp_context no longer does anything, right?
[09:16] <zyga> mvo: note that the code is structured in a specific way
[09:16] <mvo> zyga: I still made it prepare everything so that I can dump the content and compare the diff between the new and the old code
[09:16] <zyga> mvo: so when you load the profile you can still, afair, do more things, when we apply it it is too late to some things
[09:16] <mvo> zyga: oh, interessting
[09:16] <zyga> this is why those were split
[09:17] <zyga> not sure if this would explain the WARN you saw
[09:17] <zyga> jjohansen: ^^ you want to look at http://paste.ubuntu.com/24724666/
[09:18] <mvo> zyga: interessting idea, I can play a bit and see if moving things around makes a difference
[09:18] <zyga> mvo: honestly, I'd love to hack on this
[09:18] <mvo> zyga: I will first try a newer kernel just to see if it makes a difference
[09:18] <zyga> mvo: but if you want to do it then feel free :)
[09:18] <mvo> zyga: go ahead
[09:18] <zyga> mvo: I need to review PRs and apply feedback first
[09:18] <mvo> zyga: the branch is https://github.com/snapcore/snapd/compare/master...mvo5:seccomp-bpf?expand=1
[09:18] <zyga> mvo: but I can do some more hacking in the evening
[09:19] <zyga> did you see the hotfix PR by any chance?
[09:19] <mvo> zyga: yeah, its a fun and fascinating project. I need to also go and do the boring stuff now (cherry pick, release)
[09:21] <mvo> zyga: yeah, its a good idea - did you already describe in the forum how the poor souls on r1968 can get out of it?
[09:24] <zyga> mvo: no not yet, I wanted to get your feedback first
[09:25] <zyga> mvo: one thing I was thinking of is make periodic releases of the hotfix tool (only for developers using edge)
[09:25] <zyga> mvo: and to patch it a little more to be double-click-foolproof, just run it and it applies all hotfixes
[09:26] <Chipaca> pedronis`: snapd#3400 is ready for your perusal if you have a bit
[09:26] <mup> PR snapd#3400: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <https://github.com/snapcore/snapd/pull/3400>
[09:29] <mup> PR snapd#3414 opened: tests: show available entropy on error <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3414>
[09:29] <Chipaca> NicolinoCuralli: what is your problem?
[09:34] <NicolinoCuralli> chicapa: I need to upload the snap declaration for a snap under review on my brand store
[09:36] <zyga> morphis_: two more issues on suse
[09:36] <zyga> Failed to try-restart snapd.autoimport.service: Unit snapd.autoimport.service not found.
[09:36] <zyga> Failed to try-restart snapd.system-shutdown.service: Unit snapd.system-shutdown.service not found.
[09:36] <zyga> and earlier
[09:36] <zyga> Failed to preset unit: File snapd.autoimport.service: No such file or directory
[09:36] <zyga> Failed to preset unit: File snapd.system-shutdown.service: No such file or directory
[09:37] <morphis_> zyga: we don't install these service units anymore
[09:37] <morphis_> so what is starting it?
[09:37] <zyga> yes but something presets them
[09:37] <zyga> they are in systemd_services_list
[09:37] <morphis_> ah I see
[09:37] <zyga> in the spec file
[09:37] <zyga> we should drop the two
[09:37] <zyga> I can do that if you want, I already have it open
[09:39] <zyga> building locally to test
[09:42] <morphis_> zyga: please!
[09:42] <zyga> we need snap install pastebinit :)
[09:42] <zyga> there's no pastebinit on tumbleweed
[09:43] <zyga> oh, but there is susepaste and susepaste-screenshot
[09:43] <zyga> I'm especially intrerested in the screenshot paste :)
[09:44] <zyga>    http://paste.opensuse.org/71458123
[09:44] <zyga> morphis_: ^ looks ok?
[09:44] <morphis_> yes
[09:51] <pedronis> Chipaca: when I have processed the fact that all the spread runs I start fail for some random reason
[09:53] <Chipaca> pedronis: spread's just envious of your awesomeness
[09:55]  * zyga is drunk today, sorry for silly comment on 3400
[09:57]  * Chipaca hugs zyga
[09:57] <mvo> zyga: btw, do you know more about "cannot create lock directory /run/snapd/lock: Permission denied" yet? we see this a lot in the error tracker
[09:57] <Chipaca> zyga: i'm assuming you're not _actually_ drunk
[09:57] <zyga> no, not actually
[09:58] <zyga> mvo: no, still no idea what is going on there
[09:58] <zyga> mvo: how can I get error tracker data?
[10:00] <mvo> zyga: errors.ubuntu.com has a lot of it, .e.g https://errors.ubuntu.com/problem/19272ebc18709d4407dba0438a536d56bb143069
[10:00] <mvo> zyga: there might be a form to fill in to get access (if you have not done so already) to the details
[10:01]  * zyga looks at http://susepaste.org/10525636 and sighs :/
[10:01] <zyga> looking
[10:01] <mvo> zyga: this one has 5k occurances last week
[10:01] <zyga> mvo: how did you find this, I mean, how to "get started"?
[10:02] <mvo> zyga: start from https://errors.ubuntu.com/ - it takes a bit to load the data, then in the top-5 you will see some "snap install" related ones
[10:02] <zyga> aha, let me try that
[10:02] <mvo> zyga: the top one is the one I just linked to
[10:03] <zyga> classic confinement, hmm
[10:03] <zyga> still, should not impact anything
[10:04] <mup> PR snapd#3397 closed: interfaces: disable "mknod |N" in the default seccomp template again <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3397>
[10:07] <zyga> mvo: question about this report, looking at https://errors.ubuntu.com/oops/2af7141c-45e8-11e7-9188-fa163e839e11 I see snapd version 2.25, is that the real version of the snapd being executed or the one installed via classic package?
[10:08] <mvo> zyga: that is the one running, the host and core versions are available via the build-id
[10:08] <joc> morphis_: would appreciate if you could look at getting that udisksctl auto alias setup soonish, we have test runs that would like it available
[10:11] <mup> PR snapd#3415 opened: interfaces: revert "interfaces: re-add reverted ioctl and quotactl <Created by mvo5> <https://github.com/snapcore/snapd/pull/3415>
[10:13] <pedronis> Chipaca: added some comments
[10:14]  * Chipaca reads
[10:15] <zyga> morphis_: so, the overlordSuite.TestEnsureLoopPrune test never passes for me
[10:15] <zyga> morphis_: hmm, wonder if this related to multi-core build host vs single-core VM
[10:16] <zyga> morphis_: I'll commit and let OBS do the build
[10:17] <mvo> a review for #3415 would be great. it will unblock 2.26/2.27
[10:18] <zyga> approved
[10:19] <mvo> ta
[10:19]  * mvo just needs tests now
[10:19]  * mvo just needs to wait for tests now
[10:20] <Chipaca> pedronis: "the store offered snap revision" sounds like it returns a revno. "the store offered snap revision snap info" sounds like chickenspeak. "the store offered snap"?
[10:22] <Chipaca> currently best phrasing i have is “// LookupRefresh returns a snap's store-offered revision information given its refresh candidate.”
[10:24] <pedronis> mvo: test are super flaky, I had zero happy runs since yesterday, maybe is just me though
[10:25] <mvo> pedronis: autsch, that does not sound encouraging
[10:25] <mvo> pedronis: thank you, I will know in some minutes
[10:26] <mup> PR snapd#3373 closed: snapstate: consider connect/disconnect tasks in CheckChangeConflict <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3373>
[10:26] <pedronis> I had one now after tentative N+
[10:27] <pedronis> Chipaca: sounds ok
[10:27] <pedronis> (all things considered)
[10:29] <pedronis> mvo: could you push master into snapd#3385 again,  that's other one I'm trying to see pass, maybe pushing master helps
[10:29] <mup> PR snapd#3385: cmd: add stub new snap-repair command and add timer <Created by mvo5> <https://github.com/snapcore/snapd/pull/3385>
[10:33] <morphis_> zyga: in OBS?
[10:33] <morphis_> zyga: didn't checked that yet but I have just a single core on my vm too, works well here
[10:34] <pedronis> Chipaca: thx, did you see my question about the error?  also I pmed you
[10:35] <Chipaca> i didn't see your question about the error
[10:35] <Chipaca> pedronis: where was that question?
[10:41] <morphis_> Pharaoh_Atem: ping
[10:44] <pedronis> Chipaca: it was a comment attached to some other comments to some code that was changed
[10:44] <mvo> pedronis: sure, pushed 3385
[10:44] <Chipaca> pedronis: about the snap name and real name not aligning?
[10:45] <Chipaca> local vs real i mean
[10:45] <pedronis> yes
[10:45] <Chipaca> pedronis: i replied to that, i think?
[10:46] <Chipaca> pedronis: basically, yes it's used and shown to the user
[10:46] <Chipaca> pedronis: (but that's not something this branch introduces?)
[10:46] <pedronis> don't we have the local name around when we show it though?
[10:46] <pedronis> Chipaca: yes, but moving around where it error is created changes which name we use
[10:47] <pedronis> that's why I'm bothering you :)
[10:47] <pedronis> you need to look at the diff I suppose
[10:47] <pedronis> I mean master vs your branch
[10:48] <pedronis> mvo: thanks, let's how it goes
[10:48]  * pedronis -> lunch
[10:52] <Chipaca> so yes i move it from snapstate, using curInfo.Name() (which for from-the-store snaps is the RealName, ie the store name) to store using latest[0].Name, so the only case where they'd differ is if a snapid gets renamed
[10:53] <pstolowski> zyga, hey. it seems that we always use /usr/bin/snapctl from the core snap no matter what. am I right / is it expected?
[11:12] <zyga> re
[11:12] <zyga> morphis_: yes, I think it just fails on multi-core systems
[11:13] <zyga> pstolowski: snapctl is always used (except classic) after we pivot_root so yes
[11:13] <morphis_> zyga: ah you think it fails on multi-core thought somehow you mean the other way round
[11:13] <pstolowski> zyga, thanks.. ok, this explains my issues with renaming of SNAP_CONTEXT
[11:14] <zyga> morphis_: and it failed in OBS now
[11:14] <zyga> https://build.opensuse.org/package/live_build_log/system:snappy/snapd/openSUSE_Tumbleweed/x86_64
[11:14] <zyga> pstolowski: ha, interesting
[11:14] <zyga> pstolowski: just bind-mount it into core snap
[11:15] <zyga> pstolowski: although we repack the core snap so not sure why you are seeing this
[11:15] <morphis_> zyga: wait, you pushed to the system repository without testing?
[11:15] <zyga> morphis_: I tested it but it took many builds to pass
[11:16] <zyga> morphis_: since this is a trivial patch on top of existing working build I didn't expect it could be any worse
[11:16] <morphis_> actually we should always go via an review request, that way we can verify it builds on all archs + systems
[11:16] <zyga> morphis_: well, it is randomly failing because that test is racy
[11:16] <Chipaca> pedronis: WRT the error, can I address it in a followup branch? doing it properly touches cmd/snap more than i'd like to in this one
[11:17] <zyga> morphis_: and the failure has nothing to do with the change at hand
[11:17] <zyga> morphis_: maybe we just get better build VMs now :/
[11:18] <zyga> morphis_: I re-triggered the build
[11:18] <morphis_> I see, was just looking at the log file
[11:19] <zyga> morphis_: it's the same failure I mentioned before and the one we fixed in master some time ago
[11:19] <zyga> morphis_: but apparently the fix was wrong as it also fails in travis very often
[11:20] <pstolowski> zyga, hmm indeed I see this is done in prepare.sh. ok  let me verify if this is working
[11:20] <zyga> pstolowski: maybe we just don't copy snapctl
[11:22] <pstolowski> zyga, we do
[11:22] <zyga> so there must be something else at play
[11:24] <zyga> morphis_: it worked on retry
[11:27] <pstolowski> zyga, ok. confirmed. whatever we think we do in prepare.sh is not working for snapctl when I run spread test with qemu ;)
[11:27] <pstolowski> qemu:ubuntu-16.04-64 /root# md5sum /usr/bin/snapctl /snap/core/current/usr/bin/snapctl
[11:27] <pstolowski> 67d600f14953d72a8440e0d90a93abc4  /usr/bin/snapctl
[11:27] <pstolowski> 5ac1e109e0dd434d5141b9ad52b20f3f  /snap/core/current/usr/bin/snapctl
[11:27] <zyga> pstolowski: let me look
[11:27] <morphis_> zyga: good
[11:28] <zyga> pstolowski: https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L46
[11:28] <pedronis> Chipaca: it's ok
[11:29] <zyga> pstolowski: and also https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L74
[11:29] <zyga> pstolowski: this gets called from https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L94
[11:29] <zyga> pstolowski: hmm hmm hmm, no idea
[11:29] <zyga> pstolowski: how are you running your test exactly?
[11:30] <pstolowski> zyga, uh oh the tests I'm using do not call prepare.sh
[11:31] <zyga> pstolowski: oh? why? where are your tests?
[11:31] <zyga> pstolowski: this is typically done at suite level
[11:31] <pstolowski> zyga, well, existing one - e.g. main/snap-set
[11:31] <pstolowski> zyga, at least no explicit call to prepare.sh
[11:32] <zyga> pstolowski:  https://github.com/snapcore/snapd/
[11:32] <zyga> pstolowski: they do, or your spread is old/weird/broken
[11:32] <morphis_> zyga: but what change we submit we should always go through a review request for suse
[11:32] <morphis_> otherwise we may break existing installations
[11:33] <zyga> morphis_: sure, I didn't do it because I didn't have a branch and I showed you the diff to ack
[11:33] <morphis_> yeah
[11:34] <pstolowski> zyga, ah, it's called from spread.yaml, that's ok then. i got confused by one of the other tests (extra-snap-assertions) which calls prepare.sh directly
[11:40] <zyga> brb
[11:41] <pstolowski> zyga, anyway... I run a single test like this: spread -debug qemu:ubuntu-16.04-64:tests/main/snap-set and clearly the snapctl in the core is different from the one from /usr/bin
[11:42] <zyga> morphis_: so....
[11:43] <zyga> morphis_: on re-logout neither snapd.sh nor snapd-xdg.sh do stuff
[11:43] <zyga> morphis_: /snap/bin is not in path
[11:43] <morphis_> you have reboot
[11:43] <zyga> ah, the X session holds this too?
[11:43] <zyga> ok
[11:43]  * zyga reboots then :)
[11:44] <pstolowski> zyga, anyway... I run a single test like this: spread -debug qemu:ubuntu-16.04-64:tests/main/snap-set and clearly the snapctl in the core is different from the one from /usr/bin
[11:45] <zyga> morphis_: indeed, now it works perfectly!
[11:46] <morphis_> not sure how suse configures this but XDG_DATA_DIRS was filled with /var/lib/snapd/desktop and PATH with /snap/bin
[11:46] <zyga> morphis_: the snapd-xdg.sh file is +x while all the other files there are not
[11:46] <morphis_> hm
[11:46] <morphis_> should be 644, I agree
[11:46] <zyga> morphis_: but it doesn't hurt
[11:46] <zyga> morphis_: I think snapd on suse is really good now
[11:46] <morphis_> yeah, will fix that later when I can power up my suse vm again
[11:46] <morphis_> zyga: one thing is missing
[11:46] <zyga> yeah?
[11:46] <zyga> xdg-open
[11:46] <morphis_> cleanup of /var/lib/snapd on removal
[11:47] <zyga> ah, interesting
[11:47] <zyga> yep, we should use the management script and just make it better
[11:47] <morphis_> naah, xdg-open is missing everywhere but Ubuntu :-)
[11:47] <zyga> and use it on all the distributions
[11:47] <morphis_> zyga: yes
[11:47]  * zyga installs docker
[11:47] <morphis_> was ping'ing Pharaoh_Atem this morning as he wanted to generalize it but if he doesn't has time I can do that
[11:48] <zyga> morphis_: sounds good
[11:53] <Son_Goku> morphis_: moo?
[11:54] <morphis_> Son_Goku: hey!
[11:54] <morphis_> Son_Goku: just talked with zyga about snap-mgmt.sh, do you want to generalize it or should I?
[11:54] <Son_Goku> I want it perfectly working first :)
[11:55] <morphis_> Son_Goku: one thing missing before we reach that goal :-)
[11:55] <Son_Goku> I'm still fine-tuning the script
[11:55] <Son_Goku> I'm nearly there, and then we can work generalizing
[11:55] <Son_Goku> err, work on generalizing it
[11:55] <morphis_> Son_Goku: good
[11:56] <Son_Goku> I expect that we can start generalizing next week
[11:56] <Son_Goku> as I'll take care of the last wibbles in the script and packaging this weekend
[11:56] <Son_Goku> at the latest :D
[11:57] <morphis_> nice!
[12:06] <zyga> morphis_: docker works but adduser/addgroup vs useradd groupadd is an issue, we should fix this eventually
[12:06] <morphis_> zyga: who calls these?
[12:06] <zyga> morphis_: the user is instructed to
[12:07] <morphis_> for the docker snap?
[12:07] <morphis_> you can but you also can simply run the docker command via sudo
[12:08] <Son_Goku> the modern debian addfoo commands have never been ported outside of the distribution
[12:09] <Son_Goku> interestingly, I think debian is the upstream for shadow-utils
[12:13] <zyga> anyway, it will go away once snapd does user management
[12:13] <Son_Goku> you scare me with phrases like that
[12:13] <Son_Goku> "user management"?
[12:13] <Son_Goku> snapd will replace shadow-utils too?
[12:13] <zyga> no, it will just create service accounts like the one for docker
[12:13] <zyga> better than asking users to follow instructions :)
[12:13] <Son_Goku> oh, so there'll be a snappy user for this
[12:14] <zyga> Son_Goku: yes, most likely a specific one
[12:14] <zyga> there's a writeup about this ...
[12:14] <Son_Goku> we'll probably want the uid + gid reserved in Fedora
[12:14] <zyga> https://forum.snapcraft.io/t/snappy-and-users-and-groups/331
[12:14] <Son_Goku> that way it's sane across the board
[12:14] <zyga> but brace yourself
[12:14] <zyga> that's a long read
[12:15] <Son_Goku> holy crap
[12:15] <Son_Goku> I'll need to bookmark this
[12:15] <Son_Goku> jdstrand, damn, you wrote a lot...
[12:18] <Saviq> kalikiana, https://code.launchpad.net/~saviq/snapcraft/+git/snapcraft/+merge/324856
[12:19] <zyga> mvo: is did you see the lock directory issue on any of your machines?
[12:25] <morphis_> zyga: btw. if you didn't saw it yet: https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory#How_to_add_a_new_package_to_Factory
[12:27] <zyga> morphis_: if system:snappy counts as a devel project then we're very close
[12:27] <morphis_> zyga: right
[12:39] <morphis_> zyga: I think for factory inclusion we should better have the snap-mgmt.sh script included
[12:39] <morphis_> otherwise package removal is pretty dirty
[12:39] <morphis_> so let me add that this evening
[12:42] <zyga> morphis_: yes, I agree
[12:42] <zyga> morphis_: sounds good
[12:42] <zyga> hmm
[12:43] <zyga> github died
[12:43] <zyga> "major service outage"
[12:43] <zyga> well
[12:43] <morphis_> yeah
[12:46] <Son_Goku> zyga: you need to request it to be added as a devel project
[12:46] <Son_Goku> it must be specially marked for Factory
[12:47] <Son_Goku> otherwise the bot will reject the SRs
[12:47] <Son_Goku> talk to DimStar in #opensuse-factory about figuring out the process to that
[12:48] <Son_Goku> though really, now that snapd is only one package, you can move it into system:packagemanager and avoid the mess entirely
[12:48] <Son_Goku> err, one source package
[12:50] <zyga> Son_Goku: what is system:packagemanager? some blessed devel repo?
[12:50] <Son_Goku> yes
[12:50] <zyga> Son_Goku: I think we could just get system:snapd tagged this way
[12:50] <zyga> how can we check if it is tagged or not?
[12:50] <Son_Goku> well, system:snappy
[12:50] <zyga> (right)
[12:50] <Son_Goku> there's a whitelist somewhere, lemme check
[12:53] <zyga> Son_Goku: thanks, how do you know those things? :)
[12:53] <Chipaca> spread from travis is really having a bad day today :-(
[12:53] <zyga> Chipaca: github is down
[12:54] <Chipaca> this might explain things
[12:54] <Son_Goku> zyga, with the extremely notable exception of Debian and Ubuntu, I'm involved in all major Linux distributions
[12:54] <Chipaca> quick, move everything back to launchpad while nobody is looking
[12:54]  * Son_Goku stabs Chipaca with a fork
[12:54] <kyrofa> Gaaaaah giiiithuuuub
[12:54]  * Son_Goku runs and whistles
[12:54] <Son_Goku> kyrofa: this is why you have a replica project on GitLab :)
[12:54] <zyga> aaaand its back
[12:55] <Son_Goku> fwiw, it was never down for me
[12:55] <Son_Goku> apparently, only down in the European side
[12:55] <zyga> Son_Goku: look at status.github.com
[12:55] <kyrofa> Liar. It works every other refresh. Some presentation nodes
[12:56] <zyga> well they sure lost their 5-9s
[12:56] <kyrofa> Five? Hahaha
[12:57] <zyga> soon they will have 9-5s
[12:57] <kyrofa> Their API is 95%
[12:57] <Chipaca> they totally have 9 9s
[12:57] <zyga> yeah, I'm watching the same page
[12:57] <Chipaca> 0.999999999
[12:57] <zyga> LOL
[12:57] <cjwatson> I once briefly worked on software that required six nines
[12:57] <cjwatson> That was interesting
[12:58] <zyga> cjwatson: was it changed (the software)?
[12:58] <cjwatson> Very carefully :-)
[12:58] <cjwatson> telco stuff
[12:58] <Chipaca> I love that we can build stuff to that spec
[12:58] <zyga> I wonder how that must work and be like
[12:58] <cjwatson> hot failover EVERYWHERE
[12:58] <Chipaca> I hate what we apparently have to do to get there
[12:58] <zyga> how doyou learn by making mistakes?
[12:59] <zyga> aha
[12:59] <zyga> so you can still
[12:59] <zyga> interesting
[12:59] <Chipaca> zyga: you do that part on somebody *else's* telco
[12:59] <cjwatson> you get 30 seconds a year of downtime so you don't have time to boot anything
[12:59] <cjwatson> at least not much
[12:59] <mvo> zyga: no, the lock directory issue I have not seen myself, just from errrors.u.c
[13:00] <zyga> thanks
[13:00] <zyga> I'm still exploring it
[13:01] <elopio> mpt: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1555569
[13:01] <mup> Bug #1555569: [snaps] Show human-readable names for store apps <gnome-software> <sdoc> <Snappy:New> <Software Center Agent:Fix Released> <gnome-software (Ubuntu):Triaged> <https://launchpad.net/bugs/1555569>
[13:03] <mup> PR snapcraft#1337 opened: autotools: don't force uniqueness on configflags <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/1337>
[13:03] <Saviq> kalikiana, or rather ↑
[13:36] <mvo> pedronis: 3385 should be ready now btw
[13:49] <pedronis> mvo: I saw that, will merge it in a bit
[13:50] <mvo> pedronis: thanks
[13:53] <zyga> I have an idea why the lock thing is exploding
[13:53] <zyga> \o/
[13:57] <zyga> mvo: I think this is another race
[13:57] <zyga> mvo: running a scenario to confirm now
[13:58] <Son_Goku> zyga, there's a few fixes I need to submit to the snapd package on openSUSE
[13:58] <Son_Goku> so I'll prepare those tomorrow
[13:58] <Son_Goku> I won't have any time today
[13:58] <zyga> Son_Goku: sure, what kind of fixes?
[13:58] <Son_Goku> conditional checks for BRs and stuff
[13:58] <zyga> Son_Goku: no worries, we wanted to prepare to submit to factory
[13:59] <zyga> BRs?
[13:59] <Son_Goku> BuildRequires
[13:59] <zyga> sure, thank you
[13:59] <zyga> Son_Goku: but we can do that after your patches are merged
[13:59] <Son_Goku> yes
[14:00] <Son_Goku> wait what?
[14:00] <Son_Goku> what patches?
[14:00] <Son_Goku> to snap-mgmt.sh, you mean?
[14:00] <zyga> Son_Goku: well the fixes you just mentioned
[14:00] <Son_Goku> well, I think I already branched snapd from system:snappy
[14:38] <mup> PR snapcraft#1328 closed: qmake plugin: set default qt version <Created by tim-sueberkrueb> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1328>
[14:52] <pstolowski> zyga, ok, the problem with prepare.sh is that we first install new core from edge, and that already fails on configure hook (because of changes to snapd and changes to snapctl which are not in effect yet) and makes prepare.sh fail before we have a chance to re-pack core with new binaries. so it's not actually the test failing, but prepare.sh very early on.
[14:52] <cachio> niemeyer, mvo, ziga, As I cant reproduce the openvswitch error from my machine, is it ok if I create a test PR to run it from travis to get more information about the error?
[14:53] <cachio> niemeyer, mvo, ziga, afaik it is getting stuck trying to create the db
[14:54] <Chipaca> kyrofa: are you at the sprint?
[14:54] <zyga> pstolowski: interesting
[14:54] <zyga> pstolowski: we should download core then, not install it
[14:54] <zyga> cachio: fine with me
[14:55] <pstolowski> zyga, indeed
[15:03] <mup> PR snapd#3416 opened: DONT REVIEW - Adding debug information to test interfaces-openvswitch <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3416>
[15:04] <kyrofa> Chipaca, yessir, what's up?
[15:08] <Chipaca> kyrofa: I hadn't realised you guys would be in london :-) was wondering if you were doing anything this eve
[15:09] <kyrofa> Chipaca, nope
[15:09] <kyrofa> Chipaca, want to?
[15:09] <Chipaca> kyrofa: it doesn't sound like a bad idea
[15:09] <kyrofa> Chipaca, it indeed sounds relatively acceptable
[15:10] <Chipaca> all things considered etc
[15:10] <kyrofa> Chipaca, how close do you live?
[15:12] <Chipaca> kyrofa: an hour away, approx
[15:13] <Saviq> kyrofa, https://travis-ci.org/snapcore/snapcraft/builds/237914554?utm_source=github_status&utm_medium=notification
[15:13] <kyrofa> Chipaca, want do you want to do? Come in here, stay out there?
[15:14] <Chipaca> kyrofa: i think i'll be going in, in a bit
[15:14] <Chipaca> i'll have to find my bluefin pass! :-)
[15:14] <kyrofa> Chipaca, awesome. That's a bit of a trip though, you're welcome to crash if you like
[15:16] <ogra_> slangasek, why is the ubuntu-image deb trying to loop mount img files ? i thought it would not require any privieged actions anymore
[15:20] <slangasek> ogra_: because you have a version of e2fsprogs that's too old to let it populate a filesystem at creation time
[15:20] <ogra_> oh, thats still broken in 16.04 because e2fslibs wasnt fixed :/
[15:20] <ogra_> slangasek, yeah :(
[15:21] <ogra_> i thought that was supposed to have been SRUed long ago
[15:30] <slangasek> ogra_: absolutely not, that's a new major upstream version of e2fsprogs with behavior changes
[15:30] <ogra_> hmpf, k
[15:31] <pstolowski> zyga, if I don't install core in prepare and only download & modify+repack, it needs to be installed with --dangerous; is this a problem for our testing?
[15:32] <zyga> pstolowski: not sure, perhaps yes
[15:32] <zyga> pstolowski: I assume that we check the signature right?
[15:32] <ogra_> boo
[15:32] <zyga> pstolowski: and you cannot just ack the assertion
[15:32] <zyga> pstolowski: and install it?
[15:32] <ogra_> root@11f68f46633c:/# /snap/bin/htop
[15:32] <ogra_> cannot perform operation: pivot_root /tmp/snap.rootfs_CYPssc /tmp/snap.rootfs_CYPssc//var/lib/snapd/hostfs: Operation not permitted
[15:33] <ogra_> (having snap and snapd running inside docker lets you install and remove snaps ... but you cant run them)
[15:33] <zyga> ogra_: missing patches I think
[15:33] <zyga> ogra_: can you show me the denial?
[15:34] <ogra_> zyga, i dont think i can ... apparmor is off in that container
[15:34] <pstolowski> zyga, what do you mean by acking the assertion? I think I need to ignore it and force dangerous, as checksum will not match anymore? we got away with it because prepare unmount and remounts it after installed
[15:34] <kyrofa> Chipaca, think you'll be here around dinner time-ish?
[15:34] <Chipaca> kyrofa: are you guys at bluefin?
[15:34] <ogra_> zyga, i doubt it is apparmor related, ratther docker itself
[15:34] <kyrofa> Chipaca, yes
[15:34] <zyga> ogra_: and in the outside? apparmor is really a kernel-wide thing
[15:35] <zyga> ogra_: I disagree, this looks like apparmor
[15:35] <Chipaca> kyrofa: i could aim to be there at 6pm, or I could aim for later if you want to go back to the hotel and such
[15:35] <zyga> pstolowski: snap akc
[15:35] <zyga> darn :)
[15:35] <zyga> snap *ack*
[15:35] <fgimenez_> morphis_: it seems that during this test reexec was disabled on debian https://travis-ci.org/snapcore/snapd/builds/235819260#L2936 i've seen this in several executions, have you found this kind of error before?
[15:35] <zyga> pstolowski: but without the assertion the samantics is not the same in some places
[15:35] <mup> PR snapd#3415 closed: interfaces: revert "interfaces: re-add reverted ioctl and quotactl <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3415>
[15:36] <ogra_> zyga, and indeed you are right ... http://paste.ubuntu.com/24727427/
[15:36] <kyrofa> Chipaca, or we can do BOTH
[15:37] <zyga> ogra_: oh very interesting
[15:37] <kyrofa> Chipaca, no need to go back to the hotel, come whenever you think you'll be hungry
[15:37] <mvo> fgimenez_: is it reasonable straightfroward for you to test if current master is fixed with regards for the snap revert test that caused the network-manager regression? if so, could you please trigger a test?
[15:37] <pstolowski> zyga, I know... thus the question about affecting the tests.. anyway. i think I have a simple workaround (setting both new and old var in hookmgr) which is needed anyway for transition. no need to modify prepare then
[15:37] <zyga> ogra_: can you just add "signal," to snap-confine's apparmor profile and reload it
[15:38] <mvo> fgimenez_: I think master is fine and I prepared cherry-picks for 2.26, if your test is positive I will upload 2.26.4 to the PPA and make new beta images
[15:38] <ogra_> zyga, in the container ?
[15:38] <ogra_> not sure that will work
[15:38] <fgimenez_> mvo: of couse on it, will let you know how it goes
[15:38] <ogra_> (simply beacause i wont be able to relaod)
[15:38] <ogra_> **reload
[15:38] <zyga> ogra_: yes,
[15:38] <zyga> ogra_: why not?
[15:39] <mvo> fgimenez_: thank you!
[15:39] <zyga> ogra_: that doesn't sound right, snapd does it all the time, apparmor is stacked
[15:39] <ogra_> zyga, apparmor is completely disabled
[15:39] <Chipaca> kyrofa: that's my secret: i'm always hungry
[15:39] <mvo> fgimenez_: I have dinner now I think, I will read scollback, super happy that we can move foward with 2.26 now :)
[15:39] <zyga> ogra_: it's not disabled, what makes you say so?
[15:39] <zyga> ogra_: that denial is from apparmor
[15:39] <ogra_> root@11f68f46633c:/# apparmor_parser
[15:39] <ogra_> Cache read/write disabled: interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)
[15:39] <ogra_> Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
[15:39] <ogra_> Use --subdomainfs to override.
[15:39] <fgimenez_> mvo: np :) it would be great to have snapd#3348 so that we can trigger this test automatically as soon as new core snaps are published
[15:39] <mup> PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>
[15:39] <kyrofa> Chipaca, haha, well then, just come now!
[15:39] <zyga> ogra_: apparmor is not a container thing, it is loaded into your kernel
[15:39] <kyrofa> You're tired of working today anyway
[15:39] <zyga> ogra_: and it actually stopped snap-conifne in the container from doing something
[15:39] <ogra_> zyga, but the container cant talk to it
[15:39] <zyga> ogra_: so how can it be disabled?
[15:40] <ogra_> zyga, on docker level
[15:40] <zyga> ogra_: it can, because the container loaded the apparmor profile for snap-confine
[15:40] <Chipaca> grah grah grah with spread and { Error preparing project on linode:ubuntu-14.04-64 }
[15:40] <ogra_> zyga, --security-opt apparmor:unconfined
[15:40] <zyga> ogra_: that's not the same as disabled
[15:40] <mvo> fgimenez_: indeed! it has a +1 from me already
[15:40] <ogra_> for docker run
[15:40] <zyga> ogra_: can you do what I suggested
[15:40] <zyga> ogra_: it will let you see what is really wrong
[15:40] <ogra_> zyga, i can not run apparmor_parser
[15:41] <zyga> ogra_: what happens when you do?
[15:41] <ogra_> so i cant change the profile
[15:41] <ogra_> see above
[15:41] <zyga> you get a denial from snap-confine when you run apparmor_parser?
[15:41]  * zyga must be missing a link to another error
[15:41] <zyga> ah, I see now
[15:41] <ogra_> zyga, i cant run appramor_parser to reload any profile since apparmor_parser can not run inside the container
[15:42] <ogra_> due to the /proc fs there not having the needed bits
[15:42] <mvo> jdstrand: some good news, we have a working seccomp->bpf thing in go and the seecomp code in snap-confine  can shrink by ~800 lines or so now (to be fair a lot of sc_add_map() calls in there). zyga will also work on this so I'm sure it will be nice
[15:42] <zyga> ogra_: is proc and sys normal but the kernel on the outside is not?
[15:42] <zyga> ogra_: is the kernel fully patched?
[15:42] <jdstrand> interesting
[15:42] <fgimenez_> mvo: aha thx, sorry didn't notice, zyga, morphis_ could you please take a look at snapd#3348?
[15:42] <mup> PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>
[15:43] <ogra_> zyga, i have not really any idea how docker creates its virtual /roc in the containers ... it should not be shared with the host afaik
[15:43] <ogra_> **proc
[15:43] <zyga> ogra_: I think it must be, just different namespaces
[15:43] <zyga> there's just one proc
[15:43] <ogra_> with docker ?
[15:43] <zyga> yes
[15:43] <zyga> ogra_: anyway, my real questions this: is the kernel you are running on fully patched to support apparmor features from ubuntu?
[15:43] <ogra_> afaik you get a dedicated /proc when starting a container
[15:44] <zyga> ogra_: if not then don't touch docker
[15:44] <zyga> ogra_: dedicated how? it's just a procfs mount
[15:44] <zyga> ogra_: it's all the namespaces that make it different
[15:44] <ogra_> root@11f68f46633c:/# ls /proc/|wc -l
[15:44] <ogra_> 72
[15:44] <zyga> ogra_: see above
[15:44] <ogra_> ogra@anubis:~$ ls /proc/|wc -l
[15:44] <ogra_> 429
[15:44] <zyga> ogra_: it's the normal procs
[15:44] <zyga> ogra_: with a PID namespace
[15:44] <ogra_> inside vs outside the container
[15:44] <jdstrand> ogra_: I'm late to the party. are you trying to run snaps in a docker container?
[15:45] <zyga> ogra_: (it's different because you are looking from a namespace)
[15:45] <zyga> but you are looking at the same thing as outside
[15:45] <ogra_> jdstrand, well, first i only tried to get snapd to run and the core snap installed ... got that working ... now i got greedy and tried to run a snap :P
[15:45] <jdstrand> ogra_: that isn't going to work unless you disable apparmor in snapd
[15:46] <jdstrand> ogra_: it works in lxd because lxd was modified to understand apparmor stacking
[15:46] <zyga> jdstrand: note that I think ogra also uses an "interesting" kernel where some things are missing
[15:46] <ogra_> jdstrand, well, i disabled apparmor in docker ... probably i should cheat and hack lsb-release/os-release so snapd doesnt think it is on ubuntu
[15:46] <zyga> jdstrand: what it looks like to me is that that version has no idea about stacking
[15:46] <zyga> jdstrand: and what happens is that it uses the outside profile
[15:47] <zyga> ogra_: we no longer care about os-release
[15:47] <zyga> ogra_: we look at apparmor features in sysfs
[15:47] <jdstrand> zyga: well, I think it is likely that in the container apaprmor is disabled because things aren't mounted, etc, but apparmor init notices that it isn't lxd and says apparmor isn't available
[15:47] <ogra_> well, then only llsb_release
[15:47] <ogra_> zyga, ouch
[15:47] <ogra_> then i have no chance of hacking around this i guess
[15:47] <zyga> jdstrand: yes but also note that snap-confine itself (in docker) gets killed by apparmor
[15:47] <jdstrand> ogra_: you need to disable apparmor in the snapd in docker
[15:48] <zyga> jdstrand: and uses a non-stacked profile path
[15:48] <jdstrand> (and snap-confine)
[15:48] <zyga> ogra_: I think this is a moot exercise, what are you trying to achieve?
[15:48] <jdstrand> ogra_: is this a docker snap or a docker deb?
[15:48] <ogra_> jdstrand, right ... and in the past i could have done that by hacking the distro info to pretend i'm not ubuntu
[15:49] <ogra_> (disabling apparmor of snapd)
[15:49] <ogra_> jdstrand, dockeer deb on 16.04
[15:50] <ogra_> zyga, nothing really ...
[15:51] <jdstrand> ok, so, in a docker deb, the docker daemon is not confined. if you used --security-opt apparmor:unconfined (or whatever the incantaion is), then that means the container is not confined either. if you can convince snapd in the container that it shouldn't use apparmor, then apparmor should not be in your way
[15:51] <zyga> ogra_: to do that, I think, you must boot with apparmor disabled on command line
[15:51] <zyga> ogra_: I think that may be sufficient
[15:51] <jdstrand> but, docker has a seccomp list it puts on containers which could block pivot_root
[15:52] <jdstrand> (or other things)
[15:52] <ogra_> zyga, linaro uses docker for all image building ... essentially all i initially tried was to get "snap known --remote model series=16 model=pc-amd64 brand-id=canonical" to work ... to not have them use hacked up model assertions for the images they offer (since they end up non-upgradeable)
[15:52] <ogra_> zyga, so i only tried to get snapd and the snap command to work (which i achieved) ... the "running a snap" was just something i tried then ... since i was in that env anyway
[15:53] <fgimenez_> mm the store is returning 50x on some requests http://paste.ubuntu.com/24727574/
[15:53] <zyga> I see
[15:53] <ogra_> zyga, though i guess it would be nice to find a docker setup where you can actually use snaps :)
[15:53] <zyga> all the goodies today make me want to go downstairs, take a shower and read a book outside
[15:54] <ogra_> heh
[15:54] <zyga> ogra_: I think that needs love
[15:54] <zyga> jdstrand: is there any docker setup that would work today?
[15:54] <zyga> ogra_: I think lxd is possible but docker is not
[15:54] <ogra_> zyga, right ... well, at least snapd runs now, i have a setup here (will blog about it later in the week)
[15:54] <ogra_> zyga, right ... but what do you do with third parties that dont use lxd
[15:55] <ogra_> (lxd is fine btw, i tried that today)
[15:55] <ogra_> (well ... lxc actually)
[15:55] <zyga> ogra_: say it is not supported, it's not going to magically fix itself
[15:55] <zyga> unless we make snapd and docker owrk
[15:55] <zyga> *work
[15:56] <ogra_> zyga, well, all i needed was the model assertion ...
[15:56] <ogra_> so make the snap conmmand work enough to download it ... that works now
[15:56] <ogra_> running a snap would just have been the cherry on top ... not a requirement
[15:58] <ogra_> (it wouldnt have helped anyway since ubuntu-image is now --classic which makes unusable for 90% of my use cases as a snap ... i'll have to resort to the deb anyway)
[15:59] <zyga> I see
[15:59] <ogra_> (though i just found that the deb is unusable as well in 16.04 containers if you dont add PPAs ... (see my conversation with slangasek above)) ...
[16:15] <jdstrand> zyga: that question is open ended. I have not tried to run snaps within a docker container. All I can say is that if you are using the docker deb and you run containers unconfined and you make sure snapd doesn't think it should use apparmor, it could maybe be made to work (if tweaking the docker syscall list and likely running a system container)
[16:16] <mup> PR snapd#3417 opened: httputil,store: extract retry code to httputil, reorg usages <Created by pedronis> <https://github.com/snapcore/snapd/pull/3417>
[16:17] <jdstrand> zyga: if you use the docker snap, it will not work because docker doesn't know about apparmor stacking. if you use the deb but don't launch containers unconfined, you could *maybe* craft a profile for the container that would allow snaps to run *if* snapd in the container didn't think it should use apparmor
[16:18] <pedronis> mvo: will snapd#3385 create an always failing timer on classic? is that a problem?
[16:18] <mup> PR snapd#3385: cmd: add stub new snap-repair command and add timer <Created by mvo5> <https://github.com/snapcore/snapd/pull/3385>
[16:20] <bdx> hows it going everyone? I'm wondering if there is a best practice for snapping projects where the codebase comes from github? i.e. should we be tagging builds and associating those with the snap, or a direct code clone when building the snap?
[16:27] <ogra_> bdx, you should just use build.snapcraft.io ;)
[16:28] <ogra_> (at least if you own the GH branches)
[16:32] <bdx> ogra_: sick! is this newnew?
[16:32] <ogra_> yeah, relatively new
[16:33] <fgimenez_> mvo: i think we currently can't make sure that the core-revert passes with the code in master, we would need to use a core snap built from that code, if we could have a new edge core that would be enough, we can also wait until next edge core tomorrow
[16:33] <bdx> this looks awesome! digging in now. thanks!
[16:33] <ogra_> enjoy :)
[16:34] <fgimenez_> mvo: assuming that the deb ppa has those changes, with the current flakyness maybe it wasn't updated (it syncs after merge + green build)
[16:38] <aquarius_> yo, snappy types! I'm getting a weird error when I run the snap I've just built:
[16:38] <aquarius_> Failed to register: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.3234" is not allowed to own the service "org.kryogenix.pick-colour-picker" due to AppArmor policy
[16:38] <aquarius_> so, what should my service be named?
[16:42] <zyga> aquarius_: you want to look at the dbus interface but if this is a user session service I think that is currently unsupported
[16:42] <zyga> (though in progress)
[16:44] <aquarius_> zyga: er
[16:44] <aquarius_> I don't know what that means :)
[16:45] <zyga> aquarius_: is your snap using the dbus session bus?
[16:45] <aquarius_> the issue I was having is this: my snapped python2/gtk app worked fine, but it did not use my desktop theme. It was suggested that I should use add the home, gsettings, and unity7 plugs, which I have done, and now the snap installs but the app will not launch, with the above error.
[16:46] <zyga> aquarius_: none of those would make it match your desktop theme
[16:46] <aquarius_> I have a section in the snapcraft.yaml which looks like this:
[16:46] <zyga> aquarius_: did your snap previously work in devmode or in strict confinement?
[16:46] <aquarius_> https://paste.gnome.org/paztxcuml
[16:46] <aquarius_> but that section was there before and it worked.
[16:47] <aquarius_> I installed with --dangerous, but not with --devmode.
[16:47] <aquarius_> I don't really understand what that entails. :)
[16:47] <aquarius_> (that is: does --dangerous imply --devmode?)
[16:47] <zyga> no, it doesn't
[16:48] <zyga> aquarius_: I'm sorry but I cannot help you now, I ned to leave now; either catch me tomorrow or perhaps ask jdstrand
[16:48] <aquarius_> will do! cheers, pal
[16:48] <aquarius_> jdstrand: ping (you're who didrocks suggested I should talk to, actually :))
[16:51] <kyrofa> aquarius_, --devmode means "install without confinement (and warn when my app does something that WOULD be denied)"
[16:51] <kyrofa> aquarius_, --dangerous, on the other hand, means "install without verifying that this snap comes from a trusted source"
[16:51] <kyrofa> aquarius_, --devmode implies --dangerous, but not the other way around
[16:55] <aquarius_> excellent
[16:55] <bdx> ogra_: build.snapcraft.io is like CI/CD for snaps?
[16:56] <aquarius_> thank you for that, kyrofa! So, I was not installing with --devmode, and I was installing with --dangerous: I need --dangerous because I'm installing the snap I've just built :) And I didn't need --devmode which means that my app was working under confinement.
[16:56] <kyrofa> aquarius_, indeed
[16:57] <kyrofa> bdx not quite. CI typically runs tests, etc., acting as a gateway for, say, accepting pull requests
[16:58] <nacc> https://build.snapcraft.io/ has a nice picture
[16:59] <nacc> about halfway down the page as to where it fits (it's after CI)
[16:59] <bdx> ahh, the second graphic is what I was looking for
[17:00] <bdx> lets take any web app for example
[17:00] <bdx> rails, django, php .... something that is not a snap
[17:01] <bdx> so, you have a repo for your django site, would that now contain a snapcraft.yaml?
[17:01] <bdx> or would the application code be separate from the snap?
[17:02] <nacc> bdx: aiui, yes, you need a snapcraft.yaml still (i'm not sure if it can live in a separte 'packaging' repository/branch)
[17:02] <ogra_> you would likely have a django setup defined and configured inside your snapcraft.yaml, so your snap would ship it along to serve your site
[17:03] <bdx> ogra_: a 'django' snap could be a generic snap that lets you set a key and a repo basically?
[17:04] <ogra_> (or you have a webserver snap that shares content with your snap via the content interface ... that way you could update the site only ... but that would be a very personal/specific setup)
[17:04] <nacc> bdx: a snap is an entire application, you wouldn't snap django itself (imo), but your use of django
[17:04] <ogra_> bdx, no, i mean you would ship a full webserver environment including django inside your snap
[17:05] <nacc> bdx: in snap parlance, django would be a 'part'
[17:05] <ogra_> or alternatively make two snaps and have one share datas from the other
[17:05] <ogra_> *data
[17:05] <bdx> I see this, but how does the snap interface to the application code
[17:05] <bdx> currently I use a git-layer in my charms to pull in application code
[17:05] <ogra_> have a look at the content interface
[17:05] <bdx> ok
[17:06] <bdx> I'm trying to understand what about my charms should become snaps
[17:06] <ogra_> your webserver would use shared code from $SNAP/wrbserver/shared and be configured for that ... and your app code would then provide stuff in that dir through the content-sharing interface
[17:07] <bdx> ogra_: I see, so I could use the charm to handle the application code in that case
[17:07] <ogra_> when you upgrade your app snap it will automatically ship the updated code in that dir
[17:07] <bdx> I see ... so my application code is packaged with the snap then
[17:08] <ogra_> well, it really depends what you want ... either bundle the server with the app or use an interface to hold both of them separated
[17:08] <ogra_> everything is possible ;)
[17:08] <bdx> totally ... thats what make it so difficult
[17:09] <bdx> I feel like I need to be more educated on snaps to be making these decisions
[17:09] <ogra_> (you could also have a deb based server that has a fixed config to look in /snap/$your-app/current/data/ for all its stuff
[17:09] <ogra_> )
[17:09] <bdx> I'll work on that
[17:09] <bdx> yeah ... then have the charm deliver the application code
[17:09] <ogra_> there are no limits to creativity with snaps ;)
[17:10] <bdx> I think my problems moving forward will be knowing and understanding the framework here and what is available and how to use it
[17:11] <ogra_> right ... i guess thats a matter of playing around with it and learning its capabilities ;)
[17:11] <jdstrand> aquarius_: you need to slots the dbus interface so it may bind to that well-known name. do 'snap download corebird', unsquashfs it, then look at squashfs-root/meta/snap.yaml for an example
[17:12] <jdstrand> basically:
[17:12] <jdstrand> slots:
[17:12] <jdstrand>  foo:
[17:12] <jdstrand>   bus: session
[17:12] <jdstrand>   interface: dbus
[17:12] <jdstrand>   name: org.kryogenix.pick-colour-picker
[17:12] <bdx> possibly I need to forget about what components the charm will handle, and just try to get something fully snapped then turn around and use the charm to fill in the lifecycle ops that are still needed following the app being fully snapped
[17:12] <Saviq> kyrofa, https://github.com/snapcore/snapcraft/commit/d22880fdcee434a5e85c376e8f26c61a661231ce
[17:14] <jdstrand> aquarius_: see https://github.com/snapcore/snapd/wiki/Interfaces#dbus
[17:17] <mvo> pedronis: always failing timer> yeah, I can make it just exit(0) instead, that will probably be fine
[17:17] <pedronis> mvo: ah, ok
[17:19] <Saviq> kyrofa, bug #1694765
[17:19] <mup> Bug #1694765: source-type: git uses --remote for submodules <Snapcraft:New> <https://launchpad.net/bugs/1694765>
[17:20] <aquarius_> jdstrand: I've got that section you described above under plugs; is that wrong, or do I need to declare it under plugs *and* slots?
[17:21] <aquarius_> jdstrand: that is: it's currently https://github.com/stuartlangridge/ColourPicker/blob/app/snap/snapcraft.yaml#L23
[17:21] <aquarius_> do i need to duplicate that "plugs" section as "slots"?
[17:22] <mvo> pedronis: unless I'm missing something this is already the case: http://paste.ubuntu.com/24728381/
[17:23] <pedronis> mvo: yes, sorry, I forgot:  if err != errOnClassic {
[17:23] <kyrofa> pedronis, this looks like kyle but it's actually Chipaca. Github on mobile won't let me merge snapd#3400, could you give it a poke?
[17:23] <mup> PR snapd#3400: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <https://github.com/snapcore/snapd/pull/3400>
[17:24] <pedronis> kyrofa: Chipaca, looking
[17:24] <kyrofa> :) thanks
[17:24] <mvo> pedronis: great, thanks for double checking
[17:25] <pedronis> kyrofa: Chipaca, done
[17:26] <aquarius_> heh, so, it can't be plugs, since I get "cannot have plug and slot with the same name", so I'll try just as a slot. Cargo cult programming ftw. :)
[17:26] <mup> PR snapd#3400 closed: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3400>
[17:32] <aquarius_> ok, I've now got it to install, at least, but it hasn't actually fixed the original issue of not having a theme. I'll talk to didrocks again :)
[17:33] <aquarius_> jdstrand: my snapcraft.yaml looks like this: http://paste.ubuntu.com/24728481/ -- is that what you were suggesting?
[17:34] <jdstrand> aquarius_: yes. and also yes, I don't have answers for the theme
[17:35] <aquarius_> jdstrand: no problem (the theme is not your thnig :))
[17:35] <aquarius_> jdstrand: just checking I was doing what you suggested
[17:56] <seb128> aquarius_, hey, just in case it's interesting to you, colourpicker fails to start from snap here with that error
[17:56] <seb128>   File "/snap/pick-colour-picker/x1/lib/python2.7/site-packages/pick/__main__.py", line 874, in start_everything_first_time
[17:56] <seb128>     self.w.set_default_icon(image.get_pixbuf())
[17:56] <seb128> TypeError: Argument 0 does not allow None as a value
[17:56] <aquarius_> huh. really? it starts for me, it just doesn't have the right theme...
[17:58] <aquarius_> I suspect this is about paths. Fabulous, etc :)
[18:06] <seb128> aquarius_, could be, in any case it looks like the pixbuf might be None and your code doesn't handle that case
[18:06] <aquarius_> indeed!
[18:06] <aquarius_> although it shouldn't be :)
[18:06] <aquarius_> I'll look into it (and try ti work out why it's none!)
[18:06] <seb128> let me know if you need debug infos
[18:26] <niemeyer> Forum going down/up for a quick configuration update..
[18:27] <niemeyer> Almost there.. aaaaaaan
[18:28] <niemeyer> d.. it's up!
[18:33] <mup> PR snapd#3418 opened: tests: prefer ipv4 over ipv6 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3418>
[18:43] <seb128> aquarius_, theme works here in devmode on xenial/unity
[18:46] <niemeyer> SMTP is failing to relay properly.. reverting setup.. :(
[18:55] <ogra_> jdstrand, FYI ... --security-opt seccomp:unconfined in the "docker run" command works around the blocker ... not that this gets me much further though ...
[18:55] <ogra_> root@7c9bcf90f68b:/# /snap/bin/htop
[18:55] <ogra_> cannot bind-mount the mount namespace file /proc/202/ns/mnt -> htop.mnt: Permission denied
[18:55] <ogra_> support process for mount namespace capture exited abnormally
[18:55] <ogra_> :P
[19:44] <jdstrand> ogra_: I had a sneaking suspicion that mount, pivot_root and the like would be blocked by docker
[19:50] <mup> PR snapd#3419 opened: interfaces: partly revert aace15ab53 to unbreak core reverts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3419>
[19:51] <mvo> jdstrand: I have another partial revert for you -^
[19:51] <mvo> jdstrand: for you to review, we have a reliable test now and it breaks on this symbol now
[19:52] <jdstrand> oh sigh
[19:52] <jdstrand> all my arg filtering work keeps getting reverted
[19:54] <jdstrand> mvo: responded
[19:56] <mvo> jdstrand: thank you!
[19:58] <mvo> jdstrand: well, not for long hopefully, https://github.com/mvo5/snappy/commits/seccomp-bpf will fix it (when its polished enough to get merged)
[20:07] <cachio> niemeyer, could you please update the https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz with the last version which has the repeat?
[20:13] <niemeyer> cachio: Yeah, just not right now..
[20:14] <niemeyer> cachio: Also, not sure how that helps?  I mean, -repeat is only useful locally I suppose?
[20:18] <cachio> niemeyer, I need to check the test is working in ci
[20:18] <cachio> niemeyer, because from my machine it always pass
[20:19] <cachio> niemeyer, not sure if it is because my connection is slower or why
[20:19] <cachio> niemeyer, so ,my idea is to repeat the execution 100 times in ci to check the fix works
[20:20] <cachio> niemeyer, does it make sense?
[20:23] <niemeyer> cachio: Ah, yep
[20:23] <niemeyer> cachio: Can't do that now, but will do
[20:24] <niemeyer> Need to step out for a while
[23:56] <mup> PR snapd#3420 opened: many: slight improvement of some snap error messaging <Created by chipaca> <https://github.com/snapcore/snapd/pull/3420>


[04:32] <mup> Bug #1729841 changed: [2.3b3] I added a SSH key, but it didn't appear in the list until I clicked somewhere on the screen <2.3qa> <ui> <MAAS:Expired> <https://launchpad.net/bugs/1729841>
[04:32] <mup> Bug #1729913 changed: recent update to 1.9 broke dhcpd.conf.template <1.9.5> <maas> <MAAS:Expired> <https://launchpad.net/bugs/1729913>
[05:03] <Mava> any rookie tips for getting the api version? curl http://localhost:5240/MAAS/api/version returns nothing
[09:14] <mup> Bug #1741013 opened: [Wishlist] Ability that can add custom cloud-init configuration <MAAS:New> <https://launchpad.net/bugs/1741013>
[17:02] <Guest74702> does anyone know if there is an advantage to installing MAAS with LXD ?
[17:04] <Guest74702> when i do it fails to install avahi dependency issue. this seems to be a known issue, but the work-arounds don't seem to work on maas 2.3
[19:21] <torontoyes> What are the steps involved in deploying windows 10 or 2016 using Maas for no touch install.  Is it similar to using sysprep then creating an image with something like ghost?  Does MAAS have a tool for this?


[09:49] <thumper> :(
[09:49] <thumper> looks like every single windmill test is broken
[09:55] <wgrant> thumper: Hm?
[09:55] <thumper> wgrant: in the buildbot
[09:55] <wgrant> Awesome.
[09:56] <wgrant> This is why disabling them in ec2test is awesome.
[10:01] <lifeless> yes
[10:01] <lifeless> disabled tests are broken tests
[10:09] <thumper> :(
[10:09] <thumper> I feel they will be fixed soon
[10:09] <thumper> otherwise there'll be hell to pay
[10:10] <thumper> as in windmill fixed in ec2test
[16:08] <deryck> gah.  These test failures are driving me crazy.
[16:31] <adiroiban> deryck: Hi. Were you able to reproduce them?
[16:32] <deryck> adiroiban, hi.  yeah, I can now.  Had to do a make clean && make but then I do get complete Windmill failure.
[16:32] <deryck> adiroiban, rolling back to prior to our 3 changes and I get a pass.  So trying to work out which rev introduced the pain.
[16:36] <adiroiban> deryck: start by rolling my branch, as it was the only one touching some js code
[16:37] <deryck> adiroiban, I'm just bzr up'ing from the last known working rev.  one by one until I get fail.
[16:38] <adiroiban> ok. and can you also run a single test and it is failing ?
[16:42] <deryck> adiroiban, yeah, even a single test fails for me.
[16:57] <deryck> adiroiban, so it does seem to be your rev.
[16:58] <deryck> adiroiban, seems js is not hooked up properly in testing, so maybe a problem loading something you wrote when not in devmode?  Just a guess.
[16:58] <adiroiban> adiroiban: after, make clean ; make
[16:58] <adiroiban> I am also able to reproduce them
[16:59] <deryck> ah, yeah.  so if you run the dev server with devmode off, you can reproduce the js not being hooked up properly locally.
[17:00] <deryck> z is not defined. ?
[17:01] <adiroiban> deryck: uh...
[17:01] <adiroiban> at the end of pofile.js
[17:01] <adiroiban> there is a „z” char
[17:02] <adiroiban> it should be deleted
[17:05] <deryck> adiroiban, yeah, thanks.  I see it now.  Fixing up a branch to submit for testfix now.
[17:06] <adiroiban> deryck: my fault. It looks I have accidentaly commited it while merging devel.
[17:06] <deryck> adiroiban, no worries.  Can you reply to the list about the fix and that I am submitting a testfix branch for it?
[17:07] <adiroiban> deryck: lp-dev list?
[17:07] <adiroiban> or will you moderate my post to<EMAIL_ADDRESS>[17:07] <deryck> adiroiban, ah, right.  Sorry, I'll reply then.