category qt?
The qt* ports spreads around in the whole portstree. It is reasonable to concentrate all these ports in a qt category? I think it is easier to find (and also easier to maintain). ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: category qt?
> The qt* ports spreads around in the whole portstree. > > It is reasonable to concentrate all these ports in a qt category? I > think it is easier to find (and also easier to maintain). Indeed it is a bit annoying for me when I have to update qt* ports. I don't use portmaster or similar (I don't like them): I wrote my own utility, but it has still some issues, such as this one. I guess having all the qt* ports in the same category would help. Lorenzo Salvadore. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your 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. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed 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 +-+ games/domination| 1.1.1.6 | 1.2.0 +-+ 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 Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: texlive-texmf
On Sun, 23 Dec 2018 19:01:15 -0500 wrote: > Hi! > > I try to install libreoffice and it pulls also > texlive-texmf which size is about 2 GB and I have a slow > Internet. After was done, please read bellow. > > => Fetching all distfiles required by > texlive-texmf-20150523_4 for building ===> Extracting > for texlive-texmf-20150523_4 => SHA256 Checksum mismatch > for TeX/texlive-20150523-texmf.tar.xz. => SHA256 Checksum > OK for TeX/latex-base-20150101.2.tar.xz. ===> Refetch > for 1 more times files: TeX/texlive-20150523-texmf.tar.xz > ===> texlive-texmf-20150523_4 depends on > file: /usr/local/sbin/pkg - found => > texlive-20150523-texmf.tar.xz doesn't seem to exist > in /usr/ports/distfiles//TeX. => Attempting to fetch > ftp://ftp.tug.org/historic/systems/texlive/2015/texlive-20150523-texmf.tar.xz > > Are there any other site to download this file, please? > > Thank you. Hi! I would recommend to fetch and install the binary package for texlive-texmf from http://pkg.freebsd.org. It's size is about 600 Mb vs. 1,8 Gb distfile size. BTW, I build editors/libreoffice with just GTK2 and CUPS options enabled and in that case it does not require print/texlive-texmf. regadrs, Dmitry. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: texlive-texmf
On Mon, 24 Dec 2018 15:50:23 +0300 wrote: > On Sun, 23 Dec 2018 19:01:15 -0500 > wrote: > > > Hi! > > > > I try to install libreoffice and it pulls also > > texlive-texmf which size is about 2 GB and I have a slow > > Internet. After was done, please read bellow. > > > > => Fetching all distfiles required by > > texlive-texmf-20150523_4 for building ===> Extracting > > for texlive-texmf-20150523_4 => SHA256 Checksum mismatch > > for TeX/texlive-20150523-texmf.tar.xz. => SHA256 Checksum > > OK for TeX/latex-base-20150101.2.tar.xz. ===> Refetch > > for 1 more times files: TeX/texlive-20150523-texmf.tar.xz > > ===> texlive-texmf-20150523_4 depends on > > file: /usr/local/sbin/pkg - found => > > texlive-20150523-texmf.tar.xz doesn't seem to exist > > in /usr/ports/distfiles//TeX. => Attempting to fetch > > ftp://ftp.tug.org/historic/systems/texlive/2015/texlive-20150523-texmf.tar.xz > > > > Are there any other site to download this file, please? > > > > Thank you. > > Hi! > > I would recommend to fetch and install the binary package > for texlive-texmf from http://pkg.freebsd.org. It's size is > about 600 Mb vs. 1,8 Gb distfile size. > BTW, I build editors/libreoffice with just GTK2 and CUPS > options enabled and in that case it does not require > print/texlive-texmf. > > regadrs, > Dmitry. Thank you. I did install package but when I start building libreoffice it want to download again. I will try without documentation. Looks like it works. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: category qt?
On Mon, Dec 24, 2018 at 11:06:56AM +0100, Walter Schwarzenfeld wrote: > The qt* ports spreads around in the whole portstree. > > It is reasonable to concentrate all these ports in a qt category? I think it > is easier to find (and also easier to maintain). While a virtual category could easily be added (by having USES=qt add it automatically) a physical category makes little sense. It would be like having all the p5- ports put in a perl directory. -- Mathieu Arnold signature.asc Description: PGP signature
Re: category qt?
On Monday, 24 December 2018 13:00:02 CET freebsd-ports-requ...@freebsd.org wrote: > > The qt* ports spreads around in the whole portstree. > > > > It is reasonable to concentrate all these ports in a qt category? I > > think it is easier to find (and also easier to maintain). > > Indeed it is a bit annoying for me when I have to update qt* ports. > I don't use portmaster or similar (I don't like them): I wrote my own > utility, but it has still some issues, such as this one. I guess having > all the qt* ports in the same category would help. You might argue that all (?) the Qt ports are libraries and development tools, and so could live in the devel/ category. Or along other lines, that the split of Qt into a bunch of separate packages is superfluous and they should be merged (like gtk3, which is one big port -- I don't know if this is a useful functional analogy though). But what makes Qt special in this regard? (One answer I'll accept is "the ports need to be updated in a coordinated fashion"). The reason (for instance) that two of the Qt5 ports live in textproc/ is .. that they're concerned with doing text processing. That functional-categorization in the ports tree has been there since always. I guess it depends on the original post: "easier to find" for what? If you're calling for a *virtual* category (like KDE ports have), that makes immediate sense to me (but would leave the ports scattered around the ports tree). [ade] signature.asc Description: This is a digitally signed message part.
Re: category qt?
On Mon 2018-12-24 11:06:56 UTC+0100, Walter Schwarzenfeld (w.schwarzenf...@utanet.at) wrote: > The qt* ports spreads around in the whole portstree. > > It is reasonable to concentrate all these ports in a qt category? I think it > is easier to find (and also easier to maintain). Why? You'd end up with, for eg. VirtualBox at emulators/virtualbox-ose being moved to qt/virtualbox-ose, and QEMU remain as emulators/qemu, which is a system that makes no sense to me. I suspect many other people would object to something like that. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
SVN r488276 breaks net/qt5-network compilation
As follows: --- .obj/qudpsocket.o --- c++ -c -O2 -pipe -march=ivybridge -fstack-protector -fno-strict-aliasing -DOPENSSL_API_COMPAT=0x1010L -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wdate-time -Winconsistent-missing-override -pthread -fPIC -DQT_OPENSSL -DQT_SSL -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DQT_USE_SYSTEM_PROXIES -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_NETWORK_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_CORE_LIB -I. -Ikernel -I../../include -I../../include/QtNetwork -I../../include/QtNetwork/5.12.0 -I../../include/QtNetwork/5.12.0/QtNetwork -I/usr/local/include/qt5/QtCore/5.12.0 -I/usr/local/include/qt5/QtCore/5.12.0/QtCore -I/usr/local/include/qt5 -I/usr/local/include/qt5/QtCore -I.moc -I/usr/local/include -I/usr/local/lib/qt5/mkspecs/freebsd-clang -o .obj/qudpsocket.o socket/qudpsocket.cpp --- .obj/qnetworkinterface_unix.o --- kernel/qnetworkinterface_unix.cpp:477:14: error: use of undeclared identifier 'IFM_FDDI'; did you mean 'IFT_FDDI'? case IFM_FDDI: ^~~~ IFT_FDDI /usr/include/net/if_types.h:62:2: note: 'IFT_FDDI' declared here IFT_FDDI= 0xf, ^ imb ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: SVN r488276 breaks net/qt5-network compilation
On Monday, 24 December 2018 18:14:51 CET Michael Butler wrote: > As follows: .. and here I had tested on 11.2 with base SSL, openssl, openssl111, .. and not considered that 12.0 would remove the definition of IFM_FDDI entirely. Fixed, I hope, in r488281 (which built for me in a 12.0-RC3 VM). [ade] signature.asc Description: This is a digitally signed message part.
Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
[A native poudreire-devel based build of
multimedia/gstreamer1-qt@qt5 did not hang-up
and worked fine. Official package build history
also provides some evidence.]
On 2018-Dec-22, at 12:55, Mark Millard wrote:
> [I found my E-mail records reporting successful builds using
> qemu-user-static from ports head -r484783 under FreeBSD
> head -r340287.]
>
> On 2018-Dec-22, at 00:10, Mark Millard wrote:
>
>> [I messed up the freebsd-emulation email address the first time I sent
>> this. I also forgot to indicate the qemu-user-static vintage relationship.]
>>
>> I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7}
>> port cross
>> builds in another message sequence. But it turns out that one thing I ran
>> into
>> has hung-up every time, the same way, for amd64->armv7 cross builds:
>> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a
>> separate report
>> with some updated notes.
>>
>> A little context: I had built from ports head -r484783 before under FreeBSD
>> head
>> -r340287 (as I remember the version). Back then it did not have this problem
>> that it
>> now has under FreeBSD head -r341836 . One ports-specific change was to force
>> perl5.28
>> as the default instead of perl5.26 originally. In fact this is what drives
>> what is
>> being rebuilt for my experiment that caught this. But I doubt the perl
>> version is
>> important to the problem. The context has a Ryzen Threadripper 1950X and has
>> been
>> tested both for FreeBSD under Hyper-V and for the same media native-booted.
>> Both
>> hang-up at the same point as seen via ps or top. The native tools for
>> cross-build
>> speedup were in use. Cross-builds targeting aarch64 did not get this problem
>> but
>> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for the
>> first
>> armv7 try.
>>
>> ADDED: The qemu-user-static back with head -r340287 before installing the
>> updated ports would likely be different than the -r484783 vintage. So both
>> FreeBSD and qemu-user-static may have changed over the comparison.
>
> CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds
> based on qemu-user-static from ports head -484783 --all built under FreeBSD
> head -r340287 . So the use of the perl5.28 as the forced-default and the
> newer FreeBSD head version -r341836 as the context are the differences here.
>
>> The hang-up:
>>
>> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up
>> and timed
>> out. Looking during the wait in later tries shows something much like (from
>> one of the
>> examples):
>>
>> root 337190.0 0.0 12920 3528 0 I11:40 0:00.03 | |
>> `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg
>> (gstreamer1-qt5-1.2.0_14) (sh)
>> root 415510.0 0.0 12920 3520 0 I11:43 0:00.00 | |
>> `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg
>> (gstreamer1-qt5-1.2.0_14) (sh)
>> root 415520.0 0.0 10340 1744 0 IJ 11:43 0:00.01 | |
>> `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt
>> FLAVOR=qt5 build
>> root 415660.0 0.0 10236 1796 0 IJ 11:43 0:00.00 | |
>> `-- /bin/sh -e -c (cd
>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if !
>> /usr/bin/env QT_SELE
>> root 415670.0 0.0 89976 12896 0 IJ 11:43 0:00.07 | |
>> `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
>> root 415850.0 0.0 102848 25056 0 IJ 11:43 0:00.10 | |
>> |-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E
>> cmake_autogen /wrkdirs/usr/ports/multimedia/g
>> root 415860.0 0.0 102852 25072 0 IJ 11:43 0:00.11 | |
>> `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E
>> cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>
>> or as top showed it:
>>
>> 41552 root 1 52010M 1744K0 wait15 0:00 0.00%
>> /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
>> 41566 root 1 52010M 1796K0 wait 1 0:00 0.00%
>> /bin/sh -e -c (cd
>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if !
>> /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
>> 41567 root 2 52088M13M0 select 4 0:00 0.00%
>> /usr/local/bin/qemu-arm-static ninja -j28 -v all
>> 41585 root 2 520 100M24M0 kqread 8 0:00 0.00%
>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>> 41586 root 2 520 100M24M0 kqread 22 0:00 0.00%
>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>
>> So: waiting in kqread trying to run cmake.
>>
>> Unlike some intermittent hang-up
