Re: Should we Rust warnings suggesting adding work/stage/usr/local/bin to the PATH?

[Luca Pizzamiglio]

Hi Mateusz,
I've no idea how, but it's obviously misleading and somehow wrong, we
should mute this message

Best regards,
Luca

On Thu, May 17, 2018 at 3:26 PM, Stefan Esser  wrote:

> Am 17.05.18 um 14:42 schrieb Mateusz Piotrowski:
> > Hello,
> >
> > When I build Rust packages I get warnings like this one:
> >
> >> warning: be sure to add `/usr/home/0mp/ports/games/
> genact/work/stage/usr/local/bin` to your PATH to be able to run the
> installed binaries
> >
> > It is not very helpful when building ports. Do you think that we should
> > try to mute it by default?
>
> I have seen such a message when building a Haskell based port, too.
>
> Seems there are more languages (or build systems) that perform such
> a check and emit a misleading warning ...
>
> Regards, STefan
> ___
> 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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: x11/wbar build failure on 12-CURRENT

[Luca Pizzamiglio]

Hi Sergey,
Thanks for the patch!
Unfortunately there's no attachment, I'm pretty sure they are automatically
removed.

You can fill a PR on bugs.freebsd.org and a committer can take care of your
patch!

Best regards,
pizzamig

On Mon, Apr 9, 2018 at 7:40 PM, Sergey V. Dyatko 
wrote:

> Hi,
>
> after clang6 was imported to HEAD x11/wbar stopped to build with following
> error[s]:
>
> ../src/config/Functions.cc:14:34: error: invalid suffix on literal; C++11
> requires a space between literal and identifier
> [-Wreserved-user-defined-literal] #define ICON_DEFAULT
> PIXMAPDIR"/"PACKAGE_NAME".png" ^
>
> with following patches it builds just fine and as I can see it works fine
> too
>
> --
> wbr, Sergey
>
> ___
> 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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: pgpool-II37-3.7.2

[Luca Pizzamiglio]

Thanks for your work!
Unfortunately, there is no attachment and I'm pretty sure attachments are
automatically removed in this mailing list.
Why don't you submit a PR on bugs.freebsd.org ?
This is the suggested way to submit new ports.

Best regards
pizzamig

On Thu, Apr 12, 2018 at 10:19 PM, Franco Ricci 
wrote:

> Hi,
> i tried to port pgpool-II-3.7.2 on FreeBSD 11.1.
> Attached there is the new port; I make some test and It’s seems to work
> fine.
>
> Bye
> Franco
>
> ___
> 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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: codeblocks-devel looking for a committer

[Luca Pizzamiglio]

I'll take care of it

Best regards,
pizzamig

On Thu, Oct 26, 2017 at 7:08 AM, L.Bartoletti  wrote:
> Hi all,
>
> Since codeblocks is still buggy, I'm looking for a committer to PR #221703
> to have codeblocks-devel which works.
>
> Thank you.
>
> Regards
>
> Loïc
>
> ___
> 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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: qemu-aarch64-static

[Luca Pizzamiglio]

If you want to cross-compile, you need
* a proper toolchain
* a project that's enable to produce cross-compiled binaries


On Tue, Aug 22, 2017 at 8:04 PM, Andrea Venturoli <m...@netfence.it> wrote:
> On 08/22/17 18:03, Luca Pizzamiglio wrote:
>>
>> yes, the qemu emulation of other architecture means that the CPU is
>> emulated by software, that's really expensive.
>> You should consider around 10x slower or even more. ccache can help a
>> lot in this case.
>
>
> Thanks.
> So you are confirming my poudriere is running an ARM compiler to produce ARM
> code?

I've played with cross-compile in the past and that's my understanding.

>
> What's the use of "-x" when creating a jail then?
> What role does the "native cross-toolchain" play?

The FreeBSD jail is built using a cross-toolchain (fast) and it
contains "cross-binaries" (in case of ARM, in the jail you will have a
compiler which host and target are ARM)
The packages are built inside a "cross-jail" (slow)

The problem is that external ports often don't support cross-compile,
so instead of modify tons of ports to add cross-tollchain support,
poudriere/FreeBSD exploit features offered by binmisc/qemu to build
binaries in a emulated environment. The big drawback is the speed.

> I understood that would mean running an AMD64 compiler to cross-build ARM
> code... and thought that its timings would be comparable to native building.
> Is that wrong?
>
>  bye & Thanks
> av.
___
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: qemu-aarch64-static

[Luca Pizzamiglio]

yes, the qemu emulation of other architecture means that the CPU is
emulated by software, that's really expensive.
You should consider around 10x slower or even more. ccache can help a
lot in this case.

Best regards,
Luca


On Tue, Aug 22, 2017 at 7:40 AM, Andrea Venturoli  wrote:
> On 08/17/17 21:22, Jan Beich wrote:
>
>> Yep. Link the binary (i.e. "date") statically or run it inside
>> jail/chroot.
>> Otherwise, /libexec/ld-elf.so.1 references the host system, which on amd64
>> wouldn't recognize aarch64 shared libraries.
>
>
> Thanks a lot.
> Now it seems so obvious to me, but I really wouldn't have thought about this
> little detail :)
>
>
>
>> That page is a bit out of date. Nowadays building for aarch64 is as simple
>> as
>>
>>$ pkg install poudriere qemu-user-static
>>$ service qemu_user_static onestart
>>$ poudriere jail -cj 111aarch64 -a arm64.aarch64 -v 11.1-RELEASE
>>$ poudriere bulk -j 111aarch64 category/port
>
>
> I can confirm this is working.
>
>
>
>> To speed up port builds you may want to consider using native
>> cross-toolchain by creating a jail with -x flag.
>
>
> Do you have any more info on this?
> Except from poudriere's man page's description I could find no other docs.
> Is there any more elaborate description on what this does and how?
>
> I built the jail with -x, but how do I check it's using "native-xtools"?
>
> I tried building ports-mgmt/pkg and it requires ten times more than native
> build (i.e. 24 minutes for aarch64 vs. less than 3 minutes for amd64). Is
> this normal?
>
>
>
>  bye & Thanks
> av.
>
> ___
> 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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: situation with www/node6 and www/node

[Luca Pizzamiglio]

Hi,

node6 is the LTS, node is the current. From a stability point of view,
node6 is the choice, but node (7) is already widely used.
Probably, the best solution would be to provide the desired node
version via Mk/bsd.default-versions.mk and then all ports depends to
the common version (like perl, python, ...).

In the meanwhile, node can be the new default for yarn and the
conflict will be solved (and it will be coherent with npm)
___
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: The future of portmaster

[Luca Pizzamiglio]

Hi all,

thanks for all the replies.

To summarize:
* chroot/jails build could be a nice feature, but it will be an
option, not a requirement. I understand the needs to build in a clean
environment (poudriere and synth works in this direction for a good
reason), but as port maintainer, building in a "dirty" environment
detects this kind of configure problems (library auto-detected or
auto-enabled) that a clean environment cannot shows.
* dropping privileges is really a nice feature to add. The portstree
allow you to build everything as normal user, so portmaster can be
able to do it as well.
* show flags when build fails should be doable
* the dependency order is something I'd like to work on, also to
improve the internal management

I'd like to re-enabling at least --packages-build, that can be really useful.
I'll remove:
--packages-only|-PP : it looks redundant to me
-e : as above, it's redundant; to remove distfiles, --clean-distfiles
can be used after a pkg delete

I'm also considering to remove, if nobody is using them:
* all the --index options, but only
* +IGNOREME support (a file saved in /var/db/pkg/ to force ignore)

No ETA, but I'll do my best.

Best regards,
pizzamig



On Fri, Feb 17, 2017 at 5:55 PM, Chris H <bsd-li...@bsdforge.com> wrote:
> On Fri, 17 Feb 2017 10:37:16 +0300 abi <a...@abinet.ru> wrote
>
>> 17.02.2017 00:22, Chris H пишет:
>> > On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot <baho-u...@columbus.rr.com>
>> > wrote >
>> >> On 02/16/17 15:40, George Mitchell wrote:
>> >>> On 02/16/17 15:33, Baho Utot wrote:
>> >>>>
>> >>>> On 02/16/17 14:01, Lowell Gilbert wrote:
>> >>>>> Baho Utot <baho-u...@columbus.rr.com> writes:
>> >>>>>
>> >>>>>> On 02/16/17 06:08, Luca Pizzamiglio wrote:
>> >>>>>>> I'm looking for constructive critics, feedbacks, anything that can
>> >>>>>>> help me to make portmaster an actively maintained and used tool.
>> >>>>>> If you can have it build in a clean chroot or jail then you'll get my
>> >>>>>> attention
>> >>>>> What kind of special support?
>> >>>>>
>> >>>>> I use it with a chroot that mounts /usr/ports (and src) read-only, and
>> >>>>> aside from the initial base system install, it took about fifteen
>> >>>>> minutes to set up.
>> >>>>>
>> >>>> Using chroot or jails to build each individual package
>> >>>> [...]
>> >>> While I understand the interest in chroot/jails as an optional
>> >>> feature, I hope it doesn't become required.  The current non-use
>> >>> of chroot/jails is, for me, a feature -- not a bug.-- George
>> >>>
>> >>>
>> >> Having built and packaged linux from scratch using the rpm package
>> >> manager, I came to find that if one is building packages to be used on
>> >> multiple machines, one needs to build each package in a chroot
>> >> environment or the package could inherit things from the parent not
>> >> found in the target machine.  Here by making the package unusable.
>> > Hello. You shouldn't have any difficulty accomplishing your goal
>> > by simply setting up a jail, and using portmaster within that jail(8).
>> > portmaster really doesn't care where it's run. So long as it has
>> > everything it needs to accomplish it's job(s). :-)
>> >
>>  From my point of view, jails are overkill. Chroot should be enough and
>> it would be nice if portmaster starts building in clean environment.
> Oh, I won't argue that. Indeed, chroot(8) is a much lighter solution.
> But for my needs, jail(8) is the best solution. As I've already setup
> a number for other tasks, anyway.
> Speaking of chroot(8), synth(1) chroots all its work.
>
> All the best.
>
> --Chris
>
>
> ___
> 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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

The future of portmaster

[Luca Pizzamiglio]

Hi all,

portmaster, a tool used/loved/hated, is almost in abandoned state.
I'm a portmaster user, because, in some cases, it fits my needs.
In other cases, I use other tools, like poudriere or synth, that are
really great.
I don't want to open a discussion here about what it's better, but the
truth is, that I use portmaster and it's not maintained.
So I decided to spend some time to look at it and to work on it.

I forked it and I start some work.
The plan is:
- remove obsolete features, like the -PP option
- remove pkg_* support (even if someone could be against it), forcing
the usage of pkg
- prepare the support of new features like FLAVORS and subpackages
- adding a new ports, called portmaster-devel, for the new version

I did a branch on github working of the first two points
(https://github.com/pizzamig/portmaster/tree/remove_oldpkg)

I'm looking for constructive critics, feedbacks, anything that can
help me to make portmaster an actively maintained and used tool.

Thanks in advance

Best regards,
pizzamig

PS: I won't start a port/pkg tool war, my opinion is that the world is
big enough to have poudriere, synth, portmaster, portupgrade and
whatever tool you will write to handle/build any ports package in the
way that you prefer.
___
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: HEADSUP: FLAVORS (initial version) and subpackages proposals

[Luca Pizzamiglio]

Hi,

I think it's a nice to have and an improvement.
It's quite clean, even if the number of Makefile's can really increase.

I've some questions:

Q1) It seems obvious (at least to me), that DOCS and EXAMPLES
should/could become subpackages.
How it could be handled by pkg? Are you thinking to add some "magic"
to enable or disable the automatic installation of specific
subpackages?

Q2) are we opening the door the -devel packages like some Linux distros?

Q3) Do you think there is a general way to decide what should stay an
OPTION and what should/could become a FLAVOR?

Q4) Can FLAVORs be in CONFLICT with each others or only conflict-free
FLAVOR will be accepted?
If ports can depend to FLAVOR, strange CONFLICTS can arise..

Thanks for the great job! I'll keep contributing as much as I can.

Best regards,
Luca

On Tue, Dec 20, 2016 at 10:12 AM, Franco Fichtner  wrote:
>
>> On 20 Dec 2016, at 9:42 AM, Franco Fichtner  wrote:
>>
>> To emphasise on this:
>
> And lastly... if we have the automatic "default" flavour that is
> defined by the OPTIONS_DEFAULT knobs, we could finally avoid pkg
> upgrading custom builds by knowing that somebody built a "custom"
> version of their port and that there is no equivalent to upgrade
> to.
>
> This is exciting!
>
>
> Cheers,
> Franco
> ___
> 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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: net/haproxy 1.7.0 : libressl support

[Luca Pizzamiglio]

Hi Dmitry,

thanks for the suggesstion. There's some discussion on haproxy mailing
list about how to handle the problem and they're more prone to don't
support libressl, so my patch could be rejected.
And, even if my patch is accepted, it will be part of haproxy 1.7.1.
BTW, I'll fill a PR because the attachments are removed. Then the port
maintainer (who is in CC) can better decide what to do, if adopt them
in FreeBSD, if upstrem them, if reject them...

Best regards
Luca

On Fri, Dec 9, 2016 at 1:02 AM, Dmitry Sivachenko <trtrmi...@gmail.com> wrote:
>
>
>> 8 дек. 2016 г., в 22:51, Luca Pizzamiglio <luca.pizzamig...@gmail.com> 
>> написал(а):
>>
>> Hi guys,
>>
>> I had to build haproxy 1.7.0 using openssl and libressl.
>> libressl support is not really provided, becuase of the
>> OPENSSL_VERSION_NUMBER issue between those two libraries.
>>
>> In attachment there're two patches ready to be put in the files
>> directory and that solve (temporarily) the build issue.
>>
>
>
> Hello,
>
> First step should be to offer these patches to haproxy maintainers, because 
> this is not FreeBSD-specific problem.
>
> Can you please do it?
>
> Thanks!
>
>
>> Best regards
>> Luca
>>
>> PS I didn't fill a PR because I'm not sure if those patches work in
>> all situation or with all options, so it's just a help for the
>> maintainer, but maybe not a solution.
>> 
>> 
___
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"

net/haproxy 1.7.0 : libressl support

[Luca Pizzamiglio]

Hi guys,

I had to build haproxy 1.7.0 using openssl and libressl.
libressl support is not really provided, becuase of the
OPENSSL_VERSION_NUMBER issue between those two libraries.

In attachment there're two patches ready to be put in the files
directory and that solve (temporarily) the build issue.

Best regards
Luca

PS I didn't fill a PR because I'm not sure if those patches work in
all situation or with all options, so it's just a help for the
maintainer, but maybe not a solution.
___
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: Cannot update firebird25 after recent icu update

[Luca Pizzamiglio]

The problem with firebird is that, during the linking process, the
link order is wrong: it takes the firebird libraries in /usr/local/lib
library ignoring the local ones.

The workaround is to delete firebird and reinstall it, but the wrong
link order is still a problem.

Best regards,
pizzamig

On Thu, Jul 7, 2016 at 7:04 AM, Jakub Lach  wrote:
> I know, I'm on 10-STABLE though, but will not force 57.1 now obviously,
> thanks for all replies!
>
>
>
> --
> View this message in context: 
> http://freebsd.1045724.n5.nabble.com/Cannot-update-firebird25-after-recent-icu-update-tp6112177p6112250.html
> Sent from the freebsd-ports mailing list archive at Nabble.com.
> ___
> 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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Running ''portmaster ghostscript9-9.06_10'' takes a lot of time

[Luca Pizzamiglio]

Hi Henk,
same here.

make -V PKGNAME in ghostscript9 takes a huge amount of time.
BTW, every make in ghostscript* takes a lot of time.

I've no idea why.

Best regards,
Luca


On Wed, Aug 19, 2015 at 5:45 AM, Henk van Oers h...@signature.nl wrote:

 All my ports are up to date,
 but running ''portmaster -va'' on ~1000 ports takes more then 50 minutes.

 Most time is spend on ghostscript9-9.06_10

 I started a ''portmaster ghostscript9-9.06_10'' a while ago
 and it does not do any thing yet but using 100% CPU on one prosessor.

 What is going on?

 --
 Henk
 ___
 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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [BUG] GDB port bug report due to login problems with Bugzilla

[Luca Pizzamiglio]

Hi Norbert,

it could be a problem related to i386, because on amd64 it works perfectly.
I'll try to get a i386 system and test it more deeply.

thanks for the help

best regards,
pizzamig

On Wed, Aug 13, 2014 at 11:42 AM, Norbert Koch nk...@demig.de wrote:
 Hello.

 As I am not able to login to Bugzilla to report a bug
 (502 Bad Gateway from nginx?)  I would like to inform
 you here about a bug in devel/gdb.

 Since before updating to 7.8.1 I had no problems.

 Now with latest patch to fbsd-threads.c (R 364713)
 gdb crashes with the first run command.

 % gdb78 `which gdb78`gdb78.core
 GNU gdb (GDB) 7.8 [GDB v7.8 for FreeBSD]
 Copyright (C) 2014 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as i386-portbld-freebsd9.1.
 Type show configuration for configuration details.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/.
 Find the GDB manual and other documentation resources online at:
 http://www.gnu.org/software/gdb/documentation/.
 For help, type help.
 Type apropos word to search for commands related to word...
 Reading symbols from /usr/local/bin/gdb78...done.
 [New process 100614]
 Core was generated by `gdb78'.
 Program terminated with signal SIGABRT, Aborted.
 #0  0x293c73f7 in kill () from /lib/libc.so.7
 (gdb) bt
 #0  0x293c73f7 in kill () from /lib/libc.so.7
 #1  0x293c7316 in raise () from /lib/libc.so.7
 #2  0x293c5d9a in abort () from /lib/libc.so.7
 #3  0x0841ba8a in can_dump_core (reason=0x89f49b0 DB does when %s is
 detected.) at utils.c:630
 #4  0x0841bdb1 in internal_verror (
 file=0x299dca80 target.c:2626: internal-error: Can't determine the
 current address space of thread LWP 1\n\nA problem internal to GDB has
 been detected,\nfurther debugging may prove unreliable.,
 line=144656744, fmt=0x89f49cf , ap=0x299e8c00 (y or n) ) at utils.c:802
 #5  0x089f49b0 in ?? ()
 #6  0x0841be1e in ?? () at utils.c:813
 #7  0x0841be5c in internal_warning (
 file=0x89d1947 col of the target machine.\nRemaining arguments are
 interpreted by the target protocol.  For more\ninformation on the
 arguments for a particular protocol, type\n`help target ' followed by
 the protocol na..., line=2626, string=0x89d25a4 LL) at utils.c:832
 #8  0x08354773 in target_thread_address_space (ptid=...) at target.c:2642
 #9  0x0834dd24 in tdefault_trace_init (self=0x92982c0 dummy_target) at
 target-delegates.c:964
 #10 0x0834dd24 in tdefault_trace_init (self=0x92c5d40 exec_ops) at
 target-delegates.c:964
 #11 0x0834dd24 in tdefault_trace_init (self=0x298ba500) at
 target-delegates.c:964
 #12 0x0834dd24 in tdefault_trace_init (self=0x9290400 fbsd_thread_ops)
 at target-delegates.c:964
 #13 0x083547ab in target_thread_address_space (ptid=...) at target.c:2645
 #14 0x082b2227 in ?? () at regcache.c:491
 #15 0x082b231a in regcache_observer_target_changed (target=0x8999254) at
 regcache.c:520
 #16 0x0830b960 in thread_still_needs_step_over (tp=0x29a02900) at
 infrun.c:2110
 #17 0x08311beb in keep_going (ecs=0xbfbfe138) at infrun.c:5809
 #18 0x0830f842 in process_event_stop_test (ecs=0xbfbfe138) at infrun.c:4590
 #19 0x0830f292 in process_event_stop_test (ecs=0xbfbfe138) at infrun.c:4349
 #20 0x0830e525 in handle_inferior_event (ecs=0xbfbfe138) at infrun.c:3830
 #21 0x0830ca66 in fetch_inferior_event (client_data=0x298ba500) at
 infrun.c:2865
 #22 0x0830bfa8 in start_remote (from_tty=674835856) at infrun.c:2423
 #23 0x08304d1c in ?? () at infcmd.c:641
 #24 0x08304d50 in start_command (args=0x0, from_tty=1) at infcmd.c:660
 #25 0x0823b41b in do_sfunc (c=0x299d1350, args=0x0, from_tty=1) at
 ./cli/cli-decode.c:123
 #26 0x0823e241 in multi_line_command_p (type=698159952) at
 ./cli/cli-script.c:97
 #27 0x08419253 in execute_command (p=0x2983b081 , from_tty=1) at top.c:482
 #28 0x0832c821 in command_line_handler (rl=0x2983b080 ) at event-top.c:460
 #29 0x0832cd73 in gdb_readline2 (client_data=0x2983d134) at event-top.c:653
 #30 0x2912a117 in rl_callback_read_char () from
 /usr/local/lib/libreadline.so.6
 #31 0x0832c3ab in change_line_handler () at event-top.c:200
 #32 0x0832c712 in async_disable_stdin () at event-top.c:399
 #33 0xbfbfe6ac in ?? ()
 (gdb) q


 % uname -a
 FreeBSD entw-pr2.demig.intra 9.1-RELEASE FreeBSD 9.1-RELEASE #2: Wed
 Feb  6 17:03:36 CET 2013
 root@entw-pr2.demig.intra:/usr/obj/usr/src/sys/ENTW-PR2  i386


 Best regards,
 Norbert Koch
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any 

