Bug#950824: RFS: sayonara/1.5.2-beta3~1 -- Small and lightweight music player
some fix is done.
E: sayonara: \python-script-but-no-python-dep\ usr/bin/sayonara-ctl
#!python3
E: sayonara: \python-script-but-no-python-dep\
usr/bin/sayonara-query #!python3
update version is "sayonara_1.6.0~exp1"
also add source dependency to
dh-python,
doxygen,
taglib,
python3:any
and package dependencies
doxygen,
libtagc0,libtag1v5,libtag1v5-vanilla,
${python3:Depends},
for
E: sayonara: \embedded-library\ usr/bin/sayonara: taglib
taglib dependency still check in CMake
with regards.
On Sat, Feb 8, 2020 at 12:47 AM Boyuan Yang wrote:
> Hi,
>
> 在 2020-02-07五的 11:14 +0630，Ko Ko Ye`写道：
> > I am looking for a sponsor for my package "sayonara"
> >
> > Sayonara is a small, clear and fast audio player for Linux written in
> C++,
> > supported by the Qt framework.
> > It uses GStreamer as audio backend. Sayonara is open source and uses the
> > GPLv3 license.
> > more at https://sayonara-player.com [1],
> > https://gitlab.com/luciocarreras/sayonara-player [2]
>
> Could you fix those lintian errors?
>
> E: sayonara: \embedded-library\ usr/bin/sayonara: taglib
> E: sayonara: \python-script-but-no-python-dep\ usr/bin/sayonara-ctl
> #!python3
> E: sayonara: \python-script-but-no-python-dep\ usr/bin/sayonara-query
> #!python3
>
> Besides, the version string is also buggy.
> * The debian revision should be -1 and never be ~1.
> * If upstream is releasing a beta version with version string as "1.5.2-
> beta3", you should consider mangling it back to "1.5.2~beta3" since
> "1.5.2-"
> is considered a higher version than "1.5.2" in Debian.
>
> Final result should be "1.5.2~beta3-1". Plese read deb-version(5) man page
> for
> information about Debian's versioning.
>
> Another thing is that you should drop historical changelog entries in
> debian/changelog. They are useless in Debian.
>
> --
> Thanks,
> Boyuan Yang
>
--
with regards *Ko Ko Ye`*
+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com
skype: kokoye2007
jitsi: kokoye2007
http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm
Bug#950908: RFS: opensurge/0.5.1.2-1 [ITP] -- Fun 2D retro platformer inspired by Sonic games
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opensurge" * Package name: opensurge Version : 0.5.1.2-1 Upstream Author : Alexandre Martins * URL : https://opensurge2d.org * License : GPL-3+ * Vcs : https://salsa.debian.org/games-team/opensurge Section : games It builds those binary packages: opensurge - Fun 2D retro platformer inspired by Sonic games opensurge-data - Fun 2D retro platformer inspired by Sonic games (data file) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/opensurge Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/opensurge/opensurge_0.5.1.2-1.dsc Changes since the last upload: * Initial release (Closes: #943676) Regards, -- Carlos Donizete Froes [a.k.a coringao]
Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
On Fri, Feb 7, 2020 at 10:17 AM Sudip Mukherjee wrote: > > On Thu, Feb 6, 2020 at 10:53 PM Christian Barcenas > wrote: > > > > I just noticed that your packaging repo is currently empty. > > Would you be able to push your current progress to Github > > so that it's easier to review the source package? > > Pushed now. Its without any epoch in the version. I will add the epoch > and push again tonight after back from $dayjob. Also pushed in wip/epoch branch with the epoch in only binary packages for your review. I have not yet uploaded to mentors. -- Regards Sudip
Bug#950885: RFS: scons-doc/3.1.2+repack-2 -- Documentation for SCons, a replacement for Make
On Fri, Feb 07, 2020 at 07:16:07PM +0100, Jörg Frings-Fürst wrote: >Package name: scons-doc >Version : 3.1.2+repack-2 > Changes since the last upload: > >* debian/watch: Add repacksuffix. >* debian/copyright: > - Add year 2020 to debian/*. >* Declare compliance with Debian Policy 4.5.0 (No changes needed). >* upload to unstable (Closes: #943200). Alas, it fails at the "clean" stage: dh clean debian/rules override_dh_auto_clean make[1]: Entering directory '/<>' scons -c *** Error loading site_init file './site_scons/site_init.py': *** cannot import site init file './site_scons/site_init.py': ModuleNotFoundError: No module named 'distutils.util': File "/usr/lib/scons/SCons/Script/Main.py", line 1396: _exec_main(parser, values) File "/usr/lib/scons/SCons/Script/Main.py", line 1359: _main(parser) File "/usr/lib/scons/SCons/Script/Main.py", line 971: _load_all_site_scons_dirs(d.get_internal_path()) File "/usr/lib/scons/SCons/Script/Main.py", line 817: _load_site_scons_dir(d) File "/usr/lib/scons/SCons/Script/Main.py", line 751: exec(compile(fp.read(), fp.name, 'exec'), site_m) File "./site_scons/site_init.py", line 2: from Utilities import is_windows, whereis, platform, deb_date File "/<>/site_scons/Utilities.py", line 4: import distutils.util make[1]: *** [debian/rules:7: override_dh_auto_clean] Error 2 Meow! -- ⢀⣴⠾⠻⢶⣦⠀ The ill-thought conversion to time64_t will make us suffer from ⣾⠁⢠⠒⠀⣿⡁ the Y292B problem. So let's move the Epoch by 43545140006400 ⢿⡄⠘⠷⠚⠋⠀ (plus a safety margin in case of bad physicists) and make it ⠈⠳⣄ unsigned -- that'll almost double the range.
Bug#950885: RFS: scons-doc/3.1.2+repack-2 -- Documentation for SCons, a replacement for Make
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "scons-doc" Package name: scons-doc Version : 3.1.2+repack-2 Upstream Author : Steven Knight URL : https://www.scons.org/ License : Expat Vcs : https://salsa.debian.org/debian/scons-doc Section : doc It builds those binary packages: scons-doc - Documentation for SCons, a replacement for Make To access further information about this package, please visit the following URL: https://mentors.debian.net/package/scons-doc Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/scons-doc/scons-doc_3.1.2+repack-2.dsc or from git https://salsa.debian.org/debian/scons-doc/tree/release/debian/3.1.2+repack-2 Changes since the last upload: * debian/watch: Add repacksuffix. * debian/copyright: - Add year 2020 to debian/*. * Declare compliance with Debian Policy 4.5.0 (No changes needed). * upload to unstable (Closes: #943200). CU Jörg Frings-Fürst -- 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 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#950824: RFS: sayonara/1.5.2-beta3~1 -- Small and lightweight music player
Hi, 在 2020-02-07五的 11:14 +0630，Ko Ko Ye`写道： > I am looking for a sponsor for my package "sayonara" > > Sayonara is a small, clear and fast audio player for Linux written in C++, > supported by the Qt framework. > It uses GStreamer as audio backend. Sayonara is open source and uses the > GPLv3 license. > more at https://sayonara-player.com [1], > https://gitlab.com/luciocarreras/sayonara-player [2] Could you fix those lintian errors? E: sayonara: \embedded-library\ usr/bin/sayonara: taglib E: sayonara: \python-script-but-no-python-dep\ usr/bin/sayonara-ctl #!python3 E: sayonara: \python-script-but-no-python-dep\ usr/bin/sayonara-query #!python3 Besides, the version string is also buggy. * The debian revision should be -1 and never be ~1. * If upstream is releasing a beta version with version string as "1.5.2- beta3", you should consider mangling it back to "1.5.2~beta3" since "1.5.2-" is considered a higher version than "1.5.2" in Debian. Final result should be "1.5.2~beta3-1". Plese read deb-version(5) man page for information about Debian's versioning. Another thing is that you should drop historical changelog entries in debian/changelog. They are useless in Debian. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#950718: RFS: depthcharge-tools/0.3.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
On Wed, 5 Feb 2020 13:54:26 +0300 Alper Nebi Yasak wrote: > I am looking for a sponsor for my package "depthcharge-tools": > > * Package name: depthcharge-tools >Version : 0.3.0-1 >Upstream Author : Alper Nebi Yasak > * URL : https://github.com/alpernebbi/depthcharge-tools > * License : GPL-2.0+ > * Vcs : > https://salsa.debian.org/alpernebbi-guest/depthcharge-tools >Section : admin > > It builds those binary packages: > > depthcharge-tools - Tools for ChromeOS firmware/bootloader integration > depthcharge-support - ChromeOS firmware/bootloader integration > depthcharge-support-installer - Make this ChromeOS machine bootable (udeb) > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/depthcharge-tools > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/d/depthcharge-tools/depthcharge-tools_0.3.0-1.dsc > > Changes since the last upload: > >* Initial release. (Closes: #950687) Same here as with #950717: how about talking to the DI team and team-maintaining it and hosting it under https://salsa.debian.org/installer-team? P.S. I had a look at the package and apart from the fact I call the GPL "GPL-2+" not "GPL-2.0+", I don’t have any nitpicks, but then I don’t know anything about how the d-i integration should work. -- Cheers, Andrej
Bug#950717: RFS: partman-cros/1 [ITP] -- Add partman support for ChromeOS kernel partitions
On Wed, 5 Feb 2020 13:52:11 +0300 Alper Nebi Yasak wrote: > I am looking for a sponsor for my package "partman-cros": > > * Package name: partman-cros >Version : 1 >Upstream Author : Alper Nebi Yasak > * URL : https://salsa.debian.org/alpernebbi-guest/partman-cros > * License : GPL-2.0+ > * Vcs : https://salsa.debian.org/alpernebbi-guest/partman-cros >Section : debian-installer > > It builds those binary packages: > > partman-cros - Add partman support for ChromeOS kernel partitions (udeb) > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/partman-cros > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/p/partman-cros/partman-cros_1.dsc How about talking to the DI team and team-maintaining it and hosting it under https://salsa.debian.org/installer-team? -- Cheers, Andrej
Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
On Thu, 2020-02-06 at 09:39:29 +0100, Michael Biebl wrote: > Am 06.02.20 um 09:22 schrieb Adam D. Barratt: > > On 2020-02-06 08:12, Paul Gevers wrote: > > > But, if I am correct, the source could be using a version without epoch > > > and only use the epoch in the binary package (which can be dropped if > > > libbpf0 is ever replaced by libbpf1). > > > > Yes. It's a little more work on the packaging side, but entirely > > possible to do it that way. While this case is precisely what epochs were designed for, I'd still try to minimize its usage here as much as possible. And go for no epoch on the source packages, and prefixing the epoch in the binary packages, because the one in libbpf1 could then be dropped. > There is also libbpf-dev, which could not drop the epoch on a soname > bump. Would be kinda odd if going forward libbpfx would not have an > epoch and libbpf-dev does. We already have similar cases in the archive. And the nice thing of not going with a full epoch bump is that it can always be bumped for the source later on, while the reverse is not possible. :) > One other alternative could be, to ask your upstream to change the > versioning scheme and instead of using 0.0.6, switch to 6.0.0 as first > version number (which would be higher then 5.x) > Other distros might have similar problems. That might be even better, yes. :) Thanks, Guillem
Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
On Thu, Feb 6, 2020 at 10:53 PM Christian Barcenas wrote: > > I just noticed that your packaging repo is currently empty. > Would you be able to push your current progress to Github > so that it's easier to review the source package? Pushed now. Its without any epoch in the version. I will add the epoch and push again tonight after back from $dayjob. -- Regards Sudip
