[02:56] <bluzeo> hey guys- im going to be recording soon but i need a good game to record for my lets play- im thinking tux or another opensource game but cant decide
[02:57] <cfhowlett> bluzeo, your system, your choice.
[02:58] <bluzeo> i know but - there too many games that good that opensource
[03:00]  * ObrienDave takes aim at Google translate.


[06:03] <mborzecki> morning
[06:15] <tyhicks> zyga: hey - I just saw that you were debugging a dbus apparmor query bug
[06:15] <tyhicks> zyga: did you get to the bottom of it?
[06:16] <tyhicks> (I see the dc25979eb commit)
[06:21] <mup> Bug #1743504 opened: Ubuntu 16.04 snapd service not working <Snappy:New> <https://launchpad.net/bugs/1743504>
[07:41] <mup> PR snapd#4489 opened: vendor: remove x/sys/unix to fix builds on arm64 and powerpc <Created by mvo5> <https://github.com/snapcore/snapd/pull/4489>
[07:53] <mborzecki> mvo: morning
[07:56] <zyga> good morning
[07:57] <zyga> I'll get some coffee and will be back shortly :)
[07:57] <mborzecki> zyga: hey
[07:58] <mborzecki> have you guys seen this? https://forum.snapcraft.io/t/ubuntu-16-04-snapd-fail-to-start/3529
[07:58] <zyga> mborzecki: looking
[07:58] <mvo> hey mborzecki ! good morning
[07:58] <mvo> and good morning zyga
[07:59] <zyga> looks like #include maybe (vs include)
[07:59] <zyga> but not sure
[07:59] <zyga> mvo: hey!
[07:59] <zyga> -> coffee
[08:01] <mborzecki> zyga: apparmor thing?
[08:02] <zyga> yes, we delt with this in the past, that's the only thing that I can recall having an '#' issue
[08:02] <zyga> but
[08:02] <zyga> this is not a guarantee this is it
[08:02] <jdstrand> that error is talking about the '#' being a problem
[08:03] <jdstrand> the issue you were thinking of was a missing '#'
[08:03] <zyga> indeed
[08:03] <zyga> hey jdstrand :)
[08:03] <jdstrand> hey
[08:03] <zyga> I'm not used to you being in the same timezone
[08:03] <zyga> how was day one? :)
[08:03] <jdstrand> but regardless, snapd was not affected by the '#' or lack of '#', it was the apparmor python tools. I think this is unrelated to all that
[08:04] <jdstrand> day one went fine
[08:04] <zyga> ah, indeed, I think you are right
[08:04] <mvo> zyga, mborzecki doing a "grep -r" for the error message in vendor/ and /usr/share/go-1.8/src indicates its a json decode error, so probably corrupted state.json
[08:04] <mvo> mborzecki: (as you already guessed :)
[08:04] <jdstrand> no time to do any engineering really. lots of meetings, lots of interrupts when I thought I had time to do something
[08:04] <jdstrand> typical sprint :)
[08:06] <jdstrand> zyga: ftr, I have a slew of PRs scheduled for review. just need time to focus on them. they will be at the top of my list next week if I can't get to them this week (and I don't expect I can)
[08:06] <mborzecki> mvo: makes me wonder, unless hand edited, how would # end up in state.json?
[08:06] <zyga> jdstrand: ack
[08:07] <mvo> mborzecki: yeah, a good question, we would need the state.json to inspect, might be a bit flip, once you have enough users this will happen (we saw that with e.g. the dpkg/apt database frequently). or a corrupted hdd like zyga  had earlier. hard to say (or of course our fault somewhere in our state saving code)
[08:08] <mborzecki> it's not part of the pacakge right? so there's no chance of state.json getting updated as part of package upgrade?
[08:09] <zyga> jdstrand: how's the weather like?
[08:09] <jdstrand> zyga: beautiful
[08:09] <zyga> mborzecki: or if you remember my crazy hdd yesterday, may be the xml profile in place of json :)
[08:09] <zyga> mborzecki: on my disk the dpkg database contains random files
[08:09] <jdstrand> zyga: sounds like a fun day :)
[08:09] <mborzecki> zyga: yeah, that's possible too :/
[08:12] <kalikiana> sliff
[08:12] <pstolowski> good morning!
[08:12]  * kalikiana feeling a bit under the weather this not so good morning  :-(
[08:12] <mvo> mborzecki: correct
[08:12] <zyga> kalikiana: ouch
[08:13] <zyga> hey pstolowski
[08:13] <pstolowski> kalikiana, sad to hear that.. take it easy and get well!
[08:19] <zyga> mwhudson: snapd in debian is updating now
[08:19] <mvo> zyga, mborzecki, pstolowski quick question - what feels more natural to you: `snap run --strace-opts="-tt" hello` or `snap run --strace="-tt" hello` ?
[08:20] <zyga> mvo: the latter
[08:20] <pstolowski> mvo, the latter
[08:20] <mvo> (the former could also be written as `snap run --strace --strace-opts="-tt"  `
[08:20] <mvo> ok - cool, I look at it
[08:20] <mvo> thanks for your feedback
[08:20] <zyga> great, thanks for asking :)
[08:21] <zyga> snapd is now at 2.30-4 in sid :)
[08:21] <zyga> mwhudson: thank you for pushing that!
[08:21] <mborzecki> mvo: yup, the latter
[08:21] <mvo> mborzecki: ta!
[08:22] <mborzecki> mvo: btw. it'd also be a nice feature to be able to disable filtering out of pre snap-exec starce output
[08:23] <zyga> mvo: does the method to run strace scale to things like gdb?
[08:23] <mup> PR snapcraft#1869 closed: cli: exported login should only be readable by owner <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1869>
[08:23] <mvo> mborzecki: interessting idea
[08:23] <zyga> mvo: though gdb is also more complex because od symbols
[08:23] <pstolowski> and valgrind? ;)
[08:23] <zyga> hmm
[08:24] <zyga> I need to reboot my laptop
[08:24] <mvo> zyga: for gdb one would have to automatically set a breakpoint at "execve("the-snap-app")" and then run it
[08:24] <zyga> it goes crazy after suspend and all the textures blink
[08:24] <pstolowski> just kidding, valgrind is tricky for many reasons I suppose.. just gdb would be cool
[08:24] <zyga> brb
[08:29] <mup> PR snapd#4490 opened: tests/main/snap-service-after-before: add test for after/before service ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4490>
[08:30] <zyga> hmmm
[08:30] <zyga> I think I need to power it off
[08:30] <zyga> it's still wonky
[08:30] <zyga> and wifi is wonky  too
[08:30] <mborzecki> the year of linux desktop :P
[08:33]  * zyga looks for debian topics on the forum
[08:37] <mup> PR snapd#4491 opened: snap: allow options for --strace, e.g. `snap run --strace="-tt"` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4491>
[08:38] <mvo> kalikiana: hey, iirc you had some suggestion for `snap refresh --amend`, a better term. now is a good time to add them to 4356 as samuele also expressed that its not super clear to him
[08:40] <zyga> mvo: I didn't like amed too
[08:40] <zyga> mvo: I proposed one alternative on the forum but I forgot what it was
[08:43] <pedronis> mvo: I could think:  --reestablish  otherwise I thing we need more than one word with store in it somehow
[08:43] <pedronis> *I think
[08:44] <mvo> pedronis: I like --reestablish - feel free to add to the PR. I'm addressing your comments now fwiw
[08:45] <pedronis> mvo: and we have other plans for "replace"
[08:45] <pedronis> that might happen or not, but I don't think we want to use that
[08:46] <kalikiana> pedronis, mvo: I commented on the PR https://github.com/snapcore/snapd/pull/4356#discussion_r160633033
[08:46] <mup> PR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356>
[08:49]  * kalikiana getting more tea, with an extra slice of lemon
[08:51] <pedronis> mvo: put a rambling there about this
[08:51] <mvo> ta
[08:59] <zyga> snapd 2.30 on debian sid works well, spotify, gimp and brave tested
[09:00] <mvo> yay
[09:00] <mborzecki> mvo: will the strace PR will work with classic snaps too?
[09:02] <zyga> mborzecki: classic snaps don't need anything for strace
[09:02] <zyga> though it'd be nice if they also worked with the same U
[09:02] <zyga> \UI
[09:03] <mborzecki> what i meant if you do `snap run --starce <some-classic-snap>` will it work too?
[09:03] <zyga> right
[09:03] <zyga> I don't know :)
[09:04] <mvo> mborzecki, zyga: do we run snap-confine on classic snaps at all? iirc we do and if so strace should work
[09:09] <mwhudson> zyga: np, does it work? :)
[09:10] <zyga> mwhudson: yes
[09:10] <mwhudson> oh good
[09:10] <zyga> mwhudson: with apparmor enabled
[09:11] <zyga> so good work :-)
[09:11] <mborzecki> mvo: tried `snap run --strace` with a classic snap just now, works fine :)
[09:11] <mwhudson> i should send some of the changes your way
[09:11] <mvo> mborzecki: \o/
[09:11] <mwhudson> the "arch all only builds fail" thing would happen with ubuntu packaging too i'm fairly sure
[09:12] <mborzecki> mvo: https://paste.ubuntu.com/26396653/ the default value for --strace in --help is a bit confusing, i think you need to add `default-mask:""` or something similar
[09:19] <mvo> mborzecki: aha, good point. quirks with the go-flags
[09:19] <mvo> mborzecki: thanks, let me fix this
[09:21] <mvo> mborzecki: there is a failure in 4490 on 14.04 that looks vaguely ral
[09:21] <mvo> real
[09:25] <Chipaca> good morning peeps
[09:25] <mvo> Chipaca: hey, good morning!
[09:25] <Chipaca> just popping in to let you know (because I completely forgot yesterday)
[09:26] <mborzecki> mvo: thanks, looks like the formatting changed between systemd versions :/
[09:26] <Chipaca> that i've got two long parent meetings at the school today, so i've taken half a day off
[09:26] <mborzecki> Chipaca: morning
[09:26] <mvo> mborzecki: :(
[09:26] <zyga> hey there john!
[09:26] <Chipaca> so, hello and goodbye :-)
[09:26] <zyga> mborzecki: oh, "fun"
[09:26] <mvo> Chipaca: sure - when you have a moment 4489 is an easy win
[09:26] <zyga> how can projects do that :/
[09:26] <mvo> or someone else :)
[09:26] <Chipaca> mvo: ack
[09:27] <Chipaca> mvo: reach me on telegram if you need me though
[09:27] <mborzecki> zyga: systemctl --porcelain :)
[09:28] <zyga> mvo: did you see http://travis.debian.net/ ? :)
[09:29] <zyga> would be cool to have instructions like that for snapcraft
[09:30] <mvo> zyga: might cool
[09:31] <mvo> mborzecki: you mentioned you would be interested in havng "snap run --strace" not hide anything (so include the snap-confine traces). do you think a environment options is appropriate? or an extra option to `snap run --strace-it-all` or something?
[09:33] <mborzecki> mvo: enabling it via environment sounds good to me, SNAP_STRACE_EARLY=1 or something similar
[09:37] <mwhudson> zyga: what's the motivation for wanting to update snapd in stretch?
[09:38] <mwhudson> the version released with stretch re-execs i think...
[09:38] <zyga> mwhudson: yes, thought I don't know if that enables all the features
[09:38] <zyga> mwhudson: it would be a nice thing to update it
[09:38] <zyga> mwhudson: flapak gets the updates, for example
[09:38] <mwhudson> oh ok
[09:43] <mwhudson> zyga: looks like the newest flatpak is only in backports?
[09:43] <mwhudson> which would be an easier thing to do i guess
[09:45] <zyga> mwhudson: yes, that's a good thing IMO
[09:49] <mup> PR snapd#4492 opened: spread: try to enable Fedora once again <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4492>
[09:54] <zyga> mvo: can you please try to review https://github.com/snapcore/snapd/pull/4471  today?
[09:54] <mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
[10:07]  * zyga cannot stop laughing
[10:07] <zyga> https://twitter.com/Lilobase/status/952504781515509761
[10:09] <mup> PR snapd#4489 closed: vendor: remove x/sys/unix to fix builds on arm64 and powerpc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4489>
[10:11] <mup> PR snapd#4482 closed: cmd/libsnap-confine-private: add debug build of libsnap-confine-private.a, link it into snap-confine-debug <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4482>
[10:11] <mvo> mborzecki: 4483 has feedback - seems super close to handling
[10:11] <mvo> zyga: sure, going over the open PRs now
[10:12] <mborzecki> mvo: thanks for the reviews
[10:12] <zyga> thank you! :)
[10:16] <mvo> mborzecki: the failure in bboozzoo/snap-mgmt-extend-tests is very strange, could you please merge master and see if it persists? does not make much sense to me (spread failure in go unit tests on 14.04)
[10:19] <mborzecki> mvo: i'll be pushing more commits in a while and i'll merge master as well
[10:20] <mvo> mborzecki: ta
[10:33] <mborzecki> mvo: i'll have to open a follow-up pr anyway, for now i only merged master and pushed to #4480
[10:33] <mup> PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480>
[11:02] <pedronis> mvo: so far we implemented   Type=notify for snapd but no the watchdog stuff, right?
[11:20] <mborzecki> fedora currently fails with: 'No package golang(github.com/Thomasdezeeuw/ini) available.', any ideas?
[11:23] <zyga> that's a new dependency
[11:23] <zyga> we need to package it apparently
[11:27]  * kalikiana taking a break, not feeling awesome at all
[11:27] <Alexander_> Bumping into some problems with using iptables on ubuntu core. I have been trying to put in some dnat rules and they have not be working at all. Tcpdump is showing the packets going to the host machine. Any thoughts?
[11:28] <zyga> Alexander_: hmm, are the right modules loaded?
[11:28] <mborzecki> from a quick survey, github.com/go-ini/ini seems to be avialble in fedora/ubuntu/debian
[11:29] <mborzecki> and this one too github.com/vaughan0/go-ini
[11:30] <Alexander_> zyga: I do not know, I have just been call iptables from command line in normal userspace and the "classic" space. How could I find out?
[11:30] <zyga> Alexander_: lsmod may tell you that
[11:31] <zyga> mborzecki: maybe it's just a missing dep then, low hanging fruit to add
[11:31] <mborzecki> zyga: you mean replace github.com/Thomasdezeeuw/ini with one of the 2 i listed above?
[11:32] <zyga> mborzecki: ah
[11:32] <zyga> sorry I misread
[11:32] <zyga> I think go-ini is the one that pedronis was unhappy about
[11:33] <zyga> but if that's not the case and we could use that then yes, that's a quick win
[11:36] <Alexander_> $ lsmod | grep ip
[11:36] <Alexander_>  gives me
[11:36] <Alexander_> iptable_filter  ip_tables ip6table_filter ip6_tables x_tables
[11:37] <Alexander_> I assume ip_tables is the support for iptables?
[11:38] <pedronis> zyga: mborzecki: mvo proposed to use our old goconfigparser, that should have been packaged already too
[11:39] <mborzecki> pedronis: is it in the tree now?
[11:39] <pedronis> mborzecki: no, it's on github though
[11:40] <pedronis> probably best to wait for mvo to decide what to do
[11:40] <mborzecki> ok
[11:44] <zyga> hmm
[11:44] <zyga> I'm learning more aboud dbus the hard wy
[11:44] <zyga> way*
[11:45] <mvo> pedronis, zyga either way is fine with me, if we decide on the old parser I'm happy to look into the porting
[11:45] <pedronis> mvo: I think I would prefer the old parser  over go-ini
[11:46] <mvo> pedronis: works for me, I will look into the porting (unless you want to do it)
[11:46] <ikey> dbus is the debil
[11:46] <zyga> ikey: debil?
[11:46] <ikey> devil.
[11:46] <zyga> ah :D
[11:46] <zyga> in polish debil has another meaning and I was now wondering if that's an english word as well
[11:46] <ikey> ah ok
[11:46] <ikey> waterboy reference :P
[11:47] <zyga> https://translate.google.com/#pl/en/debil ;-)
[11:47] <ikey> hah nice
[11:47] <ikey> that works too
[11:49] <mvo> pedronis: heh, fun! goconfigparser is even part of the vendoring still as we use it in one of our tests
[11:50] <pedronis> mvo: yes, I see
[11:52] <mvo> pedronis: fwiw, I addressed the points in 4356
[11:55] <mborzecki> don't remember the details of fedora policy on go packages, but if it's under vendor then there musn't there be a real package with that dep too?
[11:56] <zyga> mborzecki: it depends on where it is, it needs to be marked as an embedded package, in some places it's embedded (centos) and in some places it's not (fedora)
[11:56] <zyga> mborzecki: that's what I remember, I'm sure Pharaoh_Atem can correct me if I'm wrong
[12:04] <mborzecki> zyga: i think https://github.com/snapcore/snapd/blob/master/dirs/dirs.go#L234 is causing https://bugs.launchpad.net/snappy/+bug/1743301 korora is derived from fedora and apaprently it's picking the wrong libexedir
[12:04] <mup> Bug #1743301: cannot install apps using snap on Korora <Snappy:New> <https://launchpad.net/bugs/1743301>
[12:04] <mvo> pedronis: I pushed a PR and have lunch now. wonder if I should add more unit tests for the error cases? or do you think its sufficient?
[12:04] <mup> PR snapd#4493 opened: image: port ini handling to goconfigparser <Created by mvo5> <https://github.com/snapcore/snapd/pull/4493>
[12:05] <mborzecki> zyga: we should do release.DistroLike() probably
[12:05] <mborzecki> zyga: do you know what os-relase looks like on rhel and cetos?
[12:08] <pedronis> mvo: I think the error handling is easy enough to follow
[12:08] <pedronis> mvo: pushed couple of comments
[12:08] <zyga> mborzecki: looking
[12:08] <zyga> mborzecki: yep
[12:09] <zyga> mborzecki: sure
[12:09] <zyga> mborzecki: one sec...
[12:09] <zyga> https://github.com/zyga/os-release-zoo/blob/master/redhat/rhel7.txt
[12:09] <zyga> https://github.com/zyga/os-release-zoo/blob/master/centos/centos-7.txt
[12:09] <zyga> :-)
[12:09] <zyga> enjoy! and add anything you find missing please
[12:09] <mborzecki> zyga: hah, thanks
[12:09]  * zyga still fights dbus
[12:10] <mborzecki> zyga: url open thing?
[12:11] <zyga> mborzecki: hmm?
[12:11] <zyga> mborzecki: ah, yes
[12:11] <zyga> but in reality dbus bug
[12:11] <mborzecki> interesting, does it warrant a blog post? :)
[12:11] <zyga> mborzecki: ha, I can write about that though it's pretty obscure and I haven't fixed it yet
[12:13]  * pstolowski lunch
[12:18] <zyga> hey there neal!
[12:27] <mborzecki> zyga: https://github.com/zyga/os-release-zoo/pull/26
[12:27] <mup> PR zyga/os-release-zoo#26: korora: add Korora 26 <Created by bboozzoo> <https://github.com/zyga/os-release-zoo/pull/26>
[12:28] <zyga> merged
[12:28] <zyga> thank you
[12:29] <zyga> man
[12:29] <zyga> building dbus sucks, it's hediously complex
[12:29] <zyga> I ended up rebuilding the package
[12:30] <zyga> I have no idea how things get configured apart from 'by magic' there
[12:52] <mup> PR snapd#4494 opened: dirs: check if distro 'is like' fedora when picking path to libexecdir <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4494>
[12:58]  * Chipaca is back but really exhausted from the meetings
[13:01] <zyga> joining
[13:01] <niemeyer> Speaking of which, I won't join you today
[13:04] <zyga> niemeyer: thanks for the heads up!
[13:07] <ondra> ogra ping
[13:07] <ogra> ondra, yo
[13:20] <mup> PR snapd#4307 closed: tests: fix "job canceled" issue and improve cleanup for snaps <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4307>
[13:27] <zyga> pstolowski: sudo snap debug get-base-declaration
[13:27] <pstolowski> zyga, thanks!
[13:29]  * Chipaca hugs niemeyer
[13:31] <pedronis> pstolowski: do you have a pointer to a place where we iterate of attrs (not constraints)
[13:31] <pstolowski> pedronis, 1 sec
[13:32] <JonelethIrenicus> what do I have multiple snappy cores?
[13:33] <Chipaca> JonelethIrenicus: pardon?
[13:34] <JonelethIrenicus> if I open up something like firelight I see mutliple snappy core "disks"
[13:35] <JonelethIrenicus> old versions
[13:35] <JonelethIrenicus> /snap/core/3604
[13:35] <JonelethIrenicus> /snap/core/3748
[13:35] <JonelethIrenicus> etc..
[13:36] <ogra> for rollback
[13:36] <mup> PR snapcraft#1873 opened: elf: cleaner patchelf experience <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1873>
[13:36] <zyga> JonelethIrenicus: those are multiple revisions of one snap
[13:36] <zyga> JonelethIrenicus: snapd maintains up to three revisions per snap
[13:36] <zyga> JonelethIrenicus: they get recycled automatically
[13:36] <ogra> on classic you always need to have two ... on ubuntu-core you need three (two for rollback, one for factory reset)
[13:37] <JonelethIrenicus> i see
[13:37] <ogra> (i think snapd doesnt make any difference between core and classic on that level currently, so you will end up with three on classic too ... )
[13:39] <mvo> pedronis: I updated the ini pr and addressed your feedback (thanks again for this)
[13:40] <Chipaca> JonelethIrenicus: you can remove them if you need to via "snap remove --revision=<rev#> <snapname>"
[13:40] <JonelethIrenicus> Chipaca: good tip thanks
[13:40] <Chipaca> JonelethIrenicus: if you try to remove the current one it'll tell you to behave :-)
[13:41] <JonelethIrenicus> haha well that is never going to happen
[13:41] <pedronis> mvo: looks good, you miss a bundled(...) in one of those packaging lines though
[13:42] <mvo> pedronis: uh, thanks. silly copy/paste
[13:42] <pstolowski> pedronis, hmm I think I was wrong and confused the loop over constraints with looping over attributes
[13:43] <mborzecki> does snapcraft need to know about after/before properties in apps now that the systemd after/before ordering is merged?
[13:44] <pedronis> pstolowski: I suppose better this way, but that's what I wondered, because I don't remember code like that (but it was a long time ago)
[13:46] <pstolowski> pedronis, yes, that solves half of the problems
[13:46] <zyga> lunch is soon, let's do one more test
[13:49] <mvo> mborzecki: one question about 4494> did you check that rhel and centos have a DISTRO_LIKE=fedora ? i.e. that we won't regress on those?
[13:49] <mup> PR snapd#4494 closed: dirs: check if distro 'is like' fedora when picking path to libexecdir <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4494>
[13:50] <mborzecki> mvo: i checked in zyga's os-release-zoo https://github.com/zyga/os-release-zoo/blob/master/redhat/rhel7.txt https://github.com/zyga/os-release-zoo/blob/master/centos/centos-7.txt
[13:50] <mvo> mborzecki: neat, thanks
[13:50] <Chipaca> mborzecki: that project takes patches (e.g. korororora?)
[13:51] <mborzecki> sounds kiwi'sh
[13:53] <Chipaca> my dad skills have spilled into the forum! first time i've used "you (plural)" like that that i know of :-D
[13:53] <Chipaca> anyhoo, work calls
[13:54] <mborzecki> since korora is basically fedora, I wonder if Son_Goku could cherry-pick the patch when updating the package to 2.30
[13:54] <Son_Goku> mborzecki: which patch do I need to cherry pick?
[13:54] <mborzecki> Son_Goku: https://github.com/snapcore/snapd/pull/4494
[13:54] <mup> PR #4494: dirs: check if distro 'is like' fedora when picking path to libexecdir <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4494>
[13:54] <Son_Goku> mvo: I thought I had gotten all of these things when I attempted to fix this for Korora last time?
[13:55] <Son_Goku> I swear I did...
[13:56] <Son_Goku> oh, geez
[13:56] <Son_Goku> there was another check for libexecdir
[13:56] <mvo> Son_Goku: :/ well, I guess we now have them all!
[13:56] <Son_Goku> are we really sure this time?
[13:56] <Son_Goku> now even I'm not sure...
[13:57] <Son_Goku> mborzecki: but yeah, I'll be cherry-picking this
[13:58] <mborzecki> Son_Goku: great, thanks
[13:58] <Son_Goku> mvo, could you just make sure the PR is cherry picked into the 2.30 branch?
[13:58] <Son_Goku> it makes it easier for me to keep track of these things
[13:59] <mvo> Son_Goku: sure
[14:01] <mvo> Son_Goku: its in release/2.30 now
[14:01] <Son_Goku> thanks
[14:01] <Son_Goku> I'm going to be preparing the backport later today
[14:01] <Son_Goku> err, upgrade
[14:05] <mborzecki> mvo: since you're cherry picking to 2.30, can you also pick https://github.com/snapcore/snapd/pull/4432 ? Son_Goku left a note there, but I don't see it in release/2.30
[14:05] <mup> PR #4432: cmd/snap,  tests/main/classic-confinement: fix snap-exec path when running under classic confinement <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4432>
[14:05] <mvo> mborzecki: sure, looking
[14:06] <mvo> mborzecki: done
[14:06] <mborzecki> mvo: thanks
[14:06] <Son_Goku> mvo: I just want to avoid being forced to have my own source maint tree
[14:07] <Son_Goku> because in my opinion, such things are counterproductive with ensuring fixes are upstream
[14:07] <Son_Goku> (it's one of the reasons I dislike the Debian/Ubuntu model of packaging with gbp trees)
[14:08] <Son_Goku> today, there's exactly ONE downstream patch that's not upstream
[14:08] <mvo> Son_Goku: +1
[14:08] <mvo> Son_Goku: ping me anytime if you need something cherry-picked
[14:08] <Son_Goku> cool, thanks
[14:08] <mvo> zyga: 4483 needs a second review, iirc you looked at this before so should be trivial
[14:09] <Son_Goku> God knows, I could actually do my own source trees for packaging, but I hate that stuff
[14:09] <Son_Goku> it's far too easy to get lazy and complacent
[14:09] <mvo> Son_Goku: plus the collaborating with upstream is usually very healthy
[14:09] <Son_Goku> yeah
[14:10] <mvo> (and great for upstream because they understand the needs of the packages better etc etc)
[14:10] <Son_Goku> I think what really burned me was my experience with Debian as an upstream software developer
[14:10] <Son_Goku> one of my software packages was effectively forked and they never bothered to talk to me
[14:10] <Son_Goku> meanwhile I was listed as a contact point in the copyright, so I got weird questions from people using the Debian version
[14:11] <mvo> Son_Goku: uh, that sucks - may I ask what the package name was?
[14:11] <Son_Goku> lugaru / openlugaru
[14:11] <Son_Goku> they'd also converted the source tree from Mercurial (as it was at the time) to Git
[14:11] <Son_Goku> which meant it was painful to figure out where they actually were
[14:12] <mvo> Son_Goku: uh, I see, that sounds painful
[14:12] <Son_Goku> needless to say, it annoyed me
[14:12] <mvo> Son_Goku: *nod*
[14:13] <Son_Goku> when development of lugaru restarted, I switched to Git (as everyone else wanted it), and did significant work
[14:13] <mvo> Son_Goku: I hope it got better over time
[14:13] <Son_Goku> unfortunately, their little weird tree meant that they spent a year arguing about how to refork the source tree into Alioth for packaging
[14:14] <Son_Goku> Debian was *the last* distribution to get the new Lugaru, and they missed the first release
[14:14] <Son_Goku> I wish it wasn't common practice to fork source trees for packaging in Debian, because it seems to lead to people cheaply patching things without talking to upstream
[14:15] <Son_Goku> the upstream project (that is me and a couple of others) requested that they didn't fork the tree again, and we were told to butt out :(
[14:16] <Son_Goku> it's not like I don't understand how to handle the upstream/downstream relationship
[14:16] <Son_Goku> but that was cold :/
[14:16] <mvo> Son_Goku: :(
[14:16] <mvo> Son_Goku: sorry to hear this bad experience
[14:16] <Son_Goku> yeah, well, I've made a point now to avoid what I call merged source trees for packaging
[14:16] <Son_Goku> I don't want to inflict that kind of mess onto someone else
[14:17] <Son_Goku> mvo: that said, it's not like I don't understand why debian is evolving towards that form of packaging
[14:18] <Son_Goku> debian source control is designed to be integrated with source trees, always has and always will
[14:18] <Son_Goku> it's even in the name ;)
[14:19] <Son_Goku> but it's one of the reasons I prefer the way RPMs are packaged, because it solidifies that split
[14:19] <mborzecki> off to pick up the kids
[14:19] <Son_Goku> most packaging formats impose that split (RPM Spec, Arch PKGBUILD, Solus ypkg, etc.)
[14:19] <Son_Goku> and personally, I think it's a very good thing
[14:27] <mvo> Son_Goku: right, well, there is a concept of orig.tar.gz in the deb sources as well. but yeah, its easy to fork
[14:28] <mvo> zyga: I looked at 4471 and it seems there is some good feedback already so I am happy to have another look once this feedback is addressed
[14:29] <Son_Goku> mvo, which reminds me, why aren't you just using the deb sources multi-tarball thing to deal with bundling squashfuse?
[14:30] <Son_Goku> the go hack is kind of garbage, tbh, and I don't think it's worth risking making it a permanent part of snapd
[14:30] <Son_Goku> it really only needs to exist for 16.04, as 18.04 could just have squashfuse declared as a proper dependency (since dist-upgrade is used for that process)
[14:31] <zyga> mvo: thanks!
[14:32] <zyga> mvo: looking at the earlier one as well
[14:32] <mvo> Son_Goku: I need to look into this, it will make the packaging slightly more complicated, but might be worth checking. I kind of like the facts that its inside vendor/ as this is the place where we put stuff we "vendor" :) the fact that its a bit hacky around that makes me slightly sad, I need to explore if the other options are better
[14:33] <Son_Goku> mvo: well my thought is that "snapfuse" is a workaround for an apt deficiency
[14:33] <Son_Goku> the proper thing to do is depend on squashfuse
[14:33] <mvo> it is
[14:34] <Son_Goku> again, I want to avoid the risk of "snapfuse" being a mandatory dep
[14:34] <Son_Goku> in Fedora, I just introduced squashfuse as a dependency and we were good to go
[14:45] <tedg> cjwatson: sergiusens: Good morning, I have Inkscape master building in a "snapcraft cleanbuild" well, but it fails on the builders in a weird way. https://code.launchpad.net/~ted/+snap/inkscape-master
[14:45] <tedg> I'm not sure what could be different between the two (at all), but much less that could cause something like this.
[14:45] <tedg> Or frankly, what the error really is there.
[14:48] <mup> PR snapd#4495 opened: data/dbus: add AssumedAppArmorLabel=unconfined t <Created by mvo5> <https://github.com/snapcore/snapd/pull/4495>
[14:57] <cjwatson> tedg: maybe cleanbuild uses a slightly different sources.list by default?
[14:59] <tedg> cjwatson: Yeah, I did have to add software-proprties-common as add-apt-repository wasn't on the builders but was in cleanbuild. So there are certainly some slight differences.
[15:03] <cjwatson> right, that's a difference in the default installed package set which is slightly different although conceivably also relevant
[15:06] <cjwatson> tedg: my first guess would definitely be that it's something broken in ppa:ubuntu-desktop/ubuntu/gnome-3-26, although I don't know why you wouldn't see that in cleanbuild
[15:08] <tedg> Hmm, and kenvandine is suspiciously not here :-)
[15:08] <mvo> pedronis: did you notice that master is currently failing? it looks like it cannot install test-snapd-private
[15:08] <tedg> seb128: Do you know about the gnome-3-26 backport PPA?
[15:08] <seb128> tedg, what about it?
[15:09] <tedg> seb128: My snap is failing to build with it, cjwatson thinks that it may be an issue with a package there. (I'm not sure what's up personally)
[15:11] <seb128> tedg, Ken did recent uploads there, I guess it's not impossible that he screwed
[15:11] <seb128> if your issue is in the gtkmm stack
[15:12] <seb128> we didn't do recent builds afaik so I'm unsure if the ppa got tested since those uploads
[15:12] <cjwatson> aha, reproduced, ish
[15:12] <tedg> Yeah, and he added that at my request as it was needed to get Inkscape building.
[15:13] <seb128> so you blame him but it's your fault :p
[15:13] <tedg> (well, building with the new GTK)
[15:13] <cjwatson> tedg: https://paste.ubuntu.com/26398323/
[15:13] <tedg> Haha
[15:14]  * cjwatson adds a few more packages to drill down
[15:14] <pedronis> mvo: no
[15:14] <mvo> pedronis: aha, nevermind
[15:14] <cjwatson> https://paste.ubuntu.com/26398330/
[15:14] <mvo> pedronis: I think its just a change error message, I will fix it
[15:15] <mvo> pedronis: strange that we did not see it in PRs
[15:15] <cjwatson> so the basic problem is a conflict somewhere in that set
[15:15] <pedronis> mvo: ah
[15:16] <cjwatson> libgdk-pixbuf2.0-dev Depends: libpng-dev
[15:16] <mvo> pedronis: aha, of course, we only run this test against main, right? I think you told me a while ago
[15:16] <tedg> Hmm, so perhaps I need to explicitly remove the older libpng?
[15:16] <seb128> cjwatson, tedg, Ken is back tomorrow if he needs to fix something
[15:17] <pedronis> mvo: yes,  that's because of travis security rules, secrets are set only for main repo branches
[15:17] <pedronis> not PRs
[15:18] <cjwatson> tedg: dropping libpng12-dev and adding gtk-update-icon-cache (I'm not sure why ...) seems to work at least in my reduced test case
[15:19] <mup> PR snapd#4496 opened:  tests: update auto-refresh-private to match messages from current master <Created by mvo5> <https://github.com/snapcore/snapd/pull/4496>
[15:19] <mvo> pedronis: indeed, PR on the way
[15:19] <tedg> cjwatson: Thanks, I'll give those a try! (it'll take a while to get test builds done)
[15:33] <elopio> hey kyrofa, should I make a PR to try one of the desktop solutions so we can discuss there?
[15:33] <mup> PR snapcraft#1874 opened: kbuild: pick up CROSS_COMPILE only if it's not empty <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1874>
[15:35] <pstolowski> hey tedg, howdy!
[15:35] <tedg> Howdy pstolowski !
[15:36] <diddledan> what's the mechanism for including my own plugin to build my project? I have written the pyhton script but can't get snapcraft to recognise it
[15:36] <diddledan> (I modified the PythonPlugin and saved it to ./snap/plugins/foo.py)
[15:39] <kyrofa> diddledan, try naming it x-foo.py
[15:39] <kyrofa> Or maybe x_foo.py... now I can't remember :P
[15:40] <kyrofa> Probably the latter
[15:40] <diddledan> doesn't make a difference
[15:40] <kyrofa> diddledan, what name are you using in the YAML?
[15:41] <diddledan> oh, wait, that made it work, but doesn't list it in `snapcraft plugins`
[15:43] <kyrofa> diddledan, no, those are just the built-in plugins
[15:50] <kyrofa> elopio, we can chat a little in the meeting if you like
[15:50] <elopio> sure
[16:01] <Pharaoh_Atem> mborzecki: new deps need to be packaged for fedora
[16:02] <Pharaoh_Atem> but for epel7, bundling is allowed
[16:02] <Pharaoh_Atem> that's the only reason there's a bundled mode
[16:02] <Pharaoh_Atem> (in re fedora packaging)
[16:07] <mvo> Pharaoh_Atem: for 2.31 we have a new boltdb dep, but this might be packaged already for fedora, its quite popular aiui
[16:17] <pedronis> mvo: do you know what core-snap-refresh  (but it checks boot envs)  vs core-snap-refresh-on-core are about?  I expected the first to have bits only about classic
[16:17] <pedronis> they are manual
[16:21] <mvo> pedronis: let me look, they are confusing
[16:23] <mvo> pedronis: core-snap-refresh-on-core is about refresh and revert working, it is also the newer one of the two and should be used in spread-cron (I need to double check this though)
[16:25] <mvo> pedronis: the other one looks like we should simplify it, i.e. just test that a new core snap survies refreshes and we can ignore core devices for this test because we already test that in the other test
[16:25] <pedronis> mvo: so make it classic only , and remove the bits about boot envs ?
[16:26] <mvo> pedronis: that would be my suggestion
[16:26] <pedronis> ok
[16:27] <mvo> pedronis: yeah, I think that is sufficient. we may need to add a loop to wait until snapd is active in `snap changes` though, I think as it is currently written it is racy
[16:27] <mvo> pedronis: i.e. after the reboot we may call `snap changes` before snapd has started (but then we have some wait-time for snap to wait for the socket so maybe not an issue)
[16:28] <pedronis> we do that in other places
[16:28] <pedronis> I haven't seen (yet) issues with that
[16:28] <mvo> pedronis: even better, then lets ignore it
[16:30] <mup> PR snapd#4497 opened: many: make rebooting of core on refresh immediate, refactor logic around it <Created by pedronis> <https://github.com/snapcore/snapd/pull/4497>
[16:33] <pedronis> mvo: I proposed this  ^    though spread tests need a bit more work (for example those two), also there may be different approaches/policies
[16:43] <mvo> pedronis: cool, I have a look in a bit (fighting with seccomp just now)
[16:44] <mup> PR snapd#4496 closed:  tests: update auto-refresh-private to match messages from current master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4496>
[16:55] <pedronis> mvo: thx, is not super urgent but wanted to push it before leaving,  it's been a todo since long, can wait after I'm back for sure to land
[16:56] <mvo> pedronis: ok, thank you
[16:57] <mvo> zyga-ubuntu: hey, welcome back - does https://travis-ci.org/snapcore/snapd/builds/329513349#L1950 make any sense to you?
[16:58] <zyga-ubuntu> mvo: hey
[16:58] <zyga-ubuntu> mvo: sorry, some stuff at home
[16:58] <mvo> zyga-ubuntu: in my strace PR there is a failure in the snap-update-ns test
[16:58] <zyga-ubuntu> mvo: I'm not back for real yet
[16:58] <zyga-ubuntu> mvo: great insight on your PR
[16:58] <zyga-ubuntu> (on the older one with dbus)
[16:58] <mvo> zyga-ubuntu: that looks like it is happening consistently but it does not make sense to me
[16:58] <mvo> zyga-ubuntu: aha, no worries
[16:58] <mvo> zyga-ubuntu: well, that PR is yours really, you figured it all out :)
[16:58]  * mvo hugs zyga-ubuntu
[16:58] <zyga-ubuntu> looking
[17:00] <zyga-ubuntu> mvo: that strace branch is interesting
[17:01] <mvo> zyga-ubuntu: the fun part is that #4473 (which contain most of it) is green
[17:01] <mup> PR #4473: snap: add `snap run --strace` to be able to strace snap apps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4473>
[17:01] <zyga-ubuntu> that's .... unexpected
[17:06] <zyga-ubuntu> mvo: as for the dbus problem I think there is a real bug in dbus now but I your patch works around it (and is not incorrect)
[17:07] <zyga-ubuntu> mvo: and will save me exploring that (which is painful becauese iteration is annoyingly slow)
[17:08] <zyga-ubuntu> mvo: I'm still trying to grok the strace bug, does it happen in interactive debug as well?
[17:09] <mvo> zyga-ubuntu: I have not tried that yet
[17:09] <mvo> zyga-ubuntu: we can talk about it tomorrow, its just puzzling and maybe things get clearer if my initial strace PR is merged
[17:10] <mvo> (as the diff will get smallre)
[17:10] <mvo> smaller
[17:10] <zyga-ubuntu> mvo: ok, that sounds good to me
[17:11] <zyga-ubuntu> mvo: I will be back in 15 minutes, just some constant interrupts at home now
[17:19] <zyga-ubuntu> mvo: nothing in that PR screams at me 'here'
[17:19] <zyga-ubuntu> mvo: unless there's a typo that makes strace go where it shouldnt
[17:49] <zyga-ubu1tu> re for good
[18:12] <pedronis> did travis change their timeout?
[18:13] <pedronis> there's a run that is finished after 1h+
[18:13] <pedronis> *is not finished
[18:27] <boopy> how do you update snap and how do you recover from this?
[18:27] <boopy> > snap "ubuntu-core" has changes in progress
[18:28] <cachio> niemeyer, when you have a free slot, could you please take a look to the PR #49 for spread
[18:28] <mup> PR #49: allow (optional) snappy update $pkgname <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/49>
[18:40] <mup> PR snapd#4418 closed: tests: enabling opensuse for tests <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4418>
[18:45] <mup> PR snapd#4490 closed: tests/main/snap-service-after-before: add test for after/before service ordering <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4490>
[18:57] <Pharaoh_Atem> mvo: it looks like we're not testing against Fedora in snapd CI
[18:57] <Pharaoh_Atem> what happened here?
[19:13] <mvo> Pharaoh_Atem: there were a bunch of issues with the fedora repos, there is a PR to enable fedora again iirc
[19:13] <mup> PR snapcraft#1875 opened: Remove deprecated 'snap' recommendation <Created by ted-gould> <https://github.com/snapcore/snapcraft/pull/1875>
[19:13] <Pharaoh_Atem> mvo: that means I probably have idea if the deps for master are satisfiable
[19:13] <Pharaoh_Atem> have no idea, I mean
[19:14] <mvo> Pharaoh_Atem: yeah, we are unhappy about this too: https://github.com/snapcore/snapd/pull/4492
[19:14] <mup> PR #4492: spread: try to enable Fedora once more <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4492>
[19:15] <mvo> Pharaoh_Atem: actually, this one fails because of a new dep, there is a fix already for this
[19:15] <mvo> (in 4493)
[19:16] <niemeyer> cachio: Will do
[19:21] <cachio> niemeyer, tx
[20:30] <robert_ancell> Snap packages are installed in a queue right? Does anyone know if there's a plan to be able to install in parallel?
[20:32] <nacc> robert_ancell: LP: #1585403 ?
[20:32] <mup> Bug #1585403: please support parallel operation <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1585403>
[20:36] <robert_ancell> nacc, thanks!
[20:36] <pedronis> robert_ancell:  there is no queue,  some single things are serialized
[20:36] <nacc> robert_ancell: np
[20:37] <robert_ancell> pedronis, so can a second install start before the first one is complete currently?
[20:37] <pedronis> yes,   at least  if core is already there
[20:37] <robert_ancell> pedronis, ok, thanks!
[20:37] <pedronis> if they need core they will wait on that
[20:37] <robert_ancell> I'm asking because there's a discussion in GNOME Software about parallel vs. queued installation and I'm giving the snap datapoint.
[20:40] <pedronis> as I said, there's no queue in snapd, there are conflict checks between ops (usually at the level of each single snap), and some internal ops (like changes to security) are serialized, but overall install can be started in parallel
[20:40] <pedronis> and most of it will proceed in parallel
[20:41] <robert_ancell> e.g. downloading?
[20:41] <pedronis> right
[20:41] <nacc> pedronis: does that imply the above bug should be closed?
[20:42] <pedronis> yes, except I have no idea why my colleagues didn't close it, what they were thinking
[20:42] <pedronis> with their answers
[20:43] <niemeyer> I think it can be closed
[20:44] <niemeyer> snapd indeed operates closer to make -j than it does to apt or deb in that regard
[20:44] <niemeyer> Those really serialize all steps of the installation, while snapd goes wild and only rejects known conflicts as you pointed out pedronis
[20:46] <niemeyer> make -j also doesn't parallelize _everything_ either.. just the things it knows are independent.. so vaguely resembling snapd's behavior indeed
[20:47] <nacc> pedronis: niemeyer: sounds good, thanks
[20:48] <niemeyer> It's quite awkward to say "Fix Released" for something that was always like that.. and curious that there's no better option.
[20:48] <niemeyer> nacc: np
[20:48] <nacc> niemeyer: yeah, you can change the state of the bug to Invalid, if that's actually the case
[20:48] <nacc> (IMO)
[20:48] <nacc> roughly like NOTABUG in bugzillas
[20:49] <robert_ancell> niemeyer, yeah, it always feels weird doing a Fix Released like that.
[20:49] <nacc> niemeyer: but yeah, the states aren't quite what i expect, ever :)
[20:49] <niemeyer> nacc: Invalid also feels wrong.. it's not invalid.. it's a valid feature request, and it's implemented, and always was. :)
[20:49] <robert_ancell> The other option is invalid, but that seems a bit harsh if it was a valid request at the time.
[20:50] <nacc> niemeyer: yeah, but it soudns like it was't a valid feature request then either?
[20:50] <niemeyer> Yeah, it's more like "Yay!"
[20:50] <niemeyer> :)
[20:50] <nacc> dunno, it's a lose-lose :)
[20:50] <nacc> a good comment and whatever terminal state you want :)
[20:50] <niemeyer> nacc: yeah details.. from a human perspective, a person asked for a behavior, and it's already in place.. it's not "Okay I did it", and it's not "That's wrong" either
[20:51] <nacc> niemeyer: yep, agreed
[20:51] <niemeyer> GitHub gets that right.. it's just Closed
[20:51] <nacc> right
[20:51] <nacc> the graph for LP doesn't match my brain often
[20:52] <niemeyer> I'd suspect it inherited from Bugzilla, but it's been such a long time that I can't even remember..
[20:52] <niemeyer> Anyway.. it's closed. :)
[20:55] <robert_ancell> Is there any online documentation on the policy for snapd updating snaps? They're always automatically updated on a schedule, right?
[20:56] <robert_ancell> And you can manually update them at any time.
[20:57] <robert_ancell> This seems to be the closest I can find: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/4
[21:10] <mup> Issue snapcraft#1876 opened: Cleanbuild doesn't work with SSH based Git repos <Created by ted-gould> <https://github.com/snapcore/snapcraft/issue/1876>
[21:11] <niemeyer> robert_ancell: Right, that's it
[21:11] <niemeyer> robert_ancell: The default schedule right now is 4 times within the day
[21:12] <niemeyer> robert_ancell: At random times
[21:12] <niemeyer> That is, once every 6h window
[21:13] <niemeyer> robert_ancell: We have improvements landing right now (just reviewed a PR on that, actually) that introduce monthly support in the scheduling
[21:13] <robert_ancell> niemeyer, nice
[21:13] <niemeyer> So people will be able to pick a specific day within the month
[21:13] <niemeyer> The syntax is documented in ...
[21:14] <niemeyer> https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239
[21:14] <niemeyer> and the options for core in general are documented in ...
[21:14] <niemeyer> https://forum.snapcraft.io/t/configuration-options-for-core-snap/87
[21:14] <niemeyer> The latter was not yet updated with the former because it's not yet publicly available
[21:14] <robert_ancell> I feel like we need a snapd section (perhaps a different name) in https://docs.snapcraft.io/ as that seems to cover the snap format and snapcraft
[21:15] <niemeyer> robert_ancell: I would prefer to just drop these pages there and make them point to our forum, which is easier to keep up to date and more visible
[21:15] <niemeyer> For example, the format is documented at
[21:15] <robert_ancell> niemeyer, that would work for me
[21:15] <niemeyer> https://forum.snapcraft.io/t/the-snap-format/698
[21:16] <niemeyer> And we have similar pages for each of the fundamnetal snaps (gadget, kernel, etc)
[21:20] <niemeyer> Alright, I'm going to call it a day and see if I can get some proper sleep for a change..
[21:21] <niemeyer> Have a good night all
[21:59] <Pharaoh_Atem> niemeyer, zyga-ubuntu: it seems that we might want to reprovision the Fedora 27 Linode VM from scratch: https://pagure.io/Fedora-Council/tickets/issue/99
[21:59] <Pharaoh_Atem> that will let us add tests for SELinux stuff
[21:59] <Pharaoh_Atem> c.f.: https://pagure.io/Fedora-Council/tickets/issue/99#comment-480742


 @tsimonq2 [wxl: We should look at swapping out qps with ksysguard], Why!
 Better UI I guess :)
 Do a side-by-side comparison yourself.
 Ah I gotcha. Not gonna steal Wendy's thunder though lemme know if you want a newbie like me to help @TheWendyPower
 Welcome @miguel1mx :)
 Thank you, @tsimonq2!
 The final Lubuntu 18.10 was even better than the beta! Thank you so much!
 It feels faster and the file manager is a little more responsive!
 Thanks :)
 HE'S HERE
 :D
 Welcome!
