Re: Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Please mail to debian-mentors-requ...@lists.debian.org with a subject unsubscribe. Em 05/03/2024 19:50, Fred escreveu: PLEASE REMOVE ME FROM ALL LISTS! I tried to remove myself. It didn't work. I tried to contact the list admin. I did not get an answer. I'M GONNA SPAM YOUR LISTS UNTIL YOU REMOVE ME! On 05.03.24 19:29, Lucas Castro wrote: Em 05/03/2024 08:09, Daniel Gröber escreveu: Hi Lucas, On Mon, Feb 19, 2024 at 04:50:27PM -0300, Lucas Castro wrote: * Package name : foolsm Are you sure you want to change the source package name? Doing so fractures the history of the package on tracker.d.o and it's not really necessary. The upstream has changed software name but it's a good point about tracker.d.o. I'll take a look at some project that has changed the name too, BTW I already looked at some of them but not checked the source package name. Quick package review: - d/postinst: I don't think it's useful to print the message about editing the config. I've only seen packages do that in special circumstances, do you have a justification for it being necessary here? Really, really not. I really would like improve that, I guess to write good doc and manual pages is enough. - You declare Replaces+Conflicts on lsm but you don't seem to take any care for the new binary package to actually be compatible with the old one since the config location changed. I'm in doubt, when the old config exist, if set dpkg to copy the old config from old location to the new one or if I just print/show up a message to users notifying about path update requirement. If it's good/allowed do the copy, it could be applied in postinst. I think print/show up message is rightest way. - d/foolsm.init: Still has the old $CONFIG path That's true, I'll update and re-upload. --Daniel OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Remove package from unstable?
PLEASE REMOVE ME FROM ALL LISTS! I tried to remove myself. It didn't work. I tried to contact the list admin. I did not get an answer. I'M GONNA SPAM YOUR LISTS UNTIL YOU REMOVE ME! On 05.03.24 23:30, Preuße, Hilmar wrote: On 04.03.2024 02:09, Loren M. Lang wrote: Hi, Have you just tried passing through -S from gbp? As in "gbp buildpackage -S"? It might not work if you have set a different builder like schroot, but you can just pass --git-builder=debuild or similar in that case. Yes, I tried that option "-S", but it did not give me a source package. However I found the suitable command line later in gbp-buildpackage(1): gbp buildpackage --git-upstream-tree=upstream_2.10.08+ds --git-no-create-orig --git-export-dir=/tmp --git-builder=/bin/true --git-no-pbuilder --git-no-purge , which gives me a source tree in /tmp, which I can feed to "dpkg-buildpackage ... -S" to get a source package. I still fiddling with the versioning scheme I have to use, but I guess I'll figure that out myself. Hilmar
Re: Bug#1065078: Question about the debian group on Salsa
PLEASE REMOVE ME FROM ALL LISTS! I tried to remove myself. It didn't work. I tried to contact the list admin. I did not get an answer. I'M GONNA SPAM YOUR LISTS UNTIL YOU REMOVE ME! On 05.03.24 21:34, Soren Stoutner wrote: Peter, That’s a good point. When I granted the access I actually selected Maintainer, but for some reason I wrote Developer in the email. On Tuesday, March 5, 2024 5:44:51 AM MST Peter B wrote: On 01/03/2024 04:12, Soren Stoutner wrote: I have created a repository named planner under debian and have granted you Developer access. :) F.Y.I. 'Developer' access on Salsa does not allow to Manage CI/CD settings. If required, 'Maintainer' or 'Owner' is needed to do that. https://docs.gitlab.com/ee/user/permissions.html BTDTGTTS, Peter
Re: Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
PLEASE REMOVE ME FROM ALL LISTS! I tried to remove myself. It didn't work. I tried to contact the list admin. I did not get an answer. I'M GONNA SPAM YOUR LISTS UNTIL YOU REMOVE ME! On 05.03.24 19:29, Lucas Castro wrote: Em 05/03/2024 08:09, Daniel Gröber escreveu: Hi Lucas, On Mon, Feb 19, 2024 at 04:50:27PM -0300, Lucas Castro wrote: * Package name : foolsm Are you sure you want to change the source package name? Doing so fractures the history of the package on tracker.d.o and it's not really necessary. The upstream has changed software name but it's a good point about tracker.d.o. I'll take a look at some project that has changed the name too, BTW I already looked at some of them but not checked the source package name. Quick package review: - d/postinst: I don't think it's useful to print the message about editing the config. I've only seen packages do that in special circumstances, do you have a justification for it being necessary here? Really, really not. I really would like improve that, I guess to write good doc and manual pages is enough. - You declare Replaces+Conflicts on lsm but you don't seem to take any care for the new binary package to actually be compatible with the old one since the config location changed. I'm in doubt, when the old config exist, if set dpkg to copy the old config from old location to the new one or if I just print/show up a message to users notifying about path update requirement. If it's good/allowed do the copy, it could be applied in postinst. I think print/show up message is rightest way. - d/foolsm.init: Still has the old $CONFIG path That's true, I'll update and re-upload. --Daniel
Re: Bug#1065507: RFS: netconsd/0.4-1 [ITP] -- Netconsole Daemon
PLEASE REMOVE ME FROM ALL LISTS! I tried to remove myself. It didn't work. I tried to contact the list admin. I did not get an answer. I'M GONNA SPAM YOUR LISTS UNTIL YOU REMOVE ME! On 05.03.24 19:15, Michel Lind wrote: Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "netconsd": * Package name : netconsd Version : 0.4-1 Upstream contact : https://github.com/facebook/netconsd/issues * URL : https://github.com/facebook/netconsd * License : BSD-3-clause * Vcs : https://salsa.debian.org/michel/netconsd Section : admin The source builds the following binary packages: netconsd - Netconsole Daemon To access further information about this package, please visit the following URL: https://mentors.debian.net/package/netconsd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/n/netconsd/netconsd_0.4-1.dsc Changes for the initial release: netconsd (0.4-1) unstable; urgency=medium . * Initial release. (Closes: #1065462) Regards,
Re: FWD: Copyright in LGPL projects
PLEASE REMOVE ME FROM ALL LISTS! I tried to remove myself. It didn't work. I tried to contact the list admin. I did not get an answer. I'M GONNA SPAM YOUR LISTS UNTIL YOU REMOVE ME! On 05.03.24 22:15, Alan M Varghese wrote: Soren, ... but it is also perfectly fine to ship them in the same file. I think what Wookey is referring to is that GPL and LGPL licenses contain a line that says something like: 'Copyright (C) 1991, 1999 Free Software Foundation, Inc.' I believe this copyright refers to the text of the license itself. Hence, it might not be a good idea to include a second copyright in this same file. So, including the copyright and license in the same file can work for licenses like MIT, BSD etc which does not mention a copyright of its own, and not for GPL-like licenses which includes a copyright line as part of the license. Anyways, upstream author has added a new file called "COPYRIGHT" in the root of the project[1] that mentions the copyright years, owner and the license used. Based on all our discussion so far, I understand this should be acceptable for our purposes in Debian. [1] https://github.com/hyprwm/hyprlang/blob/main/COPYRIGHT Alan On 3/6/24 02:19, Soren Stoutner wrote: Wookey, On Tuesday, March 5, 2024 2:51:10 AM MST Wookey wrote: On 2024-03-04 11:19 -0700, Soren Stoutner wrote: Alan, These are good questions. 1. Yes, there must be a copyright statement. Only the person, people, group, or organization that holds the copyright can issue a license for other people to use the work. So, you must have someone claiming a copyright or they do not have the legal ability to release the work to others under the LGPL. But what requires that to be in the source tarball? Copyright is intrinsic in the authors, it doesn't require a statement to create it. Said authors _do_ need to specify a licence (and the LGPL requires that licence text to be shipped in the source (I think, although I could only actually find this requirement for a 'Combined work' and in the FAQ just now)). _Debian_ requires a copyright statement (in the copyright file) so we do need to find out from the project what to put, and a statement in the source would be a good way to communicate that, but a notice on the project website or even an email from a representative would also do the job. That is correct. There must be a copyright statement or the license information is not legally valid (because only someone who claims copyright can issue a license). However, it doesn’t expressly need to be in the tarball (see below). That part is simply best practice, because it maintain the copyright information if the project is forked or upstream disappears, which otherwise can be difficult to determine if it was only on a website that is now defunct or in an email sent to a Debian developer who is no longer participating in the project. So, there is a distinction between what is the minimum legal requirement and what is best practice. My recommendation would be that you communicate to the upstream project that they need to include the copyright and licensing information in the root of their repository, preferably all in one file, as a minimum requirement for you to be willing to package their project in Debian. I don't think this is correct. And we should be happy to package anything which is actually free software. We don't get to impose extra requirements before we will package something. As pointed out above, there is a distinction between what is the minimum requirement for packaging in Debian and best practice. I carefully worded point 2 in my original email to state that, if **I** were packaging this software, I would communicate with upstream that if they wanted **me** to package their software in Debian, my minimum requirement would be that they explicitly state the copyright information in the source code. Originally I had a point 3, which I deleted before sending the email, explaining that my personal preference for when I would be willing to package software is higher than Debian’s requirement, and that a website notation or email communication of copyright has been used in some packages in the past, but with the downside described above. I took out point 3 because I felt it muddied the waters, but since the point has been brought up, it is worth discussing. They should put a copy of the LGPL in (in a file called 'COPYING' or 'LICENCE' by convention) (if this isn't done already). A copyright notice for the project should _not_ go in the same file (The LGPL already has one for the LGPL authorship itself, so this is probably the only file in the distribution which should definitiely _not_ have the project copyright notice). It should ideally be a header on at least one source file, (preferably all of them), but could be any README, or even just a notice on the project website, or an email saying ' I must disagree with you on this point. It is
Re: Remove package from unstable?
On 04.03.2024 02:09, Loren M. Lang wrote: Hi, Have you just tried passing through -S from gbp? As in "gbp buildpackage -S"? It might not work if you have set a different builder like schroot, but you can just pass --git-builder=debuild or similar in that case. Yes, I tried that option "-S", but it did not give me a source package. However I found the suitable command line later in gbp-buildpackage(1): gbp buildpackage --git-upstream-tree=upstream_2.10.08+ds --git-no-create-orig --git-export-dir=/tmp --git-builder=/bin/true --git-no-pbuilder --git-no-purge , which gives me a source tree in /tmp, which I can feed to "dpkg-buildpackage ... -S" to get a source package. I still fiddling with the versioning scheme I have to use, but I guess I'll figure that out myself. Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: FWD: Copyright in LGPL projects
Soren, ... but it is also perfectly fine to ship them in the same file. I think what Wookey is referring to is that GPL and LGPL licenses contain a line that says something like: 'Copyright (C) 1991, 1999 Free Software Foundation, Inc.' I believe this copyright refers to the text of the license itself. Hence, it might not be a good idea to include a second copyright in this same file. So, including the copyright and license in the same file can work for licenses like MIT, BSD etc which does not mention a copyright of its own, and not for GPL-like licenses which includes a copyright line as part of the license. Anyways, upstream author has added a new file called "COPYRIGHT" in the root of the project[1] that mentions the copyright years, owner and the license used. Based on all our discussion so far, I understand this should be acceptable for our purposes in Debian. [1] https://github.com/hyprwm/hyprlang/blob/main/COPYRIGHT Alan On 3/6/24 02:19, Soren Stoutner wrote: Wookey, On Tuesday, March 5, 2024 2:51:10 AM MST Wookey wrote: On 2024-03-04 11:19 -0700, Soren Stoutner wrote: Alan, These are good questions. 1. Yes, there must be a copyright statement. Only the person, people, group, or organization that holds the copyright can issue a license for other people to use the work. So, you must have someone claiming a copyright or they do not have the legal ability to release the work to others under the LGPL. But what requires that to be in the source tarball? Copyright is intrinsic in the authors, it doesn't require a statement to create it. Said authors _do_ need to specify a licence (and the LGPL requires that licence text to be shipped in the source (I think, although I could only actually find this requirement for a 'Combined work' and in the FAQ just now)). _Debian_ requires a copyright statement (in the copyright file) so we do need to find out from the project what to put, and a statement in the source would be a good way to communicate that, but a notice on the project website or even an email from a representative would also do the job. That is correct. There must be a copyright statement or the license information is not legally valid (because only someone who claims copyright can issue a license). However, it doesn’t expressly need to be in the tarball (see below). That part is simply best practice, because it maintain the copyright information if the project is forked or upstream disappears, which otherwise can be difficult to determine if it was only on a website that is now defunct or in an email sent to a Debian developer who is no longer participating in the project. So, there is a distinction between what is the minimum legal requirement and what is best practice. My recommendation would be that you communicate to the upstream project that they need to include the copyright and licensing information in the root of their repository, preferably all in one file, as a minimum requirement for you to be willing to package their project in Debian. I don't think this is correct. And we should be happy to package anything which is actually free software. We don't get to impose extra requirements before we will package something. As pointed out above, there is a distinction between what is the minimum requirement for packaging in Debian and best practice. I carefully worded point 2 in my original email to state that, if **I** were packaging this software, I would communicate with upstream that if they wanted **me** to package their software in Debian, my minimum requirement would be that they explicitly state the copyright information in the source code. Originally I had a point 3, which I deleted before sending the email, explaining that my personal preference for when I would be willing to package software is higher than Debian’s requirement, and that a website notation or email communication of copyright has been used in some packages in the past, but with the downside described above. I took out point 3 because I felt it muddied the waters, but since the point has been brought up, it is worth discussing. They should put a copy of the LGPL in (in a file called 'COPYING' or 'LICENCE' by convention) (if this isn't done already). A copyright notice for the project should _not_ go in the same file (The LGPL already has one for the LGPL authorship itself, so this is probably the only file in the distribution which should definitiely _not_ have the project copyright notice). It should ideally be a header on at least one source file, (preferably all of them), but could be any README, or even just a notice on the project website, or an email saying ' I must disagree with you on this point. It is perfectly fine to ship the copyright and the license in two separate files, but it is also perfectly fine to ship them in the same file. I do so in my upstream project linked in a previous email, and Debian does so in debian/copyright. Using a file named LICENSE or
Re: FWD: Copyright in LGPL projects
Wookey, On Tuesday, March 5, 2024 2:51:10 AM MST Wookey wrote: > On 2024-03-04 11:19 -0700, Soren Stoutner wrote: > > Alan, > > > > These are good questions. > > > > 1. Yes, there must be a copyright statement. Only the person, people, > > group, or organization that holds the copyright can issue a license for > > other people to use the work. So, you must have someone claiming a > > copyright or they do not have the legal ability to release the work to > > others under the LGPL. > But what requires that to be in the source tarball? Copyright is > intrinsic in the authors, it doesn't require a statement to create > it. Said authors _do_ need to specify a licence (and the LGPL requires > that licence text to be shipped in the source (I think, although I > could only actually find this requirement for a 'Combined work' and in > the FAQ just now)). > > _Debian_ requires a copyright statement (in the copyright file) so we > do need to find out from the project what to put, and a statement in > the source would be a good way to communicate that, but a notice on > the project website or even an email from a representative would also > do the job. That is correct. There must be a copyright statement or the license information is not legally valid (because only someone who claims copyright can issue a license). However, it doesn’t expressly need to be in the tarball (see below). That part is simply best practice, because it maintain the copyright information if the project is forked or upstream disappears, which otherwise can be difficult to determine if it was only on a website that is now defunct or in an email sent to a Debian developer who is no longer participating in the project. So, there is a distinction between what is the minimum legal requirement and what is best practice. > > My recommendation would be that you communicate to the upstream project that > > they need to include the copyright and licensing information in the root of > > their repository, preferably all in one file, as a minimum requirement for > > you to be willing to package their project in Debian. > > I don't think this is correct. And we should be happy to package > anything which is actually free software. We don't get to impose extra > requirements before we will package something. As pointed out above, there is a distinction between what is the minimum requirement for packaging in Debian and best practice. I carefully worded point 2 in my original email to state that, if **I** were packaging this software, I would communicate with upstream that if they wanted **me** to package their software in Debian, my minimum requirement would be that they explicitly state the copyright information in the source code. Originally I had a point 3, which I deleted before sending the email, explaining that my personal preference for when I would be willing to package software is higher than Debian’s requirement, and that a website notation or email communication of copyright has been used in some packages in the past, but with the downside described above. I took out point 3 because I felt it muddied the waters, but since the point has been brought up, it is worth discussing. > They should put a copy of the LGPL in (in a file called 'COPYING' or > 'LICENCE' by convention) (if this isn't done already). A copyright > notice for the project should _not_ go in the same file (The LGPL > already has one for the LGPL authorship itself, so this is probably > the only file in the distribution which should definitiely _not_ have > the project copyright notice). It should ideally be a header on at least > one source file, (preferably all of them), but could be any README, or > even just a notice on the project website, or an email saying ' I must disagree with you on this point. It is perfectly fine to ship the copyright and the license in two separate files, but it is also perfectly fine to ship them in the same file. I do so in my upstream project linked in a previous email, and Debian does so in debian/copyright. Using a file named LICENSE or COPYING or AUTHORS is fairly standard, but exactly how this is done doesn’t matter as long as both copyright (with years) and license are communicated. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Bug#1065078: Question about the debian group on Salsa
Peter, That’s a good point. When I granted the access I actually selected Maintainer, but for some reason I wrote Developer in the email. On Tuesday, March 5, 2024 5:44:51 AM MST Peter B wrote: > On 01/03/2024 04:12, Soren Stoutner wrote: > > I have created a repository named planner under debian and have granted you > > Developer access. :) > > F.Y.I. 'Developer' access on Salsa does not allow to Manage CI/CD > settings. > > If required, 'Maintainer' or 'Owner' is needed to do that. > https://docs.gitlab.com/ee/user/permissions.html > > BTDTGTTS, > Peter -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Em 05/03/2024 08:09, Daniel Gröber escreveu: Hi Lucas, On Mon, Feb 19, 2024 at 04:50:27PM -0300, Lucas Castro wrote: * Package name : foolsm Are you sure you want to change the source package name? Doing so fractures the history of the package on tracker.d.o and it's not really necessary. The upstream has changed software name but it's a good point about tracker.d.o. I'll take a look at some project that has changed the name too, BTW I already looked at some of them but not checked the source package name. Quick package review: - d/postinst: I don't think it's useful to print the message about editing the config. I've only seen packages do that in special circumstances, do you have a justification for it being necessary here? Really, really not. I really would like improve that, I guess to write good doc and manual pages is enough. - You declare Replaces+Conflicts on lsm but you don't seem to take any care for the new binary package to actually be compatible with the old one since the config location changed. I'm in doubt, when the old config exist, if set dpkg to copy the old config from old location to the new one or if I just print/show up a message to users notifying about path update requirement. If it's good/allowed do the copy, it could be applied in postinst. I think print/show up message is rightest way. - d/foolsm.init: Still has the old $CONFIG path That's true, I'll update and re-upload. --Daniel OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065507: RFS: netconsd/0.4-1 [ITP] -- Netconsole Daemon
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "netconsd": * Package name : netconsd Version : 0.4-1 Upstream contact : https://github.com/facebook/netconsd/issues * URL : https://github.com/facebook/netconsd * License : BSD-3-clause * Vcs : https://salsa.debian.org/michel/netconsd Section : admin The source builds the following binary packages: netconsd - Netconsole Daemon To access further information about this package, please visit the following URL: https://mentors.debian.net/package/netconsd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/n/netconsd/netconsd_0.4-1.dsc Changes for the initial release: netconsd (0.4-1) unstable; urgency=medium . * Initial release. (Closes: #1065462) Regards, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature
Bug#1065504: RFS: shotwell/0.32.6-1 -- digital photo organizer
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "shotwell": * Package name : shotwell Version : 0.32.6-1 Upstream contact : Jim Nelson * URL : https://wiki.gnome.org/Apps/Shotwell * License : LGPL-2.1, BSD-3-Clause * Vcs : https://git.jff.email/cgit/shotwell.git Section : gnome The source builds the following binary packages: shotwell - digital photo organizer shotwell-common - digital photo organizer - common files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/shotwell/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.32.6-1.dsc or from git https://git.jff.email/cgit/shotwell.git/?h=release%2Fdebian%2F0.36.6-1 Changes since the last upload: shotwell (0.32.6-1) unstable; urgency=medium . * New upstream release (Closes: #1064455). - debian/shotwell.install: + Install new shotwell-authenticator. * debian/copyright: - Add year 2024 to myself. - Refresh for the new release. * debian/control: - Add Build Depend python3-distutils. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Jörg Frings-Fürst D-54470 Lieser git: https://git.jff.email/cgit/ Skype:jff-skype@jff.email Jami: joergfringsfuerst Telegram: @joergfringsfuerst Matrix: @joergff:matrix.snct-gmbh.de My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Re: Bug#1065078: Question about the debian group on Salsa
On 01/03/2024 04:12, Soren Stoutner wrote: I have created a repository named planner under debian and have granted you Developer access. :) F.Y.I. 'Developer' access on Salsa does not allow to Manage CI/CD settings. If required, 'Maintainer' or 'Owner' is needed to do that. https://docs.gitlab.com/ee/user/permissions.html BTDTGTTS, Peter
Bug#1065102: RFS: serioussam/1.10.6d+dfsg-1 [ITP] -- open source first person shooter developed by Croteam
Dear mentors. I rewrote Debian patches to support the content of the demo version of the game. The engine now supports the content of the demo version of the game. When the game starts, the engine determines the installed game content, and if it finds content from the demo version, it turns on the mode for using the demo version of the content. This allows games to be tested by anyone who does not have a copy of the original game. A demo version of the game can be obtained from many places.The most convenient way is to download using the wget from the WebArchive. To install content from the demo version of the game, open a terminal and run the following commands: sudo apt install p7zip wget https://archive.org/download/SeriousSamDemo/SeriousSamDemo.exe wget https://archive.org/download/SeriousSamPatches/serioussampatch105_usa.exe 7z x SeriousSamDemo.exe 7z x -y serioussampatch105_usa.exe mkdir ~/.serioussam cp -ax Disk1/* ~/.serioussam rm -fr Disk1 wget https://archive.org/download/serioussamsedemo/SeriousSamSEDemo.exe wget https://archive.org/download/SeriousSamPatches/secondencounterpatch107_usa.exe 7z x SeriousSamSEDemo.exe 7z x -y secondencounterpatch107_usa.exe mkdir ~/.serioussamse cp -ax Disk1/* ~/.serioussamse rm -fr Disk1 When you first launch the game, goto Menu -> Options -> Execute Addons and select the default option. The demo version uses old settings scripts. New ones you can take here: https://github.com/tx00100xt/SeriousSamClassic Just rewrite the Scripts directory replacing the files. I also added how to install the content of the demo version of the game in README.Debian, README.source and manpages. Best Regards, Alexander Pavlov.
Bug#1065205: RFS: serioussam-vk/1.10.6d+dfsg-1 [ITP] -- Linux port of Serious Sam Classic with Vulkan support
Dear mentors. I rewrote Debian patches to support the content of the demo version of the game. The engine now supports the content of the demo version of the game. When the game starts, the engine determines the installed game content, and if it finds content from the demo version, it turns on the mode for using the demo version of the content. This allows games to be tested by anyone who does not have a copy of the original game. A demo version of the game can be obtained from many places. The most convenient way is to download using the wget from the WebArchive. To install content from the demo version of the game, open a terminal and run the following commands: sudo apt install p7zip wget https://archive.org/download/SeriousSamDemo/SeriousSamDemo.exe wget https://archive.org/download/SeriousSamPatches/serioussampatch105_usa.exe 7z x SeriousSamDemo.exe 7z x -y serioussampatch105_usa.exe mkdir ~/.serioussam-vk cp -ax Disk1/* ~/.serioussam-vk rm -fr Disk1 wget https://archive.org/download/serioussamsedemo/SeriousSamSEDemo.exe wget https://archive.org/download/SeriousSamPatches/secondencounterpatch107_usa.exe 7z x SeriousSamSEDemo.exe 7z x -y secondencounterpatch107_usa.exe mkdir ~/.serioussamse-vk cp -ax Disk1/* ~/.serioussamse-vk rm -fr Disk1 When you first launch the game, goto Menu -> Options -> Execute Addons and select the default option. The demo version uses old settings scripts. New ones you can take here: https://github.com/tx00100xt/SeriousSamClassic-VK Just rewrite the Scripts directory replacing the files. I also added how to install the content of the demo version of the game in README.Debian, README.source and manpages. Best Regards, Alexander Pavlov.
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Hi Lucas, On Mon, Feb 19, 2024 at 04:50:27PM -0300, Lucas Castro wrote: > * Package name : foolsm Are you sure you want to change the source package name? Doing so fractures the history of the package on tracker.d.o and it's not really necessary. Quick package review: - d/postinst: I don't think it's useful to print the message about editing the config. I've only seen packages do that in special circumstances, do you have a justification for it being necessary here? - You declare Replaces+Conflicts on lsm but you don't seem to take any care for the new binary package to actually be compatible with the old one since the config location changed. - d/foolsm.init: Still has the old $CONFIG path --Daniel signature.asc Description: PGP signature
Re: Rebuilding Debian packages
On 2024-03-04 08:18 +0200, Tommi Höynälänmaa wrote: > Hello > > If the dependency graph of a binary package in the unstable distribution is > changed (e.g. because of the 64-bit time_t transition) shall the binary > package be rebuilt in the distribution? Any package that has a direct dependency on a library package changing name due to the t64 transition will be rebuilt by the team managing the transition (once everything is available). i.e. package maintainers don't have to do anything specific. And this only applies to direct dependencies (on libraries), not other sorts of dependency, nor packages furtuer down the tree. I hope that answers your question? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: FWD: Copyright in LGPL projects
On 2024-03-04 11:19 -0700, Soren Stoutner wrote: > Alan, > > These are good questions. > > 1. Yes, there must be a copyright statement. Only the person, people, > group, > or organization that holds the copyright can issue a license for other people > to use the work. So, you must have someone claiming a copyright or they do > not have the legal ability to release the work to others under the LGPL. But what requires that to be in the source tarball? Copyright is intrinsic in the authors, it doesn't require a statement to create it. Said authors _do_ need to specify a licence (and the LGPL requires that licence text to be shipped in the source (I think, although I could only actually find this requirement for a 'Combined work' and in the FAQ just now)). _Debian_ requires a copyright statement (in the copyright file) so we do need to find out from the project what to put, and a statement in the source would be a good way to communicate that, but a notice on the project website or even an email from a representative would also do the job. > My recommendation would be that you communicate to the upstream project that > they need to include the copyright and licensing information in the root of > their repository, preferably all in one file, as a minimum requirement for > you > to be willing to package their project in Debian. I don't think this is correct. And we should be happy to package anything which is actually free software. We don't get to impose extra requirements before we will package something. They should put a copy of the LGPL in (in a file called 'COPYING' or 'LICENCE' by convention) (if this isn't done already). A copyright notice for the project should _not_ go in the same file (The LGPL already has one for the LGPL authorship itself, so this is probably the only file in the distribution which should definitiely _not_ have the project copyright notice). It should ideally be a header on at least one source file, (preferably all of them), but could be any README, or even just a notice on the project website, or an email saying ' Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1065476: RFS: omd/1.3.2-1 [ITP] -- Markdown frontend in pure OCaml
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "omd": * Package name : omd Version : 1.3.2-1 Upstream contact : [fill in name and email of upstream] * URL : https://github.com/ocaml/omd * License : ISC * Vcs : https://salsa.debian.org/vimerbf-guest/omd Section : ocaml The source builds the following binary packages: omd - Markdown frontend in pure OCaml (tools) libomd-ocaml-dev - Markdown frontend in pure OCaml (development) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/omd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/o/omd/omd_1.3.2-1.dsc Changes for the initial release: omd (1.3.2-1) UNRELEASED; urgency=low . * Initial release. (Closes: #1065417) -- Regards, -- Bo YU signature.asc Description: PGP signature
