Re: /usr/src and /usr/ports not git directories ?

Warner Losh wrote in : |On Sat, Jan 25, 2025 at 10:50 AM Steffen Nurpmeso |wrote: |> Florian Walpen wrote in |> <4081188.p4y8TspHLy@z240>: |>|On Thursday, January 23, 2025 4:38:16 AM CET Florian Walpen wrote: |>|> Installing the src tree as a non-git snapshot is useless for |> developers

Re: /usr/src and /usr/ports not git directories ?

On Sat, Jan 25, 2025 at 10:50 AM Steffen Nurpmeso wrote: > Florian Walpen wrote in > <4081188.p4y8TspHLy@z240>: > |On Thursday, January 23, 2025 4:38:16 AM CET Florian Walpen wrote: > |> Installing the src tree as a non-git snapshot is useless for > developers \ > |> and > |> people that upd

Re: /usr/src and /usr/ports not git directories ?

Florian Walpen wrote in <4081188.p4y8TspHLy@z240>: |On Thursday, January 23, 2025 4:38:16 AM CET Florian Walpen wrote: |> Installing the src tree as a non-git snapshot is useless for developers \ |> and |> people that update through src builds, I agree with that. My take is that |> installing

Re: [9fans] /usr/src and /usr/ports not git directories ?

Bakul Shah wrote in : |[-9fans, +freebsd-current as 9fans adds a reply-to: 9fans line] |> On Jan 23, 2025, at 3:53 PM, Warner Losh wrote: |> |> I fail to see how putting code in the kernel is better than just \ |> using got for the few people that are alergic to git. Even if it \ |> is onl

Re: /usr/src and /usr/ports not git directories ?

em. Purely convenience, but it may save you from typing in those git commands / repo addresses you looked up on your smartphone. > But I don't agree about the static src tree being useless for people that do > binary updates, there are good reasons to build from ports. Also I would > i

Re: /usr/src and /usr/ports not git directories ?

longer analysis, of why src would be, imho, still shipped, is here: so yeah, i hope src and ports don't disappear from releases completely because i have number or cases where that would be good, including offline by accident, offline by design in high security environment, natural disa

Re: [9fans] /usr/src and /usr/ports not git directories ?

> On Jan 23, 2025, at 7:30 PM, Mark Millard wrote: > > Bakul Shah wrote on > Date: Fri, 24 Jan 2025 00:15:04 UTC : > >> [-9fans, +freebsd-current as 9fans adds a reply-to: 9fans line] >> >>> On Jan 23, 2025, at 3:53 PM, Warner Losh wrote: >>> >>> I fail to see how putting code in the kern

Re: [9fans] /usr/src and /usr/ports not git directories ?

Bakul Shah wrote on Date: Fri, 24 Jan 2025 00:15:04 UTC : > [-9fans, +freebsd-current as 9fans adds a reply-to: 9fans line] > > > On Jan 23, 2025, at 3:53 PM, Warner Losh wrote: > > > > I fail to see how putting code in the kernel is better than just using got > > for the few people that are

Re: [9fans] /usr/src and /usr/ports not git directories ?

[-9fans, +freebsd-current as 9fans adds a reply-to: 9fans line] > On Jan 23, 2025, at 3:53 PM, Warner Losh wrote: > > I fail to see how putting code in the kernel is better than just using got > for the few people that are alergic to git. Even if it is only 1000 lines in > plan 9, but likely m

Re: /usr/src and /usr/ports not git directories ?

Daniel Tameling wrote in : |On Thu, Jan 23, 2025 at 06:37:21AM +0100, Steffen Nurpmeso wrote: |> What i mean seems to be that these guys already have the knowledge |> how to access the object database without any fancy and featureful |> and fat environment, so if FreeBSD would do that then pos

Re: [9fans] /usr/src and /usr/ports not git directories ?

nfer exactly what |the goal is. Is the issue wanting to use git in a way that would require |it to be present within the base system, but encountering issues with doing |so due to licenses? The git present in 9front is MIT licensed, and \ |has already |been used in part for OpenBSD's game of

Re: /usr/src and /usr/ports not git directories ?

On Thu, Jan 23, 2025 at 06:37:21AM +0100, Steffen Nurpmeso wrote: > > What i mean seems to be that these guys already have the knowledge > how to access the object database without any fancy and featureful > and fat environment, so if FreeBSD would do that then possibly > a simple from scratch che

Re: /usr/src and /usr/ports not git directories ?

cally. For this you need the matching kernel source, which is there for binary updated systems (via freebsd-update). You only need the matching ports three or to ship the ports sources as part of the package itself, which might get ugly if there are lots of dependencies. But in any case, a sourc

Re: /usr/src and /usr/ports not git directories ?

urces + .git. ... |>>> One question, would that imply git in base? :-) |>> |>> Imply? No. ... |> Can it be achieved by net/gitup, which is BSD2CLAUSE licensed? |> If yes, is there any plan to pull it into base? |> |> I've never tried it, as I'm not enouch sure it w

Re: /usr/src and /usr/ports not git directories ?

mended version, it simply didn't build on 14.0. The remedy is clearly to build kernel module packages for every minor release, and there has been an attempt to do this recently, through a separate pkg repo I think. Don't know how "official" it is. Before that the solution was

Re: /usr/src and /usr/ports not git directories ?

Florian, On Thu, Jan 23, 2025 at 01:03:14AM +0100, Florian Walpen wrote: F> > I have already once tried this statement at a smaller audience - a F> > Russian-speaking telegram channel. One meaningful feedback I got F> > is that people may occasionally build stuff from ports

Re: /usr/src and /usr/ports not git directories ?

Gleb, On Tuesday, January 21, 2025 9:09:43 PM CET Gleb Smirnoff wrote: > I have same observations: /usr/src and /usr/ports as is is an atavism. > > I have already once tried this statement at a smaller audience - a > Russian-speaking telegram channel. One meaningful feedback I g

Re: /usr/src and /usr/ports not git directories ?

it config --local core.bare false > > > > > W> > > > > > W> This will clone 1 deep into the directory 'fred' and won't > > checkout a > > > > copy. > > > > > W> If > > > > > W> w

Re: /usr/src and /usr/ports not git directories ?

n't > checkout a > > > copy. > > > > W> If > > > > W> we make this a package, it's 325MB, as you say. That can then be > > > extracted > > > > W> and then you can recover the tree with: > > > > W> > > > &

Re: /usr/src and /usr/ports not git directories ?

't checkout a > > > copy. > > > > W> If > > > > W> we make this a package, it's 325MB, as you say. That can then be > > > extracted > > > > W> and then you can recover the tree with: > > > > W> > > > > W&

Re: /usr/src and /usr/ports not git directories ?

ed' and won't checkout a > copy. > > W> If > > W> we make this a package, it's 325MB, as you say. That can then be > extracted > > W> and then you can recover the tree with: > > W> > > W> % git checkout releng/14.2 > > W> &

Re: /usr/src and /usr/ports not git directories ?

u say. That can then be extracted > W> and then you can recover the tree with: > W> > W> % git checkout releng/14.2 > W> > W> which could be done with the pkg file when extracting to /usr/src. I've not > W> measured > W> ports. > > I really like th

Re: /usr/src and /usr/ports not git directories ?

2 W> W> which could be done with the pkg file when extracting to /usr/src. I've not W> measured W> ports. I really like this plan. So before checkout .git is 337M and after checkout it is 975M, which is made by actual sources + .git. Let's go forward with shipping this bare c

Re: /usr/src and /usr/ports not git directories ?

t; I think what you want is % git clone https://github.com/freebsd/freebsd-src --depth=1 -b releng/14.2 --single-branch fred --bare % cd fred % mkdir .git % mv * .git % git config --local core.bare false This will clone 1 deep into the directory 'fred' and won't checkout a copy.

Re: /usr/src and /usr/ports not git directories ?

