Re: Unable to get py-qt5-widgets to install with pyqt:5 and USE_PYQT=widgets

2017-03-15 Thread Kevin Oberman 
How many times can I mis-read the same simple line from the Porter's
Handbook? Especially when there is a perfectly good example in the same
Makefile about 10 lines away? Sigh.

Thanks so much, Tobias.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

On Wed, Mar 15, 2017 at 2:36 AM, Tobias C. Berner <tcber...@freebsd.org>
wrote:

> Hi Kevin
>
> Try
> QT5_USE=   PYQT=core_run,gui_run,dbussupport_run,widgets_run
> instead of your QT5_USE_PYQT line.
>
>
> mfg Tobias
>
>
>
> On 15 March 2017 at 00:54, Kevin Oberman <rkober...@gmail.com> wrote:
>
>> I am attempting to update print/hplip ti build with Qt5. Despite my best
>> efforts, Iave not been able to get pyqt:5 to install py-qt5-widgets.
>>
>> I have the following in the Makefile:
>> QT5_DESC=Use Qt5 graphical user interface
>> QT5_USES=pyqt:5
>> QT5_USE_PYQT=core_run gui_run dbussupport_run widgets_run
>> QT5_CONFIGURE_ENABLE=qt5
>> but only core, gui, and dbussupport get installed. (I am using
>> OPTIONS_SUB= yes) If I manually install py-qt5-widgets, everything works as
>> expected. Tried both with and without "_run".
>>
>> Any idea why this is failing? I suspect I'm doing something dumb.
>>
>> I am not on this list, so please be sure to include me in any reply.
>>
>> Thanks,
>> --
>> Kevin Oberman, Part time kid herder and retired Network Engineer
>> E-mail: rkober...@gmail.com
>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>>
>
>

Unable to get py-qt5-widgets to install with pyqt:5 and USE_PYQT=widgets

2017-03-15 Thread Kevin Oberman 
I am attempting to update print/hplip ti build with Qt5. Despite my best
efforts, Iave not been able to get pyqt:5 to install py-qt5-widgets.

I have the following in the Makefile:
QT5_DESC=Use Qt5 graphical user interface
QT5_USES=pyqt:5
QT5_USE_PYQT=core_run gui_run dbussupport_run widgets_run
QT5_CONFIGURE_ENABLE=qt5
but only core, gui, and dbussupport get installed. (I am using OPTIONS_SUB=
yes) If I manually install py-qt5-widgets, everything works as expected.
Tried both with and without "_run".

Any idea why this is failing? I suspect I'm doing something dumb.

I am not on this list, so please be sure to include me in any reply.

Thanks,
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Re: Fwd: 2017-02-18 Update to Qt 4 and Qt 5

2017-02-20 Thread Kevin Oberman 
On Sun, Feb 19, 2017 at 3:25 AM, Raphael Kubo da Costa <rak...@freebsd.org>
wrote:

> Robert Burmeister <robert.burmeis...@utoledo.edu> writes:
>
> > k...@freebsd.org is not accepting mail
> >
> >>  UPDATING
> >>  Following what is already done in Qt 5, the Qt 4 ports no longer
> install
> >>  their binaries into ${LOCALBASE}/bin (which is "/usr/local/bin" in most
> >>  cases). Additionally, the "-qt4" suffix has been dropped from the file
> names
> >>  of the binaries that had it, such as "qmake-qt4".
> >>
> >
> > Could we have portupgrade instructions?
>
> We'd be more than glad to add those if someone can provide them; I have
> not used portupgrade myself since at least 2009, so it's hard for me to
> provide any instructions.
>
> > Neither QT4 nor QT5 will build on my FreeBSD 11 i386 system.
>
> Can you clarify? What errors are you seeing?


I can't help on portupgrade. but for portmaster, here is a start:
# pkg delete -f qt4-qmake qt4-rcc qt4-clucene qt4-webkit-4.8.7
qt4-linguisttools qt5-qmake dbus-qt5
# portmaster qt4- qt5-

