User1: User2 Oooh, while you're here - is there a way of extracting the changes file from the unapproved queue?
User2: User1 the name of the package in the queue listing is a link to the changes file
User3: bug 806940 is part of this
User4: Launchpad bug 806940 in Ubuntu Distributed Development "conflict if a dir is created in an udd branch" [Undecided,New] https://launchpad.net/bugs/806940
User3: though, perhaps eventually that will be duped onto a more generic one
User1: User2 â¦oh.  Bah! :)
User5: What path does patches to the Ubuntu Xorg Intel driver take? Xorg.freedesktop -> Debian -> Ubuntu?
 * SpamapS signs off for the day
User1: User5 Generally, yes; we're not slavish about it, though.
User6: @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:
User5: User1 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.
User5: 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.
User5: These are major fixes and I am concerned with how we can get them into Ubuntu's driver quickly.
User5: They've been reviewed at Intel and released to the Xorg mailing list.
User5: But they're of course drowning in all the other patches and discussions.
User1: Right.
User5: 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?
User1: 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.
User3: TheMuso, hi
User7: User3 Good morning.
User5: Actually they're only DDX modifications :)
User3: hi
User3: i just saw your post about the pulseaudio packaging branch
User5: Oh yeah and I see your point, I'll alert some Xorg maintainers to review and apply them there first. Thanks for the advice.
User1: User5 Then that's a bit easier :).  Still, we'd prefer them to be upstream first.
User7: User3 The desktop team maintains similar branches for desktop packages as well.
User3: similar in the sense of debian-only
User7: Right.
User3: is this mostly for the sake of faster checkouts of it?
User3: as you know the general plan is to get the ubuntu namespace branches being official, and being complete branches
User7: User3 No, its because thats how they were originally stored in bzr since before I really got involved with audio packaging.
User5: User1 Thank you. I'll talk to some Xorg maintainer. Have a good night :)
User3: do you think we could migrate them to the standard form at some point?
User3: that would remove a special case from the piloting/contribution process
User1: User5 I'm in UTC+10.  It's a good day for me.  Have fun with upstream :)
User7: User3 Actually I was hoping to eventually move Ubuntu packaging to Debian git.
User3: hm, really?
User7: User3 And what about the ubuntu-desktop packaging? How does that go in terms of patch piloting?
User3: because you're also the debian mantainer?
User7: User3 Yes, easier to pull from either side patch wise.
User7: 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.
User3: the same thing here meaning maintaining it on debian.org, or meaning having only debian/ versioned?
User7: The same thing as in Ubuntu packaging maintained in alioth/debian git vcs.
User3: hm, ok
User3: so, this seems like a plan around having lp branches and contributions on lp may be on the wrong track
User1: User3 *Or* launchpad grows git support, I guess :)
User7: Yeah that too.
User3: so, what would happen in that case?
User1: pkg-cli-* and pkg-mono also have all their canonical branches in alioth git.  I think it's a fairly popular mode of operation.
User3: you'd have the ubuntu branches on lp, but be able to more transparently merge them?
User3: or they'd stay primarily on alioth?
User1: They'd probably stay primarily on alioth, but we could pull merges from launchpad.
User1: That said, git is terrible at that workflow. :(
User7: I'm not sure. If the ubutu branches were on alioth, thats the only place I'd want to work with them.
User7: SO yeah, merging from lp would be useful.
User3: i mean there's no point in adding that support, which might not be cheap, if it's not actually helping ubuntu
User1: It would help Ubuntu insomuch as merge requests against UDD branches would be useful.
User3: 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
User3: either directly in the tree when it should be in patches, or in an ubuntu branch when it should be an upstream change
User3: 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
User3: 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
User1: Patches on the bugs are great; debdiffs on bugs are also great.
User1: 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.
User6: User3 One of the general issues I have with UDD (or any of its predecessors) is statements about "doing work in the wrong place".
User6: User3 Any contribution is the right place, and debdiff, or simple patches are all perfectly fine.
User3: because it can always be moved around later?
User6: User3 (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)
User3: i guess what i'm really asking is, how can canonical's infrastructure best be helping ubuntu?
User6: User3 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".
User6: User3 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. :)
User6: (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)
User3: :)
User7: 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.
User7: gah typing.
User3: User6 i see your point about not wanting to denigrate things people are doing that are working
User3: obviously technically the importer is supposed to handle merging them together and it generally does
User3: so themuso, if you were writing our plan for the next year (for udd/lp/bzr), what would you ask for?
User7: User3 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.
User7: 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.
User7: SO I guess all I'd prefer is patches/debdiffs.
User3: so your answer is essentially, "don't get in the way of using allioth?" or "improve the bug tracker instead?" or something?
User1: Actually, that might be worthwhile.
User1: Generate debdiffs from merge requests.
User3: or is it "make changes from branches and mps available as diffs/debdiffs?"
 * RAOF would also like bzr to be slightly better at being a git frontend, too. :)
