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.

greetings
tpowa

--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa@archlinux.org

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

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