Re: Help with debian/watch file
Hilmar, Try the following: opts="searchmode=plain,repack,compression=xz,repacksuffix=+ds1,dversionmangle=s/ \+ds1//, \ pgpsigurlmangle=s%$%.asc%" \ https://api.github.com/repos/silnrsi/teckit/releases \ https://github.com/silnrsi/teckit/releases/download/v\d+\.\d+\.\d+/ teckit@any_vers...@.tar.gz On Thursday, February 22, 2024 3:59:18 PM MST Hilmar Preuße wrote: > Hello, > > I could need some help with a debian/watch file [1]. The file is mostly > not written by me, I just replaced just some regexes to introduce the > correct versioning scheme. When running "uscan -vv" it downloads > correctly upstreams tar ball, the pgp is checked and the tar ball is > repackaged. Unfortunately the new upstream version is determined to be > $version.$version: teckit_2.5.12.2.5.12+ds1.orig.tar.xz the name of the > reduced tar ball is wrong and uscan (incorrectly) reports a new upstream > version. > > What do I do wrong? > > Thanks, >Hilmar > > [1] https://github.com/debian-tex/teckit/blob/master/debian/watch > -- > Testmail > -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1064485: RFS: samplebrain/0.18.5-1 [ITP] -- Custom sample smashing app designed by Aphex Twin
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "samplebrain": * Package name : samplebrain Version : 0.18.5-1 Upstream contact : Dave Griffiths * URL : http://thentrythis.org/projects/samplebrain * License : CC0-1.0, GPL-2+ * Vcs : https://salsa.debian.org/touss-guest/samplebrain Section : sound The source builds the following binary packages: samplebrain - Custom sample smashing app designed by Aphex Twin To access further information about this package, please visit the following URL: https://mentors.debian.net/package/samplebrain/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/s/samplebrain/samplebrain_0.18.5-1.dsc Changes for the initial release: samplebrain (0.18.5-1) unstable; urgency=medium . * Initial release. (Closes: 1040745) Regards, -- tous
Help with debian/watch file
Hello, I could need some help with a debian/watch file [1]. The file is mostly not written by me, I just replaced just some regexes to introduce the correct versioning scheme. When running "uscan -vv" it downloads correctly upstreams tar ball, the pgp is checked and the tar ball is repackaged. Unfortunately the new upstream version is determined to be $version.$version: teckit_2.5.12.2.5.12+ds1.orig.tar.xz the name of the reduced tar ball is wrong and uscan (incorrectly) reports a new upstream version. What do I do wrong? Thanks, Hilmar [1] https://github.com/debian-tex/teckit/blob/master/debian/watch -- Testmail OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255
Control: tags -1 moreinfo Hi Joachim, review based on the dsc containing: Checksums-Sha256: 75aa7ed495b21d360340c84a4def6e16e25ecc36dab91e2481631993b2624bde 5128639 vzlogger_0.8.3.orig.tar.gz c6737877696173e8daa4c9e4d4a1b6663ae5256f669c87554360e665f154e292 6252 vzlogger_0.8.3-1.debian.tar.xz It is only a partial review, especially I did not do a d/copyright review yet. Please check my remarks and remove the moreinfo tag when ready. On Tue, Feb 20, 2024 at 12:34:04PM +0100, Joachim Zobel wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "vzlogger": > > * Package name : vzlogger > Version : 3.1-4 > Upstream contact : Joachim Zobel > * URL : http://wiki.volkszaehler.org/software/controller/vzlogger > * License : GPL-3 > * Vcs : https://github.com/volkszaehler/vzlogger > Section : net > > The source builds the following binary packages: > > vzlogger - program to read measurements from smart meters and log them > to Influxdb or forward them via MQTT. > > vzlogger is a tool to read and log measurements of a wide variety of > smart meters and sensors. It supports various commonly used protocols > such as s0, d0, sml, oms and others. It can write these data to an > Influxdb, forward them via MQTT, make them available via HTTP or eport > them to a volkszaehler.org middleware. > > The package is maintained in the upstream repository. Upstream (which I > am part of) currently builds native packages. These are patched (a > switch from native to quilt, a different changelog and a version >= 3.0 > for the dependency on openssl) to make them more suitable for debian. > The package is therefore availabe in the upstream repo Yeah, format 3.0 quilt is the way, it is not a native package. > https://github.com/volkszaehler/vzlogger.git > > on branch debian-0.8.3-1. (There is no such branch on that repo, but a "debian" one.) Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for recommendation how to layout the repository used for packaging, I'd even recommend to use an extra repository for the packaging. > Alternatively, you can download thepackage with 'dget' using this > command: > > dget -x > http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.3-1.dsc > > Regards, > -- > Joachim Zobel As you are upstream: https://wiki.debian.org/UpstreamGuide d/source/lintian-overrides - delete the overrides, seems to be some remnant of earlier packaging. d/DEBIAN_RELEASE.txt - delete this file; the information contained in this files would not be a process how to create a package for Debian. (and if you need a file describing certain unusal aspects of the Debian packaging, it would be README.source (see Debian Policy §4.14) I recommend checking out git-buildpackage: https://honk.sigxcpu.org/piki/projects/git-buildpackage/ https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/ - remove Debian_release.patch -- this is not needed, you work with your debian/ directory and evolve it, you do not patch it when you create a new version. d/control - specify Rules-Require-Root - you manually depend on libsml1. Can you expand why this is needed? - Build-Depend: s/pkg-config/pkgconf - remove versions from the versioned build dependencies, if the debpendency is already fulfilled in oldstable: - libjson-c-dev, libcurl4-openssl-dev, d/postinst / postrm - When you create a user, it should start with "_" - see policy 9.2.1 - Another option might be using systemd's DynamicUser feature to create the user at runtime. (bonus: some hardening for free.) - there's systemd-sysuser (works also without systemd as init system) to use sysusers.d - do not delete users/groups on package removal. As you are involved with upstream: The manpage, initfile, systemd service file should probably be included in the upstream part, it is not only useful for Debian alone. Linitian emits: W: vzlogger source: build-depends-on-obsolete-package Build-Depends: pkg-config (>= 0.25) => pkgconf W: vzlogger: groff-message troff::5: warning: cannot select font 'CB' [usr/share/man/man8/vzlogger.8.gz:1] I: vzlogger source: debian-rules-parses-dpkg-parsechangelog [debian/rules:12] I: vzlogger: file-references-package-build-path [usr/bin/vzlogger] I: vzlogger: file-references-package-build-path [usr/lib/static/libvz.a] I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger] I: vzlogger: hardening-no-fortify-functions [usr/bin/vzlogger] I: vzlogger: systemd-service-file-missing-documentation-key [usr/lib/systemd/system/vzlogger.service] I: vzlogger source: unused-override odd-historical-debian-changelog-version *0.3.4-rc1* [debian/source/lintian-overrides:2] P: vzlogger source: capitalization-in-override-comment odd-historical-debian-changelog-version debian Debian [debian/source/lintian-overrides:1] P: vzlogger source: silent-on-rules-requiring-root [debian/c
Bug#1061290: RFS: rgbds/0.7.0-3 [ITP] -- Game Boy ASM programming tools
I'm not a DD so I can't upload this, but I took a look. I see you've addressed most of the comments on Mentors in the repository on GitHub, so I'm reviewing that rather than the older upload on Mentors. Build-Depends lists pkg-config, which is a transitional package since bookworm that should be replaced with the newer pkgconf. lintian warns about this: W: rgbds source: build-depends-on-obsolete-package Build-Depends: pkg-config => pkgconf This is just a suggestion/tip and not at all required, but it's popular to use `wrap-and-sort -ast` to put each dependency on its own line (with a trailing comma). This would make the diff clearer in commits like d1842536 and 22baba8b. The years in the Copyright field of the "Files: *" stanza of d/copyright look outdated: "1997-2020" when LICENSE says "1997-2023" since commit f8af5696. Not required by all sponsors, but Emmanuel on Mentors and Tobias here suggested maintaining the packaging Git repository on Salsa (and updating the Vcs- fields): https://salsa.debian.org/ https://salsa.debian.org/games-team https://salsa.debian.org/debian You may also want to look into git-buildpackage with pristine-tar and a DEP-14 branch layout: https://honk.sigxcpu.org/piki/projects/git-buildpackage/ https://www.eyrie.org/~eagle/notes/debian/git.html https://dep-team.pages.debian.net/deps/dep14/ Looks OK otherwise to me, and the package builds fine under sbuild with no lintian tags (even informational or pedantic) other than the obsolete package warning above; nice work! So, once the pkg-config -> pkgconf switch and copyright years update are done, I think it's good enough for someone to upload. -- Patrick "P. J." McDermott: http://www.pehjota.net/ Lead Developer, ProteanOS: http://www.proteanos.com/ Founder and CEO, Libiquity: http://www.libiquity.com/
Re: Bug#1064346: Source is missing errors on HTML source files
On 2024-02-22 11:37 +0530, Shriram Ravindranathan wrote: > Thank you Bastien, > I tried doing this but it appears that the scripts to build these example > files all depend on having the highlight binary itself installed on the > machine. I am unsure whether it is okay to have the package depend on itself > for building. Packages that use themselves to build are problematic for bootstrapping and cross-building. When cross-building you can't (usually) run the binaries just built because they are the wrong architecture. When bootstrapping packages that depend on themselves cause dependency loops which are a pain (we can't build foo because we don't have foo yet). We have 'build profiles' (older name 'staged builds') to deal with this. i.e you define a minimum 'stage1' build profile which does not have the circular dependency (and the normal build which does) so the building of the final version can be automated. The choices here are to 1) use the binary just build during the build 2) have a self dependency and use a packaged binary 1) Is simple but prevents the package cross-building. Usually the best thing to do is just skip that part if cross-building (you can live without the examples) Just ensure that the build doesn't fail due to missing files. 2) Works for cross-building (by the magic of multiarch) but you should add a stage notation so it can easily be built for new architectures, which is a bit of a faff. In case '2' you have to worry about version skew. How much does it matter if examples/whatever are built with the previous/an older version of the package? Case '1' avoids this. This is very specific to the package in question: sometimes it needs to be exactly the same, sometimes a version from a decade ago will be just fine. This is the main reason people usually pick option '1'. https://wiki.debian.org/BuildProfileSpec https://wiki.debian.org/DebianBootstrap https://wiki.debian.org/CrossBuildPackagingGuidelines All the above is quite a lot to take in, and you don't need to worry too much, but it is a good idea to at least have this stuff in the back of your mind when packaging. Ideally this would all work correctly on the whole archive, and packagers are the ones best-placed to stick in the necessary runes. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
