On Mon, 2013-04-08 at 08:16 +1000, Allan McRae wrote: > On 08/04/13 07:00, Maxime GAUDUIN wrote: > > 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! > > > > Umm... offline builds? > > Could try "brz info" and fall back if it fails. > > Allan > >
Offline builds indeed. I have sent 2 new patches to pacman-dev, one to add support for lp URLs, the other to implement the online check, and fallback to the current check for offline builds. Cheers. -- Maxime
