Bug#1024501: Can we close this bug report?
Since it is evident that the Code of Conduct does not apply to the content of packages in this way (nor can it), and absent a clear policy permitting the removal of a package based on its content not being agreeable, can we close this bug report? Regards, -Roberto -- Roberto C. Sánchez
Bug#1042682: mongo-c-driver: FTBFS with Sphinx 7.1, docutils 0.20: make[3]: *** [src/libbson/doc/CMakeFiles/bson-html.dir/build.make:554: src/libbson/doc/html/api.html] Error 2
tags 1042682 + fixed-upstream pending thanks I have confirmed that this is fixed on the upstream master branch (commit ba5ab6de26a874d33b0abc3d2b46961a69380e7a seems like the most likely, but I did not bisect to confirm). When the upstream 1.25.0 release is made and then packaged for Debian, this fix will land in unstable. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Bug#1035972: isc-dhcp EOL'ed
On Fri, Jun 16, 2023 at 10:12:22PM +0200, Moritz Muehlenhoff wrote: > On Fri, Jun 16, 2023 at 01:29:28PM -0400, Roberto C. Sánchez wrote: > > On Wed, May 17, 2023 at 10:50:34AM +0200, Moritz Muehlenhoff wrote: > > > > > > My take would be to mark it as unsupported after the trixie development > > > cycle > > > has started (this flags awareness, but has no impact on stable releases) > > > and then revisit the support situation before the trixie freeze (Kea > > > might be > > > a full replacment by then or maybe it turns out the patch support is > > > ensured > > > despite upstream's EOL) > > > > > Hi Moritz, > > > > Now that bookworm is out and (AFAICT) that the trixie development cycle > > has started, are able to go ahead with marking isc-dhcp as unsupported? > > Ultimately it's the maintainer(s) call, but sounds good to me. > Are you referring to the maintainer of debian-security-support, or the maintainer of isc-dhcp? Regards, -Roberto -- Roberto C. Sánchez
Bug#1035972: isc-dhcp EOL'ed
On Wed, May 17, 2023 at 10:50:34AM +0200, Moritz Muehlenhoff wrote: > > My take would be to mark it as unsupported after the trixie development cycle > has started (this flags awareness, but has no impact on stable releases) > and then revisit the support situation before the trixie freeze (Kea might be > a full replacment by then or maybe it turns out the patch support is ensured > despite upstream's EOL) > Hi Moritz, Now that bookworm is out and (AFAICT) that the trixie development cycle has started, are able to go ahead with marking isc-dhcp as unsupported? Regards, -Roberto -- Roberto C. Sánchez
Bug#1030726: marked as pending in intelrdfpmath
On Sun, Feb 12, 2023 at 09:32:55PM +0100, Stephen Kitt wrote: > > Given how late we are in the Bookworm release process, I’ve updated the > package description to mention that the library is only fully functional on > x86 architectures and ia64, but may be sufficient on others (for free42, it > is, at least on ARM), and haven’t restricted the architectures. That doesn’t > help on MIPS of course... > > Does libdfp work on MIPS? I got the impression it’s mainly supported on IBM > platforms (POWER and S/390) but perhaps that’s outdated! > After having talked with the developer who has implemented the new DFP-dependent features in libmongocrypt, it seems that portability (beyond amd64, arm64, ppc64el, and s390x) was in view for him. He did look at libdfp and concluded that it has some benefits over Intel DFP, but clearly building on MIPS family architectures is not achievable even with libdfp. As far as it being outdated, I am not certain but I think that upstream might have gone away from tagged/versioned releases and more to a model of "clone master and build from that". In that sense, it wouldn't be outdated, but the version in Debian would be about ~18 months out of date by that measure. In any event, upstream decided that rather than implement support for libdfp they would implement a switch to enable/disable building with Intel DFP (and thus the features that depend on it). That will allow for libmongocrypt to be able to build on all of the release architectures for bookworm. That new upstream release is due out today or tomorrow. The upstream CI gives sufficient coverage with testing that I am confident in all the 64-bit non-MIPS arches and I would be surprised if 32-bit ARM were an issue given the fairly robust upstream tests. In any event, thanks for leaving the architectures as they are for the moment. Regards, -Roberto -- Roberto C. Sánchez
Bug#1030726: marked as pending in intelrdfpmath
On Tue, Feb 07, 2023 at 08:44:50PM +0100, Stephen Kitt wrote: > > Yes, it seems like we’d really need a mips_macros.h implementation on MIPS. > That was my suspicion as well. > I enabled the test suite, and the result is basically that the library only > works fully on amd64, i386 (nearly, with two test failures out of ~120,000 > test cases), and ia64, which matches the architectures which the library > claims to support. On other architectures, the number of failures varies, up > to 12.5% of test cases on s390x. > > So really I should change the library to [amd64 i386 ia64]... > That's unfortunate. > Do you have a good way of validating whether the library is good enough for > libmongocrypt’s purposes on non-Intel architectures? > libmonogocrypt has a test suite, which we don't execute as part of the package build because of upstream's robust CI. However, we could definitely enable it and it would be sufficient to let us know that the library is adequate for what libmongocrypt needs. That said, upstream is quite close validating that libmongocrypt works with libdfp, so that might provide a near-term alternative if you decide that the best thing to do from a quality perspective is to restrict the architecture list of intelrdfpmath. Regards, -Roberto -- Roberto C. Sánchez
Bug#1030726: marked as pending in intelrdfpmath
And even with the build continuing on mips64el I see this: float128/dpml_ux_trig.c: In function '__dpml_bid_ux_degree_reduce__': float128/dpml_ux_trig.c:254:9: warning: implicit declaration of function 'UMULH' [-Wimplicit-f unction-declaration] 254 | UMULH((UX_FRACTION_DIGIT_TYPE) exponent, RECIP_TWELVE, k); | ^ When I build libmongocrypt against the resulting libintelrdfp-math, the libmongocrypt will then fail at link time: /usr/bin/ld: /home/roberto/mips64el/intelrdfpmath-2.0u2/debian/libintelrdfpmath-dev/usr/lib/mips64el-linux-gnuabi64/libbidgcc000.a(dpml_ux_ops_64.o): in function `__eval_pos_poly': (.text+0xe4): undefined reference to `UMULH' /usr/bin/ld: (.text+0xfc): undefined reference to `UMULH' /usr/bin/ld: (.text+0x144): undefined reference to `UMULH' /usr/bin/ld: (.text+0x160): undefined reference to `UMULH' /usr/bin/ld: (.text+0x168): undefined reference to `UMULH' /usr/bin/ld: /home/roberto/mips64el/intelrdfpmath-2.0u2/debian/libintelrdfpmath-dev/usr/lib/mips64el-linux-gnuabi64/libbidgcc000.a(dpml_ux_ops_64.o):(.text+0x17c): more undefined references to `UMULH' follow It might be better to simply declare intelrdfpmath '[!mipsel !mips64el]'. Sadly, my experience with Intel libraries (I maintained TBB in Debian for several years) is that they only put effort into the architectures that are important to them and that you can't assume that their code will work on other architectures. That could well be the case here. Regards, -Roberto -- Roberto C. Sánchez
Bug#1030726: marked as pending in intelrdfpmath
This patch is broken. I attempted a build and this is what happened:
(sid_mips64el-dchroot)roberto@eller:~/mips64el/intelrdfpmath-2.0u2$
dpkg-buildpackage
dpkg-buildpackage: info: source package intelrdfpmath
dpkg-buildpackage: info: source version 2.0u2-6
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Stephen Kitt
dpkg-buildpackage: info: host architecture mips64el
dpkg-source --before-build .
debian/rules clean
dh clean
debian/rules override_dh_auto_clean
make[1]: Entering directory '/home/roberto/mips64el/intelrdfpmath-2.0u2'
/usr/bin/make -C LIBRARY clean
make[2]: Entering directory '/home/roberto/mips64el/intelrdfpmath-2.0u2/LIBRARY'
makefile.iml_head:356: *** Unknown host architecture mips64. Stop.
make[2]: Leaving directory '/home/roberto/mips64el/intelrdfpmath-2.0u2/LIBRARY'
make[1]: *** [debian/rules:16: override_dh_auto_clean] Error 2
make[1]: Leaving directory '/home/roberto/mips64el/intelrdfpmath-2.0u2'
make: *** [debian/rules:13: clean] Error 2
dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2
I have attached an updated patch that seems to resolve this issue and
allows the build to execute on mips64el and mipsel.
Regards,
-Roberto
On Mon, Feb 06, 2023 at 08:58:44PM +, Stephen Kitt wrote:
> Control: tag -1 pending
>
> Hello,
>
> Bug #1030726 in intelrdfpmath reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
>
> https://salsa.debian.org/debian/intelrdfpmath/-/commit/758574be1ed3ce30ec26c6e5136fdb1691d5213a
>
>
> Fix MIPS support
>
> Closes: #1030726
>
>
> (this message was generated automatically)
> --
> Greetings
>
> https://bugs.debian.org/1030726
>
> --
> To unsubscribe, send mail to 1030726-unsubscr...@bugs.debian.org.
--
Roberto C. Sánchez
Description: Fix MIPS support
Author: Stephen Kitt
This removes references to files which aren't shipped, and adds
support for 64-bit MIPS.
Based on a patch by Roberto Sánchez .
Index: intelrdfpmath-2.0u2/LIBRARY/float128/architecture.h
===
--- intelrdfpmath-2.0u2.orig/LIBRARY/float128/architecture.h
+++ intelrdfpmath-2.0u2/LIBRARY/float128/architecture.h
@@ -128,14 +128,22 @@
# undef MULTIPLE_ISSUE
# undef UNSIGNED_TO_FLOAT
# define UNSIGNED_MULTIPLY 1
-# define ENDIANESS little_endian
+# if defined(_MIPSEL)
+# define ENDIANESS little_endian
+# elif defined(_MIPSEB)
+# define ENDIANESS big_endian
+# endif
# define SCALE_METHOD by_int
# define CVT_TO_HI_LO_METHOD by_flt
# define BITS_PER_CHAR8
# define BITS_PER_SHORT 16
# define BITS_PER_INT32
-# define BITS_PER_LONG 32
+# if (_MIPS_SIM == _ABIO32) || (_MIPS_SIM == _ABIN32)
+# define BITS_PER_LONG 32
+# elif _MIPS_SIM == _ABI64
+# define BITS_PER_LONG 64
+# endif
# define BITS_PER_FLOAT 32
# define BITS_PER_DOUBLE 64
@@ -144,22 +152,31 @@
# define INT_8 signed char
# define INT_16 signed short
# define INT_32 signed int
-# undef INT_64
+# define INT_64 long long
# undef INT_128
# define U_INT_8 unsigned char
# define U_INT_16 unsigned short
# define U_INT_32 unsigned int
-# undef U_INT_64
+# define U_INT_64 unsigned long long
# undef U_INT_128
-# define WORD INT_32
-# define U_WORD U_INT_32
-# define BITS_PER_WORD 32
-
-# define HALF_WORD INT_16
-# define U_HALF_WORD U_INT_16
-# define BITS_PER_HALF_WORD 16
-
+# if (_MIPS_SIM == _ABIO32) || (_MIPS_SIM == _ABIN32)
+# define WORD INT_32
+# define U_WORD U_INT_32
+# define BITS_PER_WORD 32
+
+# define HALF_WORD INT_16
+# define U_HALF_WORD U_INT_16
+# define BITS_PER_HALF_WORD 16
+# elif _MIPS_SIM == _ABI64
+# define WORD INT_64
+# define U_WORD U_INT_64
+# define BITS_PER_WORD 64
+
+# define HALF_WORD INT_32
+# define U_HALF_WORD U_INT_32
+# define BITS_PER_HALF_WORD 32
+# endif
#elif (defined(hp_pa) || defined(HP_PA) || defined(__hppa) || defined(__HPPA))
Index: intelrdfpmath-2.0u2/LIBRARY/float128/dpml_exception.h
===
--- intelrdfpmath-2.0u2.orig/LIBRARY/float128/dpml_exception.h
+++ intelrdfpmath-2.0u2/LIBRARY/float128/dpml_exception.h
@@ -325,7 +325,6 @@ typedef struct {
# define PROCESS_DENORMS 1
# define DPML_EXCEPTION_HANDLER DPML_EXCEPTION_NAME
# define EXCEPTION_ARGUMENTS( error_code ) error_code
-# define PLATFORM_SPECIFIC_HEADER_FILE "mips_exception.c"
# elif ARCHITECTURE == hp_pa
# define PROCESS_DENORMS 1
Index: intelrdfpmath-2.0u2/LIBRARY/float128/dpml_private.h
===
--- intelrdfpmath-2
Bug#1030726: marked as pending in intelrdfpmath
As a further note, even with the update patch that I supplied, there is still a later failure on 32-bit mipsel: float128/dpml_ux_cbrt.c: In function 'bid_f128_cbrt': float128/dpml_ux_cbrt.c:136:27: error: 'lsd' undeclared (first use in this function); did you mean 'msd'? 136 || (lsd >> D_EXP_WIDTH); | ^~~ | msd float128/dpml_ux_cbrt.c:136:27: note: each undeclared identifier is reported only once for each function it appears in Regards, -Roberto -- Roberto C. Sánchez
Bug#1030701: intelrdfpmath: FTBFS on alpha/hppa/mips and likely misbuilt on several architectures
On Mon, Feb 06, 2023 at 08:04:13PM +0100, Stephen Kitt wrote:
>
> I’m afraid there isn’t much I can do about that, other than ask upstream to
> add MIPS support.
>
> Given the RC severity of this bug, I’ll consider the main point of the bug to
> be the latter part:
>
> > The RC severity is based on looking at a related question:
> > How did intelrdfpmath compile on new platforms like powerpc/arm/s390x
> > that never had any explicit support in intelrdfpmath?
> >
> > intelrdfpmath (2.0u2-2) unstable; urgency=medium
> > * Assume unknown architectures are “EFI2”.
> >
> > LIBRARY/float128/architecture.h:
> > #if defined(ct) || defined(efi2)
> > # undef _M_AMD64
> > # define _M_AMD64
> > #endif
> >
> > This builds, but the (used) definition
> > # define ENDIANESS little_endian
> > isn't correct on s390x, and neither is
> > # define BITS_PER_LONG 64
> > on 32bit arm.
>
> Ah, I knew that would bite me some day...
>
> I’m updating intelrdfpmath to apply the architecture definitions used in
> libmongocrypt (see
> <https://github.com/mongodb/libmongocrypt/blob/master/cmake/IntelDFP.cmake>):
> armel/armhf are assumed to behave like i386 (I haven’t checked whether that
> makes sense), arm64/ppc64el/riscv64 are assumed to behave like amd64, and
> s390x is supported explicitly.
>
> If you want to track the unsupported architectures, please open a new bug. As
> far as I can tell, even if libmongocrypt were built in Debian using its
> embedded copy of intelrdfpmath, it would fail on the same architectures.
>
So, based on the fact that upstream treats x86 and x86_64 as having the
same data model, I came up with the attached patch. It allows the build
to succeed on both mips64el and mipsel. I am preparing to test (using
the libmongocrypt tests as a proxy) and I will report back with the
results of those tests.
Regards,
-Roberto
--
Roberto C. Sánchez
Index: intelrdfpmath-2.0u2/LIBRARY/float128/dpml_private.h
===
--- intelrdfpmath-2.0u2.orig/LIBRARY/float128/dpml_private.h
+++ intelrdfpmath-2.0u2/LIBRARY/float128/dpml_private.h
@@ -212,7 +212,12 @@ versions until we need them. ] */
#elif (ARCHITECTURE == mips)
-#include "mips_macros.h"
+/*
+ * This header doesn't exist and the attempted inclusion causes a FTBFS.
+ * Don't try to include it, but also leave this branch here so that the
+ * absence of it doesn't result in raising the error below.
+include "mips_macros.h"
+*/
#elif (ARCHITECTURE == hp_pa)
Index: intelrdfpmath-2.0u2/LIBRARY/float128/architecture.h
===
--- intelrdfpmath-2.0u2.orig/LIBRARY/float128/architecture.h
+++ intelrdfpmath-2.0u2/LIBRARY/float128/architecture.h
@@ -144,17 +144,23 @@
# define INT_8 signed char
# define INT_16 signed short
# define INT_32 signed int
-# undef INT_64
+# define INT_64 long long
# undef INT_128
# define U_INT_8 unsigned char
# define U_INT_16 unsigned short
# define U_INT_32 unsigned int
-# undef U_INT_64
+# define U_INT_64 unsigned long long
# undef U_INT_128
-# define WORD INT_32
-# define U_WORD U_INT_32
-# define BITS_PER_WORD 32
+# if 0
+# define WORD INT_32
+# define U_WORD U_INT_32
+# define BITS_PER_WORD 32
+# else
+# define WORD INT_64
+# define U_WORD U_INT_64
+# define BITS_PER_WORD 64
+# endif
# define HALF_WORD INT_16
# define U_HALF_WORD U_INT_16
Index: intelrdfpmath-2.0u2/LIBRARY/float128/dpml_exception.h
===
--- intelrdfpmath-2.0u2.orig/LIBRARY/float128/dpml_exception.h
+++ intelrdfpmath-2.0u2/LIBRARY/float128/dpml_exception.h
@@ -325,7 +325,7 @@ typedef struct {
# define PROCESS_DENORMS 1
# define DPML_EXCEPTION_HANDLER DPML_EXCEPTION_NAME
# define EXCEPTION_ARGUMENTS( error_code ) error_code
-# define PLATFORM_SPECIFIC_HEADER_FILE "mips_exception.c"
+//# define PLATFORM_SPECIFIC_HEADER_FILE "mips_exception.c"
# elif ARCHITECTURE == hp_pa
# define PROCESS_DENORMS 1
Bug#986152: Offer of help
On Sat, Jan 21, 2023 at 09:58:13AM +0100, Romain Francoise wrote: > On Fri, Jan 20, 2023 at 11:59:44AM +, Jeremy Sowden wrote: > > The Developer's Reference, § 5.6.1, expresses the preference that when > > new binary packages are added to a source package, it should be > > uploaded to experimental, so I've updated the version and distribution > > in the change-log entry accordingly. > > But these are not *new* binary packages, so I don't think the upload > will go through NEW. In fact, I hope it won't because there's still the > freeze to consider and I'd really like the new package to be in > bookworm. Sort of. Whenever a source package produces a new binary package, whether that package exists in the archive already or not, it will land in NEW. For instance, this happens with libraries that bump SONAME and start shipping a new binary package as a result. Consider the source package foo which produces (among others) libfoo1. If the SONAME is bumped to 2 causing libfoo2 to be emitted by the foo source package instead of libfoo1, then that upload will land in NEW. The FTP masters take notice and this particular case is usually handled very quickly (since they don't have to do all the normal checks of a brand new source package), but they still have to check that the new binary package being created by the source package in question doesn't conflict with a binary package from another source package. Imagine an entirely different source package, foo2, that already produced the binary package libfoo2. Allowing an unchecked upload of foo to add the libfoo2 binary package to the archive when foo2 is already producing a libfoo2 package would be a Bad Thing(TM). This is where appropriate use of things like Breaks/Replaces/Conflicts can help streamline the process. Regards, -Roberto -- Roberto C. Sánchez
Bug#986152: Offer of help
On Fri, Jan 20, 2023 at 09:46:35PM +, Jeremy Sowden wrote: > On 2023-01-19, at 22:56:39 +0100, Romain Francoise wrote: > > On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden wrote: > > > I've pushed all the work to my repo on Salsa: > > > > > > https://salsa.debian.org/azazel/shorewall > > > > > > Do you want to review it before I push to the shorewall-team repo? > > > > It all looks pretty good to me! In fact, it's a radical improvement > > over the previous packaging with seven source packages. > > > > [...] > > > > I have not yet actually tested the packages in my lab but please feel > > free to push your changes to the team repo, and I will do the final > > testing and upload over the week-end. I can also take care of opening > > the bugs to have the previous source packages removed from unstable. > > I was wondering about this shorewall-doc bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266957 > > Once 5.2.8 is uploaded there won't be a shorewall-doc source package. > Shall I reassign it to shorewall? > > J. That's a good question. I think that the bug is actually assigned to the shorewall-doc binary package, not the shorewall-doc source package. Assuming that the shorewall source package will start to emit a shorewall-doc binary package, I think that the BTS will do the right thing and leaving the bug assigned to shorewall-doc is correct. In that case, the source package association of shorewall-doc will change, but its bugs will still belong to shorewall-doc (the binary package). If you think about it, this must be the case, as closed and archived bugs would end up being orphaned otherwise. Regards, -Roberto -- Roberto C. Sánchez
Bug#986152: Offer of help
On Sat, Jan 07, 2023 at 12:48:08PM +0100, Romain Francoise wrote: > On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden wrote: > > I've imported my fork of Roberto's SF repo to Salsa: > > > > https://salsa.debian.org/azazel/shorewall > > > > I haven't touched it in 18 months, so I'll give it a polish when I have > > some time, and perhaps we can use it as a starting point. > > Thanks. I created a Salsa team and repo here: > https://salsa.debian.org/shorewall-team/shorewall and added you both > as co-owners. > > I felt more comfortable using Roberto's original SF repo as a starting > point, and merging in your changes after review. I can do that in the > next few days, the freeze is coming up very soon and I would like to > have the new upstream in bookworm. If you have further changes please > push them to your repo. > > I'll also configure the CI on Salsa to have all the usual QA tools run > automatically on each push. > > Did you find a practical way to do changes across all seven source > packages at once? For a bit of historical context, the current multi-branch structure from the SF repo is quite antiquiated. It is from a time before debhelper supported multiple .orig.tar.gz components. It might make sense to consider starting with a new repo, with a more sensible branch structure (one that works more easily with tools like gbp), and that makes use of the multi-tarball capabilities so that you have have all the source packages in view at the same time. Regards, -Roberto -- Roberto C. Sánchez
Bug#986152: Offer of help
On Mon, Jan 02, 2023 at 06:08:57PM +0100, Romain Francoise wrote: > Hi, > > [Cc'ing Roberto directly to make sure he's aware of this discussion.] > Thanks for that. I'm not sure I would have seen it otherwise. > I'm also a Shorewall[6] user and while the state of the package isn't > really alarming right now, I need it to be properly maintained going > forward. > My needs have been evolving the last few years and I have much less of a need for a tool like Shorewall these days. Additionally, I have never used some of the advanced features (e.g., Multi-ISP, tc, accounting, etc.). It would be good to have others involved in maintenance who are able to contribute in that way. > We could set up a pkg-shorewall team on Salsa and co-maintain the > packages there. Jeremy, would that work for you? > I see that the group has already been created and that I was added. At the moment I am not able to jump in to aid with the transition. I hope to clear some major items from my queue in the coming weeks and until then I will do what I can. I'd like to mention that there is already a Gitlab group for upstream Shorewall work (which has been essentially dormant for some time): https://gitlab.com/shorewall It might make sense to consider if there is any overlap and if any of the Salsa work might be better house under the Shorewall Gitlab group. I'll try to jump in a bit more helpfully next week. Regards, -Roberto -- Roberto C. Sánchez
Bug#1017083: [pkg-crosswire-devel] Bug#1017083: Path forward
On Sat, Aug 27, 2022 at 07:48:11PM +0200, Teus Benschop wrote: > The bug report states this: > > > In order to solve this problem, you could: > > 1. add the source files to "debian/missing-sources" directory. > > 2. repack the origin tarball and add the missing source files to it. > > The intention just now is to go for something similar to the proposed > solution number 2. > That means in this case that upstream will provide a new tarball that > includes the missing source files. > Then once this is done, a new Bibledit package can be created based on this > tarball. > > The intention is to do the above before the package will be > automatically removed from the testing distro, > and then let the new changelog close this bug in time. > I agree with your approach. Including the source now to address the bug and ensure that package is not removed is something that should be done soon. The introduction of the new package could also be pursued in parallel and once it is accepted into the archive, then bibledit could be updated to depend on the package and remove the duplicate components. Regards, -Roberto -- Roberto C. Sánchez
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
Bug#997248: mysql++: FTBFS: ./examples/load_jpeg.cpp:90:50: error: taking address of rvalue [-fpermissive]
On Mon, Nov 22, 2021 at 01:16:06PM +0100, Sascha Steinbiss wrote: > Hi everyone, > > looks like upstream fixed this already [0]. The fix is easily imported > into packaging, see attached debdiff. > > I would be happy to NMU this within a week or so if there is no action > by the maintainer to avoid mysql++ to be removed from testing. Please > let me know if this is not wanted. Also addressing this mail to the > previous uploader of the package. > > mysql++ is a dependency of my augustus package, which I would prefer not > to be removed from testing. > Hi Sascha, I cannot attend to this at the moment, so I give you my blessing to proceed with the NMU. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
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#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 02, 2021 at 04:08:37PM +, Jeremy Stanley wrote: > On 2021-09-02 10:22:15 +0900 (+0900), Hideki Yamane wrote: > [...] > > Providing "default secure setting" is good message to users. > [...] > > As previously covered, I'd suggest steering clear of referring to > this as adding "default security." That implies APT wasn't already > effectively secure over plain HTTP, and may give a false impression > that HTTPS is addressing gaps in the existing apt-secure design. > > This change is more about recognizing HTTPS as the primary transport > protocol for the modern Web, not sending mixed signals regarding the > general security risks posed by plain HTTP when used for unrelated > purposes, and no longer needing to repeatedly explain to users that > Debian has gone to great lengths to implement package distribution > security which doesn't really depend at all on transport layer > encryption. In this context, it might make sense to describe using HTTPS as the transport for APT operations is providing "default confidentiality". Regards, -Roberto -- Roberto C. Sánchez
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#984606: [pkg-crosswire-devel] Bug#984606: Bug#984606: sword-comm-scofield: Missing source
On Sat, Mar 20, 2021 at 06:52:35PM +0100, Bastian Germann wrote: > Am 20.03.21 um 17:49 schrieb Roberto C. Sánchez: > > Could you request from the release team an exception for this > > bug so that we can deal with it in the next release cycle without > > completely expelling the package in the meantime? > > If you think that is a reasonable request, you can do so. > If you want me to do something about it, I am happy to request the move to > non-free, as suggested. But I am not the maintainer nor an uploader, so the > release managers will synchronize with you beforehand, which is why I did > not file that request. Quite right. I assumed you were uploader on all the team packages, but it looks like the commentaries have not been updated for a few years. > I think the sooner this is handed in the better. In 2 > weeks the package will be autoremoved and will not have a chance even to > enter non-free after that. > Very true. Another possibility occurred to me. Would you be comfortable lowering the serverity to 'normal' until after the release, then raising the severity again? I believe that we have that latitude within the team and it would not require involving the release team (who are quite busy with a buster point release in the coming week plus the preparations for the next stable release). Regards, -Roberto -- Roberto C. Sánchez
Bug#984608: [pkg-crosswire-devel] Bug#984608: sword-comm-tdavid: Missing source
On Fri, Mar 05, 2021 at 08:46:12PM +0100, Bastian Germann wrote: > Package: sword-comm-tdavid > Severity: serious > Control: forwarded https://tracker.crosswire.org/browse/MOD-404 > > sword-comm-tdavid is missing source. The suggested decompression commands in > debian/copyright will not give the original source because the translation > process is lossy. > > I suggest to move the package to non-free or to remove it. > It seems like an excellent idea to address the matter of module source. However, it would be a shame to have this package removed from the next release. Could you request from the release team an exception for this bug so that we can deal with it in the next release cycle without completely expelling the package in the meantime? Regards, -Roberto -- Roberto C. Sánchez
Bug#984606: [pkg-crosswire-devel] Bug#984606: sword-comm-scofield: Missing source
On Fri, Mar 05, 2021 at 08:44:58PM +0100, Bastian Germann wrote: > Package: sword-comm-scofield > Severity: serious > Control: forwarded https://tracker.crosswire.org/browse/MOD-402 > > sword-comm-scofield is missing source. The suggested decompression commands > in debian/copyright will not give the original source because the > translation process is lossy. > > I suggest to move the package to non-free or to remove it. > It seems like an excellent idea to address the matter of module source. However, it would be a shame to have this package removed from the next release. Could you request from the release team an exception for this bug so that we can deal with it in the next release cycle without completely expelling the package in the meantime? 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#984526: [pkg-crosswire-devel] Bug#984526: sword-text-kjv: Package is non-free
On Thu, Mar 04, 2021 at 06:04:13PM +0100, Bastian Germann wrote: > Source: sword-text-kjv > Severity: serious > Version: 2.10-1 > > sword-text-kjv is non-free in all of its versions. The details are in > https://gitlab.com/crosswire-bible-society/kjv/-/commit/0203c85010a9a > I read the thread (and looked at your changes). This seems to a bit of a tangled mess. It will be a few days before I can take a closer look and provide my thoughts. Regards, -Roberto -- Roberto C. Sánchez
Bug#883932: Source for sword-comm-mhc
On Tue, Nov 24, 2020 at 10:33:47AM -0500, Roberto C. Sánchez wrote: > > But the Salsa project page says the repository is empty. I will push > the code I have shortly. > I have pushed everything to the Salsa repository, including all branches (master, upstream, pristine-tar) and tags. Regards, -Roberto -- Roberto C. Sánchez
Bug#883932: Source for sword-comm-mhc
On Tue, Nov 24, 2020 at 03:41:40PM +0100, Bastian Germann wrote:
> sword-comm-mhc should be developed at
> https://salsa.debian.org/pkg-crosswire-team/sword-comm-mhc
>
That's strange, since according to the working copy on my machine, the
sources are already there:
roberto@miami:~/src/debian/sword-comm-mhc.git (master=)$ git remote -v
origin g...@salsa.debian.org:pkg-crosswire-team/sword-comm-mhc.git (fetch)
origin g...@salsa.debian.org:pkg-crosswire-team/sword-comm-mhc.git (push)
But the Salsa project page says the repository is empty. I will push
the code I have shortly.
> The work can be found at https://ccel.org/ccel/henry.
>
> ThML sources are at https://ccel.org/ccel/henry/mhc{,1,2,3,4,5,6}.xml
Regards,
-Roberto
--
Roberto C. Sánchez
Bug#970471: [pkg-crosswire-devel] Bug#970471: RFS: bibletime [RC]
On Sat, Nov 14, 2020 at 02:00:05PM +0100, Bastian Germann wrote: > The fix from Adrian is now applied on salsa. Who wants to upload > bibletime 3.0-3? > I have just built and uploaded the package. Regards, -Roberto -- Roberto C. Sánchez
Bug#970471: [pkg-crosswire-devel] Processed: reopen
On Sat, Nov 14, 2020 at 02:35:51PM +0200, Adrian Bunk wrote:
> Control: found -1 3.0-1
> Control: severity -1 serious
> Control: tags -1 patch
>
> On Mon, Sep 21, 2020 at 04:45:45PM -0400, Roberto C. Sánchez wrote:
> >...
> > I spent some time on this today and thanks to a suggestion from someone
> > in IRC, I was able to determine that removing link-time optimization
> > fixed the mips64el build. Specifically, these lines had to be removed:
> >
> > -SET_TARGET_PROPERTIES("${target}" PROPERTIES
> > -INTERPROCEDURAL_OPTIMIZATION TRUE)
> >...
>
> After some further debugging I ended up with the workaround below.
>
Adrian,
Thanks so much for taking the time to debug this and submit a patch.
Your effort is very much appreciated.
Bastian has already committed the patch to our Salsa repository and an
upload will be on the way shortly.
Regards,
-Roberto
--
Roberto C. Sánchez
Bug#965012: RFT: squid3 3.5.23-5+deb9u5, please test
On Tue, Sep 29, 2020 at 12:11:24AM +0200, Markus Koschany wrote: > [adding Andreas and Kevin to CC who helped with testing past squid3 updates] > > Hello, > > I have uploaded a new version of squid3 for Stretch to people.debian.org. > > https://people.debian.org/~apo/lts/squid3/stretch/ > > It contains fixes for CVE-2020-15049, CVE-2020-15810, CVE-2020-15811 and > CVE-2020-24606. Let me know if you find any regressions from > the current released version 3.5.23-5+deb9u4. > The changes look excellent to me. Regards, -Roberto -- Roberto C. Sánchez
Bug#971264: mediawiki: ParseError after 1.27.7-1~deb9u4 upgrade (blame patch for User::pingLimiter)
tags 971264 + confirmed thanks On Mon, Sep 28, 2020 at 01:24:09PM +0100, carandraug wrote: > > Dear Maintainer, > > After the update to 1.27.7-1~deb9u4 (from 1.27.7-1~deb9u3), the mediawiki site > errors in all pages with: > > Exception encountered, of type "ParseError" > Thanks for the report. An update to fix this is being prepared and should be published later today. Regards, -Roberto -- Roberto C. Sánchez
Bug#970471: [pkg-crosswire-devel] Processed: reopen
On Mon, Sep 21, 2020 at 08:55:50AM -0400, Roberto C. Sánchez wrote:
> On Mon, Sep 21, 2020 at 02:54:17PM +0200, Bastian Germann wrote:
> > Am 21.09.20 um 14:37 schrieb Roberto C. Sánchez:
> > > On Mon, Sep 21, 2020 at 08:39:05AM +, Debian Bug Tracking System
> > > wrote:
> > >> Processing commands for cont...@bugs.debian.org:
> > >>
> > >>> reopen 970471 =
> > >> Bug #970471 {Done: Bastian Germann }
> > >> [bibletime] bibletime: FTBFS on mips64el
> > >> 'reopen' may be inappropriate when a bug has been closed with a version;
> > >> all fixed versions will be cleared, and you may need to re-add them.
> > >> Bug reopened
> > >> No longer marked as fixed in versions bibletime/3.0-2.
> > >>>
> > >
> > > Bastian,
> > >
> > > This bug may require further investigation on a porterbox to ensure that
> > > the root cause has been determined and then fixed. Do you have access
> > > to a mips64el porterbox or perhaps a non-Debian system of that
> > > architecture? If not, I can make some time later this week to try to
> > > diagnose the issue.
> > >
> > > Regards,
> > >
> > > -Roberto
> > >
> >
> > No, I do not have access to a mips64el machine. I built the package in
> > qemu. Without the patches it failed and with them applied it built
> > successfully.
> >
> That is helpful to know. I will try to rebuild 3.0-2 on a mips64el
> machine this week to see if it fails in that case. Once I am able to do
> that I will follow-up with the results.
>
I spent some time on this today and thanks to a suggestion from someone
in IRC, I was able to determine that removing link-time optimization
fixed the mips64el build. Specifically, these lines had to be removed:
-SET_TARGET_PROPERTIES("${target}" PROPERTIES
-INTERPROCEDURAL_OPTIMIZATION TRUE)
It is likely that since bibletime is a GUI application that it will not
benefit very much from link-time optimization. Is it possible to drop
that property altogether? If not, perhaps then conditionally only
setting it on known good architectures would be possible.
Regards,
-Roberto
--
Roberto C. Sánchez
Bug#970471: [pkg-crosswire-devel] Processed: reopen
On Mon, Sep 21, 2020 at 02:54:17PM +0200, Bastian Germann wrote:
> Am 21.09.20 um 14:37 schrieb Roberto C. Sánchez:
> > On Mon, Sep 21, 2020 at 08:39:05AM +, Debian Bug Tracking System wrote:
> >> Processing commands for cont...@bugs.debian.org:
> >>
> >>> reopen 970471 =
> >> Bug #970471 {Done: Bastian Germann }
> >> [bibletime] bibletime: FTBFS on mips64el
> >> 'reopen' may be inappropriate when a bug has been closed with a version;
> >> all fixed versions will be cleared, and you may need to re-add them.
> >> Bug reopened
> >> No longer marked as fixed in versions bibletime/3.0-2.
> >>>
> >
> > Bastian,
> >
> > This bug may require further investigation on a porterbox to ensure that
> > the root cause has been determined and then fixed. Do you have access
> > to a mips64el porterbox or perhaps a non-Debian system of that
> > architecture? If not, I can make some time later this week to try to
> > diagnose the issue.
> >
> > Regards,
> >
> > -Roberto
> >
>
> No, I do not have access to a mips64el machine. I built the package in
> qemu. Without the patches it failed and with them applied it built
> successfully.
>
That is helpful to know. I will try to rebuild 3.0-2 on a mips64el
machine this week to see if it fails in that case. Once I am able to do
that I will follow-up with the results.
Regards,
-Roberto
--
Roberto C. Sánchez
Bug#970471: [pkg-crosswire-devel] Processed: reopen
On Mon, Sep 21, 2020 at 08:39:05AM +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
>
> > reopen 970471 =
> Bug #970471 {Done: Bastian Germann } [bibletime]
> bibletime: FTBFS on mips64el
> 'reopen' may be inappropriate when a bug has been closed with a version;
> all fixed versions will be cleared, and you may need to re-add them.
> Bug reopened
> No longer marked as fixed in versions bibletime/3.0-2.
> >
Bastian,
This bug may require further investigation on a porterbox to ensure that
the root cause has been determined and then fixed. Do you have access
to a mips64el porterbox or perhaps a non-Debian system of that
architecture? If not, I can make some time later this week to try to
diagnose the issue.
Regards,
-Roberto
--
Roberto C. Sánchez
Bug#970471: [pkg-crosswire-devel] Bug#970471: Bug#970471: Possible ways to resolve
On Sun, Sep 20, 2020 at 07:57:59PM +0200, Bastian Germann wrote: > Am 20.09.20 um 12:35 schrieb Teus Benschop: > > The error message in this bug report is an unusual one. > > > > I managed to find one other similar report on Google, which was in Chinese. > > > > Possible solutions I could think of are these two. > > > > 1. If the error is temporary, to upload a new package that would trigger a > > rebuild. > > > > 2. To ask the FTP Masters to remove the previously build for this > > architecture, so the remaining architectures can move to testing. > > > Upstream provided a patch that I applied on salsa. Would someone please > upload the new version? > Hi Bastian, Thanks so much for taking the time to address this bug and to prepare the updated package. I have uploaded the 3.0-2 package. Note that I deleted your debian/3.0-2 tag, created a new tag signed with my GPG key, and then force pushed it. As a practice, I think we should stick to whoever upload also pushes the tag and that the tag should be signed as well. Regards, -Roberto -- Roberto C. Sánchez
Bug#964098: [pkg-crosswire-devel] Bug#964098: Bug#964098: xiphos: package new upstream release: 4.2.1
On Sat, Jul 04, 2020 at 09:54:55AM +0200, Teus Benschop wrote: > >Hi Roberto, >The merge request of Bastian was now merged into the master branch. That's excellent! >Thank you @Bastian, for contributing to Debian. >I am now working on importing the newest upstream, and building the >package, then to test the package. >Everything is going well, so I am happy. :-) >If only the upstream maintainers would complete their WebKit2 editor, that >would be so good :) >It is WebKit (version 1) now. So Bastian had reworked on the patch to work >around it. Because WebKit (version 1) is not included in Debian unstable. I am guessing that means that the package in Debian will be missing some functionality, rather than this preventing it from being in Debian entirely. Regards, -Roberto -- Roberto C. Sánchez
Bug#964098: [pkg-crosswire-devel] Bug#964098: xiphos: package new upstream release: 4.2.1
On Wed, Jul 01, 2020 at 08:34:39PM +0200, Teus Benschop wrote: >Yes, that would be good. >There's some patches and bugs too. >It would be good if the new release would fix those issues. >I was thinking of working on this after a week or so time permitting. That would be excellent. Do you intend to start by reviewing Bastian's MR in Salsa? If you can't get to it by the end of next week, please let me know and I will take care of it. 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
Bug#954345: grisbi: Save (Ctrl+S) still saves even when escaping confirmation dialog
tags 954345 + fixed-upstream thanks On Fri, Mar 20, 2020 at 05:30:10PM +0100, Ludovic Rousseau wrote: > Le 20/03/2020 à 16:40, Roberto C. Sanchez a écrit : > > Package: grisbi > > Version: 1.2.2-1 > > Severity: important > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > It seems that when choosing "Save" (for example, with Ctrl+S) that the > > presented dialog does not function correctly. Speceifically, the dialog > > contains two options: "Cancel" and "Save". Pressing the "Escape" key > > seems like it should be equivalent to a "Cancel" selection. However, > > when I attempt this (pressing "Escape" to not have the changes saved), > > Grisbi still saves the changes. This seems to make it not possible to > > discard changes in the expected way. > > Exact. > I fixed the problem in Grisbi upstream at > https://github.com/grisbi/grisbi/commit/76c4dbb62bae791129b509b297800c98b2b0cd96 > > Do you think it is important enough that I need to make a new Debian version > of Grisbi just to fix this issue? > I don't think a special release is needed for this. I am glad that it is fixed already :-) I've tagged this bug fixed-upstream to ensure that others who may encounter it know that a fix will come with a future upstream release. Regards, -Roberto -- Roberto C. Sánchez signature.asc Description: PGP signature
Bug#952666: typo in dla-2123
On Mon, Mar 02, 2020 at 01:24:38AM +, McIntyre, Vincent (CASS, Marsfield) wrote: > Hello > > Not sure quite where to direct this. > > This recent DLA > https://www.debian.org/lts/security/2020/dla-2123 > > references the wrong debian bug, 925666. > The correct number is 952666. > Hi Vince, Thanks for catching that. I have just submitted a merge request to have that updated on the site. Regards, -Roberto -- Roberto C. Sánchez
Bug#950889: debootstrap: chroot no longer builds with user-owned target dir
On Thu, Feb 13, 2020 at 05:31:56PM +0900, Hideki Yamane wrote: > Hi, > > On Fri, 7 Feb 2020 15:33:08 -0500 > "Roberto C. Sanchez" wrote: > > It seems that with the latest change to the systemd journaling > > configuration, that chroots no longer build with a user-owned target > > directory. > > Well, then how about making chroot's / as root:root and 0755 > as sane default? > Well...I did just that. Was there something wrong with my request that debootstrap check the ownership and permissions of an existing target directory and provide a suitable warning or error if the conditions are not sane? Regards, -Roberto -- Roberto C. Sánchez
Bug#947043: cyrus-sasl2: CVE-2019-19906: Off by one in _sasl_add_string function
On Fri, Dec 20, 2019 at 10:24:20PM +0100, Salvatore Bonaccorso wrote: > > And released as DSA 4591-1. Note: The patch was not upstream commited > at point of writing this. And I see Mike did as well release for LTS. > I saw that Mike did updates for jessie (LTS) and wheezy (ELTS). > > > unstable would need an update as well yet. > > > > > Of course. > > Ideally this happen soon, but the RC bug is enough to mark the > 'stable' -> 'testing' regression. Just let me know if any of you can > do it or if you would prefer a NMU with same patch (both approaches > works for me). > I have made an upload to unstable of version 2.1.27+dfsg-2 with the patch that fixes the CVE. > > > Can you later import then the changes in the packaging repository in > > > the appropriate branches? > > > > > I could manage that in the coming days. Unless Ondrej or someone else > > gets to it first. > > Thanks! > As a summary, here is the state of cyrus-sasl2 in the various release and the associated Git branches in Salsa: sid: up to date on master branch, Debian version 2.1.27+dfsg-2 has been uploaded bullseye: waiting on transition of package from sid, no associated branch in Salsa buster: new branch, master-buster*, contains new commit representing Debian version 2.1.27+dfsg-1+deb10u1 stretch: new branch, master-stretch*, contains two (2) new commits representing Debian versions 2.1.27~101-g0780600+dfsg-3 (NMU in 2017 which as not recorded follwing 2.1.27~101-g0780600+dfsg-2) and Debian version 2.1.27~101-g0780600+dfsg-3+deb9u1 with the patch for this CVE jessie: history has diverged; there is already an old commit and tag for Debian version 2.1.26.dfsg1-13+deb8u2 from 2016 which collides with Mike's recent 2.1.26.dfsg1-13+deb8u2 jessie update, so I have not done anything with this wheezy: up to date on existing master-wheezy branch based on Mike's 2.1.25.dfsg1-6+deb7u2 ELTS updates * As far as the new master-buster and master-stretch branches, I only made those branches to record the changes which have already been uploaded. In particular, I did not update debian/gbp.conf to note the new branch names; such a change will be required if we decide to make further revisions along either of the new branches and then build from the Git repository. I have pushed tags for each of the above versions as well (except the jessie version, as noted). I include all of this information so that the cyrus-sasl2 in particular is made aware of all the changes I have pushed. Regards, -Roberto -- Roberto C. Sánchez
Bug#947043: cyrus-sasl2: CVE-2019-19906: Off by one in _sasl_add_string function
On Fri, Dec 20, 2019 at 08:36:00AM +0100, Salvatore Bonaccorso wrote: > Hi Roberto, > > On Thu, Dec 19, 2019 at 08:06:19PM -0500, Roberto C. Sánchez wrote: > > On Thu, Dec 19, 2019 at 09:19:19PM +0100, Salvatore Bonaccorso wrote: > > > > > > The following vulnerability was published for cyrus-sasl2. > > > > > > CVE-2019-19906[0]: > > > Off by one in _sasl_add_string function > > > > > > If you fix the vulnerability please also make sure to include the > > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > > > > Hi Team, > > > > Is anybody already working on this update? If not, I can start on it > > possibly tomorrow or perhaps the day after. > > > > Salvatore, > > > > If I (or someone else on the team) prepares the upload, do we go ahead > > and make the upload then let the security team handle the DSA > > publication? > > I already started yesterday, and have buster and stretch packages, > will likely release the DSA later today or tomorrow. So far tested > just lightly for stretch but will double check explicitly against > openldap. > Oh! That's excellent. > unstable would need an update as well yet. > Of course. > Can you later import then the changes in the packaging repository in > the appropriate branches? > I could manage that in the coming days. Unless Ondrej or someone else gets to it first. Regards, -Roberto -- Roberto C. Sánchez
Bug#947043: cyrus-sasl2: CVE-2019-19906: Off by one in _sasl_add_string function
On Thu, Dec 19, 2019 at 09:19:19PM +0100, Salvatore Bonaccorso wrote: > > The following vulnerability was published for cyrus-sasl2. > > CVE-2019-19906[0]: > Off by one in _sasl_add_string function > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > Hi Team, Is anybody already working on this update? If not, I can start on it possibly tomorrow or perhaps the day after. Salvatore, If I (or someone else on the team) prepares the upload, do we go ahead and make the upload then let the security team handle the DSA publication? Regards, -Roberto -- Roberto C. Sánchez
Bug#936338: cpuset: diff for NMU version 1.6-3.1
On Thu, Nov 28, 2019 at 09:20:30PM -0500, Sandro Tosi wrote: > Control: tags 936338 + patch > > > Dear maintainer, > > I've prepared an NMU for cpuset (versioned as 1.6-3.1). The diff > is attached to this message. > Hi Sandro, Many thanks for taking care of this. Regards, -Roberto -- Roberto C. Sánchez
Bug#943639: grisbi: text unreadable when GTK theme is Adwaita-Dark
On Sun, Oct 27, 2019 at 06:30:08PM +0100, Ludovic Rousseau wrote: > Le 27/10/2019 à 14:07, Roberto C. Sanchez a écrit : > > Package: grisbi > > Version: 1.2.2-1 > > Severity: normal > > Tags: upstream > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > When I changed my GTK theme to Adwaita-Dark much of the UI text became > > unreadable. It appears that some UI elements are specified for > > particular colors while others are left with default values. This > > resulted in things like white text on white background, which was > > impossible to read. > > > > I may try to fix this myself, but I am not sure when I may find time. > > I can reproduce the problem. > Screen copy attached. > > I have no idea how to fix it. I reported the issue upstream in > https://www.grisbi.org/bugsreports/view.php?id=1980 > > If you know how to fix it please share your knowledge. I may try to fix it > myself. > I don't know how to fix it, as I've never developed anything for GTK. That said, it seems like a good learning opportunity, so I may make an attempt when I can find some time. Regards, -Roberto -- Roberto C. Sánchez
Bug#914573: ITP: mongo-cxx-driver -- MongoDB C++ client library
I am still waiting. However, there are many packages still waiting in NEW, some for nearly one year, so I am not sure when mongo-cxx-driver might be approved. Regards, -Roberto On Sun, Oct 27, 2019 at 08:04:26PM +0100, Christophe CT. TROPHIME wrote: > Any news for this package? > > It seems to be in NEW but cannot find it elsewhere > > https://ftp-master.debian.org/new/mongo-cxx-driver_3.4.0-1.html > > Best. > C -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Bug#934128: ansible: CVE-2019-10217: gcp modules do not flag sensitive data fields properly
On Wed, Aug 07, 2019 at 12:49:11PM +0200, Salvatore Bonaccorso wrote: > Source: ansible > Version: 2.8.3+dfsg-1 > Severity: important > Tags: security upstream > Forwarded: https://github.com/ansible/ansible/issues/56269 > > Hi, > > The following vulnerability was published for ansible. > > CVE-2019-10217[0]: > | gcp modules do not flag sensitive data fields properly > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2019-10217 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10217 > [1] https://github.com/ansible/ansible/issues/56269 > [2] https://github.com/ansible/ansible/pull/59427 > It looks like the GCP module was introduced by this upstream commit: commit 9706abf68518dc0f663f23f64475f2b270851ae4 Author: Alex Stephen Date: Tue Feb 6 08:50:16 2018 -0800 [cloud] New GCP module: DNS Managed Zones (gcp_dns_managed_zone.py) (#35014) Based on that I have annotated the CVE as not affecting ansible in jessie. It may likewise not affect the versions in stretch and buster. Regards, -Roberto -- Roberto C. Sánchez
Bug#934817: libmysql++3v5: built with libmariadbclient18, which doesn't exist any longer
On Thu, Aug 15, 2019 at 01:52:18PM +0300, Otto Kekäläinen wrote: > Package: libmysql++3v5 > Control: affects -1 mariadb-10.3 > > Hello! > > The current version of this package in unstable is quite old and has > been built against libmariadbclient18, which no longer exists in > Debian unstable (superceeded by libmariadb3). > > This affects mariadb-10.3 which cannot currently migrate form Debian > unstable to Debian testing due to this old package stopping it with > its outdated run-time dependency. > > Please consider making a new upload of this package so that the > run-time dependencies update. I will be preparing an upload of the latest upstream release (3.2.5) in the next days. I will make sure to address this and the other outstanding bugs at that time. 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#922402: Bug #922402 in lintian marked as pending
On Sat, Feb 23, 2019 at 12:59:17PM -0800, Russ Allbery wrote:
> Roberto C. Sánchez writes:
>
> > Here is the line from the pkg-config file:
>
> > Libs: -L${libdir} -lbson-static-1.0 -lpthread -lgcc -lgcc_s -lc -lgcc
> > -lgcc_s /usr/lib/x86_64-linux-gnu/librt.so
> > /usr/lib/x86_64-linux-gnu/libm.so
>
> For whatever it's worth, I personally would consider editing all of that
> out in the Debian packaging unless you're explicitly trying to support
> -nostdlib builds with that library. The linker will add the correct
> version of that rune automatically by default, and providing it via
> pkg-config can sometimes cause issues if the handling of those libraries
> changes in the future.
>
Russ,
That is very helpful indeed. I will check with upstream to see if
-nostdlib support is the intent and will adjust the pkg-config script
accordingly.
Regards,
-Roberto
--
Roberto C. Sánchez
Bug#922402: Bug #922402 in lintian marked as pending
On Fri, Feb 15, 2019 at 09:46:52PM +, Chris Lamb wrote:
> Control: tag -1 pending
>
> Hello,
>
> Bug #922402 in lintian reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
>
> https://salsa.debian.org/lintian/lintian/commit/603d9f2c5f54af162dbbfccf370d1881bbc9430f
>
>
> Prevent false positives in pkg-config-references-unknown-shared-library (eg.
> "-lm") by creating an exception list and populating with shared objects
> shipped by libc6-dev. (Closes: #922402)
>
>
Hi Chris,
As I was working on packaging the new mongo-c-driver upstream, I
encountered the same problem, though with different libraries.
Here is the line from the pkg-config file:
Libs: -L${libdir} -lbson-static-1.0 -lpthread -lgcc -lgcc_s -lc -lgcc
-lgcc_s /usr/lib/x86_64-linux-gnu/librt.so
/usr/lib/x86_64-linux-gnu/libm.so
The complaints from lintian:
W: libbson-dev: pkg-config-references-unknown-shared-library
usr/lib/x86_64-linux-gnu/pkgconfig/libbson-static-1.0.pc -lpthread (line 9)
W: libbson-dev: pkg-config-references-unknown-shared-library
usr/lib/x86_64-linux-gnu/pkgconfig/libbson-static-1.0.pc -lgcc (line 9)
W: libbson-dev: pkg-config-references-unknown-shared-library
usr/lib/x86_64-linux-gnu/pkgconfig/libbson-static-1.0.pc -lgcc_s (line 9)
W: libbson-dev: pkg-config-references-unknown-shared-library
usr/lib/x86_64-linux-gnu/pkgconfig/libbson-static-1.0.pc -lc (line 9)
W: libbson-dev: pkg-config-references-unknown-shared-library
usr/lib/x86_64-linux-gnu/pkgconfig/libbson-static-1.0.pc -lgcc (line 9)
W: libbson-dev: pkg-config-references-unknown-shared-library
usr/lib/x86_64-linux-gnu/pkgconfig/libbson-static-1.0.pc -lgcc_s (line 9)
It looks like perhaps libraries files shipped in libgcc1 also need to be
added to the whitelist.
Regards,
-Roberto
--
Roberto C. Sánchez
Bug#842284: closed by Markus Koschany (Bug#842284: fixed in libnb-platform18-java 10.0-2)
On Fri, Jan 25, 2019 at 12:57:03PM +, Debian Bug Tracking System wrote: >* Add AutoUpdate-NEVER.patch and set the defaultCheckInterval to NEVER to > prevent automatic updates. This can be changed by users individually. > (Closes: #842284) Hi Markus, Thanks for doing this. I very much appreciate it. Regards, -Roberto -- Roberto C. Sánchez
Bug#901296: ping ...
On Thu, Oct 04, 2018 at 01:06:33AM +0530, shirish शिरीष wrote: > Hi Roberto, > > please share your thoughts . > Hi Shirish, My apologies for the delay. Right now I am leaning toward following this project as a new upstream: https://github.com/ValyriaTear/luabind Please let me know if you have any thoughts on that. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Bug#914632: RFC: proposed fix for CVE-2018-19518 in uw-imap
Hi Salvatore, On Sun, Dec 30, 2018 at 09:38:57AM +0100, Salvatore Bonaccorso wrote: > > There is an alternative approach wich was raised by Magnus in the > respective bug: https://bugs.debian.org/914632#12 (and see followup > from Moritz). > I suppose I should have looked more carefully at the bugs associatd with CVE-2018-19518 and subscribed to this one. Thank you for pointing it out to me. The suggestion from Magnus is certainly less likely than mine to allow for a future exploit of the same mechanism via different means. Magnus, Would you prefer to handle the jessie update? If not, I will wait until you have patch ready and I can build/upload for jessie and release the corresponding advisory. Regards, -Roberto -- Roberto C. Sánchez
Bug#791814: sasl2-bin: fails to start saslauthd
package sasl2-bin tag 791814 + moreinfo unreproducible thanks On Thu, Jul 09, 2015 at 01:42:37AM +0900, yamasita wrote: > >* What led up to the situation? > > I was if it was normal installation. > (apt-get install sasal2-bin) > It failed to start. > service saslauthd start > or > /etc/init.d/saslauthd start > or > systemctl start saslauthd.service > >* What exactly did you do (or not do) that was effective (or ineffective)? > > I was editing the /etc/default/saslauthd. > It was changed to "START=yes". > >* What was the outcome of this action? > > saslauthd did not start. > >* What outcome did you expect instead? > > saslauthd is wanted to start. > I have attempted to reproduce this in a stretch Docker. After starting the container, I ran 'apt-get update && apt-get install -y sasl2-bin'. After that, this is the result: root@9fb09a55b38d:~# /etc/init.d/saslauthd status [FAIL] Checking SASL Authentication Daemon: saslauthd (not running) failed! root@9fb09a55b38d:~# /etc/init.d/saslauthd start [warn] To enable saslauthd, edit /etc/default/saslauthd and set START=yes ... (warning). root@9fb09a55b38d:~# sed -i 's/START=no/START=yes/' /etc/default/saslauthd root@9fb09a55b38d:~# /etc/init.d/saslauthd start [ ok ] Starting SASL Authentication Daemon: saslauthd. Here is the same sequence in an unstable Docker: root@1b23b77be2b2:~# /etc/init.d/saslauthd status [FAIL] Checking SASL Authentication Daemon: saslauthd (not running) failed! root@1b23b77be2b2:~# /etc/init.d/saslauthd start [warn] To enable saslauthd, edit /etc/default/saslauthd and set START=yes ... (warning). root@1b23b77be2b2:~# sed -i 's/START=no/START=yes/' /etc/default/saslauthd root@1b23b77be2b2:~# /etc/init.d/saslauthd start [ ok ] Starting SASL Authentication Daemon: saslauthd. Can you try again to see if you can reproduce this problem. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
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
Bug#906236: fatal regression in openssh (1:6.0p1-4+deb7u8) elts for 7/wheezy
On Mon, Sep 17, 2018 at 10:58:15AM +0200, Joost van Baal-Ilić wrote: > Hi, > > After upgrading openssh on debian 7/wheezy from 6.0p1-4+deb7u7 to > 6.0p1-4+deb7u8, > we see > > Sep 17 10:47:13 host sshd[124622]: Failed publickey for root from 1.2.3.4 > port 39792 ssh2 > Sep 17 10:47:13 host sshd[124622]: fatal: xfree: NULL pointer given as > argument [preauth] > > . Login fails: > > joostvb@home:~% ssh root@host > Authentication failed. > > . Downgrading back to 6.0p1-4+deb7u7 restores login functionality. > > Behaviour observed on 2 of our machines. Possibly more debug information > available; please ask. > > Bye, > > Joost > Joost, Thanks to your detailed report and the supplementary information you provided I have been able to determine the cause of the defect in the patch for openssh 1:6.0p1-4+deb7u8. I have just uploaded a new openssh (version 1:6.0p1-4+deb7u10) and published an updated advisory (ELA-37-3). With the additional information I received from you I was able to perform much more thorough testing of these packages and specific testing to ensure that the defect has been corrected. Regards, -Roberto -- Roberto C. Sánchez
Bug#903815: Bug#903880: Bug#903815: ITP: pw -- A simple command-line password manager
On Mon, Jul 16, 2018 at 02:36:17PM +0200, Dashamir Hoxha wrote: >On Mon, Jul 16, 2018 at 2:21 PM Holger Levsen <[1]hol...@layer-acht.org> >wrote: > > On Sun, Jul 15, 2018 at 12:41:36PM +0200, Carsten Schoenert wrote: > > Hmm, do you have tried to validate your shell code? > > [2]https://www.shellcheck.net/ > > I just pasted > > [3]https://raw.githubusercontent.com/dashohoxha/pw/master/src/pw.sh > into > > and got quite a lot of problematic remarks. > > I've also done this now and must say/add "ouch": > >I have already answered this. Only one of the suggestions might be useful. >If everything was clean, according to shellcheck, this wouldn't mean at >all >that the program is safe and secure and takes care of all the cases. >I know what is going on in my program better than the mindless shellcheck. > I've been following this thread and it is very difficult for me to understand why constructive criticism from others is so difficult for you to accept. In general, the community of Debian Developers is very concerned with producing a high quality distribution and also with supporting free software development. The fact that some have taken the time and interest to critique your work is very positive. Yet, you choose to perceive their critiques as an attack and then launch your own counter-attack. I don't mean to lecture, but your responses to several of the messages in this thread indicate that you are likely a younger/junior developer. That is not intended to be disparraging, but rather I am trying to understand the reason for the way in which you have responded in this thread. In my own case, I know that my attitude in response to critique was much like yours, when I was still a young developer who thought he knew it all. Over the years, though, I have come to understand that I know far less than I thought I knew when I was younger. That is, the world of programming knowledge far larger than I originally understood it to be. Even now, as a very experienced and senior developer, I frequently seek the advice and review of colleagues whenever I make significant changes to existing code, write new code, etc. I can tell you that I am a far better and more productive developer as a result. Another thing which seems to indicate that you are not particularly mature as a developer is the manner in which you quickly dismiss the results of static analysis. Certainly, there are instances where the tools do not fully understand the meaning of your code and provide false alarms. However, I have come to realize that static analysis is right for more than it is wrong. So, I have adopted the position that unless I can clearly articulate a good reason why the static analysis is wrong and my approach is better (and defend that reason to other programmers more senior than myself), I defer to the tool and fix the code. I do this in several programming languages. Additionally, the argument that you make, "If everything was clean, according to shellcheck, this wouldn't mean at all that the program is safe and secure and takes care of all the cases," is totally invalid. The fact that the tool fails to catch everything is not justification to automatically reject the things that it does catch. If the tool is consistently wrong, contact the developer of the tool with a sample of your code that you think the tool is incorrectly flagging, and convince the tool developer (using a technical and supported argument) why the tool should be updated. Your discussion with the tool developer might reveal to you that there is a defect in your own code that you did not understand. I encourage you, for your own benefit to accept the criticism from myself and others in the spirit in which it was intended: to help you produce a better free software tool and to improve as a developer. Regards, -Roberto -- Roberto C. Sánchez
Bug#903815: ITP: pw -- A simple command-line password manager
On Mon, Jul 16, 2018 at 03:14:20PM +0200, Dashamir Hoxha wrote: >On Mon, Jul 16, 2018 at 2:16 PM Philipp Kern <[1]pk...@debian.org> wrote: > > This clearly writes the unencrypted tarball out to disk. > >It writes to `/dev/shm` which is not disk. That is not a valid assumption. You have no way of knowing the device behind /dev/shm. > It writes to a random >temporary directory, so that it cannot be guessed. It removes >the unencrypted content as soon as the operation is performed. Unless the operation is atomic there is a possibility it can be interrupted. >All this happens almost instantly, it never stays unencrypted >for a long time. Ibid. > It is almost the same thing as using a pipe (|). >What is wrong here? It is not the same thing and it is based on several invalid/flawed assumptions. > I have been using it for 2-3 years and >never had a problem. > That doesn't make it correct code. I spend most of my day in code bases authored by other people. I consistently find bugs that have been in production, unreported, for 10 or more years. A bug is still a bug when it is found and identified, even if it has never manifested itself in the real world. If you doubt that, please review the recent news surrounding the SPECTRE and MELTDOWN vulnerabilities. Regards, -Roberto -- Roberto C. Sánchez
Bug#894297: Intent to NMU cyrus-sasl2 (was: [PATCH] cyrus-sasl2: please add build-profile support)
Hi Karsten, On Fri, Apr 20, 2018 at 04:51:04PM +0200, Karsten Merker wrote: > > - Judging from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799864, > the package changelog and the lack of activity on the > pkg-cyrus-sasl2-debian-devel mailinglist, you appear to be the > only remaining person in the cyrus-sasl2 packaging team. > > - You have marked all your packages as "Low-Threshold-NMU" at > https://wiki.debian.org/LowThresholdNmu. > > - The patch from bug #894297 is largely noninvasive as it doesn't > touch the actual cyrus-sasl2 codebase, only has any effect > at all if a build-profile is explicitly enabled during building > the package and uses the existing DEB_BUILD_OPTIONS-based > infrastructure in debian/rules. > For what it is worth, I still consider myself a member of the team. I agree that cyrus-sasl2 is in need of a great deal of attention. This semester at school has been very busy, though it is almost over. It will probably be at least a few weeks before things calm down enough for me to devote a sufficiently large block of time/effort to cyrus-sasl2 maintenance. As far as I am concerned, I welcome your NMU, so please go ahead with it. Regards, -Roberto -- Roberto C. Sánchez
Bug#810735: Workaround
I ran into this same issue and here is the workaround I used: debian:/dev# ls -l mm* brw-rw 1 root disk 179, 0 Mar 10 11:06 mmcblk0 brw-rw 1 root disk 179, 1 Mar 10 11:06 mmcblk0p1 debian:/dev# fatresize -i /dev/mmcblk0p1 fatresize 1.0.2 (01/27/16) Error: Could not stat device /dev/mmcblk0p - No such file or directory. debian:/dev# ln -s mmcblk0 hda debian:/dev# ln -s mmcblk0p1 hda1 debian:/dev# ls -l hda* lrwxrwxrwx 1 root root 7 Mar 10 11:12 hda -> mmcblk0 lrwxrwxrwx 1 root root 9 Mar 10 11:12 hda1 -> mmcblk0p1 debian:/dev# fatresize -i /dev/hda1 fatresize 1.0.2 (01/27/16) FAT: fat32 Size: 128042663936 Min size: 30039024640 Max size: 128043712512 You just need to remember to remove the symlinks when you finish. Also, best to check and use names that do not already exist in /dev. Regards, -Roberto -- Roberto C. Sánchez
Bug#889285: bind9: CVE-2017-3139 affects debian too: assertion failure in validator.c:1858
On Sat, Feb 03, 2018 at 05:17:01PM +0100, Salvatore Bonaccorso wrote: > > The bug was about CVE-2017-3137, it's never a good idea to mix up > things ;-). This is true. However, it appears that Ondrej Zary's comment to #860225 on 2017-09-02 is in fact related to CVE-2017-3139. Since one of the bind9 maintainers was the one to raise the issue of CVE-2017-3139 in that same bug, I don't see a related follow-up report from a user to be problematic. > Anyway thanks that you took action and filled a new bug > for this issue you are experiencing. > > JTR, since Red Hat does not provide much details on the CVE-2017-3139 > we cannot say Debian is affected as well by this very same CVE. Since > it's not clear, what CVE-2017-3139 is in detail, I have removed the > CVE in the subject of this bug. > It is true that there is information provided by RedHat regarding the details of the vulnerability. The RHSA mentioned in #860225 is also linked from this RedHat BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1447743 However, there are no useful details there either. I did some digging and located the bind9 source RPM references in RHSA-2017:1202 and its immediate predecessor. By comparing the packages, I was able to identify the specific patch that was associated with that RHSA. I have attached the patch to this email. The name of the patch refers to another RedHat BZ entry: https://bugzilla.redhat.com/show_bug.cgi?id=1447407 That one is not accessible to the public, so we have no way of knowing the details there. Additionally, the related upstream RT tickets are also not public. Note that the attached patch appears to be based on commit 07dbb507d2913fc35c7edbe3692a976e3248a911 from upstream's git repository: https://source.isc.org/git/bind9.git The upstream changes appear to include a hunk in resolver.c which does not appear in the RedHat patch. That chunk would also not apply to the wheezy version of bind9. > What seem clear is that apparently a fix in Debian wheezy's bind9 > version causes the regression you notices. Thus I suggest the LTS team > to try to find the defective patch introducing the issue and then > issue just a regression update (without referencing CVE-2017-3139. If > its on the other hand clear that Debian wheezy used the very same > patch for a previous issue, and CVE-2017-3139 applies as well for > Debian wheezy, then obviously it's fine to use the CVE). > I examined the changes made from 9.8.4.dfsg.P1-6+nmu2+deb7u15 to 9.8.4.dfsg.P1-6+nmu2+deb7u16, which included fixes for CVE-2017-3136, CVE-2017-3137, and CVE-2017-3138. After examining the changes and comparing them to the related upstream commits, I am convinced that the fix for CVE-2017-3137 in 9.8.4.dfsg.P1-6+nmu2+deb7u16 is correct and complete. I would consider my examination thorough, but not exhaustive owing to the large volume of change and some departures that are clearly a result of the upsteam changes being backported to the bind9 in wheezy. I am further convinced that the problem reported by Ondrej Zary in #860225 and by Vladislav Kurz are both identical occurrences of CVE-2017-3139. In order to confirm the latter hypothesis, I built the current wheezy version of bind9 and ran the dnssec test. The test passed. I then stripped the changes to validator.c from the attached patch and applied the remainder to the current wheezy version of bind9, built, and ran the dnssec test again. This time the test failed. This seems to indicate that the version of bind9 in wheezy is vulnerable to CVE-2017-3139. I then applied the remaining validator.c changes, rebuilt, and ran the dnssec test again. This time the test passed. Based on these findings, I conclude that wheezy bind9 is vulnerable to CVE-2017-3139. I propose to do the following: - Mark CVE-2017-3139 as affecting wheezy in the security tracker - Prepare and upload a version 9.8.4.dfsg.P1-6+nmu2+deb7u20 upload that incorporates the CVE-2017-3139 patch from RedHat (and which closes this bug, #889285) - Release a DLA per the normal procedure I am now in the process of preparing the package for upload, but I will wait a couple of days to allow for any objections and/or suggestions. Regards, -Roberto -- Roberto C. Sánchez >From 1d31a0cf1712d3eb001a686c06fe1225ba48fd04 Mon Sep 17 00:00:00 2001 From: Mark Andrews <ma...@isc.org> Date: Sat, 6 Oct 2012 14:56:33 +1000 Subject: [PATCH] 3391. [bug] DNSKEY that encountered a CNAME failed. [RT #31262] (original commit 07dbb507d2913fc35c7edbe3692a976e3248a911) --- bin/tests/system/dnssec/clean.sh | 1 + bin/tests/system/dnssec/ns3/secure.example.db.in | 4 ++ bin/tests/system/dnssec/ns3/sign.sh | 4 +- bin/tests/system/dnssec/tests.sh | 66 lib/dns/validator.c | 4 ++ 5 files changed, 78 insertions(+), 1 deletion(-) diff --git a/bin/tests/syste
Bug#889285: bind9: CVE-2017-3139 affects debian too
On Sat, Feb 03, 2018 at 02:37:14PM +0100, Vladislav Kurz wrote: > Hello LTS team, > > please have a look at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889285 > > I think it is the same bug as CVE-2017-3139 which was considered to affect > only RedHat, but it seems to affect debian wheezy too. > > Please check if it is possible to apply the same fixes as RedHat did. > Or at leas update the bind package in wheezy-backports to match the version > and security fixes from debian jesssie. > I am taking a look at this now. Regards, -Roberto -- Roberto C. Sánchez
Bug#888484: Packages still not available?
On Mon, Jan 29, 2018 at 02:30:01PM +0100, Fared Ghijas wrote: > >The fixed versions seem not to be available at > > [1]https://packages.debian.org/search?keywords=clamav=names=all=all > >. > It should be shortly. >Why does it take so long for such a critical bug. Because Debian has a process for issuing both security and non-security updates. That process involves the review of multiple parties. In the case of ClamAV, the updates are frequent enough that they are handled via the proposed-updates mechanism, which requires the review and approval of a release manager. This is explained in the discussion history of this bug. >This means DOS and >remote code execution vulnerability for a whole lot of mail gateways, >which might expose communication, abuse those systems for spam or use them >to get into trusted networks. The vulnerability is already actively used. Everybody involved is well aware of this. >The answer cannot be to compile a new version on our own. This is not the >reason for having a long term support distribution, maybe with a small >footprint without a compiler. It took already more than 72h while the >patch was available. > I cannot tell if you are serious or if you are trolling here. Debian is in use on hundreds of thousands, if not millions, of systems worldwide. It helps nobody to have patches rushed out without proper testing and review. Additionally, much of the work on Debian is being done by unpaid volunteers in their spare time. Additionally, the manner in which upstream made the release involved changing the version numbering of a release that was already planned, which complicated matters a bit. If you are so dependent on having updates in a particular time frame, then you should consider developing the ability to build your own security updates (yes, compiling the updates for yourself can certainly be a valid answer). If that is not possible or desirable for you, then you should contract with a commercial entity that can provide that support. There are numerous individuals and companies, including quite a few Debian developers, who would be more than happy to furnish you a support contract with a specified service level agreement response time. >The open source world usually does a great job on fast security updates >and I’m sure you guys do too. > I am not convinced that you understand and appreciate the amount of effort involved. >Could you please provide this update as soon as any possible or give us >some information how long it will take? > If you look at the messages recorded in the bug history prior to your message, the packages for jessie and stretch were uploaded about 15 hours prior to you sending your message. It takes some time for packages to be built for all supported architectures and then to be distributed across the worldwide archive mirror network. The stretch packages have all been built for a few hours now and should show up in the archive mirrors within a few hours. Regards, -Roberto -- Roberto C. Sánchez
Bug#886238: Please introduce official nosystemd build profile
On Wed, Jan 03, 2018 at 02:25:03PM +0100, Marco d'Itri wrote: > On Jan 03, Andrew Shadura <and...@shadura.me> wrote: > > > Do we really need systemd-less builds? I'm not convinced this is > > something relevant to Debian. > Not at all. > This would be a lot of work for the benefit of a tiny audience: the > disturbed people who hate systemd so much that they cannot accept even > that libsystemd is installed on their computers. > - OR - > Not at all. > This would be a lot of work for the benefit of a tiny audience: the > disturbed people who hate [non-free] so much that they cannot accept even > that [any non-free software] is installed on their computers. I suspect that having the archive split into main/contrib/non-free involves a non-trivial amount of work. Yet Debian as a project, to serve its users and derivatives, undertakes the work. As has already been pointed out by others, if someone is interested in doing the work and it is not too invasive or disruptive to other parts of Debian, then it should be done. That said, I find that your characterization of someone not wanting systemd installed on their system as "disturbed" to itself be somewhat disturbing. You cannot possibly know what grounds someone might have for not wanting systemd, and to automatically and universally characterize that as "disturbed" implies a value judgment that runs counter both to the freeness and universailty that Debian as a project espouses. Regards, -Roberto -- Roberto C. Sánchez
Bug#880566: [Pkg-crosswire-devel] Bug#880566: Sponsorship request
On Mon, Nov 20, 2017 at 11:49:12AM +, Teus Benschop wrote: >The newest packaging available from [1] fixes this bug. >I am asking for assistance with reviewing and uploading this packaging. >[1] [1]https://anonscm.debian.org/gitweb/?p=pkg-crosswire/bibletime.git Hi Teus, Apologies for the long delay. The package looks good, so I have uploaded it. Also, there was no tag in Git for 2.11.1-1, so I also tagged it and pushed the tag. Regards, -Roberto -- Roberto C. Sánchez signature.asc Description: PGP signature
Bug#878227: [Pkg-crosswire-devel] Bug#878227: Sponsorship request
On Tue, Nov 21, 2017 at 12:56:25PM +, Teus Benschop wrote: >The newest bibledit package is available from [1]. The version number >is [1]5.0.331. This is a request for sponsorship, for review and for >upload. >Thank you! >[1] [2]https://anonscm.debian.org/cgit/pkg-crosswire/bibledit-gtk.git/ > Hi Teus, Apoligies for the long delay. The package looks good so I have uploaded it. Regards, -Roberto -- Roberto C. Sánchez signature.asc Description: PGP signature
Bug#719810: shorewall-init: On ethernet module rmmod/modprobe shorewall-init fails to bring back firewall rules correctly
tags 719810 + unreproducible moreinfo thanks On Thu, Aug 15, 2013 at 10:37:38AM -0400, Daniel Dickinson wrote: > Package: shorewall-init > Version: 4.5.5.3-1 > Severity: minor > > This is a bit of a corner case. Due to a bug in the r8169 gige driver > my network connection has issues that require the ethernet driver be > rmmod'd then modprobe'd. Shorewall-init doesn't seem to properly > handl this case as shorewall's firewall rules are not put back in > place on the modprobe (and consequent network manager reconnection to > the router). > Hi Daniel, Apologies for the long delay, I sort of lost track of this bug report. I have tried to reproduce this on a fresh Debian Stretch install (inside of a Qemu VM guest). I installed/configured shorewall and confirmed that there were iptables rules that had been made active. Then I did an rmmod on virtio_net, checked and saw that the rules were still active, then did a modprobe on virtio_net and again checked and found the rules still active. At this point I believe that the bug you encountered is either a result of a specific bug in the r8169 driver, or some other kernel bug. I doubt that it is a Shorewall bug, as Shorewall is not an active service, so it would not have a way to monitor the removal of the iptables rules. This, along with the age of your original bug report causes me to think that it should be closed. However, before I do that I wanted to give you the opportunity to comment or provide additional information that might allow reproducing the bug. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Bug#881162: tomcat7: Server reports 404 on any request, even /
On Wed, Nov 08, 2017 at 03:03:06PM +0100, Markus Koschany wrote: > Thank you for the report. There was a recent security update of Tomcat 7 > which is the likely cause for this issue. > > Roberto can you take a look please? > Hi Markus & others, I was able to identify the cause of the regression that I introduced. There are updated packages here: https://people.debian.org/~roberto/ My testing this time around was more thorough and I believe that this update properly addresses the CVE without introducing a regression. If some intrepid souls could test these packages and give a thumbs up, I will upload the packages in the next 12-18 hours and then release an updated advisory. Here is my proposed advisory text: The update for tomcat7 issued as DLA-1166-1 caused a regressions whereby every request, including for the root document (/), returned HTTP status 404. Updated packages are now available to address this problem. For reference, the original advisory text follows. When HTTP PUT was enabled (e.g., via setting the readonly initialization parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server. For Debian 7 "Wheezy", these problems have been fixed in version 7.0.28-4+deb7u17. For those who are interested, the regression resulted from a combination of two factors. - When incorporating one of the upstream change sets, an unclean patch application produced a .rej rejection file which I overlooked - When incorporating another upstream changeset, my attempt to integrate the minimal change was too minimal and left out an important additional change These problems did not manifest themselves in my initial testing of the 7.0.28-4+deb7u16 packages because of browser caching. I offer my apologies for causing this problem and my thanks for your help in resolving it. Regards, -Roberto -- Roberto C. Sánchez signature.asc Description: PGP signature
Bug#881162: tomcat7: Server reports 404 on any request, even /
On Wed, Nov 08, 2017 at 03:03:06PM +0100, Markus Koschany wrote: > Thank you for the report. There was a recent security update of Tomcat 7 > which is the likely cause for this issue. > > Roberto can you take a look please? > Hi Markus, I also received a direct email from another user this morning who was experiencing a similar issue. I will definitely take a look. Regards, -Roberto -- Roberto C. Sánchez
Bug#860928: dnssec-trigger + isc-dhcp-client: /etc/ being cluttered with tons of resolv.conf.dhclient-new.* files
On Sat, Apr 22, 2017 at 02:26:59AM +0200, Axel Beckert wrote: > > * dhclient remove /etc/resolv.conf.dhclient-new.$pid again, if the > renaming failed. > Incidentally, the dhclient-script performs the move, the stderr output of the failed mv command does not get properly logged. I did notice that systemd will capture it, but I use logcheck (which doesn't look at the systemd journal) and so did not notice this problem for some time. > * dhclient prepares resolv.conf.dhclient-new.$pid not in /etc/ but in > /tmp/. There it's far less annoying if the directory is cluttered with > small files and those files would be usually cleaned up at > reboot. (Disavantage: The renaming is often a move from one file > system to another -- which might not be wanted.) > I think that this is the best solution. Could you explain why you think that the crossing the filesystem boundary is a disadvantage? > * dnssec-triggerd cleans up those files, either time-based or > event-based. > I think this is not the right approach as it results in the files still being there if dnssec-trigger is not present. Regards, -Roberto -- Roberto C. Sánchez
Bug#866632: [Pkg-crosswire-devel] Bug#866632: Reported upstream
forwarded 866632 https://github.com/postiffm/bibledit-desktop/issues/37 thanks Hi Teus, The above command to the BTS control server [0] annotates the bug's metadata with the URL of the upstream bug report. That causes it to show up at the top of the bug's status page and makes the information accessible through the BTS API. I have added the control address to the BCC of this message so that it will already be accomplished by me sending this message and there is no need for you to take any action. However, you may want to review the BTS control server page to see what other mechanisms are available. You can also issue the same commands using the reportbug command-line utility. Regards, -Roberto [0] https://www.debian.org/Bugs/server-control#forwarded On Wed, Oct 18, 2017 at 12:56:20PM +, Teus Benschop wrote: >This bug report has been forwarded to the upstream developer @ github. >Here is the link to the issue on github: >[1]https://github.com/postiffm/bibledit-desktop/issues/37 > > References > >Visible links >1. https://github.com/postiffm/bibledit-desktop/issues/37 > ___ > 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
Bug#878158: lapack: debian/rules sed expression breaks for some LDFLAGS values
Of course, a better delimiter is one that is not already used in the expression itself. Perhaps the at symbol @. -- Roberto C. Sánchez
Bug#688428: Malformed transaction database
I just encountered this problem and it was the result of a malformed packagekit transaction database : roberto-pc:~# apt-get install --reinstall libapt-pkg5.0 apt apt-utils Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 3 reinstalled, 0 to remove and 0 not upgraded. Need to get 2,558 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://ftp.us.debian.org/debian stretch/main amd64 libapt-pkg5.0 amd64 1.4.7 [916 kB] Get:2 http://ftp.us.debian.org/debian stretch/main amd64 apt amd64 1.4.7 [1,231 kB] Get:3 http://ftp.us.debian.org/debian stretch/main amd64 apt-utils amd64 1.4.7 [410 kB] Fetched 2,558 kB in 0s (49.9 MB/s) (Reading database ... 277322 files and directories currently installed.) Preparing to unpack .../libapt-pkg5.0_1.4.7_amd64.deb ... Unpacking libapt-pkg5.0:amd64 (1.4.7) over (1.4.7) ... Setting up libapt-pkg5.0:amd64 (1.4.7) ... (Reading database ... 277322 files and directories currently installed.) Preparing to unpack .../archives/apt_1.4.7_amd64.deb ... Unpacking apt (1.4.7) over (1.4.7) ... Setting up apt (1.4.7) ... (Reading database ... 277322 files and directories currently installed.) Preparing to unpack .../apt-utils_1.4.7_amd64.deb ... Unpacking apt-utils (1.4.7) over (1.4.7) ... Setting up apt-utils (1.4.7) ... Processing triggers for libc-bin (2.24-11+deb9u1) ... Processing triggers for man-db (2.7.6.1-2) ... Error: Timeout was reached roberto-pc:~# apt-get update Ign:1 http://ftp.us.debian.org/debian stretch InRelease Hit:2 http://security.debian.org/ stretch/updates InRelease Hit:3 http://ftp.us.debian.org/debian stretch-updates InRelease Hit:4 http://ftp.us.debian.org/debian stretch Release Error: Timeout was reached Reading package lists... Done roberto-pc:~# /usr/lib/packagekit/packagekitd --verbose 17:55:56PackageKit Verbose debugging enabled (on console 1) 17:55:56PackageKit daemon shutdown set to 0 seconds 17:55:56PackageKit clearing download cache at /var/cache/PackageKit/downloads 17:55:56PackageKit setting config file watch on /etc/PackageKit/PackageKit.conf 17:55:56PackageKit Trying to load : aptcc 17:55:56PackageKit dlopening '/usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so' 17:55:57PackageKit trying to open database '/var/lib/PackageKit/transactions.db' 17:55:57PackageKit creating table to repair: Failed to execute statement 'SELECT * FROM transactions LIMIT 1': database disk image is malformed Failed to load the backend: Failed to execute statement 'CREATE TABLE transactions (transaction_id TEXT PRIMARY KEY,timespec TEXT,duration INTEGER,succeeded INTEGER DEFAULT 0,role TEXT,data TEXT,description TEXT,uid INTEGER DEFAULT 0,cmdline TEXT);': table transactions already existsroberto-pc:~# roberto-pc:~# rm -f /var/lib/PackageKit/transactions.db roberto-pc:~# apt-get update Ign:1 http://ftp.us.debian.org/debian stretch InRelease Hit:2 http://security.debian.org/ stretch/updates InRelease Hit:3 http://ftp.us.debian.org/debian stretch-updates InRelease Hit:4 http://ftp.us.debian.org/debian stretch Release Reading package lists... Done roberto-pc:~# apt-get update I got the idea to check from here: https://fanf42.blogspot.com/2014/08/upgrading-to-ubuntu-1404-error-timeout.html This could really use a better/more robust error message. Regards, -Roberto -- Roberto C. Sánchez signature.asc Description: Digital signature
Bug#871810: cvs: CVE-2017-12836: CVS and ssh command injection
Hi Thorsten, On Sat, Aug 12, 2017 at 05:26:22PM +, Thorsten Glaser wrote: > Hi LTS team, > > >>On Sat, Aug 12, 2017 at 12:36:57PM +0200, SC)bastien Delafond wrote: > > >>>For wheezy, you'll need to check directly with the Debian LTS team, that > >>>can be reached via debian-...@lists.debian.org. > > is the attached debdiff ok to upload? (Specifically, is the distribution > in the changelog set correctly?) Obviously, I’ll build it in a wheezy > cowbuilder first. Yes, that looks correct. You could also do a source-only upload (assuming that you have otherwise built/tested in a wheezy environment). > > How do I upload, i.e. to what queue do I dput, and do I use -sa? > You can dput to security-master like a normal security update and -sa would likely get the upload rejected as the .orig.tar.gz is already in the archive. Regards, -Roberto -- Roberto C. Sánchez signature.asc Description: Digital signature
Bug#451665: Please include a doc-base registration file
On Sat, Aug 12, 2017 at 05:12:00PM +, Niels Thykier wrote: > On Sun, 18 Nov 2007 08:19:13 -0500 Roberto > =?iso-8859-1?Q?C=2E_S=E1nchez?= <robe...@connexer.com> wrote: > > > > /me lovingly pats the "Intermediate Perl" and "Perl in a Nutshell" books > > on my desk :-) > > > > I'm still learning, but I may give it a go in the next few weeks. > > > > Regards, > > > > -Roberto > > > > -- > > Roberto C. Sánchez > > http://people.connexer.com/~roberto > > http://www.connexer.com > > Hi, > > Any news on this bug? :) > > 10 years ago, there were talks about writing patches - but given it > hasn't materialized, I am wondering if this bug is still relevant? > To be fair, it is closer to 9.75 years ago, but no matter :-) I have to admit that I totally forgot about this. I don't find it to be an issue any longer, so unless there is some other reason to keep the bug open, feel free to close it. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Bug#870120: Upstream commits for CVE-2017-11539
Here are the upstream commits that fix CVE-2017-11539: ImageMagick-6: https://github.com/ImageMagick/ImageMagick/commit/4e81160d66f02bf7b4f569669ca7dd80d416ba6e ImageMagick-7: https://github.com/ImageMagick/ImageMagick/commit/36aad912d1f405a28a9a1204120b569e7da5898e Regards, -Roberto -- Roberto C. Sánchez signature.asc Description: Digital signature
Bug#868469: Upstream commits for CVE-2017-11352
Here are the upstream commits that fix CVE-2017-11352: ImageMagick-6: https://github.com/ImageMagick/ImageMagick/commit/7f1f01b695e869c410ee10e2176f8fd764f09373 ImageMagick-7: https://github.com/ImageMagick/ImageMagick/commit/86cb33143c5b21912187403860a7c26761a3cd23 Regards, -Roberto -- Roberto C. Sánchez signature.asc Description: Digital signature
Bug#863285: [winbind] Install/Updates Fail When Samba Running as samba 4 Domain
amba-addc1:~# echo $SERVER_ROLE
active directory domain controller
samba-addc1:~# samba-tool testparm --parameter-name="server services"
s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc,
dnsupdate
samba-addc1:~# echo $SERVER_SERVICES
s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc,
dnsupdate
samba-addc1:~# samba-tool testparm --parameter-name="dcerpc endpoint servers"
epmapper, wkssvc, rpcecho, samr, netlogon, lsarpc, spoolss, drsuapi, dssetup,
unixinfo, browser, eventlog6, backupkey, dnsserver
samba-addc1:~# echo $DCERPC_ENDPOINT_SERVERS
epmapper, wkssvc, rpcecho, samr, netlogon, lsarpc, spoolss, drsuapi, dssetup,
unixinfo, browser, eventlog6, backupkey, dnsserver
samba-addc1:~# if [ "$SERVER_ROLE" != "active directory domain controller" ] \
> && ( echo "$SERVER_SERVICES" | grep -qv '\(^\|, \)smb\(,\|$\)' ) \
> && ( echo "$DCERPC_ENDPOINT_SERVERS" | grep -qv '\(^\|, \)remote\(,\|$\)' ) \
> && ( echo "$DCERPC_ENDPOINT_SERVERS" | grep -qv '\(^\|, \)mapiproxy\(,\|$\)'
> ) \
> ; then
> echo "Ohai, I am an AD domain controller"
> fi
I believe that looking for "smb" in "server services" is perhaps too
restrictive, though I am not sure. I would expect the configuration of
my server pass the check and print the text of the echo I substituted.
In any event, I don't think I fully understand what the postinst is
trying to do, since on my system samba-ad-dc.service appears in several
places, but never in /etc/systemd/system and I cannot tell if the fact
the if condition evaluates to false on my system is related to the
upgrade failure or if is solely the result of a misconfiguration. That
is, perhaps it is my fault for not masking the smbd, nmbd, and winbind
units when I configured for AD DC.
If it helps, here are the locations of samba-ad-dc.service on the system
in question.
Prior to upgrade:
find / -name samba-ad-dc.service -exec ls -Fd {} \;
/run/systemd/generator.late/samba-ad-dc.service
/run/systemd/generator.late/runlevel5.target.wants/samba-ad-dc.service@
/run/systemd/generator.late/runlevel4.target.wants/samba-ad-dc.service@
/run/systemd/generator.late/runlevel3.target.wants/samba-ad-dc.service@
/run/systemd/generator.late/runlevel2.target.wants/samba-ad-dc.service@
/sys/fs/cgroup/systemd/system.slice/samba-ad-dc.service/
After upgrade:
find / -name samba-ad-dc.service -exec ls -Fd {} \;
/etc/systemd/system/multi-user.target.wants/samba-ad-dc.service@
/lib/systemd/system/samba-ad-dc.service
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/samba-ad-dc.service
/sys/fs/cgroup/devices/system.slice/samba-ad-dc.service/
/sys/fs/cgroup/pids/system.slice/samba-ad-dc.service/
/sys/fs/cgroup/systemd/system.slice/samba-ad-dc.service/
Let me know if I can provide any additional information or if I can help
with anything else.
--
Roberto C. Sánchez
Bug#863285: [winbind] Install/Updates Fail When Samba Running as samba 4 Domain
On Mon, Jul 31, 2017 at 09:51:25AM +0200, L.P.H. van Belle wrote: >Hai, this is know. > >Did you check and did you correct your smb.conf before you started >upgrading. >You posted a partial smb.conf, that did not help, can you post your >complete smb.conf ( anonimized if needed. ). > I know that I am not the original submitter, but I too have encountered the problem reported in this bug. >There are 2 known things when upgrade winbind. >1) A failty smb.conf, prevents/failes upgrading. > >The fix : correct the smb.conf and run dpkg --reconfigure -a > I have confirmed that my smb.conf is correct and not faulty and the upgrade still fails. >2) possible problem with nsswitch.conf >if you have winbind before compat, switch them and run dpkg --reconfigure >-a > I have compat first in nsswitch.conf on my systems. In my case, the solution was to mask the winbind and smbd units in systemd. I also masked nmbd to be safe, though the documentation indicates that nmbd does not run when Samba is configured as an AD DC. I will be upgrading all of my systems soon, but I am retaining a pre-upgrade snapshot of one of the VMs that runs as an AD DC. If I can help with resolving this, please let me know. Regards, -Roberto -- Roberto C. Sánchez
