Bug#915368: installation-reports: Lenovo X1 Carbon 6th Gen: touchpad & touchpoint issues, confusing network hardware

2018-12-02 Thread Duncan Findlay 
Package: installation-reports
Severity: normal

-- Package-specific info:

Boot method: USB
Image version: Buster Alpha 3 netinst ISO 
https://cdimage.debian.org/cdimage/buster_di_alpha3/amd64/iso-cd/debian-buster-DI-alpha3-amd64-netinst.iso
Date: 2018-12-02

Machine: Lenovo X1 Carbon 6th Gen
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[E]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[E]

Comments/Problems:

- Initial UEFI boot to the graphical instaler failed with a blank
  screen. Enabling CSM support in the BIOS fixed it (still set to
  "UEFI only").

- Network: Wifi device not supported due to missing firmware. I was
  using an external USB-C dock with Ethernet, and this was listed by
  D-I as "Unknown interface", causing some confusion. (I incorrectly
  assumed I wanted to pick "Intel Corporation Ethernet Connection (4)
  I219-V" but that didn't work. I assume that's some built in hardware
  only usable with a Lenovo propietary dock connector.)

  The "Unknown Interface" USB ethernet adapter has id 0bda:8152.

- Throughout the installation process and after boot, the touchpad and
  trackpoint did not function. I believe this is
  https://bugs.debian.org/875621. I had to recompile the kernel after
  boot, setting CONFIG_RMI4_SMB=m. Not ideal. For comparison, the
  touchpad & trackpoint worked fin with a debian stretch 9.6 live CD,
  so this feels like a regression.


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20180610"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux pine 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5914] 
(rev 08)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:5917] (rev 07)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Skylake Processor Thermal Subsystem [8086:1903] (rev 08)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Skylake 
Gaussian Mixture Model [8086:1911]
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP 
USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise 
Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] 
(rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #5 [8086:9d14] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #9 [8086:9d18] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:9d4e] 
(rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise 
Point-LP PMC [8086:9d21] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Device [8086:9d71] 
(rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:225c]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel,

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-02 Thread Wouter Verhelst 
On Sun, Dec 02, 2018 at 11:31:13PM +0100, Marco d'Itri wrote:
> On Dec 02, Wouter Verhelst  wrote:
> 
> > One thing that has not been answered yet in this discussion (and if the
> > TC is to make a decision about it, I think it should be) is "why are we
> > doing this". That is, what is the problem that usrmerge is meant to
> > solve, and how does it attempt to solve it? As far as I know, the reason
> > usrmerge exists is so that no files will be installed in /bin anymore;
> > but that seems like an XY problem.
> https://lists.debian.org/20181121140542.ga31...@espresso.pseudorandom.co.uk

Thanks; somehow I missed that, sorry.

> > Also, I would like to ask why the traditional solution in Debian -- make
> > a policy change that says no package can ship anything in /bin except
> > for a compatibility symlink, and make that rule RC at some point in the
> > future -- is not being considered. That seems like a solution that would
> > cause far less pain than what we're going through right now.
> This is not a solution. For a start it would take many years.

The fact that doing something in one particular way takes longer does
not in and of itself make it a bad solution.

It also need not take that long. We can declare *right now* that
shipping something in /bin (as opposed to /usr/bin) that is not a
compatibility symlink will be RC in bullseye. This would be plenty of
time for maintainers to be aware of it and to start looking at updating
their packages. With your usrmerge package, it's not at all clear to me
when the migration would be finished.

> Even ignoring that, it would not bring any improvement over the current 
> plan:

This is incorrect. The current plan has some systems be merged-/usr and
others not while we are in the transition. It therefore introduces
Debian-wide complexity in that maintainers are expected to support both
merged and unmerged /usr, which causes problems (as we see here). It
also effects a change without the maintainers of the software in
question being involved, which could have unintended side effects with
some packages that we don't know yet (and that we probably won't know
about until the release of buster).

Changing this through a policy change, as we've always done, would not
have those problems:

- Maintainers are expected to move their own package to merged-/usr, so
  they would be aware of issues that might ensue and would be able to
  deal with them.
- We are not expected to be supporting merged-/usr and unmerged-/usr at
  the same time; instead, we'll be gradually moving towards a
  merged-/usr situation.
- We don't end up with packages' files being moved from under them.

> even if your idea were executed perfectly and quickly then the 
> conversion program would still be in the same exact situation as it is 
> now:

Yes, obviously, that's the whole point.

[...]
> So this would make the transition unacceptably slow while providing no 
> benefit at all,

I don't agree with both these statements.

> but it would also cost a huge amount of work to change many packages.

Yes, and at the same time it would reduce a huge amount of *different*
work, since packages now won't need to be changed so that "being built
on merged-/usr" won't result in packages that don't build on
unmerged-/usr.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-02 Thread Marco d'Itri 
On Dec 02, Wouter Verhelst  wrote:

> One thing that has not been answered yet in this discussion (and if the
> TC is to make a decision about it, I think it should be) is "why are we
> doing this". That is, what is the problem that usrmerge is meant to
> solve, and how does it attempt to solve it? As far as I know, the reason
> usrmerge exists is so that no files will be installed in /bin anymore;
> but that seems like an XY problem.
https://lists.debian.org/20181121140542.ga31...@espresso.pseudorandom.co.uk

> Also, I would like to ask why the traditional solution in Debian -- make
> a policy change that says no package can ship anything in /bin except
> for a compatibility symlink, and make that rule RC at some point in the
> future -- is not being considered. That seems like a solution that would
> cause far less pain than what we're going through right now.
This is not a solution. For a start it would take many years.
Even ignoring that, it would not bring any improvement over the current 
plan: even if your idea were executed perfectly and quickly then the 
conversion program would still be in the same exact situation as it is 
now: either everything in /bin/, /sbin and /lib (and its own 
subdirectories) was created by the packaging system, and then we already 
know that it can be converted automatically, or it was not, and then we 
know that there are a few cases when the local administrator has to 
decide what to do about things that were installed by himself in the 
past in the wrong place.
So this would make the transition unacceptably slow while providing no 
benefit at all, but it would also cost a huge amount of work to change 
many packages.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-02 Thread Wouter Verhelst 
On Wed, Nov 28, 2018 at 01:49:45PM +, Ian Jackson wrote:
> Control: reassign -1 tech-ctte
> 
> Dear Technical Committee.  I don't know if you are all aware of the
> discussion surrounding this, so I will recap:
> 
> Recently debootstrap was changed to do merged-/usr by default, so that
> /bin -> /usr/bin etc.
> 
> It was discovered that when this change took effect on the Debian
> buildds, the buildds started to build packages which do not work on
> non-merged-/usr systems.
> 
> This is a special case of a general problem: buster systems with
> merged-/usr sometimes build packages which are broken on
> non-merged-/usr systems.
> 
> Some people have suggested that this should be fixed by making
> merged-/usr mandatory for buster.  However, there is no transition
> plan for this as yet and I don't think Debian is ready to commit to do
> that.
> 
> So I believe that this change should be immediately reverted in sid
> and buster, so that we do not prejudge the situation by increasing the
> number of buster installs in the field which generate packages which
> are broken on non-merged-/usr systemss.

One thing that has not been answered yet in this discussion (and if the
TC is to make a decision about it, I think it should be) is "why are we
doing this". That is, what is the problem that usrmerge is meant to
solve, and how does it attempt to solve it? As far as I know, the reason
usrmerge exists is so that no files will be installed in /bin anymore;
but that seems like an XY problem.

Also, I would like to ask why the traditional solution in Debian -- make
a policy change that says no package can ship anything in /bin except
for a compatibility symlink, and make that rule RC at some point in the
future -- is not being considered. That seems like a solution that would
cause far less pain than what we're going through right now.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-02 Thread Holger Levsen 
On Sat, Dec 01, 2018 at 10:21:50PM +, Simon McVittie wrote:
> gzip, icecc and mailagent were most recently built for buster on
> 2018-11-08, which might be long enough ago that the buster chroot was
> not merged-/usr?

right. I triggered their builds and now they are all shown as unreproducible.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-02 Thread Simon McVittie 
On Sun, 02 Dec 2018 at 21:21:40 +0900, Hideki Yamane wrote:
>   - What is the problem? (broken build for which packages? Just R?)

The problem we're aware of is:

Some packages auto-detect the absolute path to an executable (for example
bash or perl) and hard-code it into their output (for example the #! line
of the bash scripts in quilt). When built on a system with merged /usr,
they can detect and hard-code a path that exists on merged /usr systems
but does not exist on systems with unmerged /usr, such as #!/usr/bin/bash
or #!/bin/perl.  This results in the package working fine on merged-/usr
systems but not on unmerged-/usr systems.

The quilt bug https://bugs.debian.org/913226 is the one that prompted
me to look at this (it caused build failures in a Debian derivative
that I work on, which is in the process of rebasing from stretch to
buster), and is a fairly typical example. The problem case usually
involves an executable that is canonically in /bin, like bash or sed,
being detected in /usr/bin. I've also seen one occurrence of the reverse,
where an executable that is canonically in /usr/bin is found in /bin on
a merged /usr system, although I can't remember which package that was
(it would have to have been re-ordering PATH to look in /bin first).

The same packages would be similarly broken if they were built with
/usr/local/bin in the PATH, on a system where the executable they are
looking for is present in /usr/local/bin. For example, versions of quilt
where #913226 is unfixed could exhibit a similar problem if built on a
system with a /usr/local/bin/bash.

The same things can happen with /usr/sbin and /sbin.

>   - How many packages are affected?

In ,
Ansgar points to 60 packages found to have this failure mode in a rebuild
covering around 80% of the archive, and estimates that there should be
about 80 packages in total affected by this class of bug.

>   - Why it was caused? (just symlink to /bin or /sbin isn't enough
> to deal with it?)

See the quilt bug I linked above, which is a typical example.

On merged /usr systems there is no problem with the "broken" packages,
because the compatibility symlinks /bin -> /usr/bin and /sbin -> /usr/sbin
ensure that paths like /bin/sh and /usr/bin/sh both work equally well.
The problem only occurs when they are *built* on a system *with* merged
/usr, then *used* on a system *without* merged /usr.

>   - Does it cause any failure on users' machine?

Yes, for example see the quilt bug. The failure mode is:

* A developer, D, has a system with merged /usr
* A user, U, has a system without merged /usr
* D builds a package that has this type of bug
  (without using a non-merged-/usr chroot, for example --variant=buildd from
  debootstrap >= 1.0.111)
* The package works for D
* The package doesn't work for U

smcv

Re: [Pkg-fonts-devel] Bug#911705: #911705 [l10n|gu] debian-installer: fonts broken for Gujarati

2018-12-02 Thread Jonas Smedegaard 
Quoting Holger Wansing (2018-12-02 15:43:57)
> Holger Wansing  wrote:
> > Holger Wansing  wrote:
> > > Holger Wansing  wrote:
> > > > Package: fonts-freefont-udeb
> > > > Severity: normal
> > > > 
> > > > 
> > > > I just noticed that Gujarati is no longer unusable, because of 
> > > > broken font (all characters replaced by placeholder, see 
> > > > attached screenshot).
> > > > 
> > > > This seems to be related to the new fonts-freefont-udeb package, 
> > > > which replaced ttf-freefont-udeb:
> > > > When I use the ttf-freefont-udeb package from Stretch as 
> > > > localudeb to build the netboot-gtk target here locally, Gujarati 
> > > > fonts seem to be fine again (see second screenshot).
> 
> 
> Any chance we can get this fixed for Buster?

Perhaps someone in debian-in can help answer above?

An alternative is for Gujarati to use fonts-noto.  If relevant, then
I'd be happy to extend the fonts-noto udeb as needed, but it needs 
someone who actually understand Gujarati to proof-read if using Noto is 
not inferior to the previous Freefont display, and it needs someone 
(you, Holger?) to help generate something for those Gujarati experts to 
proof-read.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: #911705 [l10n|gu] debian-installer: fonts broken for Gujarati

2018-12-02 Thread Holger Wansing 
Hi,

Holger Wansing  wrote:
> Hi,
> 
> Holger Wansing  wrote:
> > 
> > Holger Wansing  wrote:
> > > Package: fonts-freefont-udeb
> > > Severity: normal
> > > 
> > > 
> > > I just noticed that Gujarati is no longer unusable, because of broken font
> > > (all characters replaced by placeholder, see attached screenshot).
> > > 
> > > This seems to be related to the new fonts-freefont-udeb package, which 
> > > replaced ttf-freefont-udeb:
> > > When I use the ttf-freefont-udeb package from Stretch as localudeb to 
> > > build
> > > the netboot-gtk target here locally, Gujarati fonts seem to be fine again
> > > (see second screenshot).


Any chance we can get this fixed for Buster?


Holger

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

Re: #914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-02 Thread Hideki Yamane 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

On Fri, 30 Nov 2018 19:40:45 +0100
"Didier 'OdyX' Raboud"  wrote:
> tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by 
> default now, or are you OK letting the TC decide on this subject?

 Hmm, I'm still considering what's the good way...

> Hideki, if I read the debootstrap history correctly, you enabled "merged 
> /usr" 
> by default in debootstrap 1.0.102. 

 Yes, that's right. #839046 was filed in Sep 2016, and uploaded in Jun 2018.

> Given the recent discussion in debian-
> devel@ (starting at [0]) and on #914897, could you (or anyone speaking as 
> with 
> a "debootstrap maintainer" hat on) state if, either of:
> 
> * you would be willing to toggle the "merged /usr" default in debootstrap in a
>   subsequent upload;
> * you maintain that the "merged /usr" default (to yes) is here to stay.

 Well, with a quick look to the thread (I cannot follow all of the email in it,
 tons of emails...), I cannot find the discussion about

  - What is the problem? (broken build for which packages? Just R?)
  - How many packages are affected?
  - Why it was caused? (just symlink to /bin or /sbin isn't enough
to deal with it?)
  - Does it cause any failure on users' machine?

 So, I want to listen above things (not thought or idea), then reply to
 your question. Please quote if someone can do it.


