Your message dated Tue, 24 Feb 2026 10:21:40 +0000 with message-id <[email protected]> and subject line Bug#1128573: Removed package(s) from unstable has caused the Debian Bug report #1119692, regarding Fwd: Bug#1119436: golf: 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.) -- 1119692: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1119692 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Source: golf Version: 601.4.41-1 User: mailto:[email protected] Usertags: hardening-buildflags golf 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 golf 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 golf, 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://people.debian.org/~ema/nocflags_paper.pdf (eprint: hal-05334704) Hi, two things have been done since the upload: 1) Golf has been renamed to RimStone and 2) the package now has only source code. As for the renaming, this was the plan all along, since Golf was always just a beta code name, and it was suggested to be changed by the original Debian reviewers anyways. It turns out though, to change the name it takes quite a bit of effort in the API, the documentation, the internals etc. So it finally came through. As for the Makefile and the flags, the package no longer has any binaries at all, rather it contains only source code as a tar.gz archive. So in the new RImStone code, the Makefile is only used after the package is installed. It is used by the end user to build the binaries into their local folder by means of riminst.sh script which generally does not require sudo. Meaning RimStone is compiled and linked by the end-user from the source installed by the package, and into a local folder. The reason for this is 1) safety, because only the source code is distributed and 2) RimStone is a high-performance language, and it uses LTO (LInk TIme Optimization) 100%, and the source code is needed to do that. Other than the source code, the RImStone package has toolkit dependencies (such as openssl, sqlite3 etc.), and also build dependencies (such as gcc, make etc). The new URL is https://rimstone-lang.com/ and the new contact email is mailto:[email protected] Each release has the packages automatically built and posted at https://github.com/rimstone/rimstone/releases . This includes files needed to build a package, as well as pre-built apt, dnf, pacman and zypper packages. For Debian, it includes these two files source archives from which a debian package can be built, say using debuild: 1. debian.tar.gz, which is the compressed debian directory with control, rules etc. files 2. source code orig.tar.gz file Regards, Serge
--- End Message ---
--- Begin Message ---Version: 601.4.41-1+rm Dear submitter, as the package golf has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/1128573 The version of this package that was in Debian prior to this removal can still be found using https://snapshot.debian.org/. Please note that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing [email protected]. Debian distribution maintenance software pp. Thorsten Alteholz (the ftpmaster behind the curtain)
--- End Message ---
