Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client
On Fri, Nov 24, 2023 at 9:30 PM Daniel Gröber wrote: > On Fri, Nov 24, 2023 at 09:03:37PM +0200, Martin-Éric Racine wrote: > > On Fri, Nov 24, 2023 at 8:59 PM Daniel Gröber wrote: > > > On Fri, Nov 24, 2023 at 06:55:44PM +0200, Martin-Éric Racine wrote: > > > > dhcpcd (1:10.0.5-4) unstable; urgency=medium > > > > . > > > >* Attempt to fix the GNU/Hurd build. > > > > + 003_fix_FTBFS_on_Hurd.patch > > > > > > Does upstream even support hurd? Looking at ./configure: > > > > > > gnu*) OS=hurd;; # No HURD support as yet > > > > Upstream never attempted to support it. I am. > > Looking the last your three dhcpcd revisions I wonder if you shouldn't be > debugging these fundamental build issues on a porterbox or in a VM rather > than through the buildds? I don't have access to the former and am not in a position to setup the later. Anyhow, doing this via the buildd has the advantage of ensuring that I don't break anything for existing ports. Martin-Éric
Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client
On Fri, Nov 24, 2023 at 09:03:37PM +0200, Martin-Éric Racine wrote: > On Fri, Nov 24, 2023 at 8:59 PM Daniel Gröber wrote: > > On Fri, Nov 24, 2023 at 06:55:44PM +0200, Martin-Éric Racine wrote: > > > dhcpcd (1:10.0.5-4) unstable; urgency=medium > > > . > > >* Attempt to fix the GNU/Hurd build. > > > + 003_fix_FTBFS_on_Hurd.patch > > > > Does upstream even support hurd? Looking at ./configure: > > > > gnu*) OS=hurd;; # No HURD support as yet > > Upstream never attempted to support it. I am. Looking the last your three dhcpcd revisions I wonder if you shouldn't be debugging these fundamental build issues on a porterbox or in a VM rather than through the buildds? --Daniel signature.asc Description: PGP signature
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- transitional dummy package, scala-mode-el to elpa-scala-mode
Hi Nicholas, Thanks for your review! Please see my replies inline below. Nicholas D Steeves writes: > Control: retitle -1 RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] > [Team] -- Emacs major mode for editing scala source code > > Xiyue Deng writes: > > [snip] >>[ Xiyue Deng ] >>* Sync to latest upstream head (5d7cf21). > > Have you asked upstream to tag a release? > Not before your review but done by now at [1] >>* Override clean rules in d/rules to fix building. (Closes: >>#1052917) > > I believe you already know that > > override_dh_auto_clean: >/bin/true > > is an incorrect approach. > Indeed it was not ideal. Upstream depends on Cask to generated the scala-mode-pkg.el file that is used in the clean target to get the name of the generated tarball, and indeed using this lazy approach is incorrect. I've now included the generated pkg file through a patch to make this work in [2]. >>* Modernize d/watch using special substitute strings. > > Ok, but why? > I believe this provides a more robust way of detecting tags and should be an encouraged practices. From my own experience, when I find a d/watch file that doesn't work I may search for other packages to learn from existing practices, and some may not work well as different upstream may follow different conventions. The substitute strings use a more robust and tested regexp that works most of the time, and promoting its use may save people's time instead of working on an ad-hoc regexp. >>* Add more metadata in d/upstream/metadata. > > https://github.com/hvesalai/emacs-scala-mode/commits/master > > is a git history log, not a changelog nor release notes. > I thought the git history log may be considered an alternative form of a Changelog. Looks like I was wrong except for projects that requires the same format across changelog/git history/release notes. I've dropped that line in [3]. >>* Update year and Upstream-Contact and add myself in d/copyright. > > Why did you add yourself? > https://en.wikipedia.org/wiki/Threshold_of_originality > > I'm happy to support your claim, but you'll need to work for it in more > than a "sweat of the brow"/mechanical sense. > To be honest, the only reason I did this is to suppress the "update-debian-copyright" lintian warning which is actually experimental. I believe what I did was in the same nature as Sławomir did in 2020 though admittedly not to the same extent, so I've reverted this part in [4]. >>* Use xz compression in d/gbp.conf. > > Why is this useful when it has been the default since gbp 0.9.15? > I'm pretty sure that if I don't add this "git deborig" will create the tarball using gzip instead. And it looks like the commit from 0.9.15 just changed the value in the comment[5]. Please let me know if there is any other option that I missed that makes it use xz. > > Best, > Nicholas > I've committed the new changes (sans "Release to unstable" commit) to the team repo and reuploaded to mentors[6]. PTAL, and TIA! [1] https://github.com/hvesalai/emacs-scala-mode/issues/182 [2] https://salsa.debian.org/emacsen-team/scala-mode-el/-/commit/bc32e3dbf3983c5cf8d4eab98be25e67a9016310 [3] https://salsa.debian.org/emacsen-team/scala-mode-el/-/commit/0ddf10c8e88ae0e6d52ce02968dd678aceeab6f7 [4] https://salsa.debian.org/emacsen-team/scala-mode-el/-/commit/203a3d718956f14bc991b61e4bf9a02bdacd1756 [5] https://salsa.debian.org/agx/git-buildpackage/-/commit/d1960b3dc0dfbb6be2183e555e615864468b234c [6] https://mentors.debian.net/package/scala-mode-el/ -- Xiyue Deng signature.asc Description: PGP signature
Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client
On Fri, Nov 24, 2023 at 8:59 PM Daniel Gröber wrote: > On Fri, Nov 24, 2023 at 06:55:44PM +0200, Martin-Éric Racine wrote: > > dhcpcd (1:10.0.5-4) unstable; urgency=medium > > . > >* Attempt to fix the GNU/Hurd build. > > + 003_fix_FTBFS_on_Hurd.patch > > Does upstream even support hurd? Looking at ./configure: > > gnu*) OS=hurd;; # No HURD support as yet Upstream never attempted to support it. I am. Martin-Éric
Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client
Hi Martin, On Fri, Nov 24, 2023 at 06:55:44PM +0200, Martin-Éric Racine wrote: > dhcpcd (1:10.0.5-4) unstable; urgency=medium > . >* Attempt to fix the GNU/Hurd build. > + 003_fix_FTBFS_on_Hurd.patch Does upstream even support hurd? Looking at ./configure: gnu*) OS=hurd;; # No HURD support as yet doesn't look promising. --Daniel signature.asc Description: PGP signature
Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client
Package: sponsorship-requests Severity: important Tags: ftbfs patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear mentors, I am looking for a sponsor for my package "dhcpcd": * Package name : dhcpcd Version : 1:10.0.5-4 Upstream contact : Roy Marples * URL : https://roy.marples.name/projects/dhcpcd * License : Expat, public-domain, ISC, BSD-3-Clause, BSD-2-Clause-NETBSD, GPL-3+, BSD-2 * Vcs : https://salsa.debian.org/debian/dhcpcd Section : net The source builds the following binary packages: dhcpcd-base - DHCPv4 and DHCPv6 dual-stack client (binaries and exit hooks) dhcpcd - DHCPv4 and DHCPv6 dual-stack client (init.d script & systemd unit) dhcpcd5 - DHCPv4 and DHCPv6 dual-stack client (dummy transitional package) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dhcpcd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dhcpcd/dhcpcd_10.0.5-4.dsc Changes since the last upload: dhcpcd (1:10.0.5-4) unstable; urgency=medium . * Attempt to fix the GNU/Hurd build. + 003_fix_FTBFS_on_Hurd.patch Regards, Martin-Éric -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmVg1ZAACgkQrh+Cd8S0 17b/7RAAoa1y2n29K6JsaI0Hnq+iFo0GEu638+AFl3tMfUwUgZt4s9hpqsrzkOcz T2LtEGtTmPCNairmC/KWMN/tqSuLR/P9l8snD04DJi6aSYQahqVOSEqb/Jdah+C9 f2E5BxLwXY2CAfSPsl+7hb5VudLfB0zu2J4Xb6Olfyn2FpJ5HyLFjo7i4cFWrZ4c feDpRzXpp87sJrvKQJbQRWMqMGbCYcDoYi0c93PxS7V0xJn6dQFpg0xOreH+CaW0 v18nKw6HdCJJAuiBJlngFqsdcEVrot4prDEUf5/eejnFvHcS1IEmdLfsFmKUOpUN t4vwX3VW5JOflSTWSOSDHnidNG5lIBpKYP2ryYEl74GyysTYX2DSsugtDpDfyiDD MIFcXPy8X3DFRZNaAZxs66pSo2SGBkDMTLKlvv/1GK7RQnl9iS24EGK7kAmwGXVN NJg5JPUKJytT4DOz2f3no4I2hYRvewoJXydWnOugk/LBFTHRqwf13d0s4pC3mXDl UWzQuU2Moqv/vt15Z2v/CgVk1CDseddjE40hVJK2JMhwBJcMzuYcgEv2kfGAPeJi WLTZgmsgH3dfK0itCY7xPJtMhuyCAueo5hsp/bDLkT/3cTFtzhxknb8yeWZ57sX2 Nwucl7sfsyV3Ilhyz2mM//wfh+X0/ACR1tRvnZDQz+reKYxUQio= =+eLR -END PGP SIGNATURE-
Bug#1056643: RFS: gtklock/2.1.0-1 [ITP] -- GTK-based lockscreen for wayland
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Control: block 1052418 by -1 Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "gtklock": * Package name : gtklock Version : 2.1.0-1 Upstream contact : Jovan Lanik * URL : https://github.com/jovanlanik/gtklock * License : GPL-3+ * Vcs : https://salsa.debian.org/Maytha8/gtklock Section : misc The source builds the following binary packages: gtklock - GTK-based lockscreen for wayland To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gtklock/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/gtklock/gtklock_2.1.0-1.dsc Changes for the initial release: gtklock (2.1.0-1) UNRELEASED; urgency=medium . * Initial release. (Closes: #1052418) Regards, - -- Maytham Alsudany -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEESl/RzRFQh8wD3DXB1ZeJcgbF8H8FAmVgdFEACgkQ1ZeJcgbF 8H88mA/9GMRiflIID3HtYQx9Q64YYzxCy7+SwzXfFiDq3gPA+jm2DzrHQ6lK62Mr W73SLWYF8P5gRDwdAuOzYr5kWMhn94YnDNvIOBAtieOE+uFTntHr3lb6Z+VrlL9t jwH6BccJAtYDaGfk2CbNlaFD0OuVJVdpMfwl+YwCpB/JogqfddZc5xwe3Z9z1a4S pHgFZRfao6qCPMnInDrjovfRifC3P+5kevNuJucxFcTZvia9I+begWZL3O6GGcKF qArc7mrC9pBF/2i74vD7jtCyv/8iTQyA8408fQhLzzk0PkkL7++FbIWrC6H2Bqq7 2hn1X5NxWd8YkAvB4X/GvpPaadqyLdtpgSgMLUoHhA7qF7GshbinJFFjuV7+bmQ+ h1koTb+cLCGIlkQ3xhlIpEkftLFNqLy0RzeU3iy1nRhn81YicsUuv3GUdVMM/Bt5 eOgadZxbs3lkTUfnngyxyAJB48natNRjvNTaP5YvQMUOXzpQP9Htl1g4GoYY5XNw +MbLoSgLDXD8mmDkeIJ1H7dCYKC/vgjpkmn6uVBjx0VcWDquQaaEDl9l6FDlH4SG k1/uimBYLPQMGbx/4Bi5TaNiaosPpPt3H7CRSqi0t/eFVLz6beHgh6r7cTuSk3sf UOVlArjpJo1WUKKy+84l1C9tgtC2s9ruslIaSQUnxW+OTBXGW94= =vrTH -END PGP SIGNATURE-