Bug#746966: debian-live: HiDPI support needed for debian-installer

[Robert Edmonds]

Chris Bainbridge wrote:
> After booting the netinst iso, the text of the Debian installer is
> very small on HiDPI displays, for many users it will be  unreadable.
> This problem is going to get worse as higher resolution 4k laptops
> begin to appear.

Hi,

Any update on this? I did a text mode install on a machine with a 13"
3200x1800 screen today and the text was quite tiny.

Thanks!

-- 
Robert Edmonds
edmo...@debian.org

Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap

[Martin Michlmayr]

* Roger Shimizu  [2016-04-12 00:48]:
> I was about to write a list on pros and cons, but I only find pros,
> with some reasons/explanation.
> 
> - Main purpose is to get ready for screen support, which surely cannot
> fit into qnap's image.

Sorry for being unclear: I have no objections to introducing the -qnap
or -tiny image.  I can see why this makes sense.

But you also merge the orion5x and kirkwood images into marvell images
and I see a number of downsides with that (and no obvious advantages).

Can you leave orion5x and kirkwood alone and introduce an
orion5x-qnap, without converting everything to marvell, or do you see
any advantages of combining orion5x and kirkwood into marvell?  (If
there are advantages, please let me know.)

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#792086: keyboard-configuration: can't change the layout to us international

[Stewart C. Russell]

Further to the OP's report, I'm having the identical result.
dpkg-reconfigure keyboard-configuration does nothing for me on two
different systems. The common factor is that they both use slightly
unusual keyboards.

The function ‘keyboard_present’ in keyboard-configuration.config
searches /proc/bus/input/devices for very specific strings. These two
keyboards contain no matches, and thus are not considered to be
attached. Shouting at the computer has not appeared to help in any way.

/proc/bus/input/devices data (from two different machines) for my two
problem keyboards are:

I: Bus=0005 Vendor=0a5c Product=8502 Version=011b
N: Name="Rapoo E6700"
P: Phys=b8:27:eb:0e:e8:ee
S:
Sysfs=/devices/platform/soc/3f201000.uart/tty/ttyAMA0/hci0/hci0:11/0005:0A5C:8502.0002/input/input2
U: Uniq=6c:5d:63:21:fd:ab
H: Handlers=sysrq kbd mouse0 event1
B: PROP=0
B: EV=12001f
B: KEY=1f 1 207 ff9f387a d941d7ff febeffdf ffef 
fffe
B: REL=143
B: ABS=f00 0
B: MSC=10
B: LED=1f

I: Bus=0011 Vendor=0002 Product=000e Version=
N: Name="ETPS/2 Elantech Touchpad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input5
U: Uniq=
H: Handlers=mouse0 event6
B: PROP=5
B: EV=b
B: KEY=e420 1 0 0 0 0
B: ABS=66180001103

Suggestions:

1. Can the OP please post the contents of their /proc/bus/input/devices
file here to see if it would trigger keyboard_present?

2. Would the maintainer(s) consider revisiting the check in
keyboard_present to include more diversity? This is likely hard, and may
break something, somewhere for someone who was relying on it.

3. Are there alternative methods (such as adding to a startup rule file)
that one could alter these device names so that they pass the
keyboard_present test?

Yours truly,
 Stewart C. Russell
 Toronto, Canada.





signature.asc
Description: OpenPGP digital signature

Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap

[Roger Shimizu]

Dear Martin,

Thanks for your feedback!

On Mon, Apr 11, 2016 at 8:43 AM, Martin Michlmayr  wrote:
> * Roger Shimizu  [2016-04-06 01:29]:
>> Hope you can accept these changes this time, because you had some
>> concern last time [3].
>
> Unfortunately I don't have time to review the changes right now.  I'm
> happy with the creation of orion5x-tiny (or orion5x-qnap) if that
> helps you.
>
> However, I'm not sure about merging orion5x and kirkwood into marvell.
> Does that actually gain us anything?  I see several downsides (the
> most obvious one is that it would break the installer links; others
> downsides, which are easier to fix, are that several other udebs would
> need to be updated).  Do you see any advantages (apart from using the
> same name as the kernel)?

I was about to write a list on pros and cons, but I only find pros,
with some reasons/explanation.

