[01:22] <mup> Bug #1665184 opened: Assertion list returned by GET /v2/assertions/type can't be reliably split <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1665184>
[01:57] <kyrofa> barry, the fact that ubuntu-image uses the beta channel by default surprises me and is unclear from the manpages. Shouldn't it be stable?
[03:33] <barry> kyrofa: it can't be because it requires devmode.  i think we definitely want to try to convert it to a classic snap at some point, but for now we treat beta as our release channel (and edge as our "proposed")
[05:50] <sgorshkov> Hi
[06:50] <mup> PR snapd#2868 closed: Don't return null result for async responses <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2868>
[06:57] <kalikiana> barry: even though you can have a snap that uses devmode without declaring it in snapcraft.yaml ;-)
[06:58] <kalikiana> I don't know that it's the right thing to do, but some snaps do it, and it's not being blocked
[07:03] <kalyan_> how to mount a ubuntu-core-16-dragonboard-410c.img
[07:04] <kalyan_> and write a file in to the mount partition
[07:27] <mup> PR snapd#2869 opened: Add Online Accounts interface <Created by mardy> <https://github.com/snapcore/snapd/pull/2869>
[09:16] <ernstp> what's the difference between meta/snap.yaml and snapcraft.yaml?
[09:17] <ogra_> one is used to build a snap, the other is meta information inside a snap package
[09:18] <ogra_> snap.yaml is all the "non-build" meta info from the snapcraft.yaml usually
[09:19] <ernstp> sometimes you create a snap.yaml manually though?
[09:20] <ogra_> not really ... you *can* do that but it means the build takes two steps and you cant use the auto-builder on launchpad
[09:22] <ernstp> looking at https://github.com/kubiko/roseapple-pi-ubuntuCore-build/tree/master/builder and https://docs.ubuntu.com/core/en/guides/build-device/board-enablement
[09:22] <ogra_> (like you can create a deb from scratch by putting the right files in the right places and using ar and gzip to finally create the package, you can do the same with a snap, but nobody would seriously do that)
[09:23] <ogra_> ernstp, thats rather outdated
[09:23] <ernstp> wow, rly?
[09:23] <ogra_> from a time where snapcraft did not understand "type: gadget"
[09:24] <ernstp> this page looks nice and official: https://docs.ubuntu.com/core/en/guides/build-device/board-enablement
[09:24] <ernstp> but it's already outdated?
[09:24] <ogra_> yet it is outdated :)
[09:24] <ogra_> https://github.com/snapcore/pi3-gadget
[09:24] <ogra_> have a look there
[09:24] <ogra_> ondra, ^^^ perhaps you shoudl update that ;)
[09:25] <ernstp> I started at these wonderful pages that haven't been updated since 2011 :-) https://wiki.ubuntu.com/ARM/RootStock https://wiki.ubuntu.com/ARM/RootfsFromScratch
[09:25] <ogra_> hah
[09:25] <ogra_> yeah, thats all obsolete but some of it might still work
[09:26] <ernstp> yeah I mean debootstrap will always work I guess
[09:26] <ogra_> its not like the underlying technology changes much there
[09:26] <ernstp> and there's multistrap
[09:27] <ogra_> rootstock went out of maintenance some time ago though ... but its just a script, easy to asdjust if needed
[09:28] <ernstp> ogra_: but thanks for pointing to the pi3 thing, I'll dig through it...
[09:28] <ogra_> if you have questions, just ask :)
[09:30] <ernstp> ogra_: is this up to date... ? https://github.com/snapcore/snapd/wiki/Gadget-snap
[09:30] <ernstp> it mentions meta/snap.yaml again..
[09:31] <ogra_> no, that needs updating too it seems
[09:34] <ernstp> I like https://github.com/kubiko/roseapple-pi-ubuntuCore-build/tree/master/builder because it includes building  u-boot etc
[09:36] <ogra_> ernstp, yeah, you could just call that from the snapcraft.yaml
[09:38] <ernstp> there's no kernel snap in the rpi3 repo?
[09:38] <ogra_> no
[09:38] <ogra_> the kernel is from the official builds in the ubuntu archive
[09:39] <ernstp> right
[09:39] <ogra_> the source for it is on kernel.ubuntu.com
[09:41] <ernstp> I guess I'm comparing this to yocto...
[09:43] <ogra_> you cast really :)
[09:43] <ogra_> *cant
[09:43] <ernstp> where you build a kernel, u-boot, pick up some userland, and then bake it all into an image
[09:44] <ogra_> all the bits are separately upgradeable and you can also roll back each of them individually
[09:44] <ernstp> of course the point of using Ubuntu Core would be to _not_ compile all of userland from scratch
[09:44] <ogra_> in case of kernel that happens even automatically if a new kernel doesnt finish booting
[09:45] <ogra_> also the resulting image is readonly with only the few bits made writable the system needs to run, you cant really tinker with it
[09:45] <ogra_> (snaps are signed readonly squashfs files)
[09:48] <ernstp> well comparing to yocto I still need to take a bunch of source, compile it and then combine it to an image I can flash to a device
[09:48] <ogra_> well, the kernel and bootloader, yeah
[09:49] <ernstp> yes
[09:49] <ogra_> (if your board is supported by the generic kernel only the bootloader ... )
[09:50] <ernstp> no I've got a custom board
[09:51] <ernstp> the arm world is moving forward but it's going slow...
[09:51] <ogra_> yep
[09:52] <ernstp> how could that setup look then...
[09:52] <ogra_> well, enabling the beaglebone black which has mainline support was a 30min job for me ... simply because i didnt need to care for the kernel
[09:52] <ernstp> gadget/gadget.yaml gadget/snapcraft.yaml kernel/snapcraft.yaml
[09:54] <ogra_> https://github.com/snapcore/snapcraft/tree/master/demos/96boards-kernel/snap
[09:54] <ernstp> I'm using an imx6 processor plus a custom board
[09:55] <ogra_> https://snapcraft.io/docs/reference/plugins/kernel has the docs for that
[09:55] <ernstp> ogra_: right, that's just like https://github.com/kubiko/roseapple-pi-ubuntuCore-build/blob/master/builder/kernel/snapcraft.yaml makes perfect sense to me
[09:55] <ogra_> right
[09:56] <ernstp> that's exactly what I need for the kernel, pointing out config, dtb, some options and whatnot
[09:57] <ernstp> then I want to build a gadget around that
[09:57] <ogra_> right, and then an image
[09:58] <ogra_> (docs for that are at https://docs.ubuntu.com/core/en/guides/build-device/image-building )
[09:59] <ernstp> which leads to the https://docs.ubuntu.com/core/en/guides/build-device/board-enablement page that was outdated you said
[10:01] <ernstp> Can I reference snaps locally?
[10:01] <ernstp> right, I can, gadget and kernel refer to snaps already existing in the store or in the current directory
[10:04] <ogra_> ernstp, yes, with the --extra-snaps option
[10:12] <ogra_> ernstp, note that even if the page is outdated, the resulting snap will work and you can later port to plain snapcraft.yaml if you want
[10:13] <ogra_> so just follow it for now :)
[10:37] <mup> PR snapd#2870 opened: tests: failover test for rc.local crash <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2870>
[11:04] <mup> PR snapd#2871 opened: utils: helper function for creating a deep copy of interface attributes <Created by stolowski> <https://github.com/snapcore/snapd/pull/2871>
[11:17] <hangun> hi
[11:18] <hangun> I registered a new account and the profile is at https://launchpad.net/~ucrobotics123
[11:19] <hangun> but when I executing " snapcraft register-key" commmand and inputing account and password
[11:20] <hangun> I got an error like this:   you need to set a usename. it will appear in the developer filed alongside the other detials or your snap.
[11:43] <ernstp> hangun: I think it's confusingly called "Developer namespace" in the account details online
[11:44] <hangun> hi ernstip
[11:45] <hangun> how I set up the "namespace"
[11:46] <hangun> I dont see where to set up in my account https://launchpad.net/~ucrobotics123
[11:48] <ogra_> hangun, did you set it up on login.ubuntu.com ?
[11:49] <ernstp> hangun: if you read the full error message there's an url
[11:52] <hangun> I set up the "Username" filed at https://login.ubuntu.com/
[11:53] <hangun> any role for that?
[11:53] <hangun> my username is "ucrobotics123"
[11:53] <ogra_> and you can log in with that on https://myapps.developer.ubuntu.com ?
[11:54] <ogra_> there is a ""developer namespace" option in the account settings
[12:03] <hangun> thanks ogra_
[12:03] <hangun> it works now
[12:09] <hangun> I have another question:  after snappy system booting up,  executing commands " snap install hello-world" , "hello-world"
[12:10] <hangun> but got error like this: cannot bind-mount the mount namespace file /proc/11268/ns/mnt -> hello-world.mnd
[12:10] <hangun> support process for mount namespace capture exited abnormally
[12:14] <cachio> niemeyer, hi, I am trygin to push to spread a branch with the change that I did to export xunit format but I am getting
[12:14] <cachio> remote: Permission to snapcore/spread.git denied to sergiocazzolato
[12:14] <niemeyer> cachio: Hi
[12:14] <niemeyer> cachio: Got your email as well
[12:14] <niemeyer> cachio: Typical workflow in github is you fork the project into your own space, push the changes you want, and then send a pull request (PR) to the original project
[12:15] <niemeyer> cachio: You don't need write access to the master branch for that
[12:15] <cachio> niemeyer, I did that
[12:16] <niemeyer> cachio: Not really.. you see the message above?
[12:16] <niemeyer> cachio: You're trying to write into snapcore/spread.git.. that's not your fork
[12:16] <cachio> niemeyer, in that case I' try again
[12:16] <niemeyer> cachio: You're not supposed to be able to push there (yet, at least)
[12:17] <cachio> niemeyer, ok
[12:22] <hangun> hello all
[12:22] <hangun> I have the similar issue like this https://bugs.launchpad.net/snap-confine/+bug/1645457
[12:22] <mup> Bug #1645457: cannot bind-mount the mount namespace file on Kernel 3.10 <Snappy Launcher:New> <https://launchpad.net/bugs/1645457>
[12:35] <zyga> hello, sorry from being absent from IRC
[12:36] <zyga> anyone had a question about namespaces in snaps?
[12:47] <ogra_> zyga, that was hangun
[12:47] <ogra_> more abour namespaces in kernel i suspect though
[12:47] <ogra_> *about
[12:48] <mup> PR snapd#2864 closed: interfaces: API additions for interface hooks <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2864>
[12:48] <zyga> hangun: hey
[12:48] <zyga> hangun: how can I help you, can you please repeat your question?
[12:51] <mup> PR snapd#2524 closed: interfaces/builtin,cmd/snap-confine: add the overmount interface <Created by kalikiana> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2524>
[12:52] <niemeyer> zyga:
 hello all
