[09:50] <rbasak> I can't seem to change the upstream bug task to a Debian nis package bug task in bug 1204530. The distro list doesn't include Debian. Is this a known bug?
[09:51] <rbasak> It's already tracking the Debian bug, just against an "upstream" instead of a "distro package" (not sure what the right terms are)
[09:56] <wgrant> rbasak: It's only possible to move a task to a target that tracks bugs in LP. If you want a Debian task, you need to add a new task with the bug watch directly.
[10:11] <rbasak> wgrant: ah, so add a new task and delete the upstream one? That sort of works in that I can add the Debian task, but I can't delete the upstream task as it's a project I don't have permission on.
[10:11] <rbasak> (whereas I think I could normally move a task from upstream if it was wrong)
[10:11] <rbasak> But that's better at least, thanks.
[10:13] <wgrant> rbasak: I've deleted the upstream task.
[10:13] <rbasak> Thanks!
[10:14] <rbasak> Normally I don't care but this is a bug I want to hand to a new starter as an exercise so I'd like the bug status right so as not to confuse things.
[10:19] <wgrant> Good idea :)
[18:00] <mbroadst> hi, I'm trying to upload a 'precise' version of a package using gbp. I already have a 'trusty' version on the PPA, and each time I try to dput the 'precise' version it indicates that the orig tarball already exists and the one being uploaded differs
[18:00] <mbroadst> I went and downloaded the orig tarball associated with the trusty one, imported it into my upstream/<version> branch, and rebuilt the source from there and it still says it differs
[18:01] <mbroadst> at this point I'm not quite sure what I'm doing wrong, it doesn't seem like they _could_ differ
[18:03] <dobey> you can't upload the same source twice
[18:03] <dobey> the same orig.tar.gz that is
[18:05] <mbroadst> dobey: but both trusty and precise versions are based on the same orig source, is there a way to avoid dput uploading that file?
[18:05] <dobey> mbroadst: are you building the source with -sa option to debbuild?
[18:11] <mbroadst> ah hm no
[18:11] <mbroadst> I was just passing -S into gbp buildpackage
[18:11] <dobey> ok, then you probably have done something that caused the orig.tar.gz to be different than the previous upload
[18:12] <dobey> and the error you're actually getting is that it already exists and you're trying to upload different contents
[18:14] <mbroadst> but how's that possible though? it says its generating the orig.tar.gz from upstream/<version>, I just downloaded the actual orig.tar.gz and import-orig'd that into upstream/<version>
[18:15] <dobey> i don't know what you're doing exactly, but are you building a package that is format native?
[18:17] <mbroadst> no its format is quilt
[18:17] <mbroadst> (I'm sorry this project was sort of dumped on me, I'm trying to catch up)
[18:19] <dobey> you did apt-get source, imported that to bzr, and then are trying to build a source package from that?
[18:20] <mbroadst> I've got this repo: https://github.com/mbroadst/debian-qpid-proton
[18:21] <mbroadst> and the "trusty" branch works, upstream points to version 0.10 of proton that was downloaded, as well as upstream/0.10
[18:21] <mbroadst> the precise branch had to be imported using 'gbp import-dsc --debian-branch=precise', and then I merged in upstream and updated the patches
[18:22] <mbroadst> because the previous precise release was for verison 0.9
[18:24] <mbroadst> the two versions share a common codebase, but the precise version needs a single patch applied to it
[18:25] <mbroadst> I presume I've done that all wrong :)
[18:53] <mbroadst> dobey: any thoughts?
[18:54] <mbroadst> I just went through the process from scratch, this time completely copying the existing trust branch and building from that to no avail
[18:54] <mbroadst> it just seems impossible that they are actually generating different orig.tar.gz files
[18:54] <mbroadst> and yet they are
[18:54] <dobey> i don't know what you're doing exactly, so i'm not sure why it's generating a different orig.tar.gz
[18:55] <teward> dobey: if he doesn't precreate the orig.tar.gz from source code without the debian/ directory it *might* include that
[18:55] <teward> no?
[18:55] <dobey> i'd say compare the orig.tar.gz that is failing for you, to the one already on the server, and see what the difference is
[18:55] <dobey> teward: or .git/
[18:55] <teward> dobey: that too, I actually torpedo that folder if it exists
[18:55] <teward> AND i keep the debian/ folder out of the tarball
[18:56] <teward> and always generate the orig tarball from just the source
[18:56] <teward> (debuild -S creates the debian part as its own tarball strangely enough when I run it)
[18:56] <mbroadst> I just unpacked them both next to each other and they were identical
[18:56] <mbroadst> so frustrating..
[18:56] <dobey> yes, it should create debian.tar.gz for format 3.0 packages
[18:57] <dobey> mbroadst: are the md5sums identical?
[18:58] <mbroadst> nope
[18:59] <mbroadst> now to see what else is screwed up here..
[18:59] <teward> mbroadst: open the orig.tar.gz and extract it.  Do you have a .git or debian/ folder in there?
[19:00] <dobey> yeah, make sure the hidden files or debian/ dir are not in the new orig.tar.gz
[19:00] <mbroadst> no, neither
[19:01] <mbroadst> absolutely bizarre, diff -arq from-build from-apt results in 0 differences
[19:02] <mbroadst> as in, once they've both been extracted
[19:02] <mbroadst> perhaps the timestamp in like gzip?
[19:03] <mbroadst> I guess this would just work if I manually place the orig.tar.gz before the dput
[19:03] <teward> i'mma try and replicate your steps if you don't mind?
[19:04] <mbroadst> sure
[19:04] <mbroadst> (btw the documentation on launchpad itself suggests just downloading the orig.tar.gz and placing it by hand..)
[19:07] <mbroadst> annd that worked
[19:07] <mbroadst> *sigh*
[19:08] <mbroadst> seriously I give it up to you guys maintaining packages in this process, it's been very exhausting :)
[19:08] <teward> well
[19:08] <teward> i have an idea how to produce pristine-tarball for you
[19:08] <teward> but you'll hate it
[19:08] <teward> and it's the 'manual' way
[19:09] <teward> dobey: no way to force it to accept the version now that there's a copy already up on the PPA right?
[19:09] <dobey> teward: delete the orig.tar.gz from the .dsc i guess?
[19:10] <teward> possibly
[19:10] <dobey> and/or source.changes
[19:10] <dobey> i think the problem is that it had to recreate the orig.tar.gz
[19:10] <teward> mmm
[19:10] <dobey> so it's including it in the upload
[19:10] <teward> probably the case
[19:11] <dobey> *shrug*
[19:11] <dobey> i can't really help any further though :)
[19:11] <teward> yep
[19:11] <mbroadst> yeah I think what happened was that I deleted the orig.tar.gz in the level above the package dir (where it builds all the artifacs) as a sort of OCD measure
[19:12] <mbroadst> so it rebuilt the orig.tar.gz, and gzip added a timestamp to that
[19:12] <mbroadst> so the md5s _would_ be different, even though the contents are identical
[19:12] <mbroadst> and afiact launchpad is checking checksums not contents
[19:12] <dobey> or more likely, it was compressed at a different level
[19:13] <dobey> which would result in different contents
[19:13] <mbroadst> http://serverfault.com/questions/110208/different-md5sums-for-same-tar-contents
[19:13] <dobey> mbroadst: it compares contents of the resulting .gz, not of the unpacked tarball
[19:14] <teward> and i went the manual route - grabbed source, built orig tarball, modified debian/ and pushed to a pristine PPA, and I know that method works xD
[19:14]  * teward is bored :)
[19:14] <teward> point not withstanding there's still a conflict somewhere along the line, making sure your orig.tar.gz is the pristine source code helps a little, IMO, even if it's an extra manual step
[19:16] <teward> mbroadst: i think you'll have bigger concerns than a failed orig tarball
[19:16] <teward> FTBFS on precise
[19:16] <teward> both amd64 and i386
[19:17] <teward> mbroadst: https://launchpad.net/~teward/+archive/ubuntu/qpid-proton/+packages if you're curious where I get that info from
[19:17] <teward> but meh
[19:17] <teward> mbroadst: the second tricky part was the versioning, PPAs can't have two versionstrings for the same package for different releases iirc
[19:17] <teward> dobey: i.e. 1.1.0-1 can't be uploaded twice (once for Precise, once for Trusty, if they both have to build separately?)
[19:20] <teward> mbroadst: granted i pulled master for those tests, but i don't see a precise branch anywhere either.
[19:23] <dobey> teward: correct
[19:23] <teward> dobey: that's what i thought, just wanted to confirm :)
[19:23] <teward> oop low power in my laptop lol
[19:23] <dobey> appending ~12.04.1 and ~14.04.1 to the version would help there
[19:24] <teward> mhm
[19:24] <teward> i use +trusty0 or +precise0 because nginx packaging is weirdly done but meh
[19:24] <teward> but that's just for nginx
[19:24] <teward> there's multiple ways to do the version string though
[19:24] <teward> :)
[19:29] <mbroadst> teward: man the main page said it passed
[19:29] <teward> mbroadst: what main page where
[19:29] <mbroadst> back to the drawing board :)
[19:29] <teward> you should answer questions
[19:29] <teward> IMO
[19:30] <teward> mbroadst: i have build failure logs if you want
[19:30] <mbroadst> yeah I can fix that, it looks like the wrong patch was applied
[19:30] <teward> mbroadst: https://launchpadlibrarian.net/216090493/buildlog_ubuntu-precise-amd64.qpid-proton_0.10-1~precise~ppa0_BUILDING.txt.gz and https://launchpadlibrarian.net/216090570/buildlog_ubuntu-precise-i386.qpid-proton_0.10-1~precise~ppa0_BUILDING.txt.gz
[19:30] <mbroadst> if you look here: https://launchpad.net/~qpid/+archive/ubuntu/testing
[19:30] <teward> mbroadst: any patches applied now have to be applied through quilt
[19:30] <teward> or a version bump :P
[19:30] <mbroadst> "latest updates" proton built fine for precise
[19:31] <teward> :P
[19:31] <mbroadst> oh maybe you grabbed the source before my update
[19:31] <teward> mbroadst: well there you go
[19:31] <teward> mbroadst: probably did, but meh
[19:31] <teward> in any case
[19:31]  * teward yawns
[19:31] <mbroadst> sorry I'm a little scatterbrained :)
[19:31] <teward> i'mma go do something else now
[19:31] <mbroadst> thanks for the help
[19:32] <teward> mbroadst: you're welcome.  my advice for making a pristine tarball:
[19:33] <teward> git clone; mv debian-qpid-proton qpid-proton-VERSIONNUMBER; cd qpid-proton-VERSIONNUMBER; mv ./debian ..; cd ..; tar czvf qpid-proton_VERSIONNUMBER.orig.tar.gz qpid-proton-VERSIONUMBER; mv ./debian qpid-proton-VERSIONNUMBER;
[19:33] <teward> debuild
[19:34] <teward> done
[19:34] <teward> eww splits
[19:35] <mbroadst> yeah seems like a saner alternative
[19:59] <cjwatson> mbroadst: using pristine-tar would have made your life much easier
[20:00] <cjwatson> (tool that efficiently automates the process of representing how to get from a branch with orig contents to a byte-for-byte identical orig.tar.gz)
[20:01] <cjwatson> gbp probably integrates with it too
[20:01] <cjwatson> I know git-dpm does
[20:29] <aquarius> I have a folder of code, which I currently have in bzr in a junk branch on launchpad. I have created a proper Launchpad project for it, and now I want the code in there. What's the best way to do this? I could, in the project on LP, import the branch from my junk branch, but that won't change the branch on my computer; I could (perhaps? don't know?) just bzr push lp:projectname from the folder on the computer and th
[20:29] <aquarius> en it all works? Not sure what to do here.
[20:30] <dobey> aquarius: bzr push --remember yes
[20:30] <dobey> aquarius: doing anything on the launchpad UI itself will not modify your local copy at all
[20:31] <aquarius> that's all? Does creating the project on LP create the right receiving environment that I can just push to it?
[20:31] <aquarius> I am not sure of my vocab here :)
[20:32] <beuno> aquarius, it does
[20:32] <aquarius> nice.
[20:32] <beuno> --remember is so bzr pushes there from then on
[20:32] <dobey> you'll have to push to lp:~aquarius/project/name first
[20:32] <aquarius> ah, will I?
[20:33] <dobey> you can't push to lp:foo without first creating the branch and linking it to the trunk series as the development focus
[20:33] <dobey> but you can just create an empty branch on lp to do that if you want, and then push --overwrite --use-existing --remember
[20:35] <aquarius> dobey, so, I should do "bzr push --remember lp:~sil/wifitransfer/trunk"? and then set that pushed branch as the development focus?
[20:36] <dobey> aquarius: yes
[20:37] <beuno> aquarius, and from then on, lp:wifitransfer will be a thing
[20:41]  * aquarius does so
[20:44] <cjwatson> dobey: not in fact true
[20:44] <dobey> cjwatson: what's not?
[20:45] <cjwatson> if you push to lp:foo, it doesn't already exist, and you have necessary privileges, then it'll autocreate a branch name with some unused name based on "trunk" and link it to lp:foo for you
[20:45] <dobey> cjwatson: oh, i wasn't aware of that. how long has that been the case?
[20:46] <beuno> *magic*
[20:46] <cjwatson> dobey: since about August 2010, I believe
[20:47] <dobey> oh, wow
[20:47] <cjwatson> a similar thing works with git
[20:47] <dobey> good to know :)
[20:48] <cjwatson> (which is why I know about this; I spent some time understanding that code in order to implement the same kind of thing for git)
[20:48] <cjwatson> it's all buried in lib/lp/code/xmlrpc/ because reasons
[20:49] <dobey> tmi ;)
[20:50] <cjwatson> aquarius: fwiw it would also have been possible to move it around from "Change details" in the LP web UI, and then "bzr push --remember" wouldn't need to re-push it
[20:50] <cjwatson> aquarius: presumably now you'll want to delete the junk branch
[20:50] <aquarius> ah. I did wonder whether that was doable. Well, I have pushed it now, anyway; now to set it as development focus
[20:52] <aquarius> yay, that seems to have worked
[21:04] <aquarius> goldarnit. I made the app name a translatable string
[21:04] <aquarius> now to work out how to fix that
[21:08] <dobey> make it not be
[21:13] <aquarius> yup. Fixed.