Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Niels Thykier]

clone 886968 -1
retitle -1 debhelper: Make -V the default for dh_makeshlibs
severity -1 wishlist
tags -1 patch
thanks

Emilio Pozuelo Monfort:
> [...]
> 
> It's not in policy (but I don't think it has to be), but following the
> conversation on #-ftp yesterday I opened:
> 
> #895949 lintian: warn about packages with udebs but no udeb line in shlibs
> #895953 lintian: check that shlibs-version >= higher-version-symbols-file
> 
> The latter wouldn't enforce -V, but would check that we at least get a high
> enough version in shlibs as compared to the .symbols file (and would have 
> solved
> the zstd problem).
> 
> Cheers,
> Emilio
> 

Related to this thread, I am wondering whether the default for
dh_makeshlibs should be changed in compat 12.  I have cloned #886968
(with this mail) and people with an interest are welcome to follow up on
that clone.

I have written a branch at [1] (review welcome).

Thanks,
~Niels

[1]:
https://salsa.debian.org/debian/debhelper/tree/dh-makeshlibs-c12-default-shlibs-versioning

Processed: Re: Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> clone 886968 -1
Bug #886968 [btrfs-progs-udeb] btrfs-progs-udeb: depends on non-udeb: libzstd1
Bug 886968 cloned as bug 896464
> retitle -1 debhelper: Make -V the default for dh_makeshlibs
Bug #896464 [btrfs-progs-udeb] btrfs-progs-udeb: depends on non-udeb: libzstd1
Changed Bug title to 'debhelper: Make -V the default for dh_makeshlibs' from 
'btrfs-progs-udeb: depends on non-udeb: libzstd1'.
> severity -1 wishlist
Bug #896464 [btrfs-progs-udeb] debhelper: Make -V the default for dh_makeshlibs
Severity set to 'wishlist' from 'grave'
> tags -1 patch
Bug #896464 [btrfs-progs-udeb] debhelper: Make -V the default for dh_makeshlibs
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
886968: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886968
896464: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896464
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Cyril Brulebois]

Hello,

Dimitri John Ledkov  (2018-04-20):
> From my point of view, this is confusing... cause I regard myself as
> being part of the installer team myself.
> 
> I guess you are advocating for general code review, more than two
> pairs of eyes on things?

There were no mails on debian-boot@, so that addition wasn't announced
nor coordinated.

> > I'm not sure why stashing a -V there once and for all to be
> > future-proof wouldn't be adequate or desireable. People can argue
> > all they like about whether the package is RC buggy in this specific
> > revision, but it seems rather pointless, I really do care about
> > mid/long-term maintenance. I have enough on my plate to not want to
> > monitor such packages closely, and open a specific bug report in
> > their next revision…
> 
> In absolute terms, it simply isn't, for debs. And only marginally
> better for udebs.

If that wasn't clear from the context: I'm interested in udebs
specifically, and while I'm going to have to disagree with “marginally
better”, that would still be a net win when the cost is zero.

> The pain is specifically with pulling udeb builds of packages that
> were done against newer glibc (e.g. in sid) into d-i that is based on
> stable/testing. Whilst the builds of those packages do not require
> newer glibc, they gain an artificially high dependency on glibc from
> sid.

That looks like d-i 101: having a consistent set of packages within a
given suite is the best way to avoid issues.

> > Are you volunteering to introduce separate symbols support for udebs
> > to all the required components and to maintain it over time?
> 
> I see that there might be a mapping issue between deb library names
> and udeb library names. And i'm hoping a simple extension of the
> .symbols file syntax should make it all work fine.

It seems like not liking -V (again, only used by udebs when symbols
files are present for debs) doesn't look like a good reason to get more
complexity in the symbols handling…

The upload we're talking about (that I only quickly glanced at) actually
bumped the version of all symbols to the last version, meaning it
actually mimicked having passed the horrendous -V flag! I'm not sure how
a symbols syntax extension would have helped get the basics straight…

> > I'm not sure what the issue is with talking to the debian installer
> > team when you're touching udeb packages and trusting their
> > assessment?
> 
> The issue being, is that I regard myself as being part of the debian
> installer team. I am delusional?
> Unless what you are in fact saying is actually "talk to Kibi".

