Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE

[Adam Borowski]

Package: debootstrap
Version: 1.0.128+nmu3
Severity: grave

bluca's NMU on 2023-07-15 makes debootstrap produce chroots using the
aliased-dirs scheme.  While it's currently the default scheme for non-buildd
systems, it is both not supported by dpkg (with no solution in sight), but
is also likely to produce packages that are explicitely forbidden by a
recent CTTE ruling that disallows moving files between directories aliased
by the current usrmerge scheme.

Quoting the still unsolving issues is pointless (you can read about them
in massive threads in a number of places) as bluca seems to be ignoring
them completely.

But, what matters here is the CTTE ruling in #1035831 -- for the time being,
packages must not move files between locations affected by the aliasing.

Packages built in an usrmerged chroot place such files under /usr while
built without usrmerge into whatever place they were installed to -- which
is a direct breach of the ruling.

Thus, that change needs to be reverted for now, and all packages built
with 1.0.128+nmu3 need to be either rebuilt or at least checked for such
a violation (as most are unaffected).


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-rc1-00036-gc493f11e457d (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debootstrap depends on:
ii  wget  1.21.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.21-1
ii  debian-archive-keyring  2023.3
ii  gnupg   2.2.40-1.1

Versions of packages debootstrap suggests:
ii  binutils 2.40.90.20230705-1
pn  squid-deb-proxy-client   
ii  ubuntu-archive-keyring   2020.06.17.1-1
ii  ubuntu-keyring [ubuntu-archive-keyring]  2020.06.17.1-1
ii  xz-utils 5.4.1-0.2
ii  zstd 1.5.5+dfsg2-1

-- no debconf information

Bug#1036400: partman-jfs: JFS is on its way out, please remove from the installer

[Adam Borowski]

On Sun, May 21, 2023 at 07:35:36AM +0200, Cyril Brulebois wrote:
> Adam Borowski  (2023-05-20):
> > The JFS filesystem is deprecated in the kernel: on life support since 2009
> > and with talks of removal altogether.  Thus, we really shouldn't offer to
> > format new setups with it.  There are people who kind-of remember JFS being
> > the fastest back in the day, and it's irresponsible to set them for failed
> > upgrades past Bookworm.
> > 
> > Thus: please remove JFS from the installer.
> 
> It doesn't seem reasonable to do that weeks away from the release, without
> any kind of heads-up. That can be done during the Trixie release cycle,
> e.g. in Alpha 1.

Aye, sorry for having distracted you during the most busy time.  I filed the
bug when I learned about plans of giving JFS the axe.

> Feel free to ping this bug report a few weeks/months into the next release
> cycle

So... it might be a better time now.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Ash nazg durbatulûk,
⣾⠁⢠⠒⠀⣿⡁   ash nazg gimbatul,
⢿⡄⠘⠷⠚⠋⠀ ash nazg thrakatulûk
⠈⠳⣄   agh burzum-ishi krimpatul.

Bug#1036400: partman-jfs: JFS is on its way out, please remove from the installer

[Adam Borowski]

Package: partman-jfs
Severity: important

Hi!
The JFS filesystem is deprecated in the kernel: on life support since 2009
and with talks of removal altogether.  Thus, we really shouldn't offer to
format new setups with it.  There are people who kind-of remember JFS being
the fastest back in the day, and it's irresponsible to set them for failed
upgrades past Bookworm.

Thus: please remove JFS from the installer.


Meow!

Bug#1014790: installation-reports: Pinebook Pro: first partition overwrites u-boot, lacks bootable flag

[Adam Borowski]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: kilob...@angband.pl

Boot method: µSD
Image version: daily, pinebookpro + partition.img

Machine: Pinebook Pro
Partitions:
Model: MMC DA4128 (sd/mmc)
Disk /dev/mmcblk2: 122138624kiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start End   Size  File system NameFlags
 1  1024kiB   16384kiB  15360kiB  u-boot
 2  16384kiB  515072kiB 498688kiB ext4bootboot, 
legacy_boot, esp
 3  515072kiB 117702656kiB  117187584kiB  btrfs
 4  117702656kiB  122137600kiB  4434944kiBlinux-swap(v1)  swap

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:  [E]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[ ]


Missing firmware for the network card; it was not present anywhere among
suggested places, only later I learned it's package "raspi-firmware" (which
doesn't play well with any non-raspi because of /boot/firmware).

I've succeeded the installation using a dock that included ethernet, further
d-i boots used usb tethering.


The main problem was in the partitioner: it starts the first partition at
1MB, which overwrites u-boot.  On Rockchip boxen, the loader wants u-boot
starting at sector 16384 (ie, 8MB).  Rounding up to an aligned value, I'd
recommend starting the first partition at 16MB.

Some doc on teh Interwebs suggests creating a dummy partition so nothing
tries to write there -- I've done so.


The other problem is the boot partition not flagged as bootable; this
results in u-boot config not being found.


The kernel's boot hanged in an unobvious place long before trying to
mount disks (despite the same version but different build working for
d-i); upon seeing that 5.19-rc4 from experimental works fine I didn't
bother debugging 5.18 as we'll upgrade once Linus releases 5.19.


After all this long fighting, it appears that the Pinebook Pro works fine.
I invite you to gawp at it at the DebConf :)


Meow!
-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20220628-02:02:00"
X_INSTALLATION_MEDIUM=netboot-gtk

==
Installer hardware-summary:
==
uname -a: Linux khazad-dum 5.18.0-2-arm64 #1 SMP Debian 5.18.5-1 (2022-06-16) 
aarch64 GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: xHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 5.18.0-2-arm64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: xHCI Host Controller [1d6b:0003]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 03
usb-list:Manufacturer: Linux 5.18.0-2-arm64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.18.0-2-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 02: USB2.0 Hub [05e3:0608]
usb-list:Level 01 Parent 01 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 03: USB OPTICAL MOUSE  [18f8:0f97]
usb-list:Level 02 Parent 02 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Interface 00: Class 03(HID  ) Subclass 01 Protocol 02 Driver usbhid
usb-list:Interface 01: Class 03(HID  ) Subclass 00 Protocol 01 Driver usbhid
usb-list: 
usb-list: Bus 03 Device 04: USB Camera [0c45:6321]
usb-list:Level 02 Parent 02 Port 01  Class ef(misc ) Subclass 02 Protocol 01
usb-list:Manufacturer: Sonix Technology Co., Ltd.
usb-list:Interface 00: Class 0e(video) Subclass 01 Protocol 00 Driver 
usb-list:Interface 01: Class 0e(video) Subclass 02 Protocol 00 Driver 
usb-list: 
usb-list: Bus 04 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.18.0-2-arm64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 

Bug#998867: bumping severity

[Adam Borowski]

Control: severity -1 critical

The current severity, "grave", is a serious understatement.

As all buildd chroots that are created with buggy debootstrap are tainted,
any packages built recently may assume merged usr, and thus needs to be
rebuilt.

Do we have a patch?  If not, let's revert, today or tomorrow at the latest.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ A white dwarf seeks a red giant for a binary relationship.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#944976: debootstrap: please add Ubuntu focal

[Adam Borowski]

Package: debootstrap
Version: 1.0.116
Severity: wishlist

Hi!
Ubuntuites don't announce their release names in advance, which means a new
script is required immediately after being known.

This time, the name is "focal".

I've tried to symlink eoan (which links to gutsy) -- seems to work ok.