Re: [BUG] GDB port bug report due to login problems with Bugzilla

[Luca Pizzamiglio]

Hi Norbert,
I installed a i386 10.0 system and I can debug with gdb78.

I've built gdb-7.8_1 and used it to debug a hello world. It worked.
I ran gdb78 to debug gdb78 debugging a hello world. It worked.
In other words, here is everything fine.

The error you show is quite strange: the whole trace is quite a messy:
the function tdefault_trace_init, showed 4 times, is not even called,
as the first resolved function async_disable_stdin.
I guess that the crash has corrupted the core dump in some way...

At the moment, I cannot install a FreeBSD 9.1 system, but I will try next days.

Could you give me also the port's configuration? Some special
configuration in make.conf? Compiler used to build gdb?

Thanks in advance

best regards,
pizzamig



On Wed, Aug 13, 2014 at 12:55 PM, Luca Pizzamiglio
luca.pizzamig...@gmail.com wrote:
 Hi Norbert,

 it could be a problem related to i386, because on amd64 it works perfectly.
 I'll try to get a i386 system and test it more deeply.

 thanks for the help

 best regards,
 pizzamig

 On Wed, Aug 13, 2014 at 11:42 AM, Norbert Koch nk...@demig.de wrote:
 Hello.

 As I am not able to login to Bugzilla to report a bug
 (502 Bad Gateway from nginx?)  I would like to inform
 you here about a bug in devel/gdb.

 Since before updating to 7.8.1 I had no problems.

 Now with latest patch to fbsd-threads.c (R 364713)
 gdb crashes with the first run command.

 % gdb78 `which gdb78`gdb78.core
 GNU gdb (GDB) 7.8 [GDB v7.8 for FreeBSD]
 Copyright (C) 2014 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as i386-portbld-freebsd9.1.
 Type show configuration for configuration details.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/.
 Find the GDB manual and other documentation resources online at:
 http://www.gnu.org/software/gdb/documentation/.
 For help, type help.
 Type apropos word to search for commands related to word...
 Reading symbols from /usr/local/bin/gdb78...done.
 [New process 100614]
 Core was generated by `gdb78'.
 Program terminated with signal SIGABRT, Aborted.
 #0  0x293c73f7 in kill () from /lib/libc.so.7
 (gdb) bt
 #0  0x293c73f7 in kill () from /lib/libc.so.7
 #1  0x293c7316 in raise () from /lib/libc.so.7
 #2  0x293c5d9a in abort () from /lib/libc.so.7
 #3  0x0841ba8a in can_dump_core (reason=0x89f49b0 DB does when %s is
 detected.) at utils.c:630
 #4  0x0841bdb1 in internal_verror (
 file=0x299dca80 target.c:2626: internal-error: Can't determine the
 current address space of thread LWP 1\n\nA problem internal to GDB has
 been detected,\nfurther debugging may prove unreliable.,
 line=144656744, fmt=0x89f49cf , ap=0x299e8c00 (y or n) ) at utils.c:802
 #5  0x089f49b0 in ?? ()
 #6  0x0841be1e in ?? () at utils.c:813
 #7  0x0841be5c in internal_warning (
 file=0x89d1947 col of the target machine.\nRemaining arguments are
 interpreted by the target protocol.  For more\ninformation on the
 arguments for a particular protocol, type\n`help target ' followed by
 the protocol na..., line=2626, string=0x89d25a4 LL) at utils.c:832
 #8  0x08354773 in target_thread_address_space (ptid=...) at target.c:2642
 #9  0x0834dd24 in tdefault_trace_init (self=0x92982c0 dummy_target) at
 target-delegates.c:964
 #10 0x0834dd24 in tdefault_trace_init (self=0x92c5d40 exec_ops) at
 target-delegates.c:964
 #11 0x0834dd24 in tdefault_trace_init (self=0x298ba500) at
 target-delegates.c:964
 #12 0x0834dd24 in tdefault_trace_init (self=0x9290400 fbsd_thread_ops)
 at target-delegates.c:964
 #13 0x083547ab in target_thread_address_space (ptid=...) at target.c:2645
 #14 0x082b2227 in ?? () at regcache.c:491
 #15 0x082b231a in regcache_observer_target_changed (target=0x8999254) at
 regcache.c:520
 #16 0x0830b960 in thread_still_needs_step_over (tp=0x29a02900) at
 infrun.c:2110
 #17 0x08311beb in keep_going (ecs=0xbfbfe138) at infrun.c:5809
 #18 0x0830f842 in process_event_stop_test (ecs=0xbfbfe138) at infrun.c:4590
 #19 0x0830f292 in process_event_stop_test (ecs=0xbfbfe138) at infrun.c:4349
 #20 0x0830e525 in handle_inferior_event (ecs=0xbfbfe138) at infrun.c:3830
 #21 0x0830ca66 in fetch_inferior_event (client_data=0x298ba500) at
 infrun.c:2865
 #22 0x0830bfa8 in start_remote (from_tty=674835856) at infrun.c:2423
 #23 0x08304d1c in ?? () at infcmd.c:641
 #24 0x08304d50 in start_command (args=0x0, from_tty=1) at infcmd.c:660
 #25 0x0823b41b in do_sfunc (c=0x299d1350, args=0x0, from_tty=1) at
 ./cli/cli-decode.c:123
 #26 0x0823e241 in multi_line_command_p (type=698159952) at
 ./cli/cli-script.c:97
 #27 0x08419253 in execute_command (p=0x2983b081 , from_tty=1) at top.c:482
 #28 0x0832c821 in command_line_handler (rl=0x2983b080 ) at event-top.c:460
 #29 0x0832cd73 in gdb_readline2 (client_data=0x2983d134

Re: ports-mgmt/portmaster and DEFAULT_VERSION=gcc=4.8: lang/gcc dependency added

[Luca Pizzamiglio]

Hi Tijl,

I've tested the patch and it works! Thanks!
Is this patch submittable?

thanks again!
best regards,
pizzamig


On Tue, Aug 5, 2014 at 6:43 PM, Tijl Coosemans t...@freebsd.org wrote:
 On Tue, 5 Aug 2014 16:41:24 +0200 Luca Pizzamiglio wrote:
 Hi list,
 I found a small issue with ports-mgmt/portmaster and the variable
 DEFAULT_VERSION defined in /etc/make.conf

 I normally use clang, to build my ports, but I use the gcc48 port
 also. The actual lang/gcc is gcc 4.7.4, but I wouldn't another gcc
 installed :)
 In order to use lang/gcc48 instead of lang/gcc, I set
 DEFAULT_VERSION=gcc=4.8 in /etc/make.conf

 Now, if you try to build with portmaster any port that requires gcc,
 the dependency lang/gcc is added (for instance, with astro/wcslib, but
 also www/firefox or mail/thunderbird)
  # portmaster -D astro/wcslib

 === Currently installed version: wcslib-4.23
 === Port directory: /usr/ports/astro/wcslib

 === Launching 'make checksum' for astro/wcslib in background
 === Gathering dependency list for astro/wcslib from ports
 === Launching child to install lang/gcc

 === wcslib-4.23  lang/gcc (1/1)

 === Port directory: /usr/ports/lang/gcc

 === Launching 'make checksum' for lang/gcc in background
 === Gathering dependency list for lang/gcc from ports

 If I run a simple make from the directory /usr/ports/astro/wcslib,
 no dependency is added and the right gcc is used.

 Am I the only one with this issue?

 Can you try the attached patch?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

ports-mgmt/portmaster and DEFAULT_VERSION=gcc=4.8: lang/gcc dependency added

[Luca Pizzamiglio]

Hi list,
I found a small issue with ports-mgmt/portmaster and the variable
DEFAULT_VERSION defined in /etc/make.conf

I normally use clang, to build my ports, but I use the gcc48 port
also. The actual lang/gcc is gcc 4.7.4, but I wouldn't another gcc
installed :)
In order to use lang/gcc48 instead of lang/gcc, I set
DEFAULT_VERSION=gcc=4.8 in /etc/make.conf

Now, if you try to build with portmaster any port that requires gcc,
the dependency lang/gcc is added (for instance, with astro/wcslib, but
also www/firefox or mail/thunderbird)
 # portmaster -D astro/wcslib

=== Currently installed version: wcslib-4.23
=== Port directory: /usr/ports/astro/wcslib

=== Launching 'make checksum' for astro/wcslib in background
=== Gathering dependency list for astro/wcslib from ports
=== Launching child to install lang/gcc

=== wcslib-4.23  lang/gcc (1/1)

=== Port directory: /usr/ports/lang/gcc

=== Launching 'make checksum' for lang/gcc in background
=== Gathering dependency list for lang/gcc from ports

If I run a simple make from the directory /usr/ports/astro/wcslib,
no dependency is added and the right gcc is used.

Am I the only one with this issue?

uname -a
FreeBSD pizzamig 9.3-RELEASE FreeBSD 9.3-RELEASE #0 r268512: Thu Jul
10 23:44:39 UTC 2014
r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64


Best regards,
pizzamig
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [9.2-STABLE/CLANG 3.3|3.4] x11/kdelibs4

[Luca Pizzamiglio]

Hi list,
I've updated my system to FreeBSD 9.3, with clang 3.4.
My make.conf set clang as default compiler.

kdelibs4 seems having a problem, or better, clang 3.4 seems having a
problem to compile one specific kdelibs4's file.
clang++ compiles the file parser.cpp (khtml/css module) for ever and ever...

Looking into it, it seems generated by bison 2.5.1, but the currently
installed bison is 2.7.1.

It's not the same problem with Kate, (Kate build process needs 5GB
RAM, more or less), because I verified the RAM usage: SIZE is
~90-100MB, RSS 70-80MB, swap used 0KB.

The current workaround is using gcc.
Is it a known issue?
Moreover, is it a clang problem? A kdelibs problem? A bison problem?


Best regards,
pizzamig

On Sun, Apr 20, 2014 at 9:38 PM, Raphael Kubo da Costa
rak...@freebsd.org wrote:
 Dimitry Andric d...@freebsd.org writes:

 The box in question is a Dell Latitude E6510 notebook with only 4 GB of 
 RAM, could this
 be the issue? The system very often starts swapping. Even my oldstyle E8400 
 workstation
 with only 8 GB (most recent 11.0-CURRENT) starts swapping very often and 
 recently, I saw
 musterious compiler erros and stopping compiling processes never seen 
 bevor. Restarting
 the failed portbuild most often finish successfully.

 There were some postings recently, about newer versions of FreeBSD being
 supposedly more swappy, see e.g.:

 http://lists.freebsd.org/pipermail/freebsd-stable/2014-April/thread.html#78361

 I have no idea if this is really substantiated with evidence, or just a
 feeling, though. :)

 In any case, when you are experiencing mysterious compiler errors, and
 your system is heavily exercising RAM and swap, it is always a good idea
 to do a full hardware diagnostics test.

 For your RAM, you can use memtest86+, and since you have a Dell, you can
 use their diagnostics program to test other parts of the machine.

 For what it's worth, ports/187150 might be related to this as well (I've
 never experienced those problems myself, but I'm on HEAD).

 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: CFT: vlc 2.0.5

[Luca Pizzamiglio]

There is a dynamic library loading of libicu*.so.48 in devel/qt4-corelib.
Unfortunately, this is not a declared as a dependency in the Makefile.
Recompile it.
This solved the issue on my system.

Best regards,
Luca

On Sat, Dec 22, 2012 at 3:53 AM, Kevin Oberman kob6...@gmail.com wrote:
 On Thu, Dec 20, 2012 at 1:38 PM, Juergen Lock n...@jelal.kn-bremen.de wrote:
 On Thu, Dec 20, 2012 at 09:18:03PM +0100, René Ladan wrote:
 On 19-12-2012 22:44, Juergen Lock wrote:
  Hi!
 
   It's this time again, there's a new vlc release out and I want to update
  the port:
 
  http://people.freebsd.org/~nox/tmp/vlc-2.0.5-001.patch
 
   Everyone is invited to test this update and post any issues they find...
 
 A quick test with an online mp3 stream works fine, but I do get this
 message in the console:

 VLC media player 2.0.5 Twoflower (revision 2.0.5-0-g1661b7d)

 Unable to load library icui18n Cannot load library icui18n: (Shared
 object libicui18n.so.48 not found, required by vlc)

 I have icu-50.1 installed, although the port does not seem to use it.
 So maybe it is triggered by some dependency.

 I don't get that here so yes it's probably a problem in a dependency.

 Sorry for those who have seen this in other threads.

 To find and fix these issues:
 Install sysutils/bsdadmonscripts (If you use pkgng, pleaqse be sure
 that you have the latest version!)
 # pkg_libchk -o | grep libicu | cut -f1 -d: | sort | uniq  somefile
 # portmaster -D `cat somefile`

 This will update all ports that are still linked to the old icu
 libraries. This should be a very short list as only a handful of ports
 link directly to these libraries. Many more depend on these ports, but
 don't directly link to libicu sharables and don't need re-building.
 --
 R. Kevin Oberman, Network Engineer
 E-mail: kob6...@gmail.com
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

libreoffice 3.5.7_1 and icu-50.1

[Luca Pizzamiglio]

Hi,

I've some trouble to compile libreoffice 3.5.7_1 after icu update to 50.1
version

the problem is located in i18npool module and the error is during the link
phase:

/usr/ports/editors/libreoffice/work/libreoffice-core-3.5.7.2/workdir/
unxfbsdi.pro/CxxObject/i18npool/source/collator/gencoll_rule.o: In function
`sal_main_with_args(int, char**)':
gencoll_rule.cxx:(.text+0x3e5): undefined reference to
`icu_50::UnicodeString::UnicodeString(char16_t const*)'


In details, the source code of i18npool/source/collator/gencoll_rule.cxx
line that creates the problem is the 119:

RuleBasedCollator *coll = new RuleBasedCollator(reinterpret_castconst
UChar *(Obuf.getStr()), status);// UChar != sal_Unicode in MinGW

effectively, objdump confirm a problem with UnicodeString constructors. In
gencoll_rule.o the symbol is:

 *UND*   _ZN6icu_5013UnicodeStringC1EPKDs

but constructor symbols in /usr/local/lib/libicuuc.so.50.1 are:

00970d0 gDF .text  0085  Base
_ZN6icu_5013UnicodeStringC1EPKti
00092590 gDF .text  0079  Base
_ZN6icu_5013UnicodeStringC1EPKci
000971f0 gDF .text  0086  Base
_ZN6icu_5013UnicodeStringC1EPKt
00092790 gDF .text  0117  Base
_ZN6icu_5013UnicodeStringC1EPKciP10UConverterR10UErrorCode
00095d00 gDF .text  00e7  Base
_ZN6icu_5013UnicodeStringC1EPKciNS0_10EInvariantE
00092490 gDF .text  007d  Base
_ZN6icu_5013UnicodeStringC1EPKcS2_
00092390 gDF .text  0078  Base
_ZN6icu_5013UnicodeStringC1EPKciS2_
00092690 gDF .text  007e  Base
_ZN6icu_5013UnicodeStringC1EPKc

I've no idea how to fix it, it seems that at compile time the constructor
is recognized, but at link time it doesn't.

My system is STABLE-8 i386.

any suggestion to solve this issue?

Thanks in advance!
Best regards,
Luca
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: libreoffice 3.5.7_1 and icu-50.1

[Luca Pizzamiglio]

Hi,
thanks for the fast answer!!!

@Joseph,
Yes, I read the UPDATING file, but I guess the -w option is not a solution
in this case.
the -w option is a temporary fix to store the old library for compatibility
reasons with not yet recompiled packages.
AFAIK, the goal of bumping libreoffice PORTREVISION is to use the last
version of libraries, avoiding the usage of the previous library version.
Moreover, if I'm not wrong, the icu50 namespace is not present in the
previous icu48 library.

@bapt,
I get the same error.

Best regards,
Luca


On Thu, Dec 20, 2012 at 1:44 PM, Baptiste Daroussin b...@freebsd.orgwrote:

 On Thu, Dec 20, 2012 at 01:30:37PM +0100, Luca Pizzamiglio wrote:
  Hi,
 
  I've some trouble to compile libreoffice 3.5.7_1 after icu update to 50.1
  version
 
  the problem is located in i18npool module and the error is during the
 link
  phase:
 
  /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.7.2/workdir/
  unxfbsdi.pro/CxxObject/i18npool/source/collator/gencoll_rule.o: In
 function
  `sal_main_with_args(int, char**)':
  gencoll_rule.cxx:(.text+0x3e5): undefined reference to
  `icu_50::UnicodeString::UnicodeString(char16_t const*)'
 
 
  In details, the source code of i18npool/source/collator/gencoll_rule.cxx
  line that creates the problem is the 119:
 
  RuleBasedCollator *coll = new RuleBasedCollator(reinterpret_castconst
  UChar *(Obuf.getStr()), status);// UChar != sal_Unicode in MinGW
 
  effectively, objdump confirm a problem with UnicodeString constructors.
 In
  gencoll_rule.o the symbol is:
 
   *UND*   _ZN6icu_5013UnicodeStringC1EPKDs
 
  but constructor symbols in /usr/local/lib/libicuuc.so.50.1 are:
 
  00970d0 gDF .text  0085  Base
  _ZN6icu_5013UnicodeStringC1EPKti
  00092590 gDF .text  0079  Base
  _ZN6icu_5013UnicodeStringC1EPKci
  000971f0 gDF .text  0086  Base
  _ZN6icu_5013UnicodeStringC1EPKt
  00092790 gDF .text  0117  Base
  _ZN6icu_5013UnicodeStringC1EPKciP10UConverterR10UErrorCode
  00095d00 gDF .text  00e7  Base
  _ZN6icu_5013UnicodeStringC1EPKciNS0_10EInvariantE
  00092490 gDF .text  007d  Base
  _ZN6icu_5013UnicodeStringC1EPKcS2_
  00092390 gDF .text  0078  Base
  _ZN6icu_5013UnicodeStringC1EPKciS2_
  00092690 gDF .text  007e  Base
  _ZN6icu_5013UnicodeStringC1EPKc
 
  I've no idea how to fix it, it seems that at compile time the constructor
  is recognized, but at link time it doesn't.
 
  My system is STABLE-8 i386.
 
  any suggestion to solve this issue?
 
  Thanks in advance!
  Best regards,
  Luca
  ___
  freebsd-off...@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-office
  To unsubscribe, send any mail to freebsd-office-unsubscr...@freebsd.org
 

 Try building with WITH_GCC

 regards,
 Bapt

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: libreoffice 3.5.7_1 and icu-50.1