As I think I've mentioned already, the bare minimum is mailing
debian-boot@, which didn't happen. And yes, bonus points if I'm in cc
(that's really appreciated); people would usually loop me in if I'm late
to the party (which happens after the fact when people mentioned the
package was sitting in NEW); and if I miss mails on debian-boot@ because
I'm lagging behind, fault's on me.

> -V a must for udebs would be bad, as that will never generate correct
> dependencies. It at best can only set an inflated minimum version,
> without a correct upper bound.

I'm not sure what the problem with that is.

Yes, sometimes udebs need to wait for other packages to migrate
together because of that “inflated” version. But usually I'm the one
reviewing those issues and adding age-days/urgent hints as needed on the
release team side, when a bunch of packages are wanted in the next d-i
release.

> symbols support should be there for udebs

But it's not.

> and -V should just die.

It's served us (or at least me) for many years, so I'll keep on relying
on it, sorry if that's so irritating.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Dimitri John Ledkov]

On 18 April 2018 at 08:18, Emilio Pozuelo Monfort  wrote:
> On 18/04/18 01:30, Cyril Brulebois wrote:
>> That's another perfect example why udeb additions should get reviewed:
>> we would have noticed another buggy package, and its bugginess might not
>> have been copied over to another package.
>
> I'm sure people don't request those reviews because they don't know or because
> they forget. A lintian warning could help, or ftp-masters enforcing an ack.
> Though I'd prefer the former as I wouldn't like NEW to have another 
> bottleneck.
>
>> If someone wants to drive an effort to make -V a must for udebs in
>> policy, that's probably fine. It doesn't strike me as ultimately needed
>> (we've lived without it for quite some time because maintainers tend to
>> just do the right thing), but if people have spare time, go for it.
>
> It's not in policy (but I don't think it has to be), but following the
> conversation on #-ftp yesterday I opened:
>
> #895949 lintian: warn about packages with udebs but no udeb line in shlibs
> #895953 lintian: check that shlibs-version >= higher-version-symbols-file
>
> The latter wouldn't enforce -V, but would check that we at least get a high
> enough version in shlibs as compared to the .symbols file (and would have 
> solved
> the zstd problem).

I like these bugs, and the patch to the latter one.


-- 
Regards,

Dimitri.

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Dimitri John Ledkov]

On 18 April 2018 at 00:30, Cyril Brulebois  wrote:
> Hi,
>
> Dimitri John Ledkov  (2018-04-17):
>> First, I apologize for not responding to this email earlier, as I have
>> missed it in my mailbox.
>
> It's a mail from hours ago, so there's no apology needed.
>
>> Secondly, my work has been blocked by this NEW processing too for
>> btrfs-progs. I'm not aware as to which Helmut's work was blocked,
>> could you please elaborate what Helmut is blocked on? And/or how can
>> libzstd/me help to unblock Helmut? -> is that about patches for
>> crossbuilding that are part of
>
> [sentenced cut in the middle but] Yes, Helmut works quite a lot on
> crossbuilding and commits sitting in git master looked like what he was
> alluding to.
>
>> Now to respond to your main inquiry. I find the tone of above message
>> unacceptable. It reads accusational to me, rather than inquisitive.
>>
>> It would have been much better to state:
>> "I notice that a call to dh_makeshlibs does not pass the -V flag as it
>> is custom for many libraries. Why have you not specified a minimum
>> required version in this case?"
>
> I suppose that's a fair way to word it. But I did mean to point out that
> packages having an impact on the installer should be reviewed by the
> installer team, at least for their initial addition; as I tried to make
> people aware a few times already (dda@, talks, replies to threads where
> udeb additions were mentioned, etc.); since that simple and natural
> process wasn't followed here, I did point that out.
>

>From my point of view, this is confusing... cause I regard myself as
being part of the installer team myself.

I guess you are advocating for general code review, more than two
pairs of eyes on things?

>> It also feels like you (or others who were made aware of this lack of
>> -V) possibly wanted to make this a bug report, and follow-on out of
>> band events made it seem like it was felt that it is RC buggy and
>> shouldn't clear NEW and/or migrate to testing if passed NEW. In that
>> case  a new bug report should have been opened, with above request at
>> an RC priority.
>
> I didn't comment on the fact it should get accepted or rejected from
> NEW. People pointed me to the udeb addition that probably get some input
> from me, so I've briefly looked at it and spotted that issue.
>

Ok, fair enough.

I am still confused under what authority, assessment or criticality
previous upload was rejected by ftp-master. I shall pursue this with
them further.

@waldi - have you recently become an FTP-Master and I have missed the
announcement?