[01:54] -lugito:#lubuntu-devel- [rMANUAL95f08d167d57: Remove Gtk Spec.pdf as Qt one as Spec sheet.] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL95f08d167d57
[01:59] -lugito:#lubuntu-devel- [T115: Revamp Weblate] teward (Thomas Ward) commented on the task: https://phab.lubuntu.me/T115#2442
[02:00] -lugito:#lubuntu-devel- [T115: Revamp Weblate] tsimonq2 (Simon Quigley) commented on the task: https://phab.lubuntu.me/T115#2444
[02:02] -lugito:#lubuntu-devel- [T115: Revamp Weblate] wxl (Walter Lapchynski) commented on the task: https://phab.lubuntu.me/T115#2445
[02:08] -lugito:#lubuntu-devel- [T107: Calamares testing] wxl (Walter Lapchynski) commented on the task: https://phab.lubuntu.me/T107#2446
[02:25] -lugito:#lubuntu-devel- [rMANUAL2a15fcb62817: Add initial docs for multimonitor settings.] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL2a15fcb62817
[02:56] -lugito:#lubuntu-devel- [rMANUAL80e32610648c: Add stub on how to launch kde_partition manager.] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL80e32610648c
[02:56] -lugito:#lubuntu-devel- [rMANUAL7b98da210442: Add kde partition manager to toctree.] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUAL7b98da210442
[03:37] -lugito:#lubuntu-devel- [rMANUALfc49e7d4137d: Add how to check SMART on kdepartition manager.] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUALfc49e7d4137d
[03:51] -lugito:#lubuntu-devel- [T115: Revamp Weblate] teward (Thomas Ward) commented on the task: https://phab.lubuntu.me/T115#2447
[05:31] -lugito:#lubuntu-devel- [rMANUAL91e6136fa1dc: Update translations with all languages Weblate supports.] tsimonq2 (Simon Quigley) committed: https://phab.lubuntu.me/rMANUAL91e6136fa1dc
[05:31] -lugito:#lubuntu-devel- [rMANUAL08c8246796d8: Update translations with all languages Weblate supports.] tsimonq2 (Simon Quigley) committed: https://phab.lubuntu.me/rMANUAL08c8246796d8
[06:13] <tsimonq2> wxl: qtwebkit-opensource-src is in Cosmic UNAPPROVED now.
[06:14] <tsimonq2> I tested the fix from my PPA in a VM before uploading and it works fine.
[06:15] <tsimonq2> If LibreOffice continues to fail I will be confused as to why.
[06:17] <tsimonq2> If @Wafficus or @HMollerCl wants to take care of https://phab.lubuntu.me/T116 that would be great, otherwise I guess I'll do it tomorrow.
[06:17] -lugito:#lubuntu-devel- [Medium, Open] Cherry pick lxqt-config GUI fixes: https://phab.lubuntu.me/T116
 hello
