Bug#1055556: RFS: diff-pdf-wx/0.5.1-1 [ITP] -- Simple tool for visually comparing two PDF files
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "diff-pdf-wx": * Package name : diff-pdf-wx Version : 0.5.1-1 Upstream contact : vac...@slavik.io * URL : https://vslavik.github.io/diff-pdf/ * License : GPL-2, LGPL-2.1+ * Vcs : https://salsa.debian.org/harry/diff-pdf-wx Section : utils The source builds the following binary packages: diff-pdf-wx - Simple tool for visually comparing two PDF files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/diff-pdf-wx/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/diff-pdf-wx/diff-pdf-wx_0.5.1-1.dsc Changes for the initial release: diff-pdf-wx (0.5.1-1) unstable; urgency=medium . * Initial packging for upstream version 0.5.1 (closes: #1055543). You may also find my git repo at: https://salsa.debian.org/harry/diff-pdf-wx Regards, -- Shengqi Chen
Re: Looking to find a sponsor
Hi Jordan, (I'm CC:ing you this time in case you're not subscribed to the list.) [...] The package is a Python app called CraftServerSetup that allows the user to create and manage game servers for the popular video game Minecraft. CraftServerSetup seems to be non-free software. If so, it cannot be included in Debian. See the Debian Free Software Guidelines [1]. As a result of the app's choice in programming language, it does not need any building or compiling at all (so I have it as a binary deb file right from the start). You must have a source package for inclusion in Debian [2], regardless of the app's build system. If you're packaging a Python app, I suggest you learn from existing Python packages in the Python packaging team [3]. On the "New Packager's Guide" page I saw something about requesting sponsors with a certain skillset..? For that, I don't care very much. Just someone who is willing to upload the deb files to apt. It's indeed just a suggestion. You may have more luck finding a sponsor who's familiar with Python packaging, as the sponsor has to review your package and feel comfortable uploading it. [1] https://wiki.debian.org/DebianFreeSoftwareGuidelines [2] https://wiki.debian.org/Packaging/Intro#What_is_a_.22package.22.3F [3] https://wiki.debian.org/Teams/PythonTeam -- Regards, Robin GPG: B26C 2ED3 7324 6221 9C3D 1DFE 293A 3C91 D188 369C OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Help with catch2 transition needed
Am Tue, Nov 07, 2023 at 01:55:49PM - schrieb Sune Vuorela: > target_link_libraries(test PRIVATE Catch2::Catch2WithMain) Thanks a lot. This was exactly the hint I needed. Kind regards Andreas. -- http://fam-tille.de
Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management
Hi Balint,
Thanks for responding with the review. I was waiting for the upstream
project to release a 0.4 with some minor fixes before re-uploading to
mentors.
I've addressed the issues you found as below:
On 22/10/2023 22:38, Bálint Réczey wrote:
Hi Colin,
I've checked the second upload at [1].
As you can see in the Lintian warnings there is a .git directory which
is not ideal for a source package.
I suggest using the most widely used git-buildpackage based workflow
where the gbp command takes care of exporting the source package
without the .git dir from the packaging repository.
I'd be happy to set up a packaging repo for you at
https://salsa.debian.org/debian/libtypec and add you as a maintainer
as described in [2]
Other observations regarding the packaging:
* There is debian/install and also there are binary package specific
*.install files which is slightly confusing.
I suggest dropping debian/install.
Fixed
* In the debian/*.install files you need to specify only the target
dir, not the target file.
Fixed
In libtypec-dev
/usr/share/pkgconfig/${DEB_HOST_MULTIARCH}/libtypec.pc/libtypec.pc
gets shipped, which is not desired.
Fixed
* libtypec.h seems to be the same on all architectures. Does it have
to be shipped in a multiarch include location?
Fixed. Now in /usr/include and in the multiarch include location
* Binary packages in debian/control are not marked as Multi-Arch: same
* Please target experimental. The package needs to pass NEW and to
migrate to testing it will need a new source-only upload anyway.
Fixed.
Please review the 0.4 release upload and let me know if this can be
sponsored further to the changes I made.
Kind regards,
Colin
Cheers,
Balint
[1] https://mentors.debian.net/package/libtypec/
[2]
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
wrote:
Hi,
I've uploaded a fixed package that addresses these issues.
Colin
On 18/07/2023 08:50, Adam Borowski wrote:
On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:
* Package name : libtypec
Version : 0.3-1
* URL : https://github.com/Rajaram-Regupathy/libtypec
libtypec1 - generic interface for efficient USB-C port management
libtypec-dev - Development files for an interface for USB-C port management
libtypec (0.3-1) unstable; urgency=low
.
* Initial release (Closes: #1023477)
* Add patch 0001-fix-libtypec-so-version.patch to fix .so name version
Hi!
Before doing manual review, let's start with lintian:
E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains architecture
specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
W: libtypec-dev: empty-binary-package
W: libtypec1: lacks-unversioned-link-to-shared-library example:
usr/lib/x86_64-linux-gnu/libtypec.so
[usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
W: libtypec1: link-to-shared-library-in-wrong-package
usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0
[usr/lib/x86_64-linux-gnu/libtypec.so]
Meow!
Re: Help with catch2 transition needed
Hi, you may want to see #1054706. Best wishes, Jerome On 07/11/2023 14:18, Andreas Tille wrote: Hi, as per bug #1054707 libodsstream failed to build from source due to /<>/test/test_ods.cpp:3:10: fatal error: catch2/catch.hpp: No such file or directory 3 | #include | ^~ compilation terminated. I noticed that catch2 does not contain the header file catch.hpp any more. There is now some catch_all.hpp. So I replaced this header file in a patch[1] but obviously this problem can't be solved by pure wild guessing since this has lead to /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': (.text+0x17): undefined reference to `main' and my manually added main() function (also in patch[2]) did not enhanced the situation much since its now running into linker errors[2]. Any hint how to fix this catch2 issue properly would be welcome Andreas. [1] https://salsa.debian.org/debichem-team/libodsstream/-/blob/master/debian/patches/new_catch2_usage.patch [2] https://salsa.debian.org/debichem-team/libodsstream/-/jobs/4898134 -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Re: Help with catch2 transition needed
On 2023-11-07, Andreas Tille wrote: > I noticed that catch2 does not contain the header file catch.hpp any > more. There is now some catch_all.hpp. So I replaced this header file > in a patch[1] but obviously this problem can't be solved by pure wild > guessing since this has lead to > >/usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/Scrt1.o: in > function `_start': > (.text+0x17): undefined reference to `main' in catch2 3.0 and later you now need to link catch2 and catch2 main in your tests. try link with Catch2WithMain in your test targets Like this: target_link_libraries(test PRIVATE Catch2::Catch2WithMain) /Sune
Re: Help with catch2 transition needed
Hi Petr, Am Tue, Nov 07, 2023 at 02:41:00PM +0100 schrieb Petr Kubánek: > catch2 is a bit complicated story. Look on GitHub, unfortunately catch2 v2.x > changed headers, just for catch2 v3.x to change it back. Best is to use catch2 > v3.x, but that comes with a static library you need to link ASIK. As you can see in the build log on Salsa[2] catch2 3.4.0-1 is used - just the version that is in unstable. Do you want to tell me that I need to add some extra library in the linker command line (via test/CMakeLists.txt) and if yes which library is this? Kind regards Andreas. > Dne 7. 11. 2023 14:18 napsal uživatel Andreas Tille : > > > Hi, > > as per bug #1054707 libodsstream failed to build from source due to > > /<>/test/test_ods.cpp:3:10: fatal error: catch2/catch.hpp: No > such file or directory > 3 | #include >| ^~ > compilation terminated. > > I noticed that catch2 does not contain the header file catch.hpp any > more. There is now some catch_all.hpp. So I replaced this header file > in a patch[1] but obviously this problem can't be solved by pure wild > guessing since this has lead to > >/usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/ > Scrt1.o: in function `_start': > (.text+0x17): undefined reference to `main' > > and my manually added main() function (also in patch[2]) did not > enhanced the situation much since its now running into linker errors[2]. > > Any hint how to fix this catch2 issue properly would be welcome > Andreas. > > > [1] https://salsa.debian.org/debichem-team/libodsstream/-/blob/master/ > debian/patches/new_catch2_usage.patch > [2] https://salsa.debian.org/debichem-team/libodsstream/-/jobs/4898134 > > > -- > http://fam-tille.de > > > -- http://fam-tille.de
Re: Help with catch2 transition needed
Hi Andreas,catch2 is a bit complicated story. Look on GitHub, unfortunately catch2 v2.x changed headers, just for catch2 v3.x to change it back. Best is to use catch2 v3.x, but that comes with a static library you need to link ASIK.PetrDne 7. 11. 2023 14:18 napsal uživatel Andreas Tille :Hi, as per bug #1054707 libodsstream failed to build from source due to /<>/test/test_ods.cpp:3:10: fatal error: catch2/catch.hpp: No such file or directory 3 | #include | ^~ compilation terminated. I noticed that catch2 does not contain the header file catch.hpp any more. There is now some catch_all.hpp. So I replaced this header file in a patch[1] but obviously this problem can't be solved by pure wild guessing since this has lead to /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': (.text+0x17): undefined reference to `main' and my manually added main() function (also in patch[2]) did not enhanced the situation much since its now running into linker errors[2]. Any hint how to fix this catch2 issue properly would be welcome Andreas. [1] https://salsa.debian.org/debichem-team/libodsstream/-/blob/master/debian/patches/new_catch2_usage.patch [2] https://salsa.debian.org/debichem-team/libodsstream/-/jobs/4898134 -- http://fam-tille.de
Help with catch2 transition needed
Hi, as per bug #1054707 libodsstream failed to build from source due to /<>/test/test_ods.cpp:3:10: fatal error: catch2/catch.hpp: No such file or directory 3 | #include | ^~ compilation terminated. I noticed that catch2 does not contain the header file catch.hpp any more. There is now some catch_all.hpp. So I replaced this header file in a patch[1] but obviously this problem can't be solved by pure wild guessing since this has lead to /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': (.text+0x17): undefined reference to `main' and my manually added main() function (also in patch[2]) did not enhanced the situation much since its now running into linker errors[2]. Any hint how to fix this catch2 issue properly would be welcome Andreas. [1] https://salsa.debian.org/debichem-team/libodsstream/-/blob/master/debian/patches/new_catch2_usage.patch [2] https://salsa.debian.org/debichem-team/libodsstream/-/jobs/4898134 -- http://fam-tille.de
Re: Help fixing a gettext translation test
On Tue, 2023-11-07 at 02:02 +0100, Santiago Vila wrote: > Hi. > > A similar bug which was fixed in a similar way: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052859#40 > > See what Aurelien Jarno (glibc maintainer) said: > > I have seen that in the meantime you have done a new upload with > > the en_US.UTF-8 locale, that's a perfectly valid workaround. Thanks for that pointer! Mathias signature.asc Description: This is a digitally signed message part
Bug#1055410: marked as done (RFS: scite/5.3.9-1 -- Lightweight GTK-based programming editor)
Your message dated Tue, 7 Nov 2023 12:57:31 +0100 with message-id <8c2f6d04-664b-4fe4-9829-6fa204ed9...@debian.org> and subject line Re: RFS: scite/5.3.9-1 -- Lightweight GTK-based programming editor has caused the Debian Bug report #1055410, regarding RFS: scite/5.3.9-1 -- Lightweight GTK-based programming editor 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.) -- 1055410: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055410 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "scite": (I am a DD, but I don't have access to my gpg-key currently, I am working on getting signatures on a new key). * Package name : scite Version : 5.3.9-1 Upstream contact : Neil Hodgson * URL : https://scintilla.org/SciTE.html * License : scintilla, Expat, BSL-1.0, LGPL-2.1 * Vcs : https://salsa.debian.org/debian/scite Section : editors The source builds the following binary packages: scite - Lightweight GTK-based programming editor To access further information about this package, please visit the following URL: https://mentors.debian.net/package/scite/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/s/scite/scite_5.3.9-1.dsc Changes since the last upload: scite (5.3.9-1) unstable; urgency=medium . * New upstream version 5.3.9 Regards, -- Andreas Rönnquist gus...@debian.org --- End Message --- --- Begin Message --- Thanks for the update.--- End Message ---
