Your message dated Thu, 17 Sep 2020 11:39:21 +0200
with message-id <[email protected]>
and subject line Re: Bug#970451: /usr/bin/dpkg-deb: error: maintainer script
'postrm' has bad permissions 644 (must be >=0555 and <=0775)
has caused the Debian Bug report #970451,
regarding /usr/bin/dpkg-deb: error: maintainer script 'postrm' has bad
permissions 644 (must be >=0555 and <=0775)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
970451: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970451
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg
Version: 1.19.7ubuntu3
Severity: important
File: /usr/bin/dpkg-deb
Dear Maintainer,
Building a .deb for an OpenSource product using a script that I used years ago
as a template.
This bug is very very old.
has bad permissions 644 (must be >=0555 and <=0775)
That was happening during the Ubuntu 14.04 days. Here it is 20.04 and it is
happening again.
Check out bugs 48914 70078 2899
popped up again in 2015
https://github.com/kristrev/multi/pull/10
2014
https://github.com/sbt/sbt-native-packager/issues/419
I haven't tried the hack around yet, but as I recall the hack around was to set
permission
to either 0775 or 0555 because the "between" logic wasn't correct.
After all of these years and all of the examples scripts using 0644 over the
decades I
really expected this bug to be dead.
-- Package-specific info:
System tainted due to merged-usr-via-symlinks.
-- System Information:
Debian Release: bullseye/sid
APT prefers focal-updates
APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'),
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-47-generic (SMP w/6 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dpkg depends on:
ii libbz2-1.0 1.0.8-2
ii libc6 2.31-0ubuntu9
ii liblzma5 5.2.4-1ubuntu1
ii libselinux1 3.0-1build2
ii libzstd1 1.4.4+dfsg-3
ii tar 1.30+dfsg-7
ii zlib1g 1:1.2.11.dfsg-2ubuntu1
dpkg recommends no packages.
Versions of packages dpkg suggests:
ii apt 2.0.2ubuntu0.1
pn debsig-verify <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi!
On Wed, 2020-09-16 at 06:18:17 -0500, Roland Hughes wrote:
> Package: dpkg
> Version: 1.19.7ubuntu3
> Severity: important
> File: /usr/bin/dpkg-deb
> Building a .deb for an OpenSource product using a script that I
> used years ago as a template.
> This bug is very very old.
>
> has bad permissions 644 (must be >=0555 and <=0775)
The maintainer script in the generated binary package needs to be
executable, and apparently either the file in the source does not have
the correct permissions or nothing in your packaging makes sure the file
ends up with them, so this looks like a packaging bug, and not a bug in
dpkg-deb.
> That was happening during the Ubuntu 14.04 days. Here it is 20.04
> and it is happening again.
> Check out bugs 48914 70078 2899
>
> popped up again in 2015
> https://github.com/kristrev/multi/pull/10
> 2014
> https://github.com/sbt/sbt-native-packager/issues/419
These all are packaging bugs, filed and fixed in their respective
packages.
> I haven't tried the hack around yet, but as I recall the hack around was to
> set permission
> to either 0775 or 0555 because the "between" logic wasn't correct.
There's no workaround here, the permissions for the file just need to
be fixed.
> After all of these years and all of the examples scripts using 0644
> over the decades I really expected this bug to be dead.
If you have seen example packaging with non-executable maintainer
script that's most probably because the packaging uses a helper such
as debhelper which will take care of fixing the permissions while
doing the build.
I'm thus closing this now as I don't see any bug in dpkg here, but
feel free to reopen if there is something else going on.
Thanks,
Guillem
--- End Message ---
