=== robru is now known as robru|packing === m_conley_away is now known as m_conley [04:42] Bonjour [04:45] pitti: bonan matenon [04:46] desrt: ton Esperanto sonne bien! [04:46] pitti: via esperanto ne estas bona. [04:46] desrt: comment sont tes lessons? [04:47] desrt: it looks quite similar to latin/spanish [04:48] it appears similar to a lot of things, depending on the sentence :) [04:53] desrt: so I guess that makes it both easy and hard to learn at the same time? [04:54] hard because you keep mixing it up with actual Spanish/French/Latin? [04:54] pitti: it's designed to make it approximately equally easy for speakers of many different language groups to learn [04:54] mostly european language groups, mind you... [04:55] so it has obvious influences from the romance languages, slavic languages, german and english [04:56] 'havu bonan tagon' (have a good day) is a lovely phrase for demonstrating that :) [04:58] ('have' from english, 'a' from polish, 'good' from french, 'day' from german) === m_conley is now known as m_conley_away === Ursinha_ is now known as Ursinha === Quintasan_ is now known as Quintasan [06:18] good morning [06:20] bonjour didrocks, ça va? [06:21] pitti: ça va, et toi? [06:22] un peu fatigue; Je suis allé dormir plus tard [06:22] (TB meeting) [06:22] and I couldn't sleep any more this morning; darn brain! [06:26] argh [06:26] take it easy for today :) [06:32] Good Morning people. [06:41] didrocks: Good morning; was your ping yesterday for any deep and meaningful purpose? [06:42] hey RAOF ;) It was more for poking about who should I ping on the SRU team? We have 2 SRUs of the unity/compiz stack waiting for 2 weeks for precise and a week for quantal. This is blocking the next backport which is the SRU for fullscreen video games [06:42] hey BigWhale [06:43] didrocks: We've got a weekly schedule for SRU processing; its on the wiki. [06:44] RAOF: ah, indeed, found it on the wiki page. And Tuesday is you! :) [06:44] Indeed. [06:44] By “Tuesday”, though, it means “Tuesday, UTC-5 or so”; I actually do it on Wednesday morning, my time :) [06:45] RAOF: ah, ok, so tomorrow morning :) [06:45] Yup. [06:45] RAOF: should I let the natural process happen or should I give you the links? [06:46] I'll see them in the pending-sru or quantal/precise unapproved queues; no need for links. [06:46] I *am* very happy to be pinged about things which should be processed swiftly. [06:47] ok, I was trying to not bother you too much, thanks RAOF :) [06:49] On my SRU processing day I welcome pings for processing; it's useful to know what's more important, and if someone's pinging then I can poke questions at them, too. [07:33] ah, there we have him! :-) pitty: can/could umockdev simulate plugging and removing devices? [07:35] ...or is that too much tied to the netlink sockets, kernels and daemons? [07:38] hey hasselmm (I assume you meant to ping me) [07:38] hasselmm: it does that already, yes [07:39] hasselmm: it intercepts access to the netlink socket and does its own uevent forging [07:39] pitti: oh! awesome! [07:39] hasselmm: NB that umockdev doesn't have an official release yet; its still in the "experiment/research" stage, and I haven't had time to work on it in the last two months [07:40] but it's definitively on my TODO list [07:40] hasselmm: right now you can simulate simple stuff like batteries or raw USB devices (lsusb/libusb work), as well as generic uevents [07:40] pitti, this is the latest code? https://github.com/martinpitt/umockdev [07:40] hasselmm: correct [07:41] pitti, what i need are block devices. but guess now i am sufficiently teased to throw away my minimal mocking/add it to umockdev [07:41] (if even needed) [07:41] hasselmm: there's a dump tool which you can run on an actual device of your's, into a text file, and replicate that in a mock env [07:41] hasselmm: for block devices in particular I'd recommend scsi_debug [07:42] hasselmm: intercepting and emulating the whole block/scsi/etc. stack is going to be a huge work, and I'm not sure that it's worth it given how well scsi_debug works [07:42] hasselmm: I should join #gnome-hackers again, indeed; usually I only hang out in #introspection and #python [07:43] hasselmm: NB that umockdev doesn't intercept /dev/ and ioctl yet [07:45] pitti: isn't scsi_debug a kernel driver? [07:45] hasselmm: yes, it is; so you need root privs [07:45] pitti, ok. so i still need umockdev :-) [07:45] hasselmm: I'm using it in the udev and gvfs tests [07:45] hasselmm: ah, ok; what are you actually trying to test? [07:46] hasselmm: as I said, rebuilding the whole block layer in userspace sounds painful [07:47] really just need to get notified of block device addition and removal [07:48] hasselmm: via uevents or via udisks d-bus messages? [07:50] pitti, good question actually :-) [07:51] hasselmm: so, merely synthesizing the uevents, or mocking udisks to emulate adding/removing a devices is rather easy; but you couldn't actually do anything with those fake device of course, as they don't exist [07:51] hasselmm: so if you only want to test the hotplugging code path, that should work [08:00] pitti: oh. gunixvolumemonitor just monitors /etc/fstab (via gunixmounts), and hard-codes the fstab path. so i am lost anyway. [08:01] hasselmm: on the gvfs level it uses udisks2 [08:01] so if you use a mock udisks2, it should reflect on the gvfs level [08:22] desrt: eek, dconf-service segfaults in my jhbuild [08:49] desrt: ok, stacktrace, reproducer, analysis, and workaround sent to https://bugzilla.gnome.org/show_bug.cgi?id=689136 [08:49] Gnome bug 689136 in writer "Crash in dconf_writer_real_end(): change is NULL (when $XDG_CONFIG_HOME/dconf does not exist)" [Normal,Unconfirmed] [09:05] hey desktopers [09:06] salut seb128! [09:06] seb128: desktop meeting reminder [09:06] lut didrocks, thanks ;-) [09:06] yw [09:10] good morning everyone [09:10] hey [09:14] hey chrisccoulson, Laney, how are you? [09:17] tired. but there is tea so life is good :-) [09:17] holiday next week ;-) [09:17] how are you? [09:17] I'm good thanks [09:18] Laney, holiday next week? or holidays starting next week for all of decembre? [09:18] seb128, yeah, good thanks. and you? [09:18] seb128: just for the week next week [09:19] chrisccoulson, I'm good thanks [09:19] Laney, do you plan to land gst1.0 stack before that? ;-) [09:20] yeah, should do [09:20] good [09:22] then I get to be away when it blows up :P [09:22] lol [09:23] Laney: tea \o/ [09:23] \o/ [09:27] mvo, hey, wie gehts? [09:28] and a xorg lockup for me :( [09:28] seb128: gut, danke. pitti got me into the idea of using duolingo.com to pratcise my french, that is actually great fun :) but I still am at level-1 and the owl is crying a lot when I do my practices [09:28] pitti: did you have any more info on this btw? ^ [09:28] didrocks: no, just what is being discussed on the upstream bug [09:28] seb128: on va plus pouvoir se moquer d'eux en français si ça continue! [09:28] pitti: ok, thanks :) [09:29] didrocks: I run the quantal kernel for the time being [09:29] pitti: I should do that as well [09:30] mvo, ;-) [09:41] hum, I don't understand why split mode is not taken into account here [09:44] didrocks: do you have intel ironlake gpu? [09:45] tjaalton: not sure if it's an ironlake, lspci is telling: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) [09:45] pitti: upstream disabled rc6 power saving for ironlake, it might help with your gpu hangs [09:45] didrocks: hmm, sounds like sandybridge [09:46] tjaalton: yeah, I guess it's a sandybridge [09:48] might want to try i915.i915_enable_rc6=0 [09:48] for the kernel [09:52] tjaalton: will do at next lockup :) [09:52] thanks! [09:53] tjaalton: nope, rc6 doesn't work for me; I have Arrandale === Sweetsha1k is now known as Sweetshark [10:11] pitti, hey, how are you? [10:11] hey seb128; quite fine, thanks! [10:11] pitti, so yesterday we had update-apt-xapian-index failing by hitting and exception in pyxdg due to a misformated .desktop in app-install-data [10:12] pitti, where would you put a test to avoid app-install-data being uploaded again with a broken .desktop that would lead in that situation? [10:13] seb128: you could add an autopkgtest to a-i-d that iterates over all shipped .desktop files with pyxdg? [10:13] I fixed pyxdg's autopkgtest this morning, FYI [10:13] pitti, oh, they were broken? they ran fine here [10:14] seb128: not much; debian bug 694517 [10:14] Debian bug 694517 in pyxdg "pyxdg: Fix autopkgtest output to go to stdout" [Normal,Open] http://bugs.debian.org/694517 [10:14] pitti, oh ok [10:15] seb128: if a-i-d had a build or binary depends on pyxdg, you could also put that test into pyxdg itself [10:15] pitti, so, if we add an autopkgtest to a-i-d ... could we get to run it on pyxdg updates? [10:15] i. e . "ensure that we can process all .desktop files present on the sysetm" [10:15] seb128: that would again require a build or binary dependency [10:15] ok, which is not the case [10:15] seb128: you could add a build dep and do the iteration in debian/rules already, which would fail the build immediately [10:15] and be more obvious [10:16] and then we can use the same test as autopkgtest [10:16] pitti, I guess I could add an autopkgtest in pyxdg which is "install a-i-d and test all the .desktop from it" [10:16] ? [10:16] oui, tu peux [10:16] but that wouldn't re-run the test on a new a-i-d upload [10:16] that wouldn't be upstreamable to debian though [10:17] the "search all *.desktop files and process them" is, though [10:17] should it re-run tests in that situation? [10:17] a test dependency changes -> re-run that test [10:17] and then all that a-i-d needs is a build dep to pyxdg and a trivial autopkgtest [10:18] Laney: you mean if a dep in debian/tests/control changes? [10:18] yeah [10:18] Laney: that would be nice, but these are not exposed in apt's indexes === vrruiz_ is now known as rvr_ [10:18] so we'd need to keep an unpacked version of all test-enabled source packages around to detect that [10:19] which is possible in principle, but nobody did that [10:19] you could build a mapping on upload, when you first run the test [10:19] (and it requires introducing state into the machiner) [10:25] seb128, did the fixed bustle make it to Q? [10:25] mhr3, no [10:25] seb128, :( will it? [10:26] I imagine you could backport it fairly easily [10:26] dunno, you are welcome to propose a SRU [10:26] e.g add a debdiff to a bug, add the SRU infos, subscribe sponsors [10:28] seb128, you're doing a very bad job at making me want to do that :P [10:29] mhr3, let's say I don't think the "bustle on quantal" userbase is big enough to make me want spend time on a SRU [10:30] but, but... *i* use it :) [10:30] I'm really waiting to see us drop the nonLTS releases, too much time backporting fixes to series [10:30] but yea, i get it [10:30] * mhr3 grabs latest tarball [10:30] mhr3, just dpkg -i the debian or raring version or push that to a ppa for quantal ;-) [10:31] bustle has binary tarballs [10:31] which is pretty interesting [10:33] mhr3, wget https://launchpad.net/ubuntu/+source/bustle/0.4.2-1/+build/3995579/+files/bustle_0.4.2-1_amd64.deb [10:33] mhr3, then dpkg -i that [10:35] oh, you even know my architecture... :) [10:36] is there any other? :-) [10:36] (well, armhf for sure) [10:38] thanks pitti, for a moment a felt special :P [10:38] pitti, I'm still on i386 :p [10:39] but knowing mhr3... ;-) [10:39] i consider this a geek equivalent of knowing my birthday :) [10:39] lol [10:42] otoh there being just two real options puts it closer to flipping a coin [10:43] well, it's a biased coin, you rather have a 90% chance that people around will pick amd64 nowadays [10:43] only a few of us hold to i386 [10:44] e.g I know of mterry out of me ;-) [10:46] ok, i guess next time you have to remember my pgp fingerprint for me to feel special :P [10:49] not going to happen :p [10:49] pitti: 3.7 final should have it disabled again, or the next rc [10:50] tjaalton: I thought the problem was with some buffer overrun, not with power saving? [10:52] pitti: well, you never know :) === Johnswing is now known as Jswing [11:52] mvo, https://code.launchpad.net/~bkerensa/ubuntu/raring/app-install-data-ubuntu/fix-for-depends/+merge/135533 [11:53] mvo, for the new time you upload it ;-) (it's one of the 100 items on the sponsoring list) [11:53] mvo, thanks in advance ;-) [11:55] time for some exercice, bbl === mitya57_ is now known as mitya57 === Pendulum_ is now known as Pendulum === tkamppeter_ is now known as tkamppeter [13:16] seb128, every release i ask about gksu i'm told it will vanish, is that the case for raring as well ? [13:17] ogra_, check with mdeslaur but I guess so ... they started replacing it with pkexec not sure what is left to do [13:17] * ogra_ is looking at bug 421660 ... and ponders how to solve it since gksu still uses gconf2 [13:17] Launchpad bug 421660 in ubuntu-defaults-nexus7 (Ubuntu) "gksu's and gksudo's modal password prompt prevents OnBoard's virtual keyboard input, causing accessibility issues" [High,Confirmed] https://launchpad.net/bugs/421660 [13:17] ogra_, when do you get a gksu prompt? we should maybe fix those when we cross them? [13:18] now that apport is migrated to pkexec, I'm not quite sure what uses gksu anymore [13:18] at least, there shouldn't be much left in the default image [13:18] seb128, heh, good question [13:19] ogra@nexus7:~$ grep -r gksu /usr/share/applications/*|wc -l [13:19] 7 [13:20] gksu.desktop, xdiagnose.desktop [13:20] the rest are false positives [13:21] but i bet there als some apps that use it hardcoded [13:21] *also [13:21] ogra_, ok, so I'm asking again: when do you get gksu to prompt you? [13:22] seb128, i have no idea, i'll ask mfisch, he marked it as affecting nexus7 [13:22] ogra_, ok, let's list the cases where it happens and fix those [13:22] (though that was with the quantal image) [13:22] it's the easiest way out [13:22] urgh a new gcc, already that the powerpc builders aren't in a great shape… [13:23] didrocks, well, 2 builders, one building libreoffice and one building webkit [13:23] didrocks, see you next week to get things in raring :p [13:23] seb128: right :p [13:23] seb128: 14 hours of wait for the since that were autolanding… [13:24] didrocks, yeah, I complained about that yesterday on #ubuntu-release, it's not only blocking autolanding, it's blocking anything to move to raring [13:24] seb128: yep [13:24] they said that IS said that we should have back and extra builder today [13:25] did they found the machine that didn't restart? [13:25] but it might be worth for you mentioning it on #ubuntu-release (so I'm not the only one complaining :p) [13:25] I already complained last thursday :p [13:25] didrocks, seems like they know where the issue is, they just need somebody to physically go on site which didn't happen yet [13:25] cjwatson told that there were a critical RT to get the machine back one [13:25] IS said that would happen today [13:25] so let's see [13:26] well, it's not FF day, but still ;) [13:26] yeah, let's see [13:26] good news is that webkit build is 10 hours in and previous one took 11h [13:26] if you have something you want to see landing you might want to ask people to score down gcc or score up what you need [13:26] * didrocks crosses fingers [13:27] seb128: I think mine will get accepted before gcc as it's nonvirt [13:27] * didrocks looks at the gcc build score/wait exceptation [13:27] cool [13:27] basically the ppa is supposed to be an extension of the official archive as we don't rebuild there [13:28] urgh no, gcc is starting in one minute [13:28] yeah, I just don't know if the pool is a fifo [13:28] well at equivalent score I mean [13:28] didrocks, that seems buggy, there are 2 builders and none is going to be done before at least an hour [13:29] I think that is 1 minute after the next build finishes [13:29] yeah, launchpad time estimation is always weird [13:30] I know why the ppa is slow [13:30] it's getting the "release" score [13:31] where everything else is getting the "-proposed" score [13:32] pitti: btw, you can ditch https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4014432 and https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4015144 if you want, both are source superseeded already [13:33] seb128, oh, ara did put a use case into bug 1078696 [13:33] Launchpad bug 1078696 in ubuntu-nexus7 "gksu does not accept sudo password on the Nexus7" [Low,Confirmed] https://launchpad.net/bugs/1078696 [13:33] i guess that one is moot once we unseeded gksu though [13:34] ogra_, yeah [13:35] didrocks: lowered to 1; I can't actually kill them [13:35] pitti: ok, thanks :) === mitya57 is now known as mitya57_ === gatox is now known as gatox_away [14:32] pitti: how dare your testing initiative find bugs in my software!! [14:32] i am insulted!! [14:32] it's annoying, isn't it! [14:32] i was perfectly happy when i had no bugs [14:33] desrt: you already knew that pitti was this kind of guy :) [14:33] pitti: thanks ;) [14:33] in addition, it's not just talks, he had proofs! [14:33] https://bugzilla.gnome.org/buglist.cgi?product=dconf → "180 bugs found" *cough* [14:33] I find that shocking :) [14:33] better to find it in the unreleased version before it starts biting real users :) [14:33] pitti: 160 of them are for dconf-editor ;) [14:34] desrt: but you garden them well, only 21 open ones [14:34] * pitti vous donne des accolades [14:38] didrocks, could you review the ubuntu-settings one liner change on https://code.launchpad.net/~vanvugt/ubuntu/raring/ubuntu-settings/fix-1073202/+merge/134424 when you have a minute? [14:39] seb128: I already reviewed it, see my comment and duflu commented on it [14:39] seb128: I'm afraid that if we accept this right now, we'll never get the right fix in the end [14:39] didrocks, right, and it got 5 comments since you commented [14:40] and I pinged people on IRC developping it [14:40] but seems it was ignored [14:40] will comment *again* [14:40] didrocks, ok, putting it work in progress then and asked them back to needs review when those issues are addressed [14:41] didrocks, don't worry, I commented saying to put it back to needs review once the other issues are resolved [14:42] didrocks, sorry, just trying to get that damn sponsoring queue under 100 items, we have quite some "tricky" items like that one that just sit here atm which is not a solution either [14:42] didrocks, anyway, moving on to the next one, thanks ;-) [14:44] seb128: I added some more comments, and will keep the tab opened [14:44] seb128: thanks ;) [14:44] didrocks, great, yw ;-) [15:00] chrisccoulson: yo [15:01] chrisccoulson: globalmenu-extension, do you know where the source for that is? I'd like to prepare it for didrocks' autolanding, so updating the packaging and merging it in to the trunk branch [15:18] cyphermox, how's that going to work? it's unbuildable outside of the firefox source tree, and doesn't have any packaging of its own [15:20] do we really automatic daily landing for that? [15:20] it seems to be fine living in firefox's source [15:20] didrocks, ^ [15:20] it will be tested when we run the firefox tests anyway ;) [15:20] i'm actually working on that arm [15:20] **atm [15:20] if it's in firefox source, it's fine, let's it be this way :) [15:20] cool [15:20] the fact that there is a dedicated launchpad project is misleading :) [15:21] didrocks, can i have test results from PPA builds appear on https://jenkins.qa.ubuntu.com/ ? [15:22] chrisccoulson: PPA builds? well, in theory everything is possible but you need to code it [15:22] the good news is that I have a ppa watcher :p [15:22] so you can maybe steal from it to get the status :) [15:22] or bribe pitti for QA to add that feature ;-) [15:22] didrocks, https://code.launchpad.net/~mozillateam/firefox/firefox-trunk.head, see the last couple of weeks of commits ;) [15:23] it's possible to run all of the firefox tests outside of the build now, and they are all packaged too [15:23] well, all -> most ;) [15:23] chrisccoulson: waow, nice work! ;) [15:24] niiice. [15:27] seb128: https://code.launchpad.net/~vanvugt/ubuntu/raring/ubuntu-settings/fix-1073202/+merge/134424 FYI in case you didn't see it [15:28] didrocks, so sam is working on the fix? [15:29] seb128: well, he told me a month ago that it will be two weeks to fix it… So I'm unsure [15:29] seb128: I tried to get duflu profiling it, seems there is no incentive [15:29] that's why I don't want to push the workaround first [15:29] because it's bitting us in other ways [15:29] and this won't get fix [15:29] chrisccoulson: I see you have a bot account for LP. Care to tell me how you use it? I was about to make the same so I don't have to expose my own GPG and SSH keys outside my machine. [15:30] didrocks, is that bug #1063617 or another one? [15:30] Launchpad bug 1063617 in compiz (Ubuntu) "1:0.9.8+bzr3319-0ubuntu1 regression: keeps setting gsettings keys to wrong values" [High,In progress] https://launchpad.net/bugs/1063617 [15:30] seb128: I *think* they are related, but no evidence [15:30] so can't promiss [15:31] didrocks, ok, anyway I just wanted to knock it off the sponsoring queue while it's being worked, no hurry to see the patch landing ... would still be nice to get the real compiz bug fixed ;-) [15:31] seb128: yeah, it's breaking at least 10 autopilot tests [15:36] desrt, I think debian hates you :p [15:37] yeah i'm wondering how that didn't break us [15:37] desrt, they are talking about reverting the glib arm abi break in debian or renaming the glib binary [15:40] seb128: they're pretty foolish [15:41] desrt, I don't think "foolish" is the word ;-) [15:41] mad-as-hatters? [15:41] desrt, they will probably settle on the "best" option which is rebuilding some hundred packages [15:41] i'd love to see them revert the ABI break that they didn't notice for over a year [15:42] and watch how the new-old ABI rebreaks everything again [15:42] desrt, they are speaking about rebuild some 300 packages already [15:42] rebuilding makes sense [15:42] i have a hard time believing that 300 packages are impacted, though [15:43] unless they really have that many packages that are updated that infrequently... [15:43] they do [15:43] well [15:43] rebuilding those 300 that haven't been updated is better than rebuilding sizeof(glib rdepends) - 300 :) [15:45] seb128: got a link to the discussion? [15:46] seb128: remember i told you -- of all my latest API-breaking parties that this would be the one that really pissed debian off the most? :) [15:46] and this one wasn't even intentional :p [15:47] desrt, http://paste.debian.net/212761/ [15:47] desrt, it's on #debian-gnome @ oftc [15:48] ongoing discussion === gatox_away is now known as gatox [16:03] seb128: i joined it :p [16:03] desrt, I see that ;-) [16:03] desrt, thanks [16:03] i didn't realise that debian was using such an ancient glib [16:04] their release cycles are long... :) [16:27] #ubuntu-devel [16:31] * didrocks whistles "meeting" to seb128's ears :) [16:31] didrocks, oh, right, I got the reminder and got carried away in a discussion [16:31] didrocks, thanks [16:31] :) [16:32] yw ;) [16:32] Sweetshark, qengho, chrisccoulson, didrocks, Laney, kenvandine, mlankhorst, cyphermox, mterry, robru, attente: hey, it's meeting time [16:32] Yay! [16:32] oh, it's meeting time! [16:32] :) [16:32] o/ [16:32] not now I'm playing tf2! :P [16:32] \o/ [16:33] https://wiki.ubuntu.com/DesktopTeam/Meeting/2012-11-27 [16:33] hello! [16:33] not a lot of updates on the wiki [16:33] don't forget to drop some lines about what you are doing [16:33] how is everyone? [16:33] mlankhorst: dont think of the game! [16:33] I didn't do anything publicly notable :) [16:33] seb128, I am here for the meeting despite being on holiday ;-) [16:33] http://status.ubuntu.com/ubuntu-raring/canonical-desktop-team.html is also set up with trend line resetted, I hope nobody forgot some specs [16:33] hi! [16:34] robru|packing, oh, great, making up for the one you missed last week ;-) [16:34] robru|packing, happy packing! [16:34] seb128, making up for having missed ALL previous meetings ;-) [16:34] Sweetshark: no I'm thinking of it as stress testing the reworked nouveau patches I made [16:34] seb128, thanks [16:34] robru|packing: between 2 boxes :p [16:34] let's get started [16:34] seb128, also, today is my birthday! ;-) [16:34] o/ [16:34] robru|packing, oh, happy birthday! [16:34] happy birthday, robru|packing :) [16:34] happy birthday robru|packing :) [16:34] seb128, thanks ;-) [16:34] :) [16:34] yay [16:34] thanks everybody ;-) [16:35] robru|packing, shouldn't it be "robru|drinking"? [16:35] happy birthday ;) [16:35] chrisccoulson, haha, soon! [16:35] ok, let's get started, I hope everybody prepared this cycle so we can have a shorted meeting rather than waiting on everyone to type ;-) [16:35] Sweetshark, hey [16:35] seb128: heya [16:35] short weekly summary ready? ;-) [16:35] - LibreOffice Hackfest 2012 Munich/Debian Bug Squashing Party: - insanely productive: http://wiki.documentfoundation.org/Hackfest/Munich2012 - some work on session installer - met some debian folks, trained some in our voodoo (SRU processes etc.) ... - resynced with Rene (LO debian maintainer) - lots of other topics, I spare you the details [16:36] - lp#1017125: tested backport, seems unfixed, which is bad and strange [16:36] - LibreOffice 4.0 alpha 1 released to quantal prereleases ppa for testing [16:36] - LibreOffice 3.6.4~rc2 prolly 3.6.4 final tagged today and locally building for later ppa upload - to be SRUed ~2 weeks later [16:36] seb128: ^ thats it [16:36] (use "..." when you are done so we know when somebody is still typing) [16:36] (or or whatever tag you like) [16:36] Sweetshark, thanks [16:37] Sweetshark, I will try to talk to the SRU guys again to get 3.5.7 reviewed [16:37] they have quite some SRU backlog [16:37] thanksgiving didn't help... [16:37] [16:37] qengho, hey [16:37] Hi hi! [16:37] desktop-r-chromiumbrowser-improvements [16:37] Just about got my stable PPA for chromium-browser building automatically. There was a new stable release just yesterday, and it worked it with only a little change. Starting the beta PPA building too. I'll hand off some builds to Security team today or tomorrow. Then, I'll start publishing in the cr-team PPA. [16:37] Translations need work. I dropped mutating the Cr "orig" tarball during UDS. I made some repairs to the po-to-chromium tool, but it needs more. Must decide where to put results, too: [16:37] I'll fish for interest at chromium upstream for interest in all the languages we support but they don't. micah says they had no interest in the past. [16:37] EOF [16:38] qengho, great, what's the ppa to use for those who want to track the current versions? [16:38] cr-team one? [16:39] https://launchpad.net/~cr-team ... ENOTFOUND [16:39]