- User Since
- Dec 13 2015, 7:56 AM (225 w, 22 h)
Sat, Mar 28
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 .
Update to 4.2.0.b1.20191027
Define BUILD_ and RUN_DEPENDS
Oct 28 2019
I just tried it again on 12.0-RELEASE-p10 and it compiled just fine (poudriere), can you post your log file?
Strange, which version of FreeBSD are you building it on?
Because 4.2.0 is the first version that supports libtorrent-rasterbar 1.2+
Oct 27 2019
Yes, but that's incorrect as 3.0.0 would be a lower version number than the current version and misleading?
Application version isn't 3.0.0 and since I'm not very fluent with git I asked for help in the #bsdports channel to understand this issue.
Releases are created off other branches and since 4.2.0 isn't released yet there's no branch or at least the seems to be their workflow given previous versions. 3.0.0 is the most recent tag reached from master branch which is why that's reported by git describe however that should be disregarded in this case. Application version is set in https://github.com/qbittorrent/qBittorrent/blob/master/version.pri which got bumped to beta1 today. I can update to that version if needed if desired as the only code change is bumping the Web API version compared to the current version.
As for the distversion I followed the syntax suggested in Example 5.11 https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#makefile-master_sites-github-description
I had a look at git describe and it reports release-3.0.0-5664-g0de5cbaa4 which doesn't seem to be very helpful in this case?