Re: [arch-general] [arch-dev-public] broken PKGDEST?
On Tue, Feb 14, 2012 at 02:10:50PM +0100, Tobias Powalowski wrote:
Hi, since quite some time, PKGDEST breaks testingpkg etc. It only can upload the arch package and not the other, eg. x64_64 is not able to upload the i686 package. Any ideas or fix for this? It really breaks my workflow.
I'm not sure what you want to do... Are you trying to release to a architecture that isn't specified in the PKGBUILD's "arch" array? Or does commitpkg fail to upload an architecture you actually specified? Just to be sure, commitpkg currently behaves as follows: 1. Iterates over all architectures that you specified in your PKGBUILD (unless you use "$commit_arch"). 2. Searches for package files for each of these architectures (and it looks in "$PKGDEST" if that is used). If it cannot find a package file for one architecture, it displays something like "Skipping $_pkgname-$fullver-$_arch: failed to locate package file" and skips that architecture. 3. Searches for signature files, bails out if one of them cannot be found or is invalid. 4. archreleases to all remaining architectures. 5. Uploads package and signature files. If it doesn't behave like that for you, you should probably file a devtools bug. If it behaves like that and you need another feature, file a feature request :)
greetings tpowa
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
I'm not sure what you want to do... Are you trying to release to a architecture that isn't specified in the PKGBUILD's "arch" array? Or does commitpkg fail to upload an architecture you actually specified?
Just to be sure, commitpkg currently behaves as follows:
1. Iterates over all architectures that you specified in your PKGBUILD (unless you use "$commit_arch").
2. Searches for package files for each of these architectures (and it looks in "$PKGDEST" if that is used). If it cannot find a package file for one architecture, it displays something like "Skipping $_pkgname-$fullver-$_arch: failed to locate package file" and skips that architecture.
3. Searches for signature files, bails out if one of them cannot be found or is invalid.
4. archreleases to all remaining architectures.
5. Uploads package and signature files.
If it doesn't behave like that for you, you should probably file a devtools bug. If it behaves like that and you need another feature, file a feature request :)
All worked fine till last devtools update I think. Everything is in the directory so there is no reason for testingpkg to bail out that the arch is not there. I had to call each chroot to get everything done, before it was just working from one chroot for both arches. This is imho a bug somewhere. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 02/14/2012 04:13 PM, Tobias Powalowski wrote:
I'm not sure what you want to do... Are you trying to release to a architecture that isn't specified in the PKGBUILD's "arch" array? Or does commitpkg fail to upload an architecture you actually specified?
Just to be sure, commitpkg currently behaves as follows:
1. Iterates over all architectures that you specified in your PKGBUILD (unless you use "$commit_arch").
2. Searches for package files for each of these architectures (and it looks in "$PKGDEST" if that is used). If it cannot find a package file for one architecture, it displays something like "Skipping $_pkgname-$fullver-$_arch: failed to locate package file" and skips that architecture.
3. Searches for signature files, bails out if one of them cannot be found or is invalid.
4. archreleases to all remaining architectures.
5. Uploads package and signature files.
If it doesn't behave like that for you, you should probably file a devtools bug. If it behaves like that and you need another feature, file a feature request :)
All worked fine till last devtools update I think. Everything is in the directory so there is no reason for testingpkg to bail out that the arch is not there. I had to call each chroot to get everything done, before it was just working from one chroot for both arches.
This is imho a bug somewhere. greetings tpowa
i don't quite understand your workflow. can you describe them in simple steps and point where is failing and how? -- Ionuț
i don't quite understand your workflow. can you describe them in simple steps and point where is failing and how?
- Build kernel for x86_86, - chroot into i686 build i686 kernel - leave chroot - testingpkg in trunk does only upload x86_64 and not both. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am 14.02.2012 15:58, schrieb Tobias Powalowski:
i don't quite understand your workflow. can you describe them in simple steps and point where is failing and how?
ok I think we come a bit closer, Problem is that both chroots use different PKGDEST, the devtools before didn't use PKGDEST and just checked for the symlinks which are working. Can we change that back, do I need to change my config? Thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Tue, Feb 14, 2012 at 04:05:52PM +0100, Tobias Powalowski wrote:
Am 14.02.2012 15:58, schrieb Tobias Powalowski:
i don't quite understand your workflow. can you describe them in simple steps and point where is failing and how?
ok I think we come a bit closer, Problem is that both chroots use different PKGDEST, the devtools before didn't use PKGDEST and just checked for the symlinks which are working. Can we change that back, do I need to change my config?
Well, changing that back would mean that we would probably have to drop "$PKGDEST" support and rely on the symlinks (or fall back to the current working directory if the package file cannot be found in "$PKGDEST" or something). Does makechrootpkg create these symlinks at all? I don't think so.
Thanks greetings tpowa
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am 14.02.2012 16:05, schrieb Tobias Powalowski:
Am 14.02.2012 15:58, schrieb Tobias Powalowski:
i don't quite understand your workflow. can you describe them in simple steps and point where is failing and how?
ok I think we come a bit closer, Problem is that both chroots use different PKGDEST,
That cannot be supported in a sane way. Why would you need that anyway?
the devtools before didn't use PKGDEST and just checked for the symlinks which are working. Can we change that back, do I need to change my config?
Why don't you just use the archbuild aliases (testing-x86_64-build etc.) for your packages? -- Pierre Schmitz, http://pierre-schmitz.com
On Tue, Feb 14, 2012 at 03:58:31PM +0100, Tobias Powalowski wrote:
i don't quite understand your workflow. can you describe them in simple steps and point where is failing and how?
- Build kernel for x86_86, - chroot into i686 build i686 kernel - leave chroot - testingpkg in trunk does only upload x86_64 and not both.
Are you sure, you put both package files into the right location (trunk or "$PKGDEST", if used)? Does commitpkg display the "Skipping [...]: failed to locate package file" warning? There were two changes since the last devtools release that might have caused that [1], [2]. We probably need more details to figure out what's going wrong here, though. [1] http://projects.archlinux.org/devtools.git/commit/?id=b763788b [2] http://projects.archlinux.org/devtools.git/commit/?id=06a681ca
Am 14.02.2012 16:07, schrieb Lukas Fleischer:
On Tue, Feb 14, 2012 at 03:58:31PM +0100, Tobias Powalowski wrote:
i don't quite understand your workflow. can you describe them in simple steps and point where is failing and how?
- Build kernel for x86_86, - chroot into i686 build i686 kernel - leave chroot - testingpkg in trunk does only upload x86_64 and not both. Are you sure, you put both package files into the right location (trunk or "$PKGDEST", if used)? Does commitpkg display the "Skipping [...]: failed to locate package file" warning?
There were two changes since the last devtools release that might have caused that [1], [2]. We probably need more details to figure out what's going wrong here, though.
[1] http://projects.archlinux.org/devtools.git/commit/?id=b763788b [2] http://projects.archlinux.org/devtools.git/commit/?id=06a681ca Definitly [1] causes this, because the symlinks would work but PKGDEST is for both chroots different.
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
participants (4)
-
Ionut Biru
-
Lukas Fleischer
-
Pierre Schmitz
-
Tobias Powalowski