[00:24] <directhex> slangasek, i got the error!
[00:24] <directhex> it's "illegal instruction" ^_^
[00:24] <slangasek> oh?
[00:24] <slangasek> reproduced in what context?
[00:25] <directhex> slangasek, building 2.6.3-2 on the debian armel porterbox
[00:25] <directhex> http://retro.apebox.org/log.txt
[00:25] <slangasek> ok
[00:26] <slangasek> that may be a Debian-specific failure, then, since the target instruction set on Ubuntu armel is different
[00:26] <directhex> (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] <directhex> 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] <directhex> 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] <ogra> 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] <slangasek> directhex: a test build here gets past that point, failing only later building docs when it runs my box out of memory
[00:30] <RAOF> 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] <slangasek> directhex: what's the CPU of the Debian armel porterbox?
[00:31] <directhex> slangasek, oh? that's valuable info. sounds like it's the arch detection stuff that's borked then
[00:31] <slangasek> yeah
[00:31] <directhex> slangasek, looks like arm5
[00:31] <directhex> directhex@agricola:~$ uname -m
[00:31] <directhex> armv5tel
[00:31]  * slangasek nods
[00:31] <ogra> thats arm'v'5 :)
[00:32] <ogra> dont forget the v ;)
[00:32] <directhex> what's the v?
[00:32] <ogra> version ... arm5 points to a core while v5 points to a spec
[00:32] <directhex> /proc/cpuinfo says thumb, i don't know if thumb2 is something else
[00:32] <ogra> arm5 is significantly older than anything you can use today :)
[00:33] <ogra> thumb2 is the newer implementation
[00:33] <directhex> is it reported differently on hardware where it's available?
[00:33] <slangasek> thumb2 is different than thumb, but I don't know that it shows differently in /proc/cpuinfo
[00:33] <slangasek> apparently not
[00:33] <ogra> it does
[00:33] <slangasek> ogra: how is it different?
[00:34] <RAOF> ls
[00:34] <RAOF> *sad face*
[00:34] <directhex> 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> ogra@babbage2:~$ cat /proc/cpuinfo |grep Features
[00:34] <ogra> Features	: swp half thumb fastmult vfp edsp thumbee vfpv3
[00:35] <ogra> hmm, no, i lied
[00:35] <ogra> i thought it was exposed
[00:35] <slangasek> what's 'thumbee'?
[00:35] <ogra> embedded thumb iirc
[00:35] <ogra> not relevant here
[00:36] <directhex> 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] <ogra> 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] <slangasek> directhex: does /proc/cpuinfo show 'swp' there?
[00:38] <directhex> slangasek, yes
[00:38] <directhex> Features        : swp half thumb fastmult edsp
[00:38] <slangasek> oh, that's in the existing code anyway
[00:38] <ogra> and also https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
[00:40] <directhex> i'm in the wrong timezone to work on this stuff, i think -_-
[00:40] <slangasek> directhex: I'd be surprised if that commit causded it, the GCC builtins shouldn't be outputting non-armv5 code on Debian
[00:40] <slangasek> -d
[00:40] <directhex> 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] <ogra> i think that one was supposed to fix the thumb porting issues
[00:42] <ogra> and i assume it comes from asac
[00:42] <directhex> yes
[00:43] <slangasek> oh, that commit also includes the changes to tramp-arm.c
[00:43] <directhex> i really doubt http://git.debian.org/?p=pkg-mono/packages/mono.git;a=commitdiff;h=b0c83ce0cf237768475d0c683f192ce2b3941af0 is the bad one
[00:43] <slangasek> that's a more likely culprit than the GCC builtins
[00:44] <slangasek> directhex: don't suppose you have a disassembly of the illegal insn?
[00:45] <directhex> slangasek, let me try something...
[00:48] <ogra> your first commit is definatley to fix the use of the swp asm instructions in the code
[00:48] <ogra> your second commit just enables vfp
[00:49] <ogra> i'm pretty usre neither will break the code with the right compiler settings
[00:49] <ogra> *sure
[00:51] <ogra> directhex, i would try to buiuld with -marm that should disable thumb and should use the old code path
[00:51] <ogra> and find out what fpu settings debian arm code should use and set that explicitly
[00:52] <ogra> that way you should exclude both patches
[00:53] <slangasek> the Debian package passes --with-fpu=NONE
[00:53] <ogra> so that already disables the second commit that was pasted here
[00:54] <ogra> -marm should switch off all thumb usage
[00:54] <directhex> 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] <ogra> and use the former code path that was patched in the first commit
[00:54] <directhex> ssh: connect to host agricola.debian.org port 22: Network is unreachable
[00:54] <directhex> i think $DEITY is telling me to go to bed
[00:54]  * slangasek is logged in still
[00:54] <directhex> aha, just came back
[01:02] <directhex> Program received signal SIGILL, Illegal instruction.
[01:02] <directhex> 0x406b50c0 in ?? ()
[01:02] <directhex> sigh, that's not very helpful
[01:02] <directhex> i'm going to bed, i should have gone to bed an hour ago
[01:03] <directhex> tomorrow i can bug the debian arm guys to verify which cpu i'm supposed to be building for precisely
[01:04] <ogra> directhex, did you look at the wikipages i posted above ?
[01:04] <ogra> the second one has a nice table
[01:06] <cjwatson> ogra: find-live-filesystem lack of special-casing - um, what's this bit then?
[01:06] <cjwatson> case $ARCH in
[01:06] <cjwatson>         *+*)
[01:06] <cjwatson>                 LIVEPROJECT="$LIVEPROJECT-$SUBARCH"
[01:06] <cjwatson>                 ;;
[01:06] <cjwatson> esac
[01:06] <slangasek> directhex: armv4t is the minimum CPU supported in Debian: http://wiki.debian.org/ArmEabiPort#ChoiceofminimumCPU
[01:06] <cjwatson> argh, that's only in the public branch, not in the deployment branch!
[01:06] <ogra> cjwatson, heh, thats why i didnt find it
[01:08] <cjwatson> ogra: it's in a different place now, but it should still work
[01:08] <cjwatson>                                 echo "$LIVECD/$DIST/$LIVEPROJECT${SUBARCH:+-$SUBARCH}/current/livecd.$LIVEPROJECT.$ITEM"
[01:08] <cjwatson> ah, wait, there's no subarch in the basename now
[01:08] <ogra> right
[01:08] <ogra> thats been my prob
[01:08] <cjwatson> ogra: r1079 in the deployment branch
[01:09] <cjwatson> message:
[01:09] <cjwatson>   drop the dupliacte reference to  in the url, to match current filenames
[01:09] <cjwatson>   on the livefs buildds
[01:09] <ogra> livecd.$LIVEPROJECT${SUBARCH:+-$SUBARCH}.$ITEM is what livecd.sh produces
[01:10] <ogra> cjwatson, the paths are correct, i have issues with the filenames
[01:11] <ogra> and more so with the sudden change in livecd.sh behavior than with cdimage or debian-cd
[01:11] <ogra> since i cant explain why it started doing that
[01:12] <cjwatson> well, go back to say gutsy, find the relevant code, and then bisect
[01:12] <ogra> well, i added a workaround for now to suppress mangling of $PROJECT with teh subarch under armel
[01:13] <ogra> 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] <ogra> no need to go back that far
[01:14] <slangasek> er, I think that change came from NCommander
[01:14] <ogra> he didnt touch anything that could have caused this
[01:14]  * ogra spent his whole evening looking through that
[01:14] <cjwatson> ogra: oh, I understand
[01:15] <cjwatson> wait, do I
[01:16] <ogra> slangasek, FSS="$FS${SUBARCH:+-$SUBARCH}" is the offending code ... and that was added when we started to support powerpc-ps3
[01:16] <cjwatson> but that isn't offending
[01:16] <ogra> well, thats what mangles the filename
[01:16] <cjwatson> IMO, cdimage is wrong if it's failing to download subarch-aware names
[01:16] <ogra> but apparently it never took effect until now
[01:16] <cjwatson> unmangling it for just one architecture was a distinctly unhelpful workaround
[01:16] <cjwatson> now we have to special-case an architecture
[01:17] <cjwatson> please undo that, and let's fix it properly
[01:17] <ogra> hrm
[01:17] <ogra> i really see no point in subarch aware names in the first place with the current livecd build structure
[01:18] <cjwatson> changing it for ONE ARCHITECTURE is unhelpful
[01:18] <ogra> since subarches are divided by subdir on the build machine
[01:18] <cjwatson> I don't care what the result is, but it has to be consistent across architectures
[01:18] <ogra> well, then we should drop it for all perhaps
[01:18] <ogra> i didnt have the balls to do that at the dawn of an alpha
[01:18] <slangasek> no, what we *should* do is get rid of the subarch name in the directory path
[01:19] <ogra> why ?
[01:19] <slangasek> because that's gratuitously different
[01:19] <ogra> that will make us end up with one huge dir that contains a ton of filesystems and logs
[01:19] <cjwatson> also, I think the different filenames may actually be necessary
[01:19] <ogra> on the livefs builder
[01:20] <cjwatson> livecd-rootfs builds different subarches in the same directory, on its side - they get copied off to separate places later
[01:20] <ogra> slangasek, take a look at acorn.buildd
[01:20] <slangasek> 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] <slangasek> yes, I'm familiar with the structure
[01:20] <cjwatson> I think that getting rid of the different basenames would introduce bugs in special cases
[01:20] <cjwatson> and I believe I agree with slangasek
[01:20] <cjwatson> tacking subarch onto the *project* name is just weird
[01:21] <cjwatson> doing that in the basename is ugly but not that intrusive; having it in the directory name is really, really odd
[01:21] <slangasek> 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] <cjwatson> in future, though, please do not introduce architecture-specific naming structures
[01:21] <ogra> that will surely require a ton of changes in different places
[01:22] <cjwatson> ogra: I will take care of it
[01:22] <ogra> ok
[01:22] <cjwatson> different places: two, possibly three
[01:22] <ogra> mainly find-live-filesystem i guess
[01:23] <cjwatson> slangasek: well, I think it was put in the directory because each subarch is built independently, and so needs separate datestamps
[01:23] <ogra> cjwatson, i didnt introduce anything, i reverted to old behavior
[01:23] <cjwatson> livecd-rootfs (1.128) maverick; urgency=low
[01:23] <cjwatson>   * do not mangle the project name by attaching the subarch to it on armel,
[01:23] <ogra> i agree with a bad hack
[01:23] <cjwatson>     this results in livefs names that confuse find-live_filesystem
[01:23] <cjwatson>  -- Oliver Grawert <ogra@ubuntu.com>  Tue, 29 Jun 2010 23:04:10 +0200
[01:23] <cjwatson> +    case $TARGETARCH in
[01:23] <cjwatson> +        armel)
[01:23] <slangasek> cjwatson: that's already the case for ports vs. main, which nevertheless share a directory tree :)
[01:23] <cjwatson> slangasek: that's true
[01:24] <cjwatson> ogra: now either armel+* is broken, or powerpc+ps3
[01:24] <ogra> 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] <cjwatson> but don't say you didn't introduce something when you did
[01:24] <cjwatson> that's really annoying
[01:25] <cjwatson> I will see if it's fixable tomorrow before starting CD builds
[01:25] <ogra> i only tried to make livecd.sh behave as it did three months ago
[01:26] <ogra> since *something* changed it's behavior and i still dont know what that was
[01:26] <cjwatson> 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] <cjwatson> there is no way that the architecture-specific-ness of this hack could have helped
[01:26] <ogra> i agree, it was kind of a last resort thing
[01:26] <slangasek> cjwatson: do you want me to have a poke at this this evening?
[01:27] <cjwatson> slangasek: if you like; I have to wait for ubiquity in the morning anyway
[01:27] <slangasek> well, one less thing for you to worry about in the morning
[01:27] <ogra> cjwatson, i muchly would have preferred to find out *why* it changed at all
[01:28] <cjwatson> 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] <ogra> but either i'm blind or dumb, i cant see a code change that causes that change in behavior
[01:28] <ogra> i wouldnt have done an arch specific hack at all if i could have found the root cause
[01:32] <slangasek> ogra: yeah, I don't see the change either. :/
[01:37] <cjwatson> 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] <cjwatson> I wonder if there was a stale version of BuildLiveCD in use
[01:37] <ogra_cmpc> it definatley used the subarch var during builds
[01:37] <ogra_cmpc> the armel kernel selection fully depends on it
[01:39] <ogra_cmpc> cjwatson, you mean it mangled the naming post build for armel ?
[01:40] <cjwatson> I don't know
[01:41] <ogra_cmpc> thats a possibility i didnt take into account
[01:42] <cjwatson> I don't think that's what I said though
[01:42] <cjwatson> I wasn't that specific :)
[01:42] <ogra_cmpc> no but its a possibility
[01:44] <slangasek> does BuildLiveCD also get updated on every build?
[01:44] <ogra_cmpc> nope
[01:44] <slangasek> ok
[01:44] <ogra_cmpc> lamont wanted to have some control over it
[01:46] <ogra_cmpc> argh
[01:46]  * ogra_cmpc reverts his change completely 
[01:47] <slangasek> ogra_cmpc: I already did so and am about to upload... ?
[01:47] <ogra_cmpc> oh, ok
[01:47] <slangasek> and then will get cdimage sorted
[01:48] <ogra_cmpc> i just started a testbuild and noticed that TARGETARCH is undefined at the point where i introduced the change :(
[01:48] <ogra_cmpc> so it wouldnt have worked anyway
[01:48] <RAOF> 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] <cjwatson> RAOF: fire me a source package
[01:49] <cjwatson> or a branch
[01:49] <RAOF> cooperteam.net/Packages/xorg-server_1.8.1.902-0ubuntu2_source.changes
[01:50] <cjwatson> can't connect
[01:50] <TheMuso> me neither.
[01:50] <RAOF> Failing that, debcheckout xorg-server and grab the ubuntu branch.
[01:50] <cjwatson> 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] <cjwatson> debcheckout will take a while
[01:51] <TheMuso> Weboffice = accessibility pain, at least for me.
[01:52] <ogra_cmpc> 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] <TheMuso> I.e, IMO the web is not the be all and end all.
[01:53] <cjwatson> RAOF: dump it on people.c.c for me?
[01:53] <ogra_cmpc> we're using it on armel quite successfully but i dont think anyone focused on a11y
[01:53] <TheMuso> 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] <ogra_cmpc> TheMuso, surely not but there are usecases where it makes sense to put the load on an extrenal server
[01:54] <TheMuso> ogra_cmpc: I agree to a point.
[01:54] <ogra_cmpc> TheMuso, well, there are these arm netbooks that will *come soon*
[01:54] <ogra_cmpc> they wont be touch based
[01:54] <TheMuso> ogra_cmpc: Ah ok, interesting.
[01:55] <ogra_cmpc> though they come "soon" since two years
[01:55] <ogra_cmpc> :)
[01:55] <TheMuso> ogra_cmpc: heh
[01:56] <TheMuso> In terms of touchscreen based accessibility, currently Apple is the only one who has it done right
[01:56] <RAOF> cjwatson: http://cooperteam.net/Packages/xorg-server_1.8.1.902-0ubuntu2_source.changes should work now.
[01:56] <ogra_cmpc> we'll get there
[01:56] <ogra_cmpc> currently ubuntu isnt great on touchscreens anyway, it can only get better
[01:59] <cjwatson> RAOF: uploaded, thanks
[01:59] <TheMuso> ogra_cmpc: ah ok
[05:29] <Meep> Hi - is there any way that you can track an RSS feed for PPA builds?
[05:30] <micahg> Meep: #launchpad would be a more appropriate place to ask
[05:32] <Meep> Thanks
[05:47] <ScottK> 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] <ScottK> cjwatson: Nevermind.  It's there, I just can't read late at night.
[05:50] <SpamapS> wow.. buildd's on launchpad seem crazy busy... 21+ hours
[06:46] <pitti> Good morning
[06:47] <pitti> RAOF: right, I saw the Debian changelog for that; but it's another easy MB :)
[06:47] <pitti> RAOF: thanks!
[06:57] <dholbach> good morning
[07:07]  * pitti hugs dholbach
[07:07]  * dholbach hugs pitti back :)
[07:07] <dholbach> how's life?
[07:08] <pitti> pretty good! yay summer
[07:08] <dholbach> yeah :-)
[07:08] <dholbach> finally
[07:20] <pitti> ccheney: is that oo.o armel segfault something new?
[07:20] <pitti> ogra_cmpc: is the OO.o armel failure blocking armel alpha-2 images, or did we unseed it there?
[07:21] <pitti> ccheney: (the segfault during build, I mean)
[07:55] <dholbach> apachelogger: can you please update https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep?
[07:56] <dholbach> Riddell: ^ or maybe you can write something for apachelogger? I have no clue what widgetcraft is
[07:56] <dholbach> and I want to announced UDW today
[07:59] <pitti> !regression-alert
[08:00] <pitti> yesterday's firefox update fails if firefox-2 is installed, see bug 600022
[08:00] <pitti> 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] <micahg> firefox (3, the default) not firefox-3
[08:13] <pitti> 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] <pitti> and we can push out a fix in some two hours
[08:23] <cjwatson> pitti: agreed
[09:07] <apachelogger> dholbach: described
[09:08] <dholbach> thanks apachelogger
[09:26] <dupondje> 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] <geser> dupondje: do you have an idea where from that non-Ubuntu changelog entries come from?
[09:39] <geser> dupondje: minor note: we use "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>" as maintainer now for main and universe
[09:42] <geser> dupondje: and libcelt-dev and libpt-dev are in universe
[09:46] <geser> 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] <dupondje> https://launchpad.net/ubuntu/+source/opal
[09:47] <dupondje> here it says main ? :p
[09:48] <Laney> not for Maverick
[09:48] <geser> 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] <dupondje> ah I see :) didn't notice
[09:49] <dupondje> could you sync it ?
[09:54] <seb128> pitti, we should maybe move the sdl discussion there
[09:54] <seb128> pitti, I don't know about libsdl1.2debian-udeb
[09:55] <seb128> but maybe cjwatson can reply to whether it's required or not nowadays
[09:56] <seb128> cjwatson, we were discussing stopping building libsdl with directfb since that's the only thing in maverick bringing directfb on the CD
[09:56] <cjwatson> we don't need anything to do with directfb in udebs any more
[09:56] <pitti> nice
[09:56] <pitti> looking at that then
[09:56] <cjwatson> libsdl1.2debian-udeb itself is still in Debian unstable so I guess something is using it
[09:57] <cjwatson> but anything directfb-ish can go
[10:01] <pitti> seb128: I prepare/test that now and upload after alpha-2; for a2 we have to resort to dropping langpacks, I think
[10:02] <pitti> (I already dropped some, with that and yesterday's fixes we should be back in size I think)
[10:04] <seb128> pitti, ok
[10:07] <lifeless> klingon can probably go
[10:07] <lifeless> and latin
[10:08]  * lifeless is teasing and knows they aren't on the CD already
[10:08] <pitti> unfortunately we had to drop languages which are even more popular than Klingon
[10:08] <lifeless> pitti: there are more popular languages? Oh Noes.
[10:08] <pitti> lifeless: I wonder what "core dump" menas in Latin
[10:09] <pitti> "means"
[10:09] <lifeless> probably something about going to the toilet in the forest.
[10:19] <jml> si haec verba legere potes, tibi nimium eruditio est
[10:21] <bilalakhtar> !regression-alert
[10:21] <bilalakhtar> bug #595265
[10:26] <pitti> bilalakhtar: did that happen in a post-lucid upgrade?
[10:26] <bilalakhtar> pitti: yes
[10:26] <bilalakhtar> pitti: an update pushed on 2010-05-03 to maverick
[10:26] <pitti> oh, maverick
[10:27] <bilalakhtar> pitti: and 2010-05-03 on lucid
[10:27] <pitti> bilalakhtar: that isn't an update to lucid then, though
[10:27] <pitti> oh, ok
[10:27] <bilalakhtar> pitti: https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/gwibber/lucid-updates
[10:27] <bilalakhtar> revision 38 ^^
[10:27] <pitti> bilalakhtar: thanks
[10:28] <pitti> bilalakhtar: I'll assign it to the appropriate developer and milestone it accordingly; thanks for pointing out!
[10:29] <bilalakhtar> 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] <pitti> "Don't allow people to click "Add" before we have enough information
[10:30] <pitti>       from facebook to add the account"
[10:30] <pitti> so this is very likely a regression from that indeed
[10:30] <pitti> bilalakhtar: nice to get to know you :)
[10:37] <BlackZ> pitti: could you look at bug #598874 when you have time ? libmpcdec is in main and it would be great to get fixed
[10:38] <pitti> seb128: new sdl working great here \o/
[10:40] <seb128> pitti, nice!
[10:44] <ogra_cmpc> pitti, we have weboffice by default on arm images, OOo only needs to be installable by release day
[10:45] <ogra_cmpc> pitti, so dont worry
[10:46] <pitti> ogra_cmpc: ok, thanks; I dropped OO.o from armel
[10:46] <pitti> http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html looks quite okay now
[10:46] <ogra_cmpc> pitti, you dropped ?
[10:46] <ogra_cmpc> it shouldnt be pulled in at all
[10:46] <ogra_cmpc> since lucid
[10:46] <pitti> ogra_cmpc: I dropped it from ubuntu-desktop [armel], yes
[10:46] <pitti> ogra_cmpc: perhaps you mean netbook?
[10:46] <ogra_cmpc> oh, desktop
[10:47] <ogra_cmpc> yeah, i dont care for desktop
[10:47] <ogra_cmpc> nobody build it
[10:47] <ogra_cmpc> *builds
[10:48] <pitti> right
[10:48] <ogra_cmpc> we should have a working metapackage on release day that doesnt differ from x86, but .nothing to worry about atm
[11:12] <pitti> Riddell: hm, koreport is uninstallable because koffice-libs Conflicts/Replaces: it (without version); should the binary just go then?
[11:13] <pitti> I don't think it breaks actual images, since it's not seeded
[11:14] <Riddell> pitti: yes that binary can go
[11:14] <Riddell> files now in koffice-libs
[11:14] <dholbach> can somebody shove my mail through ubuntu-devel-announce?
[11:14] <pitti> Riddell: oh, it's already NBS, great
[11:14] <pitti> dholbach: will do
[11:14] <dholbach> thanks pitti
[11:16] <pitti> oh, there was more interesting stuff indeed
[11:16] <pitti> geser: please prod someone to moderate u-d-a stuff if you send minutes
[11:21] <Iraq> How install file.tar.zg but learn me step by step please and thank
[11:21] <tsimpson> Iraq: not here
[11:21] <Iraq> not your channel
[11:21] <Iraq> leave me
[11:22] <Iraq> jealos
[11:28] <pitti> ogasawara: kernel ddebs> ah, retrieval from crested (amd64 buildd) was disabled since it hanged forever last time I tried it
[11:28] <pitti> ogasawara: I'm retrieving the last weeks' ddebs and now convert to urllib2 to avoid those hacks in the first place
[11:56] <pitti> ogasawara: argh, except that python is too old on macquarie, so I can't add a timeout
[11:59] <pitti> ogasawara: but missing ddebs are trickling in now
[12:02] <Daviey> 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] <cjwatson> I'll look
[12:02] <Daviey> cjwatson: super, thanks!
[12:03]  * cjwatson has a similarly positioned SRU of his own on its way so needs the karma
[12:03] <cjwatson> in the non-LP sense
[12:03] <Daviey> heh.
[12:06] <cjwatson> Daviey: I guess this will trickle into maverick via an upstream merge?
[12:06] <cjwatson> Daviey: accepted
[12:10] <Daviey> cjwatson: Yeah, that is great thanks
[12:12] <Daviey> 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] <Daviey> 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
[13:24] <pitti> 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] <smb> 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] <pitti> smb: if you don't fell sure about some of them I can skip them
[13:27] <pitti> but I'd like to push out at least the main linux and perhaps ec2
[13:28] <smb> pitti, No push them all. Even if there is anything broken there (which I do not think) it will educate :-P
[13:28] <pitti> ok
[13:57] <Tim> 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] <Tim> Or at least have the bonobo-activation-server reread the configuration
[13:58] <micahg> pitti: was the Firefox upgrade stopped on mirrors for all releases or just Hardy?
[13:59] <pitti> micahg: we didn't actually stop it; it was expected to land much earlier
[13:59] <micahg> pitti: k :)
[13:59] <chrisccoulson> pitti - i've uploaded the new version to the PPA now
[13:59] <pitti> and since affected people have firefox-2 as a fallback, it's not the end of the world perhaps
[13:59] <pitti> chrisccoulson: yay you!
[14:00] <chrisccoulson> i'm going to plan some test cases whilst it's building to make sure all the possible upgrade paths still work
[14:00] <chrisccoulson> but, i must eat first :)
[16:22] <ccheney> pitti, sorry didn't notice my xchat crashed :(
[16:23] <ccheney> pitti, i bet the armel crash is due to the removal doko requested
[16:23] <ccheney> pitti, er code removal
[16:24]  * ccheney examining the crash now to see if it looks likely
[16:31] <ccheney> pitti, armel build failed because the buildd couldn't install the depends, or the current log is that way
[16:32] <ccheney> pitti, if it segfaulted it might be a problem i can fix but the current attempt couldn't install the depends
[16:33] <ogra> ccheney, dont bother i'm pretty sure we need a working openjdk first, the segfaults are during installation fo cacert's
[16:33] <ogra> s/fo/of/
[16:33] <ccheney> ogra: ok
[16:34]  * ccheney goes back to testing server images
[16:34] <ogra> doko_, will you take care of openjdk on armel or do i need to poke linaro now ?
[16:39] <doko_> 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] <doko_> openjdk I mean
[16:39] <ogra> ok
[17:13] <seb128> kees, hi, did you ever upstream your gdm patch to use login.defs value for getting the uid limit?
[17:15] <seb128> 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
[17:53] <kees> seb128: can't you forward port it?
[17:54] <kees> seb128: dropping that patch will cause regressions for people...
[17:55] <seb128> kees, I could yes, they just rewrote this code to be async and the structure you used is not available now
[17:55] <kees> seb128: which version of gdm are you working on?
[17:55] <seb128> 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] <seb128> kees, 2.30.4 but they did quite some refactoring in the stable serie
[17:56] <seb128> 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] <kees> seb128: where in vcs is it?
[17:56] <seb128> kees, debcheckout gdm?
[17:57] <seb128> lp:~ubuntu-desktop/gdm/ubuntu
[17:57] <kees> (main is frozen atm anyway, so a delay should be okay)
[17:58] <seb128> kees, right, it's just that we have a zillion patches to gdm and I spent 3 hours on it today now updating those, so right now I'm in a state where I'm grumpy about people doing changes and not sending those upstream ;-)
[17:58] <seb128> (not that upstream applied the ones we sent...)
[17:58] <seb128> kees, anyway if you want to update it that would be nice otherwise I will do it another day
[17:58] <kees> seb128: right, sorry about that.  I'll update the patch and get it sent upstream.
[17:59] <seb128> kees, don't feel forced to do it, I just figured I would ask in case ;-)
[17:59] <kees> seb128: well, since it affects me, it's easy for me to test.  :)
[18:00] <kees> seb128: vcs says "gdm (2.30.2.is.2.30.0-0ubuntu2) lucid-proposed" ?
[18:01] <seb128> kees, hum?
[18:02] <seb128> kees, https://code.edge.launchpad.net/~ubuntu-desktop/gdm/ubuntu
[18:03] <seb128> kees, oh, lucid-proposed is newer than maverick so if you used debcheckout it might have grabbed the lucid serie
[18:03] <kees> weird, debcheckout did not pull that repo.  anyway, looks good from lp:~ubuntu-desktop/gdm/ubuntu
[18:03] <kees> ah- yeah, that's why
[18:07] <kees> seb128: er, you said the patch didn't apply any more?
[18:08] <seb128> kees, no sorry, it doesn't build anymore rather
[18:08] <seb128> kees, gui/simple-greeter/gdm-user-manager.c
[18:09] <seb128> kees, the manager variable is not available to do manager->priv->minimal_uid
[18:09] <seb128> kees, they changed the code to be async and they don't give the manager to new function now
[18:09] <kees> seb128: ah-ha! okay, I will continue poking at it.
[18:09] <seb128> thanks
[18:48] <seb128> re
[18:48] <seb128> kees, thanks for the updating the patch ;-)
[18:48] <kees> oh! sure thing.  :)
[19:10]  * shadeslayer pokes his head in
[19:26] <shadeslayer> hi,im working on bug 264752
[19:26] <shadeslayer> need a small amount of help tho,the packages debian/rules file has dh_* stuff
[19:27] <shadeslayer> can i mix it woth cdbs? or is there a simpler way to patch it?
[19:58] <ari-tczew> Dear developers, as we are after DebianImportFreeze, I appeal to more frequently move syncs from ~ubuntu-archive bug-list.  Thanks.
[19:59] <cjwatson> well, syncs certainly ought not to be processed preferentially today, as we're in soft freeze for alpha-2.
[19:59] <cjwatson> we can perhaps do some universe ones
[20:00] <cjwatson> oldest sync request seems about five days old
[20:01] <SpamapS> curious, have many people here had success using mentors.debian.net ?
[20:02] <ari-tczew> cjwatson: I'd like to see global use of syncpackage script, which reduce 100% of work archive admins.
[20:06] <cjwatson> I'm not going to get into that again, but in short I want to see LP having a sync operation built-in, which reduces archive admin work in the same way but doesn't have the shortcoming of possible inconsistencies due to work being done on the client size
[20:06] <cjwatson> *client side
[20:06] <cjwatson> ... actually apparently I am going to get into that again.  whatever.
[20:24] <kfogel> jcastro: ping
[20:26] <jcastro> kfogel: hi
[20:27] <kfogel> jcastro: hey!  A rather exciting project I know, the Decapod / Fluid book scanner software (decapod-project.org) is going to need help getting their client-side software packaged for Ubuntu / Debian sometime in the relatively near future.  What's the best way for them to do that?  They don't know much about packaging themselves; they're developers.
[20:28] <shadeslayer> kfogel: ask for it to be packaged by debian ? :P
[20:28] <kfogel> jcastro: (this may well be an FAQ, but there are so many FAQ sheets out there I couldn't find the right one, at least not quickly)
[20:28] <shadeslayer> kfogel: or #ubuntu-motu maybe
[20:28] <jcastro> kfogel: ubuntu-motu mailing list might be a good place to start
[20:28] <kfogel> shadeslayer: yes, thanks.  I have ascertained that mailing debian-mentors@lists.d.o is the way to start on that, but that doesn't guarantee that an Ubuntu package will be rolled, does it?
[20:28] <kfogel> jcastro: thank you
[20:29] <shadeslayer> kfogel: it does actually
[20:29] <jcastro> kfogel: after it's in debian it gets synced back
[20:29] <shadeslayer> kfogel: all ubuntu software is sourced from debian
[20:29] <shadeslayer> !sync | kfogel
[20:29] <shadeslayer> has info about syncs as well
[20:29] <jcastro> kfogel: long term that's what they'll want to do
[20:29] <kfogel> shadeslayer, jcastro: sorry, I should have said "does not guarantee an Ubuntu package will be rolled quickly", but maybe that doesn't matter so much in this case.
[20:29] <kfogel> Anyway, above is enough information to get me pointed in the right direction.  Thanks much!
[20:30] <jcastro> kfogel: https://wiki.ubuntu.com/Upstream <-look uunder "how to get into ubuntu"
[20:30] <kfogel> jcastro: you rock
[20:30]  * shadeslayer is all for sleep right now 
[20:30] <Drakeson> could you please check the package openjdk-6-doc? it is almost empty here (no API documentation unlike what the package description suggests)
[20:44] <seb128> re
[20:45] <seb128> cjwatson, do you know if there is any maverick grub bug about unaligned pointer errors after upgrade?
[20:46] <seb128> cjwatson, I dist-upgrade a box running maverick but which didn't get updated for some weeks and now I get that error instead of grub
[21:01] <seb128> cjwatson, ignore that, I realized that was the error the issues mentioned in your recent blog post were about...
[21:33] <SpamapS> even though its after debian import freeze, we can still request new packages to be synced manually from debian, right?
[21:45] <james_w> SpamapS: indeed
[21:47] <cjwatson> seb128: right, was about to point you at my blog :) what was it, wrong device.map or just needed dpkg-reconfigure grub-pc?
[21:49] <seb128> cjwatson, dunno yet, the box doesn't start and I'm a rsync alpha2 isos, I figured I would use it as an opportunity to try alpha2 livecd
[21:52] <seb128> but I've 2 lucid installs on that box, one that I use regularly and one which is a test install partition
[21:54] <cjwatson> probably just weren't booting from the grub installation that grub-pc/install_devices thought you were booting from then
[21:54] <IdleOne> what package handles the auto login?
[22:26] <kees> SpamapS: the memcached change looks good.  do you need sponsoring of that package?
[22:28] <pitti> ccheney: hm, it was very far into the build, but it called some java program which crashed; it's not a dependency failure
[22:28] <pitti> ccheney: anyway, we worked around the problem for now
[22:45] <SpamapS> kees: I do if you don't mind. :)
[22:45] <SpamapS> kees: forwarding patch to debian right now btw. :)
[22:45] <kees> SpamapS: uploaded!  thanks.  :)
[22:49] <SpamapS> kees: ^5
[22:49] <kees>      5
[22:49] <kees>     o/
[23:07] <ccheney> pitti, yea someone mentioned that earlier today, sorry for my slow response to your comment, i was helping my wife, she is very sick at the moment
[23:07]  * ccheney is making up missed time while away from the computer at night