What to do with merged /usr and dpkg-fsys-usrunmess
Hi, I saw warning and it advised me to use dpkg-fsys-usrunmess: But now I see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008486 And even without that there are problems with that tool: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991218 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991192 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008316 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008478 Now what I'm supposed to do? Wait for dpkg-fsys-usrunmess-unmess? Is my system broken because I have used dpkg-fsys-usrunmess(that dpkg advised me to do?). As a Debian user I'm confused and a bit angry. What is way forward? Thanks Krzysztof Sobiecki
Re: What to do with merged /usr and dpkg-fsys-usrunmess
On Wed, Apr 06, 2022 at 12:03:55PM +0200, Krzysztof Sobiecki wrote: > Hi, > I saw warning and it advised me to use dpkg-fsys-usrunmess: > But now I see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008486 > And even without that there are problems with that tool: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991218 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991192 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008316 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008478 > > Now what I'm supposed to do? Wait for dpkg-fsys-usrunmess-unmess? > Is my system broken because I have used dpkg-fsys-usrunmess(that dpkg > advised me to do?). > As a Debian user I'm confused and a bit angry. For an user: these boats are currently unstable, it's best to sit tight -- they topple only if you move around, especially when jumping between them. > What is way forward? That's the subject of a series of flamewars second in length and intensity only to the systemd debacle. You don't want to go there. The usrmerged state, while wished for by some, is currently pretty broken unless you refrain from a number of actions that are natural for packagers (inside and outside Debian) and users to do, this is considered unacceptable by the dpkg maintainer and eg. me. There is a proposal for a constructive patch set to dpkg that _may_ resolve this without nasty hacks everywhere; the patches themselves haven't been AFAIK implemented yet but there is much hope. If that fails, the drama will resume, with the big question being "WHY?". Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Eight legs good, four legs bad! -- when your drider pwns a ⣾⠁⢠⠒⠀⣿⡁ smelly goodie centaur. ⢿⡄⠘⠷⠚⠋⠀ Rearkick OP -- my grandpa's brother-in-law got one-shotted ⠈⠳⣄ from full hp in RL, please nerf!
Re: isa-support -- exit strategy?
On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
> On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote:
> > * 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.
> 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.
In this particular case, it'd probably be faster to use non-SIMD ways
instead of emulating them. This means two code paths, which particular
users may or may not want to do the effort to implement.
> 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.
This may take substantial work to implement, which for typical Debian Med
packages is an utter waste of time.
I wonder why vectorscan requires SSE4.2 while hyperscan that it's a fork of
is happy with SSE3; a personal mail server may be perfectly adequate on
hardware lacking either -- but no SSE4.2 is still realistic while no SSE3
on amd64 requires some pretty specific dumpster diving (it's lacking only
on early steppings of Athlon 64). Still, by our rules, SSE3 is not in the
arch baseline, thus it's a RC bug not to run without.
And thus, a Debian Med package is required to provide non-SSE3 builds that
are almost untestable without hard-to-get hardware, that's a pure waste of
maintainer time.
While that mail server may be fully happy with checking the patterns with
libpcre one by one. What {vector,hyper}scan are good for is matching _many_
regexes on _many_ lines of data; if there's either few patterns or little
data, the serial slow way is as good or better.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Eight legs good, four legs bad! -- when your drider pwns a
⣾⠁⢠⠒⠀⣿⡁ smelly goodie centaur.
⢿⡄⠘⠷⠚⠋⠀ Rearkick OP -- my grandpa's brother-in-law got one-shotted
⠈⠳⣄ from full hp in RL, please nerf!
Re: What to do with merged /usr and dpkg-fsys-usrunmess
On Apr 06, Krzysztof Sobiecki wrote: > Now what I'm supposed to do? Wait for dpkg-fsys-usrunmess-unmess? Install the usrmerge package and hopefully everything will be fixed. > Is my system broken because I have used dpkg-fsys-usrunmess(that dpkg > advised me to do?). Maybe. > As a Debian user I'm confused and a bit angry. And you have every right to be. Sorry, blame the dpkg maintainer. > What is way forward? Merged /usr. -- ciao, Marco signature.asc Description: PGP signature
Re: What to do with merged /usr and dpkg-fsys-usrunmess
Marco d'Itri writes: > Sorry, blame the dpkg maintainer. Is that how we discuss technical issues around here? Bjørn
Re: What to do with merged /usr and dpkg-fsys-usrunmess
On Wed, Apr 06, 2022 at 04:02:23PM +0200, Bjørn Mork wrote: > > Sorry, blame the dpkg maintainer. > > Is that how we discuss technical issues around here? This is not a technical issue. -- WBR, wRAR signature.asc Description: PGP signature
Re: What to do with merged /usr and dpkg-fsys-usrunmess
Andrey Rahmatullin writes: > On Wed, Apr 06, 2022 at 04:02:23PM +0200, Bjørn Mork wrote: >> > Sorry, blame the dpkg maintainer. >> >> Is that how we discuss technical issues around here? > This is not a technical issue. Ah, sorry. I mistook this for the "Discussion about technical development topics" list. My fault Bjørn
Re: debian-faq in NEW - or: remove documentation from the archive at all
Hi, On Sun, 2022-04-03 at 13:18 +0200, Holger Wansing wrote: > 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. Sorry it took so long. The main problem here is that BYHAND packages are separate from NEW and `dak process-new` will not look at those packages by default. The automatic processing of the "byhand" files suggested in [1] is already implemented; it just needs manual attention when the package ends in BYHAND due to introducing additional binary packages. At least I missed the earlier ping; please feel free to inquire about packages stuck in by-hand a bit more/earlier. Ansgar [1]: https://lists.debian.org/debian-devel/2022/04/msg00029.html
Bug#1009056: ITP: puppet-module-voxpupuli-unbound -- Puppet module for unbound
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: puppet-module-voxpupuli-unbound Version : 5.0.0 Upstream Author : Voxpupuli * URL : https://github.com/voxpupuli/puppet-unbound * License : Apache-2.0 Programming Lang: Puppet Description : Puppet module for unbound Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . puppet-unbound installs and configure Unbound.
Bug#1009060: ITP: odr-padenc -- This is an encoder for Programme Associated Data
Package: wnpp Severity: wishlist Owner: Robin Alexander X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: odr-padenc Version : 3.0.0 Upstream Author : Matthias P. Braendli * URL : https://github.com/Opendigitalradio/ODR-PadEnc/ * License : GPL Programming Lang: C++ Description : This is an encoder for Programme Associated Data ODR-PadEnc is an encoder for Programme Associated Data (PAD) and includes support for: . - MOT Slideshow (including catSLS), according to ETSI EN 301 234 and TS 101 499 . - DLS (including DL Plus), according to ETSI EN 300 401 and TS 102 980 . To encode DLS and Slideshow data, the odr-padenc tool reads images from a folder and DLS text from a file, and generates the PAD data for the encoder. This command belongs to the OpenDigitalRadio mmbTools which include: - odr-audioenc (audio encoder for DAB/DAB+) - odr-dabmux (DAB/DAB+ multiplex) - odr-dabmod (DAB/DAB+ modulator)
Re: What to do with merged /usr and dpkg-fsys-usrunmess
On Wed, 2022-04-06 at 03:04 -0700, Krzysztof Sobiecki wrote: > Hi, > I saw warning and it advised me to use dpkg-fsys-usrunmess: > But now I see: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008486 >From the link above: " Hi, the `dpkg-fsys-usrunmess` program should include a warning that it will convert the system into a state that will no longer be supported in the future by Debian. Ansgar " Here's hoping I don't have to reinstall soon. (Running up-to-date 'testing') -- john
Helping Ukraine with Debian
Hi! Has anyone thought about how to help out Ukraine by using Debian? Thinking about humanitarian relief and and other possibilities for communications. Is there any way I may be able to help out by remoting in? Any one got any verifiable contacts please? Thank you so much, Matt Grant
