Re: Alder lake supported? (graphics)

[Jan Beich]

Chris  writes:

> On 2024-01-16 19:02, Jan Beich wrote:
>
>> Chris  writes:
>> 
>>> I upgraded to an alder lake based machine and installed 14.
>>> But I can't seem to get the intel graphics loaded (drm-515-kmod).
>>> It simply freezes at load.
>>> Are Alder lake graphics supported?
>> Try drm-61-kmod instead (with gpu-firmware-intel-kmod-alderlake >=
>> 20230625).
>> Reported success in
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270888#c8
[...]
> I'm on 14. Commenting that conditional indicates I don't have a necessary
> file (linux/iosys-map.h). So looks like I'll we'll have to wait. Or I'll
> need to track 15. :(

On current@ list -CURRENT is expected. Due to backward compatibility it's
possible to run -CURRENT kernel with -RELEASE userland (world + packages).
For example, poudriere (as used by the package cluster) relies on this
to build binary packages for older FreeBSD versions on the same machine.

Alternatively, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274770#c5
proposed a branch which removes .require_force_probe for both ADL-S and ADL-P.
It builds fine on 14.0-RELEASE "as is" e.g., see ports/ diff below.

diff --git a/graphics/drm-515-kmod/Makefile.version 
b/graphics/drm-515-kmod/Makefile.version
index 4a7c27611bc8..469071220731 100644
--- a/graphics/drm-515-kmod/Makefile.version
+++ b/graphics/drm-515-kmod/Makefile.version
@@ -1,5 +1,5 @@
 # drm-kmod common version definition
 #
 # This will be included from consumers such as nvidia-drm
-DRM_KMOD_DISTVERSION=  5.15.118
-DRM_KMOD_GH_TAGNAME=   drm_v5.15.118_4
+DRM_KMOD_DISTVERSION=  5.15.focal
+DRM_KMOD_GH_TAGNAME=   97a4ad4364
diff --git a/graphics/drm-515-kmod/distinfo b/graphics/drm-515-kmod/distinfo
index 3599fc42317b..cadc6be14456 100644
--- a/graphics/drm-515-kmod/distinfo
+++ b/graphics/drm-515-kmod/distinfo
@@ -1,3 +1,3 @@
-TIMESTAMP = 1703336317
-SHA256 (freebsd-drm-kmod-5.15.118-drm_v5.15.118_4_GH0.tar.gz) = 
58e2fc195979e2361346ca57cc158e44413e5de26b83b951a631d09849caf90c
-SIZE (freebsd-drm-kmod-5.15.118-drm_v5.15.118_4_GH0.tar.gz) = 26092371
+TIMESTAMP = 1698298780
+SHA256 (freebsd-drm-kmod-5.15.focal-97a4ad4364_GH0.tar.gz) = 
fc6a94a74aea714bb25ccf788b8361de4db348ef1893fc391d00bd346e828732
+SIZE (freebsd-drm-kmod-5.15.focal-97a4ad4364_GH0.tar.gz) = 26126042

Re: Alder lake supported? (graphics)

[Jan Beich]

Chris  writes:

> I upgraded to an alder lake based machine and installed 14.
> But I can't seem to get the intel graphics loaded (drm-515-kmod).
> It simply freezes at load.
> Are Alder lake graphics supported?

Try drm-61-kmod instead (with gpu-firmware-intel-kmod-alderlake >= 20230625).
Reported success in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270888#c8

> releng/14.0-n265380-f9716eee8ab4
> 12th Gen Intel(R) Core(TM) i3-1215U
> vgapci0@pci0:0:2:0:   class=0x03 rev=0x0c hdr=0x00 vendor=0x8086
> device=0x46b3 subvendor=0x17aa subdevice=0x3b3a
> vendor = 'Intel Corporation'
> device = 'Alder Lake-UP3 GT1 [UHD Graphics]'
> class  = display
> subclass   = VGA

0x46b3 aka ADL-P is unstable with Linux < 5.17 or in drm-515-kmod.
https://github.com/torvalds/linux/commit/dfb924e33927
https://github.com/freebsd/drm-kmod/commit/3403defd86e5

include/drm/i915_pciids.h contains a list of supported Intel GPUs.
drivers/gpu/drm/i915/i915_pci.c with .require_force_probe contain
a list of unstable GPU generations. Previously, Linux < 5.5 used
alpha_support and Linux < 4.9 used .preliminary_hw_support.

drm-kmod doesn't support hw.i915kms.force_probe (via loader.conf or kenv)
tunable yet thus cannot override .require_force_probe for specific GPUs.
Instead it sets DRM_I915_FORCE_PROBE="*" to enable all unstable support.
https://github.com/freebsd/drm-kmod/commit/054cb0598cab

Re: problem with poudriere && port ftp/curl

[Jan Beich]

Matthias Apitz  writes:

> I have the following problem with poudriere on 14-CURRENT and ports from
> git head: every time when I start poudriere-bulk it removes a port
> already compile fine (and all its dependent ports) with the message:
>
> ...
> [00:00:40] Sanity checking the repository
> [00:00:40] Checking packages for incremental rebuild needs
> [00:00:43] Deleting curl-8.2.1.pkg: changed options
> [00:00:43] Pkg: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG
> -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER -GSSAPI_BASE
> -GSSAPI_HEIMDAL -GSSAPI_MIT +GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6
> -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL
> -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER
> +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD
> [00:00:43] New: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG
> -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER +GSSAPI_BASE
> -GSSAPI_HEIMDAL -GSSAPI_MIT -GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6
> -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL
> -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER
> +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD
>
> The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE.
> I have not set anything about
> this in the port's options or jail's make.conf. 
>
> What can I do to fix this?

Maybe poudriere is confused by GSSAPI_${${SSL_DEFAULT} == base :?BASE :NONE}
in OPTIONS_DEFAULT due ssl!=base in DEFAULT_VERSIONS via make.conf(5).
Try filing a bug against ftp/curl.

$ env -i __MAKE_CONF= PORT_DBDIR=/var/empty make -V '${OPTIONS_DEFAULT:M*GSS*}'
GSSAPI_BASE
$ env -i __MAKE_CONF= PORT_DBDIR=/var/empty DEFAULT_VERSIONS=ssl=openssl make 
-V '${OPTIONS_DEFAULT:M*GSS*}'
GSSAPI_NONE

See also https://cgit.freebsd.org/ports/diff/ftp/curl/Makefile?id=6d324c1f70c9

I can't reproduce on -CURRENT when only using base OpenSSL 3.0.

Re: qt6 the default qt on -current?

[Jan Beich]

Please, use ports@ list next time. Every supported FreeBSD version uses
the same ports/ tree. Not supported FreeBSD versions require a time
machine i.e., rolling back the ports/ tree to a date before EOL.

void  writes:

> How can I build making qt6 the default Qt?

When everything in ports supports Qt6. Once Plasma6 arrives Qt5 may
start to dilapidate and be eventually removed, similar to Qt4.

For comparison, gtk2 can use modern glib but qt5-gui cannot use qt6-core. 

> I'm using poudriere to build. I can see that for some ports there's a
> 'uses: qt6' that goes in the port. What I was looking for was a default
> string I can use with a poudriere make.conf like there is for python or
> perl.

Only select few ports support more than one Qt version. Many use flavors
in order to provide both Qt5 and Qt6 versions as binary packages.

If upstream supports Qt6 but a port doesn't expose it file a bug.

Re: Directory 1002/ missing from /var/run/user/

[Jan Beich]

Graham Perrin  writes:

> What normally takes care of creation of the numbered directories?

/var/run/user/ (or /run/user/ on Linux with systemd) is a common prefix
for XDG_RUNTIME_DIR, a standardized place for user-owned unix(4) sockets.
Fallbacks are either app-specific or shared (e.g., CVE-2020-25697).

/var/run/user/ is managed by sysutils/consolekit2 or sysutils/pam_xdg.
In consolekit2 case the directory is created (contents destroyed if
already exists) on the first session of the specific UID either via
C API, DBus API, ck-launch-session(1) or pam_ck_connector(8) and removed
when the last session terminates. In pam_xdg case the directory is
created but not removed unless track_sessions is set.

> A few hours ago, it was unexpectedly missing:

Probably auto-removed by consolekit2 either due to logout or dbus restart.

> I recreated the directory.

Can be automated via PAM e.g.,

  # pkg install consolekit2
  # echo "session optional pam_ck_connector.so nox11" >>/etc/pam.d/system
  # service dbus onestart
  $ exit # log out on VT console to re-trigger PAM

or

  # pkg install pam_xdg
  # echo "session optional pam_xdg.so notroot runtime" >>/etc/pam.d/system
  $ exit # log out on VT console to re-trigger PAM

Re: photo/video on tty console with the new VT/framebuffer

[Jan Beich]

Alastair Hogge  writes:

> On 2023-05-19 11:04, Ivan Quitschal wrote:
>
>> Hi all
>> 
>> i have a question. searched everywhere and found nothing about.
>> 
>> Is it possible to visualize photos on tty console like we used to on old 
>> SYSCONS by using zgv or something?

See https://github.com/mpv-player/mpv/issues/7983

>> Or watching videos with mpv/mplayer + sdl 2.0/openGL or something?
>
> As long as those packages support DRMKMS and does your GPU, you can to a
> degree. I noticed video works for mpv and games/sdl, tho, I cannot get
> input working. I tried the Doom 3 port, and watched movies with mpv all
> from the vty just a couple of months ago.

mpv doesn't call KDSKBMODE ioctl, so input remains under VT control but
not visible due to video showing on top. One can still control mpv via
stdin(4) using a keyboard but keybindings would be limited by termios(4).
For example, Ctrl+S would pause playback after a few seconds instead of
taking a screenshot.

SDL2 probably has a bug. SDL1 uses vgl(3) instead of KDSKBMODE directly.

Re: What llvm16 libc++ updates for -std=c++20 use [was: Re: Delay in 14.0-RELEASE cycle and blocking items]

[Jan Beich]

Mark Millard  writes:

> Alexey Dokuchaev  wrote on
> Date: Wed, 03 May 2023 07:53:09 UTC :
>
>> On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote:
>> > ...
>> > There is no feasible way we are going to make the branch point of
>> > stable/14 in time, with that scheduled for May 12, 2023 with the above
>> > points. That said, this is not an all-inclusive list, but the more
>> > major items on our radar at the moment.
>> 
>> Does this delay mean we might get Clang 16 in the base? Current 15.0.7
>> hits assertion on one of my ports which had allegedly been fixed in 16.
>> Also, AFAIU it comes with better support for modern C++, e.g. ranges.
>
> These notes are based on using -std=c++20 and llvm16 on
> opensuse tumblweed (in early April), which has libc++
> support configurable. They also presume that the FreeBSD
> llvm16 update fully adopts the libc++ from llvm16.
> (FreeBSD LLVM upgrades do not always do so at the initial
> upgrade time.)

FWIW, std::ranges in base libc++ 16 (via llvm-16-update branch) works
fine at least in emulators/yuzu (c++20) and x11-wm/hyprland (c++23).
More can take advantage but currently use a workaround e.g.,

$ rg -l :devel/range-v3 | sed s,/Makefile,,
biology/seqan3
devel/fbthrift
editors/imhex
lang/solidity
net-im/telegram-desktop

Re: Problem in userland

[Jan Beich]

Filippo Moretti  writes:

> Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot access 
> /sys/bus/pci (t=3.60308) [GFX1-]: glxtest: cannot access /sys/bus/pci

Regressed by https://bugzilla.mozilla.org/show_bug.cgi?id=1696691
but only impacts https://bugzilla.mozilla.org/show_bug.cgi?id=1676883

This may affect whether some GPU features are enabled by default based
on vendor_id + device_id allow-list. Nothing more.

Re: Did clang 14 lose some intrinsics support?

[Jan Beich]

Christian Weisgerber  writes:

> Did we lose support for SSSE3 and AVX2 intrinsics on amd64 with
> clang 14?

__builtin_* appear unstable unlike _mm* intrinsics. Clang 15 seems
to hide more but I'm not sure about the cause (need bisecting).

===> clang version 15.0.1
#define SSE2_SUPPORTED 1
#define SSE_SUPPORTED 1

===> clang version 15.0.1 with -march=native
#define AVX_SUPPORTED 1
#define FMA_SUPPORTED 1
#define SSE2_SUPPORTED 1
#define SSE4_1_SUPPORTED 1
#define SSE_SUPPORTED 1

> #if __has_builtin(__builtin_ia32_pabsd128)
>   #define SSSE3_SUPPORTED 1
> #endif
[...]
> #if __has_builtin(__builtin_ia32_pabsd256)
>   #define AVX2_SUPPORTED 1
> #endif

See https://github.com/llvm/llvm-project/commit/e5147f82e1cb

- Instead of __builtin_ia32_pabsd128 maybe use _mm_abs_epi32
- Instead of __builtin_ia32_pabsd256 maybe use _mm256_abs_epi32

Re: 13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call

[Jan Beich]

FreeBSD User  writes:

> After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd: Thu 
> Oct 14
> 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and also 
> updating port
> graphics/drm-fbsd13-kmod to drm-fbsd13-kmod-5.4.144.g20211013, 
> graphics/libdrm to
> libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes now with the following 
> message:

Which revision "13-STABLE" was before the update? If you didn't change
any kernel options (and bump into a pilot error) bisecting may help.

>
> [~] firefox
> Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with
> reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad system
> callgraphics/libdrm.

Run under truss(1) or ktrace(1) (enable tracing descendants) to get the
syscall name or number. For example, Firefox requires CAPABILITIES for
cap_rights_{limit,init} and COMPAT_FREEBSD11 [1] for pre-ino64 via Rust.

[1] https://github.com/rust-lang/libc/pull/2406

Re: latest current fails to boot.

[Jan Beich]

Tomoaki AOKI  writes:

> On Wed, 22 Sep 2021 05:47:46 -0700
> David Wolfskill  wrote:
>
>> On Wed, Sep 22, 2021 at 02:39:37PM +0200, Johan Hendriks wrote:
>> > I did a git pull this morning and it fails to boot.
>> > I hangs at Setting hostid : 0x917bf354
>> > 
>> > This is a vm running on vmware.
>> > If i boot the old kernel from yesterday it boots normally.
>> > 
>> > uname -a
>> > FreeBSD varnish-cdn-node03 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
>> > main-n249518-5572fda3a2f: Tue Sep 21 14:40:22 CEST 2021 
>> > root@varnish-cdn-node03:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64
>> > 
>> 
>> I had no issues with my build machine or either of two laptops, either
>> from yesterday:
>> 
>> FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #358
>> main-n249518-5572fda3a2f3: Tue Sep 21 05:15:22 PDT 2021
>> r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
>> amd64 1400033 1400033
>> 
>> or today:
>> 
>> FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #359
>> main-n249556-c96da1994587: Wed Sep 22 04:24:17 PDT 2021
>> r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
>> amd64 1400033 1400033
>> 
>> [uname strings from my main laptop shown, but I keep the machines
>> in sync rather aggressively.]
>> 
>> Perhaps the issue you are encountering involves things not in my
>> environment (such as VMs or ZFS)?
>> 
>> Peace,
>> david
>> -- 
>> David H. Wolfskill  da...@catwhisker.org
>> Life is not intended to be a zero-sum game.
>> 
>> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>
> For me, on bare metal (non-vm) amd64 with root-on-ZFS,
>
>   Fails to boot to multiuser at git: 8db1669959ce
>   Boot fine at git: 0b79a76f8487
>
> Boot to singleuser is fine even with failed revision.
>
> Failure mode:
>  Hard hangup or spinning and non-operable. Hard power-off needed.
>  Seems to happen after starting rc.conf processing and before setting
>  hostid.

Does "git revert --no-edit -2 8db1669959ce" help? Do you modify
kern.sched.* via /etc/sysctl.conf?

Re: [HEADSUP] making /bin/sh the default shell for root

[Jan Beich]

Jan Beich  writes:

> grarpamp  writes:
>
>> BSD community can definitely volunteer to make benchmark of
>> its shell vs others, determine if and where improvements to make.
>> Many apps never get checked for obvious speedups,
>> if so it might become fastest shell even with the new features.
>
> Like https://github.com/shellspec/shellbench ?
> I did check a month ago (on 2021-08-31) but forgot NetBSD sh(1).
> Obviously, the results may vary per OS/version/architecture/hardware.

Nevemind. I've tested inside jail (probably 12.2 amd64) instead of -CURRENT.

Re: [HEADSUP] making /bin/sh the default shell for root

[Jan Beich]

grarpamp  writes:

> BSD community can definitely volunteer to make benchmark of
> its shell vs others, determine if and where improvements to make.
> Many apps never get checked for obvious speedups,
> if so it might become fastest shell even with the new features.

Like https://github.com/shellspec/shellbench ?
I did check a month ago (on 2021-08-31) but forgot NetBSD sh(1).
Obviously, the results may vary per OS/version/architecture/hardware.

$ ./shellbench -s sh,dash,busybox/sh,bash,zsh,oksh,ksh93,yash sample/*.sh
--
name   sh   dash busybox/sh   bash  
  zsh   oksh  ksh93   yash
--
assign.sh: positional params1,983,164747,830666,979443,083
551,071875,915479,129395,225
assign.sh: variable 2,405,745827,904741,112616,017  
1,308,457  1,013,153588,698510,636
assign.sh: local var2,398,554834,027747,871603,486  
1,293,027  1,007,511  error503,410
assign.sh: local var (typeset)  error  error  error616,483  
1,306,641  1,011,383544,136504,782
cmp.sh: [ ] 1,628,216567,700465,761352,438
336,288713,738518,768297,987
cmp.sh: [[ ]]   error  error  error480,974
595,441903,502613,269376,550
cmp.sh: case2,527,633  1,196,339  1,024,253606,588
632,811959,232628,183450,893
count.sh: posix 1,640,683717,178589,330463,934
907,140700,233376,361398,937
count.sh: typeset -ierror  error  error452,029
907,541652,885385,585  error
count.sh: increment error  error  error581,631  
1,264,962845,738581,111  error
eval.sh: direct assign  1,670,797564,299518,082308,709
198,714722,050285,150279,020
eval.sh: eval assign1,102,774393,161332,925194,636
156,834476,164173,156192,191
eval.sh: command subs   2,188  5,828  4,830  2,208  
1,597  5,015  ?  4,302
func.sh: no func2,451,641836,115756,258614,579
711,116  1,087,770571,210507,644
func.sh: func   1,947,254596,731542,519349,748
187,903845,681306,506313,989
null.sh: blank  3,094,116  error  error  error  
1,529,326  1,304,367  error593,711
null.sh: assign variable2,419,811845,676751,887669,694  
1,374,858  1,012,724599,490533,401
null.sh: define function2,687,933  1,259,149  1,076,947661,432  
1,270,777  1,085,654584,490525,184
null.sh: undefined variable 2,445,429839,334750,904505,147
631,862  1,048,805473,900501,851
null.sh: : command  2,418,617839,744742,385610,307
701,972  1,064,089565,323500,879
output.sh: echo 1,518,368669,539620,417404,729
544,030781,488540,064380,174
output.sh: printf   1,481,745632,454535,170395,649
534,303  1,556258,827365,724
output.sh: printerror  error  error  error
542,740775,812353,320  error
subshell.sh: no subshell2,330,179819,359729,753571,353
705,892  1,005,262560,780485,498
subshell.sh: brace  2,343,747833,142728,803554,948
568,470984,156557,069413,438
subshell.sh: subshell   3,444  6,917  2,814  1,190  
3,578  3,391240,738  2,570
subshell.sh: command subs   1,871,462  3,806  5,966  2,766  
2,709  4,564146,388  3,691
subshell.sh: external command   1,112996579893  
2,190  2,529  1,728  1,778
--
* count: number of executions per second

Re: pkg for 14-current

[Jan Beich]

Yasuhiro Kimura  writes:

G> From: Masachika ISHIZUKA 
> Subject: pkg for 14-current
> Date: Sun, 24 Jan 2021 19:11:28 +0900 (JST)
>
>>   Hi.
>> 
>>   I updated to 14-current from 13-current and reinstalled ports-mgmt/pkg.
>>   I cannot get meta files for 14-current.
>>   How can I use pkg on 14-current ?
>>   
>>> # pkg update
>>> Updating FreeBSD repository catalogue...
>>> pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/meta.txz: Not 
>>> Found
>>> repository FreeBSD has no meta file, using default settings
>>> pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/packagesite.txz: 
>>> Not Found
>>> Unable to update repository FreeBSD
>>> Error updating repositories!
>
> All what you can do is to wait until build of offical packages for
> 14-CURRENT has completed unless you build them by yourself.

Or temporarily redefine ABI as a workaround e.g.,

  $ env ABI=FreeBSD:13:amd64 pkg install chromium
___
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: referencing one commit in another for git

[Jan Beich]

Warner Losh  writes:

> On Wed, Dec 23, 2020, 3:21 PM Alan Somers  wrote:
>
>> On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem  wrote:
>>
>> > Hi,
>> >
>> > So I just did my first git commit. Pretty scary, but it looks ok.
>> >
>> > Now, how do I reference one commit in another related
>> > commit's log?
>> >
>> > By the long winded hash or ??
>> >
>> > I'm not sure if I should ask here or on the git mailing list,
>> > but I figured this isn't a technical git question...
>> >
>> > Thanks for any help with this, rick
>> >
>>
>> Yeah, you should use the full hash.  For temporary references, like during
>> a code review, you can use the first "several" digits of the hash.   For a
>> project of FreeBSD's size, "several" is probably 11-13.  But in permanent
>> contexts, like commit logs, you should use the full hash.  When somebody
>> views the commit on a platform like Github, Github will automatically turn
>> it into a hyperlink, and display only the first "several" digits.
>>
>
>
> For MFCs we are recommending the first 11. I think this will likely suffice
> and matches the git client behavior.

Mercurial defaults to 12 digit abbreviation. Git abbreviates linux,
freebsd-legacy, freebsd-ports repos on GitHub to 12 digit.
___
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: review request: loader: implement framebuffer console

[Jan Beich]

Jan Beich  writes:

> Toomas Soome  writes:
>
>> hi!
>>
>> I have been working on proper framebuffer support on FreeBSD loader
>> and there is the current state: https://reviews.freebsd.org/D27420
>> <https://reviews.freebsd.org/D27420>
>>
>> All feedback is welcome, and especially if you can spare some time for 
>> testing:)
>
> Do you have another source? Phabricator excludes some files e.g.,
>
>   $ fetch 'https://reviews.freebsd.org/D27420?download=true' | patch -Efsp0
>   $ make -sj8 buildworld
>   [...]
>   ===> stand/images (all)
>   make[4]: make[4]: don't know how to make freebsd-brand-rev.png. Stop

FWIW, I've tried CLI but no joy:

  $ svn status
  $ pkg install arcanist-php80
  $ arc patch D27420
  PHP Deprecated:  Function libxml_disable_entity_loader() is deprecated in 
/usr/local/lib/php/arcanist/support/init/init-script.php on line 92

  Deprecated: Function libxml_disable_entity_loader() is deprecated in 
/usr/local/lib/php/arcanist/support/init/init-script.php on line 92
  [2020-12-14 13:42:12] EXCEPTION: (Exception) Error while loading file 
"/usr/local/lib/php/arcanist/src/workflow/ArcanistWorkflow.php": Private 
methods cannot be final as they are never overridden by other classes at 
[/src/init/lib/PhutilBootloader.php:275]
  arcanist()
#0 PhutilBootloader::executeInclude(string) called at 
[/src/init/lib/PhutilBootloader.php:207]
#1 PhutilBootloader::loadLibrarySource(string, string) called at 
[/src/symbols/PhutilSymbolLoader.php:422]
#2 PhutilSymbolLoader::loadSymbol(array) called at 
[/src/symbols/PhutilSymbolLoader.php:277]
#3 PhutilSymbolLoader::selectAndLoadSymbols() called at 
[/src/init/init-library.php:23]
#4 __phutil_autoload(string)
#5 class_exists(string) called at 
[/src/symbols/PhutilClassMapQuery.php:216]
#6 PhutilClassMapQuery::loadMap() called at 
[/src/symbols/PhutilClassMapQuery.php:184]
#7 PhutilClassMapQuery::execute() called at 
[/src/runtime/ArcanistRuntime.php:535]
#8 ArcanistRuntime::newWorkflows(ArcanistArcToolset) called at 
[/src/runtime/ArcanistRuntime.php:115]
#9 ArcanistRuntime::executeCore(array) called at 
[/src/runtime/ArcanistRuntime.php:37]
#10 ArcanistRuntime::execute(array) called at 
[/support/init/init-arcanist.php:6]
#11 require_once(string) called at [/bin/arc:10]

  $ svn status
  $ pkg install arcanist-php74
  $ arc patch D27420
  [...]
  A  (bin)  stand/images/freebsd-logo-rev.png
  A  (bin)  stand/images/freebsd-brand.png
  A  (bin)  stand/images/freebsd-brand-rev.png
  A stand/images/Makefile
  svn: warning: W150002: 'stand/images' is already under version control
  svn: E29: Could not add all targets because some targets are already 
versioned
  svn: E29: Illegal target for the requested operation
  A stand/i386/libi386/vbe.h
  A stand/i386/libi386/vbe.c
  A stand/fonts/Makefile
  A stand/fonts/INDEX.fonts
  svn: warning: W150002: 'stand/fonts' is already under version control
  svn: E29: Could not add all targets because some targets are already 
versioned
  svn: E29: Illegal target for the requested operation
  A stand/common/gfx_fb.h
  A stand/common/gfx_fb.c
  A contrib/terminus/ter-u32n.bdf
  A contrib/terminus/ter-u32b.bdf
  A contrib/terminus/ter-u28n.bdf
  A contrib/terminus/ter-u28b.bdf
  A contrib/terminus/ter-u24n.bdf
  A contrib/terminus/ter-u24b.bdf
  A contrib/terminus/ter-u22n.bdf
  A contrib/terminus/ter-u22b.bdf
  A contrib/terminus/ter-u20n.bdf
  A contrib/terminus/ter-u20b.bdf
  A contrib/terminus/ter-u18n.bdf
  A contrib/terminus/ter-u18b.bdf
  A contrib/terminus/ter-u16v.bdf
  A contrib/terminus/ter-u16n.bdf
  A contrib/terminus/ter-u16b.bdf
  A contrib/terminus/ter-u14v.bdf
  A contrib/terminus/ter-u14n.bdf
  A contrib/terminus/ter-u14b.bdf
  A contrib/terminus/ter-u12n.bdf
  A contrib/terminus/ter-u12b.bdf
  svn: warning: W150002: 'contrib/terminus' is already under version control
  svn: E29: Could not add all targets because some targets are already 
versioned
  svn: E29: Illegal target for the requested operation
  A contrib/pnglite/pnglite.h
  A contrib/pnglite/pnglite.c
  A contrib/pnglite/README.md
  A contrib/pnglite/LICENSE
  svn: warning: W150002: 'contrib/pnglite' is already under version control
  svn: E29: Could not add all targets because some targets are already 
versioned
  svn: E29: Illegal target for the requested operation
  svn: E125004: MIME type 'application/octet-stream
  \ No newline at end of property' contains invalid character '
  ' in media type
  svn: E125004: MIME type 'applicatio

Re: review request: loader: implement framebuffer console

[Jan Beich]

Toomas Soome  writes:

> hi!
>
> I have been working on proper framebuffer support on FreeBSD loader
> and there is the current state: https://reviews.freebsd.org/D27420
> 
>
> All feedback is welcome, and especially if you can spare some time for 
> testing:)

Do you have another source? Phabricator excludes some files e.g.,

  $ fetch 'https://reviews.freebsd.org/D27420?download=true' | patch -Efsp0
  $ make -sj8 buildworld
  [...]
  ===> stand/images (all)
  make[4]: make[4]: don't know how to make freebsd-brand-rev.png. Stop
___
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: uefi(8) fails to boot from ZFS with compression=zstd

[Jan Beich]

Toomas Soome  writes:

>
>> On 23. Oct 2020, at 05:02, Jan Beich  wrote:
>> 
>> After r366657 (currently, on r366953) I've tried to boot from a
>> compression=zstd dataset but it failed to reach loader(8), see below.
>> However, switching to CSM path (boot1.efi -> gptzfsboot) makes it work.
>> 
>> Am I missing something?
[...]
> Does it boot when you copy loader.efi to bootx64.efi?

Yes, skipping boot1.efi works fine. Luckily, my gptzfsboot + loader.efi
still fit into 1Mb I've reserved for boot partitions.

$ gpart show nda0
=>40  1000215136  nda0  GPT  (477G)
  40 320 1  freebsd-boot  (160K)
 3601688 2  efi  (844K)
2048  1000213120 3  freebsd-zfs  (477G)
  1000215168   8- free -  (4.0K)

$ sh /usr/share/examples/bhyve/vmrun.sh -ATE -d /dev/nda0 -d /dev/nda1 
host-freebsd
Launching virtual machine "host-freebsd" ...
fbuf frame buffer base: 0x82780 [sz 16777216]
Consoles: EFI console
Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk0p2:
FreeBSD/amd64 EFI loader, Revision 1.1
(Thu Oct 22 23:48:55 UTC 2020 foo@bar)

   Command line arguments: loader.efi
   Image base: 0x1e907000
   EFI version: 2.40
   EFI Firmware: BHYVE (rev 1.00)
   Console: efi (0x20001000)
   Load Path: \EFI\BOOT\BOOTX64.EFI
   Load Device: 
PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0)/HD(2,GPT,,0x168,0x698)
   BootCurrent: 
   BootOrder: [*] 0001 0002 0003
   BootInfo Path: PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0)
Ignoring Boot: Only one DP found
Trying ESP: 
PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0)/HD(2,GPT,,0x168,0x698)
Setting currdev to disk0p2:
Trying: 
PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0)/HD(1,GPT,,0x28,0x140)
Setting currdev to disk0p1:
Trying: 
PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0)/HD(3,GPT,,0x800,0x3B9E0A80)
Setting currdev to zfs:tank/ROOT/freebsd-zstd:
Loading /boot/defaults/loader.conf
Loading /boot/defaults/loader.conf
Loading /boot/device.hints
Loading /boot/loader.conf
Loading /boot/loader.conf.local
/
-  __      _ _
  |  | |  _ \ / |  __ \
  | |___ _ __ ___  ___ | |_) | (___ | |  | |
  |  ___| '__/ _ \/ _ \|  _ < \___ \| |  | |
  | |   | | |  __/  __/| |_) |) | |__| |
  | |   | | |||| |  |  |
  |_|   |_|  \___|\___||/|_/|_/
 ````
 ┌───Welcome to FreeBSD┐s` `.---...--.```   -/
 │ │+o   .--` /y:`  +.
 │  1. Boot Multi user [Enter] │ yo`:.:o  `+-
 │  2. Boot Single user│  y/   -/`   -o/
 │  3. Escape to loader prompt │ .-  ::/sy+:.
 │  4. Reboot  │ / `--  /
 │  5. Cons: Dual (Serial primary) │`:  :`
 │ │`:  :`
 │  Options:   │ /  /
 │  6. Kernel: default/kernel (1 of 2) │ .--.
 │  7. Boot Options│  --  -.
 │  8. Boot Environments   │   `:`  `:`
 │ │ .-- `--.
 └─┘.---..


Loading kernel...
/boot/kernel/kernel text=0x10c7c8 text=0x99a088 text=0x1a75e4 data=0x140 
data=0x131aa4+0x4cd55c syms=[0x8+0x10f4d0+0x8+0x112349]
Loading configured modules...
/boot/firmware/intel-ucode.bin size=0x303800
/etc/hostid size=0x25
/boot/entropy size=0x1000
/boot/kernel/ichwd.ko size 0x8558 at 0x1b27000
Start @ 0x8030d000 ...
EFI framebuffer information:
addr, size 0xc100, 0x100
dimensions 1024 x 768
stride 1024
masks  0x00ff, 0xff00, 0x00ff, 0xff00
___
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"

uefi(8) fails to boot from ZFS with compression=zstd

[Jan Beich]

After r366657 (currently, on r366953) I've tried to boot from a
compression=zstd dataset but it failed to reach loader(8), see below.
However, switching to CSM path (boot1.efi -> gptzfsboot) makes it work.

Am I missing something?

$ strings /boot/boot1.efi | fgrep zstd
org.freebsd:zstd_compress

$ strings /boot/gptzfsboot | fgrep zstd
zstd
/usr/src/sys/contrib/openzfs/module/zstd/zfs_zstd.c
org.freebsd:zstd_compress

$ zpool set bootfs=tank/ROOT/freebsd-zstd tank
$ sh /usr/share/examples/bhyve/vmrun.sh -ATE -d /dev/nda0 -d /dev/nda1 
host-freebsd
Launching virtual machine "host-freebsd" ...
fbuf frame buffer base: 0x82780 [sz 16777216]

>> FreeBSD EFI boot block
   Loader path: /boot/loader.efi

   Initializing modules: ZFS UFS
   Load Path: \EFI\BOOT\BOOTX64.EFI
   Load Device: 
PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0)/HD(2,GPT,,0x250,0x5B0)
   BootCurrent: 
   BootOrder: [*] 0001 0002 0003
   Probing 8 block devices...not supported
not supported
not supported
better
not supported
not supported
not supported
good
 done
ZFS found the following pools: tank
UFS found no partitions
ZFS: unsupported compression algorithm (null)
ZFS: i/o error - all block copies unavailable
Failed to read node from tank (5)
ZFS: unsupported compression algorithm (null)
ZFS: i/o error - all block copies unavailable
Failed to read node from tank (5)
Failed to load '/boot/loader.efi'
panic: No bootable partitions found!
Boot Failed. EFI Hard Drive
...
___
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: DRM Project report (week of August 10)

[Jan Beich]

Emmanuel Vadot  writes:

>  Hello,
>
>  5.4 was finilly reached !
>  For AMD users it means that Navi12/14, Arctarus and Renoir should work.
>  For Intel users it means that TigerLake should work too.
>
>  No ports update for now as I want to give current users a bit of time
> to update their base (as the ports needs recent addition to
> base linuxkpi) but if you have a current >= 364233 you can test
> directly the master branch of https://github.com/freebsd/drm-kmod/
>
>  I plan to commit the port update at the end of the week, and probably
> at the end of the month we will switch drm-current-kmod to 5.4.
>
>  It's now time to do 2 main things :
>  - Update stable/12 so it have all the needed code to run 5.4
>  - Remove the remaining GPLv2 code to start thinking of import into
> base.

Upstream v5.4 was tagged on 2019-11-24. Did you check linux-5.4.y (LTS)
doesn't require more LinuxKPI changes? For example, when drm-v5.0 was
the latest I've played with grafting linux-4.19.y only to discover
some commits had to be reverted due to missing LinuxKPI bits.
___
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: Working on Zoom port

[Jan Beich]

Alexandr Krivulya  writes:

> 13.04.20 19:59, Жилин, Михаил Сергеевич пишет:
>
>> Hi,
>>
>> Does the latest Firefox support audio in Zoom? It's really the only
>> pain point of Firefox + Zoom on FreeBSD.
>> I'm forced to use it every day, so Web client is cool except for
>> audio issue on Firefox.
>>
>
> According to [1] latest firefox nightly builds now support audio in
> zoom. This nightly builds are not available for FreeBSD but you can
> try to build it from sources.
>
> [1]
> https://www.reddit.com/r/firefox/comments/fsz3rk/implementation_of_the_audioworklets_makes_firefox/

If that Nightly means 76 then see bug 245422 for downstream version.
Unfortunately, it doesn't build yet due to a bug in Clang or Rust.
___
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: Firefox and Cliqz tabs crashing at GOV.UK government pages

[Jan Beich]

Graham Perrin  writes:

> On 08/04/2020 20:23, Graham Perrin wrote:
>
>> Firefox 75.0_1,1 tabs crashing or mis-rendering at some www.gov.uk pages
>>
>> Most noticeable today at
>   . Screenshots available on request.
>>
>> AFAICT the same types of problem with 75.0_1,1 on both r357746 and
>   r359628.
>
> The problem persists with r359750, is reproducible with a different
> user account, is reproducible with Cliqz browser. As far as I can
> tell, only bugging UK.GOV government pages.

I could reproduce on Nightly, so have reported upstream.
https://bugzilla.mozilla.org/show_bug.cgi?id=1629231

> Occasionally a page will appear OK (e.g. the screen to the left at
> ), more often the page will appear 
> wrong (screen to the right, safe mode).

According to backtrace the crash happens in harfbuzz code which is
responsible how text is shaped. If it doesn't crash right away then
scrolling the page usually helps to trigger.

> Most often: the tab will crash before the screen can be read. Crashes
> seem to occur at load time, towards the tail end of content loading or 
> rendering.
>
> More shots of what appears to be mis-rendering, Firefox with a
> refreshed profile in safe mode:
>
> 
> 

Maybe report your findings on upstream bug.

>
> I have .core files from both Firefox and Cliqz, should I report a bug?
>
> (Also I'd like to take this opportunity to learn how to interpret
> parts of a .core file, I'll do what I can with man pages but might
> need to seek help in IRC.)

Try "lldb --core firefox.*.core /usr/local/bin/firefox" then run "bt all"
from (lldb) prompt. core(5) files are not portable across environments,
so after getting some basic info discard the files because they'd
quickly become unusable after rebuilding www/firefox or any of its
library dependencies.
___
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: USB microphones with FreeBSD-CURRENT

[Jan Beich]

Graham Perrin  writes:

> I can't get web browsers to recognise USB microphones.
>
> USB output (e.g. to my headphones) is OK.
>
> USB input (e.g. from the microphone part of the headphones) is not.
>
> Any suggestions?

Firefox uses "pulse-rust" cubeb backend *by default* if "pulseaudio"
package is installed. getUserMedia is supposed to preset a dropdown menu
to select a microphone. Make sure pulseaudio actually recognizes the
desired microphone e.g., debug via "pactl list" and "parec".

I don't have a mic but, looking at the code, only pulse-rust or pulse
backends on Linux/FreeBSD support selecting non-default audio device.
It maybe possible to use other backends but if audio device used for
output and input are different that'd require routing defaults which can
be done via config file (e.g., ~/.asoundrc) or externally via virtual_oss.

> pcm3:  (play/rec) default
> pcm4:  (rec)

Are these distinct physical devices?

> hw.snd.default_unit: 3

Have you tried using 4?
___
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: Firefox: recommendations – Pocket

[Jan Beich]

Graham Perrin  writes:

> For a few months I got recommendations from Pocket.
>
> No longer.

Check browser.newtabpage.activity-stream.feeds.section.topstories in 
about:config
I have no clue how it's enabled by default on Tier1 platforms.

> Is the code removed? Or has Mozilla become stricter about enforcing
> regional restrictions?

No clue. Wrong list. gecko@ doesn't touch Pocket code/prefs.

> (I'm in the UK.)

VPN or did you define the following?

  pref("browser.search.region", "US");
  pref("browser.search.countryCode", "US");
___
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: The X11 with amdgpu fault

[Jan Beich]

"mms.vanbreukelin...@gmail.com"  writes:

> The output of the /var/Xorg.log is:
>
> xf86EnableIO: failed to open /dev/io for Extended I/O

Did you build x11-servers/xorg-server with SUID option enabled?
For one, /dev/io cannot be opened by anyone but root even after
adjusting file permissions.
https://github.com/freebsd/freebsd/blob/releng/12.0/sys/dev/io/iodev.c#L73
___
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: Boot loader hangs after update to r349350

[Jan Beich]

Vladimir Zakharov  writes:

> Hello
>
> After update from r349326 to r349350 boot loader hangs on string:
> Setting currdev to ada0p3:
>
> Laptop HP ProBook 430 G3.

Do you boot from a ZFS pool on a GPT partition? If so how the pool is
configured: single disk, stripe, mirror or raidz?

Try reverting r349349.
___
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: CTF: UEFI HTTP boot support

[Jan Beich]

Rebecca Cran  writes:

> I've been working with D Scott Phillips to test the UEFI HTTP loader
> code he's written, and we're now ready for wider testing.
[...]

I can't boot after r349349. loader.efi appears to fail to load. As my
boot pool is striped maybe HTTP code interferes with ZFS code assembling
bits from multiple disks. Any ideas how to debug?

Note, UEFI Network Stack is disabled and UEFI Hard Disk is #1 boot option.

  >> FreeBSD EFI boot block
 Loader path: /boot/loader.efi

 Initializing modules: ZFS UFS
 Load Path: \EFI\BOOT\BOOTX64.EFI
 LoadDevice: PciRoot(0x0)/Pci(0x1B,0x0)/Pci(0x0,0x0)/Unit(0x1)/HD(2,GPT,...)
 BootCurrent: 0004
 BootOrder: 0004 0005 0006 0007
 Probing 20 block devices..+.*+. done
  ZFS found the following pools: foo bar
  UFS found no partitions
  command args: -DS115200

  Consoles: EFI console
  Reading loader env vars from /efi/freebsd/loader.env
  Setting currdev to disk1p3:
  \
___
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: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)

[Jan Beich]

Jakub Lach  writes:

> Hello, 
>
> I'm on FreeBSD 12.0-STABLE #0 r344261 amd64.
>
> I've rebuilt all ports after clang 7 import to 12-STABLE.
>
> Now I get with mplayer 
>
> ld-elf.so.1: /lib/libc.so.7: Undefined symbol "__progname"

https://svnweb.freebsd.org/changeset/ports/490727 needs to be adjusted
for -STABLE as well.

Details are in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103
___
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: kdelibs-kde4 is marked as broken on FreeBSD 13.0: incompatible with base SSL ...

[Jan Beich]

g...@unixarea.de writes:

> Hello,
>
> I know that KDE4 will be removed from ports by the end of the year,
> that's why I wanted to update my CURRENT and ports right now before
> this. I now find that one of the fundamental ports (x11/kdelibs-kde4) is
> marked as broken...
>
> Is there a fix for this (for example using SSL from ports and not from
> base). The alternative would be reset my poudriere oven to a 19 of
> September (my last build with KDE4).

Try adding DEFAULT_VERSIONS+=ssl=openssl to make.conf(5) and commenting
out BROKEN_FreeBSD_13 in kdelibs-kde4/Makefile.
___
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: [regression] drm-stable-kmod doesn't work in i386 jail on amd64 host

[Jan Beich]

Jan Beich  writes:

> Jan Beich  writes:
>
>> I often test Firefox on 10.4 i386 and sometimes play games via Wine.
>> Both require working OpenGL for COMPAT_FREEBSD32. My GPU is Skylake
>> which worked fine a few weegs ago i.e., before r338990.
>>
>> Any clue?
>
> I've opened https://github.com/FreeBSDDesktop/kms-drm/issues/99 but so
> far no response. Would a sample would help?
>
> $ pciconf -l | fgrep 0:0:2:0
> vgapci1@pci0:0:2:0: class=0x03 card=0x79681462 chip=0x19128086 
> rev=0x06 hdr=0x00
> $ /poudriere/jails/112i386/usr/sbin/pciconf -l
> pciconf: ioctl(PCIOCGETCONF): Operation not permitted
>
> $ ./test 0 0 2 0
> vendor=0x8086, device=0x1912, subvendor=0x1462, subdevice=0x7968, revid=0x6
> $ ./test32 0 0 2 0
> test32: PCIOCGETCONF failed: Operation not permitted
> $ sudo ./test32 0 0 2 0
> test32: PCIOCGETCONF failed: Operation not permitted

For posterity, 12.0-RC2 should have the fix:
https://svnweb.freebsd.org/changeset/base/340657

If someone is on Reddit maybe they can inform the following user
https://www.reddit.com/r/freebsd/comments/9yllxo/not_getting_hardware_acceleration_with/
___
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: [regression] drm-stable-kmod doesn't work in i386 jail on amd64 host

[Jan Beich]

Jan Beich  writes:

> I often test Firefox on 10.4 i386 and sometimes play games via Wine.
> Both require working OpenGL for COMPAT_FREEBSD32. My GPU is Skylake
> which worked fine a few weegs ago i.e., before r338990.
>
> Any clue?

I've opened https://github.com/FreeBSDDesktop/kms-drm/issues/99 but so
far no response. Would a sample would help?

$ cc -o test test.c
$ cc -m32 -o test32 test.c

$ pciconf -l | fgrep 0:0:2:0
vgapci1@pci0:0:2:0: class=0x03 card=0x79681462 chip=0x19128086 rev=0x06 
hdr=0x00
$ /poudriere/jails/112i386/usr/sbin/pciconf -l
pciconf: ioctl(PCIOCGETCONF): Operation not permitted

$ ./test 0 0 2 0
vendor=0x8086, device=0x1912, subvendor=0x1462, subdevice=0x7968, revid=0x6
$ ./test32 0 0 2 0
test32: PCIOCGETCONF failed: Operation not permitted
$ sudo ./test32 0 0 2 0
test32: PCIOCGETCONF failed: Operation not permitted

$ cat test.c
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
/* Based on drmParsePciDeviceInfo() from 
graphics/libdrm/files/patch-xf86drm.c */
struct pci_conf_io pc;
struct pci_match_conf patterns[1];
struct pci_conf results[1];

if (argc < 5) {
printf("usage: %s\n", argv[0]);
return 1;
}

int fd = open("/dev/pci", O_RDONLY, 0);
if (fd < 0)
err(1, "open(/dev/pci) failed");

bzero(&patterns, sizeof(patterns));
patterns[0].pc_sel.pc_domain = atoi(argv[1]);
patterns[0].pc_sel.pc_bus = atoi(argv[2]);
patterns[0].pc_sel.pc_dev = atoi(argv[3]);
patterns[0].pc_sel.pc_func = atoi(argv[4]);
patterns[0].flags = PCI_GETCONF_MATCH_DOMAIN | PCI_GETCONF_MATCH_BUS
  | PCI_GETCONF_MATCH_DEV | PCI_GETCONF_MATCH_FUNC;
bzero(&pc, sizeof(struct pci_conf_io));
pc.num_patterns = 1;
pc.pat_buf_len = sizeof(patterns);
pc.patterns = patterns;
pc.match_buf_len = sizeof(results);
pc.matches = results;

if (ioctl(fd, PCIOCGETCONF, &pc) || pc.status == PCI_GETCONF_ERROR) {
close(fd);
err(1, "PCIOCGETCONF failed");
}
close(fd);

printf("vendor=%#x, device=%#x, subvendor=%#x, subdevice=%#x, revid=%#x\n", 
   results[0].pc_vendor, results[0].pc_device, 
   results[0].pc_subvendor, results[0].pc_subdevice,
   results[0].pc_revid);

return 0;
}
___
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: FreshPorts, pkg query and pkg rquery: versions of dependencies

[Jan Beich]

Graham Perrin  writes:

> devel/icu for example.
>
> On Mon, 29 Oct 2018 at 04:13, I wrote:
>
>> Waterfox: downgrading to icu-62.1_2,1 and rebuilding consumers
>
>> … 
>> specifies icu>=59.1,1 so I'm probably OK there …
>
> I say "probably" because I'm not sure how to interpret the>=59.1,1
> alongside these results from pkg:
>
> $ pkg query '%do %dv %R' mail/thunderbird | grep icu
> devel/icu 62.1_2,1 FreeBSD
> $ pkg rquery '%do %dv %R' mail/thunderbird | grep icu
> devel/icu 63.1,1 FreeBSD
> $

If you downgrade icu to 58.1 or earlier the build would abort when
checking BUILD_DEPENDS rather than at configure stage. Version requirements
like that are used to facilitate partial upgrades (not all dependencies
in sync or up-to-date) but the support is fragile/untested as there's no
handholding in case of issues.
___
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: downgrading to icu-62.1_2,1 and rebuilding consumers

[Jan Beich]

Graham Perrin  writes:

> - is this DEFAULT_VERSIONS= line correct/sufficient for
>   Thunderbird etc. to be built with the inferior version of icu?
>
> DEFAULT_VERSIONS= icu=62.1_2,1

Only one icu version is supported in the ports tree, so the above is nop.
The ports are built against whatever version is installed.
___
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:

> $ waterfox
> XPCOMGlueLoad error for file /usr/local/lib/waterfox/libxul.so:
> Shared object "libicui18n.so.62" not found, required by "libxul.so"
> Couldn't load XPCOM.

devel/icu major updates aren't ABI-compatible, so each update requires
rebuilding every consumer. This is usually done by bumping PORTREVISION.
As www/waterfox was removed before r482830 it missed rebuild thus still
depends on the old shared library version.

https://abi-laboratory.pro/tracker/timeline/icu4c/

> Is there any easy-ish way to work around this?

Easy way is libmap.conf but it may lead to application crashes.

>
> A downgrade to 12.0-BETA2, maybe?
>
> (I know, the www/waterfox was deleted but I'd like to continue using it for 
> as long as possible.)

Either rebuild www/waterfox from the last revision before removal or
downgrade devel/icu to 62.1 if nothing else requires 63.1. In the former
case you can also update the port (adjust DISTVERSION then run "make
makesum") assuming no patch conflicts.
___
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"

[regression] drm-stable-kmod doesn't work in i386 jail on amd64 host

[Jan Beich]

I often test Firefox on 10.4 i386 and sometimes play games via Wine.
Both require working OpenGL for COMPAT_FREEBSD32. My GPU is Skylake
which worked fine a few weegs ago i.e., before r338990.

Any clue?

$ uname -a
... FreeBSD 12.0-ALPHA8 #0 r339218M: Sun Oct  7 11:26:25 UTC 2018 
foo@bar:/tmp/usr/src/amd64.amd64/sys/MYKERNEL amd64

$ sysctl kern.conftxt | fgrep COMPAT_
options COMPAT_FREEBSD11
options COMPAT_FREEBSD10
options COMPAT_FREEBSD32

$ pkg info -x drm.\*kmod
drm-stable-kmod-g20180822

$ pkg install mesa-dri mesa-demos
$ LIBGL_DEBUG=verbose glxgears
MESA-LOADER: failed to retrieve device information
libGL: OpenDriver: trying /usr/local/lib/dri/i915_dri.so
libGL: Can't open configuration file /home/foo/.drirc: No such file or 
directory.
libGL: Using DRI2 for screen 0
libGL: Can't open configuration file /home/foo/.drirc: No such file or 
directory.
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
Segmentation 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: What's this gregset_t gregs thing

[Jan Beich]

blubee blubeeme  writes:

> Linux has gregset_t gregs;
> https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/x86/sys/ucontext.h
>
> Defined above, I also see it in the RISC-V glibc stuff as well.
>
> FreeBSD doesn't seem to have this field defined, I see FreeBSD uses
> /usr/include/x86/ucontext.h
>
> but there's no gregs;

__gregs exists on FreeBSD arm*, inherited from NetBSD.

> If I wanted to return mcontext.gregs
>
> How could I implement that on FreeBSD?

Only as gregset_t? If not return registers individually e.g.,
https://searchfox.org/mozilla-central/rev/83562422ecb0f5683da7a9a26ce05ce62bc0c882/js/src/wasm/WasmSignalHandlers.cpp#244
___
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: [RFC] Deprecation and removal of the drm2 driver

[Jan Beich]

Slawa Olhovchenkov  writes:

> On Fri, May 18, 2018 at 07:58:10PM +0200, Niclas Zeising wrote:
>
>> [ Cross posted to freebsd-current@ and freebsd-x11@.  Please respect 
>> reply-to and send all replies to freebsd-x11@.  Thanks! ]
>> 
>> 
>> Hi!
>> I propose that we remove the old drm2 driver (sys/dev/drm2) from 
>> FreeBSD.  I suggest the driver is marked as deprecated in 11.x and 
>> removed from 12.0, as was done for other drivers recently.  Some 
>> background and rationale:
>> 
>> The drm2 driver was the original port of a KMS driver to FreeBSD.  It 
>> was done by Konstantin Belousov to support Intel graphics cards, and 
>> later extended by Jean-Sébastien Pédron as well as Konstantin to match 
>> what's in Linux 3.8.  This included unstable support from Haswell, but 
>> nothing newer than that.
>> 
>> For quite some time now we have had the graphics/drm-stable-kmod and 
>> graphics/drm-next-kmods which provides support for modern AMD and Intel 
>> graphics cards.  These ports, together with the linuxkpi, or lkpi, has 
>
> What about old graphics card? I am have notebook w/ i945 chipset, is
> this supported by graphics/drm-*?
>
> And what about nvidia?
> (sorry, I am not developer this drivers, I am just user, I am don't
> know what need for nvidia work etc)

NVIDIA dropped 32bit driver since 396.* series. None of x11/nvidia-driver*
currently depend on either drm.ko or drm2.ko. However, Linux driver
appears to depend on DRM/KMS since 364.12.
___
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: Clang-6 and GNUisms.

[Jan Beich]

Ian FREISLICH  writes:

> /usr/ports/lang/v8/work/v8-3.18.5/out/native/obj.target/v8_base.x64/src/type-info.o../src/stub-cache.cc:1477:33:
> error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed
>   : GetCodeWithFlags(flags, reinterpret_cast(NULL));
> ^

Try using static_cast instead e.g.,
https://freshbsd.org/search?q=reinterpret_cast+from+%27nullptr_t%27+to

Which is caused by
https://svnweb.freebsd.org/changeset/base/228918
___
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: drm-next-kmod regression

[Jan Beich]

Manuel Stühn  writes:

> Hi,
> the last drm-next-kmod worked fine on my Lenovo T420 with i5-2520M and
> a HD Graphics 3000. After the update to the actual version (4.11) from
> ports, I'm seeing regression in form of a very slow xfce4-desktop. The
> slowness starts after some short time. Slow means for example that I
> can type faster than the terminal prints the chars or when i move
> windows they lag extremely behind the mouse's motion.
>
> One entry in Xorg.0.log caught my attention:
> [   128.266] (EE) intel(0): Failed to submit rendering commands (Bad
> address), disabling acceleration.

Did you build xf86-video-intel with SNA option enabled or have
Option "AccelMethod" "SNA" in xorg.conf? If so see also

https://github.com/FreeBSDDesktop/kms-drm/issues/32
___
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: drm-next-kmod-4.11 and vaapi hardware acceleration

[Jan Beich]

Oleg Lelchuk  writes:

> I run 12-CURRENT-r330303. My cpu is Haswell. After compiling
> drm-next-kmod-4.11 and libva-intel-driver, I get garbled videos in both mpv
> and vlc when the vaapi hardware acceleration is enabled. I had no such
> problem with the previous version of drm-next-kmod. Is it possible that
> libva-intel-driver-2.1 and drm-next-kmod-4.11 are not fully compatible with
> one another? Please tell me what I should do to resolve this issue.

See also https://github.com/FreeBSDDesktop/kms-drm/issues/32
___
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: atomic in i386 Current after CLANG 6 upgrade

[Jan Beich]

Tijl Coosemans  writes:

> On Mon, 15 Jan 2018 11:43:44 +0100 Luca Pizzamiglio  
> wrote:
>
>> I've already received a couple of messages from pkg-fallout about build
>> failure on head-i386-default [1] [2] both pointing to the same errors,
>> about missing intrinsic symbols related to __atomic_*
>> 
>> The clang documentation about C11 atomic builtins [3] stats that __atomic_*
>> are GCC extension and Clang provides them.
>> 
>> It seems to me that this specific GCC-compatible builtin are enabled on
>> amd64, but not on i386.
>> Is there a way to enable GCC compatible __atomic_ builtin also on i386?
>> Or should I provide patches to adopt _c11_atomic_* instead of __atomic_*
>> for every ports that need it ?
>> 
>> [1]
>> http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/librdkafka-0.11.3.log
>> [2]
>> http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/stress-ng-0.09.09.log
>> [3] https://clang.llvm.org/docs/LanguageExtensions.html#langext-c11-atomic
>
> 8 byte atomics requires at least i586.  So either find a way to disable
> the use of these atomics in these ports or add something like this to
> the port Makefile.
>
> .if ${ARCH} == i386 && ! ${MACHINE_CPU:Mi586}
> CFLAGS+=  -march=i586
> .endif

It wouldn't help (see below). Clang 6 accidentally made __atomic* work
enough to satisfy configure check but not for the port to build. I guess,
it also confuses configure in net/librdkafka and net-mgmt/netdata.

$ cat a.c
#include 

typedef struct {
  uint64_t val64;
} atomic_t;

int main()
{
  uint64_t foo;
  atomic_t bar;
#ifdef ATOMIC_STRUCT
  __atomic_fetch_add(&bar.val64, 1, __ATOMIC_RELAXED);
#else
  __atomic_fetch_add(&foo, 1, __ATOMIC_RELAXED);
#endif
  return 0;
}

$ cc -m32 -march=i586 a.c
$ clang50 -m32 -march=i586 a.c
/tmp/a-560ad1.o: In function `main':
a.c:(.text+0x46): undefined reference to `__atomic_fetch_add_8'
clang-5.0: error: linker command failed with exit code 1 (use -v to see 
invocation)

$ cc -m32 -DATOMIC_STRUCT -march=i586 a.c
/usr/bin/ld: error: undefined symbol: __atomic_fetch_add_8
>>> referenced by a.c
>>>   /tmp/a-ad8c36.o:(main)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
$ clang50 -m32 -DATOMIC_STRUCT -march=i586 a.c
/tmp/a-0fbfd0.o: In function `main':
a.c:(.text+0x46): undefined reference to `__atomic_fetch_add_8'
clang-5.0: error: linker command failed with exit code 1 (use -v to see 
invocation)
___
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: FreeBSD 11.0-RC1 Now Available

[Jan Beich]

Glen Barber  writes:

> The first RC build of the 11.0-RELEASE release cycle is now available.
>
> Installation images are available for:
>
> o 11.0-RC1 amd64 GENERIC
> o 11.0-RC1 i386 GENERIC
> o 11.0-RC1 powerpc GENERIC
> o 11.0-RC1 powerpc64 GENERIC64
> o 11.0-RC1 sparc64 GENERIC
> o 11.0-RC1 armv6 BANANAPI
> o 11.0-RC1 armv6 BEAGLEBONE
> o 11.0-RC1 armv6 CUBIEBOARD
> o 11.0-RC1 armv6 CUBIEBOARD2
> o 11.0-RC1 armv6 CUBOX-HUMMINGBOARD
> o 11.0-RC1 armv6 GUMSTIX
> o 11.0-RC1 armv6 RPI-B
> o 11.0-RC1 armv6 RPI2
> o 11.0-RC1 armv6 PANDABOARD
> o 11.0-RC1 armv6 WANDBOARD
> o 11.0-RC1 aarch64 GENERIC

What about granular sets? sparc64 is N/A while amd64 is missing
lib32.txz, src.txz, ports.txz, tests.txz. Regressed since 11.0-BETA4.
I've waited a day to see if the issue would disappear after mirrors
catch up but no joy, even via Tor.

$ poudriere jail -cj 110amd64 -a amd64 -v 11.0-RC1
[00:00:01] >> Creating 110amd64 fs... done
[00:00:01] >> Fetching MANIFEST for FreeBSD 11.0-RC1 amd64
/poudriere/jails/110amd64/fromftp/MANIFEST100% of 1157  B   21 MBps 00m00s
[00:00:02] >> Fetching base.txz for FreeBSD 11.0-RC1 amd64
/poudriere/jails/110amd64/fromftp/base.txz100% of   95 MB 3554 kBps 00m27s
[00:00:30] >> Extracting base.txz... done
[00:00:37] >> Fetching src.txz for FreeBSD 11.0-RC1 amd64
fetch: https://download.FreeBSD.org/ftp/releases/amd64/amd64/11.0-RC1/src.txz: 
Not Found
fetch: https://download.FreeBSD.org/ftp/releases/amd64/amd64/11.0-RC1/src.txz: 
Not Found
[00:00:37] >> Error: Failed to fetch from 
https://download.FreeBSD.org/ftp/releases/amd64/amd64/11.0-RC1/src.txz
[00:00:37] >> Error while creating jail, cleaning up.
[00:00:37] >> Removing 110amd64 jail... done

$ poudriere jail -cj 110sparc64 -a sparc64 -v 11.0-RC1
[00:00:00] >> Creating 110sparc64 fs... done
[00:00:00] >> Fetching MANIFEST for FreeBSD 11.0-RC1 sparc64
fetch: 
https://download.FreeBSD.org/ftp/releases/sparc64/sparc64/11.0-RC1/MANIFEST: 
Forbidden
fetch: 
https://download.FreeBSD.org/ftp/releases/sparc64/sparc64/11.0-RC1/MANIFEST: 
Forbidden
[00:00:00] >> Error: Failed to fetch from 
https://download.FreeBSD.org/ftp/releases/sparc64/sparc64/11.0-RC1/MANIFEST
[00:00:00] >> Error while creating jail, cleaning up.
[00:00:00] >> Removing 110sparc64 jail... done


signature.asc
Description: PGP signature

Re: BXR.SU, Super User's BSD Cross Reference w/ OpenGrok, publicly private beta

[Jan Beich]

"Constantine A. Murenin"  writes:

[...]
>   Just how fast is BXR.SU?
>
> We expect that most search requests should be fulfilled (search page
> results generated) in well under 100ms.  In my tests, and according to
> OpenGrok metrics at the bottom of each search page, most search pages
> are generated in about 30 to 50ms, so, it does seem like there's some
> room to spare.  In addition, of course we use nginx, so, once
> generated at 40ms, a page should be available immediately in no time
> should a subsequent identical request come along within a couple of
> seconds or so.
>
>
>   How does it compare with fxr.watson.org?
>
> + we're based on OpenGrok, instead of LXR
> + we also index userland of all BSDs, not just the kernels like the fxr
> + we do daily updates and re-index of all 4 BSDs
> - we only track -CURRENT of each BSD
> + the -current that we track is actually current

Last modified date on FreeBSD files is 09-Dec-2013. Do you plan to fix it?

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  
___
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: [Heads up] BSD-licensed patch becoming the default RSN.

[Jan Beich]

Pedro Giffuni  writes:

> Now, just some food for thought, but if you are unsure your patch
> applies cleanly, why would you choose to use the -s (silent) option?

Because by default patch(1) is overly verbose. At first, I'm only
interested if a patch applies cleanly, then what files fail to apply.
To fix the patch I just repeat over edit a hunk (or two) and confirm
patch(1) no longer rejects it.

With -Cs giving up is easy at any time. One may not care about
a failed hunk in a man page or prefer to edit a patch as the whole
instead of on per-file (.rej file) basis.

> It would seem to me that some people may want the -s option to be
> truly silent (those paths may be long) and since those .rej files are
> not
> really being created it is consistent not to list them.

If you need -s to be truly silent then you're probably writing a script.
At which point -C being a BSD extension and -s behaving differently from
GNU patch would make more pain than not using them.

A new option may be better e.g.,

 -q, --quiet
Do not write anything to standard output. Exit immediately
with non-zero status if any hunk fails to apply.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [Heads up] BSD-licensed patch becoming the default RSN.

[Jan Beich]

bsdpatch doesn't list files of the failed hunks with -C and -s option.
This may be less convenient if you edit a patch directly rather than
regen it after polluting the tree.

$ patch -CEfsp0 -i /path/to/varsym.diff
1 out of 1 hunks failed
1 out of 2 hunks failed
2 out of 2 hunks failed
1 out of 5 hunks failed
1 out of 1 hunks failed
1 out of 1 hunks failed
1 out of 1 hunks failed
zsh: exit 1

$ gnupatch -CEfsp0 -i /path/to/varsym.diff
1 out of 1 hunks failed--saving rejects to contrib/openbsm/etc/audit_event.rej
1 out of 2 hunks failed--saving rejects to lib/libc/sys/Makefile.inc.rej
2 out of 2 hunks failed--saving rejects to 
sys/security/audit/audit_private.h.rej
1 out of 5 hunks failed--saving rejects to sys/security/audit/audit.h.rej
1 out of 1 hunks failed--saving rejects to sys/bsm/audit_kevents.h.rej
1 out of 1 hunks failed--saving rejects to sys/kern/syscalls.master.rej
1 out of 1 hunks failed--saving rejects to sys/sys/priv.h.rej
zsh: exit 8
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@

[Jan Beich]

Dimitry Andric  writes:

> On Apr 16, 2013, at 00:42, Jan Beich  wrote:
>
>> "O. Hartmann"  writes:
>>> ./unistd.h:694:5: error: invalid token at start of a preprocessor
>>> expression
>>> #if @GNULIB_EUIDACCESS@
>>>^
>>> 1 error generated.
>> 
>> Maybe -O3 overoptimizes regex in libc e.g.,
>> 
>> $ echo '#if @GNULIB_EUIDACCESS@' | sed 's/@GNULIB_EUIDACCESS@/0/'
>> #if @GNULIB_EUIDACCESS@
>> 
>> $ echo 'xxx' | sed 's/xxx//'
>> xxx
>
> How did you arrive at this result?

1/ chroot into poudriere jail for /head amd64
2/ echo CFLAGS+=-O3 >> /etc/make.conf
3/ make -j2 (in /usr/src/lib/libc)
4/ prepend LD_LIBRARY_PATH=. before sed(1)
5/ rebuild regcomp.o, regcomp.So with -O2 to confirm

> I have recompiled both libc and sed
> with -O3, but it works just fine here.

> Maybe -march=native is the clue, so which kind of CPU do you have?

sse2 is available on amd64 even without -march=. But I can't reproduce
the issue on i386 even with -march=native.

> To see what CPU llvm detects, try:
>
>   tblgen -version | grep CPU

  Host CPU: penryn

>
> Note that -O3 turns on clang's vectorizer, so you might have run into an
> optimizer bug, or some kind of undefined behavior which now falls over.

My luck is poor even with -O2 e.g., firefox20 crash on stackoverflow.com

[New LWP 101222]
[New Thread 801b02400 (LWP 101222)]
[New Thread 81060e800 (LWP 101372 StreamTrans #1)]
[New Thread 810ee8800 (LWP 101373 DOM Worker)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 801b02400 (LWP 101222)]
PodCopy (dst=, nelem=,
src=, dst=, src=,
nelem=) at ../../../js/src/jsutil.h:238
238 PodAssign(dst, src);
(gdb) bt
#0  PodCopy (dst=, nelem=,
src=, dst=, src=,
nelem=) at ../../../js/src/jsutil.h:238
#1  getCallFrame (cx=, flags=, fun=,
report=(unknown: 2266652928), this=, args=..., script=...)
at ../../../js/src/vm/Stack-inl.h:454
#2  getFixupFrame (cx=, initial=,
fun=, ncode=, dummy=0, report=,
this=, cx=, report=, args=...,
fun=, script=..., ncode=,
initial=, stackLimit=)
at ../../../js/src/vm/Stack-inl.h:513
#3  js::mjit::stubs::FixupArity (f=..., nactual=4294945312)
at 
/wrkdirs/usr/ports/www/firefox/work/mozilla-release/js/src/methodjit/InvokeHelpers.cpp:213
#4  0x0008019c48c2 in ?? ()
#5  0x0008019b56b8 in ?? ()
#6  0x0001 in ?? ()
#7  0x in ?? ()

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

Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@

[Jan Beich]

"O. Hartmann"  writes:

> Trying to recompile converters/libiconv on FreeBSD 10.0-CUR/r49438 (with
> bran new CLANG 3.3) results  with the errors below. This error shows up
> on boxes having FBSD 10 and X11. It doesn't show up on those boxes
> running without a full X11 (that is the only difference I can figure out
> at the moment since the different systems share a lot of configuration
> stuff, having different CPU types (C2D, Sandy-Bridge, Ivy-Bridge) but
> nothing I can figure out as the source of the strange behaviour and
> error).
[...]
> converters/libiconv:
> cc -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I.. -I../lib  -I../intl
> -DDEPENDS_ON_LIBICONV=1  -DDEPENDS_ON_LIBINTL=1-O2 -pipe -O3
> -march=native -fno-strict-aliasing -c areadlink.c
> In file included from areadlink.c:27:
> In file included from ./careadlinkat.h:23:
> In file included from ./fcntl.h:62:
> ./unistd.h:694:5: error: invalid token at start of a preprocessor
> expression
> #if @GNULIB_EUIDACCESS@
> ^
> 1 error generated.

Maybe -O3 overoptimizes regex in libc e.g.,

$ echo '#if @GNULIB_EUIDACCESS@' | sed 's/@GNULIB_EUIDACCESS@/0/'
#if @GNULIB_EUIDACCESS@

