[00:00] <Yick> Is there anyone here works in the IT department ?
[00:00] <cjwatson> however it is not entirely clear to me from the comments in that bug that the segfault is in fact within isprint
[00:00] <penguin42> cjwatson: Cool, so I think that bug 965341 is that it should be using iswprint
[00:00] <penguin42> cjwatson: comment #3 from me ?
[00:00] <cjwatson> I don't see how isprint could be getting inlined into main
[00:01] <cjwatson> that comment shows the segfault in main, afaics
[00:01] <penguin42> yeh that's what the backtrace is showing - I'd thought the isprint and friends were macros or the like
[00:01] <juliohm> i'm also curious how penguin42 inferred about isprint() from the actual bug.
[00:02] <cjwatson> they might be implemented as macros, true
[00:02] <juliohm> oh, strace :-)
[00:02] <cjwatson> juliohm: he correlated gdb's output against the source code
[00:02] <juliohm> oh, not strace, gdb output, nice.
[00:03] <cjwatson> yeah, isprint is a macro that expands to an array lookup
[00:03] <cjwatson> if the value is out of bounds then it might well segfault
[00:03] <penguin42> cjwatson: Yeh, see ctype.h - it's a macro to __isprint that ends up indexing __ctype_b_loc that's 384 bytes long ish
[00:03] <Yick> Is there anyone here works in the IT department ?
[00:03] <Yick> Is there anyone here works in the IT department ?
[00:03] <cjwatson> not necessarily iswprint, it might also be correct to simply check that c is representable as unsigned char before passing it to isprint
[00:04] <cjwatson> Yick: please don't repeat without adding further context.  Why do you want such a person?
[00:04] <cjwatson> (whose IT department?)
[00:04] <Yick> any IT department. Want to know anyone has connection to Microsoft.
[00:04] <penguin42> cjwatson: However I'm a bit uncomfortable saying it just needs a change from isprint to iswprint since I don't understand the wide character stuff it's wrangling with; it does have a && c<128 *after* the !isprint(c) - but I think it needs a little more understanding
[00:05]  * penguin42 checks the date - oh yeh
[00:05] <cjwatson> penguin42: judging from the c<128 check, it isn't really interested in wide characters; I would say just  !isprint(c) && c<128  =>  c<128 && !isprint(c)
[00:06]  * juliohm is curious about the details of following the execution of the watch command in gdb for backtracing the bug and fix it
[00:06] <cjwatson> juliohm: it prints a line number when the program crashes, so it's pretty easy to look up from there (in this case)
[00:07] <cjwatson> for the rest, man gdb :-)
[00:07] <penguin42> cjwatson: Yeh, the code seems to be trying to detect wide characters and set a 'carry' variable to indicate it should fetch the next byte - and I think that's probably still OK
[00:07] <penguin42> juliohm: I installed the procps debug sym package, I then ran gdb `which watch` and then ran it in gdb with your args
[00:07] <juliohm> cjwatson, so, you have to download the source code first, right?
[00:07] <cjwatson> juliohm: yes, of course
[00:07] <penguin42> juliohm: Then I grabbed the source (using apt-get source procps) and looked for line 541
[00:07] <cjwatson> debugging programs without source code is no fun
[00:08] <juliohm> hmm, very interesting.
[00:08] <juliohm> let me try now, because maybe i can help in the future
[00:09] <juliohm> penguin42, what do you mean by procps debug sym package? is just the procps package?
[00:09] <penguin42> juliohm: Then I looked at that line and thought there's nothing that should seg fault, printed c, noticed it was HUGE, and wondered about isprint since I'd implement it using an array
[00:09] <cjwatson> hmm, mind you, isprint on a wint_t is a kind of dodgy thing to do
[00:09] <penguin42> juliohm: https://wiki.ubuntu.com/DebuggingProgramCrash
[00:10]  * juliohm is reading the link...
[00:10] <penguin42> cjwatson: Well, it does take an int (to allow EOF)
[00:11] <cjwatson> penguin42: sure, but technically, nothing in the standard requires int == wint_t
[00:11] <penguin42> nod
[00:11] <cjwatson> penguin42: I think your first instinct was correct and it should be iswprint
[00:11] <cjwatson> assuming that tests out
[00:12] <penguin42> cjwatson: What worries me is that at that point it would have the first half of a wide character and then passing that to iswprint also makes no sense
[00:12] <cjwatson> penguin42: how so?  my_getwc appears to read a whole wide character
[00:13] <cjwatson> or WEOF
[00:14] <cjwatson> penguin42: in any case, I think the important thing is that iswprint does *not* have a range of values specified as undefined behaviour
[00:15] <cjwatson> oh no that's not true
[00:15] <cjwatson> "For all functions described in this subclause that accept an argument of type wint_t, the
[00:15] <cjwatson> value shall be representable as a wchar_t or shall equal the value of the macro WEOF. If
[00:15] <cjwatson> this argument has any other value, the behavior is undefined.
[00:15] <cjwatson> "
[00:15] <cjwatson> still, my_getwc always returns something that meets that description, I think
[00:16] <cjwatson> given that it always returns either rval (which is a wchar_t and gets implicitly converted) or WEOF
[00:16] <penguin42> cjwatson: I'd be more comfortable if I understood what the heck that loop was actually trying to do
[00:17] <cjwatson> I haven't bothered to work it out but I'm confident in my statement that iswprint should never segfault in this case from dataflow analysis alone :)
[00:18] <cjwatson> it's some tedious display mangling, doesn't seem terribly interesting to work out the exact details
[00:18] <penguin42> yeh, I'm just not sure it does what the oriignal code was supposed to
[00:20] <cjwatson> well, the while condition basically asks for a non-printing character under 128 that isn't newline, tab, or (sometimes) esc; so promoting to iswprint for type compatibility doesn't seem to break anything there
[00:20] <penguin42> and my_getwc blows my mind - I can't see how it's while loop ever executes more than once given that it always returns in one of two ways
[00:20] <cjwatson> everything that manipulates c is typesafe
[00:21] <penguin42> oh, the if isn't indented - ok, I see how my_getwc works
[00:21] <cjwatson> penguin42: it just has rotten indentation
[00:21] <cjwatson> yeah, the last return is conditional on 'byte == MAX_ENC_BYTES'
[00:22] <cjwatson> but again, I think you just need to verify that it always returns a promoted wchar_t or WEOF
[00:22] <cjwatson> which is pretty clear
[00:23] <cjwatson> it's fairly grotty code but just stick to analysing the bits you need and it's ok
[00:24] <penguin42> yeh, and so my_getwc either a valid WC, a WEOF on an EOF< or WEOF on a bad char, then I think I agree iswprint should work
[00:24] <cjwatson> the one thing I'd note is the FORCE_8BIT bit at the top of the file, which may or may not be obsolete now
[00:24] <cjwatson> although leaving it there wouldn't actually hurt anything
[00:26] <penguin42> yeuch
[00:26] <juliohm> penguin42, thank you very much for the link, it's really helpful. ;-)
[00:26] <juliohm> I'll try the process when i have time.
[00:27] <penguin42> cjwatson: The code there comes from one of the debian patches
[00:27] <penguin42> cjwatson: watch_unicode.patch
[00:27] <cjwatson> yep
[00:28] <cjwatson> is that a big deal?
[00:28] <penguin42> I was just wondering if it was a debian patch or an ubuntu patch, but I think it's a debian one
[00:29] <cjwatson> looks like it
[00:29] <penguin42> nod
[00:30] <penguin42> cjwatson: Is the right thing there to add another patch to the end of the set or to fix that patch?
[00:31] <cjwatson> judgement call in general - in this case I'd probably fix that patch
[00:31] <penguin42> ode for a 1 character tweek
[00:31] <cjwatson> though I wouldn't reject a branch that added another one, I guess
[00:31] <cjwatson> but yeah, seems overkill
[00:32] <penguin42> actually it needs one of the other patches tweeking as well because that is diff'd against it
[00:33] <cjwatson> quilt push; quilt refresh your way up the stack
[00:33] <cjwatson> but basically trivial
[00:35] <penguin42> I could look at that tomorrow, but it's rather late now, and I can't actually remember any of teh quilt foo
[00:37] <cjwatson> if you've tested a patch and confirmed it works, feel free to just attach it to the bug and I can take care of the packaging
[00:37] <cjwatson> but you might want the learning experience and if so I don't want to deprive you either :)
[00:37] <penguin42> I'll look tomorrow, or should I say at 1:37 am later today
[00:43] <penguin42> right, bed!
[06:52] <YokoZar> https://launchpad.net/ubuntu/precise/+queue  :D
[06:54] <infinity> YokoZar: Yeah, I'm trying to decide if that was a joke. :P
[06:54] <infinity> YokoZar: Do I review it or reject it?
[06:54] <YokoZar> infinity: Review it of course, it fulfills its stated purpose ;)
[06:54] <infinity> Oh dear...
[06:55] <infinity> Oh, derp.  April 1.
[06:58]  * micahg is curious if a second person signed off on it
[07:04] <jhojho> cjwatson: see that you have been updating openssl. could you add the elliptic curve compile flag for 64bit for the next round? thx.
[08:59] <cjwatson> jhojho: no, I haven't got round to talking with the Debian maintainer about it yet
[09:23] <Whoopie> cjwatson: Hi, could you perhaps sponsor another package?  -> mail-notification, bug 881039
[09:24] <cjwatson> Whoopie: not right now, need to go out
[09:25] <Whoopie> cjwatson: ok
[09:25] <Whoopie> have fun
[09:25] <cjwatson> I can look later if nobody beats me to it
[09:30] <Daviey> Whoopie: you might find that some sponsors are unwilling to upload, without a Firstname Lastname in debian/changelog.
[09:31] <Whoopie> Daviey: might be. Even though I see a lot of packages with the same "issue".
[10:06] <infinity> Whoopie: It's not terribly common for people to upload with a real name.
[10:06] <infinity> Whoopie: But if the code's good, I don't care deeply either.
[11:18] <nigelb> ZarroBoogs: awww <3
[15:24] <PaoloRotolo> Hi all!
[16:20] <hallyn> tjaalton: hey, i thought i'd seen a push of xserver-xorg-video-qxl go by, but I don't see it in the archive?
[16:21] <hallyn> (maybe I mis-read a subject and it was another xserver-xorg...)
[16:35] <tjaalton> hallyn: you think we can just sync it? I mean it probably needs an FFe bug just to be on the safe side :)
[16:36] <hallyn> tjaalton: I don't know, since Munzir hasn't responded I guess I will try installing kubuntu in a guest tomorrow and see if I can (a) reproduce the bug and (b) see it fixed with the new version.
[16:37] <hallyn> tjaalton: if it doesn't explicitly fix a bug, then you might be right we should file ffe.
[16:37] <hallyn> guess it coudln't hurt to file ffe anyway, and then comment there if it fixes a bug
[16:38] <hallyn> (really, spice should be seen as a tech preview right now)
[16:40] <tjaalton> hallyn: I don't see any bugs open against -qxl, so this was something reported on irc?
[16:40] <hallyn> tjaalton: bug 913314
[16:41] <hallyn> after confirmation of the fix of original bug, he lists a few other things still going wrong.
[16:41] <tjaalton> ah, ok
[16:44]  * penguin42 looks up
[18:05] <JamesJRH> Is it possible for me to obtain a correct source of TAI from my system if I keep it in sync?
[18:06] <JamesJRH> Implementing TAI on top of UTC relies on UTC being correctly implemented. But Ubuntu seems to ignore leap seconds in it's implementation of UTC.
[19:19] <mamemame187> hello