User3: me too
User3: what sort of thing in particular?
User3: i guess, also, it's useful to know when you prefer using bzr-git  to git, and how we could build on that
User7: I lie RAOF's idea in generating debdiffs from merge proposals.
 * TheMuso will never use bzr-git, I'm happy with using git proper, as much as it can be xwilliams@example.org.
User1: User3 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).
User3: i'll file a bug for debdiffs
User3: raof, i don't think there's a way to do that at present but there should be soon
User1: I think a combination of git's colocated branches and bzr's sane way of actually pulling from other people would be great :)
User3: for native bzr branches, bzr-colo is pretty good
User3: ok, https://bugs.launchpad.net/launchpad/+bug/816757
User4: Ubuntu bug 816757 in Launchpad itself "want to get a debdiff from an ubuntu merge proposal" [Undecided,New]
User3: can you help me improve the description?
 * TheMuso looks.
User1: Actually, can we already download a diff from the merge proposal?
User3: yes; though apparently there may be a ui bug :)
User7: User1 You might be right. Let me go to the merge that started all this convo. :)
User1: 'Cause there's basically no difference between a debdiff and a branch diff in that case.
User3: Ctrl-f "download diff"
User7: Right
User3: oh, i thought you were asking for more of debdiff's policy intelligence
User3: though, for packaging branches, that may reduce to not much
User7: Yup, works here.
User1: Oh, right.  So there is.
User7: 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...
User7: alioth
User1: That's the main problem with hosting on alioth, yeah.
User3: the problem being that ubuntu access control rules don't carry over?
User7: Yes, but one wouldn't expect them to I guess.
User3: so, is this bug valid?
User7: Probably not now that we know of the download diff link.
User1: Maybe as a UI bug?
User3: saying "people didn't notice they could download the diff?"
User1: Pretty much :)
User3: that seems ilke something we could possibly test on
User3: ok, updated
User3: thanks for the information
User8: good morning
User9: fact
User10: that.
User11: 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?
 * mwhudson finds http://upstart.ubuntu.com/wiki/Debugging
