Re: regression suspend/resume on Lenovo T420

2017-05-14 Thread Poul-Henning Kamp

In message <20170514193006.GA1298@brick>, Edward Tomasz =?utf-8?Q?Napiera=C5=82
a?= writes:

>I've tried to verify that, and sadly it wasn't it for me.  The commit
>that does break resume for me is r316767.  The current -CURRENT with
>this one commit reverted ("svn merge -c -r316767 .") suspends and resumes
>correctly, at least in VT; I decided to take X out of the picture for
>now.

I can confirm that this also makes resume work on my T430s running:

FreeBSD 12.0-CURRENT #0 r318250M amd64

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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 suspend/resume on Lenovo T420

2017-05-14 Thread Edward Tomasz Napierała
On 0506T1103, Manuel Stühn wrote:
> On Sat, May 06, 2017 at 10:52:56AM +0200, Manuel Stühn wrote:
> >On Wed, 03 May 2017 22:28:41 +0200, Freebsdnewbie wrote
> >>
> >>> Von: Adrian Chadd
> >>> Gesendet: Mo. 01.05.2017 23:31
> >>> An: Manuel Stühn ,
> >>> Kopie: freebsd-current ,
> >>> Betreff: Re: regression suspend/resume on Lenovo T420
> >>>
> >>> There were lots of commits that could break things. :-)
> >>>
> >>>
> >>> Can you compile up some intermediary versions between 315141 and
> >>> r317559 to find which commit range broke things? That'll make chasing
> >>> it down much quicker!
> >>>
> >>
> >> I'm following your advice and building some intermediary versions. This 
> >> will take some time...
> >
> >So, after keep building some more worlds i've discovered the commit
> >after which resume does not work anymore. r316736 is the last working
> >one, r316737 breaks it for me (There is also no mouse cursor on the
> >console anymore after this commit).
> 
> Sorry, my fault: r316734 was the last working revision!!

I've tried to verify that, and sadly it wasn't it for me.  The commit
that does break resume for me is r316767.  The current -CURRENT with
this one commit reverted ("svn merge -c -r316767 .") suspends and resumes
correctly, at least in VT; I decided to take X out of the picture for
now.

There is still the issue of backlight being off after resume in VT; one
needs to switch consoles to restore it, but it's 1. minor and 2. broken
for a really long time now.  There's also another problem, which kind
of looks like an inability to resume if the machine is hot (as in,
thermally), but this might be just because of its age.

___
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"


Mplayer on CURRENT: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"

2017-05-14 Thread O. Hartmann
On recent CURRENT, FreeBSD 12.0-CURRENT #82 r318277: Sun May 14 19:34:54 CEST 
2017 amd64,
with WITH_LLD_IS_LD=yes set, mplayer rejects to work and
fails to start and quits immediately with:

 /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"

I already tried to recompile mplayer with "portmaster -df" to hit all ports 
required or
especially recompiled libglib-2.0, but without success. Its strange ...

Is there any hint?

Kind regards and thanks in advance,

O. Hartmann
-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpnggugMfRW8.pgp
Description: OpenPGP digital signature


Re: DTB provided by loader.efi from head -r317181 on pine64 smashed by zfs.ko ?

2017-05-14 Thread Henri Hennebert

On 05/09/2017 12:07, Henri Hennebert wrote:

Hello,

I build current -r317181 with crochet for my PINE64.

the kernel can boot with loader.conf.local:

geom_mirror_load="YES"

If I add to loader.conf.local:

zfs_load="YES"

or if I strike the space bar during loader.efi and I load zfs manually:

OK load zfs
...
OK boot
With a slimmed down kernel config, I can load zfs.ko and boot the kernel 
BUT opensolaris is not loaded and I get at kernel boot:


OK load zfs
/boot/kernel/zfs.ko text=0x9d980 text=0xe0480 data=0x214c8+0x9eb78 
syms=[0x8+0x1d6a0+0x8+0x187bd]

OK boot
Booting...
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #0 r317181M: Sun May 14 14:01:52 CEST 2017
r...@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on 
LLVM 4.0.0)

VT: init without driver.
KLD file zfs.ko is missing dependencies
Starting CPU 1 (1)
Starting CPU 2 (2)
Starting CPU 3 (3)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
random: unblocking device.


note the message:
KLD file zfs.ko is missing dependencies



the kernel don't boot and the console stay with the last line:

Using DTB provided by EFI at 0x4900.

Moreover the opensolaris.ko is not loader.

Maybe DTB is smashed by zfs.ko

Any idea ?

Henri

PS with r312006M from RaspBSD all is OK and I can user zfs as root 
filesystem.

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


___
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"


misc/mc, diff and compare two files

2017-05-14 Thread Boris Samorodov

Hi All,

FYI: For those who use FreeBSD-HEAD, misc/mc and it's awesome "compare
two files" feature:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219277

HTH
--
WBR, bsam
___
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"


[Bug 218849] Remove rc.conf jail configuration via jail_* variables

2017-05-14 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849

Thomas Steen Rasmussen / Tykling  changed:

   What|Removed |Added

 CC||tho...@gibfest.dk

--- Comment #25 from Thomas Steen Rasmussen / Tykling  ---
I believe the only reason the original poster insists on removing this now is
to deliberately break ezjail, so people will switch to his qjail tool rather
than stay with ezjail. Obviously this kind of behaviour does not belong here.

_Please_ keep the compatibility code in place until something else has been
sorted.

To solve ezjails problem of jail.conf being difficult to manage from sh scripts
erdgeist (ezjail author) offered to extend jail(8) with config file management
capabilities earlier in this thread. I do suggest we take him up on the offer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"


ports-mgmt/pkg_rmleaves stops working properly on -head after bsdiff became default diff (r317209)

2017-05-14 Thread Tomoaki AOKI
Hi.
Posting on freebsd-current as this only affects -head.

I recently noticed ports-mgmt/pkg_rmleaves failes to process
new leaf ports after removal of leaf ports on -head with error
messages below.

> diff: unrecognized option `--unchanged-line-format='
> usage: diff [-abdilpTtw] [-c | -e | -f | -n | -q | -u] [--ignore-case]
> [--no-ignore-case] [--normal] [--strip-trailing-cr]
> [--tabsize] [-I pattern] [-L label] file1 file2
>diff [-abdilpTtw] [-I pattern] [-L label] [--ignore-case]
> [--no-ignore-case] [--normal] [--strip-trailing-cr]
> [--tabsize] -C number file1 file2
>diff [-abdiltw] [-I pattern] [--ignore-case] [--no-ignore-case]
> [--normal] [--strip-trailing-cr] [--tabsize] -D string
> file1 file2 diff [-abdilpTtw] [-I pattern] [-L label] [--ignore-case]
> [--no-ignore-case] [--normal] [--tabsize]
> [--strip-trailing-cr] -U number file1 file2
>diff [-abdilNPprsTtw] [-c | -e | -f | -n | -q | -u]
> [--ignore-case] [--no-ignore-case] [--normal] [--tabsize] [-I pattern]
> [-L label] [-S name] [-X file] [-x pattern] dir1 dir2

stable/11 was OK, and the difference is that stable/11 has gnu diff
as diff, while -head has bsdiff as diff.

There's 2 (or possibly 3) options.

 a) Let pkg_rmleaves use gnu diff via textprocs/diffutils.
This is easiest (Minimal diff is attached), but doesn't help
any other ports affected. Just change diff to gdiff and RUN_DEPENDS
on textproc/diffutils.

 b) Update bsdiff to support missing options below.
This is over my hand, but if possible, would help others.

 c) If the missing options below are implemented as different
(non-documented) options on bsdiff, use them for bsdiff instead.
Will need OSVERSION check in ports Makefile.

Please note that attached diff is really MINIMAL to work on -head.
No OSVERSION switching is implemented and no bumps so forcibly
installs textproc/diffutils on revisions with gnu diff is /usr/bin/diff.
And patch wouldn't work properly as files directory doesn't exist
in pkg-mgmt/pkg_rmleaves. (At least system patch.)

I wonder which option should be taken, so not yet filed PR on bugzilla.
It should be filed differently with which option is taken.

-- 
Tomoaki AOKI
diff -u -r -P -p ports-mgmt/pkg_rmleaves/Makefile.orig ports-mgmt/pkg_rmleaves/Makefile
--- ports-mgmt/pkg_rmleaves/Makefile.orig	2015-09-09 02:00:03.629555000 +0900
+++ ports-mgmt/pkg_rmleaves/Makefile	2017-05-14 02:20:31.547549000 +0900
@@ -13,6 +13,8 @@ LICENSE=	BSD2CLAUSE
 
 NO_BUILD=	yes
 
+RUN_DEPENDS=	gdiff:textproc/diffutils
+
 WRKSRC=		${WRKDIR}
 
 PLIST_FILES=	sbin/pkg_rmleaves man/man1/pkg_rmleaves.1.gz
diff -u -r -P -p ports-mgmt/pkg_rmleaves/files/patch-pkg_rmleaves.orig ports-mgmt/pkg_rmleaves/files/patch-pkg_rmleaves
--- ports-mgmt/pkg_rmleaves/files/patch-pkg_rmleaves.orig	1970-01-01 09:00:00.0 +0900
+++ ports-mgmt/pkg_rmleaves/files/patch-pkg_rmleaves	2017-05-14 02:22:57.050609000 +0900
@@ -0,0 +1,11 @@
+--- pkg_rmleaves.orig	2014-02-22 21:21:47.0 +0900
 pkg_rmleaves	2017-05-14 02:16:55.751443000 +0900
+@@ -74,7 +74,7 @@ checkLeafs() {
+ 	fi | sort | sed -e "y/\"/'/" -e 's/#"#/"/g' > "$PKGFILE"
+ 
+ 	if [ -f "$PREV" ]; then
+-		diff --unchanged-line-format='' --old-line-format='' --new-line-format='%L' "$PREV" "$PKGFILE" > "$TMPFILE"
++		gdiff --unchanged-line-format='' --old-line-format='' --new-line-format='%L' "$PREV" "$PKGFILE" > "$TMPFILE"
+ 	else
+ 		cp "$PKGFILE" "$TMPFILE"
+ 	fi
___
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: more default uid/gid for NFS in mountd

2017-05-14 Thread Slawa Olhovchenkov
On Sun, May 14, 2017 at 01:12:11AM +, Rick Macklem wrote:

> >> It is also the case that mountd.c doesn't look "nobody" up in the password 
> >> database
> >> to set the default. It would be nice to do this, but it could result in 
> >> the mountd daemon
> >> getting "stuck" during a boot waiting for an unresponsive LDAP service or 
> >> similar.
> >> Does doing this sound like a good idea?
> >
> >This is (stuck at boot) already do for case of using NIS and nfsuserd.
> There is a difference here. nfsuserd mpas between uid/names, so it can't work
> without the password database.
> mountd can work without the password database, so I held off on doing this 
> for now.
> 
> >I am regular see this for case of DNS failed at boot.
> >You offer don't impair current behaviour.
> As an aside, if you have the critical entries in the local files (/etc/hosts, 
> /etc/passwd,
> /etc/group) and then tell the libraries to search these first in 
> /etc/nsswitch.conf, then
> you usually avoid this problem.

Same as for 'nobody' for mountd?

> Thanks for the comments, rick
> 

Thanks!
___
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"