Bug#851486: debian-installer: USB keyboard doesn't work on Banana Pi
Package: debian-installer Version: 20170112 Severity: normal Tags: d-i Dear Maintainer, My Banana Pi's SD card got corrupted so I'm trying to re-install the system. Following the instructions on https://wiki.debian.org/InstallingDebianOn/Allwinner I downloaded the bits from http://ftp.uk.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/ and the resulting SD card boots fine. After applying the console changes to output to HDMI, I can even see the installer — but the USB keyboard doesn't work... It works in u-boot so the hardware would appear to be OK. Regards, Stephen -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#818604: Relies on MD5SUM and SHA1SUM to download d-i images in a trustful way
Hi Didier, On Fri, Mar 18, 2016 at 06:43:41PM +0100, Didier 'OdyX' Raboud wrote: > Le vendredi, 18 mars 2016, 16.25:10 Didier 'OdyX' Raboud a écrit : > > win32-loader (its standalone version, available from debian/tools/ ) > > currently relies exclusively on MD5 and SHA1 to trustfully download > > the d-i images. > [...] > > B) Write a new standalone sha256sum.c NSIS plugin from one of the >existing implementations: > - libgcrypt: cipher/sha256.c (LGPLv2.1+) > - coreutils: lib/sha256.c (GPLv3+) > - e2fsprogs: lib/ext2fs/sha256.c (GPLv2) > - wget: lib/sha256.c (GPLv3+) > - glibc: crypt/sha256.c (LGPLv2.1+) > - … plenty of others > > Given that win32-loader is GPLv3 +, this excludes e2fsprogs', but others > should be fine. It might be possible to use libgcrypt-mingw-w64-dev, currently in experimental, to write a new NSIS plugin without duplicating the hashing implementation... The libgcrypt package should end up in Stretch before the release, since the whole point of it is to support the Windows build of gnupg2. Regards, Stephen signature.asc Description: PGP signature
Re: shipping libraries in debian for use when cross-building with mingw-w64-i686-dev (for win32-loader)
Hi Daniel,
On Mon, 15 Feb 2016 15:21:52 -0500, Daniel Kahn Gillmor
<d...@fifthhorseman.net> wrote:
> On Mon 2016-02-15 07:26:14 -0500, Stephen Kitt wrote:
> > This is where header files and DLLs should go; the compiler and linker
> > look there by default (/usr/{i686,x86_64}-w64-mingw32/{include,lib}).
> >
> > The overrides mention "For now" because the long-term plan is to add the
> > MinGW-w64 targets as Debian (partial) architectures
> > (https://bugs.debian.org/606825). Then the appropriate directories would
> > be /usr/{include,lib}/{i686,x86_64}-w64-mingw32 as per multi-arch...
>
> Thanks for the explanation. I've subscribed to that bug report (though
> i confess i don't understand all the details discussed there) and i'm
> happy to help make the per-package transitions necessary whenever the
> shift to "true multiarch" happens. Feel free to open bug reports
> against any of the packages needed to be touched when that happens.
Will do! Don't hold your breath though ;-).
> > Option 0 for header files and libraries, option 1 for executables. It
> > should be documented but isn't yet...
>
> Ok, works for me. The one possible exception, i think, will be the
> ${FOO}-config executable POSIX shell scripts, like gpg-error-config.
> These will likely need to be carried forward for as long as upstream
> objects to pkg-config [0]. I'm inclined to ship them in e.g.,
> /usr/i686-w64-mingw32/bin/gpg-error-config, so that rdeps can
> ./configure --with-libgpg-error-prefix=/usr/i686-w64-mingw32 for now.
> Does this make sense?
Ah, -config scripts, oh joy... ${prefix}/bin does make sense for now. I'm
planning on adding a pre-baked configure launcher, which could add that to
the PATH to make things simpler; or perhaps even a dh helper (I need to think
about that a bit more though).
> > Sounds good; I should really write up a Windows policy of some sort.
>
> Please do write one up, even if only a wiki page at the moment. I'd be
> happy to read it and give feedback.
Thanks for the offer, I'll let you know once I've done it (soon!).
> > Please use lib...-mingw-w64 and lib...-mingw-w64-dev packages if
> > possible; see libz-mingw-w64 for an example (although that particular
> > package is rather inefficient since it's a new source package rather
> > than extra binary packages produced by zlib1g).
>
> hm, I'm not convinced i want to introduce two new arch-independent
> packages in each of these dependencies; it seems excessive when most of
> these are just going to be used as build-dependencies. I'm currently
> thinking of making them strictly lib...-mingw-w64-dev, and leaving the
> .dlls in that package.
>
> Is there a practical reason to split out the .dlls separately from the
> .dll.a's for debian systems?
Only requests such as
https://bugs.launchpad.net/ubuntu/+source/gcc-mingw-w64/+bug/1235983 which
doesn't matter quite as much for gpg libraries; I imagine the resulting
packages are small, and in any case from Debian's point of view the packages'
only purpose is building software, not running it. So feel free to ignore my
request!
> Thanks for pointing out the libz-mingw-w64, also. My attempted builds
> have thus far only targeted i686-w64-mingw32. I note that
> libz-mingw-w64 additionally targets x86_684-w64-mingw32. I'm inclined
> to keep my current work focused just on the i686-w64-mingw32, but if you
> have a good argument for why you'd want them both, please let me know.
I just think it's a good idea to support 64-bit variants of Windows too.
It is now possible to configure some versions of Windows Server to only
support 64-bit executables, but I'm not sure how popular that is and I can't
imagine that affecting people wanting to use the executables we build for
Debian...
Regards,
Stephen
pgp6umlVcFoO1.pgp
Description: OpenPGP digital signature
Re: shipping libraries in debian for use when cross-building with mingw-w64-i686-dev (for win32-loader)
Hi Daniel,
Le 14/02/2016 17:40, Daniel Kahn Gillmor a écrit :
I'm trying to sort out the cross-building toolchain in debian for
making
windows binaries, for the sake of making things that will contribute to
win32-loader.
My main question is: when shipping cross-built libraries (.dll, .dll.a,
.la, and .a files) and header files for use on debian by other
cross-builders targetting win32, where do you think those libraries
should be placed in the filesystem? I see two options:
0) /usr/i686-w64-mingw32
This is where a bunch of dll's and header files already shipped by
mingw-w64-i686-dev live.
/usr/share/lintian/overrides/mingw-w64-i686-dev says in part:
# For now files are in /usr/${target}
mingw-w64-i686-dev: file-in-unusual-dir
mingw-w64-i686-dev: non-standard-dir-in-usr
I'm not sure what the "For now" is about. is there a larger plan?
This is where header files and DLLs should go; the compiler and linker
look there by default (/usr/{i686,x86_64}-w64-mingw32/{include,lib}).
The overrides mention "For now" because the long-term plan is to add the
MinGW-w64 targets as Debian (partial) architectures
(https://bugs.debian.org/606825). Then the appropriate directories would
be /usr/{include,lib}/{i686,x86_64}-w64-mingw32 as per multi-arch...
1) /usr/share/win32
This is currently where the files that target win32-loader live, like
gzip-win32 and cpio-win32. It's possible that this is only desirable
for the final .exe files produced for win32-loader, and that it should
not be used for the "intermediate" products like win32 libraries.
Exactly, that's the historical directory for executables used by
win32-loader, and I kept it for final executables because /usr/bin
doesn't seem particularly appropriate. (As long as the MinGW-w64 targets
aren't multi-arch compliant anyway.)
Do you have a preference? Do you see other options? Is any of this
documented somewhere i should read up on?
Option 0 for header files and libraries, option 1 for executables. It
should be documented but isn't yet...
Background: i'm currently working on updating gpgv-win32 to build it
From the "modern" GnuPG suite (2.1.x) instead of the "classic" suite
(1.4.x). Unlike the classic suite, the modern suite depends on a small
number of libraries that themselves need to be cross-built and
available
before gpgv.exe can be linked. I plan to build gpgv.exe statically so
that win32-loader doesn't have to deal with any dll's explicitly, but
to
do that i want to make sure that we have the underlying libraries
packaged and available properly.
At the minimum, this will include win32 builds for:
* libgpg-error
* libgcrypt
And it might be simplest for the overall process of producing gpgv.exe
From 2.1.x to produce win32 builds for (even though gpgv itself doesn't
depend on them):
* libassuan
* libksba
I'm preparing all the source changes needed for these -- i'll file bugs
with patches for the ones handled by Andreas, but i want to be sure
that
i'm putting things in the right place.
Sounds good; I should really write up a Windows policy of some sort.
Please use lib...-mingw-w64 and lib...-mingw-w64-dev packages if
possible; see libz-mingw-w64 for an example (although that particular
package is rather inefficient since it's a new source package rather
than extra binary packages produced by zlib1g).
I'm thinking that upstream might be interested in this too, since having
those particular DLLs available as native Debian packages would be
helpful for building GnuPG Windows binaries in general!
Regards,
Stephen
Bug#787131: debian-installer-launcher: stores the distribution name at build-time (Debian sid even in Jessie)
Package: debian-installer-launcher Version: 19 Severity: minor Dear Maintainer, I noticed in the LXDE live CD that the icon label and menu entry for debian-installer say Install Debian sid. I suppose that's because the .desktop file is processed at build time in unstable, but I don't know what the right fix should be... Regards, Stephen -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages debian-installer-launcher depends on: ii debconf [debconf-2.0] 1.5.56 ii menu 2.1.47 ii psmisc22.21-2 ii terminology [x-terminal-emulator] 0.7.0-1 ii xfce4-terminal [x-terminal-emulator] 0.6.3-1+b2 ii xterm [x-terminal-emulator] 318-2 debian-installer-launcher recommends no packages. Versions of packages debian-installer-launcher suggests: pn kexec-tools none -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150528215151.32429.96005.report...@heffalump.sk2.org
Bug#640789: Crash on folder name with spaces
Hi KiBi,
On Mon, Jul 07, 2014 at 03:56:21AM +0200, Cyril Brulebois wrote:
Modestas Vainius mo...@debian.org (2013-12-29):
thanks for the patch but I'm not convinced, see below:
--- a/debian/iso-scan.postinst
+++ b/debian/iso-scan.postinst
@@ -162,7 +162,7 @@ scan_device_for_isos() {
elif [ $look_subdirs = 1 ]; then
opt=-type f
fi
- isolist=$(find $dir $opt -name *.iso -o -name *.ISO
2/dev/null)
+ isolist=$(find $dir $opt -name *.iso -o -name
*.ISO 2/dev/null)
This part is certainly OK; at least I can't think of a reason why that
wouldn't be a good thing.
TOPLEVEL_DIRS_COUNT=$(($TOPLEVEL_DIRS_COUNT + 1))
for iso in $isolist; do
but then that means we're possibly going to fail here. Example:
[snip]
I guess it would make sense to fix this for real instead of hiding it a
bit further. Unfortunately 4am isn't a great time to set up a reproducer
and to keep on hacking. :/
There are in effect two bugs here. The first, which the patch fixes,
is that any folder with spaces in its name will cause iso-scan's
postinst to fail, preventing the installation. The second, which the
patch doesn't fix, is that any ISO found in a folder with spaces in
its name won't be handled correctly.
The first bug is extremely confusing, since an otherwise OK USB key
with all the appropriate files in the right place will fail to
install, with no explicit error message, and worse than that with a
message on the fourth terminal indicating that the ISO was found and
is usable...
The second bug, which is mitigated in part by the existence test (line
170), will only prevent certain ISOs from being used, and won't abort
the installation.
Wouldn't it be acceptable to apply the patch, and add an erratum
indicating that ISOs shouldn't be placed in folders containing spaces
in their names?
Regards,
Stephen
signature.asc
Description: Digital signature
Bug#623621: win32-loader: please support building with mingw-w64
Package: win32-loader Version: 0.7.0 Severity: wishlist Tags: patch Hi, mingw-w64, which is intended to eventually replace mingw32 and the assorted packages, is now available in Debian along with new builds of binutils and gcc. The attached patch allows win32-loader to build using mingw-w64 rather than mingw32. Note that it requires nsis to support mingw-w64 as well (#620099); I'll tag this bug appropriately. Regards, Stephen -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -urN win32-loader-0.7.0.orig/debian/changelog win32-loader-0.7.0+nmu1/debian/changelog --- win32-loader-0.7.0.orig/debian/changelog 2011-03-21 13:55:54.0 +0100 +++ win32-loader-0.7.0+nmu1/debian/changelog 2011-04-21 00:17:02.0 +0200 @@ -1,3 +1,10 @@ +win32-loader (0.7.0+nmu1) unstable; urgency=low + + * Non-maintainer upload. + * Rebuild with Debian dependencies only. + + -- Stephen Kitt st...@sk2.org Thu, 21 Apr 2011 00:17:02 +0200 + win32-loader (0.7.0) unstable; urgency=low The « Petite Arvine » release. diff -urN win32-loader-0.7.0.orig/debian/control win32-loader-0.7.0+nmu1/debian/control --- win32-loader-0.7.0.orig/debian/control 2011-03-17 13:35:18.0 +0100 +++ win32-loader-0.7.0+nmu1/debian/control 2011-04-21 00:12:58.0 +0200 @@ -6,7 +6,7 @@ Build-Depends: debhelper (= 7.0.50), nsis (= 2.43), - gcc-mingw32, mingw32-runtime, + mingw-w64, gettext, grub-pc (= 1.99~rc1-3), loadlin (= 1.6c.really1.6c.nobin-1~), diff -urN win32-loader-0.7.0.orig/Makefile win32-loader-0.7.0+nmu1/Makefile --- win32-loader-0.7.0.orig/Makefile 2011-03-21 13:55:54.0 +0100 +++ win32-loader-0.7.0+nmu1/Makefile 2011-04-21 00:18:36.0 +0200 @@ -4,14 +4,14 @@ PACKAGE := win32-loader VERSION := $(shell head -n 1 debian/changelog | sed -e s/^$(PACKAGE) (\(.*\)).*/\1/g) -NSIS_CC := i586-mingw32msvc-gcc -Os -NSIS_STRIP := i586-mingw32msvc-strip +NSIS_CC := i686-w64-mingw32-gcc -Os +NSIS_STRIP := i686-w64-mingw32-strip NSIS_CFLAGS := -Wl,--file-alignment,512 -Werror -D_WIN32_WINNT=0x0500 -ifeq ($(wildcard /usr/i586-mingw32msvc/include/exdll.h), /usr/i586-mingw32msvc/include/exdll.h) +ifeq ($(wildcard /usr/i686-w64-mingw32/include/exdll.h), /usr/i686-w64-mingw32/include/exdll.h) NSIS_CFLAGS += -DHAVE_EXDLL_H else -NSIS_CFLAGS += -L/usr/i586-mingw32msvc/lib/nsis -lpluginapi +NSIS_CFLAGS += -L/usr/i686-w64-mingw32/lib/nsis -lpluginapi endif # Standard makensis call
