[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: architecture limitation question



On Sun, Jul 11, 2010 at 09:51:38AM +0200, Goswin von Brederlow wrote:
> Samuel Thibault <sthibault@debian.org> writes:
> 
> > Hello,
> >
> > Harald Jenny, le Fri 09 Jul 2010 23:41:45 +0200, a écrit :
> >> I'm maintaining the amavisd-milter package and have a question: Due to the
> >> unavailability of libmilter-dev on HURD (it uses PATH_MAX which is not defined
> >> there) my package can't be built for this OS.

Hi Goswin

> 
> Can't you get the libmilter maintainer to fix that

I will mail him and ask if he has any plans but libmilter is built from
sendmail sources I don't know how difficult this may be.

> or NMU the package?

Well I'm no DD so I guess that NMU the package won't be very easy (if
possible at all)?

> This doesn't sound like fixing it is rocket science.

Hmmm at least this one not but I don't know what other problem may lurk in the
dark as I don't have a HURD system to test ;-).

> 
> > Then it's fine: amavisd-milter is in the BD-Uninstallable state, i.e.
> > doesn't consume any buildd cpu.
> >
> >> I thought about limiting the Architectures in debian/control on which
> >> amavisd-milter would run for now to linux-any, kfreebsd-any to work
> >> around the failure.
> >
> > It is useless and would just make people have to request for the
> > converse when libmilter-dev becomes available, while BD-Uninstallable
> > already tracks that appropriately.
> >
> >> Are there any other options for temporary limiting the architectures
> >> so that the build system needs not to use it's precious ressources for
> >> unsuccessful build attempts?
> >
> > The buildds are keeping up quite nice nowadays so unsuccessful build
> > attempts are fine.
> >
> > Samuel
> 
> And the BD-Uninstallable state means the package is not build anyway.

Ok

> 
> On the other hand limiting the architectures in debian/control has no
> effect at all for buildds (or wanna-build). The relevant file would be
> the Packages-Arch-Specific file. But adding a temporary entry there just
> means it must be removed again later. So better not.

Thanks for your comment on this.

For another package which I'm uploader (openswan) I face such an issue as it is
a linux-specific VPN package, for now I have added from Architecture: linux-any
lines in control file, but should I add this one to the relevant file?

> 
> MfG
>         Goswin

Thanks and kind regards
Harald


Reply to: