bugGNU nano - Bugs: bug #51061, build failure for 2.8.3: No rule...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #51061: build failure for 2.8.3: No rule to make target 'nanorc.5', needed by 'nanorc.5.html'

Submitter:  Vicente Olivert Riera <vriera>
Submitted:  Thu 18 May 2017 04:08:24 PM UTC
   
 
Severity:  5 - Blocker Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Sun 21 May 2017 09:30:19 AM UTC, comment #10: 

The fix has been released in 2.8.4.  Thanks again for reporting.

Benno Schulenberg <bens>
Group administrator
Fri 19 May 2017 03:31:54 PM UTC, comment #9: 

A hash is easier for checking integrity, yes.  But... can you change a byte of a gzipped tarball and still decompress to something valid?  And of an xz compressed tarball?  And how about lzipped?  Won't these decompressors flag an error in most cases?

Anyway, integrity of the tarball doesn't tell you much -- if someone breaks into the server and replaces the tarball, they can also replace the hash.  But the signature they cannot replace (at least, that's the theory).  So the signature is much stronger: when it verifies okay, it not only tells you that the data is intact, but also that the tarball comes from me (or at least: from the same person that also made the last ten or so tarballs).

So, if people are worried about integrity, I'd rather push them to using gpg to verify the signature.  And for a build tool, easiness or quickness should not be an argument: the highest possible amount of confidence should have priority there.

Benno Schulenberg <bens>
Group administrator
Fri 19 May 2017 10:16:26 AM UTC, comment #8: 

Thanks for pushing the fix.

Regarding the sha256, is not that is better or worse. Is just easier for checking the tarball integrity.

Is not the same just running "sha256sum nano-2.8.4.tar.gz" and compare the output to a published sha256 hash, than having to download and import a public key, download the signature, and then check the tarball integrity using the signature.

For normal users who download the tarball manually and want to check its integrity, is slightly easier the first method. But for automatic tools or package managers, is much easier just having the public hashes in a plain text file and simply compare them after downloading the tarball. You don't need the automatic tool or package manager to download any key, import it, then download a signature file, do the checks, and then clean everything.

Vicente Olivert Riera <vriera>
Fri 19 May 2017 10:09:49 AM UTC, comment #7: 

Hm...  How is a sha256 hash better than a gpg signature?

A fix for the wrong logic has been pushed: a32d21c7.

Benno Schulenberg <bens>
Group administrator
Fri 19 May 2017 09:35:19 AM UTC, comment #6: 

<off topic>

While we are at it, could a sha256 hash be published when a new tarball is released? :P

</off topic>

Vicente Olivert Riera <vriera>
Fri 19 May 2017 09:31:03 AM UTC, comment #5: 

True, Buildroot (the environment where I'm building nano) passes --disable-nanorc to the configure script. Sorry for omitting that information.

Regarding the Reported-by tag, yes, why not:

Reported-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>

Thanks.

Vicente Olivert Riera <vriera>
Fri 19 May 2017 09:27:33 AM UTC, comment #4: 

But I have GNU Make 4.2.1 too, and after unpacking the 2.8.3 tarball and running './configure && make && make install', there was nothing wrong...  Ah, but you configured with --disable-nanorc...!  That was essential information.  :)

Fixed in git (not pushed yet).  Do you wish to see your imgtec or your gentoo address in the Reported-by tag?

Benno Schulenberg <bens>
Group administrator
Fri 19 May 2017 08:02:53 AM UTC, comment #3: 

Hello Benno,

yes, the doc/nanorc.5 file is missing :-)

My make is GNU make 4.2.1, from Gentoo. Nothing weird here ¯\_(ツ)_/¯

Regards,

Vincent

Vicente Olivert Riera <vriera>
Thu 18 May 2017 05:38:27 PM UTC, comment #2: 

Ouch!  Forget my questions.  The doc/nanorc.5 file is not in the tarball...  During the conversion from DISABLE to ENABLE I have overlooked something, apparently.  There will be a 2.8.4 soon.

You have a strange make, though.  It shouldn't /need/ to make nanorc.5.html, because it already exists.  Hmm... or maybe your make considers an absent file to infinitely new whereas GNU make considers it be infinitely old?  Seen that way, I think your make is better.

Benno Schulenberg <bens>
Group administrator
Thu 18 May 2017 05:25:02 PM UTC, comment #1: 

Thanks for reporting.  Please attach the produced doc/Makefile (without any extension).  What configure options did you use?  Was this during 'make' or during 'make install'?

Benno Schulenberg <bens>
Group administrator
Thu 18 May 2017 04:08:24 PM UTC, original submission:  

[...]
Making all in doc
make[3]: Entering directory '/br/output/build/nano-2.8.3/doc'
make[3]: * No rule to make target 'nanorc.5', needed by 'nanorc.5.html'.  Stop.

Vicente Olivert Riera <vriera>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by vriera (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-05-21 bens Open/ClosedOpen Closed
        Summarynano-2.8.3 build failure: No rule to make target 'nanorc.5', needed by 'nanorc.5.html' build failure for 2.8.3: No rule to make target 'nanorc.5', needed by 'nanorc.5.html'
    2017-05-19 bens StatusIn Progress Fixed
    2017-05-18 bens StatusNone In Progress
    2017-05-18 bens Severity3 - Normal 5 - Blocker
        Assigned toNone bens

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code