[06:34] -lugito:#lubuntu-devel- [rMANUALf6043271d17a: Another crufty package to purge during update.] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUALf6043271d17a
 ok
[10:15] <apt-ghetto> In the manual I am missing a chapter about "System Administration"
[10:17] <apt-ghetto> I was wondering how I can modify for example /etc/fstab with Featherpad. Is there something similar like the GVFS admin:// backend?
[10:19] <apt-ghetto> The only useful way to edit /etc/fstab was with sudoedit. What is the Lubuntu-Way to admin the system?
 @apt-ghetto [<apt-ghetto> The only useful way to edit /etc/fstab was with sudoedit. What is t …], lxqt-sudo is the equivalent of gksudo. 'sudo featherpad' works as well, though.
 sudo and lxqt-sudo do not change env variables which lead to problems e.g. the featherpad config file is owned by root etc
 gksudo has changed the env variables. But it is not necessary and not a good idea to run the whole GUI app as root
 @aptghetto [sudo and lxqt-sudo do not change env variables which lead to problems e.g. the f …], Oh hell, you're right. That's pretty bad. *sudo chowns their fp.conf*
 Looks like this doesn't happen with lxqt-sudo. But I admit that I'm not very knowledgable in sysadmin. I'm just a reddit mod who lurks the dev chat :D
 @tsimonq2 [<tsimonq2> If @Wafficus or @HMollerCl wants to take care of https://phab.lubuntu …], I could look at it on Monday
 @marneu [Looks like this doesn't happen with lxqt-sudo. But I admit that I'm not very kno …], Sudo -i works but only for some files
 @Wafficus [Ah I gotcha.  Let me know what time works for you. I'm totally available 7:30 pm est USA onward on Monday night. Hans, I'm assuming you're in Europe right? What time works for you? Also goes for Wendy too
 @tsimonq2 could it wait until Monday night or is this urgent?
 @TheWendyPower btw, great job with the design work. I know I said it before but I am such a big fan of dark themes on everything to lower the stress on my eyes. I saw your photography site and am pretty impressed too. Keep up the good work.
 I only say this cause my job is so intense these days that I use the weekend to just wind down so I don't burn out and quit.
 Hopefully that doesn't come off as not being excited to work throughout the week nights for you guys though
 @Wafficus [@tsimonq2 could it wait until Monday night or is this urgent?], Fine by me.
 @Wafficus [@TheWendyPower @HMollerCl hey guys since we're all newbies at it, let's tackle i …], Actually I'm from South America, Chile. I'm not used to us Timezone, we use GMT here, GMT -3 is our current time
[17:32] <teward> Eastern US timezone is UTC-4 right now, in case it matters :P
[17:32] <teward> :P
[17:38] <tsimonq2> Eastern is UTC-4, Central is UTC-5, Mountain is UTC-6, Pacific is UTC-7
[17:38] <tsimonq2> In about a month though, those become:
[17:39] <tsimonq2> Eastern UTC-5, Central UTC-6, Mountain UTC-7, Pacific UTC-8
[17:39] <tsimonq2> (I think)
[17:39] <tsimonq2> teward is Eastern, I'm Central, @TheWendyPower is Mountain, and wxl is Pacific.
 Nov. 4th
 that's when DST is over and we all get another hour away from UTC in the US here
 :P
 :P
 *knows things*
 Failed to update repository: fatal: cannot mkdir /srv/weblate/lib/python3.6/site-packages/data/vcs/lubuntu/manual: Permission denied (128)
 @teward001 fix it :P
 can't I enjoy five seconds to have another shot of espresso >.>
 Nope
 😆
 @tsimonq2 standby.
 Thanks
 @teward001 You can never have 5 seconds to get cofee muahahahahahah
 try now
 @tsimonq2 something about stupid system default perms are annoying
 i may have to ACL this to change the default umasks of how dirs and such are created 😐
 but we should be good now.
 @Wafficus [@TheWendyPower btw, great job with the design work. I know I said it before but …], Thanks! My schedule is all over the place. Thankfully if we are not on at the same time we can share thoughts, suggestions and ideas here.
 @TheWendyPower cool what I'll probably do is brainstorm a few ideas of what I think the average Lubuntu user would love to have, make a super simple qt mockup of it, share it as a repository on Lubuntus phabricator and well work from there. How does that sound teammates? @HMollerCl @TheWendyPower
 I'll be able to put that into motion tomorrow night
 That sounds good. I'll make a list of some of my ideas, especially with the look of it.
[18:57] -lugito:#lubuntu-devel- [T115: Revamp Weblate] wxl (Walter Lapchynski) commented on the task: https://phab.lubuntu.me/T115#2450
[19:14] <tsimonq2> wxl: How good are you with regexp statements? :P
[19:15] <wxl> decent
[19:17] <tsimonq2> wxl: See this? https://phab.lubuntu.me/source/lubuntu-manual/browse/master/source/po/en-gb/LC_MESSAGES/ I need a regexp that matches all po files, which can be in source/po/LANG/LC_MESSAGES/ or source/po/LANG/LC_MESSAGES/*/ or source/po/LANG/LC_MESSAGES/*/*
[19:18] <wxl> what's the goal here.. where does this end up?
[19:18] <tsimonq2> Weblate.
[19:18] <tsimonq2> This plugin needs a regexp to match all po files to translate.
 (Photo, 1280x1084) https://i.imgur.com/VM9pB8K.jpg
[19:21] <wxl> that ?P<something> must be their own syntax
[19:24] <apt-ghetto> (?P<NAME>pattern) is a named capture group => https://perldoc.perl.org/perlre.html at least if it is a PCRE
[19:24] <wxl> that first one reads like "some language" "any number of characters that's not a slash" "a slash" "some component" "any number of characters that's not a slash" ".po"
[19:25] <wxl> the [^/]/ seems like a strange overly convoluted construct
[19:25] <wxl> oh yeah i don't do pcre at all
[19:27] <wxl> i guess tht would explain the parens as they're otherwise just sort of unnecessary
[19:30] <wxl> are there going to be languages in here?
[19:30] <wxl> oh nevermind
[19:30] <wxl> reading your message too literally
[19:31] <wxl> or rather, reading correctly your poorly communicated message :)
[19:31] <apt-ghetto> in think [^/]* means every sign except the slash
[19:32] <wxl> source/po/(?P<language>[^/]*)/LC_MESSAGES/
[19:32] <wxl> that's the core at least
[19:32] <wxl> well
[19:32] <wxl> source/po/(?P<language>[^/]*)/LC_MESSAGES/(?P<component>[^/]*)\.po
[19:33] <tsimonq2> Except, we can't use component, because that will always be "manual"
[19:33] <wxl> so name it anything
[19:34] <tsimonq2> Worst case scenario we have to split this into like 20 different components like LXQt, but I don't wanna do that :/
[19:34] <wxl> but i don't know if weblate somehow requires a specific name
[19:34] <tsimonq2> I'm about ready to be lazy and just do that. XD
[19:35] <tsimonq2> wxl: Wanna figure this out or should I say "screw it" and take the easy way out?
[19:35] <wxl> i think we can figure out the regex
[19:36] <tsimonq2> mkay
[19:36] <wxl> i just don't know what implications their named captures have
[19:36] <wxl> so easy might be better
[19:36] <tsimonq2> So let's do it.
[19:36] <tsimonq2> I'll get that done, just give me a few :)
[20:17] <tsimonq2> So, adding this all individually got extremely tedious.
[20:18] <tsimonq2> I figured out I can just export a JSON file, replace it with whatever new things I want, and bam :D
 Doesnt that regex statement only mean to look for match that only starts with a slash character
[23:15] -lugito:#lubuntu-devel- [rMANUALd608fafe7e36: Useage for openbox settings including how to move titlebar buttons around.] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUALd608fafe7e36


[06:42] <dholbach> good morning
[13:15] <lool> dholbach: moved invite 5 mn earlier to have people joing the HO etc.
[13:16] <lool> also added this channel to the invite
[13:21] <lool> etherpad for the HO http://pad.ubuntu.com/zx7ysKeP78
[13:23] <Vikram> hi there
[13:23] <dholbach> I just updated http://ubuntuonair.com/
[13:23] <dholbach> so the video should say "Power management architecture"
[13:23] <dholbach> if it doesn't please reload
[13:24] <dholbach> we'll start in 7m
[13:24] <MasterLotus> Hey gaize
[13:24] <dica> sto se ne vidi ovo polje gdje se pise :/
[13:25] <Fiszu> o kurde
[13:26] <Fiszu> witajcie !
[13:26] <Gold_> suuuuuuuup
[13:27] <edison_> hi
[13:27] <adi___> halo
[13:28] <adi___> i'm in indonsia
[13:28] <sidewalk> QUESTION: what goals do you have for the Power Management architecture in Ubuntu?
[13:29] <lool> http://pad.ubuntu.com/zx7ysKeP78
[13:29] <lool> sidewalk: saving power!
[13:29] <lool> ;-)
[13:30] <sidewalk> lool: i hope thats not it
[13:30] <mamthelegend> sercan nickin ne yaw
[13:30] <achiang> what is the link to the etherpad?
[13:31] <MasterLotus> nigger
[13:31] <azubu> hi
[13:32] <adi___> this progam
[13:32] <nami> Lalala
[13:32] <adi___> bisa bahasa indonesia
[13:33] <nami> hi adi are u from indonesia?
[13:34] <Milky_> where is discussion going on?
[13:34] <Uber_Nazi> Hello
[13:34] <Windows7x64> When i can download Windows 7?
[13:34] <dholbach> Milky_, http://ubuntuonair.com/
[13:34] <glam> good evening
[13:34] <adi___> mau upgrade dari ubuntu 10.04 ke ubuntu 10.10 knp ga suport
[13:35] <sammy87> good evening
[13:35] <primax> what about power management on pc?
[13:35] <dholbach> please if you ask questions, make sure you prefix them with QUESTION:
[13:35] <dholbach> so it's easier for us to pick up
[13:35] <Fr34kadelle> okay
[13:35] <comiPFC> I have a question. Will Ubuntu be avalible on old android phones like Motorola Defy for example or just newer ones?
[13:36] <qetalle007> hey
[13:36] <adi___> hay
[13:36] <dholbach> comiPFC, https://wiki.ubuntu.com/Touch lists all the devices where Ubuntu Touch was ported to
[13:37] <comiPFC> Thnaks!
[13:37] <JsKandhari> Is the event on ?
[13:37] <goji> ???
[13:37] <dholbach> yes
[13:37] <pamchi> how can i get involve ubuntu development????
[13:37] <dholbach> it's up on http://ubuntuonair.com/
[13:37] <dholbach> JsKandhari, ^
[13:37] <JsKandhari> it is 5 mins over and i can still see the noise screen
[13:37] <einalex> dholbach: perhaps it's more visible if you put it in the topic
[13:37] <dholbach> pamchi, http://developer.ubuntu.com/packaging/ basically
[13:37] <Fr34kadelle> @JsKandhari Try to Refresh?
[13:37] <pamchi> dholbach i mean, work for canonical,
[13:38] <pamchi> ?
[13:38] <dholbach> pamchi, http://www.canonical.com/about-canonical/careers
[13:38] <Guest11549> getting balck screen in between..\
[13:38] <JsKandhari> Thanks !
[13:38] <Fr34kadelle> :D
[13:38] <dholbach> comiPFC, https://wiki.ubuntu.com/Touch/Devices I meant - sorry
[13:39] <HackoGram> I've questions
[13:39] <dholbach> HackoGram, feel free to ask them in here, just make sure you prefix them with QUESTION:
[13:40] <glam> QUESTION: why linuxmint rating's in distrowatch ahead ubuntu's rating ?
[13:41] <comiPFC> @dholbach i found it there.. so only Nexuses so far...
[13:41] <dholbach> comiPFC, there's like 30-40 devices listed there, no?
[13:41] <dholbach> glam, that's not really related to power management architecture :)
[13:41] <glam> QUESTION: why linuxmint rating's in distrowatch ahead ubuntu's rating ?
[13:41] <comiPFC> talking about phablet-flash
[13:42] <glam> dholbanch, i think it's because Unity DE
[13:42] <dholbach> glam, still unrelated - it'd be a distraction from the topic
[13:42] <qwinie> Question : i'm from belgium, working with Ubuntu now for a few years. I would love to sell or just let the people know about Ubuntu. Where should i go to?
[13:42] <Milky_> there is some problem with your cam seth please recover
[13:42] <dholbach> comiPFC, ah yes, that's being discussed on the mailing list - all the bits have to be redistributable to be supported by phablet-flash
[13:43] <dholbach> comiPFC, if we can make sure that everything is redistributable, they could be supported by phablet-flash too
[13:43] <niki> wow
[13:43] <dholbach> comiPFC, it might help to ask in #ubuntu-touch
[13:44] <comiPFC> Thanks
[13:44] <ubuntualex89> Thomas you have some issues with your connectivity
[13:44] <tvoss> ubuntualex89, thx, am I breaking up?
[13:45] <dholbach> tvoss, you were briefly, yes
[13:45] <Mattia93it> When Ubuntu13.04 relase-day?
[13:45] <tvoss> dholbach, hopefully better now, let me know if it gets worse
[13:45] <Libras2909>  /msg NickServ VERIFY REGISTER Libras2909 kflqnfkwnhcq
[13:45] <hareesh> my pc gets heatd up usin ubuntu 64 bit
[13:45] <ubuntualex89> Yep.... prrety much . It seems there are issues in Germany :)  .'cause also Martin has some lag
[13:46] <dholbach> ubuntualex89, I'm in Germany too ;-)
[13:49] <qetalle007> i´m from germany too :D
[13:49] <comiPFC> QUESTIO: Maybe this isn't the time or the place for this question, but since i installed Ubuntu on my computer (from XP) it's running slower than Windows, and since it uses less ram and processor strenght it shouldn't..
[13:51] <hareesh> lags a lot over India too..
[13:52] <ubuntualex89> Yeah...not a good day for science it seems :))
[13:54] <sergiusens> did the hangout just die or is it just me?
[13:54] <sergiusens> page refresh did the trick
[13:55] <mfisch> A great example of API abuse that I used at my last job: http://mjtsai.com/blog/2010/08/03/ios-background-app-kludge/
[13:55] <CODENAME4365> hey guys
[13:58] <sergiusens> yeah, like whatsapp
[13:58] <sergiusens> tvoss: yes we do :-)
[14:00] <HcNguyen111_> @mfisch, interesting...
[14:01] <benkaiser> are you talking about the power consumption being a stat on the app or attached to user reviews?
[14:02] <Arthur___> hello
[14:02] <tvoss> sergiusens, ? :) sorry, difficutl to associate :)
[14:02] <einalex> tvoss: sure the system should save your power, but in the end the user is still interested in which application uses how much energy. She can judge how important a certain application/functionality is then because she knws the costs (in battery life).
[14:03] <tvoss> einalex, sure, having that information available is useful
[14:04] <sergiusens> tvoss: users care about network usage
[14:04] <tvoss> sergiusens, they do, sure. as I said: having the data is useful to the user, but our default policies should be clever as well
[14:05] <brunogirin> lool: would it be a case of having the app being able to specify "I need this device while running in the background so please don't shut it down" with device being things like audio, screen, etc.
[14:06] <einalex> I guess we agree that we want both: very good policies and introspection
[14:08] <lool> brunogirin: yeah, do you have a specific example?
[14:08] <lool> maybe with sensors etc.
[14:09] <karni_> You can leave that up to the app, allow it to use different flags to indicate what the expectations should be. Exactly, hints.
[14:09] <sergiusens> tvoss: camera should keep the screen on, video as well... certain video games may not require it
[14:10] <benkaiser> just have a permission for 'allowed to keep the screen on'
[14:10] <karni_> video/game should grab a lock that keeps the screen on. full screen image preview would not.
[14:11] <brunogirin> lool: for screen, video playback; for audio, music playback
[14:11] <sergiusens> karni_: depends on the video game, so yes, up to the app
[14:11] <karni_> sergiusens: Sure. Perhaps chess game would allow for the screen to go off haha :)
[14:11] <benkaiser> by giving th 'fullscreen' permission it would mean I trust that app to keep the screen on. Like when I trust an app to have sms capabilities, I trust it to not abuse them.
[14:12] <karni_> fullscreen != keep screen on
[14:12] <karni_> mixing the two would be a huge mistake.
[14:12] <psi__> hi everybody
[14:12] <einalex> karni_: +1
[14:12] <benkaiser> sorry I mean keep screen on permission
[14:12] <karni_> I trust the image preview can take up fullscreen. But no sense for it to keep screen on, unless it's a "picture frame feature"
[14:13] <brunogirin> lool: you could have an API like startDeviceSession(device); stopDeviceSession(device) to notify the OS that your app wants to use a given device without interruption
[14:13] <karni_> +1 on reference counting device wake lock
[14:14] <momits> i feel it makes sense to let the apps themselves decide which full-screen priority they need. even if the default should be really restrictive.
[14:14] <Skald_9_> it has to be easy to turn on and off
[14:15] <karni_> The app could even provide as granular flag as "grab screen lock, allow dim"
[14:15] <aabb> it's powerful
[14:16] <karni_> (that would actually be alternative of two flags, for the record)
[14:16] <achiang> karni_: android does that with the flags you pass in to the wakelock, right?
[14:18] <momits> QUESTION: as the goal is to reach convergence between the desktop and phone codebase, will the power management rules also apply for desktop apps? like video-renderers etc?
[14:18] <karni_> achiang: correct
[14:19] <karni_> achiang: an activity (what you see on the screen) can also have a "keep screen on" flag (just a wake lock made easier)
[14:20] <lool> brunogirin: what you describe is typically android wakelocks
[14:20] <lool> brunogirin: but then we're screwed in that we can't really be clever at saving power; we have to honor the apps desire
[14:20] <karni_> momits: What do you have in mind? A desktop computer usually does not go off/suspend on it's own, in contract to handheld devices.
[14:21] <shubham_> shubhu
[14:21] <momits> karni: im thinking of the dockable version of handheld devices (like ubuntu for android), which will probably replace desktop computers some time.
[14:23] <brunogirin> lool: ok didn't know :-) but we can use a similar principle and rather than the API being a hard request, make it a query from the app with a way for the OS to say "no I can't do that"
[14:23] <karni_> momits: I see. If you'd dock such device, power management wouldn't be so conservative, so your video renderer would happily use the screen that is on.
[14:24] <karni_> PowerManagement policy will change the moment you dock, I would imagine.
[14:24] <brunogirin> lool: or allow the app to register a callback so that the OS can send back a notification if it decides to reclaim the wakelock early
[14:25] <momits> ok, makes sense.
[14:26] <brunogirin> Isn't it more important to know whether your device is plugged in or not rather than whether it's in phone or desktop mode?
[14:26] <exty32> hello
[14:27] <karni_> brunogirin: I agree, however "phone mode" is not well defined. Plugged phone is somewhat better, so both factors are important.
[14:29] <brunogirin> Regarding old/new APIs, what about restricting apps that use the old API (current desktop apps) to only run in desktop mode while apps that use the new API can run in any mode?
[14:32] <deneme> ooh no
[14:32] <deneme> i just came :(
[14:32] <exty32> end
[14:43] <einalex> dholbach: Hi Daniel, Do you know if the google calender linked on ubuntuonair.com is up to date? the last hangout and to one coming up don't appear there
[14:44] <dholbach> einalex, JoseeAntonioR would know
[14:44] <dholbach> I don't, sorry
[14:44] <einalex> dholbach: alright, thanks
[14:45] <einalex> let's see if he got the ping
[14:54] <HcNguyen111_> that was good
[15:00] <linuxdude> are we live
[15:02] <dholbach> linuxdude, no
[15:02] <dholbach> linuxdude, 1h until the next hangout
[15:03] <linuxdude> dholbach: thank you
[15:03] <dholbach> anytime
[15:15] <laky95> hi all :)
[15:21] <qwertyuioppo> qwertyuiop
[15:22] <qwertyuioppo> qwertyuio
[15:22] <qwertyuioppo> qwertyui
[15:22] <qwertyuioppo> qwertyu
[15:22] <qwertyuioppo> qwerty
[15:22] <qwertyuioppo> qwert
[15:22] <qwertyuioppo> qwe
[15:22] <qwertyuioppo> qwe
[15:22] <qwertyuioppo> qw
[15:22] <qwertyuioppo> q
[15:22] <qwertyuioppo> .
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo> frgverbrgvbrwegtb
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <einalex> ~get a life
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo>
[15:22] <qwertyuioppo> where can i buy it?
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <einalex> from me
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <qwertyuioppo>
[15:23] <stijndg> nice :)
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo>
[15:25] <qwertyuioppo> .
[15:25] <qwertyuioppo> ..
[15:25] <qwertyuioppo> ...
[15:25] <qwertyuioppo> ....
[15:25] <qwertyuioppo> .....
[15:25] <qwertyuioppo> ......
[15:25] <qwertyuioppo> .......
[15:25] <qwertyuioppo> ........
[15:25] <qwertyuioppo> .........
[15:25] <qwertyuioppo> ..........
[15:25] <einalex> dholbach: you're needed ;)
[15:25] <qwertyuioppo> ............
[15:25] <qwertyuioppo> ............
[15:25] <qwertyuioppo> .............
[15:25] <qwertyuioppo> ..............
[15:25] <qwertyuioppo> ...............
[15:25] <qwertyuioppo> ...............
[15:25] <qwertyuioppo> ................
[15:25] <qwertyuioppo> .................
[15:26] <qwertyuioppo> ..................
[15:26] <qwertyuioppo> ...................
[15:26] <qwertyuioppo> ....................
[15:26] <qwertyuioppo> .....................
[15:26] <qwertyuioppo> ......................
[15:26] <qwertyuioppo> .......................
[15:26] <qwertyuioppo> ........................
[15:26] <qwertyuioppo> .........................
[15:26] <qwertyuioppo> ..........................
[15:26] <qwertyuioppo> ...........................
[15:26] <qwertyuioppo> ............................
[15:26] <qwertyuioppo> .............................
[15:26] <qwertyuioppo> ..............................
[15:26] <qwertyuioppo> ...............................
[15:26] <qwertyuioppo> ................................
[15:26] <qwertyuioppo> .................................
[15:26] <Natzer> first time on hangout... but i'm wondering..  ubuntu is such a nice os but only an handfull people right here?
[15:26] <qwertyuioppo> ..................................
[15:26] <qwertyuioppo> ...................................
[15:26] <qwertyuioppo> ....................................
[15:26] <qwertyuioppo> .....................................
[15:26] <qwertyuioppo> ......................................
[15:26] <qwertyuioppo> ......................................
[15:26] <kenvandine> dholbach, thanks!
[15:27] <einalex> many thanks! :)
[15:41] <prashant> hello
[15:41] <prashant> so whats new is going to ubuntu
[15:44] <sheeru> [QUESTION] is canonical mentoring for gsoc 2013?
[15:46] <dholbach> sheeru, no, Ubuntu is not part of this year's GSoC, I'm afraid
[15:48] <id4rk> hello everyone"
[15:48] <soe> can I use ubuntu on my huawei c8812?
[15:49] <dholbach> soe, https://wiki.ubuntu.com/Touch/Devices lists all the devices ubuntu touch was ported to
[15:50] <id4rk> now
[15:50] <soe> thanks
[15:52] <id4rk> could you make a smaller video the next time, i cannot see the chat and video at the same time lol :P
[15:52] <id4rk> or put the video on the left side of the chat
[15:53] <id4rk> everyone has widescreens nowadays
[15:53] <dholbach> id4rk, JoseeAntonioR might be able to help with that
[15:53] <dholbach> although I'm not sure he's around right now
[15:54] <id4rk> It's ok for now, don worry, it's just an idea.
[15:54] <dholbach> a good idea :)
[15:55] <id4rk> Thank you. :-)
[15:55] <disaksen> Hello people! :)
[15:56] <disaksen> Hmm, dholbach is Turkish, or atleast located in Turkey...
[15:57] <dholbach> disaksen, not really :)
[15:58] <jzo> hello
[16:01] <einalex> dholbach: what's wrong about using another client?
[16:01] <dholbach> einalex, nothing at all
[16:01] <dholbach> einalex, but I guess a lot of people just use their web browser
[16:01] <einalex> hehe that#s what I thought :)
[16:02] <pig_org> hi all
[16:02] <mitko> hi!
[16:02] <MarekZeman91> Yeap, I’m in G.Chrome
[16:02] <MarekZeman91> Ps: Hi all
[16:03] <Khariton> test
[16:04] <id4rk> Reply: test
[16:04] <MarekZeman91> test success :D
[16:04] <Khariton> thx
[16:04] <id4rk> hahaha
[16:04] <Khariton> When will begin show? ))
[16:05] <einalex> it just did
[16:05] <MarekZeman91> still see nothing
[16:05] <dholbach> if you want to ask questions, please do, but please prefix them with QUESTION:
[16:05] <Khariton> wau. this is awesome...
[16:05] <dholbach> might have to restart the page
[16:05] <einalex> try to reload the page
[16:05] <sopykt> How do I use ubutu touch on android ph
[16:06] <dholbach> sopykt, that might be a question for #ubuntu-touch
[16:06] <sopykt> yes
[16:08] <MarekZeman91> QUESTION: So what’s the current status/progress of mobile Ubuntu or Ubuntu Android?
[16:08] <vibhav> o/

