[pacman-dev] [PATCH] More verbose bzr branching error
From: Alucryd <alucryd@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. Signed-off-by: Maxime Gauduin <alucryd@gmail.com> --- scripts/makepkg.sh.in | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index da620a4..83900c5 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -473,6 +473,7 @@ download_bzr() { # Make sure we are fetching the right repo if [[ "$url" != "$(bzr config parent_location -d $dir)" ]] ; then error "$(gettext "%s is not a branch of %s")" "$dir" "$url" + error "$(gettext "The reported URL is %s")" "$(bzr config parent_location -d $dir)" plain "$(gettext "Aborting...")" exit 1 fi -- 1.8.2
On 05/04/13 18:33, Maxime Gauduin wrote:
From: Alucryd <alucryd@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.
Signed-off-by: Maxime Gauduin <alucryd@gmail.com> --- scripts/makepkg.sh.in | 1 + 1 file changed, 1 insertion(+)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index da620a4..83900c5 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -473,6 +473,7 @@ download_bzr() { # Make sure we are fetching the right repo if [[ "$url" != "$(bzr config parent_location -d $dir)" ]] ; then error "$(gettext "%s is not a branch of %s")" "$dir" "$url" + error "$(gettext "The reported URL is %s")" "$(bzr config parent_location -d $dir)" plain "$(gettext "Aborting...")" exit 1 fi
On 06/04/13 16:13, Allan McRae wrote:
On 05/04/13 18:33, Maxime Gauduin wrote:
From: Alucryd <alucryd@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
On Sun, Apr 7, 2013 at 11:24 AM, Allan McRae <allan@archlinux.org> wrote:
On 06/04/13 16:13, Allan McRae wrote:
On 05/04/13 18:33, Maxime Gauduin wrote:
From: Alucryd <alucryd@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
On 04/07/13 at 11:51am, Maxime GAUDUIN wrote:
On Sun, Apr 7, 2013 at 11:24 AM, Allan McRae <allan@archlinux.org> wrote:
On 06/04/13 16:13, Allan McRae wrote:
On 05/04/13 18:33, Maxime Gauduin wrote:
From: Alucryd <alucryd@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
On Sun, Apr 7, 2013 at 6:38 PM, Andrew Gregory <andrew.gregory.8@gmail.com>wrote:
On Sun, Apr 7, 2013 at 11:24 AM, Allan McRae <allan@archlinux.org> wrote:
On 06/04/13 16:13, Allan McRae wrote:
On 05/04/13 18:33, Maxime Gauduin wrote:
From: Alucryd <alucryd@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
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
On 04/07/13 at 07:39pm, Maxime GAUDUIN wrote:
On Sun, Apr 7, 2013 at 6:38 PM, Andrew Gregory <andrew.gregory.8@gmail.com>wrote:
On Sun, Apr 7, 2013 at 11:24 AM, Allan McRae <allan@archlinux.org> wrote:
On 06/04/13 16:13, Allan McRae wrote:
On 05/04/13 18:33, Maxime Gauduin wrote:
From: Alucryd <alucryd@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
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 Sun, Apr 7, 2013 at 8:02 PM, Andrew Gregory <andrew.gregory.8@gmail.com>wrote:
On Sun, Apr 7, 2013 at 6:38 PM, Andrew Gregory <andrew.gregory.8@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@archlinux.org> wrote:
On 06/04/13 16:13, Allan McRae wrote:
On 05/04/13 18:33, Maxime Gauduin wrote: > From: Alucryd <alucryd@gmail.com> > > 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! -- Maxime
On 08/04/13 07:00, Maxime GAUDUIN wrote:
On Sun, Apr 7, 2013 at 8:02 PM, Andrew Gregory <andrew.gregory.8@gmail.com>wrote:
On Sun, Apr 7, 2013 at 6:38 PM, Andrew Gregory <andrew.gregory.8@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@archlinux.org> wrote:
On 06/04/13 16:13, Allan McRae wrote: > On 05/04/13 18:33, Maxime Gauduin wrote: >> From: Alucryd <alucryd@gmail.com> >> >> 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 <andrew.gregory.8@gmail.com>wrote:
On Sun, Apr 7, 2013 at 6:38 PM, Andrew Gregory <andrew.gregory.8@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@archlinux.org> wrote:
> On 06/04/13 16:13, Allan McRae wrote: >> On 05/04/13 18:33, Maxime Gauduin wrote: >>> From: Alucryd <alucryd@gmail.com> >>> >>> 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
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
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@gmail.com>wrote:
On Sun, Apr 7, 2013 at 6:38 PM, Andrew Gregory <andrew.gregory.8@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@archlinux.org> wrote:
> On 06/04/13 16:13, Allan McRae wrote: >> On 05/04/13 18:33, Maxime Gauduin wrote: >>> From: Alucryd <alucryd@gmail.com> >>> >>> 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
participants (5)
-
Allan McRae
-
Alucryd
-
Andrew Gregory
-
Maxime GAUDUIN
-
Maxime Gauduin