- User Since
- Dec 13 2015, 7:56 AM (249 w, 17 m)
Jun 8 2020
Hi, sorry for being vague
May 27 2020
Please revise the list while at it,
May 7 2020
MASTER_SITES needs updating, perhaps it's also worth considering migrating to CMake as that's what upstream uses for CI and fix make test.
It also seems like it incorrectly overrides default CFLAGS -g0 -Os (optimization enabled), -g0 -O0 if disabled (which is fine I guess).
Apr 29 2020
Tests completes successfully (with and w/o RCC) on 13-CURRENT (AMD64) r360454
Update to use DISTVERSION as suggested by tcberner@
Apr 24 2020
Fair reasoning, thanks!
Apr 16 2020
Terribly sorry for the late reply, I missed this.
I don't see the point in pulling in and/or using gmake just for the sake of it. One could argue that other tools depends on gmake so it would be a futile and/or pointless effort but you have to start somewhere. Fwiw, my other PRs regarding this have been accepted so I think it's something that most seem to agree upon.
Mar 28 2020
Scanning vtbd devices doesn't seem very useful indeed.
Mar 2 2020
This will overwrite drivedb.h causing a checksum mismatch.
Feb 3 2020
I forgot to mention that these tests also fails using gmake so it's not related to gmake vs make.
Jan 30 2020
Jan 27 2020
Thanks, I got busy on my end.
Jan 24 2020
Update to 2020.01.24
Jan 22 2020
For the sake of completion, attach Poudriere log
Instead of the IGNORE can't you use IMPLIES instead to avoid breakage?
Jan 20 2020
Change MASTER_SITES on requests by bapt@ and mat@
Instead of defining localbase manually doesn't USES= localbase work?
Jan 19 2020
Jan 18 2020
Migrated to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243436 per request by mat@
Migrated to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243435 per request by mat@
While I understand your concern about compatibility that can be applied to pretty much any port with some kind of configuration option regarding dependencies. The idea is to simply give the user an option to exclude unneeded libraries as compression isn't always beneficial in terms of performance primarily on embedded devices such as ones based on MIPS and ARM (example https://serverfault.com/questions/544869/improving-openvpn-performance/755690#755690) and these are often removed on devices running OpenWrt for instance. In addtion to that it may also be a security concern see: https://forum.netgate.com/topic/141498/openvpn-compression for instance.
O3 makes very little difference new and the new versions of libx264 enables LTO by default (x264 build does not however).
Jan 15 2020
Path is wrong, you're missing one level.
Merged into https://reviews.freebsd.org/D22919
Update youtube_dl to 2020.01.15
Remove archivers/zip build dependency as bsdtar in base is able to generate zip files there's no need to pull in archivers/zip
Changed patch upon mat@ suggestions
Jan 13 2020
Thanks for your time! I agree that we should try to avoid unnecessary breakage.
I gave it a quick spin on my aarch64 box (4 cores) running 13-CURRENT (r356372) and it built successfully if it helps.
Jan 12 2020
While I'm not sure if this patch is 100% correct it makes science/py-tensorflow build:
Drop it in science/py-tensorflow/files
Any update on this, did you run into issues with the update?
Jan 11 2020
Jan 10 2020
Jan 9 2020
Jan 4 2020
Dec 28 2019
Dec 27 2019
Dec 24 2019
Dec 23 2019
http://mirrors.rit.edu/zi/ Doesn't carry it
Dec 22 2019
Dec 18 2019
Forgot to include the ssl test patch file, sorry for the noise
Update to 4.2.1
Dec 8 2019
Pianobar sets it, sorry for not mentioning that.
Dec 7 2019
Dec 6 2019
Dec 4 2019
No, it needs to get updated to 2.0. There's a bug report about it but no response from maintainer, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241202
Looking at the repo it seems like 1.3.X is deprecated/unsupported (https://git.deluge-torrent.org/deluge), perhaps set it as broken until someone submits a patch?
Hi, it's here: https://reviews.freebsd.org/D21889
PORTREVISION should be reset to 0 (or none) if DISTVERSION is bumped
Dec 3 2019
Dec 2 2019
Dec 1 2019
Nov 30 2019
Nov 27 2019
Use "efi" as label and boot/efi instead of boot/msdos
Nov 26 2019
Switch to FAT16 and reduce FAT parition size
Switch to using GPT everywhere instead of using BSD slices
Nov 24 2019
Nov 20 2019
Thanks for looking into this, while x86 is powerful enough to make the difference negligible in the end there's still quite a difference in performance and it's even greater on platforms with lower overall performance such as ARM. I'm not sure why it's preferred to have redundant libraries but as far as I can tell format support seems to be added on top of each library such as ffmpeg which can potentially replace the majority of other decoders supported although the current code does not support full utilization of ffmpeg. In general I think dependencies should be kept at a minimum without sacrificing convenience (functionality/usability) but I have no strong opinion if you want to include both decoders or just keep it as is.
Nov 15 2019
Thanks for the follow up!
Nov 14 2019
Nov 10 2019
Should also be added to vuxml?
Nov 9 2019
FLAC can also be removed if FLAC encoding is deemed unnecessary.
FFmpeg handles some of the formats libsndfile supports however not the following:
It's in the works, I'm slowly working my way through the list so it's on my todo list. Many utilities in /audio have newer counterparts or so but I'm not sure how you would go about deprecating those in a later stage.
Nov 8 2019
Nov 7 2019
Nov 6 2019
The idea is to minimize the amount of dependencies, try to consolidate overall in the long run and possibly try to deprecate some such as madlib which isn't seen development in years and has known vulns and is quite inefficient. While the default configuration of ffmpeg pulls in opus and vorbis they aren't necessarily needed as ffmpeg supports decoding of both these formats without any external libraries. This will also make it potentially less tedious when doing custom packages/repos and you want to avoid getting unnecessary dependencies pulled in.
Nov 4 2019
Hi, I think this should fix all known "issues"
Nov 1 2019
Any news on this?
Oct 29 2019
This should fix your build issues, upstream plans to use libtorrent-rasterbar 1.2.2 in their upcoming release so I guess they haven't tried and/or plans to support older versions .