<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 7, 2017 at 1:20 PM, Oliver Grawert <span dir="ltr"><<a href="mailto:ogra@ubuntu.com" target="_blank">ogra@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi,<br>
<span class="">On Di, 2017-02-07 at 16:07 +0000, Alan Pope wrote:<br>
> Hi,<br>
><br>
> Suppose I have a snap which requires a couple of non-archive debs as<br>
> stage packages. Typically I'd have a part for each which uses the<br>
> source: of a url directly to the deb using the dump plugin. This<br>
> works<br>
> fine building on my amd64 laptop (or wherever) and I end up with an<br>
> amd64 snap.<br>
><br>
> However, if I get a request for an i386 (or indeed armhf) snap, it<br>
> will break because my i386 snapcraft run will pull an amd64 deb. If I<br>
> was pulling archive packages then of course the build can run in<br>
> launchpad and it will do the Right Thing. However, if my yaml<br>
> contains<br>
> hard coded arch-specific (non-archive) debs, that breaks, pulling in<br>
> amd64 deb on an i386 builder.<br>
><br>
> I could have separate yamls per arch of course, but that seems<br>
> needlessly messy. What have others done in this case?<br>
><br>
</span>do you mean <a href="https://bugs.launchpad.net/snapcraft/+bug/1655797" rel="noreferrer" target="_blank">https://bugs.launchpad.<wbr>net/snapcraft/+bug/1655797</a> ?<br>
looks like is was just fixed last week though...<br>
not sure how/if that works for "non-archive debs" though<br></blockquote><div><br></div><div>This is somewhat different, the bugfix there was about bringing in other arches for current arch ;-) </div></div></div></div>