User12: hi folks, i have a query from a user about the mirror lists in synaptic....can anyone help?
User13: good morning
User14: thanks mvo for merging
User15: User14 thank you!
User15: User14 I'm doing some gtkbuilder fixes and then I will upload
User14: User15 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?
User15: User14 yes
User14: User15 I have had the exact same problem on two different computers chroot, and after branching the latest aptdaemon and installing it, It's gone
User15: User14 ok, let me do a update then
User15: User14 sorry, I mean to look at it yesterday, but did not found the time
User15: User14 hm, that is a bit odd, oneiric has the latest trunk
User15: User14 of aptdaemon
User14: User15 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
User15: User14 right, let me try in a vm. are you using i386 or amd64?
User14: User15i386
User15: thx
User15: and a simple apt-get install --reinstall aptdaemon python-aptdaemon does not help?
User14: User15 I'll try
User14: I've tried that, and it's working now, and when I get to the other PC, I'll try it there too
User14: don't know what could cause this
User15: woah, really odd
User16: howdy
User16: Hitting the "Delete" key doesn't seem to delete files any more. Known bug? Local config problem?
User17: jml, it's ctrl-delete now
User16: User17 oh. huh. is changing keyboard bindings an allowed thing now?
User16: (I don't really have a problem with it. Heaven knows we could use more coherent default keyboard bindings.)
User17: ok, nobody freaks out but soyuz syncing testing bugged and did a sync-source on oneiric it seems
User17: normal "sync what is newer in Debian" we do before DIF
User17: but still we are after DIF...
User17: they are trying to figure what happened
User18: an accidental autosync run?
User17: yes
User17: testing the manual "one source syncing"
User18: whoops
User17: seems like it did trigger the wrong action somewhat and did a autosync run
User17: indeed whoops...
User19: awesome, oneiric gets to be super up-to-date
User20: should at least empty the sync queue ^^
User21: hi guys, will someone from the sru team look at the queue today? https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=
User21: my interest is landscape-client
User22: hi all
User22: what is the root pw for the ubuntu daily live
User22: http://cdimage.ubuntu.com/daily-live/current/
User22: tried live|ubuntu|<empty>
User22: somebody?
User23: User22 1) This isn't a support channel, try #ubuntu
User24: User22 from memory, it's ubuntu
User24: or at least, used to be
User25: User22 just to be sure: you try sudo from the user account and not a login as root or su?
User22: sudo su -
User22: User24 sandly not working
User22: but id shows i am some kind of guest user
User24: User22 ah.  Then no idea.
User26: User17 do you use the new sync feature from launchpad for the syncs?
User17: bdrung, "sort of", cf what I said 2 hours ago
User17: there was an autosync run by mistake by the new sync feature
User17: so now I'm closing the sync requests which got done in that buggy run
User26: ah, ok.
User27: Ah.  That's what happened.
User28: barry, around ?
User29: sbuild -d oneiric *.dsc
User29: Only one build is permitted
User29: eh?
User29: oh, haha
User29: User33 hm, on uptodate oneiric, my laptop appears to have no entropy?
User29: dd if=/dev/random of=x count=8  hangs forever
User29: (and so i can't sbuild-update --keygen, and so i can't build packages...  well i guess i'll set up pbuilder)
User29: oh, 8 bytes came through
User30: https://launchpad.net/ubuntu/+source/ginkgocadx/91.69.162.6-1
User30: that changelogs look drity ass :p
User18: it's right in debian
User18: 's pts
User17: right, launchpad formatting for debian changelog is buggy
User30: seems like all the syncs that are done 2 hours ago are that way
User30: not nice :)
User17: i.e
User17: https://launchpad.net/debian/+source/tomboy/1.6.1-1
User17: dupondje, yeah, "known bug"
User26: User29 you can move the mouse to increase the entropy
User29: User26 no, neither mouse nor kbd was doing it
User26: User29 then buy entropy in the super market ;)
User29: i wonder if plugging in my phone might have helped
User29: but i am wondering if this is a 3.0 kernel regression.
User26: or pipe the entropy from another computer :)
User31: User29 I'll sell you entropy for $1 per kb
User29: User31 how do i know it's real?
User26: User31 i'll sell it for 10 euro cent per dekabyte
User29: i don't want any of that inferior walmart entropy
User31: User29 purest entropy a 20-sided die can generate
User29: User31 new service on amazon mechanical turk!
User31: lol
User28: anyone know how doku usually handles python changes ?
User28: i added a merge proposal at https://code.launchpad.net/~smoser/python/lp-813295/+merge/69491
User27: User28 he's at debconf this week.  I'd ask barry to look into it.
User28: it looked like doku is the only one that touched python
User28: and the Vcs-Bzr is http://bazaar.launchpad.net/~doko/python/pkg2.7-debian
User28: thus the question.
User27: Normally that's the case.
User27: I also know is his laptop fan died so the odds of him attending to it this week are low.
User32: 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?
User33: User29 do more network/disk/mouse activity! :)
User6: User32 Firefox was previously listed in https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions ... That probably needs updating.
User32: since they stopped micro-ing?
User6: Yeah.
User29: User33 was doing a lot of all of the above!
User33: User29 entropy generating sucks in the kernel, so doing strong key generation isn't generally something you can automate
User29: User33 i didn't notice this under natty on this laptop.  i do under oneiric.  <shrug>
User29: User34 are you syncing libvirt from sid by chance?
User6: User33 I shouldn't tell you that I automate it, should I?
User34: User29 no
User33: User29 I use this for good entropy: http://www.entropykey.co.uk/
User29: drat :)
User34: hehe
User34: User29 fyi, I'm out the next two weeks starting monday
User33: User29 nothing that I know of has changed between natty and oneiric
User29: User34 ooh, I can push SRUs!  :)
User33: User6 it's totally possible, sometimes it might just take a long time
User29: User33 maybe i should pick one onf those up
User34: User29 :)
User29: hm, a bit steep.  Wonder if i can solder my own
User6: User33 My trick is to background gpg --batch before an ISO image build. :P
User33: User29 I have 2. they generate WAY the hell more bits than I could ever use
User29: but seriously, i was typing like mad and downloading an iso
User33: User6 sounds good to me :)
User6: User33 It hasn't yet failed to complete before the image does.
User6: User33 (yet)
User33: heh
User35: User6 firefox is still microing though
User35: User6 in fact, that page has an exception for chromium, and firefox is basically doing the chromium playbook now
User32: User35 by "its not microing" i meant they stopped having it be the .x that changes all the time
User35: ah
User32: they give microreleases major version bumps
User6: ^
User35: right. well. that matches chromium
User6: And that certainly doesn't match what they used to do.
User6: Not just the cosmetic change. :P
User35: well. in terms of ubuntu policy, still would want to push out FF5, 6 etc for Natty
User6: But the new firefox versions are "rapid feature releases", not just bugfixes.
User35: User6 they used to push new features into .x
User35: admittedly, not that many
User6: And yes, we're still pushing new versions.
User35: had to be a really useful one
User36: @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
User37: If anyone is about that could moderate a post to technical-board@, I'd appreciate it :)
 * infinity squints at Kate's mail to ubuntu-devel-announce.
