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