Meow!
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-rc7-00053-g1f56ffec5b2d (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debootstrap depends on:
ii  wget  1.20.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.16-2
ii  debian-archive-keyring  2019.1
ii  gnupg   2.2.17-3

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client   
ii  ubuntu-archive-keyring   2018.09.18.1-5
ii  ubuntu-keyring [ubuntu-archive-keyring]  2018.09.18.1-5

-- no debconf information

Bug#930102: Pinebook: no bootloader

[Adam Borowski]

Package: installation-reports
Severity: normal

-- Package-specific info:

Boot method: SD
Image version: 
https://d-i.debian.org/daily-images/arm64/daily/u-boot/pinebook.img.gz 
2019-06-06
Date: 2019-06-06

Machine: Pinebook
Partitions: auto: 231MB ext4 /boot, 12.3GB btrfs /, 2GB swap


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 CD:  [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [!]
Install base system:[O]
Install tasks:  [ ]
Install boot loader:[E]
Overall install:[ ]

Comments/Problems:

2019-06-05 image didn't successfully boot, today's did -- might be user
error but what I got in my .bash_history looks right.  Or possibly
nasty-vendor-kernel Gemini somehow corrupts images while Wookey's laptop is
ok.  But whatever the cause was, today it went ok.

Alas, not so lucky with the network card.  None of these were recognized:
* Pinebook's built-in wifi
* official Pine ethernet USB dongle (RTL8152)
* a wifi USB dongle (RT5370) (would need non-free firmware but didn't even
  show as an USB device)
What worked was USB link through Wookey's Android phone.  Obviously, this
might be a problem in areas with lesser abundance of Wookeys.

The partitioner insisted on installing to SD card that d-i was on, instead
of the machine's built-in eMMC.  While both show as mmcblk devices, it's an
obvious problem akin to wanting to install to a sdb USB stick rather than
sda SATA disk -- when both candidate devices go over the same kind of
interface, you'd want to pick 1. non-removable one, and 2. one that is
doesn't bear d-i itself.  Both criteria would be matched by /dev/mmcblk2
while /dev/mmcblk0 is SD card reader.

The worst part was the bootloader.  Making the box bootable took several
hours of effort despite no lack of related expertise of folks here
(minidebconf environment).  Steps that worked are:
* flash-kernel with the obvious patch (just submitted)
* installing u-boot-menu, u-boot-sunxi
* running flash-kernel, u-boot-install-sunxi64 and u-boot-update


==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190606-02:03:57"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux moria 4.19.0-5-arm64 #1 SMP Debian 4.19.37-3 (2019-05-15) 
aarch64 GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.19.0-5-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.19.0-5-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 02: USB2.0 Hub [05e3:0608]
usb-list:Level 01 Parent 01 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 03: USB KEYBOARD [258a:000c]
usb-list:Level 02 Parent 02 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Manufacturer: HAILUCK CO.,LTD
usb-list:Interface 00: Class 03(HID  ) Subclass 01 Protocol 01 Driver usbhid
usb-list:Interface 01: Class 03(HID  ) Subclass 00 Protocol 00 Driver usbhid
usb-list: 
usb-list: Bus 02 Device 07: SAMSUNG_Android [04e8:6863]
usb-list:Level 02 Parent 02 Port 01  Class e0(wlcon) Subclass 00 Protocol 00
usb-list:Manufacturer: SAMSUNG
usb-list:Interface 00: Class e0(wlcon) Subclass 01 Protocol 03 Driver 
rndis_host
usb-list:Interface 01: Class 0a(comdt) Subclass 00 Protocol 00 Driver 
rndis_host
usb-list: 
usb-list: Bus 02 Device 04: USB 2.0 PC Cam [090c:037c]
usb-list:Level 02 Parent 02 Port 02  Class ef(misc ) Subclass 02 Protocol 01
usb-list:Manufacturer: Image Processor
usb-list:Interface 00: Class 0e(video) Subclass 01 Protocol 00 Driver 
usb-list:Interface 01: Class 0e(video) Subclass 02 Protocol 00 Driver 
usb-list: 
usb-list: Bus 03 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.19.0-5-arm64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 04 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:

Bug#930098: flash-kernel: Pinebook

[Adam Borowski]

Package: flash-kernel
Version: 3.99
Severity: wishlist
Tags: patch

Here's an entry needed for Pinebook.


--- all.db~ 2019-05-23 18:54:49.0 +0200
+++ all.db  2019-06-06 17:15:28.236371171 +0200
@@ -1363,6 +1363,13 @@
 U-Boot-Script-Name: bootscr.uboot-generic
 Required-Packages: u-boot-tools
 
+Machine: Pinebook
+Kernel-Flavors: arm64
+DTB-Id: allwinner/sun50i-a64-pinebook.dtb
+Boot-Script-Path: /boot/boot.scr
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
 Machine: PlatHome OpenBlocks AX3-4 board
 Kernel-Flavors: armmp armmp-lpae
 DTB-Id: armada-xp-openblocks-ax3-4.dtb



-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-5-arm64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  devio  1.2-1.2+b1
ii  initramfs-tools0.133
ii  linux-base 4.6
ii  mtd-utils  1:2.0.1-1
ii  ucf3.0038+nmu1

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2019.01+dfsg-7

flash-kernel suggests no packages.

-- debconf information excluded

Bug#928408: #928408: network-manager missing from lxqt desktop

[Adam Borowski]

> The package network-manager and everything form which it is dependent on
> is missing - consequently, there is no tray-icon and it is not possible
> to connect to a network.

network-manager and its ecosystem are a component of Gnome; lxqt uses cmst
instead which is based on connman.  They're roughly equivalent -- and both
are merely user-friendly interfaces that's not required to connect to a
network.

> It is very complicated to install this package
> if you have no network connection at all because of all the
> dependencies. Well I am just a user, no computer scientist or
> programmer

If so, I'd recommend giving connman a try.  It seems to require no advanced
knowledge.  I haven't used it much (just on a single phone) thus I don't
know its details, but it seems to just do its job, with no poking required.

> but I am quite sure that this is not because of some missing
> wifi firmware.

Good to know -- that's the usual problem.

> I suggest to make the whole meta-package dependent of the network-manager
> or something like that.

It already has that dependency, albeit as an alternative:

Recommends: [...], cmst | nm-tray | network-manager-gnome | plasma-nm | wicd

Thus: cmst is picked by default, but there are five user interfaces the
metapackage is happy with, three of them being network-manager GUIs.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄

Bug#915370: Please drop anacron from task-desktop

[Adam Borowski]

On Fri, Mar 08, 2019 at 09:47:34AM +, Simon McVittie wrote:
> On Thu, 07 Mar 2019 at 17:07:18 -0400, David Bremner wrote:
> > Holger Wansing  writes:
> > > Are there still many packages, that don't rely on systemd timer units?
> > 
> > Presumably packages that work without systemd, but still need to
> > periodic activity?
> 
> Default installations of Debian boot with systemd, and if a sysadmin
> chooses to switch to another init system, it's up to them to replace
> its functionality (or at least the parts of its functionality they
> want). Needing to install anacron in addition to sysvinit seems
> reasonable.

Yeah, but it's not something that should require a manual action --
especially considering that implementing this well is easy.

> Maybe task-desktop should depend on systemd-sysv | anacron?

Right, but with the reversed order.  This might be a bit unobvious, but:
• on all systemd installs, the dependency is moot (no matter the order)
• on non-systemd, your ordering would make apt try to switch inits instead
  of pulling in anacron
• the only case where non-first dependencies are ignored, B-Deps on official
  buildds, doesn't matter for a task package
 
> That doesn't *necessarily* mean you need anacron, or even cron. Many
> cron jobs now have a corresponding systemd timer; if you are running
> systemd, the cron job starts, detects that it is unnecessary, and exits,
> which is an overly-complicated way to do nothing.

Which raises a question: why would we want that redundant systemd timer?
The cron job can serve everyone, timer only systemd users.  Twice the work,
twice as many configurations to test -- for no gain.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄

Bug#922729: bug is in arch-test

[Adam Borowski]

> Other than uninstalling arch-test, there appears to be no way to tell
> debootstrap to ignore, or at least downgrade arch-test results to a
> warning. I'm not sure if a commandlinne option and/or environment
> variable would be the preferred workaround.

It's a bug in arch-test -- one I don't quite understand: even if newer
compilers could have dropped the use of SWP, I can't seem to reproduce this
failure even on jessie.  A Pine64 with CONFIG_ARMV8_DEPRECATED=n on kernel
5.0-rc6, yet any jessie programs other than ghc work -- I remember anything
with thread support crashing immediately.  No idea what could have changed.

I've dropped the check (both for SIGILL and for whether SWP gets silently
ignored) -- worst case, there'll be false positives where debootstrap
installs something that doesn't work.

In general, I don't think debootstrap should work around bugs elsewhere;
the design principle for arch-test is to err on the false positive rather
than false negative side, thus setups that fail the test should be nearly
useless.

For the record, here's the list of checks above basic syscall test:
* armhf: dmb (ARMv7)
* i386: cmovz (686)
* powerpc: fsel (!SPE)
* powerpcspe: efscfsi (SPE)
* ppc64el: mtvsrd (POWER8)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄

Bug#905793: sharing swap is bad idea

[Adam Borowski]

> 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.

Sharing swap leads to data loss if any kind of hibernate (incl. hybrid
suspend) is involved.  Thus, it really don't want to allow that by default.

If you know the danger, you can do so manually.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ So a Hungarian gypsy mountainman, lumberjack by day job,
⣾⠁⢰⠒⠀⣿⡁ brigand by, uhm, hobby, invented a dish: goulash on potato
⢿⡄⠘⠷⠚⠋⠀ pancakes.  Then the Polish couldn't decide which of his
⠈⠳⣄ adjectives to use for the dish's name.

Bug#902321: task-desktop: please install fonts-symbola by default

[Adam Borowski]

Package: task-desktop
Version: 3.44
Severity: wishlist

Hi!
As much as many of us consider emojis to be a big mistake on part of the
Unicode consortium, it's undeniable that these characters see quite wide
use these days.  Thus, at least one font that convers this range should
be installed by default.

Of these, it seems there are only two general-purpose fonts:
* fonts-symbola (nice)
* ttf-unifont (ugly and pixellated)

There are also fonts that have colourful images instead of glyphs, but these
are unfit for most programs, and are not supported by our current libraries. 
It's an issue of so-called "text presentation" vs "emoji presentation" that,
according to the Unicode standard, programs should select based on
environment being "informal like texting and chats" vs "formal like word
processing" (TR51 §4 and §2).  Text presentation is also needed when the
character's color is to be set via metadata such as CSS or ANSI SGR.

Thus, even library support issues aside, we need at least one font that
provides text presentation.  Package firefox-esr includes
/usr/lib/firefox-esr/fonts/EmojiOneMozilla.ttf which provides emoji
presentation, but is not available to other programs via fontconfig
for the above reasons.

Thus, please add "Recommends: fonts-symbola" to task-desktop.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-rc1-debug-00028-ga124d3bef9d4 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages task-desktop depends on:
ii  desktop-base9.0.7
pn  tasksel 
ii  xorg1:7.7+19
ii  xserver-xorg-input-all  1:7.7+19
ii  xserver-xorg-video-all  1:7.7+19

Versions of packages task-desktop recommends:
ii  alsa-utils  1.1.6-1
pn  anacron 
pn  avahi-daemon
pn  eject   
ii  firefox-esr 60.0.2esr-1
ii  iw  4.14-0.1
pn  libnss-mdns 
ii  libu2f-udev 1.1.5-1
pn  sudo
pn  task-gnome-desktop | task-xfce-desktop | task-kde-desktop | ta  
ii  xdg-utils   1.1.3-1

task-desktop suggests no packages.

Bug#826709: Doesn't mention --foreign in help output

[Adam Borowski]

On Mon, Apr 02, 2018 at 03:27:58PM +0200, Adam Borowski wrote:
> On Sun, Apr 01, 2018 at 11:24:14AM +0800, Paul Wise wrote:
> > 
> > > +   if [ "$HOST_ARCH" = "amd64" ] && [ "$ARCH" = "i386" ] ; 
> > > then
> > > +   # i386 binary can be run on amd64 host
> > 
> > It is a bad idea to hard-code this and hard-code it for only two
> > arches
> 
> Especially that amd64 hosts only _usually_ can run i386.

> Thus, a hard-coded list would do more harm than good.  Sure, most of the
> time it'd work, but it's the unusual cases when you need accurate error
> messages.
> 
> 
> > using arch-test and falling back to a more comprehensive list
> > would be much better
> 
> Indeed, making arch-test a Recommends for debootstrap would be a good idea:
> it's a small package, systems that act as hosts are big enough that giving
> the user helpful error messages is worth it.

Patch implementing this attached.

> There is one caveat: binfmt uses interpreters relative to the current
> process' root directory, thus testing outside the chroot doesn't imply you
> have an interpreter in the right place inside.

Implemented in arch-test 0.11, via -c $CHROOT.  There are rumours incoming
qemu has some other magic that makes this dance not required, too.

> > I prefer the message I wrote in my initial bug report:
> > 
> >   This machine cannot run binaries for architecture armhf
> >   There are two options to work around this:
> > 
> >   Use qemu-debootstrap instead of debootstrap
> > 
> >   Use debootstrap --foreign here and
> >   use debootstrap --second-stage on armhf

My stab at the patch gives only a terse error message, it's obvious how to
extend it.

> As an author of a hammer, I'm probably biased towards using it.  But,
> there's at least one possibility: before calling any complex tool inside the
> chroot, you can run something dead simple like /bin/true.  If that fails,
> then either you have a non-executable arch, glibc is broken or missing, or
> something else went bad while debootstrapping.  These alternatives can't be
> distinguished between (this is where arch-test would be better), but at
> least we'd isolate that whole class of problems from other reasons mount can
> fail.

As it takes only a single line to implement this fallback, it's a no-brainer
to include it.

Thus, I'm attaching three patches:
1. run in_target /bin/true before anything else in the second stage
2. check arch-test if installed
3. Recommend: arch-test

(Dropped #693219 from CC, it's about improving the prose of error messages,
thus these patches don't belong there.)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC?
⠈⠳⣄
>From 6a0f9d144c71d3450094faf031f604ce3c1a12a6 Mon Sep 17 00:00:00 2001
From: Adam Borowski <kilob...@angband.pl>
Date: Thu, 5 Apr 2018 19:45:11 +0200
Subject: [PATCH 1/3] Check if in-target /bin/true works before more complex
 stuff.

The first command of second stage used to be mount /proc, which has plenty
of other reasons to fail, and people tend to try those.  Instead, check
first if in-target binaries are executable at all.  They can fail because
of arch unsupported by the machine (and no qemu), missing or borked libc,
borked ld-linux -- so let's separate those from mount fails.
---
 scripts/debian-common | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/debian-common b/scripts/debian-common
index 36989a2..4ab1fe8 100644
--- a/scripts/debian-common
+++ b/scripts/debian-common
@@ -59,6 +59,8 @@ first_stage_install () {
 }
 
 second_stage_install () {
+	in_target /bin/true
+
 	setup_dynamic_devices
 
 	x_feign_install () {
-- 
2.17.0

>From 744feab59f0a794e373a575844a9ec78de18c0b2 Mon Sep 17 00:00:00 2001
From: Adam Borowski <kilob...@angband.pl>
Date: Thu, 5 Apr 2018 23:28:30 +0200
Subject: [PATCH 2/3] Use arch-test if installed to check whether second stage
 is possible.

---
 debootstrap | 16 
 1 file changed, 16 insertions(+)

diff --git a/debootstrap b/debootstrap
index 9b547ad..772e443 100755
--- a/debootstrap
+++ b/debootstrap
@@ -526,6 +526,22 @@ fi
 
 ###
 
+if [ -x /usr/bin/arch-test ] && am_doing_phase second_stage; then
+	if doing_variant fakechroot; then
+		ret=0; arch-test "$ARCH" || ret=$?
+	else
+		ret=0; arch-test -c "$TARGET" "$ARCH" || ret=$?
+	fi
+
+	case $ret in
+	0)	info ARCHEXEC "Target architecture can be executed" ;;
+	1)	error 1 ARCHNOTEXEC "Unable to execute target architecture" ;;
+	*)	info ARCHEXECUNKNOWN "Can't verify that target arch works" ;;
+	esac
+fi
+
+###

Bug#693219: Bug#826709: Doesn't mention --foreign in help output

[Adam Borowski]

On Sun, Apr 01, 2018 at 11:24:14AM +0800, Paul Wise wrote:
> CCing the maintainer of arch-test who will probably have some input.
> 
> On Sun, 2018-04-01 at 11:32 +0900, Hideki Yamane wrote:
> 
> > +   if [ "$HOST_ARCH" = "amd64" ] && [ "$ARCH" = "i386" ] ; then
> > +   # i386 binary can be run on amd64 host
> 
> It is a bad idea to hard-code this and hard-code it for only two
> arches

Especially that amd64 hosts only _usually_ can run i386.  It's a kernel
config option that happens to be enabled in Debian kernels, but may be
omitted from derivative or self-built ones, usually for reasons of space and
security (compat syscalls and ioctls are a source of bugs, sometimes
exploitable).  Thus, CONFIG_IA32_EMULATION might or might not be enabled.

On x86 I'm not aware of any 64-bit only hardware, but elsewhere, 32-bit
compat is optional -- skipping it can make chips cheaper and more
power-efficient, thus arm64 is often incapable of running armhf or armel.
Even on armhf, the manufacturer may choose to skip costly synchronization
needed for obsolete SWP instructions required by armel, which means
debootstrap (strictly single-threaded I think) will succeed but installed
system will run into mysterious corruption.

Thus, a hard-coded list would do more harm than good.  Sure, most of the
time it'd work, but it's the unusual cases when you need accurate error
messages.


> using arch-test and falling back to a more comprehensive list
> would be much better

Indeed, making arch-test a Recommends for debootstrap would be a good idea:
it's a small package, systems that act as hosts are big enough that giving
the user helpful error messages is worth it.

It wouldn't harm new (not yet supported archs) as answer "can't test"
(return code 2) is no different than arch-test being not installed.

There is one caveat: binfmt uses interpreters relative to the current
process' root directory, thus testing outside the chroot doesn't imply you
have an interpreter in the right place inside.  Usually, debootstrap is
called by tools after doing:
mkdir -p $CHROOT/usr/bin && cp -p /usr/bin/qemu-6502-static $CHROOT/usr/bin/
but it's a step you're likely to forget.  I guess, this can be done by
adding an option to arch-test to copy the helper into the chroot, call
chroot(2) then test inside.

Obviously, the above is not a concern for hardware or whole-machine
emulation (arch-test -n).


> I prefer the message I wrote in my initial bug report:
> 
>   This machine cannot run binaries for architecture armhf
>   There are two options to work around this:
> 
>   Use qemu-debootstrap instead of debootstrap
> 
>   Use debootstrap --foreign here and
>   use debootstrap --second-stage on armhf

As an author of a hammer, I'm probably biased towards using it.  But,
there's at least one possibility: before calling any complex tool inside the
chroot, you can run something dead simple like /bin/true.  If that fails,
then either you have a non-executable arch, glibc is broken or missing, or
something else went bad while debootstrapping.  These alternatives can't be
distinguished between (this is where arch-test would be better), but at
least we'd isolate that whole class of problems from other reasons mount can
fail.


Meow!
-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ

Bug#883547: flash-kernel: please allow flavourless kernels

[Adam Borowski]

On Tue, Dec 19, 2017 at 04:04:34AM +0100, Adam Borowski wrote:
> On Mon, Dec 18, 2017 at 03:08:08PM -0800, Vagrant Cascadian wrote:
> > I think the following patch should work for this, by setting:
> > 
> > Kernel-Flavor: any
> 
> > The patch significantly refactors the use of the check_kflavor function,
> 
> > I haven't done extensive testing yet, but I could go ahead any push this
> > myself once I've done more tests, if nobody objects.
> 
> Works for me on Odroid-U2 (armhf).
> 
> I'll try on Pine64 once a kernel is built, in the morning (it takes two ages
> and three aeons).

Also works; I guess you already tested on a Pine64 but the amount of manual
setup required makes systems different.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#883547: flash-kernel: please allow flavourless kernels

[Adam Borowski]

On Mon, Dec 18, 2017 at 03:08:08PM -0800, Vagrant Cascadian wrote:
> I think the following patch should work for this, by setting:
> 
> Kernel-Flavor: any

> The patch significantly refactors the use of the check_kflavor function,

> I haven't done extensive testing yet, but I could go ahead any push this
> myself once I've done more tests, if nobody objects.

Works for me on Odroid-U2 (armhf).

I'll try on Pine64 once a kernel is built, in the morning (it takes two ages
and three aeons).


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#883547: flash-kernel: please allow flavourless kernels

[Adam Borowski]

Package: flash-kernel
Version: 3.88
Severity: wishlist

Hi!
If for whatever reason you want or need to build your own kernels, the
preferred way these days is "make bindeb-pkg".  It is also a good idea
to use CONFIG_LOCALVERSION_AUTO=y, which marks the exact tree used to
build the kernel.

However, with this option, the version is _appended_ after local version,
thus making it hard to add that "-armmp" string.

I found no way to override this, other than manually editing
--- functions~  2017-08-03 05:01:54.0 +0200
+++ functions   2017-12-05 02:39:54.113903579 +0100
@@ -775,11 +775,6 @@
done
 fi
 
-if [ "$kfile_suffix" = "$kfile" ]; then
-   echo "Kernel $kfile does not match any of the expected flavors 
($kflavors), therefore not writing it to flash." >&2
-   exit 0
-fi
-
 echo "flash-kernel: installing version $kvers" >&2
 
 mkarch="$(get_mkimage_architecture $kvers)"


Just allowing an empty string flavour doesn't work, as it'll still want a -
after the version.

Thus, it would nice if there was an override -- or, perhaps, I'm holding it
wrong?


