[00:02] <cousteau> 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] <Riddell> tjaalton, bryceh: able to confirm bug 528683 ?
[00:02] <RAOF> Riddell: Yup.  Unused, won't build.
[00:04] <RAOF> cousteau: How does gnome-do itself work on your netbook?
[00:04] <Riddell> RAOF: thanks, it's gone
[00:05] <cousteau> 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] <cousteau> gnome-do would be a good alternative to other launchers on netbooks
[00:07] <cousteau> (my idea didn't attempt to implement the full Do's functionality, just a small part of it)
[00:08] <RAOF> I was thinking more of an addition, but yes.  I'm pondering whether to suggest Do for ubuntu-netbook inclusion.
[00:10] <cousteau> 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] <cousteau> but I have absolutely no idea of C#
[00:11] <cousteau> and I don't even know if all that can be implemented as a Gnome Do interface, but it probably does
[00:13] <lifeless> RAOF: does do have a bar like the mac os X big bar at the bottom of the screen ?
[00:14] <RAOF> You mean a dock?  It used to; that's now in the docky package.
[00:14] <cousteau> lifeless: it had, but afaik they splitted it as a separate project, "docky"
[00:14] <lifeless> RAOF: thanks
[00:14] <RAOF> 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] <cousteau> 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] <lifeless> RAOF: I'll tell you what lynne things :P
[00:15] <wgrant> I wish Docky handled multiple windows properly.
[00:15] <lifeless> s/things/thinks/
[00:15] <lifeless> she's being weened from Mac OSX on her new netbook.
[00:15] <RAOF> Docky + autohide on a netbook is quite nice.
[00:16] <RAOF> wgrant: What behaviour would you prefer?
[00:16] <wgrant> RAOF: I want my several terminals to be separated.
[00:16] <wgrant> And my browser windows.
[00:17] <RAOF> Ah, right.  Not one icon per app, but one icon per window.
[00:17] <RAOF> 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] <cousteau> 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] <RAOF> Man, I hope xulrunner-1.9.2 didn't break libmozjs api.
[00:20] <micahg> RAOF: idk, which program?
[00:20] <cousteau> 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] <micahg> RAOF: it's been mostly pretty smooth...
[00:21] <RAOF> micahg: Oh, I'm concerned about libgjs.
[00:21]  * micahg check if anything's been done with that yet
[00:21] <RAOF> 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] <micahg> RAOF: it's FTBFS with a no change rebuild
[00:22] <micahg> oops..might actually work..
[00:23] <chrisccoulson> RAOF - your concern is why we want to minimize the number of things using xulrunner in the archive
[00:24] <RAOF> chrisccoulson: Absolutely.  gnome-shell hasn't moved off libgjs (yet?  please make it yet!), so libgjs remains.
[00:24] <chrisccoulson> RAOF - someone started a discussion on the desktop-devel list last year about using seed, but the discussion never went anywhere
[00:25] <RAOF> Yeah, I followed that.
[00:25] <micahg> RAOF: I'll try to make sure it's ported by the beta
[00:25] <RAOF> It seemed like everyone agreed that it wouldn't be a huge effort, though.
[00:25] <RAOF> micahg: That gnome-shell is ported to seed before the beta?  Or gjs?
[00:25] <micahg> RAOF: gjs to xul192
[00:26]  * cousteau has just downloaded the netbook-launcher source and steps back frightened
[00:26] <RAOF> 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] <cousteau> maybe I just do a javascript mockup of how I'd like it to be...
[00:27] <micahg> RAOF: so far most of the changes have been what a component is called or a small API change
[00:28] <micahg> about 25% worked as no change or 1.9.1 to 1.9.2 changes
[00:51] <micahg> RAOF: gjs built :)
[00:51] <micahg> I'll stage in PPA later
[00:51] <RAOF> micahg: Yay!
[00:51] <RAOF> So, I'll look into the armel ftbfs then?
[00:56] <micahg> RAOF: yeah, that would be great, I'll prepare a debdiff on a bug for the xul192 change
[00:57] <RAOF> micahg: Oh, gjs required source changes?  Ok.
[00:58] <micahg> RAOF: no, just debian/rules
[00:58] <RAOF> Oh, really?  That's a bit strange.  Did the directory layout change?
[01:00] <micahg> RAOF: xulrunner version is hard coded :)
[01:00] <RAOF> Was it?  I thought I was extracting it from somewhere. :)
[01:01] <RAOF> Oh.  Right.  *That* package version :)
[01:01] <micahg> yep, that's the only change
[01:56] <RAOF> Is it possible to get apport hooks to enable bug reporting against PPA packages (with the bugs filed in Ubuntu)?
[01:56] <RAOF> I seem to recall network-manager having something like this.
[02:52] <\sh> jcastro: happy birthday
[05:02] <jarlath> 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] <YokoZar> Is the sponsorship page still doing that loop endlessly thing after submit?
[06:07] <RAOF> Is gdb expected to work in a qemu arm environment?
[06:09] <persia> RAOF: for some values of "work", yes.  What isn't happening?
[06:10] <RAOF> It's not catching SIGSEGV
[06:10] <RAOF> “unsupported syscall 26”.
[06:10] <persia> Ugh.  Please report a bug against qemu-kvm.
[06:11] <persia> 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] <RAOF> So, the gjs testsuite failure isn't a false-alarm. :)
[06:11] <micahg> RAOF: it failed on i386
[06:11] <RAOF> Oh.  It succeeded on my amd64
[06:12] <micahg> RAOF: on mine also :)
[06:12] <micahg> RAOF: https://edge.launchpad.net/~mozillateam/+archive/ffox35/+build/1553647
[06:12] <persia> As a side note, running sbuild against i386 on an amd64 runs a lot faster than running it against armel :)
[06:12] <RAOF> But doesn't pick up the armel-specific failure.
[06:13] <persia> True.
[06:13] <RAOF> i386 apparently has a new and different failure.
[06:13] <RAOF> ie: *everything* segfaults on armel, but the i386 build passed an entire set of unit tests.
[06:14] <persia> That's somewhat unexpected.
[06:14] <persia> Is there assembly code or something?
[06:14] <RAOF> I have no idea what crazy javascript hacks are running around in mozjs.
[06:15] <RAOF> 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] <persia> Indeed, and probably code-generation code.
[06:15] <persia> (which is hard to port).
[06:15] <RAOF> Right
[06:17] <NCommander> persia: RAOF: gdb won't work in qemu
[06:17] <NCommander> er, qemu-linux-arm
[06:17] <NCommander> ptrace isn't implemented, and its technically difficult (if not boardline impossible) to implement it
[06:17] <micahg> RAOF: do you have any idea why the test failed on i386 for me?
[06:18] <RAOF> No, but I'm updating my i386 schroot to investigate.
[06:18] <RAOF> NCommander: So, no use in filing a bug? :(
[06:18] <RAOF> NCommander: How is one expected to debug segfaults then?
[06:18] <NCommander> RAOF: well, file a bug, but its unlikely to get implemented any time soon :-/
[06:18] <persia> Let's get the bug filed for reference.  We can link to the ustream bug.
[06:19] <NCommander> RAOF: use real hardware, or qemu-system-arm
[06:19] <pitti> Good morning
[06:20] <RAOF> Morning pitti!
[06:21] <pitti> hey RAOF, how are you?
[06:22] <RAOF> Good.  I'm off to see Alice in Wonderland shortly :)
[06:23] <pitti> o_O
[06:27] <micahg> you can simulate armel in qemu?
[06:28] <RAOF> Yes; that's exactly what I've been doing.
[06:28] <micahg> ah, can you simulate ia64 also?
[06:29] <RAOF> 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] <RAOF> If you want to take it up, you're very welcome to :)
[06:29] <micahg> RAOF: nah, I've got other stuff to port, let me know when I can file the debdiff for xul192 :)
[06:31] <RAOF> 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] <RAOF> Or if you'd like TIL status on gjs :)
[06:31] <micahg> RAOF: k, no that's it :)
[06:32] <RAOF> Anyway; really off :)
[06:32] <micahg> RAOF: k
[06:47] <persia> 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] <persia> micahg: For example: `mk-sbuild --arch=ia64 lucid` is a valid command, and tries to do the right thing.
[06:52] <micahg> persia: k, I might try it
[06:53] <persia> 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).
[07:38] <dholbach> good morning
[07:47] <dholbach> tjaalton: did your comment on bug 520796 mean you ACKed it?
[07:48] <tjaalton> dholbach: yes
[07:48] <tjaalton> should've probably sub'd archive admins while at it
[07:49] <dholbach> tjaalton: ok, you better would've subscribed the ubuntu-archive team too then and unsubscribed the sponsors - I'll do that :)
[07:49] <tjaalton> dholbach: thanks :)
[07:50] <dholbach> high time we reduce the time of the sponsoring queue somewhat
[08:13] <pitti> 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] <pitti> amitk: like using an obsolete API (OSS), interfering with pulseaudio, producing a loud noise, etc
[08:15] <amitk> 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] <pitti> 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] <amitk> pitti: I've found some problems in 2 scripts since then that I'll fix now.
[08:16] <pitti> amitk: well, ac97 is used in a million machines, and there's lots of different hardware, amplifiers, loudspeakers, etc.
[08:17] <amitk> pitti: ac97 is pre-intel-hda. They have no relation
[08:17] <pitti> 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] <pitti> that's why I'm a little nervous about this
[08:19] <amitk> pitti: I hope to gather more info through the PPA testing
[08:19] <pitti> 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] <pitti> ah, the next commit explains
[08:20] <amitk> pitti: only for text
[08:20] <pitti> amitk: so this is for servers primarily?
[08:21] <amitk> pitti: likely, but I just noticed that the server seeds don't contain pm-utils*
[08:22] <pitti> amitk: do we know that setterm doesn't interfere with X?
[08:22] <amitk> pitti: it doesn't AFAICT
[08:23] <pitti> amitk: ok, that sounds rather harmless then
[08:23] <pitti> amitk: next question, http://bazaar.launchpad.net/~amitk/ubuntu/lucid/pm-utils-powersave-policy/amit/revision/15
[08:23] <pitti> amitk: why wouldn't that be something that could be enabled in the kernel by default?
[08:23] <pitti> amitk: also, I don't think [ -lt ] works with floats
[08:24] <amitk> pitti: yeah, that is one of the bugs I found :)
[08:24] <pitti> $ LANG= /bin/sh -c '[ 0.34 -lt 0.50 ] && echo yes'
[08:24] <pitti> [: 1: Illegal number: 0.34
[08:25] <amitk> 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] <pitti> amitk: r16 likewise then, I figure
[08:26] <amitk> yes
[08:31] <pitti> amitk: http://bazaar.launchpad.net/~amitk/ubuntu/lucid/pm-utils-powersave-policy/amit/revision/17
[08:31] <pitti> amitk: would you mind checking type ethtool? (since we don't seem to install that by default)
[08:32] <amitk> pitti: we don't. I should add a Deps in the packaging
[08:42] <amitk> pitti: thanks for the review. I'll fix stuff and upload to PPA
[10:11] <spaetz> cwatson?
[10:11] <spaetz> ubi-partman exits with error 141 in todays UNR installer
[10:13] <spaetz> syslog says: "/lib/partman/choose_partition//do_option: not found"
[10:14] <persia> 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] <spaetz> 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:18] <spaetz> I will make sure that I really use todays build and comment on that bug then. Thanks
[10:22] <cjwatson> spaetz: if you want to highlight me, you need to get my nick right, too :-)
[10:23] <cjwatson> 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] <cjwatson> spaetz: DO NOT ATTACH LOGS TO AN EXISTING BUG EVEN IF IT LOOKS THE SAME :-)
[10:24] <spaetz> cjwatson: ahh there you are, hello :)
[10:24] <spaetz> Just commented on the above bug
[10:24] <spaetz> Definitely reproducable
[10:25] <cjwatson> please DO NOT COMMENT ON AN EXISTING BUG
[10:25] <cjwatson> file a new one, please!
[10:25] <spaetz> will do.
[10:25] <cjwatson> there are multiple causes for that symptom
[10:25] <cjwatson> 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] <cjwatson> spaetz: you can extract them onto a USB stick
[10:26] <cjwatson> 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] <spaetz> ok, will do. No problem about shouting :)
[10:28] <spaetz> no offense :)
[10:32] <cjwatson> 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] <spaetz> Yep, just copied over log files. Battleing with launchpad right now.
[10:35] <spaetz> "Sorry, something just went wrong in Launchpad. "
[10:35] <spaetz> when looking for package ubiquity (https://launchpad.net/ubuntu/+search?text=ubiquity)
[10:39] <spaetz> cjwatson: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/535630
[10:41] <spaetz> attachments uploaded
[10:43] <cjwatson> spaetz: you didn't appear to reproduce the failure when running in debug mode
[10:43] <cjwatson> 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] <spaetz> opps, no the installer is still open
[10:44] <spaetz> should I close it and attach full logs?
[10:44] <cjwatson> yes please
[10:44] <cjwatson> I need a debug log that actually shows the failure :)
[10:44] <spaetz> or rather, let me restart the install, I will attach a clean log
[10:45] <cjwatson> yeah, that would be best if you could, thanks
[10:51] <spaetz> cjwatson: reattached new logs
[10:51] <spaetz> not rebooted, but fresh ubiquity -d run
[10:51] <spaetz> which I actually quited after the error dialog
[10:57] <spaetz> Hey, and that bug was already closed by some "mercedes" as fixed released...
[10:58] <cjwatson> I will reopen and LART mercedes
[10:58] <spaetz> thanks a bunch :)
[11:12] <cjwatson> kirkland`: any reason qemu-kvm's Architecture field doesn't include sparc?
[11:12] <cjwatson> kirkland`: the actual code seems to build fine there
[11:14] <cjwatson> 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] <cjwatson> kirkland`: (actually just libvirt-bin; cf. bug 535368)
[11:20] <pitti> 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] <Riddell> asac: kdebindings still fails in the same place on ARM
[11:41] <Riddell> still, I can add the kdeedu packages back to the seed
[11:42] <asac> Riddell: ok. so kdebindings succeeds because you disabled smoke, right?
[11:42] <asac> how important?
[11:42] <Riddell> asac: yes
[11:42] <asac> we should file a bug about that i think
[11:42] <asac> otherwise we will forget because its gone from ftbfs
[11:42] <Riddell> 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] <cjwatson> 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] <cjwatson> free: (but leave it alone now, I'm processing them the way they are)
[11:45] <free> cjwatson: thanks, I'll keep it mind
[11:45] <cjwatson> might cut down on FFe paperwork
[11:46] <persia> 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] <free> cjwatson: yeah, sorry for the extra burdeon
[11:46] <cjwatson> persia: both work fine with the tools
[11:47] <cjwatson> 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] <doko__> asac: is xulrunner-dev still the right package to build the java plugin?
[11:48] <asac> doko__: yes
[11:50] <persia> cjwatson: Ah, OK.  Thanks.
[11:57] <tankenmate> anyone know of any tmpfs corruptions on jaunty? i have a server that has a mildly corrupt /var/run..
[11:58] <tankenmate> dirent is returning a vnode that doesn't exist..
[11:58] <tankenmate> no kernel hackers
[11:58] <tankenmate> ?
[11:59] <persia> The kernel hacker / IRC nick ratio is slightly higher in #ubuntu-kernel
[12:02] <tankenmate> persia: will do thanks..
[12:05] <zyga> has anyone seen mvo lately?
[12:05] <tankenmate> hmmm no voice on #ubuntu-kernel?
[12:06] <apw> pitti, what criteria does lucid-burndown use to select blueprints?   i assume it is 'series goal' of lucid ?
[12:12] <sistpoty|work> 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] <persia> 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] <sistpoty|work> persia: yes, that's the watcher script. ghc6 was still running though
[12:16] <persia> Then I'm not sure why Laney asked for the build to be killed.
[12:16] <persia> "[03:54] <Laney> lamont: please kill https://launchpad.net/ubuntu/+source/ghc6/6.12.1-12/+build/1526050 - it's obviously hung"
[12:17] <persia> (from #launchpad)
[12:17] <Laney> sistpoty|work: what makes you think it was still progressing?
[12:20] <sistpoty|work> 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?
[12:27] <sistpoty|work> 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] <persia> Should maybe the watcher script be modified to print out an extract of ps output ?
[12:28] <sistpoty|work> persia: it does that already
[12:28] <sistpoty|work> (that's where I gather my knowledge from ;))
[12:29] <Laney> I would have expected to see some build output
[12:30] <Laney> but the fact that it hung at the start of stage2, and took so long, led me to that conclusion
[12:30] <Laney> it has also been tried and aborted several times before on different buildds
[12:30] <persia> I don't think there's any real difference between the buildds.
[12:37] <sistpoty|work> Laney: *nod*, makes sense
[12:40] <sistpoty|work> Laney: maybe we should retry again? there's a newer eglibc available that includes an arm specific change
[12:40] <Laney> sistpoty|work: a local test build would probably be a better use of resources
[12:41] <sistpoty|work> Laney: sure, but I don't have an arm box :/
[12:41] <pitti> apw: correct, it parses ubuntu/lucid/+specs
[12:44] <persia> 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] <sistpoty|work> persia: the debian build took at least 5 days. No clue about sleeping though
[12:45] <persia> 5 days!  Hrm.  Maybe I can do something.
[12:45] <sistpoty|work> persia: that would be awesome!
[12:46] <persia> What do you need?  Just confirmation success/fail?  A buildlog?
[12:46] <persia> Also, should I be able to build in a lucid pbuilder from jaunty?
[12:47] <sistpoty|work> persia: build log if it fails would be good, I guess. I think building from jaunty should work. Laney, anything else?
[12:48] <persia> Laney: Also, does it still fail to configure in qemu?
[12:50] <Laney> sistpoty|work: should be fine indeed
[12:51] <Laney> persia: I don't know, and my PC has locked up again so I can't check until later
[12:51] <Laney> . o O ( I should debug that )
[12:52] <persia> 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] <directhex> is aptitude on lucid on amd64 broken for anyone else?
[12:55] <Laney> I guess you could also try to pbuilder-armel it too, persia
[12:55] <Laney> 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] <persia> 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.
[13:38] <kirkland`> cjwatson: okay, thanks for the heads up on libvirt/sparc
[14:11] <Keybuk> Dear Launchpad folks,
[14:11] <Keybuk> I want a button on a bug report.
[14:11] <Keybuk> Clicking this button should electrocute the original reporter.
[14:11] <pitti> "Please wait while bug data is processed"
[14:11] <Keybuk> Then bar them from ever making any status changes to any bug ever again.
[14:11] <Keybuk> if this could be automatic if someone changes a bug from the "Won't Fix" status, that would be AWESOME
[14:13] <persia> 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] <zul> mvo: ping
[14:13] <Keybuk> persia: there's nothing that makes it not possible
[14:13] <Keybuk> bug #535120
[14:23] <pitti> ogra: is bug 536670 what you see as well? i. e. do you have an unpartitioned device which doesn't automount?
[14:25] <ogra> pitti, hmm, i dont knoe if my reader is unpartitioned
[14:25] <pitti> ogra: my Sony PRS 505 is
[14:25]  * ogra has a TS 600
[14:25] <ogra> let me get it ...
[14:25] <pitti> ogra: well, if you get around to it in the next week or so, would be great to check (not that urgent)
[14:26] <pitti> 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] <ogra> ok, its unpartitioned .... funny though that they put two separate devices in instead of one with two partitons
[14:28] <ogra> pitti, partitioned USB keys work
[14:28] <pitti> ogra: thanks, so that seems to be your bug then
[14:29] <ogra> right, do you need a confirmation comment or anything ?
[14:29] <pitti> ogra: heh, mine has three - internal flash memory, SD card reader, and a proprietary sony card reader
[14:29] <pitti> ogra: no, I don't; if you are interested you can subscribe
[14:29] <ogra> yeah, mine has the readers too, but internally it also has two deviced
[14:29] <ogra> *devices
[14:29] <pitti> ogra: knowing that it's not yet something else which is broken is enough for me :)
[14:29] <pitti> thanks for checking
[14:29] <ogra> one with the windows SW i never use and one for the book db
[14:30] <pitti> ogra: oh, is that windows sw one readonly?
[14:30] <ogra> no idea i never looked at it :)
[14:30] <pitti> ogra: if that's useless under Linux, please feel free to file a bug against udisks to entirely ignore that one
[14:30] <pitti> (similar to all those rescure partitions, etc.)
[14:31] <pitti> 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> ogra@osiris:/var/build$ sudo mount /dev/sde /mnt/
[14:31] <ogra> mount: blockorientiertes Gerät /dev/sde ist schreibgeschützt, wird eingehängt im Nur-Lese-Modus
[14:31] <pitti> *nod*
[14:31] <pitti> so, ROM
[14:32] <ogra> but i dont know how to find out any additional info you could match on
[14:32] <ogra> it looks like a std scsi disk
[14:32] <pitti> ogra: ubuntu-bug storage
[14:32] <ogra> with it mounted ?
[14:32] <cjwatson> Keybuk: I have somebody spuriously setting newly filed bugs to Fix Released with no comment
[14:32] <pitti> ogra: actually, that's broken right now unfortunately (I just uploaded a fix, but it still needs to get published)
[14:32] <ogra> i'll do it later then
[14:32] <pitti> ogra: file it manually, plug it in, and attach the output of "udevadm info --export-db"
[14:33] <pitti> ogra: or that; I'll ping you again
[14:33] <Keybuk> cjwatson: that I wouldn't mind ;)
[14:33] <Keybuk> (assuming the someone is the reporter)
[14:34] <kirkland> pitti: bring it on!
[14:34] <cjwatson> Keybuk: nope, just some random person, and the bug was one I was in the middle of working on
[14:35] <pitti> Russian bug roulette?
[14:55] <JamieBennett> sistpoty, Laney: did you have a gh6 fix you wanted to test on ARM hardware?
[14:56] <sistpoty|work> 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] <JamieBennett> 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] <Laney> If you could do a test-build of ghc from Lucid and see if it succeeds, that would be cool.
[14:58] <Laney> And then if and when it starts looping at the stage2 build, poking around to see what is going on
[14:59] <didrocks> 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] <Laney> 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] <james_w> pitti: yes, that package failed to import a recent version
[15:01] <JamieBennett> didrocks:  I'm not sure, that would be one for mterry to answer
[15:02] <didrocks> mterry: ^ ?
[15:02] <JamieBennett> 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] <mterry> didrocks, huh.  probably NLE, but I can't give a 100% answer without grepping the code
[15:05] <didrocks> 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] <mterry> didrocks, ah neat
[15:05] <mterry> didrocks, will do, once i check in a bit
[15:05] <persia> Laney: At a high level, all the toolchain defaults differ, including the target ISA, which has a number of effects.
[15:06] <smoser> Keybuk, for bug 531494 i'll try to get you /var/log/udev . is there anything else that woudl be helpful ?
[15:07] <didrocks> mterry: sweet :)
[15:09] <Keybuk> smoser: a patch <g>
[15:12] <smoser> 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] <smoser> however, that is on a different UEC rig than i was seeing it on with 20100303
[15:41] <tkamppeter> pitti, hi
[15:53] <pitti> hi tkamppeter
[15:56] <Gemmazz> http://imgnow.info/DSC-1268236606.jpg does my ass look big?
[15:57] <tkamppeter> pitti, have you seen that I have SRUed bug 293832?
[15:58] <pitti> tkamppeter: I'll get to SRU this week, then I'll process it
[15:58] <tkamppeter> pitti, OK.
[16:00] <sistpoty|work> kees, doko: just looking at bug #438876, might this be a problem with gcc-4.4 and stack-protector on sparc?
[16:00] <sistpoty|work> kees, doko: erm, actually bug #534459, sorry
[16:06] <Keybuk> I need to write a small C program that sets the current console back to KD_TEXT and VT_AUTO, etc.
[16:07] <Keybuk> either that, or remember to keep X running and chvt to that
[16:19] <psusi> 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] <cjwatson> psusi: definitely not!
[16:20] <cjwatson> psusi: that would suck differently
[16:20] <psusi> why?
[16:20] <cjwatson> I don't have time to explain, sorry
[16:20] <cjwatson> in a meeting
[16:20] <cjwatson> suffice to say I would absolutely veto that change
[16:21] <psusi> 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] <cjwatson> false.
[16:21] <cjwatson> pretty sure we configured grub legacy essentially the same way.
[16:21] <psusi> really?  hrm... maybe it was just me then since I've always had an unusual config due to fakeraid ;)
[16:22] <psusi> 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] <cjwatson> totally unreliable
[16:24] <psusi> how so?  as long as the core file isn't moved...
[16:24] <cjwatson> 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] <cjwatson> upstream have deprecated this and for good reason.
[16:25] <cjwatson> and it isn't just defrag
[16:25] <psusi> resizing the partition then I guess could do it as well
[16:25] <cjwatson> http://grub.enbug.org/BIOS_Boot_Partition
[16:25] <cjwatson> (that focuses on GPT, but the section on blocklists is generally applicable
[16:25] <cjwatson> )
[16:26] <psusi> yea, that's nice for GPT, but we aren't talking about people using GPT ;)
[16:26] <cjwatson> psusi: please read what I just said!
[16:26] <cjwatson> "the section on blocklists is generally applicable"
[16:28] <psusi> 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] <cjwatson> *blink* how about the way our installer automatically resizes things to make room? :-)
[16:29] <cjwatson> also, I'm just not seeing the number of issues you refer to
[16:29] <cjwatson> they're dwarfed by other things
[16:29] <psusi> it automatically resizes windows partition to make room for Ubuntu...
[16:29] <cjwatson> you haven't looked at the code, obviously :)
[16:29] <cjwatson> it doesn't care whether it's Windows
[16:30] <psusi> well I see a lot of people complaining about bug #441941
[16:30] <psusi> well yea, I suppose if you install a new version of Ubuntu it would shrink the old partition
[16:30] <cjwatson> I think that's specialised, it doesn't seem to hit everyone
[16:30] <psusi> of course if you do that, then you'd re install the mbr after the resize anyhow so no problem ;)
[16:31] <cjwatson> and that bug is unusable anyway, it's full of conflicting comments and invective
[16:31] <cjwatson> so meh
[16:31] <psusi> yea, just hits a lot of people with HP and Dell PCs ;)
[16:31] <cjwatson> I ignore bugs that are full of people ranting :)
[16:31] <cjwatson> it's not worth the energy usually
[16:31] <psusi> that's what I figured was going on
[16:32] <cjwatson> and I do think it should be fixed in the other software
[16:32] <cjwatson> since it doesn't actually seem to be Windows itself doing it
[16:32] <psusi> but after spending time reading through there, and a thread or two on the forums, it seems that this effects a fair number of people
[16:32] <james_w> JFo: have you had a launchpadlib script get a little to eager with its tagging?
[16:32] <cjwatson> seriously.  I'm not going to stop using the embedding area.  other changes may be possible, but please give that one up
[16:33] <psusi> sure, but if we could easily fix it by not using the embed area...
[16:33] <cjwatson> no.
[16:33] <cjwatson> I'm not going to keep on repeating myself here - that would break other things and I won't do it
[16:33] <psusi> what use case do you see that causing a problem?
[16:33] <cjwatson> sorry.
[16:33] <cjwatson> we're going round in circles.
[16:33] <tseliot> slangasek: do you mind if I bump the plymouth version to 0.8.0~-13 and upload my changes to both Lucid and the bzr branch? Or do you have something else to add?
[16:34] <psusi> you  mentioned installing a new ubuntu which would resize the partition, but that also reinstalls grub, so no problem
[16:34] <slangasek> tseliot: there are pending changes from Keybuk, you should talk to him
[16:35] <tseliot> slangasek: will do, thanks
[16:35] <cjwatson> psusi: as the upstream wiki page points out, even aggressive fsck changes can break it
[16:35] <slangasek> tseliot: also, yes, I do mind bumping to "-13" when this is not a Debian package and Debian is packaging it separately
[16:35] <cjwatson> psusi: I simply don't want to have to deal with that kind of problem
[16:35] <psusi> hrm...
[16:36] <slangasek> and I will continue to let 'dch' DTRT whenever I'm uploading plymouth
[16:36] <tseliot> slangasek: even if I have a new png logo?
[16:36] <cjwatson> it may be that simply having a bigger embedding area would deal with it, and we'll be doing that by default in lucid anyway
[16:36] <cjwatson> (it's not in place yet)
[16:36] <slangasek> tseliot: Ubuntu uploads should use Ubuntu version numbers; right now we're clobbering the Debian version numbers
[16:36] <psusi> eh?  what do you mean?
[16:36] <tseliot> slangasek: do they really have plymouth in Debian?
[16:37] <slangasek> tseliot: yes, of course, and even if they didn't we should still be using -0ubuntuN
[16:37] <psusi> as in have the resize stage also move the start of the windows partition further down the drive than sector 63?
[16:37] <slangasek> but I expect plymouth to take over the boot splash space in Debian just like it's doing everywhere else
[16:37] <Keybuk> slangasek: no they shouldn't :)
[16:37] <Keybuk> Ubuntu uploads of packages that were made for Ubuntu by Ubuntu should be -N :p
[16:38] <cjwatson> oh, if Windows is already installed - well, even then, recent versions of Windows tend to align themselves to 1MB start positions
[16:39] <Chipzz>   
[16:39] <cjwatson> I apologise for saying that GRUB Legacy used the embedding area too - looks like I was wrong there
[16:39] <cjwatson> but the alternative with GRUB 2 is not the same as the way GRUB Legacy worked
[16:39] <psusi> yea, I thought you had to explicitly throw the --stage1.5 flag when installing it ;)
[16:40] <psusi> it isn't?
[16:40] <cjwatson> or at least not quite
[16:40] <cjwatson> I don't think so.  But honestly the alternative sucks so much I haven't put lots of time into investigating it
[16:41] <cjwatson> and if I do it, upstream will probably refuse to support me :)
[16:41] <slangasek> Keybuk: I know that's the rule you use, but all that does is make it harder to get in sync with Debian later and works against tools like dch
[16:41] <cjwatson> which matters too ...
[16:41] <Keybuk> slangasek: we don't always want to be in sync with Debian
[16:42] <psusi> what if we created an actual tiny partition to hold the core by default?
[16:42] <slangasek> Keybuk: that's no reason to preclude trying to minimize the delta with Debian for packages that aren't Ubuntu-specific
[16:42] <Keybuk> slangasek: there can be lots of reasons
[16:42] <Keybuk> for a start, anything at the boot level is wildly different anyway
[16:43] <Keybuk> anything we've packaged ourselves based off upstream - it's going to be easier for us to keep basing off upstream
[16:43] <slangasek> I don't agree with that
[16:43] <slangasek> there are many things that have been packaged first in Ubuntu that core maintenance has moved to Debian afterwards, to save effort
[16:43] <cjwatson> that might work (although has some other problems)
[16:44] <Keybuk> slangasek: such as?
[16:44]  * _UsUrPeR_ tips his hat
[16:44] <Keybuk> initramfs-tools has been harder to maintain as a result of trying to recognise Debian as an upsteam
[16:44] <cjwatson> the obvious source of breakage there is BIOSes that can't read past a certain limit, so putting the GRUB code at the very start of the disk is strongly advantageous
[16:44] <psusi> aside from using up another partition table entry?
[16:44] <_UsUrPeR_> Can anybody describe the process of adding a network driver to the 9.10 installation CD? I already have the CD on a writable USB key, so I can make changes to the image. The undetected ethernet card is a  Atheros AR8132 / L1c Gigabit Ethernet Adapter
[16:44] <cjwatson> in fact that's a case you break by putting GRUB code in the partition, too, since Windows is typically preconfigured to occupy a huge whack of space right at the start
[16:45] <psusi> true, but I don't think any computers younger than... 10 years now?  have that issue
[16:45] <cjwatson> initramfs-tools has mostly been hard to maintain as a result of doing a bad job of trying to recognise Debian as an upstream ...
[16:45] <cjwatson> psusi: I got a bug about that just last week
[16:46] <cjwatson> so don't tell me it doesn't exist :)
[16:46] <cjwatson> you'd be amazed at how broken even quite new BIOSes can be
[16:46] <Keybuk> cjwatson: mostly because we tend to disagree with the Debian maintainer on his changes
[16:46] <cjwatson> I thought the same as you until I started hearing from reality
[16:46] <psusi> wow
[16:46] <cjwatson> I was disappointed
[16:46] <slangasek> Keybuk: I'm not going to trawl changelogs for examples; they're out there, and boot-related or not, I don't see why plymouth should wind up in the same bucket as udev in terms of Debian collaboration
[16:47] <psusi> such a computer though would only succesfully boot windows by luck
[16:47] <psusi> since windows typically also puts its loader in a single full disk filesystem
[16:47] <Keybuk> slangasek: udev is a good example of Debian collaboration?
[16:47] <Keybuk> Marco and I get on very well
[16:47] <cjwatson> psusi: no - it generally jumps to somewhere pretty early in the partition, and then ignores the BIOS from then on
[16:47] <cjwatson> AFAICT
[16:48] <Keybuk> by packaging separately based around a common upstream code, we don't have conflicts
[16:48] <cjwatson> there may be some luck involved, but people seem to generally get the good bit of it
[16:48] <slangasek> Keybuk: no conflicts, and no capacity to use any of the UDD tools for sharing packaging, either?
[16:48] <Keybuk> slangasek: this hasn't proved to be a problem
[16:49] <slangasek> you never have conflicts if you never merge :)
[16:49] <psusi> the mbr jumps to the boot sector, which then has to use the bios to read the MFT to find NTLDR and then load that... then NTLDR continues to use the bios to access the disk in typical installations until it loads the kernel and passes control to that
[16:49] <Keybuk> by not sharing the packaging, we've worked to minimise it
[16:49] <Keybuk> so we carry no patches
[16:49] <Keybuk> instead everything is done upstream
[16:49] <psusi> so if the kernel happens to he stuck on a high sector of the disk the broken bios couldn't access, windows would fail to boot
[16:50] <cjwatson> that may be true, but I wouldn't hear the complaints about Windows breaking, I only hear the complaints about Ubuntu breaking
[16:50] <psusi> heh..
[16:50] <Keybuk> slangasek: and, frankly, this works both ways
[16:51] <Keybuk> I would begin a discussion about why Debian didn't base their plymouth packages off ours
[16:51] <Keybuk> and why they aren't collaborating with us
[16:51] <Keybuk> why their package isn't -XdebianY based off ours
[16:51] <Keybuk> and I would argue that the fault is theirs, not ours
[16:52] <Keybuk> and I do acknowledge and respect that there are those within Ubuntu with a more pro-Debian stance than me <g>
[16:52]  * psusi wonders if windows 7 can boot from GPT disks... then we could use the damn bios partition
[16:52] <Keybuk> but I don't think my "Ubuntu can be separate from Debian" stance is any less valid
[16:52] <Keybuk> it's just in a different bit of the room ;)
[16:53] <statik> hi chrisccoulson, ken pinged me about bug#536737. the debdiff looks good to me, but he wanted me to get a testing ack from you before uploading.
[16:53] <Keybuk> personally, I'd prefer it if "packaging" just went away
[16:53] <Keybuk> and upstream sources could include "this is how you build it" meta-rules
[16:53] <Keybuk> so all you add as a distribution is things that are unique to your distribution
[16:53] <chrisccoulson> statik - cool, i'm just testing it quickly now
[16:54] <Keybuk> (and Ubuntu and Debian can be quite different - especially in areas I've touched <g>)
[16:54] <chrisccoulson> statik, will you be ok to upload that, or do you want me to?
[16:54] <psusi> oh well, at least I successfully got grub2 working last night for the first time... even got it to boot the system in an lvm root and no other /boot... even got it to boot from a snapshot I made then upgraded to lucid in it ;)
[16:55] <slangasek> Keybuk: "why their package isn't -XdebianY" - because it's not meant to be about props for whose package was first, it's meant to be about having a consistent model for collaboration between Debian and Ubuntu so that other Ubuntu devs can look at a package without going cross-eyed at the equivalent of a criss-cross merge :)
[16:55] <statik> chrisccoulson: oh, I thought you needed me to do the upload. I don't mind either way, if you have permissions no reason for me to do it.
[16:55] <psusi> lvm on top of dmraid no less...
[16:56] <slangasek> the Ubuntu toolchain works great for -XubuntuY, and suboptimally when you use -X for Ubuntu stuff; the Debian toolchain works not at all for -XdebianY
[16:56] <chrisccoulson> statik, yeah, i think i've got permissions to upload that
[16:56] <Keybuk> the Ubuntu toolchain works just fine?
[16:56] <Keybuk> since most packags I touched are -X :p
[16:56] <slangasek> it works to *your* satisfaction
[16:56] <statik> chrisccoulson: excellent. thanks! ping me if it turns out you need me to do anything with it. thanks for your work on this.
[16:56] <slangasek> I gather you don't use 'dch', for starters :)
[16:56] <Keybuk> I do use dch
[16:57] <slangasek> to autoincrement changelog version numbers?
[16:57] <chrisccoulson> statik - no worries. micahg should probably take the credit though :)
[16:57] <statik> indeed
[16:57] <Keybuk> slangasek: yes
[16:57] <Keybuk> slangasek: if you look through dch's own changelog, you'll see I even fixed dch so this was possible on ubuntu packages <g>
[16:57] <pitti> hm, I alwasy have to use -U for that when working on Debian packages
[16:58] <Keybuk> actually, that's a reasonable point
[16:58] <Keybuk> dch fails here for working on Debian packages while running Ubuntu :p
[16:58] <pitti> (but on a tangent, yay for consistent versioning and XubuntuY)
[16:58] <slangasek> Keybuk: so you pass the extra argument every time you work on an Ubuntu package that's versioned as -X?  That's the kind of state I think we shouldn't have to keep track of :)
[16:59] <Keybuk> it WFM
[16:59] <slangasek> Keybuk: so anyway!  how's plymouth coming? :-)
[17:00] <Keybuk> slangasek: I've not been able to do anything on it for a while, because someone's complaining about the versions I use ;)
[17:00] <slangasek> you didn't have to take the bait ;)
[17:00] <Keybuk> yes I did <g>
[17:01]  * stgraber hears about plymouth and goes to look at his pet bug (though more likely to be cryptsetup's fault)
[17:02] <Keybuk> stgraber: which one?
[17:02] <stgraber> bug 509487
[17:02] <slangasek> the "when I type my passphrase, my laptop goes into a tailspin" one
[17:03] <stgraber> slangasek: yeah, that one ;) though seems like I could provide more info to help debugging it. I'll need to reboot my laptop at some point ... two weeks I didn't reboot.
[17:03] <Keybuk> says it fixed :)
[17:04] <slangasek> Keybuk: the task on cryptsetup is still open
[17:06] <Keybuk> I can solve that, through an accident in the archive
[17:15] <_UsUrPeR_> How do I add network drivers to a ubuntu alternate install CD? The network driver (atheros on a new Acer netbook) is not being detected by the 9.10 alternate install CD, and because of that, I cannot install with a preseed.cfg over my local network.
[17:15] <_UsUrPeR_> There is no need to discuss the process of managing an .iso, I can figure that out myself. Where do I put the drivers on the CD to have them loaded during the detection process?
[17:38] <amitk> \sh: were you able to look at your LVM problem again?
[17:39] <\sh> amitk: nope...but I think bug #527666 is exactly that...
[17:39] <amitk> Keybuk: ^^^
[17:39] <Keybuk> amitk: --debug would be nice
[17:39] <\sh> amitk: sadly it was "incomplete", but reporter got down to the problems....and I set it to confirmed
[17:41] <\sh> amitk: but you say, that update-initramfs fixes that boot problem?
[17:42] <amitk> \sh: I thought it did. But now the problem is back. IOW, I booted completely once but it could be a red herring
[17:42] <amitk> Keybuk: --debug of what?
[17:43] <Keybuk> mountall
[17:44] <\sh> Keybuk: help me with the --debug upstart bootmagic or whatever you need
[17:44] <Keybuk> ?
[17:44] <\sh> Keybuk: I'll just have a clean lucid server installation here...where I can create some nice VGs +
[17:45] <Keybuk> the usual thing
[17:45] <Keybuk> add --debug to mountall, capture output
[17:48] <\sh> no update-initramfs or some other magic?
[17:50] <Keybuk> no
[17:51]  * \sh waits for the latest updates
[17:52] <\sh> Keybuk: mountall logs where when --debug enabled?
[17:53] <ogra> \sh, you will see where it logs :)
[17:53] <\sh> let me guess...console? which means some redirection needs to be done...
[17:54] <ogra> (so better also pipe it to a file when adding --debug)
[17:54] <Keybuk> \sh: pipe to /dev/kmsg and use netconsole
[17:54] <\sh> ogra: done ;)
[17:54] <ogra> but that might be tricky since it remounts stuff
[17:54] <Keybuk> (is my favourite trick)
[17:55] <ogra> we should just all switch to ARM :) serial consoles everywhere !
[17:58] <\sh> ok...my machine sits somewhere 50 meters away...damn..why me ;)
[17:59] <ogra> then you need longARM :)
[17:59] <highvoltage> heh
[18:00] <\sh> anyways..I'm admin...it must be easy ,-)
[18:00] <\sh> reboot
[18:01]  * \sh runs
[18:03] <JFo> james_w, I did :)
[18:04] <JFo> working on it now
[18:04]  * JFo wipes the grease off his hands and gets back to it
[18:09] <\sh> hmmm
[18:09] <\sh> amitk: it works now
[18:09] <amitk> \sh: what did you do?
[18:10] <amitk> I've been distracted with other things
[18:10] <\sh> amitk: I installed the new updates...something changed
[18:10] <\sh> now ssh is broken lol
[18:11] <amitk> heh
[18:13] <\sh> junior admin set two default gateways
[18:14] <amitk> redundancy, you know :)
[18:14] <\sh> well, yeah...but without policy routing ==> failed
[18:14]  * ScottK hands \\sh http://bofh.ntk.net/Bastard_Indexes.html for inspiration about how to "counsel" the admin in question.
[18:15] <\sh> ScottK: he won't get his after work beer...that's punishment enough ;)
[18:15] <Daviey> I assumed amitk was refering to a different type of redundancy, for the junior sysadmin. :)
[18:15] <\sh> anyways...there was now initramfs-tools update and a kernel update and a mountall update as it seems
[18:16] <\sh> now which package could fixed that problem
[18:16] <hggdh> pitti: could you please look at bug 442272 and suggest me who to contact?
[18:17] <\sh> the VG + LV wasn't created before the dist-upgrade...so I'm sure, that somehow someone fixed the bug without knowing
[18:18] <pitti> hggdh: hm, at first sight this looks like a glibc bug
[18:18] <\sh> amitk: did you dist-upgrade your machine regualary?
[18:19] <hggdh> pitti: yes, this is what I think. But I cannot find any hits on the glibc BTS, nor on SUSE and Fedora
[18:20] <amitk> \sh: not since the weekend
[18:20] <\sh> amitk: can you try now?
[18:21] <amitk> \sh: as soon as I can edit /root/etc/fstab from initramfs, /root being mounted read-only and not permitting me to remount it as rw
[18:21] <\sh> amitk: rescue system from cd ;)
[18:22] <amitk> i guess
[18:25] <\sh> dear google, please provide android sdk for x86_64, because running sun-java6 in ia32 mode does work, but is no fun and I could write my fai frontend also for android, to deploy servers via nexus one while train hopping, kthxbye ;)
[18:29] <\sh> amitk: when you tested it again, please comment on bug #527666 ... so we can track this in one place
[18:29] <amitk> will do
[18:30] <\sh> uh oh...junior admin got orders by senior network admin to do cisco ASR configuration on production machines...I'm not sure that this was a wise decision ;)
[18:30] <highvoltage> lamont: hi there. bug 531546 is becomming quite critical as time runs short, and you seem to be the only one who can help with it
[18:34] <_UsUrPeR_> How do I add network drivers to a ubuntu alternate install CD? The network driver (atheros on a new Acer netbook) is not being detected by the 9.10 alternate install CD, and because of that, I cannot install with a preseed.cfg over my local network.
[18:34] <_UsUrPeR_> the network card is an atheros AR8132 gigabit ethernet card.
[18:40]  * Keybuk had an evil moment
[18:40] <Keybuk> I wrote a text plugin for plymouth that looks a bit like our graphical one ;-)
[18:40] <Keybuk> the colours match and *everything* :p
[18:41] <amitk> \sh: still doesn't work. It got past the first filesystem and got stuck on the second one
[18:41] <highvoltage> rhmm? as in aalib'd?
[18:41] <Keybuk> highvoltage: no, just "ubuntu" written in the ordinary console font
[18:41] <sebner> Keybuk: you are satan! :P
[18:42] <Keybuk> it means if you have to use text, you're still purple! :D
[18:42] <sebner> lol
[18:42] <Keybuk> of course
[18:42]  * highvoltage has to constantly work hard at not making references to sexual frustration
[18:42] <Keybuk> one slight issue is that the default consoles turn purple too
[18:42] <slangasek> Keybuk: but does it pick the color automatically from the image?
[18:43] <Keybuk> so you have the whole Ubuntu 10,04 login: thing in purple
[18:43] <_UsUrPeR_> ok, I have to ask, I have not really gotten much of a response to my question. Am I inquiring about driver support in the wrong place?
[18:43] <Keybuk> so I must make sure sabdfl never sees that, or he'll want it by default <g>
[18:43] <highvoltage> you realised you just highlighted him :)
[18:43] <Keybuk> slangasek: there is no image!  It's a hex value tseliot hardcoded into the script plugin
[18:43] <Keybuk> highvoltage: yes :p
[18:43] <slangasek> Keybuk: hah
[18:43] <amitk> Keybuk: purple console can't be that bad, considering our terminals in X are all purple now :-/
[18:43] <slangasek> Keybuk: ok :)
[18:43] <_UsUrPeR_> can you guys see what I am typing?
[18:44] <highvoltage> _UsUrPeR_: no
[18:44] <Keybuk> _UsUrPeR_: no, try typing in a larger font
[18:44] <cjwatson> _UsUrPeR_: I can see, but haven't had time to answer
[18:44] <_UsUrPeR_> ok, no problem. I just noticed I was not authenticated.
[18:45]  * Keybuk never knew you could change the actual colours of the Linux VT to whatever rgb values you liked
[18:45] <Keybuk> I always thought they were fixed
[18:45] <cjwatson> _UsUrPeR_: it's easiest to look into the build system in debian-installer, which has lots of hooks for things like copying in extra files.  If you 'apt-get source debian-installer', look in build/README
[18:45] <_UsUrPeR_> cjwatson: thank you so much. I'll look in to that now.
[18:46] <\sh> amitk: ok...then there is another problem...for me it didn't work even with a partition != /home or whatever essential
[18:48] <amitk> \sh: exactly, I have 3 volumes on that disk. /home, /shared, /private listed in that order in fstab. Sometimes it gets past home but gets stuck at shared
[18:48]  * amitk calls it a night. Will debug tomorrow
[18:50] <\sh> amitk: have a good night :)
[18:53] <psusi> Keybuk: colors?  hell, I remember years ago on slackware 2 or 3 I used some utility to load a new font into the vga character generator for the console.. come to think of it, it was a pretty bad ass looking font... which I could find it again these days...
[18:56] <Keybuk> http://people.canonical.com/~scott/purple.py
[18:56] <Keybuk> ^ run as root on your console ;-)
[18:56] <Keybuk> psusi: cjwatson likes loading silly fonts and keymaps on consoles
[18:57] <psusi> I guess these days we have the fancy graphics mode consoles makes it easy
[18:58] <Keybuk> there's probably a much easier way to do that, of course
[18:58] <Keybuk> but it has amused me
[18:58] <psusi> although slow as hell
[18:59] <psusi> whenever I've tried mucking with the graphic consoles it has always been slow anyhow... that was the nice thing about the old method of doing it... since it still had the video card in text mode, there was no slow down
[19:01] <Keybuk> yeah, fbcon is much slower than vgacon
[19:01] <Keybuk> I'm surprised that nobody has done much work towards just using vte there
[19:02] <Keybuk> then you could have pango-rendered anti-aliased fonts on your framebuffer
[19:03] <\sh> Keybuk: implement this in lucid+1 , make it mature for the next LTS...and linux is ready for the desktop ,-)
[19:03] <slangasek> this is akin to "I'm surprised the Libertarians don't hold the majority in Congress", right?
[19:04] <slangasek> "wow, the craziest thing I can imagine is crazier than the world actually is"
[19:04] <Keybuk> why crazy?
[19:04] <Keybuk> we could get rid of vgacon, fbcon, etc.
[19:04] <Keybuk> and a whole world of kernel code hurt
[19:04] <\sh> dear linus, please remove console code from kernel, we don't need it
[19:04] <Keybuk> shifting all worrying about such things to userspace
[19:04] <slangasek> pango as a prerequisite for console output? :)
[19:05] <psusi> someone asked on the forums the other day about the ability to do something akin to windows restore points and that got me thinking, so I've been looking into using lvm snapshots to time machine the entire system state for possible rollback... and I read that another distro is planning on using btrfs for this.. has anyone else done any work in this area?  are there any plans to for luicid+?
[19:05] <Keybuk> slangasek: I think pango should be a prerequisite for everything!
[19:05] <Keybuk> psusi: it's the kind of thing we could use btrfs for, yes
[19:06] <Keybuk> I suspect our "plans" are much the same as other distro
[19:06] <slangasek> pango-breaded chicken strips
[19:06] <Keybuk>  1. wait for btrfs to be ready
[19:06] <Keybuk>  2. wait for btrfs to be stable
[19:06] <Keybuk>  3. wait for btrfs to be documented
[19:06] <Keybuk>  4. ...
[19:06] <elmo> 5. profit
[19:06] <\sh> 3. use ZFS when oracle releases it as GPL
[19:06] <Keybuk> \sh: btrfs is "better" than ZFS
[19:06] <psusi> I'm trying to figure out which is better, use btrfs, or lvm snapshots with whatever fs you want
[19:06] <slangasek> everything's better with btr
[19:07] <cjwatson> but ZFS is released by Sun, it must be perfect
[19:07] <\sh> Keybuk: somebody said this pointing to  reiserfs too
[19:07] <Keybuk> \sh: btrfs borrows some things from reiser
[19:07] <Keybuk> but not the murdering and killing
[19:07] <elmo> I can't believe it's not btrfs
[19:09] <\sh> Keybuk: that's the problem I think...reiserfs was really a pain to recover it by ontrack in the early days
[19:09] <Keybuk> reiserfs lies about where it puts the bodies of your files
[19:09] <psusi> last night I managed to use an lvm snapshot to clone the root, boot using the clone, then upgrade to lucid and could reboot into either the original fs or the now lucid snapshot... it seems though that the ability to merge the snapshot back into the original fs and discard the old system just went into the upstream kernel in .33, which doesn't look like it's going to make it into lucid
[19:10] <\sh> good...now for some fun...having a burger and some beer...and tomorrow again a nice nightshift
[19:10] <sebner> Keybuk: I somewhere read that btrfs will be usable (not that unstable anymore) with 2.6.34 or 2.6.35. Do you have any info on that?
[19:11]  * \sh 's gone
[19:11] <sebner> \sh: hf
[19:11] <cjwatson> sebner: the warning sign is when you keep reading things like that, but the numbers keep changing
[19:11] <sebner> heh
[19:11] <Keybuk> sebner: right, I'll wait until they say "btrfs is usable"
[19:11] <Keybuk> or, more to the point
[19:12] <sebner> cjwatson: it didn't change from 34 to 35 but was explicitely said that way
[19:12] <Keybuk> I'll wait until Linus says "I've been using btrfs for a while now, and I haven't killed the maintainer for destroying my filesystem"
[19:12] <psusi> lol
[19:12] <cjwatson> sebner: you say this as if this is the first time somebody said "btrfs will be usable with 2.6.<foo>"
[19:12] <sebner> Keybuk: kk, so I just thought about offering a possibility to use it as filesystem (maybe with ubuntu 10.10 or 11.04) like we did with ext4
[19:13] <sebner> cjwatson: As this was the first time I read that, yes ;)
[19:13] <sebner> cjwatson: that's under the category of "lack of information" then :P
[19:13] <cjwatson> http://kitenet.net/~joey/blog/entry/aloha_btrfs/ somewhat related
[19:13] <psusi> that reminds me... I need to dust off the old e2defrag code and see if I can update it to work on ext4
[19:13] <siretart`> sebner: AFAIUI, it is already usable for some cases, but has some obvious annoyances. e.g. the disk usage is notoriously wrong, and you'll get occasionally 'disk full' even when there is still plenty of space on the hard drive
[19:18] <sebner> siretart`: that's why I asked about the .34-.35 stuff as there is should be really *usable*
[19:18] <sebner> cjwatson: well right but this isn't the same like ext4 where Tso said "I used it the past 6 months without problems"
[19:27] <kees> doko: for gcc -m32 I use gcc-multilib.  this package doesn't exist on dapper; what should I be using there?
[19:28] <kees> doko: ah, nm, libc6-dev-i386 seems sufficient
[19:36] <Laney> Right, I need help debugging a system lock up I get frequently on Lucid
[19:36] <Laney> It seems related to high load
[19:39] <Laney> magic sysrq still works, but nowt else
[20:48] <xnox> Best way to request rebuild of a few packages? (no source changes)
[20:48] <xnox> ^ What's the best way
[20:56] <slangasek> xnox: that probably depends on why the packages need rebuilt
[20:56] <slangasek> generally we only rebuild packages for library transitions or the like
[20:56] <xnox> It is library transitions
[20:57] <slangasek> it's probably best to coordinate directly with a developer on IRC for that; filing bugs would just be busy work.  What library?
[20:57] <xnox> I've filed bug #536869
[20:57] <xnox> It's libhdf5 and it affects a few packages
[20:58] <xnox> I've tested all the packages by rebuilding & testing them using lucid pbuilder and lucid installation
[21:00] <xnox> slangasek: I did send an email about it ~2 weeks ago do ubuntu-devel-discuss and I had no reply =(
[21:00] <xnox> should I create non-change source debdiffs?
[21:00] <slangasek> no
[21:01] <xnox> ok good (that seemed like duplication)
[21:02] <slangasek> note that rebuilds of packages that depend on out-of-date libraries are done as a matter of course across the release cycle anyway; I'll have a look at these and see about getting them rebuilt today
[21:03] <xnox> slangasek: Didn't know that. Thanks. But currently you can't install latest octave and any of these packages because of conflicting hdf5. =(
[21:03] <xnox> s/But/Note that
[21:05] <slangasek> erm, you really opened bug tasks against all the packages?
[21:06] <xnox> Yeah, kind off. It's a single bug which affects all of the packages
[21:07] <xnox> "meta-bug"
[21:08] <slangasek> developers typically wouldn't look for such bugs before doing no-change rebuilds :)
[21:09] <xnox> =) ok, fair enough. Is there a way for non developers to request no-chnage rebuilds similar to the scheduling of bin-nmu's in debian?
[21:09] <slangasek> not formally, no
[21:09] <slangasek> as I said, IRC is easiest
[21:10] <xnox> Ok I'll know in the future then. It's just I've seen OCmal transition done like that with "meta-bug" but then again that one must be done in 6 rounds
[21:11] <Laney> Previously I have just asked for them through the sponsor queue
[21:12] <xnox> =/ well I spent about 12 hours rebuilding all of them and testing the once I use / have clue about. So I did as much as could =)
[21:12] <slangasek> xnox: wasn't the ocaml transition mostly about syncs, rather than rebuilds?
[21:14] <xnox> slangasek: not sure. As far as I understand it has syncs & rebuilds =/ maybe I'm wrong I don't use ocaml.
[21:14] <slangasek> fair 'nuff
[23:00] <slangasek> xnox: second package on the list (gnudatalanguage) has unsatisfiable build-deps (libplplot-dev)
[23:01] <slangasek> xnox: so I wonder how you rebuild-tested this?
[23:06] <slangasek> things that don't belong in a package clean target:
[23:06] <slangasek> Downloading http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c9-py2.6.egg
[23:17] <aliendude3500> Hi, I'm working on writing some code to make it easy to rearrange the title bar buttons for now users who don't feel like manually editing gconf settings. The code I have is written in Java, and works VERY well except for a slight bug that is preventing me from releasing the code. The application is able to generate the command to be ran as a String, and when I print the command to stdout, and run it manually, it
[23:17] <aliendude3500>  works PERFECTLY, however, I can't get the program to automatically run the program. I'm not sure what is wrong with my code, as I have done similar things in the past, and I was able to make java execute commands using Runtime.getRuntime().exec(command);, but it's not working in this case. Because this project is Ubuntu (and GNOME) specific at the moment, I thought I'd ask here to see if anyone knows what could
[23:17] <aliendude3500> be wrong. I'm almost positive it has to do with application permissions, but I tried signing the application, and even running it as root (Note: the command run by the program to change the title bar location does not need root permissions), but to no avail. I am open to suggestions.
[23:17] <crimsun> kees: ping, do you have a moment for private query?
[23:18] <kees> crimsun: sure, privmsg away
[23:18] <kirkland> slangasek: i'm trying to use status to programmatically determine if a service is running or not
[23:19] <kirkland> slangasek: evidently i can't op on the exit code of 'status foo' though
[23:19] <kirkland> ubuntu@aussie:~$ sudo stop eucalyptus
[23:19] <kirkland> [sudo] password for ubuntu:
[23:19] <kirkland> eucalyptus stop/waiting
[23:19] <kirkland> ubuntu@aussie:~$ status eucalyptus
[23:19] <kirkland> eucalyptus stop/waiting
[23:19] <kirkland> ubuntu@aussie:~$ echo $?
[23:19] <kirkland> 0
[23:19] <aliendude3500> The source code I have so far is located at: http://ad5300.pastebin.com/nSw80yTT
[23:19] <slangasek> kirkland: indeed; you'd have to parse the output
[23:19] <kirkland> slangasek: is that internationalized?
[23:19] <kirkland> slangasek: and is it intended to be?
[23:20] <slangasek> kirkland: dunno; you can LANG=C it if that's a concern
[23:20] <kirkland> slangasek: great, thanks!
[23:20] <kirkland> mathiaz: ^
[23:26] <cjwatson> aliendude3500: quoting in Runtime.exec() doesn't work the way you think it does - it doesn't do full shell quoting, it just parses things into words
[23:26] <cjwatson> ARGH
[23:29] <cjwatson> aliendude3500: quoting in Runtime.exec() doesn't work the way you think it does - it doesn't do full shell quoting, it just parses things into words
[23:29] <cjwatson> aliendude3500: you can see this if you write a small test case and run 'strace -f -etrace=exec' on it
[23:29] <cjwatson> Runtime.getRuntime().exec("ls \"foo bar\"");
[23:30] <cjwatson> turns into:
[23:30] <cjwatson> [pid 26481] execve("/bin/ls", ["ls", "\"foo", "bar\""], [/* 73 vars */]) = 0
[23:30] <aliendude3500> cjwatson, so how would I fix that?
[23:30] <cjwatson> aliendude3500: I'd recommend that you use the list syntax instead
[23:31] <cjwatson> so you'd have an array something like ["gconftool-2", "--set", "/apps/metacity/general/button_layout", "--type", "string", that_thing_you_build_up_with_minimize_etc]
[23:32] <cjwatson> note that you don't have any shell-style quoting in that array - it's important to understand that quoting is handled by the Unix shell, and when a program starts all it sees is an array of arguments with no quoting
[23:32] <aliendude3500> ah, I see, so I pass the arguments to exec as array elements?
[23:32] <cjwatson> right
[23:33] <cjwatson> if you need spaces in the arguments, you can just put them straight in there in a single element, no quoting required
[23:33] <aliendude3500> cjwatson, I'll try to get that working.
[23:33] <cjwatson> it's easier in some ways - I recommend using this form in any language when it's available, and these days nearly every language does have it available
[23:34] <cjwatson> re permissions, all you need is execute permission on gconftool-2, which will already be there
[23:34] <aliendude3500> does it automatically add spaces between arguments? or do I manually put those in?
[23:34] <cjwatson> spaces between arguments are also parsed by the Unix shell
[23:35] <cjwatson> so it doesn't add them, but it produces the same effect as if it did, if you see what I mean
[23:35] <cjwatson> when you do   ls "a b" c "d e"   ls is invoked with argc == 4 and argv == ["ls", "a b", "c", "d e"]
[23:37] <cjwatson> if you try to add spaces, those will show up in the arguments as if you'd quoted them, so you probably don't want to do that