Bug#987181: RFS: cpufetch/0.97-1 -- Simple yet fancy CPU architecture fetching tool
On Tue, Jun 8, 2021 at 6:54 AM clay stan wrote: > Upstream support arm means the mobile arm chips, like Snapdragon, MediaTek, > not arm PC, They are not supported by Debian. Debian can run on ARM mobile chips, probably a non-mainline Linux kernel from outside of Debian will be needed though. https://bonedaddy.net/pabs3/log/2012/12/03/debian-mobile/ https://wiki.debian.org/Mobile https://mobian.debian.net/ https://wiki.debian.org/Mobian https://mobian-project.org/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: libgrokj2k: version 9.2 uploaded
On Tue, Jun 08, 2021 at 12:11:16PM -0400, Aaron Boxer wrote: > Hi Guys, > Just a polite ping about my recently uploaded new package for > a majour release of my library. We're deeply into the freeze, no major changes can go into unstable. Your options are: * targetting experimental instead, or * waiting until Bullseye is released Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Bug#987169: RFS: newlib/3.3.0-1.1 [NMU] -- C library and math library for embedded systems
On Tue, 2021-06-01 at 07:52 +0200, Tobias Frost wrote: > > I haven't encountered the maintainer previously, but believe in > > good faith that these changes would be welcome and that the > > LowThresholdNmu criterion are met by addressing a bug with > > important severity. My interest in this bug, to introduce a newlib- > > source binary package, is to unblock my progress on gcc-sh-elf, > > which is otherwise almost ready. > Probably still a good idea to CC them or file a bug in the BTS to > document your intentions, as adding a binary package is not a usual > change, even if the NMU criterias are fulfilled. Okay, I made some noise on the bug report today and Cc'ed the debian- toolchain mailing list on it. I'm not touching the moreinfo tag yet to give them time to respond. > Alternatively, you should consider ITS'ing the package. > At least from your description it sounds as it would be a valid > candidate, but I didn't check the details. I do believe it would be a valid candidate, but I don't think it would be a good idea to salvage it until I get gcc-sh-elf into the archive. The best way forward for the Newlib package is to only provide a newlib-source package, and make the respective GCC source packages (like gcc-sh-elf and gcc-arm-none-eabi) build their own Newlib ports. For reasons I won't repeat here, this should be best practice, but I am not yet in a position to where I can assume responsibility for the ARM packages that are currently built by the Newlib source package. > please change to experimental. (Its anyway _always_ a good idea to > clear NEW first via experimental…) Done. signature.asc Description: This is a digitally signed message part
Bug#980848: marked as done (RFS: surgescript/0.5.5-1 -- Scripting language for games)
Your message dated Tue, 8 Jun 2021 21:36:24 +0200 with message-id <75df44c8cf31d10e3b3f46d4ff0c1fffa334e61f.ca...@sviech.de> and subject line Re: RFS: surgescript/0.5.5-1 -- Scripting language for games has caused the Debian Bug report #980848, regarding RFS: surgescript/0.5.5-1 -- Scripting language for games 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.) -- 980848: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980848 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 "surgescript": * Package name: surgescript Version : 0.5.5-1 Upstream Author : Alexandre Martins * URL : https://docs.opensurge2d.org * License : Apache-2.0, BSD-2-Clause * Vcs : https://salsa.debian.org/games-team/surgescript Section : libs It builds those binary packages: libsurgescript-dev - Scripting language for games (development files) libsurgescript0.5.5 - Scripting language for games (library files) surgescript - Scripting language for games To access further information about this package, please visit the following URL: https://mentors.debian.net/package/surgescript/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/surgescript/surgescript_0.5.5-1.dsc Changes since the last upload: surgescript (0.5.5-1) unstable; urgency=medium . * New upstream release. + Added the ability to pause the SurgeScript VM. + Added utility macros for checking the SurgeScript version at compile time. + Introduced a dedicated module for keeping track of time. + Renamed Object.childCount to Object.__childCount. + Updated docs. * debian/copyright: + Copyright updated for current years (2021). * debian/control: + Changed versioned in "depends+breaks+replaces" to avoid version conflict. * Renamed for debian/libsurgescript0.5.5 file. * Updated debian/upstream/metadata years (2021). Regards, -- Carlos Donizete Froes [a.k.a coringao] --- End Message --- --- Begin Message --- On Sat, 23 Jan 2021 00:12:51 -0300 Carlos Donizete Froes Hi Carlos, the package looks fine, but due to the freeze (and possibly triggering a library transition -- did not verify), it should target "experimental". I've changed the suite accordingly and did an upload. Here's the patch to apply to the CVS: --- surgescript-0.5.5.orig/debian/changelog 2021-01-23 02:51:14.0 +0100 +++ surgescript-0.5.5/debian/changelog 2021-06-08 21:31:31.557014577 +0200 @@ -1,5 +1,6 @@ -surgescript (0.5.5-1) unstable; urgency=medium +surgescript (0.5.5-1) experimental; urgency=medium + [ Carlos Donizete Froes ] * New upstream release. + Added the ability to pause the SurgeScript VM. + Added utility macros for checking the SurgeScript version at compile time. @@ -13,6 +14,10 @@ * Renamed for debian/libsurgescript0.5.5 file. * Updated debian/upstream/metadata years (2021). + [ Tobias Frost ] + * Team upload. + * Upload to experimental. + -- Carlos Donizete Froes Fri, 22 Jan 2021 22:51:14 -0300 Cheers, -- tobi signature.asc Description: PGP signature --- End Message ---
Bug#987181: RFS: cpufetch/0.97-1 -- Simple yet fancy CPU architecture fetching tool
On Tue, Jun 08, 2021 at 02:50:47PM +0800, clay stan wrote:
> Tobias Frost 于2021年6月3日周四 上午1:33写道：
> >
> > Control: tags -1 moreinfo
> >
> > Hi Clay,
> >
> > here's a review:
> > - The patch: The dep3 header, the field Bug-Debian is wrong, the ITP is not
> > related to the patch
>
> Thanks, I've updated.
>
> > - The patch looks strange to me: Why do you patch the Makefile? What do you
> > want to archieve? Parts of the patching seems ok (like avoiding stomping
> > over
> > CFLAGS, but other parts seems excessive, removing sane parts to me…
>
> The original compilation parameters will also cause Lintian to report errors,
> hardening no bind now, hardening no mandatory functions.
> I'll try to solve them in debian/rules by
> https://wiki.debian.org/Hardening, but it doesn't work
>
>and the sane parts, you mean?
You've basically completly rewritten a (mostly) working Makefile
With your comment I assume that you just wanted to have hardening,
so _just_ those parts should have been patched.
And that would be:
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
CC ?= gcc
-CFLAGS+=-Wall -Wextra -pedantic -fstack-protector-all -pedantic -std=c99
+CFLAGS:=-Wall -Wextra -pedantic -fstack-protector-all -pedantic -std=c99
${CFLAGS} ${CPPFLAGS} ${LDFLAGS}
SANITY_FLAGS=-Wfloat-equal -Wshadow -Wpointer-arith
PREFIX ?= /usr
(+ adding export DEB_BUILD_MAINT_OPTIONS = hardening=+all to d/rules)
So, see it as recommendation: I'd keep patches really minimal. Or they
will create you a lot of work…
It is a burden to carry such an intrusive patch, especially if upstream
explictly expressed that he does not generally welcome patches
if they target the Makefile.
Just one example where I think the upstream part is better:
-PREFIX ?= /usr
+PREFIX = /usr
Some other stuff could be done with debhelper overrides, so
that the patch can get smaller…
But you do you… I just strongly recommend to revisit the topic.
On top, non-upstreamable patches are bad…
> > - Upstream seems to support arm, you patch that out?
>
> Upstream support arm means the mobile arm chips, like Snapdragon, MediaTek,
> not arm PC, They are not supported by Debian.
This is not a strong reason to disable arm support entirely…
(A quick internet search suggests that there is some support for Debian on e.g
Snapdragon. And there seems to be derivates; even if not, maybe someone wants
to enhance cpufetch on the basis of the Debian package.)
> > - There is no LDCFLAGS -> did you mean LDFLAGS?
>
> Yeah, I've updated. Thanks again.
>
> >
> > - (not a blocker) Please send the manpage upstream for inclusion.
Regarding the manpage: I've diffed the manpage (cpufetch.1 and
debian/cpufetch.1). They are almost identical. With just small fixes done by
you. However, you claim (sole) copyright on it. That is not appropiate.
I would patch the manpage, if it needs fixing: The header of the upstream ones
says that upstream builds it using help2man (but hav not integrated that into
their Makefile), so possibly this is another route to go: Rebuild at build
time.
--
tobi
libgrokj2k: version 9.2 uploaded
Hi Guys, Just a polite ping about my recently uploaded new package for a majour release of my library. Thanks, Aaron
Bug#989486: RFS: python-click-log/0.3.2-1 -- Logging integration for Click - Python 3.x
Nilesh Patra writes: > * The pristine tar contained .tar.gz.*, it should > instead contain .orig.tar.gz for origtargz both for the sake of > consistency and for origtargz to run fine Oops, OK, I have just re-run pristine-tar on the .orig file and committed. > * We are in freeze time, and a new version upload unless absolutely > necessary isn't appropriate[2]. This package does not seem to have any > (RC) bug or affecting any package that a version bump would be > desired. > > Hence, this should be uploaded after bullseye release. Feel free to > ping me then, and I'll happily sponsor. Also, please take a look at my > commits in salsa. > > [2]: https://release.debian.org/testing/freeze_policy.html I'm fine with waiting. After the freeze, I think it will be ready for uploading (I don't want to spam mentors.d.o during the freeze). Thanks a lot for your help! Best regards -- Fabrice Bauzac-Stehly PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
Bug#987181: RFS: cpufetch/0.97-1 -- Simple yet fancy CPU architecture fetching tool
Tobias Frost 于2021年6月3日周四 上午1:33写道： > > Control: tags -1 moreinfo > > Hi Clay, > > here's a review: > - The patch: The dep3 header, the field Bug-Debian is wrong, the ITP is not > related to the patch Thanks, I've updated. > - The patch looks strange to me: Why do you patch the Makefile? What do you > want to archieve? Parts of the patching seems ok (like avoiding stomping > over > CFLAGS, but other parts seems excessive, removing sane parts to me… The original compilation parameters will also cause Lintian to report errors, hardening no bind now, hardening no mandatory functions. I'll try to solve them in debian/rules by https://wiki.debian.org/Hardening, but it doesn't work and the sane parts, you mean? > - Upstream seems to support arm, you patch that out? Upstream support arm means the mobile arm chips, like Snapdragon, MediaTek, not arm PC, They are not supported by Debian. > - There is no LDCFLAGS -> did you mean LDFLAGS? Yeah, I've updated. Thanks again. > > - (not a blocker) Please send the manpage upstream for inclusion. > > > Waiting for your reply… > > Cheers, > tobi >
