On 06/04/13 16:13, Allan McRae wrote:

On 05/04/13 18:33, Maxime Gauduin wrote:

...

From: Alucryd

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

On 04/07/13 at 11:51am, Maxime GAUDUIN wrote:

On Sun, Apr 7, 2013 at 11:24 AM, Allan McRae wrote:

...

On 06/04/13 16:13, Allan McRae wrote:

...

On 05/04/13 18:33, Maxime Gauduin wrote:

...

From: Alucryd

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

On 04/07/13 at 07:39pm, Maxime GAUDUIN wrote:

On Sun, Apr 7, 2013 at 6:38 PM, Andrew Gregory wrote:

...

...

On Sun, Apr 7, 2013 at 11:24 AM, Allan McRae wrote:

...

On 06/04/13 16:13, Allan McRae wrote:

...

On 05/04/13 18:33, Maxime Gauduin wrote:

...

From: Alucryd

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

...

...

...

...

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

...

...

...

...

support, realize this may not be the best approach as it prevents

On 04/07/13 at 11:51am, Maxime GAUDUIN wrote: patch the bzr 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

On 08/04/13 07:00, Maxime GAUDUIN wrote:

On Sun, Apr 7, 2013 at 8:02 PM, Andrew Gregory wrote:

...

...

On Sun, Apr 7, 2013 at 6:38 PM, Andrew Gregory wrote:

...

On 04/07/13 at 11:51am, Maxime GAUDUIN wrote:

...

On Sun, Apr 7, 2013 at 11:24 AM, Allan McRae wrote:

...

On 06/04/13 16:13, Allan McRae wrote: > On 05/04/13 18:33, Maxime Gauduin wrote: >> From: Alucryd >> >> Currently, you can pull bzr repos using different URLs like "lp:" >> "http://" or "https://" in the source array. This works well

...

...

first

...

...

>> time, but when you want to build the package again and update

...

...

local

...

...

>> repo, makepkg will run 'bzr config parent_location' to check if

...

...

...

...

>> 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

...

...

people

...

...

>> from using the convenient "lp:" URLs, but for the time being

...

...

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

On 04/07/13 at 07:39pm, Maxime GAUDUIN wrote: the the the prevents people 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

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 wrote:

...

...

On Sun, Apr 7, 2013 at 6:38 PM, Andrew Gregory wrote:

...

On 04/07/13 at 11:51am, Maxime GAUDUIN wrote:

...

On Sun, Apr 7, 2013 at 11:24 AM, Allan McRae wrote:

> On 06/04/13 16:13, Allan McRae wrote: >> On 05/04/13 18:33, Maxime Gauduin wrote: >>> From: Alucryd >>> >>> Currently, you can pull bzr repos using different URLs like "lp:" >>> "http://" or "https://" in the source array. This works well

...

...

first

...

>>> time, but when you want to build the package again and update

...

...

local

...

>>> repo, makepkg will run 'bzr config parent_location' to check if

...

...

...

>>> 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

...

...

people

...

>>> from using the convenient "lp:" URLs, but for the time being

...

...

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

On 04/07/13 at 07:39pm, Maxime GAUDUIN wrote: the the the prevents people 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

Please disregard this patch BTW, I have included it in the second new patch. Cheers. -- Maxime