On Sun, Apr 7, 2013 at 8:02 PM, Andrew Gregory <[email protected]>wrote:
> On 04/07/13 at 07:39pm, Maxime GAUDUIN wrote: > > On Sun, Apr 7, 2013 at 6:38 PM, Andrew Gregory > > <[email protected]>wrote: > > > > > On 04/07/13 at 11:51am, Maxime GAUDUIN wrote: > > > > On Sun, Apr 7, 2013 at 11:24 AM, Allan McRae <[email protected]> > > > wrote: > > > > > > > > > On 06/04/13 16:13, Allan McRae wrote: > > > > > > On 05/04/13 18:33, Maxime Gauduin wrote: > > > > > >> From: Alucryd <[email protected]> > > > > > >> > > > > > >> Currently, you can pull bzr repos using different URLs like > "lp:" > > > > > >> "http://" or "https://" in the source array. This works well > the > > > first > > > > > >> time, but when you want to build the package again and update > the > > > local > > > > > >> repo, makepkg will run 'bzr config parent_location' to check if > the > > > > > >> local repo is the same as the distant one. Except the reported > URL > > > is > > > > > >> generally not the one used in the source array (which is valid > > > > > >> nonetheless) and will fail with a non helpful error message. > This > > > patch > > > > > >> makes makepkg print the correct reported URL so that it can be > > > manually > > > > > >> changed in the source array. I, and Gary van der Merwe who wrote > > > the bzr > > > > > >> support, realize this may not be the best approach as it > prevents > > > people > > > > > >> from using the convenient "lp:" URLs, but for the time being > people > > > will > > > > > >> stop wondering why their valid URLs are rejected. > > > > > >> > > > > > > > > > > > > So there is seriosuly no way to get to the original URL used by > bzr? > > > > > > That just seems... crap! This seems fine then. > > > > > > > > > > > > > > > > Can bzr people also take a look at this: > > > > > https://bugs.archlinux.org/task/34650 > > > > > > > > > > Allan > > > > > > > > > > > > > > > > > > > This is the issue I described above. I haven't found any way to > determine > > > > the URL used for pulling the distant repo yet, besides making makepkg > > > store > > > > it in a file to be read upon update. For now I have explained how to > get > > > > the correct URL on his bug report, I'll add a paragraph on this in > the > > > VCS > > > > guidelines wiki article later today. > > > > > > > > -- > > > > Maxime > > > > > > > > > > It may not be perfect, but bzr info can operate on a remote repo, so > > > could you run `bzr info` on the source url and compare the returned > > > branch root to parent_location? > > > > > > apg > > > > > > > > Can't test right now, but I don't think that's gonna help. What we want > is > > for the local repo to exhibit the URL it was downloaded from (http://, > > https://, lp:, ssh://), but 'bzr info' or 'bzr config parent_location' > > ouptuts the same http:// URL regardless. Running the command on the > distant > > repo will just print this URL. > > > > -- > > Maxime > > > > I'm saying that instead of looking for the original url we use bzr > info to resolve the source url and compare that to parent_location > instead. > > eg: > bzr info lp:qpdfview > gives us: > "branch root: http://bazaar.launchpad.net/~adamreichold/qpdfview/trunk/" > compare that to: > bzr config parent_location > which gives us: > http://bazaar.launchpad.net/~adamreichold/qpdfview/trunk/ > > apg > > Oh, I didn't think about it like this. This is a good idea indeed, I'll play around with makepkg tomorrow to test it out. All that would be left would be to make lp: URLs work. Thx! -- Maxime
