Re: length of Debian copyright files
On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote: > Debian: > https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98.0-1 > plus we ship the LGPL in base-files' common-licenses. This kind of insanity is actually why I refuse to use the machine-parseable copyright format. Nobody cares that some file somewhere deep down in the source tree is perhams maybe somewhat more permissive than the license on the whole. If the license on the whole is a copyleft license, then that file somewhere deep down is made available to you as that copyleft license, due to "copyleft". Anything else is insanity, and I refuse to waste my time on it. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Re: trends.debian.net updated
On Sat, Apr 04, 2020 at 08:03:09PM +0200, Ole Streicher wrote: > Adam Borowski writes: > > Idea: perhaps we could make no unrestricted (maintainer, team, or QA) upload > > for 10 years a RC bug on its own? That threshold could then be gradually > > reduced to eg. 5 years, as worst offenders get fixed. > > One could deprecate old Standards-Version and require a version not that > was not superceded for more than five years. That's not what Standards-Version means. You don't get to say "I know my package does not comply with current Policy, but the Standards-Version claims an old version of Policy so that's fine". You must always be compliant with current policy (in unstable), and if policy changes in ways that apply to your package, you need to update it. One of my packages, logtool, hasn't seen an upstream change since the early naughties, and as a result there are 7 years between logtool 1.2.8-8 and logtool 1.2.8-9. That however didn't mean it wasn't maintained, just that it didn't need any update in 7 years. The only reason for Standards-Version to exist is so that when you or whoever comes after you look at things a few days/weeks/months/years down the line, you know what has changed in Policy since it was last touched and can use upgrading-checklist.txt -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Re: trends.debian.net updated
On Fri, Apr 03, 2020 at 10:41:55PM +0200, Lucas Nussbaum wrote: > Hi, > > https://trends.debian.net/ was just updated (with data until April 1st). There is a significant bump in the number of co-maintained packages during the buster release cycle. It is not at all clear to me what happened there. Do you have any idea? -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Re: length of Debian copyright files
Quoting Wouter Verhelst (2020-04-11 10:36:44) > On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote: > > Debian: > > https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98.0-1 > > plus we ship the LGPL in base-files' common-licenses. > > This kind of insanity is actually why I refuse to use the > machine-parseable copyright format. > > Nobody cares that some file somewhere deep down in the source tree is > perhams maybe somewhat more permissive than the license on the whole. If > the license on the whole is a copyleft license, then that file somewhere > deep down is made available to you as that copyleft license, due to > "copyleft". > > Anything else is insanity, and I refuse to waste my time on it. You seem to conflate two issues: a) writing debian/copyright in a machine-parsable format b) writing debian/copyright with too much detail included Please use the machine-readable format because then machines can help us. If you find it insane how detailed machine-readable format _can_ be, then please use the format _without_ the insanity. You can have a) without b) - e.g. like this: Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: GTK Source: https://download.gnome.org/sources/gtk/ License: LGPL-2.1+ Files: * Copyright: The GTK Team and others License: LGPL-2+ and LGPL-2.1+ Comment: Specific authors omitted (unneeded for this license, and list is long). If ftp-masters then file bugreports about missing or too vague entries, you lower that to lower severity (if you are confident that it really is) and take it to the tech-CTTE if that causes a dispute. If ftp-masters then reject the package with missing or too vague entries being their reason, you bring that up here on -devel, because that's a different praxis than they currently give the impression that they are follow (nowadays - how they did in the past is irrelevant here). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: length of Debian copyright files
On Sat, 11 Apr 2020 at 11:29:22 +0200, Jonas Smedegaard wrote: > You seem to conflate two issues: > > a) writing debian/copyright in a machine-parsable format > b) writing debian/copyright with too much detail included > > Please use the machine-readable format because then machines can help > us. If you find it insane how detailed machine-readable format _can_ be, > then please use the format _without_ the insanity. I agree with this part: the machine-readable format should just be an alternative encoding for whatever you would say (with whatever high or low level of detail you are using) in a plain-text copyright file. However: > Files: * > Copyright: The GTK Team and others > License: LGPL-2+ and LGPL-2.1+ > Comment: > Specific authors omitted (unneeded for this license, and list is long). My understanding is that the ftp team would consider this to be a bug, and possibly a RC one, because: - the permissive licenses have been omitted (it should say "LGPL-2+ and LGPL-2.1+ and Expat and (Expat or unlicense) and ..."); - not all of the copyright notices that exist in the source code have been copied into the copyright file I would be delighted to be told I'm wrong about that by someone who speaks for the ftp team, but I'm reluctant to get software that I want in Debian kicked out of Debian by using its acceptance or rejection as an oracle to discover the ftp team's policy. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956286 was opened at RC severity two days ago, saying that folks' copyright file is RC-buggy precisely because it does not replicate a list of copyright statements from the source code. smcv
Re: length of Debian copyright files
Quoting Simon McVittie (2020-04-11 13:49:53) > On Sat, 11 Apr 2020 at 11:29:22 +0200, Jonas Smedegaard wrote: > > You seem to conflate two issues: > > > > a) writing debian/copyright in a machine-parsable format > > b) writing debian/copyright with too much detail included > > > > Please use the machine-readable format because then machines can > > help us. If you find it insane how detailed machine-readable format > > _can_ be, then please use the format _without_ the insanity. > > I agree with this part: the machine-readable format should just be an > alternative encoding for whatever you would say (with whatever high or > low level of detail you are using) in a plain-text copyright file. > > However: > > > Files: * > > Copyright: The GTK Team and others > > License: LGPL-2+ and LGPL-2.1+ > > Comment: > > Specific authors omitted (unneeded for this license, and list is > > long). > > My understanding is that the ftp team would consider this to be a bug, > and possibly a RC one, because: > > - the permissive licenses have been omitted (it should say > "LGPL-2+ and LGPL-2.1+ and Expat and (Expat or unlicense) and ..."); > > - not all of the copyright notices that exist in the source code have > been copied into the copyright file > > I would be delighted to be told I'm wrong about that by someone who > speaks for the ftp team, but I'm reluctant to get software that I want > in Debian kicked out of Debian by using its acceptance or rejection as > an oracle to discover the ftp team's policy. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956286 was opened at > RC severity two days ago, saying that folks' copyright file is > RC-buggy precisely because it does not replicate a list of copyright > statements from the source code. So you expect RC bugreports from ftp-masters, and fear NEW rejection. Me too. But those are different actions. I do not _fear_ RC bugs from ftp-masters: Those are transparent and open for interpretation. What I fear from ftp-masters is lack of transparency and lack of dialogue and (no doubt unintended only perceived therefore quoted) "punishment" by further delays of yet another NEW processing. This is my understanding of current ftp-master procedures (from earlier in this same thread, as a reply to you): Quoting Sean Whitton (2020-03-25 20:20:59) > I am not sure that it is quite right to understand the FTP Team as > interpreting that particular part of Policy (anymore than any reader > of Policy is involved in intrepreting it), because Policy currently > requires strictly more than the FTP Team require. > > For example, if a package's license does not require all copyright > notices to be included in binary distributions, and some are missing, > we may well ACCEPT and file an RC bug, citing Policy. [...] > I do not believe that you would get a REJECT where the combination > involves a single license in the License: field. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#956453: ITP: libcyaml -- Schema-based YAML parsing and serialisation
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libcyaml Version : 1.0.2 Upstream Author : Michael Drake * URL : https://github.com/tlsa/libcyaml * License : ISC Programming Lang: C Description : Schema-based YAML parsing and serialisation LibCYAML is a C library for reading and writing structured YAML documents. The fundamental idea behind CYAML is to allow applications to construct schemas which describe both the permissible structure of the YAML documents to read/write, and the C data structure(s) in which the loaded data is arranged in memory. I will need a sponsor for this and I can maintain it after it has been uploaded and accepted. -- Regards Sudip
Bug#956455: ITP: smart-open -- utils for streaming large files
Package: wnpp Severity: wishlist Owner: Sao I Kuan * Package name: smart-open Version : 1.11.1 Upstream Author : Radim Rehurek * URL : https://github.com/piskvorky/smart_open * License : Expat Programming Lang: Python Description : utils for streaming large files smart-open is a library for efficient streaming of very large files from/to storages such as HDFS, WebHDFS, HTTP, HTTPS, SFTP, or local filesystem. It supports transparent, on-the-fly (de-)compression for a variety of different formats (gzip, bz2, etc.). This package is a dependency of idseq-bench (#956033)[0]. [0] https://bugs.debian.org/956033 This package is a work which is part of COVID-19 BioHackathon[1,2]. The package will be team maintained (med-team). [1] https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/Covid-19-hackathon [2] https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/COVID-19-Hackathon-packages-needing-work
Re: length of Debian copyright files
On Sat, Apr 11, 2020 at 11:29:22AM +0200, Jonas Smedegaard wrote: > Quoting Wouter Verhelst (2020-04-11 10:36:44) > > On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote: > > > Debian: > > > https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98.0-1 > > > plus we ship the LGPL in base-files' common-licenses. > > > > This kind of insanity is actually why I refuse to use the > > machine-parseable copyright format. > > > > Nobody cares that some file somewhere deep down in the source tree is > > perhams maybe somewhat more permissive than the license on the whole. If > > the license on the whole is a copyleft license, then that file somewhere > > deep down is made available to you as that copyleft license, due to > > "copyleft". > > > > Anything else is insanity, and I refuse to waste my time on it. > > You seem to conflate two issues: > > a) writing debian/copyright in a machine-parsable format > b) writing debian/copyright with too much detail included > > Please use the machine-readable format because then machines can help > us. If you find it insane how detailed machine-readable format _can_ be, > then please use the format _without_ the insanity. My point is that the machine-readable format is being "abused" to deep-check the copyright status of all the files, and to reject stuff/file bugs/... based on that. Yes, a machine-readable copyright format is useful for our users. It is, however, not useful if it is being used to inspect packages and kick maintainers for not doing useless busywork. It is my belief that this is actually happening, and therefore I don't want to do the machine-readable copyright format. People who care enough about the license of a piece of software that they *do* need to know *all* these details can do the damn busywork themselves; I will not. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#956456: ITP: idseq-dag -- Pipeline engine for IDseq (Infectious Disease Sequencing Platform)
Package: wnpp Severity: wishlist Owner: Emmanuel Arias * Package name: idseq-dag Version : 4.2.2 Upstream Author : IdSeq Team @ Chan Zuckerberg Initiative * URL : https://github.com/chanzuckerberg/idseq-dag * License : MIT Programming Lang: Python Description : Pipeline engine for IDseq (Infectious Disease Sequencing Platform) idseq_dag is the pipeline execution engine for idseq (see idseq.net). It is a pipelining system that implements a directed acyclic graph (DAG) where the nodes (steps) correspond to individual python classes. The graph is defined using JSON. . The pipeline would be executed locally with local machine resources. idseq-dag could be installed inside a docker container and run inside the container. . This is package for COVID-19 Hackathon. This package can be maintained under med-team umbrella.
Bug#956459: ITP: python3-favicon -- Async favicon fetcher
Package: wnpp Severity: wishlist Owner: Henry-Nicolas Tourneur * Package name: python3-favicon Version : 0.1.1 Upstream Author : Bilal Elmoussaoui * URL : https://pypi.org/project/pyfavicon/ * License : MIT Programming Lang: Python Description : Async favicon fetcher PyFavicon is a Python library for asynchronously fetching favicons. Extra information on this packaging: - I wish to maintain this package together with DPMT - This library is a dependency for the authenticator gnome app which I would like to package as well once dependencies are resolved.
Re: trends.debian.net updated
On Sat, Apr 11, 2020 at 11:10:48AM +0200, Wouter Verhelst wrote: > On Fri, Apr 03, 2020 at 10:41:55PM +0200, Lucas Nussbaum wrote: > > https://trends.debian.net/ was just updated (with data until April 1st). > > There is a significant bump in the number of co-maintained packages > during the buster release cycle. It is not at all clear to me what > happened there. > > Do you have any idea? My assumption is that the deprecation of alioth lead many "team" formed by 1 or 2 people to be replaced by simply comaintained packages. That, together with the the @packages.d.o maintainer address, I reckon those might also be considered "comaintained" instead of "team maintained". -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: length of Debian copyright files
Quoting Wouter Verhelst (2020-04-11 16:47:13) > On Sat, Apr 11, 2020 at 11:29:22AM +0200, Jonas Smedegaard wrote: > > Quoting Wouter Verhelst (2020-04-11 10:36:44) > > > On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote: > > > > Debian: > > > > https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98.0-1 > > > > plus we ship the LGPL in base-files' common-licenses. > > > > > > This kind of insanity is actually why I refuse to use the > > > machine-parseable copyright format. > > > > > > Nobody cares that some file somewhere deep down in the source tree > > > is perhams maybe somewhat more permissive than the license on the > > > whole. If the license on the whole is a copyleft license, then > > > that file somewhere deep down is made available to you as that > > > copyleft license, due to "copyleft". > > > > > > Anything else is insanity, and I refuse to waste my time on it. > > > > You seem to conflate two issues: > > > > a) writing debian/copyright in a machine-parsable format > > b) writing debian/copyright with too much detail included > > > > Please use the machine-readable format because then machines can > > help us. If you find it insane how detailed machine-readable format > > _can_ be, then please use the format _without_ the insanity. > > My point is that the machine-readable format is being "abused" to > deep-check the copyright status of all the files, and to reject > stuff/file bugs/... based on that. Abuse is seriously bad. Not sure what you mean by "abuse" in quotes, though, so let me try break it apart. Please tell me if I totally missed what you tried to say (I genuinely want to understand, not mock). Real bugs should be identified and reported, and using machine-readable data to aid in that is great. Or do you disagree with that? Filing bugreports for non-bugs is wrong, and doing it in automated ways (e.g. by use of machine-readable data) is abuse (unquoted) and should be stopped - regardless of who does it. If that's what you are talking about, then could you perhaps point at some examples that might help identify a pattern for countering such abuse? Since it keeps coming up that ftpmasters rejects for wrong reasons: Assuming good faith, I can only imagine it be _rumors_ only, stemming from a) clumsy behaviours in past dark ages and/or b) misinterpretation of rejection messages. Therefore: Please if anyone can shed more light on such rumors(!) please do - e.g. share recent(!) rejection emails showing it is fact, not rumor. > Yes, a machine-readable copyright format is useful for our users. It > is, however, not useful if it is being used to inspect packages and > kick maintainers for not doing useless busywork. It is my belief that > this is actually happening, and therefore I don't want to do the > machine-readable copyright format. > > People who care enough about the license of a piece of software that > they *do* need to know *all* these details can do the damn busywork > themselves; I will not. My point is that writing copyright file (as short as possible, and) machine-readable is *not* busywork. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: trends.debian.net updated
Quoting Mattia Rizzolo (2020-04-11 17:20:48) > On Sat, Apr 11, 2020 at 11:10:48AM +0200, Wouter Verhelst wrote: > > On Fri, Apr 03, 2020 at 10:41:55PM +0200, Lucas Nussbaum wrote: > > > https://trends.debian.net/ was just updated (with data until April 1st). > > > > There is a significant bump in the number of co-maintained packages > > during the buster release cycle. It is not at all clear to me what > > happened there. > > > > Do you have any idea? > > My assumption is that the deprecation of alioth lead many "team" formed > by 1 or 2 people to be replaced by simply comaintained packages. > That, together with the the @packages.d.o maintainer address, I reckon > those might also be considered "comaintained" instead of "team > maintained". The introduction of the Salsa "debian" area - with its accompanying explicit rules of being more team-ish than the similar area in Alioth - was indeed a game changer for many packages which I had previously maintained in smaller teams. I guess (and hope) that's the case for others too. Not sure how, but it might be possible to check that thoery if possible to gather statistics of how many packages was in the Alioth debian area compared to the Salsa debian area. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: length of Debian copyright files
Hello, On Sat 11 Apr 2020 at 12:49PM +01, Simon McVittie wrote: >> Files: * >> Copyright: The GTK Team and others >> License: LGPL-2+ and LGPL-2.1+ >> Comment: >> Specific authors omitted (unneeded for this license, and list is long). > > My understanding is that the ftp team would consider this to be a bug, > and possibly a RC one, because: > > - the permissive licenses have been omitted (it should say > "LGPL-2+ and LGPL-2.1+ and Expat and (Expat or unlicense) and ..."); Policy says it's an RC bug: "Every package must be accompanied by a verbatim copy of its distribution license in the file /usr/share/doc/package/copyright." (§2.3 and elsewhere). Whether the FTP Team would reject it depends on our judgement as to whether Debian would be violating any license terms by not including it in d/copyright; I can't say without looking at the package. The main factor is usually whether the files ends up in the binary package or not. In general, whether something is an RC bug is not really an FTP Team matter; that's Policy and the Release Team. When we file bugs based on NEW review, severities are chosen based on Policy. That's why we sometimes ACCEPT a package but then file an RC bug. > - not all of the copyright notices that exist in the source code have > been copied into the copyright file I've recently patched Policy to be much more specific and more inline with the FTP Team's consensus on this point. https://salsa.debian.org/dbnpolicy/policy/-/commit/0dc2eefc784d064b6398aa3f5233eb5b81b9e260 (not released yet) -- Sean Whitton signature.asc Description: PGP signature
Re: length of Debian copyright files
On Saturday, April 11, 2020 11:41:50 AM EDT Jonas Smedegaard wrote: > Quoting Wouter Verhelst (2020-04-11 16:47:13) > > > On Sat, Apr 11, 2020 at 11:29:22AM +0200, Jonas Smedegaard wrote: > > > Quoting Wouter Verhelst (2020-04-11 10:36:44) > > > > > > > On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote: > > > > > Debian: > > > > > https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98 > > > > > .0-1 > > > > > plus we ship the LGPL in base-files' common-licenses. > > > > > > > > This kind of insanity is actually why I refuse to use the > > > > machine-parseable copyright format. > > > > > > > > Nobody cares that some file somewhere deep down in the source tree > > > > is perhams maybe somewhat more permissive than the license on the > > > > whole. If the license on the whole is a copyleft license, then > > > > that file somewhere deep down is made available to you as that > > > > copyleft license, due to "copyleft". > > > > > > > > Anything else is insanity, and I refuse to waste my time on it. > > > > > > You seem to conflate two issues: > > > > > > a) writing debian/copyright in a machine-parsable format > > > b) writing debian/copyright with too much detail included > > > > > > Please use the machine-readable format because then machines can > > > help us. If you find it insane how detailed machine-readable format > > > _can_ be, then please use the format _without_ the insanity. > > > > My point is that the machine-readable format is being "abused" to > > deep-check the copyright status of all the files, and to reject > > stuff/file bugs/... based on that. > > Abuse is seriously bad. Not sure what you mean by "abuse" in quotes, > though, so let me try break it apart. Please tell me if I totally > missed what you tried to say (I genuinely want to understand, not mock). > > Real bugs should be identified and reported, and using machine-readable > data to aid in that is great. Or do you disagree with that? > > Filing bugreports for non-bugs is wrong, and doing it in automated ways > (e.g. by use of machine-readable data) is abuse (unquoted) and should be > stopped - regardless of who does it. If that's what you are talking > about, then could you perhaps point at some examples that might help > identify a pattern for countering such abuse? > > Since it keeps coming up that ftpmasters rejects for wrong reasons: > Assuming good faith, I can only imagine it be _rumors_ only, stemming > from a) clumsy behaviours in past dark ages and/or b) misinterpretation > of rejection messages. Therefore: Please if anyone can shed more light > on such rumors(!) please do - e.g. share recent(!) rejection emails > showing it is fact, not rumor. It's nonsense. There is zero difference in what's accepted or not based on if the machine readable copyright format is used. We may point out errors in use of the machine readable format, but it's not a criteria for rejection since its use is optional (note: there may have been occasional instances of this when combined with other problems). Scott K signature.asc Description: This is a digitally signed message part.
Re: length of Debian copyright files
Hello, On Sat 11 Apr 2020 at 11:56AM -04, Scott Kitterman wrote: > It's nonsense. There is zero difference in what's accepted or not based on if > the machine readable copyright format is used. We may point out errors in use > of the machine readable format, but it's not a criteria for rejection since > its use is optional (note: there may have been occasional instances of this > when combined with other problems). Yes, except when the misuse of the machine-readable format makes the copyright file say the wrong thing, or makes it too ambiguous. -- Sean Whitton signature.asc Description: PGP signature
Re: ITP: folium -- Make beautiful maps with Leaflet.js & Python
Yes, i see it, a debian developer says to me the option "We could be co maintainer and support it together if you want". I am interesting in that packages, perhaps it requires a lot work. I am newbie as debian maintainer but i am developer and i have used folium before. Regards. Javier Ruano. El sáb., 11 abr. 2020 17:50, Georges Khaznadar escribió: > Dear Javier, > > there is already one ITP for folium, see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942228 > > Best regards, Georges. > > Javier Ruano a écrit : > > * Package name: folium > > Version : 0.10.1 > > Upstream Author : Rob Story > > * URL : https://github.com/python-visualization/folium > > * License : MIT > > Programming Lang: Python, Javascript > > Description : Make beautiful maps with Leaflet.js & Python > > > > folium builds on the data wrangling strengths of the Python ecosystem > > and the mapping strengths of the Leaflet.js library. Manipulate your > > data in Python, then visualize it in a Leaflet map via folium. > > > > It is very useful for django programmers, and Physics and social > sciences. > > It is compatible with geopandas, which is in debian repository. > > I consider to maintain that with python-team and with pollo as sponsor. > > -- > Georges KHAZNADAR et Jocelyne FOURNIER > 22 rue des mouettes, 59240 Dunkerque France. > Téléphone +33 (0)3 28 29 17 70 > >
Bug#956463: ITP: golang-github-la5nta-wl2k-go -- A Winlink framework for Go
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org Package: wnpp Severity: wishlist Owner: Taowa Munene-Tardif * Package name: golang-github-la5nta-wl2k-go Version : 0.7.0-1 Upstream Author : Martin Hebnes Pedersen * URL : https://github.com/la5nta/wl2k-go * License : Expat Programming Lang: Go Description : A Winlink framework for Go. wl2k-go is a collection of Go packages implementing various parts needed to build a Winlink client. I wish to package wl2k-go so as to be able to package Pat. Thanks, Taowa Munene-Tardif -- Taowa Munene-Tardif taowa.ca Montréal
Bug#956478: ITP: ocaml-srt -- OCaml bindings for the Secure, Reliable, Transport protocol library
Package: wnpp Severity: wishlist Owner: Kyle Robbertze Control: block 956469 by -1 * Package name: ocaml-srt Version : 0.1.0 Upstream Author : Savonet Team * URL : https://www.liquidsoap.info * License : GPL-2 Programming Lang: OCaml Description : OCaml bindings for the Secure, Reliable, Transport protocol library This module provides OCaml bindings for the libsrt library. Secure Reliable Transport (SRT) is an open source transport technology that optimizes streaming performance across unpredictable networks, such as the Internet. This package will be maintained as part of the Debian Ocaml Team
Bug#956479: ITP: ocaml-sys-socket -- OCaml ctypes bindings to system-specific low-level socket structure and data-types
Package: wnpp Severity: wishlist Owner: Kyle Robbertze Control: block 956478 by -1 * Package name: ocaml-sys-socket Version : 1.0.0 Upstream Author : Romain Beauxis * URL : https://github.com/toots/ocaml-sys-socket * License : Expat Programming Lang: OCaml Description : OCaml ctypes bindings to system-specific low-level socket structure and data-types The interface is implemented using ocaml-ctypes and is intended to exposed the machine-specific, low-level details of the most important parts of socket implementations. Sys_socket provides an API compatible for both Unix and Win32 systems, while Sys_socket_unix provides the API specific to Unix systems, mostly the sockaddr_u structure. This package will be maintained as part of the Debian OCaml Team
Bug#956485: ITP: ocaml-unix-errno -- An errno variant that includes a variety of constructors
Package: wnpp Severity: wishlist Owner: Kyle Robbertze Control: block 956479 by -1 * Package name: ocaml-unix-errno Version : 0.5.2 Upstream Author : David Sheets * URL : https://github.com/dsheets/ocaml-unix-errno * License : ISC Programming Lang: OCaml Description : An errno variant that includes a variety of constructors An errno variant similar to Unix.error but including POSIX 2008, Linux, OS X, and FreeBSD constructors. A macro definition type is also provided in order to transport a specific errno-integer map as is the case with FUSE or 9p2000.u. The types and their functions reside in Errno and are independent of any Unix bindings. This makes the library's types usable from MirageOS on top of Xen. It is a dependency of ocmal-sys-socket and will be maintained as part of the OCaml team
Bug#956487: ITP: alcotest -- A lightweight and colourful test framework for OCaml
Package: wnpp Severity: wishlist Owner: Kyle Robbertze Control: block 956485 by -1 * Package name: alcotest Version : 1.1.0 Upstream Author : Thomas Gazagnaire * URL : https://github.com/mirage/alcotest * License : ISC Programming Lang: OCaml Description : A lightweight and colourful test framework for OCaml Alcotest exposes simple interface to perform unit tests. It exposes a simple TESTABLE module type, a check function to assert test predicates and a run function to perform a list of unit -> unit test callbacks. Alcotest provides a quiet and colorful output where only faulty runs are fully displayed at the end of the run (with the full logs ready to inspect), with a simple (yet expressive) query language to select the tests to run. It is a dependency of ocaml-unix-errno and will be maintained under the OCaml team.
Bug#956494: ITP: golang-github-bndr-gotabulate -- Gotabulate - Easily pretty-print your tabular data with Go
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org Package: wnpp Severity: wishlist Owner: Taowa Munene-Tardif * Package name: golang-github-bndr-gotabulate Version : 1.1.2-1 Upstream Author : Vadim Kravcenko * URL : https://github.com/bndr/gotabulate * License : Apache-2.0 Programming Lang: Go Description : Gotabulate - Easily pretty-print your tabular data with Go Summary Go-Tabulate - Generic Go Library for easy pretty-printing of tabular data. Needed for packaging pat (#877030). -- Taowa Munene-Tardif taowa.ca Montréal
Bug#956496: ITP: ksnip -- Qt-based cross-platform screenshot tool
Package: wnpp Severity: wishlist Owner: Boyuan Yang X-Debbugs-CC: debian-devel@lists.debian.org * Package name: ksnip Version : 1.6.1 Upstream Author : Damir Porobic * URL : https://github.com/ksnip/ksnip * License : GPL-2+ Programming Lang: C++/Qt Description : Qt-based cross-platform screenshot tool Ksnip is a Qt-based cross-platform screenshot tool that provides many annotation features for your screenshots. It provides a traditional user interface with experimental GNOME/KDE Wayland support. I plan to maintain this package myself and the packaging repo is placed under the Debian group. Co-maintainers are welcome. It depends on two separate libraries (kcolorpicker and kimageannotator). The former one is now in Sid while the latter one is being reviewed in the NEW queue. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#956500: ITP: node-bash -- Utilities for using bash from node.js.
Package: wnpp Severity: wishlist Owner: Harley Swick X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-bash Version : 0.0.1 Upstream Author : Felix Geisendörfer (http://debuggable.com/) * URL : https://github.com/felixge/node-bash * License : MIT Programming Lang: JavaScript Description : Utilities for using bash from node.js. This package is meant to be used by node applications for CLI tools or servers. This is a dependency for shiny-server which is needed by Debian Science. I plan to maintain this as part of the Javascript Maintainers team.
