[08:04] <dholbach> good morning
[08:06] <vibhav> hi dholbach
[08:07] <dholbach> hi vibhav
[08:11] <ajmitch> hi
[08:22] <plustwo> hi
[08:24] <vibhav> hi plustwo
[08:25] <plustwo> vibhav: o/
[14:26] <Pikkachu> what's the straightforward  way to modify a source package for publishing?
[14:26] <Pikkachu> I just patched the extracted directory directly and built the source package
[14:27] <tumbleweed> that's the straightforward way
[14:27] <Pikkachu> but I wondered if I should rather add the patches themselves to the patch series within debian directory
[14:27] <tumbleweed> yes, you should
[14:27] <Pikkachu> ah then I'm confused
[14:28] <tumbleweed> if the source format is 3.0 (quilt), then it probably already added your patch to the quilt series. Did it?
[14:29] <Pikkachu> yes but it was two or three patches compressed in a single one with no good description...
[14:29] <tumbleweed> right, this is why it's preferable to do it yourself :)
[14:30] <tumbleweed> http://pkg-perl.alioth.debian.org/howto/quilt.html (ignore the bit about integrating with build processes, 3.0 (quilt) does that)
[14:30] <Pikkachu> so would this work? apt-get source pidgin, then all contained patches are applied, then I add my patches to the series, then I apply them manually, then I debuild -S, then I dput $ppa $source_changes?
[14:31] <tumbleweed> yup
[14:31] <Pikkachu> ah nice...
[14:39] <Pikkachu> thanks tumbleweed, now another question...
[14:39] <tumbleweed> yup?
[14:39] <Pikkachu> I have a few patches to pidgin I need to maintain, they slightly change between 2.10.2 and 2.10.0-0ubuntu2 because...
[14:41] <Pikkachu> 2.10.2 applies changes to Windows installer, while ubuntu version does not need that. Also, there's an open upstream but already fixed in ubuntu version, so I need to apply it only in 2.10.2...
[14:42] <Pikkachu> the matter is that I need to manage this patches and I'm using bazaar for that, but I wonder what's a good approach because I'm not satisfied with current one
[14:42] <Pikkachu> current one is...
[14:42] <tumbleweed> there are lots of proposed solutions for that, but nothing really
[14:42] <tumbleweed> *nothing is really there yet
[14:43] <tumbleweed> I just maintain my quilt patches by hand
[14:43] <Pikkachu> ...I keep the patches to 2.10.2 in the repo as .patch files, and I didn't care to put the ubuntu backport in the repo
[14:44] <tumbleweed> right, that's fine then. So what's the issue?
[14:44] <Pikkachu> yeah tumbleweed, I don't like my current approach because a diff between patches is annoying, for example
[14:44] <Pikkachu> and I want to add the ubuntu backport to the repo as well
[14:45] <tumbleweed> sorry, I don't know of anything that'll make that easy. There's going to be manual labor involved one way or another
[14:46] <Pikkachu> because one could grok that the Windows bits are not needed for ubuntu, but not that he should not apply the other patch reported upstream (he would not easily realize it's applied already in ubuntu version)
[14:46] <EvilResistance> tumbleweed is right actually, it'll require a bunch of manual labor
[14:47] <Pikkachu> ah ok tumbleweed, thanks anyway... I tried to imagine a few approaches but all of them with their own quirks...
[14:47] <Pikkachu> *there's an open upstream *bug*
[15:07] <ScottK> jtaylor: Are you going to sync pycxx?
[16:44]  * micahg wonders why didrocks sync'd openclipart when it was doomed to fail
[16:44]  * ScottK votes for 'because he didn't test build it'.
[16:44] <ScottK> Nor, AFAICT ask for an FFe.
[16:45] <didrocks> micahg: Sweetshark told me it's only bug fixing (the changelog seems to suggest so) and that he test built it
[16:47] <micahg> didrocks: ugh :(, well, that's useful information, thanks
[16:48] <micahg> didrocks: FWIW, ajmitch gave me a patch, but I haven't test built it yet, was waiting to finish with something else first
[16:48] <didrocks> micahg: see #ubuntu-desktop
[16:50] <ScottK> Someone might want to file an FFe for python-axiom so I can approve it.
[16:51] <ScottK> barry: ^^^ dh_python2 conversion.
[16:51] <barry> ScottK: i can sponsor
[16:52] <ScottK> barry: Build system change needs an FFe request.  If I'm not the requester, I can approve.
[16:53] <barry> ScottK: who's working on that package?
[16:53] <ScottK> barry: It'd be a sync.
[16:53] <ScottK> No one.
[16:53] <barry> ah, well, then that's easy, right? :)
[16:53] <ScottK> As long as someone other than me asks.
[16:54] <barry> ScottK: okay, i'll file it
[16:59] <barry> ScottK: https://bugs.launchpad.net/ubuntu/+source/python-axiom/+bug/960391
[16:59] <barry> ScottK: you'll do the sync after approving that?
[16:59] <ScottK> If you want me to run it for you, I can.
[16:59] <barry> ScottK: that would be great, i'm a bit slammed at the moment
[17:00] <ScottK> Will do
[17:02] <jtaylor> ScottK: pycxx, it would make sense but its main so I can't sync
[17:02] <jtaylor> I'll request a sync later on
[17:02] <ScottK> Oh.  I didn't realize.
[17:02] <ScottK> I'll just do it then.
[17:03] <jtaylor> th
[17:03] <jtaylor> x
[17:03] <jtaylor> btw would you be open to ffe's for py3 scipy and matplotlib?
[17:05] <jtaylor> has not been done in debian yet, but if its possible to get it in precise I would give it a shot
[17:06] <ScottK> barry and jtaylor: done
[17:06] <ScottK> jtaylor: Yes, although I'd prefer to see them in Debian first (or at least reviewed by their maintainer)
[17:08] <barry> ScottK: thanks
[17:09] <ScottK> barry: Thank you.
[17:12] <jtaylor> can you tell apt to prefer a repository over another even if the package version is the same?
[17:13] <micahg> jtaylor: apt pinning
[17:18] <jtaylor> hm can I use that with a simple deb file:/// rule?
[17:18] <jtaylor> no hostname
[17:28] <jtaylor> ok I think I got it to work
[17:55] <Kiall> Is it just me, or does debhelper build the package before applying patches from quilt?
[17:55] <Kiall> (by build, I mean run override_dh_auto_build)
[17:56] <ScottK> It's just you.
[17:56] <arand> Not normally no.
[17:56] <Kiall> Right - that is what I thought
[17:56] <Kiall> I rename a file in override_dh_auto_build + there is a quilt patch for it.. and quilt complains about file not found -_-
[17:57] <ScottK> presumably because it's not renamed yet.
[17:57] <Kiall> Ohh, wait, its failing during the unapply I think
[17:59] <Kiall> Is there somewhere I should hook into to rename the file back before dpkg-genchanges is ran?
[18:02] <arand> Why not do the rename in the patch?
[18:02] <Kiall> Ah, well.. I didnt know you could do that ;)
[18:02] <arand> Otherwise, dh_clean I'm guessing
[18:04] <Kiall> arand, that worked perfectly.. thanks for the tip!
[18:06] <Rhonda> hmmmmm
[18:07] <Rhonda> When I do debuild -S, it doesn't include launchpad bugs from the changelog but Debian bugs …
[18:07] <Rhonda> Granted, I am doing that on my Debian system -- but is there a switch that would make it to pick up the LP: bugs instead of the Debian closes: bugs?
[18:09] <Kiall> Rhonda, I think the LP still is patched into the packages as they are synced in from debian..
[18:09] <Kiall> LP stuff*
[18:10] <Rhonda> I would have hoped that it's a switch to dpkg-genchanges that I could pass on  :/
[18:10] <ScottK> Rhonda: When it's sync'ed they'll get picked up.
[18:11] <Rhonda> ScottK: It won't get picked up because it's an ubuntu upload.
[18:11] <Rhonda> backports, that is
[18:11] <ScottK> Oh, backports bugs can't get automatically closed.
[18:12] <ScottK> They aren't in an LP sense Ubuntu bugs, but against the backports project.
[18:12] <Rhonda> There are so many switches that dpkg-genchanges can use, I am puzzled that this shouldn't be one.
[18:12] <ScottK> (there is a bug about that)
[18:12] <ScottK> Even if you could get the bug into genchanges, LP wouldn't know what to do with it.
[18:12] <Rhonda> ScottK: They can be reached through the same regular ubuntu bug shortcut
[18:13] <Kiall> Rhonda, why would debian include switches etc all the ubuntu stuff?
[18:13] <Kiall> Ubuntu including debian is obvious, but the other way around.. Not so much!
[18:13] <Rhonda> Kiall: Why not?
[18:13] <Kiall> Debian dont (normally) pull packages from Ubuntu?
[18:15] <Rhonda> So?
[18:15] <Rhonda> There are people trying to play nicely with derivatives, and buxy is an ubuntu member, so …
[18:16] <Kiall> Rhonda, I saw an interesting "lineage" graph for Linux distros recently. There was something ridiculous like 100+ derivatives of Debian. Should Debian include and maintain switches for each of those distros?
[18:17] <Kiall> I would say no, and that each distro maintains the code needed for their own systems..
[18:18] <Kiall> http://futurist.se/gldt/wp-content/uploads/11.04/gldt1104.png
[18:39] <jtaylor> :( matplotlib in precise is not py3 compatible yet
[18:56] <ajmitch> micahg: so, I guess an FFe wasn't needed for openclipart? ;)
[18:57] <ajmitch> also that patch you attached needs fixing before someone uploads it
[18:59] <ajmitch> micahg: have commented on #960389
[19:15] <ScottK> ajmitch: Since didrocks sync'ed it, I think the need for an FFe is passed and opening.
[19:27] <micahg> ajmitch: haven't gotten there yet :0
[19:28] <micahg> ajmitch: oh, right, well, idk, was a blind upload :)
[19:30] <ajmitch> heh
[19:32] <micahg> ajmitch: nice other catch on the conflicts line :)
[19:33] <ajmitch> it was my mistake that put it in there
[19:33] <ajmitch> since I initially had a stray } that caused it to fail to build, then took a closer look at what I'd not removed
[19:34] <ajmitch> turns out that starting a build when half-asleep isn't guaranteed to work
[19:34] <Rhonda> Kiall: Please be notified that there are efforts to reduce differences and make it easier for derivates, if you haven't heard about the derivates frontdesk.
[19:36] <Kiall> Rhonda, right that makes sense.. I havent heard of it, but I would imagine that would involve ensuring tools like dpkg-genchanges are able to handle plugins without the need for patches..  Rather than directly supporting $Distro's $Tool
[19:41] <Rhonda> … that's why I assumed a switch
[19:41] <micahg> ScottK: re FFe> there's still public shaming and what not ;)
[19:42] <ajmitch> micahg: I've heard that some people like doing that :)
[19:49] <Laney> Rhonda: there's DEB_VENDOR support
[19:50] <Rhonda> Laney: How do I have to set that to make it pick up LP instead of closes?
[19:51] <Rhonda> Yep, ubuntu has patches for dpkg-dev …
[19:51] <Laney> add a file /etc/dpkg/origins/ubuntu (contents http://paste.debian.net/160443/) and then DEB_VENDOR=Ubuntu when building the source package
[19:52]  * Laney has some shell magic to export this when in the right directory
[20:00]  * tumbleweed doesn't, but should
[20:01] <Laney> stolen from grml zsh iirc
[20:07] <Rhonda> Kiall: See what Laney wrote, I am trying that now :)
[20:07] <Laney> It certainly works; my development machine is running sid :-)
[20:07] <Laney> "syncpackage: Error: Debian version 0.1.0.5-2 has not been picked up by LP yet. Please try again later." is aaaarghghghghg
[20:08] <Rhonda> … and /usr/share/perl5/Dpkg/Vendor/Ubuntu.pm is part of the regular Debian package of libdpkg-perl :)
[20:08] <tumbleweed> Laney: I keep thinking we should set up a service that lets you know when something is syncable
[20:08] <Rhonda> Thanks to tumbleweed for pointing out that file :)
[20:09] <tumbleweed> np. I also do ubuntu-dev on Debian
[20:09] <ajmitch> tumbleweed: how useful would that really be?
[20:09] <Laney> it's like "I know about this package but you still can't have it ha ha ha ha ha"
[20:10] <Rhonda> tumbleweed: some RSS feed?
[20:10] <tumbleweed> ajmitch: my active hours seem to fall between dinstalls in Debian
[20:10] <tumbleweed> I almost always have to wait a day before I can sync
[20:10] <tumbleweed> and so I keep open tabs to remind myself. But those are fallable
[20:10] <ajmitch> that would be frustrating when trying to get a set of packages built together
[20:14] <Rhonda> hah
[20:14] <Rhonda> Launchpad-Bugs-Fixed: 932011
[20:14] <Laney> \o/
[20:14] <tumbleweed> :)
[20:14] <ajmitch> yay
[20:14]  * Rhonda hugs Laney and tumbleweed :)
[20:15]  * Laney looks at ajmitch 
[20:15] <Laney> fancy some grunt work?
[20:15] <Laney> :-) (-:
[20:16] <ajmitch> because you know that I *love* mindless work? :)
[20:16] <ajmitch> what have you broken now?
[20:16] <tumbleweed> we reserve it for old-timers
[20:16] <Laney> it's not entirely mindless
[20:17] <ajmitch> tumbleweed: now you make me feel old
[20:17] <Laney> it's "find the OOD haskell binaries and file a bug for their removal"
[20:17] <tumbleweed> why don't they show up in NBS?
[20:18] <Laney> because they aren't nbs
[20:18] <Laney> http://people.canonical.com/~ubuntu-archive/testing/precise_outdate_all.txt
[20:18] <ajmitch> Laney: so you've got everything synced & wonderful now?
[20:19] <Laney> gitit and darcs are broken
[20:19] <Laney> i think everything else is either OOD from that list or pending removal
[20:20]  * ajmitch sees some packages he'd love to remove on that list
[20:20] <ajmitch> fwiw I won't have time to look at it for at least a few hours
[20:23] <Laney> no worries
[20:24] <Laney> gah, darcs put out a new release but they don't say it supports ghc 7.4
[20:24] <Laney> "Versions of GHC from 6.10.x to 7.0.x are supported."
[20:24] <ajmitch> and gitit?
[20:25] <Laney> oh no, off by one on the year
[20:25] <Laney> 14 March 2011
[20:25] <ajmitch> heh
[20:51] <ScottK> jtaylor: No need to version python3-numby since a lower version than that has never existed.
[20:51] <jtaylor> yes, though it shouldn't harm either
[20:52] <ScottK> It does, if only slightly because then dpkg has to go look and evaluate that in it's resolvers.
[20:52] <ScottK> resolver
[20:52] <ScottK> err apt
[20:53] <jtaylor> k, If I get green light to commit it to svn I'll remove them
[20:53] <ScottK> You can always commit to svn if you're a member of the team.
[22:16] <blueyed> tumbleweed: I could need some help with fixing the test(s) for ubuntu-dev-tools. See my comment at https://code.launchpad.net/~blueyed/ubuntu-dev-tools/use-proxy-for-download/+merge/97905/comments/212630
[22:17] <Laney> finally enough haskell packages transitioned to let me dist-upgrade
[22:17] <ajmitch> yay? :)
[22:18] <Laney> definitely
[22:51] <micahg> ScottK: do reverse-suggests matter WRT backports?
[22:52] <ScottK> No.
[22:53] <micahg> ok, thanks
[22:53] <micahg> ah, ok, it's in the blurb, heh