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: 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: 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: 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
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: 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#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: 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
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: 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: 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
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: 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
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
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
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.
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.
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
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: 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: 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: 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
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
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: 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
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: 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: 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: 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: 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
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
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#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#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#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#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#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#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.
Re: how to skip some archs for autopkgtests
Hi Jonas, On Fri, Feb 03, 2023 at 04:07:09PM +0100, Jonas Smedegaard wrote: > How do I skip some known impossible to check architectures in > autopkgtests? > > Concretely, the packages src:rust-hyper-rustls and > src:rust-rustls-native-certs both fail on powerpc64 and s390x, due to > missing packages on those architectures: > > https://tracker.debian.org/pkg/rust-hyper-rustls > https://tracker.debian.org/pkg/rust-rustls-native-certs > > It is *not* that the packages are unusable on those architectures - or > at least that is yet unknown. Instead, the underlying complexity is > that the autopkgtest-dependencies are architecture-independent source > code but packaged as architecture-dependent and not offered on those > architectures. > > Any thoughts on how¹ to proceed? There is a "skip-not-installable" that you could decleare in d/t/control for these packages (for the corresponding tests that suffer from uninst test deps), more details here[1] Another way is to declare "Architecture: !s390x !ppc64el" in d/t/control but I think this is in-appropriate for the said case. [1]: https://people.debian.org/~eriberto/README.package-tests.html -- Best, Nilesh signature.asc Description: PGP signature
Re: Should singularity-container make it to next release?
On 26 January 2023 10:26:05 pm IST, Andreas Tille wrote: >Am Thu, Jan 26, 2023 at 08:22:15AM -0700 schrieb Sam Hartman: >> >> Well, if you and a group of people believe you can maintain it in stable >> given the additional discussions ith upstream, then explicitly say >> you're ready to sign up to maintaining in stable. >> I think that's the kind of sing-up-to-do-the-work that the security and >> release team are waiting for. > >I'd be happy if singularity would be in stable. I'm not sure how far >I can help out since I'm lacking competence in Go but if needed I might >contribute to my limited skills. I'd be happy to have it in stable as well, but by no means am I a professional go programmer, and to be really honest I've fixed CVEs only in one or two instances. Thus, I find it impractical to commit myself (alone) to maintaining it in stable. But if someone is willing to help out on these fronts, I'd be glad to know. -- Best, Nilesh
Re: Should singularity-container make it to next release?
On Thu, Jan 26, 2023 at 09:51:21AM +0100, Paul Gevers wrote: > On 25-01-2023 20:14, Moritz Muehlenhoff wrote: > > On Sat, Jan 21, 2023 at 08:34:40PM +0100, Salvatore Bonaccorso wrote: > > > So in my understanding of the above the situation around > > > singularity-container, > > > which lead for buster to https://bugs.debian.org/917867 and keeping it > > > out of > > > the stable release, did not really change in the aspect of beeing able to > > > patch > > > vulnerabilities to the stable branch once upstream versions moved on, is > > > this > > > correct interpretation? In context from #917867, it was even in stretch at > > > first, but needed to be removed after stretch was released in a point > > > release. I guess something that changed since then is that upstream is aware about it and can help a bit with backporting. However the onus to maintain it in stable is still on the maintainer and security@ (to some extent) It is bit of a high-effort maintainance (in stable) as far as I can see. > I have forwarded this message as bug #1029669. Unless we get more confidence > that it's supportable, let's keep it out of stable. I guess fasttrack [1] is > currently the best forum to supply singularity-container to our users. Since I had done quite a bit of work on this, I'm a sad to see this happen, as fasttrack still has much less visibility / availability than an official stable release, or even backports. > [1] https://fasttrack.debian.net/ -- Best, Nilesh signature.asc Description: PGP signature
Re: Should singularity-container make it to next release?
Hi, On Wed, Oct 12, 2022 at 09:38:27PM +0530, Nilesh Patra wrote: > src:singularity-container was lying around in a bad shape for several years > and had missed 2 debian releases until me and Andreas picked it up again. > It is currently in a reasonably good condition. I was excited to have it in > stable release again, but I have a couple of doubts over it. > > 1. A little background: > singularity-container sync the code from the upstream codebase for sylabs[1] > and there also exists a community-maintained fork called apptainer. > Sylabs singularity CE seems to sync up a lot of code with apptainer in > many releases. The apptainer community announcement page about the split also > hints towards saying similar stuff, but this is all the more confusing as it > is > hard to draw a line b/w them. > A while back, I found a reddit comment[4] from the current maintainer of > sylabs > singularity which has a statement: > > | At this point there it appears that Apptainer 1.0 will be very close > | to SingularityCE 3.9 which we released recently, given > | the picks from SingularityCE into the code base. > > So I am absolutely confused if it makes sense to package apptainer at all or > should I just let it be? > > 2. The _more_ important question: > There are CVEs being discovered in singularity-container -- no biggie. > However, some > of the CVE fixes are simply _hidden_ from the user view. > As a concrete example, there was > a "CVE-2021-33622" opened[5] against singularity-CE, and the only information > upstream provides is that it has been fixed in the 3.7.x of the community > edition > but there is no information about _what_ the fix was. > I tried asking upstream about this but did not get a pin-pointed reply[6] and > it > appears that upstream is somewhat discrete about these. > > A similar bug has been fixed in the latest release, CVE-2022-39237 here[7] > but it > does not say _what_ patch fixes it exactly. > And the problem is that apptainer has addressed the exact same bug in > its latest release and they too are un-clear about it[8]. > > So my fear is that: Once singularity-container hits stable release, and there > is > a CVE being found. It'd be a hellhole for me/others to find what exactly > fixed the CVE (unless it is being clearly stated), and apply that. The only > option left would be to upgrade the package to fix the CVE and I don't know if > release team would allow that. > > And I don't see this problem getting fixed with apptainer as well, since there > are bugs that both the codebases would keep on inheriting from one another. > And thus I am not sure if this situation is OK for stable release or not. > > OTOH, singularity is an important package and many users would be happy to > have > it in stable -- I have even got a couple of bug reports/texts saying > people are happy to see a new update of singularity. I started this thread a while back, and decided to simply ask upstream about what their opinion is[9] It looks like the situation still not fully certain on whether to let singularity make it to stable or not. I'd appreciate if someone on the list could chime in and give an opinion on if they consider it do-able or not for upcoming bookworm release. I've kept upstream in CC to avoid ping-pong, and thanks David for a nice elaborate reply. > [1]: https://github.com/sylabs/singularity > [2]: https://github.com/apptainer/apptainer > [3]: https://apptainer.org/news/community-announcement-20211130/ > [4]: > https://www.reddit.com/r/HPC/comments/r61bto/comment/hmspn72/?utm_source=share_medium=web2x=3 > [5]: > https://support.sylabs.io/support/solutions/articles/4287130-3-5-8-security-release-cve-2021-33622- > [6]: https://github.com/sylabs/singularity/issues/586 > [7]: https://github.com/sylabs/sif/security/advisories/GHSA-m5m3-46gj-wch8 > [8]: https://github.com/apptainer/apptainer/releases/tag/v1.1.2 [9]: https://github.com/sylabs/singularity/issues/1235#issuecomment-1375334909 -- Best, Nilesh signature.asc Description: PGP signature
Re: Migration bug ?
Hi, On 12 December 2022 11:58:27 am IST, Yadd wrote: >Hi, > >I pushed 2 versions of node-rollup since December 09, but migration process >never started (at least looking at tracker.d.o). Is there something broken ? You can track the migration here: https://qa.debian.org/excuses.php?package=node-rollup The tracker will reflect a news entry once it migrates. And yes, I asked in the IRC yesterday, the excuses section of the tracker is broken, or I should say frozen (for instance check the tracker link for golang-gonum-v1-plot) but the news section works fine. The migration for rollup is in progress. Thanks, Nilesh
Re: Bug#1023083: ITP: libquazip1-qt5 -- Qt/C++ wrapper over minizip - Version 1 (Qt5)
On 10/30/22 09:38, Ben Westover wrote: Hello Nilesh, You're replying to an old message by Filippo; I'm not *trying* to do anything. I have already explained to Filippo that this is not the correct way to do that. Had you simply linked the bug report/alioth-list mails in your original ITP, it'd have prevented this admittedly un-necessary correspondence. It was not clear at all in the original ITP bug as to what the entire situation is, but I understand now. Thanks for working on it! -- Best, Nilesh
Re: Bug#1023083: ITP: libquazip1-qt5 -- Qt/C++ wrapper over minizip - Version 1 (Qt5)
On Sun, Oct 30, 2022 at 03:12:18AM +, Ben Westover wrote: > On 10/29/22 1:20 PM, Filippo Rusconi wrote: > > On Tue, Sep 13, 2022 at 03:40:13PM +, Ben Westover wrote: > >> On 9/13/22 8:28 AM, Filippo Rusconi wrote: > >>>> I'd support any attempt to move the current libquazip[1] away > >>>> from Debian Med team where it is just by chance since it was a > >>>> dependency of some of our packages. It does not make any sense to > >>>> maintain it inside the Debian Med team and I would love to hand it > >>>> over. All maintainers except me do not respond to pings any more > >>>> and thus can be droped from the list of Uploaders. > >>> > >>> I understand that, let's take it away from Debian Med and put it in > >>> Debian at > >>> large. Ben, if you would do the update, then I'd go over it and upload > >>> it. That > >>> would be very good. If you want to take it out of debian-med team, the right way is to * ask * the med-team to transfer it somewhere else. What you are trying to do here is considered as a hostile takeover. > >> As stated above, the existing QuaZip *0.9* package (libquazip) and my > >> new QuaZip *1.3* package (libquazip1-qt6) are unrelated. While they are > >> both QuaZip packages, they are separate since QuaZip 0.x and 1.x are > >> supposed to coexist, much like Qt5 and Qt6. The orphaning of libquazip > >> is unrelated to my new libquazip1-qt6 being uploaded. My new package is > >> outside of any team. > >> The correct procedure here is to orphan libquazip, and anyone who is > >> interested can adopt it. Why should the package be orphaned? > >> Again, my new package libquazip1-qt6 is not > >> related to the existing libquazip package or the Med Team. There are already some changes committed to git for version 1.1 in the med team package. If we happened to miss seeing this ITP, we might have ended up stepping on your toes. -- Best, Nilesh signature.asc Description: PGP signature
Re: Transition: pkg-config to pkgconf: next steps
Hi, On Thu, Oct 20, 2022 at 11:25:13AM +0100, Andrej Shadura wrote: > The version of pkgconf package providing the pkg-config binary package has > been sitting in experimental for some time. I think I have tested the upgrade > process quite extensively, but it would still be great if someone else could > have a look. In any case, my plan is to upload it to unstable in about two > weeks time. I will then commence another round of rebuilds; meanwhile I will > be working on fixing issues I’ve already run into: > > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=andrewsh%40debian.org=pkgconf-rebuild-ftbfs Since jellyfish is listed at that link, I tried to dig further and it "seems" that pkgconf does not honor PKG_CONFIG_SYSROOT_DIR. More details at #1022087 -- Best, Nilesh signature.asc Description: PGP signature
Should singularity-container make it to next release?
Hi, src:singularity-container was lying around in a bad shape for several years and had missed 2 debian releases until me and Andreas picked it up again. It is currently in a reasonably good condition. I was excited to have it in stable release again, but I have a couple of doubts over it. 1. A little background: singularity-container sync the code from the upstream codebase for sylabs[1] and there also exists a community-maintained fork called apptainer. Sylabs singularity CE seems to sync up a lot of code with apptainer in many releases. The apptainer community announcement page about the split also hints towards saying similar stuff, but this is all the more confusing as it is hard to draw a line b/w them. A while back, I found a reddit comment[4] from the current maintainer of sylabs singularity which has a statement: | At this point there it appears that Apptainer 1.0 will be very close | to SingularityCE 3.9 which we released recently, given | the picks from SingularityCE into the code base. So I am absolutely confused if it makes sense to package apptainer at all or should I just let it be? 2. The _more_ important question: There are CVEs being discovered in singularity-container -- no biggie. However, some of the CVE fixes are simply _hidden_ from the user view. As a concrete example, there was a "CVE-2021-33622" opened[5] against singularity-CE, and the only information upstream provides is that it has been fixed in the 3.7.x of the community edition but there is no information about _what_ the fix was. I tried asking upstream about this but did not get a pin-pointed reply[6] and it appears that upstream is somewhat discrete about these. A similar bug has been fixed in the latest release, CVE-2022-39237 here[7] but it does not say _what_ patch fixes it exactly. And the problem is that apptainer has addressed the exact same bug in its latest release and they too are un-clear about it[8]. So my fear is that: Once singularity-container hits stable release, and there is a CVE being found. It'd be a hellhole for me/others to find what exactly fixed the CVE (unless it is being clearly stated), and apply that. The only option left would be to upgrade the package to fix the CVE and I don't know if release team would allow that. And I don't see this problem getting fixed with apptainer as well, since there are bugs that both the codebases would keep on inheriting from one another. And thus I am not sure if this situation is OK for stable release or not. OTOH, singularity is an important package and many users would be happy to have it in stable -- I have even got a couple of bug reports/texts saying people are happy to see a new update of singularity. Any opinions? [1]: https://github.com/sylabs/singularity [2]: https://github.com/apptainer/apptainer [3]: https://apptainer.org/news/community-announcement-20211130/ [4]: https://www.reddit.com/r/HPC/comments/r61bto/comment/hmspn72/?utm_source=share_medium=web2x=3 [5]: https://support.sylabs.io/support/solutions/articles/4287130-3-5-8-security-release-cve-2021-33622- [6]: https://github.com/sylabs/singularity/issues/586 [7]: https://github.com/sylabs/sif/security/advisories/GHSA-m5m3-46gj-wch8 [8]: https://github.com/apptainer/apptainer/releases/tag/v1.1.2 -- Best, Nilesh signature.asc Description: PGP signature
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Thu, Sep 15, 2022 at 08:22:52AM -0400, Michael Stone wrote: > On Tue, Sep 13, 2022 at 07:25:12PM +0200, Michael Biebl wrote: > > Am 13.09.22 um 18:17 schrieb Antoine Beaupré: > > > I also have the feeling that pipewire has already gone beyond what > > > pulseaudio is capable of in terms of Bluetooth support, but I might be > > > mistaken on that. > > > > Interesting. What do you have in mind here? Supported codecs? AptX? > > I had more success with PA in the past here, but that experience is > > anecdotal. > > PA also hasn't stood still, As far as I can see, the latest "new upstream" upload to unstable was in "2021-08-25" which is more than an year from now, post which there have been few bug fix uploads. More notable upload has been the one that enables gstreamer support I'm not sure if this is what you are pointing towards with "hasn't stood still" https://tracker.debian.org/news/1306307/accepted-pulseaudio-150dfsg1-4-source-into-unstable/ Ofcourse the maintainers of this package are doing an excellent job but from upstream release pov, it is still kind of standing still. (There's however a new release in experimental ATM) > and PA+bluetooth is now working much better than > it did even a few months ago. This sounds a little vague. What does "much better" mean? What exactly changed (for you)? -- Best, Nilesh signature.asc Description: PGP signature
Re: General resolution: non-free firmware
On Tue, Aug 30, 2022 at 08:28:15PM +, Thorsten Glaser wrote: > Steve McIntyre dixit: > > >Please go and *read* and *respond* in debian-vote. The discussion is > >there, not here. > > I wrote where the Reply-To pointed to. Perhaps if that had been > correct… It was clearly written that the discussion is happening in -vote, and you are supposed to reply there. How much more clarity do you need? Please take this thread there, not here. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1018701: ITP: golang-github-marten-seemann-qtls-go1-19 -- Go standard library TLS 1.3 implementation, modified for QUIC (Go-1.19)
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-marten-seemann-qtls-go1-19 Version : 0.1.0-1 Upstream Author : Marten Seemann * URL : https://github.com/marten-seemann/qtls-go1-19 * License : BSD-3-clause Programming Lang: Go Description : Go standard library TLS 1.3 implementation, modified for QUIC. For Go 1.19. This package is needed to make golang-github-lucas-clemente-quic-go work with newer Go version (1.19).
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
On Sat, Aug 27, 2022 at 09:50:41AM +0200, Gard Spreemann wrote: > > Strong motivations such as "I use this package, seriously" are not > > likely to wear out very easily through time. Packages maintained > > with a strong motivation are better cared among all packages in our > > archive. > > I humbly disagree. Even from my own point of view, I may well be very > motivated to package something I use seriously all the time, > seriously. But then I see its dependency chain of 10 unpackaged items, > start thinking about the probability that they'll *all* clear the NEW > queue, and how long that would take, and I give up. In that case, writing to FTP masters or sending a message on #debian-ftp helps sometimes, but we still need to patiently wait anyway. In my personal experience, when I upload a large amount of packages to new, FTP masters are quick to accept that. I recently packaged something and uploaded 17 new packages, everything got in within a week. And I remember at the time of bullseye release, I had 52-53 (!!) packages in NEW and they did get `processed' in 3-4 months. So I do think that FTP masters react to maintainers when they push a good amount of stuff to new. That said, I also once had a package that waited for 11 months in NEW. In any case, I agree with Lumin's point here. > And then there's the > problem of attracting smaller contributions, as mentioned above: I > really believe that people get put off from putting in 30 minutes of > work for a nice MR on Salsa if they can't expect their work to hit the > archives for months and months (suppose for example they contributed to > a package whose SONAME is being bumped). Yeah, that's a bit of a bummer. It specifically gets discouraging for newcomers who end up waiting for a long time before their contribution gets in. > > Why not calm down, and try to do something else as interesting > > as Debian development when waiting for the NEW queue? > > Sure. That's what I do. My list of joyful and less joyful things to fill > my days with is enormous. **BUT: I worry for the project if our solution > to the problem at hand is "maybe just contribute less to Debian".** Is > that really what we want? Or maybe it means 'work on something else' while your package completes its trip in new and back from vacation. -- Best, Nilesh signature.asc Description: PGP signature
Re: Need a buildd build after trip through NEW -- best practice?
[My earlier mail went blank, not sure what's up with K-9] On 24 August 2022 3:29:10 am IST, Steven Robbins wrote: >The binary upload cannot transition to testing -- a buildd binary build is >required. So far as I know -- assuming [1] is still up-to-date, this means a >nuisance upload just bumping the debian revision from -1 to -2. Is this still >the recommended practice? Yes. >I've also been wondering about the "Give Back" action button on the buildd log >page. It doesn't work in this case because "Package in state Installed, >cannot give back. ✗". Yes, because it already succeeded. You can only `give back' for builds that failed. > Wondering if the logic can be modified to also check >whether the build was done on a buildd -- e.g. check whether the logs column >contains "no log". If it wasn't a buildd build, can the giveback be allowed? It seems intentional, so that source-only uploads are really done. But you might want to ask wanna-build team (I am not a member/admin) here[2] >[1] https://wiki.debian.org/SourceOnlyUpload [2]: https://lists.debian.org/debian-wb-team/ -- Best, Nilesh
Re: Need a buildd build after trip through NEW -- best practice?
On 24 August 2022 3:29:10 am IST, Steven Robbins wrote: >The binary upload cannot transition to testing -- a buildd binary build is >required. So far as I know -- assuming [1] is still up-to-date, this means a >nuisance upload just bumping the debian revision from -1 to -2. Is this still >the recommended practice? Yes. >I've also been wondering about the "Give Back" action button on the buildd log >page. It doesn't work in this case because "Package in state Installed, >cannot give back. ✗". This was probably done to ensure only source-only uploads make it through. >Wondering if the logic can be modified to also check >whether the build was done on a buildd -- e.g. check whether the logs column >contains "no log". If it wasn't a buildd build, can the giveback be allowed? It was probably intentional. In any case, you might want to CC the wanna-build team ML as well[2] >[1] https://wiki.debian.org/SourceOnlyUpload [2]: https://lists.debian.org/debian-wb-team/ -- Regards, Nilesh
Re: Is there a mip64el machine available for debugging?
On Mon, Aug 22, 2022 at 08:08:30AM +0200, Sebastiaan Couwenberg wrote: > On 8/22/22 07:15, Steve Robbins wrote: > > Oh. I did use Eller -- but the architecture is listed as mipsel. I need > > mips64el > > eller has mips64el chroots too, just like there are i386 chroots on the > amd64 porterbox: > > sebastic@eller:~$ schroot -l | grep mips64el > chroot:bookworm-backports_mips64el-dchroot > chroot:bookworm_mips64el-dchroot > chroot:bullseye-backports_mips64el-dchroot > chroot:bullseye_mips64el-dchroot > chroot:buster-backports_mips64el-dchroot > chroot:buster_mips64el-dchroot > chroot:experimental_mips64el-dchroot > chroot:sid_mips64el-dchroot > source:bookworm-backports_mips64el-dchroot > source:bookworm_mips64el-dchroot > source:bullseye-backports_mips64el-dchroot > source:bullseye_mips64el-dchroot > source:buster-backports_mips64el-dchroot > source:buster_mips64el-dchroot > source:experimental_mips64el-dchroot > source:sid_mips64el-dchroot > > https://dsa.debian.org/doc/schroot/ For more ease, you could consider to use Enrico's script here[1] All you then need is $ debug-on-porterbox mips64el --host eller.debian.org [1]: https://salsa.debian.org/enrico/debug-on-porterbox -- Best, Nilesh signature.asc Description: PGP signature
Re: Epoch for node-markdown-it
On 8/19/22 23:02, Jonas Smedegaard wrote: Quoting Nilesh Patra (2022-08-19 17:45:57) JTFR - Upstream released 12.0.4 in 2020, and they have reached 13.0.1 _now_ (after two years) Going by previous releases, the delta between one major release is atleast an year. Seems to me that roughly... 13 has so far lasted 4 months, 12 lasted 18 months, 11 lasted 5 months, 10 lasted 8 months, 9 lasted 2 months, 8 lasted 36 months. Let upstream be erratic for one-two Debian releases, and this issue might solve itself. How do you conclude that? The data you present above says otherwise. 13->22 is a big jump and does not look like a 2-debian release thing. And so reaching to 22.2.3 will take a very long time as well, if not _forever_ and that would mean keeping up with +really for several years. I do not think tagging this along with really is much better than adding in an epoch. (I personally find the former a bit more ugly for my taste) Neither "1:" nor "22.really." as prefix is beautiful, but as already stated the former is forever. Why does the former even exist then? The only reverse-dependency of this package is "node-prosemirror-markdown" and so it would not be too much work if an epoch is introduced. ...but it would be even less work to *not* introduce an epoch. How much work does adding a "1:" in d/control for a single package take? I think this is bike-shedding here :) Quoting Nilesh Patra (2022-08-19 18:21:14) Is tagging this along for so many years really is more worthy than an epoch? What is worthy about introducing an epoch here? What is worthy about even the existence of epoch then? In any case, I think I am done keeping my point here. -- Best, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: Epoch for node-markdown-it
On Fri, Aug 19, 2022 at 09:51:14PM +0530, Nilesh Patra wrote: > > As Jonas said, an epoch cannot be undone, +really can, regardless when this > > is going to happen. > > I think ignoring when it happens is not the right way to see it. Even if we > assume that > upstream is going to work on this with the same effort, we will still end up > waiting > for a _decade_ for the +really to go away. > > Is tagging this along for so many years really is more worthy than an epoch? > Note that the package might even go stale in such a long time, thought. BTW, Jonas also said, "is it unlikely that they will reach 22 in the foreseeable future?" And the answer to that is a "Yes", so :) -- Best, Nilesh signature.asc Description: PGP signature
Re: Epoch for node-markdown-it
Hi Andrej, On Fri, Aug 19, 2022 at 05:50:46PM +0200, Andrej Shadura wrote: > Hi, > > On Fri, 19 Aug 2022, at 17:45, Nilesh Patra wrote: > >> I agree, adding an epoch in this package doesn’t seem appropriate or > >> necessary. > > > > JTFR - Upstream released 12.0.4 in 2020, and they have reached 13.0.1 > > _now_ (after two years) > > Going by previous releases, the delta between one major release is > > atleast an year. > > > > And so reaching to 22.2.3 will take a very long time as well, if not > > _forever_ > > and that would mean keeping up with +really for several years. I do > > not think tagging this along with really is much better than adding in an > > epoch. > > (I personally find the former a bit more ugly for my taste) > > As Jonas said, an epoch cannot be undone, +really can, regardless when this > is going to happen. I think ignoring when it happens is not the right way to see it. Even if we assume that upstream is going to work on this with the same effort, we will still end up waiting for a _decade_ for the +really to go away. Is tagging this along for so many years really is more worthy than an epoch? Note that the package might even go stale in such a long time, thought. > Both are ugly solutions, but an epoch is also evil, unlike +really Hah, ;-D -- Best, Nilesh signature.asc Description: PGP signature
Re: Epoch for node-markdown-it
On Fri, Aug 19, 2022 at 04:43:17PM +0200, Andrej Shadura wrote: > Hi, > > On Fri, 19 Aug 2022, at 16:37, Jonas Smedegaard wrote: > > Quoting Yadd (2022-08-19 10:21:17) > >> some months ago, a bad upstream tag changed node-markdown-it version to > >> 22.2.3 instead of 10.0.0. So I'd like to change node-markdown-it version > >> into 1:13.0.1 > > > > Since upstream is already at 10, is it unlikely that they will reach 22 > > in the foreseeable future? > > > > What I am getting at is that introducing an epoch is a pain *forever* > > (all dependent packages must then *forever* remember to add "1:" prefix) > > wheread converting the accidental too-high major version into > > pseudo-epoch "22.really." will last only until upstream catches up. > > I agree, adding an epoch in this package doesn’t seem appropriate or > necessary. JTFR - Upstream released 12.0.4 in 2020, and they have reached 13.0.1 _now_ (after two years) Going by previous releases, the delta between one major release is atleast an year. And so reaching to 22.2.3 will take a very long time as well, if not _forever_ and that would mean keeping up with +really for several years. I do not think tagging this along with really is much better than adding in an epoch. (I personally find the former a bit more ugly for my taste) The only reverse-dependency of this package is "node-prosemirror-markdown" and so it would not be too much work if an epoch is introduced. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1016677: ITP: golang-github-templexxx-cpu -- internal/cpu in Go ( add AVX512)
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-templexxx-cpu Version : 0.0.9-1 Upstream Author : Temple3x * URL : https://github.com/templexxx/cpu * License : BSD-3-clause Programming Lang: Go Description : Provides CPU related information in Go internal/cpu(in Go standard lib) with these detections: . * AVX512 * Cache Size * Invariant TSC . It also provides: . * False sharing range, see X86FalseSharingRange for X86 platform. * TSC frequency * Name * Family & Model
Bug#1016676: ITP: golang-github-templexxx-xorsimd -- XOR code engine in pure Go, more than 270GB/S per core
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-templexxx-xorsimd Version : 0.4.1-1 Upstream Author : Temple3x * URL : https://github.com/templexxx/xorsimd * License : Expat Programming Lang: Go Description : XOR code engine in pure Go, more than 270GB/S per core Package xor implements a XOR code engine in pure Go. It can deliver more than 270GB/S per core.
Bug#1016065: ITP: golang-github-shenwei356-unik -- A k-mer serialization package for Golang
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-shenwei356-unik Version : 5.0.1-1 Upstream Author : Wei Shen * URL : https://github.com/shenwei356/unik * License : Expat Programming Lang: Go Description : A k-mer serialization package for Golang (library) This package provides k-mer serialization methods for the package kmers TaxIds of k-mers are optionally saved, while there's no frequency information. . K-mers (represented in uint64 in RAM ) are serialized in 8-Byte (or less Bytes for shorter k-mers in compact format, or much less Bytes for sorted k-mers) arrays and optionally compressed in gzip format with extension of .unik.
Bug#1016061: ITP: golang-github-shenwei356-kmers -- bit-packed k-mers methods for Golang
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-shenwei356-kmers Version : 0.1.0-1 Upstream Author : Wei Shen * URL : https://github.com/shenwei356/kmers * License : Expat Programming Lang: Go Description : bit-packed k-mers methods for Golang (library) This package provides manipulations for bit-packed k-mers (k<=32, encoded in uint64).
Re: how about telegram channel
On 7/20/22 2:35 PM, Stephan Verbücheln wrote: IMHO, a (official) communcation channel for a project like Debian has two requirements which are not met by Telegram: 1. Infrastructure should be controlled by the project. 2. Protocols should be standardized and universal. Ideally, users should have free choice of their clients for various platforms. +1 Mailing list and IRC meet those criterea. Telegram does not. and Matrix too. -- Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: how about matrix channel
On Wed, Jul 20, 2022 at 11:51:45AM +0800, xiao sheng wen(肖盛文) wrote: > Hi, > > Is there a GUI Desktop client to use https://element.debian.social ? Yes, nheko in the archive[1] There is element desktop as well, which is not packaged yet, and whose unofficial (upstream packaging) `.deb's are here[2] in case you want these (not very recommended though) [1]: https://tracker.debian.org/pkg/nheko [2]: https://element.io/get-started#linux-details -- Regards, Nilesh signature.asc Description: PGP signature
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Thu, Jul 14, 2022 at 02:31:22PM +0200, julien.pu...@gmail.com wrote: > Hi, > > Le jeudi 14 juillet 2022 à 14:16 +0200, Marc Haber a écrit : > > On Thu, 14 Jul 2022 12:54:52 +0100, Steve McIntyre > > wrote: > > > And I see you uploaded ~immediately - why even bother with an ITP? > > > > Is it proper procedure to upload without an ITP? > > > > No ; I have to admit a large percentage of the new packages I upload > get their ITP minutes before the package is ready. > > Basically: I wait for the bug number before pushing to salsa & NEW. I do exactly this and have never had a problem. I maintain a number of packages (like Julien does too) and push a bunch of stuff to new from time to time. Filing an ITP, waiting for it, having a discussion and then uploading is just beyond the time I have these days -- sorry. And needless to say there is always a possibility of rejecting a package if deemed in-appropriate. -- Best, Nilesh signature.asc Description: PGP signature
Re: Bug#1013357: ITP: rust-nom-bibtex -- BibTeX parser using nom
On 6/22/22 10:40 PM, Jonas Smedegaard wrote: * Package name: rust-nom-bibtex Version : 0.3.0 Upstream Author : Charles Vandevoorde * URL : https://github.com/charlesvdv/nom-bibtex * License : Expat Programming Lang: Rust Description : BibTeX parser using nom nom-bibtex is a feature complete *BibTeX* parser using nom. It can parse the four differents types of entries listed in the BibTeX format description: * Preambles which allows to call *LaTeX* command inside your *BibTeX*. * Strings which defines abbreviations in a key-value format. * Comments. * Bibliography entries. This package is needed by zola (bug#976052). It will be maintained in the Debian section of Salsa, here: <https://salsa.debian.org/debian/rust-nom-bibtex>. Thanks for your work, Jonas. I was just curious to know if there is a reason that you are not maintaining it in the rust-team itself (given that there is a team)? BTW, I am not (actively) a part of the team, myself - I might package $something rust in near future and hence the question. -- Best, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Bug#1012673: ITP: golang-github-pion-webrtc.v3 -- Pure Go implementation of the WebRTC API
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-webrtc.v3 Version : 3.1.41-1 Upstream Author : Pion * URL : https://github.com/pion/webrtc * License : Expat Programming Lang: Go Description : Pure Go implementation of the WebRTC API (library) This package implements WebRTC API in Golang. WebRTC is a free and open- source project providing web browsers and mobile applications with real- time communication via application programming interfaces.
Bug#1012672: ITP: golang-github-pion-srtp.v2 -- A Go implementation of SRTP
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-srtp.v2 Version : 2.0.9-1 Upstream Author : Pion * URL : https://github.com/pion/srtp * License : Expat Programming Lang: Go Description : Go implementation of SRTP (library) Library implementing Secure Real-time Transport Protocol (SRTP) in Golang. SRTP is used by WebRTC for encrypting media streams being a lighter weight option than DTLS.
Bug#1012669: ITP: golang-github-pion-mdns -- Pure Go implementation of Multicast DNS
Package: wnpp Severity: wishlist Owner: Nilesh Patra * Package name: golang-github-pion-mdns Version : 0.0.5-1 Upstream Author : Pion * URL : https://github.com/pion/mdns * License : Expat Programming Lang: Go Description : Pure Go implementation of Multicast DNS Golang mDNS implementation. The original user is Pion WebRTC, but is extendable for other uses.
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
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#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#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#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#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#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#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#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#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#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.
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
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: 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: 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
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
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#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)
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#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
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
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
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=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
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
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
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: 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: 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
> 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
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
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