My update is still working on qt4-assistant, ATM, and the huge webkit build
is just starting. All of the qt5 stuff comes next, so the list is likely
not complete. I'll post an update if this finishes before I have to leave
in a couple of hours.

I suspect that the same package deletions are required for portupgrade.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Re: [kde-freebsd] KDE

2014-10-16 Thread Kevin Oberman 
On Wed, Oct 15, 2014 at 4:37 AM, Max Brazhnikov m...@issp.ac.ru wrote:
 On Tue, 14 Oct 2014 11:43:04 -0700 Kevin Oberman wrote:
 On Tue, Oct 14, 2014 at 11:17 AM, Alberto Villa avi...@freebsd.org wrote:

  Hi,
 
  KDE SC 4.14.1 is currently being tested via exp-run, it will hit the ports
  soon.
 
  On Tue, Oct 14, 2014 at 4:10 AM, jmdennis @dslextreme.com 
  jmden...@dslextreme.com wrote:
 
   I was wondering when KDE 14.4.1 would be released.  I know it has to be
   compiled since it is made for Linux and not FreeBSD but it would be nice
  to
   have the newer version released which fixes a lot of issues and is
  faster.
  --
  Alberto Villa, FreeBSD committer avi...@freebsd.org
  http://people.FreeBSD.org/~avilla


 After 10.1-RELEASE, I hope.

 I hope to get it before the release. Why do you want it after?

I get very nervous about major port updates that involve large numbers
of ports and have a major impact on a lot of users just prior to a
release.

Looking at the schedule, which has not slipped at all (Amazing!), 10.1
is 2 weeks off. I'd hope that if it comes before 10.1 that there is
time for a package build and time for people to install it before the
10.1 release. This week's package build is underway and may be
complete. So if you get 4.14 out before next Wednesday, I guess it
should be OK, but if not, I'd suggest waiting until a week or two
after 10.1 hits the streets.

Probably I'm just being paranoid.
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

Re: [kde-freebsd] KDE

2014-10-15 Thread Kevin Oberman 
On Tue, Oct 14, 2014 at 11:17 AM, Alberto Villa avi...@freebsd.org wrote:

 Hi,

 KDE SC 4.14.1 is currently being tested via exp-run, it will hit the ports
 soon.

 On Tue, Oct 14, 2014 at 4:10 AM, jmdennis @dslextreme.com 
 jmden...@dslextreme.com wrote:

  I was wondering when KDE 14.4.1 would be released.  I know it has to be
  compiled since it is made for Linux and not FreeBSD but it would be nice
 to
  have the newer version released which fixes a lot of issues and is
 faster.
 --
 Alberto Villa, FreeBSD committer avi...@freebsd.org
 http://people.FreeBSD.org/~avilla


After 10.1-RELEASE, I hope.
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

Re: [kde-freebsd] Unable to build kdelibs (segmentation fault) or debug it

