[00:27] kklimonda: Sounds great. [00:27] kklimonda: Thanks for sticking with it. [01:22] hello, i want to ask about patching [01:23] sorry for my bad english [01:23] someone report bug and he attached patch [01:24] can i apply his patch and submitting to ubuntu-motu? [05:09] 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] http://bazaar.launchpad.net/~ubuntu-desktop/vte/ubuntu/ and http://bazaar.launchpad.net/~ubuntu-desktop/vte/ubuntu/ respectively. [05:10] They are not branches of the same code (apparently?), as they have no common ancestors, so can't be merged. [05:10] 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] Or, more succinctly, "it's complicated" [05:11] (oops, that second one ought to have been: lp:ubuntu/vte [05:12] 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] ebrpder. is this sort of thing documented anywhere? [05:19] micahcowan: Not that I know of === vorian is now known as birthday-vorian [08:03] good morning! [08:04] \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] \sh: np === hrw|gone is now known as hrw === Zhenech_ is now known as Zhenech [12:47] 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] that gives you a pbuilder which builds the package with no network (package download and hooks still have net access) [12:52] geser: ok, thanks [13:04] yay, I'm two uploads from fixing python-visual FTBFS.. it took me a month to get here.. [13:05] I hope the python2.7 plans don't interfere with your progress [13:06] that's why I have to upload it fast so it doesn't affect me! ;) [13:07] the package builds fine for both 2.6 and 2.7 - the ftbfs wasn't related to python === yofel_ is now known as yofel === Zhenech_ is now known as Zhenech [13:50] kklimonda: I think the work you are doing will also fix python-hildon. [14:09] 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] kklimonda: OK. Cool. [14:22] ScottK: ugh, are we actually interested in supporting Hildon in Ubuntu? python-hildon looks mostly unmaintained at the upstream. [14:22] the last version I can find is 0.9.0 released over a year ago [14:22] kklimonda: If it's in the archive it should build. I don't care if it's removed or fixed. [14:24] ok, I'll ask mvo (update-manager-hildon is the only reverse dependency) about it === zul_ is now known as zul [14:45] 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] Launchpad bug 687353 in python-hildon (Ubuntu) "remove python-hildon from archive" [Wishlist,Incomplete] https://launchpad.net/bugs/687353 [14:45] kklimonda: Great. === hannesw_ is now known as hannesw === xfaf is now known as zul === dholbach_ is now known as dholbach [16:33] kklimonda: python-visual just needs a retry? [16:35] Done in any case. [16:35] kklimonda: Thanks for all your work on this. [16:37] ScottK: I think it's too soon as gtkglextmm is still building - I've unassigned myself as doko is working on it. [16:37] but yes, python-visual just needs a retry when gtkglextmm is published :) [16:38] kklimonda: It'll be some time before it gets done since the builders are all very busy. [16:38] If it hits too soon, I'll retry it again. [16:38] ScottK: yes, I've noticed - especially the powerpc one is swamped with jobs :) [16:39] Yes, but even i386 and amd64 are very behind at the moment. [16:39] oh, there are even two - but still it's not enough and they have a 40hrs+ queue [16:39] Yep. [16:40] powerpc builds ~as fast as amd64, but there are more amd64 builders now, so powerpc lags. [16:43] oh? powerpc is that fast? [16:44] I've always assumed that it's also slower than i386 and amd64 - not as much as armel but still === hrw is now known as hrw|gone [17:36] argh. debuild keeps auto-creating a patch called debian-changes-... ; i don't know how to prevent that from happening. any clues? [17:36] "This patch has been created by dpkg-source during the package build."... [17:36] achiang: it happens when you modify source in place [17:36] achiang, thats created by 3.0 format [17:36] source format* [17:38] 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] for the "in-place" thing [17:41] 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] achiang: I'd suggest checking content of this file to see what's going on [17:41] kklimonda: yeah. i was actually editing a patch in place. ;) [17:42] kklimonda: thanks, i'll go do that [17:46] kklimonda: no, powerpc isn't slow. :) [17:46] … otherwise I would kill myself packaging wesnoth on it [17:49] ah, good wesnoth - I remember it using all my ram and swap few years back, during one of my affairs with Gentoo. [17:49] Sure it was wesnoth and not the background emerge of your gentoo system? ;) [17:50] well, it may have been my highly tuned compiler flags that were the real culprit ;) [17:51] what's the changelog line for closing a needs-packaging bug? [17:52] mhall119: * Initial release. (LP: #XXXXXXX) is fine [17:52] Usually: Initial upload (LP: #1234) (or closes: if it was for Debian) [17:52] Actually dh_make should put that into your changelog already. [17:52] * Add watch file and closes bug #687431 (LP: #687431) [17:52] Launchpad bug 687431 in xdg-launcher "[needs-packaging] xdg-launcher" [Wishlist,New] https://launchpad.net/bugs/687431 [17:52] will that do? [17:53] it did, but I wasn't ready to close it in the first iteration [17:53] * mhall119 is still a packing noob [17:53] mhall119: A bit of double information. "Add watch file (LP: #687431)" is enough. :) [17:53] ok [17:54] … if adding the watchfile is the bug. [17:54] no, the bug is the needs-packaging bug [17:54] The bug though is rather about needs-packaging, not about a missing watchfile in the package. [17:54] but the last change i made to this package was adding the watch file [17:54] Yes, then two lines. One with " * Initial upload (LP: #687431)" and one with " * Add watchfile" [17:54] ok [17:55] * Initial upload (LP: #687431) [17:55] * Add watch file [17:55] 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] liek that? [17:55] it's a change to the package though [17:55] You would put a add watch file line if it wasn't part of a former upload. [17:55] since I built and uploaded to my ppa without the watchfile [17:56] * kklimonda kisses eatmydata - my precious [17:56] http://paste.ubuntu.com/541081/ is my current changelog [18:05] do I need to put copyright headers on all my python and shell files? [18:05] mhall119: Yes, but you needn't consider the PPA history in your debian/changelog for Ubuntu [18:06] okay, I was using the same instance for both uploads [18:06] is there a prefered template for source code copyright header? [18:06] 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] What license? [18:06] GPLv2 [18:06] GPL provides one. [18:07] thanks, found it [18:17] is there a way to turn my current packaging directory into a proper bzr package branch? [18:19] woot! no lintian complaints http://revu.ubuntuwire.com/p/xdg-launcher [18:21] Not everyone is convinced we've figured out what a proper bzr packaging branch is. [18:22] ah, ok [18:23] 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] Most people I know of just put /debian in bzr for packaging. [18:24] ok [18:25] what's the command to download and unpackage the upstream .tar.gz? [18:25] from the watch file [18:25] barry: Wait, how were you getting it to use the i386 chroot before? [18:25] or does dbuild do that if it doesn't see a local copy? [18:35] mhall119: uscan [18:54] what regex format does uscan use? [18:54] perl [18:55] mhall119: file $(which uscan) # :) [18:55] heh [18:55] 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] okay, got uscan working [19:03] I have get-orig-source: uscan --force-download --repack --rename --destdir . [19:03] in my debian/rules [19:03] how to I call that? [19:03] tillux, wouldn't that sort of thing go into the source package's debian/rules ? [19:04] mhall119, "debian/rules get-orig-source", probably? [19:06] I assume I somehow tell debuild to run get-orig-source [19:07] 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] micahcowan: if you tell me so, probably, yes ;) [19:07] tillux, have you built a binary package from a source package before? [19:08] yes [19:08] Okay, so yeah, just modify your debian/rules to add the ./configure options, and then package the binary, and upload that. [19:09] thanks tumbleweed, now I have other errors though [19:10] fixed em [19:10] mhall119: good :) (btw, #ubuntu-packaging is probably a better place for packaging questions) [19:10] 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] I didn't know about it either, thanks [19:52] can someone point me to where I can learn about submitting packages to Debian? [19:52] mhall119, completely new package, or new version of an existing package? [19:53] completely new [19:55] Not really up on the details but search for info about ITP ("intent to package") bugs. [20:00] ok, thanks [20:02] mhall119: http://www.za.debian.org/doc/manuals/maint-guide/ [20:03] mhall119: submit your package to mentors.debian.net [20:58] 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] tillux: for the new version in debian, contact the debian maintainer of the package [21:00] if possible get debian to include those patches, so it *can* be synced === tillux1 is now known as tillux [21:03] 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] launchpad can do daily PPA builds for you [21:09] tumbleweed: I didn't know that, is there some kind of instructional page somwhere? [21:10] https://help.launchpad.net/Packaging/SourceBuilds === Zhenech_ is now known as Zhenech [23:06] bummers, how to create a sid chroot in pbuilder? [23:06] I get "E: Release signed by unknown key" and can't remember the fix for it [23:07] kklimonda: specify the keyring as an argument? [23:07] kklimonda: install debian-archive-keyring and pass an appropriate --keyring option to debootstrap [23:07] (pbuilder-dist knows what to do) [23:07] ok, thanks [23:08] you also need the natty keyring [23:08] *debian-archvie-keyring from natty [23:09] hmm.. I don't use pbuilder-dist for some reason.. [23:09] and it was a good reason but I can't remember it [23:10] I guess I'll just start using it again until I hit some problem [23:10] 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] err yeah that too [23:12] I currently handle that via a pbuilder hook