Bug#1056697: 12.2 Installation Report, Complete Failure of Network

[Lennart Sorensen]

On Fri, Nov 24, 2023 at 12:34:50PM -0600, David Hillman wrote:
> 
> Package: installation-reports
> 
> Boot method: USB stick
> Image version: 
> https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.2.0-amd64-netinst.iso
> Date: 2023-November-23 11PM GMT
> 
> Machine: Dell R720
> Processor: 2 x Xeon E5-2650
> Memory: 192GB
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O ]
> Detect network card:    [E ]
> Configure network:  [E ]
> Detect media:   [ ]
> Load installer modules: [ ]
> Detect hard drives: [O ]
> Partition hard drives:  [O ]
> Install base system:    [ ]
> Clock/timezone setup:   [ ]
> User/password setup:    [O ]
> Install tasks:  [ ]
> Install boot loader:    [ ]
> Overall install:    [E ]
> 
> Comments/Problems:
> 
> 
> Installer completely failed to identify the presence of all four integrated
> Broadcom BCM5720 ethernet ports, and even after manually adding and
> configuring the four interfaces, no network connectivity is to be had. 
> Interfaces are allegedly "UP", but cannot ping anything nor respond to any
> communication.  IDRAC card interface works fine -- on the same subnet.  A
> half-dozen other multi-interface machines on the same subnet are working
> fine, as well.
> 
> Ubuntu 20 and 22 installers work just fine on the same hardware, so this is
> a Debian-specific issue.  All four interfaces work just fine under both
> Ubuntu 20 and 22, but are totally dysfunctional with Debian 12.
> 
> Journal entries for NetworkManager and avahi-daemon appear to show the
> correct IP addresses being registered for all four interfaces, and "ip"
> agress, all to no avail.  No related error messages exist in the journal.

I suspect you are missing the firmware file for the network port.  I think this 
one:

firmware-misc-nonfree: /lib/firmware/tigon/tg3.bin

The installer probably does not include that.

-- 
Len Sorensen

Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel

[Lennart Sorensen]

On Fri, Oct 27, 2023 at 02:29:30PM +0100, Steve McIntyre wrote:
> Are either of those ports (armeb/arm64ilp32) actually useful / alive
> at this point?

Not that I have seen.  I didn't think anything other than the IXP ever
really used big endian and that's a long time ago.  arm64ilp32 seems
to serve less purpose than x32 did (and x32 doesn't seem to be doing
much either).  Certainly looks essentially dead at this point.

-- 
Len Sorensen

Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Lennart Sorensen]

On Mon, Sep 25, 2023 at 02:03:35AM +0200, Bastian Blank wrote:
> The current way does not work.  See all the bug reports about
> uninstallable packages and what not with dkms.
> 
> To build modules against version x, you'll need to install version x of
> the headers, not x-1 or x+1.  This currently works most of the time, but
> is by far stable.  And if you already have to search for the specific
> version, it does not matter if you might have the ability to install
> multiple at the same time, the archive will in any case only contain one
> version at a time.

So you want to change something from where dkms works 99.99% of the time
to 0% of the time?  Having multiple kernel versions and being able
to build for them is a very normal thing to do that almost always works.
Why break that?

Sure there are some bugs for when dkms has issues, but you don't get
bug reports for all the cases where it is working.

I am having trouble understanding what the problem was that you are
attempting to fix, but so far the cure sounds far worse than the disease.

-- 
Len Sorensen

Bug#1042563: installation-reports: installation OK, screen remains blank during boot and GDM Greeter

[Lennart Sorensen]

On Sun, Jul 30, 2023 at 01:08:13PM +0100, Steve McIntyre wrote:
> Hi Axel!
> 
> I'm a little confused here...
> 
> You say the machine is a Thinkpad X230, but the attached cpuinfo says
> you have an Atom CPU and the DMI data says it's an ASUSTeK Eee
> PC. What hardware are we actually looking at here please?

It also says 4.15 kernel which is clearly not bookworm.  I think the
installation log was accidentally from a much earlier install on a
different machine.

-- 
Len Sorensen

Bug#1035569: installation-reports: failed to detect Realtek RTL8852BE WiFi 6 802.11ax PCIe adapter

[Lennart Sorensen]

On Fri, May 05, 2023 at 07:24:19PM +0200, fab...@greffrath.com wrote:
> Am 05.05.2023 18:23, schrieb Cyril Brulebois:
> > Right, initial support seems to have been merged in time for v6.2-rc1
> > only.
> 
> Oh, no!
> 
> When will be the earliest chance for a D-I image with kernel >= 6.2?