Meow!
-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 4.14.0-00115-g3d7c587c4c1b (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  devio  1.2-1.2+b1
ii  initramfs-tools0.130
ii  linux-base 4.5
ii  mtd-utils  1:2.0.1-1
ii  ucf3.0036

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2017.09+dfsg1-3

flash-kernel suggests no packages.

-- debconf information excluded

Bug#880152: flash-kernel: please echo cmdline before starting the kernel

[Adam Borowski]

Package: flash-kernel
Version: 3.87
Severity: wishlist

Hi!
It would be nice if you could echo kernel cmdline before passing control.
Currently there's:
echo "Booting Debian from ${devtype} ${devnum}:${partition}..."
I can edit the bootscript myself, but having this by default would help
anyone who sees:

.
Found U-Boot script /boot.scr
3075 bytes read in 17 ms (175.8 KiB/s)
## Executing script at 5000
4883208 bytes read in 191 ms (24.4 MiB/s)
54983 bytes read in 28 ms (1.9 MiB/s)
5465464 bytes read in 204 ms (25.5 MiB/s)
Booting Debian 4.14.0-rc7-01315-g371bf91a0a3f from mmc 0:1...
Kernel image @ 0x4200 [ 0x00 - 0x4a8308 ]
## Flattened Device Tree blob at 4300
   Booting using the fdt blob at 0x4300
   Loading Ramdisk to 4fac9000, end 4578 ... OK
   Loading Device Tree to 4fab8000, end 4fac86c6 ... OK

Starting kernel ...

`
then nothing.

(This particular board uses bootscript.odroid, but this extra line can't
hurt elsewhere.)


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 4.14.0-rc3-00467-gdcd7e571b12b (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.64
ii  devio  1.2-1.2+b1
ii  initramfs-tools0.130
ii  linux-base 4.5
ii  mtd-utils  1:2.0.1-1
ii  ucf3.0036

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2017.09+dfsg1-3

flash-kernel suggests no packages.

-- debconf information:
  flash-kernel/linux_cmdline: quiet

Bug#859386: current behaviour looks correct to me

[Adam Borowski]

> The HOME environment variable does not have to be present, programs
> must fall back to the value in the passwd file. $SHELL does not do this
> in the following two places.
>
>  * When running cd without any argument
>  * When expanding tilde (~) characters

Nope, there's nothing that says they "must" fall back to anything.  The very
docs you linked to:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html
> http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_01
explicitly say the results are unspecified.  $HOME should be set by the
login environment, but if it's not set, you get to keep the pieces.

You filed copies of this bug on three shells: busybox[sh], dash, bash.
Their policies are:
* busybox: no superfluous features are added, often even required but
  non-important features get skipped
* dash: POSIXLY_CORRECT, even when POSIX and common sense disagree
Upstreams of those two will thus almost certainly reject such a change.
* bash: no particular policy
Yet, because the two other shells don't invent a fallback for missing $HOME,
adding it bash would introduce a difference in behaviour that can be avoided
by keeping status quo.

Thus, while I understand your reason (extra robustness for user error), I'd
recommend WONTFIXing all three copies of this bug.


Please say if I missed something.
-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Bug#858308: flash-kernel: documentation for upgrading Odroid-U2/U3 to flash-kernel

[Adam Borowski]

On Tue, Mar 21, 2017 at 09:45:01AM +, Ian Campbell wrote:
> On Tue, 2017-03-21 at 00:31 +0100, Adam Borowski wrote:
> > Package: flash-kernel
> 
> Not sure that this (or u-boot) is really the best place for it, it
> certainly wouldn't occur to look under either of those packages for
> such documentation.

This doc is for converting to flash-kernel (and other modern bits), thus I
went for flash-kernel first.  You guys know what would be appropriate better
than me.

> Perhaps a wiki page under wiki.debian.org/DebianOn might be better? Or
> the installation guide perhaps?

It's not installation, merely upgrading from parts shipped by the vendor. 
You need their parts to even boot from eMMC, and the only way I know to put
Debian pieces to eMMC is... booting from said eMMC.

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Bug#858308: flash-kernel: documentation for upgrading Odroid-U2/U3 to flash-kernel

[Adam Borowski]

On Tue, Mar 21, 2017 at 06:45:30AM +0100, Geert Stappers wrote:
> On Tue, Mar 21, 2017 at 12:31:46AM +0100, Adam Borowski wrote:
> > If you're booting from a SD card, skip until running sd-fusing.sh
> > Edit sd_fusing.sh, change sector numbers to those listed in
>  s/sd_fusing.sh/sd-fusing.sh/
> > ./sd-fusing.sh /dev/mmcblk0boot0
>  s/sd-fusing.sh/sd_fusing.sh/
> 
> Hyphen or underscore

D'oh!

> > what doesn't work
> > -
> > 
> > * rebooting: the machine gets stuck and needs to be physically power-cycled

BTW, Vagrant reports that rebooting _usually_ works on his U3, it rebooted
correctly only once on my U2.  Never had such a problem with the vendor
kernel before.

> > * audio
> > 
> > * the kernel whines about broken HDMI, video capture -- I can't even test
> >   those but I don't care
> 
> Please add   'Whoever can test HDMI, please report your milage'

Okay.

> > * the machine gets very hot; with 3.8 it never was even noticeably warm
> 
> What does mean: Kernel 3.8 is good  or bad?  Please remove ambigous mean

I dropped this entire line: that "very hot" is up to 77⁰ (at 70⁰ right now
in the middle of a libreoffice build) and never tripped, thus I have nothing
but subjective feelings from touching it by hand.  It's not unlikely the
difference comes from me having moved the machine, it was AFAIR resting on a
big whole-metal router before which could have drained heat well.

The fun thing is that all those years before I bought a fan for this box,
but because of delusions of replacing my main machine with this non-noisy
thing never actually mounted it.  Could do it now and play with overclocking
to 2GHz as Samsung used to advertise the U2 can do...


New version attached.

Also, I'm not married to being the sole editor of this file, please feel
free to make any edits you want...

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!
How to upgrade an Odroid-U2/U3 to the modern kernel.


requirements


While strictly speaking, with perfect luck you don't need any extra bits,
in reality you need at least:
* an eMMC reader (if you bought your eMMC from Hardkernel, the included
  adapter works well in _some_ SD readers)
* a serial console (UART).  If you don't have one yet, with shipping it
  costs its weight in gold -- but fortunately it's not too heavy.


u-boot and other pre-kernel gubbins
---

apt install u-boot-exynos
wget http://odroid.in/guides/ubuntu-lfs/boot.tar.gz

Replace u-boot.bin from that tarball (2013 Samsung-private build) with
/usr/lib/u-boot/odroid/u-boot.bin (2016 vanilla), the other pieces are ok.

If you're booting from a SD card, skip until running sd_fusing.sh

On eMMC:

Edit sd_fusing.sh, change sector numbers to those listed in
/usr/share/doc/u-boot-exynos/README.odroid.gz :
.
signed_bl1_position=0
bl2_position=30
uboot_position=62
tzsw_position=2110
`

You may notice that these positions look wrong: on your eMMC (as originally
shipped) you have all those pieces in "SD" positions.  Tʜᴏꜱᴇ ᴀʀᴇ ᴅᴇᴄᴏʏꜱ ᴍᴀᴅᴇ
ᴛᴏ ᴡᴀꜱᴛᴇ ʏᴏᴜʀ ᴛɪᴍᴇ!  Replacing them does exactly nothing, the real bits are
on hidden parts of the eMMC.

There are rumours that it is possible to access them from a SD reader by a
"partition switch", but despite hours of searching I found no information
how to do that.  The only way seems to be using the U2 itself.  Which is a
dangerous thing as if anything goes wrong you won't be able to boot. 
Fortunately, recovery is possible with a micro-USB cable and a SD card with
a special image: http://forum.odroid.com/viewtopic.php?f=53=969 -- I did
not have the need to test that, though.

On the U2, you need to unlock the secret partition first:
https://www.kernel.org/doc/Documentation/mmc/mmc-dev-parts.txt
.
echo 0 > /sys/block/mmcblk0boot0/force_ro
`
The device name does vary: it's /dev/mmcblk0 on some kernels (vendor and
Debian's 4.10-trunk-armmp), /dev/mmcblk1 on others (Debian 4.9 and vanilla
4.11-rc2).  Only boot0 has anything, boot1 and rpmb are full of zeroes.

Run:
.
./sd_fusing.sh /dev/mmcblk0boot0
`
Watch the output -- it has no error detection at all and will lie that all
went ok even if it didn't!

Now pray and reboot.


u-boot console
--

Fortunately, unlike some other SoCs, modern u-boot _can_ boot both vendor
and mainline kernels.  Be prepared to do some manual loading, though.  For
convenience, here are relevant bits of old /boot/boot.scr:
.
setenv bootcmd "fatload mmc 0:1 0x40008000 zImage; fatload mmc 0:1 0x4200 
uInitrd; bootm 0x40008000 0x4200"
setenv bootargs "console=tty1 console=ttySAC1,115200n8 
root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro  mem=2047M"
`

If b

Bug#858308: flash-kernel: documentation for upgrading Odroid-U2/U3 to flash-kernel

[Adam Borowski]

Package: flash-kernel
Version: 3.76
Severity: wishlist
Tags: patch

Hi!
Please include the attached file in /usr/share/doc of either flash-kernel or
perhaps u-boot-exynos.  It documents how to upgrade a system using the
vendor image to Debian's u-boot, flash-kernel and modern kernels.

There already is a somewhat similar file,
/usr/share/doc/u-boot-exynos/README.odroid.gz, but it's quite obsolete
(meant for 3.8 without packaged tools) and vague.

I've also tried to explain concepts ARM porters may take for granted
but are not obvious to an average DD-level reader.


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 4.11.0-rc3-00017-ge449e163607e (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.60
ii  devio  1.2-1.2+b1
ii  initramfs-tools0.127
ii  linux-base 4.5
ii  mtd-utils  1:2.0.0-1
ii  ucf3.0036

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2016.11+dfsg1-3

flash-kernel suggests no packages.

-- debconf information:
* flash-kernel/linux_cmdline: console=tty1 console=ttySAC1,115200n8 
root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro  mem=2047M 
vm.min_free_kbytes=16384
How to upgrade an Odroid-U2/U3 to the modern kernel.


requirements


While strictly speaking, with perfect luck you don't need any extra bits,
in reality you need at least:
* an eMMC reader (if you bought your eMMC from Hardkernel, the included
  adapter works well in _some_ SD readers)
* a serial console (UART).  If you don't have one yet, with shipping it
  costs its weight in gold -- but fortunately it's not too heavy.


u-boot and other pre-kernel gubbins
---

apt install u-boot-exynos
wget http://odroid.in/guides/ubuntu-lfs/boot.tar.gz

Replace u-boot.bin from that tarball (2013 Samsung-private build) with
/usr/lib/u-boot/odroid/u-boot.bin (2016 vanilla), the other pieces are ok.

If you're booting from a SD card, skip until running sd-fusing.sh

On eMMC:

Edit sd_fusing.sh, change sector numbers to those listed in
/usr/share/doc/u-boot-exynos/README.odroid.gz :
.
signed_bl1_position=0
bl2_position=30
uboot_position=62
tzsw_position=2110
`

You may notice that these positions look wrong: on your eMMC (as originally
shipped) you have all those pieces in "SD" positions.  Tʜᴏꜱᴇ ᴀʀᴇ ᴅᴇᴄᴏʏꜱ ᴍᴀᴅᴇ
ᴛᴏ ᴡᴀꜱᴛᴇ ʏᴏᴜʀ ᴛɪᴍᴇ!  Replacing them does exactly nothing, the real bits are
on hidden parts of the eMMC.

There are rumours that it is possible to access them from a SD reader by a
"partition switch", but despite hours of searching I found no information
how to do that.  The only way seems to be using the U2 itself.  Which is a
dangerous thing as if anything goes wrong you won't be able to boot. 
Fortunately, recovery is possible with a micro-USB cable and a SD card with
a special image: http://forum.odroid.com/viewtopic.php?f=53=969 -- I did
not have the need to test that, though.

On the U2, you need to unlock the secret partition first:
https://www.kernel.org/doc/Documentation/mmc/mmc-dev-parts.txt
.
echo 0 > /sys/block/mmcblk0boot0/force_ro
`
The device name does vary: it's /dev/mmcblk0 on some kernels (vendor and
Debian's 4.10-trunk-armmp), /dev/mmcblk1 on others (Debian 4.9 and vanilla
4.11-rc2).  Only boot0 has anything, boot1 and rpmb are full of zeroes.

Run:
.
./sd-fusing.sh /dev/mmcblk0boot0
`
Watch the output -- it has no error detection at all and will lie that all
went ok even if it didn't!

Now pray and reboot.


u-boot console
--

Fortunately, unlike some other SoCs, modern u-boot _can_ boot both vendor
and mainline kernels.  Be prepared to do some manual loading, though.  For
convenience, here are relevant bits of old /boot/boot.scr:
.
setenv bootcmd "fatload mmc 0:1 0x40008000 zImage; fatload mmc 0:1 0x4200 
uInitrd; bootm 0x40008000 0x4200"
setenv bootargs "console=tty1 console=ttySAC1,115200n8 
root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro  mem=2047M"
`

If boot fails, type the commands inside bootcmd manually, perhaps replacing
"fatload" with "ext4load" (also helpful "ext4ls mmc 0:1" and so on).  The
"bootm" command is wrong: you need to replace it with "bootz".


fat -> ext4
---

Debian's kernel installation is heavily married to POSIX features that are
unavailable on fat.  And the Odroid image uses fat for /boot (and so does
every single SoC image I've seen).  Changing ln to cp and so on is not
enough, I've gave up and reformatted.  Tar your /boot up, unmount, mkfs.ext4
/dev/mmcblk0p1, untar, recheck that the files are in 

Bug#855489: lilo-installer: fails in postinst: sfdisk: invalid option -- '1'

[Adam Borowski]

Package: lilo-installer
Version: 1.51
Severity: grave
Justification: renders package unusable


(reported by "jim" on #debian-boot)

After choosing LILO rather than GRUB as the boot loader, lilo-installer fails
when invoking sfdisk.

Tested on /dev/vda and /dev/vda1.


A totally untested idea for a patch attached.
>From 227e1812e381be61b40330e372d62348a9e8dd75 Mon Sep 17 00:00:00 2001
From: Adam Borowski <kilob...@angband.pl>
Date: Sun, 19 Feb 2017 05:43:39 +0100
Subject: [PATCH] Reverse the order of arguments to sfdisk -A, add a space.

During a massive overhaul in util-linux 2.26, sfdisk -A accidentally changed
meaning to --append.  This change was later reverted, but while doing so the
parsing and argument order have changed.
---
 debian/postinst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/postinst b/debian/postinst
index 58ab0ce..f81f89b 100755
--- a/debian/postinst
+++ b/debian/postinst
@@ -155,7 +155,7 @@ if (echo "${bootdev}" | grep -v '/c[0-9]d[0-9]$' | grep -q 
'[0-9]$') \
if [ "${RET}" = "true" ]; then
pnum=$(echo ${bootdev} | sed 's/^.*\([0-9]\+\)$/\1/')
echo -n "I: Setting partition to active..." >&2
-   sfdisk -A${pnum} ${disc_offered_devfs}
+   sfdisk --activate ${disc_offered_devfs} ${pnum}
echo "done." >&2
fi
fi
@@ -174,7 +174,7 @@ if [ "${raid_boot}" = no ] && (! fdisk -l 
"$disc_offered_devfs" | grep '^/dev/'
# /boot.
pnum="$(echo "$bootfs" | sed 's/^.*\([0-9]\+\)$/\1/')"
echo -n "I: Setting partition $bootfs to active..." >&2
-   sfdisk -A"$pnum" "$disc_offered_devfs"
+   sfdisk --activate ${disc_offered_devfs} ${pnum}
echo "done." >&2
fi
 fi
-- 
2.11.0

Bug#854924: untested patch

[Adam Borowski]

Here's the obvious but untested patch.

-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11
--- clock-setup-0.131/finish-install.d/10clock-setup~	2016-01-21 05:00:53.0 +0100
+++ clock-setup-0.131/finish-install.d/10clock-setup	2017-02-12 02:08:57.930763126 +0100
@@ -96,13 +96,17 @@
 
 db_get clock-setup/utc
 if [ "$RET" = true ]; then
-	sed -i -e 's:^UTC="no":UTC="yes":' -e 's:^UTC=no:UTC=yes:' $utcfile
+	if [ -e $utcfile ]; then
+		sed -i -e 's:^UTC="no":UTC="yes":' -e 's:^UTC=no:UTC=yes:' $utcfile
+	fi
 	if [ -e /target/etc/adjtime ]; then
 		sed -i -e 's:^LOCAL$:UTC:' /target/etc/adjtime
 	fi
 	OPT="--utc"
 else
-	sed -i -e 's:^UTC="yes":UTC="no":' -e 's:^UTC=yes:UTC=no:' $utcfile
+	if [ -e $utcfile ]; then
+		sed -i -e 's:^UTC="yes":UTC="no":' -e 's:^UTC=yes:UTC=no:' $utcfile
+	fi
 	if [ -e /target/etc/adjtime ]; then
 		sed -i -e 's:^UTC$:LOCAL:' /target/etc/adjtime
 	fi

Bug#854924: clock-setup: produces bogus /etc/default/rcS then doesn't set hwclock

[Adam Borowski]

Package: clock-setup
Version: 0.131
Severity: serious
Justification: Policy 10.7.3


Upon installation with current d-i (stretch RC 2), clock-setup produces an
empty /etc/default/rcS with 000 permissions.  This breaks subsequent
upgrades from systemd to sysvinit, unless the user knows how to fix this
manually.  Well, answering 'i' to conffile conflict prompt is not rocket
surgery, but it's not possible when unattended/etc, and such prompts for
conffiles unmodified by the user are considered RC.

Moreover, because of "set -e", clock-setup then fails to process the
remaining of the script, which would set the hwclock.  This failure is not
displayed to the user.


The first part is caused by #854923 in busybox, but even if that bug is
fixed, "set -e" will make the second part fail.


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-rc7-debug-ssd-abort+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#854923: busybox: "sed -i nonexistent" creates bogus files

[Adam Borowski]

Package: busybox
Version: 1:1.22.0-19+b1
Severity: important

busybox sed -i -e 's/foo/bar/' foo
--  1 root 2689302520   0 Feb 12 01:13 foo

Impact includes for example breaking upgrading from systemd to sysvinit
after installing via stretch's d-i.



-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-rc7-debug-ssd-abort+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages busybox depends on:
ii  libc6  2.24-9

busybox recommends no packages.

busybox suggests no packages.

-- no debconf information

Bug#852646: task-xfce-desktop: please recommend atril not evince

[Adam Borowski]

Package: task-xfce-desktop
Version: 3.39
Severity: wishlist

Hi!
Currently, the XFCE task pulls in evince, whose interface is really out of
place outside of Gnome.  It'd be far better to install atril instead (from
Mate) -- it blends in with XFCE seamlessly.  It also doesn't suffer from a
number of weird decisions taken by the Gnome project that make the user
interface really inconsistent with XFCE components.

Atril is a fork of Evince, so base functionality is the same.


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.5+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#851429: installation-reports: mounting CD fails on qemu-system-aarch64

[Adam Borowski]

On Sun, Jan 15, 2017 at 01:12:53AM +, Steve McIntyre wrote:
> On Sat, Jan 14, 2017 at 10:34:18PM +0100, Adam Borowski wrote:
> >I'm afraid that regular arm64 d-i images fail to detect qemu's CD-ROM, and
> >there's apparently no way to direct it to load udebs from a network mirror
> >like mini.iso does.  On the other hand, installation with mini.iso works
> >well.
> >
> >The failing step is "Detecting hardware to find CD-ROM drives".
> >
> >CD=debian-stretch-DI-rc1-arm64-netinst.iso
> >NET="-net bridge -net nic"
> >
> >qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \
> > -bios /usr/share/qemu-efi/QEMU_EFI.fd -m 2048 $NET \
> > -drive file="$DISK",cache=writeback,index=0,media=disk,format=raw \
> > -drive file="$CD",cache=writeback,index=1,media=cdrom -boot d
> 
> I think the problem is with your setup. I've just booted that exact
> netinst image happily using
> 
> qemu-system-aarch64 -m 4G -cpu cortex-a57 -M virt -smp 8 -nographic
> -pflash AAVMF_CODE.fd -pflash AAVMF_VARS.fd -drive
> file=/scratch/iso/debian-stretch-DI-rc1-arm64-netinst.iso,id=cdrom,if=none,media=cdrom
> -device virtio-scsi-device -device scsi-cd,drive=cdrom -k en-gb
> -netdev user,id=eth0 -device virtio-net-device,netdev=eth0

Ie, virtio vs emulating a real piece of hardware.

The problem here, though, is that qemu picked a piece of hardware that's old
crap that's not expected in any physical arm64 gardware.  I guess it'd be
good to ask them to upgrade, like they did with the Cirrus card on x86.

Ordinarily I'd want you to support this "hardware" as QEMU is a major
platform (at least the one most available), but in this case, with the
extensive incantations required to get it running, requiring virtio might be
acceptable.  I refuse to say "arguments" rather than "incantations" as
the former is for specifying what the program should do and what you want
altered from reasonable defaults, rather than a massive ritual that needs to
be performed just to get basic functionality, with every piece involving
lengthy research and breakage/data loss if you skip it.  Like, my line lacks
a flash for storing EFI vars, meaning that it will install correctly (with
mini.iso), work when rebooted, even upon multiple reboots, then fail to work
anymore once you shut down qemu and start it again.

So I wonder what's the best way to proceed.  Probably documenting what's
needed might be a good step.

> and it's running the installer right now with udebs from the netinst
> iso. What version of qemu-efi are you using for
> /usr/share/qemu-efi/QEMU_EFI.fd?

0~20161202.7bbe0b3e-1 (current unstable and stretch).

-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#851429: installation-reports: mounting CD fails on qemu-system-aarch64

[Adam Borowski]

Package: installation-reports
Severity: normal

Hi!
I'm afraid that regular arm64 d-i images fail to detect qemu's CD-ROM, and
there's apparently no way to direct it to load udebs from a network mirror
like mini.iso does.  On the other hand, installation with mini.iso works
well.

The failing step is "Detecting hardware to find CD-ROM drives".

CD=debian-stretch-DI-rc1-arm64-netinst.iso
NET="-net bridge -net nic"

qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \
 -bios /usr/share/qemu-efi/QEMU_EFI.fd -m 2048 $NET \
 -drive file="$DISK",cache=writeback,index=0,media=disk,format=raw \
 -drive file="$CD",cache=writeback,index=1,media=cdrom -boot d


Host's data:
qemu-*   1:2.8+dfsg-1 amd64
qemu-efi 0~20161202.7bbe0b3e-1
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.3+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#827562: use Depends: | rather than Recommends:

[Adam Borowski]

The proposal here, downgrading Depends: to Recommends:, indeed doesn't work
that well because of reasons mentioned in the discussion.

However, this would be better: "Depends: light-locker | xscreensaver".
It will install light-locker by default where available, make task-xfce
installable on kfreebsd and hurd (where it is the default desktop!), and
allow people to go with xscreensaver without having to manage packages
marked as auto.

light-locker suffers from a number of problems that make the decision of
designating it as the default quite puzzling.


Meow!
-- 
u-boot problems can be solved with the help of your old SCSI manuals, the
parts that deal with goat termination.  You need a black-handled knife, and
an appropriate set of candles (number and color matters).  Or was it a
silver-handled knife?  Crap, need to look that up.

Bug#832485: task-xfce-desktop: uninstallable on kfreebsd due to dependency on light-locker

[Adam Borowski]

Package: task-xfce-desktop
Version: 3.35
Severity: important

Hi!
I'm afraid that the xfce task can't be currently installed on kfreebsd. 
This is especially nasty as xfce is the default DE on that arch.

The reason is that it depends on light-locker, which is Linux only.
A possible solution is to change that dependency to:
Depends: light-locker|xscreensaver
which would have the extra benefit of kind of alleviating #827562,
with light-locker as the first alternative per the XFCE's team wishes.
If you think that's a bad idea, the dependency could be arch specific.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages task-xfce-desktop depends on:
ii  lightdm   1.18.2-2
ii  task-desktop  3.34
ii  tasksel   3.34
ii  xfce4 4.12.3

Versions of packages task-xfce-desktop recommends:
ii  dbus-x111.10.8-1
ii  evince  3.20.0-1
ii  evince-gtk  3.20.0-1
pn  gnome-orca  
ii  hunspell-en-us  20070829-6
ii  hyphen-en-us2.8.8-3
ii  iceweasel   45.2.0esr-1
pn  libreoffice 
ii  libreoffice-gtk 1:5.0.2-1
ii  libreoffice-help-en-us  1:5.0.2-1
ii  mousepad0.4.0-4
ii  mythes-en-us1:5.1.3-2
pn  network-manager-gnome   
ii  orage   4.12.1-2
ii  quodlibet   3.6.2-1
ii  synaptic0.83+b1
ii  system-config-printer   1.5.7-1
ii  tango-icon-theme0.8.90-6
pn  vlc 
ii  xfce4-goodies   4.12.2
pn  xfce4-mixer 
ii  xfce4-power-manager 1.4.4-4
ii  xfce4-terminal  0.6.3-2
pn  xsane   

task-xfce-desktop suggests no packages.

-- no debconf information

Bug#810954: debian-installer: hurd hangs on startup, on loading ext2fs

[Adam Borowski]

Package: debian-installer
Version: 20160106
Severity: normal

All currently available images of hurd d-i (20151215-02:36 up to
20160113-01:54) hang on boot.  The last message given is:

start ext2fs: Hurd server bootstrap: ext2fs[gunzip:device:rd0] exec_

Machine is Virtualbox on amd64, with BIOS.

Bug#778195: debian-installer: x32 port

[Adam Borowski]

On Fri, Nov 13, 2015 at 12:42:25AM +0100, Cyril Brulebois wrote:
> John Paul Adrian Glaubitz  (2015-11-12):
> > Since I am also a porter for x32, I would be rather thrilled to see
> > x32 support in Debian Installer. Do you think there is a realistic
> > chance to have Adam's patch merged?
>
> I have no idea where x32 is headed, and whether it makes sense to have
> anything merged.

The port's status is that, if you include unmerged patches, pretty much
everything servery works, with few exceptions, such as:
* nodejs (needs chromium libs)
* iptables (ok as multiarch works 100% transparent by default)
Desktop things are in a far worse shape:
* gnome doesn't work
* xfce, lxde, mate work 100%
* kde mostly works
* no iceweasel nor chromium (ouch...)
* sound (ok with multiarch pulseaudio, but not easy to install)
And the installer seems to work, with everything I could test (BIOS, EFI, a
good set of installation options; qemu, virtualbox, a couple of real
machines).

I admit that my interests lie on the server side thus this is where I've put
most of my efforts.  But, at least on that front, things work for me and
should be ready for wider testing and upstreaming into Debian proper.

So, what should I do for you to consider merging the patches?


-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)

Bug#778195: updated patch

[Adam Borowski]

Here's a version rebased onto current d-i.

With jessie two months out, you lost the excuse.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.
From 00f9fdf27e3407940e1e1130fc9a2dbd191c498a Mon Sep 17 00:00:00 2001
From: Adam Borowski kilob...@angband.pl
Date: Mon, 22 Jun 2015 11:54:10 +0200
Subject: [PATCH] Add x32 support.

---
 build/config/x32.cfg   | 25 ++
 build/config/x32/cdrom-xen.cfg | 14 ++
 build/config/x32/cdrom.cfg |  7 +
 build/config/x32/cdrom/el-torito.cfg   |  7 +
 build/config/x32/cdrom/gtk.cfg | 17 
 build/config/x32/cdrom/isolinux.cfg| 14 ++
 build/config/x32/hd-media.cfg  | 22 
 build/config/x32/hd-media/gtk.cfg  | 16 
 build/config/x32/monolithic.cfg|  9 +++
 build/config/x32/netboot-gtk.cfg   | 23 
 build/config/x32/netboot-xen.cfg   | 16 
 build/config/x32/netboot.cfg   | 12 +
 build/config/x86.cfg   |  2 +-
 build/pkg-lists/cdrom/isolinux/gtk/x32.cfg |  8 ++
 build/pkg-lists/cdrom/isolinux/x32.cfg | 12 +
 build/pkg-lists/cdrom/x32.cfg  | 25 ++
 build/pkg-lists/hd-media/gtk/x32.cfg   | 10 +++
 build/pkg-lists/hd-media/x32.cfg   | 32 +++
 build/pkg-lists/netboot/gtk/x32.cfg| 10 +++
 build/pkg-lists/netboot/x32.cfg| 42 ++
 debian/control | 30 ++---
 21 files changed, 337 insertions(+), 16 deletions(-)
 create mode 100644 build/config/x32.cfg
 create mode 100644 build/config/x32/cdrom-xen.cfg
 create mode 100644 build/config/x32/cdrom.cfg
 create mode 100644 build/config/x32/cdrom/el-torito.cfg
 create mode 100644 build/config/x32/cdrom/gtk.cfg
 create mode 100644 build/config/x32/cdrom/isolinux.cfg
 create mode 100644 build/config/x32/hd-media.cfg
 create mode 100644 build/config/x32/hd-media/gtk.cfg
 create mode 100644 build/config/x32/monolithic.cfg
 create mode 100644 build/config/x32/netboot-gtk.cfg
 create mode 100644 build/config/x32/netboot-xen.cfg
 create mode 100644 build/config/x32/netboot.cfg
 create mode 100644 build/pkg-lists/cdrom/isolinux/gtk/x32.cfg
 create mode 100644 build/pkg-lists/cdrom/isolinux/x32.cfg
 create mode 100644 build/pkg-lists/cdrom/x32.cfg
 create mode 100644 build/pkg-lists/hd-media/gtk/x32.cfg
 create mode 100644 build/pkg-lists/hd-media/x32.cfg
 create mode 100644 build/pkg-lists/netboot/gtk/x32.cfg
 create mode 100644 build/pkg-lists/netboot/x32.cfg

diff --git a/build/config/x32.cfg b/build/config/x32.cfg
new file mode 100644
index 000..62df865
--- /dev/null
+++ b/build/config/x32.cfg
@@ -0,0 +1,25 @@
+MEDIUM_SUPPORTED = cdrom cdrom-xen netboot netboot-gtk netboot-xen hd-media
+MEDIUM_SUPPORTED_EXTRA = monolithic
+
+# The version of the kernel to use.
+KERNELVERSION = $(LINUX_KERNEL_ABI)-amd64
+KERNELMAJOR = 2.6
+KERNELNAME = vmlinuz
+
+# Not used for amd64.
+#UPX=upx-ucl-beta
+
+# Default syslinux configuration
+SYSLINUX_CFG=standard
+
+# The default video modes
+# These should be kept in sync with win32-loader's preseed line as
+# defined in graphics.nsi around line 58
+VIDEO_MODE=vga=788
+VIDEO_MODE_GTK=vga=788
+
+GRUB_EFI=y
+GRUB_PLATFORM=x86_64-efi
+GRUB_EFI_NAME=x64
+
+include config/x86.cfg
diff --git a/build/config/x32/cdrom-xen.cfg b/build/config/x32/cdrom-xen.cfg
new file mode 100644
index 000..2b4fd1b
--- /dev/null
+++ b/build/config/x32/cdrom-xen.cfg
@@ -0,0 +1,14 @@
+TYPE=cdrom/gtk
+
+EXTRANAME=cdrom/xen/
+
+MANIFEST-KERNEL = kernel image for installing under Xen
+MANIFEST-INITRD = initrd for installing under Xen
+MANIFEST-XENCFG = example Xen configuration
+
+XEN_INSTALL_METHOD = cdrom
+TARGET = $(KERNEL) $(INITRD) xen_config
+SYMLINK_KERNEL = ../vmlinuz
+SYMLINK_INITRD = ../gtk/initrd.gz
+
+EXTRATARGETS = build_cdrom_gtk
diff --git a/build/config/x32/cdrom.cfg b/build/config/x32/cdrom.cfg
new file mode 100644
index 000..5678ba5
--- /dev/null
+++ b/build/config/x32/cdrom.cfg
@@ -0,0 +1,7 @@
+# el-torito is too large at the moment, so is disabled.
+FLAVOUR_SUPPORTED = isolinux gtk #el-torito
+
+MEDIA_TYPE = CD-ROM
+
+# Syslinux configuration
+SYSLINUX_CFG=template
diff --git a/build/config/x32/cdrom/el-torito.cfg b/build/config/x32/cdrom/el-torito.cfg
new file mode 100644
index 000..96cf55b
--- /dev/null
+++ b/build/config/x32/cdrom/el-torito.cfg
@@ -0,0 +1,7 @@
+# A bootable image suitable for El Torito CD images.
+
+FLOPPY_SIZE = 2880
+
+TARGET = $(BOOT)
+
+MANIFEST-BOOT = El Torito boot image for CD
diff --git a/build/config/x32/cdrom

Bug#777905: oif, the patch is bad

[Adam Borowski]

Oops, the patch wrongly links to kernel/amd64.sh rather than just amd64.sh
I haven't noticed this in testing as the version uploaded to my private repo
was patched manually.  A fixed version is attached.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.
From 1ec12e462282b5f031cd28aaaef5ded7ffeb039d Mon Sep 17 00:00:00 2001
From: Adam Borowski kilob...@angband.pl
Date: Thu, 12 Feb 2015 07:39:01 +0100
Subject: [PATCH] Link x32 kernel selectors to amd64.

---
 kernel/x32.sh | 1 +
 1 file changed, 1 insertion(+)
 create mode 12 kernel/x32.sh

diff --git a/kernel/x32.sh b/kernel/x32.sh
new file mode 12
index 000..2f5ab2e
--- /dev/null
+++ b/kernel/x32.sh
@@ -0,0 +1 @@
+amd64.sh
\ No newline at end of file
-- 
2.1.4

Bug#778194: missing patch

[Adam Borowski]

Oif, the patch wasn't actually attached.  Sending it now.
From 75a5da43aef805be81c08a69bd8986d9dbe60a4a Mon Sep 17 00:00:00 2001
From: Adam Borowski kilob...@angband.pl
Date: Sat, 4 Apr 2015 03:12:34 +0200
Subject: [PATCH] Add x32/efi recipe, as a symlink to amd64/efi.

---
 recipes-x32-efi | 1 +
 1 file changed, 1 insertion(+)
 create mode 12 recipes-x32-efi

diff --git a/recipes-x32-efi b/recipes-x32-efi
new file mode 12
index 000..d383b93
--- /dev/null
+++ b/recipes-x32-efi
@@ -0,0 +1 @@
+recipes-amd64-efi
\ No newline at end of file
-- 
2.1.4

Bug#778194: partman-auto: x32 port

[Adam Borowski]

Package: partman-auto
Version: 124
Severity: wishlist
Tags: d-i patch
User: debian-...@lists.debian.org
Usertags: port-x32 di-x32

Hi!
Please apply the attached git patch (via git am).  It adds support for the
x32 architecture, by linking recipes-x32-efi to recipes-amd64-efi.  The
patch can be applied directly to the d-i/partman-auto git repository.

If you want to test, as the patch-set for x32 in d-i involves around twenty
packages, you'll want ready packages from the repository at debian-x32.org.
Complete d-i isos are available at http://debian-x32.org/#debian-installer
while debs/udebs/modified sources at http://ftp.debian-x32.org/debian/


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'unreleased'), (50, 'experimental')
Architecture: x32 (x86_64)

Kernel: Linux 3.19.0-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150212110128.23057.88563.report...@umbar.angband.pl

Bug#778195: debian-installer: x32 port

[Adam Borowski]

Package: debian-installer
Version: 20150108
Severity: wishlist
Tags: d-i patch
User: debian-...@lists.debian.org
Usertags: port-x32 di-x32

Hi!
Here's the main part for x32 support in d-i.  This patch is rather big, but
as it doesn't touch non-x32 parts (save for a single comment), it should be
safe to apply.  It's in the form of a git am patch, to ease patching.


If you want to test, as the patch-set for x32 in d-i involves around twenty
packages, you'll want ready packages from the repository at debian-x32.org.
Complete d-i isos are available at http://debian-x32.org/#debian-installer
while debs/udebs/modified sources at http://ftp.debian-x32.org/debian/

By the way, if you'd want to apply all patches to the d-i/ repository in one
go, daughter bug reports are:
#48 grub-installer
#49 lilo-installer
#51 efi-reader
#52 partman-efi
#58 partman-partitioning
#777905 base-installer
#778194 partman-auto

As for d-i related bugs in other sources, the usertag is:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org;tag=di-x32

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'unreleased'), (50, 'experimental')
Architecture: x32 (x86_64)

Kernel: Linux 3.19.0-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
From d9ace554fa6716e8ecb5647475ced4475ea741aa Mon Sep 17 00:00:00 2001
From: Adam Borowski kilob...@angband.pl
Date: Thu, 12 Feb 2015 08:10:53 +0100
Subject: [PATCH] Add x32 support.

---
 build/config/x32.cfg   | 25 ++
 build/config/x32/cdrom-xen.cfg | 14 ++
 build/config/x32/cdrom.cfg |  7 +
 build/config/x32/cdrom/el-torito.cfg   |  7 +
 build/config/x32/cdrom/gtk.cfg | 17 
 build/config/x32/cdrom/isolinux.cfg| 14 ++
 build/config/x32/hd-media.cfg  | 22 
 build/config/x32/hd-media/gtk.cfg  | 16 
 build/config/x32/monolithic.cfg|  9 +++
 build/config/x32/netboot-gtk.cfg   | 23 
 build/config/x32/netboot-xen.cfg   | 16 
 build/config/x32/netboot.cfg   | 12 +
 build/config/x86.cfg   |  2 +-
 build/pkg-lists/cdrom/isolinux/gtk/x32.cfg |  8 ++
 build/pkg-lists/cdrom/isolinux/x32.cfg | 12 +
 build/pkg-lists/cdrom/x32.cfg  | 25 ++
 build/pkg-lists/hd-media/gtk/x32.cfg   | 10 +++
 build/pkg-lists/hd-media/x32.cfg   | 32 +++
 build/pkg-lists/netboot/gtk/x32.cfg| 10 +++
 build/pkg-lists/netboot/x32.cfg| 42 ++
 debian/control | 30 ++---
 21 files changed, 337 insertions(+), 16 deletions(-)
 create mode 100644 build/config/x32.cfg
 create mode 100644 build/config/x32/cdrom-xen.cfg
 create mode 100644 build/config/x32/cdrom.cfg
 create mode 100644 build/config/x32/cdrom/el-torito.cfg
 create mode 100644 build/config/x32/cdrom/gtk.cfg
 create mode 100644 build/config/x32/cdrom/isolinux.cfg
 create mode 100644 build/config/x32/hd-media.cfg
 create mode 100644 build/config/x32/hd-media/gtk.cfg
 create mode 100644 build/config/x32/monolithic.cfg
 create mode 100644 build/config/x32/netboot-gtk.cfg
 create mode 100644 build/config/x32/netboot-xen.cfg
 create mode 100644 build/config/x32/netboot.cfg
 create mode 100644 build/pkg-lists/cdrom/isolinux/gtk/x32.cfg
 create mode 100644 build/pkg-lists/cdrom/isolinux/x32.cfg
 create mode 100644 build/pkg-lists/cdrom/x32.cfg
 create mode 100644 build/pkg-lists/hd-media/gtk/x32.cfg
 create mode 100644 build/pkg-lists/hd-media/x32.cfg
 create mode 100644 build/pkg-lists/netboot/gtk/x32.cfg
 create mode 100644 build/pkg-lists/netboot/x32.cfg

diff --git a/build/config/x32.cfg b/build/config/x32.cfg
new file mode 100644
index 000..62df865
--- /dev/null
+++ b/build/config/x32.cfg
@@ -0,0 +1,25 @@
+MEDIUM_SUPPORTED = cdrom cdrom-xen netboot netboot-gtk netboot-xen hd-media
+MEDIUM_SUPPORTED_EXTRA = monolithic
+
+# The version of the kernel to use.
+KERNELVERSION = $(LINUX_KERNEL_ABI)-amd64
+KERNELMAJOR = 2.6
+KERNELNAME = vmlinuz
+
+# Not used for amd64.
+#UPX=upx-ucl-beta
+
+# Default syslinux configuration
+SYSLINUX_CFG=standard
+
+# The default video modes
+# These should be kept in sync with win32-loader's preseed line as
+# defined in graphics.nsi around line 58
+VIDEO_MODE=vga=788
+VIDEO_MODE_GTK=vga=788
+
+GRUB_EFI=y
+GRUB_PLATFORM=x86_64-efi
+GRUB_EFI_NAME=x64
+
+include config/x86.cfg
diff --git a/build/config/x32/cdrom-xen.cfg b/build/config/x32/cdrom-xen.cfg
new file mode 100644
index 000..2b4fd1b
--- /dev/null
+++ b/build/config/x32/cdrom-xen.cfg
@@ -0,0 +1,14 @@
+TYPE=cdrom/gtk
+
+EXTRANAME=cdrom/xen/
+
+MANIFEST-KERNEL

Bug#777905: base-installer: x32 port

[Adam Borowski]

Package: base-installer
Version: 1.152
Severity: wishlist
Tags: d-i patch
User: debian-...@lists.debian.org
Usertags: port-x32 di-x32

Hi!
Please apply the attached patch.  It defines kernel selectors for the x32
architecture.  As x32 is a new ABI atop the amd64 kernel, this patch
symlinks kernel/amd64.sh to kernel/x32.sh, to keep them in sync in the
future.  The patch can be applied directly to the d-i/base-installer git
repository.

If you want to test, as the patch-set for x32 in d-i involves around twenty
packages, you'll want ready packages from the repository at debian-x32.org.
Complete d-i isos are available at http://debian-x32.org/#debian-installer
while debs/udebs/modified sources at http://ftp.debian-x32.org/debian/


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'unreleased'), (50, 'experimental')
Architecture: x32 (x86_64)

Kernel: Linux 3.19.0-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
From 60dd1261da6c21033b13ed7670d245f7f09640cf Mon Sep 17 00:00:00 2001
From: Adam Borowski kilob...@angband.pl
Date: Thu, 12 Feb 2015 07:39:01 +0100
Subject: [PATCH] Link x32 kernel selectors to amd64.

---
 kernel/x32.sh | 1 +
 1 file changed, 1 insertion(+)
 create mode 12 kernel/x32.sh

diff --git a/kernel/x32.sh b/kernel/x32.sh
new file mode 12
index 000..85c8502
--- /dev/null
+++ b/kernel/x32.sh
@@ -0,0 +1 @@
+kernel/amd64.sh
\ No newline at end of file
-- 
2.1.4

Bug#777752: partman-efi: x32 port

[Adam Borowski]

Package: partman-efi
Version: 60
Severity: wishlist
Tags: d-i patch

User: debian-...@lists.debian.org
Usertags: port-x32 di-x32

Hi!
Please apply the attached patch.  It adds support for the x32 architecture. 
The patch follows in every case amd64 code paths, as x32 is a new ABI atop
the amd64 kernel.  The patch can be applied directly to the d-i/partman-efi
git repository.

If you want to test, as the patch-set for x32 in d-i involves around twenty
packages, you'll want ready packages from the repository at debian-x32.org.
Complete d-i isos are available at http://debian-x32.org/#debian-installer
while debs/udebs/modified sources at http://ftp.debian-x32.org/debian/


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'unreleased'), (50, 'experimental')
Architecture: x32 (x86_64)

Kernel: Linux 3.19.0-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
From 4ae9c282d11f364a6b1b92207807a76a08d1bedd Mon Sep 17 00:00:00 2001
From: Adam Borowski kilob...@angband.pl
Date: Thu, 12 Feb 2015 07:33:04 +0100
Subject: [PATCH] Add support for x32.

---
 commit.d/format_efi | 2 +-
 debian/control  | 2 +-
 fstab.d/efi | 2 +-
 init.d/efi  | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/commit.d/format_efi b/commit.d/format_efi
index a78444a..223ebae 100755
--- a/commit.d/format_efi
+++ b/commit.d/format_efi
@@ -4,7 +4,7 @@
 
 ARCH=$(archdetect)
 case $ARCH in
-i386/*|amd64/*)
+i386/*|amd64/*|x32/*)
 	new_efi_fs=fat32
 	;;
 *)
diff --git a/debian/control b/debian/control
index a91db3b..e83c29f 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,6 @@ Vcs-Git: git://anonscm.debian.org/d-i/partman-efi.git
 
 Package: partman-efi
 Package-Type: udeb
-Architecture: i386 ia64 amd64 arm64
+Architecture: i386 ia64 amd64 arm64 x32
 Depends: partman-base (= 114), efi-modules, dosfstools-udeb, ${misc:Depends}
 Description: Add to partman support for EFI System Partitions
diff --git a/fstab.d/efi b/fstab.d/efi
index 14b6696..42b0c6f 100755
--- a/fstab.d/efi
+++ b/fstab.d/efi
@@ -4,7 +4,7 @@
 
 ARCH=$(archdetect)
 case $ARCH in
-i386/mac|amd64/mac)
+i386/mac|amd64/mac|x32/mac)
 	# Not yet sure what to do on Intel Macs.  Mounting the EFI System
 	# Partition on /boot/efi will change the behaviour of grub-install,
 	# so it seems best to avoid it for the moment.
diff --git a/init.d/efi b/init.d/efi
index 7b71990..cc9ad61 100755
--- a/init.d/efi
+++ b/init.d/efi
@@ -12,7 +12,7 @@ if [ -d /proc/efi ] || [ -d /sys/firmware/efi ]; then
 	 /var/lib/partman/efi
 else
 	case $ARCH in
-	i386/mac|amd64/mac)
+	i386/mac|amd64/mac|x32/mac)
 		# Intel Macs have an EFI partition, regardless of
 		# whether we're currently booted using BIOS
 		# compatibility or not (if we are, we won't be able to
@@ -88,7 +88,7 @@ log Found $NUM_ESP ESPs, $NUM_NO non-ESPs
 
 if [ $NUM_ESP = 0 ]  [ $NUM_NO -gt 0 ]; then
 	case $ARCH in
-		i386/*|amd64/*)
+		i386/*|amd64/*|x32/*)
 			db_input critical partman-efi/non_efi_system || true
 			db_go || exit 1
 			db_fset partman-efi/non_efi_system seen true
-- 
2.1.4

Bug#777749: lilo-installer: x32 port

[Adam Borowski]

Package: lilo-installer
Version: 1.47
Severity: wishlist
Tags: d-i patch
User: debian-...@lists.debian.org
Usertags: port-x32 di-x32

Hi!
Please apply the attached patch.  It adds support for the x32 architecture.
The patch can be applied directly to the d-i/lilo-installer git repository.

If you want to test, as the patch-set for x32 in d-i involves around twenty
packages, you'll want ready packages from the repository at debian-x32.org.
Complete d-i isos are available at http://debian-x32.org/#debian-installer 
while debs/udebs/modified sources at http://ftp.debian-x32.org/debian/


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'unreleased'), (50, 'experimental')
Architecture: x32 (x86_64)

Kernel: Linux 3.19.0-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
From 8d71debe874d8878600a57b1ee7033b0b9c4a2fd Mon Sep 17 00:00:00 2001
From: Adam Borowski kilob...@angband.pl
Date: Thu, 12 Feb 2015 07:17:08 +0100
Subject: [PATCH] Add support for x32.

---
 debian/control   | 2 +-
 debian/isinstallable | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 24993e8..547981a 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Vcs-Browser: http://anonscm.debian.org/gitweb/?p=d-i/lilo-installer.git
 Vcs-Git: git://anonscm.debian.org/d-i/lilo-installer.git
 
 Package: lilo-installer
-Architecture: i386 amd64
+Architecture: i386 amd64 x32
 Provides: bootable-system
 Depends: ${misc:Depends}, kernel-installer, di-utils (= 1.15), di-utils-mapdevfs, fdisk-udeb, os-prober
 XB-Installer-Menu-Item: 7500
diff --git a/debian/isinstallable b/debian/isinstallable
index 80a7939..530e491 100755
--- a/debian/isinstallable
+++ b/debian/isinstallable
@@ -7,7 +7,7 @@ log() {
 
 ARCH=$(archdetect)
 case $ARCH in
-i386/mac|amd64/mac|i386/efi|amd64/efi)
+i386/mac|amd64/mac|x32/mac|i386/efi|amd64/efi|x32/efi)
 	# LILO stands a better chance of working in BIOS compatibility mode,
 	# where /sys/firmware/efi doesn't exist.
 	# Note: depends on partman-efi to load the efivars module!
-- 
2.1.4

Bug#777758: partman-partitioning: x32 port

[Adam Borowski]

Package: partman-partitioning
Version: 106
Severity: wishlist
Tags: d-i patch
User: debian-...@lists.debian.org
Usertags: port-x32 di-x32

Hi!
Please apply the attached patch.  It adds a default disk label type for the
x32 architecture.  Without this patch, the user gets an error message and
has to choose GPT/MSDOS on his own.  The patch can be applied directly to
the d-i/partman-partitioning git repository.

If you want to test, as the patch-set for x32 in d-i involves around twenty
packages, you'll want ready packages from the repository at debian-x32.org.
Complete d-i isos are available at http://debian-x32.org/#debian-installer
while debs/udebs/modified sources at http://ftp.debian-x32.org/debian/


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'unreleased'), (50, 'experimental')
Architecture: x32 (x86_64)

Kernel: Linux 3.19.0-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
From cbc96e8dcffdbf5b8b6fb8280efda97de17ed5d7 Mon Sep 17 00:00:00 2001
From: Adam Borowski kilob...@angband.pl
Date: Thu, 12 Feb 2015 07:36:14 +0100
Subject: [PATCH] Add support for x32.

---
 debian/rules  | 3 +++
 lib/disk-label.sh | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 98b3fde..649db62 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,6 +13,9 @@ endif
 ifeq ($(ARCH), amd64)
 FS_DEPENDS=ntfs-3g-udeb
 endif
+ifeq ($(ARCH), x32)
+FS_DEPENDS=ntfs-3g-udeb
+endif
 ifeq ($(ARCH), ia64)
 FS_DEPENDS=ntfs-3g-udeb
 endif
diff --git a/lib/disk-label.sh b/lib/disk-label.sh
index b24f4a8..bec6ba8 100644
--- a/lib/disk-label.sh
+++ b/lib/disk-label.sh
@@ -18,7 +18,7 @@ default_disk_label () {
 		else
 			echo msdos
 		fi;;
-	amd64|kfreebsd-amd64|i386|kfreebsd-i386|hurd-i386)
+	amd64|kfreebsd-amd64|i386|kfreebsd-i386|hurd-i386|x32)
 		case $sub in
 		mac|efi)
 			echo gpt;;
-- 
2.1.4

Bug#777748: grub-installer: x32 port

[Adam Borowski]

Package: grub-installer
Version: 1.105
Severity: wishlist
Tags: d-i patch
User: debian-...@lists.debian.org
Usertags: port-x32 di-x32

Hi!
Please apply the attached patch.  It adds support for the x32 architecture.
This uses in every case amd64 code paths, as x32 in an ABI atop the amd64
kernel.

If you want to test, as the patch-set for x32 in d-i involves around twenty
packages, you'll want ready packages from the repository at debian-x32.org.
Complete d-i isos are available at http://debian-x32.org/#debian-installer 
while debs/udebs/modified sources at http://ftp.debian-x32.org/debian/


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'unreleased'), (50, 'experimental')
Architecture: x32 (x86_64)

Kernel: Linux 3.19.0-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
From ae118c2291de0eb8a5ccb783c87c00783756c514 Mon Sep 17 00:00:00 2001
From: Adam Borowski kilob...@angband.pl
Date: Thu, 12 Feb 2015 07:11:26 +0100
Subject: [PATCH] Add support for x32.

This is identical to amd64, as x32 uses amd64 kernels.
---
 debian/control   | 2 +-
 debian/isinstallable | 2 +-
 grub-installer   | 8 
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index 89538b7..8662673 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Vcs-Browser: http://anonscm.debian.org/gitweb/?p=d-i/grub-installer.git
 Vcs-Git: git://anonscm.debian.org/d-i/grub-installer.git
 
 Package: grub-installer
-Architecture: i386 hurd-i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc ppc64el mipsel arm64
+Architecture: i386 hurd-i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc ppc64el mipsel arm64 x32
 XB-Subarchitecture: ${subarch}
 Provides: bootable-system
 Depends: ${shlibs:Depends}, ${misc:Depends}, kernel-installer, created-fstab, di-utils (= 1.15), di-utils-mapdevfs, os-prober, partman-utils
diff --git a/debian/isinstallable b/debian/isinstallable
index 9956321..7dab8ff 100755
--- a/debian/isinstallable
+++ b/debian/isinstallable
@@ -8,7 +8,7 @@ log() {
 ARCH=$(archdetect)
 
 case $ARCH in
-i386/mac|amd64/mac)
+i386/mac|amd64/mac|x32/mac)
 	# Note: depends on partman-efi to load the efivars module!
 	if [ -d /sys/firmware/efi ]; then
 		log GRUB not yet usable on Intel-based Macs booted using EFI
diff --git a/grub-installer b/grub-installer
index a531d69..e1ce949 100755
--- a/grub-installer
+++ b/grub-installer
@@ -319,7 +319,7 @@ case $ARCH in
 arm64/efi)
 	grub_package=grub-efi-arm64
 	;;
-i386/mac|amd64/mac)
+i386/mac|amd64/mac|x32/mac)
 	# Note: depends on partman-efi to load the efivars module!
 	if [ -d /sys/firmware/efi ]; then
 		# This point can't be reached (yet).  See debian/isinstallable.
@@ -328,7 +328,7 @@ case $ARCH in
 		grub_package=grub-pc
 	fi
 	;;
-i386/efi|amd64/efi)
+i386/efi|amd64/efi|x32/efi)
 	if [ -f /var/lib/partman/ignore_uefi ]; then
 		grub_package=grub-pc
 	else
@@ -345,7 +345,7 @@ case $ARCH in
 		fi
 	fi
 	;;
-i386/*|amd64/*)
+i386/*|amd64/*|x32/*)
 	grub_package=grub-pc
 	;;
 powerpc/*)
@@ -863,7 +863,7 @@ else
 	case $(archdetect) in
 	i386/*)
 		stagedir=i386-pc ;;
-	amd64/*)
+	amd64/*|x32/*)
 		stagedir=x86_64-pc ;;
 	*)
 		error Unsupported architecture for SATA RAID/multipath installation
-- 
2.1.4

Bug#777751: efi-reader: x32 port

[Adam Borowski]

Package: efi-reader
Version: 0.14
Severity: wishlist
Tags: d-i patch

Hi!
Please apply the attached patch.  It adds support for the x32 architecture. 
The patch is trivial -- all that needed to be done is adding x32 to
debian/control.  The patch can be applied directly to the d-i/efi-reader git
repository.

If you want to test, as the patch-set for x32 in d-i involves around twenty
packages, you'll want ready packages from the repository at debian-x32.org.
Complete d-i isos are available at http://debian-x32.org/#debian-installer
while debs/udebs/modified sources at http://ftp.debian-x32.org/debian/


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'unreleased'), (50, 'experimental')
Architecture: x32 (x86_64)

Kernel: Linux 3.19.0-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
From bb723d009d35a5a3048c13129d88a688825c6b70 Mon Sep 17 00:00:00 2001
From: Adam Borowski kilob...@angband.pl
Date: Thu, 12 Feb 2015 07:29:01 +0100
Subject: [PATCH] Add x32 to the list of architectures.

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 2396049..42926e7 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Vcs-Browser: http://anonscm.debian.org/gitweb/?p=d-i/efi-reader.git
 Vcs-Git: git://anonscm.debian.org/d-i/efi-reader.git
 
 Package: efi-reader
-Architecture: ia64 amd64 i386 arm64 armhf
+Architecture: ia64 amd64 i386 arm64 armhf x32
 Depends: ${shlibs:Depends}
 Description: Select default values from EFI configuration.
 Package-Type: udeb
-- 
2.1.4

Bug#773452: killing udhcp helps

[Adam Borowski]

 hang in netcfg on IPv6-only

At that time, if you switch to a console (Ctrl-Alt-F2) and kill udhcp, the
installer happily continues.  Not even an error message is given (about
udhcp's demise), and the installed system is configured for IPv6-only, as
expected.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150124041015.ga16...@angband.pl

Bug#772702: installation-reports: fails to mount ext4 after partitioning

[Adam Borowski]

Package: installation-reports
Severity: grave
Justification: fails installation with default settings on popular machines 
(probably all)

-- Package-specific info:

Boot method: CD
Image version: 
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
 with mtime 2014-12-10 05:35
Date: 2014-12-10 ~07:30

Machine: VirtualBox BIOS, VirtualBox EFI, qemu-kvm
Partitions: empty partition table (fresh VMs)

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:  [O]
Load installer modules: [O]
Clock/timezone setup:   [ ]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [E]

Current dailies fail upon mounting ext4 filesystems just after partitioning
(default whole-disk) with the following message:
The attempt to mount a file system with type ext4 in SCSI3 (0,0,0), partition #2
(sda) at / failed.

dmesg says:
ext4: Unknown symbol pagecache_isize_extended (err 0)

Changing the fs type to btrfs (and likely others) allows proceeding.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141210093938.3374.30227.report...@umbar.angband.pl

Bug#767999: debootstrap/base-passwd: #767999 and #766459 should really be fixed in base-passwd

[Adam Borowski]

On Thu, Nov 06, 2014 at 02:06:07PM +, Michael Tautschnig wrote:
 At least Santiago's and my opinion diverge on whether base-passwd is presently
 in line with policy on 3.8 Essential packages. Therefore the route from here
 appears to hinge on interpreting policy in one of two ways: my point is that
 base-passwd, at present, is not providing its functionality after just being
 unpacked - it does require postinst having been run. Santiago claims, if I
 interpret this correctly, that every package has to be configured at least 
 once
 before being useful at all (irrespective of whether it is essential or not).

I'm not a policy lawyer so I might be wrong, but:
3.8. doesn't give an exception for not configured before.
6.5. does give it but only for Pre-Depends rather than essential, and only
 for preinst (base-files uses it in postinst)

Santiago's intepretation might come from 6.5.new-preinst`install' talking
first about essential and pre-depends in one place, then about just
pre-depends in the very next sentence.  A non-strict reader might assume the
second sentence omits and essentials for brevity.

 1. Determine whether base-passwd is in line with policy on providing its
 functionality as an essential package.
   A) If it is, then debootstrap is buggy.