$ echo 'xxx' | sed 's/xxx//'
xxx
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mdoc warning: .Fx: Unknown FreeBSD version `10' (#181)

[Jan Beich]

Andrey Fesenko  writes:

> On Sat, Mar 16, 2013 at 8:59 PM, deeptech71  wrote:
>
>> When running ``man script'' (world r248258), I get:
>>
>>   mdoc warning: .Fx: Unknown FreeBSD version `10' (#181)
>>
>> (and the whole man page, which quickly hides the warning).

There's one more .Fx bug in __iconv_get_list(3) since 9.0.

> not correct macros .Fx may be fix
>  % diff script.1 script.1.orig
> 181c181
> < .Fx 10.0 .
> ---
>> .Fx 10 .

Brian, what happened to MFC'ing -d/-p/-r options ? r238896 seems to work
just fine on script(1) from /stable/9 and /stable/8.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found

[Jan Beich]

Dimitry Andric  writes:

> $ echo 'sub/foo.barx' | grep sub/foo.bar
> $ echo $?
> 1

$ echo 'sub/foo.barx' | env -i grep sub/foo.bar
$ echo 'sub/foolbarx' | env -i grep sub/foo.bar
$ echo 'sub/foo.barx' | env -i grep 'sub/foo\.bar'
sub/foo.barx
$ echo 'sub/foo.barx' | env -i grep -o sub/foo.bar
sub/foo.bar
$ echo 'sub/foo.barx' | env -i grep --color=no sub/foo.bar
sub/foo.barx