[12:52] <niemeyer> 10:22:33 I have the similar issue like this https://bugs.launchpad.net/snap-confine/+bug/1645457
[12:52] <mup> Bug #1645457: cannot bind-mount the mount namespace file on Kernel 3.10 <Snappy Launcher:New> <https://launchpad.net/bugs/1645457>
[12:54] <ogra_> heh, and he left
[12:59] <mup> PR snapd#2866 closed: cmd/libsnap: add helper for dropping permissions <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2866>
[13:11] <jdstrand> zyga: hey, why make the libcap stuff conditional? it will work everywhere
[13:12] <zyga> jdstrand: because we cannot add dependencies to snapd easily now
[13:12] <zyga> jdstrand: I want to just enable it on compile time if it is available
[13:13] <zyga> jdstrand: and as we work on resolving the other bug (that affects apt) we can just hard-depend on it
[13:13] <jdstrand> zyga: but the code is correct... why can't you add a dependency?
[13:13] <zyga> jdstrand: right now because of how apt works it means people will not update
[13:13] <zyga> jdstrand: mvo has the gory details
[13:13] <zyga> jdstrand: but that's the bottom line
[13:13] <jdstrand> we add new stuff all the time
[13:13] <jdstrand> look at bind9 updates
[13:14] <jdstrand> this isn't a reason to not do stuff
[13:14] <zyga> jdstrand: and stats show us that people are stuck on ancient snapd
[13:14] <jdstrand> I know that thread
[13:14] <zyga> jdstrand: we researched this, apt behaves this way if you use a particular command
[13:14] <jdstrand> so fix apt
[13:14] <jdstrand> that was the takeaway from the conversation as I understood it
[13:15] <zyga> jdstrand: I'm not aware of that, I need to ask mvo
[13:15] <zyga> jdstrand: I asked him today and he recommended against adding deps to snapd
[13:15] <zyga> jdstrand: in any case, on ubuntu the build will not use libcap and will just do that unconditionally
[13:16] <zyga> jdstrand: on fedora we can use libcap
[13:16] <zyga> jdstrand: I think this is fine
[13:16] <zyga> jdstrand: until we can address the issue in apt
[13:16] <jdstrand> I don't think it is fine because it adds code complexity in the setgroups check
[13:16] <zyga> jdstrand: wh?
[13:17] <zyga> *why?
[13:17] <jdstrand> we are using libcap to see if we can use setgroup
[13:17] <zyga> the only complexity will be an #ifdef in the sc_has_capabaility
[13:17] <jdstrand> no
[13:17] <zyga> without libcap it will just say yes
[13:17] <jdstrand> and that will be wrong
[13:17] <zyga> why?
[13:17] <jdstrand> if you call drop privs as non-root, setgroups will fail
[13:18] <jdstrand> that is the whole reason the check is there
[13:18] <zyga> oh we ca easily check for that
[13:18] <zyga> we have the cap if running as root
[13:18] <jdstrand> yes, but the code is correct. we need to fix the underlying problem, not contort our code
[13:18] <zyga> that's one line in the #else part of the has_capability
[13:19] <jdstrand> the underlying problem is a distro problem that affects more than just snapd. not fixing it and people aren't getting other updates. snapd shows the symptom, but that is only because it is the only thing we are looking at
[13:21] <jdstrand> also, the xfslibs change also introduced a dependency. are we going to yank that out? cause that will affect security policy
[13:21] <jdstrand> kernels, bind9, and other things all do this regularly in the distro
[13:21] <zyga> jdstrand: I noticed that too
[13:21] <zyga> jdstrand: one secodn
[13:21] <zyga> jdstrand: (mvo says it is hard socially)
[13:22] <zyga> jdstrand: for that I think we just need the macro definitions
[13:22] <zyga> jdstrand: not any real dependency at runtime, right?
[13:24] <zyga> jdstrand: or we can link libacap statically
[13:24] <zyga> jdstrand: that's easy too
[13:24] <zyga> jdstrand: would you +1 that?
[13:25] <Son_Goku> :/
[13:26] <jdstrand> for quota patch, it shouldn't pull in a runtime dep, only the build afaics (according to ldd)
[13:27] <zyga> jdstrand: I think we pulled in libhandle, not sure why
[13:27] <zyga> I saw it in ldd
[13:27] <zyga> Son_Goku: hey
[13:27] <jdstrand> oh, I don't have the right branch, hold on
[13:27] <Son_Goku> zyga: hi
[13:27] <zyga> jdstrand: I mean libhandle from xfs is in master
[13:29] <jdstrand> no, I have the right branch
[13:29] <jdstrand> ldd ./snap-confine/snap-confine
[13:29] <jdstrand> I see no libhandle
[13:30] <jdstrand> that is with quota patches but not up to date master
[13:31] <jdstrand> and with up to date master, no libhandle
[13:32] <jdstrand> mvo: hey, can you comment on the no new deps thing? ^
[13:32] <zyga> jdstrand: I agree, I wonder why I saw it on centos, I'll check later
[13:34] <zyga> Son_Goku: question, so the centos package
[13:35] <zyga> Son_Goku: can we build a small centos package separately from the fedora package?
[13:35] <zyga> Son_Goku: just something that could live in copr for now
[13:35] <zyga> Son_Goku: I was looking at rhel and man, no build deps for anything
[13:35] <Son_Goku> haha
[13:35] <mvo> jdstrand: in a meeting right now
[13:35] <zyga> Son_Goku: so I think the package should build on centos first
[13:35] <Son_Goku> well, if it can build in EPEL, that's enough
[13:35] <zyga> Son_Goku: and then can move over as a binary package
[13:35] <zyga> Son_Goku: exactly
[13:35] <Son_Goku> no, I mean, that's enough for everyone (CentOS, RHEL, etc.)
[13:36] <zyga> Son_Goku: did you see my blog post about centos?
[13:36] <zyga> Son_Goku: ah, I see
[13:36] <Son_Goku> EPEL is RHEL + EPEL packages
[13:36] <mvo> jdstrand: what dependency was that again?
[13:36] <Son_Goku> and because CentOS is binary compatible, it works there
[13:36] <zyga> mvo: libcap2
[13:36] <zyga> mvo: (and libcap-dev as build-dep)
[13:36] <jdstrand> mvo: this time, libcap
[13:36] <jdstrand> libcap2, yes
[13:36] <mvo> jdstrand: isn't that part of a the default install anyway?
[13:37] <mvo> if so, we are fine
[13:37] <zyga> hmmm, good question
[13:37] <jdstrand> let me double check
[13:37] <zyga> it is in main
[13:37] <ogra_> we definitiely ship it in core
[13:37] <jdstrand> I checked the apt-cache rdepends, but didn't finish looking at it before I got fired up :)
[13:37] <mvo> it is installed in my pbuilder chroot
[13:37] <jdstrand> ogra_: we have libcap-ng in core
[13:37] <zyga> I think it's in bydefault
[13:38] <zyga> jdstrand: in that case let's re-open and land as-is
[13:38] <mup> PR snapd#2866 opened: cmd/libsnap: add helper for dropping permissions <Created by zyga> <https://github.com/snapcore/snapd/pull/2866>
[13:38] <jdstrand> avahi-daemon needs it, so it is in the desktop
[13:38] <zyga> jdstrand: can you review it now
[13:39] <jdstrand> iputils-ping needs it, and that is in minimal
[13:39] <ogra_> jdstrand, i see libcap2 here and libcap2-bin
[13:39] <jdstrand> (on trusty)
[13:39] <hangun> hi zyga
[13:39] <jdstrand> same for xenial
[13:39] <hangun> just left for a while
[13:39] <ogra_> on trusty we still use the same core
[13:40] <ogra_> https://launchpadlibrarian.net/306642126/core_16.04.1_amd64.manifest is the manifest file for the core snap
[13:40] <jdstrand> and yakkety and zesty
[13:40] <jdstrand> well, the core snap isn't an issue cause it'll just be slurped in, but I did check there. let me check again
[13:41] <Son_Goku> zyga: EPEL in Koji uses RHEL 7 base, EPEL in COPR uses CentOS 7 base
[13:41] <ogra_> http://people.canonical.com/~ogra/core-builds/ has links to all the manifests
[13:41] <jdstrand> ogra_: you are right. libcap2 is in /lib but libcap-ng is in /usr/lib. I only checked /usr/lib
[13:41] <jdstrand> it's in minimal, so crisis averted for this
[13:42] <Son_Goku> jdstrand: bah, UsrMerge :)
[13:42] <Son_Goku> do iiiit :D
[13:42] <jdstrand> however, I thought a fix for apt-get was the way to go to make it work the same as apt
[13:42] <zyga> Son_Goku: I suspect 18 will do it
[13:42] <Son_Goku> FINALLY
[13:43] <zyga> Son_Goku: nobody cares though :)
[13:43] <Son_Goku> :'(
[13:43] <zyga> it's a change that changes nothing relevant for anyone
[13:43] <zyga> internal refactor
[13:43] <Son_Goku> y'all suck :)
[13:43] <zyga> hangun: hi
[13:43] <zyga> hangun: I want to help you with the issue you mentioned
[13:43] <zyga> hangun: I merged a small fix into snapd master that affects 3.10
[13:43] <jdstrand> zyga: all this said. it is actually interesting to think about (not for this PR) to make snap-confine statically linked, or at least, partially so
[13:44] <zyga> jdstrand: yes, I agree, though we will use core libs for re-exec linking it statically is not a bad idea
[13:44] <zyga> hangun: can you try master and tell me exactly what error are you getting
[13:44] <jdstrand> zyga: well, re-exec is only for classic
[13:45] <zyga> jdstrand: yes
[13:45] <zyga> jdstrand: do you see advantages to static linking on core?
[13:47] <jdstrand> but it does help the re-exec case. it also would allow us to reduce the apparmor profile. potentially avoids problems where the libs it would dynamically link out to change incompatibly such that snap-confine fails. that *should* never happen and tests would reveal that type of thing
[13:47] <jdstrand> it does mean that we need to rebuild for security updates
[13:47] <jdstrand> it is something to think about. I'm not recommending it atm, just thinking out loud
[13:48] <zyga> jdstrand: I think we should add that to the list of things to investigate once core splits into core + base
[13:48] <zyga> jdstrand: could be used to keep core totally tiny
[13:48] <jdstrand> well, it would actually be a little bigger
[13:48] <mup> PR snapd#2872 opened: tests: only check core refresh if there's no update available <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2872>
[13:49] <jdstrand> since it doesn't use many libraries and most of those are fundamental-- I doubt any would drop of, so there would be duplication. but I'm not saying this is a concern, just that it wouldn't be smaller
[13:49] <zyga> jdstrand: only if something else also depends on libcap in core
[13:49] <hangun> zyga:  My env like this snapd version (2.21), snapcraft version (2.26) ubuntu-snappy version (2.21).
[13:49] <jdstrand> libcap is the only thing
[13:49] <jdstrand> that it would save
[13:49] <zyga> hangun: you need to build snapd from master
[13:49] <jdstrand> if it is totally staically compiled, then libc is there and in core
[13:50] <zyga> hangun: there's a lot of improvements that landed since 2.21
[13:50] <zyga> hangun: and the fix to 3.10 that I did is not released yet
[13:50] <zyga> hangun: I don't know it fixes the issue you are seeing but I did use it run on a 3.10 kernel
[13:50] <zyga> hangun: (though without apparmor)
[13:50] <zyga> hangun: but you need that fix to get it to work anyway
[13:51] <morphis> lool: lool: https://github.com/morphis/tvheadend/tree/snap-support
[13:51] <jdstrand> of course, you could just statically link libcap
[13:51] <jdstrand> anyway, something to think about
[13:51] <mup> PR snapd#2835 closed: strutil: support version compare with empty strings <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2835>
[13:52] <hangun> zyga:  thanks, i try it now.
[13:54] <zyga> Son_Goku: what are those notificationabout snap-confine for f23 being deleted?
[13:54] <zyga> Son_Goku: is that because of EOL?
[13:54] <Son_Goku> no
[13:54] <Son_Goku> I think it's because you never submitted them as updates
[13:55] <zyga> so what is exactly being deleted?
[13:55] <Son_Goku> if they're not tagged, koji aggressively gc's them
[13:55] <Son_Goku> the build artifacts
[13:55] <zyga> ah
[13:55] <zyga> that's fine
[13:55] <zyga> Son_Goku: we should try to get those packages out
[13:55] <zyga> Son_Goku: 2.23 has all the fixes for fedora now
[13:55] <Son_Goku> is it released?
[13:56] <Son_Goku> I didn't see mvo announce 2.23 yet
[13:56] <Son_Goku> did we also get any new systemd units that I need to refresh my systemd unit patch for?
[13:58] <zyga> Son_Goku: mvo will release it today I think
[13:58] <zyga> mvo: when is the release? today?
[13:58] <zyga> Son_Goku: no, we can drop units now
[13:58] <zyga> Son_Goku: more less
[13:58] <Son_Goku> well, our systemd units work slightly differently from ubuntu's remember
[13:58] <zyga> Son_Goku: we have a packaging/ directory
[13:58] <zyga> Son_Goku: yes, I mean we should put them there
[13:58] <zyga> Son_Goku: if you commit them we don't need to carry the patch
[13:58] <Son_Goku> well, I can certainly submit a PR with them, if you'd like
[13:58] <zyga> Son_Goku: please, I really want those
[13:59] <zyga> Son_Goku: you didn't answer my question about the centos blog post
[13:59] <Son_Goku> I didn't read it yet
[13:59] <zyga> Son_Goku: did you see the stuff I added there?
[13:59] <zyga> Son_Goku: ah, OK
[13:59] <Son_Goku> reading it now
[14:00] <Son_Goku> looks like zbyszek left comments on your blog?
[14:00] <zyga> Son_Goku: yes
[14:00] <zyga> Son_Goku: nice to see feedback from systemd developers :)
[14:00] <Son_Goku> talking to them often helps, too :)
[14:01] <Son_Goku> Lukas and Zbyszek are nice people
[14:01] <zyga> I'm sure, I'd love to meet them in person one day
[14:01] <Son_Goku> Lukas is the RHEL systemd maintainer, and Zbyszek is the Fedora one
[14:01] <zyga> I could use more sleep ;)
[14:01] <Son_Goku> or more coffee :)
[14:01] <zyga> I think I need to survive too ;)
[14:02] <hangun> zyga:  is this the snapd link https://github.com/snapcore/snapd/ ?   How I compile it or any easy way to get a latest nightly deb package?
[14:02] <zyga> hangun: yes that is it
[14:02] <lool> morphis: awesome!
[14:03] <zyga> hangun: not sure where are the nighly packages, I think they are built somewhere but I cannot say
[14:03] <zyga> hangun: I wrote a blog post about how to build it from source on centos lately, the instructions are almost enitirely valid for other distributions (you just need the right build dependencies)
[14:04] <zyga> hangun: https://new.zygoon.pl/post/case-study-snapd-on-centos/
[14:04] <hangun> zyga:  awesome
[14:04] <zyga> hangun: feel free to ping me with question
[14:05] <zyga> hangun: you can try to build just the snap-confine parts
[14:05] <zyga> hangun: and you can make install DESTDIR=/tmp/foo if you just need a particular file to test
[14:05] <zyga> hangun: I'm not sure what the process is on your device
[14:06] <hangun> zyga:  my board is bubblegum 96board http://www.96boards.org/product/bubblegum-96/
[14:09] <zyga> hangun: I see
[14:09] <zyga> I don't have that board at home
[14:10] <ogra_> hopefully all needed config options are set in that kernel
[14:10] <hangun> zyga:  i will re-build snapd following your blog
[14:12] <mup> PR snapd#2841 closed: interfaces: allow recv* and send* by default, accept4 with accept and other cleanups <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2841>
[14:14] <mup> PR snapd#2842 closed: interfaces: misc updates for network-control, firewall-control, unity7 and default policy <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2842>
[14:15] <Son_Goku> zyga, what should I label the folder inside of packaging/ ?
[14:15] <Son_Goku> I originally was using the catch-all top level directory dist/, but I guess that doesn't fit here
[14:18] <zyga> Son_Goku: just put packaging/fedora-25 there
[14:18] <zyga> Son_Goku: we can use symlinks for others
[14:18] <zyga> Son_Goku: and then we can use that in downstream packages
[14:19] <zyga> Son_Goku: we can also keep a copy of the spec for CI
[14:19] <Son_Goku> even if the units are useful for more than fedora? they're basically the ones anyone that isn't using Debian uses
[14:19] <zyga> Son_Goku: yes
[14:19] <zyga> Son_Goku: symlinks :)
[14:19] <zyga> Son_Goku: we can sim;lify over time
[14:19] <Son_Goku> okay
[14:20] <Son_Goku> as for spec for CI, that would mean that snapcore-selinux needs to somehow be available for spread to pull in
[14:20] <Son_Goku> or is it always going to retrieve that from fedora dist-git?
[14:20] <zyga> Son_Goku: yes, I think we can come up with something
[14:20] <Son_Goku> okay
[14:20] <zyga> Son_Goku: not sure yet
[14:21] <zyga> jdstrand: what about 2863?
[14:21] <zyga> jdstrand: I'd like that in candidate that's going out now
[14:21] <mup> PR snapd#2866 closed: cmd/libsnap: add helper for dropping permissions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2866>
[14:25] <jdstrand> zyI already commented on that yesterday. I didn't think it needed more work from me, but I'll approve it
[14:25] <mup> PR snapd#2873 opened: tests: several improvements to the nested suite <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2873>
[14:27] <zyga> re
[14:28] <jdstrand> zyga: I already commented on that yesterday. I didn't think it needed more work from me, but I'll approve it
[14:28] <zyga> jdstrand: just the approval :)
[14:29] <jdstrand> zyga: note, you merged https://github.com/snapcore/snapd/pull/2866 without a second +1, just mine
[14:29] <mup> PR snapd#2866: cmd/libsnap: add helper for dropping permissions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2866>
[14:29] <zyga> jdstrand: I cannot merge it without it
[14:29] <jdstrand> well, you'll need a second +1 too
[14:29] <jdstrand> unles the commit policy changed
[14:29] <zyga> jdstrand: that counts as one
[14:29]  * jdstrand is just operating under what he's been told
[14:30] <jdstrand> zyga: what counts as one? my +1? yes, and you need two +1s other than yourself as I've been told
[14:33] <hangun> zyga:  I git clone snapd from source and then  ./mkversion.sh
[14:34] <hangun> zyga: *** Setting version to '2.22.2+git475.g7900000.dirty' from git.
[14:34] <Son_Goku> zyga, does snap-confine get the same versioning as snapd now?
[14:35] <Son_Goku> or does it still maintain its own version somewhere?
[14:35] <zyga> Son_Goku: yes
[14:35] <zyga> Son_Goku: it's the same version, easier :)
[14:35] <Son_Goku> okay
[15:05] <Son_Goku> zyga: working on the snapd.spec rebase to v2.23... https://github.com/Conan-Kudo/snapd/commit/f73baebb3d0d9f049568b1134365c2b47368c981
[15:06] <Son_Goku> let me know if there's something I'm missing that should be added
[15:06] <Son_Goku> haven't built it yet, either, as I need to go to work
[15:06] <Son_Goku> I'll test and fix up the inevitably broken file lists...
[15:06] <zyga> Son_Goku: looking
[15:08] <zyga> Son_Goku: BuildRequires: pkgconfig(libcap)
[15:08] <Son_Goku> on snap-confine?
[15:08] <Son_Goku> does that mean we can use file caps?
[15:09] <zyga> Son_Goku: also requires xfsprogs-devel
[15:09] <zyga> Son_Goku: no but we start to use libcap
[15:09] <zyga> Son_Goku: maybe we can switch over time, but the dependency is in place now
[15:09] <zyga> Son_Goku: you also want glibc-static
[15:09] <Son_Goku> uh why glibc-static?
[15:10] <zyga> Son_Goku: though we don't need to ship the resulting file (system-shutdown)
[15:10] <zyga> Son_Goku: there's a special helper that systemd runs on core systems to unmount the filesystem correctly
[15:10] <zyga> Son_Goku: it's only used on core
[15:10] <zyga> Son_Goku: and it runs back in intrd land
[15:10] <zyga> Son_Goku: so it has to be static
[15:10] <zyga> Son_Goku: just add the build-dep for now, we can make that conditional on something like --non-core-build or something later
[15:11] <zyga> Son_Goku: check the list in the blog post, I listed all the packages for centos and that's pretty much the same list for Fedora
[15:11] <zyga> Son_Goku: reading the rest now
[15:12] <zyga> Son_Goku: make sure the configure call matches autogen (not sure if it doenst)
[15:13] <zyga> Son_Goku: we have a new go executable (snapctl) that should be built and installed to %{_bindir}
[15:13] <zyga> Son_Goku: we should include the /var/lib/snapd/void directory that is root.root 0000
[15:13] <zyga> Son_Goku: snap-confine creates it but it should be owned by the package
[15:13] <Son_Goku> it is
[15:13] <zyga> oh, must have missed it
[15:13] <Son_Goku> snapctl goes in snap-confine?
[15:14] <zyga> Son_Goku: no, more like snapd
[15:14] <zyga> Son_Goku: I'd merge them TBH
[15:14] <zyga> Son_Goku: one binary package
[15:14] <zyga> Son_Goku: but digress,
[15:14] <zyga> Son_Goku: we need a new info file
[15:14] <zyga> Son_Goku: it is in libexecdir for now
[15:14] <zyga> Son_Goku: it is in data/info after build AFAIR
[15:14] <zyga> Son_Goku: it's just a version dump
[15:14] <zyga> Son_Goku: oh and we should run ./mkversion.sh
[15:15] <zyga> Son_Goku: right now we skipped that but it is mandatory for snap-confine and everything else now
[15:15] <zyga> Son_Goku: we _probably_ have to fix mkversion
[15:15] <zyga> Son_Goku: or have it just echo the fedora version
[15:15] <zyga> Son_Goku: it looks at git
[15:15] <zyga> Son_Goku: but then falls back to debian/changelog
[15:15] <zyga> Son_Goku: it's a bit hard to say where the reference version should be
[15:15] <zyga> Son_Goku: we can fix that but not sure where to put the version
[15:15] <Son_Goku> if we could just write a file out somewhere, I can inject the version that way
[15:16] <Son_Goku> with like echo "%{version}" > VERSION
[15:16] <zyga> Son_Goku: the script generates a go version file, a static file for snap-confine (configure.ac reads it) and the info file (snapd reads it at runtiime)
[15:16] <zyga> Son_Goku: kind of yes,
[15:16] <zyga> Son_Goku: but if you do that in mkversion.sh as a patch we can upstream it and it will not drift over time
[15:16] <Son_Goku> yeah, alright, I'll take a look at it
[15:16] <zyga> Son_Goku: that script was a quick and dirty way to progress and this is a good chance to just make it nicer
[15:17] <Son_Goku> I gotta go to work
[15:17] <zyga> Son_Goku: thank you, let's sync later
[15:17] <zyga> Son_Goku: you can drop SNAPD_REEXEC, reexec is disabled on fedora and similar now
[15:18] <zyga> Son_Goku: you can keep it just in case you want to for now but it's not useful anymore
[15:18] <Son_Goku> I'm going to leave it as reference
[15:18] <zyga> Son_Goku: oh and we have a few more manual pages Is uspect
[15:18] <zyga> Son_Goku: still not enough but more than before :-)
[15:18] <zyga> I plan to write the missing few when I have a chance to look at this
[15:18] <zyga> (fighting other dragons now)
[15:19] <zyga> Son_Goku: we may have more directories in /var/lib/snapd/ we should cross-check with debian packaging
[15:19] <zyga> (and document them in snapd man page)
[15:20] <zyga> Son_Goku: that's all I could see on a quick read, again *thanks* for picking this up :)
[15:33] <brunch875> does snappy have any system for bug reporting?
[15:33] <brunch875> not snappy itself, but for specific snaps
[15:33] <zyga> brunch875: no not at present
[15:33] <brunch875> zyga, is it planned?
[15:34] <zyga> brunch875: there's work for landing a way to display contact information, it should be ready in the next release
[15:34] <brunch875> nice!
[15:34] <zyga> brunch875: I think that can be extended to include other URLs (e.g. a support URL)
[15:34] <zyga> brunch875: you want to ask mvo about this, he was working on the feature
[15:34] <zyga> brunch875: but I think he's very busy today, working on the release
[15:34] <zyga> brunch875: so perhaps tomorrow
[15:35] <zyga> brunch875: or just send an email to the snapcraft mailing list
[15:35] <mvo> snap info snapname in master will give you contact information
[15:35] <mvo> (in a meeting)
[15:35]  * zyga hugs mvo
[15:35] <zyga> thanks! :)
[15:35] <brunch875> thank you!
[15:36] <stokachu> im seeign this on 14.04 : 2017-02-16T15:34:49Z INFO snap "core" has bad plugs or slots: core-support (unknown interface)
[15:36] <ogra_> stokachu, well, just an INFO message ... does it behave correctly ?
[15:36] <stokachu> ogra_, not sure yet still trying to load my snap
[15:37] <ogra_> (core just got upgraded to  new version, you most likely just got that one)
[15:38] <zyga> stokachu: this is a known issue, not sure where the bug for tracking that is
[15:38] <stokachu> zyga, ok thanks
[15:39] <ogra_> it shouldnt cause any harm though
[15:40] <popey> mvo: just saw your mail about new core and tried to update...
[15:40] <popey> $ snap refresh
[15:40] <popey> 2017-02-16T15:40:17Z INFO snap "core" has bad plugs or slots: core-support (unknown interface)
[15:40] <popey> core 16.04.1 from 'canonical' refreshed
[15:41] <popey> is that expected?
[15:41] <mvo> popey: yes, its just a warning (still not nice)
[15:41] <ogra_> so it refreshed fine and informed you that the old core didnt have that interface
[15:41] <popey> oh, it's moaning about the old core, I see.
[15:41] <popey> thanks
[15:41] <ogra_> well, about the one in use at the time of the upgrade
[15:42] <ogra_> (also, core-support is moot on classic systems)
[15:43] <ogra_> (at least it should be :P)
[16:03] <jdstrand> kyrofa: fyi, responded to https://github.com/snapcore/snapd/pull/2837
[16:03] <mup> PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837>
[16:43] <mup> Bug #1648615 changed: Apps hit apparmor denial trying to connect to unity8's mir_socket <Canonical System Image:Confirmed for alecu> <Snappy:Invalid by mterry> <https://launchpad.net/bugs/1648615>
[16:56] <mup> PR snapd#2874 opened: kmod: added Specification for kmod security backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/2874>
[17:11] <mup> PR snapd#2829 closed: tests: add libvirt interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2829>
[17:27] <sdrobertw> Found this forum post on 96Boards: http://bit.ly/2kWV5l5
[17:36] <kyrofa> sdrobertw, not sure what's going on there-- I suggest an email to the snapcraft list, or have them hop in here so we can troubleshoot
[17:38] <kyrofa> barry, ah, no, I was using the deb anyway. I meant when I run ubuntu image without `-c`, it defaults to using beta
[17:38] <ogra_> sdrobertw, i guess thats the same guy we have on the mailing list, he has assembled a non-working image (kernel snap not fully working etc)
[17:38] <ogra_> sdrobertw, his image is/was built in a way that the firstboot initialization did not properly work, which results in snapd not working
[17:40] <barry> kyrofa: that must be a behavior of snap prepare-image.  if no -c is given to u-i, we don't pass --channel to `snap prepare-image`
[17:40] <sdrobertw> kyrofa: I will tell them to join the channel
[17:40] <kyrofa> barry, ah, interesting. Perhaps you should, haha!
[17:41] <kyrofa> barry, that way you can document it. No one knows you're actually using snapd behind the scenes
[17:42] <barry> kyrofa: we should definitely document that, but understand that u-i will also eventually create classic images, so it's not supposed to be so tied to snaps.  i guess snap prepare-image needs better documentation and/or defaults
[17:42] <kyrofa> barry, understood. Although keep in mind that documentation for snap prepare-image won't help anyone if it's always wrapped by ubuntu-image
[17:43] <kyrofa> barry, if we eventually need to call prepare-image ourselves (is that what you mean?), that's fine
[17:43] <barry> kyrofa: well, what i'd like to do is document u-i "backends" (of which there is only one right now) and that's where we can document how prepare-image is called under the hood
[17:43] <barry> kyrofa: no, you should never have to call it yourself
[17:44] <kyrofa> barry, I see, okay
[17:51] <lool> kyrofa: hey, is cleanbuild working for you with a snap/snapcraft.yaml?
[17:52] <lool> I've got this error when trying a build:
[17:52] <lool> Processing triggers for libc-bin (2.23-0ubuntu5) ...
[17:52] <lool> Could not find snap/snapcraft.yaml. Are you sure you're in the right directory?
[17:52] <lool> To start a new project, use 'snapcraft init'
[17:52] <kyrofa> lool, I haven't tried. To be completely honest I don't use cleanbuild-- I just create a clean container myself so I can utilize caching
[17:52] <lool> kyrofa: would you know if the tarball is supposed to contain snapcraft.yaml?
[17:52] <kyrofa> lool, ohhh
[17:52] <kyrofa> lool, I know what you hit
[17:52] <lool> I looked as the tarignore logic, and it seems correct yet the tarball doesn't contain snapcraft.yaml
[17:53] <kyrofa> lool, indeed, way back when 'prime' used to be called 'snap' so cleanbuild had logic to ignore it when creating the tarball
[17:53] <kyrofa> lool, that's since been fixed, let me see if it's been released yet
[17:53] <lool> oh ok, just me looking at fixed source code which is not the one I'm running, blah
[17:53] <kyrofa> lool, ah, 2.27
[17:53] <kyrofa> lool, it's in proposed
[17:54] <kyrofa> lool, haha, that'll always get ya
[17:55] <kyrofa> lool, sorry about that, we caught that issue too late
[17:55] <lool> no that's great news, it's already fixed
[17:55] <lool> kyrofa: it's funny cause I actually thought of this snap/ ignore explanation and thought "oh that will be easy to fix"
[17:56] <kyrofa> lool, yeah it was like four characters
[17:56] <kyrofa> Plus tests, of couse
[17:56] <kyrofa> with an r in there somewhere
[17:56] <lool> BTW I've noticed two pieces of potentially interesting behavior
[17:56] <lool> one is with dependent libs
[17:56] <kyrofa> Oh?
[17:57] <lool> I have these binaries that require libsctp1
[17:57] <lool> they are prebuilt
[17:57] <lool> if I build the snap on a system that has the package, the lib gets copied automagically
[17:57] <lool> however if it's missing, no error but the snap is incomplete
[17:57] <lool> this would be caught by cleanbuild
[17:57] <lool> in the sense that if I always used cleanbuild and tested the snap I would notice
[17:58] <lool> but someone doing changes / buidling the snap wont notice
[17:58] <lool> I wonder if you should warn/fail the build when trying to copy libs and failing, don't know
[17:58] <kyrofa> lool, indeed. There are a few things here
[17:58] <kyrofa> lool, first, check out https://snapcraft.io/docs/build-snaps/syntax and read about the `build-attributes`
[17:58] <lool> it's kind of hard to both be tolerant in case it's in a later part and to be rigorous to make sure all libs are there
[17:59] <kyrofa> lool, long story short, this is really unclear behavior as you noticed
[17:59] <lool> ah didn't know about build-attributes: no-system-libraries
[17:59] <kyrofa> lool, we're moving to, instead of magically copying things we know we need, erroring on them
[17:59] <kyrofa> lool, we're hemming and hawing on it because it will break a lot of things, though
[17:59] <lool> ok
[17:59] <kyrofa> lool, not sure when that will happen or what it'll look like
[17:59] <kyrofa> lool, however, if you want that behavior now, you can use that build-attribute
[18:00] <lool> can I set build-attributes globally? seems per part
[18:00] <kyrofa> lool, indeed, per-part
[18:00] <kyrofa> lool, it's really there for content sharing when "yes I know that lib isn't here, I don't _want_ it to be"
[18:00] <lool> kyrofa: is it build-attributes: [no-system-libraries]?
[18:00] <kyrofa> You got it
[18:01] <kyrofa> lool, what that means is that you'll need to specify all the libs you need as stage-packages
[18:01] <lool> ok, the other thing I wanted to mention, probably bottom of the priority pile thing, is about 32-bits in amd64
[18:01] <lool> I'm building an amd64 snap on amd64 but it contains a 32-bits runtime because "meh"
[18:01] <lool> when I do this, I get tons or warnings
[18:02] <pmcgowan> kyrofa, is there a way to "pin" a version of a snap so it doesnt update
[18:02] <lool> kyrofa: actually I get one per binary
[18:03] <lool> e.g. Unable to determine library dependencies for b'prime/xyz'
[18:04] <lool> seems fair in terms of number of warnings, just thinking this could the same as for 64 bits, but again I dont expect any priority on this, just thought I'd mention I came across this
[18:05] <kyrofa> lool, got pulled into a call, give me a few and I'll get back to you
[18:06] <lool> kyrofa: no worries, this was just FYI
[18:18] <mup> PR snapd#2865 closed: image,cmd/snap: refactoring and initial envvar support to use stores needing auth <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2865>
[18:30] <kyrofa> Alright, done with the call
[18:30] <ogra_> who won ?
[18:30] <ogra_> :)
[18:30] <kyrofa> Me, duh
[18:31] <kyrofa> lool, ah, indeed that's interesting. We use the host's ldd to check that
[18:31] <kyrofa> lool, but it's not a native elf file, so it skips it
[18:32] <kyrofa> pmcgowan, sorry for the delay: not that I know of. I think you can disable refresh systemwide by stopping the right systemd unit, but that doesn't sound like what you asked for
[18:32] <kyrofa> pmcgowan, however, that's a pretty popular request. manik is tracking it
[18:32] <pmcgowan> kyrofa, not exactly, so if I revert a snap, does that effectively do it?
[18:33] <pmcgowan> I assume the snap wont update after a revert?
[18:33] <kyrofa> pmcgowan, it won't update to the revision from which you reverted, but I do believe it'll update when a new update comes out
[18:33] <pmcgowan> makes sense
[18:36] <DedSec> does anyone know if its possible to have an snap get the current version of an app using an github tag?
[18:36] <kyrofa> DedSec, you mean when building?
[18:36] <DedSec> yes
[18:36] <kyrofa> DedSec, oh certainly
[18:37] <kyrofa> DedSec, use source-tag
[18:37] <kyrofa> DedSec, so you have `source: <github repo>` followed by `source-tag: <tag>`
[18:37] <kyrofa> DedSec, `snapcraft help sources` may prove helpful as well
[18:38] <DedSec> gotcha, so i could easily create an tag for Dev buils and one for stable and then have different snapcraf.yaml files for each version
[18:38] <DedSec> sounds easy :)
[18:41] <brunch875> does anyone know why there are two telegram snaps? I'm using sergiusens one because it has never given me any trouble
[18:41]  * ogra_ uses it becaause he is a sergiusens fanboy
[18:43] <kyrofa> brunch875, the store only cares about the names being unique. Anyone can release anything
[18:44] <brunch875> So I could upload my own telegram? neat
[18:44] <brunch875> thanks kyrofa, that cleared my doubts
[18:44] <kyrofa> brunch875, so if you run `snap find telegram` you'll see that sergiusens has one, and pain7 has one. Pick your poison, or upload your own!
[18:45] <kyrofa> brunch875, the one thing you can be certain of is that telegram has not officially released their own
[18:45] <kyrofa> brunch875, because that would probably be called "telegram" and come from the "telegram" developer
[18:45] <kyrofa> (or something)
[18:45] <brunch875> what if I registered as telegram?
[18:46] <kyrofa> brunch875, I suspect the name is reserved
[18:46] <brunch875> I take it telegram would be able to reclaim its name
[18:46] <kyrofa> brunch875, you'll have to justify it
[18:47] <Pharaoh_Atem> sergiusens: hey, any luck on the PR?
[19:11] <mup> PR snapd#2875 opened: mkversion.sh: Add support for taking the version as a parameter <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2875>
[19:16] <Cynerva> Is there a way for a snap configure hook to get all the config keys?
[19:22] <kyrofa> Cynerva, what do you mean?
[19:25] <Cynerva> kyrofa: I'd like to get a list of every config that's been set for the snap. Partially for validation - so if someone says `snap set mysnap potato` but we don't have a potato config, I'd like to have the hook fail with feedback for the user
[19:26] <kyrofa> Cynerva, ah okay. While I know you can retrieve multiple values at once with `snap get key1 key2 key3 ...` I don't think there's a way to retrieve _everything_
[19:27] <kyrofa> Cynerva, but I think the plan is at some point to allow the snap to specify some sort of schema
[19:27] <kyrofa> (don't take my word for it though, not quite sure on the plan)
[19:41] <jdstrand> ogra_: hey, I was excited to see a new core in stable hoping for logging and ntp options (though they aren't there yet). That's fine, but I wanted to play with 'snap get', so I tried 'sudo snap get core ssh' and various other things, but it didn't work
[19:42] <jdstrand> $ sudo snap get core ssh
[19:42] <jdstrand> error: snap "core" has no "ssh" configuration option
[19:42] <jdstrand> ogra_: I feel like I am missing something obvious
[19:43] <jdstrand> https://docs.ubuntu.com/core/en/guides/build-device/config-hooks only shows 'set'
[19:43] <kyrofa> jdstrand, assuming things haven't changed too much, you can only get things once it's been set. If the hook in the core snap doesn't `snapctl set` them when installing, you can get them
[19:43] <jdstrand> it seems /snap/core/1083/meta/hooks/configure doesn't implement 'get', but I've not used the configure hook
[19:43] <kyrofa> jdstrand, `get` is a snapd function
[19:43] <jdstrand> oh
[19:44] <kyrofa> jdstrand, it just returns the config value corresponding to that key for the snap
[19:44] <jdstrand> let me try with rsyslog rather than ssh
[19:44] <Cynerva> kyrofa: ahh okay, we'll make do without the validation for now, thanks :)
[19:44] <kyrofa> jdstrand, which you can set via `snap set` (in which case the `configure` hook is run and can validate it) or from within the hook via `snapctl set`
[19:45] <ogra_> jdstrand, snap get service.ssh.disabled
[19:45] <jdstrand> sure enough
[19:45] <ogra_> jdstrand, snap get service.rsyslog.disabled
[19:45] <jdstrand> $ sudo snap set core service.rsyslog.disable=false
[19:45] <ogra_> err
[19:45] <jdstrand> $ sudo snap get core service.rsyslog.disable
[19:45] <jdstrand> false
[19:45] <ogra_> yeah
[19:45] <ogra_> so setting it true disables ssh
[19:46] <ogra_> same for rsyslog
[19:46] <jdstrand> $ sudo snap get core service.ssh.disable
[19:46] <jdstrand> error: snap "core" has no "service.ssh" configuration option
[19:46] <jdstrand> right
[19:46] <jdstrand> so you have to 'set' it first
[19:46] <ogra_> yep
[19:46] <jdstrand> ok, I'll file that away while I wait for ntp and remote logging :)
[19:46] <jdstrand> kyrofa, ogra_: thanks!
[19:47] <ogra_> well, service.systemd-timesyncd.disable
[19:47] <ogra_> that one wroks already
[19:47] <ogra_> (so you could install an ntp snap)
[19:47] <ogra_> timeserver is next on my list
[19:54] <mup> Bug #1665438 opened: Running command can end up with wrong security profile if refreshed <Snappy:New> <https://launchpad.net/bugs/1665438>
[20:34] <stokachu> im trying to make a network interface persists through reboots using the daemon configuration, the interface is listed in ip addr but no ip address or iptables rules applied, https://github.com/conjure-up/conjure-up/blob/master/snap/snapcraft.yaml#L20-L24
[20:34] <stokachu> this is a classic snap, am i missing anything here?
[20:35] <stokachu> here i sthe output from systemctl status https://gist.github.com/battlemidget/e7ea01bfb37a3feb38f2c0fc5e138ada
[20:35] <stokachu> i dont see any errors here
[20:37] <stokachu> https://gist.github.com/battlemidget/e7ea01bfb37a3feb38f2c0fc5e138ada#file-gistfile2-txt that shows running the command directly also works
[20:47] <mwhudson> what's the eta on snap info showing tracks?
[20:51] <mup> Bug #1665184 changed: Assertion list returned by GET /v2/assertions/type can't be reliably split <Snappy:Invalid> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1665184>
[21:09] <kyrofa> barry, python3 -m flake8 is finding the one bundled in ubuntu-image before it finds python3-flake8
[21:09] <kyrofa> barry, is that a problem on my machine?
[21:10] <kyrofa> barry, running from the ubuntu-image deb, by the way
[21:10] <barry> kyrofa: i'm not sure what that means.  flake8 isn't bundled with u-i
[21:10] <kyrofa> barry, /usr/lib/python3/dist-packages/ubuntu_image/testing/flake8.py
[21:11] <barry> kyrofa: how is that even on sys.path?
[21:11] <barry> kyrofa: show me all the commands you're doing
[21:12] <kyrofa> barry, within the snapcraft tree: python3 -m flake8 --max-complexity=10 snapcraft
[21:12] <kyrofa> barry, and boy I'll tell you... it's not happy with snapcraft :P
[21:14] <barry> kyrofa: you mean, you're inside a snapcraft git clone?
[21:14] <kyrofa> Indeed
[21:14]  * barry tries to repoduce
[21:14] <kyrofa> barry, which contains another snapcraft directory
[21:15] <kyrofa> barry, my sys.path doesn't look outrageous: http://pastebin.ubuntu.com/24009515/
[21:16] <barry> indeed
[21:18] <barry> kyrofa: wtf?!
[21:18] <kyrofa> barry, do you see it as well?
[21:19] <barry> kyrofa: i do see it in a traceback
[21:20] <barry> offs
[21:20] <barry> kyrofa: i know what the problem is :(
[21:22] <barry> almost
[21:22] <kyrofa> barry, I'm curious
[21:22] <barry> kyrofa: i need to find one more piece of the puzzel
[21:22] <barry> *puzzle
[21:22] <lool> oh I have a funny one
[21:23] <lool> I have a symlink under stage/blah that is pointing to an absolute directory location on my system
[21:23] <lool> snapcraft tries to go in there and change stuff  :-)
[21:23] <kyrofa> lool, how are you getting an absolute symlink into stage?
[21:23] <lool> I wasn't getting this issue until I had something installed in the system location
[21:24] <lool>     install: |
[21:24] <lool>       # ship static symlink pointing to writable dir
[21:24] <lool>       mkdir -p $SNAPCRAFT_PART_INSTALL/config
[21:24] <lool>       ln -sf /var/snap/lteenb-lool/current/rf_driver \
[21:24] <lool>           $SNAPCRAFT_PART_INSTALL/config/rf_driver
[21:24] <lool> in one of my parts
[21:24] <kyrofa> Ah, you're just asking for trouble
[21:24] <lool> I need the symlink though  :-/
[21:24] <kyrofa> lool, snapcraft works really hard in its plugins to prevent that, because you'll end up with a broken link in the final snap
[21:24] <lool> kyrofa: it actually works well in the final snap!  :-)
[21:25] <kyrofa> lool, it won't make it through review, I expect
[21:25] <kyrofa> Oh wait...
[21:25] <kyrofa> lool, you cheater!
[21:25] <kyrofa> I didn't read the entire path
[21:25] <kyrofa> But yeah, I'd still be surprised if the review tools let that through. Have you tried?
[21:26] <kyrofa> lool, I'm assuming the snap is called "lteenb-lool"?
[21:26] <lool> yes
[21:26] <barry> kyrofa: LP: #1631156
[21:26] <mup> Bug #1631156: flake8.extension entry point has global ramifications <Ubuntu Image:Won't Fix> <https://launchpad.net/bugs/1631156>
[21:26] <barry> which doesn't help you much unfortunately :(
[21:27] <kyrofa> barry, ouch. Yeah, I guess I'll remove it then
[21:27] <barry> kyrofa: are you on zesty?
[21:27] <kyrofa> barry, xenial
[21:27] <barry> dang
[21:27] <barry> i could fix it for zesty, but i'd have to put flufl.testing in backports for y and x
[21:27] <barry> which maybe i should do
[21:28] <barry> fwiw, it has nothing to do with snapcraft; any invocation of flake8 will break :(
[21:28] <ogra_> lool, and cp instead of linking doesnt work ?
[21:28] <lool> ogra_: would like to keep the up-to-date master configs in the snap
[21:29] <kyrofa> barry, alright, thank you for the investigation!
[21:29] <ogra_> hmm
[21:29] <barry> kyrofa: let me think more on it
[21:30] <bdmurray> https://snapcraft.io/docs/build-snaps/metadata makes reference to using wrappers, how I can add things to the wrapper?
[21:30] <kyrofa> lool, what exactly are you trying to accomplish there?
[21:30] <lool> kyrofa: the config has an include system with include <rf_driver/foo>; rf_driver is a symlink to the actual backend
[21:31] <ogra_> bdmurray, easiest is to just add another wrapper (yay onions)
[21:31] <kyrofa> bdmurray, those are small scripts you'd write yourself
[21:31] <lool> instead of having the whole config copied into SNAP_DATA, I have SNAP/rf_driver -> SNAP_DATA/rf_driver and I manage the SNAP_DATA/rf_driver symlink with the snap's config
[21:31] <kyrofa> lool, why not generate it at install time?
[21:31] <mup> PR snapcraft#1143 opened: Switch Track and Arch in channel maps <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1143>
[21:32] <lool> kyrofa: well the configs are under SNAP, so cant write there
[21:32] <bdmurray> ogra_: Could you elaborate?
[21:32] <ogra_> bdmurray, command-<command>.wrapper is generated, you cant really change it ... but you can make "command" another wrapper that then calls the actual command
[21:32] <kyrofa> lool, ah yes of course
[21:33] <ogra_> bdmurray, an onion of shell wrappers ...
[21:33] <kyrofa> lool, so when you say snapcraft messes with it, what do you see happening?
[21:33] <mup> PR snapd#2824 closed: overlord: make seeding work also on classic, optionally <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2824>
[21:34] <lool> generally, it doesn't build anymore right now, I think it used to with previous version; but more interestingly, when I build it with the snap installed, because the absolute symlink ends up in stage/, snapcraft dives into it and tries to move files underneath
[21:35] <lool> I suspect I have changed other things in the build that trigger this issue though
[21:35] <kyrofa> lool, yeah probably because it notices it's absolute, so it's trying to follow the symlink and copy the dir
[21:35] <bdmurray> ogra_: there's nothing that can be put in the yaml file to just set env variables in the wrapper?
[21:36] <ogra_> bdmurray, i think something was recently added ... not sure it is in a released snapcraft yet ?
[21:36] <kyrofa> bdmurray, you'll be able to do that in snapcraft v2.27, in proposed
[21:36] <ogra_> kyrofa, was the environment handling in snapcraft.yaml released already ? (and are there docs for bdmurray )
[21:36] <kyrofa> ogra_, too slow!
[21:36] <ogra_> ah, yeah :)
[21:37] <ogra_> <- old fart :P
[21:37] <lool> kyrofa: I'll play a bit more with it, I think I can reduce the number of weird things
[21:45] <pmcgowan> ogra_, kyrofa which services do I need to disable to stop auto updates? is snap.refresh.service enough?
[21:45] <kyrofa> pmcgowan, I _think_ so
[21:47]  * kyrofa wonders about snapd.refresh.timer
[21:47] <pmcgowan> kyrofa, that was my thought
[21:48] <kyrofa> pmcgowan, I haven't done this if you can't tell :
[21:48] <kyrofa> :P
[21:48] <bdmurray> How can I only rebuild the necessary parts of the snap after I added environment information to the yaml file?
[21:51] <kyrofa> bdmurray, just run `snapcraft` again, that meta-data is always copied over
[21:52] <kyrofa> bdmurray, are you running out of snapcraft master, then?
[21:55] <bdmurray> kyrofa: no 2.27 is in -proposed and I installed it
[21:55] <kyrofa> bdmurray, ah, okay
[21:55] <kyrofa> Then you should be good, yeah
[21:56] <lool> kyrofa: so I was wrong, everything is fine now; I think the new snapcraft was actually stricted and made me fix a bug (trying to install this symlink twice) which probably snapcraft shouldn't bother detecting
[21:56] <lool> what was really happening was that another part was shipping a default version of this symlink (the upstream one) and when snapcraft tried installing it, it installed in the system dir due to my hacked symlink
[21:57] <lool> not something you should worry about really
[21:57] <kyrofa> Ahh, yeah that would be tough
[21:57] <lool> once I stopped priming that copy of the symlink, things worked again just fine
[21:57] <kyrofa> Good catch though
[21:57] <lool> well snapcraft was good actually
[21:57] <lool> it's actually been a pleasure to do this build from source that upstream requested (instead of the from debs I had)
[21:58] <kyrofa> Yeah in my experience anything complex from debs just require all sorts of hackery to make work
[21:58] <kyrofa> From source is so much easier in a lot of cases
[21:59] <pmcgowan> kyrofa, after some search I decided to disable the timer just fyi
[21:59] <lool> kyrofa: it was from a PPA in this case, but otherwise trivial to use the debs
[21:59] <kyrofa> pmcgowan, I guess you'll see in a few hours if that's what was required :P
[21:59] <kyrofa> Ah, okay
[22:01] <mup> PR snapcraft#1118 closed: Trigger beta tests on travis every day <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1118>
[22:01] <mup> PR snapcraft#1144 opened: Trigger beta tests on travis every day <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1144>
[22:20] <bdmurray> kyrofa: So that didn't work out too well for me. http://pastebin.ubuntu.com/24009810/
[22:20] <kyrofa> bdmurray, that doesn't mean anything to me. But I assume you're saying the environment variable wasn't defined? Can I see your snapcraft.yaml?
[22:21] <bdmurray> kyrofa: I'm saying I think the "\n" is an issue
[22:21] <kyrofa> bdmurray, wait.... you're essentially calling `open('$SNAP')`?
[22:22] <bdmurray> kyrofa: no $SNAP/lib/python3.5/site-packages/etc/apport/crashdb.conf
[22:22] <kyrofa> bdmurray, point is, python isn't going to resolve that for you
[22:22] <kyrofa> bdmurray, I'm not sure where that's coming from in this case, but that's definitely wrong
[22:23] <bdmurray>       APPORT_CRASHDB_CONF: $SNAP/lib/python3.5/site-packages/etc/apport/crashdb.conf
[22:23] <bdmurray> That's what I put under environment:
[22:23] <kyrofa> bdmurray, looks like the environment is working then
[22:23] <kyrofa> bdmurray, but your python code needs to support that string containing an environment variables
[22:23] <kyrofa> Which it seems it does not
[23:05] <kyrofa> bdmurray, to be clear, $SNAP is defined at runtime, not at build time


[01:52] <greg-g> I need help describing a bug so I can make sure I'm not reporting a duplicate. Here we go:
[01:54] <greg-g> I have my email filered by imapfilter every 3 minutes, sometimes TBird gets new messages during a time when a message is in my inbox and not yet filtered. It shows up there to be expected. However, later when the message has been filtered to the right folder, in TBird it now shows up in both locations.
[01:54] <greg-g> This is with 3.3a1, btw.
[01:54] <greg-g> I know to report it upstream, but, I just have no idea how to make that a simple bug title/search for a possible duplicate
[01:54] <micahg> greg-g: we don't have 3.3a1 packaged yet
[01:54] <micahg> ok
[01:54] <micahg> :)
[01:54] <greg-g>  :)
[01:55] <greg-g> I'm at a lose as "duplicate" brings up way too many search results :/
[01:55] <greg-g> loss, even
[01:57] <greg-g> oh well, I'll just report it upstream and hopefully someone can help me refine my bug title :)
[01:58] <micahg> greg-g: mozilla 573729 seems close
[01:58] <ubot2> Mozilla bug 573729 in Filters "Race condition when two TB instances on different computers move messages based on filters - messages get duplicated." [Major,Resolved: incomplete] http://bugzilla.mozilla.org/show_bug.cgi?id=573729
[01:58] <micahg> also mozilla 519083
[01:58] <ubot2> Mozilla bug 519083 in Filters "message duplicated when copied or moved from filter" [Normal,Unconfirmed] http://bugzilla.mozilla.org/show_bug.cgi?id=519083
[02:00]  * greg-g is reading
[02:00]  * micahg will bbiab
[02:02] <greg-g> yeah, that first one looks almost related, but that results in two messages being in FilteredFolder, not one being in the original location and one being in the folder. I suspect it is something to do with IMAP-IDLE from that bug though.
[02:02]  * greg-g tests turning IDLE off
[02:12] <greg-g> no, not an IDLE issue :/
[02:23] <greg-g> micahg: just in case you are curious: https://bugzilla.mozilla.org/show_bug.cgi?id=618201
[02:23] <ubot2> Mozilla bug 618201 in General "Messages stays in Inbox after imapfilter moves it to another folder" [Normal,Unconfirmed]
[02:37] <micahg> greg-g: I added you to my watch list, I'll try to keep an eye on the progress
[02:37] <micahg> greg-g: hopefully by next month we'll have 3.3 builds
[02:40] <greg-g> micahg: rock, I look forward to it. I'm just getting a jump on testing ;)
[03:24] <vish> micahg: hi, why do we not enable FF's smooth-scrolling by default?
[03:24] <vish> well, it does seem to use more CPU here.. but is that the problem for everyone?
[03:24] <micahg> vish: no idea, I saw a bug for it recently
[03:25] <micahg> vish: I can look into it
[03:25] <vish> micahg: yea, hence the Q
[03:25] <vish> micahg: thanks. :)
[03:26] <vish> i was testing with smooth-scrolling and it does cause X freeze for me.. but that might just be a bug in my graphics..
[06:34] <micahg> chrisccoulson: please push xulrunner-1.9.2.head changelog when you get a chance, I'll fix the arm FTBFS in natty afterwards
[15:08] <dpm> fta, another complete translation: the Simplified Chinese team just told me they've finished translating Chromium: https://translations.launchpad.net/chromium-browser :-)
[15:20] <fta> \o/
[15:21] <fta> dpm, jcastro: i've been told that the guy working on packaging chromium-os (not chrome-os) is interested by merging our translations
[15:21] <jcastro> !
[15:26] <fta> hm, bug 688492
[15:26] <ubot2> Launchpad bug 688492 in chromium-browser (Ubuntu) "Not rendering Thai or Lao correctly (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/688492
[15:29] <fta> dpm, ^^ is that something you're familiar with?
[15:39] <dpm> fta, ah great to hear that (chromium-os)! I'm not familiar with font rendering. I'd suggest jtv to file a bug against upstream, as he's more knowledgeable on this than I am
[16:24] <fta> dpm, btw, i've slightly improved the error logs: http://people.ubuntu.com/~fta/chromium/translations/trunk/converter-output.html
[16:24] <fta> dpm, how can we get the translator's attention to fix those?
[16:25] <fta> dpm, i can sure fix this kind of trivial errors but i'd prefer the translators to be aware of those mistakes
[17:12] <dpm> fta, sorry for the delay. An e-mail to the launchpad-translators list with CC to ubuntu-translators would work. You can send it yourself or if you tell me what should be on the e-mail I can do it for your you if you like
[17:13] <fta> dpm, where can i find the full emails?
[17:13] <dpm> or wait a sec, we can perhaps get the pt-br ones fixed straight away, by pinging someone on IRC
[17:14] <dpm> fta, launchpad-translators AT lists DOT launchpad DOT net and ubuntu-translators AT lists DOT ubuntu DOT com
[17:14] <fta> thanks
[17:17] <dpm> fta, the Brazilian guys are looking at it right now, I couldn't find anyone from the German team online
[17:34] <dpm> so it seems now pt-br translations are fixed


