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