E.g. even if shlibs were completely wrong, it is not something we are
unable to fix with regular follow-up uploads.

>> However, it is good to point out at this time, that udeb version of
>> libraries do not currently ship or use symbols files at all to
>> generate dependencies.
>> But also note that since libzstd1-udeb is a brand new package, any
>> version of thereof would correctly and strictly satisfy any udeb
>> package that gains a dependency on it. There are no linking or
>> dependency bugs in above libzstd1, nor udeb edition of the binary
>> packages.
>
> I'm not sure why stashing a -V there once and for all to be future-proof
> wouldn't be adequate or desireable. People can argue all they like about
> whether the package is RC buggy in this specific revision, but it seems
> rather pointless, I really do care about mid/long-term maintenance. I
> have enough on my plate to not want to monitor such packages closely,
> and open a specific bug report in their next revision…
>

In absolute terms, it simply isn't, for debs. And only marginally
better for udebs.

>> This is no different to some other library udebs, e.g. liblzo2-2-udeb
>
> That's another perfect example why udeb additions should get reviewed:
> we would have noticed another buggy package, and its bugginess might not
> have been copied over to another package.
>
>> Personally, I find it odd to have minimum -V arg version dependencies
>> for udebs only, when symbols are present for the deb edition of the
>> library. For example, btrfs-progs depends on libc6 (>= 2.8), yet
>> btrfs-progs-udeb depends on libc6-udeb (>= 2.27). This causes an
>> immense amount of pain, when rebuilding packages locally, mixing &
>> matching packages when debugging issues in d-i, and does not at all
>> correctly generate private dependencies for udebs that use e.g.
>> @GLIBC_PRIVATE and thus require libc6-udeb (>> 2.27), libc6-udeb (<<
>> 2.28) style dependency instead. I'm not sure where/how .symbols should
>> be used or shipped, to start generate genuinely correct version
>> dependencies for udebs across the board. Debhelper? Dpkg?
>
> I have done my share part of performing local builds and various
> combinations of udebs, and I never experienced this “immense amount of
> pain”.
>

The pain is specifically with pulling udeb builds of packages that
were done against newer glibc (e.g. in sid) into d-i that is based on
stable/testing. W

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Emilio Pozuelo Monfort]

On 18/04/18 01:30, Cyril Brulebois wrote:
> That's another perfect example why udeb additions should get reviewed:
> we would have noticed another buggy package, and its bugginess might not
> have been copied over to another package.

I'm sure people don't request those reviews because they don't know or because
they forget. A lintian warning could help, or ftp-masters enforcing an ack.
Though I'd prefer the former as I wouldn't like NEW to have another bottleneck.

> If someone wants to drive an effort to make -V a must for udebs in
> policy, that's probably fine. It doesn't strike me as ultimately needed
> (we've lived without it for quite some time because maintainers tend to
> just do the right thing), but if people have spare time, go for it.

It's not in policy (but I don't think it has to be), but following the
conversation on #-ftp yesterday I opened:

#895949 lintian: warn about packages with udebs but no udeb line in shlibs
#895953 lintian: check that shlibs-version >= higher-version-symbols-file

The latter wouldn't enforce -V, but would check that we at least get a high
enough version in shlibs as compared to the .symbols file (and would have solved
the zstd problem).

Cheers,
Emilio

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Cyril Brulebois]

Hi,

Dimitri John Ledkov  (2018-04-17):
> First, I apologize for not responding to this email earlier, as I have
> missed it in my mailbox.

It's a mail from hours ago, so there's no apology needed.

> Secondly, my work has been blocked by this NEW processing too for
> btrfs-progs. I'm not aware as to which Helmut's work was blocked,
> could you please elaborate what Helmut is blocked on? And/or how can
> libzstd/me help to unblock Helmut? -> is that about patches for
> crossbuilding that are part of

[sentenced cut in the middle but] Yes, Helmut works quite a lot on
crossbuilding and commits sitting in git master looked like what he was
alluding to.

> Now to respond to your main inquiry. I find the tone of above message
> unacceptable. It reads accusational to me, rather than inquisitive.
> 
> It would have been much better to state:
> "I notice that a call to dh_makeshlibs does not pass the -V flag as it
> is custom for many libraries. Why have you not specified a minimum
> required version in this case?"

I suppose that's a fair way to word it. But I did mean to point out that
packages having an impact on the installer should be reviewed by the
installer team, at least for their initial addition; as I tried to make
people aware a few times already (dda@, talks, replies to threads where
udeb additions were mentioned, etc.); since that simple and natural
process wasn't followed here, I did point that out.

