[pacman-dev] [PATCH] More verbose bzr branching error

[Alucryd]

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
> > <andrew.gregory.8 at gmail.com>wrote:
> > 
> >> On 04/07/13 at 07:39pm, Maxime GAUDUIN wrote:
> >>> On Sun, Apr 7, 2013 at 6:38 PM, Andrew Gregory
> >>> <andrew.gregory.8 at gmail.com>wrote:
> >>>
> >>>> On 04/07/13 at 11:51am, Maxime GAUDUIN wrote:
> >>>>> On Sun, Apr 7, 2013 at 11:24 AM, Allan McRae <allan at archlinux.org>
> >>>> wrote:
> >>>>>
> >>>>>> On 06/04/13 16:13, Allan McRae wrote:
> >>>>>>> On 05/04/13 18:33, Maxime Gauduin wrote:
> >>>>>>>> From: Alucryd <alucryd at gmail.com>
> >>>>>>>>
> >>>>>>>> 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