Re: sysutils/openzfs-kmod installed from poudriere repo but not recognised as a non-automatic package
On 16/12/2020 03:33, Graham Perrin wrote: Do I misunderstand something below? root@mowa219-gjp4-8570p:~ # pkg query '%o %R' | grep poudriere | grep zfs | sort sysutils/openzfs-kmod poudriere root@mowa219-gjp4-8570p:~ # pkg query -e '%a = 0' '%o %R' | grep poudriere | sort archivers/zip poudriere devel/autoconf poudriere devel/ccache poudriere devel/cmake poudriere devel/gmake poudriere graphics/drm-kmod poudriere graphics/gpu-firmware-kmod poudriere ports-mgmt/pkg poudriere ports-mgmt/poudriere-devel FreeBSD textproc/groff poudriere root@mowa219-gjp4-8570p:~ # pkg info openzfs-kmod openzfs-kmod-2020120100 Name : openzfs-kmod Version : 2020120100 Installed on : Tue Dec 15 19:59:00 2020 GMT Origin : sysutils/openzfs-kmod Architecture : FreeBSD:13:amd64 Prefix : /usr/local Categories : sysutils kld Licenses : CDDL Maintainer : freql...@freebsd.org WWW : https://github.com/zfsonfreebsd/ZoF Comment : OpenZFS kernel module for FreeBSD Options : DEBUG : off GCOV : off INVARIANTS : off Annotations : FreeBSD_version: 1300131 repo_type : binary repository : poudriere Flat size : 4.99MiB Description : Kernel module for OpenZFS on FreeBSD WWW: https://github.com/zfsonfreebsd/ZoF root@mowa219-gjp4-8570p:~ # I realise my mistake, hopefully: root@mowa219-gjp4-8570p:~ # pkg query -e '%a = 0' '%o %R' | grep zfs | sort sysutils/openzfs FreeBSD sysutils/zfs-snap-diff FreeBSD sysutils/zfs-stats FreeBSD root@mowa219-gjp4-8570p:~ # pkg query -e '%a = 1' '%o %R' | grep zfs | sort sysutils/openzfs-kmod poudriere root@mowa219-gjp4-8570p:~ # Originally, openzfs-kmod was automated through my _installation_ of openzfs from the FreeBSD repo. I subsequently chose to _upgrade_ (not install) openzfs-kmod from my poudriere repo, i.e. pkg upgrade -f -r poudriere sysutils/openzfs-kmod ___ 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"
sysutils/openzfs-kmod installed from poudriere repo but not recognised as a non-automatic package
Do I misunderstand something below? root@mowa219-gjp4-8570p:~ # pkg query '%o %R' | grep poudriere | grep zfs | sort sysutils/openzfs-kmod poudriere root@mowa219-gjp4-8570p:~ # pkg query -e '%a = 0' '%o %R' | grep poudriere | sort archivers/zip poudriere devel/autoconf poudriere devel/ccache poudriere devel/cmake poudriere devel/gmake poudriere graphics/drm-kmod poudriere graphics/gpu-firmware-kmod poudriere ports-mgmt/pkg poudriere ports-mgmt/poudriere-devel FreeBSD textproc/groff poudriere root@mowa219-gjp4-8570p:~ # pkg info openzfs-kmod openzfs-kmod-2020120100 Name : openzfs-kmod Version : 2020120100 Installed on : Tue Dec 15 19:59:00 2020 GMT Origin : sysutils/openzfs-kmod Architecture : FreeBSD:13:amd64 Prefix : /usr/local Categories : sysutils kld Licenses : CDDL Maintainer : freql...@freebsd.org WWW : https://github.com/zfsonfreebsd/ZoF Comment : OpenZFS kernel module for FreeBSD Options : DEBUG : off GCOV : off INVARIANTS : off Annotations : FreeBSD_version: 1300131 repo_type : binary repository : poudriere Flat size : 4.99MiB Description : Kernel module for OpenZFS on FreeBSD WWW: https://github.com/zfsonfreebsd/ZoF root@mowa219-gjp4-8570p:~ # ___ 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: Identifying broken applications following careless use of make -DBATCH_DELETE_OLD_FILES delete-old-libs
On 14/12/2020 13:20, David Wolfskill wrote: I find that "pkg_libchk" (from ports-mgmt/bsdadminscripts2) is helpful for such cases. Peace, david Thanks for this, and for the answers from other users. Ultimately I chose to: pkg upgrade -f pkg upgrade -f -r poudriere The second command was probably to broad. In retrospect I could have forced just three from my poudriere repo: drm-kmod gpu-firmware-kmod openzfs-kmod As far as I can tell, just one casualty: SimpleScreenRecorder, which does record and save, but fails to cancel (before beginning a recording) or close (after saving a recording); it stops responding. I'm now building multimedia/simplescreenrecorder with poudriere, if installation from this repo does not resolve the issue then I might repeat 'pkg upgrade -f' alone plus just the three kmods from poudriere. (Afterthought, note to self: maybe SimpleScreenRecorder is a casualty of a routine upgrade that I performed a few hours earlier; there was much KDE stuff at the time.) ___ 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: linker_load_file: /boot/kernel/ipfw.ko - unsupported file type
15.12.2020, 15:17, "Oleg V. Nauman" : > Hello, > > kernel: link_elf_obj: symbol fib6_lookup_rt undefined > kernel: linker_load_file: /boot/kernel/ipfw.ko - unsupported file type > > It seems ipf.ko unconditionally perform IPV6 lookup even on system built with > WITHOUT_INET6=YES defined Should be fixed in r368651. > FreeBSD 13.0-CURRENT r368604 amd64 > > Thank you > ___ > 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" ___ 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: usr.bin/xinstall r366697 versus: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On 12/12/20 2:15 AM, Graham Perrin wrote:
On 23/11/2020 12:18, Graham Perrin wrote:
On 22/11/2020 12:00, Dimitry Andric wrote:
…
I'd guess it's an unintended side-effect of
https://svnweb.freebsd.org/base?view=revision=366697
("install(1): Avoid unncessary fstatfs() calls and use mmap() based on
size").
If you only revert usr.bin/xinstall to r366696, and then rebuild it,
does it still occur?
-Dimitry
Thank you!
Success with r366696:
…
Re:
please, should I open a bug for this?
Is the issue exposed by my choice of gzip-9 for e.g. /usr/ and if so,
can I avoid it by (now) reverting to lz4 for that part, and/or any
other part, of the file system?
Unfortunately I don't have an answer for you at this time, but ACK.
-Ryan
root@mowa219-gjp4-8570p:~ # zfs get mountpoint,compression
NAME PROPERTY VALUE SOURCE
Transcend mountpoint /Volumes/t500 local
Transcend compression zstd
local
Transcend/VirtualBox mountpoint /Volumes/t500/VirtualBox inherited
from Transcend
Transcend/VirtualBox compression zstd inherited from Transcend
copperbowl mountpoint /copperbowl
local
copperbowl compression lz4
local
copperbowl/ROOT mountpoint
none local
copperbowl/ROOT compression lz4 inherited from copperbowl
copperbowl/ROOT/Waterfox mountpoint
/ local
copperbowl/ROOT/Waterfox compression lz4 inherited from copperbowl
copperbowl/ROOT/r367081f mountpoint
/ local
copperbowl/ROOT/r367081f compression lz4 inherited from copperbowl
copperbowl/ROOT/r367936e mountpoint
/ local
copperbowl/ROOT/r367936e compression lz4 inherited from copperbowl
copperbowl/ROOT/r367936f mountpoint
/ local
copperbowl/ROOT/r367936f compression lz4 inherited from copperbowl
copperbowl/ROOT/r367936f@2020-03-20-06:19:45 mountpoint
- -
copperbowl/ROOT/r367936f@2020-03-20-06:19:45 compression
- -
copperbowl/ROOT/r367936f@2020-11-22-23:18:47 mountpoint
- -
copperbowl/ROOT/r367936f@2020-11-22-23:18:47 compression
- -
copperbowl/ROOT/r367936f@2020-12-06-16:23:14 mountpoint
- -
copperbowl/ROOT/r367936f@2020-12-06-16:23:14 compression
- -
copperbowl/VirtualBox mountpoint
/usr/local/VirtualBox local
copperbowl/VirtualBox compression
gzip-9 local
copperbowl/iocage mountpoint /copperbowl/iocage inherited from
copperbowl
copperbowl/iocage compression
gzip-9 local
copperbowl/iocage/download mountpoint /copperbowl/iocage/download
inherited from copperbowl
copperbowl/iocage/download compression
lz4 local
copperbowl/iocage/download/12.0-RELEASE mountpoint
/copperbowl/iocage/download/12.0-RELEASE inherited from copperbowl
copperbowl/iocage/download/12.0-RELEASE compression
lz4 local
copperbowl/iocage/images mountpoint /copperbowl/iocage/images
inherited from copperbowl
copperbowl/iocage/images compression
lz4 local
copperbowl/iocage/jails mountpoint /copperbowl/iocage/jails
inherited from copperbowl
copperbowl/iocage/jails compression
lz4 local
copperbowl/iocage/jails/jbrowsers mountpoint
/copperbowl/iocage/jails/jbrowsers inherited from copperbowl
copperbowl/iocage/jails/jbrowsers compression lz4 inherited from
copperbowl/iocage/jails
copperbowl/iocage/jails/jbrowsers/root mountpoint
/copperbowl/iocage/jails/jbrowsers/root inherited from copperbowl
copperbowl/iocage/jails/jbrowsers/root compression lz4 inherited from
copperbowl/iocage/jails
copperbowl/iocage/log mountpoint /copperbowl/iocage/log inherited
from copperbowl
copperbowl/iocage/log compression
lz4 local
copperbowl/iocage/releases mountpoint /copperbowl/iocage/releases
inherited from copperbowl
copperbowl/iocage/releases compression
lz4 local
copperbowl/iocage/releases/12.0-RELEASE mountpoint
/copperbowl/iocage/releases/12.0-RELEASE inherited from copperbowl
copperbowl/iocage/releases/12.0-RELEASE compression lz4 inherited
from copperbowl/iocage/releases
copperbowl/iocage/releases/12.0-RELEASE/root mountpoint
[2 WEEKS LEFT REMINDER] Call for 2020Q4 quarterly status reports
Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is December, 31st 2021 for work done since the last round of Quarterly Reports: October 2020 - December 2020. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the Markdown template, fill it in, and email it to quarterly-submissi...@freebsd.org. The template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md We look forward to seeing your 2020Q4 reports! Thanks, Daniel Ebdrup Jensen (on behalf of quarterly@) ___ freebsd-quarterly-ca...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls To unsubscribe, send any mail to "freebsd-quarterly-calls-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"
linker_load_file: /boot/kernel/ipfw.ko - unsupported file type
Hello, kernel: link_elf_obj: symbol fib6_lookup_rt undefined kernel: linker_load_file: /boot/kernel/ipfw.ko - unsupported file type It seems ipf.ko unconditionally perform IPV6 lookup even on system built with WITHOUT_INET6=YES defined FreeBSD 13.0-CURRENT r368604 amd64 Thank you ___ 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: Identifying broken applications following careless use of make -DBATCH_DELETE_OLD_FILES delete-old-libs
Quoting Jens Schweikhardt (from Mon, 14 Dec 2020 14:15:05 +0100 (CET)): Alexander, it would seem that find /usr/local/*bin* /usr/local/lib* -type f \ | xargs ldd -f '%p|%A\n' 2>/dev/null \ | grep '^not found' | cut -d '|' -f2 \ | xargs pkg which -q | sort -u is prone to false positives, since ldd is sensitive to LD_LIBRARY_PATH, viz.: Yes. Firefox, LibreOffice/OpenOffice come to my mind directly. There may be others. I expect those to be rare (compared to the size of the ports collection), but if you encounter some false positives, it's probably a big package. Either way, "locate $missing_lib" is a good idea here. [...] So make sure you look into what exact library is missing and if it's actually somewhere "non-standard", that directory should be in LD_LIBRARY_PATH. Temporary for the run of this check, yes. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgp867e3Ceh6b.pgp Description: Digitale PGP-Signatur
Re: after update to r368166: no sound recording
> On 15. Dec 2020, at 08:44, Matthias Apitz wrote: > > El día lunes, diciembre 14, 2020 a las 10:16:21a. m. +0100, Matthias Apitz > escribió: > >> I did a step by step down grading with 'svn up -r. hdaa.c hdaa.h' >> (only these two files), starting from r368166 down to the following >> revisions: >> >> r368166: no recording from pcm1 >> >> r358333: no recording from pcm1 >> >> r350078: no recording from pcm1 >> >> r337043: recording is fine >> >> I've cc'ed now the commiters of the r358333 and r350078. kaktus@ and sbruno@ >> please check the issue >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251727 >> and this mail thread in current@ > > I have nailed down the problem and locally fixed it with this: > > # svn diff sys/dev/sound/pci/hda/hdaa.c > Index: sys/dev/sound/pci/hda/hdaa.c > === > --- sys/dev/sound/pci/hda/hdaa.c(revisión: 368166) > +++ sys/dev/sound/pci/hda/hdaa.c(copia de trabajo) > @@ -6598,6 +6598,7 @@ >devinfo->newgpo = -1; >callout_init(>poll_jack, 1); >devinfo->poll_ival = hz; > +devinfo->init_clear = 1;/* added by g...@unixarea.de */ > >hdaa_lock(devinfo); >res = hda_command(dev, > > because there seems to be no code to set devinfo->init_clear from > loader.conf; there is in hdaa.c: > > SYSCTL_ADD_INT(device_get_sysctl_ctx(dev), >SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, >"init_clear", CTLFLAG_RW, >>init_clear, 1,"Clear initial pin widget configuration"); > > but I don't see any function like hdaa_init_clear_handler() which writes > the value to devinfo->init_clear; > > Am I mistaken? > >matthias > > Good catch, I played with the sysctl as well as device.hints, both which didn’t (seem to) make a difference. -m > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub ___ 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"
