Bug#983146: 983146 RFS: bung/3.2.6-3 [ITP] -- backup next generation
Dear Bastian Regards "Please use the *.source.tgz as source instead of *.source_with_htm_and_pdf.tgz", I assume you refer to the files at https://github.com/CharlesMAtkinson/bung/releases/tag/3.2.6. If that is not correct, please correct my assumption and disregard the rest of this mail. Regards "You should then export and install the .htm as documentation automatically", when and where do you want that automation to happen? In case you wanted it to be done while installing the .deb, it is not possible. The .htm files are created from .odt files using soffice from package libreoffice-common. Package libreoffice-common may not be installed on computers where the .deb will be installed. There is no way to create .htm files from .odt files on all computers where the .deb will be installed Best Charles
Re: Is valid for Debian a source code not in English? (was Help to know if a package is valid)
Em sex., 19 de ago. de 2022 às 16:38, Lucas Castro escreveu: > > > Em 16/08/2022 22:50, braulio escreveu: > > On 22/08/05 15:36, braulio wrote: > >> Good afternoon. > >> > >> I need help with a situation. I packaged a program under the GPL-3+ > >> license where Upstream wrote all the texts in its native language Pt-Br, > >> and for the packaging, I did all the translation to English, creating a > >> directory 'debian/locale/en' with your required files for the translation > >> as the 'manual', 'README', example and strings of the --help command. I > >> would like to know if my package is valid, since I didn't find any kind of > >> content in Debian Policy. > > I guess any changes to upstream must be implements along with patch and > > anything under debian/ must be related to debian package only. > > So shouldn't debian/locale/ be related locate of debian package itself? No. Similarly, you could provide a manpage or sources[1] via debian/. IMO, it is not a good practice to generate new files in upstream place via patches. [1] https://www.debian.org/doc/debian-policy/ch-source.html#missing-sources-debian-missing-sources Eriberto
Re: Is valid for Debian a source code not in English? (was Help to know if a package is valid)
Em 16/08/2022 22:50, braulio escreveu: On 22/08/05 15:36, braulio wrote: Good afternoon. I need help with a situation. I packaged a program under the GPL-3+ license where Upstream wrote all the texts in its native language Pt-Br, and for the packaging, I did all the translation to English, creating a directory 'debian/locale/en' with your required files for the translation as the 'manual', 'README', example and strings of the --help command. I would like to know if my package is valid, since I didn't find any kind of content in Debian Policy. I guess any changes to upstream must be implements along with patch and anything under debian/ must be related to debian package only. So shouldn't debian/locale/ be related locate of debian package itself? Below is a link to the packaging in my salsa for further clarification. https://salsa.debian.org/braulio/md2term Sincerely, -- Braulio H. M. Souto E-mail:brau...@disroot.org / XMPP:brau...@suchat.org FB39 DE61 869F 49D5 CCC8 3AE0 D53A 15D9 83A1 0B94 After a few days the package was uploaded to the NEW queue and a few days later it was approved by the FTP Master, so it is possible to have such a package in Debian.
Bug#1011368: marked as done (RFS: libkdumpfile/0.5.0-1 [ITP] -- Kernel coredump file access)
Your message dated Fri, 19 Aug 2022 20:29:59 +0200 with message-id and subject line Re: Bug#1011368: RFS: libkdumpfile/0.4.1-1 [ITP] -- Python bindings for libkdumpfile9 has caused the Debian Bug report #1011368, regarding RFS: libkdumpfile/0.5.0-1 [ITP] -- Kernel coredump file access to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1011368: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011368 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libkdumpfile": * Package name: libkdumpfile Version : 0.4.1-1 Upstream Author : Petr Tesarik * URL : https://github.com/ptesarik/libkdumpfile * License : LGPL-3+ or GPL-2+ * Vcs : https://salsa.debian.org/michel/libkdumpfile Section : libs The source builds the following binary packages: libkdumpfile-bin - libkdumpfile9 utilities libkdumpfile-dev - libkdumpfile9 development libraries and header files libkdumpfile-doc - Kernel coredump file access (documentation) libkdumpfile9 - Kernel coredump file access python3-libkdumpfile - Python bindings for libkdumpfile9 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libkdumpfile/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libk/libkdumpfile/libkdumpfile_0.4.1-1.dsc Changes for the initial release: libkdumpfile (0.4.1-1) unstable; urgency=low . * Initial release (Closes: #1010829) Regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part --- End Message --- --- Begin Message --- Thanks for the new package!--- End Message ---
Bug#1017588: Your autotools copyright question
On Fri, Aug 19, 2022 at 10:13:00AM +0200, Bastian Germann wrote: > Am 19.08.22 um 03:41 schrieb Michel Alexandre Salim: > > Quick question (applies to drgn, not libkdumpfile) - if the tarball > > contains some m4 rules copied verbatim from autotools, do I have to list > > them in d/copyright? > > The answer is tricky: Per Debian Policy you have to include every license > that appears. > You do not have to include the Copyright statements because the files are not > a compiled part of the binary. > > Legally, it is okay to leave the licenses out of d/copyright and I have > never seen ftpmaster reject a package because the FSF All Permissive License > was missing. I do not think there is an official exception for it but there > is certainly an unwritten exception. > > So the official answer is: include them. The unofficial answer is: it is okay > not to. > Got it, thanks! So if a unique license appears in the files that are not a compiled part, the argument in favor of listing it in d/copyright gets stronger, but if the license is the same and only the copyright is different I'll probably lean towards skipping unless someone insists they are included. I fixed libkdumpfile last night per your feedback, but there's a minor update just uploaded (2022-08-19 16:05) that refreshed the patches - one replaced by the upstream commit fixing a bug I reported, the other is now merged so I updated the header to include the fixed commit. Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature
Re: How to Specifically Scan for Existing Bug Tickets?
Hi Mentors, Sorry for bugging. Found out already: https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=grub-efi-amd64-signed;package=shim-signed Regards, Holloway On Fri, Aug 19, 2022 at 8:58 PM Chew, Kean Ho wrote: > Hi Mentor, > > Quick one, can I specifically scan the bug tracking system for existing > tickets with patterns? > > I found 3 bugs related to SecureBoot grub-amd64-signed packages and > already narrowed down the scope + reproducible steps. I want to check for > existing ones before filing a new one. I'm on the stable branch and > reportbug requested me to check testing and sid branches. > > 1 bug is: the package did not install grub secureboot during apt install > step (https://lists.debian.org/debian-efi/2022/08/msg00019.html). Manual > grub installation workaround is needed. > 1 bug is: grub-install with removable flag can cause boot-loop at EFI > level (basically keep resetting system). > 1 bug is: when using --bootloader-id flag, EFI unknowingly failed to > locate grub/grub.cfg and drop to grub shell. > > > Regards, > Holloway >
How to Specifically Scan for Existing Bug Tickets?
Hi Mentor, Quick one, can I specifically scan the bug tracking system for existing tickets with patterns? I found 3 bugs related to SecureBoot grub-amd64-signed packages and already narrowed down the scope + reproducible steps. I want to check for existing ones before filing a new one. I'm on the stable branch and reportbug requested me to check testing and sid branches. 1 bug is: the package did not install grub secureboot during apt install step (https://lists.debian.org/debian-efi/2022/08/msg00019.html). Manual grub installation workaround is needed. 1 bug is: grub-install with removable flag can cause boot-loop at EFI level (basically keep resetting system). 1 bug is: when using --bootloader-id flag, EFI unknowingly failed to locate grub/grub.cfg and drop to grub shell. Regards, Holloway
Bug#983146: 983146 RFS: bung/3.2.6-3 [ITP] -- backup next generation
Am 07.08.22 um 04:34 schrieb Charles: I do not understand the E class item. "usr/share/doc/bung/Backup scripts next generation 3.2.x User Guide.htm" is present in bung_3.2.6.orig.tar.gz The .htm is generated from the corresponding .odt file. Please use the *.source.tgz as source instead of *.source_with_htm_and_pdf.tgz. You should then export and install the .htm as documentation automatically.
Bug#1017588: Your autotools copyright question
Am 19.08.22 um 03:41 schrieb Michel Alexandre Salim: Quick question (applies to drgn, not libkdumpfile) - if the tarball contains some m4 rules copied verbatim from autotools, do I have to list them in d/copyright? The answer is tricky: Per Debian Policy you have to include every license that appears. You do not have to include the Copyright statements because the files are not a compiled part of the binary. Legally, it is okay to leave the licenses out of d/copyright and I have never seen ftpmaster reject a package because the FSF All Permissive License was missing. I do not think there is an official exception for it but there is certainly an unwritten exception. So the official answer is: include them. The unofficial answer is: it is okay not to.