> It also feels like you (or others who were made aware of this lack of
> -V) possibly wanted to make this a bug report, and follow-on out of
> band events made it seem like it was felt that it is RC buggy and
> shouldn't clear NEW and/or migrate to testing if passed NEW. In that
> case  a new bug report should have been opened, with above request at
> an RC priority.

I didn't comment on the fact it should get accepted or rejected from
NEW. People pointed me to the udeb addition that probably get some input
from me, so I've briefly looked at it and spotted that issue.

> However, it is good to point out at this time, that udeb version of
> libraries do not currently ship or use symbols files at all to
> generate dependencies.
> But also note that since libzstd1-udeb is a brand new package, any
> version of thereof would correctly and strictly satisfy any udeb
> package that gains a dependency on it. There are no linking or
> dependency bugs in above libzstd1, nor udeb edition of the binary
> packages.

I'm not sure why stashing a -V there once and for all to be future-proof
wouldn't be adequate or desireable. People can argue all they like about
whether the package is RC buggy in this specific revision, but it seems
rather pointless, I really do care about mid/long-term maintenance. I
have enough on my plate to not want to monitor such packages closely,
and open a specific bug report in their next revision…

> This is no different to some other library udebs, e.g. liblzo2-2-udeb

That's another perfect example why udeb additions should get reviewed:
we would have noticed another buggy package, and its bugginess might not
have been copied over to another package.

> Personally, I find it odd to have minimum -V arg version dependencies
> for udebs only, when symbols are present for the deb edition of the
> library. For example, btrfs-progs depends on libc6 (>= 2.8), yet
> btrfs-progs-udeb depends on libc6-udeb (>= 2.27). This causes an
> immense amount of pain, when rebuilding packages locally, mixing &
> matching packages when debugging issues in d-i, and does not at all
> correctly generate private dependencies for udebs that use e.g.
> @GLIBC_PRIVATE and thus require libc6-udeb (>> 2.27), libc6-udeb (<<
> 2.28) style dependency instead. I'm not sure where/how .symbols should
> be used or shipped, to start generate genuinely correct version
> dependencies for udebs across the board. Debhelper? Dpkg?

I have done my share part of performing local builds and various
combinations of udebs, and I never experienced this “immense amount of
pain”.

Are you volunteering to introduce separate symbols support for udebs to
all the required components and to maintain it over time?

> Based on all of the above, I believe libzstd1, and libzstd1-udeb are
> both policy complaint as previously uploaded.

I like the typo.

> If you are still concerned about minimum version dependencies which
> are generated by packages that build/link/gain dependency on libzstd1
> and/or libzstd1-udeb, I welcome you, ftp masters, or anybody else to
> open a new (or clone this) bug report against libzstd for
> consideration. I also welcome references from the Debian Policy to
> educate myself further about library dependencies, and if and how,
> this package is not policy complaint and pointers on how to best fix
> it.

I'm not sure what the issue is with talking to the debian installer team
when you're touching udeb packages and trusting their assessment?

If someone wants to drive an effort to make -V a must for udebs in
policy, that'

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Dimitri John Ledkov]