On Tue, 21 Jan 2025, at 21:29, Warner Losh wrote: >> Do you mean have the "install src" checkbox invoke git clone? >> That seems like a better idea, at least to me. This wouldn't be ideal for small systems or any area with lousy internet. > I think we should replace the populate /usr/src from a

Re: /usr/src and /usr/ports not git directories ?

s who don't make local |> mods it might be sufficient. |> |>> On January 21, 2025 10:09:43 PM GMT+02:00, Gleb Smirnoff < |> gleb...@freebsd.org> wrote: |>> ... |>>>I think that /usr/src and /usr/ports as part of FreeBSD release |>>>distribu

Re: /usr/src and /usr/ports not git directories ?

On Tue, 21 Jan 2025 17:11:02 -0500 Brandon Allbery wrote: > I would offer a data point: the first thing I did was install sudo from a > package. The second thing I did was replace it with a build from the ports > package installed with 14.2-RELEASE… which _downgraded_ it. This seems

Re: /usr/src and /usr/ports not git directories ?

Yes, the pkg was 1.9.16p2, the build from ports.tgz was 1.9.16p1. (The one from ports HEAD as of a few days ago was 1.9.16p2_1, FWIW.) I'm still getting used to the little changes since the last time I ran FreeBSD (back around 5-CURRENT). On Tue, Jan 21, 2025 at 5:43 PM Tomoaki AOKI wrote:

Re: /usr/src and /usr/ports not git directories ?

I would offer a data point: the first thing I did was install sudo from a package. The second thing I did was replace it with a build from the ports package installed with 14.2-RELEASE… which _downgraded_ it. This seems bad for any security-impacting port. On Tue, Jan 21, 2025 at 4:37 PM Tomek

Re: /usr/src and /usr/ports not git directories ?

something locally (i.e., custom kernel with genuine world, only some specific leaf ports needs non-default options), src and/or ports package that exactly matches what other parts are built from would be wanted, and it could be difficult for newbies determining at which commit they'd been

Re: /usr/src and /usr/ports not git directories ?

ource, has minimal overhead and also lets > users update > or turn the shallow checkout into a deep one, etc. A shallow checkout is > quite a bit > less than a full tree, though still more than just the raw files. I've not > done poking to > see size comparisons. Still having

Re: /usr/src and /usr/ports not git directories ?

ods it might be sufficient. > > > > On January 21, 2025 10:09:43 PM GMT+02:00, Gleb Smirnoff < > gleb...@freebsd.org> wrote: > > ... > > >I think that /usr/src and /usr/ports as part of FreeBSD release > > >distribution should just go away. But we should pr

Re: /usr/src and /usr/ports not git directories ?

tail git does, but seemingly it would download modified files while saving for re-use those that haven't changed. For users who don't make local mods it might be sufficient. > On January 21, 2025 10:09:43 PM GMT+02:00, Gleb Smirnoff > wrote: > ... > >I think that /usr/src a

Re: /usr/src and /usr/ports not git directories ?

On Tue, Jan 21, 2025 at 9:09 PM Gleb Smirnoff wrote: > On Sat, Jan 18, 2025 at 09:29:03AM -0800, bob prohaska wrote: > b> (..) > b> The most visible problem is lack of a /usr/src/.git directory. Can > b> the existing src and ports directories be salvaged? > (..) > I t

Re: /usr/src and /usr/ports not git directories ?

not shipping src in installer? what could possibly go wrong! i was just thinking of this the other day. that installers are self-contained packages that come with os and it's source... On January 21, 2025 10:09:43 PM GMT+02:00, Gleb Smirnoff wrote: ... >I think that /usr/src and /u

Re: /usr/src and /usr/ports not git directories ?

Bob, On Sat, Jan 18, 2025 at 09:29:03AM -0800, bob prohaska wrote: b> A fresh install of b> FreeBSD-15.0-CURRENT-amd64-20250102-3d0a0dda3a7d-274510-memstick.img b> set up without much difficulty and Xorg seems to work out of the box b> on my Lenovo t400s. Both src and ports dire

Re: /usr/src and /usr/ports not git directories ?

On Sat, 18 Jan 2025 09:29:03 -0800 bob prohaska wrote: > A fresh install of > FreeBSD-15.0-CURRENT-amd64-20250102-3d0a0dda3a7d-274510-memstick.img > set up without much difficulty and Xorg seems to work out of the box > on my Lenovo t400s. Both src and ports directories were

Re: /usr/src and /usr/ports not git directories ?

o work out of the box > > on my Lenovo t400s. Both src and ports directories were installed by > > bsdinstall, but an attempt to run git pull in the src directory failed > > with "not a git repository", even though .git entries are present. > > > > The most visi

Re: /usr/src and /usr/ports not git directories ?

On Sat, Jan 18, 2025 at 09:29:03AM -0800, bob prohaska wrote: > A fresh install of > FreeBSD-15.0-CURRENT-amd64-20250102-3d0a0dda3a7d-274510-memstick.img > set up without much difficulty and Xorg seems to work out of the box > on my Lenovo t400s. Both src and ports directories were

/usr/src and /usr/ports not git directories ?

A fresh install of FreeBSD-15.0-CURRENT-amd64-20250102-3d0a0dda3a7d-274510-memstick.img set up without much difficulty and Xorg seems to work out of the box on my Lenovo t400s. Both src and ports directories were installed by bsdinstall, but an attempt to run git pull in the src directory failed

Re: UEFI + SOL / COM ports = boot hang

The default state of this server is that FreeBSD hangs when booting off UEFI and the COM ports are enabled. That seems to be because console includes or adds "efi" by default. Under every circumstance I've tested, when console contains "efi", the server hangs at th

UEFI + SOL / COM ports = boot hang

I have a Quanta D52B-1U server. When I boot it via legacy BIOS, there is no issue. When I boot with UEFI and COM ports & console redirection disabled, there is no issue. However, when boot UEFI and enable the COM ports and/or console redirection, the server hangs at boot time right

Re: A few good ports on release iso images ?