[00:09] <tyhicks> jdstrand: circling back to our earlier discussion... a review of the code netlink code doesn't show anything odd and a simple test program which calls socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE) definitely requires a 'network netlink raw,' apparmor rule
[00:10] <tyhicks> here's the denial I get if I don't add that rule to the profile:
[00:10] <tyhicks> audit: type=1400 audit(1488499593.813:25): apparmor="DENIED" operation="create" profile="test" pid=1969 comm="nl" family="netlink" sock_type="raw" protocol=0 requested_mask="create" denied_mask="create"
[02:53] <mup> PR snapcraft#1171 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1171>
[07:49] <mup> PR snapd#2973 closed: cmd/snap-confine: use sc_do_mount everywhere <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2973>
[08:00] <mup> PR snapd#2953 closed: release: detect if we are in ForcedDevMode by inspecting the kernel <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2953>
[08:23] <mup> PR snapd#2978 opened: cmd/snap-confine: use sc_do_umount everywhere <Created by zyga> <https://github.com/snapcore/snapd/pull/2978>
[08:29] <liuxg> ogra_, ping
[08:31] <liuxg> ogra_, I used your sample code in the mailinglist to launch google.com using xdg-open, but it did not work in my place. the source code is at https://github.com/liu-xiao-guo/launchwebsite
[08:46] <mup> PR snapd#2950 closed: interfaces: use spec in kmod backend, updated firewall_control, openvswitch_support, ppp <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2950>
[08:46] <mardy> cjwatson: hi! Just found out about build.snapcraft.io :-) Are there plans to make it support gitlab.com?
[09:21] <stub> How to I revert a channel to an older release?
[09:21] <stub> Do I need to download the old snap and reupload it, or is there a smarter way?
[10:01] <mup> PR snapd#2970 closed: many: add support for retrieving snap history from API <Created by justincan> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2970>
[10:15] <ogra_> liuxg, do you have snapd-xdg-open installed on the host ?
[10:26] <joedborg> o/ all
[10:28] <joedborg> I'm trying to set an environment variable inside an app declaration (inside snapcraft.yaml).  I need to base this off the $SNAP variable, but I can't get it to resolve.
[10:28] <joedborg> e.g. $ echo $PYTHONPATH
[10:28] <joedborg> $SNAP/horizon
[10:38] <mup> PR snapd#2979 opened: tests: add ubuntu-core-16-32 system to the external backend and fix docker test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2979>
[10:38] <kalikiana_> stub: Unpublish, re-publish, that's the best way I found to do it
[10:39] <stub> ta.
[10:42] <liuxg> ogra_, ping
[10:42] <ogra_> liuxg, hey, did you see my reply above ?
[10:42] <liuxg> ogra_, sorry, I did not see the reply :) I will try it. thanks
[10:43] <liuxg> ogra_, is it a snap or debian?
[10:44] <ogra_> its a deb you need installed on your desktop (it was discussed in the thread)
[10:46] <cjwatson> mardy: Not at present
[10:46] <liuxg> ogra_, sorry, I did not read it through. I think it is good to have it as a build-package in the snapcraft.yaml
[10:46] <ogra_> liuxg, nope
[10:46] <ogra_> you need it installed on the desktop, nothing in snapcraft.yaml will help with that
[10:46] <liuxg> ogra_, I just installed it, and it worked.
[10:47] <liuxg> ogra_, so build-package will not install it onto the desktop?
[10:47] <ogra_> no
[10:47] <ogra_> snapcraft only operates inside the snap
[10:47] <liuxg> ogra_, ok. I got it. thanks.
[10:48] <liuxg> ogra_, thanks for your help on this. so, this is an dependence.
[10:48] <ogra_> right
[11:56] <didrocks> ogra_: I think the user wants to install a snap in the store (ktouch)
[11:56] <didrocks> not creating it
[11:57] <ogra_> didrocks, hmm, that wasnt clear to me, yeah, you might be right
[11:57] <didrocks> ogra_: so, the issue I guess is that the platform snap isn't connected to it, and the KDE helper (but I don't know how it works exactly) don't do this check with a nice error message unlike our desktop helper
[11:57] <popey> yeah, i agree
[11:58] <popey> they need to connect the content snap
[11:58] <didrocks> sitter: hey, you might way to either use our desktop helpers or add this kind of check as we do
[11:58] <didrocks> ogra_: feel free to rephase ;)
[11:58] <didrocks> rephrase*
[11:58] <didrocks> even
[12:00]  * ogra_ re-phases and is now fully positive charged
[12:01] <didrocks> ahah
[12:01] <didrocks> two or three phases? :)
[12:02] <ogra_> old school .... only two and a grounding (at times) :)
[12:02] <didrocks> heh
[12:51] <mup> PR snapd#2977 closed: releasing package snapd version 2.23 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2977>
[13:11] <jdstrand> tyhicks: maybe I got rate limited (even though I set it to '0')
[13:13] <jdstrand> tyhicks: but it was weird-- if I added the seccomp rule, no apparmor denial, if I removed it, seccomp denial. I then tried it multiple times...
[13:13] <jdstrand> (ie, went back and forth)
[13:16]  * jdstrand tries with dgram
[13:18] <stokachu> hmm how do i select a different organization in build.snapcraft.io?
[13:18] <stokachu> i made sure it had access to that org on github
[13:21] <jdstrand> dgram makes no difference
[13:22] <jdstrand> tyhicks: maybe it was incredibly poor timing-- I can confirm that it is denied by apparmor as root and non-root. I can also confirm that if I go fast enough even with rate limiting disabled, I don't always see it in the log
[13:23] <didrocks> mvo: hey, didn't you tell yesterday that 2.23 was blocked for zesty due to autopkgtests failing?
[13:28] <mvo> didrocks: it was, then things fixed themself, it was an outdated core snap on ppc64el that held it back. sorry, I understand this is annoying now :(
[13:29] <didrocks> mvo: we maybe should have put a hold… yeah, annoying it did fixed himself
[13:31] <Jasem[m]> Quick question: If I build a snap on 17.04, it will work on 16.04?
[13:34] <didrocks> Jasem[m]: if you include your all dependencies in your snap for a fully confined one, it should, indeed :)
[14:05] <Jasem[m]> didrocks: Thanks, I decided to build on 16.04 just to be safe
[14:07] <ogra_> Jasem[m], if you restrict yourself to run "snapcraft cleanbuild"  the host distro shouldnt matter (it will build in a xenial lxd container then)
[14:08] <Jasem[m]> ogra_: thanks will take that into consideration. So I'm building a snap now in 16.04, so deploying it to Ubuntu-Core wouldn't be an issue I presume?
[14:08] <ogra_> right
[14:09] <Jasem[m]> Anyone here used Ubuntu-Core with Snapdragon board? I just saw the Embedded Linux videos
[14:09] <ogra_> well, i'm maintaining the port ... so i occasionally actually use it ;)
[14:10] <ogra_> s/port/image port/
[14:10] <Jasem[m]> ogra_: I was considering it for my embedded project, but then read some issues about WiFi.. I think I might be eventually settle for the good-old RPI3
[14:10] <ogra_> the dragonboard has no wifi issues
[14:10] <ogra_> the pi3 does though :)
[14:11] <Jasem[m]> PI3 working fine here with WiFi.. well, I tried other boards but each has its own issues. RPI3 is the most reliable so far despite its shortcomings
[14:11] <ogra_> (only for the inital setup, it is rock solid afterwards ... but pi3 needs to do the setup wired )
[14:11] <Jasem[m]> No USB3, no Gigabit Ethernet
[14:12] <Jasem[m]> From the Embedded Linux presentation, it seems everything around Ubuntu-Core is free.. how does Canonical make any money of that then?
[14:13] <ogra_> services, support, contracts with device manufacturers for porting/maintaining an image for their HW
[14:14] <Jasem[m]> is there a service for "Here is X, Y, Z software I need. Make them into snaps and give me an image" ?
[14:18] <Jasem[m]> Oh I'll just contact Canonical and find out
[15:00] <mup> PR snapd#2980 opened: client, daemon: move "snap list" name filtering into snapd <Created by chipaca> <https://github.com/snapcore/snapd/pull/2980>
[15:07] <mup> PR snapd#2981 opened: tests: add kernel-module-control interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2981>
[15:23] <joedborg> is there any reason why snapcraft doesn't stage hidden files?
[15:23] <joedborg> as in it seems to explicitly seems to ignore them
[15:48] <mup> PR snapd#2944 closed: interfaces/builtin/alsa: add read access to alsa state dir <Created by ssweeny> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2944>
[15:49] <ssweeny> thanks jdstrand
[15:50] <jdstrand> ssweeny: np
[16:10] <SuperJonotron> running into an odd issue here with snaps, done this a thousand times before but just rebuild a snap with two commands, both show up in the binary and if I navigate to that directory and call them by name ./snapName.command it says no such file or directory when trying to run
[16:11] <SuperJonotron> does this maybe indicate snapcraft created a bad snap?
[16:28] <mup> PR snapd#2982 opened: daemon: add desktop file location for app to the API <Created by mvo5> <https://github.com/snapcore/snapd/pull/2982>
[17:31] <cholcombe> i'm giving snappy-debug a try and it cannot connect to log-observe: error: snap "ubuntu-core" has no slot named "log-observe".  Anyone else encountered this?
[17:32] <kyrofa> cholcombe, can you pastebin the output of `snap interfaces`?
[17:32] <cholcombe> sure one sec
[17:32] <cholcombe> kyrofa: http://paste.ubuntu.com/24103211/
[17:32] <cholcombe> this is on an ec2 xenial box
[17:33] <kyrofa> Uh... huh. It says it's connected
[17:33] <cholcombe> lol i know
[17:33] <kyrofa> Does it work now? :P
[17:33] <cholcombe> nope
[17:33] <cholcombe> snap connect snappy-debug:log-observe ubuntu-core:log-observe
[17:33] <cholcombe> error: snap "ubuntu-core" has no slot named "log-observe"
[17:33] <cholcombe> is that the right command?
[17:33] <kyrofa> Ohhh
[17:33] <kyrofa> cholcombe, no, it's only core now
[17:33] <kyrofa> cholcombe, in fact, you can leave the last arg off completely
[17:33] <cholcombe> oh ok
[17:33] <kyrofa> cholcombe, just run `snap connect snappy-debug:log-observe`
[17:33] <cholcombe> yeah that works now
[17:34] <kyrofa> cholcombe, ooo, gluster, that sounds like fun
[17:34] <cholcombe> kyrofa: gluster has a new iscsi manager that i'm trying out
[17:34] <cholcombe> i might even be bold and snap gluster
[17:35] <cholcombe> the daemon is hanging when i start it and i'm not sure what's going on.  maybe strace will tell me something
[17:36] <cholcombe> oh maybe this doesn't fork.  i must've misread the C code
[17:37] <kyrofa> Hahaha
[17:37] <kyrofa> So it's actually working?
[17:37] <cholcombe> i'm not certain.  i'm messing around with it
[17:37] <cholcombe> strace says it's waiting on futex
[17:39] <cholcombe> kyrofa: yeah i think it is working
[17:39] <cholcombe> looks like i need targetcli and some other crap.  need to rebuild the snap
[17:39] <ogra_> snap "ubuntu-core" ?????
[17:39] <ogra_> you shouldnt have that at all
[17:40] <kyrofa> ogra_, probably referring to out-of-date docs
[17:40] <ogra_> everyone should have been moved from ubuntu-core to core nowadays
[17:40] <ogra_> kyrofa, well, it is in the error message above
[17:41] <kyrofa> ogra_, because it's not intelligent
[17:41] <kyrofa> $ sudo snap connect foo:bar baz:qux
[17:41] <kyrofa> error: snap "foo" has no plug named "bar"
[17:41] <ogra_> oh
[17:41] <ogra_> silly !
[17:41] <kyrofa> Agreed
[17:41] <ogra_> add AI !!!!!
[17:41] <cholcombe> kyrofa: if gluster-blockd needs to access targetcli do i need an interface for that?
[17:42] <kyrofa> cholcombe, are they in separate snaps?
[17:42] <cholcombe> i'm not sure if targetcli is snapped.  i could just apt install it
[17:43] <kyrofa> cholcombe, is that something that should be contained within the snap?
[17:43] <cholcombe> hmm.  i'm guessing not
[17:44]  * kyrofa isn't sure what targetcli is
[17:45] <cholcombe> kyrofa: it's a python program that configures iscsi initators
[17:45] <kyrofa> cholcombe, think about it this way. If someone installs your snap on a clean install of Ubuntu, what's going to happen?
[17:45] <kyrofa> cholcombe, you can't depend on a deb
[17:45] <cholcombe> then yeah targetcli's python script will be missing
[17:45] <kyrofa> cholcombe, so an interface isn't going to help you here
[17:45] <cholcombe> and tcmu-runner whatever that is.  it's also complaining about that
[17:46] <kyrofa> Oh man. Out of coffee before 10am. This will not be a good day
[17:46] <cholcombe> ah crap tcmu-runner is another C program i need to snap
[17:47] <cholcombe> so yeah i guess i should package this all together
[17:47] <kyrofa> Yeah I think so
[17:47] <kyrofa> cholcombe, just consider what happens if someone installed your snap alongside, I dunno, the ceph snap that also bundles those things (let's assume). Will it still work okay?
[17:48] <cholcombe> i'm not sure
[17:48] <cholcombe> ceph will likely also want iscsi targets
[17:48] <cholcombe> it's unlikely they'll both be on the same machine but you never know
[17:49] <kyrofa> Yeah it doesn't really change what you need to do (just bundle them), just something to keep in mind
[17:49] <cholcombe> ok
[19:21] <mup> PR snapcraft#1169 closed: tests: update the ftp source for integration test <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1169>
[19:51] <mup> PR snapd#2983 opened: Support spread testing with proxy <Created by nuclearbob> <https://github.com/snapcore/snapd/pull/2983>
[20:27] <kyrofa> jdstrand, within a snap, /tmp used to be unique to each app
[20:27] <kyrofa> jdstrand, is that no longer the case? i.e. is the same /tmp/ shared across apps in the same snap?
[20:27] <kyrofa> jdstrand, I guess it was specific to the instantiation, huh
[20:28] <kyrofa> jdstrand, but has that changed?
[20:31] <jdstrand> kyrofa: /tmp is shared across commands in the same snap
[20:32] <kyrofa> jdstrand, do you remember when that change was introduced? Or was is all snap-confine?
[20:32] <jdstrand> kyrofa: all commands share the same mount namespace. this is part of the reason why the snap-update-ns exists
[20:32] <jdstrand> kyrofa: iirc it was snap-confine 1.0.43
[20:32] <kyrofa> jdstrand, wonderful, that really simplifies some things
[20:36] <jdstrand> snap-update-ns issue*
[20:46] <cholcombe> kyrofa: gluster-blockd makes a unix socket in /var/run/gluster-blockd.socket.  If i want to access that from a user space program do i need to do anything special?
[20:46] <cholcombe> i guess i'm asking which way the confinement goes.
[20:47] <kyrofa> cholcombe, gluster-blockd is the thing you're trying to snap? And "a user space program" is outside of snaps?
[20:47] <cholcombe> correct
[20:47] <cholcombe> can user space programs access that socket or does it go both ways and i have to be in the snap to access it?
[20:47] <kyrofa> cholcombe, you wouldn't need to do anything special from the user-space point of view, but I don't think a confined snap can place something directly in /var/run
[20:47] <cholcombe> ok
[20:48] <cholcombe> yeah i'm still in dev mode
[20:48] <kyrofa> cholcombe, for the most part, you're not running a chroot (ala docker or lxd)
[20:48] <cholcombe> ok
[20:49] <kyrofa> cholcombe, well, I guess that's not quite right nowadays
[20:49] <kyrofa> cholcombe, you're essentially chrooted into the core snap with stuff from the system bind-mounted in
[20:49] <cholcombe> i see
[20:50] <cholcombe> that's what i thinking
[20:50] <cholcombe> so if i stay in classic of dev mode i'm good to go.  but if i go strict i'm going to have issues with that unix socket
[20:51] <kyrofa> cholcombe, indeed. If strict you'll need to put that somewhere the snap can actually write
[20:51] <cholcombe> yeah
[21:03] <cholcombe> coreycb: for https://github.com/open-iscsi/tcmu-runner/blob/91d23191f97937bb92c19cc73565c8ea73c3cc7e/CMakeLists.txt do you know how to set LIBNL_LIB in the snapcraft.yaml?
[21:07] <coreycb> cholcombe, it looks like you can set environment variables in snapcraft.yaml - https://bugs.launchpad.net/snappy/+bug/1583259
[21:07] <cholcombe> kyrofa: looks like tcmu-runner wants me to drop files into /etc/dbus-1/system.d
[21:07] <mup> Bug #1583259: Snappy needs to influence environment variables in applications  <snap-desktop-issue> <verification-done> <Canonical Click Reviewers tools:Fix Released by jdstrand> <Snappy Launcher:Invalid> <Snapcraft:Fix Released by sergiusens> <Snappy:Fix Released> <click-reviewers-tools
[21:07] <mup> (Ubuntu):Fix Released> <click-reviewers-tools (Ubuntu Xenial):Fix Released> <click-reviewers-tools (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1583259>
[21:07] <kyrofa> cholcombe, so it needs the systemd dbus eh? That sounds like an interface
[21:07] <cholcombe> coreycb: cool thanks for
[21:08] <cholcombe> kyrofa: like i need to write an interface or i just make use of one?
[21:09] <kyrofa> cholcombe, I'm not quite sure. I've successfully avoided dbus in snaps so far, so I don't have experience to fall back on here. jdstrand can probably help you more
[21:09] <cholcombe> ok
[21:10] <jdstrand> cholcombe: take a look at the dbus interface and specify 'bus: system'. that will give you the dbus policy in /etc/dbus-1/system.d
[21:10] <cholcombe> jdstrand: ok
[21:10] <jdstrand> cholcombe: if that interface isn't enough for you, you will need to a new interface
[21:10] <jdstrand> to write*
[21:11] <cholcombe> jdstrand: ok i'll take a peek in a minute
[21:11] <jdstrand> cholcombe: https://github.com/snapcore/snapd/wiki/Interfaces#dbus
[21:12] <cholcombe> this is prob a silly question but when i'm building snapcraft packages are all the dependencies being apt installed on my local system or are they in a chroot?
[21:12] <kyrofa> cholcombe, no silly questions here :)
[21:12] <cholcombe> :)
[21:12] <kyrofa> cholcombe, it actually depends
[21:12] <kyrofa> cholcombe, which depedencies are we talking about? How are they specified?
[21:13] <cholcombe> i guess the question is should i building in a lxc container
[21:13] <cholcombe> anything i say as build dependencies
[21:13] <cholcombe> i'm wondering if i'm polluting my desktop with tons and tons of dev packages
[21:13] <kyrofa> cholcombe, yep. build-packages are installed on the host
[21:13] <cholcombe> ok
[21:13] <kyrofa> cholcombe, stage-packages aren't-- they're unpacked right into the snap
[21:13] <cholcombe> hmm alright
[21:14] <kyrofa> cholcombe, indeed, every snap I personally build is in a new lxc container
[21:14] <cholcombe> yeah i was wondering :D
[21:14] <cholcombe> i need to start doing that
[21:14] <kyrofa> cholcombe, is also ensures that I determine ALL dependencies
[21:14] <cholcombe> exactly
[21:39] <pmcgowan> kyrofa, does a configure hook run before or after connecting interfaces
[21:39] <kyrofa> pmcgowan, neither, there are new hooks being written for that (called interface hooks)
[21:40] <kyrofa> pmcgowan, oh wait, do you mean when installing?
[21:40] <pmcgowan> kyrofa, well I mean in general
[21:40] <kyrofa> pmcgowan, the configure hook won't run when you use `snap connect/disconnect`
[21:40] <pmcgowan> I just added a configure hook to my snap and now the content interface is not really connecting
[21:40] <kyrofa> pmcgowan, interesting, that shouldn't affect anything there
[21:41] <kyrofa> pmcgowan, do you get an error?
[21:41] <pmcgowan> wondering if its related before I back off
[21:41] <pmcgowan> no error
[21:41] <kyrofa> So helpful :P
[21:41] <pmcgowan> just that I should connect the interface
[21:41] <pmcgowan> whih shows connected
[21:41] <pmcgowan> kyrofa, I will back up and see then
[21:41] <kyrofa> Huh... not sure what's happening there
[21:44] <Pharaoh_Atem> wtf
[21:44] <Pharaoh_Atem> why is 2.23 not 2.23?
[21:44] <Pharaoh_Atem> the snapd 2.23 tagged in git doesn't match what I expect it to be
[21:44] <Pharaoh_Atem> it's ~14 days old
[21:45] <pmcgowan> kyrofa, oy, I removed the hook and it works again
[21:45] <pmcgowan> enough for friday
[21:46] <kyrofa> pmcgowan, haha, okay, well ping me Monday then, happy to dig into that with you
[21:46] <pmcgowan> kyrofa, k have a good weekend
[21:46] <kyrofa> pmcgowan, you too!
[21:53] <cholcombe> kyrofa: think you could take a quick peek at this? http://paste.ubuntu.com/24104552/  i'm trying to build the targetcli python part
[21:53] <cholcombe> it seems to build correctly and then fail
[21:54] <cholcombe> i can paste my snapcraft.yaml also
[21:55] <cholcombe> http://paste.ubuntu.com/24104562/


