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
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
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
7 matches
Mail list logo