[07:03] <pov> hello
[07:04] <pov> is anybody has from KZ?
[08:09] <iomari891> greetings, what time will 22.10 be available?
[08:09] <arraybolt3> iomari891: Probably later today. The exact time, not sure.
[08:09] <iomari891> arraybolt3: thanks
[09:43] <qw3rty> 'ello
[13:16] <BluesKaj> Hi all
[18:51] <user|34> Sooo, when we can expect do-relase-upgrade to work? I can see the isos already, but it's not upgrading yet
[18:52] <arraybolt3> user|34: Be patient, it only just came out! :P You might need to set your system to be able to upgrade to non-LTS releases, which you can do by running "sudo software-properties-kde" in a terminal, then clicking "Updates", then setting "Show new distribution releases" to  "Normal Releases".
[18:53] <arraybolt3> I don't know for sure if it's available to upgrade to yet, but I'd be surprised if it was.
[18:53] <user|34> I'm always curious to check out new things ^^
[18:56] <arraybolt3> I see that. :-D Y'know, if you wanted to, you could try installing the latest Kinetic daily ISO into a VM and then do-release-upgrading it to the as-of-yet unnamed Ubuntu LL development release. That would give you the absolute newest stuff that Ubuntu is doing, in a safe environment. Be prepared for it to break, we developers and developer helpers like to do all sorts of crazy stuff early on in the cycle.
 It's not yet available as an update no
 But iso is there already
 Are there already any backports for KDE 5.26.1?
 Yes (re @ksenchy: Are there already any backports for KDE 5.26.1?)
 Where