A buggy shortcut?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r247839: broken pipe - for top, sudo and ports

[Jan Beich]

Jilles Tjoelker  writes:

> On Thu, Mar 07, 2013 at 04:54:01AM -0100, Jan Beich wrote:
>
>> Jilles Tjoelker  writes:
>
>> > On Tue, Mar 05, 2013 at 08:59:09PM +0100, Hartmann, O. wrote:
>
>> >> A "truss top" reveals this, is this of help?
>
>> >> [...]
>> >> stat("/etc/nsswitch.conf",{ mode=-rw-r--r--
>> >> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
>> >> stat("/etc/nsswitch.conf",{ mode=-rw-r--r--
>> >> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
>> >> stat("/etc/nsswitch.conf",{ mode=-rw-r--r--
>> >> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
>> >> stat("/etc/nsswitch.conf",{ mode=-rw-r--r--
>> >> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
>> >> stat("/etc/nsswitch.conf",{ mode=-rw-r--r--
>> >> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
>> >> socket(PF_LOCAL,SOCK_STREAM,0)   = 4 (0x4)
>> >> connect(4,{ AF_UNIX "/var/run/nscd" },15)= 0 (0x0)
>> >> fcntl(4,F_SETFL,O_NONBLOCK)  = 0 (0x0)
>> >> kqueue(0x80183b000,0x80122fc58,0x10,0x80062b308,0x80183b010,0x2)
>> >> = 5 (0x5)
>> >> kevent(5,{0x4,EVFILT_WRITE,EV_ADD,0,0x0,0x0},1,0x0,0,0x0) = 0 (0x0)
>> >> kqueue(0x5,0x7fffd2e0,0x1,0x0,0x0,0x0)   = 6 (0x6)
>> >> kevent(6,{0x4,EVFILT_READ,EV_ADD,0,0x0,0x0},1,0x0,0,0x0) = 0 (0x0)
>> >> kevent(5,{0x4,EVFILT_WRITE,EV_ADD,1,0x4,0x0},1,0x0,0,0x0) = 0 (0x0)
>> >> kevent(5,0x0,0,{0x4,EVFILT_WRITE,EV_EOF,0,0x2000,0x0},1,0x0) = 1 (0x1)
>> >> sendmsg(0x4,0x7fffd290,0x0,0x1,0x1,0x0)  ERR#32 'Broken pipe'
>> >> SIGNAL 13 (SIGPIPE)
>> >> process exit, rval = 0
>
>> > Apparently there is a bug that causes nscd to close the connection
>> > immediately but even then it is wrong that this terminates the calling
>> > program with SIGPIPE.
>
>> > The below patch prevents the SIGPIPE but cannot revive the connection to
>> > nscd. This may cause numeric UIDs in top or increase the load on the
>> > directory server. It is compile tested only.
>> [...]
>
>> The patch seems to fix the issue in a world after r247804. I don't see
>> numeric UIDs in top but without the patch top crashes with SIGPIPE a lot
>> less frequently than sudo or make install (in base/ports) for me.
>
>> In my case shutting down nscd helped, too. Compared to stock
>> nsswitch.conf I only have "cache" added.
>
> Can you find what causes nscd to close the connection quickly, such as
> using ktrace?

# single user mode
$ ktrace -p $(pgrep nscd); top -b; ktrace -c; kdump
71 nscd GIO   fd 5 wrote 0 bytes
   ""
71 nscd GIO   fd 5 read 32 bytes
   0x 0400     1000   0100  |..|
   0x0012       |..|

71 nscd RET   kevent 1
71 nscd CALL  accept(0x4,0,0)
71 nscd RET   accept 6
71 nscd CALL  getsockopt(0x6,0,0x1,0x7f9fce28,0x7f9fce24)
71 nscd RET   getsockopt 0
71 nscd CALL  kevent(0x5,0x7f9fcf00,0x2,0,0,0x7f9fcf50)
71 nscd GIO   fd 5 wrote 64 bytes
   0x 0600    f9ff 1100   401f  |@.|
   0x0012  401f  40e6 4002 0800  0600   |..@...@.@.|
   0x0024    1100 0100  0400    |..|
   0x0036  40e6 4002 0800   |..@.@.|

71 nscd GIO   fd 5 read 0 bytes
   ""
71 nscd RET   kevent 0
71 nscd CALL  kevent(0x5,0x7f9fcec0,0x1,0,0,0x7f9fcee0)
71 nscd GIO   fd 5 wrote 32 bytes
   0x 0400     1100     |..|
   0x0012       |..|

71 nscd GIO   fd 5 read 0 bytes
   ""
71 nscd RET   kevent 0
71 nscd CALL  kevent(0x5,0,0,0x7f9fcec0,0x1,0)
71 nscd GIO   fd 5 wrote 0 bytes
   ""
71 nscd GIO   fd 5 read 32 bytes
   0x 0600    f9ff 3000   0100  |..0...|
   0x0012    40e6 4002 0800 |..@.@.|

71 nscd RET   kevent 1
71 nscd CALL  close(0x6)
71 nscd RET   close 0
71 nscd CALL  kevent(0x5,0,0,0x7f9fcec0,0x1,0)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r247839: broken pipe - for top, sudo and ports

[Jan Beich]

Jilles Tjoelker  writes:

> On Tue, Mar 05, 2013 at 08:59:09PM +0100, Hartmann, O. wrote:
>
>> A "truss top" reveals this, is this of help?
>
>> [...]
>> stat("/etc/nsswitch.conf",{ mode=-rw-r--r--
>> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
>> stat("/etc/nsswitch.conf",{ mode=-rw-r--r--
>> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
>> stat("/etc/nsswitch.conf",{ mode=-rw-r--r--
>> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
>> stat("/etc/nsswitch.conf",{ mode=-rw-r--r--
>> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
>> stat("/etc/nsswitch.conf",{ mode=-rw-r--r--
>> ,inode=162310,size=1007,blksize=32768 }) = 0 (0x0)
>> socket(PF_LOCAL,SOCK_STREAM,0)   = 4 (0x4)
>> connect(4,{ AF_UNIX "/var/run/nscd" },15)= 0 (0x0)
>> fcntl(4,F_SETFL,O_NONBLOCK)  = 0 (0x0)
>> kqueue(0x80183b000,0x80122fc58,0x10,0x80062b308,0x80183b010,0x2) = 5 (0x5)
>> kevent(5,{0x4,EVFILT_WRITE,EV_ADD,0,0x0,0x0},1,0x0,0,0x0) = 0 (0x0)
>> kqueue(0x5,0x7fffd2e0,0x1,0x0,0x0,0x0)   = 6 (0x6)
>> kevent(6,{0x4,EVFILT_READ,EV_ADD,0,0x0,0x0},1,0x0,0,0x0) = 0 (0x0)
>> kevent(5,{0x4,EVFILT_WRITE,EV_ADD,1,0x4,0x0},1,0x0,0,0x0) = 0 (0x0)
>> kevent(5,0x0,0,{0x4,EVFILT_WRITE,EV_EOF,0,0x2000,0x0},1,0x0) = 1 (0x1)
>> sendmsg(0x4,0x7fffd290,0x0,0x1,0x1,0x0)  ERR#32 'Broken pipe'
>> SIGNAL 13 (SIGPIPE)
>> process exit, rval = 0
>
> Apparently there is a bug that causes nscd to close the connection
> immediately but even then it is wrong that this terminates the calling
> program with SIGPIPE.
>
> The below patch prevents the SIGPIPE but cannot revive the connection to
> nscd. This may cause numeric UIDs in top or increase the load on the
> directory server. It is compile tested only.
[...]

The patch seems to fix the issue in a world after r247804. I don't see
numeric UIDs in top but without the patch top crashes with SIGPIPE a lot
less frequently than sudo or make install (in base/ports) for me.

In my case shutting down nscd helped, too. Compared to stock
nsswitch.conf I only have "cache" added.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r247829: dbus fails to start. portmaster SIGNAL 13 when doing extraction

[Jan Beich]

"Hartmann, O."  writes:

> *** [do-extract] Signal 13

I have the same issue but it usually happens on `make install'.
And reverting r247804 seems to be the workaround. Can you confirm?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: Capsicum overhaul.

[Jan Beich]

Pawel Jakub Dawidek  writes:

> I just committed pretty large change that affects not only Capsicum, but
> also descriptor handling code in the kernel. If you will find some
> strange problems after r243611 (like panics, unexpected application
> errors, etc.) I may be at fault. I'll be looking at current@ mailing
> list closly, so report here if you find problems that look related to my
> change.

tmux started to behave weirdly, sometimes failing to attach:

  $ printenv
  PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
  OLDPWD=/
  DISPLAY=:0
  PWD=/home/foo
  TERM=xterm
  USER=foo
  HOME=/home/foo
  SHELL=/bin/sh

  $ ktrace -i tmux -L test -f /dev/null
  $ echo $?
  1
  $ kdump -r | pastebinit -a 'tmux fails to attach'
  http://pastebin.com/U3nCPrFY

  $ env -i TERM=$TERM ktrace -i /usr/local/bin/tmux -L test -f /dev/null
  $ ^D
  [exited]
  $ kdump -r | pastebinit -a 'tmux fails to attach (workaround)'
  http://pastebin.com/w1dsUAU4

I've tried so far:

  * booting allbsd.org snapshot -> no joy
  * enabling capsicum options -> no joy
  * reverting recent capsicum commits -> works fine
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

DEBUG_FLAGS broken with -jX (Was: svn commit: r244236 - head/share/mk)

[Jan Beich]

Ed Maste  writes:

> Author: emaste
> Date: Sat Dec 15 00:03:35 2012
> New Revision: 244236
> URL: http://svnweb.freebsd.org/changeset/base/244236
>
> Log:
>   Put shared library debug info into separate .symbols file
>   
>   Sponsored by: ADARA Networks

Does this work with -jX ?

  $ echo DEBUG_FLAGS=-g >/etc/make.conf
  $ make -vj2
  [...]
  --- Version.map ---
  cat /usr/src/lib/librpcsec_gss/Symbol.map | cpp - -  | awk -v 
vfile=/usr/src/lib/librpcsec_gss/../libc/Versions.def -f 
/usr/src/share/mk/version_gen.awk > Version.map
  --- librpcsec_gss.a ---
  building static rpcsec_gss library
  ranlib librpcsec_gss.a
  --- librpcsec_gss.so.1.debug ---
  building shared library librpcsec_gss.so.1
  /usr/obj/usr/src/tmp/usr/bin/ld:Version.map:1: syntax error in VERSION script
  cc: error: linker command failed with exit code 1 (use -v to see invocation)
  *** [librpcsec_gss.so.1.debug] Error code 1
  1 error
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r246057: buildworld fails with: /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()'

[Jan Beich]

"O. Hartmann"  writes:

> c++ -O3 -pipe -fno-strict-aliasing -march=native -march=native
> -DHAVE_CONFIG_H -I/usr/src/libexec/atf/atf-check/../../../contrib/atf
> -Qunused-arguments -fstack-protector -Wsystem-headers -Wall
> -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith
> -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-conversion -stdlib=libc++ -std=c++11
> -L/usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++
> -L/usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c -o
> atf-check atf-check.o -latf-c++ -latf-c
> /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to
> `std::bad_alloc::~bad_alloc()'
> /usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++/libatf-c++.so:
> undefined reference to `std::bad_alloc::bad_alloc()'
> /usr/obj/usr/src/libexec/atf/atf-check/../../../lib/atf/libatf-c++/libatf-c++.so:
> undefined reference to `std::bad_alloc::~bad_alloc()'
> /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to
> `std::bad_alloc::bad_alloc()'
> c++: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** [atf-check] Error code 1

Try stage binaries built with default CXXFLAGS from allbsd.org snapshot.
With them installed do you see smth like the following?

  $ clang++ -stdlib=libc++ foo.c
  clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior 
is deprecated
  /usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()'
  /usr/lib/libc++.so: undefined reference to `std::bad_alloc::bad_alloc()'
  /usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()'
  /usr/lib/libc++.so: undefined reference to `std::bad_alloc::bad_alloc()'
  clang++: error: linker command failed with exit code 1 (use -v to see 
invocation)

It's different from the error when you build libc++ before libcxxrt.

  $ clang++ -stdlib=libc++ foo.c
  clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior 
is deprecated
  /usr/lib/libc++.so: undefined reference to 
`std::uncaught_exception()@CXXABI_1.3'
  /usr/lib/libc++.so: undefined reference to 
`std::exception::~exception()@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to 
`std::bad_alloc::~bad_alloc()@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to `typeinfo for 
std::exception@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to 
`std::bad_alloc::~bad_alloc()@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to 
`std::bad_alloc::bad_alloc()@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to `typeinfo for 
std::bad_cast@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to 
`std::bad_cast::~bad_cast()@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to `typeinfo for 
std::bad_alloc@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to 
`std::bad_alloc::bad_alloc()@CXXRT_1.0'
  /usr/lib/libc++.so: undefined reference to `std::terminate()@CXXABI_1.3'
  clang++: error: linker command failed with exit code 1 (use -v to see 
invocation)

--
#! /bin/sh
# fetch/install stage binaries from allbsd.org snapshots

TARGET=amd64
TARGET_ARCH=amd64
BRANCH=10.0-HEAD
#REVISION=r245980 # works fine
REVISION=r246034 # doesn't work
LIBS="lib/libcxxrt/libcxxrt.so.1:/lib \
  lib/libc++/libc++.so.1:/usr/lib \
  gnu/lib/libsupc++/libsupc++.so.1:/usr/lib"

for f in $LIBS; do
#chflags 0 $dir/${file##*/}
fetch -o ${f#*:} 
https://pub.allbsd.org/FreeBSD-snapshots/${TARGET}-${TARGET_ARCH}/${BRANCH}-${REVISION}-JPSNAP/stage/usr/obj/usr/src/${f%:*}
done
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: November 5th is Clang-Day

[Jan Beich]

David Naylor  writes:

> On Friday, 2 November 2012 10:13:30 David Chisnall wrote:
>
>> On 2 Nov 2012, at 05:24, Jan Beich wrote:
>> >> Known Issues
>> > 
>> > emulators/wine doesn't work with lib32 built by clang, probably due to
>> > wine bugs.
>> 
>> Is this still the case?  There was an issue preventing WINE from working
>> because it required stricter stack alignment than clang provided by
>> default, but I thought it was fixed.  Does WINE work if compiled with the
>> flag that forces stack realignment?  If not, then it's some other issue...
>
> There are two issues here: 1) wine compiled with clang, and 2) wine (compiled 
> with gcc) running on clang compiled base.  
>
> Regarding 1), according to the wiki [1], wine does have stack alignment 
> issues 
> and some wine programs do not run when compiled with clang [2][3] and other 
> bugs with clang cause freezing within wine [4][5].  The impression I get is 
> that, using the work-a-round of stack realignment, wine does work to some 
> extent when compiled by clang.

Took me some time but now I can confirm that clang-built wine-1.5.16
works fine for me with gcc-built lib32 (i.e. ld-elf32.so.1 + /usr/lib32).
  
> Regarding 2) (which I believe Jan was referring to), when I have a gcc built 
> world and just replace lib32 with clang built libraries I have winecfg and 
> regedit launching but displaying black screens.  Switching back to gcc built 
> lib32 I get a working winecfg and regedit.  This, to me, indicates a clang 
> error somewhere.

My experience varies between clang-built and gcc-built wine.

  # clang, quick crash
  $ winecfg
  err:seh:raise_exception Unhandled exception code c005 flags 0 addr 
0x622975ab
  err:seh:raise_exception Unhandled exception code c005 flags 0 addr 
0x622975ab
  err:seh:raise_exception Unhandled exception code c005 flags 0 addr 
0x622975ab
  Exit 5

  # gcc, black rectangle
  $ winecfg
  err:seh:raise_exception Unhandled exception code c005 flags 0 addr 
0x622995ab
  err:service:service_send_start_message service L"MountMgr" failed to start
  fixme:service:scmdatabase_autostart_services Auto-start service L"MountMgr" 
failed to start: 1053
  err:seh:raise_exception Unhandled exception code c005 flags 0 addr 
0x622995ab
  err:service:service_send_start_message service L"PlugPlay" failed to start
  fixme:service:scmdatabase_autostart_services Auto-start service L"PlugPlay" 
failed to start: 1053
  err:seh:raise_exception Unhandled exception code c005 flags 0 addr 
0x622995ab
  err:seh:raise_exception Unhandled exception code c005 flags 0 addr 
0x622995ab
  load: 0.89  cmd: wine 14626 [piperd] 7.49r 0.03u 0.01s 0% 8932k

So, why not switch stack alignment in wine (upstream)? This would make
/stable/9 wine package continue to work on /head.

Here's my wine package built with and without the patch.

# sha256: cef5e543a5c534acb7237634224561863122ab3c256df319c6428856266d79fd
http://ompldr.org/vZzR0bw/4byte-clang-wine-fbsd64-1.5.16,1.txz
# sha256: 68e402bf7cb39ea48b9bef7772422cf476e89b214fd3b98ced37e0068f588c6c
http://ompldr.org/vZzR0ZA/16byte-clang-wine-fbsd64-1.5.16,1.txz

# include, winegcc: Switch to 16-byte aligned stack on FreeBSD.
#
# We cannot use __clang__ or __FreeBSD_version in order to stay
# compatible where a package built for FreeBSD X also works on
# FreeBSD X+1.

--- include/windef.h~
+++ include/windef.h
@@ -53,7 +53,8 @@ extern "C" {
 #ifndef __stdcall
 # ifdef __i386__
 #  ifdef __GNUC__
-#   ifdef __APPLE__ /* Mac OS X uses a 16-byte aligned stack and not a 4-byte one */
+/* Mac OS X and FreeBSD 10 use a 16-byte aligned stack and not a 4-byte one */
+#   if defined(__APPLE__) || defined(__FreeBSD__)
 #define __stdcall __attribute__((__stdcall__)) __attribute__((__force_align_arg_pointer__))
 #   else
 #define __stdcall __attribute__((__stdcall__))
--- include/msvcrt/crtdefs.h~
+++ include/msvcrt/crtdefs.h
@@ -44,7 +44,8 @@
 #ifndef __stdcall
 # ifdef __i386__
 #  ifdef __GNUC__
-#   ifdef __APPLE__ /* Mac OS X uses a 16-byte aligned stack and not a 4-byte one */
+/* Mac OS X and FreeBSD 10 use a 16-byte aligned stack and not a 4-byte one */
+#   if defined(__APPLE__) || defined(__FreeBSD__)
 #define __stdcall __attribute__((__stdcall__)) __attribute__((__force_align_arg_pointer__))
 #   else
 #define __stdcall __attribute__((__stdcall__))
--- tools/winegcc/utils.h~
+++ tools/winegcc/utils.h
@@ -42,7 +42,7 @@ enum target_cpu
 
 enum target_platform
 {
-PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_SOLARIS, PLATFORM_WINDOWS, PLATFORM_CYGWIN
+PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_FREEBSD, PLATFORM_SOLARIS, PLATFORM_WINDOWS, PLATFORM_CYGWIN
 };
 
 void error(const char* s, ...) DECLSPEC_NORETURN;
--- tools/winegcc/winegcc.c~
+++ tools/winegcc/winegc

Re: November 5th is Clang-Day

[Jan Beich]

Brooks Davis  writes:

> Known Issues

emulators/wine doesn't work with lib32 built by clang, probably due to
wine bugs.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCH] unbreak XDM build when clang set as base compiler

[Jan Beich]

Oliver Pinter  writes:

> +# XXX unbreak build with clang as CC
> +BUILD_DEPENDS+= ucpp:${PORTSDIR}/devel/ucpp
> +RUN_DEPENDS+=   ucpp:${PORTSDIR}/devel/ucpp
> +CONFIGURE_ENV+=  ac_cv_path_RAWCPP="ucpp -s"

ucpp is even less compatible with GNU cpp:
- escaped newline is not recognized (Xreset, Xstartup)
- extra whitespace around expanded macro (Xresources, Xservers)
- apostrophe is treated differently (Xsession)

Another example is libX11 or ports/166373.

--- config/Xreset   cpp47
+++ config/Xreset   ucpp
@@ -1,4 +1,6 @@
 #!/bin/sh
 # Deregister a login. (Derived from TakeConsole as follows:)
 #
-/usr/local/bin/sessreg -d -w /var/log/wtmp -u /var/run/utmp-x 
/usr/local/lib/X11/xdm/Xservers -l $DISPLAY -h "" $USER
+ /usr/local/bin /sessreg -d -w  /var/log/wtmp  -u  /var/run/utmp   
+-x /usr/local/lib/X11/xdm/Xservers -l $DISPLAY -h "" $USER
+
--- config/Xresources   cpp47
+++ config/Xresources   ucpp
@@ -2,17 +2,17 @@ Xcursor.theme: whiteglass
 
 
 
-xlogin*login.translations: #override \
-   CtrlR: abort-display()\n\
-   F1: set-session-argument(failsafe) finish-field()\n\
-   Delete: delete-character()\n\
-   Left: move-backward-character()\n\
-   Right: move-forward-character()\n\
-   Home: move-to-begining()\n\
-   End: move-to-end()\n\
-   CtrlKP_Enter: set-session-argument(failsafe) finish-field()\n\
-   KP_Enter: set-session-argument() finish-field()\n\
-   CtrlReturn: set-session-argument(failsafe) finish-field()\n\
+xlogin*login.translations: #override  \ 
+   CtrlR: abort-display() \n\ 
+   F1: set-session-argument(failsafe) finish-field() \n\ 
+   Delete: delete-character() \n\ 
+   Left: move-backward-character() \n\ 
+   Right: move-forward-character() \n\ 
+   Home: move-to-begining() \n\ 
+   End: move-to-end() \n\ 
+   CtrlKP_Enter: set-session-argument(failsafe) finish-field() \n\ 
+   KP_Enter: set-session-argument() finish-field() \n\ 
+   CtrlReturn: set-session-argument(failsafe) finish-field() \n\ 
Return: set-session-argument() finish-field()
 
 xlogin*greeting: Welcome to CLIENTHOST
@@ -60,9 +60,9 @@ xlogin*hiColor: black
 #endif
 
 #if PLANES >= 8
-xlogin*logoFileName: /usr/local/lib/X11/xdm/pixmaps/xorg.xpm
+xlogin*logoFileName:  /usr/local/lib/X11/xdm/pixmaps  / xorg.xpm 
 #else
-xlogin*logoFileName: /usr/local/lib/X11/xdm/pixmaps/xorg-bw.xpm
+xlogin*logoFileName:  /usr/local/lib/X11/xdm/pixmaps  / xorg-bw.xpm 
 #endif
 xlogin*useShape: true
 xlogin*logoPadding: 10
@@ -80,3 +80,4 @@ Chooser*label.font:   *-new century schoo
 Chooser*label.label:   XDMCP Host Menu from CLIENTHOST
 Chooser*list.font: -*-*-medium-r-normal-*-*-230-*-*-c-*-iso8859-1
 Chooser*Command.font:  *-new century schoolbook-bold-r-normal-*-180-*
+
--- config/Xservers cpp47
+++ config/Xservers ucpp
@@ -9,4 +9,5 @@
 # look like:
 #  XTerminalName:0 foreign
 #
-:0 local /usr/local/bin/X :0 
+:0 local  /usr/local/bin /X :0   
+
--- config/Xsession cpp47
+++ config/Xsession ucpp
@@ -1,49 +0,0 @@
-#!/bin/sh
-#
-
-# redirect errors to a file in user's home directory if we can
-
-errfile="$HOME/.xsession-errors"
-if ( umask 077 && cp /dev/null "$errfile" 2> /dev/null )
-then
-   exec > "$errfile" 2>&1
-else
-
-   mktemp=/usr/bin/mktemp
-   for errfile in "${TMPDIR-/tmp}/xses-$USER" "/tmp/xses-$USER"
-   do
-   if ef="$( umask 077 && $mktemp "$errfile.XX" 2> /dev/null)"
-   then
-   exec > "$ef" 2>&1
-   mv "$ef" "$errfile" 2> /dev/null
-   break
-   fi
-   done
-fi
-
-case $# in
-1)
-   case $1 in
-   failsafe)
-   exec /usr/local/bin/xterm -geometry 80x24-0-0
-   ;;
-   esac
-esac
-
-# The startup script is not intended to have arguments.
-
-startup=$HOME/.xsession
-resources=$HOME/.Xresources
-
-if [ -s "$startup" ]; then
-   if [ -x "$startup" ]; then
-   exec "$startup"
-   else
-   exec /bin/sh "$startup"
-   fi
-else
-   if [ -r "$resources" ]; then
-   /usr/local/bin/xrdb -load "$resources"
-   fi
-   exec /usr/local/bin/xsm
-fi
--- config/Xstartup cpp47
+++ config/Xstartup ucpp
@@ -1,4 +1,6 @@
 #!/bin/sh
 # Register a login (derived from GiveConsole as follows:)
 #
-exec /usr/local/bin/sessreg  -a -w /var/log/wtmp -u /var/run/utmp  -x 
/usr/local/lib/X11/xdm/Xservers -l $DISPLAY -h "" $USER
+exec  /usr/local/bin /sessreg  -a -w  /var/log/wtmp  -u  /var/run/utmp 
+-x /usr/local/lib/X11/xdm/Xservers -l $DISPLAY -h "" $USER
+
--- config/xdm  cpp47
+++ config/xdm  ucpp
@@ -9,20 +9,20 @@
 
 
 
-DisplayManager.authDir:/var/lib/xdm
-DisplayManager.errorLogFile:   /var/log/xdm.log
-DisplayManager.pidFile:/var/run/xdm.pid
+DisplayManager.authDir: /var/lib/xdm 
+DisplayManager.errorLogFile:/va

Re: Clang as default compiler November 4th

[Jan Beich]

Doug Barton  writes:

> On 09/11/2012 02:52 AM, Erik Cederstrand wrote:
>> So can we do a sweep on the ports tree and mark the 2232 ports with 
>> USE_GCC=4.2 until they can actually build with clang?
>
> Unfortunately it isn't that simple. We already have a statistically
> significant number of ports that don't even compile with gcc 4.2.1. How
> many compilers do we expect the users to install? :)
>
> What we need to do is what I and others have been asking to do for
> years. We need to designate a modern version of gcc (no less than 4.6)
> as the official default ports compiler, and rework whatever is needed to
> support this. Fortunately, that goal is much more easily achieved than
> fixing ports to build and run with clang. (It's harder than it sounds
> because there are certain key libs that define some paths depending on
> what compiler they were built with, but still easier than dealing with
> clang in the short term.)

To that effect ports also need to respect CC/CXX. There were a few -exp
runs without /usr/bin/{cc,gcc,etc} to find out non-conforming ones as
part of ports/159117. However, the issue was quickly shoved under the
carpet in order to focus on the more important, clang as default.

# last try, assumes_gcc are ports ignoring CC/CXX, many are fixed
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/index-reason.html

>
> Once that is done, the compiler in the base is an afterthought, and we
> can do away with gcc in the base altogether much more easily. Users who
> want to help support building ports with clang can continue to do so.
>
> Doug

--
Ignoring for the moment clang -exp runs are *still* done with clang 3.0
while we're discussing here clang 3.2 becoming default.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

fetch(1) fails with https:// - Authentication error

[Jan Beich]

It seems recent OpenSSL update broke fetch(1) for me.

  $ diff -u $SRC_BASE/crypto/openssl/apps/openssl.cnf /etc/ssl/openssl.cnf
  $ fetch https://foo/bar
  fetch: https://foo/bar: Authentication error

Same error as with the patch for 1.0.0d from a year ago and
same workaround - s/SSLv23_client_method/SSLv3_client_method/.

--
FreeBSD 10.0-CURRENT #0 r238415: Fri Jul 13 07:18:02 UTC 2012
foo@bar:/home/blah/.cache/a/freebsd/sys/a/misc/MODULAR amd64

world built with clang
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFC/CFT] large changes in the loader(8) code

[Jan Beich]

"Andrey V. Elsukov"  writes:

> On 29.06.2012 15:01, Jan Beich wrote:
>
>>>> So, i have created the branch and committed the changes:
>>>>http://svnweb.freebsd.org/base/user/ae/bootcode/
>>>> The patch is here:
>>>>http://people.freebsd.org/~ae/boot.diff
>>>
>>> FWIW, I verified it compiles OK with clang, and especially boot2's size
>>> isn't increased at all.
>> Does it boot for you? Same if I build zfs.c with gcc -O0:
>> 
>>   FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1
>>   (foo@bar, Tue Jun 26 18:52:52 UTC 2012)
>>   ZFS: can't find pool by guid
>>   ZFS: can't find pool by guid
>> 
>>   can't load 'kernel'
>> 
>
> Does zfsloader without patches compiled with CLANG work for you?

It does. I did test before using

  $ cd /usr/src/sys/boot
  $ env -i __MAKE_CONF= PATH=/bin:/sbin:/usr/bin:/usr/sbin make CC=clang
  $ make install
  
  $ sudo qemu-system-x86_64 -curses -drive file=/dev/ada0 -drive file=/dev/ada1

In gcc -O0 case

  $ touch zfs/zfs.c
  $ rm i386/zfsloader/zfsloader*
  $ echo CFLAGS+=-O0 >>zfs/Makefile
  $ env -i ... make CC=gcc

And for gcc47
  
  $ touch zfs/zfs.c
  $ rm i386/zfsloader/zfsloader*
  $ env -i ... make CC=/usr/local/bin/gcc47 -C zfs

I haven't tried to further track down which flag(s) within -O1 make
zfsloader from your branch work when compiled with base gcc.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFC/CFT] large changes in the loader(8) code

[Jan Beich]

Dimitry Andric  writes:

> On 2012-06-26 14:50, Andrey V. Elsukov wrote:
>
>> Some time ago i have started reading the code in the sys/boot.
>> Especially i'm interested in the partition tables handling.
>> I found several problems:
>> 1. There are several copies of the same code in the libi386/biosdisk.c
>> and common/disk.c, and partially libpc98/biosdisk.c.
>> 2. ZFS probing is very slow, because the ZFS code doesn't know how many
>> disks and partitions the system has:
>>  http://www.freebsd.org/cgi/query-pr.cgi?pr=148296
>>  http://www.freebsd.org/cgi/query-pr.cgi?pr=161897
>> 3. The GPT support doesn't check CRC and even doesn't know anything
>> about the secondary GPT header/table.
>> 
>> So, i have created the branch and committed the changes:
>>  http://svnweb.freebsd.org/base/user/ae/bootcode/
>> The patch is here:
>>  http://people.freebsd.org/~ae/boot.diff
>
> FWIW, I verified it compiles OK with clang, and especially boot2's size
> isn't increased at all.

Does it boot for you? Same if I build zfs.c with gcc -O0:

  FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1
  (foo@bar, Tue Jun 26 18:52:52 UTC 2012)
  ZFS: can't find pool by guid
  ZFS: can't find pool by guid

  can't load 'kernel'

>
> It would be nice if you could check it with clang now and again, before
> you finally merge this project into head.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Default directory used for 'zpool import' broken (/dev/dsk)?

[Jan Beich]

Andriy Gapon  writes:

> on 14/05/2012 19:11 Andriy Gapon said the following:
>
>> on 14/05/2012 18:19 Fabian Keil said the following:
>>> The following patch seems to work for me:
>>>
>>> 
>>> commit 7ec69700f2d6944a61f5c7a826e67f46fa160221
>>> Author: Fabian Keil 
>>> Date:   Mon May 12 16:53:56 2012 +0200
>>>
>>> Default to searching vdevs in /dev. /dev/dsk doesn't exist on FreeBSD.
>>> 
>>> Fixes import issues if no cachefile exists and -d isn't used:
>>> 
>>> fk@r500 ~ $sudo zpool import wde2
>>> cannot open '/dev/dsk': must be an absolute path
>> 
>> Hah, so this hasn't been fixed actually.
>> Thank you for the patch!
>> 
>>> diff --git a/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c 
>>> b/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c
>>> index fe76250..5d1e454 100644
>>> --- a/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c
>>> +++ b/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c
>>> @@ -1909,7 +1909,7 @@ zpool_do_import(int argc, char **argv)
>>>  
>>> if (searchdirs == NULL) {
>>> searchdirs = safe_malloc(sizeof (char *));
>>> -   searchdirs[0] = "/dev/dsk";
>>> +   searchdirs[0] = "/dev";
>>> nsearch = 1;
>>> }
>>> 
>>>
>>> The cachefile part is speculation ...
>> 
>> 
>
> Not sure if the following is also necessary, but it looks like it
> makes sense:

It looks like bin/155104 which affects zdb -e.

>
> --- a/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c
> +++ b/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c
> @@ -1145,7 +1145,7 @@ zpool_find_import_impl
>   char *end, **dir = iarg->path;
>   size_t pathleft;
>   nvlist_t *ret = NULL;
> - static char *default_dir = "/dev/dsk";
> + static char *default_dir = "/dev";
>   pool_list_t pools = { 0 };
>   pool_entry_t *pe, *penext;
>   vdev_entry_t *ve, *venext;
>
> I am not sure if zpool_find_import_impl is ever called with empty/zero
> paths/path in the importargs_t parameter.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFT] Major snd_hda rewrite

[Jan Beich]

Alexander Motin  writes:

> I would like request for testing of my work on further HDA sound
> driver improvement.
[...]
>  - Codec pins and GPIO signals configuration was exported via set of
> writable sysctls. Another sysctl dev.hdaa.X.reconfig allows to trigger
> driver reconfiguration in run-time. The only requirement is that all
> pcm devices should be closed at the moment, as they will be destroyed
> and recreated. This should significantly simplify process of fixing
> CODEC configuration. It should be possible now even to write GUI to do
> it with few mouse clicks.

reconfig seems to not honor hw.snd.default_unit sysctl. After
reconfiguration the sysctl was reset to `0' (default). Is this expected?
Even if it is specified as a tunable in loader.conf?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Heads up: New C++ stack

[Jan Beich]

David Chisnall  writes:

[...]
> libcxxrt and libc++ are now in contrib and building with the base
> system, but are not used by anything (and are only built if you set
> WITH_LIBCPLUSPLUS=yes when building world, not by default).  If you
> want to test some code with the new stack, you need to build it and
> then specify -stdlib=libc++ to clang++ (both when compiling and
> linking).

Does the option work when building world with -jX ?

  $ make -sj2 buildworld
  [...]
  ===> lib/libcompiler_rt (obj,depend,all,install)
  ===> lib/libc (obj,depend,all,install)
  ===> lib/libcxxrt (obj,depend,all,install)
  /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
  clang: error: linker command failed with exit code 1 (use -v to see 
invocation)
  *** [libcxxrt.so.1] Error code 1

And later in silent build --verbose in LDFLAGS for libc++ produces noise
that's neither a warning nor a build directory.

  ===> lib/libcxxrt (all)
  ===> lib/libc++ (all)
  FreeBSD clang version 3.0 (tags/RELEASE_30/final 145349) 20111210
  Target: x86_64-unknown-freebsd10.0
  Thread model: posix
   "/usr/obj/usr/src/tmp/usr/bin/ld" --eh-frame-hdr -Bshareable -o libc++.so.1 
/usr/obj/usr/src/tmp/usr/lib/crti.o /usr/obj/usr/src/tmp/usr/lib/crtbeginS.o 
-L/usr/obj/usr/src/lib/libc++/../libcxxrt/ -L/usr/obj/usr/src/tmp/usr/lib -x 
--fatal-warnings --warn-shared-textrel -soname libc++.so.1 valarray.So 
utility.So strstream.So regex.So random.So iostream.So debug.So chrono.So 
bind.So algorithm.So hash.So thread.So future.So new.So locale.So typeinfo.So 
mutex.So memory.So ios.So condition_variable.So system_error.So string.So 
stdexcept.So exception.So -lcxxrt -lgcc --as-needed -lgcc_s --no-as-needed -lc 
-lgcc --as-needed -lgcc_s --no-as-needed /usr/obj/usr/src/tmp/usr/lib/crtendS.o 
/usr/obj/usr/src/tmp/usr/lib/crtn.o
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 10.0-CURRENT/AMD64 (CLANG): lang/gcc46 fails to build

[Jan Beich]

"O. Hartmann"  writes:

> .././../gcc-4.6-20111202/libcpp/charset.c:1371:1: error: conflicting
> types for 'cpp_interpret_string'
> cpp_interpret_string (cpp_reader *pfile, const cpp_string *from, size_t
> count,
> ^
> .././../gcc-4.6-20111202/libcpp/include/cpplib.h:742:13: note: previous
> declaration is here
> extern bool cpp_interpret_string (cpp_reader *,
> ^

Have you built world WITH_ICONV= ? Try the 2nd patch in ports/161417.
ports/163103 confirms the issue is not related to clang, nor 10-CURRENT.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: bsdgrep --null has no effect

[Jan Beich]

Jan Beich  writes:

> "O. Hartmann"  writes:
>
>> ===>  Patching for stellarium-0.11.1
>> sed:
>> /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/core/external/fixx11h.h
>> /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/CMakeLists.txt
>> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TelescopeControl/src/TelescopeControl.hpp
>> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Oculars/src/Oculars.hpp
>> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/CompassMarks/src/CompassMarks.hpp
>> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TextUserInterface/src/TextUserInterface.hpp
>> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Supernovae/src/Supernovae.hpp
>> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/SolarSystemEditor/src/SolarSystemEditor.hpp
>> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Satellites/src/Satellites.hpp
>> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/HelloStelModule/src/HelloStelModule.hpp
>> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TimeZoneConfiguration/src/TimeZoneConfiguration.hpp
>> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasure/src/AngleMeasure.hpp
>> : File name too long
>> *** Error code 1
>
> Do you use bsdgrep? ${GREP} -Rl --null ... | ${XARGS} -0 ... won't work.
>
>   $ gnugrep -l --null . /usr/include/md*.h | vis
>   /usr/include/md2.h\^@/usr/include/md4.h\^@/usr/include/md5.h\^@
>
>   $ bsdgrep -l --null . /usr/include/md*.h | vis
>   /usr/include/md2.h
>   /usr/include/md4.h
>   /usr/include/md5.h

Oops, here is a diff. Non -l/-L case still seems to be broken.

  $ echo t >a; echo t >b; echo t >c
  $ gnugrep --null . ? | vis
  a\^@t
  b\^@t
  c\^@t

  $ bsdgrep --null . ? | vis
  a\^@:t
  b\^@:t
  c\^@:t

Index: usr.bin/grep/util.c
===
--- usr.bin/grep/util.c (revision 228003)
+++ usr.bin/grep/util.c (working copy)
@@ -246,9 +246,9 @@ procfile(const char *fn)
printf("%u\n", c);
}
if (lflag && !qflag && c != 0)
-   printf("%s\n", fn);
+   printf("%s%c", fn, nullflag ? 0 : '\n');
if (Lflag && !qflag && c == 0)
-   printf("%s\n", fn);
+   printf("%s%c", fn, nullflag ? 0 : '\n');
if (c && !cflag && !lflag && !Lflag &&
binbehave == BINFILE_BIN && f->binary && !qflag)
printf(getstr(8), fn);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

bsdgrep --null has no effect (Was: port astro/stellarium: /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasure/src/AngleMeasure.hpp, : File name too long, *** Error code 1)

[Jan Beich]

(add gabor@ to CC, drop questions@)

"O. Hartmann"  writes:

> ===>  Patching for stellarium-0.11.1
> sed:
> /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/core/external/fixx11h.h
> /usr/ports/astro/stellarium/work/stellarium-0.11.1/src/CMakeLists.txt
> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TelescopeControl/src/TelescopeControl.hpp
> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Oculars/src/Oculars.hpp
> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/CompassMarks/src/CompassMarks.hpp
> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TextUserInterface/src/TextUserInterface.hpp
> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Supernovae/src/Supernovae.hpp
> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/SolarSystemEditor/src/SolarSystemEditor.hpp
> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/Satellites/src/Satellites.hpp
> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/HelloStelModule/src/HelloStelModule.hpp
> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/TimeZoneConfiguration/src/TimeZoneConfiguration.hpp
> /usr/ports/astro/stellarium/work/stellarium-0.11.1/plugins/AngleMeasure/src/AngleMeasure.hpp
> : File name too long
> *** Error code 1

Do you use bsdgrep? ${GREP} -Rl --null ... | ${XARGS} -0 ... won't work.

  $ gnugrep -l --null . /usr/include/md*.h | vis
  /usr/include/md2.h\^@/usr/include/md4.h\^@/usr/include/md5.h\^@

  $ bsdgrep -l --null . /usr/include/md*.h | vis
  /usr/include/md2.h
  /usr/include/md4.h
  /usr/include/md5.h
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ee (easy editor) bugged on 9.0?

[Jan Beich]

Jason Edwards  writes:

> Has anyone noticed the easy editor is quite bugged on 9.0? On console
> direct access, opening the easy editor has several bugs:
>
> 1) the cursor starts on line 2 instead of line 1
> 2) the line numbering is printed on line 1 instead of the boundary (line 0)
> 3) the keys page up and page down bring the escape menu

Try to use cons25 emulation beforehand

  $ vidcontrol -T cons25 # aka TEKEN_CONS25 in kernel config

unless you've updated etc/ttys to use `xterm'.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [Sbcl-bugs] crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread

[Jan Beich]

Nikodemus Siivola  writes:

>> After r216641 sbcl built with sb-thread dies on mailbox tests. It also
>> dies when I try to complete a symbol in slime. The workaround seems to
>> be to revert libthr to r216640.
>
>> Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@
>> in case it's the latter one.
>
> I find it quite possible that this was an SBCL bug.
>
> It would be much appreciated if you could try with current HEAD from
> SBCL's git repository if it makes things better.

I've tried git master (as of d0d44cc) and sb-thread build passes fine,
mailbox.interrupts-safety.1 test no longer hangs. Also tried on
stumpwm + slime (:spawn) setup, it no longer crashes.

--
FreeBSD 10.0-CURRENT r227674M amd64
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"