On 17 April 2018 at 19:01, Cyril Brulebois  wrote:
> Dimitri John Ledkov  (2018-01-15):
>> On 15 January 2018 at 00:27, Cyril Brulebois  wrote:
>> > Hi,
>> >
>> > Cyril Brulebois  (2018-01-12):
>> >> Your package is no longer installable (along with its rev-dep
>> >> partman-btrfs) because it now depends on libzstd1, which isn't
>> >> a udeb.
>> >
>> > It seems zstd is only an option for btrfs-progs, and I've just confirmed
>> > that setting --disable-zstd on the dh_auto_configure line lets btrfs-progs
>> > build just fine, without the libzstd1 dependency. As far as I can tell,
>> > there's no absolute need for this feature in d-i, and we could consider
>> > building the udeb without zstd support, instead of requesting the addition
>> > of a libzstd1-udeb. What do you think?
>> >
>>
>> That's an oversight on my part. From the recovery point of view, it
>> would be desired to have zstd compression support built-into
>> btrfs-progs-udeb such that one can use d-i recovery mode to
>> backup/restore btrfs filesystems with zstd compression.
>
> Your unreviewed addition of udeb as seen in NEW (currently holding back
> Helmut's work as noticed on #debian-ftp) is broken. It's missing a
> version.
>
> Repeating the same request and piece of advice (since 2012 or so):
> please get udeb-related things reviewed by debian-boot@/me?
>
> Thanks already.

First, I apologize for not responding to this email earlier, as I have
missed it in my mailbox.

Secondly, my work has been blocked by this NEW processing too for
btrfs-progs. I'm not aware as to which Helmut's work was blocked,
could you please elaborate what Helmut is blocked on? And/or how can
libzstd/me help to unblock Helmut? -> is that about patches for
crossbuilding that are part of

Now to respond to your main inquiry. I find the tone of above message
unacceptable. It reads accusational to me, rather than inquisitive.

It would have been much better to state:
"I notice that a call to dh_makeshlibs does not pass the -V flag as it
is custom for many libraries. Why have you not specified a minimum
required version in this case?"

It also feels like you (or others who were made aware of this lack of
-V) possibly wanted to make this a bug report, and follow-on out of
band events made it seem like it was felt that it is RC buggy and
shouldn't clear NEW and/or migrate to testing if passed NEW. In that
case  a new bug report should have been opened, with above request at
an RC priority.

I hope above is an adequate description, of the technical question you
are alluding to.

The proposed update that got rejected from NEW had
```
override_dh_makeshlibs:
dh_makeshlibs -plibzstd1 --add-udeb=libzstd1-udeb
```
(I hope this is enough context from said upload, for more details see
tree at 
https://salsa.debian.org/med-team/libzstd/tree/50c4849ef0ea5d79d7d5f84fd0a46b6404a413eb)

Note, that libzstd1 provides a symbols file, therefore packages that
link against it, normally get the correct minimum version dependency
based on the symbols file.
Therefore lack of -V flag is irrelevant for the actual dependencies
generated on packages that link/depend on libzstd1.

However, it is good to point out at this time, that udeb version of
libraries do not currently ship or use symbols files at all to
generate dependencies.
But also note that since libzstd1-udeb is a brand new package, any
version of thereof would correctly and strictly satisfy any udeb
package that gains a dependency on it. There are no linking or
dependency bugs in above libzstd1, nor udeb edition of the binary
packages.

This is no different to some other library udebs, e.g. liblzo2-2-udeb

Personally, I find it odd to have minimum -V arg version dependencies
for udebs only, when symbols are present for the deb edition of the
library. For example, btrfs-progs depends on libc6 (>= 2.8), yet
btrfs-progs-udeb depends on libc6-udeb (>= 2.27). This causes an
immense amount of pain, when rebuilding packages locally, mixing &
matching packages when debugging issues in d-i, and does not at all
correctly generate private dependencies for udebs that use e.g.
@GLIBC_PRIVATE and thus require libc6-udeb (>> 2.27), libc6-udeb (<<
2.28) style dependency instead. I'm not sure where/how .symbols should
be used or shipped, to start generate genuinely correct version
dependencies for udebs across the board. Debhelper? Dpkg?

Based on all of the above, I believe libzstd1, and libzstd1-udeb are
both policy complaint as previously uploaded.

If you are still concerned about minimum version dependencies which
are generated by packages that build/link/gain dependency on libzstd1
and/or libzstd1-udeb, I welcome you, ftp masters, or anybody else to
open a new (or clone this) bug report against libzstd for
consideration. I also welcome references from the Debian Policy to
educate myself further about library dependencies, and if and how,
this package is not policy complaint and pointers on how to best fix
it.

-- 
Regards,

Dimitri.

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Cyril Brulebois]

Dimitri John Ledkov  (2018-01-15):
> On 15 January 2018 at 00:27, Cyril Brulebois  wrote:
> > Hi,
> >
> > Cyril Brulebois  (2018-01-12):
> >> Your package is no longer installable (along with its rev-dep
> >> partman-btrfs) because it now depends on libzstd1, which isn't
> >> a udeb.
> >
> > It seems zstd is only an option for btrfs-progs, and I've just confirmed
> > that setting --disable-zstd on the dh_auto_configure line lets btrfs-progs
> > build just fine, without the libzstd1 dependency. As far as I can tell,
> > there's no absolute need for this feature in d-i, and we could consider
> > building the udeb without zstd support, instead of requesting the addition
> > of a libzstd1-udeb. What do you think?
> >
> 
> That's an oversight on my part. From the recovery point of view, it
> would be desired to have zstd compression support built-into
> btrfs-progs-udeb such that one can use d-i recovery mode to
> backup/restore btrfs filesystems with zstd compression.

Your unreviewed addition of udeb as seen in NEW (currently holding back
Helmut's work as noticed on #debian-ftp) is broken. It's missing a
version.

Repeating the same request and piece of advice (since 2012 or so):
please get udeb-related things reviewed by debian-boot@/me?

Thanks already.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Nicholas D Steeves]

On Mon, Jan 15, 2018 at 02:20:28PM +, Dimitri John Ledkov wrote:
> On 15 January 2018 at 00:27, Cyril Brulebois  wrote:
> > Hi,
> >
> > Cyril Brulebois  (2018-01-12):
> >> Your package is no longer installable (along with its rev-dep
> >> partman-btrfs) because it now depends on libzstd1, which isn't
> >> a udeb.
> >
> > It seems zstd is only an option for btrfs-progs, and I've just confirmed
> > that setting --disable-zstd on the dh_auto_configure line lets btrfs-progs
> > build just fine, without the libzstd1 dependency. As far as I can tell,
> > there's no absolute need for this feature in d-i, and we could consider
> > building the udeb without zstd support, instead of requesting the addition
> > of a libzstd1-udeb. What do you think?
> >
> 
> That's an oversight on my part. From the recovery point of view, it
> would be desired to have zstd compression support built-into
> btrfs-progs-udeb such that one can use d-i recovery mode to
> backup/restore btrfs filesystems with zstd compression.
> 
> -- 
> Regards,
> 
> Dimitri.

Hi Cyril! 

I agree that it's not essential for d-i; although, it's worth
mentioning that zstd seems like it will more likely satisfy users who
are coming from zfs' "lz4 compression is usually beneficial" school of
thought than lzo will.

Dmitri, does btrfs send/receive actually require userspace libzstd?
Or is it needed for defrag? (rewrites files, and also optionally
applies, removes, or changes compression type) I'm guessing that
btrfs-check requires it. (check --repair is, broadly speaking,
equivalent to 'fsck.ext4 -p')

The worst-case d-i bloat for an official arch seems to be 193.4kB for
i386, before compression.  Would you please 'reassign -1 libzstd' if
you agree that Debian's rescue mode should support cloning/restoring
subvolumes with compressed files, and/or being able to repair the
(unmounted) rootfs?  It seems strange that buster's initramfs has this
functionality and that rescue mode doesn't.  Alternatively, the btrfs
binary in the udeb could be statically linked...

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Dimitri John Ledkov]