I am suspecting sometime after Bookworm is released in June.  Certainly
bookworm is using 6.1 kernel (which is a longterm support kernel, which
6.2 isn't).  So the kernel version isn't changing until the next release
(typically in 2 years or so if the past is anything to go by).  Testing
and unstable will of course get a new kernel much sooner than that.

I would be surprised if support for a new network chip version was
backported to the 6.1 stable tree.  Usually only bug fixes get ported
there.

-- 
Len Sorensen

Bug#1013678: installation-reports: honeycomb lx2: partial success, network and issues with raid/lvm/grub

[Lennart Sorensen]

On Fri, Jun 24, 2022 at 02:10:44PM -0700, Vagrant Cascadian wrote:
> Package: installation-reports
> Severity: normal
> X-Debbugs-Cc: vagr...@debian.org
> 
> Boot method: network
> Image version: 
> https://d-i.debian.org/daily-images/arm64/20220624-02:19/netboot/netboot.tar.gz
> Date: 2022-06-24 after breakfast but before lunch
> 
> Machine: Solidrun Honeycomb LX2
> Partitions:
> udev   devtmpfs  32513604   0  32513604   0% /dev
> tmpfs  tmpfs  6514616 744   6513872   1% /run
> /dev/sda3  ext4   9510080 1530260   7475144  17% /
> tmpfs  tmpfs 32573080   0  32573080   0% /dev/shm
> tmpfs  tmpfs 5120   0  5120   0% /run/lock
> /dev/sda1  vfat3899043536386368   1% /boot/efi
> tmpfs  tmpfs  6514616   0   6514616   0% /run/user/1000
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[E]
> Configure network:  [O]
> Detect media:   [O]
> Load installer modules: [O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[O]
> Install tasks:  [O]
> Install boot loader:[E]
> Overall install:[E]
> 
> Comments/Problems:
> 
> On-board ethernet is not detected in debian-installer or even once the
> system is installed. Worked around with a USB-ethernet adapter.
> 
> Boot loader would install successfully, but grub would not boot when I
> had a system with rootfs on lvm on raid1 (with degraded 1-disk
> array). I think this sort of configuration used to work, but it has
> been ages since I've tested. Will check another install if it works
> better with a not degraded array (e.g. raid1, two disks). Workaround
> was to use a plain partition with ext4 for rootfs.
> 
> FWIW, Same issues with bullseye's installer too, so at least it's
> not...  a regression? :)
> 
> 
> live well,
>   vagrant
> 
> -- Package-specific info:
> 
> ==
> Installer lsb-release:
> ==
> DISTRIB_ID=Debian
> DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
> DISTRIB_RELEASE="12 (bookworm) - installer build 20220624-02:01:58"
> X_INSTALLATION_MEDIUM=netboot
> 
> ==
> Installer hardware-summary:
> ==
> uname -a: Linux hclx2 5.18.0-2-arm64 #1 SMP Debian 5.18.5-1 (2022-06-16) 
> aarch64 GNU/Linux
> lsmod: Module  Size  Used by
> lsmod: fuse  131072  0
> lsmod: nls_ascii  16384  1
> lsmod: nls_cp437  20480  1
> lsmod: efivarfs   20480  1
> lsmod: dm_mod143360  6
> lsmod: dax36864  1 dm_mod
> lsmod: raid1  57344  1
> lsmod: md_mod167936  4 raid1
> lsmod: xfs  1376256  0
> lsmod: jfs   196608  0
> lsmod: btrfs1466368  0
> lsmod: xor20480  1 btrfs
> lsmod: xor_neon   20480  1 xor
> lsmod: raid6_pq  106496  1 btrfs
> lsmod: zstd_compress 253952  1 btrfs
> lsmod: libcrc32c  16384  2 btrfs,xfs
> lsmod: vfat   28672  1
> lsmod: fat81920  1 vfat
> lsmod: ext4  761856  1
> lsmod: crc16  16384  1 ext4
> lsmod: mbcache24576  1 ext4
> lsmod: jbd2  143360  1 ext4
> lsmod: crc32c_generic 16384  3
> lsmod: sd_mod 57344  3
> lsmod: t10_pi 20480  1 sd_mod
> lsmod: crc64_rocksoft 20480  1 t10_pi
> lsmod: crc64  20480  1 crc64_rocksoft
> lsmod: crc_t10dif 20480  1 t10_pi
> lsmod: crct10dif_common   16384  1 crc_t10dif
> lsmod: ahci_qoriq 16384  0
> lsmod: ahci_platform  16384  3
> lsmod: libahci_platform   20480  2 ahci_platform,ahci_qoriq
> lsmod: libahci40960  3 
> libahci_platform,ahci_platform,ahci_qoriq
> lsmod: libata303104  4 
> libahci,libahci_platform,ahci_platform,ahci_qoriq
> lsmod: usb_storage73728  0
> lsmod: scsi_mod  229376  3 sd_mod,usb_storage,libata
> lsmod: scsi_common16384  3 scsi_mod,usb_storage,libata
> lsmod: cdc_ether  20480  0
> lsmod: usbnet 45056  1 cdc_ether
> lsmod: r8152 110592  0
> lsmod: mii20480  2 usbnet,r8152
> lsmod: xhci_plat_hcd  20480  0
> lsmod: xhci_hcd  253952  1 xhci_plat_hcd
> lsmod: at803x 32768  0
> lsmod: xgmac_mdio 20480  0
> lsmod: acpi_mdio  16384  1 xgmac_mdio
> lsmod: mdio_devres16384  1 xgmac_mdio
> lsmod: of_mdio20480  2 

Bug#1003490: u-boot: FTBFS on arch:all with qemu-ppce500 target

[Lennart Sorensen]

On Mon, Jan 10, 2022 at 05:10:04PM -0800, Vagrant Cascadian wrote:
> Package: u-boot
> Version: 2022.01+dfsg1-1
> Severity: serious
> X-Debbugs-Cc: debian-powe...@lists.debian.org, q...@packages.debian.org, 
> binut...@packages.debian.org
> 
> Something in the toolchain recently changed which causes u-boot arch:all
> build to FTBFS... I suspect binutils, as building in "bookworm" still
> works fine where binutils hasn't yet migrated.
> 
> On arch:all builds the qemu-ppce500 target is cross-compiled.
> 
> Full log:
> 
>   
> https://buildd.debian.org/status/fetch.php?pkg=u-boot=all=2022.01%2Bdfsg-1=1641860624=0
> 
> The hopefully relevent lines from the build log:
> 
>   powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/cpu/mpc85xx/.tlb.o.d -nostdinc 
> -isystem /usr/lib/gcc-cross/powerpc-linux-gnu/11/include -Iinclude  
> -I/<>/include  -I/<>/arch/powerpc/include -include 
> /<>/include/linux/kconfig.h  
> -I/<>/arch/powerpc/cpu/mpc85xx -Iarch/powerpc/cpu/mpc85xx 
> -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security 
> -fno-builtin -ffreestanding -std=gnu11 -fshort-wchar -fno-strict-aliasing 
> -fno-PIE -Os -fno-stack-protector -fno-delete-null-pointer-checks 
> -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds 
> -Wno-array-bounds -Wno-stringop-overflow -Wno-maybe-uninitialized 
> -fmacro-prefix-map=/<>/= -g -fstack-usage -Wno-format-nonliteral 
> -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=date-time 
> -Wno-packed-not-aligned -D__powerpc__ -ffixed-r2 -m32 -fno-ira-hoist-pressure 
> -Wa,-me500 -msoft-float -mno-string -fpic -mrelocatable -ffunction-sections 
> -fdata-sections -mcall-linux -msingle-pic-base -fno-jump-tables -pipe
> -DKBUILD_BASENAME='"tlb"'  -DKBUILD_MODNAME='"tlb"' -c -o 
> arch/powerpc/cpu/mpc85xx/tlb.o /<>/arch/powerpc/cpu/mpc85xx/tlb.c
> ...
> {standard input}: Assembler messages:
> {standard input}:127: Error: unrecognized opcode: `tlbre'
> {standard input}:418: Error: unrecognized opcode: `tlbre'
> {standard input}:821: Error: unrecognized opcode: `msync'
> {standard input}:821: Error: unrecognized opcode: `tlbwe'
> {standard input}:884: Error: unrecognized opcode: `tlbsx'
> make[4]: *** [/<>/scripts/Makefile.build:253: 
> arch/powerpc/cpu/mpc85xx/tlb.o] Error 1
> make[3]: *** [/<>/Makefile:1810: arch/powerpc/cpu/mpc85xx] Error 
> 2
> make[3]: *** Waiting for unfinished jobs
>   powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/lib/.traps.o.d -nost
> 
> 
> If anyone has thoughts what might be the issue, please chime in!
> 
> 
> I could remove qemu-ppce500 from the build targets(all other targets
> build fine); I am not sure if it is used by qemu or if qemu builds all
> it's own firmwares.

Which gcc version?  I believe gcc 9 removed the code for powerpcspe
which gcc 8 deprecated.  So at this point I think only llvm/clang supports
the powerpcspe targets.

I don't recall if binutils also dropped support or have kept it around.

-- 
Len Sorensen

Bug#991638: [Pkg-javascript-devel] Bug#991638: nodejs: Please enable build on 32-bit PowerPC (powerpc)

[Lennart Sorensen]

On Thu, Jul 29, 2021 at 10:23:38PM +0200, John Paul Adrian Glaubitz wrote:
> It should work on the standard 32-bit PowerPC baseline which includes
> AltiVec. Other systems such as PowerPC E500 had their own Debian port
> anyway (powerpcspe).

32 bit powerpc does not require altivec.  e300 runs it fine and sure
doesn't have altivec.  G3 powermac had no altivec either.  A few packages
(like vlc for example) are broken and assume altivec is always present.

powerpcspe was for the offshoot that didn't use the normal FPU (had a
signal processor instruction set instead) like the e500 (but not e500mc).

-- 
Len Sorensen

Bug#986709: Removal certainly seems like the wrong solution

[Lennart Sorensen]

Now Debian has a release with a useful package missing.  What ever
happened to orphaning a package if you didn't want to maintain it anymore?
I certainly see nothing that make the claim that it isn't suitable for
release justified.  It is working very well and does not appear to have
any serious bugs.  Good thing you didn't remove it from sid.  The removal
from bullseye was clearly wrong and unjustified.  Not the correct way
to handle a package (I am surprised it got removed in fact).

As for the idea restic is a useful replacement, not a chance.  That design
is way too complicated and they are not even at a release where they
declare the api or repo format stable.  rsnapshot nicely provides a
backup that you can look at with standard tools and recover things
however is most convinient.

And someone did just do some updates upstream and make a 1.4.4 release
a few days ago.

-- 
Len Sorensen

Bug#985853: debian-installer: Whitespace before a commented line in preseed file causes line to be parsed

[Lennart Sorensen]

On Thu, Mar 25, 2021 at 09:45:17AM +1030, Andrew McDonnell wrote:
> Package: debian-installer
> Version: 20190702+deb10u8
> Severity: important
> Tags: d-i
> 
> In a preseed file I accidentally had a space before a comment character, which
> caused my preseed to fail in unexpected ways. I could not find anythying that
> stood out in the documentation (e.g.
> https://www.debian.org/releases/buster/amd64/apbs04.en.html or
> https://www.debian.org/releases/stable/amd64/apbs03.en.html) stating that this
> would occur.
> 
> The specific example in my case looked like this:
> 
> #_preseed_V1
> d-i debian-installer/locale string en_AU
> d-i keyboard-configuration/xkb-keymap select us
> d-i keymap select us
> ... etc ...
> # Example of fetching a script to run
>  #d-i preseed/run string http://10.1.2.3/my-script.sh
> 
> 
> My install was hanging and when I entered a console and looked in the syslog,
> it was attempting to access that script for which the IP address does not 
> exist
> on my network. I finally started to understand the problem when I did this, 
> the
> latter finally triggered a parse error in the installer console:
> 
>  #d-iWHATpreseed/run string http://10.1.2.3/my-script.sh
> 
> 
>  #d-iWHATpreseed/runISstringHAPPENINGhttp://10.1.2.3/my-script.sh
> 
> at this point I saw the white space, removed it and the problem went away.
> 
> (I am also unsure whether "d-iWHAT" is also a bug or just some default 
> applying
> if the item owner is not found)
> 
> So I guess that either
> - whitespace is disallowed before a comment character and this should be added
> to https://www.debian.org/releases/stable/amd64/apbs03.en.html - it mentioned
> whitespace between fields but not at the start of a line
> - this is a bug

Well none of the examples ever have spaces before # for comments.
The documentation page you linked to doesn't even mention comments at all.
I would agree that perhaps it should.  I have certainly encountered file
types before where comments had to have # at the start of the line.

-- 
Len Sorensen

Bug#981115: please support multiple compose keys in keyboard-configuration

[Lennart Sorensen]

On Tue, Jan 26, 2021 at 10:33:07PM +0100, Martin wrote:
> On 2021-01-26 14:02, Lennart Sorensen wrote:
> > It is not that simple.
> ...
> > Simply manually putting in the config instead seems like a lot less work.
> 
> Thanks for the investigation, Lennart!
> 
> I probably stay with:
> 
> $ setxkbmap -option compose:caps
> $ setxkbmap -option compose:ralt

You could do them on one line too.

-- 
Len Sorensen

Bug#981115: please support multiple compose keys in keyboard-configuration

[Lennart Sorensen]

On Tue, Jan 26, 2021 at 05:24:14PM +0100, Martin wrote:
> Package: keyboard-configuration
> Version: 1.200
> Severity: wishlist
> 
> It is convenient to have compose keys for both hands, e.g.
> capslock and ralt, similar to the two shift keys.
> 
> When running 
> $ sudo dpkg-reconfigure keyboard-configuration
> users can only select one compose key.
> 
> I assume, that multiple comma separated values would work.

It is not that simple.  While xkboptions supports specifying the compose
option multiple times, it is not a comma separated list.  Right now
the config for keyboard-configuration stores a single value for the
compose key in the debconf database and is able to match that against a
simple switch statement.  If it was changed to a comma separated list,
it would require splitting before being able to match each key against
the switch statement.  The code that turns the compose key value into
the right xkboptions would need to be expanded to handle multiple values
in a loop.  Quite a lot of current assumptions would need to be tossed
away and replaced with code that is quite a bit more complicated.  I am
sure it could be done but I am not sure if anyone would be willing to
put in the effort for something that is probably very rarely wanted.

Simply manually putting in the config instead seems like a lot less work.

-- 
Len Sorensen

Bug#967896: Maybe this is related to this upstream kernel bug

[Lennart Sorensen]

https://bugzilla.kernel.org/show_bug.cgi?id=201813 looks pretty much
the same.  It sounds like it has been fixed in a newer kernel and/or
firmware for the card, but I don't know what the chances of such changes
being backported to the stable kernels are.

-- 
Len Sorensen

Bug#969552: [Help] Re: Bug#969552: phipack: arm64 autopkgtest failure: ERROR: Illegal state encountered: �

[Lennart Sorensen]

On Tue, Sep 08, 2020 at 05:35:45PM -0400, Lennart Sorensen wrote:
> On Tue, Sep 08, 2020 at 10:35:26PM +0200, Andreas Tille wrote:
> > Control: tags -1 help
> > 
> > Hi Debian Arm team,
> > 
> > I admit I have no idea how to deal with this except by excluding
> > arm64 from the list of supported architectures which is definitely
> > not my prefered way of action.
> > 
> > Any help would be really appreciated.
> 
> I don't have access to an arm64 system at the moment, but a good start
> might be to fix the compiler warnings, such as the array subscript out
> of bounds in global.c line 44.  The rest of the warnings appear harmless.
> 
> It would appear that GAP_SIZE = 2 is wrong given GAP[] only contains a
> single character.

I found the actual problem.  Someone didn't know that there are 3 types
of char in C.  char, signed char and unsigned char.  char is _only_ for
use in strings, and never to be used as a numerical value.  This is due
to the sign of char being implementation specific.  On x86 it is signed,
on arm it is unsigned.  So any time you want to work with numerical
values of a char, you must specify if you want signed or unsigned.
Changing char ch to unsigned char ch, made x86 fail the same way arm64
did, and making it signed char, makes both pass the test.

So here is a patch that appears to solve the problems in the code.

-- 
Len Sorensen
diff -ruN phipack-0.0.20160614/src/fasta.c phipack-0.0.20160614.arm64/src/fasta.c
--- phipack-0.0.20160614/src/fasta.c	2016-06-14 00:18:29.0 -0400
+++ phipack-0.0.20160614.arm64/src/fasta.c	2020-09-08 19:08:06.672390326 -0400
@@ -36,7 +36,7 @@
 void read_sequence_name(FILE *in_file,char *name, int capacity)
 {
   int i=0;
-  char ch='\0';
+  signed char ch='\0';
 
   ch=fgetc(in_file);
   if(ch != '>')
@@ -97,7 +97,7 @@
 {
   int bases_read=0;
   int new_limit;
-  char ch;
+  signed char ch;
   char s[250];
   
   ch=fgetc(in_file);
@@ -175,7 +175,7 @@
   int *seq_counter;
   int i;
  
-  char ch;
+  signed char ch;
 
   int cur_seqs;
   int num_seqs=1,new_num;
diff -ruN phipack-0.0.20160614/src/global.c phipack-0.0.20160614.arm64/src/global.c
--- phipack-0.0.20160614/src/global.c	2016-06-13 22:33:15.0 -0400
+++ phipack-0.0.20160614.arm64/src/global.c	2020-09-08 18:04:48.956444973 -0400
@@ -34,7 +34,7 @@
 const int AA_AMBIG_SIZE =2;
 
 const char GAP[] = {'-'};
-const int GAP_SIZE=2;
+const int GAP_SIZE=1;
 
 cbool memberOf(const char *set, const int num, char ch)
 {
@@ -79,10 +79,10 @@
   switch(alignKind)
 {
 case DNA:
-  return (memberOf(DNA_MISSING,DNA_MISSING_SIZE,ch) || memberOf(DNA_AMBIG,DNA_AMBIG_SIZE,ch));
+  return (memberOf(DNA_MISSING,DNA_MISSING_SIZE,ch) || memberOf(DNA_AMBIG,DNA_AMBIG_SIZE,ch)) ? TRUE : FALSE;
   break;
 case AA:
-  return (memberOf(AA_MISSING,AA_MISSING_SIZE,ch) || memberOf(AA_AMBIG,AA_AMBIG_SIZE,ch));
+  return (memberOf(AA_MISSING,AA_MISSING_SIZE,ch) || memberOf(AA_AMBIG,AA_AMBIG_SIZE,ch)) ? TRUE : FALSE;
   break;
 case OTHER:
   if(ch == GLOBAL_MISSING)
diff -ruN phipack-0.0.20160614/src/main.c phipack-0.0.20160614.arm64/src/main.c
--- phipack-0.0.20160614/src/main.c	2016-06-14 00:18:17.0 -0400
+++ phipack-0.0.20160614.arm64/src/main.c	2020-09-08 19:17:18.230153542 -0400
@@ -71,7 +71,8 @@
 
 void get_params(int argc, char**argv, options *opt) 
 { 
-  char *cur,ch,nextch;
+  char *cur;
+  signed char ch,nextch;
   char temp[MAX_SIZE+1];
   int i;
   cbool inFileFound=FALSE;
diff -ruN phipack-0.0.20160614/src/mem.c phipack-0.0.20160614.arm64/src/mem.c
--- phipack-0.0.20160614/src/mem.c	2016-06-13 22:33:15.0 -0400
+++ phipack-0.0.20160614.arm64/src/mem.c	2020-09-08 19:12:52.415278666 -0400
@@ -96,7 +96,7 @@
 
 char ffclose(FILE *handle)
 {
-  char f;
+  signed char f;
   char s[MAX_SIZE+1];
 
   f=fclose(handle);
diff -ruN phipack-0.0.20160614/src/misc.c phipack-0.0.20160614.arm64/src/misc.c
--- phipack-0.0.20160614/src/misc.c	2016-06-13 22:33:15.0 -0400
+++ phipack-0.0.20160614.arm64/src/misc.c	2020-09-08 19:08:28.352322441 -0400
@@ -46,7 +46,7 @@
 
 char skip_all_space(FILE *in_file)
 {
-  char ch;
+  signed char ch;
   
   ch=fgetc(in_file);
   while((ch != EOF) && isspace(ch))
@@ -61,7 +61,7 @@
 
 char skip_newlines(FILE *in_file)
 {
-  char ch;
+  signed char ch;
   
   ch=fgetc(in_file);
   while((ch != EOF) && (ch == '\n'))
@@ -76,7 +76,7 @@
 
 char skip_non_newline(FILE *in_file)
 {
-  char ch;
+  signed char ch;
   
   ch=fgetc(in_file);
   while((ch != EOF) && (ch != '\n'))
@@ -90,7 +90,7 @@
 
 char skip_non_newline_space(FILE *in_file)
 {
-  char ch;
+  signed char ch;
   
   ch=fgetc(in_file);
   while((ch != EOF) && (ch != '\n') && isspace(ch))
diff -ruN phipack-0.0.20160614/src/phylip.c phipack-0.0.20160614.arm64/src/phylip.c
--- phipack-0.0.20160614/src/phylip.c	2016-06-14 00:18:17.0 -0400
+++ 

Bug#969552: [Help] Re: Bug#969552: phipack: arm64 autopkgtest failure: ERROR: Illegal state encountered: �

[Lennart Sorensen]

On Tue, Sep 08, 2020 at 10:35:26PM +0200, Andreas Tille wrote:
> Control: tags -1 help
> 
> Hi Debian Arm team,
> 
> I admit I have no idea how to deal with this except by excluding
> arm64 from the list of supported architectures which is definitely
> not my prefered way of action.
> 
> Any help would be really appreciated.

I don't have access to an arm64 system at the moment, but a good start
might be to fix the compiler warnings, such as the array subscript out
of bounds in global.c line 44.  The rest of the warnings appear harmless.

It would appear that GAP_SIZE = 2 is wrong given GAP[] only contains a
single character.

-- 
Len Sorensen

Bug#826796: Request for a new: linux-image-powerpc64-4K

[Lennart Sorensen]

On Fri, Jun 05, 2020 at 03:08:55PM +0200, John Paul Adrian Glaubitz wrote:
> Is POWER5 still supported by the Linux kernel? I thought IBM removed a
> bunch of older machines but kept PowerPC 970 support.

4.17 dropped power4.  power5 and up are still supported just fine.

-- 
Len Sorensen

Bug#826796: Request for a new: linux-image-powerpc64-4K

[Lennart Sorensen]

On Fri, Jun 05, 2020 at 08:37:02AM +0200, John Paul Adrian Glaubitz wrote:
> I would like to switch the ppc64 kernel back to 4k pages. The majority
> of our users are people on G5 Macs anyway, so I don't see a point
> in using 64k pages.
> 
> Anyone with a large modern POWER machine is going to run the ppc64el
> port anyway.

Only power8 and newer can run ppc64el, so all power 5, 6 and 7 users
would still need to run be.  But there are probably a lot less than of
G5 users.  And most people with work loads that have a use for 64k pages
are probably on newer machines too.

-- 
Len Sorensen

Bug#942128: installation-guide-amd64: security apt resource

[Lennart Sorensen]

On Thu, Oct 10, 2019 at 07:50:33PM +0200, Pavel Kosina wrote:
> Package: installation-guide-amd64
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> In installation of debian 10, testing, there is bad entry to
> /etc/apt/sources.list - installation procedure reports error when trying
> contact old security repository (up to 9).
> 
> The instalation procedure should use the new one:
> deb http://security.debian.org testing-security main contrib non-free
> deb-src http://security.debian.org testing-security main contrib non-free
> 
> Thank you.
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), 
> LANGUAGE=cs_CZ.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Did you mean Debian 11 (Buster is 10 and is stable release right now)?

-- 
Len Sorensen

Bug#935931: Re: Bug#935931: debian-installer: Reinstalling Debian on a current Debian installation without erasing or fomatting the home folder

[Lennart Sorensen]

On Mon, Sep 30, 2019 at 12:51:33PM -0400, Daniel wrote:
> Dear Lennart,
> 
> I hope that when one opens a "whishlist bug" at least there is a chance to
> have a confrontation.
> 
> The main point I want to address is when you do a "smart installation" it is
> supposed to perform a clean installation hence the only folder that must to
> be untouched is "/home". The same concept when you have "/" and "/home" in
> separated partitions and you perform a clean installation. I think that is
> pretty trivial, the smart parts are:
> 
> * the installer is able to check for a previous Debian installation before
> to begin the process;
> 
> * and in case it founds a previous installation, the installer, is able to
> perform a fresh installation without overwriting the "/home" folder.

Well I believe you have the option to not format a mountpoint during
the install already, so at least that part should be pretty easy.

> I can confirm that ElementaryOS and POP!_OS, that share the same installer,
> can do that.

Well hopefully someone will try to contribute that then.  I suspect the
main thing is finding someone that wants to implement it and do the work
to add it and maintain it.

> Last point I want touch is about the swap partition. With the SSD and the OS
> able to boot in a bunch of seconds the hibernation doesn't make any sense
> today. For example I have 16GB of ram, based on the standard rules I should
> use at least 1.5x of the ram if not the double. It means that I should use
> 32GB just to hibernate my session, no way... With the SSD disks the lesser
> you write on the disk the better, I put just 2GB of swap-file and
> "swappiness" at 1 and the swap is never used and I didn't waste 30GB of
> space.

Only advantage to huibernation is not having to close all the things
you are working on and opening them again after the next boot.  I do
find hibernation takes too long with a lot of ram and hence never do it
myself. :)

> To conclude I think I elaborated everything clearly, I see a lot of benefits
> and improvement with the suggestions I gave to Debian, I also think that are
> pretty trivial to implement. I don't want introduce a Windows behavior of
> "reinstall when it broken", but back to time when I hadn't a fast internet
> connection it was faster download the full ISO and performing a fresh
> installation rather than doing a "dist-upgrade".

I remember upgrades over dial up.  Still did not make me want to go
download full iso images elsewhere.  It could do it while I slept.
Things have gotten a lot bigger since then though.  I have seen people
keep a subset mirror of Debian on a USB drive that they would update with
rsync once in a while at work, and bring home to use for upgrades where
the connection was slow.  Still in place upgrades of course, not using
the installer.

> The bottom line is with a smart installer you don't need to separate your
> disk(s) in partitions but you can throw everything in "/" including the
> "swap" as swap-file that you can modify freely based on your needs (if you
> can't live without hibernation[1]). There is also a dynamic swap manager
> available on Debian as well: https://github.com/Tookmund/Swapspace

-- 
Len Sorensen

Bug#935931: Re: Bug#935931: debian-installer: Reinstalling Debian on a current Debian installation without erasing or fomatting the home folder

[Lennart Sorensen]

On Sat, Sep 28, 2019 at 11:27:29PM -0400, Daniel wrote:
> Hi Nicholas,
> 
> thanks for your reply, I really appreciated your constructive approach.
> 
> I use Debian since 2007 and I did a lot of installation, I personally use a
> FrankenDebian (testing with pinning toward SID and Experimental) however
> when I install Debian on other machines I install definitely the current
> stable available. I have been performing exclusively desktop installations
> and while I consider the best option separating /home recently I found
> myself not able to get the right balance between "/", "/home" and "swap".
> The default "/" assigned is often too small while sometimes I wasted
> gigabyte never used. The "swap" with the amount of ram available today is
> always more accessory and with the SSD disk the trend is to reduce its use
> the most. Eventually I stopped to create a "swap" partition in favor of a
> "swap-file" (like Raspian e.g.); hence I also stopped to create "/" and
> "/home" but just "/" and still as LVM; at this point you don't have anymore
> issue with the space and if you need you can add all the disks you want
> because it is still a LVM partition.
> 
> Now the case I am figuring out is the one you didn't separe "/" and "/home"
> (however the installer is still creating "swap") but you need to reinstall
> Debian because you screwed it up for some reason. Now a smart installer
> before to start everything takes its time to check the disk and discovers
> that you have, along a crypted disk and a LVM group, also a previous version
> of Debian hence check the users and it asks you if you want keep all the
> users, just one, etc... and then it reinstalls the system and recovers the
> setting from the user(s) you selected, without creating a FrankenDebian but
> just a fresh and **smart** installation.
> 
> This leads in my opinion in creating a further voice for the Debian install:
> **the desktop installation**; Standard and Advanced are eventually too
> generic and do not target properly the desktop cases. If the D-I was
> properly able to read LUKS and LVM during the installation time, and if was
> also able to perform a smart installation as described in the paragraph
> above, a Desktop installation should be:
> 
> 1. Create an encrypted partition by default (LUKS + LVM);

I rarely do that, but I can see why some people want it.

> 2. install everything in / ;

I do tend to prefer that for most setups myself.

> 3. not create a "swap partition" but a swap-file.

My understanding is that suspend to disk works much easier with a swap
partition still, but my information could be out of date on that.
And of course swap smaller than ram makes suspend to disk not possible.

> I also add that:
> 
> 4. should deactivate root user by default, which is now considering a best
> practice;

Not sure I agree it is considered best practices.  A lot of distributions
do it, but not all.  I do prefer root login to work from the console if
I have to fix something.

> 5. should deactivate the source repos and asking to activate the "contrib"
> and "non-free" repos (like in Advanced Mode).
> 
> 
> I don't see any complicated tasks to achieve, others Linux distro already
> started to move in this direction while other *nix operative systems already
> do that since a long time.

Other distributions (Certainly the case for redhat based stuff in the
past) had to do it since they didn't have a working in place upgrade.
That rather makes it required that the installer can do an upgrade and
detect existing settings.  Debian seems to have always aimed for an in
place upgrade that worked, so the installer really only had the purpose
of the initial install.  It's one of the things that made me switch to
Debian over 20 years ago.  I have never had to do a reinstall of a Debian
system except on a machine that lost the disk and I didn't have a backup
of it (nothing important was kept on that system).  I really should
have replaced that other disk in the RAID1 within a reasonable amount
of time. :)

> The only issues I see here are the resistance to the changes and the fact
> that actually the D-I has some issue to recognize the encrypted partitions
> and if you want reinstall Debian you can't preserve any of the partitions
> you want because it will consider the encrypted disks as blanks.

Collecting all those settings does not sound like a trivial job, and based
on the normal use case of a Debian install, I sure don't see the value
in it.  How do you even decide which settings should be preserved and
which should not?  What if one of the settings is what broke your system?
If you screw up the system, go fix it.  You will learn something from it.
Blowing away the system and installing it again means you learn nothing,
waste a bunch of time, and will likely do it again in the future.  I have
certainly broken my installs over the years and had to fix it, but it has
always been possible.  Running unstable and experimental stuff at times

Bug#929752: Changing quote signs in GPL allowed? [Was: Bug#929752: installation-guide: left quotes in gpl.xml are not correctly rendered in pdf ]

[Lennart Sorensen]

On Tue, Aug 06, 2019 at 08:30:56PM +0200, Holger Wansing wrote:
> I was about to commit these changes, however it came to my mind if such
> changes to the GPL are allowed?
> 
> At least the English variant of the GPL is 'official' and is not to be
> changed, so what about changing the quoting signs into   
> entities?

gpl.xml isn't official.  It isn't one of the files from the FSF.
There is a gpl-2.0.dbk[1] version available which in fact does use 
and  while every other file format uses ` and '.  So at least
there is precedence for using  tags instead.  After all if you
decided to use the docbook file as your source text, you would get the
quotes desired.

[1] https://www.gnu.org/licenses/old-licenses/gpl-2.0.dbk

-- 
Len Sorensen

Bug#929476: Debian 9 installation.

[Lennart Sorensen]

On Fri, May 24, 2019 at 11:10:43AM +0200, mb wrote:
> Package: installation-reports
> 
> Boot method: USB pen drive prepared in Windows10 with RUFUS (MBR, GPT, iso, 
> dd: always same problem) or with UBUNTU 18 dd command
> Image version: 
> https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/debian-9.9.0-amd64-DVD-1.iso
>   
> 
> Date: from 19 May to 24 May 2019
> 
> Machine: Acer spin 3
> Processor: I3
> Memory: 8 GByte
> Partitions: unallocated 52 GByte on sdd disk for dual boot with Windows10 Home
> 
> Output of lspci -knn (or lspci -nn):
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O ]
> Detect network card:[ ]
> Configure network:  [ ]
> Detect CD:  [E ]
> Load installer modules: [ ]
> Detect hard drives: [ ]
> Partition hard drives:  [ ]
> Install base system:[ ]
> Clock/timezone setup:   [ ]
> User/password setup:[ ]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[ ]
> 
> Comments/Problems:
> 
> The installation in Graphic mode after the language, country and locales 
> stops because cannot find the CD.
> It is not clear what is such "CD"? All installation software isn't in 
> thedebian-9.9.0-amd64-DVD-1.iso  
> 
>   file loaded on the USB pen drive?
> 
> Googled a lot, it seems most of people face a lot of trouble with Debian 
> installation but no solutions available.
> Is this Debian only for very expert users? I'm Using UBUNTU since 2012, even 
> when I was a complete newbie I succeed into dual boot installation,
> With Debian it seems I have to spend months for learning very advanced 
> knowledge or gathering information.
> I understood Debian was an operating  system accessible to everybody not 
> dedicated to very specialized Information technology people only.

