Need to ship jpeg library that we build from the tree

VERIFIED DUPLICATE of bug 32754

Status

()

P3
major
VERIFIED DUPLICATE of bug 32754
19 years ago
19 years ago

People

(Reporter: dp, Assigned: granrosebugs)

Tracking

({relnote})

Trunk
x86
Linux
relnote
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT-])

(Reporter)

Description

19 years ago
We need to ship the jpeg library that we build from the tree. We seem to have 
a requirement of libjpeg.so.2 that is available on linux. Instead for the 
shipping product we need to ship the jpeg library we build and not have 
external dependency on system jpeg libraries.
(Reporter)

Comment 1

19 years ago
Marking beta1.

Pam, I am initially assinging the bug to you so you can drive this to 
completion.
Keywords: beta1

Comment 2

19 years ago
ok. This is a dupe, but I'll let granrose mark it.
-p
Assignee: pnunn → granrose

Comment 3

19 years ago
Putting on [NEED INFO], chofmann to get more info.
Whiteboard: [NEED INFO]

Comment 4

19 years ago
*** Bug 30196 has been marked as a duplicate of this bug. ***

Comment 5

19 years ago
Putting on PDT- radar for beta1.
Whiteboard: [NEED INFO] → [PDT-]
(Reporter)

Comment 6

19 years ago
We have decided that we have shipped 14 milestone
builds to 30-40,000 linux users over the last several
months, and this doesn't appear to have become a
significant problem for those testers...

chofmann -from dp's cube

should release note the fact that we rely on 
linux/unix platforms to provide a libjpeg.so
as part of OS installation.

We might think about shipping this way for the final
release to cut down on the size of the mozilla/netscape
download packages...

dp might have other comments about the wonders of modularity
and our ability to find, trust, and use modular components
from the OS...

blizzard,  any comments on what you think might be the right
thing to do here based on what is provided and installed
by most users in, say, the RedHat distribution? 
Keywords: relnote

Comment 7

19 years ago
Based on what i've heard from most of the people i've talked to about this issue
(that is, outside of netscape), who have some experience with unix software
development, it seems that the right thing is to turn on the building of our own
image libraries. This might increase our download size, but SuSE linux users
will hate us less if we do it.
The jpeg library seems to be the real kicker.  Maybe we can rename it to
libmozjpeg and build it?  The other libraries seem less pained.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 9

19 years ago
so what's the plan for this?  Do I need to do anything, and if so, what's the 
timeframe?  I'm assuming this is not a nscp beta bug since it's PDT- and there's 
no beta1 keyword.

Comment 10

19 years ago
surprise! i already modified the automation to build mozilla jpeg, png, and
zlib.

i need to get someone with suse to try running the most recent builds.

Comment 11

19 years ago
if it turns out that there is good demand for the jpeg library we 
could drop it on the ftp site and have the beta 1 release notes point
at it.

Comment 12

19 years ago
I hate to break this to you, but it's all the same automation, so we're building
mozilla's jpeg on the beta branch builds as well.
(Assignee)

Comment 13

19 years ago
leaf has already fixed this.  resolving duplicate.

*** This bug has been marked as a duplicate of 32754 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 14

19 years ago
*** Bug 34998 has been marked as a duplicate of this bug. ***

Comment 15

19 years ago
dp@netscape.com/et al, I'm rubber-stamping this as Verified since I see 
'libjpeg.so' in the install directory.

The bug it was marked as duplicate is now fixed, so please re-open it if you're 
still seeing any problem.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.