On 15 January 2018 at 00:27, Cyril Brulebois  wrote:
> Hi,
>
> Cyril Brulebois  (2018-01-12):
>> Your package is no longer installable (along with its rev-dep
>> partman-btrfs) because it now depends on libzstd1, which isn't
>> a udeb.
>
> It seems zstd is only an option for btrfs-progs, and I've just confirmed
> that setting --disable-zstd on the dh_auto_configure line lets btrfs-progs
> build just fine, without the libzstd1 dependency. As far as I can tell,
> there's no absolute need for this feature in d-i, and we could consider
> building the udeb without zstd support, instead of requesting the addition
> of a libzstd1-udeb. What do you think?
>

That's an oversight on my part. From the recovery point of view, it
would be desired to have zstd compression support built-into
btrfs-progs-udeb such that one can use d-i recovery mode to
backup/restore btrfs filesystems with zstd compression.

-- 
Regards,

Dimitri.

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Cyril Brulebois]

Hi,

Cyril Brulebois  (2018-01-12):
> Your package is no longer installable (along with its rev-dep
> partman-btrfs) because it now depends on libzstd1, which isn't
> a udeb.

It seems zstd is only an option for btrfs-progs, and I've just confirmed
that setting --disable-zstd on the dh_auto_configure line lets btrfs-progs
build just fine, without the libzstd1 dependency. As far as I can tell,
there's no absolute need for this feature in d-i, and we could consider
building the udeb without zstd support, instead of requesting the addition
of a libzstd1-udeb. What do you think?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Cyril Brulebois]

Package: btrfs-progs-udeb
Version: 4.14.1-1
Severity: grave
Justification: renders package unusable

[ Please keep debian-b...@lists.debian.org in copy. ]

Hi,

Your package is no longer installable (along with its rev-dep
partman-btrfs) because it now depends on libzstd1, which isn't
a udeb.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant