Bug#883702: RFS: lina/5.3.0-1 ( #859130 ITP: lina -- iso-compliant Forth interpreter and compiler )
Control: owner -1 !
On Thu, Dec 21, 2017 at 08:26:45PM +0100, Adam Borowski wrote:
> On Wed, Dec 06, 2017 at 05:51:50PM +0100, Albert van der Horst wrote:
> > * Package name : lina
> > Version : 5.3.0-1
>
> Hi! I for one don't know the slightest bit about Forth, but as no one has
> taken this RFS, I can review packaging only -- which, while not ideal, is
> not a show stopper for uploading.
Adam Borowski For The Win yeah
Seen doing him many sponsored uploads.
I want to do this one, sponsoring upload of forth compiler "lina".
> I'm afraid the package fails to build,
> you need to add fasm to Build-Depends.
Yes, we ((Albert & Geert) , who did meet 2017-12-21 ) can confirm
that fasm needs to be added to Build-Depends.
About the "no packages needs to be build" we did see last night.
That is because 'Architecture: i386' in debian/control
and doing `debuild -uc -us` on an amd64 computer.
Having 'Architecture: amd64 i386' builds a package on amd64.
> > Changes since the last upload:
> >
> > * Initial release (Closes: #859130)
> > * Added a Makefile
> > * Administrative defects detected by lintian
>
> Usually, the first release has a changelog with nothing but "initial
> release" in it -- there are no changes to report. Cases where it's
> reasonable to do otherwise are:
> 1. existing out-of-Debian .deb packaging
> 2. a truly noteworthy remark
> Neither of additional entries match these criteria: adding a makefile is
> part of the packaging.
>
> Also, "defects detected by lintian" means nothing. What matters is _what_
> needed to be fixed, not what tool was used to spot the defect.
>
Would it be okay to do another upload to mentors.debian.net for 5.3.0-1 ?
(a next upload to debian would have an incremented debian version ( e.g. 5.3.0-2 ) )
> Before we even start, it would be nice if you could address the rest of
> issues detected by lintian -- an automated system saves a lot of human time.
Precious time of reviewers. (and yes, it does cost precious time from
the maintainer ( hey it gets higher quality ))
> Also, is this the real source (AKA, "preferred form for modification")?
> Assembler is a valid language, generated assembler (nor generated shell,
> generated C, ...) is not. Some parts say about a configuration process
> that, as it seems to me, expands variables for a particular platform.
<snippet from="ci86.lina.fas of the lina.orig.tar.gz at mentors.debian.net">
; If this is a configured assembly file, it should be accompanied with configured
; documentation (texinfo, ps, html.)
; WITHOUT THE DOCUMENTATION: GIVE UP! GET THE REAL THING!
; You have a configured system, if there are NO curly brackets on the next line.
;
;
; Configuration of this particular version:
; 32-bits protected mode
; running under Linux ; with native forth I/O
</snippet>
So yes, I have the feeling that I'm dealing with generated assembly.
The .orig.tar.gz does have ci86.lina.fas
I wonder what generated it and from what.
@Albert: Would you please elaborate?
> Your choice of a language to code a compiler is... interesting. But then,
> at least it's not node.js, php or python :)
Yes, the transmitted smiley is recieved as a smiley.
Groeten
Geert Stappers
--
Leven en laten leven
Reply to: