Bug#1068789: nsis: build fails if version number has buildX or ubuntuX suffix

Thanks for making me aware of the issue. I’d like to fix this issue for other Debian derivatives such as Linux Mint as well. Would the following change work for you? VER_REVISION=$(shell echo $(firstword $(subst +, ,$(word 3,$(VERSION_DECOMPOSED | sed 's/[^0-9]//g') Are there any other

Bug#1050588: bookworm-pu: package nsis/3.08-3+deb12u1

Control: tags -1 -moreinfo Control: owner -1 Thomas Gaugler Hi Adam, I am the maintainer of Nullsoft Scriptable Install System (NSIS) and propose the changes committed into the debian/bookworm branch on the 27th January 2024 to be released as updated nsis 3.08-3+deb12u1 packages (<ht

Bug#1050288: nsis 3.08-3 (bookworm) generates bogus relocation information (regression)

Thank you for your detailed bug report. I built the nsis_3.09-1 and nsis-common_3.09-1 packages on Debian Bookworm, installed the resulting packages and can confirm with the two Nullsoft Installer (.nsi) scripts provided by you that the resulting installer executables no longer show the

Bug#1010488: win32-loader: please annotate the wine Build-Depends with

Fixed with the following commit:

Bug#962161: Add dependency to #972268

Control: block -1 972268

Bug#972268: ipxe-signed - PXE boot firmware EFI signed binary

Source: ipxe Severity: wishlist X-Debbugs-Cc: o...@debian.org Dear Maintainer, I would like to enable PXE booting within the win32-loader package under an UEFI Secure Boot regime. The original request (https://bugs.debian.org/962161) did not include the secure boot requirement. However a

Bug#947572: FTBFS with scons 3.1.2-1

Thank you for your bug report. The version 3.05 of NSIS should result in a successful build via scons requiring Python 3 compatible syntax. In particular the included commit #7124 "Port SCons scripts to py3k (xantares/py3k PR)" [1] addresses that. I am going to work on the upgrade of the

Bug#942396: nsis: increase NSIS_MAX_STRLEN to 8192

I just imagined to have one additional package. Let's call it nsis-special for the sake of simplicity. nsis-special would have the following content: /usr/share/nsis/Special/8kStrings/bzip2_solid-x86-ansi /usr/share/nsis/Special/8kStrings/bzip2_solid-x86-unicode

Bug#942396: nsis: increase NSIS_MAX_STRLEN to 8192

The discussion within bug report #432713 (https://bugs.debian.org/432713) is relevant here as well. Nevertheless I think it might be worthwhile providing the stubs of the special builds of "advanced logging" and "large strings" via an optional Debian package. Unfortunately it is not

Bug#922797: Wish for inclusion of ntfs, ntfscomp and http modules

Package: grub-efi-amd64-signed Version: 1+2.02+dfsg1+11 Severity: wishlist win32-loader installs the Linux kernel and initial ramdisk file in the win32-loader folder of the system drive. The inclusion of the ntfs and ntfscomp modules into the grub-efi-amd64-signed package would allow grub to

Bug#918863: reboot returns to Windows 10 on Lenovo X1

See for a proof of concept.

Bug#918863: reboot returns to Windows 10 on Lenovo X1

The BOOTCFG_IsUEFI function in include/bootcfg.nsh could be used to detect the firmware type (legacy BIOS versus UEFI). I thought to use the momentum around secure boot within Debian [2] for supporting it within win32-loader as well. The basic idea is to replicate the following commands in

Bug#919023: Simplification of BOOTCFG_CreateGUID function

/sh linked to /bin/dash Init: systemd (via /run/systemd/system) win32-loader depends on no packages. win32-loader recommends no packages. Versions of packages win32-loader suggests: pn wine >From e735da16c5059c680d279a00de8cdf3c0e1bf53e Mon Sep 17 00:00:00 2001 From: Thomas Gaugler Date:

Bug#918376: nsis 3.03-2: FTBFS, alignment problem

Thanks for your detailed bug report. I tried to reproduce the bug via the Disco Dingo Ubuntu/arm64 cloud image running inside the QEMU emulator [1]. I did not succeed in triggering the bug with this setup. I concluded from your debug output that the icon group boundary is not aligned to the

Bug#806036: Privilege escalation and code execution vulnerabilities in generated NSIS installers

Thank you very much for your detailed bug report. I would propose to wait for the review and the fix going in upstream. Thereafter the fix could be back ported to the NSIS version distributed by Debian. Best regards, Thomas

Bug#778029: nsis: ftbfs with GCC-5

I tried to reproduce the reported errors utilizing cowbuilder. Therefore I created a cowbuilder chroot environment containing the gcc-5 and g++-5 packages. I used the Debian Stretch (testing) distribution as basis. sudo cowbuilder --create --distribution stretch --basepath

Bug#754829: [binutils-mingw-w64-i686] i686-w64-mingw32-windres running on s390x does not properly convert string

Package: binutils-mingw-w64-i686 Version: 2.24.51.20140617-1+3 Severity: normal i686-w64-mingw32-windres running on s390x behaves differently when it comes to strings. s390x: $ echo 'STRINGTABLE { 1, String }' | i686-w64-mingw32-windres /* Type: stringtable Name: 1. */ LANGUAGE 9, 1

Bug#704828: nsis: CWD taken from symlink target, not symlink itself

If you provide the -nocd option to makensis then makensis won't change the current directory to that of the .nsi file. Below is an example to illustrate it: cd /tmp mkdir -p minimal/folder cat EOF minimal/folder/minimal.nsi !system pwd OutFile minimal.exe Section SectionEnd EOF cd minimal ln -s

Bug#704828: nsis: CWD taken from symlink target, not symlink itself

Good point! I extended your example by an include directive such as: tmp/folder/Makefile --- include folder/hello all: pwd --- tmp/folder/hello --- hello: echo Hello World!

Bug#704828: nsis: CWD taken from symlink target, not symlink itself

If you build your .nsi script in the /home/user/project folder then it is going to fail as well. makensis follows symbolic links. So if you put your .nsi file in the parent folder then you would need to adapt the file references to this new base (/home/user/project). In your example this means

Bug#654380: AW: Re: Bug#654380: #654380 (was: nsis: The zmemcpy patch breaks NSISdl::download (at least).)

Please add the Origin field as suggested by you and go ahead with the upload. I don't have any further things to be added for your upload. Thanks in advance and as well a Happy New Year, Thomas Didier Raboud o...@debian.org hat geschrieben: On Tue, 3 Jan 2012 19:43:42 +0100, Thomas Gaugler

Bug#654380: #654380 (was: nsis: The zmemcpy patch breaks NSISdl::download (at least).)

Hi Odyx, This seems to correspond to RedHat's [RH#734905] and to NSIS's [NSIS#3406350]. It works indeed. And the patch is shipped since multiple releases in Fedora, so I pushed it to nsis' packaging repository: http://anonscm.debian.org/gitweb/?p=collab-maint/nsis.git;a=commit;h=f89eb1af

Bug#642756: Fixing RCs #634405 and #642756

Hi OdyX, it seems like neither you nor me can find a proper solution to solve the parallel building problems highlighted by bugs #634405 and #642756. Hence, I propose to simply drop parallel building support, with the attached patch. What do you think ? On one hand we could drop the

Bug#642756: nsis: FTBFS: sh: 1: .test/makensis: Text file busy

Hi, It looks like this time the build got past the build failure as described in bug #634405. At the moment I have got no plausible explanation about the Text file busy errors. Do these errors happen reproducible? Best regards, Thomas -- To UNSUBSCRIBE, email to

Bug#634405: nsis: FTBFS: i686-w64-mingw32-gcc: error: Source/bzip2/bzlib.c: No such file or directory

It would be interesting to know if similar effects as described in bug #632228 could be observed. Does a non-parallel build fail as well? The Source/bzip/bzlib.c file is included in the .orig tarball. So the file should be there when building. Best regards, Thomas -- To UNSUBSCRIBE, email to

Bug#630620: nsis: Fails to install on the first try

Thanks for pointing out the issue of overwriting files caused by the split of the nsis package into four packages. I added Replaces/Breaks against nsis to the new packages and committed these changes to the git repository: http://anonscm.debian.org/gitweb/?p=collab-maint/nsis.git Best regards,

Bug#620099: nsis: diff for NMU version 2.46-3.1

Hi Stephen, I combined the best of your patch and the input from http://sourceforge.net/support/tracker.php?aid=2949102. The result is now visible in the collab-maint subversion repository. http://svn.debian.org/wsvn/collab-maint/ext-maint/nsis/trunk/?op=log The preference is given to

Bug#620099: nsis: diff for NMU version 2.46-3.1

Hi Stephen, Thanks for the patch. I am unsure if I could completely drop support for mingw32 as your patch suggests. The win32-loader package uses mingw32 as a compiller and requires the NSIS plugin api header and library files for mingw32. Best regards, Thomas -- To UNSUBSCRIBE, email to

Bug#620099: nsis: support building with mingw-w64

Hi Stephen, Thanks for your patch. I am going to combine your patch with the information provided in the sourceforge tracker: http://sourceforge.net/support/tracker.php?aid=2949102 One open issue is where to install the header and library files for the plugin development. Currently the paths

Bug#619488: nsis: Please upload an upstream snapshot (Unicode support, more languages, …)

Hi OdyX, Thanks a lot for your suggestions and feedback. I am exploring if a full build could be limited to one architecture (i386) and for all other architectures the architecture independent packages could be reused. So far I have not completely succeeded to build nsis from the subversion

Bug#619488: nsis: Please upload an upstream snapshot (Unicode support, more languages, …)

Hi OdyX, Given the lack of proper NSIS releases, but given the improvements made in their VCS, I think it would be nice to have a more recent nsis, a snapshot from their SVN. That's a good idea and it is also on my mind for sometime. However before I move onto that I would like to lay the

Bug#609781: nsis: FTBFS on i386: E: Caught signal 'Terminated': terminating immediately

your package FTBFS on i386 in experimental, apparently with a timeout: ... | /build/buildd-nsis_2.46-3-i386-Xh5JX8/nsis-2.46/build/release/tests/test | E: Caught signal 'Terminated': terminating immediately | make[1]: ... scons: building terminated because of errors. | scons: writing

Bug#598039: [p-a-s]: Please remove architecture restrictions on experimental for NSIS

Package: buildd.debian.org Severity: minor Please remove the current architecture restrictions on the experimental repository for the NSIS package. The source code of NSIS should allow to build for any architecture. Thanks in advance, Thomas -- To UNSUBSCRIBE, email to

Bug#596894: nsis: provide binary package on powerpc

There should no longer be any reasons to restrict the target architectures for the NSIS package. I am going to remove the architecture restrictions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Bug#580957: nsis: Lacks Dzongkha Language files

There does not seem to be a Windows codepage representing the Dzongkha language. Source: http://www.microsoft.com/globaldev/reference/WinCP.mspx Therefore I assume we would need to wait for Unicode NSIS. http://bugs.debian.org/489374 -- To UNSUBSCRIBE, email to

Bug#579407: nsis: zlib compression does not work

) in the header of each non-compressed block (BTYPE=00). [For details see section 3.2.4 in RFC 1951]. Forwarded: http://sf.net/support/tracker.php?aid=2995455 Bug-Debian: http://bugs.debian.org/579407 Author: Thomas Gaugler tho...@dadie.net Index: nsis-2.46/Source/zlib/INFBLOCK.C

Bug#579407: nsis: zlib compression does not work

Thank you very much for your detailed bug report. The same effects could also be observed on Debian squeeze/sid i386. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#538762: correlation with plugin size?

Download win32-loader package (Lenny): http://mirrors.kernel.org/debian/pool/main/w/win32-loader/win32-loader_0.6.10_all.deb Extract systeminfo.dll from win32-loader package via 7-Zip: 7z e win32-loader_0.6.10_all.deb data.tar.gz 7z e data.tar.gz 7z e -r data.tar win32-loader.exe 7z e -r

Bug#538762: correlation with plugin size?

The GetComputerNameEx API function is not available on Windows 9x. As a result the LoadLibrary API function loading the win32-loader plugin dll fails because the reference of GetComputerNameExA in the import table could not be resolved on Windows 9x. The would propose the attached patch to fix

Bug#538762: correlation with plugin size?

There is a problem loading the win32-loader (SVN rev. 61594) plug-in via the LoadLibrary API function on Windows 98 Second Edition. I have not yet found out why the win32-loader plug-in behaves different on Windows 98 Second Edition compared to other NSIS plug-ins. Below are my notes regarding

Bug#443121: nsis: NSISdl et al. trigger anti-virus false positives

Package: nsis Version: 2.45-1 The online virus scan service http://www.virustotal.com did not report any viruses, worms or trojans on the NSISdl.dll file included in the nsis_2.45-1_i386.deb package: Antivirus Version Last Update Result TrendMicro8.950.0.10942009.08.24

Bug#538762: results from plugin are corrupted

I built the installer executable from the sources [testcase.tar.gz] provided in your bug report on Debian Sid (i386). The installer correctly showed the following information in a message box: --- Name Setup --- arch=amd64

Bug#319999: porting asm to gcc

/System/Source/call.asm nsis-2.40-src/Contrib/System/Source/call.asm --- nsis-2.40-src.orig/Contrib/System/Source/call.asm 1970-01-01 01:00:00.0 +0100 +++ nsis-2.40-src/Contrib/System/Source/call.asm 2008-10-24 20:15:22.0 +0200 @@ -0,0 +1,954 @@ +;# Copyright (c) 2008 Thomas Gaugler