Most people don't have a problem installing.  Of course searching will
mostly find the people that did have problems since people without
problems usually don't post anything to say "everything worked fine".

That laptop is very new and it is possible some part of the hardware
isn't supported by the kernel in Debian 9.  It was released in 2017
after all, quite a bit before that laptop existed.

You could try the installer for testing (The Debian 10 in development
right now) to see if that works better.  I suspect Debian 10 will make
it out sometime this year.

-- 
Len Sorensen

Bug#925556: UEFI or not, can't mount /dev

[Lennart Sorensen]

On Tue, Mar 26, 2019 at 07:13:21PM +, Steve McIntyre wrote:
> On Wed, Mar 27, 2019 at 02:58:36AM +0800, 積丹尼 Dan Jacobson wrote:
> >Package: debian-installer
> >
> >Guess what, seen with ASUS X370-A:
> 
> Dan, you know better than this. A useful bug report needs much more
> information. For a start, what image did you use to install with? This
> looks like it *might* be on first boot after installation, but you're
> leaving me to guess at that. How did you partition, etc.? Were there
> any errors reported during installation?
> 
> Please help us to help you...

Well the picture appears to show root is sdb2 on a disk with sdb1 and
sdb2 partitions, and it can't mount /dev apparently because there is no
/dev directory on the root filesystem to mount it on.

At least that's what it looks like in the picture.

Clearly the initramfs was able to mount /dev and run fsck, but mounting
it to /root/dev to transfer to the real rootfs failed due to a missing
directory.

-- 
Len Sorensen

Bug#838503: debian-installer: mdadm should not start syncing RAID1 arrays at full speed during installation

[Lennart Sorensen]

On Fri, Dec 07, 2018 at 12:22:38AM +, Steve McIntyre wrote:
> I've no idea why he things this is a regression. But this is something
> we should probably change anyway - installing on RAID is pointlessly
> slow here unless you know how to work around it. And it's been that
> way since ~forever.

For some reason I thought the limit used to be lower many years ago,
but I can't find any evidence of that.  Certainly the 20 max is a
default in the kernel since before it moved to git.  Perhaps the kernel
changed at some point and is more aggresive in going to the max than it
used to be?

But yes, I also think having the limit lower in the installer makes sense.
You are not protecting anything valuable yet at that point and would
like to get your system ready to use as soon as possible.

-- 
Len Sorensen

Bug#905793: Why does the Installer formats given swap

[Lennart Sorensen]

On Fri, Aug 10, 2018 at 10:08:52AM +0200, Herbert Kaminski wrote:
> Am Thu, 9 Aug 2018 14:14:15 -0400
> schrieb lsore...@csclub.uwaterloo.ca (Lennart Sorensen):
> 
> > [...] 
> > Well 99.9% of installs don't have another linux on the system, 
>^
> Interesting. How did you get that figure?

Totally made it up. :)

I suspect I guessed low in fact.

-- 
Len Sorensen

Bug#905793: Why does the Installer formats given swap

[Lennart Sorensen]

On Thu, Aug 09, 2018 at 07:37:15PM +0200, John Landmesser wrote:
> Package: debian-installer
> 
> 
> is there a reason why the installer defaults to format given swap partition?
> 
> I now know that you can opt out to format swap, but i don't understand that
> formatting swap is default!
> 
> I had several Linux on same PC and after installing aditional debian, the
> other Linux didn't find their swap anymore because UUID has changed.
> 
> I fixed it but i thought: "Debian, that should be a no go, formatting given
> swap"
> 
> So i'm curious for the reason for this behaviour!

Well 99.9% of installs don't have another linux on the system, so any
swap partition would be a new one that you just created, so you want
it formatted, or it wouldn't be used.

Maybe it would be possible to make it default to not format a swap
partition if that partition already exists and isn't being created
from scratch.

The installer at least has the option to not format it for the extremely
unusual case of wanting to reuse an existing swap partition.

-- 
Len Sorensen

Bug#891615: Upstream's thoughts

[Lennart Sorensen]

I found this:

https://bugs.freedesktop.org/show_bug.cgi?id=66722

Seems to indicate they have no intention of supporting python3 since
they believe it can be used from python3 in a different way already.

So semms they think the answer in python3 is to use GObject Introspection
(GIR)

-- 
Len Sorensen

Bug#888515: debian-installer: UEFI boot menu (grub) misses the help screen

[Lennart Sorensen]

On Fri, Jan 26, 2018 at 05:16:38PM +0100, Samuel Thibault wrote:
> Hello Grub maintainers, any idea about this?

Is this too much of a hack:



menuentry ' ' {true}
menuentry 'Help:' {true}
submenu '  Prerequesites for installing Debian.' {
menuentry 'PREREQUISITES FOR INSTALLING DEBIAN' {true}
menuentry ' ' {true}
menuentry 'You must have at least 105 megabytes of RAM to use this 
Debian' {true}
menuentry 'installer.' {true}
menuentry ' ' {true}
menuentry 'You should have space on your hard disk to create a new disk 
partition' {true}
menuentry "of at least 680 megabytes to install the base system.  
You'll need more" {true}
menuentry 'disk space to install additional packages, depending on what 
you wish' {true}
menuentry 'to do with your new Debian system.' {true}
menuentry ' ' {true}
menuentry 'See the Installation Guide or the FAQ for more information; 
both' {true}
menuentry 'documents are available at the Debian web site, 
http://www.debian.org/' {true}
menuentry ' ' {true}
menuentry 'Thank you for choosing Debian!' {true}
}
submenu '  Boot methods for special ways of using this CD-ROM' {
menuentry 'BOOT METHODS' {true}
menuentry ' ' {true}
menuentry 'Available boot methods:' {true}
menuentry ' ' {true}
menuentry 'installgui' {true}
menuentry '  Start the installation using the graphical installer -- 
this is the' {true}
menuentry 'install' {true}
menuentry '  Start the installation using the text mode installer' 
{true}
menuentry 'expertgui' {true}
menuentry '  Start the installation in expert mode, for maximum 
control, using' {true}
menuentry '  the graphical installer' {true}
menuentry 'expert' {true}
menuentry '  Start the installation in expert mode using the text mode 
installer' {true}
}

Obviously the text has to be corrected I just copied from isolinux pages
as an example.

-- 
Len Sorensen

Bug#888513: huge graphical bug

[Lennart Sorensen]

On Fri, Jan 26, 2018 at 04:21:08PM +0100, melissa M. wrote:
> Package: debian-installer
> Version: stable
> Severity: grave
> 
> hi maintainer,
> 
> big graphical bug with the installer netinstall of Debian Stretch 9.3, but
> also Testing and Sid.
> 
> Ditto with the installer mini iso-Stretch 9.3
> 
> I created my bootable usb drive with "dd", unetbootin, etcher, but the big
> graphical bug still present :(
> 
> I have a laptop pc Toshiba Satellite P870-338 with the Optimus technology
> (graphics chipset intel i7 3630qm and nvidia GT 630m) with a bios 100% uefi
> 
> this is the screen that I get with the installer, it is impossible to
> install in these conditions.
> http://pix.toile-libre.org/upload/original/1516915180.jpg
> 
> I think I might be an isolated case, but I still haven't found solution to
> resolve this bug very annoying.
> 
> the bug has been present since two years...
> 
> is there a workaround ??
> a parameter to pass to the kernel ??
> 
> this bug est present on the mini iso, and the iso netinstall (testing,
> stable and sid). :'(
> 
> please consider my bug report.

Does it happen in both graphical and text mode install?

-- 
Len Sorensen

Bug#881626: busybox: enable telnetd

[Lennart Sorensen]

On Tue, Nov 14, 2017 at 06:59:41PM +, Holger Levsen wrote:
> you are aware that this would only cause (these) people to switch away
> from Debian, but not from telnet?

I honestly believe they just haven't tried.  As long as you indulge them,
they will keep training new people with bad habits.  It won't go away
until you make it go away.  Sometimes you really do have to tell
people no.

> also, I miss your removal requests for the telnetd and ftpd and
> (countless) other packages.
> 
> to the original poster: what's wrong with installing telnetd? its only
> 103kb in size...

Well at least in a separate package you don't accidentally get it just
by installing busybox.

-- 
Len Sorensen

Bug#881626: busybox: enable telnetd

[Lennart Sorensen]

On Mon, Nov 13, 2017 at 05:16:26PM +, Luca Boccassi wrote:
> Package: busybox
> Version: 1.27.2-1
> Severity: wishlist
> Tags: patch
> 
> Dear Maintainers,
> 
> Please consider enabling telnetd in the busybox package. A tiny and
> trivial patch to set the config is attached inline. A rebuild with that
> change seems to work fine.
> 
> As much as I wish it wasn't the case, telnet is still widely used,
> especially in the ISP/telco world. Telcos networking engineers expect
> to be able to telnet into boxes in their network even today.
> 
> Having telnetd available without having to rebuild busybox would be
> extremely handy when using Debian (or derivatives) in small boxes (eg:
> arm64) inside a telecommunication provider's network.

Anything that makes it more work for you and hence gives more incentive
for you to get the clueless people that want to keep using telnet to
change is a good thing.  Allowing telnet access ought to be made as
difficult as possible.

People have been saying to not use telnet for about 20 years now.
They better have learned by now.

-- 
Len Sorensen

Bug#878722: bts reassign 878722 partman-auto

[Lennart Sorensen]

On Fri, Nov 10, 2017 at 04:19:14PM +, Ben Hutchings wrote:
> This is true, but I don't think it's a good reason not to implement a
> mostly-reliable heuristic.
> 
> If there are multiple disks, there are usually going to be just 2 of
> them, one of which contains the installer.  In any installer build
> other than netboot, it will look for its own disk in order to load
> udebs.  Once it has done that, it can determine that the other disk is
> the one to install on.  That's a pretty good heuristic.

I think more than one disk in the machine isn't that unusual.

> Aside from that, we can also make a guess based on the bus type:
> 
> - ATA: probably internal

eSATA is not that unusual.

> - NVMe: probably internal
> - USB: probably external
> - MMC/SD: ambiguous (eMMC must be internal, and Linux has a notion of
> 'non-removable' slots, but I don't think userland has this info)
> 
> If we could get more information about MMC/SD slots then we should be
> able to implement an heuristic that would work for >99% of cases.

You can certainly try to make a good guess, but it certainly still needs
to be confirmed.

-- 
Len Sorensen

Bug#878722: bts reassign 878722 partman-auto

[Lennart Sorensen]

On Tue, Nov 07, 2017 at 09:56:31PM +0100, Michael Kesper wrote:
> Yes sure but why can't I correct it after the fact?
> Even "rescanning disks" does not let you chose any other disks.
> 
> Is there a way of chosing "first internal disk" then?
> Imagine I want to create one installation medium for laptops which only
> differ whether they are set up with a NVM or a sata SSD.
> I did not find any documentation helping me with this.

I can't think of any reliable way to determine what is an internal or
external disk, and the concept of 'first' doesn't even have meaning.

-- 
Len Sorensen

Bug#879895: Other error

[Lennart Sorensen]

I do get this error when using 5.1.30 at the moment:

VBoxClient: VBoxClient (seamless): failed to start.  Stage: Setting guest IRQ 
filter mask  Error: VERR_INTERNAL_ERROR

But that is with 5.2.0 guest utils and 5.1.30 dkms.  Maybe not a good
combination to have installed.

-- 
Len Sorensen

Bug#879895: Still broken

[Lennart Sorensen]

I still get the same unpin error with 5.2.0-dfsg-2.  So vboxvideo still
crashes when X starts.

5.1.30-dfsg-1 is fine.

-- 
Len Sorensen

Bug#879895: Really broken

[Lennart Sorensen]

If you force vboxvideo to build by editing the makefile, you get a
file that crashes when you try to use it.  Going back to 5.1.x works
fine however.

There error given is:

kernel: [   17.290464] [drm:vbox_bo_unpin [vboxvideo]] *ERROR* unpin bad 
8f5597836400

So somehow the 5.2.0 version is just plain broken it seems.

-- 
Len Sorensen

Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

On Thu, Sep 28, 2017 at 01:49:50AM +0300, Adrian Bunk wrote:
> What compile times exactly did you measure?
> 
> The numbers I got are:
> -O0: 11s
> -O1: 82m
> -O2: 249m

Maybe I did it wrong and failed to change the flag then.  I must admit
I did find it odd that I saw no change in time between -O1 and -O2.

> The following builds for me easily within the 150m time limit:
> 
> --- debian/rules.old  2017-09-27 18:38:24.225620119 +
> +++ debian/rules  2017-09-27 18:40:59.878867203 +
> @@ -1,6 +1,13 @@
>  #!/usr/bin/make -f
>  # -*- makefile -*-
>  
> +DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
> +
> +# work around the #861281 gcc >= 6 compile time regression on 32bit arm
> +ifneq (,$(findstring $(DEB_HOST_ARCH), armel))
> +export DEB_CFLAGS_MAINT_APPEND = -O1
> +endif
> +
>  export DEB_BUILD_MAINT_OPTIONS=hardening=+all
>  
>  %:

That seems like it should work well.

-- 
Len Sorensen

Bug#876825: Seems it is not really an infinite loop

[Lennart Sorensen]

I just tried with the gcc 7.2.0 cross compiler.  It took 28 minutes to
compile the file but it did finish.  It took 5 times the ram and 30
times the time that it took to compile for amd64.  It was not stuck,
just doing a lot of work trying to optimize it seems.

Fixing the causes of the warnings has no impact on the compile time,
which is not really surprising.

-- 
Len Sorensen

Bug#849400: debian-installer: LUKS on rootfs and boot

[Lennart Sorensen]

On Wed, Sep 27, 2017 at 01:47:52PM +0200, Ben Hutchings wrote:
> DO NOT use a fat32 partition for /boot!
> 
> It will appear to work, but the first upgrade of a package that
> installs into /boot will fail because dpkg cannot create a hard link
> there.

Maybe /boot/efi was what was meant.

-- 
Len Sorensen

Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

On Wed, Sep 27, 2017 at 04:39:39PM +0200, Andreas Tille wrote:
> I realised that the first patch was included but I considered it better
> to split it into two.

All good.

> To make things really clear for me: Edmund suggested another upload
> with only -O1 (how can I make sure that -O1 is used only on armel?)
> but your suggestion seems to affect the autobuilder which means for
> me: "Wait until we tell you something else."  Is this correct?

I tried with -O1 and it did not make any noticeable reduction in compile
time, so don't bother.  The only option for this package is to increase
the timeout on armel.  It needs that much time.

-- 
Len Sorensen

Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

On Tue, Sep 26, 2017 at 08:43:32PM +0200, Andreas Tille wrote:
> Hi Lennart,
> 
> thanks again for your analysis of the code.
> 
> To summarise:  We should go with the patch you suggested originally
> 
>
> https://anonscm.debian.org/git/debian-med/rnahybrid.git/tree/debian/patches/fix_loop_index.patch
> 
> to fix the bug and in addition the warnings will be fixed in
> 
>
> https://anonscm.debian.org/git/debian-med/rnahybrid.git/tree/debian/patches/fix_warnings.patch

Well my second patch included the first, but splitting them makes
sense too.

You also have to increase the allowed timeout for the package on armel.
It really is making progress and really does take that long to compile
but it will finish given the needed time.  Not sure just how much time,
but I would suggest trying a timeout of 300 minutes instead of 150.
Once it succeeds you will know what the real build time is.

> I'll be able to run the test suite on amd64 and also one arm64 box
> I own.

-- 
Len Sorensen

Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

On Tue, Sep 26, 2017 at 08:19:59PM +0100, Edmund Grimley Evans wrote:
> It's a possibility to bear in mind, definitely, but the
> perhaps-infinite loop can be observed with a cross-compiler:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876825

I just tried doing the cross compile manually, and it does actually
complete, but it takes MUCH longer than the native x86 compile.  So at
least with gcc 7.2.0 it is NOT an infinite loop, it just looks like it.

On this machine it takes about 50 seconds to compile energy.c for amd64,
and it takes the cross compiler 25 minutes to compile energy.c for armel.
It also used 660MB ram, while the amd64 compile only used 150MB.
Maybe the extra registers on arm is making the compiler try a lot more
optimization possibilities with all the loops.

So I can see how the armel build machine is timing out.  Also it means
gcc does NOT have an infinite loop bug, at least not in 7.2.  I suspect
gcc 6 didn't either.

> (I will test with the compilers in unstable, as requested, if no one
> else gets there first.)

Well I tried as you can see.

> I don't think the buildds report memory usage, but the time is 150 minutes:
> 
> https://buildd.debian.org/status/logs.php?pkg=rnahybrid=armel

So the build timeout is too short for this package on that build machine
with the way gcc optimizes now.

-- 
Len Sorensen

Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

On Tue, Sep 26, 2017 at 02:09:56PM -0400,  wrote:
> On Tue, Sep 26, 2017 at 07:30:40PM +0200, Andreas Tille wrote:
> > Hi Marc,
> > 
> > thanks for the quick response.
> > 
> > On Tue, Sep 26, 2017 at 06:45:42PM +0200, Marc Rehmsmeier wrote:
> > > Hi Andreas,
> > > 
> > > I am not entirely sure what I was doing there and then. That seems to be 
> > > version 2.1.2, correct?
> > 
> > Yes, that's correct.  We always try to package the latest upstream
> > 
> > 
> > > In version 2.1.1, the array is allocated with ALPHASIZE+1. The <= in the 
> > > k-loop is originally not a mistake; the function's sibling, 
> > > init_dl_dangle_dg_ar, has the <= in the first loop (the i-loop). These 
> > > are the allocations in version 2.1.1:
> > > 
> > > double dr_dangle_dg_ar[ALPHASIZE][ALPHASIZE][ALPHASIZE+1];
> > > double dl_dangle_dg_ar[ALPHASIZE+1][ALPHASIZE][ALPHASIZE];
> > > 
> > > You see that there's a +1 on the corresponding sides.
> > 
> > Yes, I see.  Would you like to express that the better fix for that
> > issue would be to restore this allocation inside energy.h instead of
> > fixing the loop index?
> 
> So someone broke the allocation size in 2.1.2?
> 
> Seems like a valid fix too, especially if there is some actual use for
> the extra slot.
> 
> > > At some point I introduced an additional letter to the alphabet, the X (a 
> > > masking letter; see input.h). I am not sure about the program logic 
> > > anymore, whether X can actually be used for lookups in the energy tables 
> > > (as the N could). In hybrid_core.c, where the energy functions are used, 
> > > I check for X in a few places, so the idea was perhaps to not use X for 
> > > lookups (in fact, I do not want to consider any masked sequence at all). 
> > > Should that be true, ALPHASIZE being 6 would be wasteful, but it 
> > > shouldn't harm otherwise. Of course, you could change the two for-loops 
> > > (the k-loop in init_dr_dangle_dg_ar and the i-loop in its sibling) so 
> > > that they use < instead of <=, but, while that might fix the array bound 
> > > bug, it might not solve an underlying logic problem. In effect you might 
> > > have a program that works technically, but produces the wrong result. 
> > > Unfortunately I can't help with that. You could try fixing the loops and 
> > > then do a few runs and compare the outputs, as a minimal test.
> > 
> > So it seems to me that it is safer to leave the loop untouched ...
> 
> Makes sense if the energy.h is fixed instead.

Of course it seems the change was a number of places.  ALPHASIZE was
changed from 5 to 6, which removed the need for the +1 in a number of
places, but of course makes the arrays a chunk larger.

I think in fact just fixing the two places that initialize the array to
0 to not have the <= is in fact the safer option since that will match
the allocation.  Everywhere else that had to deal with the +1 seems to
have already been changed in 2.1.2 to match ALPHASIZE now being 6.

Of course the larger arrays might have something to do with why the
compile takes a bit longer than before.  But that could also just be a
gcc change.

-- 
Len Sorensen

Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

On Tue, Sep 26, 2017 at 07:30:40PM +0200, Andreas Tille wrote:
> Hi Marc,
> 
> thanks for the quick response.
> 
> On Tue, Sep 26, 2017 at 06:45:42PM +0200, Marc Rehmsmeier wrote:
> > Hi Andreas,
> > 
> > I am not entirely sure what I was doing there and then. That seems to be 
> > version 2.1.2, correct?
> 
> Yes, that's correct.  We always try to package the latest upstream
> 
> 
> > In version 2.1.1, the array is allocated with ALPHASIZE+1. The <= in the 
> > k-loop is originally not a mistake; the function's sibling, 
> > init_dl_dangle_dg_ar, has the <= in the first loop (the i-loop). These are 
> > the allocations in version 2.1.1:
> > 
> > double dr_dangle_dg_ar[ALPHASIZE][ALPHASIZE][ALPHASIZE+1];
> > double dl_dangle_dg_ar[ALPHASIZE+1][ALPHASIZE][ALPHASIZE];
> > 
> > You see that there's a +1 on the corresponding sides.
> 
> Yes, I see.  Would you like to express that the better fix for that
> issue would be to restore this allocation inside energy.h instead of
> fixing the loop index?

So someone broke the allocation size in 2.1.2?

Seems like a valid fix too, especially if there is some actual use for
the extra slot.

> > At some point I introduced an additional letter to the alphabet, the X (a 
> > masking letter; see input.h). I am not sure about the program logic 
> > anymore, whether X can actually be used for lookups in the energy tables 
> > (as the N could). In hybrid_core.c, where the energy functions are used, I 
> > check for X in a few places, so the idea was perhaps to not use X for 
> > lookups (in fact, I do not want to consider any masked sequence at all). 
> > Should that be true, ALPHASIZE being 6 would be wasteful, but it shouldn't 
> > harm otherwise. Of course, you could change the two for-loops (the k-loop 
> > in init_dr_dangle_dg_ar and the i-loop in its sibling) so that they use < 
> > instead of <=, but, while that might fix the array bound bug, it might not 
> > solve an underlying logic problem. In effect you might have a program that 
> > works technically, but produces the wrong result. Unfortunately I can't 
> > help with that. You could try fixing the loops and then do a few runs and 
> > compare the outputs, as a minimal test.
> 
> So it seems to me that it is safer to leave the loop untouched ...

Makes sense if the energy.h is fixed instead.

-- 
Len Sorensen

Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

On Tue, Sep 26, 2017 at 12:21:20PM -0400, Lennart Sorensen wrote:
> Here is a patch that removes all the warnings I see.  Maybe that will
> help.  I don't have an armel to test on.
> 
> Most of the warnings are due to missing #include in a lot of places.

The failure in build may in fact just be because the build machine is
too slow.

The file it timed out on takes almost 1 minute to compile on a 2GHz x86.
That one file is about 90% of the total build time of the package.

How long does it take on the armel build box and how much memory does
it use while doing it?  My x86 hit close to 150MB for the cc1 process
on that file.  Memory bandwidth could possible affect the compile time
on that file a lot.

So perhaps the real answer is that the timeout on this package needs
to be increased, or it should only be built on the fastest of the
armel build machines.

The energy.c file is over 12000 lines long and contains massive nested
loops that the optimizer is probably trying to do nice things to.

I highly doubt there is a bug in gcc, or any infinite loop.  Just gcc
is trying harder to optimize than it used to, and the timeout is too low.

I would be very surprised if a manual attempt to build it on armel would
not succeed, although you are probably looking at 4 hours to do it.

-- 
Len Sorensen

Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

On Tue, Sep 26, 2017 at 05:48:40PM +0200, Andreas Tille wrote:
> Hi Lennart,
> 
> thanks for your suggestions.  I hereby will forward it upstream hoping
> for comments.

Here is a patch that removes all the warnings I see.  Maybe that will
help.  I don't have an armel to test on.

Most of the warnings are due to missing #include in a lot of places.

-- 
Len Sorensen
diff -ur rnahybrid-2.1.2.orig/src/energy.c rnahybrid-2.1.2/src/energy.c
--- rnahybrid-2.1.2.orig/src/energy.c	2013-08-25 11:51:20.0 -0400
+++ rnahybrid-2.1.2/src/energy.c	2017-09-26 11:04:34.747986466 -0400
@@ -536,7 +536,7 @@
 void init_dr_dangle_dg_ar()
 {
   int i,j,k;
-  for(i=0;i

Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

On Tue, Sep 26, 2017 at 09:57:09AM +0100, Edmund Grimley Evans wrote:
> The infinite loop is still there with gcc-7. I've created bug #876825.
> 
> Before you exclude armel, you could perhaps try doing something about
> this warning, which is given not just on armel and may or may not be
> related to the compiler going into an infinite loop:
> 
> energy.c:539:104: warning: iteration 6 invokes undefined behavior
> [-Waggressive-loop-optimizations]

Is it because of this:
energy.c:539:53: note: within this loop
   for(i=0;i There are other warnings, too, but undefined behaviour is particularly scary.

The pointers being converted to integers concern me a bit.  That might
cause big problems on 64 bit systems.

It sure looks like some seriously sloppy coding.

-- 
Len Sorensen

Bug#870628: Please warn about slow starts on USB

[Lennart Sorensen]

On Thu, Aug 03, 2017 at 07:55:09PM +0200, Samuel Thibault wrote:
> The gtk initrd is like 38MB, at USB 1.0 speed (1.5Mbps) that's almost
> two minutes yes.  I however wonder how old a computer needs to be to be
> only 1.0...

I have never seen a machine with only 1.0 USB that could boot from USB.
I don't think the concept of booting from USB existed until we had USB 2.
It was just too slow to comprehend trying.

And how could a 64bit machine have only USB 1.0?  Not a chance.

Now if the USB key happens to be a Kingston Datatraveller G3 like the
one on my desk, then I can believe it taking forever and crashing.
That thing is an unreliable piece of crap that somehow claims to be USB3.

-- 
Len Sorensen

Bug#868994: text too small to read on text based installer on high resolution screen

[Lennart Sorensen]

On Thu, Jul 20, 2017 at 11:30:26AM +1000, Jason Lewis wrote:
> Package: installation-reports
> 
> Boot method: usb stick
> Image version:
> http://saimei.ftp.acc.umu.se/cdimage/unofficial/non-free/cd-including-firmware/9.0.0+nonfree/amd64/iso-cd/firmware-9.0.0-amd64-netinst.iso
> Date: 2017-07-20
> 
> Machine: Dell Precision 5520
> Processor: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
> Memory: 32gb
> Partitions: n/a
> 
> Output of lspci -knn (or lspci -nn):
> 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5910] (rev 05)
> Subsystem: Dell Device [1028:07bf]
> 00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe Controller
> (x16) [8086:1901] (rev 05)
> Kernel driver in use: pcieport
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Device
> [8086:591b] (rev 04)
> Subsystem: Dell Device [1028:07bf]
> 00:04.0 Signal processing controller [1180]: Intel Corporation Skylake
> Processor Thermal Subsystem [8086:1903] (rev 05)
> Subsystem: Dell Device [1028:07bf]
> 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H USB 3.0
> xHCI Controller [8086:a12f] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> Kernel driver in use: xhci_hcd
> Kernel modules: xhci_pci
> 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise
> Point-H Thermal subsystem [8086:a131] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise
> Point-H Serial IO I2C Controller #0 [8086:a160] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise
> Point-H Serial IO I2C Controller #1 [8086:a161] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:16.0 Communication controller [0780]: Intel Corporation Sunrise
> Point-H CSME HECI #1 [8086:a13a] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:16.3 Serial controller [0700]: Intel Corporation Sunrise Point-H KT
> Redirection [8086:a13d] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> Kernel driver in use: serial
> 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-H SATA
> controller [AHCI mode] [8086:a102] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> Kernel driver in use: ahci
> Kernel modules: ahci
> 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express
> Root Port #1 [8086:a110] (rev f1)
> Kernel driver in use: pcieport
> 00:1c.1 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express
> Root Port #2 [8086:a111] (rev f1)
> Kernel driver in use: pcieport
> 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express
> Root Port #9 [8086:a118] (rev f1)
> Kernel driver in use: pcieport
> 00:1d.4 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express
> Root Port #13 [8086:a11c] (rev f1)
> 00:1d.6 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express
> Root Port #15 [8086:a11e] (rev f1)
> Kernel driver in use: pcieport
> 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-H LPC
> Controller [8086:a154] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-H PMC
> [8086:a121] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:1f.3 Audio device [0403]: Intel Corporation Device [8086:a171] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-H SMBus
> [8086:a123] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:13b6] (rev a2)
> Subsystem: Dell Device [1028:07bf]
> 02:00.0 Network controller [0280]: Intel Corporation Device [8086:24fd]
> (rev 78)
> Subsystem: Intel Corporation Device [8086:0050]
> Kernel modules: iwlwifi
> 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A
> PCI Express Card Reader [10ec:525a] (rev 01)
> Subsystem: Dell Device [1028:07bf]
> Kernel driver in use: rtsx_pci
> Kernel modules: rtsx_pci
> 04:00.0 Non-Volatile memory controller [0108]: Toshiba America Info
> Systems Device [1179:010f] (rev 01)
> Subsystem: Toshiba America Info Systems Device [1179:0001]
> Kernel driver in use: nvme
> Kernel modules: nvme
> 06:00.0 PCI bridge [0604]: Intel Corporation DSL6340 Thunderbolt 3
> Bridge [Alpine Ridge 2C 2015] [8086:1576]
> Kernel driver in use: pcieport
> 07:00.0 PCI bridge [0604]: Intel Corporation DSL6340 Thunderbolt 3
> Bridge [Alpine Ridge 2C 2015] [8086:1576]
> Kernel driver in use: pcieport
> 07:01.0 PCI bridge [0604]: Intel Corporation DSL6340 Thunderbolt 3
> Bridge [Alpine Ridge 2C 2015] [8086:1576]
> Kernel driver in use: pcieport
> 07:02.0 PCI bridge [0604]: Intel Corporation DSL6340 Thunderbolt 3
> Bridge [Alpine Ridge 2C 2015] [8086:1576]
>   

Bug#824648: win32-loader: reproduced error (0xc000007b g2ldr.mbr)

[Lennart Sorensen]

On Tue, Jul 18, 2017 at 10:40:30AM +0200, standard wrote:
> Package: win32-loader
> Followup-For: Bug #824648
> 
> I tried to install Debian (9.0) on a Tablet with Windows 10 Home. 
> * SSD-Harddrive with GPT
> * 2 GB RAM
> * 64 bit CPU
> * UEFI-BIOS
> 
> After restart I got the error 0xc07b and error message for g2ldr.mbr
> 
> As it turned out, the UEFI (and Windows) was only 32 bit(!)

Yes Windows requires UEFI to match in bit level.

> Eventuelly I managed to create a bootable USB key. It needed a 
> EFI/BOOT/bootia32.efi file to work.
> 
> The problem might be related to the 32 bit system instead of 64 bit.

At least in Debian 8, I believe the only media to support 32bit UEFI
was the i386/amd64 multiarch net install image.  I know I have used that
one successfully on an intel system with 32bit UEFI.

I didn't check if Debian 9 has similar limits on 32bit UEFI support in
the installer.  It is a pretty rare system type to encounter fortunately.

-- 
Len Sorensen

Bug#805488: [Patch] Fix (including for a lot of other failing tarballs)

[Lennart Sorensen]

On Fri, Jul 07, 2017 at 10:10:04PM +0200, Tomasz Buchert wrote:
> Wow, this is nice. Would you mind adding some tests to cover this?
> Ideally, we would have coverage for all rsyncable "dialects" we
> support.  Can you commit to collab-maint?

Something like this perhaps:

diff --git a/test/test_roundtrip.sh b/test/test_roundtrip.sh
index 5465ed4..b82620d 100644
--- a/test/test_roundtrip.sh
+++ b/test/test_roundtrip.sh
@@ -19,6 +19,18 @@ test_bz2() {
   assertWorksWithTarball $SAMPLES/tarballs/foo-1.0.tar.bz2
 }
 
+test_gz_135_rsyncable() {
+  assertWorksWithTarball 
$SAMPLES/tarballs/libinotify-kqueue-1.3.5rsyncable_20120419.orig.tar.gz
+}
+
+test_gz_14_rsyncable() {
+  assertWorksWithTarball 
$SAMPLES/tarballs/libinotify-kqueue-1.4rsyncable_20120419.orig.tar.gz
+}
+
+test_gz_16_rsyncable() {
+  assertWorksWithTarball 
$SAMPLES/tarballs/libinotify-kqueue-1.6rsyncable_20120419.orig.tar.gz
+}
+
 test_gz() {
   assertWorksWithTarball $SAMPLES/tarballs/foo-1.0.tar.gz
 }

I tried with a smaller tar file first, but you need to be at least 4 or
8KB depending on gzip version to trigger the rsyncable window size thing
so I used the other sample which resulted in different files for each
gzip version.

-- 
Len Sorensen


libinotify-kqueue-1.3.5rsyncable_20120419.orig.tar.gz
Description: application/gzip


libinotify-kqueue-1.4rsyncable_20120419.orig.tar.gz
Description: application/gzip


libinotify-kqueue-1.6rsyncable_20120419.orig.tar.gz
Description: application/gzip

Bug#805488: [Patch] Fix (including for a lot of other failing tarballs)

[Lennart Sorensen]

On Fri, Jul 07, 2017 at 10:10:04PM +0200, Tomasz Buchert wrote:
> Wow, this is nice. Would you mind adding some tests to cover this?
> Ideally, we would have coverage for all rsyncable "dialects" we
> support.

I can try to add some test coverage.  I will have to check how to do that.

>Can you commit to collab-maint?

I highly doubt it.  I am not a DD or DM (I keep meaning to become one,
but never seem to get around to it).

-- 
Len Sorensen

Bug#805488: [Patch] Fix (including for a lot of other failing tarballs)

[Lennart Sorensen]

I managed to fix almost half the failures in knownproblems by making
--gnu always be tried rather than only when GZIP_OS_UNIX is found.
Doing the same for --rsyncable and --new-rsyncable probably makes sense
too.

The --new-rsyncable was written for gzip 1.4, while gzip 1.6 does things
a bit different (it's a bit of a hybrid between the original rsyncable
and the 1.4 rsyncable).  I have added a new --16-rsyncable option to
zgz that matches the new behaviour, which fixes this bug.

I have tested both gzip 1.4 and gzip 1.6 with --rsyncable and pristine-tar
now handles both.

-- 
Len Sorensen
>From dd0d04fa27d77c1a808e43a313788b63200e54b5 Mon Sep 17 00:00:00 2001
From: Len Sorensen 
Date: Thu, 6 Jul 2017 16:52:41 -0400
Subject: [PATCH] Try --gnu all the time and fix current rsyncable

The rsyncable code was not quite in sync with what gzip --rsyncable
actually does on debian.  Resolving this fixes bug 805488.

Only trying --gnu when GZIP_OS_UNIX is found causes a lot of possible
matches to be missed.  Making --gnu always be attemped no matter what
fixes the following knownproblem cases:

abind_1.1.0.orig.tar.gz
arj_3.10.22.orig.tar.gz
commons-configuration_1.6.orig.tar.gz
dot2tex_2.8.5.orig.tar.gz
evolver_2.30c.orig.tar.gz
faad2_2.6.1.orig.tar.gz
intercal_0.28.orig.tar.gz
libapache-session-perl_1.87.orig.tar.gz
libdatetime-event-sunrise-perl_0.0501.orig.tar.gz
libfreezethaw-perl_0.45.orig.tar.gz
libhtml-linkextractor-perl_0.130.orig.tar.gz
libhtml-prototype-perl_1.48.orig.tar.gz
libhttp-browserdetect-perl_0.98.orig.tar.gz
libinline-perl_0.45.orig.tar.gz
libmail-sendeasy-perl_1.2.orig.tar.gz
libmail-sender-perl_0.8.13.orig.tar.gz
libmail-sender-perl_0.8.16.orig.tar.gz
libmarc-lint-perl_1.43.orig.tar.gz
libmp3-tag-perl_0.9714.orig.tar.gz
libnet-daemon-perl_0.43.orig.tar.gz
libnet-ifconfig-wrapper-perl_0.09.orig.tar.gz
libpdf-api2-perl_0.72.003.orig.tar.gz
libpdf-api2-perl_0.73.orig.tar.gz
libpdf-reuse-perl_0.35.orig.tar.gz
libphp-adodb_5.07.orig.tar.gz
libplrpc-perl_0.2020.orig.tar.gz
libpod-simple-wiki-perl_0.08.orig.tar.gz
libreadonly-perl_1.03.orig.tar.gz
libspreadsheet-writeexcel-perl_2.25.orig.tar.gz
libterm-readline-perl-perl_1.0302.orig.tar.gz
libxml-smart-perl_1.6.9.orig.tar.gz
pyparsing_1.5.1.orig.tar.gz
python-kinterbasdb_3.2.orig.tar.gz
rmetrics_260.72.orig.tar.gz
scalpel_1.60.orig.tar.gz
ttf-umefont_401.orig.tar.gz
ttf-umefont_402.orig.tar.gz
unace_1.2b.orig.tar.gz
unrar-nonfree_3.8.5.orig.tar.gz
---
 pristine-gz| 13 +
 zgz/gzip/deflate.c | 27 ---
 zgz/gzip/gzip.c|  4 ++--
 zgz/gzip/gzip.h|  2 +-
 zgz/zgz.c  | 15 ++-
 5 files changed, 38 insertions(+), 23 deletions(-)

diff --git a/pristine-gz b/pristine-gz
index 2f67160..d110eaf 100755
--- a/pristine-gz
+++ b/pristine-gz
@@ -188,13 +188,10 @@ sub reproducegz {
 
   my @try;
 
-  if ($os == $fconstants{GZIP_OS_UNIX}) {
-# for 98% of the cases the simple heuristic above works
-# and it was produced by gnu gzip.
-push @try, [ '--gnu', @args ];
-push @try, [ '--gnu', @args, '--rsyncable' ];
-push @try, [ '--gnu', @args, '--new-rsyncable' ];
-  }
+  push @try, [ '--gnu', @args ];
+  push @try, [ '--gnu', @args, '--rsyncable' ];
+  push @try, [ '--gnu', @args, '--new-rsyncable' ];
+  push @try, [ '--gnu', @args, '--16-rsyncable' ];
 
   if ($name =~ /\//) {
 push @args, "--original-name", $name;
@@ -301,7 +298,7 @@ sub gengz {
   my @params = split(' ', $delta->{params});
   while (@params) {
 $_ = shift @params;
-next if /^(--gnu|--rsyncable|--new-rsyncable|-[nmM1-9])$/;
+next if /^(--gnu|--rsyncable|--new-rsyncable|--16-rsyncable|-[nmM1-9])$/;
 if (/^(--original-name|--quirk|--osflag)$/) {
   shift @params;
   next;
diff --git a/zgz/gzip/deflate.c b/zgz/gzip/deflate.c
index 780e500..016b757 100644
--- a/zgz/gzip/deflate.c
+++ b/zgz/gzip/deflate.c
@@ -107,11 +107,19 @@ int RSYNC_WIN = 4096;
 /* Whether to enable compatability with Debian's old rsyncable patch. */
 int debian_rsyncable = 1;
 
-void disable_debian_rsyncable () {
+void set_14_rsyncable () {
 	debian_rsyncable = 0;
 	RSYNC_WIN = 8192;
 }
 
+/* gzip 1.6 uses a different rsyncable that is a hybrid between the
+ * original and the gzip 1.4 version
+ */
+void set_16_rsyncable () {
+	debian_rsyncable = 2;
+	RSYNC_WIN = 8192;
+}
+
 #define RSYNC_SUM_MATCH_DEBIAN(sum) ((sum) % RSYNC_WIN == 0)
 #define RSYNC_SUM_MATCH(sum) (((sum) & (RSYNC_WIN - 1)) == 0)
 /* Whether window sum matches magic value */
@@ -532,9 +540,9 @@ static void rsync_roll(unsigned start, unsigned num)
 	rsync_sum += (ulg)window[i];
 	/* Old character out */
 	rsync_sum -= (ulg)window[i - RSYNC_WIN];
-	if (debian_rsyncable && rsync_chunk_end == 0xUL && RSYNC_SUM_MATCH_DEBIAN(rsync_sum))
+	if (debian_rsyncable == 1 && rsync_chunk_end == 0xUL && RSYNC_SUM_MATCH_DEBIAN(rsync_sum))
 	rsync_chunk_end = i;
-	if (! debian_rsyncable && rsync_chunk_end == 0xUL && 

Bug#866085: At least it should be the option to not download

[Lennart Sorensen]

On Wed, Jun 28, 2017 at 08:52:31AM +0200, Narcis Garcia wrote:
> If you *will* be connected to the internet you *will* need to install
> security updates;
> Internet is not the only source for packages (). If someone
> installs Debian on 3 computers (or repeats installation 3 times), it
> shouldn't mean to use 3x internet traffic repeating installer downloads.
> 
> A) This user can save and reuse packages cache and apply updates at the
> convenient moment.
> B) When repeating install at the same computer (e.g. changing install
> decisions such as partitioning, architecture, etc.) the user only needs
> updates on final one.
> 
> Most of internet uses on the world have really low bandwidth accessing
> to the internet, and making (some) unnecessary downloads can be a money
> & time problem.
> 
> +
> I've participated on an "install party" where only half of Debian
> installs could be done because of this issue.

If you are doing an install party, set up a proxy server.  That really
really helps a lot.

-- 
Len Sorensen

Bug#858731: Doesn't this fix loose the bug?

[Lennart Sorensen]

I was under the impression stretch would release with 4.9 kernel.
So fixing it in 4.10 and marking it done seems like it might loose the
bug report without ever getting it actually included in stretch.

Will the config change in the 4.10 experimental automatically be included
in any updates to the 4.9 kernel going in unstable/testing?

Just wondering.

-- 
Len Sorensen

Bug#857172: Please enable SSE2 on amd64 and disable altivec on PPC ports

[Lennart Sorensen]

On Wed, Mar 08, 2017 at 04:06:17PM +0100, John Paul Adrian Glaubitz wrote:
> The firefox package is built with AltiVec enabled and so is mplayer,
> for example. So, yes, Altivec is actively used and I would honestly
> refrain from disabling it in a performance-sensitive package like
> babl.
> 
> Altivec is disabled on powerpcspe where it's not available in the
> hardware, but most machines on which people install Debian powerpc
> should have Altivec.

e5500 does not have it, which means one of the modern powerpc chips
doesn't support it.

Certainly the powerpc64 port claims e5500 support, and hence does NOT
assume altivec support.

It really is something that should be runtime detected and used if
present but not required.

-- 
Len Sorensen

Bug#855415: installation-reports: Debian-Testing fails to reboot after installation.

[Lennart Sorensen]

On Fri, Feb 17, 2017 at 07:14:11PM +0100, Michael Siemmeister wrote:
> Last week I tried to install Debian in a virtual-box. Currently I use
> Debian 8.7 for running the virtual-box program. I managed to install
> Debian stable without any problems. Then I cloned the virtual-box and
> tried an upgrade to Debian-testing. I think, it worked. After a while
> I shut down the virtual-machine. When trying to reboot, it did not
> start properly. I just got some messages like 'Created slice User
> Slice of Debian-gdm.', 'Starting User Manager ofr UID 117.', and
> finally 'Started Daily apt activities.'. Then the virtual display just
> starts blinking. Nothing else happens. After three minutes or so the
> display freezes.
> 
> Then I thought, okay, maybe the virtualbox program has got a bug. So,
> I downloaded the Debian-Testing-DVD-1 via jigdo-lite and copied it to
> a USB drive. I tried to install Debian-Testing on an old laptop, a
> Toshiba Satellite from 2009. Unfortunately I don' remember the exact
> model number. I had already installed Debian Stable without any
> problems on that laptop some months ago. The Debian-Testing installer
> worked fine and finally, it asked me to reboot the PC. After rebooting
> similar problems occured. There was a message about the graphics card
> and after 30 seconds the display started blinking. Nothing else
> happened.
> 
> As I have written above these errors only occured with Debian-Testing.
> Debian-Stable worked fine on Virtualbox and the Toshiba laptop. So, I
> don't think there are some hardware problems.

If you are running virtualbox on jessie, that would be version 4.3.36.
I do find a lot of problems reported with gnome 3 and virtual box 4.x.

I wonder if virtualbox 5.1.8 in jessie-backports would solve the problem.

I also wonder if having virtualbox 4.x as host with 5.x guest utilities
installed could cause problems (I suspect the guest utilities are
automatically installed and for stretch they would be version 5.x,
not 4.x).

After all gnome3 mandates 3D accaleration, and having drivers that don't
match the hardware (virtualbox in this case) could be a problem.

-- 
Len Sorensen

Bug#815187: Similar problem

[Lennart Sorensen]

On Sat, Feb 04, 2017 at 11:33:02PM +1000, David wrote:
> Hi. I'm a noob but I think I had a similar problem.
> Legacy BIOS on laptop with 2 identical SATA disks.
> Windows 7 on /dev/sda1. Installed jessie 8.7.1 from USB on /dev/sdb2 (swap
> on sdb1)
> Grub wanted to install to /dev/sda MBR but I wanted to keep the windows
> installation native and boot Debian from /dev/sdb using BIOS boot options.
> So I specified /dev/sdb MBR as target for grub.
> Completed without error but then not bootable from /dev/sdb. Once it said
> "Missing operating system" but mostly there was just a blinking cursor
> Fixed by booting from a Live CD,  installing grub from there using steps in
> this post
> http://howtoubuntu.org/how-to-repair-restore-reinstall-grub-2-with-a-ubuntu-live-cd
> Installed without errors and now working as desired.
> I'm happy to provide any logs that would help but might need some guidance
> to find the relevant info.

It is quite likely that the bios swaps the device ID of sda and sdb when
you choose to boot sdb, which then means grub would get confused since
it was installed expecting sdb to be the second disk, but when booted
it is suddenly the first disk instead.

I suspect to make it happy would require convincing grub that sdb is in
fact the first hd in the system (In older grub versions one would do
this by changing the device.map file in /boot/grub but I don't recall
if that is still used).

Or you could change the order of the disks in the bios (somehow) before
booting the installer and hopefully sdb would be the first disk then
from grub's point of view.

This is my guess at the problem at least.

-- 
Len Sorensen

Bug#852323: debian-installer: grub-installer not convert root= entry to UUID

[Lennart Sorensen]

On Mon, Jan 23, 2017 at 04:03:06PM +, Steve McIntyre wrote:
> On Mon, Jan 23, 2017 at 06:43:27PM +0300, Andrey Jr. Melnikov wrote:
> >Package: debian-installer
> >Severity: important
> >Tags: d-i
> >
> >
> >Installation procedure of grub2 dont't transform root= entry from /dev/sd?? 
> >to UUID notation. 
> >This lead to unbootable system after install.
> 
> Hmmm. It normally does this reliably in my experience. What version of
> d-i did you use, and did you follow through the menus as normal? Is
> there anything special about your setup?

Well the log indicates the use of a GPT partition table with BIOS boot
and not creating the GPT bios boot partition.  So at least that qualifies
as not normal.

Perhaps that is an indication that the system is supposed to be EFI
booted but somehow the installer was booted in the wrong mode.

-- 
Len Sorensen

Bug#261415: network installation always asks for proxy

[Lennart Sorensen]

On Sat, Jan 21, 2017 at 11:31:37PM -0800, Josh Triplett wrote:
> I do think we ought to attempt autodetection for this.  As long as a
> means exists for preseeders and expert installs to specify one anyway
> (for optional caching proxies), autodetecting by default seems like a
> good idea, to eliminate one of the more highly technical questions in
> the install.

Just how would you autodetect if a proxy should be used?  You can detect
if internet access works without one perhaps, but that doesn't mean a
proxy isn't desired.  I have actually encountered a network where the
firewall allowed access to one debian mirror without going through the
proxy, but security required going through a proxy.  Good luck detecting
that mess correctly.

-- 
Len Sorensen

Bug#851947: Debian 8.7.1 installation problem

[Lennart Sorensen]

On Fri, Jan 20, 2017 at 11:25:37AM +0200, :-) wrote:
> Package: installation-reports
> 
> Boot method: UEFI from USB flash drive
> Image version: http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/
> Date: 19.01.2017
> 
> Machine: HP ProBook 4540s
> Processor: Intel Core i5-3230M
> Memory: 8GB
> Partitions: GPT partition table, sda1 12 GB SWAP, sda2 35GB root
> 
> Output of lspci -knn (or lspci -nn):
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [E]
> Detect network card:[ ]
> Configure network:  [ ]
> Detect CD:  [ ]
> Load installer modules: [ ]
> Detect hard drives: [ ]
> Partition hard drives:  [ ]
> Install base system:[ ]
> Clock/timezone setup:   [ ]
> User/password setup:[ ]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[ ]
> 
> Comments/Problems:
> 
> I downloaded debian-8.7.1-amd64-CD-1.iso and made an UEFI bootable USB
> Flash Drive (UFD) via RUFUS 2.11. I booted from UFD and chose
> "Install" (Result is the same if I choose "Install graphical"). The
> next screen appeared in color stripes like a rug. I tried to change
> any available video options in GRUB, editting the command line with
> 'E'. It didn't help. I tried to switch off the discrete video
> controller (AMD Radeon HD 7500/7600 series) from UEFI BIOS and install
> with Intel HD 4000. It didn't help. I have had the same issue with
> previous versions of Debian too. With Ubuntu I haven't had that
> problem, but I want a classic Debian. I tried to install it on HP
> EliteDesk 705 G1 booting from the same UFD with the same boot method.
> The installation was successfull.

Why did you not just write the iso raw to the USB key?  It is already
a bootable image.

Using any of the other tools for converting iso's to bootable USB just
tends to break things.

Of course that might very well not have anything to do with the graphics
messing up.  I have recently hit one machine where 1280x1024 didn't work
because it tried to use vesa, and the ati card for some reason decided
to use 75HZ refresh with a monitor that said it could only do 60Hz.
1024x768 worked fine of course.  It was a rather old machine though.

Since it didn't work with the intel graphics, that does seem to rule
out the video card.  Maybe the monitor is the problem, although quite
how it could do that I am not sure.  Since ubuntu worked, clearly
something is wrong in software.

Does the grub menu appear fine with graphics?

-- 
Len Sorensen

Bug#851740: bug report installing 9.0 RC1

[Lennart Sorensen]

On Wed, Jan 18, 2017 at 10:56:58AM +0100, bkk wrote:
> Package: installation-reports
> 
> Boot method: Installer bootet via USB
> Image version: 
> http://cdimage.debian.org/cdimage/stretch_di_rc1/amd64/iso-cd/debian-stretch-DI-rc1-amd64-netinst.iso
> Date: 2017-01-18 09:45
> 
> Machine: SUPERMICRO X10SBA-L-O-P
> Processor: Intel Celeron J1900 (cpu family:6, model: 55, stepping:8)
> Memory: 4GB
> Partitions:
> 
> Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x51e39a8b
> 
> Device Boot  StartEndSectors   Size Id Type
> /dev/sda1  *  2048 1945382911 1945380864 927,6G 83 Linux
> /dev/sda2   1945384958 19535237118138754   3,9G  5 Extended
> /dev/sda5   1945384960 19535237118138752   3,9G 82 Linux swap / 
> Solaris
> 
> 
> 
> Output of lspci -knn (or lspci -nn):
> 
> 00:00.0 Host bridge [0600]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
> Serie s SoC Transaction Register [8086:0f00] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  SoC Transaction Register [15d9:0816]
> Kernel driver in use: iosf_mbi_pci
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor 
> Z36xx x/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  Graphics & Display [15d9:0816]
> Kernel driver in use: i915
> Kernel modules: i915
> 00:13.0 SATA controller [0106]: Intel Corporation Atom Processor E3800 Series 
> SA TA AHCI Controller [8086:0f23] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor E3800 Series SATA 
> AHC I Controller [15d9:0816]
> Kernel driver in use: ahci
> Kernel modules: ahci
> 00:1a.0 Encryption controller [1080]: Intel Corporation Atom Processor 
> Z36xxx/Z3 7xxx Series Trusted Execution Engine [8086:0f18] 
> (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  Trusted Execution Engine [15d9:0816]
> 00:1c.0 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
> Exp ress Root Port 1 [8086:0f48] (rev 0e)
> Kernel driver in use: pcieport
> Kernel modules: shpchp
> 00:1c.2 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
> Exp ress Root Port 3 [8086:0f4c] (rev 0e)
> Kernel driver in use: pcieport
> Kernel modules: shpchp
> 00:1c.3 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
> Exp ress Root Port 4 [8086:0f4e] (rev 0e)
> Kernel driver in use: pcieport
> Kernel modules: shpchp
> 00:1d.0 USB controller [0c03]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
> Se ries USB EHCI [8086:0f34] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  USB EHCI [15d9:0816]
> Kernel driver in use: ehci-pci
> Kernel modules: ehci_pci
> 00:1f.0 ISA bridge [0601]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
> Series  Power Control Unit [8086:0f1c] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  Power Control Unit [15d9:0816]
> Kernel driver in use: lpc_ich
> Kernel modules: lpc_ich
> 00:1f.3 SMBus [0c05]: Intel Corporation Atom Processor E3800 Series SMBus 
> Contro ller [8086:0f12] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor E3800 Series SMBus 
> Co ntroller [15d9:0816]
> Kernel driver in use: i801_smbus
> Kernel modules: i2c_i801
> 02:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network 
> Conne ction [8086:1533] (rev 03)
> Subsystem: Super Micro Computer Inc I210 Gigabit Network Connection 
> [15d 9:1533]
> Kernel driver in use: igb
> Kernel modules: igb
> 03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network 
> Conne ction [8086:1533] (rev 03)
> Subsystem: Super Micro Computer Inc I210 Gigabit Network Connection 
> [15d 9:1533]
> Kernel driver in use: igb
> Kernel modules: igb
> 
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [E]
> Detect CD:  [ ]
> Load installer modules: [O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[E]
> 

Bug#851620: partman-md: doesn't warn about not being able to embed in the end

[Lennart Sorensen]

On Mon, Jan 16, 2017 at 10:46:44PM +0100, Samuel Thibault wrote:
> Package: partman-md
> Version: 77
> Severity: wishlist
> 
> Hello,
> 
> partman-md doesn't warn when disks to be used for RAID are partitioned
> with GPT without a bios boot partition for embedding (and I haven't seen
> documentation about the issue in the installer manual).

I suspect it might be a case of using gpt when not running in UEFI mode
is not normally done.

Normally people are either running UEFI mode and hence use GPT, or
they are using legacy BIOS and hence stick to DOS MBR partition table.
Given you don't have to go to GPT until your disk is 2TB or larger,
it has been OK for most people on legacy systems.

Of course since lilo is also a boot loader option in the installer,
one could argue whether there ought to be grub specific checks in the
partitioning tool.  I believe the warning you saw only came when the
grub install part did its checks much later, which is of course when
the grub code would be run.  Yes that's certainly a bit late given you
have to go back and do it all again if you want to use grub.

-- 
Len Sorensen

Bug#848929: installation-reports: no problem

[Lennart Sorensen]

On Thu, Dec 22, 2016 at 11:28:27AM +, Holger Levsen wrote:
> interesting. 

Yes.

> as another data point, for reproducible-builds we're running four i386 build
> nodes on virtual amd64 hardware, with 36GB ram each, and at least building the
> Debian archive works nicely.

But are they amd64 installs with 32bit chroots for building, or are they
i386 pae installs?

-- 
Len Sorensen

Bug#848929: installation-reports: no problem

[Lennart Sorensen]

On Tue, Dec 20, 2016 at 10:33:24PM +0100, Rudi Pfau wrote:
> Package: installation-reports
> Severity: normal
> 
> 
> 
> -- Package-specific info:
> 
> Boot method: network
> Image version: Debian 8.6.0.i386 1
> Date: 
> 
> Machine: self build tower
> - board: Asus X99-A II
> - RAM:   32GB (4*8G)
> - SSD:1TB Cruical MX300
> - CPU:   INTEL i7-6800K 3.4 GHz
> - GPU:   ASUS ROG Strix Radeon RX 460

So did you actually mean to install a 32 bit OS on a nice 64 bit machine
with 32 GB ram?

Just curious.  Obviously it will work, but I don't find much reason to
have a 32 bit system these days myself.

-- 
Len Sorensen

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

On Sat, Nov 12, 2016 at 10:00:53PM +0200, Adrian Bunk wrote:
> I do not understand this part.
> 
> -maltivec should only be set for the code that is behind the runtime 
> feature check, so this code is only run on hardware that has AltiVec.

Well a mistake in the configure script is making it set for everything.

After fixing that there is the problem of how to build merge.c in
deinterlace with only -maltivec for the altivec merge function, and not
the rest of the file which is supposed to be the generic C implementation.

I guess like the yuv file that has altivec support, the altivec merge
function needs to be built by itself with -maltivec while the rest of
the file is built without it.

I am trying to figure out how to do that but haven't quite figured it
out yet.  Certainly that is the correct way to fix it.

-- 
Len Sorensen

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

On Fri, Nov 04, 2016 at 01:33:36PM -0400, Lennart Sorensen wrote:
> And of course I made a typo while copying things into the patch.
> 
> Doing another build test of it now.
> 
> --- vlc-2.2.4.orig/configure.ac   2016-05-31 12:11:07.0 -0400
> +++ vlc-2.2.4/configure.ac2016-11-04 12:22:02.543265439 -0400
> @@ -1422,25 +1422,24 @@
>VLC_SAVE_FLAGS
>AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
>[ac_cv_c_altivec], [
> -CFLAGS="${CFLAGS} -maltivec"
> +CFLAGS="${CFLAGS} -maltivec -fno-tree-vectorize"
>  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
>  [#include ]], [
>  [vec_ld(0, (unsigned char *)0);]])], [
> -  ac_cv_c_altivec="-maltivec"
> +  ac_cv_c_altivec="-maltivec -fno-tree-vectorize"
>  ], [
>ac_cv_c_altivec="no"
>  ])
>])
> -  VLC_RESTORE_FLAGS
>AS_IF([test "${ac_cv_c_altivec}" != "no"], [
>  CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
>  AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
> are available.])
> -VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
> -ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
> -VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
> +ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} 
> ${ac_cv_c_altivec_abi}"
> +VLC_ADD_CFLAGS([libdeinterlace],[${ac_cv_c_altivec} 
> ${ac_cv_c_altivec_abi}])
>  have_altivec="yes"
>])
>AC_CHECK_HEADERS(altivec.h)
> +  VLC_RESTORE_FLAGS
>  
>VLC_SAVE_FLAGS
>LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"

That did not quite work, so I had to try the slightly more complicated
patch.

This patch works:

--- vlc-2.2.4.orig/configure.ac 2016-05-31 12:11:07.0 -0400
+++ vlc-2.2.4/configure.ac  2016-11-08 10:28:54.763640362 -0500
@@ -1422,25 +1422,23 @@
   VLC_SAVE_FLAGS
   AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
   [ac_cv_c_altivec], [
-CFLAGS="${CFLAGS} -maltivec"
+CFLAGS="${CFLAGS} -maltivec -fno-tree-vectorize"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#include ]], [
 [vec_ld(0, (unsigned char *)0);]])], [
-  ac_cv_c_altivec="-maltivec"
+  ac_cv_c_altivec="-maltivec -fno-tree-vectorize"
 ], [
   ac_cv_c_altivec="no"
 ])
   ])
