FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/eric6 | 19.04 | 20.4 +-+ devel/es-eric6 | 19.04 | 20.4 +-+ german/eric6| 19.04 | 20.4 +-+ net/boringtun | 0.2.0 | v0.3.0 +-+ russian/eric6 | 19.04 | 20.4 +-+ textproc/coccigrep | 1.17| v1.19 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: amdgpu panics
On 05/04/2020 21:58, Grzegorz Junka wrote: On 05/04/2020 13:40, Hans Petter Selasky wrote: On 2020-04-05 14:18, Grzegorz Junka wrote: How can I debug what's wrong? Can you check the timestamps for: ls -l /boot/modules and ls -l /boot/kernel That they match? Try loading like this: kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko --HPS They don't match, and they can't. Files in /boot/modules have been installed by drm-fbsd12.0-kmod and files in /boot/kernel have been installed by FreeBSD-kernel-venus-12.1_3 (venus is the name I gave the kernel configuration). I built the ports and the kernel on the same system but at different times. First I updated all sources (/usr/src and /usr/ports) then I built packages. When that didn't work, few days later I built the kernel and world. No updates to the sources have been made between those two. kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko <- doesn't work, system halts after loading one of the vega10 modules. GrzegorzJ ^ correction - port sources are of course in /usr/local/poudriere/ports, not /usr/ports ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: qt5-webengine
## Dan McGrath (danmcgrath...@gmail.com): > I swear, you find that squirrel you phone me asap! I have the warthogs > circling looking for him for at least a week now! https://cybersquirrel1.com/ Regards, Christoph -- Spare Space ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: amdgpu panics
On 05/04/2020 13:40, Hans Petter Selasky wrote: On 2020-04-05 14:18, Grzegorz Junka wrote: How can I debug what's wrong? Can you check the timestamps for: ls -l /boot/modules and ls -l /boot/kernel That they match? Try loading like this: kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko --HPS They don't match, and they can't. Files in /boot/modules have been installed by drm-fbsd12.0-kmod and files in /boot/kernel have been installed by FreeBSD-kernel-venus-12.1_3 (venus is the name I gave the kernel configuration). I built the ports and the kernel on the same system but at different times. First I updated all sources (/usr/src and /usr/ports) then I built packages. When that didn't work, few days later I built the kernel and world. No updates to the sources have been made between those two. kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko <- doesn't work, system halts after loading one of the vega10 modules. GrzegorzJ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: fetch is tarpitted by Texas Instruments and/or Akamai and can not download distfiles for TI-related ports.
On 4/5/20 11:11 AM, Julian Elischer wrote: On 4/3/20 7:39 AM, Lev Serebryakov wrote: On 03.04.2020 16:47, Kurt Jaeger wrote: I don't know, is it generic for Akamai or TI-specific. I think, somebody with official hat (FreeBSD Foundation speakperson?) should contact TI and Akamai about this situation. Faking User-Agent could be only temporary solution! I've opened a case with ti.com, CS0177749. I guess this will take some time to resolve. Someone from akamai suggests that it might be some mis-selected option selected for the CDN from akamai and that TI should get in touch with the akamai support to get it sorted. Let's see the efficiency of the free markets at work 8-) Thank you very much! I've brought this up with a friend at akamai.. He's looking into it.. Ok I see it's fixed.. called him off. Julian ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: fetch is tarpitted by Texas Instruments and/or Akamai and can not download distfiles for TI-related ports.
On 4/3/20 7:39 AM, Lev Serebryakov wrote: On 03.04.2020 16:47, Kurt Jaeger wrote: I don't know, is it generic for Akamai or TI-specific. I think, somebody with official hat (FreeBSD Foundation speakperson?) should contact TI and Akamai about this situation. Faking User-Agent could be only temporary solution! I've opened a case with ti.com, CS0177749. I guess this will take some time to resolve. Someone from akamai suggests that it might be some mis-selected option selected for the CDN from akamai and that TI should get in touch with the akamai support to get it sorted. Let's see the efficiency of the free markets at work 8-) Thank you very much! I've brought this up with a friend at akamai.. He's looking into it.. Julian ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)
On 4/5/2020 10:05 PM, Tomasz CEDRO wrote: > On Sun, Apr 5, 2020 at 4:59 PM Ruslan Garipov wrote: >> I'm sorry, I forgot to ask how do you call /usr/src/release/release.sh? >> Do you pass a configuration file to this script? >> >> By default /usr/src/release/release.sh checks out the source tree for >> the CURRENT branch (svn://svn.FreeBSD.org/base/head@rHEAD). In this >> case (if you doesn't change it) chrooted environment definitely will >> fail to run on STABLE and/or RELEASE. >> >> May be it's easy for you to use `make release` directly. > > Case solved! =) > > I wrongly assumed that release will simply update this svn repo that I > am working on.. but it fetches HEAD.. so I was trying to build > 13/HEAD/CURRENT on 12/STABLE/RELEASE that have different ABI thus bad > syscall.. and I need CURRENT to build CURRENT, right? :-) I believe in order to build the source tree you just need a compatible toolchain. So you can build the source tree for 13.0-CURRENT on 12.1-RELEASE system. But you need CURRENT to **run** userland with ABI from the CURRENT. In order to build, for example, 12.1-RELEASE image with release(7) you should assign the SRCBRANCH variable to "base/release/12.1.0@rHEAD", and for 12.0-STABLE: SRCBRANCH="base/stable/12@rHEAD". Either in your configuration file for release(7) or directly in your shell: env SRCBRANCH="base/release/12.1.0@rHEAD" /usr/src/release/release.sh > > I will provide a release.conf, make.conf, src.conf and maybe KERNCONF > if I need something beyond GENERIC. For now I just need to work with > 12-STABLE. Good hint! :-) Sure. Just as a note, by default (when the caller doesn't provide a configuration file to release(7), or the file provided doesn't exists), release(7) builds GENERIC kernel and uses no make.conf and src.conf. Once again: for native build `make release` may be quite easy and fast. release(7) guarantees "absolutely clean build environment". > > Thank you Ruslan!! :-) > > Tomek > > ps/2: Can I provide a patch that will print out what actually is being > fetched by release.sh? That could save some time for first time users > :-) Why not :-) For me reading /usr/src/release/release.sh and default configs for ARM saved me a lot of time. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)
On Sun, Apr 5, 2020 at 4:59 PM Ruslan Garipov wrote: > I'm sorry, I forgot to ask how do you call /usr/src/release/release.sh? > Do you pass a configuration file to this script? > > By default /usr/src/release/release.sh checks out the source tree for > the CURRENT branch (svn://svn.FreeBSD.org/base/head@rHEAD). In this > case (if you doesn't change it) chrooted environment definitely will > fail to run on STABLE and/or RELEASE. > > May be it's easy for you to use `make release` directly. Case solved! =) I wrongly assumed that release will simply update this svn repo that I am working on.. but it fetches HEAD.. so I was trying to build 13/HEAD/CURRENT on 12/STABLE/RELEASE that have different ABI thus bad syscall.. and I need CURRENT to build CURRENT, right? :-) I will provide a release.conf, make.conf, src.conf and maybe KERNCONF if I need something beyond GENERIC. For now I just need to work with 12-STABLE. Good hint! :-) Thank you Ruslan!! :-) Tomek ps/2: Can I provide a patch that will print out what actually is being fetched by release.sh? That could save some time for first time users :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)
On 4/5/2020 6:52 PM, Tomasz CEDRO wrote:
> Hello Ruslav and thank you for your feedback! :-)
>
> On Sun, Apr 5, 2020 at 3:07 PM Ruslan Garipov wrote:
>> On 4/4/2020 7:50 PM, Tomasz CEDRO wrote:
>>> 1. Is it a good build / testing environment? Maybe there is a simpler
>>> / better way to cross compile binaries and test on another machine?
>>> Both are using 12.1-RELEASE AMD64 installations so far. All /usr/local
>>> should work both with 12.1-RELEASE and 12-STABLE right?
>> Both machines have the same architecture, therefore it is not a cross
>> build, I believe. For my direct builds (both build and consumer
>> machines are x86-64) I use the procedure described in the handbook
>> (``23.6. Tracking for Multiple Machines''[1]).
>
> I know that method, thank you :-) But I also want to try out the
> binary release, which seems a bit more flexible to have just
> everything in one place, may be used to install on an external machine
> without NFS access, etc :-)
>
> It would be also nice to know the time cost of those two methods, so I
> want to verify :-)
>
>
>>> 3. During /usr/src/release/release.sh I get following error as pasted
>>> below. Does release.sh update /usr/ports just as it snaps from svn or
>>> it will use the /usr/porst that are just there and I need to provide
>>> /usr/ports in a state that will be bindled into a /scratch release?
>> A quote from release(7) man page:
>>
>> release.sh checks out the src/, ports/, and doc/ trees to CHROOTDIR...
>>
>> Therefore, release(7) "ignores" /usr/ports and uses
>> ${CHROOTDIR}/usr/ports. My build machine doesn't have access to the
>> Internet, therefore, I have to define the PORTS_UPDATE_SKIP variable and
>> provide ports tree into the ${CHROOTDIR}/usr/ports before
>> I will call /usr/src/release/release.sh.
>
> Okay, so the build uses totally separate CHROOT in /scratch? I wonder
> if that "Bad System Call" is caused by my Host tools or the CHROOT
> tools?
>
> It looks like the /scratch has its own compiled in tools not a copy
> from my host?
>
> # diff -u /usr/bin/fetch /scratch/usr/bin/fetch
> Binary files /usr/bin/fetch and /scratch/usr/bin/fetch differ
I'm sorry, I forgot to ask how do you call /usr/src/release/release.sh?
Do you pass a configuration file to this script?
By default /usr/src/release/release.sh checks out the source tree for
the CURRENT branch (svn://svn.FreeBSD.org/base/head@rHEAD). In this
case (if you doesn't change it) chrooted environment definitely will
fail to run on STABLE and/or RELEASE.
May be it's easy for you to use `make release` directly.
>
>
>>> ===> docproj-2.0_14 depends on file: /usr/local/sbin/pkg - not found
>>> ===> License BSD2CLAUSE accepted by the user
>>> ===> Fetching all distfiles required by pkg-1.14.2 for building
>>> ===> Extracting for pkg-1.14.2
>>> ===> License BSD2CLAUSE accepted by the user
>>> ===> Fetching all distfiles required by pkg-1.14.2 for building
>>> => SHA256 Checksum mismatch for freebsd-pkg-1.14.2_GH0.tar.gz.
>>> ===> Refetch for 1 more times files: freebsd-pkg-1.14.2_GH0.tar.gz
>>> ===> License BSD2CLAUSE accepted by the user
>>> => freebsd-pkg-1.14.2_GH0.tar.gz doesn't seem to exist in /tmp/distfiles/.
>>> => Attempting to fetch
>>> https://codeload.github.com/freebsd/pkg/tar.gz/1.14.2?dummy=/freebsd-pkg-1.14.2_GH0.tar.gz
>>> freebsd-pkg-1.14.2_GH0.tar.gz Bad system call (core dumped)
>> /usr/src/release/release.sh defines DISTDIR=/tmp/distfiles when it
>> installs the textproc/docproj port or a port from the ${EMBEDDEDPORTS}.
>>
>> As for why fetch(1) fails with bad system call under chrooted
>> environment -- I don't know. I failed on a port fetching only if I
>> hadn't provided all necessary distfiles. You have checksum error
>> message which is causing refetching of the ports-mgmt/pkg port.
>> Therefore, I believe
>> ${CHROOTDIR}/tmp/distfiles/freebsd-pkg-1.14.2_GH0.tar.gz exists on your
>> file system (remained from a previous fetch try?)... May be you should
>> try fetch(1) from the chrooted environment manually, to get any content?
>
> This "Bad System Call" stops me from proceeding. I did place by hand
> the required package in the right place, then it built ok, then I got
> that "Bad System Call" again on install :-(
>
> How can I get the debug symbols in /scratch binaries?
>
> So far I can just show:
> [New LWP 100764]
> Core was generated by `/usr/bin/fetch -Fpr -S 3405355
> http://distcache.FreeBSD.org/ports-distfiles/free'.
> Program terminated with signal SIGSYS, Bad system call.
> #0 0x0008003c1bca in ?? ()
> (gdb) bt
> #0 0x0008003c1bca in ?? ()
> #1 0x00080031d144 in ?? ()
> #2 0x00080031d260 in ?? ()
> #3 0x0008 in ?? ()
> #4 0xb650b69b3fd03fb8 in ?? ()
> #5 0x7fffdd40 in ?? ()
> #6 0x7fffe64c in ?? ()
> #7 0x000800e1d000 in ?? ()
> #8 0x002091e0 in ?? ()
> #9 0x7fffdc80 in ?? ()
> #10 0x7fffdc40 in ?? ()
> #11 0x00080031d2f9 in ?? ()
> #12
Re: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)
On 4/5/2020 6:52 PM, Tomasz CEDRO wrote:
> Hello Ruslav and thank you for your feedback! :-)
>
> On Sun, Apr 5, 2020 at 3:07 PM Ruslan Garipov wrote:
>> On 4/4/2020 7:50 PM, Tomasz CEDRO wrote:
>>> 1. Is it a good build / testing environment? Maybe there is a simpler
>>> / better way to cross compile binaries and test on another machine?
>>> Both are using 12.1-RELEASE AMD64 installations so far. All /usr/local
>>> should work both with 12.1-RELEASE and 12-STABLE right?
>> Both machines have the same architecture, therefore it is not a cross
>> build, I believe. For my direct builds (both build and consumer
>> machines are x86-64) I use the procedure described in the handbook
>> (``23.6. Tracking for Multiple Machines''[1]).
>
> I know that method, thank you :-) But I also want to try out the
> binary release, which seems a bit more flexible to have just
> everything in one place, may be used to install on an external machine
> without NFS access, etc :-)
>
> It would be also nice to know the time cost of those two methods, so I
> want to verify :-)
>
>
>>> 3. During /usr/src/release/release.sh I get following error as pasted
>>> below. Does release.sh update /usr/ports just as it snaps from svn or
>>> it will use the /usr/porst that are just there and I need to provide
>>> /usr/ports in a state that will be bindled into a /scratch release?
>> A quote from release(7) man page:
>>
>> release.sh checks out the src/, ports/, and doc/ trees to CHROOTDIR...
>>
>> Therefore, release(7) "ignores" /usr/ports and uses
>> ${CHROOTDIR}/usr/ports. My build machine doesn't have access to the
>> Internet, therefore, I have to define the PORTS_UPDATE_SKIP variable and
>> provide ports tree into the ${CHROOTDIR}/usr/ports before
>> I will call /usr/src/release/release.sh.
>
> Okay, so the build uses totally separate CHROOT in /scratch?
Yes.
> I wonder
> if that "Bad System Call" is caused by my Host tools or the CHROOT
> tools?
By the chrooted environment within the ${CHROOTDIR} I believe.
Otherwise you would get the same error on "host".
>
> It looks like the /scratch has its own compiled in tools not a copy
> from my host?
Yes, release(7) builds and installs clean userland into the ${CHROOTDIR}
(DESTDIR=${CHROOTDIR}), and doesn't copy it from the "host".
>
> # diff -u /usr/bin/fetch /scratch/usr/bin/fetch
> Binary files /usr/bin/fetch and /scratch/usr/bin/fetch differ
>
>
>>> ===> docproj-2.0_14 depends on file: /usr/local/sbin/pkg - not found
>>> ===> License BSD2CLAUSE accepted by the user
>>> ===> Fetching all distfiles required by pkg-1.14.2 for building
>>> ===> Extracting for pkg-1.14.2
>>> ===> License BSD2CLAUSE accepted by the user
>>> ===> Fetching all distfiles required by pkg-1.14.2 for building
>>> => SHA256 Checksum mismatch for freebsd-pkg-1.14.2_GH0.tar.gz.
>>> ===> Refetch for 1 more times files: freebsd-pkg-1.14.2_GH0.tar.gz
>>> ===> License BSD2CLAUSE accepted by the user
>>> => freebsd-pkg-1.14.2_GH0.tar.gz doesn't seem to exist in /tmp/distfiles/.
>>> => Attempting to fetch
>>> https://codeload.github.com/freebsd/pkg/tar.gz/1.14.2?dummy=/freebsd-pkg-1.14.2_GH0.tar.gz
>>> freebsd-pkg-1.14.2_GH0.tar.gz Bad system call (core dumped)
>> /usr/src/release/release.sh defines DISTDIR=/tmp/distfiles when it
>> installs the textproc/docproj port or a port from the ${EMBEDDEDPORTS}.
>>
>> As for why fetch(1) fails with bad system call under chrooted
>> environment -- I don't know. I failed on a port fetching only if I
>> hadn't provided all necessary distfiles. You have checksum error
>> message which is causing refetching of the ports-mgmt/pkg port.
>> Therefore, I believe
>> ${CHROOTDIR}/tmp/distfiles/freebsd-pkg-1.14.2_GH0.tar.gz exists on your
>> file system (remained from a previous fetch try?)... May be you should
>> try fetch(1) from the chrooted environment manually, to get any content?
>
> This "Bad System Call" stops me from proceeding. I did place by hand
> the required package in the right place, then it built ok, then I got
> that "Bad System Call" again on install :-(
>
> How can I get the debug symbols in /scratch binaries?
You need to provide custom src.conf or/and make.conf to release(7).
I, actually, provide make.conf, src.conf and kernel config (not for the
debug symbols; just for tuning the target release).
>
> So far I can just show:
> [New LWP 100764]
> Core was generated by `/usr/bin/fetch -Fpr -S 3405355
> http://distcache.FreeBSD.org/ports-distfiles/free'.
> Program terminated with signal SIGSYS, Bad system call.
> #0 0x0008003c1bca in ?? ()
> (gdb) bt
> #0 0x0008003c1bca in ?? ()
> #1 0x00080031d144 in ?? ()
> #2 0x00080031d260 in ?? ()
> #3 0x0008 in ?? ()
> #4 0xb650b69b3fd03fb8 in ?? ()
> #5 0x7fffdd40 in ?? ()
> #6 0x7fffe64c in ?? ()
> #7 0x000800e1d000 in ?? ()
> #8 0x002091e0 in ?? ()
> #9 0x7fffdc80 in ?? ()
> #10 0x7fffdc40 in ?? ()
> #11 0x000
Re: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)
Hello Ruslav and thank you for your feedback! :-)
On Sun, Apr 5, 2020 at 3:07 PM Ruslan Garipov wrote:
> On 4/4/2020 7:50 PM, Tomasz CEDRO wrote:
> > 1. Is it a good build / testing environment? Maybe there is a simpler
> > / better way to cross compile binaries and test on another machine?
> > Both are using 12.1-RELEASE AMD64 installations so far. All /usr/local
> > should work both with 12.1-RELEASE and 12-STABLE right?
> Both machines have the same architecture, therefore it is not a cross
> build, I believe. For my direct builds (both build and consumer
> machines are x86-64) I use the procedure described in the handbook
> (``23.6. Tracking for Multiple Machines''[1]).
I know that method, thank you :-) But I also want to try out the
binary release, which seems a bit more flexible to have just
everything in one place, may be used to install on an external machine
without NFS access, etc :-)
It would be also nice to know the time cost of those two methods, so I
want to verify :-)
> > 3. During /usr/src/release/release.sh I get following error as pasted
> > below. Does release.sh update /usr/ports just as it snaps from svn or
> > it will use the /usr/porst that are just there and I need to provide
> > /usr/ports in a state that will be bindled into a /scratch release?
> A quote from release(7) man page:
>
> release.sh checks out the src/, ports/, and doc/ trees to CHROOTDIR...
>
> Therefore, release(7) "ignores" /usr/ports and uses
> ${CHROOTDIR}/usr/ports. My build machine doesn't have access to the
> Internet, therefore, I have to define the PORTS_UPDATE_SKIP variable and
> provide ports tree into the ${CHROOTDIR}/usr/ports before
> I will call /usr/src/release/release.sh.
Okay, so the build uses totally separate CHROOT in /scratch? I wonder
if that "Bad System Call" is caused by my Host tools or the CHROOT
tools?
It looks like the /scratch has its own compiled in tools not a copy
from my host?
# diff -u /usr/bin/fetch /scratch/usr/bin/fetch
Binary files /usr/bin/fetch and /scratch/usr/bin/fetch differ
> > ===> docproj-2.0_14 depends on file: /usr/local/sbin/pkg - not found
> > ===> License BSD2CLAUSE accepted by the user
> > ===> Fetching all distfiles required by pkg-1.14.2 for building
> > ===> Extracting for pkg-1.14.2
> > ===> License BSD2CLAUSE accepted by the user
> > ===> Fetching all distfiles required by pkg-1.14.2 for building
> > => SHA256 Checksum mismatch for freebsd-pkg-1.14.2_GH0.tar.gz.
> > ===> Refetch for 1 more times files: freebsd-pkg-1.14.2_GH0.tar.gz
> > ===> License BSD2CLAUSE accepted by the user
> > => freebsd-pkg-1.14.2_GH0.tar.gz doesn't seem to exist in /tmp/distfiles/.
> > => Attempting to fetch
> > https://codeload.github.com/freebsd/pkg/tar.gz/1.14.2?dummy=/freebsd-pkg-1.14.2_GH0.tar.gz
> > freebsd-pkg-1.14.2_GH0.tar.gz Bad system call (core dumped)
> /usr/src/release/release.sh defines DISTDIR=/tmp/distfiles when it
> installs the textproc/docproj port or a port from the ${EMBEDDEDPORTS}.
>
> As for why fetch(1) fails with bad system call under chrooted
> environment -- I don't know. I failed on a port fetching only if I
> hadn't provided all necessary distfiles. You have checksum error
> message which is causing refetching of the ports-mgmt/pkg port.
> Therefore, I believe
> ${CHROOTDIR}/tmp/distfiles/freebsd-pkg-1.14.2_GH0.tar.gz exists on your
> file system (remained from a previous fetch try?)... May be you should
> try fetch(1) from the chrooted environment manually, to get any content?
This "Bad System Call" stops me from proceeding. I did place by hand
the required package in the right place, then it built ok, then I got
that "Bad System Call" again on install :-(
How can I get the debug symbols in /scratch binaries?
So far I can just show:
[New LWP 100764]
Core was generated by `/usr/bin/fetch -Fpr -S 3405355
http://distcache.FreeBSD.org/ports-distfiles/free'.
Program terminated with signal SIGSYS, Bad system call.
#0 0x0008003c1bca in ?? ()
(gdb) bt
#0 0x0008003c1bca in ?? ()
#1 0x00080031d144 in ?? ()
#2 0x00080031d260 in ?? ()
#3 0x0008 in ?? ()
#4 0xb650b69b3fd03fb8 in ?? ()
#5 0x7fffdd40 in ?? ()
#6 0x7fffe64c in ?? ()
#7 0x000800e1d000 in ?? ()
#8 0x002091e0 in ?? ()
#9 0x7fffdc80 in ?? ()
#10 0x7fffdc40 in ?? ()
#11 0x00080031d2f9 in ?? ()
#12 0x000800e1d000 in ?? ()
#13 0x7fffdd40 in ?? ()
#14 0x in ?? ()
Thank you! :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: amdgpu panics
On 2020-04-05 14:18, Grzegorz Junka wrote: How can I debug what's wrong? Can you check the timestamps for: ls -l /boot/modules and ls -l /boot/kernel That they match? Try loading like this: kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko --HPS ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: qt5-webengine
Am 05.04.20 um 02:50 schrieb John Kennedy:> The thing that drove me away from portmaster to synth and eventually to > poudriere is incompatible dependencies. I was running into those with just > X11 dependencies (~600 packages in my full port rebuild, so not sure how you > got lucky over that period of time). Now, people keep on fixing portmaster > and fixing dependencies, but at times I would have just been SOL for an > indeterminate period of time. I have for more than 1 year been using a rewrite of portmaster that uses a completely different approach than the official version. But due to "features" of the ports system, that only ever considered whether they might break poudriere (and thus the package build cluster) it is extremely complex to cover all special cases. That version has been tested by a few people that asked, but I have meanwhile given up on trying to get it working perfectly for all cases. The logic is just too complex to express in Bourne Shell or Bash. Main features beyond a better strategy logic is that this portmaster can be used to build in a clean environment (idea stolen from synth) and it can also be used to maintain a repository to upgrade from. I have started porting that version to LUA a few months ago and have been able to update ports with it (with the syntax of the shell version just translated to LUA). Since LUA offers quite advanced features for object oriented or function programming styles, I have then re-implemented layer for layer in a style that uses LUA features. This has also allowed a significant speed-up: Checking my ~2400 ports for missing updates (and I have kept the development system without updates to have a good test coverage) results in 1373 actions (upgrades, new installations) and it takes 50s to get all ports checked and another 10 seconds to identify collisions of to-be-installed dependencies with existing ports. (And with 4 cores this could be reduced to 20 seconds for this large set of ports, but I'm currently trying to get the functionality complete, speed comes as a secondary goal.) > I also got in the habit of rebuilding and reinstalling everything about > once a month because of weird (dependency) breakages that portmaster (at > least at the time) couldn't figure out and recompile itself. I'm tracking not only version changes, but also whether a port relies on an outdated library. It is possible to update all ports that have an OSVERSION from before a kernel change that requires the port to be re-installed (most relevant for -CURRENT). I'm working on this in spare time (too little, currently) and the ports system is not friendly to any tool besides poudriere. The implementation of flavors is particular bad to deal with, if you do not just maintain a package repository, but want to upgrade a system with installed ports to the latest versions (with your options intact). > I'm really impatient, and have a compulsion to security-patch things, so > thus I was finally driven to change (after I don't know how many years). > > Synth and poudriere avoided it because it was a build dependency, not a > run-time dependency, and their build environments kept that very clean > (which portmaster couldn't do, at least at the time). It also let me have > less packages loaded on the machine overall, so less surface area for attacks. > Yeah, it recompiles a BUNCH of things that often don't get upgraded, but I've > never felt the need to recompile everything in case something got missed. It is already possible to install build dependencies from packages saved from a prior portmaster session and delete build tools not required as run dependencies at the end of the portmaster run. This does work with the version in ports. I have added the ability to build in a clean jail with build tools only ever available within the jail during the session. > I also find that port problems that break poudriere builds get caught > quickly (vs more-rare synth problems, and way faster than portmaster), so > I get to reap the advantages of what FreeBSD is building with. Yes, the problem is that only problems that affect poudriere are caught by the build cluster and even port system infrastructure changes may impact tools like portmaster (or portupgrade) in such a way that they completely break. That has been the case with the (IMHO) badly designed flavor support, which made portmaster unusable until I took over maintainership and added flavor support (working most of the time, but not perfect). There have been other changes, like renaming of ports and packages at the same time when KDE4 was removed from ports: This makes it impossible for a tool like portmaster to correctly identify the port directory to use in order to upgrade some installed package - at least one of port origin and package name are needed to perform a match (MOVED could have helped, but it was not used when KDE4 was deleted for reasons that I can understand). Anyway, I'm working on the LUA i
Re: /usr/src/release/release.sh -> ports -> fetch pkg -> Bad system call (core dumped)
On 4/4/2020 7:50 PM, Tomasz CEDRO wrote:
> Hello world :-)
>
> I would like to build a 12-STABLE (/usr/src contains
> svn.freebsd.org/base/stable/12) locally on strong machine (24CPU 127GB
> RAM 12-1-RELEASE AMD64), then test changes on my local machine
> (panasonic toughbook i5 laptop 12.1-RELEASE AMD64). This will be used
> for testing kernel patches and driver development/fixes.
>
> The goal is to have separate zroot/ROOT/stable to select and act as
> the FreeBSD base. So far I have zroot/ROOT/default to use FreeBSD
> 12.1-RELEASE. I would like to switch between those to on boot to have
> one base system stable for working and another base system for testing
> on real environment.
>
> I noticed that simple copy of /boot/kernel does not work on my target
> machine. Thus I am trying to create a whole release, put a separate
> system base, then on boot select different zfs container base to boot
> from. I just love ZFS for that! I may even use snapshots to log and
> rollback changes.
>
> Questions:
>
> 1. Is it a good build / testing environment? Maybe there is a simpler
> / better way to cross compile binaries and test on another machine?
> Both are using 12.1-RELEASE AMD64 installations so far. All /usr/local
> should work both with 12.1-RELEASE and 12-STABLE right?
Both machines have the same architecture, therefore it is not a cross
build, I believe. For my direct builds (both build and consumer
machines are x86-64) I use the procedure described in the handbook
(``23.6. Tracking for Multiple Machines''[1]).
>
> 2. When that works, I would like to cross-compile for ARM in a similar
> manner, then attach pyOCD + GDB to debug ARM target. I guess that
> should work too as above?
>
> 3. During /usr/src/release/release.sh I get following error as pasted
> below. Does release.sh update /usr/ports just as it snaps from svn or
> it will use the /usr/porst that are just there and I need to provide
> /usr/ports in a state that will be bindled into a /scratch release?
A quote from release(7) man page:
release.sh checks out the src/, ports/, and doc/ trees to CHROOTDIR...
Therefore, release(7) "ignores" /usr/ports and uses
${CHROOTDIR}/usr/ports. My build machine doesn't have access to the
Internet, therefore, I have to define the PORTS_UPDATE_SKIP variable and
provide ports tree into the ${CHROOTDIR}/usr/ports before
I will call /usr/src/release/release.sh.
>
> ===> docproj-2.0_14 depends on file: /usr/local/sbin/pkg - not found
> ===> License BSD2CLAUSE accepted by the user
> ===> Fetching all distfiles required by pkg-1.14.2 for building
> ===> Extracting for pkg-1.14.2
> ===> License BSD2CLAUSE accepted by the user
> ===> Fetching all distfiles required by pkg-1.14.2 for building
> => SHA256 Checksum mismatch for freebsd-pkg-1.14.2_GH0.tar.gz.
> ===> Refetch for 1 more times files: freebsd-pkg-1.14.2_GH0.tar.gz
> ===> License BSD2CLAUSE accepted by the user
> => freebsd-pkg-1.14.2_GH0.tar.gz doesn't seem to exist in /tmp/distfiles/.
> => Attempting to fetch
> https://codeload.github.com/freebsd/pkg/tar.gz/1.14.2?dummy=/freebsd-pkg-1.14.2_GH0.tar.gz
> freebsd-pkg-1.14.2_GH0.tar.gz Bad system call (core dumped)
/usr/src/release/release.sh defines DISTDIR=/tmp/distfiles when it
installs the textproc/docproj port or a port from the ${EMBEDDEDPORTS}.
As for why fetch(1) fails with bad system call under chrooted
environment -- I don't know. I failed on a port fetching only if I
hadn't provided all necessary distfiles. You have checksum error
message which is causing refetching of the ports-mgmt/pkg port.
Therefore, I believe
${CHROOTDIR}/tmp/distfiles/freebsd-pkg-1.14.2_GH0.tar.gz exists on your
file system (remained from a previous fetch try?)... May be you should
try fetch(1) from the chrooted environment manually, to get any content?
> => Attempting to fetch
> http://distcache.FreeBSD.org/ports-distfiles/freebsd-pkg-1.14.2_GH0.tar.gz
> freebsd-pkg-1.14.2_GH0.tar.gz Bad system call (core dumped)
> => Couldn't fetch it - please try to retrieve this
> => port manually into /tmp/distfiles/ and try again.
> *** Error code 1
>
> Stop.
>
> Any hints and comments are welcome :-)
> Tomek
>
[1]
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/small-lan.html
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: qt5-webengine
On Sat, Apr 4, 2020 at 7:43 PM Robert Huff wrote: > I understand there are folks for whom poudriere or synth are The > Right Tool(tm). But I am one of a number of folks for whom it is like > carpet-bombing the neighborhood to get rid of one miscreant squirrel. > I swear, you find that squirrel you phone me asap! I have the warthogs circling looking for him for at least a week now! -- Cheers, Danny -- Danny McGrath - danmcgrath...@gmail.com GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: amdgpu panics
On 04/04/2020 10:27, Matthias Andree wrote: Thank you John for the comprehensive explanation. It took me a while to go through all the details, then again to recompile the ports and try to reinstall all packages. What i discovered in the meantime is that it's not an isolated problem: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241787 https://forums.freebsd.org/threads/upgrading-to-freebsd-12-1-release-resolving-an-issue-with-drm-fbsd12-0-kmod.72895/ On my system I indeed had the jail at a different patch level than the host system, although they were all running 12.1-RELEASE. I updated the host and the jail to 12.1-RELEASE-p3. Poudriere noticed the updated jail and deleted and recompiled all 2000+ packages. Then I upgraded the system on which I wanted to install the packages to 12.1-RELEASE-p3 too. Then I deleted drm-fbsd12.0-kmod and installed drm-kmod. It reinstalled drm-fbsd12.0-kmod. The result? Blank screen!!! I start as single or normal user then do: kldload amdgpu I see the driver is loading various graphics kernel modules then the screen goes blank and the whole system hangs. No panic is shown, no restart, just hungs. Any SSH sessions to the system become stale. Only hard reset is able to restart it. This is really frustrating and a really bad user experience. I wouldn't be surprised if the remained desktop users moved to Linux or other FreeBSD forks if they haven't already. The only option left I see is to also compile the kernel myself from sources. Compared to 2,000 packages that seams a reasonable approach, and then IN THAT SAME LIVE SYSTEM also rebuild the graphics modules. I understand that the poudriere/pkg proponents have aggressively lobbied users to use pkg and poudriere for clean-room builds, but I wonder if it isn't easier to forgo poudriere for drivers and instead: obtain/update to 12.1-RELEASE-p3 sources in /usr/src (with svn, for instance) make buildworld buildkernel make installkernel edit your loader.conf[.local] so it doesn't load b0rked graphics modules, reboot into single-user mergemaster -Fp make installworld mergemaster -Fi make delete-old # important - there may be 12.0 parts that need removal, 12.1 for instance updated LLVM rebuild your kmods and drivers IN THIS LIVE SYSTEM RIGHT FROM PORTS (not poudriere) install kmods and drivers reboot and then gradually manually load kernel drivers such as amdgpu one by one so you know which work (enable them in the loader) and which won't. I am not sure if it helps for amdgpu, since I am using nvidia- which sort-of works (but GNOME frequently flakes out for my user but not other users)... but I'd think this approach forgoes any potential difference between the build jail and live system kernel sources Of course this rules out freebsd-update for kernel/system patching then, you'd update /usr/src and then make -DNOCLEAN buildworld buildkernel and install again once -p4 or newer come out. I reinstalled the whole system from a newly compiled kernel and world. It didn't help. When I do "kldload amdgpu" the screen goes blank after loading one of the driver modules. I have compiled the base on another system and firstly just unpacked the kernel files. When that didn't work I used FreeBSD-base packages to reinstall everything from the build server. It worked pretty well but didn't change a thing. The build system has an NVidia card and an AMD (Phenom) process. The system on which I install has AMD Vega 64 card and another AMD (Ryzen) processor. I don't use any configuration to build for a specific architecture and I hope "drm-fbsd12.0-kmod" doesn't do any optimizations based on the architecture on which it's compiled. How can I debug what's wrong? Grzegorz J ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: qt5-webengine
On Sun, 5 Apr 2020 18:08:27 +0700 "Alex V. Petrov" wrote: > 04.04.2020 21:10, ajtiM via freebsd-ports пишет: > > Hi! > > > > Today update for qt5-webengine cannot compile: > > > > /usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so: > > undefined reference to `re2::RE2::Arg::parse_ulong(char const*, > > unsigned long, void*)' c++: error: linker command failed with exit > > code 1 (use -v to see invocation) *** > > [../../libexec/QtWebEngineProcess] Error code 1 > > > > make[4]: stopped in > > /usr/ports/www/qt5-webengine/work/.build/src/process 1 error > > > > make[4]: stopped in > > /usr/ports/www/qt5-webengine/work/.build/src/process *** > > [sub-process-make_first] Error code 2 > > > > make[3]: stopped in /usr/ports/www/qt5-webengine/work/.build/src > > --- sub-webengine-make_first --- > > A failure has been detected in another branch of the parallel make > > > > make[5]: stopped in > > /usr/ports/www/qt5-webengine/work/.build/src/webengine *** > > [sub-module-pro-make_first] Error code 2 > > > > make[4]: stopped in > > /usr/ports/www/qt5-webengine/work/.build/src/webengine 1 error > > > > make[4]: stopped in > > /usr/ports/www/qt5-webengine/work/.build/src/webengine *** > > [sub-webengine-make_first] Error code 2 > > > > make[3]: stopped in /usr/ports/www/qt5-webengine/work/.build/src > > --- sub-tools-qwebengine_convert_dict-make_first --- > > A failure has been detected in another branch of the parallel make > > > > make[4]: stopped in > > /usr/ports/www/qt5-webengine/work/.build/src/tools/qwebengine_convert_dict > > *** [sub-tools-qwebengine_convert_dict-make_first] Error code 2 > > > > make[3]: stopped in /usr/ports/www/qt5-webengine/work/.build/src > > 3 errors > > > > make[3]: stopped in /usr/ports/www/qt5-webengine/work/.build/src > > *** [sub-src-make_first] Error code 2 > > > > make[2]: stopped in /usr/ports/www/qt5-webengine/work/.build > > 1 error > > > > make[2]: stopped in /usr/ports/www/qt5-webengine/work/.build > > ===> Compilation failed unexpectedly. > > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the > > failure to the maintainer. > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/ports/www/qt5-webengine > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/ports/www/qt5-webengine > > > > ===>>> make build failed for www/qt5-webengine > > ===>>> Aborting update > > > > ===>>> Update for www/qt5-webengine failed > > ===>>> Aborting update > > > > Thank you. > > > > I have the same error too. > FreeBSD 12.1-STABLE r359434 amd64. > Reinstall devel/re2 and devel/re2c I do not use webengine anymore because I do not using FreeCAD anymore on FreeBSD. -- Ernst Lubitsch’s Ninotchka: “‘Waiter! A cup of coffee without cream, please!’ ‘I’m sorry, sir, we have no cream, only milk, so can it be a coffee without milk?’” ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: qt5-webengine
04.04.2020 21:10, ajtiM via freebsd-ports пишет: > Hi! > > Today update for qt5-webengine cannot compile: > > /usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so: undefined > reference to `re2::RE2::Arg::parse_ulong(char const*, unsigned long, > void*)' c++: error: linker command failed with exit code 1 (use -v to > see invocation) *** [../../libexec/QtWebEngineProcess] Error code 1 > > make[4]: stopped in /usr/ports/www/qt5-webengine/work/.build/src/process > 1 error > > make[4]: stopped in /usr/ports/www/qt5-webengine/work/.build/src/process > *** [sub-process-make_first] Error code 2 > > make[3]: stopped in /usr/ports/www/qt5-webengine/work/.build/src > --- sub-webengine-make_first --- > A failure has been detected in another branch of the parallel make > > make[5]: stopped in > /usr/ports/www/qt5-webengine/work/.build/src/webengine *** > [sub-module-pro-make_first] Error code 2 > > make[4]: stopped in > /usr/ports/www/qt5-webengine/work/.build/src/webengine 1 error > > make[4]: stopped in > /usr/ports/www/qt5-webengine/work/.build/src/webengine *** > [sub-webengine-make_first] Error code 2 > > make[3]: stopped in /usr/ports/www/qt5-webengine/work/.build/src > --- sub-tools-qwebengine_convert_dict-make_first --- > A failure has been detected in another branch of the parallel make > > make[4]: stopped in > /usr/ports/www/qt5-webengine/work/.build/src/tools/qwebengine_convert_dict > *** [sub-tools-qwebengine_convert_dict-make_first] Error code 2 > > make[3]: stopped in /usr/ports/www/qt5-webengine/work/.build/src > 3 errors > > make[3]: stopped in /usr/ports/www/qt5-webengine/work/.build/src > *** [sub-src-make_first] Error code 2 > > make[2]: stopped in /usr/ports/www/qt5-webengine/work/.build > 1 error > > make[2]: stopped in /usr/ports/www/qt5-webengine/work/.build > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the > failure to the maintainer. > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/www/qt5-webengine > *** Error code 1 > > Stop. > make: stopped in /usr/ports/www/qt5-webengine > > ===>>> make build failed for www/qt5-webengine > ===>>> Aborting update > > ===>>> Update for www/qt5-webengine failed > ===>>> Aborting update > > Thank you. > I have the same error too. FreeBSD 12.1-STABLE r359434 amd64. -- - Alex. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Indentatioin problem while building sysutils/duplicity
Hello all, > > [root@numenor ~]# cd /usr/ports/sysutils/duplicity > [root@numenor duplicity]# make all > ===> duplicity-0.8.12_1 depends on package: py37-setuptools>0 - found > ===> duplicity-0.8.12_1 depends on file: /usr/local/bin/python3.7 - found > ===> duplicity-0.8.12_1 depends on shared library: librsync.so - found > (/usr/local/lib/librsync.so) > ===> Configuring for duplicity-0.8.12_1 > Traceback (most recent call last): > File "", line 1, in > File "setup.py", line 55 > for arg in args: > ^ > IndentationError: unexpected indent Not familiar enough with python to find the root cause of this, because it looks fine at first sight... sysutils/duplicity07 (py27 version) is OK. TIA, Cheers, Xavier -- Xavier Humbert - sysadmin & network engineer signature.asc Description: OpenPGP digital signature