[21:38] <oerheks> ksenchy not for 22.04; for 22.10 beta > sudo add-apt-repository ppa:kubuntu-ppa/backports
 Thx, will wait for update then


[00:28] <g4vr0che> Excuse me. I believe I inadvertenly sent something here via ubottu. It can be safely disregarded. Thanks
[00:33] <ikonia> ok
[00:33] <ikonia> no problem
[02:00] <phunyguy> Need to keep an eye on that nicholas fella.
[05:52] <genii> Apologies
[06:06] <valorie> ooo, can't spell relevant either, tsk tsk
[06:18]  * genii hears about coffee
[07:09] <rww> hrm, I haven't been called a nazi in a while
[07:26] <valorie> :(
[07:27] <rww> fun fact: said user then moved to the Ubuntu subreddit to complain about me
[07:27] <rww> he managed to pick the *only other* Ubuntu thing I moderate to complain on
[07:28] <Tm_T> aww
[07:29] <rww> which, amusingly, lets me see what other posts he's made on reddit. including the large number of them to /r/mensrights, wherein he discusses his dislike of women
[07:29] <rww> real winner there
[07:29] <rww> oh look, racism and problematic nsfw ones too
[07:30] <valorie> an all around fun troll?
[07:34] <rww> it's actually fairly fascinating
[07:34] <rww> he seems to have parental issues
[07:34] <Flannel> rww: and how does that make you feel?
[07:34] <rww> i haven't had a decent insight into the mind of a troll in a while
[07:34] <Flannel> rww: tell me more about decent insight into the mind of a troll
[07:35] <rww> this isn't the 90s flannel, nobody knows what Eliza is any more
[07:35] <Flannel> :(
[07:36] <rww> ironically, he also posts anti-Jewish stuff to /r/conspiracy
[07:36] <rww> so
[07:36] <rww> that's a bit hilarious
[07:36] <elky> maybe he was complimenting you in his own way?
[07:37] <rww> maybe he's frustrated because he's one of the minority in that subreddit that actually think the holocaust happened
[07:47] <rww> aanndd just found his alt account
[07:47] <rww> which he uses to upvote and agree with himself
[07:47] <rww> because lol
[07:57] <valorie> at least he's not out on the streets creating havok
[07:57] <rww> indeed
[19:11] <phunyguy> rww: which user was it?
[19:12] <rww> phunyguy: IRC handle javi404, reddit handles javi404 and 355pm
[19:14] <phunyguy> ahh ok
[19:15] <phunyguy> I had a similar experience with someone else, only they know me just here.... but I found them on facebook and it was basically what I expected.
[19:15] <phunyguy> tough guy only on the Internet... minimum wage job because he can't keep one for more than a month, family issues, problems with authority, etc
[19:17] <phunyguy> after telling me how bad he would beat me up, and how I would fold like paper on the streets, etc, I found a picture he posted where he said he was scared while driving through the ghetto.
[19:17] <phunyguy> made my afternoon.
[19:18] <rww> then there's the guy who used to be in #ubuntu-offtopic until I banned him enough and then migrated to ##chat, who's a rabid republican who hates obama and liberals and welfare... but is dirt poor and on welfare
[19:25]  * phunyguy grumbles
[19:37]  * IdleOne takes phunyguy's welfare stamps and gubmant cheez
[20:49] <phunyguy> I am one of the weird ones that actually likes government cheese, IdleOne.
[20:49] <phunyguy> And I have been on food stamps before.  Not something I would wish on anyone.
[20:54] <Pici> I'd fold you like an origami swan.
[21:40] <phunyguy> Pici: promise?
[21:40] <phunyguy> pinky swear....
[22:57] <genii> ouchies
[23:59] <daftykins> best watch this kingtat fellow, utter lies and poor advice are being spewed


[02:47] <dupingping> hi everyone.
[02:47] <dupingping> I built a launchpad.dev server on my local.
[02:48] <dupingping> And it shows me "Module zope.publisher.publish, line 132, in publish
[02:48] <dupingping> result = publication.callObject(request, obj)
[02:48] <dupingping> Module lp.services.webapp.servers, line 1508, in callObject
[02:48] <dupingping> raise NotFound(self, '', request)
[02:48] <dupingping> what should i do?
[02:58] <wgrant> dupingping: Which URL are you accessing?
[02:58] <wgrant> That can indicate that you're using an unrecognised domain.
[02:59] <dupingping> yes, at the local lan, vm server.
[03:00] <wgrant> Launchpad uses vhosts extensively, so you can't access it by IP address or the machine's hostname.
[03:00] <wgrant> You need to use https://launchpad.dev/[...], or one of the recognised subdomains.
[03:00] <wgrant> https://dev.launchpad.net/Running/RemoteAccess
[03:00] <dupingping> oh, I did not use vhost. I installed it directly on my local pc.
[03:01] <wgrant> The Launchpad application will only respond to domains that it knows about.
[03:01] <wgrant> So you need to edit /etc/hosts (or a local DNS zone).
[03:02] <dupingping> oh, yes, let me try now.
[03:02] <wgrant> eg. I run LP in an LXC container, so in my host's /etc/hosts:
[03:02] <wgrant> <IP_ADDRESS>       launchpad.dev answers.launchpad.dev archive.launchpad.dev api.launchpad.dev bazaar.launchpad.dev bazaar-internal.launchpad.   dev blueprints.launchpad.dev bugs.launchpad.dev code.launchpad.dev feeds.launchpad.dev keyserver.launchpad.dev lists.launchpad.dev ppa.  launchpad.dev private-ppa.launchpad.dev testopenid.dev translations.launchpad.dev xmlrpc-private.launchpad.dev
[03:02] <wgrant> xmlrpc.launchpad.dev
[03:02] <dupingping> yes, It works as http://localhost:8085 in my PC.
[03:03] <wgrant> utilities/rocketfuel-setup automatically configures /etc/hosts, if you used that script.
[03:04] <dupingping> yes, i used it, rocketfuel-setup.
[03:04] <wgrant> Does https://launchpad.dev/ work?
[03:04] <dupingping> And how to register an account on that server?
[03:04] <dupingping> yes, work.
[03:05] <wgrant> The initial dev database has certain preconfigured accounts. You can log in as eg<EMAIL_ADDRESS>for an admin account<EMAIL_ADDRESS>for an unprivileged account, and various others that can be found in the "emailaddress" table.
[03:05] <dupingping> yes, let me try.
[03:13] <dupingping> oh, It shows me an error, I'll pastebinit soon.
[03:14] <wgrant> Possibly an OpenID TLS cert issue, we'll see.
[03:16] <blr> dupingping: there's also a script for generating new accounts/users in utilities/make-lp-user
[03:17] <dupingping> blr, yes, let me try.
[03:19] <dupingping> please look, http://paste.ubuntu.com/13613443
[03:21] <wgrant> dupingping: Try going back to the homepage and logging in again.
[03:21] <wgrant> I've seen that before on the very first session on a fresh DB, and then it works a second time.
[03:22] <dupingping> wgrant: yes, let me try again.
[03:38] <dupingping> wgrant: it's run on same PC but from another one. the launchpad.dev/+login page shows me You don't have permission to access /+login on this ...
[03:39] <wgrant> dupingping: Edit the ACLs in /etc/apache2/sites-available/local-launchpad
[03:55] <dupingping> wgrant: thank you, I did it. And I want to know how to build bootable iso image from many source packages?
[03:55] <dupingping> please help me.
[03:55] <dupingping> I just found launchpad-buildd script. I think that it's just a wrapper for debian livefs project.
[03:56] <wgrant> There are many steps between where you are now and bootable images.
[03:56] <wgrant> https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally documents some of them.
[03:56] <dupingping> yes, let me try, the steps. wgrant:
[03:57] <wgrant> dupingping: But if you're just looking to build images, a full Launchpad really isn't the easiest way to do that.
[03:59] <dupingping> wgrant: yes, And I think that i should build a local server same as launchpad.net to develop launchpad.
[04:00] <wgrant> Right, if you want to develop Launchpad then that totally makes sense.
[04:00] <wgrant> But I wouldn't necessarily start by building ISOs; that's a big chunk of complex infrastructure.
[04:01] <dupingping> wgrant: So, please help me.
[04:04] <wgrant> dupingping: If you want to develop Launchpad, ISO building is not a good first thing to work on. And if you just want to build ISOs, your own Launchpad is not a good way to do that.
[04:06] <dupingping> wgrant: yes, but I could not understand how to run the launchpad.net fully.
[04:06] <dupingping> And without fully understand, I could not join to develop launchpad.net
[04:07] <dupingping> *develop* may contribute.
[04:07] <wgrant> ISO building relies on all of the things described on HowToUseSoyuzLocally.
[04:07] <dupingping> So i wanted to fully duplicate the launchpad.net to my local PC.
[04:07] <wgrant> Understand all of that first, and then you can eventually move up to building ISOs.
[04:07] <dupingping> wgrant: yes.
[04:15] <dupingping> wgrant: yes.
[04:16] <dupingping> wgrant:  what is the source build project of the launchpad.net?
[04:16] <dupingping> e.g. launchpad-buildd build iso image from binary packages.
[04:16] <dupingping> I mean that build binary packages steps.
[04:17] <dupingping> from source packages.
[04:20] <dupingping> wgrant: let's guess about following point.
[04:21] <dupingping> If i modified libc package, so many packages needs to be rebuilt.
[04:21] <dupingping> then how can i get the packages list to be rebuilt?
[04:22] <dupingping> to get distro iso image.
[04:22] <dupingping> wgrant: make sense?
[04:33] <wgrant> dupingping: launchpad-buildd builds several different things, including binary packages and live images.
[04:34] <dupingping> wgrant: yes. then it detects source depends packages?
[04:34] <wgrant> dupingping: A glibc change doesn't require the entire world to be rebuilt.
[04:35] <dupingping> wgrant: yes, right. it's just an example. If i modify a frequently used function's parameter.
[04:35] <dupingping> how can i detect source packages that use it?
[04:35] <wgrant> Launchpad has no facilities for automatically doing that.
[04:35] <wgrant> You'd use external tools to analyse the archive.
[04:36] <dupingping> external tools?
[04:37] <dupingping> I'm sure i can detect dependency tree of binary packages. Is there a tool for source packages?
[04:37] <wgrant> There are no fundamental differences between the two.
[04:39] <dupingping> So is there a tool to do it?
[04:41] <wgrant> It depends on exactly what you're going to do, but regardless it's not within Launchpad's remit.
[04:45] <dupingping> wgrant: yes, i see.
[10:59] <cjwatson> wgrant: Could you glance over my post-review changes to https://code.launchpad.net/~cjwatson/launchpad/limit-debdiff/+merge/278187 ?
[11:05] <wgrant> cjwatson: I assume debdiff doesn't do anything silly like uncompressing the tarball onto disk before extracting it?
[11:05] <wgrant> >1GiB single files are unlikely, but uncompressed tarballs are plausible.
[11:22] <cjwatson> wgrant: It may call dpkg-source, which I don't *think* does that, but you never know.  Maybe I should bump that to 10GiB; the main purpose is just to defend against running haetae out of disk.
[11:22] <cjwatson> wgrant: There were 22 diffs in dogfood's DB over 1GiB.  They must all have taken quite some time to generate (I didn't check).
[11:27]  * cjwatson bumps that


[00:45] <seidos> feeling under dressed
[00:45]  * seidos puts on a bow tie
[00:55] <philipballew> seidos, why the style choice?
[00:56] <seidos> philipballew: why the logic?
[00:57] <philipballew> seidos, well logic would say if you put what your wearing on irc, it is not a common outfit to be worn by you. therefor logic would ask why the change
[00:57] <seidos> philipballew: so cyberspace isn't magical?
[00:58]  * seidos throws bow tie in the trash can
[00:58] <seidos> lol
[00:58] <philipballew> theres no doves appearing out of hats on my screen haha seidos
[00:59]  * seidos cries
[01:00] <seidos> this is what it sounds like, when doves cry
[01:06] <philipballew> i hear music coming from my speakers. i like the sound of doves crying seidos
[01:09] <seidos> pigeons croo
[01:09] <seidos> croo croo, not sure about crying
[01:10] <seidos> t.v. is on, watching cartoon network \o/
[01:10] <seidos> it's a star wars clone wars marathon
[01:10] <akk> mourning doves cry -- ooooahhhhhh oooooohhhhh ooooohhhhhhhh
[01:11] <seidos> mourning doves cry: "where's my crew!  where's my crew!"
[01:51] <seidos> this is weird:  http://techcrunch.com/2011/07/04/mark-zuckerberg-is-the-most-followed-user-on-google/
[01:55] <philipballew> why would he have a profile?
[01:58] <seidos> seems fishy to me
[01:59] <seidos> he is known for issuing fake adverts
[01:59] <philipballew> i watched the social network or whatever that movies called the other day
[01:59] <philipballew> they used kde to do all their stuff in the movie
[02:01] <seidos> won't see it
[02:02] <seidos> saw transformers 2 finally
[02:36] <grantbow> can someone please update the topic for the next meeting on July 17th? Thanks.
[03:06] <jdeslip> Finally...
[03:06] <jdeslip> :)
[03:07] <seidos> make sure you wrote command down :D
[03:20] <grantbow> I used rww's suggestion merged with mine and embelished a bit. "Agenda items added within 24 hours of the start of the meeting may be postponed until the next meeting. Adding your item well in advance helps everyone collaborate and avoids last minute surprises."
[03:21] <grantbow> comments and suggestions welcomed.
[03:23] <seidos> hmmm, what did lady macbeth even look like?
[03:24] <seidos> there isn't a way to collaborate on launchpad, is there?
[03:24] <seidos> it seems like IRC is where it's at...
[03:24] <seidos> it would make sense if things could start off chill, then if it gets enough momentum then put it on the meeting agenda
[03:25] <seidos> ideas come and go, not sure that all of them are worth putting on an agenda
[03:26] <seidos> would be cool if they could be hashed out informally among friends
[03:40] <grantbow> I agree
[05:35] <cactaur> I feel like this would be appropriate today in a California room.
[05:36] <cactaur> Especially after the now-5-year-reigning hot-dog champion.
[05:36] <cactaur> http://www.youtube.com/watch?v=HgqbCq_sxmo
[16:17] <pleia2> rww brought it up during the meeting - yes we discussed goals last time, and they were added to the application, they just all seemed short term rather than long term, and were added accordingly
[16:25] <MarkDude> pleia2, did you see my snarky comments after the meeting ? I wanted rww to tell you I went nuts and started quoting Churchill :D
[16:25] <MarkDude> But of course did not do such a thing
[16:25] <nigelb> *went*?
[16:25] <MarkDude> nigelb, I did not
[16:26] <pleia2> MarkDude: I saw :)
[16:26] <MarkDude> Although, my reputation greatly proceeds me, argue with one billionaire that starts Open Source project, people rememebr
[16:27]  * MarkDude was very uppity last year :D
[16:28] <pleia2> haha
[16:29]  * MarkDude had some maritime signal flares we lit off last night- They go up 100 meters, and stay lit for a minute or so
[16:30] <MarkDude> Yay- the 4th means blow sh*t up
[16:30] <MarkDude> and booze and bbq
[17:00] <BrightAmbition> hello
[17:00] <BrightAmbition> geez did i run someone away?
[17:00] <BrightAmbition> lol
[20:59] <pleia2> requested http://www.jonobacon.org/2011/07/05/free-official-ubuntu-book-for-approved-loco-teams/