2014-03-06 Thread Kevin Oberman 
On Wed, Mar 5, 2014 at 5:43 AM, Raphael Kubo da Costa rak...@freebsd.orgwrote:

 Kevin Oberman rkober...@gmail.com writes:

  Linking CXX executable ../bin/kfilemetadatareader
  cd /usr/ports/x11/kdelibs4/work/.build/kio  /usr/local/bin/cmake -E
  cmake_link_script CMakeFiles/kfilemetadatareader.dir/link.txt --verbose=1
  /usr/local/bin/c++   -O2 -pipe -fno-strict-aliasing -Wnon-virtual-dtor
  -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W
  -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS
  -fno-check-new -fno-common -Woverloaded-virtual -O2 -DNDEBUG
  -DQT_NO_DEBUG   -Wl,-rpath,/usr/lib:/usr/local/lib
  CMakeFiles/kfilemetadatareader.dir/kfilemetadatareader_automoc.o
  CMakeFiles/kfilemetadatareader.dir/kfile/kfilemetadatareaderprocess.o  -o
  ../bin/kfilemetadatareader  ../lib/libkio.so.5.12.2
  ../lib/libnepomuk.so.4.12.2 ../lib/libnepomukutils.so.4.12.2
  /usr/local/lib/qt4/libQtNetwork.so /usr/local/lib/qt4/libQtXml.so
  ../lib/libnepomuk.so.4.12.2 ../lib/libkdeui.so.5.12.2
  /usr/local/lib/qt4/libQtGui.so /usr/local/lib/qt4/libQtSvg.so
  /usr/local/lib/libsoprano.so ../lib/libkdecore.so.5.12.2
  /usr/local/lib/qt4/libQtDBus.so /usr/local/lib/qt4/libQtCore.so -pthread
 
 -Wl,-rpath,/usr/ports/x11/kdelibs4/work/.build/lib:/usr/local/lib/qt4:/usr/local/lib:
  -Wl,-rpath-link,/usr/ports/x11/kdelibs4/work/.build/lib
  ../lib/libkio.so.5.12.2: undefined reference to
  `Strigi::AnalysisResult::AnalysisResult(std::basic_stringchar,
  std::char_traitschar, std::allocatorchar  const, long,
  Strigi::IndexWriter, Strigi::StreamAnalyzer, std::basic_stringchar,
  std::char_traitschar, std::allocatorchar  const)'
  collect2: ld returned 1 exit status

 This looks like libc++ and libstdc++ being mixed when building your C++
 ports.


OK. I believe that this implies that there are libraries linked to both
libraries. Correct? I have not seen this with any other C++ ports. How can
I track this down or work around this? I can't see how anything it links to
be linked to stdlibc++, but  I'm looking.I think there are aaout 68
sharables linked to the prior version.

Or do I simply not understand the issue?
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

Re: [kde-freebsd] Unable to build kdelibs (segmentation fault) or debug it

2014-03-05 Thread Kevin Oberman 
On Tue, Mar 4, 2014 at 12:02 AM, Max Brazhnikov m...@freebsd.org wrote:

 On Sat, 01 Mar 2014 11:20:43 -0800 Kevin Oberman wrote:
  I have been unable to upgrade to the latest kdelibs. Attempts to build
 fail
  with a segmentation fault when attempting to generate index.cache.bz2.
  Maybe exhausting some resource?
 
  I'm running 10-Stable (r262619) on an amd64 system and using clang by
  default. All other ports (except those dependent on kdelibs) are current
 as
  of today.
 
  Any idea what may be happening? I can make a core dump available, but I
  imagine that I will need to figure out just what things need to be
 re-built
  with symbols before it will be much help.

 Good start would be build log with CMAKE_VERBOSE=1 DISABLE_MAKE_JOBS=1


Max,

Thanks for the quick response.

Well, that sure slows things down. Made it way past the 33% mark, but died
later at 47%. Of course, that may just be a side effect of serializing the
build, but it did not segv. Instead I see:

Linking CXX executable ../bin/kfilemetadatareader
cd /usr/ports/x11/kdelibs4/work/.build/kio  /usr/local/bin/cmake -E
cmake_link_script CMakeFiles/kfilemetadatareader.dir/link.txt --verbose=1
/usr/local/bin/c++   -O2 -pipe -fno-strict-aliasing -Wnon-virtual-dtor
-Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W
-Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS
-fno-check-new -fno-common -Woverloaded-virtual -O2 -DNDEBUG
-DQT_NO_DEBUG   -Wl,-rpath,/usr/lib:/usr/local/lib
CMakeFiles/kfilemetadatareader.dir/kfilemetadatareader_automoc.o
CMakeFiles/kfilemetadatareader.dir/kfile/kfilemetadatareaderprocess.o  -o
../bin/kfilemetadatareader  ../lib/libkio.so.5.12.2
../lib/libnepomuk.so.4.12.2 ../lib/libnepomukutils.so.4.12.2
/usr/local/lib/qt4/libQtNetwork.so /usr/local/lib/qt4/libQtXml.so
../lib/libnepomuk.so.4.12.2 ../lib/libkdeui.so.5.12.2
/usr/local/lib/qt4/libQtGui.so /usr/local/lib/qt4/libQtSvg.so
/usr/local/lib/libsoprano.so ../lib/libkdecore.so.5.12.2
/usr/local/lib/qt4/libQtDBus.so /usr/local/lib/qt4/libQtCore.so -pthread
-Wl,-rpath,/usr/ports/x11/kdelibs4/work/.build/lib:/usr/local/lib/qt4:/usr/local/lib:
-Wl,-rpath-link,/usr/ports/x11/kdelibs4/work/.build/lib
../lib/libkio.so.5.12.2: undefined reference to
`Strigi::AnalysisResult::AnalysisResult(std::basic_stringchar,
std::char_traitschar, std::allocatorchar  const, long,
Strigi::IndexWriter, Strigi::StreamAnalyzer, std::basic_stringchar,
std::char_traitschar, std::allocatorchar  const)'
collect2: ld returned 1 exit status

