Your message dated Wed, 07 Jan 2026 16:05:04 +0000
with message-id <[email protected]>
and subject line Bug#1124897: fixed in rl-renderpm 4.0.3+repack-10
has caused the Debian Bug report #1124897,
regarding rl-renderpm: please build using the default build flags
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.)


-- 
1124897: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124897
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: rl-renderpm
Version: 4.0.3+repack-9
User: [email protected]
Usertags: hardening-buildflags

rl-renderpm is not currently using the default build flags set by 
dpkg-buildflags(1).
The default flags are chosen for multiple reasons including security,
performance, reproducibility, adherence to standards, and error handling.

Please make sure that rl-renderpm builds using the default build flags. blhc(1p)
and hardening-check(1) can be used to confirm that the issue is fixed.

In the general case, packages honoring CFLAGS, LDFLAGS, and other
similar environment variables get the default build flags for free
without the need for any work on the maintainer side. In the case of
rl-renderpm, the flags are either ignored or overridden.

The most common reasons for this are:

Hand-written Makefiles
----------------------
Some upstream Makefiles either override the values of variables such as
CFLAGS and similar or do not use them at all. See:
https://wiki.debian.org/HardeningWalkthrough#Handwritten_Makefiles

Misconfigured build systems
---------------------------
If the upstream code uses autotools, CMake, or other popular build
systems, it usually requires no further modifications. If might however
be that some variables are hardcoded in some way.

In this CMake snippet, the value of CXXFLAGS is overwritten with "-O2":

 set(CMAKE_CXX_FLAGS "-O2")

If the intention is to append to CXXFLAGS, one should use the following
instead:

 set(CMAKE_CXX_FLAGS "-O2 ${CMAKE_CXX_FLAGS}")

See #655870 for a similar autotools example. 

Very old debhelper usage
------------------------
Packages not using dh(1), or those using a debhelper compatibility level
less than 9, need to manually include /usr/share/dpkg/buildflags.mk in
order for the dpkg-buildflags variables to be set:
https://wiki.debian.org/Hardening#dpkg-buildflags

Flags hardcoded in debian/rules (either voluntarily or not)
-----------------------------------------------------------
Some packages voluntarily hardcode the values of CFLAGS and friends in
debian/rules, ignoring the defaults set by dpkg-buildflags(1).

Others attempt to append to the variables, but end up accidentally
overriding the defaults:

 #!/usr/bin/make -f
 export CFLAGS += -pipe -fPIC -Wall

 %:
        dh $@

Debhelper only sets CFLAGS if it is not set yet. In the example above,
when dh is invoked the value of CFLAGS is "-pipe -fPIC -Wall", hence the
hardened defaults are not used. The right way to append to CFLAGS is
using DEB_CFLAGS_MAINT_APPEND instead, as documented in
dpkg-buildflags(1).

For a detailed analysis of this issue, see https://hal.science/hal-05334704/

--- End Message ---
--- Begin Message ---
Source: rl-renderpm
Source-Version: 4.0.3+repack-10
Done: Georges Khaznadar <[email protected]>

We believe that the bug you reported is fixed in the latest version of
rl-renderpm, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Georges Khaznadar <[email protected]> (supplier of updated rl-renderpm 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Wed, 07 Jan 2026 16:19:11 +0100
Source: rl-renderpm
Architecture: source
Version: 4.0.3+repack-10
Distribution: unstable
Urgency: medium
Maintainer: Georges Khaznadar <[email protected]>
Changed-By: Georges Khaznadar <[email protected]>
Closes: 1124897
Changes:
 rl-renderpm (4.0.3+repack-10) unstable; urgency=medium
 .
   * simplified files d/control and d/rules. Made the set of build-dependencies
     more accurate. Closes: #1124897
Checksums-Sha1:
 8947d93974b9b1bc184c618fc30b76fe1c376814 2095 rl-renderpm_4.0.3+repack-10.dsc
 6c096a06dd682be34908fa55da1ce911f2712833 5644 
rl-renderpm_4.0.3+repack-10.debian.tar.xz
 f9338e5f5639db1efd7957f6c85c86e068aceec9 7858 
rl-renderpm_4.0.3+repack-10_amd64.buildinfo
Checksums-Sha256:
 dc967b8c84e199690d4a147428108a9f7f2c1051b6fca18ccc9ef3ee26454cb9 2095 
rl-renderpm_4.0.3+repack-10.dsc
 0efb30d804d30023ab01cb9445adc6daabe0ae20669092c9d19920a83157b601 5644 
rl-renderpm_4.0.3+repack-10.debian.tar.xz
 a61cf9c7103f6364f611fe2a7376cc259cb485bda70cc4dad9ba83ee921e4b93 7858 
rl-renderpm_4.0.3+repack-10_amd64.buildinfo
Files:
 fe121849c4cacde9847376415a797e9f 2095 python optional 
rl-renderpm_4.0.3+repack-10.dsc
 50cef649e367acf1c63d12c2c5cea19b 5644 python optional 
rl-renderpm_4.0.3+repack-10.debian.tar.xz
 c9e800b678ab4927ef7a541bff041f7b 7858 python optional 
rl-renderpm_4.0.3+repack-10_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQJIBAEBCgAyFiEEM0CzZP9nFT+3zK6FHCgWkHE2rjkFAmlee4QUHGdlb3JnZXNr
QGRlYmlhbi5vcmcACgkQHCgWkHE2rjmiLA//aGDiJlq/3PYu+MzULPSZeg55RMAl
Q39Lb+uj75VIa5EdKBdoquxkx+q4jKk2wGigTuf+2noAI+EP9hEkfHHMMErbkLsJ
fgEXEaJdS9bQEbQBQzpp5iMe418vRGzru157G/895NQDSEWEdKJP1sMnJUrLXBd+
DpvEoR8gzQ5GaPTY2zIMUW/tH7D1W+OKokXIGHv0kKFGkr43rbSscmL1ynm3l1fQ
UoBUYP8x3pFiaLEprctIpf8RKZueKqRyXBIUET7Tdm7UYbOMuy8E4HTyVgAgZTEK
XRkPaoI25J1ce0akSqHF2LM1vGSZEMgjTRrmTzm1UMSdRoeDGpD2X3QBhYbL4GwL
JS2mKwy63O9TcUPvAi6KkXWwVhwREXMYzqbLFZ66Wq+MRYpZIfhkzXCoER3Cdn46
zkZFPEcikQINxkGD3PJUIDo5ku5rxl8N/WLMEXdecE2kskBHVXsdWHjbV4iDW7ju
Pkma/b7iMNTJ8BH3w030au3Eq/8UmaKh5NmzO8Pd6Goi8JriM6v0mP4A7KQgB9vN
6iiUSzzYRaslx7YHChC50IaGEcoiYi/xY94uljUoWPaemIdbxpYHuDwztgiy52Wl
NfBKgYywPfcybsNbamhT/W+F7n5MebiLGbIIKkPRMi1zi40HNMU9Xie8Xh1i7vP5
X+ULnAFA/oQNar4=
=RSWv
-----END PGP SIGNATURE-----

Attachment: pgp92QT9WPCOU.pgp
Description: PGP signature


--- End Message ---

Reply via email to