public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Question regarding rootfile warning "Error! '/aarch64' in rootfiles files found!"
Date: Thu, 09 Dec 2021 19:54:38 +0000	[thread overview]
Message-ID: <F8734CC6-50A2-4906-A440-59801346A6F6@ipfire.org> (raw)
In-Reply-To: <50d27cdb-d2aa-e4da-7b22-90cb453a545f@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

Hello,

> On 9 Dec 2021, at 19:52, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello Michael,
> 
> thanks for your reply.
> 
> As far as I understood the issue, make.sh checking for architecture names in paths
> is fine, but in filenames (such as x86_64.h), it is not. A whitelist approach would
> not be necessary in this case, it only needs to ignore the file name of a given path
> while checking for architecture names.

In this case it is, but generally it isn’t.

The check was built for Perl and Python modules that carry the architecture name in their paths. For Perl that is usually a directory and Python has it in the filename.

The idea is to catch any build problems if someone builds it on one architecture and doesn’t notice.

I never notice.

I do not think there is a technical solution to this.

-Michael

> Does this make sense? Or did I misunderstood you?
> 
> Thanks, and best regards,
> Peter Müller
> 
> 
>> Hello,
>> 
>> What is the bug for? The check does exactly what it is supposed to do.
>> 
>> We either need to get rid of it entirely because it has false positives or we need to have a whitelist.
>> 
>> Is that a solution that you had in mind?
>> 
>> -Michael
>> 
>>> On 9 Dec 2021, at 19:39, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>>> 
>>> P.S.: Bug #12743 (https://bugzilla.ipfire.org/show_bug.cgi?id=12743) has been raised for this.
>>> 
>>> Should anybody have spare time to work on it, please feel free to do so. :-)
>>> 
>>>> Hello Adolf,
>>>> 
>>>> thanks for your reply.
>>>> 
>>>>> How should we deal with the situation where a source file filename happens to use an architecture name the same as an IPFire name.
>>>> 
>>>> I also think this is a false positive, though it surprises me we never came across this
>>>> scenario all the years before. Either way, make.sh (or whatever's doing this check) needs
>>>> to be updated to ignore such cases.
>>>> 
>>>> I'll file a bug for this later...
>>>> 
>>>> Thanks, and best regards,
>>>> Peter Müller
>>>> 
>> 


  reply	other threads:[~2021-12-09 19:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-05 10:47 Peter Müller
2021-12-05 11:45 ` Adolf Belka
2021-12-09 19:31   ` Peter Müller
2021-12-09 19:39     ` Peter Müller
2021-12-09 19:41       ` Michael Tremer
2021-12-09 19:52         ` Peter Müller
2021-12-09 19:54           ` Michael Tremer [this message]
2021-12-15 14:06             ` Adolf Belka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F8734CC6-50A2-4906-A440-59801346A6F6@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox