[00:32] <duffydack> hmm http://aeric.poon.my/?p=496   might mean something to someone.
[01:14] <dnielsen> ajmitch, I apologize for the delay https://bugzilla.gnome.org/show_bug.cgi?id=626962
[01:14] <ubot4> Gnome bug 626962 in Community Extensions "Ubuntu One Music Store extension fails to build" [Normal,Resolved: notgnome]
[14:20] <Chipaca> apachelogger: nessita: rodrigo_: ping
[14:21] <apachelogger> Chipaca: ahoy
[14:22] <nessita> Chipaca: pong
[14:23] <Chipaca> nessita: rodrigo_:
 nessita, verterok: any objections against uploading my gsoc KDE stuff to universe for maverick?
[14:23] <Chipaca>  (that is if it gets a FFe)
[14:23] <Chipaca> I wanted to check apachelogger was working with all the latest bugfixes
[14:23] <verterok> Chipaca: +1
[14:24] <nessita> Chipaca: I'm not aware of what apachelogger has been working on
[14:24] <rodrigo_> apachelogger, what does that include?
[14:24] <nessita> besides "KDE" :-)
[14:24] <Chipaca> nessita: quite. So, talk with him :)
[14:24] <verterok> Chipaca: we need to be sure about the sso dbus signals :)
[14:24] <apachelogger> http://apachelog.wordpress.com/2010/08/21/ubuntu-one-technical-aspects/
[14:24] <rodrigo_> apachelogger, remember the kwallet patch you submitted is going to be removed in the next upload (today), so you might want to make sure you add that to ubuntu-sso-client
[14:25] <apachelogger> do I have something to patch against?
[14:25] <apachelogger> seeing as my patch was rejected due to sso being in a constant state of flux
[14:25] <Chipaca> apachelogger: also note we can't merge your patch upstream until you sign the canonical contributor agreement (if you want to do that)
[14:25] <rodrigo_> apachelogger, ubuntu-sso-client, should be stable now for you to patch it
[14:27] <rodrigo_> apachelogger, about the UI, we even added DBus interfaces to u-sso-client to allow other UIs to be implemented
[14:28] <apachelogger> Chipaca: last I saw the agreement I got advised not to sign it... so...
[14:28] <Chipaca> apachelogger: by whom?
[14:28] <apachelogger> a lawyer friend of mine
[14:29] <Chipaca> apachelogger: okie then :)
[14:30] <nessita> Chipaca: I'm not sure what you want me to look :-)
[14:30] <nessita> Chipaca: do we have a merge proposal to review?
[14:30] <rodrigo_> nessita, http://apachelog.wordpress.com/2010/08/21/ubuntu-one-technical-aspects/
[14:31] <apachelogger> supposedly we could just use ubuntu-sso-client as is in KDE too?
[14:32] <apachelogger> i.e. only deploy the UI components (based on syncdaemon's dbus interface) in maverick
[14:32] <rodrigo_> apachelogger, there is a low-level DBus interface in u-sso-client that you could use to provide a QT ui
[14:33] <nessita> apachelogger: we provide a DBus interface and you could build a KDE GUI on top of that
[14:33] <rodrigo_> apachelogger, we added that in fact based on your needs to have a QT UI
[14:33] <Chipaca> nessita: so... I'm not sure what apachelogger's current work entails, but I thought the easiest way to get him an answer as to whether it should/could go in universe.
[14:33] <nessita> apachelogger: let me give you a pointer
[14:33] <Chipaca> nessita: or rather, I'm pretty sure it shouldn't, for the reasons I think you're explaining (that I already explained), but you could get into more detail than i can
[14:33] <nessita> alecu: do you have the wiki pointer for ussoc?
[14:34] <apachelogger> nessita: do we need to create a Qt UI on top of it?
[14:35] <alecu> nessita, yes... just a sec.
[14:35]  * apachelogger finds it unlikely to roll out a somewhat stable UI in time to accumulate testing for maverick
[14:35] <Chipaca> apachelogger: what we could do is split ubuntu-sso-client into ubuntu-sso-client and ubuntu-sso-client-gtk, and you patch the former and replace the latter with -qt
[14:36] <nessita> Chipaca: the latter you meant?
[14:36] <Chipaca> nessita: patch the former to also use kwallet
[14:36] <nessita> ah
[14:36] <nessita> :-)
[14:36] <alecu> https://wiki.ubuntu.com/SingleSignOn/UbuntuSsoClient
[14:37] <alecu> nessita, but that's the doc for programs that need credentials
[14:37] <nessita> apachelogger: ok, the link that alecu pasted shows the high level DBUS interface. I forgot we haven't documented yet the "low-level" interface that the GUI's use
[14:38] <alecu> nessita, yup, we still need to write the docs for someone wanting to login/register
[14:38] <alecu> * to make a login/register ui
[14:39] <nessita> apachelogger: so, basically, SSO provides a DBUS service with 2 main interfaces: the Credentials which is what we call "high level" (apps like syncdaemon use them)
[14:39] <nessita> apachelogger: and the UserManagement, which is a lower level interface, that is used by the GTK GUI
[14:40] <nessita> apachelogger: and that any other interface (let's say, KDE), can use to provide the same functionality
[14:57] <rye> nessita, hi, i wanted to ask what is the correct way for up-to-date maverick system to authorize the machine. In my case a browser window is opened when I run ubuntuone-preferences, should it be this way or I should get a GUI for that?
[14:58] <apachelogger> nessita: sso-client package misses recommends on gnome-keyring
[14:58] <nessita> rye: we're landing the latests versions for everything, do you have trunk for all?
[14:58] <nessita> apachelogger: why should it recommend it?
[14:59] <apachelogger> nessita: because you only support gnome-keyring
[15:00] <nessita> apachelogger: we have the requirement of python-keyring, which requires gnome-keyring
[15:00] <nessita> apachelogger: so I don't understand why we need to "recommed" gnome-keyring being that we need it to work (at least the current version)
[15:00] <apachelogger> me@osiris:~$ apt-cache show python-gnomekeyring|grep gnome-keyring
[15:00] <apachelogger> Depends: libc6 (>= 2.4), libglib2.0-0 (>= 2.12.0), libgnome-keyring0 (>= 2.20.3), python (<< 2.7), python (>= 2.6), python-support (>= 0.90.0), python-gtk2
[15:00] <apachelogger> Suggests: gnome-keyring
[15:00] <apachelogger> I beg to differ
[15:01] <nessita> Chipaca: what was the command you taught me to see package dependencies?
[15:01] <Chipaca> nessita: apt-get rdepends?
[15:01] <nessita> let's see
[15:02] <Chipaca> nessita: or apt-cache putty :)
[15:02] <Chipaca> not putty, dotty
[15:02] <Chipaca> off-by-180
[15:02] <apachelogger> rdepends has a misleading name, it lists reverse relations rather than depends in particular BTW
[15:03] <nessita> Chipaca: E: Invalid operation (for rdepends) :-)
[15:03] <apachelogger> nessita: apt-cache, not get :P
[15:03] <nessita> apachelogger: "libgnome-keyring0" -> "gnome-keyring";
[15:03] <nessita> apachelogger: so, "python-gnomekeyring" -> "libgnome-keyring0"; and "libgnome-keyring0" -> "gnome-keyring";
[15:04] <nessita> apachelogger: we do depend on gnome-keyring :-)
[15:04] <apachelogger> me@osiris:~$ apt-cache show libgnome-keyring0 | grep gnome-keyring | grep -v libgnome
[15:04] <apachelogger> Suggests: gnome-keyring
[15:04] <apachelogger> Breaks: gnome-keyring (<< 2.30)
[15:04] <apachelogger> I again beg to differ
[15:05] <nessita> apachelogger: what I showed you is the output of apt-cache dotty python-gnomekeyring
[15:05] <apachelogger> dotty also tracks relations and not dependencies in particular
[15:06] <nessita> apachelogger: I'm new at packaging, so I probably made a mistake (or ten), but honestly I'm not convinced of this
[15:06] <nessita> apachelogger: how come python-gnomekeyring does not depend of gnome-keyring? that sounds weird
[15:07] <apachelogger> because it only depends on the library and the library only suggest gnome-keyring
[15:07] <apachelogger> I am sure there is a reason for that
[15:07] <apachelogger> but why exactly you will have to ask someone who has to do with those packages
[15:07] <apachelogger> not exactly my area of work either :P
[15:09] <nessita> heh
[15:26] <nessita> rye: hey, you never answered
[15:28] <rye> nessita, i am running bleading-edge maverick , not the version from trunk
[15:52] <rodrigo_> anyone knows about glibc brokenness on latest maverick packages? I seem to be having weird memory corruption bugs, and after 1 hour looking at my code, it doesn't seem to be my fault
[16:06] <rye> rodrigo_, are you talking about nautilus plugin?
[16:07] <rodrigo_> rye, I am talking about a nautilus plugin branch I'm working on, yes
[16:08] <rodrigo_> it's segfaulting on a g_free call
[16:11] <rye> rodrigo_, related to _CBData ?
[16:12] <rodrigo_> rye, no
[16:12] <rodrigo_> rye, it's crashing here:
[16:12] <rodrigo_> if (finfo->priv->path != NULL)
[16:12] <rodrigo_> 		g_free (finfo->priv->path);
[16:13] <rye> rodrigo_, is finfo->priv != NULL ?
[16:13] <rodrigo_> rye, it should, yes
[16:14] <rodrigo_> it's crashing on the g_free
[16:23] <rodrigo_> aha, I found it!!
[16:24] <rodrigo_> stupid copy&paste
[16:52] <rodrigo_> alecu, nessita, Chipaca: https://code.edge.launchpad.net/~rodrigo-moya/ubuntuone-client/check-published-files/+merge/33660
[17:13] <alecu> rodrigo_, reviewing your branch
[17:26] <apachelogger> nessitalunch: I am getting a segfault with ubuntu-sso-client
[17:32] <trichard> hey, is there any way to see which file ubuntuone is syncing at the moment?
[18:39] <nessita> apachelogger: can you please be more specific? :-)
[18:45] <apachelogger> nessita: trying to login -> backend goes down with segfault
[18:45] <nessita> apachelogger: how are you trying to login?
[18:45] <apachelogger> last log entry: 2010-08-25 18:26:15,602:602.580070496 ubuntu_sso.main keyring_store_credentials: app_name dbus.String(u'Ubuntu').
[18:45] <apachelogger> nessita: using the GTK UI
[18:45] <nessita> apachelogger: how are you running the GTK UI?
[18:46] <apachelogger> from terminal without args
[18:46] <nessita> apachelogger: you're having a mismatch between the version of the UI and the version of the daemon
[18:47] <nessita> be sure you're running both from the same branch
[18:47] <apachelogger> I am running from the packages
[18:47] <nessita> apachelogger: you shouldn't be running the GUI other than from a dbus call
[18:47] <nessita> apachelogger: can you paste how are you running the GUI?
[18:47] <nessita> the exact command
[18:48] <apachelogger> me@osiris:~$ ubuntu-sso-login-gui
[18:48] <apachelogger> and in another tab
[18:48] <apachelogger> me@osiris:~$ /usr/lib/ubuntu-sso-client/ubuntu-sso-login
[18:49] <nessita> apachelogger: where are you getting the  ubuntu-sso-login-gui from? is not shipped in the package
[18:49] <nessita> apachelogger: that script is not supported (just FYI)
[18:49] <nessita> apachelogger: we will be removing it soon
[18:50] <apachelogger> me@osiris:~$ dpkg -L ubuntu-sso-client | grep login-gui
[18:50] <apachelogger> /usr/bin/ubuntu-sso-login-gui
[18:50] <apachelogger> it is shipped in the package
[18:51] <nessita> apachelogger: it shouldn't be, I'll file a bug. Thanks for pointing this out!
[18:51] <apachelogger> nessita: how should one be starting the gui?
[18:51] <nessita> apachelogger: anyways, you should raise the GUI using Dbus
[18:51] <nessita> apachelogger: use d-feet or something similar to call the dbus method
[18:52] <nessita> apachelogger: the methods you want are in the Credentials interface. Either "login_or_register_to_get_credentials" or "login_to..."
[18:52] <apachelogger> k
[19:00] <apachelogger> nessita: http://paste.ubuntu.com/483561/
[19:00] <nessita> apachelogger: you don't have the gnome keyring available
[19:01] <nessita> apachelogger: I'm a bit lost what your question is
[19:01] <apachelogger> what part is supposed to create it though?
[19:01] <nessita> apachelogger: the keyring is a dbus service
[19:01]  * apachelogger has a default keyring, it just seems that it falls over not having a login keyring
[19:01] <nessita> alecu: look ^
[19:01] <apachelogger> me@osiris:~$ qdbus org.gnome.keyring
[19:02] <apachelogger> /
[19:02] <apachelogger> gnome keyring is there
[19:02] <nessita> apachelogger: ah yes, sorry
[19:02] <apachelogger> also in seahorse I can access it properly
[19:02] <nessita> apachelogger: I'm just passing this to al
[19:02] <nessita> alecu*
[19:02] <apachelogger> aye
[19:02] <nessita> apachelogger: we have a bug reported for that
[19:02] <alecu> I'm about to start working on this issue, yes
[19:03] <apachelogger> simply creating a login keyring should suffice to work around it?
[19:03] <alecu> it's #624033
[19:03]  * apachelogger finds "login" a bit of a generic name TBH
[19:03] <nessita> apachelogger: not sure, let the master answer
[19:04] <apachelogger> nessita: segfault again
[19:04] <apachelogger> last line of log: 2010-08-25 20:04:16,309:309.218883514 ubuntu_sso.main keyring_store_credentials: app_name dbus.String(u'ubuntuone-syncdaemon').
[19:05] <nessita> apachelogger: may be related to not having the keyring available?
[19:05] <apachelogger> I created one :P
[19:05] <nessita> hum
[19:05] <apachelogger> that is after I obtained a token
[19:05] <nessita> apachelogger: just FYI, app_name should be "Ubuntu One", which is a constant defined in ubuntuone.clientdefs
[19:05] <nessita> apachelogger: so the token actually works with syncdaemon
[19:06] <apachelogger> k
[19:06] <apachelogger> well, since it crashes anyway... ;)
[19:07] <alecu> apachelogger, "login" is the keyring that's automatically unlocked by some pam module using your login in password when you have just logged in with gdm.
[19:07] <apachelogger> alecu: I c
[19:07] <apachelogger> that is bound to fail on KDE systems
[19:07] <apachelogger> or you are missing a dep for that
[19:08] <alecu> apachelogger, which dep do you think might solve this?
[19:08] <apachelogger> dunno
[19:08] <apachelogger> I never heared of such a pam module before
[19:09] <alecu> apachelogger, also it's failing on some gnome systems that have a keyring named "default" but no "login" keyring.
[19:09] <alecu> apachelogger, it's lib-pam-gnomekeyring
[19:10] <apachelogger> installed
[19:10] <apachelogger> http://live.gnome.org/GnomeKeyring/Pam
[19:10] <apachelogger> login gets created if not present
[19:10] <apachelogger> but it seems KDM will not include the PAM module
[19:11] <apachelogger> (which IIRC was also the problem that early on lucid was not able to start gnome-keyring in KDE - in GNOME it did get autostarted frome the module but in KDE not)
[19:11] <rodrigo_> apachelogger, I think that's your pam setup, nothing to do with kdm
[19:11] <rodrigo_> but yeah, you'd need gnome-keyring autostarted
[19:16] <apachelogger> me@osiris:/etc/pam.d$ grep -ri gnome_key .
[19:16] <apachelogger> ./common-password:password      optional        pam_gnome_keyring.so
[19:16] <apachelogger> no autostart -> no login keyring
[19:17] <apachelogger> alecu: I would check for existance of the keyring and if not manually create it
[19:46] <kklimonda> rye: any chance I'll get access to my contacts before I get old and wrinkled? ;)
[20:09] <ajmitch> rodrigo_: so you've managed to track down how to fix up the mono bindings?
[20:10]  * ajmitch was looking for a fix yesterday for it
[20:13] <apachelogger> nessita: want me to get a backtrace?
[20:14] <rodrigo_> ajmitch, not yet, busy with other stuff, but will look at it soon
[20:19] <nessita> apachelogger: for the segfaulting? yes please
[20:20] <nessita> apachelogger: also, you're running kde, right? (just to know)
[20:21] <ajmitch> rodrigo_: ok, you'll probably end up cursing gapi2-codegen's lack of useful output as I did :)
[20:23] <apachelogger> nessita: yes, I am running KDE
[20:24] <rodrigo_> ajmitch, yeah :(
[20:25] <rodrigo_> ajmitch, only output I get is something about not knowing what GtkVBoxClass is
[20:25] <rodrigo_> ajmitch, do you get the same?
[20:25] <ajmitch> yep
[20:25] <ajmitch> adding in the syncdaemon header header into ubuntuone.source generated C# files for at least that part, but still no useful u1ms code
[20:25] <ajmitch> & it of course failed to compile, not unsurprising
[20:27] <ajmitch> apparantly the gapi stuff hasn't seen a lot of love recently
[20:31] <rodrigo_> ajmitch, it used to work ok, and there have been no changes, so not sure what's up
[20:32] <ajmitch> the only code changes to the u1ms widget recently have been adding in the syncdaemon support, but I'm not sure how that should affect it
[20:32] <apachelogger> nessita: http://paste.ubuntu.com/483608/
[20:33] <ajmitch> diving into the gapi code to get some useful answers takes a little while
[20:33] <rodrigo_> ajmitch, in fact, it started happening when I removed the previous files that were talking to syncdaemon, to replace them with libsyncdaemon
[20:33] <rodrigo_> ajmitch, so not sure what doesn't make gapi happy
[20:33] <ajmitch> the previous code didn't link to an external library (libsyncdaemon)?
[20:34] <ajmitch> it would seem rather strange if you did need to have any information about libsyncdaemon in the code for gapi to look at
[20:35] <rodrigo_> hmm
[20:35] <rodrigo_> but it's just internal usage, not in the headers it is supposed to be parsing
[20:35] <rodrigo_> or does gapi look at the .c files?
[20:36] <ajmitch> the headers afaik
[20:36] <rodrigo_> yeah, that's what I thought
[20:37] <ajmitch> without useful output from the tool this is just speculation really
[20:38] <ajmitch> & frustrating at that :)
[20:38] <rodrigo_> Field ParentClass has unknown Type GtkVBoxClass in Struct UbuntuOne.U1MusicStoreClass
[20:38] <rodrigo_> yeah, that's the only thing I get
[20:39] <ajmitch> that's boilerplate widget code you've got there too
[20:39] <rodrigo_> but I guess he should know UbuntuOne.U1MusicStoreClass is a GTK class struct
[20:39] <nessita> apachelogger: I have no idea what's going on there, seems like a dbus issue
[20:39] <nessita> apachelogger: maybe you have a too old/ too new dbus?
[20:39] <nessita> apachelogger: maybe gnomekeyring depends on a different dbus than the one that kde provides?
[20:40] <apachelogger> there is only one dbus
[20:40] <apachelogger> so either what is currently in maverick is broken or it is something else
[20:40] <nessita> apachelogger: what's currently in maverick is working on gnome desktops
[20:40] <nessita> apachelogger: do you have a gnome VM? maybe you can try there and see if it fails for you
[20:42] <apachelogger> dont have one around
[20:42] <rodrigo_> ajmitch, well, that's the usual boilerplate for GTK widgets, so I'd assume gapi knows about it
[20:48]  * ajmitch shall have to get back to it later
[20:51] <rodrigo_> ajmitch, in /usr/share/gapi-2.0/gtk-api.xml, there is no Gtk*Class at all, so not sure why it tries to parse the music store one :(
[20:52] <ajmitch> or more, why did it work up until now/
[20:53]  * ajmitch will be back later
[20:57]  * apachelogger pokes his dbus with a long pointy stick of fluff
[21:53] <rodrigo_> apachelogger, I just removed your kwallet patch from the u1-client package, since it didn't apply anymore
[21:54] <rodrigo_> ajmitch, for when you get back, I've succeeded in not having the GtkVBoxClass warning, but still doesn't create any .cs files
[21:54]  * ajmitch is around now
[21:54] <ajmitch> so that warning may have been somewhat spurious?
[21:55] <ajmitch> fwiw, I can get a U1MusicStoreClass.cs created by commenting out the line that refers to parent_class in the .xml file
[21:55] <rodrigo_> ajmitch, unfortunately, seems so
[21:55] <ajmitch> I haven't checked to see if the assembly that is created is at all useful though
[21:56] <rodrigo_> ajmitch, hmm, maybe we can mark it to be removed on the ubuntuone-api.metadata file
[21:56] <rodrigo_> let me try...
[21:56] <ajmitch> that would probably remove it, but I don't know if it should be
[21:56] <ajmitch> worth a try
[21:58] <rodrigo_> no, no luck :(
[21:58] <apachelogger> rodrigo_: cruel world
[21:59] <rodrigo_> apachelogger, patch ubuntu-sso-client, as you talked with nessita
[22:08] <apachelogger> http://simplest-image-hosting.net/jpg-0-plasma-desktoplm3446
[22:09] <rodrigo_> ajmitch, so, you get something in ubuntuone-api.xml?
[22:09] <rodrigo_> ajmitch, right now, I get it empty
[22:10] <ajmitch> rodrigo_: empty after changing what?
[22:10] <ajmitch> at the moment I'm rebuilding the previous libubuntuone in a chroot to have a look at it
[22:10] <rodrigo_> ajmitch, empty when it gets generated
[22:10] <rodrigo_> ajmitch, ok
[22:15] <ajmitch> assuming that pbuilder will cooperate & let me into the chroot after it built
[22:15] <ajmitch> but I can at least see that the gapi2-codegen output is different in the build log
[22:15]  * ajmitch just needs to look at the xml file
[22:19] <rodrigo_> ajmitch, I'm looking at the gtk-sharp package, to see if anything changed there
[22:19] <ajmitch> nothing has changed there
[22:20] <rodrigo_> ah, you checked already?
[22:20] <ajmitch> it hasn't changed for quite awhile (last upload 14 weeks ago)
[22:21] <ajmitch> yeah, I've been complaining about the gapi stuff in the debian mono channel as well :)
[22:21] <rodrigo_> ok
[22:25]  * ajmitch is wanting to get this as working as possible before uploading to debian experimental
[22:40]  * ajmitch wonders why the ubuntuone-api.xml file is so very different between the 2 releases
[22:40] <ajmitch> in 0.3.2, it has object name="U1MusicStore", and in 0.3.3 it only gets the struct name="U1MusicStoreClass"
[22:41] <apachelogger> nessita: the gui uses gobject signals?
[22:41] <ajmitch> yet more evidence that gapi is just crap :)
[22:45] <dobey> eh, let's just rewrite it all in vala, and not provide any bindings to anything ;)
[22:45] <ajmitch> dobey: can you get it done by next week? :)
[22:46] <nessita>  apachelogger: yes
[22:48] <dobey> sure, but i don't measure time in earth days, so one week is actually 3 years in earth time, for me ;)
[22:56] <ajmitch> dobey: we were just discussing how it'd be nice to use gobject introspection for mono bindings, if you have a free evening to work on it :)
[22:59] <dobey> me and mono don't mix well
[23:02] <ajmitch> it was worth a try
[23:03] <ajmitch> don't worry, the gapi code that parses C at the moment is written in perl, which is such an improvement
[23:07] <apachelogger> nessita: why not dbus?
[23:07] <dobey> eh, i like perl
[23:08] <nessita> apachelogger: the GUI part is not a dbus service, is just a plain GTK interface, so it signals thru gobject
[23:09] <apachelogger> nessita: but the backend is a dbus service so the gui could just call a method of the backend's dbus api
[23:13] <nessita> apachelogger: yeah, propably. We didn't design it that way, we should be able to re-think that for the next cycle


