[00:00] <dennis_> hi at all
[00:00] <dennis_> i have a programming problem in c++
[00:00] <dennis_> someone can help me?
[00:00] <dennis_> ?
[00:01] <micahg> TheMuso: sure enough fails in sbuild since the default resolver can't handle the alternate build-dep
[00:01] <TheMuso> Right.
[00:02]  * TheMuso only uses sbuild so would have probably caught that sooner or later anyway.
[00:03] <TheMuso> dennis_: You are probably best asking in #ubuntu-app-devel if its for an app you are writing on Ubuntu. Otherwise I am pretty sure there are channels dedicated to c/c++ on freenode where you could ask your question.
[00:04] <micahg> TheMuso: so, in theory it should work in LP, but I should probably verify that (the last upload had the change, but that was before xulrunner dropped to universe)
[00:05] <TheMuso> micahg: Ok, well I am running it in sbuild now and it is currently building.
[00:05] <TheMuso> 8/c
[00:05] <TheMuso> I'll try installing in a oneiric chroot and see what happens.
[00:06] <micahg> TheMuso: orly?  did you limit the component to main only?
[00:06] <TheMuso> micahg: No.
[00:06] <micahg> TheMuso: then it's not a good test
[00:06] <TheMuso> Probably shoudl have.
[00:06] <TheMuso> yup just realised that.
[00:09] <TheMuso> micahg: Yeah ok it does fail.
[00:10] <TheMuso> micahg: So it seems this is a merge after all.
[00:10] <micahg> TheMuso: idk, in theory it should work in LP, I'll ask wgrant a bit later
[00:10] <RAOF> wgrant: Are you subscribed to bug 791596 because you are affected by it?
[00:10] <wgrant> micahg: What's up?
[00:11] <micahg> ah, will xulrunner-dev | firefox-dev DTRT in oneiric main (only firefox-dev in main)
[00:12] <wgrant> RAOF: I thought I was, but now I'm not so sure.
[00:12] <wgrant> RAOF: Since I'm using xorg-edgers, so I should have had the patch for a month.
[00:12] <wgrant> RAOF: But when I rebooted yesterday for the first time in a couple of weeks, my cursor started going strange in the bottom right corner of the screen.
[00:12] <wgrant> Doesn't seem to be hardware.
[00:13] <RAOF> And you're still using edgers?
[00:14] <wgrant> Yes.
[00:14] <wgrant> There it goes again.
[00:14] <RAOF> Hm, that makes you a less than perfect test subject.
[00:14]  * TheMuso moves onto something else for the moment.
[00:14] <wgrant> Indeed.
[00:14] <wgrant> So I just subscribed to see how it progressed.
[00:14] <wgrant> It may be entirely unrelated.
[00:16] <RAOF> Would you like to try an X server without that patch, for science?
[00:18] <micahg> wgrant: did you see my question above about the alternate build-deps?
[00:19] <wgrant> micahg: I did, but got distracted, sorry (on a call).
[00:19] <wgrant> micahg: That should work OK.
[00:20] <wgrant> micahg: I think.
[00:20] <wgrant> micahg: What doesn't work well is when the first is versioned, and the package is there but the version is wrong.
[00:20] <TheMuso> wgrant: Failed in a local sbuild with main/restricted enabled only.
[00:20] <micahg> wgrant: oh, sorry, right I have an open bug for the versioned build-deps
[00:21] <micahg> TheMuso: are you on natty?
[00:21] <TheMuso> micahg: Yes, but I was building in a oneiric chroot.
[00:21] <wgrant> TheMuso: Huh.
[00:21] <micahg> TheMuso: right, I think sbuild in oneiric might fix it
[00:21] <wgrant> TheMuso: Which resolver is sbuild using?
[00:21] <TheMuso> The default.
[00:23] <TheMuso> wgrant: ^^
[00:23] <micahg> which is internal on natty
[00:23] <wgrant> Ah.
[00:23] <wgrant> Possibly not, then.
[00:24] <micahg> the version in oneiric now uses the apt resolver which I think will work
[00:24] <TheMuso> Yes but what are the buildds using?
[00:29] <micahg> wgrant: is there any way to test what LP will do aside from an archive upload?
[00:30] <wgrant> micahg: You could configure a PPA to use components, and try there. But otherwise not really.
[00:30] <micahg> wgrant: k, thanks
[00:34] <micahg> we'll find out soon
[00:41] <TheMuso> Ok.
[00:45] <micahg> Unpacking firefox-dev (from .../firefox-dev_5.0~b2+build1+nobinonly-0ubuntu2_i386.deb) ... \o/
[00:46] <maco> slangasek: i know they do, but i also thought since it was for avoiding collisions and i didnt see a reference to that version in rmadison, it didnt really matter in this case. didnt think about previous versions
[00:49] <TheMuso> micahg: Is https://code.launchpad.net/~dev-nigelj/ubuntu/oneiric/zabbix/721707-v2/+merge/61855 on your radar, or should I go ahead and look at it?
[00:50] <micahg> TheMuso: it's on my radar, but if you're out of things to do, feel free to do it
[00:50] <TheMuso> micahg: there is plenty more in the queue, so I will leave for now, thanks.
[00:55] <micahg> TheMuso: https://launchpad.net/~micahg/+archive/ftbfs-test/+build/2543125
[00:55]  * micahg adds to sync request
[00:57] <TheMuso> micahg: thanks
[00:59] <TheMuso> micahg: ACKed, thanks.
[00:59] <micahg> TheMuso: cool, thanks
[01:42] <chrisccoulson> is there anyone around who can accept these binaries for me: https://launchpad.net/ubuntu/+source/thunderbird/5.0~b1+build2+nobinonly-0ubuntu1/+build/2543042 ? :)
[01:43] <chrisccoulson> i can reward with beer....
[01:49] <RAOF> wgrant: Would you be willing to try https://edge.launchpad.net/~raof/+archive/aubergine/+packages ? I can't see how thta patch could be causing this problem‽
[01:52] <wgrant> RAOF: I guess I should run with natty-updates' xserver-xorg-core for a couple of hours first, since it's not easily reproducible.
[01:53] <RAOF> That would be better, yes.
[02:10] <broder> TheMuso: you saw that there are two branches you'll need to grab for the mediatomb merge, right?
[02:10] <TheMuso> broder: Yes, got them both.
[02:10] <broder> (and thanks for dealing with it - I just hadn't found the time to pull everything together yet)
[02:10] <TheMuso> broder: Actually used your branch as a base.
[02:11] <broder> ah, cool
[02:11] <TheMuso> broder: Np, kind of a pain that it was accross 2 branches, for packaging it makes more work IMO.
[02:11] <TheMuso> Code, I can accept, multiple branches for different fixes, but packaging... Well Not decided yet, but it certainly took more time to unravel everything.
[02:11] <micahg> that package actually needs a merge as well, I've been meaning to do it
[02:13] <micahg> but if the patches work, that's fine, run with it
[02:14] <TheMuso> I wasn't even aware that it needed a merge.
[02:15] <micahg> I missed it last cycle
[02:16] <micahg> it needs porting to mozjs185 which is why I've been pushing it off, it should work though with xulrunner-1.9.2 while it's still in the archive
[02:18] <TheMuso> ah.
[02:18] <TheMuso> I don't envy you guys working on browser stuff. My head aches enough from having to tackle audio.
[02:18] <micahg> TheMuso: I'd rather tackle browsers than audio ;)
[02:22] <TheMuso> heh
[02:22] <TheMuso> The biggest headache is the tons of hardware, and manufacturers liking to cut corners/not do things right in their BIOS/allow bugs to creap into their chipsets.
[02:23] <TheMuso> Although accessibility presents its own headaches sometimes as well.
[03:48] <TheMuso> @pilot out
[03:53] <broder> TheMuso: fyi, giving a branch an "approved" review doesn't remove it from the queue
[03:53] <broder> but changing the status at the top of the page to "merged" would :)
[03:55] <TheMuso> broder: oh right thanks.
[03:55] <TheMuso> I have dealt with so many branches today, my head hurts.
[04:01] <poolie> TheMuso: hi, could/did you file a bug against lp about that zope error?
[04:18] <smartass> Can anyone here give me some background on how the OS will handle mouse coordinates when multiple monitors are setup?
[04:18] <smartass> Will the mouse move to the 2nd screen if I send coordinates for example 35000 to the OS?
[04:19] <RAOF> You're after X protocol documentation here.
[04:19] <RAOF> And the answer is ‘it depends’ :)
[04:20] <smartass> I tried to find something useful but without much success
[04:24] <RAOF> Well, it depends on what you're actually trying to do.  I'm off for lunch now, and this isn't really the place for X protocol discussions.  #ubuntu-app-devel might be better, or #xorg-devel.  ‘apropos pointer’ will give you a reference to “XWarpPointer (3)     - move pointer”, which is the documentation you probably want to start with.
[04:28] <TheMuso> poolie: Not yet, what project should I file it against?
[04:29] <TheMuso> Sorry, was away for a shortish break.
[04:30] <smartass> What I need to know is how the coordinates are managed when multiple monitors are setup. My utility needs to manage multiple touchscreens so that if you touch touchscreen1 the touch should be displayed on the monitor being setup. Thanks anyway, I'll give the other rooms a shot and I need to do this for mac as well.
[04:40] <poolie> TheMuso: if you get an oops or zope error pushing to launchpad, file against lp
[04:45] <TheMuso> poolie: ok thanks.
[06:02] <poolie> ta
[06:14] <StevenK> hrw: Can you please STOP including ddeb's in your armel-cross packages?
[06:17] <slangasek> StevenK: they're not meant to get included, but if we want them to be produced at all it takes fiddly handling in the rules because of the nested package builds involved...  what's broken this time?
[06:18] <StevenK> slangasek: They get included and then process-accepted blows up
[06:19] <slangasek> which source package is including them?
[06:19] <StevenK> gcc-4.6-armel-cross
[06:19] <StevenK> I rejected the two binaries from accepted so process-accepted would start working again.
[06:20] <slangasek> ah - if this hadn't been a NEW package, wouldn't they have been rejected straightaway?  That's what I recall seeing before
[06:21] <StevenK> slangasek: But they weren't in the NEW queue, they were in the ACCEPTED queue
[06:21] <slangasek> yes, because I accepted them out of NEW, not noticing the .ddeb issue... :)
[06:21] <StevenK> Ah ha
[06:28] <slangasek> StevenK: while you're here... do you know why ggz-client-libs in Ubuntu has a patch from you from 2008 that's never been forwarded to Debian? :)
[06:28] <StevenK> You know, 2008 was a long time ago ... :-)
[06:28]  * slangasek can't figure out what the patch is for, and it's the only delta
[06:32] <StevenK> slangasek: However, ggz-client-libs hasn't been touched in Debian since at least then anyway :-)
[06:32] <slangasek> yes, it's been NMUed
[06:32] <StevenK> I think it fixes an install failure, but the patch is obtuse.
[06:34] <StevenK> Oh! I think it's a build failure, since it wanted to write to /?
[06:35] <slangasek> hmm, but the NMU built fine in Debian without this patch
[06:35] <slangasek> If the Debian package builds in oneiric, should I sync it?
[06:36] <StevenK> If it builds and install on oneirc, yes, do so.
[07:48] <dholbach> good morning
[08:38] <ara> Hello! Do we know when we will have daily Oneiric images?
[08:56] <seb128> ara, hey, not sure I guess they should be on from now on but cjwatson and pitti are off since before a1 so maybe check with them next week
[08:57] <ara> seb128, sure, I will, thanks seb
[08:57] <seb128> ara, yw
[09:28] <hrw> StevenK: sorry. will not happen again
[10:20] <dholbach> can somebody review my ubuntu-packaging-guide mp? http://pad.lv/mps/ubuntu-packaging-guide
[10:24] <Laney> noooooooooooooo I hate that division
[10:39] <dholbach> Laney, can you elaborate?
[10:39] <dholbach> if you have a better idea how to make scanning the list of topics easier, I'm all ears
[10:40] <Laney> all of that stuff should be integrated into the main document(s) IMHO
[10:40] <Laney> rather than having a big division: "traditional" and "UDD"
[10:40] <dholbach> there's no "traditional" in there
[10:41] <dholbach> the task-based articles on the front page all contain UDD bits that are relevant to them
[10:41] <dholbach> the articles in the knowledge base dive deeper into the topics
[10:42] <dholbach> I think there's value in short task-based articles that give new contributors a result, even if they don't work in 100% of the cases or might need some other tool that they can find out about in the knowledge base
[10:44] <dholbach> Laney, would you agree that the list of knowledge base articles is a bit hard to read and it might get worse over time and that we should start categorising things?
[10:45] <dholbach> I personally could imagine that renaming "UDD" on that page to "Development Tools" (or some such) could do a bit to avoid confusion about "UDD vs. traditional techniques"
[10:46] <Laney> ah I thought there was 'traditional' in there — my bad (and yes, I like the task based approach)
[10:46] <Laney> I think that UDD should be renamed indeed, because it reinforces (or at least opens the door to) the division
[10:46] <Laney> Development Processes or something
[10:47] <Laney> but it /is/ interesting that we'll not be training people in how to use the traditional tools
[10:47] <Laney> how do they give back to Debian then? :-)
[10:47] <dholbach> there's an article in progress about working with Debian and other upstreams
[10:47] <dholbach> I think mok0 is working on it
[10:48] <dholbach> Development Processes might work
[10:48] <dholbach> I'll update the mp
[10:48] <dholbach> we can still change it to something cleverer later on
[10:49] <Laney> 'tis probably more than one article but I guess we could give a short intro 'how to build your package for Debian' or something and then link to the Debian packaging guide
[10:49] <Laney> and apologies for my confusion
[10:50] <dholbach> don't worry - I assume a lack of caffeine ;-)
[10:50] <Laney> not consumed enough kola cubes yet
[10:50] <dholbach> ok, updated the branch
[10:52] <Laney> looks good
[10:52] <dholbach> thanks
[13:37] <ScottK> dholbach: I don't see the mp anymore, so I can't comment on the specifics, but based on the discussion here, I am concerned.  I don't think the UDD based toolset is mature enough yet to be 'the way we do things'.  If that's all that's covered in the new packaging guide, it shouldn't be called a packaging guide and it doesn't cover the normal tools for doing so.
[13:39] <dholbach> The mp was more about restructuring the listing of articles
[14:10] <showard> Hi - don't want to be impatient, but just want to make sure bug #755641 has not slipped through the cracks
[14:11] <showard> I need an archive admin to approve the upload to -proposed. Duplicates are reported daily for it.
[14:25] <ScottK> showard: Before an archive admin can approve it, someone from ubuntu-sru has to say it's OK for -proposed.
[14:26] <ScottK> dholbach: OK.  Where can I find the current document?
[14:31] <hyperair> any technical-board member here?
[14:31]  * hyperair wrote a microrelease exception addition request (for banshee), but it looks like it's stuck in the moderation queue.
[14:33] <tumbleweed> ScottK: http://people.canonical.com/~dholbach/packaging-guide/html/
[14:34] <ScottK> tumbleweed: Thanks.
[14:34] <ScottK> hyperair: Almost certainly.  I'd suggest either email to their list or just ask your question.
[14:35] <hyperair> ScottK: that's exactly what i did.
[14:36] <ScottK> OK.
[14:37] <ScottK> There's TB members on vacation so I imagine it might take a bit longer than usual.
[14:46] <ScottK> dholbach: Where do I file bugs about the guide?
[14:47] <tumbleweed> ScottK: as I appear to be the day's caching dholbach-proxy: lp:ubuntu-packaging-guide
[14:48] <ScottK> tumbleweed: Thanks.
[14:54] <dholbach> thanks tumbleweed
[14:54] <dholbach> I hope it's not perceived as "my guide" - it will move to a more official home soon enough
[14:54] <hyperair> ScottK: alright, thanks for the information.
[14:56] <ScottK> dholbach: I think it needs to be clarified what it is before it moves anywhere more official. (just mailed ubuntu-devel and the udd list to discuss)
[14:58] <showard> ScottK: thanks for clarifying
[14:59] <ScottK> showard: It turns out most ubuntu-sru memebers are also archive admins, so the distinction is a subtle one.
[14:59] <Laney> It's difficult. Having both workflows would probably be confusing. Having traditional-only would require a rewrite when we decide to advocate UDD (which is supposed to be The Future), and having UDD only means you promote an immature toolset.
[15:02] <ScottK> Laney: I think renaming it is the best plan.
[15:02] <ScottK> Laney: But you need to cover traditional stuff anyway or you're stuck as soon as you hit an out of date branch.
[15:25] <Laney> part of the idea was to replace the out of date wiki mess though
[15:42] <ScottK> Right.  I think better docs for UDD is a good and important thing, but to represent it as the Ubuntu way is getting ahead of things.
[16:19] <apw> is there any documentation on how one handles source 3.0 (quilt) when commiting with bzr, particularly how to maintain the .pc poop
[16:23] <ScottK> apw: I think barry gave a link on ubuntu-devel in the thread on this subject.
[16:24] <barry> apw: http://people.canonical.com/~dholbach/packaging-guide/html/udd-patchsys.html
[16:25] <broder> apw: as long as you're not trying to merge, i think the answer is mostly "do a quilt push -a before you commit and bzr add all of the .pc poop"
[16:26] <apw> broder, i am trying to merge
[16:27]  * apw whines about the importer pulling in .pc, stupid
[16:27] <broder> i feel like i've heard cjwatson mention a flow where he quilt pops, then merges the unpatched trees, but i forget how he said he did that...
[16:27]  * mdeslaur learns about bzr loom for the first time
[16:28] <barry> one key thing i've learned is that you basically want to bzr revert any changes in the .pc directory before you commit.
[16:28] <mdeslaur> barry: whaaa? but...won't that break when you try and unapply quilt patches that haven't applied cleanly?
[16:30] <barry> mdeslaur: i haven't seen that, but i have seen conflicts in the .pc directory after a merge, and it's pretty much worked for me to just revert those and carry on
[16:30] <barry> mdeslaur: but of course, when you're talking udd+quilt, ymmv ;)
[16:30] <mdeslaur> hehe
[16:31] <ScottK> I think it'd be better if the importer did it with patches not applied.  It seems like that would make a whole world of pain go away.
[16:31]  * barry channels maco now
[16:32] <maco> hi barry
[16:32] <apw> can anyone shed any light on the Architecture: linux-any appearing in a debian package, and whether we understand it
[16:33] <barry> ScottK: i thought the same thing too, but jelmer (i think) had some good arguments as to why that's not the right thing to do.  i think the intent there is that people should be able to just branch and hack.
[16:33] <barry> hi maco
[16:33] <ScottK> barry: Yes and with the .pc issues they can't do that.
[16:34] <arand> apw: Won't build for kfreebsd or hurd?
[16:34] <barry> ScottK: not without pain today, true
[16:34] <apw> will the ubuntu archive grok it ?
[16:34] <arand> apw: That I do not know..
[16:35] <barry> for me, the benefits of bzr/dvcs outweigh that pain, but not for everybody.  maco for example doesn't use udd for quilt packages.  certainly that's a reasonable strategy.
[16:36] <maco> barry: i made a script the other day to fetch a source package for a given release, check if its using cdbs for patchsys, and then apply the patch, dch -i, *the only piece of user interaction happens here*, debuild -S, and create a debdiff.  that wiki page you linked is way more head-hurty than the script i handed akk to make a debdiff out of a patch she was submitting
[16:36] <maco> and once that script has a --help and some error checking, i'll push it toward u-d-t
[16:37] <maco> (its aimed at non-upload-rights people needing to make a debdiff to hand to a sponsor)
[16:37] <barry> maco: yep, no disagreement there
[16:39] <smoser> barry, stupid question...
[16:39] <smoser> how do i get the python upstream 2.7 branch in hg?
[16:40] <broder> apw: soyuz can deal with linux-any, afaik
[16:40] <barry> smoser: i'm not sure what the url is for non-core committers.  let me see if i can find it
[16:40] <broder> maco: that sounds a lot like edit-patch. have you looked at that?
[16:40] <smoser> yeah, yeah, yeah, barry, you're a core committer, the rest of us are slime... :)
[16:41] <barry> smoser: no, no, no.  dvcs democratizes everything :)
[16:42] <barry> btw, smoser: http://docs.python.org/devguide/
[16:42] <infinity> barry: Why which you mean "it creates the illusion of power with local branches until people realise they can't get them merged back into mainline without a hefty donation of cookies and kittens"?
[16:42] <barry> mmm, kitten cookies, yum!
[16:42] <maco> broder: nope. didnt know it existed. it's not listed in apt-cache show ubuntu-dev-tools
[16:43] <broder> maco: it may slide into devscripts at some point; i haven't been following that stuff too closely
[16:43] <barry> infinity: of course, you can always publish your own branches, and rant about the oppressive thumb of the establishment and its evil cabal of gatekeepers
[16:43] <maco> broder: i think sponsor-patch was the closest i saw in the list at the time
[16:43] <broder> maco: but edit-patch/add-patch have been around for a while. if they're not listed in the package description, a bug would probably be helpful
[16:43] <tumbleweed> it's in devscripts now
[16:44] <barry> smoser: http://docs.python.org/devguide/setup.html?highlight=mercurial
[16:44] <infinity> barry: And rename my fork "diamondback"?
[16:44] <tumbleweed> maco: add/edit-patch just does the "determine patch system, patch, generate changelog entry" bits
[16:45] <maco> http://pastebin.com/gNGdjqse this is what i had
[16:45] <barry> infinity: i prefer to use names from the deadly viper assassin squad, but ymmv
[16:45] <tumbleweed> maco: bad link
[16:46] <maco> oh expiry
[16:46] <maco> http://pastebin.com/X2VAZRFV
[16:49] <tumbleweed> maco: hrm, I wonder if sponsor-patch doesn't already cover that (it uses edit-patch)
[16:49] <maco> can you tell it to not upload it somewhere?
[16:49] <ScottK> Call maco's script sponsoree-patch.
[16:49] <maco> heh
[16:50] <tumbleweed> maco: yes
[16:50] <maco> ScottK: bonus points if it can attach the debdiff to a bug report?
[16:50] <tumbleweed> yeah, sponsor-patch is a bad name for that usecase
[16:51] <broder> maco: look at what the -s option to sponsor-patch breaks down to and tweak accordingly
[16:53]  * maco looks at -b and puzzles
[16:54] <maco> DIST? i just have a crackload of aliases....  pbn build ../foo.dsc,  pbo build ../foo.dsc, etc.
[16:56] <tumbleweed> maco: standard pbuilder config is to use DIST=natty pbuilder ...
[16:56] <tumbleweed> it also supports pbuilder-dist
[16:58] <Laney> ScottK: can you think of a non-confusing-to-newbies-yet-realistic-about-the-situation to present this stuff? "Ignore UDD/have it as an appendix"?
[17:00] <maco> tumbleweed: huh. ok. i just have symlinks in ~ to pbuilder-dist and aliases to call those symlinks
[17:00] <tumbleweed> maco: try -B pbuilder-dist then
[17:01] <maco> as an argument to what command?
[17:01] <maco> (i also dont have a pbuilderrc, so i dont know what this standard config is)
[17:01] <tumbleweed> maco: sponsor-patch
[17:01] <maco> well, /etc/ has a pbuilderrc, but it just gives a mirrorsite
[17:02] <tumbleweed> maco: yeah, standard non-default config :) https://wiki.ubuntu.com/PbuilderHowto
[17:02] <maco> little b you mean? manpage doesnt have a big B
[17:02] <tumbleweed> hrm, it should have had it for a while now. What release are you on?
[17:03] <maco> maverick
[17:03] <tumbleweed> ah, yeah it may have come after that
[17:03] <broder> yeah, i think that's too old - i'm pretty sure i added the -B stuff in the natty cycle
[17:03] <maco> will have to try when i'm home...which is conveniently also where any source package i may have sitting around are located
[17:04] <tumbleweed> unfortunatly you can't just grab the latest u-d-t trunk, because of the devscripts migration, we'd probably have to do decent backports
[17:04] <broder> tumbleweed: that's been fixed, at least for natty
[17:04] <broder> somebody uploaded a devscripts backport to the dailies ppa
[17:04] <tumbleweed> broder: cool, that doesn't help maverick though :)
[17:04] <maco> at some point i should upgrade this system
[17:05] <broder> tumbleweed: there's a backport in there for maverick, too
[17:05] <tumbleweed> yeah, just saw that
[17:05] <maco> my team lead at work upgraded to natty because the update manager told him to. then all my coworkers told him he shouldnt have and laughed at his confusion with unity. i think the other kde user went into recruiter mode
[17:06] <tumbleweed> unity seems to cause a day or two's pain for most people
[17:07] <maco> i told him how to get back to gnome. he checked how much ram he had to answer the initial question he was asked, then shut down ubuntu and went back to his mac. this was the first time id ever seen his ubuntu machine turned on since i started working here in january
[17:07] <tumbleweed> maco: so, when you do get home, grab u-d-t from the ~udt-developers PPA
[17:07] <broder> (ppa:~udt-developers/daily)
[17:07] <maco> tumbleweed: does natty's u-d-t have the thing you're saying? my dev machine at home is on natty
[17:07] <Laney>  
[17:07] <maco> im going to have to reinstall to get my netbook to natty. not enough space to download the packages
[17:08] <tumbleweed> maco: yes it does
[17:09] <maco> ok then
[17:12] <smoser> barry, so my feeling right now is that offlineimap is to intrinsically familiar with IMAP_SSL.
[17:13] <smoser> it has some wrappers that it uses "UsefulIMAPSSL"
[17:13] <smoser> i think i have a fix in offlineimap at http://paste.ubuntu.com/617647/ (tested a bit here)
[17:18] <SpamapS> broder: omg, backportpackage is amazing. :-D
[17:18] <broder> :)
[17:19] <broder> i was pretty happy with how it turned out, and i use it all the time now
[17:21] <SpamapS> Its something I find myself doing about once a week.. debcommit.. dch .. bzr bd -S .. bzr revert ... repeat..
[17:22] <broder> though you should also thank bdrung for harassing me into making it do more more than the first version i wrote
[17:24] <SpamapS> bdrung: thank you for harrassing broder
[17:24] <SpamapS> we couldn't do it without your harrassment
[17:29] <bdrung> you're welcome. i am a happy backportpackage user too
[17:29] <bdrung> only one bit is missing: backporting from debian
[17:33] <bdrung> that's bug #703099
[17:34] <bdrung> broder: can i harass you to fix ^?
[17:34] <broder> bdrung: yeah, probably
[17:34] <bdrung> or should i ask more frequently ;)
[17:34] <bdrung> ?
[17:34] <broder> remind me some time this weekend
[17:35] <broder> actually, remind me on sunday if you don't see an mp by then
[17:56] <bdmurray> @pilot in
[18:04] <kees> cjwatson: I've just adjusted platform.oneiric/standard for apparmor (to drop the Perl bits). do I need to do anything beyond just committing that change?
[18:04] <kees> (https://wiki.ubuntu.com/SeedManagement seems to imply I just need to commit)
[18:06] <tumbleweed> bdrung: sponsor-patch doesn't seem to like DEBCHANGE_RELEASE_HEURISTIC=changelog, maybe it should use dch --release instead of --edit
[18:10] <bdrung> tumbleweed: that seems to work too. feel free to change it.
[18:12] <bdrung> tumbleweed: what do you think about time based releases for u-d-t?
[18:12] <tumbleweed> bdrung: don't have anything against them, but I also don't think there's anything wrong with the current release rate
[18:13] <tumbleweed> +  * mark-irq9-active-high-in-DSDT.patch: fix system_shutdown not working in
[18:13] <tumbleweed> +  * mark-irq9-active-high-in-DSDT.patch: fix system_shutdown not working in
[18:13] <tumbleweed> grr
[18:14] <bdrung> tumbleweed: i was thinking about a biweekly release schedule for not critical bugs. so that we don't accumulate too many changes
[18:14] <tumbleweed> that's not a bad idea
[18:15] <bdrung> releasing 0.109 took to long
[18:16] <bdrung> tumbleweed: second thing: a 1.0 release when all unwanted scripts are moved elsewhere
[18:16] <tumbleweed> well, there were some big changes in that (which haven't actually been completed yet :/ )
[18:16] <tumbleweed> persia seems to be aiming for nothing left
[18:16] <bdrung> tumbleweed: that's unrealistic
[18:17] <tumbleweed> I tend to agree
[18:19] <bdrung> tumbleweed: on the get rid list: mk-sbuild, check-symbols, reverse-build-depends, *distro-info, bug #708886 - anything forgotten on this list?
[18:23] <tumbleweed> looks like we're about to add backportpackage to that list, if broder does something the debian backporters like
[18:23] <bdrung> maybe
[18:27] <smoser> cjwatson, do you have thoughts on merging rsyslog from debian ? debian is at 5.8.1-1, oneiric at 4.6.4-2ubuntu4 . 4.6.4-2 was the last of debian's 4.X.  http://paste.ubuntu.com/617682/ rsyslog Changelog since 4.6.x
[18:30] <ScottK> Laney: If you want to write newbie docs, it's got to be done using the mature tools.  I think ignore UDD (for now) would be the right approach.
[18:33] <broder> tumbleweed: i think backportpackage will still be more of a u-d-t than a devscript, since the end result will be ubuntu-targeted packages
[18:33] <broder> hmm...though i wonder if there's anything in the script right now that would keep you from backporting with -d wheezy or similar
[18:38] <ScottK> broder: You might want to talk to Rhonda about that.  Rhonda is heavily involved in Debian backports.
[18:39] <tumbleweed> broder: well, for a start it wouldn't use the correct version format :)
[19:20] <bdmurray> Does anybody know where https://wiki.ubuntu.com/DistributedDevelopment/Documentation/SettingUp went?
[19:20] <barry> i want to do a no-change rebuild.  `dch -R -D oneiric` is almost, but not quite, right.  when the last changelog entry is this: "jinja2 (2.5.5-5) unstable; urgency=low" the next one will be this: "jinja2 (2.5.5-5build1) oneiric; urgency=low".  yes, i can manually fix that, but i'm wondering if dch has an option to use `ubuntu1` instead of `build1`
[19:20] <barry>  
[19:20] <barry>  
[19:21] <akgraner> highvoltage, got time for a call or pm?
[19:21] <barry> bdmurray: i think it mostly got rolled into http://people.canonical.com/~dholbach/packaging-guide/html/getting-set-up.html
[19:22] <debfx> barry: buildX is actually right for rebuilds
[19:22] <barry> debfx: ah, because autosyncs will continue?
[19:23] <bdmurray> barry: and the same is probably true for the other links on https://wiki.ubuntu.com/SponsorshipProcess ?
[19:23] <debfx> barry: yes
[19:24] <broder> tumbleweed: sure, it would be an "ubuntu-style" backport, and not uploadable to debian, but i don't think we actually verify the destination releases
[19:24] <barry> bdmurray: i think the other links will point into subpages of http://people.canonical.com/~dholbach/packaging-guide/html/knowledge-base.html
[19:24] <barry> debfx: thanks
[19:35] <bdmurray> barry: and if something is wrong in the packaging guide?
[19:37] <barry> bdmurray: best to open a bug on lp:ubuntu-packaging-guide
[19:38] <bdmurray> if it only it were a wiki page ;-)
[19:39] <barry> bdmurray: :)
[20:02] <jikanter> micahg: what's new bud?
[20:04] <bdmurray> @pilot out
[20:38] <barry> james_w: ping
[20:38] <james_w> hi barry
[20:38] <barry> james_w: hi, hope all is well.
[20:38] <barry> james_w: i'm working on getting rid of python3.1 and need to rebuild python-bsddb3, but have run into this udd error:
[20:39] <barry> http://package-import.ubuntu.com/status/python-bsddb3.html#2011-05-19 20:55:56.006213
[20:39] <barry> james_w: wondering, can this be manually fixed?
[20:39] <james_w> barry, I'm not sure
[20:39] <james_w> probably a bit late for #bzr too
[20:40] <barry> james_w: yeah, that's what i was afraid of ;)
[20:40] <james_w> I'm not too sure what that is trying to tell us
[20:41] <james_w> I think it might be a broken branch though
[20:41] <james_w> possibly due to stacking
[20:41] <barry> james_w: ok, no worries.  i was hoping it might be easy, but i don't want to shave too many yaks today.
[20:44] <james_w> barry, something weird seems to have happened in the history of that branch that has left some dangling tags
[20:44] <james_w> I suggest you file a bug
[20:45] <barry> james_w: there's already https://bugs.launchpad.net/udd/+bug/653312
[20:48] <james_w> ok
[21:01] <bdmurray> @pilot in
[21:31] <broder> hmm..."time in sponsorship queue" is starting to creep upwards :(
[21:35] <micahg> broder: that's due to UDS still, should go back now shortly
[21:35] <micahg> s/now/down/
[21:35] <broder> hmm, probably true
[21:35] <broder> it does look like it's cresting, but it's kind of hard to tell with the resolution we have
[21:37] <slangasek> nvidia-common in oneiric seems to be of an entirely different provenance than the one in natty; does anyone know if this was intentional, or if the Ubuntu version was accidentally clobbered when Debian started shipping one?
[21:38] <Keybuk> I know where I'd put my money ...
[21:44] <robbiew> heh
[22:00] <bryceh> Sarvatt, ^ know what's up with nvidia-common?
[22:01] <bryceh> slangasek, not an intentional change on our end afaik
[22:02] <Sarvatt> oh yuck, no that wasn't intentional
[22:09] <slangasek> bryceh, Sarvatt: ok; I think someone will need to epoch it and reupload then
[22:09] <slangasek> and either put 'ubuntu' in the version number, or have the archive admins blacklist it for syncing
[22:10] <bryceh> Sarvatt, sounds like a tseliot job?  Shall I send him an email about this?  Or do you want to square it away?
[22:10] <bryceh> lp #792576
[22:10] <micahg> can we just do 20110426+1+really0.2.x instead of an epoch?  that way if we manage to consolidate in the future, it's easier to reconcile
[22:10] <bryceh> Sarvatt, thanks
[22:11] <slangasek> micahg: I suppose so
[22:11] <bcurtiswx> who maintains planet ubuntu?
[22:12] <slangasek> in that case we should definitely add it to the sync blacklist, since we don't want it to show up on the merge list either without specific action
[22:12] <micahg> +1
[22:12] <bryceh> bcurtiswx, it's open maintenance, I don't think it has a specific maintainer
[22:13] <bryceh> slangasek, agreed
[22:13] <slangasek> and in general, if people are maintaining packages in Ubuntu with non-Ubuntu version numbers... please ask for them to be added to the sync blacklist, even if there's currently no package of that name in Debian :-)
[22:13] <bcurtiswx> hum, i moved my blog to my local comp, and im confused as why the rss feed link works, but not the link on my name.. and today's blog didn't show.  im lost for answers
[22:13]  * micahg is still for adding ubuntu to the version string as well
[22:14] <slangasek> micahg: I'm indifferent to that... but even with an ubuntu version it should still be blacklisted if our version numbers are going to imply a merge is wanted
[22:14] <micahg> slangasek: true
[22:15] <micahg> slangasek: blacklists still show up in MoM though
[22:15] <slangasek> they're not supposed to
[22:15] <slangasek> if they do, I think that's a regression
[22:15] <micahg> chromium-browser and flashplugin-nonfree are blacklisted and still show up
[22:16] <slangasek> we ought to fix that then :)
[22:16] <micahg> indeed
[22:17] <micahg> bug 671556 could probably be hijacked to track that
[23:09] <bdmurray> @pilot out
[23:47] <SpamapS> ugh even getting 10Mbit clamav takes way too long to bzr branch. :-P