From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4gYv7T0Ssnz2xXH for ; Mon, 08 Jun 2026 14:09:57 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4gYv7P5Y4cz2xLl for ; Mon, 08 Jun 2026 14:09:53 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4gYv7P1C1fz10R for ; Mon, 08 Jun 2026 14:09:53 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1780927793; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WyZbpD3sOEEDKD0c1Z4pcE1I7dtqHRcrkWcWpnT//R0=; b=J0MykC2VsszEzl56h6thv85kmp3fwdaTvnz52mnz+PhvS+b1bla94dxo+QMORX1e51Qn6W L1LYT/8B7DI53pBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1780927793; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WyZbpD3sOEEDKD0c1Z4pcE1I7dtqHRcrkWcWpnT//R0=; b=bCGh1MnVTaHPQCPuFnf9ozd+lHgtN5ONsu7a6Jjf/P0xJq9Kx8XR0b5sjOmCUKvaW5rvof QpccvJYmGS3+ZpGwa8b81PL4XONXDKvOGWP36ipjgktifh03qIVV5S8ZQ6Mxw49LBRRXtP mnCH/H70p5uWa0ExRQFCdKt09g4GgC4TjpFTacz5DSzBkOhdRm6aBgqxatzbxpwpRjRQ3H mham0k/TNvHGLUnzG7PJrmJqSz4jl/W/oS7v8UiXyLdkZ59nlLBYRxD57vuPdG1NLgZamI 5/m00ckQixz50gabUAg1QvkRtd+63iaQlaO+qihpiNcQ4gTfspuigZNb2up2uA== Message-ID: <0038d0e6-6ec4-42c4-9e5c-9ad4811c46f4@ipfire.org> Date: Mon, 8 Jun 2026 16:09:46 +0200 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Subject: Re: Unending item build To: development@lists.ipfire.org References: <530a1f74-957c-4c3f-a3ea-7c5c0962bbae@ipfire.org> <7FD296B9-B63A-401D-8972-38C03D3E9F06@ipfire.org> Content-Language: en-US From: Matthias Fischer In-Reply-To: <7FD296B9-B63A-401D-8972-38C03D3E9F06@ipfire.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08.06.2026 16:03, Michael Tremer wrote: > Hello Matthias, Hi Michael, >> On 8 Jun 2026, at 12:58, Matthias Fischer wrote: >> >> Hi all, >> >> I'd like to warm up an old problem...perhaps I found something like a >> solution. >> >> The original problem is rather old - it dates from 2025-01-15. It still >> can be found here: >> https://marc.info/?l=ipfire-development&m=173691503411708 >> >> Once in a while I experienced the same problem like Jon - building >> stopped suddenly: "./make.sh build goes into a loop and builds an item >> forever." And it doesn't matter which item. Either the counter kept >> running indefinitely, or it stopped displaying anything at all. >> >> That was pretty annoying. No errors, nothing in the logs. After stopping >> the build with CTRL-C and restarting the whole build, usually everything >> ran through and worked again as if nothing had happened. >> >> The last message often was just "make: Leaving directory '/usr/src/lfs'" >> and that was all. >> >> Lastly I was thinking it might have something to do with counters. >> So I changed "while sleep 1" to "while sleep 2" in 'make.sh'. Nothing more. >> >> Since then buildings are running without stopping anymore... >> >> Did anyone had similar problems? > > Very rarely. I think I have seen it before, but I cannot reproduce it at all. Yep. It happens just now and then, you never know when and why... > I am happy to remove the timer entirely because it would be sufficient to see the build time after the package has finished building. +1. You got my vote. The simpler, the better. > Would anyone be opposed to that? No. ;-) Best Matthias