Maintaining mail/mailman3
Hello, I submitted a patch for mail/mailman3 more than one year ago [1]. It required updates to multiple ports, which all have been merged, but mail/mailman3 has not. Since the original report, I added an updated patch to upgrade to 3.3.5 and I just finished building 3.3.7 locally. The current maintainer is AWOL so I'd like to volunteer to take over as port maintainer. .einar ISNIC [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258941
audio/miniaudio update to 0.11.x
Hi guys I hope you're doing well I wanted to tell you that I'm currently working on games/jaggedalliance2 upgrade to 0.20.0 ( https://ja2-stracciatella.github.io/2022/11/14/release-0.20.0.html) which brings support for newer miniaudio-0.11 That means that https://cgit.freebsd.org/ports/commit/?id=e403b5a815496a076a0ee20df6439b8b0199fc75 (audio/miniaudio: Downgrade 0.11.9 -> 0.10.43) can be reverted when I'm done. I'll keep you posted!
Intentionally bad port behaviour
What's the policy on dodgy acting ports? I had elinks crash (well, the spidermonkey part crashed) elinks then accused me of editting the config file manually (I hadn't) and then went into an intentional endless loop. I think this should be patched out: | src/util/error.c : | | /* User torturation. */ | /* You are worried about what you see here? You don't see anything in | * the first place. Also, be assured that we know what are we doing. */ | /* (We are killing the user, obviously.) */ | | /* TODO: Gettextify? Er, better not. More people (translators) could | * find out what are we doing... ;-) --pasky */ | /* TODO: Be more cruel when in trouble? ;-) --pasky */ | | fputs( "Wheee! You played with the config.h by hand, didn't you?\n" | "Of _COURSE_ you did! Is that how a nice .. creature behaves like?\n" | "Of _COURSE_ it isn't! I feel offended and thus I will revenge now!\n" | "You will _suffer_ >:).\n" | "\n" | "CPU burning sequence initiated...\n", f); | | /* TODO: Include cpuburn.c here. --pasky */ | while (1); Cheers
Re: Intentionally bad port behaviour
On 2022-11-14 16:05, Jamie Landeg-Jones wrote: What's the policy on dodgy acting ports? I had elinks crash (well, the spidermonkey part crashed) elinks then accused me of editting the config file manually (I hadn't) and then went into an intentional endless loop. I think this should be patched out: | src/util/error.c : | | /* User torturation. */ | /* You are worried about what you see here? You don't see anything in | * the first place. Also, be assured that we know what are we doing. */ | /* (We are killing the user, obviously.) */ | | /* TODO: Gettextify? Er, better not. More people (translators) could | * find out what are we doing... ;-) --pasky */ | /* TODO: Be more cruel when in trouble? ;-) --pasky */ | | fputs( "Wheee! You played with the config.h by hand, didn't you?\n" | "Of _COURSE_ you did! Is that how a nice .. creature behaves like?\n" | "Of _COURSE_ it isn't! I feel offended and thus I will revenge now!\n" | "You will _suffer_ >:).\n" | "\n" | "CPU burning sequence initiated...\n", f); | | /* TODO: Include cpuburn.c here. --pasky */ | while (1); Cheers Exceptionally bad behavior for anything in the ports tree. I think this port should be patched out of the ports tree. --Chris 0xBDE49540.asc Description: application/pgp-keys
Re: Access to FreeBSD package build server via IPv4-only network
On 2022-11-10 10:58:04 (+0800), Jan Beich wrote: Simon Wright writes: My issue is that since the build servers are IPv6-only and my provider in Philippines does not offer any IPv6 service at all, I need to use a proxy to use curl to access this file: http://beefy16.nyi.freebsd.org/data/131amd64-default/.data.json https://pkg-status.freebsd.org/beefy16/data/131amd64-default/.data.json pkg-status can act as a proxy, limited to freebsd.org machines it manages. I've asked pkgmgr to change the links in the pkg-fallout reports to point at the pkg-status.freebsd.org proxy, rather than to the builders directly. They've changed that yesterday. Philip [hat: clusteradm] -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: Intentionally bad port behaviour
On Mon, 14 Nov 2022, Chris wrote: > Exceptionally bad behavior for anything in the ports tree. > I think this port should be patched out of the ports tree. And then block that creature from ever having anything to do with ports again... That is a gross abuse of trust. -- Dave
Re: Intentionally bad port behaviour
Jamie Landeg-Jones wrote: > What's the policy on dodgy acting ports? > > I had elinks crash (well, the spidermonkey part crashed) > > elinks then accused me of editting the config file manually (I hadn't) > and then went into an intentional endless loop. > > I think this should be patched out: I think there are (at least) two issues in the port: 1) that code should not be compiled in, because it's in the "else" branch of a "#ifdef HAVE_EXECINFO_H", so something is broken in the port/configure script 2) the port has a "CONIGURE_ENV" line, that is quite surely a typo -- Alex Dupre
Re: Intentionally bad port behaviour
El mar., 15 nov. 2022 1:05, Jamie Landeg-Jones escribió: > What's the policy on dodgy acting ports? > > I had elinks crash (well, the spidermonkey part crashed) > > elinks then accused me of editting the config file manually (I hadn't) > and then went into an intentional endless loop. > > I think this should be patched out: > > | src/util/error.c : > | > | /* User torturation. */ > | /* You are worried about what you see here? You don't see > anything in > | * the first place. Also, be assured that we know what are we > doing. */ > | /* (We are killing the user, obviously.) */ > | > | /* TODO: Gettextify? Er, better not. More people (translators) > could > | * find out what are we doing... ;-) --pasky */ > | /* TODO: Be more cruel when in trouble? ;-) --pasky */ > | > | fputs( "Wheee! You played with the config.h by hand, > didn't you?\n" > | "Of _COURSE_ you did! Is that how a nice .. creature > behaves like?\n" > | "Of _COURSE_ it isn't! I feel offended and thus I will > revenge now!\n" > | "You will _suffer_ >:).\n" > | "\n" > | "CPU burning sequence initiated...\n", f); > | > | /* TODO: Include cpuburn.c here. --pasky */ > | while (1); > This is really terrible and reflects very poorly on the upstream project/developers. It shows a worrying absence of ethics. I would definitely patch this out. > Cheers > >
