#ubuntu-gnome 2013-02-01 <jery> Ñ Ð¼Ð¾Ð³Ñ Ð½Ð°Ð¿Ð¸ÑÐ°ÑÑ? <jery> ÑÑÐ°!!! <jery> ÑÑÑ ÐµÑÑÑ ÐºÑÐ¾? <jery> Ð·Ð°Ð¹ÑÐ¸ Ð·Ð°ÑÑÐ»... ÑÐ¾Ð»ÑÐºÐ¾ ÑÑÑ Ð½ÐµÑ Ð½Ð¸ÐºÐ¾Ð³Ð¾... <jery> Ð±Ð»Ð¸Ð¸Ð¸Ð¸Ð½... <Barami> Hello :) <darkxst> ricotz, the new js188 versioning patches install directly to mozjs-17.0.so, rather than a symlink to mozjs-17.0.so.1.0.0 <darkxst> is that acceptable ? <darkxst> (from a distro point of view) <ricotz> darkxst, for public shared library, no <ricotz> it should have a proper soname <darkxst> ricotz, ok I suspected that would be the case. <ricotz> you actually installed it and confirmed it ends up that way? <darkxst> ricotz, yes <ricotz> ok <ricotz> mozjs-17.0.so.0.0.0, mozjs-17.0.so.0, mozjs-17.0.so <ricotz> those 3 files should be present <ricotz> mozjs-17.0.so.0.0.0 the actual library <darkxst> yeh, ok, will patch it to do that <ricotz> and two symlinks <darkxst> plan is to get js release out around 18th <darkxst> but patches need to land first <ricotz> oh, that would be nice #ubuntu-gnome 2013-02-02 <darkxst> jbicha_, so do we want to try land js188 in raring? (hopefully should be released around the 18th) <darkxst> I have gnome-shell 3.6 running on the new stack, all good so far <jbicha_> darkxst: the blocker to me is whether we can get the rdepends to build against it <jbicha_> why don't you open a tracking bug against mozjs in launchpad? <darkxst> jbicha_, I will, but it wont be possible to get all of rdepends done (atleast not before feature freeze) <jbicha_> ok, well we can see use the bug to see how many do build <darkxst> jbicha_, none will build just yet! <jbicha_> uh, you have patches for some though, right? <darkxst> so far I have only done gjs and polkit (irrelevant though) <darkxst> couchdb looks easy <darkxst> cinnamon, should just need a rebuild <darkxst> 0ad is probably the worst <darkxst> also the patches will tend to be fairly big deltas, so really need to land them upstream first if possible <darkxst> jbicha_, done <darkxst> jbicha_, couchdb makes extensive use of an illegal javascript syntax, so basically they are stuck on js185 <darkxst> (made worse by the face that this is in the actual end-user code, not the actual engine) <jbicha> maybe we'll keep a mozjs185 around until stuff can be ported <darkxst> yeh #ubuntu-gnome 2013-02-04 <robert_ancell> jbicha, ricotz, hey. I've moved to another team inside Canonical so you may have noticed not a lot of work from me with packaging recently <jbicha> robert_ancell: oh which team? <robert_ancell> jbicha, secret stuff at the moment <jbicha> cool #ubuntu-gnome 2013-02-05 <darkxst> ricotz, https://bugzilla.mozilla.org/show_bug.cgi?id=837921 <ubot5> Mozilla bug 837921 in JavaScript Engine "Metabug for tracking SpiderMonkey standalone embedding bugs" [Normal,New] #ubuntu-gnome 2013-02-06 <darkxst> jbicha, since you have asked a few times, I have gnome git access now <jbicha> darkxst: good! <darkxst> it was a pain to get though (Mango was very broken) <jbicha> :( it wasn't too bad when I applied <darkxst> I applied 3 times, and it never worked <darkxst> finally they manually created an account for me <jbicha> wow <jbicha> and the GNOME Classic mode for 3.7.5 is surprisingly good <darkxst> yeh looks great <darkxst> too bad gnome-shell is completely stuffed for me today <jbicha> they just landed a window-list extension on the bottom bar <jbicha> darkxst: I just pushed gnome-shell 3.7.5 to the staging PPA <darkxst> I will see if that helps, but on jhbuild been getting lots of stuck grabs etc <darkxst> jbicha, I can't use that one <darkxst> since I am running js188 stack <darkxst> jbicha, "gnome-shell : Depends: libgjs0-libmozjs185-1.0"? <jbicha> darkxst: I believe that's automatic from the libgjs-dev build-depends <jbicha> hmm <darkxst> jbicha, anyway I will help out with packaging 3.7.5 <jbicha> ok, just send me or ricotz your debdiff's <jbicha> the time zone difference will probably be a bit annoying as it's about bed time here <darkxst> timezone always is a bit annoying! <darkxst> jbicha, I assume your using git snapshots, since that tarballs aren't out yet are they? <jbicha> yes they didn't release gnome-shell-extensions 3.7.5 yet <darkxst> ricotz, whats the best way to get updates for gnome3-staging through to you? <ricotz> darkxst, how do you mean? <ricotz> brb <darkxst> ricotz, I am going to help out with updating some packages to 3.7.5 <ricotz> darkxst, nice :) <ricotz> i think a " debdiff *.dsc *.dsc | filterdiff -i "*/debian*/" " is fine <ricotz> i will try to look into some updates later too <darkxst> and email? <ricotz> or some pastebin <darkxst> what is the filterdiff meant to do? <ricotz> to get rid of the upstream changes <darkxst> yeh thats what I figured, but its not working properly like that <ricotz> debdiff *.dsc *.dsc | filterdiff -i "*/debian/*" <ricotz> bbl <darkxst> oh, dont worry, just diff of diff confusion <darkxst> here is empathy http://pastebin.com/Q7f7urdr <darkxst> need telepathy-logger update, but thats just a straight rebuild no patches etc <ricotz> sorry, please paste me the link later again, g2g <ricotz> btw empathy might not be the best to start, since we probably need to disbale some other patches to make it work without the g-c-c support <nick07> hello <darkxst> ricotz, jbicha http://pastebin.com/ig8g5feJ <jbicha> darkxst: why the debian/rules change? <darkxst> gdm-binary seems to already be gdm now <darkxst> i.e. renamed upstred <darkxst> upstream <darkxst> gnome-session: http://pastebin.com/3Xgx4uAm <jbicha> darkxst: where should we ship the .session's for GNOME Fallback then? <darkxst> jbicha, its in gnome-shell-extensions <jbicha> that's different, the gnome-panel session still pretty much works on Ubuntu <darkxst> oh we are keeping that as well, even on 3.8? <jbicha> sure, why not? <jbicha> maybe they just need to be added to gnome-panel itself upstream http://jonathancarter.org/2013/02/05/gnome-panel-is-alive/ <darkxst> jbicha, ok, I will leave it in for now <darkxst> jbicha, http://pastebin.com/BHnHH23N #ubuntu-gnome 2013-02-07 <jbicha> ricotz: hi, your gnome-shell needs to depend on gir1.2-nmgtk-1.0 <ricotz> jbicha, hi, i see <ricotz> libnm-gtk-dev needs to depend on it too <darkxst> ricotz, can you update mutter/gnome-shell on testing, seems to be a little less broken today ;) <ricotz> darkxst, will do <darkxst> gnome really should have a short freeze before release, just about every release has been broken so far this cycle <ricotz> darkxst, what exactly is broken for you? <darkxst> overview kept breaking, requiring restart of gnome-shell <jbicha> darkxst: GNOME historically just dumps the current master into a tarball on release day during the unstable dev cycle with insufficient testing to make sure things actually work <darkxst> I also keep getting a stuck grab <jbicha> that said, 3.7.5 has been mostly smooth here (but I'm not using js188 either) <darkxst> jbicha, I know, even more like there is a last minute rush to land everything before release <darkxst> maybe overview issue is related to multiple monitors <jbicha> what annoys me more is that there aren't enough .1 releases to fix things that are broken, we have to do too much cherrypicking of patches <jbicha> only 1 monitor here <darkxst> hmm, we need to ut back ubuntu-lightdm-user-switching.patch in 3.7.x <jbicha> darkxst: ok I pushed gdm to the staging PPA and will push gnome-session after I finish tweaking and testing #ubuntu-gnome 2013-02-08 <darkxst> jbicha, ok. <darkxst> I should have some time to do a bunch more later today. <darkxst> jbicha, are you missing background on 3.7.5? <jbicha> darkxst: no, but I don't have ubuntu-settings installed either https://launchpadlibrarian.net/130099807/ubuntu-settings_12.10.6_12.10.7.diff.gz <jbicha> we need to figure out whether we should explicitly override the Ubuntu overrides in ubuntu-gnome-default-settings <darkxst> we probably need to, if they are going to go an disable stuff like that! <darkxst> jbicha, seems latest cogl is quite unhappy about having g-s-d background plugin disabled <darkxst> seg faults everytime trying to enter overview <darkxst> (fixed itself after I removed ubuntu-settings) <darkxst> cogl 1.14 <jbicha> darkxst: ok but there's still the question of whether we should explicitly override other settings <darkxst> jbicha, or conflict against ubuntu-settings? <darkxst> probably you don't want ubuntu-settings if you have install ubuntu-gnome-setting <jbicha> darkxst: ubuntu-settings is a dependency of ubuntu-desktop though so maybe change that to an alternate dependency too <darkxst> I think that would be best <darkxst> or it could be nice if there were per-DE overrides, but I don't think thats actually possible <jbicha> desrt wanted that but I don't know whether that's possible yet <darkxst> ricotz, how do I update .symbols files? there are a lot of changed symbols in libsoup update <ricotz> darkxst, apply the diff which you get on the build failure <ricotz> and change the version to the upstream version only <darkxst> ricotz, change the overall version aka. library version? <darkxst> or something else <ricotz> it should be the upstream version without the debian part <darkxst> hmm so just this in the changelog?, libsoup2.4 (2.41.5-0ubuntu1) raring; urgency=low ? and/or libsoup2.4-1 > libsoup2.4(1)? <ricotz> darkxst, "2.41.5" <ricotz> you asked about the symbols file <darkxst> yeh <darkxst> but got confused I guess, it has <darkxst> libsoup-2.4.so.1 libsoup2.4-1 <ricotz> did you built your package? <darkxst> (for 2.40.1) <ricotz> it will complain about new symbols normally <ricotz> which gives you a diff to apply <darkxst> I patch the file and libsoup built <ricotz> if you already done it, you don't really gave me much to work with <ricotz> look at the file you make the new symbols match the scheme of the old entries <ricotz> don't change the first line (soname) if there wasnt a bump <darkxst> ricotz, http://pastebin.com/GKJTjsJN <darkxst> sorry wrong on <darkxst> one <darkxst> right one, http://pastebin.com/DtQk8PLJ <ricotz> darkxst, are you using a chroot/pbuilder to build? <ricotz> you are probably missing some builddeps <darkxst> hmm no <ricotz> darkxst, seems like bad luck for you, this looks like an upstream problem imo <ricotz> probably some deprecation fallout <darkxst> meh pbuilder not happy either <darkxst> Err http://archive.ubuntu.com/ubuntu/ raring/main libdconf1 amd64 0.15.2-0ubuntu4 <darkxst> 404 Not Found [IP: (502)257-5948 80] <ricotz> darkxst, ok, the symbols removals seems fine since they never were part of the public api <ricotz> done between 2.41.1 > 2.41.2 <ricotz> darkxst, i had a look at the package and will push it to gnome3-staging <darkxst> ricotz, thanks <darkxst> atleast, gnome-documents requires it <ricotz> jbicha, just a heads up, cogl >= 1.13.2 will be needed soon, currently it seems avoidable with some reverts though <jbicha> ricotz: that doesn't sound fun, we can't run apps built against two different cogl's at the same time? <ricotz> jbicha, exactly <ricotz> we can't <jbicha> and we can't land the new cogl in raring directly because gnome 3.6 won't work with it easily? <ricotz> jbicha, it is suppose to be API compatible, so it should work <jbicha> ok, do you want to open a tracking bug at some point? <jbicha> we don't need new clutter then? <ricotz> imo they should go together <jbicha> I think seb128 will let us land a few 3.8 things if it's "safe" <ricotz> it should be tested before going for it <ricotz> this requires a rebuild of lot of things as you know :\ <jbicha> yeah <ricotz> clutter master currently depends on cogl 1.13.2 <ricotz> but it is avoidable <jbicha> like gnome-games 3.8 should be easy since except for the split, not much has been done with them <ricotz> (clutter 1.14 i mean) <ricotz> it would be reasonable to copy the shlibs mechanism of gjs/mozjs <ricotz> to bundle clutter/cogl together <ricotz> which should make it impossible to have a no-working install combination <jbicha> ok that's beyond my expertise :) <ricotz> i see <ricotz> the problem is also to hope there won't be another cogl soname bump <darkxst> http://pastebin.com/6F61502i <darkxst> jbicha, ricotz ^ <darkxst> do you want debdiff's for pacakges that have no debian changes required? (gnome-sushi, gnome-system-monitor etc..) <jbicha> darkxst: sure, it will help fill out your https://launchpad.net/~darkxst/+related-packages <jbicha> it's not as significant as if there were lots of things that needed to be changed but I think it still helps <darkxst> gnome-sushi http://pastebin.com/pbSvE2xu <darkxst> gnome-system-monitor http://pastebin.com/8zMrTcek <darkxst> gsettings http://pastebin.com/24Stcb79 <darkxst> ricotz, is xorg 1.14 going to land this cycle? <ricotz> darkxst, yes, i think so <darkxst> ok, cool <darkxst> jbicha, don't know if you saw this one, before you got disconnect, gsettings http://pastebin.com/24Stcb79 #ubuntu-gnome 2013-02-09 <jbicha> darkxst: thanks, I uploaded g-s-m and -documents, I'm checking sushi now <darkxst> gnome-backgrounds http://pastebin.com/e0XuH2sH <darkxst> jbicha, you seen these errors before http://paste.ubuntu.com/1627348/ <jbicha> darkxst: it builds here, what do you use to build packages? <darkxst> jbicha, I am getting that with jhbuild and debuild <darkxst> it seems to work in pbuilder, but I couldnt work out how to regenerate the symbols in that <jbicha> you can kind of copy and paste from the log to make a patch which you can apply to the symbols file <jbicha> but they split the library which I think we'll want to do in the packaging too so it's going to be a trickier update <darkxst> jbicha, yeh I know <darkxst> jbicha, gcr - http://pastebin.com/ecJStfd5 <darkxst> symbols are updated, but I did not split the libraries <darkxst> ricotz, fyi, you will need to patch this next time you make a snapshot http://git.gnome.org/browse/mutter/tree/configure.ac#n204 <darkxst> since our xi has the barrier stuff removed #ubuntu-gnome 2013-02-10 <darkxst> jbicha, is there really any point splitting up gcr libs? <jbicha> darkxst: ask upstream ;) <jbicha> https://bugzilla.gnome.org/show_bug.cgi?id=689685 <ubot5> Gnome bug 689685 in gcr "VAPI support for gcr" [Normal,New] <jbicha> I was thinking Debian would want the libraries split although I'm not aware of any apps that use gcr but don't use gtk <darkxst> I think the whole point of gcr is to provide the UI <jbicha> splitting the libraries shouldn't hurt anything (except requiring rdepends to be rebuilt) but we should do the same thing Debian does <jbicha> nothing needs the new gcr right? so maybe we should just hold off on updating gcr for now? <jbicha> darkxst: Fedora hasn't bothered splitting gcr but Debian tends to split more than Fedora http://koji.fedoraproject.org/koji/buildinfo?buildID=382408 <jbicha> I mean we do 10 packages and they do 3 :) <darkxst> jbicha, I will ask stefw <darkxst> jbicha, five-or-more http://pastebin.com/JXurftpM <darkxst> four-in-a-row http://pastebin.com/4Hh99VMX <jbicha> robert_ancell: why did you use dh for gnome-games instead of keeping cdbs? <robert_ancell> jbicha, because dh is easier <jbicha> robert_ancell: sure but I don't think the Debian GNOME team wants to switch <robert_ancell> jbicha, sure, if they take the work upstream we'll just sync off them <jbicha> or they could sync off us <darkxst> chess http://pastebin.com/aqduXHEW <jbicha> darkxst: have you ever done transitional packages before? because chess needs one <darkxst> jbicha, no <robert_ancell> jbicha, well, I don't mind either way. So if you want to change it no opposition from me <jbicha> darkxst: there's an example in line 251 of http://anonscm.debian.org/viewvc/pkg-gnome/desktop/experimental/gnome-games/debian/control.in?view=markup <jbicha> darkxst: otherwise users won't get upgraded from glchess to the newer gnome-chess automatically <darkxst> jbicha, ok <darkxst> I suppose five-or-more also needs one <darkxst> jbicha, so I remove the breaks/replaces from gnome-chess package? <darkxst> like this? http://pastebin.com/aqduXHEW <darkxst> jbicha, ^ is that correct? <darkxst> first 2 games updated also (same links) <jbicha> we still need breaks/replaces since I think the new game ships some of the same files as the old one <jbicha> in the Debian example, they used versioned b/r's though <darkxst> jbicha, http://pastebin.com/aqduXHEW <ErtanERBEK> anyone know how can I hide windows content at drag or move time ? <jbicha> darkxst: the Description line is missing some linebreaks <darkxst> jbicha, ok, fixed all 3 debdiffs <jbicha> darkxst: oops, that creates empty binaries <darkxst> hmm how do I stop that? <jbicha> when there is more than one binary, you have to use a .install to explicitly tell it which files go in which packages <jbicha> http://paste.ubuntu.com/1634727/ <jbicha> http://lintian.debian.org/tags/transitional-package-should-be-oldlibs-extra.html <darkxst> oh, I see #ubuntu-gnome 2013-02-11 <darkxst> jbicha, they should be right now <SonikkuAmerica> Hey! (Wow, this is all of us?) <SonikkuAmerica> !enlightenment is !e <JDBuntu> using gnome shell with ubuntu 12.10 can anyone suggest the best way to get a link to a specific folder put in the dock? Not just the files link, but a link to a specific folder that will launch that location when clicked? <SonikkuAmerica> Are you talking about the dock in Activities? <JDBuntu> yes <SonikkuAmerica> Hold on a second. Let me switch to Shell. (I'm using Fallback rt now) <JDBuntu> thanks! <SonikkuAmerica2> (I'm back) <SonikkuAmerica2> Check out this link on StackExchange: http://askubuntu.com/questions/40382/how-to-add-a-folder-to-the-favorites-bar-in-gnome-shell <JDBuntu> thank you <SonikkuAmerica2> It's for GNOME 3.0 but I would assume it still works in 3.6 <SonikkuAmerica2> Also, I would use gedit rather than nano if you don't wanna mess with the terminal <JDBuntu> I'm good with nano <JDBuntu> SonikkuAmerica - thank I got it sorted <SonikkuAmerica> Awesome. <JDBuntu> That is annoying. I think that they should have a better solution for that... <JDBuntu> I love gnome shell, but come on. <SonikkuAmerica> Take it up with the GNOME 3 team. <JDBuntu> right! <JDBuntu> anyway. thank you! <SonikkuAmerica> You're welcome. <darkxst> jbicha, are you seeing uscan choking on whitespace in watch files? <darkxst> it just started today ;( <jbicha> darkxst: no, I haven't seen that but I haven't run uscan directly in quite a while <jbicha> I use "bzr mu" with debian directory only packaging like is done with the ubuntu-desktop team branches <jbicha> that workflow is sort of documented at https://wiki.ubuntu.com/DesktopTeam/Bzr but I think that page is kind of confusing <jbicha> darkxst: I'm working on converting the -games back to cdbs <darkxst> jbicha, ok <darkxst> gnome-screenshot http://pastebin.com/5hfkfMkY <jbicha> except for some boilerplate in debian/rules and using debian/control.in it's not that much more complicated <jbicha> dh7 format is really nice though <SonikkuAmerica> One sec <SonikkuAmerica> e.e #ubuntu-gnome 2013-02-12 <darkxst> ricotz, do you remember what cause the closure leaks in gjs tests? <ricotz> darkxst, it was triggered by js port of mainloop which relied on a glib patch <ricotz> http://git.gnome.org/browse/glib/commit/?id=1ce415b45bde895c31dd32e2f7ab7e7ab79e735e <darkxst> hmm right, so this one I am seeing is something else then <darkxst> its leaking a closure in testGObjectClass <ricotz> so i guess you changed something <darkxst> ricotz, no i didnt change anything, rebased patches for js17 etc, but that is all just build scripts <darkxst> I suspect its a deeper issue in g-i or glib <darkxst> https://github.com/darkxst/js17/tree/mozjs17-rebase <ricotz> darkxst, this looks new thoug http://git.gnome.org/browse/gjs/commit/?h=wip/mozjs-188&id=ab258cc09201308aba8f3c1a956555f6f4bcc5f9 <darkxst> ricotz, no, walters missed that patch when he created the wip branch <darkxst> that was/is one of the original patches for my js188 port <ricotz> ah ok, i didnt compared it with the patch-set <darkxst> I have not touched gjs in weeks <darkxst> mostly been prodding mozilla people, trying to get a release <ricotz> so you are seeing this issue building the current branch against "my moz188" snapshot too? <ricotz> i will just build gjs now <darkxst> its more broken right now due to the new introspection checks Jasper added <darkxst> in git g-i <ricotz> right, just noticed <darkxst> I filed a bug, but bgo is down right now <darkxst> I even commented out all the closures in the test case, and that didnt help either <darkxst> ricotz, anyway if you revert back to the released g-i then you will probably see it <jbicha> ricotz: I filed bug 1123302 <ubot5> bug 1123302 in modemmanager (Ubuntu) "Please package modemmanager >= 0.7.990" [Wishlist,New] https://launchpad.net/bugs/1123302 <ricotz> jbicha, ah, i see, cyphermox has it probably in his queue already <ricotz> i guess accountsservice and colord are more important get noticed ;) <ricotz> last time i checked RAOF was onto colord, it has been a while already though <ricotz> also osinfo, i think <jbicha> for colord: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699941 <ubot5> Debian bug 699941 in libgusb "Update to 0.1.5 release" [Wishlist,Open] <ricotz> ok <jbicha> SonikkuAmerica: you're in Ohio? <darkxst> ricotz, https://bugzilla.gnome.org/show_bug.cgi?id=693627 <ubot5> Gnome bug 693627 in general "introspection errors in gjs make test" [Normal,Resolved: fixed] <darkxst> jbicha, gnome-keyring http://pastebin.com/XpAHJQQC <ricotz> darkxst, yeah i noticed that gjs got fixed in this regard <darkxst> ricotz, the failing test happens even with js185 <darkxst> altough jasper can't reproduce it <ricotz> darkxst, if you want to tackle the gnome-keyring then do the whole thing and start with gcr <ricotz> there is even a new lib irc <darkxst> ricotz, I already did gcr <darkxst> oh jbicha hasnt uploaded it <jbicha> darkxst: you didn't split the library ;) <darkxst> we never really came to a conclusion on that <jbicha> do you know what I need to run gnome-shell from jhbuild without hitting <jbicha> Window manager warning: Log level 32: Execution of main.js threw exception: TypeError: Meta.BarrierDirection is undefined <SonikkuAmerica> jhbuild? What's that? <jbicha> https://live.gnome.org/Jhbuild <jbicha> darkxst: right, you could also ask in #debian-gnome on OFTC; of course they're trying to release wheezy with 3.4 so they probably aren't too concerned with 3.7.5 yet :) <darkxst> jbicha, you need to patch out HAVE_XI23 in mutter configure <darkxst> ubuntu xi has the barrier stuff patched out <jbicha> hmm that doesn't seem to work <darkxst> jbicha, try revert this http://git.gnome.org/browse/gnome-shell/commit/?id=fb63f48d0a0bd9b7db14400369237f8ba29da160 <darkxst> and the one before it <jbicha> darkxst: thanks that works, now I have to figure out who killed the usermenu... * SonikkuAmerica sends detectives out <darkxst> jbicha, mutter is supposed to fallback to the old barriers, but I suspect that it hasnt really been tested <darkxst> gnome-calc http://pastebin.com/VAETCEsg <jbicha> robert_ancell: we get to add an epoch to gnome-calculator <robert_ancell> jbicha, oh, why's that? <jbicha> because some maintainers can't count ;) <SonikkuAmerica> Hmm? <robert_ancell> oh, someone bumped it to 6.x? <SonikkuAmerica> Is gcalc-tool doing something weird? <jbicha> for upgrades to work, I'm pretty sure we need a transitional package and the transitional package has to have a higher version number than 6.6.2 <ricotz> jbicha, just bump the xi dep in configure.ac and you are fine, no reverts needed #ubuntu-gnome 2013-02-13 <darkxst> jbicha, are you missing random icons in jhbuild? <Guest85676> hi <jbicha> darkxst: no but I'm not really running much from jhbuild, 3.7.5 is only a week old :) <darkxst> right, mine has been stuffed for a week or so <darkxst> I probably need to rebuild some of the deps <darkxst> jbicha, here is gcr with split libraries (I never did get an answer from upstream or debian) http://pastebin.com/ij5Ub0dT <marry> Does anyone happen to know what the long during beep may be whilst shutting the system down? I use Ubuntu 12.04 (Mint 13), Motherboard NF7-S. And following question; does anyone know how to get rid of this? Thanks in advance! <ricotz> darkxst, hi, gnome-calculator still misses a proper versioned conflicts/replaces <darkxst> ricotz, they were there, but missing the epoch that jbicha added <ricotz> darkxst, right, but it should be conflicts/replaces <ricotz> jbicha, ^ <ricotz> Conflicts: gcalctool (<< 1:3.7.5) <ricotz> Replaces: gcalctool (<< 1:3.7.5) <ricotz> jbicha, darkxst, i would even go that far to add "Provides: gcalctool" <darkxst> ricotz, oh right, all the examples I saw were break/replace, but I can update it <darkxst> ricotz, jbicha http://pastebin.com/eaCXQSdY <ricotz> darkxst, don't add a new changelog entry <darkxst> ricotz, it was uploaded already though <ricotz> no, just update the last one and bump it to raring2 <darkxst> oh ok <darkxst> updated. <ricotz> pushed <jbicha> ricotz: thanks, I think the Provides is unnecessary though <ricotz> jbicha, ubuntu-desktop depends on gcalctool, so you can't actually remove the transitional package <jbicha> ricotz: right but there's no need to remove it in 13.04 #ubuntu-gnome 2013-02-14 <darkxst> ricotz, if you or jbicha update to g-s 3.6.3, make sure to keep git_messagetray_fix_expansion.patch <darkxst> they missed it in the release <darkxst> I would have done the updates myself, but will be away for a few days #ubuntu-gnome 2013-02-15 <jesus0103> amigos quieren saber se la clave pera desbloquear la canaima <jesus0103> la clave es C4na1ma #ubuntu-gnome 2013-02-17 <gabriele_> Hi... <gabriele_> I have got a problem with my webcam... it isn't seen by my pc <darkxst> jbicha, is gnome tweak tool working for you currently? <darkxst> jbicha, http://pastebin.com/JuLaTfzQ #ubuntu-gnome 2013-02-18 <jbicha> darkxst: yes it's broken <darkxst> ok <darkxst> jbicha, seems that set_properties is broken, so probably a bug (or change) in pyGtk <darkxst> jbicha, there is no bzr branch for mutter (in raring)? <jbicha> darkxst: no (except for ubuntu:mutter) since the Desktop Team don't maintain it and there wasn't a team with upload rights for it <darkxst> jbicha, ok, was going to update mutter/g-s to 3.6.3 <darkxst> I will just do mutter as a debdiff? <jbicha> darkxst: great! <darkxst> I can actually test things like this again now, since vmware finally works again <darkxst> (some stupid mesa bug) <ricotz> jbicha, hi <ricotz> jbicha, please notice that the actual diff here doesn't contain any changes https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+sourcepub/2988610/+listing-archive-extra <jbicha> ricotz: thanks, I'll try again <ricotz> jbicha, yw <Guest96819> hello all <Guest96819> does anyone knows where Gnome Subtitles autosaves backup files in case of crash? it has an option about that and i have it enabled but i cannot find the file <darkxst> jbicha, so there is some fallout from the glib updates <darkxst> gnome-shell now fails to build due to removal of GStaticRecMutex <darkxst> (via e-d-s) <darkxst> should I cherrypick the required patch for e-d-s that fixes this <darkxst> or remove the G_DISABLED_DEPRECATED from g-s build #ubuntu-gnome 2013-02-19 <jbicha> darkxst: either way sounds fine <jbicha> darkxst: libreoffice or abiword/gnumeric? <darkxst> jbicha, I would go with libreoffice <jbicha> ok, I'm less concerned about iso size now that Xubuntu will be oversize too <jbicha> it looks like there's concensus (and good reasons) for us to go with Firefox & LibreOffice by default for now <darkxst> yeh seems like the best thing to do <darkxst> btw how much bigger does it make the iso? <jbicha> I don't know, I never set aside time to watch my laptop crunch away for a few hours <darkxst> jbicha, the e-d-s patch is *huge* http://git.gnome.org/browse/evolution-data-server/commit/?id=a22972f4bd76a15729e95a7b9cb75021ed2c38af <darkxst> think I will just turn off the strict deprecation checks in g-s <ricotz> jbicha, jfyi update gnome-desktop with care ;) <ricotz> the new gir1.2-gnomedesktop-3.0 will break gnome-shell <jbicha> ricotz: ok, we'll just update all of it at once (gnome-shell, gnome-desktop, & settings-daemon, & control-center) <ricotz> jbicha, mutter hard-depends on cogl 1.13.x <ricotz> i am currently reverting the quite some things to keep it working <jbicha> ok thanks, if everything in raring is ok with cogl 1.13 we could upload to raring to make things easier <ricotz> jbicha, otherwise this might be at show-stopper <jbicha> 2. or we could maintain all the rdepends in the PPA <ricotz> currently reverting 8 mutter commits and 5 clutter commits <ricotz> and 1 gnome-shell for caribou 0.4.8 <jbicha> we can do caribou 0.4.8 in raring, right? <ricotz> jbicha, most of the rdeps are gnome packages where we want/have newer versions in the ppa anyway <ricotz> (for cogl that is) <ricotz> jbicha, i guess so (caribou) <ricotz> havent look at it, if it isnt such a mess like gnome-desktop it should be safe <jbicha> oh caribou needs libgee 0.8 which has a soname bump and unity is among its rdepends <ricotz> huh, libgee-0.8 has an soname bump? <ricotz> (libgee and libgee-0.8 are parallel installable) <jbicha> well the debian experimental stuff is named differently <ricotz> LIBGEE_LT_VERSION="4:0:2" <ricotz> looks fine <ricotz> libgee-0.8-2 it is <ricotz> jbicha, ubuntu has a separate source package <ricotz> debian experimental is broken in that regard imo <jbicha> ok I see, never mind then <ricotz> but 0.8.2 is enough for caribou? <ricotz> < that is the actual version <ricotz> (not to be confused with the package name suffix) <jbicha> probably, configure.ac just says gee-0.8 <ricotz> ok, then it is fine <ricotz> jbicha, btw, did you ran into trouble like the wallpaper isnt set on startup and not through g-c-c <ricotz> like g-s-d is broken in this matter <ricotz> and of course gtk+2.0 2.24.15 is needed by gnome-themes-standard <jbicha> ricotz: do you have https://launchpadlibrarian.net/130099807/ubuntu-settings_12.10.6_12.10.7.diff.gz installed? I need to explicitly disable that tweak in ubuntu-gnome-settings <jbicha> if you give me a debdiff for gnome-themes-standard 3.6.3 I'll be happy to sponsor it for you <ricotz> jbicha, oh this looks like the trouble <ricotz> jbicha, it will need gtk+2.0 2.24.15 first <jbicha> ah, well we can update that too <ricotz> oh and i meant g-t-s 3.7.x ;) <darkxst> jbicha, can you sponsor my mutter/g-s updates? <darkxst> jbicha, also can you target bug at Quantal as well https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1128804 <ubot5> Launchpad bug 1128804 in mutter (Ubuntu) "Update mutter/gnome-shell to 3.6.3" [Undecided,New] <jbicha> darkxst: yes, can you make a debdiff of just the debian/ directory for gnome-shell? it would be a little bit easier for my workflow <darkxst> jbicha, ok <darkxst> jbicha, http://pastebin.com/zqSrADyC <jbicha> the new patch has a few extra lines from the dep3 template but otherwise looks good <darkxst> jbicha, removed <ricotz> darkxst, is calendar-remove-strict-check.patch really needed? <darkxst> ricotz, yes <ricotz> raring or quantal doesnt have e-d-s 3.7.x <darkxst> e-d-s uses a bunch of deprecated api's <darkxst> oh its caused by the glib update <darkxst> s/oh/no/ <ricotz> ok <darkxst> previously it would cause a warning, rather than an error <ricotz> right, nevermind <ricotz> i have done the same in the my ppa <darkxst> jbicha, oh btw, you did get my second (split libs) gcr debdiff? <jbicha> darkxst: yes but I've been putting off sponsoring it because it's a bit trickier than a regular upload <darkxst> ok no problem <ricotz> darkxst, when there are x.90 tarballs i will try to take a look <darkxst> ricotz, ok thanks #ubuntu-gnome 2013-02-20 <ricotz> jbicha, hi, i will push the gnome-keyring 3.7.5 stack <ricotz> (if ppa uploading works out, seems to be kind of broken sometimes today) <jbicha> ricotz: cool, btw I think we need to remerge gnome-keyring with the version in the PPA <ricotz> jbicha, already did <ricotz> made an ~raring2 earlier <ricotz> gcr is a pita <jbicha> I ppa-purged the staging PPA and when I tried readding it, I got <jbicha> dpkg: error processing /var/cache/apt/archives/gnome-keyring_3.7.2-0ubuntu1~raring1_amd64.deb (--unpack): trying to overwrite '/etc/pkcs11/modules/gnome-keyring.module', which is also in package libp11-kit-gnome-keyring:amd64 3.6.2-0ubuntu2 <ricotz> i know i was told twice today ;) <jbicha> oh I see, thanks :) <ricotz> don't you dare to run away from staging ;P <jbicha> I was testing GTK 3.8/Nautilus 3.8 on raring <ricotz> oh, really <ricotz> nautilus 3.8? <ricotz> doesnt sound like something for raring <jbicha> everything works except for the gnome-shell search provider which unfortunately looks a bit difficult, bug 1130746 <ubot5> bug 1130746 in nautilus (Ubuntu) "Update to nautilus 3.7.90" [Wishlist,New] https://launchpad.net/bugs/1130746 <ricotz> jbicha, i see, but should this be really considered? <jbicha> personally I think it's worth it as the bugfixes are nice to have <ricotz> ok, feature-wise too <jbicha> but that one known regression (gnome-shell search) is enough to block it too <ricotz> i guess not from the ubuntu pov ;) if you insist to get it in before freeze and fix it afterwards <jbicha> I don't know if I can fix it, the search provider api is not documented & there's been quite a bit of refactoring <ricotz> i see <ricotz> jbicha, btw is zeitgeist a core application/library in regards of the unity desktop? <jbicha> yes <ricotz> ok <jbicha> Unity's Privacy Settings panel is mostly a front-end to tweak zeitgeist <ricotz> alright, good to know <jbicha> darkxst: hey they released gnome-shell (502)257-5948 after all <darkxst> jbicha, right <darkxst> after they said they wouldn't! <darkxst> anyway will update #ubuntu-gnome 2013-02-21 <darkxst> meh, gnome-shell get stuck maximised <darkxst> err gnome-terminal <jbicha> GNOME doesn't really coordinate their releases very well <jbicha> gnome-desktop needs gnome-shell which needs mutter which needs an unreleased cogl, and gnome-control-center is 2 days late <darkxst> lol <jbicha> I blame jhbuild for making these broken dependencies easy for maintainers <darkxst> thats about it! <darkxst> and again they will probably have to do another .1 g-s release <darkxst> jbicha, g-s update http://pastebin.com/azupx0pw <arcadia> Hello? <darkxst> jbicha, once we have a RC release of new spidermonkey can we land it in raring? <jbicha> darkxst: we need to discuss that with some other people, probably #ubuntu-desktop during the europe day <jbicha> I had an alternate idea that we could create a mozjs185 source for stuff that wouldn't work with the new version and keep mozjs for the new one <darkxst> jbicha, yeh that would work <darkxst> ricotz, can you repackage mozjs using this tarball? https://bugzilla.mozilla.org/show_bug.cgi?id=735599#c38 <ubot5> Mozilla bug 735599 in JavaScript Engine "Create JS 1.8.7 source release" [Normal,New] <ricotz> darkxst, oh, nice <darkxst> gnome-devel-docs http://pastebin.com/9MUczD8Z <darkxst> libgweather http://pastebin.com/6YVKeUJ4 <darkxst> gnome-contacts fails, because both versions of Gee get pulled in, contacts requires gee-0.8, but libfolks uses gee2 <darkxst> how can I stop that? <jbicha> I think that means you need to build folks against gee-0.8 first <darkxst> ah right, so need to update folks to 0.9 then <darkxst> jbicha, libgee 0.8.4 update could straight into raring? <ricotz> darkxst, hi <darkxst> hi <ricotz> i had a look at the mozjs tarball <ricotz> you are already aware of the missing symlinks irc <darkxst> ricotz, you mean the lib.so.0 etc links? <ricotz> but the library itself is broken while you dropped important LDOPTS <ricotz> (yes those) <darkxst> they wont upstream those links <ricotz> ok, but bug812265-setup-versioning_3.patch is broken <darkxst> ricotz, how so? <ricotz> i guess you ignored this line: <ricotz> $(SHARED_LIBRARY): EXTRA_DSO_LDOPTS += -Wl,-soname,$(notdir $(SHLIB_ABI_VER)) <jbicha> darkxst: yes for new libgee <ricotz> darkxst, this is needed EXTRA_DSO_LDOPTS += -Wl,-soname,$(LIBRARY_NAME).so <ricotz> or something like that <ricotz> i am not sure yet <ricotz> this buildsys is quite annoying ;) <darkxst> ricotz, yes, even the mozilla people don't really understand it :) <ricotz> that is a pity <darkxst> they want to dump all the Makefiles in the future however <ricotz> i see <ricotz> darkxst, will push it to my staging ppa and hoping the best <darkxst> ricotz, did the above EXTRA_DSO_LDOPTS work ? <ricotz> "EXTRA_DSO_LDOPTS += -Wl,-soname,lib$(LIBRARY_NAME).so.0" works, but i guess this won't work for upstream <ricotz> btw gjs build fine against it <darkxst> ricotz, so that is not required upstream then? <ricotz> it is required but not with this name if the symlinks are not wanted <ricotz> but it will actually only work with proper symlinks <darkxst> ok, so just with lib.so <darkxst> oh <ricotz> ld requires an soname e.g. ".0" <ricotz> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html <ricotz> not following this isnt right, and upstream should adapt to it, like they did before <ricotz> why was it is removed anyway? <ricotz> i mean from the patches <ricotz> darkxst, https://launchpad.net/~ricotz/+archive/staging/+packages <ricotz> jbicha, ^ <ricotz> mozjs17 should be something to get into raring <jbicha> I can't make that decision, you'll need to see what the other Ubuntu devs think <ricotz> right <jbicha> it sounds promising though <ricotz> yes, in regards of speeding up gnome-shell <darkxst> ricotz, they claimed that lib.x.y.so is equivalent to lib.so.x.y #ubuntu-gnome 2013-02-22 <ricotz> i am not an expert with this, but i really doubt that <darkxst> well I don't really know <darkxst> other than that tarball builds and gjs builds (in jhbuild) <ricotz> sure it builds, but it needs to be patched for "real-life" usage ;) <darkxst> well upstream seem to think otherwise, and I don't know enough to really argue the point <jbicha> ricotz: by the way, g-s-d from the staging PPA seems to not work with setting a different locale/language (~/.pam_environment seems to just be ignored) <darkxst> jbicha, do I need to file a bug for gee update? http://pastebin.com/QdJqhaVL <ricotz> jbicha, i see <ricotz> darkxst, something broke the g-s gir building, feel free to look at it, should be the fault of gjs/mozjs -- https://launchpad.net/~ricotz/+archive/staging/+packages <jbicha> darkxst: I don't think we need a bug since it's in universe (so I can upload it) & doesn't require a transition <darkxst> ricotz, I know what that is <darkxst> ricotz, http://pastebin.com/aujJKGdR <darkxst> (gi scanner chokes on the -include now in cflags) <ricotz> hmm, interesting, this should be handled in g-i <darkxst> ricotz, yeh, probably. had meant to look into it further, but haven't had a chance yet <ricotz> darkxst, thanks <ricotz> darkxst, i knew you already ran into this ;) <ricotz> bye, g2g <jbicha> darkxst: I think I'll upload devel-docs to raring directly as nothing is 3.8 specific <darkxst> jbicha, ok <britt> hey guys <britt> I really like the new software defaults for 13.04 <britt> good work <britt> I do have a couple of weird issues with the gnome-shell though <britt> I filed a bug about AM/PM time no longer working <britt> and also on my dual monitors, my mouse is getting hung up on the bottom of the primary screen when trying to pan over <britt> it's in the notification area, except the notification screen hasn't slid up yet, it is just perminantly unable to pan from one montor to the next in the bottom 3/4inch of my screen <ricotz> darkxst, hi, did you look into folks 0.9.1? <ricotz> currently doing e-d-s 3.7.90 which is needed for folks, i guess <ricotz> darkxst, folks is uploaded #ubuntu-gnome 2013-02-23 <darkxst> ricotz, oops, I had already done it, but wasnt around last night <ricotz> darkxst, i see, i hope you didnt do e-d-s too? <darkxst> ricotz, no <ricotz> ah, then you looked at folks 0.9.0? <darkxst> ricotz, I used your e-d-s to finish it off this morning <darkxst> must have just missed you ealier <ricotz> ok :\ <ricotz> i looked at empathy, but it seems libaccounts-glib.so.0 is broken <darkxst> damn <ricotz> i think i got it wrong, just a linker problem <darkxst> oh, wow, just realised how long I have been using Linux <darkxst> would be about 16 years, since I first got a slackware CD from somewhere and installed it on my computer <darkxst> jbicha, Finally got around to making a wiki page, https://wiki.ubuntu.com/TimLunn/DeveloperApplication <darkxst> can you add an endorsement :) <britt> hey is anyone else using the fglrx drivers <britt> I am having an issue where the gnome-shell activities window displays solid black background when I have the file manager handle the desktop <britt> the only way for the activities view to show the background is to turn desktop file manager handling <britt> this is in raring btw <ricotz> jbicha, hi <ricotz> jbicha, could you upload this http://paste.debian.net/plain/237380 <ricotz> jbicha, please take this into account when updating to 3.7.90 https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+sourcepub/2996246/+listing-archive-extra <jbicha> ricotz: oh is that the proper fix for the empathy build problem? <ricotz> jbicha, it is a proper fix for everything using libaccount-plugin ;) <ricotz> the empathy problem is an upstream problem <jbicha> ricotz: so we still need your linker patch? <ricotz> yes, it is in the empathy package <ricotz> the libaccount-plugin things is kind of needed for g-c-c, as you see <jbicha> ricotz: unless it's critical, I don't think I can sponsor it as I think the fix needs to be proposed against <jbicha> lp:gnome-control-center-signon <ricotz> jbicha, i see <jbicha> oh and I don't have upload rights to the package itself either <jbicha> http://people.canonical.com/~stgraber/package_sets/raring/ubuntu-desktop <ricotz> jbicha, do you know if there were/are plans to upstream this panel, while empathy would benefit from it? <ricotz> although not sure if vala code would be accepted <jbicha> ricotz: I'm sure the gnome-control-center devs are not at all interested in supporting external panels if that's what you're asking ;) <ricotz> what i am saying it the online-accounts panel is pretty useless, and empathy upstream support UOA, so there were no upstream attempts for the UOA panel <ricotz> (as far you know) <jbicha> I'm not sure Canonical wants that code to be maintained on git.gnome.org, but anyway you're welcome to try <jbicha> I guess you mean moving it into the empathy source? <jbicha> ricotz: I filed bug 1132119 <ubot5> bug 1132119 in cogl (Ubuntu) "Upgrade to cogl 1.13.4" [Undecided,New] https://launchpad.net/bugs/1132119 <ricotz> jbicha, no, i mean moving it to g-c-c like i didnt with the last upload <ricotz> jbicha, ah nice <jbicha> the odds of the g-c-c developers accepting that patch are very low <jbicha> even if it was in C .... they do not support UOA <ricotz> ok, either way, i wanted the functionality back, it was kind of the drawback without it <jbicha> ricotz: do you know whether we're going to want http://git.gnome.org/browse/clutter/commit/?id=4b92d656 for raring? <ricotz> jbicha, i guess, yes <ricotz> otherwise we need to ship clutter in the ppa too <ricotz> does it break things already? <jbicha> I mean for raring directly, and no I haven't seen the problem yet but I don't tweak my fonts either <jbicha> I wasn't planning on uploading the new clutter for raring unless there was a good reason <ricotz> jbicha, ah, i didnt look at the clutter debdiff in the bug <ricotz> i thought you want to revert it for some reason <ricotz> no idea if there is going to be another 1.12.x bug fix release <jbicha> it wasn't backported to the 1.12 branch, not sure if that was an oversight <jbicha> normal distros won't ship the new cogl with the old clutter and gnome-shell anyway; we're just "special" <ricotz> i guess there wasnt much backported anyway, but i think i isnt the best to hold back the new clutter <jbicha> ok can you quantify the benefits? <ricotz> sorry, no <jbicha> I'm thinking it's slightly safer to just stick with the current clutter <ricotz> libgdata snapshot and gnome-documents pushed <ricotz> gnome-contacts pushed <jbicha> ricotz: why did you merge the empathy plugins and can we undo that? <jbicha> never mind <ricotz> btw mutter/rules contain a typo and we really want to have symbols file here again <darkxst> jbicha, gdm http://pastebin.com/FH9aiqdw <jbicha> darkxst: thanks, unfortunately ppa uploads aren't working for me right now :( <darkxst> oh <darkxst> the gdm transition is a mess right now ;( <jbicha> which transition? <darkxst> after login, you get blue-blinds background, then a white screen, then gnome-shell animates in <darkxst> although the white screen presumably comes from gnome-shell <darkxst> https://bugzilla.gnome.org/show_bug.cgi?id=694321 <ubot5> Gnome bug 694321 in general "gray background shows after login before the shell starts up" [Normal,Resolved: fixed] <jbicha> darkxst: are you able to upload to your ppa? <darkxst> jbicha, no apparently not, packages seem to be uploading into a black hole :) <darkxst> jbicha, actually did work, but took a long time <darkxst> baobab http://pastebin.com/KBwTXLvQ <darkxst> gjs pastebin.com/pDjcDY4t #ubuntu-gnome 2013-02-24 <britt> can someone take a look at bug 1132033 for me <ubot5> bug 1132033 in gnome-shell (Ubuntu) "Gnome-Shell activities shows black background with fglrx in raring" [Undecided,New] https://launchpad.net/bugs/1132033 <darkxst> britt, you need to re-enable the background plugin <britt> how do I do that exactly? <darkxst> dconf-editor <britt> and why does it turn off only with fglrx? <britt> with OS drivers, without touching any dconf settings, it works great <darkxst> no idea, but if you have ubuntu-settings installed then it will be disabled <britt> I dont <darkxst> check org.gnome.settings-daemon.plugins.background <britt> I dont think it's a plugin issue. Because when I have fglrx installed and I toggle file manager handling desktop it alternates working normally and not <britt> well I dont have fglrx installed but it says it is active <britt> would fglrx disable that? <britt> that would be odd <darkxst> don't think so <darkxst> but I dont use fglrx <britt> is it possible that there is some incompatibility between the new gnome-shell package that we have and fglrx? Because using gnome-shell 3.6 on 12.10 worked great. <britt> Because I can point out two other bugs with the current version of gnome-shell <darkxst> britt, which version are you using? <darkxst> and what are the other 2 bugs? <britt> I'm using 13.04 raring dev, and running gnome shell 156.14.161.142-0ubuntu1 <britt> and the two bugs are bug 1131104, and another where with dual monitors theres about a 50pixel region on the bottom where the mouse gets hung up on the main monitor <ubot5> bug 1131104 in gnome-shell (Ubuntu) "AM/PM time no longer working in Gnome Shellin Raring" [Undecided,New] https://launchpad.net/bugs/1131104 <britt> and by "hung" up, I mean that in the notification region on the main monitor I cannot pan to the second monitor. It gets stuck on the screen edge <darkxst> first is a pointer barrier <darkxst> I though it had been removed but maybe that happened in 3.7 <britt> perhaps <darkxst> its the same height as the messagetray? <britt> yes exactly the same <britt> though the barrier is up whether the message tray is showing or not <britt> the other bug was where AM/PM time is not working <britt> it is only showing 24 hour time, no matter how it is set in "Date and Time Settings" <darkxst> is there a launchpad bug for the barrier thing? I will backport the patch <britt> no I didn't report that one. Would you like me to? <darkxst> yes <britt> ok give me a few min for the bug report to upload <britt> do you know anything about the AM/PM clock issue? <darkxst> no, but its working fine in 3.7 <britt> is raring sticking with 3.6 or will 3.8 make it into the gnome-3ppa? <darkxst> the ISO's will be 3.6 <darkxst> but 3.8 will be available via gnome3-staging ppa <darkxst> ^are <britt> that's good, though I know a lot of people that use this version of ubuntu don't use the ppa <britt> which means that gnome-shell-3.6 needs to get the bugs worked out :-/ <britt> ok the cursor barrier is bug 1132308 <ubot5> bug 1132308 in gnome-shell (Ubuntu) "~50px pointer barrier in gnome shell at bottom of primary monitor in raring" [Undecided,New] https://launchpad.net/bugs/1132308 <britt> well I hope the AM/PM issue and the fglrx issue get fixed by launch. That would be unfortunate if they weren't <britt> I dont know what I can do to help though <jbicha> britt: could you report the time bug too? <britt> that one is reported bug 1131104 <ubot5> bug 1131104 in gnome-shell (Ubuntu) "AM/PM time no longer working in Gnome Shellin Raring" [Undecided,Confirmed] https://launchpad.net/bugs/1131104 <darkxst> brit is time broken on screenshield also? <jbicha> darkxst: gnome-shell 3.7.90 is in the staging PPA if you want to see if that improves the login transition for you <darkxst> jbicha, that patch that fixes that landed after .90 <britt> is the gnome-shell package in 13.04 the same as in 12.10? <darkxst> britt, mostly yes <britt> or at least in the gnome3 ppa for 12.10? <britt> hrm, in 12.10 I didn't have any of these same bugs <britt> does that mean that the issue is in a different package? <darkxst> is the clock working in the screenshield? <darkxst> looks like the time is pulled straight from gnome-desktop <britt> is that the same as the lockscreen? Both the login screen and the lock screen show the same 24 hour time, regardless of the settings in date and time <darkxst> settings panel display correct though? <britt> yes in the settings panel the toggle switch is set to AM/PM <britt> and it shows it in am/pm in the settings panel <britt> though the actually top panel/lock screen/login screen all show 24 hour time <darkxst> try this in lg <darkxst> wc = new imports.gi.GnomeDesktop.WallClock() <darkxst> wc.clock <britt> where should I paste that coad? <britt> code* <darkxst> Alt+F2, lg <britt> all that did was print me the date and time (in 24 hour time) <darkxst> so gnome-desktop is broken <darkxst> no gnome-shell <darkxst> or perhaps g-s-d <britt> I dont know :-/ <britt> dconf shows 12h time, so whatever it is isn't listening to dconf <britt> the other settings are working though like "show second" and "show date" <darkxst> perhaps this https://bugzilla.gnome.org/show_bug.cgi?id=690703 <ubot5> Gnome bug 690703 in calendar "Date and AM/PM missing from top bar" [Normal,Resolved: fixed] <britt> is there a way we can pull in that fix? <darkxst> sure <britt> http://git.gnome.org/browse/gnome-desktop/commit/?id=0940370f82730359a7771aae750136e3fe6bfaa9 <britt> seems like it's just a boolean value set incorrectly <britt> at least from what I am reading <britt> hey I made progress on the fgrlx issue in gnome-shell <britt> https://bugs.freedesktop.org/show_bug.cgi?id=56657 <ubot5> Freedesktop bug 56657 in xlib backend "cairo produces black background in the Activities overview in gnome-shell with AMD catalyst driver" [Minor,Resolved: fixed] <britt> apparently it is attributed to cairo <britt> fglrx (and apparently xf86-video-intel also) and cairo 1.12.6 aren't playing nicely <britt> they reported rolling back to cairo 1.12.2 fixes the issue <britt> hrm it looks like we are on 1.12.14 <britt> ugh <britt> well maybe a newer fglrx version will work. they're still running a super outdated build which is crap <darkxst> fglrx is just crap ;) <britt> lol I know. I need it for my graphics card to do anything remotely usefull with 3d though. And 12.10 and fglrx worked fine together <britt> and the 13.1 drivers were supposed to make things better, but for some reason ubuntu refuses to upgrade fglrx, even in the fglrx-updates package which is MEANT for updates lol <britt> well if the issue is with cairo...then I have no clue on who would help fix this bug <darkxst> britt, attach the upstream bug to your report <britt> I am. Can you possible bring in the cairo and the fglrx people to the bug report? I cannot change it's status <darkxst> britt, you should be able to add them using "also affects distribution" <britt> nice thank you. I didn't know I could do that <britt> well hopefully that gets worked out. TBH i'm hoping that a new fglrx version will work the issue out passively <britt> we'll see <britt> is there anything else I should do for the other two bugs or do you and jbicha have it? <darkxst> britt, you could try fglrx on xorg-edgers ppa <darkxst> britt, looking at clock thing now, that other patch doesnt apply in 3.6 <britt> ergh <britt> I did use the xorg-edgers ppa, it's the same issue. They're also running the same fglrx version (though it's marked as beta6, so I dont know what that is) <darkxst> it should be the latest fglrx available <britt> thank you for looking into these issues. I, and quite possibly everyone, greatly appreciate your help <britt> it isn't unfortunately <darkxst> britt, you could ask ricotz next time he is around <britt> maybe theres probems with newer fglrx versions and they're holding off on it. Is rocotz an amd user? <britt> ooh I now see hes the maintainer for the edgers ppa haha <darkxst> not sure, but he uploaded the fglrx <britt> I maybe will ask him <britt> he is also the uploader for cairo <britt> maybe I can get two birds with one stone <darkxst> britt, just pushed an updated gnome-desktop to my
{'channel': 'ubuntu-gnome', 'month': 2}