[01:31] <Unit193> https://bugs.launchpad.net/ubuntu/+source/xfce4-indicator-plugin/+bug/1237552 sure doesn't contain much...
[01:39] <brainwash> ??
[01:40] <Unit193> Not much debugging to go on.
[01:41] <brainwash> the main report is marked as private
[01:41] <Unit193> Someone in another channel just hit it.
[01:41] <Unit193> Oh bah, it didn't tell me that bit, just the helpless "Are you lost?"
[01:42] <brainwash> you need to be the maintainer or member of bug control :/
[01:43] <brainwash> so it happened in trusty?
[01:45] <Unit193> Saucy, 0.5.0 still.
[01:47] <brainwash> oh, funny thing is, I was able to crash thunar today and apport redirected me to a private report
[01:47] <Unit193> Able to view it?
[01:47] <brainwash> that's somehow not that helpful
[01:47] <brainwash> nope
[01:48] <Unit193> Yep, dumb.
[01:49] <brainwash> somehow I get the feeling that there are tons of private reports on launchpad
[01:50] <brainwash> like dark matter in the universe
[01:50] <brainwash> :D
[01:50] <Unit193> Well, you're going for bug control, right?
[01:50] <Noskcaj> brainwash, something like 50% of all bug reports from what i've seen
[01:50] <brainwash> wow
[01:51]  * Unit193 wonders if that's why lp is so slow. :P
[01:51] <brainwash> Unit193: yes, I'll try
[01:51] <Unit193> ...From what I
[01:51] <Unit193> 've seen you just set to triaged and make it public. :P
[01:52] <Noskcaj> Unit193, after checking the stacktraces, yes
[01:53] <Unit193> Mhmm, suuure they do. :P
[01:54] <brainwash> Noskcaj: so I've managed to build gnome-system-tools for my testing ppa, but I had to use quilt, dch, debuild and so on
[01:54] <brainwash> isn't there a direct way for bzr -> ppa?
[01:54] <brainwash> one that works
[01:54] <Unit193> Eww, bzr.
[01:54] <Noskcaj> Unit193, Eww, git
[01:54] <Noskcaj> ;)
[01:55] <Unit193> git++
[01:55] <brainwash> svn for the old skool heads
[01:55] <Noskcaj> no, cvs for old school
[01:56] <brainwash> oh, not familiar with cvs
[01:57] <Noskcaj> bzr to ppa is what th recipes are meant to do, but they're a pain to make work
[02:00] <brainwash> I will do some research to get it working
[02:00] <brainwash> or at least understand how it works and what exactly is needed
[02:01] <Unit193> Meh, recipies aren't too hard.
[12:47] <bluesabre> brainwash: there are some tricks for recipes, need a hand?
[12:47] <bluesabre> actually fixing some recipes this morning
[12:50] <brainwash> bluesabre: I'll have to read the manual first, only tried to build gnome-system-tools via a generic recipe and it failed due to the missing patch integration I think
[12:50] <brainwash> thought that it would manually convert the bzr commit into a patch file or something like that
[12:51] <bluesabre> oh, shouldn't have to do that
[12:51] <bluesabre> https://help.launchpad.net/Packaging/SourceBuilds/BzrBuilder
[12:51] <bluesabre> you'll probably have to create your own debian/rules to do the custom builds steps
[12:51] <brainwash> ah, that looks interesting
[12:52] <bluesabre> so, for example
[12:52] <bluesabre> I have this recipe
[12:52] <bluesabre> https://code.launchpad.net/~lightdm-gtk-greeter-team/+recipe/lightdm-gtk-greeter-daily-trusty-gtk2
[12:52] <bluesabre> which uses this custom debian
[12:52] <bluesabre> https://code.launchpad.net/~smd-seandavis/lightdm-gtk-greeter/trusty-debian-gtk2
[12:53] <bluesabre> probably have to edit debian/control too since the pre-build steps will probably require gnome-common and other packages
[12:53] <brainwash> mmh, but the greeter does not have any debian/patches
[12:54] <bluesabre> if it did, they would just get applied pre-build
[12:55] <brainwash> ok, I'll test it again, shouldn't be that complicated to fix it :)
[12:55] <brainwash> thanks
[12:55] <bluesabre> good luck
[12:56] <brainwash> can we fix the pending issues for mugshot? https://bugs.launchpad.net/ubuntu/+source/mugshot
[12:56] <bluesabre> yeah, on my todo list for this weekend
[12:57] <bluesabre> all of my daily builds have been failing for a while, trying to resolve those before anything else
[12:57] <brainwash> for all your apps?
[12:58] <brainwash> only noticed the greeter build failures
[12:58] <bluesabre> most of them.  Mainly because I removed the native packaging from all the python apps
[12:58] <bluesabre> so bzr-dailydeb is like, ok what do I do with this?
[12:59] <bluesabre> mugshot's been failing
[12:59] <bluesabre> menulibre is pointing at the wrong branch
[12:59] <bluesabre> >.>
[12:59] <bluesabre> none of the stable ppas have been updated for a while
[13:00] <bluesabre> except the greeter, but only for trusty
[13:00] <bluesabre> I've been slacking
[13:00] <bluesabre> or something :)
[13:01] <brainwash> did people complain?
[13:01] <bluesabre> nope
[13:01] <bluesabre> nobody notices
[13:01] <bluesabre> they just don't get updates
[13:01] <bluesabre> :)
[13:01] <brainwash> "where is my daily update?!"
[13:01] <brainwash> :D
[13:02] <bluesabre> :)
[13:02] <bluesabre> it might also be because I haven't made any release announcements
[13:02] <bluesabre> going to spend tomorrow doing those
[13:04] <bluesabre> also, gotta help satya get gtk-theme-config to support translations
[13:04] <bluesabre> suppose I should do that first
[13:04] <brainwash> it's a python app, right?
[13:05] <bluesabre> vala
[13:05] <bluesabre> so, gotta learn a bit too
[13:05] <brainwash> vala seems like a great modern language
[13:05] <bluesabre> I should start porting some apps to vala soon
[13:06] <bluesabre> easy to read, compiles to C
[13:06] <brainwash> python -> vala?
[13:06] <bluesabre> for some apps anyway
[13:06] <bluesabre> like mugshot would benefit most likely
[13:06] <brainwash> it would? how?
[13:06] <bluesabre> small apps should have small footprints
[13:06] <bluesabre> python brings some weight
[13:07] <brainwash> you mean the extra dependencies?
[13:07] <bluesabre> during runtime
[13:07] <brainwash> or runtime
[13:07] <brainwash> oh
[13:07] <bluesabre> ochosi was complaining that light-locker-settings consumes more memory than xfce4-settings :)
[13:08] <bluesabre> its a tradeoff.  Python can be quickly developed and it does everything great
[13:08] <brainwash> but that's also gtk3 vs gtk2, or?
[13:08] <bluesabre> that, but mainly python's memory consumption
[13:09] <bluesabre> I'll never port menulibre or catfish for instance, too script-like, python is a perfect match
[13:10] <bluesabre> but for something like the xfce4-keyboard-overlay, that would definitely be better as a compiled language
[13:11] <bluesabre> so I'll be porting the work I've done for that to vala
[13:11] <bluesabre> https://launchpad.net/xfce4-keyboard-overlay/trunk
[13:11] <brainwash> but it can be still done in python and work fine =S
[13:11] <bluesabre> definitely
[13:12] <bluesabre> but it can be faster and lighter
[13:13] <bluesabre> I freaking love python, but there are some things better for other languages
[13:13] <bluesabre> like parole, for instance
[13:13] <bluesabre> though, it would be easier to fix its bugs if it were python :)
[13:14] <brainwash> yes, you can easily apply changes and debug it
[13:14] <brainwash> and it's easy to read most of the time
[13:14] <bluesabre> yup, its great for rapid app development
[13:15] <bluesabre> and for prototyping too
[13:15] <bluesabre> if I can't figure something out in C, I try it in python first
[13:26] <bluesabre> neat
[13:26] <bluesabre> https://wiki.gnome.org/Projects/Vala/GameDevelopmentSeries/Setup
[13:32] <brainwash> ^ ah dammit, another thing I have to learn/try
[13:32] <brainwash> so much to learn :)
[13:36] <Unit193> Though, it seems the interest for it died dow a lot.  Isn't the new, hip one Go?
[13:37] <GridCube> but is not unity promoting vala?, i might not be up to date tho
[13:42] <bluesabre> vala is the goto thing for Unity, Gnome, and elementary
[13:43] <bluesabre> even some xfce projects use vala
[13:43] <bluesabre> some = at least one
[13:43] <Unit193> But upstream doesn't even like C++, right?
[13:43] <bluesabre> yeah, C is where its at
[13:44] <bluesabre> I don't like C++ anymore, I think the syntax is ugly
[13:48] <bluesabre> but yeah, Go is exploding in popularity currently
[13:49] <bluesabre> or thats how it seems from my G+
[13:57] <bluesabre> I'm guessing the installer hasn't been fully translated yet...
[13:57] <bluesabre> http://imagebin.org/297910
[13:59] <bluesabre> I like the new slides
[14:00] <GridCube> P: bluesabre why you installing in spanish?
[15:07] <bluesabre> GridCube: I've got to test some things in something other than english
[15:07] <bluesabre> spanish is my most fluent second
[15:07] <GridCube> :D
[15:07] <Unit193> Meaning you can read 3 words?
[15:25] <bluesabre> at this point, more or less
[15:26] <bluesabre> I took spanish courses for 7 years
[15:26] <bluesabre> been out of school for 2 years
[15:26] <starrats> I need some help please.
[15:26] <bluesabre> its running away from me
[15:27] <bluesabre> I've gotta run, but go ahead and ask your question starrats and somebody should be able to help
[15:28] <brainwash> starrats: please ask your question then
[15:28] <starrats> my pointer still occasionally sticks/frozen when i turn on 14.04 and I tried to do somehting about and I accidentally 'disabled the pointer and now i can't get on 14.04 at all, is there a way i can fix it or ?
[15:29] <starrats> do I have to re-install the 
[15:29] <starrats> the distro
[15:30] <brainwash> re-installing would be the cleanest solution
[15:30] <bluesabre> maybe the compositor?
[15:30] <brainwash> the login greeter still works fine?
[15:30] <starrats> okay, just stick the disk in the tray and makesure that it's the one being read at time of boot
[15:31] <Unit193> Could remove the config from .config/, though don't think it'd fix the sticking.
[15:31] <starrats> yes the login greeter, if you mean that thing that swirls on the 'xubuntu blue screen' yes it works
[15:32] <Unit193> No, where you type your password to login.
[15:32] <starrats> no that doesn't work
[15:33] <starrats> I didn't make it work that way, no password to get on the desktop it just went there
[15:34] <starrats> when i first loaded the disk, if i re-install I will be having a password to login
[15:34] <starrats> right now I'm on VBox again
[15:38] <starrats> I'm just going to re-install the 14.04 disc and start afresh
[19:24] <Unit193> I'm going to shoot whoever came up with the submit bug links. >_<
[19:28] <Unit193> Heeey, I typed the right UUID!  Can't confirm before submitting. :/
[20:56] <brainwash> ali1234: still working on the thunar segfault?
[20:56] <ali1234> not really
[20:56] <ali1234> i don't know what else to do unless you've got some clues
[20:58] <brainwash> so a not needed/false unref is causing this?
[20:59] <ali1234> there could be many caused
[20:59] <ali1234> that's one of them
[20:59] <ali1234> another is allocating with g_slice and freeing with g_free
[21:01] <brainwash> the issue with the slice allocator has started with 13.10
[21:01] <brainwash> and many apps are/were affected
[21:05] <ali1234> yeah.... indicates it's probably in some library
[21:05] <ali1234> what other apps?
[21:06] <brainwash> the terminal (encoding menu)
[21:06] <ali1234> we fixed that one though
[21:06] <brainwash> yes
[21:07] <brainwash> I remember some evolution reports too
[21:07] <ali1234> that's another thing that can cause it... misuse of linked lists
[21:07] <ali1234> basically the slice allocator *replaces* malloc
[21:07] <ali1234> which means all the things that normally would cause random segfaulting now cause a segfault inside of the slice allocator instead
[21:07] <ali1234> that's a pretty wide class of bug
[21:08] <brainwash> sadly
[21:09] <brainwash> so we are only aware of this issue thanks to apport?
[21:09] <ali1234> pretty much
[21:09] <ali1234> errors.ubuntu.com
[21:09] <brainwash> does thunar actually quits?
[21:09] <brainwash> quit
[21:09] <ali1234> i mean you'll always see this type of crash, but we wouldn't know how common it is really
[21:10] <ali1234> lots of reports say it happens when you quit thunar
[21:10] <brainwash> oh, so when things finalize
[21:10] <ali1234> yes, quite likely
[21:10] <brainwash> and memory gets cleaned up
[21:10] <ali1234> so, double free(), wrong type of free()
[21:10] <brainwash> mmh :/
[21:10] <ali1234> the usual stuff
[21:14] <ali1234> there are steps to debug it but i haven't been able to reproduce
[21:15] <ali1234> you can turn off the slice allocator or put it into debug mode - that should catch any problems even if it doesn't actually crash
[21:17] <brainwash> I'll try to reproduce, had a different thunar crash yesterday
[21:17] <brainwash> so I got reminded of this issue
[21:17] <brainwash> mousepad crashed too while reading a big file
[21:18] <brainwash> and all the other reports on the Xfce bug tracker
[21:19] <brainwash> there is so much to fix
[21:19] <brainwash> but want to move forward and switch to gtk3 and wayland
[21:20] <brainwash> we want
[21:23] <ali1234> i don't have much interest in switching to wayland
[21:23] <ali1234> not until there is a sensible abstraction layer for compositors
[21:23] <ali1234> which is probably 2 or 3 years away from happening
[21:30] <brainwash> so X not dead yet :)
[21:42] <ali1234> not for a long long time
[21:45] <ali1234> wayland doesn't form a replacement for it... at all. and neither does mir
[21:51] <andrzejr_> ali1234, one problem with wayland/mir is that they do not want such abstraction layer
[21:51] <ali1234> yes, i know. that's why it will take 2/3 years
[21:51] <andrzejr_> (that's what X is)
[21:52] <ali1234> yes, it is
[21:52] <ali1234> and that's why they can't replace it
[21:52] <andrzejr_> worse, it won't happen at all and we will have DE's and apps written for a specific compositor
[21:52] <ali1234> that will just be like X was, pre-xdg
[21:53] <ali1234> the best thing to do is just refuse to have anything to do with wayland until they create that abstraction layer
[21:53] <ali1234> it doesn't have to be part of wayland
[21:53] <ali1234> it just has to exist
[21:54] <ali1234> and be supported by gnome and kde
[21:54] <ali1234> then i'll consider using it
[21:54] <andrzejr_> slow development and rigidness of X is blessing - otherwise you would see new incompatible ideas popping up everywhere
[22:37] <Unit193> ochosi, Noskcaj: http://packages.qa.debian.org/g/gmusicbrowser.html
[22:37] <Noskcaj> yep
[22:38] <Noskcaj> sync bug up, and alessio is making another upload soon
[23:35] <a5m0> is there a user accessible way to modify the xubuntu installer's cryptsetup to use sha512 instead of sha1?
[23:45] <Noskcaj> a5m0, probably?
[23:59] <a5m0> tried grepping in my iso for cryptsetup but it only found the packages, guess the config is packed