- Main purpose is to get ready for screen support, which surely cannot
fit into qnap's image.
  By creating marvell and marvell-tiny, we can easily and safely add
screen-udeb to marvell target and keep it from marvell-tiny target.

- If creating orion5x-tiny or orion5x-qnap, the result is almost the
same, and download links need to be updated, too.

- For "some udebs need to update" part, I guess you mean the device
list in libdebian-installer.git [4]. From what I tested, It works well
with my previous patch without touching that part of code. Maybe
there's some other issues/cases I didn't meet.

[4] 
https://anonscm.debian.org/cgit/d-i/libdebian-installer.git/plain/src/system/subarch-arm-linux.c

- I'm going to add new target "netboot-screen" and
"netboot/network-screen" in addition to current target "netboot" and
"netboot/network-console", because I think the verification of screen
support takes months, if not years, on different platform such as
mips/s390x/sparc/...etc. I don't want to suddenly add screen-udeb and
break a lot arch/platform.
During the "transition" period, with new target "netboot-screen" and
"netboot/network-screen", the download links have to be
appended/changed anyway.
After the verification period, if all platform confirms to work well,
we can choose to A) rename new targets to old nearest ones; or B)
remove old targets and keep only the new ones. The previous one can
keep download links, though.

- By updating the download links, YES, the manual have to be updated.
Let's face it since screen is introduced in, and manuals have to be
changed a lot anyway.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Processed (with 1 error): your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 733686 debian-installer-7.0-netboot-mips: Partitioning step
Bug #733686 [debian-installer-7.0-netboot-mips] 
debian-installer-7.0-netboot-mips: Partitioning step fails during netboot 
install on SGI O�
Changed Bug title to 'debian-installer-7.0-netboot-mips: Partitioning step' 
from 'debian-installer-7.0-netboot-mips: Partitioning step fails during netboot 
install on SGI O�'.
> fails during netboot install on SGI O2
Unknown command or malformed arguments to command.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
733686: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733686
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: moving up severity for attention

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 767487 important
Bug #767487 [debian-installer] debian-installer: virtio support for powerpc 
cdrom/netboot installs
Severity set to 'important' from 'normal'
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
767487: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767487
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#279888: marked as done (yaboot-installer: support pegasos2 ...)

[Debian Bug Tracking System]

Your message dated Mon, 11 Apr 2016 15:57:14 +0200
with message-id 

and subject line 
has caused the Debian Bug report #279888,
regarding yaboot-installer: support pegasos2 ...
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
279888: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279888
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: yaboot-installer
Severity: wishlist


Kamion, as discussed on irc, i am filling here a bug report to add
support yaboot on pegasos 2. This is not urgent, since first we need to
convinve Ethan to let Warren include the amiga partition table patch,
and second i need to release the fixed OF upgrade that enables support
for it.

Anyway, the info you asked are : 

1) how to detect a pegasos 2 in yaboot-installer ? 

   /proc/cpuinfo has the field :

   machine : CHRP Pegasos2 

   or 

   machine : CHRP Pegasos

   Depending on the pegasos model.

2) What to do to install yaboot ? 

  Well, this one is easy, as there is no magic to do. Just move the
  /usr/lib/yaboot/yaboot to /boot, and that's it. The OF will be set to
  autoboot this yaboot binary (we can use code similar to the
  nobootloader one to tell the user how to do this if needed), and
  yaboot will get its config file from /etc/yaboot.conf as usual.

  There is no need to run ybin at all, or to move it to a prep partition
  or anything such.

3) Inform the user of the OF variable setting as mentioned above.

4) ofpath needs some fixing. In particular there are two issues :

  1) OF syntax may differ a little, should not, but may. I need to test
  this in details. Also not sure if yaboot can make use of devaliases.

  2) pegasos partitions start at 0, not 1. not sure how apple or ibm
  handle those, but the yaboot documentation seems to start counting at
  1.

Ok, noted here for reference, and as said no urgency. I will probably
contribute to this myself next week too. Especially point 3) and 4)
which needs real hardware for testing.

Friendly,

Sven Luther


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.8-pegasos
Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15)


--- End Message ---
--- Begin Message ---
pretty sure debian works there--- End Message ---