-  VLC_RESTORE_FLAGS
   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
 CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
 AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
are available.])
-VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
-ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
-VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
+ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
 have_altivec="yes"
   ])
   AC_CHECK_HEADERS(altivec.h)
+  VLC_RESTORE_FLAGS
 
   VLC_SAVE_FLAGS
   LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"
--- vlc-2.2.4.orig/modules/video_filter/Modules.am  2015-02-02 
14:42:29.0 -0500
+++ vlc-2.2.4/modules/video_filter/Modules.am   2016-11-08 10:28:31.391639060 
-0500
@@ -29,6 +29,7 @@
 libdeinterlace_plugin_la_SOURCES += deinterlace/merge_arm.S
 libdeinterlace_plugin_la_CFLAGS += -DCAN_COMPILE_ARM
 endif
+libdeinterlace_plugin_la_CFLAGS += $(ALTIVEC_CFLAGS)
 video_filter_LTLIBRARIES += libdeinterlace_plugin.la
 
 libdynamicoverlay_plugin_la_SOURCES = \

With this patch, only functions inside a CPU feature check for altivec
support has any vector instructions.

And I realized the reason it was broken is that when using -maltivec and
-O4 (which vlc uses), you get -ftree-vectorize automatically enabled
which means gcc starts to automatically generate vector instructions
all over the place, which is not desired in this case.  It rather defeats
the purpose of having a cpu feature check after all.

-- 
Len Sorensen

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

And of course I made a typo while copying things into the patch.

Doing another build test of it now.

--- vlc-2.2.4.orig/configure.ac 2016-05-31 12:11:07.0 -0400
+++ vlc-2.2.4/configure.ac  2016-11-04 12:22:02.543265439 -0400
@@ -1422,25 +1422,24 @@
   VLC_SAVE_FLAGS
   AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
   [ac_cv_c_altivec], [
-CFLAGS="${CFLAGS} -maltivec"
+CFLAGS="${CFLAGS} -maltivec -fno-tree-vectorize"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#include ]], [
 [vec_ld(0, (unsigned char *)0);]])], [
-  ac_cv_c_altivec="-maltivec"
+  ac_cv_c_altivec="-maltivec -fno-tree-vectorize"
 ], [
   ac_cv_c_altivec="no"
 ])
   ])
-  VLC_RESTORE_FLAGS
   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
 CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
 AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
are available.])
-VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
-ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
-VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
+ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
+VLC_ADD_CFLAGS([libdeinterlace],[${ac_cv_c_altivec} 
${ac_cv_c_altivec_abi}])
 have_altivec="yes"
   ])
   AC_CHECK_HEADERS(altivec.h)
+  VLC_RESTORE_FLAGS
 
   VLC_SAVE_FLAGS
   LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"


-- 
Len Sorensen

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

Actually maybe this simpler version is better.  I think I just figured
out why libdeinterlace wasn't getting the altivec flags, which was that
it was listed as deinterlace rather than libdeinterlace.

Doing a build test of it now.

--- vlc-2.2.4.orig/configure.ac 2016-05-31 12:11:07.0 -0400
+++ vlc-2.2.4/configure.ac  2016-11-04 12:22:02.543265439 -0400
@@ -1422,25 +1422,24 @@
   VLC_SAVE_FLAGS
   AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
   [ac_cv_c_altivec], [
-CFLAGS="${CFLAGS} -maltivec"
+CFLAGS="${CFLAGS} -maltivec -fno-vectorize"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#include ]], [
 [vec_ld(0, (unsigned char *)0);]])], [
-  ac_cv_c_altivec="-maltivec"
+  ac_cv_c_altivec="-maltivec -fno-vectorize"
 ], [
   ac_cv_c_altivec="no"
 ])
   ])
-  VLC_RESTORE_FLAGS
   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
 CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
 AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
are available.])
-VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
-ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
-VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
+ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
+VLC_ADD_CFLAGS([libdeinterlace],[${ac_cv_c_altivec} 
${ac_cv_c_altivec_abi}])
 have_altivec="yes"
   ])
   AC_CHECK_HEADERS(altivec.h)
+  VLC_RESTORE_FLAGS
 
   VLC_SAVE_FLAGS
   LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"

-- 
Len Sorensen

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

On Fri, Nov 04, 2016 at 10:44:21AM -0400, Lennart Sorensen wrote:
> This would of course go much faster if I currently had access to a
> powerpc box rather than running in qemu. :)
> 
> I miss the p710 at my previous job.

So here is the patch I am currently building.  I think it now builds
correctly.

If someone actually wants to test it on real hardware without altivec that
would be great.  Not sure I will have much luck testing it under qemu.

-- 
Len Sorensen
diff -urN --exclude Makefile.in --exclude install-sh --exclude configure vlc-2.2.4.orig/compat/dummy.c vlc-2.2.4/compat/dummy.c
--- vlc-2.2.4.orig/compat/dummy.c	2016-02-04 17:08:51.0 -0500
+++ vlc-2.2.4/compat/dummy.c	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-/* Automatically generated */
diff -urN --exclude Makefile.in --exclude install-sh --exclude configure vlc-2.2.4.orig/configure.ac vlc-2.2.4/configure.ac
--- vlc-2.2.4.orig/configure.ac	2016-05-31 12:11:07.0 -0400
+++ vlc-2.2.4/configure.ac	2016-11-04 12:22:02.543265439 -0400
@@ -1422,25 +1422,23 @@
   VLC_SAVE_FLAGS
   AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
   [ac_cv_c_altivec], [
-CFLAGS="${CFLAGS} -maltivec"
+CFLAGS="${CFLAGS} -maltivec -fno-vectorize"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#include ]], [
 [vec_ld(0, (unsigned char *)0);]])], [
-  ac_cv_c_altivec="-maltivec"
+  ac_cv_c_altivec="-maltivec -fno-vectorize"
 ], [
   ac_cv_c_altivec="no"
 ])
   ])
-  VLC_RESTORE_FLAGS
   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
 CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
 AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions are available.])
-VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
-ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
-VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
+ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
 have_altivec="yes"
   ])
   AC_CHECK_HEADERS(altivec.h)
+  VLC_RESTORE_FLAGS
 
   VLC_SAVE_FLAGS
   LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"
diff -urN --exclude Makefile.in --exclude install-sh --exclude configure vlc-2.2.4.orig/modules/video_filter/Modules.am vlc-2.2.4/modules/video_filter/Modules.am
--- vlc-2.2.4.orig/modules/video_filter/Modules.am	2015-02-02 14:42:29.0 -0500
+++ vlc-2.2.4/modules/video_filter/Modules.am	2016-11-04 12:00:24.90729 -0400
@@ -29,6 +29,7 @@
 libdeinterlace_plugin_la_SOURCES += deinterlace/merge_arm.S
 libdeinterlace_plugin_la_CFLAGS += -DCAN_COMPILE_ARM
 endif
+libdeinterlace_plugin_la_CFLAGS += $(ALTIVEC_CFLAGS)
 video_filter_LTLIBRARIES += libdeinterlace_plugin.la
 
 libdynamicoverlay_plugin_la_SOURCES = \

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

On Fri, Nov 04, 2016 at 10:41:57AM -0400, Lennart Sorensen wrote:
> Well it's not the complete solution yet.
> 
> I have it down to only deinterlace being miscompiled (it auto vectorized
> Generic* functions with altivec instructions, which is not good).
> 
> At the moment it looks like either the altivec stuff has to be #ifdef
> out and compiled in a separeta pass like the yuv _altivec_ plugin, or
> gcc #pragma has to be used to only enable altivec in the one function
> (which I am trying now).  #pragma seems a tad ugly though.
> 
> I suspect gcc didn't always generate vector code automatically when
> -maltivec was passed, but these days it does, even at -O2 it seems,
> even though all the places I can find in the documentation says only -O3
> enables vectorization.

This would of course go much faster if I currently had access to a
powerpc box rather than running in qemu. :)

I miss the p710 at my previous job.

-- 
Len Sorensen

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

On Fri, Nov 04, 2016 at 10:52:05AM +0100, Sebastian Ramacher wrote:
> On 2016-11-03 13:58:58, Lennart Sorensen wrote:
> > On Tue, Nov 01, 2016 at 01:42:17PM -0400, Lennart Sorensen wrote:
> > > Well that looks like it only adds it for libvlccore.
> > 
> > So at least something like this is needed, but I think the VLCCORE is
> > wrong too, and maybe the deinterlace has to be moved to only merge.c
> > rather than all of deinterlace.
> > 
> > --- configure.ac.orig   2016-11-03 13:56:25.826878272 -0400
> > +++ configure.ac2016-11-03 13:56:55.558878272 -0400
> > @@ -1431,7 +1431,6 @@
> >ac_cv_c_altivec="no"
> >  ])
> >])
> > -  VLC_RESTORE_FLAGS
> >AS_IF([test "${ac_cv_c_altivec}" != "no"], [
> >  CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
> >  AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec 
> > extensions are available.])
> > @@ -1441,6 +1440,7 @@
> >  have_altivec="yes"
> >])
> >AC_CHECK_HEADERS(altivec.h)
> > +  VLC_RESTORE_FLAGS
> >  
> >VLC_SAVE_FLAGS
> >LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"
> > 
> > The CPPFLAGS are being clobbered with the -maltivec, which is only needed
> > when testing altivec.h, and should be removed again after that.
> > 
> > That removes the -maltivec that was showing up everywhere at least, and
> > now it is only in a few places, although perhaps still a few too many.
> 
> Please get this (and any follow-up patches) integrated upstream. See
> https://wiki.videolan.org/Sending_Patches/ for details.

Well it's not the complete solution yet.

I have it down to only deinterlace being miscompiled (it auto vectorized
Generic* functions with altivec instructions, which is not good).

At the moment it looks like either the altivec stuff has to be #ifdef
out and compiled in a separeta pass like the yuv _altivec_ plugin, or
gcc #pragma has to be used to only enable altivec in the one function
(which I am trying now).  #pragma seems a tad ugly though.

I suspect gcc didn't always generate vector code automatically when
-maltivec was passed, but these days it does, even at -O2 it seems,
even though all the places I can find in the documentation says only -O3
enables vectorization.

-- 
Len Sorensen

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

On Tue, Nov 01, 2016 at 01:42:17PM -0400, Lennart Sorensen wrote:
> Well that looks like it only adds it for libvlccore.

So at least something like this is needed, but I think the VLCCORE is
wrong too, and maybe the deinterlace has to be moved to only merge.c
rather than all of deinterlace.

--- configure.ac.orig   2016-11-03 13:56:25.826878272 -0400
+++ configure.ac2016-11-03 13:56:55.558878272 -0400
@@ -1431,7 +1431,6 @@
   ac_cv_c_altivec="no"
 ])
   ])
-  VLC_RESTORE_FLAGS
   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
 CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
 AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
are available.])
@@ -1441,6 +1440,7 @@
 have_altivec="yes"
   ])
   AC_CHECK_HEADERS(altivec.h)
+  VLC_RESTORE_FLAGS
 
   VLC_SAVE_FLAGS
   LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"

The CPPFLAGS are being clobbered with the -maltivec, which is only needed
when testing altivec.h, and should be removed again after that.

That removes the -maltivec that was showing up everywhere at least, and
now it is only in a few places, although perhaps still a few too many.

-- 
Len Sorensen

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

On Tue, Nov 01, 2016 at 07:37:33PM +0200, Adrian Bunk wrote:
> On Tue, Nov 01, 2016 at 01:08:03PM -0400, Lennart Sorensen wrote:
> > On Tue, Nov 01, 2016 at 12:22:19PM -0400, Lennart Sorensen wrote:
> > > On Tue, Nov 01, 2016 at 04:34:01PM +0200, Adrian Bunk wrote:
> > > > This doesn't looks wrong to me.
> > > > 
> > > > Note that depending on the software --enable-altivec can either mean
> > > > - compile unconditionally for AltiVec, or
> > > > - enable AltiVec parts with autodetection to only use them when the
> > > >   hardware supports it
> > > 
> > > Well in VLC it means build with -maltivec among other things.
> > > 
> > > > As I already wrote, vlc contains AltiVec-specific code and 
> > > > autodetection 
> > > > for using it only when the hardware supports it.
> > > > 
> > > > This should be enabled on all ppc ports, except the SPE one.
> > > > 
> > > > --enable-altivec also adding -maltivec elsewhere is a bug.
> > > 
> > > Well it certainly appears to have been done on purpose in the configure
> > > script.  Maybe it is a bug.  Perhaps I should poke it a bit...
> > > 
> > > > And due to this bug the whole AltiVec autodetection in vlc is
> > > > pretty useless.
> > > 
> > > Well if it has such auto detection, then yes it is.
> > 
> > I currently suspect:
> > 
> > configure.ac:
> > ...
> >   ])
> >   VLC_RESTORE_FLAGS
> >   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
> > CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"  <-- this looks wrong
> > AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec 
> > extensions are available.])
> > VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
> > ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} 
> > ${ac_cv_c_altivec_abi}"
> > ...
> > 
> > I think that line should not be there since all over CPPFLAGS is used as
> > part of the COMPILE variable, meaning not just CFLAGS gets -maltivec when
> > needed through ALTIVEC_CFLAGS, but in fact everywhere that has CPPFLAGS
> > gets it, meaning everything.
> 
> I was more suspecting the VLC_ADD_CFLAGS() would be the problem,
> but since the build log says "-maltivec -maltivec" it is actually
> likely that this is wrong in more than one place.

Well that looks like it only adds it for libvlccore.

-- 
Len Sorensen

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

On Tue, Nov 01, 2016 at 12:22:19PM -0400, Lennart Sorensen wrote:
> On Tue, Nov 01, 2016 at 04:34:01PM +0200, Adrian Bunk wrote:
> > This doesn't looks wrong to me.
> > 
> > Note that depending on the software --enable-altivec can either mean
> > - compile unconditionally for AltiVec, or
> > - enable AltiVec parts with autodetection to only use them when the
> >   hardware supports it
> 
> Well in VLC it means build with -maltivec among other things.
> 
> > As I already wrote, vlc contains AltiVec-specific code and autodetection 
> > for using it only when the hardware supports it.
> > 
> > This should be enabled on all ppc ports, except the SPE one.
> > 
> > --enable-altivec also adding -maltivec elsewhere is a bug.
> 
> Well it certainly appears to have been done on purpose in the configure
> script.  Maybe it is a bug.  Perhaps I should poke it a bit...
> 
> > And due to this bug the whole AltiVec autodetection in vlc is
> > pretty useless.
> 
> Well if it has such auto detection, then yes it is.

