Re: isa-support -- exit strategy?
On Sun, 2022-04-03 at 14:17 +0300, Adrian Bunk wrote: > For binaries, I have seen packages in the Debian Med (?) team that build > several variants of a program and have a tiny wrapper program that chooses > the correct one at startup. It appears this is called simd-dispatch and the script is available in several packages, but here is an example copy of it. https://sources.debian.org/src/scrappie/latest/debian/bin/simd-dispatch Probably something like this should move to isa-support, so that it can be shared instead of duplicated. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: isa-support -- exit strategy?
On Fri, 2022-03-25 at 23:34 +0100, Adam Borowski wrote: > Suggestions? FYI, as a result of this coming up on IRC again, I have summarised various suggestions on this wiki page for future reference: https://wiki.debian.org/InstructionSelection Please feel free to update/fix the page as needed. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1019205: ITP: elpa-srv -- RFC2782 (SRV record) client for emacs
Package: wnpp Severity: wishlist Owner: David Bremner X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: elpa-srv Version : 0.2 Upstream Author : Magnus Henoch * URL : https://github.com/legoscia/srv.el * License : GPL2+ Programming Lang: Emacs lisp Description : RFC2782 (SRV record) client for emacs This package is used to look up hostname and port for a service at a specific domain. There might be multiple results, and the caller is supposed to attempt to connect to each hostname+port in turn. This is a dependency of recent versions of elpa-jabber (and indirectly a blocker for an RC bug fix). It will be managed by the Emacs Addons team. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmMV/40ACgkQA0U5G1Wq FSHuVxAAr/u1BTMh9LNrqYnoEY3vdnxNGRWhtX90BXtXYEGYSpEsrFYis/L4SGqN FCGDTj/wd7ItRgfAEVJliuX/DfbNrBgLDjbV12JBbQeERK4jKfa2HpjQ3Q0XntLK z6FwOnRuux9Ue17AT/k+WsgIzmd47WSCDfFCBWofO8JVOvZmM07W4ynr8vHlrOkC LUNcMuKma8gNdSYw90oxWrJPpQFIsN6O/A1CKmrXyD/TmdbxsC45Rou1w1TnjHck GrqQf7I0DCClhEmp/6XH6aWEFqdYAL5OFX8XUxEY0sXf6OGY0IOr4VkiOa6JWsvb iPdb75Bz/XIP6KkeLg0nNXOnXiW3Qwm9Sa2ex9kwBYtpF1ZSw/+WEPnQb1xq9bYs xI5gRpjx3VSOXkKAMiulzDM4Q6KbJTbu1kxbk++6O15R9cNzuUwk/U0GsMRnYJWh f8jW4L4APbmmf5hDmW4yCFlXdxxhCUe2Nv2XvfgLjfdDxFpb+4aIi2GWqDEvdWRO tKeI4aznKQnejYlpy1YIuU3oH1QG4RRspF/HpuGc0gH1qtRmrN7RQy+z6OeWZQFS ROQyPTSiy3dBlSNHKiFu/fk+0MRbSQPK9w+gLwz76o+f874V1M8vlIrf47PsXGeU eb87I27dgDw1w3S3f+kDIQDgjfqm2MsUdWyi65ki30h+QvLS0AE= =FQbh -END PGP SIGNATURE-
Bug#1019209: ITP: node-gulp-tap -- Easily tap into a gulp pipeline
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-gulp-tap Version : 2.0.0 Upstream Author : Mario Gutierrez * URL : https://github.com/geejs/gulp-tap * License : Expat Programming Lang: JavaScript Description : Easily tap into a gulp pipeline Some filters like gulp-coffee process all files. What if you want to process all JS and Coffee files in a single pipeline? Use tap to filter out .coffee files and process them through the coffee filter and let JavaScript files pass through. . If you do not return a stream, tap forwards your changes. . Node.js is an event-based server-side JavaScript engine. node-gulp-tap is a dependency for packaging node-gulp-sass (ITP #884844); I plan to maintain this package as a part of the Debian JavaScript Maintainers Team. signature.asc Description: This is a digitally signed message part
Intel CET Support?
Hello, i just stumbled upon the fact that debian doesn't yet make use of the Intel CET security feature, while many other distributions (Ubuntu, Fedora, Suse, Arch Linux) do. The idea is to insert endbr instructions, (which are just NOPs on older CPUs) at the beginning of functions to identify valid call targets to mitigate ROP attacks. You can do a quick test with objdump -d /usr/bin/mv | grep endbr | wc -l which outputs a nonzero number if the feature is used. See for example this Phoronix article: https://www.phoronix.com/news/Intel-CET-IBT-For-Linux-5.18 What is the reason debian doesn't use this? It seems like a sensible thing to do for me, but maybe you had a discussion about it and came to another conclusion? Or was this just overlooked? Looking forward to your answers. Regards, Felix Potthast
Re: Intel CET Support?
On 2022-09-05 22:44:52 +0200 (+0200), Felix Potthast wrote: > i just stumbled upon the fact that debian doesn't yet make use of > the Intel CET security feature, while many other distributions > (Ubuntu, Fedora, Suse, Arch Linux) do. [...] Forgive me if this is a dumb question, but were you running on a Linux 5.18 kernel when you tested this? The default kernel on the current Debian release is too old to support it, but there is a 5.18 kernel in the bullseye-backports suite. This is from my workstation running a relatively up to date Debian unstable booted on a 5.18.x kernel, as you can see: fungi@dhole:~$ uname -v #1 SMP PREEMPT_DYNAMIC Debian 5.18.14-1 (2022-07-23) fungi@dhole:~$ objdump -d /bin/mv | grep endbr | wc -l 2 fungi@dhole:~$ objdump -d /bin/mv | grep endbr 4230: f3 0f 1e fa endbr64 4270: f3 0f 1e fa endbr64 -- Jeremy Stanley signature.asc Description: PGP signature
Bug#1019237: ITP: thelounge -- Modern, responsive, cross-platform, self-hosted web IRC client
Package: wnpp Severity: wishlist Owner: Bo YU X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: thelounge Version : v4.3.1 - 2022-04-11 Upstream Author : Max Leiter * URL : https://github.com/thelounge/thelounge * License : MIT Programming Lang: TypeScript, Vue Description : Modern, responsive, cross-platform, self-hosted web IRC client Modern features brought to IRC. Push notifications, link previews, new message markers, and more bring IRC to the 21st century. Always connected. Remains connected to IRC servers while you are offline. Cross platform. It doesn't matter what OS you use, it just works wherever Node.js runs. Responsive interface. The client works smoothly on every desktop, smartphone and tablet. Synchronized experience. Always resume where you left off no matter what device. To learn more about configuration, usage and features of The Lounge, take a look at the website. The Lounge is the official and community-managed fork of Shout, by Mattias Erming. -- Regards, -- Bo YU signature.asc Description: PGP signature
Re: Automatic trimming of changelogs in binary packages
On 18/08/22 21:18, Gioele Barabucci wrote: Does anybody have objective objections against activating automatic changelog trimming in binary packages? Hi, a couple of weeks since the initial email (thanks everybody for the input), my reading is that there is now consensus in going ahead with the proposed automatic trimming of changelogs. ## Addressed contrary objections In particular, I understand that all contrary objections that were raised have been satisfyingly addressed: * Packages not meant to be included in Debian (and without access to a changelog server): Creators that want to preserve the full history can use the `--no-trim` option to disable the trimming. * Third-party repositories: Their administrators can provide access to the full changelogs by setting `Changelogs:` in the `Release` file, or can use `--no-trim` in the packages that they distribute. * Users should be made aware that changelogs have been trimmed: `dh_installchangelogs` has been modified to add a comment at the end of the trimmed changelogs. * Source packages should retain full changelogs: This is, in fact, already the case: only the changelogs included in the binary packages are trimmed. * Reproducible output: Once trimming will be enabled in `dh_installchangelogs`, either the changelogs will be trimmed (default) or not (due to the explicit use of `--no-trim`). This ensures the reproducibility of packages. ## Non-blocking concerns to be addressed in the future In addition, there were concerns and ideas that were raised as non blocking and that will be discussed and addressed in the future: * Perhaps have dpkg treat changelogs as metadata: There are pros (deduplication) and cons (the need to have a new command like `dpkg --show-changelog`). * d-security has no online changelogs: Fixing this has been proposed in 2008 (https://bugs.debian.org/490848) but it did not seem to sparkle enough interest at the time (and users of d-security are unlikely to be interested in changelog entries older than old-old-stable). * apt changelog could be instructed to choose between the local and the remote changelogs, perhaps via options like `Changelogs::PreferOnline` (to complement `AlwaysOnline`) and `--full`. * Maybe the URLs used by the tracker to link to the changelogs and the URLs used by apt to fetch the changelogs could be aligned. Regards, -- Gioele Barabucci