each release. > > > -- > Rod Grimes rgri...@freebsd.org Currently, IIRC, DVD image contains at least some of pkgs, while other images contains none. What would be useful for ALL images would be: *ports-mgmt/pkg, *All (at least, n

Re: A few good ports on release iso images ?

> Shawn Webb writes: > > > While probably less efficient than just running the tools outright, I > > usually just set up a tmpfs that I chroot into and install those kinds > > of packages. > > Yeah, I do something similar, with the footnote that I more often than > not have no internet connection

Re: A few good ports on release iso images ?

Shawn Webb writes: > While probably less efficient than just running the tools outright, I > usually just set up a tmpfs that I chroot into and install those kinds > of packages. Yeah, I do something similar, with the footnote that I more often than not have no internet connection, so I

Re: A few good ports on release iso images ?

On Tue, Jul 30, 2024 at 07:07:51PM +, Poul-Henning Kamp wrote: > I do not want want this to turn into a everything-and-Emacs bloat-party, > but I would find it really helpful if our install-ISO images had two > HW-spelunking ports installed: > > sysutils/smartmo

Re: A few good ports on release iso images ?

On 2024-07-30 19:07 +, Poul-Henning Kamp wrote: > sysutils/smartmontools > > and > > sysutils/dmidecode > > Is that even possible ? > > Am I the only one who thinks so ? I have missed having these tools numerous times over the years. Whether it's installing on a new machine

A few good ports on release iso images ?

I do not want want this to turn into a everything-and-Emacs bloat-party, but I would find it really helpful if our install-ISO images had two HW-spelunking ports installed: sysutils/smartmontools and sysutils/dmidecode Is that even possible ? Am I the only one who thinks so

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

schrieb FreeBSD User: >> >>> Hello, >> >>> >> >>> after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> >> >>> 1.21.0 on CURRENT >> >>> and 14-STABLE, I can't update several ports: >> >

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

Am Tue, 9 Apr 2024 17:10:52 +0200 Rainer Hurling schrieb: > Am 09.04.24 um 09:20 schrieb Baptiste Daroussin: > > On Sat 06 Apr 09:23, Rainer Hurling wrote: > >> Am 06.04.24 um 09:05 schrieb FreeBSD User: > >>> Hello, > >>> > >>> afte

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

Am 09.04.24 um 09:20 schrieb Baptiste Daroussin: On Sat 06 Apr 09:23, Rainer Hurling wrote: Am 06.04.24 um 09:05 schrieb FreeBSD User: Hello, after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 on CURRENT and 14-STABLE, I can't update several ports: www/

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

Am 06.04.24 um 09:56 schrieb FreeBSD User: Am Sat, 6 Apr 2024 09:23:30 +0200 Rainer Hurling schrieb: Am 06.04.24 um 09:05 schrieb FreeBSD User: Hello, after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 on CURRENT and 14-STABLE, I can't update several por

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

On Sat 06 Apr 09:23, Rainer Hurling wrote: > Am 06.04.24 um 09:05 schrieb FreeBSD User: > > Hello, > > > > after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> > > 1.21.0 on CURRENT and > > 14-STABLE, I can't update several ports:

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

On Sat 06 Apr 09:05, FreeBSD User wrote: > Hello, > > after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 > on CURRENT and > 14-STABLE, I can't update several ports: > > www/apache24 > databases/redis > > pkg core dumps while

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg-static core dumps on some ports

Am Sat, 6 Apr 2024 09:05:00 +0200 FreeBSD User schrieb: > Hello, > > after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 > on CURRENT and > 14-STABLE, I can't update several ports: > > www/apache24 > databases/redis > > pkg co

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

Am 06.04.24 um 09:05 schrieb FreeBSD User: Hello, after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 on CURRENT and 14-STABLE, I can't update several ports: www/apache24 databases/redis pkg core dumps while performing installation. apache24 and redis are

pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

Hello, after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 on CURRENT and 14-STABLE, I can't update several ports: www/apache24 databases/redis pkg core dumps while performing installation. apache24 and redis are ports I realized this misbehaviour on ALL 1

Re: git repo ports issues?

Yuri wrote: > Hi Jamie, > > > This was a faulty script where 2023 wasn't changed to 2024. > > Thanks for the notice. Ahh, ok, I did think it was probably a bit more than coincidence that it was exactly 1 year to the day! Cheers for the quick reply, Jamie

Re: The ports quarterly tree 2023Q4 is borked for www/firefox

/show_bug.cgi?id=275814 Should be fixed by: https://cgit.freebsd.org/ports/commit/?h=2023Q4&id=ec15ee20bdd912ca31982b1be0062da5fb783ac7 -Dimitry awesome ! we have liftoff once again : hydra# hydra# poudriere ports -l 2023Q4git+ssh 2023-12-18 12:29:26 /usr/local/poudriere/ports/2023Q4 h

Re: The ports quarterly tree 2023Q4 is borked for www/firefox

ug.cgi?id=275814 Should be fixed by: https://cgit.freebsd.org/ports/commit/?h=2023Q4&id=ec15ee20bdd912ca31982b1be0062da5fb783ac7 -Dimitry

The ports quarterly tree 2023Q4 is borked for www/firefox

I do not know where else to post this. Seems that a bug report about the problem does not mean much : Bug 275814 - www/firefox has the wrong version in the Makefile https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275814 This issue is pretty clear. This morning I flushed out my ports tree

Re: something magic about the size of a ports tree

On 2023-10-03 12:24, Dag-Erling Smørgrav wrote: Matthias Apitz writes: I have on my poudriere build host a ports tree and wanted to move it to the host where the resulting packages are installed: root@jet:/usr/local/poudriere/ports # du -sh ports20230806 397Mports20230806 root@jet:/usr

Re: something magic about the size of a ports tree

Warner Losh writes: > Do we support any compression on top of that? Has support for > poudriere been added for it? Yes (zstd) and no. DES -- Dag-Erling Smørgrav - d...@freebsd.org

Re: something magic about the size of a ports tree

On Tue, Oct 3, 2023, 10:24 AM Dag-Erling Smørgrav wrote: > Matthias Apitz writes: > > I have on my poudriere build host a ports tree and wanted to move it to > > the host where the resulting packages are installed: > > > > root@jet:/usr/local/poudriere/ports # du

Re: something magic about the size of a ports tree

1400094? >> > > Yes, on jet it is ZFS: > > root@jet:/usr/local/poudriere/ports # mount | grep ports2023 > poudriere/poudriere/ports/ports20230806 on > /usr/local/poudriere/ports/ports20230806 (zfs, local, noatime, nfsv4acls) > > on c720-1400094 it is only plain UFS. >

Re: something magic about the size of a ports tree

With ZFS, you might be using transparent compression. "du -sh" will show you a file's compressed size. But "ls -lh" will show you the logical size. That's probably why the tarball looked so much bigger than the ports tree on the first system. If you do "du -s

Re: something magic about the size of a ports tree

El día martes, octubre 03, 2023 a las 06:14:23p. m. +0200, Olivier Certner escribió: > Hi Matthias, > > Some ZFS dataset with zstd compression on jet, and no compression on > c720-1400094? > Yes, on jet it is ZFS: root@jet:/usr/local/poudriere/ports # mount | grep port

Re: something magic about the size of a ports tree

Matthias Apitz writes: > I have on my poudriere build host a ports tree and wanted to move it to > the host where the resulting packages are installed: > > root@jet:/usr/local/poudriere/ports # du -sh ports20230806 > 397Mports20230806 > root@jet:/usr/local/poudriere/po

Re: something magic about the size of a ports tree

Hi Matthias, Some ZFS dataset with zstd compression on jet, and no compression on c720-1400094? -- Olivier Certner

something magic about the size of a ports tree

I have on my poudriere build host a ports tree and wanted to move it to the host where the resulting packages are installed: root@jet:/usr/local/poudriere/ports # du -sh ports20230806 397Mports20230806 root@jet:/usr/local/poudriere/ports # tar cf p.tar ports20230806 root@jet:/usr/local

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

://git.freebsd.org/ports.git` work for you? (currently it's not working from where I am). Maybe related. Best Michael Today, yes. Sorry for not replying sooner, Gmail sent your 2nd September email to spam. % pwd /tmp % time git clone https://git.freebsd.org/ports.git && rm -r ports

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

On Sat, 2 Sep 2023 09:53:38 +0100 Graham Perrin wrote: > Some inspections are extraordinarily time-consuming. Others complete > very quickly, as they should. > > One recent inspection took more than half an hour. > > Anyone else? > Does `git clone https://git.freebsd.org/ports.git` work f

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

On 9/2/23, Graham Perrin wrote: > On 02/09/2023 10:17, Mateusz Guzik wrote: >> On 9/2/23, Graham Perrin wrote: >>> Some inspections are extraordinarily time-consuming. Others complete >>> very quickly, as they should. >>> >>> One recent inspection took more than half an hour. >>> >>> Anyone else?

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

On 02.09.2023 09:32, Graham Perrin wrote: On 02/09/2023 10:17, Mateusz Guzik wrote: get a flamegraph with dtrace https://github.com/brendangregg/FlameGraph See for a PDF of a reply that probably did not reach the list. Graham, th

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

On 02/09/2023 10:17, Mateusz Guzik wrote: On 9/2/23, Graham Perrin wrote: Some inspections are extraordinarily time-consuming. Others complete very quickly, as they should. One recent inspection took more than half an hour. Anyone else? A screenshot: % pkg

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

On 9/2/23, Graham Perrin wrote: > Some inspections are extraordinarily time-consuming. Others complete > very quickly, as they should. > > One recent inspection took more than half an hour. > > Anyone else? > > A screenshot: > > % pkg iinfo poudriere-devel > poudr

kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

Some inspections are extraordinarily time-consuming. Others complete very quickly, as they should. One recent inspection took more than half an hour. Anyone else? A screenshot: % pkg iinfo poudriere-devel poudriere-devel-3.3.99.20220831 % uname -aKU FreeBSD m

Re: ports-mgmt/portconf – not src.conf(5) – to specify multiple flavours of a port for buildkernel purposes

l.log, rocks with laughter at innumerable warnings, cancels, … make[4028]: "/usr/ports/Mk/bsd.port.mk" line 5393: warning: duplicate script for target "sumo" ignored make[4028]: "/usr/ports/Mk/Uses/kmod.mk" line 74: warning: using previous script for "sumo&

ports-mgmt/portconf – not src.conf(5) – to specify multiple flavours of a port for buildkernel purposes

No manual entry for ports.conf % apropos ports.conf apropos: nothing appropriate % rg -i -e 'ports\.conf' /usr/doc/website/content/en % rg -i -e 'ports\.conf' /usr/doc/documentation/content/en % – and so on. As far as I can tell, it's not documented in the usual places.

Re: OpenSSL 3 ports fallout

Gleb Popov wrote on Date: Sun, 13 Aug 2023 20:30:48 UTC : > Some of the ports I'm using are failing to build after OpenSSL 3 > import due to the following problem. OpenSSL headers that are shipped > in base contain declarations of various deprecated functions for which > lib

OpenSSL 3 ports fallout

Some of the ports I'm using are failing to build after OpenSSL 3 import due to the following problem. OpenSSL headers that are shipped in base contain declarations of various deprecated functions for which libcrypto.so doesn't contain definitions. Some of them are RSA_generate_key and ER

CURRENT with ZFS not bootable when built with LLVM from ports

Building -CURRENT (2023-07-17 be4c7f273508) without system compiler (with LLVM16 from ports) results in unbootable system:Preloaded elf kernel "/boot/kernel/kernel" at 0x82328000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0x82329090. Preloaded boot_

Re: Problem compiling py-* ports

and al > py-* ports fail with the following message.sincerelyFilippo > > FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #6 > main-n261981-63b113af5706: Tue Apr  4 16:57:47 CEST 2023 > filippo@STING:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 > > you are on a zfs commit with k

Re: Problem compiling py-* ports

On 4/18/23, Filippo Moretti wrote: > Good morning, I run this versione of Frrebsd and al > py-* ports fail with the following message.sincerelyFilippo > > FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #6 > main-n261981-63b113af5706: Tue Apr 4 16:57:47 CEST

Re: Problem compiling py-* ports

After following the instructions provided I get the following:==>>> All >> py39-pygments-2.14.0 (1/9) ===>  Building for py39-pygments-2.15.0 /usr/local/bin/python3.9: No module named build *** Error code 1 Stop. make: stopped in /usr/ports/textproc/py-pygments ===>>

Re: Problem compiling py-* ports

for all affected > hosts with dependent software is not the best solution. Depending on your situation, it might or might not be faster than trying to identify the exact offending files and just removing them ;) -- Felix Palmen {private} fe...@palmen-it.de -- ports committer (mentee)

Re: Problem compiling py-* ports

> On 18 Apr 2023, at 11:12, Filippo Moretti wrote: > > Good morning, >I run this versione of Frrebsd and al py-* ports fail > with the following message. > sincerely > Filippo Maybe this helps: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269545#c6

Re: Problem compiling py-* ports

W dniu 18.04.2023 o 10:46, Felix Palmen pisze: * Filippo Moretti [20230418 08:12]:   File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 31, in     if isinstance(ob, importlib_metadata.MetadataPathFinder) AttributeError: module 'importlib_metadata' has no attribute

Re: Problem compiling py-* ports

d remove them if necessary) and then do a rebuild. You can avoid this class of issues using poudriere btw... -- Felix Palmen {private} fe...@palmen-it.de -- ports committer (mentee) --{web} http://palmen-it.de {pgp public key} http://palmen-it.de/pub.txt {pgp fingerpri

Problem compiling py-* ports

Good morning,   I run this versione of Frrebsd and al py-* ports fail with the following message.sincerelyFilippo FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #6 main-n261981-63b113af5706: Tue Apr  4 16:57:47 CEST 2023 filippo@STING:/usr/obj/usr/src/amd64.amd64/sys

Re: Unusual errors on recent stable/13 22-Dec-2022 (a related problem report on freebsd-ports?)

