Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates
reopen 1068605 owner 1068605 ! thanks Hi, Sorry I didn't ask this sooner, but would you prefer if I call you Deng, or Xiyue, or something else? Conventions and understanding vary a lot from place to place, after all. Xiyue Deng writes: > Thanks for pointing out #1019031! Totally missed it. I'll opt for > option 1 obviously. Updated team repo and mentors accordingly. You're welcome, and thank you. On a related note, have you read the definitions for source and binary packages? #1019031 was filed against src:web-mode, so was hidden from the bin:elpa-web-mode view. On the BTS the src:package view will display bugs that affect each binary package as well as the src:package. §4 of Policy has the definition, and here is another good resource: https://wiki.debian.org/Packaging/SourcePackage > Also, accordingly to this comment from Tobias[1] it looks like there are > opinions that prefer to reuse existing RFS bugs instead of filing new > ones. Do you think it's OK to reopen this one? There are also people who maintain the opposite position, but in the spirit of harmony I've reopened this bug. [edit: Be careful about only waiting a day and then going ahead and doing something without having received a reply, because when you "ask" for something, but then don't actually wait for a reply, it can make you look disingenuous and/or impatient and/or pushy.] Onto the review: * New upstream release Push the upstream tag to salsa, and find a way to mitigate this issue in the future. * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse * Update standards version to 4.6.2; no changes needed Update this, since a new Policy version was recently released. Did you already work through the upgrade checklist stepwise, starting from 4.3.0? "debian-devel-announce" is a low traffic list that will keep you appraised of stuff like this. * Use https link of homepage in d/control * Modernize d/watch using special substitute strings to be more robust I'm happy to see this clear, concise, and useful phrasing. If you have any pending not-yet-uploaded work that doesn't use this, please update it. If you're interested in a nitpick, the key term is "substitution strings" and not "[special] substitute strings" (see the manpages for uscan and deb-substvars as well as codesearch.debian.net). * Fix issues in d/copyright - Clarify license to be GPL-3+ to be consistent with upstream This is unclear. Which licence was it before, and whose license are you talking about? Web-mode is a non-native package and debian/* is separate from the upstream source. Also, what does it mean to clarify a license? - Update copyright year info for upstream - Add copyright info for debian/* You added a license grant for debian/* where there was previously none with no explanation, notes, nor justification. Are you sure you have the right to do this? Contact debian-legal and ask them for a patch review of your intended changes. - Add Upstream-Contact Thanks for this and for all the other work I didn't comment on. Here are some things you can work on while waiting for a reply from debian-legal: * lintian-explain-tags prefer-uscan-symlink: if you're changing the watch file then this should be addressed * There's also a version qualifier in d/control that can be dropped. * Finally, have you installed and tested your updated package? * Extra/bonus: Which tags from the lintian output are candidates for an override, and why? -N signature.asc Description: PGP signature
Bug#1067698: RFS: persist-el/0.6+dfsg-1 [Team] -- persist variables between Emacs Sessions
Control: owner -1 ! Xiyue Deng writes: >[ Xiyue Deng ] >* New upstream release. >* Re-export upstream signing key without extra signatures. $ uscan --download-current-version Newest version of persist-el on remote site is 0.6, specified download version is 0.6 gpgv: Signature made Sat 13 Jan 2024 05:05:03 EST gpgv:using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40 gpgv: Good signature from "GNU ELPA Signing Agent (2019) " gpgv: Signature made Sat 13 Jan 2024 05:05:03 EST gpgv:using EDDSA key 0327BE68D64D9A1A66859F15645357D2883A0966 gpgv: Can't check signature: No public key uscan die: OpenPGP signature did not verify. at /usr/share/perl5/Devscripts/Uscan/Output.pm line 77.
Re: Looking for sponsor with update for Debian package
Replying from my phone (part 2) On Sun, 21 Jan 2024, 14:46 Loren M. Lang, wrote: > On Sun, Jan 21, 2024 at 03:12:41PM +0100, Norwid Behrnd wrote: > > @Loren As an sponsored maintainer and hence subscriber to this mailing > list, I > > think a subject line with a specific ticket number, package name and -- > in the > > particular case -- the acronym RFS would ease to follow up the progress > of > > your work. Ideally it were the template reaching level 4 / Find a > sponsor[1] > > offers. > > Thank you for your feedback. While I am a long-time Debian user and > built packages for personal use, this is my first attempt to contribute > back so am still learning the process. I will work on filing a proper > RFS bug report with the template as documented on the Mentors Wiki. > P.S. Maybe you'll appreciate hearing about "reportbug sponsorship-requests"? >
Re: Looking for sponsor with update for Debian package
Replying from my phone. On Sun, 21 Jan 2024, 14:46 Loren M. Lang, wrote: > On Sun, Jan 21, 2024 at 03:12:41PM +0100, Norwid Behrnd wrote: > > @Loren As an sponsored maintainer and hence subscriber to this mailing > list, I > > think a subject line with a specific ticket number, package name and -- > in the > > particular case -- the acronym RFS would ease to follow up the progress > of > > your work. Ideally it were the template reaching level 4 / Find a > sponsor[1] > > offers. > Thank you for your feedback. While I am a long-time Debian user and > built packages for personal use, this is my first attempt to contribute > back so am still learning the process. I will work on filing a proper > RFS bug report with the template as documented on the Mentors Wiki. > > > > > Inferring from your message filed by Sun, 21 Jan 2024 02:29:20 -0800 > your work > > relates to rpm[2] with its RFA[3] (and hence, an existing ticket) I > fetched a > > fork by > > > > ``` > > git clone http://www.north-winds.org/git/rpm.git > > ``` > > > > File `/debian/changelog` for your new version 4.18.2+dfsg-1 does not > > explicitly mention to close (including the corresponding ticket numbers, > and > > a `closes: #NNN`) one of the bugs currently (15:10 UTC +1) listed on > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=rpm. > If > > your work addressed them, may you amend accordingly the changelog file? > > Yes, I will upload the changelog. So the standard procedure it to > normally file a bug report first so the changelog can be updated to > reflect it and then the source package can be generated for upload? > I'm not sure what you mean by the above, but the Request for Sponsorship (RFS) bug will not be closed in the changelog, because you create it after you've finalised and uploaded your updated package. I think Norwid Behrnd is expressing that your upload fixes existing bug[s], so you should close the applicable one[s] from the changelog. This will require a triage of the existing bugs. > Are you member of the pkg-rpm-team? If not, and if the package now were > > maintained by you, a successful upload to Debian likely might require an > > update of debian/control, in lines of `Vcs-Browser:` and `Vcs-Git:`. > > I have sent a request to join the team from the email in the Maintainers > field. I also looked at the Team page, but they reference a non-existent > mailing list on Alioth. > > https://wiki.debian.org/Teams/pkg-rpm It may also be worthwhile to CC people listed in Uploaders if you don't receive a reply in a reasonable amount of time. I don't plan to move the Git hosting from Salsa. My branches are based > on the latest tip from the repo on Salsa and my goal is that that are > just merged into that repo. > I don't think there's anything wrong with this in principle, and it does celebrate how git is decentralised That said, it imposes additional demands on your sponsor (and/or tram member[s]). Long-term, how will this work in practice? Rather than depend on someone to manually pull from non-Debian infrastructure, why not just register for a Salsa account of your own, and then push directly? Best, Nicholas
Bug#1061157: RFS: mini-httpd/1.30-7 -- Small HTTP server
Control: owner -1 ! Hi Alexandru, Happy New Year! I'll sponsor this one. In the future please use "reportbug sponsorship-requests" and enter my email at the "Enter any additional addresses this report should be sent to; press ENTER after each address. Press ENTER on a blank line to continue" step, because the method you use doesn't let the additional recipient[s] reply to the bug. If you want to use another method, please add the following pseudoheader: X-Debbugs-Cc: additional@recipient addresses@list ie@me Gentle reminder not to push tags until the package has been accepted into the archive. It would also be nice to see you use end punctuation again. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Hi, Paul Wise writes: > On Mon, 2023-12-04 at 02:28 -0800, Xiyue Deng wrote: > >> I think dh_auto_clean is the right place, because the build failure is >> because that the clean target requires the existence of >> scala-mode-pkg.el, which is generated by Cask. As we don't have Cask, >> we need to provide this before dh_auto_clean runs. The generation of this metadata, and file, is one of dh_elpa's primary functions. See the section of the dh_elpa man page that discusses DEB_VERSION_UPSTREAM. Read Policy §4.9 closely; Cask cannot be used. Grep the buildlog for "dh_" and if you'd like to see a more comprehensive list of applicable entry points in the sequence, try $ dh binary-indep --no-act It's also worth reading the dh man page. > I think it is against ftp-master rules to have generated files > present that can't be built using only tools from Debian main. Yes, and thank you for bringing this up. > So I think you would need to package Cask first? Cask is not relevant nor needed, and dh_elpa is used. Whenever this topic comes up on IRC, new contributors are briefed and are additionally referred to the RFP for Cask, where the unsuitability of this type of tool for Debian packaging is discussed (#837922). It's also worth noting that dh_elpa was written by people by current and/or past members of the Debian TC. Xiyue Deng writes: > Cask and similar tools like Eask and Eldev are tools that automatically > install dependencies of an Emacs addon package, which doesn't use and > circumvents the system package management. I think the Emacsen team > chooses not to package those tools and prefers using dh-elpa for the > job, and may override build target to avoid using those tools. If you're familiar with the concept of "hats", then when you're working on debian/* you need to put on your Debian packaging hat, and when you're working on !(debian/*) you use your upstream development/debugging/packaging hat. These tools are not relevant to Debian packaging and referring to them is not useful for describing packaging problems or decisions; there will always be a more direct and useful description. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Xiyue Deng writes: > Nicholas D Steeves writes: >> Xiyue Deng writes: >>> Nicholas D Steeves writes: >>> > > There are about 3 years of newer commits since 1.1.0, and one of the > major changes is that it adds support of scala 3 syntax which is not yet > in a tagged release and would be good to have. Ok, you've convinced me :) Convey this information in your changelog (that's what it's for), because the human maintainer (and any interested users) of this package deserves to know why you made this change. > Also seeing the last commit is from the end of last year, I sense that > upstream may becoming a bit dormant for the time being, which is why I > prefer to package the latest snapshot instead of waiting for a stable > release. This can also mean that we run the risk of becoming defacto upstream if they quit at this point, but that said, I agree it's a good cut point as well as the right thing to do. >> Also, do you use this package? >> > > Not on a regular basis, but I do use it a bit once in a while as I try > to learn a bit of new programming languages every few months. Thanks for confirming! [snip] > And then I just realized: why not just host the scala-mode-pkg.el file > and substitute the version so that we don't need to update it manually > on each update? This is now implemented at [1]. Substvars make sense ;) Also, neat use of a makefile target called from within the dh sequence. Are you sure dh_auto_clean is the right place for this override? Skim its man page, as well as the one for dh_clean before replying. Also, whenever one overrides something in rules, one needs to document this in the changelog. Please use "cp -a" so timestamps between builds will be reproducible. What is the rationale for CURDIR? From what I can tell it isn't needed and should be dropped. >> Do you see what will happen when the package is updated to >> 1.1.1 or newer? Also, why did you choose to set the version to "0.23" >> rather than "1.1.0"? > > Well I didn't choose it (if I did I'd use 1.1.0 :) This is the version > specified in scala-mode.el[2]. I like your choice, and so what if upstream has that! Is it correct? >> Did you verify that elpa package version is consistent with the >> upstream version of the Debian package in bin:elpa-scala-mode that is >> consumed by users (the binary package)? >> > > I tried install it from stable.melpa.org and yeah it's being > installed as scala-mode-0.23 even if it's registered as version 1.1.0 > there[3]. So it's consistent in a sense :P Oh my! Sorry for the convoluted sentence I wrote, and I'm impressed that you were able to make sense of it. Yes, stable.melpa.org publishes a scala-mode version 1.1.0 elpa package, which contains a scala-mode.el file with "Package-Version: 0.23", and it also contains a scala-mode-pkg.el file that overrides the Package-Version to `1.1.0`. It is because of this pkg.el file that elpa/scala-mode-1.1.0 subdir. Meanwhile our elpa-scala-mode 1.1.0-* all declare 0.23, and install to a scala-mode-0.23 subdir. Thank you for your kind optimism, that's very gracious. Your work reveals that I missed this issue when reviewing 1.1.0-1, which I appreciate having pointed out. Lets fix it in the upload you've proposed. > Anyway, I have just made a pull request to update this upstream[4] so > hopefully the versioning will be sane. Thank you, and hopefully they'll agree. >>>>>* Modernize d/watch using special substitute strings. >>>> >>>> Ok, but why? >>>> >>> >>> I believe this provides a more robust way of detecting tags and should >>> be an encouraged practices. From my own experience, when I find a >>> d/watch file that doesn't work I may search for other packages to learn >>> from existing practices, and some may not work well as different >>> upstream may follow different conventions. The substitute strings use a >>> more robust and tested regexp that works most of the time, and promoting >>> its use may save people's time instead of working on an ad-hoc regexp. >> >> Sounds good! This is the kind of rationale that should be in the >> changelog, so please add it there :) From now on, read your changelog >> and patche desriptions, and imagine I'm asking you "ok, but why" for >> each point. Yes, rarely something is self-evident and/or an >> implementation detail, but most of the time you should say a few words >> explaining "why"--particularly when you want to find a sponsor quickly. >> My expectation is that you get better at this with each review, and that >> you will apply everything you learned to all pending sponsorship >>
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Xiyue Deng writes: > Nicholas D Steeves writes: > > >> Have you asked upstream to tag a release? >> > > Not before your review but done by now at [1] Thank you. You may have heard that Debian is a distribution that privileges the stable release model... When the human maintainer of a Debian package tracks stable releases, why is importing a snapshot justified? Also, do you use this package? >>>* Override clean rules in d/rules to fix building. (Closes: >>>#1052917) >> >> I believe you already know that >> >> override_dh_auto_clean: >>/bin/true >> >> is an incorrect approach. >> > > Indeed it was not ideal. Upstream depends on Cask to generated the > scala-mode-pkg.el file that is used in the clean target to get the name > of the generated tarball, and indeed using this lazy approach is > incorrect. I've now included the generated pkg file through a patch to > make this work in [2]. Consistency is essential between an explanation (in a comment or changelog) and the work that was done. Statically defining package metadata is fine, but in this case you can't claim that you're generating the pkg.el file. Either make the changelog and patch description consistent with what is actually happening, or change the implementation so that something is actually generated (there are multiple approaches here). I think I tend to use makefile substvars for this. Do you see what will happen when the package is updated to 1.1.1 or newer? Also, why did you choose to set the version to "0.23" rather than "1.1.0"? Did you verify that elpa package version is consistent with the upstream version of the Debian package in bin:elpa-scala-mode that is consumed by users (the binary package)? >>>* Modernize d/watch using special substitute strings. >> >> Ok, but why? >> > > I believe this provides a more robust way of detecting tags and should > be an encouraged practices. From my own experience, when I find a > d/watch file that doesn't work I may search for other packages to learn > from existing practices, and some may not work well as different > upstream may follow different conventions. The substitute strings use a > more robust and tested regexp that works most of the time, and promoting > its use may save people's time instead of working on an ad-hoc regexp. Sounds good! This is the kind of rationale that should be in the changelog, so please add it there :) From now on, read your changelog and patche desriptions, and imagine I'm asking you "ok, but why" for each point. Yes, rarely something is self-evident and/or an implementation detail, but most of the time you should say a few words explaining "why"--particularly when you want to find a sponsor quickly. My expectation is that you get better at this with each review, and that you will apply everything you learned to all pending sponsorship requests in addition to future ones. >>>* Add more metadata in d/upstream/metadata. >> >> https://github.com/hvesalai/emacs-scala-mode/commits/master >> >> is a git history log, not a changelog nor release notes. >> > > I thought the git history log may be considered an alternative form of a > Changelog. Looks like I was wrong except for projects that requires the > same format across changelog/git history/release notes. I've dropped > that line in [3]. Thank you. Re: "projects that requires the same format across changelog/git history/release notes": Changelogs, NEWS files, and release notes are three (or arguably two) distinct types of documentation that are also distinct from VCS history. This isn't a superficial formatting or style thing, because they have different audiences and purposes. I think that the kind of changelog that you're probably thinking of it when upstream takes git's shortlog history, puts it in a file, and edits it so that it makes sense. >>>* Update year and Upstream-Contact and add myself in d/copyright. >> >> Why did you add yourself? >> https://en.wikipedia.org/wiki/Threshold_of_originality >> >> I'm happy to support your claim, but you'll need to work for it in more >> than a "sweat of the brow"/mechanical sense. >> > > To be honest, the only reason I did this is to suppress the > "update-debian-copyright" lintian warning which is actually > experimental. I believe what I did was in the same nature as Sławomir > did in 2020 though admittedly not to the same extent, so I've reverted > this part in [4]. Cool. Yeah, lintian has these tags: error, warning, info, pedantic, experimental. Which ones do you think are suggestions, and which one[s] require a mandatory fix? Note that suggestions ar
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- transitional dummy package, scala-mode-el to elpa-scala-mode
Control: retitle -1 RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code Xiyue Deng writes: [snip] >[ Xiyue Deng ] >* Sync to latest upstream head (5d7cf21). Have you asked upstream to tag a release? >* Override clean rules in d/rules to fix building. (Closes: >#1052917) I believe you already know that override_dh_auto_clean: /bin/true is an incorrect approach. >* Modernize d/watch using special substitute strings. Ok, but why? >* Add more metadata in d/upstream/metadata. https://github.com/hvesalai/emacs-scala-mode/commits/master is a git history log, not a changelog nor release notes. >* Update year and Upstream-Contact and add myself in d/copyright. Why did you add yourself? https://en.wikipedia.org/wiki/Threshold_of_originality I'm happy to support your claim, but you'll need to work for it in more than a "sweat of the brow"/mechanical sense. >* Use xz compression in d/gbp.conf. Why is this useful when it has been the default since gbp 0.9.15? Best, Nicholas signature.asc Description: PGP signature
Bug#1054009: RFS: runit-services/0.7.0 -- UNIX init scheme with service supervision (services)
Hi Lorenzo, Lorenzo writes: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "runit-services": > > > * Package name : runit-services >Version : 0.7.0 [snip] >* Import the runscript from mini-httpd-run package: > - change the runscript to use the default config file > - d/control: runit-services Provides mini-httpd-run I'm unfamiliar with runit, but does anything need to be done in the mini-httpd package to support your work in this upload? By the way, thank you for writing such nice commit messages! https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/commit/566393e02ab8010405d14e38c0e02f4bea51afc8 I appreciate the thought and the openness that went into that work. One minor comment here: I'd recommend filing a bug against mini-httpd-run shortly after the upload of runit-services_0.7.0, because otherwise someone might potentially see a neglected package and then adopt it. This bug would make the plan from your commit message more visible and official. It will also give the Quality Assurance team the opportunity to support your plan, and this seems like it will be required for a Request of QA Team (RoQA) removal--unless you adopt mini-httpd-run and file a Request of Maintainer (RoM). Maybe one of these approaches is already part of your plan? Also, thank you for thinking about smoothing the transition for users by using Provides; although, I wonder how this will actually function, because mini-httpd-run's version 1.0+nmu1 >> runit-services' 0.7.0. You're right, Conflicts isn't required and it doesn't seem like Breaks would be appropriate either. Have you considered using versioned Provides? This would make it more clear, in dependency resolution, that mini-httpd-run is now an obsolete cruft package. https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides Alternatively if the transition requires user/sysadmin intervention, then why wouldn't a debian/NEWS file be a good thing? Kind regards, Nicholas signature.asc Description: PGP signature
Bug#1052127: RFS: ifupdown-ng/0.12.1-1 -- network interface configuration tool
Thank you for working on this! One note: where is it documented how ipupdown and ipupdown-ng interact? For example using the alternatives system, or a different config file location, or some sort of tagging mechanism in network/interfaces. I would appreciate it if this was in the changelog, at a minimum, and maybe other people would too? A brief "...by using $method" seems like it would be enough. Kind regards, Nicholas P.s. sorry for the html part, I'm on my phone
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, Alexandru Mihail writes: >> # Fix git config email and gpg identity, then [snip] >> > I fixed my git config and redid the tag as discussed above Thanks! >> Sorry I only noticed this when I manually inspected and compared the >> tag > Yeah, sorry too :) > I'll be going on vacation for two weeks so I will be available via mail > but won't be able to push unless we coordinate that tomorrow (roughly > 14 Hrs from now would be when I have to leave. If not I'll happily push > afterwards (14th September). > Tag is in the usual spot: > https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4 I just uploaded and sent you an invitation that grants Maintainer permissions for this repository. You will receive two emails from the FTP Masters (Debian archive). The first will be a "processing" email that says the release was uploaded successfully, and the second will be that mini-httpd was accepted into Debian unstable/sid. Please wait until you receive the "accepted" email before pushing your tag to g...@salsa.debian.org:debian/mini-httpd.git, and please push the master branch there at your earliest convenience. Congratulations, and enjoy your holidays! :) Cheers, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Alexandru, Thank you for the ping :) Alexandru Mihail writes: > I've commited and pushed the changes to the remote I was using for the > MR so far: > commit: > https://salsa.debian.org/alexandru_mihail/mini-httpd/-/commit/fc7c4f664dc1369b1bf5d46c8c9b7aa11de68407 > > > But I think I may have not commited where I was supposed to, granted > you've already closed the MR. You committed in the right place, and yes, as requested pushed to the remote in your personal namespace rather than to the collaborative space where mini-httpd is maintained. Yes, this is what I asked for, because I wanted to make sure everything was in good order before uploading to the archive and asking you to push to the actual project (thus making it permanent). I'm pulling from your remote directly rather than using the gitlab now. Tags on the actual project are immutable (or should be treated thus), and should only be pushed after an upload has been accepted, and this is why I wanted to check that everything was 100% good. Yes, I had already merged your MR, and MRs are automatically closed when they're merged. > I've already created a GPG signed tag accessible at: > https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4 Thanks! > The commit is not visible in the previous MR: > https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2? This is because the MR was merged already (and thus already closed and not open for updates). > Is there something I've glanced over here ? Did you realise that you're still committing using your protonmail.ch address (and presumably GPG identity)? Early in this process you switched to a gmail address, and I understood that that was the one that you would be using for for your Debian work. You'll need to update your git config to use the new gmail address and gpg identity (try #debian-mentors on irc.oftc.net if you can't make sense of the docs). Also, at this time please base your work on debian/mini-httpd.git rather than alexandru_mihail/mini-httpd.git. # Fix git config email and gpg identity, then git clone g...@salsa.debian.org:debian/mini-httpd.git cd mini-httpd git remote add alex g...@salsa.debian.org:alexandru_mihail/mini-httpd.git git fetch alex # just so you have another backup dch -r git commit debian/changelog -m "Release 1.30-4 to unstable." # do your tagging procedure git push --delete alex debian/1.30-4 git push -f alex master debian/1.30-4 Sorry I only noticed this when I manually inspected and compared the tag and release commit on the CLI...I feel like the web-thing hid this information from me, and that might be confirmation bias, but it seems like the same thing happened to you ;) Cheers, Nicholas P.S. FYI, to get Salsa's Gitlab instance to show green verified commits and tags you may also need to update your email address and gpg key there. I don't care about this so long as the actual git data is correct, but you (and/or others) might. signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, On Fri, 18 Aug 2023 02:07:46 +0300 Alexandru Mihail wrote: > >After that, let's talk about uploading. Think about whether you'd > >like > >to start gaining practice with dput (or dput-ng), or whether you'd > >like > >me to sponsor directly from git. > I'm pretty ambivalent to both..are you more comfortable with either one > ? I'd reckon practice with dput might help me in the case where I > become an uploading maintainer with full rights? They're about the same for me. Honestly I'd prefer to do a git upload at this time, and save the GPG key discussion for your next upload. We can use dput and mentors then, and I think we'll both agree that we've both worked hard enough for this first upload haha. > Cheers, we're getting close :D ! Indeed, I just merged, congratulations! At this point, please do a "dch -r" and ensure that the changelog entry is refinalised; this will update the date stamp. Hint: you may have to make do a noop edit like + to make this work properly. Commit the new changelog entry with a message like: Release 1.30-4 to unstable. And push that to the remote we're using for your MR. Then make an annotated and optionally GPG signed tag. I like to use "gbp tag" for this, but you can use whatever method you prefer. Please make sure the annotated tag is on the master branch and not a detached head. Let me know, and I'll review, and upload when everything looks good, as it no doubt will. Then I'll give you push permissions so you can push the release commit and tag to the actual project repository :) Cheers, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, Thanks again for your work! I submitted a second (I think we're at the second one) gitlab review here: https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2/diffs Summary: 1. One minor nitpick for multi-maint changelog format 2. Two lines that I can't make sense of within the context of the changelog. If you haven't already, please follow-up with these two bugs you've noted on the BTS, and please CC any contributors to those bugs. After that, let's talk about uploading. Think about whether you'd like to start gaining practise with dput (or dput-ng), or whether you'd like me to sponsor directly from git. If there's anything you'd like to squash either squash it and force push, or let me what what you'd like help squashing. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Alexandru Mihail writes: > I've redone some diffs, too. Also, my previous statement of 1.4.2 httpd > makes no sense, because, at a quick glance, I could observe the > introduction of virtual hosting in httpd 1.5*, which mini-httpd had > from the beginning. You're right to advise to look at 1.5* again. +1 and where can I see this new work? >>I started a review and noted what looks like one typo. > Where can I view the typo/review info ? I've looked in my original > merge details and I couldn't find it. Am I affected by temporary > blindness ? :) You should have received notifications for the review to the email address that you used to sign up for Salsa, and those emails included links to individual items. Alternatively, you can see the full review here: https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2/diffs If you strongly dislike using web interfaces and prefer patches via email, please let me know and we'll switch back to email. Regards, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru,
Alexandru Mihail writes:
> MR filed:
> https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2
Thanks. We can rebase and squash at the end, but for now please don't
force push.
>>Oh man, yeah, hello early days of the internet! All you need now is
>>some MIDI files and GIFs.
> Haha, your paragraph makes me want to reinstall DOOM/Starcraft for the
> nth time now :)
:)
>>3. Please note which version of NCSA httpd matches mini-httpd.
> After much diff'ing and vim'ing and staring at #ifdefs and trying to
> separate Jef's unversioned changes to htpasswd.c from actual NCSA
> updates:
> It's 99.999% 1.4.2. I noted that in debian/copyright.
Remember my Wed, 21 Jun 2023 email (as well as the one with the
diagram)? 1.4.2 still has the "no commercial endeavour" clause.
Here is what I found with
https://github.com/TooDumbForAName/ncsa-httpd/
$ git checkout 1.5.1
$ git diff 1.4.2 -- support/htpasswd.c
diff --git a/support/htpasswd.c b/support/htpasswd.c
index a9263ec..fb3415a 100644
--- a/support/htpasswd.c
+++ b/support/htpasswd.c
@@ -4,12 +4,18 @@
* Rob McCool
*/
+#include "config.h"
+#include "portability.h"
+
#include
#include
#include
#include
#include
#include
+#ifdef NEED_CRYPT_H
+#include
+#endif /* NEED_CRYPT_H */
#define LF 10
#define CR 13
@@ -79,10 +85,13 @@ to64(s, v, n)
}
}
+#ifdef HEAD_CRYPT
char *crypt(char *pw, char *salt); /* why aren't these prototyped in include */
+#endif /* HEAD_CRYPT */
+
#ifdef HEAD_GETPASS
char *getpass(char *prompt);
-#endif
+#endif /* HEAD_GETPASS */
void add_password(char *user, FILE *f) {
char *pw, *cpw, salt[3];
=
I compared a couple of versions and found the same diff.
Hint: Read the commit message for 1.5.1. Having read that, what is your
explanation for this diff, and what is your explanation for the changes
between any version of httpd in this range and mini-httpd? There's
another hint in the tarball name that you're comparing with, but that
Jef Poskanzer may not have used.
> I hope everything is in order with my MR.
Yes, your MR looks good. I started a review and noted what looks like
one typo.
> Have a great day and may the Debian swirl girate eternally !
Haha, you too!
Nicholas
signature.asc
Description: PGP signature
Bug#1041612: Enhancing upstream version git awareness in Debian packages [was Re: Bug#1041612: RFS: dh-git/1.0 [ITP]]
Hi Aidan, Aidan writes: > OK, thank you for your quick feedback. > If the implementation is fundamentally flawed then I think I'll just leave > it. I liked the user-facing UI of your proposed solution, I agree that it can be hard to learn how to work with git in Debian packaging, and it can be hard to understand Debian upstream version numbers. https://wiki.debian.org/Packaging/SourcePackage https://www.debian.org/doc/debian-policy/ch-source.html Please note that many Debian packages are not child branches of upstream git history. Instead they import tarballs of git snapshots, but that's not to say that the metadata is lost! Might you be interested in writing a decoder of Debian upstream versions that already embed upstream git metadata? Some examples of existing versions are: 1.1+14.gb364e08 tagged_release + commits_since_that_release . letter_for_VCS_used hash 0.0~git20220110.1ce338b a_release_has_not_been_tagged ~ VCS_used date . hash 1.2.1+git20190611.dadb6258 tagged_release + VCS_used date . hash https://manpages.debian.org/bookworm/dpkg-dev/deb-version.7.en.html Between that, and the remote defined at debian/upstream/metadata:Repository for many packages, you can also write a simple program that searches upstream history for a confirmed match. https://wiki.debian.org/UpstreamMetadata Upstreams possess their git history, so they can just run the decoder on the Debian version. ie: $ git-upstream-decoder 1.1+14.gb364e08-2 b364e08009fe0062cf0927d8a0582fad5a12b8e7 The second third of this project could be the encoder, which 1. Generates a Debian Policy-compliant upstream version with embedded committish info (see the three examples included in this email). Some examples of how to do this can be found in dh-make-golang. 2. For workflows where upstream git history is merged, the encoder could also make it easier to tag an upstream committish for Debian use, which is just an extension of solution at #1. 3. Generates a watch file that uses mode=git, and that encodes the upstream committish into the Debian upstream version. If I remember correctly uscan already has built-in support for a format compatible with git-describe. The final third letting people know about your tool, encouraging upstreams to use it, etc. One problem I noticed with dh-git is that it would require upstreams to have access to a Debian system. Not all do, and not all want to. Please let me know if you're interested, please consider CCing your reply (in-line style, not top-posting) to debian-de...@debian.org, and please keep me in CC. Regards, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Alexandru, Thank you for this latest update. Notes follow inline. Please count the TODO items, resolve 4/4, and file an MR. Alexandru Mihail writes: > Hello again, Nicholas ! > > --- > debian/copyright: > > Files: htpasswd.c htpasswd.1 > Copyright: 1993-1994 Rob McCool > Copyright: 1997 Jef Poskanzer > License: BSD-2-clause > Comment: htpasswd* are mostly NCSA licensed. > RobMcCool's copyright was established by examining original NCSA httpd 1. Please indent everything in the Comment: field by a single white space at the beginning of the line. > source code mirrored here: > https://github.com/TooDumbForAName/ncsa-httpd/ > This git repository is a convenient copy of the NCSA HTTPd 1.5.2 source > code which was verified to be accurate and complete by comparing with a > WaybackMachine capture of the original NCSA ftp archive found here: > https://web.archive.org/web/20130120184619/http://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd/current/httpd_1.5.2a-export_source.tar.Z Does that link really work? Are you sure it's not this one? https://web.archive.org/web/20160619204223/ftp://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd/current/httpd_1.5.2a-export_source.tar.Z I'm surprised the WayBack Machine dates that file June 19, 2016--very curious. > Portions of htpasswd* were edited by Jef Poskanzer, thus these files > remain under BSD-2-clause. The copyright info you've written in this version is immensely improved :) 2. Beyond this, you'll need to add a on every blank line that . so that the paragraphs in the "Comment" field of the "Files: htpasswd.c htpasswd.1" aren't split by an empty newline; they need to remain part of the same field. Nagivate to /usr/share/doc/*/copyright for many examples. > NCSA License: > This code is in the public domain. Specifically, we give to the public > domain all rights for future licensing of the source code, all resale > rights, and all publishing rights. . > We ask, but do not require, that the following message be included in > all derived works: . > Portions developed at the National Center for Supercomputing > Applications at the University of Illinois at Urbana-Champaign. . > THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED, > FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT > LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A > PARTICULAR PURPOSE. /\ It will look something like that (note the new indented periods) > debian-legal thread: > https://lists.debian.org/debian-legal/2023/07/msg1.html > > --- > Nicholas, I've finally found an "original" copy > of the httpd 1.5.2 src !! (Mentioned in the text above, it's the very > long WaybackMachine link). You have exceptional research skills. > After diff'ing the github copy and the > original .tar.Z (also, haven't seen that format in years), they seem to > match! Thus, I can confirm the github copy is accurate (previously, we > had no authoritative way to trust the github repo). Oh man, yeah, hello early days of the internet! All you need now is some MIDI files and GIFs. 3. Please note which version of NCSA httpd matches mini-httpd. >>I'm still not certain that this wiki contributor's position is >>legally >>sound everywhere in the world. For a counter example see: >> > https://opensource.stackexchange.com/questions/9871/why-is-there-no-public-domain-licensing-in-europe > > I've read the link and I share your concerns. I'm a bit lost > here..maybe another question to legal is the right choice ? While I'm not a lawyer, I believe that the approach we're going with is more legally defensible around the world than the aspirational public domain one. BSD-2-clause is also better understood than NCSA as far as I know. I'm relieved that work this didn't end up being a pulp novel situation where someone stumbles onto a dirty rotten secret at the heart of the origins of the internet while untangling the roots of a project like this one. As an aside, the last release that Robert McCool worked on was v1.3, and then he left in 1994 [1]. > Thanks for your time and may you have a great day, You're welcome, you too! Send me that merge request when you have time. Cheers, Nicholas [1] https://web.archive.org/web/20090416132804/http://hoohoo.ncsa.uiuc.edu/docs/acknowledgement.html signature.asc Description: PGP signature
Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager
Hi Paul, Paul Tagliamonte writes: > I /am/ one of the package maintainers :) > It's great to hear from you :) As one of the maintainers, will you have time and energy to review and merge Mateusz's work in the near future? Alternatively, would you be willing to add Mateusz as an Uploader and to let a mentor review and sponsor the proposed changes? I'm happy that you wrote back, because the best solution is collaboration! Mateusz, I'm supposing that you would be ok with this, because you've made a number of changes to fluxbox that are not appropriate for an NMU and that are the domain of a package's maintainers. Consequently, it makes it look like you'd like to help with the periodic maintenance of this package. Please let us know if this isn't what you want. Kind regards, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, For brevity I've omitted the parts that look good. Alexandru Mihail writes: > RobMcCool's copyright was traced from a git repository which > imported NCSA httpd (which was verified to be precise). > Multiple commits by RobMcCool on HEAD > show his contributions on the files specified here. Thank you you have the right idea about writing how you established copyright. That said, what you've written is impossible, because Rob McCool's work was 1993-1994, but git's first release was in 2005 ;) Also, please revise the text to explain what "verified to be precise" means. Grammatically, it sounds like you verified that the tags in the repository match the WayBack Machine's copies of release tarballs. Did you verify that Jef Poskanzer didn't make edits? If Jef Poskanzer made edits, they would most likely be under the mini-httpd project license, thus the effective license would be BSD-2-clause. A simple solution would be claim these files are BSD-2-clause, but to note that htpasswd* contain (or are mostly) NCSA licensed, and then shift the NCSA licence text into the Comment section of Files: htpasswd.* If you run lintian without shifting the license text you'll learn why I recommend it. \cut this/ > The files are under the NCSA license which qualifies as DFSG > compatible after inquiry (specifically, from the license text: > > "This code is in the public domain. Specifically, we give to the > public > domain all rights for future licensing of the source code, all resale > rights, and all publishing rights" > > From DSFGLicenses's Q on DebianWiki: > > "Software placed in the public domain has all the freedoms > required by the DFSG, and is free software." /cut this\ I'm still not certain that this wiki contributor's position is legally sound everywhere in the world. For a counter example see: https://opensource.stackexchange.com/questions/9871/why-is-there-no-public-domain-licensing-in-europe > git repository: https://github.com/TooDumbForAName/ncsa-httpd/ Note: If you provide a link that isn't on Debian infrastructure then you'll also need to summarise what it contains (for various reasons that I can explain if you're interested). It may be worth noting that someone else can use this to verify if the htpasswd.* copy in mini-httpd corresponds to the NCSA copy. > debian-legal thread: > https://lists.debian.org/debian-legal/2023/07/msg1.html > DFSGLicenses: https://wiki.debian.org/DFSGLicenses / \ Nice, but cut the last line of /this\ Thanks again for reading this page, as well as for sharing the story of how it inspired you to contribute to Debian! :) > Is my TLDR still a bit TL ? I was trying not to leave out anything > related to discussion on debian-legal or how we traced everything back > to RobMcCool. Thank you for your attention to detail, and yes, still too long. There has been far more discussion at this bug than at debian-legal... > Did i get the right field ? > > "6.6. Comment > > Formatted text, no synopsis: this field can provide additional > information. For example, it might quote an e-mail from upstream > justifying why the license is acceptable to the main archive, or an > explanation of how this version of the package has been forked from a > version known to be DFSG-free, even though the current upstream version > is not. " > > Sounded like a good fit. You're right, yes, that's the one :) > Replying to previous untackled mail: >>Wow, that's wonderful (and unexpected) news! I hope negotiations go > well. > > Thanks, me too :) I'll have to complete the new maintainer process here > (and actually have an upload by my mentor (you!) before I can discuss > matters more firmly with higher-ups. There's no rush; your patience and > attention to detail are very appreciated btw :) Thanks :) >>My key is on both the Debian keyring and public servers >> >> https://wiki.debian.org/DebianKeyring >> https://keys.openpgp.org/ >> and maybe also here >> http://pgp.mit.edu/ > > OK, thanks, I'll have to find a good place for my key too, then. I confirmed your signature on this email. Here are some key-related resources: https://wiki.debian.org/Keysigning https://wiki.debian.org/Keysigning/Coordination Best, Nicholas P.S. Please consider trimming the irrelevant quotation from correspondences on the BTS. It's a top-posting convention that takes up a lot of space and waste time (since we're an in-line posting community) https://bugs.debian.org/1036751 signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, Alexandru Mihail writes: > After a bit more research into how other projects treat NCSA bits I'd > propose something along the lines of: > > debian/copyright: > Files: htpasswd.c Yes, and htpasswd.1. > Copyright: 1993-1994 Rob McCool > Copyright: 1997 Jef Poskanzer ? Yes, and you would know the years better than I! Also, you'll need to say a few words about how you established copyright--a very short too long didn't read version of this thread. Find out how to do this at §5.1 of the following (read the short list of fields, and you'll see which one it is): https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#file-syntax > License: NCSA > > > License: NCSA > This code is in the public domain. Specifically, we give to the public > domain all rights for future licensing of the source code, all resale > rights, and all publishing rights. > > We ask, but do not require, that the following message be included in > all derived works: > > Portions developed at the National Center for Supercomputing > Applications at the University of Illinois at Urbana-Champaign. > > THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED, > FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT > LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A > PARTICULAR PURPOSE. Looks good to me. > Also, looking into your concerns about public domain in other countries > (specifically referring to NCSA's :"This code is in the public > domain"): > > Excerpt from https://wiki.debian.org/DFSGLicenses#Public_Domain : [snip] Thank you for looking into this, and for sharing this information. Regards, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hellow Alexandru, Alexandru Mihail writes: > Hello Nicholas, >>That's ok, you don't need to find the original version. Remember >>that >>it's a fork and child relationship, > > Yes, I'm terribly sorry, I'm familiar with the fork-child relationship > but I still found your analogy very helpful and concise, I might > present it to my interns (if that's O.K), thanks a lot for the > reminder. I was extremely tired when I wrote the last e-mail. No worries, and yes, go ahead and use that analogy :) If you feel like citing/attributing it to me, I'd appreciate it, but this isn't required. > In short, considering debian-legal's input, should I mention the NCSA > copyright notice in debian/copyright for Files: htpasswd.c, adding a > separate License: NCSA field to clarify the provenance of said source ? Yes, and if I remember correctly, you had figured this out by your next email (once again, sorry for my delays in replying). > I will fix the /patches issues we discussed in a later commit and > would also like to propose a mechanism for integrating PAM (Pluggable > Authentication Modules) into mini-httpd. I am currently in the > negotiation phase with my employer to grant an exception for this > particular patch in order for it to be upstreamed into debian/patches > (since, remember, we're the de-facto upstream here) and for my code to > become GPL licensed). PAM support (which would be toggled via a > Makefile parameter) could provide tangible improvements for the users > of mini-httpd and might even increase the server's popularity. The AUTH > mechanism in mini-httpd is arguably heavily antiquated and prone to > DDos attacks, MitM, scalability issues, etc. PAM would also enable AAA > solutions to interoperate with mini-httpd almost seamlessly (such as > Radius, TACACS+) which is becoming increasingly relevant in today's > SSO/IoT central trust-based use cases. Wow, that's wonderful (and unexpected) news! I hope negotiations go well. >>P.S. Please acknowledge: Have you read the DFSG yet, and do you >>understand why it's important? > Yes I have and yes I do, it is one of the main reasons I decided to > start contributing to DebianWiki (and now mini-httpd) to begin with. :) Thanks, much appreciated, and cool story! >>I confirm receipt of your mail, and I see an attached signature. >>Where >>can I download your public key? > > I'd like to ask you the same question, since I'd like to add your > address to my keyring. I've read a bit of documentation which suggests > using Ubuntu's HKP which seems a bit off-axis. I understand that the > Debian Public Key Server is for DDs and DMs only (I am not yet a DM). > I could perhaps use my DebianWiki personal page to link to my public > key, but I do not know if that solution would be accepted or would > sound absurd. I should find a better solution after some research. My key is on both the Debian keyring and public servers https://wiki.debian.org/DebianKeyring https://keys.openpgp.org/ and maybe also here http://pgp.mit.edu/ I haven't checked if pgp.mit.edu auto-updated from keys.openpgp.org how it used to work with the old SKS network. P.S. Please make create key revocation certificates for the cases: no-longer-used, superceded, and compromised, and store them someplace safe. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, Alexandru Mihail writes: > After yet some more software archaeology, I've uncovered some more > rusty HTML 1.0 documents which are of interest to our dilemma. > Apparently, NCSA HTTPd Acknowledgements as of 7-14-95 state: > "Thanks to: > Robert McCool > For developing NCSA HTTPd till version 1.3 and this documentation." > > https://web.archive.org/web/20090416132804/http://hoohoo.ncsa.uiuc.edu/docs/acknowledgement.html > > This is the time Robert left the project and the date (and license > release - 1.3) probably aligns best with the code we have in mini- > httpd. After extensive googling, it seems to me that the original mini- > httpd-1.0.0.tar.gz source is lost to time, or at least is buried beyond > my reach. That's ok, you don't need to find the original version. Remember that it's a fork and child relationship, so anyone, today, can fork httpd (1.1-1.3, 1.4-1.14, 1.15, etc.) under the license terms specific to a particular release. So, for a hypothetical case where the file[s] in question are identical for the following versions ..: 1.1-1.3: "Do what you want but only on continental landmasses" license || \\ || \=Possible fork point. If discriminating against islanders ||is important, then fork from this point. \/ 1.4-1.14: "Non-commercial use only, except for fishermen" license || \\ || \=Possible fork point. If privileging fishermen and ||discriminate against everyone else is important, then fork ||from this point. \/ 1.15: GPL3+ \\ \=Possible fork point. Only discriminates against those who wish to keep their source private while also distributing their fork. Fork from this point if that's important. ...then if httpd 1.15 is older then mini-httpd 1.30, you must choose 1.15. Meanwhile, Robert McCool's copyright still exists in 1.15 even if he hasn't made a contribution since 1.3. P.S. Please acknowledge: Have you read the DFSG yet, and do you understand why it's important? https://wiki.debian.org/DebianFreeSoftwareGuidelines > I transitioned all debian mail-related services to Google, and am using > a good MUA now (PGP signing properly). (BTW, does everything look all > right on your end?) I confirm receipt of your mail, and I see an attached signature. Where can I download your public key? > I've committed to salsa and uploaded to mentors a new .changes which > reflects the change in Maintainer's E-Mail. Naturally, I changed the > key and updated the changelog. Thanks! > Thanks and have a great day/night ! You too! :) Regards, Nicholas signature.asc Description: PGP signature
Bug#1040253: RFS: texlive-bin/2023.20230311.66589-1 -- TeX Live: LuaJIT, modified for use with LuaJITTeX (development part)
Hello Hilmar, Preuße, Hilmar writes: > On 04.07.2023 15:42, Nicholas D Steeves wrote: > >>>texlive-bin (2023.20230311.66589-1) experimental; urgency=medium >>>. >>> * New upstream snapshot made for TL 2023. >>>- Remove sources of dvisvgm from orig.tar.xz, we don't build >>> it anyways. >> >> Thus shouldn't the upstream_version have a suffix like +dfsg, +ds (for >> "Debian Source"), or +repack, as appropriate, depending on the reason >> dvisvgm is excluded? >> > I can add it, if it is needed. This is ultimately up to your sponsor, but I think it's needed. It's also friendlier to upstream, because it's possible that a bug exists when using Debian-package-provided deps rather than texlive-bin-bundled deps (or vice versa). The repack suffix makes it clear to upstream that their source was modified. > The original tar ball contains a lots of source code, which exists as > separate package in Debian. Hence I decided to remove the source code to > get a smaller tar ball: > > # packaged separately: > rm -rf $verstr/texk/dvisvgm > rm -rf $verstr/utils/biber > rm -rf $verstr/utils/asymptote > rm -rf $verstr/utils/xindy > rm -rf $verstr/utils/ps2eps > rm -rf $verstr/utils/t1utils > > The split off was done years ago, just this time I decided to remove the > (duplicate) code. Thank you, you have the right idea, and this action is appreciated! :) Assuming all of those deps are in Debian main, it sounds like the "+ds" suffix would be the most appropriate. Regards, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Alexandru,
Alexandru Mihail writes:
> Hello Nicholas,
> debian-legal replied, I could only find occurences of Rob McCool's NCSA
> derived code in htpasswd.c as well. The NCSA license states we might(not
> must) include a copy of their short legal excerpt on derivative works (and
> mini-httpd is one)
> Maybe we should include a mention of said excerpt in debian/copyright under
> htpasswd: and include the excerpt somewhere ?
> Anyway, it seems to me we're in the clear when it comes to DFSG.
Sort of in the clear; however, from what I've read there isn't just one
"The NCSA license"; there seem to be three. Rob McCool is still a
copyright holder, and needs to be documented in debian/copyright.
Because of the ambiguity as to which license (and license version)
applies, and because Debian's copy of mini-httpd is now the defacto
upstream, I insist that the applicable license is also documented.
Also, the way I see it, if you've done the work, you might as well
document your findings as well as the fact that you did the work. This
type of work, while not immediately evident, is nonetheless
copyrightable, so--if you want to--you will be able to add you own claim
to the debian/* section of copyright.
> Attaching debian-legal reply:
>
> On 2023-07-02 16:43, Alexandru Mihail wrote:
>> mini-httpd contains early portions of code commited by Rob
>> McCool which seem to originate from NCSA httpd.
>
> Just htpasswd.c (which is what I get when searching for Rob McCool), or
> something else?
>
>> How do we proceed to clarify this situation?
>
> Figure out (from the history of the code, etc.) if that license applies.
>
> Looking into this a bit, I found this repository (which I am _assuming_,
> but have not verified, is a faithful import of NCSA httpd):
> https://github.com/TooDumbForAName/ncsa-httpd/
>
> I definitely see some code from mini-httpd's htpasswd.c in
> cgi-src/util.c in the HEAD of that repository above.
>
> Looking at git blame on that, it came from auth/htpasswd.c in httpd 1.1:
> https://github.com/TooDumbForAName/ncsa-httpd/commit/9572b626b7f10ab57e4715b3f3ff41b3f0696684#diff-7c5a48b0225b3fd1048000f4dfe2c4d9f56faa29f74876ff724384244d6d099d
>
> So that seems to be the original source of the code in question.
>
> In that same version, the top-level README says:
>
>
> This code is in the public domain. Specifically, we give to the public
> domain all rights for future licensing of the source code, all resale
> rights, and all publishing rights.
>
> We ask, but do not require, that the following message be included in
> all derived works:
>
> Portions developed at the National Center for Supercomputing
> Applications at the University of Illinois at Urbana-Champaign.
>
> THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
> FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
> LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
> PARTICULAR PURPOSE.
>
Do you think that httpd 1.1, httpd 1.15, or some other version is the
most likely source? If they're identical from the perspective of
mini-httpd, then I think you can make an argument for either, even
though it's probable that mini-httpd inherited whatever license was
active at the NCSA at the time of mini-httpd's creation.
Note that public domain doesn't exist in some countries. In this case
("public domain"), the mini-httpd author would need to have written
mini-httpd (distribution might count too, but I'm not sure) in a country
that recognises public domain; then, the relevant public domain bits
would become implicitly relicensed under the primary license for
mini-httpd. If this is the case, then a note should also be added to
McCool's debian/copyright section.
Cheers,
Nicholas
signature.asc
Description: PGP signature
Bug#1040253: RFS: texlive-bin/2023.20230311.66589-1 -- TeX Live: LuaJIT, modified for use with LuaJITTeX (development part)
Hello Hilmar, > texlive-bin (2023.20230311.66589-1) experimental; urgency=medium > . > * New upstream snapshot made for TL 2023. > - Remove sources of dvisvgm from orig.tar.xz, we don't build > it anyways. Thus shouldn't the upstream_version have a suffix like +dfsg, +ds (for "Debian Source"), or +repack, as appropriate, depending on the reason dvisvgm is excluded? Regards, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, Thanks for the ping. I had forgotten that I had a WIP draft. Alexandru Mihail writes: >> > remember the original NCSA httpd licence. P.S. It feels like >> > archaeology to find missing documentation for something from the > > dawn >> > of > > Eureka ! > I present the original NCSA httpd license in its purest form after some > software archeology: > https://web.archive.org/web/20060830015540/http://hoohoo.ncsa.uiuc.edu/docs-1.5/Copyright.html Wow, you are good at this! :D > (NCSA HTTPd Development Team / ht...@ncsa.uiuc.edu / Last Modified 08-01-95) > == LICENSE START === > NCSA HTTPd Server > Software Development Group > National Center for Supercomputing Applications > University of Illinois at Urbana-Champaign > 605 E. Springfield, Champaign IL 61820 > ht...@ncsa.uiuc.edu > > Copyright (C) 1995, Board of Trustees of the University of Illinois > > NCSA HTTPd software, both binary and source (hereafter, Software) is > copyrighted by The Board of Trustees of the University of Illinois (UI), and > ownership remains with the UI. > > The UI grants you (hereafter, Licensee) a license to use the Software > for academic, research and internal business purposes only, without a > fee. Hmm, the above grant looks like it may not be DFSG compatible. Do you see how? https://www.debian.org/social_contract#guidelines or https://wiki.debian.org/DebianFreeSoftwareGuidelines or with a story https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines > Licensee may distribute the binary and source code (if released) to third > parties provided that the copyright notice and this statement appears on all > copies and that no charge is associated with such copies. If Rob McCool didn't ever relicense the part of NCSA HTTPd that is part of mini-httpd, then it looks like we might need to provide this notice, and upstream mini-httpd should have been doing so. > Licensee may make derivative works. However, if Licensee distributes any > derivative work based on or derived from the Software, then Licensee will (1) > notify NCSA regarding its distributing of the derivative work, and (2) > clearly notify users that such derivative work is a modified version and not > the original NCSA HTTPd Server software distributed by the UI by including a > statement such as the following: > > "Portions developed at the National Center for Supercomputing > Applications at the University of Illinois at Urbana-Champaign." Is this DFSG compatible? > Any Licensee wishing to make commercial use of the Software should contact > the UI, c/o NCSA, to negotiate an appropriate license for such commercial > use. Commercial use includes (1) integration of all or part of the source > code into a product for sale or license by or on behalf of Licensee to third > parties, or (2) distribution of the binary code or source code to third > parties that need it to utilize a commercial product sold or licensed by or > on behalf of Licensee. And is this DFSG compatible? > Any commercial company wishing to use the software as their commercial World > Wide Web server and are not redistributing the software need not commercially > license the software but can use it free of charge. and this? Note the clause "and are not redistributing the software". So you can't sell copies of this software? > Should we include a mention of this under debian/copyright stating > something along the lines of 'parts of mini_httpd.c under NCSA HTTPD > and include a copy of the license somewhere? Most likely, yes, but the bigger issue is if this license is not DFSG-compatible. > As far as I could dig, this is the license which should be attributed in our > case. This is the 1.15 htttpd license, and with 99.% certainty, this was > the chunk of code still found in mini_httpd.c. The logic is, NCSA httpd had, > historically, two licenses (chronologically): one open and one proprietary. > mini_httpd is a fork of the open one, that we can be sure of. I think there > is little reason to involve debian-legal at this point. > What's your opinion here? Thank you for the note about this history. I didn't know NCSA httpd had two licenses. I wonder if there was later a change to "everything that was 'open' is now permissively licensed" at some point? If the chunk of code is still big enough and original enough to meet the minimum threshold for originality, then yes, the original copyright and license would apply; however, I think this would mean that we need to find documentation that someone contacted the U of I (and/or Rob McCool). A quick query of tldrlegal shows an NCSA license that is shorter and more permissive: https://www.tldrlegal.com/license/university-of-illinois-ncsa-open-source-license-ncsa I suspect that NCSA httpd may have been relicensed to this shorter version. Yeah, this seems to be a case where it's worth contacting debian-legal, especially given those bits that
Re: New package: ITP or RFP ?
Ramūnas Keliuotis writes: > Hi, > > Thank you for the information, I was looking through Debian guides for a > while. > Will review your given links as well. > > Now I need answers to questions: > 1. Is it ok for source code to be in Github? or do I need a Salsa > account? If you're asking if everything can be maintained on one branch, the answer is that it will be easier to maintain a correct Debian package if you dedicate a branch to it. Also, when configuring a branch it's trivially easy to dedicate a different remote for the debian packaging branch. More on this later. The three most common workflows (in no particular order) are: 1. Use 'gbp import-orig --uscan' to download a tarball of the most recent upstream release, and merge that to the Debian packaging branch. 2. Merge git tags to the Debian packaging branch. 3. The "packaging branch only" approach, which only has the "debian" subdir. > 2. Do I need to create a source package? *.dsc dpkg-buildpackage, debuild, sbuild, etc. will create this for you. https://wiki.debian.org/Packaging/SourcePackage#The_definition_of_a_source_package > 3. How to implement build /scripts? > Now we are using bash scripts and preconfigured docker containers. > But dh scripts should be used, so, how to start using them? > I have installed Debian SID. I know that all dependencies must be there. https://www.debian.org/doc/manuals/developers-reference/tools.html#dh-make Your package will not have internet access when it is built, so all dependencies must be in debian/control. > 4. Also, we are using our own open source rust libraries > https://github.com/NordSecurity/libtelio > https://github.com/NordSecurity/libdrop > Maybe there is there a Debin Rust packaging team as well? Yes, if these are not in Debian then they will need to be packaged first. > Would be good to get reference to sample package - observe its build > configuration. I would follow the Developers Reference, use dh_make, and then compare the results with another package. Add "deb-src" lines to /etc/apt/sources.list enables easy access to source with a simple "debcheckout" or "apt source openvpn". https://wiki.debian.org/Mentors Have fun! Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Alexandru, Alexandru Mihail writes: > Hello Nicholas, > >> Sorry, my mistake. I meant to write "debian/copyright". One or more >> entries in the copyright file conflicts with upstream evidence. > > No problem, I think I found what you were referring to and corrected our > copyright, upstream is right. I documented the changes in the changelog. Aha, yes, that's 1/2 of what I was referring to :) The other half are those copyright years that predate the 1999 claimed in our copyright file. I also found what looks like a new issue: Those files that Rob McCool authored as part of NCSA httpd that are part of mini-httpd, what license are they? Attribution would be required if they were MIT/Expat, BSD, or similar. This issue might also affect apache2's copyright file, if anything remains of NCSA in Apache. Httpd predates the "NCSA" license, by the way. If you can't find anything about it, then consider contacting the debian-legal mailing list, because someone there might remember the original NCSA httpd licence. P.S. It feels like archaeology to find missing documentation for something from the dawn of the Web! Also, it's a mystery to me what license the original httpd was. >> > > Would you please push your work to your personal Salsa namespace (fork >> > > relationship optional), and provide the link to the repo? > > https://salsa.debian.org/alexandru_mihail/mini-httpd > Forked from master of: > https://salsa.debian.org/debian/mini-httpd Thanks. >> speaking these patch fixups aren't release critical, and you can ignore >> them if you'd like. > I will fix them, it's fine :) Thank you :) > Also, I uploaded again to mentors last night. > Thanks and farewell, You're welcome. We're in the last round of review, by the way, and I think it will be ready to upload with the next update. I hope that the forests aren't burning, wherever you are. Take care, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, Alexandru Mihail writes: >> 2. I found an inaccuracy in the upstream sections of debian/changelog; >> please fix it. Plain old grep or manual header check should be enough >> to spot this. > > Can you please elaborate a bit ? Are you referring to my changelog entry or > any mistakes in upstream.changelog or older debian/changelog entries ? Sorry, my mistake. I meant to write "debian/copyright". One or more entries in the copyright file conflicts with upstream evidence. Our obligation is to accurately represent upstream's claims; however, if you think the existing state better represents reality, and that upstream's copy is inaccurate, then please do something like 1. Correct our copy of upstream's claims. 2. Make a note about how the file previously contained a different claim, which you think is correct, and write why. The field that is used for this can be (quickly) found in this documentation: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ >> 3. Do the patches have accurate filenames, subjects, and synopses? >> Adopting a package is the perfect time to fix anything misleading. >> > Most of them are fine, I'd change the filename of "0006-fix-makefile", a bit > too generic, it changes some install dirs and adds -lssl to a compile target, > not exactly something obvious when you read "fix-makefile". I'll come up with > a better name. I agree most are fine, and yes the one you've pointed out could be nicer. The one I'm concerned about has a subject that doesn't appear to describe what the patch actually does, which is misleading. Strictly speaking these patch fixups aren't release critical, and you can ignore them if you'd like. >> Would you please push your work to your personal Salsa namespace (fork >> relationship optional), and provide the link to the repo? This way I > Will do, it was a very busy week :) No worries :) >> P.S. It seems like Debian's copy might be the defacto upstream, as of >> eight years ago, when someone wrote we were "doing a good job" >> maintaining mini_httpd. > Hah, I've heard the same thing from an OpenWRT maintainer a few years ago. > We're their defacto upstream as well (and any OpenWRT based router firmwares > such as Tomato, etc etc). Long live the red spiral, I guess :) Wow, I guess it's true then, and that your work will benefit more people than anticipated! This makes me think of the Civil Infrastructure Platform (https://wiki.linuxfoundation.org/_media/civilinfrastructureplatform/2017-08-cip-debconf-r5.pdf) > Have a great day, Likewise, you too! Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, Alexandru Mihail writes: > Turns out bullseye-backports lintian (2.115.1~bpo11+1) only checks for 4.6.1 > Standards, therefore a more serious error (depends-on-obsolete-package > lsb-base) was reported by sid lintian. > Upon inspecting the situation (lsb-base is now a transitional empty > package only here for debootstrap purposes mainly) and reading > https://lists.debian.org/debian-devel/2023/01/msg00160.html I removed > the package dependency entirely. This should be entirely safe. Nice catch, and if someone using OpenRC is affected, I hope that person will be willing to provide a patch for what sounds like a corner-case. > I also added Upstream-Contact into debian/copyright and stripped some > trailing whitelines. Package should be lintian O.K. now. Thank you. > Nicholas, my salsa account is verified now, waiting for push permission if > that is ok. Is there anything else I should do now about that ? > 1. What is the purpose of the dh_installsystemd override? (hint: see the dh_installsystemd man page about --name). 2. I found an inaccuracy in the upstream sections of debian/changelog; please fix it. Plain old grep or manual header check should be enough to spot this. 3. Do the patches have accurate filenames, subjects, and synopses? Adopting a package is the perfect time to fix anything misleading. 4. Does everything in your changelog entry still accurately reflect the package? (ie "not started by default"). Would you please push your work to your personal Salsa namespace (fork relationship optional), and provide the link to the repo? This way I can responsibly grant you permissions, because I will have reviewed how you work in git :) I can also review from git, if you prefer Regards, Nicholas P.S. It seems like Debian's copy might be the defacto upstream, as of eight years ago, when someone wrote we were "doing a good job" maintaining mini_httpd. signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Alexandru Mihail writes: > As for the old bugs, at least #491078 and #1018900 are stil present, I > shall test a user submitted patch for the first one. Thank you for taking the time to verify and document this. While not required, it would also be nice if #491078 was noted in the appropriate patch[es]. Bug-Debian is an optional field: https://dep-team.pages.debian.net/deps/dep3/ > I'll also create a salsa account soon. Thanks! Do you know if you'd prefer to fork and file pull requests/merge requests, or wait for the permissions to push directly to be granted? > I hope this mail finds you well ! > Thanks, you as well! Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Lorenzo, Thank you for the help with reviewing :) Hi Alexandru, Reply follows inline with two hints. Lorenzo writes: > On Thu, 01 Jun 2023 12:05:51 + > Alexandru Mihail wrote: > >> I've uploaded again to mentors, the (now gone) lintian warning >> complained about missing the SystemD service for the package. I've >> added one from scratch and upon initial testing it performs OK. Wonderful :) By the way, do you know if the forking service type is needed for mini-httpd? This page notes when that type is required: https://wiki.debian.org/systemd/Services >> I modified debian/rules to take the service into consideration though >> this raises some concerns for non-systemd Debian installations. I >> assume further modifications are required to intelligently enable or >> ignore the service (use old init.d mechanism). Thank you for considering the implications of your changes, especially at this phase of the freeze when we all need to be really careful about any changes. > (looking at your rules file) > override_dh_installinit: > dh_installinit --no-stop-on-upgrade --no-start --name=mini-httpd > > override_dh_installsystemd: > dh_installsystemd --name=mini-httpd > > if the '--no-stop-on-upgrade --no-start' is to avoid a conflict between > the systemd service and the init.d file, you don't need that: debhelper > generated scripts should do the right thing. > If you look at generated maintscripts One way to do this is 'dpkg-deb -R [aka: --raw-extract] archive directory', then inspect the DEBIAN dir. > you see that systemctl calls are guarded by a test for > /run/systemd/system (it imply that systemd is the running init); the > equivalent code for sysvinit (invoke.rc.d) is not guarded but that's > ok since other inits are supposed to mask initscripts and systemd > already does that. Thanks again for your analysis and explanation Lorenzo! Regards, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Alexandrus, It appears that your mail user agent (possibly webmail) is encrypting emails to me when you "reply all" to the bug; the effect is non-public. It may be that the only way to fix that effect is to either 1. not CC me (just send to the bug) 2. Make that interface forget my key, because it always encrypts when a key is available. 3. Maybe there's a config toggle that disables unconditional encryption, for use with mailing lists? Alexandru Mihail writes: > Hello Nicholas, > Of course, please quote the first email at the bug. My apologies for omitting > to reply all :) -- Re PM follows: > Thank you a lot for taking the time to sponsor my work, it is a great > pleasure and honor for me to finally contribute to Debian packages, after 11 > years of daily usage :) . Sorry for the later reply, it's morning here. You're welcome! :) No worries with taking time to reply, and feel free to ping me if I take to long to reply. >> "Do you intend to continue to maintain mini-httpd at this location (Vcs >> location), or do you have a new one in mind?" >> > Do you have any preferences/suggestions regarding this question? > I am comfortable with git so forking on git wouldn't be a problem. I have no > remote to share so far. Since you're comfortable with git, please consider creating a Salsa account and continuing to maintain the package in the Debian (previously collab-maint) group. Here's more info on what that means: https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group It's ok if you don't want to; however, in this case we'll need to update the Vcs links in the package. >> "On the topic of work, has upstream resolved any of these old bugs" >> > The latest upstream release is still mini_httpd-1.30.tar.gz. ACME > produces quality releases in general, but their release cycle is > pretty lethargic as they are a small team working on many tools. That's ok, and totally understandable. What I meant is that 1.30 isn't that old compared to Bug #437932 (14 Aug 2007), #516307 from 2009. Those look like they may have already been fixed upstream. Then there are ones like #491078 that may have been fixed in Debian and/or upstream, or could be fixed in the next upload to Debian. > As context, I've worked professionally on patches for mini-httpd for about 9 > months, adding PAM support and AAA authentication. Sadly, the license of my > work is evidently proprietary. If I have the time I can try to tackle all the > bugs alone, as I know everything that's happening in mini_httpd.c. I'll try > mailing Jef (from ACME) to see if any fixes are in the pipeline. Nice, it sounds like you're the ideal maintainer for Debian's mini-httpd! It also sounds like you already know work to get things merged upstream whenever possible. > I might need a wee bit of assistance with lintian errors/Debian > conventions as I mainly come from RPM land. I've packaged debs before > for my employer, but Debian's standards and procedures are very > different (and that's a good thing !). Oh good, you're already using lintian :) Please take care to use a recent version like 2.116.3 or 2.115.1~bpo11+1 (bullseye backport). Run it with the "--info" argument to get explanations. There is currently one warning (W) that needs to be fixed before this package is ready to upload. > I'm looking forward to your input and have a great weekend ! Thank you, I hope yours was as good as mine! Regards, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, Please take care to reply in cleartext to this RFS bug (#1036751), using "reply to all" or "reply to list", because it's expected that most Debian development and discussion happens in the open. It's also important to have evidence of progress so that someone's bug cleanup script doesn't mark the project as stalled and close the bug. May I quote your decrypted email (the first and longer one) at this bug in my reply? Best, Nicholas signature.asc Description: PGP signature
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Control: owner -1 ! Control: tag -1 +moreinfo Control: block 927950 by -1 Hi Alexandru, Welcome! I'd like to sponsor your work, and I hope that attention to detail doesn't annoy you. Please take a look at the questions in the following reply: Alexandru Mihail writes: > * Package name : mini-httpd >Version : 1.30-4 >Upstream contact : Jef Poskanzer j...@mail.acme.com > * URL : https://www.acme.com/software/mini_httpd > * License : BSD-2-clause > * Vcs : https://salsa.debian.org/debian/mini-httpd Do you intend to continue to maintain mini-httpd at this location (Vcs location), or do you have a new one in mind? Do you intend to maintain the package in git, and if so would you please share the remote of your fork? You don't have to if you don't want to, by the way. > mini-httpd (1.30-4) unstable; urgency=medium > . >* New maintainer. (Closes: #927950) Thank you for adopting this package! >* Added missing newline in the rules file >* Bumped Standards-Version to 4.5.1 This doesn't make sense, because, in 1.30-3, Håvard F. Aasen updated Standards-Version to 4.6.1; in other words, this line claims you regressed the package back to 4.5.1. Yes, Aasen didn't document this change in the changelog, and that makes it unclear what happened...maybe it was a "bump", but maybe Aasen did the work of checking the package was compliant. I'd like you to verify compliance with the current version of Debian Policy (4.6.2), and here is the checklist to help you along your way. Please start at 4.4.1. https://www.debian.org/doc/debian-policy/upgrading-checklist.html. and I'd like to see you document your work with: * Declare compliance with Standards-Version 4.6.2. (no changes required) because I believe that you're not a robot ;) One of the perspectives I was mentored to uphold is that "bumping" is for robots. Please note that your sponsor will need to manually check for compliance with Policy before uploading. Yes, this means duplicate work, or even triplicate work if it was a package that needed ftpmaster review! The number is just a number, and what really counts is the work. On the topic of work, has upstream resolved any of these old bugs: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mini-httpd If so, let's talk about closing them! This is a normal part of adopting a package (closing fixed bugs, and/or reopening ones that are still relevant). Regards, Nicholas signature.asc Description: PGP signature
Bug#1021364: RFS: ghostwriter/2.2.0-1 [RC] -- Distraction-free, themeable Markdown editor
Sebastien Chavaux writes: > it's a bit of a mess, I made changes, in debian/copyright, unfortunately it > makes build errors: > *** No rule to make target '3rdparty/MathJax/bin/startup.js', needed by > 'build/release/qrc_resources.cpp'. > Stop. > make[1]: *** Waiting for unfinished jobs > make[1]: Leaving directory '/build/ghostwriter-2.1.6+dfsg' > dh_auto_build: error: make -j6 returned exit code 2 > make: *** [debian/rules:6: build] Error 2 > dpkg-buildpackage: error: debian/rules build subprocess returned exit > status 2 > I: copying local configuration > E: Failed autobuilding of package > > Isn't libjs-mathjax MathJax2, and doesn't Ghostwriter needs MathJax3, which is incompatible with MathJax2? https://github.com/KDE/ghostwriter/blob/master/3rdparty/MathJax/src/package.json Here is the RFP bug for MathJax3 for anyone who is interested in packaging this important javascript library: https://bugs.debian.org/950424 Regards, Nicholas signature.asc Description: PGP signature
Re: Can I know how to resolve the error "No public key found for key"
Hello Makoto Yamashita, Makoto Yamashita writes: > Dear whom it may concern, > > Thank you very much for reading my email. > I am a maintainer of the SDPA package and I am trying to > upload a modified file, but I received the following mail. > > Unable to verify file sdpa_7.3.16+dfsg-1_amd64.changes. No public > key found for key > Please try to fix it and re-upload. Thanks, > > Looking at https://tracker.debian.org/pkg/sdpa shows that you have always had sponsored uploads, so I am guessing that you are uploading to mentors.debian.net. Please verify that dput is actually attempting to upload there and not to somewhere else like ftp.upload.debian.org. It may also be necessary to update your key on https://mentors.debian.net (use a web-browser to do this). Please note that if you are uploading using a different email address than the one you had used before, then you will need to add that identity to your GPG key, and you will also need to upload the updated key to mentors.debian.net. Regards, Nicholas P.S. On Debian mailing lists it is assumed that you are subscribed. If you are not subscribed, then no one will CC you unless you ask "Please CC me" in every email you send to that list. I am breaking that convention because I worry that you did not receive Andrey's reply. signature.asc Description: PGP signature
Re: Bug#1010663: RFS: strawberry/1.0.4-1 [ITP] -- Audio player and music collection organizer
Hi Peter, Thank you for working on packaging Strawberry for Debian! I was the one who requested Clementine database import functionality (upstream) some time ago, and have been using MPD+Cantata while waiting for Strawberry to mature. Clementine memory usage (and crashes) forced me to give it up, and I'm looking forward to trying out Strawberry some day :) Also, thank you for your willingness to learn Debian standards and rationale; a lot of this stuff is nonintuitive, but eventually the rationale guiding the mentorship decisions will become second-nature. Thank you for your mentorship Bastian! Regards, Nicholas signature.asc Description: PGP signature
Re: Looking for a new maintainer for the "rush" package
Dear Mats, Fabio, and MIA Team, Mats, would you please skip the "Hi Mats," section below? MIA Team, It sounds like Mats probably intends to retire, but this conclusion isn't beyond reasonable doubt--so this Maintainer's packages are in a limbo state. TLDR; David Kalnischkies recommended contacting your team 2022-03-17, and Mats has not yet followed up on the debian-mentors thread. Given that it's almost been a month without follow-up, I feel that opening a ticket is justified, pending clarification. Maybe you will interpret the record differently and understand that Mats expresses a more strong intent to leave than I understood? "Fabio A. De Muzio Tobich" writes: > Em 17/03/2022 17:19, Mats Erik Andersson escreveu: >> Torsdag den 17 mars 2022, klockan 15:22, skrev Nicholas D Steeves detta: >>> >>> From a thread on debian-mentors, >>> >>> vimer writes: >>> >>>> Hi, >>>> On Tue, Mar 15, 2022 at 05:23:16AM -0700, deb...@lewenberg.com wrote: >>>>> The Debian package "rush" has not been updated since 2017. The >>>>> upstream software is actively maintained and has advanced from the 1.x >>>>> version in Debian to version 2.x (the latest version is 2.2 released >>>>> Jan 2022). I filed a bug in Dec 2021 to have the upstream changes >>>>> packaged, but no response from the package maintainer was forthcoming. >>>>> >>>>> Is there someone who can take over the maintenance of this package? [snip] >>> >>> Given the OP asked for "someone who can take over the maintenance of >>> this package", and given the state of the package, salvaging "rush" >>> would be more appropriate: >>> [snip] >>> Anyone interested in pursuing the process may follow the Developers >>> Reference section "How to salvage a package"; Please note that the >>> maintainer also has rights, so one must wait 21 days after filing the >>> ITS before proceeding with the salvage operation. >>> [snip] >> >> The truth is that I am in no position to verify my identity >> to the Debian project, ever since the time it began demanding >> three signatures of trust. So even if I desired to commence >> an up-to-date packaging effort, there is no sensible means >> for me to achieve that endeavour. Therefore I hereby annonce >> my desire for another responsible and devoted person to take >> over maintenance of "gnurush". This is a piece of software >> that deserves continued use under diligent maintainership. >> I did try my best during a period in time, but now I leave! >> >> Best regards, >>Mats Erik Andersson, dr sci math >> Hi Mats, As David Kalnischkies noted, identity verification is not required for sponsored uploads, but only for the "Debian Maintainer" (uploading rights granted for a select list of packages) role. Given that your retirement is predicated on "there is no sensible means for me to achieve [identity verification]", and identity verification is not in fact required, the conclusion does not follow from the premise, resulting in an ambiguous state. Are you interested in continuing to maintain your packages, or would you like to Orphan all of them, or would you like to orphan only a subset of them? I noticed that you maintain more than a few packages :-) Thank you for your work! If it would be too much of a hassle to file Orphan bugs for all of your packages then would you please reply to at least m...@qa.debian.org ? I've added them to CC for your convenience, as well as to tentatively initiate the investigation process. Let them know that you're retiring from Debian, if that's what you intent to do. I feel like that's probably what you intend, but Debian has extensive formal processes in place to prevent people from hijacking the work of others, and this is one of those processes. That said, I always hope that Maintainers will resume contributions! > Greetings, > Hi Fabio! > Since Mats has expressed his desire to pass the package on to a > new maintainer, I'm guessing it's not necessary to go through > the salvage process. Therefore an ITS would be unnecessary and > one could adopt the package directly. > > Maybe orphan the package, then open an ITA. > I've initiated the MIA process; although, I hope that Mats didn't actually intent to retire. > So I ask, is there anyone working on this package? > Well, no one filed an ITS, which is too bad because the 21 day wait would have expired by now. > If not, I believe I can adopt it. > That's great news! :-) As I interpreted the discussion, lots of people would like to see GNU Rush updated, but no one wanted to maintain it long-term. Kind regards, Nicholas signature.asc Description: PGP signature
Bug#1003855: RFS: kotlin-mode/20210917git0-1 [RFP] -- Emacs major mode for kotlin
Hi Joshua, Joshua Peisach writes: > Hi Nicholas, > > The pristine-tar branch is already pushed. And finals won't be happening > until April ish > > https://salsa.debian.org/emacsen-team/kotlin-mode/-/tree/pristine-tar > > > Is something missing? Ah, sorry, I was scanning for a 0.*~ prefixed version and communicated poorly. This is needed to defend against the use of an epoch whenever upstream switches to a tagging stable version, ie 20210917git0 sorts higher than 1.0.0. The cause of this was overriding uscan's "pretty" option in debian/watch. I made the necessary fixups and uploaded. Please review the changes at your leisure :-) Cheers, Nicholas P.S. I chose to enforce xz compression because you're using uscan's git mode, which makes the argument for github release tarballs nonapplicable. For some reason your copy of uscan downloaded an orig.tar.gz instead of an orig.tar.xz, and this gbp.conf will prevent "what is going on?!" moments from emerging. signature.asc Description: PGP signature
Bug#1003855: convert RFP to ITP and set owner
retitle 922934 ITP: kotlin-mode -- Emacs major mode for editing Kotlin files owner 922934 Joshua Peisach thanks Joshua, please take care to select the *reply to all* function rather than "reply" in the future, because bug_num...@bugs.debian.org should be kept in CC. Debian is developed in the open, and not via private messages.
Re: Looking for a new maintainer for the "rush" package
From a thread on debian-mentors, vimer writes: > Hi, > On Tue, Mar 15, 2022 at 05:23:16AM -0700, deb...@lewenberg.com wrote: >>The Debian package "rush" has not been updated since 2017. The >>upstream software is actively maintained and has advanced from the 1.x >>version in Debian to version 2.x (the latest version is 2.2 released >>Jan 2022). I filed a bug in Dec 2021 to have the upstream changes >>packaged, but no response from the package maintainer was forthcoming. >> >>Is there someone who can take over the maintenance of this package? > In case the maintainer does not mark the package as 'O'(Orphaned) package, > we can do some fix or update with NMU[0]. > > But it's would better to do NMU for active Debian Developer. > Given the OP asked for "someone who can take over the maintenance of this package", and given the state of the package, salvaging "rush" would be more appropriate: https://wiki.debian.org/PackageSalvaging https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging #929160 justifies a minimal NMU fixing only that bug. I've CCed Mats, because the best solution is for the maintainer to take care of this :-) Anyone interested in pursuing the process may follow the Developers Reference section "How to salvage a package"; Please note that the maintainer also has rights, so one must wait 21 days after filing the ITS before proceeding with the salvage operation. Regards, Nicholas signature.asc Description: PGP signature
Bug#1003855: (everything)
Hi Joshua, So, would you like me to take care of converting the RFP to an ITP, and adding taku0 to the copyright holders? I'm part of the Debian Emacsen Team so also take care of the other nitpicks in git; they're not release critical blockers, so go into the -2 source-only upload. Regards, Nicholas signature.asc Description: PGP signature
Bug#1003855: (everything)
P.S. If you'd like me to do the BTS paperwork for you, or if you can't make sense of the docs, please let me know. I know it can be difficult and frustrating, and honestly, even I still make mistakes with it! I'd CC you, so you would see exactly how it works. In other words, I don't mean for want this to be a barrier for you :-)
Bug#1003855: (everything)
Hi Joshua, Reply follows inline: Joshua Peisach writes: > Hi Nicholas, and thank you for helping me! > You're welcome, and I hope you're enjoying the process as a learning experience :-) I don't believe in assigning "yak shaving" busywork, so if there's anything that seems excessively strict to you, please let me know so I can share why it's worth your time. > I've applied your suggestions (I kind of bunted the long description, looked > at other descriptions in other emacs packages). As for d/rules, I tried a > drop-down approach. I hope it works. > Long description is good, thank you, and thank you for changing the section! Oh, sorry, I forgot to mention that proper nouns should remain capitalised in the short description--this is just a nitpick. Rules is much better now; however, Cask will not be integrated into debhelper, because we use dh-elpa. See Bug #837922 for more info. I would be happy to explain in more detail if you have questions about this. > In d/copyright, a small glance at the header of the .el files show the > license (lol) > Yes ;-) The ftpmaster who reviews this package will find discrepancies equally quickly. The following omission is not release critical IMHO (specifically for a GPL-3+ package), but you'll be asked to add: 2019 taku0 and it's possible an ftpmaster will reject the package for having an incomplete copyright file: https://ftp-master.debian.org/REJECT-FAQ.html Finally, #922934, the RFP (request for packaging) bug should be converted to an ITP (intent to package) bug ASAP, and you should take ownership of it. Best practices is to do this before starting work, to avoid duplication of work, especially to avoid the demotivating situation where a DD who isn't aware of your RFS (request for sponsorship) independently creates their own package, then uploads it...making your work a wasted effort. This happened to me once. Claiming an ITP can be done with either pseudo-headers, the "bts" CLI command, or by emailing cont...@bugs.debian.org https://www.debian.org/Bugs/server-control The two commands you're need to use are "retitle" and "owner". When using the pseudo-header method for these commands, "-1" refers to bug being acted upon. You can find an example here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003855#21 When you're finished, please remove the moreinfo tag from this bug. If you'd prefer, you can do all BTS operation is one shot by emailing cont...@bugs.debian.org specifying 922934 and 1003855 where appropriate. Don't forget to CC both bugs if you use this method, and don't forget the termination string: https://www.debian.org/Bugs/server-control#thanks Regards, Nicholas signature.asc Description: PGP signature
Bug#1003855: RFS: kotlin-mode/20210917git0-1 [RFP] -- Major mode for kotlin
Hi Joshua, This is just a gentle ping for a status update. I hope your semester is going well :-) Regards, Nicholas signature.asc Description: PGP signature
Bug#1003855: RFS: kotlin-mode/20210917git0-1 [RFP] -- Major mode for kotlin
Control: tag -1 moreinfo I'm happy to see that my feeling that the technical side of your work was good was proven correct! It builds, dh-elpa tests pass, autopkgtests are good, and it's lintian clean. Please untag moreinfo when the issues raised in the previous email have been resolved. Apologies if my reply didn't get past your spam filter, I'm still working through the capabilities of my ISP's smarthost replay. A copy of the email is available at https://bugs.debian.org/1003855 If you'd like clarification about anything, please let me know.
Bug#1003855: RFS: kotlin-mode/20210917git0-1 [RFP] -- Major mode for kotlin
Control: owner -1 ! Hi Joshua, Joshua Peisach writes: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "kotlin-mode": > > * Package name: kotlin-mode >Version : 20210917git0-1 >Upstream Author : Emacs Kotlin Mode Maintainers > * URL : > https://github.com/Emacs-Kotlin-Mode-Maintainers/kotlin-mode > * License : GPL-3+ > * Vcs : https://salsa.debian.org/emacsen-team/kotlin-mode >Section : lisp > I'd be happy to sponsor this one! Thank you for your work, and yes, I agree that this should be part of Debian. Here are a couple of points that need to be worked on, one nitpick, and one enhancement. Copyright either isn't accurate or is missing a citation (or copy of email as proof of the asserted copyright). Using a tool like silversearch-ag (or similar) and searching for "copyright", "©", or '\(c\)' will reveal the inconsistency. Please list documented copyright holders with documented copyright years, or provide proof for what is currently asserted. Short description needs to mention Emacs. Nitpick: first letter should not be capitalised. Long description: this was copy and pasted and needs to be rewritten for a Debian context. Nitpick: Section: lisp is acceptable, but lintian is making an overclaim when it complains about this. Noninteractive libraries are definitely section: lisp, but this package is used to interactively edit Kotlin files so should be Section: editors. Rules: We use dh-elpa and not Cask, and Cask doesn't integrate with Debhelper, so the comment is misleading. Overridden targets can empty, and there is no need for those colons. If you'd like to make build log output nicer, here's a neat trick for the body of override_dh_auto_build: @echo Ignoring upstream Makefile and building/installing with dh-elpa. I'll take a more in-depth look tomorrow (eg: I didn't check to see if it FTBFS or if autopkgtests function). Cheers, Nicholas signature.asc Description: PGP signature
Re: cppcheck: Incorrect minimum version requirement for Depends: on libc
Hi Joachim, Joachim Reichel writes: > Hi, > > On 19.11.21 18:35, Joachim Reichel wrote: >> I'd appreciate some help with a problem I don't understand. >> >> Bug #1000146 against cppcheck 2.6-1 (in testing and unstable) is about the >> fact >> that /usr/bin/cppcheck seems to require "libc6 >= 2.32" while the Depends: >> line >> in the binary package cppcheck contains "libc6 (>= 2.29)". > > I debugged this a bit further and found that dpkg-shlibdeps does not take > certain symbols into account. Details are in bug #1000421. > Nice find! Cheers, Nicholas signature.asc Description: PGP signature
Bug#1000324: RFS: ghostwriter/2.1.0-1 -- Distraction-free, themeable Markdown editor
Hi Sebastien, Sebastien Chavaux writes: > > Thank you first of all. So it's not that I don't want to maintain git / > salsa, it's that I'm not comfortable with it, should do a remedial course > on it. > I also found git hard to start out with. The first thing I noticed that all documentation seemed to omit was how important it is to set EDITOR in ~/.bashrc. Beyond that, here are the three approaches I took: 1. Keep it simple, and use debcommit. With this approach I assume whole-repository granularity. Note that one pitfall with this method is that you may need to manually run "git status", "git add ./", and "git remove list of files". "git add ./" will also add backup-files~, which is annoying. To be fair, debcommit+git does support more a more fine-grained staging and committing workflow, but I never really got comfortable with it. One significant advantage to this approach is that it encourages objective-driven development. eg: your "* changelog entry for foo" can be seen as your goal; then you work to accomplish your goal. * uscan * dch -v1.0.1 # Make any change, even as simple as , then save and exit * debcommit -a # This "opens a new changelog entry" in git history [a]* Attempt a build * If it fails, make changes * dch # Document the purpose of your changes, save, and exit * debcommit -a ... cycle back to [a] and so on... Eventually "dch -r", commit, and tag. 2. git-buildpackage a bit more difficult, but still fairly easy to use, and optionally enables a the opposite workflow, where the changelog is generated from commit messages. When this was my primary approach I manually ran git commands as necessary. 3. Learn to use Magit to exploit the full power of git staging, reverting, rebasing, 3-way diffing during conflicts, etc. This is now my preferred approach, because it enables one to do all the work at once, then quickly stage specific groups of files and lines from files (such as changelog) into atomic, self-contained commits. Getting comfortable with this approach requires getting comfortable with Emacs, which might not be something you're interested in. For what it's worth, I was initially skeptical, but after a few months found it totally worthwhile. Whatever approach you end up taking, I hope you'll one day have an empowering "Aha!" moment when you realise that your work wasn't wiped out by a hasty "git reset --hard committish". eg: https://stackoverflow.com/questions/5473/how-can-i-undo-git-reset-hard-head1 Beyond this, it's a bit annoying to have to locally delete a release tag if your mentor asks for revisions; this includes updating the changelog, committing, rerunning "dch -r", committing, and retagging. > I will see how to define the same list of architectures as qtwebengine5. I > watch this and do it after work. > This sounds like a good approach to me :-) Cheers, Nicholas signature.asc Description: PGP signature
Bug#1000324: RFS: ghostwriter/2.1.0-1 -- Distraction-free, themeable Markdown editor
P.S. Yes, these methods aren't mutually exclusive; they can be combined. I was just trying to keep things simple ;-) signature.asc Description: PGP signature
Bug#996189: RFS: liesel/5.1.1 -- prepares PDFs to be printed as pamphlets/booklets
Dear Andrew, Andrew Rightenburg writes: > Package: sponsorship-requests > Severity: normal > X-Debbugs-Cc: and...@rail5.org > > Dear mentors, > > I am looking for a sponsor for my package "liesel": > > * Package name: liesel >Version : 5.1.1 >Upstream Author : rail5 > * URL : https://gitlab.com/rail5-bookthief/liesel > * License : GPL-3.0+ with runtime exception for OpenSSL > * Vcs : https://salsa.debian.org/rail5/liesel >Section : misc > > It builds this binary package: > liesel - Command-line utility to prepare PDFs to be printed as > pamphlets/booklets > > To access further information about this package, please visit the following > URL: > > https://gitlab.com/rail5-bookthief/liesel > This RFS caught my eye because I have a substantial interest in print culture. Here are a couple of comments: Have you read the Upstream Guide: https://wiki.debian.org/UpstreamGuide ? "focal" is not a Debian suite, and the Debian packaging should be on a separate branch if it's maintained in upstream VCs. Typically git tags are then merged to that branch. IIRC this info (and more) should be in the debian-mentor mailing list archives, but it will probably be faster to just read the Upstream Guide. Next, I don't think that Misc is the right section. After consulting the following, I think you will agree that there exists another section that will make your software more discoverable: https://packages.debian.org/unstable/ :-) A Debian ITP (Intent to Package) bug is also missing, closing that ITP in the first--and only--changelog entry is also missing. Also, in your ITP bug and long description (in debian/control), please compare Liesel to alternatives that already exist in the archive. After consulting https://gitlab.com/rail5-bookthief/bookthief, it looks like liesel exclusively supports four pages per pamphlet/booklet? Here are some other docs you'll need to read sooner or later: https://www.debian.org/doc/debian-policy https://www.debian.org/doc/manuals/developers-reference https://www.debian.org/doc/manuals/debmake-doc/index.en.html https://www.debian.org/doc/manuals/maint-guide For Liesel to be become part of Debian it will, at a minimum, need to be DFSG and Policy-compliant, and you'll definitely want to read the Upstream Guide. Your sponsor will also ask you to make the package "lintian clean". If all of this sounds like too much work, then you'll want to file an RFP (Request for Packaging). For both an ITP and RFP, use the command "reportbug wnpp". Take care! Nicholas signature.asc Description: PGP signature
Bug#976113: Closing Hydrogen RFS
> > Hi Nicholas, > > Uploaded! Thanks for all the hard work getting hydrogen reintroduced > through several beta releases etc. > Thank you on both accounts! > I am closing the RFS bug manually as the package could sit in the NEW > queue for a while. > I hope it's accepted in less than ~34 days so the package will make it into bullseye! :-) > I have also merged your changes and my last minute tweak into the salsa > repository. > Thanks! I've gone ahead and deleted the now-uneeded rfs-976113-rebase branch and also the master-next branch that I had created for Dennis to work from for things he wanted to see in -2. If for some reason you'd like me to resurrect one of both of them, I can do this within a week--after that, my backups will rotate them into oblivion. Have you created the release tag on your local master branch, or shall I, and would you like to push the tag when the package is accepted, or would you like me to remember to do so? Cheers, Nicholas signature.asc Description: PGP signature
Bug#976113: P.S. Re: RFS Review for Hydrogen
Hi Ross, I just noticed that the package of mentors was out of date, so I have built and uploaded as fresh copy. When consulting git, please take care to look at the rfs-976113-rebase branch. The commit intended for release is 3bbf783 on this branch, and intended version can be identified on mentors with the changelog footer "Wed, 06 Jan 2021 21:17:22". It may take a few minutes for mentors to pick up the new package, but we should be good to go after that :-) Thank you, Nicholas signature.asc Description: PGP signature
Bug#976113: RFS Review for Hydrogen
Hi Ross, Sorry for the delay, so tired and busy here! Ross Gammon writes: > Please note, I was not able to do a test installation to check hydrogen > is working. I hope you can confirm that. > I can confirm it works for everything I use it for, but unfortunately I don't have any midi gear to test midi-related functionality. > Blocking upload: > 1. The package fails to build twice in a row (I used the --twice option > in pdebuild). It appears some translation files are not being cleaned > after the first build. > Thank you for spotting this. I've activated a build hook to catch cases like this in the future. Fixed, and fixed an assumption I had made about the translations. > Minor things: > 1. We could enable Salsa CI by adding a debian/salsa-ci.yml file. We could, but I don't think Hydrogen's test is significant enough to make it worthwhile to spin up an instance every time someone pushes to the repo (cost of resources, and cost of carbon footprint). > 2. I think the copyright-hints & check files can be removed as they were > used by cdbs? Done, queued for the source-only -2 upload > 3. The github issues page could be added to the upstream metadata > file. Is this user facing? I have been specifically omitting this from my packages, because I worry that it will make it more convenient for the user to click and report upstream, despite "Don't file bugs upstream" (https://www.debian.org/Bugs/Reporting). > 4. I am not sure what is going on with the icon. There is a lot going on > in d/rules and also a patch. This is probably something that should be > sorted out upstream. As a minimum we should probably forward our patch > upstream or tag the patch as "Forwarded: not-needed" if it is not an > upstream issue. I note that in Ubuntu, they install an svg into the > pixmaps folder. Yeah, it's confusing to me too, and yes, ought to be solved upstream. The png (erroneously named as a bmp) is used internally for something, and I'm not sure using the svg in that context would succeed, but it seems like it ought to be. The SVGs we install are: usr/share/hydrogen/data/img/gray/h2-icon.svg usr/share/hydrogen/data/img/gray/icon.svg usr/share/hydrogen/data/img/gray/warning.svg usr/share/icons/hicolor/scalable/apps/org.hydrogenmusic.Hydrogen.svg > 5. Patch 2001 should probably be tagged as "Forwarded: not-needed" as it > seems Debian specific. Done. Queued for -2. > 6. I see that even with all hardening options enabled in d/rules, we > still get the "hardening no fortify" lintian error. Are there some flags > not being passed to the build system? Possibly. I will investigate and plan to solve this for -2. > 7. I see the large number of commits to add library packages and upload > pre-release versions has resulted in some churn in the changelog. I > think some entries can be removed now that we have agreed to upload a > simpler structure and because it is a proper release (e.g. disabling the > documentation)? > I believe I cut the bin:lib-pkg ones, but I see I missed the docs ones. Fixed. > Suggestions/Considerations: > 1. It is worth taking a look at the version of hydrogen uploaded in > Ubuntu by Erich Eickmeyer. By adding ladspa-sdk and libtar as build > dependencies (and a patch), it appears that the hydrogen builds with > extra options. I considered enabling new features, but chose to change the package as little as possible, because we're so late in the bullseye cycle. I'm of course open to enabling them if someone else will thoroughly test the features. > Erich also switched the jack dependency to jack2. When building with libjack-dev, debhelper should indirectly generate a dependency on libjack-jackd2-0 | libjack-0.125. My rational for not switching is that I'm aware of users of older Firewire interfaces who prefer (or need) jack and not jack2. I also asked #debian-multimedia for confirmation that sticking with jack was consistent with team policy and received a firm statement to not switch to building against jack2-dev. > 2. I see we have added a lintian override for the desktop and appdata > files not being in the same package as the executable. Is there a reason > for not just installing the desktop/appdata files with the executable > instead of in -data? > If I remember correctly this was one of the previous maintainers' decisions, and I think it had to with putting everything is arch:all into the -data package--personally I think that's a reasonable design decision. bin:hydrogen Depends on bin:hydrogen-data, and bin:hydrogen-data Recommends bin:hydrogen, so they'll almost always both be installed. Do you know if appdata files should always go in the same package as the executable? Thanks again for taking the time to review and sponsor! Nicholas signature.asc Description: PGP signature
Bug#976113: Bug#954823: Sponsorship of hydrogen
Hi Ross, Updated package upload to mentors, and pushed to the WIP branch called rfs-976113-rebase. I've of course merged this to master locally, so that the debian release tag will exist on the correct branch. Let me know if there's anything else you'd like to see. Other than that, reply follows inline: Ross Gammon writes: > On 30/12/2020 00:55, Nicholas D Steeves wrote: >> Ross Gammon writes: > OK - I think we are a bit too close to the next Debian release to be > making things complicated. Maintaining a library complicates upgrades to > new versions if transitions are required, and can be problematic if the > the ABI is not stable. I don't know how stable the hydrogen library is. > Why don't we just stick to how it was structured before it was removed? > That way users of Hydrogen in making music (like me) can just use the > application like they used to. > Done. > We have to go through the NEW queue to get hydrogen into the next > release, so making the ftp-master review as simple as possible (with a > rock solid copyright file) is the least risky approach. > Copyright should be good. I did at least three full reviews in 2020, including one just now. > I think the main reason for splitting stuff out into a *-data package is > to split the architecture dependent files from the architecture > independent files. When looking at the contents of the old hydrogen > package, you could question some of the decisions between the -data and > -doc packages. > Ah, yes that makes sense :-) > Maybe after the release we can think about helping developers of > potential plugins, and moving files around between packages? That is > unless the previous structural decisions contributed to any bugs! > > We can always backport new versions for users of Debian stable after the > release if there is a demand. > Agreed, and I like your plan for this case. Thank you, Nicholas signature.asc Description: PGP signature
Bug#976113: Bug#954823: Sponsorship of hydrogen
Hi Ross, Ross Gammon writes: > I have spent some time going through the commit messages. There has > been a lot of work done! Yes :-) If I remember correctly, cdbs -> dh, and upstream churn between prereleases was the worst of it. >> Will you be sponsoring from git or mentors? How would you like me to >> work during the WIP cycles of the review? The git history will look a >> bit silly and confusing with too many "refinalise for release to >> unstable" commits ;-) > > I can do either. But I think in this case, I would prefer to work from > mentors (mainly because I have problems with my gbp setup on this > computer). But please also keep the git repository in sync (even if it > is on a different branch that we can merge later). > Will do! The WIP branch is called "rfs-976113-rebase" and I pushed it just now; it doesn't contain much yet. I will update mentors as soon as we have an upload candidate (still too many outstanding big issues at this time). > Actually, I would like to compliment you on your commit messages. It was > pleasing to see a verbose reason for the change, instead of some short > cryptic message that just generates more questions. > Thank you you, I appreciate that you noticed! It really helps with making sense of work from months ago that I've now forgotten the details and reasoning. And for other team members, of course. 'wish all new contributors were mentored to value this ;-) (I was) >> On #debian-multimedia, Sebastinas did a preliminary review, and two big >> issues were: >> >> 1. override_dh_auto_build had a typo! "override_override_dh_auto_build" >>* I've fixed this locally >> 2. I was missing an override_dh_auto_configure to make use of >>$DEB_CMAKE_EXTRA_FLAGS >>* I believe that is why the extra lib and dev packages became >> necessary. Now that I know what was causing the problem I can >> restore something closer to the old packaging. >>* Changing this in the future will require another trip through NEW, >> so what do you think the correct split of the package is? > > I was wondering why the library packages suddenly appeared. I think if > it is possible, it is best to stick to the old packages. What > applications would want to use hydrogen as a library? > Hypothetical 3rd party plugins, I think? Unfortunately even with -DWANT_SHARED=OFF we still end up with libhydrogen-core-1.0.1.a, which appears to have not been installed in the 0.9.7 series of Debian packages. I can whitelist and ignore it, but for comparison to other distributions, OpenSUSE chose to ship the lib: https://software.opensuse.org/package/libhydrogen-core0 (for 0.9.7) https://software.opensuse.org/package/libhydrogen-core1 (for 1.0.1) Also, I'm also not sure if there is any practical benefit to hydrogen-dev (hypothetical plugin development), so I'm wondering if the headers should not be installed; they weren't installed in the last release (0.9.7-6). Hydrogen-dev_1.0.1-1_all.deb is only 84KB, so could be merged into libhydrogen-core-1.0.1. Sebastinas says the -dev package is arch-specific, and if that's the case it seems like merging the -dev package into bin:libhydrogen-core-1.0.1 would be reasonable. There is something to be said the principle of least surprise when moving between distributions, but I don't have a position on way or the other. At this time we can also reassess the hydrogen and hydrogen-data split. If I was packaging Hydrogen from scratch I'm not sure that I would split them... Finally, if we maintain the split, what is your position on .desktop and appdata files? Should they go in bin:hydrogen-data, or in bin:hydrogen? >> I have not yet reopened any bugs. The list of -rm bugs is: >> 945042 642014 629105 870395 794042 586087 874907 347279 945042 >> [snip] > > I think the best thing is to reopen the bug and then close them in the > changelog once it is confirmed that they are closed. That way they are > closed with the right version information. The most important thing is > to ensure that bugs that are not fixed in the new version remain open. > I've reopened this list of bugs. > Let me know when the new version is available on mentors. > Will do! I'd just want to take care of the major design decisions first. Cheers, Nicholas signature.asc Description: PGP signature
Bug#977011: RFS: ircd-irc2/2.11.2p3~dfsg-5.1 [NMU] [RC] -- The original IRC server daemon
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "ircd-irc2": * Package name: ircd-irc2 Version : 2.11.2p3~dfsg-5.1 Upstream Author : Jarkko Oikarinen and University of Oulu, Computing Center * URL : http://www.irc.org/ * License : GPL-1+ * Vcs : https://anonscm.debian.org/viewvc/collab-maint/deb-maint/ircd-irc2/ Section : net It builds those binary packages: ircd-irc2 - The original IRC server daemon To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ircd-irc2/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/ircd-irc2/ircd-irc2_2.11.2p3~dfsg-5.1.dsc Changes since the last upload: ircd-irc2 (2.11.2p3~dfsg-5.1) unstable; urgency=medium . * Non-maintainer upload. * Drop unnecessary dh-systemd build-dep, because debhelper (>= 9.20160709) already provides this (Closes: #958604). * ircd-irc2.lintian-overrides: "package-contains-upstream-install-documentation" no longer exists, so use its replacement "package-contains-upstream-installation-documentation". Regards, Nicholas
Bug#976828: RFS: python-moreorless/0.3.0-1 [ITP] -- Python difflib with simpler arguments, and enhanced "No newline at EOF" support
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-moreorless": * Package name: python-moreorless Version : 0.3.0-1 Upstream Author : Tim Hatch * URL : https://github.com/thatch/moreorless * License : Expat * Vcs : https://salsa.debian.org/sten/python-moreorless which will be moved to the Python Team after upload: https://salsa.debian.org/python-team/packages/python-moreorless Section : python It builds those binary packages: python3-moreorless - Python difflib with simpler arguments, and enhanced "No newline at EOF" support To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-moreorless/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-moreorless/python-moreorless_0.3.0-1.dsc Changes for the initial release: python-moreorless (0.3.0-1) unstable; urgency=medium . * Initial release (Closes: #973266) Regards, -- Nicholas D Steeves
Bug#976113: RFS: hydrogen/1.0.1-1 [ITP, reintroduce to Debian] -- advanced drum machine/step sequencer
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "hydrogen": * Package name: hydrogen Version : 1.0.1-1 Upstream Author : Sebastian Moors * URL : http://www.hydrogen-music.org/ * License : BSD-3-clause, Apache-2.0, ISC, BSD-2-clause, GPL-2+ * Vcs : https://salsa.debian.org/multimedia-team/hydrogen Section : sound It builds those binary packages: libhydrogen-core-1.0.1 - advanced drum machine/step sequencer (lib) hydrogen-doc - advanced drum machine/step sequencer (doc) hydrogen-dev - advanced drum machine/step sequencer (dev) hydrogen-data - advanced drum machine/step sequencer (data) hydrogen - advanced drum machine/step sequencer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hydrogen/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hydrogen/hydrogen_1.0.1-1.dsc Changes since the last upload: hydrogen (1.0.1-1) unstable; urgency=medium . [ Ondřej Nový ] * d/changelog: Remove trailing whitespaces * d/control: Set Vcs-* to salsa.debian.org . [ Filipe Sateler] * Change maintainer address to debian-multime...@lists.debian.org . [ Olivier Humbert ] * Update d/changelog: deleting unnecessary empty lines * Update d/control: - add Pulseaudio to the description - debhelper: declare version * Update d/hydrogen.install (install a better image) . [ Nicholas D Steeves ] * Reintroduce hydrogen to Debian. (Closes: #960539) * New upstream version 1.0.0~beta2. * Rebase all patches onto 1.0.0~beta2: - Drop 020170916~27d664c.patch (possibly resurrect). - Drop 1000_portaudio_v2.patch (no longer needed). - Drop 1001_rubberband_path.patch (merged upstream). - Drop 1002_fix_locale_coverage.patch (exists upstream @L42). - Drop 1005_name_shouldnt_repeat_genericname.patch (merged upstream). - Drop 1006_porttime.patch (merged upstream). - Drop 1008-ftbfs-gcc-4.7.diff (no longer needed). - Drop 1010-spelling.patch (no longer needed). - Drop 1015-man_path.patch (no longer needed). - Drop 1020-cxx_flags.patch (no longer needed). * Fix typos in description, enhance grammar, and refer to Qt as "Qt" rather than "QT". Thanks to Thomas Vincent for finding this while working on a translation. (Closes: #945042) * Update filenamemangle, uversionmangle, and version match to allow uscan to detect alpha, beta, and rc versions. We're now tracking beta Qt5 releases, because Qt4 is unmaintained and was removed from Debian. * Built against qtbase5-dev instead of libqt4-dev. (Closes: #954823) * Add the following new build-deps: libqt5xmlpatterns5-dev, qttools5-dev. * Add myself to Uploaders. * Comment-out the actions in the debian/docs.stamp rules target because docs are absent from this beta2 release. * Add qttools5-dev-tools to build-deps, because we need Qt5 lupdate to regenerate translations. * rules: export QTDIR=/usr/lib/qt5. * Add libcppunit-dev to build-deps; this will activate unit tests. * Add liblo-dev to build-deps; this enables Open Sound Control (OSC). * Add 1001-patch-stats.py-with-Python-2to3.patch. * Drop Jaromír Mikeš from Uploaders, because he has not been active in Debian for > 2 years, and because he communicated that he is no longer working on this package (see Bug #954823, Message #15). * Drop Jonas Smedegaard from Uploaders on his request (see Bug #954823, Message #37). * Migrate the package from cdbs to debhelper: - Switch to debhelper-compat 13. - Drop debian/control.in. - Drop cdbs build-dep. - Convert existing rules file into dh sequence compatible format, and drop the license boilerplate, because this is declared in Files:debian/* of copyright. - Install man page with debian/hydrogen.manpages. - Drop README.source, which existed to declare that this was a cdbs-using package. * Update hydrogen-data.install for new upstream locations of appdata.xml. * Update hydrogen-data.install and hydrogen-data.links for new upstream location of h2-icon.svg. * hydrogen.install: Drop icon installation, because it exists in hydrogen-data. * Create libhydrogen-core-1.0.0 package for libhydrogen-core-1.0.0.so. * Create a hydrogen-dev package for the headers. * rules and hydrogen-doc.install: Disable doc generation and installation, because docs appear to be absent from this beta2 release. * rules: export DEB_CMAKE_EXTRA_FLAGS * copyright: - Fix inaccurate date range for "The hydrogen development team". - Update Sebastian Moors' years. - Update Jérémy Zurcher's years. - Add missing section for cmake/S
Bug#975901: RFS: scala-mode-el/1:1.1.0-1 [ITA] -- Emacs major mode for editing scala source code (reintroduce to Debian)
Package: sponsorship-requests Severity: normal Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "scala-mode-el": * Package name: scala-mode-el Version : 1:1.1.0-1 Upstream Author : Heikki Vesalainen * URL : https://github.com/hvesalai/emacs-scala-mode * License : GPL-3+, SCALA-LICENSE * Vcs : https://salsa.debian.org/emacsen-team/emacs-scala-mode Section : editors It builds those binary packages: scala-mode-el - transitional dummy package, scala-mode-el to elpa-scala-mode elpa-scala-mode - Emacs major mode for editing scala source code To access further information about this package, please visit the following URL: https://mentors.debian.net/package/scala-mode-el/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/scala-mode-el/scala-mode-el_1.1.0-1.dsc Changes since the last upload: scala-mode-el (1:1.1.0-1) unstable; urgency=medium . [ Sławomir Wójcik ] * Adopt package; this package is now maintained by the Debian Emacsen team. (Closes: #766441) * control: updated binary name to elpa-scala-mode, repositories addresses, maintainer/uploaders, standards version, long description and dependencies * Updated rules to use dh_elpa, added necessary elpa and elpa-test files * Added watch file * Updated docs file * Added source format * Added NEWS file * Removed emacsen-install, emacsen-remove and emacsen-startup files which were no longer necessary due to migration to dh_elpa . [ Sławomir Wójcik and Nicholas D Steeves] * New upstream version 1.1.0. * Migrate to debhelper-compat 13. * Update copyright file to reflect new upstream source, and migrate to a machine-readable copyright file. * Add gbp.conf. * Declare Standards-Version 4.5.1. . [ Nicholas D Steeves ] * Add Breaks, Replaces, and Provides to elpa-scala-mode to ensure smooth upgrades. * Add epoch to version, so that apt will upgrade existing users from 20111005-2.1 to 1.1.0-1. * Declare Rules-Requires-Root: no. * Declare dummy transitional package scala-mode-el as Section: oldlibs so that deborphan will suggest its removal. * elpa-test: Fix autopkgtests by setting autopkgtest_keep, thus retaining the files that contain scala-mode's tests. * Add myself to Uploaders. Regards, Nicholas
Bug#973902: RFS: btrfs-progs/5.9-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities
Hi Gianfranco, Thank you for sponsoring! Gianfranco Costamagna writes: > Hello > Sponsored after adding > * Drop hardcoded dep on modern libgcc-s1, and breaks old initramfs-tools, > because these are not applicable to the backport. > > to changelog... > G. > I don't understand why adding this line was required, because I'm using best-practises for backports (merged changelog), and merging tag from testing, rather than forking for each release, and I'm generating the .changes file relative to the last upload to buster-backports (which is why this entry didn't appear the 5.9-1~bpo10+1 entry). Full changelog for buster-backports shows: btrfs-progs (5.9-1~bpo10+1) buster-backports; urgency=medium * Rebuild for buster-backports. -- Nicholas D Steeves Thu, 05 Nov 2020 16:18:31 -0500 btrfs-progs (5.9-1) unstable; urgency=medium * New upstream release. -- Adam Borowski Fri, 23 Oct 2020 21:22:35 +0200 btrfs-progs (5.7-1~bpo10+1) buster-backports; urgency=medium * Rebuild for buster-backports. * Drop hardcoded dep on modern libgcc-s1, and breaks old initramfs-tools, because these are not applicable to the backport. -- Nicholas D Steeves Tue, 28 Jul 2020 20:31:55 -0400 btrfs-progs (5.7-1) unstable; urgency=medium Regards, Nicholas signature.asc Description: PGP signature
Bug#973902: RFS: btrfs-progs/5.9-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my continuing backports of "btrfs-progs": * Package name: btrfs-progs Version : 5.9-1~bpo10+1 Upstream Author : linux-bt...@vger.kernel.org * URL : http://btrfs.wiki.kernel.org/ * License : GPL-2, TLP-4 * Vcs : https://salsa.debian.org/debian/btrfs-progs/tree/debian Section : admin It builds those binary packages: btrfs-progs - Checksumming Copy on Write Filesystem utilities libbtrfs0 - Checksumming Copy on Write Filesystem utilities (runtime library) libbtrfs-dev - Checksumming Copy on Write Filesystem utilities (development headers) libbtrfsutil1 - Checksumming Copy on Write Filesystem utilities (runtime util library) libbtrfsutil-dev - Checksumming Copy on Write Filesystem utilities (util development headers) python3-btrfsutil - Checksumming Copy on Write Filesystem utilities (python3 bindings) btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/btrfs-progs/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_5.9-1~bpo10+1.dsc Changes since the last upload: btrfs-progs (5.9-1~bpo10+1) buster-backports; urgency=medium . * Rebuild for buster-backports. . btrfs-progs (5.9-1) unstable; urgency=medium . * New upstream release. Regards, Nicholas
Bug#973901: RFS: vorta/0.7.1-1 [ITP] -- Desktop Client for Borg Backup
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "vorta", a user-friendly desktop client for Borg Backup. Three systems I support are already using this package to remind the user to do a backup, and to do it. Two are using a NAS, one is using a USB drive. It works great.: * Package name: vorta Version : 0.7.1-1 Upstream Author : Manuel Riel * URL : https://vorta.borgbase.com * License : GPL-3+, CC0-1.0 * Vcs : https://salsa.debian.org/debian/vorta Section : utils It builds those binary packages: vorta - Desktop Client for Borg Backup To access further information about this package, please visit the following URL: https://mentors.debian.net/package/vorta/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/v/vorta/vorta_0.7.1-1.dsc Changes for the initial release: vorta (0.7.1-1) unstable; urgency=medium . * Initial release (Closes: #922961). Regards, Nicholas
Bug#962294: marked as done (RFS: btrfs-progs/5.7-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities)
"Debian Bug Tracking System" writes: > Your message dated Wed, 21 Oct 2020 14:20:47 +0200 > with message-id <4ce39769-f1c3-68ad-3965-688d1f6c0...@debian.org> > and subject line Re: Bug#962294: RFS: btrfs-progs/5.7-1~bpo10+1 -- > Checksumming Copy on Write Filesystem utilities > has caused the Debian Bug report #962294, > regarding RFS: btrfs-progs/5.7-1~bpo10+1 -- Checksumming Copy on Write > Filesystem utilities > to be marked as done. > Thank you Gianfranco, much appreciated! A number of our users on upstream linux-btrfs have been recommended Fedora live media as the easiest way to get a recent version of 'btrfs check' (fsck equivalent for fs structures and metadata), so it's good to have an in-house solution again. Best, Nicholas signature.asc Description: PGP signature
Bug#971677: closed by Louis-Philippe Véronneau (sponsored fissix)
"Debian Bug Tracking System" writes: > 971677: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971677 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > From: Louis-Philippe Véronneau > Subject: sponsored fissix > To: 971677-d...@bugs.debian.org > Date: Sun, 11 Oct 2020 19:03:35 -0400 > > This package has been uploaded to NEW. > Thanks again Louis-Philippe! -- Nicholas
Bug#971634: RFS: btrfsmaintenance/0.5-1 -- automate btrfs maintenance tasks on mountpoints or directories
Sven Hoexter writes: > Hi Nicholas, > uploaded the package. > > Sven Thank you Sven, much appreciated! Nicholas signature.asc Description: PGP signature
Bug#971679: RFS: vorta/0.7.1-1 [ITP] -- Desktop Client for Borg Backup
Package: sponsorship-requests Severity: wishlist Control: block 922961 by -1 Dear mentors, I am looking for a sponsor for my package "vorta", a user-friendly desktop client for Borg Backup. Three systems I support are already using this package to remind the user to do a backup, and to do it. Two are using a NAS, one is using a USB drive. It works great. * Package name: vorta Version : 0.7.1-1 Upstream Author : Manuel Riel * URL : https://vorta.borgbase.com * License : GPL-3+, CC0-1.0 * Vcs : https://salsa.debian.org/debian/vorta Section : utils It builds those binary packages: vorta - Desktop Client for Borg Backup To access further information about this package, please visit the following URL: https://mentors.debian.net/package/vorta/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/v/vorta/vorta_0.7.1-1.dsc Changes for the initial release: vorta (0.7.1-1) unstable; urgency=medium . * Initial release (Closes: #922961). Regards, -- Nicholas D Steeves
Bug#971677: RFS: fissix/20.8.0-1 [ITP] -- backport of lib2to3 that supports the latest Python3 grammars
Package: sponsorship-requests Severity: wishlist Control: block 944989 by -1 Dear mentors, I am looking for a sponsor for my package "fissix". Fissix is a dependency of Bowler, "a refactoring tool for manipulating Python at the syntax tree level" ( https://github.com/facebookincubator/bowler ). * Package name: fissix Version : 20.8.0-1 Upstream Author : John Reese * URL : https://github.com/jreese/fissix * License : PSF-2 * Vcs : https://salsa.debian.org/python-team/packages/fissix Section : python It builds those binary packages: python3-fissix - backport of lib2to3 that supports the latest Python3 grammars To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fissix/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fissix/fissix_20.8.0-1.dsc Changes for the initial release: fissix (20.8.0-1) unstable; urgency=medium . * Initial release (Closes: #944989) Regards, -- Nicholas D Steeves
Bug#971634: RFS: btrfsmaintenance/0.5-1 -- automate btrfs maintenance tasks on mountpoints or directories
Package: sponsorship-requests Severity: normal Dear mentors and Sven, I am looking for a sponsor for my package "btrfsmaintenance": * Package name: btrfsmaintenance Version : 0.5-1 Upstream Author : David Sterba * URL : https://github.com/kdave/btrfsmaintenance * License : GPL-2 * Vcs : https://salsa.debian.org/sten-guest/btrfsmaintenance Section : admin It builds those binary packages: btrfsmaintenance - automate btrfs maintenance tasks on mountpoints or directories To access further information about this package, please visit the following URL: https://mentors.debian.net/package/btrfsmaintenance/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/btrfsmaintenance/btrfsmaintenance_0.5-1.dsc Changes since the last upload: btrfsmaintenance (0.5-1) unstable; urgency=medium . * New upstream release. (Closes: #970732) - /etc/default/btrfsmaintenance now optionally supports more granular systemd time and date specification. - balance, scrub, and trim are finally serialised as mutually exclusive operations. - Default filters for btrfs balance are now "5 10" for data (from "1 5 10 20 30 40 50"), and "5" for metadata (from "1 5 10 20 30"); this means that less data is rewritten, and that less free space is recovered; this change mitigates some of the longstanding negative effects on system responsiveness during a balance operation because the work completes more quickly. * Drop leading white space from NEWS.Debian, and rename the file as "NEWS". * README.Debian: Note that btrfsmaintenance is not yet aware of a system's power state (on AC, battery, UPS), plus minor edits for polish. * README.Debian: Add Qu Wenruo's position against balancing, with citation. * Switch to debhelper-compat 13. * Override dh_installdeb to add missing executable bit to BASH scripts. * Set Rules-Requires-Root: no. * Add 0002-Add-doc-key-to-btrfsmaintenance-refresh.service.patch to address lintian complaint systemd-service-file-missing-documentation-key. * Update description to address new blk-mq default scheduler. (Closes: #970731) * Declare Standards-Version: 4.5.0. (No additional changes needed) Regards, -- Nicholas D Steeves
Bug#964164: Bug#947017: Bug#964164: RFS: org-drill/2.7.0-1 [ITP] -- spaced repetition drills in Emacs for accelerated study/learning
Hi Thomas, Thank you for taking a look at this. Thomas Koch writes: > Thank you Nicholas for the reminder and sorry for keeping you waiting. > > Unfortunately, I don't believe the package would pass the NEW queue in its > current state. You did remove the apple.jpg file but you added a new > apple.png file that is not mentioned in debian/copyright. > > I know how annoying these copyright issues are! > Which package are you looking at? I have insufficient permissions to rewrite history or delete the org-drill repo Emacsen Team project, thus insufficient permissions to clean the git repo. Going from the provided source package: https://mentors.debian.net/debian/pool/main/o/org-drill/org-drill_2.7.0+dfsg-1.dsc Copyright and source of apple.png is documented, and the license is CC0, which does not require specific documentation or attribution in copyright. CC0 Allows implicit relicensing, thus the debian/* rule in copyright applies GPL-3+ to debian/patches/0001-add-a-more-freely-licenced-image-of-an-apple.patch So the package is license-compliant. When upstream merges the PR the new apple.png will fall under the upstream "Files: *" GPL-3+ rule. At that time the package will also be license-compliant. I admit that documentation of this file's CC0 would be nice to have, to highlight the fact that one is free to do more with that file than the GPL-3+ permits, but this is not a license-compliance issue. > I think the easiest would be to just remove the file and its references > without any replacement. You might then help upstream with a pull request to > provide a dfsg free picture for the next version. > I filed such a PR the 28th of July. Please see the Forwarded header of that patch. > The following remarks are maybe not strictly required: > > Even if you add a new file, you should not use debian/patches to add it but > just include it in the debian tarball. I actually never had to do this > myself, so I have no experience with adding a binary file. > I chose to use a cherry picked patch from the PR I filed because then everything is documented in two places (the patch and the PR), and so that the patch can be automatically dropped in a future release (prioritises human time). I'm familiar with the alternative, which would additionally require additional documentation in README.source. > Please also add a version number to dfsg suffix like dfsg1 or dfsg-1. It > happened to me before that I needed multiple uploads to the new queue before > I found all non dfsg-unfree files: https://tracker.debian.org/pkg/nix > > Especially the version number of the orig tarball is different from the > changelog. I wonder how this worked in the first place. > Ah, you're looking at the non-dfsg git repo... > If you want to reflect the dfsg cleaning work also in your git packaging > branch, I started a knowledge base article here: > https://wiki.debian.org/kb/git_packaging_dfsg_clean_branch > An example of this: https://salsa.debian.org/debian/nix > > My nix package also contains a debian/watch example to produce a dfsg clean > orig tarball. > > The git packaging repo does not contain the latest commits apparently, there > is no debian/patches folder: > https://salsa.debian.org/emacsen-team/org-drill/-/tree/master/debian > Yes, that project should be deleted. The plan is to use a gbp-style repo that leverages uscan's Files-Excluded. > Thank you very much for your contribution and especially for your patience! You're welcome! Nicholas signature.asc Description: PGP signature
Bug#964164: RFS: org-drill/2.7.0-1 [ITP] -- spaced repetition drills in Emacs for accelerated study/learning
Hi Thomas, Nicholas D Steeves writes: > DFSG-compliant orig.tarball has been created and an updated package > has been uploaded to mentors If you have a moment, would you please sponsor this fulfilment of your RFS (please set yourself as owner of the bug if so, because I've also requested sponsorship on IRC)? Thanks, Nicholas signature.asc Description: PGP signature
Re: Bug#962294: RFS: btrfs-progs/5.7-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities
Control: retitle -1 RFS: btrfs-progs/5.7-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities Dear mentors, I am looking for a sponsor for my package "btrfs-progs": * Package name: btrfs-progs Version : 5.7-1~bpo10+1 Upstream Author : linux-bt...@vger.kernel.org * URL : http://btrfs.wiki.kernel.org/ * License : TLP-4, GPL-2 * Vcs : https://salsa.debian.org/debian/btrfs-progs/tree/debian Section : admin It builds those binary packages: btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb) python3-btrfsutil - Checksumming Copy on Write Filesystem utilities (python3 bindings) libbtrfsutil-dev - Checksumming Copy on Write Filesystem utilities (util development headers) libbtrfsutil1 - Checksumming Copy on Write Filesystem utilities (runtime util library) libbtrfs-dev - Checksumming Copy on Write Filesystem utilities (development headers) libbtrfs0 - Checksumming Copy on Write Filesystem utilities (runtime library) btrfs-progs - Checksumming Copy on Write Filesystem utilities To access further information about this package, please visit the following URL: https://mentors.debian.net/package/btrfs-progs/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_5.7-1~bpo10+1.dsc Changes since the last upload: btrfs-progs (5.7-1~bpo10+1) buster-backports; urgency=medium . * Rebuild for buster-backports. * Drop hardcoded dep on modern libgcc-s1, and breaks old initramfs-tools, because these are not applicable to the backport. . btrfs-progs (5.7-1) unstable; urgency=medium . * New upstream release. * Hardcode dependency on modern libgcc-s1 + breaks: old initramfs-tools, to avoid extra moving parts. * Don't declare initramfs trigger ourselves (done by dh_installinitramfs). . btrfs-progs (5.6-1~bpo10+1) buster-backports; urgency=medium . * Rebuild for buster-backports. . btrfs-progs (5.6-1) unstable; urgency=medium . * New upstream release. * Versioned symbols. * Slightly improve long descs. * Drop old -dbgsym migration. * Don't skip scan if modprobe fails (eg. due to built-in). Closes: #956174. . btrfs-progs (5.4.1-2) unstable; urgency=medium . * Declare Breaks: on versions of libgcc-s1 that produce bad initramfs. Closes: #950556. . btrfs-progs (5.4.1-1) unstable; urgency=medium . * New upstream release. . btrfs-progs (5.4-1) unstable; urgency=medium . * New upstream release. . btrfs-progs (5.3.1-1) unstable; urgency=medium . * New upstream point release. * Update symbols -- they're versioned upstream now. . btrfs-progs (5.3-1) unstable; urgency=medium . * New upstream release. * Fix FTBFS with new asciidoctor. * Update symbols. Regards, Nicholas signature.asc Description: PGP signature
Re: How to submit patches?
Hi, Emmanuel Arias writes: > Hi Martin, > > When I submit a patch, first I prepare a NMU patch, then submit that patch > to bts. If the bug does not exist I create it and attach the patch. > Please don't prepare NMUs unless you're planning to upload an NMU, and please don't submit NMUdiffs unless an NMU is justified. NMUs are an aggressive action that carries the following connotations: 1) the maintainer has been unresponsive for what would be considered a reasonable amount of time for the severity of a bug 2) the maintainer is poorly maintaining the package 3) the maintainer might be poorly maintaining other packages. So yeah, negative...some people feel insulted and/or attacked by such an action. See also: https://wiki.debian.org/NonMaintainerUpload Of course, this is not the case when the maintainer has set themselves as lowNMU ;-) Instead, increment the Debian revision. 1-1 becomes 1-2 for non-native; 1 becomes 1.1 for native if a decimal point was used, otherwise it might be more conventional to just increment to 2. I'm not sure because the only native package I've worked on uses decimals. Leave the distro as 'UNRELEASED'. I also like to use the [ My Name ] * Do not write "Non Maintainer upload here". * Item 1. * Item 2. * etc. format, to save the maintainer time in case they haven't enabled DEBCHANGE_MULTIMAINT=yes in devscripts.conf--otherwise, if they don't manually add your name you'll disappear from the changelog entry. > But I would wait for a more experienced opinion :) > Another option is to fork the salsa repo, file an MR, and post the MR URL to the bug (the info in the previous section also applies here). IMHO it's worth setting the patch flag with the "Control: tag -1 +patch" pseudoheader for both debdiffs/git-format-patches and MRs. I hope this email doesn't come across as harsh...my concern is that the response to NMUs is usually negaive, and the social outcome can be that everyone involved becomes demotivated. To all new contributors reading this: please don't mention NMUs in the bug, nor intend to upload NMUs, nor use NMU version numbers, unless an NMU is justified. Oh, and to be fair, I also used to think that NMUs were ok as something like "democratic contributions for the good of Debian"; however, I was wrong. Patches are OK, premature NMUs are not. And why not mention that you're willing to do an NMU early on? Well, strictly speaking, this is permitted, eg: "if you're busy, I'd be happy to NMU, but I'd rather not", but the effect of this is that it puts pressure on the maintainer to take action, to avoid the stigma of an NMU. If the case doesn't merit this, it's simply not nice :-) Have fun! Nicholas signature.asc Description: PGP signature
Re: What is reasonable for debian/NEWS?
Hi Andreas, Andreas Ronnquist writes: > I have a package (the cd audio ripper asunder) that has been using > freedb.org for getting CDDB information, which has closed it's service > - and is replacing it with gnudb.org which provide the same service. > > I am about to upload a new version to unstable where I patch this since > a new upstream version hasn't been released yet - but this change of > course only changes the default setting, any user will need to change > their individual setting too. > > Is this reasonable to mention in debian/NEWS? (I just learned that it > shouldn't be NEWS.Debian, but only NEWS)... > What justifies a NEWS.Debian is the fact that users' existing configuration if broken by the obsolescence/non-existence of freedb.org. If upstream introduced a incompatible config key change in a new version that would break users' existing config then this would also justify a NEWS.Debian. Changes that do not require user action should never interrupt an upgrade. Maxim: do not nag users unnecessarily. Cheers, Nicholas signature.asc Description: PGP signature
Bug#964164: RFS: org-drill/2.7.0-1 [ITP] -- spaced repetition drills in Emacs for accelerated study/learning
DFSG-compliant orig.tarball has been created and an updated package has been uploaded to mentors signature.asc Description: PGP signature
Re: package one package from a git repo with multiple packages
Hi Ali, Ali Mezgani writes: > Hello, > > What is the issue, if you need a new contributor I should do. What are > blocking phases? > Sorry, I missed your email and don't understand what you mean. Do you mean you'd like to package the "New Session Manager" fork (fltk port)? Thanks, Nicholas signature.asc Description: PGP signature
Re: package one package from a git repo with multiple packages
Hi, "rosea.grammostola" writes: > To be more precise: non-session-manager is forked. That fork > (new-session-manager) can be build without NTK. > > Non-Daw with non-sequencer/non-timeline/non-mixer isn't forked and still > needs the NTK toolkit (fork of fltk). > Hmm, maybe I should prioritise packaging non-session-manager in the hopes of warming upstream's heart[s] with what a great downstream we are? ...then ask nicely for a port of non-timeline and mixer ;-) Cheers, Nicholas signature.asc Description: PGP signature
Re: package one package from a git repo with multiple packages
Hi Rosea, "rosea.grammostola" writes: > Project has been forked, I've no interest in packaging it, but it should > be easier now with plain FLTK instead of NTK > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965068 > Thank you for the link. Yes, and with meson replacing the waf evil :-) I took a quick stab at preliminary packaging and was successful, so I'll think about whether I have enough energy for a copyright review and claim the RFP if I decide yes. Regards, Nicholas signature.asc Description: PGP signature
Bug#964164: (no subject)
Control: forwarded https://bitbucket.org/eeeickythump/org-drill/issues/69/applejpg-is-not-freely-redistributable I asked a team member to sponsor, he asked me if I had attempted to track down the source and license for apple.jpg. Upon investigation, I found this is the source http://clipart-library.com/clipart/8TGbezg7c.htm , License: Personal Use, thus violating §6 of DFSG "No discrimination against fields of endeavor". signature.asc Description: PGP signature
Re: package one package from a git repo with multiple packages
Hi Rosea, Sorry for the long delay in replying. I lost the thread and it took me this long to think "say, I wonder what happened with that new contributor who wants to work on NON?" "rosea.grammostola" writes: > Nicholas and others, > > Ha, I didn't solve anything man. I'm probably the most unclassified > person for the job. But hey, if no one wants to do it, you've to do it > yourself isn't it? Which I can't so that's why I'm asking these 'stupid' > newbie questions on this list. Sure there are all kind of obstacles, but > I can't accept that these can't be tackled. > For the record I didn't think any of your questions were stupid. I also commend your attitude :-) By the way, have you made any progress with this package? > Arch Linux, Fedora, Kxstudio etc etc has the NON packages, but Debian > not... yeah! :) > Agreed, we really ought to, especially since we're one of the only distributions that still support i386, where a lightweight DAW like NON might be the only one that performs adequately. Of course, it will also be really useful for low-powered ARM devices after i386 is retired. > Ok back to business. Because no one else was taking up this package, I > came up with this plan, which might make it possible for me (with the > help of others) to get NSM packaged for Debian. > > 1) package only Non-Session-Manager (NSM) first > > 2) package it without dependency on NTK, but on FLTK only > > 3) See if you can get Non-Daw with NTK later in Debian. > > All this is only possible if I can get people help me. So I decided to > just write a e-mail to debian-mentor and see what happens. > Please ask questions, or ask for comments on your plan of action (put "RFC" in front of the subject heading to notify people of this). The approach "if I can get people to help me" isn't likely to go anywhere, because it's almost always faster to do the work oneself then to review someone else's work, and it takes even more time to come up with a plan from scratch and explain "this is what I'd do, in this order, and this is why (for each step)". Please ask questions, especially if you're stumped :-) If this a case of not knowing where to start, that wouldn't be a stupid question either! Because everyone has to start somewhere... Cheers, Nicholas P.S. Please reply "inline" aka: "interleaved" https://en.wikipedia.org/wiki/Posting_style#Interleaved_style P.P.S. I CCed you because it's been so long since the last post to this thread. signature.asc Description: PGP signature
Bug#964492: RFS: emacs-wgrep/2.3.2+9.gf0ef9bf-1 [ITP] -- edit multiple Emacs buffers using a master grep pattern buffer
Package: sponsorship-requests Severity: normal Justification: blocks importing the latest upstream release of Ivy Control: block 944986 by -1 Dear mentors, I am looking for a sponsor for my package "emacs-wgrep" * Package name: emacs-wgrep Version : 2.3.2+9.gf0ef9bf-1 Upstream Author : Masahiro Hayashi * URL : https://github.com/mhayashi1120/Emacs-wgrep * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-wgrep Section : editors It builds these binary packages: elpa-wgrep - edit multiple Emacs buffers using a master grep pattern buffer elpa-wgrep-ack - edit multiple Emacs buffers using a master ack pattern buffer elpa-wgrep-ag - edit multiple Emacs buffers using a master ag pattern buffer elpa-wgrep-helm - edit multiple Emacs buffers with a helm-grep-mode buffer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-wgrep Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-wgrep/emacs-wgrep_2.3.2+9.gf0ef9bf-1.dsc For the option to sponsor from git, use: https://salsa.debian.org/emacsen-team/emacs-wgrep and git deborig Changes since the last upload: * Initial release. (Closes: #944986) Regards, Nicholas
Bug#964164: RFS: org-drill/2.7.0-1 [ITP] -- spaced repetition drills in Emacs for accelerated study/learning
Package: sponsorship-requests Severity: normal Dear mentors, Thomas, and Sébastien, I am looking for a sponsor for my package "org-drill". Please set yourself as owner of this bug or reply to it when uploading to prevent duplicate work. Package name: org-drill Version : 2.7.0-1 Upstream Author : Phillip Lord URL : https://gitlab.com/phillord/org-drill License : GPL-3+ Vcs : https://salsa.debian.org/emacsen-team/org-drill Section : education It builds this binary package: elpa-org-drill - spaced repetition drills in Emacs for accelerated study/learning To access further information about this package, please visit the following URL: https://mentors.debian.net/package/org-drill Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/org-drill/org-drill_2.7.0-1.dsc Changes since the last upload: * Initial release (Closes: #947017). Regards, Nicholas D Steeves
Bug#962294: RFS: btrfs-progs/5.6-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "btrfs-progs" * Package name: btrfs-progs Version : 5.6-1~bpo10+1 Upstream Author : linux-bt...@vger.kernel.org * URL : http://btrfs.wiki.kernel.org/ * License : GPL-2 * Vcs : https://salsa.debian.org/debian/btrfs-progs/tree/debian Section : admin It builds these binary packages: btrfs-progs - Checksumming Copy on Write Filesystem utilities libbtrfs0 - Checksumming Copy on Write Filesystem utilities (runtime library) libbtrfs-dev - Checksumming Copy on Write Filesystem utilities (development headers) libbtrfsutil1 - Checksumming Copy on Write Filesystem utilities (runtime util library) libbtrfsutil-dev - Checksumming Copy on Write Filesystem utilities (util development headers) python3-btrfsutil - Checksumming Copy on Write Filesystem utilities (python3 bindings) btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/btrfs-progs Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_5.6-1~bpo10+1.dsc Changes since the last upload: * Rebuild for buster-backports. . btrfs-progs (5.6-1) unstable; urgency=medium . * New upstream release. * Versioned symbols. * Slightly improve long descs. * Drop old -dbgsym migration. * Don't skip scan if modprobe fails (eg. due to built-in). Closes: #956174. . btrfs-progs (5.4.1-2) unstable; urgency=medium . * Declare Breaks: on versions of libgcc-s1 that produce bad initramfs. Closes: #950556. . btrfs-progs (5.4.1-1) unstable; urgency=medium . * New upstream release. . btrfs-progs (5.4-1) unstable; urgency=medium . * New upstream release. . btrfs-progs (5.3.1-1) unstable; urgency=medium . * New upstream point release. * Update symbols -- they're versioned upstream now. . btrfs-progs (5.3-1) unstable; urgency=medium . * New upstream release. * Fix FTBFS with new asciidoctor. * Update symbols. Regards, Nicholas
Bug#962242: RFS: vorta/0.6.26+8.gec0f19a-1~exp1 [ITP] -- Desktop Client for Borg Backup
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "vorta" * Package name: vorta Version : 0.6.26+8.gec0f19a-1~exp1 Upstream Author : Manuel Riel * URL : https://vorta.borgbase.com * License : GPL-3+ * Vcs : https://salsa.debian.org/debian/vorta Section : utils It builds this binary package: vorta - Desktop Client for Borg Backup To access further information about this package, please visit the following URL: https://mentors.debian.net/package/vorta Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/v/vorta/vorta_0.6.26+8.gec0f19a-1~exp1.dsc Changes since the last upload: * Initial release (Closes: #922961). --- I've created a git repo at: g...@salsa.debian.org:sten/vorta.git https://salsa.debian.org/sten/vorta and intent to maintain this package in the Debian salsa group, so it would be nice if the sponsor would push my repo there and grant me push access. Regards, Nicholas
Bug#955323: RFS: atomic-chrome-el/2.0.0-1 [ITP] -- edit a web-browser text entry area with Emacs
Hi Antoine! It seems I forgot to push my work on this package from early 2020 :-/ Probably fell asleep...I'm truly sorry for wasting your time in the initial review. Reply follows inline; feel free to skip the rest of this email if you're busy. The package should meet your standards @a69fbc3. OT, I wish the sponsorship template would insert commit:@foo...that would have prevented this, and I think the pkg on mentors was @a69fbc3... Antoine Beaupré writes: > i am not sure, but i suspect it is a mismatch between the > debian/changelog and debian/control package names. indeed, with the > following patch: > [snip] > -atomic-chrome (2.0.0-1) unstable; urgency=medium > +atomic-chrome-el (2.0.0-1) unstable; urgency=medium [snip] > ... the package compiles. > Indeed. Fixed 1 Jan 2020 (many apologies, I forgot to push). > The other issue I found is what now seems to be a recurring disagreement > between us. :) This is the tarball that `uscan` gives me when I run the > above command: > [snip] > There are a few things wrong here: > > 1. we should not needlessly differ from the upstream tarball > Yeah... I did special-case your preference 29 March 2020 (forgot to push). [1a] That said, in addition to what we discussed before, I'm finding that more and more projects release less-than useful tarballs eg: missing tox.ini or other things for self-tests. Fundamentally, the only reason I use a tarball check in the watch file is to reduce the load on the system that runs uscan (daily?). I would move everything over to pure git (with a quilt patch series, if necessary) in a heartbeat if using git in the watch file wouldn't make people grumble. > 2. if we really have to, `uscan` should allow us to reconstruct our > tarball reproducibly, or at least `README.source` should explain > how. at minimum, `README.source` should explain *why* we differ > [2a] I'm still not convinced of the value of this when it's fetchable with 'apt source', 'dgit clone', or 'dget'. That copy is gpg signed via the changes and/or dsc, and benefits from our (Debian) identity verification. Re: README.source, I don't know about this one...Lamby convinced me not to use README.source for this purpose some time ago. I used to always document when I was using a git tag rather than upstream release tarball :-) > 3. even if we insist on using `xz` (and I don't see why we do in this > case), we don't need the maximum compression level. this is a small > package and there's not reason to "crank it up to 11", so to speak :) > [3a] :-) I agree with you that it doesn't have much practical value for a package of this size, but there is a reason: establishing policy. I think it was spwhitton who impressed on me the value that the accumulation of packaging decisions affects trends, consensus, and ultimately Policy. The practical value is that if maintainers are willing to "crank it up to 11" even for little packages, then it's fair to expect the same from maintainers of packages where the diff is large. I'd give up on this with proof that weaker compression resulted in less net electricity consumption (including ongoing storage and transmission) than what is required for compression and decompression of xz. If you know, please share! > The following patch should fix the problem: > > From a9dc9a10a4c1ea9024a70335232dd837d36738d1 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= > Date: Fri, 17 Apr 2020 21:01:14 -0400 > Subject: [PATCH] remove superfluous diff with upstream tarball > Thank you for the patches, I sincerely appreciate that you took time to write them. Once again, sorry for not realising I hadn't pushed... > I feel uncomfortable sponsoring a package if it doesn't use the upstream > tarballs. I hope you'll understand. > Definitely! I've been mentoring some new Emacsen Team members, and wrote up a short hierarchy of priorities. The standards of one's sponsor are #1, unless they contradict Policy. Anyways, it has both conceptual and practical dimensions. Here's a practical one you'll appreciate: tldr (pithy synopsis), don't drain your sponsor with unnecessary arguments or they'll be too drained to review and sponsor your work ;-) If you're interested in reading it and/or if you think such a thing would make a good addition to an existing doc, please let me know! Cheers, Nicholas signature.asc Description: PGP signature
Bug#954050: RFS: persist-el/0.4+dfsg-1 [ITP] -- persist variables between Emacs Sessions
Hi Thomas, Reply follows in-line: Thomas Koch writes: > Hi Nicholas, > > I just uploaded persist-el. Thank you and sorry for the delay. This > was my first sponsorship and I also had to setup a new laptop. I'm > just waiting for the confirmation mail for the upload. > Thank you for sponsoring! Best of luck with the toil of getting the new laptop setup (eg: MUA line wrapping, and weird trailing white-space in lintian output). Did you upload twice btw? [22-04 edit: Oh! Sébastien, thank you!] > There are a few nitpicks and I'd be grateful if you could track them, > e.g. in bugs.d.o after the package enters the archive: > > - It's a pity that we can not include the info file due to the > license. Could you ask upstream to consider another license? Sure thing, I've added it to my TODO. BTW, because it's a GNU ELPA project I'm pessimistic they'll relicense the docs... > - As long as the doc is not included, I think you don't need to build > depend on texinfo. Agreed, I'll either drop it for the -2 upload, or if upstream relicenses their texinfo source then I'll build the info file. > - If upstream also uses Git, I prefer to track upstreams master branch > as upstream branch in the packaging repo. You could still merge their > branch in your existing repo or restart the repo? I also prefer to track upstream's master branch; however, persist.el is part of the GNU ELPA mondo-repo, which contains many other packages, and our team uses one repo per source package. > - Lintian also had two nitpicks, see below. I'm guilty of the "wrong" > section myself for elpa-editorconfig. What is the teams stand on this? > I've discussed similar issues with the team before, and the consensus is that it's not worth the trouble of a section change. Having filed a couple of section change requests in the past, an ftpmaster sometimes moved them to weird/generic sections...eg: I requested a move for Elpy (Python IDE) to Development from either Lisp or Editors, and they moved it to Text... Dh-make-elpa also used to use section "lisp" but now uses section "editors", and this is also a case where where "editors" seems to be team-endorsed (via dh-make-elpa), and I think the team consensus is that lintian's claim is wrong. IIRC the "info" severity is a compromise between our team and whoever believes all packages that are implemented in lisp should be in section lisp... When it was a warning I filed a bunch of section change requests (editors-to->lisp) that ftpmasters didn't seem to appreciate. That said, upon further consideration I agree that "lisp" might have been the most appropriate section, because persist.el has no interactive functions and is thus more of a library than an editor. If there's a way to attach a note to the ftpmaster review, then let's do that! I'm of course happy to happy to correct the package's classification in control so that it matches the archive. > I: persist-el source: public-upstream-key-not-minimal > upstream/signing-key.asc has 1 extra signature(s) for keyid 066DAFCB81E42C40 > > N: > > > N:The package contains a public upstream signing key with extra > > > N:signatures. The signatures are unnecessary and take up space in the > > > N:archive. > > > N: > > > N:Please export the upstream key again with the command: > > > N: > > > N: $ gpg --armor --export --export-options export-minimal,export-clean > > > N: > > > N:and use that key instead of the key currently in the source package. > > > N:
Bug#954050: RFS: persist-el/0.4+dfsg-1 [ITP] -- persist variables between Emacs Sessions
Hi Thomas and Sébastien, #947017 "ITP: org-drill" is blocked by this RFS (#954050) for a required dependency (persist-el). Please sponsor at your earliest convenience to we can resume progress on getting org-drill back into Debian. Thanks, Nicholas signature.asc Description: PGP signature
Bug#955323: RFS: atomic-chrome-el/2.0.0-1 [ITP] -- edit a web-browser text entry area with Emacs
Package: sponsorship-requests Severity: wishlist Control: block 909336 by -1 Dear mentors, I am looking for a sponsor for my package "atomic-chrome-el" Package name: atomic-chrome-el Version : 2.0.0-1 Upstream Author : alpha22jp URL : https://github.com/alpha22jp/atomic-chrome License : GPL-2+ Vcs : https://salsa.debian.org/emacsen-team/atomic-chrome-el Section : editors It builds this binary package: elpa-atomic-chrome - edit a web-browser text entry area with Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/atomic-chrome-el Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/atomic-chrome-el/atomic-chrome-el_2.0.0-1.dsc Alternatively, sponsor from git: git clone g...@salsa.debian.org:emacsen-team/atomic-chrome-el.git uscan -v --download-current-version Changes since the last upload: * Initial release. (Closes: #909336) Regards, Nicholas
Bug#954050: RFS: persist-el/0.4+dfsg-1 [ITP] -- persist variables between Emacs Sessions
Package: sponsorship-requests Severity: wishlist Control: block 953128 by -1 Dear mentors, I am looking for a sponsor for my package "persist-el". It is a dependency of org-drill (ITP #947017), and org-drill will restore functionality to Emacs' org-mode that was previously built-in. * Package name: persist-el Version : 0.4+dfsg-1 Upstream Author : Phillip Lord * URL : http://elpa.gnu.org/packages/persist.html * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/persist-el Section : editors It builds this binary package: elpa-persist - persist variables between Emacs Sessions To access further information about this package, please visit the following URL: https://mentors.debian.net/package/persist-el Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/persist-el/persist-el_0.4+dfsg-1.dsc Alternatively, use git, gbp, and pristine tar using this repo: https://salsa.debian.org/emacsen-team/persist-el Changes since the last upload: * Initial release. (Closes: #953128) Regards, Nicholas
Re: package one package from a git repo with multiple packages
Hi,
Rosea, thank you for working on Non! Out of curiosity, how did you
resolve the NTK-fork dep and the waf evil? If it wouldn't be too much
trouble, would you please generate bin packages for the full suite? I'm
personally interested in the Timeline, Mixer, and Session manager, and I
have a friend who would appreciate the Sequencer.
Reply follows inline:
"rosea.grammostola" writes:
> On 3/9/20 2:11 PM, Andrey Rahmatullin wrote:
>>> You can build each project independently.
>> It doesn't matter.
>> If you are able to split this repo into separate source packages, do it,
>>
> That's probably the best option then. But what if upstream doesn't want
> to split it, how do I split it 'according to the Debian policy'?
>
> Which steps should I take?
src:non (or src:non-daw) would generate
bin:non-{timeline,sequencer,mixer,session-manager}. Andrey, is the
simplest method still debian/bin-pkg-name0.install and
debian/bin-pkg-name1.install + simple glob patterns, and/or do you think
rules will need to iterate over the waf targets?
signature.asc
Description: PGP signature
Bug#953396: RFS: heimdall-flash/1.4.2+dfsg-1 [ITS] [RC] -- tool for flashing firmware on Samsung Galaxy S devices
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "heimdall-flash" Package name: heimdall-flash Version : 1.4.2+dfsg-1 Upstream Author : Benjamin Dobell URL : http://www.glassechidna.com.au/products/heimdall/ License : Expat Vcs : https://salsa.debian.org/debian/heimdall-flash (please create) Section : devel It builds these binary packages: heimdall-flash - tool for flashing firmware on Samsung Galaxy S devices heimdall-flash-frontend - tool for flashing firmware on Samsung Galaxy S devices - Qt GUI To access further information about this package, please visit the following URL: https://mentors.debian.net/package/heimdall-flash Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/heimdall-flash/heimdall-flash_1.4.2+dfsg-1.dsc I've created a project I plan to move to Debian/collab-maint here: https://salsa.debian.org/sten-guest/heimdall-flash git clone https://salsa.debian.org/sten-guest/heimdall-flash.git Changes since the last upload: [Nicholas D Steeves] * Salvage heimdall-flash. (Closes: #946706) * Set myself as Maintainer. * New upstream release. (Closes: #872788) - Ben Hutchings, Matt Taggart, Mathias Behrle, and Michal Suchanek confirmed that this release solves issues with downloading a device's PIT. (Closes: #800573) * Build with Qt5. (Closes: #874915) * Add gbp.conf. * Drop remove-largefile-define.diff, to test if it is still needed. The upstream build system now uses qmake via CMake, rather than directly using the native Qt build system, heimdall-frontend.pro has disappeared, and CMakeLists.txt:L48 appends QT_LARGEFILE_SUPPORT to COMPILE_DEFINITIONS. Given Marcin's description and confirmation with Lisandro about QT_LARGEFILE_SUPPORT in Debian, it's unclear whether or not patching out QT_LARGEFILE_SUPPORT is still required. * Switch to debhelper-compat 12. Cut "--parallel" from rules, because it is enabled by default with this dh version. * Drop all overrides from rules. * Drop get-orig-source from rules, because it does not appear to have been used since 1.4~rc1+dfsg-1, because it uses the old github remote, and because I do not want to maintain it. * Add CMake as a build-dep. * Modify heimdall-flash.install and heimdall-flash-frontend.install to source binaries from CMake build dir. * Update Vcs links to use the Debian project on salsa. * Override dh_auto_install to build man page from Linux README, and add txt2man as a build-dep. * Drop the version qualifier for libusb-1.0-0-dev build-dep, because even oldoldstable has the minimum required version of 2:1.0.19-1. * Install man page using heimdall-flash.manpages * Provide a man page for heimdall-frontend using heimdall-flash-frontend.links * Copyright: Use secure URLs. * Copyright: Add Steve Langasek and myself for debian/* * Rules: Stop parsing the changelog and instead use pkg-info.mk to get DEB_VERSION_UPSTREAM. * Declare Standards-Version: 4.5.0 - Change Priority extra to optional. * Add lintian override for "appstream-metadata-missing-modalias-provide". See lintian-overrides for rationale. Thanks to Moritz Mühlenhoff for the review and discussion on this package's lint. * Add zadig.exe to copyright's Files-Excluded, add +dfsg suffix to version, and adjust watch file for a DFSG-repacked orig.tarball. * Add Lintian override for hardening-no-bindnow. See debian/lintian-overrides for rationale. . [Felix Lechner and Nicholas D Steeves] * Update watch file to use new gitlab.com upstream. Regards, Nicholas D Steeves
Bug#945447: RFS: emacs-websocket/1.12+1.g74e4b82-1 [ITP] -- Emacs WebSocket client and server
Hi Antoine,
Antoine Beaupré writes:
> A few comments...
>
> Why do you specify a compression level and algorithm in gbp.conf?
>
> compression = xz
> compression-level = 9
>
This reduces the incidence of encountering an annoying gbp bug, where
gbp fails, allegedly because "two tarballs were found", even when the
tarball did not previously exist on disk and is generated on demand from
upstream tag. Other than that it's harmless and redundant, because
these settings are now gbp defaults.
> Upstream doesn't seem to use any peculiar tarball format, so that
> generated tarball won't match the one published on github.
>
I'm using release tags directly and not github generated & published
tarballs ("why" is another discussion). The reason the Emacsen Team
requests a tarball in d/watch is because the git mode we previously used
was too resource-intensive. The bug mentioned above also has a useful
(hack of a) side-effect in that it seems to enforce new upstream version
imports from git tags rather than github-generated tarballs. Whenever
the "light" git-mode becomes generally recommended and preferred over
the tarball one I'll switch my upstream-uses-github packages over to it.
> I also wonder if it's really necessary to ship a git snapshot instead of
> the 1.12 release... I see it includes a patch to tweak the GPL version,
> is that why that was done?
>
For multiple past NEW packages, ftpmasters have asked me to contact
upstream about licensing problems (eg: we're accepting, but you need to
do xyz), so I started doing this preRFS. Then lamby asked me not to
carry licensing-related-changes as a quilt patch--with good rationale
that I agree with. Thus, packaging a git snapshot. The contradictory
declared license issue is here:
https://github.com/ahyatt/emacs-websocket/issues/62
> Are the tests included in the package build? or autopkgtest? could that
> be done? Not a blocker.
>
Sorry, I don't understand what you mean... ERT tests are already run
during the build, autopkgtest-pkg-elpa has been activated
(d/control:L12), I've confirmed autopkgtest runs the tests, and I've
also opened an upstream issue about integrating the functional tests
into the ERT framework:
https://github.com/ahyatt/emacs-websocket/issues/64
Since all NEW packages now require two uploads before they can enter
testing, I like to add value to the second upload, and the following
brand new commit seems like a good candidate for this:
https://github.com/ahyatt/emacs-websocket/commit/69ee80a88ba825a925e82a5576a340b3ec03fd51
Depending on how long it takes this package to pass NEW upstream might
tag a new release including that commit, which would be ideal for the
second upload!
> Otherwise looks good.
>
Thanks for reviewing :-) 'hope my reply sufficiently addresses your
concerns!
Cheers,
Nicholas
signature.asc
Description: PGP signature
Bug#945447: RFS: emacs-websocket/1.12+1.g74e4b82-1 [ITP] -- Emacs WebSocket client and server
Package: sponsorship-requests Severity: wishlist Control: block 945329 by -1 Dear mentors, I am looking for a sponsor for my package "emacs-websocket", which is a required dependency of atomic-chrome-el (Bug #909336). * Package name: emacs-websocket Version : 1.12+1.g74e4b82-1 Upstream Author : Andrew Hyatt * URL : https://github.com/ahyatt/emacs-websocket * License : GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-websocket Section : lisp It builds this binary package: elpa-websocket - Emacs WebSocket client and server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-websocket Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-websocket/emacs-websocket_1.12+1.g74e4b82-1.dsc Alternatively clone the repo and get upstream source from tag using gbp, or generate an orig tarball for other build systems: git clone g...@salsa.debian.org:emacsen-team/emacs-websocket.git cd emacs-websocket # optionally -> git deborig Regards, Nicholas
Bug#939996: closed by Boyuan Yang (Re: RFS: irony-mode/1.3.1-3~bpo10+1)
"Debian Bug Tracking System" writes: > 939996: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939996 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > From: Boyuan Yang > Subject: Re: RFS: irony-mode/1.3.1-3~bpo10+1 -- Emacs C/C++ minor mode > powered by libclang > To: 939996-d...@bugs.debian.org > Date: Fri, 04 Oct 2019 13:03:40 -0400 > > Uploaded onto NEW queue. > Thank you Boyuan Yang! Regards, Nicholas signature.asc Description: PGP signature
Bug#940927: RFS: color-theme-modern/0.0.2+4.g42a7926-1 [ITP] -- deftheme reimplementation of classic Emacs color-themes
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "color-theme-modern". This functionality was previously provided by the emacs-goodies-el package. Package name: color-theme-modern Version : 0.0.2+4.g42a7926-1 Upstream Author : Syohei YOSHIDA URL : https://github.com/emacs-jp/replace-colorthemes License : GPL-3+ Vcs : https://salsa.debian.org/emacsen-team/color-theme-modern.git Section : lisp It builds this binary package: elpa-color-theme-modern - deftheme reimplementation of classic Emacs color-themes To access further information about this package, please visit the following URL: https://mentors.debian.net/package/color-theme-modern Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/color-theme-modern/color-theme-modern_0.0.2+4.g42a7926-1.dsc Changes since the last upload: * Initial release. (Closes: #905246) Regards, Nicholas
Re: System freeze while compiling
On Sat, Sep 14, 2019 at 11:35:23PM +0200, Abou Al Montacir wrote: >On Sat, 2019-09-14 at 12:58 +0200, Geert Stappers wrote: > > On Sat, Sep 14, 2019 at 10:55:11AM +0200, Abou Al Montacir wrote: > > Hello All, > > I have a small Issue with Debian system freezing when compiling a SW the > system > > simply hangs and I need to cut powerTested on both Stretch and Buster. Same > > issue, the compiler makes the system freeze > > Is there a way to avoid this in order to understand what is the issue? > Some other options, on the assumption that it's memory starvation (may or may not work) might be to: 1) disable swap, and use the "vm.min_free_kbytes = 327680" sysctl. 3) Keep an eye on the system and + when it loses responsiveness. 4) ulimit (IIRC someone else mentioned this), but I've heard that it doesn't respond quickly enough to some requests. 5) Manual cgroups limits, LXC with cgroup limits, or possibly something like firejail. > Yes please, make it possible to understand the issue. > > Provide information how to reproduce it. > >I'm using a proprietary compiler for compiling a large C file with several >included files. The file used to compile fine when I invoque the compiler >with -std=gnu99, but if I enable -std=c11 then system freezes. >I'll not be able to provide neither the source nor the compiler itself as >it requires a license tied to the HW to run. However I can perform complex >testing. > > Actually I'm very surprised that a user space program (compiler) running on > an > > unprevileged account (non root) can kill the system as it happens. > Just to rule out one exotic possibility: Does this "license tied to the HW" use a kernel module? See this link for how to search of out of tree modules: https://unix.stackexchange.com/questions/72889/how-to-determine-which-module-taints-the-kernel > Does anyone know how to sandbox the command so that It does not kill the > system? > See item #5 above (I've never tested firejail btw)...also, I don't know if this would break the HW tied license check. It seems like it might. > Good question. Make the question better by telling what the command is. > > It might get you an answer how to sandbox it. > >The command is kind of "cc -std=gnu11 -o file.o file.c". > Another general recommendation is to configure syslog to send logs to another system, in case there's a helpful message that isn't getting flushed to disk before the crash. > Please CC me as not subscribed. > Done. Cheers, Nicholas signature.asc Description: PGP signature
Bug#939996: RFS: irony-mode/1.3.1-3~bpo10+1
Package: sponsorship-requests Severity: normal Dear mentors (CCing Gianfranco who helped make this possible with llvm bpo), I am looking for a sponsor for my package "irony-mode". My motivation for maintaining the backport is thus: a Debian user on the upstream bugtracker had difficulty making 1.3.1-1 (version in stable which uses libclang 7) work with a newer version of libclang (installed à la frankenDebian). So let's provide an official solution! Package name: irony-mode Version : 1.3.1-3~bpo10+1 URL : https://github.com/Sarcasm/irony-mode/ License : GPL-3+ Vcs : https://salsa.debian.org/emacsen-team/irony-mode Section : editors It builds these binary packages: elpa-irony - Emacs C/C++ minor mode powered by libclang irony-server - Emacs C/C++ minor mode powered by libclang (server) irony-mode - Transition Package, irony-mode to elpa-irony To access further information about this package, please visit the following URL: https://mentors.debian.net/package/irony-mode Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/irony-mode/irony-mode_1.3.1-3~bpo10+1.dsc Changes since the last upload: * Rebuild for buster-backports. . irony-mode (1.3.1-3) unstable; urgency=medium . [ Nicholas D Steeves ] * Switch to debhelper-compat 12. * Build against libclang-8. . [ David Bremner ] * Team upload * Rebuild with quilt patches . irony-mode (1.3.1-2) unstable; urgency=medium . * Team upload. * Rebuild with current dh-elpa Regards, Nicholas
