From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id EIiZCugLJWCEMQAA0tVLHw (envelope-from ) for ; Thu, 11 Feb 2021 10:50:16 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id 8JSNBugLJWDBCwAA1q6Kng (envelope-from ) for ; Thu, 11 Feb 2021 10:50:16 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AA14494021E for ; Thu, 11 Feb 2021 10:50:15 +0000 (UTC) Received: from localhost ([::1]:50796 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lA9Y6-0000YO-JE for larch@yhetil.org; Thu, 11 Feb 2021 05:50:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35118) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lA9Xw-0000YG-Cl for guix-patches@gnu.org; Thu, 11 Feb 2021 05:50:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:46315) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lA9Xu-0004JL-GE for guix-patches@gnu.org; Thu, 11 Feb 2021 05:50:04 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lA9Xu-00081y-Di for guix-patches@gnu.org; Thu, 11 Feb 2021 05:50:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#46376] [PATCH] gnu: tesseract-ocr: update to 4.1.1) Resent-From: Jelle Licht Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 11 Feb 2021 10:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46376 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Andy Tai Cc: 46376@debbugs.gnu.org Received: via spool by 46376-submit@debbugs.gnu.org id=B46376.161304054730805 (code B ref 46376); Thu, 11 Feb 2021 10:50:02 +0000 Received: (at 46376) by debbugs.gnu.org; 11 Feb 2021 10:49:07 +0000 Received: from localhost ([127.0.0.1]:57861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lA9X0-00080m-Gg for submit@debbugs.gnu.org; Thu, 11 Feb 2021 05:49:07 -0500 Received: from mail1.fsfe.org ([217.69.89.151]:53038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lA9Wp-00080D-F6 for 46376@debbugs.gnu.org; Thu, 11 Feb 2021 05:49:05 -0500 From: Jelle Licht In-Reply-To: References: <86a6sep7h0.fsf@posteo.net> <867dnhpi85.fsf@posteo.net> <86sg6450cl.fsf@posteo.net> Date: Thu, 11 Feb 2021 11:48:52 +0100 Message-ID: <86o8gq517v.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.26 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (strict), No valid DKIM" header.from=posteo.net (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: AA14494021E X-Spam-Score: -2.26 X-Migadu-Scanner: scn1.migadu.com X-TUID: 2IfaK0vzx7lK Hey Andy, Andy Tai writes: > updated patch: > > unit tests run, with some failures due to illegal instruction and > others succeed, but these requires first manual downloading of the > training data; I am not sure how that can be done as part of Guix > package definition. Help on that is much appreciated. (details > commented in the patch) The illegal instruction stuff seems somehow problematic either way. The training data seems to be generated via a not-really-trivial process, so my guess is that to properly package this, we would really have to generate the training data 'from source'. For now, it might make more sense to have users "BYOTD" (bring your own training data) and leave it out of the packaging story. Andy, what would you think about dumbing down your patch so tesseract-ocr simply doesn't run tests (or try to build them, for that matter)? So sorry for sending you on this wild goose chase! I'm willing to adjust and push such a change, unless someone has a better idea. Thanks, - Jelle