Re: mips64el/mipsel and testing migration
On Sat, Feb 04, 2023 at 05:49:12PM +0200, Adrian Bunk wrote: > On Sat, Feb 04, 2023 at 09:59:23AM -0500, Roberto C. Sánchez wrote: > >... > > If that is the case, then I am puzzled how intelrdfpmath would have > > migrated to testing without being able to build on mips64el/mipsel > > intelrdfpmath having never been built on mips* is not an RC bug or > testing migration blocker for intelrdfpmath since there are no old > binaries of intelrdfpmath in unstable.[1] > I see. > > and > > it makes me think that I might need to be concerned that libmongocrypt > > might not migrate in time. > > libmongocrypt is currently in testing, so the 12th is not a hard > deadline here. > Ah, that's very helpful. I was concerned that there might not be time to resolve this problem. I am grateful to have a little room here to be able to get things properly in order. > > If that is not the case, and the excuses are spurious because the lack > > of availability on mips64el/mipsel won't prevent testing migration, that > > would be good to know as well. > >... > > libmongocrypt does have old binaries on mips* in unstable, > which blocks testing migration of libmongocrypt. > > There are 3 options for handling this: > > 1. Is there a way to build libmongocrypt without intelrdfpmath? > Upstream has mentioned the possibility of being able to build with libdfp. However, I suspect that no action has yet been taken on this as the first step was to get everything working with Intel DFP. I will inquire about this. > 2. Fixing intelrdfpmath on mips* > Seems unlikely. More below. > 3. "reportbug ftp.debian.org" could be used to request removal of the > old mipsel/mips64el binaries of libmongocrypt, but that requires first > making the build dependency in mongo-c-driver exclude architectures > where libmongocrypt is no longer available. > If !pkg.mongo-c-driver.no-libmongocrypt is still a usable configuration, > then [!mipsel !mips64el] could be used there. > OK. This is something I'd rather avoid, but in the event we can't come up with anything else, it might be the only option. > > I will look whether 2. is feasible. intelrdfpmath does build on not > explicitely supported architectures like s390x, and MIPS might be a > victim of explicit support code that is now half-broken. > The mips64el/mipsel builds of intelrdfpmath fail like this: In file included from float128/dpml_ux.h:39, from float128/dpml_ux_bid.c:32: float128/dpml_private.h:215:14: fatal error: mips_macros.h: No such file or directory 215 | #include "mips_macros.h" | ^~~ compilation terminated. Inspecting float128/dpml_private.h I see that it refers to a variety of platform-specific macro headers. Some are present in the source distribution (e.g., ix86, which also covers hppa, amd64, and sparc), while several are #include'd but not present in the source (e.g., mips, cray, vax, and alpha). This helpful comment is present just prior to the #include's: /* Environment specific macro definitions that pre-empt the generic (and perhaps slow) definitions below are in include files per ARCHITECTURE. The macros defined in these files should be a subset of the macros defined below (i.e. if there is a specific version, there should also be a generic version that will work with any ANSI C compiler). [ In practice, we may not get around to writing the generic versions until we need them. ] */ It makes me think that, (a) if they haven't made it around to implementing the missing pieces yet that they never will, and (b) that it might be possible to simply drop the #include for mips and let the slow generic macros be used on mips. In any event, I can file a bug against intelrdfpmath requesting that the maintainer look into that possibility. Regards, -Roberto -- Roberto C. Sánchez
mips64el/mipsel and testing migration
Yesterday a new version of libmongocrypt was uploaded into unstable with the idea that it would migrate into bookwork in time for the freeze. The new package introduces a dependency on libintelrdfpmath-dev. It appears that libintelrdfpmath-dev fails to build on mips64el/mipsel. However, that package seems to not have been inhibited from migrating to testing recently [0]. When I checked the excuses on libmongocrypt this morning I saw: Migration status for libmongocrypt (1.6.2-1 to 1.7.1-2): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: ∙ ∙ libmongocrypt unsatisfiable Build-Depends(-Arch) on mips64el: libintelrdfpmath-dev (>= 2.0u2-6) ∙ ∙ libmongocrypt unsatisfiable Build-Depends(-Arch) on mipsel: libintelrdfpmath-dev (>= 2.0u2-6) ∙ ∙ missing build on mips64el ∙ ∙ missing build on mipsel ∙ ∙ Too young, only 0 of 5 days old Additional info: ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/libm/libmongocrypt.html Not considered The BD-Uninstallable makes sense as libintelrdfpmath-dev is not available on mips64el/mipsel. However, I have not been able to find a definitive list of release architectures for bookworm. The arch qualify page still lists mips64el/mipsel in a way that makes it seem like a release architecture for bookworm. If that is the case, then I am puzzled how intelrdfpmath would have migrated to testing without being able to build on mips64el/mipsel and it makes me think that I might need to be concerned that libmongocrypt might not migrate in time. If that is not the case, and the excuses are spurious because the lack of availability on mips64el/mipsel won't prevent testing migration, that would be good to know as well. Can someone who knows comment on whether mips64el/mipsel are in fact release architectures and/or whether the lack of a successful build on those architectures will in fact prevent testing migration in this case? Regards, -Roberto [0] https://tracker.debian.org/news/1415574/intelrdfpmath-20u2-6-migrated-to-testing/ -- Roberto C. Sánchez
Re: apache2 update for next buster point release?
On Tue, Jun 21, 2022 at 09:44:37AM +0200, Emilio Pozuelo Monfort wrote: > Hi Roberto, > > On 20/06/2022 22:30, Roberto C. Sánchez wrote: > > Hello Release Managers, > > > > I have been working on updating apache2 for stretch. Most of the open > > CVEs affect both the stretch and buster versions of apache2 (in addition > > to the bullseye version). For the buster/bullseye the CVEs have mostly > > been marked " (Minor issue; can be fixed in point release)". > > > > Since buster will shortly transition to LTS, it seems likely that we > > will want an update of apache2 in the final buster point release prior > > to the LTS transition. The info at release.debian.org indicates that a > > buster point release is planned for mid-June, which makes me think one > > could be scheduled anytime. > > The final point release is likely to happen in August. > > > I backported the patches for the CVEs fixed upstream in versions 2.4.53 > > and 2.4.54 and I am proposing an upload as described by the attached > > debdiff. Please let me know if this would be acceptable. If so, I will > > file the appropriate bug in the BTS and then proceed with the upload. > > Please file a buster-pu bug so that the reviews can take place there. > Otherwise this may get lost. > > Also please mention (in that bug) what the risk of regressions is, what kind > of testing you have done (e.g. manual testing, test suite, autopkgtests...). > Thanks for the pointer. I will do as you suggest. Regards, -Roberto -- Roberto C. Sánchez
apache2 update for next buster point release?
Hello Release Managers,
I have been working on updating apache2 for stretch. Most of the open
CVEs affect both the stretch and buster versions of apache2 (in addition
to the bullseye version). For the buster/bullseye the CVEs have mostly
been marked " (Minor issue; can be fixed in point release)".
Since buster will shortly transition to LTS, it seems likely that we
will want an update of apache2 in the final buster point release prior
to the LTS transition. The info at release.debian.org indicates that a
buster point release is planned for mid-June, which makes me think one
could be scheduled anytime.
I backported the patches for the CVEs fixed upstream in versions 2.4.53
and 2.4.54 and I am proposing an upload as described by the attached
debdiff. Please let me know if this would be acceptable. If so, I will
file the appropriate bug in the BTS and then proceed with the upload.
Regards,
-Roberto
P.S. I am not subscribed to either debian-release or debian-apache, so
CCs would be appreciated.
--
Roberto C. Sánchez
diff -Nru apache2-2.4.38/debian/changelog apache2-2.4.38/debian/changelog
--- apache2-2.4.38/debian/changelog 2021-12-21 11:50:43.0 -0500
+++ apache2-2.4.38/debian/changelog 2022-06-20 15:03:00.0 -0400
@@ -1,3 +1,20 @@
+apache2 (2.4.38-3+deb10u8) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * CVE-2022-22719: denial of service in mod_lua via crafted request body.
+ * CVE-2022-22720: HTTP request smuggling.
+ * CVE-2022-22721: integer overflow leading to buffer overflow write.
+ * CVE-2022-23943: heap memory overwrite via crafted data in mod_sed.
+ * CVE-2022-26377: mod_proxy_ajp: Possible request smuggling.
+ * CVE-2022-28614: read beyond bounds via ap_rwrite().
+ * CVE-2022-28615: Read beyond bounds in ap_strcmp_match().
+ * CVE-2022-29404: Denial of service in mod_lua r:parsebody.
+ * CVE-2022-30522: mod_sed denial of service.
+ * CVE-2022-30556: Information Disclosure in mod_lua with websockets.
+ * CVE-2022-31813: mod_proxy X-Forwarded-For dropped by hop-by-hop mechanism.
+
+ -- Roberto C. Sánchez Mon, 20 Jun 2022 15:03:00 -0400
+
apache2 (2.4.38-3+deb10u7) buster-security; urgency=medium
* Fix possible NULL dereference or SSRF in forward proxy configurations
diff -Nru apache2-2.4.38/debian/patches/CVE-2022-22719.patch
apache2-2.4.38/debian/patches/CVE-2022-22719.patch
--- apache2-2.4.38/debian/patches/CVE-2022-22719.patch 1969-12-31
19:00:00.0 -0500
+++ apache2-2.4.38/debian/patches/CVE-2022-22719.patch 2022-06-20
15:03:00.0 -0400
@@ -0,0 +1,95 @@
+From 1b96582269d9ec7c82ee0fea1f67934e4b8176ad Mon Sep 17 00:00:00 2001
+From: Yann Ylavic
+Date: Mon, 7 Mar 2022 14:51:19 +
+Subject: [PATCH] mod_lua: Error out if lua_read_body() or lua_write_body()
+ fail.
+
+Otherwise r:requestbody() or r:parsebody() failures might go unnoticed for
+the user.
+
+
+Merge r1898689 from trunk.
+Submitted by: rpluem
+Reviewed by: rpluem, covener, ylavic
+
+
+git-svn-id:
https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1898694
13f79535-47bb-0310-9956-ffa450edef68
+---
+ modules/lua/lua_request.c | 33 -
+ 1 file changed, 20 insertions(+), 13 deletions(-)
+
+diff --git a/modules/lua/lua_request.c b/modules/lua/lua_request.c
+index 493b2bb431..1eab7b6a47 100644
+--- a/modules/lua/lua_request.c
b/modules/lua/lua_request.c
+@@ -235,14 +235,16 @@ static int lua_read_body(request_rec *r, const char
**rbuf, apr_off_t *size,
+ {
+ int rc = OK;
+
++*rbuf = NULL;
++*size = 0;
++
+ if ((rc = ap_setup_client_block(r, REQUEST_CHUNKED_ERROR))) {
+ return (rc);
+ }
+ if (ap_should_client_block(r)) {
+
+ /**/
+-char argsbuffer[HUGE_STRING_LEN];
+-apr_off_trsize, len_read, rpos = 0;
++apr_off_tlen_read, rpos = 0;
+ apr_off_t length = r->remaining;
+ /**/
+
+@@ -250,18 +252,18 @@ static int lua_read_body(request_rec *r, const char
**rbuf, apr_off_t *size,
+ return APR_EINCOMPLETE; /* Only room for incomplete data chunk :(
*/
+ }
+ *rbuf = (const char *) apr_pcalloc(r->pool, (apr_size_t) (length +
1));
+-*size = length;
+-while ((len_read = ap_get_client_block(r, argsbuffer,
sizeof(argsbuffer))) > 0) {
+-if ((rpos + len_read) > length) {
+-rsize = length - rpos;
+-}
+-else {
+-rsize = len_read;
+-}
+-
+-memcpy((char *) *rbuf + rpos, argsbuffer, (size_t) rsize);
+-rpos += rsize;
++while ((rpos < length)
++ && (len_read = ap_get_client_block(r, (char *) *rbuf + rpos,
++ length - rpos)) > 0) {
++rpos += len_read;
++}
++if (len_read < 0)
Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
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. Regards, -Roberto -- Roberto C. Sánchez
Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
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. Regards, -Roberto -- Roberto C. Sánchez
Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
On Mon, Nov 29, 2021 at 07:54:15PM +0200, Adrian Bunk wrote: > On Mon, Nov 29, 2021 at 05:32:30PM +0100, Julien Cristau wrote: > > > > 2 things: > > - I think we should pick 1.53 if possible, since that's what mozilla use > > for their esr91 binaries > > I was suggesting 1.51 since the smaller the difference to the currently > used version, the lower the risk of new bad surprises when updating > rustc. > > Roberto is doing this primarily for LTS, and for stretch LTS next years > Firefox that will require yet another rustc update will no longer be an > issue. > > The Debian packages of rustc 1.53 in experimental and unstable were > built with LLVM 12, we won't see before it enters stable-pu whether > building rustc 1.53 with LLVM 11 breaks on some architecture (unlikely > but not impossible, especially with the error thresholds). > I concur with Adrian's assessment here. > > - I don't think we need to rename the packages unless there's evidence > > of breakage that can't be easily fixed by either simple patches or > > removing the affected packages. Renamed packages are acceptable but > > that seems like extra work and overhead that may not be necessary. > > We have already learned the hard way that such evidence might appears > after it is too late. > > In bullseye there are > 800 non-Firefox packages build depending on rustc. > > In buster there are "only" around 450 packages build depending on rustc. > One of them is librsvg, which failed to build with last years new rustc > for Firefox. > > The librsvg updated for rustc 1.41 updated for last years Firefox ESR > did build on amd64 but not on ppc64el. > > And BTW, this rustc/firefox misery also blocks the CVE-2019-20446 fix in > librsvg from entering buster. > > Assuming ppc64el will continue to not be part of LTS also for buster, > the easiest solution will be to re-upload the fixed librsvg to > buster-security immediately after LTS starts for buster. > > For rustc 1.41 in buster this is exactly the evidence you are asking for. > And it could not have reasonably be discovered before uploading rustc. > > The lesson learned is that the normal rustc package can no longer be > updated in stable series now that Firefox is no longer the sole user. > I concur with this as well. 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. Regards, -Roberto -- Roberto C. Sánchez
Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
On Sat, Nov 27, 2021 at 05:47:45PM +, Adam D. Barratt wrote: > On Tue, 2021-11-23 at 15:20 -0500, Roberto C. Sanchez wrote: > > In preparing the rustc 1.51 upload/backport (to support backports of > > the > > latest firefox-esr and thunderbird packages) it has been suggested > > that > > to avoid some issues associated with providing a significant new > > version > > of rustc in the rustc binary package (along with the associated > > library > > packages), that I prepare the 1.51 rustc package with a different > > name. > > Following the model of what was done for gcc, nasm, and nodejs, I was > > considering source package rustc-mozilla with a single binary package > > (also rustc-mozilla) to ensure that rdeps don't end up getting > > surprised > > by a new rustc. Would this be considered acceptable for the bullseye > > and buster uploads of rustc 1.51? > > > > I think that sounds sensible, given that bullseye currently has 1.48 > (and buster 1.41). > > As a matter of interest, why was 1.51 the version chosen? I'm mostly > curious as that version is not currently in any suite in Debian. > Hi Adam, I had to make a minor tweak. The source package will still be rustc-mozilla. However, rather than consolidate to a single binary package (which proved to be infeasible for several reasons), I went ahead with simply renaming all the binary packages as either rust-mozilla-*, or rustc-mozilla-*, or librust-mozilla-*, and so on. I am assuming that this is also acceptable, but if it is not, please let me know. The choice of 1.51 was requested by Adrian Bunk, as rustc 1.51 is the (minimum?) version required by FireFox and ThunderBird 91. I will also file a separate bug for the buster-pu companion package. Regards, -Roberto -- Roberto C. Sánchez
Re: Processed: unarchiving 970132
On Sat, Nov 20, 2021 at 01:02:34PM +, Adam D. Barratt wrote:
> Hi,
>
> On Fri, 2021-11-19 at 23:36 +, Debian Bug Tracking System wrote:
> > Processing commands for cont...@bugs.debian.org:
> >
> > > unarchive 970132
> > Bug #970132 {Done: "Adam D. Barratt" }
> > [release.debian.org] buster-pu: package rustc/1.41.1+dfsg1-1~deb10u1
> > Unarchived Bug 970132
>
> I realise this was only unarchived, rather than re-opened, but as I'm
> not sure why you'd do one without intending to do the other - please do
> not re-use the old bug for any further rustc uploads; those should be
> tracked in a new bug.
>
> If I've misunderstood the intention then apologies.
>
Hi Adam,
I was attempting to follow-up with Adrian concerning his last message
about the armel build failure. I downloaded the bug as mbox, then
replied to Adrian and the bug but the reply to the bug was rejected
because it was archived. I tried to unarchive and subscribe then reply
again, but I that didn't work either (it seems because I didn't allow
sufficient time for the unarchive to process before re-sending the
reply).
I definitely intend to open a new bug for the 1.51 upload I am preparing
now. If it would be better for the old bug to be archived and for no
further discussion to take place in that bug, then I can go ahead and
archive it again, or you can.
Regards,
-Roberto
--
Roberto C. Sánchez
Bug#998344: buster-pu: package llvm-toolchain-11/1:11.0.1-2~deb10u1
On Fri, Nov 12, 2021 at 07:32:42PM +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Fri, 2021-11-12 at 14:08 -0500, Roberto C.Sánchez wrote: > > > > Is there anything else that needs to be addressed, or do I have the > > OK to upload? > > Thanks. Please go ahead as far as I'm concerned. > You're welcome and thanks very much for the quick response! I will be uploading shortly. Regards, -Roberto -- Roberto C. Sánchez
Bug#998344: buster-pu: package llvm-toolchain-11/1:11.0.1-2~deb10u1
On Wed, Nov 10, 2021 at 03:54:48PM +0100, Emilio Pozuelo Monfort wrote: > > Thanks for the updated debdiff. Do you have an eta for the mips build? It'd > be nice to have confirmation that that indeed builds fine. > The mips build finished succesfully. (Apologies for the delay in responding.) > btw minor nitpick, but the clang-tools install change isn't mentioned in the > changelog. Would be nice to have that fixed before the actual upload, but no > need to send another debdiff just for that. > I added this to the buster changelog: - Don't install hwasan_symbolize as part of clang-tools package on mips (that particular utility isn't built on mips) Is there anything else that needs to be addressed, or do I have the OK to upload? Regards, -Roberto -- Roberto C. Sánchez
Bug#998344: buster-pu: package llvm-toolchain-11/1:11.0.1-2~deb10u1
On Wed, Nov 10, 2021 at 09:00:50AM +0100, Emilio Pozuelo Monfort wrote: > On 09/11/2021 21:00, Roberto C. Sánchez wrote: > > Hi Adam, > > > > On Wed, Nov 03, 2021 at 02:20:35PM +, Adam D. Barratt wrote: > > > On Tue, 2021-11-02 at 13:28 -0400, Roberto C. Sanchez wrote: > > > > In order to support the update of rustc in buster, which in turn is > > > > needed to support the updates of firefox-esr and thunderbird, I am > > > > proposing an update of llvm-toolchain-11 in buster. The attached > > > > diff represents the change from the current package in the buster- > > > > backports repository. > > > > > > That diff appears to be between the git branches, rather than the > > > generated packages. Would it be possible to have a source debdiff > > > between your base and the package you're planning to upload? > > > > > I rebased my changes on 11.0.1-2 from buster. The debdiff attached to > > this email represents the updated packge I am proposing for upload. > > I think you mean from bullseye? > Yes, quite right. I did in fact mean bullseye. The target suite is buster, but the source package I am basing the update on is from bullseye. I must have confused myself. > > Note that I also updated the version of the proposed package to > > 11.0.1-2+deb10u1. > > That should be 11.0.1-2~deb10u1, to be lower than the version in bullseye. > Again, it appears I successfully confounded myself :-/ I have updated the version to 11.0.1-2~deb10u1 and attached an updated debdiff that reflects the corrected version. Thanks for catching this, Emilio. As a side note, the version I have for the stretch upload is 11.0.1-2~deb9u1. Regards, -Roberto -- Roberto C. Sánchez diff -Nru llvm-toolchain-11-11.0.1/debian/changelog llvm-toolchain-11-11.0.1/debian/changelog --- llvm-toolchain-11-11.0.1/debian/changelog 2021-01-06 14:16:26.0 -0500 +++ llvm-toolchain-11-11.0.1/debian/changelog 2021-10-30 13:14:49.0 -0400 @@ -1,3 +1,11 @@ +llvm-toolchain-11 (1:11.0.1-2~deb10u1) buster; urgency=medium + + * Backport to buster. +- Disable tests on (big endian) mips due to timeout (i.e., test runtime + exceeds 10h). + + -- Roberto C. Sánchez Sat, 30 Oct 2021 13:14:49 -0400 + llvm-toolchain-11 (1:11.0.1-2) unstable; urgency=medium * Fix the changelog diff -Nru llvm-toolchain-11-11.0.1/debian/clang-tools-X.Y.install.in llvm-toolchain-11-11.0.1/debian/clang-tools-X.Y.install.in --- llvm-toolchain-11-11.0.1/debian/clang-tools-X.Y.install.in 2020-11-01 04:19:28.0 -0500 +++ llvm-toolchain-11-11.0.1/debian/clang-tools-X.Y.install.in 2021-10-30 13:14:49.0 -0400 @@ -32,7 +32,7 @@ usr/lib/llvm-@LLVM_VERSION@/bin/clang-move usr/lib/llvm-@LLVM_VERSION@/bin/clang-offload-wrapper -[!armel !armhf !ppc64el !hurd-any !s390x !powerpc !ppc64 !mipsel !mips64el !sparc64 !riscv64] usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/bin/hwasan_symbolize +[!armel !armhf !ppc64el !hurd-any !s390x !powerpc !ppc64 !mips !mipsel !mips64el !sparc64 !riscv64] usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/bin/hwasan_symbolize clang/tools/scan-build-@LLVM_VERSION@ usr/share/clang/ clang/tools/scan-build-py-@LLVM_VERSION@ usr/share/clang/ diff -Nru llvm-toolchain-11-11.0.1/debian/rules llvm-toolchain-11-11.0.1/debian/rules --- llvm-toolchain-11-11.0.1/debian/rules 2021-01-06 03:25:29.0 -0500 +++ llvm-toolchain-11-11.0.1/debian/rules 2021-10-30 13:14:49.0 -0400 @@ -196,7 +196,7 @@ endif # llvm tests timeout, disable it on mipsel -ifeq (mipsel,$(DEB_HOST_ARCH)) +ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel)) RUN_TEST=no endif
Bug#998344: buster-pu: package llvm-toolchain-11/1:11.0.1-2~deb10u1
Hi Adam, On Wed, Nov 03, 2021 at 02:20:35PM +, Adam D. Barratt wrote: > On Tue, 2021-11-02 at 13:28 -0400, Roberto C. Sanchez wrote: > > In order to support the update of rustc in buster, which in turn is > > needed to support the updates of firefox-esr and thunderbird, I am > > proposing an update of llvm-toolchain-11 in buster. The attached > > diff represents the change from the current package in the buster- > > backports repository. > > That diff appears to be between the git branches, rather than the > generated packages. Would it be possible to have a source debdiff > between your base and the package you're planning to upload? > I rebased my changes on 11.0.1-2 from buster. The debdiff attached to this email represents the updated packge I am proposing for upload. Note that I also updated the version of the proposed package to 11.0.1-2+deb10u1. > Part of the reason that we request a debdiff rather than a VCS diff is > that they can often reveal unexpected differences, for instance due to > build system differences. In this case, the diff between the source > package in bullseye and that uploaded to buster-backports includes 128 > generated files under debian/, which shouldn't really be in the source > package. > > > As a result of mips build failures with the backport package, I am > > running a test build on a mips porter box to verify that the mips > > changes result in a successfully built package. > > How did that go? > It failed at the very end, but the failure seems to be spurious. That is, I did a full build (dpkg-buildpackage with no options) rather than an arch:any build. Some components are not built for mips (and other architectures) and trying to build arch:all packages on those architectures would actually fail because the components end up not being built. I started a new build with the --build=any option to dpkg-builpackage. If you would like to wait for the result of that build, I am happy to wait on uploading. However, I am confident that the changes I have in the attached debdiff are completely ready for upload. Regards, -Roberto -- Roberto C. Sánchez diff -Nru llvm-toolchain-11-11.0.1/debian/changelog llvm-toolchain-11-11.0.1/debian/changelog --- llvm-toolchain-11-11.0.1/debian/changelog 2021-01-06 14:16:26.0 -0500 +++ llvm-toolchain-11-11.0.1/debian/changelog 2021-10-30 13:14:49.0 -0400 @@ -1,3 +1,11 @@ +llvm-toolchain-11 (1:11.0.1-2+deb10u1) buster; urgency=medium + + * Backport to buster. +- Disable tests on (big endian) mips due to timeout (i.e., test runtime + exceeds 10h). + + -- Roberto C. Sánchez Sat, 30 Oct 2021 13:14:49 -0400 + llvm-toolchain-11 (1:11.0.1-2) unstable; urgency=medium * Fix the changelog diff -Nru llvm-toolchain-11-11.0.1/debian/clang-tools-X.Y.install.in llvm-toolchain-11-11.0.1/debian/clang-tools-X.Y.install.in --- llvm-toolchain-11-11.0.1/debian/clang-tools-X.Y.install.in 2020-11-01 04:19:28.0 -0500 +++ llvm-toolchain-11-11.0.1/debian/clang-tools-X.Y.install.in 2021-10-30 13:14:49.0 -0400 @@ -32,7 +32,7 @@ usr/lib/llvm-@LLVM_VERSION@/bin/clang-move usr/lib/llvm-@LLVM_VERSION@/bin/clang-offload-wrapper -[!armel !armhf !ppc64el !hurd-any !s390x !powerpc !ppc64 !mipsel !mips64el !sparc64 !riscv64] usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/bin/hwasan_symbolize +[!armel !armhf !ppc64el !hurd-any !s390x !powerpc !ppc64 !mips !mipsel !mips64el !sparc64 !riscv64] usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/bin/hwasan_symbolize clang/tools/scan-build-@LLVM_VERSION@ usr/share/clang/ clang/tools/scan-build-py-@LLVM_VERSION@ usr/share/clang/ diff -Nru llvm-toolchain-11-11.0.1/debian/rules llvm-toolchain-11-11.0.1/debian/rules --- llvm-toolchain-11-11.0.1/debian/rules 2021-01-06 03:25:29.0 -0500 +++ llvm-toolchain-11-11.0.1/debian/rules 2021-10-30 13:14:49.0 -0400 @@ -196,7 +196,7 @@ endif # llvm tests timeout, disable it on mipsel -ifeq (mipsel,$(DEB_HOST_ARCH)) +ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel)) RUN_TEST=no endif
Bug#993133: bullseye-pu: package shiro/1.3.2-4+deb11u1
I removed the top line of the change log (the security team reference), rebuilt, and re-uploaded. Thanks again for all the help and for your patience with my mistake. Regards, -Roberto -- Roberto C. Sánchez
Bug#993134: buster-pu: package shiro/1.3.2-4+deb10u1
I removed the top line of the change log (the security team reference), rebuilt, and re-uploaded. Thanks again for all the help and for your patience with my mistake. Regards, -Roberto -- Roberto C. Sánchez
Bug#993134: buster-pu: package shiro/1.3.2-4+deb10u1
On Sun, Aug 29, 2021 at 05:17:02PM +0100, Adam D. Barratt wrote: > > As it turns out, the bullseye upload is still sat on upload.d.o, > because: > > Aug 29 15:31:17 processing /shiro_1.3.2-4+deb11u1_source.changes > Aug 29 15:31:17 shiro_1.3.2.orig.tar.xz doesn't exist (ignored for now) > > My assumption is that both of your .changes reference the same > .orig.tar.xz. If they were uploaded close together, then the queue > daemon will have removed the .orig from the queue together with the > files from the buster upload, thus stranding the bullseye upload. Yes, they reference the same .orig.tar.gz and I uploaded simultaneously. > To > avoid this, either space the uploads further apart, or don't include > the .orig in more than one of them - in fact, if the upstream tarball > is the same as is already in the archive, you don't need to include it > in either. > Is this because the upload is going to the main FTP archive, rather than the security archive first? It seems that the "always use -sa to build a u1 update" needs to only be for uploads targeted at security.d.o. > In this case, you'll either need to dcut the remaining files from the > previous upload, or wait for the queue daemon to delete them on its > own. > > I've flagged the buster upload for rejection, once dak notices, so feel > free to re-upload that once you receive the rejection confirmation (and > bullseye once it times out, or you dcut it). > Great! Thanks for the info, as the single REJECT seemed strange when I was expecting two of them. Regards, -Roberto -- Roberto C. Sánchez
Bug#993134: buster-pu: package shiro/1.3.2-4+deb10u1
On Fri, Aug 27, 2021 at 08:33:44PM +0100, Adam D. Barratt wrote: > On Fri, 2021-08-27 at 13:45 -0400, Roberto C. Sanchez wrote: > > I have prepared an update for shiro in buster. This has been > > coordinated with the package maintainer and at the recommendation of > > the > > security team and with their concurrence, it is being proposed for > > the > > next buster point release. > > +shiro (1.3.2-4+deb10u1) buster; urgency=medium > + > + * Non-maintainer upload by the Security Team. > > fwiw, I at least find it a little confusing to have debdiffs claim to > be uploads by the Security Team when they were neither produced (so far > as I can tell) nor uploaded by that team, nor released via the security > archive. > Quite right. I originally prepared the uploads as security updates, but then changed course to the point release route. Would you like to REJECT the uploads and I can upload again with a fixed changelog? Regards, -Roberto -- Roberto C. Sánchez
Bug#984896: buster-pu: package jquery/3.3.1~dfsg-3
On Wed, Mar 17, 2021 at 07:39:08PM +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Tue, 2021-03-09 at 18:08 -0500, Roberto C. Sanchez wrote: > > I would like to fix CVE-2020-11022 and CVE-2020-11023. The same fix > > has > > been prepared for stretch and will be uploaded concurrently with the > > buster fix. The security team has marked these issues as no-dsa. > > > > Please go ahead. > Thanks! (Also thanks for the additional prod). I have just uploaded. Regards, -Roberto -- Roberto C. Sánchez
Bug#912531: stretch-pu: package exiv2/0.25-3.1+deb9u2
On Mon, Jun 22, 2020 at 01:55:35PM +0200, Salvatore Bonaccorso wrote: > Hi Roberto, > > On Mon, Jun 15, 2020 at 04:05:15PM -0400, Roberto C. Sánchez wrote: > > On Mon, Jun 15, 2020 at 08:28:14PM +0100, Adam D. Barratt wrote: > > > Control: tags -1 -moreinfo + confirmed > > > > > > On Thu, 2018-11-01 at 21:07 -0400, Roberto C.Sánchez wrote: > > > > On Thu, Nov 01, 2018 at 06:50:53PM +, Adam D. Barratt wrote: > > > > > Control: tags -1 + moreinfo > > > > > > > > > > On Wed, 2018-10-31 at 23:25 -0400, Roberto C. Sanchez wrote: > > > > > > I have prepared an update for exiv2 in jessie (0.24-4.1+deb8u2) > > > > > > related to CVE-2018-16336 and also including a minor fix to the > > > > > > previous patch for CVE-2018-10958 and CVE-2018-10999. > > > > > > > > > > The Security Tracker indicates that CVE-2018-16336 is as-yet > > > > > unfixed in unstable; is that correct? > > > > > > > > > Hi Adam, > > > > > > > > That is correct. I completely overlooked it. I will check with the > > > > maintainers about their plans for unstable. > > > > > > > > > > It looks like that eventually happened, early this year(!). > > > > > > If this is still something that you're interested in fixing for > > > stretch, please go ahead. > > > > > The work has already been done, so I will go ahead with an upload > > shortly. > > Given the target fix now for 9.13, can you as well do a corresponding > buster update to avoid a regression from updates from stretch to > buster? > The upstream version for exiv2 is the same in buster and stretch, so I think it should be a trivial update. I will upload exiv2 0.25-4+deb10u1 targeted at suite "buster" within the next 24 hours. Regards, -Roberto -- Roberto C. Sánchez
Bug#912531: stretch-pu: package exiv2/0.25-3.1+deb9u2
On Mon, Jun 15, 2020 at 08:28:14PM +0100, Adam D. Barratt wrote: > Control: tags -1 -moreinfo + confirmed > > On Thu, 2018-11-01 at 21:07 -0400, Roberto C.Sánchez wrote: > > On Thu, Nov 01, 2018 at 06:50:53PM +, Adam D. Barratt wrote: > > > Control: tags -1 + moreinfo > > > > > > On Wed, 2018-10-31 at 23:25 -0400, Roberto C. Sanchez wrote: > > > > I have prepared an update for exiv2 in jessie (0.24-4.1+deb8u2) > > > > related to CVE-2018-16336 and also including a minor fix to the > > > > previous patch for CVE-2018-10958 and CVE-2018-10999. > > > > > > The Security Tracker indicates that CVE-2018-16336 is as-yet > > > unfixed in unstable; is that correct? > > > > > Hi Adam, > > > > That is correct. I completely overlooked it. I will check with the > > maintainers about their plans for unstable. > > > > It looks like that eventually happened, early this year(!). > > If this is still something that you're interested in fixing for > stretch, please go ahead. > The work has already been done, so I will go ahead with an upload shortly. Regards, -Roberto -- Roberto C. Sánchez
Bug#956535: buster-pu: package php-horde-data/2.1.4-5+deb10u1
On Tue, Apr 21, 2020 at 06:55:41PM +0100, Adam D. Barratt wrote: > On Sun, 2020-04-19 at 16:39 -0400, Roberto C.Sánchez wrote: > > Hi Mathieu & Adam, > > > > On Wed, Apr 15, 2020 at 03:07:00PM +0200, Mathieu Parent (Debian) > > wrote: > > > > > > Thanks Roberto! > > > > > > Hello Salvatore, > > > > > > > Mathieu, but are you still planning to request removals? > > > > > > Done as #956808. > > > > > Given that the removal has been requested, I'll not prepare new > > uploads for unstable. Adam, could you weigh in on whether I may > > proceed with the uploads (all six) or whether I need to wait for the > > removal to take place? > > On the assumption that the removal won't take too long, please go > ahead. > Thanks. I have uploaded to ftp-master. However, I did notice one peculiarity. I had this near the end of the output: ** Uploading php-horde-data_2.1.4.orig.tar.gz Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. ** That is interesting because I noticed that one of the packages, php-horde-data, had the same upstream version, 2.1.4, for both stretch and buster. Since this was the first stable update for both, I built them each with -sa to include the .orig.tar.gz. I guess it will be evident soon whether that is a problem when I receive the receipt message from dak, but I thought to bring it up just in case. Regards, -Roberto -- Roberto C. Sánchez
Bug#956535: buster-pu: package php-horde-data/2.1.4-5+deb10u1
Hi Mathieu & Adam, On Wed, Apr 15, 2020 at 03:07:00PM +0200, Mathieu Parent (Debian) wrote: > > > Thanks Roberto! > > Hello Salvatore, > > > Mathieu, but are you still planning to request removals? > > Done as #956808. > Given that the removal has been requested, I'll not prepare new uploads for unstable. Adam, could you weigh in on whether I may proceed with the uploads (all six) or whether I need to wait for the removal to take place? Regards, -Roberto -- Roberto C. Sánchez
Bug#956535: buster-pu: package php-horde-data/2.1.4-5+deb10u1
On Tue, Apr 14, 2020 at 10:04:00PM +0200, Salvatore Bonaccorso wrote: > Control: tags -1 - moreinfo > > Hi Adam, > > On Sun, Apr 12, 2020 at 10:05:55PM +0100, Adam D. Barratt wrote: > > Control: tags -1 + moreinfo > > > > On Sun, 2020-04-12 at 09:23 -0400, Roberto C. Sanchez wrote: > > > Please find attached a proposed debdiff for php-horde-data. The > > > change fixes CVE-2020-8518, which the security team has classified as > > > , deeming it a minor issue which can be fixed via a point > > > release. > > > > The Security Tracker indicates that this issue affects the package in > > unstable and is not yet fixed there; is that correct? > > This is correct, the issue has not been fixed in unstable "yet". The > horde ecosystem is currently unmaintained, and previous maintainer > indicated to ask actually for removal if nobody steps up. See #942282 > for context. > > That said, it's possible to either wait for a fix in unstable or the > removal of the php-horde* packages first before accepting the upload > for a buster point release (same for the other updates proposed by > Roberto). > > Does this make sense? > Hi Salvatore, I've communicated with Mathieu Parent (the php-horde-* maintainer) regarding his intentions for unstable uploads of these three packages. He has asked that I go ahead and perform the uploads. However, if you think that a removal request is forthcoming in the very near future, I will wait and not make those uploads. My intent was to have them done in the next 24 hours. Please advise if I should proceed or if I should wait for removal. Regards, -Roberto -- Roberto C. Sánchez
Bug#956534: Bug#956532: stretch-pu: package php-horde-data/2.1.4-3+deb9u1
On Sun, Apr 12, 2020 at 10:10:14PM +0100, Adam D. Barratt wrote: > > Looking at the Security Tracker and the BTS, it appears that this issue > is not yet resolved in unstable. If that's correct, please let us know > once that's been done; if not, please ensure that the tracking / > metadata is corrected. > > Regards, > > Adam > Hi Adam, You are correct that this has not been fixed in unstable; that is the case for the updates associated with #956532, #956533, #956534, #956535, #956536, and #956537. I will coordinate with the maintainer to get that done for each package and then I will follow-up to the bugs once that is done. Regards, -Roberto -- Roberto C. Sánchez
Bug#956535: buster-pu: package php-horde-data/2.1.4-5+deb10u1
owner 956535 ! thanks On Sun, Apr 12, 2020 at 09:23:37AM -0400, Roberto C. Sanchez wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Please find attached a proposed debdiff for php-horde-data. The change > fixes CVE-2020-8518, which the security team has classified as , > deeming it a minor issue which can be fixed via a point release. May I > have permission to upload to stretch-proposed-updates? ^^^ That should read: buster-proposed updates. Regards, -Roberto -- Roberto C. Sánchez signature.asc Description: PGP signature
Bug#956534: stretch-pu: package php-horde-form/2.0.15-1+deb9u2
On Sun, Apr 12, 2020 at 09:27:50AM -0400, Roberto C. Sanchez wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Please find attached a proposed debdiff for php-horde-form. The change
> fixes CVE-2020-8866, which the security team has classified as ,
> deeming it a minor issue which can be fixed via a point release. I have
> prepared this update in coordination with the security team. May I have
> permission to upload to stretch-proposed-updates?
>
Here is the patch.
--
Roberto C. Sánchez
diff -Nru php-horde-form-2.0.15/debian/changelog php-horde-form-2.0.15/debian/changelog
--- php-horde-form-2.0.15/debian/changelog 2019-06-16 07:47:48.0 -0400
+++ php-horde-form-2.0.15/debian/changelog 2020-03-24 13:54:47.0 -0400
@@ -1,3 +1,14 @@
+php-horde-form (2.0.15-1+deb9u2) stretch; urgency=high
+
+ * Fix CVE-2020-8866:
+The Horde Application Framework contained a remote code execution
+vulnerability. An authenticated remote attacker could use this flaw to
+upload arbitrary content to an arbitrary writable location on the server
+and potentially execute code in the context of the web server user.
+(Closes: #955020)
+
+ -- Roberto C. Sanchez Tue, 24 Mar 2020 13:54:47 -0400
+
php-horde-form (2.0.15-1+deb9u1) stretch-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru php-horde-form-2.0.15/debian/patches/0002-SECURITY-Prevent-ability-to-specify-temporary-filename.patch php-horde-form-2.0.15/debian/patches/0002-SECURITY-Prevent-ability-to-specify-temporary-filename.patch
--- php-horde-form-2.0.15/debian/patches/0002-SECURITY-Prevent-ability-to-specify-temporary-filename.patch 1969-12-31 19:00:00.0 -0500
+++ php-horde-form-2.0.15/debian/patches/0002-SECURITY-Prevent-ability-to-specify-temporary-filename.patch 2020-03-24 13:54:47.0 -0400
@@ -0,0 +1,35 @@
+From 35d382cc3a0482c07d0c2272cac89a340922e0a6 Mon Sep 17 00:00:00 2001
+From: Michael J Rubinsky
+Date: Sun, 1 Mar 2020 14:46:49 -0500
+Subject: [PATCH] SECURITY: Prevent ability to specify temporary filename.
+
+Origin: https://github.com/horde/Form/commit/35d382cc3a0482c07d0c2272cac89a340922e0a6
+---
+ lib/Horde/Form/Type.php | 11 +--
+ 1 file changed, 5 insertions(+), 6 deletions(-)
+
+diff --git a/Horde_Form-2.0.15/lib/Horde/Form/Type.php b/Horde_Form-2.0.15/lib/Horde/Form/Type.php
+index f1e8157..e302d8d 100644
+--- a/Horde_Form-2.0.15/lib/Horde/Form/Type.php
b/Horde_Form-2.0.15/lib/Horde/Form/Type.php
+@@ -1200,12 +1200,11 @@ class Horde_Form_Type_image extends Horde_Form_Type {
+ if (!empty($upload['hash'])) {
+ $upload['img'] = $session->get('horde', 'form/' . $upload['hash']);
+ $session->remove('horde', 'form/' . $upload['hash']);
+-}
+-
+-/* Get the temp file if already one uploaded, otherwise create a
+- * new temporary file. */
+-if (!empty($upload['img']['file'])) {
+-$tmp_file = Horde::getTempDir() . '/' . basename($upload['img']['file']);
++if (!empty($upload['img']['file'])) {
++$tmp_file = Horde::getTempDir() . '/' . basename($upload['img']['file']);
++} else {
++$tmp_file = Horde::getTempFile('Horde', false);
++}
+ } else {
+ $tmp_file = Horde::getTempFile('Horde', false);
+ }
+--
+2.20.1
+
diff -Nru php-horde-form-2.0.15/debian/patches/series php-horde-form-2.0.15/debian/patches/series
--- php-horde-form-2.0.15/debian/patches/series 2019-06-16 07:46:47.0 -0400
+++ php-horde-form-2.0.15/debian/patches/series 2020-03-24 13:54:47.0 -0400
@@ -1 +1,2 @@
0001-SECURITY-prevent-directory-traversal-vulnerability.patch
+0002-SECURITY-Prevent-ability-to-specify-temporary-filename.patch
signature.asc
Description: PGP signature
Re: NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]
On Tue, Jul 09, 2019 at 01:33:49PM +0100, Sean Whitton wrote: > Hello, > > On Mon 08 Jul 2019 at 02:02PM +02, Michael Biebl wrote: > > > I would go even further and drop the (manual) NEW queue for binary-NEW > > packages. > > Is there a good reason why new binary packages need manual processing by > > the FTP team? Couldn't this be fully automated? > > The three things the FTP team check[1] are worth doing again for > binary-NEW packages. In order: there are often lots of new files in an > upload that ends up in binary-NEW so there might be licensing issues; a > new binary package means a new member of the binary package namespace; > it's good to have a second pair of eyes look at your SONAME bump etc. > > [1] https://ftp-master.debian.org/REJECT-FAQ.html right at the top > I've always wondered about this. Why is it, then, that binary-NEW still applies if there have been no source files added/removed? (A SONAME bump possibly being necessitated by some change that does not involve adding/removing/renaming source files.) Following on that, what about a package that does add/remove source files (perhaps many) without a SONAME bump or other change that results in a new binary package? It seems like reviewing the package name space on introduction of a new binary package and an additional review of a SONAME bump are good things and the binary-NEW criteria seem to fit. However, the "there might be new source files with licensing issues" does not seem to be a good fit for binary-NEW criteria. Not to say that it matters much in the context of binary-NEW. But if catching potential licensing issues associated with large source changes is in fact something which the FTP team wishes to be able to do, it probably warrants a different filter than "adds a new binary package to the archive" in order to be effective. Regards, -Roberto -- Roberto C. Sánchez
Bug#912531: stretch-pu: package exiv2/0.25-3.1+deb9u2
On Sun, Mar 31, 2019 at 08:09:27PM +0100, Adam D. Barratt wrote: > On Thu, 2018-11-01 at 21:07 -0400, Roberto C.Sánchez wrote: > > On Thu, Nov 01, 2018 at 06:50:53PM +, Adam D. Barratt wrote: > > > Control: tags -1 + moreinfo > > > > > > On Wed, 2018-10-31 at 23:25 -0400, Roberto C. Sanchez wrote: > > > > I have prepared an update for exiv2 in jessie (0.24-4.1+deb8u2) > > > > related to CVE-2018-16336 and also including a minor fix to the > > > > previous patch for CVE-2018-10958 and CVE-2018-10999. > > > > > > The Security Tracker indicates that CVE-2018-16336 is as-yet > > > unfixed in > > > unstable; is that correct? > > > > > > > Hi Adam, > > > > That is correct. I completely overlooked it. I will check with the > > maintainers about their plans for unstable. > > Was there any progress there? The issue is still marked as affecting > unstable in the tracker. > No real progress. I sent a message [0] to the packaging team's mailing list that same day (1st November). Salvatore responded a few days later, but there was no response after that. Regards, -Roberto [0] https://alioth-lists.debian.net/pipermail/pkg-kde-extras/2018-November/029728.html -- Roberto C. Sánchez
Bug#925383: Processed: Re: Bug#925383: unblock: shorewall/5.2.3.2-1
Control: tags -1 - moreinfo Hi Paul, On Sun, Mar 31, 2019 at 10:35:35AM +0200, Paul Gevers wrote: > Control: tags -1 moreinfo confirmed > > Hi Roberto, > > On 30-03-2019 13:24, Roberto C. Sánchez wrote: > > I removed the moreinfo tag nearly a week ago. Did I misunderstand what > > else I needed to do? Did I need to go ahead and upload as well? > > That. Jonathan said "I suggest you go ahead and remove the moreinfo tag > when it's ready for review". I agree that there is a slight ambiguity > there, but he meant, "I suggest you go ahead *with the upload* and > remove the moreinfo tag when it's ready for review *of the difference > between what is in buster and what is in sid*". > OK. That was clearly a reading comprehension failure on my part. Thank you for clarifying. > > I was > > waiting for a pre-approval, but if uploading now makes more sense and > > saves you work (since you could review and then unblock the waiting > > package), I can upload right away. > > I have added the moreinfo tag again, please remove it again once the > upload happened and we can review the delta between sid and buster. > I have uploaded the packages and also removed the moreinfo tag. Regards, -Roberto -- Roberto C. Sánchez
Bug#925383: Processed: Re: Bug#925383: unblock: shorewall/5.2.3.2-1
On Sun, Mar 24, 2019 at 06:51:04PM +, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > > > tags 925383 - moreinfo > Bug #925383 [release.debian.org] unblock: shorewall/5.2.3.2-1 > Removed tag(s) moreinfo. > > thanks > Stopping processing here. > Hi Jonathan, I removed the moreinfo tag nearly a week ago. Did I misunderstand what else I needed to do? Did I need to go ahead and upload as well? I was waiting for a pre-approval, but if uploading now makes more sense and saves you work (since you could review and then unblock the waiting package), I can upload right away. Regards, -Roberto -- Roberto C. Sánchez
Bug#925383: unblock: shorewall/5.2.3.2-1
tags 925383 - moreinfo thanks On Sun, Mar 24, 2019 at 04:39:20PM +, Jonathan Wiltshire wrote: > Control: tag -1 moreinfo > > On Sat, Mar 23, 2019 at 10:09:49PM -0400, Roberto C. Sanchez wrote: > > 5.2.3.2 > > > > 1) Shorewall 5.2 automatically converts and existing 'masq' file to an > > equivalent 'snat' file. Regrettably, Shorewall 5.2.3 broke that > > automatic update, such that the following error message was issued: > > > >Use of uninitialized value $Shorewall::Nat::raw::currentline in > >pattern match (m//) at /usr/share/shorewall/Shorewall/Nat.pm > >line 511, <$currentfile> line nnn. > > > > and the generted 'masq' file contains only initial comments. > > > > That has been corrected. > > > > I have attached debdiffs for all 6 packages. > > It can't be unblocked until it's in unstable; are you asking for > pre-approval? I didn't read the diffs in detail yet but it sounds like a > fix we'd want so I suggest you go ahead and remove the moreinfo tag when > it's ready for review. > Yes, it was my intent to request pre-approval. My apologies for the confusion. Regards, -Roberto -- Roberto C. Sánchez signature.asc Description: PGP signature
Bug#912531: stretch-pu: package exiv2/0.25-3.1+deb9u2
On Thu, Nov 01, 2018 at 06:50:53PM +, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Wed, 2018-10-31 at 23:25 -0400, Roberto C. Sanchez wrote: > > I have prepared an update for exiv2 in jessie (0.24-4.1+deb8u2) > > related to CVE-2018-16336 and also including a minor fix to the > > previous patch for CVE-2018-10958 and CVE-2018-10999. > > The Security Tracker indicates that CVE-2018-16336 is as-yet unfixed in > unstable; is that correct? > Hi Adam, That is correct. I completely overlooked it. I will check with the maintainers about their plans for unstable. Regards, -Roberto -- Roberto C. Sánchez
RFC: shorewall* 5.0.15.6 for stretch?
[I am not subscribed to debian-release, please keep me in CC]
Hello Release Folks,
I would like to ask if it would be OK for me to update the shorewall*
packages [0] prior to the stretch release.
The current version of the packages in stretch/sid is 5.0.15.2 and the
new version which I would like to upload is 5.0.15.6.
The releases between .2 and .6 fix some important upstream bugs as well
as update some documentation. The most important fix relates to the
.service files used by systemd. The relevant upstream release note
entry:
Now, when systemd stops a Shorewall-generated firewall, the
placed in the safe state rather than cleared.
As the changes for all releases from .2 to .6 are very limited, I would
rather upload new 5.0.15.6 packages from upstream and I have prepared
them already (debdiffs attached). This will be less confusing for users
than a targeted fix that results in a 5.0.15.2-2 package.
However, if that is not appropriate for some reason, I can resort to a
targeted fix.
How should I proceed?
Regards,
-Roberto
[0] shorewall-init shorewall-core shorewall shorewall6 shorewall-lite
shorewall6-lite
--
Roberto C. Sánchez
diff -Nru shorewall6-5.0.15.2/changelog.txt shorewall6-5.0.15.6/changelog.txt
--- shorewall6-5.0.15.2/changelog.txt 2016-12-20 12:41:05.0 -0500
+++ shorewall6-5.0.15.6/changelog.txt 2017-03-16 11:25:42.0 -0400
@@ -1,4 +1,28 @@
-Changes in 5.0.15.1
+Changes in 5.0.15.6
+
+1) Update release documents.
+
+2) Backport fix for two-interface snat-file.
+
+Changes in 5.0.15.5
+
+1) Update release documents.
+
+2) Rebuild with corrected build50.
+
+Changes in 5.0.15.4
+
+1) Update release documents.
+
+2) Merge fixes from 5.1.3.1 and earlier.
+
+Changes in 5.0.15.3
+
+1) Update release documents.
+
+2) Merge three fixes from the 5.1.0 branch
+
+Changes in 5.0.15.2
1) Update release documents.
diff -Nru shorewall6-5.0.15.2/configure shorewall6-5.0.15.6/configure
--- shorewall6-5.0.15.2/configure 2016-12-20 12:41:05.0 -0500
+++ shorewall6-5.0.15.6/configure 2017-03-16 11:25:42.0 -0400
@@ -28,7 +28,7 @@
#
# Build updates this
#
-VERSION=5.0.15.2
+VERSION=5.0.15.6
case "$BASH_VERSION" in
[4-9].*)
diff -Nru shorewall6-5.0.15.2/configure.pl shorewall6-5.0.15.6/configure.pl
--- shorewall6-5.0.15.2/configure.pl 2016-12-20 12:41:05.0 -0500
+++ shorewall6-5.0.15.6/configure.pl 2017-03-16 11:25:42.0 -0400
@@ -31,7 +31,7 @@
# Build updates this
#
use constant {
-VERSION => '5.0.15.2'
+VERSION => '5.0.15.6'
};
my %params;
diff -Nru shorewall6-5.0.15.2/debian/changelog shorewall6-5.0.15.6/debian/changelog
--- shorewall6-5.0.15.2/debian/changelog 2016-12-24 17:17:39.0 -0500
+++ shorewall6-5.0.15.6/debian/changelog 2017-04-03 11:03:31.0 -0400
@@ -1,3 +1,9 @@
+shorewall6 (5.0.15.6-1) unstable; urgency=medium
+
+ * New Upstream Version
+
+ -- Roberto C. Sanchez <robe...@connexer.com> Mon, 03 Apr 2017 11:03:31 -0400
+
shorewall6 (5.0.15.2-1) unstable; urgency=medium
* New Upstream Version
diff -Nru shorewall6-5.0.15.2/install.sh shorewall6-5.0.15.6/install.sh
--- shorewall6-5.0.15.2/install.sh 2016-12-20 12:41:05.0 -0500
+++ shorewall6-5.0.15.6/install.sh 2017-03-16 11:25:42.0 -0400
@@ -22,7 +22,7 @@
# along with this program; if not, see <http://www.gnu.org/licenses/>.
#
-VERSION=5.0.15.2
+VERSION=5.0.15.6
#
# Change to the directory containing this script
diff -Nru shorewall6-5.0.15.2/manpages/shorewall6-accounting.5 shorewall6-5.0.15.6/manpages/shorewall6-accounting.5
--- shorewall6-5.0.15.2/manpages/shorewall6-accounting.5 2016-12-20 12:41:52.0 -0500
+++ shorewall6-5.0.15.6/manpages/shorewall6-accounting.5 2017-03-16 11:26:27.0 -0400
@@ -2,12 +2,12 @@
.\" Title: shorewall6-accounting
.\"Author: [FIXME: author] [see http://docbook.sf.net/el/author]
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
-.\" Date: 12/20/2016
+.\" Date: 03/16/2017
.\"Manual: Configuration Files
.\"Source: Configuration Files
.\" Language: English
.\"
-.TH "SHOREWALL6\-ACCOUNTI" "5" "12/20/2016" "Configuration Files" "Configuration Files"
+.TH "SHOREWALL6\-ACCOUNTI" "5" "03/16/2017" "Configuration Files" "Configuration Files"
.\" -
.\" * Define some portability stuff
.\" -
diff -Nru shorewall6-5.0.15.2/manpages/shorewall6-actions.5 shorewall6-5.0.15.6/manpages/shorewall6-actions.5
--- shorewall6-5.0.15.2/manpages/shorewall6-actions.5 2016-12-20 12:41:53.0 -0500
+++ shorewall6-5.0.15.6/manpages/shorewall6-actions.5 2017-03-16 11:26:28.0 -0400
@@ -2,12 +2,12 @@
.\&q
Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default
Do you want me to go ahead with uploading -3 as is then?
Regards,
-Roberto
On Wed, Sep 09, 2015 at 07:48:32AM +0100, Daniel Glassey wrote:
> On Tue, Sep 08, 2015 at 09:35:14PM -0400, Roberto C. Sánchez wrote:
> > Daniel,
> >
> > I just built this and was going to upload for you, but I noticed that
> > lintian complained of two errors:
> >
> > E: sword source: license-problem-undefined-license unknown (paragraph at
> > line 25)
> > E: libsword-dev: pkg-config-multi-arch-wrong-dir usr/lib/pkgconfig/sword.pc
> > full text contains architecture specific dir x86_64-linux-gnu
> >
> > I don't have time to dig into the lintian errors tonight, but I may be
> > able to in the next day or so.
> >
> > Also, if you could push the tags for the various 1.7.3 versions that
> > would be helpful. I was going to check out on the debian/1.7.3+dfsg-3
> > and build from Git, but there was no tag, so I did an 'apt-get source'
> > and applied the patch you attached to the bug instead.
>
> Ah, indeed, I forgot to tag 1.7.3+dfsg-3.
>
> The fixes for lintian inc enabling multiarch are all in git in 1.7.3+dfsg-4
> ready to be tagged and released.
> I only did the 1.7.3+dfsg-3 to keep the patch simple for transition team to
> apply if necessary.
>
> Thanks :)
> Daniel
>
> > On Mon, Sep 07, 2015 at 11:55:36AM +0100, Daniel Glassey wrote:
> > > user release.debian@packages.debian.org
> > > usertag 796711 + transition
> > > usertag 796711 + patch
> > > block 796711 by 790756
> > > reassign 796711 release.debian.org
> > > thanks
> > >
> > > patch attached for the transition.
> > >
> > > I need to wait for a keyring update before I can upload myself.
> > >
> > > Thanks,
> > > Daniel
> >
> > > diff --git a/debian/changelog b/debian/changelog
> > > index b62945f..7fa2648 100644
> > > --- a/debian/changelog
> > > +++ b/debian/changelog
> > > @@ -1,3 +1,13 @@
> > > +sword (1.7.3+dfsg-3) unstable; urgency=low
> > > +
> > > + * c++ transition
> > > + rename library to libsword11v5
> > > + blocked by ICU c++ transition
> > > + * add patch abicompare.patch to allow libsword to work with
> > > + abi-compliance-checker for future transitions
> > > +
> > > + -- Daniel Glassey <w...@debian.org> Wed, 02 Sep 2015 14:15:09 +0100
> > > +
> > > sword (1.7.3+dfsg-2.1) unstable; urgency=medium
> > >
> > >* Non maintainer upload.
> > > diff --git a/debian/control b/debian/control
> > > index 53dbebe..9f59bf3 100644
> > > --- a/debian/control
> > > +++ b/debian/control
> > > @@ -17,7 +17,7 @@ Uploaders: Daniel Glassey <w...@debian.org>,
> > > Standards-Version: 3.9.3
> > > Homepage: http://www.crosswire.org/sword/
> > >
> > > -Package: libsword11
> > > +Package: libsword11v5
> > > Architecture: any
> > > Depends: libsword-common, ${shlibs:Depends}, ${misc:Depends}
> > > Recommends: sword-frontend
> > > @@ -36,7 +36,7 @@ Description: API/library for bible software
> > > Package: libsword-dev
> > > Architecture: any
> > > Section: libdevel
> > > -Depends: libsword11 (= ${binary:Version}), ${misc:Depends}
> > > +Depends: libsword11v5 (= ${binary:Version}), ${misc:Depends}
> > > Recommends: libsword-utils
> > > Description: Development files for libsword
> > > The SWORD Project is an open source, cross-platform (Linux, Windows,
> > > Solaris,
> > > @@ -80,7 +80,7 @@ Package: libsword-dbg
> > > Architecture: any
> > > Section: debug
> > > Priority: extra
> > > -Depends: libsword11 (= ${binary:Version}), ${misc:Depends}
> > > +Depends: libsword11v5 (= ${binary:Version}), ${misc:Depends}
> > > Description: API/library for bible software - Debug Files
> > > The SWORD Project is an open source, cross-platform (Linux, Windows,
> > > Solaris,
> > > MacOSX etc.) API/library for Bible software with a constantly growing
> > > list
> > > diff --git a/debian/libsword11.docs b/debian/libsword11.docs
> > > deleted file mode 100644
> > > index 546a37e..000
> > > --- a/debian/libsword11.docs
> > > +++ /dev/null
> > > @@ -1 +0,0 @@
> > > -doc/translation-template.conf
> > > diff --git a/debian/libsword11.install b/debian/libsword11.install
> > > deleted file mode 100644
> > > ind
Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default
Of course. The upload is meant for experimental like -3. Correct? Regards, -Roberto On Wed, Sep 09, 2015 at 09:33:03AM +0100, Daniel Glassey wrote: > On Wed, Sep 09, 2015 at 04:08:25AM -0400, Roberto C. Sánchez wrote: > > Do you want me to go ahead with uploading -3 as is then? > > No need, could you just git-buildpackage build and tag -4 ? > > Thanks, > Daniel > -- Roberto C. Sánchez signature.asc Description: Digital signature
Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default
The build failed because there is now a .gitignore in the repository. According to dpkg-source it is an unexpected upstream change and it fails the build. Can the .gitignore be removed? Regards, -Roberto On Wed, Sep 09, 2015 at 11:03:56AM +0100, Daniel Glassey wrote: > Oops, didn't change that before I committed. No, this is for unstable for the > transition. > > Thanks, > Daniel > -- Roberto C. Sánchez signature.asc Description: Digital signature
Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default
ain.h 2015-09-03 07:52:46.497269566
> +0100
> sword-1.7.3+dfsg/include/femain.h2015-09-03 07:57:23.730644294
> +0100
> +@@ -23,12 +23,15 @@
> + #ifndef FEMAIN_H
> + #define FEMAIN_H
> +
> ++#include
> ++#include
> ++
> + class FEMain
> + {
> + public:
> + FEMain ();
> + virtual ~FEMain ();
> +- list < SWDisplay * >displays; // so we can delete each display we
> create
> ++ std::list < sword::SWDisplay * >displays; // so we can delete each
> display we create
> + };
> +
> + #endif
> +Index: sword-1.7.3+dfsg/include/hebrewmcim.h
> +===
> +--- sword-1.7.3+dfsg.orig/include/hebrewmcim.h 2013-06-29
> 07:40:28.0 +0100
> sword-1.7.3+dfsg/include/hebrewmcim.h2015-09-03 07:49:51.896403768
> +0100
> +@@ -42,8 +42,8 @@
> +
> + void init();
> + int subst[255];
> +-map<int, int> subst2[12];
> +-map<int, int*> multiChars;
> ++std::map<int, int> subst2[12];
> ++std::map<int, int*> multiChars;
> +
> + public:
> + HebrewMCIM();
> +Index: sword-1.7.3+dfsg/include/sapphire.h
> +===
> +--- sword-1.7.3+dfsg.orig/include/sapphire.h 2013-06-29 07:40:28.0
> +0100
> sword-1.7.3+dfsg/include/sapphire.h 2015-09-03 07:50:55.180717576
> +0100
> +@@ -37,6 +37,9 @@
> + * results of assignments need to be reduced to 8 bits with
> + * & 0xFF or % 0x100, whichever is faster.
> + */
> ++
> ++#ifndef SAPPHIRE_H
> ++#define SAPPHIRE_H
> +
> + #ifndef NULL
> + #define NULL 0
> +@@ -80,3 +83,5 @@
> +
> +
> + SWORD_NAMESPACE_END
> ++
> ++#endif //SAPPHIRE_H
> +Index: sword-1.7.3+dfsg/include/zcom.h
> +===
> +--- sword-1.7.3+dfsg.orig/include/zcom.h 2013-06-29 07:40:28.0
> +0100
> sword-1.7.3+dfsg/include/zcom.h 2015-09-03 07:31:44.063009491 +0100
> +@@ -25,6 +25,7 @@
> + #define ZCOM_H
> +
> + #include
> ++#include
> +
> + #include
> +
> diff --git a/debian/patches/series b/debian/patches/series
> index f081236..4ead391 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -10,3 +10,4 @@
> multiarch-clucene.patch
> no-included-zconf.h.diff
> dso-missing-shared.patch
> +abicompare.patch
> ___
> Pkg-crosswire-devel mailing list
> pkg-crosswire-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-crosswire-devel
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Bug#779462: unblock: shorewall/4.6.4.3-2 . shorewall-core/4.6.4.3-2
On Sun, Mar 01, 2015 at 01:52:02AM +0100, Mehdi Dogguy wrote: Hi, On Sat, Feb 28, 2015 at 05:26:20PM -0500, Roberto C. Sanchez robe...@connexer.com wrote: Please unblock packages shorewall and shorewall-core I have uploaded version 4.6.4.3-2 of each package to fix RC bugs #779119 and #779120. I've unblocked them and aged them a little. Thanks! Regards, -Roberto -- Roberto C. Sánchez signature.asc Description: Digital signature
Would a shorewall upload incorporating this patch be accepted?
[Please CC me, I am not subscribed to the list]
It has been brought to my attention that the Wheezy version of the
shorewall package contains a bug for users with a multi-ISP
configuration. This was fixed by upstream in a subsequent release and
the user has requested that the fix be included in Wheezy. Before I go
building and uploading the package, I'd like to know if the patch would
be suitable from the Release Team's perspective.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
--- lib.core-orig 2013-03-14 12:04:51.0 +0200
+++ lib.core-new2013-03-14 12:06:07.0 +0200
@@ -916,7 +916,12 @@
delta=$1
if ! echo $route | fgrep -q ' nexthop '; then
- route=`echo $route | sed 's/via/nexthop via/'`
+if echo $route | fgrep -q via; then
+route=`echo $route | sed 's/via/nexthop via/'`
+else
+route=nexthop $route
+fi
+
dev=$(find_device $route)
if [ -f ${VARDIR}/${dev}_weight ]; then
weight=`cat ${VARDIR}/${dev}_weight`
signature.asc
Description: Digital signature
Bug#681989: unblock: shorewall-init/4.5.5.3-1 shorewall-core/4.5.5.3-1 shorewall/4.5.5.3-1 shorewall6/4.5.5.3-1 shorewall-lite/4.5.5.3-1 shorewall6-lite/4.5.5.3-1
On Wed, Jul 18, 2012 at 04:47:07PM +0200, Mehdi Dogguy wrote: On 18/07/2012 16:22, Roberto C. Sanchez wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Please unblock package shorewall You still didn't answer my question regarding this update: Why do they _need_ to stay in sync apart the fact that upstream wants that? are there any checks performed? So, it turns out that this is all a big misunderstanding. Upstream wants the packages to stay in sync because he thinks that is what the distros want. He has indicated that he is perfectly capable of simply releasing only the packages with actual changes for a point release, so long as the distros are OK with it. I assured him that from a Debian perspective, this is preferred. I asked him to check with the people who package Shorewall for the other distros and if they do not object, to start releasing only the package(s) with actual changes. To answer your second question, there are no checks performed. I'd like to recommend that you allow the current batch from unstable into testing since I already uploaded them and there is no way to take that back. Thanks for your time. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Pre-approval request for upload of shorewall-* packages
On Fri, Jul 06, 2012 at 02:15:19PM +0200, Mehdi Dogguy wrote: Why do they _need_ to stay in sync apart the fact that upstream wants that? are there any checks performed? That is a good question. I will investigate that. Please see the attached debdiff for the proposed changes. The debdiffs look okay. Thanks. I have gone ahead and uploaded. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: [SRM] shorewall{,6,-lite,6-lite} update for stable?
On Sat, Nov 05, 2011 at 02:06:42PM +, Adam D. Barratt wrote: On Thu, 2011-11-03 at 08:35 +, Adam D. Barratt wrote: [...] On Sat, Oct 29, 2011 at 12:16:00PM -0400, Roberto C. Sánchez wrote: [...] Please see attached debdiffs. [...] Okay. In that case, please go ahead; thanks. For the record, these were uploaded and accepted. For the record, thanks very much for your assistance in this. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: [SRM] shorewall{,6,-lite,6-lite} update for stable?
On Wed, Nov 02, 2011 at 09:35:36PM +, Adam D. Barratt wrote: On Sat, 2011-10-29 at 20:48 -0400, Roberto C. Sánchez wrote: On Sat, Oct 29, 2011 at 12:16:00PM -0400, Roberto C. Sánchez wrote: I'd like to see debdiffs before a final ACK, but I'd be inclined to say yes based on the information provided so far. OK. I will prepare the uploads and send the debdiffs for final approval prior to uploading. Please see attached debdiffs. Thanks. Diffs of packages with debian-changes-$version auto-patches are somewhat annoying to review. :-/ I agree. However, to minmize the +squeez1 diff for shorewall, I made the updates in the upstream files, instead of including them in a Debian-specific patch. At least that is my recollection of it. At least there is only the one. Please note that for shorewall-lite and shorewall6-lite I had to include the helpers file from a newer release. Because of an upstream bug, that file was missing from every release until 4.4.18.1. Is the resulting file correct / sane for 4.4.11? Yes. It was the one that was developed for 4.4.11, but leaft out due to an upstream packaging error. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: [SRM] shorewall{,6,-lite,6-lite} update for stable?
On Sat, Oct 29, 2011 at 03:12:06PM +0100, Adam D. Barratt wrote:
On Sat, 2011-10-22 at 16:35 -0400, Roberto C. Sánchez wrote:
As a result of #646112, it has come to my attention that I made a
packaging error in the shorewall{,6,-lite,6-lite} packages that released
with Squeeze. Incidentally, the problem also affects shorewall-lite and
shorewall6-lite in Sid. I have already fixed the latest version in the
git repository and the fix will go into unstable at the next upload.
[...]
Would this be something that the stable release manager's might consider
for the next point release? If so, can I proceed wth an upload to
s-p-u?
I'd like to see debdiffs before a final ACK, but I'd be inclined to say
yes based on the information provided so far.
OK. I will prepare the uploads and send the debdiffs for final approval
prior to uploading.
Does this also affect the version of shorewall-lite in lenny?
The lenny version is not affected.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Re: [SRM] shorewall{,6,-lite,6-lite} update for stable?
On Sat, Oct 29, 2011 at 12:16:00PM -0400, Roberto C. Sánchez wrote:
I'd like to see debdiffs before a final ACK, but I'd be inclined to say
yes based on the information provided so far.
OK. I will prepare the uploads and send the debdiffs for final approval
prior to uploading.
Please see attached debdiffs. Please note that for shorewall-lite and
shorewall6-lite I had to include the helpers file from a newer release.
Because of an upstream bug, that file was missing from every release
until 4.4.18.1.
As soon as I receive approval, I will upload.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
diff -Nru shorewall-4.4.11.6/debian/changelog shorewall-4.4.11.6/debian/changelog
--- shorewall-4.4.11.6/debian/changelog 2010-11-28 21:36:22.0 -0500
+++ shorewall-4.4.11.6/debian/changelog 2011-10-29 14:15:28.0 -0400
@@ -1,3 +1,9 @@
+shorewall (4.4.11.6-3+squeeze1) stable-proposed-updates; urgency=low
+
+ * Install missing /usr/share/shorewall/helpers (Closes: #646112)
+
+ -- Roberto C. Sanchez robe...@connexer.com Sat, 29 Oct 2011 14:14:21 -0400
+
shorewall (4.4.11.6-3) unstable; urgency=low
* Fix macro.JAP to correct nested macro call.
diff -Nru shorewall-4.4.11.6/debian/patches/debian-changes-4.4.11.6-3 shorewall-4.4.11.6/debian/patches/debian-changes-4.4.11.6-3
--- shorewall-4.4.11.6/debian/patches/debian-changes-4.4.11.6-3 2010-11-28 21:39:09.0 -0500
+++ shorewall-4.4.11.6/debian/patches/debian-changes-4.4.11.6-3 1969-12-31 19:00:00.0 -0500
@@ -1,105 +0,0 @@
-Description: Upstream changes introduced in version 4.4.11.6-3
- This patch has been created by dpkg-source during the package build.
- Here's the last changelog entry, hopefully it gives details on why
- those changes were made:
- .
- shorewall (4.4.11.6-3) unstable; urgency=low
- .
- * Fix macro.JAP to correct nested macro call.
- .
- The person named in the Author field signed this changelog entry.
-Author: Roberto C. Sanchez robe...@connexer.com
-
-The information above should follow the Patch Tagging Guidelines, please
-checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
-are templates for supplementary fields that you might want to add:
-
-Origin: vendor|upstream|other, url of original patch
-Bug: url in upstream bugtracker
-Bug-Debian: http://bugs.debian.org/bugnumber
-Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
-Forwarded: no|not-needed|url proving that it has been forwarded
-Reviewed-By: name and email of someone who approved the patch
-Last-Update: -MM-DD
-
shorewall-4.4.11.6.orig/known_problems.txt
-+++ shorewall-4.4.11.6/known_problems.txt
-@@ -147,3 +147,17 @@
- showed an empty log when issued to one of the -lite packages.
-
- Corrected in Shorewall 4.4.11.6
-+
-+22) If 10 or more interfaces are configured in Complex Traffic Shaping
-+(/etc/shorewall/tcdevices), the following compilation diagnostic
-+is issued:
-+
-+Argument a isn't numeric in sprintf at
-+ /usr/share/shorewall/Shorewall/Config.pm line 893.
-+
-+and an invalid TC configuration is generated.
-+
-+A fix is available at
-+http://shorewall.git.sourceforge.net/git/gitweb.cgi?p=shorewall/shorewall;a=commitdiff;h=20bb781874c739c01b798d2db31b6c1d9cfefe96
-+
-+
shorewall-4.4.11.6.orig/releasenotes.txt
-+++ shorewall-4.4.11.6/releasenotes.txt
-@@ -218,6 +218,17 @@ VI. PROBLEMS CORRECTED AND NEW FEATURE
- I I I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E
-
-
-+Post-4.4.11.6
-+
-+1) Previously, if 10 or more interfaces were configured in Complex
-+Traffic Shaping (/etc/shorewall/tcdevices), the following
-+compilation diagnostic was generated:
-+
-+Argument a isn't numeric in sprintf at
-+ /usr/share/shorewall/Shorewall/Config.pm line 893.
-+
-+and an invalid TC configuration was generated.
-+
- 4.4.11.6
-
- 1) The Shorewall-lite and Shorewall6-lite Debian init scripts contained a
shorewall-4.4.11.6.orig/changelog.txt
-+++ shorewall-4.4.11.6/changelog.txt
-@@ -1,3 +1,7 @@
-+Changes post 4.4.11.6
-+
-+1) Fix 10+ TC Interfaces.
-+
- Changes in Shorewall 4.4.11.6
-
- 1) Fix log reading in -lite packages.
shorewall-4.4.11.6.orig/Perl/Shorewall/Tc.pm
-+++ shorewall-4.4.11.6/Perl/Shorewall/Tc.pm
-@@ -1279,7 +1279,7 @@ sub setup_traffic_shaping() {
- my $tcref= $tcclasses{$device}{$decimalclassnum};
- my $mark = $tcref-{mark};
- my $devicenumber = in_hexp $devref-{number};
-- my $classid = join( ':', in_hexp $devicenumber, $classnum);
-+ my $classid = join( ':', $devicenumber, $classnum);
- my $rate = $tcref-{rate}kbit;
- my $quantum = calculate_quantum $rate, calculate_r2q( $devref-{out_bandwidth} );
-
-@@ -1304,15 +1304,15 @@ sub setup_traffic_shaping() {
- emit ( [ \$${dev}_mtu -gt $quantum ] quantum=\$${dev}_mtu || quantum=$quantum
[SRM] shorewall{,6,-lite,6-lite} update for stable?
As a result of #646112, it has come to my attention that I made a
packaging error in the shorewall{,6,-lite,6-lite} packages that released
with Squeeze. Incidentally, the problem also affects shorewall-lite and
shorewall6-lite in Sid. I have already fixed the latest version in the
git repository and the fix will go into unstable at the next upload.
The result of this issue is that there is some brokenness for specific
users. This occurs when a particular setting is enabled in the
respective package's configuration file to restrict the kernel modules
that got loaded to only those listed in the helpers file. The packaging
error that I made was to not include the default helpers file. I have
attached the two helpers files that would need to be included in the
update. The first file would be included in shorewall and
shorewall-lite and the second file in shorewall6 and shorewall6-lite.
The files are already shipped in the respective .orig.tar.gz that are in
the archive. The packaging change would be to install the file into
/usr/share/shorewall{,6,-lite,6-lite} in the binary packages.
Would this be something that the stable release manager's might consider
for the next point release? If so, can I proceed wth an upload to
s-p-u?
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Re: [SRM] shorewall{,6,-lite,6-lite} update for stable?
On Sat, Oct 22, 2011 at 04:35:49PM -0400, Roberto C. Sánchez wrote: I have attached the two helpers files that would need to be included in the update. The first file would be included in shorewall and shorewall-lite and the second file in shorewall6 and shorewall6-lite. I cleverly forgot the attachments the first time, so here they are this time. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com # # Shorewall version 4 - Helpers File # # /usr/share/shorewall/helpers # # This file loads the kernel helper modules. # # THE ORDER OF THE COMMANDS BELOW IS IMPORTANT!! You MUST load in # dependency order. i.e., if M2 depends on M1 then you must load M1 # before you load M2. # # If you need to modify this file, copy it to /etc/shorewall and modify the # copy. # ### # Helpers # loadmodule ip_conntrack_amanda loadmodule ip_conntrack_ftp loadmodule ip_conntrack_h323 loadmodule ip_conntrack_irc loadmodule ip_conntrack_netbios_ns loadmodule ip_conntrack_pptp loadmodule ip_conntrack_sip loadmodule ip_conntrack_tftp loadmodule ip_nat_amanda loadmodule ip_nat_ftp loadmodule ip_nat_h323 loadmodule ip_nat_irc loadmodule ip_nat_pptp loadmodule ip_nat_sip loadmodule ip_nat_snmp_basic loadmodule ip_nat_tftp loadmodule ip_set loadmodule ip_set_iphash loadmodule ip_set_ipmap loadmodule ip_set_macipmap loadmodule ip_set_portmap # # 2.6.20+ helpers # loadmodule nf_conntrack_ftp loadmodule nf_conntrack_h323 loadmodule nf_conntrack_irc loadmodule nf_conntrack_netbios_ns loadmodule nf_conntrack_netlink loadmodule nf_conntrack_pptp loadmodule nf_conntrack_proto_gre loadmodule nf_conntrack_proto_sctp loadmodule nf_conntrack_sip sip_direct_media=0 loadmodule nf_conntrack_tftp loadmodule nf_conntrack_sane loadmodule nf_nat_amanda loadmodule nf_nat_ftp loadmodule nf_nat_h323 loadmodule nf_nat_irc loadmodule nf_nat loadmodule nf_nat_pptp loadmodule nf_nat_proto_gre loadmodule nf_nat_sip loadmodule nf_nat_snmp_basic loadmodule nf_nat_tftp # # Shorewall6 version 4 - Helpers File # # /usr/share/shorewall6/helpers # # This file loads the modules that may be needed by the firewall. # # THE ORDER OF THE COMMANDS BELOW IS IMPORTANT!! You MUST load in # dependency order. i.e., if M2 depends on M1 then you must load M1 # before you load M2. # # If you need to modify this file, copy it to /etc/shorewall and modify the # copy. # ### # # Helpers # loadmodule nf_conntrack_amanda loadmodule nf_conntrack_ftp loadmodule nf_conntrack_h323 loadmodule nf_conntrack_irc loadmodule nf_conntrack_netbios_ns loadmodule nf_conntrack_netbios_ns loadmodule nf_conntrack_netlink loadmodule nf_conntrack_pptp loadmodule nf_conntrack_proto_sctp loadmodule nf_conntrack_proto_udplite loadmodule nf_conntrack_sane loadmodule nf_conntrack_sip sip_direct_media=0 loadmodule nf_conntrack_pptp loadmodule nf_conntrack_proto_gre loadmodule nf_conntrack_proto_sctp loadmodule nf_conntrack_sip loadmodule nf_conntrack_tftp loadmodule nf_conntrack_sane signature.asc Description: Digital signature
Please unblock shorewall and shorewall6
It seems that shorewall and shorewall6 (4.4.18.1-1) are in need of same manual hinting to propogate to testing. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Please unblock shorewall and shorewall6
On Sat, Apr 02, 2011 at 06:59:28PM +0100, Adam D. Barratt wrote: On Sat, April 2, 2011 17:43, Roberto C. Sánchez wrote: It seems that shorewall and shorewall6 (4.4.18.1-1) are in need of same manual hinting to propogate to testing. Julien added a hint earlier today. Thanks very much. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
shorewall-lite and shorewall6-lite are stuck from migrating
I am curious as to how to handle this situation: shorewall-lite and shorewall6-lite are both stuck from migrating. The excuses look like this: roberto@miami:~$ grep-excuses shorewall-lite shorewall-lite (4.4.11.6-1+squeeze1 to 4.4.17-1) Maintainer: Roberto C. Sanchez 10 days old (needed 10 days) shorewall-lite (source, i386, amd64, armel, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc) has new bugs! Updating shorewall-lite introduces new bugs: #610314 Not considered roberto@miami:~$ grep-excuses shorewall6-lite shorewall6-lite (4.4.11.6-1+squeeze1 to 4.4.17-1) Maintainer: Roberto C. Sanchez 10 days old (needed 10 days) shorewall6-lite (source, i386, amd64, armel, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc) has new bugs! Updating shorewall6-lite introduces new bugs: #610327 Not considered I think that this is because the bug was fixed in sid in version 4.4.16-1 (uploaded on January 15), but the bug was reported against Squeeze version 4.4.11.6-1 on January 17). I uploaded version 4.4.11.6-1+squeeze1 later that same day (on January 17). Of course, since 4.4.16-1 also corrected the problem but the problem had not yet been reported, there was no reason to expect it to be mentioned in the changelog. Do I need to mention it in a future changelog (4.4.18 should be released in a few weeks), or does get solved by manual hinting or some other way? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: shorewall-lite and shorewall6-lite are stuck from migrating
On Mon, Feb 21, 2011 at 08:36:23PM +0100, Julien Cristau wrote: On Mon, Feb 21, 2011 at 14:09:33 -0500, Roberto C. Sánchez wrote: I think that this is because the bug was fixed in sid in version 4.4.16-1 (uploaded on January 15), but the bug was reported against Squeeze version 4.4.11.6-1 on January 17). I uploaded version 4.4.11.6-1+squeeze1 later that same day (on January 17). Of course, since 4.4.16-1 also corrected the problem but the problem had not yet been reported, there was no reason to expect it to be mentioned in the changelog. http://bugs.debian.org/cgi-bin/version.cgi?info=1;absolute=0;fixed=shorewall-lite%2F4.4.11.6-1%2Bsqueeze1;collapse=1;found=shorewall-lite%2F4.4.11.6-1;package=shorewall-lite It doesn't have to be mentioned in the changelog, but you need to tell the bts which versions have the fix. See the 'fixed' command in bts(1). Ah, yes. Shame on me for overlooking that. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Pre-approval for t-p-u upload of {shorewall,shorewall6}-lite
Release Team,
It has just recently been reported that the shorewall-lite package in
testing (and likewise, the shorewall6-lite package in testing) contains
a bug which renders the package largely unusable. The associated bugs,
are #610314 (shorewall-lite) and #610327 (shorewall6-lite) and are
severity grave.
I am seeking approval from the release team to prepare an upload to
t-p-u that will correct those two bugs as well as another issue which is
important, but requires only a trivial change to fix. Please see below
for details.
The diff to fix the init script problem is this:
--- a/Shorewall-lite/init.debian.sh
+++ b/Shorewall-lite/init.debian.sh
@@ -17,10 +17,9 @@ SRWL=/sbin/shorewall-lite
SRWL_OPTS=-tvv
test -n ${INITLOG:=/var/log/shorewall-lite-init.log}
-[ $INITLOG eq /dev/null SHOREWALL_INIT_SCRIPT=1 ||
SHOREWALL_INIT_SCRIPT=0
+[ $INITLOG = /dev/null ] SHOREWALL_INIT_SCRIPT=1 ||
SHOREWALL_INIT_SCRIPT=0
export SHOREWALL_INIT_SCRIPT
-
test -x $SRWL || exit 0
test -x $WAIT_FOR_IFUP || exit 0
test -n $INITLOG || {
It will need to be applied once to each package.
Additionally, the main upstream developer has brought to my attention
that there is a rather annoying bug (it would be severity important if a
proper bug report were submitted on it) that prevents some logging
functionality from working. The diff for that fix is:
--- a/Shorewall-lite/shorewall-lite
+++ b/Shorewall-lite/shorewall-lite
@@ -94,9 +94,9 @@ get_config() {
[ -z $LOGFILE ] LOGFILE=/var/log/messages
if ( ps ax 2 /dev/null | grep -v grep | qt grep 'syslogd.*-C' ) ; then
- LOGREAD=logread | tac
+ g_logread=logread | tac
elif [ -r $LOGFILE ]; then
- LOGREAD=tac $LOGFILE
+ g_logread=tac $LOGFILE
else
echo LOGFILE ($LOGFILE) does not exist! 2
exit 2
@@ -469,6 +469,7 @@ g_use_verbosity=
g_noroutes=
g_timestamp=
g_recovering=
+g_logread=
finished=0
As with the first fix, this would have to be applied once to each of
shorewall-lite and shorewall6-lite. As I will be updating to correct
the two RC bugs, I'd also like permission to include this additional
fix.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Re: Pre-approval for t-p-u upload of {shorewall,shorewall6}-lite
On Mon, Jan 17, 2011 at 11:35:49AM -0500, Roberto C. Sánchez wrote: Release Team, It has just recently been reported that the shorewall-lite package in testing (and likewise, the shorewall6-lite package in testing) contains a bug which renders the package largely unusable. The associated bugs, are #610314 (shorewall-lite) and #610327 (shorewall6-lite) and are severity grave. I am seeking approval from the release team to prepare an upload to t-p-u that will correct those two bugs as well as another issue which is important, but requires only a trivial change to fix. Please see below for details. Please disregard the second diff, as it is already part of the package in squeeze (just a bit of forgetfulness on my part, not remembering it was already there). So, I only require approval for the init script change. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Pre-approval for t-p-u upload of {shorewall,shorewall6}-lite
On Mon, Jan 17, 2011 at 02:31:46PM -0500, Roberto C. Sánchez wrote:
Please disregard the second diff, as it is already part of the package
in squeeze (just a bit of forgetfulness on my part, not remembering it
was already there). So, I only require approval for the init script
change.
I have attached the complete debdiffs for your review.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
diff -Nru shorewall-lite-4.4.11.6/debian/changelog shorewall-lite-4.4.11.6/debian/changelog
--- shorewall-lite-4.4.11.6/debian/changelog 2010-10-11 18:53:01.0 -0400
+++ shorewall-lite-4.4.11.6/debian/changelog 2011-01-17 14:38:40.0 -0500
@@ -1,3 +1,9 @@
+shorewall-lite (4.4.11.6-1+squeeze1) testing-proposed-updates; urgency=high
+
+ * Sync init script with upstream (Closes: #610314)
+
+ -- Roberto C. Sanchez robe...@connexer.com Mon, 17 Jan 2011 14:34:14 -0500
+
shorewall-lite (4.4.11.6-1) unstable; urgency=low
* New Upstream Version
diff -Nru shorewall-lite-4.4.11.6/debian/shorewall-lite.init shorewall-lite-4.4.11.6/debian/shorewall-lite.init
--- shorewall-lite-4.4.11.6/debian/shorewall-lite.init 2010-10-11 18:53:01.0 -0400
+++ shorewall-lite-4.4.11.6/debian/shorewall-lite.init 2011-01-17 14:38:40.0 -0500
@@ -17,10 +17,9 @@
SRWL_OPTS=-tvv
test -n ${INITLOG:=/var/log/shorewall-lite-init.log}
-[ $INITLOG eq /dev/null SHOREWALL_INIT_SCRIPT=1 || SHOREWALL_INIT_SCRIPT=0
+[ $INITLOG = /dev/null ] SHOREWALL_INIT_SCRIPT=1 || SHOREWALL_INIT_SCRIPT=0
export SHOREWALL_INIT_SCRIPT
-
test -x $SRWL || exit 0
test -x $WAIT_FOR_IFUP || exit 0
test -n $INITLOG || {
diff -Nru shorewall6-lite-4.4.11.6/debian/changelog shorewall6-lite-4.4.11.6/debian/changelog
--- shorewall6-lite-4.4.11.6/debian/changelog 2010-10-11 18:53:22.0 -0400
+++ shorewall6-lite-4.4.11.6/debian/changelog 2011-01-17 14:38:29.0 -0500
@@ -1,3 +1,9 @@
+shorewall6-lite (4.4.11.6-1+squeeze1) testing-proposed-updates; urgency=high
+
+ * Sync init script with upstream (Closes: #610327)
+
+ -- Roberto C. Sanchez robe...@connexer.com Mon, 17 Jan 2011 14:36:34 -0500
+
shorewall6-lite (4.4.11.6-1) unstable; urgency=low
* New Upstream Version
diff -Nru shorewall6-lite-4.4.11.6/debian/shorewall6-lite.init shorewall6-lite-4.4.11.6/debian/shorewall6-lite.init
--- shorewall6-lite-4.4.11.6/debian/shorewall6-lite.init 2010-10-11 18:53:22.0 -0400
+++ shorewall6-lite-4.4.11.6/debian/shorewall6-lite.init 2011-01-17 14:38:29.0 -0500
@@ -17,7 +17,7 @@
SRWL_OPTS=-tvv
test -n ${INITLOG:=/var/log/shorewall6-lite-init.log}
-[ $INITLOG eq /dev/null SHOREWALL_INIT_SCRIPT=1 || SHOREWALL_INIT_SCRIPT=0
+[ $INITLOG = /dev/null ] SHOREWALL_INIT_SCRIPT=1 || SHOREWALL_INIT_SCRIPT=0
export SHOREWALL_INIT_SCRIPT
signature.asc
Description: Digital signature
Re: Bug#608347: lowering severity
On Fri, Dec 31, 2010 at 03:55:21PM +, Neil Williams wrote: On Thu, 30 Dec 2010 15:55:24 -0800 Jorge Moraleda jorge.moral...@gmail.com wrote: 3) The README.debian file now calls to execute make to build all examples. That's a separate bug. It doesn't affect the -dbg package which is meant for a different purpose. IMHO it may be better for the examples package to omit the Makefiles completely or document clearly that the supplied Makefiles are only examples too and you need to use the example source code in your own projects with your own make config. Additionally, the way in which this was fixed was wrong as well: perl -p -i -e s/-ltbb_debug/\/usr\/lib\/debug\/usr\/lib\/libtbb.so.2/g Changing the -l flag to link directly against the debug symbols will not work. Anyhow, I am looking at the Makefile now and will either fix that or add appropriate documentation to the README.Debian file. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bug#608347: libtbb2-dbg: Segfault at _dl_relocate_object() dl-reloc.c:242 0x00007ffff7de9b03
I am curious as to whether the release team thinks that #608347 (quoted below) is really RC. Do I need to target the fix for this to go into Squeeze? Regards, -Roberto On Wed, Dec 29, 2010 at 06:20:45PM -0800, Jorge Moraleda wrote: Package: libtbb2-dbg Version: 3.0+r035-1 Justification: renders package unusable Severity: grave When linking against the tbb debug libraries from the package, a segmentation fault occurs at initialization time: 17 _dl_relocate_object() dl-reloc.c:242 0x77de9b03 16 dl_main() rtld.c:2232 0x77de2970 15 _dl_sysdep_start() dl-sysdep.c:243 0x77df36e7 14 _dl_start_final() rtld.c:338 0x77de0423 13 _dl_start() rtld.c:564 0x77de0423 12 _start() 0x77ddfaf8 This problem does not occur when linking against the release version of the library in package libtbb2 or when linking aganst the release or debug versions downloaded from http://www.threadingbuildingblocks.org -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bug#601977: cyrus-sasl2-heimdal-dbg: file conflict during upgrade from lenny
On Tue, Dec 14, 2010 at 08:03:10PM +0100, Luca Capello wrote: Hi there! On Tue, 14 Dec 2010 01:29:01 +0100, Roberto C. Sánchez wrote: created by dh_strip, excerpted from debian/rules below: dh_strip -s -psasl2-bin -plibsasl2-2 -plibsasl2-modules -plibsasl2-modules-ldap -plibsasl2-modules-otp -plibsasl2-modules-sql -plibsasl2-modules-gssapi-mit -plibsasl2-dev -Nlibsasl2-modules-gssapi-heimdal --dbg-package=cyrus-sasl2-dbg dh_strip -s -plibsasl2-modules-gssapi-heimdal -Nsasl2-bin -Nlibsasl2-2 -Nlibsasl2-modules -Nlibsasl2-modules-ldap -Nlibsasl2-modules-otp -Nlibsasl2-modules-sql -Nlibsasl2-modules-gssapi-mit -Nlibsasl2-dev --dbg-package=cyrus-sasl2-heimdal-dbg Both packages need to be able to be installed together, so my question centers around whehter it is OK to put a diversion in place so that cyrus-sasl2-heimdal-dbg diverts the file. What does everyone think? I guess that it would have helped me quite a lot to know that this bug had a reply and it was now ignored for quite a month, but it seems that the reply above was not sent to the BTS and only to the mailing list: http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/2010-October/001957.html So, it appears that there are some other possibilities, thanks to a posting by Luca Capello [0]. Is there any reason why you did not Cc: me? I was wondering if this bug was forgot, given that I did not receive any update on it (and no, going to the BTS or subscribing to *every* bug someone is interacting with it is not an acceptable solution). My apologies. That was an oversight on my part. The first possibility is trivial, but is not as correct. The second is more correct but a larger diff. Given that this must go into Lenny, what opinion or preference does the release team have on the matter? [...] Given the just announced deep freeze, I'd like some guidance from the release team on this, so that I can prepare an update with an acceptable fix to go into Squeeze. I am not a library expert, but you cannot install both libraries together: = l...@gismo:~$ apt-cache show libsasl2-modules-gssapi-mit | grep Conflicts Conflicts: libsasl2-modules-gssapi-heimdal l...@gismo:~$ = So, if you want to debug the GSSAPI Heimdal library you need cyrus-sasl2-heimdal-dbg and, I guess, at the same time libsasl2-modules-gssapi-heimdal. Given that the latter conflicts with the former, it seems clear that the correct approach is the second option I proposed. Thanks. Would the release team be willing to accept an upload consisting of the patch which Luca provided to fix #601977? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bug#601977: cyrus-sasl2-heimdal-dbg: file conflict during upgrade from lenny
On Sun, Nov 28, 2010 at 04:14:50PM -0500, Roberto C. Sánchez wrote: On Sun, Oct 31, 2010 at 04:11:07PM -0400, Roberto C. Sánchez wrote: I'd be interested to know if anyone has a recommendation on how to handle this. The two packages in question are -dbg packages that are created by dh_strip, excerpted from debian/rules below: dh_strip -s -psasl2-bin -plibsasl2-2 -plibsasl2-modules -plibsasl2-modules-ldap -plibsasl2-modules-otp -plibsasl2-modules-sql -plibsasl2-modules-gssapi-mit -plibsasl2-dev -Nlibsasl2-modules-gssapi-heimdal --dbg-package=cyrus-sasl2-dbg dh_strip -s -plibsasl2-modules-gssapi-heimdal -Nsasl2-bin -Nlibsasl2-2 -Nlibsasl2-modules -Nlibsasl2-modules-ldap -Nlibsasl2-modules-otp -Nlibsasl2-modules-sql -Nlibsasl2-modules-gssapi-mit -Nlibsasl2-dev --dbg-package=cyrus-sasl2-heimdal-dbg Both packages need to be able to be installed together, so my question centers around whehter it is OK to put a diversion in place so that cyrus-sasl2-heimdal-dbg diverts the file. What does everyone think? So, it appears that there are some other possibilities, thanks to a posting by Luca Capello [0]. The first possibility is trivial, but is not as correct. The second is more correct but a larger diff. Given that this must go into Lenny, what opinion or preference does the release team have on the matter? Regards, -Roberto [0] http://bugs.debian.org/610977 Given the just announced deep freeze, I'd like some guidance from the release team on this, so that I can prepare an update with an acceptable fix to go into Squeeze. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Normal kernel being before the Xen hypervisor in Squeeze
On Fri, Dec 10, 2010 at 05:40:02PM +0100, Julien Cristau wrote: On Sat, Dec 11, 2010 at 00:19:34 +0800, Thomas Goirand wrote: I was tempted to write a RC bug report here. Please let me know what you think of this, and I may write one report. No. Really? No? I have production servers in a remote facility. The configuration is such that if none of the guests come up, the machines are not reachable over the network. This sort of a configuration change seems the sort of thing that could cause problems. Do you say 'no' to Thomas writing a RC bug report because this is clearly documented in the release notes somewhere? I checked the release notes and couldn't find anything about this. Did I miss something? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bug#601977: cyrus-sasl2-heimdal-dbg: file conflict during upgrade from lenny
On Sun, Oct 31, 2010 at 04:11:07PM -0400, Roberto C. Sánchez wrote: I'd be interested to know if anyone has a recommendation on how to handle this. The two packages in question are -dbg packages that are created by dh_strip, excerpted from debian/rules below: dh_strip -s -psasl2-bin -plibsasl2-2 -plibsasl2-modules -plibsasl2-modules-ldap -plibsasl2-modules-otp -plibsasl2-modules-sql -plibsasl2-modules-gssapi-mit -plibsasl2-dev -Nlibsasl2-modules-gssapi-heimdal --dbg-package=cyrus-sasl2-dbg dh_strip -s -plibsasl2-modules-gssapi-heimdal -Nsasl2-bin -Nlibsasl2-2 -Nlibsasl2-modules -Nlibsasl2-modules-ldap -Nlibsasl2-modules-otp -Nlibsasl2-modules-sql -Nlibsasl2-modules-gssapi-mit -Nlibsasl2-dev --dbg-package=cyrus-sasl2-heimdal-dbg Both packages need to be able to be installed together, so my question centers around whehter it is OK to put a diversion in place so that cyrus-sasl2-heimdal-dbg diverts the file. What does everyone think? So, it appears that there are some other possibilities, thanks to a posting by Luca Capello [0]. The first possibility is trivial, but is not as correct. The second is more correct but a larger diff. Given that this must go into Lenny, what opinion or preference does the release team have on the matter? Regards, -Roberto [0] http://bugs.debian.org/610977 -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Upload pre-approval for shorewall/4.4.11.6-2
On Fri, Oct 29, 2010 at 02:02:13PM +0200, Mehdi Dogguy wrote: On 29/10/2010 04:22, Roberto C. Sánchez wrote: Release team, I would like approval to upload shorewall/4.4.11.6-2. Please see the attached diff for all of the changes. It looks ok. Please go ahead with the upload and let us know once the pacakge has been uploaded and accepted. (Please upload shorewall *only*) Uploaded. Only shorewall. I have spoken to the main upstream author and asked that he just provide patches for individual packages, rather than a new upstream release of all the packages. Thanks for the unblock. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Upload pre-approval for shorewall/4.4.11.6-2
Release team,
I would like approval to upload shorewall/4.4.11.6-2. Please see the
attached diff for all of the changes.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
diff --git a/Perl/Shorewall/Tc.pm b/Perl/Shorewall/Tc.pm
index 86808e6..fad39b7 100644
--- a/Perl/Shorewall/Tc.pm
+++ b/Perl/Shorewall/Tc.pm
@@ -1279,7 +1279,7 @@ sub setup_traffic_shaping() {
my $tcref= $tcclasses{$device}{$decimalclassnum};
my $mark = $tcref-{mark};
my $devicenumber = in_hexp $devref-{number};
- my $classid = join( ':', in_hexp $devicenumber, $classnum);
+ my $classid = join( ':', $devicenumber, $classnum);
my $rate = $tcref-{rate}kbit;
my $quantum = calculate_quantum $rate, calculate_r2q( $devref-{out_bandwidth} );
@@ -1304,15 +1304,15 @@ sub setup_traffic_shaping() {
emit ( [ \$${dev}_mtu -gt $quantum ] quantum=\$${dev}_mtu || quantum=$quantum );
if ( $devref-{qdisc} eq 'htb' ) {
- emit ( run_tc class add dev $device parent $devref-{number}:$parent classid $classid htb rate $rate ceil $tcref-{ceiling}kbit prio $tcref-{priority} \$${dev}_mtu1 quantum \$quantum );
+ emit ( run_tc class add dev $device parent $devicenumber:$parent classid $classid htb rate $rate ceil $tcref-{ceiling}kbit prio $tcref-{priority} \$${dev}_mtu1 quantum \$quantum );
} else {
my $dmax = $tcref-{dmax};
if ( $dmax ) {
my $umax = $tcref-{umax} ? $tcref-{umax}b : \${${dev}_mtu}b;
- emit ( run_tc class add dev $device parent $devref-{number}:$parent classid $classid hfsc sc umax $umax dmax ${dmax}ms rate $rate ul rate $tcref-{ceiling}kbit );
+ emit ( run_tc class add dev $device parent $devicenumber:$parent classid $classid hfsc sc umax $umax dmax ${dmax}ms rate $rate ul rate $tcref-{ceiling}kbit );
} else {
- emit ( run_tc class add dev $device parent $devref-{number}:$parent classid $classid hfsc sc rate $rate ul rate $tcref-{ceiling}kbit );
+ emit ( run_tc class add dev $device parent $devicenumber:$parent classid $classid hfsc sc rate $rate ul rate $tcref-{ceiling}kbit );
}
}
diff --git a/changelog.txt b/changelog.txt
index 5b2676f..2970dad 100644
--- a/changelog.txt
+++ b/changelog.txt
@@ -1,3 +1,7 @@
+Changes post 4.4.11.6
+
+1) Fix 10+ TC Interfaces.
+
Changes in Shorewall 4.4.11.6
1) Fix log reading in -lite packages.
diff --git a/debian/changelog b/debian/changelog
index 1ce46d8..6009942 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+shorewall (4.4.11.6-2) unstable; urgency=low
+
+ * Incorporate patch from upstream: Fix 10+ TC Interfaces.
+
+ -- Roberto C. Sanchez robe...@connexer.com Thu, 28 Oct 2010 22:12:15 -0400
+
shorewall (4.4.11.6-1) unstable; urgency=low
* New Upstream Version
diff --git a/known_problems.txt b/known_problems.txt
index c3cc35a..002f4cb 100644
--- a/known_problems.txt
+++ b/known_problems.txt
@@ -147,3 +147,17 @@
showed an empty log when issued to one of the -lite packages.
Corrected in Shorewall 4.4.11.6
+
+22) If 10 or more interfaces are configured in Complex Traffic Shaping
+(/etc/shorewall/tcdevices), the following compilation diagnostic
+is issued:
+
+Argument a isn't numeric in sprintf at
+ /usr/share/shorewall/Shorewall/Config.pm line 893.
+
+and an invalid TC configuration is generated.
+
+A fix is available at
+http://shorewall.git.sourceforge.net/git/gitweb.cgi?p=shorewall/shorewall;a=commitdiff;h=20bb781874c739c01b798d2db31b6c1d9cfefe96
+
+
diff --git a/releasenotes.txt b/releasenotes.txt
index 43ef45e..b0671fb 100644
--- a/releasenotes.txt
+++ b/releasenotes.txt
@@ -218,6 +218,17 @@ VI. PROBLEMS CORRECTED AND NEW FEATURES IN PRIOR RELEASES
I I I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E
+Post-4.4.11.6
+
+1) Previously, if 10 or more interfaces were configured in Complex
+Traffic Shaping (/etc/shorewall/tcdevices), the following
+compilation diagnostic was generated:
+
+Argument a isn't numeric in sprintf at
+ /usr/share/shorewall/Shorewall/Config.pm line 893.
+
+and an invalid TC configuration was generated.
+
4.4.11.6
1) The Shorewall-lite and Shorewall6-lite Debian init scripts contained a
signature.asc
Description: Digital signature
Re: Question regarding new shorewall-* upstream version
On Tue, Oct 12, 2010 at 06:49:42PM +0100, Adam D. Barratt wrote: On Mon, 2010-10-11 at 19:10 -0400, Roberto C. Sánchez wrote: Also note, that due to a mistake in the 4.4.11.6 release, some necessary changes were left out (namely some changelog and release notes entries, as well the last bit of changes dealing with the SAME target issue). I have attached updated diffs. Thanks. Please go ahead with the uploads. I have uploaded. Please unblock at your leisure. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Question regarding new shorewall-* upstream version
Did none of the Release Team see this? Some guidance on this would be much appreciated. Regards, -Roberto On Fri, Oct 01, 2010 at 09:29:08PM -0400, Roberto C. Sánchez wrote: Shorewall upstream has released to small point releases specifically with targeted fixes that should make it into the shorewall-* packages that are currently in Squeeze. I have attached the diffs for each of the packages. Please note that the real changes are actually quite small, and that quite a few of the changes (like all of the changes in the various man pages) are version number updates. That said, it is possible to cherry pick just specific changes and upload -2 versions of the affected packages. However, it is preferrable for the new upstream versions to be uploaded as they are specifically targeted for Squeeze. I am looking for some guidance from the release team on whether or not it is possible to approve the attached diff, or if I need to prepare -2 versions with still more limited changes. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bug#595444: release.debian.org: unblock shorewall{,6,-lite,6-lite,-init}/4.4.11.4-1
It appears that my below request did not receive any attention as shorewall migrated today by itself. I would like to renew my request for an unblock of shorewall6, shorewall-lite, shorewall6-lite and shorewall-init. The changes in these packages are trivial (release notes and version numbers in some of the scripts), and would help to avert a potential source of confusion among users. Regards, -Roberto On Sat, Sep 04, 2010 at 03:46:25PM -0400, Roberto C. Sánchez wrote: reopen 594144 thanks On Sat, Sep 04, 2010 at 05:04:52PM +0200, Julien Cristau wrote: On Fri, Sep 3, 2010 at 20:13:07 -0400, Roberto C. Sanchez wrote: This new upstream release is specifically targeted for Squeeze. The relevant changelog entry is: shorewall (4.4.11.4-1) unstable; urgency=low . * New Upstream Version (Closes: #594144) That's not a relevant changelog entry. It would be if 594144 was a request for packaging the new upstream release, and testing wasn't frozen. Well, the relevant entry from the upstream changelog is: Fix REQUIRE_INTERFACE=Yes Hopefully that is more relevant. shorewall unblocked, the rest of them left alone. I'm not sure I understand the reasoning behind this. The only changes in the rest of the packages are the changes resulting from the change in version number. That is, it is about as invasive as an updated translation or updated documentation. While technically it is possible to have shorewall6 4.4.11.3-1 installed alongside shorewall 4.4.11.4-1, it will likely result in confusion for users. Upstream always releases all the packages as a group, and anyone who uses Shorewall outside of Debian will always get them together as a group with the same version number. And it is has also been that way with the official Debian packages for quite some time. I encourage you to reconsider and permit the rest of the packages into testing. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#595444: release.debian.org: unblock shorewall{,6,-lite,6-lite,-init}/4.4.11.4-1
reopen 594144 thanks On Sat, Sep 04, 2010 at 05:04:52PM +0200, Julien Cristau wrote: On Fri, Sep 3, 2010 at 20:13:07 -0400, Roberto C. Sanchez wrote: This new upstream release is specifically targeted for Squeeze. The relevant changelog entry is: shorewall (4.4.11.4-1) unstable; urgency=low . * New Upstream Version (Closes: #594144) That's not a relevant changelog entry. It would be if 594144 was a request for packaging the new upstream release, and testing wasn't frozen. Well, the relevant entry from the upstream changelog is: Fix REQUIRE_INTERFACE=Yes Hopefully that is more relevant. shorewall unblocked, the rest of them left alone. I'm not sure I understand the reasoning behind this. The only changes in the rest of the packages are the changes resulting from the change in version number. That is, it is about as invasive as an updated translation or updated documentation. While technically it is possible to have shorewall6 4.4.11.3-1 installed alongside shorewall 4.4.11.4-1, it will likely result in confusion for users. Upstream always releases all the packages as a group, and anyone who uses Shorewall outside of Debian will always get them together as a group with the same version number. And it is has also been that way with the official Debian packages for quite some time. I encourage you to reconsider and permit the rest of the packages into testing. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Please unblock shorewall{,-lite,6,6-lite,-init}/4.4.11.3-1
On Fri, Aug 27, 2010 at 10:06:32AM +0200, Mehdi Dogguy wrote: On 08/26/2010 09:46 PM, Roberto C. Sánchez wrote: Ping. Pong… What's confusing is that upstream's changelog appears in all of those packages but the changes are only in the first one… Upstream seem also to advertize 4.4.11.3 as available in Debian Squeeze :) So, it appears that you got you freeze exception elsewhere. It appears that shorewall-init was left out. It would excellent if someone could unblock it so that 4.4.11.3-1 can make it into Squeeze. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Please unblock shorewall{,-lite,6,6-lite,-init}/4.4.11.3-1
On Fri, Aug 27, 2010 at 10:06:32AM +0200, Mehdi Dogguy wrote: On 08/26/2010 09:46 PM, Roberto C. Sánchez wrote: Ping. Pong… What's confusing is that upstream's changelog appears in all of those packages but the changes are only in the first one… That is because upstream has six separate release packages (shorewall, shorewall6, shorewall-lite, shorewall6-lite, shorewall-init, shorewall-doc) and releases them all for every release or point release (whether or not there were changes in every individual package) but then uses only a single consolidated changelog. Upstream seem also to advertize 4.4.11.3 as available in Debian Squeeze :) So, it appears that you got you freeze exception elsewhere. This must be a typo. I know that 4.4.11.2 is already there and the 2 and the 3 are right next to each other on the qwerty keyboard :-) Thanks very much for the unblock. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Please unblock shorewall{,-lite,6,6-lite,-init}/4.4.11.3-1
Ping. On Sun, Aug 22, 2010 at 09:48:24PM -0400, Roberto C. Sánchez wrote: With attachments this time. On Sun, Aug 22, 2010 at 09:45:15PM -0400, Roberto C. Sánchez wrote: I have uploaded version 4.4.11.3-1 of shorewall, shorewall-lite, shorewall6, shorewall6-lite and shorewall-init. This is a new upstream version with three very small targeted fixes. The diffs are attached, and please keep in mind that many of the changes are updates in the version numbers in the various source files and then things like dates in the generated man pages. Please allow these packages to migrate to squeeze. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Request for pre-approval of cyrus-sasl2 upload
Ping. On Mon, Aug 23, 2010 at 06:27:43PM -0400, Roberto C. Sánchez wrote: On Tue, Aug 24, 2010 at 12:06:56AM +0200, Julien Cristau wrote: is going to succeed even if configure doesn't. Should probably use something like mkdir $(TMPBUILD_MIT) cd $(TMPBUILD_MIT) \ LDFLAGS=$(LDFLAGS) -L/usr/lib/mit-krb5 -Wl,-z,defs \ CFLAGS=$(CFLAGS) CPPFLAGS=$(CPPFLAGS) -I/usr/include/mit-krb5 \ ../configure $(CONFIGURE_COMMON_OPTIONS) --with-gss_impl=mit i.e. without the unnecessary subshell and '; cd ..' after configure. Probably same with the $(MAKE) invocation. Ah, yes. Thanks very much for catching that. I have made the recommended change for both instances of the ../configure invocation. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Request for pre-approval of cyrus-sasl2 upload
On Tue, Aug 24, 2010 at 12:06:56AM +0200, Julien Cristau wrote: is going to succeed even if configure doesn't. Should probably use something like mkdir $(TMPBUILD_MIT) cd $(TMPBUILD_MIT) \ LDFLAGS=$(LDFLAGS) -L/usr/lib/mit-krb5 -Wl,-z,defs \ CFLAGS=$(CFLAGS) CPPFLAGS=$(CPPFLAGS) -I/usr/include/mit-krb5 \ ../configure $(CONFIGURE_COMMON_OPTIONS) --with-gss_impl=mit i.e. without the unnecessary subshell and '; cd ..' after configure. Probably same with the $(MAKE) invocation. Ah, yes. Thanks very much for catching that. I have made the recommended change for both instances of the ../configure invocation. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Request for pre-approval of cyrus-sasl2 upload
On Sun, Aug 22, 2010 at 11:59:06AM +0100, Julien Cristau wrote: On Sun, Aug 22, 2010 at 00:21:39 -0400, Roberto C. Sánchez wrote: Release Team, I would like to request pre-approval to upload cyrus-sasl2 (2.1.23.dfsg1-6) to sid, with the goal of having it migrate to squeeze. Please note that a very important point about this request is that the -6 package would have to pass through NEW. It's not clear to me why it would need that. All binary packages already exist in the archive overrides. Perhaps I misremember, but I seem to recall that with the shorewall-* packages, when things changed around and binary packages moved from one source package to another, that there was NEW processing involved. If that is not the case and I am indeed mistaken, then so much the better. [...] Today, thanks to the avilability of the heimdal-multidev and krb5-multidev packages, it is possible to have the MIT and Heimdal Kerberos -dev libraries concurrently installed. This makes it possible to build against both from within one source package. Merging the two source packages into one would eliminate both of these issues. Having both of these issues persist through the life of Squeeze would, IMHO, be a Bad Thing(TM). Seems like a rather good idea to me. Now a few questions on the details (not necessarily problems, just thoughts I had while looking over the diff): README.Debian-NMU | 11 -- changelog |9 + control | 29 + Can you explain why cyrus-sasl2-heimdal-dbg needs to depend on cyrus-sasl2-dbg? The cyrus-sasl2-dbg package contains debug symbols for all binaries (everything in sasl2-bin, which has stuff in /usr/bin and /usr/sbin) and also all libraries (all of the various modules, like LDAP, OTP, etc). The cyrus-sasl2-heimdal-dbg contains only debug symbols for the libgssapiv2.so.2.0.23 library as it is compiled against Heimdal Kerberos (the debug symbols for that library as it is compiled against MIT Kerberos are contained in the cyrus-sasl2-dbg package). In order to allow a user who wishes to use debugging symbols the ability to have all symbols available, whether he chooses to use the Heimdal Kerberos or MIT Kerberos variants of GSSAPI, the cyrus-sasl2-heimdal-dbg package depends on cyrus-sasl2-dbg, and diverts libgssapiv2.so.2.0.23 contained in the latter package. This is a recent change, as of the NMU upload of 2.1.23.dfsg1-5.1. Prior to that, cyrus-sasl2-heimdal-dbg conflicted with cyrus-sasl2-dbg, meaning that users could not have the complete set of debugging symbols installed if they also wanted the Heimdal variant's debug symbols. (Sorry for the longwinded explanation.) cyrus-sasl2-heimdal-dbg.postrm| 10 + cyrus-sasl2-heimdal-dbg.preinst | 10 + Is the name /usr/lib/sasl2/libgssapiv2.so.2.0.23 stable? If not it seems easy for this to get out of sync with the actual file name. I believe that it is stable. Also, ti is worth pointing out that this is a private library file (contained in /usr/lib/sasl2/ instead of in /usr/lib/). libsasl2-modules-gssapi-heimdal.dirs |2 Seems like these directories would get created by dh_install/dh_lintian anyway. Is this necessary? I've been meaning to clean up the packaging and move over to dh7 in the process. However, given that the freeze surprised me, I am trying to keep the changes as targeted as possible. libsasl2-modules-gssapi-heimdal.install |1 libsasl2-modules-gssapi-heimdal.lintian-overrides |2 patches/0024_allow_detection_of_heimdal.dpatch| 22 That patch looks like a kludge around a broken configure check for GSS_C_NT_HOSTBASED_SERVICE. Can you explain it a bit more? Russ Allbery can provide a much more lucid explanation, but the short version is that in the new Heimdal headers, the way in which GSS_C_NT_HOSTBASED_SERVICE gets defined confuses the AC_EGREP_HEADER check that the cyrsus-sasl2 build system uses. According to Russ, there is a better AC macro available, but the version of autoconf currently used in cyrus-sasl2 is too old to support it. So, yes, it is a bit of a kludge. patches/00list|1 rules | 114 -- May I suggest to put the common configure flags for the two variants in a variable, both so it's easier to see the differences and so they don't diverge by mistake in the future? I will do that. The run make, expect failure, run make again thing is... interesting :) Interesting was not the word that came to mind for me :-) The dh_install calls are a bit weird, mixing -s, -pfoo and -Nbar args. I agree. However, I found that for some reason if I did not use the -p and -N on each invocation (specifying in each
Re: Request for pre-approval of cyrus-sasl2 upload
On Sun, Aug 22, 2010 at 02:28:37PM -0400, Roberto C. Sánchez wrote: Assuming that my explanations are satisfactory, did you want to see a new diff for placing the configure options into a variable? I went ahead and finished making the changes just now. The updated diff is attached. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com cyrus-sasl2_consolidation.diff.gz Description: Binary data signature.asc Description: Digital signature
Please unblock shorewall{,-lite,6,6-lite,-init}/4.4.11.3-1
I have uploaded version 4.4.11.3-1 of shorewall, shorewall-lite, shorewall6, shorewall6-lite and shorewall-init. This is a new upstream version with three very small targeted fixes. The diffs are attached, and please keep in mind that many of the changes are updates in the version numbers in the various source files and then things like dates in the generated man pages. Please allow these packages to migrate to squeeze. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Please unblock shorewall{,-lite,6,6-lite,-init}/4.4.11.3-1
With attachments this time. On Sun, Aug 22, 2010 at 09:45:15PM -0400, Roberto C. Sánchez wrote: I have uploaded version 4.4.11.3-1 of shorewall, shorewall-lite, shorewall6, shorewall6-lite and shorewall-init. This is a new upstream version with three very small targeted fixes. The diffs are attached, and please keep in mind that many of the changes are updates in the version numbers in the various source files and then things like dates in the generated man pages. Please allow these packages to migrate to squeeze. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com shorewall_4.4.11.2-1_4.4.11.3-1.diff.gz Description: Binary data shorewall-lite_4.4.11.2-1_4.4.11.3-1.diff.gz Description: Binary data shorewall6_4.4.11.2-1_4.4.11.3-1.diff.gz Description: Binary data shorewall6-lite_4.4.11.2-1_4.4.11.3-1.diff.gz Description: Binary data shorewall-init_4.4.11.2-1_4.4.11.3-1.diff.gz Description: Binary data signature.asc Description: Digital signature
Request for pre-approval of cyrus-sasl2 upload
Release Team, I would like to request pre-approval to upload cyrus-sasl2 (2.1.23.dfsg1-6) to sid, with the goal of having it migrate to squeeze. Please note that a very important point about this request is that the -6 package would have to pass through NEW. (Please see the attached diffstat and compressed diff for the gory details, as what follows is a narrative description of the situation.) This is the associated changelog entry: cyrus-sasl2 (2.1.23.dfsg1-6) unstable; urgency=low * Merge cyrus-sasl2 and cyrus-sasl2-heimdal source packages (Closes: #568358) + Build against new heimdal-multidev (Closes: #591147) * Properly detect presence of Heimdal (Closes: #590912); thanks tremendously to Russ Allbery for the patch Of the bug closures, #568358 is severity normal (but has significant positive security implications for the life of Squeeze), and then #591147 is severity grave and #590912 is severity serious. Additionally, #582040 (also severity grave) was closed in an NMU, but its propogation is being held up by the other two RC bugs. I will focus my comments on #568358 as the others are self explanatory. Several years ago, it was requested that version of the SASL GSSAPI modules compiled against the Heimdal Kerberos library be provided. At the time, the only modules available were compiled against MIT Kerberos. Users desiring Heimdal versions had to rebuild the package themselves. Part of the reason for that was that it was not possible to simultaneously install the Hiemdal and MIT Kerberos -dev packages, preventing the building of both sets of modules from a single source package. The solution at the time was to add a second source package (cyrus-sasl2-heimdal). This was less than optimal, but the only available option. This has resulted in some major annoyances: - Any upload of cyrus-sasl2 or cyrus-sasl2-heimdal must be accompanied by a source-ful upload of the other package, carrying the same source version (this impacts both NMUs and security uploads) - The debian/ directories must be manually kept in sync Today, thanks to the avilability of the heimdal-multidev and krb5-multidev packages, it is possible to have the MIT and Heimdal Kerberos -dev libraries concurrently installed. This makes it possible to build against both from within one source package. Merging the two source packages into one would eliminate both of these issues. Having both of these issues persist through the life of Squeeze would, IMHO, be a Bad Thing(TM). Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com cyrus-sasl2_consolidation.diff.gz Description: Binary data README.Debian-NMU | 11 -- changelog |9 + control | 29 + cyrus-sasl2-heimdal-dbg.postrm| 10 + cyrus-sasl2-heimdal-dbg.preinst | 10 + libsasl2-modules-gssapi-heimdal.dirs |2 libsasl2-modules-gssapi-heimdal.install |1 libsasl2-modules-gssapi-heimdal.lintian-overrides |2 patches/0024_allow_detection_of_heimdal.dpatch| 22 patches/00list|1 rules | 114 -- sample/Makefile |7 - 12 files changed, 172 insertions(+), 46 deletions(-) signature.asc Description: Digital signature
Re: Permission to upload new Shorewall point release
On Tue, Aug 10, 2010 at 08:37:09PM +0100, Adam D. Barratt wrote: On Mon, 2010-08-09 at 21:30 -0400, Roberto C. Sánchez wrote: The Shorewall upstream team was caught off guard by the freeze (I know that this is a recurring theme). While the Shorewall team was preparing a new upstream release, we realize that it is excedingly unlikely that the scope of changes would be acceptable for a freeze exception. To that end, Shorewall upstream has released a new point release (4.4.11.2) that is specifically intended for Squeeze. Please go ahead and let us know once the packages have been accepted. The packages have been uploaded and accepted. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Permission to upload new Shorewall point release
On Tue, Aug 10, 2010 at 10:24:32PM +0100, Adam D. Barratt wrote:
On Tue, 2010-08-10 at 17:13 -0400, Roberto C. Sánchez wrote:
On Tue, Aug 10, 2010 at 08:37:09PM +0100, Adam D. Barratt wrote:
On Mon, 2010-08-09 at 21:30 -0400, Roberto C. Sánchez wrote:
The Shorewall upstream team was caught off guard by the freeze (I know
that this is a recurring theme).
While the Shorewall team was preparing a new upstream release, we
realize that it is excedingly unlikely that the scope of changes would
be acceptable for a freeze exception. To that end, Shorewall upstream
has released a new point release (4.4.11.2) that is specifically
intended for Squeeze.
Please go ahead and let us know once the packages have been accepted.
The packages have been uploaded and accepted.
shorewall{,6} unblocked.
Please note, the uploaded packages were:
shorewall, shorewall6, shorewall-lite, shorewall6-lite, shorewall-init
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Re: Permission to upload new Shorewall point release
On Tue, Aug 10, 2010 at 11:30:49PM +0100, Adam D. Barratt wrote:
On Tue, 2010-08-10 at 17:26 -0400, Roberto C. Sánchez wrote:
On Tue, Aug 10, 2010 at 10:24:32PM +0100, Adam D. Barratt wrote:
shorewall{,6} unblocked.
Please note, the uploaded packages were:
shorewall, shorewall6, shorewall-lite, shorewall6-lite, shorewall-init
Oops; sorry about that. They're now all unblocked.
Thanks very much for the quick reply.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Permission to upload new Shorewall point release
Greetings RMs, The Shorewall upstream team was caught off guard by the freeze (I know that this is a recurring theme). While the Shorewall team was preparing a new upstream release, we realize that it is excedingly unlikely that the scope of changes would be acceptable for a freeze exception. To that end, Shorewall upstream has released a new point release (4.4.11.2) that is specifically intended for Squeeze. I would appreciate it if permission would be granted to upload this version for eventual migration to squeeze. I have attached the individual compressed diffs (Shorewall upstream releases each component as a seperate release tarball) and a diffstat that covers all of the diffs, combined. Please note that the changes are spread across 5 packages and the bulk of the changes are documentation, releasenotes and header updates in the man pages. I have the packages built and am waiting for approval before I upload. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com b/Perl/Shorewall/Actions.pm | 11 +- b/Perl/Shorewall/Chains.pm |2 b/Perl/Shorewall/Config.pm |3 b/Perl/Shorewall/IPAddrs.pm | 16 +-- b/Perl/Shorewall/Rules.pm| 22 ++-- b/Perl/Shorewall/Zones.pm| 35 ++ b/Perl/prog.header |2 b/changelog.txt | 23 b/ifupdown.sh|6 - b/init.debian.sh | 21 +++- b/init.sh| 30 +++-- b/install.sh |2 b/known_problems.txt | 69 + b/manpages/shorewall-accounting.5|4 b/manpages/shorewall-actions.5 |4 b/manpages/shorewall-blacklist.5 |4 b/manpages/shorewall-ecn.5 |4 b/manpages/shorewall-exclusion.5 |4 b/manpages/shorewall-hosts.5 |4 b/manpages/shorewall-init.8 |4 b/manpages/shorewall-interfaces.5|4 b/manpages/shorewall-lite-vardir.5 |4 b/manpages/shorewall-lite.8 |4 b/manpages/shorewall-lite.conf.5 |4 b/manpages/shorewall-maclist.5 |4 b/manpages/shorewall-masq.5 |4 b/manpages/shorewall-modules.5 |4 b/manpages/shorewall-nat.5 |4 b/manpages/shorewall-nesting.5 |4 b/manpages/shorewall-netmap.5|4 b/manpages/shorewall-notrack.5 |4 b/manpages/shorewall-params.5|4 b/manpages/shorewall-policy.5|4 b/manpages/shorewall-providers.5 |4 b/manpages/shorewall-proxyarp.5 |4 b/manpages/shorewall-route_rules.5 |4 b/manpages/shorewall-routestopped.5 |4 b/manpages/shorewall-rules.5 | 73 -- b/manpages/shorewall-tcclasses.5 |4 b/manpages/shorewall-tcdevices.5 |4 b/manpages/shorewall-tcfilters.5 |4 b/manpages/shorewall-tcinterfaces.5 |4 b/manpages/shorewall-tcpri.5 |4 b/manpages/shorewall-tcrules.5 |4 b/manpages/shorewall-tos.5 |4 b/manpages/shorewall-tunnels.5 |4 b/manpages/shorewall-vardir.5|4 b/manpages/shorewall-zones.5 |4 b/manpages/shorewall.8 |4 b/manpages/shorewall.conf.5 |4 b/manpages/shorewall6-accounting.5 |4 b/manpages/shorewall6-actions.5 |4 b/manpages/shorewall6-blacklist.5|4 b/manpages/shorewall6-exclusion.5|4 b/manpages/shorewall6-hosts.5|4 b/manpages/shorewall6-interfaces.5 |4 b/manpages/shorewall6-lite-vardir.5 |4 b/manpages/shorewall6-lite.8 |4 b/manpages/shorewall6-lite.conf.5|4 b/manpages/shorewall6-maclist.5 |4 b/manpages/shorewall6-modules.5 |4 b/manpages/shorewall6-nesting.5 |4 b/manpages/shorewall6-notrack.5 |4 b/manpages/shorewall6-params.5 |4 b/manpages/shorewall6-policy.5 |4 b/manpages/shorewall6-providers.5|4 b/manpages/shorewall6-route_rules.5 |4 b/manpages/shorewall6-routestopped.5 |4 b/manpages/shorewall6-rules.5|4 b/manpages/shorewall6-tcclasses.5|4 b/manpages/shorewall6-tcdevices.5|4 b/manpages/shorewall6-tcinterfaces.5 |4 b/manpages/shorewall6-tcpri.5|4 b/manpages/shorewall6-tcrules.5 |4 b/manpages/shorewall6-tos.5 |4 b/manpages/shorewall6-tunnels.5 |4 b/manpages/shorewall6-vardir.5 |4 b/manpages/shorewall6-zones.5|4 b/manpages/shorewall6.8 |4 b/manpages/shorewall6.conf.5 |4 b/releasenotes.txt | 44 b/shorecap |2 b/shorewall | 12 +- b/shorewall-init.spec|6 - b/shorewall-lite
Re: Can I upload this new xl2tpd upstream release?
On Fri, Aug 06, 2010 at 03:42:02PM -0400, Julien Cristau wrote: On Fri, Aug 6, 2010 at 13:43:40 -0400, Roberto C. Sánchez wrote: Greetings RMs, I have been corresponding with upstream for xl2tpd, and they just last night released a new minor upstream version (1.2.7, with 1.2.6 being the current version in Debian). I'd like pre-approval to upload the new upstream version (diffstat and compressed complete diff are attached) as I would like to see it in Squeeze. Please note that the new upstream release closes #578070 and #589306. Looks reasonable enough, please go ahead (and get back to me when it's uploaded for the actual unblock). I have just uploaded it a few minutes ago. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Can I upload this new xl2tpd upstream release?
Greetings RMs, I have been corresponding with upstream for xl2tpd, and they just last night released a new minor upstream version (1.2.7, with 1.2.6 being the current version in Debian). I'd like pre-approval to upload the new upstream version (diffstat and compressed complete diff are attached) as I would like to see it in Squeeze. Please note that the new upstream release closes #578070 and #589306. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com xl2tpd_1.2.6_1.2.7.diff.bz2 Description: Binary data CHANGES |7 ++ Makefile |4 +-- avp.c |4 +-- call.c| 17 control.c | 12 +++ debian/changelog |6 + doc/l2tpd.conf.sample |5 +++- doc/xl2tpd.conf.5 |7 ++ file.c| 45 +++ file.h|4 +++ l2tp.h|2 + misc.h|1 network.c |1 xl2tpd.c | 52 +- 14 files changed, 136 insertions(+), 31 deletions(-) signature.asc Description: Digital signature
Re: tbb has not been built on ia64; why?
On Tue, Jun 08, 2010 at 08:52:22AM +0200, Andreas Barth wrote: * Roberto C. Sánchez (robe...@connexer.com) [100608 00:56]: I was looking at the status of tbb, and apparently it has not propogated to testing because of not being build on ia64. One buildd status page says Build-Attempted, but doesn't provide a link to a build log. Does anyone know what is going on with it? Given back, we'll let have it another try. Strange. It is now in the building state for more than two days. Still no log. Any ideas? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
tbb has not been built on ia64; why?
I was looking at the status of tbb, and apparently it has not propogated to testing because of not being build on ia64. One buildd status page says Build-Attempted, but doesn't provide a link to a build log. Does anyone know what is going on with it? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: potential removals from testing
On Tue, Mar 23, 2010 at 04:53:20PM +, Robert Lemmen wrote: libtzinfo-ruby rc-buggy: #503591 low popcon not in stable I'd like to see if we can make certain that Rails will not need to depend on this. Incidentally, the rc-bugginess is probably debatable. That, and upstream has committed to fixing the issue (by making it easy to package a binary release of the package without the actual timezone data files), but has not committed to a timeline. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#573272: transition: ruby1.9 - ruby1.9.1
On Tue, Mar 23, 2010 at 09:19:19PM +0100, Lucas Nussbaum wrote: Roberto C. Sanchez robe...@connexer.com libi18n-ruby (U) So, this package does not depend on ruby1.9 any longer. It seems as though an NMU [0] closed #569875. However, that closure note in the changelog never carried through to the bug. (However, I am sending this note to the 569875-done as well, so that bug will close). Given that, I do not think that it needs to be removed. Regards, -Roberto [0] http://packages.qa.debian.org/libi/libi18n-ruby/news/20100319T093718Z.html -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#554447: Bug #554447 electricsheep broken for new installations on lenny
On Mon, Nov 30, 2009 at 01:59:42PM +0100, Holger Levsen wrote: Hi Adam, On Dienstag, 17. November 2009, Adam D. Barratt wrote: I've just had a look through the bug log for #533652 (from which this bug against release.debian.org was cloned) and it's unclear to me whether this is a request to remove the current package from Lenny or update it; Well, it was ment as a request for either and for the maintainer to comment on it. As the maintainer has not reacted, I suggest to remove electricsheep from stable, as it is broken (for new installations. Old installs will continue to show old data, but not download new). Hi. My apologies for not responding earlier. I think that removal from Lenny is the best thing, for two reasons: 1. The new electricsheep package depends on the flam3 package, which is new in Squeeze/Sid, probably making a stable update nearly impossible 2. I have limited time to work on the package and I would rather devote that time to fixing bugs Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: give-back tbb on ia64
On Mon, Sep 28, 2009 at 10:56:00AM +0200, Marc 'HE' Brockschmidt wrote: Roberto C. Sánchez robe...@connexer.com writes: Did my request get lost in the noise? Seems so. Given back now. In the future you might want to file a bug instead of simply mailing us, as the BTS is better at tracking issues :-) Thanks for taking care of this. I did see in the last day or so someone take that approach and get a quicker reponse. I will keep it in mind for the next time. :-) Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: give-back tbb on ia64
Did my request get lost in the noise? Regards, -Roberto On Tue, Sep 22, 2009 at 02:47:36PM -0400, Roberto C. Sánchez wrote: It looks like tbb failed on ia64 because of a problem in a texlive package [0]. This, I'd like to request a give-back for tbb on ia64. Regards, -Roberto [0] like so: Preparing to replace texlive-base 2007.dfsg.2-4 (using .../texlive-base_2007.dfsg.2-4_all.deb) ... Reinstalling deleted mandatory conffile modes.mf cp: cannot stat `/usr/share/texlive-base/modes.mf': No such file or directory dpkg: error processing /x/org/chroots/buildd/sid/var/cache/apt/archives/texlive-base_2007.dfsg.2-4_all.deb (--unpack): subprocess pre-installation script returned error exit status 1 Selecting previously deselected package texlive-fonts-recommended. Preparing to replace texlive-fonts-recommended 2007.dfsg.2-4 (using .../texlive-fonts-recommended_2007.dfsg.2-4_all.deb) ... Unpacking replacement texlive-fonts-recommended ... Selecting previously deselected package texlive-latex-base. Preparing to replace texlive-latex-base 2007.dfsg.2-4 (using .../texlive-latex-base_2007.dfsg.2-4_all.deb) ... Reinstalling deleted mandatory conffile color.cfg cp: cannot stat `/usr/share/texlive-base/color.cfg': No such file or directory dpkg: error processing /x/org/chroots/buildd/sid/var/cache/apt/archives/texlive-latex-base_2007.dfsg.2-4_all.deb (--unpack): subprocess pre-installation script returned error exit status 1 Processing triggers for install-info ... Errors were encountered while processing: /x/org/chroots/buildd/sid/var/cache/apt/archives/texlive-base_2007.dfsg.2-4_all.deb /x/org/chroots/buildd/sid/var/cache/apt/archives/texlive-latex-base_2007.dfsg.2-4_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) apt-get failed. -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
give-back tbb on ia64
It looks like tbb failed on ia64 because of a problem in a texlive package [0]. This, I'd like to request a give-back for tbb on ia64. Regards, -Roberto [0] like so: Preparing to replace texlive-base 2007.dfsg.2-4 (using .../texlive-base_2007.dfsg.2-4_all.deb) ... Reinstalling deleted mandatory conffile modes.mf cp: cannot stat `/usr/share/texlive-base/modes.mf': No such file or directory dpkg: error processing /x/org/chroots/buildd/sid/var/cache/apt/archives/texlive-base_2007.dfsg.2-4_all.deb (--unpack): subprocess pre-installation script returned error exit status 1 Selecting previously deselected package texlive-fonts-recommended. Preparing to replace texlive-fonts-recommended 2007.dfsg.2-4 (using .../texlive-fonts-recommended_2007.dfsg.2-4_all.deb) ... Unpacking replacement texlive-fonts-recommended ... Selecting previously deselected package texlive-latex-base. Preparing to replace texlive-latex-base 2007.dfsg.2-4 (using .../texlive-latex-base_2007.dfsg.2-4_all.deb) ... Reinstalling deleted mandatory conffile color.cfg cp: cannot stat `/usr/share/texlive-base/color.cfg': No such file or directory dpkg: error processing /x/org/chroots/buildd/sid/var/cache/apt/archives/texlive-latex-base_2007.dfsg.2-4_all.deb (--unpack): subprocess pre-installation script returned error exit status 1 Processing triggers for install-info ... Errors were encountered while processing: /x/org/chroots/buildd/sid/var/cache/apt/archives/texlive-base_2007.dfsg.2-4_all.deb /x/org/chroots/buildd/sid/var/cache/apt/archives/texlive-latex-base_2007.dfsg.2-4_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) apt-get failed. -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Shorewall package hinting
On Sat, Jul 04, 2009 at 07:10:44PM +0100, Adam D. Barratt wrote: On Wed, 2009-07-01 at 21:03 -0400, Roberto C. Sánchez wrote: #include http://lists.debian.org/debian-release/2009/05/msg00223.html I added a hint for the packages a couple of days ago and they've now migrated. I saw the migration messages. Thanks very much. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Shorewall package hinting
#include http://lists.debian.org/debian-release/2009/05/msg00223.html Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Please hint some shorewall* packages
It apears that the following shorewall* packages require manual hinting: shorewall-common shorewall-perl shorewall-shell shorewall6 Please allow them to propogate to testing. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Please hint shorewall6 and shorewall-{common,perl,shell}
It appears that shorewall6 and shorewall-{common,perl,shell} are all
stuck and cannot migrate. Please manually hint into testing.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Please hint some shorewall* packages
It apears that the following shorewall* packages require manual hinting: shorewall-common shorewall-perl shorewall-shell shorewall6 Please allow them to propogate to testing. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Please unblock shorewall-{common,perl,shell}
It appears that shorewall-{common,perl,shell} are in need of hinting in
order to propogate. I'd appreciate if someone could hint them.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Re: Question about fixing #512075
On Sun, Jan 25, 2009 at 01:22:19PM +0100, Adeodato Simó wrote: * Thomas Weber [Sat, 24 Jan 2009 22:08:31 +0100]: I've patched 1.0.6 instead, it turned out to be only a one-line change. Sadly, the package now FTBFS on ARM only, /usr/bin/ld: cannot find -lgfortranbegin Sigh, back to square one. Okay, CC'ing the arm buildd maintainers to see if the recognice something from the log: http://buildd.debian.org/~luk/status/package.php?p=octave-symbolic#fail-octave-symbolic-arm I wonder if this indicates some sort of issue with the ARM buildd. I just noticed that libwx-perl 0.84-3 (which I uploaded to t-p-u) fails to build only on ARM: http://buildd.debian.org/fetch.cgi?pkg=libwx-perlver=0.84-3arch=armstamp=1232426618file=log However, the previous version of the package in testing (0.84-2) built fine on ARM. Though that last successful build was on Jul 20, 2008. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Why was libwx-perl remvoed from Lenny?
I just saw [0] that libwx-perl was removed from Lenny. Why? The bug referenced in the removal hint (#499740) didn't even affect the version that was in testing (0.84-2), which was the version that was in there as of the freeze and the version I was expecting would release with Lenny. Regards, -Roberto [0] http://packages.qa.debian.org/libw/libwx-perl/news/20090105T163916Z.html -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Why was libwx-perl remvoed from Lenny?
On Mon, Jan 19, 2009 at 04:18:56PM +0100, Adeodato Simó wrote: * Roberto C. Sánchez [Mon, 19 Jan 2009 08:54:31 -0500]: I just saw [0] that libwx-perl was removed from Lenny. Why? The bug referenced in the removal hint (#499740) didn't even affect the version that was in testing (0.84-2), which was the version that was in there as of the freeze and the version I was expecting would release with Lenny. I'm very sorry about this, and I'm sure Neil too. Would you accept our apologies, and re-upload 0.84-2 as 0.84-3 to testing-proposed-updates? (If you don't have that version handy, let me know and I will give you a copy.) No apology is necessary. With the number of bugs/packages being dealt with by the release team, little things like this are bound to happen. I will happily upload 0.84-3 to testing-proposed-updates. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Approval for upload of new Shorewall upstream 4.0.15
On Sun, Dec 14, 2008 at 07:25:58PM +0100, Luk Claes wrote:
Roberto C. Sánchez wrote:
I am preparing a new upstream release (4.0.15) of Shorewall (affected Debian
packages: shorewall-{perl,shell,common,lite,doc}). Nearly all of the
changes
have already been approved, uploaded and migrated to Lenny in the form of
patches to the 4.0.14 packages. Only the latest fix (I just committed it
upstream tonight), has not been incorporated. I would like to receive
approval
for upload of the new 4.0.15 (still to be released) packages. This will
help
to avoid user confusion and 4.0.15 is currently planned to be the very last
release in the 4.0 series of Shorewall releases.
Please upload and ping us again when finished.
Just uploaded.
Regards,
Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
