Hi,
Sorry for the symlink breakage.
On Mon, Feb 14, 2022 at 6:54 PM Michael Biebl wrote:
> While speaking of getting rid off unnecessary complexity: Is the
> separate udeb build still needed?
This is what I sometimes decide to evaluate, but then time goes on
something else. :(
Now I'm going to
Am 14.02.22 um 18:51 schrieb Michael Biebl:
I agree.
Apparently this isn't the first time that dmraid has been bitten by this
split-usr issue (and having to manually fiddle with the creation of the
.so symlink) [1]
Getting rid of this unnecessary complexity would solve this once and for
Am 14.02.22 um 17:55 schrieb Helmut Grohne:
We have this moratorium in place that says you should not move files
from / to /usr, because it could go bad when moving files.
ttbomk, those "bad" things only happen if you move files from /lib to
/usr (under the same name) but *also* move it
Control: tags -1 + patch
Hi Michael,
On Sun, Feb 13, 2022 at 02:20:26PM +0100, Michael Biebl wrote:
> I suspect the following:
>
> in 1.0.0.rc16-10 /usr/lib/libdmraid.so is a dangling symlink to
> /lib/libdmraid.so.1.0.0.rc16 (yay for those pointless split-usr shenanigans,
> can we please have
I suspect the following:
in 1.0.0.rc16-10 /usr/lib/libdmraid.so is a dangling symlink to
/lib/libdmraid.so.1.0.0.rc16 (yay for those pointless split-usr
shenanigans, can we please have merged-usr like yesterday) and as a
result the compiler/linker falls back to link
Looking at those symbols, they all appear to come from libdmraid and
this appears to be an issue caused by dmraid (1.0.0.rc16-10)
Building in a sid chroot with libdmraid-dev_1.0.0.rc16-9_amd64.deb and
libdmraid1.0.0.rc16_1.0.0.rc16-9_amd64.deb makes the build succeed.
So I suspect this breakage
Control: reassign -1 libdmraid-dev
Control: found -1 1.0.0.rc16-10
Control: affects src:libblockdev
Reassigning accordingly.
Am 13.02.22 um 14:11 schrieb Michael Biebl:
Looking at those symbols, they all appear to come from libdmraid and
this appears to be an issue caused by dmraid
7 matches
Mail list logo