Re: Is git obligatory?
On Fri, May 31, 2019 at 02:36:58AM +0200, Albert van der Horst wrote: > > > Do I interpret that out of context or does this mean > > > that nowadays neither a CVS repository nor a > > > source tarbal are acceptable starting points for a Debian package? > > You still need to create the orig tarball somehow. Nothing has changed > > in > > this regard. > > That I know. The question is if there is a tarball floating around > somewhere with a program source, can a Debian Developer make it > into a package or are there additional hard demands placed on > the tarball apart from copyright issues. There is no definite yes or no answer. There are indeed additional quality requirements for the software but this doesn't seem related to the inital question that mentioned git ans CVS. You can definitely package a DFSG-free software using a published tarball. -- WBR, wRAR signature.asc Description: PGP signature
Re: Looking for a sponsor
what happened with that ? El jue., 2 de may. de 2019 a la(s) 05:24, escribió: > > Hello everyone, > > (TLWR: > I have worked on my fisrt package, and am looking for a DD/DM to check it > and eventually sponsor it into unstable.) > > Some time ago I had to compile the latest version of Heimadll ( > www.glassechidna.com.au/heimdall/), because the packaged version wasn't > compatible with my device. I thought it was a good occasion for a first > contribution to Debian, since it is a simple enough package (2 binaries). > > The package is currently maintained by Steve Langasek, but it has not seen > updates for ~3 years while upstream had a new release ~ 2 years ago, and > Steve has not answered my messages to the mail address mentioned on his > packager page, so I thought it okay to bypass him there. > > I've gone through the "Debian new maintainer's guide", took what I could > from Steve's package, and I think I now have a decent package, or at least > an upgrade from the current one. That being said, there are a few things > that I am not too sure about, and I certainly made a few errors since this > is my first package and there was many things I barely understood well > enough to have it look like it works. > > So if someone here has some time and the motivation to go through what I > did, correct it and maybe sponsor it into unstable, please reply to me so I > can send you what I did. > > Thank you for reading. > > > >
Re: Is git obligatory?
El jue., 30 de may. de 2019 a la(s) 20:37, Albert van der Horst ( alb...@spenarnc.xs4all.nl) escribió: > Andrey Rahmatullin schreef op 2019-05-30 18:34: > > "An ITP relates to packaging a git repo for Debian" ITP = Intent to packaging what ever are the source, means its a try to made the packagin.. but not officially until that packagin are in good shape.. > > > That I know. The question is if there is a tarball floating around > somewhere with a program source, can a Debian Developer make it > into a package or are there additional hard demands placed on > in nomadays there's no CVS and internet was not so popular (neither accesible) .. so then git, repository are not (was not) the main source of packagin in nomadays in the first era, internet was not a so popular resource.. and the disks and compat disk was the main resources of distribution.. today the network and internet are the main resource.. but in essence.. maybe in the future that behaviour of make a "oring" will dessapier.. as i know.. ebuils and apk grab directly the sources from the repositories > the tarball apart from copyright issues. > (Of course a Debian Developer will not touch a program that he considers > not to be of sufficient quality, such as rejecting programs without a > maintainer or such that are not under source control, but that > is a subjective call.) > > Groetjes Albert > > -- > Suffering is the prerogative of the strong, the weak -- perish. > Albert van der Horst > >
Re: Is git obligatory?
Andrey Rahmatullin schreef op 2019-05-30 18:34: Do I interpret that out of context or does this mean that nowadays neither a CVS repository nor a source tarbal are acceptable starting points for a Debian package? You still need to create the orig tarball somehow. Nothing has changed in this regard. That I know. The question is if there is a tarball floating around somewhere with a program source, can a Debian Developer make it into a package or are there additional hard demands placed on the tarball apart from copyright issues. (Of course a Debian Developer will not touch a program that he considers not to be of sufficient quality, such as rejecting programs without a maintainer or such that are not under source control, but that is a subjective call.) Groetjes Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Re: Bug#883702: RFS: lina/5.3.0-1 ( #859130 ITP: lina -- iso-compliant Forth interpreter and compiler )
On Thu, May 30, 2019 at 07:21:04PM +0200, Albert van der Horst wrote: > > Yes it will. But a total rewrite of a Forth compiler is not much effort. > The 32 bit arm compiler was a couple of months of spare time, in fact > a port of the i86 assembler system. > The 64 bit port is a tad more spectacular. > Both are at https://github.com/albertvanderhorst/ciforth/releases git > I received an orange pi 1+ (64 bit arm) in the mail. It was some trouble to > get a linux installed on it. That succeeded about a week ago. > This is the first change that I checked in, mark the date: > " > revision 6.63 > date: 2019-05-21 21:16:03 +; author: albert; state: Exp; lines: +12 > -9 And what is the git commit hash?? ( e.g. https://github.com/albertvanderhorst/ciforth/commit/12c4697198b0c3113a79ff5e249e4bc0be8cea9a has git commit hash 12c4697198b0c3113a79ff5e249e4bc0be8cea9a ) > Macro cleanup. Removed x86 remainders, i.a. LODS in ciarm.gnr. > Added lina64.cfg and width64.m4 to accomodate the 64 bit assembler on > the Orange 1+. > " > And no I did not learn the Aarch64 7000 page assembler manual by heart > beforehand. > > Forth is a different world. If the RISC V systems come, bring it on! > > Now if in hindsight someone decides that lina may be valuable to Debian, > please contact me. Nobody responded to my RFS. :-( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859130#18 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883702#51 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859130#83 Groeten Geert Stappers -- Leven en laten leven signature.asc Description: PGP signature
Bug#929773: RFS: wf-recorder/0.1-1 ITP
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "wf-recorder" * Package name : wf-recorder Version : 0.1-1 Upstream Author : Ilia Bozhinov * Url : https://github.com/ammen99/wf-recorder * Licenses : Expat Programming Lang : C Section : x11 wf-recorder is a utility program for screen recording of wlroots-based compositors (more specifically, those that support wlr-screencopy-v1 and xdg-output). Its dependences are ffmpeg, wayland-client and wayland-protocols. It builds those binary packages: * wf-recorder To access further information about this package, visit the following URL: https://mentors.debian.net/package/wf-recorder Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wf-recorder/wf-recorder_0.1-1.dsc Alternatively, you can access package debian/ directory via git from URL: https://salsa.debian.org/bisco-guest/wf-recorder.git More information about wf-recorder can be obtained from https://github.com/ammen99/wf-recorder cheers, Birger
Re: Bug#883702: RFS: lina/5.3.0-1 ( #859130 ITP: lina -- iso-compliant Forth interpreter and compiler )
Adam Borowski schreef op 2018-06-29 19:16: I refrained from answering at the time. I would have given the same answer as now, but now I've something to back it up. On Fri, Jun 29, 2018 at 12:14:12PM +0200, Albert van der Horst wrote: Adam Borowski schreef op 2017-12-21 20:26: > 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. > Your choice of a language to code a compiler is... interesting. But > then, at least it's not node.js, php or python :) A compiler writer has no choice, all compilers are written in assembler (and itself). php and python are merely libraries written in c. Besides c there are very few compilers around. This is one. I haven't yet seen any other compiler written in assembler (I'm a part of the generation that played with decomissioned punched tape in kindergarten but didn't get to use such computers myself). It's a pretty bad idea -- it takes many times as long to write the same program in assembler than in a There is a fundamental misunderstanding here. Everybody can avoid using assembler and use a high level language ... except the writer of the high level language. And if you write your compiler in c, well I could scoff and say that you're just writing a c-library, but let me comment that you're dependant on a 2.2 million lines house of cards, that is totally not under your control. Writing in assembler doesn't even make you dependant on an assembler. Forth folks are use to writing their own assembler, then use that to write the compiler. https://github.com/albertvanderhorst/ciasdis compiled language, and the program is not portable. It looks like arm will dethrone x86 pretty soon -- the architecture is way more efficient, Intel no longer has a process advantage, and even the niche of high-end servers is getting assaulted. Then there's coming riscv with lofty goals of kicking So you say that because my compiler has been written in i86 it is likely not portable. Debian folks tend to fill that in as "configure , then make must work". There is more to it, because at least that presuppose a working gcc. But lina is portable to an extent, but the portability of a compiler is by definition limited. The argument is that "you'll be troubled when the arm comes" Well the arm architecture has been added to lina, and with quite much less effort probably than gcc. If portability is measured in time to port, lina is more portable than gcc. Note that we are talking about the compiler. The application programs are as portable as c-programs are. out both arm and x86, and a list of backing companies that may actually accomplish that. Yet your compiler is stuck with i386 while a C program wouldn't care about the platform. It's easy to change code generation (and producing bytecode for LLVM or such would grant instant support for a wide array of targets) but porting the compiler itself would need a total rewrite. Yes it will. But a total rewrite of a Forth compiler is not much effort. The 32 bit arm compiler was a couple of months of spare time, in fact a port of the i86 assembler system. The 64 bit port is a tad more spectacular. Both are at https://github.com/albertvanderhorst/ciforth/releases I received an orange pi 1+ (64 bit arm) in the mail. It was some trouble to get a linux installed on it. That succeeded about a week ago. This is the first change that I checked in, mark the date: " revision 6.63 date: 2019-05-21 21:16:03 +; author: albert; state: Exp; lines: +12 -9 Macro cleanup. Removed x86 remainders, i.a. LODS in ciarm.gnr. Added lina64.cfg and width64.m4 to accomodate the 64 bit assembler on the Orange 1+. " And no I did not learn the Aarch64 7000 page assembler manual by heart beforehand. Forth is a different world. If the RISC V systems come, bring it on! Now if in hindsight someone decides that lina may be valuable to Debian, please contact me. Nobody responded to my RFS. :-( Meow! Groetjes Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
Re: Is git obligatory?
Please stop replying to old mails to start a new thread, use the "New email" feature of your client instead. On Thu, May 30, 2019 at 05:59:27PM +0200, Albert van der Horst wrote: > In an old message Geert Stappers made the following remark > (in Dutch so I'll translate) > > "An ITP relates to packaging a git repo for Debian" No idea what it means without context, TBH. > Do I interpret that out of context or does this mean > that nowadays neither a CVS repository nor a > source tarbal are acceptable starting points for a Debian package? You still need to create the orig tarball somehow. Nothing has changed in this regard. -- WBR, wRAR signature.asc Description: PGP signature
Is git obligatory?
In an old message Geert Stappers made the following remark (in Dutch so I'll translate) "An ITP relates to packaging a git repo for Debian" Do I interpret that out of context or does this mean that nowadays neither a CVS repository nor a source tarbal are acceptable starting points for a Debian package? Groetjes Albert -- Suffering is the prerogative of the strong, the weak -- perish. Albert van der Horst
