[01:17] 'Tis the season for SRU requests! [01:22] ... tra la la la la, la la la la? [02:59] Oh, pretty new raring wallpapers. I missed that. [03:45] duflu: Oooh, yeah! [03:46] robert_ancell: Fix it so that dynamic wallpapers work in unity-greeter, damnit :) [03:46] RAOF, fix it yourself :) [05:12] pitti, is a g-i update coming? [05:15] Does Totem count as 'desktop' or is there a more relevant place to talk about it? (I'm wondering if I should be making more noise about bug 1158594, as a regression in the default video player is fairly notable) [05:15] Launchpad bug 1158594 in totem (Ubuntu) "Video is too yellow/bright, as if a grossly exaggerated gamma transform is applied (raring regression)" [Undecided,New] https://launchpad.net/bugs/1158594 [06:00] Good morning [06:00] darkxst: yes, working on it; it needs glib 2.36.0, so that needs to build in Debian exp first [06:14] pitti, ok np [06:14] g'day [06:15] pitti, another question, we currently patch gvfs to install the new goa modules, would there be some way we can incorparate this into the main archive? http://pastebin.com/2zckE7s1 [06:29] darkxst: I'm not entirely sure; we certainly want that for Debian, though [06:29] darkxst: can we wait with this question until seb128 gets online? [06:30] pitti, sure [06:35] darkxst: that doesn't need any additional build deps? [06:35] like libgoa-1.0-dev ? [06:35] pitti, yes [06:35] darkxst: so that's not in your debdiff [06:35] Pitti, sorry that was an old debdiff [06:37] darkxst: ah, I can apply it to Debian for now, debian has 3.7.91-1+b1 [06:38] pitti, ok this is the right one http://pastebin.com/PmBkKFWr [06:38] darkxst: http://paste.ubuntu.com/5651492/ ? [06:39] pitti, yes looks good [06:39] darkxst: configure.ac checks for that version [06:39] ok, test-building [06:39] * pitti uploads g-i 1.36.0 to Debian exp, will sync in a few hours when it's imported into LP [06:41] yes, I had the version check in there one stage, but lost it at some point [06:48] darkxst: builds fine, I committed that to the Debian packaging branch [06:49] we can't build that in Ubuntu yet as our goa version is too old [06:49] anyone here have ops in #ubuntu-server? plan_1 probably needs a +q or +b [06:50] yes I know that, but its painful trying to keep it up to date in the ppa. [06:55] I guess I was kinda hoping we could either update goa, or put some if $GOA_VERSION magic so its just a rebuild required for each update [07:10] darkxst: I don't think it's a problem to update goa in raring, as we don't use it in the default desktop [07:10] we should coordinate that with seb128 [07:12] ok [08:04] good morning [08:39] hey desktopers [08:42] g'daay === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [09:33] seb128, hi, was talking to pitti before about updating goa [09:33] bonjour seb128 [09:33] and adding the new goa modules to gvfs [09:38] darkxst, pitti: hey [09:38] darkxst, I was pondering just dropping goa and building eds and co without it... [09:39] since we use uoa in Ubuntu [09:39] seb128, we kinda need it though [09:39] or not [09:39] we have uoa [09:39] seb128, as in ubuntu GNOME [09:40] "drop" would mean "drop build deps and move package to universe"? [09:40] and re-patching gvfs everytime there is an update is a pain [09:40] pitti, yes [09:40] well, like that we now need to re-patch gvfs from debian on each update, and you need to re-re-patch it back to the Debian version [09:41] so for GNOME ubuntu it would be better to directly take the debian exp version [09:41] pitti, btw your gvfs update brings libsystemd-login0 in, is that wanted? [09:41] seb128: not deliberately [09:42] pitti, Debian added a build-depends on libsystemd-login-dev [09:42] (for raring, anyway) [09:42] pitti, which is in the version you used to do the 1.16 update [09:43] ah, it's used in the udisks2 monitor [09:44] it doesn't change behaviour if logind is not running, but if the extra depends is a problem I can take it out again [09:44] darkxst, pitti: in any case there is a limit of how much we can do GNOME without Ubuntu bits in Ubuntu, it's going to get harder and harder [09:44] seb128: actually, with ubuntu moving away from gnome piece by piece it should get easier again? [09:44] darkxst, pitti: like if apps like shotwell have a build-time option for goa or uoa we will build them with ubuntu online account, not goa [09:44] or you need 2 builds of shotwell with different flags/patch [09:44] it's a pain to start "forking" apps [09:45] shotwell as an example [09:45] going to be the same of e-d-s and other stuff [09:46] seb128: uploaded gvfs without the systemd-logind dep [09:46] many of these things are dynamically loaded modules? [09:46] pitti, danke [09:46] seb128: so that you get your 24 kB back :) [09:46] darkxst, no, some are, but most software don't want that complexity [09:47] so it seems to me that dropping goa into universe, updating it to 3.7, and using it for ubuntu gnome only seems the right thing? [09:47] pitti, ;-) I was more unsure if that would have any side effect, I noticed because gvfs was on hold in my "upgrade" [09:47] seb128: no, it doesn't [09:48] pitti, don't you need libsoup 2.42 for goa 3.7? [09:48] peut-être, je ne sais pas [09:48] I think you do [09:48] * seb128 checks [09:48] libsoup-2.4 >= 2.41 [09:49] yep, you do [09:49] too late to update that one in raring though [09:49] they went through quite some changes this cycle [09:49] like they dropped libsoup-gnome and merged the features in libsoup [09:49] and that impact on several components in the default installation [09:50] we can sort that out in sleazy, though [09:50] yeah [09:50] and raring will stay reasonably stable now, so ubuntu gnome should have little trouble [09:50] gnome have a habit of breaking stuff post-freeze ;( === tkamppeter_ is now known as tkamppeter [10:10] pitti, seb128, what are the chances of landing the newly release spidermonkey and updated gjs in universe for raring? [10:11] darkxst, that was briefly discussed on the lists a few weeks ago, nobody seemed interested or picked it up, I guess it's late now [10:11] you can try asking for a FFe [10:12] seb128, I know its late [10:12] has taken about 4 months of prodding mozilla people and even patching their build systems to make it happen [10:12] I'm not fond of adding another version of a javascript engine without transitionning/replacing the old one [10:13] seb128, except the benefits of the new engine for gnome-shell/gjs are huge [10:13] it's not like g-s was not working well atm [10:13] seb128, its leaks like a sieve [10:14] and there are regular deadlocks caused by GC [10:14] will teach them to write their shell in js? :p [10:14] joke aside, it's not my call [10:14] file a FFe if you feel strongly about it [10:18] seb128, couchDB cannot transition to the new spidermonkey [10:19] darkxst, so we have an issue.. [10:19] (if we still care about couchdb) [10:19] they are using illegal JS syntax as a core feature of their user plugin system [10:19] I don't really care about couchdb, but I presume others might [10:20] yeah [10:20] as said, not my call [10:20] file the FFe and see what they say [10:20] ok will do [10:20] security might be fine with having 2 copies of libgjs in universe [10:21] we don't need 2 copies of gjs [10:21] sorry, libmozjs [10:21] the new gjs works perfectly with g-s 3.6 [10:21] which is actually the security sensitive bit I guess [10:22] I would have thought the security sensitive bit, is downloading random g-s extensions? [10:22] i.e from outside the vetted code on e.g.o [10:22] you are speaking about gnome-shell there [10:23] not about having 2 copies of a javascript engine in the archive [10:23] which might each have security issues in their code [10:24] and might be used by random users/apps [10:24] ideally we would drop the old one and migrate to the new one and support only that one [10:24] but I don't see that happening for raring [10:24] especially that stuff like couchdb can't be easily ported as you said [10:27] well I am no security expert, but that seems like the biggest weak point, its really not hard to get web folks to excute random shell command, and/or download from random ppa's etc. [10:28] anyway will file a FFe [10:40] xnox, ping? [10:40] mhr3: hola =) [10:41] xnox, hey, you mentioned you'd be able to help us with s-c review and generating the indices, right? [10:41] mhr3: yes. [10:41] (cc: jamesh) ^ [10:41] xnox, i think this will need some help and review - https://code.launchpad.net/~jamesh/archive-index/app-install [10:42] mhr3: I'm confused which branch it's based on.... [10:43] on the one mvo suggested [10:43] afiar [10:43] yeah =) me got merge-proposal wrong way around. [10:44] xnox, i see it just got mp-ed, so pls take a look at it, we'd need it asap [10:45] mhr3: yeah, looking. [10:45] mvo: I think I did last extraction the wrong way.... =( [10:45] xnox, thx a lot! :) [10:47] mhr3: right, I'll generate new app-install-data, send it to a ppa or somewhere & then you will be able to test s-c. Do we already have scopes in the archive? [10:47] or do I need to scan the test ppa? [10:47] xnox, you need the smart-scopes ppa [10:47] https://launchpad.net/~ubuntu-unity/+archive/experimental-prevalidation [10:48] ack. [10:55] seb128, I suspect I would bring down launchpad if I provide a debdiff of the new spidermonkey engine vs 185 ;) (as requested in ffe wiki [10:57] hmm or I misread they want a diff of the non-existant upstream changelog [10:57] darkxst, the goal is to try to figure out what changed and how risky the changes are [10:58] seb128, even the mozilla guys can't really keep track of what changed! [10:58] darkxst, doesn't speak good for your ffe... [10:58] that doesn't seem like the sort of change we want to see landing late [10:59] 2 years is a long time! [11:00] right [11:01] anyway, I guess we could just land it in the ppa, for now [11:02] but the issue around having 2 seperate mozjs version will continue well into S [11:03] right, we need to decide if that's an issue or not [11:07] seb128, ok, so how do we go about that ? this is going to likely be a continuing theme, with hopefully regular release from here on in [11:07] i.e. mozjs24 in November will break, everything again [11:08] well, if we could keep only one or two versions at a time that would be good [11:08] we just need to figure out how we roll [11:09] and I guess their is a catch 22 issue, most projects wont port to a version, until the distros carry it [11:12] would be easier if they had a forward compatibility story... [11:12] although, on the plus side, once all the upstream patches filter down to the various releases, they should actually be esr point releases [11:12] but go GNOME for basing their shell on an abi unstable stack [11:12] I pretty sure all this happened after the fact [11:14] i.e mozilla abandoning any promise of ABI/API stability for the JS engine, all happened well after GNOME had already locking into their choice [11:16] and actually porting gjs was not that bad, although the complete lack of documentation probably made it take 3x as long as it might have [11:17] I have *spent* far more time, bugging mozilla for the release! [11:27] anyway I can't really speak for the history of all of it, but my understanding is, that at the time gjs was far more mature than any of the alternatives [11:28] right [11:28] well, the bottom line is that the lower number of javascript engines we have to support the better [11:28] but I'm sure we can get the new version in [11:29] it's just really late for raring [11:31] things move slowly in mozilla land! [11:32] the release was supposed to happen mid Feb after the patches landed [11:32] and actually most of the patches havent even landed yet even though they are r+ [11:33] anyway regardless of all that, at the very least it would be good to have it there for S opening [11:33] upstream have already switched to it for gjs master [11:34] although I suppose that doesnt even matter, since ubuntu is now a cycle behind ;( [11:37] darkxst, right [11:37] anyway I am now going to smash both my monitors since they keep turning off every 3secs, and then go to bed [11:37] darkxst, thanks for the work on that and sorry things are not easier to land [11:39] seb128, I understand its way late in the cycle now. [11:39] darkxst, it's also that gnome-shell/gjs isn't our priority [11:40] so people will pay less attention to those [11:40] seb128, well that I don't get, I mean obviously we would maintain the packages [11:41] darkxst, "we" being? [11:41] seb128, ubuntu GNOME [11:41] gnome3-team [11:41] darkxst, you are wanting to support security fixes for libmozjs and all its rdepends in the archive? [11:41] including couchdb etc [11:42] if you throw a javascript engine in the archive you can't claim it's for gnome-shell only [11:42] you need to proper support it and all its users [11:42] hmm right, ok scrap that idea! [11:42] ;-) [11:45] that said, I don;t see any security fixes in the 185 packaging [11:45] no, because mozilla probably doesn't do security work for standalone libmozjs [11:45] so perhaps I just wait for mbiebl package it up, then we can sync it ;) [11:45] which is another good reason to try to limit the use of that lib [11:46] seb128, they have point releases every 6 weeks in the esr branch, which are purely just security fixes [11:47] they do roll releases and ensure abi compat for those? [11:48] they have promised to roll releases, once all the versioning stuff had landed [11:48] ok, let's see how that goes [11:49] and abi compat should be assured, unless they really had to do something strange to fix the security issue [11:49] seb128, I would guess more likely to start in 24 series [11:49] let's see [11:50] darkxst, thanks for the details [11:50] lunch time here [11:50] bbiab [11:50] bed time here, cya === MacSlow is now known as MacSlow|lunch === alan_g is now known as alan_g|lunch [13:07] ughhhh === timchen`` is now known as timchen119 [13:10] desrt, bad day ? [13:10] sick :( [13:10] uhh, go to bed === MacSlow|lunch is now known as MacSlow [13:18] ah yes, finally, we can be free from the tyranny of atd [13:19] lol [13:19] did it attack you in your sleep and the like ? [13:20] no, just commenting on the thread on -devel about removing atd [13:20] yeah [13:20] i was just wondering about "tyranny" ... i mssed the irnoy tags i think [13:20] *missed the irony [13:22] every time we remove something "UNIX" I feel a little bit of pride and happiness [13:22] I guess it's just me [13:23] jcastro_, you probably like systemd then ;-) [13:23] let's not get crazy [13:23] but I'm sure we can replace atd with systemd right? [13:23] yes. it does that too. [13:23] of course. [13:24] if i get some time this weekend i'm going to rip out my sink in the kitchen [13:24] because, you know..... systemd now === alan_g|lunch is now known as alan_g === m_conley_away is now known as m_conley [13:45] desrt, when does systemd grow an input layer and display server btw ? [13:46] :) [13:46] ogra_: i give it another year, tops [13:46] lol, not friday guys! [13:46] maybe sooner if we release mir early =) [13:46] * ogra_ is sure its friday somewhere ... in a parallel universe :) [13:51] well bother. i just installed skype from software-center without any crashing. only problem was that the icon on the launcher never updated, so i thought it wasn't actually installing it [13:52] dobey, hey [13:53] dobey, I assigned you 2 s-c bugs that were ranking high on the errors tracker, I hope it's ok [13:53] dobey, let me know if you prefer those assigned to a team or tracked differently [13:53] oh, it seems all the reports are from 12.10 [13:57] dobey, the bugs I assigned to you? should not, I did pick "13.04" as release on e.u.c [13:57] but maybe nobody reported them to launchpad from raring [13:57] well, there are no dups on launchpad it seems [13:59] but https://errors.ubuntu.com/bucket/?id=software-center%3Atrans-failed%3Aerror-dep-resolution-failed shows "Ubuntu 12.10" for almost all the errors from today and yesterday [14:00] also, the infinite scroll stuff is annoying as heck, because it's slow and causes the footer to constantly move down :) [14:02] "openswan: racoon: Depends: ipsec-tools (= 1:0.8.0-14ubuntu2) but 1:0.8.0-14ubuntu2 is to be installed" [14:02] lol wtf [14:02] that's the only one i've seen so far on 13.04 in that list, and that's on armhf [14:03] dobey, well, the bug might be the same on 12.10 [14:03] i'm sure it is [14:03] dobey, the table shows 184 reports on 5.5.4, 91 on .5, 4+7 on .6 [14:04] it's just that there is a magnitude less users on raring [14:06] but errors.ubuntu.com makes it hard for me to find useful data on it, because there are no dupes on lp, and the bug on lp only shows one of the failure cases, which when i tried, doesn't fail. [14:08] dobey, that's a side effect on a package being broken/not installable? [14:12] seb128: that specific crash seems to be, yes [14:12] ok [14:13] or at least, it's caused by install failure. i didn't go through all the error reports, but the ones i looked at were package not installable issues [14:38] desrt, did you have any distro specific systemd patch for "can-ntp" to work? [14:39] no [14:39] it's implemented the same way as it is upstream [14:39] and lennart took my patch into the new version of systemd (which already had a release) [14:42] desrt, we have 198 which includes it [14:42] desrt, I'm wondering why clicking on the property in d-feet doesn't give me a value [14:42] desrt, or rather I'm trying to figure why I can't select "time from internet" in the indicator-datetime g-c-c panel [14:46] awesome, [14:46] /dev/sda2 454G 5.3G 426G 2% / [14:46] \o/ [14:48] nice [14:48] * seb128 wants [14:51] heh [14:51] seb128, [14:51] Mem: 15924 5131 10792 0 161 3845 [14:51] ;) [14:51] chrisccoulson, make sure to watch your laptop at the next rally :p [14:51] hah [14:53] chrisccoulson, I guess it's nice and smooth, especially with a new install ;-) [14:53] seb128, yeah, it's running quite slick === davidcalle_ is now known as davidcalle [15:04] seb128: hmmm. [15:04] seb128: are you sure timedated got restarted properly after the upgrade? [15:05] i did some testing of the old systemd with our vendor patch against our datetime panel [15:05] and also did some testing of the new patch against fedora with upstream gnome panel [15:05] in both cases it properly detected the availability of ntp [15:06] and fwiw, the 'time from internet' option in the panel is only disabled when the property exists _and_ is false [15:06] so a missing property would not cause it to be greyed out [15:07] * desrt updates his raring [15:09] is there a command that essentially produces the output of for i in `dpkg -l | cut whatever`; do apt-cache policy $i | grep '**'; done, but also with the package name in question on the same line? [15:10] desrt, we have the new systemd/timedated for some days and I reboot every morning [15:10] desrt, what are you to do with that command? see if you are using ppa versions? [15:11] ya. exactly :) [15:12] that_command | grep ppa... would be great [15:13] desrt, dpkg -l | grep ~ [15:13] if ppas are not crazy they use a version with ~ [15:14] my ppa is often crazy :) [15:14] plus... the distro often uses those versions too [15:19] desrt, we don't record the source of the packages [15:19] desrt, if you use the same version as the archive no tools will be able to tell you where you got the installed one [15:21] huh [15:22] then how does apt know to reinstall the archive version over top of he same version that i build locally? [15:22] desrt, so I guess you are saying it works for you? [15:22] seb128: it worked when i tested. i'm updating everything so i can test again. [15:22] desrt, does it reinstall versions? could be luck or md5sum [15:22] but the md5 just tell you that your version is not the archive one [15:23] not where it's coming from === alan_g is now known as alan_g|afk [15:33] desrt, let me know if you get the bug/or not and if I can help testing [15:37] seb128: what is the bug, specifically? 'automatically update time from internet' is greyed? [15:37] in current raring? [15:37] desrt, yes === alan_g|afk is now known as alan_g [15:43] seb128: seeing the issue. will investigate. [15:45] desrt, [15:45] $ dbus-send --print-reply --system --dest="org.freedesktop.timedate1" /org/freedesktop/timedate1 org.freedesktop.DBus.Properties.Get string:"org.freedesktop.timedate1" string:"CanNTP" [15:45] method return sender=:1.546 -> dest=:1.561 reply_serial=2 [15:45] variant boolean false [15:45] seb128: interesting. looks like upstream changed behaviour in timedated [15:45] [15:45] ah [15:45] it looks for ntp implementations by searching in /etc/systemd/ntp-units.d [15:45] this allows you to have ntpd vs. chrony, for example [15:45] ohmy [15:46] it used to default to 'ntpd.service' if none was found [15:47] seems that the new version no longer has the default, so if we have no files there, it assume we have no ntp implementation [15:48] i'll have systemd-shim install a file and that ought to fix it [15:50] oh good... it allows an alternate path in /usr/lib as well [15:50] * desrt hates having crap in /etc by defaul [15:59] seb128: is there qt/kde messaging-menu for KDE plasma available? cause libindicate works on KDE upstream release, but I can't seem to find the messaging-menu port for kde. [15:59] not that I know [15:59] larsu, ^ [16:00] seb128: i ported a few things to messaging-menu & dropped pointless build-deps on linindicate from things that were ported. Thus reverse-depends src:libindicate is getting very small. [16:00] good [16:11] xnox: thanks! There are no qt bindings yet as far as I know... [16:15] larsu: so only messaging-menu apps work on Unity/Gnome desktop && only libindicate apps work on KDE desktop. \o/ [16:15] .... wait /o\ === alan_g is now known as alan_g|vt === alan_g|vt is now known as alan_g [16:49] desrt, you around? [16:49] desrt, I'm being pestered by this SIGBUS error :( [16:50] I don't know what but something must have changed recently to start causing this more and more. [16:51] Maybe there was an update to gnome-screensaver that makes it want to read dconf values while the screen is locked or something like that. [16:52] Anyway, I'm going to try to find a way of catching the SIGBUS thing, that you already told me was not easy at all, so I'd appreciate any help. [16:53] marga, hey, re your -data missing package issue, the arch all binaries are built on i386 and only listed in the debs resulting from the build on that arch [16:54] if you went in the launchpad ui to download the debs [16:54] seb128, yes, I figured it out eventually, but was very confused for a while :) [16:54] it can be confusing indeed [16:54] I was particularly confused about the package not being in the build-log [16:55] Now it makes sense, thanks. [16:56] marga, yw [17:02] marga: :( [17:03] marga: all i can say is that this is fixed in raring :/ [17:03] and it's not easily backportable [17:04] cyphermox: some initial working testcases for wpa_supplicant, FYI: http://people.canonical.com/~pitti/tmp/networktest.py [17:08] happy Easter holidays everyone! I'll be back next Wednesday, off IRC; I'll read email sporadically [17:11] seb128: so i can fix this issue fairly easily, but there is a bit of a packaging issue [17:11] desrt, oh? [17:13] seb128: systemd services (timedated) will look in /usr/lib for the ntp unit files... but you setup the libdir of systemd-shim for multiarch [17:13] I don't set up anything, debhelper does that [17:13] it's easy enough to override the configure call to use the correct --libdir= [17:13] I will put it back to /usr/lib [17:14] i could also just hardcode the install path for the unit file [17:14] since according to the documentation it uses a fixed path [17:14] so installing to a fixed path probably makes sense [17:14] namely /usr/lib/systemd/ntp-units.d/ [17:14] desrt, wfm [17:14] k [17:15] i'll do a new systemd-shim soon [17:15] thanks for the catch... as i said, i tried the patch with fedora and new systemd and ubuntu and old systemd... not the new systemd on ubuntu :) [17:19] yw ;-) [17:24] seb128: is my installing files into /usr/lib directly going to cause trouble to your multiarch stuff? [17:24] like some failed lintian check or so... [17:24] * desrt updates the packaging for himself to see [17:26] desrt, no [17:27] the packaging doesn't care about the destination [17:28] it cares about files that are make installed and not in any binary === rickspencer3_ is now known as rickspencer3 [17:33] seb128: amd64 these days? [17:33] can you take http://people.gnome.org/~ryanl/systemd-shim_2-0ubuntu1_amd64.deb for a spin? [17:34] (hint: make sure you restart systemd-timedated) [17:34] desrt, you told me that the fix did not fix the home going MIA. [17:34] desrt, does it? [17:34] marga: stops the SIGBUS [17:34] how? [17:35] because it stops the use of mmap for touching the homedir [17:35] and maps out of the xdg runtime dir instead [17:35] desrt, no, i386 [17:35] my concerns about it not being completely fixed is that the daemon may still misbehave a bit if it tries to do an update and it finds it can't access ~ [17:35] seb128: damn :p [17:35] desrt, just give me the tarball/source, I will give it a try in half an hour [17:35] need to run out for a bit [17:35] okay [17:36] thanks [17:36] i'm getting lars to check [17:36] he have amd64 [17:39] desrt, and you say it's very hard to backport this to precise? [17:39] yes [17:39] dconf underwent quite a lot of changes to make this possible [17:39] uhm... [17:40] a backport would basically look like an SRU of the new package [17:40] and it wouldn't even help you that much because the new code uses a keyfile for settings on nfs, as i mentioned before [17:40] so you'd have this backcompat issue [17:40] right [17:41] well, I'll take a look at the new code tomorrow (I'm too jetlagged today to do anything that requires my brain to actually think), see how a patch to fix the mmap would look without changing the rest. [17:42] seb128: larsu confirms it works... i'll do a new upstream release now [17:43] marga: you'll have to write new code [17:43] the way the old system works: each app directly mmaps ~/.config/dconf/user [17:43] so when the NFS homedir goes away, every process is in danger of SIGBUS [17:44] the way the new system works: dconf-service creates a file in /run/user/desrt/dconf/user and every process maps that [17:44] then dconf-service keeps /run/user/desrt/dconf/user in sync with ~/.config/dconf/user.txt [17:44]