Bug#1036955: RFS: trurl/0.7-1 -- command line tool for URL parsing and manipulation
On Tue, 2023-05-30 at 21:41 +0200, Michael Ablassmeier wrote: > trurl (0.7-1) unstable; urgency=medium > . > * New upstream release. Uploaded. Upstream has added -Werror to the default CFLAGS. It isn't recommended to do this in released software, because it means a lot more build failures when compilers get updated in distros. Please consider sending upstream a patch to move that to their CI scripts instead. Most of the suggestions I listed in my first review still apply: https://lists.debian.org/msgid-search/551f9af844ea1ebe0b814678c5560e42303d8299.ca...@debian.org -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello again, Nicholas ProtonMail wins this time, I shall send directly to the bug as of now. > 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: Sure, I'm absolutely fine with that > 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. I'll check if those are resolved, of course; I'll add a suitable systemd service to resolve "missing-systemd-service-for-init.d-script". > > Thank you, I hope yours was as good as mine! > Sure was, thank you too and have a great day/night ! Best, Alexandru --- Original Message --- On Wednesday, May 31st, 2023 at 00:06, Nicholas D Steeves wrote: > 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 alexandru_mih...@protonmail.ch 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
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
Hello Nicholas, Of course, please quote the first email at the bug. My apologies for omitting to reply all :) Best, Alexandru On Tue, May 30, 2023 at 23:17, Nicholas D Steeves <[s...@debian.org](mailto:On Tue, May 30, 2023 at 23:17, Nicholas D Steeves < wrote: > 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
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#1036955: RFS: trurl/0.7-1 -- command line tool for URL parsing and manipulation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "trurl": * Package name : trurl Version : 0.7-1 * URL : https://github.com/curl/trurl * License : curl Section : utils The source builds the following binary packages: trurl - command line tool for URL parsing and manipulation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/trurl/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/t/trurl/trurl_0.7-1.dsc Changes since the last upload: trurl (0.7-1) unstable; urgency=medium . * New upstream release. Typos in manpage have been reported upstream: https://github.com/curl/trurl/pull/212 Regards, -- Michael Ablassmeier
Re: Questions about ITP in Debian
On Mon, May 29, 2023 at 6:24 PM Tadeu Sampaio wrote: > > Thx Robin for the fast response! So what is needed in order to proceed with > the ITP below, we need a sponsor? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024547 > > Best regards, > Tadeu The (currently) last message [1] on that ITP already mentioned what needs to be done and provided useful links to get started. In short, to proceed you'd need to: 1. Coordinate with the current owner of that ITP (unless that's you). 2. Prepare a source package that conforms to Debian policy and can build the binary packages (.deb files) using the standard Debian build tools. (Note that upstream's .deb files are not sufficient.) 3. Find a sponsor willing to review and upload the source package for you. For example through mentors.debian.net and this mailing list. Documentation on what this means in practice is found in the links already provided in the ITP. [1] [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024547#25 Regards, Robin
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello again, I have reuploaded mini-httpd to mentors as per your recommandations Nicholas. Please see my last mail for some questions regarding upstream/VCS. Regards, Alexandru Mihail