[Luca Pizzamiglio]

Thanks Bapt!

Best regards,
Luca


On Thu, Dec 20, 2012 at 2:31 PM, Baptiste Daroussin b...@freebsd.orgwrote:

 On Thu, Dec 20, 2012 at 02:20:22PM +0100, Luca Pizzamiglio wrote:
  Hi,
  thanks for the fast answer!!!
 
  @Joseph,
  Yes, I read the UPDATING file, but I guess the -w option is not a
 solution
  in this case.
  the -w option is a temporary fix to store the old library for
 compatibility
  reasons with not yet recompiled packages.
  AFAIK, the goal of bumping libreoffice PORTREVISION is to use the last
  version of libraries, avoiding the usage of the previous library version.
  Moreover, if I'm not wrong, the icu50 namespace is not present in the
  previous icu48 library.
 
  @bapt,
  I get the same error.
 

 I really fail at seeing where the issue comes from, I ll to come back soon
 with
 a fix, perhaps upgrading to libreoffice 3.6 would be the best solutiom.
 Don t
 know, sprry for the mess.

 Bapt

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: devel/gdb does not compile with gcc47+

[Luca Pizzamiglio]

Hi Jakub,
Are you using a customized make.conf?
Could you send it, please?

Best regards,
Luca


On 12/16/12 22:42, Jakub Lach wrote:
 Thread model: posix
 gcc version 4.7.3 20121208 (prerelease) (FreeBSD Ports Collection)
 configure:4043: $? = 0
 configure:4032: gcc47 -V 5
 gcc47: error: unrecognized command line option '-V'
 gcc47: fatal error: no input files
 compilation terminated.
 configure:4043: $? = 1
 configure:4032: gcc47 -qversion 5
 gcc47: error: unrecognized command line option '-qversion'
 gcc47: fatal error: no input files
 compilation terminated.
 configure:4043: $? = 1
 configure:4063: checking for C compiler default output file name
 configure:4085: gcc47 -O2 -pipe -march=native -DRL_NO_COMPAT
 -fno-strict-aliasing -I/usr/local/include  -L/us
 /usr/local/lib/libreadline.so: undefined reference to `tputs'
 /usr/local/lib/libreadline.so: undefined reference to `tgoto'
 /usr/local/lib/libreadline.so: undefined reference to `tgetflag'
 /usr/local/lib/libreadline.so: undefined reference to `UP'
 /usr/local/lib/libreadline.so: undefined reference to `tgetent'
 /usr/local/lib/libreadline.so: undefined reference to `tgetnum'
 /usr/local/lib/libreadline.so: undefined reference to `PC'
 /usr/local/lib/libreadline.so: undefined reference to `tgetstr'
 /usr/local/lib/libreadline.so: undefined reference to `BC'
 collect2: error: ld returned 1 exit status
 configure:4089: $? = 1
 configure:4126: result:
 configure: failed program was:
 | /* confdefs.h */
 | #define PACKAGE_NAME 
 | #define PACKAGE_TARNAME 
 | #define PACKAGE_VERSION 
 | #define PACKAGE_STRING 
 | #define PACKAGE_BUGREPORT 
 | #define PACKAGE_URL 
 | /* end confdefs.h.  */
 | 
 | int
 | main ()
 | {
 |
 |   ;
 |   return 0;
 | }
 configure:4132: error: in `/usr/obj/usr/ports/devel/gdb/work/gdb-7.5.1':
 configure:4136: error: C compiler cannot create executables
 See `config.log' for more details.
 
 
 
 
 --
 View this message in context: 
 http://freebsd.1045724.n5.nabble.com/devel-gdb-does-not-compile-with-gcc47-tp5769812.html
 Sent from the freebsd-ports mailing list archive at Nabble.com.
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
 

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: gdb75 dumps core on startup

[Luca Pizzamiglio]

I'm waiting someone commit this:

ports/171109

On Mon, Aug 27, 2012 at 4:44 PM, Andriy Gapon a...@freebsd.org wrote:
 on 27/08/2012 17:03 Andriy Gapon said the following:
 Program terminated with signal 11, Segmentation fault
 ...
 #0  0x004777e2 in i386_use_watchpoints ()
 #1  0x00476bbd in _initialize_amd64fbsd_nat ()
 #2  0x0060deea in initialize_all_files ()
 #3  0x005e710f in gdb_init ()
 #4  0x00549086 in relocate_gdb_directory ()
 #5  0x00547aa4 in catch_errors ()
 #6  0x00548bb4 in gdb_main ()
 #7  0x00457ea9 in main ()

 This is on amd64 head.


 The problem seems to be caused by files/patch-gdb-amd64-nat.h, which for some
 cryptic reason removes prototype of amd64bsd_target() from amd64-nat.h.  That
 allows the code to be compilable still (sloppy gdb developers!) but the 
 assumed
 return type of the function becomes int instead of a pointer which it really 
 is.
 Thus, the returned pointer value gets truncated on amd64 and as a result an
 invalid pointer is passed to i386_use_watchpoints() from 
 _initialize_amd64fbsd_nat().

 Oh, looking at the patch in PR ports/165357
 (http://www.freebsd.org/cgi/query-pr.cgi?pr=165357), it seems that
 amd64bsd_target() should have re-appeared in a new header file 
 amd64bsd-nat.h...
  But that part of the patch seems to be incorrect in that it would create
 files/amd64bsd-nat.h instead of a patch file to create amd64bsd-nat.h in the
 source directory.  Apparently this file never made it as a result.

 --
 Andriy Gapon
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: gdb75 dumps core on startup

[Luca Pizzamiglio]

Hi,
Hans : have you tried the patch included here ports/171109?
Andriy: thanks for the report, I create a patch for that as soon as I can!

Regards,
Luca

On Mon, Aug 27, 2012 at 4:59 PM, Hans Ottevanger h...@beastielabs.net wrote:
 On 08/27/12 16:03, Andriy Gapon wrote:

 Program terminated with signal 11, Segmentation fault
 ...
 #0  0x004777e2 in i386_use_watchpoints ()
 #1  0x00476bbd in _initialize_amd64fbsd_nat ()
 #2  0x0060deea in initialize_all_files ()
 #3  0x005e710f in gdb_init ()
 #4  0x00549086 in relocate_gdb_directory ()
 #5  0x00547aa4 in catch_errors ()
 #6  0x00548bb4 in gdb_main ()
 #7  0x00457ea9 in main ()

 This is on amd64 head.


 I can confirm that this happens on my not so recent 10-CURRENT (r239353),
 also amd64.

 I see a similar issue on 8.3-STABLE (r239646) on amd64:

 $ gdb75 ./a.out
 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
 Undefined symbol ps_pglobal_lookup]
 Segmentation fault: 11 (core dumped)

 while on i386 gcc75 works OK, but I see:

 $ gdb75 ./a.out
 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
 Undefined symbol ps_pglobal_lookup]
 GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD]
 Copyright (C) 2012 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as i386-portbld-freebsd8.3.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/...
 Reading symbols from /home/hans/a.out...done.
 (gdb)

 I do not know if the message about the undefined symbol is related to the
 issue at hand. The previous version (gcc741) did not show this message and
 functioned perfectly, also on amd64.

 Kind regards,

 Hans
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: gdb doesn't work well with qtcreator

[Luca Pizzamiglio]

Hi HU,
I tested QtCreator on a 8-STABLE i386 machine and a 9-STABLE amd64 machine.
In both cases I'm not able to reproduce the error

Regards,
Luca

On 08/14/12 02:29, HU Dong wrote:
 waiting for your furthur reply.
 
 B.R.
 HU Dong
 On Monday, August 13, 2012, Luca Pizzamiglio 
 l.pizzamig...@bally-wulff.de mailto:l.pizzamig...@bally-wulff.de wrote:
   Hi HU,
  
   I tried QtCreator 2.5.0 (Based on Qt 4.8.2 - 32 bit) on my 8-STABLE 
 i386 system.
  
   gdb works good (only one worning about inappropriate ioctl for 
 terminal device), but it works as expected.
  
   If I've time, I could try on a 9-STABLE system.
  
   Regards,
   Luca
  
   On 08/13/12 10:23, HU Dong wrote:
  
   On Mon, Aug 13, 2012 at 4:09 PM, Luca Pizzamiglio
   l.pizzamig...@bally-wulff.de mailto:l.pizzamig...@bally-wulff.de 
 mailto:l.pizzamig...@bally-wulff.de 
 mailto:l.pizzamig...@bally-wulff.de wrote:
  
   Hi.
   Could you provide a simple repro-case? Is your application a
   multi-thread one?
  
   I'm using gdb 7.4.1_4 with KDevelop without problem, but my
   applications are not Qt based...
  
   Regards,
   Luca
  
  
   On 08/09/12 14:02, HU Dong wrote:
  
   On Thu, Aug 9, 2012 at 7:55 PM, Konstantin Tokarev
   annu...@yandex.ru mailto:annu...@yandex.ru 
 mailto:annu...@yandex.ru mailto:annu...@yandex.ru wrote:
  
  
  
   09.08.2012, 15:50, HU Dong itechb...@gmail.com 
 mailto:itechb...@gmail.com
   mailto:itechb...@gmail.com mailto:itechb...@gmail.com:
  
   Hi,all!
 I just installed devel/qtcreator from port.
   Everything seemed to
   work fine except the debugger. At first I set it to
   /usr/bin/gdb, it
   simply crashed when I started debugging, with a dialog
   reporting The
   gdb process crashed. Then I installed devel/gdb and set
   the debugger
   to /usr/local/bin/gdb, qtcreator reported that
   Application process
   could not be stopped:The program is not being run. and
   Cannot
   continue debugged process:The program is not being run.
 I've spent much time searching on the internet,
   but found nothing
   helpful. Did anyone run into the same problem?
  
 Env: FreeBSD  9.0-RELEASE-p3 FreeBSD
   9.0-RELEASE-p3 #0: Tue Jun 12
   01:47:53 UTC 2012
   
 root@i386-builder.daemonology.__net:/usr/obj/usr/src/sys/__GENERIC
 i386
  
  
   Which version og gdb are you using? Qt Creator officially
   requires gdb = 7.2,
   and may have issues with earlier versions.
  
   Maybe it's worthwhile to ask on 
 qt-crea...@qt-project.org mailto:qt-crea...@qt-project.org
   mailto:qt-crea...@qt-project.org 
 mailto:qt-crea...@qt-project.org too.
  
   --
   Regards,
   Konstantin
  
  
   I've tested both gdb 6.1.1 and 7.4.1_4, but with no luck.
  
   I suspect that this problem is kind of freebsd-specific, cause I
   didn't find similar problems reported on the internet.
  
   HU Dong
   _
   freebsd-ports@freebsd.org mailto:freebsd-ports@freebsd.org 
 mailto:freebsd-ports@freebsd.org mailto:freebsd-ports@freebsd.org
   mailing list
   http://lists.freebsd.org/__mailman/listinfo/freebsd-ports
   http://lists.freebsd.org/mailman/listinfo/freebsd-ports
   To unsubscribe, send any mail to
   freebsd-ports-unsubscribe@__freebsd.org http://freebsd.org
   mailto:freebsd-ports-unsubscr...@freebsd.org 
 mailto:freebsd-ports-unsubscr...@freebsd.org
  
  
  
   It's not application-related. I tried hello,world! and the problem
   still existed. The problem happened in Qt Creator, not kdevelop. Anyway,
   thank you!
  
   B.R.
   HU Dong
  
  
 
 -- 
 祝好！  Best Regards,
 胡东  HU Dong
 清华大学电子系 Dept of EE, Tsinghua Univ
 137 5115 5701 +86 137 5115 5701
 

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: gdb doesn't work well with qtcreator

[Luca Pizzamiglio]

Hi.
Could you provide a simple repro-case? Is your application a 
multi-thread one?


I'm using gdb 7.4.1_4 with KDevelop without problem, but my applications 
are not Qt based...


Regards,
Luca

On 08/09/12 14:02, HU Dong wrote:

On Thu, Aug 9, 2012 at 7:55 PM, Konstantin Tokarev annu...@yandex.ru wrote:



09.08.2012, 15:50, HU Dong itechb...@gmail.com:

Hi,all!
 I just installed devel/qtcreator from port. Everything seemed to
work fine except the debugger. At first I set it to /usr/bin/gdb, it
simply crashed when I started debugging, with a dialog reporting The
gdb process crashed. Then I installed devel/gdb and set the debugger
to /usr/local/bin/gdb, qtcreator reported that Application process
could not be stopped:The program is not being run. and Cannot
continue debugged process:The program is not being run.
 I've spent much time searching on the internet, but found nothing
helpful. Did anyone run into the same problem?

 Env: FreeBSD  9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12
01:47:53 UTC 2012
r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386


Which version og gdb are you using? Qt Creator officially requires gdb = 7.2,
and may have issues with earlier versions.

Maybe it's worthwhile to ask on qt-crea...@qt-project.org too.

--
Regards,
Konstantin


I've tested both gdb 6.1.1 and 7.4.1_4, but with no luck.

I suspect that this problem is kind of freebsd-specific, cause I
didn't find similar problems reported on the internet.

HU Dong
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: gdb doesn't work well with qtcreator

[Luca Pizzamiglio]

Hi HU,

I tried QtCreator 2.5.0 (Based on Qt 4.8.2 - 32 bit) on my 8-STABLE i386 
system.


gdb works good (only one worning about inappropriate ioctl for terminal 
device), but it works as expected.


If I've time, I could try on a 9-STABLE system.

Regards,
Luca

On 08/13/12 10:23, HU Dong wrote:

On Mon, Aug 13, 2012 at 4:09 PM, Luca Pizzamiglio
l.pizzamig...@bally-wulff.de mailto:l.pizzamig...@bally-wulff.de wrote:

Hi.
Could you provide a simple repro-case? Is your application a
multi-thread one?

I'm using gdb 7.4.1_4 with KDevelop without problem, but my
applications are not Qt based...

Regards,
Luca


On 08/09/12 14:02, HU Dong wrote:

On Thu, Aug 9, 2012 at 7:55 PM, Konstantin Tokarev
annu...@yandex.ru mailto:annu...@yandex.ru wrote:



09.08.2012, 15:50, HU Dong itechb...@gmail.com
mailto:itechb...@gmail.com:

Hi,all!
  I just installed devel/qtcreator from port.
Everything seemed to
work fine except the debugger. At first I set it to
/usr/bin/gdb, it
simply crashed when I started debugging, with a dialog
reporting The
gdb process crashed. Then I installed devel/gdb and set
the debugger
to /usr/local/bin/gdb, qtcreator reported that
Application process
could not be stopped:The program is not being run. and
Cannot
continue debugged process:The program is not being run.
  I've spent much time searching on the internet,
but found nothing
helpful. Did anyone run into the same problem?

  Env: FreeBSD  9.0-RELEASE-p3 FreeBSD
9.0-RELEASE-p3 #0: Tue Jun 12
01:47:53 UTC 2012

root@i386-builder.daemonology.__net:/usr/obj/usr/src/sys/__GENERIC
  i386


Which version og gdb are you using? Qt Creator officially
requires gdb = 7.2,
and may have issues with earlier versions.

Maybe it's worthwhile to ask on qt-crea...@qt-project.org
mailto:qt-crea...@qt-project.org too.

--
Regards,
Konstantin


I've tested both gdb 6.1.1 and 7.4.1_4, but with no luck.

I suspect that this problem is kind of freebsd-specific, cause I
didn't find similar problems reported on the internet.

HU Dong
_
freebsd-ports@freebsd.org mailto:freebsd-ports@freebsd.org
mailing list
http://lists.freebsd.org/__mailman/listinfo/freebsd-ports
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
freebsd-ports-unsubscribe@__freebsd.org
mailto:freebsd-ports-unsubscr...@freebsd.org



It's not application-related. I tried hello,world! and the problem
still existed. The problem happened in Qt Creator, not kdevelop. Anyway,
thank you!

B.R.
HU Dong


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Firefox 14.0.1_1

[Luca Pizzamiglio]

The same here on FreeBSD 8-3 STABLE and KDE4.8.4.

with GTK everything works fine.

Luca

On 07/27/12 12:28, ajtiM wrote:

Hi!

I build Firefox 14.0.1_1 on FreeBSD Release 9.0 with QT4 option and it works
so bad on KDE 4.8.4. It is impossible to see what is in menus, you cannot
choose any option from menu
I will start rebuilding with GTK option.


Mitja

http://jpgmag.com/people/lumiwa
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: editors/libreoffice : patches for 8.3-STABLE (i386)

[Luca Pizzamiglio]

Hi,

yes, removing the offending 'case' was just a it compiles solution,
not the correct way to fix it.
Thanks for taking care of it

Best regards,
Luca

On Fri, Jul 6, 2012 at 12:14 PM, Alex Dupre a...@freebsd.org wrote:
 Luca Pizzamiglio ha scritto:
 I'm Luca and my system is a 8.3-STABLE system (then with clang derived
 from ports) on a i386 architecture.
 I had problem to build the latest libreoffice (3.5.4), so I tried to
 solve issues I met and I developed this easy patches.

 Are they acceptable? Are this problem known also on other 
 systems/architectures?

 They are partially correct (removing the offending 'case' is not
 correct). I have additional patches to also fix build with kde4 that are
 running on my tinderbox now. Talk to you later.

 --
 Alex Dupre
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

editors/libreoffice : patches for 8.3-STABLE (i386)

[Luca Pizzamiglio]

Hi all.

I'm Luca and my system is a 8.3-STABLE system (then with clang derived
from ports) on a i386 architecture.
I had problem to build the latest libreoffice (3.5.4), so I tried to
solve issues I met and I developed this easy patches.

Are they acceptable? Are this problem known also on other systems/architectures?

Best regards,
Luca Pizzamiglio

PS: please, include my email address on reply, I'm not (yet) using
this address on this mailing list ;)


patch-filter__source__graphicfilter__icgm__bitmap.cxx
Description: Binary data


patch-sd__source__filter__eppt__pptx-epptbase.cxx
Description: Binary data


patch-sd__source__filter__eppt__pptx-epptooxml.cxx
Description: Binary data
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: graphics/poppler-qt4: Installation error: /poppler-0.18.4/qt4/src', GEN poppler-optcontent.moc, not: not found, gmake[1]: *** [poppler-optcontent.moc] Error 127

[Luca Pizzamiglio]

The same problem here, on FreeBSD 8.2 and legacy GCC.
The problem arises on poppler-optcontent.moc.

Best regards,
Luca


gmake[3]: Leaving directory 
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/poppler'
gmake[2]: Leaving directory 
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/poppler'

Making all in test
gmake[2]: Entering directory 
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/test'

  CXXperf-test.o
  CXXperf-test-preview-dummy.o
  CXXLD  perf-test
  CXXpdf-fullrewrite.o
  CXXLD  pdf-fullrewrite
gmake[2]: Leaving directory 
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/test'

Making all in qt4
gmake[2]: Entering directory 
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/qt4'

Making all in src
gmake[3]: Entering directory 
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/qt4/src'

  GENpoppler-optcontent.moc
-i: not found
gmake[3]: *** [poppler-optcontent.moc] Error 127
gmake[3]: Leaving directory 
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/qt4/src'

gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory 
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/qt4'

gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory 
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4'

gmake: *** [all] Error 2


On 02/23/12 22:35, O. Hartmann wrote:

I found myself confronted with this error today. I happens on a FreeBSD
10.0/amd64 box, most recently built-world.

The error is persistent with CLANG and legacy GCC 4.2.1. The port is a
denepndency for several client applications I've installed on that box
and after the update today (poppler-qt4 seems to be installed before as
version 0.18.4 and got updated today to version 0.18.4_1), the port
isn't installed anymore!

The portmaintainersoftware is portmaster. Error follows below.

Any ideas?

Regards,
Oliver

clang++: warning: argument unused during compilation: '-fno-check-new'
   CXXlibpoppler_cpp_la-poppler-version.lo
clang++: warning: argument unused during compilation: '-fno-check-new'
   CXXLD  libpoppler-cpp.la
clang++: warning: argument unused during compilation: '-pthread'
clang++: warning: argument unused during compilation: '-pthread'
gmake[3]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp'
Making all in tests
gmake[3]: Entering directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp/tests'
   CXXparseargs.o
clang++: warning: argument unused during compilation: '-fno-check-new'
   CXXpoppler-dump.o
clang++: warning: argument unused during compilation: '-fno-check-new'
   CXXLD  poppler-dump
clang++: warning: argument unused during compilation: '-ansi'
   CXXpoppler-render.o
clang++: warning: argument unused during compilation: '-fno-check-new'
   CXXLD  poppler-render
clang++: warning: argument unused during compilation: '-ansi'
gmake[3]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp/tests'
gmake[2]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp'
gmake[2]: Entering directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4'
gmake[2]: Nothing to be done for `all-am'.
gmake[2]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4'
gmake[1]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4'
===   Installing for poppler-qt4-0.18.4
===Generating temporary packing list
Making install in src
gmake[1]: Entering directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/qt4/src'
   GENpoppler-optcontent.moc
not: not found
gmake[1]: *** [poppler-optcontent.moc] Error 127
gmake[1]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/qt4/src'
gmake: *** [install-recursive] Error 1
*** [do-install] Error code 2

Stop in /usr/ports/graphics/poppler-qt4.

===  Installation of poppler-qt4-0.18.4 (graphics/poppler-qt4) failed
===  Aborting update

Terminated

===  You can restart from the point of failure with this command line:
portmasterflags  graphics/poppler-qt4



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: graphics/poppler-qt4: Installation error: /poppler-0.18.4/qt4/src' GEN poppler-optcontent.moc, not: not found, gmake[1]: *** [poppler-optcontent.moc] Error 127

[Luca Pizzamiglio]

Hi Reiner,
unfortunately no x11-toolkits/qt33 here!

And there's something strange: I cannot build poppler-qt4 1.18.4.
but Oliver built it, the problem occurs during the install phase.
And I cannot see any 0.18.4_1 version, as Oliver reports...

Where am I wrong? any ideas?

thanks

Regards,
Luca


On 02/24/12 12:05, Rainer Hurling wrote:

Am 23.02.2012 22:35 (UTC+1) schrieb O. Hartmann:

I found myself confronted with this error today. I happens on a FreeBSD
10.0/amd64 box, most recently built-world.

