Re: [HEADSUP] making /bin/sh the default shell for root
On 12/10/21 14:21, Gary Jennejohn wrote: On Tue, 12 Oct 2021 06:59:00 -0400 grarpamp wrote: No. The system shell is supposed to make the system usable by the users. Actually, the real problem is that the easiest way to shoot one's own foot is by changing the language (say, the shell) spoken by default by FreeBSD. Well, the FreeBSD system speaks sh for its own use, this is clearly documented as the shell called by init(8), and later by rc(8), it should probably be the root:0 entry at least for consistancy. No other shell is called by the FreeBSD system there. Whatever the users want for their own shells is really up to them to decide after that. "Default" is bit of low context word, as there is no falling back to some shell occuring, no filling in for some missing option, etc. Maybe use word "shipped" or "root" instead. Everyone said they already do, and will continue to, exec whatever shell they like, whether after login, or by changing the entry. So in addition to the user being ultimately responsible for their own box and usage, this well announced entry for UPDATING cannot therein really be responsible for any user self-shooting. This is non-sense. Well, FreeBSD does not add every shell in base, does not add every app to base, etc. Some reasons for those limits should be obvious. This update gives further distilling clarity by limiting the number of shipped uid 0 entries to 1, with that 1 being sh. Every unix user should know that it's possible to changing the used shell by using chsh and this includes root. Then for every user, this update is not a problem. I've been using UNIX both privately and professionally since 1984 and I must admit that I never heard of chsh before seeing this e-mail. I simply use vipw; it's the logical way to do this sort of thing IMHO. But I suppose that this is the way to go for users who don't have root access (which I always have). AFAIK only root can use vipw, while chsh is usable by all system users. Guess you've been root since 1984 :) -- Guido Falsi
Re: recent head having significantly less "avail memory"
On 14/09/21 00:12, Konstantin Belousov wrote: On Mon, Sep 13, 2021 at 10:07:46PM +0200, Guido Falsi wrote: On 13/09/21 19:08, Konstantin Belousov wrote: On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: Hi, I updated head recently and today I noticed a difference which looks wrong. At boodt the new head shows signifcantly less avail memory than before, around 3 GiB less. I moved from commit 71fbc6faed6 [1] where I got: Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) to commit 7955efd574b [2] where I get: Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) I'm seeing this on multiple machines. Unluckily bisecting and trying an older loader.efi in sseparate tests did not give me any more insight. The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look like a possible trigger to this, but I have been unable to confirm it. Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could be? Is this UEFI or bios boot? Provide verbose dmesg for old and new boots on the same machine. For UEFI boot, show output of 'sysctl machdep.efi_map', again for old and new boots. I shared the data you request here: https://www.madpilot.net/cloud/s/ENW5zF7jfmrmFeG Thanks. If you do on the loader prompt for the new (AKA bad) kernel copy_staging enable and then boot, does the report of avail memory becomes good? Yes, it works as expected, that is reports the amount of memory I expect: Sep 14 00:24:50 marvin kernel: real memory = 17179869184 (16384 MB) Sep 14 00:24:50 marvin kernel: avail memory = 16590356480 (15821 MB) -- Guido Falsi
Re: recent head having significantly less "avail memory"
On 13/09/21 19:08, Konstantin Belousov wrote: On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: Hi, I updated head recently and today I noticed a difference which looks wrong. At boodt the new head shows signifcantly less avail memory than before, around 3 GiB less. I moved from commit 71fbc6faed6 [1] where I got: Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) to commit 7955efd574b [2] where I get: Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) I'm seeing this on multiple machines. Unluckily bisecting and trying an older loader.efi in sseparate tests did not give me any more insight. The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look like a possible trigger to this, but I have been unable to confirm it. Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could be? Is this UEFI or bios boot? Provide verbose dmesg for old and new boots on the same machine. For UEFI boot, show output of 'sysctl machdep.efi_map', again for old and new boots. I shared the data you request here: https://www.madpilot.net/cloud/s/ENW5zF7jfmrmFeG -- Guido Falsi
Re: recent head having significantly less "avail memory"
On 13/09/21 20:17, Ryan Stone wrote: On Mon, Sep 13, 2021 at 2:13 PM Guido Falsi via freebsd-current wrote: I'm not sure how to get the verbose data for the old boot, since I've been unable to revert the machine to the old state. I'll try anyway though. Do you have physical access to the machine? It might be easiest to grab a snapshot image, stick it on a USB drive and boot from that. I definitely have physical access, it's my desktop, laptop and build machines. First thing I'm doing is disable cron job removing old zfs snapshots, so state is not lost. Since this is involving only UEFI, loader and kernel, I've recovered the old parts and now I have the machine reporting the usual amount of memory, so I should be able to extract the requested data and post it shortly. Thanks for your help anyway! -- Guido Falsi
Re: recent head having significantly less "avail memory"
On 13/09/21 19:08, Konstantin Belousov wrote: On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: Hi, I updated head recently and today I noticed a difference which looks wrong. At boodt the new head shows signifcantly less avail memory than before, around 3 GiB less. I moved from commit 71fbc6faed6 [1] where I got: Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) to commit 7955efd574b [2] where I get: Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) I'm seeing this on multiple machines. Unluckily bisecting and trying an older loader.efi in sseparate tests did not give me any more insight. The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look like a possible trigger to this, but I have been unable to confirm it. Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could be? Is this UEFI or bios boot? Machine is UEFI Provide verbose dmesg for old and new boots on the same machine. For UEFI boot, show output of 'sysctl machdep.efi_map', again for old and new boots. I'm not sure how to get the verbose data for the old boot, since I've been unable to revert the machine to the old state. I'll try anyway though. Anyway this is happening on tree different machines. I forgot to mention they are using a custom kernel. I don't think it makes a difference but I'll also test GENERIC, just in case. -- Guido Falsi
recent head having significantly less "avail memory"
Hi, I updated head recently and today I noticed a difference which looks wrong. At boodt the new head shows signifcantly less avail memory than before, around 3 GiB less. I moved from commit 71fbc6faed6 [1] where I got: Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) to commit 7955efd574b [2] where I get: Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) I'm seeing this on multiple machines. Unluckily bisecting and trying an older loader.efi in sseparate tests did not give me any more insight. The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look like a possible trigger to this, but I have been unable to confirm it. Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could be? [1] https://cgit.freebsd.org/src/commit/?id=71fbc6faed62e8eb5864f7c40839740f5e9f5558 [2] https://cgit.freebsd.org/src/commit/?id=7955efd574b98601a95da45d6d8e7f452631fddd [3] https://cgit.freebsd.org/src/commit/?id=6032b6ba9596927aba15a8004ade521a593a7d58 -- Guido Falsi
Re: -CURRENT compilation time
On 06/09/21 10:08, Jeremie Le Hen wrote: Hey, I want to build -CURRENT again from sources. It's been a long time since I hadn't done that. I'm shocked by the compilation time. I started the whole thing on Friday night and Monday morning it's still in stage 4.2 (building libraries). Through occasional glancing at the screen over the weekend, it seems obvious to me that the compilation time is utterly dominated by LLVM. Compiling C++ seems extremely CPU heavy and this is made worse by the fact LLVM is built twice (once for build/cross tools, once for the actual world). So OK, my CPU is not the most powerful out there but it's still decent [1]. So I have a couple of questions coming to my mind: 1. Is there any optimization I could benefit from? (I'm sure there's a knob to use the existing compiler instead of building a cross-compiler.) I'm routinely compiling head once a month or so on an "i7-6700 CPU @ 3.40GHz" (from dmesg), slightly more powerful than an i5 but this is a relatively old one so not top notch anymore. It usually takes less than 4 hours. I also build a NanoBSD image from scratch from time to time to an even older i5, which takes a little longer, but always under 6 hours, so the build times you report look anomalous. So as already suggested make sure yiu are using parallel make jobs (-j option to make) and memory is large enough (I think you need at least 2 GiB for make job is the minimum to not risk thrashing. You should really enable meta mode (look for WITH_META_MODE in src.conf(5)). It will not help the first time but will help a lot in future recompilations with an already populated /usr/obj. You could also investigate using ccache, which again will only help for successive rebuilds, and will consume a fair amount of disk space. Another consideration, my builds are happening on SSD disks, with swap on SSD, if you have everything on spinning media that is also a slowing factor. If you have plenty of ram you could build in ram, which is what I'm doing with poudriere for ports and it really speeds things up (even SSD disks tend to get slower when hit with a constant high load of mixed read/write accesses, which poudriere with parallel builds sometime causes) Hope this helps! -- Guido Falsi
Re: poudriere: net/openldap24-server: stage/runaway , building forever
On 09/04/21 11:56, O. Hartmann wrote: On Fri, 9 Apr 2021 10:16:27 +0200 (CEST) Ronald Klop wrote: Hi, The official pkg builders are also stuck for 14-CURRENT. Although at a different port sysutils/msktutil. See main-amd64 at https://pkg-status.freebsd.org/builds?type=package It is stuck in "stage/runaway" for 61 hours now. http://beefy18.nyi.freebsd.org/build.html?mastername=main-amd64-default=p569609_s5b3b19db73 (ipv6 only) NB: I'm not involved in the pkg building cluster. Regards, Ronald. Van: "O. Hartmann" Datum: vrijdag, 9 april 2021 07:27 Aan: FreeBSD Ports Onderwerp: Re: poudriere: net/openldap24-server: stage/runaway , building forever On Fri, 9 Apr 2021 06:17:03 +0200 "Hartmann, O." wrote: Recent CURRENT host (FreeBSD 14.0-CURRENT #26 main-n245806-4d221f59b85: Sat Apr 3 06:43:44 CEST 2021 amd64), poudriere CURRENT jail at 14.0-CURRENT 147 amd64 from 2021-04-08 05:25:38. It seems that the recent CURRENT does have a serious problem when building net/openldap24-server. The build process gets stuck with staging and is marked "runaway": [head-amd64-head-default] [2021-04-08_13h56m41s] [parallel_build:] Queued: 1847 Built: 63 Failed: 17 Skipped: 1759 Ignored: 8Tobuild: 0 Time: 13:26:35 [01]: net/openldap24-server | openldap-sasl-server-2.4.58 stage/runaway (06:28:32 / 08:41:16) Also, on jails (recent CURRENT) serving as OpenLDAP server (also recent taken from git /usr/ports, branch main), run into a serious problem starting slapd, when starting slapd and the process is reporting checking configuration, it freezes forever. Putting slapd into debug mode doesn't help, since the freeze is quite early. Does anybody know what the reason for this strange behaviour is on CURRENT? All CURRENT servers are affected (almost all the same revision as shown above)? Thanks in advance, O. Hartmann Short update, another host is stuck at the very same point, host's CURRENT is at FreeBSD 14.0-CURRENT #2 main-n245870-86a52e262a6: Wed Apr 7 13:57:20 CEST 2021 amd64, it's jails is taken from the same source. The process is stuck at staging and took 34 hours ... never seen before: [...] [09:05:25] [03] [02:13:44] Finished net/openldap24-server | openldap-sasl-server-2.4.58: Failed: stage/runaway load: 10.39 cmd: awk 24374 [running] 0.06r 0.00u 0.00s 0% 3420k [headamd64-head-default] [2021-04-07_12h26m18s] [parallel_build:] Queued: 3298 Built: 2123 Failed: 7 Skipped: 1161 Ignored: 7Tobuild: 0 Time: 40:52:34 [03]: net/openldap24-server | openldap-sasl-server-2.4.58 stage/runaway (31:48:30 / 34:01:11) [40:52:52] Logs: /pool/poudriere/data/logs/bulk/headamd64-head-default/2021-04-07_12h26m18s ___ [...] It seems, that jails on 14-CURRENT do have a strange and malfunctional behaviour now. Most probably related to commit d36d68161517 check the thread at [1]. A solution is being discussed in D29623 at [2]. [1] https://lists.freebsd.org/pipermail/dev-commits-src-all/2021-April/005159.html [2] https://reviews.freebsd.org/D29623 -- Guido Falsi ___ 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: Problem compiling libgit2
On 06/04/21 18:59, Filippo Moretti via freebsd-current wrote: After moving ports to git I had the following error while updating libgit2:===> Extracting for libgit2-1.1.0 => ===> Extracting for libgit2-1.1.0 => SHA256 Checksum OK for libgit2-1.1.0.tar.gz. ===> Patching for libgit2-1.1.0 sed: /usr/ports/devel/libgit2/work/libgit2-1.1.0/cmake/Modules/SelectHTTPSBackend.cmake: No such file or directory *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/libgit2 *** Error code 1 Stop. make: stopped in /usr/ports/devel/libgit2 my system:root@STING /usr/ports/devel/libgit2]# uname -a FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #23 main-n245729-51cc31088bf: Tue Mar 30 18:58:45 CEST 2021 root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 It's been fixed, update your ports tree. -- Guido Falsi ___ 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: 13.0 RC4 might be delayed
On 29/03/21 16:28, Mario Lobo wrote: [snip] Good point. Now the question is, what the default should be. Since the correct aio configuration is in the pkg-message and easy to setup I'd go for default to AIO turned on. -- Guido Falsi +1 The way it is, is running smooth here on STABLE/13 and 14-CURRENT. I've just committed the AIO option (enabled by default) in r569604. BTW, since I'm going to sleep shortly, this will be my last commit to subversion. If I read correctly the migration schedule, subversion will be read only by the time I wake up. Hope everything works out fine! -- Guido Falsi ___ 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: 13.0 RC4 might be delayed
On 29/03/21 06:26, Greg Rivers wrote: On Sunday, 28 March 2021 20:37:13 CDT David G Lawrence via freebsd-current wrote: On 27/03/21 06:04, David G Lawrence via freebsd-current wrote: On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin wrote: On 26/03/2021 03:40, The Doctor via freebsd-current wrote: ??? if people are having issues with ports like ??? If I'm not mistaken: * 13.0-RC3 seems to be troublesome, as a guest machine, with emulators/virtualbox-ose 6.1.18 as the host * no such trouble with 12.0-RELEASE-p5 as a guest. I hope to refine the bug report this weekend. Had nothing but frequent guest lockups on 6.1.18 with my Win7 system. That was right after 6.1.18 was put into ports. Fell back to legacy (v5) and will try again shortly to see if it's any better. Kevin, ?? Make sure you have these options in your /etc/sysctl.conf : vfs.aio.max_buf_aio=8192 vfs.aio.max_aio_queue_per_proc=65536 vfs.aio.max_aio_per_proc=8192 vfs.aio.max_aio_queue=65536 ?? ...otherwise the guest I/O will random hang in VirtualBox. This issue was mitigated in a late 5.x VirtualBox by patching to not use AIO, but the issue came back in 6.x when that patch wasn't carried forward. Sorry I lost that patch. Can you point me to the patch? Maybe it can be easily ported. I found the relevant commit. Please give me some time for testing and I'll put this patch back in the tree. If you're going to put that patch back in, then AIO should probably be made an option in the port config, as shutting AIO off by default will have a significant performance impact. Without AIO, all guest IO will be become synchronous. Ideally, someone would fix the AIO case by either increasing the defaults in FreeBSD to something reasonable, and/or properly handing the case when an AIO limit is reached. Agreed, it would be a shame to have AIO disabled by default. A one time update to sysctl.conf (per the existing pkg message!) is a small price to pay for much better performance. Good point. Now the question is, what the default should be. Since the correct aio configuration is in the pkg-message and easy to setup I'd go for default to AIO turned on. I Have a few things on he pope with ports, I will need some days to work this out. -- Guido Falsi ___ 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: 13.0 RC4 might be delayed
On 28/03/21 22:34, Guido Falsi via freebsd-current wrote: On 27/03/21 06:04, David G Lawrence via freebsd-current wrote: On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin wrote: On 26/03/2021 03:40, The Doctor via freebsd-current wrote: ??? if people are having issues with ports like ??? If I'm not mistaken: * 13.0-RC3 seems to be troublesome, as a guest machine, with emulators/virtualbox-ose 6.1.18 as the host * no such trouble with 12.0-RELEASE-p5 as a guest. I hope to refine the bug report this weekend. Had nothing but frequent guest lockups on 6.1.18 with my Win7 system. That was right after 6.1.18 was put into ports. Fell back to legacy (v5) and will try again shortly to see if it's any better. Kevin, Make sure you have these options in your /etc/sysctl.conf : vfs.aio.max_buf_aio=8192 vfs.aio.max_aio_queue_per_proc=65536 vfs.aio.max_aio_per_proc=8192 vfs.aio.max_aio_queue=65536 ...otherwise the guest I/O will random hang in VirtualBox. This issue was mitigated in a late 5.x VirtualBox by patching to not use AIO, but the issue came back in 6.x when that patch wasn't carried forward. Sorry I lost that patch. Can you point me to the patch? Maybe it can be easily ported. I found the relevant commit. Please give me some time for testing and I'll put this patch back in the tree. -- Guido Falsi ___ 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: 13.0 RC4 might be delayed
On 27/03/21 06:04, David G Lawrence via freebsd-current wrote: On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin wrote: On 26/03/2021 03:40, The Doctor via freebsd-current wrote: ??? if people are having issues with ports like ??? If I'm not mistaken: * 13.0-RC3 seems to be troublesome, as a guest machine, with emulators/virtualbox-ose 6.1.18 as the host * no such trouble with 12.0-RELEASE-p5 as a guest. I hope to refine the bug report this weekend. Had nothing but frequent guest lockups on 6.1.18 with my Win7 system. That was right after 6.1.18 was put into ports. Fell back to legacy (v5) and will try again shortly to see if it's any better. Kevin, Make sure you have these options in your /etc/sysctl.conf : vfs.aio.max_buf_aio=8192 vfs.aio.max_aio_queue_per_proc=65536 vfs.aio.max_aio_per_proc=8192 vfs.aio.max_aio_queue=65536 ...otherwise the guest I/O will random hang in VirtualBox. This issue was mitigated in a late 5.x VirtualBox by patching to not use AIO, but the issue came back in 6.x when that patch wasn't carried forward. Sorry I lost that patch. Can you point me to the patch? Maybe it can be easily ported. -- Guido Falsi ___ 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: Is there any OS builtin git command like svnlite ?
On 14/03/21 21:09, Kurt Jaeger wrote: Hi! I'm working on clean installed VM -current from NFS mounted src like : admin@tbedfc:~ % df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/vtbd0p2 11G4.1G5.7G42% / devfs 1.0K1.0K 0B 100% /dev vm.tfc:/.dake12T843G 11T 7% /.dake vm.tfc:/ds/src/freebsd/current/14.0/913e7dc3e0eb 11T 55G 11T 0% /usr/src vm.tfc:/ds/obj/freebsd/current/14.0/913e7dc3e0eb 11T322G 11T 3% /usr/obj admin@tbedfc:~ % But could not display revison by uname : admin@tbedfc:~ % uname -a FreeBSD tbedfc 14.0-CURRENT FreeBSD 14.0-CURRENT #0: Fri Mar 12 18:16:41 JST 2021 root@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 admin@tbedfc:~ % I think this is because incapable of using git command with `git -C $SRCDIR rev-parse --verify --short HEAD'. In the first place, git command does not builtin src like svnlite. Is there any solution of this ? Not yet. There are ports that you can install with 'pkg install': pkg install git The git port has flavors. The full port can be excessive, git@lite looks good, if one only wants basic functionality there is also git@tiny, but I don't know what limitations that entails. -- Guido Falsi ___ 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: On 14-CURRENT: no ports options anymore?
On 13/03/21 20:17, Hartmann, O. wrote: Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to set options via "make config" or via poudriere accordingly. I always get "===> Options unchanged" (when options has been already set and I'd expect a dialog menu). This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64). I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG. How to fix this? What happened? I encountered something similar, some base shared library has changed, guess this is related with the ncurses changes in base. If I remember correctly force reinstalling dialog4ports package fixed it. Make sure you reinstall a freshly rebuilt one. Most probably anything using ncurses will require rebuild/reinstall. The cause is dialog4ports failing to start and the system sees no option changed. If that's not enough try # ldd -v /usr/local/bin/dialog4ports And see if it reports some useful information. -- Guido Falsi ___ 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: xfig menu on xfce
On 04/03/21 21:16, Guido Falsi via freebsd-current wrote:
On 04/03/21 20:56, Antonio Olivares wrote:
On Thu, Mar 4, 2021 at 1:55 PM Antonio Olivares
wrote:
On Thu, Mar 4, 2021 at 1:51 PM David Wolfskill
wrote:
On Thu, Mar 04, 2021 at 01:47:03PM -0600, Antonio Olivares wrote:
xfig installed from pkg
on the menu click on xfce we get error message
Failed to execute command "/usr/bin/xfig".
Failed to execute child process "/usr/bin/xfig" (No such file or
directory)
x Close
running from command line does work. which xfig reports
/usr/local/bin/xfig
olivares@deepcool:~ $ which xfig
/usr/local/bin/xfig
olivares@deepcool:~ $ uname -a
FreeBSD deepcool 13.0-BETA4 FreeBSD 13.0-BETA4 #0
releng/13.0-n244592-e32bc253629: Fri Feb 26 06:17:34 UTC 2021
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64
olivares@deepcool:~ $
Best Regards,
I am unfamiliar with xfce, but that seems like a bug in the menu entry
itself. Not sure whose responsibility that is
Peace,
david
I do not know how to edit the link, but it is not a big deal. It runs
from comand line.
Menu entries are created fort all desktop environments creating files
defined by common standards. Each installed software is responsible for
creating the correct file. (".desktop" files)
Looking at xfig port the desktop entry provided by upstream has that
patch coded in. The port is not patching it. The error you see would
happen with any desktop environment in FreeBSD. I'll provide a patch to
fix this.
Thanks for reporting it!
Filed bug report with patch:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254031
--
Guido Falsi
___
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: xfig menu on xfce
On 04/03/21 20:56, Antonio Olivares wrote:
On Thu, Mar 4, 2021 at 1:55 PM Antonio Olivares wrote:
On Thu, Mar 4, 2021 at 1:51 PM David Wolfskill wrote:
On Thu, Mar 04, 2021 at 01:47:03PM -0600, Antonio Olivares wrote:
xfig installed from pkg
on the menu click on xfce we get error message
Failed to execute command "/usr/bin/xfig".
Failed to execute child process "/usr/bin/xfig" (No such file or directory)
x Close
running from command line does work. which xfig reports
/usr/local/bin/xfig
olivares@deepcool:~ $ which xfig
/usr/local/bin/xfig
olivares@deepcool:~ $ uname -a
FreeBSD deepcool 13.0-BETA4 FreeBSD 13.0-BETA4 #0
releng/13.0-n244592-e32bc253629: Fri Feb 26 06:17:34 UTC 2021
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64
olivares@deepcool:~ $
Best Regards,
I am unfamiliar with xfce, but that seems like a bug in the menu entry
itself. Not sure whose responsibility that is
Peace,
david
I do not know how to edit the link, but it is not a big deal. It runs
from comand line.
Menu entries are created fort all desktop environments creating files
defined by common standards. Each installed software is responsible for
creating the correct file. (".desktop" files)
Looking at xfig port the desktop entry provided by upstream has that
patch coded in. The port is not patching it. The error you see would
happen with any desktop environment in FreeBSD. I'll provide a patch to
fix this.
Thanks for reporting it!
BTW to edit desktop menu entries in xfce you can use x11/menulibre.
The icedtea-web start/openjdk issue is more important for me. Just
writing to see if someone else has encountered this.
Don't know much about java, but I can't find information about this
problem in this thread.
--
Guido Falsi
___
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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 03/02/21 17:02, John Baldwin wrote: On 2/2/21 10:16 PM, Hartmann, O. wrote: On Mon, 1 Feb 2021 03:24:45 + Rick Macklem wrote: Rick Macklem wrote: Guido Falsi wrote: [good stuff snipped] Performed a full bisect. Tracked it down to commit aa906e2a4957, adding KTLS support to embedded OpenSSL. I filed a bug report about this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135 Apart from switching to svn:// scheme, another workaround is to build base using WITHOUT_OPENSSL_KTLS. Just fyi, when I tested the daemons I have for nfs-over-tls (which use ktls), they acted like things were ok (no handshake problems), but the data ended up on the wire unencrypted (nfs-over-tls doesn't do a SSL_write(), so it depends on ktls to do the encryption). Since these daemons work fine with openssl3 in ports/security/openssl-devel, I suspect the ktls backport is not quite right. I've sent jhb@ email. I was wrong on the above. I did a full buildworld/installworld and the daemons now seem to work with the openssl in head/main. Btw, did anyone try rebuilding svn from sources after doing the system upgrade? (The openssl library calls and .h files definitely changed.) Yes, I did, on all boxes and its a pain in the a..., we had to rebuild EVERY port (at least, I did, to avoid further problem). Yesterday, on of our fastes boxes got ready and even with a full rebuild of the system AND a full rebuild of the ports (no poudriere, traditional way via make), the Apache 2.4 webservice doesn't work, and so does subversion not (Firefox reports problems with SSL handshake, subversion is stuck/frozen forever). I will run today another full world build today, hopefully finishing on friday (portmaster -dfR doesn't get everything in line on some ports, I assume). oh I tracked the subversion hang down to a bug in serf (an Apache library used by subversion). It would also affect any other software using serf. The serf in ports will also have to be patched. I submitted your patch as a bug report to the serf port: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253214 -- Guido Falsi ___ 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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 03/02/21 07:16, Hartmann, O. wrote: On Mon, 1 Feb 2021 03:24:45 + Rick Macklem wrote: Rick Macklem wrote: Guido Falsi wrote: [good stuff snipped] Performed a full bisect. Tracked it down to commit aa906e2a4957, adding KTLS support to embedded OpenSSL. I filed a bug report about this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135 Apart from switching to svn:// scheme, another workaround is to build base using WITHOUT_OPENSSL_KTLS. Just fyi, when I tested the daemons I have for nfs-over-tls (which use ktls), they acted like things were ok (no handshake problems), but the data ended up on the wire unencrypted (nfs-over-tls doesn't do a SSL_write(), so it depends on ktls to do the encryption). Since these daemons work fine with openssl3 in ports/security/openssl-devel, I suspect the ktls backport is not quite right. I've sent jhb@ email. I was wrong on the above. I did a full buildworld/installworld and the daemons now seem to work with the openssl in head/main. Btw, did anyone try rebuilding svn from sources after doing the system upgrade? (The openssl library calls and .h files definitely changed.) Yes, I did, on all boxes and its a pain in the a..., we had to rebuild EVERY port (at least, I did, to avoid further problem). Yesterday, on of our fastes boxes got ready and even with a full rebuild of the system AND a full rebuild of the ports (no poudriere, traditional way via make), the Apache 2.4 webservice doesn't work, and so does subversion not (Firefox reports problems with SSL handshake, subversion is stuck/frozen forever). I will run today another full world build today, hopefully finishing on friday (portmaster -dfR doesn't get everything in line on some ports, I assume). Ass I said a confirmed woraround is building world with WITHOUT_OPENSSL_KTLS defined. -- Guido Falsi ___ 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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 01/02/21 04:24, Rick Macklem wrote: Rick Macklem wrote: Guido Falsi wrote: [good stuff snipped] Performed a full bisect. Tracked it down to commit aa906e2a4957, adding KTLS support to embedded OpenSSL. I filed a bug report about this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135 Apart from switching to svn:// scheme, another workaround is to build base using WITHOUT_OPENSSL_KTLS. Just fyi, when I tested the daemons I have for nfs-over-tls (which use ktls), they acted like things were ok (no handshake problems), but the data ended up on the wire unencrypted (nfs-over-tls doesn't do a SSL_write(), so it depends on ktls to do the encryption). Since these daemons work fine with openssl3 in ports/security/openssl-devel, I suspect the ktls backport is not quite right. I've sent jhb@ email. I was wrong on the above. I did a full buildworld/installworld and the daemons now seem to work with the openssl in head/main. Btw, did anyone try rebuilding svn from sources after doing the system upgrade? (The openssl library calls and .h files definitely changed.) The problem happens with svnlite from base, which should have been rebuilt and reinstalled with the system upgrade. I also tested with ports svn which I did rebuild in poudriere and force reinstalled. So, actually yes I did rebuild it, but I could force a new rebuild just to be sure. -- Guido Falsi ___ 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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 31/01/21 10:35, Hartmann, O. wrote: On Sat, 30 Jan 2021 16:22:50 +0100 Guido Falsi via freebsd-current wrote: On 30/01/21 12:34, Guido Falsi via freebsd-current wrote: On 30/01/21 11:25, Tomoaki AOKI wrote: On Sat, 30 Jan 2021 07:39:23 +0100 "Hartmann, O." wrote: We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri Jan 29 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the command make update issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is working like a snail! Hitting Ctrl-t on the console gives: load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188 kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61 amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports The system is idle otherwise. How can this be resolved? Is this phenomenon known? Kind regards and thank you very much in advance, O. Hartmann +1. IIRC, d6327ae8c11b was OK, but ebc61c86b556 is not. Unfortunately, I currently don't have enough time to bisect further. :-( I'm running 07d218f70c2f and it is affected, this restricts the range slightly more. I tried bisecting the kernel only between d6327ae8c11b and 07d218f70c2f, but got no results. Looks like the problem is not in the kernel but somewhere else (libc? ssl?) Bisecting the whole system is going to take longer. I'll try to find the time. We also have running a 14-CURRENT-based webserver with www/apach24. After upgrading from an earlier (working) 14-CURRENT (FreeBSD 14.0-CURRENT #40 main-c256208-geb61de5b787: Fri Jan 22 16:28:09 CET 2021 amd64), the reported phenomenon took place. I also have to admit that after main-c256208-geb61de5b787, the whole system has been rebuilt from a clean /usr/src (otherwise we use -DNO_CLEAN or its WITHOUT_CLEAN equivalent). Hopefully that helps. Performed a full bisect. Tracked it down to commit aa906e2a4957, adding KTLS support to embedded OpenSSL. I filed a bug report about this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135 Apart from switching to svn:// scheme, another workaround is to build base using WITHOUT_OPENSSL_KTLS. -- Guido Falsi ___ 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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 30/01/21 12:34, Guido Falsi via freebsd-current wrote: On 30/01/21 11:25, Tomoaki AOKI wrote: On Sat, 30 Jan 2021 07:39:23 +0100 "Hartmann, O." wrote: We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri Jan 29 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the command make update issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is working like a snail! Hitting Ctrl-t on the console gives: load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188 kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61 amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports The system is idle otherwise. How can this be resolved? Is this phenomenon known? Kind regards and thank you very much in advance, O. Hartmann +1. IIRC, d6327ae8c11b was OK, but ebc61c86b556 is not. Unfortunately, I currently don't have enough time to bisect further. :-( I'm running 07d218f70c2f and it is affected, this restricts the range slightly more. I tried bisecting the kernel only between d6327ae8c11b and 07d218f70c2f, but got no results. Looks like the problem is not in the kernel but somewhere else (libc? ssl?) Bisecting the whole system is going to take longer. I'll try to find the time. -- Guido Falsi ___ 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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 30/01/21 11:25, Tomoaki AOKI wrote: On Sat, 30 Jan 2021 07:39:23 +0100 "Hartmann, O." wrote: We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri Jan 29 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the command make update issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is working like a snail! Hitting Ctrl-t on the console gives: load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188 kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61 amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports The system is idle otherwise. How can this be resolved? Is this phenomenon known? Kind regards and thank you very much in advance, O. Hartmann +1. IIRC, d6327ae8c11b was OK, but ebc61c86b556 is not. Unfortunately, I currently don't have enough time to bisect further. :-( I'm running 07d218f70c2f and it is affected, this restricts the range slightly more. -- Guido Falsi ___ 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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 30/01/21 07:39, Hartmann, O. wrote: We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri Jan 29 16:29:50 CET 2021 amd64. After make delete-oldfiles/delete-old-libs, the command make update issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is working like a snail! Hitting Ctrl-t on the console gives: load: 0.06 cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188 kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61 amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports The system is idle otherwise. How can this be resolved? Is this phenomenon known? I'm seeing similar behaviour. Switching to the svn:// scheme was a successful workaround. -- Guido Falsi ___ 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: problem building virtualbox-ose-kmod
On 26/01/21 13:29, Dima Panov wrote: Moin! Stefan, please add check for __FreeBSD_version and fill PR or commit it directly with ports-secteam approval. There's a bug report for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252675 And another one which is marked as a duplicate of this. In the duplicate I posted a patch including the __FreeBSD_version check. Since you just gave approval for that I'll go ahead and commit, it should also be merged to 2021Q1, since it affects 13. -- Guido Falsi ___ 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"
