[00:08] <slangasek> Keybuk: ok, doesn't look like nfs mounts are the issue; it seems something else changed between my test w/ NFS mounts enabled and without
[00:09] <slangasek> (though I do appear to have the opposite problem, that nothing is waiting around for the NFS shares to become available, so they don't get automounted, sigh)
[00:09] <slangasek> Keybuk: it looks like the problem I was actually having consists of gdm failing to start up
[00:09] <slangasek> which I think you've already triaged :)
[00:35] <Keybuk> slangasek: not triaged
[00:36] <Keybuk> still don't know why gdm doesn't start
[00:36] <Keybuk> just know that it doesn't
[00:36] <Keybuk> (rather than it does start and fails)
[00:36] <Keybuk> mountall should wait around though
[00:36] <Keybuk> it only exits once everything in fstab has been mounted
[00:36] <Keybuk> it stays running after emitting filesystem for anything else
[00:36] <slangasek> hmm, ok
[00:37] <Keybuk> (at least it should <g>)
[00:37] <slangasek> ok, will dig further
[00:47] <stgraber> Keybuk: hey, I'm currently working on improving the boot process of LTSP and noticed we have ureadahead doing something during our boot process (probably profiling). As we're reading a compressed boot image from the network, I'm not sure we really need it and having it profile on a read-only system doesn't make much sense.
[00:47] <stgraber> is there a way to turn it off ?
[01:00] <bluefoxicy> Why does VLC load with a christmas hat now?
[01:02] <slangasek> I guess somebody put a Christmas egg in it
[01:14] <slangasek> james_w: what needs to happen to get the fix for bug #493462 out to lucid?  I seem to have run into the same problem again (emacs-goodies-el)
[01:17] <Keybuk> stgraber: don't install it
[01:19] <stgraber> Keybuk: well, we use ubuntu-minimal ;)
[01:20] <slangasek> stgraber: rm /etc/init/ureadahead-other.conf?
[01:21] <Keybuk> stgraber: here's a better question for you ...
[01:21] <Keybuk> does readahead slow down your boot?
[01:21] <Keybuk> I would have thought, with network latency and all, that there would be an advantage to doing all the reads up front in one block
[01:23] <stgraber> Keybuk: that's a good question, at the moment it doesn't as we don't have a pack in the chroot and I don't suppose we have a way to generate one without first booting a thin client and getting it
[01:48] <stgraber> did a quick check, having the pack from the netbook put into the image makes the boot 250ms slower. I guess I'll drop ureadahead for now and see if there's some way I can use it later.
[01:57] <Keybuk> packs are individually sorted for each filesystem
[02:11] <lamont> why is it that all the i386 boxes in the house that I have running karmic seize from time to time?
[02:52] <shtylman> there appears to be a nasty regression in lucid kernels with regard to intel wifi
[02:52] <shtylman> my wifi can't connect at all
[02:52] <shtylman> similar symptoms to bug: 425366
[02:52] <shtylman> bug #425366
[02:53] <shtylman> always wlan0: disassociating by local choice (reason=3)
[03:11] <crimsun> shtylman: can you associate with an unencrypted AP?
[03:12] <shtylman> crimsun: nope
[03:12] <shtylman> that didn't work either (tried it the other day)
[03:13] <shtylman> I also tried a daily kernel
[03:13] <shtylman> same problem
[03:13] <StevenK> pitti: I'm promoting ubuntu-netbook-default-settings to main, it replaces ubuntu-netbook-remix-default-settings which has been in main for a while.
[03:13] <crimsun> shtylman: and with the appropriate kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.2/ ?
[03:14] <shtylman> didn't see those...I tested with a 2.6.33 kernel
[03:14] <shtylman> should I try one of those ?
[03:15] <crimsun> shtylman: yes
[03:15] <shtylman> k..gimme a min
[03:20] <shtylman> crimsun: same
[03:20] <shtylman> wpa supplicant retries in a loop
[03:20] <shtylman> dmesg says deauth reason 3
[03:21] <crimsun> shtylman: please file a bug against linux (ubuntu-bug linux) including that bit about testing mainline 2.6.32.2
[03:22] <shtylman> what about that other bug?
[03:22] <shtylman> I remanmed it... and changed the package for it
[03:22] <shtylman> should i file a new bug?
[03:22] <shtylman> or just add the comment
[03:22] <crimsun> file a new one, please. That's a different kernel.
[03:22] <shtylman> k
[03:22] <crimsun> it'll be triaged as appropriate regardless
[03:25] <shtylman> would this be an issue that has been confirmed with the upstream kernel?
[03:25] <shtylman> is that the upstream kernel as far as we are concerned?
[03:25] <crimsun> since you've confirmed it in 2.6.32.2, it's an upstream issue, yes.
[03:26] <crimsun> I presume you tested 2.6.33-rc1's mainline build as well?
[03:26] <shtylman> not built from git
[03:26] <shtylman> I just tested the daily one from kernel.ubuntu.com
[03:27] <shtylman> haha... I couldn't report the bug cause its not a genuine package
[03:27] <crimsun> oh c-o-d, not http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc1/ ? I don't think anything much has changed, but I haven't tracked linus's merges in a few days
[03:28] <shtylman> lemme try that one just to be sure
[03:28] <shtylman> then should I remove them before i run ubuntu-bug .. cause otherwise it fails
[03:29] <crimsun> probablya
[03:30] <crimsun> shtylman: perhaps ping mcgrof in #ubuntu-kernel
[03:30] <shtylman> k
[05:41] <roger21> hi, what would be the file that allow to set up the double click delay ?
[05:42] <ScottK> roger21: I think #ubuntu would be a better channel to ask that question.
[05:43] <roger21> well they usually refer to the graphical interface, but yes i is not a dev related question
[06:36] <micahg> is this a good place for bzr merge help?
[06:44] <spiv> micahg: I'm guessing it could be, but if not you could try #bzr
[06:45] <micahg> will #bzr help with bzr merge-package?
[06:45] <spiv> micahg: we'll try, anyway :)
[06:45] <micahg> the problem is that I get this when trying to merge two bzr repos bzr: ERROR: No such tag: upstream-3.0~hg20091109r4325+nobinonly
[06:46] <micahg> I'm trying to merge TB3 into the current TB2 bzr repo
[06:47] <micahg> or is merge-package only with distro merges?
[06:50] <ScottK> micahg: I'd ask james_w after he's awake.
[06:50] <micahg> ok, ScottK, you know what tz that would be?
[06:50] <ScottK> He lives in the UK, but I don't know that he's there currently.
[06:50] <micahg> ok, I'll try when I get up then :)
[07:48] <dholbach> good morning
[07:50] <Dday> after moving from ubuntu 9.04-9.10 my sound no longer works, does anyone know what i should do?
[07:55] <dholbach> does anybody know a bit more about the aptitude stack smashing?
[07:55] <dholbach> it makes running pbuilder a bit hard :)
[07:56] <slangasek> kees: ^^
[07:57] <nixternal> dholbach: looks like kees already uploaded a fix
[07:57] <nixternal> I caught everyone complainging, so I have been doing my Debian work :D
[07:57] <dholbach> bug 499665 and bug 499693
[07:57] <nixternal> 488631
[07:57] <nixternal> they seem to be the same
[07:57] <dholbach> nixternal: I just hope that LP doesn't use aptitude in the chroots, that'd make it a bit more complicated to fix
[07:57] <nixternal> bug 488631
[07:57] <nixternal> err
[07:58] <nixternal> bug 499631
[07:58] <nixternal> silly fingers
[07:58] <dholbach> I'll dupe the others
[07:58] <dholbach> hey mvo
[07:59] <kees> dholbach: yeah, as slangasek says, I just tracked it down and uploaded what seems to fix it for me.
[07:59]  * dholbach hugs kees
[07:59] <dholbach> thanks guys :-D
[07:59] <kees> mvo: I think the recent apt upload broke ABI (at least for aptitude)
[08:00]  * kees hugs dholbach
[08:00] <slangasek> dholbach: why does /pbuilder/ use aptitude?  it ought to just use apt, as far as I'm concerned
[08:00] <kees> yeah, I nearly closed the bug as "don't use aptitude".  :P
[08:00] <nixternal> son of a!! *#)@*#@ I need that folder...I wrote a damn xmobar plugin (Haskell) for apt and just deleted it...I knew I should have worked on something else
[08:01] <dholbach> slangasek: that's an entirely different question :)
[08:01] <kees> heh
[08:01] <mvo> hey dholbach
[08:02]  * dholbach will take the dog for a walk and wait for the aptitude rebuild to happen :)
[08:02] <mvo> kees: oh, hrm, thanks. I have a look
[08:05] <mvo> kees: hm, I did test that :/ did you/someone uploaded a rebuild already?
[08:06] <kees> mvo: I just uploaded a rebuild, yes.
[08:06] <mvo> many thanks kees!
[08:06] <kees> sure thing!  Hopefully that was the right solution.
[08:08] <mvo> kees: yeah, I just spotted the problem I think
[08:08] <kees> ah, ok.  some structure change size?  I was trying to figure out what would have triggered a stack-overflow, but not a fortify check.
[08:10] <mvo> kees: its a change in the signature of packagemanager.h, it got a new default argument and I overlooked that when I did the merge
[08:10] <kees> ah-ha
[08:10] <mvo> kees: the anoying thing is that its not even really needed, just for debugging purpose
[08:10] <kees> :(
[08:10] <mvo> kees: (ImmediateAdd() is the one)
[08:12] <mvo> kees: thanks again, I will unbreak the abi again in apt and do another aptitude upload afterward
[08:12] <kees> okay, cool.  thanks for finding the break!
[08:46] <pitti> Good morning
[08:47] <pitti> slangasek: cryptsetup> great, thanks! will do SRUs today
[08:47] <pitti> StevenK: u-n-default-settings> ack, thanks
[08:47] <dholbach> hi pitti
[08:47]  * pitti hugs dholbach
[08:48]  * dholbach hugs pitti back
[08:49] <StevenK> pitti: It probably appears in component-overrides, I'll be fixing the seeds tomorrow
[08:50] <ttx> mvo: would that aptitude thing explain some installer breakage as well ? I just ran into a failure at package selection stage
[08:50]  * ttx tries to reproduce with server ISO in regular install mode
[08:50] <mvo> ttx: yes, most likely
[08:51] <ttx> mvo: ok :)
[10:07] <cjwatson> ttx: asix> ask the kernel team to add it to nic-usb-modules - it seems perfectly reasonable to me, but I'd just be proxying your request through to the kernel team anyway :)
[10:08] <ttx> cjwatson: ok, will file bug, just wanted to make sure there wasn't any size/speed/whatever conflict involved here
[10:08] <cjwatson> not especially, no
[10:08] <ttx> I guess minimodules are "mini".
[11:07] <LucidFox> siretart`, do you think it would make sense for you to join #gtkpod and join the discussion about libmp4v2 licensing?
[11:28] <primes2h> pitti: Hello, could you have a look at this please? bug #499445. It seems to be jockey related in some way...
[11:29] <primes2h> pitti: This bug has been confirmed on two different ubuntu forum post, I ask them to confirm it on launchpad as well
[12:35] <bdrung> do anyone have a armel or powerpc machine here?
[12:35] <bdrung> then please check if linphone 3.2.1-1 builds
[12:47] <asac> bdrung: is there any reason to believe that it could be a problem?
[12:47] <bdrung> asac: the ubuntu package had a patch.
[12:48] <bdrung> asac: lp #498584
[12:49] <asac> bdrung: are all the rdpends avail?
[12:54] <bdrung> asac: there is siproxd as rdepends
[12:58] <asac> bdrung: that is missing still?
[12:59] <asac> bdrung: we cannot build stuff on porter machines where not all rdepends are in archive
[13:22] <lamont> so when the machine locks up between the gdm screen and a working desktop... what's the best way to actually see WTF it's doing ?
[13:30] <bdrung> asac: the rdepends is available. why are the rdepends relevant?
[13:31] <asac> 13:59 < asac> bdrung: we cannot build stuff on porter machines where not all rdepends are in archive
[13:31] <bdrung> asac: do i as motu have access right to these porter machines?
[13:31] <asac> no
[13:31] <asac> but you asked if someone could try it ;)
[13:31] <asac> so i wanted a confirm that everything is there so i  can try it without utilizing my board ;)
[13:32] <bdrung> asac: the dependencies are there. (builds on amd64)
[13:32] <asac> kk
[13:35] <asac> bdrung: actually i think its safe to assume that we still need that
[13:35] <asac> merge
[13:36] <asac> i would suggest just to upload the merge ...
[13:36] <asac> if you really want it, i can give the sync a try
[13:36] <bdrung> k
[13:36] <asac> on the porter machine
[13:36] <asac> but armel is really slow ;)
[13:36] <bdrung> asac: can you give the porter machine a try?
[13:36] <tseliot> primes2h: it's package related and I replied in the bug report
[13:40] <asac> bdrung: feels overly accurate to me, but i can try armel if that helps. if you think it might be fixed, we can just sync and then fix again if it fails
[13:40] <asac> but as i said, i dont think its fixed
[13:40] <asac> really unlikely
[13:40] <asac> we still have gcc 4.4
[13:40] <asac> anyway. getting build dependencies now
[13:41] <bdrung> asac: there are new upstream releases in between. if it builds on armel, we should sync. otherwise merge.
[13:41] <asac> bdrung: why would it build?
[13:42] <asac> its the Werror ... thats almost certainly still a problem
[13:42] <asac> anyway, i cannot remove stuff from the chroot
[13:42] <asac> so no chance to build there
[13:42] <asac> libreadline-dev is installed by conflicts with some of the build depds
[13:42] <asac> would require admin intervention :/
[13:42] <primes2h> tseliot: Ah, ok. Thanks for the reply. I haven't tried, but are you sure b43 and ssl interfere with wl or was only a cleaning things?
[13:43] <bdrung> asac: it builds on debian (with gcc 4.3)
[13:43] <primes2h> thing
[13:43] <asac> bdrung: yes. but 4.4 is the problem
[13:43] <tseliot> primes2h: as you can see in the other bug report, wl can't be loaded if those other two modules are loaded
[13:43] <ScottK> bdrung: Unless it build with 4.4, that's pretty meaningless.
[13:43] <asac> that emits more warnings than 4.3
[13:44] <asac> which is why Werror kills us
[13:44] <asac> imo just upload the merge
[13:44] <asac> or ask for a sync and fix again if it fails
[13:44] <bdrung> k, will upload the merge
[13:44] <asac> great :)
[13:47] <primes2h> tseliot: I saw it but somewhere on Internet I read something about modules priority. I mean, it should work if you load modules in a certain way. Does this say something to you?
[13:50] <tseliot> primes2h: does "sudo modprobe --force b43 ssb" work if wl is loaded? And by work I mean do both bluetooth and wifi work?
[13:51] <primes2h> tseliot: Hold on, it's the test I was planning to do. :)
[13:51] <tseliot> ok
[13:52] <ion> I’m forced to use a proprietary driver for my BCM4322, since the free driver doesn’t support this one yet. I’ve noticed that the Windows™ driver with ndiswrapper works a lot better than bcmwl.
[13:54] <asac> dont buy broadcom wifi hardware :-P
[13:54] <asac> thats inferior stuff
[13:55] <ion> Indeed
[13:55] <asac> the fact that macs have those just shows that you get ripped off ;)
[13:55] <primes2h> tseliot: WARNING: Error inserting cfg80211 (lib/modules/2.6.31-16-generic/kernel/net/wireless/cfg80211.ko): Invalid module format
[13:55] <primes2h> WARNING: Error inserting mac80211 (lib/modules/2.6.31-16-generic/kernel/net/mac80211/mac80211.ko): Invalid module format
[13:56] <primes2h> WARNING: Error inserting ssb (lib/modules/2.6.31-16-generic/kernel/drivers/ssb/ssb.ko): Invalid module format
[13:56] <asac> sound bad ;)
[13:56] <asac> "invalid module format"
[13:56] <tseliot> primes2h: unfortunately the driver is half proprietary and it doesn't seem to integrate well with open drivers. I don't think there's anything we can do about it
[13:56] <primes2h> ERROR: Error inserting b43 (lib/modules/2.6.31-16-generic/kernel/drivers/net/wireless/b43/b43.ko): Invalid module format
[13:57] <primes2h> asac: I know :(
[13:57] <asac> sure that those files are not corrupted?
[13:57] <primes2h> asac: Tell netbook producer
[13:58] <asac> did those files come oob with netbook producer?
[13:58] <primes2h> asac: If I uninstall proprietary driver, bluetooth works again
[13:58] <primes2h> asac: I meant about broadcom hardware ;)
[13:59] <asac> primes2h: you should tell that to them ;) ... but i see the point
[13:59] <asac> you can probably order an atheros card from ebay ;)
[13:59] <asac> if you can access it
[14:00] <primes2h> ion: I gave it a try but a weird error come up when installing Win driver using ndiswrapper.
[14:01] <primes2h> ion: and it's not a workaround because you need to blacklist b43 and ssb as well to make them work
[14:01] <primes2h> asac: Less work buying a bluetooth dongle ;)
[14:01] <tseliot> that's for sure
[14:02] <tseliot> :-/
[14:02] <tseliot> primes2h: do you mind if I mark the bug report as won't fix?
[14:03] <primes2h> tseliot: It could be fixed in the future with a new version of proprietary driver I think.
[14:03] <primes2h> tseliot: Do you agree?
[14:03] <tseliot> primes2h: hopefully. Let's mark it as triaged then
[14:03] <primes2h> tseliot: bluetooth should be a broadcom as well
[14:04] <primes2h> tseliot: It's a HP one, but a Broadcom in fact
[14:04] <tseliot> primes2h: if so, one is proprietary while the other is not
[14:04] <primes2h> tseliot: Wireless+bluetooth toghether
[14:04]  * tseliot nods
[14:05] <primes2h> tseliot: What about the open source driver develop?
[14:06] <primes2h> tseliot:do you know something?
[14:06] <primes2h> DO
[14:06] <tseliot> primes2h: the driver is partially closed. I don't know if there's an open alternative, I was only volunteered to maintain the proprietary driver :-P
[14:07] <primes2h> tseliot: Ah, ok. Thanks anyway :)
[14:07] <tseliot> np
[14:10] <asac> primes2h: internal is much better because you have real superior antennas usually
[14:14] <primes2h> asac: The problem here is to have it working :P but you're right
[14:14] <primes2h> have it working in a way or in another one.
[14:34] <Ng> how does apport become aware of kernel crashes? can I encourage it to pull one out of logs from a point in time where apport was disabled?
[14:35] <persia> Ng: iff you have a .crash file available.
[14:35] <persia> If you don't, you likely don't have recoverable information about the crash.
[14:36] <Ng> hrm, that's a shame. I'll have to work on reproducing it then
[14:36] <Ng> thanks
[14:46] <james_w> Ng: you can enable kerneloops on karmic or later
[14:50] <Ng> james_w: ooh nice, that's made it write a .crash
[14:50] <LaserJock> james_w: if I have a package import that's not quite right (missing a revision), what should I do?
[14:51] <james_w> LaserJock: please file a bug against 'udd'
[14:51] <Ng> the questions apport is asking me could do with "I don't know" buttons. I don't know if this is a regression, it's brand new hardware ;)
[14:52] <LaserJock> james_w: awesome, thanks
[14:54] <primes2h> tseliot: you know? If I give "sudo modprobe b43" only it loads and load all other modules (ssb, mac80211 etc) correctly
[14:54] <LaserJock> james_w: oh, actually you already marked it Fix Released :(
[14:54] <primes2h> tseliot: but still no bluetooth... :(
[14:54] <LaserJock> james_w: bug #490574
[14:55] <tseliot> primes2h: :-/
[14:58] <ScottK> james_w: Do you have a moment to discuss a merge problem I ran into last night?
[14:58] <james_w> yes
[14:58] <ScottK> I was merging clamsmtp.
[14:58] <ScottK> They have the unfortunate habit of shipping some .SVN dirs in the upstream tarball.
[14:59] <ScottK> I went through the process of merging on the wiki and at the end, all the .SVN files showed up as diff from Debian.
[14:59] <ScottK> My guess is that the importer is helpfully excluding those.
[14:59] <ScottK> Since it's part of the upstream tarball, it really shouldn't.
[14:59] <james_w> are you being sarcastic?
[15:00] <ScottK> The helpfully part is sarcastic, yes.
[15:00] <james_w> ok, now I know how to phrase the next comment...
[15:00] <ScottK> I'm sure the exclusion made sense at the time, but it doesn't work well in this case.
[15:00] <james_w> that problem is fixed, it will work itself out over time
[15:00] <james_w> doesn't help you with this merge, but the problem is gone
[15:01] <ScottK> Is this a recent change?
[15:01] <ScottK> The Debian upload I was merging from was only a few days old.
[15:02] <james_w> it may have been
[15:02] <james_w> I'm not sure exactly when the code was deployed
[15:02] <ScottK> OK.
[15:05] <jono> anyone here know how to just merge in one file from a merge proposal?
[15:05] <jono> james_w, ^
[15:06] <james_w> bzr merge ...
[15:06] <james_w> bzr revert <everything that changed except that file>
[15:06] <james_w> bzr revert --forget-merges
[15:07] <james_w> bzr commit
[15:07] <jono> thanks
[15:57] <mr_pouit> james_w: what's the refresh rate of lp:debian/*? xfce4-terminal 0.4.3-1 is now in testing (so one week old), and lp:debian/sid/xfce4-terminal is still unaware of it, which renders merging very very easy.
[15:58] <james_w> it's supposed to be very quick, but I've had to suspend it while I debug something tricky, sorry
[15:59] <mr_pouit> ah ok, that makes sense now :>
[16:13] <geser> is there some documentation on how to "process" merge-proposals?
[16:16] <persia> geser: What worked for me (but may not work for you) was bzr branch foo; bzr merge bar; bzr commit; bzr push foo
[16:16] <persia> Launchpad appeared to notice what was done, and update things appropriately.
[16:19] <geser> persia: and on https://code.edge.launchpad.net/~abogani/ubuntu/lucid/gdb-avr/gdb-avr.fix-FTBFS/+merge/16509 I just "Approve" it? nothing else to do (besides to actually merge it)?
[16:19] <persia> geser: I was told not to do anything at all on launchpad.
[16:19] <persia> Launchpad can apparently detect the merge when you push to a target, but can't process the merge itself.
[16:19] <geser> ok
[16:21] <persia> I'm not sure about how it relates to uploads though.  I suspect you would have to both push to the branch and upload, as I doubt that LP can update the branch from an upload *and* detect that this processed the merge proposal.
[16:21] <persia> On the other hand, you might check in #launchpad :)
[16:33] <fbond> mvo: What upstream version corresponds with Ubuntu's python-apt 0.7.9~exp2ubuntu10 package?
[16:33] <fbond> (i.e. a bzr revno?)
[16:35] <mvo> fbond: I need to look that up, why?
[16:36] <mvo> fbond: should be revno 305 if I'm not mistaken
[16:38] <geser> james_w: just a quick question: I'm following https://wiki.ubuntu.com/DistributedDevelopment/Documentation/UploadingAPackage and got stuck at the "bzr mark-uploaded" step with "bzr: ERROR: Unknown target distribution: lucid". Doesn't it now about lucid?
[16:38] <james_w> geser: "debcommit -r" should work for now
[16:51] <ttx> Time to leave, have great holidays everyone
[16:52]  * slangasek waves to ttx 
[16:52] <ttx> slangasek: o/
[16:57] <douglasawh-work> turns out my dd/clonezilla issues were karmic issues, so we're having to go back to Jaunty
[16:57] <douglasawh-work> any ideas if grub2/whatever else is going on in the boot works better with dd in Lucid?
[17:05] <persia> douglasawh-work: lucid-in-progress is available for testing: you might give it a try.  The best way to make sure that it works for lucid is to test early and often.
[17:33] <statik> hi all - in the new ubuntu distributed development way of doing things, if i look at a merge and decide it should be a sync, is requestsync still the right way to handle that?
[17:36] <persia> statik: My understanding is that a sync should still be requested of the archive administrators.  I suspect that there would be some value to updating the merge proposal in launchpad to reflect the decision to request a sync in preference to a merge.
[17:37] <fbond> mvo: I'm working on an application that requires certain python-apt features.  I need to be able to specify a minimum python-apt version that works.
[17:37] <fbond> The features I'm using look like they were implemented as of bzr revno 313.
[17:38] <fbond> I have 0.7.9~exp2ubuntu10 installed and it appears to work.
[17:39] <fbond> (For instance, DscSrcPackage.required_changes was introduced in 313, and is present in 0.7.9~exp2ubuntu10.)
[17:39] <mvo> fbond: ok, a good way might be (depends on what you need exactly) something like a feature test with "hasattr" or try: except: around the required code to see if its there (or good old fashioned dependencies :)
[17:39] <statik> persia, thanks!
[17:40] <fbond> mvo: No, I mean for a README file distributed with the software I'd like to be able to say "requires python-apt version x.y.z or later".  That's alright.  I'll just say minimum 0.7.9 but Ubuntu's 0.7.9~exp2 or later appears to work.
[17:41] <mvo> fbond: ok
[17:42] <fbond> mvo: Thanks.
[17:56] <douglasawh-work> persia: sadly, I can't use Lucid because of an ATI bug which maxes out the cpu
[17:56] <douglasawh-work> all of our laptops at work have ATI cards :(
[17:56] <douglasawh-work> actually, we have one with switchable graphics, so I may give that a go
[19:09] <Keybuk> slangasek: so fixing all the VT issues does seem to solve your input issue
[19:09] <Keybuk> downside; now the smooth X transition doesn't work :p
[19:12] <ion> ...the smooth X transition worked at some point?
[20:56] <micahg> james_w: is bzr merge-package only for debian imports?
[21:44] <shlomi> Hi , I need help fixing/exploring a bug. Can someone please tell me what software in ubuntu is in charge of creating the isolinux translation files (*.tr) on the CD ?
[21:46] <shlomi> A reference to some doc about iso building process might help to ...
[21:54] <cody-somerville> shlomi, I believe the translations are kept in the gfxboot-theme-ubuntu and are translated using Rosetta
[23:35] <james_w> micahg: it's not exclusive to them, but other branches may not be set up to use it
[23:41] <slangasek> james_w: hey, is there a way to know what commands are run (or what branches are being worked on) that trigger http://package-import.ubuntu.com/failures/.bzr/failures/ ?  e.g., http://package-import.ubuntu.com/failures/.bzr/failures/quilt seems like it should be fixable by adding the tag, which I've done to try to do a merge-package, but I don't know if what I've done should fix this issue
[23:44] <slangasek> james_w: and I guess the importer doesn't do v3 yet? :(
[23:57] <micahg> james_w: ok, yeah, the error I get it about a tag, so I guess I'll just do a regular merge on the branches