Bug#945755: RFS: ipgrab/0.9.10-4 [QA] -- tcpdump-like utility that prints detailed header information
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ipgrab" * Package name: ipgrab Version : 0.9.10-4 Upstream Author : Mike Borella * URL : https://sourceforge.net/projects/ipgrab/ * License : GPL-2+ * Vcs : https://salsa.debian.org/debian/ipgrab Section : net It builds those binary packages: ipgrab - tcpdump-like utility that prints detailed header information To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ipgrab Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/ipgrab/ipgrab_0.9.10-4.dsc Changes since the last upload: * QA upload. * debian/control: Adding VCS fields in control file. Regards, -- ... ⢀⣴⠾⠻⢶⣦⠀ Thiago Andrade Marques ⣾⠁⢰⠒⠀⣿⡁ GPG: 4096R/F8CDB08B ⢿⡄⠘⠷⠚⠋⠀ GPG Fingerprint: 1D38 EE3C 624F 955C E1FA 3C85 5A30 3591 F8CD B08B ⠈⠳⣄ Cel: 19 98181-1156
Bug#945325: marked as done (RFS: fet/5.40.3-1 [QA] -- timetable generator)
Your message dated Thu, 28 Nov 2019 03:23:22 +0100 with message-id <20191128022322.gb32...@angband.pl> and subject line Re: Bug#945325: RFS: fet/5.40.3-1 [QA] -- timetable generator has caused the Debian Bug report #945325, regarding RFS: fet/5.40.3-1 [QA] -- timetable generator 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.) -- 945325: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945325 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 "fet" * Package name: fet Version : 5.40.3-1 Upstream Author : Liviu Lalescu Volker Dirr * URL : https://www.lalescu.ro/liviu/fet/ * License : AGPL-3+ * Vcs : https://salsa.debian.org/debian/fet Section : misc It builds those binary packages: fet - timetable generator fet-data - timetable generator - documentation and examples To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fet Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fet/fet_5.40.3-1.dsc Changes since the last upload: * QA upload, orphaning package; see #945298. * New upstream version 5.40.3. * debian/control: - Added 'Rules-Requires-Root: no' in source stanza. - Added VCS fields. - Bumped Standards-Version to 4.4.1. * debian/rules: Removed override_dh_dwz, no longer needed. (Closes: #934854) Thanks to Gianfranco Costamagna. Regards, -- Thiago Andrade Marques --- End Message --- --- Begin Message --- On Fri, Nov 22, 2019 at 11:36:36PM -0200, Thiago wrote: > * Package name: fet >Version : 5.40.3-1 > Changes since the last upload: > >* QA upload, orphaning package; see #945298. >* New upstream version 5.40.3. >* debian/control: >- Added 'Rules-Requires-Root: no' in source stanza. >- Added VCS fields. >- Bumped Standards-Version to 4.4.1. >* debian/rules: Removed override_dh_dwz, no longer needed. (Closes: > #934854) >Thanks to Gianfranco Costamagna. Hi! dh_missing reports a lot of files that are not installed anywhere. This doesn't seem to be a regression, but it's still something to fix. I've uploaded 5.40.3-1 as-is -- I strongly prefer many small changes over a single big version. The non-installed stuff are examples, documentation and an icon. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.--- End Message ---
Re: Bug#944930: RFS: libt3highlight/0.4.6-2
Control: tags -1 +moreinfo On Wed, Nov 27, 2019 at 09:11:07AM +0100, Gertjan Halkes wrote: > I would like to kindly bring this bug to your attention again. I think it may > have fallen through the cracks as I accidentally didn't wait for the upload > to finish and it got rejected on the first try. I would very much like to > have some feedback on whether I correctly packaged the fix for the stable > release. Alas, the cracks are pretty wide :/ > On Sun, 17 Nov 2019 19:57:23 +0100, Gertjan Halkes wrote: > >I have prepared a fix for the stable version of my package "libt3highlight". > >It is a simple back-port of a fix that is already available in > >unstable/testing. I would appreciate it if you could have a look and provide > >guidance on whether I have packaged this correctly (this is the first time > >I'm preparing a bug-fix for a package in stable). I'm afraid that there's a non-trivial process for a stable update. It is described in developers-reference section 5.5.1.: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions First, you need to file a bug on release.debian.org explaining the reason and including the debdiff between 0.4.6-1 and the new upload. Only once approved, we can continue with actually uploading. > >* Package name: libt3highlight > > Version : 0.4.6-2 The version must end with +deb10u1 (u2 for second update, etc; deb11 for Bullseye, ...). So it'd be 0.4.6-1+deb10u1 . > >Changes since the last upload: > > > > * Back-port of bugfix from version 0.4.8 that prevents crashes due to > >calling free on an invalid pointer. It would be good to describe all other changes as well. Adding a way to verify upstream signatures is good. Making the build verbose may get allowed, but I'm not sure. So, you need to seek the stable release team's approval, then come back here. Good luck! Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#945749: RFS: pyenv/1.2.15-1 -- Python version manager
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "pyenv" * Package name: pyenv Version : 1.2.15-1 Upstream Author : Christopher Hunt chrah...@gmail.com * URL : https://github.com/pyenv/pyenv * License : MIT * Vcs : Git Section : misc It builds those binary packages: pyenv - Python version manager To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pyenv Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pyenv/pyenv_1.2.15-1.dsc Changes since the last upload: * Initial release. Closes: [no ITP as yet] Regards, -- Russell Pagden
'Architecture: all' with architecture specific dependencies - the Depends field contains an arch-specific dependency but the package is architecture all
I am maintaining two Debian derivatives distributions, Whonix and
Kicksecure. (Open Source) I hope you don't mind my question.
I am trying to build a custom meta package with 'Architecture: all' that
has an architecture specific dependency:
hardened-malloc [amd64]
Package hardened-malloc is only available for amd64 and cannot be
trivially ported. (Would require source code level changes which I am
unable to contribute.) That package is not all that important. We want
it pre-installed on amd64 but at the same time it shouldn't be a blocker
for ports to let's say arm64.
(We got ported to to arm64 and ppc64 earlier before we introduced
architecture specific packages.)
Here is a simplified example.
Package: kicksecure-dependencies-cli
Priority: required
Architecture: all
Depends: ...,
pkg1,
pkg2,
...,
hardened-malloc [amd64],
${misc:Depends}
Description: Dependencies for hardened systems CLI
A metapackage, which installs command line interface (CLI) packages
which should be installed on hardened systems.
debhelper fails with the following error message
>dh_gencontrol
> dpkg-gencontrol: error: the Depends field contains an arch-specific
dependency but the package is architecture all
> dh_gencontrol: dpkg-gencontrol -pkicksecure-dependencies-cli
-ldebian/changelog -Tdebian/kicksecure-dependencies-cli.substvars
-Pdebian/kicksecure-dependencies-cli -UMulti-Arch returned exit code 255
> dh_gencontrol: Aborting due to earlier error
> make: *** [debian/rules:9: binary] Error 25
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2
'Recommends:' does not fit either since we're using apt with
'--no-install-recommends' during the build process to have tighter
control about which packages get installed.
Can I somehow hack or work around that limitation?
I could use 'Architecture: any' but then that meta package would be
build and added to the repository as 'amd64', although it's "mostly"
just a 'Architecture: all' package, except for the "optional dependency".
This would mean that either,
- architecture users other than amd64 couldn't simply install our meta
package by simply adding our third party repository and apt installing
from it, or
- I'd have to build that package for all platforms and add to
repository. That's doable in theory but would require a lot of
cowbuilder chroots, disk space and build time.
("99%" of our packages are "really" 'Architecture: all', i.e. just
configuration packages, bash or python.)
Hence, I am looking for a simpler fix. Any idea?
Kind regards,
Patrick
'Architecture: all' with architecture specific dependencies - the Depends field contains an arch-specific dependency but the package is architecture all
I am maintaining two Debian derivatives distributions, Whonix and
Kicksecure. (Open Source) I hope you don't mind my question.
I am trying to build a custom meta package with 'Architecture: all' that
has an architecture specific dependency:
hardened-malloc [amd64]
Package hardened-malloc is only available for amd64 and cannot be
trivially ported. (Would require source code level changes which I am
unable to contribute.) That package is not all that important. We want
it pre-installed on amd64 but at the same time it shouldn't be a blocker
for ports to let's say arm64.
(We got ported to to arm64 and ppc64 earlier before we introduced
architecture specific packages.)
Here is a simplified example.
Package: kicksecure-dependencies-cli
Priority: required
Architecture: all
Depends: ...,
pkg1,
pkg2,
...,
hardened-malloc [amd64],
${misc:Depends}
Description: Dependencies for hardened systems CLI
A metapackage, which installs command line interface (CLI) packages
which should be installed on hardened systems.
debhelper fails with the following error message
>dh_gencontrol
> dpkg-gencontrol: error: the Depends field contains an arch-specific
dependency but the package is architecture all
> dh_gencontrol: dpkg-gencontrol -pkicksecure-dependencies-cli
-ldebian/changelog -Tdebian/kicksecure-dependencies-cli.substvars
-Pdebian/kicksecure-dependencies-cli -UMulti-Arch returned exit code 255
> dh_gencontrol: Aborting due to earlier error
> make: *** [debian/rules:9: binary] Error 25
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2
'Recommends:' does not fit either since we're using apt with
'--no-install-recommends' during the build process to have tighter
control about which packages get installed.
Can I somehow hack or work around that limitation?
I could use 'Architecture: any' but then that meta package would be
build and added to the repository as 'amd64', although it's "mostly"
just a 'Architecture: all' package, except for the "optional dependency".
This would mean that either,
- architecture users other than amd64 couldn't simply install our meta
package by simply adding our third party repository and apt installing
from it, or
- I'd have to build that package for all platforms and add to
repository. That's doable in theory but would require a lot of
cowbuilder chroots, disk space and build time.
("99%" of our packages are "really" 'Architecture: all', i.e. just
configuration packages, bash or python.)
Hence, I am looking for a simpler fix. Any idea?
Kind regards,
Patrick
Bug#945447: RFS: emacs-websocket/1.12+1.g74e4b82-1 [ITP] -- Emacs WebSocket client and server
On 2019-11-27 07:43:59, Nicholas D Steeves wrote:
> Hi Antoine,
>
> Antoine Beaupré writes:
>
>> A few comments...
>>
>> Why do you specify a compression level and algorithm in gbp.conf?
>>
>> compression = xz
>> compression-level = 9
>>
>
> This reduces the incidence of encountering an annoying gbp bug, where
> gbp fails, allegedly because "two tarballs were found", even when the
> tarball did not previously exist on disk and is generated on demand from
> upstream tag.
I have not found this to be a problem enough to proactively add this
setting when it's not necessary.
> Other than that it's harmless and redundant, because these settings
> are now gbp defaults.
Really! What do you base this on? The manpages of "gbp-buildpackage(1)"
in both buster and sid currently say:
--git-compression=TYPE
Specifies the upstream tarball compression type. This will be
used to locate
and build the upstream tarball if necessary. The default is auto
which derives
the compression type from the pristine-tar branch if available
and falls back
to gzip otherwise. Other options are gzip, bzip2, lzma and xz.
--git-compression-level=LEVEL
Specifies the upstream tarball compression level if an upstream
tarball needs
to be built.
The keyword here is "default is auto". :p I'm especially concerned about
the excessively high compression-level as well - it's usually not
necessary to change the compression level, and makes it diverge
needlessly from upstream.
>> Upstream doesn't seem to use any peculiar tarball format, so that
>> generated tarball won't match the one published on github.
What I should have written here, for the record, is more like "upstream
doesn't use .xz and uses the default github-generated .gz files".
> I'm using release tags directly and not github generated & published
> tarballs ("why" is another discussion).
I would argue it's the core of this discussion here. You haven't
convinced me that using a .xz tarball format is necessary at all, nor
why you need to diverge from the upstream tarballs.
> The reason the Emacsen Team requests a tarball in d/watch is because
> the git mode we previously used was too resource-intensive.
This seems like another reason to stick with .tgz and not diverge.
> The bug mentioned above also has a useful (hack of a) side-effect in
> that it seems to enforce new upstream version imports from git tags
> rather than github-generated tarballs.
I'm confused - how does compression and compression-level enforce
importing from git tags? And how does that differ from github-generated
tarballs which *are* (reproducibly too) generated frmo git-tags as well?
> Whenever the "light" git-mode becomes generally recommended and
> preferred over the tarball one I'll switch my upstream-uses-github
> packages over to it.
I don't understand what this refers to.
>> I also wonder if it's really necessary to ship a git snapshot instead of
>> the 1.12 release... I see it includes a patch to tweak the GPL version,
>> is that why that was done?
>
> For multiple past NEW packages, ftpmasters have asked me to contact
> upstream about licensing problems (eg: we're accepting, but you need to
> do xyz), so I started doing this preRFS. Then lamby asked me not to
> carry licensing-related-changes as a quilt patch--with good rationale
> that I agree with. Thus, packaging a git snapshot. The contradictory
> declared license issue is here:
>
> https://github.com/ahyatt/emacs-websocket/issues/62
Cool, makes sense.
>> Are the tests included in the package build? or autopkgtest? could that
>> be done? Not a blocker.
>>
>
> Sorry, I don't understand what you mean... ERT tests are already run
> during the build, autopkgtest-pkg-elpa has been activated
> (d/control:L12), I've confirmed autopkgtest runs the tests, and I've
> also opened an upstream issue about integrating the functional tests
> into the ERT framework:
>
> https://github.com/ahyatt/emacs-websocket/issues/64
Awesome, that answers my question, thanks!
> Since all NEW packages now require two uploads before they can enter
> testing, I like to add value to the second upload, and the following
> brand new commit seems like a good candidate for this:
>
> https://github.com/ahyatt/emacs-websocket/commit/69ee80a88ba825a925e82a5576a340b3ec03fd51
>
> Depending on how long it takes this package to pass NEW upstream might
> tag a new release including that commit, which would be ideal for the
> second upload!
Cool.
>> Otherwise looks good.
>>
>
> Thanks for reviewing :-) 'hope my reply sufficiently addresses your
> concerns!
Not quite. Your reply about the compression level stuff makes me more
worried than anything, to be honest. :p
I would like us to stick with the actual gbp defaults here, which are
"auto" and can easily pick up upstream tgz defaults.
A.
--
One of the strongest motives that leads men to art and science is
escape from
Bug#945588: RFS: lutris/0.5.4-1 -- open source gaming platform for GNU/Linux
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "lutris" * Package name: lutris Version : 0.5.4-1 Upstream Author : Mathieu Comandon * URL : https://lutris.net or https://github.com/lutris/lutris * License : GPL-3 * Vcs : https://salsa.debian.org/stephanlachnit-guest/lutris Section : games It builds those binary packages: lutris - open source gaming platform for GNU/Linux To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lutris Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lutris/lutris_0.5.4-1.dsc Changes since the last upload: * Initial release (Closes: #754129) Regards, Stephan Lachnit -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#945447: RFS: emacs-websocket/1.12+1.g74e4b82-1 [ITP] -- Emacs WebSocket client and server
Hi Antoine,
Antoine Beaupré writes:
> A few comments...
>
> Why do you specify a compression level and algorithm in gbp.conf?
>
> compression = xz
> compression-level = 9
>
This reduces the incidence of encountering an annoying gbp bug, where
gbp fails, allegedly because "two tarballs were found", even when the
tarball did not previously exist on disk and is generated on demand from
upstream tag. Other than that it's harmless and redundant, because
these settings are now gbp defaults.
> Upstream doesn't seem to use any peculiar tarball format, so that
> generated tarball won't match the one published on github.
>
I'm using release tags directly and not github generated & published
tarballs ("why" is another discussion). The reason the Emacsen Team
requests a tarball in d/watch is because the git mode we previously used
was too resource-intensive. The bug mentioned above also has a useful
(hack of a) side-effect in that it seems to enforce new upstream version
imports from git tags rather than github-generated tarballs. Whenever
the "light" git-mode becomes generally recommended and preferred over
the tarball one I'll switch my upstream-uses-github packages over to it.
> I also wonder if it's really necessary to ship a git snapshot instead of
> the 1.12 release... I see it includes a patch to tweak the GPL version,
> is that why that was done?
>
For multiple past NEW packages, ftpmasters have asked me to contact
upstream about licensing problems (eg: we're accepting, but you need to
do xyz), so I started doing this preRFS. Then lamby asked me not to
carry licensing-related-changes as a quilt patch--with good rationale
that I agree with. Thus, packaging a git snapshot. The contradictory
declared license issue is here:
https://github.com/ahyatt/emacs-websocket/issues/62
> Are the tests included in the package build? or autopkgtest? could that
> be done? Not a blocker.
>
Sorry, I don't understand what you mean... ERT tests are already run
during the build, autopkgtest-pkg-elpa has been activated
(d/control:L12), I've confirmed autopkgtest runs the tests, and I've
also opened an upstream issue about integrating the functional tests
into the ERT framework:
https://github.com/ahyatt/emacs-websocket/issues/64
Since all NEW packages now require two uploads before they can enter
testing, I like to add value to the second upload, and the following
brand new commit seems like a good candidate for this:
https://github.com/ahyatt/emacs-websocket/commit/69ee80a88ba825a925e82a5576a340b3ec03fd51
Depending on how long it takes this package to pass NEW upstream might
tag a new release including that commit, which would be ideal for the
second upload!
> Otherwise looks good.
>
Thanks for reviewing :-) 'hope my reply sufficiently addresses your
concerns!
Cheers,
Nicholas
signature.asc
Description: PGP signature
Bug#945571: RFS: libt3widget/1.1.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libt3widget" * Package name: libt3widget Version : 1.1.0-1 Upstream Author : Gertjan Halkes * URL : https://os.ghalkes.nl/t3/libt3widget.html * License : GPLv3 Section : libs It builds those binary packages: libt3widget-dev - Development files for libt3widget libt3widget2 - C++ terminal dialog toolkit To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libt3widget Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libt/libt3widget/libt3widget_1.1.0-1.dsc Changes since the last upload: * New upstream release. Regards, Gertjan Halkes
Bug#944930: RFS: libt3highlight/0.4.6-2
Dear mentors, I would like to kindly bring this bug to your attention again. I think it may have fallen through the cracks as I accidentally didn't wait for the upload to finish and it got rejected on the first try. I would very much like to have some feedback on whether I correctly packaged the fix for the stable release. Regards, Gertjan Halkes On Sun, 17 Nov 2019 19:57:23 +0100, Gertjan Halkes wrote: >Package: sponsorship-requests >Severity: normal > >Dear mentors, > >I have prepared a fix for the stable version of my package "libt3highlight". >It is a simple back-port of a fix that is already available in >unstable/testing. I would appreciate it if you could have a look and provide >guidance on whether I have packaged this correctly (this is the first time >I'm preparing a bug-fix for a package in stable). > >* Package name: libt3highlight > Version : 0.4.6-2 > Upstream Author : Gertjan Halkes >* URL : https://os.ghalkes.nl/t3/libt3highlight.html >* License : GPLv3 > Section : libs > >It builds those binary packages: > > libt3highlight-dev - Development files for libt3highlight > libt3highlight2 - Syntax highlighting library > t3highlight - Command-line syntax highligher > >To access further information about this package, please visit the following >URL: > >https://mentors.debian.net/package/libt3highlight > >Alternatively, one can download the package with dget using this command: > >dget -x >https://mentors.debian.net/debian/pool/main/libt/libt3highlight/libt3highlight_0.4.6-2.dsc > >Changes since the last upload: > > * Back-port of bugfix from version 0.4.8 that prevents crashes due to >calling free on an invalid pointer. > >Regards, > Gertjan Halkes >
