| dcg | hi all, having some issues getting multiple X servers running on maverick. | 01:30 |
|---|---|---|
| dcg | have 2 servers running :0 on VT7 and :1 on VT9 unfortunately I can only have one of them displaying at a time, (yes I do have a working setup for 2 monitors/keyboards/mice) basically to view the other X server I have to hit CTRL-ALT-F7 or CTRL-ALT-F9 from the currently focused keyboard. | 01:32 |
| dcg | does anyone have some suggestions? | 01:32 |
| === smspillaz|swap is now known as smspillaz | ||
| TariQMowafy | hello | 03:07 |
| TariQMowafy | hello | 03:08 |
| TariQMowafy | anybody here? | 03:08 |
| === Bertrand is now known as bl8 | ||
| === oubiwann_ is now known as oubiwann | ||
| kklimonda | good morning | 05:13 |
| latenal | hello, I need some help. I have a built-in blueotooth device. Few days ago it start to have trouble to connect to my handsfree but was ok with my cellphone. I tried to install/uninstall blueman and bluez and after few manipulations the daemon stopped working. I can't start it any more | 05:51 |
| RAOF | !support | 05:52 |
| ubot2 | The official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org and http://askubuntu.com | 05:52 |
| RAOF | You'll probably get more help in any of those avenues. | 05:52 |
| latenal | thank you | 05:53 |
| broder | by the way, in case there was ever any doubt, NV-CONTROL is a really crappy protocol to work with | 05:58 |
| broder | on the plus side, i think the daemon i'm currently writing for work that tries to automatically handle hotplug events on NVIDIA is GPL tainted, so it might get to see the light of day :) | 05:59 |
| RAOF | Oh! Does NV-CONTROL actually generate hotplug events? Cool :) | 06:04 |
| broder | no, but i'm polling for them :) | 06:05 |
| broder | generating useful events would be entirely too, well, useful for NV-CONTROL | 06:05 |
| TheMuso | lol | 06:17 |
| didrocks | good morning | 07:35 |
| pitti | Good morning | 07:57 |
| Sweetshark | didrocks, pitti: Good Morning! | 08:06 |
| pitti | hey Sweetshark, moin moin! | 08:06 |
| didrocks | Guten Morgen pitti und Sweetshark | 08:07 |
| glatzor | morning mvo pitti | 08:09 |
| pitti | hey glatzor | 08:10 |
| pitti | glatzor: great work on aptdaemon! looks really cool | 08:10 |
| glatzor | thanks pitti | 08:10 |
| pitti | mvo: speaking of which, do you want to sponsor this? or want me to? | 08:12 |
| pitti | robert_ancell: hey Robert, good evening! | 08:13 |
| * Sweetshark reboots | 08:14 | |
| mvo | hey glatzor! thanks for your mail | 08:14 |
| mvo | pitti: I'm working on it currently, there is a test-failure left (but only on build anoyingly) | 08:15 |
| pitti | ah, great | 08:15 |
| * pitti hugs glatzor and mvo | 08:15 | |
| pitti | robert_ancell: do you have some time to look into this webkit bug 710582? | 08:18 |
| ubot2 | Launchpad bug 710582 in webkit "webkit crashes on amd64 architecture with SIGSEGV in WTF::OSAllocator::reserveAndCommit() was: webkit does not implement "assert" sanely" [Critical,Confirmed] https://launchpad.net/bugs/710582 | 08:18 |
| didrocks | hey glatzor, mvo | 08:23 |
| glatzor | morning didrocks | 08:23 |
| mvo | hey didrocks | 08:27 |
| robert_ancell | pitti, not tonight but can tomorrow | 08:30 |
| pitti | robert_ancell: I was just wondering in general, depending on your current workload; if you are already overloaded, I'll look for someone else | 08:30 |
| robert_ancell | pitti, assign it to me | 08:32 |
| pitti | robert_ancell: ok, thank you | 08:33 |
| jasoncwarner | hey robert_ancell, I think we are good on that meeting for tonight...no worries...pitti set my mind at ease ;) | 08:33 |
| robert_ancell | jasoncwarner, oh, np | 08:34 |
| mvo | hey jasoncwarner, welcome back, isn't it terrible late in your TZ ? | 08:35 |
| jasoncwarner | hey mvo, not terribly, ;) | 08:35 |
| jasoncwarner | but for what time I normally wake up, it is getting late! | 08:35 |
| mvo | heh .) | 08:35 |
| didrocks | hey jasoncwarner | 08:43 |
| jasoncwarner | morning didrocks! | 08:44 |
| jasoncwarner | pitti tells me that you've been slacking ;) | 08:44 |
| jasoncwarner | says you are never doing awesome things and never completely amazing him with your work ethic and dedication ;) | 08:44 |
| pitti | yeah, a whole 4 hours during his sleep!!!! | 08:44 |
| Sweetshark | jasoncwarner: Oh, just a short question: What are your usual work hours currently? I know nothing is usual currently with all that exciting stuff going on, but I keep calculating timezones ... ;) | 08:45 |
| jasoncwarner | Sweetshark: I normally work San Francisco hours.... | 08:46 |
| jasoncwarner | which was easier to tell people when the clocked worked with timezones ;) | 08:46 |
| didrocks | jasoncwarner: yeah, totally slacking :) | 08:49 |
| didrocks | I +1 pitti | 08:49 |
| didrocks | sorry, time for one of my 20 naps of the day :) | 08:49 |
| jasoncwarner | ha! | 08:49 |
| pitti | *chuckle* | 08:49 |
| * pitti hugs didrocks | 08:49 | |
| * didrocks hugs pitti back | 08:50 | |
| pitti | didrocks: don't forget to watch Big Bang Theory in between them! | 08:50 |
| Sweetshark | When I met didrocks at FOSDEM he wasnt even sleeping ... | 08:50 |
| didrocks | pitti: hehe, I have 3/4 episod late on the last season! | 08:50 |
| didrocks | you see, unity destroy my life, I even can't keep up Big Bang Theory :) | 08:50 |
| jasoncwarner | rock paper scissor lizard spock! | 08:50 |
| pitti | didrocks: ah, I already caught up all the way until 4/14 | 08:51 |
| pitti | didrocks: I informed you thusly! | 08:51 |
| didrocks | pitti: excellent, I'm still at 4/11 IIRC ;) | 08:51 |
| pitti | man, I love that show | 08:51 |
| didrocks | yeah, it's so nice :) | 08:52 |
| didrocks | I think now that I saw that one, I even prefer it than The IT Crowd | 08:52 |
| didrocks | (well, maybe not the "The Internet" episod) ;) | 08:52 |
| Sweetshark | pitti: Dont be cruel, I got the first two seasons as DVDs from my brother for my birthday, but he insisted he would like to look them together with me. And he is currently in Ingolstadt helping making nice german cars during the week that prolongs stuff needlessly. | 08:52 |
| pitti | Sweetshark: argh, poor you | 08:53 |
| pitti | didrocks: yeah, me too; but at least I still have the 4th episode of IT crowd left to watch | 08:54 |
| didrocks | pitti: oh right, I hadn't started watching the last season as well! | 08:55 |
| Sweetshark | In my desperation I already stopped the DVD in one of the episodes we had already seen and analysed the physics on the whiteboards. | 08:55 |
| didrocks | Sweetshark: and so? are things correct or is it nuts? | 08:56 |
| Sweetshark | didrocks: correct mostly | 08:56 |
| didrocks | without any stop, it seemed to be correct as well, but I didn't analyse closly | 08:56 |
| didrocks | closely* | 08:57 |
| Sweetshark | at least the quantum mechanics stuff. Dunno about the string theory. Im not into esoterics ;) | 08:57 |
| pitti | Sweetshark: at least you can live in the peace of mind that _nobody_ knows whether it's correct :) | 08:59 |
| pitti | so your guess is as good as anyone elses's | 09:00 |
| didrocks | (small notice: so, the invisible window bug is still there, but very very rare though… The good news is that *now* we have a reproducible test case \o/) | 09:02 |
| pitti | at least I'm using unity again since yesterday evening, and I haven't gone nuts again yet | 09:03 |
| didrocks | you can trigger it in the classic session as well ;) | 09:05 |
| didrocks | you won't escape compiz bugs like that! | 09:05 |
| didrocks | but agreed, the situation is way better | 09:05 |
| pitti | didrocks: not in classic+metaicy :) | 09:06 |
| pitti | (which is what I was using) | 09:06 |
| didrocks | pitti: that's cheating though :) | 09:06 |
| pitti | you should try metaicy, it's yummy | 09:06 |
| pitti | metacity works as well, though | 09:06 |
| didrocks | I was using metacity the past last years TBH :) | 09:06 |
| didrocks | (just switched for a cycle to compiz when it was the new bling bling) | 09:06 |
| dpm | good morning all | 09:17 |
| pitti | hey dpm | 09:17 |
| dpm | hey pitti. It seems there's been some feedback of non-working FF lucid translations in the -proposed langpacks -> https://lists.ubuntu.com/archives/ubuntu-translators/2011-February/004395.html | 09:17 |
| didrocks | hey dpm | 09:18 |
| dpm | heya didrocks :) | 09:18 |
| pitti | dpm: oh, thanks; I'll remove that one from -proposed right away then | 09:19 |
| dpm | ok, let's see if we get some more feedback | 09:20 |
| pitti | $ cat 10.04/whitelist.txt | 09:20 |
| pitti | fi | 09:20 |
| pitti | oc | 09:20 |
| dpm | hm :( | 09:20 |
| pitti | dpm: I'm not entirely sure what the whitelist is, but that might not be a coincidence | 09:20 |
| pitti | is -oc broken as well? | 09:20 |
| dpm | it seems po2xpi is the culprit here then? | 09:20 |
| dpm | not sure | 09:20 |
| dpm | let me see if I can install a few in my lucid pc | 09:21 |
| seb128 | hey | 09:25 |
| didrocks | salut seb128 | 09:28 |
| rodrigo_ | morning | 09:29 |
| seb128 | hey didrocks rodrigo_ | 09:31 |
| seb128 | how are you? | 09:32 |
| didrocks | good morning rodrigo_ | 09:32 |
| didrocks | I'm fine, thanks, you? | 09:32 |
| rodrigo_ | hi seb128, didrocks | 09:33 |
| seb128 | didrocks, I'm fine as well, a bit late to start, I ran out for some errands before starting | 09:34 |
| didrocks | seb128: sunny days? | 09:34 |
| didrocks | or cloudy weather like in Lyon? :) | 09:35 |
| seb128 | no, it's not sunny here, rather went out to get some coffee and something to eat | 09:35 |
| seb128 | running out of breakfast stuff here ;-) | 09:35 |
| pitti | bonjour seb128 | 09:35 |
| seb128 | hey pitti | 09:35 |
| didrocks | seb128: hehe, not a nice way to start the day, right. errands were mandatory then :) | 09:36 |
| seb128 | I got coffee and cake so that's fixed, I can work ;-) | 09:36 |
| seb128 | didrocks, did you get comments about the compiz update? | 09:42 |
| seb128 | pitti, do you run again unity? | 09:42 |
| pitti | seb128: yes, I do | 09:42 |
| pitti | since the update last night | 09:42 |
| didrocks | seb128: yeah, still some invisible window issue | 09:42 |
| seb128 | working fine? | 09:42 |
| pitti | seb128: no problems so far | 09:43 |
| seb128 | didrocks, ok, as you thought | 09:43 |
| didrocks | seb128: but the good news is that we have a reproducible test case now | 09:43 |
| seb128 | didrocks, using apport? ;-) | 09:43 |
| didrocks | seb128: no, synaptic :-) | 09:43 |
| seb128 | I didn't try yet here but I get it almost every time I use update-manager and the polkit daemon crashes | 09:43 |
| seb128 | which triggers apport and let compiz in a broken state | 09:44 |
| didrocks | yeah, it's really a criptic path that has been reported as well :) | 09:44 |
| didrocks | but it "works" as triggering the bugs reliably | 09:44 |
| didrocks | bug* | 09:44 |
| didrocks | so nice :) | 09:44 |
| seb128 | or rather than waiting for polkit to crash just hit esc on the password dialog | 09:44 |
| seb128 | update-manager freaks out and freeze for 5 minutes and apport display a dialog and break compiz | 09:44 |
| didrocks | yeah, apparently, compiz just ask for paint rather than create create reparent… | 09:44 |
| seb128 | didrocks, ok, great, it means sam can work on it now then? | 09:45 |
| didrocks | as it is thinking the window is already there | 09:45 |
| didrocks | yeah, he's already aware of that :) | 09:45 |
| didrocks | so, basically, 3 bugs before merging back the glib branch to trunk: | 09:45 |
| Sweetshark | .oO(apt-get build-dep libreoffice <= WooHa!) | 09:46 |
| didrocks | 1. alt / tab being slow (almost finished) | 09:46 |
| didrocks | 2. this invisible window | 09:46 |
| didrocks | 3. test the new order with the sn_* crash | 09:46 |
| seb128 | I get the sn_ crash every second login | 09:46 |
| seb128 | would be nice to get it fixed ;-) | 09:47 |
| didrocks | maybe removing my workaround with the new patch for it can be an help | 09:47 |
| seb128 | Sweetshark, hey, what about it? hours of downloads? ;-) | 09:47 |
| didrocks | but there is an ABI break and such… | 09:47 |
| didrocks | so I prefer rather than running untested stuff that it lands to trunk + make dist as we need to do that rebase | 09:47 |
| Sweetshark | seb128: nah, downloads are fast here ... | 09:49 |
| * Sweetshark has 100MBit downstream at home ... | 09:49 | |
| seb128 | didrocks, right | 09:49 |
| seb128 | Sweetshark, that's quite a nice internet access indeed ;-) | 09:50 |
| pitti | Sweetshark: wow, but you don't have a large "Uni Hamburg" plate on your front door, do you? | 09:50 |
| Sweetshark | pitti: nope. Than it would even be faster. Uni Hamburg also has some huge IPv4 ranges. Good that they build DESY here before the dawn of the WorldWideWeb ... | 09:52 |
| Sweetshark | we got fibreglas connections around here and cable TV and phone are served over that connection as a sideeffect. 100MBit/s almost never get saturated for simple downloads as some server on the way will choke. bittorrrent is the only thing that lights up stuff completely ... | 09:58 |
| === zyga_ is now known as zyga | ||
| Sweetshark | No I was wondering about all the additional packages that got installed as I already build LO without them ;) | 09:59 |
| Sweetshark | ... but that was without --with-system-libs ... | 10:00 |
| seb128 | Sweetshark, right, debian and ubuntu tend to not like using lib copies | 10:01 |
| seb128 | it means you have copies of the code to update every time you fix a bug or a security issue | 10:01 |
| === smspillaz is now known as smspillaz|dinner | ||
| === kamstrup is now known as kamstrup|hackfes | ||
| Sweetshark | Is there a policy that packages must build single-threaded? Because LO does and well, it could be a lot faster ... | 10:02 |
| pitti | Sweetshark: no, the buildds use DEB_BUILD_OPTIONS=parallel=4 | 10:03 |
| pitti | Sweetshark: most packages actually build with "debuild -j4" | 10:03 |
| pitti | but that also runs debian/rules in parallel | 10:03 |
| pitti | which the current LibO package fails on | 10:03 |
| pitti | Sweetshark: but if you set the above, it'll be a lot faster indeed (replace 4 with your number of cores) | 10:04 |
| pitti | Sweetshark: on my core i5 2.4 GHz/4 GB RAM, the last OO.o built in about 3 hours | 10:04 |
| Sweetshark | seb128: sure, nobody likes it. But from a dev point of view it might make sense because you dont want to recompile LO everytime some system lib got updated (as LO is linking a lot of those, that would be pretty often) | 10:05 |
| seb128 | Sweetshark, which is another reason to use the system libraries? | 10:06 |
| seb128 | if they are dynamically loaded you don't need to rebuild l-o when a library is updated | 10:06 |
| seb128 | if you use a copy you need to patch l-o and rebuild it... | 10:06 |
| pitti | Sweetshark: yeah, it's actually considered a bug if a package includes copies of system libraries | 10:07 |
| pitti | if it's a security sensitive thing like poppler, zlib, or pcre, the security team haunts maintainers pretty severely (and rightly so) | 10:07 |
| Sweetshark | seb128: In theory. In practice, API might change, LO might depend explicitly on an outdated lib or even might only run against a patched version ... | 10:09 |
| Sweetshark | of course, Nothing of that should happen, but it does ;) | 10:10 |
| === kamstrup|hackfes is now known as kamstrup|hackfez | ||
| Sweetshark | Hmmm, another stupid question about the debian way of building: When I apt-get source, apt-get build-dep and then apt-get source -b so that it is build via dpkg-buildpackage, what does the unpacking of tarballs? | 10:41 |
| pitti | Sweetshark: apt-get source -b is pretty much overkill there | 10:48 |
| pitti | Sweetshark: apt-get source does the unpacking, through dpkg-source -x foo.dsc | 10:49 |
| === smspillaz|dinner is now known as smspillaz | ||
| Sweetshark | pitti: I just trying to get my head around all the stuff that happens "around" the "real" build by the build.pl up to a complete package. | 10:53 |
| pitti | Sweetshark: build.pl? | 10:53 |
| pitti | Sweetshark: the most low-level program you should be concerned about is dpkg-buildpackage | 10:54 |
| pitti | -S -> build source package, -b -> build binary pacakge | 10:54 |
| Sweetshark | pitti: the build script in the LO build itself. Scary stuff. | 10:54 |
| pitti | I think most people use the "debuild" wrapper, which calls lintian and provides some extra configurability | 10:54 |
| pitti | Sweetshark: ah | 10:54 |
| pitti | Sweetshark: the entry point to building a source package is the debian/rules Makefile | 10:55 |
| pitti | Sweetshark: for that I suggest to do the packaging tutorial first; trying to understand that stuff on the LibO package will be ... not easy | 10:55 |
| Sweetshark | So one working set of commands would be: apt-get build-deps && apt-get source && dpkg-source -x && dpkg-buildpackage, right? Or is there anything missing in the chain? | 10:56 |
| dpm | pitti, I've had a quick look at some of the langpacks which have already been buit: es, bn, de, pt, pt_BR (same langpack), bn. In all of them firefox translations look ok to me (i.e. no obvious breakage). I could not install any other language, as the 'language-pack-LL' packages are still on the old version (I guess they haven't been built yet), and I get a conflict when trying to install the corresponding 'language-pack-LL-base', which is already on | 11:00 |
| dpm | the latest version for most of the languages. So I'm not sure how the translator installed the Finnish langpack, and I'm not sure if he might have created the breakage himself | 11:00 |
| * Sweetshark tries (but with replacing dpg-buildpackage replaced by dpkg-source -b in the unpacked dir) | 11:00 | |
| pitti | Sweetshark: apt-get source already unpacks the source, unless you add -d | 11:00 |
| pitti | Sweetshark: dpkg-source -b is not what you want; you want debuild -b or dpkg-buildpackage -b | 11:01 |
| pitti | Sweetshark: dpkg-source -b is a very low-level (i. e. not meant for users) interface for building a source pacakge, i. e. the diff.gz/dsc | 11:01 |
| pitti | dpm: hm, might be your mirror which is behind? they all built over night | 11:01 |
| pitti | dpm: this morning at 9 am the queue was empty | 11:02 |
| dpm | ah, let me see... | 11:03 |
| === MacSlow is now known as MacSlow|lunch | ||
| Sweetshark | pitti: I want to go 'very lowlevel' to see what happens in each step that dpkg-buildpackage would do as per http://www.debian.org/doc/maint-guide/ch-build.en.html ... | 11:09 |
| pitti | Sweetshark: essentially it calls "debian/rules build", then "debian/rules binary" (for binary builds) | 11:10 |
| pitti | for source packages, it cleans, calls dpkg-source -b, etc. | 11:10 |
| pitti | but it's not all that important | 11:10 |
| Sweetshark | I just want to get a feel where the magic happens ;) | 11:13 |
| pitti | Sweetshark: which package do you use for studying this? | 11:14 |
| Sweetshark | when I run dpkg-source -b . in the dir where I ran apt-get source, I get cannot open `./debian/changelog' for reading, which is to be expected as debian is in the subdir libreoffice-3.3.0 ... | 11:15 |
| Sweetshark | pitti: libreoffice ;) | 11:15 |
| pitti | uh | 11:15 |
| Laney | maybe 'hello' is a better place to start ;-) | 11:15 |
| pitti | Sweetshark: yeah, you need to be in the source tree for every dpkg-buildpackage operation | 11:15 |
| Sweetshark | when I am in libreoffice-3.3.0 (actually I tried that first), I get "no orig.tar file found" | 11:16 |
| pitti | yeah, hello is already nontrivial, and still uses plain debhelper | 11:16 |
| pitti | Sweetshark: doc says dpkg-source -b <source dir> | 11:17 |
| * pitti never used that himself | 11:17 | |
| Sweetshark | which is true, there is only a libreoffice_3.3.0.orig.tar.gz in ../ | 11:18 |
| Laney | actually the hello I just got doesn't even use debhelper at all o_o | 11:18 |
| pitti | indeed | 11:19 |
| broder | right - you want hello-debhelper :) | 11:19 |
| pitti | Sweetshark: right, so dpkg-source actually does need to run outside the source tree | 11:19 |
| Laney | so if you want low level then this might be good reading | 11:19 |
| Sweetshark | I just want to do the low level stuff once now, to get a feeling for it so I will not freak out should the need arise someday ... | 11:21 |
| seb128 | rodrigo_, hey | 11:21 |
| seb128 | rodrigo_, just read your comment, we already build tomboy without the applet enabled | 11:22 |
| pitti | seb128: hm, do you know what the new geoclue stuff is actually supposed to do? empathy doesn't show me the location of people anywhere | 11:22 |
| seb128 | pitti, the indicator-datetime is supposed to show "do you want to change your tz" when travelling | 11:22 |
| pitti | ah | 11:22 |
| seb128 | pitti, set your tz to an u.s one and restart it | 11:22 |
| seb128 | it should tell you "you are in germany, do you want to set that tz" | 11:22 |
| seb128 | pitti, we don't build empathy with geoclue, it would require bringing in libchamplain to gets the maps etc | 11:23 |
| pitti | $ killall indicator-datetime-service; TZ=America/Chicago /usr/lib/indicator-datetime/indicator-datetime-service | 11:23 |
| pitti | (process:15280): Indicator-Datetime-WARNING **: Unable to create GeoClue address: Address interface already started | 11:23 |
| pitti | hm, I guess it's very racy with the auto-respawn | 11:23 |
| seb128 | pitti, it's likely you need to restart geoclue as well | 11:24 |
| pitti | oh, indeed | 11:24 |
| seb128 | pitti, it's rather geoclue which picks the tz | 11:24 |
| pitti | -ETOOMANYDAEMONS | 11:24 |
| seb128 | the indicator just talk to geoclue | 11:24 |
| pitti | hm, restarted geoclue-master, and it talked to Ubuntu GeoIP; now restarted indicator-datetime-service, but no question here | 11:25 |
| seb128 | pitti, it should be a line in the indicator | 11:25 |
| seb128 | not a popup | 11:25 |
| pitti | nope | 11:25 |
| seb128 | how did you change your tz? | 11:25 |
| pitti | I have them both in the foreground now | 11:26 |
| pitti | seb128: running the daemons with TZ=America/Chicago | 11:26 |
| seb128 | not sure how they get the tz or if they respect that | 11:26 |
| seb128 | or if they just read /etc/timezone or something | 11:26 |
| pitti | that'd be a bug | 11:27 |
| pitti | but let me try changing that | 11:27 |
| * pitti changes it in time-admin | 11:27 | |
| pitti | (process:15490): Indicator-Datetime-WARNING **: Unable to create GeoClue address: Address interface already started | 11:28 |
| pitti | I keep getting that | 11:28 |
| pitti | (process:15490): Indicator-Datetime-WARNING **: Unable to get Geoclue address: Geoclue master client has no usable Address providers | 11:28 |
| pitti | anyway, I was just curious | 11:28 |
| seb128 | pitti, ok, check with ken or ted when they are online, I didn't play much with it | 11:29 |
| seb128 | pitti, I know it's supposed to show a "set the tz to ..." line in the indicator when it detects you are on a different tz | 11:29 |
| pitti | argh, argh! I have an invisible window again | 11:30 |
| seb128 | pitti, | 11:31 |
| seb128 | <smspillaz> oh, heh | 11:31 |
| seb128 | interesting workaround for the invisible window bug | 11:31 |
| seb128 | hide and show the desktop | 11:31 |
| seb128 | pitti, try that maybe ;-) | 11:31 |
| pitti | how? | 11:31 |
| seb128 | if you have a gnome-panel running put the "show desktop" applet | 11:31 |
| pitti | I don't | 11:31 |
| seb128 | otherwise dunno | 11:31 |
| seb128 | smspillaz, ^ | 11:31 |
| smspillaz | seb128: wassup ? | 11:31 |
| seb128 | pitti, thereis probably a show desktop keybinding in compîz | 11:31 |
| pitti | and apparently the nasty window is on top of the unity panel, I can't even open the launche rnow | 11:31 |
| smspillaz | seb128: pitti: Ctrl-Alt-D | 11:31 |
| seb128 | smspillaz, how do you hide and show desktop to workaround this bug | 11:32 |
| pitti | smspillaz: doesn't work | 11:32 |
| seb128 | smspillaz, thanks | 11:32 |
| smspillaz | I used the thing on the gnome-panel | 11:32 |
| pitti | smspillaz: might only work with gnome-panel? | 11:32 |
| smspillaz | pitti: might have changed | 11:32 |
| seb128 | ctrl-alt-D works there | 11:32 |
| smspillaz | showdesktop handling is done within the wm | 11:32 |
| smspillaz | pitti: ccsm -> general -> keybindings -> show desktop | 11:32 |
| === smspillaz is now known as smspillaz|eating | ||
| rodrigo_ | seb128, yes, found out the peditor stuff is in libgnome-cil, that's where the dep comes from | 11:33 |
| rodrigo_ | seb128, so moving those files to gconf-cil and testing | 11:33 |
| pitti | smspillaz|eating: thanks, I used gnome-keybinding-properties and that worked (it was Mod4+D before) | 11:33 |
| pitti | found a time-admin window hiding itself | 11:33 |
| smspillaz|eating | ok | 11:34 |
| pitti | nice | 11:34 |
| smspillaz|eating | pitti: yeah we've got a reproducible test case now so I'm going to look into it tonight | 11:34 |
| * pitti calls that "sanity key" | 11:34 | |
| seb128 | rodrigo_, well I assumed it was in libgnome-cil for a reason, that's why I asked you if we could move to plain gconf# | 11:34 |
| seb128 | rodrigo_, but if we can move it to another binary nice | 11:34 |
| seb128 | rodrigo_, check with Laney or pkgcli guys maybe though | 11:35 |
| rodrigo_ | seb128, yes, I guess it's there for some reason, not sure which though, so yes, testing | 11:35 |
| rodrigo_ | Laney, ^ | 11:35 |
| Laney | you could split the peditors assembly out into another package yeah | 11:36 |
| Laney | I don't know if that would save you anything on the dep chain, but it's worth a try | 11:36 |
| seb128 | is there a way to do the equivalent of "ldd" on mono bindings? | 11:36 |
| seb128 | i.e to see what peditor depends on | 11:36 |
| Laney | give us a patch in Debian and we'll take it | 11:36 |
| Sweetshark | In case anyone is interested: mkdir foo && cd foo && apt-get source libreoffice && dpkg-source --before-build libreoffice-3.3.0 && dpkg-source -b libreoffice-3.3.0 && make -C libreoffice-3.3.0 -f libreoffice-3.3.0/debian/rules build | 11:37 |
| Laney | monodis --assemblyref I think | 11:37 |
| seb128 | Laney, thanks | 11:37 |
| seb128 | Laney, well, it would save "Name=gnome-vfs-sharp" | 11:37 |
| seb128 | coming from /usr/lib/cli/gnome-sharp-2.24/gnome-sharp.dll | 11:37 |
| Laney | is that where your problematic dep comes from? | 11:38 |
| seb128 | doh | 11:38 |
| seb128 | the peditor one depends on gnome-sharp | 11:38 |
| Laney | if peditors depends on gnome-sharp thoug... | 11:38 |
| Laney | yeah, :( | 11:38 |
| seb128 | right | 11:38 |
| seb128 | that brings the gnome-vfs stack in | 11:38 |
| rodrigo_ | seb128, the peditor stuff is in libgnome-2.24-cil | 11:39 |
| rodrigo_ | in the upstream source code, they are with the gconf 'basic' bindings | 11:39 |
| seb128 | rodrigo_, yes, but it doesn't make sense to split it out since gconf-sharp-peditors.dll depends on the gnome-sharp.dll | 11:39 |
| seb128 | rodrigo_, which depends on gnome-vfs | 11:39 |
| rodrigo_ | doesn't seem to depend on gnome-sharp.dll | 11:39 |
| * rodrigo_ re-checks | 11:39 | |
| seb128 | rodrigo_, monodis --assemblyref /usr/lib/cli/gconf-sharp-peditors-2.24/gconf-sharp-peditors.dll | 11:40 |
| Laney | rodrigo_: try monodis --assemblyref /path/to/dll | grep Name | 11:40 |
| seb128 | Name=gnome-sharp | 11:40 |
| Laney | you can see it probably with "using Gnome;" in the sources | 11:40 |
| Laney | it probably follows the c lib | 11:40 |
| seb128 | $ monodis --assemblyref /usr/lib/cli/gconf-sharp-2.0/gconf-sharp.dll | grep Name | 11:40 |
| seb128 | Name=mscorlib | 11:40 |
| seb128 | Name=glib-sharp | 11:40 |
| seb128 | that one is better ;-) | 11:41 |
| Laney | I don't know the API at all, but maybe you can replicate it on top of gconf# | 11:42 |
| seb128 | pitti, https://bugs.launchpad.net/ubuntu/+source/ubuntu-geoip/+bug/715445 | 11:43 |
| ubot2 | Launchpad bug 715445 in ubuntu-geoip "indicator-datetime doesn’t get geoclue information from ubuntu-geoip-provider" [Undecided,New] | 11:43 |
| pitti | seb128: ah :) | 11:43 |
| seb128 | pitti, you might get that bug | 11:43 |
| rodrigo_ | right, it indeed uses some Gnome. stuff, just for the filepicker button | 11:43 |
| rodrigo_ | I guess we can just change that to use Gtk.FileChooser | 11:43 |
| seb128 | rodrigo_, is that exposed to the clients? i.e would that be an api, abi breakage? | 11:44 |
| rodrigo_ | not exposed, afaics | 11:45 |
| seb128 | rodrigo_, did you talk to upstream tomboy about that? | 11:45 |
| seb128 | just to know what they think | 11:45 |
| rodrigo_ | seb128, yes, but it's got nothing to do really with tomboy, tomboy just uses the PropertyEditor objects in gconf# | 11:46 |
| Laney | ddd | 11:46 |
| seb128 | rodrigo_, well, it uses an api which use libgnome | 11:46 |
| rodrigo_ | yes, but lignome usage is internal to gnome-sharp | 11:46 |
| seb128 | rodrigo_, so they need to clean that in some way, either by moving away from propertyeditor or by changing the bindings | 11:46 |
| seb128 | rodrigo_, right, so either we move the issue to gnome-sharp | 11:47 |
| rodrigo_ | yes, changing the bindings is the easiest, it seems | 11:47 |
| seb128 | or we port tomboy to not use propertyeditor | 11:47 |
| rodrigo_ | the usage of PEditor in tomboy is huge | 11:47 |
| seb128 | bah | 11:48 |
| seb128 | so it means gconfpeditor should be updated to stop using libgnome | 11:48 |
| seb128 | then the libgnome2.24-cil should be splitted | 11:48 |
| Laney | it would be an api break as far as i can see | 11:48 |
| seb128 | or the gconfpeditor binding moved with gconf# | 11:48 |
| Laney | void Changed (object obj, Gnome.ColorSetArgs args) | 11:49 |
| rodrigo_ | yeah, indeed | 11:49 |
| seb128 | k | 11:49 |
| seb128 | tomboy really need to stop using gconfpeditor | 11:49 |
| seb128 | to switch to gsettings or something | 11:49 |
| seb128 | rodrigo_, just forget about it for this cycle then, porting tomboy to gconf# seems work over what it's worth | 11:50 |
| rodrigo_ | ok, but I'll change the description of the bug | 11:50 |
| seb128 | shame because it's the only thing keeping libgnomeui and libgnome on the default install | 11:50 |
| seb128 | rodrigo_, can you check with upstream what are they gnome3 plans anyway? | 11:50 |
| seb128 | they need to stop using libgnome some day | 11:50 |
| seb128 | using gsettings or something else | 11:50 |
| rodrigo_ | seb128, sure | 11:50 |
| seb128 | thanks | 11:51 |
| Laney | the mono gi stuff is currently being hacked on | 11:51 |
| Laney | so we should be able to get better bindings in the near future | 11:51 |
| seb128 | those will be really welcome | 11:52 |
| seb128 | it sucks to be stucked with old libs because mono is so behind | 11:52 |
| seb128 | ups | 11:52 |
| seb128 | Laney, btw is there any plan in debian to update mono from 2.6 to 2.8? | 11:53 |
| seb128 | Laney, or alternatively any reason why 2.6 is better? | 11:54 |
| Laney | we are skipping to 2.10 and it's being worked in git currently | 11:55 |
| Laney | most of the work was on polishing for squeeze | 11:55 |
| seb128 | ok... | 11:56 |
| seb128 | is 2.10 out yet? will that land in debian before natty feature freeze or not? | 11:56 |
| seb128 | just trying to figure what we should do in natty | 11:56 |
| seb128 | hum, lunch time | 11:56 |
| Laney | it's on RC2 currently, and no probably not | 11:56 |
| seb128 | ok | 11:56 |
| seb128 | so I guess stay on 2.6 | 11:56 |
| seb128 | thanks | 11:56 |
| === artir is now known as Artir | ||
| dpm | hey didrocks, are you still having issues ssh'ing to people.canonical.com? I am having them now, but I want to confirm it's not just me before asking IS | 12:16 |
| didrocks | dpm: just tried, it seems to be okayish… the ssh connectin hasn't dropped for a minute… | 12:17 |
| dpm | ok, thanks didrocks | 12:18 |
| dpm | ah, it just worked for me right now as well | 12:19 |
| didrocks | seems that there are some underlaying network issue in any case… | 12:20 |
| === MacSlow|lunch is now known as MacSlow | ||
| seb128 | rodrigo_, did you confirm the vino issue or just reopened the bug to track it? | 12:32 |
| === smspillaz|eating is now known as smspillaz | ||
| rodrigo_ | seb128, confirmed it, and found it seems to be an avahi issue | 12:33 |
| rodrigo_ | seb128, see my last comment | 12:33 |
| seb128 | rodrigo_, ok, emails are lagging behind, I just got the one about the bug being reopen and assigned to you | 12:35 |
| rodrigo_ | seb128, my comment: "Following DaveHansen's comment, if you stop avahi daemon, no CPU high usage. Ditto if you restart avahi daemon again after having stopped it. So seems it's indeed an avahi problem" | 12:35 |
| seb128 | just read the comment on launchpad | 12:35 |
| seb128 | rodrigo_, yeah, got it now, thanks ;-) | 12:35 |
| rodrigo_ | I'm debugging avahi-daemon now, although it seems I'll need to restart the session | 12:36 |
| rodrigo_ | can't get it to use 100% cpu now | 12:36 |
| rodrigo_ | well, 40% for me, rather than 100% | 12:36 |
| seb128 | I usually get the issue by running vino-preference and checking, unchecking the checkbox to share | 12:37 |
| === evilvish is now known as vish | ||
| rodrigo_ | seb128, yes, me too, but after restarting avahi-daemon, can't | 12:38 |
| dpm | pitti, chrisccoulson, ok re: the lucid-proposed language packs, it seems that FF translation breakage only affects the whitelisted languages in po2xpi (that's 'fi' and 'oc'). I've reported it on bug 715733 | 12:39 |
| ubot2 | Launchpad bug 715733 in po2xpi "XPI files are not correctly built for whitelisted templates" [Undecided,New] https://launchpad.net/bugs/715733 | 12:39 |
| seb128 | chrisccoulson, current firefox failed to build on armel and powerpc, fix it! ;-) | 12:47 |
| seb128 | didrocks, current unity failed to build, fix it ;-) | 12:47 |
| didrocks | seb128: trunk or the package? | 12:48 |
| seb128 | if you wonder about those it's thanks to robert_ancell who made build failures be listed on http://people.canonical.com/~platform/desktop/versions.html | 12:48 |
| seb128 | didrocks, 3.4.0-0ubuntu2 | 12:48 |
| seb128 | didrocks, though a retry now that glew is fixed might work? | 12:48 |
| seb128 | let me try that | 12:48 |
| chrisccoulson | seb128 - one step ahead of you already ;) http://bazaar.launchpad.net/~mozillateam/firefox/firefox-4.0.head/revision/759 | 12:49 |
| didrocks | seb128: yeah, it was due to glew | 12:49 |
| didrocks | seb128: I didn't retried on purpose, thinking that for such a small fix in alpha2, it will prevent people pushing their bugs with apport | 12:49 |
| didrocks | now, I think it's fine | 12:49 |
| seb128 | didrocks, ok, let's try then | 12:49 |
| seb128 | chrisccoulson, ok, you are fine for this time but we are watching you :p | 12:49 |
| didrocks | (taking the predicate that apport is basing the version on the published binary ) | 12:49 |
| chrisccoulson | heh :) | 12:50 |
| didrocks | hope that the second time I'm fixing the same issue in glew will be the latest | 12:50 |
| seb128 | didrocks, there is a new glew in debian btw | 12:50 |
| seb128 | should we sync? ;-) | 12:50 |
| didrocks | seb128: just look if the .pc file requires glu :) | 12:51 |
| didrocks | then, for driver issue, I'm not there anymore \o/ | 12:51 |
| didrocks | maybe better to wait on an unity release to blame dx :) | 12:51 |
| didrocks | like "I updated glew and unity and unity doesn't run!" :) | 12:52 |
| seb128 | lol | 12:52 |
| seb128 | yeah ;-) | 12:52 |
| didrocks | (I can also update compiz too to add to the confusion ;)) | 12:52 |
| Sweetshark | \o/ the libreoffice package finished to build ... | 13:02 |
| Sweetshark | ... kinda ... | 13:02 |
| Sweetshark | ... well, it chrashes in smoketest, but thats what smoketests are for, right? | 13:03 |
| pitti | dpm: thanks; so let me remove them from the whitelist and rebuild these two | 13:17 |
| dpm | pitti, ok. Could you please also remove the 'ca' language packs from lucid-proposed? They are failing as well (Firefox in English, no FF translations in the langpack), but probably for some other reason | 13:18 |
| pitti | dpm: ah, oc and fi's mozilla.tar.gz are unpacked, while the others have a XX.jar archive | 13:23 |
| mvo | didrocks: what is the best way to test oneconf when you only have one machine? | 13:29 |
| mvo | didrocks: is there something like FAKE_MACHINE=1 ;) ? | 13:29 |
| pitti | VMs? | 13:30 |
| didrocks | mvo: I think I wanted to implement that, not sure I've done, let me check :) | 13:30 |
| didrocks | # faking this id for testing purpose | 13:31 |
| didrocks | #self.hostid = 'BBBBBB' | 13:31 |
| didrocks | #self.hostname = "foomachine" | 13:31 |
| didrocks | in oneconf/hosts.py | 13:31 |
| didrocks | mvo: ^ | 13:31 |
| didrocks | just uncomment to override real values :) | 13:31 |
| didrocks | then oneconf-query --update to get a first set | 13:31 |
| mvo | cool, thanks didrocks | 13:32 |
| cyphermox | hey didrocks | 13:41 |
| mterry | seb128, still able to crash reliably? I have a test package for you to try | 13:41 |
| seb128 | mterry, hey, just tried, first try, first crash | 13:42 |
| seb128 | so I guess it's a "yes" ;-) | 13:42 |
| mterry | seb128, https://launchpad.net/~mterry/+archive/ppa | 13:42 |
| didrocks | hey cyphermox | 13:42 |
| cyphermox | didrocks, about my issues with building unity ;) what I was referring to was specifically using "bzr bd" to locally build a deb for hacking. I'm aware it's no good for making sure that it builds cleanly, but it's fewer steps for hacking and testing than bzr bd -S && pbuilder, for example | 13:43 |
| seb128 | mterry, do you have a vcs for it? | 13:43 |
| mterry | seb128, it's got a new version of libdbusmenu with a patch that avoids freeing a particular object. It quieted a lot of warnings about trying to disconnect signals from invalid objects for me | 13:43 |
| seb128 | mterry, don't bother I will grab the debdiff | 13:43 |
| mterry | seb128, not yet, but will have one in a sec | 13:43 |
| didrocks | cyphermox: right, but you have a FTBFS, right? | 13:43 |
| mterry | seb128, ok | 13:43 |
| didrocks | cyphermox: I think it's related to your branch | 13:43 |
| seb128 | mterry, I just want to build locally so I still have the dbgsym for it | 13:43 |
| didrocks | cyphermox: or you can, for hacking installing unity | 13:43 |
| didrocks | cyphermox: then, with next release, unity --distro to remove all the cruft | 13:44 |
| seb128 | we need soyuz dbgsym support | 13:44 |
| cyphermox | didrocks, it fails if I take lp:~ubuntu-desktop/unity/ubuntu ;) | 13:44 |
| seb128 | didrocks, is anybody else than you is able to build unity? | 13:44 |
| pitti | dpm: I uploaded (hopefully) fixed -oc and -fi langpacks to lucid-proposed | 13:44 |
| seb128 | didrocks, you are sure you don't have a special compiz environment set? | 13:44 |
| didrocks | seb128: you were, I didn't change the packaging though | 13:44 |
| seb128 | didrocks, not I'm not | 13:44 |
| didrocks | nothing in my env | 13:44 |
| seb128 | it try to install to debian/$curdir/$destdir | 13:45 |
| didrocks | seb128: like, it's not building for you? | 13:45 |
| cyphermox | didrocks, the issue is really that somehow, unless I set COMPIZ_DESTDIR, stuff gets installed in an invalid path | 13:45 |
| seb128 | remember? | 13:45 |
| didrocks | cyphermox: COMPIZ_DESTDIR shouldn't be used | 13:45 |
| dpm | pitti, ah, cool. Did you read the message about the 'ca' ones above? ^ I don't know what's going on there, so for now I think it might be best just to remove it from -proposed | 13:45 |
| didrocks | cyphermox: it's breaking COMPIZ and other wrapper | 13:45 |
| didrocks | cyphermox: we will remove it as told | 13:45 |
| cyphermox | didrocks, I realize it might not be a good idea, just saying it "works" for now | 13:45 |
| pitti | dpm: yes, I removed it | 13:45 |
| didrocks | seb128: and there was no issue in a pbuilder, right? | 13:45 |
| seb128 | didrocks, we did chat a bit about that a few weeks back | 13:45 |
| dpm | pitti, ok, thanks | 13:46 |
| pitti | dpm: I responsed, but apparently you got hit by DSL reconnect or so? | 13:46 |
| seb128 | didrocks, didn't try pbuilder but it builds on the buildds | 13:46 |
| didrocks | seb128: yeah, I remember now, I would say that you have something in your env then :) | 13:46 |
| seb128 | didrocks, ok, I though you were discussing similar issues | 13:46 |
| didrocks | for the same reason I can't build nux here, but ona pbuilder it works | 13:46 |
| seb128 | I will go back in my corner | 13:46 |
| dpm | pitti, yeah, sorry, I didn't get the response | 13:46 |
| didrocks | cyphermox: setting COMPIZ_DESTDIR is a workaround that is bad. The thing is to find what causes that to you | 13:47 |
| didrocks | I build unity in another box to check as well | 13:47 |
| didrocks | (a clean install) | 13:47 |
| didrocks | it's working as well | 13:47 |
| cyphermox | didrocks, there is nothing I can think of in env that would cause this -- I'm trying another box now | 13:47 |
| didrocks | cyphermox: yeah, please, keep me posted | 13:47 |
| === oubiwann is now known as oubiwann_ | ||
| cyphermox | didrocks, I'll try on a live session jsut for you ;) | 13:47 |
| seb128 | didrocks, it's weird, this box has for sure nothing not coming from the distro | 13:48 |
| ari-tczew | is there anyone familiar with gnutls26 ? | 13:48 |
| ari-tczew | I'm going to upgrade this package and looking for concerns, if so. | 13:48 |
| didrocks | seb128: yeah, there should be something, if someone with a box providing this issue wants to investigate | 13:48 |
| didrocks | but not setting COMPIZ_DESTDIR :) | 13:48 |
| seb128 | it's a weird one | 13:49 |
| cyphermox | didrocks, I'm getting a usb key ready, then I'll post full bzr bd logs from a clean copy of lp:~ubuntu-desktop/unity/ubuntu | 13:49 |
| seb128 | seems cmake related | 13:49 |
| didrocks | seb128: yeah, as my nux and doxygen not building :/ | 13:49 |
| seb128 | but I don't know enough about cmake to debug it | 13:49 |
| didrocks | cyphermox: excellet | 13:49 |
| didrocks | seb128: all the compiz cmake should be rewritten, honestly… | 13:50 |
| seb128 | ari-tczew, no one here | 13:50 |
| cyphermox | seb128, it is, somehow it's detecting compiz's install path wrong, but I'm convinced it's not env | 13:50 |
| didrocks | I spent enough time to just make it works aleady | 13:50 |
| didrocks | already* | 13:50 |
| Amaranth | didrocks: Hey, I like the compiz build system :) | 13:56 |
| Amaranth | The way plugin building is setup mainly | 13:56 |
| didrocks | Amaranth: well, it's broken… | 13:56 |
| didrocks | needs a good refresh and refactoring | 13:56 |
| Amaranth | You can pull a single plugin out and build it standalone but core know how to handle them all as well with the same CMakeLists.txt | 13:57 |
| didrocks | yeah, this part is good :) | 13:57 |
| didrocks | (and we use it) | 13:57 |
| Amaranth | although some of it ended up being the usual build system hacks on top of hacks | 13:57 |
| * bcurtiswx waves to room | 14:07 | |
| seb128 | hey bcurtiswx | 14:12 |
| seb128 | mterry, ok, seems to fix it, I tried 6 times without issues | 14:12 |
| seb128 | mterry, it crashed every second time in average before | 14:12 |
| seb128 | mterry, I will keep playing a bit with it but seems to work | 14:13 |
| mterry | seb128, sweet. Now I have to figure out how to make a real patch vs that quick fix | 14:13 |
| seb128 | bcurtiswx, the m-c bug you emailed me about, not sure it's really a bug... | 14:13 |
| seb128 | mterry, do you know what is wrong or do you need a valgrind log pointing it? | 14:14 |
| seb128 | mterry, I guess valgrind would show the issue | 14:14 |
| bcurtiswx | seb128, OK, thanks for looking at it :) | 14:14 |
| seb128 | kklimonda, hi. | 14:14 |
| mterry | seb128, no, I know the issue... | 14:14 |
| seb128 | mterry, ok, great, let me know if you need testing for the proper fix later on then | 14:14 |
| mterry | seb128, when the app's menu items are finalized, they try to disconnect from the accel group that the dbusmenu client is holding | 14:14 |
| mterry | seb128, I just haven't been able to find the appropriate point at which to let go of the accel group yet | 14:15 |
| seb128 | ok | 14:15 |
| mterry | seb128, I shouldn't need further testing. I see warnings when I hit the bug, it just doesn't crash like it does for you. So as long as I can make those warnings go away, I'm good | 14:15 |
| seb128 | mterry, ok, excellent | 14:16 |
| kklimonda | seb128: hey | 14:16 |
| seb128 | kklimonda, how are you? | 14:16 |
| didrocks | cyphermox: did it build? | 14:16 |
| cyphermox | didrocks, didn't get to it yet, my iso from yesterday would oops. | 14:17 |
| kklimonda | seb128: a bit tired, just got back from a long walk and I'm trying to make a fire in the fireplace ;) | 14:17 |
| seb128 | heh, some exercice! | 14:18 |
| seb128 | kklimonda, bug #715046, do you want to work on it? | 14:18 |
| ubot2 | Launchpad bug 715046 in transmission "[Natty] Update Transmission to version 2.21" [Undecided,New] https://launchpad.net/bugs/715046 | 14:18 |
| seb128 | kklimonda, if so can you tag it desktop-upgrade and assign it to you? | 14:18 |
| kklimonda | seb128: I will work on it, but it may not be possible to update it in natty. | 14:19 |
| seb128 | kklimonda, why? | 14:19 |
| seb128 | kklimonda, well in any case just comment on the bug if it's not | 14:19 |
| kklimonda | upstream has decided to use the new libevent, which isn't completely API comptaible with the old one, and I can't couldn't fix all packages that depend on the old libevent so far. | 14:20 |
| seb128 | kklimonda, can we use the new one with the commit requiring the new libevent reverted? | 14:21 |
| kklimonda | whoa, nothing like a 4 second lag to make what your write sound like a complely blabbering ;) | 14:21 |
| kklimonda | seb128: I don't think it's worth an effort (the rewrite has been one of the most important things in 2.20) but I'll take a look when I'm back, and ask upstream to reconsider bundling libevent2 in their source, like they did before with libevent1. We could also consider doing it ourselves. | 14:22 |
| seb128 | kklimonda, well in any case if you tag and assign the bug that will avoid work duplication | 14:23 |
| seb128 | so maybe just drop a comment on the bug saying what you wrote there? | 14:23 |
| seb128 | kklimonda, thanks | 14:23 |
| kklimonda | yes, I'll coment on the bug in a minute. | 14:24 |
| kklimonda | at least assign it to myself, I'd like to ask T dev about rebundling libevent2 before I I do any more commenting :) | 14:24 |
| cassidy | hey guys. Any plan to ship glib-networking? You need it to be able to use proxies in Telepathy | 14:32 |
| didrocks | kiwinote_: hey, are you around? | 14:37 |
| kiwinote_ | didrocks: yep | 14:37 |
| didrocks | kiwinote_: I was wondering if you can shed some light on the -2 magic :) | 14:38 |
| lamalex_ | bryceh, is there any eta on nvidia drivers? | 14:38 |
| didrocks | kiwinote_: in the ref count, when there is a direct match to the serach | 14:38 |
| kiwinote_ | didrocks: um yeah, that's a bit quirky | 14:38 |
| kiwinote_ | didrocks: I aren't quite sure, but I think the query consists of different parts, and on each iteration the nr_pkgs, nr_apps counters aren't reset | 14:39 |
| kiwinote_ | didrocks: I made that change because it would seem to give correct results now, if it disadvantages any oneconf stuff, just let me know | 14:40 |
| didrocks | kiwinote_: no, I'm fixing other stuff for oneconf, but the match seems correct now | 14:40 |
| didrocks | kiwinote_: so, I was just unfortunate that pkgs - apps was exactly the right count. I was assuming pkgs was the total, not only technical items :) | 14:41 |
| didrocks | I was quite curious of the fix though | 14:41 |
| kiwinote_ | didrocks: yeah - in maverick the nr_pkgs was the total of all pkgs and apps, but that's changed now | 14:41 |
| didrocks | kiwinote_: right ;) well, I'm adapting to it, but the "look at the total result if there is no app found" is giving me some headaches :) | 14:42 |
| seb128 | cassidy, is that in debian? we could just sync it if that's there | 14:53 |
| cassidy | it is | 14:53 |
| cassidy | I'm trying to open a lp bug about that since 10 minutes.. | 14:53 |
| cassidy | but I'm always redirected to https://help.ubuntu.com/community/ReportingBugs | 14:53 |
| chrisccoulson | does anybody actually use thunderbird? i've had no bugs about the menus so far. not sure if that's good or bad ;) | 14:55 |
| kenvandine | chrisccoulson, hehe... there are always bugs :) | 14:57 |
| seb128 | cassidy, right, we turn off bug reporting for non bugsquad by default | 14:57 |
| cassidy | didrocks, rahh I could have spend my day on this :p | 14:57 |
| seb128 | cassidy, see the ?no-redirect url in the wiki | 14:57 |
| cassidy | I tried, didn't work | 14:57 |
| didrocks | cassidy: I know that, hence the ?no-redirect pointer I gave you | 14:58 |
| seb128 | cassidy, http://bugs.launchpad.net/ubuntu/+filebug?no-redirect | 14:58 |
| seb128 | doesn't work? | 14:58 |
| cassidy | it does ! | 14:58 |
| * cassidy blames didrocks | 14:58 | |
| didrocks | why? | 14:58 |
| cassidy | <didrocks> c'est le ?no-redirec la magie | 14:58 |
| seb128 | lol | 14:58 |
| seb128 | with a "t" | 14:58 |
| seb128 | cassidy, subscribe ubuntu-sponsors to the request while you are at it | 14:59 |
| cassidy | isn't that a bit too complex to just report a bug ? :\ | 14:59 |
| seb128 | cassidy, well usually you use "report a bug" in the menus | 14:59 |
| seb128 | or ubuntu-bug | 14:59 |
| seb128 | which collect infos etc for you | 14:59 |
| didrocks | cassidy: I told you it's written on https://help.ubuntu.com/community/ReportingBugs :p | 15:00 |
| seb128 | cassidy, the goal is to discourage opening bug without apport since those lack infos | 15:00 |
| cassidy | yeah but ubuntu-bug doesn't work for the ubuntu component | 15:00 |
| didrocks | cassidy: ubuntu-bug without anything | 15:00 |
| cassidy | yeah didn't work, there is "I want to report on Ubuntu" | 15:01 |
| cassidy | it asks if that's a security, X issue, etc | 15:01 |
| seb128 | hum indeed | 15:01 |
| seb128 | well those are sort of a corner case | 15:01 |
| seb128 | but seems an apport bug as well | 15:01 |
| seb128 | you can probably open a bug on apport about it | 15:02 |
| seb128 | seems it should be working | 15:02 |
| cassidy | seb128, didrocks: bigon: https://bugs.launchpad.net/ubuntu/+bug/715821 | 15:02 |
| ubot2 | Launchpad bug 715821 in ubuntu "Sync glib-networking from Debian" [Undecided,New] | 15:02 |
| didrocks | cassidy: thanks | 15:02 |
| bratsche | didrocks around? | 15:21 |
| didrocks | bratsche: yes? | 15:21 |
| seb128 | hey bratsche, how are you? | 15:21 |
| bratsche | didrocks: I was told I should ping you and let you know I'm trying to get libgrip into universe. I submitted a request here: https://bugs.launchpad.net/ubuntu/+bug/715830 | 15:22 |
| ubot2 | Launchpad bug 715830 in ubuntu "New Source Package: libgrip" [Undecided,New] | 15:22 |
| bratsche | Hi seb128, I'm okay. How are you? | 15:22 |
| seb128 | bratsche, I'm fine thanks | 15:22 |
| didrocks | bratsche: ok, I can check the package and look at it, thanks :) | 15:22 |
| bratsche | didrocks: Thanks! | 15:22 |
| didrocks | bratsche: not exactly right now, but later today or tomorrow | 15:22 |
| bratsche | Sure, no worries. | 15:23 |
| didrocks | yw ;) | 15:23 |
| rodrigo_ | in which branches are the maverick packages? | 15:36 |
| dobey | rodrigo_: lp:ubuntu/maverick/$sourcpkgname | 15:39 |
| dobey | rodrigo_: or did you mean something else? | 15:39 |
| rodrigo_ | dobey, that's what I mean, but the gtk package is not there | 15:40 |
| seb128 | rodrigo_, we don't keep stable vcs for most of the desktop things | 15:40 |
| seb128 | we don't work enough on stable versions to do that | 15:40 |
| rodrigo_ | right, but I thought they were pushed to maverick branches automatically | 15:41 |
| seb128 | rodrigo_, so I guess you need to checkout the revision before we started worked on natty or check the sru version control | 15:41 |
| * Sweetshark just got work: http://cgit.freedesktop.org/libreoffice/build/tag/?id=libreoffice-3.3.1.1 | 15:41 | |
| seb128 | rodrigo_, well the autoimport will work, what dobey said | 15:41 |
| dobey | rodrigo_: it looks like it is there to me | 15:41 |
| dobey | rodrigo_: https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/gtk+2.0/maverick | 15:41 |
| rodrigo_ | ah, it's gtk+2.0 | 15:41 |
| dobey | :) | 15:42 |
| Sarvatt | MacSlow: any chance you could merge https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/654921 somtime? been blocking a pixman update on that getting fixed since it will look ugly | 15:43 |
| ubot2 | Launchpad bug 654921 in notify-osd "Black border in the notifications when effects are turned off" [Undecided,Confirmed] | 15:43 |
| jcastro | chrisccoulson: when in the cycle do you plan on landing appmenu for firefox? | 15:44 |
| MacSlow | Sarvatt, on the weekend I will address notify-osd... right now there's still unity-features on my plate that need to land before the weekend | 15:45 |
| Sarvatt | sounds good, thanks for taking a look at it! pixman wasn't building with our GCC for a few months anyway so no rush, just would like to update it before natty release because it has quite a few speedups for the people using ARM systems | 15:46 |
| dpm | pitti, ok, it seems that the problem might not be with po2xpi, but with the exported files from LP: bug 715854 | 16:00 |
| ubot2 | Launchpad bug 715854 in launchpad "Exported Firefox translations contain wrong references to languages other than the current" [Undecided,New] https://launchpad.net/bugs/715854 | 16:00 |
| seb128 | kenvandine, mterry: it's getting hard finding appmenu issues! | 16:04 |
| mterry | seb128, yay | 16:04 |
| seb128 | I've been triaging the bugs and playing it there, only find really minor issues | 16:04 |
| seb128 | mterry, seems there is one issue with icons, interested by working on it? | 16:05 |
| mterry | seb128, sure | 16:06 |
| seb128 | mterry, ok, I will open a bug and assign it to you | 16:06 |
| seb128 | mterry, nautilus "go" menu has no icons for the standard locations | 16:06 |
| seb128 | computer, trash, etc | 16:06 |
| seb128 | u1 in the file menu also has an icon where it doesn't in the normal menu | 16:06 |
| seb128 | mterry, I've set APPMENU_DISPLAY_BOTH=1 in my session to test | 16:07 |
| seb128 | comparing both menus | 16:07 |
| mterry | seb128, weird, cool. assign me up | 16:08 |
| seb128 | mterry, bug #715864 | 16:11 |
| ubot2 | Launchpad bug 715864 in indicator-appmenu "icons not always displayed as they should" [Undecided,New] https://launchpad.net/bugs/715864 | 16:11 |
| cyphermox | didrocks, I can't reproduce it on a live session -- seems like somehow once my environment is all set for building packages, there's a difference from an install of just bzr, bzr-builddeb and unity build-deps | 16:11 |
| didrocks | cyphermox: right, if you see something, do not hesitate to ping me :) | 16:11 |
| cyphermox | didrocks, I did see something | 16:11 |
| didrocks | (I'm using bzr bd as well) | 16:12 |
| didrocks | cyphermox: oh? a fix? | 16:12 |
| cyphermox | looks like changing COMPIZ_PLUGIN_INSTALL_TYPE to compiz from package will get good results, but I guess that might break something else | 16:12 |
| cyphermox | also didn't try that on buildds or pbuilder yet :/ | 16:13 |
| rodrigo_ | oh, accountsservice from the gnome3 ppa is now in universe? | 16:13 |
| seb128 | rodrigo_, right, got synced from debian | 16:13 |
| rodrigo_ | cool | 16:13 |
| cyphermox | didrocks, seems like something is setting both DESTDIR and COMPIZ_DESTDIR, which is why the paths are doubled there when the plugin gets installed (in the bug I filed) | 16:13 |
| didrocks | cyphermox: wait? I didn't set it to package? | 16:13 |
| cyphermox | didrocks, no, you did | 16:13 |
| didrocks | cyphermox: yeah, hence my "COMPIZ_DESTDIR is broken" | 16:14 |
| didrocks | package is what should be set | 16:14 |
| didrocks | to get the right debug options triggeed | 16:14 |
| didrocks | triggered* | 16:14 |
| didrocks | and so generating -dbgsym | 16:14 |
| cyphermox | right | 16:14 |
| cyphermox | but nah, it still didn't work anyway | 16:14 |
| cyphermox | didrocks, the issue is that here DESTDIR is already set, but in CompizPlugin.cmake COMPIZ_DESTDIR also gets set to DESTDIR -- in the same file, the plugin is set to be installed to ${COMPIZ_DESTDIR}/somethingsomething | 16:16 |
| didrocks | cyphermox: I know, but CompizPlugin.cmake set COMPIZ_DESTDIR only in Compiz mode normally | 16:16 |
| didrocks | not package one | 16:16 |
| cyphermox | hm | 16:17 |
| seb128 | ok... | 16:19 |
| seb128 | mterry, do you know where is the code to display the "close" item for dialogs which don't have a menu to display? | 16:19 |
| mterry | seb128, I believe in indicator-appmenu | 16:19 |
| seb128 | mterry, ok, can you confirm the "close" entry is inactive on i.e vino-preference | 16:20 |
| mterry | seb128, works for me | 16:20 |
| seb128 | hum, k | 16:20 |
| seb128 | mterry, it seems random there but is the entry is unactive for quite some capplets there | 16:22 |
| seb128 | does it work for others? | 16:23 |
| seb128 | didrocks, pitti, rodrigo_: ^ | 16:23 |
| desrt | mterry: 0.7.2 makes you happy? | 16:24 |
| rodrigo_ | seb128, hmm, 2.32 capplets you mean? | 16:24 |
| seb128 | rodrigo_, yes, well dialogs which don't have a menu, gnome-mouse-properties, vino-properties, alacarte, etc | 16:25 |
| mterry | desrt, except for https://bugzilla.gnome.org/show_bug.cgi?id=640683 yes | 16:26 |
| ubot2 | Gnome bug 640683 in gsettings backend "Mutex deadlock on unsubscribe" [Normal,Unconfirmed] | 16:26 |
| rodrigo_ | seb128, I have gcc 3.0 here, but for vino-preferences, it's not inactive | 16:26 |
| mterry | desrt, but I have worked around that for my case, and I think it's a hard-to-reproduce one | 16:26 |
| seb128 | rodrigo_, ok, thank you | 16:26 |
| desrt | that's probably gdbus, right? | 16:26 |
| seb128 | rodrigo_, small issue but I will watch for it | 16:26 |
| rodrigo_ | seb128, you're welcome :) | 16:26 |
| * desrt catches up on the bug | 16:27 | |
| mterry | desrt, either that or how dconf uses it | 16:27 |
| desrt | mterry: we have another bug open about 'use of gdbus' too :) | 16:27 |
| desrt | But notably, these widgets don't make an attempt to avoid setting a value if | 16:30 |
| desrt | that same value is in GSettings already. | 16:30 |
| desrt | mterry; :( | 16:30 |
| desrt | does that include when the initial value of the widget is set (ie: when starting up the app?) | 16:31 |
| desrt | if so, it's **very** broken | 16:31 |
| pitti | hey desrt, how are you? | 16:32 |
| desrt | pretty good | 16:32 |
| desrt | got a fun project this week :) | 16:32 |
| desrt | so i'm happy :p | 16:32 |
| pitti | desrt: FTR, my pygobject patch for gsettings landed :) | 16:32 |
| pitti | desrt: oh, what are you doing? | 16:32 |
| desrt | what're you working on? | 16:32 |
| desrt | NICE | 16:32 |
| desrt | the settings['key'] = (1,2,3) thing? | 16:33 |
| pitti | desrt: the "dict-like settings object", yes | 16:33 |
| desrt | did you do the automatic type hinting for the GVariant construction? | 16:33 |
| pitti | desrt: we are currently discussing how/when to release | 16:33 |
| pitti | desrt: yes, with the get_range() thing; although only with some limited support | 16:33 |
| desrt | what limits? | 16:33 |
| pitti | desrt: I only support the "type" range | 16:34 |
| desrt | btw: you can use the information from get_range() to ensure you never make a call that issues a g_critical() or aborts | 16:34 |
| desrt | ah. i see :) | 16:34 |
| pitti | desrt: I haven't had time yet to implement the others (range/flags), they just throw a NotImplementedError for now | 16:34 |
| pitti | I think that's ok given that code which uses that is mostly 'static' | 16:34 |
| desrt | would be really nice if you could throw a range exception for the others | 16:34 |
| desrt | i guess you already throw a type exception if gvariant conversion fails? | 16:35 |
| pitti | desrt: once they are implemented? yes, shoudl be a ValueError then | 16:35 |
| pitti | desrt: yes | 16:35 |
| desrt | (which should automatically ensure that you always have the right type...) | 16:35 |
| desrt | that's really slick :) | 16:35 |
| desrt | brings us somewhere close to the QML API now | 16:35 |
| pitti | desrt: yeah, I noticed that the current gvariant implementation is very sensitive -- one false step and BANG! you program crashes | 16:35 |
| desrt | except that python has no convention for monitoring property values for changes, unfortunately | 16:36 |
| pitti | desrt: that's why I need to do rather expensive "does this key exist" tests before calling set_value() etc. | 16:36 |
| desrt | pitti: i went through a phase a year or so ago about "WTF is with all of these g_critical() errors in my xsession-errors"? | 16:36 |
| desrt | which motivated me to turn all of my g_criticals into asserts :) | 16:36 |
| Amaranth | Or get people to run with GDEBUG again | 16:37 |
| Amaranth | critical-errors or whatever | 16:37 |
| desrt | the best suggestion i heard is to sleep(10) on each g_critical :) | 16:38 |
| * desrt . o O ( wonder how long it takes for you guys to vendor-patch that one out ) | 16:38 | |
| mterry | desrt, right, my app didn't have any smarts to avoid the changed-set cycle on startup. I would argue that using the api like that shouldn't cause a bug, but it was inefficient | 16:39 |
| desrt | anyway... it's vaguely on my list of things to do to go through and turn a lot of those asserts into return_if_fail()s | 16:39 |
| mterry | desrt, is there a reason that dconf doesn't guard against that for apps? | 16:39 |
| desrt | mterry: it's sometimes difficult for dconf to know what is already in the database | 16:40 |
| desrt | since some changes might be in-flight | 16:40 |
| desrt | it's not really a problem of what ends up in the database at the end of it all because that's inherently a simple (non-buggy) race | 16:41 |
| desrt | but it's an issue of ensuring that the state of the widget is consistent with what the final value ends up being | 16:41 |
| desrt | and it's not always possible to ensure that we'll always see a change signal after the skipped set request | 16:41 |
| desrt | last time i looked at it i was unable to convince myself that it would be 'safe' in all cases | 16:42 |
| === alecu is now known as alecu-lunch | ||
| desrt | we also need to carefully make the distinction about the meaning of writing a setting which is equal to the value of the setting in the systems-wide default database | 16:44 |
| desrt | since probably we *do* want to write those even still | 16:44 |
| desrt | the rule for app authors is quite simple, though: only do GSettings writes in response to explicit user action | 16:44 |
| ogra | didrocks, tickle | 16:45 |
| * desrt should document that | 16:45 | |
| didrocks | ogra: hey | 16:46 |
| ogra | didrocks, the unity-2d team asked for two more patches to be included in metacity | 16:46 |
| ogra | https://code.launchpad.net/~unity-2d-team/unity-2d/metacity (commits 100 to 102) | 16:47 |
| didrocks | ogra: is there an ABI break? | 16:47 |
| ogra | i would like to get a signoff from the desktop team | 16:47 |
| ogra | hmm, not sure, it adds new functions | 16:47 |
| ogra | but doesnt modify existing ones as far as i can see | 16:47 |
| didrocks | debian/patches/17-workspace-switcher-cycle.patch | 16:48 |
| didrocks | -> we don't have that behavior in compiz | 16:48 |
| didrocks | it seems wrong | 16:48 |
| ogra | weird, wha does bfiller think we do then | 16:48 |
| ogra | *why | 16:48 |
| bfiller | didrocks: compiz desktop cube has this behavior will allow you to rotate from last side of cube to first side | 16:49 |
| ogra | ah, here he is | 16:49 |
| didrocks | bfiller: right, but we don't use cube by default | 16:49 |
| didrocks | bfiller: we have staticswitcher, where we don't use the behavior on purpose | 16:49 |
| didrocks | that* | 16:50 |
| didrocks | ogra: /apps/metacity/general/capture_before_unmap change seems fine if you can confirm it doesn't slow down on minimize | 16:50 |
| ogra | i will test it tomorrow | 16:50 |
| ogra | thanks | 16:50 |
| bfiller | didrocks: what if I made it configurable via gconf whould it be acceptable? | 16:50 |
| didrocks | bfiller: sure, but the default should be off | 16:50 |
| bfiller | didrocks: sounds good, I will rework it then | 16:51 |
| ogra | didrocks, apart from that change it is ok to go in ? | 16:51 |
| didrocks | bfiller: propose it upstream as well btw | 16:51 |
| didrocks | ogra: yeah, after the test :) | 16:51 |
| ogra | i.e. i dont need to bother you again and just upload after testing | 16:51 |
| ogra | right :) | 16:51 |
| ogra | great, thanks | 16:52 |
| bfiller | didrocks: ok | 16:52 |
| didrocks | yw | 16:52 |
| desrt | mterry: i just committed a docs patch that makes your code officially buggy :) | 16:57 |
| desrt | mterry: of course, i'll still keep the bug open and investigate the root issue, though | 16:57 |
| desrt | since it's quite likely that this issue could pop up in legitimate cases too | 16:58 |
| mterry | desrt, dammit :) | 16:58 |
| desrt | mterry: if you have some time to kill, a small test case would go a long way :) | 16:59 |
| desrt | uhhhh | 17:00 |
| desrt | child_watch_helper_thread | 17:00 |
| desrt | SIGCHLD implicated in this bug? we have an open bug about a race here (that's exceptionally difficult to solve) | 17:01 |
| desrt | the bug only happens in the single-threaded case of GMainLoop but what matters is how many threads GMainLoop saw by the time the child was spawned... | 17:01 |
| * desrt tries to find that bug | 17:02 | |
| bryceh | lamalex_, there is not a public eta on the nvidia drivers, no | 17:02 |
| lamalex_ | bryceh, yah- i got the memo | 17:03 |
| lamalex_ | im really pissed at myself for just running a dist upgrade and not looking at it | 17:03 |
| bryceh | lamalex_, sorry to hear; we did try to give plenty of heads up, mentioned it in the release notes, etc. | 17:05 |
| desrt | mterry: here is the bug for reference: https://bugzilla.gnome.org/show_bug.cgi?id=398418 . not sure it's related though | 17:05 |
| ubot2 | Gnome bug 398418 in mainloop "GChildWatch race condition?" [Major,New] | 17:05 |
| lamalex_ | bryceh, yah i know it was completely my fault | 17:05 |
| lamalex_ | i have been careful about not updating, but this morning i just f'ed up | 17:05 |
| bryceh | lamalex_, for future reference, in EVERY release nvidia and fglrx ALWAYS break at some point, so if you want to track the development version just be prepared for being proprietary-driverless for about a month | 17:06 |
| bryceh | (longer in fglrx's case) | 17:06 |
| mterry | desrt, seems different, since later comments say only present if you don't link against gobject | 17:09 |
| desrt | mterry: that's because we g_thread_init() from g_object_init() these days | 17:10 |
| desrt | and a thread-safe mainloop is immune to this bug | 17:10 |
| desrt | it looks like you have two separate bugs here, though | 17:11 |
| desrt | one of them is a deadlock on a GDBusConnection lock (with no all-threads backtrace to discover the true issue) | 17:11 |
| desrt | the other two are GMainLoop deadlocks | 17:11 |
| desrt | hmm. this really really looks like heap corruption | 17:13 |
| desrt | could just as easily be dconf's fault, of course | 17:15 |
| desrt | (for corrupting the heap) | 17:15 |
| mterry | desrt, well, it's just that it goes away with a really small patch to avoid spamming dconf | 17:17 |
| desrt | mterry: there's a rather insideous bug hiding here | 17:17 |
| desrt | you've exposed it. i'm rather happy that you did. please don't hide it again :p | 17:18 |
| mterry | desrt, it's simple enough to turn off my patch in my code and test dconf in future | 17:18 |
| desrt | true. but that will never happen :) | 17:18 |
| desrt | have you tried valgrinding? | 17:19 |
| mterry | desrt, well, I can easily test patches is all I'm saying. But the combination of difficulty of creating a test case and since I worked around it... | 17:20 |
| mterry | desrt, yeah | 17:20 |
| mterry | desrt, nothing notable, except for a memory leak due to bad vala bindings :) | 17:20 |
| desrt | valgrind is particularly bad at telling you when you're trashing the heap as long as your trashing falls nicely within the bounds of existing objects :p | 17:21 |
| desrt | i guess you used always-malloc, of course... | 17:22 |
| mterry | desrt, probably not. this was a relatively simple valgrind run | 17:24 |
| desrt | ah. you should always do that :p | 17:24 |
| desrt | the slice allocator is quite good about giving out the same memory twice | 17:24 |
| mterry | desrt, when running valgrind? OK | 17:24 |
| desrt | it makes it really hard for valgrind to detect accesses to freed objects | 17:25 |
| desrt | which is the sort of thing that results in what we're seeing here | 17:25 |
| desrt | it could be a dumb refcounting bug or something | 17:25 |
| mterry | desrt, documentation likes debug-blocks even better | 17:26 |
| desrt | i don't know what one | 17:26 |
| * desrt reads up :) | 17:26 | |
| mterry | well, I guess not 'better' but 'in conjunction' | 17:27 |
| desrt | neat option. | 17:31 |
| desrt | it's quite a good one to have too | 17:31 |
| desrt | gslice is pretty quick about what it does with memory, particularly when it comes to its 'magazine' | 17:33 |
| desrt | if you tlel it "here's a 16-byte chunk of memory that i'm freeing" it will toss it in a list and give that chunk back out to the next person who asks for a 16-byte chunk of memory with no additional checking at all | 17:34 |
| desrt | so you can do some pretty funky things, as you might imagine | 17:34 |
| desrt | like donating malloc()'d or mmap()'d memory to the next g_slice_alloc() user :) | 17:35 |
| desrt | (or, as in the example that was given, memory that is from the slice allocator, but the wrong size) | 17:35 |
| chrisccoulson | pitti - did your firefox stop crashing btw? i just had a look on crash-stats, and the last submitted crash report due to the globalmenu was on 4th feb | 18:33 |
| === smspillaz is now known as smspillaz|sleepi | ||
| === smspillaz|sleepi is now known as smspillaz|asleep | ||
| didrocks | mterry: you can give me all the utouch-* stack + girr | 18:52 |
| didrocks | ginn | 18:52 |
| mterry | didrocks, hah! will do | 18:52 |
| didrocks | mterry: I've already done the work when checking for NEWing :) | 18:52 |
| didrocks | mterry: so, just a quick look again for the MIR, but all is basically done :) | 18:53 |
| mterry | didrocks, cool | 18:53 |
| didrocks | mterry: will get to it tomorrow | 18:53 |
| didrocks | now, time for dinner + some work offline! | 18:53 |
| bcurtiswx | cya didrocks | 18:53 |
| didrocks | see you bcurtiswx | 18:53 |
| RoAkSoAx | anyone might have an idea why a .desktop file is not updating the path to the icon? (this software was initially created with quickly and everything was working fine till last upload) | 19:08 |
| mterry | RoAkSoAx, you talking about natty quickly? | 19:10 |
| mterry | RoAkSoAx, it started using svg icons in the latest update, maybe that's related? | 19:11 |
| RoAkSoAx | mterry: not really natty quickly, but I uploaded new release of testdrive couple weeks ago and during the build process the icon path for the .desktop file was updated correctly. I uploaded a new testdrive earlier this week and the path has not been updated in the .desktop file. I'm building in pbuilder's today, and the path gets updated correctly | 19:12 |
| mterry | RoAkSoAx, oh, odd. so quickly didn't change... | 19:13 |
| RoAkSoAx | mterry: nope the setup.py hasn't been touched for a long time | 19:14 |
| RoAkSoAx | and quickly just updated the .quickly file version | 19:14 |
| RoAkSoAx | but that the weird thing is that the package in the archives does not update the path of the image for the .desktop file, while the ones I'm building right now in pbuilders do | 19:15 |
| RoAkSoAx | I guess I'll just have to upload a new testdrive and see if it is fixed | 19:15 |
| chrisccoulson | seb128 - are you able to accept firefox for me please? (it's sat in binary NEW atm) | 19:26 |
| seb128 | chrisccoulson, hum, how can I money that? :-) | 19:26 |
| chrisccoulson | heh :) | 19:27 |
| seb128 | chrisccoulson, can do, is the new binary for main or universe? | 19:27 |
| chrisccoulson | i'll buy you a beer at UDS ;) | 19:27 |
| chrisccoulson | seb128 - for main, i would like to build icedtea-plugin against it | 19:27 |
| seb128 | chrisccoulson, done | 19:29 |
| chrisccoulson | seb128 - excellent, thanks :) | 19:29 |
| seb128 | chrisccoulson, yw | 19:30 |
| === tkamppeter_ is now known as tkamppeter | ||
| jcastro | mterry: so the eclipse menu was too scary? | 21:27 |
| mterry | jcastro, yeah ;) | 21:27 |
| mterry | jcastro, I'll revisit it if no one else does | 21:28 |
| dobey | rodrigo_: around? | 21:28 |
| jcastro | mterry: on the plus side hopefully you're not permanently damaged from the experience, heh | 21:29 |
| * mterry hopes | 21:29 | |
| seb128 | robert_ancell, hey | 22:26 |
| robert_ancell | seb128, hello | 22:26 |
| seb128 | robert_ancell, how are you? | 22:27 |
| robert_ancell | good | 22:27 |
| seb128 | robert_ancell, great ;-) | 22:27 |
| seb128 | robert_ancell, can you make sure that the versions update you do keep a clean stdout? | 22:27 |
| seb128 | robert_ancell, otherwise the cron job sends an email with the log every time it runs | 22:28 |
| robert_ancell | it does, doesn't it? | 22:28 |
| robert_ancell | oh, so that's why you did that | 22:28 |
| seb128 | no, it sends email about build records | 22:28 |
| robert_ancell | did I leave some debugging in? | 22:28 |
| seb128 | seems you added that yesterday in your commit | 22:28 |
| robert_ancell | Should we just change that to 1>/dev/null? | 22:28 |
| robert_ancell | It's only stderr we really care about | 22:29 |
| seb128 | " print ' failed to build on on %s' % record.arch_tag" | 22:29 |
| seb128 | I think is the issue | 22:29 |
| seb128 | robert_ancell, we could as well, or just redirect stdout to a log file or something | 22:29 |
| robert_ancell | I think that would be better. The log output is useful | 22:29 |
| seb128 | k, I will rework that what I've so time to write a log on put it online in the same directory | 22:30 |
| seb128 | so maybe just drop that print for now to stop the email spam until then | 22:30 |
| seb128 | I will also do some cleaning tomorrow I think in the list | 22:31 |
| robert_ancell | clean what? | 22:31 |
| robert_ancell | I'll fix up the print now | 22:31 |
| seb128 | robert_ancell, there is a bunch of lines which have no upstream versions, wrong url | 22:32 |
| seb128 | robert_ancell, there is also some sources where we should track a stable serie | 22:33 |
| seb128 | like glom | 22:33 |
| seb128 | I've been reviewing some todays and taking some notes, will update the .py tomorrow | 22:33 |
| seb128 | we should perhaps drop some sources from the list as well, i.e plymouth | 22:34 |
| seb128 | things which are from the foundation team and we will not update | 22:34 |
| robert_ancell | just blacklist them so they only show on the extended view | 22:35 |
| seb128 | could do that | 22:35 |
| seb128 | well I just reviewed it, there is only plymouth being annoying | 22:36 |
| seb128 | robert_ancell, btw I didn't sync farsight2, there is an ubuntu diff for it | 22:37 |
| seb128 | changing the gst depends to good since we moving the farsight code there | 22:37 |
| robert_ancell | oh, I was supposed to take that one off the list, thanks | 22:37 |
| seb128 | TheMuso, why is the espeak version 1.44.05~really-1.44.04-0ubuntu1? | 22:44 |
| seb128 | or, you repacked it, weird version | 22:45 |
| seb128 | rather than using current-repacked or something | 22:45 |
| === bjf is now known as bjf[afk] | ||
| chrisccoulson | m'eh, just got the invisible window bug again | 22:50 |
| chrisccoulson | i thought didrocks said that was fixed ;) | 22:51 |
| seb128 | chrisccoulson, it's not but they go a way to trigger it reliably now and know what's going on | 22:51 |
| seb128 | sam said he would fix it tomorrow | 22:51 |
| chrisccoulson | seb128 - oh, that's good :) | 22:51 |
| seb128 | you can hide and show the desktop to workaround it | 22:51 |
| seb128 | ctrl-alt-d | 22:51 |
| seb128 | robert_ancell, btw do you see any compelant reason to try to get cairo 1.11? | 22:52 |
| seb128 | or should we just stay on 1.10? I don't really trust their schedules | 22:52 |
| robert_ancell | not that I know of. I'd like to have the latest because that makes support easier post-release | 22:52 |
| robert_ancell | how late do you think we can wait? | 22:53 |
| TheMuso | seb128: I had a weird problem when I uploaded it, I detailed the problem in teh changelog. | 22:53 |
| TheMuso | I hope to merge the latest Debian revision before FF, so hopefully that problem won't show itself again. | 22:53 |
| TheMuso | It had something to do with the binary files in the tarball, can't remember exactly without checking the changelog myself. | 22:54 |
| seb128 | TheMuso, ok, yeah the changelog explain it, it's just the version you picked which is confusing | 22:56 |
| seb128 | TheMuso, rather than doing version-repacked you did next-version... | 22:57 |
| seb128 | robert_ancell, well, we should decide around feature freeze I guess | 22:57 |
| robert_ancell | seb128, interesting, why doesn't cairo show up on versions by default? | 22:58 |
| seb128 | robert_ancell, I will check with upstream if they are a fixed schedule, but seems they started recently to roll 1.11 tarballs so I'm not really confident it will turn stable this cycle | 22:58 |
| seb128 | they got over one cycle delay for 1.10 | 22:58 |
| seb128 | robert_ancell, it does but on the non default list...not sure why | 22:59 |
| seb128 | do, launchpad off in 2 minutes it says | 22:59 |
| seb128 | it's not in the germinate desktop list | 23:00 |
| seb128 | it's in the standard one | 23:01 |
| seb128 | ok, enough irc for today here, see you tomorrow | 23:04 |
| bcurtiswx | aww darn, bzr just went down... | 23:09 |
| bcurtiswx | sorry | 23:10 |
| bcurtiswx | LP went down for the bzr get etc.. | 23:10 |
| micahg | bcurtiswx: should be about 90 minutes | 23:12 |
| bcurtiswx | micahg, yup plenty of time for me to go take care of dinner and clean it up. lol | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!