Re: C.UTF-8 as default locale

[Baptiste Daroussin]

On Sun, Nov 04, 2018 at 09:35:48AM +0300, Yuri Pankov wrote:
> Hi,
> 
> Looking through https://wiki.freebsd.org/DevSummit/201810, I noticed the
> following entry:
> 
> - Make C.UTF-8 the default locale (conrad, dteske(installer))
> 
> As this sort of change is better done early, I have put togetger a
> simple change introducing C.UTF-8 locale using the same common LC_CTYPE
> map as other UTF-8 locales (and it's now the source of symlinks instead
> of en_US one), and having all other components use C locale:
> 
> https://reviews.freebsd.org/D17833
> 
> With that in place, next step is likely to be updating 'default' entry
> in /etc/login.conf to include 'charset=UTF-8' and 'lang=C.UTF-8', and
> changes to installer are likely to be not needed?
> 


Hey I never thought it could be done in such an easy way! don't know why,
I was always looking at it in a complex way, thus never started it.

Thank you very much, this looks fine to me! and that is imho a great addition

Best regards,
Bapt


signature.asc
Description: PGP signature

armv7 BETA3 panics when usb-disk inserted

[Poul-Henning Kamp]

With the 12.0-BETA3 BEAGLEBONE image, I very often see this panic
when I plug a USB attached SSD disk in.

login: ugen1.2:  at usbus1
umass0 on uhub0
umass0:  on 
usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:0:0: Attached to scbus0
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-2 SCSI device
da0: Serial Number 2HC015KJ
da0: 40.000MB/s transfers
da0: 38166MB (78165359 512 byte sectors)
da0: quirks=0x2
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock 
@ /usr/src/sys/cam/scsi/scsi_da.c:2123

cpuid = 0
time = 1541273846
KDB: stack backtrace:
db_trace_self() at db_trace_self
 pc = 0xc05c93f4  lr = 0xc0075dd8 (db_trace_self_wrapper+0x30)
 sp = 0xc35dca40  fp = 0xc35dcb58
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
 pc = 0xc0075dd8  lr = 0xc029d624 (vpanic+0x16c)
 sp = 0xc35dcb60  fp = 0xc35dcb80
 r4 = 0x0100  r5 = 0x0001
 r6 = 0xc06d2cde  r7 = 0xc0a94fd8
vpanic() at vpanic+0x16c
 pc = 0xc029d624  lr = 0xc029d404 (doadump)
 sp = 0xc35dcb88  fp = 0xc35dcb8c
 r4 = 0x  r5 = 0xd1eb1474
 r6 = 0xc06ff75f  r7 = 0xc259b780
 r8 = 0xd1eb1464  r9 = 0xc259b780
r10 = 0x084b
doadump() at doadump
 pc = 0xc029d404  lr = 0xc0282c14 (__mtx_unlock_flags)
 sp = 0xc35dcb94  fp = 0xc35dcbf0
 r4 = 0xc029d404  r5 = 0xc35dcb94
__mtx_unlock_flags() at __mtx_unlock_flags
 pc = 0xc0282c14  lr = 0xc0282538 (__mtx_lock_flags+0xec)
 sp = 0xc35dcbf8  fp = 0xc35dcc20
 r4 = 0x  r5 = 0xd1eb1464
 r6 = 0xc06ff75f r10 = 0x084b
__mtx_lock_flags() at __mtx_lock_flags+0xec
 pc = 0xc0282538  lr = 0xc002f384 (daasync+0x5c)
 sp = 0xc35dcc28  fp = 0xc35dcc70
 r4 = 0xc0018574  r5 = 0xd375f940
 r6 = 0x0400  r7 = 0xc23ed900
 r8 = 0x  r9 = 0xc072ee95
r10 = 0xd375f940
daasync() at daasync+0x5c
 pc = 0xc002f384  lr = 0xc000f6e4 (xpt_async_process_dev+0x220)
 sp = 0xc35dcc78  fp = 0xc35dcca8
 r4 = 0xc0018574  r5 = 0xd375f940
 r6 = 0x0400  r7 = 0xc002f328
 r8 = 0xc2322320  r9 = 0xc072ee95
r10 = 0xc2322300
xpt_async_process_dev() at xpt_async_process_dev+0x220
 pc = 0xc000f6e4  lr = 0xc000e614 (xptdevicetraverse+0xa4)
 sp = 0xc35dccb0  fp = 0xc35dccd0
 r4 = 0xd376994c  r5 = 0xd1eb1474
 r6 = 0xc072ee95  r7 = 0xd1eb1000
 r8 = 0xd3769900  r9 = 0xd41a2800