[16:23] <hannie> hi CarstenG
[16:23] <CarstenG> Hi Hannie
[16:24] <hannie> If you have a few minutes, I need your help
[16:24] <CarstenG> Sure
[16:24] <CarstenG> I try my best :-)
[16:25] <hannie> I have installed Virtual Box and want to install Raring. But I do not get internet connection when trying to install within VB. Any idea?
[16:26] <hannie> I have googled for an answer, but to no avail (yet)
[16:27] <hannie> When I open Firefox in Raring, it cannot load webpages because there is no connection
[16:27] <CarstenG> mmmh
[16:27] <hannie> Could it be VB, or Raring?
[16:27] <CarstenG> I don't have Virtual Box in use.
[16:28] <hannie> ah, I thought you had
[16:28] <CarstenG> I use QEMU
[16:28] <hannie> I might try that one. Are you happy with it?
[16:28] <CarstenG> And there internet was working out of the box.
[16:28] <CarstenG> Well, it works. :-)
[16:28] <hannie> Ok, I can try to use that.
[16:29] <hannie> Will let you know what the result is...........
[16:29] <CarstenG> There is one thing I did not yet solved...
[16:29] <hannie> and that is?
[16:30] <CarstenG> When I want to make a screenshot from the host system of the QEMU window, I have manually scale the QEMU window to the right size to get 768x 1024 pixel...
[16:30] <CarstenG> And this is a bit stupid.
[16:31] <CarstenG> I'm looking for a setting where I can define the size of the window.
[16:31] <hannie> Ah. I remember I had problems with pixels in emulated Quantal in VB as well
[16:32] <hannie> It switched to other resolution without letting me know
[16:32] <CarstenG> But this is maybe a general question for window managers, not for QEMU or VB...
[16:32] <hannie> I will try to install qemu and let you know when I have done it
[16:37] <CarstenG> Nice.
[16:37] <CarstenG> I have also a question:
[16:38] <CarstenG> Could you please have a look to http://ubuntuone.com/6E3PLypVgAhGx6AQwAXdrE (German draft version of precise) and tell me what you think of this links to Launchpad.
[16:39] <CarstenG> So one can jump very quickly to the right string in LP.
[16:39] <CarstenG> for review and fixes.
[16:47] <CarstenG> Ok, I have to leave. See you later...