All strigi ports look up to date:
# pkg info strigi\*
strigi-0.7.8_2
strigiclient-0.7.8
strigidaemon-0.7.8
strigiutils-0.7.8

I rebuilt them, just in case they are involved. (Also updated cmake, since
the port revision was bumped last night.) No change.
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] Unable to build kdelibs (segmentation fault) or debug it

2014-03-02 Thread Kevin Oberman 
I have been unable to upgrade to the latest kdelibs. Attempts to build fail
with a segmentation fault when attempting to generate index.cache.bz2.
Maybe exhausting some resource?

I'm running 10-Stable (r262619) on an amd64 system and using clang by
default. All other ports (except those dependent on kdelibs) are current as
of today.

Any idea what may be happening? I can make a core dump available, but I
imagine that I will need to figure out just what things need to be re-built
with symbols before it will be much help.
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] Re: Building KDE on PowrPC

2011-03-16 Thread Kevin Oberman 
 Date: Tue, 15 Mar 2011 23:49:45 -0500
 From: Jeremy Messenger mezz.free...@gmail.com
 Sender: owner-freebsd-gn...@freebsd.org
 
 On Tue, Mar 15, 2011 at 11:42 PM, Super Bisquit superbisq...@gmail.com 
 wrote:
  Okay kde4 breaks at /usr/ports/devel/py-gobject with configure missing
  gobject introspection. Gobject-introspection 0.10.4 (I am also building
  gnome3) stops at asking for the file to patch.
 
  This is affecting both desktop suites.
 
 Please post the error log that way I don't have to throw a wild guess.

This is a Python issue. The update script for moving from 2.6 to 2.7
fails to re-install gobj-introspection and this results in several py-*
ports failing. Just re-install the gobj-introspection port and
everything will e fine.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

Re: [kde-freebsd] Dual-head with ATI AIW X800 (R420 JK)/7.1-STABLE/Xorg 7.4 working

2009-03-07 Thread Kevin Oberman 
 Date: Sat, 7 Mar 2009 21:00:48 -0500
 From: Adam K Kirchhoff ad...@voicenet.com
 
 On Sat, 07 Mar 2009 17:50:16 -0800
 Kevin Oberman ober...@es.net wrote:
 
   Date: Sat, 7 Mar 2009 20:26:12 -0500
   From: Adam K Kirchhoff ad...@voicenet.com
   
   On Sat, 07 Mar 2009 17:18:30 -0800
   Kevin Oberman ober...@es.net wrote:
   
 Date: Sat, 7 Mar 2009 19:35:42 -0500 (EST)
 From: Michael L. Squires mi...@siralan.org
 Sender: owner-freebsd-...@freebsd.org
 
 I'm in the process of rebuilding my home desktop to use FreeBSD 
 7.1-STABLE 
 and Xorg 7.4.  Hardware is a Supermicro P6DC6+/ATI AIW X800 with two 
 HP 
 P1110 monitors.
 
 I modified the xorg.conf generated by Xorg -configure to allow for 
 a 
 2560x1024 virtual screen with two 1280x1024 displays and used 
 xrandr to 
 set one monitor to the right of the other, which worked fine.
 
 I'm using KDE4.2, with kdm started in /etc/ttys (thanks Robert) and 
 with 
 both dbus and hal running.
 
 Version of Xorg 7.4 is the version available this morning (3/7/2009), 
 which is identified as xorg-server-1.5.3_6,1 in /var/db/pkg.
 
 The only error I'm seeing is Xlib: extension Generic Event 
 Extension 
 missing on display :0.0. but this seems to have no effects.
 
 The same setup is working fine on my old notebook, a Toshiba 8100 
 which 
 drives one of the two P1110's through a Belkin KVM switch.

First, I'd suggest using 'Option Position 1280 0' in the Monitor
section of the right monitor. (I'd also add Position 0 0 to the left
monitor. It's just cleaner than xrandr since the monitor is correct from
the start.
   
   You can use the RightOf option in the xorg.conf monitor sections, as
   well, to set the position initially.
  
  Maybe, but when I switched from a xinerama config to an xrandr config,
  that stopped working for me. Maybe I needed something else to make it
  work. 
 
 With Xinerama, RightOf was an option in the ServerLayout section.
 With the inclusion of xrandr 1.2, it's an option in the monitor 
 section.
 
 This is a pretty good wiki for xrandr 1.2 and shows a number of
 xorg.conf options and examples:
 http://wiki.debian.org/XStrikeForce/HowToRandR12

Ahh. Thanks!

Guess I need to spend some time reading newer man pages.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

Re: [kde-freebsd] system:/media/cd0 and volume_label not latin symbols

2007-04-06 Thread Kevin Oberman 
 Date: Fri, 6 Apr 2007 13:37:17 +0200
 From: Jean-Yves Lefort [EMAIL PROTECTED]
 Sender: [EMAIL PROTECTED]
 
 --Signature=_Fri__6_Apr_2007_13_37_17_+0200_OapU1fZfsGyEc4EJ
 Content-Type: text/plain; charset=US-ASCII
 Content-Disposition: inline
 Content-Transfer-Encoding: 7bit
 
 On Wed, 4 Apr 2007 12:58:29 +0200
 Michael Nottebrock [EMAIL PROTECTED] wrote:
 
  On Wednesday, 4. April 2007, Jean-Yves Lefort wrote:
 
So I see several solutions:
 1. By default submit to HAL user's locale encoded mount point name.
  
   This is not possible. All hal data must be encoded in UTF-8.
  
 2. Modify mount point naming scheme to something which is not
dependant on locale encoding, for example, to device name.
  
   I'd rather not make this the default behaviour. The volume label is
   much more informative than the device name and should cause no
   problems for most users.
  
 3. Change user's locale to UTF8.
  
   This is the recommended solution. UTF-8 is now universally supported
   and I see no reason to stick to a legacy encoding.
 
  Universally supported except in FreeBSD. :( I'm not aware of any substantial
  work on UTF-8 since it was imported, which would mean that there's still no
  collation support.
 
  If even some Linux distributions despite their vastly superior UTF-8 support
  apparently do it, I think solution 2 should at least be offered via OPTIONS
  right in the port - installing an alternative ruleset wouldn't be too
  difficult to implement.
 
 What would be difficult (or impossible) would be to provide a
 satisfactory explanation of the option using the small number of
 characters available.
 
 You're right that the FreeBSD libc lacks Unicode collation support,
 but it seems that no gain is made by sticking to a legacy locale:
 
 $ touch A B a b
 $ export LANG=en_US.UTF-8; ls
 A   B   a   b
 $ export LANG=en_US.ISO8859-1; ls
 A   B   a   b
 
 As you can see, the files are incorrectly sorted with both locales. On
 a Linux box, the sort order is correct (a A b B) in both cases.
 
 If someone can convince me that there are good reasons to use a legacy
 locale, I might add the option despite the fact that its description
 would be cryptic.
 
Jean-Yves,

I guess the term correct is unclear as for en_US languages. The order
should be either A a B b or A B a b. The answer you see is the one
most commonly used on computers, (A B a b). It is also the one
used by the default LANG=C.

What you call the correct order is not normal collation sequencing in
the US and that is the country that these languages are supposed to
support.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgpPNaBKWObbD.pgp
Description: PGP signature
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd