Re: https://portsfallout.com/ doesn't show all fallout and no category in bugzilla to report bugs for https://portsfallout.com/
Op 18-12-2024 om 23:16 schreef Yuri: For example, these 2 recent failures don't appear on https://portsfallout.com/: * https://pkg-status.freebsd.org/ampere2/data/main-arm64-default/peb87cb7f3aa2_saf66ffbf69e/logs/onnxruntime-1.18.2_1.log * https://pkg-status.freebsd.org/beefy15/data/133i386-default/545eb5d3ac42/logs/olive-video-editor-0.2.0.log Additionally, bugzilla doesn't have a category to report bugs for https://portsfallout.com/ My request to add such category went unanswered: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276267 Thanks, Yuri I don't think portsfallout is an "official" FreeBSD project. See https://portsfallout.com/about for the maintainer and github project of it. Regards, Ronald.
Unmaintained FreeBSD ports which are out of date
Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/go-git| 5.10.0 | 5.13.1 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout!
Re: editors/ghostwriter 24.12.0 versus x11/kde5
On Thu, 2 Jan 2025 08:41:27 +0100 Guido Falsi wrote: > On 02/01/25 01:38, Tomoaki AOKI wrote: > > On Wed, 1 Jan 2025 19:50:50 +0100 > > Guido Falsi wrote: > > > >> Don't see a good reason to force everyone to use an old version. > >> > >> Anyway the ports tree is open source, nothing stops anyone from > >> proposing (with himself as maintainer) a new port for the old version > >> calling it "ghostwriter-qt5" or whatever. > > > > Or flavorizing with qt5/kf5 version alone stick with latest possible > > (older than ones for qt6/kf6) version until KDE6 becomes default > > on ports. > > I'm not sure putting VERSION under flavors control is > supported/suggested. Would make managing the port quite more complicated > anyway. Yes. Is complicated. For example, mail/claws-mail is ver. 3.21.0 for Gtk2 and 4.3.0 for Gtk3. This is because upstream is deveoping Gtk2 version on 3.x branch and Gtk3 version on 4.x branch. And here, I've mis-remembered. It was using OPTION, not FLAVOR. https://cgit.freebsd.org/ports/tree/mail/claws-mail/Makefile https://cgit.freebsd.org/ports/tree/mail/claws-mail/Makefile.claws https://cgit.freebsd.org/ports/tree/mail/claws-mail/Makefile.ver But there is no reason (putting aside the complexities like above) that FLAVOR cannot do the same thing, just technically, though. > A separate port for the older version would be more reasonable, the name > I suggested for such a port it is also suboptimal. The name should have > at least an indication this is an old version. Exactly. It would be simpler. Using FLAVOR/OPTION is just another possibility. Regards. > Best regards! > > > -- > Guido Falsi -- Tomoaki AOKI
Re: editors/ghostwriter 24.12.0 versus x11/kde5
On Thu, 2 Jan 2025 14:05:23 +0100 Guido Falsi wrote: > On 02/01/25 13:57, Tomoaki AOKI wrote: > > On Thu, 2 Jan 2025 08:41:27 +0100 > > Guido Falsi wrote: > > > >> On 02/01/25 01:38, Tomoaki AOKI wrote: > >>> On Wed, 1 Jan 2025 19:50:50 +0100 > >>> Guido Falsi wrote: > >>> > Don't see a good reason to force everyone to use an old version. > > Anyway the ports tree is open source, nothing stops anyone from > proposing (with himself as maintainer) a new port for the old version > calling it "ghostwriter-qt5" or whatever. > >>> > >>> Or flavorizing with qt5/kf5 version alone stick with latest possible > >>> (older than ones for qt6/kf6) version until KDE6 becomes default > >>> on ports. > >> > >> I'm not sure putting VERSION under flavors control is > >> supported/suggested. Would make managing the port quite more complicated > >> anyway. > > > > Yes. Is complicated. > > > > For example, mail/claws-mail is ver. 3.21.0 for Gtk2 and 4.3.0 for Gtk3. > > This is because upstream is deveoping Gtk2 version on 3.x branch and > > Gtk3 version on 4.x branch. > > > > And here, I've mis-remembered. It was using OPTION, not FLAVOR. > > > >https://cgit.freebsd.org/ports/tree/mail/claws-mail/Makefile > >https://cgit.freebsd.org/ports/tree/mail/claws-mail/Makefile.claws > >https://cgit.freebsd.org/ports/tree/mail/claws-mail/Makefile.ver > > > > But there is no reason (putting aside the complexities like above) that > > FLAVOR cannot do the same thing, just technically, though. > > > > > >> A separate port for the older version would be more reasonable, the name > >> I suggested for such a port it is also suboptimal. The name should have > >> at least an indication this is an old version. > > > > Exactly. It would be simpler. Using FLAVOR/OPTION is just another > > possibility. > > > > A flavor is an option that would force me to be the maintainer of an > outdated software, something I'm not willing to do. > > So another port with a separate maintainer is the only way to go. > > While technically it would be possible to have separate MAINTAINER > values for flavors, it would be quite difficult to draw the lines in > relation to responsibilities in case of problems. Agreed. I don't intend to force anyone anything. Just proposing different possibilities for the future (in mail archives to be searched). This is mostly because I've wondered which way to go, whether any better way exist or not, when I've filed Bug 276165 [1]. There was multiple ways to go, each had Pros and Cons, and finally chosen the one I've filed. Anyway, I'm currently not using editors/ghostwriter (as I don't want any ports depending on www/qt[5|6]-webengine to be newly installed), so doing fork or not would be on whom actually want to do and maintain. And why I've popped in this discussion is because I've lost qterminal as of conflicts (I've overlooked the switch to qt6 and addition of kf6 dependencies, thus, missed to lock it. And reverting after that could cause new dependency hell). I've switched back to x11/mate-terminal now, as I've found the workaround when it failed to build. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276165 Regards. > > -- > Guido Falsi > -- Tomoaki AOKI
Re: editors/ghostwriter 24.12.0 versus x11/kde5
On 02/01/25 13:57, Tomoaki AOKI wrote: On Thu, 2 Jan 2025 08:41:27 +0100 Guido Falsi wrote: On 02/01/25 01:38, Tomoaki AOKI wrote: On Wed, 1 Jan 2025 19:50:50 +0100 Guido Falsi wrote: Don't see a good reason to force everyone to use an old version. Anyway the ports tree is open source, nothing stops anyone from proposing (with himself as maintainer) a new port for the old version calling it "ghostwriter-qt5" or whatever. Or flavorizing with qt5/kf5 version alone stick with latest possible (older than ones for qt6/kf6) version until KDE6 becomes default on ports. I'm not sure putting VERSION under flavors control is supported/suggested. Would make managing the port quite more complicated anyway. Yes. Is complicated. For example, mail/claws-mail is ver. 3.21.0 for Gtk2 and 4.3.0 for Gtk3. This is because upstream is deveoping Gtk2 version on 3.x branch and Gtk3 version on 4.x branch. And here, I've mis-remembered. It was using OPTION, not FLAVOR. https://cgit.freebsd.org/ports/tree/mail/claws-mail/Makefile https://cgit.freebsd.org/ports/tree/mail/claws-mail/Makefile.claws https://cgit.freebsd.org/ports/tree/mail/claws-mail/Makefile.ver But there is no reason (putting aside the complexities like above) that FLAVOR cannot do the same thing, just technically, though. A separate port for the older version would be more reasonable, the name I suggested for such a port it is also suboptimal. The name should have at least an indication this is an old version. Exactly. It would be simpler. Using FLAVOR/OPTION is just another possibility. A flavor is an option that would force me to be the maintainer of an outdated software, something I'm not willing to do. So another port with a separate maintainer is the only way to go. While technically it would be possible to have separate MAINTAINER values for flavors, it would be quite difficult to draw the lines in relation to responsibilities in case of problems. -- Guido Falsi
