X-Original-To: alpine-infra@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id E5B7D5C59FC for ; Fri, 27 Oct 2017 16:13:06 +0000 (GMT) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id B4B8C9E3140; Fri, 27 Oct 2017 16:13:06 +0000 (GMT) Received: from ncopa-desktop.copa.dup.pw (15.63.200.37.customer.cdi.no [37.200.63.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id 3F8A29E0126; Fri, 27 Oct 2017 16:13:05 +0000 (GMT) Date: Fri, 27 Oct 2017 18:13:01 +0200 From: Natanael Copa To: Oliver Smith Cc: alpine-infra@lists.alpinelinux.org Subject: Re: Building unofficial packages on Alpine build infrastructure? Message-ID: <20171027181301.478d6385@ncopa-desktop.copa.dup.pw> In-Reply-To: <514355cb-b6f1-c220-99fc-b096dcb0b693@bitmessage.ch> References: <514355cb-b6f1-c220-99fc-b096dcb0b693@bitmessage.ch> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 24 Oct 2017 22:47:00 +0000 Oliver Smith wrote: > Dear Alpinists, >=20 >=20 > at least Timo Teras[1] and William Pitcock[2] have proposed, that the > Alpine package building infrastructure could be used for unofficial > Alpine packages, when "the new build infrastructure [is] in place". replacing the building infra is a big project. I don't know how much time it will take, and so far the progress have been slow. > So postmarketOS[3] is a thin layer on top of Alpine, that provides > packages to make it work on mobile devices. Currently every user is > compiling these from source, but we would be very grateful if we could > use Alpine's infrastructure for building binary packages. That way we > could focus more on actual development and giving back to Alpine (e.g. > together with Ad=E9lie, we're currently upstreaming KDE), instead of > duplicating the effort. >=20 > For reference, here[4] are our current aports. Especially the device > folder makes no sense to be upstreamed. We will not build packages that > contain closed source blobs (our firmware aports will be refactored to > download these files at installation time[5]). >=20 > Thoughts? I am glad to have you around I want help if we can. I have already have use for the apk string version compare implementation that you wrote in python. What are your exact needs? Build servers on what architecture(s)? Where do you want upload the built packages? Do you mind if we follow this up after the v3.7 release? Thanks! >=20 >=20 > Best regards, > Oliver Smith >=20 >=20 > [1]: Timo Teras: "This would allow several improvements: - would > simplify us supporting contributed ppa type aports trees our infra would > build" > [2]: William Pitcock: "Once we have the new build infrastructure in > place, I am sure that we could arrange for derivatives to make use of > it. But I will need to talk with the infra team before committing us to > that." > [3]: > [4]: > [5]: >=20 >=20