[02:11] <artnay> updated: https://wiki.ubuntu.com/ArtworkTodoProposal. now I need to get some sleep, later mates
[01:51] <artnay> about the structure of wiki... do you have any ideas? :o
[01:52] <artnay> we don't want to mess it up and then notice it wasn't that carefully planned
[01:53] <artnay> nevertheless it would be nice to get it updated on this weekend
[01:54] <klepas> hey artnay
[01:54] <artnay> hi klepas
[01:55] <artnay> https://wiki.ubuntu.com/ArtworkTodoProposal
[01:56] <artnay> there's what I've been thinking
[01:56] <artnay> but I could use some help with planning the structure
[01:56] <klepas> i'd be happy to help
[01:56] <klepas> just busy with stuff
[01:57] <klepas> in the moment
[01:57] <klepas> how long will you be online for artnay? :)
[01:57] <artnay> too long as always :)
[01:57] <klepas> good
[01:57] <artnay> I already closed my phone so my gf won't be bugging me
[01:57] <klepas> well for me that is
[01:57] <klepas> that's nice
[01:57] <klepas> =)
[01:58] <artnay> maybe the Members section should be renamed as Contact
[01:58] <artnay> and then there would be a list of members with e-mail addresses, info on this channel and the mailing list
[02:00] <klepas> i don't think 'members' would be an applicable choice of wording
[02:00] <klepas> how about 'contributers'?
[02:00] <klepas> or something like that
[02:00] <artnay> changed already
[02:00] <artnay> to Contact
[02:01] <artnay> the thing that is bugging me has something to do with the current projects
[02:01] <artnay> how should they be separated?
[02:02] <artnay> main page is easy to modify, but projects page should be planned very carefully
[02:02] <klepas> i'm not even sure myself
[02:02] <klepas> i'm not an 'official' ubuntu contributor yet
[02:02] <artnay> me neither
[02:02] <klepas> :)
[02:02] <artnay> but I just feel thanking Mark for giving us Ubuntu ;)
[02:05] <klepas> Hehe. Reasonable enough
[02:05] <klepas> reason why I started helping out with various things here and there
[02:05] <klepas> not much yet in Ubuntu though
[02:11] <artnay> should we have a page for general feedback?
[02:11] <artnay> or should ppl give their feedback to project's discussion page?
[02:12] <artnay> what if there is no project? if people just want to give new ideas etc.
[02:12] <artnay> and they don't want to use the mailing list nor irc
[02:13] <artnay> or something similiar to "HelpArtworkTeam"
[02:13] <artnay> maybe that would go under FAQ after all
[02:14] <artnay> what do you think?
[02:29] <klepas> yea
[02:29] <klepas> you've got a point about people not wanting/being lazy about using either the ML or IRC
[02:34] <artnay> so that would be one topic then
[02:35] <klepas> definitely
[02:36] <klepas> but somehow i think in our current state, a lot of people wouldn't make use of the wiki either
[02:36] <klepas> as is proven already =\
[02:38] <artnay> true, but we need to gather up first
[02:38] <artnay> when people see that there's some activity, they might participate
[02:38] <klepas> yea
[02:39] <artnay> now they might think the whole development process is sort of secret (unless they realize that nothing is actually happening)
[02:40] <artnay> I'll take a shower and grab something to eat, brb
[02:42] <klepas> np
[02:42] <klepas> enjoy
[02:53] <artnay> ok, now I feel like F5'd
[02:54] <artnay> is henrik a part of artwork team? at least he is behind AUC
[02:55] <artnay> or is he? :o
[02:57] <artnay> I hate to steal this facility to moan but I contributed 2 backgrounds a couple of weeks back here, still no sign of them and after 2 emails still no feedback if anythings wrong, which is a little frustrating!
[02:58] <artnay> " "
[03:01] <artnay> https://addons.mozilla.org/themes/moreinfo.php?id=1567&application=firefox
[03:02] <artnay> tango theme for fx
[03:03] <artnay> I'd love to see humility theme for fx
[03:03] <artnay> that would bring some consistency
[03:04] <artnay> people are using that as an arguement for changing epiphany
[03:05] <klepas> artnay: yea
[03:05] <klepas> i know what you mean
[03:05] <klepas> Henrik is actually a Canonical guy, iirc
[03:06] <klepas> Henrik, volvoguy (Aaron, iirc) and I have admin rights to AUC
[03:06] <klepas> but I've stopped using administering it because it is simply such an annoying process of adding new items
[03:09] <artnay> ok, I've never tried that art.* concept
[09:20] <derek[] > Is there a ttf viewer for linux where I could preview them?


