| mwhudson | does launchpad support mirroring git repos? | 05:33 |
|---|---|---|
| wgrant | mwhudson: I have it half done, but am currently distracted by some other work. | 05:38 |
| mwhudson | wgrant: damn ubuntu lts releases? | 07:08 |
| mwhudson | wgrant: would make git recipes about 1 million % more useful, as i'm sure is obvious | 07:09 |
| wgrant | Yeah, that's one of the main motivations. | 07:09 |
| mwhudson | i guess i can play games with an account that has a passwordless ssh key that only lives on some DC machine but eh... | 07:39 |
| chrisr_ | I'm still having problems with launchpad not triggering our builds. Could someone please check why launchpad does not pick up the uploads for cpp-ethereum in https://launchpad.net/~ethereum/+archive/ubuntu/ethereum ? Thanks a lot! | 09:24 |
| chrisr_ | uploaded a new package just now | 09:25 |
| cjwatson | chrisr_: You should have just got a rejection mail. | 09:30 |
| cjwatson | chrisr_: This time that should give you a bit more to go on. | 09:31 |
| cjwatson | chrisr_: If you didn't get it, I can dig it out of logs for you. | 09:31 |
| mwhudson | can i reference tags in git recipes? | 09:40 |
| cjwatson | Yes. | 09:41 |
| chrisr_ | cjwatson: thanks! Unfortunately, I don't have access to that address. Can I use a different address for "maintainer" and for the signing key? | 09:41 |
| wgrant | Hm, you're not using your own signing key? | 09:42 |
| cjwatson | chrisr_: You can, but only the signer will be mailed in the PPA case. | 09:43 |
| mwhudson | cjwatson: can you see what's going on here then? https://code.launchpad.net/~mwhudson/+recipe/golang-1.4-exp | 09:43 |
| cjwatson | Er, wait, no | 09:43 |
| wgrant | IIRC the maintainer will be emailed if they're a member of the PPA owner. | 09:43 |
| mwhudson | cjwatson: maybe i'm not actually specifying the right branch? | 09:43 |
| wgrant | Or something like that. | 09:43 |
| cjwatson | Yeah, that's right, I think it's just the signer. | 09:43 |
| cjwatson | I rewrote that code recently to be less twisty but it's still twisty. | 09:44 |
| cjwatson | chrisr_: so anyway, the rejections are like this: | 09:45 |
| cjwatson | 2016-04-05 09:25:15 DEBUG File cpp-ethereum_1.2.3~wily.orig.tar.gz already exists in Ethereum (Release builds), but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors. | 09:45 |
| cjwatson | chrisr_: Once you've uploaded a given file to a given archive, you may never upload the same file name with different contents. People mostly run into this with .orig.tar.gz if their workflow is for some reason not careful to preserve the existing one. | 09:46 |
| cjwatson | chrisr_: If you need to change the .orig.tar.gz, you need to increase the upstream part of the version number (before the last "-") | 09:47 |
| cjwatson | chrisr_: But usually it's not necessary to change the .orig.tar.gz, and this probably happens because the previous copy of that file isn't in the parent directory of the directory where you ran the source package build | 09:48 |
| cjwatson | chrisr_: Also, as a side note, you should stop using the ~wily etc. scheme and start using something like ~ubuntu15.10. We're running out of alphabet soon, so you can't continue to assume that the codenames will sort alphabetically. | 09:48 |
| chrisr_ | I don't think I need to change the orig.tar.gz, and actually I'm using debuild -sd | 09:49 |
| wgrant | mwhudson: Hm, that shouldn't happen unless the tagged commit isn't on any branch. | 09:50 |
| * wgrant looks. | 09:50 | |
| mwhudson | wgrant: hm, it may not be on a branch in that repo | 09:50 |
| mwhudson | yeah | 09:50 |
| wgrant | That'd be the problem. | 09:50 |
| chrisr_ | let me try a "clean build" | 09:50 |
| mwhudson | the way branches and pushes interact in git is still a bit unclear to me | 09:51 |
| cjwatson | chrisr_: debuild -sd is a good start, but only works if you have the correct .orig in your parent to build from. | 09:51 |
| cjwatson | chrisr_: You need to fix that before attempting to do a "clean build". | 09:51 |
| chrisr_ | ah, because of sha / md5sums? | 09:51 |
| wgrant | mwhudson: Branches and pushes are easy enough to understand. But don't try to understand tag fetch or push rules. | 09:51 |
| cjwatson | chrisr_: Right, the .dsc contains the checksums of all the files that make up the source package, and they must match. | 09:51 |
| mwhudson | wgrant: the tag not being present in the repo was my first problem... | 09:51 |
| cjwatson | chrisr_: The .changes only lists what's being uploaded, but the .dsc has the full set. | 09:52 |
| wgrant | mwhudson: git-build-recipe isn't currently clever enough to recognise a tag name and just directly clone it. It clones the repo, then gives the revision specifier to rev-parse. git clone will by default grab any tags that reference commits that are in any branch. | 09:52 |
| chrisr_ | cjwatson: it might be that increasing the version number is the safer bet then. Would something like 0.2.3+1~wily-0ubuntu1 work? | 09:52 |
| chrisr_ | 1.2.3+1~wily-0ubunt1 of course | 09:52 |
| cjwatson | chrisr_: Yes, but if you're increasing the version number anyway then you should take the opportunity to replace ~wily with ~ubuntu15.10 | 09:53 |
| cjwatson | chrisr_: But it shouldn't be necessary to increase the version number in this case | 09:53 |
| cjwatson | chrisr_: Just download the current .orig files from http://ppa.launchpad.net/ethereum/ethereum/ubuntu/pool/main/e/ethereum/ | 09:53 |
| mwhudson | wgrant: ah ok | 09:54 |
| cjwatson | chrisr_: Or, possibly more sensibly, from the various "Package files" sections resulting from expanding the cpp-ethereum uploads on https://launchpad.net/~ethereum/+archive/ubuntu/ethereum/+packages (that way it's at least transport-secured) | 09:54 |
| cjwatson | chrisr_: Make sure those are in the parent directory when you run debuild | 09:55 |
| chrisr_ | the problem is that we usually do that using our automation system... | 09:55 |
| cjwatson | Right, which is why you need to fix your automation :-) | 09:56 |
| cjwatson | Otherwise you'll just run into the exact same thing next time. | 09:56 |
| cjwatson | You need to keep the .orig files around, or else ensure that they are generated in a bit-for-bit reproducible way | 09:56 |
| cjwatson | (pristine-tar can help to achieve the latter, if you choose that) | 09:57 |
| chrisr_ | the problem is that the script downloads the release branch and determines the version from its contents, so it breaks if there is a commit to the release branch that does not increment the version number. | 09:59 |
| chrisr_ | and that is what happened actually | 10:00 |
| chrisr_ | since we want to include that change, I guess it is fair to increment the version number to +1 | 10:00 |
| cjwatson | chrisr_: That sounds reasonable | 10:03 |
| cjwatson | chrisr_: Sounds like a good case for using recipes (although if it's git then you would have to work around our current lack of git-to-git imports) | 10:04 |
| chrisr_ | we tag the actual release and we should only check out tags, but yeah, future improvements :-) | 10:08 |
| mwhudson | wgrant, cjwatson: now what? https://launchpadlibrarian.net/251803269/buildlog.txt.gz | 10:12 |
| mwhudson | is it possible that the revision for nest-part is being interpreted in the base branch not the nested one? | 10:12 |
| wgrant | I rewrote this code but have totally forgotten it. Will check. | 10:12 |
| cjwatson | It may be worth using git-build-recipe locally to iterate quickly. | 10:13 |
| mwhudson | yeah i guess but the branches are large and in london | 10:13 |
| mwhudson | can i put local paths in the recipe? | 10:13 |
| cjwatson | file:// | 10:13 |
| mwhudson | also bedtime | 10:13 |
| mwhudson | ok | 10:13 |
| cjwatson | Or is it just undecorated paths? One of those, probably both. | 10:13 |
| wgrant | wgrant@lamuella:~/tmp$ git ls-remote lp:~mwhudson/ubuntu/+source/golang-defaults/+git/xenial | grep tmp-go | 10:14 |
| wgrant | wgrant@lamuella:~/tmp$ | 10:14 |
| mwhudson | wgrant: but it's on https://git.launchpad.net/~mwhudson/ubuntu/+source/golang/+git/xenial/refs/heads?h=tmp-go-1.4 | 10:14 |
| mwhudson | this is me failing at git again i presume | 10:14 |
| mwhudson | waait | 10:15 |
| wgrant | Not the same repo :P | 10:15 |
| cjwatson | that's not the same repo | 10:15 |
| cjwatson | snap | 10:15 |
| mwhudson | wgrant: *cough* | 10:15 |
| wgrant | No, recipe. | 10:15 |
| cjwatson | thpppt | 10:15 |
| cjwatson | (last I checked we had no LP object called thpppt | 10:15 |
| cjwatson | ) | 10:15 |
| mwhudson | it doesn't help that the links in the recipe source don't work... | 10:15 |
| wgrant | Yeah. | 10:16 |
| wgrant | It's complicated. | 10:16 |
| wgrant | In this case it's unambiguous, but it's sometimes not. | 10:16 |
| mapreri | is it just me or staging.lp.net seems to run an older launchpad than production? r13390 < r17972 | 10:23 |
| cjwatson | mapreri: It's built from a different branch. | 10:24 |
| mwhudson | and now it seems the release tag and release tarball have different contents | 10:24 |
| cjwatson | db-devel rather than devel. | 10:24 |
| mwhudson | can't blame lp for that one :-) | 10:24 |
| cjwatson | db-devel r13390 is in fact newer than devel r17972. | 10:25 |
| mapreri | oh, I see the merge commits on db-devel | 10:26 |
| cjwatson | It's equivalent to devel r17979. | 10:26 |
| mapreri | I'm not sure if such numbering/versioning is a bzr weirdness or development model weirdness :) | 10:27 |
| mwhudson | although hm, where did it get that orig from... | 10:27 |
| cjwatson | mapreri: A little of both. | 10:27 |
| wgrant | mwhudson: e0b1199cc6302b267abf335042961b77aee12ff4refs/tags/upstream/1.4.3 | 10:28 |
| wgrant | I assume. | 10:28 |
| mwhudson | ok | 10:28 |
| wgrant | mapreri: https://dev.launchpad.net/Trunk has some terribly overcomplicated diagrams. | 10:28 |
| wgrant | Though not quite as spectacular as the original RFWTAD diagram. | 10:29 |
| mwhudson | oh, that suggests a much simpler idea... | 10:29 |
| mapreri | I had the impression edge.lp.net was gone? those graphs have it. | 10:30 |
| cjwatson | s/edge/qastaging/ for this purpose. | 10:31 |
| mapreri | ic | 10:31 |
| wgrant | (the difference being that edge was on the production DB, while qastaging is on its own copy. Better to QA probably broken code on sacrificial data!) | 10:32 |
| * mwhudson has a working git recipe finally | 10:38 | |
| mwhudson | wgrant, cjwatson: thanks for putting up with my dumb mistakes | 10:38 |
| cjwatson | np | 10:38 |
| wgrant | I'm happy to blame git weirdness :) | 10:40 |
| chrisr_ | cjwatson: ah, it finally worked, thanks a lot for your help! | 11:58 |
| cjwatson | Ah good | 11:59 |
| === xnox_ is now known as xnox | ||
| === cprov_ is now known as cprov | ||
| === psivaa_ is now known as psivaa | ||
| === zoktar_ is now known as zoktar | ||
| mohankumar_ | Team , is there anyway to export bug report from lanchpad ? | 14:26 |
| teward | 'export' a bug report how? | 14:27 |
| dobey | you can read all bug reports that you have access to read, with the lp API | 14:27 |
| teward | ^ that though | 14:27 |
| teward | was about to say the API may be of use | 14:27 |
| mohankumar_ | teward , to word doc or excel file (specific project bug report ) | 14:27 |
| teward | ah | 14:27 |
| teward | in that case, no, there's no direct export to a word doc or excel file; you could probably run a script to create a CSV based on API output, and then convert that to Excel yourself | 14:28 |
| cjwatson | https://help.launchpad.net/API/launchpadlib | 14:28 |
| teward | ^ | 14:28 |
| teward | but i don't think there's a built-in 'export' function like you're seeking | 14:28 |
| cjwatson | No, there isn't. | 14:29 |
| teward | yep | 14:29 |
| cjwatson | Nor will there be. | 14:29 |
| mohankumar_ | teward, cjwatson : thanks ! | 14:29 |
| mohankumar_ | teward , could you shed some light on " script to create a CSV based on API output" , any links ? | 14:30 |
| dobey | mohankumar_: you'd have to write the script | 14:31 |
| dobey | you could probably use python-launchpadlib and python-uno to generate a libreoffice spreadsheet though | 14:32 |
| teward | ^ | 14:32 |
| mohankumar_ | dobey , Oh , great ! | 14:32 |
| === dpm is now known as dpm-afk | ||
| === TRB143_ is now known as TRB143 | ||
| === dpm-afk is now known as dpm | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!