[06:53] <Xarlock> hello
[06:54] <Xarlock> would anyone mind helping me set up my screen res.?
[06:54] <Xarlock> i'm stuck in 800x600 its not good
[09:34] <con> hi can anyone tell how the mentoring system works?


[01:58] <daftykins> well well
[01:58] <daftykins> i've been calling my 6 x 1TB RAID5 an old dog for a while now
[01:58] <daftykins> sure enough one disk tonight has just rellocated two sectors
[01:58] <daftykins> most disks have a power-on hours statistic at 6 years :)
[06:20] <foobarry> morning internet people
[06:23] <foobarry> so...next wave of phishing will be heartbleed "reset your password" ohish attempts...
[06:57] <mapp> morning
[06:57] <mapp> hah yea most likely foobarry :)
[09:06] <brobostigon> morning boys and girls.
[10:26] <foobarry> what do people usually use as their 2nd factor when using lastpass?
[10:27] <MartijnVdS> app on phone?
[10:29] <foobarry> AKA google auth.
[10:29] <foobarry> yubikey is premium only
[10:29] <foobarry> https://helpdesk.lastpass.com/security-options/multifactor-authentication-options/
[10:32] <popey> foobarry: yeah, yubikey
[10:33] <popey> and i pay because I want to support lastpass
[10:36] <isleofmandan> Hello. Quick Q - has anyone flashed Ubuntu on a Galaxy Nexus?  It seems to have finished whatever it was doing. Rebooting now...
[10:41] <foobarry> nose will not stop running last few days. think its hayfever season announcing itself
[10:42] <foobarry> ooo nice aston martin outside my house
[10:42] <isleofmandan> popey - and it seems to have worked. Yay!
[10:56] <popey> foobarry: i got put _on_ to laspass when some other site was hacked and i had to reset 100+ passwords in a day
[11:07] <foobarry> neighbours look like they are having an open day to flog their house
[11:08] <foobarry> hence the steady stream of flashy cars and overbuilt men. wonder why it's attracting those types
[11:08] <foobarry> we're not a flashy area
[11:21] <bigcalm> !ding
[14:29] <foobarry> !ping
[15:29] <popey> bug 1306970
[15:31] <popey> can anyone else confirm that on 14.04?
[15:57] <Azelphur> popey: did you tag that as security vuln?
[15:57] <Azelphur> just out of curiosity
[15:59] <popey> not till someone confirms it
[17:38] <penguin42> popey: It's interesting, I've seen the problem at the login screen - I just had that where I couldn't get focus on the password
[17:40] <penguin42> popey: Which apps have you had it leak to - or is it any?
[18:30] <mapps> evening
[18:36] <SuperEngineer> #1 cook brussels sprouts
[18:37] <SuperEngineer> #11 forget cooking brussels sprouts
[18:37] <SuperEngineer> #120 goto burn brussels spouts
[18:38] <SuperEngineer> #200 goto print OH Bugger!
[18:42] <penguin42> probably best thing you can do with a brussel
[18:43] <mapps> heh
[18:43] <mapps> i like sprouts
[18:43] <DJones> Sprouts are outstanding, shame they're not eaten more often
[18:44] <SuperEngineer> +1 to support for sprouts
[18:46] <SuperEngineer> Sprouts - the Ubuntu of the veg world ... soooo underated ;)
[18:46] <SuperEngineer> [but easily burnt if negleted...
[18:47] <DJones> SuperEngineer: Steam them
[18:47] <SuperEngineer> ...update your sprouts as soon as poss folks!
[18:48] <SuperEngineer> darn... forgot about the possibilty of submitting them Steam !
[18:48] <SuperEngineer> *to Steam
[18:48] <DJones> Ah well, just enjoyed some pan fried kangaroo steak, was surprised at how soft the meat was
[18:49] <SuperEngineer> DJones: please don't say it tasted like bouncy chicken... heard that one b4
[18:49] <DJones> I won't
[18:49] <SuperEngineer> ;)
[19:03] <penguin42> popey: Only key I've managed to pass through here is Alt seems to do some stuff to System Settings menu if I have it open under the lock, but I've not managed to get any letter keys through
[20:02] <directhex> my god, our bedroom is approaching the land of "tidy"
[20:20] <brobostigon> organised chaos, directhex ?
[20:28] <directhex> brobostigon, organised un-chaos!!!
[20:28] <brobostigon> oh dear,
[20:31] <directhex> clutter being disposed of!
[20:31] <directhex> dusting in places we've never dusted since moving in!
[20:33] <brobostigon> :)
[20:36] <penguin42> heck, what's bought this on?
[20:37] <directhex> penguin42, turning the bedroom into a sex dungeon! can't get dust on the leather!
[20:37] <directhex> er, i mean, being tired of living in a hellhole
[20:38] <brobostigon> lol.
[20:39] <penguin42> directhex: tasteful fresian leather I assume
[20:44] <directhex> hot pink, as found in all the classiest sex clubs
[22:50] <popey> Ircing in the  curry house
[22:55] <penguin42> Haskell with NaNs?
[23:06] <popey> mmmm curry


