Re: Bookworm backport status
Hi Paul, On 21/06/2023 06:16, Paul Wise wrote: On Mon, 2023-06-19 at 14:40 +0200, Alec Leamas wrote: Anyone which can shed some light on the bookworm-backports status and perhaps also where my upload ended up? I suggest checking the debian-backports mailing list archives and if the answer isn't there, ask on the list or on the IRC channel. Ah... thanks for that pointer! Still confused, but on a higher level. Will sort it out there. Cheers! --alec
Upload to bookworm-backports
Dear mentors, I'm trying to upload openpcn to bookworm-backports. Since I'm just a DM, I need a sponsor to upload the first package heading into the NEW queue. However, bookworm-backports is yet not accepted by the mentors infrastructure. Is there any other way I could get some help with this upload? The package is available at https://gitlab.com/leamas/opencpn in the branch debian/bookworm-backports. The delta against sid is as expected minimal. Cheers! --alec
Re: Upload to bookworm-backports
Hi, El 21/06/23 a las 14:28, Alec Leamas escribió: > Dear mentors, > > I'm trying to upload openpcn to bookworm-backports. Since I'm just a DM, I > need a sponsor to upload the first package heading into the NEW queue. > > However, bookworm-backports is yet not accepted by the mentors > infrastructure. Is there any other way I could get some help with this > upload? > Please read this first: https://lists.debian.org/debian-backports/2023/06/msg00017.html Cheers, -- Santiago signature.asc Description: PGP signature
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. >> > >> > 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 d
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, Thanks for the ping. I had forgotten that I had a WIP draft. Alexandru Mihail writes: >> > remember the original NCSA httpd licence. P.S. It feels like >> > archaeology to find missing documentation for something from the > > dawn >> > of > > Eureka ! > I present the original NCSA httpd license in its purest form after some > software archeology: > https://web.archive.org/web/20060830015540/http://hoohoo.ncsa.uiuc.edu/docs-1.5/Copyright.html Wow, you are good at this! :D > (NCSA HTTPd Development Team / ht...@ncsa.uiuc.edu / Last Modified 08-01-95) > == LICENSE START === > NCSA HTTPd Server > Software Development Group > National Center for Supercomputing Applications > University of Illinois at Urbana-Champaign > 605 E. Springfield, Champaign IL 61820 > ht...@ncsa.uiuc.edu > > Copyright (C) 1995, Board of Trustees of the University of Illinois > > NCSA HTTPd software, both binary and source (hereafter, Software) is > copyrighted by The Board of Trustees of the University of Illinois (UI), and > ownership remains with the UI. > > The UI grants you (hereafter, Licensee) a license to use the Software > for academic, research and internal business purposes only, without a > fee. Hmm, the above grant looks like it may not be DFSG compatible. Do you see how? https://www.debian.org/social_contract#guidelines or https://wiki.debian.org/DebianFreeSoftwareGuidelines or with a story https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines > Licensee may distribute the binary and source code (if released) to third > parties provided that the copyright notice and this statement appears on all > copies and that no charge is associated with such copies. If Rob McCool didn't ever relicense the part of NCSA HTTPd that is part of mini-httpd, then it looks like we might need to provide this notice, and upstream mini-httpd should have been doing so. > Licensee may make derivative works. However, if Licensee distributes any > derivative work based on or derived from the Software, then Licensee will (1) > notify NCSA regarding its distributing of the derivative work, and (2) > clearly notify users that such derivative work is a modified version and not > the original NCSA HTTPd Server software distributed by the UI by including a > statement such as the following: > > "Portions developed at the National Center for Supercomputing > Applications at the University of Illinois at Urbana-Champaign." Is this DFSG compatible? > Any Licensee wishing to make commercial use of the Software should contact > the UI, c/o NCSA, to negotiate an appropriate license for such commercial > use. Commercial use includes (1) integration of all or part of the source > code into a product for sale or license by or on behalf of Licensee to third > parties, or (2) distribution of the binary code or source code to third > parties that need it to utilize a commercial product sold or licensed by or > on behalf of Licensee. And is this DFSG compatible? > Any commercial company wishing to use the software as their commercial World > Wide Web server and are not redistributing the software need not commercially > license the software but can use it free of charge. and this? Note the clause "and are not redistributing the software". So you can't sell copies of this software? > Should we include a mention of this under debian/copyright stating > something along the lines of 'parts of mini_httpd.c under NCSA HTTPD > and include a copy of the license somewhere? Most likely, yes, but the bigger issue is if this license is not DFSG-compatible. > As far as I could dig, this is the license which should be attributed in our > case. This is the 1.15 htttpd license, and with 99.% certainty, this was > the chunk of code still found in mini_httpd.c. The logic is, NCSA httpd had, > historically, two licenses (chronologically): one open and one proprietary. > mini_httpd is a fork of the open one, that we can be sure of. I think there > is little reason to involve debian-legal at this point. > What's your opinion here? Thank you for the note about this history. I didn't know NCSA httpd had two licenses. I wonder if there was later a change to "everything that was 'open' is now permissively licensed" at some point? If the chunk of code is still big enough and original enough to meet the minimum threshold for originality, then yes, the original copyright and license would apply; however, I think this would mean that we need to find documentation that someone contacted the U of I (and/or Rob McCool). A quick query of tldrlegal shows an NCSA license that is shorter and more permissive: https://www.tldrlegal.com/license/university-of-illinois-ncsa-open-source-license-ncsa I suspect that NCSA httpd may have been relicensed to this shorter version. Yeah, this seems to be a case where it's worth contacting debian-legal, especially given those bits that don'
Re: Packaging git submodule as multi upstream tarballs?
I'm not sure if uscan can do it, but for meshlab, as they don't tag the submodule when they release the main project, I have a script that updates the submodule commit using the github API. It's more clunky than I'd like, but I am not sure exactly how to fix this. It parses the version out of debian/changelog to find the main repo revision. https://salsa.debian.org/science-team/meshlab/-/blob/master/debian/get-orig-source.sh Ryan On Tue, Jun 13, 2023 at 10:45 AM Daniel Gröber wrote: > Hi Mentors, > > I'm working on packaging prjtrellis[1] which has a git submodule that is > required for building. My plan is to use dpkg-source's multi upstream > tarball support to do this. > > [1]: https://github.com/YosysHQ/prjtrellis > > I'm wondering if a) this is a good idea and 2) how to get uscan to download > the precise commit referenced in the main package instead of the "latest" > version. Is this even possible? > > I have a similar situation in my yosys package already (it has a > berkeley-abc submodule) but since berkeley-abc is just a seperate package I > just package the latest berkeley-abc commit and pray it doesn't diverge > from what upstream's release uses too much. This is less than ideal > obviously. > > Any input would be appreciated, > --Daniel > >
Re: Packaging git submodule as multi upstream tarballs?
Hi Ryan, On Wed, Jun 21, 2023 at 03:07:24PM -0500, Ryan Pavlik wrote: > I'm not sure if uscan can do it, I did get it working but it's exceedingly cludgy. I have to use mode=git for the second component since uscan can't just download master.tar.gz AFACT (it's at a static location not linked from a page). I also have to set the version to "ignore" instead of "same" as the generated git commit based version is obviously not going to match the main project tag. Further I have to disable the uupdate hook since 1) it would have to be attached to the second component to work properly but 2) it gets passed the generated git version which again doesn't match the main tarball so it barfs as it can't find the orig.tar. What a mess. So I have this now: version=4 opts=filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%,\ https://github.com/YosysHQ/prjtrellis/tags \ (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian opts=mode=git,\ component=database \ https://github.com/YosysHQ/prjtrellis-db.git \ HEAD ignore > but for meshlab, as they don't tag the submodule when they release the > main project, I have a script that updates the submodule commit using the > github API. It's more clunky than I'd like, but I am not sure exactly how > to fix this. It parses the version out of debian/changelog to find the > main repo revision. > https://salsa.debian.org/science-team/meshlab/-/blob/master/debian/get-orig-source.sh I was looking for an API endpoint to get the submodule commit actually, this way at least I don't have to do a temp clone just to get it. This is super useful, thanks! --Daniel
