lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220817130743.6ogxalp6kndjkutc@begin>
Date:   Wed, 17 Aug 2022 15:07:43 +0200
From:   Samuel Thibault <samuel.thibault@...-lyon.org>
To:     Nikita Travkin <nikita@...n.ru>
Cc:     gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        speakup@...ux-speakup.org
Subject: Re: [PATCHv4] speakup: Generate speakupmap.h automatically

Hello,

Nikita Travkin, le mer. 17 août 2022 09:10:11 +0500, a ecrit:
> Samuel Thibault писал(а) 16.08.2022 23:33:
> > Nikita Travkin, le mar. 16 août 2022 12:28:43 +0500, a ecrit:
> >> After that I also had some weird issues of the build system trying to
> >> write speakupmap.h into the source dir and not the output dir (the
> >> source is read only due to the tooling I use) but this seems to have
> >> been resolved by cleanly rebuilding the speakup dir.
> > 
> > Mmm, how did you get/update your source dir? The latest version of the
> > patchset does generate it in the build tree.
> 
> It's just a git tree for Linux in which I've checked-out the
> v6.0-rc1 tag and applied few unrelated patches on top.
> 
> The thing confused me a bit as all other artifacts were properly
> placed in the output dir with an exception of the speakupmap.h.
> 
> My guess would be that I had some cache left over in the build dir
> from before this patch, when the file was hardcoded so it tried to
> recreate it as it was.

That was my guess as well.

> This seems reproducible:

Ok. I guess the confusion is coming from the firstly-generated
.main.o.cmd file that would still refer to the in-source origin.  I
don't think we can do much about this case, unfortunately.

Thanks for checking,
Samuel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