Re: Gitea Package Maintainers
On Wed, Jul 13, 2022 at 10:08 AM Stefan Bethke wrote: > > Am 13.07.2022 um 00:42 schrieb 6543 <6...@obermui.de>: > > > > > > Hello stb, > > > > > > I'm building a matrix room, for gitea package maintainers, since you where > > mentioned at > > https://www.freebsd.org/cgi/ports.cgi?query=gitea&stype=all&sektion=all, > > I'd like to invite you. > > > > > > If you have an matrix account please tell me your username so I can add you. > > > > the main goal is to communicate if a new release will be published soon > > because of security fixes ... > > Would you mind explaining who you are and what your connection to FreeBSD > and/or the Gitea projects are? > > Stefan > 6543 is a developer/maintainer with the Gitea project. Thanks, Kyle Evans
Re: Cannot build within a new 13.1 arm64.aarch64 poudriere jail
On Wed, Oct 12, 2022 at 6:46 PM Naram Qashat wrote: > > I recently created a brand new FreeBSD 13.1 jail for arm64.aarch64 on my > amd64 poudriere. I am using poudriere-devel 3.3.99.20220713. > > I created the jail using the following command: > > poudriere jail -c -m src=/usr/src -b -J 12 -j local_aarch64 -a > arm64.aarch64 > > My /usr/src is on the releng/13.1 branch. > > Immediately after that, I attempted the following: > > poudriere bulk -j local_aarch64 ports-mgmt/pkg > > It fails at the configure stage, saying no working C compiler was found. > Full log is here: > > https://poudriere.cyberbotx.com:8766/data/local_aarch64-default/2022-10-10_20h05m42s/logs/errors/pkg-1.18.4.log > > Oddly, if I run the above bulk command with -i included, when I am > dropped into the jail's shell and move into pkg's work directory and do > ./configure, it progresses just fine. > > What I'm not sure is if there is something wrong with how I created my > jail or with poudriere or something with 13.1 for aarch64. > > Any help with this issue would be appreciated. > This is the result of native-xtools producing a broken compiler. I fixed it here: 3afe1c2e181 It was then re-broken here: 70c04943208 I have a review to re-fix it here: https://reviews.freebsd.org/D36981 You can follow-along here to get notified when the fix hits stable/13: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267026 Thanks, Kyle Evans
Re: How do I determine the ABI string used by pkg?
On Sat, Mar 4, 2023 at 11:10 PM Ian Smith wrote: > > On 2 March 2023 6:50:13 pm AEDT, Mel Pilgrim > wrote: > > I need to determine the ABI string pkg uses on a given system, and > > need to do so when there are no pkgs installed. > > # pkg -N -vv | grep ABI > > gets you ABI and ALTABI; the former is the amd64 form, the latter x86:64 > Note the more concising spelling of this if you know the names (or need it for, say, scripting): # pkg config ABI # pkg config ALTABI Thanks, Kyle Evans
Re: How do I determine the ABI string used by pkg?
On Tue, Mar 7, 2023 at 11:34 PM Mel Pilgrim wrote: > > On 2023-03-07 19:56, Tatsuki Makino wrote: > > Hello. > > > > Are you still saying that you are creating another program that does not > > rely on the pkg command? > > Then again, let's look at elf_tables.h. > > It would be necessary to have such a conversion table. > > Yeah basically. It pulls the pkg source as a build dependency and > includes what it needs from there. It's a hack, though. All that's > needed to obviate it entirely would be for the unbootstrapped `pkg -N > -vv` to have functional parity with its bootstrapped counterpart, and > that's slated for my next pet-project time slot. > For the giggles, I implemented[0] a `pkg -N config` that allows executing the equivalent of pkg-config(8), but for the bootstrap. It has a caveat that the bootstrap doesn't actually know about ALTABI, and it can't currently dump the UCL object entries (list/object). It's not really how -N was intended to be used at all, but maybe bapt has a better idea for exposing it (I kind of like the general idea, even if not this exact way to invoke it). Thanks, Kyle Evans [0] https://people.freebsd.org/~kevans/pkg-config.diff
Re: INDEX-12 gotten by portsnap is not updated
On Wed, May 3, 2023 at 10:50 PM Tatsuki Makino wrote: > > Hello. > > It appears that INDEX-12 (DESCRIBE.12) has not been updated by portsnap for > several days. > For example, gstreamer1 remains in the following version > > > zgrep -e ^gstreamer1-1 /var/db/portsnap/files/e24b4779*a78a1f31.gz | cut -f > > 1 -d \| > gstreamer1-1.22.0_1 > > Is it under some kind of maintenance? > > Regards. > Not sure if Colin subscribes to ports@, so looping him in explicitly. Thanks, Kyle Evans
Re: Correct install locations for things using the base system make infrastructure
On 8/23/23 17:15, Mark Johnston wrote:
On Wed, Aug 23, 2023 at 10:04:45PM +0100, David Chisnall wrote:
Hi all,
I’ve been fighting this for over an hour and I presume someone else has done it
in the past. If something is built using the BSD bsd.prog.mk build goo, what
do I need to do in the ports infrastructure to make sure that BINDIR and MANDIR
are set, to make it install things in the right places?
So far, every invocation I’ve tried has made things differently wrong and the
porters handbook is completely silent on the case of bmake. Any help
gratefully received!
ftp/netdumpd does this. The recipe seems to be:
MAKE_ARGS+=BINDIR=${PREFIX}/bin
etc.
Right, the two key things I noted when adding sysutils/quickjail is that
with bsd.prog.mk you'll need USES=uidfix, and then
MAKE_ENV+= BINDIR="${PREFIX}/bin" \
MANDIR="${PREFIX}/share/man/man"
(Both of which I ${MKDIR} in pre-install)
Thanks,
Kyle Evans
Re: aarch64 devel/gdb for kgdb use on main [so: 15] (and, likely, 14.0-????): dump core.txt.?'s kgdb backtraces are messed up
On 9/12/23 23:28, Mark Millard wrote:
[Trying to send to freebsd-ports accurately this time.]
On Sep 12, 2023, at 21:23, Mark Millard wrote:
[I've cc'd the last 2 devel/gdb authors of kgdb-related material.]
kgdb 13.1_4 is an improvement over 13.1_3 for aarch64 but is still
broken. 13.1_3 example:
0x in ?? ()
(kgdb) #0 0x in ?? ()
#1 in ?? ()
Backtrace stopped: not enough registers or memory available to unwind further
(kgdb)
13.1_4 example:
get_curthread () at /usr/src/sys/arm64/include/pcpu.h:77
77 __asm __volatile("ldr %0, [x18]" : "=&r"(td));
(kgdb) #0 get_curthread () at /usr/src/sys/arm64/include/pcpu.h:77
#1 doadump (textdump=0, textdump@entry=1576585744)
at /usr/src/sys/kern/kern_shutdown.c:405
#2 0x000ec18c in db_dump (dummy=, dummy2=,
dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:591
#3 0x000ebf88 in db_command (last_cmdp=,
cmd_table=, dopager=true)
at /usr/src/sys/ddb/db_command.c:504
#4 0x000ebc80 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:551
#5 0x000ef440 in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:268
#6 0x004b4860 in kdb_trap (type=60, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:790
#7
#8
#9
#10
#11
#12
#13
#14
#15
#16
#17
#18
#19
#20
#21
#22
#23
Backtrace stopped: Cannot access memory at address 0x10
(kgdb)
Yeah, sorry, I see the problem now; looks like I didn't test it after
one last change I ported from jhb's cheri branch:
> tf_size = regcache_map_entry_size (trapframe_map);
regcache_map_entry_size() is in-fact what we want, but I didn't realize
that it doesn't do the magical translation from 0 -> register_size that
seems to be done everywhere else. With the below patch[0] to populate
all of the sizes, things look sane again.
Thanks,
Kyle Evans
[0] https://people.freebsd.org/~kevans/kgdb-fix.diff
@@ -126,13 +126,13 @@ aarch64_fbsd_supply_pcb(struct regcache *regcache,
CORE_ADDR pcb_addr)
static const struct regcache_map_entry aarch64_fbsd_trapframe_map[] =
{
-{ 1, AARCH64_SP_REGNUM, 0 },
-{ 1, AARCH64_LR_REGNUM, 0 },
-{ 1, AARCH64_PC_REGNUM, 0 },
-{ 1, AARCH64_CPSR_REGNUM, 0 },
+{ 1, AARCH64_SP_REGNUM, 8 },
+{ 1, AARCH64_LR_REGNUM, 8 },
+{ 1, AARCH64_PC_REGNUM, 8 },
+{ 1, AARCH64_CPSR_REGNUM, 8 },
{ 1, REGCACHE_MAP_SKIP, 8 }, /* esr */
{ 1, REGCACHE_MAP_SKIP, 8 }, /* far */
-{ 30, AARCH64_X0_REGNUM, 0 }, /* x0 ... x29 */
+{ 30, AARCH64_X0_REGNUM, 8 }, /* x0 ... x29 */
{ 0 },
};
@@ -141,12 +141,12 @@ static const struct regcache_map_entry
aarch64_fbsd_trapframe_map[] =
static const struct regcache_map_entry aarch64_fbsd13_trapframe_map[] =
{
-{ 1, AARCH64_SP_REGNUM, 0 },
-{ 1, AARCH64_LR_REGNUM, 0 },
-{ 1, AARCH64_PC_REGNUM, 0 },
+{ 1, AARCH64_SP_REGNUM, 8 },
+{ 1, AARCH64_LR_REGNUM, 8 },
+{ 1, AARCH64_PC_REGNUM, 8 },
{ 1, AARCH64_CPSR_REGNUM, 4 },
{ 1, REGCACHE_MAP_SKIP, 4 }, /* esr */
-{ 30, AARCH64_X0_REGNUM, 0 }, /* x0 ... x29 */
+{ 30, AARCH64_X0_REGNUM, 8 }, /* x0 ... x29 */
{ 0 },
};
Re: what is pkg annotation ports_top_git_hash?
On 9/5/24 05:06, Ronald Klop wrote:
*Van:* Baptiste Daroussin
*Datum:* donderdag, 5 september 2024 11:38
*Aan:* Ronald Klop
*CC:* ports@freebsd.org
*Onderwerp:* Re: what is pkg annotation ports_top_git_hash?
On Thu 05 Sep 11:30, Ronald Klop wrote:
> Hi,
>
> I'm looking into some metadata of a pkg.
> I found annotation ports_top_git_hash which looks like what I'm
looking for.
>
> But I found that not all pkgs in one build have the same
'ports_top_git_hash'.
>
> See for example:
> curl -s
https://pkg.freebsd.org/FreeBSD:13:aarch64/latest/data.txz
<https://pkg.freebsd.org/FreeBSD:13:aarch64/latest/data.txz> | tar
-x -f - --to-stdout data | jq '.packages[] | {origin: .origin,
ports_top_git_hash: .annotations.ports_top_git_hash }' | jq
.ports_top_git_hash | sort | uniq
> "1b6eada811a"
> "60a177caf14"
>
> I found a reference to this in the poudriere source code, but it
didn't make it more clear for me.
>
https://github.com/freebsd/poudriere/blob/b2360d43e63e098a9afd3243f81f7fe8852c8965/src/share/poudriere/common.sh#L1114
<https://github.com/freebsd/poudriere/blob/b2360d43e63e098a9afd3243f81f7fe8852c8965/src/share/poudriere/common.sh#L1114>
>
> Wat does 'ports_top_git_hash' mean? Isn't it the git hash of the
top directory of the ports tree?
This the hash of the top directory of the ports tree at the moment
the package
was built.
Best regards,
Bapt
Hi,
That is what I hoped for. How can it be that one package build contains
multiple values for this? Is that because not all packages are rebuild
every time?
Hi,
Note that the cluster infrastructure doesn't do a fresh build every
time, so you'll see packages across multiple builds that didn't need a
rebuild (any kind of version/dependency bump). If you started a fresh
bulk -a today, I'd expect they would all have the same annotation, but
these packages carried over don't get a spurious rebuild to correct any
metadata.
Thanks,
Kyle Evans
Re: ca_root_nss
On Tue, Feb 8, 2022 at 2:05 PM Dan Mahoney wrote: > > All, > > Now that FreeBSD seems to be handling root ssl certs internally, will the > ca_root_nss port/package go away at some point? (Or rather, stop being a > dependency of other packages? I.e. if you want to trust ca_root_nss you can > install it, but the OS baseline is what things like "curl" default to > trusting. > My hope is that we'll eventually transform ca_root_nss into a package that does effectively what the current base infrastructure does, but we can use it as an 'update' mechanism for the trust store. Ideally, long-term, nothing will depend on ca_root_nss and it's entirely a leaf port that users may install if they need something in newer updates that didn't qualify for an SA/EN (e.g., new roots added aren't really a security issue and probably won't be the highest of priority). I don't have a timeline on this yet, unfortunately; there's still a number of issues pointed out by Michael Osipov with the new model that need to be fixed before we can redesign ca_root_nss. I'm still hoping that I can find someone else to help me out here, because my time is pretty over-committed as it is. Thanks, Kyle Evans
[RFC] patch's default backup behavior
Hello! FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, where a backup is created for every file patched. I'd like to test the waters on switching this to the GNU behavior, which feels a whole lot more reasonable. Notably, they'll only create backup files if a mismatch was detected (presumably this means either a hunk needed fuzz or a hunk outright failed). This yields far fewer backup files in the ideal scenario (context entirely matches), while still leaving backup files when it's sensible (base file changed and we might want to regenerate the patch). Thoughts / comments / concerns? Cross-posted this to a couple of different lists to try and hit the largest number of stakeholders in patch(1) behavior. Thanks, Kyle Evans
Re: [RFC] patch's default backup behavior
On Fri, Apr 8, 2022 at 10:41 PM Warner Losh wrote: > > > > On Fri, Apr 8, 2022, 9:26 PM Kyle Evans wrote: >> >> Hello! >> >> FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, >> where a backup is created for every file patched. >> >> I'd like to test the waters on switching this to the GNU behavior, >> which feels a whole lot more reasonable. Notably, they'll only create >> backup files if a mismatch was detected (presumably this means either >> a hunk needed fuzz or a hunk outright failed). This yields far fewer >> backup files in the ideal scenario (context entirely matches), while >> still leaving backup files when it's sensible (base file changed and >> we might want to regenerate the patch). >> >> Thoughts / comments / concerns? Cross-posted this to a couple of >> different lists to try and hit the largest number of stakeholders in >> patch(1) behavior. > > > Could one select the old behavior? Or would it just be a change? A new -V > value? > Yeah, the current behavior is actually represented by the `-b` flag. With the new behavior, we'd specifically implement `--backup-if-mismatch` (a nop from the beginning), `--no-backup-if-mismatch` (turn off backups, equivalent to `-V none` but "lighter" in that it won't override -b/-V) and we'd leave existing flags otherwise alone. > I like the Idea. > > Warner > >> Thanks, >> >> Kyle Evans >>
Re: [RFC] patch's default backup behavior
On Sun, Apr 10, 2022 at 5:33 AM Matthias Andree wrote: > > [resending from hopefully subscribed address that it makes it to some of > the lists] > > Am 09.04.22 um 05:25 schrieb Kyle Evans: > > Hello! > > > > FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, > > where a backup is created for every file patched. > > > > I'd like to test the waters on switching this to the GNU behavior, > > which feels a whole lot more reasonable. Notably, they'll only create > > backup files if a mismatch was detected (presumably this means either > > a hunk needed fuzz or a hunk outright failed). This yields far fewer > > backup files in the ideal scenario (context entirely matches), while > > still leaving backup files when it's sensible (base file changed and > > we might want to regenerate the patch). > > > > Thoughts / comments / concerns? Cross-posted this to a couple of > > different lists to try and hit the largest number of stakeholders in > > patch(1) behavior. > > > > Thanks, > > > > Kyle Evans > > > > Kyle, > > you would discard the original reference for gendiff or "make makepatch" > in ports, that would make patch - edit - regenerate-patch cycles require > extra efforts, and if that extra effort is only remembering patch's -b > option, but if we do it consistently for FreeBSD 14 and announce it in > due time beforehand, fine. Certainly worthy of release notes. > Arguably, `make patch` should be using the `-b` option even today to be portable across different patch implementations. Yes, we have our own patch with our own behavior that we can rely on, but I'm personally a fan of not tying ourselves and, perhaps more importantly, others (downstreams) into one behavior when we can trivially wire it down. > I personally also dislike and advise against "magic" and if-then > behavior. It makes documentation less concise, it makes tool behavior > more complex to judge, and from people who script a test-based approach, > this bears potential for confusion, astonishment and other effects, > because behavior as to when we get .orig files gets *apparently* > inconsistent, and may send people who have not read the entire manual to > the letter on detours finding out why they sometimes get .orig, or > worse, when developing patches, and interaction with other tools might > surprise people, too. > There are certainly trade-offs -- with the GNU behavior, you can instead quickly use the presence of an .orig file to know that you may need to sanity check the result and tooling can key off the same rather than checking patch(1) output for words like 'fuzz'. fuzz has bitten people before, it will bite people again. I'm not so sure that the scenario you write about will really happen. GNU patch has done this for many years, and I haven't seen such a proliferation of confusion. If anything, I see more confusion in practice from BSD patch's default differing from both the much more common GNU behavior and also from POSIX-specified behavior. > IF we are to change policy, my vote is to ALWAYS leave the .orig files > away and not only write them if we also write .rej files. I explicitly > dislike the GNU behavior, which seems geared for interactive use rather > than scripting. > re: interactive use, I think that's an entirely separate debate, even. :-) My personal opinion is that defaults *should* be geared more for interactive use, and scripts should be (+ able to be) entirely explicit about the behavior they want. This is a general opinion, not just with patch. If you solidify script usage with flags, then we can be a bit more fluid so that tooling can adapt to the ever-changing user landscape. Obviously you can't reliably predict potential for future behavior changes, though there are some obvious candidates like this one where the difference in defaults between us and other implementations are well-known. > I checked POSIX 2018, apparently the backup files (.orig) are only > required if -b is given, so omitting them would seem fine to me, and the > rationale section suggests that for consistency with other utilities, > the default would be to NOT save .orig file, but the -b option can be > used to request them being written (but then consistently on all files > not just those without rejects - also because there is no working patch > -R for ed-style diffs.). I'd actually be OK with that, too, to an extent. Thanks, Kyle Evans
Re: [RFC] patch's default backup behavior
On Sun, Apr 10, 2022 at 10:48 AM Gary Jennejohn wrote: > > On Sun, 10 Apr 2022 10:21:56 -0500 > Kyle Evans wrote: > > > On Sun, Apr 10, 2022 at 5:33 AM Matthias Andree > > wrote: > [big SNIP] > > > I checked POSIX 2018, apparently the backup files (.orig) are only > > > required if -b is given, so omitting them would seem fine to me, and the > > > rationale section suggests that for consistency with other utilities, > > > the default would be to NOT save .orig file, but the -b option can be > > > used to request them being written (but then consistently on all files > > > not just those without rejects - also because there is no working patch > > > -R for ed-style diffs.). > > > > I'd actually be OK with that, too, to an extent. > > > > Please do not change the behavior of the -b flag! I make patches to > /usr/src/ to eliminate things I don't want compiled in when I run > buildkernel and buildworld and then move the resulting .orig backups > to the original file names to eliminate those changes. > No one has proposed changing the behavior of the -b flag (that would be silly), but rather the default behavior (sans -b flag). The -b flag is the proposed solution to maintaining the status quo across such a change if it happens.
Re: Bugzilla preview does not work
On Sat, Apr 16, 2022 at 10:06 AM Marcel Bischoff wrote: > > Hi all, > > I just wanted to submit a bug ticket for a port and found that the Bugzilla > preview window does not work at all — its output is just blank. I've tested > this in Safari and Firefox with all ad blockers off. There's no error in the > JavaScript console. > > Is this expected behavior (would be very surprising to me) or does this need > to be fixed? In any case, I thought I'd raise the issue here. > Hi, Looks like: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250699 Thanks, Kyle Evans
