Bug#1068101: RFS ping mini-httpd/1.30-10 -- Small HTTP server
Hi, thanks for your considerations ! > It looks like you've been maintaining this package for a while now. > Have you considered applying to become a Debian Maintainer[1]? That > would allow you to eventually be given upload permissions on the > mini- > httpd package, so you wouldn't need to keep filing RFS bugs. :) > Yes, I've been thinking about applying for a long time, my first sponsor ( who helped me with the first 2-3 versions ) suggested it as well, but I was not yet sure how long I should wait as a non-uploading maintainer before applying. I do need a DD to "vouch" for me, don't I ? I don't know how busy my first (and only regular) sponsor is, he's been away for a few releases..I hope he'll reply if I ask for some help. Thanks for the idea :) > Also, I suspect people might be more hesitant to sponsor packages > after the actions of "Jia Tan" and the xz backdoor. Going through the > process to become a DM can help demonstrate your commitment to good > packaging and the Debian project as a whole. (I'm not in any way > trying > to suggest you might be a malicious actor, just that there's recently > been [rightfully] a lot of scrutiny of how easy it can be for someone > to mess with packages shipped by a distribution.) Yes you,re right, perhaps that is a cause as well. Usually, RFS were closed in a matter of days before for this package. Jia's actions did produce some shockwaves in the FOSS/Linux world for sure.. Have a great day, I'll look into starting the new member process ! Alexandru Mihail > > Mathias > > [1] -- https://nm.debian.org/public/newnm signature.asc Description: This is a digitally signed message part
Bug#1068101: RFS ping mini-httpd/1.30-10 -- Small HTTP server
Pinging about the RFS - mini-httpd/1.30-10. If anyone can help with the upload, that would be a huge help. It's been a month since opening the RFS and some people that proposed patches for this release are really looking forward to using it. Mentors page: https://mentors.debian.net/package/mini-httpd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-10.dsc Thanks a lot and have a nice day, Alexandru Mihail mini-httpd maintainer signature.asc Description: This is a digitally signed message part
Bug#1068101: RFS ping mini-httpd/1.30-10 -- Small HTTP server
Hi, a new upload for mini-httpd/1.30-10 is ready on mentors. This upload clarifies systemd hardening features with a NEWS entry, removes commented PrivateUsers directive and a typo in the changelog. Thanks, Salvo ! I think we're getting close to release. Please take a look at your convenience (#2): https://mentors.debian.net/package/mini-httpd/ Have a great day and thank you for your interest in Debian, Alexandru Mihail mini-httpd maintainer signature.asc Description: This is a digitally signed message part
Bug#1068101: RFS ping mini-httpd/1.30-10 -- Small HTTP server
Hello, Thanks for your help ! > I had a look. > > It's not called "SystemD". You're correct, I'll fix the typo :) > > Why is this line commented? > > #PrivateUsers=yes This should have been deleted. I will fix that. I was doing some experiments with PrivateUsers which turned out to make CGI scripts unusable, so it's off the table. > > > I think your patch presumes that the filesystem is utf-8 encoded and > would > break in other (admittedly rare) cases. Just FYI. This is fine; The utf8 charset encoding is sent when the client requests directory listings and error pages (that's what the patch does). This is standard, expected behaviour for a web server. (From the web: Because it is the default all modern browsers will use utf-8 without being explicitly told to do so. It remains in meta data as a common good practice) > > Commits on salsa introduce unrelated changes in 1 single commit. > > Did you submit the patches to upstream? Is upstream active? Upstream is sadly defunct for all intents and purposes. Patches have been forwarded long before I took over mini-httpd (a year ago) and no news were heard for a really long time. I think the last upstream release happened more than 5-6 years ago (1.30). That's the reason we're on 1.30-10 now :). I discussed these matters with other members in Debian as well; I could forward everything but sadly as far as I know, nobody would read them. We're the upstream for now. > > Your changes to the .service file might break CGI scripts that might > be having > access to all sort of things. I think a news file should be added to > warn users > of the possibly breaking changes. You're right, a news file is in order. I will start writing one today. The good part is that the systemd service is rather new (2 releases ago) so not many people adopted it yet. The chance of functioning setups just breaking is lower, then. I will write a news entry, anyway. > Thanks for your review, I'll have a better release ready in a bit. Have a great one, Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1068101: RFS ping mini-httpd/1.30-10 -- Small HTTP server
Hello, pinging about the RFS - mini-httpd/1.30-10. This introduces systemd service hardening, fixes a bug related to charsets in error pages and directory listings which was ugly. Please help if possible. Mentors page: https://mentors.debian.net/package/mini-httpd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-10.dsc Thanks ! signature.asc Description: This is a digitally signed message part
Bug#1068101: RFS ping mini-httpd/1.30-10 -- Small HTTP server
Gently pinging about the RFS - mini-httpd/1.30-10 Mentors page: https://mentors.debian.net/package/mini-httpd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-10.dsc Thanks a lot ! signature.asc Description: This is a digitally signed message part
Bug#714549: Bug fixed in 1.30-10
Hello Alexander, I've incorporated your suggestions into a patch present in the next version of mini-httpd (1.30-10). This is already committed in VCS, I'm waiting for a FTP upload for now. Thanks a lot for your contribution(s)to Debian ! This is what your test commands produce now with the latest (1.30-10) version of the program (default config): worker@sid:~$ echo -en 'GET /no/such/file HTTP/1.0\r\n\r\n' | nc 127.0.0.1 80 | grep -i Content-Type Content-Type: text/html;charset=iso-8859-1 worker@sid:~$ echo -en 'GET /directory/ HTTP/1.0\r\n\r\n' | nc 127.0.0.1 80 | grep -i Content-Type Content-Type: text/html; charset=UTF-8 worker@sid:~$ apt list --installed | grep mini-httpd WARNING: apt does not have a stable CLI interface. Use with caution in scripts. mini-httpd/now 1.30-10 amd64 [installed,local] Does this look OK to you now ? Seems fixed from my point of view. If possible, please retest when you get an official upgrade of the package throught apt. If everything is OK, nothing else needs to be done. However, if you still see wrong output please open another bug report and we'll take it from there since this one will automatically close pending FTP upload. Thanks again and have a good one, Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1068101: RFS: mini-httpd/1.30-10 -- Small HTTP server
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mini-httpd": * Package name : mini-httpd Version : 1.30-10 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 Section : web The source builds the following binary packages: mini-httpd - Small HTTP server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mini-httpd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-10.dsc Changes since the last upload: mini-httpd (1.30-10) unstable; urgency=medium * Added patch improving handling of "charset=%s" in error pages and directory listing. Before, a literal "%s" was output as opposed to the actual charset. Now, the correct charset (UTF-8 for dirs and ISO-8859-1 for err) is output. Thanks again, Alexander Foken ! (Closes: #714549) * Added a SystemD DocumentationKey entry fixing lintian warning. This points to the manpage for now. * Added SystemD hardening features to service. The directives I have provided should have no impact. I've confirmed no impact to basic functionality, vhosting, error pages and CGI. I managed to get the service to a "4.7 - OK" rating by using systemd-analyze security mini-httpd (all the way from 9.6). I have NOT enabled hardening features which have a high change of impacting functionality such as removing CAP_CHROOT which would mean mini_httpd's chroot mode of operation is forbidden. Help is welcome in improving these options (maybe someone with a security background could chip in). Regards, -- Alexandru Mihail mini-httpd maintainer signature.asc Description: This is a digitally signed message part
Bug#1065667: RFS ping mini-httpd/1.30-9 -- Small HTTP server
Gently pinging about the RFS - mini-httpd/1.30-9 Mentors page: https://mentors.debian.net/package/mini-httpd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-9.dsc Thanks a lot ! signature.asc Description: This is a digitally signed message part
Bug#1065667: RFS: mini-httpd/1.30-9 -- Small HTTP server
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mini-httpd": * Package name : mini-httpd Version : 1.30-9 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 Section : web The source builds the following binary packages: mini-httpd - Small HTTP server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mini-httpd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-9.dsc Changes since the last upload: * Added patch fixing NPH scripts (SSL) getting an additional HTTP/1.0 200 OK header before the actual expected one. This violates the CGI RFC (RFC-3875). (Closes: #1064656) * Merged branch fixing mini-httpd starting too early after reboot. This only happened using the old init.d script. The systemd service is not affected. Thanks, Jean ! Regards, -- Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1064656: mini-httpd violates RFC3875 for NPH-CGIs
Hello again,> Dear Maintainer, > > mini-httpd as currently found in > https://salsa.debian.org/debian/mini-httpd/- > /blob/master/mini_httpd.c?ref_type=heads > violates the CGI RFC (RFC-3875). The RFC specifies in "5.2 NPH > Response" > that an "NPH script MUST return a complete HTTP response message", > and > more "The server MUST ensure that the script output is sent to the > client unmodified." But mini-http actually DOES modify the HTTP > response > from NPH CGIs. It prefixes the script output with a fixed "HTTP/1.0 > 200 > OK" header, even if the NPH CGI wants to report a different status. > This > happens only if SSL is active. Acknowledged, thanks for the test case and proposed solution. This will be incorporated into mini-httpd-1.30.9. Thanks for your contribution to Debian, Alexandru Mihail, mini-httpd maintainer
Bug#1062805: RFS: mini-httpd/1.30-8 -- Small HTTP server
Hi Abhijith, Thanks a lot ! I'll wait for your upload before pushing git tags then. Have a great day and thanks again for the help, Alexandru signature.asc Description: This is a digitally signed message part
Bug#1062805: RFS ping
To clarify, the package to be uploaded is available at: https://mentors.debian.net/package/mini-httpd/ Thanks ! Alexandru Mihail mini-httpd maintainer signature.asc Description: This is a digitally signed message part
Bug#1062805: RFS ping
Gently pinging about this upload. It fixes #1061792 which seems to impact the workflow of some users. Also, it fixes a logical error in the systemd service which is guaranteed to be present in all versions > 1.30.3. Kinds regards, Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1062805: RFS: mini-httpd/1.30-8 -- Small HTTP server
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mini-httpd": * Package name : mini-httpd Version : 1.30-8 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 Section : web The source builds the following binary packages: mini-httpd - Small HTTP server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mini-httpd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-8.dsc Changes since the last upload: mini-httpd (1.30-8) unstable; urgency=medium . * Modified mini-httpd.postinst to check if we're doing a fresh install or upgrading. Secondly, if we're fresh installing, the default index.html file is copied into /var/www/html only if no other index files are present (ex: index.cgi). This prevents the shipped index.html overwriting existing index.ext files. If we are upgrading, no files will be touched. (Closes: #1061792) * Removed erroneous duplicate "-C /etc/mini-httpd.conf" in systemd ExecStart. The "-C" call was already present in the EnvironmentFile (/etc/default/mini-httpd) read and used by the service. This resulted in mini-httpd's commandline containing the "-C" call twice. Thanks, Alexander Foken. Regards, -- Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1061792: mini-httpd: Update of mini-httpd still breaks default web page if it is not index.html
> Hi, Hi again, > Result of my basic tests: > > Update with existing /var/www/html/index.cgi works as expected > (index.cgi as default page). > > Install with existing /var/www/html/index.cgi works as expected > (index.cgi as default page). > > Install without /var/www/ works as expected (index.html copied, and > as > default page). > > Install with empty /var/www/html/ works as expected (index.html > copied, > and as default page). > > > Testing error behaviour: > > rm -rf /var/www > > touch /var/www > > chmod 000 /var/www > > apt install /tmp/mini-httpd_1.30-8_amd64.deb > > Fails as expected: > > Setting up mini-httpd (1.30-8) ... > mkdir: cannot create directory ‘/var/www’: Not a directory > dpkg: error processing package mini-httpd (--configure): > installed mini-httpd package post-installation script > subprocess > returned error exit status 1 > Processing triggers for man-db (2.12.0-3) ... > Errors were encountered while processing: > mini-httpd > E: Sub-process /usr/bin/dpkg returned an error code (1) > > postinst checks look sane. > Thanks a lot for your help ! You've sped up this release tremendously by helping me with testing ! > > But while testing, I found an odd little detail: > > mini_httpd is invoked with a repeated -C /etc/mini-httpd.conf, or at > least that is what systemd reports. You're right, I missed that one ! Although you're right, httpd does not care about duplicated -C call now, it might in the future if getopts in mini_httpd.c change. It's clearly a bug I missed when I created the systemd service from scratch. This: git diff debian/mini-httpd.service diff --git a/debian/mini-httpd.service b/debian/mini-httpd.service index 577b72a..916ae65 100644 --- a/debian/mini-httpd.service +++ b/debian/mini-httpd.service @@ -6,7 +6,7 @@ After=network.target Type=forking PIDFile=/run/mini_httpd.pid EnvironmentFile=-/etc/default/mini-httpd -ExecStart=/usr/sbin/mini_httpd -C /etc/mini-httpd.conf $DAEMON_OPTS -i /run/mini_httpd.pid +ExecStart=/usr/sbin/mini_httpd $DAEMON_OPTS -i /run/mini_httpd.pid [Install] WantedBy=multi-user.target fixes it entirely. On this note, I'm getting close to releasing 1.30-8, this systemd little fix pushes these changes into "quite important enough to push into a new release" land. Thanks for all your help ! You'll automatically get a mail when I push, as your Bug report will automatically close. Have a great one, Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1061792: mini-httpd: Update of mini-httpd still breaks default web page if it is not index.html
Hello, thank you for reporting this bug here ! > Package: mini-httpd > Version: 1.30-7 > Severity: normal > > Dear Maintainer, > > unfortunately, the current version mini-httpd 1.30-7 in unstable does > NOT fix the Bug#1057842. > > The postinst script > < > https://salsa.debian.org/debian/mini-httpd/-/blob/master/debian/mini- > httpd.postinst?ref_type=heads> > still creates an unwanted default page. It is no longer named > index.mini-httpd.html, but instead index.html. This makes things > worse > with the new version of the 0003-fix-change-index-document-root patch > < > https://salsa.debian.org/debian/mini-httpd/-/blob/master/debian/patche > s/0003-fix-change-index-document-root?ref_type=heads>. > index.mini-httpd.html would have lower priority than any other > default > page, but index.html has highest priority. > I can reproduce your environment, all is well so far. > > Checking for and copying to /var/www/html/index.mini-httpd.html would > have prevented that. > > As before, the real problem is that the postinst script re-creates an > index file in the document directory during the update of the > package. > It is ok to do so during installation of the package, but not during > the > update. > > Looking at the apache2 package may help: > < > https://salsa.debian.org/apache-team/apache2/-/blob/master/debian/apac > he2.postinst?ref_type=heads> > I feared the fragile handling of in postinst would bite this package in the arse sooner or later, as inherited by former maintainers. I know how APT handles its error codes, the apache2 solution should work. Unfortunately, other bug investigations limit the time I could spend testing this. Could you perhaps help me test a dirty .deb package which includes better handling of install/upgrade file copying? If so, we should think of a channel in which I could upload said package. I'd love to align this package's handling of shipped files with apache2. > Best regards > > Alexander Foken > > Kind regards, Alexandru Mihail Maintainer signature.asc Description: This is a digitally signed message part
Bug#1061157: RFS: mini-httpd/1.30-7 -- Small HTTP server
> > Hi Alexandru, > > Happy New Year! I'll sponsor this one. > Hello, Nicholas ! Happy New Year to you too ! I hope you had a great holiday with your family and friends ! > 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 > Sure, will do, thanks for the pointer ! I refrained from using it in the past because I couldn't get it to work with GUI mail clients e.g Evolution/Thunderbird. It insisted on using sendmail which, naturally, fails. It's surely a newbie error on my end. > 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. > I somehow forgot about that part of tag etiquette, thanks ! Regarding punctuation, it seems too much holiday cheer damaged my grammar parser a bit... :D > Cheers, > Nicholas Have a great one, thanks for the sponsorship (and past mentoring) ! Take care, Alexandru signature.asc Description: This is a digitally signed message part
Bug#1061157: RFS: mini-httpd/1.30-7 -- Small HTTP server
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mini-httpd": * Package name : mini-httpd Version : 1.30-7 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 Section : web The source builds the following binary packages: mini-httpd - Small HTTP server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mini-httpd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-7.dsc Changes since the last upload: mini-httpd (1.30-7) unstable; urgency=medium . * Modified mini-httpd.postinst to not copy /usr/share/doc/mini-httpd/examples/index.html into /var/www/html/index.html if it's not readable, fixing weird edge cases where docker's dpkg cleans up /usr/share/*/examples beforehand, (Closes: #1061070) * Created 0011-fix-typo-in-documentation-maxage which clears confusion regarding the maxage config & cli option, the actual name for the variable being max_age in mini_httpd.c. The patch modifies documentation and help output to reflect this reality. (Closes: #1018900) Regards, -- Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1061070: mini-httpd: Installing fails with : cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No such file or directory
On a later thought, this also works: git diff debian/mini-httpd.postinst diff --git a/debian/mini-httpd.postinst b/debian/mini-httpd.postinst index 372bbe0..4a469d1 100644 --- a/debian/mini-httpd.postinst +++ b/debian/mini-httpd.postinst @@ -2,8 +2,10 @@ set -e if [ ! -r /var/www/html/index.html ]; then -mkdir -p /var/www/html -cp /usr/share/doc/mini-httpd/examples/index.html /var/www/html/index.html +if [ -r /usr/share/doc/mini-httpd/examples/index.html ]; then +mkdir -p /var/www/html +cp /usr/share/doc/mini-httpd/examples/index.html /var/www/html/index.html +fi fi #DEBHELPER# I tested it successfully on Debian Testing slim. However, it will take me some time to add this to the next release and, moreover, for that to make its way from sid -> testing. If urgent action is required, use a local workaround; if not, wait for my upload :) Regards, Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1061070: mini-httpd: Installing fails with : cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No such file or directory
Hi again, I've finally cracked the code ! I finally found out what the difference is, regarding package installs, between the official and slim images. Mainly, the existence of this file, which overrides dpkg official logic: /etc/dpkg/dpkg.cfg.d/docker You can check this yourself ! This file is NOT present in the non-slim images (checked on sid and sid-slim just to be sure as well). The file does a bunch of wild stuff, mainly telling dpkg (apt backend) to exclude a bunch of folders and files (through wildcards) from dpkg installs and configures (mainly /usr/share/doc, locale). This seems logical for a slimmed down image, but may lead to inconsistent results. Out of pure curiosity I tried installing some other random packages I use and, sure enough, one of them failed in a similar way (failed to cp to /usr/share/doc//examples/config.txt). It was mc or an apache plugin I think. Anyway, adding this last line with mini-httpd: root@ef77c06126ea:/etc/dpkg/dpkg.cfg.d# tail -n 1 /etc/dpkg/dpkg.cfg.d/docker path-include /usr/share/doc/mini-httpd/examples/* seems to fix it (works as expected). I see the maintainer of this image did a similar workaround for other stuff around such as this line: path-include /usr/share/doc/kde/HTML/C/* Thus, I propose the easiest fix of adding this to your yaml config file (I don't have much experience with docker). I still want to ship this file in the official manner which other packages use, so I'm reluctant to propose a workaround which is only applicable here. I'm working on patching some existing C problems which affect all users, currently. However, if you or anyone else proposes a fix which does not affect normal operation in the debian:testing docker && plain install use cases and does not break lintian rules, I'm more than happy to incorporate it in mini-httpd:1.30-7. If you find the workaround satisfactory and you need to use the slim image, please close this bug via bugs.debian.org; if not I'm open to suggestions and patch proposals. Thank you for improving the quality of Debian packages ! Alexandru Mihail mini-httpd maintainer On Thu, 2024-01-18 at 17:35 +0100, lor...@freenet.de wrote: > On Thu 2024-01-18 17:17, Alexandru Mihail wrote: > > Can you replicate the problem by running apt purge mini-httpd && > > apt >install mini-httpd ? (docker) > > # docker run -ti --rm debian:testing-slim bash -c "apt-get update && > apt-get purge mini-httpd && apt-get install -y mini-httpd > [...] > Package 'mini-httpd' is not installed, so not removed > [...] > Setting up mini-httpd (1.30-6) ... > cp: cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No > such file or directory > dpkg: error processing package mini-httpd (--configure): > installed mini-httpd package post-installation script subprocess > returned error exit status 1 > Setting up libgdbm6:amd64 (1.23-5) ... > Setting up libaprutil1:amd64 (1.6.3-1+b1) ... > Setting up apache2-utils (2.4.58-1+b1) ... > Processing triggers for libc-bin (2.37-13) ... > Errors were encountered while processing: > mini-httpd > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > Can you replicate in a non-docker environment (testing or sid) if > > you have access to one ? > > no, but I can use another base image > > # docker run -ti --rm debian:testing bash -c "apt-get update && apt- > get install -y mini-httpd" > > this works. The error seems only to happen on debian:testing-slim but > not on debian:testing signature.asc Description: This is a digitally signed message part
Bug#1061070: mini-httpd: Installing fails with : cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No such file or directory
Hello, I cannot replicate the failing cp on 2 Debian virtual machines, one tracking testing and one sid. I don't have much experience with docker, I will try your command in the sid VM. Docker fails to run hello world on my personal Ubuntu machine for some odd reason. On Wed, 2024-01-17 at 10:51 +, lortas wrote: > Package: mini-httpd > Version: 1.30-6 > Severity: important > > Dear Maintainer, > > > # docker run -ti --rm debian:testing-slim bash -c "apt-get update && > apt-get install -y mini-httpd" > [...] > Setting up libexpat1:amd64 (2.5.0-2+b2) ... > Setting up libssl3:amd64 (3.1.4-2) ... > Setting up libapr1:amd64 (1.7.2-3+b2) ... > Setting up mini-httpd (1.30-6) ... > cp: cannot stat '/usr/share/doc/mini-httpd/examples/index.html': No > such file or directory > dpkg: error processing package mini-httpd (--configure): > installed mini-httpd package post-installation script subprocess > returned error exit status 1 > Setting up libgdbm6:amd64 (1.23-5) ... > Setting up libaprutil1:amd64 (1.6.3-1+b1) ... > Setting up apache2-utils (2.4.58-1+b1) ... > Processing triggers for libc-bin (2.37-13) ... > Errors were encountered while processing: > mini-httpd > E: Sub-process /usr/bin/dpkg returned an error code (1) > Can you replicate the problem by running apt purge mini-httpd && apt install mini-httpd ? (docker) Can you replicate in a non-docker environment (testing or sid) if you have access to one ? Regards, Alexandru Mihail mini-httpd maintainer signature.asc Description: This is a digitally signed message part
Bug#1058066: RFS ping
Uploaded, thanks ! https://mentors.debian.net/package/mini-httpd/ https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-6.dsc > > Please upload your package to mentors. Thanks. > > signature.asc Description: This is a digitally signed message part
Bug#1058066: RFS ping
Gently pinging about the current RFS; This contains an important fix for a problem which also affects stable (#1057842) Thanks, Alexandru Mihail mini-httpd maintainer signature.asc Description: This is a digitally signed message part
Bug#1058066: sponsorship-requests: Request sponsored upload for mini-httpd_1.30-6
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mini-httpd": * Package name : mini-httpd Version : 1.30-6 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.git The source builds the following binary packages: mini-httpd_1.30-6_arch.deb For more information please see https://salsa.debian.org/debian/mini-httpd.git and https://salsa.debian.org/debian/mini-httpd/-/tags/debian%2F1.30-6 Changes since the last upload: mini-httpd (1.30-6) unstable; urgency=medium * Modified 0003-fix-change-index-document-root and 0005-cgi-php to push index.mini-httpd.html to the end of known index.* array, modified install script to copy the provided index.html into /var/www/html/index.html, if not present (Closes: #1057842) * Moved package provided index.html file to /usr/share/doc/mini-httpd/examples, to avoid lintian warning regarding doc location Regards, Alexandru Mihail mini-httpd maintainer signature.asc Description: This is a digitally signed message part
Bug#1057842: mini-httpd: Update of mini-httpd breaks default web page if it is not index.html
Hi, Thanks for reporting this bug ! I retested your actions and successfully reproduced the problem. This is an older patch before my role here, why index.mini-httpd.html is in the second slot in that array eludes me totally. (probably historic reasons ?) > https://sources.debian.org/patches/mini-httpd/1.30-3/0003-fix-change-index-document-root/ > > The real problem is that > https://salsa.debian.org/debian/mini-httpd/-/blob/master/debian/mini-httpd.postinst > creates the file /var/www/html/index.mini-httpd.html at all, and that > https://sources.debian.org/patches/mini-httpd/1.30-3/0003-fix-change-index-document-root/ > modifies the binary to deliver this file. > Agreed, thanks for your detective work ! > A more sane way would be to follow the example of Apache, delivering > a > default > /var/www/html/index.html when the package is installed, update it > only > if it is > unmodified, and do not recreate it when the package is updated. That > way, the entire patch > https://sources.debian.org/patches/mini-httpd/1.30-3/0003-fix-change-index-document-root/ > can be omitted and mini-httpd works as intended. This is the solution I was considering as well; We're already shipping the frugal default index.html which postinst is manually copying into / var/www/html. Copying files like that in postinst is frowned upon, anyway; package files, if possible, should be handled properly from the beginning. I was thinking of removing 0003-fix-change-index-document- root.patch all together; move the default index.html in the package filesystem into /var/www/html/index.html and not recreating it if it's dirty. I find that an elegant solution to this problem. The only think we'd break is any external scripts which would depend on index.mini- httpd.html existing. I know of no such scripts, but other people's packages might/might not complain. Maybe worth investigating. This is a pretty important bug as it affects the version in stable, too, not only sid/testing (1.30-3), so thanks for reporting, again ! If everything works as expected, I plan on releasing another update 1.30-6 the next week; I want to lump this bugfix together with some general cleanup of the existing patches. If you have any other questions/suggestions please reply to the bug. Thanks ! Alexandru Mihail mini-httpd maintainer signature.asc Description: This is a digitally signed message part
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Hello, > Looks good to me! I just uploaded. If this upload introduces any > other > problems, feel free to contact me to upload a fix. > > Thanks! > Thanks for your contribution and thanks for offering to help with a possible future upload :) By the way, the other fixed bug rendered virtual hosting in mini-httpd pretty annoying; if you were ever thinking about using that feature, it should work as intended now (seeing you have a non-trivial setup, maybe that could be of interest sometimes) > cheers, josch Have a great day, Alexandru signature.asc Description: This is a digitally signed message part
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Hello again,> okay, I'll wait. Thank you for your quick reply! Thank you for the wait ! I've committed the necessary systemd service fix into a new mini-httpd release (1.30-5). Currently waiting for sponsored upload from my mentor. Have a great one, Alexandru signature.asc Description: This is a digitally signed message part
Bug#1052364: sponsorship-requests: Request sponsored upload for mini-httpd_1.30-5
Package: sponsorship-requests Severity: normal Hello Nicholas, Requesting a sponsored upload for a new version of mini-httpd (mini- httpd_1.30-5), fixing https://bugs.debian.org/491078 and https://bugs.debian.org/1051374 (Serious). https://salsa.debian.org/debian/mini-httpd/-/tags/debian%2F1.30-5 Thanks and have a tremendous day, Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Hello, > do you have an estimate when you think you can upload this? > > This bug has now blocked part of my work in Debian for two weeks and > I'm unable > to do another release for my package until this bug gets fixed. > I'm planning to release no later than Friday. I'm also tackling #491078 now, and would prefer to bundle both fixes into 1.30-5 for efficiency reasons and a cleaner update path. > If you are short on time I can also NMU mini-httpd with the changes > to the > service file I proposed in my last mail. > Is that all right with you ? > Thanks! > > cheers, josch Cheers, Alexandru signature.asc Description: This is a digitally signed message part
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Hello, > I successfully tested the following patch to the .service file: > > @@ -5,7 +5,8 @@ > [Service] > Type=forking > PIDFile=/run/mini_httpd.pid > -ExecStart=/usr/sbin/mini_httpd -C /etc/mini-httpd.conf > +EnvironmentFile=-/etc/default/mini-httpd > +ExecStart=/usr/sbin/mini_httpd -C /etc/mini-httpd.conf $DAEMON_OPTS > -i /run/mini_httpd.pid > > [Install] > WantedBy=multi-user.target > Thanks for your input and suggestions :) > The EnvironmentFile uses "=-" to support a non-existant > /etc/default/mini-httpd. The ExecStart line also adds a -i option to > make sure > that neither /etc/mini-httpd.conf nor $DAEMON_OPTS can set -i to > something that > is different from the path in PIDFile. > > What do you think? This is great, I successfully tested your proposed service file changes and everything appears to work great ! We're currently on mini-httpd/unstable,now 1.30-4; The next release (1.30-5) will incorporate your fix, closing this bug. > > Thanks! > > cheers, josch Thanks to you too ! Best, Alexandru signature.asc Description: This is a digitally signed message part
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Hello, > > > > > > > If possible it would of course be nice if the systemd service > > > would not break > > > user's setups and would continue to consume /etc/default/mini- > > > httpd. > > > > this issue has now made the mmdebstrap jenkins job fail for 10 days > > in a row: > > > > https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/ I can confirm the issue and this will be addressed. This is NOT intentional, thus no NEWS entry will be added. > > > Or will you restore > > compatibility with existing setups using /etc/default/mini-httpd so > > that I > > need to do nothing and just wait for an upload fixing this? > Yes, this is the intended course of action. > I asked in #debian-systemd and the fix could be as simple as setting > the > following in the .service file: > > EnvironmentFile=-/etc/default/mini-httpd > > Can you confirm? I will test this and get back to you as soon as I can confirm the fix. Documentation on /etc/default/mini-httpd options is rather scarce, do you mind posting a minimal /etc/default/mini-httpd file with which I could confirm the fix (a path or port setting perhaps)? It would speed up my work here as the package does not provide a default one. > > Thanks! > > cheers, josch Cheers, Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Greetings again, #1 Changes rejected: mini-httpd_1.30-4.dsc: Invalid size hash for mini- httpd_1.30.orig.tar.gz: According to the control file the size hash should be 43469, but mini-httpd_1.30.orig.tar.gz has 43889. If you did not include mini-httpd_1.30.orig.tar.gz in your upload, a different version might already be known to the archive software. #2 > 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. > Just to recap here: following our previous mail's logic, namely: 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 This results in: worker@Debian:~/git/mini-httpd$ git diff origin/master..HEAD diff --git a/debian/changelog b/debian/changelog index ad0073c..73a286b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -14,7 +14,7 @@ mini-httpd (1.30-4) unstable; urgency=medium * Clarified NCSA origins of mini-httpd htpasswd* by adding a corresponding copyright entry with proper attribution. - -- Alexandru Mihail Tue, 04 Jul 2023 23:49:19 +0300 + -- Alexandru Mihail Tue, 05 Sep 2023 01:29:43 +0300 mini-httpd (1.30-3) unstable; urgency=medium worker@Debian:~/git/mini-httpd$ git show origin commit 1c8f17316e8f1f787c478e0428cfdd27b5c9ca1b (origin/master, origin/HEAD) Merge: d736d78 acfc103 Author: Nicholas D Steeves <2201-s...@users.noreply.salsa.debian.org> Date: Wed Aug 23 21:50:16 2023 + Merge branch 'master' into 'master' Merge 1.30-4 release from new maintainer See merge request debian/mini-httpd!2 Pushing tag & master would just amount to: git push origin debian/1.30-4 git push ? Going to sleep, looking forward to hearing from you tomorrow (its 3AM here :D) Have a nice $part_of_day ! > Congratulations, and enjoy your holidays! :) > > Cheers, > Nicholas Thank you ! All the best, Alexandru signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Nicholas, > 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. Damn, it seems the web GUI tricked us both..I was convinced I sorted that out (GPG was already O.K but mail was not *sigh*) Many thanks for your attention to detail :D > # 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 > I fixed my git config and redid the tag as discussed above > 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 > Cheers, > Nicholas > Have a great one, Alexandru > 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. Did that too, no reason not to :) signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello, Gently pinging about my last mail. Sorry for nagging; I think we both want this release finalized and to crack a cold one admiring our work :) > 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. I've already created a GPG signed tag > accessible at: > https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4 > > The commit is not visible in the previous MR: > https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2? > > Is there something I've glanced over here ? > Otherwhise, the commit & tag are per your requirements. Have a great one Nicholas ! Alexandru > signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Nicholas, > 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. Indeed, it was quite a lot of work, but it is for a good cause ! :) > 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: > 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. 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. I've already created a GPG signed tag accessible at: https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4 The commit is not visible in the previous MR: https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2? Is there something I've glanced over here ? Otherwhise, the commit & tag are per your requirements. > Cheers, > Nicholas Have a great day ! Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello, Nicholas ! >Thanks again for your work! I submitted a second (I think we're at >the >second one) gitlab review here: Fixes for review items are commited :) I cannot yet review the untested patch about VHOSTING as I cannot replicate (or maybe miss something in my mini_httpd.conf ?) the bug. I'd deffer it to next upload if you don't happen to have some time/knowledge about ancient multihosting :) >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? Cheers, we're getting close :D ! Alexandru signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
I committed the fixes, after reading your review on salsa. Please take a look at https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2/diffs?commit_id=f89931149c0c7105585061cbfbdcc2cd2ac212b5 when you can. Cheers, Alexandru signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Nicholas, I was in the process of writing this mail when I just saw your gitlab activity. >+1 and where can I see this new work? git checkout 1.5c git diff 1.4.2 -- conf/httpd.conf-dist | grep -B 2 -A 4 " VirtualHost " +#BindAddress 127.0.0.1 + +# VirtualHost allows you to look differently depending on the hostname you +# are called by. The parameter must be either an IP address or a hostname +# that maps to a single IP address. Most of the normal httpd.conf commands +# are available, as well as the ability to denote a special ResourceConfig +# file for this host. +# You can also specify an error level with this setting, by denoting the +# VirtualHost as Optional or Required. + + +DocumentRoot /local +ServerName localhost.ncsa.uiuc.edu But this does not matter anymore : "We discussed this, and you agreed that 1.4.2 just confuses things. Just stick with 1.5." I agree and I remember. "I wonder if he used the not-for-export version, and then didn't edit htpasswd* ?" This seems like the case to me too.. I will work on the other points you've noted and commit again when I'm ready. >If you strongly dislike using web interfaces and prefer patches via >email, please let me know and we'll switch back to email. No, not at all. I actually prefer the web iface for leaving more trivial, small notes on the MR and for replying to them in a more timely manner than a traditional bug mail, it's up to you too. Thanks, Alexandru signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Nicholas, >Remember my Wed, 21 Jun 2023 email (as well as the one with the >diagram)? I remembered this also: >"...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." >I compared a couple of versions and found the same diff. >Hint: Read the commit message for 1.5.1. 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. >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 ? :) Have a great day/night, Alexandru signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Nicholas, MR filed: https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2 >Does that link really work? Are you sure it's not this one? I have no idea what automagically happened, somehow the first one worked for me, but now does not. :) Using yours (thanks!). >The copyright info you've written in this version is immensely >improved :) Thanks, it was your patience and help that got me here too :D >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. I hope everything is in order with my MR. Have a great day and may the Debian swirl girate eternally ! Alexandru Mihail > > > > 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: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
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 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 Portions of htpasswd* were edited by Jef Poskanzer, thus these files remain under BSD-2-clause. 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. 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). 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). >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 ? >I confirmed your signature on this email. Here are some key-related >resources Thanks ! >P.S. Please consider trimming the irrelevant quotation from >correspondences on the BTS. Thank you for the heads up ! :) Thanks for your time and may you have a great day, Alexandru https://bugs.debian.org/1036751 > signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello again, Public key is up: https://keys.openpgp.org/vks/v1/by-fingerprint/CEC2B41FDE5A803B6B08C01471CA8C5A78AA77BB I also imported your key into my gpg keyring. Thanks a lot ! Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Nicholas, No problem about the later reply :) >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): debian/copyright: Files: htpasswd.c htpasswd.1 Copyright: 1993-1994 Rob McCool Copyright: 1997 Jef Poskanzer License: NCSA Comment: htpasswd.c and htpasswd.1 contain significant portions of code from NCSA httpd (cgi-src/util.c, auth/htpasswd.c). 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. 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." git repository: https://github.com/TooDumbForAName/ncsa-httpd/ debian-legal thread: https://lists.debian.org/debian-legal/2023/07/msg1.html DFSGLicenses: https://wiki.debian.org/DFSGLicenses 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. 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. 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. 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 :) >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 hope I haven't missed any points from the discussion here. Have a great day, Alexandru Mihail On Sat, 2023-07-15 at 16:17 -0400, Nicholas D Steeves wrote: > 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 SO
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello again, >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 >? 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 Copyright: 1993-1994 Rob McCool Copyright: 1997 Jef Poskanzer ? 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. 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 : Q: Since Debian is usually quite careful when it comes to legal issues, I'm wondering what the official view point is here? A: The official viewpoint is that the software must meet the requirements of the DFSG. Generally, a CC0-style PD dedication is viewed as sufficient for all jurisdictions, and can satisfy the DFSG if source is available. Q: Jurisdictions for Public Domain? A: We are unaware of a case where a jurisdiction has upheld a copyright claim to a work which has been dedicated to the public domain everywhere. This is a potential theoretical source of problems, but there's enough actual problems with copyright and licensing for us to concentrate our limited time on them instead. Q: Should there be a lintian error if the "license" is Public Domain and a copyright holder is specified? A: No. Q: Should Public Domain perhaps be prohibited in general? A: Definitely not. Best, Alexandru Mihail On Thu, 2023-07-06 at 23:54 +0300, Alexandru Mihail wrote: > 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. > > 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 > ? > > > 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. > > > 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. > :) > > > 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. > > Stay
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
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. 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 ? 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. >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. :) >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. Stay safe and thanks for your time, Alexandru Mihail On Wed, 2023-07-05 at 21:01 -0400, Nicholas D Steeves wrote: > 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 tr
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Nicholas, > 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. I agree, we need to document the NCSA bits. > 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. 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. Anyway, this might settle our ambiguity; I'll come up with a definitive reply once I diff the sources again. 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'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 and have a great day/night ! Alexandru Mihail --- Original Message --- On Tuesday, July 4th, 2023 at 5:24 PM, Nicholas D Steeves wrote: > Hello Alexandru, > > Alexandru Mihail alexandru_mih...@protonmail.ch 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: > > &
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
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. 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. -- Richard Best, Alexandru On Mon, Jun 26, 2023 at 16:41, Alexandru Mihail <[alexandru_mih...@protonmail.ch](mailto:On Mon, Jun 26, 2023 at 16:41, Alexandru Mihail < wrote: > Hello, > Posting the debian-legal original post link here for easy reference: > https://lists.debian.org/debian-legal/2023/06/msg00019.html > > Best, > Alexandru > > --- Original Message --- > On Thursday, June 22nd, 2023 at 4:46 PM, Alexandru Mihail > wrote: > >> Hello Nicholas, >> Hehe, thanks a lot :D >> >> > Wow, you are good at this! :D >> >> I mailed debian-legal and am waiting for a reply. >> Cheers, >> Alex >> >> --- Original Message --- >> On Wednesday, June 21st, 2023 at 9:52 PM, Nicholas D Steeves >> nstee...@gmail.com wrote: >> >> >> >> > Hi Alexandru, >> > >> > Thanks for the ping. I had forgotten that I had a WIP draft. >> > >> > Alexandru Mihail alexandru_mih...@protonmail.ch 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
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello, Posting the debian-legal original post link here for easy reference: https://lists.debian.org/debian-legal/2023/06/msg00019.html Best, Alexandru --- Original Message --- On Thursday, June 22nd, 2023 at 4:46 PM, Alexandru Mihail wrote: > Hello Nicholas, > Hehe, thanks a lot :D > > > Wow, you are good at this! :D > > I mailed debian-legal and am waiting for a reply. > Cheers, > Alex > > --- Original Message --- > On Wednesday, June 21st, 2023 at 9:52 PM, Nicholas D Steeves > nstee...@gmail.com wrote: > > > > > Hi Alexandru, > > > > Thanks for the ping. I had forgotten that I had a WIP draft. > > > > Alexandru Mihail alexandru_mih...@protonmail.ch 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
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Nicholas, Hehe, thanks a lot :D > > Wow, you are good at this! :D > I mailed debian-legal and am waiting for a reply. Cheers, Alex --- Original Message --- On Wednesday, June 21st, 2023 at 9:52 PM, Nicholas D Steeves wrote: > Hi Alexandru, > > Thanks for the ping. I had forgotten that I had a WIP draft. > > Alexandru Mihail alexandru_mih...@protonmail.ch 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
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello, Gently pinging in regard to the NCSA license situation Best, Alexandru On Fri, Jun 16, 2023 at 10:54, Alexandru Mihail <[alexandru_mih...@protonmail.ch](mailto:On Fri, Jun 16, 2023 at 10:54, Alexandru Mihail < wrote: > Hello again Nicholas, > I hope this mail finds you well. > >> > 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 > > (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. > 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. > > 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." > > 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. > > 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. > > UI MAKES NO REPRESENTATIONS ABOUT THE SUITABILITY OF THIS SOFTWARE FOR ANY > PURPOSE. IT IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY. THE UI > SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY THE USERS OF THIS SOFTWARE. > > By using or copying this Software, Licensee agrees to abide by the copyright > law and all other applicable laws of the U.S. including, but not limited to, > export control laws, and the terms of this license. UI shall have the right > to terminate this license immediately by written notice upon Licensee's > breach of, or non-compliance with, any of its terms. Licensee may be held > legally responsible for any copyright infringement that is caused or > encouraged by Licensee's failure to abide by the terms of this license. > > == LICENSE END = > > 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? > 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? > > Kind regards, > Alexandru > > --- Original Message --- > On Monday, June 12th, 2023 at 9:27 PM, Alexandru Mihail > wrote: > >> Hello again, >> >> > I hope that the forests aren't burning, wherever you are. >> > &
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello again Nicholas, I hope this mail finds you well. > > 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 (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. 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. 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." 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. 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. UI MAKES NO REPRESENTATIONS ABOUT THE SUITABILITY OF THIS SOFTWARE FOR ANY PURPOSE. IT IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY. THE UI SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY THE USERS OF THIS SOFTWARE. By using or copying this Software, Licensee agrees to abide by the copyright law and all other applicable laws of the U.S. including, but not limited to, export control laws, and the terms of this license. UI shall have the right to terminate this license immediately by written notice upon Licensee's breach of, or non-compliance with, any of its terms. Licensee may be held legally responsible for any copyright infringement that is caused or encouraged by Licensee's failure to abide by the terms of this license. == LICENSE END = 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? 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? Kind regards, Alexandru --- Original Message --- On Monday, June 12th, 2023 at 9:27 PM, Alexandru Mihail wrote: > Hello again, > > > I hope that the forests aren't burning, wherever you are. > > > > Take care, > > > Oh damn, I really hope you and your family are going to be safe if you're > facing wildfires near you.. > Here in Eastern Europe it's not really that much of an issue, thankfully. > > > 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. > > It's pretty much a mistery to me too, seems like the original "License" if > you could call it that is nothing more than: > " > Copyright (C) 2022 by J
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello again, > I hope that the forests aren't burning, wherever you are. > > Take care, Oh damn, I really hope you and your family are going to be safe if you're facing wildfires near you.. Here in Eastern Europe it's not really that much of an issue, thankfully. > 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. It's pretty much a mistery to me too, seems like the original "License" if you could call it that is nothing more than: " Copyright (C) 2022 by Jef Poskanzer . All rights reserved. You may use this software however you like as long as you keep my name on it and don't sue me. " This is the current license (Author:So what does the legalese mean? This is a modified version of the BSD license). I'll try to dig a bit more about original source code license, if any other than the above was ever present :) Yeah, archeology indeed, I've had the same issue,believe it or not, when porting a certain version of a vintage telnet library from the 80s on modern hardware. Fun times, indeed Stay safe and good luck ! Alexandru --- Original Message --- On Monday, June 12th, 2023 at 9:01 PM, Nicholas D Steeves wrote: > Hello Alexandru, > > Alexandru Mihail alexandru_mih...@protonmail.ch 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
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
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. > > > 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 > speaking these patch fixups aren't release critical, and you can ignore > them if you'd like. I will fix them, it's fine :) Also, I uploaded again to mentors last night. Thanks and farewell, Alexandru --- Original Message --- On Saturday, June 10th, 2023 at 6:52 PM, Nicholas D Steeves wrote: > Hi Alexandru, > > Alexandru Mihail alexandru_mih...@protonmail.ch 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
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello Nicholas, > 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. Thanks, I hope so as well > 1. What is the purpose of the dh_installsystemd override? (hint: see the > dh_installsystemd man page about --name). I missed that, fixed now, thanks ! > 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 ? > 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. > 4. Does everything in your changelog entry still accurately reflect the > package? (ie "not started by default"). Fixed, thank you ! > 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 :) > 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 :) Have a great day, Alexandru --- Original Message --- On Tuesday, June 6th, 2023 at 8:49 PM, Nicholas D Steeves wrote: > Hi Alexandru, > > Alexandru Mihail alexandru_mih...@protonmail.ch 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.
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hello again, Uploaded again to mentors. 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. I also added Upstream-Contact into debian/copyright and stripped some trailing whitelines. Package should be lintian O.K. now. 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 ? Best, Alexandru --- Original Message --- On Saturday, June 3rd, 2023 at 12:59 PM, Alexandru Mihail wrote: > Hi, > Thanks everyone for the input ! > Indeed the forking service type is the correct one for this package as > daemon() is called as part of the initialization sequence. (if daemon() is > not available, plain fork() is called anyway) > I've adjusted debian/rules, taking into consideration Lorenzo's advice, > thanks Lorenzo ! > > > 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'd prefer waiting for push permission, for sure; if that is not possible in > the near future, I can also fork and file requests. > > Have a great weekend! > Alexandru > > --- Original Message --- > On Saturday, June 3rd, 2023 at 1:58 AM, Nicholas D Steeves nstee...@gmail.com > wrote: > > > > > Alexandru Mihail alexandru_mih...@protonmail.ch 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
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi, Thanks everyone for the input ! Indeed the forking service type is the correct one for this package as daemon() is called as part of the initialization sequence. (if daemon() is not available, plain fork() is called anyway) I've adjusted debian/rules, taking into consideration Lorenzo's advice, thanks Lorenzo ! > 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'd prefer waiting for push permission, for sure; if that is not possible in the near future, I can also fork and file requests. Have a great weekend! Alexandru --- Original Message --- On Saturday, June 3rd, 2023 at 1:58 AM, Nicholas D Steeves wrote: > Alexandru Mihail alexandru_mih...@protonmail.ch 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
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Nicholas, 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. 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). mini-httpd already depends on init-system-helpers so that might not be an issue, I'll have to test on a non systemd system. As for the old bugs, at least #491078 and #1018900 are stil present, I shall test a user submitted patch for the first one. I'll also create a salsa account soon. I hope this mail finds you well ! Kind regards, Alexandru Mihail On Wed, May 31, 2023 at 00:53, Alexandru Mihail <[alexandru_mih...@protonmail.ch](mailto:On Wed, May 31, 2023 at 00:53, Alexandru Mihail < wrote: > 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 >>
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 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
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
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mini-httpd": * 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 Section : web The source builds the following binary packages: mini-httpd - Small HTTP server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mini-httpd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-4.dsc Changes since the last upload: mini-httpd (1.30-4) unstable; urgency=medium . * New maintainer. (Closes: #927950) * Added missing newline in the rules file * Bumped Standards-Version to 4.5.1 Regards, -- Alexandru Mihail
Bug#927950: ITA mini-httpd
retitle 927950 ITA: mini-httpd -- Small HTTP server Hi, I would like to adopt the mini-httpd deb project. If at all of interest, I am already a member of the DebianWiki team: https://wiki.debian.org/AlexandruMihail Regards, Alexandru
