/srv/irclogs.ubuntu.com/2015/09/01/#launchpad.txt

=== maclin1 is now known as maclin
=== maclin1 is now known as maclin
=== maclin1 is now known as maclin
=== maclin1 is now known as maclin
=== maclin1 is now known as maclin
rbasakI 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:50
ubot5bug 1204530 in nis (Ubuntu) "yppasswd results in a segmentation fault when run on clients or server" [High,Confirmed] https://launchpad.net/bugs/120453009:50
rbasakIt's already tracking the Debian bug, just against an "upstream" instead of a "distro package" (not sure what the right terms are)09:51
wgrantrbasak: 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.09:56
rbasakwgrant: 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
rbasakBut that's better at least, thanks.10:11
wgrantrbasak: I've deleted the upstream task.10:13
rbasakThanks!10:13
rbasakNormally 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:14
wgrantGood idea :)10:19
=== gaughen_ is now known as gaughen
mbroadsthi, 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 differs18:00
mbroadstI 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 differs18:00
mbroadstat this point I'm not quite sure what I'm doing wrong, it doesn't seem like they _could_ differ18:01
dobeyyou can't upload the same source twice18:03
dobeythe same orig.tar.gz that is18:03
mbroadstdobey: 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
dobeymbroadst: are you building the source with -sa option to debbuild?18:05
mbroadstah hm no18:11
mbroadstI was just passing -S into gbp buildpackage18:11
dobeyok, then you probably have done something that caused the orig.tar.gz to be different than the previous upload18:11
dobeyand the error you're actually getting is that it already exists and you're trying to upload different contents18:12
mbroadstbut 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:14
dobeyi don't know what you're doing exactly, but are you building a package that is format native?18:15
mbroadstno its format is quilt18:17
mbroadst(I'm sorry this project was sort of dumped on me, I'm trying to catch up)18:17
dobeyyou did apt-get source, imported that to bzr, and then are trying to build a source package from that?18:19
mbroadstI've got this repo: https://github.com/mbroadst/debian-qpid-proton18:20
mbroadstand the "trusty" branch works, upstream points to version 0.10 of proton that was downloaded, as well as upstream/0.1018:21
mbroadstthe precise branch had to be imported using 'gbp import-dsc --debian-branch=precise', and then I merged in upstream and updated the patches18:21
mbroadstbecause the previous precise release was for verison 0.918:22
mbroadstthe two versions share a common codebase, but the precise version needs a single patch applied to it18:24
mbroadstI presume I've done that all wrong :)18:25
mbroadstdobey: any thoughts?18:53
mbroadstI just went through the process from scratch, this time completely copying the existing trust branch and building from that to no avail18:54
mbroadstit just seems impossible that they are actually generating different orig.tar.gz files18:54
mbroadstand yet they are18:54
dobeyi don't know what you're doing exactly, so i'm not sure why it's generating a different orig.tar.gz18:54
tewarddobey: if he doesn't precreate the orig.tar.gz from source code without the debian/ directory it *might* include that18:55
tewardno?18:55
dobeyi'd say compare the orig.tar.gz that is failing for you, to the one already on the server, and see what the difference is18:55
dobeyteward: or .git/18:55
tewarddobey: that too, I actually torpedo that folder if it exists18:55
tewardAND i keep the debian/ folder out of the tarball18:55
tewardand always generate the orig tarball from just the source18:56
teward(debuild -S creates the debian part as its own tarball strangely enough when I run it)18:56
mbroadstI just unpacked them both next to each other and they were identical18:56
mbroadstso frustrating..18:56
dobeyyes, it should create debian.tar.gz for format 3.0 packages18:56
dobeymbroadst: are the md5sums identical?18:57
mbroadstnope18:58
mbroadstnow to see what else is screwed up here..18:59
tewardmbroadst: open the orig.tar.gz and extract it.  Do you have a .git or debian/ folder in there?18:59
dobeyyeah, make sure the hidden files or debian/ dir are not in the new orig.tar.gz19:00
mbroadstno, neither19:00
mbroadstabsolutely bizarre, diff -arq from-build from-apt results in 0 differences19:01
mbroadstas in, once they've both been extracted19:02
mbroadstperhaps the timestamp in like gzip?19:02
mbroadstI guess this would just work if I manually place the orig.tar.gz before the dput19:03
tewardi'mma try and replicate your steps if you don't mind?19:03
mbroadstsure19:04
mbroadst(btw the documentation on launchpad itself suggests just downloading the orig.tar.gz and placing it by hand..)19:04
mbroadstannd that worked19:07
mbroadst*sigh*19:07
mbroadstseriously I give it up to you guys maintaining packages in this process, it's been very exhausting :)19:08
tewardwell19:08
tewardi have an idea how to produce pristine-tarball for you19:08
tewardbut you'll hate it19:08
tewardand it's the 'manual' way19:08
tewarddobey: no way to force it to accept the version now that there's a copy already up on the PPA right?19:09
dobeyteward: delete the orig.tar.gz from the .dsc i guess?19:09
tewardpossibly19:10
dobeyand/or source.changes19:10
dobeyi think the problem is that it had to recreate the orig.tar.gz19:10
tewardmmm19:10
dobeyso it's including it in the upload19:10
tewardprobably the case19:10
dobey*shrug*19:11
dobeyi can't really help any further though :)19:11
tewardyep19:11
mbroadstyeah 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 measure19:11
mbroadstso it rebuilt the orig.tar.gz, and gzip added a timestamp to that19:12
mbroadstso the md5s _would_ be different, even though the contents are identical19:12
mbroadstand afiact launchpad is checking checksums not contents19:12
dobeyor more likely, it was compressed at a different level19:12
dobeywhich would result in different contents19:13
mbroadsthttp://serverfault.com/questions/110208/different-md5sums-for-same-tar-contents19:13
dobeymbroadst: it compares contents of the resulting .gz, not of the unpacked tarball19:13
tewardand i went the manual route - grabbed source, built orig tarball, modified debian/ and pushed to a pristine PPA, and I know that method works xD19:14
* teward is bored :)19:14
tewardpoint 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 step19:14
tewardmbroadst: i think you'll have bigger concerns than a failed orig tarball19:16
tewardFTBFS on precise19:16
tewardboth amd64 and i38619:16
tewardmbroadst: https://launchpad.net/~teward/+archive/ubuntu/qpid-proton/+packages if you're curious where I get that info from19:17
tewardbut meh19:17
tewardmbroadst: the second tricky part was the versioning, PPAs can't have two versionstrings for the same package for different releases iirc19:17
tewarddobey: 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:17
tewardmbroadst: granted i pulled master for those tests, but i don't see a precise branch anywhere either.19:20
dobeyteward: correct19:23
tewarddobey: that's what i thought, just wanted to confirm :)19:23
tewardoop low power in my laptop lol19:23
dobeyappending ~12.04.1 and ~14.04.1 to the version would help there19:23
tewardmhm19:24
tewardi use +trusty0 or +precise0 because nginx packaging is weirdly done but meh19:24
tewardbut that's just for nginx19:24
tewardthere's multiple ways to do the version string though19:24
teward:)19:24
mbroadstteward: man the main page said it passed19:29
tewardmbroadst: what main page where19:29
mbroadstback to the drawing board :)19:29
tewardyou should answer questions19:29
tewardIMO19:29
tewardmbroadst: i have build failure logs if you want19:30
mbroadstyeah I can fix that, it looks like the wrong patch was applied19:30
tewardmbroadst: 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.gz19:30
mbroadstif you look here: https://launchpad.net/~qpid/+archive/ubuntu/testing19:30
tewardmbroadst: any patches applied now have to be applied through quilt19:30
tewardor a version bump :P19:30
mbroadst"latest updates" proton built fine for precise19:30
teward:P19:31
mbroadstoh maybe you grabbed the source before my update19:31
tewardmbroadst: well there you go19:31
tewardmbroadst: probably did, but meh19:31
tewardin any case19:31
* teward yawns19:31
mbroadstsorry I'm a little scatterbrained :)19:31
tewardi'mma go do something else now19:31
mbroadstthanks for the help19:31
tewardmbroadst: you're welcome.  my advice for making a pristine tarball:19:32
tewardgit 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
tewarddebuild19:33
tewarddone19:34
tewardeww splits19:34
mbroadstyeah seems like a saner alternative19:35
cjwatsonmbroadst: using pristine-tar would have made your life much easier19:59
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:00
cjwatsongbp probably integrates with it too20:01
cjwatsonI know git-dpm does20:01
aquariusI 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 th20:29
aquariusen it all works? Not sure what to do here.20:29
dobeyaquarius: bzr push --remember yes20:30
dobeyaquarius: doing anything on the launchpad UI itself will not modify your local copy at all20:30
aquariusthat's all? Does creating the project on LP create the right receiving environment that I can just push to it?20:31
aquariusI am not sure of my vocab here :)20:31
beunoaquarius, it does20:32
aquariusnice.20:32
beuno--remember is so bzr pushes there from then on20:32
dobeyyou'll have to push to lp:~aquarius/project/name first20:32
aquariusah, will I?20:32
dobeyyou can't push to lp:foo without first creating the branch and linking it to the trunk series as the development focus20:33
dobeybut you can just create an empty branch on lp to do that if you want, and then push --overwrite --use-existing --remember20:33
aquariusdobey, so, I should do "bzr push --remember lp:~sil/wifitransfer/trunk"? and then set that pushed branch as the development focus?20:35
dobeyaquarius: yes20:36
beunoaquarius, and from then on, lp:wifitransfer will be a thing20:37
* aquarius does so20:41
cjwatsondobey: not in fact true20:44
dobeycjwatson: what's not?20:44
cjwatsonif 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 you20:45
dobeycjwatson: oh, i wasn't aware of that. how long has that been the case?20:45
beuno*magic*20:46
cjwatsondobey: since about August 2010, I believe20:46
dobeyoh, wow20:47
cjwatsona similar thing works with git20:47
dobeygood to know :)20:47
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
cjwatsonit's all buried in lib/lp/code/xmlrpc/ because reasons20:48
dobeytmi ;)20:49
cjwatsonaquarius: 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 it20:50
cjwatsonaquarius: presumably now you'll want to delete the junk branch20:50
aquariusah. I did wonder whether that was doable. Well, I have pushed it now, anyway; now to set it as development focus20:50
aquariusyay, that seems to have worked20:52
aquariusgoldarnit. I made the app name a translatable string21:04
aquariusnow to work out how to fix that21:04
dobeymake it not be21:08
aquariusyup. Fixed.21:13
=== cory_fu is now known as cory_out

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!