debian-faq in NEW - or: remove documentation from the archive at all
Hi all, debian-faq is waiting in NEW queue for more than 4 months now (upload is from 23.11.2021), with no visible activity from ftp-masters (and even with no message at all!). I pinged ftp-masters at the end of January, but got no reaction at all. Again my question, if there is something wrong with this upload or this package??? There have been countless NEW processings since then, but this (in my opinion) uncritical documentation-only package is still waiting. Any comments on this? If documentation is that unimportant, we could save a long of work and time, if we remove all documentation packages from the archive and the website!!! Holger (being extremly sad about all this) Holger Wansing wrote (Sat, 29 Jan 2022 20:36:19 +0100): > [Uploader in CC] > > > Hi all, > > I would like to see the 11.0 version of debian-faq accepted to unstable. > > Are there any issues with this one? > > Being this purely a documentation-only package, I had naively thought, it's > an > easy case for going through NEW, but I might be wrong here? > > > Thanks for all your work > Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: isa-support -- exit strategy?
On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote: > Hi! Hi Adam! >... > * while a hard Depends: works for leafy packages, on a library it > disallows having alternate implementations that don't need the > library in question. Eg, libvectorscan5 blocks a program that > uses it from just checking the regexes one by one. > > Suggestions? glibc 2.33 added a modernized version of the old hwcaps. If a package builds a library several times with different optimizations and installs them into the correct directories in the binary package, the dynamic linker will automatically select the fastest one supported by the hardware. SIMDe (or similar approaches) could be used to build variant(s) of the library that have compile-time emulation of SIMD instructions in the lower baseline builds of vectorscan. People using libvectorscan5 on modern hardware with SSE 4.2 would then get the properly optimized fast version, while people on older hardware would get a version that is slow but works. 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. > Meow! cu Adrian
Re: isa-support -- exit strategy?
On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote: > SIMDe (or similar approaches) could be used to build variant(s) of the > library that have compile-time emulation of SIMD instructions in the > lower baseline builds of vectorscan. But why? Who in their right mind would ever try to use those aweful slow implementations? Bastian -- I have never understood the female capacity to avoid a direct answer to any question. -- Spock, "This Side of Paradise", stardate 3417.3
Bug#1008892: ITP: node-w3c-keyname -- Get a KeyboardEvent.key-style string from an event
Package: wnpp Severity: wishlist Owner: Michael Ikwuegbu X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-w3c-keyname Version : 2.2.4 Upstream Author : Marijn Haverbeke * URL : https://github.com/marijnh/w3c-keyname#readme * License : Expat Programming Lang: JavaScript Description: Get a KeyboardEvent.key-style string from an event. w3c-keyname is a library that exports a function keyName that takes a keyboard event and returns a KeyboardEvent.key-style string. . Node.js is an event-based server-side JavaScript engine. Praveen agreed to sponsor this package.
Re: Embedded buildpath via rpath using cmake
On 2022-02-03, Vagrant Cascadian wrote: > Over the last several months, I and others have found quite a few > packages that embed build paths via rpath when building with cmake. I > found myself slowly edging into a mass bug filing, one bug report at a > time... > > I ended up submitting a few patches and noting some affected packages: > > > https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html > > There are almost certainly packages missing from that list, as it is > generated by human confirmation... So in the last couple months I kept finding more packages affected by this; the above URL now has confirmed 380+ packages affected by this issue, a few of which are are now fixed, thanks! On those I've tested and confirmed, I've either submitted a patch and/or mentioned in comments for the package in the reproducible builds notes, which you can see by clicking on the referenced package in the above URL, or searching for the relevent package in: https://salsa.debian.org/reproducible-builds/reproducible-notes/-/blob/master/packages.yml I don't know for sure that this is a comprehensive list of affected packages; I've mostly identified packages that fail to build with build path variations and had otherwise no known cause, or used other identified issues that apparently had a direct correlation to this issue. Doing a systematic search for all packages that use cmake to build and fail to build reproducibly in unstable or experimental would probably be the next step to identify any remaining packages... > In many cases I've tested so far, passing an argument via a > dh_auto_configure override in debian/rules fixes the issue: > >override_dh_auto_configure: >dh_auto_configure -- -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON > > > Alternately, the experimental debhelper compat level v14 does include a > fix for these embedded rpaths, though in the current state, passing both > -DCMAKE_SKIP_RPATH=ON and -DCMAKE_RPATH_USE_ORIGIN=ON, it triggers build > failures 263 packages, according to a test run by Lucas Nussbaum in > October: > > http://qa-logs.debian.net/2021/10/25/diff.dcsr.txt > > > Since debhelper v14 is not finalized yet, I just sent a request to > debhelper to only pass one of the arguments, > -DCMAKE_RPATH_USE_ORIGIN=ON, which should significantly reduce the > number of build failures while still making many packages reproducible > with debhelper compat v14: > > https://bugs.debian.org/1004939 Haven't gotten any comment on this from the debhelper maintainers yet... There are a few where -DCMAKE_RPATH_USE_ORIGIN=ON does trigger test failures or otherwise causes build failures (some had test suite failures without changes), but my off the cuff guess is ~2% of the ~380 noted packges; less than I could count on both hands using very simple methods. This should be significantly less that -DCMAKE_SKIP_RPATH=ON... It seems like it is not possible to actually create something like a lintian warning for this, as the actual build path is stripped out before creating the .deb package; the only result is for the most part a different build id and a few small changes in the binaries. Would, of course, be happy to be proven wrong! I've added a new list of affected maintainers produced with dd-list with the packages marked with the "cmake_rpath_contains_build_path" issue that haven't yet been fixed in some way according to tests.reproducible-builds.org. Thanks everyone! live well, vagrant "Adam C. Powell, IV" oce (U) A. Maitland Bottoms airspyone-host codec2 gr-fosphor gr-funcube (U) gr-hpsdr (U) gr-iqbal gr-osmosdr gr-radar gr-rds hackrf libfreesrp rtl-sdr volk Adam Borowski pmdk-convert pmemkv Adrian Knoth libdrumstick (U) Alastair McKinstry ecflow mathgl (U) Alberto Garcia cog Alberto Luaces Fernández openscenegraph Alessio Treglia fluidsynth (U) libdrumstick (U) Alf Gaida libqtxdg (U) lxqt-config (U) lxqt-globalkeys (U) nomacs (U) screengrab (U) Andrea Capriotti userbindmount (U) vdeplug4 (U) Andreas Bombe soapyosmo (U) soapysdr (U) Andreas Cord-Landwehr kdevelop-python (U) Andreas Metzler hugin (U) libpano13 (U) Andreas Rönnquist allegro5 (U) Andreas Tille bamtools (U) civetweb (U) libminc (U) openmm (U) prime-phylo (U) spoa (U) Andrew Lee (李健秋) libqtxdg (U) lxqt-config (U) lxqt-globalkeys (U) nomacs (U) screengrab (U) Andrey Rahmatullin librsync Andrius Merkys libemf2svg (U) macromoleculebuilder (U) openmm (U) Antoine Beaupré slop Anton Gladky libopenshot (U) liggghts (U) metis (U) tetgen (U) Antonio Ospite libam7xxx Apollon Oikonomopoulos leatherman (U) APT Development Team apt Arne Bernin libfreenect (U) Arne Morten Kvarving opm-simulators (U) Arnout Engelen libdrumstick (U) Aron Xu fcitx-qt5
Re: debian-faq in NEW - or: remove documentation from the archive at all
Hi, On Sun, Apr 03, 2022 at 01:18:37PM +0200, Holger Wansing wrote: Hi all, debian-faq is waiting in NEW queue for more than 4 months now (upload is from 23.11.2021), with no visible activity from ftp-masters (and even with no message at all!). I pinged ftp-masters at the end of January, but got no reaction at all. If the mail list does not reply you, I think you can try it in IRC #debian-ftp from oftc. BR, Bo Again my question, if there is something wrong with this upload or this package??? There have been countless NEW processings since then, but this (in my opinion) uncritical documentation-only package is still waiting. Any comments on this? If documentation is that unimportant, we could save a long of work and time, if we remove all documentation packages from the archive and the website!!! Holger (being extremly sad about all this) Holger Wansing wrote (Sat, 29 Jan 2022 20:36:19 +0100): [Uploader in CC] Hi all, I would like to see the 11.0 version of debian-faq accepted to unstable. Are there any issues with this one? Being this purely a documentation-only package, I had naively thought, it's an easy case for going through NEW, but I might be wrong here? Thanks for all your work Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
