Bug#1009304: ITP: libjxl-testdata -- Data test suite for libjxl
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libjxl-testdata Version : 0.1 Upstream Author : libjxl authors * URL : https://github.com/libjxl/testdata * License : BSD Programming Lang: None Description : Data test suite for libjxl Description: JPEG XL Image Coding System - "JXL" (testdata) The JPEG XL Image Coding System (ISO/IEC 18181) is a lossy and lossless image compression format. It has a rich feature set and is particularly optimized for responsive web environments, so that content renders well on a wide range of devices. Moreover, it includes several features that help transition from the legacy JPEG format. . This package installs the testdata files for libjxl. -- Upstream has recently remove the testdata from the main repo. Replicate the split at Debian package level. This will allow distributing updated libjxl release without updating at the same time libjxl-testdata (~19M). This will be team maintained: Debian PhotoTools Maintainers
Rust libraries left broken
Quoting Sylvestre Ledru (2022-04-11 09:34:48) > Le 11/04/2022 à 01:14, Jonas Smedegaard a écrit : > > Quoting Sylvestre Ledru (2022-04-10 22:15:47) > >> Maybe you should join the team, commit there and follow the process > >> for our packages? :) > > > > Thanks for the suggestion, but I decline the offer: > > > > I am not interested in joining a team where packages should be > > tracked in one giant git repo. > > > > If I am mistaken and that's not a policy in the Rust team - or if > > the team might consider changing that policy, then I would gladly > > join. > It is and it probably won't change (too hard)) > > I will then have to ask you to stop doing NMU without delays as it > will make our life harder. :( Thanks, your kind request is duly noted. Rust team [discouraging nmudiff] and [not using our BTS], and leaving packages [very broken], makes our lives harder as well. :-( - Jonas [discourage nmudiff]: See https://bugs.debian.org/998347#28 [not using our BTS]: See https://bugs.debian.org/969609#10 [very broken]: Totally broken for months despite fix being simple (and notably *not* needing to involve NEW queue): * rust-rustls: 6 months FTBFS, https://bugs.debian.org/1007749 * rust-sha-1: 16 months FTBFS, https://bugs.debian.org/1009123 * rust-http: 4 months FTBFS, https://bugs.debian.org/988945 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Another workflow for Rust Was: Rust libraries left broken
Hello Jonas, Hello people in the CC, On Mon, Apr 11, 2022 at 12:34:47PM +0200, Jonas Smedegaard wrote: > Quoting Sylvestre Ledru (2022-04-11 09:34:48) > > Le 11/04/2022 à 01:14, Jonas Smedegaard a écrit : > > > Quoting Sylvestre Ledru (2022-04-10 22:15:47) > > >> Maybe you should join the team, commit there and follow the process > > >> for our packages? :) > > > > > > Thanks for the suggestion, but I decline the offer: > > > > > > I am not interested in joining a team where packages should be > > > tracked in one giant git repo. > > > > > > If I am mistaken and that's not a policy in the Rust team - or if > > > the team might consider changing that policy, then I would gladly > > > join. > > It is and it probably won't change (too hard)) > > > > I will then have to ask you to stop doing NMU without delays as it > > will make our life harder. :( > > Thanks, your kind request is duly noted. > > Rust team [discouraging nmudiff] and [not using our BTS], and leaving > packages [very broken], makes our lives harder as well. :-( > > > - Jonas > > [discourage nmudiff]: See https://bugs.debian.org/998347#28 > > [not using our BTS]: See https://bugs.debian.org/969609#10 > > [very broken]: Totally broken for months despite fix being simple > (and notably *not* needing to involve NEW queue): > * rust-rustls: 6 months FTBFS, https://bugs.debian.org/1007749 > * rust-sha-1: 16 months FTBFS, https://bugs.debian.org/1009123 > * rust-http: 4 months FTBFS, https://bugs.debian.org/988945 > Duly noted and in my very own works: Acknowledge Now that is expressed that things are NOT going smoothly, we should be alert that we NOT gonna fight with each other. Jonas, you have my permission to let it go. Jonas, you have my permission to let it go for now. Jonas, my actual request is that you notice that your report "Debian Rust packaging currently sub-optimal" has been seen. Then interpret it as "no need to add more fuel to the flame war". It is up to us for how long we let cool this down. The cooling down is important for getting a constructive mindset. As in "frustration will block finding a solution". I will leave this "as is" for the next few days. And after that continue with an old idea how to improve Debian Rust packaging. That will be at debian-r...@lists.debian.org I have set Reply-To for it. Groeten Geert Stappers DD -- Silence is hard to parse
Re: secnet_0.6.2_multi.changes REJECTED
Firstly, thanks to ftpmaster for your thorough review of this package.
For transparency, I am CCing this reply to debian-devel, and quoting
the whole of the REJECTED mail. There does not seem to be anything in
here that ought to be private. Please let me know if there is
somewhere better. (I considered -legal but it didn't seem
appropriate.)
FTAOD, I am not, with this mail, asking -devel for a peer review of my
package's licensing status, nor of the ftpmaster decision; just using
-devel as a catch-all list.
Sean Whitton writes ("secnet_0.6.2_multi.changes REJECTED"):
> +--+
> | REJECT reasoning |
> +--+
>
> Another team member identified that there is code in this package
> under a number of different licenses other than GPL-3+, but that is
> not specified in sufficient detail in d/copyright. That contravenes
> both Debian Policy and the terms of those licenses.
My apologies. You are completely correct. I don't understand how I
came to think that the approach I took was sufficient. I guess it is
a long time since I prepared a package with so many different bits and
pieces in it.
> They also pointed out that there is some code from StackOverflow,
> which is not GPL-3+.
I think this is not right? I think you are referring to
`argparseactionnoyes.py`. As I documented in the file header, it is
part of StackOverflow's TOS that contributors grant a CC-BY-SA 4.0
licence for the snippets they upload, which would make the
contributions GPL3+-compatible. My file comment gives the relevant
references. [1]
It seems to me that StackOverflow have chosen this approach (making
the upload licence part of the TOS) precisely to enable people to copy
code fragments out of StackOverflow into their own projects. ISTM
that in (unless it appears that the posting StackOverflow user did not
write the code in question), we should be able to rely on that.
Can you please confirm whether the opinion of the ftpmaster team, that
is not sufficient? If it is not sufficent, I guess I will find
someone to write a clean room implementation of this 22-line class.
> I noticed that b91dec.{php,awk} have no license information at all.
As you observe, these files as provided by upstream do not themselves
contain licence information. But the file base91-c/README (which is
provided by upstream) says, amongst other things:
All source code in this package is released under the terms of the BSD license.
See the file LICENSE for copying permission.
And these files were (according to their copyright notice) written by
the same author and clearly part of the base91-c project. I think
this licence therefore applies also to the files b91dec.{php,awk}.
> +--+
> |Other comments|
> +--+
>
> Your changelog mentions changes to comply with modern Policy, so please
> consider upgrading the standards-version too.
Thank you. I appear to have omitted to do this when doing my
standards update review.
> Shouldn't subdirmk be a separate package?
Well. It is designed to be "git-subtree"'d into one's package. That
is the way the upstream package uses it.
It would be possible to make it a separate package and build-depend on
it, at the cost of some additional work. The upside would be a very
small amount of disk space saving, and largely theoretical saving of
work in case of a need to do a security update for subdirmk (which
seems unlikely to be critical since it's build system software which
is designed to execute its input) - and that all only in the case
where a second package in Debian uses subdirmk.
It seemed me best to me to defer this work until subdirmk becomes more
widely used.
Thanks,
Ian.
[1]
https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=secnet.git;a=blob;f=argparseactionnoyes.py;h=a7eef1c46345be27eaa90a17858bc52a3f60;hb=HEAD
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Re: secnet_0.6.2_multi.changes REJECTED
Quoting Ian Jackson (2022-04-11 18:51:35) > For transparency, I am CCing this reply to debian-devel, and quoting > the whole of the REJECTED mail. There does not seem to be anything in > here that ought to be private. Please let me know if there is > somewhere better. (I considered -legal but it didn't seem > appropriate.) Since you ask: Seems to me that more suitable would be to file an ITP bugreport and post followups like this to that bugreport. Filing an ITP would also serve as an invitation for ftpmasters to post their followup to that bugreport on their own. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Helping Ukraine with Debian
Long Term: Wars in modern times can only happen, if Propaganda ensures their support by the population. Anything that helps against propaganda helps against wars. Think what technology would make it easier for people to discover the truth and share it with others (avoiding censorship). I'm currently interested in decentralized search engines, e.g. YaCy.net. Other topics might be free, decentralized and censorship-resistant communication (Email, XMPP, ...)? > Andrew M.A. Cater hat am 07.04.2022 11:57 geschrieben: > > > On Thu, Apr 07, 2022 at 06:41:58PM +1200, Matt Grant wrote: > > Hi! > > > > Has anyone thought about how to help out Ukraine by using Debian? > > Thinking about humanitarian relief and and other possibilities for > > communications. Is there any way I may be able to help out by remoting > > in? Any one got any verifiable contacts please? > > > > Thank you so much, > > > > Matt Grant > > Hi Matt, > > I think there's a couple of things here. Although the Debian installer and > some other parts of Debian have been localised into Ukrainian, anyone > who speaks and writes Ukrainian would be very welcome to help Debian in > general make Debian a better environment in Ukrainian - we're short handed > for this. > > Distributing laptops with Debian on, for example, or Freedombox or whatever > may be counterproductive at this time: probably the best help that anybody > could do is to give money to the International Red Cross or one of the large > aid agencies on the ground - and keep giving. If Debian is worth 10 currency > units a month to you - give that much to one of the large aid agencies as > if you were giving it to Debian. > > Offering to help administer somebody's machine remotely in the climate of > cyber attacks, allegations and misleading information might not be welcomed :( > > All the very best, as ever, > > Andy Cater
Re: Helping Ukraine with Debian
Hi, On Thu, Apr 7, 2022 at 3:41 AM Matt Grant wrote: > > Hi! > > Has anyone thought about how to help out Ukraine by using Debian? Thinking > about humanitarian relief and and other possibilities for communications. Is > there any way I may be able to help out by remoting in? Any one got any > verifiable contacts please? > > Thank you so much, > > Matt Grant They have a Ukrainian language forum and mailing list. As I don't understand this language, I can't say that it was portrayed in one of these links and I see it as the most viable way to have contact with Ukrainians or get information to contribute. Links taken from the page [3]. [1] https://linux.org.ua [2] https://lists.debian.org/debian-user-ukrainian [3] https://www.debian.org/international/Ukrainian -- Cheers, Leandro Cunha Software Engineer and Debian Contributor -BEGIN PGP PUBLIC KEY BLOCK- mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh 0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7 ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3 k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx /m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C +DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4 hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08 iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X 7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00 4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9 WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O +SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW fNdY6Ns= =rdCA -END PGP PUBLIC KEY BLOCK-
d/copyright: sunweaver's best practice write-up (was: Re: secnet_0.6.2_multi.changes REJECTED)
Hi Ian, On Mo 11 Apr 2022 18:51:35 CEST, Ian Jackson wrote: Another team member identified that there is code in this package under a number of different licenses other than GPL-3+, but that is not specified in sufficient detail in d/copyright. That contravenes both Debian Policy and the terms of those licenses. My apologies. You are completely correct. I don't understand how I came to think that the approach I took was sufficient. I guess it is a long time since I prepared a package with so many different bits and pieces in it. sharing some best practice here, feel free to adopt or give feedback on. For d/copyright maintenance I use my update-copyright.in script [1]. I run it on the source package's base folder. The script creates a d/copyright.in file. I keep this file as-is as part of my debian/ folder and use it for later reference. When wrapping up a new DEB package, I copy over d/copyright.in to d/copyright and complete it manually (plus doing some manual checks to see if the licensecheck tool got things right). Note, that I don't use file globbing in d/copyright, at all; every source file is listed individually. This catches 99% of all DFSG licenses on 80-95% of files in the src:pkg's source tree (depending on upstream being good at using proper license headers on individual files or not). Whenever an upstream version bump is due, I import the new upstream and re-run the update-copyright.in script on the src:pkg's base folder again. I get a diff between my previous debian/copyright.in version and the new version. This diff I then work into the actual d/copyright manually and thus have an easy workflow for tracking copyright changes in upstream projects (on a per individual file basis). This workflow is esp. helpful on projects where many copyright holders/years and/or licenses are involved and get updated every year or maybe with every changeset / new contributor. Greets, Mike [1] https://github.com/sunweaver/MyHomeConfig/blob/master/bin/update-copyright.in -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpePd8Qei1Vp.pgp Description: Digitale PGP-Signatur
Bug#1009331: ITP: node-gitlab-favicon-overlay -- Combine images for a favicon with the help of canvas
Package: wnpp Severity: wishlist Owner: Michael Ikwuegbu X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-gitlab-favicon-overlay Version : 2.0.0 Upstream Author : GitLab Frontend Team * URL : https://gitlab.com/gitlab-org/frontend/favicon-overlay#read> * License : Expat Programming Lang: JavaScript Description : Combine images for a favicon with the help of canvas . Node.js is an event-based server-side JavaScript engine.
Re: writing REJECTED messages publicly on the ITP bugs (was: secnet_0.6.2_multi.changes REJECTED)
On 4/11/22 19:04, Jonas Smedegaard wrote: Quoting Ian Jackson (2022-04-11 18:51:35) For transparency, I am CCing this reply to debian-devel, and quoting the whole of the REJECTED mail. There does not seem to be anything in here that ought to be private. Please let me know if there is somewhere better. (I considered -legal but it didn't seem appropriate.) Since you ask: Seems to me that more suitable would be to file an ITP bugreport and post followups like this to that bugreport. Filing an ITP would also serve as an invitation for ftpmasters to post their followup to that bugreport on their own. Kind regards, - Jonas I'd approve if the FTP masters were doing this by default. I wouldn't mind if my (licensing or others) mistakes were discussed publicly. So now I wonder what's the FTP team members (and other DDs) opinion about this. Maybe it'd be nicer to have an opt-in for it, but then that'd be very annoying for the FTP team to know when to do what (with possible mistakes). Any idea how we could automate the Reply-To: thingy in a REJECTED action, depending on uploader's preference? (not: I'm not volunteering, just trowing a piece of idea... :) Cheers, Thomas Goirand (zigo)
Re: d/copyright: sunweaver's best practice write-up (was: Re: secnet_0.6.2_multi.changes REJECTED)
On 4/11/22 21:59, Mike Gabriel wrote: Hi Ian, On Mo 11 Apr 2022 18:51:35 CEST, Ian Jackson wrote: Another team member identified that there is code in this package under a number of different licenses other than GPL-3+, but that is not specified in sufficient detail in d/copyright. That contravenes both Debian Policy and the terms of those licenses. My apologies. You are completely correct. I don't understand how I came to think that the approach I took was sufficient. I guess it is a long time since I prepared a package with so many different bits and pieces in it. sharing some best practice here, feel free to adopt or give feedback on. For d/copyright maintenance I use my update-copyright.in script [1]. I run it on the source package's base folder. The script creates a d/copyright.in file. I keep this file as-is as part of my debian/ folder and use it for later reference. When wrapping up a new DEB package, I copy over d/copyright.in to d/copyright and complete it manually (plus doing some manual checks to see if the licensecheck tool got things right). Note, that I don't use file globbing in d/copyright, at all; every source file is listed individually. This catches 99% of all DFSG licenses on 80-95% of files in the src:pkg's source tree (depending on upstream being good at using proper license headers on individual files or not). Whenever an upstream version bump is due, I import the new upstream and re-run the update-copyright.in script on the src:pkg's base folder again. I get a diff between my previous debian/copyright.in version and the new version. This diff I then work into the actual d/copyright manually and thus have an easy workflow for tracking copyright changes in upstream projects (on a per individual file basis). This workflow is esp. helpful on projects where many copyright holders/years and/or licenses are involved and get updated every year or maybe with every changeset / new contributor. Greets, Mike [1] https://github.com/sunweaver/MyHomeConfig/blob/master/bin/update-copyright.in Mike, I'd very much welcome this script within the devscripts package! :) Thanks for sharing it. I probably will give it a try. Cheers, Thomas Goirand (zigo)
Re: writing REJECTED messages publicly on the ITP bugs (was: secnet_0.6.2_multi.changes REJECTED)
On Mon, 2022-04-11 at 23:34 +0200, Thomas Goirand wrote: > Any idea how we could automate the Reply-To: thingy in a REJECTED > action, depending on uploader's preference? (not: I'm not > volunteering, just trowing a piece of idea... :) Here is an idea I posted on IRC a while back that should work and would solve the issues with not every package in NEW having an ITP: #debian-ftp: random unpolished idea for NEW: instead of rejects, while the package is in NEW, dak could export the Source/Maintainer/Uploaders to the BTS but not the package itself, then ftp-masters would file RC issues against the "NEW" package, which would get closed by new revisions of the package uploaded to NEW pabs: if the BTS knew about NEW packages that would be great. I have to make notes to file bugs the next day etc. * pabs asked about feasibility in #debbugs #debbugs: dondelelcaro: wondering about the feasibility of the BTS side of this idea from #debian-ftp: random unpolished idea for NEW: instead of rejects, while the package is in NEW, dak could export the Source/Maintainer/Uploaders to the BTS but not the package itself, then ftp-masters would file RC issues against the "NEW" package, which would get closed by new revisions of the package uploaded to NEW pabs: I'm OK with that in principle; we'd need to figure out the right way to share that data, but the BTS basically only needs the information from the .changes anyway dondelelcaro: how about debbugs downloads the deb822 for NEW? https://ftp-master.debian.org/new.822 it is almost the same as Sources files hmm, no Uploaders though IIRC debbugs doesn't look at that though the rest of the info in it seems similar to .changes hrm; that could work. the bit that we're missing is the .versions file for NEW which lists the changelogs but maybe that's not super important for things in NEW since presuambly there'd only be a few bugs, and they'd be RC, so someone could just manually fix them up if they weren't properly versioned after the package completes NEW hmm ok. might be possible to get dak to export the .versions somehow too anyway, just an idea at this stage. thanks for clarifying it is reasonable and potentially feasible -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: d/copyright: sunweaver's best practice write-up (was: Re: secnet_0.6.2_multi.changes REJECTED)
Quoting Mike Gabriel (2022-04-11 21:59:12) > For d/copyright maintenance I use my update-copyright.in script [1]. I > run it on the source package's base folder. [...] > [1] > https://github.com/sunweaver/MyHomeConfig/blob/master/bin/update-copyright.in You should no longer need licensecheck2dep5 nor iconv - see the licensecheck examples at https://wiki.debian.org/CopyrightReviewTools - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
