Re: Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
reopen 990059 affects 990059 firefox-esr firefox libcurl3-nss thanks On Sat, Jun 19, 2021 at 09:00:13AM +0200, Carsten Schoenert wrote: > Hello Kevin, hello Sebastian, > > thanks for working on this issue in between times, I wasn't able to do > anything practically the last days. > > Am 18.06.21 um 23:31 schrieb Kevin Locke: > > Hi Sebastian, > > > > On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote: > >> Thanks for this detailed analysis. That actually means that the symbol > >> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum > >> version requirement for all symbols that works with SSLChannelInfo. From > >> your description, at least the version for SSL_GetChannelInfo would need > >> to be bumped. If thunderbird would then be built against a libnss3 > >> version with a fixed symbol files, it would pick up tight enought > >> dependencies. > >> > >> So ideally the bug against thunderbird would be reassigned to libnss3 > >> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild > >> thunderbird to pick up the correct depedencies. > > > > Good point. Fixing the libnss3 symbol file sounds like the right fix to > > me. As far as I can tell SSL_GetChannelInfo is the only symbol which > > takes SSLChannelInfo. I've opened https://bugs.debian.org/990058 with > > the proposed fix. > > Fixing libnss3 is obviously the correct thing anyway. But this will take > its time to get it landed into bullseye. > > >> But since that version of libnss3 is not in bullseye, the rebuild would > >> not be abile to migrate. Ideally libnss3 would be reverted to the > >> version in bullseye to avoid this issue. Otherwise I can schedule > >> binNMUs of thunderbird in tpu, but that means that we would need to do > >> that for any thunderbird upload that we want in bullseye until the > >> release. That is suboptimal - it's more work with less testing. > > > > That may be tricky. firefox 88.0.1-1 in unstable depends on > > libnss3 (>= 2:3.63~). If the maintainers are willing to upload an NSS > > version between 2:3.63 and 2:3.65, I believe that would solve the issue > > without breaking firefox. (2:3.63-1 is the only suitable version > > in debian/changelog.) I've opened https://bugs.debian.org/990059 to > > discuss. > > To prevent quite a lot of work on all involved parties with not that > much gain in the end I'd suggest to go back to my option B that was to > (re)build Thunderbird with it's internal shipped NSS version. Unfortunately, this affects more than Thunderbird. It also affects Firefox ESR (although not on amd64 because for some reason it was built against an older version of NSS, but it affects other architectures). It also affects the latest upload of curl. I'm going to upload a new version of 3.67 that will restore the binary compat so that things built against the new version will work with the older one. That should allow to binNMU the affected packages. Mike
Re: Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
On Mon, Jul 05, 2021 at 07:57:30AM +0900, Mike Hommey wrote: > reopen 990059 > affects 990059 firefox-esr firefox libcurl3-nss > thanks > > On Sat, Jun 19, 2021 at 09:00:13AM +0200, Carsten Schoenert wrote: > > Hello Kevin, hello Sebastian, > > > > thanks for working on this issue in between times, I wasn't able to do > > anything practically the last days. > > > > Am 18.06.21 um 23:31 schrieb Kevin Locke: > > > Hi Sebastian, > > > > > > On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote: > > >> Thanks for this detailed analysis. That actually means that the symbol > > >> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum > > >> version requirement for all symbols that works with SSLChannelInfo. From > > >> your description, at least the version for SSL_GetChannelInfo would need > > >> to be bumped. If thunderbird would then be built against a libnss3 > > >> version with a fixed symbol files, it would pick up tight enought > > >> dependencies. > > >> > > >> So ideally the bug against thunderbird would be reassigned to libnss3 > > >> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild > > >> thunderbird to pick up the correct depedencies. > > > > > > Good point. Fixing the libnss3 symbol file sounds like the right fix to > > > me. As far as I can tell SSL_GetChannelInfo is the only symbol which > > > takes SSLChannelInfo. I've opened https://bugs.debian.org/990058 with > > > the proposed fix. > > > > Fixing libnss3 is obviously the correct thing anyway. But this will take > > its time to get it landed into bullseye. > > > > >> But since that version of libnss3 is not in bullseye, the rebuild would > > >> not be abile to migrate. Ideally libnss3 would be reverted to the > > >> version in bullseye to avoid this issue. Otherwise I can schedule > > >> binNMUs of thunderbird in tpu, but that means that we would need to do > > >> that for any thunderbird upload that we want in bullseye until the > > >> release. That is suboptimal - it's more work with less testing. > > > > > > That may be tricky. firefox 88.0.1-1 in unstable depends on > > > libnss3 (>= 2:3.63~). If the maintainers are willing to upload an NSS > > > version between 2:3.63 and 2:3.65, I believe that would solve the issue > > > without breaking firefox. (2:3.63-1 is the only suitable version > > > in debian/changelog.) I've opened https://bugs.debian.org/990059 to > > > discuss. > > > > To prevent quite a lot of work on all involved parties with not that > > much gain in the end I'd suggest to go back to my option B that was to > > (re)build Thunderbird with it's internal shipped NSS version. > > Unfortunately, this affects more than Thunderbird. It also affects > Firefox ESR (although not on amd64 because for some reason it was built > against an older version of NSS, but it affects other architectures). It > also affects the latest upload of curl. It also affects openjdk-17, openjdk-8 and pcp in sid, if they're ever meant to transition to testing (which, from the look of it, is probably not the case). Mike
Re: Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality
On Mon, Jul 05, 2021 at 08:14:45AM +0900, Mike Hommey wrote: > On Mon, Jul 05, 2021 at 07:57:30AM +0900, Mike Hommey wrote: > > reopen 990059 > > affects 990059 firefox-esr firefox libcurl3-nss > > thanks > > > > On Sat, Jun 19, 2021 at 09:00:13AM +0200, Carsten Schoenert wrote: > > > Hello Kevin, hello Sebastian, > > > > > > thanks for working on this issue in between times, I wasn't able to do > > > anything practically the last days. > > > > > > Am 18.06.21 um 23:31 schrieb Kevin Locke: > > > > Hi Sebastian, > > > > > > > > On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote: > > > >> Thanks for this detailed analysis. That actually means that the symbol > > > >> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum > > > >> version requirement for all symbols that works with SSLChannelInfo. > > > >> From > > > >> your description, at least the version for SSL_GetChannelInfo would > > > >> need > > > >> to be bumped. If thunderbird would then be built against a libnss3 > > > >> version with a fixed symbol files, it would pick up tight enought > > > >> dependencies. > > > >> > > > >> So ideally the bug against thunderbird would be reassigned to libnss3 > > > >> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild > > > >> thunderbird to pick up the correct depedencies. > > > > > > > > Good point. Fixing the libnss3 symbol file sounds like the right fix to > > > > me. As far as I can tell SSL_GetChannelInfo is the only symbol which > > > > takes SSLChannelInfo. I've opened https://bugs.debian.org/990058 with > > > > the proposed fix. > > > > > > Fixing libnss3 is obviously the correct thing anyway. But this will take > > > its time to get it landed into bullseye. > > > > > > >> But since that version of libnss3 is not in bullseye, the rebuild would > > > >> not be abile to migrate. Ideally libnss3 would be reverted to the > > > >> version in bullseye to avoid this issue. Otherwise I can schedule > > > >> binNMUs of thunderbird in tpu, but that means that we would need to do > > > >> that for any thunderbird upload that we want in bullseye until the > > > >> release. That is suboptimal - it's more work with less testing. > > > > > > > > That may be tricky. firefox 88.0.1-1 in unstable depends on > > > > libnss3 (>= 2:3.63~). If the maintainers are willing to upload an NSS > > > > version between 2:3.63 and 2:3.65, I believe that would solve the issue > > > > without breaking firefox. (2:3.63-1 is the only suitable version > > > > in debian/changelog.) I've opened https://bugs.debian.org/990059 to > > > > discuss. > > > > > > To prevent quite a lot of work on all involved parties with not that > > > much gain in the end I'd suggest to go back to my option B that was to > > > (re)build Thunderbird with it's internal shipped NSS version. > > > > Unfortunately, this affects more than Thunderbird. It also affects > > Firefox ESR (although not on amd64 because for some reason it was built > > against an older version of NSS, but it affects other architectures). It > > also affects the latest upload of curl. > > It also affects openjdk-17, openjdk-8 and pcp in sid, if they're ever > meant to transition to testing (which, from the look of it, is probably > not the case). Scrap that, openjdk* and pcp are not using the problematic symbol. Mike
Bug#990699: release.debian.org: Sorting out bug 990059 in bullseye
Package: release.debian.org Severity: important Usertags: binnmu transition Hi, Recent versions of libnss3 had a backwards incompatible change that made packages built with the newer versions fail to work properly with the older version of the package that is in bullseye. That wouldn't be a problem if 2 packages that use the problematic symbol and are built with the newer version hadn't themselves made it to bullseye. The packages are, namely, firefox-esr and curl (curl has only become a problem this week). I uploaded a version of nss (2:3.67-2) that works around the issue and will make rebuilds of those packages work with the version of nss in bullseye, meaning we'd need binNMUs of both curl and firefox-esr and subsequent transitions. However, firefox-esr is due for a security update next tuesday/wednesday, so it will be rebuilt anyways. I guess we might as well wait. Which leaves us with just curl. nmu curl_7.74.0-1.3 . ANY . -m 'Rebuild against newer libnss3-dev' Mike
Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
On Sat, Dec 11, 2021 at 01:54:21PM +, Adam D. Barratt wrote: > On Tue, 2021-11-30 at 13:36 -0500, Roberto C.Sánchez wrote: > > On Tue, Nov 30, 2021 at 06:00:57PM +, Adam D. Barratt wrote: > > > On Tue, 2021-11-30 at 09:37 -0500, Roberto C.Sánchez wrote: > > > > If there are no objections, I will proceed with uploading within > > > > the > > > > next 24 hours. I'd like to ensure that the new FF/TB make it > > > > into > > > > the next point release if at all possible and that work is > > > > currently > > > > blocked by the need for the updated rustc. > > > > > > > > > > I was assuming the plan was for the Firefox and Thunderbird updates > > > to > > > be released via the security archive. That's certainly how > > > basically > > > every other update to both packages occurs. > > > > > Quite right. I conflated the fact that LLVM and rustc are not going > > in via security update. Apologies for the confusion. > > As a quick follow-up to this, with the 11.2 point release being next > weekend, and thus the p-u freeze this weekend, I note that the rustc- > mozilla upload is not yet in NEW, so we're starting to get quite close > timing wise. Relatedly, what's the plan for cargo in buster? Firefox ESR needs at least 0.47, bullseye has 0.47, but buster has 0.43.1. Mike
Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
On Sat, Dec 11, 2021 at 05:04:17PM -0500, Roberto C. Sánchez wrote: > On Sun, Dec 12, 2021 at 06:34:01AM +0900, Mike Hommey wrote: > > On Sat, Dec 11, 2021 at 01:54:21PM +, Adam D. Barratt wrote: > > > On Tue, 2021-11-30 at 13:36 -0500, Roberto C.Sánchez wrote: > > > > On Tue, Nov 30, 2021 at 06:00:57PM +, Adam D. Barratt wrote: > > > > > On Tue, 2021-11-30 at 09:37 -0500, Roberto C.Sánchez wrote: > > > > > > If there are no objections, I will proceed with uploading within > > > > > > the > > > > > > next 24 hours. I'd like to ensure that the new FF/TB make it > > > > > > into > > > > > > the next point release if at all possible and that work is > > > > > > currently > > > > > > blocked by the need for the updated rustc. > > > > > > > > > > > > > > > > I was assuming the plan was for the Firefox and Thunderbird updates > > > > > to > > > > > be released via the security archive. That's certainly how > > > > > basically > > > > > every other update to both packages occurs. > > > > > > > > > Quite right. I conflated the fact that LLVM and rustc are not going > > > > in via security update. Apologies for the confusion. > > > > > > As a quick follow-up to this, with the 11.2 point release being next > > > weekend, and thus the p-u freeze this weekend, I note that the rustc- > > > mozilla upload is not yet in NEW, so we're starting to get quite close > > > timing wise. > > > > Relatedly, what's the plan for cargo in buster? Firefox ESR needs at > > least 0.47, bullseye has 0.47, but buster has 0.43.1. > > Emilio is working on that. There were some tweaks needed to the > rustc-mozilla packages I prepared in order to support his work. As of > this morning he identified some small additional tweaks, but he was able > to work around the issues in order to get a FF build completed. As soon > as he gives me the thumbs up, then I will make the final tweaks and > upload the rustc-mozilla packages. Will it be cargo-mozilla in buster? How about cbindgen? Will it be cbindgen-mozilla or is cbindgen just going to be updated? Mike
Bug#1033101: nmu: thunderbird_1:102.9.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu libnss3-dev 2:3.89-1 introduced an incompatibility that made builds against it fail to work with older versions of libnss3. 2:3.89-2 fixed that. Firefox-esr is also affected, but I'm going to upload a new version soon anyways. nmu thunderbird_1:102.9.0-1 . ANY . unstable . -m "Rebuild against libnss3-dev 2:3.89-2"
Bug#1033151: unblock: firefox-esr/102.9.0esr-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package firefox-esr
(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)
[ Reason ]
New version fixes CVEs and the RC bug that was putting the package in
the autorm list.
[ Impact ]
No firefox in bookwork.
[ Tests ]
Package was smoke-tested.
[ Risks ]
Apart from the upstream differences from the CVE fixes/new upstream
release, that we'd take (and have taken) in stable, the differences are
very limited in scope (see attached diff)
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock firefox-esr/102.9.0esr-2
diff -Nru firefox-esr-102.8.0esr/debian/browser.mozconfig.in
firefox-esr-102.9.0esr/debian/browser.mozconfig.in
--- firefox-esr-102.8.0esr/debian/browser.mozconfig.in 2023-02-15
08:44:35.0 +0900
+++ firefox-esr-102.9.0esr/debian/browser.mozconfig.in 2023-03-18
06:53:04.0 +0900
@@ -30,6 +30,6 @@
ac_add_options --with-unsigned-addon-scopes=app,system
ac_add_options --allow-addon-sideload
ac_add_options --enable-alsa
-%if DIST == bullseye || DIST == buster || DIST == stretch
+%if DIST == bullseye || DIST == buster || DIST == stretch || DEB_HOST_ARCH ==
s390x
ac_add_options --without-wasm-sandboxed-libraries
%endif
diff -Nru firefox-esr-102.8.0esr/debian/changelog
firefox-esr-102.9.0esr/debian/changelog
--- firefox-esr-102.8.0esr/debian/changelog 2023-02-15 08:45:08.0
+0900
+++ firefox-esr-102.9.0esr/debian/changelog 2023-03-18 06:53:38.0
+0900
@@ -1,3 +1,22 @@
+firefox-esr (102.9.0esr-2) unstable; urgency=medium
+
+ * gfx/skia/generate_mozbuild.py, gfx/skia/moz.build: Remove explicit NEON
+flags from skia build. Closes: #982794. Thanks Emanuele Rocca.
+
+ -- Mike Hommey Sat, 18 Mar 2023 06:53:38 +0900
+
+firefox-esr (102.9.0esr-1) unstable; urgency=medium
+
+ * New upstream release.
+ * Fixes for mfsa2023-10, also known as:
+CVE-2023-25751, CVE-2023-28164, CVE-2023-28162, CVE-2023-25752,
+CVE-2023-28176.
+
+ * debian/browser.mozconfig.in: Disable wasm sandboxing on s390x for now.
+It doesn't work at the moment.
+
+ -- Mike Hommey Wed, 15 Mar 2023 07:26:00 +0900
+
firefox-esr (102.8.0esr-1) unstable; urgency=medium
* New upstream release.
diff -Nru
firefox-esr-102.8.0esr/debian/patches/debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
firefox-esr-102.9.0esr/debian/patches/debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
---
firefox-esr-102.8.0esr/debian/patches/debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
2023-02-15 08:44:54.0 +0900
+++
firefox-esr-102.9.0esr/debian/patches/debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
2023-03-18 06:53:24.0 +0900
@@ -7,7 +7,7 @@
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/testing/xpcshell/runxpcshelltests.py
b/testing/xpcshell/runxpcshelltests.py
-index 212bfeb..6761334 100755
+index c3de2a2..0636219 100755
--- a/testing/xpcshell/runxpcshelltests.py
+++ b/testing/xpcshell/runxpcshelltests.py
@@ -13,6 +13,7 @@ import os
@@ -18,7 +18,7 @@
import shutil
import signal
import subprocess
-@@ -835,9 +836,23 @@ class XPCShellTestThread(Thread):
+@@ -837,9 +838,23 @@ class XPCShellTestThread(Thread):
if self.interactive:
self.log.info("%s | Process ID: %d" % (name, self.proc_ident))
diff -Nru
firefox-esr-102.8.0esr/debian/patches/porting/Bug-1822827-Remove-explicit-NEON-flags-from-skia-bui.patch
firefox-esr-102.9.0esr/debian/patches/porting/Bug-1822827-Remove-explicit-NEON-flags-from-skia-bui.patch
---
firefox-esr-102.8.0esr/debian/patches/porting/Bug-1822827-Remove-explicit-NEON-flags-from-skia-bui.patch
1970-01-01 09:00:00.0 +0900
+++
firefox-esr-102.9.0esr/debian/patches/porting/Bug-1822827-Remove-explicit-NEON-flags-from-skia-bui.patch
2023-03-18 06:53:24.0 +0900
@@ -0,0 +1,44 @@
+From: Emanuele Rocca
+Date: Sat, 18 Mar 2023 06:48:32 +0900
+Subject: Bug 1822827 - Remove explicit NEON flags from skia build
+
+While Firefox builds for Android ARMv7 don't support non-NEON
+processors, downstreams (including non-Android ones) may still want to
+support them.
+
+Because those Firefox builds don't support non-NEON processors, the NEON
+flags are actually already passed globally, and they don't need to be
+explicitly added. NEON_FLAGS is actually only meant to be used for
+sources that specifically need NEON support even when the target doesn't
+support it, for, e.g. specialized code behind runtime CPU detection.
+---
+ gfx/skia/generate_mozbuild.py | 2 --
+ gfx/skia/moz.build| 2 --
+ 2 files changed, 4 deletions(-)
+
+diff --git a/
nspr transition to testing
Hi, Why has nspr been a valid candidate for testing migration for several weeks or months without it happening? Mike
Re: nspr transition to testing
On Tue, Nov 15, 2016 at 07:24:00AM +, Niels Thykier wrote: > Mike Hommey: > > Hi, > > > > Why has nspr been a valid candidate for testing migration for several > > weeks or months without it happening? > > > > Mike > > > > Hi Mike, > > Britney believes migrating nspr will break libnspr4-0d in testing. > Which is technically true as libsnpr4-0d has a strictly equal dependency > on libsnpr4. Normally she should remove libnspr4-0d as she migrates > nspr to testing, but for some reason she doesn't in this case. > > It wasn't entirely obvious to me in the 5 minutes I had time to debug > it. AFAICT, nothing depends on libsnpr4-0d in testing, so at first > glance, she should just throw it out. Who should I bug for something to happen, presumably manually since it's not happening automatically? ftp-masters? Mike
Re: Plan for updating (hypothetical future) firefox-esr versions in stable with changed build-deps?
On Fri, Aug 26, 2016 at 11:39:20AM +0200, Julien Cristau wrote: > On Fri, Aug 26, 2016 at 06:59:20 +, Angus Lees wrote: > > > Dear SRMs, > > > > My understanding is that Debian's new-ish plan is to update firefox-esr > > versions in stable when there is a security update and the firefox-esr > > upstream support window for the previous version has expired. > > What is the plan for handling any new build-deps this new firefox-esr > > release might require, and how will they also be merged into the existing > > stable release? > > > I would expect firefox to bundle rustc I hope you're joking. Mike
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
On Mon, Jan 07, 2019 at 10:28:31AM +, Luke Kenneth Casson Leighton wrote: > On Sun, Jan 6, 2019 at 11:46 PM Steve McIntyre wrote: > > > > [ Please note the cross-post and respect the Reply-To... ] > > > > Hi folks, > > > > This has taken a while in coming, for which I apologise. There's a lot > > of work involved in rebuilding the whole Debian archive, and many many > > hours spent analysing the results. You learn quite a lot, too! :-) > > > > I promised way back before DC18 that I'd publish the results of the > > rebuilds that I'd just started. Here they are, after a few false > > starts. I've been rebuilding the archive *specifically* to check if we > > would have any problems building our 32-bit Arm ports (armel and > > armhf) using 64-bit arm64 hardware. I might have found other issues > > too, but that was my goal. > > very cool. > > steve, this is probably as good a time as any to mention a very > specific issue with binutils (ld) that has been slowly and inexorably > creeping up on *all* distros - both 64 and 32 bit - where the 32-bit > arches are beginning to hit the issue first. > > it's a 4GB variant of the "640k should be enough for anyone" problem, > as applied to linking. > > i spoke with dr stallman a couple of weeks ago and confirmed that in > the original version of ld that he wrote, he very very specifically > made sure that it ONLY allocated memory up to the maximum *physical* > resident available amount (i.e. only went into swap as an absolute > last resort), and secondly that the number of object files loaded into > memory was kept, again, to the minimum that the amount of spare > resident RAM could handle. > > some... less-experienced people, somewhere in the late 1990s, ripped > all of that code out [what's all this crap, why are we not just > relying on swap, 4GB swap will surely be enough for anybody"] > > by 2008 i experienced a complete melt-down on a 2GB system when > compiling webkit. i tracked it down to having accidentally enabled > "-g -g -g" in the Makefile, which i had done specifically for one > file, forgot about it, and accidentally recompiled everything. > > that resulted in an absolute thrashing meltdown that nearly took out > the entire laptop. > > the problem is that the linker phase in any application is so heavy > on cross-references that the moment the memory allocated by the linker > goes outside of the boundary of the available resident RAM it is > ABSOLUTELY GUARANTEED to go into permanent sustained thrashing. > > i cannot emphasise enough how absolutely critical that this is to > EVERY distribution to get this fixed. > > resources world-wide are being completely wasted (power, time, and the > destruction of HDDs and SSDs) because systems which should only really > take an hour to do a link are instead often taking FIFTY times longer > due to swap thrashing. > > not only that, but the poor design of ld is beginning to stop certain > packages from even *linking* on 32-bit systems! firefox i heard now > requires SEVEN GIGABYTES during the linker phase! > > and it's down to this very short-sighted decision to remove code > written by dr stallman, back in the late 1990s. > > it would be extremely useful to confirm that 32-bit builds can in fact > be completed, simply by adding "-Wl no-keep-memory" to any 32-bit > builds that are failing at the linker phase due to lack of memory. Note that Firefox is built with --no-keep-memory --reduce-memory-overheads, and that was still not enough for 32-bts builds. GNU gold instead of BFD ld was also given a shot. That didn't work either. Presently, to make things link at all on 32-bits platforms, debug info is entirely disabled. I still need to figure out what minimal debug info can be enabled without incurring too much memory usage during linking. Mike
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
On Mon, Jan 07, 2019 at 11:46:41PM +, Luke Kenneth Casson Leighton wrote: > On Tuesday, January 8, 2019, Mike Hommey wrote: > > > . > > > > Note that Firefox is built with --no-keep-memory > > --reduce-memory-overheads, and that was still not enough for 32-bts > > builds. GNU gold instead of BFD ld was also given a shot. That didn't > > work either. Presently, to make things link at all on 32-bits platforms, > > debug info is entirely disabled. I still need to figure out what minimal > > debug info can be enabled without incurring too much memory usage > > during linking. > > > Dang. Yes, removing debug symbols was the only way I could get webkit to > link without thrashing, it's a temporary fix though. > > So the removal of the algorithm in ld Dr Stallman wrote, dating back to the > 1990s, has already resulted in a situation that's worse than I feared. > > At some point apps are going to become so insanely large that not even > disabling debug info will help. That's less likely, I'd say. Debug info *is* getting incredibly more and more complex for the same amount of executable weight, and linking that is making things worse and worse. But having enough code to actually be a problem without debug info is probably not so close. There are solutions to still keep full debug info, but the Debian packaging side doesn't support that presently: using split-dwarf. It would probably be worth investing in supporting that. Mike
Re: firefox-esr: no longer using system nspr, nss, sqlite?
On Fri, Jun 16, 2017 at 04:09:12PM +0100, Steven Chamberlain wrote: > Hi, > > firefox-esr since 52.2.0esr-1 is no longer using the system libs for > nspr, nss, sqlite; was that an intentional change? > > This affects at least sid (where DIST="stretch"): > https://buildd.debian.org/status/fetch.php?pkg=firefox-esr&arch=amd64&ver=52.2.0esr-1&stamp=1497417448&raw=0 > (see "NSPR selection... source-tree", or grep for USE_SYSTEM_ ) > > and I expect it would affect the backports in jessie-security too (but I > don't know how/where to find build logs, to check that). > > Maybe it should have been ifneq in debian/rules? > | ifeq (,$(filter wheezy jessie stretch,$(DIST))) > | SYSTEM_LIBS += nspr nss sqlite > | endif > | #ifeq (,$(filter wheezy jessie,$(DIST))) > | SYSTEM_LIBS += vpx > | endif Look at the build dependencies in debian/control.in, specifically the versions, and the versions of the mentioned libraries in jessie and stretch. Yep, the required versions are not there. Mike
Bug#795079: stretch-pu: package iceweasel/38.1.1esr-1~deb9u1
On Mon, Aug 10, 2015 at 05:02:45PM +0100, Simon McVittie wrote: > On 10/08/15 16:57, Jonathan Wiltshire wrote: > > On 2015-08-10 15:52, Simon McVittie wrote: > >> On 10/08/15 13:35, Jonathan Wiltshire wrote: > >>> Yes, provided that an upload to unstable with a higher version number > >>> happens before or ASAP afterwards please. > >> > >> iceweasel/38.1.1esr-1 is already in unstable, which is why I suggested > >> iceweasel/38.1.1esr-1~deb9u1 for t-p-u. > >> > >> S > > > > Ah, apologies. In that case please go ahead. > > I am not the maintainer, just an interested user suggesting a way for > this security fix to bypass the g++-5 transition (and the X-Debbugs-Cc > to the maintainers seems to have got lost). > > iceweasel maintainers: if you want to do a t-p-u upload of an iceweasel > built in stretch to bypass the g++-5 transition, the release team say > that's OK (see #795079 for full details). > > If you don't intend to do that upload, would you like me to do so as an > NMU? (Disclaimer: I know nothing about iceweasel internals, so I would > just be "turning the handle" on a no-changes rebuild.) Please feel free to do so. I don't have a build environment for testing. You don't need anything more than a null changelog entry with a version bump. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150810220811.ga16...@glandium.org
Bug#795079: stretch-pu: package iceweasel/38.1.1esr-1~deb9u1
On Tue, Aug 11, 2015 at 07:08:11AM +0900, Mike Hommey wrote: > On Mon, Aug 10, 2015 at 05:02:45PM +0100, Simon McVittie wrote: > > On 10/08/15 16:57, Jonathan Wiltshire wrote: > > > On 2015-08-10 15:52, Simon McVittie wrote: > > >> On 10/08/15 13:35, Jonathan Wiltshire wrote: > > >>> Yes, provided that an upload to unstable with a higher version number > > >>> happens before or ASAP afterwards please. > > >> > > >> iceweasel/38.1.1esr-1 is already in unstable, which is why I suggested > > >> iceweasel/38.1.1esr-1~deb9u1 for t-p-u. > > >> > > >> S > > > > > > Ah, apologies. In that case please go ahead. > > > > I am not the maintainer, just an interested user suggesting a way for > > this security fix to bypass the g++-5 transition (and the X-Debbugs-Cc > > to the maintainers seems to have got lost). > > > > iceweasel maintainers: if you want to do a t-p-u upload of an iceweasel > > built in stretch to bypass the g++-5 transition, the release team say > > that's OK (see #795079 for full details). > > > > If you don't intend to do that upload, would you like me to do so as an > > NMU? (Disclaimer: I know nothing about iceweasel internals, so I would > > just be "turning the handle" on a no-changes rebuild.) > > Please feel free to do so. I don't have a build environment for testing. > You don't need anything more than a null changelog entry with a version > bump. Although, you have to be aware that there's going to be 38.2.0esr in about 24 hours. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150810221008.gb16...@glandium.org
Re: Bug#558412: binutils-dev: Please provide libbfd_pic.a
On Fri, Jan 15, 2010 at 07:57:51AM +0100, Luk Claes wrote: > Roberto C. Sanchez wrote: > > This did not seem to get any attention on debian-devel, so I am cross > > posting to debian-release. I would really be interested to know if > > others think that the binNMU approach suggested by Matthias is > > acceptable and/or viable. > > Unless it's an option to include oprofile into binutils source package, > I don't see what's wrong with the binNMU approach? Another option would be to have #548715 addressed, and stop caring about oprofile. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Please BinNMU 5 packages to fix their dependencies
Hi, The dh_xulrunner script provided by xulrunner 1.9.1.6-1 was broken and led to packages using it lacking a dependency on xulrunner-1.9.1. The script was fixed in 1.9.1.6-2 and to ensure it will continue to work in the future, I added a test during the xulrunner build. I've checked all the build-rdeps using dh_xulrunner and only 5 are apparently affected. So, please schedule the following binNMUs: nmu gluezilla_2.4.3-1 galeon_2.0.7-1.2 chmsee_1.0.7-1.2 gnome-python-extras_2.25.3-4.1 xiphos_3.1.2-1 . ALL . -m 'Rebuild with fixed dh_xulrunner, see #567746' dw gluezilla_2.4.3-1 galeon_2.0.7-1.2 chmsee_1.0.7-1.2 gnome-python-extras_2.25.3-4.1 xiphos_3.1.2-1 . ALL . -m 'xulrunner (>= 1.9.1.6-2)' Cheers, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please BinNMU 5 packages to fix their dependencies
On Tue, Feb 02, 2010 at 09:39:17AM +0100, Mike Hommey wrote: > Hi, > > The dh_xulrunner script provided by xulrunner 1.9.1.6-1 was broken and > led to packages using it lacking a dependency on xulrunner-1.9.1. > > The script was fixed in 1.9.1.6-2 and to ensure it will continue to work > in the future, I added a test during the xulrunner build. > > I've checked all the build-rdeps using dh_xulrunner and only 5 are > apparently affected. So, please schedule the following binNMUs: > > nmu gluezilla_2.4.3-1 galeon_2.0.7-1.2 chmsee_1.0.7-1.2 > gnome-python-extras_2.25.3-4.1 xiphos_3.1.2-1 . ALL . -m 'Rebuild with fixed > dh_xulrunner, see #567746' > dw gluezilla_2.4.3-1 galeon_2.0.7-1.2 chmsee_1.0.7-1.2 > gnome-python-extras_2.25.3-4.1 xiphos_3.1.2-1 . ALL . -m 'xulrunner (>= > 1.9.1.6-2)' I'm wondering... is the >= syntax properly handled ? 1.9.1.6-2 has been available on (some) architectures for a few days, but none of the packages above have apparently been attempted to be built. Cheers, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please BinNMU 5 packages to fix their dependencies
On Mon, Feb 08, 2010 at 06:57:20PM +0100, Mike Hommey wrote: > On Tue, Feb 02, 2010 at 09:39:17AM +0100, Mike Hommey wrote: > > Hi, > > > > The dh_xulrunner script provided by xulrunner 1.9.1.6-1 was broken and > > led to packages using it lacking a dependency on xulrunner-1.9.1. > > > > The script was fixed in 1.9.1.6-2 and to ensure it will continue to work > > in the future, I added a test during the xulrunner build. > > > > I've checked all the build-rdeps using dh_xulrunner and only 5 are > > apparently affected. So, please schedule the following binNMUs: > > > > nmu gluezilla_2.4.3-1 galeon_2.0.7-1.2 chmsee_1.0.7-1.2 > > gnome-python-extras_2.25.3-4.1 xiphos_3.1.2-1 . ALL . -m 'Rebuild with > > fixed dh_xulrunner, see #567746' > > dw gluezilla_2.4.3-1 galeon_2.0.7-1.2 chmsee_1.0.7-1.2 > > gnome-python-extras_2.25.3-4.1 xiphos_3.1.2-1 . ALL . -m 'xulrunner (>= > > 1.9.1.6-2)' > > I'm wondering... is the >= syntax properly handled ? 1.9.1.6-2 has been > available on (some) architectures for a few days, but none of the > packages above have apparently been attempted to be built. Cyril Brulebois enlighted me with the obvious: the dep-wait should be on xulrunner-dev (>= 1.9.1.6-2), not xulrunner. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please BinNMU 5 packages to fix their dependencies
On Mon, Feb 08, 2010 at 07:39:45PM +, Adam D. Barratt wrote: > On Mon, 2010-02-08 at 19:04 +0100, Mike Hommey wrote: > > On Mon, Feb 08, 2010 at 06:57:20PM +0100, Mike Hommey wrote: > > > On Tue, Feb 02, 2010 at 09:39:17AM +0100, Mike Hommey wrote: > > > > nmu gluezilla_2.4.3-1 galeon_2.0.7-1.2 chmsee_1.0.7-1.2 > > > > gnome-python-extras_2.25.3-4.1 xiphos_3.1.2-1 . ALL . -m 'Rebuild with > > > > fixed dh_xulrunner, see #567746' > > > > dw gluezilla_2.4.3-1 galeon_2.0.7-1.2 chmsee_1.0.7-1.2 > > > > gnome-python-extras_2.25.3-4.1 xiphos_3.1.2-1 . ALL . -m 'xulrunner (>= > > > > 1.9.1.6-2)' > > > > > > I'm wondering... is the >= syntax properly handled ? 1.9.1.6-2 has been > > > available on (some) architectures for a few days, but none of the > > > packages above have apparently been attempted to be built. > > > > Cyril Brulebois enlighted me with the obvious: the dep-wait should be on > > xulrunner-dev (>= 1.9.1.6-2), not xulrunner. > > dep-waits fixed. It seems the nmus haven't triggered on the architectures where xulrunner-dev >= 1.9.1.6-2 is available. Could you check what is happening ? Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100218104312.ga28...@glandium.org
Re: Please BinNMU 5 packages to fix their dependencies
On Thu, Feb 18, 2010 at 11:41:00AM -, Adam D. Barratt wrote: > Mike Hommey wrote: > [...] > >>>>On Tue, Feb 02, 2010 at 09:39:17AM +0100, Mike Hommey wrote: > >>>>>nmu gluezilla_2.4.3-1 galeon_2.0.7-1.2 chmsee_1.0.7-1.2 > >>>>>gnome-python-extras_2.25.3-4.1 xiphos_3.1.2-1 . ALL . -m 'Rebuild > >>>>>with fixed dh_xulrunner, see #567746' dw gluezilla_2.4.3-1 > >>>>>galeon_2.0.7-1.2 chmsee_1.0.7-1.2 gnome-python-extras_2.25.3-4.1 > >>>>>xiphos_3.1.2-1 . ALL . -m 'xulrunner (>= 1.9.1.6-2)' > [...] > >It seems the nmus haven't triggered on the architectures where > >xulrunner-dev >= 1.9.1.6-2 is available. Could you check what is > >happening ? > > Which package / architecture combinations haven't been tried that > you think should have been? > > The archive is still at xulrunner 1.9.1.6-1 for alpha, armel, mips, > powerpc and sparc. So far as I can see, all other architectures have > built all of the binNMUs, with a couple of exceptions for e.g. > gluezilla being not-for-us on mipsel. M I was basing my mail on https://buildd.debian.org/pkg.cgi?pkg=galeon and likewise for others packages, which only show the logs for the non binNMUs version for the ones that are currently not dep-wait. Turns out the buildd site is wrong, since http://packages.debian.org/sid/galeon lists the binNMU versions. Sorry for the noise. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100218121808.ga13...@glandium.org
SRMs: possibe updates for xulrunner/icedove/kompozer on stable
Hi, In case you don't read my blog, it appears that there were hidden issues in the mozilla code base on arm, mips, sparc and powerpc. Question is: should we update the stable packages with the relevant patches ? Cheers, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100223085244.ga8...@glandium.org
Re: Bits from the Release Team: What should go into squeeze?
On Sun, Mar 14, 2010 at 09:42:58PM +0100, Philipp Kern wrote: > Dear fellow developers, > > we all want to get out squeeze as soon as possible. Currently we are > still at 400 bugs concerning the next stable release, with 300 of them not > yet fixed in unstable. > > We would like to know what needs attention, what bugs still need to be > fixed in your package before squeeze is released, which features or new > upstream versions you want to see in squeeze which are not ready yet. > Furthermore we would like to get an overview of the remaining transitions > that need to be done. > > It would be great if every team on track could send us a short mail to > debian-rele...@lists.debian.org. Speaking for the pkg-mozilla team, everything is more or less in shape, except the icedove transition that has not started yet: 3.0.x is expected to be the one shipped with squeeze, but it's still only in experimental. In any case, we don't want to ship 2.0.0.x in squeeze. Iceape is now closely following xulrunner changes on my end, and I expect xulrunner and iceweasel packages to be in a really releasable shape[1] for the 3.5.9 upstream release planned for March 30. The only real blocker is the current set of RC bugs on libnss3, which should be fixed in 3.12.6, which is actually released upstream, but has no official tarball ; I'm planning an upload this week (possibly as soon as today). It would be preferrable if we could use system libraries for liboggplay and libsoundfish, but the former would need some patches and the latter is not even packaged, and unfortunately, the xiph pkg team has not been very responsive. So, except if the release doesn't happen during the next 6 months, I don't think it will be possible. Mike 1. They could very well be released as they are now, but I have a few more stuff I'd like to push in squeeze. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100315073037.ga5...@glandium.org
Re: Icedove transition coming soon (was: Bits from the Release Team: What should go into squeeze?)
On Sat, Mar 20, 2010 at 07:23:54PM +0100, Christoph Goehre wrote: > Hi, > > On Mon, Mar 15, 2010 at 08:30:37AM +0100, Mike Hommey wrote: > > > It would be great if every team on track could send us a short mail to > > > debian-rele...@lists.debian.org. > > > > Speaking for the pkg-mozilla team, everything is more or less in shape, > > except the icedove transition that has not started yet: 3.0.x is > > expected to be the one shipped with squeeze, but it's still only in > > experimental. In any case, we don't want to ship 2.0.0.x in squeeze. > > OK, lets talk about icdove transition. With some help of Mike, I've > prepared the icedove-dev package for icedove 3.0. So it's time to move > icedove from experimental to sid, to be able to release it with squeeze. > We/I'll upload it to unstable until Groupwaremeeting[1] on 17th of > April. > > On the other hand, we have experimental free for versions of icedove > 3.1, which will hopefully released at 1st of June. Guido and I discuss > yesterday the fact, to get a beta/RC version of 3.1 in squeeze. Please don't. Having more mozilla software in the release won't help with security support. > If Mozilla > be in time with its release plan, this would be a additional option. > Also in the face of EOL of 3.0 before ending of security support for > squeeze. 3.1 will also be EOL before the end of security support of squeeze. Going with 3.1 doesn't buy much time-wise. On the other hand, having only one codebase for the mozilla applications we ship (icedove, iceape, iceweasel) *will* help security support. That is why our target is respectively 3.0, 2.0 and 3.5. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100321074022.gb10...@glandium.org
Planned changes to iceweasel/iceape vs. freeze
Hi, I don't remember where I got this idea that the freeze was expected to happen somewhen late this month, but I was taken by surprise by the freeze happening already. Anyways, the mozilla packages I take care of are in a releasable shape already, but there are more changes that I was planning to do some time this month, or at least for next upstream releases, scheduled for september 7th. I'll list these below, please tell me for which I can go forward (hopefully, all ;) ) - Iceweasel and xulrunner are currently two separate source packages, sharing the exact same tarball. It is the result of the packages history, and it would be better if they were merged, for several reasons: - It is a maintenance burden. - I suspect some stable users are not upgrading xulrunner on their stable systems, leaving their iceweasel at risk. Having new iceweasel packages at the same time would allow to force xulrunner upgrade with dependencies. While this can also be done with the current split source packages, it adds a lot of work, especially when there really is no change in the iceweasel package itself. Currently, only xulrunner is updated in stable-security except when there are browser-specific changes (which hasn't happened for a while). - It should allow to run browser-specific tests more easily. Obviously, only the source packages would be merged. All the resulting binary packages would stay the same. - Improve dh_xulrunner to also gather plugin information to, in the long term, help mimic Ubuntu's Xb-Npp-* control fields. - Add an option to dh_xulrunner to add the appropriate xulrunner package to something other than shlibs:Depends. - Add a /usr/lib/xulrunner-devel symlink to /usr/lib/xulrunner-devel- - Add links to nspr-config and nss-config in /usr/lib/xulrunner-devel-1.9.1/bin/, and possibly some other missing files compared to upstream "sdk". - Apply fix for https://bugzilla.mozilla.org/show_bug.cgi?id=504766 (debian bug 591512) - Apply fix for bug 590040. - Add local homepages when upgrading and running for the first time, instead of the pages on http://mozilla.debian.net/ - Improve or remove the restart popup that shows up when upgrading the package. The main problem it is trying to avoid is the impossibility to cleanly close iceweasel after an upgrade. I need to test further, but there are chances this is really only needed when upgrading between major versions. I'm not entirely sure it has a benefit for other cases, though apart from one complaint on planet.debian.org, I saw no feedback... there are a bunch of known issues with it, like with multiple iceweasel windows, or like not activating again when the user doesn't want to restart now but the browser is upgraded again later. - Generate the iceweasel branding from upstream unofficial branding. I spotted a missing file in the current branding, so this would fix this and avoid it happening again in the future. - Improve the situation with search box icons (those showing up in the box on the top right of the UI): the main problem is that the icons had to be removed from the source, because they are not free. The result is that now, the icons are really links to the icons on the original web sites. The problem is that the code surrounding this upstream is not adequate for such use, and the cache is not persistent enough, and a failure to load the icon once results in the icon never been reloaded ever again (except maybe after an upgrade) - Improve the xpcom standalone glue so that it loads the most appropriate version instead of the first one it finds that matches the criterias. - Provide a "generic" xulrunner binary, so that one can run /usr/bin/xulrunner application.ini instead of /usr/bin/xulrunner-1.x application.ini. The most appropriate version would then be used. - Possibly remove the libmozillainterfaces-java package. It is apparently unused, not really maintained upstream (it's even being removed from current trunk, in favor of a separate repository if a maintainer shows up), and more importantly, not tested. Please note that most if not all the changes above will be applied anyways on the 3.6/1.9.2 packages currently in experimental, and 4.0b/2.0b packages in http://mozilla.debian.net/packages. Other than that, as with previous freeze periods, I'd like new upstream (minor) releases to be allowed to go through. Cheers, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100809140615.ga12...@glandium.org
Re: Planned changes to iceweasel/iceape vs. freeze
On Thu, Aug 12, 2010 at 06:32:54AM +0100, Adam D. Barratt wrote: > > - Possibly remove the libmozillainterfaces-java package. It is > > apparently unused, not really maintained upstream (it's even being > > removed from current trunk, in favor of a separate repository if a > > maintainer shows up), and more importantly, not tested. > > My only concern with the removal is that people may be relying on it > locally, although no packages in the archive depend on it. Admittedly > that's not a particularly overriding argument against shipping > unmaintained code in stable. There is also the concern that the xulrunner-1.9.1 package contains the libjavaxpcomglue.so and javaxpcom.jar files that could be used by something else, without using libmozillainterfaces-java, i.e. hidden dependencies. I think the only package that could be relying on these is eclipse, but that'd need to be checked. > and the remainder: > > > - Improve dh_xulrunner to also gather plugin information to, in the long > > term, help mimic Ubuntu's Xb-Npp-* control fields. > > Forgive my ignorance here, but what are the fields in question used for? In Ubuntu, they are used to gather information for the plugin finder service. When firefox encounters a mime-type it doesn't know how to handle in an tag, it asks the plugin finder server what plugin could work for that type. My (long term) idea for Debian is to not rely on a server gathering the information, but on iceweasel checking in the local package database for this information directly. I wanted to have the helper before squeeze so that at least some packages could be filled with that information. The plugin finder service using the packages info could be provided as an external extension when it is ready. > > - Add an option to dh_xulrunner to add the appropriate xulrunner package to > > something other than shlibs:Depends. > > Are there specific use cases for this right now? Probably not for stable, but who knows. I'm going to require that for pyxpcom in experimental. I don't know if pyxpcom can build against xulrunner-1.9.1, but if it does, I'm considering separating it out. But that's still at the blurry idea stage. > > - Improve or remove the restart popup that shows up when upgrading the > > package. The main problem it is trying to avoid is the impossibility > > to cleanly close iceweasel after an upgrade. I need to test further, > > but there are chances this is really only needed when upgrading > > between major versions > > This would imply improving rather than removing, afaics. (As removing > it would presumably still leave the potential for things to go horribly > wrong over a major version update?) IIRC, there is a possibility for iceweasel to stay frozen on an empty popup when you try to close the old version after you upgraded to the new one. I need to check that before deciding if that will be improving rather than removing. > Finally, how large a change to the package do the following items imply? > > > - Generate the iceweasel branding from upstream unofficial branding. I > > spotted a missing file in the current branding, so this would fix this > > and avoid it happening again in the future. That would imply removing a good part of debian/branding and modifying the Makefile or rules to have most of the branding copied over from browser/branding/unofficial. > > - Improve the situation with search box icons (those showing up in the > > box on the top right of the UI): > > the main problem is that the icons had to be removed from the source, > > because they are not free. The result is that now, the icons are > > really links to the icons on the original web sites. The problem is > > that the code surrounding this upstream is not adequate for such use, > > and the cache is not persistent enough, and a failure to load the icon > > once results in the icon never been reloaded ever again (except maybe > > after an upgrade) Until I actually look at how this can be improved, I don't have an idea. The good thing is that the cache doesn't need to be invented, because it already exists. It only isn't persistent enough, and doesn't handle offline on first load cases as mentionned above. I'd expect the patch to be relatively small (especially compared to all the patches already applied) Cheers, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100812115446.ga8...@glandium.org
Re: Planned changes to iceweasel/iceape vs. freeze
On Thu, Aug 12, 2010 at 01:23:32PM +0100, Adam D. Barratt wrote: > On Thu, August 12, 2010 06:32, Adam D. Barratt wrote: > > On Mon, 2010-08-09 at 16:06 +0200, Mike Hommey wrote: > >> - Iceweasel and xulrunner are currently two separate source packages, > >> sharing the exact same tarball. It is the result of the packages > >> history, and it would be better if they were merged, for several > >> reasons: > >> - It is a maintenance burden. > >> - I suspect some stable users are not upgrading xulrunner on their > >> stable systems, leaving their iceweasel at risk. > > As a further comment on this, the reverse dependencies of xulrunner should > also be to tested to ensure that they build and operate correctly against > the combined package. As I wrote, I won't be modifying the generated binary packages. I will make sure the whole content is exactly the same. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100812123217.ga9...@glandium.org
Proxied permission to upload a patched cairo [Was: Bug#502018: Iceweasel rendering problems still exist in Iceweasel 3.5.11 in Sid]
Hi release team, As I've been asked to convince you to allow a new cairo upload with a given patch (see below), here I am ;) A lot of the display issues iceweasel users are experiencing in squeeze are most likely related to the fact that the patch fixing similar issues in lenny was dropped in cairo a long time ago. The patch is a hack around real driver issues, and it would be much better to fix the real driver bugs, but it's very unlikely to happen before squeeze releases. Hell, the situation was already the same for lenny, and these bugs haven't been fixed since then. So, I hereby request that the cairo maintainers be allowed to upload a new cairo version with the patch mentioned below. Thanks, Mike On Fri, Aug 13, 2010 at 06:08:07PM +0200, Sebastian Dröge wrote: > On Fri, 2010-08-13 at 17:59 +0200, Mike Hommey wrote: > > On Fri, Aug 13, 2010 at 05:55:16PM +0200, Sebastian Dröge wrote: > > > On Fri, 2010-08-13 at 10:41 +0200, Mike Hommey wrote: > > > > On Fri, Aug 13, 2010 at 08:59:17AM +0200, BU66ER BAD6ER wrote: > > > > > The Iceweasel rendering problems still exist in Iceweasel 3.5.11 in > > > > > Sid, but only on my ATI Radeon "fglrx" machine, and not on my nVidia > > > > > GeForce "nvidia" box. Some web pages turn all black, with some text > > > > > parts visible. Moving the mouse cursor shows the text (boxes/fields) > > > > > below the cursor but does not render the entire web page. Selecting > > > > > the entire web page (Ctrl-A) shows all text but no other graphics. > > > > > > > > > > The bug can be repeated in Icedove and I have been recommended to > > > > > install the 'experimental' version of libcairo2; but I feel it would > > > > > be better to have this bug fixed in the food chain. > > > > > > > > > > The temporary fix is to use any other browser, as this bug is only > > > > > shown in Iceweasel/Icedove. I run KDE 4.4.5 and have composite turned > > > > > on in my xorg.conf. > > > > > > > > It turns out the patch that was applied on 1.6.4-7 to fix this bug is > > > > *not* applied anymore. The 1.6.4-7 entry is not present in the > > > > changelog, so I suspect it was fixed in one branch and not in the other. > > > > > > > > Dave, could you apply the patch again? > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=49;bug=495620 > > > > > > > > Who knows, it could also fix the various problems with the experimental > > > > cairo. > > > > > > Probably but I don't really like the idea of having yet another release > > > with this workaround for buggy drivers. As long as that workaround is in > > > cairo nobody will ever fix the buggy drivers... > > > > > > If nothing happens before squeeze release on the drivers front. (...) > > > > It hasn't happened since way before lenny released, there is no way this > > will happen in the little time remaining before the squeeze release. > > Yes, unfortunately... and then it will stay again at the same state > until squeeze+1 is frozen ;) > > Oh well, if you can convince the release team that a new cairo upload > with your patch is acceptable I'll do it -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100816084522.ga...@glandium.org
Re: Planned changes to iceweasel/iceape vs. freeze
Hi, On Mon, Aug 09, 2010 at 04:06:15PM +0200, Mike Hommey wrote: > - Possibly remove the libmozillainterfaces-java package. It is > apparently unused, not really maintained upstream (it's even being > removed from current trunk, in favor of a separate repository if a > maintainer shows up), and more importantly, not tested. On top of removing javaxpcom as mentioned above, I would like to get rid of python-xpcom as generated from xulrunner. I already have a package mostly ready for a separated python-xpcom (ITP: #591894), for which I made sure the same codebase as the one embedded in xulrunner is going to be used, and that Luke Faraone already tested with Browse.activity from the olpc stack, cf. http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2010-August/002905.html Would the release team allow me to upload this new package to unstable with the intended goal to have it included in squeeze (or not, if the olpc stack is to be left out of squeeze), in place of the currently xulrunner-generated package ? Cheers, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100817193141.ga31...@glandium.org
Re: RFC: SQLite3 in Squeeze
On Tue, Aug 17, 2010 at 07:49:49PM +0200, Laszlo Boszormenyi wrote: > Hi Release Team, > > There's a problem with SQLite3 3.7.0 in Squeeze. > The version in testing (3.6.23.1-4) was suitable to release. Next major > upstream version (3.7.0) was released, which was uploaded to unstable. > Then freeze happened. The latest release came with problems, like slow > song change with Banshee (reported as #591298 [1]). In that bugreport I > noted that v3.7.0 has a database corruption issue as well and I'm > waiting for v3.7.0.1 to be released. Then I had to travel for some days. > The bad thing is, that Iain Lane was so disappointed with the slow > Banshee song change that he prepared an NMU of SQLite3 with a backported > fix of that slowness. Julien Cristau uploaded his NMU, with high > urgency. Both of them ignored the fact that there's an unfixed database > corruption issue in that NMU. The bad thing is, somehow 3.7.0-1.1 > migrated to Squeeze, even if it was not affected by this bug. As 3.7.0.1 > was released (fixing an other performance regression and the potential > database corruption), I have uploaded it to unstable and it's ready to > migrate. The problem is, the performance regression hit by Banshee is > still present. > > While it would be good to have 3.7.0.1-1 in testing, it's still not > suitable to release because of the latter problem. What should I do? I > don't have package version 3.6.23.1-4 anymore and I don't know when this > bug will be fixed or if it will be easily backportable. FWIW, the corruption may also happen with iceweasel. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100818101524.gb5...@glandium.org
Re: RFC: SQLite3 in Squeeze
On Wed, Aug 18, 2010 at 04:53:01PM +0200, Mehdi Dogguy wrote: > On 08/18/2010 04:34 PM, Julien Cristau wrote: > > > > Sounds like we should go back to 3.6.x in testing and sid. > > > > If we go that way, we will have to rebuild some packages [1] (red ones). > > [1] http://release.debian.org/transitions/Sqlite3.html If only sqlite had a symbols file... Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100818171036.ga7...@glandium.org
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On Mon, Aug 23, 2010 at 04:05:32AM +0200, Matthias Klose wrote: > On 21.08.2010 14:56, Julien Cristau wrote: > >On Fri, Aug 20, 2010 at 19:33:12 +0200, Arthur Loiret wrote: > > > >>Now, to be clear, what nice things would gcc-4.5 bring to our users? > >>There is a complete list here [0], but those ones are, in my opinion, > >>very nice: > >> - The new link time optimiser. > >> - Improved C++0x support. > >> - Plugins support. > >> > >My understanding is that lto in 4.5 is not quite there yet. Not that > >I've tried it or anything. > > I don't share your understanding. I tried it for some builds. Maybe it works on small things, but I heard it doesn't work very well for stuff like mozilla. 4.6 is supposed to get better. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100823080305.ga4...@glandium.org
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On Mon, Aug 23, 2010 at 11:41:40AM +0200, Matthias Klose wrote: > On 23.08.2010 10:03, Mike Hommey wrote: > >On Mon, Aug 23, 2010 at 04:05:32AM +0200, Matthias Klose wrote: > >>On 21.08.2010 14:56, Julien Cristau wrote: > >>>On Fri, Aug 20, 2010 at 19:33:12 +0200, Arthur Loiret wrote: > >>> > >>>>Now, to be clear, what nice things would gcc-4.5 bring to our users? > >>>>There is a complete list here [0], but those ones are, in my opinion, > >>>>very nice: > >>>> - The new link time optimiser. > >>>> - Improved C++0x support. > >>>> - Plugins support. > >>>> > >>>My understanding is that lto in 4.5 is not quite there yet. Not that > >>>I've tried it or anything. > >> > >>I don't share your understanding. I tried it for some builds. > > > >Maybe it works on small things, but I heard it doesn't work very well > >for stuff like mozilla. 4.6 is supposed to get better. > > well, mozilla is not the average package regarding complexity. It > does work well with medium size packages like the python > interpreter, after modifying the build system, showing no > regressions in the python testsuite. so while 4.6 will be better, > 4.5 does work for many cases. Well, maybe it works for python, or at least it doesn't break it, but does it really works as intended, by actually making things better, and not worse, generated-code-wise ? Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100823100359.ga17...@glandium.org
Re: Planned changes to iceweasel/iceape vs. freeze
On Wed, Aug 25, 2010 at 02:58:48PM +0200, Mike Hommey wrote: > These two are the main part of what constitutes 3.5.11-2 currently in > unstable. It would probably make sense for you to start reviewing it, so > that further steps get easier to review. I'm attaching a detailed > analysis of the changes in 3.5.11-2. It would be nice to get it into > testing whenever possible, but that depends on sqlite, and also needs to > wait for python-xpcom getting out of NEW... Now that sqlite3 has transitioned, and considering 3.5.12 is going to be released upstream next week, it would be nice to have 3.5.11-2 transition to testing before I upload 3.5.12 to unstable. A small note about the status file I sent with the previous message (as noticed by Julien Cristau): > - The copyright and watch files were taken from Iceweasel missing Cheers, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100901195804.ga6...@glandium.org
Bug#595215: unblock: pyxpcom/1:0.0~hg20100212-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package pyxpcom As part of what could be called the iceweasel/xulrunner package overhaul, the python-xpcom binary package is now built from the pyxpcom source package. Now that the unified iceweasel is in testing, pyxpcom needs to go in as well for the plan to complete (and for the python-xpcom rdeps to not fall apart when the xulrunner source is removed). unblock pyxpcom/1:0.0~hg20100212-2 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100902062427.3343.1739.report...@jigen.glandium.org
Re: Proxied permission to upload a patched cairo [Was: Bug#502018: Iceweasel rendering problems still exist in Iceweasel 3.5.11 in Sid]
Dear release team, On Tue, Aug 17, 2010 at 05:47:07AM +0200, Sebastian Dröge wrote: > On Mon, 2010-08-16 at 18:54 +0100, Adam D. Barratt wrote: > > On Mon, 2010-08-16 at 10:45 +0200, Mike Hommey wrote: > > > As I've been asked to convince you to allow a new cairo upload with a > > > given patch (see below), here I am ;) > > [...] > > > On Fri, Aug 13, 2010 at 06:08:07PM +0200, Sebastian Dröge wrote: > > > > On Fri, 2010-08-13 at 17:59 +0200, Mike Hommey wrote: > > > > > On Fri, Aug 13, 2010 at 05:55:16PM +0200, Sebastian Dröge wrote: > > [...] > > > > > > Probably but I don't really like the idea of having yet another > > > > > > release > > > > > > with this workaround for buggy drivers. As long as that workaround > > > > > > is in > > > > > > cairo nobody will ever fix the buggy drivers... > > > > > > > > > > > > If nothing happens before squeeze release on the drivers front. > > > > > > (...) > > > > > > > > > > It hasn't happened since way before lenny released, there is no way > > > > > this > > > > > will happen in the little time remaining before the squeeze release. > > > > Well, I'm not going to force the maintainers to include the patch if > > they don't want to but, yes, I'd accept an upload that incorporated that > > patch (preferably without a bunch of unrelated changes that break the > > world as well ;-). > > Well, I asked Mike to ask you because of this patch. It feels dirty to > apply this hack again :/ > > I'll upload a new cairo version with just this patch to unstable soon, > thanks. Please allow that version of cairo (1.8.10-5) into testing. Cheers, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100902143509.ga31...@glandium.org
Pre-approval for next iceweasel upload to unstable
ozilla.debian.net/%LOCALE%/%APP%/%VERSION%/whatsnew/";);
-pref("startup.homepage_welcome_url","http://mozilla.debian.net/%LOCALE%/%APP%/%VERSION%/firstrun/";);
+pref("startup.homepage_override_url","");
+pref("startup.homepage_welcome_url","");
pref("app.releaseNotesURL",
"http://mozilla.debian.net/%LOCALE%/%APP%/%VERSION%/releasenotes/";);
diff --git a/debian/branding/jar.mn b/debian/branding/jar.mn
index aa6839d..017783e 100644
--- a/debian/branding/jar.mn
+++ b/debian/branding/jar.mn
@@ -1,5 +1,7 @@
+#ifndef BRANDING_TEST
ice.jar:
% content ice %content/ice/
% locale ice en-US %locale/en-US/ice/
content/ice/ice.xhtml (ice.xhtml)
locale/en-US/ice/ice.dtd (ice.dtd)
+#endif
diff --git a/debian/changelog b/debian/changelog
index 6693bfa..5c22d98 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,75 @@
+iceweasel (3.5.11-3) UNRELEASED; urgency=low
+
+ * debian/README.Debian: Move to debian/iceweasel.README.Debian.
+ * debian/branding/Makefile.in: Use browser/branding/unofficial/document.png
+instead of browser/app/document.png.
+ * debian/branding/content/*.png.uu (removed),
+debian/branding/content/*-base.png, debian/source/include-binaries,
+debian/branding/content/Makefile.in: Replace .uu files with their binary
+counterpart, now that dpkg-dev supports binary files in the debian/
+directory.
+ * debian/control*:
+- Remove build dependency on sharutils.
+- Install libmozjs debug symbols together with the xulrunner ones.
+ * debian/rules:
+- Refactor file preprocessing.
+- Actually allow the build sequence to start from intermediate stamps.
+- Don't fail to build if the build-xulrunner directory exists.
+- Move .PHONY definitions for test targets to debian/test.mk.
+- Add some sanity checks on version numbers.
+- Use the new DEBIAN_RELEASE variable for dh_gencontrol.
+- Enhance the check-system-libs rule to check in the all autoconf.mk
+ files.
+- Further split build and install process in several stamped steps.
+- Actually set CXX in default case, and re-export it.
+- Move stamps creation at the end, so that "touch" always happens at
+ the end.
+- Separate dh_xulrunner check from dh_install rule for better debugging.
+ * debian/test.mk:
+- Move tests HOME directory into build-xulrunner/dist instead of now
+ nonexistent dist.
+- Don't automatically modify TESTS when TEST_PATH is set.
+- Force armel JIT to compile ARMv4T instructions during tests.
+- Define generic -skip rules for tests.
+- Put all tests requiring an application in a separate variable.
+- Use iceweasel for reftest/crashtest.
+ * debian/reftest-app: Remove our custom reftest-app.
+ * debian/extra-stuff/Makefile.in:
+- Preprocess browser/app/profile/firefox.js before creating places.js.
+ * debian/branding/content/jar.mn: Add missing aboutFooter.png to branding.
+ * debian/rules, debian/noinstall.in: Move testsuite related header field
+removal to noinstall.in.
+ * debian/rules, debian/branding/jar.mn, debian/branding/Makefile.in: Check
+the iceweasel branding installs all files provided by upstream unofficial
+branding.
+ * debian/dh/dh_xulrunner.in:
+- Fix small formatting issue in dh_xulrunner manual page.
+- Remove debug output in dh_xulrunner.
+ * debian/rules, debian/dh/dh_xulrunner_test, debian/dh/dh_xulrunner.in:
+Better check for the dh_xulrunner behaviour.
+ * debian/rules, debian/dh/npapi_getinfo.c, debian/dh/dh_xulrunner.in,
+debian/xulrunner-dev.install.in: New dh_xulrunner feature: return
+plugins handled mime types in a substvar.
+ * debian/xulrunner-dev.links.in: Install a symlink to nspr-config for the
+SDK.
+ * debian/branding/firefox-branding.js: Unset startup.homepage_override_url
+and startup.homepage_welcome_url. In other words, don't display anything
+special after an upgrade or for the first time the browser is started.
+ * debian/xulrunner-GRE_VERSION.postinst.in,
+debian/xulrunner-GRE_VERSION.prerm.in,
+debian/xulrunner-GRE_VERSION.manpages.in,
+debian/xulrunner-stub-GRE_VERSION.1.in: Add a /usr/bin/xulrunner-stub
+binary in the form of an alternative, and a corresponding manual page.
+ * debian/smjs.1, debian/control*: Add a note that smjs is not recommended
+for production use.
+
+ * extensions/auth/nsHttpNegotiateAuth.cpp: Calculate negotiate auth token
+ length after removing padding. bz#592692. Closes: #590040.
+ * gfx/qcms/iccread.c: Fix unaligned reads in qcms. bz#504766.
+Closes: #591512.
+
+ -- Mike Hommey Wed, 01 Sep 2010 22:35:09 +0200
+
iceweasel (3.5.11-2) unstable; urgency=low
[ iceweasel ]
diff --git a/debian/control b/debian/control
index 9a13008..95a1b52 100644
--- a/debian/control
+++ b/debian/control
@@ -39,7 +39,6 @@ Build-Depends: autotools-d
Re: [Pkg-chromium-maint] Chromium 6 in squeeze
On Thu, Sep 02, 2010 at 07:49:21PM -0400, Michael Gilbert wrote: > On Wed, Sep 1, 2010 at 4:24 AM, Giuseppe Iuculano wrote: > > Hi Release Team, > > > > > > In the next few days upstream will release chromium 6 in the stable > > channel. This means that v5 will not receive any further (security) > > update, and v6 will receive security and stability updates. > > > > I could start to backport patches, but unfortunately there are some > > important webkit security issues (SVG related) that are hard to backport > > due to at least one or two major refactoring[1] of the SVG code. > > This means that any future SVG security issue (and unfortunately they > > are frequent) will be hard to fix. > > Is this a supportable approach? Once google discontinues version 6 > after perhaps 2 months from now (5 was only stable for two months or > less), you're going to have to do the hard work of backports. I think > we should be working on making a libwebkit-chrome binary package from > the webkit source so we only need to backport to one webkit codebase. There is absolutely no way this could technically work, except with a whole lot of upstream*s* cooperation, a lot of work, and a whole lot of time. Not going to happen before squeeze. I'm fairly confident this won't be happening before wheezy either. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100903151847.ga21...@glandium.org
Re: Is it too late for iceweasel 3.6.8 in Squeeze?
On Mon, Sep 06, 2010 at 01:46:39AM -0400, Ariel wrote: > > Is it too late to campaign for iceweasel 3.6.8 in Squeeze? > > The reason I ask is that I have never able to play flash videos in > iceweasel (under linux) without stuttering, and random freezes of > the video (but the audio continue). > > Until 3.6.8 > > With 3.6.8 it's been wonderful, videos play perfectly without any > problems. > > Placing the plugin in it's own thread has really been great in many > ways, I can now have multiple pages each with heavy flash items, > without having any slowdown of the browser (since the plugins are > placed on a different CPU core). > > If not, then this will be the first time that debian stable is > released and I need to update to a package in testing on the very > first day. > > This is OK for me, but for any random debian user it's going to look > like linux can't play flash video, and if you google for it you'll > find that this is a VERY common complaint and criticism of linux. Are you volunteering to make all packages depending on xulrunner and libmozjs build and properly work with the xulrunner and libmozjs versions corresponding to iceweasel 3.6? Only once all that is done maybe the release team can decide squeeze would be better with iceweasel 3.6. Not before. I'll just add a note. You're at least the fourth person to come and ask for iceweasel 3.6 in squeeze. It's the fourth time I'm giving the same reasons, yet nothing happens. Even with all the good intention in the world, I can't make it happen alone! Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100906071203.ga3...@glandium.org
Re: Is it too late for iceweasel 3.6.8 in Squeeze?
On Mon, Sep 06, 2010 at 03:17:24AM -0400, Ariel wrote: > > On Mon, 6 Sep 2010, Mike Hommey wrote: > > >On Mon, Sep 06, 2010 at 01:46:39AM -0400, Ariel wrote: > > >Are you volunteering to make all packages depending on xulrunner and > >libmozjs build and properly work with the xulrunner and libmozjs > >versions corresponding to iceweasel 3.6? Only once all that is done > >maybe the release team can decide squeeze would be better with iceweasel > >3.6. Not before. > > Why do you need just xulrunner-1.9.2 in squeeze? I have both > xulrunner-1.9.2 (3.6) and xulrunner-1.9.1 (3.5) installed, and > everything seems to work just fine. Same with libmozjs2d and > libmozjs3d - I have both installed. Are you volunteering to support both xulrunner-1.9.1 and xulrunner-1.9.2 for squeeze lifetime ? Oh by the way, getting iceweasel 3.6 in would mean getting icedove 3.1 in, too, and iceape 2.0 out, for the same reason: we can't support more than one mozilla codebase for the lifetime of a release. Except if people volunteer and actually support them (because saying "I'll do", and not actually doing it is too easy). Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100906072338.ga3...@glandium.org
Re: Pre-approval for next iceweasel upload to unstable
On Thu, Sep 02, 2010 at 04:50:01PM +0200, Mike Hommey wrote: > Hi, > > As stated in another message, next upstream firefox release is scheduled > for next week. On top of (obviously) the upstream changes, I would like > to apply the attached debian changes, to both code and packaging. If everything goes according to plan, I'll be uploading iceweasel 3.5.12-1 in unstable with the attached changes late tomorrow or the following day. Is that going to be okay? Cheers, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100906150433.ga31...@glandium.org
Re: Bug#595881: openoffice.org: FTBFS in squeeze: ERROR: error 65280 occurred while making /build/user-openoffice.org_3.2.1-6-amd64-1k3kmU/openoffice.org-3.2.1 /ooo-build-3-2-1-4/build/OOO320_m19/exte
On Tue, Sep 07, 2010 at 03:50:11AM +0200, Rene Engelhard wrote: > So xulrunner needs to be fixed and/or nspr 4.8.6 unblocked from sid. It will be fixed. The pkg-config files are wrong. They are unfortunately generated using the nspr version as taken from nspr-config --version, that is, the version of nspr used during build. This will be fixed in 3.5.12-1/1.9.1.12-1. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100907070833.gb4...@glandium.org
Re: Bug#595882: vlc: FTBFS in squeeze: configure: error: Please install the Firefox development tools; mozilla-config.h, plugin/npapi.h and plugin/npruntime.h were not found.
On Tue, Sep 07, 2010 at 06:45:24AM +0200, Reinhard Tartler wrote: > On Di, Sep 07, 2010 at 01:42:05 (CEST), Lucas Nussbaum wrote: > > >> Package 'libxul' requires 'nspr >= 4.8.6' but version of NSPR is 4.8.4 > >> Package 'libxul' requires 'nspr >= 4.8.6' but version of NSPR is 4.8.4 > >> checking npfunctions.h usability... no > >> checking npfunctions.h presence... no > >> checking for npfunctions.h... no > >> checking npapi.h usability... no > >> checking npapi.h presence... no > >> checking for npapi.h... no > >> checking for npruntime.h... no > >> configure: error: Please install the Firefox development tools; > >> mozilla-config.h, plugin/npapi.h and plugin/npruntime.h were not found. > >> make: *** [build-stamp] Error 1 > > Well, the reason is given in the configure log. > > >> rmadison -u qa libnspr4-0d > libnspr4-0d |4.7.1-5 |stable | alpha, amd64, arm, armel, hppa, > i386, ia64, mips, mipsel, powerpc, s390, sparc > libnspr4-0d |4.8.4-2 | testing | amd64, armel, hppa, i386, ia64, > kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc > libnspr4-0d |4.8.6-1 | unstable | alpha, amd64, armel, hppa, > hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, > s390, sparc > > Why isn't it in testing? Probably because I didn't ask for it. > >> grep-excuses nspr > nspr (4.8.4-2 to 4.8.6-1) > Maintainer: Maintainers of Mozilla-related packages > 32 days old (needed 10 days) > Not touching package due to block request by freeze (contact > debian-release if update is needed) > Not considered > > > is nspr 4.8.6 going to migrate to squeeze? Please don't, at least yet ; I plan to go through nspr and nss to see if we want them in squeeze. In the meantime, xulrunner-dev is going to be fixed. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100907071000.gc4...@glandium.org
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 01:48:49PM +0200, Stefano Zacchiroli wrote: > [3] A question you might have at this point is: "why you bother about > Chromium and not other packages?". Well, I do bother about all > packages and I'm just trying to anticipate questions I'll might be > asked as soon as Squeeze get released. For instance and for the same > reason, I've proposed just yesterday to mention the removal of Plone > from Squeeze, and the maintainer has kindly agreed to explain the > reasons in the Squeeze release notes. So, I'm not special casing > anything here, and I encourage you to point me to other similar > cases. I think a section of the release notes should include such information. It could also include hints at what we plan to do. I don't know what Giuseppe plans for chromium, but I for one plan to upload newer versions of iceweasel as soon as I can (which might not be as soon as one could hope, due to the xulrunner transition that goes with it). Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908121103.ga31...@glandium.org
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 02:11:03PM +0200, Mike Hommey wrote: > On Wed, Sep 08, 2010 at 01:48:49PM +0200, Stefano Zacchiroli wrote: > > [3] A question you might have at this point is: "why you bother about > > Chromium and not other packages?". Well, I do bother about all > > packages and I'm just trying to anticipate questions I'll might be > > asked as soon as Squeeze get released. For instance and for the same > > reason, I've proposed just yesterday to mention the removal of Plone > > from Squeeze, and the maintainer has kindly agreed to explain the > > reasons in the Squeeze release notes. So, I'm not special casing > > anything here, and I encourage you to point me to other similar > > cases. > > I think a section of the release notes should include such information. > It could also include hints at what we plan to do. I don't know what > Giuseppe plans for chromium, but I for one plan to upload newer versions > of iceweasel as soon as I can (which might not be as soon as one could > hope, due to the xulrunner transition that goes with it). into backports, that is. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908130618.ga...@glandium.org
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 05:17:55PM +0200, Josselin Mouette wrote: > Le mercredi 08 septembre 2010 à 17:09 +0200, Giuseppe Iuculano a écrit : > > On 09/08/2010 05:04 PM, Michael Gilbert wrote: > > > > > I think it is indeed supportable now for squeeze. > > > > What was changed from lenny to now? > > What has changed is that webkit is widely deployed inside and outside > Debian, and for that has undergone a large scrutiny that got rid of much > maintainability issues. > > Furthermore we are shipping the 1.2 branch in squeeze, for which > upstream has explicitly committed to long term support. *hum* the 1.0 branch was supposed to come with long term support, too. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908152647.gb2...@glandium.org
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 11:14:33AM -0400, Joey Hess wrote: > [2] Chromium or iceweasel; take your pick since backports is being > suggested as a delivery mechanism for both. There is a difference with Iceweasel, though, in that squeeze will ship with Iceweasel. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908153039.gc2...@glandium.org
Re: chromium not in Squeeze: a bit of communication needed?
On Wed, Sep 08, 2010 at 12:19:40PM -0400, Joey Hess wrote: > Michael Gilbert wrote: > > A an option in the installer like volatile/security should address a > > lot of this concern. > > Unless it installs the package from backports, the most the installer > can do is eliminate one or two of the three or four things users must > do to use it. All my comments about user discoverability/usability still > apply. > > > > If backports are really officially supported, and we encourage users to > > > install a web browser from them, which is not available in stable, how > > > is that truely different than shipping the same web browser in stable? > > > > The difference is that there is no arduous backporting/dsa process to > > push that update > > If we're encouraging users to install a web browser from an officially > supported part of Debian, then the security support requirements are not > lessened *at all*. Arguably, it's easier to get newest releases of the software as security support into testing and thus backports, than it is to get them in stable. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908164117.gb3...@glandium.org
Bug#596662: unblock: iceweasel/3.5.12-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package iceweasel
The original 3.5.12-1 package had the changes mentionned in
20100902145001.gb31...@glandium.org, 3.5.12-2 added 2 fixes for induced
FTBFSes on hppa and hurd. Both fixes only touch to build scripts, not
code. See the attached debdiff.
unblock iceweasel/3.5.12-2
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru iceweasel-3.5.12/debian/changelog iceweasel-3.5.12/debian/changelog
--- iceweasel-3.5.12/debian/changelog 2010-09-08 09:04:44.0 +0200
+++ iceweasel-3.5.12/debian/changelog 2010-09-11 11:04:53.0 +0200
@@ -1,3 +1,14 @@
+iceweasel (3.5.12-2) unstable; urgency=low
+
+ * config/JarMaker.py: Use errno.ENOENT instead of "2" in JarMaker.py.
+bz#595459. Fixes FTBFS on Hurd.
+ * debian/rules, debian/xulrunner-dev.install.in: Build npapi_getinfo in
+build-xulrunner/dist/bin, and use an RPATH. Some plugins depend on
+libxpcom.so, and dlopen() from npapi_getinfo fails unless libxpcom.so
+can be loaded too. Fixes FTBFS on hppa as a side effect.
+
+ -- Mike Hommey Sat, 11 Sep 2010 09:42:37 +0200
+
iceweasel (3.5.12-1) unstable; urgency=high
* New upstream release.
diff -Nru iceweasel-3.5.12/debian/patches/fixes/Use-errno.ENOENT-instead-of-2-in-JarMaker.py.patch iceweasel-3.5.12/debian/patches/fixes/Use-errno.ENOENT-instead-of-2-in-JarMaker.py.patch
--- iceweasel-3.5.12/debian/patches/fixes/Use-errno.ENOENT-instead-of-2-in-JarMaker.py.patch 1970-01-01 01:00:00.0 +0100
+++ iceweasel-3.5.12/debian/patches/fixes/Use-errno.ENOENT-instead-of-2-in-JarMaker.py.patch 2010-09-11 11:04:40.0 +0200
@@ -0,0 +1,43 @@
+From 3630e5168a6f5be3035210eb07e4fa9f6c52813b Mon Sep 17 00:00:00 2001
+From: Mike Hommey
+Date: Sat, 11 Sep 2010 09:31:09 +0200
+Subject: Use errno.ENOENT instead of "2" in JarMaker.py
+
+https://bugzilla.mozilla.org/show_bug.cgi?id=595459
+---
+ config/JarMaker.py |5 +++--
+ 1 files changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/config/JarMaker.py b/config/JarMaker.py
+index 9bd5111..3029120 100644
+--- a/config/JarMaker.py
b/config/JarMaker.py
+@@ -44,6 +44,7 @@ See the documentation for jar.mn on MDC for further details on the format.
+ import sys
+ import os
+ import os.path
++import errno
+ import re
+ import logging
+ from time import localtime
+@@ -385,7 +386,7 @@ class JarMaker(object):
+ try:
+ os.remove(out)
+ except OSError, e:
+-if e.errno != 2:
++if e.errno != errno.ENOENT:
+ raise
+ return open(out, 'wb')
+ def ensureDirFor(self, name):
+@@ -405,7 +406,7 @@ class JarMaker(object):
+ try:
+ os.remove(out)
+ except OSError, e:
+-if e.errno != 2:
++if e.errno != errno.ENOENT:
+ raise
+ os.symlink(src, out)
+
+--
+1.7.2.rc1.13.gd67bc
+
diff -Nru iceweasel-3.5.12/debian/patches/series iceweasel-3.5.12/debian/patches/series
--- iceweasel-3.5.12/debian/patches/series 2010-09-07 08:56:20.0 +0200
+++ iceweasel-3.5.12/debian/patches/series 2010-09-11 11:04:40.0 +0200
@@ -37,6 +37,7 @@
fixes/Use-syscall-for-mmap-and-munmap-and-disable-ncpus-in.patch
fixes/Calculate-negotiate-auth-token-length-after-removing.patch
fixes/Bug-504766.-qcms-Fix-unaligned-reads-in-qcms.-r-jrmu.patch
+fixes/Use-errno.ENOENT-instead-of-2-in-JarMaker.py.patch
iceweasel-branding/Rename-Firefox-to-Iceweasel.patch
iceweasel-branding/Set-MOZ_APP_NAME-to-iceweasel.patch
iceweasel-branding/Our-name-should-be-Iceweasel-not-Firefox.patch
diff -Nru iceweasel-3.5.12/debian/rules iceweasel-3.5.12/debian/rules
--- iceweasel-3.5.12/debian/rules 2010-09-07 08:53:03.0 +0200
+++ iceweasel-3.5.12/debian/rules 2010-09-11 11:04:52.0 +0200
@@ -84,8 +84,8 @@
debian/dh/dh_xulrunner.1: debian/dh/dh_xulrunner
pod2man -c Debhelper -r $(GRE_VERSION) $^ > $@
-debian/dh/npapi_getinfo: %: %.c
- $(CC) -o $@ $< -Imodules/plugin/base/public -ldl
+build-xulrunner/dist/bin/npapi_getinfo: debian/dh/npapi_getinfo.c
+ $(CC) -o $@ $< -Imodules/plugin/base/public -ldl -Wl,-rpath,\$$ORIGIN
IN_FILES := $(wildcard debian/*.in debian/dh/*.in)
define preprocess
@@ -244,7 +244,7 @@
override_dh_installdocs: MPL
dh_installdocs -A $^
-stamps/dh_install:: debian/dh/dh_xulrunner debian/noinstall debian/dh/npapi_getinfo
+stamps/dh_install:: debian/dh/dh_xulrunner debian/noinstall build-xulrunner/dist/bin/npapi_getinfo
awk '{print "debian/tmp/" $$1 }' < debian/noinstall | xargs rm -r
dh_install --fail-missing
#Install helpers
@@ -284,10 +284,10 @@
# Make sur
Bug#609298: unblock: iceweasel/3.5.16-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package iceweasel The last release contains a few changes that would be nice to have in squeeze, plus reverts a change from previous version that didn't have the expected benefit, plus another one to make lenny backports easier, see the attached debdiff, and the changelog below: * debian/iceweasel.README.Debian: Fix for the default dsp wrapper behaviour. * debian/xulrunner-GRE_VERSION.postinst.in: Revert components registration trigger, it didn't fix anything for python-xpcom. * debian/iceweasel.desktop: Add russian translation. Closes: #608876. Thanks Alexander Sashanov. * debian/control.in, debian/rules, debian/xulrunner-GRE_VERSION.links.in: Use /usr/share/myspell/dicts for dictionaries when building for lenny. Closes: #609111. unblock iceweasel/3.5.16-4 -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nru iceweasel-3.5.16/debian/changelog iceweasel-3.5.16/debian/changelog --- iceweasel-3.5.16/debian/changelog 2010-12-27 11:00:11.0 +0100 +++ iceweasel-3.5.16/debian/changelog 2011-01-07 14:15:14.0 +0100 @@ -1,3 +1,19 @@ +iceweasel (3.5.16-4) unstable; urgency=low + + * debian/iceweasel.README.Debian: Fix for the default dsp wrapper behaviour. + * debian/xulrunner-GRE_VERSION.postinst.in: Revert components registration +trigger, it didn't fix anything for python-xpcom. + * debian/iceweasel.desktop: Add russian translation. Closes: #608876. +Thanks Alexander Sashanov. + * debian/control.in, debian/rules, debian/xulrunner-GRE_VERSION.links.in: +Use /usr/share/myspell/dicts for dictionaries when building for lenny. +Closes: #609111. + + * build/automation.py.in: Add a 2 minutes timeout on automation.py-driven +tests. + + -- Mike Hommey Fri, 07 Jan 2011 14:11:08 +0100 + iceweasel (3.5.16-3) unstable; urgency=low * debian/xulrunner-GRE_VERSION.postinst.in: Trigger components registration diff -Nru iceweasel-3.5.16/debian/control iceweasel-3.5.16/debian/control --- iceweasel-3.5.16/debian/control 2010-12-27 10:44:31.0 +0100 +++ iceweasel-3.5.16/debian/control 2011-01-07 14:08:57.0 +0100 @@ -39,7 +39,8 @@ ttf-freefont, imagemagick, librsvg2-bin, - xsltproc + xsltproc, + lsb-release Build-Conflicts: graphicsmagick-imagemagick-compat, libhildonmime-dev, libosso-dev diff -Nru iceweasel-3.5.16/debian/control.in iceweasel-3.5.16/debian/control.in --- iceweasel-3.5.16/debian/control.in 2010-12-27 10:44:31.0 +0100 +++ iceweasel-3.5.16/debian/control.in 2011-01-07 14:08:57.0 +0100 @@ -39,7 +39,8 @@ ttf-freefont, imagemagick, librsvg2-bin, - xsltproc + xsltproc, + lsb-release Build-Conflicts: graphicsmagick-imagemagick-compat, libhildonmime-dev, libosso-dev diff -Nru iceweasel-3.5.16/debian/iceweasel.desktop iceweasel-3.5.16/debian/iceweasel.desktop --- iceweasel-3.5.16/debian/iceweasel.desktop 2010-12-27 10:44:31.0 +0100 +++ iceweasel-3.5.16/debian/iceweasel.desktop 2011-01-07 13:34:02.0 +0100 @@ -20,6 +20,7 @@ Name[pl]=Iceweasel Name[pt]=Iceweasel Name[pt_BR]=Iceweasel +Name[ru]=Iceweasel Name[sk]=Iceweasel Name[sv]=Iceweasel Comment=Browse the World Wide Web @@ -43,6 +44,7 @@ Comment[pl]=Przeglądanie stron WWW Comment[pt]=Navegue na Internet Comment[pt_BR]=Navegue na Internet +Comment[ru]=Обозреватель Всемирной Паутины Comment[sk]=Prehliadanie internetu Comment[sv]=Surfa på webben GenericName=Web Browser @@ -65,6 +67,7 @@ GenericName[pl]=Przeglądarka WWW GenericName[pt]=Navegador Web GenericName[pt_BR]=Navegador Web +GenericName[ru]=Интернет-браузер GenericName[sk]=Internetový prehliadač GenericName[sv]=Webbläsare X-GNOME-FullName=Iceweasel Web Browser @@ -87,6 +90,7 @@ X-GNOME-FullName[pl]=Przeglądarka WWW Iceweasel X-GNOME-FullName[pt]=Iceweasel Navegador Web X-GNOME-FullName[pt_BR]=Navegador Web Iceweasel +X-GNOME-FullName[ru]=Интернет-браузер Iceweasel X-GNOME-FullName[sk]=Internetový prehliadač Iceweasel X-GNOME-FullName[sv]=Webbläsaren Iceweasel Exec=iceweasel %u diff -Nru iceweasel-3.5.16/debian/iceweasel.README.Debian iceweasel-3.5.16/debian/iceweasel.README.Debian --- iceweasel-3.5.16/debian/iceweasel.README.Debian 2010-12-27 10:44:31.0 +0100 +++ iceweasel-3.5.16/debian/iceweasel.README.Debian 2011-01-07 13:34:02.0 +0100 @@ -20,8 +20,8 @@ Sound - -By default, iceweasel detects and r
Bug#609410: unblock: pyxpcom/1:0.0~hg20100212-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package pyxpcom
This release finally fixes all known install/upgrade issues. The changelog
boils down to this:
* debian/control: Conflicts with xulrunner-1.9.1 <= 1.9.1.11-1.
Closes: #596459.
* debian/prerm.in, debian/postinst.in, debian/install.in: Install
libpyloader.so in /usr/lib/python-xpcom and create a symbolic link
in xulrunner components directory so that component registration
(which we need to trigger by hand) always work. Closes: #582071.
This is the -4 changelog, but the -5 release "only" fixes the changes from -4
so its changelog is largely irrelevant.
debdiff attached.
unblock pyxpcom/1:0.0~hg20100212-5
-- System Information:
Debian Release: 6.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u pyxpcom-0.0~hg20100212/debian/install.in pyxpcom-0.0~hg20100212/debian/install.in
--- pyxpcom-0.0~hg20100212/debian/install.in
+++ pyxpcom-0.0~hg20100212/debian/install.in
@@ -1,5 +1,5 @@
builddir/dist/bin/libpyxpcom.so ##XREDIR##
-builddir/dist/bin/components/libpyloader.so ##XREDIR##/components
+builddir/dist/bin/components/libpyloader.so usr/lib/python-xpcom
builddir/dist/bin/components/pyabout.py ##XREDIR##/components
builddir/dist/bin/python/* usr/lib/##PYVER##/site-packages
builddir/dist/include/PyXPCOM.h ##INCDIR##
diff -u pyxpcom-0.0~hg20100212/debian/changelog pyxpcom-0.0~hg20100212/debian/changelog
--- pyxpcom-0.0~hg20100212/debian/changelog
+++ pyxpcom-0.0~hg20100212/debian/changelog
@@ -1,3 +1,21 @@
+pyxpcom (1:0.0~hg20100212-5) unstable; urgency=low
+
+ * debian/postinst.in: Fix symbolic link destination, and fix the way
+it is created.
+
+ -- Mike Hommey Sat, 08 Jan 2011 11:04:50 +0100
+
+pyxpcom (1:0.0~hg20100212-4) unstable; urgency=low
+
+ * debian/control: Conflicts with xulrunner-1.9.1 <= 1.9.1.11-1.
+Closes: #596459.
+ * debian/prerm.in, debian/postinst.in, debian/install.in: Install
+libpyloader.so in /usr/lib/python-xpcom and create a symbolic link
+in xulrunner components directory so that component registration
+(which we need to trigger by hand) always work. Closes: #582071.
+
+ -- Mike Hommey Fri, 07 Jan 2011 14:40:06 +0100
+
pyxpcom (1:0.0~hg20100212-3) unstable; urgency=low
* debian/control: Replace Pre-Depends with plain dependency for xulrunner.
reverted:
--- pyxpcom-0.0~hg20100212/debian/postinst
+++ pyxpcom-0.0~hg20100212.orig/debian/postinst
@@ -1,10 +0,0 @@
-#!/bin/sh
-
-set -e
-
-# xulrunner trigger needs that to happen before running
-if [ "$1" = "configure" ]; then
- update-python-modules -p
-fi
-
-#DEBHELPER#
diff -u pyxpcom-0.0~hg20100212/debian/control pyxpcom-0.0~hg20100212/debian/control
--- pyxpcom-0.0~hg20100212/debian/control
+++ pyxpcom-0.0~hg20100212/debian/control
@@ -21,6 +21,7 @@
${python:Depends},
${xulrunner:Depends}
Breaks: epiphany-gecko (<< 2.28)
+Conflicts: xulrunner-1.9.1 (<= 1.9.1.11-1)
XB-Python-Version: ${python:Versions}
Description: XPCOM bindings for Python
PyXPCOM allows for communication between Python and XPCOM, such that a
diff -u pyxpcom-0.0~hg20100212/debian/prerm.in pyxpcom-0.0~hg20100212/debian/prerm.in
--- pyxpcom-0.0~hg20100212/debian/prerm.in
+++ pyxpcom-0.0~hg20100212/debian/prerm.in
@@ -3,7 +3,8 @@
set -e
if [ "$1" = "remove" ]; then
-rm -f ##XREDIR##/components/pyabout.pyo
+rm -f ##XREDIR##/components/pyabout.pyo \
+ ##XREDIR##/components/libpyloader.so
fi
#DEBHELPER#
only in patch2:
unchanged:
--- pyxpcom-0.0~hg20100212.orig/debian/postinst.in
+++ pyxpcom-0.0~hg20100212/debian/postinst.in
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+if [ "$1" = "configure" ]; then
+ln -snf ../../python-xpcom/libpyloader.so ##XREDIR##/components/libpyloader.so
+dpkg-trigger ##XREDIR##/components
+fi
+
+#DEBHELPER#
Re: Release notes entry for web browser security support
On Wed, Jan 12, 2011 at 08:50:13PM +0100, Moritz Mühlenhoff wrote: > On Mon, Jan 10, 2011 at 06:47:21PM -0500, Michael Gilbert wrote: > > On Tue, 11 Jan 2011 00:40:42 +0100, Moritz Muehlenhoff wrote: > > > On Mon, Jan 10, 2011 at 11:12:39PM +0100, Josselin Mouette wrote: > > > > Heya, > > > > > > > > Le lundi 10 janvier 2011 à 20:56 +0100, Moritz Muehlenhoff a écrit : > > > > > As such, browsers built upon the webkit, qtwebkit > > > > > and khtml engines are included in Squeeze, but not covered by full > > > > > security > > > > > support. We will make an effort to track down and backport security > > > > > fixes, > > > > > but in general these browsers should not be used against untrusted > > > > > websites. > > > > > > > > I was under the impression that upstream promised long-term maintenance > > > > for the webkit 1.2 branch. It is one of the reasons for which epiphany > > > > was kept as the default browser for GNOME. Is that no longer true? > > > > > > I couldn't find that branch on http://trac.webkit.org/browser , but some > > > digging revealed that there's in fact a stable branch maintained > > > elsewhere: > > > http://gitorious.org/webkitgtk/stable/commits/master > > > > Also http://webkitgtk.org/?page=download. 1.2.6 is now available > > there (vice 1.2.5 in squeeze/sid), and I was going to look at packaging > > it. Not sure if it would be accepted for squeeze at this point though. > > However, it does look like it fixes a bunch of security issues. > > IMO, the same policy should apply as for xulrunner, i.e. introducing the new > stable point releases (as long as they don't break the API, of course). Note that that has been the policy for xulrunner 1.9 in Lenny until upstream dropped support. For squeeze I'm planning not to follow this policy. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110112195818.ga13...@glandium.org
Bug#610076: unblock: nss/3.12.8-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package nss I know this is probably not the right time for this, and I apologize, but I only started actively backporting my packages recently. This new version contains a small change to make backports for lenny not require any change besides a new changelog entry. As I do expect nss updates to squeeze that would also need to be pushed to lenny-backports, it will make my work easier. Thanks. unblock nss/3.12.8-2 -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nru nss-3.12.8/debian/changelog nss-3.12.8/debian/changelog --- nss-3.12.8/debian/changelog 2010-10-07 08:51:49.0 +0200 +++ nss-3.12.8/debian/changelog 2011-01-14 16:15:41.0 +0100 @@ -1,3 +1,12 @@ +nss (3.12.8-2) unstable; urgency=low + + * debian/rules: Fallback to DEB_BUILD_ARCH when dpkg-architecture does't +support DEB_BUILD_ARCH_BITS. + * debian/control: Lower build depends on dpkg-dev to (>= 1.13.19), which +was the value before starting to use DEB_BUILD_ARCH_BITS. + + -- Mike Hommey Fri, 14 Jan 2011 16:07:35 +0100 + nss (3.12.8-1) unstable; urgency=low * New upstream release. diff -Nru nss-3.12.8/debian/control nss-3.12.8/debian/control --- nss-3.12.8/debian/control 2010-10-07 08:20:56.0 +0200 +++ nss-3.12.8/debian/control 2011-01-14 16:15:41.0 +0100 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Maintainers of Mozilla-related packages Uploaders: Mike Hommey -Build-Depends: debhelper (>= 7.0.50~), dpkg-dev (>= 1.15.4), libnspr4-dev (>= 4.8.6), zlib1g-dev, libsqlite3-dev (>= 3.3.9) +Build-Depends: debhelper (>= 7.0.50~), dpkg-dev (>= 1.13.19), libnspr4-dev (>= 4.8.6), zlib1g-dev, libsqlite3-dev (>= 3.3.9) Standards-Version: 3.9.1.0 Homepage: http://www.mozilla.org/projects/security/pki/nss/ Vcs-Git: git://git.debian.org/git/pkg-mozilla/nss.git diff -Nru nss-3.12.8/debian/rules nss-3.12.8/debian/rules --- nss-3.12.8/debian/rules 2010-10-07 08:20:56.0 +0200 +++ nss-3.12.8/debian/rules 2011-01-14 16:15:41.0 +0100 @@ -5,7 +5,7 @@ MOD_MINOR_VERSION := $(word 2, $(subst ., ,$(UPSTREAM_VERSION))) MOD_PATCH_VERSION := $(word 3, $(subst ., ,$(UPSTREAM_VERSION))) -ifeq (64,$(shell dpkg-architecture -qDEB_BUILD_ARCH_BITS)) +ifneq (,$(filter 64 alpha amd64 ia64 s390x,$(shell dpkg-architecture -qDEB_BUILD_ARCH_BITS 2> /dev/null || dpkg-architecture -qDEB_BUILD_ARCH))) USE_64 := USE_64=1 else USE_64 :=
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Fri, Feb 18, 2011 at 01:34:27PM +0100, Mike Hommey wrote: > On Fri, Feb 18, 2011 at 12:59:46PM +0100, Josselin Mouette wrote: > > Le vendredi 18 février 2011 à 10:29 +0100, Benjamin Drung a écrit : > > > I favor a combination of idea one and two, which is: Keep 3.5 in > > > unstable and push the last 4.0 betas/rc to experimental. Push 4.0 to > > > unstable when it's out. > > > > > > Then we have one big break and a tested 4.0 in unstable. > > > > I’d favor that one too. The sooner we can adapt reverse dependencies to > > 4.0 in experimental, the better. And no need to do the work twice. > > There have been almost a year to adapt reverse dependencies to 3.6 in > experimental. And I don't think most rdeps are ready for 3.6. Do you > expect things to be significantly different? Three months later, I see no significant change in the reverse dependencies status. At the moment, we're stuck with 3.5 in testing and unstable, and 4.0 in experimental. This deeply sucks. However, by the time wheezy is released, Firefox will have had several new releases. And the current embedding API (gtkembedmoz) has already been removed from Firefox 5.0, coming in a few weeks. We're obviously not going to maintain xulrunner 1.9.1 or 1.9.2 forever, so at some point, things relying on gtkembedmoz will have to either contribute to mozilla to get a new embedding API that works better for them (it would be about time), or die. Waiting for that to happen, the only solution forward is IMHO to remove packages using gtkembedmoz. Packages relying on xulrunner-dev to build plugins should still be fine, though. As for libmozjs, the API is a fast moving target, and AFAIK, only a few packages such as gjs are following the trend. Others should probably die too. The Debian Mozilla team just doesn't have the resources to handle the situation entirely. We (sic) can't fix all rdeps that can be fixed (here I'm thinking things that can switch to something else than xulrunner, like kazehakase, but I think that one was RMed), and sort out the other rdeps status on our own. Past and present experience suggests that nothing is ever going to happen in experimental, so I guess the only way to get things moving is a painful massive breakage in unstable. What's the release team take? Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110513071942.ga7...@glandium.org
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Fri, May 13, 2011 at 11:56:49AM +0200, Josselin Mouette wrote: > Le vendredi 13 mai 2011 à 09:19 +0200, Mike Hommey a écrit : > > However, by the time wheezy is released, Firefox will have had several > > new releases. And the current embedding API (gtkembedmoz) has already been > > removed from Firefox 5.0, coming in a few weeks. We're obviously not > > going to maintain xulrunner 1.9.1 or 1.9.2 forever, so at some point, > > things relying on gtkembedmoz will have to either contribute to mozilla > > to get a new embedding API that works better for them (it would be about > > time), or die. Waiting for that to happen, the only solution forward is > > IMHO to remove packages using gtkembedmoz. > > Agreed. > > > Packages relying on xulrunner-dev to build plugins should still be fine, > > though. As for libmozjs, the API is a fast moving target, and AFAIK, > > only a few packages such as gjs are following the trend. Others should > > probably die too. > > As for libmozjs, GNOME has 2 reverse deps: gjs and libproxy. > > There has been talk to remove gjs from GNOME and focus on seed, I think > it will happen around GNOME 3.4 - in time for wheezy, but we need to > keep it working in the meantime. > > As for libproxy, we’re waiting for JSCore to be split out of webkit - > this has happened in git master already. Once this is done, we can make > JSCore a hard dependency for libproxy and remove spidermonkey support. Any insight from the release team? Should I stop caring, upload 4.0.1 to unstable, and whatever breaks will have to be dealt with by either removing or fixing? Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110524060013.ga31...@glandium.org
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Tue, May 24, 2011 at 04:44:35PM +0200, Julien Cristau wrote: > On Tue, May 24, 2011 at 08:00:13 +0200, Mike Hommey wrote: > > > Any insight from the release team? > > > What's the list of affected packages? Most libmozjs-dev and xulrunner-dev build-rdeps. Unfortunately, I forgot to get the list of failed builds I had done when recovering from my btrfs problems. That'd take some effort to rebuild such list, but I can tell you that the list of those that didn't fail was quite reduced. So just consider all these build-rdeps at risk. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110524145158.ga18...@glandium.org
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Tue, May 24, 2011 at 04:51:58PM +0200, Mike Hommey wrote: > On Tue, May 24, 2011 at 04:44:35PM +0200, Julien Cristau wrote: > > On Tue, May 24, 2011 at 08:00:13 +0200, Mike Hommey wrote: > > > > > Any insight from the release team? > > > > > What's the list of affected packages? > > Most libmozjs-dev and xulrunner-dev build-rdeps. Unfortunately, I forgot > to get the list of failed builds I had done when recovering from my > btrfs problems. That'd take some effort to rebuild such list, but I can > tell you that the list of those that didn't fail was quite reduced. So > just consider all these build-rdeps at risk. $ build-rdeps xulrunner-dev Reverse Build-depends in contrib: - videolink Found a total of 1 reverse build-depend(s) for xulrunner-dev. Reverse Build-depends in main: -- pyxpcom instantbird ruby-gnome2 vlc gtk-vnc sugar-hulahop mongodb mozzemberek gluezilla firetray kazehakase google-gadgets gnome-chemistry-utils libgtk2-mozembed-perl rhythmbox chmsee gnome-python-extras openvrml moon libjdic-java mozvoikko xiphos gecko-mediaplayer galeon weave libreoffice packagekit swt-gtk icedtea-web totem gjs eclipse gnash openjdk-6 Found a total of 34 reverse build-depend(s) for xulrunner-dev. Reverse Build-depends in non-free: -- No reverse build-depends found for xulrunner-dev. $ build-rdeps libmozjs-dev Reverse Build-depends in contrib: - No reverse build-depends found for libmozjs-dev. Reverse Build-depends in main: -- libjavascript-perl edbrowse couchdb elinks libproxy gjs gxine mediatomb openvrml freej Found a total of 10 reverse build-depend(s) for libmozjs-dev. Reverse Build-depends in non-free: -- No reverse build-depends found for libmozjs-dev. > > Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110524145558.gb18...@glandium.org
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Tue, May 24, 2011 at 04:55:58PM +0200, Mike Hommey wrote: > On Tue, May 24, 2011 at 04:51:58PM +0200, Mike Hommey wrote: > > On Tue, May 24, 2011 at 04:44:35PM +0200, Julien Cristau wrote: > > > On Tue, May 24, 2011 at 08:00:13 +0200, Mike Hommey wrote: > > > > > > > Any insight from the release team? > > > > > > > What's the list of affected packages? > > > > Most libmozjs-dev and xulrunner-dev build-rdeps. Unfortunately, I forgot > > to get the list of failed builds I had done when recovering from my > > btrfs problems. That'd take some effort to rebuild such list, but I can > > tell you that the list of those that didn't fail was quite reduced. So > > just consider all these build-rdeps at risk. And for a real list of packages that are actually broken: by xulrunner-dev/libmozjs-dev 2.0: couchdb edbrowse elinks firetray freej galeon gecko-mediaplayer gluezilla google-gadgets gtk-vnc gxine instantbird kazehakase libgtk2-mozembed-perl libjavascript-perl libjdic-java mediatomb mongodb moon mozvoikko mozzemberek pyxpcom ruby-gnome2 sugar-hulahop swt-gtk videolink weave by xulrunner-dev/libmozjs-dev 5.0: chmsee gjs xiphos I will file corresponding bugs next week, after my VAC, except if someone wants to beat me to it (logs are in http://people.debian.org/~glandium/iceweasel4-transition.logs.tbz2) Note that moon and mediatomb already FTBFS on unstable (bugs already existing) and that moon failure with patches from the corresponding bug applied might actually not be entirely related to xulrunner-dev (though a patched moon builds fine against xulrunner-dev 2.0) Also note that totem and rhythmbox FTBFS in their version currently in unstable, but not for the version in experimental. Also note that there a few other failures that are due to a problem in xulrunner-dev that I fixed locally and will push in next upload, namely https://bugzilla.mozilla.org/show_bug.cgi?id=662223 and https://bugzilla.mozilla.org/show_bug.cgi?id=662224. I don't expect any other of the FTBFSes above to be due to bugs in the mozilla headers. As for the plan forward, considering there will be no upstream security release for 4.0 (5.0 is considered to be that), the plan is to go straight with version 5.0 (last beta available on mozilla.debian.net). Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110606093003.ga15...@glandium.org
Bug#632634: nmu: dehydra_0.9.hg20110609-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu dehydra_0.9.hg20110609-1 . ALL . -m "Rebuild against libmozjs 5.0" -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110704094734.10588.46023.report...@jigen.glandium.org
Bug#632635: nmu: pyxpcom_1:2.0~hg20110502-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu pyxpcom_1:2.0~hg20110502-1 . ALL . -m "Rebuild against xulrunner 5.0" -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110704094810.10650.65116.report...@jigen.glandium.org
Iceweasel 5.0 in unstable
Hi, I just uploaded iceweasel 5.0 to unstable. Sorry for any unexpected disturbance this may bring. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715092554.ga10...@glandium.org
Bug#634156: nmu: openvrml_0.18.8-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu openvrml_0.18.8-4 . ALL . -m "Rebuild against libmozjs-dev 5.0" -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110717103735.5213.15748.report...@jigen.glandium.org
Re: [Openjdk] Bug#636514: icedtea-plugin: obsolete (and unneeded?) dependency on xulrunner-1.9.1
On Thu, Aug 04, 2011 at 08:17:49AM +0200, Matthias Klose wrote: > severity 636514 normal > thanks > > I really do not have any trust in some member of the release team filing this > kind of reports. Please think twice before doing this. > > > On 08/03/2011 07:50 PM, Julien Cristau wrote: > > Package: icedtea-plugin > > Version: 1.1-1 > > Severity: serious > > > > icedtea-plugin depends on xulrunner-1.9.1, which is no longer built in > > unstable. > > > > Also: > > 12:40 < glandium> jcristau: as for icedtea-web, i don't see where it > > depends on > > xulrunner-1.9.1 > > 12:40 < jcristau> http://packages.debian.org/sid/icedtea-plugin > > 12:41 < jcristau> dep: xulrunner-1.9.1 > > 12:42 < glandium> jcristau: i have no idea why it depends on > > xulrunner-1.9.1... > > there's no reason for that > > 12:43 < glandium> it's also stupid, because it makes it necessary to > > install > > xulrunner to benefit the plugin in iceape Just in case that wasn't clear, the glandium mentioned above is me, and that was with my iceweasel maintainer on, which is the source package that was generating xulrunner-1.9.1. Unstable doesn't have xulrunner-1.9.1 anymore, or at least, it's not generated from the source currently in unstable. It's still in unstable but won't for long. Anyways, making plugin packages *depend* on xulrunner, any version, is wrong, because: - webkit browsers don't use xulrunner - all gecko browsers don't use xulrunner (only iceweasel does) FWIW, Ubuntu's package doesn't depend on xulrunner-1.9.1, but instead depends on firefox | chromium-browser | epiphany-browser | midori. Which is just as useless, as this requires people using other browsers (for example, uzbl or conkeror) to install one of these browsers while they don't need it. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110804080436.ga6...@glandium.org
Re: Bug#637195: Package suggests libnotify1
reassign 637195 release.debian.org retitle 637195 nmu: iceweasel_5.0-6 thanks On Tue, Aug 09, 2011 at 12:59:07PM +0200, Laurent Bigonville wrote: > Package: xulrunner-5.0 > Version: 5.0-6 > Severity: normal > User: pkg-gnome-maintain...@lists.alioth.debian.org > Usertags: libnotify0.7-transition > > Dear maintainer, > > Your package is suggesting libnotify1 which will be gone soon. > > I'm not too sure about why xulrunner-5.0 is suggesting it, but if > it's still needed, please transition to libnotify4. It build depends on libnotify-dev, and uses whatever dpkg-shlibdeps would use for Depends for the resulting binary. It happens that it was built against libnotify-dev 0.5.0-2 (see build logs). So, it will need a binNMU, but please don't binNMU it just yet, it's waiting to transition to testing soon. nmu iceweasel_5.0-6 . ALL . -m "Rebuild against libnotify-dev 0.7.3" Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110809112311.gb7...@glandium.org
Bug#638698: BinNMUs for iceweasel 6.0
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu dehydra_0.9.hg20110609-2 . ALL . -m "Rebuild against libmozjs-dev 6.0" dw dehydra_0.9.hg20110609-2 . ALL . -m "libmozjs-dev (>= 6.0)" nmu gjs_1.29.0-1 . ALL . -m "Rebuild against libmozjs-dev 6.0" dw gjs_1.29.0-1 . ALL . -m "libmozjs-dev (>= 6.0)" nmu gxine_0.5.906-1 . ALL . -m "Rebuild against libmozjs-dev 6.0" dw gxine_0.5.906-1 . ALL . -m "libmozjs-dev (>= 6.0)" nmu oolite_1.75.3-1 . ALL . -m "Rebuild against libmozjs-dev 6.0" dw oolite_1.75.3-1 . ALL . -m "libmozjs-dev (>= 6.0)" nmu openvrml_0.18.8-4 . ALL . -m "Rebuild against libmozjs-dev 6.0" dw openvrml_0.18.8-4 . ALL . -m "libmozjs-dev (>= 6.0)" nmu gnome-shell_3.0.2-1 . ALL . -m "Rebuild against libmozjs-dev 6.0" dw gnome-shell_3.0.2-1 . ALL . -m "libgjs-dev (>> 1.29.0-1)" nmu pyxpcom_1:2.0~hg20110502-3 . ALL . -m "Rebuild against xulrunner-dev 6.0" dw pyxpcom_1:2.0~hg20110502-3 . ALL . -m "xulrunner-dev (>= 6.0)" -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110821064132.3611.21834.report...@jigen.glandium.org
Bug#638698: BinNMUs for iceweasel 6.0
On Sun, Aug 21, 2011 at 08:41:32AM +0200, Mike Hommey wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu dehydra_0.9.hg20110609-2 . ALL . -m "Rebuild against libmozjs-dev 6.0" > dw dehydra_0.9.hg20110609-2 . ALL . -m "libmozjs-dev (>= 6.0)" > nmu gjs_1.29.0-1 . ALL . -m "Rebuild against libmozjs-dev 6.0" > dw gjs_1.29.0-1 . ALL . -m "libmozjs-dev (>= 6.0)" > nmu gxine_0.5.906-1 . ALL . -m "Rebuild against libmozjs-dev 6.0" > dw gxine_0.5.906-1 . ALL . -m "libmozjs-dev (>= 6.0)" > nmu oolite_1.75.3-1 . ALL . -m "Rebuild against libmozjs-dev 6.0" > dw oolite_1.75.3-1 . ALL . -m "libmozjs-dev (>= 6.0)" > nmu openvrml_0.18.8-4 . ALL . -m "Rebuild against libmozjs-dev 6.0" > dw openvrml_0.18.8-4 . ALL . -m "libmozjs-dev (>= 6.0)" > nmu gnome-shell_3.0.2-1 . ALL . -m "Rebuild against libmozjs-dev 6.0" > dw gnome-shell_3.0.2-1 . ALL . -m "libgjs-dev (>> 1.29.0-1)" > nmu pyxpcom_1:2.0~hg20110502-3 . ALL . -m "Rebuild against xulrunner-dev 6.0" > dw pyxpcom_1:2.0~hg20110502-3 . ALL . -m "xulrunner-dev (>= 6.0)" Ping? -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110915190659.ga13...@glandium.org
Re: Bug#492927: epiphany-browser: Crashes in GkAtoms_info
On Sun, Nov 30, 2008 at 09:56:40AM +0100, Josselin Mouette wrote: > Le samedi 29 novembre 2008 à 18:30 +, Sam Morris a écrit : > > > Try rebuilding epiphany against xulrunner 1.9.0.4-2 and see if that > > > still happens. > > > > Good news--I haven't seen this crash since rebuilding epiphany against > > xulrunner 1.9.0.4-2. On two different machines. :) > > Dear release team, could you please schedule binNMUs of epiphany-browser > against xulrunner 1.9.0.4-2 ? That should fix #492927. I would also go for a binNMU of chmsee, devhelp, galeon, kazehakase, liferea, and yelp. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503907: diffstat
On Thu, Dec 25, 2008 at 03:43:35PM +, Neil McGovern wrote: > On Wed, Dec 24, 2008 at 12:23:03AM -0500, Asheesh Laroia wrote: > > I have a feeling that the libwebkit currently in sid and lenny is pretty > > broken, from the looks of this bug. > > > > Unfortunately, we don't seem to be able to get much/any response from > the maintainers. It would have been really useful to have a comment > recently. > > > Is there any way that this library can be permitted to enter testing with > > all these changes? > > > > Not really, no. > > > * Find the fix for this issue and backport it on top of 1.0.1-4 > > This would be preferred. > > > * Remove libwebkit-1.0-1 from lenny > > Possible, but not something I'm too happy with given it's popcon. More than its popcon, the real problem is its reverse dependencies, some of which can't be removed without massive work on the packages, because they do provide alternatives (think epiphany, liferea, ...). > > * Simply allow lenny to release with 1.0.1-4 that is this broken. > > > > Could anyone confirm how broken this is? Is it all sites, or a > selection? Maintainers: do you have an opinion on this bug? According to upstream, a new release was due soon after I uploaded to experimental, but hasn't happened yet. I may be part of the reason for the delay because of my lack of time to test the build on all architectures (and the experimental buildd network still hasn't got mips or arm...) According to upstream, still, a lot of bugs have been fixed between 1.0.1 and the version in experimental right now, and FWIW, the BTS already has 5 such crash bugs that are fixed in experimental. Anyways, I think libwebkit-1.0-1 is one of these few packages that it would be good to have in the release, yet we can't guarantee it works properly. Maybe we should have a special "unsupported" section for stable, or we should allow packages to ship with some of their dependencies only fulfilled from unstable, which would state their unsupported status. Anyways, I will check again with upstream what the plans are for this new release and will keep you posted. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#505563: Mozilla Thunderbird Multiple Vulnerabilities
On Wed, Dec 31, 2008 at 04:21:05PM +1100, Mark Purcell wrote: > Thanks Alexander, > > Be advised that the normal approach to fixing a RC bug during lenny deep > freeze is by back porting the fix, rather than uploading the new upstream > release. > > Have debian-release been engaged? We (the mozilla team) don't have the resources nor the time to cherry pick security fixes for mozilla packages. Other people are welcome to join if they wish to do that, but so far, nobody volunteered. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Iceape removal
On Mon, Feb 02, 2009 at 08:03:36PM +0100, Luk Claes wrote: > Moritz Muehlenhoff wrote: > > On 2009-01-28, Luk Claes wrote: > >> Moritz Muehlenhoff wrote: > >>> Luk Claes wrote: > Do you also take care of documenting this in the Release Notes? > >>> I'll do that in the next days. > >> Ok, thanks! > > > > I've filed a bug against release-notes. Do the now obsolete binary > > packages (like iceape-browser) need to be removed by FTP masters? > > It's already removed by FTP masters, iceape just needs to migrate to > have any effect in testing (which won't happen before all reverse deps > are fixed). What do you mean by that? Theorically, there is nothing to do to reverse dependencies. Keeping iceape-dev and iceape-dev-bin ensures they can be built from source, but they shouldn't need rebuilding or any NMU. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Iceape removal
On Mon, Feb 02, 2009 at 10:34:07PM +0100, Luk Claes wrote: > Mike Hommey wrote: > > On Mon, Feb 02, 2009 at 08:03:36PM +0100, Luk Claes wrote: > >> Moritz Muehlenhoff wrote: > >>> On 2009-01-28, Luk Claes wrote: > >>>> Moritz Muehlenhoff wrote: > >>>>> Luk Claes wrote: > >>>>>> Do you also take care of documenting this in the Release Notes? > >>>>> I'll do that in the next days. > >>>> Ok, thanks! > >>> I've filed a bug against release-notes. Do the now obsolete binary > >>> packages (like iceape-browser) need to be removed by FTP masters? > >> It's already removed by FTP masters, iceape just needs to migrate to > >> have any effect in testing (which won't happen before all reverse deps > >> are fixed). > > > > What do you mean by that? Theorically, there is nothing to do to reverse > > dependencies. Keeping iceape-dev and iceape-dev-bin ensures they can be > > built from source, but they shouldn't need rebuilding or any NMU. > > Ah, ok, the better. That just means that the issues listed in > `grep-excuses iceape` need to be solved before it migrates. Which only contains out-of-dates for alpha, hppa, and ia64, where it appears the packages have been built already and only need signing and upload (and apparently, hppa is already uploaded). Coming out smoothly, it seems. Cheers, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Possible unblock request for xulrunner and iceweasel
Hi, I uploaded a new security/stability releases of iceweasel and xulrunner that may be good to have in Lenny, but it might be good to wait and see if no big regression comes with them. Please do as you think is most appropriate considering the timing. Cheers, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: I'd consider this bug very serious
On Thu, Feb 05, 2009 at 01:59:48PM +0100, Raphael Hertzog wrote: > On Thu, 05 Feb 2009, Michael Meskes wrote: > > severity 514132 grave > > thanks > > > > I beg to disagree. This bug will break a lot (my personal guess is about > > 80%) > > of postgresql clusters as the setup Bernd describes is a de facto standard. > > Do you mean that it is a regression compared to etch ? If yes, I agree > that it should be RC. It seems, from the changelog, that this problem has been introduced as a fix to #472627. So this is definitely a regression compared to etch. Considering how far we are from the release, I'd say it would be better to back out the change for #472627, reopen it and ship lenny with that bug. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[SRM] Possible update for nss
Hi,
Bug #509930 makes nss crash on sparc (as reported on our BTS) and ia64
(as reported upstream). It has the bad side effect to make iceweasel and
anything using nss OCSP check. I'm currently uploading a fix to unstable,
but I think it would be a good thing to have this fix in stable, too.
You'll find the (small) patch below. It comes from upstream, as stated
in the changelog, and is safe, as the structure is purely internal to
the library.
What do you think?
Mike
diff --git a/debian/changelog b/debian/changelog
index 90aa93d..de4ba65 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+nss (3.12.0-6) stable-proposed-updates; urgency=low
+
+ * mozilla/security/nss/lib/libpkix/pkix_pl_nss/system/pkix_pl_object.h:
+Apply patch from upstream to fix alignment issues on sparc and ia64.
+Closes: #509930.
+
+ -- Mike Hommey Mon, 06 Apr 2009 20:21:52 +0200
+
nss (3.12.0-5) unstable; urgency=low
* debian/control:
diff --git
a/mozilla/security/nss/lib/libpkix/pkix_pl_nss/system/pkix_pl_object.h
b/mozilla/security/nss/lib/libpkix/pkix_pl_nss/system/pkix_pl_object.h
index 872f169..b683fec 100755
--- a/mozilla/security/nss/lib/libpkix/pkix_pl_nss/system/pkix_pl_object.h
+++ b/mozilla/security/nss/lib/libpkix/pkix_pl_nss/system/pkix_pl_object.h
@@ -71,7 +71,7 @@ extern "C" {
/* PKIX_PL_Object Structure Definition */
struct PKIX_PL_ObjectStruct {
-PKIX_UInt32 magicHeader;
+PRUint64magicHeader;
PKIX_UInt32 type;
PKIX_Int32 references;
PRLock *lock;
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [SRM] Possible update for nss
On Mon, Apr 06, 2009 at 08:48:15PM +0200, Mike Hommey wrote: > Hi, > > Bug #509930 makes nss crash on sparc (as reported on our BTS) and ia64 > (as reported upstream). It has the bad side effect to make iceweasel and > anything using nss OCSP check. I'm currently uploading a fix to unstable, ^ word missing here: crash. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upcoming point releases for oldstable (Etch) and stable (Lenny)
On Wed, Apr 08, 2009 at 10:19:00PM +0200, Luk Claes wrote: > Hi > > This is just to inform you that there will be soon a point release of > Etch: 4.0r8 tomorrow and Lenny: 5.0.1 on Saturday. > > In a point release packages in oldstable or stable will get updated. > Most of these packages will already be in the security archive, though > some of them are fixes for major issues that are not security related or > have less impact from a security point of view. > > More details can be found in the announcements that will be sent to > debian-annou...@l.d.o. If you already want to have an idea about which > packages might be included, please have a look at the preparation pages > [1] [2] If I get an answer to <20090406184815.ga10...@glandium.org>, would it be included in 5.0.1, or is it too late already? Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [SRM] Possible update for nss
On Wed, Apr 22, 2009 at 08:46:08AM +0200, Luk Claes wrote: > Mike Hommey wrote: >> Hi, >> >> Bug #509930 makes nss crash on sparc (as reported on our BTS) and ia64 >> (as reported upstream). It has the bad side effect to make iceweasel and >> anything using nss OCSP check. I'm currently uploading a fix to unstable, >> but I think it would be a good thing to have this fix in stable, too. >> >> You'll find the (small) patch below. It comes from upstream, as stated >> in the changelog, and is safe, as the structure is purely internal to >> the library. >> >> What do you think? > > Please upload. Done. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Webkit build issues
On Tue, Apr 28, 2009 at 09:45:41PM +0200, Adeodato Simó wrote: > I'm told Mike was looking into this, but it indeed looks like circular > Build-Dependencies... The possible long-term solution is to split libJavaScriptCore out of libwebkit, but I don't see that happening in the very near future, a future where we can get these builds to happen quickly. The best I can see for a short-term solution would be to disable the webkit plugin in libproxy, and possibly enable the mozjs one to avoid losing the .pac parsing functionality, but then I'm not sure how webkit will like it. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Webkit build issues
On Wed, Apr 29, 2009 at 03:32:02PM +0200, Josselin Mouette wrote: > Le mercredi 29 avril 2009 à 15:15 +0200, Emilio Pozuelo Monfort a > écrit : > > > Mike, Emilio, can you coordinate so that any sensible solution is > > > implemented reasonably soon? A good number of packages build-depend on > > > libsoup, and none of them will be buildable. Plus the webkit transition > > > can't go forward without it, of course. > > > > I can disable the webkit plugin in libproxy for now, so that things are > > buildable again, and then we can look if everything still works fine (I > > think it > > will). > > It will probably remove the ability to parse proxy.pac files. s/probably// ; that's why i suggested to enable the mozjs plugin in the meanwhile though I'm not sure how it will behave in the same address-space as webkit. > The correct long-term solution is probably to split the plugins out of > the libproxy source. Or, as I said, libJavaScriptCore split out of libwebkit, which seems to be a direction upstream is going to follow. (They apparently already do so on Mac at least) Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote: > Luk Claes schrieb: > > Matthias Klose wrote: > >> Grant Grundler schrieb: > >>> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: > Grant Grundler wrote: > > > > On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote: > > > > http://lists.debian.org/debian-release/2009/04/msg00303.html > Note that it's wrong to assume we will come with the answers. > >>> I was expecting a summary of specific issues from an organization > >>> that claims to operate transperently. The hand waving is easy. But > >>> doesn't resolve problems and doesn't meet my expectation of an "open" > >>> organization that I've donated money, time, and materials to. > >> +1. dropping hppa as a release architecture was not communicated by the > >> release > >> team at all. I did spend some time to get gcj / default-jdk working on > >> hppa, > >> and some money (buying a new disk for a hppa machine) to help this port. > >> The > >> time and the money could have spent better, if d-r would have better > >> communicated about their intent. > > > > There are issues with the hppa port where the release team considered > > dropping it since 2005 communicated to the porter list... > > > >> hppa is not in a good shape, but there are other architectures which are > >> not > >> better (sparc, mips*) from a toolchain point of view. what about these? > > > > I'm not aware of current toolchain issues on sparc and the issues on > > mips* still seem to be manageable, no? > > sparc-biarch defaulting to 32bit isn't supported by upstream; there are > requests > to move to v9 optimization by default, which requires some work in the > compiler. > I don't plan to update this for upcoming GCC versions, and there's no interest > by upstream to help with this kind of setup. You can't buy v8 software for > years > now, but afaik all our machines run 64bit kernels. Maybe it's time to > acknowledge this, remove sparc from the list of release architectures and go > on > with sparc64? Isn't sparc64 a full 64 bits port ? sparc is unfortunately not amd64, where the pros of the added registers overcome the cons of bigger pointers. In other words, 64 bits code is slower, fatter and more memory hungry than 32 bits code on sparc. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Do we want to change libxml2's package name
Hi, While going through the list of bugs for libxml2, I was wondering what to do with #142172, which I tagged wontfix almost 6 years ago, when I became libxml2 maintainer, because of the status quo between the reporter and the previous maintainer. I am now wondering what to do. Doing the change, introducing a transitional package, shouldn't be disruptive. On the other hand, leaving the package as it is is doing no harm besides the policy violation that has been in place for almost a decade. What do you think? Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Do we want to change libxml2's package name
On Mon, Jul 13, 2009 at 07:15:36PM +0200, Luk Claes wrote: > Raphael Hertzog wrote: > > On Mon, 13 Jul 2009, Mike Hommey wrote: > >> I am now wondering what to do. Doing the change, introducing a > >> transitional package, shouldn't be disruptive. On the other hand, > >> leaving the package as it is is doing no harm besides the policy > >> violation that has been in place for almost a decade. > >> > >> What do you think? > > > > I agree with Junichi's last comment. Keep the package name as is and > > update it only next time that the SONAME changes. > > > > Many package do not respect this point of the policy. It should be a > > conventional name to use when you have to rename the package for a SONAME > > change but it should not introduce a useless transition just for > > aesthetics. > > Please don't change package names unless really needed or really > confusing especially with libraries, TIA. I'll just close the bug then. It's useless to keep it wontfix. (and the SONAME is not going to change any time soon) Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote: > On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: > > On 19.08.2009 13:42, Bastian Blank wrote: > >> On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: > >>> I did speak with Martin Zobel at Debconf on how to get there, having two > >>> proposals: > >>> - have an inplace-transition building required library packages for an > >>> upgrade as biarch packages and continue to use the current sparc name. > >> This would mean that many packages needs to be modified. Is it really > >> worth the work needed if we consider the availability of multiarch in > >> the next time? > > you'll end up modifying a different set of packages for the new > > architecture name in control and rules files. I don't know if this is > > less or more work. > > If I understand this correctly, this would need the modification off all > library packages to implement biarch semantic. ... which will be needed anyways. So your choice is actually between doing it and doing it plus some extra intermediate work. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Mozilla plans for the squeeze cycle
On Fri, Aug 21, 2009 at 03:39:55PM +0200, Alexander Sack wrote: > On Sun, Aug 16, 2009 at 02:41:21PM +0200, Marc Brockschmidt wrote: > > Heya, > > > > As announced on dda [RT1], we want to get an impression when releasing > > Squeeze is feasible. We have proposed a (quite ambitious) freeze in December > > 2009, and some developers have noted that their planned changes wouldn't be > > possible in this time frame. So, to find out when releasing would work for > > most people, it would be great if you could answer the following questions: > > > > > * Which major upstream releases of Mozilla/Xulrunner-based software are > > expected in the next two years? Which of those are material for Debian > > stable, which might be a bit flaky? > > firefox 3.6 is currently scheduled for december 2009; i think it would > be worthwhile to get that in before freeze even if its not yet final > at that point; this would help to get a bit longer upstream security > support and would make debian more modern. Also it will probably get > to final during freeze. > > Mozilla does not have any 2 years plans that one could rely on. Last I > know is the general goal to target a ~9 month cycle, but with usual > approach to release when ready (so 3.5 took 12 month). And security support is dropped 6 months after that for the previous release. I.e. Firefox 3.0 security support will be dropped in 4 months. Firefox is also not the only mozilla product we have, and only considering Firefox may be biaised. Thunderbird 3.0 might be expected somewhen soonish in the next few months, as well as Seamonkey 2.0. They will both be based on Gecko 1.9.1, which is the version of Gecko that Firefox 3.5 uses. Getting all these in sync means we share the same codebase in all Mozilla products, which, despite upstream support being dropped earlier may substantially help the security team. Firefox 3.6, on the other hand, relies on Gecko 1.9.2. I, for one, don't want to maintain 2 gecko codebases in the same distribution much longer. But people are free to join the mozilla team and help out. > > * How much time do you usually need from a new upstream release to a > > stable Debian package in unstable? > > > > * How many "big" transitions will the upcoming changes cause? When should > > those > > happen? Can we do something to make them easier? Every new gecko, which we mainly have in xulrunner nowadays, needs some work, though I do hope 3.6 will require less work than 3.5 has and will. ATM, 3.5 is definitely not release-ready, and a lot of work remains to be done: - Build and test rdeps against newer version (applications such as epiphany[1], and plugins) - Patch liboggplay, liboggz, libvorbis, libtheora, etc. with the necessary patches, and make sure it doesn't break other packages. - Build xulrunner against these patched libraries instead of the bundled oned as currently is the case. Once we're done with this, the same will have to done again for 3.6. As the whole depends on more than myself alone, it's hard to give an evaluation on how long these transition will take. I'm not even able to say how long it will take me to get 3.5 itself in shape. Cheers, Mike 1. Note that epiphany may be totally dropping gecko support in the near future (and I hear yelp and devhelp should, too), but that still leaves us with at least galeon and kazehakase. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Mozilla plans for the squeeze cycle
On Fri, Aug 21, 2009 at 09:41:31PM +0200, Mike Hommey wrote: > On Fri, Aug 21, 2009 at 03:39:55PM +0200, Alexander Sack wrote: > > On Sun, Aug 16, 2009 at 02:41:21PM +0200, Marc Brockschmidt wrote: > > > Heya, > > > > > > As announced on dda [RT1], we want to get an impression when releasing > > > Squeeze is feasible. We have proposed a (quite ambitious) freeze in > > > December > > > 2009, and some developers have noted that their planned changes wouldn't > > > be > > > possible in this time frame. So, to find out when releasing would work for > > > most people, it would be great if you could answer the following > > > questions: > > > > > > > > * Which major upstream releases of Mozilla/Xulrunner-based software are > > > expected in the next two years? Which of those are material for Debian > > > stable, which might be a bit flaky? > > > > firefox 3.6 is currently scheduled for december 2009; i think it would > > be worthwhile to get that in before freeze even if its not yet final > > at that point; this would help to get a bit longer upstream security > > support and would make debian more modern. Also it will probably get > > to final during freeze. > > > > Mozilla does not have any 2 years plans that one could rely on. Last I > > know is the general goal to target a ~9 month cycle, but with usual > > approach to release when ready (so 3.5 took 12 month). > > And security support is dropped 6 months after that for the previous > release. I.e. Firefox 3.0 security support will be dropped in 4 months. (leaving the rest of the message for security-team (now CCed)' eyes) Rough estimates have been published for the next Firefox releases, namely 3.6, 3.7 and 4.0. The roadmap is as follows: 3.6 - Q3/Q4 2009 3.7 - Q1/Q2 2010 4.0 - Q3/Q4 2010 What this means is that upstream wants a 6 months release cycle, which means, with 6 months support for previous releases after a new one, that a given release (branch) will only be supported one year. Cheers, Mike > Firefox is also not the only mozilla product we have, and only > considering Firefox may be biaised. > > Thunderbird 3.0 might be expected somewhen soonish in the next few > months, as well as Seamonkey 2.0. They will both be based on Gecko > 1.9.1, which is the version of Gecko that Firefox 3.5 uses. > > Getting all these in sync means we share the same codebase in all > Mozilla products, which, despite upstream support being dropped earlier > may substantially help the security team. > > Firefox 3.6, on the other hand, relies on Gecko 1.9.2. > > I, for one, don't want to maintain 2 gecko codebases in the same > distribution much longer. But people are free to join the mozilla team > and help out. > > > > * How much time do you usually need from a new upstream release to a > > > stable Debian package in unstable? > > > > > > * How many "big" transitions will the upcoming changes cause? When should > > > those > > > happen? Can we do something to make them easier? > > Every new gecko, which we mainly have in xulrunner nowadays, needs some > work, though I do hope 3.6 will require less work than 3.5 has and will. > > ATM, 3.5 is definitely not release-ready, and a lot of work remains to > be done: > - Build and test rdeps against newer version (applications such as > epiphany[1], and plugins) > - Patch liboggplay, liboggz, libvorbis, libtheora, etc. with the > necessary patches, and make sure it doesn't break other packages. > - Build xulrunner against these patched libraries instead of the bundled > oned as currently is the case. > > Once we're done with this, the same will have to done again for 3.6. As > the whole depends on more than myself alone, it's hard to give an > evaluation on how long these transition will take. I'm not even able to > say how long it will take me to get 3.5 itself in shape. > > Cheers, > > Mike > > 1. Note that epiphany may be totally dropping gecko support in the near > future (and I hear yelp and devhelp should, too), but that still leaves > us with at least galeon and kazehakase. > > > -- > To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
On Thu, Sep 03, 2009 at 12:16:53PM +0200, Bastian Blank wrote: > On Thu, Sep 03, 2009 at 11:32:14AM +0200, Martin Grimm wrote: > > So as long as there is no easy manual way to provide anonymized figures > > without installing software on our production servers we can't deliver > > such data :-( > > Hmm. You could collect the /var/lib/dpkg/status files and do a > mass submit with the data out of this files. It would lack the usage > data, but at least shows something. > > Okay, this also depends on the condition that you don't consider the > package names themself sensitive. That could surely grant a wishlist bug for popcon, to allow to, say, only report package names that are found in the debian archive. Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Getting xulrunner 1.9.1 in unstable
Hi, I have some probable good news. Some testing seems to show that while ABI incompatible (stuff built with xulrunner 1.9 don't work quite well with xulrunner 1.9.1), xulrunner 1.9.1 is mostly API compatible and reverse build dependencies seem to be okay with only a few changes (runtime dependency and GRE version range setting for the xulrunner stub). Now, I'd like to know if there is some other ongoing transition that may be disturbed by a possible xulrunner transition, and if the following plan suits you: - Send NMU patches to the BTS for the impacted packages, and have maintainers upload a new release of their package. They would be made to build depend on xulrunner-dev 1.9.1, so that they would only be dep-waiting in the buildd queue. - NMU the (hopefully few) packages remaining unpatched by 27/09. - Upload xulrunner 1.9.1 to unstable on 27/09. Note that by 27/09, most gnome programs currently depending on xulrunner (epiphany, yelp, etc.) should have been made xulrunner free, by the means of the new gnome release[1], so, possibly, they would be out of the transition. Cheers, Mike 1. http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/2009-September/060568.html -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Getting xulrunner 1.9.1 in unstable
Hi, I'm going to go with a slightly more complete plan, hopefully getting xulrunner 1.9.1 in unstable tomorrow: - Send patches for the impacted packages. That has already been done 12 days ago, and some packages have already been updated. - NMU the remaining packages. I will be building the packages today to hopefully upload them today or tomorrow. - Upload xulrunner 1.9.1 to unstable tomorrow. - Request BinNMUs for packages currently depending on libmozjs1d. Cheers, Mike On Wed, Sep 16, 2009 at 08:57:02AM +0200, Mike Hommey wrote: > Hi, > > I have some probable good news. Some testing seems to show that while > ABI incompatible (stuff built with xulrunner 1.9 don't work quite well > with xulrunner 1.9.1), xulrunner 1.9.1 is mostly API compatible and > reverse build dependencies seem to be okay with only a few changes > (runtime dependency and GRE version range setting for the xulrunner > stub). > > Now, I'd like to know if there is some other ongoing transition that may > be disturbed by a possible xulrunner transition, and if the following > plan suits you: > - Send NMU patches to the BTS for the impacted packages, and have > maintainers upload a new release of their package. They would be made > to build depend on xulrunner-dev 1.9.1, so that they would only be > dep-waiting in the buildd queue. > - NMU the (hopefully few) packages remaining unpatched by 27/09. > - Upload xulrunner 1.9.1 to unstable on 27/09. > > Note that by 27/09, most gnome programs currently depending on xulrunner > (epiphany, yelp, etc.) should have been made xulrunner free, by the > means of the new gnome release[1], so, possibly, they would be out of > the transition. > > Cheers, > > Mike > > 1. > http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/2009-September/060568.html > > > -- > To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550519: nmu: mediatomb_0.12.0~svn2018-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu mediatomb_0.12.0~svn2018-4 . ALL . -m "Rebuild for libmozjs transition" The build should be done against libmozjs-dev 1.9.1.3-3. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550518: nmu: openjdk-6_6b16-1.6.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu openjdk-6_6b16-1.6.1-1 . ALL . -m "Rebuild for xulrunner/libmozjs transition" The build should be done against xulrunner-dev 1.9.1.3-3 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550521: nmu: libjavascript-perl_1.12-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu libjavascript-perl_1.12-3 . ALL . -m "Rebuild for libmozjs transition" The build should be done against libmozjs-dev 1.9.1.3-3 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550526: nmu: edbrowse_3.4.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu edbrowse_3.4.1-1 . ALL . -m "Rebuild for libmozjs transition" The build should be done against libmozjs-dev 1.9.1.3-3 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550522: nmu: freej_0.10git20090824-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu freej_0.10git20090824-1 . ALL . -m "Rebuild for xulrunner/libmozjs transition" The build should be done against xulrunner-dev and libmozjs-dev 1.9.1.3-3 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550523: nmu: gxine_0.5.904-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu gxine_0.5.904-2 . ALL . -m "Rebuild for libmozjs transition" The build should be done against libmozjs-dev 1.9.1.3-3 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550525: nmu: elinks_0.12~pre5-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu elinks_0.12~pre5-1 . ALL . -m "Rebuild for libmozjs transition" The build should be done against libmozjs-dev 1.9.1.3-3 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550527: nmu: couchdb_0.9.0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu couchdb_0.9.0-2 . ALL . -m "Rebuild for libmozjs transition" The build should be done against libmozjs-dev 1.9.1.3-3 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550528: nmu: bfilter_1.1.4+svn20090620-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu bfilter_1.1.4+svn20090620-1 . ALL . -m "Rebuild for libmozjs transition" The build should be done against libmozjs-dev 1.9.1.3-3 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550529: nmu: libproxy_0.2.3-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu libproxy_0.2.3-4 . ALL . -m "Rebuild for libmozjs transition" The build should be done against libmozjs-dev 1.9.1.3-3 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Mozilla codebase releases 1.8.1.2 and 1.8.0.10
Hi, Mozilla has released security updates for its 1.8 and 1.8.0 branches, respectively 1.8.1.2 (for Firefox 2.0.0.2) and 1.8.0.10 (for Seamonkey 1.0.8, Thunderbird 1.5.0.10). While on the 1.8 branch, the changes to nspr and nss might not be as substancial, the changes to the 1.8.0 branch consisted in taking new upstream versions: Mozilla version 1.8.0.9 1.8.1.1 1.8.0.10 and 1.8.1.2 NSPR version 4.6.14.6.4 4.6.5 NSS version 3.10.2 3.11.4 3.11.5 The changes between minor versions might mostly be security updates, though I've not have time and probably won't have much to dig into the code and/or upstream CVS. So while we're mostly safe with the iceweasel upgrade, we may be going to introduce new versions of NSPR and NSS if we blindly upgrade to the latest 1.8.0 branch releases. While it may not be a huge problem with iceape and icedove, since they are using their own copies of the libraries, it may be more of a problem for xulrunner which provides libnss and libnspr for other packages to build. I *won't* have time to cherry pick security fixes to make a proper upload involving less risk for the release, so I'm requesting for help: - either be allowed to upload these new versions to the archive - or someone (could be several someones) motivated enough and with a lot of spare time could cherry pick the security fixes for nspr and nss for incorporation in the 1.8.0 branch. I'll let the RMs decide whether iceape and icedove upgrades are less problematic since they don't involve reverse dependencies. The iceweasel upgrade may only involve security fixes and minor enhancements, but I've not looked into the changes yet, but I hope Eric will ;). The only thing I can tell to reassure you is that NSPR and NSS have strong ABI stability requirements, since they are used by closed-source products such as SunOne, so we're probably safe here. OTOH, NSS added some new stuff (such as libfreebl) that may need some care to not mess with, especially on xulrunner, but I've had to deal with it with iceweasel so that's not a big surprise. Cheers, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
