[00:27] <ScottK> kklimonda: Sounds great.
[00:27] <ScottK> kklimonda: Thanks for sticking with it.
[01:22] <udienz> hello, i want to ask about patching
[01:23] <udienz> sorry for my bad english
[01:23] <udienz> someone report bug and he attached patch
[01:24] <udienz> can i apply his patch and submitting to ubuntu-motu?
[05:09] <micahcowan> For vte: I'm a little confused as to whether I ought to branch, modify, then propose a merge against the branch mentioned by "apt-get source", or the appropriate-looking one from the "code" tab of the Ubuntu package's page.
[05:10] <micahcowan> http://bazaar.launchpad.net/~ubuntu-desktop/vte/ubuntu/   and   http://bazaar.launchpad.net/~ubuntu-desktop/vte/ubuntu/   respectively.
[05:10] <micahcowan> They are not branches of the same code (apparently?), as they have no common ancestors, so can't be merged.
[05:10] <ebroder> micahcowan: If apt-get source mentions a branch, it's generally better to submit patches against that, with the caveat that sometimes the branch mentioned by apt-get source is a Debian branch, not an Ubuntu branch, in which case it's probably not better
[05:11] <ebroder> Or, more succinctly, "it's complicated"
[05:11] <micahcowan> (oops, that second one ought to have been: lp:ubuntu/vte
[05:12] <ebroder> The lp:ubuntu/foo branches are frequently (although not universally) automatically generated, so if it looks like there's an alternative branch maintained by Ubuntu folks, that's probably better
[05:18] <micahcowan> ebrpder. is this sort of thing documented anywhere?
[05:19] <ebroder> micahcowan: Not that I know of
[08:03] <dholbach> good morning!
[08:04] <micahg> \sh: zf is backported in the zf ppa, I'll try for an official maverick backport this weekend
[08:08] <\sh> micahg: thx a lot :)
[08:08] <micahg> \sh: np
[12:47] <geser> kklimonda: grab http://bazaar.launchpad.net/~stgraber/%2Bjunk/sandbox/annotate/head%3A/sandbox-raw-nonetwork.c, compile it and modify line 128 of /usr/lib/pbuilder/pbuilder-buildpackage to 'echo "$DPKG_COMMANDLINE" | /usr/local/bin/sandbox-raw-nonetwork $CHROOTEXEC $SUTOUSER' (adapt the path to sandbox-raw-nonetwork as necessary)
[12:49] <geser> that gives you a pbuilder which builds the package with no network (package download and hooks still have net access)
[12:52] <kklimonda> geser: ok, thanks
[13:04] <kklimonda> yay, I'm two uploads from fixing python-visual FTBFS.. it took me a month to get here..
[13:05] <geser> I hope the python2.7 plans don't interfere with your progress
[13:06] <kklimonda> that's why I have to upload it fast so it doesn't affect me! ;)
[13:07] <kklimonda> the package builds fine for both 2.6 and 2.7 - the ftbfs wasn't related to python
[13:50] <ScottK> kklimonda: I think the work you are doing will also fix python-hildon.
[14:09] <kklimonda> ScottK: no, but the fix for python-hildon looks pretty straighforward - as I'm pretty much done with python-visual (all that's left is to upload new gtkglextmm and rebuild python-visual) I can fix it
[14:09] <ScottK> kklimonda: OK.  Cool.
[14:22] <kklimonda> ScottK: ugh, are we actually interested in supporting Hildon in Ubuntu? python-hildon looks mostly unmaintained at the upstream.
[14:22] <kklimonda> the last version I can find is 0.9.0 released over a year ago
[14:22] <ScottK> kklimonda: If it's in the archive it should build.  I don't care if it's removed or fixed.
[14:24] <kklimonda> ok, I'll ask mvo (update-manager-hildon is the only reverse dependency) about it
[14:45] <kklimonda> ScottK: mvo has said that he's going to "kill [update-manager-hildon]" so I'll subscribe ubuntu-archive to bug 687353 after it's gone
[14:45] <ScottK> kklimonda: Great.
[16:33] <ScottK> kklimonda: python-visual just needs a retry?
[16:35] <ScottK> Done in any case.
[16:35] <ScottK> kklimonda: Thanks for all your work on this.
[16:37] <kklimonda> ScottK: I think it's too soon as gtkglextmm is still building - I've unassigned myself as doko is working on it.
[16:37] <kklimonda> but yes, python-visual just needs a retry when gtkglextmm is published :)
[16:38] <ScottK> kklimonda: It'll be some time before it gets done since the builders are all very busy.
[16:38] <ScottK> If it hits too soon, I'll retry it again.
[16:38] <kklimonda> ScottK: yes, I've noticed - especially the powerpc one is swamped with jobs :)
[16:39] <ScottK> Yes, but even i386 and amd64 are very behind at the moment.
[16:39] <kklimonda> oh, there are even two - but still it's not enough and they have a 40hrs+ queue
[16:39] <ScottK> Yep.
[16:40] <ScottK> powerpc builds ~as fast as amd64, but there are more amd64 builders now, so powerpc lags.
[16:43] <kklimonda> oh? powerpc is that fast?
[16:44] <kklimonda> I've always assumed that it's also slower than i386 and amd64 - not as much as armel but still
[17:36] <achiang> argh. debuild keeps auto-creating a patch called debian-changes-... ; i don't know how to prevent that from happening. any clues?
[17:36] <achiang> "This patch has been created by dpkg-source during the package build."...
[17:36] <kklimonda> achiang: it happens when you modify source in place
[17:36] <coolbhavi> achiang, thats created by 3.0 format
[17:36] <coolbhavi> source format*
[17:38] <achiang> kklimonda: i am modifying a package the desktop-team way, by branching their ubuntu branch with bzr. maybe that has something to do with it
[17:38] <achiang> for the "in-place" thing
[17:41] <kklimonda> achiang: I can't really tell why have this happened to you, when I get debian-changes-... it's because I've somehow edited the source files directly as opposed to creating patches
[17:41] <kklimonda> achiang: I'd suggest checking content of this file to see what's going on
[17:41] <achiang> kklimonda: yeah. i was actually editing a patch in place. ;)
[17:42] <achiang> kklimonda: thanks, i'll go do that
[17:46] <Rhonda> kklimonda: no, powerpc isn't slow. :)
[17:46] <Rhonda> … otherwise I would kill myself packaging wesnoth on it
[17:49] <kklimonda> ah, good wesnoth - I remember it using all my ram and swap few years back, during one of my affairs with Gentoo.
[17:49] <Rhonda> Sure it was wesnoth and not the background emerge of your gentoo system? ;)
[17:50] <kklimonda> well, it may have been my highly tuned compiler flags that were the real culprit ;)
[17:51] <mhall119> what's the changelog line for closing a needs-packaging bug?
[17:52] <kklimonda> mhall119: * Initial release. (LP: #XXXXXXX) is fine
[17:52] <Rhonda> Usually: Initial upload (LP: #1234)  (or closes: if it was for Debian)
[17:52] <Rhonda> Actually dh_make should put that into your changelog already.
[17:52] <mhall119>   * Add watch file and closes bug #687431 (LP: #687431)
[17:52] <mhall119> will that do?
[17:53] <mhall119> it did, but I wasn't ready to close it in the first iteration
[17:53]  * mhall119 is still a packing noob
[17:53] <Rhonda> mhall119: A bit of double information. "Add watch file (LP: #687431)" is enough. :)
[17:53] <mhall119> ok
[17:54] <Rhonda> … if adding the watchfile is the bug.
[17:54] <mhall119> no, the bug is the needs-packaging bug
[17:54] <Rhonda> The bug though is rather about needs-packaging, not about a missing watchfile in the package.
[17:54] <mhall119> but the last change i made to this package was adding the watch file
[17:54] <Rhonda> Yes, then two lines. One with " * Initial upload (LP: #687431)" and one with " * Add watchfile"
[17:54] <mhall119> ok
[17:55] <mhall119>   * Initial upload (LP: #687431)
[17:55] <mhall119>   * Add watch file
[17:55] <Rhonda> Actually the "Add watchfile" could be considered of part of the initial upload packaging efforts, so it's not a "change" per se.
[17:55] <mhall119> liek that?
[17:55] <mhall119> it's a change to the package though
[17:55] <Rhonda> You would put a add watch file line if it wasn't part of a former upload.
[17:55] <mhall119> since I built and uploaded to my ppa without the watchfile
[17:56]  * kklimonda kisses eatmydata - my precious
[17:56] <mhall119> http://paste.ubuntu.com/541081/ is my current changelog
[18:05] <mhall119> do I need to put copyright headers on all my python and shell files?
[18:05] <ScottK> mhall119: Yes, but you needn't consider the PPA history in your debian/changelog for Ubuntu
[18:06] <mhall119> okay, I was using the same instance for both uploads
[18:06] <mhall119> is there a prefered template for source code copyright header?
[18:06] <ScottK> mhall119: It's not absolutely required as long as it's clear what the license is for everything, but it's a best practice to do so.
[18:06] <ScottK> What license?
[18:06] <mhall119> GPLv2
[18:06] <ScottK> GPL provides one.
[18:07] <mhall119> thanks, found it
[18:17] <mhall119> is there a way to turn my current packaging directory into a proper bzr package branch?
[18:19] <mhall119> woot! no lintian complaints http://revu.ubuntuwire.com/p/xdg-launcher
[18:21] <ScottK> Not everyone is convinced we've figured out what a proper bzr packaging branch is.
[18:22] <mhall119> ah, ok
[18:23] <mhall119> anywhere I learn what the general setup should be like? or do I just bzr init the folder I'm using to build?
[18:24] <ScottK> Most people I know of just put /debian in bzr for packaging.
[18:24] <mhall119> ok
[18:25] <mhall119> what's the command to download and unpackage the upstream .tar.gz?
[18:25] <mhall119> from the watch file
[18:25] <ebroder> barry: Wait, how were you getting it to use the i386 chroot before?
[18:25] <mhall119> or does dbuild do that if it doesn't see a local copy?
[18:35] <ScottK> mhall119: uscan
[18:54] <mhall119> what regex format does uscan use?
[18:54] <Rhonda> perl
[18:55] <Rhonda> mhall119: file $(which uscan)  # :)
[18:55] <mhall119> heh
[18:55] <tillux> Hi there - I'd like to upload a package to my PPA, but I need to specify certain ./configure options/parameters but I don't know how to do that, I'd be glad if someone could point out to me where to start or what to do ;)
[19:02] <mhall119> okay, got uscan working
[19:03] <mhall119> I have get-orig-source: uscan --force-download --repack --rename --destdir .
[19:03] <mhall119> in my debian/rules
[19:03] <mhall119> how to I call that?
[19:03] <micahcowan> tillux, wouldn't that sort of thing go into the source package's debian/rules ?
[19:04] <micahcowan> mhall119, "debian/rules get-orig-source", probably?
[19:06] <mhall119> I assume I somehow tell debuild to run get-orig-source
[19:07] <tumbleweed> mhall119: get-orig-source is outside debuild's world, if you  are packaging in bzr, bzr bd knows to run get-orig-source
[19:07] <tillux> micahcowan: if you tell me so, probably, yes ;)
[19:07] <micahcowan> tillux, have you built a binary package from a source package before?
[19:08] <tillux> yes
[19:08] <micahcowan> Okay, so yeah, just modify your debian/rules to add the ./configure options, and then package the binary, and upload that.
[19:09] <mhall119> thanks tumbleweed, now I have other errors though
[19:10] <mhall119> fixed em
[19:10] <tumbleweed> mhall119: good :) (btw, #ubuntu-packaging is probably a better place for packaging questions)
[19:10] <tumbleweed> err, for "lots of help with packaging" a quick question is obviously fine here
[19:11]  * micahcowan didn't know about #ubuntu-packaging
[19:12] <mhall119> I didn't know about it either, thanks
[19:52] <mhall119> can someone point me to where I can learn about submitting packages to Debian?
[19:52] <micahcowan> mhall119, completely new package, or new version of an existing package?
[19:53] <mhall119> completely new
[19:55] <micahcowan> Not really up on the details but search for info about ITP ("intent to package") bugs.
[20:00] <mhall119> ok, thanks
[20:02] <tumbleweed> mhall119: http://www.za.debian.org/doc/manuals/maint-guide/
[20:03] <udienz> mhall119: submit your package to mentors.debian.net
[20:58] <tillux> what is the procedure for updating/submitting a new version of an existing pacakge to debian and then requesting a sync to ubuntu (with patches, at least it was like that for an older version of that package)?
[20:59] <tumbleweed> tillux: for the new version in debian, contact the debian maintainer of the package
[21:00] <tumbleweed> if possible get debian to include those patches, so it *can* be synced
[21:03] <tillux> They might already be included, didn't check the latest version in debian. The main problem is that the package (denemo) is currently evolving quite quickly (which is why I also want to add git-weekly-(or so) builds to my launchpad ppa...)
[21:05] <tumbleweed> launchpad can do daily PPA builds for you
[21:09] <tillux> tumbleweed: I didn't know that, is there some kind of instructional page somwhere?
[21:10] <tumbleweed> https://help.launchpad.net/Packaging/SourceBuilds
[23:06] <kklimonda> bummers, how to create a sid chroot in pbuilder?
[23:06] <kklimonda> I get "E: Release signed by unknown key" and can't remember the fix for it
[23:07] <micahg> kklimonda: specify the keyring as an argument?
[23:07] <tumbleweed> kklimonda: install debian-archive-keyring and pass an appropriate --keyring option to debootstrap
[23:07] <tumbleweed> (pbuilder-dist knows what to do)
[23:07] <kklimonda> ok, thanks
[23:08] <micahg> you also need the natty keyring
[23:08] <micahg> *debian-archvie-keyring from natty
[23:09] <kklimonda> hmm.. I don't use pbuilder-dist for some reason..
[23:09] <kklimonda> and it was a good reason but I can't remember it
[23:10] <kklimonda> I guess I'll just start using it again until I hit some problem
[23:10] <tumbleweed> I don't either, but I'm also thinking I should :) (once I get it to support mirrors)
[23:11]  * micahg needs to get pbuilder-dist to recognize -updates, -proposed, -security, and -backports
[23:11] <tumbleweed> err yeah that too
[23:12] <tumbleweed> I currently handle that via a pbuilder hook