User34: User29 fyi, I will be publishing another libvirt update today
User29: for o?
User34: User29 no, lucid - natty
User29: ok
User34: I already did oneiric last week
User28: barry, ^^ would you be able to look at/merge the python bug above?
User28: i'd like to have the images for alpha3 work on eucalyptus, and they will not without this fix.
User28: never mind, i see that you responded to the merge proposal
User38: User28 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
User28: the commit is in the 2.7 branch
User28: upstream
User28: thats where i pulled it from
User38: oh, the issue tracker didn't include the changeset that i could see.  it was just the default (3.3) and 3.2 changesets
 * barry looks again
User28: http://code.activestate.com/lists/python-checkins/98577/
User28: i didn't see it in the issue tracker either, and tried to backport the 3.2 change
User28: then got cpython and noticed it was already there.
User38: User28 huh.  yeah, weird that it didn't make it to the tracker
User38: User28 in that case, i'll merge and push in a few minutes (want to finish something up first)
User28: barry, thanks.
User39: User40 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
User40: User39 looks like it's your copy.
User40: udd=> select count(*) from archived_bugs; count
User40: -------- 527700
User40: (1 row)
User39: User40 okay thanks
User34: User29 fyi if you are preparing libvirt SRUs: bug #817187
User4: 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
User36: User48 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)?
User29: User34 I'm not touching SRUs, maybe at all this week
 * hallyn goes to look in case he misunderstood