t is happening. Is this just happening to me? It > > >> appears that the ZFS code has been updated recently, and I'm wondering > > >> whether a regression has crept in. [Or it could just be my hardware?] > > > > > > > > > https://lists.f

Re: Unusual errors on recent stable/13 22-Dec-2022 (a related problem report on freebsd-ports?)

t; >> whether a regression has crept in. [Or it could just be my hardware?] > > > > > > https://lists.freebsd.org/archives/freebsd-ports/2022-December/003153.html > > > > indicates a problem with tmpfs use such that using USE_TMPFS=no > > avoids a problem f

Re: Has anyone tried to build QEMU from ports lately?

On 10/11/22 04:20, Dennis Clarke wrote: On 10/10/22 17:53, Warner Losh wrote: On Mon, Oct 10, 2022 at 10:56 AM Warner Losh wrote: I know what's causing this problem. I'll resolve. tl/dr: _pv_entry.h depends on sys/param.h being included before its use. https://reviews.freebsd.org/D36927 f

Re: Has anyone tried to build QEMU from ports lately?

ules... can't find '/etc/hostid' can't find '/boot/entropy' Using DTB provided by EFI at 0x87efb000. Kernel entry at 0xf680002e... Kernel args: (null) ---<>--- GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2

Re: Has anyone tried to build QEMU from ports lately?