r10 = 0xc000f4c4
xptdevicetraverse() at xptdevicetraverse+0xa4
 pc = 0xc000e614  lr = 0xc000e3a0 (xpttargettraverse+0x7c)
 sp = 0xc35dccd8  fp = 0xc35dccf8
 r4 = 0xd3769900  r5 = 0xd376994c
 r6 = 0xd3769800  r7 = 0xc091a140
 r8 = 0xd41a2800  r9 = 0xc000f458
r10 = 0xd375f940
xpttargettraverse() at xpttargettraverse+0x7c
 pc = 0xc000e3a0  lr = 0xc000b3f4 ($a.10+0x148)
 sp = 0xc35dcd00  fp = 0xc35dcdc0
 r4 = 0x  r5 = 0x0400
 r6 = 0xd3769900  r7 = 0xc091a140
 r8 = 0xd41a2800  r9 = 0xd375f944
r10 = 0xd375f940
$a.10() at $a.10+0x148
 pc = 0xc000b3f4  lr = 0xc000bbe8 (xpt_done_process+0x3c4)
 sp = 0xc35dcdc8  fp = 0xc35dcdd8
 r4 = 0xd41a2800  r5 = 0xc258ca80
 r6 = 0x  r7 = 0xc091a140
 r8 = 0x0001  r9 = 0x0100
r10 = 0xc35dcdfc
xpt_done_process() at xpt_done_process+0x3c4
 pc = 0xc000bbe8  lr = 0xc000dac4 (xpt_done_td+0xec)
 sp = 0xc35dcde0  fp = 0xc35dce20
 r4 = 0xc091a100  r5 = 0xc06d60c2
 r6 = 0x  r7 = 0xc091a140
xpt_done_td() at xpt_done_td+0xec
 pc = 0xc000dac4  lr = 0xc0262f88 (fork_exit+0xa0)
 sp = 0xc35dce28  fp = 0xc35dce40
 r4 = 0xc259b780  r5 = 0xc23f7390
 r6 = 0xc000d9d8  r7 = 0xc091a100
 r8 = 0xc35dce48  r9 = 0x
r10 = 0x
fork_exit() at fork_exit+0xa0
 pc = 0xc0262f88  lr = 0xc05cbcd4 (swi_exit)
 sp = 0xc35dce48  fp = 0x
 r4 = 0xc000d9d8  r5 = 0xc091a100
 r6 = 0x  r7 = 0x
 r8 = 0x r10 

C.UTF-8 as default locale

[Yuri Pankov]

Hi,

Looking through https://wiki.freebsd.org/DevSummit/201810, I noticed the
following entry:

- Make C.UTF-8 the default locale (conrad, dteske(installer))

As this sort of change is better done early, I have put togetger a
simple change introducing C.UTF-8 locale using the same common LC_CTYPE
map as other UTF-8 locales (and it's now the source of symlinks instead
of en_US one), and having all other components use C locale:

https://reviews.freebsd.org/D17833

With that in place, next step is likely to be updating 'default' entry
in /etc/login.conf to include 'charset=UTF-8' and 'lang=C.UTF-8', and
changes to installer are likely to be not needed?



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r339898 - head/lib/libc/amd64/sys

[Konstantin Belousov]

On Sat, Nov 03, 2018 at 06:59:02PM -0400, Charlie Li wrote:
> On 03/11/2018 11:29, Konstantin Belousov wrote:
> > Some minimal amount of facts instead of guesses would be much more useful.
> > 
> Yeah, being sleep deprived and hurried (on my end) certainly doesn't help.
> > What is the instruction which faulted ?  Disassemble the text at 0x2f5664.
> > Regardless of what is the instruction, show either the output from
> > 'x86info -f' on the machine, or cpu identification lines from the
> > _verbose_ boot dmesg.
> > 
> It appears that 0x2f5664 does not exist:
Or rather, it is a middle of the valid instruction.
Next frame looks like it is process_irelocs(), if trusting the line
numbers.  So most likely it is something related to calling wrong
relocator function, if anything.

Perhaps you could try to trace the things manually, doing
single-stepping of the startup code in debugger. There should be very
modest amount of the irelocs, perhaps only one, and see where things go
off the way.

Might be try to vary the clang version, we know that this work with
6.0.1, and according to your report, breaks with 7.0.  Try clang trunk ?

> 
> Disassembly of section .init:
> 
> 002f565c <_init>:
>   2f565c:   48 83 ec 08 sub$0x8,%rsp
>   2f5660:   e8 fb 3c f3 ff  callq  229360 
>   2f5665:   e8 b6 ff ff ff  callq  2f5620
> <__do_global_ctors_aux>
>   2f566a:   48 83 c4 08 add$0x8,%rsp
>   2f566e:   c3  retq
> 
> CPU ident:
> 
> CPU: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz (2394.52-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x306d4  Family=0x6  Model=0x3d  Stepping=4
> 
> Features=0xbfebfbff
> 
> Features2=0x7ffafbbf
>   AMD Features=0x2c100800
>   AMD Features2=0x121
>   Structured Extended
> Features=0x21c27ab
>   Structured Extended Features3=0x9c00
>   XSAVE Features=0x1
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> > make is statically linked, do dynamically linked program fault ?
> > 
> After some more checks, only the statically linked programs crash.
> 
> -- 
> Charlie Li
> Can't think of a witty .sigline today…
> 
> (This email address is for mailing list use only; replace local-part
> with vishwin for off-list communication)
> 



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r339898 - head/lib/libc/amd64/sys

[Charlie Li]

On 03/11/2018 11:29, Konstantin Belousov wrote:
> Some minimal amount of facts instead of guesses would be much more useful.
> 
Yeah, being sleep deprived and hurried (on my end) certainly doesn't help.
> What is the instruction which faulted ?  Disassemble the text at 0x2f5664.
> Regardless of what is the instruction, show either the output from
> 'x86info -f' on the machine, or cpu identification lines from the
> _verbose_ boot dmesg.
> 
It appears that 0x2f5664 does not exist:

Disassembly of section .init:

002f565c <_init>:
  2f565c:   48 83 ec 08 sub$0x8,%rsp
  2f5660:   e8 fb 3c f3 ff  callq  229360 
  2f5665:   e8 b6 ff ff ff  callq  2f5620
<__do_global_ctors_aux>
  2f566a:   48 83 c4 08 add$0x8,%rsp
  2f566e:   c3  retq

CPU ident:

CPU: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz (2394.52-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306d4  Family=0x6  Model=0x3d  Stepping=4

Features=0xbfebfbff

Features2=0x7ffafbbf
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended
Features=0x21c27ab
  Structured Extended Features3=0x9c00
  XSAVE Features=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
> make is statically linked, do dynamically linked program fault ?
> 
After some more checks, only the statically linked programs crash.

-- 
Charlie Li
Can't think of a witty .sigline today…

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)



signature.asc
Description: OpenPGP digital signature

FreeBSD 12.0-BETA3 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The third BETA build of the 12.0-RELEASE release cycle is now available.

Installation images are available for:

o 12.0-BETA3 amd64 GENERIC
o 12.0-BETA3 i386 GENERIC
o 12.0-BETA3 powerpc GENERIC
o 12.0-BETA3 powerpc64 GENERIC64
o 12.0-BETA3 sparc64 GENERIC
o 12.0-BETA3 armv6 RPI-B
o 12.0-BETA3 armv7 BANANAPI
o 12.0-BETA3 armv7 BEAGLEBONE
o 12.0-BETA3 armv7 CUBIEBOARD
o 12.0-BETA3 armv7 CUBIEBOARD2
o 12.0-BETA3 armv7 CUBOX-HUMMINGBOARD
o 12.0-BETA3 armv7 RPI2
o 12.0-BETA3 armv7 PANDABOARD
o 12.0-BETA3 armv7 WANDBOARD
o 12.0-BETA3 armv7 GENERICSD
o 12.0-BETA3 aarch64 GENERIC
o 12.0-BETA3 aarch64 RPI3
o 12.0-BETA3 aarch64 PINE64-LTS

Note regarding arm SD card images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use SVN to do a source based update of an existing
system, use the "stable/12" branch.

A summary of changes since 12.0-BETA2 includes:

o SPE exception handling was implemented for the powerpcspe
  architecture.  (Note, the powerpcspe build failed for BETA3 for
  reasons unrelated to source code changes, and is being investigated).

o The localedef(1) utility was updated to add '-b' and '-l' options to
  specify output endianness, and now used when building share/ctypedef
  and share/colldef.  (PR 231965)

o The uplcom(4) driver has been updated to add support for formula-based
  arbitrary baud rates.  (PR 225932)

o The cxgbe(4) driver has been updated to use automatic cidx updates
  with ofld and ctrl queues.

o Backwards compatibility for the geli(8) 'attach' subcommand has been
  added, allowing older geli(8) binaries to attach newer geli(4)-backed
  devices.  (PR 232595)

o The timezone database files have been updated to version 2018g.

o Bhyve has been updated to allow the VNC server to listen for incoming
  IPv6 connections.  (PR 232018)

o Various fixes and updates to lualoader.

o NUMA support can now be disabled via sysctl(8) by adding
  vm.numa.disabled=1 in loader.conf(5).

o And various other miscellaneous fixes.

A list of changes since 11.2-RELEASE is available in the stable/12
release notes:

https://www.freebsd.org/releases/12.0R/relnotes.html

Please note, the release notes page is far from complete, and will be
updated on an ongoing basis as the 12.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64 and i386 architectures.
Disk images may be downloaded from the following URL (or any of the
FreeBSD FTP mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/12.0-BETA3/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

 ap-south-1 region: ami-0b11f11c62b62b89a
 eu-west-3 region: ami-0b0fcc030402e10d6
 eu-west-2 region: ami-0192397e78f5895ca
 eu-west-1 region: ami-0db8552914f93ae8c
 ap-northeast-2 region: ami-0baa216e14b3d5ec8
 ap-northeast-1 region: ami-0c7a27bd048ba2d42
 sa-east-1 region: ami-0d063602355a4f1bd
 ca-central-1 region: ami-032a9eb595f2244d3
 ap-southeast-1 region: ami-039dcb5c7817c27a0
 ap-southeast-2 region: ami-0ca61f5d0b3c6ce5b
 eu-central-1 region: ami-02ef27d661779d0a8
 us-east-1 region: ami-07380393ea7dc9ad3
 us-east-2 region: ami-031c7e040e277b3d4
 us-west-1 region: ami-016204e250b5a864f
 us-west-2 region: ami-01f0894333d0750ed

=== Vagrant Images ===

FreeBSD/amd64 images are available on

Re: base packages and 12 -> 13 upgrade

[Boris Samorodov]

On 03.11.2018 18:05, Mikaël Urankar wrote:

Le sam. 3 nov. 2018 à 15:45, Boris Samorodov  a écrit :


Hi All,

A have a base package server and upgraded some of my home servers
to use base packages. Now when the package builder builds packages
for 13-current, what is the procedure to upgrade base packages from
12 to 13?

Whenever I try to install/upgrade packages I get:
---
pkg-static: wrong architecture: FreeBSD:13:amd64 instead of FreeBSD:12:amd64
pkg-static: repository FreeBSD-base contains packages with wrong ABI:
FreeBSD:13:amd64


I think you need to do something like that:
env ABI=FreeBSD:13:amd64 pkg update
env ABI=FreeBSD:13:amd64 pkg upgrade


Yep! That was it. Thank you.

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r339929 no audio output to some sound devices with Firefox and some other applications

[Graham Perrin]

On 03/11/2018 11:48, Hans Petter Selasky wrote:
 
> On 11/3/18 11:32 AM, Graham Perrin wrote:
>
>>  for example:
>>
>> - audible in Chromium, Falkon and Web
>> - silent in Firefox, New Moon (Pale Moon) and Waterfox.
>>
>> HP EliteBook 8570p, integral loudspeakers.
>>
>> If I recall correctly: yesterday I _did_ get audio from at least one of the 
>> affected applications, whilst the notebook was docked. A Philips display 
>> with integral loudspeakers at one of the two DisplayPort sockets at the rear 
>> of the dock.
>
> Which version of Firefox? Cannot reproduce over here.
>
> Did you check the "mixer" controls, that PCM and Master volume is not zero.
>
> --HPS

OK, I dug deeper, to end the silence it's necessary to switch from /dev/dsp0 to 
/dev/dsp1 for each affected application, whilst there's playback from the 
application.

Then (confusingly) adjusting _either_ slider – /dev/dsp0 or /dev/dsp1 – affects 
the output.

Is this expected?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r339898 - head/lib/libc/amd64/sys

[Konstantin Belousov]

On Sat, Nov 03, 2018 at 08:52:16AM -0400, Charlie Li wrote:
> On 01/11/2018 15:43, Charlie Li wrote:
> > On 01/11/2018 12:04, Brooks Davis wrote:
> >> Is this failure with devel/llvm70?  It's currently missing the patch
> >> required to make this work.  https://reviews.freebsd.org/D17709 contains
> >> this patch among others.  I'll see about getting it applied.
> >>
> > Yes, devel/llvm70. Will build with your port commit at my next opportunity.
> > 
> After building world and kernel r340097, kernel runs fine, but every
> userspace program in world crashes with Illegal instruction. They all
> crash in exactly the same way. Example backtrace from bmake, running
> from objdir (first discovered after updating a poudriere jail and
> attempting to even start it):
> 
> Reading symbols from
> /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make...Reading symbols from
> /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make.debug...done.
> done.
> [New LWP 100097]
> Core was generated by `/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make
> --help'.
> Program terminated with signal SIGILL, Illegal instruction.
> #0  0x002f5664 in _init ()
> (gdb) bt
> #0  0x002f5664 in _init ()
> #1  0x002290fe in _start (ap=, cleanup= out>) at /usr/src/lib/csu/amd64/crt1.c:66
> 
> Given the line number referenced in crt1.c, I'm guessing this condition
> may have existed since at least r339351.

Some minimal amount of facts instead of guesses would be much more useful.

What is the instruction which faulted ?  Disassemble the text at 0x2f5664.
Regardless of what is the instruction, show either the output from
'x86info -f' on the machine, or cpu identification lines from the
_verbose_ boot dmesg.

make is statically linked, do dynamically linked program fault ?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: base packages and 12 -> 13 upgrade

[Mikaël Urankar]

Le sam. 3 nov. 2018 à 15:45, Boris Samorodov  a écrit :
>
> Hi All,
>
> A have a base package server and upgraded some of my home servers
> to use base packages. Now when the package builder builds packages
> for 13-current, what is the procedure to upgrade base packages from
> 12 to 13?
>
> Whenever I try to install/upgrade packages I get:
> ---
> pkg-static: wrong architecture: FreeBSD:13:amd64 instead of FreeBSD:12:amd64
> pkg-static: repository FreeBSD-base contains packages with wrong ABI:
> FreeBSD:13:amd64

I think you need to do something like that:
env ABI=FreeBSD:13:amd64 pkg update
env ABI=FreeBSD:13:amd64 pkg upgrade
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

base packages and 12 -> 13 upgrade

[Boris Samorodov]

Hi All,

A have a base package server and upgraded some of my home servers
to use base packages. Now when the package builder builds packages
for 13-current, what is the procedure to upgrade base packages from
12 to 13?

Whenever I try to install/upgrade packages I get:
---
pkg-static: wrong architecture: FreeBSD:13:amd64 instead of FreeBSD:12:amd64
pkg-static: repository FreeBSD-base contains packages with wrong ABI: 
FreeBSD:13:amd64

---

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r339898 - head/lib/libc/amd64/sys

[Charlie Li]

On 01/11/2018 15:43, Charlie Li wrote:
> On 01/11/2018 12:04, Brooks Davis wrote:
>> Is this failure with devel/llvm70?  It's currently missing the patch
>> required to make this work.  https://reviews.freebsd.org/D17709 contains
>> this patch among others.  I'll see about getting it applied.
>>
> Yes, devel/llvm70. Will build with your port commit at my next opportunity.
> 
After building world and kernel r340097, kernel runs fine, but every
userspace program in world crashes with Illegal instruction. They all
crash in exactly the same way. Example backtrace from bmake, running
from objdir (first discovered after updating a poudriere jail and
attempting to even start it):

Reading symbols from
/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make...Reading symbols from
/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make.debug...done.
done.
[New LWP 100097]
Core was generated by `/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make
--help'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x002f5664 in _init ()
(gdb) bt
#0  0x002f5664 in _init ()
#1  0x002290fe in _start (ap=, cleanup=) at /usr/src/lib/csu/amd64/crt1.c:66

Given the line number referenced in crt1.c, I'm guessing this condition
may have existed since at least r339351.

-- 
Charlie Li
Can't think of a witty .sigline today…

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)



signature.asc
Description: OpenPGP digital signature

Re: r339929 no audio output to some sound devices with Firefox and some other applications

[Hans Petter Selasky]

On 11/3/18 11:32 AM, Graham Perrin wrote:

 for example:

- audible in Chromium, Falkon and Web
- silent in Firefox, New Moon (Pale Moon) and Waterfox.

HP EliteBook 8570p, integral loudspeakers.

If I recall correctly: yesterday I _did_ get audio from at least one of the 
affected applications, whilst the notebook was docked. A Philips display with 
integral loudspeakers at one of the two DisplayPort sockets at the rear of the 
dock.


Which version of Firefox? Cannot reproduce over here.

Did you check the "mixer" controls, that PCM and Master volume is not zero.

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waterfox: shared object "libicui18n.so.62" not found, required by "libxul.so"

[Jan Beich]

Graham Perrin  writes:

> On 28/10/2018 23:26, Jan Beich wrote:
>
>> … Either rebuild www/waterfox from the last revision before removal …
>
> OK, that worked fine. Essentially:
>
> svn cp svn://svn.freebsd.org/ports/head/www/waterfox@480899 
> /usr/ports/www/waterfox
>
> Vulnerabilities noted (at configure time) and understood.

Why not update? Mk/bsd.gecko.mk hasn't changed incompatibly yet.
1. Drop PORTREVISION line
2. Bump 56.2.3 to 56.2.5
3. Run "make makesum"
4. Run "make all deinstall install clean"

> Prior to that, I experimented briefly with waterfox@480899 copied to
> /usr/local/poudriere/ports/default/www/waterfox
> … wondering whether poudriere might be 'forced' to work with the deleted 
> port. I guess not :-)

