[00:05] <cjwatson> -                if 'DONE' in f or 'POSTPONED' in f or 'TODO' in f or 'INPROGRESS' in f:
[00:05] <cjwatson> +                if 'DONE' in f or 'POSTPONED' in f or 'TODO' in f or 'INPROGRESS' in f or 'WIP' in f:
[00:05] <cjwatson> nixternal: ^- committed, should fix that
[00:08] <nixternal> cjwatson: rock on! thanks!
[00:08] <cjwatson> it'll probably take an hour or two before pitti's cron job picks that up
[00:09] <nixternal> that's cool...really appreciate that...I was just going to change them all on the wiki page, but you made that easier :)
[00:20] <maxb> I don't suppose there is any way to convince update-manager that a *specific* third-party repo should not be disabled on distro upgrade, is there?
[00:26] <james_w> maxb: the feature was just added I think
[00:26] <james_w> there's some config somewhere
[00:27] <maxb> I shall go grepping then
[00:28] <maxb> Of course, if it has just been added, it'll be several years before all my colleagues are using a suitable version of Ubuntu :-)
[00:29] <cjwatson> maxb: add it to /usr/share/update-manager/mirrors.cfg?
[00:29] <cjwatson> I think that works
[00:34] <james_w> maxb: there's bug 147080 for coarse-grained
[00:45] <yoasif> i have a possible bug, but i don't know where to file it
[00:45] <yoasif> basically, all of the alpha-1 cds have the same name (ubuntu, xubuntu, kubuntu), which makes it a chore to seed all of them on bittorrent (or even to store them).... any ideas where to file this?
[00:46] <cjwatson> yoasif: already filed as bug 199660
[00:47] <cjwatson> (Invalid because it was moved to ubuntu-cdimage; but I do suggest you find a workaround anyway, it's painful to change because it would break everyone's scripts)
[00:47] <yoasif> cjwatson, thanks, still kinda lame
[00:47] <cjwatson> how polite
[00:47] <yoasif> hmm?
[00:55] <maxb> Is notify-osd broken in lucid, or is the funky grid of orange lines some sort of debug aid?
[00:59] <maxb> cjwatson: Thanks for the mirrors.cfg pointer. I think you are right about the filename, but I think the copy that is actually used is shipped in the release-upgrader tarball. Hmm. But now I have ideas about overriding it using /etc/update-manager/release-upgrades.d/
[01:07] <Rocket2DMn> doko, what?
[01:07] <ebroder> lies
[01:07] <ebroder> Sorry - wrong window
[02:04] <kees> james_w: is the documentation out of date or am I doing something wrong with these merges?
[02:05] <kees> $ bzr mark-uploaded
[02:05] <kees> bzr: ERROR: Unknown target distribution: lucid
[02:05] <james_w> is a bug
[02:05] <james_w> you can ignore it for now
[02:05] <james_w> so I guess the documentation is out of date :-)
[02:05] <kees> heh
[02:06] <kees> james_w: it would be nice to have changelog merging working better and something that does the dpkg-genchanges -S -v... stuff.  Is that on the list?
[02:06] <kees> james_w: it's currently harder to do merges with bzr, since MoM does this stuff for you automatically.
[02:06] <james_w> the changelog merging is on the list
[02:07] <kees> I'm worried we're going to start losing merged changelog history if people aren't helped to do the dpkg-genchanges call.
[02:07] <kees> anyway, must run away to dinner...
[02:07] <james_w> we could add a --merge flag to "bzr bd"
[02:07] <james_w> that can look at the changelog and do the right thing
[02:07] <james_w> it's not possible to do it automatically
[02:08] <Keybuk> all mark-uploaded does is tag, right?
[02:09] <james_w> yeah
[02:09] <Keybuk> so debcommit -r DTRT for now :p
[02:09] <james_w> indeed :-)
[02:10]  * maxb wonders if anyone is interested in sponsoring a merge of Subversion?
[02:37] <sam_> Hi,After I finish a dpkg-buildpackage I modify some .conf files but no .c source files, I want to update the modified .conf files into the .deb file, how can I use dpkg-buildpackage command to avoid re-compile all the .c source files:
[02:38] <Amaranth> If you're just building it for yourself you can use debuild binary
[04:14] <DNS777> hey guys, do you have a simple guide for me how to make a proper ubuntu/debian package? :-)
[04:15] <fabrice_sp> !packagingguide
[04:15] <fabrice_sp> DNS777, ^
[04:16] <DNS777> ty :)
[04:17] <fabrice_sp> yw ;-)
[04:20] <YokoZar> jcastro: I want to make a wiki page link to "upstreaming bugs" to describe the process, which page should I point it at?
[04:21]  * YokoZar is modifying the Testing Team pages to mention how important upstreaming bugs is when they're found in the development release
[04:22] <jcastro> YokoZar: https://wiki.ubuntu.com/Bugs/Upstream
[04:23] <jcastro> YokoZar: feel free to grab an existing subpage and make a wine-specific one if you want
[04:23] <YokoZar> not wine related ;)
[04:23] <YokoZar> jcastro: that was my thought, but that page doesn't seem too friendly in its current form.
[04:23] <YokoZar> https://wiki.ubuntu.com/Bugs/HowToTriage at "Forwarding upstream" links to that page too, but it doesn't seem to have the promised content
[04:23] <YokoZar> namely "details on how ot report bugs in various upstream bug trackers"
[04:24] <jcastro> yeah
[04:24] <jcastro> the idea is that each of those sections is specific to that project
[04:24] <jcastro> as you can see we only have the major ones
[04:24] <YokoZar> I guess I was expecting a brief paragraph or two on why we upstream in general and what it is on that page
[04:24] <jcastro> but anyone is welcome to add anything, like the Listen folks did
[04:24] <jcastro> I suppose I could add something like that.
[04:24] <jcastro> can you send me a mail and I'll todo it?
[04:25]  * jcastro is only half-way working right now. :p
[04:25] <YokoZar> Will do.  Thanks :)
[05:01] <ebroder> If you hit 'c' at the aptitude [Y/n/?] prompt, you might get something useful
[05:02] <ebroder> Oof - wrong window
[06:11] <kees> james_w: it's possible to do it automatically -- just lookup the version in LP for that suite
[06:48] <pitti> Good morning
[07:14] <geser> good morning pitti
[07:53] <dholbach> good morning
[08:00] <tbielawa> morning
[08:01]  * ruffus910 waves hello
[08:12] <slangasek> Keybuk: dropping the "starting-dm" event - wasn't ubiquity integration also dependent on this?  and will gdm declare a Breaks: on usplash, to help users avoid getting wedged if there's a reboot mid-upgrade?
[08:30] <ttx> cjwatson: testing the eucalyptus update, it appears that the SC cannot announce itself on a CC+SC setup (local name conflict because SC_NAME = CC_NAME)
[08:31] <lool> james_w: Cool, thanks a lot!
[08:34] <ttx> cjwatson: maybe we should place the information about "target cluster" in a TXT record as well
[08:34] <ttx> -s doesn't seem to scale :)
[09:30] <zheng> Hi, I'm new to use dpkg-buildpackage for .deb, how can I add a user after I install a ????.deb?
[09:31] <zheng> Is there a scipt to add user in the .deb? how can I call it?\
[09:41] <jiboumans> zheng: lots of existing packages do it already (mysql and apache come to mind), you could take a look at those and follow their lead
[09:42] <zheng> jiboumans, hi, thx in advance,
[09:43] <zheng> I test it with postgresql, when I install postgres from internet with "apt-get isntall postgresql", it will add a user: postgres;
[09:44] <zheng> but when I download the postgresql's source with "apt-get source", then I dpkg-buildpackage it, but I dont add user for me this time.
[09:45] <zheng> but when I download the postgresql's source with "apt-get source", then I dpkg-buildpackage it into the .deb, then I install these .deb file, but It dont add user for me this time.
[10:03] <zheng> hi, jiboumans, I get it, I add some script in debian/postinst.ex
[10:10] <DNS777> did any1 tried to compile the mumble-1.2.0 ?
[10:11] <DNS777> i have a lot of errors with that :-(
[11:05] <Keybuk> slangasek: I put a breaks on usplash
[11:05] <Keybuk> if ubiquity was depending on it, then that was definitely a bug ;)
[11:05] <Keybuk> cjwatson: if you were using starting-dm, use starting gdm instead
[11:30] <james_w> kees: true, but I would like to work offline where possible
[11:37] <Lure> pitti: have time to discuss one karmic sru?
[11:39] <pitti> Lure: just ask :)
[11:42] <Lure> karmic shipped with beta5 version of digikam (as upstream release schedule slipped twice)
[11:42] <Lure> we have one highly visible crasher - bug 454113
[11:42] <Lure> so I suspect the only way for sru is to backport individual fixes (one-by-one)?
[11:43] <Lure> no way to bend rule to go with final in such case?
[11:43]  * Lure has done backports, but seems many do not have them enabled and not get fixes
[11:44] <Lure> pitti: ^^^
[11:49] <pitti> Lure: depends if _all_ changes between beta5 and final conform to SRU requirements
[11:49] <pitti> if they do, shipping the entire upstream release is okay
[11:49] <pitti> but the default mode is "backport that one patch"
[11:58] <dholbach> if anybody could moderate ubuntu-devel-announce I'd appreciate it :)
[12:00] <Lure> pitti: they don't - problem I see that there are also string changes (due to string freeze on rc)
[12:00] <chrisccoulson> hello dholbach
[12:00] <dholbach> hey chrisccoulson
[12:00] <chrisccoulson> how are you?
[12:00] <Lure> pitti: ok, can I at least prepare multiple bugfixes in one sru upload?
[12:00] <pitti> Lure: seems like backporting would be safer then
[12:00] <dholbach> chrisccoulson: good good - how about you?
[12:01] <pitti> Lure: sure, just make sure to attribute the individual patches to their bug reports
[12:01] <chrisccoulson> dholbach - i'm quite tired, but i finish work for the week in an hour :)
[12:01] <dholbach> yeeehaw :)
[12:01]  * dholbach hugs chrisccoulson
[12:02]  * chrisccoulson hugs dholbach
[12:02] <directhex> no hugs for me? :(
[12:02]  * dholbach hugs directhex too
[12:03] <directhex> yays
[12:06] <pitti> doko_, robbiew_: for bug 417757, would it be ok to just upload the reapplied patch and thus unfix the two other bugs again? I have to agree to the folks there that it's indeed urgent
[12:15]  * chrisccoulson hugs directhex too
[12:15] <directhex> \o/
[12:15] <sebner> poor directhex :P
[12:15]  * sebner hugs directhex too
[14:00] <doko_> pitti: please let's check this in lucid first (will upload after the gcc-4.4 builds are in the archive)
[14:09] <emgent> cjwatson: around?
[14:46] <superm1> pitti, would it be feasible to specify flags and commands that upstream wants gdb ran with in apport  hooks?
[14:50] <pitti> superm1: not currently, but of course you could change the code to append a field GdbFlags: to the gdb options
[14:51] <superm1> pitti, okay. well i'll need to see exactly what's missing and look into doing that then
[14:52] <pitti> superm1: what would be an example option you'd be interested in?
[14:52] <superm1> pitti, so here's exactly what upstream asks for: http://www.mythtv.org/docs/mythtv-HOWTO-22.html#ss22.2
[14:53] <superm1> i haven't compared exactly what is different with the commands applied to gdb on all traces, but upstream was saying that with our (newly functional!) traces that we're submitting upstream, they weren't exactly that
[14:56] <pitti> superm1: hm, most of the gdb options there just seem to affect the gdb CLI, not the trace output?
[14:57] <superm1> pitti, ah yeah i think your right
[14:58] <superm1> pitti, so when working with a coredump they're N/A.  I'll punt this question back at upstream then to get a specific for what they're not liking about the new traces, they should be useful, although just not the exact same format they're used to seeing
[15:19] <lool> kirkland: Hey
[15:20] <lool> kirkland: I see you made the transitional qemu depend on qemu-kvm
[15:20] <lool> kirkland: Why not -extras?
[15:21] <lool> kirkland: e.g. qemubuilder depends on qemu | kvm, we could transition it to the new packages and/or have the transitional packages point at the corresponding new places for the binaries
[15:46] <kees> james_w: well, you can't "bzr branch" or "bzr push" or "dput" when offline, so it doesn't seem to bad that you can't do your final upload prep (dpkg-genchanges) until you're online too.
[15:46] <james_w> but if I have the branch prepared and I want to test build then I do a dpkg-genchanges
[15:49] <james_w> perhaps we could do something with a marker set by merge-package
[15:49] <james_w> I'm a bit nervous about that though
[15:50] <james_w> plus, when sponsoring it's not the person that does the merge that usually does the dpkg-genchanges
[15:50] <james_w> and MoM doesn't currently help with that anyway
[16:16] <geser> jdstrand: do you know why there are so many unprocessed sync requests? (like e.g. 489631)
[16:17] <jdstrand> geser: two thoughts: a) resources and b) source format 3.0 (quilt)
[16:17] <jdstrand> geser: I'm on today, but haven't started processing them
[16:18] <geser> does b) also stop syncs from format 1.0 packages?
[16:19] <slangasek> it means that archive admins' time is taken up playing whack-a-mole with the 3.0 stuff for the autosyncs
[16:19] <geser> ah
[16:58] <hyperair> has anyone here heard of an issue regarding pulseaudio and usb headsets?
[16:58] <hyperair> lag in audio, or something like that
[16:59] <hyperair> dtchen: ^^ ?
[17:32] <micahg> pitti: can I chat with you about ubuntu-bug?
[17:41] <slangasek> pitti: where does the code for this new pm-utils-powersave-policy package live?  And is this package being installed by default?
[17:42] <slangasek> pitti: (the SATA link power management stuff still concerns me, due to the impact for anyone who's hitting swap)
[17:43] <jdong> slangasek: out of curiousity, how bad is the latency when SATA goes into ALPM?
[17:43] <slangasek> jdong: I never measured it except holistically
[17:43] <slangasek> and by that measurement, it was "pretty bad"
[17:44] <jdong> slangasek: ouch. Heh I've only done the same also, and surprisingly I didn't feel the hit. Maybe I'm spoiled with RAM and don't hit swap
[17:44] <slangasek> I knew I was memory-constrained already, at the time; I've since solved that underlying bug
[17:47] <jdong> *nods*
[17:47] <jdong> well honestly Linux interactivity (ahem) sucks whenever hitting swap in any form...
[17:47] <jdong> but yeah, I can totally see how a couple ms of a sleeping SATA link could exacerbate things
[17:49]  * jdong wonders what happened to Con Koliva's work with swap prefetching
[17:52] <Trewas> jdong: it wasn't accepted to the mainline kernel because no-one could provide hard numbers how/when it helps, and then con pretty much gave up
[17:52] <jdong> *nods*
[17:53] <jdong> it's annoyingly challenging to find ways to quantify desktop interactivity, unfortunately
[17:53] <Trewas> agreed
[17:53] <jdong> Phoronix does it by... umm... measuring 10000 SQLite inserts with a BFS kernel
[17:53] <jdong> (WTF?)
[17:55] <fta> doko_, pitti: are you still working on the ipv6 resolver bug?
[18:07] <fbond> Hi.  When the update-notifier window is popped up and then sent to the background it briefly steals my keyboard focus.  Does anyone know if this has been reported as a bug?
[18:20] <slangasek> ScottK: thanks for getting boost1.40 on its feet - fwiw, boost-graph-parallel fails to build because it depends on mpi, so I'm culling it entirely from the package now (there was still one reference in debian/control)
[18:21] <ScottK> slangasek: OK.  Thanks.  I thought I saw some reference upstream to graph and graph-parallels being merged.
[18:21] <ScottK> slangasek: Also ajmitch has a patch for the boost-python problem he's been on the verge of uploading for some time.  You probably ought to get that from him.
[18:21] <slangasek> ajmitch: ping?
[18:23] <slangasek> what's currently broken wrt boost-python?
[18:23] <ScottK> I don't remember, but it affects Karmic too.
[18:23] <ScottK> It doens't hit many packages, but the ones it does it hits hard is all I remember
[19:36] <kees> pitti: still around?
[20:00] <ajmitch> slangasek: pong
[20:00] <slangasek> ajmitch: hey - ScottK says there's a boost-python fix I should be talking to you about
[20:00] <ajmitch> slangasek: yes I talked to ScottK yesterday, thanked him for getting the merge in, I have free time today to upload again
[20:01] <slangasek> ajmitch: ok - not knowing when you'd be around, I went ahead and uploaded my boost fix separately; I guess those builds are now far enough along that it doesn't matter whether the next upload happens now vs. later
[20:01] <ajmitch> or if you prefer to upload, patch is in boost1.40 in https://edge.launchpad.net/~ajmitch/+archive/ppa
[20:02] <ajmitch> ok
[20:02] <ScottK> Either way, I no longer TIL Boost, so it's a win.
[20:02] <ajmitch> heh
[20:02] <slangasek> :-)
[21:16] <smoser> kirkland, around ?
[21:22] <maxb> I have a merge of Subversion pending sponsorship. Should I just continue to wait and hope? Or should I contact anyone in particular?
[21:23] <ScottK> maxb: Wait and hope.  You didn't happen to fix the lack of kwallet integration did you?
[21:26] <maxb> I didn't test it, being firmly in gnome land, but the Debian changes being merged included turning that on
[21:26] <maxb> Although I'm now having a sudden wondering whether it'll still build in a main-only environment
[21:27] <ScottK> maxb: If it builds, that's better than it did before.
[21:28] <ScottK> There's a bug on that you can take credit for fixing in debian/changelog then.
[21:30] <maxb> Ah, kdelibs5-dev is in main, I'm safe
[21:31] <ScottK> All of Kubuntu is in Main, so kdelibs is a safe bet.
[21:31] <ScottK> maxb: Since you fixed kwallet, I'll have a look at it.  What bug?
[21:32] <maxb> bug 483953
[21:32] <ScottK> Looking
[21:35] <ScottK> maxb: Explicitly listing the supported versions is preferred over 'all' in the new Debian Python policy that's in draft.  If that's the only change i have, I'll adjust that and upload.
[21:35] <maxb> Hm
[21:36] <maxb> That is a shame, because it's a cause of debian/ubuntu delta
[21:36]  * maxb hunts the text of the draft
[21:37] <ScottK> maxb: http://lists.debian.org/debian-python/2009/12/msg00009.html
[21:38] <ScottK> maxb: We were originally going to explicitly deprecate all, but since it's unfortunately quite common in the archive we thought it would be too soon for that.
[21:39] <maxb> Install of "all", we could make it say ">= 2.something" instead, and that would be OK ?
[21:40] <ScottK> Yes.
[21:40] <ScottK> maxb: What does it say in Debian right now?
[21:40] <maxb> It says individual versions
[21:41] <maxb> I changed it so the Ubuntu delta didn't itself have to be adjusted when Ubuntu changed its own default Python version, with a view to feeding that back to Debian
[21:42] <maxb> uh, s/default version/set of supported versions/
[21:44] <ScottK> Let me look
[21:44] <ScottK> maxb: What Debian has is OK.
[21:45] <ScottK> That it covers more Python versions than we have is not a problem.
[21:45] <ScottK> That's meant to be a list of versions it could support, not just the ones used in the current release.
[21:45] <ScottK> If that's the only diff, this should be a sync.
[21:46] <maxb> Oh, no, that's far from the only diff
[22:00] <ScottK> maxb: Would you please do up a debdiff for me then?
[22:00] <maxb> ScottK: Sorry, did I miss anything in the netsplit?
[22:01] <ScottK> maxb: I asked you to make a debdiff for me.
[22:01] <ScottK> This new fangled bzr stuff I'm still working on learning.
[22:01] <maxb> Heh
[22:01] <maxb> We didn't reach a conclusion (that I saw) on what the XS-Python-Version: should look like
[22:02] <maxb> Also, owing to how part of the work I did with this merge was stitching up some weirdness that the bzr importer created, it really needs to actually be bzr pushed, rather than letting the importer re-derive it from an upload
[22:04] <ScottK> maxb: Oh, here's what I said on that:
[22:04] <ScottK> That it covers more Python versions than we have is not a problem.
[22:04] <ScottK> That's meant to be a list of versions it could support, not just the ones used in the current release.
[22:05] <ScottK> So it's fine as is from Debian.
[22:06] <maxb> In that case, I guess I'll just uncommit the last revision from the bzr branch
[22:08] <maxb> Or should I re-add 2.4, which we previously dropped, as an Ubuntu delta?
[22:09] <maxb> The latter, I guess
[22:11] <ScottK> It does no harm, so don't diverge over it.
[22:14] <maxb> Is there any convention on where in the changelog I should write LP bugnumbers closed by merge of Debian changes?
[22:15] <ebroder> Probably on the "Merge from Debian" line?
[22:15] <slangasek> I find all the available options unsatisfactory, personally :)
[22:16] <ScottK> slangasek: For which point?
[22:16] <slangasek> ScottK: for LP bugnumber convention on fixes merged from Debian
[22:17] <ScottK> Ah.  Right.
[22:18] <maxb>   * Merge from debian unstable (LP: #483953).
[22:18] <maxb>     Includes enabling kwallet support (LP: #481792, #466078).
[22:18] <maxb>     Remaining changes:
[22:18] <maxb> ^ Acceptable ?
[22:19] <ScottK> I'd go for that.
[22:22] <cody-somerville> lmao
[22:22] <cody-somerville> Due to a bug in Debian's infrastructure a ton of stuff migrated to testing from unstable when it shouldn't have.
[22:23] <ebroder> "Whoops"
[22:23] <cody-somerville> So much for the little experiment of syncing from testing instead of unstable, lol.
[22:23] <ScottK> maxb: I have to run out for a while, so just shove your debdiff in the bug and i'll look at it later.
[22:23] <ScottK> cody-somerville: It'll be more important later anyway.
[22:23] <ebroder> Hmm...I'm waiting for a package to hit testing. I wonder if it was affected
[22:23] <maxb> ScottK: Thanks - did you see my comment about needing the branch pushed too, even if you upload by the debdiff?
[22:24] <ScottK> maxb: I did, but I didn't understand it.
[22:24] <ScottK> We can chat later as I really need to run.
[22:24] <maxb> I shall elaborate upon it in the bug
[22:24] <ScottK> OK.  Good
[22:25] <Czesiu> Hello
[22:25] <Czesiu> Could you tell me what's wrong with call: requestsync -d unstable rrdcollect 10.04?
[22:26] <Czesiu> Replacing 10.04 with lucid also doesn't work as expected
[22:26] <maxb> Nothing obviously wrong, what breaks?
[22:26] <Czesiu> I'm using ubuntu-dev-too 0.83debian1 from
[22:26] <Czesiu> E: The versions in Debian and Ubuntu are the same already (0.2.4-2). Aborting.
[22:26] <maxb> lucid is correct here, 10.04 is not, I would say
[22:27] <Czesiu> But there is new release in unstable at the moment
[22:27] <maxb> How recently uploaded?
[22:27] <Czesiu> 4 days ago
[22:27] <maxb> Hmm
[22:28] <Czesiu> hm, I checked 6 days ago
[22:28] <maxb> Ok, it breaks for me too, this seems like a bug
[22:29] <Czesiu> Thanks, I'll report it.
[22:30] <maxb> Czesiu: Wait 5 minutes please, I'm just investigating
[22:30] <Czesiu> ok
[22:31] <maxb> Hmm, LP itself knows about the new version
[22:32] <Czesiu> May I check it too?
[22:32] <maxb> What do you mean?
[22:34] <Czesiu> maxb: what LP knows about the latest release from Debian
[22:34] <maxb> You may see it here: https://launchpad.net/debian/sid/+source/rrdcollect
[22:35] <Czesiu> maxb: oops, I've never look carefully on that page :)
[22:41] <maxb> Czesiu: I'm completely confused as to why requestsync is getting it wrong, but I can't find anything wrong with what I get if I manually drive the Launchpad API, so I think a bug on requestsync is the right way to go
[22:42] <Czesiu> maxb: I see there is new version on Debian. I'll upgrade it and if the bug persists I'll report it
[22:46] <maxb> Czesiu: Oh. bah. It's apparently hitting some php script instead of launchpad :-/
[22:46] <maxb> I didn't know about that
[22:49] <maxb> Czesiu: It's apparently getting confused because the new version has not build on all architectures in Debian
[22:49] <maxb> You can check it yourself with rmadison -u debian -a source -s unstable rrdcollect
[22:50] <Czesiu> maxb: hm, it's not build only on hurd-i386, which is not release critical IIRC
[22:50] <maxb> Indeed. But it's enough to accidentally confuse requestsync
[22:51] <Czesiu> maxb: thanks, I will add this suggestion to bugreport too
[22:51] <michalski-bj> is Cody Somerville in by chance? (online, avail.)
[22:52] <michalski-bj> need to ask him a few questions
[22:52] <maxb> Czesiu: Please add the actual current output of "rmadison -u debian -a source -s unstable rrdcollect" to the bug report as well
[23:03] <maxb> Hmm. What is ScottK likely to have wanted a debdiff *against*, given this is a new upstream version?
[23:03] <ScottK> maxb: The current Debian version.
[23:04] <maxb> Aha
[23:04] <ScottK> I've already pulled that from Debian.
[23:07] <mun24> how to get the error code for connect socket error -1
[23:08] <Czesiu> maxb: thanks for support. #560758 has been submitted to Debian BTS.
[23:08] <maxb> errr, the *debian* bts?
[23:09] <maxb> requestsync is an ubuntu program
[23:09] <Czesiu> maxb: right. I'm developing on Debian, but I also try to take care of ubuntu bugs reported for my packages. And I am using ubuntu-dev-tools available in Debian
[23:10] <maxb> Ah. It would probably be best to have filed the bug "upstream" in Launchpad
[23:10] <ccheney> does linux just work out of the box with 4k sectors?
[23:10] <ccheney> http://www.engadget.com/2009/12/11/western-digital-advanced-format-promises-slight-boost-in-usabl/ <- saw this a few min ago
[23:11] <Czesiu> maxb: hm, let me check that, I'm still not accustomed to launchpad :)
[23:12] <directhe`> ccheney, man mkfs.ext2
[23:12] <ccheney> ah found this thread too http://www.gossamer-threads.com/lists/linux/kernel/1039141
[23:13] <directhe`> oh, hardware drivers need support too? hadn't thought of that
[23:14] <ccheney> oh ugh this is another one of those we need uefi immediately things
[23:16] <ccheney> "Most likely, the universe will explode at this time..." ;-)
[23:16] <maxb> ScottK: I'm afraid your advice about it being OK to include versions of Python we don't have in XS-Python-Version is apparently not correct.
[23:16] <maxb> The build is FTBFS in my PPA
[23:18] <directhe`> ccheney, what's wrong with regular EFI? all the cool kids have EFI
[23:21] <Czesiu> maxb: I see that developer of Debian package for ubuntu-dev-tools is also a member of the same team on LP, so I left it as it.
[23:23] <ccheney> directhe`: hmm i thought it was all uefi now, i haven't actually ever seen a system with it other than macs (and on those never seen what theirs looks like)
[23:23] <ccheney> we should be seeing a lot of *efi soon though as 2TiB is limit for bios aiui
[23:24] <ccheney> directhe`: as best as i can tell current efi is called uefi
[23:27] <directhe`> ccheney, i have itanium kit with EFI, and a mac with EFI
[23:28] <directhe`> ccheney, iirc the only "normal" systems with EFI are a limited number of motherboards from MSI
[23:28] <directhe`> plus you need Vista x64 SP1, or Windows 7, to boot EFI in "native" mode, so that's hindered adoption somewhat
[23:37] <ccheney> directhe`: yep, but the limit of 2TiB drives should force more deployment of EFI soon
[23:37] <directhe`> ccheney, you'd think so
[23:37] <directhe`> ccheney, 32-bit windows is still popular amongst people with 4 gig of ram...
[23:38] <ccheney> directhe`: heh yea
[23:45] <ScottK> maxb: Weird.  OK.
[23:45] <ScottK> maxb: Where's the build log?
[23:45] <maxb> https://launchpad.net/~maxb/+archive/ppa/+build/1391193/+files/buildlog_ubuntu-lucid-amd64.subversion_1.6.6dfsg-2ubuntu1~~testbuild1_FAILEDTOBUILD.txt.gz
[23:46] <maxb> I've just done a local cowbuilder build with XS-Python-Version: >= 2.4, and that works. I'd like to go with that, if it's acceptable to you
[23:46] <ScottK> maxb: That's good.
[23:47] <maxb> peterS will likely take that into Debian, I would imagine
[23:50] <ScottK> maxb: That's, IIRC, explicitly preferred in the new draft Python policy, so I would hope so.
[23:50] <ScottK> maxb: I think that's a Python support bug, btw (your build failure).
[23:51] <maxb> I can believe that
[23:53] <ScottK> Would you please file an Ubuntu python-support bug on that?
[23:53] <maxb> It'll take more research than I have time for tonight, but I'll scribble myself a note
[23:54] <ScottK> Thanks.
[23:59] <maxb> ScottK: Do you mean python-support? pyversions is contained in the 'python' source
[23:59] <ScottK> maxb: I do because I think it's python-support that is interpreting the field.  Subscribe me to the bug and I'll move it if need be.
[23:59]  * ScottK has to run again.