[00:09] <ochosi> btw, i set the vertical offset for the shadow because the light source is "from above" in our theme
[00:15] <ochosi> time for bed
[00:42] <bluesabre> thanks for the tip ochosi, this feels a lot more Greybird: http://paste.ubuntu.com/7889923/
[00:42] <bluesabre> Unit193: thoughts?
[00:51] <bluesabre> https://i.imgur.com/QIwZ84y.png    Left: xfwm4 compositor, Right: compton
[01:12] <Unit193> Er, I was supposed to respond.  Uhhh, sure?
[01:13] <bluesabre> I thought you used compton, so thought I bounced it off you :)
[01:13] <Unit193> Heh, nooope.  I tried it a bit before trusty was released.
[01:13] <bluesabre> ah
[01:13] <bluesabre> :D
[01:14] <Unit193> Installing.
[01:15] <Unit193> (That's why it was hard to find some config for it, purged and deleted.)
[01:15] <bluesabre> got it
[01:15] <Unit193> We'll see if this also fixes the xfwm4 glitches.
[01:16] <Unit193> Wow, lag in Skype.
[01:17] <Unit193> Hrm, it's actually when you minimize all windows, and pull one up again.  Something to do with the desktop.
[01:17]  * bluesabre cannot test performance-related things, everything works well
[01:20] <Unit193> https://github.com/chjj/compton/blob/master/src/compton.c#L5175 handy.
[01:22] <bluesabre> oh good, I hate cluttering $HOME
[01:23] <Unit193> I dislike cluttering home and /etc/skel/ ;)
[01:42] <Unit193> Reminds me, ToZ had a good point on .Xdefaults and xscreensaver.Dialog.borderWidth
[01:44] <ToZ> I did?
[01:44] <bluesabre> this sounds familiar
[01:44] <bluesabre> have the link?
[01:49] <Unit193> 02/#xubuntu-devel.2014-02-19.log.gz:20:53:12 < ToZ> should I create a bug report to suggest a cosmetic change to the xscreensaver unlock dialog (change is actually to /etc/skel/.Xdefaults from xubuntu-default-settings) to remove the white border?
[01:49] <Unit193> 02/#xubuntu-devel.2014-02-19.log.gz:20:57:37 < ToZ> set "xscreensaver.Dialog.borderWidth:        0" - gets rid of the thick white border
[01:50] <ToZ> ...and there it is.
[01:58] <bluesabre> :)
[01:58] <Unit193> ToZ: I've use it, it is nicer.
[01:58] <Unit193> s/I've/I/
[02:07] <bluesabre> just tested, muuuuuch nicer
[02:23] <Unit193> bluesabre done be on a roll.
[02:24] <bluesabre> :)
[02:24] <Unit193> But, shouldn't you consult your visual aid? ;)
[02:24] <bluesabre> so I noticed that the Settings Menu appears above the other menus in whisker (hierarchy and all that)
[02:25] <bluesabre> so, wondering if I should add the Settings Manager launcher back and have the Settings menu in alphabetical order with the others
[02:26] <bluesabre> thoughts?  Seems least invasive that way
[02:26] <bluesabre> and only a tiny bit repetitive for classic menu users
[02:30] <Unit193> Putting  Settings Manager then a seperator makes sense for the classic menu users though.
[02:32] <bluesabre> ok, think I've decided on a good setup
[02:33] <bluesabre> :)
[02:33] <Unit193> Explain?
[02:35] <bluesabre> https://i.imgur.com/VAbLGmt.png
[02:36] <bluesabre> works well with both menus this way
[02:37] <Unit193> Will have to get used to it, but makes logical sense.
[02:38] <bluesabre> somebody will complain, but ui freeze isn't until september ;)
[02:40] <Unit193> It'd be great to get more feedback from people, but I'm +1 for this.
[02:40] <Unit193> bluesabre: May be more than needed, but what do you think about before/after of whisker+classic and propose at the next meeting?
[02:41] <bluesabre> Well, next meeting is in a few hours, so fine by me :)
[02:43] <bluesabre> whisker: https://imgur.com/52N8SmP
[02:52] <bluesabre> added to agenda
[02:58] <bluesabre> time to go pick up wife/wait in car for an hour
[02:58] <bluesabre> be back tomorrow
[03:02] <Unit193> Hahaha. :D  Have fun.
[03:20] <Unit193> bluesabre: While we're at it, could list other changes made at the meeting, but I won't be there. :P
[07:07] <elfy> bluesabre: some [info] for meeting
[07:07] <elfy> image testing is moribund
[07:07] <elfy> so is package testing
[08:22] <Unit193> bluesabre, ochosi: Debian #756359 (Not for seeding, but nevertheless).
[09:43] <ochosi> hey folks, would you mind if we postpone the meeting 30mins? gotta take someone to the trainstation...
[09:43] <bluesabre> ok, fine by me
[09:44] <bluesabre> btw, we already have clutter in xubuntu, abiword pulls it
[09:44] <ochosi> woot?
[09:44] <ochosi> that's absurd...
[09:44] <bluesabre> :D
[09:45] <ochosi> well "lucky" us i guess, we can use the parole clutter backend "for free" :p
[09:45] <ochosi> but still, this seems just like another reason to get rid of abiword
[09:45] <bluesabre> Unit193: yeah, only requires the installation of gstreamer1.0-clutter, 111 kb
[09:46] <ochosi> (or can it be built without clutter?)
[09:46] <bluesabre> woops
[09:46] <ochosi> :)
[09:46] <ochosi> pinging Unit193 is always a good idea
[09:46] <bluesabre> didn't mean to write that to Unit193, was going to send something else
[09:46] <bluesabre> :D
[09:46] <bluesabre> but forgot
[09:46] <ochosi> :}
[09:59]  * skellat is ready for meeting
[10:00] <doubleplusgood> Wow right on the number
[10:00] <bluesabre> nice skellat
[10:01] <bluesabre> I think we might wait a few minutes for ochosi if that's ok?
[10:01] <skellat> Okay
[10:01] <skellat> It'll be probably my first meeting in 2014 to attend
[10:05] <bluesabre> congrats :)
[10:09] <sh4tr> have you experienced scroll lag+high cpu/xorg ?
[10:10] <bluesabre> I haven't noticed anything of the sort recently
[10:10] <doubleplusgood> Somewhat, but I think that was compton.
[10:11] <brainwash> xubuntu 14.10?
[10:12] <brainwash> bluesabre: so we can close bug 1349056 now?
[10:12] <brainwash> according to the last comment
[10:13] <brainwash> or is some fixing needed?
[10:14] <doubleplusgood> I think so
[10:14] <bluesabre> That might need some fixing actually
[10:15] <bluesabre> ochosi, eric_the_idiot ^
[10:15] <doubleplusgood> Although, I just tried it on my laptop and it gave me a black screen...
[10:16] <bluesabre> doubleplusgood, please see the "Other Info, #3" section of this bug report https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1326740
[10:19] <doubleplusgood> bluesabre: Fixed
[10:20] <doubleplusgood> bluesabre: Thanks
[10:20] <bluesabre> :)
[10:23] <doubleplusgood> Is there any development on xfwm's compositor?
[10:25] <brainwash> not really, ali1234 was doing some experiments some months ago
[10:26] <bluesabre> !team | meeting in 4 minutes
[10:30] <bluesabre> #startmeeting Xubuntu Community Meeting
[10:30] <meetingology> Meeting started Tue Jul 29 10:30:35 2014 UTC.  The chair is bluesabre. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[10:30] <meetingology> Available commands: action commands idea info link nick
[10:30] <bluesabre> !team | Meeting time
[10:30] <bluesabre> So, who's here?
[10:30] <skellat> o/
[10:30] <doubleplusgood> Here
[10:31]  * knome is lurking a bit
[10:32]  * bluesabre hasn't guided one of these meetings in a while
[10:32] <knome> good luck ;)
[10:32] <knome> you basically need #topic, #subtopic, #action and #info
[10:32] <bluesabre> yup
[10:33] <bluesabre> ochosi should be back shortly
[10:33] <bluesabre> #topic Open action items
[10:35] <bluesabre> #info xubuntu packageset has been updated with the packages we ship, so uploads should be simpler now
[10:36] <bluesabre> #info gstreamer1.0-clutter is the only additional package if we ship parole with a clutter backend
[10:36] <skellat> #info The "split theme package" bug may subside after the recent QA upload for shimmer-themes but catching duplicates has to be done manually.
[10:36] <knome> any news/progress on getting the list of packageset packages to the wiki?
[10:36] <bluesabre> I think ochosi followed up on that one
[10:38] <bluesabre> oh wait, we did not make progress on that
[10:38] <knome> :)
[10:39] <bluesabre> but I think ochosi did "bluesabre to set up a page on the ubuntu-wiki collecting apps that potentially need a pkexec profile and send an email to the list to get users to contribute to the list "
[10:39] <skellat> Which relates to the gksu issue
[10:39] <bluesabre> #action bluesabre to put list of xubuntu packageset packages on wiki
[10:39] <meetingology> ACTION: bluesabre to put list of xubuntu packageset packages on wiki
[10:41] <bluesabre> #nick slickymaster
[10:42] <bluesabre> #info slickymaster wrote a draft for "things to do after a 12.04 to 14.04 upgrade"
[10:45] <bluesabre> I guess we can move on to updates now
[10:46] <bluesabre> #topic Team updates
[10:47] <ochosi> sorry for being late
[10:47]  * ochosi took JPohlmann to the train
[10:47] <bluesabre> #info new packages in utopic: xfce4-power-manager, xfwm4
[10:47] <bluesabre> hey ochosi
[10:47] <bluesabre> wb
[10:47] <ochosi> ty, and hey everyone
[10:48] <skellat> #info From overwatch on bugs, there has been a small effort to try to treat design decisions as bugs and patch them away
[10:48] <skellat> #info Such bugs that have attempted to re-open design decision have been flagged as opinion for now
[10:49] <skellat> At least when I catch them
[10:49] <bluesabre> Thanks for that :)
[10:49] <ochosi> #info xfwm4 tabwin needs small theme updates/tweaks, ochosi has local patches for that already
[10:50] <ochosi> (things look okayish by default though)
[10:50] <bluesabre> yeah
[10:51] <ochosi> question re: clutter
[10:51] <ochosi> what other packages would be pulled in if we decided to get rid of abiword at some point?
[10:51] <skellat> What would we ditch abiword in favor of?
[10:51] <ochosi> i mean: what packages would be pulled in/needed by parole other than gstreamer1.0-clutter
[10:51] <ochosi> skellat: i guess nothing
[10:52] <ochosi> skellat: but anyway, let's not go there *now*, i just wanna know in case ;)
[10:52] <skellat> Okay
[10:52] <knome> let's talk about the abiword replacing later
[10:52] <knome> (i mean, in this meeting..)
[10:53] <ochosi> sure, why not
[10:53]  * skellat would run rdepends if he wasn't sitting at a Debian Jessie ARM box at the moment
[10:53] <bluesabre> yeah, we'll have plenty for Discussion today :)
[10:53] <ochosi> bluesabre: hm, so would you happen to know or shall we investigate that later? (or are you investigating now? :D)
[10:54] <bluesabre> ochosi: looks like this, gstreamer1.0-clutter libclutter-1.0-0 libclutter-1.0-common libclutter-gtk-1.0-0
[10:54] <bluesabre> possibly more
[10:54] <ochosi> right
[10:54] <bluesabre> but I can send the current file listing in utopic to see what is *currently* installed
[10:55] <bluesabre> we can review that later
[10:55] <ochosi> well i guess as long as we keep abiword it's a no-brainer to add the clutter backend
[10:55] <bluesabre> do we want to move to Announcements?
[10:55]  * bluesabre always feels like team updates and announcements are the same
[10:56] <ochosi> yeah, i kinda agree
[10:56] <bluesabre> #topic Announcements
[10:56] <bluesabre> #info Xubuntu 14.04.1 released last week, good job everyone!
[10:57] <ochosi> +1
[10:57] <bluesabre> ochosi: are we participating in alpha2, or only betas this cycle?
[10:57] <ochosi> iirc only betas
[10:58] <bluesabre> ok, thought so when I checked our calendar
[10:58] <bluesabre> anybody else have any announcements?
[10:58] <ochosi> #info Xfce has made some progress towards new development releases that we will most likely want to pick for 14.10
[10:59] <ochosi> btw, how does that micro-release exception work exactly wrt that ^ ?
[10:59] <bluesabre> We've been picking them as they are released :)
[10:59] <bluesabre> with the MRE, not entirely sure
[10:59] <bluesabre> since big changes happen with dev releases
[10:59] <ochosi> well i'm thinking 14.04
[10:59] <bluesabre> and we are running on top of 4.11 in 14.04
[11:00] <bluesabre> I assume the usual rules apply
[11:00] <ochosi> yeah, that is true for a few of those releases...
[11:00] <bluesabre> with regard to interface freeze, etc
[11:00] <ochosi> right, i guess i have to look up what MRE is about exactly at some point
[11:00] <bluesabre> yeah
[11:00] <bluesabre> discussion time?
[11:01] <ochosi> +1
[11:01] <bluesabre> #topic Discussion
[11:01] <bluesabre> #subtopic Default IRC client
[11:01] <bluesabre> I'm still not sure we have a clear direction with this yet
[11:02] <ochosi> me neither
[11:02] <bluesabre> However, I did find yesterday that Mint switched from xchat to hexchat
[11:02] <knome> i don't think we ever will, we just need to make a decision
[11:02] <knome> what would you guys think of the following:
[11:02] <skellat> Mint does not equal *buntu
[11:02] <ochosi> yeah, probably a vote
[11:02] <knome> drop xchat for 14.10
[11:02] <ochosi> skellat: sure, but it means maintenance/attention usually
[11:03] <knome> see what the feedback is like
[11:03] <ochosi> yeah, somehow i'm all for experimenting a bit in the upcoming cycle
[11:03] <knome> if the feedback is people want an IRC client, consider including xchat/hexchat for 15.04
[11:03] <ochosi> and point ppl to pidgin meanwhile
[11:03] <knome> yep
[11:03] <bluesabre> that sounds good to me
[11:04] <skellat> +1
[11:04] <ochosi> yup, same here
[11:04] <knome> as i've said in the ML, pidgin is a fairly good IRC client for people who IRC only occasionally
[11:04] <ochosi> yeah, and it's a consequent move after getting rid of gthumb
[11:04] <knome> yep
[11:04] <knome> streamline
[11:04] <ochosi> yup
[11:05] <bluesabre> #vote Drop xchat for Xubuntu 14.10
[11:05] <meetingology> Please vote on: Drop xchat for Xubuntu 14.10
[11:05] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname)
[11:05] <ochosi> +1
[11:05] <meetingology> +1 received from ochosi
[11:05] <bluesabre> +1
[11:05] <meetingology> +1 received from bluesabre
[11:05] <knome> +1
[11:05] <meetingology> +1 received from knome
[11:05] <skellat> +1
[11:05] <meetingology> +1 received from skellat
[11:05] <doubleplusgood> +1
[11:05] <meetingology> +1 received from doubleplusgood
[11:05] <bluesabre> nice
[11:05] <bluesabre> #endvote
[11:05] <meetingology> Voting ended on: Drop xchat for Xubuntu 14.10
[11:05] <meetingology> Votes for:5 Votes against:0 Abstentions:0
[11:05] <meetingology> Motion carried
[11:05] <knome> bluesabre, was that a team or public vote?
[11:06] <bluesabre> knome: good question, should have specified
[11:06] <bluesabre> each of the team members present voted in favor of
[11:06] <knome> not that it seems to matter much, both XPL and XTL agreed
[11:07] <knome> but with the current team size, we don't have a quorum ;)
[11:07] <bluesabre> We should go ahead and extend this to the ML
[11:07] <skellat> Back out the vote and throw it to CIVS?
[11:07] <ochosi> bluesabre: we can extend it to the ml, but please add a timeout (1 week should do)
[11:07] <knome> skellat, why would we want to use complex voting methods if we can do a simple vote on the mailing list?
[11:08] <bluesabre> ochosi: want to send that mail?
[11:08] <skellat> knome: Force of habit from LoCo Council so that we had a paper trail to back up what we did
[11:08] <skellat> An external paper trail, that is
[11:09] <ochosi> bluesabre: hm, fine :)
[11:09] <bluesabre> #action ochosi to send mail to ML to vote for dropping xchat for 14.10
[11:09] <meetingology> ACTION: ochosi to send mail to ML to vote for dropping xchat for 14.10
[11:10] <bluesabre> #subtopic Gksu/do
[11:11] <bluesabre> ochosi: did you get a chance to chat with ubuntu-devel folks on this?
[11:11] <ochosi> i did
[11:11] <ochosi> there were some comments about pkexec being superior and gksu being hackery
[11:11] <ochosi> but tbh nothing too-convincing
[11:12] <ochosi> the other thing is though that it doesn't seem hard to add support for pkexec
[11:12] <ochosi> and i guess the list of apps that need it isn't overly long
[11:12] <ochosi> (the hackery concerning e.g. how that pwd-dialog is done etc)
[11:13] <knome> is there any reason not to move to pkexec (apart from the one-off workload) ?
[11:14] <ochosi> well, actually we just fixed a bug wrt pkexec in xfce this weekend (https://bugzilla.xfce.org/show_bug.cgi?id=9373)
[11:14] <bluesabre> at this point, we've carried 2 (or 3) releases without gksu
[11:14] <ochosi> yeah, not too much of an outcry so far
[11:15] <knome> you're not answering my question :P
[11:15] <ochosi> :>
[11:15] <bluesabre> I see no reason to not move to pkexec, other than old habits (gksudo) die hard
[11:15] <ochosi> +1
[11:15] <knome> right, then let's move into it
[11:16] <skellat> I don't see any reason to avoid the shift to pkexec other than we'll have a differing paradigm from other flavours in case people shift to us.
[11:16] <bluesabre> ok
[11:16] <knome> if it's horrible, we can reassess that in 15.04 as well
[11:16] <ochosi> well for the moment it means improving the status quo if we add policy file
[11:16] <ochosi> s
[11:16] <ochosi> so i'd go for this incremental improvement and see whether it helps
[11:16] <bluesabre> indeed
[11:16] <ochosi> anything from the docs-side on this?
[11:17] <ochosi> is gksu/do part of the docs? is pkexec mentioned at all?
[11:17] <bluesabre> I think gksu parts of the docs were removed, right?
[11:17] <knome> there was some work done on it
[11:18] <knome> since david is away, you can assign a work item for me to check our situation
[11:19] <bluesabre> #action knome to check docs side of including pkexec policy files in favor of gksu
[11:19] <meetingology> ACTION: knome to check docs side of including pkexec policy files in favor of gksu
[11:19] <bluesabre> good?
[11:19] <knome> yep
[11:19] <bluesabre> cool
[11:19] <bluesabre> #subtopic Xfce bug bounty program
[11:20] <ochosi> #info ochosi has helped to set up a bug bounty programme on bountysource.com for Xfce
[11:21] <ochosi> i think it would be good to support that by informing people
[11:21] <ochosi> we can discuss whether we want to directly put some of our funds on bugreports a bit later
[11:21] <ochosi> but the first step should be to put out a blog-post on x.org, g+, fb, twitter, well all the usual suspects basically
[11:22] <knome> #action marketing team to support xfce's bug bounty programme by informing people on website and social media
[11:22] <meetingology> ACTION: marketing team to support xfce's bug bounty programme by informing people on website and social media
[11:22] <ochosi> would be very cool if i wouldn't be the only one doing it
[11:22] <knome> #nick makreting
[11:22] <knome> #nick marketing
[11:22] <ochosi> cause i'm already handling a lot of that upstream at xfce
[11:22] <knome> ochosi, be in touch with the marketing team (eg. me and pleia2) and talk about that, and things will get done
[11:22] <ochosi> ok, ty
[11:23] <bluesabre> #subtopic Trello and Blueprints
[11:23] <bluesabre> "Discuss how to continue with Trello and blueprints and evaluate how things are going so far. Also: should the Trello board be public?"
[11:24] <bluesabre> So far, I think Trello works well. Makes it easy to find and keep up with task items
[11:24] <ochosi> yup
[11:24] <ochosi> i think it should be public though
[11:25] <ochosi> i don't remember who brought that up earlier (maybe it was in bluesabre's application for upload-rights?)
[11:25] <skellat> Yeah, Scott Kitterman brought it up then
[11:25] <ochosi> but i don't see any reason to keep this private, since bps are also public
[11:25] <bluesabre> Yeah, it should be public.
[11:26] <knome> my concern is that when we are using trello, the blueprints aren't kept up-to-date
[11:28] <ochosi> well i guess in the long run the question is whether to s/blueprints/trello/
[11:28] <ochosi> but yeah, we've had that problem of not up-to-date blueprints in previous cycles
[11:28] <ochosi> and using trello "on the side" this cycle certainly hasn't contributed to mitigating that situation
[11:28] <bluesabre> I don't think I'd want to get rid of blueprints
[11:29] <knome> yes, trello is okay, but then we shouldn't use blueprints at all
[11:29] <knome> the pro for blueprints is that they are always up-to-date regarding bugs linked to them
[11:29] <knome> and when they are linked to the status tracker, it's very easy to get an up-to-date overview of the progress
[11:30] <knome> of course you need to keep the manually added work items in the blueprints up-to-date as well
[11:30] <knome> but with trello, you have to keep the trello board updated
[11:30] <knome> the work items,
[11:30] <knome> the bugs
[11:30] <knome> and in addition there are no good overview stats
[11:31] <skellat> One keeps us more firmly grounded within the Ubuntu ecosystem, one does not.  Where do we stand is the question we have to consider in the end.
[11:31] <knome> i don't think that's the core question
[11:31] <ochosi> knome: yup, i agree. the best thing (imho) would be to improve launchpad :>
[11:31] <knome> the core question is what works best with the team
[11:32] <knome> i mean, many teams have stopped using blueprints already
[11:32] <ochosi> but since that's not likely to happen, i guess we have to see what we can live with
[11:32] <knome> i prefer the method we used for the reasons stated above
[11:32] <ochosi> the sluggishness of launchpad is quite a downer, but yeah, it has all those pros that you mentioned
[11:32] <knome>  but i'm fine with trello
[11:32] <skellat> knome: True.  How have our Kubuntu colleagues managed the use of Trello and the use of Launchpad?
[11:33] <ochosi> skellat: they exclusively use trello
[11:33] <knome> whatever we decide to do, we should make it clear for possible new members what and how we are using
[11:33] <knome> and describe the process
[11:33] <skellat> knome: Agreed
[11:34] <knome> so what's the evaluation on trello so far?
[11:34] <ochosi> i personally like it
[11:34] <ochosi> it's quite snappy an the overview it provides works well for me
[11:34] <ochosi> it's less statistical than status.ubuntu thoug
[11:34] <ochosi> h
[11:35] <bluesabre> It works well for having an overview of what everyone is doing without jumping between blueprints and bug reports
[11:35] <knome> bluesabre, what about the overview page of the status page?
[11:35] <ochosi> yeah, the jumping between blueprints is a bit annoying, because they're so slow in usage
[11:35] <knome> http://status.ubuntu.com/ubuntu-t/group/topic-t-flavor-xubuntu.html
[11:35] <bluesabre> I find that I don't know where most things are on launchpad
[11:36] <ochosi> knome: for me, that one is a bit cluttered. i mean it's really comprehensive but too much
[11:36] <bluesabre> this is a super helpful page, but I would not know how to get here without your link
[11:36] <knome> i partly agree
[11:36] <ochosi> the simplicity is what i prefer there with trello
[11:36] <ochosi> so yeah, as i said, i'd prefer to improve on the existing infrastructure actually
[11:36] <knome> bluesabre, ehm, go to the main page: http://status.ubuntu.com/ubuntu-t/ and click the xubuntu link
[11:37] <knome> links are obviously for T, because U hasn't been set up
[11:37] <knome> that page also always has links to the blueprints
[11:37] <knome> so you can access those easily as well
[11:37] <bluesabre> and there's that
[11:38] <knome> setting up? that takes 5 minutes
[11:38] <bluesabre> right
[11:38] <bluesabre> but we haven't done it yet
[11:38] <knome> if *that's* the reason what's keeping us from using launchpad, i'll promise to do that every cycle
[11:39] <knome> bluesabre, well, yeah, because i didn't get any questions about it from ochosi until i asked him a few days ago whether we were going to set it up altogether
[11:39] <bluesabre> that's cool, but I think that's the problem with launchpad
[11:39] <knome> what then?
[11:40] <knome> things not setting up automatically?
[11:40] <bluesabre> too many links, too much content
[11:40] <knome> was the trello board set up magically?
[11:40] <ochosi> i kinda agree with bluesabre there, the learning curve for launchpad is really different from trello and the likes
[11:40] <knome> i understand and can agree
[11:40] <Noskcaj> Did i just miss a meeting or something?
[11:40] <ochosi> it took me ages and lots of energy to slowly start using it
[11:40] <ochosi> Noskcaj: we're still in the middle
[11:41] <knome> but it's really a crap argument that "it's too hard to set it up, boo hoo" when it takes 5 minutes
[11:41] <Noskcaj> I'm here for ~5 mins
[11:41] <bluesabre> right, that's not my argument
[11:41] <knome> right,
[11:41] <knome> now when the cycle was beginning
[11:42] <knome> i was told we were going to use both trello and blueprints to see how they work and which works better
[11:42] <knome> obviously i gathered that wrong, because we've mostly been using trello
[11:42]  * bluesabre just needs to collect all his bookmarks to navigate launchpad
[11:42] <bluesabre> I might be the only one with this issue :)
[11:42] <knome> you don't need the bookmarks really
[11:42] <knome> you only ned the main blueprint link
[11:43] <knome> or the status.u.c link
[11:43] <knome> (for the blueprint stuff, that is)
[11:43] <skellat> pad.lv truly helps too
[11:43] <knome> i'm not saying people shouldn't have problems perceiving that.
[11:43] <ochosi> skellat: what's that?
[11:43] <skellat> ochosi: The Launchpad-specific link shortener
[11:44] <bluesabre> but yeah, I agree that trello has been getting updated more frequently than the blueprints
[11:44] <bluesabre> and that is probably because its easier to use and everything is always in front of you
[11:44] <ochosi> sure, that's mostly a fact
[11:44] <knome> well the comparison is obviously flawed because the blueprints aren't set up the way they are supposed to
[11:44] <ochosi> (i mean the less frequent updates)
[11:45] <knome> and when we decided to use... well, "both", i asked whether people would be up for that
[11:45] <knome> and everybody was like "sure!"
[11:45] <knome> well, now we see it
[11:45] <knome> we really can't use BOTH
[11:45] <bluesabre> yeah
[11:45] <ochosi> knome: the only thing lacking in the bps is the link to status.ubuntu though, right?
[11:45] <knome> if we aren't using blueprints, let's not even register them then.
[11:45] <knome> ochosi, yeah, and people updating them
[11:46]  * skellat throws out the ridiculous suggestion of somebody building a bridge using launchpadlib between trello and lp
[11:47] <knome> ochosi, i don't think you can do a fair comparison between the two during one cycle, because keeping them both up-to-date means almost double the work
[11:47] <knome> ochosi, and people are always going to prefer either or
[11:48] <bluesabre> Do we want to continue this discussion a bit later to finish up the meeting?  Or we can create some action items?  I'll need to leave for work shortly
[11:48] <skellat> I need to bow out too
[11:49] <knome> i don't think we're going to find a resolution with this group of people anyway
[11:49] <ochosi> sounds sane
[11:49] <bluesabre> yeah
[11:49] <knome> just wanted to raise my concerns
[11:49] <ochosi> well personally i don't have that many blueprints anyway
[11:49] <ochosi> so for me it's not so much work to keep both updated
[11:49] <knome> ochosi, work item?
[11:49] <knome> ochosi, you personally, but
[11:49] <ochosi> knome: that too, but i also am only involved in two blueprints
[11:50] <knome>  [unit193] Propose a new installable metapackage, xubuntu-core: INPROGRESS
[11:50] <knome> isn't that done?
[11:50] <ochosi> i know that it's different with others
[11:50] <knome> i don't think Unit193 has many items either
[11:50] <bluesabre> #action team to continue discussion using Trello, Blueprints
[11:50] <meetingology> ACTION: team to continue discussion using Trello, Blueprints
[11:50] <ochosi> should be, it's in xubuntu-meta but i don't know whether it's uploaded
[11:50] <knome> i'm not blaming anybody, i'm just saying that it isn't working
[11:50] <bluesabre> It's uploaded
[11:50] <skellat> #nick team
[11:50] <knome> besides the work item is "propose", that's surely done
[11:50] <bluesabre> :)
[11:51] <ochosi> :]
[11:51] <knome> just pointing out
[11:51] <bluesabre> Unit193 ^
[11:51] <ochosi> knome: fine, let's send a grumpy email to the ml pointing team members towards updating their blueprints
[11:51] <ochosi> we can figure out the status.ubuntu thing later
[11:51] <ochosi> (maybe not today, but one of these days)
[11:51] <knome> also,
[11:52] <knome> let me say this one last thing:
[11:52] <knome> since you say launchpad is so hard to use
[11:52] <knome> and trello is easy
[11:52] <knome> why do we need to have "notes"/"help" cards in the trello main view to help people use trello?
[11:52] <knome> no need to answer, just wanted to point that out.
[11:53] <bluesabre> #subtopic Merged Settings menu in Whisker and classic menu
[11:53]  * ochosi has never looked at those
[11:53] <bluesabre> https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1310264
[11:53] <knome> ochosi, i never looked at the launchpad documentation... :P
[11:53] <bluesabre> So, I've updated the menu files in xubuntu-default-settings, want to get more feedback
[11:53] <bluesabre> https://i.imgur.com/52N8SmP.png
[11:54] <bluesabre> https://i.imgur.com/VAbLGmt.png
[11:54] <bluesabre> In the classic menu, I've made the Settings menu its own item, do we want to keep this, or how would we like to continue?
[11:54] <ochosi> that looks excellent to me
[11:54] <ochosi> i think we've had this setup previously in the classic menu
[11:54] <bluesabre> yeah
[11:55] <ochosi> it's a good fallback and with our default whisker it'll be a nice improvement
[11:55] <ochosi> bluesabre: btw, that looks as if some icons were not 16px in that menu
[11:56] <ochosi> if you could check and let me know which ones, i'll try to fix that in our icon-theme
[11:56] <skellat> I like the new look
[11:56] <bluesabre> ok, so if we agree to this, I can push that today
[11:56] <ochosi> please do so
[11:56] <knome> yep, looks good
[11:57] <bluesabre> We also have a few other changes in the next xubuntu-default-settings, if I can get some quick feedback
[11:57] <ochosi> sure
[11:57] <bluesabre> https://bazaar.launchpad.net/~xubuntu-dev/xubuntu-default-settings/trunk/view/head:/debian/changelog
[11:58] <bluesabre> I did a bit of tidying based on comments in the past
[11:58] <ochosi> not sure what the 20px thing is about, but the rest is fine
[11:58] <bluesabre> 1. Removed the huge white border from xscreensaver, we don't use it anymore, but it does make it look much more attractive
[11:58] <ochosi> ok
[11:58] <ochosi> then i'm +1 on that
[11:59] <ochosi> the battery-plugin will maybe be renamed to xfpm-plugin (because the brightness plugin has been merged in)
[11:59] <ochosi> but adding it to the panel is good
[11:59] <bluesabre> Also added a reasonable config for compton which mimics our current xfwm compositor
[11:59] <ochosi> don't forget to take indicator-power out of the seed
[11:59] <bluesabre> yup, that's committed
[11:59] <bluesabre> just gotta update meta
[11:59] <ochosi> or, if we still seed it (so that we have power-indicator in the greeter/lockscreen) we need to hide it in the indicator-plugin
[12:00] <ochosi> i've been testing the compton config on two different setups now and it looks and feels good. this is probably the first time i'm satisfied with compton, so nice work on that :)
[12:00] <bluesabre> cool
[12:01] <knome> ;)
[12:01] <bluesabre> so that's that for xubuntu-defualt-settings
[12:01] <bluesabre> #action bluesabre to upload new xubuntu-default-settings
[12:01] <meetingology> ACTION: bluesabre to upload new xubuntu-default-settings
[12:01] <ochosi> great
[12:01] <ochosi> thanks a bunch bluesabre
[12:01] <bluesabre> #subtopic Parole's clutter backend
[12:02] <bluesabre> #info Abiword already pulls clutter, so parole only adds gstreamer1.0-clutter (111 kb)
[12:02] <bluesabre> #info With the clutter backend, parole works correctly even in virtualbox
[12:03] <bluesabre> #info performance for clutter is less than xv, but better than just X
[12:03] <bluesabre> So, what do we want to do?
[12:03] <ochosi> i'm personally in favor of enabling it
[12:03] <ochosi> same as with the xchat decision, i'm for trying this in 14.10
[12:04] <ochosi> we can revisit it in 15.04 (or even before the release) if there are some terrible unforeseeable drawbacks
[12:04] <bluesabre> With enabling it, do we want to set it as default as well?
[12:04] <bluesabre> knome: any thoughts, for or against?
[12:05] <knome> 14.10 is a non-LTS release so it's the perfect place to test new things
[12:05] <ochosi> i guess by setting it as default, it would get quite a bit of testing
[12:05] <ochosi> since totem also uses it by default, i don't see a huge problem there
[12:06] <ochosi> we should document that though somewhere
[12:06] <knome> another option is to ask Unit193 to build a custom ISO
[12:06] <knome> and get that testing
[12:06] <ochosi> yeah, if it's only about that one package, i suggest we just go ahead with it
[12:07] <knome> just make sure the final assessment if it works or not happens early enough to be able to revert the change
[12:07] <bluesabre> of course :)
[12:07] <ochosi> i guess enabling by default is a thing for x-d-s anyway
[12:07] <bluesabre> right
[12:07] <ochosi> so the first step of adding it in parole is definitely fine
[12:07] <knome> i know it is an obvious thing, but we've been too late before ;)
[12:08] <ochosi> knome: true, but this time we actually have an uploader ;)
[12:08] <ochosi> bluesabre: so yeah, i'm +1 on both (add, default)
[12:09] <bluesabre> ok, I'll make these changes today
[12:09] <knome> ochosi, yeah yeah
[12:09] <knome> ;)
[12:09] <ochosi> thanks again bluesabre
[12:09] <bluesabre> #action bluesabre to enable clutter in parole, set as default in xubuntu-default-settings
[12:09] <meetingology> ACTION: bluesabre to enable clutter in parole, set as default in xubuntu-default-settings
[12:09] <bluesabre> Anything else we want to discuss?
[12:10] <ochosi> nothing from my side at this point
[12:10] <bluesabre> knome, skellat?
[12:10] <skellat> I'm good
[12:10] <knome> i guess dropping abiword
[12:10] <knome> but we can do that later
[12:11] <bluesabre> ok
[12:11] <ochosi> hmright
[12:11] <bluesabre> #subtopic Schedule next meeting
[12:11] <bluesabre> Who's next?
[12:12] <knome> pleia2,
[12:12] <bluesabre> #action pleia2 to schedule next meeting
[12:12] <meetingology> ACTION: pleia2 to schedule next meeting
[12:13] <bluesabre> #endmeeting
[12:13] <meetingology> Meeting ended Tue Jul 29 12:13:19 2014 UTC.
[12:13] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/xubuntu-devel/2014/xubuntu-devel.2014-07-29-10.30.moin.txt
[12:13] <bluesabre> *phew*
[12:13] <knome> thanks bluesabre
[12:13] <bluesabre> thanks guys
[12:13] <ochosi> thanks bluesabre :)
[12:13] <skellat> Thank you bluesabre
[12:13]  * bluesabre heads to work
[12:13] <bluesabre> bbl
[12:13] <ochosi> i gotta go too, have a nice day everyone!
[12:14] <knome> you too
[12:32] <elfy> well that was tldr
[12:32] <elfy> why is there a   * ''Vote:'' Drop xchat for Xubuntu 14.10 (Carried) on the logs
[12:33] <elfy> should that not go to the mailing list
[12:33] <knome> didn't undo the vote, but it'll be on the mailing list shortly
[12:33] <elfy> thanks
[12:41] <elfy> seen it
[15:47] <edmael> Hi!
[15:48] <edmael> I'm trying to hack some Xfce component but I'd like to understand how they're compiled on Xubuntu and what make or autogen options are used. Is there a simple way to check this? On Arch I used to check the PKGBUILD and it's pretty simple, I wonder if there's a similar way.
[16:59] <edmael> Hi
[16:59] <elfy> hello
[16:59] <edmael> I'm trying to compile Xfce-panel, but I get this error and I can't understand why: :~/Developement/xfce4-panel$ ./autogen.sh --sysconfdir=/etc --libexecdir=/usr/lib --disable-static --enable-gio-unix --localstatedir=/varxdt-autogen: You must have "glib2" installed. You can get if from
[16:59] <edmael>              ftp://ftp.gtk.org/pub/gtk/.
[17:00] <knome> edmael, do you have the development libraries for glib2 installed?
[17:00] <edmael> developement libraries for glib2? Where can I find them?
[17:00] <knome> in the repositories...
[17:00] <edmael> I've got the Xfce developement libraries installed
[17:01] <edmael> $ sudo apt-get install gli
[17:01] <edmael> glibc-doc                 glib-networking-dbg       glines
[17:01] <edmael> glibc-doc-reference       glib-networking-services  glipper
[17:01] <edmael> glibc-source              glib-networking-tests     gliv
[17:01] <edmael> glib-networking           glide2-bin
[17:01] <edmael> glib-networking-common    gliese
[17:01] <eric_the_idiot> apt-get build-dep xfce4-panel  should pull in the required packages for building the panel
[17:01] <knome> edmael, please
[17:01] <knome> edmael, do not paste multiline pastes on the channel
[17:02] <edmael> Sorry knome
[17:02] <knome> apt-cache search glib2: libglib2.0-dev - Development files for the GLib library
[17:03] <knome> (if you insist using command line...)
[17:04] <edmael> I still get an error. Maybe it's cause I'm using Xubuntu 14.10? It tells me that libglib2.0-dev depends on libglib2.0-0 (= 2.41.1-2) but the version 2.41.2-1~ubuntu1 is going to be installed (and then it stops).
[18:22] <Unit193> knome: Yeah, that is rather my fault, I didn't update the BP.
[18:22] <knome> Unit193, that's not the point, but thanks for keeping it up-to-date ;)
[18:24] <Unit193> I would have gotten the trello card, had Sean not already done so. :D  And yeah, know it's not the point, but still.
[18:25] <knome> just proves my point
[18:27] <Unit193> http://paste.openstack.org/show/8s4GUZ7RFQyOfgH1zEvq latest Xubuntu stats.
[18:28] <Unit193> Eh, trello is more handy to get to the dang specs for sure...
[18:54] <Unit193> !info qtmir utopic
[18:55] <Unit193> https://launchpad.net/ubuntu/+source/qtmir
[19:31] <ochosi> knome, pleia2: lemme know when we can talk about promiting bountysource for xfce – or whether there is actually a need for that
[19:31] <ochosi> i guess what we want is pretty obvious, i.e. promote the programme on all our "channels"
[19:31] <elfy> evening ochosi
[19:32] <ochosi> hey elfy
[19:32] <ochosi> how's it going?
[19:32] <elfy> ok thanks :)
[19:33] <ochosi> good to hear
[19:33] <elfy> tried to read the meeting logs - tldr, read the summary instead
[19:33] <ochosi> i guess bluesabre didn't have time to put up the minutes, as he had to leave immediately after the meeting
[19:33] <ochosi> it took a bit longer than anticipated
[19:34] <elfy> Unit193: so - I'd say that we need to test install of it, what it gives you - eg less than normal but enough
[19:34] <elfy> ochosi: yea I noticed :p
[19:35] <knome> ochosi, i'm mostly off tomorrow and thursday
[19:36] <ochosi> knome: yeah, i'm actually also travelling around in the country and have meetings
[19:36] <ochosi> is the beginning of next week or even the weekend more realistic for you?
[19:36] <elfy> Unit193: mmm - so it just appears to be doing nothing now it's downloading bits
[19:36] <elfy> oh
[19:37] <elfy> kernel module problem
[19:37] <Unit193> Yeah, I had initramfs problem...
[19:37] <elfy> ok
[19:37] <Unit193> (Told it to continue anyway, we'll see.)
[19:37] <elfy> so it's not something we can write up and get people to just test yet then
[19:38] <elfy> ploughing on for the moment :p
[19:39]  * ochosi didn't know elfy had a plough
[19:39] <elfy> yep
[19:39] <elfy> and a horse to pull it :)
[19:40] <ochosi> lucky you!
[19:40] <elfy> I wish
[19:41] <Unit193> elfy: So, does it look to be installing stuff it shouldn't?  It may be "Expert Command-line install" that we need if so.
[19:42] <elfy> no it looks like it's installing the right stuff
[19:43] <elfy> retrieving partman etc atm
[19:52] <elfy> Unit193: so it doesn't find the vbox drive ...
[19:56] <elfy> and the install option for me gets the same no kernel module found thing
[19:57]  * elfy gives up for the night
[20:00] <Unit193> Well, mine worked, but I had to use the caret option so I'm remembering wrong it seems. :P
[20:00]  * Unit193 can't remember which gives tasksel.
[20:00] <elfy> I don't get that far ...
[20:01] <ochosi> Unit193: remember to document that stuff ;)
[20:01] <elfy> are you using 32bit or 64 bit - not that it should make a difference
[20:01] <Unit193> ochosi: https://sigma.unit193.net/~unit193/core.html
[20:01] <Unit193> elfy: 32.
[20:01] <ochosi> Unit193: yeah, that was just re: "remembering wrong" ;)
[20:02] <Unit193> ochosi: Oh no, my memory is terrible, I know this well. :D
[20:02] <ochosi> hehe
[20:02] <ochosi> good good
[20:03] <elfy> Unit193: forget that - I picked Install :D
[20:03] <Unit193> ochosi: http://www.youtube.com/watch?v=dZLAlceZ2qo
[20:03] <Unit193> elfy: That was my next try, thanks.
[20:04] <elfy> well up to now everything has failed on kernel modules and not finding them
[20:04] <elfy> and I think it is going to do the same again
[20:05] <elfy> http://www.zimagez.com/zimage/screenshot-290714-210529.php
[20:06] <elfy> so I've had the same on every option and tried 32 and 64 bit
[20:06] <ochosi> Unit193: will look as soon as that video from openshot has finished exporting
[20:06] <ochosi> (so tomorrow maybe)
[20:06] <Unit193> elfy: I'm also using us.
[20:07] <elfy> gb archives here
[20:07] <elfy> giving up for now
[20:09] <ochosi> awwh
[20:36] <Unit193> So, it seems to have worked.  Anything you want me to check, ochosi, knome?
[20:36] <knome> was?
[20:37] <Unit193> Is?
[20:38] <Unit193> I did a mini+Command-line install and have a desktop.  Not sure if there's anything you want me to test?
[20:39] <knome> can't come up with any ideas right now
[20:39] <knome> ask me again on friday/saturday
[20:47] <knome> nighty ->
[23:42] <CajunTechie2> Hello everyone. Quick question: how does someone go about becoming a formal member of the Community team? If this isn't the place to ask, please point me in that direction. Thanks!


[08:10] <jaminkle> can you guys help me with a kernal panic i am getting when i boot or should i ask in #ubuntu
[08:11] <abogani> jaminkle: #ubuntu is a better place for that type of questions
[08:12] <jaminkle> ;[
[16:54] <zul> rtg: is the universe kernel build system for intrepid up somewhere?
[16:55] <amitk> zul: BenC was going to propagate teh tree...
[16:55] <amitk> *the
[16:55] <zul> amitk: ah ok
[17:00] <BenC> depends on what you mean by universe
[17:00] <BenC> if you mean ports (a la sparc), then yes...if you mean universe as in binary-custom out-of-tree builds, then no
[17:01] <BenC> well, ports wont be universe, so you can't possibly mean that :)
[17:06] <zul> the binary-custom build thingies :)