Control: tags -1 + moreinfo On Sun, Feb 05, 2023 at 12:08:32PM +0200, Adrian Bunk wrote: > Control: tags -1 - moreinfo > Control: severity -1 serious > > On Fri, Dec 28, 2018 at 02:59:26PM +0100, Arturo Borrero Gonzalez wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Control: tag -1 moreinfo > > > > On Sun, 16 Dec 2018 13:14:19 +0100 Olivier <olivie...@free.fr> wrote: > > > Package: iptables Version: 1.8.2-2+b1 Severity: important > > > > > > Dear Maintainer, > > > > > > Issue occure during iptables:i386 1.8.2-2 -> 1.8.2-2+b1 upgrade. > > > > > > /var/lib/dpkg/info/iptables.postinst fail with message: > > > > > > ln: failed to create symbolic link ''$'\t'' > > > /sbin/iptables-save': No such file or directory > > > > > > > I can't reproduce the issue: > >... > > I didn't try in i386 because I don't have any machine (virtual or > > physical) with that arch, maybe is a architecture specific bug in the > > shell? Hard to believe to say the least. > >... > > I can reproduce the problem in a current amd64 unstable chroot.
Great, can you provide some information regarding how? Could you for example modify iptables.prerm to check what the content of $IFS is when you reproduce this? Did any other packages maintainer script (which does things with IFS) error out while you reproduce the problem with iptables? I can only speculate about this issue. I don't doubt the original reportes error message actually happened and is real, but I don't see how. The only possibility I see is that IFS was modified to a non-default value which made it no longer include tab- and space-characters. The iptables.prerm script doesn't set IFS itself, so I have to assume it somehow inherited a dirty environment from somewhere. Is it possible that some other packages maintainerscript code messed with IFS without resetting it and then that environment got inherited by iptables.prerm? If so then I think the package needs to be identified and this bug reassigned to it.... I don't think every package that has maintainerscripts should expect a dirty environment and guard against for example a non-default IFS, but that's kind of the only solution inside iptables that I can see.... have it explicitly (un)set IFS. I however don't think that's the correct solution, just a solution. > > #1007829 was a similar problem in arptables, > I haven't checked how these are related. I don't see how these two are related at all. #1007829 seems to be a simple logic error. Regards, Andreas Henriksson