[00:24] slangasek, i got the error! [00:24] it's "illegal instruction" ^_^ [00:24] oh? [00:24] reproduced in what context? === jjohansen is now known as jjohansen[afk] [00:25] slangasek, building 2.6.3-2 on the debian armel porterbox [00:25] http://retro.apebox.org/log.txt [00:25] ok === dendro-afk is now known as dendrobates [00:26] that may be a Debian-specific failure, then, since the target instruction set on Ubuntu armel is different [00:26] (the error is misleading - it says the monolite (bootstrap compiler) install it out of date, as a result of the illegal instruction) [00:27] * ogra would suggest doing a testbuild in an armel PPA of that same package [00:27] slangasek, it's debian-specific in that it happens on debian - but it doesn't happen with the upstream 2.6.3 tarball, only once the diff is applied. so it's a regression introduced by the ubuntu patches. plus i can't verify whether it works on ubuntu, since i have no access to ubuntu porter resources [00:27] * slangasek nods [00:28] ogra, i don't have access to an armel ppa, but feel free to copy in the source package from https://launchpad.net/~directhex/+archive/monoxide?field.series_filter=maverick [00:29] directhex, i'm sadl very busy with other stuff, but i guess someone from the linaro team shoudl be able to help you with a ppa upload, alternatively you need to wait until after A2 [00:29] directhex: a test build here gets past that point, failing only later building docs when it runs my box out of memory [00:30] pitti: Sure, I'll drop the changelog. The recent upload should have helped - that changelog used to be in *all* the xserver packages. [00:30] directhex: what's the CPU of the Debian armel porterbox? [00:31] slangasek, oh? that's valuable info. sounds like it's the arch detection stuff that's borked then [00:31] yeah [00:31] slangasek, looks like arm5 [00:31] directhex@agricola:~$ uname -m [00:31] armv5tel [00:31] * slangasek nods [00:31] thats arm'v'5 :) [00:32] dont forget the v ;) [00:32] what's the v? === bjf is now known as bjf[afk] [00:32] version ... arm5 points to a core while v5 points to a spec [00:32] /proc/cpuinfo says thumb, i don't know if thumb2 is something else [00:32] arm5 is significantly older than anything you can use today :) [00:33] thumb2 is the newer implementation [00:33] is it reported differently on hardware where it's available? [00:33] thumb2 is different than thumb, but I don't know that it shows differently in /proc/cpuinfo [00:33] apparently not [00:33] it does [00:33] ogra: how is it different? [00:34] ls [00:34] *sad face* [00:34] i've looked at this code lately more than i'd like, i know mono parses /proc/cpuinfo to detect cpu abilities, including thumb... but i don't think the ubuntu patch accounts for thumb versus thumb2 [00:34] ogra@babbage2:~$ cat /proc/cpuinfo |grep Features [00:34] Features : swp half thumb fastmult vfp edsp thumbee vfpv3 [00:35] hmm, no, i lied [00:35] i thought it was exposed [00:35] what's 'thumbee'? [00:35] embedded thumb iirc [00:35] not relevant here [00:36] it'll take me another age to test the theory, but i guess http://git.debian.org/?p=pkg-mono/packages/mono.git;a=commitdiff;h=c8243c343373c8bfbf10f037eb6ac8a5e1649db3 is the problem commit [00:36] the thumb2 instructions are definately available in all v7 cpus so a check against armv7 should suffice to enable thumb2 [00:37] * slangasek nods [00:38] * ogra assumes you read https://wiki.ubuntu.com/ARM/Thumb2 [00:38] directhex: does /proc/cpuinfo show 'swp' there? [00:38] slangasek, yes [00:38] Features : swp half thumb fastmult edsp [00:38] oh, that's in the existing code anyway [00:38] and also https://wiki.ubuntu.com/ARM/Thumb2PortingHowto [00:40] i'm in the wrong timezone to work on this stuff, i think -_- [00:40] directhex: I'd be surprised if that commit causded it, the GCC builtins shouldn't be outputting non-armv5 code on Debian [00:40] -d [00:40] slangasek, i'll have to try with that branch reverted, then. there are only three ubuntu arm patches, that one looked most suspicious [00:42] i think that one was supposed to fix the thumb porting issues [00:42] and i assume it comes from asac [00:42] yes [00:43] oh, that commit also includes the changes to tramp-arm.c [00:43] i really doubt http://git.debian.org/?p=pkg-mono/packages/mono.git;a=commitdiff;h=b0c83ce0cf237768475d0c683f192ce2b3941af0 is the bad one [00:43] that's a more likely culprit than the GCC builtins [00:44] directhex: don't suppose you have a disassembly of the illegal insn? [00:45] slangasek, let me try something... [00:48] your first commit is definatley to fix the use of the swp asm instructions in the code [00:48] your second commit just enables vfp [00:49] i'm pretty usre neither will break the code with the right compiler settings [00:49] *sure [00:51] directhex, i would try to buiuld with -marm that should disable thumb and should use the old code path [00:51] and find out what fpu settings debian arm code should use and set that explicitly [00:52] that way you should exclude both patches [00:53] the Debian package passes --with-fpu=NONE [00:53] so that already disables the second commit that was pasted here [00:54] -marm should switch off all thumb usage [00:54] would you believe i just lost access to the debian arm porterbox, at the very moment where i worked out how to get mono to give me the asm instructions it wants to use? [00:54] and use the former code path that was patched in the first commit [00:54] ssh: connect to host agricola.debian.org port 22: Network is unreachable [00:54] i think $DEITY is telling me to go to bed [00:54] * slangasek is logged in still [00:54] aha, just came back === dendrobates is now known as dendro-afk [01:02] Program received signal SIGILL, Illegal instruction. [01:02] 0x406b50c0 in ?? () [01:02] sigh, that's not very helpful [01:02] i'm going to bed, i should have gone to bed an hour ago [01:03] tomorrow i can bug the debian arm guys to verify which cpu i'm supposed to be building for precisely [01:04] directhex, did you look at the wikipages i posted above ? [01:04] the second one has a nice table [01:06] ogra: find-live-filesystem lack of special-casing - um, what's this bit then? [01:06] case $ARCH in [01:06] *+*) [01:06] LIVEPROJECT="$LIVEPROJECT-$SUBARCH" [01:06] ;; [01:06] esac [01:06] directhex: armv4t is the minimum CPU supported in Debian: http://wiki.debian.org/ArmEabiPort#ChoiceofminimumCPU [01:06] argh, that's only in the public branch, not in the deployment branch! [01:06] cjwatson, heh, thats why i didnt find it [01:08] ogra: it's in a different place now, but it should still work [01:08] echo "$LIVECD/$DIST/$LIVEPROJECT${SUBARCH:+-$SUBARCH}/current/livecd.$LIVEPROJECT.$ITEM" [01:08] ah, wait, there's no subarch in the basename now [01:08] right [01:08] thats been my prob [01:08] ogra: r1079 in the deployment branch [01:09] message: [01:09] drop the dupliacte reference to in the url, to match current filenames [01:09] on the livefs buildds [01:09] livecd.$LIVEPROJECT${SUBARCH:+-$SUBARCH}.$ITEM is what livecd.sh produces [01:10] cjwatson, the paths are correct, i have issues with the filenames [01:11] and more so with the sudden change in livecd.sh behavior than with cdimage or debian-cd [01:11] since i cant explain why it started doing that [01:12] well, go back to say gutsy, find the relevant code, and then bisect [01:12] well, i added a workaround for now to suppress mangling of $PROJECT with teh subarch under armel [01:13] the thing is that it didnt behave like that in lucid ... sadly we didnt build images in maverick until now so i cant exactly pinpoint when it changed behavior [01:13] no need to go back that far [01:14] er, I think that change came from NCommander [01:14] he didnt touch anything that could have caused this [01:14] * ogra spent his whole evening looking through that [01:14] ogra: oh, I understand [01:15] wait, do I [01:16] slangasek, FSS="$FS${SUBARCH:+-$SUBARCH}" is the offending code ... and that was added when we started to support powerpc-ps3 [01:16] but that isn't offending [01:16] well, thats what mangles the filename [01:16] IMO, cdimage is wrong if it's failing to download subarch-aware names [01:16] but apparently it never took effect until now [01:16] unmangling it for just one architecture was a distinctly unhelpful workaround [01:16] now we have to special-case an architecture [01:17] please undo that, and let's fix it properly [01:17] hrm [01:17] i really see no point in subarch aware names in the first place with the current livecd build structure [01:18] changing it for ONE ARCHITECTURE is unhelpful [01:18] since subarches are divided by subdir on the build machine [01:18] I don't care what the result is, but it has to be consistent across architectures [01:18] well, then we should drop it for all perhaps [01:18] i didnt have the balls to do that at the dawn of an alpha [01:18] no, what we *should* do is get rid of the subarch name in the directory path [01:19] why ? [01:19] because that's gratuitously different [01:19] that will make us end up with one huge dir that contains a ton of filesystems and logs [01:19] also, I think the different filenames may actually be necessary [01:19] on the livefs builder === oubiwann is now known as oubiwann-away [01:20] livecd-rootfs builds different subarches in the same directory, on its side - they get copied off to separate places later [01:20] slangasek, take a look at acorn.buildd [01:20] ogra: you mean like we do for all the other archs except for armel and ps3 on http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ ? [01:20] yes, I'm familiar with the structure [01:20] I think that getting rid of the different basenames would introduce bugs in special cases [01:20] and I believe I agree with slangasek [01:20] tacking subarch onto the *project* name is just weird [01:21] doing that in the basename is ugly but not that intrusive; having it in the directory name is really, really odd [01:21] lool tried to remedy this once before, but ran into timing constraints; I'm not saying we should make this change before a2 either, just that it's where we should end up [01:21] in future, though, please do not introduce architecture-specific naming structures [01:21] that will surely require a ton of changes in different places [01:22] ogra: I will take care of it [01:22] ok [01:22] different places: two, possibly three [01:22] mainly find-live-filesystem i guess [01:23] slangasek: well, I think it was put in the directory because each subarch is built independently, and so needs separate datestamps [01:23] cjwatson, i didnt introduce anything, i reverted to old behavior [01:23] livecd-rootfs (1.128) maverick; urgency=low [01:23] * do not mangle the project name by attaching the subarch to it on armel, [01:23] i agree with a bad hack [01:23] this results in livefs names that confuse find-live_filesystem [01:23] -- Oliver Grawert Tue, 29 Jun 2010 23:04:10 +0200 [01:23] + case $TARGETARCH in [01:23] + armel) [01:23] cjwatson: that's already the case for ports vs. main, which nevertheless share a directory tree :) [01:23] slangasek: that's true [01:24] ogra: now either armel+* is broken, or powerpc+ps3 [01:24] cjwatson, right, as i said, i agree it was a hack, but target was to get back the behavior i has through the last 4 releases [01:24] but don't say you didn't introduce something when you did [01:24] that's really annoying [01:25] I will see if it's fixable tomorrow before starting CD builds [01:25] i only tried to make livecd.sh behave as it did three months ago [01:26] since *something* changed it's behavior and i still dont know what that was [01:26] I don't object to fixing things for alphas by way of hacks; I've done that often enough myself. My point, which I've made but which I seem not to be making effectively, is that those hacks need to not be architecture-specific like this. [01:26] there is no way that the architecture-specific-ness of this hack could have helped [01:26] i agree, it was kind of a last resort thing [01:26] cjwatson: do you want me to have a poke at this this evening? [01:27] slangasek: if you like; I have to wait for ubiquity in the morning anyway [01:27] well, one less thing for you to worry about in the morning [01:27] cjwatson, i muchly would have preferred to find out *why* it changed at all [01:28] what worries me is that we will build up a pile of these architecture-specific hacks, and then the logic to deal with them on the cdimage side will become completely incomprehensible instead of mostly incomprehensible. [01:28] but either i'm blind or dumb, i cant see a code change that causes that change in behavior [01:28] i wouldnt have done an arch specific hack at all if i could have found the root cause [01:32] ogra: yeah, I don't see the change either. :/ [01:37] nor I, but I also don't see why it was failing to include the subarch in the first place and so as I say I consider the new behaviour better [01:37] I wonder if there was a stale version of BuildLiveCD in use [01:37] it definatley used the subarch var during builds [01:37] the armel kernel selection fully depends on it [01:39] cjwatson, you mean it mangled the naming post build for armel ? [01:40] I don't know [01:41] thats a possibility i didnt take into account [01:42] I don't think that's what I said though [01:42] I wasn't that specific :) [01:42] no but its a possibility [01:44] does BuildLiveCD also get updated on every build? [01:44] nope [01:44] ok [01:44] lamont wanted to have some control over it [01:46] argh [01:46] * ogra_cmpc reverts his change completely [01:47] ogra_cmpc: I already did so and am about to upload... ? [01:47] oh, ok [01:47] and then will get cdimage sorted [01:48] i just started a testbuild and noticed that TARGETARCH is undefined at the point where i introduced the change :( [01:48] so it wouldnt have worked anyway [01:48] Speaking of cdimages - would anyone like to sponsor an xorg-server upload to shave ~1MB off xserver-common by dropping the upstream changelog as per pitti's request? [01:49] RAOF: fire me a source package [01:49] or a branch [01:49] cooperteam.net/Packages/xorg-server_1.8.1.902-0ubuntu2_source.changes [01:50] can't connect [01:50] me neither. [01:50] Failing that, debcheckout xorg-server and grab the ubuntu branch. [01:50] HEAD says 500 Can't connect to cooperteam.net:80 (connect: Connection refused) [01:51] * ogra_cmpc wonders if we couldnt drop OO.o in favour of zoho-weboffice at some point and win 100MB [01:51] * RAOF is IRCing from cooperteam.net, so I wonder what's wrong. [01:51] debcheckout will take a while [01:51] Weboffice = accessibility pain, at least for me. [01:52] TheMuso, ah, thats a valid point [01:52] * TheMuso is somewhat opposed to a lot of things that are done on the web, that could just as easily be done in client apps running on the desktop. [01:53] I.e, IMO the web is not the be all and end all. [01:53] RAOF: dump it on people.c.c for me? [01:53] we're using it on armel quite successfully but i dont think anyone focused on a11y === neumann is now known as Lrrr [01:53] ogra_cmpc: Considering lots of those devices are touch screen based anyway, a11y is going to need a lot more work than just web office etc. [01:54] TheMuso, surely not but there are usecases where it makes sense to put the load on an extrenal server [01:54] ogra_cmpc: I agree to a point. [01:54] TheMuso, well, there are these arm netbooks that will *come soon* [01:54] they wont be touch based [01:54] ogra_cmpc: Ah ok, interesting. [01:55] though they come "soon" since two years [01:55] :) [01:55] ogra_cmpc: heh [01:56] In terms of touchscreen based accessibility, currently Apple is the only one who has it done right [01:56] cjwatson: http://cooperteam.net/Packages/xorg-server_1.8.1.902-0ubuntu2_source.changes should work now. [01:56] we'll get there [01:56] currently ubuntu isnt great on touchscreens anyway, it can only get better [01:59] RAOF: uploaded, thanks [01:59] ogra_cmpc: ah ok === awolfson is now known as awolfson_afk [05:29] Hi - is there any way that you can track an RSS feed for PPA builds? [05:30] Meep: #launchpad would be a more appropriate place to ask [05:32] Thanks [05:47] cjwatson: We've now got our first member of kubuntu-dev who wasn't MOTU first, which caused me to notice that kubuntu-dev isn't a member of ubuntu-dev. I assume this is just an oversight ... [05:48] cjwatson: Nevermind. It's there, I just can't read late at night. [05:50] wow.. buildd's on launchpad seem crazy busy... 21+ hours [06:46] Good morning [06:47] RAOF: right, I saw the Debian changelog for that; but it's another easy MB :) [06:47] RAOF: thanks! [06:57] good morning [07:07] * pitti hugs dholbach [07:07] * dholbach hugs pitti back :) [07:07] how's life? [07:08] pretty good! yay summer [07:08] yeah :-) [07:08] finally [07:20] ccheney: is that oo.o armel segfault something new? [07:20] ogra_cmpc: is the OO.o armel failure blocking armel alpha-2 images, or did we unseed it there? [07:21] ccheney: (the segfault during build, I mean) [07:55] apachelogger: can you please update https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep? [07:56] Riddell: ^ or maybe you can write something for apachelogger? I have no clue what widgetcraft is [07:56] and I want to announced UDW today [07:59] !regression-alert [07:59] cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive [08:00] yesterday's firefox update fails if firefox-2 is installed, see bug 600022 [08:00] Launchpad bug 600022 in firefox-3.0 (Ubuntu Hardy) "package firefox 3.0.19 nobinonly-0ubuntu0.8.04.1 failed to install/upgrade: trying to overwrite `/usr/share/bug/firefox/presubj', which is also in package firefox-2" [High,In progress] https://launchpad.net/bugs/600022 [08:00] and due to the newly split out -branding package, it doesn't fail gracefully enough, firefox-3 is rather broken after apt fails over [08:06] firefox (3, the default) not firefox-3 [08:13] ok, so discussion in #u-desktop confirms the "high" importance, not "critical"; affected people have firefox-2 as a temporary fallback, and only few people have that installed in the first place [08:13] and we can push out a fix in some two hours [08:23] pitti: agreed [09:07] dholbach: described [09:08] thanks apachelogger [09:26] http://ubuntu.dupondje.be/opal.debdiff => does this look ok, would like to get it merged asap, to get newer Ekiga into Maverick :) [09:37] dupondje: do you have an idea where from that non-Ubuntu changelog entries come from? [09:39] dupondje: minor note: we use "Ubuntu Developers " as maintainer now for main and universe [09:42] dupondje: and libcelt-dev and libpt-dev are in universe [09:46] dupondje: forget the last comment; I just saw that that opal is in universe too, so the other build-dependecies from universe are not a problem and opal could even by synced instead of merged [09:47] https://launchpad.net/ubuntu/+source/opal [09:47] here it says main ? :p [09:48] not for Maverick [09:48] dupondje: don't look at the "Component" as it set from the last upload but look at the table below. At the point of upload opal was in main but got demoted (moved to universe) later [09:49] ah I see :) didn't notice [09:49] could you sync it ? [09:54] pitti, we should maybe move the sdl discussion there [09:54] pitti, I don't know about libsdl1.2debian-udeb [09:55] but maybe cjwatson can reply to whether it's required or not nowadays [09:56] cjwatson, we were discussing stopping building libsdl with directfb since that's the only thing in maverick bringing directfb on the CD [09:56] we don't need anything to do with directfb in udebs any more [09:56] nice [09:56] looking at that then [09:56] libsdl1.2debian-udeb itself is still in Debian unstable so I guess something is using it [09:57] but anything directfb-ish can go [10:01] seb128: I prepare/test that now and upload after alpha-2; for a2 we have to resort to dropping langpacks, I think [10:02] (I already dropped some, with that and yesterday's fixes we should be back in size I think) [10:04] pitti, ok [10:07] klingon can probably go [10:07] and latin [10:08] * lifeless is teasing and knows they aren't on the CD already [10:08] unfortunately we had to drop languages which are even more popular than Klingon [10:08] pitti: there are more popular languages? Oh Noes. [10:08] lifeless: I wonder what "core dump" menas in Latin [10:09] "means" [10:09] probably something about going to the toilet in the forest. [10:19] si haec verba legere potes, tibi nimium eruditio est [10:21] !regression-alert [10:21] cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive [10:21] bug #595265 [10:21] Launchpad bug 595265 in gwibber (Ubuntu) "Can not add Facebook account as add button not displayed after authorisation." [Critical,Triaged] https://launchpad.net/bugs/595265 [10:26] bilalakhtar: did that happen in a post-lucid upgrade? [10:26] pitti: yes [10:26] pitti: an update pushed on 2010-05-03 to maverick [10:26] oh, maverick === almaisan-away is now known as al-maisan [10:27] pitti: and 2010-05-03 on lucid [10:27] bilalakhtar: that isn't an update to lucid then, though [10:27] oh, ok [10:27] pitti: https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/gwibber/lucid-updates [10:27] revision 38 ^^ [10:27] bilalakhtar: thanks [10:28] bilalakhtar: I'll assign it to the appropriate developer and milestone it accordingly; thanks for pointing out! [10:29] pitti: you're welcome. I have always been hearing about you, having the highest karma on lp. talking to you for the first time! [10:30] "Don't allow people to click "Add" before we have enough information [10:30] from facebook to add the account" [10:30] so this is very likely a regression from that indeed [10:30] bilalakhtar: nice to get to know you :) [10:37] pitti: could you look at bug #598874 when you have time ? libmpcdec is in main and it would be great to get fixed [10:37] Launchpad bug 598874 in libmpc (Ubuntu) "Please sync libmpc 2:0.1~r459-1 (universe) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/598874 [10:38] seb128: new sdl working great here \o/ [10:40] pitti, nice! [10:44] pitti, we have weboffice by default on arm images, OOo only needs to be installable by release day [10:45] pitti, so dont worry [10:46] ogra_cmpc: ok, thanks; I dropped OO.o from armel [10:46] http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html looks quite okay now [10:46] pitti, you dropped ? [10:46] it shouldnt be pulled in at all [10:46] since lucid [10:46] ogra_cmpc: I dropped it from ubuntu-desktop [armel], yes [10:46] ogra_cmpc: perhaps you mean netbook? [10:46] oh, desktop [10:47] yeah, i dont care for desktop [10:47] nobody build it [10:47] *builds [10:48] right [10:48] we should have a working metapackage on release day that doesnt differ from x86, but .nothing to worry about atm === asac__ is now known as asac === ikonia_ is now known as ubuntu-ops [11:12] Riddell: hm, koreport is uninstallable because koffice-libs Conflicts/Replaces: it (without version); should the binary just go then? [11:13] I don't think it breaks actual images, since it's not seeded [11:14] pitti: yes that binary can go [11:14] files now in koffice-libs [11:14] can somebody shove my mail through ubuntu-devel-announce? [11:14] Riddell: oh, it's already NBS, great [11:14] dholbach: will do [11:14] thanks pitti [11:16] oh, there was more interesting stuff indeed [11:16] geser: please prod someone to moderate u-d-a stuff if you send minutes [11:21] How install file.tar.zg but learn me step by step please and thank [11:21] Iraq: not here [11:21] not your channel [11:21] leave me [11:22] jealos [11:28] ogasawara: kernel ddebs> ah, retrieval from crested (amd64 buildd) was disabled since it hanged forever last time I tried it [11:28] ogasawara: I'm retrieving the last weeks' ddebs and now convert to urllib2 to avoid those hacks in the first place [11:56] ogasawara: argh, except that python is too old on macquarie, so I can't add a timeout [11:59] ogasawara: but missing ddebs are trickling in now === al-maisan is now known as almaisan-away [12:02] jdong / cjwatson / slangasek: I know you probably have your hands full atm with A2 prep, but at some point today; do you think you could ack the SRU of Bug 566792 ; As i really want to make sure it gets through verfication prior to 10.04.1. [12:02] Launchpad bug 566792 in eucalyptus (Ubuntu Lucid) "metadata service returns empty data with 200 OK" [High,Confirmed] https://launchpad.net/bugs/566792 [12:02] I'll look [12:02] cjwatson: super, thanks! [12:03] * cjwatson has a similarly positioned SRU of his own on its way so needs the karma [12:03] in the non-LP sense [12:03] heh. [12:06] Daviey: I guess this will trickle into maverick via an upstream merge? [12:06] Daviey: accepted === almaisan-away is now known as al-maisan [12:10] cjwatson: Yeah, that is great thanks [12:12] cjwatson: I intentionally *haven't* pushed this to maverick, as the current version in maverick is a stop gap -waiting on upstream to fix there latest devel branch so we can push it into maverick. The area that has been fixed in this upload, has had a major rewrite in the upstream devel branch - and i don't want to introduce a false sense of fixedness. [12:12] Hopefully upstream will have addressed this in their latest devel branch, but i want the issue there until they drop it to us. [12:12] * cjwatson nods === oubiwann-away is now known as oubiwann === MacSlow is now known as MacSlow|lunch [13:24] smb: I'm about to release the lot of linux packages for lucid, they look ok from here; did you hear any problems? [13:26] pitti, Not to my knowledge. I haven't heard/or do remember definite feedback on the topic branch packages but I asked twice and anything happening to them is imo their own problem then [13:27] smb: if you don't fell sure about some of them I can skip them [13:27] but I'd like to push out at least the main linux and perhaps ec2 [13:28] pitti, No push them all. Even if there is anything broken there (which I do not think) it will educate :-P [13:28] ok [13:57] This might be a silly question but I've Googled and come up with nothing, how do I flush whatever is caching /usr/lib/bonobo/server/ files. [13:57] Or at least have the bonobo-activation-server reread the configuration [13:58] pitti: was the Firefox upgrade stopped on mirrors for all releases or just Hardy? [13:59] micahg: we didn't actually stop it; it was expected to land much earlier [13:59] pitti: k :) === jtechidna is now known as JontheEchidna [13:59] pitti - i've uploaded the new version to the PPA now [13:59] and since affected people have firefox-2 as a fallback, it's not the end of the world perhaps [13:59] chrisccoulson: yay you! [14:00] i'm going to plan some test cases whilst it's building to make sure all the possible upgrade paths still work [14:00] but, i must eat first :) === al-maisan is now known as almaisan-away === awolfson_afk is now known as awolfson === cyphermox_ is now known as cyphermox === MacSlow|lunch is now known as MacSlow === sconklin-gone is now known as sconklin === bjf[afk] is now known as bjf === almaisan-away is now known as al-maisan === bjf is now known as bjf[afk] === dendro-afk is now known as dendrobates === Amto_res is now known as Amto`OFF [16:22] pitti, sorry didn't notice my xchat crashed :( [16:23] pitti, i bet the armel crash is due to the removal doko requested [16:23] pitti, er code removal [16:24] * ccheney examining the crash now to see if it looks likely [16:31] pitti, armel build failed because the buildd couldn't install the depends, or the current log is that way [16:32] pitti, if it segfaulted it might be a problem i can fix but the current attempt couldn't install the depends [16:33] ccheney, dont bother i'm pretty sure we need a working openjdk first, the segfaults are during installation fo cacert's [16:33] s/fo/of/ [16:33] ogra: ok [16:34] * ccheney goes back to testing server images [16:34] doko_, will you take care of openjdk on armel or do i need to poke linaro now ? [16:39] ogra: please poke linaro, won't have time for this for a while. and linaro does have a work item to update the linaro armel bits [16:39] openjdk I mean [16:39] ok === bjf[afk] is now known as bjf [17:13] kees, hi, did you ever upstream your gdm patch to use login.defs value for getting the uid limit? [17:15] kees, it doesn't apply to the current version, I've disabled it for now, the work in progress for the next upload but if you want to have a go at updating it that would be nice === deryck is now known as deryck[lunch] === cr3_ is now known as cr3 [17:53] seb128: can't you forward port it? [17:54] seb128: dropping that patch will cause regressions for people... [17:55] kees, I could yes, they just rewrote this code to be async and the structure you used is not available now [17:55] seb128: which version of gdm are you working on? [17:55] kees, right, well right now I've no further time to spend on it so I guess I will let the gdm update sit in the vcs until somebody has time for it [17:56] kees, 2.30.4 but they did quite some refactoring in the stable serie [17:56] kees, anyway if you have some time and want to do it I would appreciate, otherwise I will see if robert_ancell can do it or delay the update to next week [17:56] seb128: where in vcs is it? [17:56] kees, debcheckout gdm? [17:57] lp:~ubuntu-desktop/gdm/ubuntu [17:57]