Poudriere may not like:
1. MOVED entry i.e., remove waterfox line
2. Lack of waterfox in www/Makefile (only used by "bulk -a")
3. Non-default file permissions (check-sanity)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waterfox: shared object "libicui18n.so.62" not found, required by "libxul.so"

[Graham Perrin]

On 28/10/2018 23:26, Jan Beich wrote:

> … Either rebuild www/waterfox from the last revision before removal …

OK, that worked fine. Essentially:

svn cp svn://svn.freebsd.org/ports/head/www/waterfox@480899 
/usr/ports/www/waterfox

Vulnerabilities noted (at configure time) and understood.



Prior to that, I experimented briefly with waterfox@480899 copied to
/usr/local/poudriere/ports/default/www/waterfox
… wondering whether poudriere might be 'forced' to work with the deleted port. 
I guess not :-)



For reference only, from a few days ago:

root@momh167-gjp4-hpelitebook8570p-freebsd:/usr/ports/www/waterfox # date ; 
uname -v
Tue 30 Oct 2018 07:33:04 GMT
FreeBSD 13.0-CURRENT r339737 GENERIC-NODEBUG
root@momh167-gjp4-hpelitebook8570p-freebsd:/usr/ports/www/waterfox # make 
install clean
===>  Installing for waterfox-56.2.3_2
===>  Checking if waterfox already installed
===>   Registering installation for waterfox-56.2.3_2
Installing waterfox-56.2.3_2...
…
===>  Cleaning for waterfox-56.2.3_2
root@momh167-gjp4-hpelitebook8570p-freebsd:/usr/ports/www/waterfox # exit
logout
[grahamperrin@momh167-gjp4-hpelitebook8570p-freebsd] ~% sh
$ pkg query '%o %v %R' icu waterfox
devel/icu 63.1,1 poudriere
www/waterfox 56.2.3_2 unknown-repository
$ waterfox --safe-mode -p everyday
Fontconfig warning: "/usr/local/etc/fonts/local.conf", line 1093: saw number, 
expected matrix
1540885107127   FirefoxAccounts ERROR   Background refresh of profile failed: 
{"name":"FxAccountsProfileClientError","code":null,"errno":998,"error":"NETWORK_ERROR","message":"[Exception...
 \"NS_ERROR_ABORT\"  nsresult: \"0x80004004 (NS_ERROR_ABORT)\"  location: \"JS 
frame :: resource://services-common/rest.js :: onStopRequest :: line 483\"  
data: no]"}
1540885107127   addons.productaddons    WARN    Failed downloading XML, status: 
0, reason: error
$



Thanks again
Graham
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r339929 no audio output to some sound devices with Firefox and some other applications

[Graham Perrin]

 for example:

- audible in Chromium, Falkon and Web
- silent in Firefox, New Moon (Pale Moon) and Waterfox.

HP EliteBook 8570p, integral loudspeakers.

If I recall correctly: yesterday I _did_ get audio from at least one of the 
affected applications, whilst the notebook was docked. A Philips display with 
integral loudspeakers at one of the two DisplayPort sockets at the rear of the 
dock.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"