I currently suspect:

configure.ac:
...
  ])
  VLC_RESTORE_FLAGS
  AS_IF([test "${ac_cv_c_altivec}" != "no"], [
CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"  <-- this looks wrong
AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
are available.])
VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
...

I think that line should not be there since all over CPPFLAGS is used as
part of the COMPILE variable, meaning not just CFLAGS gets -maltivec when
needed through ALTIVEC_CFLAGS, but in fact everywhere that has CPPFLAGS
gets it, meaning everything.

I will try compile testing that as soon as I have the system ready.

-- 
Len Sorensen

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

On Tue, Nov 01, 2016 at 04:34:01PM +0200, Adrian Bunk wrote:
> This doesn't looks wrong to me.
> 
> Note that depending on the software --enable-altivec can either mean
> - compile unconditionally for AltiVec, or
> - enable AltiVec parts with autodetection to only use them when the
>   hardware supports it

Well in VLC it means build with -maltivec among other things.

> As I already wrote, vlc contains AltiVec-specific code and autodetection 
> for using it only when the hardware supports it.
> 
> This should be enabled on all ppc ports, except the SPE one.
> 
> --enable-altivec also adding -maltivec elsewhere is a bug.

Well it certainly appears to have been done on purpose in the configure
script.  Maybe it is a bug.  Perhaps I should poke it a bit...

> And due to this bug the whole AltiVec autodetection in vlc is
> pretty useless.

Well if it has such auto detection, then yes it is.

-- 
Len Sorensen

Bug#842513: vlc: immediate crash on launch on powerpc

[Lennart Sorensen]

On Mon, Oct 31, 2016 at 11:13:00PM +0200, Adrian Bunk wrote:
> This actually looks like a bug in upstream configure.ac to me:
> VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
> ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
> VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
> 
> It is correct that this adds -maltivec to AltiVec-specific code,
> and vlc has proper autodetection to run this only when AltiVec
> is actually present.
> 
> The VLC_ADD_CFLAGS here look just wrong - it is not the job of 
> configure.ac to add such flags to generic code (whatever march
> and hardware features are present is defined through compiler
> defaults and the CFLAGS passed by the user).

Actually what looks really wrong is that debian/rules builds ffmpeg with
--disable-altivec and then builds vlc with --enable-altivec.

Since powerpc can't assume you have altivec, perhaps vlc shouldn't be
built with it, or at least ought to have justification for why it is
done that way.  Maybe it was thought that no CPU without altivec would
be powerful enough to bother using vlc, but I think that may not in fact
be a valid assumption these days.

Certainly a 2.5GHz e5500 core is pretty decent performance, but has
no altivec.

-- 
Len Sorensen

Bug#842591: debootstrap-udeb: fails to validate InRelease (BADSIG)

[Lennart Sorensen]

On Mon, Oct 31, 2016 at 04:18:55PM +0100, Cyril Brulebois wrote:
> No, the “certainly did” and “worked fine” bits are wrong.
> 
> And that's not just me, we've had users report it, Philip Hands saw it
> as well. So no it did *NOT* work (in the specific case where it actually
> matters).

Yes, turns out sed doesn't do \a, but it does work if \a in sed is
replaced by [[:cntrl:]].  Doesn't make the line any prettier.

> Well that's the case in Debian right now, even in d-i! So your “busybox
> head does not appear to support it.” was wrong (that happens, no big
> deal), and I'm not so fond of being called a liar when I report test
> results for stuff I actually checked.

Well the version I looked at didn't have it, so apparently it was slightly
more than 3 years old.  It is a recent addition.

> Anyway, back to getting the next d-i release ready now that this issue
> is fixed.

Yep.

-- 
Len Sorensen

Bug#842591: debootstrap-udeb: fails to validate InRelease (BADSIG)

[Lennart Sorensen]

On Sun, Oct 30, 2016 at 05:28:57PM +0100, Cyril Brulebois wrote:
> Package: debootstrap-udeb
> Version: 1.0.85
> Severity: grave
> Justification: renders package unusable
> 
> The (re)addition of InRelease support broke debootstrap(-udeb) in a d-i
> context. The sed|tr|sed dance doesn't kill the final newline, which
> leads to a BAD signature.

The one I proposed certainly did.  It worked fine and was portable.
Just a touch ugly perhaps.

> My original proposal was to use head -c -1, which while not specified by
> posix actually just works. Reasons include:
>  1. Tests agree.
>  2. busybox's coreutils/head.c has:
> case 'c':
> count_bytes = 1;
>   …
> if (negative_N) {
> if (count_bytes) {
> print_except_N_last_bytes(fp, count);
> } else {
> print_except_N_last_lines(fp, count);
> }
> } else {
> print_first_N(fp, count, count_bytes);
> }

Well only if you have ENABLE_FEATURE_FANCY_HEAD and it was only added
in 2013, so rather recent addition.

> It might be suboptimal to use this for the time being, as it /might/
> limit portability. On the other hand, the idea was to get a d-i release
> out of the door.
> 
> I'll give it some thoughts in the upcoming hours, and decide how to fix.

-- 
Len Sorensen

Bug#790241: I don't see Node/JS in the code

[Lennart Sorensen]

On Mon, Oct 24, 2016 at 12:12:41PM +0200, W. Martin Borgert wrote:
> Len, you are right! I just checked the buildbot-0.9.0 branch and it
> does not seem to use the Node server, just some Node tools and
> AngularJS client-side. I wonder where I did got this idea from...

Well there is a mention of angular nodejs and how it uses python jade
or something instead.

> Sorry for the unintentional misinformation!

I just wanted to make sure I didn't miss something.

I wonder what the chances of getting 0.9 packaged in Debian is, and if
there is any chance of it hitting stretch in time.

-- 
Len Sorensen

Bug#790241: I don't see Node/JS in the code

[Lennart Sorensen]

I don't see any mention of Node/JS in buildbot's code or documentation.

I do see requirements for ramlfications and a few other things not in
Debian, but I sure can't find the Node/JS stuff anywere.

-- 
Len Sorensen

Bug#841236: installation-reports: After install of Debian 8.6, Debian won't boot probably due to problem with nvidia

[Lennart Sorensen]

On Tue, Oct 18, 2016 at 08:59:35PM +0200, Remi Vanicat wrote:
> Package: installation-reports
> Severity: important
> 
> Dear Maintainer,
> 
> -- Package-specific info:

> 
> Boot method: CD
> Image version: 
> http://cdimage.debian.org/debian-cd/8.6.0/multi-arch/iso-cd/debian-8.6.0-amd64-i386-netinst.iso
> Date: 
> 
> Machine: ASUS ROG G752VM-GC006T

I believe that model ships with SSD RAID enabled, which currently makes
linux unable to see the SSD since the intel controller has hijacked the
NVMe device and hidden it behind the AHCI controller  (even though it
isn't a SATA device) in a weird mode.

You would have to turn off that mode in the BIOS (if possible, Lenovo
currently is unwilling to allow it on some of their modela for examples).

I imagine at some point intel will get around to adding support for
their crazy mode to linux but it hasn't happened so far.

It also makes backups and recovery for windows a nightmware since the
standard drivers don't see the SSD either and you have to somehow get
the intel raid drivers loaded before it shows up.

-- 
Len Sorensen

Bug#841062: installation-reports

[Lennart Sorensen]

On Mon, Oct 17, 2016 at 11:49:05AM +0200, Erwan Prioul wrote:
> Package: installation-reports
> 
> Boot method: ISO image
> Image version: 
> http://cdimage.debian.org/mirror/cdimage/daily-builds/daily/current/ppc64el/iso-cd/debian-testing-ppc64el-netinst.iso
> Date: Mon Oct 17 00:44:56 2016
> 
> Machine: qemu VM / P8 baremetal / powerVM
> Processor: ppc64el
> Memory: 4Gb
> Partitions: 
> /dev/sda1 JFS (more than 10Gb)
> /dev/sda3 swap
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [O]
> Detect CD:  [O]
> Load installer modules: [O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Install tasks:  [O]
> Install boot loader:[E]
> Overall install:[E]
> 
> Comments/Problems:
> 
> When partitionning the disk, I chose the guided partitionning to use the 
> entire disk and one partition, then I changed the file system of the main 
> partition to JFS instead of ext4.
> Everything went right until the grub installation.
> It failed with:
> 
> Install the GRUB boot loader on a hard disk
> ---
> 
> !! ERROR: Unable to install GRUB in /dev/sda1
> 
> Executing 'grub-install /dev/sda1' failed.
> 
> This is a fatal error.
> 
> from /var/log/syslog:
> Oct 17 00:51:19 grub-installer: info: Installing grub on '/dev/sda1'
> Oct 17 00:51:19 grub-installer: info: grub-install does not support 
> --no-floppy
> Oct 17 00:51:19 grub-installer: info: Running chroot /target grub-install 
> --force "/dev/sda1"
> Oct 17 00:51:19 grub-installer: Installing for powerpc-ieee1275 platform.
> Oct 17 00:51:20 grub-installer: grub-install: error:
> Oct 17 00:51:20 grub-installer:  unknown filesystem.
> Oct 17 00:51:20 grub-installer: error: Running 'grub-install  --force 
> "/dev/sda1"' failed.
> Oct 17 01:09:20 main-menu[974]: (process:5214): File descriptor 3 
> (pipe:[9531]) leaked on lvdisplay invocation. Parent PID 5736: /bin/sh
> Oct 17 01:09:20 main-menu[974]: (process:5214): File descriptor 4 
> (/dev/pts/4) leaked on lvdisplay invocation. Parent PID 5736: /bin/sh
> Oct 17 01:09:20 main-menu[974]: (process:5214): File descriptor 5 
> (/dev/pts/4) leaked on lvdisplay invocation. Parent PID 5736: /bin/sh
> Oct 17 01:09:20 main-menu[974]: (process:5214): File descriptor 6 
> (/dev/pts/4) leaked on lvdisplay invocation. Parent PID 5736: /bin/sh
> Oct 17 01:09:20 main-menu[974]: (process:5214):   Volume group "sda" not found
> Oct 17 01:09:20 main-menu[974]: (process:5214):   Cannot process volume group 
> sda
> Oct 17 01:09:20 main-menu[974]: WARNING **: Configuring 'grub-installer' 
> failed with error code 1
> Oct 17 01:09:20 main-menu[974]: WARNING **: Menu item 'grub-installer' failed.

I just tried it and it worked fine.

I picked the default guided partitioning, then changed the root partition
(partition 2) from ext4 to JFS.  I did NOT delete and create any
partitions from the default guided setup.

I think, based on your error, that you deleted partition 1 (8MB the PReP
boot partition) which is required for installing the boot loader in IBM
power systems.  Or maybe you change the use type to JFS from PReP boot.

Partition 1 (PReP boot) does NOT contain a filesystem and is not mounted.
Grub is written to it raw and the firmware loads the contents of the
partition into ram and executes it raw.

-- 
Len Sorensen

Bug#812611: Install on Orange Pi Plus eMMC work but no reboot

[Lennart Sorensen]

On Thu, Oct 06, 2016 at 11:28:07PM +0100, Ben Hutchings wrote:
> Is that actually controlled by straps, though?  For the TI SoC I've
> been working with recently, when the boot device is set to eMMC the ROM
> code will look for the SPL in:
> 
> 1. boot area
> 2. fixed offsets in main area
> 3. file named 'MLO' in first partition (MBR, FAT)
> 
> in that order.

When I read the documentation, that bit was rather incomplete, so I
don't know for sure.  I think you are right that it tries them all.

Certainly the support for GPT and ext2 were not in the documentation
and was determined by giving it a try and being surprised it worked,
which the TI people then confirmed.  So MLO can be on FAT or ext2
partition with that partition being on an MBR or GPT setup.

I prefer the boot area (and is what the product I worked on uses), with
option 3 being my second choice;  I do not like option 2 at all since
it is incompatible with GPT.

-- 
Len Sorensen

Bug#812611: Install on Orange Pi Plus eMMC work but no reboot

[Lennart Sorensen]

On Thu, Oct 06, 2016 at 12:29:13PM -0700, Vagrant Cascadian wrote:
> To make matters more complicated, there are definitely some boards
> (Firefly, maybe BeagleBoard-X15) which can install the OS to eMMC, but
> u-boot still has to be loaded from SD card. I don't think we have much
> information on which boards those are. It may also vary from one u-boot
> version to the next...

The BeagleBoard X15 has jumper settings to boot:

SD if present, otherwise eMMC
UART
SATA if present otherwise SD

I know the CPU for eMMC boot will boot u-boot from partition 1 with a
given filename from either FAT or EXT2 filesystem, with either MBR or
GPT partition table.  It will also boot from eMMC boot area.  I am
not sure which one the X15 happens to be supporting when they say boot
from eMMC.

Seems the jumpers are not installed howefver, and it would take soldering
work to make it do anything other than the first option.

-- 
Len Sorensen

Bug#839894: installation-report: Jessie installer fails to install GRUB on a large JBOD system

[Lennart Sorensen]

On Thu, Oct 06, 2016 at 07:45:36AM +, Jonathan Quick wrote:
> Package: installation-reports
> Version: 2.58
> Severity: important
> 
> Dear Maintainer,
> 
> Whilst installing from a (Jessie) 8.6 netboot installer the GRUB installation 
> step failed, leaving the system unbootable.
> 
> -- Package-specific info:
> 
> Boot method: network
> Image version: 20150422+deb8u4+b1/images/netboot/debian-installer/amd64/linux
> Date: 6 October 2016 08:30 SAST
> 
> Machine: SuperMicro SuperServer
> Partitions: 
> Device Boot Start   End   Sectors  Size Id Type
> /dev/sdak1   2048 119883775 119881728 57.2G 83 Linux
> /dev/sdak2  119885822 125044735   5158914  2.5G  5 Extended
> /dev/sdak5  119885824 125044735   5158912  2.5G 82 Linux swap / Solaris
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [O]
> Detect CD:  [ ]
> Load installer modules: [O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[O]
> Install tasks:  [O]
> Install boot loader:[E]
> Overall install:[O]after recovery via rescue mode
> 
> Comments/Problems:
> 
> This was an installation of only the standard system plus a SSH server - no 
> desktop.
> Generally the installation went smoothly apart from the boot-loader step 
> which failed with no information on why.
> Trying a full desktop install gave the same problem (after a longer wait of 
> course).
> 
> Using the rescue mode (once I realised out that shells in the text mode 
> intaller didn't work and switched to the graphical
> one) I discovered that the grub2 package and its dependencies had not been 
> installed.  Once I had installed those packages,
> I was then able to use 'grub-install sdak' and 'update-grub' to get things 
> going.  Only after doing this did the option to
> reinstall GRUB appear in the rescue menu.  Now that GRUB is installed, the 
> machine boots fine into a working system.
> 
> Note this system has 36 4TB hard disk drives attached via a HBA (mpt3sas) and 
> one 64GB SSD attached to the motherboard SATA
> controller to which I was actually installing, hence the '/dev/sdak' disk 
> designation.
> 
> A test installation using a (Wheezy) 7.11 installer ran just fine without 
> showing this problem, but didn't see the HBA
> and its attached disks.

Sounds like the regex for matching valid disks in the installer handling
grub install isn't expecting 2 letter names, which is certainly an unusual
case, and if your system had put the target disk first rather than last,
you wouldn't have had a problem either.  Of course if wheezy didn't see
the other disks that would have solved the problem for it.

Probably this part of grub-installer is the problem:

case $prefix in
/dev/md)
disc_offered_devfs="$bootfs"
;;
/dev/mapper)
disc_offered_devfs="$bootfs"
;;

/dev/[hsv]d[a-z0-9]|/dev/xvd[a-z]|/dev/cciss/c[0-9]d[0-9]*|/dev/ida/c[0-9]d[0-9]*|/dev/rs/c[0-9]d[0-9]*|/dev/mmcblk[0-9]|/dev/nvme[0-9]*n[0-9]*|/dev/ad[0-9]*|/dev/da[0-9]*)
disc_offered_devfs="$prefix"
;;
*)
disc_offered_devfs=$(echo "$bootfs_nodevfs" | sed 
"s:\(.*\)/.*:\1/disc:")
;;
esac

/dev/[hsv]d[a-z0-9] will match /dev/sda through /dev/sdz, but NOT /dev/sdak.

If it added /dev/sd[a-z][a-z] as well, it should work for you.

So maybe:

/dev/[hsv]d[a-z0-9]|/dev/sd[a-z][a-z]|/dev/xvd[a-z]|/dev/cciss/c[0-9]d[0-9]*|/dev/ida/c[0-9]d[0-9]*|/dev/rs/c[0-9]d[0-9]*|/dev/mmcblk[0-9]|/dev/nvme[0-9]*n[0-9]*|/dev/ad[0-9]*|/dev/da[0-9]*)

Not sure if other places need fixing too.

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Thu, Oct 06, 2016 at 04:31:39PM +0200, Gianluca Renzi wrote:
> Just a clue: try to add a module parameter, for example videodepth= where
> you pass to the module offb.
> So if not passed gets the default, otherwise get the correct bpp value
> (8,15,16,24,32)???

The offb.c code seems to clearly use what openfirmware tells it and
nothing else.  It has no module options.

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Thu, Oct 06, 2016 at 07:44:35AM +0200, Mathieu Malaterre wrote:
> That's precisely what I tried yesterday.
> 
> Anytime I press 'Enter' after '22 set-mode' or '32 set-depth' I loose
> display (either black or corrupted). when I then type 'boot' it goes
> back to normal 8 bits. I have access to another Mac Mini G4 and even a
> Gigabit Ethernet to test.

Hmm, oh well.  No idea how to test it then, other than hard coding 32bpp
in the offb.c overriding what it gets from the firmware.

Still fixing the reversed red/blue would be nice.

