Something happens: https://bugzilla.mozilla.org/show_bug.cgi?id=517422#c11

I'm going to try to adapt those patches on Icecat.

We talked about this at today's meeting but decided to defer it as there was a lot to think about. Some of the highlights from today's meeting notes:

• Some FPC members thought that firefox had a blanket bundling exception but after some research we only found an [https://fedorahosted.org/fesco/ticket/472#comment:16 exception for libvpx] which is no longer bundled.
• Many FPC members felt that in fairness to icecat we should allow the same exceptions as firefox was granted. Since firefox hasn't been granted any at the moment, we'd need to look at whether to grant firefox any bundling exceptions.
• One FPC member thought that one of the reasons we might ship icecat would could make changes to unbundle without worrying about the mozilla trademarks. So even though it would be fair to grant icecat the same exceptions as firefox it might be better to unbundle in Fedora.

All of these issues and potential ways forward will need to be discussed more before a decision is made.

Replying to [comment:2 toshio]:

We talked about this at today's meeting but decided to defer it as there was a lot to think about. Some of the highlights from today's meeting notes:

• Some FPC members thought that firefox had a blanket bundling exception but after some research we only found an [https://fedorahosted.org/fesco/ticket/472#comment:16 exception for libvpx] which is no longer bundled.
• Many FPC members felt that in fairness to icecat we should allow the same exceptions as firefox was granted. Since firefox hasn't been granted any at the moment, we'd need to look at whether to grant firefox any bundling exceptions.
• One FPC member thought that one of the reasons we might ship icecat would could make changes to unbundle without worrying about the mozilla trademarks. So even though it would be fair to grant icecat the same exceptions as firefox it might be better to unbundle in Fedora.

All of these issues and potential ways forward will need to be discussed more before a decision is made.

I agree.
I just want remember you that Firefox and Icecat may have different configuration entries (mozconfig file); therefore Firefox-or-xulrunner don't need of media libraries required by Icecat instead.
This ticket exists because, enabling OGG-OPUS-WEBM support, Icecat needs bundled libogglibtheoralibopus*libvorbis; easiest choice is to disable their support till conditions improve.

Question from today's meeting: Do all the libraries that you're requesting a bundling exception for have a non-upstreamed patch? If so, that might be a point in favor of us granting a temporary bundling exception while those patches are integrated upstream.

Replying to [comment:4 toshio]:

Question from today's meeting: Do all the libraries that you're requesting a bundling exception for have a non-upstreamed patch?

Effectively, nearly for every library the patches have been transmitted and verified in specific svn releases almost. For instance, about libvorbis I read this note:

The source from this directory was copied from the libvorbis subversion repository using the update.sh script. The only changes made were those applied by update.sh and the addition/upate of Makefile.in files for the Mozilla build system. The upstream version used was libvorbis svn r18077.

Some files are renamed during the copy to prevent clashes with object file names with other Mozilla libraries.

alloca.diff - Bug 469639 - Failed to build firefox trunk on OpenSolaris

In any case, currently Icecat compilation doesn't consider the linkage against these libraries in Fedora.

Replying to [comment:4 toshio]:

If so, that might be a point in favor of us granting a temporary bundling exception while those patches are integrated upstream.

Next week, GNUzilla team should release a new Icecat version (27.0.1) (http://lists.gnu.org/archive/html/bug-gnuzilla/2014-03/msg00008.html). Maybe, this exception for bundled files may not be necessary anymore with the new release.

Next week, GNUzilla team should release a new Icecat version (27.0.1) (​http://lists.gnu.org/archive/html/bug-gnuzilla/2014-03/msg00008.html). Maybe, this exception for bundled files may not be necessary anymore with the new release.

To this day, Icecat 27 has not been released yet

I'm still working on Icecat-24. Situation of bundled files (based on https://bugzilla.redhat.com/show_bug.cgi?id=517856#c15) is currently (those #marked are NOT removed in build process):

{{{
rm -rf media/libjpeg
rm -rf js/src/ctypes/libffi
rm -rf media/libpng
rm -rf memory/jemalloc

It doesn't seems possible to link against these system libraries

See https://bugzilla.mozilla.org/show_bug.cgi?id=517422

rm -rf media/libtheora

rm -rf media/libvorbis

rm -rf media/libogg

rm -rf media/libopus

rm -rf media/libvpx \
media/webrtc/trunk/third_party/libyuv/include \
testing/gtest/gtest/include/gtest \
addon-sdk/source/doc/static-files/syntaxhighlighter \
addon-sdk/source/doc/static-files/js/jquery.js \
addon-sdk/source/examples/reddit-panel/data/jquery-1.4.4.min.js \
addon-sdk/source/examples/annotator/data/jquery-1.4.2.min.js \
addon-sdk/source/examples/library-detector/data/library-detector.js \
addon-sdk/source/python-lib/markdown \
addon-sdk/source/python-lib/simplejson \
build/pymake \
build/stlport \
content/canvas/test/webgl \
db/sqlite3 \
editor/libeditor/html/tests/browserscope \
gfx/cairo \
gfx/skia \
intl/icu \
media/mtransport/third_party/nICEr \
media/mtransport/third_party/nrappkit \
media/webrtc \
memory/jemalloc \
modules/freetype2 \
modules/libbz2 \
modules/zlib \
netwerk/srtp \
other-licenses/7zstub/src \
other-licenses/atk-1.0/atk \
other-licenses/bsdiff \
other-licenses/ply \
python/blessings \
python/mock-1.0.0 \
python/psutil \
python/which \
security/nss \
security/sandbox \
testing/mochitest/pywebsocket \
testing/mozbase/mozprocess/tests/iniparser \
testing/xpcshell/node-spdy \
toolkit/devtools/acorn

intl/locales/*/hyphenation ?

js \ ?

nsprpub \ ?

python/virtualenv \ ?

intl/hyphenation \ ?

ipc/chromium \ ?

media/libcubeb \ not built in fedora

media/libspeex_resampler \ patched

media/libnestegg \ not built in fedora

media/libsoundtouch \ ?

media/kiss_fft \ not built in fedora

parser/expat/lib \ ?

gfx/angle \ not built in fedora

gfx/graphite2 \ ?

gfx/harfbuzz \ ?

gfx/ots \ ?

gfx/ybcr \ not built in fedora

toolkit/crashreporter/google-breakpad \ not built in fedora and not requested

other-licenses/snappy \ ?

build/pgo/blueprint \ not built in fedora

mfbt/double-conversion \ ?

}}}

I'm still working on Icecat-24. Situation of bundled files (based on https://bugzilla.redhat.com/show_bug.cgi?id=517856#c15) is currently (those #marked are NOT removed in build process):

{{{
rm -rf media/libjpeg
rm -rf js/src/ctypes/libffi
rm -rf media/libpng
rm -rf memory/jemalloc

It doesn't seems possible to link against these system libraries

See https://bugzilla.mozilla.org/show_bug.cgi?id=517422

rm -rf media/libtheora

rm -rf media/libvorbis

rm -rf media/libogg

rm -rf media/libopus

rm -rf media/libvpx \
media/webrtc/trunk/third_party/libyuv/include \
testing/gtest/gtest/include/gtest \
addon-sdk/source/doc/static-files/syntaxhighlighter \
addon-sdk/source/doc/static-files/js/jquery.js \
addon-sdk/source/examples/reddit-panel/data/jquery-1.4.4.min.js \
addon-sdk/source/examples/annotator/data/jquery-1.4.2.min.js \
addon-sdk/source/examples/library-detector/data/library-detector.js \
addon-sdk/source/python-lib/markdown \
addon-sdk/source/python-lib/simplejson \
build/pymake \
build/stlport \
content/canvas/test/webgl \
db/sqlite3 \
editor/libeditor/html/tests/browserscope \
gfx/cairo \
gfx/skia \
intl/icu \
media/mtransport/third_party/nICEr \
media/mtransport/third_party/nrappkit \
media/webrtc \
memory/jemalloc \
modules/freetype2 \
modules/libbz2 \
modules/zlib \
netwerk/srtp \
other-licenses/7zstub/src \
other-licenses/atk-1.0/atk \
other-licenses/bsdiff \
other-licenses/ply \
python/blessings \
python/mock-1.0.0 \
python/psutil \
python/which \
security/nss \
security/sandbox \
testing/mochitest/pywebsocket \
testing/mozbase/mozprocess/tests/iniparser \
testing/xpcshell/node-spdy \
toolkit/devtools/acorn

intl/locales/*/hyphenation ?

js \ ?

nsprpub \ ?

python/virtualenv \ ?

ipc/chromium \ ?

media/libcubeb \ no built in fedora

media/libspeex_resampler \ patched

media/libnestegg \ no built in fedora

media/libsoundtouch \ Patched/customized by upstream team. See specific README_MOZILLA..

media/kiss_fft \ no built in fedora

gfx/angle \ no built in fedora

gfx/harfbuzz \ Customized by upstream team. See specific README_MOZILLA.

gfx/ots \ Patched by upstream team. See specific README_MOZILLA.

gfx/ybcr \ no built in fedora

toolkit/crashreporter/google-breakpad \ not built in fedora and not requested

other-licenses/snappy \ ?

build/pgo/blueprint \ no built in fedora

mfbt/double-conversion \ ?

}}}

This is the related koji build for f20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6679382

Other libraries seem more difficult to patching. I hope next release may be more manageable.

FPC talked about this and continued to try to refine a general policy that we could apply to this package and to firefox. I've written the proposals here:

https://fedoraproject.org/wiki/User:Toshio/Bundling_relaxation

It's unknown yet whether the necessary proposals would be successful in passing the FPC. If they did, I think that a combination of either 1 or 2 (to clear firefox) and 4 might work for icecat.

Replying to [comment:9 toshio]:

https://fedoraproject.org/wiki/User:Toshio/Bundling_relaxation
As I said during last meeting, I am negative on this proposal, because it's way too lax and opens up all backdoors to all bundling. IMO, all such bundling exceptions need to be temporary and need to be re-evaluated at fixed intervals, with the option to revoke such exceptions and to withdraw packages if necessary.

=> -1 on Toshio's proposal.

I am however positive on grating icecat a special temporary exception on bundling all libs firefox bundles, but would encourage GNUzilla/icecat to treat this as "last escape in case all else fail" to continue their (as I perceive it) good work to escape the historic issues firefox has never been able to overcome.

<nod> I assume you mean -1 on any of the four of the proposals on that page?

A temporary exception is something else we might pass for icecat specifically. We probably want to determine:

• What time period before we revist?
• How much progress do we want to see at that time?
• Given past behaviour, firefox will likely bundle more/apply new patches to existing bundled libraries. How do we want that to affect our exception for icecat?

At last week's meeting we passed all four of the criteria listed on

https://fedoraproject.org/wiki/User:Toshio/Bundling_relaxation

info Security team, too big to fail, too small to care, and forks of packages granted an exception are passed (+1:5, 0:0, -1:1)

We wanted to highlight that these are all criteria that we may use to evaluate whether a package is allowed to bundle but like all the criteria, none of these is a sure thing. ie: if you come to us with a package that has an active security team we may still say no.

The specific question of icecat and firefox we started voting on:

Proposal: firefox has a bundling exception since it has an active security team tracking issues in their codebase. icecat has an exception since it is a fork of firefox that closely tracks firefox's changes.

but tibbs brought up that he would be more in favor of a temporary bundling exception than a permanent one that allowed firefox to bundle forever. We agreed to further discuss this this week.

Since I will likely not be here this week, I am +1 to a temporary bundling exception for both icecat and firefox with whatever length of time or other terms that the other fpc members propose.

I might vote for a permanent exception as well but if that's what ends up on the table I would prefer to read the meeting log and cast my vote after the meeting.

Note to self/meeting chair: before this ticket is closed, we'll need to integrate both the firefox/icecat decision and the criteria from Bundling_relaxation into the No_bundled_libraries page.

Please, can we take up a little of time to draft these new guidelines for Icecat and Firefox?

Greetings.

info firefox has a temporary bundling exception since it has an active security team tracking issues in their codebase. icecat has a temporary exception since it is a fork of firefox that closely tracks firefox's changes. We'll re-evaluate this before F22. Passed (+1:7, 0:0, -1:0)

Hmm... It makes sense for us to have virtual provides for each individual project being bundled so that the security team can easily alert maintainers when a security issue in a bundled library pops up. From the list of bundled software, it's not clear what the project or package names should be. Could the icecat and firefox/xulrunner maintainers propose a list of virtual provides should be for your respective projects? The list will look something like:

{{{
Provides: bundled(libtheora)
Provides: bundled(libvorbis)
Provides: bundled(libogg)
Provides: bundled(opus)
[...]
}}}

I'm just not sure what some of the other names should be.

Once we have the list, I can update the bundled library page and you can start using them. Note that virtual Provides should carry version information where applicable to aid the security team in evaluating whether a flaw affects the version of code that's being bundled. So in your package you might have Provides: bundled(libtheora) = 1.1.1

Hi Toshio.

Replying to [comment:18 toshio]:

Hmm... It makes sense for us to have virtual provides for each individual project being bundled so that the security team can easily alert maintainers when a security issue in a bundled library pops up. From the list of bundled software, it's not clear what the project or package names should be. Could the icecat and firefox/xulrunner maintainers propose a list of virtual provides should be for your respective projects? The list will look something like:

{{{
Provides: bundled(libtheora)
Provides: bundled(libvorbis)
Provides: bundled(libogg)
Provides: bundled(opus)
[...]
}}}

I'm just not sure what some of the other names should be.

Once we have the list, I can update the bundled library page and you can start using them. Note that virtual Provides should carry version information where applicable to aid the security team in evaluating whether a flaw affects the version of code that's being bundled. So in your package you might have Provides: bundled(libtheora) = 1.1.1

The virtual-provides list for Icecat is already mentioned in the SPEC file (http://sagitter.fedorapeople.org/Icecat/icecat.spec) since it is provided for the packaging guidelines:

{{{

FPC ticket https://fedorahosted.org/fpc/ticket/391

Provides: bundled(libtheora) = 1.1.1
Provides: bundled(libvorbis) = 1.3.4
Provides: bundled(libogg) = 1.3.0
Provides: bundled(opus) = 1.1
Provides: bundled(xulrunner) = 24.0
Provides: bundled(expat) = 2.1.0
Provides: bundled(graphite2) = 1.2.3
Provides: bundled(python-virtualenv) = 1.8.4
Provides: bundled(ots) = 0.5.0
Provides: bundled(hurfbuzz) = 0.9.2
Provides: bundled(soundtouch) = 1.7.3
Provides: bundled(snappy) = 1.0.4
Provides: bundled(double-conversion) = 1.1.3
}}}

Toshio, do you need something else to go on?

RPM packaging of Icecat goes on...
The Virtual Provides list is now

{{{
Provides: bundled(libtheora) = 1.1.1
Provides: bundled(libvorbis) = 1.3.4
Provides: bundled(libogg) = 1.3.0
Provides: bundled(opus) = 1.1
Provides: bundled(xulrunner) = 24.0
Provides: bundled(expat) = 2.1.0
Provides: bundled(graphite2) = 1.2.3
Provides: bundled(ots) = 0.5.0
Provides: bundled(hurfbuzz) = 0.9.2
Provides: bundled(soundtouch) = 1.7.3
Provides: bundled(snappy) = 1.0.4
Provides: bundled(double-conversion) = 1.1.3
}}}

We are also in waiting for a reply from Firefox maintainers so, please, give an positive/negative opinion about this ticket. In my opinion, six months are exaggerated to have a resolution.

Thanks.

As for the Firefox team, the virtual list of bundled libraries looks okay to me.

Added the list of provides in comment:21 to the bundled library page. @stransky, if you need more virtual provides than that due to firefox bundling other libraries, let us know and we'll add them to the page.

icecat packagers, you are good to go.

Thank you very much.

So, turns out the four criteria from https://fedoraproject.org/wiki/User:Toshio/Bundling_relaxation were all approved, but were never written into the guidelines. See:

• comment 13 in this ticket
• http://meetbot.fedoraproject.org/teams/fpc/fpc.2014-04-03-16.02.log.html#l-208
• http://meetbot.fedoraproject.org/teams/fpc/fpc.2014-04-03-16.02.log.html#l-224

I'll take care of writing this all up.

Announcement text:

The guidelines on library bundling have been expanded to provide information on some additional cases where the packaging committee may grant exceptions.
* https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Some_reasons_you_might_be_granted_an_exception
* https://fedoraproject.org/w/index.php?title=Packaging%3ANo_Bundled_Libraries&diff=406057&oldid=383256
* https://fedorahosted.org/fpc/ticket/391#comment:13