#ubuntu-gnome 2013-01-01 <jbicha> darkxst: um, not exactly; the staging ppa is nice because it's a team effort <jbicha> the staging ppa really is prep work for the gnome3 ppa, whereas I see the ricotz testing ppa as a way to get near nightly builds without having to compile it yourself or use jhbuild <ricotz> darkxst, hi, i see you are interested in mozjs187 you might want to give the last g-s/gjs/mozjs packages in ppa:ricotz/staging a try <ricotz> happy new year! <darkxst> ricotz, sure will try them out <darkxst> ricotz, gnome-sushi needs to be rebuilt against js187 <ricotz> darkxst, yes, i know <ricotz> darkxst, are you aware of a newer snapshot than this one from april, or even the creation process of that tarball? <darkxst> ricotz, just looking at that now, since that snapshot did not fix leaks I see <ricotz> ok, thanks <darkxst> just seems to be a couple of minor patches, perhaps we could build directly off the hg branch <darkxst> https://hg.mozilla.org/releases/mozilla-esr17/ <ricotz> darkxst, afaics there are quite some patches which can't be ignored <ricotz> i was hoping they are available somewhere <darkxst> ricotz, library name patches are here https://bugzilla.mozilla.org/show_bug.cgi?id=628723 <ubot5> Mozilla bug 628723 in JavaScript Engine "Create JS 1.8.5 source release" [Normal,Resolved: fixed] <darkxst> you can see everything that was done for the 185 release here https://bitbucket.org/wesgarland/js-1.8.5/ <darkxst> other than that, there were a couple of patches to fix tests, but I can't find them anywhere https://bugzilla.mozilla.org/show_bug.cgi?id=735599#c7 <ubot5> Mozilla bug 735599 in JavaScript Engine "Create JS 1.8.7 source release" [Normal,New] <darkxst> anyway would make more sense to apply the patches as distro patches, since mozilla clearly arent interested in releasing standalone releases anymore <ricotz> thanks <ricotz> yeah, seems to be so <darkxst> ricotz, http://pastebin.com/M7KsJHfS <darkxst> so seems to just be, this with s/5/7, https://bitbucket.org/wesgarland/js-1.8.5/raw/cf58d9c277c7c4f1dc173ebe8814fa300f4abd84/patches/libname-changes.patch <darkxst> and this https://bug735599.bugzilla.mozilla.org/attachment.cgi?id=618606 <darkxst> and the test diff above <darkxst> ricotz, btw this is the branch that the current tarball is based off https://hg.mozilla.org/releases/mozilla-esr10 #ubuntu-gnome 2013-01-02 <ricotz> darkxst, i will try to package a snapshot from esr17 as 1.8.8 <darkxst> ricotz, sure, but gjs still needs some work <darkxst> I can do most of it but stumped on that one thing per bugzilla report <ricotz> yes, this package won't interfere with the current working 1.8.7 <darkxst> ok cool <darkxst> also could update the current esr10 snapshot, have been alot of commits to that branch since the last snapsnot <ricotz> darkxst, did you try to use the current esr10 <ricotz> ah, about to ask that <darkxst> no didnt try, but would be suprised if it dont work <darkxst> the autoconf2.13 thing seems a pain? not sure how to work around that in deb package <ricotz> darkxst, i will create a "proper" tarball <darkxst> ricotz, yeh that is what I did <ricotz> meaning no need to autoconf in rules <darkxst> although I was using jhbuild for the 17esr <darkxst> ricotz, did you sort out the internal headers (from js/src/dist/include) in the deb? (I havent actualy checked, but assume you must have for gjs to build) <ricotz> darkxst, yes, they are installed now <darkxst> ok <darkxst> I know Jasper and owen are quite keen for an updated spidermonkey so the other bits should fall into place, once they are back from holidays <darkxst> ricotz, anyway I'm off to bed, good night #ubuntu-gnome 2013-01-03 <britt__> hey guys <britt__> I just reported bug 1095674 about the gnome-control-center not showing "software-sources" or "ubuntuone" in the Raring dev release <ubot5> bug 1095674 in gnome-control-center (Ubuntu) "Software-Sources and Ubuntuone missing from gnome-control-center in Raring" [Undecided,New] https://launchpad.net/bugs/1095674 <britt__> do any of you have that problem? <jbicha> britt__: that's a feature not a bug <britt__> jbicha why wouldn't we want it to show software sources? <jbicha> those items are still accessible in the Activities Overview <jbicha> if we're trying to be a mostly pure GNOME distro, then we should ship System Settings as close as possible to how GNOME intends <britt__> yeah I saw that, and also within the software center <britt__> I guess, but that is a very "system settings-ish" thing and was very usefull <jbicha> also, Ubuntu One and Software Sources don't integrate right with System Settings as they are external "pop-ups" instead of embedded into the main window <britt__> I gotcha <britt__> so we are running two separate system settings packages now with main ubuntu, one strictly for unity? <jbicha> no, it's one package but it looks different if run from Unity <jbicha> XDG_CURRENT_DESKTOP=Unity gnome-control-center <jbicha> ^ run that to see the other style <britt__> yes but there is a new package in the repos called gnome-control-center-unity that is a dependency of ubuntu-desktop <jbicha> that's currently just the Appearance panel <britt__> gotcha gotcha <britt__> I see the differences <britt__> man my OCD goes crazy when there are things in the application window that are settings specific, and not in system settings <britt__> or in Unity's case, they are in system settings AND the app launcher <britt__> I see the pure-gnome POV, but it fractures the usability a bit <britt__> however it is minor to say the least <jbicha> well GNOME has this mockup: https://live.gnome.org/Design/SystemSettings/Sharing but unforunately I doubt Ubuntu One or Landscape would use it instead of their unique apps <jbicha> while Ubuntu One is cool, the UI doesn't fit with GNOME and the Ubuntu One management seems to have no desire to improve that <britt__> yeah, and they are both qt I believe which breaks away from gtk+ <britt__> which is crap, because the ubuntu-specific-bonuses is the one thing that makes me keep coming back to ubuntu rather than others <jbicha> Software Sources is python+gtk (and it's also accessible from Software Center which is ok too) <britt__> do you know why they are so stuck on the ubuntuone-control panel being so dang ugly? I dont understand why the windows and osx control panels look better than the one designed for ubuntu <britt__> heck the phone versions look better <jbicha> I submitted UI bugs immediately after the Qt version landed in Ubuntu by default but they've been ignored <britt__> yeah you aren't the only one. Omgubuntu has been ranting on it for well over a year <britt__> it is attrocious <britt__> and has NOTHING to do with any of the other themes <britt__> grey dull background, weird rounded corners <jbicha> we might include U1 by default any way (we already ship most of the libraries it needs) <britt__> too bad we cant use the old gtk interface that it used to have <britt__> that one was ok <britt__> better than the new one, albeit less featurefull <britt__> speaking of "by default". Have we made any decision on Libreoffice over abiword and gnumeric? <britt__> opening abiword and libreoffice-word side by side they look nearly identical, though abiword is far far behind <britt__> I either think we include no-default office program, or it be libreoffice <britt__> because it bugs me having to break ubuntu-gnome-desktop meta dependency just to remove it <jbicha> you don't have to break anything, abiword & gnumeric are just recommends <jbicha> britt__: no, ubuntu-standard is the base of Ubuntu (server, Kubuntu, etc), ubuntu-desktop is the one with all of the gnome, unity, firefox etc. dependencies <britt__> hrm <britt__> I was wrong then <britt__> I just remember removing default ubuntu apps and not having them pulled back in on reinstalling ubuntu-desktop <britt__> is there a way they are installed by default but not a ubuntu-desktop dependency? <britt__> I dont know how ubiquity works with installations <jbicha> it might be useful to have a ubuntu-gnome-desktop-extras package but I don't want to be the one maintaining that <britt__> haha <britt__> yeah more work is never good <britt__> I'm just thinking along the lines of trying to get this remix to be an official derivative. And things like would probably add to the credibility of the project <britt__> the work done to differentiate the unity/gnome hybrid components has been fantastic <britt__> if that was you who did that, well don sir <britt__> done* #ubuntu-gnome 2013-01-04 <mcsx3> Good Evening! Everyone. Can anybody here helpme with a little prob? thx. I'm trying to use a ZTE MF180 broadband G3 USB dongle on Unbuntu 12.10. I've found on the Web some solutions, but noone has worked. <darkxst> ricotz, I have gjs building against js188, but still rather broken, patches are here https://www.dropbox.com/s/c4zbelqognlrb2l/gjs188.patches <darkxst> plus you need the 3x RESOLVE_START patches and the other type changes patch from bug 690982 <ubot5> bug 690982 in aikilab.org "there isn't a link to sharism and the sharism logo in the footer" [Medium,Won't fix] https://launchpad.net/bugs/690982 <darkxst> ^gnome.bugzilla even https://bugzilla.gnome.org/show_bug.cgi?id=690982 <ubot5> Gnome bug 690982 in general "Building gjs against spidermoney from firefox 17esr" [Normal,Unconfirmed] <ricotz> darkxst, great! <darkxst> ricotz, great, might be a bit premature, but getting closer atleast. <darkxst> currently trying to fix a segfault in the importer, which makes no sense <darkxst> ricotz, can you rebuild js188 package without stripping debug symbols? <darkxst> obviously I can do it locally, but really at this point in time, the only people using it, are probably going to want the symbols! <ricotz> darkxst, i will add a *-dbg package <darkxst> ricotz, yeh that is fine if its not to much effort <ricotz> an extra package is better since it will be quite large in this case <darkxst> ok <ricotz> only symbols for the shared lib though <ricotz> the static libs will be stripped <ricotz> dbg package 25MB <ricotz> static debug would be +50MB <darkxst> that is fine, I don't think gjs uses the static libraries <ricotz> yes, just saying <ricotz> i want to avoid those additional 50MB <darkxst> yeh fair enough <ricotz> should be there in a bit <darkxst> ok, thanks <gh0st> Again, to recap I just installed Gnome remix. apt-get doesn't work. this is the error:http://paste.ubuntu.com/1496880/ <jbicha> gh0st: um, did you read the error message? <gh0st> I'm not really sure what they mean? <gh0st> jbicha: I get errors even without the proxy. Will upload the error log in a minute <jbicha> it doesn't sound like your errors are specific to the GNOME Remix, there's a lot more people that can give support in #ubuntu <gh0st> jbicha:jbicha: alright. Just one more question . I've extracted the contents of the firefox tar file I downloaded online. To run the firefox executable inside, what do I do? double clicking it like vanilla ubuntu doesn't work. Using terminal produces the following error:http://paste.ubuntu.com/1496982/ <jbicha> why are you trying to use Firefox from a tarball? #ubuntu-gnome 2013-01-05 <britt__> hey guys <britt__> is anyone else having lockup issues on closing windows? <britt__> bug 1094571 was reported in this issue, but it has really gotten bad over the last couple of days <ubot5> bug 1094571 in gnome-shell (Ubuntu) "gnome-shell (or session) continually crashes/locksup when closing any window" [Undecided,Confirmed] https://launchpad.net/bugs/1094571 <britt__> hrm it actually may have been fixed with todays updates #ubuntu-gnome 2013-01-06 <TheLordOfTime> jbicha, how much do you know about packaging <TheLordOfTime> and ubuntu revision numbers for non-security bugs? * TheLordOfTime pokes jbicha <jbicha> the SRU team generally prefers using the same version numbering you'd use for security bugs <TheLordOfTime> jbicha, that's what i thought, thanks. <jbicha> or maybe that's the security team that didn't like my version numbering <TheLordOfTime> :P <TheLordOfTime> i tend to listen to security team numbering <TheLordOfTime> it hasn't killed me yet. :P #ubuntu-gnome 2013-01-07 <darkxst> ricotz, so I think (well hope) almost there getting gjs working wil js188 <ricotz> darkxst, great, so i guess it compiles with failing tests? <darkxst> well sort of, but I know what is causing most of the issues, just waiting on Jasper to get feedback from upstream on that, since the typedefs are a bit retarded. <darkxst> like this 'typedef struct { jsid *_; } JSHandleId;' <darkxst> such that my patches are a bit hacky to make that work #ubuntu-gnome 2013-01-08 <darkxst> ricotz, can you rebuild js188 with e4x enabled <ricotz> darkxst, e4x (xml support) is enabled by default <darkxst> ricotz, hmm ok, well its not working for some reason <ricotz> darkxst, are you forced to replace the current handling to port it? <ricotz> (if this is gjs related) <darkxst> yes gjs related <darkxst> it was removed in 18, so should work in 17 <darkxst> Gio overrides make use of it though <ricotz> ah i see <ricotz> so an alternative is needed (soon) then <darkxst> yes <ricotz> ok, anyway, it is enabled in the 188 build and is suppose to work then #ubuntu-gnome 2013-01-09 <darkxst> ricotz, sorted out the e4x thing <darkxst> and now just failing 1 test <darkxst> gnome-shell runs, albeit with a few minor issues <ricotz> fantastic ;) <ricotz> darkxst, do you have a new patch-stack based on gjs master? <darkxst> ricotz, just rebased and cleaning it up a <darkxst> bit <ricotz> darkxst, oh, i see, take your time <darkxst> ricotz, https://www.dropbox.com/s/gxhzh6qkc3sak92/gjs188-r1.patch <darkxst> might still be a few misplaced hunks but mostly cleaned up. <ricotz> darkxst, thanks <ricotz> just a minor, there are some of those faulty alignments <ricotz> - jsid id, <ricotz> + JSObject **obj, <ricotz> darkxst, #define JSVAL_IS_OBJECT(obj) !JSVAL_IS_PRIMITIVE(obj) <ricotz> this is not the same as the original method <ricotz> it will miss the NULL case <ricotz> meaning NULL will be handled as not an object <ricotz> #define JSVAL_IS_OBJECT(obj) ( JS_IS_NULL(obj) || !JSVAL_IS_PRIMITIVE(obj)) <darkxst> hmm right, I missed that somehow ;) <ricotz> darkxst, are you still seeing tests failing? <darkxst> localeCompare fails <ricotz> assertRaises(function() { "\ud800".localeCompare("a"); }); <ricotz> is suppose to fail <ricotz> so you can ignore those <darkxst> but it aborts the other tests? that doesnt seem right <ricotz> it runs through for me while commenting those two <darkxst> yeh everything else passes, although some things are probably missing tests <ricotz> yes, running g-s is the actual test ;) <darkxst> g-s runs, but not 100% right <darkxst> dash is broken <darkxst> overview search is a bit strange <darkxst> I suspect I could have some JSPropertyOP's somewhere <darkxst> They only segfault if the they use 'id' <darkxst> other wise they just fail silently with priv == NULL <darkxst> ^^could have missed <ricotz> hmm, you should avoid changing the functions interface <darkxst> mozilla changed it <ricotz> typedef JSBool (*JSPropertyOp)( <ricotz> JSContext *cx, JSObject *obj, jsid id, jsval *vp); <ricotz> you are expecting **obj, ... <darkxst> typedef JSBool <darkxst> (* JSPropertyOp)(JSContext *cx, JSHandleObject obj, JSHandleId id, JSMutableHandleValue vp); <ricotz> ah i see <darkxst> the JSHandle* things are pointers rooted objects <darkxst> upstream are planning on changing most of jspai to use them directly <darkxst> but currently onlt the callbacks do <ricotz> ok <darkxst> some way to scan for all callback functions would be nice <ricotz> look for gjs_*et_prop_verbose_stub <ricotz> gjs_add_prop_verbose_stub gjs_delete_prop_verbose_stub <ricotz> jsapi-util.c/h <darkxst> hmm <darkxst> and how to use that? short of plugging it into the class definitions <ricotz> was just looking to similar interfaces <ricotz> i guess i will try to run it later to maybe see some failure outputs <darkxst> maybe could check from within priv_from_js() <ricotz> darkxst, didnt really get to look into it <ricotz> darkxst, it seems to run stable despite the broken dash #ubuntu-gnome 2013-01-10 <darkxst> ricotz, are you seeing focus issues in overview? <darkxst> with my gjs patches? <ricotz> darkxst, hmm, focus issues of what kind? <ricotz> (you probably want to show the patches to Jasper too) <darkxst> ricotz, I can't use the mouse to click anything in overview anymore, but it worked yesterday <darkxst> also alt-tab gets stuck, which also worked yesterday <darkxst> Jasper has looked at my patches <ricotz> mouse in overviewe and alt-tab is working here <darkxst> ok, hopefully something is hosed in my jhbuild <ricotz> your patches with the changed compat OBJECT <darkxst> btw dash is fixed <ricotz> what was it? <darkxst> bug in my JS_NewNumberValue patch <darkxst> have replaced that one with a wrapper <ricotz> ah <brittyboi> have you guys been crashing in Gnome-Shell when closing apps in 13.04 dev? Every 3-4 times I close a window the whole system becomes unresponsive to input <darkxst> brittyboi, nope <brittyboi> hrm <ricotz> brittyboi, try to disable the event-sounds if they are enabled <darkxst> brittyboi, can you get a backtrace <brittyboi> how do I do that? <brittyboi> I can try, but it isn't being reported in ant logs that I can see <ricotz> g-c-c > audio > effects > disable <brittyboi> hold on I'll get you guys the bug number, i'm not the only one <ricotz> i am suspecting your are hitting the eglibc bug triggered by the newer glib <brittyboi> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1094571 <ubot5> Launchpad bug 1094571 in gnome-shell (Ubuntu) "gnome-shell (or session) continually crashes/locksup when closing any window" [Undecided,Confirmed] <brittyboi> I'll try that right now <ricotz> darkxst, could you paste a new patch-set? <darkxst> ricotz, https://www.dropbox.com/s/dipa498sjc5jcm9/gjs188-r2.patch <ricotz> darkxst, thanks! <darkxst> np <ricotz> darkxst, i guess this is missing some parts <ricotz> like the defintion of HAVE_JS_NEWNUMBERVALUE <darkxst> ricotz you need to rerun autogen <ricotz> i did <darkxst> thats there +AC_CHECK_FUNCS(JS_NewNumberValue) <darkxst> check the config.log then I guess <darkxst> although that should fail anyway on js188 <darkxst> since its removed <darkxst> it is #ifndef <darkxst> ricotz, did build fail? <ricotz> ok, but putting JSVAL_IS_OBJECT into it is wrong <ricotz> since you want the opposite here <darkxst> ricotz, no, I am just cheating and using it to detect js188 <ricotz> ah ok <darkxst> it could just as well be #ifndef HAVE_JS_SOMEOTHER_REMOVED_FUNC <darkxst> ricotz, working ok ? <ricotz> not yet <darkxst> ricotz, oh you need to add static back here +JSBool JS_NewNumberValue(JSContext *cx, double d, jsval *rval) (in compat.h) <darkxst> (Jasper told me to remove it ;( ) <ricotz> darkxst, i know this is only one part of the problem <darkxst> what other problem? <ricotz> linking against libgjs <darkxst> ricotz, are you using jhbuild? <ricotz> you should see at least warnings for gjs-console <ricotz> no, i am not <darkxst> oh right <ricotz> while compat.h is a public installed header putting things like #ifndef HAVE_JS_NEWNUMBERVALUE in there <ricotz> doesnt work <darkxst> hmm right <darkxst> but it should be undefined? so why doesnt it work? <darkxst> either way you can just remove the #ifndef <darkxst> oh I suppose its picking up js185 <ricotz> if you have it installed then remove it <darkxst> I am using jhbuild <darkxst> which links explicitly to the mozjs188.pc <ricotz> (i have the 188 headers installed so no js185 headers) <ricotz> note that the header locations are the same <ricotz> try to remove your systems mozjs headers <darkxst> ricotz, I can't do that, I am using them! <ricotz> so you only have 188 around? <darkxst> no I have js188 headers <darkxst> and multiple other libs <darkxst> all off your ppa <ricotz> ok <darkxst> but I am building gjs/g-s from jhbuild <ricotz> alright <ricotz> i think removing the conditional stuff is better <darkxst> ricotz, I basically only added it in at Jaspers request <ricotz> and squash those hunks in the change build version to mozjs188 patch <ricotz> i see <ricotz> seems not optimal to do so <darkxst> whats not optimal? <ricotz> trying to support backward compat in this case <ricotz> the other changes arent compatible either, so why bother to try it for those <darkxst> yeh probably wont happen, given the JSHandleObject/Id stuff <ricotz> darkxst, btw, it is running now for some time <ricotz> without "focus-issues" <darkxst> ricotz, cool, let me know any issues you do see, I think a number of the ones I am seeing are unrelated and that somehow jhbuild has hosed itself (or a broken commit has landed) <darkxst> they seem more like mutter issues really <darkxst> any gotta run, dinner time here <ricotz> darkxst, alright, thanks for your work! <darkxst> np, although it would have been much easier if the changes were actually documented ;) <darkxst> which reminds me, I probably should add these to the wiki page <darkxst> ^mozilla wiki <darkxst> ricotz, http://git.gnome.org/browse/pango/commit/?id=48423ef827f5fcedac92e1e73c29f0bb94eeadda <darkxst> can you update that? <ricotz> darkxst, why? <ricotz> i hope this new fontconfig will get into raring though <darkxst> pango depends on it <darkxst> well I will just revert that commit for now <ricotz> it just depends on it to make the tests happy <ricotz> darkxst, i guess i can upload it to my staging ppa <darkxst> well it seemed to build ok, after reverting that commit <ricotz> it is just needed to have pango working "reliable" with multithreading <ricotz> make check indicates the problems <ricotz> https://launchpad.net/~ricotz/+archive/staging/+sourcepub/2922082/+listing-archive-extra <ricotz> robert_ancell, hi, is this a candidate for raring yet in its early state? ^ <robert_ancell> ricotz, I don't know enough about fontconfig/pango but we were taking a cautious approach to shipping them <robert_ancell> ricotz, having it in a PPA and getting some confirmation it works well will help <ricotz> robert_ancell, alright, will use it for some time <ricotz> and maybe move it to testing ppa after <ricotz> (it might solve a crash with nautilus i saw occasionally with the harbuzz/pango/gtk git-stack) #ubuntu-gnome 2013-01-11 <brittyazel> hey guys <brittyazel> are we planning for gnome 3.8 for 13.04? <darkxst> brittyazel, it will likely be via the ppa <darkxst> since ubuntu is holding back on many packages <brittyazel> oh ok <brittyazel> that is fine though <brittyazel> is there a way we can bundle that ppa by default with our iso? <brittyazel> it seems like much of the distro and it's updated gnome packages rely on that ppa rather than just what is in the main repos <darkxst> brittyazel, most things are already in gnome3-team/staging if you like to break things <brittyazel> lol no i'll probably hold off <darkxst> I think at this stage we will stick with the official packages for the iso <brittyazel> I'm hesitant to upgrade my work machine to 13.04 alpha to help hunt bugs, though the 3.8 kernel that landed today is tempting to say the least <brittyazel> gotcha. <darkxst> and we do push all our bug fixes into the main repos, its just where there is a version split we need to use the ppa <brittyazel> man that is unfortunate that we share so many packages with standard ubuntu. It means we have to constantly tiptoe around them :-/ <brittyazel> yeah I get it. Derivatives like kubuntu have it a bit easier because they can have all of their own packages in the repos without conflict <darkxst> yeh <brittyazel> Is there any particular reason that we do not include the gnome3-ppa by default? It seems like it makes it harder, though I dont know all of the internal details <darkxst> basically comes down not being able to include ppa's in an official derivate (not that we are quite there yet, but still) <brittyazel> oh that's an odd requirement....especially for a distro like ours in which having all of our necessary applications in the main repos would mess with ubuntu <brittyazel> we could do something super sneaky and have our own version of gnome packages in the main repos but with a different naming convention and different dependency table so as to separate ourselves. But that would be SUPER hard to maintain <darkxst> no, that won't happen <brittyazel> I figured as much. It would be an insane amount of work and would probably be way more effort than it is worth <darkxst> the main pain points (such as gnome-control-center) are getting fixed, but now ubuntu has dropped a cycle behind <brittyazel> too bad ubuntu doesn't brand all of the gnome libraries and packages that they use as "ubuntuunity" or something. Then we could have the same scenario as the other derivitaves <darkxst> but that would be pointless <brittyazel> yeah I noticed that. Actually i'm intrigued on where ubuntu is headed actually. Ubuntu Phone is largly written in QML/Qt, and they want a unified interface. Though their main desktop is GTK.... <darkxst> U1 is not GTK <brittyazel> yeah but isn't that the only qt app that ubuntu has in it's native stack? <darkxst> software centre as well probably <brittyazel> they killed the qt version of unity. <brittyazel> no software centre is gtk+ <darkxst> yeh with so many custom/ugly widgets who could guess <brittyazel> lol I know. I'm actually kind of for ubuntu adopting QML and Qt and migrating away from gnome/compiz. I think it would make a better end user experience, but that is just me. <brittyazel> It seem like Gnome is moving one direction and Unity is moving another <brittyazel> and there's only so many post-hoc patches that can be applied <darkxst> apperently not, some packages have 30+ patches <darkxst> g-c-c at one point was I believe closer to 100 <darkxst> probably ~60 now <brittyazel> lol yeah but that is 30-100 patches to an already dated package. I mean they could just montgomeryrobert@example.net/.6 forever and just patch the living hell out of it, but that seems illogical <darkxst> yeh and many bugs are caused by mismatched versions <brittyazel> and it seems like they built a decent phone UI already...I wonder if we will ever see that on the desktop <darkxst> I would estimate around ~60-70% of bugs I have worked on have either been due to ubuntu packaging or patches <brittyazel> do you know at all what changes the phoneOS is going to bring to the Desktop? Are they going to merge the two projects at all <brittyazel> wow that is crazy <darkxst> I think its just the same packages, but they are working to improve performance and power consumption of mobile devices <darkxst> luckily I dont have a nexus 7 otherwise I would probably try and port gnome-shell <darkxst> or something stupid like that <brittyazel> I dont think the phone UI is running compiz though. It looked way to stable and nice to be compiz (if that is too harsh) lol <brittyazel> haha <darkxst> could be, its running proprietry binary blobs for 3D <brittyazel> for gnome3 to want to be on touch screens so badly, i've never actually seen it on a touch screen lol <brittyazel> yeah but, maybe i'm just ignorant, but I've never known compiz to have nearly half of the features needed for a touch ui with edge detection and whatnot <darkxst> that was never a design critieria (despite the rumours) <darkxst> those features are not compiz! <brittyazel> for which? Gnome? <darkxst> yeh gnome-shell <darkxst> edge detection etc, is in Xorg/Xfixes <brittyazel> I know they never said it, but much of the ui is moving from menu-based to sliding switches and buttons. Seems very touch-ish. Which is completely fine <darkxst> unrealted to the WM <brittyazel> gotcha gotcha. So they just have compiz set to trigger events based on xinputs? <darkxst> well compiz hooks into events triggered by X <darkxst> maybe they have taken elements from touch UI's, but they are not desiging for touch devices <brittyazel> i see <brittyazel> I know they aren't purely focusing on touch-ui's (like windows 8 *cough*), but you can tell it is definitely in their thoughts, especially with the xinput2.2 stuff being implemented next round <brittyazel> though I am under the belief that there is a median interface that works for desktop ui's and touch, and that Gnome-Shell has found it lol <brittyazel> so I applaud them <darkxst> yeh, I can't use anything else anymore. <darkxst> everything else just seems wrong <brittyazel> I definiely love it. I still love kde and appreciate it's applications, detail, and complexity. But gnome-shell is next-gen. I just dont get why people flack it so hard <darkxst> lol, cuase it don't look like gnome2! <brittyazel> lol they hate it because it has taste and style <brittyazel> I never understood the desire to punnish ones self with ugly ui's lol <brittyazel> one's guys aregument to me was that "it is impossible to be productive on gnome-shell" and when I countered that I am in fact VERY productive on it he said "nuh uh, you obviously dont do "real" work" <darkxst> well I suppose there are a few points. 1.lack of customisation (but there are extension/themes/tweak-tool for that). <darkxst> 2. people hate change <brittyazel> It is crappy that most UI changes need to come from third party tools <brittyazel> you get spoiled on KDE where every little detail is giving a gui tool <darkxst> 3. it was really released a bit early (3.0 was really a super early alpha) <brittyazel> yeah I agree with that <darkxst> tweak-tool is just a wrapper to gsettings <brittyazel> I guess given those 3 you can be disatsfied with it, but it is fervently hated lol <darkxst> Oh I'm sure ther are more <brittyazel> lol <darkxst> also the big point, is IMO the dissatisfied users are always the loudest <darkxst> how many people write blogs posts just to hate on a project <darkxst> vs how many who love a project <brittyazel> well 3.6 made gnome-shell great for me personally :-) I love the new gdm and notifications. I wish 3.8 was just for bringing UI customization options. Then I would be in heaven <brittyazel> yeah it's true. So many vocal haters. And it scared people off who research stuff before hand (even though it is free and can only cost them time to try it themselves) <brittyazel> I wish I knew more about packaging and the behind-the-scenes work so I could help you guys <brittyazel> unfortunately I would probably be more of a burden <darkxst> heaps of good stuff have landed in 3.7/8 already <darkxst> especially amazing considering how early in the cycle it is <brittyazel> I read it was just changes to the control-center like a privacy setting list and a search option list <brittyazel> is there anything else substantial? <darkxst> relayout of overview search <darkxst> ricotz, did you build gjs in a deb? if so can I grab a debdiff? <brittyazel> is 3.8 getting xinput2.2 and gstreamer1.0 do you know? <darkxst> my jhbuild is still hosed <darkxst> brittyazel, niether of those are gnome-shell things, more distro stuff <darkxst> gsteamer1.0 was already support in 3.6 i think <brittyazel> I gotcha. I thought that there were gnome elements that depended on those <darkxst> g-s shel has been ported to xi2 already <brittyazel> kk <darkxst> the new pressure/pointer barriers should be landing in Xorg 1.14 <brittyazel> is 13.04 getting 1.14? <brittyazel> btw it's pretty nice that they set the gtk flags for wayland recently <brittyazel> that should make it nice for wayland in the future <darkxst> I think its planned (Xorg 1.14), but ricotz or jbicha would likely know more <darkxst> wayland is still some way off <brittyazel> yeah a far way off <ricotz> darkxst, a debdiff? what are you trying? <darkxst> ricotz, or just the source packages. Just want to try install it locally <darkxst> I figured you probably already done that, so no point re-inventing the wheel <ricotz> i see <ricotz> you need to rebuild its rdepends too though <darkxst> ricotz, yeh I realise that <ricotz> http://people.ubuntu.com/~ricotz/gjs/ <darkxst> ricotz, thx <ricotz> darkxst, i guess you havent tested your patches with g-s then yet? <darkxst> ricotz, yes I have, but I have that unrelated "focus issue" :( <darkxst> ricotz, gnome-shell doesnt want to build either ;( http://paste.ubuntu.com/1519355/ <ricotz> darkxst, amd64 with nvidia blob? <darkxst> ricotz, yeh <darkxst> ricotz, I take it you have seen the seg faults on GC? <darkxst> ricotz, particularly this, http://pastebin.com/GxKtpXCW surely that can't be right ;( <ricotz> darkxst, yeah seeing those, but i asked because of the g-s deb packages <ricotz> uploaded them to the folder too <darkxst> ricotz, I just removed the gtk-docs line from the .install file <ricotz> yeah, you probably missing a build-dep <darkxst> ricotz, I tried to rerun 'apt-get build-dep gnome-shell' but it didnt think I needed anythin <ricotz> darkxst, gtk-doc-tools <darkxst> ricotz, thats installed <ricotz> you have checked the debian/control build-deps? <ricotz> anyway, you got around it <darkxst> yeh <darkxst> anyway I should sleep, and then tomorrow I will find a sledgehammer or something to coerce gdb into behaving! <darkxst> ricotz, http://pastebin.com/8N2L3QpY <ricotz> darkxst, will try it #ubuntu-gnome 2013-01-12 <darkxst> ricotz, you can revert this http://git.gnome.org/browse/gnome-shell/commit/src/shell-global.c?id=6f605598de1eb4361ef912e85edb27a8b7b96b21 under js188 <ricotz> darkxst, i see, "should" or "can"? <darkxst> "should" since the gc deadlocks seem to be fixed now in js188 <ricotz> yeah, i mean, does something break if i don't <darkxst> nothing will break if don't <darkxst> but memory usage drops significantly <darkxst> if you do <ricotz> ok <darkxst> ricotz, you tried the gc fix? <ricotz> darkxst, yes <ricotz> i uploaded updated gjs packages too <ricotz> (to the former location) <darkxst> might be worth putting them into staging? solid as a rock here <ricotz> the patches for 187 are quite small and easy, so this transition it reasonable <darkxst> ricotz, yeh most of the fixes for 187 were also safe on 185 <ricotz> i need to think about going for 188 with this patch stack without knowing a js188 tarball will come <darkxst> Jasper thinks he has convinced them to make a tarball <darkxst> but there has not been any progess <darkxst> and apparently politics gets in the way of using an official ff release rather than a standalone one <ricotz> yes the 187 version of gjs in testing contains only two small patches, and that i am comfortable with letting it loose on the public ;) <ricotz> i would like to see some progress on the js188 release first <ricotz> i will think about it <ricotz> bbl <darkxst> I personally still don't get why we need a release! politics aside, if we take mozilla out of the release loop, then can update whenever <darkxst> Surely all distro's can handle taking a mozilla release, and adding 2-3 patches #ubuntu-gnome 2013-01-13 <darkxst> ricotz, https://bugzilla.mozilla.org/show_bug.cgi?id=829421 <ubot5> Mozilla bug 829421 in JavaScript Engine "ArgumentObjects memory leak" [Normal,Unconfirmed] <ricotz> darkxst, i see <ricotz> darkxst, is this a problem of moz187 too? <darkxst> ricotz, will there is a similar problem in 187, but not exactly the same <ricotz> darkxst, alright <ricotz> btw keep an eye on "tabs vs. spaces" <ricotz> pushed an update <darkxst> thanks #ubuntu-gnome 2013-01-14 <darkxst> jbicha, whats the go with libaudit1? its stuck in proposed? <darkxst> gdm 3.7 wants it <jbicha> darkxst: when there's a new soname, the rdepends have to be rebuilt so that we don't have nbs packages <jbicha> reverse-depends src:audit <jbicha> also, although it's difficult to read: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt <darkxst> reverse-depends is quite broken here -> ImportError: No module named devscripts.logger <jbicha> after those 3 packages are rebuilt, it will migrate automatically <jbicha> http://paste.ubuntu.com/1529738/ <darkxst> ok <darkxst> jbicha, not sure if you have seen this, mozjs188 goodness, https://bugzilla.gnome.org/show_bug.cgi?id=690982 <ubot5> Gnome bug 690982 in general "gjs: port to spidermonkey js188/esr17" [Normal,Unconfirmed] <darkxst> although the gnome guys seem to want an official tarball from mozilla before they switch over. <jbicha> darkxst: how risky would it be to use the newer gjs with GNOME 3.6? <darkxst> jbicha, I think it should work fine right now, but I don't know if there are any API changes planned down the track <darkxst> probably best to ask Jasper or gcampax, I guess <darkxst> but either way, worst case might be cherry-picking a few patches against g-s to get/keep it working <jbicha> we'd have to make sure that all of these keep working & building: http://paste.ubuntu.com/1529818/ <jbicha> and you'd need to coordinate with chrisccoulson at least <darkxst> jbicha, why? library would change to mozjs188 <darkxst> or mozjs187 which was a much smaller diff, but didnt really fix much <jbicha> darkxst: I assume we wouldn't be keeping the old library around? <darkxst> probably would have too, I don't really follow any of those other projects, but I am pretty sure no other project has even looked at js188 <darkxst> ricotz and I basically created our own tarball for that <darkxst> they may have looked at js187, since there is an (unreleased) tarball from mozilla for that <jbicha> it's a bit cleaner if we don't have to add a new source package but we don't want to start the transition if we don't think we can complete it <jbicha> anyway, Chris is listed as the mozjs Debian maintainer so see what he thinks <jbicha> I don't know much about javascript except that I help package gjs <darkxst> api changes from 187 -> 188 are all trivial, however it was a pain tracking some of them down, since they don't always trigger compiler warnings <darkxst> and nothing is documented ;( <darkxst> gjs has lot of custom bindings, it could well be the other packages are much easier though <darkxst> jbicha, cinammon uses gjs? <jbicha> I think cinnamon is a customized version of gnome-shell 3.2 with pieces ripped out, new stuff added, and a few things backported <darkxst> yeh I know that much, so its probably ok, I didnt have to touch a single line of gnome-shell code <darkxst> its mainly the custom bindings in gjs, that required porting <jbicha> darkxst: oh now that I updated I'm getting the devscripts.logger problem too :( <jbicha> installing https://launchpad.net/ubuntu/+source/devscripts/2.12.6 works #ubuntu-gnome 2013-01-15 <everaldo> good night (or day) <darkxst> everaldo, day here ;) <everaldo> darkxst, hey... are you already using raring? <darkxst> yeh <darkxst> well some of it <everaldo> well, it look more stable than quantal here <everaldo> it looks <everaldo> darkxst, are you happy with nautilus? <darkxst> tbh I don't really use it alot so yes! <everaldo> man, I got crazy...so patched it <everaldo> well, just 5 patches <everaldo> darkxst, http://paste.ubuntu.com/1533063/ <darkxst> oh, I have 3.7.3 <everaldo> darkxst, from where? sources? <darkxst> gnome3-staging ppa <everaldo> is the one that will be used for gnome-remix? <darkxst> well its the test ppa for gnome3 ppa , don't know if that will be included in the iso however <everaldo> darkxst, do you think that is a good idea try to submit my patches to raring? <darkxst> sure you can try <everaldo> also, will try to patch 3.7.3 <darkxst> although I think they want to reduce the delta, not increase it! <everaldo> yes, I know... but it is a little hard to use the current Nautilus version <darkxst> atleast search is fixed <everaldo> yes, I saw <everaldo> but the missing expand list views (treeview) is something that really make me crazy <everaldo> it is ok remove it from sidebar but... for list view <everaldo> lots of more clicks to use nautilus <darkxst> guess I am old school, I tend to type the path * everaldo thinking about GNOME3 Staging <jbicha> we likely won't get gnome-shell 3.8 in the regular gnome3 PPA this cycle, since it needs gnome-control-center/gnome-settings-daemon 3.8 and that won't be ready <darkxst> oh i see <jbicha> darkxst: when are you going to apply for Ubuntu membership? <darkxst> ah, soon <darkxst> the guys on the developer advisory team, said I should wait for a bit more <darkxst> and/or they would contact me again, when they think I am ready or something <darkxst> but also I have mainly been working upstream again given the current segmentation in ubuntu <jbicha> are you interested in packaging gnome 3.7.4 for the staging ppa? <darkxst> potentially could help out later in the week, bit busy today <jbicha> that's fine, there isn't a rush <darkxst> ok, I can do some packages <Mikel> Want to solve the problem of launch menu. Icons are not separated <ricotz> jbicha, hi, be aware that the tarballed configure.ac of g-s lies about the gjs dep <jbicha> ricotz: lies? <ricotz> it really needs gjs 1.35.4 <jbicha> it's running here fine with gjs 1.35.3 <jbicha> gjs 1.35.4 on the other hand isn't because I guess it needs a newer gobject-introspection <ricotz> jbicha, hmm, should get some js failures <ricotz> due missing cairo dispose methodes <ricotz> yeah, gjs probably needs the newer g-i too <jbicha> I wonder if I can get robert_ancell to package accountsservice 0.6.30 since g-c-c 3.7.4 needs it <ricotz> jbicha, libpeas would be nice too, since 1.6.2 isnt even in quantal/raring <ricotz> and 1.7.0 is needed <ricotz> <ricotz> jbicha, libpeas would be nice too, since 1.6.2 isnt even in quantal/raring <ricotz> <ricotz> and 1.7.0 is needed <jbicha_> yeah, we should get 1.6 at least (but it's not in the desktop set so I can't do it) <ricotz> jbicha, another thing, mutter might need an unreleased clutter too to work correctly <ricotz> jbicha, since you are the only one uploading to the gnome3 ppas from the ubuntu-desktop team, do you care for having admin rights for the group? <jbicha> hmm, the new g-i still isn't enough to get the new gjs to work <jbicha> I'm already an admin since I'm on the desktop team, thanks though :) <ricotz> jbicha, you are sure gjs isnt working? <ricotz> it builds and tests (make check) is successful for you? <jbicha> it builds fine, but gdm only shows the wallpaper unless I downgrade gjs <jbicha> I've updated mutter, gnome-shell, gsettings-desktop-schemas and gnome-settings-daemon <ricotz> jbicha, you should have a look at the session log then <ricotz> (runs fine here) <ricotz> (although i use mozjs 1.8.7) <jbicha> darkxst: you could try asking the Fedora maintainer what he thinks about the new mozjs proposal https://apps.fedoraproject.org/packages/js/ <darkxst> ok will try <darkxst> jbicha, anyway mozilla want to land this before releasing https://bugzilla.mozilla.org/show_bug.cgi?id=812265 <ubot5> Mozilla bug 812265 in Build Config "js/src needs versioning added to build system to support spidermonkey releases" [Normal,New] <darkxst> which looks like it will change version number to use firefox version #ubuntu-gnome 2013-01-16 <jbicha> ricotz: my gjs problem was http://paste.ubuntu.com/1538095/ <ricotz> jbicha, ah, you didnt update gnome-shell concurrently <ricotz> simply removing the "dbus import" there fixes it <jbicha> well I built gnome-shell against gjs 1.35.4 <ricotz> no the js code of gnome-shell contains a left over <ricotz> just use the newer shell version <jbicha> that was 3.7.4 and there haven't been any commits like that since <ricotz> the js code isnt affected by a rebuild <ricotz> http://git.gnome.org/browse/gnome-shell/commit/?id=e294abc567b50ce4358dcd6be1e2f147b81ebcf8 <ricotz> so 3.7.4 is fine <ricotz> maybe you didnt update the -common package correctly? <jbicha> oh, never mind I apparently reverted back to +1-585-472-9035 since I had problems <jbicha> thanks <ricotz> ok <jbicha> ok, now my problem is that I can't figure out how to get gnome-control-center to compile: http://paste.debian.net/225388/ <jbicha> I am building against g-s-d 3.7.4 which was built against gnome-desktop 3.7.4 <ricotz> jbicha, i was planning to take a look at those two packages <ricotz> look like a missing ldflag <ricotz> btw nice to finally have eglibc 2.17 <ricotz> jbicha, as i said yesterday mutter/g-s might have problems without a newer clutter1.0 due xi2 bugs <ricotz> jbicha, or maybe not, just go ahead <ricotz> robert_ancell, hi <robert_ancell> ricotz, hello <ricotz> jbicha, robert_ancell, i have a e-d-s 3.7.4 here, any objections to push it to staging? <ricotz> https://launchpad.net/~ricotz/+archive/staging/+sourcepub/2930384/+listing-archive-extra <robert_ancell> ricotz, sounds good to me <ricotz> i am not using evolution, but it doesnt make g-s crash or something here ;) <ricotz> fabien doing evolution packages too, maybe i convince him to look at rdepends too <robert_ancell> ricotz, I figure it's OK because it's a staging PPA - if it does break stuff then the new e-d-s doesn't get copied to the main PPA <robert_ancell> and at least then we'll know <ricotz> for non-evolution users it shouldnt do much <jbicha> I don't think you should push e-d-s <ricotz> jbicha, why <ricotz> (already did) <jbicha> I don't think we want to maintain all the rdepends that need to be rebuilt <ricotz> but still stoppable <ricotz> jbicha, currently it coexists fine <jbicha> well maybe it's doable since we're already maintaining most of the gnome stack anyway <jbicha> it was a bit different when we shipped the same gnome as ubuntu <ricotz> wait with g-s upload until e-d-s is finished please <jbicha> sure, I'm hoping I can figure g-c-c out first since it's kinda tied with gnome-shell <ricotz> did you manager to refresh some more patches of g-s-d? <ricotz> *manage <ricotz> robert_ancell, are you working on any package? <robert_ancell> ricotz, just updated libpeas, now working on colord <robert_ancell> and baobab <robert_ancell> in raring, not the PPA <ricotz> ok, pushed eog <ricotz> alright, i guess libpeas 1.7.0? <robert_ancell> libpeas 1.6 in raring <ricotz> or 1.6.2 <ricotz> ok <ricotz> i hope you can do 1.7.0 for the ppa too <robert_ancell> sure <ricotz> thanks :) <jbicha> ricotz: no, g-s-d isn't really any better; I went ahead and pushed what I have to https://code.launchpad.net/~gnome3-team/gnome-settings-daemon/ubuntu <jbicha> https://code.launchpad.net/~gnome3-team/gnome-control-center/ubuntu <ricotz> jbicha, ok <jbicha> ok, it was some Ubuntu patches that were breaking the g-c-c build <jbicha> ricotz: http://paste.ubuntu.com/1538880/ <ricotz> libedataserverui was removed upstream <ricotz> just remove this dep and try again <ricotz> which package is this? <ricotz> i guess gnome-shell <ricotz> jbicha, just drop that dep it is obsolete <jbicha> yeah, it was gnome-shell, I had to replace it with libcamel1.2-dev <ricotz> jbicha, camel is not a dep of g-s <ricotz> libecal-1.2 and libedataserver-1.2 <ricotz> if libcamel1.2-dev is needed the e-d-s package is missing an internal dev dependency <jbicha> http://paste.ubuntu.com/1538931/ <ricotz> yeah and missing internal dep <ricotz> +an <jbicha> ok I'll wait for you to push a new eds then? <ricotz> yeah, i am on it <ricotz> jbicha, why did you push a glib2.0 package to the ppa? <jbicha> ricotz: um, don't we need it? <ricotz> no it is in raring as you stated <ricotz> the ppa builds against the proposed pocket <ricotz> otherwise you would have seen quite some failures <jbicha> oh I'll delete it then <ricotz> also wait a bit before you delete packages <ricotz> i guess you did with the previous glib2.0 package <jbicha> do you want to delete it instead then? <ricotz> no delete this one <ricotz> but someone deleted the older one already <jbicha> on the other hand... <jbicha> I don't think we should encourage users to be using -proposed <ricotz> no please remove it <ricotz> if someone is able to deal with gnome3-staging then -proposed shouldnt be problem <ricotz> also gobject-introspection was already deleted <ricotz> jbicha, i figured you did that? <ricotz> (i deleted the glib package now) <jbicha> yes but I wasn't thinking about glib2.0 getting held in -proposed for a while <ricotz> jbicha, if you want to badly do a binary copy <ricotz> the builders are busy already ;) <jbicha> how do I do that? <ricotz> i copied both now <jbicha> ok, how did you do it? <ricotz> pm <ricotz> if possible do a binary copy to avoid rebuilds and different binaries <darkxst> ricotz, can you file a bug with your install headers patch upstream, and cc Jeff Walden <ricotz> darkxst, i don't have a mozilla bugzilla account, feel free to do so <darkxst> ricotz, ok <darkxst> ricotz, also mozilla are planning on landing this before release https://bugzilla.mozilla.org/show_bug.cgi?id=812265 <ubot5> Mozilla bug 812265 in Build Config "js/src needs versioning added to build system to support spidermonkey releases" [Normal,New] <darkxst> which changes the versioning to match firefox numbers <darkxst> so presumably mozjs-17.2 or similar <ricotz> darkxst, i see, looks nice <ricotz> with support to co-install multiple headers <darkxst> yep <ricotz> hoping this release will happen soon then <darkxst> hopefully <darkxst> ricotz can you whip up an install-headers patch with proper headers #ubuntu-gnome 2013-01-17 <ricotz> darkxst, http://paste.debian.net/plain/225500 <darkxst> ricotz, so I tried to install 3.7 from testing on my Q laptop and hit the same 'focus issue' have been having with jhbuild on R :( <ricotz> darkxst, vanilla quantal with ricotz/testing ppa? <darkxst> ricotz, it was a vanilla quantal install, but has ubuntu-gnome-desktop installed <ricotz> with "focus issue" you mean the exclusive problem in g-s overview? <darkxst> yeh <darkxst> well not just overvew, happens with any pop-up or dialog <darkxst> i.e alt-tab <ricotz> so switching to a window with alt-tab shows it but doesn't focus it? <darkxst> mabye focus is really the wrong word, but basically launching a dialog (say alt-tab) all input gets stuck keyboard/mouse, that times out after about 10-30sec <darkxst> then you get one more input event from key/mouse and it gets stuck indefinately <ricotz> ok, focus-issue is the wrong word for it then <ricotz> i might have seen this with the volume control with raring <darkxst> also its not your typical push/pop modal issue <ricotz> the alt-tab window stays there for ever? <darkxst> that tends to cause wierd things with events going to the wrong windows <darkxst> ricotz, yeh <ricotz> could you use your volume conrol keys in a "faster way" <ricotz> so tune it up and down a bit <darkxst> I did not try volume keys <ricotz> this is how i am seeing it occasionally and the volume-control-window of g-s gets stuck <ricotz> of course this window doesnt use modal so it doesnt grab all keys afterwards <ricotz> but it sounds like the same issue <darkxst> similar, except this is affecting basically everything <ricotz> i guess you told me already, which x-driver do you use? <darkxst> intel on Q, nvidia blob on R <ricotz> ok <ricotz> blob and intel on R here <ricotz> only seen my issue on with blob <ricotz> will try to reproduce it (i updated today to 313.18) <ricotz> also i am using a pre-release of eglibc 2.17 <ricotz> on raring <ricotz> which solves some deadlocks of 2.16 <darkxst> of course the strange thing is the 3.7 g-s packages from testing work perfectly on my R machine with broken jhbuild <darkxst> and when I attached to g-s with gdb, it just had g-s sitting in a normal idle state <darkxst> anyway I am stuck on my laptop this week, so can't really go and break it again, to try debug more <ricotz> darkxst, alright, this seems to be caused by some dependency or the X stack <darkxst> hm right <darkxst> btw, I think I probably have xorg-edgers installed on my R/jhbuild machine <ricotz> me too ;) <jbicha_> gdm unlock seems broken http://paste.ubuntu.com/1542043/ <darkxst> jbicha_, I think that is this bug https://bugzilla.gnome.org/show_bug.cgi?id=689106 <ubot5> Gnome bug 689106 in lock-screen "ScreenShield: try harder to become modal, and catch failures" [Critical,New] <jbicha_> darkxst: thanks, I guess I should file a bug report then <jbicha_> I'm getting the gnome-screensaver
{'channel': 'ubuntu-gnome', 'month': 1}