em soon?
>
> That is the plan
>
> --
> WBR
> Vladimir Kondratyev
>
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
t work?
>
> >
> >
> > For reference:
> >
> > CA76: cortex-a76 (aarch64)
> > CA7: cortex-a7 (armv7)
> >
> > # ls -dC1 /usr/obj/BUILDs/*/
> > /usr/obj/BUILDs/main-CA7-dbg-clang/
> > /usr/obj/BUILDs/main-CA7-nodbg-clang/
> > /usr/obj/BUILDs/main-CA76-dbg-clang/
> > /usr/obj/BUILDs/main-CA76-nodbg-clang/
> >
> > I do not use ~/src.configs/make.conf with
> > poudriere-devel for package builds. I avoid
> > doing package builds outside of poudriere
> > in normal circumstances.
> >
> > I normally do not build stable/* or releng/*.*
> > systems, just using official FreeBSD builds
> > for such. (Long ago I used to build more
> > variations.)
> >
> > I only build amd64 systems on amd64; I only
> > build aarch64 and armv7 on aarch64. (Long
> > ago I used to cross build little endian
> > systems on amd64.)
>
> We cross-build everything ;-)
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
reveu (segunda, 12/05/2025 à(s) 22:56):
> On May 12, 2025, at 14:02, Nuno Teixeira wrote:
>
> > Oh, thats nice!
>
> sjg provided something (SB_OBJROOT) that
> needs to be put to use for the purpose
> --but did not put that thing to any use.
>
> This gets back to my not
R}"
-- make DESTDIR="${BASEDIR}" installworld
-- etcupdate -D "${BASEDIR}"
-- bectl activate "${RELEASE}"
- reboot to new BE
2- make buildworld-jobs buildkernel-jobs
Curious to see what results will I have in phase 2.
Do I need to set any config variable?
Cheers,
; > > SB_OBJROOT so it should meet your need.
> > > I think ;-)
> > >
> > > And the above won't break our builds - which set SB_OBJROOT
> > > before running make.
> >
> > Looks to be working for both aarch64 and amd64 with
> > ~/src.
Same context of WITH_META_MODE, it will speed up for sure my builds,
tunning what parts/targets of llvm will be built:
> WITH_LLVM_TARGET_AARCH64=
> WITH_LLVM_TARGET_ARM=
> WITHOUT_LLVM_TARGET_MIPS=
> WITHOUT_LLVM_TARGET_POWERPC=
> WITHOUT_LLVM_TARGET_RISCV=
> WITHOUT_LLVM_TARGET_X86=
>
I will u
e" that I do in build world is:
/etc/src.conf:
WITH_MALLOC_PRODUCTION=yes
WITHOUT_LLVM_ASSERTIONS=yes
that might be incompatible with pkgbase since those settings are for
releases.
Cheers,
Mark Millard escreveu (terça, 6/05/2025 à(s) 17:52):
> On May 6, 2025, at 08:15, Nuno Teixeira
uilds expecially on rpi4.
Any hints are welcome.
Thanks,
Mark Millard escreveu (segunda, 5/05/2025 à(s) 23:18):
> Nuno Teixeira wrote on
> Date: Mon, 05 May 2025 20:37:09 UTC :
>
> > (...)
> >
> > Don't forget to `env NO_PKG_UPGRADE=yes beinstall.sh` to not mess w
(...)
This way i did have less compiling expecially on buildworld. My rpi4 is
recompiling allmost everything in buildworld phase using beinstall.sh.
I will use this mehod from now on.
Thanks very much for your great explanation!
Cheers,
Nuno Teixeira escreveu (segunda, 5/05/2025 à(s)
23:36
t compile
Cheers,
Mark Millard escreveu (segunda, 5/05/2025 à(s) 23:18):
> Nuno Teixeira wrote on
> Date: Mon, 05 May 2025 20:37:09 UTC :
>
> > (...)
> >
> > Don't forget to `env NO_PKG_UPGRADE=yes beinstall.sh` to not mess with
> > ports and stuff.
>
(...)
Don't forget to `env NO_PKG_UPGRADE=yes beinstall.sh` to not mess with
ports and stuff.
Nuno Teixeira escreveu (segunda, 5/05/2025 à(s)
21:34):
> Hello,
>
> Using incremental WITH_META_MODE builds, after installation with
> beinstall.sh, building same src, a complete co
Hello!
So nice, I can see now:
Skipping meta for ...: ...
some_file.meta: 23: file 'other' is newer than the target...
This is great!
Thank you so much,
Simon J. Gerraty escreveu (terça, 28/01/2025 à(s) 22:51):
> Nuno Teixeira wrote:
> > Just to check that I'm using
ll to show this as well)
/etc/src.conf:
WITH_MALLOC_PRODUCTION=yes
WITHOUT_LLVM_ASSERTIONS=yes
/etc/make.conf:
KERNCONF=GENERIC-NODEBUG
DEVELOPER=yes
DEVELOPER_MODE=yes
PORTSDIR=/home/nunotex/Work/freebsd/ports/main
DISTDIR=/Arq/DISTFILES
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web:
Nice! I will do that, `--with-xmlrpc-tinyxml2` directly on port config ala
linux distros.
Thanks!
Baptiste Daroussin escreveu (sexta, 27/12/2024 à(s)
14:54):
> On Fri 27 Dec 14:24, Nuno Teixeira wrote:
> > Perfect!
> >
> > I'm thinking using a radio option wher
c-tinyxml2
XMLRPC_LIB_DEPENDS= libxmlrpc.so:net/xmlrpc-c
XMLRPC_CONFIGURE_ON=--with-xmlrpc-c
```
Baptiste Daroussin escreveu (sexta, 27/12/2024 à(s)
13:17):
> On Fri 27 Dec 12:48, Nuno Teixeira wrote:
> > Hello Baptiste,
> >
> > Yes, this proves that my C skills are awesome
sexta, 27/12/2024 à(s)
12:35):
>
>
> 27 décembre 2024 à 13:13 "Nuno Teixeira" >
> a écrit:
>
> Hello,
>
> Looking for help to figure out a base64.h and tinyxml2:
> https://github.com/rakshasa/rtorrent/issues/1353
>
> Any help is welcome, t
j${JOB_MAX} buildworld > ../buildworld.log 2>&1
where JOB_MAX is derrived from ncpus in local.sys.mk if not set in
env.
---
because it is cool. I like cool stuff.
Cheers :)
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
; That laptop has 4C/8T & 32 GB RAM. This morning, it took:
>>
>> * 17:46 for stable/14-n269310-bbd018d0aaaf ->
>> stable/14-n269315-b21c677ed28a
>> (0:02 to update /usr/src; 17:44 to build; 0:00 to delete old libraries)
>>
>> * 24:03 for main-n273250-9d585
ldn't want to be throttling a 32x2 machine
> down to -j 14.
>
> Peace,
> david
> --
> David H. Wolfskill da...@catwhisker.org
> It has been said that history repeats itself. This is perhaps not quite
> correct; it merely rhymes. -- Theodor Reik
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
on a 32x2 Epyc running "make -j 112 buildworld".
>
> I have placed copies of the build typescript and the 2 meta files in
> https://www.catwhisker.org/~david/FreeBSD/head/n273073/
>
> I am about to try a similar build on a couple of smaller machines,
> but they may take a while to get to the point of failure.
>
> Peace,
> david
> --
> David H. Wolfskill da...@catwhisker.org
> It has been said that history repeats itself. This is perhaps not quite
> correct; it merely rhymes. -- Theodor Reik
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
Hello,
(kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)!
>> sysctl_warn_reuse: can't re-use a leaf
>>
>
Just upgraded my rpi4 to 8c44df321 (14/08) and I can confirm that it only
shows on bootup and when doing poudriere operations (zfs activity) as
mentioned in previous messages.
I
return val;
#endif
}
Commit is
https://cgit.freebsd.org/ports/commit/?id=4ffd449f0cfdbef7d1c78442ad3ea0be9ab12ea3
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
gt; Thanks,
>
> Kyle Evans
>
Upgraded today and tests builds and runs OK.
Thank you for ultra fast fix!
Cheers,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
t sigset_t *__restrict newsigmask))
| ^
/usr/include/ssp/poll.h:49:11: error: unknown type name 'sigset_t'
/usr/include/ssp/poll.h:49:11: error: unknown type name 'sigset_t'
3 errors generated.
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
vice via 'device filemon' in the kernel
> config file? or to just load it when rebuilding the system?
>
> There is man 4 filemon but nothing there to describe usage as .ko
> or device. System is n271321-9ae91f59c500 on arm64.
>
> --
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
(...)
commit 108de784513d87bbe850e7b003a73e26b5b54caa
Author: Val Packett
Date: Fri May 31 08:45:02 2024 -0600
Redefine CLOCK_BOOTTIME to alias CLOCK_MONOTONIC, not CLOCK_UPTIME
Nuno Teixeira escreveu (sábado, 1/06/2024 à(s) 09:01):
> Hello all,
>
> Anyone seeing this erro
^
./src/intel/common/xe/intel_gem.c:66:9: note: previous case defined here
66 |case CLOCK_MONOTONIC:
| ^
/usr/include/sys/_clock_id.h:56:26: note: expanded from macro
'CLOCK_MONOTONIC'
56 | #define CLOCK_MONOTONIC 4
| ^
1 error generated.
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
Hello,
Just upgraded to latest main at cadd2ca217
Boot menu shows up and then it stops earlier around:
..
FreeBSD clang version ...
No crash dump.
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
kernel boot.
>
> As workaround I already have kld_list+="uhid" in /etc/rc.conf. But IMHO
> it some regression.
>
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
that
usb devices was not detected at this time.
Anyone experience it?
Thanks
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
Working fine!
Thanks for fast fix.
Justin Hibbits escreveu (sexta, 17/05/2024 à(s)
13:57):
> On Fri, 17 May 2024 11:09:00 +0100
> Nuno Teixeira wrote:
>
> > Hello,
> >
> > tpm kernel module fails to load starting on main from May 9.
> > Updated today and same
bhyve/Win11.
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
> script the next dialog uses --mixedform, and restarts the script on
> > error, which it looks like is what you observe.
>
> Thanks for pointing that out, Jessica. I'll wait for the next 15
> snapshot and will check.
>
> I'm not sure about a good way to test it on a running system instead.
>
> --
> Renato Botelho
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
out it.
Thanks!
Dimitry Andric escreveu (terça, 30/04/2024 à(s) 18:45):
> On 30 Apr 2024, at 14:26, Nuno Teixeira wrote:
> >
> > I'm lost on build failure of audio/amsynth (updated to version 1.13.3)
> on recent main.
> > Thre strange thing is if I use llvm from ports,
ed from macro
'_LIBCPP_BEGIN_NAMESPACE_FILESYSTEM'
892 | inline namespace __fs
{ namespace filesystem {
|
^
mv -f src/.deps/amsynth-AudioOutput.Tpo src/.deps/amsynth-AudioOutput.Po
1 error generated.
---
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
(...)
Backup server is https://www.rsync.net/ (free 500GB for FreeBSD
developers).
Nuno Teixeira escreveu (quarta, 10/04/2024 à(s)
13:39):
> With base stack I can complete restic check successfully
> downloading/reading/checking all files from a "big" remote compressed
> ba
ing backup to check its
integrity.
Maybe someone could do a restic test to check if this is reproducible.
Thanks,
escreveu (quarta, 10/04/2024 à(s) 13:12):
>
>
> > On 10. Apr 2024, at 13:40, Nuno Teixeira wrote:
> >
> > Hello all,
> >
> > @ current 1500018
577594281s: connection lost
Connection continues UP.
Cheers,
escreveu (quinta, 28/03/2024 à(s) 15:53):
> > On 28. Mar 2024, at 15:00, Nuno Teixeira wrote:
> >
> > Hello all!
> >
> > Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop
> (
(...)
initial_turbo
https://www.raspberrypi.com/documentation/computers/config_txt.html#overclocking
Nuno Teixeira escreveu (domingo, 31/03/2024 à(s)
19:59):
> Hello,
>
> If you got a fan in your rpi4 box, you could try to overclock it.
> If not, there is a funcionality in c
t;
> i've tried increasing some of the USB timings (hw.usb.timings.*) but
> this didn't seem to have any effect. is there anything else i could try
> that might affect this, or is this perhaps a known issue?
>
> thanks, lexi.
>
--
Nuno Teixeira
FreeBSD Committer (ports)
t; > > > Ast's could be the right tool for this, but I'm super unfamiliar
> with
> > > > > them, and I can't find any docs on them.
> > > > >
> > > > > Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent
> to
> > > &
* rack 38
---
It would be so nice that we can have a sysctl tunnable for this patch
so we could do more tests without recompiling kernel.
Thanks all!
Really happy here :)
Cheers,
Nuno Teixeira escreveu (domingo, 17/03/2024 à(s) 20:26
clock() routine from
> userret(), in order to avoid tons of timer interrupts and context switches.
> To test this theory, you could apply a patch like:
It's affecting overall system performance, bonnie was just a way to
get some numbers to compare.
Tomorrow I will test patch.
Tha
sysctl.
> I have CCed Drew and Randall, who know much more about HPTS and might have
> follow up questions. I'll bring the issue up in the FreeBSD transport call
> next Thursday.
>
> What hardware are you using?
Laptop:
Legion 5-15IMH05 (Lenovo) - Type 82AU
Thanks!
--
Nuno Teixeira
FreeBSD Committer (ports)
o do as I can feel the entire OS is
being slow, without errors, just slow.
- Approx. results as test [2]
Nuno Teixeira
FreeBSD Committer (ports)
2982us 338us3072us1135us 591us3236us
Cheers,
--
Nuno Teixeira
FreeBSD Committer (ports)
date to bring
the rack stack with all its fixes in.
Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
--
Nuno Teixeira
FreeBSD Committer (ports)
, used by RACK and BBR.
As tuexen said, on main, loader.conf: tcp_rack_load="YES" will load
tcphpts.ko as I am seing in my rpi4 right now.
I'm testing it and check its performance.
I will test again on my amd64 laptop and run more tests too.
--
Nuno Teixeira
FreeBSD Committer (ports)
GENERIC that could lead to my slow
opearations problem
> options TCP_RACK
Don't think I need this one as I will use kernel module instead of
building it in kernel.
Resuming I only need to add:
options TCPHPTS
Is this correct?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
reveu (sábado, 16/03/2024 à(s) 09:40):
>
> On Sat, 16 Mar 2024 09:41:13 +0100
> tue...@freebsd.org wrote:
>
> > > On 16. Mar 2024, at 08:57, Nuno Teixeira wrote:
> > >
> > > Hello all,
> > >
> > > On a laptop i7/16MB ram, desktop use and port
Followed man tcp_rack:
loader.conf:
tcp_rack_load="YES"
sysctl.conf:
net.inet.tcp.functions_default=rack
poudriere have restricted access to network, usually for fetch distfiles.
escreveu (sábado, 16/03/2024 à(s) 08:41):
>
> > On 16. Mar 2024, at 08:57, Nuno Teixeira wrote
stead of option.
> >
> > It's not a typo, both spellings work, cf. config(5).
> Thank you very much for the hint. I did not know this. I wrote
> option in the article (for whatever reason) and tested the
> configs using options...
>
> Best regards
> Michael
> >
> > DES
> > --
> > Dag-Erling Smørgrav - d...@freebsd.org
>
--
Nuno Teixeira
FreeBSD Committer (ports)
e
> RACK stack.
>
> Please let me know if you have any questions.
>
> Best regards
> Michael
>
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
clude, builds will continue to
> find headers there that should be found in
> $STAGE_ROOT/common/usr/include and thus revert Makefile.depend changes.
> We added a mechanism to allow triggering auto-clean of stage tree when such
> changes are made.
>
> --sjg
>
--
Nuno Teixeira
FreeBSD Committer (ports)
(...)
-ansi == Same as -std=c89
So it seems correct to remove it when -std=c99 is used.
Nuno Teixeira escreveu no dia sexta, 29/12/2023 à(s)
12:03:
>
>
>
> I think we have two options:
>> 1. Build the ports with a C version of at least C99.
>>
>
> - Adding U
l"
Fix build.
Notes:
Adding USE_CSTD=c99 doesn't fix build by itself like we seen on some ports
that were fixed by it.
Something have changed from current 157 to 158.
> 2. Remove the inline from tcp_[gs]et_flags().
>
> Best regards
> Michael
> >
^
/usr/include/netinet/tcp.h:88:8: error: unknown type name 'inline'
88 | static inline void
|^
3 errors generated.
###
Any clues?
--
Nuno Teixeira
FreeBSD Committer (ports)
Dec 2023, at 13:22, Nuno Teixeira wrote:
> >
> > On every current upgrade I update efi/freebsd/loader.efi (amd64) and
> efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi.
> > For safety reasons I always have a copy of last running loader by
> appending "-o
eeded.
Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi
-> /boot/loader.efi ?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
Hello all,
Maybe not the best mailing to ask it but...
How do you update BIOS without Windows since most brands only have bios
software to windows?
I'm about to buy a new pc without windows license and I'm looking for
brands that have bios-cli that work in FreeBSD.
Thanks,
--
Nun
ording filesystem state for clean... done
---
Thanks!
Nuno Teixeira escreveu no dia sábado, 14/10/2023 à(s)
12:22:
> Hello all,
>
> I did try updating BETA1 -> BETA2, BETA2 -> BETA3, ..., BETA5 -> RC1 in
> poudriere:
>
> `poudriere jail -u -j JAIL -t 14.0-RC1`
>
stall the downloaded upgrades, run
"/tmp/poudriere.3homsGor/freebsd-update.1BURpmmK install".
Installing updates... done.
No updates are available to install.
Run '/tmp/poudriere.3homsGor/freebsd-update.1BURpmmK fetch' first.
[00:11:17] Error: Fail to upgrade system
---
Any clues
here:
>
> https://people.freebsd.org/~pi/logs/pou-fail.txt
> (short, only 1550 bytes)
>
> I have:
>
> 140 14.0-BETA2 amd64 http2023-09-16 08:20:01 /pou/jails/140
>
> with
>
> /usr/local/bin/poudriere installed by package
> poudriere-devel-3.3.99.20220831
>
> --
> p...@freebsd.org +49 171 3101372 Now what ?
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
end rc.conf
>
> begin hostapd-wlan0.conf
> interface=wlan0
> ctrl_interface=/var/run/hostapd-wlan0
> ctrl_interface_group=wheel
> ssid=[redacted]
> wpa=2
> wpa_passphrase=[redacted]
> wpa_key_mgmt=WPA-PSK
> wpa_pairwise=CCMP
> end hostapd-wl
domingo, 2/07/2023
à(s) 08:57:
> On Sun, 02 Jul 2023 14:41:55 +0900 (JST)
> Yasuhiro Kimura wrote:
>
> > From: Nuno Teixeira
> > Subject: ld-elf.so.1: Shared object "libssl.so.111" not found, required
> by "pkg" and others
> > Date: Sun, 2 Jul 2023 0
/2023 à(s)
09:15:
> Nuno Teixeira wrote on
> Date: Sun, 02 Jul 2023 05:22:48 UTC :
>
> > I'm returning to current and installed from
> > 20230622-b95d2237af40-263748-bootonly.iso
> > <
> https://download.freebsd.org/snapshots/amd64/amd64/ISO-IMAGES/14.0/FreeB
e last days with llvm15->llvm16,
openssl3, etc.
My question is when can I do a delete-old{-libs}?
I'm thinking building pkgs with a updated current on poudriere and then
clean up libs?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
(...)
Trying :
`zpool set feature@block_cloning=disabled zroot`:
cannot set property for 'zroot': property 'feature@block_cloning' can only
be set to 'disabled' at creation time
Nuno Teixeira escreveu no dia quarta, 12/04/2023 à(s)
13:57:
> Hello all,
>
t; present
> > .=
> > >
> > > >>>>>=20
> > > >>>>> I rememeber now really scraed that there was a HEADSUP in the
> list re
> > g=
> > > ard
> > > >>> ing
> > > >>>>> some serious ZFS
> > > >>>>> problems - I didn't find it right now.
> > > >>>>>=20
> > > >>>>> Thanks in advance,
> > > >>>>>=20
> > > >>>=20
> > > >>> That's fallout from the new block cloning feature, adding the
> author
> > > >>>=20
> > > >>=20
> > > >> Thanks.
> > > >>=20
> > > >> As of this moment, all systems with the newest kernel and the new
> ZFS op
> > t=
> > > ion=20
> > > >> enabled, crash -
> > > >> the reason is mostly in different ZFS datasets. I guess there is
> no way
> > b
> > > =
> > > ack
> > > >> once this faulty
> > > >> option is enabled?
> > > >=20
> > > > I've run a test on a scratch pool here, first without
> block_cloning=20
> > > > enabled, then with. There was no corruption when block_cloning was=20
> > > > disabled. There was corruption when block_cloning was enabled.
> > > >=20
> > > > I don't know of any way to revert back nor is there any way to fix
> or=20
> > > > recover the corrupted blocks.
> > >
> > > Is the corruption still present after EXDEV fixes?
> >
> > Yes and no.
> >
> > Yes, there is corruption when block_cloning is enabled.
> >
> > There is no corruption when block_cloning is disabled.
>
> I should add some detail to this.
>
> The corruption experienced when block cloning is disabled was fixed by:
>
> - eb1feadc201a
> - e2d997d1cbb9
> - d012836fb616 (specifically this commit)
> - 20be1b4fc4b7
>
> When block_cloning is enabled, the pool is corrupted. This has not been
> fixed.
>
>
> --
> Cheers,
> Cy Schubert
> FreeBSD UNIX: Web: https://FreeBSD.org
> NTP: Web: https://nwtime.org
>
> e^(i*pi)+1=0
>
>
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
Fixed at
https://cgit.freebsd.org/ports/commit/?id=fb22e1c2e3653558065ffa0509c3c020834723db
Thanks all,
Nuno Teixeira escreveu no dia sexta, 24/03/2023 à(s)
11:15:
> I'm thinking in the best plan to patch port.
> What about patch it for OSVERSION < 14 that will fix 12 and 13 and
.h
> and byteswap.h, it was a minefield of what can or can't be defined in the
> face
> of existing use.
>
> Warner
>
>
>> A+
>>
>> Paul
>>
>>
>>
>>
>>
--
Nuno Teixeira
FreeBSD Committer (ports)
. You could likely put that into the
> port.
>
> In releng/13 there is also infiniband/byteswap.h that does:
>
> #include
> #include
>
> #define bswap_16bswap16
> #define bswap_32bswap32
> #define bswap_64bswap64
>
> otis
>
> —
> Juraj Lutter
> o...@freebsd.org
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
t; On Fri, Mar 24, 2023, 9:23 AM Nuno Teixeira wrote:
>
>> Hello all,
>>
>> I'm getting a file not found on 12 and 13 compiling net/sflowtool latest
>> update:
>> It compile fine on 14.
>>
>> I've searched 14 src and found:
>> ---
>
o sflowtool.c
sflowtool.c:32:10: fatal error: 'byteswap.h' file not found
#include
^~~~
1 error generated.
*** [sflowtool.o] Error code 1
---
--
Nuno Teixeira
FreeBSD Committer (ports)
Hello Gary,
Thanks for the hint, I will try it.
I've forgot to mention a PR about it:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263620
Thanks,
Gary Jennejohn escreveu no dia terça, 7/03/2023 à(s) 15:11:
> On Tue, 7 Mar 2023 13:47:53 +0000
> Nuno Teixeira wrote:
>
einstall reinstall
===> Creating some important subdirectories
===> Starting chrooted make in /tmp/beinstall.6sMgsC/mnt...
cd: /tmp/mountpoint.CagxU8/usr/ports/x11/nvidia-driver: No such file or
directory
make: don't know how to make deinstall. Stop
---
Any hints?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
dec hex filename
22977071 1848409 4437760 29263240 0x1be8588 kernel.full
cd: /usr/ports/graphics/drm-kmod: No such file or directory
---
Any hint?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
Sorry, wrong post!
Nuno Teixeira escreveu no dia quarta, 2/11/2022 à(s)
21:44:
> Hello,
>
> From
> https://lists.freebsd.org/archives/freebsd-ports/2022-August/002476.html
>
> ---
> With both FLANG and MLIR:
> (...)
> [13:49:55] [01] [13:49:17] Finished devel/llvm13
obalISel.inc.d -o RISCVGenGlobalISel.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-instr-info -I /usr/src/contrib/llvm-project/llvm/include
> -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d
> RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc
> /u
Considering that morse could use same beep dsp code, instead of
repeating dsp code inside morse, why not use a dsp library or
something so that morse could use it without duplicating code?
Hans Petter Selasky escreveu no dia sábado, 29/10/2022
à(s) 19:22:
> On 10/29/22 20:18, Nuno Teixe
> Technically you could symlink the two - yes.
Can't understand how, what do I missing?
Hans Petter Selasky escreveu no dia sábado, 29/10/2022
à(s) 19:11:
> On 10/29/22 17:44, Nuno Teixeira wrote:
> > Hello Hans,
> >
> > A few days ago I tried beep and it remembe
15:36, Nuno Teixeira wrote:
> > Hello,
> >
> > unixcw is what I was looking for.
> > I think I will include it in some scripts just for fun :)
> >
> > I've started with base morse because it was nice if it can be updated to
> > play on dsp too.
> >
sábado, 29/10/2022 à(s) 14:01:
> On Fri, Oct 28, 2022 at 07:36:02PM +0100, Nuno Teixeira wrote:
> > Hello all,
> >
> > Is there any way to get sound from morse(6) without speaker(4) device?
>
> Any reason you can't just use unixcw from ports ?
> Or would ebook2
Hello all,
Is there any way to get sound from morse(6) without speaker(4) device?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
---
Cheers
Daniel Tameling escreveu no dia sábado,
24/09/2022 à(s) 14:47:
> On Wed, Sep 21, 2022 at 12:08:38PM +0100, Nuno Teixeira wrote:
> > Summary: Using bectl for upgrades
> >
> > RELEASE=Whatever
> > > bectl create ${RELEASE}
> > > bectl mount ${RELEASE}
>
he libs
> during the pkg rebuild.
>
> In the generic case I prefer to stay safe and keep the libs until I
> validated that nothing uses them anymore. That's the reason why I made
> the delete-old-libs functionality separate from delete-old already in
> the initial impleme
Hi Paul,
Really nice! I will test it soon.
Cheers
Paul Mather escreveu no dia quarta, 21/09/2022
à(s) 00:17:
> On Sep 20, 2022, at 6:19 PM, Alan Somers wrote:
>
> > On Tue, Sep 20, 2022 at 4:14 PM Nuno Teixeira
> wrote:
> >>
> >> Hello to all,
> >&g
(...)
maybe:
> yes | make DESTDIR=${BASEDIR} delete-old delete-old-libs
Nuno Teixeira escreveu no dia quarta, 21/09/2022 à(s)
00:09:
> Hi Alan,
>
> This general procedure works just as well if you're upgrading from source,
>> too.
>>
>> sudo make DEST
; etcupdate -D $BASEDIR
Need to find how to execute:
`make delete-old delete-old-libs` since $BASEDIR don't have /usr/src
Thanks
--
Nuno Teixeira
FreeBSD Committer (ports)
t
> reboot
...
if a problem happens, reboot default from BE loader
---
if everything fine destroy default and rename test to default
> bectl destroy -o default
> bectl rename test default
repeat on next upgrade
Don't know if a faster way exists with chroot or bectl jail...
Any hint
commit it.
Thanks to all and specially thanks to @emaste,
--
Nuno Teixeira
FreeBSD Committer (ports)
Hi,
Yes I understand it now! It's because I patched kernel for PR 265632
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265632>
Thanks and sorry for the noise,
Michael Gmelin escreveu no dia sexta, 26/08/2022 à(s)
18:03:
>
>
> On 26. Aug 2022, at 18:55, Nuno Teixeira
Hello to all,
Today I updated and uname -a shows main-n257625-587649902329-dirty.
Why is showing -dirty?
Cheers,
--
Nuno Teixeira
FreeBSD Committer (ports)
Hi all!
patch ready and tested at PR 265632
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265632>
Cheers,
Jung-uk Kim escreveu no dia quinta, 25/08/2022 à(s)
21:24:
> On 22. 8. 25., Nuno Teixeira wrote:
> > Hi!
> >
> > `pciconf -l | grep ^hdac`:
> > ---
edia
subclass = HDA
---
(LENOVO_VENDORID 0x17aa)
maybe:
#define LENOVO_L5INTEL_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x380f) ?
Jung-uk Kim escreveu no dia quinta, 25/08/2022 à(s)
20:15:
> On 22. 8. 25., Nuno Teixeira wrote:
> > ** Same config we
** Same config were imported from D30333
<https://reviews.freebsd.org/D30333> for Legion 5 AMD, PR 265632
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265632>for Intel version
Nuno Teixeira escreveu no dia quinta, 25/08/2022 à(s)
19:59:
> Hello,
>
> I have Lenovo Le
bsd.org/bugzilla/show_bug.cgi?id=265632>
for Legion 5 AMD:
(sys/dev/sound/pci/hda/hdac.h)
---
#define LENOVO_L5AMD_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x381b)
---
How do I found id for Intel version so I can submit a patch?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
@ main-n257521-97be6fced7db
Clean boot without warnings.
OK.
Thanks,
Nuno Teixeira escreveu no dia quinta, 18/08/2022 à(s)
12:04:
> Forgot to send a screenshot
> <https://people.freebsd.org/~eduardo/logs/boot%4020220817.JPG> for
> loader.efi @ main-n257458-ef8b872301c5
> (
reebsd/loader.efi
/boot/efi//efi/freebsd/loader.efi )
Someone talked about this warnings earlier:
---
Attempted extraction of recovery data from stadard superblock: failed
Attempt to find boot zone recovery data: failed
(...)
---
But it boots ok.
Cheers,
Nuno Teixeira escreveu no dia quarta, 17/08/20
*** and "EFI Hard Drive"(legacy /efi/boot/bootx64.efi) from BIOS.
^^^^
Nuno Teixeira escreveu no dia quarta, 17/08/2022 à(s)
19:14:
> Hi,
>
> And it's done:
> ---
> Boot0007* FreeBSD-14
>
1 - 100 of 151 matches
Mail list logo