[17:13] <ochosi> bluesabre_laptop: ping
[17:33] <ochosi> bluesabre: ping :)
[17:33] <bluesabre> hey ochosi
[17:33] <bluesabre> btw, just uploaded a few fixes
[17:34] <ochosi> ah nice
[17:34] <ochosi> gotta pull again then :)
[17:35] <bluesabre> everything that's currently in there should be working as expected at this point
[17:35] <ochosi> cool
[17:35] <ochosi> how're you determining whether something is an application?
[17:35] <ochosi> (i get lots of .iso, postinst etc. that are definitely not applications)
[17:36] <bluesabre> just by mime right now.  Unfortunately, things like pdf and such are also listed under the application mime
[17:36] <ochosi> (i mean: they're executables, but not applications)
[17:36] <ochosi> right. i see
[17:36] <ochosi> maybe we should work around that somehow
[17:36] <bluesabre> yeah
[17:36] <ochosi> only search for stuff in /bin and .desktop or something like that
[17:36] <bluesabre> good idea
[17:37] <ochosi> but anyway, there's appfinder for that :)
[17:37] <bluesabre> I actually need to tweak all the type filters since mimetype isn't always so accurate
[17:37] <ochosi> (i mean if you're seriously looking for something that is installed in the right place)
[17:37] <ochosi> mhm
[17:37] <bluesabre> true
[17:37] <ochosi> one more thing about the suggestions
[17:37] <ochosi> i think the delay needs some tweaking
[17:38] <ochosi> maybe more delay, currently it slows down typing too much
[17:38] <ochosi> it seems to poll after every letter/change
[17:38] <ochosi> (i mean immediately)
[17:38] <bluesabre> yup
[17:39] <ochosi> let me quickly look at what we did for gmusicbrowser
[17:39] <ochosi> cause there we tested quite a while what feels best
[17:40] <ochosi> also: don't poll after the first letter
[17:42] <ochosi> something like: my $timeout = $1<2 ? 1000 : $1==2 ? 200 : 100 (in perl)
[17:43] <ochosi> (or drop the 1000, maybe better)
[17:54] <bluesabre> ochosi: try it now.  I moved the suggestions into a gobject thread
[17:57] <ochosi> bluesabre: far better
[17:58] <bluesabre> awesome
[17:58] <ochosi> but still, if i try to type "xubuntu" it stops me after "xu" :/
[17:58] <bluesabre> ok, I'll throw some timeouts in there
[17:58] <ochosi> thanks :)
[17:59] <ochosi> i'll try to make another layout-mockup now
[17:59] <bluesabre> sounds good
[18:07] <ochosi> humm
[18:08] <ochosi> i'm not very happy with how much space the infobar takes...
[18:08] <ochosi> i'd prefer something far more subtle
[18:08] <ochosi> at least by default
[18:09] <bluesabre> mock up something awesomer :D
[18:09] <ochosi> hehe
[18:09] <ochosi> yeah, banging my head against the wall currently
[18:09] <ochosi> as soon as i'm done with that, i'll mock it up :p
[18:10]  * davmor2 moves ochosi 's wall
[18:13] <ochosi> heh
[18:13] <ochosi> thanks davmor2 :)
[18:13] <ochosi> bluesabre: ok, baby steps then. some padding/arrangment tweaks: http://imagebin.org/213285
[18:14] <ochosi> btw, notice the "x" (close-button) in the search-bar. it should be there when $search!=''
[18:14] <ochosi> and ideally there would be a spinner instead of the "x" while the search is going on
[18:14] <ochosi> which would on hover show the "x" to cancel the search
[18:15] <ochosi> btw, "Esc" could be mapped to cancel the search by default _and_ to clear a finished search
[18:16] <bluesabre> sounds good
[18:32] <scott-work> thank you for the bug on xfce4-utils mr_pouit
[18:57] <ochosi> bluesabre: i think i finally have an idea how to implement the "find" in the UI
[18:57] <bluesabre> cool
[18:58] <bluesabre> btw, made some of the interface adjustments.  Not sure how I'm going to do the spinner in the entry box though
[19:01] <ochosi> bluesabre: http://imagebin.org/213292
[19:01] <ochosi> obviously the "search thorougly" is supposed to be a button :}
[19:01] <ochosi> didn't take the time to really draw it ;)
[19:02] <bluesabre> I like that
[19:02] <bluesabre> Care if I make the button look just like that?
[19:02] <bluesabre> lol
[19:02] <ochosi> haha
[19:02] <ochosi> please do that!
[19:05] <ochosi> if the spinner in the entry doesn't work, we can also put it in the statusbar
[19:05] <ochosi> cause while the search is running, there's nothing else there
[19:05] <ochosi> Unit193: tried searchmonkey now, it looks overly complicated (the UI) and it's not really faster or anything
[19:07] <Unit193> Right, it was just an idea, I personally use locate and try find every so often.
[19:08] <ochosi> Unit193: i think you might be able to use catfish in the future :)
[19:08] <ochosi> (in the near future)
[19:08] <knome> hurr durr
[19:09] <Unit193> I pulled from git, worked with the locate backend.
[19:09] <Unit193> s/git/bzr/
[19:10] <ochosi> yup
[19:12] <knome> bbl
[19:27] <ochosi> bluesabre: interface adjustments look good! btw, the dotted lines in the treeview, did you set those in the code?
[19:27] <ochosi> cause they don't look like proper murrine-engine dots, more like fallback-stuff
[19:28] <bluesabre> It's not murrine, is it?  pygi uses gtk3
[19:30] <ochosi> oh right
[19:30] <ochosi> i forgot :)
[19:30] <ochosi> (stupid me)
[19:30] <bluesabre> lol
[19:30] <ochosi> well still
[19:30] <bluesabre> but I agree.  Are those dots themeable?
[19:31] <bluesabre> or maybe we should port murrine to gtk3?  (not going to volunteer myself for that one)
[19:31] <ochosi> hmm, treeviews/listviews in greybird-gtk3 don't have the dots, but alternating row-colours
[19:31] <ochosi> well, in fact unico is a rewrite of murrine for gtk3
[19:31] <ochosi> it has similar functions
[19:31] <ochosi> it's just not as mature
[19:31] <ochosi> partly because gtk3 isn't as mature as gtk2
[19:32] <ochosi> (murrine and unico are written by the same author)
[19:32] <bluesabre> oh awesome
[19:33] <ochosi> so you added the dots?
[19:34] <ochosi> cause if yes i have to check whether i can theme them with unico (not entirely sure i can)
[19:34] <ochosi> but alternating row-colors would be nice
[19:34] <ochosi> they're in the theme, they work e.g. in the file-open dialog
[19:34] <bluesabre> yeah, it was an option for the treeview.  It should have the alternating rows now (does on mine)
[19:34] <ochosi> ok nice
[19:38] <bluesabre> ochosi: just pushed the latest interface changes
[19:40] <mr_pouit> ok, let's add a workaround for the non-expandable tasklist plugin from 4.10 :<
[19:44] <ochosi> mr_pouit: agreed
[19:45] <mr_pouit> that will be ugly, and may have funny side effects for people that changed the default config, but well
[19:46] <mr_pouit> (basically, if /plugins/plugin-2 is tasklist and /plugins/plugin-3 is separator, then we're in the xubuntu default layout and it sets /plugins/plugin-3 as expandable
[19:46] <ochosi> bluesabre: maybe add a tooltip to the close-button and make it clear the treeview as well
[19:46] <ochosi> mr_pouit: it's a problem only for people who used the ppa. and those are on their own anyway :}
[19:47] <mr_pouit> now if someone customised the layout enough to have plugin-2 as a tasklist in panel 0 and plugin-3 as a separator in panel 1, it will be affected as well
[19:47] <mr_pouit> no, that's on upgrades from 4.8 :[
[19:47] <bluesabre> ochosi: I'm not sure why we'd want to clear the treeview as well?
[19:48] <ochosi> bluesabre: hmm, right. i dunno, i kinda expected that, but i think you're right
[19:49] <ochosi> the changes look and work great btw
[19:50] <ochosi> do you wanna keep $searchterm in the statusbar?
[19:51] <ochosi> i mean there's one use-case i can think of, clearing the search-entry and then wanting to know what you searched for, but that's kinda odd and i'm not sure it's enough to keep a duplication
[19:51] <mr_pouit> did you talk with kalikiana about replacing catfish? (or will it live with another name)
[19:51] <ochosi> mr_pouit: right, i didn't read what you proposed properly. i'm not sure that this is the kind of workaround we want. it's a bit hacky and not exactly failproof
[19:52] <ochosi> mr_pouit: yes, he was looking for a new maintainer anyway
[19:52] <ochosi> mr_pouit: but we'll see, i think last time it didn't compile for hi
[19:52] <ochosi> m
[19:52] <ochosi> i'll talk to him 'bout it
[19:53] <bluesabre> yeah, he was having difficulties with it
[19:53] <bluesabre> btw, I fixed the annoying bugs with catfish in lubuntu as well, so they might be able to use it next time if we get this in
[19:53] <ochosi> ah right
[19:54] <ochosi> in that case superseding current catfish would be best
[19:54] <bluesabre> you wouldn't believe it, but pcmanfm does not take path arguments
[19:54] <bluesabre> silly
[19:54] <ochosi> pff
[19:54] <ochosi> i was never a big fan of pacmanfm tbh
[19:55]  * ochosi hopes jannis will pick up thunar-development again sometime soon
[20:00] <ochosi> k, i'm off for a bit
[20:00] <ochosi> prolly bbl though
[20:00] <ochosi> bluesabre: btw, you didn't add the delay yet, did you?
[20:01] <ochosi> anyway, just wondering, no rush :)
[20:02] <bluesabre> yeah, haven't added the delay yet, but reduced the number of attempts
[20:13] <bluesabre> ochosi: Just pushed the icon tooltips.  btw, have any feedback for the custom date and custom file format dialogs?
[20:26] <knome> bleh, hey people
[20:27] <bluesabre> hey knome
[20:27] <knome> hey bluesabre
[20:28]  * knome is *so* tired from being at places during the last days
[20:28] <knome> home office ftw
[20:30] <Unit193> knome: Howdy matie.
[20:30] <knome> hey Unit193! :)
[20:31]  * knome is starting to like his new terminal color-scheme a lot
[20:32] <micahg> mr_pouit: I think it's awesome that 4.10 is in and there are no new build failures
[20:32] <knome> http://temp.knome.fi/other/shot-201205-21.png <-
[20:42] <mr_pouit> micahg: yep \o/, the ppa helped though (there was only one failure with linelight-plugin, and it was noticed in my ppa)
[20:43] <mr_pouit> the "less nice" part is that plugins need to be updated to benefit from the new 'deskbar' mode introduced in xfce4-panel 4.10
[20:44] <bluesabre> how much updating?
[20:47] <mr_pouit> not that big, I think it's mostly on new callback
[20:47] <mr_pouit> *one
[20:52] <baizon> knome: irssi?
[20:53] <ochosi> knome: i dunno, the blues are too agressive for me
[20:53] <ochosi> bluesabre: will take a look tomorrow, gotta sleep now
[20:53] <ochosi> night everyone
[20:57] <Unit193> baizon: Yes that is.
[21:02] <knome> baizon, yes
[21:02] <knome> ochosi, nighty!
[21:02] <knome> ochosi, (not for me!)
[21:12] <micahg> knome: why did you remove xubuntu-dev from xubuntu-artwork, it contains the canonical branch for the ubuntu package and core-devs need to be able to commit
[21:16] <knome> micahg, hmph, isn't that a bit unclean? :|
[21:17] <knome> i can revert if that's needed. i thought it was only you and lionel who needed to access
[21:18] <knome> -dev is invited once again.
[21:18] <knome> sorry for the hassle!
[21:18]  * knome shouldn't work on FOSS when tired
[21:19] <knome> otoh, i think i found a bug in xfce bugzilla which is fixed
[21:19] <micahg> knome: well, core-devs shouldn't be touching it unless they need to fix an issue in the archive
[21:20] <knome> mmh, well anyway, it's reverted
[21:20] <micahg> thanks
[21:20] <knome> np
[21:21] <knome> btw, have you had a chance to look at the website/wiki "development" pages?
[21:21] <knome> we still refer to people having to apply as a MOTU
[21:21] <knome> i'd like to get those pages updated to be as correct as possible, and maybe we could attract a few people
[21:21] <knome> the rest of the "how to contribute" stuff is relatively current and correct now :)