From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0328EC43603 for ; Mon, 9 Dec 2019 19:39:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C4C35206E0 for ; Mon, 9 Dec 2019 19:39:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="ivWRzgyW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726354AbfLITjj (ORCPT ); Mon, 9 Dec 2019 14:39:39 -0500 Received: from mail-oi1-f170.google.com ([209.85.167.170]:43183 "EHLO mail-oi1-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726342AbfLITjj (ORCPT ); Mon, 9 Dec 2019 14:39:39 -0500 Received: by mail-oi1-f170.google.com with SMTP id x14so7432999oic.10 for ; Mon, 09 Dec 2019 11:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=vEDacINzJXblL4Uy3342kCr+ZBLkrpqbrNvusQA4qf4=; b=ivWRzgyW68FBC63BW4vtKZ+/m89q1v0hGOVk5uHszWTVMwVpnq6CWS7EJumfMJ9Sqf 80pGGHdGemsVXO2hnYqi4I4L0DpYWWoUdI4TJNHZZcD+E48XtFzr7GgKmMvAvUNBxzy+ naiyemd6sDzoSuClmjhoxGdRNZ/4tX6Cubpp9VuxHejrwh7vGFa/vuYBWIAIAzbUtaCe Iwje/WMuFKKvot8zYt/n+Lmy+AiSY1TmYkWlniKsJYkWJXDN+cCbF9Z0RO1Au23XJUSE FvgUk+FYLXYHapNNJ/Wf8J60eVpUmKOhdUN1jCXcgXd3VsiiXElAB0jM7NqKGpcNSEvo p47A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=vEDacINzJXblL4Uy3342kCr+ZBLkrpqbrNvusQA4qf4=; b=E447UjxD5WfQ45PxXRv5/6C7u/DKB1p/L/ZGmZzvy8ev/+HOKb/AqaNozXtsrZtQVN e4tRDdg+iYSKCV5jhzZKFosMgCqfz1KL0PxeqWUuTUVD94QwWaH+4HUGd52Wt6dR++hi MgvYJGrUL5nrv/C4DnQpJljeO3Rvruu19YaOPTC0kTNUPkazUs/rOM4UsqGvLYpuSlN1 0h4Te9F9Fn/yQYruFnMz9A5HiQjK+th6K9AMo6dzQVMIOkfovNMm/nI5BJVdw8SY8Foh UDZn0gIyrgo2sAPQ6PxVdJMUpIfo4/SbZbcctgeWPhF3oJaP1hjeV4HH7qnRMElJBmZ0 G35Q== X-Gm-Message-State: APjAAAU+GEmWSaurcffB3ow7dQCoxWK5YAk/dUP6XAT0gUgruL6MSAHz CZXecDnAQgqsyJ+hEbGIEkfU5w7nKEpqmQ== X-Google-Smtp-Source: APXvYqy/FOAxRNLiDeDBuJN2/wMrbqgzCLUB/3Kiuee175CxLB1JIUTTvEGiSgk2dJMlacMdv9r0aA== X-Received: by 2002:a05:6808:210:: with SMTP id l16mr690963oie.95.1575920377982; Mon, 09 Dec 2019 11:39:37 -0800 (PST) Received: from ziepe.ca ([217.140.111.136]) by smtp.gmail.com with ESMTPSA id r24sm300842ota.61.2019.12.09.11.39.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 09 Dec 2019 11:39:37 -0800 (PST) Received: from jgg by jggl.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1ieOsa-00012k-EF; Mon, 09 Dec 2019 15:39:36 -0400 Date: Mon, 9 Dec 2019 15:39:36 -0400 From: Jason Gunthorpe To: Thorben =?utf-8?B?UsO2bWVy?= Cc: linux-rdma@vger.kernel.org Subject: Re: install-step fails for pandoc-prebuilt man-pages in infiniband-diags/man Message-ID: <20191209193936.GA3471@ziepe.ca> References: <5d754108-7020-6041-1b7d-bbb3fb2f089b@secunet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5d754108-7020-6041-1b7d-bbb3fb2f089b@secunet.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Wed, Dec 04, 2019 at 03:34:14PM +0100, Thorben Römer wrote: > While investigating, I came up with the following explanation: The > hashes (generated by buildlib/pandoc-prebuilt.py) differ from machine to > machine, as the contents of the *.rst-files are hashed. Most of these > files are processed via cmake's configure_file from *.in.rst-files and > contain custom-per-build-data such as absolute paths. This means that > hashing *.rst-files will produce differing hashes based on the > build-directory-path (among other data points, possibly). It is not the build directory path, it is the install directory path, and yes, the no-pandoc builds have to use the standard paths. > by looking at the hashes produced by two of my machines, they were > different for all but 3 files (ibcacheedit.8.rst, ibstatus.8.rst and > check_lft_balance.8.rst). These files (and their includes, as their > content is also hashed!) are the only files that to not contain any > differing data when being transformed from *.in.rst to *.rst via > configure_file, which supports my hypothesis. This only happens if each machine is configuring to use different paths, or something has gone quite wrong. What are the actual diffs from the two .rst's ? > With my limited time and expertise in the rdma-core project, I was only > able to come up with a solution that I don't find very practical. I will > append a diff of pandoc-prebuilt.py nonetheless, which replaces > hashing-calls for *.rst to *.in.rst if applicable. This just makes broken output if pandoc is not present, it is not practical. The only good options is to shift the substition to after pandoc/rst2man run - but I'm not sure if that is doable.. Jason