[00:33] kees: that dosemu diff is really not minimal [00:33] Riddell: no? [00:34] or is that the one with build cruft? [00:35] kees: yep [00:39] Riddell: I'm open to suggestions on how to avoid the cruft. seems to show up in my debdiff any time I debuild -S it [00:40] kees: filterdiff? [00:40] LaserJock: oh, sure, I can manually do it. :) [00:41] but it does represent what's going to happen when it builds [00:41] kees: does that matter so much? [00:41] what kind of cruft is it? [00:43] LaserJock: autoconf joy [00:43] Riddell: what would you like me to do? [00:44] kees: if it's unavoidable I can just look through it [00:44] kees: so like config.guess, config.sub? [00:47] Hm. Where was that network-manager + WPA-enterprise bug... [00:48] kees: you're on MIR team now? Could you take on bug #315403? looks like cup has been dep-wait on jflex since November [00:48] Launchpad bug 315403 in jflex "MIR for jflex" [Undecided,New] https://launchpad.net/bugs/315403 [00:48] slangasek: I am, but I'm totally underwater at the moment with security work [00:48] ok [00:49] lool: how about you? Any cycles for MIR work? ^^ [00:49] * slangasek wonders if jflex should replace jlex as a dep of libxsltc-java === hyperair1 is now known as hyperair [00:57] Woah. That's got to be the longest bug with a reasonable signal/noise ration on launchpad. [01:07] Riddell: thanks [01:16] aren't programs that need to save supposed to stop shutdown from happening until you deal with them? [01:16] istr this used to happen but now it doesn't for me anymore [01:17] i got a bug about OOo not stopping shutdown to save and tested on a vm and it doesn't work even for Gedit for me [01:17] calc: GNOME upstream broke the use of the standard session protcol [01:18] calc: so that really ought to be assigned to gnome-session; dunno if a bug is already open [01:18] slangasek: ah ok [01:18] cf. http://np237.livejournal.com/22014.html [01:19] slangasek: thanks for the link [01:25] * slangasek oohs, noticing that rss-glx is the only thing on the CD using libmagick10 and wondering if he can reclaim 2.4MB by rebuilding it against libmagickcore [01:28] calc: ooo/amd64 ftbfs? [01:28] ah, because of libmysqlclient still [01:28] calc: n/m [01:29] * slangasek schedules a retry, since everything seems to be in order now [01:42] hah, nice; libmagick10 has been split into 'libmagickcore1' and 'libmagickwand1', which... depend on each other. [01:43] Yes. [01:43] StevenK: dare I ask why? [01:43] I knew they were split - why is there a circular dependency? [01:43] slangasek: Because the Maintainer needs his crack pipe taken away ... [01:44] well, ok. It's ImageMagick, so that's par for the course. [01:44] see also: epochs [01:44] slangasek: I've been closing my eyes and saying "Lalala" about libmagick10 in NBS since it requires a bunch of source changes and there's a lovely argument going on in the BTS about it ... [01:44] StevenK: right - I'm going to do rss-glx though, because libmagickcore1+libmagickwand1 is 2.1MB smaller than libmagick10 :) [01:44] Heh [01:45] I've been hoping the mess resolves itself, but if it gets much later I'm going to JFDI [01:45] they must have built it without --enable-inline-fibonnaci-array [01:45] cd [01:45] is the argument in the BTS converging on sanity? [01:45] woops wrong tab [01:46] It wasn't, last I read. [01:46] slangasek: yea i just rescheduled armel as well [01:46] slangasek: I last read the bug in the BTS about a month ago, mind you [01:47] StevenK: can you nudge it in that direction? :) [01:47] slangasek: I was staying out of it :-P [01:47] * StevenK points to his "Slightly innocent by-stander" hat [01:48] * slangasek crosses out "by-stander" and writes in "downstream victim" :) [01:49] Haha === hyperair is now known as Guest24873 === hyperair is now known as Guest9613 === hyperair is now known as Guest24922 === bluesmoke is now known as Amaranth [03:39] TheMuso: You know how the recent pulseaudio uploads fixed my stutter on HDAs-Intel? It seems they've transferred them to my USB speakers :( [03:39] lol [03:39] RAOF: That sucks. [03:40] At least now it correlates with CPU load. [03:40] Not heavy CPU load, mind. Just any cpu load. [03:40] RAOF: Try alsa-driver 1.0.18 final, if its gone, then its a driver fix we can probably pull to work it out. [03:40] Right. [03:40] * TheMuso read an interesting tidbit this morning, USB2 is only half-duplex. [03:41] What's the m-a package for alsa-driver? [03:41] RAOF: alsa-source afaik. [03:45] Mmmm, build-stutter. [03:45] can you use sudo to restrict what people can run for stuff that's not for root? [03:51] Hm. alsa-source fails to build somewhere. That's going to be fun for someone not me. [03:56] RAOF: Ah ok, will chase that up. [03:59] r [03:59] RAOF: how did you go with mono? [04:00] lifeless: I am, as yet, unable to make it segfault when I'm looking at it. [04:00] RAOF: ha! [04:00] RAOF: running under gdb fixes it ? [04:01] It does indeed. Well, running the mono commands that the postinst would run under gdb doesn't segfault, at least. [04:02] RAOF: I will bet that running under valgrind would find it on your machine :P [04:02] I suppose that if I wanted to be 100% thorough I'd upload a new mono that wraps all executions of mono in gdb, and then build-depend on that new version. [04:03] * RAOF wonders if NCommander feels like some more mono pain, with added debug difficulty. [04:04] AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH [04:04] (no) [04:04] But this is one that I've only been able to reproduce on the PPA buildds, where we have no access! What could be more fun than debugging that? [04:05] * NCommander turns on the Soyuz light [04:14] TheMuso: No joy on the alsa-driver 1.0.18 front. If it's any better, it's not much better. [04:18] Hm. What's the easiest way to get a Debian Experimental VM happening in virt-manager? [04:25] RAOF: Right, so its probably userspace... again. === hyperair is now known as Guest70032 === hyperair1 is now known as hyperair === hyperair1 is now known as hyperair === hyperair1 is now known as hyperair === hyperair1 is now known as hyperair === hyperair1 is now known as hyperair === hyperair1 is now known as hyperair === dmb_ is now known as _dmb === _dmb is now known as libdmb === bluesmoke is now known as Amaranth [06:27] slangasek, i think someone abducted the mythbuntu builds from cdimages.ubuntu.com... there's no ISOs anymore for yesterday or the day before: http://cdimages.ubuntu.com/mythbuntu/daily-live/ [06:27] anything interesting in livefs build logs? [06:28] well there were ISOs before for at least the 12th [06:28] hmm [06:28] well wait, no i had an 11th downloaded, so i dont know there was for the 12th [06:29] i'll look at livefs build logs [06:29] it's not a livefs build problem, though there was a livefs build failure on amd64 [06:29] (i would have expected that the old one was used anyhow though if later ones were failing) [06:29] W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/jaunty/main/b [06:29] inary-i386/Packages.bz2 Hash Sum mismatch [06:29] it's that darn mirroring locking bug === antdedyet_ is now known as antdedyet [06:38] so likely would affect xubuntu and what not too [06:39] yes, it's an intermittent thing [06:39] good morning [06:39] * slangasek waves [06:39] Hola [06:40] why did the ISO from the 11th get purged tho if the ones on the 12th and 13th weren't actually made? [06:40] the script isn't so intelligent that it checks for successful builds before kicking off stale images [06:40] superm1: there's a 14 now, though :) [06:41] slangasek, well it's unfortunately broke unless it included the xfce4-session build that just finished 7 minutes ago... same for xubuntu. for some reason it looks like the build was scored really low and didn't build for 8 hours [06:41] mm [06:41] well, I was just doing an ISO build anyway, to test that this would work - the livefs still needs rebuilt [06:42] slangasek, yeah i dont think it's even finished the publisher run yet: https://launchpad.net/ubuntu/+source/xfce4-session/4.4.3-0ubuntu2 [06:43] did you happen to take a peek at the amd64 livefs build failure I alluded to? Anything that needs doing there, or should that sort itself out? [06:43] let me take a look [06:44] hm, very bzr. " Depends: update-manager but it is not going to be installed" what would prevent "update-manager" of all things? [06:44] i suspect it should sort itself out, but if it doesnt i can prepare an amd64 chroot sometime tomorrow [06:55] hrmph, unable to install hardy this morning, results in grub saying "Error 18" [06:56] oh, hm, http://wiki.linuxquestions.org/wiki/GRUB#Error_18 [06:59] liw: you needs a /boot somewhere "near" to the start of the disk (<2GB IIRC) [07:00] well, 8GB, according to that URL [07:01] sladen, yeah, but I keep being weirded out that a modern motherboard's bios needs that still [07:04] liw: using some low-level ext hackery it would be possible to force certain files below a magic threshold, but I (probably like you) thought it was "fixed" by now === bluesmoke is now known as Amaranth [07:14] Amaranth: bluesmoke? [07:14] RAOF: magic blue smoke [07:15] RAOF: Your computer makes it when you compile mono too many times [07:15] Heh. [07:15] * RAOF 's box made it without compiling mono _at all_. === tkamppeter_ is now known as tkamppeter [07:55] Hello [07:55] [ 52.630275] SDA:<4>Driver 'sr' needs updating - please use bus_type methods HELP! [07:55] please help [08:39] calc: the fortran stuff cleaned up nicely; the java stuff is still there even on i386 - is that because -l10n hasn't built yet? === thekorn_ is now known as thekorn [08:51] is it fairly safe to update from a fresh install with alpha 2? [08:53] bryce: thanks for devscripts! I'll file a wishlist bug in Debian too later this evening. Regarding its merge, I could look at it in the next few days. === quassel251 is now known as eilidh [09:20] slangasek: Reviewed jflex; found a bunch of small issues which can easily be resolved, but I don't think we should block main promotion on them === savvas is now known as savvas_ === savvas_ is now known as savvas === thekorn_ is now known as thekorn [10:51] what's the status of radeon support with free drivers? my RV630 does not seem to work in intrepid, but perhaps jaunty has new goodies? === corge is now known as fdd [11:51] Qt will use lgpl: http://www.eweek.com/c/a/Linux-and-Open-Source/Nokia-to-Offer-Qt-Under-LGPL-Licensing/ [12:43] cjwatson: do we have anything that tries to populate /dev anymore? [12:47] (other than makedev itself) [12:47] * ogra just wanted to note there are some postinsts that run makedev :) [12:47] james_w: i saw that you took over the firebug branch with what comes from debian at some point. [12:47] yeah, they'll fail now ;) [12:47] (in Debian too) [12:47] asac: yeah [12:47] i saw that (on arm though) [12:48] james_w: and changed the binary package name from firebug to iceweasel? [12:48] asac: nope [12:48] ogra: I'm wondering whether we should drop makedev [12:48] how is that supposed to work now ? [12:48] calling some udev specific command ? [12:49] ogra: the device will already exist ? [12:49] or does it just rely on the kernel creating these devices [12:49] james_w: did you try to contact jared first? (who was the original maintainer) [12:49] there aren't any devices for which the kernel won't create it first [12:49] ah [12:49] asac: it was a merge from Debian as the Ubuntu package was really out of date, modifications were made from Debian's package to make it work with firefox etc. [12:49] asac: no, I didn't. There was an old upgrade bug open on the package. [12:50] well, people will complain if they dont have makedev anymore ... [12:50] james_w: you could have pinged us ;) [12:50] ok [12:50] asac: I didn't feel I needed to. [12:50] ogra: will they? [12:50] but thats the only drawback i see ... i.e. if you have scripts that use it to create any special devices [12:50] makedev is already a no-op with a warning if you try and run it [12:51] Keybuk: I don't think so [12:51] oh, and i was talking about mknod :) ignore me :) [12:51] I was under the impression that postinsts that run makedev generally had conditionals [12:51] james_w: you know that an extension team existed ;) [12:52] i saw a lot of makedev calls building the last arm rootfs tree [12:52] but they usually only warn [12:52] asac: yes, and I updated the branches from the debdiffs that were supplied. [12:52] NCommander: bug 316841: don't we need to update finish-install too to set up an upstart job for the serial console? [12:52] Launchpad bug 316841 in shadow "Freescale MX series needs new ports added to securetty.linux" [Medium,Fix released] https://launchpad.net/bugs/316841 [12:52] cjwatson: we end up with a fairly random set of stuff in the "real" /dev [12:52] many of which have the wrong names, permissions, etc. [12:53] it would be nicer if that just had the most basic devices like console, null, etc. only [12:53] james_w: in general all is fine .. i just think that you changed the orig tarball layout to something that cannot be patched without patchsystem [12:53] which is somewhat bad ;) ... but now its done, so whatever ;) [12:53] debootstrap might populate it a bit, though I thought it had stopped doing that [12:53] cjwatson: the makedev postinst itself populates it [12:53] asac: ah, ok, sorry about that. [12:54] and there are packages that call makedev if they don't think udev is running [12:54] which means it ends up partially populated when installing [12:54] asac: you should probably create a README.Source that you can reference from these packages that explains this stuff. [12:54] james_w: we will bring mozilla-devscripts to debian soon ... then firebug guy can use med-xpi-unpack and med-xpi-pack to do that [12:55] e.g. creating a good orig [12:55] Keybuk: a udev /dev should be bind-mounted during installation though [12:55] firebug guy/debian guy/ [12:55] cjwatson: is it? [12:55] we do mount --bind /dev /target/dev [12:56] james_w: yeah true ... i just didnt expect someone to go and merge from debian to a previously independent branch ... my wrong [12:56] I can't swear that that's present at all possible points but I certainly thought it ought to be [12:56] damn, I shall have to figure this bug out harder then ;) [12:56] you could add something to makedev.postinst to check for the udevdb [12:56] there's something in MAKEDEV itself that does that already [12:57] james_w: but lets move on ;) [12:57] oh yes [12:57] you can't MAKEDEV over the top of udev [12:57] do we need to install the makedev package by default any more? [12:57] cjwatson: support for making devices other than in /dev ? [12:57] (it's a bit of a long stretch) [12:57] a few things depend on it [12:57] hmm, udev is probably not installed in buildd chroots [12:57] historically that has been Painful [12:58] james_w: btw, the work you did is much appreciated ;) (in case it sounded different) [12:58] why would something need to call makedev during package builds? [12:58] that's not even possible surely? :p [12:58] it wouldn't, but the buildd chroots probably need at least a few devices present [12:58] I don't know if they bind-mount /dev [12:58] interesting question [12:58] asac: no problem. I realise that you are trying to do something a bit different and I don't want to make it harder than it has to be for you. [12:58] it's nice for debootstrapped chroots to have some useful devices out of the box too [12:59] yeah, I was thinking of just going for a more minimal default /dev [12:59] without some of the more exotic devices [13:01] bryce: around? (re: sane-backends) [13:01] james_w: in fact i dont try to do things different. just wasnt sure (and still nto 100% sure) what to do with debian merges for pre-existing branches [13:10] Keybuk: debootstrap appears to do 'MAKEDEV std ptmx fd' and put the result in /dev [13:11] which IIRC is not an entirely crazy set [13:11] right [13:11] that's a pretty reasonable core set [13:12] * Keybuk tries to remember why he doesn't just call MAKEDEV to populate /lib/udev/devices [13:12] so I think that means makedev may be unnecessary in the required seed [13:12] it's explicitly seeded there right now [13:13] enough base things depend on it that it'll stay in the seed [13:13] but we could probably unseed it and see how long it takes to go away [13:15] yeah, that's what I meant [13:16] * Keybuk likes discussing changing fundamental things in the middle of an alpha freeze [13:16] germinate seems to think that it should at least drop out to standard [13:16] which would mean debootstrap would stop installing it === hyperair1 is now known as hyperair [13:24] cjwatson: *nods* [13:24] a few things seem to hold it in standard [13:24] fuse-utils [13:24] * Keybuk looks at ogra ;-) [13:24] should be easy to address [13:25] hmm, havent touched it for a whil ... i'll look [13:25] *while [13:25] i think that comes from the odd debian postinst scrits we dont use ... [13:25] *scripts [13:26] ogra@osiris:~/Devel/packages/fuse-2.7.4$ grep makedev debian/*.post* [13:26] debian/fuse-utils.postinst: # Call makedev and fix perms [13:27] well, that indeed justifies a dependency ... omg ! its mentioned in the comments !!! [13:27] * ogra drops :) [13:28] james_w: any ideas how i could publish a failed bzr merge? just forcefully committing and requiring developers to uncommit to work on it? [13:28] Keybuk, fix uploaded [13:29] james_w: will bzr resolve FILE forcefully resolve a conflict? [13:29] asac: can they not just the merge for themselves? [13:29] james_w: but how to publish the "work task" ? [13:29] james_w: that would require a separate channel like mailing list etc. [13:30] launchpad merge request? [13:31] james_w: yeah. that could be used, but is a bit of a launchpad specific problem to the general problem. but good enough i guess (just have to figure out the xml api i guess) [13:31] s/specific problem/specific solution/ ;) [13:32] the API doesn't quite allow you to create merge requests yet I believe [13:32] hmm ... that would be a blocker then ;) [13:32] I agree a way of storing a conflicted tree with pending merges might be quite useful [13:32] but force committing it isn't the answer [13:32] yeah. thats why i asked ;) [13:36] james_w: if i uncommit, i can still refer to that revision right? [13:36] why is there no linux-image-debug-2.6.27-9-generic on security.ubuntu.com? `apt-cache madison linux-image-debug-2.6.27-9-generic` claims it to be produced from the source package linux_2.6.27-9.19, but it does not seem to be published at all! [13:36] asac: yeah, by revid [13:36] james_w: but i guess that hidden revision isnt pushed? [13:36] asac: correct [13:37] couldnt a similar mechanism be used to publish such broken merge requests? [13:37] james_w: ? [13:37] what mechanism? [13:37] james_w: to have a revid that represents the broken merge [13:38] not really, as a pending merge/conflicts are working tree things, not revisions [13:39] james_w: yes, but if uncommit a merge, isnt the merged tree still reachable through the "hidden" revid? [13:40] but well, i better stop talking about things i dont know any details ;) [13:40] yes, you are right [13:41] james_w: about the former or the latter ... or both? [13:41] :-P [13:41] but it's equally as accessible, more visible, and easier to refer to in the place that you merged from [13:41] heh :-) [13:41] the former [13:44] ogra: it wasn't just the comments, note that makedev's executable is in upper case :-P [13:45] argh [13:45] but that code path is never executed if udev is active anyway [13:45] I'm not sure what would happen if you installed fuse-utils in a buildd chroot, though [13:45] we could just make the postinst succeed anyway [13:46] lamont`: ah, excellent timing. Do buildd chroots bind-mount /dev from the base (presumably udev)? [13:46] just an || true ? [13:46] * ogra would rather comment that line out completely though [13:47] cjwatson: buidld chroots have proc and dev/pts from the parent [13:47] can they have /dev? [13:47] or is there a good reason not to? === eights is now known as baytes === ziroday` is now known as ziroday [14:08] james_w: 317111 [14:10] thanks [14:20] slangasek, it looks like the livefs for mythbuntu still have the old xfce4-session for today. xubuntu's is good I believe ( cody-somerville can you confirm? ), could you poke it to do one more build? [14:23] superm1, charlie-tca confirms livecd starts fine today [14:24] As for mythbuntu, I don't have access to distro build infrastructure (I'm in OEM Services). slangasek, cjwatson, or evand should be able to help you get you your livefs rebuilt. [14:24] thanks [14:24] superm1, Have you looked to see if maybe your livefs build failed? [14:25] cjwatson: ping [14:25] cody-somerville, yeah the last one passed: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/jaunty/mythbuntu/20090114/ . I think it was just an inconvenient time that it was cronned before things were published [14:25] cjwatson: yesterday daily jaunty installer won't accept a swap + / ext4 [14:26] plus gparted on the livecd doesn't support et4 [14:26] *ext4 [14:26] BUGabundo_work, are you running Windows at the moment? [14:27] yes from another PC [14:27] took almorning backing up disk to external driver [14:27] uses usbcreator to make a pendrive [14:27] and now am stuck with the install! [14:27] BUGabundo_work: the gparted bug for ext4 is still open [14:27] reporting both bugs on LP [14:27] do not report that one again [14:27] ok I'll subs to it then [14:28] won't! [14:28] about the installer cjwatson? [14:28] 8GiBs swap + / ext4 is replaced by / ext3 + /Home ext3 [14:28] very strange [14:28] BUGabundo_work: do you mean that you did guided partitioning? [14:28] manual [14:28] does the guided handle ext4? [14:29] no [14:29] there you go [14:29] so you must have created /home by hand. Do you mean that it did not recognise the existing ext4 partition as being ext4? [14:29] old partitions were ext3. one / + one /home plus one swap [14:30] I deleted them via installer (which means they are still intact) [14:30] BUGabundo_work: so I do not understand your bug. First you say that the old partition was ext4, now you say that it was ext3 [14:30] and "tried" to create new ones [14:30] can you please be more precise? [14:30] no no no [14:30] old was ext3 [14:30] and xfs [14:31] new schema with deleted old partitions is meant to be 8gibs /swap + / ext4 [14:31] BUGabundo_work: please file a bug stating precisely what you did, step by step [14:31] but the installer replaces that with 8g / ext3 and /home ext3 [14:31] no swap, no ext4 [14:31] BUGabundo_work: concentrate on making it possible for me to follow the same steps and reproduce the problem [14:31] sure [14:31] brb [14:31] that's deeply improbable [14:31] the installer never creates /home by default [14:31] do you have the bug id for gparted? [14:32] I know! its strange [14:32] no, but it shouldn't take you long to look it up [14:32] I can show you via webcam [14:32] do you want that ? [14:32] BUGabundo_work: is this the alternate installer or the desktop installer [14:32] no, I would rather not have a video [14:32] humm tried first from the quick installer at livecd boot [14:32] then from Full desktop live [14:32] so the desktop installer [14:33] will reboot, and report the bug, step by step [14:33] BUGabundo_work: please attach /var/log/syslog, /var/log/partman, and /var/log/installer/debug *after* reproducing the bug but *before* rebooting [14:33] I don't know how you guys call the installer that doesn't boot into desktop [14:33] okay [14:33] it's the same installer [14:34] okay [14:34] good to know [14:37] cjwatson: I'm still making a webcam cast of the procedure [14:37] in case you want to watch it later [14:37] http://bambuser.com/node/68590 [14:37] usually logs are actually more helpful to me, but thank you [14:38] once in a blue moon I guess a video would be handy [14:38] no prob [14:40] ok just reproduced it! [14:40] getting logs to a bug [14:41] cjwatson: what package? [14:43] BUGabundo_work: ubiquity [14:43] (it's probably not really there but that's a good starting point) [14:46] cjwatson: bug 317124 [14:46] Error: Launchpad bug 317124 could not be found [14:46] uploading logs now [14:47] thanks [14:48] cjwatson: logs sent [14:48] bug 317124 [14:48] Launchpad bug 317124 in ubiquity "jaunty installer fails to accept manual ext4 schema" [Undecided,New] https://launchpad.net/bugs/317124 [14:48] ping me for any extra test or info [14:49] BUGabundo_work: OK, I'm working on something else right now but will get to this next [14:50] thanks [14:50] if it gets fixed today, maybe I can still test it again [14:50] and get a fresh install [14:50] finally [14:51] 10GiBs for / is full [14:53] cjwatson: are you kamion on LP? [14:58] BUGabundo_work: yes === devfil__ is now known as devfil [15:09] slangasek: yes that would be because of the ooo-l10n afaik [15:12] BUGabundo_work: ok, turns out it's nothing to do with ext4 and is a bug that's been fixed in a more recent version of ubiquity [15:13] BUGabundo_work: I'd appreciate it if you didn't assign bugs to me in future [15:13] my manager gets to do that :) [15:16] cjwatson: ;) [15:17] I must backport that gparted patch though, a lot of people have been asking for it [15:18] cjwatson: sorry [15:30] not for the first time I wish that dpkg had a command line option to tell you what deps were missing [15:31] dpkg -i foo.deb; apt-get -f install # this more or less works as a workaround (Keybuk surely knows this, but others might not have realized) [15:31] Keybuk, ther is that apt thing :) [15:35] gdebi is also a handy tool for this === BenC2 is now known as BenC [15:38] liw: that's not quite what I meant [15:38] apt attempts to fix it given the known archives [15:38] (dpkg --configure -a gives similar output, but also tries to fix things) [15:38] all I want to know is what's wrong [15:39] Keybuk, ok [15:39] apt-get has --no-act, though [15:40] Keybuk: is gdebi what you want then? it will also look at the known archive but will tell you about stuff it can not find [15:40] dunno [15:40] it's more the versions [15:40] I've installed a bunch of jaunty packages on intrepid [15:40] want to know what I need to upgrade [15:46] liw: dpkg --unpack foo; apt-get -f install rather. [15:49] Keybuk, the fix attempt from apt-get -f install will show you the problems .... [15:51] bue like mvo explained, gdebi will do that on a preventive manner [15:55] lool: jflex> cheers - do we need to look at getting jlex demoted as well? [15:56] ogra: hrm, was this fuse upload really warranted during a milestone freeze? [15:57] slangasek, err, i thought we are suposed to upload to have it in the queue [15:57] slangasek, its not urgently needed in the images [15:57] superm1: yes, mythbuntu livefs respinning now [15:57] slangasek, great thanks [15:57] ogra: we haven't been using a queue for alpha milestones for 3 release cycles... [15:57] meh, sorry then [15:58] it wont do any harm though [15:58] slangasek: I have a pending update-manager upload that helps nvidia users, is it ok to still upload ? [15:58] mvo_: bug #? [15:59] slangasek: bug #308410 [15:59] Launchpad bug 308410 in nvidia-graphics-drivers-180 "Latest Xorg removes nvidia driver ... conflicting xserver-xorg-video-4" [Medium,Confirmed] https://launchpad.net/bugs/308410 [15:59] slangasek: the "fix" for now is to auto transition the users from nvidia to nv in the xorg conf [16:01]