User34: User29 ack-- I just spent some time investigating the issue, so wanted to spare you that
User29: User34 i'm convused, it builds fine for oneiric, what fails?
User34: User29 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
User29: ah
User29: thanks!
User34: User29 right, change in kernel behavior in oneiric is exposed in chroots that cause ftbfs
User14: ping ev
User29: 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?
User41: are there any good debhelper8 backports to lucid?
User41: perhaps in a PPA, or something?
User41: nevermind, i've worked around it
User32: there's a debhelper8?
User32: *now* how tiny is debian/rules?? O_o
User42: hmmm, i still haven't even converted firefox to use dh7 ;)
User42: and my debian/rules is huge
User42: **its
User36: @pilot off
User43: (pilot (in|out)) -- Set yourself an in or out of patch pilot.
User36: @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:
User44: Hey guys. Anybody here working for canonical lexington office?
User45: here
User45: don't ask me to do something difficult
User44: Hi carif. Not too difficult I hope
User44: any idea how long it takes HR to respond to new applications?
User44: haven't heard for weeks, kind of depressing
User45: galfly, your irc nick isn't in https://directory.canonical.com/search/
User44: how come? I am on launchpad
User45: galfly, i think you'll need to ask is at #is to add you and entry, take a picture, etc
User44: I'm not sure if I understand
User45: galfly, oh perhaps I've mixed you up, I didn't read carefully enough
User45: galfly, you've applied to Canonical for a job?
User44: carif, I applied to an opening at canonical and I'm on launchpad etc.
User44: carif yeap
User45: galfly, so sorry, I was talking "internal speak"
User44: carif, I'm not there yet :)
User44: soon, I'll be fluent in internal
User44: I hope :)
User45: galfly, me too, so how did you submit your application and to whom?
User44: cairf, I emailed my resume to xwilliams@example.org with a cover but am not sure if that was the best way
User46: User44 https://tbe.taleo.net/NA3/ats/careers/jobSearch.jsp?org=CANONICAL&cws=1&rid=86
User46: going through that would be a better start
User44: brianchidester thanks a lot. any idea how long it takes them to respond on average?
User32: they say on the applications if its over 6wk with no response, might as well give up
User32: i think
User32: though im not sure with the new application system
User6: User44 If you don't apply with the shiny new system, there's a fair chance it might slip through the cracks.
User6: User44 (ie: don't email directly)
User32: 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?
User44: you guys all rock
User44: thanks a lot
User47: User44 sorry, battery died
User45: galfly, good luck, later
User44: countdown from 6 weeks stars as of today
User44: looking for an apartment in lexington area as well
User44: ha ha!
User48: User36 no, it's not needed anymore
User48: just deleted the merge proposal
User36: User48 thanks
User29: I wonder whether dpkg should detect failure to unpack a .deb and automatically remove+re-fetch one or two times
User38: 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
User6: User38 python-dbus : Breaks: python-qt4-dbus (< 4.8.3-3) but 4.8.3-2 is to be installed
User38: User6 ah, i had an out of date control file i think.  thanks.  still the apt-get error message sure isn't helping much ;)
User38: User6 thanks
User6: User38 It's a bit easier to sort if you "apt-get install python-qt4-dbus python-dbus"
User38: User6 yep, that makes much more sense
User3: hi again barry
User6: User38 Now, it would be hugely helpful if there was a new python-qt4 to sync that had the changes that I assume are required...
User38: User3 time files doesn't it? ;)
User27: User38 python-qt4 4.8.3 is supposed to switch to dh_python2.  Now if only someone would upload it to Debian.
User38: User6 yes, there is that.
User38: User27 maybe someone who had debian upload privs? :)
User38: User27 i think this is fallout from the unintended sync
User27: User6 It would.  It would help even more if someone would upload such a change to Debian.
User27: User38 That and the python-dbus upload being done slightly too soon in Debian.
User38: User27 yep
User38: User27 is there anything i can do to help?  i'm blocked on it atm.
User27: User38 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.
User3: barry i was wondering if after the holiday period we should do something to shake up the meetings a bit
User27: (after suitable testing)
User3: i'm glad we started them and it's good to stay in touch but perhaps something new is needed now
User38: User27 let me see if i remember where that is
User38: User3 i totally agree
User6: User27 is this in need of Debian NMU love, or is the maintainer on top of it?
User27: User38 http://paste.debian.net/124320/
User27: User6 The maintainer is a team that all tries to avoid this one because it's painful.
User27: I'll upload it once barry's blessed it.
User38: User27 thanks.  let me test that
User38: User3 i think we should cut out the boilerplate and concentrate on what's really valuable
User6: User27 oh, fair enough.  Happy to sync it once you land it in incoming, then.
User3: yeah
User3: i don't have anything specific at the moment but i was going to ponder it over the holidayish period
User27: User38 You mean assigning work to people that skipped the meeting?
User38: User27 if by "people who skipped the meeting" you mean "you" then yes :)
User38: User3 agreed!  i'll do the same
User27: User38 No problem.  I have a consulting rate related to having work assigned to me.  win-win.
User38: User27 no problem, since i know you're familiar with my referral cut
User27: Definitely win-win then.
User38: User27 if only we were running the gubmint.  debt crisis solved
User27: Mine anyway.
User38: right :-D
User38: User27 hey, when will debian policy force people to put each build-dep on a separate line?
User27: Probably never.
User38: everyone who puts one huge block of build-deps should be forced to read 100 diffs of them
User38: anyway, i'm going to grab some dinner and let this build
User2: User38 for those diffs, I use vimdiff :)
User27: User38 You'll want to merge python-defaults from experimental (I just uploaded it)
ubuntu-devel
Ubuntu IRC