[fedora-arm] F26 Python LC_CTYPE=C complaint.

Discussion:

Richard Ryniker

2017-04-19 14:31:19 UTC

Running on Raspberry Pi 3, with updates to April 19:

[***@RPi3-2 ~]$ uname -a
Linux RPi3-2 4.11.0-0.rc5.git0.1.fc26.armv7hl #1 SMP Mon Apr 3 21:06:36 UTC 2017 armv7l armv7l armv7l GNU/Linux
[***@RPi3-2 ~]$ /usr/bin/python3.6 --version
Python detected LC_CTYPE=C: LC_ALL & LANG coerced to C.UTF-8 (set another locale or PYTHONCOERCECLOCALE=0 to disable this locale coercion behaviour).
Python 3.6.0
[***@RPi3-2 ~]$ env | grep LC
LC_ALL=C
[***@RPi3-2 ~]$

I downloaded and built the current 3.6.1 Python with only default
configuration, and there is no complaint:

[***@RPi3-2 ~]$ /usr/local/bin/python3.6 --version
Python 3.6.1
[***@RPi3-2 ~]$

If Fedora packages Python configured to complain about awkward locale
settings, it would be nice if Fedora starts after installation with a
non-objectionable value.

In order to boot F26 on a Raspberry Pi, it is necessary to blacklist the
vc4 module to avoid a kernel failure
(https://bugzilla.redhat.com/show_bug.cgi?id=1387733). This means the
default target can be multi-user, but not graphical. Consequently, the
first boot application never runs. Is first boot where appropriate
locale configuration should occur?
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedora

Dennis Gilmore

2017-04-19 17:09:25 UTC

Permalink

Post by Richard Ryniker
Linux RPi3-2 4.11.0-0.rc5.git0.1.fc26.armv7hl #1 SMP Mon Apr 3
21:06:36 UTC 2017 armv7l armv7l armv7l GNU/Linux
Python detected LC_CTYPE=C: LC_ALL & LANG coerced to C.UTF-8 (set
another locale or PYTHONCOERCECLOCALE=0 to disable this locale
coercion behaviour).
Python 3.6.0
LC_ALL=C
I downloaded and built the current 3.6.1 Python with only default
Python 3.6.1
If Fedora packages Python configured to complain about awkward locale
settings, it would be nice if Fedora starts after installation with a
non-objectionable value.
In order to boot F26 on a Raspberry Pi, it is necessary to blacklist the
vc4 module to avoid a kernel failure
(https://bugzilla.redhat.com/show_bug.cgi?id=1387733). This means the
default target can be multi-user, but not graphical.Â Â Consequently,
the
first boot application never runs.Â Â Is first boot where appropriate
locale configuration should occur?

this is a generic issue not arm specific so is more appropriate on the
devel list however it is related to
https://fedoraproject.org/wiki/Changes/python3_c.utf-8_locale there are
a few ways to work around it. one of which is to set your locale to
C.UTF-8 or to make sure that you have the glibc-langpack-<foo> locale
installed for your running locale

Dennis

Richard Ryniker

2017-04-19 18:17:53 UTC

Permalink

Post by Dennis Gilmore
this is a generic issue not arm specific so is more appropriate on the
devel list however it is related to
https://fedoraproject.org/wiki/Changes/python3_c.utf-8_locale there are
a few ways to work around it. one of which is to set your locale to
C.UTF-8 or to make sure that you have the glibc-langpack-<foo> locale
installed for your running locale

Thank you for the link. I admire the Python folk who understood the
importance of encoding support for character data, and suffered the pain
necessary to implement a correct, robust implementation.

My concern for Fedora is whether a default installation can select locale
data that avoids this situation. Have the current problems with the
Raspberry Pi platform scuttled the usual process to define locale for a
Fedora installation? Or is this an outstanding issue for every F26 user?
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscri

Paul Whalen

2017-04-19 17:29:57 UTC

Permalink

----- Original Message -----

Post by Richard Ryniker
Linux RPi3-2 4.11.0-0.rc5.git0.1.fc26.armv7hl #1 SMP Mon Apr 3 21:06:36 UTC
2017 armv7l armv7l armv7l GNU/Linux
Python detected LC_CTYPE=C: LC_ALL & LANG coerced to C.UTF-8 (set another
locale or PYTHONCOERCECLOCALE=0 to disable this locale coercion behaviour).
Python 3.6.0
LC_ALL=C
I downloaded and built the current 3.6.1 Python with only default
Python 3.6.1
If Fedora packages Python configured to complain about awkward locale
settings, it would be nice if Fedora starts after installation with a
non-objectionable value.
In order to boot F26 on a Raspberry Pi, it is necessary to blacklist the
vc4 module to avoid a kernel failure
(https://bugzilla.redhat.com/show_bug.cgi?id=1387733). This means the

Hopefully this is no longer the case. On the 20170416 nightly images[1] I
didn't need to blacklist on my problematic monitor (Haier 21").

Post by Richard Ryniker
default target can be multi-user, but not graphical. Consequently, the
first boot application never runs. Is first boot where appropriate
locale configuration should occur?

The display and initial-setup should come up even with the module
blacklisted (perhaps not on workstation, not tested there), you lose some
performance but it should be very usable.

Paul

[1] - https://kojipkgs.fedoraproject.org/compose/branched//Fedora-26-20170416.n.0/compose/Spins/armhfp/images/

Post by Richard Ryniker
_______________________________________________

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubsc

Richard Ryniker

2017-04-20 14:13:25 UTC

Permalink

Post by Paul Whalen

Post by Richard Ryniker
In order to boot F26 on a Raspberry Pi, it is necessary to blacklist the
vc4 module to avoid a kernel failure
(https://bugzilla.redhat.com/show_bug.cgi?id=1387733). This means the

Hopefully this is no longer the case. On the 20170416 nightly images[1] I
didn't need to blacklist on my problematic monitor (Haier 21").

It is still true (for me), using
Fedora-Workstation-armhfp-26-20170419.n.0-sda.raw.xz

Full log at: http://ryniker.org/Fedora/arm/log_02

My monitor displays several hundred lines during boot before the failure,
which presumably occurs during the attempt to start a graphical
environment for first boot.

Apr 20 09:46:35 localhost kernel: ------------[ cut here ]------------
Apr 20 09:46:35 localhost kernel: WARNING: CPU: 0 PID: 34 at drivers/gpu/drm/drm_atomic_helper.c:1122 drm_atomic_helper_wait_for_vblanks+0xdc/0x1e8 [drm_kms_helper]
Apr 20 09:46:35 localhost kernel: [CRTC:65] vblank wait timed out
Apr 20 09:46:35 localhost kernel: Modules linked in: xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 fuse tun nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c crc32_arm_ce iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables joydev brcmfmac brcmutil cfg80211 rfkill vc4 snd_soc_core ac97_bus snd_pcm_dmaengine bcm2835_rng bcm2835_wdt bcm2835_dma leds_gpio nfsd auth_rpcgss nfs_acl lockd grace hid_logitech_hidpp hid_logitech_dj smsc95xx usbnet mii mmc_block snd_pcm snd_timer
Apr 20 09:46:35 localhost kernel: snd soundcore drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm dwc2 udc_core sdhci_iproc sdhci_pltfm sdhci bcm2835 i2c_bcm2835 mmc_core pwm_bcm2835 sunrpc scsi_transport_iscsi
Apr 20 09:46:35 localhost kernel: CPU: 0 PID: 34 Comm: kworker/0:1 Tainted: G W 4.11.0-0.rc6.git0.1.fc26.armv7hl #1
Apr 20 09:46:35 localhost kernel: Hardware name: Generic DT based system
Apr 20 09:46:35 localhost kernel: Workqueue: events vc4_seqno_cb_work [vc4]
Apr 20 09:46:35 localhost kernel: [<c0311700>] (unwind_backtrace) from [<c030c430>] (show_stack+0x18/0x1c)
Apr 20 09:46:35 localhost kernel: [<c030c430>] (show_stack) from [<c0639384>] (dump_stack+0x80/0xa0)
Apr 20 09:46:35 localhost kernel: [<c0639384>] (dump_stack) from [<c034c874>] (__warn+0xe4/0x104)
Apr 20 09:46:35 localhost kernel: [<c034c874>] (__warn) from [<c034c8d0>] (warn_slowpath_fmt+0x3c/0x4c)
Apr 20 09:46:35 localhost kernel: [<c034c8d0>] (warn_slowpath_fmt) from [<bf2103f0>] (drm_atomic_helper_wait_for_vblanks+0xdc/0x1e8 [drm_kms_helper])
Apr 20 09:46:35 localhost kernel: [<bf2103f0>] (drm_atomic_helper_wait_for_vblanks [drm_kms_helper]) from [<bf4137c8>] (vc4_atomic_complete_commit+0x5c/0xb4 [vc4])
Apr 20 09:46:35 localhost kernel: [<bf4137c8>] (vc4_atomic_complete_commit [vc4]) from [<c0364ef8>] (process_one_work+0x254/0x42c)
Apr 20 09:46:35 localhost kernel: [<c0364ef8>] (process_one_work) from [<c036600c>] (worker_thread+0x2b8/0x434)
Apr 20 09:46:35 localhost kernel: [<c036600c>] (worker_thread) from [<c036abdc>] (kthread+0x120/0x138)
Apr 20 09:46:35 localhost kernel: [<c036abdc>] (kthread) from [<c0307e58>] (ret_from_fork+0x14/0x3c)
Apr 20 09:46:35 localhost kernel: ---[ end trace f56f6c0054d1c6b0 ]---
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedorapr

Peter Robinson

2017-04-20 14:18:29 UTC

Permalink

Post by Richard Ryniker

Post by Paul Whalen

Hopefully this is no longer the case. On the 20170416 nightly images[1] I
didn't need to blacklist on my problematic monitor (Haier 21").

Can you report it upstream with that crash, details of the
kernel/monitor/interface used to connect to the monitor etc
https://github.com/anholt/linux/issues
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe

Richard Ryniker

2017-04-20 15:06:50 UTC

Permalink

Post by Richard Ryniker

Post by Paul Whalen

Hopefully this is no longer the case. On the 20170416 nightly images[1] I
didn't need to blacklist on my problematic monitor (Haier 21").

I have confirmed that when vc4 is blacklisted in this nightly build, boot
will proceed (slowly) through first-boot and successfully create a user.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fe

Peter Robinson

2017-04-20 15:32:34 UTC

Permalink

Post by Richard Ryniker

Post by Paul Whalen

Hopefully this is no longer the case. On the 20170416 nightly images[1] I
didn't need to blacklist on my problematic monitor (Haier 21").

I have confirmed that when vc4 is blacklisted in this nightly build, boot
will proceed (slowly) through first-boot and successfully create a user.

No, you've misinterpretted me, file a bug with all the issues when vc6
*isn't* blacklisted. While blacklisted the driver works around the
problem it doesn't give accelerated UX and it doesn't work towards
fixing the problem. If the issue isn't reported upstream the
maintainer won't have the details so it can be fixed!
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an

Richard Ryniker

2017-04-20 16:08:09 UTC

Permalink

I understood, will report as you suggested later today. Too many balls
in the air right now.

Post by Paul Whalen
The display and initial-setup should come up even with the module
blacklisted (perhaps not on workstation, not tested there), you lose some
performance but it should be very usable.

I did want to state my success following Paul Whalen's remark, in case
others face the same problem. I do not think the desktop is "very
usable" but the important result is the system can be configured with
users, etc. Access via ssh works fine, no vc4 problems there.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an em

r***@alum.mit.edu

2017-04-20 18:33:18 UTC

Permalink

Upstream is https://github.com/anholt/linux/issues/66
opened Oct 25, 2016.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedorapr