Re: reference Debian package of multiple binaries sharing one man page
On 11/11/23 08:12, Tobias Frost wrote: On Fri, Nov 10, 2023 at 08:20:35PM +0100, Norwid Behrnd wrote: I seek a maintained Debian package which provides multiple binaries sharing one man page in common -- do you know an example? devscripts - it links debchange.1 to dch.1 via debian/links (dh_link) $grep -r dch debian/links /usr/bin/debchange /usr/bin/dch Please note that using d/links for manpages breaks building packages with , unless dh-exec is used and the manpages links are marked with . Regards, -- Gioele Barabucci
Re: reference Debian package of multiple binaries sharing one man page
Hi, On 2023/11/11 3:20, Norwid Behrnd wrote: Hello, I seek a maintained Debian package which provides multiple binaries sharing one man page in common -- do you know an example? Vim is an example of this, if I recalled it right - Vim has multiple frontends, there is a CLI one and a GTK one, which is in vim-gtk3 package. Both frontends has its corresponding manual pages, but they are identical. However, vim(1) is packaged into vim-common, gvim(1) is packaged into vim-gui-common. Since one copy of the manual is packages two times separately, I don't see any issue like this will come to Vim. Regards, Xinhui
Re: Linking coreutils against OpenSSL
On 2023-11-10 Michael Stone wrote:
> On Fri, Nov 10, 2023 at 03:10:42PM +0100, Ansgar wrote:
>> Please avoid producing different results depending on the build
>> environment. That just results in non-reproducible issues in unclean
>> environments (suddenly different dependencies, different features,
>> ...).
> I think that is an acceptable tradeoff at this time; the only difference
> will be the dependencies, but that is the intent. Automated buildd packages
> should be stable. Based on further experience and feedback, one of the other
> options could be chosen instead. (I'm particularly interested in hearing
> from people who compare the different builds on arm, as that is where
> there's been an assertion of a performance regression.)
Hello,
you seem to have missed/deleted the paragraph where Ansgar suggested how
to do this *without* tradeoff. ("explicitly disable/enable build options
per arch")
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru coreutils-9.4/debian/rules coreutils-9.4/debian/rules
--- coreutils-9.4/debian/rules 2023-11-10 14:31:21.0 +0100
+++ coreutils-9.4/debian/rules 2023-11-11 11:37:05.0 +0100
@@ -13,13 +13,20 @@
DEB_CFLAGS_MAINT_APPEND += -mieee
endif
+ifeq ($(DEB_TARGET_MULTIARCH),x86_64-linux-gnu)
+opensslconf = --with-openssl=auto-gpl-compat
+else
+opensslconf = --with-openssl=no
+endif
+
BIN_PROGS = cat chgrp chmod chown cp date dd df dir echo false ln ls mkdir \
mknod mv pwd readlink rm rmdir vdir sleep stty sync touch true uname \
mktemp
d=debian/coreutils
override_dh_auto_configure:
- dh_auto_configure -- --enable-install-program=arch --with-openssl=auto-gpl-compat
+ dh_auto_configure -- --enable-install-program=arch \
+ $(opensslconf)
%:
dh $@ --with autoreconf
Re: Linking coreutils against OpenSSL
On Sat, Nov 11, 2023 at 11:50:31AM +0100, Andreas Metzler wrote:
you seem to have missed/deleted the paragraph where Ansgar suggested how
to do this *without* tradeoff. ("explicitly disable/enable build options
per arch")
No, I didn't. That was in my original email and is one of the
possibilities for future versions depending on the feedback from people
testing to guide whether it makes sense to make this per-arch rather
than global.
Re: reference Debian package of multiple binaries sharing one man page
Hello, On Fri, Nov 10, 2023 at 08:20:35PM +0100, Norwid Behrnd wrote: > However, there still is some detail I did not understand well enough; the > additional line > > .so man1/mdl.1 > > in my file /debian/markdownlint.1 I think you missunderstodd the instructions: > Here is how to do it: If you want to have your man page available under the > names `foo' and `bar' in section 1, then put the man page in foo.1 and have > bar.1 look like this: > > .so man1/foo.1 You will need a file mdl.1 with the following content: .so man1/markdownlint.1 and markdownlint.1 should be the normal manpage without a .so line. Alex
Re: Linking coreutils against OpenSSL
On 2023-11-11 Michael Stone wrote:
> On Sat, Nov 11, 2023 at 11:50:31AM +0100, Andreas Metzler wrote:
> > you seem to have missed/deleted the paragraph where Ansgar suggested how
> > to do this *without* tradeoff. ("explicitly disable/enable build options
> > per arch")
> No, I didn't. That was in my original email and is one of the possibilities
> for future versions depending on the feedback from people testing to guide
> whether it makes sense to make this per-arch rather than global.
Hm. Would you mind explaining why you chose to not implement this but
instead only used a per-arch build-dep? (With the downside of wrong
builds on dirty chroots and slent breakage when a respective feature
is not found)?
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
New sparc64 porterbox available
Hi! After a long time since the previous sparc64 porterbox went offline since it had to move out of the data center at my old university, I am happy to announce that a new sparc64 porterbox is now available. The porterbox is a virtual machine (LDOM) hosted on a SPARC T4-1 with 96 GB of RAM and more than 500 GB of disk space (I hope we will be able to increase the available disk space in the near future). Hosting is kindly provided by Cononva Communications GmbH in Salzburg, Austria. I have already verified that creating a chroot works as expected and I could test-build a package without any issues, so I am confident it should work for everyone else. For questions and problems reports, please drop me an email or join #debian-ports on OFTC IRC network. Thanks, Adrian > [1] https://db.debian.org/machines.cgi?host=stadler -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1055791: ITP: env-assert -- tool to ensure that the environment variables match expectations
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: env-assert Version : 0.008 Upstream Author : Mikko Koivunalho * URL : https://metacpan.org/release/Env-Assert * License : Artistic or GPL-1+ Programming Lang: FIXME Description : tool to ensure that the environment variables match expectations The envassert script, accompanied by the Env::Assert module, checks that your runtime environment, as defined with environment variables, matches with what you want. You can define your required environment in a file. Default file is .envassert but you can use any file. It is advantageous to use envassert for examnple when running a container. If you check your environment for missing or wrongly defined environment variables at the beginning of the container run, your container will fail sooner instead of in a later point in execution when the variables are needed. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1055803: ITP: golang-github-backblaze-blazer -- Go library for Backblaze's B2
Package: wnpp Severity: wishlist Owner: Félix Sipma X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-backblaze-blazer Version : 0.6.1 Upstream Contact: Backblaze * URL : https://github.com/Backblaze/blazer * License : Apache-2.0 Programming Lang: Go Description : Go library for Backblaze's B2 Blazer is a Golang client library for Backblaze's B2 object storage service. It is designed for simple integration with existing applications that may already be using S3 and Google Cloud Storage, by exporting only a few standard Go types. . It implements and satisfies the B2 integration checklist (https://www.backblaze.com/b2/docs/integration_checklist.html), automatically handling error recovery, reauthentication, and other low-level aspects, making it suitable to upload very large files, or over multi-day time scales. This is a dependency of restic. I intend to maintain this package within the Debian Go Packaging team. -- Félix signature.asc Description: PGP signature
Bug#1055819: ITP: poetry-plugin-export -- export of locked packages to various formats
Package: wnpp Severity: wishlist Owner: Emmanuel Arias X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: poetry-plugin-export Version : 1.6.0 Upstream Contact: Sébastien Eustace * URL : https://github.com/python-poetry/poetry-plugin-export * License : expat Programming Lang: Python Description : export of locked packages to various formats This package is a plugin that allows the export of locked packages to various formats. For now only the constraints.txt and requirements.txt formats are available. This plugin provides the same features as the existing export command of Poetry which it will eventually replace. . This package is necessary to build the last upstream release of poetry. . I plan maintain this package under the Python Team umbrella. signature.asc Description: PGP signature
Re: Linking coreutils against OpenSSL
On Sat, Nov 11, 2023 at 09:32:46AM +0200, Julian Andres Klode wrote: > > WRT dlopen(), this is never an appealing solution because you do not > get any type-checking, you have to make sourceful changes for an soname > bump. It is an interface you can use for loading plugins (that is, you > should be in control of what the interface is that you are loading from > the library object), but it's not really usable for stuff that is outside > of your control. There are some caveats, yes, but I *have* made it work. For example, see [1]. This allows debugfs in e2fsprogs to use GNU readline (or BSD's libedit), which is *super* convenient, without requiring forcing GNU readline to be placed in emergency boot floppies or being added to essential. [1] https://github.com/tytso/e2fsprogs/blob/master/lib/ss/get_readline.c For things which are optional, if there is a soname bump, things won't stop working. In the case of coreutils and OpenSSL, sha1sum will just git a bit slower --- in fact, the speeds that it has today, which has never been a problem for me, FWIW. And yes, to add accomodate a soname bump you might need to make some sourceful changes, but it's often not that hard to do. At least for the libreadline functionality used by debugfs, it's mainly doing a bit of testing, concluding "nope, the ABI didn't change for the functions that libss cares about", and just adding the additional SONAME to: #define DEFAULT_LIBPATH "libreadline.so.8:libreadline.so.7:libreadline.so.6:libreadline.so.5:libreadline.so.4:libreadline.so:libedit.so.2:libedit.so:libeditline.so.0:libeditline.so" :-) As another example, I have a pending patch to e2fsprogs that I will shortly integrating which allows mke2fs to optionally use libarchive, so that mke2fs -d can take a tarball, but again, without expanding the dependencies for e2fsprogs. It's not *that* bad. - Ted
