Bug#1065194: RFS: python-raccoon/3.1.1-1 -- Python DataFrame with fast insert and appends (Python 3)
Hi, On Fri, Mar 01, 2024 at 11:54:26PM +0530, Akash Doppalapudi wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-raccoon": * Package name : python-raccoon Version : 3.1.1-1 Upstream contact : Ryan Sheftel * URL : https://github.com/rsheftel/raccoon * License : MIT * Vcs : https://salsa.debian.org/debian/python-raccoon Section : python The source builds the following binary packages: python3-raccoon - Python DataFrame with fast insert and appends (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-raccoon/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-raccoon/python-raccoon_3.1.1-1.dsc Changes since the last upload: python-raccoon (3.1.1-1) unstable; urgency=medium . * New upstream version 3.1.1 * New Maintainer I think you need close this issue also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052685 BR, Bo signature.asc Description: PGP signature
Re: How to handle marked for removal
Hello Loren, you can wait till the package cimg-dev is fixed. you can contact the maintainer if (s)he needs help to fix it. Kind regards Mechtilde Am 03.03.24 um 07:29 schrieb Loren M. Lang: Hello Mentors, I was notified that a package of mine is now marked for removal in testing due to the time_t change. This seems to be with packages that are indirect build dependencies. I don't see anything in my own package that uses time_t or date/time operations. I just want to know what my responsibility is for maintaining my package through this. As it does not seem to be my direct build dependency, I'm not sure if I even need to consider rebuilding anything. My specific package is tiv which has a build-dep on cimg-dev and it seems somewhere down the line it has this: 1062125: gimp: NMU diff for 64-bit time_t transition https://bugs.debian.org/1062125 1063178: nifticlib: NMU diff for 64-bit time_t transition https://bugs.debian.org/1063178 Do I need to respond or just wait it out? Thanks -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1065078: Question about the debian group on Salsa
Loren, Yes, I would say that is generally correct. If you have a package that is team maintained, it is best under the team namespace. If it is not team maintained, it is generally best under the debian namespace (which is the team of all Debian Developers). It makes it easier for others to pick up if something happens to you. However, there may be specific cases where you do want to keep it in your own namespace. I maintain one package where I am also the upstream developer. I keep the Debian packaging in my own namespace because I want to have a very high threshold for other people making changes to it. At this stage, if something were to happen to me, both the Debian package and the upstream project would need to be adopted by someone else, which would probably necessitate a renaming of the project. Down the road, I would like to get more people involved in both the upstream development and the Debian packaging. When that happens I will probably move the Salsa project to a team namespace. There is certainly nothing wrong with keeping your project under your own namespace, but if you would like to move it to the debian namespace, grant me full access to it (my Salsa username is soren) and I can then move it to the debian namespace and grant you full access to the project there. Soren On Saturday, March 2, 2024 11:34:14 PM MST Loren M. Lang wrote: > On Sat, Mar 02, 2024 at 01:11:46AM +0100, Salvo Tomaselli wrote: > > In data venerdì 1 marzo 2024 05:12:51 CET, Soren Stoutner ha scritto: > > > Generally you should create the repository under the debian namespace > > > > You need to ask a DD to do that. Non DD don't have permissions for this. > > So is having all packages (at least those not maintained by a team) > under the debian/ namespace considered a best practice for all but the > most sensitive of packages? Should I actually have my own package > transfered to this namespace? > > I just have a small, CLI package that I maintain alone and, since I > don't have DD permissions, just assumed that I should put it under my > own namespace. Is it recommended to just keep it under the neutral > debian namespace just in case I am no longer able to keep it maintained > in the future? > > My current package is https://salsa.debian.org/penguin359/tiv > > -Loren -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Medical Device Interfacing
Ok, thanks for the update. On Sun, Mar 3, 2024 at 12:23 PM Soren Stoutner wrote: > You probably just need to wait a bit. > > "Your account will be locked until a gitlab administrator enables it. As > of July 2021 you will now receive an email confirming your account > validation, please be patient. (Ping the above Support after 4 days > patience)” > > https://wiki.debian.org/Salsa/Doc#Support > > On Saturday, March 2, 2024 11:37:12 PM MST Nishi Shailesh wrote: > > > Thank you for the information. > > > *"create a Git repository on Salsa to host the Debian package > information"* > > > This requires login to https://salsa.debian.org/ > > > I am not receiving email for confirming my email. > > > > > > On Sun, Mar 3, 2024 at 10:29 AM Soren Stoutner wrote: > > > > What you probably want to do is create an upstream project on your > > > > internet > > > > repository host of choice. Then, once it is published, create a Git > > > > repository on Salsa to host the Debian package information. > > > > > > > > On Saturday, March 2, 2024 9:53:20 PM MST Nishi Shailesh wrote: > > > > > Hello mentors, > > > > > I forgot to add that, I have basic skill in preparing .deb file > > > > > > > > > > On Sun, Mar 3, 2024 at 10:21 AM Nishi Shailesh < > > > > > > > > biochemistryg...@gmail.com> > > > > > > > > > wrote: > > > > > > Hellos mentors, > > > > > > I am from medical field and also know python/php > > > > > > I have basic scripts for ASTM and HL7 unidirectional and > bi-directional > > > > > > communication between medical instruments and linux box. > > > > > > They are generic and tested in many equipments. > > > > > > As no such packages are available in linux, I would like to > contribute. > > > > > > Can any mentor guide me how I can contribute? > > > > > > Dr Shaileshkumar Patel > > > > > > MD, Biochemistry > > > > > > https://github.com/nishishailesh/mdi > > > > > > > > > > > > > > > > > > -- > > > > > > શૈલેશ પટેલ > > > > > > > > -- > > > > Soren Stoutner > > > > so...@debian.org > > > -- > > Soren Stoutner > > so...@debian.org > -- શૈલેશ પટેલ
Re: Medical Device Interfacing
You probably just need to wait a bit. "Your account will be locked until a gitlab administrator enables it. As of July 2021 you will now receive an email confirming your account validation, please be patient. (Ping the above Support after 4 days patience)” https://wiki.debian.org/Salsa/Doc#Support[1] On Saturday, March 2, 2024 11:37:12 PM MST Nishi Shailesh wrote: > Thank you for the information. > *"create a Git repository on Salsa to host the Debian package information"* > This requires login to https://salsa.debian.org/ > I am not receiving email for confirming my email. > > On Sun, Mar 3, 2024 at 10:29 AM Soren Stoutner wrote: > > What you probably want to do is create an upstream project on your > > internet > > repository host of choice. Then, once it is published, create a Git > > repository on Salsa to host the Debian package information. > > > > On Saturday, March 2, 2024 9:53:20 PM MST Nishi Shailesh wrote: > > > Hello mentors, > > > I forgot to add that, I have basic skill in preparing .deb file > > > > > > On Sun, Mar 3, 2024 at 10:21 AM Nishi Shailesh < > > > > biochemistryg...@gmail.com> > > > > > wrote: > > > > Hellos mentors, > > > > I am from medical field and also know python/php > > > > I have basic scripts for ASTM and HL7 unidirectional and bi-directional > > > > communication between medical instruments and linux box. > > > > They are generic and tested in many equipments. > > > > As no such packages are available in linux, I would like to contribute. > > > > Can any mentor guide me how I can contribute? > > > > Dr Shaileshkumar Patel > > > > MD, Biochemistry > > > > https://github.com/nishishailesh/mdi > > > > > > > > > > > > -- > > > > શૈલેશ પટેલ > > > > -- > > Soren Stoutner > > so...@debian.org -- Soren Stoutner so...@debian.org [1] https://wiki.debian.org/Salsa/Doc#Support signature.asc Description: This is a digitally signed message part.
Re: Medical Device Interfacing
Thank you for the information. *"create a Git repository on Salsa to host the Debian package information"* This requires login to https://salsa.debian.org/ I am not receiving email for confirming my email. On Sun, Mar 3, 2024 at 10:29 AM Soren Stoutner wrote: > What you probably want to do is create an upstream project on your > internet > repository host of choice. Then, once it is published, create a Git > repository on Salsa to host the Debian package information. > > On Saturday, March 2, 2024 9:53:20 PM MST Nishi Shailesh wrote: > > Hello mentors, > > I forgot to add that, I have basic skill in preparing .deb file > > > > On Sun, Mar 3, 2024 at 10:21 AM Nishi Shailesh < > biochemistryg...@gmail.com> > > > > wrote: > > > Hellos mentors, > > > I am from medical field and also know python/php > > > I have basic scripts for ASTM and HL7 unidirectional and bi-directional > > > communication between medical instruments and linux box. > > > They are generic and tested in many equipments. > > > As no such packages are available in linux, I would like to contribute. > > > Can any mentor guide me how I can contribute? > > > Dr Shaileshkumar Patel > > > MD, Biochemistry > > > https://github.com/nishishailesh/mdi > > > > > > > > > -- > > > શૈલેશ પટેલ > > > -- > Soren Stoutner > so...@debian.org -- શૈલેશ પટેલ
How to handle marked for removal
Hello Mentors, I was notified that a package of mine is now marked for removal in testing due to the time_t change. This seems to be with packages that are indirect build dependencies. I don't see anything in my own package that uses time_t or date/time operations. I just want to know what my responsibility is for maintaining my package through this. As it does not seem to be my direct build dependency, I'm not sure if I even need to consider rebuilding anything. My specific package is tiv which has a build-dep on cimg-dev and it seems somewhere down the line it has this: 1062125: gimp: NMU diff for 64-bit time_t transition https://bugs.debian.org/1062125 1063178: nifticlib: NMU diff for 64-bit time_t transition https://bugs.debian.org/1063178 Do I need to respond or just wait it out? Thanks -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Re: Medical Device Interfacing
What you probably want to do is create an upstream project on your internet repository host of choice. Then, once it is published, create a Git repository on Salsa to host the Debian package information. On Saturday, March 2, 2024 9:53:20 PM MST Nishi Shailesh wrote: > Hello mentors, > I forgot to add that, I have basic skill in preparing .deb file > > On Sun, Mar 3, 2024 at 10:21 AM Nishi Shailesh > > wrote: > > Hellos mentors, > > I am from medical field and also know python/php > > I have basic scripts for ASTM and HL7 unidirectional and bi-directional > > communication between medical instruments and linux box. > > They are generic and tested in many equipments. > > As no such packages are available in linux, I would like to contribute. > > Can any mentor guide me how I can contribute? > > Dr Shaileshkumar Patel > > MD, Biochemistry > > https://github.com/nishishailesh/mdi > > > > > > -- > > શૈલેશ પટેલ -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Medical Device Interfacing
Hello mentors, I forgot to add that, I have basic skill in preparing .deb file On Sun, Mar 3, 2024 at 10:21 AM Nishi Shailesh wrote: > Hellos mentors, > I am from medical field and also know python/php > I have basic scripts for ASTM and HL7 unidirectional and bi-directional > communication between medical instruments and linux box. > They are generic and tested in many equipments. > As no such packages are available in linux, I would like to contribute. > Can any mentor guide me how I can contribute? > Dr Shaileshkumar Patel > MD, Biochemistry > https://github.com/nishishailesh/mdi > > > -- > શૈલેશ પટેલ > -- શૈલેશ પટેલ
Medical Device Interfacing
Hellos mentors, I am from medical field and also know python/php I have basic scripts for ASTM and HL7 unidirectional and bi-directional communication between medical instruments and linux box. They are generic and tested in many equipments. As no such packages are available in linux, I would like to contribute. Can any mentor guide me how I can contribute? Dr Shaileshkumar Patel MD, Biochemistry https://github.com/nishishailesh/mdi -- શૈલેશ પટેલ
Bug#1065302: RFS: elpa-rust-mode/1.0.5+git20240301.6d86af4-1 -- Major Emacs mode for editing Rust source code
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "elpa-rust-mode": * Package name : elpa-rust-mode Version : 1.0.5+git20240301.6d86af4-1 Upstream contact : The Rust Project Developers * URL : https://github.com/rust-lang/rust-mode * License : Apache-2.0 or MIT * Vcs : https://salsa.debian.org/emacsen-team/rust-mode Section : editors The source builds the following binary packages: elpa-rust-mode - Major Emacs mode for editing Rust source code To access further information about this package, please visit the following URL: https://mentors.debian.net/package/elpa-rust-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/elpa-rust-mode/elpa-rust-mode_1.0.5+git20240301.6d86af4-1.dsc Changes since the last upload: elpa-rust-mode (1.0.5+git20240301.6d86af4-1) unstable; urgency=medium . [ Nicholas D Steeves ] * Drop emacs24 from Enhances (package does not exist in bullseye). * Matthew Kraai has moved to Emeritus status; remove him from Uploaders on his request. . [ Xiyue Deng ] * Sync to latest upstream head (6d86af4) * Drop obsolete patches * Skip upstream Makefile which relies on eask * Drop obsolete override_dh_auto_test and refine override_dh_auto_clean * Include all source files in d/elpa * Migrate from compat to debhelper-compat version 13 * Drop unnecessary parameter "--parallel" with debhelper-compat 13 * Drop obsolete version requirements from dh-elpa and emacs * Update to Standards-Version 4.6.2 (no change needed) * Extend package description using upstream introduction * Drop Built-Using from "Architecture: all" package * Add myself as uploader * Modernize d/watch with special substitute strings * Rename license from Expat to MIT following upstream * Use https in Format URL * Update copyright years * Add copyright information for debian/* * Add Upstream-Contact * Add d/upstream/metadata Regards, -- Xiyue Deng
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
On Tue, Feb 27, 2024 at 06:50:56AM +0100, Joachim Zobel wrote: > Hi. > > Thanks for taking the time to review my package. > > Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > > d/postinst / postrm > > - When you create a user, it should start with "_" - see policy > > 9.2.1 > This has been implemented and is on its way, see > https://github.com/volkszaehler/vzlogger/pull/628 > > It was a bit complicated because I need to rename an existing user. > There are installations of the existing native package. I am therefore > unsure if it is good to do this. Going by the letter which is > "When maintainers choose a new hardcoded or dynamically generated > username" the username has already been choosen when the > debian/vzlogger.init script was created. > > Since it is a now or never situation and since the number of existing > installations is still low I tend to rename the user. Any opinions are > appreciated. If you think the existing user base is large enough, you can also migrate the username, if you detect in your postinst script that you are upgrading from an version with the old username. (This code could then be dropped in trixie+1, assuming the package will be in trixie, of course) > Sincerely, > Joachim >
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Hi Joachim, On Sat, Feb 24, 2024 at 06:37:02PM +0100, Joachim Zobel wrote: > Hi. > > I'll reply to the DEP-14 issue while working on the others. > > Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost: > > > https://github.com/volkszaehler/vzlogger.git > > > > > > on branch debian-0.8.3-1. > > > > (There is no such branch on that repo, but a "debian" one.) > > Sorry, forgot to merge that. > > > Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for > > recommendation how to layout the repository used for packaging, I'd > > even recommend to use an extra repository for the packaging. > > I know about DEP-14 and actually tried it. I found it however very > inconvenient to use and I think this is because it is inappropriate for > the current situation. Sorry, I don't get what you mean. Why is it inappropiate? Putting DEP14 (branch names[1]) aside, Debian packagaing is supposed to be "linear", you work on a package, upload it, and the next iteration you base your work on the already uploaded version. It makes no sense to have a branch for every Debian package revision, because once it has been uploaded it will become immuteable, you cannot reupload the same revesion, the upload will be rejected. We *tag* Debian package releases to mark them, and when the next one is ready, it will be based on the old revision, so it is more natural to continue on that branch. Also, you are supposed to note the branch in VCS-Git where packaging is happening, and this is _a_ branch (that's singular!), see the Debian Policy for extra reasoning. [1] which are only getting important if you need to manage different Debian release suites or backports on top. the scheme /, e.g debian/unstable is meant to aid here. note: you cannot have branches "debian" _and_ "debian/$suite", because git won't allow that. If you use "debian" as branch, this will make it harder to deploy DEP14 later. > The package is maintained in the upstream repository as a native > package (by me). This is necessary because Debian packages are built as > part of the upstream releases. So all packaging changes happen upstream > first. If you are in control of upstream packaging, well, frankly, than you are in control to do things propoerly upstream. The first thing is: stop building native packages. Native packages are the wrong approach 99% of the time. [2] This will also save you a lot of time, you won't need to maintain two flavours. (As Debian packages need to follow Debian rules and not upstream rules, a native package will not be acceptable for Debian.) The upstream guide discourages to have a debian/ directory in the upstream main branch [3], but if you do, and base your packaging on it. Having a debian directory in "main" and another branch, especially if they are divereged, will only confuse people. (and they might to need to work on your package, e.g if there is a need for an NMU.) So pick one. [2] https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F You should only use a native Debian package when it is clear that the package would not be useful outside the context of a Debian system, and would never be distributed except packaged for Debian or its derivatives. Even if the software is currently only available in Debian, if someone could reasonably use the software on another distribution or on another operating system, then the package should be non-native [3] https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source, third paragraph. > The changes that are later needed to turn an upstream native > release into a Debian release are few and won't change much over time. > So a patch makes sense IMHO. As said, native is wrong anyways, but the packaging directory should be orthogonal to the upstream version, as the upstream version needs also to work on non-Debian systems, don't they? > This situation can change when vzlogger reaches stable (and as a result > reaches Raspbian). At that point maintaining a package in the upstream > repo is no longer necessary. This sounds wrong. Either you package in an dedicated repository, or you don't. That is orthogonal to whether the package is in Debian or not. > For now I would prefer to use the suggested release workflow (which I > am already using for libsml, where the situation is the same). tracker.d.o is unhappy: "The VCS repository is not up to date, push the missing commits." Your process breaks tooling in Debian. It is broken. > I am > aware that the DEP-14 layout works well if upstream is not doing > package maintenance and I am not generally against it. It is not significant for DEP-14 whether upstream is doing package maintaince or not. In your instance, you are in control of the upstream repository, so you *can* change things. In situations where this is not possible, we'd ignore the debian/ directory from upstream completly. My other current > ITP #1062335
