From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id ABE883858D35 for ; Sat, 7 Jan 2023 15:05:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ABE883858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from r6.localdomain (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 4073C30067D2; Sat, 7 Jan 2023 16:05:49 +0100 (CET) Received: by r6.localdomain (Postfix, from userid 1000) id ACA9134022F; Sat, 7 Jan 2023 16:05:48 +0100 (CET) Message-ID: <00dfa3cd4404ec84cb29c7040f3caf3e895f0a61.camel@klomp.org> Subject: Re: install mpfr-dev package on sourceware From: Mark Wielaard To: Overseers mailing list , "Frank Ch. Eigler" Cc: Joel Brobecker Date: Sat, 07 Jan 2023 16:05:48 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.2 (3.46.2-1.fc37) MIME-Version: 1.0 X-Spam-Status: No, score=-3032.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, On Sat, 2023-01-07 at 17:45 +0400, Joel Brobecker via Overseers wrote: > >=20 > > OTOH even running configure/make should not > > really be necessary: have y'all considered building the tarballs > > via "git archive" or such? >=20 > This is a good question. The current process is really aweful > and prone to breaking (all the time, actually). The problem > is that this process predates me, and I don't have information > on why it is what it is today. One of the reasons might be that > it allows pre-generating some files so users of the snapshot > don't have to. Yeah, various packages do want to generate some files for their dist tars. Same for elfutils and binutils. Also some documentation might need to be (re)generated. I am working on a sourceware snapshot/docs service using the sourceware buildbot so you can simply configure a container with the needed build/dist/doc dependencies. The snapshot process can then run inside that container (possibly on a separate snapshot build machine). Currently working on the binutils release script, which should automate a couple of steps which are now only done by hand at release time. It should make sure the release process doesn't accidentially break and you only notice at the time you are preparing an official release. Cheers, Mark