[16:08] <vibhav> MarekZeman91: Thats unrelated to the topic. You can ask them at #ubuntu-touch
[16:10] <vibhav> QUESTION: Essentially, the Facebook and the Twitter core apps use the friends api?
[16:12] <CheeseBurg> QUESTION: Is friends made with Python 3? Why not C++, I feel like good C++ code could be faster and more memory effective than good Python 3 code.
[16:14] <crhrabal> QUESTION:  Will Friends have different UI in desktop vs touch?
[16:15] <vibhav> crhrabal: friends is an API. You can decide the UI
[16:15] <vibhav> Friends doesn't provide a UI, iirc
[16:16] <micah_> QUESTION: I'm working on a Pandora client for Ubuntu touch. I'm in the early stages, but it would be nice for the final product to be able to post to facebook / twitter, etc. Where can I find the info about the friends API?
[16:17] <vibhav> micah_: Are you talking about documentation?
[16:17] <micah_> yeah
[16:17] <vibhav> let me see
[16:20] <CheeseBurg> CheeseBurg: Is the friends api connecting to Ubuntu One so that the Ubuntu One account is automatically connected to my other accounts. This would be nice doing a fresh install and once I log in, all my other accounts just sync without any extra work.
[16:21] <jessejoker>  What code editor are showing us there Ken?
[16:22] <trobert2> are we going to be able to code apps in python for mobile?
[16:22] <trobert2> i got the impression that we can do it only in c/c++
[16:23] <ahayzen> QUESTION: How does the QML app link to the Python 3 API behind...and is the Python 3 API running on the Phone or is something else used?
[16:23] <ahayzen> trobert2, same...maybe u can use Python backends?
[16:24] <CheeseBurg> QUESTION: How many social networks do you support now? Are you expecting the community to add more or will a team within Canonical also be working to add more networks along side the community?
[16:25] <vibhav> jessejoker: QtCreator
[16:25] <jessejoker> vibhav: ty!
[16:25] <trobert2> thank you!
[16:26] <ahmet> ...
[16:26] <vibhav> QUESTION: Where can I find the api documentation for the friends api?
[16:29] <dholbach> thta's https://launchpad.net/qml-friends
[16:29] <dholbach> that's https://launchpad.net/qml-friends :)
[16:30] <micah_> thanks!
[16:32] <ahayzen> kenvandine, thanks :)
[16:32] <kenvandine> ahayzen, np
[16:33] <vibhav> QUESTION: How can I use the friends api with my C code?
[16:33] <kenvandine> lp:libfriends
[16:33] <kenvandine> there are code examples there as well
[16:33] <crhrabal> Disqus would be great with Friends :)
[16:34] <kenvandine> and you can build it with docs enabled for gtkdoc style docs
[16:36] <CheeseBurg> QUESTION: Will Unity Next use the friends api?
[16:38] <crhrabal> QUESTION: Are Google+ and Google Hangouts Open-Source? Would Google+ and Hangouts be possible to implement within Friends?
[16:43] <micah_> QUESTION: Will there be a way to only allow certain contacts from fb, etc. into our contact book? I have too many FB friends.
[16:44] <CheeseBurg> QUESTIONS: Is the api being developed with the SDK?
[16:45] <CheeseBurg> Does Ubuntu have a contacts application? Will the friends api be intergrated into it?
[16:45] <crhrabal> QUESTION: With limitations in Google+, does Ubuntu have any plans to create their own unfettered alternative to Hangouts?
[16:46] <Lil-|^Red> Will the Social network App allow for a statusnet (pump.io etc) aspect ? i.e. https://pump.jpope.org/jpope
[16:46] <Lil-|^Red> QUESTION : | Will the Social network App allow for a statusnet (pump.io etc) aspect ? i.e. https://pump.jpope.org/jpope
[16:46] <Lil-|^Red> soz forgot the pre-amble.
[16:48] <brunogirin> QUESTION: if I build a new online platform, how much work is it to add support to it in Online Accounts?
[16:51] <Lil-|^Red> Question : | Will diaspora be supported :: e.g. https://diasp.eu/posts/224394
[16:53] <CheeseBurg> bye guys
[16:53] <ahayzen> thanks guys :)
[16:53] <Lil-|^Red> see-ya thanx.
[16:54] <robru> Lil-|^Red, no *plans* for diaspora but I'm certainly interested in accepting some patches for it if somebody were to write it ;-)
[16:55] <Lil-|^Red> I wil federate that request to the networks :-[ wHAT'S THE BEST CONTACT INFO. FOR THAT ?
[16:55] <Lil-|^Red> soz 4 caps.
[16:56] <dholbach>  #gwibber on irc.freenode.net it seems
[16:57] <Lil-|^Red> robru: dholbach: Sorry, I turned up late .... I meant in launchpad ?
[16:57] <dholbach> https://launchpad.net/friends if I'm not mistaken
[16:58] <Lil-|^Red> done.
[16:58] <dholbach> might be worth checking with the guys in #gwibber though :)
[16:59] <Lil-|^Red> I will mention the info. of " https://launchpad.net/~robru " too.
[17:01] <robru> Lil-|^Red, that's my launchpad page ;-)
[17:20] <Lil-|^Red> OK .. Federated to one pod so far .. https://diasp.eu/posts/946179#  [If you click on the speach-bubble ('Comment') and the bottom of the screen - you should get a Request for Patches message.
[17:21] <Lil-|^Red> If you can't... don't bother/worry .. It's only another bpod to deal with ;)
[17:22] <Lil-|^Red> robru: Hope some love comes yur way .. :-)
[17:24] <gromy> *
[17:30] <RojLaweRoj> hi frriend :(
[17:30] <RojLaweRoj> hii
[17:31] <RojLaweRoj> who is here
[17:31] <Lil-|^Red> RojLaweRoj: Moi- sei
[17:32] <Lil-|^Red> Why the :( grumpy-face ?
[17:32]  * Lil-|^Red tucks into his chicken home pride...
[17:33] <Lil-|^Red> oh well ...
[17:34] <ROJ> hiii
[17:34] <Lil-|^Red> same guy ?
[18:51] <Keiron> Is the stream over?
[19:27] <Guest6376> :o
[19:27] <Guest6376> 6 days left to hit the official 13.04 ? :)
[23:51] <ip4gjb> hello
[23:51] <JoseeAntonioR> hey, ip4gjb


[01:35] <azriel> anyone around?
[01:36] <azriel> well, i was reading an article and upstart was mentioned, but nothing about the status of it, i was wondering if its already being used by default in ubuntu
[01:37] <mbiebl> http://upstart.ubuntu.com/
[05:17] <EruditeHermit> hi, when I installed upstart on my debian box, it seemed to start everything sequentially like sysvinit
[05:17] <EruditeHermit> is there something I need to do to make it start htem in parallel?
[05:42] <wasabi> Yes, you need to rewrite every single init script on your system.
[05:42] <wasabi> Get busy!
[10:36] <Fuzzy76> are there any newer documentation regarding the implementation plan mentioned half way down on http://www.netsplit.com/blog/articles/2006/08/26/upstart-in-universe ?
[10:37] <Fuzzy76> the goals seemed to have been missed, so I was just wondering what the current roadmap looked like :)
[11:25] <sadleder> Fuzzy76: have a look at http://people.ubuntu.com/~fabbione/irclogs/upstart-2007-03-16.html, Keybuk answered on that question there
[11:28] <Fuzzy76> So if I understand correctly, there will be a separate repository for packages with upstart jobs, and if I add that, my Feisty will use those?
[11:47] <sadleder> Fuzzy76: that's how I understand it
[01:06] <cortana> Md: optimism ;)
[01:06] <cortana> though i'd like to see lenny switch too
[03:33] <sadleder> mbiebl: hi, are you trying to keep differences to other distributions (e. g. ubuntu) in jobs small?
[03:34] <mbiebl> sadleder: the current package in experimental is basically identical with the one in feisty.
[03:34] <mbiebl> So, sure, I want to keep the difference as small as possible.
[03:35] <sadleder> mbiebl: I just wondered why upstart-jobs is not a branch from replacement-initscripts
[03:36] <mbiebl> sadleder: this is just a repo for my to toy around.
[03:37] <sadleder> mbiebl: ok
[03:37] <mbiebl> It's nothing official.
[03:37] <sadleder> mbiebl: the bootchart you pointed me to looked impressive
[03:37] <mbiebl> I probably shouldn't have put it on my public web site ;-)
[03:40] <sadleder> ;-)
[03:42] <sadleder> mbiebl: just found it on a search for a toy to play with ;-)
[09:34] <tale_> why isn't the concurrency setting turned on by default on feisty?
[09:35] <tale_> I saw it on digg in a performance tips blog that someone had posted.
[09:35] <tale_> they said to set it to shell
[09:35] <tale_> instead of none
[09:35] <tale_> I saw one guy in the comments that said it made his system boot slower
[09:36] <tale_> I thought concurrency was going to be enabled with upstart for this release.  Of course, I don't know that much about upstart.
[10:13] <tale_> Either everyone is asleep or nobody knows the answer.  Which is it?  :-)
[11:51] <darx> greetings folks :)
[11:52] <darx> how can i remove an application from running at the startup?