[12:51] <blahdeblah> gbell: Linux.conf.au is on in January as well - I think it's in Geelong this year
[21:38] <gbell> @jea: I hadn't ever heard of OSDC!  Thanks Jea!  I went to Linuxconf in Tassie years ago... was fun and interesting but not sure worth the trip.  Anybody going to OSDC?
[21:38] <meetingology> gbell: Error: "jea:" is not a valid command.
[21:38] <gbell> jea: I hadn't ever heard of OSDC!  Thanks Jea!  I went to Linuxconf in Tassie years ago... was fun and interesting but not sure worth the trip.  Anybody going to OSDC?
[22:07] <jea> gbell: I know of some people going, but not from this channel specifically


[01:47] <mwhudson> mcphail: according to the mailing list it's supposed to be $SNAP_USER_COMMON but it doesn't work right now
[01:48] <mwhudson> mcphail: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1611063
[01:48] <mup> Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1611063>
[01:48] <notadeveloper> is video acceleration available in snappy
[02:06] <mup> Bug #1624963 opened: pulseaudio interface (still) missing permissions <Snappy:New> <https://launchpad.net/bugs/1624963>
[03:23] <mup> PR snapd#1939 opened: Update documentation on testing snapd <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1939>
[04:19] <mup> Bug #1602752 changed: Add support for timezone-read interface <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1602752>
[05:39] <mup> PR snapd#1939 closed: Update documentation on testing snapd <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1939>
[06:32] <mup> PR snapd#1937 closed: image: ensure local snaps are put last in seed.yaml  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1937>
[06:37] <mcphail> mwhudson: thanks!
[06:50] <dholbach> hey hey
[06:58] <stub> When I say 'Snap Store' in my documentation, what URL should I be linking to?
[07:28] <mup> PR snapd#1938 closed: asserts: check that validation assertions are signed by the publisher of the gating snap <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1938>
[07:36] <mup> PR snapd#1940 opened: asserts: define a bit less terse Ref.String <Created by pedronis> <https://github.com/snapcore/snapd/pull/1940>
[07:48] <zyga> mwhudson: hey :)
[07:48] <zyga> mwhudson: I'll work on release today :) happy to finally reach this point
[07:56] <mup> PR snapd#1932 closed: add HACKING.md and move content from README.md over <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1932>
[08:17] <zyga> jdstrand, tyhicks: https://github.com/snapcore/snap-confine/pull/147
[08:17] <mup> PR snap-confine#147: Implement secure_getenv(3) if not provided by stdlib <Created by zyga> <https://github.com/snapcore/snap-confine/pull/147>
[08:19] <zyga> lool: https://github.com/snapcore/snap-confine/pull/147
[08:19] <mup> PR snap-confine#147: Implement secure_getenv(3) if not provided by stdlib <Created by zyga> <https://github.com/snapcore/snap-confine/pull/147>
[08:22] <mwhudson> zyga: oh yeah, you'll need to find a DD to do the thing that lets you upload the package
[08:23] <zyga> mwhudson: I need to refresh my memory on the process
[08:23] <zyga> mwhudson: I'll do a sdist release without tagging as soon as 147 lands and do a round of packaging and distro testing
[08:24] <zyga> mwhudson: then officially tag and start pushing downstream
[08:24] <mwhudson> zyga: https://wiki.debian.org/DebianMaintainer#Granting_Permissions
[08:24] <mwhudson> zyga: sounds good
[08:24] <zyga> thank you!
[08:27] <mup> PR snapd#1920 closed: --lazy is only available with -l in trusty <Created by vosst> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1920>
[08:39] <mup> PR snapd#1873 closed: interfaces: disable auto-connect in libvirt interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1873>
[08:39] <mup> PR snapd#1940 closed: asserts: define a bit less terse Ref.String <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1940>
[08:53] <ogra_> cjwatson, looks like LP tries to upload the .manifest files now (thanks for publishing them !) ... i got mails from tonights auto-builds: " __all__: The upload does not appear to be a valid package."
[08:56] <ogra_> mvo, could you approve https://myapps.developer.ubuntu.com/dev/click-apps/5912/rev/3/ ? and give me upload access to the beagleblack gadget (i have a working beagle image here)
[08:59] <mvo> ogra_: we probably need to republish the beaglblack under a different publisher, e.g. beagleblack.ogra ? or just beagle.ogra or something
[09:00] <ogra_> mvo, ok, i can do that
[09:00] <mvo> ogra_: great, thank you
[09:04] <lool> zyga: thanks for adding secure_getenv; wanted to do it over the week-end but ended up debugging other things
[09:13] <zyga> matteo: hey
[09:13] <matteo> hi zyga
[09:13] <zyga> matteo: would you mind doing a quick test build of snap-confine from this branch https://github.com/snapcore/snap-confine/pull/147/files
[09:13] <mup> PR snap-confine#147: Implement secure_getenv(3) if not provided by stdlib <Created by zyga> <https://github.com/snapcore/snap-confine/pull/147>
[09:13] <zyga> matteo: I will do a release shortly, I just want to make sure it works outside of glibc
[09:14] <matteo> you mean with MUSL?
[09:15] <zyga> yes
[09:19] <matteo> I'm using glibc on OpenWrt, but I can rebuild the toolchain
[09:21] <zyga> matteo: hmm, I thought that openwrt used musl
[09:21] <zyga> lool: ^ where did you end up using musl?
[09:21] <matteo> sure, by default
[09:21] <lool> zyga: I can do a build with musl
[09:21] <matteo> but I switched to glibc to be sure that it works
[09:21] <lool> after lunch
[09:22] <zyga> lool: thanks
[09:22] <zyga> matteo: I see, thanks
[09:22] <zyga> matteo: I guess lool will do the check
[09:22] <matteo> zyga: I didn't want to add extra entropy to the system :D
[09:22] <zyga> hehe :)
[09:22] <zyga> is openwrt ususally using musl?
[09:24] <timothy> openwrt can also use uclibc
[09:24] <ogra_> mwhudson, in bug 1624329 i dont want you to fix firstboot ... thats mvo's job i guess :) but i want the network device to work after i plugged in a cable (it doesnt, even if i cancel console-conf to have it start over from scratch)
[09:24] <mup> Bug #1624329: snapd firstboot setup fails constantly when rebooting before console-conf has finished <Snappy:New> <snapd (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1624329>
[09:25] <mwhudson> ogra_: that's super odd
[09:25] <mwhudson> (the device not appearing)
[09:25] <matteo> timothy: time ago, now it's dropped it for most architectures
[09:25] <timothy> you can still choose it from make menuconfig
[09:26] <matteo> it's the default on archs unsupported by MUSL
[09:26] <mwhudson> ogra_: to get the devices it just does (roughly) pyudev.Context().list_devices(subsystem='net')
[09:26] <ogra_> it appears but i cant configure it
[09:26] <mwhudson> ogra_: there's nothing cached between invocations...
[09:26] <matteo> yes, you can choose it if you really like broken C libraries
[09:26] <ogra_> weird
[09:26] <mwhudson> ogra_: i finally dug my dragonboard out today so i can experience some of your pain more faithfully tomorrow :)
[09:27] <ogra_> hah, great
[09:27] <ogra_> i'm just playing with a beaglebone image here ... thats even more odd
[09:27] <mwhudson> i have a pile of hardware that i think strictly speaking belongs to linaro
[09:27] <mwhudson> a panda, beagleboard xm, arndale
[09:27] <ogra_> (beautiful oopses on boot and no network device at all ... )
[09:28] <ogra_> (on second boot all is fine ... but then firstboot is already in a wonky state)
[09:29] <mwhudson> ogra_: how do you connect to dragonboard serial?
[09:29] <mwhudson> i have a fdti thing but i never got it to work
[09:29] <ogra_> with the mezzanine board that got shipped along :P
[09:29] <mwhudson> ah heh clearly i bought mine too early
[09:30] <ogra_> well, the company bought mine
[09:30] <mwhudson> well yes, mine too
[09:30] <mwhudson> but it was before that sort of thing was available
[09:31] <mwhudson> ogra_: this one? https://www.seeedstudio.com/96Boards-UART-p-2525.html
[09:31] <ogra_> yep
[09:32] <zyga> mwhudson: it's fiddly
[09:32] <zyga> mwhudson: I had mine but it's easy to make it not work
[09:32] <zyga> mwhudson: as a quick test, check if the daughter board works by itself
[09:33] <zyga> mwhudson: I also found that the board has to be aligned properly vertically, it can easily bend back and forth and this makes the connection fail
[09:34] <mwhudson> zyga: can't possibly be more fiddly than the http://www.digikey.co.nz/product-detail/en/ftdi-future-technology-devices-international-ltd/TTL-232RG-VIP-WE/768-1069-ND/2441358 i was trying to use before
[09:34] <ogra_> mvo, http://paste.ubuntu.com/23202066/ ... could we make the firstboot service run after console-conf somehow ?
[09:35] <zyga> mwhudson: heh, well, you can always use those simple ftdi cables with female connectors
[09:35] <mwhudson> ogra_: that's netplan segfaulting?
[09:35] <mwhudson> zyga: ?
[09:38] <ogra_> mwhudson, thats a kernel oops of the NIC ... my prob is that firstboot is from then on broken, even if i have a boot without oops
[09:38] <zyga> mwhudson: a usb serial from ftdi where each connector is a separate cable with female connector, just plug those over and it should work
[09:38] <zyga> mwhudson: (just make sure not to fry the board)
[09:38] <mwhudson> zyga: huh i didn't see that one when i was looking ~15 months ago
[09:38] <mwhudson> anyway i'll try the one i have and order a mezzanine if i can't make it work
[09:38] <zyga> mwhudson: http://www.aliexpress.com/store/product/USB-to-TTL-Serial-Cable-Adapter-FTDI-Chipset-PL2303HX-USB-Cable-Computer-Cable/1180713_1889042442.html
[09:38] <zyga> mwhudson: something like this
[09:38] <mvo> ogra_: hm, that would make sense, this way we have ntp hopefully
[09:38] <mwhudson> zyga: the dragonboards connectors are themselves female aren't they?
[09:38] <zyga> hmmm, are they? sorry I don't have one in front of me
[09:38] <zyga> (there are male variants of the thing as well)
[09:38] <ogra_> mvo, well, i dont care that much about ntp ... more about having network at all
[09:39] <ogra_> ppisati_, http://paste.ubuntu.com/23202086/ ... beaglebone (with linux-generic xenial)
[09:42] <ppisati_> cking: ogra_ :O
[09:42] <ppisati_> ops
[09:42] <ppisati_> ogra_: :O
[09:42] <ogra_> yeah :/
[09:42] <cking> ?!
[09:42] <ogra_> i blame pitti .... netplan tries to start the network :)
[09:42] <ppisati_> ogra_: yeah, put the blame on pitti
[09:42] <ogra_> hehe
[09:42] <ogra_> let me build a public image so you can tinker with it
[09:42] <ppisati_> ogra_: ta
[09:42] <ogra_> (gimme 10-15min)
[09:42] <ppisati_> ogra_: is that a beaglebone black?
[09:42] <ogra_> yep
[09:42] <ppisati_> k
[09:42] <ogra_> with 4.4.0-36-generic
[09:43] <ogra_> it works better on subsequent boots btw ... on first boot i always get the oops, reliably ... on subsequent ones it only happens very random
[09:44] <ppisati_> weird
[09:44] <ogra_> yep
[09:56] <ogra_> ppisati_, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has the beagle image now
[09:58] <mup> PR snapd#1941 opened: interfaces/builtin: allow mmaping pulseaudio buffers <Created by zyga> <https://github.com/snapcore/snapd/pull/1941>
[10:00] <ppisati_> ogra_: cool, i'll give it a spin
[10:03] <ogra_> mvo, hmm, looks like it would just help if firstboot.go wouldnt create an empty state.json file when there is no network ...
[10:04] <ogra_> mvo, if i do: "sudo rm /var/lib/snapd/state.json && sudo systemctl restart snapd.firstboot.service && sudo reboot" it works fine
[10:04] <cjwatson> ogra_: Hm, that exact message doesn't appear in the LP source tree.  URL to the failing build?
[10:05] <ogra_> i have four of them ... one sec ...
[10:05] <ogra_> https://launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/5109
[10:05] <mvo> ogra_: yeah, three are some easy wins here
[10:05] <ogra_> equally 5107, 5108 and 5110
[10:07] <cjwatson> ogra_: Ah, right.  Please file a bug against LP itself - we'll need to be more selective about which files we upload to the store
[10:10] <ogra_> cjwatson, yep ... it is blocking all upload apart from ppc64el and s390x now it seems ... i assume these two dont generate manifests
[10:10] <ogra_> *uploads
[10:10] <cjwatson> ogra_: Dropping the manifest temporarily will work around it.
[10:10] <ogra_> k
[10:10] <cjwatson> ogra_: But I should be able to fix it reasonably quickly.
[10:11] <ogra_> thats good enough :)
[10:11] <ogra_> ok
[10:26] <ogra_> cjwatson, Bug #1625117 for you
[10:26] <mup> Bug #1625117: store uploads fail since os snaps publish manifest files <Launchpad itself:New> <https://launchpad.net/bugs/1625117>
[10:27] <cjwatson> Ta
[10:33] <mup> PR snapd#1942 opened: Initial support for download deltas (via SNAPPY_DELTA_DOWNLOAD_FORMATS) <Created by absoludity> <https://github.com/snapcore/snapd/pull/1942>
[10:54] <mup> PR snapd#1943 opened: wrappers: add new X-Snap-Exec=$snap.$app support to .desktop files <Created by mvo5> <https://github.com/snapcore/snapd/pull/1943>
[10:55] <mvo> seb128: https://github.com/snapcore/snapd/pull/1943 this is what you asked for last week, right?
[10:55] <mup> PR snapd#1943: wrappers: add new X-Snap-Exec=$snap.$app support to .desktop files <Created by mvo5> <https://github.com/snapcore/snapd/pull/1943>
[11:42] <mectors> how do I use the content plug to allow a snap to read the directory /root/.certs/?
[11:43] <ogra_> you would need a snap that provides /root i guess (no, thats not possible)
[11:43] <ogra_> and i doubt you will have any access to "dot" dirs anyway ...
[11:52] <mectors> ogra: thanks
[12:06] <mectors> ogra: how do I execute a script to change a file so I can rewrite the directories?
[12:08] <mectors> basically execute a sed s/root/$SNAP_DATA/
[12:13] <ogra_> mectors, i'D use a wrapper script
[12:35] <morphis_> niemeyer: was about to try the spread snap, how is that supposed to work for local backends like kvm or lxd?
[12:36] <morphis_> getting errors like: 2016/09/19 14:33:36 Cannot allocate qemu:ubuntu-16.04: cannot launch qemu qemu:ubuntu-16.04: exec: "kvm": executable file not found in $PATH
[12:37] <mectors> ogra: how does a wrapper script work?
[12:44] <tenaciousmv> hi. I'm trying to get the nodejs-plugin-based shout demo working: https://github.com/snapcore/snapcraft/tree/master/demos/shout   when I build and install it locally, i don't see anything in /snap/bin afterward
[12:44] <tenaciousmv> but when i run `snap install shout` instead it works
[12:45] <tenaciousmv> i used --force-dangerous for the local install
[12:45] <tenaciousmv> snapcraft v 2.17
[12:46] <ogra_> mectors, https://github.com/ogra1/laidout ... look at snapcraft.yaml and wrapper.sh there ... thats a very simple wrapper script
[12:47] <mectors> ogra: thanks
[12:57] <fearing> found this in my history just seeing what this is
[12:58] <zyga> jdstrand: hello
[12:58] <ogra_> ppisati_, btw, bug 1625177
[12:58] <mup> Bug #1625177: OOPS on beaglebone on boot of 4.4.0-36-generic under snappy ubuntu core xenial <linux (Ubuntu):New> <https://launchpad.net/bugs/1625177>
[12:58] <jdstrand> zyga: hi!
[12:59] <zyga> jdstrand: hey, I merged secure_getenv improvement, I noticed your NAK in the morning
[12:59] <zyga> jdstrand: I'd appreciate a post-merge review of this 3 line function
[12:59] <zyga> jdstrand: just to be on the safe side :)
[13:00] <zyga> jdstrand: I'd like to file the bugs for apparmor issues we found last week
[13:00] <zyga> jdstrand: do you have a preference? is launchpad oka?
[13:02] <sergiusens> can't you just command do `command: desktop-launch $SNAP/usr/bin/laidout "$@"`?
[13:02] <sergiusens> err, without the $@
[13:03] <ogra_> sergiusens, yeah, that snap is super old ... from a time where the desktop-launcher stuff was still in development
[13:03] <ogra_> and it was only a proof of concept to show someone that i can make a snap from an upstream binary in less than 10min
[13:03] <jdstrand> zyga: thanks for fixing that. I'll take a look. I filled the apparmor bug already
[13:03]  * jdstrand looks for it
[13:04] <ogra_> sergiusens, effectively the wrapper is nonsense there ... at least nowadays (and i doubt with the new laucnehrs it wouldnt even build anymore)
[13:04] <jdstrand> zyga: https://bugs.launchpad.net/apparmor/+bug/1624497
[13:04] <mup> Bug #1624497: complain mode blocks access to nsfs (/proc/self/ns/*) without exec rule <AppArmor:Confirmed> <https://launchpad.net/bugs/1624497>
[13:09] <sergiusens> zyga are you aware of any missing interface work to get tray icons to work? My telegram snap has the forbidden icon since forever and I know that kyrofa has some snaps in that state too
[13:10] <zyga> sergiusens: no, is there a bug report for this somewhere?
[13:10] <zyga> sergiusens: I'll check out your snap later today so that I can perhaps see this myseld
[13:11] <sergiusens> zyga hmm, kyrofa or seb128 I guess would know
[13:13] <seb128> sergiusens, zyga, could be bug #1600136
[13:13] <mup> Bug #1600136: App indicator does not show icon for Qt apps <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1600136>
[13:13] <seb128> it's trying to use /tmp to share the icon
[13:14] <didrocks> sergiusens: that's what we discussed during the heidelberg sprint (and the bug seb128 referenced). Main issue is this /tmp thing in appmenu-qt
[13:17] <zyga> jdstrand: one tiny unrelated issue, the base profile doesn't allow xdg-open
[13:17] <zyga> jdstrand: and the executable in the core snap (which is probably out of date anyway) is in /usr/local
[13:18] <zyga> jdstrand: I was thinking about adding it to the main template
[13:18] <zyga> jdstrand: to /usr/bin/xdg-open xi,
[13:19] <jdstrand> zyga: I would think that the unity7 interface would make more sense. it is only for desktop applications, no?
[13:19] <zyga> jdstrand: well, I don't know
[13:19] <zyga> jdstrand: perhaps
[13:19] <zyga> jdstrand: though at the same time, I don't know
[13:19] <jdstrand> "xdg-open is for use inside a desktop session only. It is not recommended to use xdg-open as root."
[13:20] <jdstrand> from it's man page
[13:20] <zyga> jdstrand: in any case we need to have it somewhere and document it
[13:20] <jdstrand> please use unity7 for now. we can move it to default if required, but I don't think we will
[13:20] <jdstrand> also, yeah, moving out of /usr/local would be good too
[13:21] <jdstrand> I'm not sure how that would work on an actual desktop though...
[13:21] <zyga> jdstrand: on the desktop there's snapd-xdg-open
[13:21] <zyga> jdstrand: we need to keep things in sync as AFAIK they drifted apart now
[13:21] <zyga> jdstrand: I'll try to untangle it
[13:21] <jdstrand> well, now I'm confused
[13:22] <jdstrand> ok, so snapd-xdg-open is what snapd provides, not xdg-open?
[13:24] <didrocks> jdstrand: snapd-xdg-open is the service on the desktop side answering to our fake xdg-open requests over dbus
[13:24] <didrocks> (and snapd-xdg-open calls the real xdg-open on the desktop)
[13:24] <jdstrand> so why is zyga requesting we add xdg-open to the policy?
[13:24] <ogra_> there is one xdg-open *inside* the ubuntu-core snap ... thats the one in /usr/local ... on the desktop side there is /usr/lib/x86_64-linux-gnu/snapd-xdg-open which (as i understand) is supposed to talk to the oone inside the snap
[13:25] <ogra_> and this is all along with the default xdg-open you have installed on a desktop anyway
[13:25] <jdstrand> shouldn't the one in /usr/local go away then?
[13:26] <jdstrand> (in the all snaps image)
[13:26] <ogra_> well, it should surely move to /usr/bin
[13:26] <seb128> that one is our small wrapper doing the dbus call
[13:26] <zyga> jdstrand: yes
[13:26] <jdstrand> and people just use snapd-xdg-open?
[13:26] <zyga> jdstrand: I don't know how it managed to get there TBH
[13:26] <seb128> snapd-xdg-open is on the host
[13:26] <seb128> not in the snap
[13:26] <zyga> jdstrand: no, people use xdg-open
[13:26] <jdstrand> man, this is confusing
[13:26] <ogra_> ah, well, i dont know if snapd-xdg-open? doesnt need the one inside the snaps
[13:26] <zyga> jdstrand: that talks to snapd-xdg-open in the distro
[13:26] <seb128> that's the service listening to the dbus call
[13:26] <jdstrand> so on all snaps, we call it xdg-open, but it is really a wrapper. on desktop it is snapd-xdg-open cause the real xdg-open is not snapd-xdg-open
[13:27] <jdstrand> let's back up
[13:27] <seb128> can't parse that
[13:27] <jdstrand> what are snaps supposed to use?
[13:27] <seb128> define snaps?
[13:27] <zyga> no, it works the same way everywhere
[13:27] <zyga> or actually
[13:27] <zyga> no
[13:27] <jdstrand> a snap of type: app
[13:27] <seb128> you mean what is a desktop snapped app supposed to use?
[13:27] <didrocks> jdstrand: you basically have: xdg-open (fake, in /usr/local), called by the snap app <------ dbus --------> snapd-xdg-open (service, activated by fake /usr/local) which execs real xdg-open
[13:27] <zyga> on classic the core snap has 'xdg-open' that talks over dbus to snapd-xdg-open
[13:27] <didrocks> the first one is inside the snap/ubuntu-core
[13:28] <didrocks> the second part of the array is on the destkop
[13:28] <ogra_> zyga, http://paste.ubuntu.com/23202842/  ... its a buuld time hack
[13:28] <ogra_> *build
[13:28] <seb128> didrocks, to be exact that uses gio and doesn't execs the real xdg-open ;-)
[13:28] <jdstrand> with didrocks explanation, why do we need to add anything to the policy-- the xdg-open that talks to snapd-xdg-open is in the snap
[13:29] <didrocks> seb128: indeed, to keep the service running :) :p
[13:29] <seb128> well apparently snapd denies /usr/local/xdg-open to be exec
[13:29] <jdstrand> seb128: what is the system /usr/local/xdg-open supposed to be used by?
[13:30] <seb128> random code
[13:30] <jdstrand> to do what?
[13:30] <seb128> open an url
[13:30] <ogra_> /usr/local/bin/xdg-open FWIW :)
[13:30] <jdstrand> meh
[13:30] <seb128> random admin script, desktop apps, command line apps do "xdg-open http:...."
[13:31] <jdstrand> I'm not trying to be obtuse, I'm trying to be very specific. there are several things called xdg-open. zyga wants to adjust the policy. I want to know how the pieces fit together
[13:31] <seb128> we also associate that wrapper with "http:"
[13:31] <didrocks> for instance, Qt openUrl() is wrapping qtsubprocess.call("xdg-open url") (or whatever is the correct syntax)
[13:31] <seb128> jdstrand, http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/500-create-xdg-wrapper.binary
[13:31] <jdstrand> seb128: so why wouldn't that snap ship xdg-open like snaps on classic do?
[13:31] <seb128> code might be easier than words
[13:31] <jdstrand> but that is on classic
[13:31] <ogra_> that is why i posted it above :P
[13:31] <seb128> I don't understand that question
[13:31] <seb128> that wrapper is part of the ubuntu-core image
[13:32] <seb128> why would snap need to ship it?
[13:32] <jdstrand> look
[13:32] <didrocks> seb128: I think jdstrand is asking, why aren't we asking every snap app using xdg-open to ship it as part of the code
[13:32] <seb128> because it's easier to have it in the base image?
[13:32] <jdstrand> I understnad what snappy's xdg-open is supposed to do. I'm trying to reconcile classic and all snaps
[13:32] <didrocks> jdstrand: am I right on your question? ^
[13:32] <jdstrand> didrocks: you are
[13:33] <didrocks> I think shipping it on runtime snaps might make sense
[13:33] <jdstrand> and if it is right to be in the base image, why are we doing things different between classic and all snaps?
[13:33] <didrocks> as the usage of xdg-open is often by the toolkit
[13:33] <didrocks> not directly or in a awareness-way by the app
[13:33] <seb128> that's not true
[13:33] <seb128> if you look on codesearch.debian.net you can see it's used by stack of random command line tools
[13:33] <seb128> like mutt
[13:33] <seb128> or mc
[13:34] <seb128> or backup script things
[13:34] <didrocks> yeah, cli ones might do it…
[13:34] <jdstrand> what is interesting about xdg-open on all snaps is there is no desktop by default
[13:34] <jdstrand> so shipping it is kinda weird
[13:34] <seb128> doesn't need to be a desktop for it to work
[13:34] <seb128> it's just a wrapper to call the appropriate handle
[13:34] <seb128> that could be links
[13:35] <jdstrand> the man page for xdg-open says it needs to run in a desktop session
[13:35] <seb128> we are not using xdg-open though
[13:35] <jdstrand> but we are meant to replace it
[13:35] <seb128> we are diverting the command to call our handler that opens a browser
[13:35] <jdstrand> and a browser isn't on all snaps
[13:36] <sergiusens> didrocks seb128 thanks
[13:36] <seb128> how is "open an url" supposed to work on all snaps?
[13:36] <jdstrand> that's a great question
[13:36] <jdstrand> I don't think anyone defined that
[13:36] <ogra_> yeah, thats future work
[13:36] <jdstrand> (which is what I'm really getting at)
[13:37] <seb128> can we get the cheap trick we currently have to work then?
[13:37] <seb128> until that proper job is done
[13:37] <jdstrand> how would it work?
[13:37] <seb128> on classic I mean
[13:37] <jdstrand> you call xdg-open and nothing happens
[13:37] <zyga> jdstrand: (offtopic): https://github.com/snapcore/snapd/pull/1941
[13:37] <mup> PR snapd#1941: interfaces/builtin: allow mmaping pulseaudio buffers <Created by zyga> <https://github.com/snapcore/snapd/pull/1941>
[13:37] <seb128> well what we currently have would make urls work on classic
[13:37] <seb128> if snap-confine wasn't blocking the xdg-open exec
[13:38] <jdstrand> seb128: yes, of cousre we want it on classic. which is why I suggested unity7, but then didrocks said that snaps on classic should ship it
[13:38] <zyga> (that's snapd, snap-confine just does what it is told to do)
[13:38] <jdstrand> seb128: which brings us full circle-- why do we need to allow it in the policy if apps are meant to ship it
[13:38] <zyga> jdstrand: we don't want snaps on classic to ship xdg-open
[13:38] <seb128> I disagree with having every app to ship it
[13:38] <didrocks> I didn't say that, I said if we don't want to ship it on ubuntu core snap, maybe having it as part of the toolkit makes sense
[13:38] <zyga> jdstrand: because then we are stuck with the interface forever
[13:39] <didrocks> but seb128 has some good arguments about cli apps
[13:39]  * jdstrand doesn't care where it is shipped-- just trying to find the right place
[13:39] <jdstrand> /usr/local is not the right place btw
[13:39] <jdstrand> that is for admins, not system installed software
[13:40] <didrocks> I think attente shipped it there because he didn't want to conflict in case we have a "personal snap" shipping the system version
[13:40] <seb128> that's also where we have you fake "apt" that tells you that apt is not supported
[13:40] <didrocks> but my memory could be skewed :)
[13:40] <didrocks> and good point seb128 ;)
[13:40] <seb128> you->our
[13:40] <jdstrand> that is an abuse of /usr/local
[13:40] <seb128> but the reason is probably what did said
[13:40] <jdstrand> anyway
[13:41] <seb128> I'm not going to discuss that, it was not my doing but mvo's
[13:41] <seb128> I'm happy for it to change location
[13:42] <mvo> jdstrand: /usr/local/bin/{apt,xdg-open} should change location? sure
[13:43] <jdstrand> that's kinda a side discussion, but it did add to my confusion
[13:44] <seb128> so summary is
[13:44] <jdstrand> fyi, nothing in snap-confine mounts /usr/local from the os for classic for that to work anyway (afaics)
[13:45] <seb128> well, that dir is part of ubuntu-core
[13:45] <seb128> I didn't try in recent weeks but the fake "apt" command was in the snaps last time I tried
[13:45] <jdstrand> it is. I'm thinking through what should be done
[13:45] <seb128> so the ubuntu-core /usr/local/bin was available inside the snaps
[13:45] <ogra_> but is it in PATH ?
[13:45] <seb128> yes
[13:46] <jdstrand> I guess it probably should be in the core snap, but since nothing in all snaps uses it, that makes me slightly uncomfortable, but I guess there is nothing better that can be done
[13:47] <jdstrand> especially if there is defined future work for making it work on all snaps
[13:48] <jdstrand> so for now, leaving it in the core snap (but please move it to /usr/bin so we are using the correct locations and for avoiding confusion in the future) and add '/usr/bin/xdg-open ixr,' to the unity7 interface makes the most sense. at least that way if someone on all snaps tries to use it we are suggesting that it isn't supported yet
[13:49] <jdstrand> that's my opinion. does that make sense to others? ^ (seb128, didrocks, zyga, mvo)
[13:50] <seb128> jdstrand, that wfm, though it's a crossdesktop thing and used by command line tools often so unsure unity7 is the right interface
[13:51] <seb128> jdstrand, like mutt would probably end up using it to open an url
[13:51] <seb128> unsure how much of a big hammer it is to recommend those to use unity7
[13:51] <jdstrand> seb128: because today the thing it is replacing is documented as requiring a desktop session and because we haven't defined what it should look like without a desktop session
[13:52] <seb128> right, it should need one
[13:52] <jdstrand> when we do, it can be moved/added to somewhere else, perhaps the default policy
[13:52] <seb128> but unity7 give you quite some things
[13:52] <seb128> but I guess fair enough for now
[13:52] <jdstrand> it could be a separate interface
[13:53] <jdstrand> I'm uncomfortable adding it to the default policy because it requires dbus
[13:53] <mup> PR snapd#1941 closed: interfaces/builtin: allow mmaping pulseaudio buffers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1941>
[13:53] <seb128> I see
[13:53] <didrocks> jdstrand: wfm as well
[13:53] <seb128> well unity7 should do for now
[13:54] <mup> PR snapd#1944 opened: many: validate refreshes against validation assertions by gating snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/1944>
[13:56] <jdstrand> zyga: so, sounds like adding it to unity7 is the way to go for now since we only support it on classic desktop atm (a comment saying as much would be good). it sounds like mvo may move it from /usr/local. not sure if that is something you would want to do as part of this
[13:57] <zyga> jdstrand: OK
[13:57] <zyga> jdstrand: will do
[13:57] <jdstrand> zyga: if it would help, I could do it. I always have a list of miscellaneous updates :)
[13:59] <zyga> jdstrand: if you want to, sure go ahead :)
[13:59] <zyga> jdstrand: I'm looking at snap-confine SRU paperwork now
[14:01] <mvo> jdstrand: I can look into the move to /usr/bin later, probably tomorrow morning
[14:02] <jdstrand> mvo: ok, I'll just add the access to /usr/local and mention in the PR it should be adjusted when it is moved
[14:06] <mvo> jdstrand: great, thank you
[14:18] <tenaciousmv> sergiusens: do you know of a nodejs-based snap that works when locally built and installed? See my comment above about shout working only when installed from snapcraft store
[14:19] <sergiusens> tenaciousmv see your comment where?
[14:20] <sergiusens> and yes, it works, our tests make sure of that (shout is in demos)
[14:20] <kyrofa> sergiusens, zyga I'm not sure where was ever a bug filed since we never really got to the point where we knew what was causing the bug. didrocks said it needed some love from the desktop team. I was planning on starting an email thread once I had enough spare brainpower for it
[14:24] <tenaciousmv> sergiusens: repasting comment: hi. I'm trying to get the nodejs-plugin-based shout demo working: https://github.com/snapcore/snapcraft/tree/master/demos/shout  when I build and install it locally, i don't see anything in /snap/bin afterward
[14:28] <tenaciousmv> sergiusens: i'm glad the tests pass :) i wonder what i could be doing wrong. I just built, installed (with --force-dangerous) and shout is not in /snap/bin
[14:28] <seb128> mvo, sorry I forgot to reply to your ping earlier, unsure that's best, I would rather not have to modify the upstream .desktop, what sergiusens suggested and sounded nicer was to have that snapcraft.yaml define the .desktop name and let you override the exec and do the sed-ing for you
[14:29] <kyrofa> tenaciousmv, the app is a service, which means it generates a systemd unit file instead
[14:29] <kyrofa> tenaciousmv, it won't put anything in /snap/bin/
[14:29] <mvo> seb128: works for me, just copy/paste this comment in the PR and I will close it
[14:30] <tenaciousmv> kyrofa: after snap install shout, i see it in /snap/bin
[14:31] <tenaciousmv> though `which snap` return /usr/bin/snap
[14:32] <tenaciousmv> is the verion of shout in the store the one built from the snapcraft.yaml in demos?
[14:33] <kyrofa> tenaciousmv, no idea. Who is the publisher?
[14:33] <seb128> mvo, k
[14:34] <tenaciousmv> kyrofa: sergiusens
[14:34] <kyrofa> tenaciousmv, I'm not sure what he has there. All I know is that this: https://github.com/snapcore/snapcraft/blob/master/demos/shout/snapcraft.yaml will not put anything in /snap/bin/
[14:36] <tenaciousmv> kyrofa: right, exactly
[14:36] <tenaciousmv> kyrofa: so how would you run the shout from the demos after installing it?
[14:37] <kyrofa> tenaciousmv, it should already be running-- it's a daemon
[14:37] <kyrofa> (once you install it, obviously)
[14:37] <kyrofa> I'm not sure about the port, though
[14:39] <tenaciousmv> kyrofa: so i should be able to see it in service --status-all then no?
[14:39] <tenaciousmv> kyrofa: thx for helping btw
[14:40] <kyrofa> tenaciousmv, now sure what the `service` command does nowadays, but you should be able to see if with `systemctl status snap.shout.server.service` I think
[14:40] <kyrofa> s/if/it/
[14:41] <tenaciousmv> kyrofa: indeed, i see it!
[14:44] <tenaciousmv> kyrofa: is there an example of a nodejs app (not a daemon)?
[14:45] <kyrofa> tenaciousmv, not that I know of off the top of my head, but you could make the shout one an example if you simply remove the `daemon: simple` line
[14:45] <tenaciousmv> kyrofa: ah, duh. Thanks!
[14:48] <mup> PR snapd#1943 closed: wrappers: add new X-Snap-Exec=$snap.$app support to .desktop files <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1943>
[14:53] <sergiusens> tenaciousmv that demo doesn't setup anything to be in snap/bin
[14:53] <tenaciousmv> sergiusens: yea, kyrofa explained it to me. I missed the daemon line in the snapcraft.yaml
[14:53] <sergiusens> tenaciousmv shout on the store is in my repo, not in the demos
[14:54] <tenaciousmv> sergiusens, ok will check it out
[14:59] <mup> PR snapd#1945 opened: Spread out to trusty <Created by vosst> <https://github.com/snapcore/snapd/pull/1945>
[15:00] <mup> PR snapcraft#811 opened: Support deb files as sources <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/811>
[15:01] <sergiusens> ogra_ ^ for you
[15:01] <sergiusens> morphis and maybe you too ;-) ^
[15:01] <ogra_> bug 1604669
[15:01] <mup> Bug #1604669: Support Installing a local deb package in the snapcraft <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1604669>
[15:01] <ogra_> ah
[15:02] <sergiusens> ogra_ ;-)
[15:02] <ogra_> :)
[15:07] <jdstrand> seb128: fyi, http://paste.ubuntu.com/23203145/. the all snaps one is more justification that this should still be in unity7 for the moment. the second is on my desktop with snapd 2.14.2
[15:08] <seb128> k, makes sense
[15:08] <seb128> jdstrand, your desktop doesn't have snapd-xdg-open installed right?
[15:08] <seb128> (we don't depends/recommends it afaik)
[15:08] <jdstrand> no
[15:08] <seb128> that's something we should change
[15:08] <jdstrand> perhaps we should on classic?
[15:09] <seb128> yes
[15:09] <seb128> mvo, ^ would you be the right person to add snapd-xdg-open to the snapd recommends?
[15:09] <jdstrand> snapd-xdg-open doesn't appear to be a package in xenial
[15:10] <seb128> it's in universe
[15:10] <seb128> https://launchpad.net/ubuntu/+source/snapd-xdg-open
[15:11] <seb128> oh, in xenial
[15:11] <seb128> it's in xenial-proposed only
[15:11] <jdstrand> I see
[15:11] <seb128> the SRU verification relies on having the wrapper in the ubuntu-core image and working
[15:12] <mhall119> lool: did you say there wouldbe RPi3 images of snappy ubuntu core today?
[15:13] <tedg> I'm trying to put a slot on a snap, but it doesn't seem to show up in "snap interfaces" list
[15:13] <tedg> Does anyone have a snapcraft.yaml of putting a slot on a snap that I could crib from?
[15:14] <lool> mhall119: at least pi2; I'd hope pi3 as well
[15:15] <lool> zyga: FTBFS with musl: http://paste.ubuntu.com/23203170/
[15:16] <lool> zyga: missing include probably?
[15:16] <lool> I'll double check I have the right version pulled from the build
[15:18] <jdstrand> pcoca: hi!
[15:18] <jdstrand> pcoca: do you have a moment to talk about bug #1613572 ?
[15:18] <mup> Bug #1613572: sandbox denials for snaps on BTLE device <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1613572>
[15:19] <mup> PR snapcraft#805 closed: Refresh discharge macaroon if necessary <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/805>
[15:19] <mhall119> lool: when and where will those be available?
[15:20] <lool> zyga: http://paste.ubuntu.com/23203191/
[15:21] <tedg> Huh, seems that mongo22 doesn't have a slot either.
[15:21] <lool> zyga: right, you missed #include secure-getenv.h in sc-main.c
[15:22] <ogra_> mhall119, dailies (built from the edge channel) are at  http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ .. and beta releases are just being announced by mvo
[15:23] <ogra_> http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
[15:23] <mhall119> thanks ogra_
[15:24] <tedg> bluez does, cribbing from there
[15:28] <lool> zyga: adding the #include is enough to fix build http://paste.ubuntu.com/23203216
[15:28] <lool> it fails in other components later
[15:31] <lool> zyga: http://paste.ubuntu.com/23203233/
[15:32] <popey> mhall119: https://lists.ubuntu.com/archives/snapcraft/2016-September/001166.html :)
[15:35] <mhall119> literally 10 minutes ago, that's timing :)
[15:37] <zyga> lool: looking
[15:37] <zyga> lool: oh, indeed
[15:38] <zyga> lool: thanks, I'll put that into the relase
[15:41] <zyga> lool: pushed
[15:42] <lool> zyga: lovely, thanks
[15:43] <lool> updated my openwrt feed to point at it
[15:44] <lool> mhall119: http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
[15:44] <lool> ah too late
[15:47] <ogra_> lool, yeah, and lame too ... http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has so many more exciting bugs
[15:49] <mhall119> lol
[15:54] <diddledan> I've reordered the list on https://github.com/ubuntu/snappy-playpen/wiki/SandPit to be alphabetical (also added my attempt at corebird to the list)
[16:07] <oparoz> Hello, what's the difference between mvo's all-snaps images and the ones available at cdimage?
[16:18] <ogra_> oparoz, the cdimage ones are official beta images
[16:18] <ogra_> the mov all-snaps ones are obsolete
[16:19] <ogra_> *mvo
[16:19] <oparoz> Thanks ogra_ . Does that mean that zyga's script to built images can be updated to point to the beta images? https://github.com/zyga/devtools/blob/master/ubuntu-image
[16:20] <ogra_> oparoz, use http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ or if you like to live on the edge use http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
[16:20] <ogra_> everything else is dead beef and not supported anymore
[16:20] <oparoz> :)
[16:20] <ogra_> since they would be using  the wrong creation tool
[16:21] <oparoz> wrong creation tool?
[16:21] <dduffey> hi, I've tried various snappy 16 pi3 images but they all hang at the 4-rasberry screen
[16:21] <dduffey> lool, ^^^ what image are you using/
[16:22] <lool> dduffey: http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current is latest
[16:22] <lool> dduffey: you want serial console rather than console
[16:22] <lool> but I suppose console should work
[16:22] <ogra_> yeah
[16:22] <ogra_> dont use embedded boards without serial
[16:22] <ogra_> general rule of thumb
[16:23] <dduffey> lool, okay
[16:23] <tbr> +1 for UART
[16:23] <tbr> those things are dirt cheap
[16:23] <ogra_> yeah
[16:25] <ogra_> oparoz, sudo snap install ubuntu-image --devmode --edge ... then you need to create a signed model assertion and have a proper new gadget.yaml following the new format
[16:26] <dduffey> lool, thanks ... I am using that image ... normal for it not to hit the network until I plug in a serial console and setup networking, correct?
[16:26] <ogra_> dduffey, you need to run through the console-conf tool, yes
[16:26] <ogra_> else you dont have a user either
[16:26] <lool> dduffey: yes
[16:29] <oparoz> Thanks ogra_ . I think I'll just wait for you guys to provide the pi2 gadget and updated partitioning script to use an external HD :)
[16:29] <ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/ is up to date ... regarding the gadget :)
[16:32]  * ogra_ calls it a day
[16:32] <oparoz> Thanks ogra_
[16:32] <ogra_> np
[16:39] <mup> PR snapcraft#812 opened: New plugin: jhbuild <Created by attente> <https://github.com/snapcore/snapcraft/pull/812>
[16:58] <mup> PR snapd#1926 closed: tests: add https_proxy into environment as well <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1926>
[17:12] <mup> Bug #1625279 opened: cmd_run.go:179: WARNING: cannot create user data directory: cannot create "/home/$USER/snap/$SNAP/$VERSION": mkdir /home/$USER/snap/$SNAP: permission-denied <Snappy:New> <https://launchpad.net/bugs/1625279>
[17:17] <tyhicks> zyga: congrats on the release :)
[17:23] <sergiusens> so jdstrand or zyga is there a plan of action for LP #1600136 ?
[17:23] <mup> Bug #1600136: App indicator does not show icon for Qt apps <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1600136>
[17:27] <jdstrand> sergiusens: not from me. I gave several ideas on how the desktop team/someone familiar with the technologies could pursue
[17:27] <jdstrand> sergiusens: but no one responded
[17:28] <jdstrand> ultimately, the snaps are putting things in /tmp and that isn't the same /tmp that the system would see
[17:28] <sergiusens> jdstrand oh really, it might be a communication breakdown problem then as I suspect the desktop folk were pointing the other way
[17:28]  * sergiusens checks the bug report
[17:29] <jdstrand> well, I'm happy to discuss ways forward, but this is basically the same as all the stuff going into the desktop part. trying to make traditional applications that aren't designed for application isolation work
[17:31] <jdstrand> I suspect upstreams would be interested in patches because this would affect any sandboxing mechanism that uses a private /tmp (which is all of them afaik)
[17:31] <sergiusens> jdstrand I am going to play with my preload part and see what I can do; but patching upstreams would be ideal ;-)
[17:32] <sergiusens> in the case of telegram they already fork and patch Qt so I will try and see if they can take one more patch
[17:33] <mup> Bug #1625291 opened: ConnectedSlotSnippet not invoked when connecting two snaps <Snappy:New> <https://launchpad.net/bugs/1625291>
[17:36] <kyrofa> sergiusens, jdstrand at the sprint we realized the applications were sending icon blobs
[17:36] <kyrofa> sergiusens, jdstrand in dbus I mean
[17:36] <kyrofa> We couldn't figure out why they weren't showing up
[17:45] <jdstrand> kyrofa: I thought they were sending icon urls that were in /tmp. so the app puts it in its /tmp, but the system sees a different /tmp
[17:45] <mup> Bug #1623589 opened: No icons anymore <Snappy:New> <snapweb:Confirmed> <https://launchpad.net/bugs/1623589>
[18:12] <sergiusens> kyrofa wait, this isn't in the bug report
[18:12] <sergiusens> if it's blobs it should just work however inefficient that is
[18:13] <sergiusens> doesn't surprise me given other uses of bus I've seen :-P
[18:23] <tenaciousmv> sergiusens: another q about the nodejs plugin
[18:23] <tenaciousmv> sergiusens: running npm install as root sometimes has issues
[18:24] <kyrofa> jdstrand, sergiusens yeah that's what we all thought, but in heidelberg that didn't appear to be what was happening. I personally didn't update the bug because I was incredibly confused at that point :P
[18:24] <tenaciousmv> because of the way npm tries to downgrade privileges or sth
[18:24] <tenaciousmv> sergiusens: is there a way to run npm install not as root?
[18:24] <tenaciousmv> sergiusens: another technique people use is npm install -g --unsafe-perm <package>
[18:25] <tenaciousmv> sergiusens: to prevent user/group switching during the installation
[18:32] <jdstrand> kyrofa: ah, well, then perhaps more digging simply needs to be done then documented in the bug and we can go from there
[18:35] <kyrofa> jdstrand, indeed
[18:46] <mhall119> zyga: is there a way to specify environment variables in snapcraft.yaml yet?
[18:46] <tvoss> niemeyer: o/
[18:52] <niemeyer> tvoss: Heya
[18:52] <tvoss> niemeyer: hey, welcome back :)
[18:52] <niemeyer> tvoss: Glad to see your PRs coming up :)
[18:52] <niemeyer> tvoss: Thanks
[18:53] <niemeyer> tvoss: A few comments in one of them.. also, would just like to highlight the fact we have a convention on the summary
[18:53] <niemeyer> Please have a look at the list here to get an idea: https://github.com/snapcore/snapd/pulls
[18:53] <tvoss> niemeyer: yeah, let me rename them
[18:56] <dch> I'm packaging couchdb via snappy. It's important we have a migration story for our 1.6.x debian-style packages to a snappy-based one, and often they have very large databases 500GB upwards, so we can't "just" copy files around.
[18:56] <tvoss> niemeyer: working through your comments now
[18:56] <niemeyer> tvoss: Thanks again
[18:57] <dduffey> okay I have pi3 booting and visiable via usb serial ... it seems to be taking some time after "Stated update resolvconf for Networkd DNS." .. but no login prompt, etc.
[18:57] <dch> is it possible to allow a snap to access specific parts of the old existing filesystem, like /var/lib/couchdb or /etc/couchdb/*.ini ?
[18:58] <dch> I'm also interested in making the snap available for centos & redhat too, this looks very cool
[19:06] <mhall119> sergiusens: snapcraft is stripping quotes out of the "command:" parameter for my daemon, how can I stop that?
[19:06] <sergiusens> tenaciousmv don't run snapcraft as root
[19:08] <sergiusens> mhall119 it may just be a bug
[19:17] <kgunn> jdstrand: hey, so took strace of amd64 and arm64, they are strikingly similar...so i don't quite see why amd64 succeeds confined and arm64 gets a hard denial
[19:18] <kgunn> one of the few differences i see is that the system call signatures are similar but not same...e.g. amd64 open is openat on arm64
[19:18] <kgunn> and stat on amd64 is newfstatat on arm64
[19:19] <kgunn> likewise access on amd64 is faccessat on arm64
[19:25] <mup> PR snapd#1879 closed: debian: adjust installation to account for deputy systemd on trusty <Created by vosst> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1879>
[19:27] <mup> PR snapd#1927 closed: tests: account for different PWD handling on trusty <Created by vosst> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1927>
[19:28] <tenaciousmv> sergiusens: good idea! thanks
[19:28] <mup> PR snapd#1923 closed: tests: replace realpath with readlink -f for trusty support <Created by vosst> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1923>
[19:38] <mup> PR snapd#1913 closed: daemon,store: move store login user logic to store <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1913>
[19:38] <mup> PR snapd#1946 opened: interfaces: allow xdg-open in unity7, unity7 cleanups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1946>
[19:40] <jdstrand> kgunn: syscall numbers are architecure-dependent
[19:42] <kgunn> jdstrand: yeah, these arent' the numbers, these are the names of the calls listed in the strace
[19:42] <kgunn> jdstrand: but i'm kinda lost on what to do next
[19:43] <jdstrand> glibc might implement things differently depending on the arch too
[19:45] <kgunn> jdstrand: so do i simply need to add "openat" in my list of mirPermanentSlotSecComp
[19:45] <kgunn> ?
[19:45] <kgunn> in order to cover both archs?
[19:45] <jdstrand> kgunn: I suggest comparing /etc/passwd, /etc/group, /var/lib/extrausers, and compare the file and directory ownerships from / to SNAP_DATA, etc, etc
[19:46] <jdstrand> kgunn: do you have a seccomp denial? you shouldn't. openat is allowed
[19:46] <jdstrand> kgunn: ie, the policy should already cover both archs for common stuff like that
[19:47] <kgunn> jdstrand: lemme look again, i have to drag out all my dragonbaord and cables :)
[19:47] <jdstrand> kgunn: the 3 you mentioned are already allowed
[19:48] <kgunn> ah k
[19:49] <kgunn> i'll double check the exact denial again...i forgot to note it down
[19:49] <dduffey> if I have xenial snappy installed, how do i search --edge
[19:49] <dduffey> 'snap find --edge"
[19:53] <zyga> re
[19:53] <jdstrand> kgunn: you are still talking about dac_override, no? or did you get new denials?
[19:53]  * zyga gets back to work
[19:53] <jdstrand> morphis: fyi, I approved udisks2, but I think you need to press the publish button
[20:41] <mhall119> sergiusens: this is my snapcraft.yaml: http://paste.ubuntu.com/23204318/
[20:42] <mhall119> but snapcraft snap turns the exec line into:
[20:42] <mhall119> exec "env" ERL_FLAGS="-couch_ini ${SNAP_DATA}/default.ini ${SNAP_DATA}/local.ini" ${SNAP}/bin/couchdb "$@"
[20:42] <mhall119> wait, that's my modified one
[20:42] <mhall119> exec "env" ERL_FLAGS=-couch_ini ${SNAP_DATA}/default.ini ${SNAP_DATA}/local.ini ${SNAP}/bin/couchdb "$@"
[20:42] <mhall119> ^^ that's what it does
[20:42] <mhall119> so  ERL_FLAGS=-couch_ini and then it tries to execute  ${SNAP_DATA}/default.ini
[20:46] <mhall119> I think i found a way around it
[20:51] <kgunn> jdstrand: ok, interesting, i just rebuilt snapd with only the inclusion of the new
[20:52] <kgunn>  /run/udev/data/c13:[0-9]* r,
[20:52] <kgunn>  /run/udev/data/+input:input[0-9]* r,
[20:52] <kgunn> ...and that seemed to cure the dac_override need
[20:52] <kgunn> jdstrand: only other thing i can think, is i got my dragon into a weird state that a reboot cured?
[20:53] <kgunn> at any rate... jdstrand you were ok with me adding those to the mir interface right ^?
[20:53] <jdstrand> kgunn: yes
[20:54] <jdstrand> kgunn: glad that doc_override went away
[20:54] <kgunn> will clean up and submit a pr
[21:09] <kgunn> ug... jdstrand getting denial now...this is odd... i'll ping back if i get some consistency....
[21:13] <mwhudson> snappy sure makes reading the output of mount to e.g. find your sdcard harder :-)
[21:14] <mwhudson> (lxd and schroot, too)
[21:17] <mup> PR snapd#1946 closed: interfaces: allow xdg-open in unity7, unity7 cleanups <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1946>
[21:19] <mup> PR snapcraft#813 opened: [WIP] "snapcraft validate" and "snapcraft gated" commands <Created by ralsina> <https://github.com/snapcore/snapcraft/pull/813>
[21:21] <kgunn> jdstrand: dang i just got it figured out! ... so i got tired of the screen blanking on dragon, so i added a setterm to my bash
[21:21] <kgunn> that was screwing with it, so all good now...
[21:21]  * kgunn makes note of setterm being a not good idea with mir testing
[21:22] <kgunn> i had kinda forgotten i even added that....
[21:24] <jdstrand> huh
[21:24] <jdstrand> nice find!
[21:36] <mhall119> is there any way to pre-populate $SNAP_DATA without resorting to a wrapper script?
[21:40] <mhall119> twice now I've had snaps that don't need a wrapper except for doing the initial $SNAP_DATA setup
[21:44] <mup> PR snapd#1858 closed: interfaces: add stub selinux backend <Reviewed> <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1858>
[22:03] <mup> PR snapd#1947 opened: interfaces/builtin: add initial docker interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1947>
[22:05] <mup> PR snapd#1619 closed: interfaces/builtin: add initial docker interface <Blocked> <Created by tianon> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/1619>
[23:32] <tianon> jdstrand: would it be helpful to just put you directly on the collaborators list for https://github.com/docker-snap/docker ? :)


[01:39]  * Hobbsee wonders if eagles has tried coming back again.
[01:39]  * Pici has not seen him since he was last here with you
[01:40] <Hobbsee> oh, excellent :)
[01:42] <Hobbsee> Oh.  And what I actually came in for was to mention that it looks like we need more ops for -meeting, and perhaps -motu too.  I'll deal with the -motu ones, as i've got access there, but it would be great if someone with power would find and appoint some more -meeting ops.
[01:42] <Hobbsee> (preferably before release)
[01:48] <StevenK> Hi. I just got privmsg'd by emma, and I thought I should report it
[01:49] <Pici> StevenK: What did she message you about?
[01:49] <StevenK> #ubuntu-uncensored, and my suspected lurking there
[01:49] <elky_work> StevenK: that channel is back?
[01:50] <StevenK> No, but it seems she is plotting another like it
[01:50]  * nalioth blinks
[01:50] <nalioth> StevenK: i suspect you're behind the times.  such a channel exists at this time.
[01:51] <StevenK> Ahh
[01:51] <elky_work> StevenK: please post an email to<EMAIL_ADDRESS>with more details about this
[01:51] <StevenK> I'm not concerned about the channel, I'm concerned about her privmsg'ing me randomly
[01:52] <StevenK> elky_work: Awww, but that involves reaching for my mail client
[01:52] <StevenK> And IRC is closer
[01:52] <elky_work> indeed, as are we. it seems she's not changed at all, and we'd like as much information about your encounter as is possible for you to give us
[01:52] <nalioth> include your logs, please
[01:52] <StevenK> I'd rather not post them publically
[01:52] <elky_work> the list isnt public
[01:52] <elky_work> that's why i suggested that list
[01:52] <StevenK> Ah
[01:52] <nalioth> StevenK: the irc-council@ is not a public list
[01:53]  * StevenK grumbles at elky_work and write a mail
[01:53] <elky_work> StevenK: grumbling only works f2f, which involves you actually showing up at SLUG sometime this millenia ;)
[01:54]  * StevenK hand waves
[02:48] <elky_work> hrm, this daal is a warmer mild than i anticipated
[03:04] <elky_work> StevenK: the email has been received, thank you :)
[03:04] <StevenK> elky_work: No trouble :-)
[03:04] <elky_work> well, not for you or i
[04:17] <Pici> hmm
[04:17] <Pici> Anyone seen the latest post to the ubuntu-devel list? Also the recent edits to https://help.ubuntu.com/community/FixDCCExploit ?
[04:19] <Pici> I'm heading off to sleep, will reply to email in the morning if no one else has.
[04:28] <mneptok> WHAM! BAM! THANK YOU VAN DAMME!
[07:04] <ompaul> just marked <sipowitz> with a mute unmute - they left the channel on a swear word before anyone answered their question
[07:06] <Mez> hmm, any PHP coders in here interested in joining up on a new project
[07:27] <ompaul> Mez, better to say "see this: url with in php stuffz" ;-)
[07:27] <ompaul> morning Mez anywayz
[07:27] <Mez> ompaul, is hush hush atm
[07:28] <ompaul> Mez, then the advert is fail
[07:28] <ompaul> :-/
[08:10] <jussi01> Morning all
[08:34] <Myrtti> morning
[08:34] <Gary> a PINK phpbb theme!
[08:37] <Myrtti> see?
[08:46] <Gary> Myrtti: I saw your pink theme - it was very pink
[08:46] <Myrtti> it is :-)
[08:47]  * jussi01 hugs Gary...knew youd be around for anything pink! :D
[09:09] <Myrtti> !puregnome
[09:09] <Myrtti> !purexfce
[09:10] <Myrtti> hm
[09:10] <Myrtti> right
[09:10] <jussi01> !purekde
[09:10] <jussi01> just had to finish it off...
[09:10] <Myrtti> oh, now I know
[09:10] <jussi01> :P
[09:14]  * wgrant points jussi01 to Slackware.
[09:14] <jussi01> wgrant: ???
[09:14] <wgrant> Slackware is the distro that lacks GNOME.
[09:14] <jussi01> right...
[09:16]  * jussi01 hugs kde4 and kicks wgrant out... :P
[09:17] <wgrant> * Ubuntu hugs KDE4 and kicks KDE3 out.
[09:17] <wgrant> That has made a lot of people unhappy.
[09:18] <wgrant> Kicking me out in favour of KDE4 would, however, displease fewer people.
[09:18] <wgrant> Sounds better.
[09:26] <jussi01> hehe
[09:26] <jussi01> Ill do both.. :D kde4 rocks :D
[09:34] <Myrtti> are we all having a nice and a wonderful day?
[09:34] <Myrtti> if not, huggles are imminent
[09:35] <Hobbsee> i'll have a huggle.  I have a big test tomorrow :(
[09:35] <Hobbsee> but i did finish an assignment today!
[09:42] <ikonia> jussi01: your dinner last night looked nice, except for the sweet corn
[09:42] <jussi01>  ikonia dont like sweetcrn?
[09:42]  * jussi01 loves sweetcorn
[09:43] <jussi01> hahahahahaha, thats so funny... just got the last bill from the electricity company... -96¤ :D
[09:44] <Myrtti> jussi01: shut up.
[09:44] <Myrtti> jussi01: I've not seen an electricity bill since March.
[09:45] <jussi01> Myrtti: the new house has electricity included :D
[09:45] <ikonia> jussi01 sweetcorn is vile
[09:46] <jussi01> hehe
[09:47] <jussi01> ikonia: you know that red sauce was great, it had mushrooms, chili, red onion, and some other stuff i cant remember...
[09:47] <ikonia> jussi01 it looked nice !
[09:48]  * jussi01 likes to cook :)
[09:51] <ikonia> looksl ike you can coo
[09:51] <ikonia> cookl
[09:52] <jussi01> :)
[10:00] <jussi01> yay!! fennec got released :D http://www.linuxdevices.com/news/NS2883566630.html?kc=rss
[10:00] <jussi01> well kinda, at least
[10:06] <ikonia> jussi01 what would you run that on /
[10:06] <jussi01> ikonia: my n800
[10:07] <ikonia> nokia tablet thing
[10:07] <Myrtti> yup
[10:07] <jussi01> :)
[10:08] <jussi01> ooh, feature upgrade. :D
[10:22] <elkbuntu> oh awesome. that would probably be great on an eee 701
[10:22] <jussi01> yep :)
[10:23] <elkbuntu> package plzkthxbai
[10:23] <elkbuntu> although, i 'real' firefox can be optimised for space quite nicely too
[10:23] <elkbuntu> s/i //
[10:24] <jussi01> oh bleh, it doesnt install for some reason
[10:52] <Myrtti> oh dear
[10:53] <Myrtti> having just said that I've not seen electricity bill since March... a letter from the power company
[10:53]  * Myrtti prays a bit and opens the envelope
[10:53]  * Hobbsee sends Myrtti a Fake Water Bill.
[10:53] <StevenK> Maybe they're sending around Bob the Dinosaur
[10:54]  * Hobbsee has it delivered by a french motorcade.
[10:54] <Myrtti> oh.   Send it through IRC.  Signed, your eater company"
[10:54] <Flannel> er, water company.
[10:55] <Hobbsee> sorry, canadian motorcade, not french.
[10:55] <Hobbsee> Flannel: hehe
[13:19] <ikonia> jrib: I chose to not help him as I'm trying to not pander to people and deal with people who ask nicly first
[13:19] <ikonia> I'd get to him once the others are sorted
[13:20] <ikonia> I noticed that people who behave badly and just are a pain get ansered quicker to make them shutup/go away, I'm trying to not do that
[13:20] <ikonia> (although this guy wasn't bad)
[13:47] <Myrtti> *sigh*
[14:09]  * Pici hugs Myrtti
[14:14] <ikonia> what's anyones take on this mount output ?
[14:14] <ikonia> http://paste.ubuntu.com/55634/
[14:14] <ikonia> never mind
[14:14] <ikonia> he's using wubi
[14:14] <Myrtti> wubi
[14:14] <Myrtti> yeah
[14:15] <Myrtti> /host/ubuntu is a telltale sign
[14:15] <ikonia> all the effort and he never once mentioned it
[14:15] <ikonia> why why why wubi is used 'll never know, it's a solution to a non-existant problem that just causes pain
[14:16] <Myrtti> ikonia: it has its uses
[14:16] <Myrtti> it's not as bad as you think, really
[14:16] <ikonia> Myrtti sell me a use
[14:17] <Myrtti> it's a fullfledged real demo and a gentle introduction to ubuntu
[14:17] <ikonia> Myrtti as opposed to a livecd ?
[14:18] <Pici> For people who are afraid to partition their drives.
[14:18] <Myrtti> yes
[14:18] <ikonia> I don't agree
[14:18] <Myrtti> Pici: I don't agree with you there
[14:18] <Myrtti> livecd is sluggish, and is more dependant on RAM
[14:18] <Myrtti> virtualization can't offer compiz and 3D effects.
[14:19] <Myrtti> its not a way to permanently install ubuntu
[14:19] <Myrtti> it's a way to demonstrate it and to get used to it, but not to be used permanently.
[14:19] <Pici> I'd say its somewhere between a full install and the livecd.
[14:19] <ikonia> I'll re-phrase then, the benfitis don't out weigh the hassle
[14:19] <Myrtti> Pici: indeed
[14:19] <Myrtti> ikonia: in that I can agree
[14:20] <Myrtti> again, as my personal opinion
[14:20] <Myrtti> then again, I installed wubi to my nieces computer
[14:20] <Myrtti> and it has it's benefits
[14:20] <Myrtti> I wouldn't even dream of doing a full install
[15:07] <Myrtti> I want to tickle a customer with a sharp knife near the ribs or jugular
[15:09] <Pici> youch
[15:10] <Gary> just a gentle tickle then
[15:14] <Myrtti> !prayer | oh please dear GOD, hear me scream
[15:27] <Pici> Anyone think that we need a !getdeb?
[15:28] <Pici> I mean to explain why using it is not really supported.
[15:29] <ikonia> be helpful
[15:32] <gnomefreak> same reason debian archives and other non offical archives?
[15:33] <Pici> Yep
[15:33] <gnomefreak> maybe make one that fits all and alias getdeb to it?
[15:34]  * gnomefreak not really here i was just cleanign out my channels from status bar
[15:46] <RichiH> h06 has been spamming #freenode with his :DDDDDDDDDDD already
[15:47] <RichiH> i know i am on the access list, but i don't want to boot him without poking in here
[15:47] <ikonia> on him
[15:48] <ikonia> he's been quiet so far, 2 lines of spam, got my eye on him
[15:58] <Myrtti> there, gone
[16:17] <Pici> ikonia: you keep de-opping yourself.
[16:17] <ikonia> Pici: its not me
[16:18] <Pici> ikonia: chanserv keeps de-opping you.
[16:18] <ikonia> auto_bleh seems to try to deop me, then it either works or does it 3 times
[16:18] <ikonia> this weekend is fix my client weekend
[16:20]  * Myrtti hands ikonia a copy of irssi
[16:20] <Myrtti> clean, nice, pristine irssi
[16:20] <ikonia> I think thats what's needed
[16:21] <ikonia> a general clean up
[16:21] <ikonia> I think a script auto_whois on pm caused issues with auto_bleh and I have to restart irssi to get it back to know sane state
[16:21] <ikonia> I'll stop using it
[16:36] <Pici> ikonia: I had a problem with the auto realname script that gave me similar issues.
[16:37] <ikonia> I'll spend some time at the weekend and house keep / tidy up
[17:21] <Myrtti> *yawn*
[18:12] <Myrtti> LOL
[18:12] <Myrtti> *snork*
[18:13] <Myrtti> hello arquebus, how may we help you?
[18:13] <arquebus> hello? Im wondering if anyone knows if ubuntu-es has a bot for sending out factoids
[18:17] <nalioth> arquebus: have you tried !asking in #ubuntu-es ?
[18:19] <arquebus> nalioth: yes, once or twice, there doesnt seem to be an op around in there, I thought there would be a centralized place for bots in ubuntu for all languages
[18:20] <Myrtti> well first of all, for general issues about loco channels, there's #ubuntu-irc
[18:20] <nalioth> arquebus: no, have you tried to !trigger !the !bot in #ubuntu-es ?
[18:21] <arquebus> nalioth: I'll try that now, that sounds interesting
[18:21] <arquebus> Myrtti: I'll check there
[18:23] <arquebus> well !trigger !the !bot didnt seem to work, that would have been cool if it did
[18:50]  * Pici sighs
[19:26] <Myrtti> Pici: and whats wrong with sudo shutdown -h +60 ;-)
[19:26] <Pici> Myrtti: I was overthinking it.
[19:26] <Myrtti> yes, you were
[19:26] <Myrtti> but worry not
[19:27] <Myrtti> I used at myself for weeks before I realized what "sudo shutdown -h now" really means
[19:28] <Myrtti> I need a babysitter for my guinea pigs
[19:41] <Myrtti> MOAR PILLOWS!
[20:35] <Myrtti> oh dear god my head explodes
[20:38]  * Tm_T huggles Myrtti
[23:21] <ikonia> eyeball on CaptainMorgan: I'm going to bed in a minute
[23:21] <ikonia> he's got a real attitude on him
[23:25] <ompaul> night ikonia
[23:25] <ikonia> night (in a minute) just waiting for washing machine to beep
[23:25] <ompaul> hehe


[00:09] <Fudge> anyone had luck booting a daily image
[10:09] <lotus|xenial> i need to test 4.3 kernel on my xenial box
[10:09] <lotus|xenial> but got an error on adding kernel
[10:11] <lotus|xenial> it says dpkg: error on archive --install
[10:11] <lotus|xenial> after trying sudo dpkg -i linux-headers-4.3.0-040300-generic_4.3.0-040300.201511020846_amd64.deb
[10:39] <lordievader> Good morning.
[10:39] <lotus|xenial> hey lordievader
[10:40] <lordievader> Hey lotus|xenial, how are you doing?
[10:40] <lotus|xenial> fine tnx
[10:41] <lordievader> :)
[12:41] <BluesKaj> 'Morning folks
[15:53]  * penguin42 returns from Xenial
[16:24] <penguin42> can someone try dmesg |grep ifup  - I see two segfaults
[16:33] <clivejo> penguin42: running Kubuntu 16.04(xenial) and tried "dmesg |grep ifup" nothing here
[16:33] <penguin42> hmm
[16:34] <penguin42> clivejo: I think it's bug 13196209 that I'm hitting
[16:34] <penguin42> oops
[16:34] <penguin42> I mean bug 1416793