[00:07] SpamapS: Oooh, while you're here - is there a way of extracting the changes file from the unapproved queue? [00:08] RAOF: the name of the package in the queue listing is a link to the changes file [00:09] bug 806940 is part of this [00:09] Launchpad bug 806940 in Ubuntu Distributed Development "conflict if a dir is created in an udd branch" [Undecided,New] https://launchpad.net/bugs/806940 [00:09] though, perhaps eventually that will be duped onto a more generic one [00:09] SpamapS: …oh. Bah! :) [00:11] What path does patches to the Ubuntu Xorg Intel driver take? Xorg.freedesktop -> Debian -> Ubuntu? [00:12] * SpamapS signs off for the day [00:14] Yewbacca: Generally, yes; we're not slavish about it, though. [00:14] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [00:28] RAOF: Thanks for the reply. I was working with Wu Fengguang of Intel fame on fixing two major problems. ELD autodetection over HDMI support now added, meaning the HDMI output finally supports multichannel audio rather than just stereo. [00:28] The other fix involves reading the extended CEA mode block to finally detect all display modes rather than just the ones that fit in the basic mode block. [00:28] These are major fixes and I am concerned with how we can get them into Ubuntu's driver quickly. [00:28] They've been reviewed at Intel and released to the Xorg mailing list. [00:29] But they're of course drowning in all the other patches and discussions. [00:29] Right. [00:30] Do you have any suggestions? Should I focus on alerting Xorg.freedesktop.org to it and then let it trickle to Ubuntu? Or do you sometimes apply important fixes on your own and if so, who do I talk to? [00:30] That would involve both kernel and DDX fixes, yes? In either case, we really do prefer that patches are at least applied to a development tree. These sound like fairly large changes, so we'd want upstream to have signed off first. [00:30] TheMuso, hi [00:31] poolie: Good morning. [00:31] Actually they're only DDX modifications :) [00:31] hi [00:32] i just saw your post about the pulseaudio packaging branch [00:32] Oh yeah and I see your point, I'll alert some Xorg maintainers to review and apply them there first. Thanks for the advice. [00:33] Yewbacca: Then that's a bit easier :). Still, we'd prefer them to be upstream first. [00:33] poolie: The desktop team maintains similar branches for desktop packages as well. [00:33] similar in the sense of debian-only [00:33] Right. [00:33] is this mostly for the sake of faster checkouts of it? [00:34] as you know the general plan is to get the ubuntu namespace branches being official, and being complete branches [00:34] poolie: No, its because thats how they were originally stored in bzr since before I really got involved with audio packaging. [00:35] RAOF: Thank you. I'll talk to some Xorg maintainer. Have a good night :) [00:35] do you think we could migrate them to the standard form at some point? [00:35] that would remove a special case from the piloting/contribution process [00:35] Yewbacca: I'm in UTC+10. It's a good day for me. Have fun with upstream :) [00:36] poolie: Actually I was hoping to eventually move Ubuntu packaging to Debian git. [00:37] hm, really? [00:37] poolie: And what about the ubuntu-desktop packaging? How does that go in terms of patch piloting? [00:37] because you're also the debian mantainer? [00:37] poolie: Yes, easier to pull from either side patch wise. [00:37] THe X guys do the same thing, I do the same thing with accessibility packages, and I am sure others working on Ubuntu, like the multimedia/MOTU guys do as well. [00:38] the same thing here meaning maintaining it on debian.org, or meaning having only debian/ versioned? [00:38] The same thing as in Ubuntu packaging maintained in alioth/debian git vcs. [00:40] hm, ok [00:40] so, this seems like a plan around having lp branches and contributions on lp may be on the wrong track [00:41] poolie: *Or* launchpad grows git support, I guess :) [00:41] Yeah that too. [00:41] so, what would happen in that case? [00:42] pkg-cli-* and pkg-mono also have all their canonical branches in alioth git. I think it's a fairly popular mode of operation. [00:42] you'd have the ubuntu branches on lp, but be able to more transparently merge them? [00:42] or they'd stay primarily on alioth? [00:43] They'd probably stay primarily on alioth, but we could pull merges from launchpad. [00:43] That said, git is terrible at that workflow. :( [00:43] I'm not sure. If the ubutu branches were on alioth, thats the only place I'd want to work with them. [00:43] SO yeah, merging from lp would be useful. [00:44] i mean there's no point in adding that support, which might not be cheap, if it's not actually helping ubuntu [00:45] It would help Ubuntu insomuch as merge requests against UDD branches would be useful. [00:46] it seems like one of the things that makes them problematic at the moment is that people do the work essentially in the wrong place [00:46] either directly in the tree when it should be in patches, or in an ubuntu branch when it should be an upstream change [00:47] one of the working assumptions was that having different branches be more consistent (eg whole tree etc) would make that a simpler story to do properly [00:51] raof, so would having the merge proposals be useful as compared to having patches on the bugs, or patches on debian bugs for that matter [00:51] Patches on the bugs are great; debdiffs on bugs are also great. [00:52] Patches on Debian bugs are also fine, but our stack is generally different enough that there are a fair number of bugs which aren't in common, and you need to be running Debian on bare-metal to usefully report a Debian bug on the stack. [00:53] poolie: One of the general issues I have with UDD (or any of its predecessors) is statements about "doing work in the wrong place". [00:54] poolie: Any contribution is the right place, and debdiff, or simple patches are all perfectly fine. [00:54] because it can always be moved around later? [00:54] poolie: (I'll admit that this sometimes makes the UDD stuff feel more like a hundrance than a help, but there must be clever ways to make it all work together more smoothly) [00:55] i guess what i'm really asking is, how can canonical's infrastructure best be helping ubuntu? [00:56] poolie: I dunno. I might be in a vanishing minority, but I'd like to be able to just do dpkg-source work the way I've always done and upload a dsc/diff/tar/orig that integrates seamlessly into branch-based work other people want to do. We're sort of there, and imports mostly work, but not quite. And it's discouraging when people blame it not working on "the old way" being "the wrong way". [00:57] poolie: But, some people love the shiny and new here too, so saying it's not worth making it as shiny as possible if it's not the way old farts like me work isn't helpful either. It seems like a real value add. It's just a value-add *I* don't care about. :) [00:59] (And I realise I missed out on half the conversation here, and this is just a drive-by commenting on my way to beer, but if you want actual opinions, ask me sometime. You know I'm full of 'em, some even useful) [00:59] :) [01:03] For me personally, I am happy working in alioth with git, because everything I track upstream uses git, which at times, can be very handy should one want to make a git snapshot release for a package. Just merge a git branch into the upstrea branch locatino or whereever you want, cherry-pick individual commits, etc. Bzr's biggest advantage is its merge algorithm however. [01:03] gah typing. [01:03] infinity: i see your point about not wanting to denigrate things people are doing that are working [01:04] obviously technically the importer is supposed to handle merging them together and it generally does [01:04] so themuso, if you were writing our plan for the next year (for udd/lp/bzr), what would you ask for? [01:06] poolie: I am not the one to ask. Like infinity, I am happy with existing tools, and don't care much for UDD, probably because the majority of thigns I touch already are in alioth git, or will soon be. [01:07] I don't mind having to do the extra legwork to make sure a particular patch author is credited for their work properly in a vcs. [01:08] SO I guess all I'd prefer is patches/debdiffs. [01:08] so your answer is essentially, "don't get in the way of using allioth?" or "improve the bug tracker instead?" or something? [01:08] Actually, that might be worthwhile. [01:09] Generate debdiffs from merge requests. [01:09] or is it "make changes from branches and mps available as diffs/debdiffs?" [01:10] * RAOF would also like bzr to be slightly better at being a git frontend, too. :) [01:10] me too [01:11] what sort of thing in particular? [01:11] i guess, also, it's useful to know when you prefer using bzr-git to git, and how we could build on that [01:11] I lie RAOF's idea in generating debdiffs from merge proposals. [01:11] * TheMuso will never use bzr-git, I'm happy with using git proper, as much as it can be quirky at times. [01:12] poolie: I prefer to use bzr-git to git anytime it works. Mainly that's when I don't have to deal with a non-master branch, because there's no way of doing that with bzr-git (that I know of). [01:13] i'll file a bug for debdiffs [01:19] raof, i don't think there's a way to do that at present but there should be soon [01:20] I think a combination of git's colocated branches and bzr's sane way of actually pulling from other people would be great :) [01:20] for native bzr branches, bzr-colo is pretty good [01:21] ok, https://bugs.launchpad.net/launchpad/+bug/816757 [01:21] Ubuntu bug 816757 in Launchpad itself "want to get a debdiff from an ubuntu merge proposal" [Undecided,New] [01:21] can you help me improve the description? [01:22] * TheMuso looks. [01:23] Actually, can we already download a diff from the merge proposal? [01:23] yes; though apparently there may be a ui bug :) [01:23] RAOF: You might be right. Let me go to the merge that started all this convo. :) [01:23] 'Cause there's basically no difference between a debdiff and a branch diff in that case. [01:23] Ctrl-f "download diff" [01:24] Right [01:24] oh, i thought you were asking for more of debdiff's policy intelligence [01:24] though, for packaging branches, that may reduce to not much [01:24] Yup, works here. [01:25] Oh, right. So there is. [01:25] Thinking about it further though, as pilots, things get more sticky if we are working on a package that has an Ubuntu packaging branch in alito that we cannot directly write to. If we want to upload the change... [01:25] alioth [01:26] That's the main problem with hosting on alioth, yeah. [01:27] the problem being that ubuntu access control rules don't carry over? [01:30] Yes, but one wouldn't expect them to I guess. [01:32] so, is this bug valid? [01:33] Probably not now that we know of the download diff link. [01:33] Maybe as a UI bug? [01:33] saying "people didn't notice they could download the diff?" [01:33] Pretty much :) [01:33] that seems ilke something we could possibly test on [01:42] ok, updated [01:42] thanks for the information === asac_ is now known as asac [05:53] good morning [05:53] fact [05:54] that. [05:59] if an upstart job fails to start during a package upgrade, but runs fine when started with "sudo start $service", where can i start looking? [06:01] * mwhudson finds http://upstart.ubuntu.com/wiki/Debugging [06:36] hi folks, i have a query from a user about the mirror lists in synaptic....can anyone help? [07:02] good morning === smb` is now known as smb [08:32] thanks mvo for merging [08:40] evfool: thank you! [08:40] evfool: I'm doing some gtkbuilder fixes and then I will upload [09:00] mvo: remember that problem I told you about, with update-manager not being able to update because package names in dbus.strings instead of python strings? [09:01] evfool: yes [09:01] mvo: I have had the exact same problem on two different computers chroot, and after branching the latest aptdaemon and installing it, It's gone [09:03] evfool: ok, let me do a update then [09:03] evfool: sorry, I mean to look at it yesterday, but did not found the time === tkamppeter__ is now known as tkamppeter [09:19] evfool: hm, that is a bit odd, oneiric has the latest trunk [09:19] evfool: of aptdaemon [09:20] mvo: yep, but I still can't find out why I get this behavior. any ideas what should I be looking for? Getting this on two absolutely unrelated chroots isn't normal behavior [09:21] evfool: right, let me try in a vm. are you using i386 or amd64? [09:21] mvo:i386 [09:21] thx [09:22] and a simple apt-get install --reinstall aptdaemon python-aptdaemon does not help? [09:23] mvo: I'll try [09:24] I've tried that, and it's working now, and when I get to the other PC, I'll try it there too [09:24] don't know what could cause this [09:26] woah, really odd [09:57] howdy [10:52] Hitting the "Delete" key doesn't seem to delete files any more. Known bug? Local config problem? [10:53] jml, it's ctrl-delete now [10:54] seb128: oh. huh. is changing keyboard bindings an allowed thing now? [10:54] (I don't really have a problem with it. Heaven knows we could use more coherent default keyboard bindings.) === MacSlow is now known as MacSlow|lunch [11:52] ok, nobody freaks out but soyuz syncing testing bugged and did a sync-source on oneiric it seems [11:53] normal "sync what is newer in Debian" we do before DIF [11:53] but still we are after DIF... [11:53] they are trying to figure what happened [11:53] an accidental autosync run? [11:54] yes [11:54] testing the manual "one source syncing" [11:54] whoops [11:54] seems like it did trigger the wrong action somewhat and did a autosync run [11:54] indeed whoops... [11:56] awesome, oneiric gets to be super up-to-date [11:57] should at least empty the sync queue ^^ [12:33] hi guys, will someone from the sru team look at the queue today? https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text= [12:33] my interest is landscape-client === MacSlow|lunch is now known as MacSlow [13:02] hi all [13:03] what is the root pw for the ubuntu daily live [13:03] http://cdimage.ubuntu.com/daily-live/current/ [13:03] tried live|ubuntu| [13:10] somebody? [13:11] tuxcrafter: 1) This isn't a support channel, try #ubuntu [13:12] tuxcrafter: from memory, it's ubuntu [13:12] or at least, used to be [13:13] tuxcrafter: just to be sure: you try sudo from the user account and not a login as root or su? [13:13] sudo su - [13:15] Hobbsee: sandly not working [13:15] but id shows i am some kind of guest user [13:15] tuxcrafter: ah. Then no idea. [13:57] seb128: do you use the new sync feature from launchpad for the syncs? [13:58] bdrung, "sort of", cf what I said 2 hours ago [13:58] there was an autosync run by mistake by the new sync feature [13:58] so now I'm closing the sync requests which got done in that buggy run [13:59] ah, ok. [14:00] Ah. That's what happened. [14:03] barry, around ? [14:25] sbuild -d oneiric *.dsc [14:25] Only one build is permitted [14:25] eh? [14:25] oh, haha [14:30] kees: hm, on uptodate oneiric, my laptop appears to have no entropy? [14:31] dd if=/dev/random of=x count=8 hangs forever [14:31] (and so i can't sbuild-update --keygen, and so i can't build packages... well i guess i'll set up pbuilder) [14:32] oh, 8 bytes came through [14:46] https://launchpad.net/ubuntu/+source/ginkgocadx/2.5.1.0-1 [14:46] that changelogs look drity ass :p [14:47] it's right in debian [14:47] 's pts [14:48] right, launchpad formatting for debian changelog is buggy [14:49] seems like all the syncs that are done 2 hours ago are that way [14:49] not nice :) [14:49] i.e [14:49] https://launchpad.net/debian/+source/tomboy/1.6.1-1 [14:49] dupondje, yeah, "known bug" === dendrobates is now known as dendro-afk === tlp_ is now known as tlp [15:35] hallyn: you can move the mouse to increase the entropy [15:42] bdrung: no, neither mouse nor kbd was doing it [15:43] hallyn: then buy entropy in the super market ;) [15:43] i wonder if plugging in my phone might have helped [15:44] but i am wondering if this is a 3.0 kernel regression. [15:44] or pipe the entropy from another computer :) [15:44] hallyn: I'll sell you entropy for $1 per kb [15:45] mdeslaur: how do i know it's real? [15:45] mdeslaur: i'll sell it for 10 euro cent per dekabyte [15:45] i don't want any of that inferior walmart entropy [15:47] hallyn: purest entropy a 20-sided die can generate [15:48] mdeslaur: new service on amazon mechanical turk! [15:48] lol === dendro-afk is now known as dendrobates [16:14] anyone know how doku usually handles python changes ? [16:14] i added a merge proposal at https://code.launchpad.net/~smoser/python/lp-813295/+merge/69491 [16:16] smoser: he's at debconf this week. I'd ask barry to look into it. [16:17] it looked like doku is the only one that touched python [16:17] and the Vcs-Bzr is http://bazaar.launchpad.net/~doko/python/pkg2.7-debian [16:17] thus the question. [16:19] Normally that's the case. [16:19] I also know is his laptop fan died so the odds of him attending to it this week are low. [16:38] i think firefox should be in the "special cases" section, but i don't actually know what the new policy is https://wiki.ubuntu.com/StableReleaseUpdates ...help? [16:40] hallyn: do more network/disk/mouse activity! :) [16:40] maco: Firefox was previously listed in https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions ... That probably needs updating. [16:40] since they stopped micro-ing? [16:40] Yeah. [16:40] kees: was doing a lot of all of the above! [16:40] hallyn: entropy generating sucks in the kernel, so doing strong key generation isn't generally something you can automate [16:41] kees: i didn't notice this under natty on this laptop. i do under oneiric. [16:41] jdstrand: are you syncing libvirt from sid by chance? [16:41] kees: I shouldn't tell you that I automate it, should I? [16:41] hallyn: no [16:41] hallyn: I use this for good entropy: http://www.entropykey.co.uk/ [16:41] drat :) [16:41] hehe [16:42] hallyn: fyi, I'm out the next two weeks starting monday [16:42] hallyn: nothing that I know of has changed between natty and oneiric [16:42] jdstrand: ooh, I can push SRUs! :) [16:42] infinity: it's totally possible, sometimes it might just take a long time [16:42] kees: maybe i should pick one onf those up [16:42] hallyn: :) [16:42] hm, a bit steep. Wonder if i can solder my own [16:43] kees: My trick is to background gpg --batch before an ISO image build. :P [16:43] hallyn: I have 2. they generate WAY the hell more bits than I could ever use [16:43] but seriously, i was typing like mad and downloading an iso [16:43] infinity: sounds good to me :) [16:43] kees: It hasn't yet failed to complete before the image does. [16:43] kees: (yet) [16:43] heh [16:54] infinity: firefox is still microing though [16:55] infinity: in fact, that page has an exception for chromium, and firefox is basically doing the chromium playbook now [16:55] nemo: by "its not microing" i meant they stopped having it be the .x that changes all the time [16:55] ah [16:55] they give microreleases major version bumps [16:55] ^ [16:55] right. well. that matches chromium [16:56] And that certainly doesn't match what they used to do. [16:56] Not just the cosmetic change. :P [16:56] well. in terms of ubuntu policy, still would want to push out FF5, 6 etc for Natty [16:56] But the new firefox versions are "rapid feature releases", not just bugfixes. [16:57] infinity: they used to push new features into .x [16:57] admittedly, not that many [16:57] And yes, we're still pushing new versions. [16:57] had to be a really useful one [17:00] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber [17:06] If anyone is about that could moderate a post to technical-board@, I'd appreciate it :) [17:08] * infinity squints at Kate's mail to ubuntu-devel-announce. === dendrobates is now known as dendro-afk [17:37] hallyn: fyi, I will be publishing another libvirt update today [17:37] for o? [17:37] hallyn: no, lucid - natty [17:37] ok [17:38] I already did oneiric last week [17:42] barry, ^^ would you be able to look at/merge the python bug above? [17:42] i'd like to have the images for alpha3 work on eucalyptus, and they will not without this fix. [17:43] never mind, i see that you responded to the merge proposal [17:43] smoser: i just reviewed it ;) looks good to me, but i want to get the patch into upstream py 2.7 first. i will work on that in a few minutes. assuming that goes okay, i'll merge your change (which is basically the upstream changeset) and push an update [17:44] the commit is in the 2.7 branch [17:44] upstream [17:44] thats where i pulled it from [17:44] oh, the issue tracker didn't include the changeset that i could see. it was just the default (3.3) and 3.2 changesets [17:44] * barry looks again [17:45] http://code.activestate.com/lists/python-checkins/98577/ [17:46] i didn't see it in the issue tracker either, and tried to backport the 3.2 change [17:46] then got cpython and noticed it was already there. [17:46] smoser: huh. yeah, weird that it didn't make it to the tracker [17:46] smoser: in that case, i'll merge and push in a few minutes (want to finish something up first) [17:46] barry, thanks. === Guest20890 is now known as gord [18:59] lucas: I'm looking at the udd and the archived_bugs table seems to be empty I'm not sure if its just my copy of it or something else [19:02] bdmurray: looks like it's your copy. === beuno is now known as beuno-lunch [19:02] udd=> select count(*) from archived_bugs; count [19:02] -------- 527700 [19:02] (1 row) [19:04] lucas: okay thanks === zyga is now known as zyga-afk [19:46] hallyn: fyi if you are preparing libvirt SRUs: bug #817187 [19:46] Launchpad bug 817187 in libvirt (Ubuntu Hardy) "change in readlink() errno in 2.6.39 and later kernels causes FTBFS for packages with older gnulib" [High,Triaged] https://launchpad.net/bugs/817187 [19:51] rsalveti: looking at https://code.launchpad.net/~rsalveti/ubuntu/oneiric/base-files/run-transition/+merge/67444 is it still needed after all the /run changes that happened lately (including new releases of base-files)? [19:56] jdstrand: I'm not touching SRUs, maybe at all this week [19:56] * hallyn goes to look in case he misunderstood [19:56] hallyn: ack-- I just spent some time investigating the issue, so wanted to spare you that [19:57] jdstrand: i'm convused, it builds fine for oneiric, what fails? [19:57] hallyn: I probably wasn't clear. If you are preparing srus and running an oneiric kernel, then you'll get ftbfs. the bug details all of this and what to do to fix the situation [19:57] ah [19:58] thanks! [19:58] hallyn: right, change in kernel behavior in oneiric is exposed in chroots that cause ftbfs === zyga-afk is now known as zyga [20:23] ping ev [20:46] ok, so as SpamapS noticed, since at least yesterday, if you debootstrap an image, you have to explicitly add the ubuntu-keyring package for apt to work. That wasn't the case a few days ago. Expected? [20:50] are there any good debhelper8 backports to lucid? [20:50] perhaps in a PPA, or something? [20:55] nevermind, i've worked around it [20:56] there's a debhelper8? [20:56] *now* how tiny is debian/rules?? O_o [20:58] hmmm, i still haven't even converted firefox to use dh7 ;) [20:58] and my debian/rules is huge [20:58] **its [21:00] @pilot off [21:00] (pilot (in|out)) -- Set yourself an in or out of patch pilot. [21:00] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === yofel_ is now known as yofel [21:13] Hey guys. Anybody here working for canonical lexington office? [21:14] here [21:14] don't ask me to do something difficult [21:14] Hi carif. Not too difficult I hope [21:15] any idea how long it takes HR to respond to new applications? [21:15] haven't heard for weeks, kind of depressing === beuno-lunch is now known as beuno [21:17] galfly, your irc nick isn't in https://directory.canonical.com/search/ [21:18] how come? I am on launchpad [21:20] galfly, i think you'll need to ask is at #is to add you and entry, take a picture, etc [21:21] I'm not sure if I understand [21:21] galfly, oh perhaps I've mixed you up, I didn't read carefully enough [21:22] galfly, you've applied to Canonical for a job? [21:22] carif, I applied to an opening at canonical and I'm on launchpad etc. [21:22] carif yeap [21:22] galfly, so sorry, I was talking "internal speak" [21:22] carif, I'm not there yet :) [21:23] soon, I'll be fluent in internal [21:23] I hope :) [21:23] galfly, me too, so how did you submit your application and to whom? [21:25] cairf, I emailed my resume to hr@canonical.com with a cover but am not sure if that was the best way [21:26] galfly: https://tbe.taleo.net/NA3/ats/careers/jobSearch.jsp?org=CANONICAL&cws=1&rid=86 [21:26] going through that would be a better start [21:27] brianchidester thanks a lot. any idea how long it takes them to respond on average? [21:27] they say on the applications if its over 6wk with no response, might as well give up [21:27] i think [21:28] though im not sure with the new application system [21:28] galfly: If you don't apply with the shiny new system, there's a fair chance it might slip through the cracks. [21:28] galfly: (ie: don't email directly) [21:28] it kinda depends when the hiring manager has set aside to go through the Pile O' Stuff, but iirc from when i applied 3-4 wk? [21:29] you guys all rock [21:29] thanks a lot [21:29] galfly: sorry, battery died === brianchidester_ is now known as brianchidester [21:30] galfly, good luck, later [21:30] countdown from 6 weeks stars as of today [21:30] looking for an apartment in lexington area as well [21:30] ha ha! [21:36] stgraber: no, it's not needed anymore [21:36] just deleted the merge proposal [21:41] rsalveti: thanks [22:05] I wonder whether dpkg should detect failure to unpack a .deb and automatically remove+re-fetch one or two times === cinerama_ is now known as cinerama [23:28] i'm having a hard time understanding an apt-get install error. try installing python-qt4-dbus on oneiric and you'll get a broken package. but afaict, python-qt4-dbus depends on python-dbus >= 0.80.0 and python-dbus 0.84.0-2 is installed [23:31] barry: python-dbus : Breaks: python-qt4-dbus (< 4.8.3-3) but 4.8.3-2 is to be installed [23:33] infinity: ah, i had an out of date control file i think. thanks. still the apt-get error message sure isn't helping much ;) [23:33] infinity: thanks [23:37] barry: It's a bit easier to sort if you "apt-get install python-qt4-dbus python-dbus" [23:38] infinity: yep, that makes much more sense [23:38] hi again barry [23:38] barry: Now, it would be hugely helpful if there was a new python-qt4 to sync that had the changes that I assume are required... [23:39] poolie: time files doesn't it? ;) [23:39] barry: python-qt4 4.8.3 is supposed to switch to dh_python2. Now if only someone would upload it to Debian. [23:39] infinity: yes, there is that. [23:39] ScottK: maybe someone who had debian upload privs? :) [23:39] ScottK: i think this is fallout from the unintended sync [23:39] infinity: It would. It would help even more if someone would upload such a change to Debian. [23:40] barry: That and the python-dbus upload being done slightly too soon in Debian. [23:40] ScottK: yep === negronjl_ is now known as negronjl [23:40] ScottK: is there anything i can do to help? i'm blocked on it atm. [23:41] barry: You can take that patch I pointed you at to review the other day and put it in dpmt svn for me to review/upload. [23:41] barry i was wondering if after the holiday period we should do something to shake up the meetings a bit [23:41] (after suitable testing) [23:41] i'm glad we started them and it's good to stay in touch but perhaps something new is needed now [23:41] ScottK: let me see if i remember where that is [23:41] poolie: i totally agree [23:42] ScottK: is this in need of Debian NMU love, or is the maintainer on top of it? [23:42] barry: http://paste.debian.net/124320/ [23:42] infinity: The maintainer is a team that all tries to avoid this one because it's painful. [23:43] I'll upload it once barry's blessed it. [23:43] ScottK: thanks. let me test that [23:43] poolie: i think we should cut out the boilerplate and concentrate on what's really valuable [23:44] ScottK: oh, fair enough. Happy to sync it once you land it in incoming, then. [23:44] yeah [23:44] i don't have anything specific at the moment but i was going to ponder it over the holidayish period [23:45] barry: You mean assigning work to people that skipped the meeting? [23:45] ScottK: if by "people who skipped the meeting" you mean "you" then yes :) [23:45] poolie: agreed! i'll do the same [23:46] barry: No problem. I have a consulting rate related to having work assigned to me. win-win. [23:46] ScottK: no problem, since i know you're familiar with my referral cut [23:47] Definitely win-win then. [23:48] ScottK: if only we were running the gubmint. debt crisis solved [23:49] Mine anyway. [23:49] right :-D [23:49] ScottK: hey, when will debian policy force people to put each build-dep on a separate line? [23:50] Probably never. [23:50] everyone who puts one huge block of build-deps should be forced to read 100 diffs of them [23:52]