Bug#645642: Please add armhf to architecture list

2011-10-18 Thread Loïc Minier
On Mon, Oct 17, 2011, Bdale Garbee wrote:
> It looks like I did that back in 1999 to get around some problem, and
> then over time people have let me know various other architectures work
> and so I've added them back in.  I think you're right, though, making it
> 'any' won't hurt at this point... if it doesn't build on all
> architectures, I may get some FTBFS bugs, but they won't be RC if the
> package never built on that architecture before...

 Makes sense; thanks!

-- 
Loïc Minier



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#645642: Please add armhf to architecture list

2011-10-17 Thread Bdale Garbee
On Mon, 17 Oct 2011 16:46:36 +0200, Loïc Minier  wrote:
> Package: yforth
> Version: 0.1beta-21
> Severity: wishlist
> 
>  I see yforth lists armel armeb and arm in control, would you please
>  also list armhf?

Sure.

>  Also, I checked Packages-arch-specific and it has:
> yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # 
> compiler
> 
>  while your control has:
> Architecture: alpha amd64 arm armeb armel hurd-i386 i386 kfreebsd-i386 
> kfreebsd-amd64 m68k powerpc ppc64 sparc
> 
>  what's puzzling is that you've listed 64-bits arches in control, but
>  debian/changelog says:
> yforth (0.1beta-10) frozen unstable; urgency=low
> 
>   * update control file to account for yforth not working on 64 bit machines.
> Instead of 'any', specify i386/m68k/sparc/arm.  I *think* all of those
> should work.  Update documentation to include my best contact info for.
> the upstream author, and acknowledge that there is no longer an upstream.
> site for this package.  Closes 32413.
> 
>  -- Bdale Garbee   Tue, 26 Jan 1999 09:18:24 -0700
> 
>  so maybe it's time to revert back to Architecture: any?

It looks like I did that back in 1999 to get around some problem, and
then over time people have let me know various other architectures work
and so I've added them back in.  I think you're right, though, making it
'any' won't hurt at this point... if it doesn't build on all
architectures, I may get some FTBFS bugs, but they won't be RC if the
package never built on that architecture before...

Bdale


pgpEiOtDeourG.pgp
Description: PGP signature


Bug#645642: Please add armhf to architecture list

2011-10-17 Thread Loïc Minier
Package: yforth
Version: 0.1beta-21
Severity: wishlist

Hi

 I see yforth lists armel armeb and arm in control, would you please
 also list armhf?  It should work just as well as armel, the only
 difference being floating point calling conventions, and that's hidden
 by GCC AFAICT.

 Also, I checked Packages-arch-specific and it has:
yforth: i386 m68k sparc arm armel powerpc kfreebsd-i386 kfreebsd-amd64 # 
compiler

 while your control has:
Architecture: alpha amd64 arm armeb armel hurd-i386 i386 kfreebsd-i386 
kfreebsd-amd64 m68k powerpc ppc64 sparc

 what's puzzling is that you've listed 64-bits arches in control, but
 debian/changelog says:
yforth (0.1beta-10) frozen unstable; urgency=low

  * update control file to account for yforth not working on 64 bit machines.
Instead of 'any', specify i386/m68k/sparc/arm.  I *think* all of those
should work.  Update documentation to include my best contact info for.
the upstream author, and acknowledge that there is no longer an upstream.
site for this package.  Closes 32413.

 -- Bdale Garbee   Tue, 26 Jan 1999 09:18:24 -0700

 so maybe it's time to revert back to Architecture: any?

   Thanks,
-- 
Loïc Minier



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org