rm-bsd-user.fa.p/bsd-user_signal.c.o >> FAILED: libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o >> cc -m64 -mcx16 -Ilibqemu-arm-bsd-user.fa.p -I. -I.. -Itarget/arm >> -I../target/arm -I../common-user/host/x86_64 -I../bsd-user/include >> -Ibsd-user/freebsd -I../bsd-user/

Re: Has anyone tried to build QEMU from ports lately?

er/host/x86_64 -I../bsd-user/include > -Ibsd-user/freebsd -I../bsd-user/freebsd -I../bsd-user/host/x86_64 > -Ibsd-user -I../bsd-user -I../bsd-user/arm -Iqapi -Itrace -Iui > -Iui/shader -I/usr/local/include/capstone > -I/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004

Has anyone tried to build QEMU from ports lately?

/host/x86_64 -I../bsd-user/include -Ibsd-user/freebsd -I../bsd-user/freebsd -I../bsd-user/host/x86_64 -Ibsd-user -I../bsd-user -I../bsd-user/arm -Iqapi -Itrace -Iui -Iui/shader -I/usr/local/include/capstone -I/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb -I

Re: Header symbols that shouldn't be visible to ports?

On 7 Sep 2022, at 15:55, Cy Schubert wrote: > > This is exactly what happened with DMD D. When 64-bit statfs was introduced > all DMD D compiled programs failed to run and recompiling didn't help. The > DMD upstream failed to understand the problem. Eventually the port had to > be removed. I’

Re: Header symbols that shouldn't be visible to ports?

er releases won't run correctly on newer ones. Would it > > > > make sense to guard these symbols so they can't be used by programs in > > > > the ports tree? There is some precedent for that, for example > > > > _WANT_SOCKET and _WANT_MNTOPTNAMES. &g

Re: Header symbols that shouldn't be visible to ports?

ities in the base system like ps and ifconfig, but aren't > > > stable across major releases. Since they aren't stable, utilities > > > built for older releases won't run correctly on newer ones. Would it > > > make sense to guard these symbols so they can&#x

  1   2   3   4   5   6   7   8   9   10   >