[00:31] <ebroder> Is there any chance of seeing dpkg 1.15 merged into Karmic at this point, or is it too late in the release cycle?
[00:37] <ebroder> Anybody? I'd like to see the fix to Debian #476899 make it into Karmic, but I don't want to expend the effort if I'd be wasting my time
[00:38]  * ajmitch would probably ask again in a few hours when people are less likely to still be on their weekend
[00:38] <ebroder> Fair 'nuff
[00:39] <ajmitch> there's still a few weeks until feature freeze so it's far from impossible
[00:39] <TheMuso> Maybe another 10-12 hours at least, since the people who work on dpkg are in EU timezones.
[00:39] <ebroder> ajmitch: More than a few weeks; I just don't know what kind of special treatment dpkg gets
[00:39]  * ajmitch wouldn't really be willing to do that merge right now :)
[00:40] <ebroder> MoM says it's a small merge. Not convinced I believe it, but you know
[00:40] <ajmitch> I imagine that it'd probably be done inthe next week or so if it happens
[00:41] <ajmitch> last upload mentioned waiting for 1.15.1 in the changelog
[00:41] <ebroder> Oh, I missed that
[00:42] <ebroder> I guess I'll go ahead and file a merge bug, even if I'm not going to do the merge myself
[00:44] <andrew_sayers> FWIW, 1.15.3 will cause some heartache.
[00:44] <ebroder> how so?
[00:45] <andrew_sayers> Fixes bug #391165
[00:45] <andrew_sayers> I've spent a good portion of the past week reporting bugs in packages that will break when that goes through.
[00:45] <andrew_sayers> Take a look at https://bugs.launchpad.net/~andrew-bugs-launchpad-net - you can spot when I noticed this issue :)
[00:46] <ebroder> Ugh. Sounds like fun
[00:47] <andrew_sayers> Yeah, I had to download every .diff.gz to file all them :s
[00:47] <andrew_sayers> Anyway, those packages will break when 1.15.3 hits.
[00:47] <ebroder> Break as in fail to install?
[00:47] <andrew_sayers> Fail to build.
[00:47] <ebroder> Ok. That's slightly less concerning
[00:47] <andersk> Is someone aware that packages.ubuntu.com is only showing karmic packages?
[00:48] <andrew_sayers> packages.ubuntu.com is up?
[00:48] <ebroder> Yeah, but ==andersk on only showing karmic packages
[00:49] <andrew_sayers> Since it was down for almost 24 hours, I'm guessing it's been reformatted or something.
[02:35] <shaya> anyone have an issue w/ the firefox-3.5 segfaulting on startup in karmic?
[02:40] <billybigrigger> no probs with 3.5 yet
[02:41] <shaya> segfaulting for me on startup in libstdc++
[02:41] <shaya> installing dbg libs now
[02:41] <shaya> though very very large
[02:45] <shaya> I think I see the problem
[02:45] <shaya> libxul from 1.8 is being loaded
[02:47] <shaya> seems to be that eclipse pulls in the libxul (1.8) lib into /usr/lib/
[02:48] <shaya> firefox-3.5 (xul 1.9) then links against it
[02:48] <shaya> and boom crash
[02:48] <shaya> and removed and it works
[03:11]  * ccheney finds it interesting that twitter apparently can't handle over 18 tweets/s (reading article about MJ and Google)
[04:23] <icarus901> anyone getting signature validation failures when trying to pull security updates?
[04:23] <icarus901> no proxy here
[06:32] <dholbach> good morning
[06:50] <jumentous> hi anyone, i was looking for some help understanding anna and the install process, i realise this probably isn't the place but can someone point me in the right direction
[07:00] <superm1> hi pitti. i forgot to follow up. did jockey-text look sane, or did you want to see any other changes to it?
[07:01] <StevenK> Morning pitti
[07:01] <pitti> good morning
[07:01]  * StevenK blinks at how he misread superm1 saying hi pitti as pitti greeting the channel
[07:02] <pitti> hey StevenK :)
[07:02] <pitti> superm1: sorry, didn't get mailed about it, and didn't look over the weekend
[07:02] <ajmitch> hello pitti
[07:02] <pitti> superm1: I opened https://code.edge.launchpad.net/~superm1/jockey/jockey-text now as a reminder
[07:03] <StevenK> pitti: I had one dorky question about the MIRs for UNR -- does ubuntu-netbook-remix-default-settings really need an MIR given it's effectively a bunch of gconf defaults and some packaging around them?
[07:03] <superm1> pitti, no problems. just wanted to make sure i had some time later this week to sort out anything with it necessary.  switching a few things to depend on such changes and wanted to time it all right
[07:03] <superm1> thanks
[07:03] <pitti> StevenK: MIR bug/task, yes; wiki page for trivial packages, simple language bindings, etc., no
[07:04] <pitti> StevenK: for small packages, just have a quick look at the bugs in D/U
[07:04] <StevenK> pitti: Right, okay, so I'll leave the task in the bug alone, but I won't write an MIR for it.
[07:04] <pitti> StevenK: and such meta-packages don't generally require any effort at all, ubuntu-mir just has a quick look at the packaging
[07:04] <StevenK> pitti: And there is no task for the meta package (unr-meta), should I add one?
[07:05] <pitti> please
[07:14] <pitti> tkamppeter: bug 361772 confuses me; it went through a successful SRU, but people have still problems, and there are several open tasks; what's the status of this?
[07:32] <tkamppeter> pitti, I am looking through it currently to update the status. There were two situations how users could run into a Ghostscript upstream bug. One was fixed by the foomatic-db-engine SRU, the other gets fixed by the CUPS SRU of bug 382379.
[07:33] <tkamppeter> An additional measure to fix this problem is a change on the Ricoh family PPDs on the OpenPrinting web server which I did some weeks ago.
[07:33] <pitti> tkamppeter: I just moved cups/poppler to -updates, FYI
[07:34] <tkamppeter> pitti, Great. Thanks.
[07:38] <tkamppeter> pitti, I have updated bug 361772, marking the CUPS tasks as "Fix Released" and referencing to bug 382379.
[07:38] <pitti> tkamppeter: thanks
[07:39] <pitti> tkamppeter: the open ghostscript task is still valid then?
[07:43] <tkamppeter> pitti, yes. The upstream bug in Ghostscript is not fixed yet. We do not need to do an SRU when the Ghostscript developers fix the problem, as the changes in foomatic-db-engine, in cups, and also automatic updating of PPD files of existing print queues in all printer driver packages prevent from the Ghostscript bug affecting any Ubuntu user.
[07:50] <ebroder> pitti: Just saw the build failures for xen-3.3 to karmic. I swear these built the last time I touched them :)
[07:50] <ebroder> I'll try to figure out what's up
[07:50] <pitti> ebroder: oops; thanks
[07:51] <ebroder> pitti: Do I bump the version number when the package FTBFS's?
[07:51] <pitti> ebroder: yes, you need to
[07:51] <pitti> and a new changelog
[07:51] <ebroder> Sure
[07:52] <ebroder> Oh, as in leave the ubuntu10 entry in there and add a separate ubuntu11 one with just these changes?
[07:52] <pitti> right
[07:52] <ebroder> Ok. Will do
[08:14] <StevenK> pitti: So, I'm happy to leave the tasks as New, should I set them to something else when I have the MIR attached to the bug report?
[08:14] <pitti> StevenK: that's fine
[08:15] <al-maisan> Moin pitti, how are you?
[08:15] <pitti> hey al-maisan; good, thanks!
[08:15] <pitti> and you?
[08:15] <al-maisan> pitti: not too bad :)
[08:16] <\sh> moins
[08:16] <al-maisan> pitti: I was wondering  what a "fake sync" is ..
[08:16] <pitti> al-maisan: ah, it's essentially: take our orig.tar.gz, apply the debian diff.gz, add a "-Xbuild1" changelog with "fake sync from Debian (different orig.tar.gz)"
[08:17] <al-maisan> pitti: I see .. thanks!
[08:18] <pitti> al-maisan: that's something mvo can do easily, not necessary to upload a patch or so
[08:18] <dholbach> al-maisan: it's cases where we can't sync because soyuz (and dak) already know a file named project_version.orig.tar.gz with a different md5sum
[08:18] <al-maisan> pitti: even better, the ball is mvo's court now :)
[08:19] <al-maisan> dholbach: gotcha!
[08:25] <ebroder> Hey pitti: Xen died because it's being built with -Werror and threw a bogus warning. How bad would it be to add a -Wno-error for that particular subdirectory?
[08:25] <pitti> ebroder: you can't fix the warning?
[08:25] <pitti> ebroder: no-error is fine for me
[08:26] <ebroder> I'm not seeing an easy way to fix the warning
[08:26] <ebroder> Ok, I think -Wno-error is the most straightforward fix, honestly
[08:27] <pitti> ebroder: calling memset with zero length?
[08:27] <pitti> that doesn't make sense
[08:27] <ebroder> Yeah. It's actually calling memset with sizeof(a_struct) where a_struct is an empty struct
[08:27] <pitti> what's the code doing?
[08:27] <pitti> ebroder: couldn't you just comment out that memset then?
[08:28] <ebroder> Hmm...I guess that wouldn't actually change anything...
[08:28]  * tjaalton hugs doko for the new eclipse :)
[08:31] <dholbach> pitti: sponsoring king! :)
[08:31] <pitti> dholbach: well, that's still you according to the statistics :)
[08:32] <dholbach> pitti: I just noticed that you're working on it right now
[08:32] <dholbach> and that's great :)
[08:32] <pitti> right
[08:33] <jamesh> pitti: do you how hard would it be to write a dh_shlibdeps style program if I've already got the logic to determine file dependencies?
[08:34] <pwnguin> new eclipse?
[08:34] <pitti> jamesh: what is a file dependency?
[08:34] <pitti> jamesh: in general, dh_* are pretty easy (just look at it, it's perl)
[08:35] <pitti> the dh lib does all the ground work for you already
[08:35] <jamesh> pitti: This is to try and automatically calculate dependencies for Erlang programs
[08:35] <pitti> jamesh: everything it needs to do is to set a dpkg variable ${your:depends} to the value you compute
[08:36] <jamesh> pitti: I did a proof of concept Python program that can scan the Erlang .beam files, determine what they import, scan the /usr/lib/erlang directory to find those modules and finally do "dpkg -S" to find the package names
[08:36] <pitti> jamesh: dh_shlibdeps is 88 lines of code, of which you can probably reuse most
[08:37] <pitti> jamesh: oh, that wouldn't be debhelper then, though
[08:37] <pitti> since that has to work at build time without all the (potetial) dependencies being installed
[08:37] <pitti> if you build-depend on them, it would work, of course
[08:38] <pitti> but then you already figured them out?
[08:38] <pwnguin> doko: excellent
[08:38] <jamesh> pitti: from the small sample of Erlang packages I've looked at, they generally build-depend on their dependencies
[08:38] <jamesh> I'm not sure if that's due to a requirement in the compiler or not though
[08:39] <pitti> jamesh: could be; for programs with test suites during build you also generally need them
[08:44] <jamesh> pitti: out of interest, if this job weren't being done by debhelper, what would do it?
[08:44] <pitti> jamesh: as I said, if the purpose is to fish out the three needed dependencies from your erlang-all-libs-meta package, dh is fine
[08:45] <pitti> jamesh: there is little precedent for figuring out dependencies which aren't installed by b-deps, I'm afraid
[08:46] <pitti> jamesh: for C programs, people generally determine build dependencies by a combination of reading configure.ac, READMEs, and try&error
[08:46] <ebroder> pitti: Should I open a new bug for the Xen FTBFS bug, or just attach it to the one with the ubuntu10 patch?
[08:46] <jamesh> pitti: I basically want something that will get correct minimal dependencies for binary packages and not break when the next upstream release comes out
[08:47] <pitti> ebroder: as you wish; reopen it if you do the latter
[08:47] <ebroder> *nods*
[08:47] <jamesh> (or reduce the set of dependencies if upstream drops a dependency)
[08:47] <pitti> jamesh: dh sounds fine then, if you assume that b-deps pull everything in that you potentially need
[08:55] <Guest53149> hi all
[09:07] <ttx> doko: I posted a workaround patch for the SHA384withECDSA ca-certificates-java issue on bug 392104.
[09:13] <cjwatson> ebroder: I have the dpkg merge half-done, just haven't quite got round to finishing it
[09:13] <cjwatson> ebroder: still intending to do it
[09:14] <ebroder> cjwatson: Great! I'll trust that you can handle it way better than I :)
[09:14] <ebroder> I'm not trying to pressure you or anything, I just was trying to poke around to see what the situation was
[09:15] <cjwatson> understood
[09:27] <doko> tjaalton, pwnguin: and I'm filing a bug report to remove this package again, because it does include a handful or more third party libs inside the eclipse package. if you want to keep eclipse, please fix these bugs, hint, hint ;)
[09:29] <ttx> doko: one issue is that the patched ca-certificates-java won't build in current karmic (with ca-certificates preventing ca-certificates-java to install as a build-dep)
[09:30] <lesshaste> hi.. I have a weird bug where after a poweroff (shutdown -h or shutdown -P) my laptop skips grub when it restarts but after a restart (shutdown -r) it doesn't
[09:30] <ttx> doko: so ca-certificates might need to be temporarily reverted first
[09:30] <lesshaste> the problem is that I am missing some key facts.. does jaunty have some script that kick starts the kernel super fast somehow? (kexec?)
[09:30] <lesshaste> that might be causing this
[09:30] <cjwatson> lesshaste: only if you have the kexec-tools package installed. Do you?
[09:31] <doko> ttx: yes, two ca-certificates upload (buildN) with the -java upload in between should work
[09:31] <lesshaste> cjwatson: I believe not
[09:31] <cjwatson> lesshaste: can you check, please?
[09:31] <lesshaste> cjwatson: locate kexec only shows files in the linux headers
[09:31] <cjwatson> dpkg-query -W kexec-tools
[09:32] <lesshaste> dpkg-query -W kexec-tools
[09:32] <lesshaste> No packages found matching kexec-tools.
[09:32] <cjwatson> ok
[09:32] <cjwatson> in that case, forget kexec, it's not your problem.
[09:32] <cjwatson> I have seen another bug report to this effect, but have no idea what could be causing it
[09:33] <lesshaste> cjwatson: so on a technical level, which part of the system could skip grub?
[09:33] <cjwatson> none that I'm aware of
[09:33] <cjwatson> you're sure the whole of grub is actually being skipped, and not just the grub menu?
[09:33] <lesshaste> no I am not sure but I can't find any useful logs
[09:33] <cjwatson> there won't be any
[09:33] <lesshaste> is there a way to turn on logging somehow for this?
[09:34] <cjwatson> no
[09:34] <lesshaste> hmm
[09:34] <cjwatson> what settings do you have for timeout and hiddenmenu in /boot/grub/menu.lst?
[09:34] <lesshaste> http://launchpadlibrarian.net/28500841/menu.lst is at https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/389930
[09:35] <lesshaste> it's also clearly assigned to the wrong place which doesn't help
[09:36] <cjwatson> no it's not, it just has a stray task on gnome-power-manager
[09:36] <lesshaste> it's assigned to grub now
[09:37] <cjwatson> it's assigned to grub *as well*. Launchpad bugs can have tasks on multiple places
[09:37] <lesshaste> umm.. hang on.. possible user error
[09:39] <ebroder> pitti: Fix for xen-3.3 is attached to bug #393376. I'll subscribe ubuntu-main-sponsors soon, but I want to at least pretend to test the resulting package before I do. Hopefully that'll be some time tomorrow
[09:39] <tjaalton> doko: where is the package developed?
[09:39] <tjaalton> doko: I mean the repository
[09:40] <tjaalton> doko: if there is one
[09:40] <lesshaste> cjwatson: sadly no user error :(
[09:40] <cjwatson> lesshaste: you could try pressing Escape at boot to see if that brings up the grub menu
[09:41] <cjwatson> lesshaste: other than that, I have no idea. sorry.
[09:42] <tgpraveen> hi i wanted to know will we get that delta debs feature in alpha 3 or 4?
[09:42] <tgpraveen> is any work being done on it. it would really make it easier for ppl like me on slow connection to help out in testing
[09:43] <chrisccoulson> hey cjwatson - i'm not sure if you saw my message the other day about your gnome-session issue
[09:44] <lesshaste> back in a moment
[09:44] <doko> tjaalton: I updated the packaging in the debian pkg-java repository
[09:45] <cjwatson> chrisccoulson: I did, but don't know what to say. It reproduces for me by calling the D-Bus RequestReboot() method in a live CD.
[09:45] <cjwatson> nothing special going on
[09:48] <chrisccoulson> hmmmm. that's strange. did you manage to test by running "gnome-session --debug" from a failsafe xterm, and redirecting the output to some permanent storage? the log may show what is causing it
[09:50] <tjaalton> doko: ah great
[09:50] <cjwatson> chrisccoulson: haven't yet, sorry
[09:51] <cjwatson> chrisccoulson: I'm rsyncing an updated image right now, will try after that
[09:51] <chrisccoulson> cjwatson - no problem. it will hopefully show what is going on :)
[09:54] <dupondje> pitti: availible ? :D
[09:54] <pitti> hi dupondje
[09:56] <lesshaste> cjwatson: ha! cracked at least some of it :)
[09:56] <dupondje> could u maby get the newest git from gvfs into repo's ? :P
[09:57] <pitti> dupondje: seb128 has an upload ready, I think
[09:57] <pitti> dupondje: at least for the latest release
[09:57] <dupondje> 1.3git20090512-0ubuntu2
[09:57] <dupondje> is newest
[09:58] <pitti> right, "upload ready" -> not uploaded yet
[09:58] <dupondje> oh ok :P
[09:58] <dupondje> cause mounting is broken :(
[09:59] <seb128> how broken?
[09:59] <dupondje> seb128: I subscribed you to the bug :)
[09:59] <lesshaste> cjwatson: are you still here?
[09:59] <seb128> I got over 300 emails yesterday I'm not read of reading yours
[09:59] <dupondje> seb128: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/393051
[10:00] <seb128> gvfs didn't change are you sure it's a gvfs bug?
[10:00] <cjwatson> lesshaste: yes. I was waiting for you to clarify your statement
[10:00] <seb128> anyway it's monday morning let's catch up with normal tasks before looking at cracky bugs
[10:00] <cjwatson> I didn't think I needed to say "go ahead" before you would ;-)
[10:01] <chrisccoulson> wasn't there a devkit-disks and gdu upload before the weekend? mounting seemed to break after that
[10:01] <dupondje> it was
[10:01] <seb128> chrisccoulson, read backlog?
[10:01] <dupondje> and it was a bug reported into gnome, and its fixed in the git atm
[10:01] <lesshaste> the laptop is a Toshiba,  after a poweroff and restart the Toshiba logo appears and then it goes straight to booting linux without seeing grub, however, it seems that grub is actually running during the part where you can only see the Toshiba logo!
[10:02] <seb128> we should forbid people to upload on friday afternoon ;-)
[10:02] <dupondje> check the bugreport, somebody applied the patch I mentioned, and it fixed it
[10:02] <lesshaste>  tested this by using the down arrow and pressing enter to boot into windows instead of linux.
[10:02] <dupondje> http://git.gnome.org/cgit/gvfs/commit/?id=384b3a679e3cf5138ada51338d613df517e0658a
[10:02] <seb128> dupondje, no need to check the bug, I've things ready on disk but that was the weekend and I don't work over the weekend
[10:02] <lesshaste> cjwatson: strange eh?
[10:02] <dupondje> :)
[10:03] <seb128> we should close the bug tracker during the weekends that would avoid being flooded while you take a break ;-)
[10:03] <dupondje> lol
[10:03] <dupondje> :)
[10:04] <dupondje> don't break anything !
[10:04] <dupondje> :D
[10:04] <chrisccoulson> seb128 - i'm sure users would find other ways to complain
[10:04] <seb128> not really "lo"l, it's stressful to start monday with 800 bug emails in your inbox
[10:04] <chrisccoulson> like e-mailing u-d-d
[10:04] <chrisccoulson> ;)
[10:04] <seb128> chrisccoulson, I'm used to ignore this list by now ;-)
[10:05] <lesshaste> cjwatson:  so whatever part of the system attempts to display to the screen preboot doesn't work after a poweroff (-P), but does work after a restart (-r)
[10:06] <cjwatson> lesshaste: may just be a broken BIOS then? dunno
[10:06] <cjwatson> I'm not likely to be able to fix it
[10:06] <cjwatson> best I can suggest is that you see if grub2 has the same symptoms
[10:08] <lesshaste> I'll update the bug report and hope someone reading it is interested
[10:09] <lesshaste>  what part of linux is running when the grub menu is showing?
[10:09] <cjwatson> no part of Linux is running.
[10:10] <cjwatson> GRUB's job in this context is to load Linux, therefore clearly Linux isn't running yet ...
[10:14] <lesshaste> cjwatson: yes of course.. that was a bit dim of me
[10:14] <lesshaste> cjwatson: so it really is a question of whether grub can fix whatever the bios has screwed up it seems
[10:14] <lesshaste> and grub is only supported grub2 these days :(
[10:14] <lesshaste> which isn't in jaunty
[10:15] <lesshaste> is there an easy way to upgrade to grub2 on jaunty?
[10:26] <pitti> mdz: did you actually commit your patch for bug 391021? I don't see it in trunk
[10:33] <cjwatson> lesshaste: see my mail to ubuntu-devel-announce a little while ago
[10:40] <pitti> james_w: hm, bzr bd -S just blew up for me, is that known? (trying to download upstream tarball) http://paste.ubuntu.com/206107/
[10:43] <pitti> jamesh: hm, same for bd-do (I now have the orig.tar.gz)
[10:44] <lesshaste> cjwatson: oh... let me check that
[10:47] <lesshaste> cjwatson: hmm.. choosing it chained won't actually test whether it can initialise the screen though will it
[10:49] <cjwatson> lesshaste: probably not
[10:49] <cjwatson> well, dunno
[10:49] <cjwatson> it'll probably try to initialise the screen whether it's chained or not
[11:01] <mdz> pitti, it is definitely committed
[11:01] <mdz> but is it pushed?
[11:02] <mdz> pitti, revno: 1476
[11:02] <mdz> committer: Matt Zimmerman <mdz@canonical.com>
[11:02] <mdz> branch nick: apport
[11:02] <mdz> timestamp: Tue 2009-06-23 10:53:14 +0100
[11:02] <mdz> message:
[11:02] <mdz>   Sort the list of dependencies so it's easier to scan (LP: #391021)
[11:02] <mdz>         checkout of branch: bzr+ssh://bazaar.launchpad.net/%7Eapport-hackers/apport/trunk/
[11:02] <pitti> mdz: weird, 1476 is "ui.py: Do not reject non-distro package reports if report sets CrashDB (for third-party destination). (LP: #391015)" for me
[11:03] <pitti> mdz: see http://bazaar.launchpad.net/~apport-hackers/apport/trunk/changes
[11:03] <pitti> mdz: so somehow your commit got lost, weird
[11:04] <cjwatson> not sure how that could be allowed to happen to a checkout, since commits to a checkout actually commit to the master first and then pull
[11:04] <mdz> pitti, looks like it is out of sync somehow, I will fix
[11:04] <cjwatson> don't suppose you used commit --local?
[11:04] <cjwatson> 'bzr up' should tell you
[11:04] <pitti> mdz: hang on, I don't think you can currently commit to trunk
[11:04] <cjwatson> (and should leave you with an uncommitted merge if necessary)
[11:04] <mdz> pitti, Committed revision 1490.
[11:04] <pitti> perhaps checkouts get confused if push fails due to -EPERM
[11:04] <mdz> cjwatson, I think I probably committed locally (thinking I was bound), and then later did 'bzr bind'
[11:05] <cjwatson> yes, you need push as well as bind in that case
[11:05] <mdz> the resulting state shows no pending changes with 'bzr status' but in fact there are de facto uncommitted changes
[11:05] <cjwatson> which is a bit annoying and confusing, I remember filing a bug about that ages ago
[11:05] <cjwatson> I think bind should automatically push
[11:05] <mdz> so I forgot about the commit because I couldn't see it anywhere
[11:05] <mdz> cjwatson, at the least, bzr status should show outstanding changes
[11:05] <cjwatson> or tell you if it couldn't
[11:05] <pitti> mdz: I added you to ~apport-hackers now
[11:05] <mdz> pitti, thanks
[11:05] <pitti> push should work now
[11:05] <mdz> pitti, 1490 should be there now
[11:06] <pitti> right, appears on loggerhead
[11:07] <lesshaste> cjwatson: I see my exact laptop is in the list https://wiki.ubuntu.com/KernelTeam/Grub2Testin
[11:08] <lesshaste> +g
[11:09] <pitti> seb128: apport 1.5 should now work around these constant "412 Precondition Failed" things, as well as fix the recent IndexError; testing/uploading backports now
[11:09] <seb128> pitti, nice!
[11:10] <pitti> well, with "work around" -> "except HTTPError: pass" *shrug*
[11:13] <Keybuk> mdz: bzr missing would have told you what was up
[11:13] <mdz> Keybuk, hmm, that's not part of my normal workflow
[11:13] <Keybuk> but I agree, local extra revisions should be included in status output of a checkout
[11:13] <Keybuk> since you only tend to learn missing if you follow a local branch/push to trunk workflow
[11:21] <tseliot> cjwatson: I need to check the product name of a laptop so that the debian-installer proceeds with the installation only on that specific model. I'm using dmidecode to check the product name. Would /etc/rcS.d/ be the right place to perform the check? (or maybe /usr/lib/base-installer.d ?)
[11:22] <cjwatson> neither
[11:22] <cjwatson> do you just want to halt or something if it doesn't match, or do you want to display UI?
[11:23] <tseliot> cjwatson: just halt and print a string of text with the reason why it stopped
[11:23] <cjwatson> /usr/lib/debian-installer-startup.d/ would be appropriate, then
[11:24] <cjwatson> err, sorry, make that /lib/debian-installer-startup.d/
[11:25] <tseliot> cjwatson: ok, thanks. Is this documented somewhere?
[11:27] <tseliot> ah, maybe this one? http://d-i.alioth.debian.org/doc/talks/debconf6/paper/index.html
[11:32] <mdz> pitti, I wonder why LP didn't automatically link the bug to that commit
[11:32] <pitti> mdz: did you specify --fixes lp:12345?
[11:32] <pitti> it might just lag
[11:33] <mdz> pitti, no, I just put it in the log message
[11:33] <mdz> I thought that took care of things automatically
[11:34] <pitti> it doesn't parse log messages
[11:34] <pitti> mdz: for ubuntu packages, debcommit parses LP: #xxxx out of debian/changelot
[11:35] <mdz> pitti, hmm, interesting.  I wonder why not.
[11:35] <mdz> it seems a natural thing to do
[11:36] <cjwatson> tseliot: that's a sensible paper yes
[11:37] <tseliot> ok, thanks
[12:02] <lesshaste> cjwatson: hah! https://bugs.launchpad.net/ubuntu/+source/grub/+bug/374823
[12:02] <lesshaste> :)
[12:02] <lesshaste> it's just a matter of finding the right words it seems
[12:04] <pitti> seb128: ok, please delete all the retracer cron mails sent by now; all following breakages are real, I'll look into them
[12:05] <lesshaste> not that there is a solution there either really
[12:23] <dupondje> outch
[12:23] <dupondje> seb128: seems it blows another error now :s
[12:23] <dupondje> after upgrading gvfs
[12:27] <dupondje> seb128: added comment to
[12:27] <dupondje> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/393051 :p
[12:28] <seb128> dupondje, do you have policykit-1 installed?
[12:29] <pitti> right, I guess somethign needs to pull in policykit-1-gnome
[12:30] <seb128> pitti, something being whatever ask for the credentials, grepping for PolicyKit1 in gvfs returns nothing
[12:31] <pitti> seb128: hm, tricky
[12:31] <pitti> client programs don't need to know about PK any more, that's one of the nice things
[12:31] <pitti> but I wouldn't like devicekit-disks to depend on -gnome, since it will also be used in KDE
[12:31] <pitti> so, of course we can add it to ubuntu-desktop, but not everyone has that
[12:32] <pitti> seb128: do you think it would be too evil to add a dependency to gvfs?
[12:32] <seb128> I'm fine adding it to gvfs
[12:32] <pitti> seb128: i. e. replacing the policykit-gnome one from gnome-mount?
[12:32] <pitti> since gnome-mount is no more either
[12:32] <seb128> but how does it work?
[12:32] <seb128> who does the polkit calls?
[12:32] <seb128> gvfs or devicekit?
[12:33] <pitti> I'm not entirely sure, TBH; some clever callback mechanism
[12:34] <seb128> alright, let's add the depends to gvfs
[12:34] <seb128> did you mir, etc policykit-1 already?
[12:34] <pitti> it's just a new upstream version, it went to main
[12:34] <pitti> it just changed name to be co-installable until everything is ported
[12:34] <glatzor_> hello mvo. I just merged my gobject branch of aptdaemon. all the threading is now gone!
[12:35] <pitti> hey glatzor_
[12:35] <glatzor_> servus pitti and seb128 !
[12:35] <seb128> pitti, ok, let me grab some coffee and I will do the gvfs update with the depends
[12:35] <seb128> hey glatzor_
[12:37] <vadi2> Hi. Does anyone know anything about the "rebootless kernel upgrades" from http://www.ksplice.com/uptrack/ ? Is the thing safe to use?
[13:02] <dupondje> seb128: wasn't installed, installed it now, but still doesn't work
[13:05] <dupondje> seb128: ok it worked now after reboot :)
[13:25] <pitti> dupondje: right, it currently has an .autostart file, thus you need to restart the session
[13:36]  * apw wonders who is an archive admin today
[13:39] <jpds> apw: https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days
[13:41] <apw> jpds, perfect thanks
[14:04] <ogra> pitti, thanks for the seed change :)
[14:04] <pitti> ogra: ?
[14:05] <ogra> f-spot and tomboy for arm
[14:05] <pitti> ah, I just updated it to drop udev-extras from standard, but you're welcome :)
[14:05] <directhex> is mono behaving itself on arm today?
[14:05] <ogra> :)
[14:05] <ogra> directhex, only f-spot ...
[14:06] <ogra> banshee and tomboy have probs, havent debugged deeper yet
[14:06] <directhex> oh? tomboy's not working? that's odd, i thought it was fully managed
[14:06] <ogra> it works fine until i try to use the notification icon
[14:07] <directhex> crashes?
[14:07] <ogra> yep
[14:07] <directhex> left or right click?
[14:07] <ScottK> pitti: When you have a moment, I'd like to discuss clamav in -proposed for Jaunty (it's a point release update).
[14:07] <ogra> directhex, either
[14:07] <ogra> directhex, Bug 391124
[14:07] <pitti> ScottK: ah, another round?
[14:08] <ScottK> pitti: We're about to do another round of major updates in -backports, but for Jaunty it should be updatable into -proposed with the existing minor version update authority, so it's a separate issue.
[14:09] <pitti> ScottK: I see, so they should go to -proposed directly
[14:09] <ScottK> For Jaunty, yes.
[14:09] <directhex> ogra, looks like a gtk# problem. i'd forward it upstream asap
[14:09] <ogra> will do
[14:09] <ScottK> pitti: The question is about packaging updates.  When I've done point release updates in the past, I've packaged the new upstream for that release based on that release's packaging and not updated the packaging more than absolutely required.
[14:10] <ogra> directhex, mono-debuuger would surely be helpful :P
[14:10] <pitti> ScottK: right, makes sense
[14:10] <ScottK> pitti: The clamav package we released Jaunty with was still not terribly mature, so I'd like to capture the packaging improvements too this time.
[14:10] <ScottK> So I'm curious how you feel about that and how much detailed justification you want.
[14:10] <pitti> ScottK: what would that change in particular?
[14:11] <pitti> ScottK: changes to debconf, any conffiles, etc. are generally a no-go area IMHO
[14:11] <ScottK> There are some improvements in the inits.  All the debconf translations now match the actual questions.
[14:11] <pitti> ScottK: cleanup to rules, debhelper, etc. (internal build process) is bearable
[14:11] <pitti> translation fixes are okay, we update them regularly anyway
[14:12] <ScottK> OK.
[14:12] <directhex> ogra, yes, but the debugger's backend is C - and someone would need to port it to arm. until novell start getting demand from commercial arm/linux users (their main arm port is osx) then it'll not be a priority for upstream
[14:12] <ScottK> pitti: How about init scripts?
[14:12] <pitti> ScottK: not for debconf translations generally, but it's the same result for the user
[14:12] <ScottK> OK
[14:12] <ogra> directhex, yeah, understood, and apparently its not an easy task
[14:12] <pitti> ScottK: I'm not fond of conffile changes post release, since they cause prompting and potential hassle
[14:13] <ScottK> pitti: OK.  I'll look through it in detail and make sure I only pull out what makes sense.
[14:13] <directhex> ogra, well, being written in C is like kryptonite for me, so this is one i can't help with :p
[14:13] <ScottK> pitti: Thanks for the feedback.
[14:13] <ogra> mcasadevall took a look and told me its not trivial ...
[14:13] <pitti> ScottK: whichever approach is easier then, I guess (revert init script changes and keep the rest, or just update upstream version and keep packaging)
[14:13] <pitti> ScottK: thanks for working on this!
[14:13] <ogra> so we'll live with gdb
[14:14] <ScottK> pitti: OK.  No problem.
[14:14] <lessshaste> cjwatson, hello again.. I just attempted sudo apt-get install grub-pc
[14:14] <lessshaste> cjwatson, are you about? It didn't quite work out
[14:17] <lessshaste> I get http://pastebin.com/f9a0cc84 rather worryingly
[14:25] <lessshaste> I am attempting to upgrade to grub2.. sadly the ubuntu upgrade script made a mess so would anyone be able to look at my edited menu.1st please before I reboot to make sure I will still be able to log in again!  http://pastebin.com/f66d81456
[14:30] <lessshaste> noone kind enough?? :(
[14:56] <cjwatson> lesshaste: I don't see what point you're trying to make with those pastebin entries
[14:56] <cjwatson> lesshaste: what is worrying? what is wrong?
[15:05] <dvestal> cjwatson: I think that lessshaste was trying to get someone to make sure that he had setup his grub menu.lst file correctly.
[15:06] <cjwatson> dvestal: thank you but I'd already been talking with lesshaste earlier and know what he was doing
[15:06] <cjwatson> dvestal: I'm also continuing the conversation on #ubuntu-kernel now
[15:06] <lesshaste> thanks
[15:06] <dvestal> cjwatson: ahh. sorry then.
[15:06] <shaya> anyone here using the firefox-3.5 package besides me?
[15:06] <shaya> its incompatible w/ the libxul0d package
[15:06] <shaya> instant segfault if both are installed
[15:07] <lesshaste> dvestal, but thanks
[15:23] <pitti> tseliot1, superm1: I uploaded a new jockey with all the recent broadcom wl changes; testing appreciated!
[15:24] <tseliot1> pitti: great, thanks. I was planning on bugging you about this ;)
[15:24] <pitti> this also drops libglade, to make seb128 a tad happier :)
[15:25] <tseliot1> pitti: what's the name of the new module (which replaces libglade)?
[15:25] <pitti> tseliot1: gtk.Builder
[15:26] <tseliot1> pitti: thanks, I'll remember to use that from now on
[15:26] <james_w> pitti: yeah, there's a big filed, I think I know how to fix it
[15:28] <pitti> james_w: great, thank you
[15:54] <Caesar> tjaalton: are you tjaalton or timo-aalton on Launchpad?
[15:55] <Caesar> sorry timo-aaltonen
[15:55] <dholbach> Caesar: probably the one with more karma :)
[15:55] <Caesar> dholbach: ah yes, good idea
[15:55] <dholbach> it's tjaalton
[15:56] <dholbach> he's in ubuntu-core-dev too
[15:56] <Caesar> Got him
[15:56] <tjaalton> heh
[15:57]  * Caesar waves
[15:57] <tjaalton> hi
[15:57] <Caesar> tjaalton: hi, I just filed the first of the two libxcb bugs we discussed
[15:57] <Caesar> I'll file the second one with the patch when I get to work
[15:57] <tjaalton> Caesar: ah, great
[15:57] <tjaalton> ok, I'll have a look tomorrow
[15:57]  * Caesar heads to work
[15:59] <pitti> mdz: (just replied to bug report as well); udev-extras removal is deliberate, it's dead
[15:59] <pitti> mdz: or, rather, merged into udev itself
[16:00] <mdz> pitti, oh, the versioned conflict confused me
[16:00] <mdz> Conflicts: hotplug, ifrename, libdevmapper1.02 (<< 2:1.02.08-1ubuntu7), udev-extras (<= 20090618)
[16:01] <pitti> mdz: we added that just in case we'll ever have an udev-extras with new staging stuff
[16:01] <pitti> but right now, the udev-extras git head is empty, and kay has no plans to re-fill it
[16:13] <ogra> cjwatson, https://blueprints.launchpad.net/ubuntu/+spec/mobile-arm-karmic-subarches-in-debian-cd used to be dead, but given that we will have to support two different armel SoCs both using two different bootloaders we will need to revive it, do you have any problem if we implement it similar as the ps3 thing ?
[16:13] <ogra> s/as the/to the/
[16:14] <cjwatson> ogra: fine by me as long as you guys maintain the code ;-)
[16:14] <ogra> (i think i remember to have heard rumours the ps3 hack isnt liked very much)
[16:14] <ogra> ok, thanks :)
[16:14] <cjwatson> I'm fine with it actually
[16:15] <ogra> i'll steal from it then
[16:15] <cjwatson> well
[16:15] <cjwatson> the bit I don't like is that they're two separate CDs
[16:15] <cjwatson> I'd rather that they were a single CD, since most of the content's the same
[16:15] <cjwatson> if you can arrange for a single image that boots both ways, that's clearly technically superior
[16:15] <cjwatson> if you can't, the ps3 hack is fine
[16:15] <ogra> right, having u-boot for one board and redboot for the other makes two images somewhat required in armel land
[16:17] <lesshaste> hi again
[16:32] <alkisg> asac, if you'd need any more info or any patch-beta-testing for https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/391040 I'd be happy to help.
[16:45] <ScottK> slangasek: Ping.  Let me know when your coherent enough to deal with clamav backporting ....
[17:01] <lesshaste> hi
[17:26] <FJ_Sanchez> Hi
[17:26] <FJ_Sanchez> I need help to fix a dependency problem
[17:26] <FJ_Sanchez> I want to manually change version deps
[17:26] <FJ_Sanchez> How can I do this?
[17:54] <kb9vqf_> Anyone here willing to rescore a PPA build?
[17:54] <kb9vqf_> This one https://launchpad.net/~ubuntu-389-directory-server/+archive/ppa/+build/1097734 and related were affected by a certificates bug that has since been fixed, but it'll be many hours before it rebuilds
[17:57] <Ampelbein> kb9vqf_: perhaps you are better off asking in #launchpad.
[17:57] <kb9vqf_> Ampelbein: Thanks for the suggestion!
[18:04] <asac> alkisg: does it work if you name your iface ethtest (instead of eth0)
[18:04] <alkisg> asac: eh, rename it from udev rules?
[18:06] <c_korn> hello, I am trying to package pidgin-2.5.8 using the diff.gz of 2.5.7 in karmic. but after configure these errors occur: http://pastebin.com/d64f79db1
[18:09] <alkisg> asac: sorry, my X crashed, if you replied about how to rename my eth0 to ethtest I didn't see it
[18:12] <asac> alkisg: no. rename it in the interfaces
[18:12] <asac> alkisg: replace iface eth0 ... with iface ethYOUR
[18:12] <asac> and auto eth0 with auto ethYOUR
[18:12] <alkisg> ok
[18:13] <asac> alkisg: after changing that you need to sudo killall nm-system-settings
[18:13] <alkisg> But #iface eth0 inet dhcp is commented out - or do you want me to modify eth1 which uses a static ip instead?
[18:17] <Caesar> slangasek: you around?
[18:17] <alkisg> asac: with the following /etc/network/interfaces, I'm still not able to manage system connections for ethYOUR: http://pastebin.ubuntu.com/206402
[18:18] <Ampelbein> c_korn: did you update the autoconf patch?
[18:18] <c_korn> Ampelbein: yes.
[18:19] <asac> alkisg: well. you still have eth1 in there
[18:19] <c_korn> http://pastebin.com/d2660e191
[18:19] <asac> alkisg: try to change that to ethYOUR2
[18:19] <c_korn> this is the autoconf patch I applied
[18:19] <alkisg> asac: ok, trying
[18:22] <robbiew> cjwatson: Keybuk: do you know what the current status of bug 383697 is?  I can't tell from the last few comments.
[18:22] <alkisg> asac: Yes, now I'm able to manage the connections - but of course that was expected, because eth1 no longer has a static ip.
[18:22] <alkisg> It's the same effect like I didn't declare any ethX interfaces at all...
[18:23] <Ampelbein> c_korn: looking.
[18:30] <Ampelbein> c_korn: builds fine here.
[18:32] <cjwatson> robbiew: no progress since I sent that patch, AFAICS ...
[18:32] <cjwatson> Keybuk: do you want me to rework it as an Ubuntu-specific patch as implied by your last comment (it would involve nothing more than removing that block) or are you happy to apply my patch as-is?
[18:37] <kb9vqf_> I am trying to get a fix into the official archives for bug 357556 , and have attached a debdiff/followed all the steps on https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue -- is there any way to speed the process along or do I just wait?
[18:40] <Ampelbein> kb9vqf_: xscreensaver is in main so the correct team to subscribe is ubuntu-main-sponsors.
[18:41] <kb9vqf_> Ampelbein: OK
[18:41] <Ampelbein> kb9vqf_: i unsubscribed u-u-s and subscribed ubuntu-main-sponsors
[18:42] <kb9vqf_> Ampelbein: I am also looking for an SRU...I'm updating the description now
[18:44] <kb9vqf_> Ampelbein: OK, I have the SRU request added to the bug
[18:44] <kb9vqf_> This is my first attempt at this procedure; please go easy on me :)
[18:46] <Ampelbein> kb9vqf_: no problem ;-)
[19:06] <asac> alkisg: please post output of nm-tool
[19:15] <alkisg> asac: working (ethYOUR): http://pastebin.ubuntu.com/206444        -      not working (eth0/eth1): http://pastebin.ubuntu.com/206445
[19:25] <tjaalton> <
[19:25] <tjaalton> uh
[19:38] <c_korn> Ampelbein: did you build the package in karmic or jaunty?
[19:40] <Ampelbein> c_korn: karmic. but i think i know why it built: i used autoreconf to build, not just autoconf.
[19:41] <c_korn> didn't you just test the diff.gz for the new version?
[19:41] <c_korn> I try to build it for jaunty
[19:44] <sianis> fta: ping
[19:48] <fta> sianis, pong
[19:48] <sianis> fta: could you please see this: https://answers.launchpad.net/gwibber/+question/75068
[19:49] <fta> sianis, is it in the upstream tree?
[19:50] <shaw> where can I ask about PPA issues?
[19:50] <sianis> fta: I don't know, we translated it at: https://translations.launchpad.net/gwibber
[19:51] <sianis> fta: there is no hu.po here: http://bazaar.launchpad.net/~gwibber-committers/gwibber/trunk/files/head%3A/po/
[19:52] <fta> sianis, ok, i'll ask upstream how they manage their translations
[19:52] <sianis> fta: thank you, let me know if you have question
[19:57] <shaw> if I have PPA trouble, where's the best place to ask about it?
[19:57] <cody-somerville> #launchpad
[19:58] <shaw> cody-somerville: thanks!
[20:02] <asac> alkisg: are eth1 and eth0 the only interfaces you have?
[20:02] <alkisg> asac: yes
[21:25] <maxb> wgrant: Hi, any news on that xserver-xorg-input-synaptics upload? :-)
[21:31] <shaya> what's going on w/ udev/udev-extras and ubuntu-standard?
[21:32] <maxb> shaya: If you still have problems with that after "apt-get update", you have a slow mirror
[21:33] <slangasek> Caesar: pong
[21:36] <superm1> pitti, took a look at the handling for 'wl' now with the bcmwl-kernel-source package and jockey. it's really close to right now.  jockey just needs to unload b43/ssb and then load 'wl' and then things should be functional off the live disk
[21:47] <shaya> maxb: using archive.ubuntu.com
[21:47] <shaya> though appears its fine now
[23:02] <pitti> superm1: thanks; can you please file a bug and assign it to me?
[23:23] <Caesar> slangasek: o hai
[23:23] <Caesar> I had a random Ubuntu development question for you
[23:24] <Caesar> I'm half-tempted to email ubuntu-devel instead for wider circulation
[23:28] <slangasek> Caesar: aw, I'm not wide enough?
[23:28]  * slangasek eats more doritos
[23:28] <Caesar> heh
[23:29] <Caesar> In a nutshell, my question was...
[23:29] <cjwatson> kirkland: do we need whatever patch https://bugzilla.redhat.com/show_bug.cgi?id=504787 was referring to? I don't seem to be able to boot PAE guests here ...
[23:29] <Caesar> When Ubuntu merges a package from Debian unstable, is that the end of paying attention to what happens to it in Debian?
[23:30] <Caesar> For a concrete case, I'm thinking specifically of libxcb in Hardy
[23:30] <TheMuso> c
[23:30] <Caesar> Debian just updated Lenny's version of it to address performance issues
[23:30] <Caesar> It's the same underlying version that is in Hardy
[23:31] <Caesar> So if I hadn't noticed and filed bugs against Ubuntu, would Ubuntu have noticed?
[23:31] <kirkland> cjwatson: what are you trying to boot?
[23:31] <Caesar> By extension, what happens if RC bugs get filed against the Debian version after it's been synced into Ubuntu?
[23:31] <slangasek> Caesar: merges, or syncs?
[23:31] <cjwatson> kirkland: install of today's server CD
[23:31] <kirkland> cjwatson: i'm able to boot the karmic i386 server cd
[23:31] <Caesar> slangasek either I guess
[23:31] <cjwatson> kirkland: the server CD installer itself isn't PAE
[23:32] <cjwatson> kirkland: you need to actually install it
[23:32] <cjwatson> and then try to boot the resulting system
[23:32] <kirkland> cjwatson: ah, okay, let me do that
[23:32] <slangasek> Caesar: in the case of a sync, there's not generally perceived to be an obligation on the part of the syncer to track the bug status of the package in Debian going forward, and the tools currently available don't exactly facilitate that
[23:32] <cjwatson> kirkland: now, admittedly I was experimenting with grub2 and LVM ... but as far as I can tell it's got past the obvious problem points there and is reading the filesystem successfully
[23:32] <slangasek> Caesar: in the case of a merge, you're "touched-it-last" for the package and are expected to watch whether there are further updates from Debian that should be merged in the cycle
[23:33] <cjwatson> (I tend to do experiments like that with the server CD just because it's quicker)
[23:36] <cjwatson> kirkland: https://bugzilla.redhat.com/show_bug.cgi?id=499596 might be a better report, and the workaround suggested there (-cpu qemu32) works for me
[23:36] <kirkland> cjwatson: what's your host running?
[23:36] <cjwatson> kirkland: karmic i386
[23:37] <kirkland> cjwatson: what cpu?
[23:37] <kirkland> cjwatson: pae, or non-pae on the host?
[23:37] <cjwatson> pae
[23:37] <cjwatson> core2duo
[23:37] <cjwatson> flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida tpr_shadow vnmi flexpriority
[23:39] <kirkland> cjwatson: curious, do you have any older pae-kerneled images lying around?  do those work, or are those broken too?
[23:39] <cjwatson> kirkland: not easily - jaunty server i386 worked not *that* long ago though
[23:40] <kirkland> cjwatson: right, i have definitely tested that one pretty extensively, don't know that i've tested karmic-i386 lately
[23:40] <kirkland> cjwatson: i'm onsite at eucalyptus, pulling the karmic-i386 iso now
[23:40] <cjwatson> the patch in http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/development/source/SRPMS/qemu-0.10.50-6.kvm86.fc12.src.rpm/qemu-fix-cpuid-trimming.patch?extract=true doesn't seem to apply
[23:41] <kirkland> cjwatson: if you're slightly brave, you can try the daily build of qemu-kvm at https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream
[23:41] <kirkland> cjwatson: qemu-kvm will be replacing/providing/conflicting qemu and kvm very soon
[23:43] <kirkland> cjwatson: that's built from upstream git, which might have this patch, perhaps
[23:43] <kirkland> cjwatson: you can bzr branch lp:qemu-kvm and check the logs
[23:44] <kirkland> cjwatson: otherwise, i'm downloading the iso now and can try to reproduce it here
[23:45] <cjwatson> https://launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream description needs a sudo before tee
[23:49] <kirkland> cjwatson: thanks
[23:49] <kirkland> cjwatson: is there any way do disable graphics mode in the server installer, such that i can use kvm -curses?
[23:50] <kirkland> cjwatson: if so, I could boot/install this entirely remotely without vnc :-)
[23:50] <kirkland> cjwatson: *very* low bandwidth :-)
[23:51] <geofft> kirkland: you're asking about putting fb=false on the kernel command line?
[23:51] <kirkland> geofft: oooh, will that do it?  /me tries
[23:52] <cjwatson> kirkland: DEBIAN_FRONTEND=text
[23:52] <cjwatson> geofft: that probably won't work quite right ...
[23:52] <geofft> oh, is there something newer that I missed?
[23:52] <cjwatson> you want to actually instruct the *installer* not to use a framebuffer, I think
[23:53] <cjwatson> oh, sorry, fb=false is actually an installer option, I forgot that
[23:53] <cjwatson> but still, I'd suggest DEBIAN_FRONTEND=text anyway
[23:53] <kirkland> cjwatson: this is a kernel boot option?
[23:53] <cjwatson> in low-bandwidth environments you probably want the lighter-weight frontend. It's actually as old as d-i :-)
[23:53] <cjwatson> kirkland: yes
[23:54] <directhex> d-i has a non-text-based frontend?
[23:54] <cjwatson> newt != text
[23:55] <cjwatson> I mean, as it happens, yes it does, but I think kirkland means how to turn off the full-screen thing
[23:55] <cjwatson> kirkland: waiting for qemu-kvm to download
[23:56] <kirkland> cjwatson: heh, i'm waiting for the iso to download
[23:58] <kirkland> cjwatson: hmm, the bootloader itself goes graphical, which busts kvm's -curses option
[23:59] <cjwatson> hold down shift at boot, if you can
[23:59] <cjwatson> I think it's shift