Even if it somehow is, there's a practical problem: it's impossible to
deploy a fix to a significant part of users.

   B) If base-passwd violates policy, then base-passwd is buggy.

I say it is, but since the only consumer that matters is base-files, it
might be safer to change the latter.

 My point of view is that base-passwd should be changed, and thanks to
 suggestions from Tollef last night the attached patch should actually achieve
 this. The idea simply is to sort out creating /etc/passwd and /etc/group in
 preinst already, so that these files will be present once the package reaches
 the state unpacked.

I tested your patch when debootstrapping from squeeze, it did work.  Should
I test some more scenarios (cdebootstrap?  2-phase cross-arch debootstrap?
some other distro?) -- or do you think it should be safe?

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141106214440.ga16...@angband.pl

Re: debootstrap and cdebootstrap vs systemd

[Adam Borowski]

On Thu, Nov 06, 2014 at 11:14:10PM +0100, Simon Richter wrote:
 I've run into a bit of a problem building a root filesystem for an ARM
 system where the kernel shipped by the vendor is 2.6 based. As systemd
 does not work there, I tried installing a sysvinit based system using
 --include and --exclude to (c)debootstrap.
 In short: this does not work.

You can chroot to the system from the host machine, and upgrade to sysvinit.
If your host can't run arm code, install qemu-user-static and copy
/usr/bin/qemu-arm-static to the target system.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141106233306.ga7...@angband.pl

Bug#767999: debootstrap/base-passwd: #767999 and #766459 should really be fixed in base-passwd

[Adam Borowski]

On Thu, Nov 06, 2014 at 10:32:34PM +, Michael Tautschnig wrote:
  I tested your patch when debootstrapping from squeeze, it did work.  Should
  I test some more scenarios (cdebootstrap?  2-phase cross-arch debootstrap?
  some other distro?) -- or do you think it should be safe?
 
 Cool, thanks!! If testing is trivial for you then I'm sure this would be
 appreciated (in particular the it did not work before, but not it works
 improvement). While I wouldn't really expect any new problems, I don't know
 enough about, e.g., cdebootstrap so maybe something could go wrong over there?

I just tested:  no patchyour patch
squeeze debootstrap ✕   ✓
wheezy debootstrap  ✕   ✓
unstable debootstrap✓   ✓ hacked in #766459
squeeze cdebootstrap✕   ✕
wheezy cdebootstrap ✕   ✕
unstable cdebootstrap   ✓   ✓

squeeze cdebootstrap dies after extraction, before unpacking:
E: Execution failed: No such file or directory

wheezy cdebootstrap dies immediately:
P: Retrieving InRelease
P: Validating InRelease
I: Good signature from Debian Archive Automatic Signing Key (7.0/wheezy) 
ftpmas...@debian.org
(or on my partial mirror: W: Couldn't validate InRelease!)
P: Parsing InRelease
W: parser_rfc822: Iek! Don't find end of field, it seems to be after the end of 
the line!
E: Couldn't parse InRelease!

So cdebootstrap failures are unrelated to this bug.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141107000218.gb7...@angband.pl

Bug#767999: base-files: fails to install with pre-jessie debootstrap

[Adam Borowski]

Control: retitle -1 base-files: fails to install with pre-jessie debootstrap
Control: reassign -1 base-files
Control: found -1 base-files/7.6
Control: tags -1 +patch

(TL;DR: there's a working patch attached)

On Tue, Nov 04, 2014 at 09:04:14AM +0100, Santiago Vila wrote:
 On Tue, Nov 04, 2014 at 01:05:11AM +0100, Adam Borowski wrote:
  [...]
  While #766459 fixed debootstrapping with jessie's debootstrap, I'm afraid
  this doesn't solve most use cases that include upgrading, installation from
  non-DI or installation in hosting scenarios.
  
  For a long time, most versions of debootstrap in use will come from wheezy,
  Red Hat or some random live-cd.  None of those can install jessie :(
  
  Thus, I'm afraid that fixing *new* copies of debootstrap is not enough,
  and this bug needs to be solved in base-files or base-passwd.
 
 For the umpteenth time: This is a bug in debootstrap and that's where
 it should be fixed!!!

Even if it was, there's no way an updated version of debootstrap gets to
machines of a significant part of users.  An upload to stable can apply only
to those running an up-to-date version of wheezy.

How do you propose changing debootstrap on already burned CDs?  How do you
propose updating squeeze, current and past versions of Ubuntu, Knoppix,
GRML, etc (live CDs often get used to install Debian).  Heck, even Red Hat
does include debootstrap packages -- how can you update that?  And without
working debootstrap, forget about Debian containers, etc.

 (And you should really read the full logs for Bug#766459 to understand
 this instead of killing the messenger

The guilty party for this bug is either base-files or base-passwd.  Neither
dpkg nor debootstrap are at fault: that this problem did not show up before
was an issue akin to relying on hash order.

Thus, it can be possibly fixed only in base-files or base-passwd.  By a
literal reading of the policy it's more of a fault of the latter, however I
can't think of a fix there without some REALLY nasty side effects: that
package would need to ship /etc/passwd and /etc/group them somehow divert
them away so it's installed only the first time.  On the other hand, it is
easy to work around in base-files' postinst.

 base-files does not do anything which is not allowed by policy).

Policy 3.8.:
# all `essential' packages must supply all of their core functionality even
# when unconfigured

That's the core functionality of base-passwd.

 People who do not understand the essential flag keep filing bugs
 against base-files.

Please point out how I misread policy 3.8.


But, I did manage to prepare a patch that seems to be working.
As it's impossible for an admin to renumber system groups in the middle of
a debootstrap run, it's enough to use numeric values of groups base-files
need (root, staff, mail and utmp).  In the patch I'm proposing, these are
used if /etc/group is missing.  That's a hack, but a good deal better than
alternatives I can think of.


Meow!
-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.
diff -Nurd base-files-7.10/debian/postinst.in base-files-7.10.new/debian/postinst.in
--- base-files-7.10/debian/postinst.in	2014-10-27 13:36:30.0 +0100
+++ base-files-7.10.new/debian/postinst.in	2014-11-05 05:35:03.801097773 +0100
@@ -1,12 +1,25 @@
 #!/bin/sh
 set -e
 
+# During debootstrap /etc/passwd and /etc/group may not exist yet.
+if [ -f /etc/group ]
+  then
+STAFF=staff
+MAIL=mail
+UTMP=utmp
+  else
+STAFF=50
+MAIL=8
+UTMP=43
+fi
+ROOT=0
+
 install_local_dir() {
   if [ ! -d $1 ]; then
 mkdir -p $1
   fi
   if [ -f /etc/staff-group-for-usr-local ]; then
-chown root:staff $1 2 /dev/null || true
+chown $ROOT:$STAFF $1 2 /dev/null || true
 chmod 2775 $1 2 /dev/null || true
   fi
 }
@@ -20,7 +33,7 @@
 install_directory() {
   if [ ! -d /$1 ]; then
 mkdir /$1
-chown root:$3 /$1
+chown $ROOT:$3 /$1
 chmod $2 /$1
   fi
 }
@@ -58,17 +71,17 @@
   install_from_default /usr/share/base-files/dot.bashrc/root/.bashrc
   install_from_default /usr/share/base-files/profile   /etc/profile
   install_from_default /usr/share/base-files/motd  /etc/motd
-  install_directory mnt   755 root
-  install_directory srv   755 root
-  install_directory opt   755 root
-  install_directory etc/opt   755 root
-  install_directory var/opt   755 root
-  install_directory media 755 root
-  install_directory var/mail 2775 mail
+  install_directory mnt   755 $ROOT
+  install_directory srv   755 $ROOT
+  install_directory opt   755 $ROOT
+  install_directory etc/opt   755 $ROOT
+  install_directory var/opt   755 $ROOT
+  install_directory media 755 $ROOT
+  install_directory var/mail 2775 $MAIL
   if [ ! -L /var/spool/mail

Bug#766459: please don't upload this to wheezy

[Adam Borowski]

Hi!

For reasons I explained in #767999, hacking debootstrap to configure
base-passwd and base-files in a specific order is neither sufficient nor
necessary.  It does work around the problem for those running debootstrap
from fully upgraded unstable (and if it was uploaded to stable, wheezy)
but doesn't help in any other use cases.

I have proposed a different fix to base-files.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141105050559.ga15...@angband.pl

Bug#765839: some more data

[Adam Borowski]

I asked around, and:

arm: Broadcom/VideoCore: not working.

Adreno: unfortunately, Maarten Lankhorst (xserver-xorg-video-freedreno
maintainer) says his only board just broke, and thus he's unable to test. 
This is sad as this driver is known to work on Fedora for at least some
version of gnome -- it'd be nice to know whether it's a problem with
drivers, gnome stack in Debian (cogl as Josselin suspects?) or perhaps just
configuration.

Other architectures: I did not get any answer.


So for now there's not a single report of gnome on !amd64 !i386 working...

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141101020027.ga18...@angband.pl

default DE requalification: quality of task

[Adam Borowski]

Hi!
In the default desktop environment requalification table, I think gnome's
score for task quality should be downgraded -- although it might be better
to axe the whole category.

There are two criteria listed:
* quality: task-gnome has the distinction of being the only desktop task
  with a severe bug.  Installing a non-working desktop on all but two
  architectures (or at least a good part of machines for those
  architectures) counts as pretty bad in my book...
* testing: as XFCE was the default for most of jessie's development, no one
  noticed what dropping of gnome-fallback really means, until recently.
So, I'd say the correct score would be -1 rather than +1...

However, I kind of fail to see the point of giving two whole points for
something as minor as the tasksel task.  It's just a link to the DE's
primary metapackage plus a few goodies -- nothing as important as complete
translations, etc.  So what about removing this line instead of arguing?


Meow!
-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141101025829.gb18...@angband.pl

desktop requalification: KDE seems to be portable

[Adam Borowski]

Hi!
I see the field for KDE/portability is left as a question mark.  In case
you won't get answers from official porters soon, I can confirm KDE does
work at least on:
* real metal: an armhf laptop
* qemu: powerpc
If you wish, I can test on more arms, and on anything qemu offers.

I did notice, though, that on both of those setups KDE is excruciatingly
slow.  LXDE and Mate are decently fast, XFCE somewhat slower than these
two... while with KDE, it's more like half a minute before a menu pops up.
Qemu in true emulation mode is not exactly a speed demon, that laptop is
damn weak as arms go[1], but this kind of speeds might be bad on less
powerful x86 too.

Thus, if by portability you mean works everywhere, please give it +1.
If you want to extend this field to also include works well on weak
hardware, I'd score it at 0.


[1]. 1x1.2Ghz 1GB ram.
-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141101032805.gc18...@angband.pl

Re: desktop requalification: KDE seems to be portable

[Adam Borowski]

On Sat, Nov 01, 2014 at 04:28:05AM +0100, Adam Borowski wrote:
 I see the field for KDE/portability is left as a question mark.  In case
 you won't get answers from official porters soon, I can confirm KDE does
 work at least on:
 * real metal: an armhf laptop
 * qemu: powerpc

Not so good on kfreebsd-amd64, though.
Current d-i daily, KDE task: after kdm login, there's nothing but a
wallpaper, cursor and a disk icon, clicking it makes the icon disappear and
from that point nothing works.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141101041332.ga24...@angband.pl

Bug#765839: task-desktop: installs a non-working dekstop environment on all but 2 archs

[Adam Borowski]

On Tue, Oct 21, 2014 at 04:37:42PM -0400, Joey Hess wrote:
 Adam Borowski wrote:
  * powerpc in qemu
  (using an existing system on real metal, d-i on qemu)
 
 What specific real metal did you use to test gnome on powerpc?

The parenthesis is not indented, it applies to both bullet points.

I did not test armhf on qemu (as I own multiple pieces of real metal),
and did not test powerpc outside qemu as I have no access to such a physical
machine.

Sorry if I was unclear.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014102159.ga18...@angband.pl

Bug#765839: task-desktop: installs a non-working dekstop environment on all but 2 archs

[Adam Borowski]

Source: task-desktop
Version: 3.28
Severity: important


Hi!
By dropping gnome-fallback, Gnome3 has effectively dropped support for all
architectures other than amd64 and i386 (possibly armhf on Nvidia Tegra?).
Yet in current debian-installer, gnome3 is installed by default, only to
show:


Oh no!  Something has gone wrong
A problem has occured and the system can't recover.
Please log out and try again.

with a [Log Out] button that doesn't even work.

This is because Gnome3 requires specific GL rasterizers that are provided:

* in hardware: Nvidia (inc. nouveau), Radeon (free and non-free), Intel
  drivers, but not eg. Mali proprietary
* in software: llvmpipe

llvmpipe is compiled only on five architectures: amd64, i386, armhf,
kfreebsd-amd64 and kfreebsd-i386.  Out of these five, kfreebsd-* don't count
because systemd.  In theory, Gnome3 should work with llvmpipe on armhf, but
sadly, in practice it doesn't, in any setup I tried.  I don't know gnome's
underpinnings enough to debug this further, beyond installing it and giving
it a working X11 setup.

I have tried Gnome3 on:
* an armhf laptop, Omega OAN133, with:
  * framebuffer
  * proprietary Mali drivers
* an armhf desktop, hardkernel Odroid U2 (also Mali)
* powerpc in qemu
(using an existing system on real metal, d-i on qemu)


Out of other -desktop tasks, I've checked that XFCE, LXDE, KDE and Mate
work, and Cinnamon does not (not surprising as it's a Gnome3 front).

Proposed solutions:

1. revert to xfce by default :p
2. make task-desktop arch:any, with gnome first on amd64 and i386, and xfce
   (or mate...) elsewhere
3. remove the task-gnome-desktop package on !amd64 !i386


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141018155236.9105.68915.report...@umbar.angband.pl

Bug#765839: task-desktop: installs a non-working dekstop environment on all but 2 archs

[Adam Borowski]

On Mon, Oct 20, 2014 at 01:55:48PM -0400, Joey Hess wrote:
 Adam Borowski wrote:
  I have tried Gnome3 on:
  * an armhf laptop, Omega OAN133, with:
* framebuffer
* proprietary Mali drivers
  * an armhf desktop, hardkernel Odroid U2 (also Mali)
  * powerpc in qemu
  (using an existing system on real metal, d-i on qemu)
 
 What was the result of all these tests?

Everywhere the same: Oh no!  Something has gone wrong on a white screen. 
Replacing gdm3 with lightdm allows logging in, which gives the same screen.
Cinnamon shows a different message.

I got more arms but not a single piece of hardware of other architectures.
I can check more in qemu if you want, though.

Meow!
-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141021003931.ga9...@angband.pl

Re: default desktop: availability on all arches

[Adam Borowski]

On Wed, Sep 10, 2014 at 11:56:58AM +0100, Steven Chamberlain wrote:
 On 10/09/14 07:40, Adam Borowski wrote:
  I think the DebianDesktop requalification table lacks an important
  row: the availability of the desktop environment in question on all
  Debian architectures.
 
 Not everyone has been persuaded on that principle yet :P  But on
 kfreebsd CDs we can at least override the default desktop if it's
 something we don't have.

I just re-checked on powerpc in qemu, unlike my other setups it's not a real
machine, but qemu is at least a reproducible setup without out-of-archive
bits like all three of my armhf rigs.  A d-i run takes two ages and three
forevers, though...  Powerpc is not a slow architecture, but is extremely
slow in qemu.

 Let's discuss your other point about 3D acceleration though:
 
  llvmpipe is not a strict requirement, but I have yet to find a non-x86
  opengl driver that gnome's compositor can work with.  I tried:
  * an A10 laptop with non-free unpackaged Mali blob
  * Exynos4412 hardkernel, unpackaged opengl drivers
  * chroot on Raspberry Pi, non-free Broadcom stuff
  * qemu stuff has no accelerated opengl either
 
 What happens otherwise if trying to start GNOME3 (or others)?
 * without 3D, with llvmpipe
 * without both

llvmpipe doesn't work at all -- not ported to -- on !x86 !armhf.

 Does it fall back gracefully to a fallback/flashback mode, and does that
 still work these days?

All you get is a non-windowed screen that says:
.
Oh no!  Something has gone wrong.

A problem has occured and the system can't recover.
Please log out and try again.

Log Out.
`
You can't even press Log Out, upon clicking the mouse cursor disappears
and pressing any key on the keyboard turns the screen black, without no
way out other than Alt-Ctrl-F1.

According to what I read on the Interwebs, the fallback mode has been
removed in Gnome 3.8, and flashback is just a plugin on gnome-shell.

 In this mode would it still meet the 'accessibility' or other criteria
 already on the Wiki page?

'Accessibility' is usually meant as being helpful to the blind, poor-
sighted and those with hand-control disabilities: modes with big letters,
contrasted screen elements, doubleclick and shift workarounds, etc.

I'd say you'd need 'availability' or 'portability': gnome3 with a solid -1
(works only on 3 architectures at all -- 2 usably), no idea about kde,
no problems for the rest.

For example the Allwinner10-based laptop I had with me on DebConf 2013, I
tested with xfce, but as A10 is terribly underpowered even for arm, I ended
up with lxde with a bunch of programs from xfce.  This worked great.

  Thus, it's safe to say anyone with a non-Nvidia non-Radeon non-Intel GPU
  will need llvmpipe.
 
 The Radeon users would need to be using non-free microcode too I guess?

I'm well-armed but not well-x86ed, all my home boxes got nvidia, can't
check.

  I'd say the default desktop environment should work on almost all setups.
 
 Yes, surely.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140911153618.ga29...@angband.pl

Re: default desktop: availability on all arches

[Adam Borowski]

On Thu, Sep 11, 2014 at 06:11:22PM +0100, Steven Chamberlain wrote:
 On 11/09/14 16:36, Adam Borowski wrote:
  What happens otherwise if trying to start GNOME3 (or others)?
  * without 3D, with llvmpipe
  * without both
  
  llvmpipe doesn't work at all -- not ported to -- on !x86 !armhf.
  
  Does it fall back gracefully to a fallback/flashback mode, and does that
  still work these days?
  
  All you get is a non-windowed screen that says:
  Oh no!  Something has gone wrong.
 
 Fair enough if a Debian desktop doesn't want to support toy
 architectures (I don't mind use of this term).

So you call all but two[1] of Debian architectures (14+9) toys[2]?  Where
has the universal operating system gone?

 Ultimately I think we'll be saying the default Debian _system_ is an
 amd64 machine, with modern Intel, Nvidia (or Radeon + nonfree microcode)
 graphics, running the GNOME 3 desktop, and fair enough, the Debian
 homepage could serve a direct link to a GNOME amd64/i386 ISO download.
 That install media should default to installing GNOME.

XFCE has none of Gnome3's problems, and were it not a last-minute entry, I'd
suggest going with Mate.  Mate has the upside of having been the default for
every but one releases that had tasksel.

 Is that what we're *really* deciding with the process here?
 https://wiki.debian.org/DebianDesktop/Requalification/Jessie

I'd say that being available on most architectures warrants at least a row
in that table.  It's more important than, say, 2 points you get for a
tasksel metapackage that _hasn't even worked until now_ -- the only desktop
task that was even shown in d-i was task-desktop.  No wonders the Mate team
didn't even request one: users had the mate-desktop-environment metapackage
which was for all purposes better.  Until this qualification, which suddenly
decided to give 2 points for this detail.

So what I'm suggesting is to add the availability or portability row to
the table.


[1]. armhf machines typically rely on their GPUs to have any reasonable
graphics performance, trying to emulate opengl in software isn't going to
work.

[2]. Ok, I admit hurd is a toy, so are some of -ports.
-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140911182608.gb1...@angband.pl

Re: default desktop: availability on all arches

[Adam Borowski]

On Thu, Sep 11, 2014 at 05:36:18PM +0200, Adam Borowski wrote:
 I just re-checked on powerpc in qemu, unlike my other setups it's not a real
 machine, but qemu is at least a reproducible setup without out-of-archive
 bits like all three of my armhf rigs.

 I'd say you'd need 'availability' or 'portability': gnome3 with a solid -1
 (works only on 3 architectures at all -- 2 usably), no idea about kde,
 no problems for the rest.

Tried kde: massively slower than other desktop environments, but works.
So it looks like gnome3 is the only one that doesn't work on most
architectures.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140911181028.ga1...@angband.pl

default desktop: availability on all arches

[Adam Borowski]

Hi!

I think the DebianDesktop requalification table lacks an important
row: the availability of the desktop environment in question on all
Debian architectures.

This is mainly an argument against gnome3, as it's restricted basically
to just amd64, i386 and armhf (poorly):
* systemd is not available on kfreebsd-*
* llvmpipe is available only on {,kfreebsd-}{amd64,i386} and armhf
  Also, emulating opengl in software on a slow architecture isn't the
  best idea.

llvmpipe is not a strict requirement, but I have yet to find a non-x86
opengl driver that gnome's compositor can work with.  I tried:
* an A10 laptop with non-free unpackaged Mali blob
* Exynos4412 hardkernel, unpackaged opengl drivers
* chroot on Raspberry Pi, non-free Broadcom stuff
* qemu stuff has no accelerated opengl either

Thus, it's safe to say anyone with a non-Nvidia non-Radeon non-Intel GPU
will need llvmpipe.

I'd say the default desktop environment should work on almost all setups.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910064057.ga3...@angband.pl

Bug#760637: busybox: please support find -perm /0123 before jessie

[Adam Borowski]

Package: busybox
Version: 1:1.22.0-8
Severity: wishlist
Tags: fixed-upstream

Hi!
GNU find deprecated find -perm +0123 since 2005, and finally dropped it in
findutils 4.5 (-perm /0123 is the replacement).  Yet, busybox still doesn't
even support / yet.  This has been just fixed upstream, so could you please:
1. package current upstream git, or
2. cherry-pick commit 3e9b13e4c572d97468bef029f9c6e72271297fcb
before jessie freeze?

Otherwise, stuff that already moved from + to / (most of uses) will break in
jessie, and the rest which will need to be updated later will break on
partial upgrades post-jessie.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140906111559.8340.77180.report...@umbar.angband.pl

Bug#584752: same for keymap selection

[Adam Borowski]

On Mon, May 14, 2012 at 10:17:19PM +0100, Miguel Figueiredo wrote:
 Hi,
 
 On 13-05-2012 13:26, Adam Borowski wrote:
 Same for the keymap selection screen: if you select a wrong one, the
 go back  button doesn't work.
 
 Can you give more information in which image this happens and steps
 to reproduce it?

D-I alpha1, i386 netinst.
VirtualBox (current from unstable).
(not a lowmem issue, same on 64MB and 1G)

* Install
* English

same: other/Europe/Poland/en_US.UTF-8 or United States

* Persian

reproducible every time.

 (Also, it's strange that typing po selects Persian instead of Polish
 -- one would expect that if a prefix search doesn't work, it'd go to O
 instead).
 
 AFAIK in the installer when you press a key the cursor jumps to the
 next option of the *single* letter pressed.
 When you type 'po' it jumps to the next option that starts with a
 'p' and then jumps to the first option that starts with 'o'.
 If there's no 'o' stays in the previous choice - Persian in this case.
 It jumps to Pxxx and then tries to jump ro Oxxx and not to POxxx.

Oh heh, I did not notice there's no keymap starting with O, sorry for noise.


Cheers and schtuff!
-- 
“This is gonna be as easy as cheating on an ethics exam!”
-Cerise Brightmoon


signature.asc
Description: Digital signature

Bug#584752: same for keymap selection

[Adam Borowski]

Same for the keymap selection screen: if you select a wrong one, the
go back button doesn't work.

(Also, it's strange that typing po selects Persian instead of Polish
-- one would expect that if a prefix search doesn't work, it'd go to O
instead).

-- 
“This is gonna be as easy as cheating on an ethics exam!”
-Cerise Brightmoon



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120513122620.ga31...@angband.pl

Bug#635336: debian-installer: USB install: fails to mount CD

[Adam Borowski]

Package: debian-installer
Severity: normal

(daily build from July 22)

First, the documentation for installing from USB is unclear whether you're
supposed to copy the contents of the CD to the FAT filesystem (ignoring
symlink problems), or just dump the .iso image to the root of the
filesystem.  I did both just to be sure.

Boot and initial steps of d-i go just fine.

However, it later fails at the Detect and mount CD-ROM stage.  The machine
happens to physically have one, it's just empty.  Trying to skip the stage
doesn't work.  Only manually doing: mount -tvfat /dev/sdb /cdrom will let
the installation to continue.

Pre-squeeze images in January did not have this problem.  The machine I
installed then did not physically have a CD or DVD drive at all though, so
this might be a factor.

(Just got to the DebConf, so I can't try to start d-i on the old machine.  I
do have the one that fails, so you can contact me in person.)

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110725104049.5071.96097.report...@orthanc.angband.pl

Bug#245465: use swap size, not RAM

[Adam Borowski]

What if we looked at the size of available swap rather than RAM?

People don't really expect to have their actual memory eaten by something
that appears to be a disk filesystem (and used to be one).  I'd say that
eating some of swap space would be less surprising.

In other words: a machine with 64MB RAM + swap will want to use tmpfs (much
faster than a regular filesystem), but one with 1-2GB and no swap probably
won't.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110416175645.ga20...@angband.pl

Re: d-i on ancient hardware

[Adam Borowski]

On Mon, Jul 10, 2006 at 01:56:54AM +0200, Frans Pop wrote:
 Next time please file an installation report instead of sending an
 email to the list.
m'kay.

  On the other hand, if you insist on keeping loadlin, please provide a
  .bat file.  A beginner user won't know to look in isolinux.cfg to
  copy the append line; also, there's no GPM in stone-age OSes...
 We should document it better, that is true (and ship a more recent 
 version). On my TODO list, but fairly low down.

I guess that it would be enough to mindlessly convert isolinux.cfg
from:
LABEL install
kernel 2.6/vmlinuz
append video=vesa:ywrap,mtrr vga=788 ...
to:
rem LABEL install^M
loadlin 2.6\vmlinuz video=vesa:ywrap,mtrr vga=788 ...^M

(ie, piping it through a simple sed/perl/awk/whatever filter)

A fancy menu would cause portability problems, and is way under my
threshold of caring.  Telling people to uncomment the correct line
if you're unhappy with the default would be enough for Microsoft
archaeology.
 
  4. [G-I] [Off-topic]: As you already don't support my magnificent 486
  and similar, why won't you slap any theme on?  The current widgets
  are hideous, and since there's space for games...
 This is still Beta. We are working on that before the release, though as 
 always opinions differ:
 http://www.yepthatsme.com/2006/07/08/debian-graphical-installer-excellent-work-guys/
  

It's an opinion about the installer in general, not the look of
buttons and scrollbars.  And the latter doesn't have any _real_
value, yet an amazing amount of people care about pretty widgets.
It makes a helluva difference when trying to sell a program to a
customer...  It costs nothing but a bit of disk space to replace the
Win95 look with something better.
 
  6. As proceeding through module selection on lowmem is doomed to
  lose, the user needs to turn swap on before.  Too bad, the initial
  lowmem message doesn't suggest _when_ swap can be turned on.
 
  Various points:
  * the lowmem message: console 2 is not yet available
  * Detecting CD-ROMs: this is when ide drivers are probed
  * d-i module selection: can't continue past
 
  A simple hint in the lowmem message would save people some time.
 
 Not sure about that as IIRC swap is turned off again during partitioning. 
Then buh-bye, 24MB.  I doubt that it's a good idea to cut away large
pieces of the installer just to handle this case.

 The most important part is not to load more modules than you
 strictly need.
Can't get lower than no extra modules at all, even fs ones :p

  7. On 24MB+37MB swap, even with no extra d-i modules chosen, anna
  goes into an OOM loop.  Increasing the swap to 100MB doesn't help
  either.
 We test releases at 32 and 48 MB. I'm not completely surprised that 24 MB 
 does not work. We already know that the current lowmem levels need to be 
 checked and probably adjusted.

I doubt if getting 24MB to work is really worth your time.

  8. I chosen IPv6 support -- incidentally, my network segment was
  v6-only.  Yet, DHCP failed and stateless configuration wasn't used
  either.  The manual config, being given 2002:5033:a761:4::1 started
  to lecture me how an IP address looks like -- saying IP where it
  meant IPv4.
 
 I don't think IPv6 installations have ever really been tested. It would be 
 great if you could do trace the cause of the problems and help us fix 
 them. Please file specific bugs against the relevant d-i components if 
 you find issues.

There are two issues:
1. DHCP+debconfage
2. wget

For 1., I'm not sure how widespread DHCP6 is.  It's pretty new, while
radvd works even with Microsoft crap.
But, at the very least, having the manual config accept IPv6
addresses would be a must.

For 2., it looks like you already found the culprit:

  10. And yet, even though ftp.pl.debian.org is reachable over IPv6,
  mirror-chooser wasn't happy.  It turns out that the 'wget' binary
  provided by busybox is a crippled IPv4-only.
 That should be a matter of enabling the relevant options in the busybox 
 configuration.
 
 A quick grep on the busybox config gives me:
 CONFIG_FEATURE_IPV6 is not set
 CONFIG_FEATURE_WGET_IP6_LITERAL=y
 
 Looks like the first needs to be enabled...

Wonderful.  And, udeb-floppy is separate from udeb, so an eventual
slight size increase won't be noticeable for netinst.  I'm not that
sure if the diff is bigger than several bytes...

  11. It turned out the disk controller/mobo/something on the P1 box
  was somewhat flaky, causing intermittent faults.  If something bad
  happens during debootstrap, the d-i wrapper over it gives a dialog
  box with two choices: Go back and Continue.  Too bad, whatever
  you choose, it proceeds with the latter -- yet, failing at the end
  even if you fix the error manually.
 
 Handling of the two buttons can indeed be improved in some places. It's 
 not always as easy as it sounds to define correct behavior though.

Continue may be trickier, but for Go back, the correct behavior
smells like killing away the 

d-i on ancient hardware

[Adam Borowski]

Whee?!

I tested d-i (2006.07.02 daily netinst) on a real 80486 with 24MB
memory, and here's the story.  Just note that d-i is completely
outside of my area of expertise, so this is quite a newbish report.


1. The BIOS was too old to support booting from CD.  Someone
suggested using SBM, but, too bad, it doesn't appear to be on the
netinst CD.  The box doesn't have a working floppy, and the woody on
it lacks drivers for the network card.  Fortunately, the box
dual-booted to MS-DOS 6.22(!).  And here goes loadlin...

I wonder what's the purpose in shipping loadlin these days.  It
needs to be run in real mode, and AFAIK even Windows98 can't be
forced to start it.  The incidence of real-mode-capable DOS is so low
that loadlin can be reasonably purged from any space-tight images.

On the other hand, if you insist on keeping loadlin, please provide a
.bat file.  A beginner user won't know to look in isolinux.cfg to
copy the append line; also, there's no GPM in stone-age OSes...



2. [G-I]: If the graphics card is not VESA-compliant, the error
message about an invalid _text_ mode can be confusing.


3. [G-I]: On lowmem, it would be better to flat-out refuse to run the
graphical installer; a blank screen is an ugly way to die.


4. [G-I] [Off-topic]: As you already don't support my magnificent 486
and similar, why won't you slap any theme on?  The current widgets
are hideous, and since there's space for games...


Ok, let's continue with the text installer...

5. A question Choose a country, territory or area has Choose
language on the dialog caption.  What language, who, where? 
Especially as lowmem just gave me a message about continuing in
English, this can be confusing.  What about Choose location?



6. As proceeding through module selection on lowmem is doomed to
lose, the user needs to turn swap on before.  Too bad, the initial
lowmem message doesn't suggest _when_ swap can be turned on.

Various points:
* the lowmem message: console 2 is not yet available
* Detecting CD-ROMs: this is when ide drivers are probed
* d-i module selection: can't continue past

A simple hint in the lowmem message would save people some time.



7. On 24MB+37MB swap, even with no extra d-i modules chosen, anna
goes into an OOM loop.  Increasing the swap to 100MB doesn't help
either.

In fact, I failed to find _any_ way to go past on 24MB physical.

Oh well, I moved the disk to the next machine in my junk pile, a
Pentium1 MMX with 32MB ram.


8. I chosen IPv6 support -- incidentally, my network segment was
v6-only.  Yet, DHCP failed and stateless configuration wasn't used
either.  The manual config, being given 2002:5033:a761:4::1 started
to lecture me how an IP address looks like -- saying IP where it
meant IPv4.

I set up network connectivity manually.  By the way, having ping
and the like around would be helpful; installation is exactly the
point where network diagnostics is the most useful.

Fortunately, ping works two-way.  I had the box world-reachable
(tested) with untested DNS resolution.


9. But yet, the installer won't let me continue until I complete
network config.  With no other option, I gave it a bogus IPv4
address and then restored the connectivity it overwrote.


10. And yet, even though ftp.pl.debian.org is reachable over IPv6,
mirror-chooser wasn't happy.  It turns out that the 'wget' binary
provided by busybox is a crippled IPv4-only.

So oh well, I had to make IPv4 work to make it happy.



11. It turned out the disk controller/mobo/something on the P1 box
was somewhat flaky, causing intermittent faults.  If something bad
happens during debootstrap, the d-i wrapper over it gives a dialog
box with two choices: Go back and Continue.  Too bad, whatever
you choose, it proceeds with the latter -- yet, failing at the end
even if you fix the error manually.
That is, this is the case only if the error happened during the
retrieval/verifying phase.  If the error happens during unpack or
configure, _both_ choices act as Go back, regardless whether you
fix the error by hand or not.



12. Why does it use debootstrap AT ALL?  This is something that could
be much better done at d-i build time instead of the installation
itself.  Unpacking a tarball takes seconds even on this bitty box.
Debootstrap takes ages on modern hardware, too -- on the order of
5mins on my desktop when pulling debs from a proxy over a 350KB/s
link.

Shaving at least several minutes off every install is not something
to shake a stick at...



Due to unsound hardware, I repeated successful installation thrice to
make sure no further errors can be blamed on the damn P1.  For this
reason I also delayed tasksel until after the reboot, on the 486
which is in good condition.


13. When booting, I get Begin: Waiting for root file system... ...
and a 5min wait before getting dropped to a shell.  It then needs a
modprobe ide-disk.  Curiously, you need to wait several seconds
before closing the shell or it will fail again -- this gives a good
hint towards