Bug#1008182: ITP: node-rewire -- Easy monkey-patching for node.js unit tests
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-rewire Version : 6.0.0 Upstream Author : Johannes Ewald * URL : https://github.com/jhnns/rewire * License : Expat Programming Lang: JavaScript Description : Easy monkey-patching for node.js unit tests rewire adds a special setter and getter to modules making it possible to modify their behaviour for better unit testing. It provides functionality for . + inject mocks for other modules or globals like process + inspect private variables + override variables within the module. . Node.js is an event-based server-side JavaScript engine.
Bug#1073802: ITP: oras -- OCI registry client - managing content like artifacts, images, packages
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: oras Version : 1.2.0-1 Upstream Author : OCI Registry As Storage (ORAS) * URL : https://github.com/oras-project/oras * License : Apache-2.0 Programming Lang: Go Description : OCI registry cli tool managing content like artifacts, images, packages ORAS works similarly to tools you may already be familiar with, such as docker. It allows you to push (upload) and pull (download) things to and from an OCI Registry, and also handles login (authentication) and token flow (authorization). What ORAS does differently is shift the focus from container images to other types of artifacts. . ORAS is the de facto tool for working with OCI Artifacts. It treats media types as a critical piece of the puzzle. Container images are never assumed to be the artifact in question.
Re: Mini-DebConf in Cambridge, UK - October 10-13 2024
On Mon, Jun 24, 2024 at 12:32:59PM +0100, Steve McIntyre wrote: > On Mon, Jun 24, 2024 at 12:18:56PM +0200, somebody *claiming* to be Luna > Jernberg wrote: > > > > Just to be 100% clear, that mail didn't come from Luna's normal gmail > account but was instead spoofed and sent via emkei.cz, a "free online > fake mailer". It's now blocked from Debian lists. If what you're saying is correct (based on headers that make sense), it's a bit concerning since someone is launching targeted spoofing attacks with the name of actual Debian contributors. The style of writing mail - everything in one line, CCing several lists is similar to how Luna writes it too. Freaky. Best, Nilesh signature.asc Description: PGP signature
Bug#1075841: ITP: golang-sourcehut-rockorager-vaxis --
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-sourcehut-rockorager-vaxis Version : 0.9.2-1 Upstream Author : Tim Culverhouse * URL : https://git.sr.ht/~rockorager/vaxis * License : Apache-2.0 Programming Lang: Go Description : Terminal User Interface (TUI) library for go Vaxis is a Terminal User Interface (TUI) library for go. Vaxis supports modern terminal features, such as styled underlines and graphics. A widgets package is provided with some useful widgets. . Vaxis is blazingly fast at rendering. It might not be as fast or efficient as notcurses, but significant profiling has been done to reduce all render bottlenecks while still maintaining the feature-set. . Vaxis does not use terminfo. Support for features is detected through terminal queries. Vaxis assumes xterm-style escape codes everywhere else. signature.asc Description: PGP signature
Re: DD's, Debian Mentors needs you!
On Sun, Jul 07, 2024 at 07:54:25AM +0200, Andreas Tille wrote: > Am Sat, Jul 06, 2024 at 02:45:33PM +0100 schrieb Phil Wyett: > > Hi all DD's > > > > Debian Mentors[1] always struggles to find available Debian Developers for > > final reviewing and > > sponsoring of packages submitted too our part of the project. > > One thing I'm missing on mentors.d.n is that I it does not advertise > existing teams. It happened from time to time that there was some > sponsoring request of Debian Science, Debian Med or Debian Python Team > related packages (surely others I did not notices). Asking on the > relevant lists very easily helps getting the package in question > sponsored. I have a personal sponsoring policy that I only sponsor from > a Git repository in a team I'm working in. This has the advantage I can > easily help by pushing some commit with extensive comment to teach the > sponsee in some direct way. Making a sponsee aware how to work together > with a team inside Debian is IMHO very important. +1. I wanted to sponsor at least 3 packages but backed off when I saw it is impossible to push my changes to a common git repo to ease off the work. I could go ahead with selint (on salsa) but to my surprise selinux team does not have a request to join button on[1] - likely disabled on purpose. [1]: https://salsa.debian.org/selinux-team Best, Nilesh signature.asc Description: PGP signature
Re: DD's, Debian Mentors needs you!
On Sun, Jul 07, 2024 at 08:34:13AM +, weepingclown wrote: > Hi Nilesh, > > The 'request access' button is now available once clicked on the button with > three dots on the top right, and on mobile this seems to be a "More actions" > button instead of thw three dots one. IIRC this change has happened since > before the last few gitlab version updates. Ah, thanks weeping sir! I have clicked on the request access button ever since I started contributing and was unaware about this. I've applied. Let's see if someone considers approving. > Best, > Ananthu > > On 7 July 2024 7:47:39 am UTC, Nilesh Patra wrote: > >I could go ahead with selint (on salsa) but to my surprise selinux team does > >not > >have a request to join button on[1] - likely disabled on purpose. > > > Best, Nilesh signature.asc Description: PGP signature
Re: Bug#1076153: ITP: dh-rust -- debhelper buildsystem for Rust code
On Thu, Jul 11, 2024 at 06:06:21PM +0200, Jonas Smedegaard wrote: > Package: wnpp > Severity: wishlist > Owner: Jonas Smedegaard > X-Debbugs-Cc: debian-devel@lists.debian.org, build-common team > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > * Package name: dh-rust I would be happy if this makes it to the archive, though. Would be easier to have a dh for rust which would be specifically useful to build packages that are not just crates, but instead use multiple language including but not limited to rust. As an addendum, also gives freedom to maintain packages outside of the giant git repo of crates, without having to embed this code in every such outside-of-team maintained package. Best, Nilesh signature.asc Description: PGP signature
Re: Suggest
On Sat, Jul 20, 2024 at 07:30:24PM +0330, Binesh Moradi wrote: > In the future, definitely create a mobile version of Debian that can run on > phones, like Ubuntu Touch. https://lists.debian.org/debian-project/2024/07/msg4.html https://lists.debian.org/debian-project/2024/07/msg5.html https://mobian-project.org/ signature.asc Description: PGP signature
Re: OpenPGP digital signature
On 30 July 2024 3:35:18 pm GMT+09:00, Yadd wrote: >On 7/30/24 09:53, imtoas...@mail.com wrote: >> >> [Message resent because the year was wrong] >> >> Dear all, >> >> We are currently considering the following dates as our freeze >> dates. If you are aware of major clashes of these dates with anything >> we depend on please let us know. We also like to stress again that we >> really would like to have a short Hard and Full Freeze (counting in >> weeks, rather than months), so please plan accordingly. If serious >> delays turn up during any of the Freeze steps, we rather (partially or >> completely) thaw bookworm again than staying frozen for a long time. >> >> 2023-01-12 - Milestone 1 - Transition and toolchain freeze >> 2023-02-12 - Milestone 2 - Soft Freeze >> 2023-03-12 - Milestone 3 - Hard Freeze - for key packages and >> packages without autopkgtests >> To be announced - Milestone 4 - Full Freeze >> >> On behalf of the Release Team, >> Paul > >2025 I suppose Sounds pretty sus. I doubt if this mail is from the official release team. Doesn't look like Paul's address either.
Re: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts
On Thu, Aug 15, 2024 at 12:30:22PM -0500, G. Branden Robinson wrote: > At 2024-08-15T13:20:02-0400, Michael Stone wrote: > > > This change was noted in NEWS. > > > > > > I would suggest hooking your config into something that uses the > > > network-online.target target, with a timeout like network-manager > > > and networkd do, so that the boot process doesn't hang. If it's a > > > simple unit, it's enough to add RuntimeMaxSec= to it, so that it's > > > killed if it doesn't work within the configured timeout. > > > > It's just so depressing that this is how debian works now. We used to > > try to not break things, now the answer is "you should have read the > > NEWS, and known that unrelated packages were going to break, and > > reconfigured standard debian network tools to add non-default > > timeouts". All because the aesthetic preference for not having the > > same binary appear in two different paths is a higher priority than > > keeping systems working. > > "Move fast and break as much stuff as possible, or Debian will be doomed > to irrelevance. I'll be SABDFL someday!" > > The creed of the _impactful_ developer. It looks like a pretty pointless change - breaks several scripts for example. It was/is common to assume /sbin/ip to be present and usable. Michael's bug report does make sense to me. Such a change is even causing systems to not bootup. Best, Nilesh signature.asc Description: PGP signature
Re: Removing more packages from unstable
On Tue, Aug 20, 2024 at 11:09:51AM +0200, Bastian Venthur wrote: > I think popcon does give a good approximation of how much percent of people > installed a certain package even if not everyone uses it, don't you agree? > > Last time I installed Debian it was still enabled by default. When was it? My last installation of Debian on a laptop was approximately 1.5 years ago and it was off by default. It asked me if I want to enable it or not. Did that change recently in D-I? Best, Nilesh signature.asc Description: PGP signature
Re: Removing more packages from unstable
On Wed, Aug 21, 2024 at 08:40:15PM +, weepingclown wrote: > Hi, > > I believe at least some of these packages were probably packaged as > dependencies for packaging lazygit. I am not sure which all, but I remember > atleast gocui, pty and termbox-go to be needed by lazygit in one way or > another. There has been further work on packaging lazygit towards the end of > the previous year, which I believe was mostly finished, that was then delayed > by the person primarily focusing on this being the chief organizer for > DebConf24. I am not sure removing them is the best idea, given it is part of > an ongoing work. Is there any further intended effort for lazygit? > Best, > Ananthu > > >golang-github-jesseduffield-asciigraph > >golang-github-jesseduffield-gocui > >golang-github-jesseduffield-pty > >golang-github-jesseduffield-roll > >golang-github-jesseduffield-rollrus > >golang-github-jesseduffield-termbox-go > >golang-github-jesseduffield-yaml > >golang-github-manyminds-api2go > > I am fixing riscv64 FTBFS in some of these now so it migrates properly. If the work is mostly done, we can quickly wrap up lazygit in a month or two. Want to give a hand? Best, Nilesh signature.asc Description: PGP signature
Re: lintian.debian.org off ?
On 2024-09-02 07:27, Louis-Philippe Véronneau wrote: > Apparently I'm a Lintian maintainer now. I had a quick look at Lintian and > lintian.debian.org is referenced in multiple places. I feel quite happy on reading this and seeing that you also just did a lintian release to unstable. Thank you, thank you, thank you! :) Greetings, Nilesh
Bug#932956: ITP: node-node-sass -- Wrapper around libsass
Package: wnpp Severity: wishlist Owner: Nilesh X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-node-sass Version : 4.12.0 Upstream Author : Andrew Nesbitt ( http://andrew.github.com) * URL : https://github.com/sass/node-sass * License : Expat Programming Lang: JavaScript Description : Wrapper around libsass Node-sass is a library that provides binding for Node.js to LibSass. . LibSass is the C version of the popular stylesheet preprocessor, Sass. . It allows you to natively compile .scss files to css at incredible speed and automatically via a connect middleware. . Node.js is an event-based server-side JavaScript engine. This package is a dependency of node-mermaid.I am interested in maintaining this package long time. It would be great if it could be given an bug number to close. Regards Nilesh
Bug#1039056: ITP: golang-go.mau-zeroconfig -- TODO
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-go.mau-zeroconfig Version : 0.1.2-1 Upstream Author : TODO * URL : https://github.com/tulir/zeroconfig.git * License : TODO Programming Lang: Go Description : Relatively simple declarative config format for zerolog Relatively simple declarative config format for zerolog. Meant to be used as YAML, but JSON struct tags are included as well. (Transitive) dep of gomuks.
Bug#1039057: ITP: golang-go.mau-zeroconfig -- Relatively simple declarative config format for zerolog
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-go.mau-zeroconfig Version : 0.1.2-1 Upstream Author : 2023, Tulir Asokan * URL : https://github.com/tulir/zeroconfig.git * License : MPL-2.0 Programming Lang: Go Description : Relatively simple declarative config format for zerolog Relatively simple declarative config format for zerolog. Meant to be used as YAML, but JSON struct tags are included as well. (Transitive) dep of gomuks.
Bug#1039519: ITP: golang-maunium-go-mauflag -- Extendable argument parser for Golang
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-maunium-go-mauflag Version : 1.0.0-1 Upstream Author : 2016 Maunium * URL : https://github.com/tulir/mauflag.git * License : GPL-3 Programming Lang: Go Description : Extendable argument parser for Golang Mauflag is an extendable argument parser for golang that mostly follows GNU Program Argument Syntax Conventions. . This is a transitive dep of gomuks.
Bug#1039596: ITP: golang-github-tidwall-sjson -- Set JSON values very quickly in Go
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-tidwall-sjson Version : 1.2.5-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/sjson * License : Expat Programming Lang: Go Description : Set JSON values very quickly in Go SJSON is a Go package that provides a very fast and simple way to set a value in a json document.
Bug#1039717: ITP: golang-maunium-go-maulogger -- Simple easy to use logger in go
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-maunium-go-maulogger Version : 2.4.1-1 Upstream Author : 2016-2023 Tulir Asokan * URL : https://github.com/tulir/maulogger.git * License : MPL-2 Programming Lang: Go Description : Simple easy to use logger in go Maulogger is a simple and easy to use logger written in golang. Can be used in conjunction with zerolog. . This is a transitive dep of gomuks.
Bug#1039876: ITP: golang-maunium-go-mautrix -- Matrix framework in golang
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-maunium-go-mautrix Version : 0.15.3-1 Upstream Author : Tulir Asokan * URL : https://github.com/mautrix/go.git * License : MPL-2.0 Programming Lang: Go Description : Matrix framework in golang Mautrix is a Golang Matrix framework. Used by gomuks, go-neb, mautrix-whatsapp and others.
Bug#1039892: ITP: golang-go.mau-mauview -- Go TUI library based on tcell
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-go.mau-mauview Version : 0.2.1-1 Upstream Author : Tulir Asokan * URL : https://github.com/tulir/mauview.git * License : MPL-2.0 Programming Lang: Go Description : Go TUI library based on tcell mauview is a Golang TUI library based on tcell. . This package is a dependency of Gomuks
Bug#1039954: ITP: gomuks -- Terminal based Matrix client written in Go
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: gomuks Version : 0.3.0 Upstream Authors: https://github.com/tulir/gomuks/issues URL : https://github.com/tulir/gomuks * License : AGPL-3+ Description : Terminal based Matrix client written in Go Gomuks is a terminal based Matrix client written in Golang which uses mautrix and mauview. signature.asc Description: PGP signature
Re: Go (golang) packaging, using external libs
On Thu, Jul 06, 2023 at 06:46:46PM +, Valera Rozuvan wrote: > Is it at all possible to create a proper DEB package: > > - using golang > - to be published in the official Debian package repository > - using a golang library which is not in Debian It is, golang has a provision for vendoring libs in vendor/ directory and go compiler will pick these up while building. However, this is usually (very much) discouraged, unless there are genuine reasons to do so, and it is always a better route to package dependencies. > (such as https://pkg.go.dev/github.com/lib/pq - A pure Go postgres driver) This library is packaged in the archive and is present as golang-github-lib-pq-dev package. See https://tracker.debian.org/pkg/golang-github-lib-pq > I would greatly appreciate, if someone can point me at an example package > which is in Debian, and is using an external golang lib. You can have a look at cadvisor, libpod, singularity-container and gitaly packages as examples. Best, Nilesh signature.asc Description: PGP signature
Re: Mini-DebConf in Cambridge, UK - November 23-26 2023
On Sun, Jul 23, 2023 at 12:50:06PM +0200, Luna Jernberg wrote:
> Might come if the Debian project can help me pay for travel and
> hotel/accommodation RattusRattus promised to email me when he have
> time to i can apply (during the Debian 12.1 release ISO test yesterday
> afternoon)
Please keep replies to email sent on debian-devel-announce /
{debconf,debian}-announce
off those mailing lists. They are supposed to be only for announcements,
and nothing else. It's quite annoying for me to see replies to announce
emails on that kind of mailing list, and subsequently get into my more
important (IMAP) folders.
I'm also saying this to you explicitly because I've seen replies from
you on annouce mailing lists on more occassions than this one.
Thanks.
signature.asc
Description: PGP signature
Re: Mini-DebConf in Cambridge, UK - November 23-26 2023
On Sun, Jul 23, 2023 at 12:24:32PM -0700, Steve Langasek wrote:
> On Sun, Jul 23, 2023 at 06:36:21PM +0530, Nilesh Patra wrote:
> > On Sun, Jul 23, 2023 at 12:50:06PM +0200, Luna Jernberg wrote:
> > > Might come if the Debian project can help me pay for travel and
> > > hotel/accommodation RattusRattus promised to email me when he have
> > > time to i can apply (during the Debian 12.1 release ISO test yesterday
> > > afternoon)
>
> > Please keep replies to email sent on debian-devel-announce /
> > {debconf,debian}-announce
> > off those mailing lists. They are supposed to be only for announcements,
> > and nothing else. It's quite annoying for me to see replies to announce
> > emails on that kind of mailing list, and subsequently get into my more
> > important (IMAP) folders.
>
> The mail was not delivered to the announce list. In fact,
> debian-devel-announce directs all mails with an In-Reply-To: header to
> debian-devel.
I know.
> So while it's best practice when replying to make sure you're sending to the
> right address, the fact that it winds up in your announce imap folder is a
> local configuration issue, not a question of where it was sent.
I don't run a mailserver of my own, so this is how my sieve filters are
configured at the moment. It has almost never been a problem, except for
when people reply to too many lists with the announce ones as well.
However, I'll look into fixing my sieve rules (thanks to the hint from
bremner).
That said, my point still stands, and the replies that have nothing to
do with announcements should not be sent to that list. It is not about
best practice, but rather about following the the etiquette.
Best,
Nilesh
signature.asc
Description: PGP signature
Re: Can we distribute pre-built locales to speed up image generation?
Hi Charles, On Tue, Aug 01, 2023 at 04:43:59PM +0900, Charles Plessy wrote: > In the course of generating singularity/apptainer Debian images at work, > I wanted to make all locales available to the users. On an un-related note, are you using signularity-container package from debian archive itself? I recently did some work to get it into fasttrack. https://micronews.debian.org/2023/1686751737.html Best, Nilesh signature.asc Description: PGP signature
Re: lintian.debian.org off ?
On Sat, Sep 23, 2023 at 11:02:08AM +0800, Paul Wise wrote: > On Fri, 2023-09-22 at 09:27 +0200, Jérémy Lal wrote: > > > Host lintian.debian.org not found: 3(NXDOMAIN) > > > > is this expected ? > > Yes, it is replaced by the UDD interface: > > https://wiki.debian.org/Services/lintian.debian.org > https://udd.debian.org/lintian/ > > There is no web based location for the description of each tag yet. I don't know if it is just me, but even udd gives me a 500 when I try to check lintian output for any (existing) package. For example: https://udd.debian.org/lintian/?packages=nim Best, Nilesh signature.asc Description: PGP signature
Re: lintian.debian.org off ?
On Mon, Sep 25, 2023 at 10:28:06PM -0700, Otto Kekäläinen wrote: > > > > > Host lintian.debian.org not found: 3(NXDOMAIN) > > > > > > > > > > is this expected ? > > > > > > > > Yes, it is replaced by the UDD interface: > > > > > > > > https://wiki.debian.org/Services/lintian.debian.org > > The page above links to two bug reports but I can't find any actual > information about *why* the site https://lintian.debian.org/ was shut > down? You can find a better explanation and context here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858039#22 Best, Nilesh signature.asc Description: PGP signature
Bug#1053518: ITP: golang-github-ozeidan-fuzzy-patricia -- A generic patricia trie (also called radix tree) implemented in Go (Golang).
Package: wnpp
Severity: wishlist
Owner: Ananthu C V
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-ozeidan-fuzzy-patricia
Version : 3.0.0
Upstream Author : Omar Zeidan
* URL : https://github.com/ozeidan/fuzzy-patricia.git
* License : Expat
Programming Lang: Go
Description : A generic patricia trie (also called radix tree)
implemented in Go (Golang).
A generic patricia trie (also called radix tree) implemented in Go (Golang).
The patricia trie as implemented in this library enables fast visiting of items
in some particular ways:
visit all items saved in the tree,
visit all items matching particular prefix (visit subtree), or
given a string, visit all items matching some prefix of that string.
[]byte type is used for keys, interface{} for values.
Trie is not thread safe. Synchronize the access yourself.
This package is in the dependency tree of Lazygit (#908894)
Re: ITP: golang-github-microsoft-go-winio -- Win32 IO-related utilities for Go
Hello, On Wed, Oct 25, 2023 at 05:13:10PM +0300, Ramūnas Keliuotis wrote: > Package: wnpp > Severity: wishlist > Owner: Ramunas Keliuotis > > * Package name: golang-github-microsoft-go-winio > Version : 0.6.1-1 > Upstream Author : Microsoft > * URL : https://github.com/Microsoft/go-winio > * License : Expat > Programming Lang: Go > Description : Win32 IO-related utilities for Go This seems to be a windows specific library - if I'm not mistaken, there is no use of this library for debian/any linux distro, yes? > I am not an owner nor a maintainer of this golang library. > This golang package is dependency to my program I am packaging for Debian. > Need to wrap this golang library into a Debian package and upload it to SID. > > I am not sure about the golang packaging into Debian, I submitted a > request to get > access to go-team Salsa area. Then I can work with `dh-make-golang` and upload > to salsa. But again - what is the sequence of how to proceed? You need to ask a debian developer to sponsor (upload package on your behalf) to unstable, provided your package is in good shape. You might want to skim quickly through: https://mentors.debian.net/intro-maintainers/ > -- > The content of this email, including all attachments, is confidential. If > you are not the intended recipient of this e-mail, please notify us > immediately and delete this email. Any disclosure, copying, distribution or > any other use of its content is strictly prohibited. Just so you know, a couple of ITPs you filed are being submitted to *public* mailing lists with several hundreds (if not thousands) of subscribers. You might want to delete this footer for mails you send to debian mailing lists. Best, Nilesh signature.asc Description: PGP signature
Re: ITP: golang-github-microsoft-go-winio -- Win32 IO-related utilities for Go
On Thu, Oct 26, 2023 at 08:35:51AM +0200, Salvo Tomaselli wrote: > > Go has the extremely nice feature that cross-compiling for other > > architectures and OSs is very easy. I have, on a number of occasions > > used Debian to cross-compile Go programs for Windows. > > > > I have no particular interest in this package, but yes, it is > > appropriate to package a Windows-only Go package in Debian. > > Why would it be in debian though? > > Go provides a repository for libraries. I thought we were packaging libraries > in debian if they were a requirement for things used in debian, that can't > just download libraries when building (which is the normal way in go) This is true. It makes sense to package go libraries in debian only when some target package actually depends on it. In this case, for me it makes no sense to have a windows specific go library in debian. One could easily compile for another OS or whatever target by fetching the library - there is no need to have a specific debian package for it. I don't expect anyone as such to use a debian package to compile things for another OS. Best, Nilesh signature.asc Description: PGP signature
Re: ITP: golang-github-microsoft-go-winio -- Win32 IO-related utilities for Go
On 26 October 2023 9:19:06 pm IST, Marvin Renich wrote: >>From the original ITP: > This golang package is dependency to my program I am packaging for Debian. This is going to be my last mail about this topic. The ITP may say so, but for most go packages, the windows specific code is in separate files than the rest and the decision of compiling them or not is taken care of by go directives. If the code is still present in such a way that windows library becomes mandatory to be included, then upstream should fix this in their codebase. Windows specific code would not even be compiled in the debian package (which is expected). It is highly unlikely for a windows-only go library to be actually needed in debian. To be clear, the statement that it makes sense to package go libraries only when they are dependencies of a target also means that they serve some actual "Linux" functionality in the target package as well.
Re: RFC: advise against using Proton Mail for Debian work?
On 15 November 2023 5:10:50 am IST, Nicholas D Steeves wrote: >On the surface, this means Proton Mail (free account) is great! And for >general use, I feel like we should be supportive of them; however, I'm >starting to wonder if we need to recommend against the use of Proton >mail for Debian work for the following two reasons: > >1. I've received a report that this provider is not appropriate for DM >and DD use, because the key pair is stored on their servers. Ie: The >applicant doesn't control the means to validating identity and >authorship. 100% agreed. I once advocated a DM who uses protonmail and a few months (after they became a DM), I came to know about PM's storing keys in the server. So I quickly checked with the person in question if they pushed their keys to PM's servers, and to my utter horror, they did. I quickly made the keyring maint know and their keys were removed immediately and a new pair of keys were later added back after a few months when enough trust was established for those. This is not the only instance I faced this. Another individual whom I advocated for being a DM also did this, but we found out about it before the process started. People who are new to the GPG thing end up thinking it's okay to add their keys to PM - which is fine, but this is as good as compromised from the debian view which I think is correct. Due to this, I'm always skeptical whenever I receive a PGP signed or encrypted email from protonmail. >2. The Proton Mail web client automatically encrypts email to anyone who >it has a key for. Usually, this would be a great thing, but it means >that emailing 1234 at bugs.debian.org while CCing >uploader_since_this_is_an_rc_...@debian.org will encrypt the email that >is sent to the BTSe...which has the effect of making Debian development >veiled in plain sight rather than "in the open". Does it not encrypt email per-sender? >I see three outcomes: > >A) Continue to explain this to new contributors on a one-by-one basis. >B) Advise against using Proton Mail for Debian work (where? our wiki?) It might be good to give a warning about pushing PGP keys to proton mail's servers and it's implication on debian work *and* also inform new contributors on one by one basis who may not have seen the wiki. I also think that providers that do not offer IMAP/POP3 are not very recommended for debian work too as you lose the ability to use a mailing client (and sign your mails). I think it'd be good to add a note about that as well. I've seen at least 2 people start with a tutanota email address and later switch due to this reason. >C) Proton Mail begins to do something differently on their end, such as >offering some features to Debian contributors that currently require a >subscription. This does not look feasible since 'Debian contributors' is a broad term and it'd be impractical to classify people there and give them access. What could _maybe_ make sense is to have case-by-case endorsements for debian contributors to get such features. >P.S. Also, at what point should we add them to CC and/or write them an >open letter? I think whenever we reach a sensible way forward :) If they don't already, probably adding a warning regarding PGP keys in their webUI could be good as well. Best, Nilesh
Re: Changing supermajority requirements
On Wed, Nov 22, 2023 at 11:29:36AM +, Bill Allombert wrote: > Le Wed, Nov 22, 2023 at 11:00:57AM +0100, Ansgar a écrit : > > Hi, > > > > the Constitution has several supermajority requirements that seem > > excessive to me: > > > > Constitution changes: > > > > +--- > > | 4.1.2: Amend this constitution, provided they agree with a 3:1 majority. > > | [...] > > | 5.1.5.3: A Foundation Document requires a 3:1 majority for its > > supersession. [...] > > +--- > > > > Constitutional changes to my country's constitution only require a 2:1 > > majority. A 3:1 majority seems excessive for that reason and I would > > suggest to change both of these to 2:1 for that reason. > > > > I think a supermajority is fine for changing fundamental rules, so more > > than a simple majority is okay. > > Note that so far in almost no cases a GR failed due to the supermajority > requirement. > So it is difficult to read your proposal without thinking you have > ulterior motives, that maybe you should communicate ? +1. It's be nice to know if there are any recent GRs that had 2:1 supermajority but *not* 3:1 and it failed due to the same. Best, Nilesh signature.asc Description: PGP signature
Re: Limited security support for Go/Rust? Re ssh3
On Sun, Jan 14, 2024 at 10:47:18AM +0100, Simon Josefsson wrote: > Stephan Verbücheln writes: > > > On Sat, 30 Dec 2023 12:47:48 + Colin Watson > > wrote: > >> I also feel that something security-critical like this that's > >> labelled by upstream as "still experimental" probably shouldn't > >> be in a Debian release. > > > > It is written in Go. The problem of Go library support in Debian should > > also be considered for a security-critical tool like this. > > > > https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking > > Interesting -- what is the current thinking about this problem? > > The more I think about it, I think it seems unfair to categorize this as > a Go/Rust problem. +1. Container packages such as docker and podman are also golang packages and also security critical. > ... > My suggestion is that we relax or remove the Go/Rust statement in future > release notes. Or we could as well look at improving the infrastructure to deal with them. Best, Nilesh signature.asc Description: PGP signature
Bug#1063612: ITP: corrosion -- Tool for integrating rust with an existing CMake project
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: corrosion Version : 0.4.7 Upstream Contact: Andrew Gaspar * URL : https://github.com/corrosion-rs/corrosion * License : MIT Programming Lang: C++ Description : Tool for integrating rust with an existing CMake project Corrosion, formerly known as cmake-cargo, is a tool for integrating Rust into an existing CMake project. . Corrosion can automatically import executables, static libraries, and dynamic libraries from a workspace or package manifest (Cargo.toml file). Needed for angelfish to manage it easily. This will be maintained in the debian namespace.
Bug#1064207: ITP: golang-sourcehut-rjarry-go-opt -- Parse command line arguments based on tag annotations on struct fields (library)
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-sourcehut-rjarry-go-opt Version : 1.4.0 Upstream Contact: Robin Jarry * URL : https://git.sr.ht/~rjarry/go-opt * License : Expat Programming Lang: Go Description : Parse command line arguments based on tag annotations on struct fields (library) This is a library to parse command line arguments based on tag annotations on struct fields. It came as a spin-off from aerc to deal with its internal commands. . This project is a scaled down version of https://github.com/alexflint/go- arg with different usage patterns in mind: command parsing and argument completion for internal application commands.
Any way to install packages+run autopkgtests on porterbox machines?
Hi, When I want to fix autopkgtests for a package on a particular architecture, I currently see no way to run autopkgtests before I dput since porter boxes do not provide root access which autopkgtest needs. Currently I am manually hacking around the test scripts and running the autopkgtests but this does not emulate the autopkgtest environment well enough. It also does not work well for daemon-like packages for instance. Additionally, say, I have a package which FTBFS due to something broken in a build dependency on a particular architecture. If I fixup the problem in the build-dependency, there is no way I could test if the target package really works on that arch since I do not see a way to install the fixed builddep without uploading it to the archive. Have you found any way around these? Best, Nilesh signature.asc Description: PGP signature
Re: Any way to install packages+run autopkgtests on porterbox machines?
On Fri, Mar 01, 2024 at 06:03:16PM +0500, Andrey Rahmatullin wrote: > You can use local sbuild chroots for foreign architectures, both for > building and, I assume, running autopkgtests. I know but that is not something I want. This invaidates the whole point of using porter machines. Best, Nilesh signature.asc Description: PGP signature
Re: Any way to install packages+run autopkgtests on porterbox machines?
On Sun, Mar 03, 2024 at 06:09:47PM +0100, Paul Gevers wrote: > On 01-03-2024 1:58 p.m., Nilesh Patra wrote: > > Have you found any way around these? > > https://salsa.debian.org/mbanck/dd-autopkgtest/ Thanks, I will use this for autopkgtests. This however also only partially solves the issue for me. If I want to run tests with another package (say a test dependency) that I fixed locally on a particular arch (which is not amd64) -- how doI run autopkgtests with this combo on a porter machine? Best, Nilesh signature.asc Description: PGP signature
Bug#1068578: RFH: singularity-container -- container platform focused on supporting "Mobility of Compute"
Package: wnpp Severity: normal X-Debbugs-Cc: singularity-contai...@packages.debian.org, debian-devel@lists.debian.org, o...@debian.org, me...@dogguy.org Control: affects -1 + src:singularity-container Assistance required with maintaining the singularity-container package. I am not the uploader/maintainer of this package, however I am the only one who has been taking care of it via team uploads for more than 2 years and all other uploaders are MIA. Few of them asked me to remove myself from uploaders field, which I have done. However, I don't consider the package well-maintained w/o me doing the work. It is also stalled from migrating to stable because maintaining it there requires backporting and testing CVE fixes and I don't have the bandwidth to do that work, which is the reason for #1029669. With my available time, it is unlikely that I will be maintaining it timely or at all. Any help for maintaining it would be great. The package description is: Mobility of Compute encapsulates the development to compute model where developers can work in an environment of their choosing and creation and when the developer needs additional compute resources, this environment can easily be copied and executed on other platforms. Additionally as the primary use case for Singularity is targeted towards computational portability, many of the barriers to entry of other container solutions do not apply to Singularity making it an ideal solution for users (both computational and non-computational) and HPC centers. signature.asc Description: PGP signature
Re: finally end single-person maintainership
On Sat, Apr 13, 2024 at 10:08:07AM +0200, Andreas Tille wrote: > Am Sat, Apr 13, 2024 at 01:16:37AM +0900 schrieb Simon Richter: > > > > For example, any repository that does not list debian/files and > > debian/*.substvars in the gitignore will fail to build twice in a row, > > because these files are created and are subsequently untracked. > > Sorry, no. We should teach people to build in a chroot which does > not leave this stuff inside local debian/ dir. True. Or add relevant files and stash (which is what I do for non-chroot builds). > > Once people are familiar with how Debian packaging works, we can introduce > > the git interfaces on top. Before that, git is more of a hindrance than a > > benefit to new contributors, precisely because it looks familiar, but the > > knowledge is not transferable. > > >From my mentoring work I can confirm this sequence is not necessary for > everyone. You might have different experience, but I would not subscribe > this as a general rule. To add in more perspective to it -- I started contributing to debian in 2019. I don't think I would have the motivation to contribute further had it not been for a git based workflow and salsa. In the sense that it'd have made it an uphill journey for me to know how to send patches. Git was something I was familiar with so I did not have to spend time struggling with basic things. Like Andreas, I have mentored many new comers too, advocated them to be DMs/DDs and I never found any of them complaining about git workflow so what is quoted above is not true as a general rule. People who did debian packaging without git for a long time and then had to switch/use a git based workflow might find it a little counter-intuitive which also stems from the fact that people generally resist change. But the same is not necessarily true for new contributors. On Sat, Apr 13, 2024 at 01:16:37AM +0900, Simon Richter wrote: > We're not even doing anyone a favour by introducing the git based workflows > first, because about half of the techniques people know from git will > conflict with something git-buildpackage or dgit does, and without a mental > model of how Debian packaging is supposed to work standalone, they have no > chance of solving even the simplest problem. I did not have a solid understanding of how debian packaging works standalone, and had only very little idea about most of the things when I started -- it only gets better with time. But I believe I did solve at least some simple problems to qualify for becoming a DD :-) Best, Nilesh signature.asc Description: PGP signature
Re: Any volunteers for lintian co-maintenance?
On Fri, May 10, 2024 at 04:06:15PM +0200, Andreas Tille wrote: > > If lintian is important to you, I strongly recommend that you do put *some* > > of your volunteer time into it. > > +1 > for Soren and everybody else reading this. Lintian is important for me. For the past few months, I have been reviewing and merging MRs and pushing small fixes of my own. I am not a proficient perl programmer and hence I am not the best person to be doing so. But then, nobody else was doing it and I decided to do at least a little bit. If someone would like to dedicatedly contribute sometime there, it'd be really great. The package is not in a very good shape right now. Best, Nilesh signature.asc Description: PGP signature
Re: Any volunteers for lintian co-maintenance?
Hi Andrius, On Fri, May 10, 2024 at 05:58:24PM +0300, Andrius Merkys wrote: > Do you mean bugs on bugs.d.o, or are there other issues? As you may have seen in the other emails, there are performance issues. Other than that, there are 2 open RC bugs right now (fixed in salsa but not uploaded I don't make uploads for lintian). A pile of MRs are pending for reviews at many points in time. > I personally feel motivated to implement new features in lintian or go after > low hanging fruits, but I am somewhat driven away by the need to understand > lintian's internals. Is there a documentation on the data/control flow, or > class diagrams? This would help me a lot. Not that I know of, I suppose Axel/Bastian may be able answer this. Best, Nilesh signature.asc Description: PGP signature
Re: Bug#1071126: ITP: battinfo -- cli tool & nim-lang library to query battery info for GNU/Linux
On Fri, May 17, 2024 at 08:52:00PM +0530, Prasanna Venkadesh wrote: > > > On 15 May 2024 12:33:49 am IST, Nilesh Patra wrote: > >On Tue, May 14, 2024 at 06:31:16PM +, Prasanna Venkadesh wrote: > >>It seems, there is no packaging team available yet for Nim lang. > >>I am not looking for co-maintainers, it's not complex. > > > >There does exist a nim team. > > > > https://salsa.debian.org/nim-team > > Oh! I couldn't find the team in this wiki https://wiki.debian.org/Teams > > In that case, I would like the package to be managed under the team. I also > notice that the package names for libraries follow nim-* pattern. > > How about hybrids, when its both a CLI app & a library? I suppose you need to name a package in a way that has more weight. Is it more likely to be used by end users as a library or application? Name the source package based on what makes more sense. As for battinfo, it makes more sense to have an application name (battinfo instead of nim-battinfo). > > What are my next steps? You could contact the owners of nim team to grant you access to the salsa namespace. If there's too much delay/you are in a hurry, you could use another namespace for now. Best, Nilesh signature.asc Description: PGP signature
Bug#972757: ITP: golang-github-smallfish-simpleyaml -- Go package to interact with arbitrary YAML
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-CC: debian-devel@lists.debian.org * Package name: golang-github-smallfish-simpleyaml Version : 0.0~git20170911.a320310-1 Upstream Author : 陈小玉 * URL : https://github.com/smallfish/simpleyaml * License : BSD-3-Clause Programming Lang: Golang Description : Go package to interact with arbitrary YAML Simpleyaml is Go package to interact with arbitrary YAML and extracting relevant information from the YAML. I shall maintain this package.
Bug#972759: ITP: golang-github-iafan-cwalk -- Concurrent filepath.Walk replacement
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-CC: debian-devel@lists.debian.org * Package name: golang-github-iafan-cwalk Version : 0.0~git20191125.dd7f505-1 Upstream Author : Igor Afanasyev * URL : https://github.com/iafan/cwalk * License : Expat Programming Lang: Golang Description : Concurrent filepath.Walk replacement A concurrent version of filepath.Walk function that scans files in a directory tree and runs a callback for each file. . Since scanning (and callback execution) is done from within goroutines, this may result in a significant performance boost on multicore systems in cases when the bottleneck is the CPU, not the I/O. . Upstream tests showed ~3.5x average speed increase on an 8-core CPU and 8 workers. For measurements, upstream used provided bin/traversaltime.go utility that measures directory traversal time for both concurrent (cwalk.Walk()) and standard (filepath.Walk()) functions. I shall maintain this package.
Bug#974774: ITP: golang-github-alexflint-go-arg -- Struct-based argument parsing in Go
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-CC: debian-devel@lists.debian.org * Package name: golang-github-alexflint-go-arg Version : 1.3.0+ds Upstream Author : Alex Flint * URL : https://github.com/alexflint/go-arg * License : BSD-2-Clause Programming Lang: Golang Description : Struct-based argument parsing in Go The idea behind go-arg is that Go already has an excellent way to describe data structures using structs, so there is no need to develop additional levels of abstraction. Instead of one API to specify which arguments a program accepts, and then another API to get the values of those arguments, go-arg replaces both with a single struct. I shall maintain this package.
Bug#974798: ITP: ggd-utils -- programs for use in ggd
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-CC: debian-devel@lists.debian.org * Package name: ggd-utils Version : 0.0.7+ds Upstream Author : gogetdata * URL : github.com/gogetdata/ggd-utils * License : Expat Programming Lang: Golang Description : programs for use in ggd Takes a genome file and (currently) a .vcf.gz or a .bed.gz and checks that: . * a .tbi is present * the VCF has ""##fileformat=VCF" as the first line * the VCF has a #CHROM header * the chromosome are in the order specified by the genome file (and present) * the positions are sorted * the positions are <= the chromosome lengths defined in the genome file. . As a result, any new genome going into GGD will have a .genome file that will dictate the sort order and presence or absence of the 'chr' prefix for chromosomes I shall maintain this package.
Bug#974834: ITP: gsort -- Sort genomic data
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-CC: debian-devel@lists.debian.org * Package name: gsort Version : 0.1.4-1 Upstream Author : Brent Pedersen * URL : https://github.com/brentp/gsort * License : Expat Programming Lang: Golang Description : sort genomic data gsort is a tool to sort genomic files according to a genomefile. For example, to sort VCF to have order: X, Y, 2, 1, 3, ... and the header needs to be kept at the top. . As a more likely example, if a file nneds to be sorted to match GATK order (1 ... X, Y, MT) which is not possible with any other sorting tool. With gsort one can simply place MT as the last chrom in the ".genome" file. . It will also be useful for getting files ready for use in bedtools. I shall maintain this package.
Bug#977155: ITP: node-thenby: library that helps sorting arrays on multiple keys
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-thenby Version : 1.3.4+git20200720.0fd165a+ds-1 Upstream Author : Teun Duynstee * URL : https://github.com/Teun/thenBy.js * License : Apache-2.0 Programming Lang: Javascript Description : library that helps sorting arrays on multiple keys It allows users to use the native Array::sort() method of javascript, but pass in multiple functions to sort that are composed with firstBy().thenBy().thenBy() style. This is a pre-dependency of q2-taxa I shall maintain this package.
Bug#983185: ITP: golang-github-twotwotwo-sorts -- Parallel and radix sorting in Go
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-CC: debian-devel@lists.debian.org * Package name: golang-github-twotwotwo-sorts Version : 0.0~git20160814.bf5c1f2-1 Upstream Author : Randall Farmer * URL : https://github.com/twotwotwo/sorts * License : BSD-3-clause Programming Lang: Golang Description : Parallel and radix sorting in Go sorts/sortutil sorts common slice types and adds functions to help sort floats. This package helps if sorting huge datasets is a bottleneck. I shall maintain this package.
Bug#983187: ITP: golang-github-will-rowe-nthash -- Go implementation of ntHash
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-CC: debian-devel@lists.debian.org * Package name: golang-github-will-rowe-nthash Version : 0.3.0-1 Upstream Author : Will Rowe * URL : https://github.com/will-rowe/nthash * License : Expat Programming Lang: Golang Description : Go implementation of ntHash This is a Go implementation of the ntHash recursive hash function for hashing all possible k-mers in a DNA/RNA sequence. I shall maintain this package.
Bug#983188: ITP: unikmer -- Toolkit for nucleic acid k-mer analysis
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-CC: debian-devel@lists.debian.org * Package name: unikmer Version : 0.17.2-1 Upstream Author : Wei Shen * URL : https://github.com/shenwei356/unikmer * License : Expat Programming Lang: Golang Description : Toolkit for nucleic acid k-mer analysis unikmer is a golang package and a toolkit for nucleic acid k-mer analysis, providing functions including set operation k-mers optional with TaxIDs but without count information. . K-mers are either encoded (k<=32) or hashed (arbitrary k) into uint64, and serialized in binary file with extension .unik. . TaxIDs can be assigned when counting k-mers from genome sequences, and LCA (Lowest Common Ancestor) is computed during set opertions including computing union, intersecton, set difference, unique and repeated k-mers. I shall maintain this package.
Re: Need Help to build debian package from source code
Hi, On Thu, Mar 11, 2021 at 12:59:25PM +0530, Manikant Singh wrote: > Hi Team, > > I am IIT Kanpur student. I am trying to build debian package from source > code after making some changes to it. > Though I am able to make changes and build debian package successfully, > some of the changes are not reflected. > > I made changes to corefile.c which are correctly reflected > But changes made to histfile.c are not reflected after installation. It's really hard for any of us to help you unless you give details of what you did, and what exactly do you aim to achieve. Which package are you trying to build? Are you trying to make it into official Debian? What changes did you make? Please push your source package somewhere for a review > I have followed this tutorial to create debian package. > https://www.linuxfordevices.com/tutorials/debian/build-packages-from-source Hmm, this looks like a hello world package. Why don't you follow our wiki for the same[1], rather than other tutorials on the web? There are also several wikis for setting up packaging environment et. al. Do you have those things in place on your system? [1]: https://wiki.debian.org/Packaging/Intro > Could you help me with it ? Any help is appreciated. Details are necessary. But that being said, this list isn't the best place for beginner packaging problems. Please use: https://lists.debian.org/debian-mentors (debian-ment...@lists.debian.org) for these questions (unless they are ambiguous or directly deal with policy matters or need the attention of several DDs) > PS: I have tried with configure & make commands. installation works fine > but I need debian package only. Again, details please :-) Please put any follow up mails to debian-mentors mailing list than here Nilesh
Bug#985945: ITP: nthash -- recursive hash function for hashing all possible k-mers in a DNA/RNA sequence
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: nthash Version : 2.2.0-1 Upstream Author : Hamid Mohamadi * URL : https://github.com/bcgsc/ntHash * License : Expat Programming Lang: C++ Description : recursive hash function for hashing all possible k-mers in a DNA/RNA sequence This contains: 1) nttest binary which has options for evaluating runtimes and uniformity for different hashing methods. 2) header-only binary containing the necessary files for implementing nthash function. I intend to maintain this package
Bug#985988: ITP: r-cran-genoplotr -- Plot Publication-Grade Gene and Genome Maps
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: r-cran-genoplotr Version : 0.8.11 Upstream Author : Lionel Guy * URL : https://cran.r-project.org/package=genoPlotR * License : GPL-2+ Programming Lang: R Description : Plot Publication-Grade Gene and Genome Maps Draws gene or genome maps and comparisons between these, in a publication-grade manner. Starting from simple, common files, it will draw postscript or PDF files that can be sent as such to journals. I intend to maintain this package.
Bug#985992: ITP: fastani -- Fast alignment-free computation of whole-genome Average Nucleotide Identity
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: fastani Version : 1.32-1 Upstream Author : Georgia Institute of Technology * URL : https://github.com/ParBLiSS/FastANI * License : Apache-2.0 Programming Lang: C++ Description : Fast alignment-free computation of whole-genome Average Nucleotide Identity ANI is defined as mean nucleotide identity of orthologous gene pairs shared between two microbial genomes. FastANI supports pairwise comparison of both complete and draft genome assemblies. I shall maintain this package.
Bug#986032: ITP: r-bioc-netsam -- Network Seriation And Modularization
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: r-bioc-netsam Version : 1.30.0 Upstream Author : Jing Wang * URL : https://bioconductor.org/packages/NetSAM * License : LGPL-2 Programming Lang: R Description : Network Seriation And Modularization The NetSAM (Network Seriation and Modularization) package takes an edge-list representation of a network as an input, performs network seriation and modularization analysis, and generates as files that can be used as an input for the one-dimensional network visualization tool NetGestalt (http://www.netgestalt.org) or other network analysis. I intend to maintain this package.
Bug#986039: ITP: r-cran-svmisc -- SciViews - Miscellaneous Functions
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: r-cran-svmisc Version : 1.1.0 Upstream Author : Philippe Grosjean * URL : https://cran.r-project.org/package=svMisc * License : GPL-2 Programming Lang: R Description : SciViews - Miscellaneous Functions Miscellaneous functions for SciViews or general use: manage a temporary environment attached to the search path for temporary variables you do not want to save() or load(), test if Aqua, Mac, Win, ... Show progress bar, etc I intend to maintain this package
Bug#986052: ITP: r-bioc-qtlizer -- Comprehensive QTL annotation of GWAS results
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: r-bioc-qtlizer Version : 1.4.0+dfsg Upstream Author : Matthias Munz * URL : https://bioconductor.org/packages/Qtlizer/ * License : GPL-3 Programming Lang: R Description : Comprehensive QTL annotation of GWAS results This R package provides access to the Qtlizer web server. Qtlizer annotates lists of common small variants (mainly SNPs) and genes in humans with associated changes in gene expression using the most comprehensive database of published quantitative trait loci (QTLs). I shall maintain this package
Bug#986067: ITP: r-cran-sampling -- Draw random samples using different sampling schemes
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: r-cran-sampling Version : 2.9 Upstream Author : Yves Tille , Alina Matei * URL : https://cran.r-project.org/package=sampling * License : GPL-2+ Programming Lang: R Description : Draw random samples using different sampling schemes Functions to draw random samples using different sampling schemes are available. Functions are also provided to obtain (generalized) calibration weights, different estimators, as well some variance estimators. I shall maintain this package
Bug#986078: ITP: ssshtest -- stupid simple (ba)sh testing
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: ssshtest Version : 0.0+git20190416.6f5438a Upstream Author : Ryan Layer * URL : https://github.com/ryanlayer/ssshtest.git * License : Expat Programming Lang: Bash Description : stupid simple (ba)sh testing ssshtest is a series of bash functions which help run bash tests in a easy manner. It has functions for checking equality, determine if a string is in stdout, not in stdout, in stderr and many more. I shall maintain this package
Bug#986102: ITP: r-cran-uniqtag -- Abbreviate Strings to Short, Unique Identifiers
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: r-cran-uniqtag Version : 1.0 Upstream Author : Shaun Jackman * URL : https://cran.r-project.org/package=uniqtag * License : Expat Programming Lang: R Description : Abbreviate Strings to Short, Unique Identifiers For each string in a set of strings, determine a unique tag that is a substring of fixed size k unique to that string, if it has one. If no such unique substring exists, the least frequent substring is used. If multiple unique substrings exist, the lexicographically smallest substring is used. This lexicographically smallest substring of size k is called the "UniqTag" of that string. I shall maintain this package
Bug#986137: ITP: pullseq -- Extract sequence from a fasta or fastq
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: pullseq Version : 1.0.2 Upstream Author : Brian C. Thomas * URL : https://github.com/bcthomas/pullseq/releases * License : Expat Programming Lang: C Description : Extract sequence from a fasta or fastq This is a utility to extract sequence from a fasta or fastq. Also helps filter sequences by a minimum length or maximum length. Fast, written in C, using kseq.h library. I shall maintain this package
Bug#986170: ITP: r-bioc-ioniser -- Quality Assessment Tools for Oxford Nanopore MinION data
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: r-bioc-ioniser Version : 2.14.0+dfsg Upstream Author : Mike Smith * URL : https://bioconductor.org/packages/IONiseR * License : Expat Programming Lang: R Description : Quality Assessment Tools for Oxford Nanopore MinION data IONiseR provides tools for the quality assessment of Oxford Nanopore MinION data. It extracts summary statistics from a set of fast5 files and can be used either before or after base calling. In addition to standard summaries of the read-types produced, it provides a number of plots for visualising metrics relative to experiment run time or spatially over the surface of a flowcell. I shall maintain this package
Bug#986242: ITP: fastq-pair -- Rewrites paired end fastq so all reads have a mate to separate out singletons
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: fastq-pair Version : 1.0 Upstream Author : Rob Edwards * URL : https://github.com/linsalrob/fastq-pair * License : Expat Programming Lang: C Description : Rewrites paired end fastq so all reads have a mate to separate out singletons This package rewrites the fastq files with the sequences in order, with matching files for the two files provided on the command line, and then any single reads that are not matched are place in two separate files, one for each original file. . This code is designed to be fast and memory efficient, and works with large fastq files. It does not store the whole file in memory, but rather just stores the locations of each of the indices in the first file provided in memory I shall maintain this package
Bug#986252: ITP: ntcard -- Streaming algorithm to estimate cardinality in genomics datasets
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: ntcard Version : 1.2.2+dfsg Upstream Author : Hamid Mohamadi * URL : https://github.com/bcgsc/ntCard * License : Expat Programming Lang: C++ Description : Streaming algorithm to estimate cardinality in genomics datasets As input it takes file(s) in fasta, fastq, sam, or bam formats and computes the total number of distinct k-mers, F0, and also the k-mer coverage frequency histogram, fi, i>=1. I shall maintain this package
Bug#986295: ITP: r-bioc-ballgown -- Flexible, isoform-level differential expression analysis
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: r-bioc-ballgown Version : 2.22.0+dfsg Upstream Author : Jack Fu * URL : https://bioconductor.org/packages/ballgown * License : Artistic-2.0 Programming Lang: R Description : Flexible, isoform-level differential expression analysis Tools for statistical analysis of assembled transcriptomes, including flexible differential expression analysis, visualization of transcript structures, and matching of assembled transcripts to annotation. I shall maintain this package
Bug#986421: ITP: nxtrim -- Optimized trimming of Illumina mate pair reads
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: nxtrim Version : 0.4.3+dfsg Upstream Author : Illumina, Inc. * URL : https://github.com/sequencing/NxTrim * License : BSD Programming Lang: C++ Description : Optimized trimming of Illumina mate pair reads This package helps rmove Nextera Mate Pair junction adapters and categorise reads according to the orientation implied by the adapter location. I shall maintain this package
Bug#986973: ITP: r-cran-gunifrac -- Generalized UniFrac Distances
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: r-cran-gunifrac Version : 1.1 Upstream Author : Jun Chen * URL : https://cran.r-project.org/package=GUniFrac * License : GPL-3 Programming Lang: R Description : Generalized UniFrac Distances Generalized UniFrac distances for comparing microbial communities. Permutational multivariate analysis of variance using multiple distance matrices. I shall maintain this package
Bug#987263: ITP: node-jmespath -- javascript implementation of JMESPath
Package: wnpp Severity: wishlist Owner: Nilesh Patra X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org * Package name: node-jmespath Version : 0.15.0+dfsg Upstream Author : James Saryerwinnie * URL : https://github.com/jmespath/jmespath.js * License : Apache-2.0 Programming Lang: Javascript Description : javascript implementation of JMESPath Jmespath.js is a javascript implementation of JMESPath, which is a query language for JSON. It will take a JSON document and transform it into another JSON document through a JMESPath expression. I shall maintain this package
Re: Proposal to create unstable-proposed-updates suite for use during freeze
> Hi, > Problem: Currently uploading new upstream versions to unstable during freeze > is discouraged. It means users using unstable don't get new updates and > developers are forced to upload to experimental. Using experimental directly > is risky as it can have changes not ready for unstable also. > Proposed solution: open unstable-proposed-updates with freeze and close it > when freeze is lifted. The packages in this suite can migrate to testing, > this avoids manual reuploads to unstable after freeze is lifted. +1 to this. Please do not take this otherwise For me personally, it was an enormous amount of work (+mess?) to push all my work to unstable. Most of my work was in git, some of it in experimental, it is also hard to keep track of everything. And post uploading to unstable too, its hard to keep (instant) track of the buildds+debci for several dozens of packages I uploaded, and... I'm still not sure if everything I intended to push is indeed pushed (though I did do a few checks by now) I do _not_ blame _anyone_ for it, but I think having such a suite would really help in getting everything gets in as intended, and ofcourse reduce the work post release. However, it'd create a bit of extra work for buildd admins, but it -probably- is worth the effort > Optional: create a companion testing suite say rolling which may be used > during this time and a second Britney instance can manage migration to this > suite. Sounds cool as well Nilesh signature.asc Description: PGP signature
Re: Proposal to create unstable-proposed-updates suite for use during freeze
On 8/20/21 3:51 PM, Stephan Lachnit wrote: > On Fri, Aug 20, 2021 at 11:03 AM Andrey Rahmatullin wrote: >> If you mean keeping unstable as is and uploading stuff for testing into >> t-p-u, that's was always called a bad idea, as nobody tests stuff in >> t-p-u. > > If you don't change anything else, then you're right. If you enable > t-p-u by default for testing installations, this can be mitigated a > bit. Or, instead, if you have a u-p-u suite, and stuff that passes there migrates to t-p-u, this could be completely mitigated. Nilesh
Re: Proposal to create unstable-proposed-updates suite for use during freeze
On 20 August 2021 7:00:15 pm IST, Pirate Praveen wrote: > > >On 20/08/21 4:51 pm, Nilesh Patra wrote: >> Or, instead, if you have a u-p-u suite, and stuff that passes there migrates >> to t-p-u, >> this could be completely mitigated. > >No, that will defeat the purpose of freeze. t-p-u is targeted at testing >without going via unstable. > >If this has to happen then t-p-u should be completely disconnected from >testing during freeze. Well, I meant u-p-u and t-p-u as disconnected suites during freeze. Upload to u-p-u, stuff passing there migrates to t-p-u. When freeze ends, packages from u-p-u and t-p-u auto-migrate to unstable and (new) testing respectively. Do I miss some context here? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Re: Proposal to create unstable-proposed-updates suite for use during freeze
> We already have testing-proposed-updates with a different set of rules. See > https://wiki.debian.org/TestingProposedUpdates Ah, well ofcourse I knew about this. I ended up mis-taking it with the companion suite proposed. Please excuse me for being sloppy there :D -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Looking for Estonian DD-s
Hi Wouter, On 8/25/21 8:36 PM, Wouter Verhelst wrote: > On Mon, Aug 23, 2021 at 04:12:43AM +, Paul Wise wrote: >> On Sun, Aug 22, 2021 at 2:31 PM Aivar Annamaa wrote: >> >>> Is here someone, who can meet me in Tartu, Estonia or is willing to >>> arrange this over the internet? Perhaps I could sign a statement about >>> my identity with Estonian ID card? >> >> I checked the list of lists of Debian locations and there are no >> Debian members that list their location as Estonia. It generally isn't >> accepted to sign keys over the internet or other electronic means. > > Disagree. Why would that be the case? > > By signing an OpenPGP key you certify that you are sufficiently > convinced that the key's holder is who they say they are, and that they > control their key. The easiest way to do that is to meet someone in > person, but that doesn't mean it's the *only* possible way. That is correct, but it varies from Developer to deveoper. Some folks would agree here, while others would not want to sign keys w/o meeting in-person - this is on coherence with the long-ish discussion on -project discussion, which you can find here[1] regarding keysigning in times of COVID. That said, Key Endorsements solve this situation to a large extent[2] if not completely. [1]: https://lists.debian.org/debian-project/2020/08/msg0.html [2]: https://lists.debian.org/debian-devel-announce/2020/11/msg3.html OpenPGP_signature Description: OpenPGP digital signature
No processing/acceptance from dak for some packages?
Hi, I have been trying to upload yaggo 1.5.10-5 for more than 12 hours by now. And I have done this several times by now[look here] It gets to the ftp upload server, sits there for a while, and vanishes eventually. There is however no further processing, neither accept, nor reject. I however, tried uploading golang-github-shenwei356-bio 0.3.2-1, and golang-github-shenwei356-util 0.4.0-1 and these went smoothly. This looks just... weird. Would someone know why this happens? [look here]: All attempts visible here: https://alioth-lists.debian.net/pipermail/debian-med-packaging/2021-September/thread.html Nilesh OpenPGP_signature Description: OpenPGP digital signature
Debian Med video conference tomorrow, Wednesday 2021-11-17 18:00 UTC
Hi, this is the call for the next video conference of the Debian Med team that are an established means to organise the tasks inside our team. We do these conferences twice per month on every 2th and 17th of a month. Usually it takes us only 15-20 minutes depending what we are talking about and how many people are joining. The next meeting is tomorrow 18:00 UTC https://www.timeanddate.com/worldclock/fixedtime.html?msg=Debian+CoViD-19+Biohackathon+Video+Conference&iso=2027T18 The meeting is on the Debian Social channel https://jitsi.debian.social/DebianMedCovid19 These video meetings were started in the Debian Med Biohackathon. The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some action items to be done: - Coordinating work for bioconductor transition (to be started soon) - Effort to package tensorflow and other ML software which is used in several applications that are used to fight COVID-19. The precondition bazel to package tensorflow was a direct consequence of a Debian Med hackathon and it was even acknowledged - Package software that is used to fight COVID-19 which we are listing in some spreadsheet[2]. It reaches from small tools up to complex software packages. There should be targets for everybody who wants to join us. - General Debian Med issues not directly connected to COVID-19 - Updating packages with failing watch files Newcomers are always welcome. Regards, Nilesh signature.asc Description: PGP signature
Setting DKIM locally (Was: Re: Gmail bounce unauthenticated @debian.org addresses)
On Fri, 2022-03-04 at 13:27 +0100, Stephan Lachnit wrote: >> Can you point to some quick guide on how to do this for gmail? The >> support page seems kinda confusing to me. > This usually requires you running your own mail server (for outgoing > mail). > I don't think mail providers like GMail allow you to set up DKIM for > individual IP addresses. I wonder if this is a good opportunity to share what I am doing for this. I do not use gmail anymore, stopped using months back but that does not matter. Also, do not have the b/w to setup own mailserver, so what I do is that I sign my mails "locally" as MUAs can also support DKIM signing, and I send that via SMTP. I use mutt primilarily, and months back I found this smart trick to do so, see this link[1] -- created dkim keys locally, modified that script a little and the .msmtprc and .muttrc a little, and voila! Saw something similar for emacs as well[2] I actually found a very helpful advice in the 'comments' section(by Ucko) of Anarcat's blog[3] that helped. Happy to share more details if someone needs. [1]: https://bbs.archlinux.org/viewtopic.php?id=210976 [2]: https://github.com/BramvdKroef/dotemacs/blob/master/dkim.el [3]: https://anarc.at/blog/2020-04-14-opendkim-debian/ Regards, Nilesh signature.asc Description: PGP signature
Re: Re: No mips64el porterbox?
Quoting Julien Pudyt > Le mardi 01 mars 2022 à 10:34 +0100, Sebastiaan Couwenberg a écrit : >> On 3/1/22 10:28, Julien Puydt wrote: >> > Is there really no mips64el porterbox, or is it only a transitory >> > situation? >> >> eller.debian.org has mips64el chroots. >> > How do I use one of those and not a mipsel one? I'm using > https://dsa.debian.org/doc/schroot/ as usual, and it looks like I'm > getting a mipsel and not mips64el... Just in case this helps, I use this very helpful script from Enrico Zini, you can find it here[1] So for mips64el, just do $ debug-on-porterbox mips64el --host eller.debian.org And voila ... [1]: https://salsa.debian.org/enrico/debug-on-porterbox Regards, Nilesh signature.asc Description: PGP signature
Bug#1008099: ITP: golang-github-cention-sany-utf7 -- UTF7 UTF8 transcoder. With transformer interface.
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-cention-sany-utf7 Version : 0.0~git20170124.26cad61-1 Upstream Author : Sany * URL : https://github.com/cention-sany/utf7 * License : TODO Programming Lang: Go Description: UTF7 UTF8 transcoder This library is a UTF7 UTF8 transdecoder which also provides a transformer interface
Bug#1008101: ITP: golang-github-jhillyerd-enmime -- MIME mail encoding and decoding package for Go
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-jhillyerd-enmime Version : 0.9.3-1 Upstream Author : James Hillyerd * URL : https://github.com/jhillyerd/enmime * License : Expat Programming Lang: Go Description : MIME mail encoding and decoding package for Go enmime is a MIME encoding and decoding library for Go, focused on generating and parsing MIME encoded emails. It is being developed in tandem with the Inbucket email service. . enmime includes a fluent interface builder for generating MIME encoded messages.
Bug#1008103: ITP: golang-github-gatherstars-com-jwz -- Go implementation of the JWZ email threading algorithm
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-gatherstars-com-jwz Version : 1.3.0-1 Upstream Author : GatherStars * URL : https://github.com/gatherstars-com/jwz * License : Apache-2.0 Programming Lang: Go Description : Go implementation of the JWZ email threading algorithm This package provides the original JWZ algorithm to implementors of the 'Threadable interface'. It has been tested against many thousands of emails. . Along with providing the threading capability itself, the package also provides: . + A generic walker, to which you can provide a function to operate upon the nodes in the threaded tree. + A generic sorter, to which you can provide your own comparison function (a byDate example is provided)
Advice for package needing stuff installed in /srv (node-shiny-server)
Hi All, I recently completed the packaging of node-shiny-server, uploaded to NEW and it is there in the archive now (exp suite) The default/expected behaviour just after package install is that as soon as the user starts it and visits (talking about local setup here) localhost: they should be seeing a welcome page. But, the welcome page config (https://github.com/rstudio/shiny-server/tree/master/samples) need to be stored in /srv/shiny-server for this welcome display to happen. Now, I think we as a distribution are not supposed to install anything to /srv as they are reserved explicitly for sys admins. I get a big fat lintian error if I even attempt to do that. Without installing the welcome template to /srv/shiny-server, the user would get a kind of warning message when they visit localhost and that might scare them away. And hence, I need help/opinions to decide what should be done here. (Note that I do not want to patch code to change the default behaviour here.) Any ideas? Regards, Nilesh signature.asc Description: PGP signature
Re: Advice for package needing stuff installed in /srv (node-shiny-server)
On Wed, Apr 27, 2022 at 06:10:37PM +0100, Wookey wrote: > On 2022-04-27 21:40 +0530, Nilesh Patra wrote: > > Hi All, > > > > But, the welcome page config > > (https://github.com/rstudio/shiny-server/tree/master/samples) > > need to be stored in /srv/shiny-server for this welcome display to happen. > > > > (Note that I do not want to patch code to change the default behaviour > > here.) > > Why not? This is what distro packages do - make sure things are installed in > sensible places. > > And patching a path is nice and simple (although you might also have to patch > some docs to match). No, sorry - that'd be a bit too much delta here, meaning shiny-server would be able to serve from two loc (I do not want that) As a distribution I do not want to be doing things completely orthogonal from the way upstream does things. Not to mention that derivatives would inherit directly. Atleast this level of effort does not seem justified for just a welcome page. > I'm not sure what the right path is. The default webserver path in debian > has been /var/www/html/ for decades so I'd use that, but you might > have reasons to make it /var/www/shiny-server instead if you want > shiny-server to be co-installable with other web-servers, and serve different > stuff? Yeah that makes sense but again, same reason as I gave above. Maybe we (me and people in CC) could ask upstream if they are willing to support something like this at their end as well. Regards, Nilesh signature.asc Description: PGP signature
Re: Advice for package needing stuff installed in /srv (node-shiny-server)
On Wed, Apr 27, 2022 at 07:42:29PM +0200, Jonas Smedegaard wrote: > Following FHS 3.0 is required by Debian Policy, and it says that "no > program should rely on a specific subdirectory structure of /srv > existing or data necessarily being stored in /srv". > So if I understand the situation correctly, leaving the package to > depend on filesystem path /srv/shiny-server is a violation of Debian > Policy and needs to be fixed, This was the whole point of my email, and it is the reason I started this email thread in the first place. I would have gone with installing it in /srv w/o seeking advice if it were not a violation. > either by avoiding that code (installing > it only as example files) or patching, or convincing upstream to change > default path. Yes, this was discussed in just the previous conversation (w/ me and wookey) I am looking for more opinions. Essentially if someone has a techincal way/solution to bypass this; or if someone on the list has had experience of working on a package that had similar reqs as shiny-server, it'd be nice to know what they did for their package. Best, Nilesh signature.asc Description: PGP signature
Re: Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
Would it be possible to manually remove this item from the list that generates autoremovals?This is creating an insane amount of noise and emails too.--Best,NileshOn 26/05/22, 12:11 pm Timo Lindfors wrote: On 5/24/22 21:34, Paul Gevers wrote: > https://bugs.debian.org/1011268 (but apparently my first assumption > was wrong and it's another bug, most likely Simon was right. Thanks for the link. I was quite puzzled this morning when I saw several removals messages. I guess I should just wait and hope that the removals don't actually happen. -Timo
Re: Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
On Sun, May 29, 2022 at 01:03:11PM +0530, Pirate Praveen wrote: > 2022, മേയ് 28 8:42:22 PM IST, Thomas Goirand ൽ എഴുതി > >On 5/27/22 09:48, Paul Gevers wrote: > >> Patches welcome. Code is here: > >> https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > >> > > > >IMO, if nobody has time to do it, the person who designed the tool should > >take care of fixing it. Instead of sending 536 mail, it should be sending a > >single mail with 536 entries in it... And it's not the first time I'm > >writing this. > > If we don't have volunteers, may be we can fund this? Thanks for opening issue on the corresponding repo. > I also got 1000s of emails from js team. > I think this is a horribly broken design with very high impact on > contributors. Some just don't contribute in js team because of high volume > emails. I unsubbed off js-team ML a couple of months ago due to similar reasons. I was getting more than 100 emails per day, and it would blow up to a few 100s when there was a mass bug filing/autorm going. I do, however contribute to JS team sometimes. > https://salsa.debian.org/debian/grow-your-ideas/-/issues/36 -- Best, Nilesh signature.asc Description: PGP signature
Bug#1012642: ITP: golang-github-pion-stun -- A Go implementation of STUN
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-stun Version : 0.3.4-1 Upstream Author : Pion * URL : https://github.com/pion/stun * License : Expat Programming Lang: Go implementation of STUN The library is used as a part pion WebRTC implementation. Package stun implements Session Traversal Utilities for NAT (STUN) [RFC5389] protocol and client with no external dependencies and zero allocations in hot paths. Client supports automatic requests and retransmissions.
Bug#1012643: ITP: golang-github-pion-logging -- The logging library used by Pion
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-logging Version : 0.2.2-1 Upstream Author : Pion * URL : https://github.com/pion/logging * License : Expat Programming Lang: Go Description : The logging library used by Pion The logging library used by Pion (library) The library is used as a part of pion WebRTC implementation. Provides easy logging for same. This is needed for pion webrtc and eventually riseup-vpn.
Bug#1012644: ITP: golang-github-pion-randutil -- Helper library for cryptographic and mathmatical randoms
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-randutil Version : 0.1.0-1 Upstream Author : Pion * URL : https://github.com/pion/randutil * License : Expat Programming Lang: Go Description: Helper library for cryptographic and mathmatical randoms Helper library for cryptographic and mathmatical randoms. Used in pion webrtc implementation.
Bug#1012646: ITP: golang-github-pion-rtcp -- A Go implementation of RTCP
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-rtcp Version : 1.2.9-1 Upstream Author : Pion * URL : https://github.com/pion/rtcp * License : Expat Programming Lang: Go Description : A Go implementation of RTCP See (/DESIGN.md) for an overview of features and future goals. . Roadmap . The library is used as a part of our WebRTC implementation. Please refer to that roadmap (https://github.com/pion/webrtc/issues/9) to track our major milestones. . Community . Pion has an active community on the Golang Slack (https://invite.slack.golangbridge.org/). Sign up and join the **#pion** channel for discussions and support. You can also use Pion mailing list (https://groups.google.com/forum/#!forum/pion). . We are always looking to support **your projects**. Please reach out if you have something to build! . If you need commercial support or don't want to use public methods you can contact us at t...@pion.ly (mailto:t...@pion.ly) . Contributing . Check out the **contributing wiki** to join the group of amazing people making this project possible: . License . MIT License - see (/LICENSE) for full text TODO: perhaps reasoning
Bug#1012645: ITP: golang-github-pion-rtp -- A Go implementation of RTP
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-rtp Version : 1.7.5-1 Upstream Author : Pion * URL : https://github.com/pion/rtp * License : Expat Programming Lang: Go Description : Go implementation of RTP (library) Golang based implementation of Real-time Transport Protocol (RTP) . The Real-time Transport Protocol (RTP), defined in RFC 3550, is an IETF standard protocol to enable real-time connectivity for exchanging data that needs real-time priority.
Bug#1012648: ITP: golang-github-pion-interceptor -- Pluggable RTP/RTCP processors for building real time communication
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-interceptor Version : 0.1.11-1 Upstream Author : Pion * URL : https://github.com/pion/interceptor * License : Expat Programming Lang: Go Description : Pluggable RTP/RTCP processors for building real time communication Interceptor is a framework for building RTP/RTCP communication software. This framework defines a interface that each interceptor must satisfy. These interceptors are then run sequentially. It also provides common interceptors that will be useful for building RTC software. . This package was built for pion/webrtc but is consumable by anyone.
Bug#1012650: ITP: golang-github-pion-udp -- A connection-oriented listener over a UDP PacketConn
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-udp Version : 0.1.1-1 Upstream Author : Pion * URL : https://github.com/pion/udp * License : Expat Programming Lang: Go Description : connection-oriented listener over a UDP PacketConn This package is used in the pion/DTLS and pion/SCTP transport to provide a connection-oriented listener over a UDP.
Bug#1012652: ITP: golang-github-pion-transport -- Transport testing for pion
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-trasport Version : 0.13.0-1 Upstream Author : Pion * URL : https://github.com/pion/transport * License : Expat Programming Lang: Go Description : Transport testing for Pion Provides multiple plugins for pion/webrtc like a VPN layer, eplaydetector providing packet replay detection algorithm etc.
Bug#1012653: ITP: golang-github-pion-sctp -- A Go implementation of SCTP
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-sctp Version : 1.8.2-1 Upstream Author : Pion * URL : https://github.com/pion/sctp * License : Expat Programming Lang: Go Description : A Go implementation of SCTP Golang based implementation of Stream Control Transmission Protocol . SCTP (Stream Control Transmission Protocol) is an IETF standard for a transport protocol which enables the reliable, in-order transmission of messages while offering congestion control, multi- homing, and other features to improve reliability and stability of the connection. It's used for sending traditional telephone calls over the Internet, but is also used for WebRTC data.
Bug#1012660: ITP: golang-github-pion-dtls -- DTLS 1.2 Server/Client implementation for Go
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-dtls Version : 2.1.5-1 Upstream Author : Pion * URL : https://github.com/pion/dtls * License : Expat Programming Lang: Go Description : DTLS 1.2 Server/Client implementation for Go Native DTLS 1.2vimplementation in the Go programming language. . This is currently targeting DTLS 1.2, and the most modern/common cipher suites. Current features are: . * DTLS 1.2 Client/Server * Key Exchange via ECDHE(curve25519, nistp256, nistp384) and PSK * Packet loss and re-ordering is handled during handshaking * Key export (RFC 5705 (https://tools.ietf.org/html/rfc5705)) * Serialization and Resumption of sessions * Extended Master Secret extension (RFC 7627) * ALPN extension (RFC 7301)
Bug#1012661: ITP: golang-github-pion-datachannel -- A Go implementation of WebRTC Data Channels
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-datachannel Version : 1.5.2-1 Upstream Author : Pion * URL : https://github.com/pion/datachannel * License : Expat Programming Lang: Go Description: A Go implementation of WebRTC Data Channels Golang library implementing WebRTC Data Channels. WebRTC data channel lets you send text or binary data over an active connection to a peer
