From MAILER-DAEMON Thu Sep 01 12:18:20 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oTmtY-0006U6-4o for mharc-reproduce-devel@gnu.org; Thu, 01 Sep 2022 12:18:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60030) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTmtW-0006So-5X for reproduce-devel@nongnu.org; Thu, 01 Sep 2022 12:18:18 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:44268) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTmtV-0000B6-TA for reproduce-devel@nongnu.org; Thu, 01 Sep 2022 12:18:17 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 9A7EC1207F0; Thu, 1 Sep 2022 12:18:17 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #62700] lzma/xz compilation bug for cmake in Maneage 27ff6f7 From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 62700 X-Apparently-From: Savane authenticated user boud Message-Id: <20220901-161817.sv54731.25337@savannah.nongnu.org> References: <20220703-173702.sv54731.33839@savannah.nongnu.org> <20220714-144031.sv54731.59289@savannah.nongnu.org> <20220715-144420.sv54731.44629@savannah.nongnu.org> <20220807-163932.sv97383.368@savannah.nongnu.org> <20220808-203822.sv54731.72283@savannah.nongnu.org> <20220808-203843.sv54731.71009@savannah.nongnu.org> In-Reply-To: <20220808-203843.sv54731.71009@savannah.nongnu.org> Date: Thu, 1 Sep 2022 12:18:17 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2022 16:18:18 -0000 Update of bug #62700 (project reproduce): Status: Fixed => In Progress _______________________________________________________ Follow-up Comment #5: Lasse Collin, the xz developer, proposed a much cleaner fix, on the Libera Chat irc channel #tukaani, as suggested at https://tukaani.org . I'm currently testing the fix. I've also reset the status to 'in progress', because Lasse said that the two library version numbers causing the problem are development versions, i.e. they shouldn't normally be used in any stable OS. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Thu Sep 01 15:55:45 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oTqHt-0004iy-UQ for mharc-reproduce-devel@gnu.org; Thu, 01 Sep 2022 15:55:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47230) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTqHd-0004ia-5l for reproduce-devel@nongnu.org; Thu, 01 Sep 2022 15:55:25 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:41440) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTqHb-0008G3-IA for reproduce-devel@nongnu.org; Thu, 01 Sep 2022 15:55:24 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 59669120814; Thu, 1 Sep 2022 15:55:18 -0400 (EDT) To: Jash Shah , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [sr #110710] GCC building failed on a CentOS based manylinux2014_x86_64 system From: Jash Shah X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: support X-Savane-Item-ID: 110710 X-Apparently-From: Savane authenticated user jash_shah Message-Id: <20220901-195515.sv302170.20158@savannah.nongnu.org> References: In-Reply-To: Date: Thu, 1 Sep 2022 15:55:18 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2022 19:55:26 -0000 URL: Summary: GCC building failed on a CentOS based manylinux2014_x86_64 system Project: Maneage Submitter: jash_shah Submitted: Thu 01 Sep 2022 07:55:15 PM UTC Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Follow-up Comments: ------------------------------------------------------- Date: Thu 01 Sep 2022 07:55:15 PM UTC By: Jash Shah I've been working on building a Python implementation of Gnuastro . This required me to use a manylinux2014_x86_64 based docker image, which uses CentOS 7. I chose gnuastro-in-maneage-static maneage project to build gnuastro statically, so that the Python package extension modules would only have to link to one shared lib, and thus only that one library(libgnuastro.so) is included in the Python distribution wheel. Look at auditwheel for more info. However while following the steps to Build only a software env in the docker the build failed with the following error while building GCC. I've included as much as my terminals max output allowed in the attached log file. Any help would be great! _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Thu 01 Sep 2022 07:55:15 PM UTC Name: gcc-failed.log Size: 72KiB By: jash_shah _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Thu Sep 01 17:23:12 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oTrea-0001zW-Ok for mharc-reproduce-devel@gnu.org; Thu, 01 Sep 2022 17:23:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35202) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTreY-0001z3-Qi for reproduce-devel@nongnu.org; Thu, 01 Sep 2022 17:23:10 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:41190) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTreY-0001VZ-Hy for reproduce-devel@nongnu.org; Thu, 01 Sep 2022 17:23:10 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 53C4F120814; Thu, 1 Sep 2022 17:23:10 -0400 (EDT) To: Jash Shah , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [sr #110710] GCC building failed on a CentOS based manylinux2014_x86_64 system From: Mohammad Akhlaghi X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: support X-Savane-Item-ID: 110710 X-Apparently-From: Savane authenticated user makhlaghi Message-Id: <20220901-222310.sv97383.75606@savannah.nongnu.org> References: <20220901-195515.sv302170.20158@savannah.nongnu.org> In-Reply-To: <20220901-195515.sv302170.20158@savannah.nongnu.org> Date: Thu, 1 Sep 2022 17:23:10 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2022 21:23:11 -0000 Follow-up Comment #1, sr #110710 (project reproduce): Thanks for sharing this problem Jash. Unfortunately the log file doesn't contain the actual error! It must have been caused by lines above the part you sent. Do you still have the terminal open? If not, can you post the name of the Docker image you used so I can try it? Until then, to get things going, you can use '--host-cc' (as the suggestion at the end of the log says). With this option, Maneage will not build GCC, and will use the host GCC and C++ Standard library for the high-level software. It shouldn't affect Gnuastro's library because Gnuastro (or its dependencies) don't link with the C++ library. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Fri Sep 02 13:56:30 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oUAu3-0006MD-2K for mharc-reproduce-devel@gnu.org; Fri, 02 Sep 2022 13:56:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60958) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oUAts-0006Km-VH for reproduce-devel@nongnu.org; Fri, 02 Sep 2022 13:56:20 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:59092) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oUAtp-0006G4-Nb for reproduce-devel@nongnu.org; Fri, 02 Sep 2022 13:56:16 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 4E8081205C5; Fri, 2 Sep 2022 13:56:12 -0400 (EDT) To: Mohammad Akhlaghi , Pedram Ashofteh Ardakani , reproduce-devel@nongnu.org Subject: [task #16246] Database authentication with Wget From: Mohammad Akhlaghi X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: task X-Savane-Item-ID: 16246 X-Apparently-From: Savane authenticated user makhlaghi Message-Id: <20220902-185612.sv97383.44404@savannah.nongnu.org> References: <20220825-161000.sv97383.76981@savannah.nongnu.org> <20220826-052821.sv188538.37391@savannah.nongnu.org> <20220826-155227.sv97383.95218@savannah.nongnu.org> <20220826-154632.sv188538.71639@savannah.nongnu.org> <20220826-183852.sv97383.98458@savannah.nongnu.org> <20220827-063908.sv188538.30904@savannah.nongnu.org> In-Reply-To: <20220827-063908.sv188538.30904@savannah.nongnu.org> Date: Fri, 2 Sep 2022 13:56:12 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2022 17:56:20 -0000 Update of task #16246 (project reproduce): Status: In Progress => Done Percent Complete: 70% => 100% Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #6: I am happy to say that the first implementation of this task has been completed and has been merged into the main Maneage branch as Commit 43186705 . If there are any problems or improvements, we should open other bugs or tasks. So I am closing this task. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Fri Sep 02 15:01:01 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oUBuX-0006xK-GQ for mharc-reproduce-devel@gnu.org; Fri, 02 Sep 2022 15:01:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55478) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oUBuW-0006xB-BR for reproduce-devel@nongnu.org; Fri, 02 Sep 2022 15:01:00 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:56274) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oUBuW-0002Cv-1v for reproduce-devel@nongnu.org; Fri, 02 Sep 2022 15:01:00 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 6D1F71205C5; Fri, 2 Sep 2022 15:00:59 -0400 (EDT) To: Jash Shah , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [sr #110710] GCC building failed on a CentOS based manylinux2014_x86_64 system From: Jash Shah X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: support X-Savane-Item-ID: 110710 X-Apparently-From: Savane authenticated user jash_shah Message-Id: <20220902-190059.sv302170.32106@savannah.nongnu.org> References: <20220901-195515.sv302170.20158@savannah.nongnu.org> <20220901-222310.sv97383.75606@savannah.nongnu.org> In-Reply-To: <20220901-222310.sv97383.75606@savannah.nongnu.org> Date: Fri, 2 Sep 2022 15:00:59 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2022 19:01:00 -0000 Follow-up Comment #2, sr #110710 (project reproduce): Thanks for the quick reply Mohammad! Yes, I did go with the --host-cc option, and the project was configured without any errors! I also moved forward with building the Python wheels, without modifying any dependencies or the _high-level.mk_ for now, and the wheel had very less amount of dependencies than before! Now, I'm trying by modifying the _high-level.mk_ file, where I move all the _.so_ files of the dependencies of Gnuastro out of the _/build/software/installed /lib_ directory, so that the libgnuastro.so file is built statically. == Reproduce the Problem == 1. Clone the https://gitlab.com/makhlaghi/gnuastro-in-maneage-static repo. 2. Have docker setup in your environment. 3. Follow the steps in https://gitlab.com/makhlaghi/gnuastro-in-maneage-static#only-software-environment-in-the-docker-image 4. Except in Step 3, change line 1 in Dockerfile to FROM quay.io/pypa/manylinux2014_x86_64:latest 5. The error appears after running step 10. I've also attached a longer .log file of the output of ./project configure. (file #53653) _______________________________________________________ Additional Item Attachment: File name: gcc-failed.log Size:1166 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Mon Sep 05 13:10:15 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oVFbx-00025L-Ps for mharc-reproduce-devel@gnu.org; Mon, 05 Sep 2022 13:10:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42952) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVFbw-00024w-OW for reproduce-devel@nongnu.org; Mon, 05 Sep 2022 13:10:12 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:58830) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVFbw-0008Hf-Eq for reproduce-devel@nongnu.org; Mon, 05 Sep 2022 13:10:12 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 1A3871204DC; Mon, 5 Sep 2022 13:10:11 -0400 (EDT) To: Mohammad Akhlaghi , Pedram Ashofteh Ardakani , reproduce-devel@nongnu.org Subject: [task #15825] Documentation in Texinfo From: Mohammad Akhlaghi X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: task X-Savane-Item-ID: 15825 X-Apparently-From: Savane authenticated user makhlaghi Message-Id: <20220905-181010.sv97383.20383@savannah.nongnu.org> References: <20201128-234440.sv97383.7456@savannah.nongnu.org> In-Reply-To: <20201128-234440.sv97383.7456@savannah.nongnu.org> Date: Mon, 5 Sep 2022 13:10:11 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2022 17:10:13 -0000 Update of task #15825 (project reproduce): Percent Complete: 0% => 10% _______________________________________________________ Follow-up Comment #1: Work on a full Texinfo documentation has started in the 'texibook' branch of the Maneage development repo . In particular, Commit 4fed6094 adds the skeleton Texinfo source (in 'reproduce/softare/doc/maneage.texi') and also adds its build rules in 'high-level.mk'. The build rules currently build the Info, PDF and HTML versions of the manual, making it easily accessible by running '.local/bin/info maneage' on the host operating system. The basic infrastructure is therefore in place and we can now start adding content. Once the first draft is complete, we can put the HTML and PDF versions on the Maneage webpage :-). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Fri Sep 09 14:25:58 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oWihS-0007c3-EO for mharc-reproduce-devel@gnu.org; Fri, 09 Sep 2022 14:25:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56650) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWihR-0007bd-A9 for reproduce-devel@nongnu.org; Fri, 09 Sep 2022 14:25:57 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:55550) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWihR-0007DR-1U for reproduce-devel@nongnu.org; Fri, 09 Sep 2022 14:25:57 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id B2E7E12011F; Fri, 9 Sep 2022 14:25:56 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #62700] lzma/xz compilation bug for cmake in Maneage 27ff6f7 From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 62700 X-Apparently-From: Savane authenticated user boud Message-Id: <20220909-182556.sv54731.65551@savannah.nongnu.org> References: <20220703-173702.sv54731.33839@savannah.nongnu.org> <20220714-144031.sv54731.59289@savannah.nongnu.org> <20220715-144420.sv54731.44629@savannah.nongnu.org> <20220807-163932.sv97383.368@savannah.nongnu.org> <20220808-203822.sv54731.72283@savannah.nongnu.org> <20220808-203843.sv54731.71009@savannah.nongnu.org> <20220901-161817.sv54731.25337@savannah.nongnu.org> In-Reply-To: <20220901-161817.sv54731.25337@savannah.nongnu.org> Date: Fri, 9 Sep 2022 14:25:56 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2022 18:25:57 -0000 Follow-up Comment #6, bug #62700 (project reproduce): While it is useful for xz to protect against the CentOS 7 mess, in principle, Maneage should not have detected the error, since we build both _xz_ and _cmake_. However, commit 2a3304cfb of Maneage from Dec 2018 by Mohammad [1] changes from - ./bootstrap --prefix=$(idir) && make && make install && \ to + ./bootstrap --prefix=$(idir) --system-curl --system-zlib \ + --system-bzip2 --system-liblzma && \ in the _high-level.mk_ rule for building _cmake_. This makes _cmake_ dependent on the host system, and helped to detect the _xz_ problem on CentOS 7. However, detecting bugs is not our primary aim :). Is there any good reason for building _cmake_ on the host system _curl_, _zlib_, _bzip2_, and _liblzma_? If not, then I propose to remove all four of these _--system-X_ options from the _cmake_ build rule. [1] http://git.maneage.org/project.git/commit/?id=2a3304cfb832d2f9548bb869f5a44a3412a1c3f9 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sat Sep 10 08:55:36 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oX01I-0003pM-O5 for mharc-reproduce-devel@gnu.org; Sat, 10 Sep 2022 08:55:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56246) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oX01H-0003p6-2t for reproduce-devel@nongnu.org; Sat, 10 Sep 2022 08:55:35 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:39950) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oX01G-0001jB-MN for reproduce-devel@nongnu.org; Sat, 10 Sep 2022 08:55:34 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id CEB451204E9; Sat, 10 Sep 2022 08:55:29 -0400 (EDT) To: Boud Roukema , reproduce-devel@nongnu.org Subject: [bug #63043] cmake build rule uses host liblzma.so and other host libraries From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63043 X-Apparently-From: Savane authenticated user boud Message-Id: <20220910-125528.sv54731.72522@savannah.nongnu.org> References: In-Reply-To: Date: Sat, 10 Sep 2022 08:55:29 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2022 12:55:35 -0000 URL: Summary: cmake build rule uses host liblzma.so and other host libraries Project: Maneage Submitter: boud Submitted: Sat 10 Sep 2022 12:55:27 PM UTC Category: Software Severity: 4 - Important Item Group: Output not reasonable Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any _______________________________________________________ Follow-up Comments: ------------------------------------------------------- Date: Sat 10 Sep 2022 12:55:27 PM UTC By: Boud Roukema DESCRIPTION: Maneage commit f459fc2 [1] (same as core maneage 4318670, but with the xz hack reverted), configured on CentOS 7, has a fatal error when compiling cmake, as explained in bug 62700 [0]. This is because the cmake build rule in _high-level.mk_ says ./bootstrap --prefix=$(idir) --system-curl --system-zlib \ --system-bzip2 --system-liblzma && \ which (presumably) means that "system" libraries should be used, not cmake's own versions. This was inserted in commit 2a3304cfb of Maneage in Dec 2018 by Mohammad. The motivation is (most likely) to avoid cmake's choice of libraries, and instead use Maneage's versions. However, cmake's bootstrap and configure system chooses, in some cases, host system versions of these libraries instead of the Maneage versions. This is a bug in our build of cmake on *any* OS, since we have all four of curl, zlib, bzip2, and liblzma built earlier in the configure pipeline. We should not use host libraries that we already have prepared within Maneage. Bug 62700 is only one example of this cmake build bug having bad consequences; other examples may have occurred undetected, and future examples can be expected. REPRODUCE THE BUG: To see the error, build commit f459fc2 [1] from scratch. Do _grep /usr/lib64/liblzma\.so_ on the log of the build, where _/usr/lib64/liblzma\.so*_ is your host system location of _liblzma.so_ . You should see something like /BUILD/build/software/installed/bin/g++ -liconv -O3 -DNDEBUG -Wl,-rpath-link=/BUILD/build/software/installed/lib -L/BUILD/build/software/installed/lib CMakeFiles/ctresalloc.dir/CTestResourceAllocation/ctresalloc.cxx.o -o ../../bin/ctresalloc ../../Source/libCTestLib.a ../../Source/libCMakeLib.a ../../Source/kwsys/libcmsys.a ../../Utilities/std/libcmstd.a ../../Utilities/cmexpat/libcmexpat.a ../../Utilities/cmlibarchive/libarchive/libcmlibarchive.a /usr/lib64/libz.so /usr/lib64/liblzma.so ../../Utilities/cmzstd/libcmzstd.a /usr/lib64/libbz2.so ../../Utilities/cmjsoncpp/libcmjsoncpp.a ../../Utilities/cmlibuv/libcmlibuv.a -ldl -lrt ../../Utilities/cmlibrhash/libcmlibrhash.a -lpthread /BUILD/build/software/installed/lib/libcurl.so This particular line shows that host-system liblzma.so and libbz2.so were linked, though Maneage libcurl.so was linked. In general, this bug is likely to lead to random behaviour. FAILED HACKS: Commit 213eddd [2] tries adding LDFLAGS and CFLAGS to the cmake rule to try to force usage of Maneage libraries. Commit fa98e74e [3] tries adding LDFLAGS alone to the cmake rule to try to force usage of Maneage libraries. Both these commits fail: they still show linking to _/usr/lib64/liblzma.so_ in the cmake build. My guess is that some sort of usage of LDFLAGS and CFLAGS should be able to work, keeping in mind that Darwin/xnu apparently has a problem if both C_INCLUDE_FLAGS and CPPFLAGS include the same directory. The question is where to insert these into the _cmake_ build structure. URLS: [0] https://savannah.nongnu.org/bugs/?62700 [1] https://codeberg.org/boud/maneage_dev/commit/f459fc2199f1a2b74702efa7e8d239c276e2ed97 (core Maneage without the xz hack) [2] https://codeberg.org/boud/maneage_dev/commit/213eddd9cc456a2a5c272ccf2080dd6027fbd070 (LDFLAGS and CFLAGS) [3] https://codeberg.org/boud/maneage_dev/commit/fa98e74e2313026198125566c57b20ad9cbb53a5 (LDFLAGS) _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sat Sep 10 13:47:25 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oX4Zh-0000u3-6b for mharc-reproduce-devel@gnu.org; Sat, 10 Sep 2022 13:47:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52058) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oX4Zg-0000qE-5Z for reproduce-devel@nongnu.org; Sat, 10 Sep 2022 13:47:24 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:48418) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oX4Zf-0000ZQ-OM for reproduce-devel@nongnu.org; Sat, 10 Sep 2022 13:47:23 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 52BBE1204E9; Sat, 10 Sep 2022 13:47:23 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #62700] lzma/xz compilation bug for cmake in Maneage 27ff6f7 From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 62700 X-Apparently-From: Savane authenticated user boud Message-Id: <20220910-174723.sv54731.20287@savannah.nongnu.org> References: <20220703-173702.sv54731.33839@savannah.nongnu.org> <20220714-144031.sv54731.59289@savannah.nongnu.org> <20220715-144420.sv54731.44629@savannah.nongnu.org> <20220807-163932.sv97383.368@savannah.nongnu.org> <20220808-203822.sv54731.72283@savannah.nongnu.org> <20220808-203843.sv54731.71009@savannah.nongnu.org> <20220901-161817.sv54731.25337@savannah.nongnu.org> <20220909-182556.sv54731.65551@savannah.nongnu.org> In-Reply-To: <20220909-182556.sv54731.65551@savannah.nongnu.org> Date: Sat, 10 Sep 2022 13:47:23 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2022 17:47:24 -0000 Update of bug #62700 (project reproduce): Status: In Progress => Postponed _______________________________________________________ Follow-up Comment #7: There are effectively two different bugs: * CentOS/xz bug #62700 (let's continue here) - the problem of RHEL developers using XZ library symbols in a way that they shouldn't have; * cmake build bug #63043 [1] - this is the build problem of cmake linking to a mix of host and Maneage libraries, that may sometimes cause fatal errors, at other times cause undetected errors, and in other cases have no effect. PROPOSAL: (a) revert the xz hack - i.e. merge f459fc2 [2] into core Maneage; and (b) wait for upstream xz to release e.g. xz-5.2.7, and then update to that in core Maneage after verification. The reason for (a) is that the easyfinder hack is not a seriously thought out and tested solution, so it's better to have configure failures on some systems like CentOS 7 for a short time rather than let a bad solution propagate further. I think that the time scale for 5.2.7 is likely to be short, since Lasse Collins wants to avoid the CentOS 7 problem from propagating further (people might write software that is dependent on the wrong library symbols). Draft fixes can be seen on the xz experimental git branch [3], such as commit 913ddc55 'liblzma: Vaccinate against an ill patch from RHEL/CentOS 7.' [1] https://savannah.nongnu.org/bugs/index.php?63043 [2] https://codeberg.org/boud/maneage_dev/commit/f459fc2199f1a2b74702efa7e8d239c276e2ed97 [3] xz git history _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sat Sep 10 15:36:09 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oX6Gv-000599-Iy for mharc-reproduce-devel@gnu.org; Sat, 10 Sep 2022 15:36:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53814) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oX6Gt-000591-OA for reproduce-devel@nongnu.org; Sat, 10 Sep 2022 15:36:07 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:54792) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oX6Gt-0006UV-8o for reproduce-devel@nongnu.org; Sat, 10 Sep 2022 15:36:07 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 494AA1204E9; Sat, 10 Sep 2022 15:36:06 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63043] cmake build rule uses host liblzma.so and other host libraries From: Mohammad Akhlaghi X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63043 X-Apparently-From: Savane authenticated user makhlaghi Message-Id: <20220910-203606.sv97383.16786@savannah.nongnu.org> References: <20220910-125528.sv54731.72522@savannah.nongnu.org> In-Reply-To: <20220910-125528.sv54731.72522@savannah.nongnu.org> Date: Sat, 10 Sep 2022 15:36:06 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2022 19:36:07 -0000 Follow-up Comment #1, bug #63043 (project reproduce): I'll look into the build logs of CMake next time I build Maneage. But a good way to check the linking status of a program or shared library is to use 'ldd' (on GNU/Linux systems). When I run it on my current build of Maneage I get the output shown in the P.S. As you see there, except for the C library and Linux kernel, all the other libraries it links to are in Maneage. Have you tried this on the problematic system? P.S. $ ldd .local/bin/cmake libiconv.so.2 => /BDIR/software/installed/lib/libiconv.so.2 (0x00007ff6fda9c000) libz.so.1 => /BDIR/software/installed/lib/libz.so.1 (0x00007ff6fda7f000) liblzma.so.5 => /BDIR/software/installed/lib/liblzma.so.5 (0x00007ff6fcfd8000) libbz2.so.1.0 => /BDIR/software/installed/lib/libbz2.so.1.0 (0x00007ff6fcf9d000) libcurl.so.4 => /BDIR/software/installed/lib/libcurl.so.4 (0x00007ff6fcf0f000) libstdc++.so.6 => /BDIR/software/installed/lib/libstdc++.so.6 (0x00007ff6fcc00000) libgcc_s.so.1 => /BDIR/software/installed/lib/libgcc_s.so.1 (0x00007ff6fceee000) libssl.so.3 => /BDIR/software/installed/lib/libssl.so.3 (0x00007ff6fc880000) libcrypto.so.3 => /BDIR/software/installed/lib/libcrypto.so.3 (0x00007ff6fc200000) libc.so.6 => /usr/lib/libc.so.6 (0x00007ff6fc931000) libm.so.6 => /usr/lib/libm.so.6 (0x00007ff6fcb18000) libmd.so.0 => /usr/lib/libmd.so.0 (0x00007ff6fda72000) linux-vdso.so.1 => linux-vdso.so.1 (0x00007fff41ec7000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff6fdb85000) _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sat Sep 10 19:05:18 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oX9XK-00088R-E2 for mharc-reproduce-devel@gnu.org; Sat, 10 Sep 2022 19:05:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58698) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oX9XG-00086e-1A for reproduce-devel@nongnu.org; Sat, 10 Sep 2022 19:05:14 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:40628) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oX9XE-0000zh-Op for reproduce-devel@nongnu.org; Sat, 10 Sep 2022 19:05:12 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id B12851204E9; Sat, 10 Sep 2022 19:05:11 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63043] cmake build rule uses host liblzma.so and other host libraries From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63043 X-Apparently-From: Savane authenticated user boud Message-Id: <20220910-230511.sv54731.34817@savannah.nongnu.org> References: <20220910-125528.sv54731.72522@savannah.nongnu.org> <20220910-203606.sv97383.16786@savannah.nongnu.org> In-Reply-To: <20220910-203606.sv97383.16786@savannah.nongnu.org> Date: Sat, 10 Sep 2022 19:05:11 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2022 23:05:14 -0000 Follow-up Comment #2, bug #63043 (project reproduce): Compilation of 'cmake' fails on CentOS 7, so _ldd .local/bin/cmake_ gives _No such file or directory_ . :P On Debian 11.3, _ldd .local/bin/cmake_ shows that the Maneage libraries for curl, liblzma, bz2, have been linked. So the risk might be lower than I stated earlier: if linking succeeds, then on at least two systems, the Maneage libraries *are* linked, not the host ones. Hypothesis: with the current build rules, both the host system and Maneage libraries are examined, and, if both are valid, a decision is then made to use the Maneage libraries (probably because they're listed first). However, if one is invalid (missing symbols), then there's a fatal error. On Debian 11.3, the log includes lines like /BUILD/software/installed/bin/g++ -liconv -O3 -DNDEBUG -Wl,-rpath-link=/BUILD/software/installed/lib -L/BUILD/software/installed/lib CMakeFiles/testAffinity.dir/testAffinity.cxx.o -o testAffinity ../../Source/libCMakeLib.a ../../Source/kwsys/libcmsys.a ../../Utilities/std/libcmstd.a ../../Utilities/cmexpat/libcmexpat.a ../../Utilities/cmlibarchive/libarchive/libcmlibarchive.a /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/liblzma.so ../../Utilities/cmzstd/libcmzstd.a /BUILD/software/installed/lib/libbz2.so /BUILD/software/installed/lib/libcurl.so ../../Utilities/cmjsoncpp/libcmjsoncpp.a ../../Utilities/cmlibuv/libcmlibuv.a -ldl -lrt ../../Utilities/cmlibrhash/libcmlibrhash.a -lpthread The option '-L/BUILD/software/installed/lib' is given before '/usr/lib/x86_64-linux-gnu/liblzma.so', and 'g++' may work with several iterations - first check for consistency, and later make a final decision. In any case, it should be possible to find build rules for cmake where '/usr/lib/x86_64-linux-gnu/liblzma.so' is absent or becomes '/BUILD/software/installed/lib/liblzma.so'; that would give valid command lines for the compile instructions. The error appears to come from something like a 'configure' command earlier, but 'cmake' doesn't use a standard 'configure' file, just './bootstrap', so it's not clear where the problem happens; there are several lines like this: checking for -Wl,--no-as-needed... -- Looking for lzma_lzma_preset in /usr/lib/x86_64-linux-gnu/liblzma.so - found -- Found LibLZMA: /usr/lib/x86_64-linux-gnu/liblzma.so (found version "5.2.5") I'm just guessing: I'm not an expert on g++ compilation algorithms or the cmake build algorithm. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sun Sep 11 11:27:04 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oXOrP-0000Mc-2F for mharc-reproduce-devel@gnu.org; Sun, 11 Sep 2022 11:27:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58588) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oXOrM-0000LM-FR for reproduce-devel@nongnu.org; Sun, 11 Sep 2022 11:27:01 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:59202) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oXOrM-0004XP-4I for reproduce-devel@nongnu.org; Sun, 11 Sep 2022 11:27:00 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 6B6601206B6; Sun, 11 Sep 2022 11:26:58 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63043] cmake build rule uses host liblzma.so and other host libraries From: Mohammad Akhlaghi X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63043 X-Apparently-From: Savane authenticated user makhlaghi Message-Id: <20220911-162658.sv97383.70224@savannah.nongnu.org> References: <20220910-125528.sv54731.72522@savannah.nongnu.org> <20220910-203606.sv97383.16786@savannah.nongnu.org> <20220910-230511.sv54731.34817@savannah.nongnu.org> In-Reply-To: <20220910-230511.sv54731.34817@savannah.nongnu.org> Date: Sun, 11 Sep 2022 11:26:58 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2022 15:27:01 -0000 Follow-up Comment #3, bug #63043 (project reproduce): I had a look in my build logs for CMake (it has always been bothering us in Maneage from the day it was inserted! Anytime someone asks me what is the worst software you have confronted, I always immediately say CMake! It doesn't even need thinking! But any way, let's get to the main point...). When I searched for `liblzma.so`, it only shows my host's '/usr/lib/liblzma.so'! In fact, this happens for almost the libraries that it links against! The only one that it uses Maneage's own build is 'libcurl.so'! However, when I was searching Maneage's installed library in the logs, I noticed something interesting: besides 'libcurl', it only occurs in the RPATH command ('-Wl,-rpath-link=/BDIR/software/installed/lib'). So it actually links with my operating system's 'liblzma.so', 'libz.so' and etc, but it only put's Maneage's library location in RPATH! Therefore, the reason I don't get a crash is that my operating system's liblzma.so and libz.so and etc are compatible with Maneage's. This leak had indeed passed through our fingers and we had missed it! This is just bad design on CMake's side! _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sun Sep 11 16:54:39 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oXTyR-00041f-Kf for mharc-reproduce-devel@gnu.org; Sun, 11 Sep 2022 16:54:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36008) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oXTyP-00041O-FK for reproduce-devel@nongnu.org; Sun, 11 Sep 2022 16:54:37 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:37628) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oXTyP-0006wx-5p for reproduce-devel@nongnu.org; Sun, 11 Sep 2022 16:54:37 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id E204D1206BD; Sun, 11 Sep 2022 16:54:36 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63043] cmake build rule uses host liblzma.so and other host libraries From: Mohammad Akhlaghi X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63043 X-Apparently-From: Savane authenticated user makhlaghi Message-Id: <20220911-215436.sv97383.57804@savannah.nongnu.org> References: <20220910-125528.sv54731.72522@savannah.nongnu.org> <20220910-203606.sv97383.16786@savannah.nongnu.org> <20220910-230511.sv54731.34817@savannah.nongnu.org> <20220911-162658.sv97383.70224@savannah.nongnu.org> In-Reply-To: <20220911-162658.sv97383.70224@savannah.nongnu.org> Date: Sun, 11 Sep 2022 16:54:36 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2022 20:54:37 -0000 Follow-up Comment #4, bug #63043 (project reproduce): I just tried building CMake by removing all those '--system-*' options, and instead completely disabled any system libs by adding '--no-system-libs' instead. In the build commands, I noticed that the build commands contain '-DLZMA_API_STATIC' option, and in the end, and in the full log, I couldn't find any '/usr/lib/*.so' in any of the linking commands! In the end, I could also confirm that it had done a static build to its internal libz, liblzma, libcurl and libbz2 (its not in the libraries it now links to, see the P.S.). Can you try this on your CentOS 7? P.S. List of libraries that CMake links with when it is built with '--no-system-libs': $ ldd .local/bin/cmake libgcc_s.so.1 => /BDIR/software/installed/lib/libgcc_s.so.1 (0x00007f5fa675f000) libiconv.so.2 => /BDIR/software/installed/lib/libiconv.so.2 (0x00007f5fa6919000) libssl.so.3 => /BDIR/software/installed/lib/libssl.so.3 (0x00007f5fa6868000) libcrypto.so.3 => /BDIR/software/installed/lib/libcrypto.so.3 (0x00007f5fa6200000) libstdc++.so.6 => /BDIR/software/installed/lib/libstdc++.so.6 (0x00007f5fa5e00000) libz.so.1 => /BDIR/software/installed/lib/libz.so.1 (0x00007f5fa6742000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f5fa6780000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f5fa5c19000) linux-vdso.so.1 (0x00007ffdc496b000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f5fa7576000) _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sun Sep 11 16:59:10 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oXU2n-0004y0-VJ for mharc-reproduce-devel@gnu.org; Sun, 11 Sep 2022 16:59:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34798) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oXU2k-0004wg-V1 for reproduce-devel@nongnu.org; Sun, 11 Sep 2022 16:59:06 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:36070) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oXU2k-0007XN-MS for reproduce-devel@nongnu.org; Sun, 11 Sep 2022 16:59:06 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 604391206CB; Sun, 11 Sep 2022 16:59:06 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63043] cmake build rule uses host liblzma.so and other host libraries From: Mohammad Akhlaghi X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63043 X-Apparently-From: Savane authenticated user makhlaghi Message-Id: <20220911-215906.sv97383.85514@savannah.nongnu.org> References: <20220910-125528.sv54731.72522@savannah.nongnu.org> <20220910-203606.sv97383.16786@savannah.nongnu.org> <20220910-230511.sv54731.34817@savannah.nongnu.org> <20220911-162658.sv97383.70224@savannah.nongnu.org> <20220911-215436.sv97383.57804@savannah.nongnu.org> In-Reply-To: <20220911-215436.sv97383.57804@savannah.nongnu.org> Date: Sun, 11 Sep 2022 16:59:06 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2022 20:59:07 -0000 Follow-up Comment #5, bug #63043 (project reproduce): As you mentioned, one of the reasons that I had initially added the '--system-*' options was to be sure about the versions of these libraries in the final reporting of the used software by CMake. But since CMake's design is problematic if the change suggested before fixes teh problem, we can go ahead with this (letting CMake use its internal versions), and simply say something this in the LaTeX target: "CMake $(cmake-version) (with internal libraries distributed in tarball)". _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Tue Sep 13 04:43:32 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oY1W0-0007iA-Du for mharc-reproduce-devel@gnu.org; Tue, 13 Sep 2022 04:43:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48744) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oY1Vx-0007h1-Rw for reproduce-devel@nongnu.org; Tue, 13 Sep 2022 04:43:29 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:35014) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oY1Vx-0005kb-Jc for reproduce-devel@nongnu.org; Tue, 13 Sep 2022 04:43:29 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 1E20012072B; Tue, 13 Sep 2022 04:43:29 -0400 (EDT) To: Raul Infante-Sainz , reproduce-devel@nongnu.org Subject: [bug #63054] Pyerfa crash, setting setuptools_scm as a prerequisite of pyerfa From: Raul Infante-Sainz X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63054 X-Apparently-From: Savane authenticated user infantesainz Message-Id: <20220913-084328.sv138654.63814@savannah.nongnu.org> References: In-Reply-To: Date: Tue, 13 Sep 2022 04:43:29 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2022 08:43:30 -0000 URL: Summary: Pyerfa crash, setting setuptools_scm as a prerequisite of pyerfa Project: Maneage Submitter: infantesainz Submitted: Tue 13 Sep 2022 08:43:28 AM UTC Category: Software Severity: 3 - Normal Item Group: Crash Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any _______________________________________________________ Follow-up Comments: ------------------------------------------------------- Date: Tue 13 Sep 2022 08:43:28 AM UTC By: Raul Infante-Sainz Until now, 'setuptools_scm' was not a prerequisite of 'pyerfa'. It is strange that we didn't notice this until now because 'pyerfa' is also a requisite of 'astropy'. In any case, I faced an installation crash after updating the Maneage branch of one project and I found this issue. With the commit below, 'setuptools_scm' has been set as a prerequisite of 'pyerfa'. Now the installation of 'pyerfa' is done without any problem. Check it and merge if you consider that everything is good. https://gitlab.com/maneage/project-dev/-/commit/1333c1b1 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Tue Sep 13 06:50:30 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oY3Us-0006Dc-P1 for mharc-reproduce-devel@gnu.org; Tue, 13 Sep 2022 06:50:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42272) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oY3Uq-0006Cf-Ex for reproduce-devel@nongnu.org; Tue, 13 Sep 2022 06:50:28 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:45866) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oY3Uq-00019F-2I for reproduce-devel@nongnu.org; Tue, 13 Sep 2022 06:50:28 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id C657E1206D5; Tue, 13 Sep 2022 06:50:27 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [task #15942] Removing Metastore from Maneage From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: task X-Savane-Item-ID: 15942 X-Apparently-From: Savane authenticated user boud Message-Id: <20220913-105027.sv54731.9324@savannah.nongnu.org> References: <20210411-145014.sv97383.34705@savannah.nongnu.org> <20210411-152314.sv54731.14500@savannah.nongnu.org> <20210411-164916.sv97383.92849@savannah.nongnu.org> <20210411-190431.sv54731.70253@savannah.nongnu.org> <20210411-202837.sv97383.25236@savannah.nongnu.org> <20210411-213641.sv54731.50960@savannah.nongnu.org> In-Reply-To: <20210411-213641.sv54731.50960@savannah.nongnu.org> Date: Tue, 13 Sep 2022 06:50:27 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2022 10:50:28 -0000 Update of task #15942 (project reproduce): Depends on: => task #15363 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Tue Sep 13 07:06:01 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oY3jo-0000Nh-Lx for mharc-reproduce-devel@gnu.org; Tue, 13 Sep 2022 07:06:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39594) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oY3je-0000Kw-8l for reproduce-devel@nongnu.org; Tue, 13 Sep 2022 07:05:46 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:49176) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oY3jd-0003ZT-Sp for reproduce-devel@nongnu.org; Tue, 13 Sep 2022 07:05:45 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 49D6F1206D5; Tue, 13 Sep 2022 07:05:45 -0400 (EDT) To: Boud Roukema , reproduce-devel@nongnu.org Subject: [bug #61846] Try to disable nullability-completeness for flock.c for Darwin From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 61846 X-Apparently-From: Savane authenticated user boud Message-Id: <20220913-110545.sv54731.19785@savannah.nongnu.org> References: <20220118-114455.sv54731.63708@savannah.nongnu.org> In-Reply-To: <20220118-114455.sv54731.63708@savannah.nongnu.org> Date: Tue, 13 Sep 2022 07:05:45 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2022 11:05:47 -0000 Update of bug #61846 (project reproduce): Status: None => Fixed Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #1: Since flock has been updated to 0.4.0 [1] and this appears to be stable, it seems to me that this bug can be safely closed. Since I was the person who posted it, I'm closing it. If there is a reason to re-open it, please say why and then re-open it. [1] http://git.maneage.org/project.git/tree/reproduce/software/config/versions.conf#n29 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Tue Sep 13 17:40:11 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oYDdb-0006co-8O for mharc-reproduce-devel@gnu.org; Tue, 13 Sep 2022 17:40:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44024) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYDdZ-0006bl-3R for reproduce-devel@nongnu.org; Tue, 13 Sep 2022 17:40:09 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:57224) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYDdY-00054B-Rn for reproduce-devel@nongnu.org; Tue, 13 Sep 2022 17:40:08 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 955531205A4; Tue, 13 Sep 2022 17:40:08 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63043] cmake build rule uses host liblzma.so and other host libraries From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63043 X-Apparently-From: Savane authenticated user boud Message-Id: <20220913-214008.sv54731.71137@savannah.nongnu.org> References: <20220910-125528.sv54731.72522@savannah.nongnu.org> <20220910-203606.sv97383.16786@savannah.nongnu.org> <20220910-230511.sv54731.34817@savannah.nongnu.org> <20220911-162658.sv97383.70224@savannah.nongnu.org> <20220911-215436.sv97383.57804@savannah.nongnu.org> <20220911-215906.sv97383.85514@savannah.nongnu.org> In-Reply-To: <20220911-215906.sv97383.85514@savannah.nongnu.org> Date: Tue, 13 Sep 2022 17:40:08 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2022 21:40:09 -0000 Follow-up Comment #6, bug #63043 (project reproduce): It seems like the internal versions are in: cmake-3.24.0/Utilities/cmbzip2 cmake-3.24.0/Utilities/cmcurl cmake-3.24.0/Utilities/cmliblzma cmake-3.24.0/Utilities/cmzlib but there are also scripts for doing _git clone_ to upstream repositories of these: cmake-3.24.0/Utilities/Scripts/update-bzip2.bash cmake-3.24.0/Utilities/Scripts/update-curl.bash cmake-3.24.0/Utilities/Scripts/update-liblzma.bash cmake-3.24.0/Utilities/Scripts/update-third-party.bash cmake-3.24.0/Utilities/Scripts/update-zlib.bash On Debian 11.3, using _--no-system-libs_ and grepping the log gives: egrep -C1 --color=always "cmliblzma" log.config.20220912.1 |wc 622 9678 450111 egrep -C1 --color=always "git clone" log.config.20220912.1 |wc 0 0 0 On CentOS 7, using _--no-system-libs_ and grepping the log gives: egrep -C1 --color=always "cmliblzma" log.config.20220912.1 |wc 691 10164 430116 egrep -C1 --color=always "git clone" log.config.20220912.1 |wc 0 0 0 So it seems very much like the internal cmake _Utilities/_ versions are used, not versions downloaded with _git clone_. The output from _ldd_ is similar to what you (Mohammad) gave. So then the question is whether cmake having different versions of curl and the three compression libraries to the Maneage versions of the four libraries could cause build bugs, analysis bugs, or reproducibility bugs (or others?). My guess is that cmake will only do _de_compression, not compression. I have no idea if cmake rules can have the effect of using cmake as a binary front end to _curl_. Given that the four packages are, AFAIK, quite mature, it's quite likely that back-portability should be quite good between different versions that are not too far from each other. If problems do occur, then people using packages that depend on cmake will have to re-open this bug, or open a related one and propose a more robust solution. So I'm fine with _--no-system-libs_ and the LaTeX target something like: "CMake $(cmake-version) (with internal libraries distributed in Utilities/cm* in tarball)". _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Thu Sep 15 12:25:00 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oYrfe-0001pV-VX for mharc-reproduce-devel@gnu.org; Thu, 15 Sep 2022 12:24:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60360) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYrfX-0001oV-6K for reproduce-devel@nongnu.org; Thu, 15 Sep 2022 12:24:52 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:52348) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYrfW-00085o-Tz for reproduce-devel@nongnu.org; Thu, 15 Sep 2022 12:24:50 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 59DCE12068F; Thu, 15 Sep 2022 12:24:49 -0400 (EDT) To: Raul Infante-Sainz , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63054] Pyerfa crash, setting setuptools_scm as a prerequisite of pyerfa From: Mohammad Akhlaghi X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63054 X-Apparently-From: Savane authenticated user makhlaghi Message-Id: <20220915-172449.sv97383.63939@savannah.nongnu.org> References: <20220913-084328.sv138654.63814@savannah.nongnu.org> In-Reply-To: <20220913-084328.sv138654.63814@savannah.nongnu.org> Date: Thu, 15 Sep 2022 12:24:49 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2022 16:24:54 -0000 Follow-up Comment #1, bug #63054 (project reproduce): Thanks a lot for sharing this discovery! Do you think this is related to bug #61811 (jinja2, extension-helpers, pybind11 not found, even though installed)? Because pyerfa was also mentioned there. If those software have a similar problem, we may be able to fix them in a similar way ;-). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Thu Sep 15 12:36:32 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oYrqn-0006EX-CI for mharc-reproduce-devel@gnu.org; Thu, 15 Sep 2022 12:36:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35316) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYrqj-0006Bk-5j for reproduce-devel@nongnu.org; Thu, 15 Sep 2022 12:36:25 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:56496) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYrqh-0006CZ-RA for reproduce-devel@nongnu.org; Thu, 15 Sep 2022 12:36:23 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 658CE12068F; Thu, 15 Sep 2022 12:36:23 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63043] cmake build rule uses host liblzma.so and other host libraries From: Mohammad Akhlaghi X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63043 X-Apparently-From: Savane authenticated user makhlaghi Message-Id: <20220915-173623.sv97383.82065@savannah.nongnu.org> References: <20220910-125528.sv54731.72522@savannah.nongnu.org> <20220910-203606.sv97383.16786@savannah.nongnu.org> <20220910-230511.sv54731.34817@savannah.nongnu.org> <20220911-162658.sv97383.70224@savannah.nongnu.org> <20220911-215436.sv97383.57804@savannah.nongnu.org> <20220911-215906.sv97383.85514@savannah.nongnu.org> <20220913-214008.sv54731.71137@savannah.nongnu.org> In-Reply-To: <20220913-214008.sv54731.71137@savannah.nongnu.org> Date: Thu, 15 Sep 2022 12:36:23 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2022 16:36:26 -0000 Update of bug #63043 (project reproduce): Status: None => Fixed Assigned to: None => boud _______________________________________________________ Follow-up Comment #7: Thanks a lot for the complete analysis of the situation! I hadn't noticed the 'git clone' parts! Probably they are used when they decided to update those software and build new CMake tarballs, not when building from a pre-built tarball. > My guess is that cmake will only do de_compression, not compression. I agree! Probably as far as we are concerned (in Maneage's software building), those libraries won't be necessary at all (we de-compress the tarball before calling CMake). It probably needs these because CMake is a very non-modular and monolithic software: probably it also generates tarballs or uploads/downloads components and needs these for those scenarios. These are most probably not things that a Maneager would need in their analysis! > I have no idea if cmake rules can have the effect of using cmake as a binary front end to _curl. Since it does a static build to the cURL library, I probably CMake won't be using the 'curl' binary program. > If problems do occur, then people using packages that depend on cmake will have to re-open this bug, or open a related one and propose a more robust solution. I agree! But I recommend that they do the second option (open a new bug) for their unique situation (generally, its not a good idea to re-vitalize closed bugs, its better to cite the closed bug in the new bug instead). > So I'm fine with --no-system-libs and the LaTeX target something like: "CMake $(cmake-version) (with internal libraries distributed in Utilities/cm* in tarball)". Great! Can you commit this so I merge your commit into the core branch? Even though it is a very small fix and I can do it pretty fast, its good that this be in your name (who found, contributed to the fix and confirmed the fix; in other words, done all the hard work!). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Thu Sep 15 13:52:15 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oYt27-0003QY-4h for mharc-reproduce-devel@gnu.org; Thu, 15 Sep 2022 13:52:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58522) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYt25-0003QK-Tn for reproduce-devel@nongnu.org; Thu, 15 Sep 2022 13:52:13 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:53214) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYt25-00020L-LE for reproduce-devel@nongnu.org; Thu, 15 Sep 2022 13:52:13 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 1755E12068F; Thu, 15 Sep 2022 13:52:13 -0400 (EDT) To: Raul Infante-Sainz , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63054] Pyerfa crash, setting setuptools_scm as a prerequisite of pyerfa From: Raul Infante-Sainz X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63054 X-Apparently-From: Savane authenticated user infantesainz Message-Id: <20220915-175212.sv138654.37405@savannah.nongnu.org> References: <20220913-084328.sv138654.63814@savannah.nongnu.org> <20220915-172449.sv97383.63939@savannah.nongnu.org> In-Reply-To: <20220915-172449.sv97383.63939@savannah.nongnu.org> Date: Thu, 15 Sep 2022 13:52:13 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2022 17:52:14 -0000 Follow-up Comment #2, bug #63054 (project reproduce): maybe you are right! I have been looking at that. The only thing I have found is this line in the 'setup.py' file of 'extension-helpers': setup(use_scm_version={'write_to': os.path.join('extension_helpers', 'version.py')}) I tried to reproduce that problem but since it is not a reproducible bug I couldn't. In any case I can also add 'setuptools_scm' as a prerequisite of 'extension-helpers' and let the users try if they get the same problem. What do you think? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Thu Sep 15 14:38:02 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oYtkQ-0006Sc-06 for mharc-reproduce-devel@gnu.org; Thu, 15 Sep 2022 14:38:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41980) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYtkO-0006SJ-Pe for reproduce-devel@nongnu.org; Thu, 15 Sep 2022 14:38:00 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:48686) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYtkO-0000m5-HD for reproduce-devel@nongnu.org; Thu, 15 Sep 2022 14:38:00 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id E25F912068F; Thu, 15 Sep 2022 14:37:59 -0400 (EDT) To: Raul Infante-Sainz , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63054] Pyerfa crash, setting setuptools_scm as a prerequisite of pyerfa From: Mohammad Akhlaghi X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63054 X-Apparently-From: Savane authenticated user makhlaghi Message-Id: <20220915-193759.sv97383.47792@savannah.nongnu.org> References: <20220913-084328.sv138654.63814@savannah.nongnu.org> <20220915-172449.sv97383.63939@savannah.nongnu.org> <20220915-175212.sv138654.37405@savannah.nongnu.org> In-Reply-To: <20220915-175212.sv138654.37405@savannah.nongnu.org> Date: Thu, 15 Sep 2022 14:37:59 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2022 18:38:01 -0000 Follow-up Comment #3, bug #63054 (project reproduce): That sounds like a good idea. Maybe after adding this, you can try a clean build in a different build directory on one of your systems that had that problem before. I remember almost always having the problem on my system, so after checking and committing, just let me know and I'll also do a clean build here to confirm and hopefully merge it in. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Fri Sep 16 02:43:56 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oZ54s-0007Wl-Nd for mharc-reproduce-devel@gnu.org; Fri, 16 Sep 2022 02:43:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36238) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZ54r-0007Wc-QX for reproduce-devel@nongnu.org; Fri, 16 Sep 2022 02:43:53 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:34850) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZ54r-0002bZ-Gf for reproduce-devel@nongnu.org; Fri, 16 Sep 2022 02:43:53 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 47D7412068F; Fri, 16 Sep 2022 02:43:47 -0400 (EDT) To: Raul Infante-Sainz , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63054] Pyerfa crash, setting setuptools_scm as a prerequisite of pyerfa From: Raul Infante-Sainz X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63054 X-Apparently-From: Savane authenticated user infantesainz Message-Id: <20220916-064346.sv138654.60972@savannah.nongnu.org> References: <20220913-084328.sv138654.63814@savannah.nongnu.org> <20220915-172449.sv97383.63939@savannah.nongnu.org> <20220915-175212.sv138654.37405@savannah.nongnu.org> <20220915-193759.sv97383.47792@savannah.nongnu.org> In-Reply-To: <20220915-193759.sv97383.47792@savannah.nongnu.org> Date: Fri, 16 Sep 2022 02:43:47 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2022 06:43:54 -0000 Follow-up Comment #4, bug #63054 (project reproduce): Thanks Mohammad. I have pushed a commit so you can easily try it. Just don't forget to add 'astropy' as a final Python target to be built. https://gitlab.com/maneage/project-dev/-/commit/a9eac928 In my case, none of the problems described in bug #61811 happened. However, a new one appeared: 'numpy' complaining about not finding 'cython'! So, it would be a new case for bug #61811. Let me know how it goes in your case. I will try to check more things in the mean time. Maybe adding 'setuptools_scm' as a prerequisite of all problematic packages? Let's see. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Tue Sep 20 16:36:23 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oajyh-0007zK-8l for mharc-reproduce-devel@gnu.org; Tue, 20 Sep 2022 16:36:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44368) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oajyd-0007vs-Dn for reproduce-devel@nongnu.org; Tue, 20 Sep 2022 16:36:21 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:48866) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oajyc-0004Br-JG for reproduce-devel@nongnu.org; Tue, 20 Sep 2022 16:36:19 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 877BB1206CA; Tue, 20 Sep 2022 16:36:17 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63043] cmake build rule uses host liblzma.so and other host libraries From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63043 X-Apparently-From: Savane authenticated user boud Message-Id: <20220920-203617.sv54731.32716@savannah.nongnu.org> References: <20220910-125528.sv54731.72522@savannah.nongnu.org> <20220910-203606.sv97383.16786@savannah.nongnu.org> <20220910-230511.sv54731.34817@savannah.nongnu.org> <20220911-162658.sv97383.70224@savannah.nongnu.org> <20220911-215436.sv97383.57804@savannah.nongnu.org> <20220911-215906.sv97383.85514@savannah.nongnu.org> <20220913-214008.sv54731.71137@savannah.nongnu.org> <20220915-173623.sv97383.82065@savannah.nongnu.org> In-Reply-To: <20220915-173623.sv97383.82065@savannah.nongnu.org> Date: Tue, 20 Sep 2022 16:36:17 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2022 20:36:21 -0000 Follow-up Comment #8, bug #63043 (project reproduce): Commit 52814c3 builds fully from scratch through to final verify.tex checksums on CentOS 7 and Debian 11.5. Fine by me to put this in the core branch and close this (cmake) bug. https://codeberg.org/boud/maneage_dev/commit/52814c33554cd03a3ce54d8e25bed30688201cbc _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Tue Sep 20 16:39:50 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oak1s-0001iN-Uz for mharc-reproduce-devel@gnu.org; Tue, 20 Sep 2022 16:39:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41448) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oak1n-0001g0-E4 for reproduce-devel@nongnu.org; Tue, 20 Sep 2022 16:39:35 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:41596) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oak1m-0004TM-5M for reproduce-devel@nongnu.org; Tue, 20 Sep 2022 16:39:34 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id CAFD51206DE; Tue, 20 Sep 2022 16:39:33 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #62700] lzma/xz compilation bug for cmake in Maneage 27ff6f7 From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 62700 X-Apparently-From: Savane authenticated user boud Message-Id: <20220920-203933.sv54731.97964@savannah.nongnu.org> References: <20220703-173702.sv54731.33839@savannah.nongnu.org> <20220714-144031.sv54731.59289@savannah.nongnu.org> <20220715-144420.sv54731.44629@savannah.nongnu.org> <20220807-163932.sv97383.368@savannah.nongnu.org> <20220808-203822.sv54731.72283@savannah.nongnu.org> <20220808-203843.sv54731.71009@savannah.nongnu.org> <20220901-161817.sv54731.25337@savannah.nongnu.org> <20220909-182556.sv54731.65551@savannah.nongnu.org> <20220910-174723.sv54731.20287@savannah.nongnu.org> In-Reply-To: <20220910-174723.sv54731.20287@savannah.nongnu.org> Date: Tue, 20 Sep 2022 16:39:33 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2022 20:39:36 -0000 Follow-up Comment #8, bug #62700 (project reproduce): The time scale for xz-5.2.7 to be released should be a month or so; possbly shorter. On Maneage time scales, that's short :). Anyone impatient, or worried about the CentOS 7 bug, can look at this patch without waiting: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=31d80c6b261b24220776dfaeb8a04f80f80e0a24 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Tue Sep 20 17:53:20 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oalB9-0004m1-Sd for mharc-reproduce-devel@gnu.org; Tue, 20 Sep 2022 17:53:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51066) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oalB8-0004gT-62 for reproduce-devel@nongnu.org; Tue, 20 Sep 2022 17:53:18 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:51532) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oalB7-0000hX-TE for reproduce-devel@nongnu.org; Tue, 20 Sep 2022 17:53:17 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id BBEE91206CA; Tue, 20 Sep 2022 17:53:16 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #61240] gcc 10.2.1-6 cannot compile gcc 10.2.0; related: unwind, iconv From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 61240 X-Apparently-From: Savane authenticated user boud Message-Id: <20220920-215316.sv54731.93656@savannah.nongnu.org> References: <20210928-222713.sv54731.15996@savannah.nongnu.org> <20210928-224614.sv54731.98675@savannah.nongnu.org> <20210929-223654.sv54731.70864@savannah.nongnu.org> <20211001-054051.sv54731.1778@savannah.nongnu.org> <20211001-153004.sv97383.43104@savannah.nongnu.org> <20211009-225156.sv54731.14925@savannah.nongnu.org> <20211010-135739.sv97383.50836@savannah.nongnu.org> <20211010-213159.sv54731.73778@savannah.nongnu.org> <20211012-221322.sv54731.95298@savannah.nongnu.org> <20220118-000929.sv97383.68170@savannah.nongnu.org> In-Reply-To: <20220118-000929.sv97383.68170@savannah.nongnu.org> Date: Tue, 20 Sep 2022 17:53:16 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2022 21:53:18 -0000 Follow-up Comment #10, bug #61240 (project reproduce): Just to clarify that _--disable-multiarch_ was removed from _basic.mk_ in commit 8463df97c6f of Mon Oct 4 02:51:45 2021 +0200, in core maneage, along with software updates. Funnily enough, this fix happened, according to the time stamps, prior to the 9 Oct, 10 Oct, ..., phases of discussion of this bug (#61240). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Wed Sep 21 13:05:43 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ob3AM-0003qZ-Qj for mharc-reproduce-devel@gnu.org; Wed, 21 Sep 2022 13:05:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45490) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ob3AJ-0003qQ-RR for reproduce-devel@nongnu.org; Wed, 21 Sep 2022 13:05:39 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:38616) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ob3AJ-0002O8-Ja for reproduce-devel@nongnu.org; Wed, 21 Sep 2022 13:05:39 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 1088E1205A4; Wed, 21 Sep 2022 13:05:39 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #61271] Python build bug with curses.h in commit 775fc03 From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 61271 X-Apparently-From: Savane authenticated user boud Message-Id: <20220921-170538.sv54731.32785@savannah.nongnu.org> References: <20211003-202243.sv54731.81490@savannah.nongnu.org> <20220108-234004.sv97383.27653@savannah.nongnu.org> <20220109-133858.sv54731.6941@savannah.nongnu.org> In-Reply-To: <20220109-133858.sv54731.6941@savannah.nongnu.org> Date: Wed, 21 Sep 2022 13:05:39 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2022 17:05:40 -0000 Update of bug #61271 (project reproduce): Status: None => Works For Me _______________________________________________________ Follow-up Comment #4: DESCRIPTION: ncurses header files are typically provided in several major systems (Debian) directly in _/usr/include_ . The 'configure' of python-3.10.6, for commit 4318670 of core maneage, still had fatal errors because it couldn't find either _ncurses.h_ or _curses.h_ in either the Maneage _include/_ directory or the host OS _/usr/include_ . EXAMPLE LOG: 18136 /BUILD/software/installed/bin/gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implic it-function-declaration -fvisibility=hidden -I./Include/internal -I./Include -I. -I/BUILD/ software/installed/include -I/usr/include/x86_64-linux-gnu -I/usr/local/include -I/dev/shm/BUILD/python-3.10.6/I nclude -I/dev/shm/BUILD/python-3.10.6 -c /dev/shm/BUILD/python-3.10.6/Modules/termios.c - o build/temp.linux-x86_64-3.10/dev/shm/BUILD/python-3.10.6/Modules/termios.o 18137 /dev/shm/BUILD/python-3.10.6/Modules/readline.c: In function 'setup_readline': 18138 /dev/shm/BUILD/python-3.10.6/Modules/readline.c:1258:37: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] 18139 1258 | completer_word_break_characters = 18140 | ^ 18141 building 'resource' extension 18142 /BUILD/software/installed/bin/gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implic it-function-declaration -fvisibility=hidden -I./Include/internal -I./Include -I. -I/BUILD/ software/installed/include -I/usr/include/x86_64-linux-gnu -I/usr/local/include -I/dev/shm/BUILD/python-3.10.6/I nclude -I/dev/shm/BUILD/python-3.10.6 -c /dev/shm/BUILD/python-3.10.6/Modules/resource.c -o build/temp.linux-x86_64-3.10/dev/shm/BUILD/python-3.10.6/Modules/resource.o 18143 In file included from /dev/shm/BUILD/python-3.10.6/Modules/_curses_panel.c:15: 18144 ./Include/py_curses.h:36:10: fatal error: curses.h: No such file or directory 18145 36 | #include 18146 | ^~~~~~~~~~ 18147 compilation terminated. ... 18171 In file included from /dev/shm/BUILD/python-3.10.6/Modules/_cursesmodule.c:114: 18172 ./Include/py_curses.h:36:10: fatal error: curses.h: No such file or directory 18173 36 | #include 18174 | ^~~~~~~~~~ 18175 compilation terminated. ... 19279 checking for getnameinfo... yes 19280 checking for strlcpy... In file included from /dev/shm/BUILD/python-3.10.6/Modules/_curses_panel.c:15: 19281 ./Include/py_curses.h:36:10: fatal error: curses.h: No such file or directory 19282 36 | #include 19283 | ^~~~~~~~~~ 19284 compilation terminated. 19285 In file included from /dev/shm/BUILD/python-3.10.6/Modules/_cursesmodule.c:114: 19286 ./Include/py_curses.h:36:10: fatal error: curses.h: No such file or directory 19287 36 | #include 19288 | ^~~~~~~~~~ 19289 compilation terminated. ... 19302 Failed to build these modules: 19303 _curses _curses_panel SUGGESTED FIX: Commit 7286ad6 on branch 'fix_ncurses_for_python' [1] works for me. It adds the two lines cd "$(iidir)" ln -fsv $(idir)/include/ncursesw/*.h . to the 'ncurses' build rules in 'basic.mk'. [1] https://codeberg.org/boud/maneage_dev/commit/7286ad62014acaa8c46504493040c5acba7bd535 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Wed Sep 21 14:48:45 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ob4m4-0000gt-UL for mharc-reproduce-devel@gnu.org; Wed, 21 Sep 2022 14:48:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ob4lz-0000gF-Hw for reproduce-devel@nongnu.org; Wed, 21 Sep 2022 14:48:43 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:60256) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ob4ly-0000cn-TJ for reproduce-devel@nongnu.org; Wed, 21 Sep 2022 14:48:38 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id C3AEB120699; Wed, 21 Sep 2022 14:48:35 -0400 (EDT) To: Raul Infante-Sainz , Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #61811] jinja2, extension-helpers, pybind11 not found, even though installed; pyyaml error From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 61811 X-Apparently-From: Savane authenticated user boud Message-Id: <20220921-184835.sv54731.14055@savannah.nongnu.org> References: <20220113-111724.sv138654.94090@savannah.nongnu.org> <20220113-160338.sv54731.42724@savannah.nongnu.org> <20220113-183057.sv54731.69768@savannah.nongnu.org> <20220114-085000.sv138654.88305@savannah.nongnu.org> <20220114-152742.sv54731.95773@savannah.nongnu.org> <20220119-103307.sv97383.19872@savannah.nongnu.org> <20220713-114008.sv97383.9574@savannah.nongnu.org> In-Reply-To: <20220713-114008.sv97383.9574@savannah.nongnu.org> Date: Wed, 21 Sep 2022 14:48:35 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2022 18:48:43 -0000 Update of bug #61811 (project reproduce): Summary: jinja2, extension-helpers, pybind11 not found, even though installed => jinja2, extension-helpers, pybind11 not found, even though installed; pyyaml error _______________________________________________________ Follow-up Comment #7: DESCRIPTION: Running commit 4318670 of core maneage, with the addition of _pyyaml_ as a target: --- a/reproduce/software/config/TARGETS.conf +++ b/reproduce/software/config/TARGETS.conf @@ -39,7 +39,7 @@ top-level-programs = gnuastro # Python libraries/modules. -top-level-python = +top-level-python = pyyaml leads to compilation errors of the C source code of _pyyaml_. Independently, in a research project package, the compilation error does not appear to block a full configure of python packages, with _matplotlib_ selected in _TARGETS.conf_. Thus, this is a bug in principle, though not (so far) an obvious problem in practice. Nevertheless, it should be fixed, and seems to be included in bug #61811 [0], which is why I'm adding it here. LOG EXCERPT: 187806 /BUILD/software/installed/include/yaml.h:636:55: note: expected 'const yaml_char_t *' {aka ' const unsigned char *'} but argument is of type 'char *' 187807 636 | const yaml_char_t *anchor, const yaml_char_t *tag, int implicit, 187808 | ~~~~~~~~~~~~~~~~~~~^~~ 187809 config.status: executing libtool commands 187810 ext/_yaml.c: In function '__pyx_tp_dealloc_5_yaml_CParser': 187811 ext/_yaml.c:23870:5: error: lvalue required as increment operand 187812 23870 | ++Py_REFCNT(o); 187813 | ^~ 187814 ext/_yaml.c:23872:5: error: lvalue required as decrement operand 187815 23872 | --Py_REFCNT(o); 187816 | ^~ 187817 ext/_yaml.c: In function '__pyx_tp_dealloc_5_yaml_CEmitter': 187818 ext/_yaml.c:24040:5: error: lvalue required as increment operand 187819 24040 | ++Py_REFCNT(o); 187820 | ^~ 187821 ext/_yaml.c:24042:5: error: lvalue required as decrement operand 187822 24042 | --Py_REFCNT(o); 187823 | ^~ 187824 ext/_yaml.c: In function '__Pyx_modinit_type_init_code': 187825 ext/_yaml.c:24844:25: error: 'PyTypeObject' {aka 'struct _typeobject'} has no member named 'tp_print' 187826 24844 | __pyx_type_5_yaml_Mark.tp_print = 0; 187827 | ^ 187828 ext/_yaml.c:24864:28: error: 'PyTypeObject' {aka 'struct _typeobject'} has no member named 'tp_print' 187829 24864 | __pyx_type_5_yaml_CParser.tp_print = 0; 187830 | ^ HINTS: It might be necessary to shift from our default python build rules to rules that use 'wheel', per the discussion at [1]. Bug [2] appears to be related, but it's not immediately clear what the bug is and whether there is a generic, rather than OS-specific, fix. Some descriptions of 'wheel' are at [3][4]. A related guess is in [5][6] - it could be that the 'wheel' files with the 'sdist' option are not correctly built in the upstream 'pyyaml' (or 'jinja2' and so on) distributions. Debugging this might require understanding the relation of cython to python, pyyaml and the other packages, and understanding the various updates and bugs in cython, and errors that people make when preparing python packages in relation to cython. Disclaimer: I'm just guessing here. WHAT DID NOT WORK: I tried --- a/reproduce/software/make/python.mk +++ b/reproduce/software/make/python.mk @@ -581,7 +581,8 @@ $(ipydir)/pythran-$(pythran-version): \ $(ipydir)/pyyaml-$(pyyaml-version): \ $(ibidir)/yaml-$(yaml-version) \ - $(ipydir)/cython-$(cython-version) + $(ipydir)/cython-$(cython-version) \ + $(ipydir)/wheel-$(wheel-version) tarball=pyyaml-$(pyyaml-version).tar.gz $(call import-source, $(pyyaml-url), $(pyyaml-checksum)) $(call pybuild, tar -xf, PyYAML-$(pyyaml-version), , \ but the same error occurred. URLs: [0] https://savannah.nongnu.org/bugs/?61811 [1] https://github.com/PyWavelets/pywt/issues/602 [2] https://github.com/yaml/pyyaml/issues/416 [3] https://realpython.com/python-wheels [4] https://pythonwheels.com [5] https://github.com/yaml/pyyaml/issues/179 [6] https://github.com/yaml/pyyaml/pull/188 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sat Sep 24 15:28:59 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ocApf-0000Ew-3T for mharc-reproduce-devel@gnu.org; Sat, 24 Sep 2022 15:28:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43114) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocApe-0000Eb-6q for reproduce-devel@nongnu.org; Sat, 24 Sep 2022 15:28:58 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:42098) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocApd-0002cl-P4 for reproduce-devel@nongnu.org; Sat, 24 Sep 2022 15:28:57 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 60E481205F9; Sat, 24 Sep 2022 15:28:57 -0400 (EDT) To: Boud Roukema , reproduce-devel@nongnu.org Subject: [task #16267] Autocompletion would be nice From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: task X-Savane-Item-ID: 16267 X-Apparently-From: Savane authenticated user boud Message-Id: <20220924-192856.sv54731.16485@savannah.nongnu.org> References: In-Reply-To: Date: Sat, 24 Sep 2022 15:28:57 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2022 19:28:58 -0000 URL: Summary: Autocompletion would be nice Project: Maneage Submitter: boud Submitted: Sat 24 Sep 2022 07:28:56 PM UTC Should Start On: Sat 24 Sep 2022 12:00:00 AM UTC Should be Finished on: Sat 24 Sep 2022 12:00:00 AM UTC Category: Software Priority: 3 - Low Status: None Privacy: Public Percent Complete: 0% Assigned to: None Open/Closed: Open Discussion Lock: Any Effort: 0.00 _______________________________________________________ Follow-up Comments: ------------------------------------------------------- Date: Sat 24 Sep 2022 07:28:56 PM UTC By: Boud Roukema Autocompletion of the './project' commands in the interactive shell would be nice. This can really speed up work, reduce the chance of errors, and help the user discover previously unknown options. There are standard ways of implementing this - I've never done it. Autocompletion rules would later have to be updated when adding/removing commands and options to './project'. Since ./project is about the only Maneage command that is normally run directly, and often manually, probably it's the only one worth developing autocompletion for. I put this at 'low' priority, because a risk of making Maneage look too easy could be that users underestimate the current state of Maneage - a very experimental stage - and don't understand that they'll need to "look under the hood". But probably nobody will object if someone implements this quickly... Since './project' is only expected to require a minimal POSIX-like environment and OS, autocompletion implementations might be highly OS-dependent, though I'm just guessing here. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sat Sep 24 15:39:20 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ocAzg-00028v-GZ for mharc-reproduce-devel@gnu.org; Sat, 24 Sep 2022 15:39:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40930) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocAze-00028U-GL for reproduce-devel@nongnu.org; Sat, 24 Sep 2022 15:39:19 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:42104) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocAze-0003zc-5k for reproduce-devel@nongnu.org; Sat, 24 Sep 2022 15:39:18 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id E0113120629; Sat, 24 Sep 2022 15:39:17 -0400 (EDT) To: Boud Roukema , Mohammad Akhlaghi , pedramardakani@proton.me, reproduce-devel@nongnu.org Subject: [task #16267] Autocompletion would be nice From: Mohammad Akhlaghi X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: task X-Savane-Item-ID: 16267 X-Apparently-From: Savane authenticated user makhlaghi Message-Id: <20220924-203917.sv97383.42370@savannah.nongnu.org> References: <20220924-192856.sv54731.16485@savannah.nongnu.org> In-Reply-To: <20220924-192856.sv54731.16485@savannah.nongnu.org> Date: Sat, 24 Sep 2022 15:39:17 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2022 19:39:19 -0000 Follow-up Comment #1, task #16267 (project reproduce): We have some good (although not yet fully complete!) experience with Bash's autocomplete features in Gnuastro: https://www.gnu.org/software/gnuastro/manual/html_node/Bash-TAB-completion-tutorial.html . Pedram done all of this work in Gnuastro. It is pretty exciting and highly customizable (in Gnuastro it can also be used to select table column names within a table or FITS keywords! But as I said, it is still not fully complete, so its not activated by default installation. I also agree that it isn't a high priority for Maneage at this stage: we don't have too many options and most don't take too many values. But in the future, if someone has some free time to implement it, of course, they would be very welcome! _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sat Sep 24 15:43:56 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ocB47-0002OW-VS for mharc-reproduce-devel@gnu.org; Sat, 24 Sep 2022 15:43:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40874) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocB46-0002OO-TD for reproduce-devel@nongnu.org; Sat, 24 Sep 2022 15:43:54 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:34298) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocB46-0004jL-Ks for reproduce-devel@nongnu.org; Sat, 24 Sep 2022 15:43:54 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 2772F120629; Sat, 24 Sep 2022 15:43:54 -0400 (EDT) To: Raul Infante-Sainz , Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #61811] jinja2, extension-helpers, pybind11 not found, even though installed; pyyaml error From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 61811 X-Apparently-From: Savane authenticated user boud Message-Id: <20220924-194354.sv54731.74914@savannah.nongnu.org> References: <20220113-111724.sv138654.94090@savannah.nongnu.org> <20220113-160338.sv54731.42724@savannah.nongnu.org> <20220113-183057.sv54731.69768@savannah.nongnu.org> <20220114-085000.sv138654.88305@savannah.nongnu.org> <20220114-152742.sv54731.95773@savannah.nongnu.org> <20220119-103307.sv97383.19872@savannah.nongnu.org> <20220713-114008.sv97383.9574@savannah.nongnu.org> <20220921-184835.sv54731.14055@savannah.nongnu.org> In-Reply-To: <20220921-184835.sv54731.14055@savannah.nongnu.org> Date: Sat, 24 Sep 2022 15:43:54 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2022 19:43:55 -0000 Follow-up Comment #8, bug #61811 (project reproduce): Commit ab7303c [1], which is one commit beyond core maneage 4318670, works for me to solve compilation bugs for the python packages 'extension-helpers' (as mentioned in #61811 here), and 'packaging', which is mentioned in the #61811 discussion as a dependency. The solution is to add both 'setuptools' and 'setuptools_scm' as dependencies in 'python.mk'. This solves the bug for me on Debian 11 and CentOS 7 parallel machines. The two debian lists of dependencies of these two packages [2][3] are a strong clue that these dependencies are needed. Astropy (for example) has to be enabled in TARGETS.conf for ab7303c to be tested. See also: the discussion at bug #63054 [4]. [1] https://codeberg.org/boud/maneage_dev/commit/ab7303cd70e48830c22bd0f4ae7f70411afc3246 [2] https://sources.debian.org/src/python-packaging/21.3-1.1/debian/control [3] https://salsa.debian.org/python-team/packages/extension-helpers/-/blob/master/debian/control [4] https://savannah.nongnu.org/bugs/?63054 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sat Sep 24 15:58:57 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ocBIf-0003cC-3r for mharc-reproduce-devel@gnu.org; Sat, 24 Sep 2022 15:58:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44254) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocBId-0003c4-V3 for reproduce-devel@nongnu.org; Sat, 24 Sep 2022 15:58:55 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:53258) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocBIc-0006dz-M6 for reproduce-devel@nongnu.org; Sat, 24 Sep 2022 15:58:55 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 598B81205F9; Sat, 24 Sep 2022 15:58:54 -0400 (EDT) To: Raul Infante-Sainz , Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #61811] jinja2, extension-helpers, pybind11 not found, even though installed; pyyaml error From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 61811 X-Apparently-From: Savane authenticated user boud Message-Id: <20220924-195854.sv54731.12569@savannah.nongnu.org> References: <20220113-111724.sv138654.94090@savannah.nongnu.org> <20220113-160338.sv54731.42724@savannah.nongnu.org> <20220113-183057.sv54731.69768@savannah.nongnu.org> <20220114-085000.sv138654.88305@savannah.nongnu.org> <20220114-152742.sv54731.95773@savannah.nongnu.org> <20220119-103307.sv97383.19872@savannah.nongnu.org> <20220713-114008.sv97383.9574@savannah.nongnu.org> <20220921-184835.sv54731.14055@savannah.nongnu.org> <20220924-194354.sv54731.74914@savannah.nongnu.org> In-Reply-To: <20220924-194354.sv54731.74914@savannah.nongnu.org> Date: Sat, 24 Sep 2022 15:58:54 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2022 19:58:56 -0000 Follow-up Comment #9, bug #61811 (project reproduce): Commit 67daeee [0], which is one commit beyond core maneage 4318670, works for me to solve the 'pyyaml' compilation bug listed below here in bug #61811. The solution is to update from pyyaml-5.1 to pyyaml-6.0. (This seems to be independent from the other set of python bugs listed here.) The cause of the problem is stated in the python documentation: Py_REFCNT changed in implementation to a function [1], so increasing its value with '++Py_REFCNT' is invalid, which is why the error message states 'lvalue required as increment operand'. An 'lvalue' is a 'left-hand value', i.e. that can be put in the left-hand part of an assignment operation, written '=' in C; the "value" of a function is (I guess) the address of the function in RAM, so augmenting the value of that address would be nonsense. To see the problem for yourself, try compiling the standalone program int Py_REFCNT(const double *o){ }; int main(void){ double x; ++Py_REFCNT(&x); } with a C compiler. You should obtain the same error as when installing pyyaml-5.1 with python-3.10.6. Grep your log file if you didn't notice the bug before. Commit 67daeee also adds 'setuptools_scm' dependencies for the python build rules for 'soupsieve' and 'webencodings', since otherwise these builds may fail (depending on the speed and parallel nature of compiles; these *did* fail for me); see also bug #63054 [2]. Astropy (for example) has to be enabled in TARGETS.conf for 67daeee to be tested. [0] https://codeberg.org/boud/maneage_dev/commit/67daeee967fafd44e6f8199748f5cae4dd7ad5d6 [1] https://docs.python.org/3/c-api/structures.html#c.Py_REFCNT [2] https://savannah.nongnu.org/bugs/?63054 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sat Sep 24 16:09:53 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ocBTF-0007vm-Pl for mharc-reproduce-devel@gnu.org; Sat, 24 Sep 2022 16:09:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59066) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocBTD-0007ve-Mg for reproduce-devel@nongnu.org; Sat, 24 Sep 2022 16:09:52 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:33224) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocBTD-0008Pb-Em for reproduce-devel@nongnu.org; Sat, 24 Sep 2022 16:09:51 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 36CB91205F9; Sat, 24 Sep 2022 16:09:51 -0400 (EDT) To: Raul Infante-Sainz , Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63054] Pyerfa crash, setting setuptools_scm as a prerequisite of pyerfa From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63054 X-Apparently-From: Savane authenticated user boud Message-Id: <20220924-200951.sv54731.37822@savannah.nongnu.org> References: <20220913-084328.sv138654.63814@savannah.nongnu.org> <20220915-172449.sv97383.63939@savannah.nongnu.org> <20220915-175212.sv138654.37405@savannah.nongnu.org> <20220915-193759.sv97383.47792@savannah.nongnu.org> <20220916-064346.sv138654.60972@savannah.nongnu.org> In-Reply-To: <20220916-064346.sv138654.60972@savannah.nongnu.org> Date: Sat, 24 Sep 2022 16:09:51 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2022 20:09:52 -0000 Follow-up Comment #5, bug #63054 (project reproduce): See my two merge requests at bug #61811 for overlapping discussion. Rather than adding 'setuptools_scm' for _all_ python packages, or rather than waiting until someone reports a problem for a package, a systematic way to benefit from the work of the Debian Astro group would be, for each of our python packages, to look at https://tracker.debian.org/PACKAGENAME after checking/searching for the matching debian PACKAGENAME; once the tracker web page is found, go to 'browse' (left-hand column), 'debian/' and find the file 'control', and see what prerequisites Debian Astro think are needed (a few packages are not on salsa.debian.org, but a 'browse' source button should be available somewhere on the tracker). 'Build-Depends:' are for building; 'Depends:' are for running. Adding 'setuptools_scm' as a prerequisite for 'pyyaml' made no difference for me, and it's not listed in the Debian Astro control file [1]. With core maneage 4318670, I have _not_ detected any errors compiling _pyerfa_. [1] https://salsa.debian.org/python-team/packages/pyyaml/-/blob/debian/master/debian/control _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sat Sep 24 19:24:55 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ocEVz-0004og-CI for mharc-reproduce-devel@gnu.org; Sat, 24 Sep 2022 19:24:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52038) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocEVy-0004oY-9C for reproduce-devel@nongnu.org; Sat, 24 Sep 2022 19:24:54 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:51532) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocEVx-00012h-QM for reproduce-devel@nongnu.org; Sat, 24 Sep 2022 19:24:53 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id A494712062D; Sat, 24 Sep 2022 19:24:52 -0400 (EDT) To: Boud Roukema , reproduce-devel@nongnu.org Subject: [bug #63101] oberdiek update causes failure to find pdfcol.sty From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63101 X-Apparently-From: Savane authenticated user boud Message-Id: <20220924-232451.sv54731.4241@savannah.nongnu.org> References: In-Reply-To: Date: Sat, 24 Sep 2022 19:24:52 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2022 23:24:54 -0000 URL: Summary: oberdiek update causes failure to find pdfcol.sty Project: Maneage Submitter: boud Submitted: Sat 24 Sep 2022 11:24:51 PM UTC Category: Software Severity: 3 - Normal Item Group: Crash Status: Works For Me Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any _______________________________________________________ Follow-up Comments: ------------------------------------------------------- Date: Sat 24 Sep 2022 11:24:51 PM UTC By: Boud Roukema In September 2022, the 'pdfcol' package was separated out of the LaTeX package 'oberdiek', which is indirectly required by some common LaTeX packages, so 'pdfcol' needs to be installed as an individual texlive package. The change occurred between 'oberdiek' revision IDs 61066 and 64463, causing a fatal LaTeX error in the second, but not the first, of two almost successive installs of a package with a change that was irrelevant for LaTeX: ! LaTeX Error: File `pdfcol.sty' not found. l.23 \pdfcolInitStack {tcb@breakable}^^M Commit e2bc511 [2], one commit beyond 4318670, fixes this bug for me by adding 'pdfcol' to the texlive entry in 'reproduce/software/config/texlive-packages.conf'. A brief hint for people trying to find where the texlive install log is is also added as a comment in this commit. [1] https://github.com/ho-tex/oberdiek/commit/57cd8aeae9d2468726270b4855362511fe88b511 [2] https://codeberg.org/boud/maneage_dev/commit/e2bc511330486c66ef1c0713a91cd54c859b9782 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sun Sep 25 11:08:44 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ocTFK-0001N8-6s for mharc-reproduce-devel@gnu.org; Sun, 25 Sep 2022 11:08:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55084) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocTFG-0001Lj-HF for reproduce-devel@nongnu.org; Sun, 25 Sep 2022 11:08:39 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:41136) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocTFG-0004Aj-4H for reproduce-devel@nongnu.org; Sun, 25 Sep 2022 11:08:38 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 6BD67120665; Sun, 25 Sep 2022 11:08:36 -0400 (EDT) To: Boud Roukema , reproduce-devel@nongnu.org Subject: [task #16268] python: -single-version-externally-managed instead of egg From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: task X-Savane-Item-ID: 16268 X-Apparently-From: Savane authenticated user boud Message-Id: <20220925-150834.sv54731.91056@savannah.nongnu.org> References: In-Reply-To: Date: Sun, 25 Sep 2022 11:08:36 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2022 15:08:40 -0000 URL: Summary: python: -single-version-externally-managed instead of egg Project: Maneage Submitter: boud Submitted: Sun 25 Sep 2022 03:08:34 PM UTC Should Start On: Sun 25 Sep 2022 12:00:00 AM UTC Should be Finished on: Sun 25 Sep 2022 12:00:00 AM UTC Category: None Priority: 5 - Normal Status: None Privacy: Public Percent Complete: 0% Assigned to: None Open/Closed: Open Discussion Lock: Any Effort: 0.00 _______________________________________________________ Follow-up Comments: ------------------------------------------------------- Date: Sun 25 Sep 2022 03:08:34 PM UTC By: Boud Roukema On the Libera Chat channel #python, when I asked a specific question in trying to find a simple workaround for the pyerfa bug #63054 [0], Chris Warrick described 'egg' format as 'legacy packaging format that should be avoided', and instead recommended us considering an update of our build rules [1]. The key part seems to be python setup.py install --single-version-externally-managed although apparently a root option '--root=/SOME/PATH' could be useful too. [0] https://savannah.nongnu.org/bugs/index.php?63054 [1] https://stackoverflow.com/questions/6301003/stopping-setup-py-from-installing-as-egg/33791008#33791008 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Sun Sep 25 11:17:15 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ocTNb-0004cL-N0 for mharc-reproduce-devel@gnu.org; Sun, 25 Sep 2022 11:17:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41046) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocTNa-0004Z8-1l for reproduce-devel@nongnu.org; Sun, 25 Sep 2022 11:17:14 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:53854) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocTNZ-0005X1-Qz for reproduce-devel@nongnu.org; Sun, 25 Sep 2022 11:17:13 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id 5FEFF120665; Sun, 25 Sep 2022 11:17:13 -0400 (EDT) To: Raul Infante-Sainz , Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63054] Pyerfa crash, setting setuptools_scm as a prerequisite of pyerfa From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63054 X-Apparently-From: Savane authenticated user boud Message-Id: <20220925-151713.sv54731.75352@savannah.nongnu.org> References: <20220913-084328.sv138654.63814@savannah.nongnu.org> <20220915-172449.sv97383.63939@savannah.nongnu.org> <20220915-175212.sv138654.37405@savannah.nongnu.org> <20220915-193759.sv97383.47792@savannah.nongnu.org> <20220916-064346.sv138654.60972@savannah.nongnu.org> <20220924-200951.sv54731.37822@savannah.nongnu.org> In-Reply-To: <20220924-200951.sv54731.37822@savannah.nongnu.org> Date: Sun, 25 Sep 2022 11:17:13 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2022 15:17:14 -0000 Follow-up Comment #6, bug #63054 (project reproduce): I have now reproduced the bug: 'pyerfa' fails with an error that 'packaging' is missing, even though 'packaging' *is* a dependency of 'pyerfa' in 'python.mk'. Commit 1333c1b1 proposed below by Raúl is _not_ enough for my run: I got the above fatal error while including _setuptools_scm_ as a prerequisite for _pyerfa_ . I'm currently trying a workaround, since 'packaging' was installed on this particular Maneage system about an hour before 'pyerfa' needed it, so this is probably something subtle related to pyerfa's 'setup.py' file and the various python 'os', 'sys' and 'setuptools' packages work... _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Mon Sep 26 04:19:08 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ocjKW-0003dk-4c for mharc-reproduce-devel@gnu.org; Mon, 26 Sep 2022 04:19:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57232) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocjKU-0003c8-Sd for reproduce-devel@nongnu.org; Mon, 26 Sep 2022 04:19:06 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:34938) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocjKU-0005gS-Kk for reproduce-devel@nongnu.org; Mon, 26 Sep 2022 04:19:06 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id ACF24120668; Mon, 26 Sep 2022 04:19:04 -0400 (EDT) To: Raul Infante-Sainz , Boud Roukema , reproduce-devel@nongnu.org Subject: [task #16268] python: -single-version-externally-managed instead of egg From: Raul Infante-Sainz X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: task X-Savane-Item-ID: 16268 X-Apparently-From: Savane authenticated user infantesainz Message-Id: <20220926-081904.sv138654.81432@savannah.nongnu.org> References: <20220925-150834.sv54731.91056@savannah.nongnu.org> In-Reply-To: <20220925-150834.sv54731.91056@savannah.nongnu.org> Date: Mon, 26 Sep 2022 04:19:04 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2022 08:19:07 -0000 Follow-up Comment #1, task #16268 (project reproduce): Do you mean that with the option '--single-version-externally-managed' bug #63054 would be fixed? I could check it. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Mon Sep 26 05:50:57 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ocklN-0006Lx-7G for mharc-reproduce-devel@gnu.org; Mon, 26 Sep 2022 05:50:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42648) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocklL-0006It-Tf for reproduce-devel@nongnu.org; Mon, 26 Sep 2022 05:50:55 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:57014) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocklL-0003E8-LC for reproduce-devel@nongnu.org; Mon, 26 Sep 2022 05:50:55 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id BD9BF120668; Mon, 26 Sep 2022 05:50:54 -0400 (EDT) To: Raul Infante-Sainz , Boud Roukema , reproduce-devel@nongnu.org Subject: [task #16268] python: -single-version-externally-managed instead of egg From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: task X-Savane-Item-ID: 16268 X-Apparently-From: Savane authenticated user boud Message-Id: <20220926-095054.sv54731.90739@savannah.nongnu.org> References: <20220925-150834.sv54731.91056@savannah.nongnu.org> <20220926-081904.sv138654.81432@savannah.nongnu.org> In-Reply-To: <20220926-081904.sv138654.81432@savannah.nongnu.org> Date: Mon, 26 Sep 2022 05:50:54 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2022 09:50:56 -0000 Follow-up Comment #2, task #16268 (project reproduce): It *might* solve the bug #63054, but that wasn't my intention. I think the idea is rather to replace our current 'pybuild' rule with ... if type pyhook_before &>/dev/null; then pyhook_before; fi; \ python setup.py build; \ python setup.py install --single-version-externally-managed; \ if type pyhook_after &>/dev/null; then pyhook_after; fi; \ cd ..; \ ... But it would be good if somebody could find some documentation - whether 'formal' documentation or a git commit description or inline source documentation - which tells us a bit more about this. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/ From MAILER-DAEMON Tue Sep 27 03:59:45 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1od5VH-0002ZN-SD for mharc-reproduce-devel@gnu.org; Tue, 27 Sep 2022 03:59:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55750) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1od5VD-0002Tn-PU for reproduce-devel@nongnu.org; Tue, 27 Sep 2022 03:59:39 -0400 Received: from frontend2.savannah.gnu.org ([209.51.188.113]:38436) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1od5VB-00060D-LC for reproduce-devel@nongnu.org; Tue, 27 Sep 2022 03:59:38 -0400 Received: by frontend2.savannah.gnu.org (Postfix, from userid 33) id A325B12067D; Tue, 27 Sep 2022 03:59:36 -0400 (EDT) To: Raul Infante-Sainz , Boud Roukema , Mohammad Akhlaghi , reproduce-devel@nongnu.org Subject: [bug #63054] Pyerfa crash, setting setuptools_scm as a prerequisite of pyerfa From: Boud Roukema X-Savane-Server: savannah.nongnu.org:443 [209.51.188.113] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Savane-Project: reproduce X-Savane-Tracker: bugs X-Savane-Item-ID: 63054 X-Apparently-From: Savane authenticated user boud Message-Id: <20220927-075936.sv54731.98427@savannah.nongnu.org> References: <20220913-084328.sv138654.63814@savannah.nongnu.org> <20220915-172449.sv97383.63939@savannah.nongnu.org> <20220915-175212.sv138654.37405@savannah.nongnu.org> <20220915-193759.sv97383.47792@savannah.nongnu.org> <20220916-064346.sv138654.60972@savannah.nongnu.org> <20220924-200951.sv54731.37822@savannah.nongnu.org> <20220925-151713.sv54731.75352@savannah.nongnu.org> In-Reply-To: <20220925-151713.sv54731.75352@savannah.nongnu.org> Date: Tue, 27 Sep 2022 03:59:36 -0400 (EDT) X-BeenThere: reproduce-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2022 07:59:40 -0000 Follow-up Comment #7, bug #63054 (project reproduce): Commit e6c09c0ec [1] solves the pyerfa bug for me. This is effectively ab7303c [2] that fixes 'extension-helpers' and 'packaging' in bug #61811 [3], followed by 2b02ded that forcefully adds the 'packaging' .egg file to _sys.path_ , and followed by enabling _gnuastro_ installation in order to have a full test through to _verify.mk_ checksums. [The 'pyyaml' bug (fixable with 67daeee) gives the expected error in the log file, without preventing successful configuring and making.] In other words, 2b02ded does not solve the pyerfa bug for me unless it is merged with ab7303c; 2b02ded and ab7303c merged together *do* solve the pyerfa bug for me (provided that _gnuastro_ is enabled in _TARGETS.conf_). [1] https://codeberg.org/boud/maneage_dev/commit/e6c09c0ecf8f96106435353f3a37ad90ea0afa8f [2] https://codeberg.org/boud/maneage_dev/commit/ab7303cd70e48830c22bd0f4ae7f70411afc3246 [3] https://savannah.nongnu.org/bugs/index.php?61811#comment8 [4] https://codeberg.org/boud/maneage_dev/commit/2b02dedd38d833463811a64400757bf9ba96b5b5 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/