[00:02] I have a netbook and it's very uncomfortable to navigate normal "netbook- and MID-oriented launchers" using that small touchpad, since those launchers are more intended for tablet PCs and other touchscreen devices [00:02] tjaalton, bryceh: able to confirm bug 528683 ? [00:02] Launchpad bug 528683 in nouveau-kernel-source "Please remove nouveau-kernel-source from the archive (lucid)" [Undecided,New] https://launchpad.net/bugs/528683 [00:02] Riddell: Yup. Unused, won't build. [00:04] cousteau: How does gnome-do itself work on your netbook? [00:04] RAOF: thanks, it's gone [00:05] RAOF: I think it worked well... dunno, had to format the netbook and get the original OS installed on it, now I was trying moblin (I use Do on my desktop) [00:06] gnome-do would be a good alternative to other launchers on netbooks [00:07] (my idea didn't attempt to implement the full Do's functionality, just a small part of it) [00:08] I was thinking more of an addition, but yes. I'm pondering whether to suggest Do for ubuntu-netbook inclusion. [00:10] well, maybe the search bar on my idea could be an interface to Gnome Do, or even further, maybe my whole idea could be implemented as a Do theme, I don't know [00:10] but I have absolutely no idea of C# [00:11] and I don't even know if all that can be implemented as a Gnome Do interface, but it probably does [00:13] RAOF: does do have a bar like the mac os X big bar at the bottom of the screen ? [00:14] You mean a dock? It used to; that's now in the docky package. [00:14] lifeless: it had, but afaik they splitted it as a separate project, "docky" [00:14] RAOF: thanks [00:14] lifeless: Docky is actually rather neat; particularly the glow around needs-attention windows that bleeds onto your screen when the dock is hidden. [00:15] I personally don't like it since 1) it groups windows, 2) it needs compiz or any other composition and that makes my graphics card slow [00:15] RAOF: I'll tell you what lynne things :P [00:15] I wish Docky handled multiple windows properly. [00:15] s/things/thinks/ [00:15] she's being weened from Mac OSX on her new netbook. [00:15] Docky + autohide on a netbook is quite nice. [00:16] wgrant: What behaviour would you prefer? [00:16] RAOF: I want my several terminals to be separated. [00:16] And my browser windows. [00:17] Ah, right. Not one icon per app, but one icon per window. [00:17] There's something coming down the pipeline that may solve that for you, but it's currently just a glimmer in a dev's eye. [00:18] I had an idea about showing thumbnails of all the windows of a program when hovering the program icon, but they didn't like it [00:18] Man, I hope xulrunner-1.9.2 didn't break libmozjs api. [00:20] RAOF: idk, which program? [00:20] which one is that? I have a package called like that, but it's "not installed" and I don't know which firefox it belongs to [00:21] RAOF: it's been mostly pretty smooth... [00:21] micahg: Oh, I'm concerned about libgjs. [00:21] * micahg check if anything's been done with that yet [00:21] micahg: Obviously, xul hasn't yet built, and it'll be even longer before it's built on armel, at which point I'll (a) check if it still fails to build and (b) fix it if it does. [00:22] RAOF: it's FTBFS with a no change rebuild [00:22] oops..might actually work.. [00:23] RAOF - your concern is why we want to minimize the number of things using xulrunner in the archive [00:24] chrisccoulson: Absolutely. gnome-shell hasn't moved off libgjs (yet? please make it yet!), so libgjs remains. [00:24] RAOF - someone started a discussion on the desktop-devel list last year about using seed, but the discussion never went anywhere [00:25] Yeah, I followed that. [00:25] RAOF: I'll try to make sure it's ported by the beta [00:25] It seemed like everyone agreed that it wouldn't be a huge effort, though. [00:25] micahg: That gnome-shell is ported to seed before the beta? Or gjs? [00:25] RAOF: gjs to xul192 [00:26] * cousteau has just downloaded the netbook-launcher source and steps back frightened [00:26] micahg: Thanks. If everything's nice it should need nothing more that a no-change rebuild, plus some investigation as to why the test-suite fails on armel. [00:26] maybe I just do a javascript mockup of how I'd like it to be... [00:27] RAOF: so far most of the changes have been what a component is called or a small API change [00:28] about 25% worked as no change or 1.9.1 to 1.9.2 changes === robbiew is now known as robbiew_ === skipper is now known as bdrung [00:51] RAOF: gjs built :) [00:51] I'll stage in PPA later [00:51] micahg: Yay! [00:51] So, I'll look into the armel ftbfs then? [00:56] RAOF: yeah, that would be great, I'll prepare a debdiff on a bug for the xul192 change [00:57] micahg: Oh, gjs required source changes? Ok. [00:58] RAOF: no, just debian/rules [00:58] Oh, really? That's a bit strange. Did the directory layout change? [01:00] RAOF: xulrunner version is hard coded :) [01:00] Was it? I thought I was extracting it from somewhere. :) [01:01] Oh. Right. *That* package version :) [01:01] yep, that's the only change [01:56] Is it possible to get apport hooks to enable bug reporting against PPA packages (with the bugs filed in Ubuntu)? [01:56] I seem to recall network-manager having something like this. [02:52] <\sh> jcastro: happy birthday === elky` is now known as elky [05:02] parted + udisks won't install in the updates. Is this known? [05:09] * persia notes that the updates *do* install if one updates enough simultaneous packages [05:44] Is the sponsorship page still doing that loop endlessly thing after submit? [06:07] Is gdb expected to work in a qemu arm environment? [06:09] RAOF: for some values of "work", yes. What isn't happening? [06:10] It's not catching SIGSEGV [06:10] “unsupported syscall 26”. [06:10] Ugh. Please report a bug against qemu-kvm. [06:11] That really should work (although note that many times things still work when reporting "unsupported syscall", depending on precisely which syscall it was and why it was called) [06:11] So, the gjs testsuite failure isn't a false-alarm. :) [06:11] RAOF: it failed on i386 [06:11] Oh. It succeeded on my amd64 [06:12] RAOF: on mine also :) [06:12] RAOF: https://edge.launchpad.net/~mozillateam/+archive/ffox35/+build/1553647 [06:12] As a side note, running sbuild against i386 on an amd64 runs a lot faster than running it against armel :) [06:12] But doesn't pick up the armel-specific failure. [06:13] True. [06:13] i386 apparently has a new and different failure. [06:13] ie: *everything* segfaults on armel, but the i386 build passed an entire set of unit tests. [06:14] That's somewhat unexpected. [06:14] Is there assembly code or something? [06:14] I have no idea what crazy javascript hacks are running around in mozjs. [06:15] Since they've been going for javascript performance, and that necessarily involves JIT, I'd guess that yes, there is assembly code involved. [06:15] Indeed, and probably code-generation code. [06:15] (which is hard to port). [06:15] Right [06:17] persia: RAOF: gdb won't work in qemu [06:17] er, qemu-linux-arm [06:17] ptrace isn't implemented, and its technically difficult (if not boardline impossible) to implement it [06:17] RAOF: do you have any idea why the test failed on i386 for me? [06:18] No, but I'm updating my i386 schroot to investigate. [06:18] NCommander: So, no use in filing a bug? :( [06:18] NCommander: How is one expected to debug segfaults then? [06:18] RAOF: well, file a bug, but its unlikely to get implemented any time soon :-/ [06:18] Let's get the bug filed for reference. We can link to the ustream bug. [06:19] RAOF: use real hardware, or qemu-system-arm [06:19] Good morning [06:20] Morning pitti! [06:21] hey RAOF, how are you? [06:22] Good. I'm off to see Alice in Wonderland shortly :) [06:23] o_O [06:27] you can simulate armel in qemu? [06:28] Yes; that's exactly what I've been doing. [06:28] ah, can you simulate ia64 also? [06:29] micahg: I'm off. You can leave the i386 test suite failure with me if you like; I'll get to it tomorrow, along with the armel failure. [06:29] If you want to take it up, you're very welcome to :) [06:29] RAOF: nah, I've got other stuff to port, let me know when I can file the debdiff for xul192 :) [06:31] I've made that change locally; once I've figured out the test-suite failures, I'll upload. Unless the debdiff was more than s/1.9.1/1.9.2/? [06:31] Or if you'd like TIL status on gjs :) [06:31] RAOF: k, no that's it :) [06:32] Anyway; really off :) [06:32] RAOF: k === Amaranth_ is now known as Amaranth [06:47] micahg: You should be able to simulate anything (pbuilder-dist and mk-sbuild support this), but many architecture pairs don't quite work as well as one might hope. [06:48] micahg: For example: `mk-sbuild --arch=ia64 lucid` is a valid command, and tries to do the right thing. [06:52] persia: k, I might try it [06:53] micahg: No promises it works. I've only been testing with amd64-armel (which works fairly well) and amd64-powerpc (which works, but not so well). === thekorn_ is now known as thekorn [07:38] good morning [07:47] tjaalton: did your comment on bug 520796 mean you ACKed it? [07:48] Launchpad bug 520796 in x11proto-dri2 "Sync x11proto-dri2 2.2-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/520796 [07:48] dholbach: yes [07:48] should've probably sub'd archive admins while at it [07:49] tjaalton: ok, you better would've subscribed the ubuntu-archive team too then and unsubscribed the sponsors - I'll do that :) [07:49] dholbach: thanks :) [07:50] high time we reduce the time of the sponsoring queue somewhat [08:13] amitk: hm, the ac97 pm-powersave hook looks a bit wild -- echo 1 > /dev/dsp looks like there could be half a dozen things which could go wrong [08:13] amitk: like using an obsolete API (OSS), interfering with pulseaudio, producing a loud noise, etc [08:15] pitti: I agree. It is recommended on lesswatts too. I was hoping someone with the HW would be able to tell me what it does. [08:16] amitk: also, I think we previously enabled powersaving on intel sound chips, but crimsun had to disable it again because it caused problems -- do we know that these wouldn't affect that ac97 hook? [08:16] pitti: I've found some problems in 2 scripts since then that I'll fix now. [08:16] amitk: well, ac97 is used in a million machines, and there's lots of different hardware, amplifiers, loudspeakers, etc. [08:17] pitti: ac97 is pre-intel-hda. They have no relation [08:17] amitk: right, it's technically a different driver, but the problems from the hda powersave ones (producing plops, latency, etc.) might hit ac97 as well [08:17] that's why I'm a little nervous about this [08:19] pitti: I hope to gather more info through the PPA testing [08:19] amitk: is http://bazaar.launchpad.net/~amitk/ubuntu/lucid/pm-utils-powersave-policy/amit/revision/13 just for text VTs, or for X as well? I thought that X would already do it [08:20] ah, the next commit explains [08:20] pitti: only for text [08:20] amitk: so this is for servers primarily? [08:21] pitti: likely, but I just noticed that the server seeds don't contain pm-utils* [08:22] amitk: do we know that setterm doesn't interfere with X? [08:22] pitti: it doesn't AFAICT [08:23] amitk: ok, that sounds rather harmless then [08:23] amitk: next question, http://bazaar.launchpad.net/~amitk/ubuntu/lucid/pm-utils-powersave-policy/amit/revision/15 [08:23] amitk: why wouldn't that be something that could be enabled in the kernel by default? [08:23] amitk: also, I don't think [ -lt ] works with floats [08:24] pitti: yeah, that is one of the bugs I found :) [08:24] $ LANG= /bin/sh -c '[ 0.34 -lt 0.50 ] && echo yes' [08:24] [: 1: Illegal number: 0.34 [08:25] pitti: I think it is still under devel. As I noted in the comment, this is not the best way to do it, it has to be done periodically in the scheduler [08:26] amitk: r16 likewise then, I figure [08:26] yes [08:31] amitk: http://bazaar.launchpad.net/~amitk/ubuntu/lucid/pm-utils-powersave-policy/amit/revision/17 [08:31] amitk: would you mind checking type ethtool? (since we don't seem to install that by default) [08:32] pitti: we don't. I should add a Deps in the packaging [08:42] pitti: thanks for the review. I'll fix stuff and upload to PPA [10:11] cwatson? [10:11] ubi-partman exits with error 141 in todays UNR installer [10:13] syslog says: "/lib/partman/choose_partition//do_option: not found" [10:14] spaetz: That's usually best debugged with more logs. I believe it happens when some partman module doesn't successfully identify the target. [10:17] my syslog seems pretty identical to the one in https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/527848 which cwtson closed as fixed 8 days ago. [10:17] Launchpad bug 527848 in ubiquity "[Lucid] ubi-partman failed with exit code 141 during manual partitioning" [Undecided,Fix released] [10:18] I will make sure that I really use todays build and comment on that bug then. Thanks [10:22] spaetz: if you want to highlight me, you need to get my nick right, too :-) [10:23] spaetz: if you can definitely reproduce it with a current build, start the installer with 'ubiquity --debug' in a terminal, exit the installer when it crashes, and then run 'ubuntu-bug ubiquity' to create a new bug with all the necessary information [10:23] spaetz: DO NOT ATTACH LOGS TO AN EXISTING BUG EVEN IF IT LOOKS THE SAME :-) [10:24] cjwatson: ahh there you are, hello :) [10:24] Just commented on the above bug [10:24] Definitely reproducable [10:25] please DO NOT COMMENT ON AN EXISTING BUG [10:25] file a new one, please! [10:25] will do. [10:25] there are multiple causes for that symptom [10:25] spaetz: oh, if your network card doesn't work - the log files I need are /var/log/syslog, /var/log/partman, and /var/log/installer/debug [10:26] spaetz: you can extract them onto a USB stick [10:26] sorry to shout above, but it's really hard work disentangling multiple problems from a single bug and I want to discourage the practice as much as possible [10:28] ok, will do. No problem about shouting :) [10:28] no offense :) [10:32] spaetz: please let me know the bug number once you file it - we've had a few of these problems and I want to stomp on them hard and quickly [10:34] Yep, just copied over log files. Battleing with launchpad right now. [10:35] "Sorry, something just went wrong in Launchpad. " [10:35] when looking for package ubiquity (https://launchpad.net/ubuntu/+search?text=ubiquity) [10:39] cjwatson: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/535630 [10:39] Launchpad bug 535630 in ubiquity "[lucid UNR] ubi-partman crashes with error 141" [Undecided,New] [10:41] attachments uploaded [10:43] spaetz: you didn't appear to reproduce the failure when running in debug mode [10:43] spaetz: or if you did, you didn't exit the installer before saving off the logs, so it didn't flush all the log data out [10:44] opps, no the installer is still open [10:44] should I close it and attach full logs? [10:44] yes please [10:44] I need a debug log that actually shows the failure :) [10:44] or rather, let me restart the install, I will attach a clean log [10:45] yeah, that would be best if you could, thanks [10:51] cjwatson: reattached new logs [10:51] not rebooted, but fresh ubiquity -d run [10:51] which I actually quited after the error dialog [10:57] Hey, and that bug was already closed by some "mercedes" as fixed released... [10:58] I will reopen and LART mercedes [10:58] thanks a bunch :) [11:12] kirkland`: any reason qemu-kvm's Architecture field doesn't include sparc? [11:12] kirkland`: the actual code seems to build fine there [11:14] kirkland`: I'm having to remove libvirt on powerpc and sparc even though that makes some things uninstallable there, because the lesser evil is getting rid of the old libparted from the archive [11:16] kirkland`: (actually just libvirt-bin; cf. bug 535368) [11:16] Launchpad bug 535368 in parted "gparted will not install on lucid Alpha3" [Undecided,Confirmed] https://launchpad.net/bugs/535368 [11:20] james_w: I think it's the second time that I look at a branch (lp:ubuntu/sysvinit) which only has the karmic version; does that mean that something in lucid packaging changed which made the auto-importer fail? [11:41] asac: kdebindings still fails in the same place on ARM [11:41] still, I can add the kdeedu packages back to the seed [11:42] Riddell: ok. so kdebindings succeeds because you disabled smoke, right? [11:42] how important? [11:42] asac: yes [11:42] we should file a bug about that i think [11:42] otherwise we will forget because its gone from ftbfs [11:42] asac: not very, it makes the ruby and csharp bindings for KDE but they're not much used. a bug would be good though [11:44] free: re these twisted syncs, it's OK in future to use a single bug for lots of closely associated syncs rather than a set of bugs with the same description, if you prefer that [11:44] free: (but leave it alone now, I'm processing them the way they are) === pedro__ is now known as pedro_ [11:45] cjwatson: thanks, I'll keep it mind [11:45] might cut down on FFe paperwork [11:46] cjwatson: Prior recommendations in this channel have been to either file a bundle of bugs, or manually provide an archive-admin with a preformatted list. Would it be worth adding clear documentation on which works better with the tools to the wiki somewhere? [11:46] cjwatson: yeah, sorry for the extra burdeon [11:46] persia: both work fine with the tools [11:47] persia: normally separate bugs would be easier to keep track of (you'd get a more sensible comment trail), but when applying for a combined FFe I think a single bug is easier [11:48] asac: is xulrunner-dev still the right package to build the java plugin? [11:48] doko__: yes [11:50] cjwatson: Ah, OK. Thanks. [11:57] anyone know of any tmpfs corruptions on jaunty? i have a server that has a mildly corrupt /var/run.. [11:58] dirent is returning a vnode that doesn't exist.. [11:58] no kernel hackers [11:58] ? [11:59] The kernel hacker / IRC nick ratio is slightly higher in #ubuntu-kernel [12:02] persia: will do thanks.. [12:05] has anyone seen mvo lately? [12:05] hmmm no voice on #ubuntu-kernel? [12:06] pitti, what criteria does lucid-burndown use to select blueprints? i assume it is 'series goal' of lucid ? [12:12] lamont | doko__ : just looking at https://launchpad.net/ubuntu/+source/ghc6/6.12.1-12/+build/1526050/+files/buildlog_ubuntu-lucid-armel.ghc6_6.12.1-12_FAILEDTOBUILD.txt.gz, I assume the build was killed by hand? do we have a faster armel box than jackfruit? [12:13] sistpoty|work: I can confirm it was killed by hand, by Laney's request. There's a don't-die-from-timeout loop in there that makes it not die. [12:14] persia: yes, that's the watcher script. ghc6 was still running though [12:16] Then I'm not sure why Laney asked for the build to be killed. [12:16] "[03:54] lamont: please kill https://launchpad.net/ubuntu/+source/ghc6/6.12.1-12/+build/1526050 - it's obviously hung" [12:17] (from #launchpad) [12:17] sistpoty|work: what makes you think it was still progressing? === MacSlow is now known as MacSlow|lunch [12:20] Laney: mainly that I've watched a ghc6 stage2 compile pass taking a week a long time ago. ghc6 was still running in the build, so why should it not progress? === doko__ is now known as doko [12:27] Laney: indeed, I think progress at this point was highly unlikely, since I can't see gcc running (and usually that's where it takes very long) [12:27] Should maybe the watcher script be modified to print out an extract of ps output ? [12:28] persia: it does that already [12:28] (that's where I gather my knowledge from ;)) [12:29] I would have expected to see some build output [12:30] but the fact that it hung at the start of stage2, and took so long, led me to that conclusion [12:30] it has also been tried and aborted several times before on different buildds [12:30] I don't think there's any real difference between the buildds. [12:37] Laney: *nod*, makes sense [12:40] Laney: maybe we should retry again? there's a newer eglibc available that includes an arm specific change [12:40] sistpoty|work: a local test build would probably be a better use of resources [12:41] Laney: sure, but I don't have an arm box :/ [12:41] apw: correct, it parses ubuntu/lucid/+specs [12:44] Laney: sistpoty|work: How long is this expected to take to build, and how well does it deal with sleep? I have an ARM box, but I carry it with me and don't want to kill the battery whenever I go between power connections. [12:44] persia: the debian build took at least 5 days. No clue about sleeping though [12:45] 5 days! Hrm. Maybe I can do something. [12:45] persia: that would be awesome! [12:46] What do you need? Just confirmation success/fail? A buildlog? [12:46] Also, should I be able to build in a lucid pbuilder from jaunty? === pts is now known as pths [12:47] persia: build log if it fails would be good, I guess. I think building from jaunty should work. Laney, anything else? [12:48] Laney: Also, does it still fail to configure in qemu? [12:50] sistpoty|work: should be fine indeed [12:51] persia: I don't know, and my PC has locked up again so I can't check until later [12:51] . o O ( I should debug that ) [12:52] Laney: Could you? I have significantly more memory/processor cycles to throw at qemu-armel than real armel (as do most of us, I suspect). [12:55] is aptitude on lucid on amd64 broken for anyone else? [12:55] I guess you could also try to pbuilder-armel it too, persia [12:55] if you have the requisite hardware to hand [12:56] * persia mostly needs a good kick to install Ubuntu on the new server still sitting in shiny packaging. [12:57] I'll definitely start an sbuild-armel run on an amd64 server tomorrow. I need to fiddle a bit to make sure I have ~5 days where I won't run out of power for the real build. === MacSlow|lunch is now known as MacSlow [13:38] cjwatson: okay, thanks for the heads up on libvirt/sparc === kirkland` is now known as kirkland [14:11] Dear Launchpad folks, [14:11] I want a button on a bug report. [14:11] Clicking this button should electrocute the original reporter. [14:11] "Please wait while bug data is processed" [14:11] Then bar them from ever making any status changes to any bug ever again. [14:11] if this could be automatic if someone changes a bug from the "Won't Fix" status, that would be AWESOME [14:13] Keybuk: Do you have an example bug where a non-developer managed to unset Won'tFix ? I thought that wasn't supposed to be possible. [14:13] mvo: ping [14:13] persia: there's nothing that makes it not possible [14:13] bug #535120 [14:13] Launchpad bug 535120 in upstart "Please add option -f and -F to shutdown for LPIC compatibility" [Wishlist,Won't fix] https://launchpad.net/bugs/535120 === sconklin-gone is now known as sconklin [14:23] ogra: is bug 536670 what you see as well? i. e. do you have an unpartitioned device which doesn't automount? [14:23] Launchpad bug 536670 in gvfs "Does not automount unpartitioned devices" [High,Confirmed] https://launchpad.net/bugs/536670 [14:25] pitti, hmm, i dont knoe if my reader is unpartitioned [14:25] ogra: my Sony PRS 505 is [14:25] * ogra has a TS 600 [14:25] let me get it ... [14:25] ogra: well, if you get around to it in the next week or so, would be great to check (not that urgent) [14:26] ogra: I can perfectly reproduce the bug with both an USB stick and my ebook; I just wanted to know whether a partitioned device failed for you (that works well for me) [14:27] ok, its unpartitioned .... funny though that they put two separate devices in instead of one with two partitons [14:28] pitti, partitioned USB keys work [14:28] ogra: thanks, so that seems to be your bug then [14:29] right, do you need a confirmation comment or anything ? [14:29] ogra: heh, mine has three - internal flash memory, SD card reader, and a proprietary sony card reader [14:29] ogra: no, I don't; if you are interested you can subscribe [14:29] yeah, mine has the readers too, but internally it also has two deviced [14:29] *devices [14:29] ogra: knowing that it's not yet something else which is broken is enough for me :) [14:29] thanks for checking [14:29] one with the windows SW i never use and one for the book db [14:30] ogra: oh, is that windows sw one readonly? [14:30] no idea i never looked at it :) [14:30] ogra: if that's useless under Linux, please feel free to file a bug against udisks to entirely ignore that one [14:30] (similar to all those rescure partitions, etc.) [14:31] ogra: it'd be a 5-minute fix, and it's one more bug to fix to catch up with kirkland :-P [14:31] ogra@osiris:/var/build$ sudo mount /dev/sde /mnt/ [14:31] mount: blockorientiertes Gerät /dev/sde ist schreibgeschützt, wird eingehängt im Nur-Lese-Modus [14:31] *nod* [14:31] so, ROM [14:32] but i dont know how to find out any additional info you could match on [14:32] it looks like a std scsi disk [14:32] ogra: ubuntu-bug storage [14:32] with it mounted ? [14:32] Keybuk: I have somebody spuriously setting newly filed bugs to Fix Released with no comment [14:32] ogra: actually, that's broken right now unfortunately (I just uploaded a fix, but it still needs to get published) [14:32] i'll do it later then [14:32] ogra: file it manually, plug it in, and attach the output of "udevadm info --export-db" [14:33] ogra: or that; I'll ping you again [14:33] cjwatson: that I wouldn't mind ;) [14:33] (assuming the someone is the reporter) [14:34] pitti: bring it on! [14:34] Keybuk: nope, just some random person, and the bug was one I was in the middle of working on [14:35] Russian bug roulette? === robbiew_ is now known as robbiew [14:55] sistpoty, Laney: did you have a gh6 fix you wanted to test on ARM hardware? [14:56] JamieBennett: not a fix, just a test-build with the current sources against the current libc (that changed since the last failed build on the buildds) [14:57] sistpoty|work:: I have ARM hardware available that can be used if you give me a run down of exactly what you want me to do with it [14:58] If you could do a test-build of ghc from Lucid and see if it succeeds, that would be cool. [14:58] And then if and when it starts looping at the stage2 build, poking around to see what is going on [14:59] JamieBennett: I was wondering, what draws the background in n-l-efl? g-s-d or do you have your own way in n-l-efl to draw it? [15:00] JamieBennett: are you familiar with the difference between Debian and Ubuntu wrt ARM that could cause FTBFS like this? Or are there many and numerous? [15:00] pitti: yes, that package failed to import a recent version [15:01] didrocks: I'm not sure, that would be one for mterry to answer [15:02] mterry: ^ ? [15:02] Laney: I haven't looked into the specifics of this build failure yet, just got a 'call for hardware' message. I'll investigate. [15:02] didrocks, huh. probably NLE, but I can't give a 100% answer without grepping the code [15:05] mterry: if it's not g-s-d and if you don't use gnome-desktop to draw it, you might be interested by the cache I have implemented. This can save some time at boot. Just tell me :) [15:05] didrocks, ah neat [15:05] didrocks, will do, once i check in a bit [15:05] Laney: At a high level, all the toolchain defaults differ, including the target ISA, which has a number of effects. [15:06] Keybuk, for bug 531494 i'll try to get you /var/log/udev . is there anything else that woudl be helpful ? [15:06] Launchpad bug 531494 in upstart "cloud-init job not running in eucalyptus without ramdisk" [Critical,Confirmed] https://launchpad.net/bugs/531494 [15:07] mterry: sweet :) [15:09] smoser: a patch [15:12] Keybuk, you'll be happy, or sad to know, that in my first test on the 20100310 image, i did not reproduce failure. [15:12] however, that is on a different UEC rig than i was seeing it on with 20100303 === tkamppeter_ is now known as tkamppeter [15:41] pitti, hi === jamie is now known as Guest59876 [15:53] hi tkamppeter [15:56] http://imgnow.info/DSC-1268236606.jpg does my ass look big? [15:57] pitti, have you seen that I have SRUed bug 293832? [15:57] Launchpad bug 293832 in poppler "printer prints page at wrong position, page cut" [High,Fix committed] https://launchpad.net/bugs/293832 [15:58] tkamppeter: I'll get to SRU this week, then I'll process it [15:58] pitti, OK. [16:00] kees, doko: just looking at bug #438876, might this be a problem with gcc-4.4 and stack-protector on sparc? [16:00] Launchpad bug 438876 in perl "perl ftbfs with gcc-4.4 -O2 on sparc" [Medium,Triaged] https://launchpad.net/bugs/438876 [16:00] kees, doko: erm, actually bug #534459, sorry [16:00] Launchpad bug 534459 in patch "2.6-2 FTBFS on sparc (bus error in test cases)" [Undecided,Confirmed] https://launchpad.net/bugs/534459 [16:06] I need to write a small C program that sets the current console back to KD_TEXT and VT_AUTO, etc. [16:07] either that, or remember to keep X running and chvt to that [16:19] wow... seems a LOT of users have problems with grub using the embed area and bad windows software overwriting it... but it doesn't look like anything is being done about this. Shouldn't we change grub to not use the embed area by default? [16:20] psusi: definitely not! [16:20] psusi: that would suck differently [16:20] why? [16:20] I don't have time to explain, sorry [16:20] in a meeting [16:20] suffice to say I would absolutely veto that change [16:21] heh... iirc we dind't used to use stage1.5 by default in grub legacy.. so I'm wondering why it's defaulted to now.... [16:21] false. [16:21] pretty sure we configured grub legacy essentially the same way. [16:21] really? hrm... maybe it was just me then since I've always had an unusual config due to fakeraid ;) [16:22] but unless you want to do something radical like online defrag that would disturb /boot/grub, I don't see what disadvantage you would have by not using the embed area [16:23] totally unreliable [16:24] how so? as long as the core file isn't moved... [16:24] putting grub in the partition means that you have to use blocklists which means that "significant enough" changes to the partition break stuff [16:24] upstream have deprecated this and for good reason. [16:25] and it isn't just defrag [16:25] resizing the partition then I guess could do it as well [16:25] http://grub.enbug.org/BIOS_Boot_Partition [16:25] (that focuses on GPT, but the section on blocklists is generally applicable [16:25] ) [16:26] yea, that's nice for GPT, but we aren't talking about people using GPT ;) [16:26] psusi: please read what I just said! [16:26] "the section on blocklists is generally applicable" [16:28] I'm aware of the issues... it just seems to me that most of our users would not have a problem with that since they don't tend to do radical operations to the filesystem [16:29] *blink* how about the way our installer automatically resizes things to make room? :-) [16:29] also, I'm just not seeing the number of issues you refer to [16:29] they're dwarfed by other things [16:29] it automatically resizes windows partition to make room for Ubuntu... [16:29] you haven't looked at the code, obviously :) [16:29] it doesn't care whether it's Windows [16:30] well I see a lot of people complaining about bug #441941 [16:30] Launchpad bug 441941 in grub2 "grub fails after running Windows" [Undecided,Confirmed] https://launchpad.net/bugs/441941 [16:30] well yea, I suppose if you install a new version of Ubuntu it would shrink the old partition [16:30] I think that's specialised, it doesn't seem to hit everyone [16:30] of course if you do that, then you'd re install the mbr after the resize anyhow so no problem ;) [16:31] and that bug is unusable anyway, it's full of conflicting comments and invective [16:31] so meh [16:31]