=2305843009213693952) at vector.tcc:72
> #9 0x104749bc in cmsys::hashtable cmDefinitions::Def>, std::string, cmsys::hash,
> cmsys::hash_select1st,
> std::equal_to, std::allocator >::_M_initialize_buckets
> (this=0xffffb100, __n=100) at hashtable.hxx:797
> #10 0x1047
Definitions::Def>, std::string, cmsys::hash,
> cmsys::hash_select1st,
> std::equal_to, std::allocator >::_M_initialize_buckets
> (this=0xb100, __n=100) at hashtable.hxx:797
> #10 0x10474ae4 in hashtable (this=0xb100, __n=100,
> __hf=@0x
,
> cmsys::hash_select1st,
> std::equal_to, std::allocator >::_M_initialize_buckets
> (this=0xb100, __n=100) at hashtable.hxx:797
> #10 0x10474ae4 in hashtable (this=0xffffb100, __n=100,
> __hf=@0xaeb2, __eql=@0xaeb1, __a=@0xfff
(this=0x51c3f480, gg=0xc138) at
> /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGenerator.cxx:244
> #15 0x101874b0 in cmGlobalGenerator::CreateLocalGenerator
> (this=0xc138) at
> /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-
r/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalGenerator.cxx:1906
#16 0x100224dc in cmCTest::Initialize (this=0xffffcf50,
binary_dir=0x51c890f8
"/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", command=0x0)
at
/usr/obj/port
fffcf50,
binary_dir=0x51c890f8
"/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", command=0x0)
at
/usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.cxx:511
#17 0x1002c704 in cmCTest::Run (this=0xcf50,
args=@0xcb80,
On 2014-10-31 15:33, Beeblebrox wrote:
graphics/png has been failing like this for some time, and I would go
around
the problem by fetching the newer binary then re-starting poudriere.
That
trick did not work this time, so now I'm stuck.
Same error when building on host (non-poudriere).
graphics/png has been failing like this for some time, and I would go around
the problem by fetching the newer binary then re-starting poudriere. That
trick did not work this time, so now I'm stuck.
Same error when building on host (non-poudriere). Port used to compile on
host, but no l
On Sun, Apr 28, 2013 at 1:42 AM, Thomas Mueller
wrote:
> from Chris Rees:
>
>> What new features are you trying to take advantage of with png?
>
> I went to the libpng website and couldn't find the desired changelog, but
> found libpng 1.4.x and 1.5.x were still in active development, and there w
from Chris Rees:
> What new features are you trying to take advantage of with png?
I went to the libpng website and couldn't find the desired changelog, but found
libpng 1.4.x and 1.5.x were still in active development, and there was also a
beta 1.7.0 . 1.6.2 is the latest release.
I notice t
On 26 Apr 2013 13:05, "Thomas Mueller" wrote:
>
> from Dirk Meyer:
>
> > Hallo Thomas Mueller,
>
> > > What is the status of graphics/png, now that FreeBSD 8.4_RC2 has been
released and the ports tree has been unfrozen?
> >
> > > Will it get t
from Dirk Meyer:
> Hallo Thomas Mueller,
> > What is the status of graphics/png, now that FreeBSD 8.4_RC2 has been
> > released and the ports tree has been unfrozen?
>
> > Will it get the long overdue update to 1.6.x; how much regression testing
> > need
What is the status of graphics/png, now that FreeBSD 8.4_RC2 has been released
and the ports tree has been unfrozen?
Will it get the long overdue update to 1.6.x; how much regression testing needs
to be done?
Tom
___
freebsd-ports@freebsd.org
What is the status of graphics/png?
I noticed NetBSD pkgsrc was prompt in updating to 1.6 (or was it 1.6.0?), even
though they are behind in some other packages.
I'm concerned with the prospect of having to rebuild all ports that depend on
png when 1.5.x -> 1.6.
> The status is
On 02/22/13 12:22, Thomas Mueller wrote:
What is the status of graphics/png?
I noticed NetBSD pkgsrc was prompt in updating to 1.6 (or was it 1.6.0?), even
though they are behind in some other packages.
I'm concerned with the prospect of having to rebuild all ports that depend on png
What is the status of graphics/png?
I noticed NetBSD pkgsrc was prompt in updating to 1.6 (or was it 1.6.0?), even
though they are behind in some other packages.
I'm concerned with the prospect of having to rebuild all ports that depend on
png when 1.5.x -> 1.6
Hi!
> > > I didn't realize the FreeBSD ports people would be so cautious with png.
>
> > [5810 eitan@radar ~ ]%grep png-1.5 -c /usr/ports/INDEX-10
> > 6036
>
> > might help explain why. :)
>
>
> > Eitan Adler
>
> I don't have INDEX-10, but ran
> grep png-1.5 -c /BETA1/usr/ports/INDEX-9
> and
> > I didn't realize the FreeBSD ports people would be so cautious with png.
> [5810 eitan@radar ~ ]%grep png-1.5 -c /usr/ports/INDEX-10
> 6036
> might help explain why. :)
> Eitan Adler
I don't have INDEX-10, but ran
grep png-1.5 -c /BETA1/usr/ports/INDEX-9
and got 6032.
Does that mean so m
On 15 October 2012 05:45, Thomas Mueller wrote:
>> On Sun, Oct 14, 2012 at 3:07 AM, Thomas Mueller
>> wrote:
>> > From my original post:
>
>> >> I think graphics/png is at 1.5.12 in FreeBSD ports but 1.5.13?
>
>> >> Does anybody know
> On Sun, Oct 14, 2012 at 3:07 AM, Thomas Mueller
> wrote:
> > From my original post:
> >> I think graphics/png is at 1.5.12 in FreeBSD ports but 1.5.13?
> >> Does anybody know when 1.5.13 will appear or if there is a particular snag?
> > Niclas Zeising
On Sun, Oct 14, 2012 at 3:07 AM, Thomas Mueller wrote:
> From my original post:
>
>> I think graphics/png is at 1.5.12 in FreeBSD ports but 1.5.13?
>
>> Does anybody know when 1.5.13 will appear or if there is a particular snag?
>
> Niclas Zeising responded:
>
>&
>From my original post:
> I think graphics/png is at 1.5.12 in FreeBSD ports but 1.5.13?
> Does anybody know when 1.5.13 will appear or if there is a particular snag?
Niclas Zeising responded:
> Since we are in a feature freeze, and graphics/png is the dependency of
> a lot of
On 2012-10-13 10:37, Thomas Mueller wrote:
> I think graphics/png is at 1.5.12 in FreeBSD ports but 1.5.13?
>
> Does anybody know when 1.5.13 will appear or if there is a particular snag?
>
> Tom
Since we are in a feature freeze, and graphics/png is the dependency of
a lot of
I think graphics/png is at 1.5.12 in FreeBSD ports but 1.5.13?
Does anybody know when 1.5.13 will appear or if there is a particular snag?
Tom
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To
gt; -- Up-to-date: /usr/local/bin/libpng15-config
> > -- Up-to-date: /usr/local/lib/libpng/libpng15.cmake
> > -- Up-to-date: /usr/local/lib/libpng/libpng15-debug.cmake
> > install -o root -g wheel -m 444
> > /usr/ports/graphics/png/work/libpng-1.5.10/pngdebug.h
> &g
Up-to-date: /usr/local/lib/libpng/libpng15.cmake
> -- Up-to-date: /usr/local/lib/libpng/libpng15-debug.cmake
> install -o root -g wheel -m 444
> /usr/ports/graphics/png/work/libpng-1.5.10/pngdebug.h
> /usr/ports/graphics/png/work/libpng-1.5.10/pnginfo.h
> /usr/ports/graphics/png/wor
date: /usr/local/bin/libpng-config
-- Up-to-date: /usr/local/libdata/pkgconfig/libpng15.pc
-- Up-to-date: /usr/local/bin/libpng15-config
-- Up-to-date: /usr/local/lib/libpng/libpng15.cmake
-- Up-to-date: /usr/local/lib/libpng/libpng15-debug.cmake
install -o root -g wheel -m 444
/usr/ports/graphic
on 26/04/2012 11:55 Andriy Gapon said the following:
> on 07/03/2012 18:19 Andriy Gapon said the following:
>> on 07/03/2012 14:11 b. f. said the following:
>>> you can just
>>> install lang/gcc or lang/gcc46 and set USE_GCC=4.6 in your build
>>> environment, an included Makefile, or on the command
on 07/03/2012 18:19 Andriy Gapon said the following:
> on 07/03/2012 14:11 b. f. said the following:
>> you can just
>> install lang/gcc or lang/gcc46 and set USE_GCC=4.6 in your build
>> environment, an included Makefile, or on the command line
And an additional problem with this recommendation i
ect the toolchain-related variables, you can just
>>>> install lang/gcc or lang/gcc46 and set USE_GCC=4.6 in your build
>>>> environment, an included Makefile, or on the command line. I have been
>>>> building graphics/png in this way for years. You can and sho
lang/gcc46 and set USE_GCC=4.6 in your build
>>> environment, an included Makefile, or on the command line. I have been
>>> building graphics/png in this way for years. You can and should
>>> dispense with the libmap.conf additions, the hardcoded CC, CXX, and
>>> CPP in
Error code 1
> >
> > Stop in /usr/ports/graphics/png.
> > *** Error code 1
> >
> > Stop in /usr/ports/graphics/png.
> > vmboX#
>
> Are you adding -fstack-protector to your CFLAGS?
>
> b.
>
I dont have any special CFLAGS variables -- empty make.conf,
the recommended way to use lang/gcc* for
>> ports. For all but a handful of ports that lang/gcc* depends upon, or
>> those that don't respect the toolchain-related variables, you can just
>> install lang/gcc or lang/gcc46 and set USE_GCC=4.6 in your build
>> environm
On 3/8/12, Mark Linimon wrote:
> On Wed, Mar 07, 2012 at 12:11:52PM +, b. f. wrote:
>> The custom gcc article that you are attempting to use was written at
>> a time when some of the related port Makefiles had some shortcomings
>> that no longer exist, and is not the recommended way to use lan
On Wed, Mar 07, 2012 at 12:11:52PM +, b. f. wrote:
> The custom gcc article that you are attempting to use was written at
> a time when some of the related port Makefiles had some shortcomings
> that no longer exist, and is not the recommended way to use lang/gcc*
> for ports.
Would you be int
On Wed, Mar 07, 2012 at 06:19:51PM +0200, Andriy Gapon wrote:
> BTW, our traditional taxonomy seems to be: "USE_XXX" is for stuff that ports
> really require, "WITH_XXX" is for user preferences.
This isn't a taxonomy suggestion, it's a documented requirement:
http://www.freebsd.org/doc/en_US.ISO8
On 3/7/12, Andriy Gapon wrote:
> on 07/03/2012 14:11 b. f. said the following:
>> you can just
>> install lang/gcc or lang/gcc46 and set USE_GCC=4.6 in your build
>> environment, an included Makefile, or on the command line
>
> BTW, our traditional taxonomy seems to be: "USE_XXX" is for stuff that
on 07/03/2012 14:11 b. f. said the following:
> you can just
> install lang/gcc or lang/gcc46 and set USE_GCC=4.6 in your build
> environment, an included Makefile, or on the command line
BTW, our traditional taxonomy seems to be: "USE_XXX" is for stuff that ports
really require, "WITH_XXX" is for
> Adding dinoex (Maintainer of graphics/png).
>
> On Mon, Feb 27, 2012 at 9:51 PM, Gautam wrote:
>
> >
> >
> >> Still didnt work for me -- did another buildworld and retried to check if
> > there was something else messed up.
> >
> > I am moving
Hi,
Adding dinoex (Maintainer of graphics/png).
On Mon, Feb 27, 2012 at 9:51 PM, Gautam wrote:
>
>
>> Still didnt work for me -- did another buildworld and retried to check if
> there was something else messed up.
>
> I am moving back to base gcc for now. Waiting
Hi,
On Sun, Feb 26, 2012 at 1:43 AM, Jakub Lach wrote:
> To be precise, I'm user of lang/gcc46, but since long before lang/gcc
> creation, so it shouldn't really matter.
>
>
Still didnt work for me -- did another buildworld and retried to check if
there was something else messed up.
I am moving
To be precise, I'm user of lang/gcc46, but since long before lang/gcc
creation, so it shouldn't really matter.
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/graphics-png-does-not-build-with-lang-gcc-tp5495065p5515762.html
Sent from the freebsd-ports mailing li
/etc/libmap.conf
libgcc_s.so.1 gcc46/libgcc_s.so.1
libgomp.so.1gcc46/libgomp.so.1
libssp.so.0 gcc46/libssp.so.0
libstdc++.so.6 gcc46/libstdc++.so.6
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/graphics-png-does-not-build-with-lang-gcc-tp5495065p5515746.html
I don't think so. Maybe it's P4 specific.
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/graphics-png-does-not-build-with-lang-gcc-tp5495065p5515744.html
Sent from the freebsd-ports mailing list archive at Nabble.com.
_
Hi,
On Wed, Feb 22, 2012 at 10:10 PM, Jakub Lach wrote:
> make.conf:
>
> .if !empty(.CURDIR:M/usr/ports/*)
> WRKDIRPREFIX= /usr/obj
> .include "/etc/ports.conf"
> .endif
>
> ports.conf:
>
> CC=gcc46
> CXX=g++46
> CFLAGS=-O2 -pipe -march=native
> CXXFLAGS=${CFLAGS}
>
> No such problem here.
>
Th
make.conf:
.if !empty(.CURDIR:M/usr/ports/*)
WRKDIRPREFIX= /usr/obj
.include "/etc/ports.conf"
.endif
ports.conf:
CC=gcc46
CXX=g++46
CFLAGS=-O2 -pipe -march=native
CXXFLAGS=${CFLAGS}
No such problem here.
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/gr
c46/libgcc_s.so.1
> libgomp.so.1gcc46/libgomp.so.1
> libobjc.so.3gcc46/libobjc.so.2
> libssp.so.0 gcc46/libssp.so.0
> libstdc++.so.6 gcc46/libstdc++.so.6
>
>
> When I tried to rebuild some ports, I found a problem with linking
> graphics/png.
>
> I found a simil
'
pngrutil.So:pngrutil.c:(.text+0x19d9): more undefined references to
`__stack_chk_fail_local' follow
collect2: ld returned 1 exit status
*** Error code 1
gcc46 -O2 -pipe -march=pentium4 -fno-strict-aliasing -march=pentium4 -I.
-std=gnu99 -fstack-protector -L. -static -o pngtest pn
On 25.05.2011 17:37, Andrey Chernov wrote:
If only FF wants hacked library, there is no point to make even
separated port.
Certainly thunderbird too. Not sure about others, but, likely, www/libxul too --
and www/seamonkey2. Worse: we tend to have multiple versions of some of those in
the tree (
If only FF wants hacked library, there is no point to make even
separated port. Making APNG default is an additional security risk since
another vulnerability may be founded in the APNG extension in the future
will affect all programs at once, i.e. we'll have png risk + apng risk as
result. Mor
On 25.05.2011 15:02, Andrey Chernov wrote:
There used to be concerns about security of animated PNG code, but today I can
> not find any advisories fresher than 2008:
>
> http://osvdb.org/show/osvdb/48766
Wrong place to find advisores related to subj. See
http://www.libpng.org/pub/png/l
On Wed, May 25, 2011 at 02:28:20PM -0400, Mikhail T. wrote:
> I'd like to see this option on by default now. I think, it's been available
> (off
> by default) long enough and I, for one, always turn it on for completeness.
> There used to be concerns about security of animated PNG code, but toda
I'd like to see this option on by default now. I think, it's been available (off
by default) long enough and I, for one, always turn it on for completeness.
There used to be concerns about security of animated PNG code, but today I can
not find any advisories fresher than 2008:
http://osvdb
On 7/11/10, Anonymous wrote:
> "b. f." writes:
...
> Did you miss ports/148196? ld(1) ignores libmap.conf and will try to
I did miss it, but it doesn't really surprise me. I've only seen
discussion of libmap.conf(5) with reference to rtld(1), and AFAIK
ld(1) doesn't directly invoke rtld to fin
"b. f." writes:
[...]
> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/configuring-ports-gcc.html
>
> Despite claims of 100% backwards-compatibility for these libraries,
> this remapping will have some consequences,
Did you miss ports/148196? ld(1) ignores libmap.conf and will tr
> Anonymous writes:
>
> > Doug Barton writes:
> >
> >> readelf -s /lib/libc.so.7 | fgrep __stack_chk_fail
> >>952: 0002806026 FUNCGLOBAL DEFAULT 10
> >> __stack_chk_fail@@FBSD_1.0
> >> 1457: 0002806026 FUNCGLOBAL DEFAULT 10 __stack_chk_fail_local
> >> at FBSD_1.0
> >
>
Anonymous writes:
> Doug Barton writes:
>
>> readelf -s /lib/libc.so.7 | fgrep __stack_chk_fail
>>952: 0002806026 FUNCGLOBAL DEFAULT 10 __stack_chk_fail@@FBSD_1.0
>> 1457: 0002806026 FUNCGLOBAL DEFAULT 10
>> __stack_chk_fail_lo...@fbsd_1.0
>
>> 45: 000ecec029 F
Doug Barton writes:
> readelf -s /lib/libc.so.7 | fgrep __stack_chk_fail
>952: 0002806026 FUNCGLOBAL DEFAULT 10 __stack_chk_fail@@FBSD_1.0
> 1457: 0002806026 FUNCGLOBAL DEFAULT 10
> __stack_chk_fail_lo...@fbsd_1.0
> 45: 000ecec029 FUNCLOCAL HIDDEN10 __
On Wed, 30 Jun 2010, Anonymous wrote:
Doug Barton writes:
nm libssp.so.0 | grep __stack_chk_fail_local
0ac0 t __stack_chk_fail_local
I'm not sure what FreeBSD version you're using
-current, and I update just about every day. I tried upgrading -current
with a clean /usr/obj today (r20
Doug Barton writes:
> nm libssp.so.0 | grep __stack_chk_fail_local
> 0ac0 t __stack_chk_fail_local
>
> So I'm at a loss, and pretty close to throwing in the towel and going
> back to the base gcc for everything.
I'm not sure what FreeBSD version you're using but I have
__stack_chk_fail_local
On Tue, 29 Jun 2010, Doug Barton wrote:
One more question. Is your gcc compiled with the LTO option?
(/var/db/ports/gcc*/options will tell you.) I had that enabled (it's off by
default) so I'm going to try recompiling gcc without it and see if it helps.
Never mind, compiling without the LTO o
On Tue, 29 Jun 2010, Doug Barton wrote:
On 06/29/10 19:27, Anonymous wrote:
Doug Barton writes:
Tried doing the update today, but it failed:
Full log at http://people.freebsd.org/~dougb/png-gcc451.log
Visibility and binding for that symbol are same here whether using
gcc45 or basegcc.
Yo
On 06/29/10 19:27, Anonymous wrote:
> Doug Barton writes:
>
>> Tried doing the update today, but it failed:
>>
>> Full log at http://people.freebsd.org/~dougb/png-gcc451.log
>
> Visibility and binding for that symbol are same here whether using
> gcc45 or basegcc.
>
> You can try to build with
-g -g -I. -g -std=gnu99
> -fstack-protector -L. -static -o pngtest pngtest.o -lpng -lz -lm
> pngread.So: In function `png_create_read_struct_2':
> /usr/local/tmp/usr/local/ports/graphics/png/work/libpng-1.4.3/pngread.c:201:
> undefined reference to `__stack_chk_fail_local'
>
pngtest pngtest.o -lpng -lz -lm
pngread.So: In function `png_create_read_struct_2':
/usr/local/tmp/usr/local/ports/graphics/png/work/libpng-1.4.3/pngread.c:201:
undefined reference to `__stack_chk_fail_local'
pngrutil.So: In function `png_read_chunk_header':
/usr/local/tmp/usr/local/por
On Sun, Jun 13, 2010 at 2:50 PM, Torfinn Ingolfsen wrote:
> I am trying to install the graphics/png port on my PowerMac G4, which runs
> 8.1-beta1:
> r...@kg-g4# uname -a
> FreeBSD kg-g4.kg4.no 8.1-BETA1 FreeBSD 8.1-BETA1 #0: Fri May 28 04:38:56 UTC
> 2010 r...@xserve.lan.xcll
I am trying to install the graphics/png port on my PowerMac G4, which runs
8.1-beta1:
r...@kg-g4# uname -a
FreeBSD kg-g4.kg4.no 8.1-BETA1 FreeBSD 8.1-BETA1 #0: Fri May 28 04:38:56 UTC
2010 r...@xserve.lan.xcllnt.net:/usr/obj/usr/src/sys/GENERIC powerpc
r...@kg-g4# cd /usr/ports/graphics/png
r
On 03/28/10 07:09, ajtiM wrote:
> What I am doing wrong, please?
Nothing, the mistake is mine. The docs say that 'portmaster -r' accepts
a glob pattern, but that's not accurate. I will work on fixing that bug
asap, but meanwhile you can do this:
portmaster -r `echo /var/db/pkg/png-1* | sed s#.*/
>> No valid installed port, or port directory given
> > > ===>>> Try portmaster --help
> > >
> > > If I use portmaster -r /usr/ports/graphics/png-
> > >
> > > ===>>> No valid installed port, or port directory given
> > >
er --help
> >
> > If I use portmaster -r /usr/ports/graphics/png-
> >
> > ===>>> No valid installed port, or port directory given
> > ===>>> Try portmaster --help
> >
> > What I am doing wrong, please?
> >
> > Mitja
>
> Get
On 03/28/10 09:09, ajtiM wrote:
> Thank you but if I use:
> portmaster -r png-
> I got ===>>> No valid installed port, or port directory given
> ===>>> Try portmaster --help
>
> If I use portmaster -r /usr/ports/graphics/png-
>
> ===>>&g
On Sunday 28 March 2010 08:45:32 Erik Trulsson wrote:
> On Sun, Mar 28, 2010 at 07:47:36AM -0500, ajtiM wrote:
> > In the /usr/ports/UPDATING is:
> >
> > "20090328:
> > AFFECTS: users of graphics/png
> > AUTHOR: din...@freebsd.org
> >
> >
On Sun, Mar 28, 2010 at 07:47:36AM -0500, ajtiM wrote:
> In the /usr/ports/UPDATING is:
>
> "20090328:
> AFFECTS: users of graphics/png
> AUTHOR: din...@freebsd.org
>
> The png library has been updated to version 1.4.1. Please rebuild all
> ports that de
In the /usr/ports/UPDATING is:
"20090328:
AFFECTS: users of graphics/png
AUTHOR: din...@freebsd.org
The png library has been updated to version 1.4.1. Please rebuild all
ports that depend on it.
If you use portmaster:
portmaster -r jpeg-
If you use portup
Andrey Chernov wrote:
On Tue, Apr 07, 2009 at 05:16:38PM -0400, Philip M. Gollucci wrote:
Ion-Mihai Tetcu wrote:
Pass me the full log please.
http://people.freebsd.org/~pgollucci/png-1.2.35.log
You have
WITHOUT_MAN=yes
I am not sure how ports system should handle that, in case it should.
D
On Tue, Apr 07, 2009 at 05:16:38PM -0400, Philip M. Gollucci wrote:
> Ion-Mihai Tetcu wrote:
> > Pass me the full log please.
>
> http://people.freebsd.org/~pgollucci/png-1.2.35.log
You have
WITHOUT_MAN=yes
I am not sure how ports system should handle that, in case it should.
--
http://ache.pp.
All/png-1.2.35.tbz
> Registering depends:.
> Creating bzip'd tar ball in '/tmp/packages/All/png-1.2.35.tbz'
> *** Error code 1
>
> Stop in /a/ports/graphics/png.
> Deleting png-1.2.35
> pkg_delete: file '/usr/local/man/man3/libpng.3.gz' doesn't ex
Ion-Mihai Tetcu wrote:
Pass me the full log please.
http://people.freebsd.org/~pgollucci/png-1.2.35.log
--
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollu...@p6m7g8.com) c: 70
;
*** Error code 1
Stop in /a/ports/graphics/png.
Deleting png-1.2.35
pkg_delete: file '/usr/local/man/man3/libpng.3.gz' doesn't exist
pkg_delete: file '/usr/local/man/man3/libpngpf.3.gz' doesn't exist
pkg_delete: file '/usr/local/man/man5/png.5.gz' doesn
Hello,
Peter Czanik írta:
> Peter Czanik írta:
>
>> Hello,
>> Recently graphics/png can't be packaged:
>>
>> libpng passes test
>> ===> Installing for png-1.2.34
>> ===> Generating temporary packing list
>> install -o root -g
Peter Czanik írta:
> Hello,
> Recently graphics/png can't be packaged:
>
> libpng passes test
> ===> Installing for png-1.2.34
> ===> Generating temporary packing list
> install -o root -g wheel -m 555 libpng-config /usr/local/bin
> ln -sf libpng-config /usr/
Hello,
Recently graphics/png can't be packaged:
libpng passes test
===> Installing for png-1.2.34
===> Generating temporary packing list
install -o root -g wheel -m 555 libpng-config /usr/local/bin
ln -sf libpng-config /usr/local/bin/libpng12-config
install -C -o root -g w
cs/apng or add the patch to
graphics/png.
I rather to honor graphics/png (include PNG folks) and no way for
graphics/apng as it will be worst to have conflict in ports tree. It's
pain in ass. Keep in its tarball and compiles as static is fine. It's no
big deal and problem solve.
right hand side of the
menu bar, which tell you that its loading a page.
Oh, I see. Well, if that thing requires APNG, then, indeed, it is
indispensable and the cat is, indeed, out of the bag... In that case we
should either make our own graphics/apng or add the patch to graphics/png
Hi,
On Mon, Dec 22, 2008 at 08:16:43PM -0500, Mikhail T. wrote:
> >The throbber is pretty important UI for a browser. If you break it,
> >people will complain.
> Uhm, what is "throbber"? Could you elaborate?
The little spinning things in the tabs, or the right hand side of the
menu bar, which te
Jeremy Lea wrote:
Hi,
On Mon, Dec 22, 2008 at 05:06:52PM -0500, Mikhail Teterin wrote:
Was not one of the advantages of APNG the fact, that a non-Animated PNG
reader will still show the first frame of the animation? In that case,
the icons will simply be non-animated...
The throbber
Hi,
On Mon, Dec 22, 2008 at 05:06:52PM -0500, Mikhail Teterin wrote:
> Was not one of the advantages of APNG the fact, that a non-Animated PNG
> reader will still show the first frame of the animation? In that case,
> the icons will simply be non-animated...
The throbber is pretty important UI
Sent by Jeremy Lea:
Hi,
On Mon, Dec 22, 2008 at 03:10:59PM -0500, Mikhail Teterin wrote:
Personally, I think, I'm in favor of the last approach, at least for
now that animated PNG (APNG) content is non-existent anyway
Except for many of the chrome icons in firefox, etc. i.e. doing th
Hi,
On Mon, Dec 22, 2008 at 03:10:59PM -0500, Mikhail Teterin wrote:
> Personally, I think, I'm in favor of the last approach, at least for
> now that animated PNG (APNG) content is non-existent anyway
Except for many of the chrome icons in firefox, etc. i.e. doing this
with break firefox. Do n
ion for us is how to build the ports -- whether to:
* build the libpng as static from the sources, that come with each
of the
numerous Mozilla pieces and link them into each piece statically;
* fork a separate graphics/mozilla-png -- CONFLICT it with graphics/png
and allow the use
On Mon, 2008-12-15 at 23:02 -0600, Jeremy Messenger wrote:
> On Mon, 15 Dec 2008 16:38:56 -0600, Coleman Kane
> wrote:
>
> > On Sun, 2008-12-14 at 22:54 -0600, Jeremy Messenger wrote:
> >> On Sun, 14 Dec 2008 12:22:34 -0600, Coleman Kane
> >> wrote:
> >>
> >> > Hello,
> >> >
> >> > I recently pl
On Mon, 15 Dec 2008 16:38:56 -0600, Coleman Kane
wrote:
On Sun, 2008-12-14 at 22:54 -0600, Jeremy Messenger wrote:
On Sun, 14 Dec 2008 12:22:34 -0600, Coleman Kane
wrote:
> Hello,
>
> I recently played with building Thunderbird 3.0b1 from source (it
works
> pretty well, btw). I was playin
On Sun, 2008-12-14 at 22:54 -0600, Jeremy Messenger wrote:
> On Sun, 14 Dec 2008 12:22:34 -0600, Coleman Kane
> wrote:
>
> > Hello,
> >
> > I recently played with building Thunderbird 3.0b1 from source (it works
> > pretty well, btw). I was playing with some of the options to enable
> > using the
ate change to the port files of graphics/png. I think
that APNG support from libpng may be useful in other software as well.
I am attaching the patch, to apply in /usr/ports, for anyone to test. So
far it doesn't seem to regress anything for me, and I can use
thunderbird 3 with --with-system-pn
On Mon, 2008-12-15 at 02:28 +0300, Andrey Chernov wrote:
> On Sun, Dec 14, 2008 at 01:22:34PM -0500, Coleman Kane wrote:
> > One thing that I noticed was the APNG patch from here:
> > * http://littlesvr.ca/apng/.
> > This seems to be expected by Thunderbird and is part of the latest
> > source tr
On Sun, Dec 14, 2008 at 01:22:34PM -0500, Coleman Kane wrote:
> One thing that I noticed was the APNG patch from here:
> * http://littlesvr.ca/apng/.
> This seems to be expected by Thunderbird and is part of the latest
> source tree. Mozilla has been maintaining a format spec here:
> * https://
merged the patch into the latest version (1.2.33) that we use, and have
made an appropriate change to the port files of graphics/png. I think
that APNG support from libpng may be useful in other software as well.
I am attaching the patch, to apply in /usr/ports, for anyone to test. So
far it
this:
if ${.CURDIR:M/usr/ports/*}
CC= distcc cc
.endif
It's actually more complex, but that's what it comes down to.
If I now do that:
# cd /usr/ports/graphics/png; make -V CC
distcc cc
I can see that the ports makefile has the right CC setting. However, the file
/usr/obj/usr/ports/grap
honor CC.
It is not a reason, it is a goal. The reason is the bug true nature
discovered.
I normally set CC to anything and it honors.
How did you set? The graphics/png doesn't honor it when you add
CC=foobar in make.conf or graphics/png/Makefile.
/usr/ports/graphics/pn
te:
>>>>>>>
>>>>>>>> On Sat, Jul 29, 2006 at 01:16:47PM -0500, Jeremy Messenger wrote:
>>>>>>>>
>>>>>>>>> On Fri, 28 Jul 2006 18:35:14 -05
1 - 100 of 118 matches
Mail list logo
