Re: New contributor question
On Sun, 2024-02-11 at 17:04 -0500, Darren Tomblin wrote: > I’m wondering what I have to do to say I want to work on a bug Which bug report are you looking at? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Package remains in status "Uploaded"
On Wed, 2023-09-27 at 21:21 +0200, Niels Thykier wrote: > Turns out a give-back is not sufficient (wrong state). Seems like you > will need to find a buildd admin. Try debian-wb-t...@lists.debian.org or > loon...@buildd.debian.org The folks on #debian-ports said it needs a maintainer upload that has a version number higher than the current loong64 build. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: license-reconcile
On Mon, 2023-09-18 at 12:51 +0100, Peter Blackman wrote: > Is anyone aware of an equivalent package? There are many tools in this area: https://wiki.debian.org/CopyrightReviewTools Probably the best one is scancode-toolkit, but it isn't in Debian. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1026335: Review of the initial packaging of the carl9170 firmware
On Sun, 2023-08-13 at 11:51 +, John Scott wrote: > Because carl9170 is largely under the GPL and we're obligated to > distribute complete sources for our binaries, I've set Static-Built- > Using on both gcc (because of libgcc) and Newlib. FYI, that wasn't the correct thing to do. Built-Using is for license compliance cases: https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using Static-Built-Using is for other static linking or embedding cases. The static linking wiki page needs updates for Static-Built-Using and the predecessors of it used by the Rust and Golang packages. https://wiki.debian.org/StaticLinking -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: How to handle breakages when the size of a class in a shared lib increases?
On Wed, 2023-07-12 at 06:49 +, Sune Vuorela wrote: > Either you need to do a packagename change (and debian specific SONAME > iwth all that entails; or maybe there is a way to restore the old abi. > Can you provide a full diff of header,implementation of the relevant > classes ? You can also obtain an ABI diff using abipkgdiff (from abigail-tools) and pkg-abidiff (not in Debian). These are complementary tools, use both. https://github.com/lvc/pkg-abidiff -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bookworm backport status
On Mon, 2023-06-19 at 14:40 +0200, Alec Leamas wrote: > Anyone which can shed some light on the bookworm-backports status and > perhaps also where my upload ended up? I suggest checking the debian-backports mailing list archives and if the answer isn't there, ask on the list or on the IRC channel. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Packaging git submodule as multi upstream tarballs?
On Tue, 2023-06-13 at 16:48 +0200, Daniel Gröber wrote: > I'm working on packaging prjtrellis[1] which has a git submodule that is > required for building. My plan is to use dpkg-source's multi upstream > tarball support to do this. This appears to be the repo of the submodule: https://github.com/YosysHQ/prjtrellis-db I note Arch Linux uses a separate database package: $ grep database .github/archlinux/PKGBUILD # The database is provided in a separate package rmdir "$pkgdir"/usr/share/$_prj/database > [1]: https://github.com/YosysHQ/prjtrellis This repo contains embedded code copies, please follow this advice: https://wiki.debian.org/EmbeddedCopies -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Questions about packaging the 'googleapis' project
On Tue, 2023-06-13 at 19:22 +0200, Oliver Reiche wrote: > 1. Due to the missing build description, is it ok if the maintainer > provides a Makefile for building the C++ libraries in ./debian? ... > 4. Such a Makefile (and control file) will be quite lengthy. The upstream repo seems to use bazel as its build system, at least according to the README. Is that not usable here? The bazel tool appears to be packaged in bazel-bootstrap in Debian. I note that some of the BUILD.bazel files are themselves generated files, so you will also need to figure out how to regenerate them. $ git grep -l 'This file was automatically generated by' | wc -l 396 > 7. With no version given, what version should we use for this package? I noticed that upstream has a common-protos-1_3_1 tag, perhaps they could be convinced to add a version number? Or use the default version number uscan uses for unversioned repos. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1036955: RFS: trurl/0.7-1 -- command line tool for URL parsing and manipulation
On Tue, 2023-05-30 at 21:41 +0200, Michael Ablassmeier wrote: > trurl (0.7-1) unstable; urgency=medium > . > * New upstream release. Uploaded. Upstream has added -Werror to the default CFLAGS. It isn't recommended to do this in released software, because it means a lot more build failures when compilers get updated in distros. Please consider sending upstream a patch to move that to their CI scripts instead. Most of the suggestions I listed in my first review still apply: https://lists.debian.org/msgid-search/551f9af844ea1ebe0b814678c5560e42303d8299.ca...@debian.org -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1036237: RFS: libwebservice-musicbrainz-perl/1.0.6-1 -- XML based Web service API to the MusicBrainz database
On Wed, 2023-05-17 at 22:10 +0200, Michael Ablassmeier wrote: > I am looking for a sponsor for my package > "libwebservice-musicbrainz-perl": I suggest moving your Perl packages into the Perl team. You'll get shared maintenance and sponsorship when needed. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system
On Mon, 2023-05-15 at 18:14 +0200, Oliver Reiche wrote: > Could you please tell me if it is acceptable for Debian that I have > build dependencies (proto files) in ./debian/third_party, with the > copyright file explicity mentioning those? Generally all build dependencies should be packaged separately instead. https://wiki.debian.org/EmbeddedCopies -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Nyxt Browser package
On Mon, 2023-04-24 at 13:54 -0700, Soren Stoutner wrote: > It is a pleasure to make the acquaintance with a fellow developer > working on packaging a browser based on Qt WebEngine. The docs suggest WebKitGTK, QT WebEngine support is experimental. https://github.com/atlas-engineer/nyxt/ Nyxt has engine support for WebKit and experimental support for WebEngine/Blink. https://github.com/atlas-engineer/nyxt/blob/master/documents/README.org Nyxt is available in both WebKit and WebEngine (experimental) flavors. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Backporting package which missed bookworm.
On Mon, 2023-04-17 at 18:02 +0200, Alec Leamas wrote: > Hence I need to use the backports. I see no particular problem with > backporting 5.8.0 from sid/testing once it's there to bookworm-backports. This can only happen after it reaches testing, so after the bookworm release after testing becomes trixie and opencpn migrates. > However, what about bullseye-backports? At which point can I backport > the package in sid (yet ot be uploaded) to bullseye? Of course, what I > want is to do it "now". That isn't possible, but you can upload to bullseye-backports-sloppy: https://backports.debian.org/Contribute/#index4h3 With the release of a new stable version uploading packages with versions greater than in new stable or new stable-security are not allowed. So if you want to upload a new package version from e.g. bookworm to buster, use buster-backports-sloppy as the target distribution. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1034442: RFS: trurl/0.4-1 [ITP] -- command line tool for URL parsing and manipulation
Control: close -1
On Sat, 2023-04-15 at 15:59 +0200, Michael Ablassmeier wrote:
> I am looking for a sponsor for my package "trurl":
What is the status of getting your new OpenPGP key accepted? Some links
related to that below, if you are having trouble with keysigning then
key endorsements might be another option.
https://keyring.debian.org/
https://keyring.debian.org/replacing_keys.html
https://wiki.debian.org/Keysigning/Offers
https://lists.debian.org/msgid-search/20200913071104.qcx76k25q5dpt...@enricozini.org
https://lists.debian.org/msgid-search/20201108205109.6nzboemjkr5ik...@enricozini.org
Package looks good, uploaded it to NEW.
You might want to add some autopkgtests, I think this would require
patching test.pl to use PATH instead of ./ and then patching Makefile
to set PATH to include the build directory (be sure to send those to
upstream). Then you will be able to run the tests against the installed
binary /usr/bin/trurl instead of the build dir.
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst
https://wiki.debian.org/ContinuousIntegration
https://ci.debian.net/doc/
Tools' complaints that might be worth fixing upstream or in Debian:
$ lintian --info --show-overrides --color auto --display-info
--display-experimental --pedantic
I: trurl source: debian-watch-file-is-missing
I: trurl: hardening-no-bindnow [usr/bin/trurl]
I: trurl: typo-in-manual-page occurances occurrences
[usr/share/man/man1/trurl.1.gz:39]
X: trurl source: upstream-metadata-file-is-missing
$ find . -type f -exec anorack {} +
./checksrc.pl:851: a extended -> an extended /Ekst'EndI2d/
$ codespell --quiet-level=3 .
./trurl.1:39: occurances ==> occurrences
./trurl.c:859: inbetween ==> between, in between
./RELEASE-NOTES:20: messsage ==> message
$ find . -type f -exec spellintian {} +
./trurl.1: occurances -> occurrences
# wrap-and-sort makes VCS diffs of package info easier to read
$ wrap-and-sort --short-indent --wrap-always --sort-binary-packages
--trailing-comma --dry-run
--- Dry run, these files would be modified ---
debian/control
$ find . -type f -iname '*.[1-9]' -exec mandoc -T lint -W warning {} +
mandoc: ./trurl.1:5:13: WARNING: cannot parse date, using it verbatim: TH 3 Apr
2023
$ find .. -maxdepth 1 -type f -iwholename '../*.build' -exec blhc --all {} +
CFLAGS missing (-fPIE): cc -g -O2
-ffile-prefix-map=/home/pabs/devel/debian/mentors/trurl-0.4=.
-fstack-protector-strong -Wformat -Werror=format-security -W -Wall -pedantic -g
-Wdate-time -D_FORTIFY_SOURCE=2 -c -o trurl.o trurl.c
LDFLAGS missing (-fPIE -pie -Wl,-z,now): cc -Wl,-z,relro trurl.o -lcurl -o
trurl
$ find . -type f -iwholename './debian/*/bin/*' -exec hardening-check --quiet
{} +
./debian/trurl/usr/bin/trurl:
Immediate binding: no, not found!
Control flow integrity: no, not found!
$ find . -type f -iname '*.yml' -exec yamllint --config-data relaxed {} +
./.github/workflows/makefile.yml
21:81 warning line too long (122 > 80 characters) (line-length)
30:81 warning line too long (86 > 80 characters) (line-length)
48:7 warning wrong indentation: expected 4 but found 6 (indentation)
$ perlcritic --noprofile --verbose '%f:%l:%c: %m. %e. Near `%r` (Severity:
%s)\n' --gentle .
checksrc.pl:100:5: Bareword file handle opened. See pages 202,204 of PBP. Near
`open(W, "<$dir/checksrc.skip") or return;` (Severity: 5)
checksrc.pl:100:5: Two-argument "open" used. See page 207 of PBP. Near `open(W,
"<$dir/checksrc.skip") or return;` (Severity: 5)
checksrc.pl:382:5: Bareword file handle opened. See pages 202,204 of PBP. Near
`open(R, "<$file") || die "failed to open $file";` (Severity: 5)
checksrc.pl:382:5: Two-argument "open" used. See page 207 of PBP. Near `open(R,
"<$file") || die "failed to open $file";` (Severity: 5)
$ cppcheck -j1 --quiet --enable=all .
trurl.c:517:9: style: The scope of the variable 'i' can be reduced.
[variableScope]
int i;
^
trurl.c:788:7: style: The scope of the variable 'rc' can be reduced.
[variableScope]
int rc;
^
trurl.c:790:9: style: The scope of the variable 'oldnq' can be reduced.
[variableScope]
char *oldnq;
^
trurl.c:516:11: style: Local variable 'set' shadows outer function
[shadowFunction]
char *set = node->data;
^
trurl.c:509:13: note: Shadowed declaration
static void set(CURLU *uh,
^
trurl.c:516:11: note: Shadow variable
char *set = node->data;
^
trurl.c:622:9: style: Local variable 'i' shadows outer variable [shadowVariable]
int i;
^
trurl.c:606:7: note: Shadowed declaration
int i;
^
trurl.c:622:9: note: Shadow variable
int i;
^
trurl.c:187:17: style: struct member 'option::output' is never used.
[unusedStructMember]
unsigned char output;
^
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#1033809: RFS: tagainijisho/1.2.2-1 [ITP] -- Japanese dictionary and learning assistant
On Sat, 2023-04-01 at 20:27 -0700, Bryan Gardiner wrote: > ... sponsor to help me reintroduce "tagainijisho" into Debian: Please note the extra steps needed when reintroducing packages: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#reintroducing-packages -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy
On Tue, 2023-03-14 at 18:41 -0700, Soren Stoutner wrote: > I am one of the Debian Qt WebEngine maintainers, and I also submit > code to the upstream Qt project. > > The Salsa link you included appears to be a bit misinformed about > security support for Qt WebEngine in Debian. I was just relaying the opinion of the Debian Security Team. I suggest you contact them about the status of Qt WebEngine security support and updating the comments in the debian-security-support package. I don't see Debian security updates nor stable updates of Qt WebEngine for current/previous Debian releases so far, but I am very glad to hear that they are being worked on for the Debian bookworm release at least. https://lists.debian.org/debian-security-announce/ https://lists.debian.org/debian-announce/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy
On Sat, 2023-03-11 at 14:41 -0700, Soren Stoutner wrote: > * URL : https://www.stoutner.com/privacy-browser-pc/ > privacybrowser - web browser that respects your privacy I note that this browser depends on Qt WebEngine, all the Qt based web engines are not security supported in Debian. I encourage you to switch to a browser engine that is security supported, or discuss with the Debian and upstream Qt web engine maintainers to add such support. https://salsa.debian.org/debian/debian-security-support/-/blob/master/security-support-limited * qtwebengine-opensource-src: No security support upstream and backports not feasible, only for use on trusted content * qtwebkit: No security support upstream and backports not feasible, only for use on trusted content * qtwebkit-opensource-src: No security support upstream and backports not feasible, only for use on trusted content * kde4libs: khtml has no security support upstream, only for use on trusted content * khtml: khtml has no security support upstream, only for use on trusted content, see #1004293 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: hurd-i386: Right way to disable tests
On Wed, 2022-11-09 at 13:47 +0100, Mathieu Malaterre wrote: > I see that jpeg-xl test suite is running of out time hurd-i386: > What would be the "right" way to disable the test in d/rules ? I suggest instead trying to debug it on the porterbox where there is no sbuild based timeout to contend with. The folks on the Debian Hurd mailing list/IRC can probably also provide assistance with debugging. If you have no time to debug, then just leave it to FTBFS for now. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1023119: RFS: cruft-ng/0.9.47 with new dh-cruft binary package -- tool that help identify system files)
On Sat, 2022-11-05 at 01:44 +0100, Alexandre Detiste wrote: > So this will be 0.9.48. Please upload a source package to mentors.debian.net or elsewhere and I will review and upload the package including dh-cruft. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: doubts about debian/copyrights
On Sat, 2022-10-22 at 15:59 +0200, Fabio Fantoni wrote: > Which would be the best tool(s) to get a good starting debian/copyright > and decrease the time it takes to complete and fix it? Allegedly scancode is the best option for that, but it isn't in Debian. I think decopy/licensecheck are the best ones already in Debian. https://wiki.debian.org/CopyrightReviewTools https://github.com/nexB/scancode-toolkit/ Personally I afterwards manually review each file and check all of the details, since the Debian archive admins will be doing that anyway. I find that a keyboard-driven file manager like mc works for this. > decopy spotted one file (usr/share/icons/Mint-X/apps/96/miro.svg) with > license "CC-BY", I tried a search for found the specific license used > but I not found, in mint-theme instead for example about a license doubt > I went to look for the origin and I found it and solved it > (https://salsa.debian.org/cinnamon-team/mint-themes/-/commit/dcf71951df39f326ea9057d39095f7e94926bf19), > > regarding this file, however, the site mentioned inside no longer exists > and therefore I have not found a certain answer. All the sites mentioned in that commit work for me: https://github.com/shimmerproject/Greybird https://shimmerproject.org/ > there are also some other files with "creative common" found inside it > with a grep but that was not spotted by decopy and also in these there > aren't details on the exact license Might be worth filing bugs on decopy about these missing detections. As Andrew says, best ask upstream about any unclear licenses. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#1008882: RFS: odr-audioenc/3.2.0-1 [ITP] -- DAB and DAB+ encoder that integrates into the ODR-mmbTools
On Fri, 2022-10-21 at 17:29 +0200, Robin Alexander wrote: > 1. Why didn't the "source-is-missing" error show on my environment > (prior to push the package with dput)? Is there a specific lintian setup > that I missed? FYI, my packaging environment runs on bullseye (I tried > sid yesterday, but somehow there was a problem with one missing package > that was preventing apt upgrade and install) The mentors server runs lintian from bullseye-backports not bullseye, that is likely the reason that you are getting different results. In general package building and testing is done in sid environments, so you might want to use sbuild/pbuilder to at least get a sid chroot for building and testing and or a sid virtual machine for complex testing. The reason for the apt issues you encountered is that there is a Perl transition in progress. Please subscribe to debian-devel-announce. https://lists.debian.org/msgid-search/Y07wZyTNjNTxIsYI@estella.local.invalid > 2. The "source-is-missing" error is actually not a missing file but a > file (libtoolame-dab/html/psycho.html) with too-long lines. Is there any > action I must take to make lintian happy or can the package be accepted > "as-is" ? libtoolame-dab sounds like an embedded code copy that should be packaged separately. I note that some parts of it are already in Debian in twolame. Other parts aren't though. The naming of the two is very similar too. So it seems to clearly be either a local fork, an older version of libtwolame or an embedded code copy of a fork of libtwolame. It would be good if you could clarify the situation with upstream and try to get them to remove the copy or merge the fork further upstream. Please note that forks and code copies should be registered with the Debian security team so that they fix security bugs in both copies: https://wiki.debian.org/EmbeddedCopies If I look at the twolame source package then I see that psycho.html is present there too, but it is automatically generated from a text file. They clearly are not the same file, asciidoc builds the twolame HTML. When I convert the two HTML files to plain text using `w3m -dump` and then compare them with wdiff or meld (accounting for bugs in w3m, the different name and different quote types), the twolame version is definitely the newer documentation since there are sentence and word additions. I notice that libtoolame-dab also contains a 'text'dir, but the psy.text file in that directory doesn't contain any of the doc text. wdiff <(cp -f ./odr-audioenc-3.3.1/libtoolame-dab/html/psycho.html . ; sed -i '/style/,/STYLE/d' psycho.html ; w3m -dump psycho.html) <(w3m -dump ./twolame-0.4.0/doc/html/psycho.html | sed "s/’/'/g;s/TwoLAME/tooLAME/g") I'm not sure what to think of this, but two scenarios I can think of: The libtoolame-dab text directory used to have a text file that was the source of the HTML file and the text got dropped. This may have been an LGPL violation when it was done if the HTML was built from the text. The libtoolame documentation (inherited by libtoolame-dab) was always maintained in plain HTML and then later when tooLAME got renamed to TwoLAME, they converted it to asciidoc format for easier maintenance. Given the way the style tag contents are formatted and some of the mistakes in the libtoolame-dab HTML, probably it was the second one. Please add an override explaining that it is manually maintained. libtoolame-dab definitely needs to be split out of odr-audioenc, rebased on the latest TwoLAME and merged into it too though. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#1008882: RFS: odr-audioenc/3.2.0-1 [ITP] -- DAB and DAB+ encoder that integrates into the ODR-mmbTools
On Thu, 2022-10-20 at 14:42 +0200, Robin Alexander wrote: > I should have written instead that the upstream odr-audioenc *INCLUDES > MODIFIED SOURCES* of fdk-aac (Fraunhofer FDK AAC Codec Library for > Android). Since the original version of the Fraunhofer FDK AAC Codec > Library for Android (I believe it is libfdk-aac-dev) is non-free, I > guess that the modified sources also belong to non-free and thus > odr-audioenc becomes non-free as well. I note that there is a request to move fdk-aac to main: https://bugs.debian.org/981285 PS: please try to get your fdk-aac changes upstream if you didn't yet. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#1008882: RFS: odr-audioenc/3.2.0-1 [ITP] -- DAB and DAB+ encoder that integrates into the ODR-mmbTools
On Wed, 2022-10-19 at 10:26 +0200, Robin Alexander wrote: > My package odr-audioenc was rejected after it reached the NEW queue > because one of the library it depends on does not belong to "main" but > to "non-free". I therefore need to change the section in file > debian/control from "hamradio" to "non-free/hamradio" and submit the > package again. If the package itself is otherwise free, you want contrib not non-free. The library will go to non-free of course though. > - Do I need to change the package release from 1 to 2 because of this > debian/control file change or can I keep the same package release, given > that the package never made it to unstable I'm not sure, but I think it would be best to change it, as documentation of the changes done based on ftp-master feedback. > - Can I take the opportunity of this change to include the latest > upstream version? Yes. > can I delete the repository on salsa and re-create it again before > pushing the package? Yes, the git repo isn't very relevant here. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: autopkgtest : s390x is considered regression but never built
On Thu, 2022-10-06 at 09:18 +0200, Tobias Frost wrote: > Oh, sorry; I missed that you meant d/test/control… > (Though, Reading [1], I'm not sure if there is support for "!", but I > guess it is worth a try…) elbrus confirmed on #debci that ! is supported in d/t/c Architecture. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: autopkgtest : s390x is considered regression but never built
On Thu, 2022-10-06 at 07:15 +0800, Paul Wise wrote: > On Tue, 2022-10-04 at 08:50 +0200, Mathieu Malaterre wrote: > > > Is there a way to de-activate explicitly s390x from the default > > autpkgtest list ? > > I asked about this #debci on IRC and got this answer: More discussion on #debci, elbrus and I came to the conclusion that removing @ from Depends in debian/tests/control is the right thing to do here, because the tests only use cjxl/jxlinfo/djxl from libjxl-tools and that if libjxl-tools were in Depends instead of @ (which includes arch:all) then britney should understand the situation and DTRT, but if not then contact the release team for help with the issue. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: autopkgtest : s390x is considered regression but never built
On Tue, 2022-10-04 at 08:50 +0200, Mathieu Malaterre wrote: > Is there a way to de-activate explicitly s390x from the default > autpkgtest list ? I asked about this #debci on IRC and got this answer: pabs: haven't checked but the answer normally is that the package also builds arch:all binaries and either the correct solution is to skip s390x (as in the follow up) or if there's a chance it will ever build on s390x to ask the release team to hint the package through -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: vim-command-t upload errors
On Wed, 2022-09-21 at 10:44 +0100, Sam Morris wrote: > It looks like the connection's being closed during the transfer; If you are able to try the upload from a different Internet connection, or with a VPN or via Tor that might help narrow down the issue. > dput-ng's error handling could certainly do with some improvement ... Please do report a bug about that, hopefully it can get fixed. > As for why dput-ng and lftp both have trouble uploading to the > server, but dput does not, I've no idea... You might be able to figure this out by using Wireshark to obtain network traces of successful and unsuccessful uploads and comparing them to see where the process goes wrong. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Self dependent package, build profiles & buildd servers
On Fri, 2022-09-16 at 19:53 +0200, Fab Stz wrote: > How does is this actually managed on the official buildd servers? How > does it actually know which DEB_BUILD_PROFILES to apply on each run? The Debian buildds currently do not have support for build profiles, for now build profiles are only for bootstrappers/porters/maintainers. It sounds like you are going to have to fix the upstream build system to use the first build products during the second build product build. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: how to manage packages that require native acceleration code
On Mon, 2022-09-12 at 10:05 -0400, Aaron Boxer wrote: > My codec project uses SIMD code for x86 and AArch64 architectures. > Also, as there are different versions of SIMD i.e. SSE vs AVX vs > AVX2, the project uses a library that builds multiple versions of the > accelerated code and chooses which version to use at runtime. Runtime selection of instructions is the best solution indeed. Other solutions include automatic porting between SIMD instructions, emulating atomic instructions, manual runtime code path selection, manual runtime function selection, compiler function multi-versioning, glibc hwcaps library selection, runtime binary selection, blocking installation and blocking running binaries. All are summarised here: https://wiki.debian.org/InstructionSelection -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Few questions about shaderc packaging
On Sun, 2022-09-11 at 21:40 +0200, Philippe SWARTVAGHER wrote: > Upstream has several files describing copyrights of the project [1-4]. > In d/copyright, I licensed the whole project with Apache 2.0, with > "Google Inc." as copyright holder. Should I detail more? Generally, the ftp-masters require the copyright and license info of every file in the source package to be documented in debian/copyright. https://ftp-master.debian.org/REJECT-FAQ.html The machine-readable copyright format design helps make that easy. https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ There are various tools available to partially automate that process. Allegedly ScanCode is the best one, but it isn't available in Debian. The output of the tools should be checked manually for correctness too. https://wiki.debian.org/CopyrightReviewTool > The crossbuilding for arm64 fails on Salsa-CI, because of unavailable > dependencies: Cross-building is optional so you don't have to fix that right now, all arch-specific Debian packages are created using native builds. It is estimated that only about 50% of Debian is cross-buildable, that number is slowly going up over time as people work on issues. > The following packages have unmet dependencies: > builddeps:.:arm64 : Depends: asciidoctor:arm64 > Depends: ruby-pygments.rb:arm64 but it is not installable I note that both asciidoctor and ruby-pygments.rb have issues reported by the multi-arch hinter. Fixing those might allow this to work. https://tracker.debian.org/pkg/asciidoctor https://tracker.debian.org/pkg/ruby-pygments.rb > Since asciidoctor is only used at build time to generate the manpage, is > it possible to specify in d/control that asciidoctor doesn't have to be > available on arm? Indeed, the version for the host architecture will be > enough to build the package and won't be required to install the package. Please note that asciidoctor is installable on arm64 (I checked), the issue you face is only a problem in the cross-build scenario. You can mark asciidoctor with the nodoc build profile, so that people who don't want to build documentation can apply the profile and disable building the manual page and not need the asciidoctor build dependency. https://wiki.debian.org/BuildProfileSpec > The name of the shared library generated by upstream source code is > libshaderc_shared.so.1, but the suffix "shared" seems to be used just to > emphasize the shared aspect of the library. The following files are also > installed: ... > I named the library package libshader1. Is it a correct situation? Or > should I rather rename the shared library to libshaderc.so? or the > package to libshaderc-shared1? I suggest talking to upstream about this. It does seem like the "shared" suffix should not be part of the SONAME. > As stated in [5], I didn't include a symbols file in the package, since > the library is in C++ (I generated it, and even unmangled, it will be > hard to maintain). Is it correct for this package? That is reasonable, if you change your mind, the KDE team documentation on this issue might be useful for maintaining the C++ symbols files: https://qt-kde-team.pages.debian.net/symbolfiles.html Please note that not using symbols files means you will need to maintain the shlibs and be sure to bump them when symbols change, or just make reverse-deps use more strict dependencies. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Guidance for returning contributors
On Tue, 2022-08-30 at 03:56 -0400, Matt Arnold wrote: > Guidance for returning contributors We unfortunately don't have a general guide on this topic, but it might be worth writing one if you are keeping notes on the process. > My question is how would i now contribute this back? Every team is different, but indeed GitHub/GitLab style workflows have taken over many teams. Once you have a salsa account, you can either use the web based workflows, or use the `salsa` command from devscripts to do the same thing from the command-line. You will need to register a auth token for the `salsa` command first though. There are also other tools/libraries for accessing GitLab APIs in Debian, but the primary one is not yet available in Debian. https://about.gitlab.com/partners/technology-partners/#cli-clients PS: the one for GitHub is available in Debian as `gh` and it is great. > The situation is I recently had to prepare a new upstream version of > a package in Debian for a client minetest to 5.6.0. ... > For example would it be considered rude to just send a cleaned up > version to games team mailing list with git-send-email. Or party like > it's 2009 and file a bug report with a debdiff. There has been some discussion of minetest 5.6.0 on the IRC channel recently, and also another returning DD interested in it on the list. Also a non-DD got minetest updated via a non-games-team RFS in April. https://lists.debian.org/msgid-search/cajxtcxxymplmom+lhhtosnbnpp6ir87g2ppdacaf2hoxqut...@mail.gmail.com https://bugs.debian.org/1006832 https://lists.debian.org/msgid-search/Yhglc0bFzC1B6LPB@strider So I think I would start by sending a mail to the games list and clicking the join button on the team salsa page. > Also I might be getting ahead of myself here, but what are the best > practices regarding PGP/GPG. I currently have a DD-signed 2048 bit RSA > key. Do I need to upgrade if i get back into this seriously. The only > DDs i know are in Ireland, DC, NZ, and NYC and getting any of those > places in person is cost prohibitive atm. I think this key strength is still accepted, although a larger key or an ECC key might be better in the long run, and OpenPGPv5 is coming: https://debconf22.debconf.org/talks/71-sequoia-pgp-v5-openpgp-authentication-and-debian/ There are Debian folks offering key signing in many other places: https://wiki.debian.org/Keysigning/Offers Attending the annual Debian conference (or other events) is also a good way to get signatures. The next DebConf is in India in September 2023 and there is usually travel/etc funding available to contributors. In addition, key endorsements are now an alternative to key signing: https://lists.debian.org/msgid-search/20201108205109.6nzboemjkr5ik...@enricozini.org -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: parse SPDX-License-Identifier to produce copyright file
On Mon, 2022-08-22 at 21:00 +0200, Fab Stz wrote: > Does there exist a tool for Debian that will parse a package directory (its > source files), extract the "SPDX-License-Identifier:" and produce something > that would fit into a machine-readable debian/copyright file? For the more general question of generating debian/copyright, there is this wiki page listing different options. The best one is allegedly scancode but that isn't available in Debian yet. https://wiki.debian.org/CopyrightReviewTools -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: symbols-File for Library
On Sat, 2022-08-13 at 11:31 +0200, Marc Haber wrote: > I think this is worth doing only if the number of your reverse depends > is well in the two-digit range or above that. That doesn't apply (yet) > to gensio, so I'm likely to remove the symbols file from my package > again and override the lintian warning. Looks like you only have one reverse dep (ser2net) so that sounds fine. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: symbols-File for Library
On Sat, 2022-08-13 at 22:19 +0200, Marc Haber wrote:
> dpkg-gensymbols does not seem to be willing to grok the second line
> ("gensio_log_levels, not a valid version").
>
> Also, the arch extension does not seem to be in deb-symbols(5).
See the deb-src-symbols(5) manual page, I think you want this:
(arch=!arm64|c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*,
gensios::gensio_log_levels, char const*, __va_list_tag*)@Base" 2.5.1
(arch=arm64|c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*,
gensios::gensio_log_levels, char const*, __va_list_tag*)@Base" 2.5.1
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#1017071: RFS: psi-notify/1.3.1-1 -- Alert when your machine is becoming oversaturated
On Fri, 2022-08-12 at 23:35 -0500, Michel Alexandre Salim wrote: > -O2 is baked into the Makefile. The last option should win so -O0 takes > precedence, I suppose? I can probably convince upstream to implement a > simple ./configure. Sounds right, so probably not an issue, just seemed a bit weird. > Likely, assuming things continue to work. I'll look into that. I don't know what happens when someone uses BSD make instead, that is unlikely on Linux distros but you never know :) > Right. The Debian patch is actually to disable sanitization -- upstream > enabled it for testing only in 1.3.1 which broke CI builds. Current > hypothesis is because eatmydata changes some LD_PRELOAD settings. The patch headers made it sound like you might enable it globally. eatmydata definitely sounds like it would cause this issue. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: symbols-File for Library
On Fri, 2022-08-12 at 12:06 +0200, Marc Haber wrote: > what's the benefit in having a symbols file? It means that packages depending on a library can relax their version dependencies on that library to the oldest version that supports all the symbols they use. Until the symbols mechanism was invented, whenever a library added a symbol, it bumped its shlibs and after that packages built against the library would require the new version. That made it harder to do (partial) upgrades, testing migration etc. https://wiki.debian.org/Projects/ImprovedDpkgShlibdeps -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: symbols-File for Library
On Fri, 2022-08-12 at 07:00 +0200, Tobias Frost wrote:
> ${shlibs:Depends}
I mean for the library, what do you set debian/$package.shlibs to?
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Re: symbols-File for Library
On Thu, 2022-08-11 at 16:10 +0200, Tobias Frost wrote: > I tried them on a few occasions only to drop them a few uploads later, as > they add a lot of maintainance burden. They will frequently break, as some > other package or toolchain might have influences, are > architecture dependent and once you think you've got it you'll get the > next breakage… I'd just override the warning and be done. What do you do for the library shlibs in that case? Use == $version? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1016624: RFS: psi-notify/1.3.0-1 -- Alert when your machine is becoming oversaturated
On Thu, 2022-08-04 at 14:53 -0500, Michel Alexandre Salim wrote: > Saw that from the notes you gave to the initial upload too. I checked > libsystemd.pc and... there's nothing we can use there, unfortunately. How about this? pkg-config --variable systemd_user_unit_dir systemd -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: autopkgtest testing postinst
On Thu, 2022-07-21 at 10:30 +0200, Marc Haber wrote: > Is there also a documented way to install the packages from stable, > testing, unstable to automatically test updates? That sounds like what piuparts is for: https://packages.debian.org/unstable/piuparts https://piuparts.debian.org/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: keys
On Fri, 2022-07-15 at 00:32 +0200, Alec Leamas wrote: > Any clues out there? The Debian mentors site only verifies against the OpenPGP keys that have been registered on the mentors site for each individual user. So login to your mentors account, update the key there and reupload. If you still get an error, let us know the package so we can check. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: pbuilder not updating
On Thu, 2022-07-14 at 17:49 -0400, Matt Barry wrote: > I imagine I'm missing something simple wrt pbuilder.. any ideas where > to look? Are you getting any errors from the pbuilder update command? Are you updating the same chroot as you are building with? You can also add a hook that does apt update before the build: ==> ~/.pbuilder/hooks/D01update <== #!/bin/bash exec apt-get update Sometimes it is useful to have a shell during the build, which you can use to do things you forgot to do in the packaging or elsewhere. ==> ~/.pbuilder/hooks/A00shell -> shell <== ==> ~/.pbuilder/hooks/B00shell -> shell <== ==> ~/.pbuilder/hooks/C00shell -> shell <== ==> ~/.pbuilder/hooks/D00shell -> shell <== ==> ~/.pbuilder/hooks/E00shell -> shell <== ==> ~/.pbuilder/hooks/G00shell -> shell <== ==> ~/.pbuilder/hooks/H00shell -> shell <== ==> ~/.pbuilder/hooks/I00shell -> shell <== ==> ~/.pbuilder/hooks/shell <== #!/bin/bash exec /bin/bash -i /dev/tty 2> /dev/tty There are various pbuilder hook examples here: /usr/share/doc/pbuilder/examples More pbuilder tips and tricks here: https://wiki.debian.org/PbuilderTricks -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: autopkgtest testing postinst
On Thu, 2022-07-14 at 09:52 +0200, Marc Haber wrote: > How would I do that in autopkgtest? Can I uninstall and reinstall the > package in question while an autopkgtest is running? Sounds like you want the breaks-testbed and needs-root restrictions: https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: tests failing without specific locales
On Thu, 2022-06-09 at 08:38 +0200, Marc Haber wrote: > I havent looked at the test in detail, I have not yet decided whether > the package would be helpful in Debian. It looks like the test has > en_GB.UTF-8 hardcoded, sets the locale to that value and then fails > it it's not there. Most likely it's the home locale of the dev. It sounds like you could simply patch it to use C.UTF-8 instead? Or send upstream a patch to take the locale from the environment variables. Of course then tests might fail if someone uses a weird locale and the test results depend on the locale, but then you could set the locale to C.UTF-8 in debian/rules. Or perhaps debhelper should be doing that in the next compat level. > And build-depending on that is not bad in some way? I can't think of a reason it would be problematic. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: tests failing without specific locales
On Thu, 2022-06-09 at 07:28 +0200, Marc Haber wrote: > I am working on a package written in python that thankfully has a > test suite. Unfortunately, one of the tests fails if the en_GB.UTF-8 > locale is not present. Any idea why the test requires that locale? Tried C.UTF-8? > How do I solve this? Do I need to build-depend on the locales-all > package or is there a less ugly way? I think that using locales-all is currently the only way to ensure that a specific locale other than C/C.UTF-8 is installed. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1012196: ITP: exaile/4.1.2-beta1-1 -- Exaile is a music player with a simple interface
On Wed, 2022-06-01 at 01:41 +0200, Bastian Germann wrote: > On reintroducing a package you need to file an ITP on wnpp as well. Please note there are some extra steps in addition to filing the ITP: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: How to install kdump in debian11?
On Tue, 2022-05-31 at 18:17 +0800, starcold14 wrote: > How to install kdump in debian11? I answered this question on debian-devel too. In future, please don't send the same question to multiple lists and please send questions about using Debian to our support channels instead of other lists. https://www.debian.org/support -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Looking for a new maintainer for 'colordiff'
On Tue, 2022-05-17 at 20:40 +0100, Dave Ewart wrote: > Should I create RFS? I'm unclear whether this is more suited to a > one-off upload or for ongoing maintainership. Advice welcome! It depends on the sponsor, some prefer you to file a public RFS for each upload, others prefer you to contact them in private. I suggest you file an RFS and see what your new sponsor says. > I've been developing 'colordiff' for more than 20 years, but in the > Debian ecosystem I've never uploaded the packages myself. Rather I've > been building the packages and various individuals have sponsored the > uploads. However my most recent sponsor Colin Tuckley (since 2007) is no > longer able to do so. This sounds like a situation where you could upgrade your privileges in Debian to Debian Maintainer with upload permission for colordiff, please pursue that once you have a new sponsor. https://wiki.debian.org/DebianMaintainer -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1010792: RFS: psi-notify/1.2.1-2 [ITP] -- Alert when your machine is becoming oversaturated
On Mon, 2022-05-09 at 20:18 -0700, Michel Alexandre Salim wrote: > I am looking for a sponsor for my package "psi-notify": I prefer that three issues are fixed before uploading psi-notify: Since the package requires Linux kernel PSI APIs, it probably won't work on kFreeBSD or Hurd, if so, change Architecture to linux-any. Please s/MIT/Expat in debian/copyright, see here for details of why: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name Presumably the debian/ directory is not copyright by upstream, so please add a second stanza like this: Files: * Copyright: 2020-present Christopher Down License: Expat Files: debian/* Copyright: 2022 Michel Alexandre Salim License: Expat License: Expat ... These issues would be nice to fix at some point: The Depends on libnotify-bin doesn't appear to be needed, since no part of the package uses notify-send as far as I can tell, since it seems that psi-notify uses libnotify instead. You don't need the Closes in the second changelog entry, since when building the package for upload to NEW, dpkg-buildpackage -v0 should be used when there are multiple changelog entries, so that all of the changelog entries are present in the .changes file and all of the bugs closed by all of the entries are added to Closes in the .changes file. Alternatively you can collapse all the entries into one, your choice. Enable the additional hardening options, unless they break something. Drop or uncomment all the commented out things from debian/rules. Drop override_dh_install since you have debian/install. I prefer to wrap the files in the debian/ dir using this: wrap-and-sort --short-indent --wrap-always --sort-binary-packages --trailing-comma Please add some upstream metadata: https://wiki.debian.org/UpstreamMetadata Please think about how to add autopkgtests at some point. https://ci.debian.net/doc/ The upstream README.md references galago-project.org, which is dead. The notification spec has moved here, please send a patch upstream: https://specifications.freedesktop.org/notification-spec/latest/ You might like to send upstream a patch adding install to the Makefile which would make debian/install obsolete. You can find inspiration for this in the Makefile of mpv-mpris. It allows installing as a user or as root, allows overriding the user/root detection, uses the right prefix, supports DESTDIR etc. Note that for installing the systemd unit file, you should look up the right paths using pkg-config. Once the package has been accepted into Debian, please send upstream a patch linking to the Debian package. Alternatively, just replace that section of the README.md with a link and or badge for Repology: https://repology.org/project/psi-notify/versions I'm not sure how demo.gif was created, but I'm assuming it was manually recorded, which means it can get out of sync with the code, it would be nice if upstream would create it dynamically at build time. These complaints from the lintian tool could be fixed: $ lintian --info --display-info --display-experimental --pedantic --show-overrides --color auto I: psi-notify source: debian-watch-contains-dh_make-template [debian/watch] I: psi-notify: hardening-no-bindnow [usr/bin/psi-notify] I: psi-notify: hardening-no-fortify-functions [usr/bin/psi-notify] X: psi-notify source: upstream-metadata-file-is-missing When I run check-all-the-things, these tools report things that potentially could be fixed: cme check dpkg, cppcheck, flawfinder, grep http:, iwyu, PATH_MAX, proselint, wrap-and-sort, yamllint. Some of them are about Debian things, some are upstream things. https://github.com/collab-qa/check-all-the-things -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Debian watch file and GitLab for Autotools projects?
On Wed, 2022-04-06 at 16:26 +, Eivind Naess wrote: > The project is using ./autogen.sh to generate the configure scripts, > et al for the project. When I got to tag and create a release, I have > to upload the resulting tarball with the resulting configure scripts > embedded. Personally I would suggest not using the tarballs containing autotools files for the Debian orig.tar and instead using tarballs that are identical to the upstream git repository. This ensures that on Debian you are always building the ./configure and other autotools files from source at `debian/rules build` time. Also review the upstream git repository to ensure it doesn't contain embedded copies of files maintained elsewhere (those should be packaged in Debian and added to build-deps instead), or other generated files (those should be removed and instead created at build time. The only potential exception to this are the copies of the licenses. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: A question about "non official" debian packages
On Thu, 2022-03-03 at 16:30 +0100, Albert van der Horst wrote: > Is it frowned upon by the Debian community to use the .deb format to > publish these packages? While it is fine to publish .deb packages outside of Debian, it is usually better for everyone and recommended by Debian to get them included in Debian itself. Take a look at this if you are interested: https://mentors.debian.net/intro-maintainers/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: How to resolve unsatisfied dependency (verisoned) after ftpmaster acception
On Fri, 2022-01-21 at 10:06 +0100, Markus Blatt wrote: > I assume that this version dependency was added when the packages > were built some time ago. Correct, see the dh_shlibdeps, dpkg-shlibdeps, deb-shlibs, deb-symbols and dpkg-gensymbols manual pages for details. > What is the recommend way to resolve this? In addition to the unsatisfiable dependency, the binaries in unstable haven't been built on a buildd, so they won't be accepted into testing. https://qa.debian.org/excuses.php?package=opm-common Rebuilding the package (either via a package update or a binNMU) will rebuild the binary, which will pick up the new libfmt dependency. If you elect for a binNMU that will solve the buildd binaries issue. If you elect for a package update, you just need to ensure your sponsor does a source-only upload so builds will happen on built on buildds. https://wiki.debian.org/binNMU https://wiki.debian.org/SourceOnlyUpload -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters
On Thu, 2022-01-13 at 20:54 +, John Scott wrote: > You might like to have a look at this mail from Ben Hutchings: > https://lists.debian.org/msgid-search/179d6d32466dd13962a3aab251c45242fbf2d8ae.ca...@decadent.org.uk > The reason that none of the other Wi-Fi firmware packages have them is > because they're all non-free (with the exception of ath9k_htc). Thanks for the link, I'm not subscribed to that list. Makes sense. > I wasn't sure if there was any established convention; my thread "Naming > convention for udebs: -udeb/-installer suffix" didn't garner any > pertinent responses. I've switched the name though. I did a search of a Debian mirror filesystem and found that only the linux and linux-signed-* source packages use the -di suffix, most use the -udeb suffix. The -installer suffix seems to be used only for udeb packages when the source package has the -installer suffix too, such as bootloader installers like grub-installer, with a few exceptions for other udebs that install things. I suggest using the -udeb suffix. > These are all good catches, I'm working on incorporating them and doing > a slow and careful review. Recently on another project I noticed an upstream commit that added copyright information in the middle of a file alongside the functions that were copied from elsewhere. This sort of thing is hard to notice during the manual review of file headers I usually do using mc (after enabling the preview pane and arrow keys for navigation), but some of the copyright review tools might be helpful. I actually detected the list.h LGPL license using debmake -k (as run by check-all-the-things). Apparently the best option is ScanCode but that isn't in Debian yet. https://wiki.debian.org/CopyrightReviewTools > I think you're mistaken here, you should take a look at > /usr/share/dpkg/buildopts.mk which I include via an include directive in > debian/rules. Basically, DEB_BUILD_OPTION_PARALLEL is a helper macro for > the value of parallel from DEB_BUILD_OPTIONS; these are one and the > same. I see, I wasn't aware of this snippet/variable. > That's true. My intent was that, since it's a hidden directory, it would > help remind one that that directory gets created. It seems to've only > caused confusion, so I'll pull it. That seems reasonable if you want to keep it. Maybe add a comment. > Indeed, the documentation is rather old and terse and doesn't address > this issue. I'll probably ask the Reportbug folks and send them a MR > updating the docs. Great. > > Please ask upstream to make a new release, it has been a very long time > > since the last one. > I will do after making some of the following important changes. Thanks. > > Please ask upstream to send FindUSB-1.0.cmake & libusb-zeropacket.diff > > to libusb upstream and then remove them from carl9170fw. > I will ask, but with all due respect, I think this is lower priority and > that I'll have limited ability to help them. Sure. TBH they don't appear to be used by carl9170fw so I'm not sure why they are in the source repository at all. > I do not have a grasp, let alone a good one, of CMake, so this may be a > challenge. The documentation for CMake is fairly comprehensive, until recently I had never touched CMake and didn't understand it but when I needed to figure it out I found it to be reasonable and well documented. > I actually think I'll do one better: I submitted upstream an AppStream > metadata file a while ago, and although they haven't responded to it > yet, perhaps my sending them other changes will get their attention. > AppStream metadata and Debian upstream metadata files have considerable > overlap, and in my personal opinion having good AppStream metadata makes > an upstream metadata file unnecessary, but I'm willing to entertain > arguments to the contrary. I haven't looked at AppStream but I got the feeling they had different audiences or purposes or tools looking at them. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters
On Sat, 2021-12-25 at 18:25 +, John Scott wrote: > https://mentors.debian.net/debian/pool/main/c/carl9170fw/carl9170fw_1.9.9-399-gcd480b9-1.dsc Some things that prevent the upload of this package: I don't think udebs are needed for firmware packages, none of the other WiFi firmware packages in Debian have them. If the package is actually needed it should be named -udeb not -di, since other udebs use -udeb. Several files have missing/incorrect information in debian/copyright, please do a full audit of the code looking for copyright/license info. * tools/include/list.h is LGPL * tools/include/frame.h is partly from Linux, unknown copyright * include/shared/eeprom.h also contains ISC code DEB_BUILD_OPTION_PARALLEL doesn't appear to be a standard variable, please switch to DEB_BUILD_OPTIONS=parallel=N instead, see Debian Policy, section 4.9.1 and debhelper(7) and dpkg-buildpackage(1). Some things that would be nice to fix at some stage: Nothing in debian/rules references .config so you can drop that from before the execute_before_dh_auto_configure target. It seems like the Homepage should be the carl9170.fw firmware wiki page instead of the carl9170 driver wiki page. https://wireless.wiki.kernel.org/en/users/drivers/carl9170.fw I would express the license of include/shared/fwcmd.h etc as GPL-2-only && ISC rather than putting a copy of the ISC license in a comment. bug-presubj isn't well wrapped. I'm not sure if wrapped or unwrapped is the best option for this file though. Please ask upstream to make a new release, it has been a very long time since the last one. Please ask upstream to update their copies of code from the Linux kernel and other external sources to the latest versions. Please ask upstream to send FindUSB-1.0.cmake & libusb-zeropacket.diff to libusb upstream and then remove them from carl9170fw. Please ask upstream to delete FindPackageHandleStandardArgs.cmake, since that is now available from cmake upstream and from Debian cmake. Potentially cmake_minimum_required will need to be bumped for this. Please ask upstream to include the copyright information for carlfw/src/memcpy.S and carlfw/src/memset.S in the files. Please ask upstream to update the COPYRIGHT file. Please send upstream some changes that would allow building the upstream source using a pre-packaged toolchain like the Debian one. Please also figure out how to eliminate the other debian/rules workarounds. It would be nice if the Linux kernel community or the Debian src:linux package could split kconfig off into a reusable component. Please add an upstream metadata file: https://wiki.debian.org/UpstreamMetadata I suggest these arguments to wrap-and-sort: wrap-and-sort --short-indent --wrap-always --sort-binary-packages --trailing-comma --dry-run These tests from check-all-the-things suggest some polishing for upstream and or yourself: anorack codespell cppcheck cpuinfo debmake-k duck http path-max proselint shellcheck spellintian todo https://github.com/collab-qa/check-all-the-things -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Suggestion needed on test failures due to double arithmetics
Giulio Paci wrote: > 3) what is the most appropriate solution. As I understand it, floating point values should not be compared without some kind of accuracy/precision factor. Zero idea about the best reference for how to do it correctly, but here is a random one: https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: A package to be removed
On Mon, 2021-11-22 at 08:47 +0200, Tommi Höynälänmaa wrote: > Package theme-d-gnome was scheduled for autoremoval on 2021-11-21 but > it looks like the package has not been removed yet. It looks like the autoremoval was processed: $ apt-cache madison theme-d-gnome theme-d-gnome |0.9.6-3 | https://deb.debian.org/debian unstable/main amd64 Packages theme-d-gnome |0.9.6-3 | https://deb.debian.org/debian unstable/main Sources $ rmadison theme-d-gnome theme-d-gnome | 0.7.5-2 | oldstable | source, all theme-d-gnome | 0.9.5-4 | stable | source, all theme-d-gnome | 0.9.6-3 | unstable | source, all $ w3m -dump https://tracker.debian.org/pkg/theme-d-gnome | grep -A6 versions | tail -n3 • oldstable: 0.7.5-2 • stable: 0.9.5-4 • unstable: 0.9.6-3 > I searched the package at packages.debian.org and the package was > displayed there in testing and unstable distributions. The packages site usually takes longer to update than other sources. > Grep-excuses displays theme-d-gnome as "flagged for removal". It is still in the list of auto-removals hints but not in the autoremoval calculations, so next time the hints are regenerated and then the testing migration runs I expect the excuses will change. https://release.debian.org/britney/hints/auto-removals https://udd.debian.org/cgi-bin/autoremovals.yaml.cgi -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Source with different examples directories
On Sun, 2021-11-21 at 21:22 +0100, Marc Haber wrote: > Is there a less ugly way? Send upstream a patch to create a directory structure like this: src/ examples/ c/ c++/ If you're only after workarounds, there are two options: Run dh_installexamples twice. First install the C++ examples, then mkdir c++, then mv * c++, then install the C examples. Read the dh_installexamples code and adapt the `cd && find | sort | xargs cp` command that dh_installexamples is just a wrapper for. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#994912: RFS: tokenize-rt
On Sat, 2021-10-30 at 20:47 +, Joshua Peisach wrote: > I contacted upstream about tokenize-rt. It seemed perfect to put into > upstream Python because it's small, and its tiny popularity but is > used by many of his other apps which rely tokenize-rt. I approached > him in a GitHub issue and he said if that was the attitude I was > going to have, 'don't package my stuff'. > (https://github.com/asottile/tokenize-rt/issues/77) I think I caused this problem by misunderstanding that tokenize-rt is a wrapper for Python stdlib tokenize, rather than a fork of it and then suggesting that the tokenize-rt fork of tokenize should be merged with the Python stdlib tokenize, leading to the above bug. I'm sorry I caused this issue and for not investigating more closely. I will apologise to tokenize-rt for this too. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: How to include the .git folder in a source package's .tar.xz archive?
On Fri, 2021-10-29 at 15:28 +0200, Alec Leamas wrote: > Other solutions could be creating a file like VERSION with relevant git > data and add that to the distribution. That file can normally not be > checked into git, it's a chicken and egg problem. The solution is to add > the logic to autoconf/cmake/whatever is used. I maintain a package called autorevision, which is aimed at adding git information to exported tarballs. It supports various languages and build systems. Please use that instead of any sort of custom solution. https://autorevision.github.io/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator
On Sun, 2021-10-24 at 14:24 +0200, wf...@niif.hu wrote: > libraries (like libswtpm_libtpms.a) This library sounds like an embedded code copy, if it is one, please follow the advice on this wiki page. libtpms is already in Debian. https://wiki.debian.org/EmbeddedCopies -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Uscan with gitlab and user provided tarball
On Tue, 2021-10-19 at 09:03 +0200, Ole Streicher wrote: > At least some of them are not really suitable to be packaged as > separate public packages. The two submodules in question (AOcommon, > schaapcommon) are personal utility functions of the upstream authors > which are not intended for general use. I maintain a few packages that are in a similar situation, I've actually been leaning towards packaging the code copy separately but haven't gotten around to it yet. The code copy isn't changing very often though, it is fairly mature. > how to effecitvely (with the help of upstream) detect and download > the complete source. I would use the component feature of dpkg-source v3 source packages to add additional orig tarballs, one for each of the submodules. Unfortunately the component feature doesn't support subdirectories but you can workaround that by creating symlinks in debian/rules. uscan supports the component feature, but as far as I can tell the git mode of uscan doesn't support git submodules. I suggest you file a bug or patch asking for support for that if there isn't one already. If you don't want to use uscan, you can just create a get-orig-source target in debian/rules with git clone and git archive and run that to download releases. If you want to use uscan, you will have to rely on the http mode for downloads for now. Since you don't have proper links, the html searchmode will not work for you. So you will have to either use the plain searchmode or use a pagemangle to transform the HTML to something useful. Unfortunately GitLab does everything from JavaScript so neither of those will work. I suggest you load the releases page with your browser dev tools open, work out which API is used to download the releases information and then have uscan download that and use the plain searchmode and various mangle rules to find the files. Once you have figured it out, please document it on the wiki to help others. https://wiki.debian.org/debian/watch#Gitlab -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Uscan with gitlab and user provided tarball
On Tue, 2021-10-12 at 14:43 +0200, Ole Streicher wrote: > https://gitlab.com/aroffringa/wsclean > > He uses git submodules These all look like embedded code copies, so I suggest packaging them separately instead of including them the wsclean source tarball. https://wiki.debian.org/EmbeddedCopy -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: WNPP Update Package source of gjiten
On Wed, 2021-10-06 at 13:50 +0900, notebook wrote: > When I asked for the package source back then, I was referred only to > the debian tarball. I.e. I was not aware of anything else existing. The package source and the upstream source are two different things. When creating a fork of an existing upstream project you should use the source of the existing upstream project. > As my changes are huge and the project has previously been basically > dead, I think it's not worth the effort vs the risk and work effort. There should be almost zero risk since the tarballs are likely identical to the source in CVS. The effort is likely not much, just converting the repo and then exporting and applying all the patches you created. It is also inappropriate to erase the contributions and names of the previous upstream contributors from the git history. > I guess you're talking about Ludovic Drolez . I > contacted him 8 months ago without any answer. I infered the mail is > dead or he's too busy with other stuff. But perhaps from member to > member there's a higher success rate :) Hmm, OK. Maybe try him again. > I thought, if all links in the package point to github in the future, > the source forge project becomes obsolete. For Debian purposes yes, but Debian is not the entire Free Software world. Individual users and other redistributors will probably continue to encounter the SourceForge project until someone makes it redirect to your fork of the project. Personally when a project is undermaintained I contribute to and or take over the project instead of forking because it maintains the continuity of the one project in one place instead of proliferating copies of it many different places. https://repology.org/project/gjiten/packages -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: WNPP Update Package source of gjiten
On Tue, Oct 5, 2021 at 7:06 AM notebook wrote: > I'm working on the "Gjiten" package ([1]). It was kind of abandoned and used > Gtk2. > I upgraded it to Gtk3 and did some further development on it (see [2]). > > I'd like to get the new codebase into the debian repos. If I understand > correctly, I need a sponsor for that(?) Is there anyone willing to sponsor > the package? Is there is a particular reason you used the Debian tarballs instead of the old upstream CVS repository when creating the new upstream git repository? I'd suggest creating a new git upstream repository based on the old upstream CVS repository and then rebasing your new changes on top of that. Otherwise you are hiding the history of the project. I note that the person in the Debian package Uploaders field is a Debian member and was last active in Debian in March 2021, so I suggest asking them about the situation, they are likely to respond. Also ask them if they still have access to the SourceForge project and could setup a redirect to your fork of the upstream project. -- bye, pabs https://wiki.debian.org/PaulWise
Re: static linking, libc and handling this in the aide package
On Sat, Sep 11, 2021 at 2:26 PM Marc Haber wrote: > What would debian-mentors' recommendation be? Your hints will be > appreciated. To prevent installation of an static aide with a incompatible nss libraries, you could get glibc to add Provides: libc-nss-abi (= N) or Provides: libc-nss-abi-N and a mechanism to get the current ABI number at build time then have aide depend on that. Then when glibc transitions happen, aide could get binNMUed automatically. I wondering which nss calls aide is doing and if they can be eliminated entirely. I think I would lean towards the dynamic solution; I assume that if someone can modify the nss libraries then they can also modify the static aide binaries. It might be worth discussing the issue with aide upstream, they probably have guidance about this by now. PS: I wonder if you are tracking when static aide requires a binNMU after security updates to libraries it uses? -- bye, pabs https://wiki.debian.org/PaulWise
Re: include additional git repo in package
On Wed, Aug 11, 2021 at 1:54 PM Peymaneh Nejad wrote: > I am working on packaging the Caddy web server. Caddys github repo[1] only > includes the platform-agnostic files (mostly .go source files) needed for > building and testing. > distro-specific files such as systemd unit files, bashcompletion, > pre/post(un)install scripts etc have been moved to a seperate "dist" repo[2]. > > I am wondering what would be a good way to include these in the package. Three options that I can think of: Convince upstream to include the dist files in the main repo again. Use dpkg-source v3 multiple upstream (MUT) tarballs, which uscan supports, search for component/MUT in the manual page. Create two source packages to mirror what upstream has done. -- bye, pabs https://wiki.debian.org/PaulWise
Re: overriding package with older version in new queue
On Tue, Aug 10, 2021 at 11:24 AM Peymaneh Nejad wrote: > I realised later that this package actually break the build, and that this > can be solved by packaging _older_ version of the dependency package (that's > also what upstream does. The best option is to send upstream a patch to fix the build when using the newer version of the dependency, then package the version that includes the patch. Eventually upgrading the dependency package will be needed so the build failure will need to be fixed sooner or later and fixing it sooner rather than later is better. If you take this approach it is a good idea to make the build work with both the old version and the new version, so that people stuck on the old version for whatever reason don't have to upgrade. > Should I or my sponsor contact ftp masters and cancel the upload, and do a > new on, or is it possible to overwrite the uploaded package even tho the > version number would be lower? I imagine uploading an older version might be > difficult, latest when in reaches unstable. If fixing the build failure isn't feasible right now, you could contact the ftp-masters and ask for a reject, then upload the older version. There is no other way to get an older version into Debian. Once the package is accepted there isn't any proper way to make the version become older. There are two hacky/bad ways though 1) discuss the case on debian-devel and if you get consensus you can add an epoch 2) you can upload 0.1.1 as 0.1.2+really0.1.1 instead to make the version later than 0.1.2 but contain the code from 0.1.1. Both of these are not good ideas though. > If I should contact ftp masters, should this be done via bts pseudo package > or directly via mail? Usually on the #debian-ftp IRC channel on OFTC is a better option for this particular type of request. > PS: i am not subscribed to this ml, please keep me in cc when ansering ;) Done. PS: In future, when asking questions, please include specific details, including package names and excerpts of build logs etc. Advice is almost always better when given more information as input. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Handling stale bug reports
On Sat, Aug 7, 2021 at 10:54 PM Brian Thompson wrote: > How should a new maintainer go about closing old bug reports? I noticed that you have been: Closing bug reports without any explanation. Closing what looks like legitimate feature requests. Neither of these is a good idea IMO. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Handling stale bug reports
On Sat, Aug 7, 2021 at 10:54 PM Brian Thompson wrote: > What's the best way to go about handling old bug reports? Triage them; go through each bug, try to find out if it was fixed and which version it was fixed in. For the definitely fixed bugs, close them with a versioned -done message. For the definitely not fixed bugs, mark them as found in the versions you tested the issue on. For issues that were caused by an incorrect action by the submitter, close them with an unversioned -done message. For other situations, discuss the issues with their submitters and potentially with the rest of the APT team and with the wider Debian community. If no obvious course of action presents itself for a bug and the bug doesn't appear to have value any longer, the last resort is to just close the bug. Some more bug triage tips are on the wiki, and the links in the "Other documentation" section of the page. https://wiki.debian.org/BugTriage -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian/watch file does not ignore beta version
On Thu, Jun 24, 2021 at 10:01 PM Hilmar Preuße wrote: > uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/,\ ... > According to [1] the entry "uversionmangle=..." should handle the case > that there could be beta/rc versions, which should be ignored. When > doing an uscan now it downloads happily version v1.3.8rc1, which is > available from upstream, instead of the expected 1.3.7b. Using uscan --verbose helps diagnose the issue: uversionmangle just adds the ~ character into rc versions in the right place, it doesn't make the matched versions disappear. Since there is no v1.3.8 tag yet, the latest tag v1.3.8rc1 gets assigned version 1.3.8~rc1, which is later than the 1.3.7b version. There are two ways to make the rc versions disappear: Make the version matching regex ignore them. Make uversionmangle change their versions so they are earlier than all the other versions. Personally I would do neither of these and instead start uploading beta/rc versions to experimental, you can get valuable feedback from CI/users this way that can then feed back upstream to fix any issues before the final release. PS: I suggest using mode=git, because the GitHub tags pages are paginated, cutting off older versions. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.
On Thu, 2021-06-24 at 23:30 +0800, Tian Qiao wrote: > I will suggest to upstream, remove these binary dependencies in > subsequent code refactoring, and use some assembler libraries > instead, such as Keystone. Thanks! Switching to different dependencies shouldn't be necessary, just not including the dependencies in the git repository and instead including them in the Windows binary packages. Alternatively just run the dependencies at build time and include the build results in the binary packages for each platform. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.
On Thu, 2021-06-24 at 00:46 +0800, Tian Qiao wrote: > Besides, "nasm.exe" and "objdump.exe" are provided for the > convenience of Windows users. I suggest upstream should remove these from the source code and only distribute them with their Windows binary packages. The build process for the Windows binary packages could download the files. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.
On Wed, 2021-06-23 at 18:32 +0800, Tian Qiao wrote: > On Jun 23, 2021, at 1:06 AM, Tobias Frost wrote: > > > shellcodes/data/linux/*bin > > - Are they rebuilt during package build? > > these are similar to static resources, which help users quickly build > shellcode when writing exploit script. > So won’t rebuild during package build. How were these files created? It looks like they are generated from the assembly files in the src/ subdirectory. All generated files should be built from source at build time, and preferably removed from the upstream source repository and tarballs, or the Debian tarball. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.
On Fri, Jun 18, 2021 at 8:30 AM Tobias Frost wrote: > I suggest to read [1] and all linked documents, and recreate the package. > You'll find dh_make(1) from the package dh-make useful to generate boiler > plate > templates for the debian directory. Those templates needs to be hand-edited > afterwards, many of them wont be needed: you'd rm them… To get hints, you may > take a look a similar packages as well The packages generated by stdeb are usually much closer to a final package than those generated by dh-make, so I would suggest to fix the existing packaging instead of starting from scratch. -- bye, pabs https://wiki.debian.org/PaulWise
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
Bug#988484: ITP: openh264 -- H.264 encoding and decoding
On Wed, Jun 2, 2021 at 3:36 PM Tobias Frost wrote: > Has this been discussed on e.g debian-legal or with the ftp masters > beforehand? FTR, Debian's patent policy is to only discuss them with lawyers, never in public: https://www.debian.org/legal/patent https://www.debian.org/reports/patent-faq -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#979807: Bug#979400: RFS: drs/5.0.5-1 [ITP] -- DRS4 Evaluation Board software
On Tue, Jun 1, 2021 at 11:46 AM Steffen Möller wrote: > I had a look and like the device. Conceptionally, it would be very > interesting to learn if you can build the firmware for the Spartan-3 > also with Debian. It should be possible with Yosys. I do not mean that > you need to Open Source your firmware, but just to know that others > could come up with their own and use that - would be nice, maybe you > could open source some parts of that so that the driver could be reused > - you get the idea. The tarball already includes the firmware source in *.vhd and other files, presumably under the same license as the rest of the package, but I cannot find any indication in the tarball that this package is under the GPL though (except for the embedded code copy of the MIDAS XML Library), but the website does say GPLv3. Looks like Yosys doesn't yet fully support Spartan-3: https://github.com/YosysHQ/yosys/issues/448 SymbiFlow are working on Xilinx Artix 7-Series FPGAs, perhaps they could eventually support Xilinx Spartan-3 too. https://symbiflow.github.io/ -- bye, pabs https://wiki.debian.org/PaulWise
Bug#979807: RFS: drs/5.0.5-1 [ITP] -- DRS4 Evaluation Board software
On Tue, Jun 1, 2021 at 10:39 AM Tobias Frost wrote: > this seems to be a quite specific software for some quite specific evaluation > board… The chip seems like something useful for scientists and others dealing with high speed analog signals. Looks like both the board and the chips themselves can be purchased by anyone, I presume that the physics department of ETH Zurich (see the submitter's email) has purchased them and is using them in their own experiments and is also using Debian and wants to use Debian packages of the software. http://phys.ethz.ch/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Are these superficial autopkgtests?
On Tue, May 25, 2021 at 1:53 AM John Scott wrote: > Note that in their reference to building a 'Hello, world' program, the > specification says that what makes the test superficial is that the > library's functionality isn't used in the 'Hello, world' program, but > merely linking against it is tested. Since I'm testing GCC, Newlib > (which provides the I/O functions), and the simulator in combination, > is building and running such relatively simple programs appropriate to > say that the tests provide good coverage? I would say both of these are non-superficial tests, since they both exercise major parts of the functionality (code generation, linking?, I/O functions, simulation etc) rather than just superficial things like options processing etc. Obviously if you can come up with more tests to exercise a larger variety of functionality, that would be good. BTW, is qemu-system-sh4 not suitable for running the output of gcc-sh-el? Also, yabause is an emulator for the Sega Saturn, which was a games console based on SuperH SH-2. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#988466: RFS: aspell-sl/0.60-5 -- Slovenian dictionary for GNU Aspell
On Fri, 2021-05-21 at 08:27 +0200, Tomaž Šolc wrote: > Should I wait with this package until Bullseye is released? Yes, or upload to experimental now and unstable after the release. > If you think it makes more sense, I can simply drop it from the binary > package. I think it makes sense to leave it out of the binary package and maybe use sed to remove the references to it from the README file. > I like it better the way it is right now because doc-utf8 directory is > created and removed a few lines apart in d/rules. It makes it clearer > what is going on. Fair enough. > Can you tell me which lintian warnings you mean? I only get: No warnings, but I enable all the lintian complaints: $ cat ~/.lintianrc info=yes display-info=yes display-experimental=yes pedantic=yes show-overrides=yes color=auto verbose=yes Unfixable: I: aspell-sl source: homepage-refers-to-filesystem-listing https://ftp.gnu.org/gnu/aspell/dict/0index.html I: aspell-sl: homepage-refers-to-filesystem-listing https://ftp.gnu.org/gnu/aspell/dict/0index.html X: aspell-sl source: debian-watch-does-not-check-gpg-signature Incorrect: I: aspell-sl: wrong-section-according-to-package-name aspell-sl => localization Fixable (but your reasoning is fair enough): P: aspell-sl source: package-uses-old-debhelper-compat-version 12 Probably not fixable yet? X: aspell-sl source: upstream-metadata-file-is-missing > It's a text file compressed with "prezip" (part of aspell). You can > decompress it with "precat sl.cwl" When I used diffoscope to compare the .dsc files, I get a big hex diff because it doesn't know about this file format. diffoscope can convert binary files to plain text to make for more human readable diffs. Could you submit a feature request about allowing this for aspell cwl files? I would do it but I guess you know more about the format/extensions. I noticed when diffing the precat output that there has been a lot of reordering of words, could this have any adverse effects? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#988466: RFS: aspell-sl/0.60-5 -- Slovenian dictionary for GNU Aspell
On Thu, 2021-05-20 at 20:28 +0200, Tomaž Šolc wrote: > I contacted Tomaž Erjavec and Aleš Košir (one of the authors of > aspell-sl). aspell-sl is currently unmaintained. The old website and the > archive of releases were lost in a hard drive crash. Some of it is available on archive.org, but only earlier versions. This tool can be used to download everything from archive.org: https://github.com/hartator/wayback-machine-downloader/ > I checked the gnu.org release (0.50-0). It appears newer than 0.60 on > which the current Debian package is currently based, despite its version > number. It has a later copyright date (2004 vs. 2002) and the dictionary > has approx. 17000 new words added and no words were removed. That is an interesting development, thanks for noticing. > For now I think it makes sense to base the aspell-sl Debian package on > the 0.50-0 release from gnu.org instead of the 0.60 from the old > website. I see on repology.org that other distros that don't pull > aspell-sl package from Debian do that as well. Agreed. > In the long term, it would be nice if aspell-sl would get a new upstream > maintainer. I will send out a few more mails, but I suspect finding one > will not be easy. Thanks for doing that. If that happens, I think the AUTHORS file from 0.60 should get restored, it is important to give credit for work people do. If that happens, whoever creates the new project might want to import all the upstream tarballs from archive.org and the Debian snapshots, so that the project history is preserved. https://snapshot.debian.org/package/aspell-sl/ > I've updated my proposed package: I changed the version to > 0.60+really0.50.0-1, updated the copyright file, added a watch file that > checks the gnu.org index and did a few other minor packaging changes. As I'm not a Slovenian speaker and am not doing any i18n/l10n, I'm not the best person to be sponsoring this package. Since there is no translation list for Slovenian, I suggest that you ask on the debian-i18n mailing list for a sponsor. Alternatively, hopefully Tobias Frost (CCed) will sponsor, as they did in 2016 for the last upload. If both of these options fail, then I am willing to sponsor, some comments you might want to look at before that though: * At this point in the freeze, the release team asks for folks to upload new upstream releases and other changes not targeted at bullseye to be uploaded to experimental instead of unstable. - https://release.debian.org/bullseye/freeze_policy.html * Should doc/sl_SI.aff also be converted to UTF-8? * Should doc/sl_SI.aff be installed outside /usr/share/doc? - `apt-file search .aff` suggests the same location as the other files * The web page in the Vcs-Browser field doesn't really provide a web based interface for browsing the git repo, I suggest dropping that. * Your copyright dates on debian/* should be "2016, 2021". * Creating debian/clean would let you drop override_dh_clean * There are some lintian complaints: - some of them are true and unfixable (you could override these with a comment explaining the situation) - at least one of them is incorrect (you could file lintian bugs) - at least one of them could be fixed * file is not able to identify sl.cwl, any idea what format it is and what tools are able to read it? (you could file a bug against file) PS: I did a search through the Debian locations resources and found a few places where Slovene, Slovenia or Slovenian are referred to within a Debian related context, links below. In case you want to bring the Debian Slovenian community together, these links could be a good start. https://wiki.debian.org/DebianLocations https://wiki.debian.org/JanPrunk https://wiki.debian.org/DebianEdu/Help/ProfessionalHelp#Slovenia https://lists.debian.org/debian-user-slovenian/ ircs://irc.oftc.net/debian.si (from https://wiki.debian.org/IRC) (only one person in the channel. several others in the access list, one of them (Jan Prunk ) is online today (but not in the channel), the rest were last online in 2011 but have registered email addresses) https://www.debian.org/international/l10n/po/sl https://www.debian.org/international/l10n/po/sl_SI https://www.debian.org/international/l10n/po-debconf/sl https://www.debian.org/international/l10n/po4a/sl https://www.debian.org/devel/website/stats/sl#gettext https://d-i.debian.org/l10n-stats/level1/sl.txt https://d-i.debian.org/l10n-stats/level2/sl.txt https://d-i.debian.org/l10n-stats/level3/sl.txt https://www.debian.org/mirror/sponsors (ftp.arnes.si sponsored by ARNES) https://www.debian.org/consultants/#SI https://web.archive.org/web/20100206014457/http://debian.si/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Question about writing systemd unit for old package
On Wed, May 19, 2021 at 8:51 AM Richard Hector wrote: > Does that not depend on whether it does anything before dropping > privileges? For example, a webserver can bind to low ports before > dropping privilege. I imagine if the systemd service unit specified > running as (eg) www-data, that wouldn't work. I don't know the details, but I think systemd can open the ports and transparently pass them to the unprivileged process when it is spawned without any data loss, in a similar way to the inetd stuff used to work. http://0pointer.de/blog/projects/inetd.html -- bye, pabs https://wiki.debian.org/PaulWise
Re: Question about writing systemd unit for old package
On Mon, May 17, 2021 at 12:51 PM Khoa Tran Minh wrote: > I'm trying to write a new systemd unit for mini-httpd package, which is > using lsb-base to init. Can I replace the old init script straight up, or > do I have to maintain both the systemd unit and the old init script ? Please make sure you send the systemd unit upstream too. Users of init systems other than systemd would probably appreciate it if you didn't remove the old init script. If the old init script is crufty, you could rebase it onto the init-d-script tool, but I am not sure how portable that is to non-Debian distros. https://manpages.debian.org/init-d-script > A related question: The binary itself can drop privilege and run as > non-root, then should I use that native feature or use systemd User= when > writing a default config/unit ? I would suggest to use systemd features for this. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#988466: RFS: aspell-sl/0.60-5 -- Slovenian dictionary for GNU Aspell
On Thu, May 13, 2021 at 3:15 PM Tomaž Šolc wrote: > The upstream homepage for this package is no longer available on the web. I > continue to maintain this package since it is the only Slovenian spell checker > available in Debian. The Homepage is 404, but the site it was on still works. Have you tried contacting the person (Tomaž Erjavec) listed at the bottom of the page (there is an email)? https://nl.ijs.si/ I noticed an older version of this on the GNU website. It might be worth contacting the aspell/ispell communities about this too. https://ftp.gnu.org/gnu/aspell/dict/sl/ https://ftp.gnu.org/gnu/aspell/dict/0index.html I noticed that LibreOffice includes support for Slovenian and have their own dictionary. It might be worth contacting the Slovenian LibreOffice community. https://wiki.documentfoundation.org/Language/Support https://sl.libreoffice.org/ https://extensions.libreoffice.org/en/extensions/show/slovenian-dictionary-pack https://extensions.libreoffice.org/en/extensions/show/odprtitezaver-slovenian-thesaurus http://www.tezaver.si/ https://cgit.freedesktop.org/libreoffice/dictionaries/tree/sl_SI/ If all of the above suggestions don't help, I would encourage you to create a new upstream project for aspell-sl, release a new version and then contact all the distro maintainers to update to your new release. https://repology.org/project/aspell-sl/versions -- bye, pabs https://wiki.debian.org/PaulWise
Bug#985893: Forking on MMSD
On Wed, Apr 14, 2021 at 7:42 PM Pavel Machek wrote: > I don't think forking ofono is good idea. I'd like to point out that this isn't ofono that is being forked, but mmsd. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Only got half of the conversation from salsa.debian.org in mail
On Fri, Apr 2, 2021 at 6:26 PM Tong Sun wrote: > Is that possible with salsa.debian.org? thx Preferences -> Notifications -> Receive notifications about your own activity. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Help for packaging Trigger Rallys next version
On Mon, Mar 29, 2021 at 8:03 PM Onsemeliot wrote: > I suspect adapting the old Trigger Rally Debian package isn't as > complicated as it seems to me right now. It is made slightly more complicated by this being a team maintained package that is stored in a git repository. If it weren't stored in a git repository, the update process would be something like this: # Get the current source apt source trigger-rally cd trigger-rally*/ # Download the latest upstream source uscan --verbose # Copy the debian/ dir to the new packaging uupdate ../trigger-rally_0.7.0.orig.tar.gz cd ../trigger-rally-0.7.0/ # Build the source package # (checks if the Debian patches still work) # (some of them are applied upstream so will need to be removed first) debuild -S # Update the Debian copy of the upstream copyright info $EDITOR debian/copyright # Review all the Debian packaging mc debian/ # Build the package in a clean chroot pdebuild # Check the package for issues lintian # upload to mentors.debian.net debrelease Longer-form documentation for the above is linked from here: https://mentors.debian.net/intro-maintainers The addition of the team maintenance means you will need to join the Debian games team. The use of a git repository means you have to find out which workflow the games team uses for their trigger-rally repository. > Can a mentor guide me so that I can become competent enough to > contribute in a meaningful way by creating the next deb package for our > project? If you have any particular questions, please feel free to ask them on this list. -- bye, pabs https://wiki.debian.org/PaulWise
Re: rm_conffile and left behind files
On Sun, Mar 7, 2021 at 5:07 AM Tong Sun wrote: > Is it OK that I simply `rm` them, like `rm /etc/dnsmasq.d/dbab-*`? I think so, yes. -- bye, pabs https://wiki.debian.org/PaulWise
Re: rm_conffile and left behind files
On Sun, Mar 7, 2021 at 4:45 AM Tong Sun wrote: > Ah, indeed. the two files are modified after the package was > installed. Actually they are generated, not from within the package. Configuration files should either be conffiles installed in the .deb or files created by the package at postinst/run time, but not both of these at the same time. So the .deb should not contain the files and they should get removed from disk by the prerm. Also you will need to transition them from conffiles to regular files, I don't know how to do that though. -- bye, pabs https://wiki.debian.org/PaulWise
Re: rm_conffile and left behind files
On Sun, Mar 7, 2021 at 3:31 AM Tong Sun wrote: > after I remove the package Did you remove the package or purge it? Removing it will not run the postrm, but purging it will. > the last two files ... still remains and are left behind, while the first one > was indeed gone. Were the two files modified after the package was installed? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Controlling the init system for my package
On Sun, Feb 21, 2021 at 9:56 PM Tong Sun wrote: > What's the correct way to install/enable/remove the daemon from my > package inside the post install/rm scripts? Usually debhelper will do the right thing without any configuration. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Looking for GSoC 2021 Project Mentor
On Sun, Feb 14, 2021 at 12:36 PM Kavan Mevada wrote: > One manifest file to generate all required files for packaging so we don't > have to look at multiple files There was a project created similar to this last year, but the project was abandoned in the end, you might want to contact the author to discuss it. https://github.com/dupr/duprkit/ https://lists.debian.org/msgid-search/22bf61c333d3694911c5c78016906...@debian.org https://lists.debian.org/msgid-search/775023a55a7883fa5ff6b5953c47d...@debian.org https://lists.debian.org/msgid-search/20190409161728.GA10592@Asuna Personally I dislike mixing multiple different file formats or languages into one file like the RPM folks do in .spec files. > which build system it would use That shouldn't be needed, the build system should be automatically detected. debhelper already does that and Debian is working more towards automating everything else involved in packaging. https://wiki.debian.org/AutomaticPackagingTools -- bye, pabs https://wiki.debian.org/PaulWise
Re: Sending gpg keys to keyserver
On Tue, Feb 9, 2021 at 6:48 PM Ross Gammon wrote: > I have an upload stuck in the upload queue due to an expired key, and I > would like upload my newly unexpired key to the Debian keyservers so > that it is eventually unblocked. > > But I get this error: > $ gpg -v --keyserver keyring.debian.org --send-key 'fingerprint' > gpg: sending key 0x to hkp://keyring.debian.org > gpg: keyserver send failed: Connection refused > gpg: keyserver send failed: Connection refused That command works for me and looks like the correct one according to: https://keyring.debian.org/ > 6. Today, realise the upload has silently failed due to expired key. > 7. Extend expiry date of keys forward two more years. It is a good idea to set a calendar appointment or at/systemd-run job to give you a reminder before the date. I'm doing the expiry update 3 months before my expiry. https://riseup.net/en/security/message-security/openpgp/best-practices#set-a-calendar-event-to-remind-you-about-your-expiration-date > Any ideas on what configuration I might need to update? Maybe look at your firewalls, network or proxy setup, or use wireshark and tcptraceroute to see what is blocking the connection. Or try creating a temporary user on your machine, logging in as that, creating a new key with a test name/email and try sending that to the server, the result will give some more info on where the problem is. Also do that from another machine on the same network, or from a Debian Live system booted on your machine. -- bye, pabs https://wiki.debian.org/PaulWise
Re: init.d-script-does-not-source-init-functions, is it really necessary
On Sun, Feb 7, 2021 at 5:34 AM Tong Sun wrote: > The bug report is at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958899 > > Basically I was trying to start/stop a Perl based http server. > I do have one that almost like that, > https://github.com/suntong/dbab/blob/master/bin/dbab > but somehow codes were added when I found cases when things didn't work. I think using /usr/bin/env in the #! line as the init-d-script manual example does would make the script work on kFreeBSD. > So you are saying something as simple as ... > without anything else would be good enough? In theory yes, I haven't tested it for your case. You would also of course need to fix the descriptions and arguments though. -- bye, pabs https://wiki.debian.org/PaulWise
Re: init.d-script-does-not-source-init-functions, is it really necessary
On Sat, Feb 6, 2021 at 9:31 PM Tong Sun wrote: > I have a dilemma, I suggest deleting your existing init script and instead using the example from the init-d-script(5) manual page. > However, sourcing /lib/init/init-d-script will break in some cases, > because of which, I had a bug opened against my package. Please link to the bug report. -- bye, pabs https://wiki.debian.org/PaulWise
Re: daemon start/stop for sysvinit
On Sat, Feb 6, 2021 at 9:02 PM Tong Sun wrote: > Is there a way to make both systemd and sysvinit Debian happy, for my > Perl based daemon? sysvinit is not compatible with systemd units. You will need to add an init script, see the simple example in the init-d-script(5) manual page, unless your daemon is more complicated. > > Letting dh_installinit put code into postinst etc has done the right > > thing for me in a package of my own > > But I'm having a hard time making some senses out of that short sentence. I think that is referring to the situation where you already have an init script and dh_installinit from debhelper takes care of running the init script from the postinst when you install the package. -- bye, pabs https://wiki.debian.org/PaulWise
Re: My package version is incorrect
On Sat, Feb 6, 2021 at 9:20 PM Tong Sun wrote: > My package version is incorrect. It is currently "1.5.01-1", which I > later learned that it should be "1.5.1-1" instead. These two versions are considered equal by dpkg: $ dpkg --compare-versions "1.5.01-1" eq "1.5.1-1" ; echo $? 0 $ dpkg --compare-versions "1.5.01-1" lt "1.5.1-1" ; echo $? 1 $ dpkg --compare-versions "1.5.01-1" gt "1.5.1-1" ; echo $? 1 > Is it so? and what should I do about it before the freeze? (there > haven't been any upstream functional improvements since then) I'm not sure if dak would accept the change but there also doesn't appear to be any reason to change the version that I can see, since 1.5.2-1 is greater than 1.5.01-1 too. $ dpkg --compare-versions "1.5.01-1" lt "1.5.2-1" ; echo $? 0 -- bye, pabs https://wiki.debian.org/PaulWise
Re: Platformer game package - "Super Bombinhas"
On Tue, 2021-02-02 at 07:19 -0300, Victor David Santos wrote: > bundle.rb is still useful for the way I currently create an > executable for Windows. deb.sh would still be useful to copy the > files to the package structure (or is there a better way to do this?) The intro guide I linked will have info on how to create the Debian package correctly. > It's no longer used, I removed the "Aleva Games" name from the > project and decided to launch it under my own name. By the way, none > of the SVG files in the project are being used. They are remainders > from long ago, when the game's graphics weren't even pixel art... I > will remove them. I see. The names seemed similar to the aesprite files. BTW, aesprite is now proprietary so I suggest you switch to LibreSprite. https://libresprite.github.io/ > It's the logo from my engine, I don't see the point in including the > original SVG file in the project. The PNG file is built from the SVG file, so the PNG is not source and should not be in the Git repo, while the SVG file is source and so should be in the Git repo. > I downloaded most of them from freesound.org, edited some of them > myself on Audacity. OK, so the original source for the audio is probably lost as usually folks only upload their premixed versions, possibly based on proprietary samples and digital instruments. > They were all composed by other people and exported to me as OGG. I > don't know exactly what technologies they used, one of them I know > used Ardour 6, but possibly also other software. Same goes for this. > They were created in Linux Multimedia Studio. However, they are also > no longer used, I will remove them from the project. and for this. -- bye, pabs https://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part
Re: Platformer game package - "Super Bombinhas"
On Mon, 2021-02-01 at 08:36 -0300, Victor David Santos wrote: > Thanks for the detailed feedback. Just to make sure, not all of these > items you pointed out are mandatory for the package to be accepted, > right? All of the points I made are my personal opinions. There are a range of different approaches to the things I brought up within Debian and opinions on them vary widely. I don't generally sponsor packages so my opinions don't really matter here and I expect there are plenty of folks who would not require any of the changes I suggested. I only post my opinions in order to try to influence people to do things in what I see as a way to mitigate lots of downsides of certain practices. > For example, the fact that my font image doesn't support all > character sets. It's not viable for me to make it support all of > them, instead I would update it on demand as new translations were > made... An alternative approach would be to render text from the system fonts at runtime, that would give you support for every language with fonts. That might not fit with your design philosophy though, so perhaps it is best to stick the current approach of hand-drawn pixel fonts for now. > If you could point out to me which of these are changes I must do, > that would help a lot... I don't have as much time to dedicate to > this project as I would like. :/ Reading through the intro guide, creating a Debian source package (rather than just a .deb) and packaging gosu/minigl are the only things you must do. Answers to the questions I asked would not take long to do and would be useful to have. > The Gosu library is not owned by me, so how would I proceed to have > it packaged for Debian? Is it really necessary, considering that it's > a Ruby gem, publicly available from rubygems.org? Each dependency must be separately packaged in Debian properly with a new source package (.dsc) and one or more binary packages (.deb). Personally I would suggest packaging them from the upstream source on GitHub rather than from the Ruby gem files. That isn't mandatory for Debian packages of Ruby projects though. https://www.libgosu.org/ https://github.com/gosu/gosu/ https://github.com/victords/minigl -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Platformer game package - "Super Bombinhas"
On Sun, Jan 31, 2021 at 8:36 PM Victor David Santos wrote: > I would like to distribute my open source platformer game in the official > Debian repositories. Please review our guide for new package maintainers: https://mentors.debian.net/intro-maintainers Some things you might want to think about before working on this: The game appears to be GNU GPLv3 and CC-BY-SA-4.0 rather than MIT licensed. I thought Ruby could load code from multiple files, maybe using modules or similar, so deb.sh and bundle.rb probably are unnecessary? gosu and minigl aren't yet in Debian, so you would need to package those for Debian first. It might be interesting to package the editor too so people can add their own levels. If you update the code/data and release a new version, the screenshots could get outdated, creating them at build time can avoid this. You might want to switch from your custom i18n/l10n to a more standard format like gettext, since that is what most translators are used to. The images in deb/ and data/ are built from the *.svg and *.aesprite files. Some of the *.aesprite files seem to be created from *.svg files. That should happen at build time instead of storing the prebuilt files in the git repository. I wonder about where the res/alevaLogo.svg file came from, what it refers to and what the license is. It also doesn't appear to be used anywhere in the codebase? I note that data/img/ui/minigl.png was rendered from Inkscape but there is no corresponding minigl.svg file. It also doesn't appear to be used anywhere in the codebase? How were the audio files in data/sound/ created? How were the audio files in data/song/ created? How were the audio files in res/song/ created? Some of the images contain pre-rendered text, which means that text won't be translatable. Also the font image only supports a limited set of characters, so the game won't be translatable to non-Latin alphabets. I note that several (res/bombie2.svg, res/BombaAzul.svg, res/Fureel.svg, res/tileset/2.svg) of the SVG images contain bitmaps, so that means they won't be scalable if you want to make a higher-resolution version. deb.sh does not contain any bashisms, so it could be POSIX shell instead of bash. There is a typo in elements.rb, replace "seciton" with "section". There are a few duplicate files, run this command to find them: fdupes -q -r . The path in the .deb should be /usr/share rather than /opt. The data/*/README.md files have some http links that could be turned into https. The roodi and rubocop Ruby code checkers report some issues at different levels. -- bye, pabs https://wiki.debian.org/PaulWise