- -- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp
 http://wiki.debian.org/HidekiYamane
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEQZYJUbYxgXxV33EdBBJ4KqpAHFMFAlwDzlUACgkQBBJ4KqpA
HFOnfxAAv8s9EQwntX9SBHALIY+5X1Ma98aMhrzZ2SWDt1txznXRt18z/85oOWqs
FGLrm2QY159qWEG2lpsWhAIr7wQJBPcFH5MRQcn6pDM6pXB1ioaTsW9uhd/AMl+s
mCyvWW0xtJ1ww2EXV2hN5X0K4AAre2rajb0P4p6efeY5V9sbMQ/gZa+L2sJuL1P/
/6fK4Kxe893lVuZ3oxtOhKRkdgi1V1X63kUURofuTSZiVzeGYWAuPdnHBxADs9vK
kk6mpUFkYSeOfg45h2KQzUqeTsX5GTogWIFqEOAJ0KJGDusOiFEPWL/pus+De1E7
cyEX2i6yq3wOOQBov5/eNH2gMs9pDaOqM8hR0tjvya4aAJOa7VyFY2GzMdsEHdQe
Ay7EtzG3RLwuiQ0XrSmIyaDdlJpofCGernNgVu+dnBJb/1U4RHgneVbIELULGUYm
DGFov6FpeUQB6wc/fsaoDWQBiwwNCS2qkJnZJg5nu4ne12NqnERqoq2lIR3ivSe2
1Oi9v/ClKqNSKGLAIoRVvllZhs9W1ppwkZIqtC0mZlN05nw7Wyrj4YoRbJ4r70Rd
rdQzTntchOXbYOmdt2H6yUdpnJJoA46+OxlwykvjrUnDnzgheNMJ0wRh36LcOz50
pjQBQGGVVl/9+Tjw/vSCu+alwLwPY34YFOM8I4fh/V0OHbO4fNE=
=yD0D
-END PGP SIGNATURE-