Does the radeonfb have the red/blue reversal problem in pseudocolor mode
(I think that's what it came up in too by default)?

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Wed, Oct 05, 2016 at 08:55:50PM +0200, Mathieu Malaterre wrote:
> Will do ASAP. For reference:
> 
> https://bugs.debian.org/825840#92
> 
> and
> 
> devalias tells me that  'screen' points to
> '/pci@f000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0'

Not sure how that maps to the dev syntax I found.

I guess you would want '22 set-mode' for 1680x1050 then.

Of course based on that alias, maybe it would work to just do:

dev screen
22 set-mode
32 set-depth
boot

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Wed, Oct 05, 2016 at 06:40:36PM +0200, Mathieu Malaterre wrote:
> On Tue, Oct 4, 2016 at 10:24 PM, Lennart Sorensen
> <lsore...@csclub.uwaterloo.ca> wrote:
> > On Tue, Oct 04, 2016 at 09:22:17PM +0200, Mathieu Malaterre wrote:
> >> On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
> >> <lsore...@csclub.uwaterloo.ca> wrote:
> >> > On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
> >> >> € grep bogl_set_palette *
> >> >> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
> >> >> bogl.c: bogl_set_palette = bogl_fb_set_palette;
> >> >> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
> >> >> bogl.c:   the palette with bogl_set_palette() for this to take effect. 
> >> >> */
> >> >> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
> >> >> palette[][3]);
> >> >> bogl-test.c:  bogl_set_palette (0, 16, palette);
> >> >> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
> >> >> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
> >> >> bterm.c:  bogl_set_palette(0, 16, palette);
> >> >> bterm.c:bogl_set_palette(0, 16, palette);
> >> >> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
> >> >>
> >> >> It looks like bterm always set only colors 0-15.
> >> >
> >> > So it does.  Hmm, I will compare the code some more.
> >> >
> >> > Has it been confirmed that radeonfb does not have wrong colours while
> >> > offb on the same machine does?
> >> >
> >> > And what video mode does radeonfb run with?  I wish someone had dmesg
> >> > dumps of both offb and radeonfb, but I am not having much luck finding
> >> > any with google.
> >>
> >> Attached.
> >
> > Could you try what offb does if you boot with the kernel option:
> > video=1680x1050-32
> 
> Does not seems to be read at all. I tried both:
> 
> $ cat /etc/yaboot.conf
> [...]
> append="video=1680x1050-32"
> 
> and
> 
> $ cat /etc/yaboot.conf
> [...]
> append="video=offb:1680x1050-32"
> 
> dmesg & fbset output appears perfectly identical.

Maybe it just doesn't support doing that.

Looking at the code, offb in fact just does whatever open firmware
settings say to do.

So that means you would have to change the mode in open firmware before
booting.

So if you know how to drop to the open firmware prompt this might work:

dev pci1/@D/ATY,RockHopper2_A
32 set-depth
boot

I think I am guessing correctly for the dev value to talk to the video
card.

There is a 'set-mode' command too, but I don't know the mode number
for 1680x1050.  The radeonfb driver actually talks to the monitor and
does the mode setting itself.  Looking at modedb.c in the kernel,
entry 27 happens to be 1600x1200, and entry 36 is 1680x1050.  No idea
if that relates to the modes in the mac open firmware, but if it does,
this might work:

dev pci1/@D/ATY,RockHopper2_A
36 enable-videomode
36 set-mode
32 set-depth
boot

But this is still just to find out of offb works correctly in 24/32 bit
color mode, in which case the problem is only in 8 bpp.

-- 
Len Sorensen

Bug#826629: Possible offb unload fix.

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 09:39:12PM +0200, Mathieu Malaterre wrote:
> Here is what I see:
> 
> [   52.270154] bus: 'pci': add driver radeonfb
> [   52.270224] bus: 'pci': driver_probe_device: matched device
> :00:10.0 with driver radeonfb
> [   52.270233] bus: 'pci': really_probe: probing driver radeonfb with
> device :00:10.0
> [   52.270256] devices_kset: Moving :00:10.0 to end of list
> [   52.270264] radeonfb_pci_register BEGIN
> [   52.270267] radeonfb: MM1
> [   52.275001] radeonfb :00:10.0: enabling device (0006 -> 0007)
> [   52.279727] radeonfb: MM2
> [   52.295202] radeonfb: MM3
> [   52.299816] radeonfb: MM4
> [   52.304934] radeonfb: MM0 9800 800 radeonfb
> [   52.309768] checking generic (9c008000 96000) vs hw (9800 800)
> [   52.309776] fb: switching to radeonfb from OFfb ATY,RockHo
> [   52.315075] Console: switching to colour dummy device 80x25
> [   52.315595] device: 'fb0': device_unregister
> [   52.315736] PM: Removing info for No Bus:fb0
> [   52.317348] device: 'fb0': device_create_release
> [   52.317407] radeonfb: MM5 0
> [   52.317447] device: 'vtcon1': device_unregister
> [   52.317500] PM: Removing info for No Bus:vtcon1
> [   52.317565] device: 'vtcon1': device_create_release
> [   52.318992] radeonfb :00:10.0: BAR 0: can't reserve [mem
> 0x9800-0x9fff pref]
> [   52.319029] radeonfb (:00:10.0): cannot request region 0.
> [   52.319066] radeonfb: probe of :00:10.0 failed with error -16

So offb_destroy is NOT called.  Well that explains the problem.

Unfortunately it seems the reason it isn't called is that the
fb->info->count is not zero, because it is still open.  I am not sure
how the ability to unregister a conflicting framebuffer is supposed to
work if it stays active until it is replaced.

The kick out appears to successfully remove offb from being the active
fb, but since the release hasn't been called yet, the resources are not
yet freed, so radeonfb fails when trying to reserve them.  If offb_destroy
had been called the resources would be free and there would almost
certainly not be a problem.

Now the radeon.ko gets away with this because it doesn't try to reserve
the memory and never calls pci_request_region at all.

How about adding this to your patch:

--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2319,14 +2319,14 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
if (ret < 0) {
printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
pci_name(rinfo->pdev));
-   goto err_release_fb;
+   //goto err_release_fb;
}
 
ret = pci_request_region(pdev, 2, "radeonfb mmio");
if (ret < 0) {
printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
pci_name(rinfo->pdev));
-   goto err_release_pci0;
+   //goto err_release_pci0;
}
 
/* map the regions */

So it will still complain, but it will ignore the fact the memory
reservation failed, and still continue and do the ioremap and try to
use it.

That is how radeon.ko works as far as I can tell.

Of course once that is done, then the changes to offb.c become irrelevant.

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 09:22:17PM +0200, Mathieu Malaterre wrote:
> On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
> <lsore...@csclub.uwaterloo.ca> wrote:
> > On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
> >> € grep bogl_set_palette *
> >> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
> >> bogl.c: bogl_set_palette = bogl_fb_set_palette;
> >> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
> >> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
> >> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
> >> palette[][3]);
> >> bogl-test.c:  bogl_set_palette (0, 16, palette);
> >> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
> >> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
> >> bterm.c:  bogl_set_palette(0, 16, palette);
> >> bterm.c:bogl_set_palette(0, 16, palette);
> >> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
> >>
> >> It looks like bterm always set only colors 0-15.
> >
> > So it does.  Hmm, I will compare the code some more.
> >
> > Has it been confirmed that radeonfb does not have wrong colours while
> > offb on the same machine does?
> >
> > And what video mode does radeonfb run with?  I wish someone had dmesg
> > dumps of both offb and radeonfb, but I am not having much luck finding
> > any with google.
> 
> Attached.

Could you try what offb does if you boot with the kernel option:
video=1680x1050-32

I just wonder if that makes bterm work with right colors.

Of course it might not like it if it doesn't know how to change the mode
on an "Unknown" type of device.

Unfortunately /proc/iomem on powerpc is apparently totally useless.

-- 
Len Sorensen

Bug#826629: Possible offb unload fix.

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 08:41:45PM +0200, Mathieu Malaterre wrote:
> Hi Len,
> 
> Here is the release function I am using:
> 
> static void offb_destroy(struct fb_info *info)
> {
> struct offb_par *par = (struct offb_par *) info->par;
> if (info->screen_base)
> iounmap(info->screen_base);
> if (par->cmap_adr != NULL) {
> iounmap(par->cmap_adr);
> par->cmap_adr = NULL;
> }
> release_mem_region(info->apertures->ranges[0].base,
> info->apertures->ranges[0].size);
> framebuffer_release(info);
> }
> 
> 
> (you need the cast to avoid warning about deref of void*).
> 
> And if I do `modprobe radeonfb`:
> 
> [   72.163546] bus: 'pci': add driver radeonfb
> [   72.163618] bus: 'pci': driver_probe_device: matched device
> :00:10.0 with driver radeonfb
> [   72.163627] bus: 'pci': really_probe: probing driver radeonfb with
> device :00:10.0
> [   72.163651] devices_kset: Moving :00:10.0 to end of list
> [   72.163659] radeonfb_pci_register BEGIN
> [   72.163680] radeonfb :00:10.0: enabling device (0006 -> 0007)
> [   72.163721] radeonfb :00:10.0: BAR 0: can't reserve [mem
> 0x9800-0x9fff pref]
> [   72.163726] radeonfb (:00:10.0): cannot request region 0.
> [   72.163746] radeonfb: probe of :00:10.0 failed with error -16

Could you put a print statement in offb_destroy to make sure that is
actually being called?

And this is radeonfb with code added to actually try to kick out offb,
right?

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 08:20:13AM +0200, Mathieu Malaterre wrote:
> Hi,
> 
> > Well it seems ATY,Rockhopper2 (not Rockhopper) in the Mac Mini is in fact
> > a Radeon, and the way the radeonfb driver handles the pallete appears
> > to match the cmap_radeon in offb, so perhaps this would work in offb.c
> 
> I had time to test this patch yesterday night. It did not work using
> `cmap_radeon` codepath. I even tried changing:
> 
> out_le32(par->cmap_adr + 0xb4, (red << 16 | green << 8 | blue));
> 
> into:
> 
> out_le32(par->cmap_adr + 0xb4, (blue << 16 | green << 8 | red));
> 
> I am also thinking we are not looking at the right code.
> 
> I can see my `printk` messages so I know we are entering the
> `cmap_radeon` codepath.

Well radeonfb uses:

OUTREG(PALETTE_INDEX, pindex);
OUTREG(PALETTE_DATA, (red << 16) |
   (green << 8) | blue);

which is :

writel(pindex, (rinfo->mmio_base)+0x00B0)
writel((red << 16) | (green << 8) | blue), 
(rinfo->mmio_base)+0x00B4)

offb in cmap_radeon mode uses:
out_8(par->cmap_adr + 0xb0, regno);
out_le32(par->cmap_adr + 0xb4, (red << 16 | green << 8 | blue));

Not sure if using out_8 for the index versus using a 32 bit write makes
a difference.  I highly doubt it.

The memory being mapped is 0x4000 in size for radeonfb and 0x2000 in offb.
For the colour table that sounds plenty big.

Of course radeonfb is using pci functions to get the memory range while
offb uses OF calls.  The dmesg output I have seen so far seems to indicate
these are both returning the same thing, so that is not likely to be
the problem.

As for radeon driver, it appears to me that it pretty much always runs
32 bit truecolor, which should solve any palette problems by not using
them.

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 04:47:21PM +0200, Mathieu Malaterre wrote:
> Yes. If you re-read my post on debian-powerpc :) But getting `modprobe
> radeonfb` to work does not work as you know very well :)
> So the userland code in bterm is correct (no big endian issue).

Yes I also really doubt this is a bterm problem.

I was hoping my offb patch would solve the modprobe radeonfb problem by
freeing the pallete data memory to allow radeonfb to grab all the memory.

> Will do tonight. I can send the fbset output too.

Great.

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
> € grep bogl_set_palette *
> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
> bogl.c: bogl_set_palette = bogl_fb_set_palette;
> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
> palette[][3]);
> bogl-test.c:  bogl_set_palette (0, 16, palette);
> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
> bterm.c:  bogl_set_palette(0, 16, palette);
> bterm.c:bogl_set_palette(0, 16, palette);
> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
> 
> It looks like bterm always set only colors 0-15.

So it does.  Hmm, I will compare the code some more.

Has it been confirmed that radeonfb does not have wrong colours while
offb on the same machine does?

And what video mode does radeonfb run with?  I wish someone had dmesg
dumps of both offb and radeonfb, but I am not having much luck finding
any with google.

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 08:20:13AM +0200, Mathieu Malaterre wrote:
> I had time to test this patch yesterday night. It did not work using
> `cmap_radeon` codepath. I even tried changing:
> 
> out_le32(par->cmap_adr + 0xb4, (red << 16 | green << 8 | blue));
> 
> into:
> 
> out_le32(par->cmap_adr + 0xb4, (blue << 16 | green << 8 | red));
> 
> I am also thinking we are not looking at the right code.
> 
> I can see my `printk` messages so I know we are entering the
> `cmap_radeon` codepath.

But radeonfb works?

I was comparing the code in radeonfb to offb which is why I thought
using the colour setting code in cmap_radeon should work.

It looks like for the first 16 palette entries, something special is
done that matches cmap_simple, which might explain why the TERM=linux case
works, if it just uses the standard 16 colours, while with TERM=bterm
it might be trying to create custom colours, which puts it into the
higher range where different handling is done for the pallete and
cmap_simple no longer works on the radeon.

It is also likely that if you booted in 24bit or 32bit colour mode
instead of 8 bit, it would work too, since that too is done differently.
Might be interesting to try if there is an easy way to try that.

-- 
Len Sorensen

Bug#839672: debian-installer bug with drives in jbod

[Lennart Sorensen]

On Mon, Oct 03, 2016 at 05:30:09PM +, Brett Taylor wrote:
> Package: installation-reports
> 
> Boot method: network
> Image version: 
> Date: Oct 3 2016 12pm
> 
> Machine: supermicro SC826E16/MB-X9DRE-TF+
> Processor: E5-2680v2
> Memory: 36JSF2G72PZ / 36KSF2G72PZ
> Partitions:
> 
> Output of lspci -knn (or lspci -nn):
[snip]
> Logic MegaRAID SAS-3 3108 [Invader] [1000:005d] (rev 02)
> Oct  3 13:25:46 rx Subsystem: LSI Logic / Symbios Logic Device [1000:9363]
> Oct  3 13:25:46 rx Kernel driver in use: megaraid_sas
> Oct  3 13:25:46 rx ff:08.0 System peripheral [0880]: Intel Corporation Xeon

OK, so an LSI 3108 megaraid.

[snip]
> (0,7,0) (sda) - 480.1 GB ATA Micron_M500DC_MT

Micron M500DC SSDs.

[snip]
> Tainted: GB 3.16.0-4-amd64 #1 Debian 3.16.36-1+deb8u1
So Debian Jessie (your report didn't bother to say which debian version
you were trying to install which makes the report REALLY hard to do
anything about).

So you are using SSDs that support SED (self encrypting drive) as far
as I can tell.  I found this kernel driver change from last year (which
is of course newer than the kernel in jessie):

commit 7497cde883b184ead109652f236df98d78090a90
Author: sumit.sax...@avagotech.com 
Date:   Mon Jan 5 20:06:03 2015 +0530

megaraid_sas: add support for secure JBOD

This patch adds support for Secure Encrypting Drives (SED) in JBOD mode:

1) If the firmware supports SED JBOD, all non read/write commands to JBODs
   will be sent via firmware path, and read/write commands to JBODs will
   be sent via fastpath.
2) If the firmware does not support SED JBOD, driver will fall back to the
   old design, i.e. send all JBOD I/O via fastpath.

Signed-off-by: Sumit Saxena 
Signed-off-by: Chaitra Basappa 
Reviewed-by: Martin K. Petersen 
Signed-off-by: Christoph Hellwig 

I wonder if you have hit a problem with your SSDs in JBOD mode due to the
driver in 3.16 kernel in jessie not yet supporting that combination, while
almost certainly being on hardware new enough that it does support that.

Could you try booting the testing version of the installer just to see
if it survives?  If it does, that would certainly point to the issue
being a problem in the megaraid driver on the older kernel in jessie.

The fact it works in non JBOD mode where the RAID hides details of the
drives certainly makes that seem possible too.

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

Well it seems ATY,Rockhopper2 (not Rockhopper) in the Mac Mini is in fact 
a Radeon, and the way the radeonfb driver handles the pallete appears
to match the cmap_radeon in offb, so perhaps this would work in offb.c

--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -333,7 +333,7 @@
par->cmap_adr = offb_map_reg(dp, 2, 0, 0x1fff);
if (par->cmap_adr)
par->cmap_type = cmap_M3B;
-   } else if (dp && !strncmp(name, "ATY,Rage6", 9)) {
+   } else if (dp && (!strncmp(name, "ATY,Rage6", 9)) || !strncmp(name, 
"ATY,Rockhopper2", 15)) {
par->cmap_adr = offb_map_reg(dp, 1, 0, 0x1fff);
if (par->cmap_adr)
par->cmap_type = cmap_radeon;

-- 
Len Sorensen

Bug#826629: Possible offb unload fix.

[Lennart Sorensen]

I think the problem with registereing the PCI address in radeonfb is
that the offb does not unmap its addresses fully in the destroy function.

After all, it allocates both info->screen_base and par->cmap_addr as
using seperate ioremap calls on some hardware.  The radeonfb on the
other hand does a single large ioremap of the entire range.

The destroy function is:

static void offb_destroy(struct fb_info *info)
{
if (info->screen_base)
iounmap(info->screen_base);
release_mem_region(info->apertures->ranges[0].base, 
info->apertures->ranges[0].size);
framebuffer_release(info);
}

While the error handling of offb_init_fb is:

out_err:
iounmap(info->screen_base);
out_aper:
iounmap(par->cmap_adr);
par->cmap_adr = NULL;

So I think the solution is to change offb_destroy to:

static void offb_destroy(struct fb_info *info)
{
if (info->screen_base)
iounmap(info->screen_base);
if (info->par->cmap_adr) {
iounmap(info->par->cmap_adr);
info->par->cmap_adr = NULL;
}
release_mem_region(info->apertures->ranges[0].base, 
info->apertures->ranges[0].size);
framebuffer_release(info);
}

I think that will then let the radeonfb do its ioremap call after kicking
out the offb driver.

Certainly your logs indicate the offb was using:
9c008000 96000 (so 9c008000-9c09dfff)
I also believe the code is using:
9c7ff000-9c7f for cmap_adr based on:

} else if (!strncmp(name, "ATY,", 4)) {
unsigned long base = address & 0xff00UL;
par->cmap_adr =
ioremap(base + 0x7ff000, 0x1000) + 0xcc0;
par->cmap_data = par->cmap_adr + 1;
par->cmap_type = cmap_simple;

The first is info->screen_base and the second is info->par->cmap_adr,
but in destroy only the first one was freed, while the second stays
allocated and blocks the call in the radeonfb that wants:
9800-9fff
This of course overlaps both the other ranges.

Now the second ioremap for the cmap_adr should only happen when the
depth is 8 as far as I can tell.  Does it seem likely that is the mode
it is using for the offb initially?  From a bit of searching on google I
found some indications that 8 bit depth is very likely in fact by default.

-- 
Len Sorensen