The error is persistent with CLANG and legacy GCC 4.2.1. The port is a
denepndency for several client applications I've installed on that box
and after the update today (poppler-qt4 seems to be installed before as
version 0.18.4 and got updated today to version 0.18.4_1), the port
isn't installed anymore!

The portmaintainersoftware is portmaster. Error follows below.

Any ideas?


Deinstalling x11-toolkits/qt33, upgrading graphics/poppler-qt4 and after
that reinstalling x11-toolkits/qt33 works for me.

Hope this helps,
Rainer



Regards,
Oliver

clang++: warning: argument unused during compilation: '-fno-check-new'
CXX libpoppler_cpp_la-poppler-version.lo
clang++: warning: argument unused during compilation: '-fno-check-new'
CXXLD libpoppler-cpp.la
clang++: warning: argument unused during compilation: '-pthread'
clang++: warning: argument unused during compilation: '-pthread'
gmake[3]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp'
Making all in tests
gmake[3]: Entering directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp/tests'
CXX parseargs.o
clang++: warning: argument unused during compilation: '-fno-check-new'
CXX poppler-dump.o
clang++: warning: argument unused during compilation: '-fno-check-new'
CXXLD poppler-dump
clang++: warning: argument unused during compilation: '-ansi'
CXX poppler-render.o
clang++: warning: argument unused during compilation: '-fno-check-new'
CXXLD poppler-render
clang++: warning: argument unused during compilation: '-ansi'
gmake[3]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp/tests'
gmake[2]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp'
gmake[2]: Entering directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4'
gmake[2]: Nothing to be done for `all-am'.
gmake[2]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4'
gmake[1]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4'
=== Installing for poppler-qt4-0.18.4
=== Generating temporary packing list
Making install in src
gmake[1]: Entering directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/qt4/src'
GEN poppler-optcontent.moc
not: not found
gmake[1]: *** [poppler-optcontent.moc] Error 127
gmake[1]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/qt4/src'
gmake: *** [install-recursive] Error 1
*** [do-install] Error code 2

Stop in /usr/ports/graphics/poppler-qt4.

=== Installation of poppler-qt4-0.18.4 (graphics/poppler-qt4) failed
=== Aborting update

Terminated

=== You can restart from the point of failure with this command line:
portmasterflags graphics/poppler-qt4

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: graphics/poppler-qt4: Installation error: /poppler-0.18.4/qt4/src' GEN poppler-optcontent.moc, not: not found, gmake[1]: *** [poppler-optcontent.moc] Error 127

[Luca Pizzamiglio]

Problem fixed! thanks to solve ports/165438!

It was caused by qt3 conflict OR freebsd  9.0.

I had no qt3 package installed, qt4 only.
Compiled and updated. Thanks.

Best regards,
Luca



On 02/24/12 15:04, Rainer Hurling wrote:

On 24.02.2012 12:56 (UTC+1), Luca Pizzamiglio wrote:

Hi Reiner,
unfortunately no x11-toolkits/qt33 here!


Did you also looked for qt-copy-3.3.8_13? It was only a guess because it
helped me.


And there's something strange: I cannot build poppler-qt4 1.18.4.
but Oliver built it, the problem occurs during the install phase.
And I cannot see any 0.18.4_1 version, as Oliver reports...


My upgraded version is now poppler-qt4-0.18.4. I don't know about a
portrevision 1. Seems that Oliver has to explain this.


Where am I wrong? any ideas?

thanks

Regards,
Luca


On 02/24/12 12:05, Rainer Hurling wrote:

Am 23.02.2012 22:35 (UTC+1) schrieb O. Hartmann:

I found myself confronted with this error today. I happens on a FreeBSD
10.0/amd64 box, most recently built-world.

The error is persistent with CLANG and legacy GCC 4.2.1. The port is a
denepndency for several client applications I've installed on that box
and after the update today (poppler-qt4 seems to be installed before as
version 0.18.4 and got updated today to version 0.18.4_1), the port
isn't installed anymore!

The portmaintainersoftware is portmaster. Error follows below.

Any ideas?


Deinstalling x11-toolkits/qt33, upgrading graphics/poppler-qt4 and after
that reinstalling x11-toolkits/qt33 works for me.

Hope this helps,
Rainer



Regards,
Oliver

clang++: warning: argument unused during compilation: '-fno-check-new'
CXX libpoppler_cpp_la-poppler-version.lo
clang++: warning: argument unused during compilation: '-fno-check-new'
CXXLD libpoppler-cpp.la
clang++: warning: argument unused during compilation: '-pthread'
clang++: warning: argument unused during compilation: '-pthread'
gmake[3]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp'
Making all in tests
gmake[3]: Entering directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp/tests'
CXX parseargs.o
clang++: warning: argument unused during compilation: '-fno-check-new'
CXX poppler-dump.o
clang++: warning: argument unused during compilation: '-fno-check-new'
CXXLD poppler-dump
clang++: warning: argument unused during compilation: '-ansi'
CXX poppler-render.o
clang++: warning: argument unused during compilation: '-fno-check-new'
CXXLD poppler-render
clang++: warning: argument unused during compilation: '-ansi'
gmake[3]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp/tests'
gmake[2]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp'
gmake[2]: Entering directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4'
gmake[2]: Nothing to be done for `all-am'.
gmake[2]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4'
gmake[1]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4'
=== Installing for poppler-qt4-0.18.4
=== Generating temporary packing list
Making install in src
gmake[1]: Entering directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/qt4/src'
GEN poppler-optcontent.moc
not: not found
gmake[1]: *** [poppler-optcontent.moc] Error 127
gmake[1]: Leaving directory
`/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/qt4/src'
gmake: *** [install-recursive] Error 1
*** [do-install] Error code 2

Stop in /usr/ports/graphics/poppler-qt4.

=== Installation of poppler-qt4-0.18.4 (graphics/poppler-qt4) failed
=== Aborting update

Terminated

=== You can restart from the point of failure with this command
line:
portmasterflags graphics/poppler-qt4




___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [CFT] Xorg Upgrade 7.5.2

[Luca Pizzamiglio]

Running on:

* Intel Sandybridge (+ optimus, disabled) on FreeBSD 9.0
* NVidia GTS 450 on FreeBSD 8.2

Not unkwonw problem.
Usual problem on Intel Sandybridge (tty switch, KMS patch issues on 
FreeBSD 9 and optimus incompatibility (/dev/dri/card1)).


Tested with KDE 4.7.4 and desktop effect activated. Not all effect are 
available using openGL. AFAIK KDE 4.8 is able to use more OpenGL effects 
using the same library.


Thanks for the great job you've done!

Best regards,
Luca

On 02/06/12 02:45, Martin Wilke wrote:

Knock knock...

The X11 Team is pleased to announce the next round of Xorg updates.
Note that this is experimental so you really have to know what you are
doing, read UPDATING in the repository, and follow our exact
instructions. We are specifically looking for feedback from Intel, ATI
and NVIDIA users.

Summary of changes:

xf86-video-nouveau has been removed along with the WITHOUT_NOUVEAU
knob. We suggest switching to the nvidia blob.

KMS Support [1]:
Unfortunately, the intel KMS driver will only work for the latest
FreeBSD 9-STABLE or 10-CURRENT users. The patch for HEAD current is
named all.13.1.patch. The higher the version the newer the patch is.
Other needed patches are already available in the Xorg update.

HEAD Users:
Get the latest patchset from Kib here:
http://people.freebsd.org/~kib/drm/

9-STABLE Users:
'meowthink' is currently maintaining the backport to 9 STABLE.
Make sure you have the latest FreeBSD 9-STABLE source.
Get the patch from here:
https://docs.google.com/leaf?id=0BxbPi2OX4_B-NWY3NWU3MzEtNDBjYy00NTljLThlZGItMWFlYjIyYjI4Yjk3hl=en_US

Rebuild your Kernel and reboot.

Known issuse:
There will be a patch reject in the sys/dev/drm/i915_suspend.c file.
The solution is to manually undo the expansion of the $FreeBSD: $
tag, so it only saysis $FreeBSD$.

Checkout Xorg Development Repo:
You will need to install devel/subversion in order to checkout the xorg
repo. Next, you will need to add WITH_NEW_XORG=yes in
your /etc/make.conf if you want to try out the new Xorg and mesa.

Intel users: note that if you are not qualified for the KMS patch, you
shouldn't use WITH_NEW_XORG=yes because the old intel driver doesn't
build with the new X server. If you are qualified, you should also set
WITH_KMS=yes in /etc/make.conf.

svn co https://trillian.chruetertee.ch/svn/ports/tags/xorg_7_5_2

A small merge script to merge the svn checkout into the real portstree
can be found here:

http://people.freebsd.org/~miwi/xorg/xorgmerge

The script is a modified version of the old kdemerge script. Please set
the KDEDIR variable to the path of your X.org ports.

After merging, run one of the following command, depending on which
tool you use to manage your installed packages.

 portupgrade -af \*
 portmaster -a

After installing these, you will have to rebuild all xf86-* ports. We
will bump all related ports during the commit to the ports tree.

Roadmap:

Our current plan is to let the CFT running until the last weekend of
February. We hope to get a lot feedback to solve as many problems as
possible. So please help us to get the best xorg update ever in!


Links:
http://wiki.freebsd.org/Intel_GPU [1]
http://wiki.freebsd.org/Xorg
http://miwi.bsdcrew.de/2012/02/working-on-xorg-stuff/

Your FreeBSD Xorg Team

PS: Please reply to the x11@ mailing list. Cross posted due to the
potentially disruptive nature of the change and need to get a wide
variety of testers.



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

[Request for Comments] Add a AFFECT relationship between ports

[Luca Pizzamiglio]

Hi people,

I would like to propose a new feature/ports relationship/variable 
on ports management.

We could call this feature AFFECT and it exports a kind of dependency.

I'd explain the behavior with an example: nvidia-driver port.
During the installation process, this port moves the official Xorg
openGL installing the NVidia ones.
Removing nvidia-driver port, the old official libraries are restored.

libGL port  C. ignore this kind of stuff and if you update them with 
the nvidia-driver port installed, you overwrite the Nvidia libraries and 
the restore procedure (of the nvidia-driver) restores the not-updated 
official Xorg libraries.


This kind of relationship is not a CONFLICT or a DEPEND, it's something
different. nvidia-driver AFFECT graphics/libGL, but graphics/libGL must
ignore the presence of nvidia-driver.

The AFFECT should state: libGL is affected by nvidia-driver, then the
update procedure is:
* deinstall nvidia-driver
* update libGL
* reinstall nvidia-driver

Comments  ideas are really welcome!
If you agree, we could start implementationtest of this feature.

Best regards,

Luca
Conrad



On 08/23/11 11:38, Conrad J. Sabatier wrote:

On Tue, 23 Aug 2011 10:53:48 +0200
Luca Pizzamigliol.pizzamig...@bally-wulff.de  wrote:


On 08/23/11 10:35, Conrad J. Sabatier wrote:

On Tue, 23 Aug 2011 10:08:22 +0200
Luca Pizzamigliol.pizzamig...@bally-wulff.de   wrote:


There is no conflict:
you need to install openGL before and then nvidia Driver.
the nvidia driver install procedure renames the original library
and install the nvidia version one (look at /usr/local/lib and
/usr/local/lib/xorg/modules/extensions, there are XXX-lib* old
library) both libraries has the same API, but the nvidia one uses
some legacy stuffs on the nvidia kernel driver.


Yes, of course, it works fine *if* you make sure to install libGL
first.  The thing that concerns me is if at some point, say, during
a forced portupgrade, the libGL port may overwrite the nvidia
library once again.

It just seems that there should be something in place to prevent
this from happening.

Tschüß!  :-)



Yes, you're right. If you update openGL library later, NVidia driver
installation is brocken.


Yes, I've already been bitten by this at least once.


The right procedure should be:
deinstall nvidia driver
upgrade openGL libraries
reinstall nvidia driver

This is a kind of half-conflict: openGL library conflicts with
nvidia driver, but nvidia driver doesn't.
Or: nvidia-driver installation should block openGL library upgrade.
Or: nvidia-driver should be deinstalled before and reinstalled after.

This is a more general problem, ports infrastructure doesn't model
this kind of dependencies/conflicts.

I don't think openGL library maintainer wanna manage others ports
that breaks its libraries...

We should propose to add to the ports infrastructure this kind of
relationship (AFFECTS could be a name) and its management...


That would be an interesting proposal to put forth.  Not sure how warm
of a reception it will be met with, though.  :-)

Do we need to map out some sort of formal proposal, including a
possible implementation, or just toss the idea out for discussion?
What do you think?


Ciao! (I live in Germany, but I'm still Italian :-)


Ah, OK.  :-)  Well, in that case...Ciao to you, too!  :-)



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [Request for Comments] Add a AFFECT relationship between ports

[Luca Pizzamiglio]

On 08/24/11 10:27, Matthew Seaman wrote:

On 24/08/2011 08:02, Luca Pizzamiglio wrote:

I'd explain the behavior with an example: nvidia-driver port.
During the installation process, this port moves the official Xorg
openGL installing the NVidia ones.
Removing nvidia-driver port, the old official libraries are restored.


nvidia-driver is pretty much a special case in the ports.  I think it
(and its slave ports) are the only ports that do anything like that.

Your idea is interesting however.  Do you have any other examples where
this would apply?

Cheers,

Matthew



Hi Matthew,
at the moment I have no other examples.

nvidia-driver is a special case, I know. I guess that some other ports 
could have the same behavior, but maintainers choose the CONFLICT 
relationship to solve this issue.
It's possible to have devel ports or patched version of some ports that 
don't conflict with the original one, but just AFFECT them...


Best regards,
Luca
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: vigra 1.7.1

[Luca Pizzamiglio]

you still have the wrong hdf5 library installed.
=== The dependency for science/hdf5-18
   seems to be handled by hdf5-1.6.9_1

remove hdf5-1.6.9_1 with pkd_delete and restart portmaster graphic/vigra

Bye

On 06/30/11 14:13, Gritsuk Anton wrote:

It's not work for me. Why?

See the attach file.


On 30.06.2011 15:02, Vasil Dimov wrote:

Hi,

I fixed this in
http://lists.freebsd.org/pipermail/cvs-ports/2011-June/220020.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/158425






___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: GMP change

[Luca Pizzamiglio]

Hi Denny,

your trick works! Thanks, but I think is not the best solution for all 
cases... If there are more conflicting ports, disabling the check is not 
a good idea...


Best regards

Luca

On 04/22/2010 12:10, Denny Lin wrote:

On Thu, Apr 22, 2010 at 11:36:17AM +0200, Luca Pizzamiglio wrote:

Hallo Andrea,

I've had the same problem using portupgrade and no clean solution found.

This is the dirty trick I've used:

pkg_delete -f libgmp4\*
portupgrade -N math/gmp

BTW, portupgrade with -o doesn't work because now the conflicts is
checked before the building process and gmp building fails..


See if this works:
# env DISABLE_CONFLICTS=1 portmaster -o math/gmp math/libgmp4



--
Mit herzlichen Grüßen,

Luca Pizzamiglio
Systementwicklung

BALLY WULFF Entertainment GmbH
Maybachufer 48-51
12045 Berlin
Phone:  +49(30)62002 149
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org