Re: [console-setup] udebs declared as Multi-Arch: foreign

[Ian Campbell]

On Mon, 2018-12-17 at 15:46 +, Ben Hutchings wrote:
> I mean both udebs (kernel-image-*.udeb and *-modules-*.udeb) and the
> full linux-image-*.deb.

Oh, of course! Thanks.

Ian.

Re: Encrypted /boot

[Cyril Brulebois]

Hello,

autos...@riseup.net  (2018-12-17):
> I have managed to find a way to trick the Debian installer into
> encrypting the /boot partition, so that only the MBR GRUB portion of
> the hard drive is unencrypted.
> 
> This means the password must be input twice at boot, but on the plus
> side, the Linux kernel lives in /boot, so the system is better
> protected.
> 
> Are you interested in how I did this? I have a full step-by-step guide
> which I have tried to minimize as much as possible.  I was hoping it
> could be engineered into a guided installation option.
> 
> Note: it only involved one reboot back into the installer environment.
> 
> Also, I did it with GPT, which is also something that D-I should
> support, especially when it comes to encrypted disks (GPT stores a
> couple backups of the partition table).

This seems like something that we should support at some point, AFAICT
grub's cryptodisk support has been around for quite a while, but I've
never managed to dive into it.

A step by step guide would certainly be helpful to others, and might be
a basis for d-i contributors to get involved in implementing this.

Thanks for your proposal.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: [console-setup] udebs declared as Multi-Arch: foreign

[Ben Hutchings]

On Mon, 2018-12-17 at 15:33 +, Ian Campbell wrote:
> On Mon, 2018-12-17 at 15:19 +, Ben Hutchings wrote:
> > On Mon, 2018-12-17 at 10:29 +, Ian Campbell wrote:
> > > On Mon, 2018-12-17 at 01:29 +, Ben Hutchings wrote:
> > > > udpkg and the various package retrievers in d-i don't support
> > > > multi-
> > > > arch.  Until they do there's probably little point in adding that
> > > > information to udebs.
> > > 
> > > It's also not terribly clear what the utility of a multiarchified
> > > installer initramfs would actually be.
> > 
> > In any case where the installed system will have a 32-bit primary
> > architecture and 64-bit kernel, either the installer should be multi-
> > arch or it will need to support cross-install.
> > 
> > So far we've bodged this by building duplicate 64-bit kernel packages
> > labelled with the 32-bit architecture.
> 
> By "kernel packages" do you mean the `foo.udeb` which knows how to
> select a kernel (I've forgotten the real name) rather than the full
> `linux-image-*.deb`?

I mean both udebs (kernel-image-*.udeb and *-modules-*.udeb) and the
full linux-image-*.deb.

We've done that for at least hppa, mips, mipsel, powerpc, and sparc.

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.




signature.asc
Description: This is a digitally signed message part

Re: [console-setup] udebs declared as Multi-Arch: foreign

[Ian Campbell]

On Mon, 2018-12-17 at 15:19 +, Ben Hutchings wrote:
> On Mon, 2018-12-17 at 10:29 +, Ian Campbell wrote:
> > On Mon, 2018-12-17 at 01:29 +, Ben Hutchings wrote:
> > > udpkg and the various package retrievers in d-i don't support
> > > multi-
> > > arch.  Until they do there's probably little point in adding that
> > > information to udebs.
> > 
> > It's also not terribly clear what the utility of a multiarchified
> > installer initramfs would actually be.
> 
> In any case where the installed system will have a 32-bit primary
> architecture and 64-bit kernel, either the installer should be multi-
> arch or it will need to support cross-install.
> 
> So far we've bodged this by building duplicate 64-bit kernel packages
> labelled with the 32-bit architecture.

By "kernel packages" do you mean the `foo.udeb` which knows how to
select a kernel (I've forgotten the real name) rather than the full
`linux-image-*.deb`?

Ian.

Re: [console-setup] udebs declared as Multi-Arch: foreign

[Ben Hutchings]

On Mon, 2018-12-17 at 15:19 +, Ben Hutchings wrote:
> On Mon, 2018-12-17 at 10:29 +, Ian Campbell wrote:
> > On Mon, 2018-12-17 at 01:29 +, Ben Hutchings wrote:
> > > udpkg and the various package retrievers in d-i don't support
> > > multi-
> > > arch.  Until they do there's probably little point in adding that
> > > information to udebs.
> > 
> > It's also not terribly clear what the utility of a multiarchified
> > installer initramfs would actually be.
> 
> In any case where the installed system will have a 32-bit primary
> architecture and 64-bit kernel, either the installer should be multi-
> arch or it will need to support cross-install.

Actually that wouldn't be needed in every case, but imagine we wanted
to support installation of arm64ilp32 on A64-only hardware...

Ben.

> So far we've bodged this by building duplicate 64-bit kernel packages
> labelled with the 32-bit architecture.
> 
> Ben.
> 
-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.




signature.asc
Description: This is a digitally signed message part

Re: [console-setup] udebs declared as Multi-Arch: foreign

[Ben Hutchings]

On Mon, 2018-12-17 at 10:29 +, Ian Campbell wrote:
> On Mon, 2018-12-17 at 01:29 +, Ben Hutchings wrote:
> > udpkg and the various package retrievers in d-i don't support
> > multi-
> > arch.  Until they do there's probably little point in adding that
> > information to udebs.
> 
> It's also not terribly clear what the utility of a multiarchified
> installer initramfs would actually be.

In any case where the installed system will have a 32-bit primary
architecture and 64-bit kernel, either the installer should be multi-
arch or it will need to support cross-install.

So far we've bodged this by building duplicate 64-bit kernel packages
labelled with the 32-bit architecture.

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.




signature.asc
Description: This is a digitally signed message part

Re: Bug#906016: transition: gjs built with mozjs60

[Julien Cristau]

On 12/17/18 4:08 PM, John Paul Adrian Glaubitz wrote:
> On 12/17/18 3:56 PM, Simon McVittie wrote:
>> gjs recently switched from mozjs52 to mozjs60, and mozjs60 doesn't work
>> on s390x (#909536; about 80% of its tests fail, which means I have no
>> confidence that the resulting binaries would be useful or usable if
>> we ignored the test failures).
> 
> This sounds suspicious and more like a single bug that breaks mozjs60 on
> s390x, maybe similar to the issues we have on SPARC due to the tagged pointers
> conflicting with the extended virtual address on SPARC.
> 
> We might have a patch for s390x in openSUSE/SLE, I'll have a look. There
> also might be one in Fedora we could pick for Debian.
> 
https://bugzilla.mozilla.org/show_bug.cgi?id=1488552 is what I was
hitting last time around.  That got resolved as fixed a few days ago,
although it depends on a refactoring that's not in 60.  Still, might be
worth trying to run SpiderMonkey tests on trunk on 64bit BE and see if
and how much better it is now.

Cheers,
Julien

Re: Bug#906016: transition: gjs built with mozjs60

[John Paul Adrian Glaubitz]

On 12/17/18 3:56 PM, Simon McVittie wrote:
> gjs recently switched from mozjs52 to mozjs60, and mozjs60 doesn't work
> on s390x (#909536; about 80% of its tests fail, which means I have no
> confidence that the resulting binaries would be useful or usable if
> we ignored the test failures).

This sounds suspicious and more like a single bug that breaks mozjs60 on
s390x, maybe similar to the issues we have on SPARC due to the tagged pointers
conflicting with the extended virtual address on SPARC.

We might have a patch for s390x in openSUSE/SLE, I'll have a look. There
also might be one in Fedora we could pick for Debian.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#906016: transition: gjs built with mozjs60

[Simon McVittie]

On Thu, 13 Dec 2018 at 17:00:21 +0100, Emilio Pozuelo Monfort wrote:
> On 13/12/2018 16:58, Emilio Pozuelo Monfort wrote:
> > task-pkgs-are-installable-faux depends on task-gnome-desktop, which depends 
> > on
> > gnome, which is removed from s390x. I'm not comfortable breaking that, you'd
> > need an ack from Cyril for that. The alternative would be to keep building
> > gnome from src:meta-gnome3 on s390x but removing the deps that are not 
> > available,
> > or to apply the proposed mozjs patches from upstream to restore support on 
> > s390x
> > if those are enough.
> 
> Another option is to restrict the task-gnome-desktop check to !s390x. But 
> again
> I'd like an ack from Cyril before doing that in case d-i needs to be updated 
> to
> not offer that on s390x.

For context for those newly Cc'd:

We have this dependency chain:

task-gnome-desktop -> gnome-core -> gnome-shell -> gjs -> mozjs{52,60}

gjs recently switched from mozjs52 to mozjs60, and mozjs60 doesn't work
on s390x (#909536; about 80% of its tests fail, which means I have no
confidence that the resulting binaries would be useful or usable if
we ignored the test failures). As far as I know, the best patches we
have for that are the ones Julien Cristau tested, which might be part
of a solution but are not sufficient on their own to make a reasonable
proportion of the tests pass. (Julien, please correct me if I'm wrong?)

The GNOME team and the release team both seem to be willing to declare
that the "full-fat" GNOME desktop will not be available on s390x
machines, which are very conspicuously not available in a desktop or
laptop form factor :-) I'm fairly sure that GNOME and Mozilla upstream
have no interest in supporting s390x mainframes either. As a result we
have arranged for all the JavaScript-based GNOME packages (most notably
gnome-shell), and the gnome-core and gnome metapackages, to not be built
on s390x. However, this leaves us with an important task package that
isn't installable on a release architecture, causing migration to fail.

I suspect gnome-shell may have never worked acceptably on s390x in any
case, since mainframes are not noted for their 3D graphics hardware,
and s390x is not currently whitelisted to build the llvmpipe software
renderer in mesa's debian/rules (I believe the Mesa maintainers are
willing to enable llvmpipe on new architectures after a porter has tested
it and told them it works, so a s390x porter could usefully try that out).

The options I can see are:

* Accept that task-gnome-desktop is not going to be installable on s390x.
  Change the testing migration scripts to skip installability testing for
  that package on s390x, or ignore the fact that it fails. Optionally
  change tasksel to make task-gnome-desktop Architecture: any, and give it
  some Build-Depends-Arch that are not satisfiable on s390x so that it will
  not be built there.
  - s390x d-i users will not be able to install a GNOME desktop. Hopefully
the menu item would not appear, and task-desktop would pick up the
second-preference desktop instead, which currently seems to be XFCE?
  - Risk: is it possible to ignore uninstallability of task-gnome-desktop
without ignoring uninstallability of other task packages?

* Require task-gnome-desktop to be installable on s390x, but modify
  meta-gnome3 so that on s390x, gnome-core installs something that is not
  the full GNOME 3 desktop used on other architectures, for example
  the GNOME-2-derived gnome-session-flashback instead of gnome-session and
  gnome-shell, and lightdm instead of gdm3.
  - s390x users will not get the same GNOME desktop everyone else does.
  - Risk: if GNOME Flashback becomes unsupportable in some future release
(it's a GNOME 2 derivative a bit like MATE, although without using
forks of the apps, and most upstream and downstream GNOME maintainers
don't use or maintain it), we're back where we started.

* Require task-gnome-desktop to be installable on s390x, but modify
  meta-gnome3 so that on s390x, gnome-core doesn't install a whole desktop
  enviroment at all, just the GNOME applications.
  - s390x users will not get a GNOME desktop at all.
  - Risk: this is not what the user asked for or expected.

* Require task-gnome-desktop to be installable on s390x, but modify
  either tasksel or meta-gnome3 so that on s390x, task-gnome-desktop
  installs some GNOME-derived but non-GNOME desktop environment like MATE.
  - s390x users will not get the same desktop environment everyone
else does.
  - Risk: this is not what the user asked for or expected.

I don't think waiting for someone who understands s390x to fix gjs-on-s390x
is an option, although s390x porters are very welcome to prove me wrong!

How should we proceed?

Thanks,
smcv

Encrypted /boot

[autosend]

I have managed to find a way to trick the Debian installer into encrypting the
/boot partition, so that only the MBR GRUB portion of the hard drive is
unencrypted.
This means the password must be input twice at boot, but on the plus side, the
Linux kernel lives in /boot, so the system is better protected.

Are you interested in how I did this? I have a full step-by-step guide which I
have tried to minimize as much as possible.
I was hoping it could be engineered into a guided installation option.

Note: it only involved one reboot back into the installer environment.

Also, I did it with GPT, which is also something that D-I should support,
especially when it comes to encrypted disks (GPT stores a couple backups of the
partition table).

Re: [console-setup] udebs declared as Multi-Arch: foreign

[Ian Campbell]

On Mon, 2018-12-17 at 01:29 +, Ben Hutchings wrote:
> udpkg and the various package retrievers in d-i don't support multi-
> arch.  Until they do there's probably little point in adding that
> information to udebs.

It's also not terribly clear what the utility of a multiarchified
installer initramfs would actually be.

Ian. 

Re: Debian Installer Buster Alpha 4 release

[Rick Thomas]

> On Dec 15, 2018, at 2:26 PM, Cyril Brulebois  wrote:
> 
> Hardware support changes
> 
> 
> * debian-installer:
>- [armel] Disable OpenRD targets, no longer present in u-boot.

Does this mean that my OpenRD hardware will no longer be supported in Buster?
What about SheevaPlug hardware?  Is that still supported by upstream u-boot?
   …
> * u-boot:
   …
>- [armel] Drop openrd targets (no longer supported upstream).

Nice, physically small, reliable hardware…  A shame to see it go…

>- u-boot-imx: Remove mx6cuboxi4x4 target, as ram is now properly
>  detected with mx6cuboxi.

Good news!  Glad to hear it.

Thanks for all your work!
Rick

Re: [debian-installer] Call to update translations for Buster

[Holger Wansing]

Hi,

Holger Wansing  wrote:
> Hi translators,
> 
> since we are slowly coming nearer to the end of the development cycle for 
> Buster, it's probably a good time to send a heads-up to you for the 
> debian-installer now.
> 
> There is still a lot of time left, but you might want to start working on
> translation updates now, to save yourself from a last-minute hurry! :-)
> 
> 
> For those of you who are working directly on the Debian GIT repository, this
> is at https://salsa.debian.org/installer-team/d-i.
> 
> Or, if you work via the Weblate web interface, use
> https://hosted.weblate.org/projects/debian-installer/.
> 
> For some statistics, visit https://d-i.debian.org/l10n-stats/.
> 
> 
> 
> In case of questions or trouble, don't hesitate to ask for help on
> debian-boot or me.

This is the second reminder, only several weeks left until the freeze dance
begins.
Hurry up ;-)


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: [installation-guide] Call to update translations for Buster

[Holger Wansing]

Hi,

Holger Wansing  wrote:
> Hi all,
> 
> since we are slowly coming nearer to the end of the development cycle for 
> Buster, it's probably a good time to send a heads-up to you translators for
> the installation-guide now.
> 
> There are still several months left, but you might want to start working on
> translation updates now, to save yourself from last-minute hurry! :-)
> 
> (Several languages are updated regularly, and don't need this heads-up 
> mail strictly spoken :-) This is really great. 
> I added those to the recipients nevertheless, just for completeness.)
> 
> Please find the Debian GIT repository at
> https://salsa.debian.org/installer-team/installation-guide
> 
> 
> In case of questions or trouble, don't hesitate to ask for help on
> debian-boot@lists.debian.org or me.
> 
> 
> Thanks for your time

This is the second reminder, only several weeks left until the freeze dance
begins.
Hurry up ;-)


Holger




-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076