Bug#1076582: initramfs-tools-core: mkinitramfs failure zstd -q -9 -T0 70 (No space left on device)
On Fri, 2024-07-19 at 16:13 +0200, Diederik de Haas wrote: > [ adding debian-release to the list for some troubling observations ] > > On Friday, 19 July 2024 15:54:57 CEST Vincent Lefevre wrote: > [...] > > Note that > > https://www.debian.org/releases/stable/amd64/apcs01.en.html > > does not recommend anything for the /boot partition. > > > > https://www.debian.org/releases/stable/amd64/apcs05.en.html says > > "25–50MB should suffice" (though this is probably not sufficient > > for most uses). > > > > https://linuxhint.com/boot-partition-size-debian/ says > > 256 MB / 512 MB for Debian 11. > > > > Mine has 512 MB (more that 10 times the recommended 25–50MB). > > Holy crap! Some quotes from the Stable documentation: > > "If you have a large IDE disk" > "This restriction doesn't apply if you have a BIOS newer than around > 1995–98" > Seeing the word "cylinder" all over the place ... > "CHS translation mode (“Large”)" = Cylinder/Head/Sector I presume? > > And then indeed "25–50MB should suffice" (for /boot/ partition). > > Maybe that document should be updated for this CENTURY? "That document" comes from src:installation-guide, which is maintained by the d-i team, not the Release Team. Regards, Adam
Bug#1071272: linux: building the bookworm-backports armhf kernel causes OOM on buildds
Source: linux Version: 6.7.12-1~bpo12+1 Severity: serious X-Debbugs-CC: debian-...@lists.debian.org X-Debbugs-CC: d...@debian.org Hi, armhf builds of the bookworm-backports kernel appear to have led to outages on several buildds recently. Each of arm-ubc-04, arm-ubc-05 and arm-ubc-06 (QEMU ganeti guests) stopped responding after starting to build the kernel, and had to be rebooted. The build logs stop are various points - two at different points during drivers/net, and one during the dpkg-deb runs at the end of the build. The one common factor appears to be that the system logs on each machine show the OOM killer being invoked during the build, initially killing syslog but subsequently schroot and many system processes. Each buildd has 12GB of RAM and 120GB of swap available. The issue also seems to be specific to the armhf build - arm-ubc-06 recently successfully built the armel build of the same kernel version. Please let us know if you need any further information. Regards, Adam
Bug#1031888: emacs-nox: bullseye-security update fails to install on mips64el
On Thu, 2024-05-16 at 17:01 +0100, Sean Whitton wrote: > control: reopen 1031888 > > Hello Adam, > > On Fri 21 Apr 2023 at 10:19am +01, Adam D. Barratt wrote: > [...] > > With my DSA hat on, I'm not aware of it having been confirmed to > > fix > > the issue on bullseye. I'm happy to test an updated package in the > > meantime. (FWIW the update isn't in p-u currently because of this > > issue.) > > I have prepared an update for bullseye incorporating upstream's fix > for the memory leak. > I would be grateful if you could test whether the mips64el > installation is still reproducible. > > As deb11u3 is already in p-u and tagged, I've versioned this deb11u4. > I've pushed it to the fix-1031888 branch of salsa:rlb/deb-emacs.git. > I've built a 27.1+1-3.1+deb11u4~1.gbp4104c1 package, and confirmed that it installs cleanly over +deb11u2 on mipsel-osuosl-01. I then checked the version numbers, and realised that +deb11u2 was the version that was previously failing. Checking back, all of the debian.org systems that were affected by the bug are either down or have already been upgraded to bookworm, so I'm afraid I no longer have a useful test environment for #1031888. Regards, Adam
Bug#1067016: nvidia-settings 470.239.06-1 flagged for acceptance
package release.debian.org tags 1067016 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: nvidia-settings Version: 470.239.06-1 Explanation: new upstrem bugfix release; build for ppc64el
Bug#1055348: jetty9: Update from DLA 3641 breaks puppetdb ("Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.ecl
On Sun, 2023-11-05 at 21:46 +0100, Markus Koschany wrote: > Am Sonntag, dem 05.11.2023 um 20:35 + schrieb Adam D. Barratt: > > [...] > > After a bit of searching, I happened across a discussion of a > > similar > > change in a different product that mentioned the > > SslContextFactory$Server syntax, so gave that a try. The resulting > > package is now installed on handel.d.o and seems to work - at > > least, > > it's been running for 45 minutes now (whereas the broken versions > > lasted less than 5 minutes) and at least one client has > > successfully > > made a "puppet agent" run in the meantime. > > > > I've attached a debdiff of the package we're now running, with the > > revised patch. > > Great, thanks for the update. I feared the Java dot syntax couldn't > be applied one-to-one to Clojure. I suggest we wait another 24h to > confirm it works and if you don't see another regression then I'll > release a new update tomorrow. > Everything still seems to be working OK. For completeness: adsb@handel:~$ dpkg -l | grep jetty ii libjetty9-extra-java 9.4.50-4+deb10u1 all Java servlet engine and webserver -- extra libraries ii libjetty9-java9.4.50-4+deb10u1 all Java servlet engine and webserver -- core libraries ii libtrapperkeeper-webserver-jetty9-clojure 1.7.0-2+deb10u1+dsa1 all trapperkeeper webserver service Regards, Adam
Bug#1055348: jetty9: Update from DLA 3641 breaks puppetdb ("Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.ecl
On Sun, 2023-11-05 at 19:18 +0100, Markus Koschany wrote: > Am Sonntag, dem 05.11.2023 um 16:33 + schrieb Adam D. Barratt: > > [...] > > Do you have an idea how simple rebuilding the bullseye package on > > buster would be? I'm happy to try that in general, but I've not > > really > > looked at the Java ecosystem in Debian much. > > Sorry, I missed those new or updated dependencies. That complicates > the matter a little. We also have to deal with clojure here, a LISP > dialect of the Java language with a different build system > (leiningen), but if all dependencies were in place a rebuild would be > pretty simple. As a last resort I could bundle all those dependencies > together with trapperkeeper-* the Java way TM but I hope we can avoid > that. > > The most ideal solution is a patch for the current version in Buster. > I have uploaded a new revision to people.debian.org with minimal > changes here: > > https://people.debian.org/~apo/lts/buster/trapperkeeper-webserver-jetty9-clojure/ > > dget -x > https://people.debian.org/~apo/lts/buster/trapperkeeper-webserver-jetty9-clojure/trapperkeeper-webserver-jetty9-clojure_1.7.0-2+deb10u1.1.dsc > > > should work as expected. I'm attaching the debdiff as well. > > My solution is to replace the old SslContextFactory class with the > new inner SslContextFactory.Server class but I don't know if this > change has the desired effect because I couldn't test it. Thanks for the patch. Unfortunately it didn't work as-is: Nov 5 18:39:14 handel/handel java[2393]: Exception in thread "main" java.lang.AssertionError: Assert failed: (keyword? kw) Nov 5 18:39:14 handel/handel java[2393]: at puppetlabs.kitchensink.core$without_ns.invokeStatic(core.clj:613) Nov 5 18:39:14 handel/handel java[2393]: at puppetlabs.kitchensink.core$without_ns.invoke(core.clj:613) Nov 5 18:39:14 handel/handel java[2393]: at puppetlabs.trapperkeeper.core$main.invokeStatic(core.clj:175) Nov 5 18:39:14 handel/handel java[2393]: at puppetlabs.trapperkeeper.core$main.doInvoke(core.clj:159) Nov 5 18:39:14 handel/handel java[2393]: at clojure.lang.RestFn.applyTo(RestFn.java:137) Nov 5 18:39:14 handel/handel java[2393]: at clojure.core$apply.invokeStatic(core.clj:665) Nov 5 18:39:14 handel/handel java[2393]: at clojure.core$apply.invoke(core.clj:660) Nov 5 18:39:14 handel/handel java[2393]: at puppetlabs.puppetdb.cli.services$provide_services.invokeStatic(services.clj:570) Nov 5 18:39:14 handel/handel java[2393]: at puppetlabs.puppetdb.cli.services$provide_services.invoke(services.clj:558) Nov 5 18:39:14 handel/handel java[2393]: at puppetlabs.puppetdb.cli.services$cli$fn__41585.invoke(services.clj:578) ... After a bit of searching, I happened across a discussion of a similar change in a different product that mentioned the SslContextFactory$Server syntax, so gave that a try. The resulting package is now installed on handel.d.o and seems to work - at least, it's been running for 45 minutes now (whereas the broken versions lasted less than 5 minutes) and at least one client has successfully made a "puppet agent" run in the meantime. I've attached a debdiff of the package we're now running, with the revised patch. Regards, Adam diff -Nru trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/changelog trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/changelog --- trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/changelog 2019-09-13 10:00:50.0 +0100 +++ trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/changelog 2023-11-05 19:28:22.0 + @@ -1,3 +1,11 @@ +trapperkeeper-webserver-jetty9-clojure (1.7.0-2+deb10u1+dsa1) buster; urgency=medium + + * Non-maintainer upload. + * Replace deprecated class SslContextFactory with SslContextFactory.Server. +Largely based on a patch by Markus Koschany. (Hopefully Closes:#1055348) + + -- Adam D. Barratt Sun, 05 Nov 2023 19:28:22 + + trapperkeeper-webserver-jetty9-clojure (1.7.0-2+deb10u1) buster; urgency=medium [ Manfred Stock ] diff -Nru trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/series trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/series --- trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/series 2019-09-13 09:54:48.0 +0100 +++ trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/series 2023-11-05 19:28:22.0 + @@ -3,3 +3,4 @@ 0003-TK-369-Add-LifeCycleImplementingRequestLogImpl.patch 0004-Implement-LifeCycle-methods-missing-from-RequestLogI.patch 0005-maint-Disable-EndpointIdentification.patch +SslContextFactory.Server.patch diff -Nru trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/SslContextFactory.Server.patch trapperkeeper-webserver-jetty9-clojure-1.7.0/debian/patches/SslContex
Bug#1055348: jetty9: Update from DLA 3641 breaks puppetdb ("Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.ecl
On Sat, 2023-11-04 at 20:33 +0100, Markus Koschany wrote: > Could you install the version of trapperkeeper-webserver-jetty9- > clojure from Bullseye and reinstall the jetty9 security update and > report back if this solves your problem? Doing that directly doesn't "just work": libtrapperkeeper-webserver-jetty9-clojure : Depends: libkitchensink-clojure (>= 3.1.1-2) but 2.3.0-2 is to be installed Depends: libprismatic-schema-clojure (>= 1.1.12) but 1.1.6-1 is to be installed Depends: libpuppetlabs-i18n-clojure (>= 0.9.0-2) but 0.8.0-1 is to be installed Depends: libring-codec-clojure (>= 1.1.2) but 1.0.1-1 is to be installed Depends: libssl-utils-clojure (>= 3.1.0) but 0.8.3-2 is to be installed Depends: libtrapperkeeper-clojure (>= 3.1.0) but 1.5.2-2 is to be installed Depends: libtrapperkeeper-filesystem-watcher-clojure (>= 1.2.2-2) but it is not installable Depends: libordered-clojure but it is not installable Adding a bullseye APT source ends up at "19 upgraded, 5 newly installed". Do you have an idea how simple rebuilding the bullseye package on buster would be? I'm happy to try that in general, but I've not really looked at the Java ecosystem in Debian much. Regards, Adam
Bug#1055348: jetty9: Update from DLA 3641 breaks puppetdb ("Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.ecl
Source: jetty9 Version: 9.4.50-4+deb10u1 Severity: serious X-Debbugs-Cc: d...@debian.org Hi, Upgrading libjetty9-java and libjetty9-extra-java to the version from DLA 3641-1 reliably causes PuppetDB to fail to start, with the stacktrace shown below. Downgrading resolves the issue. I'm not sure which keystore is being referred to, but none of the files listed in /etc/puppetdb/conf.d/jetty.ini appear to contain more than a single certificate. Regards, Adam -- Logs begin at Sat 2023-11-04 14:52:45 UTC, end at Sat 2023-11-04 16:16:11 UTC. -- Nov 04 14:52:50 handel systemd[1]: Started Puppet data warehouse server. Nov 04 14:53:22 handel java[1669]: WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: puppetlabs.trapperkeeper.internal, being replaced by: #'puppetlabs.kitchensink.core/boolean? Nov 04 14:53:32 handel java[1669]: 14:53:32.886 [main] DEBUG puppetlabs.puppetdb.http - The v1 API has been retired; please use v4 Caught HTTP processing exception Nov 04 14:53:32 handel java[1669]: 14:53:32.898 [main] DEBUG puppetlabs.puppetdb.http - The v2 API has been retired; please use v4 Caught HTTP processing exception Nov 04 14:53:32 handel java[1669]: 14:53:32.899 [main] DEBUG puppetlabs.puppetdb.http - The v3 API has been retired; please use v4 Caught HTTP processing exception Nov 04 14:53:34 handel java[1669]: 14:53:34.073 [main] DEBUG puppetlabs.trapperkeeper.bootstrap - Loading bootstrap config from classpath: 'jar:file:/usr/share/puppetdb/puppetdb.jar!/bootstrap.cfg' Nov 04 14:53:39 handel java[1669]: Exception in thread "main" java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.eclipse.jetty.util.ssl.SslContextFactory Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1289) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1271) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:373) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:244) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:97) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:323) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:234) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.server.Server.doStart(Server.java:401) Nov 04 14:53:39 handel java[1669]: at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) Nov 04 14:53:39 handel java[1669]: at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Nov 04 14:53:39 handel java[1669]: at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) Nov 04 14:53:39 handel java[1669]: at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Nov 04 14:53:39 handel java[1669]: at java.base/java.lang.reflect.Method.invoke(Method.java:566) Nov 04 14:53:39 handel java[1669]: at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:167) Nov 04 14:53:39 handel java[1669]: at clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:438) Nov 04 14:53:39 handel java[1669]: at puppetlabs.trapperkeeper.services.webserver.jetty9_core$eval43528$start_webserver_BANG___43533$fn__43534$fn__43535.invoke(jetty9_core.clj:685) Nov 04 14:53:39 handel java[1669]: at puppetlabs.trapperkeeper.services.webser
Bug#1052129: acpica-unix: Failed to migrate to Testing; missing s390x build not properly handled
On Sun, 2023-09-17 at 14:58 -0400, Boyuan Yang wrote: > If you are clear that upstream is completely not supporting big- > endian build anymore, please > submit a package removal request to Debian Release Team (using > reportbug tool) to remove > the current s390x package in Debian Testing. No. Architecture-specific removals happen in unstable, so the request needs to be made to the FTP Team. Regards, Adam
Bug#1039743: christianriesen-base32: FTBFS with phpunit 10: make[1]: *** [debian/rules:19: override_dh_auto_test] Error 2
On Wed, 2023-06-28 at 17:57 -0300, Athos Ribeiro wrote: > Source: christianriesen-base32 > Version: 1.6.0-3 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: pkg-php-p...@lists.alioth.debian.org > Usertags: phpunit > > Hi, > > We will start the phpunit 10 transition in unstable soon. During a > test > rebuild, christianriesen-base32 was found to FTBFS. I've picked up an arbitrary bug from the set to reply to here. Transitions should be co-ordinated with the Release Team, and I can't see a tracking bug or discussion for this one (or the related symfony transition). Have I simply missed it? FTBFS bugs relating to transitions should be filed at severities below RC until the transition has actually started. I'm not one of the team members who regularly handles transitions any more, but looking at the list of bugs you have filed so far tonight, any transition that introduces over 100 build failures in other packages is in no sense ready to happen "soon". Regards, Adam
Bug#1031888: emacs-nox: bullseye-security update fails to install on mips64el
On Fri, 2023-04-21 at 12:08 +0300, Adrian Bunk wrote: > On Tue, Mar 14, 2023 at 02:04:19PM -0700, Sean Whitton wrote: > > Version: 1:28.2+1-11 > > > > Hello, > > > > On Sun 26 Feb 2023 at 09:41PM +02, Adrian Bunk wrote: > > > > > While I suspect they are the same, there is no proof that this > > > leak is > > > actually the same as the mips64el installation issue. > > > > Looks like it was. > > If this was confirmed, could the fix go into the next point release, > which would require a -pu request+upload today (or early tomorrow)? > With my DSA hat on, I'm not aware of it having been confirmed to fix the issue on bullseye. I'm happy to test an updated package in the meantime. (FWIW the update isn't in p-u currently because of this issue.) Regards, Adam
Bug#1031888: emacs-nox: bullseye-security update fails to install on mips64el
Source: emacs Version: 1:27.1+1-3.1+deb11u2 Severity: grave Control: affects -1 + security.debian.org Control: affects -1 + release.debian.org X-Debbugs-Cc: t...@security.debian.org X-Debbugs-Cc: debian-ad...@lists.debian.org Hi, Upgrading emacs-nox on a bullseye mips64el system to the latest security update fails: Setting up emacs-nox (1:27.1+1-3.1+deb11u2) ... update-alternatives: using /usr/bin/emacs-nox to provide /usr/bin/emacs (emacs) in auto mode Install emacsen-common for emacs emacsen-common: Handling install of emacsen flavor emacs emacs: could not load dump file "/usr/lib/emacs/27.1/mips64el-linux-gnuabi64/emacs.pdmp": out of memory ERROR: install script from emacsen-common package failed dpkg: error processing package emacs-nox (--configure): installed emacs-nox package post-installation script subprocess returned error exit status 1 Downgrading to +deb11u1 on the same system works fine. Removing the emacs packages and installing +deb11u2 directly fails in the same way. This is reproducible on four debian.org buildds. Regards, Adam
Bug#1030160: chromium: FTBFS on arm64/armhf in bullseye-security (V4L issues)
Source: chromium Version: 109.0.5414.119-1~deb11u1 Severity: serious Tags: FTBFS X-Debbugs-CC: t...@security.debian.org Control: affects -1 + security.debian.org Control: affects -1 + release.debian.org Hi, The most recent chromium upload to bullseye-security fails to build on arm64 and armhf due to issues with Video4Linux. Relevant-looking log output is included below. Regards, Adam FAILED: obj/media/gpu/v4l2/v4l2/v4l2_video_decoder_delegate_vp8.o clang++-13 -MMD -MF obj/media/gpu/v4l2/v4l2/v4l2_video_decoder_delegate_vp8.o.d -DMEDIA_GPU_IMPLEMENTATION -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -D__STDC_CONSTANT_MACROS -D__STDC_FO RMAT_MACROS -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D_GNU_SOURCE -DCR_CLANG_REVISION=\"llvmorg-16-init-8697-g60809cd2-1\" -DNDEBUG -DNVALGRIND -DD YNAMIC_ANNOTATIONS_ENABLED=0 -DGL_GLEXT_PROTOTYPES -DUSE_GLX -DUSE_EGL -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40 -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DVK_USE_PLATFORM_XCB_KHR -DVK_USE_PLATFORM_WAYLA ND_KHR -DSK_CODEC_DECODES_PNG -DSK_CODEC_DECODES_WEBP -DSK_ENCODE_PNG -DSK_ENCODE_WEBP -DSK_ENABLE_SKSL -DSK_UNTIL_CRBUG_1187654_IS_FIXED -DSK_USER_CONFIG_HEADER=\"../../skia/config/SkUserConfig.h\" -DSK_WIN_FON TMGR_NO_SIMULATIONS -DSK_GL -DSK_CODEC_DECODES_JPEG -DSK_ENCODE_JPEG -DSK_HAS_WUFFS_LIBRARY -DSK_VULKAN=1 -DSK_SUPPORT_GPU=1 -DSK_GPU_WORKAROUNDS_HEADER=\"gpu/config/gpu_driver_bug_workaround_autogen.h\" -DVK_US E_PLATFORM_XCB_KHR -DVK_USE_PLATFORM_WAYLAND_KHR -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DUSE_CHROMIUM_ICU=1 -DU_ENABLE_TRACING=1 -DU_ENABLE_RESOURCE_TRACING=0 -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IM PL=ICU_UTIL_DATA_FILE -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DGOOGLE_PROTOBUF_INTERNAL_DONATE_STEAL_INLINE=0 -DHAVE_PTHREAD -DLEVELDB_PLATFORM_CHROMIUM=1 -DLEVELDB_PLATFORM_CHROMIUM=1 -DLIBGAV1_MAX_BITDEPTH=10 -DLIBGAV1_THREADPOOL_USE_STD_MUTEX -DLIBGAV1_ENABLE_LOGGING=0 -DLIBGAV1_PUBLIC= -DVK_NO_PROTOTYPES -DUSE_VULKAN_XCB -I../.. -Igen -I../../third_party/libyuv/include -I../../third_party /perfetto/include -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -Igen/shim_headers/zlib_shim -Igen/shim_headers/jsoncpp_shim -Igen/shim_headers/double_conversion_shim -Igen/shim_headers/libe vent_shim -Igen/shim_headers/libpng_shim -Igen/shim_headers/libwebp_shim -Igen/shim_headers/brotli_shim -Igen/shim_headers/libXNVCtrl_shim -I../../third_party/khronos -I../../gpu -I../../third_party/vulkan-deps/ vulkan-headers/src/include -I../../third_party/wayland/src/src -I../../third_party/wayland/include/src -Igen/third_party/dawn/include -I../../third_party/dawn/include -Igen/shim_headers/re2_shim -Igen/shim_heade rs/opus_shim -Igen/shim_headers/snappy_shim -I../../third_party/abseil-cpp -I../../third_party/boringssl/src/include -I../../third_party/protobuf/src -Igen/protoc_out -Igen/third_party/perfetto -I../../third_par ty/mesa_headers -I../../third_party/skia -I../../third_party/wuffs/src/release/c -I../../third_party/vulkan/include -I../../third_party/vulkan-deps/vulkan-headers/src/include -I../../third_party/wayland/src/src -I../../third_party/wayland/include/src -I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -I../../third_party/ced/src -I../../third_party/libwebm/source -I../../third_party/protobuf/src - I../../third_party/leveldatabase -I../../third_party/leveldatabase/src -I../../third_party/leveldatabase/src/include -I../../third_party/libaom/source/libaom -I../../third_party/libgav1/src -I../../third_party/l ibgav1/src/src -I../../third_party/wayland/include -I../../third_party/wayland/include/src -I../../third_party/wayland/src/cursor -I../../third_party/wayland/src/egl -I../../third_party/wayland/src/src -Igen/thi rd_party/wayland/src/protocol -Wall -Wextra -Wimplicit-fallthrough -Wextra-semi -Wunreachable-code-aggressive -Wthread-safety -Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi -Wloop-analysis -Wno -unneeded-internal-declaration -Wenum-compare-conditional -Wno-ignored-pragma-optimize -Wno-bitfield-constant-conversion -Wshadow -fno-delete-null-pointer-checks -fno-ident -fno-strict-aliasing --param=ssp-buffe r-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -fcrash-diagnostics-dir=../../tools/clang/crashreports -mllvm -instcombine-l ower-dbg-declare=0 -ffp-contract=off -mbranch-protection=standard --target=aarch64-linux-gnu -ffile-compilation-dir=. -no-canonical-prefixes -ftrivial-auto-var-init=pattern -fdata-sections -ffunction-sections -f no-unique-section-names -fno-omit-frame-pointer -g0 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include - DPROTOBUF_ALLOW_DEPRECATED=1 -std=
Bug#1029215: debian-archive-keyring: bookworm SRM key
Source: debian-archive-keyring Version: 2021.1.1 Severity: serious X-Debbugs-Cc: debian-rele...@lists.debian.org Hi, We need an SRM key for bookworm, so that we can include it in the release. Regards, Adam
Bug#1029214: debian-archive-keyring: bookworm archive signing keys
Source: debian-archive-keyring Version: 2021.1.1 Severity: serious X-Debbugs-Cc: ftpmas...@debian.org, debian-rele...@lists.debian.org Hi, We need new archive signing keys for bookworm, so that we can include them in the release. Regards, Adam
Bug#1027925: spamassassin FTBFS on IPV6-only buildds
On Wed, 2023-01-04 at 18:31 +, Adam D. Barratt wrote: > One difference at least is that "IPv6-only" buildds *do* have IPv4 > networking, but only on lo. As a result, your have_inet4 test will > return true: > > adsb@x86-conova-01:~$ ip --brief -4 a > lo UNKNOWN127.0.0.1/8 > > adsb@x86-conova-01:~$ perl -MIO::Socket::INET -e '$sock = > IO::Socket::INET->new(LocalAddr => "127.0.0.1", Proto => "udp");' -e > 'print $sock ? "true\n" : "false\n";' > true > > https://lists.debian.org/debian-devel/2020/07/msg00070.html is a > discussion of the general issue from a couple of years ago, which > actually includes spamassassin in its list of affected packages. Looking at the source, I think the issue is that spamd is calling ip_or_name_to_ip_addresses() on the IP address, which in turn is passing AI_ADDRCONFIG to getaddrinfo(), which will fail on a system configured in such a way, as it does not consider loopback addresses. https://salsa.debian.org/perl-team/interpreter/perl/-/commit/425d71c741280e5c7d61b8895993e39b0c6c7ca4 is how a similar issue there was solved, if it's useful. Regards, Adam
Bug#1027925: spamassassin FTBFS on IPV6-only buildds
On Wed, 2023-01-04 at 10:01 -0800, Noah Meyerhans wrote: > On Wed, Jan 04, 2023 at 06:58:30PM +0200, Adrian Bunk wrote: > > https://buildd.debian.org/status/logs.php?pkg=spamassassin&arch=amd64 > > > > ... > > Jan 4 03:57:23.254 [3488924] dbg: logger: adding facilities: all > > Jan 4 03:57:23.255 [3488924] dbg: logger: logging level is DBG > > Jan 4 03:57:23.257 [3488924] dbg: logger: successfully opened file > > log/sa_check_spamd.g3uk5R/d.sa_check_spamd/spamd.err.0.timestamped > > Jan 4 03:57:23.257 [3488924] dbg: logger: successfully added file > > method > > Jan 4 03:57:23.257 [3488924] dbg: spamd: will perform setuids? 0 > > Jan 4 03:57:23.257 [3488924] dbg: spamd: socket module of choice: > > IO::Socket::IP 0.41, Socket 2.033, have PF_INET, have PF_INET6, > > using legacy Socket6::getaddrinfo, AI_ADDRCONFIG is supported > > Jan 4 03:57:23.257 [3488924] dbg: spamd: socket specification: > > "127.0.0.1", IP address: 127.0.0.1, port: 61558 > > server socket setup failed, retry 1: spamd: invalid address for a > > listen socket: "127.0.0.1": Address family for hostname not > > supported > > [...] > I haven't been able to reproduce this on VMs with IPv6-only > networking. > Is the buildd network environment documented anywhere? There's > clearly > something different about it than my test environment, but I haven't > been able to figure out what it is. > > In the meantime, I'm looking into printing more information about the > Network configuration when running these failing tests. See > https://salsa.debian.org/debian/spamassassin/-/commit/531bf8ea45cde94a60852d62ac701f70c0db4b3d > > On my IPv6-only build host, these changes print: > IP-DEBUG: have_inet4 returning false > IP-DEBUG: have_inet6 returning true > IP-DEBUG: Set spamdlocalhost to ::1 > IP-DEBUG: Set spamdhost to ::1 > > > noahm@localhost:~/spamassassin$ ip -4 addr ; ip -4 ro ; dpkg- > buildpackage -uc -us > /tmp/build.log 2>&1 > One difference at least is that "IPv6-only" buildds *do* have IPv4 networking, but only on lo. As a result, your have_inet4 test will return true: adsb@x86-conova-01:~$ ip --brief -4 a lo UNKNOWN127.0.0.1/8 adsb@x86-conova-01:~$ perl -MIO::Socket::INET -e '$sock = IO::Socket::INET->new(LocalAddr => "127.0.0.1", Proto => "udp");' -e 'print $sock ? "true\n" : "false\n";' true https://lists.debian.org/debian-devel/2020/07/msg00070.html is a discussion of the general issue from a couple of years ago, which actually includes spamassassin in its list of affected packages. Regards, Adam
Bug#1024400: net-luminis-build-plugin: broken maintainer field
Source: net-luminis-build-plugin Version: 0.2.0-4 Severity: serious X-Debbugs-Cc: ta...@debian.org Hi, The upload of net-luminis-build-plugin which orphaned it appears to have generated a broken Maintainer field: Package: net-luminis-build-plugin Binary: libnet-luminis-build-plugin-java Version: 0.2.0-4 Maintainer: Debian QA Group Mathieu Malaterre I'm assuming the second line is a failed attempt at removing the Uploaders field, as mentioned in the changelog, which originally read: Uploaders: Mathieu Malaterre Amongst other things, this breaks the scripts in the BTS which generate lists of RC bugs in unstable and testing for britney, meaning that those lists have not been updated since Monday morning. Regards, Adam
Bug#1023811: golang-github-grpc-ecosystem-go-grpc-middleware_1.3.0-1 sources changed in the archive?
On Thu, 2022-11-10 at 15:53 +0200, Adrian Bunk wrote: > Get:1 https://deb.debian.org/debian experimental/main golang-github- > grpc-ecosystem-go-grpc-middleware 1.3.0-1 (dsc) [2857 B] > Err:1 https://deb.debian.org/debian experimental/main golang-github- > grpc-ecosystem-go-grpc-middleware 1.3.0-1 (dsc) > Hash Sum mismatch > Hashes of expected file: >- > SHA256:8e86e0a9cc31461c0f564e8feefb2e1e9ec05c265ab06e96fd32b7de787bc5 > 04 >- Filesize:2857 [weak] >- MD5Sum:c4d33ab09e4f4a95c819dd1de88d0876 [weak] > Hashes of received file: >- > SHA256:8bbee530bbdb11a58a275c34878c372558223c294384897822eba1338b84db > 82 >- MD5Sum:8d6eee1b2b773c9be12536396ba949a6 [weak] >- Filesize:2857 [weak] > Last modification reported: Wed, 26 Oct 2022 14:32:16 + > Get:2 https://deb.debian.org/debian experimental/main golang-github- > grpc-ecosystem-go-grpc-middleware 1.3.0-1 (tar) [104 kB] > Get:3 https://deb.debian.org/debian experimental/main golang-github- > grpc-ecosystem-go-grpc-middleware 1.3.0-1 (diff) [2652 B] > E: Failed to fetch > https://deb.debian.org/debian/pool/main/g/golang-github-grpc-ecosystem-go-grpc-middleware/golang-github-grpc-ecosystem-go-grpc-middleware_1.3.0-1.dsc > Hash Sum mismatch >Hashes of expected file: > - > SHA256:8e86e0a9cc31461c0f564e8feefb2e1e9ec05c265ab06e96fd32b7de787bc5 > 04 > - Filesize:2857 [weak] >Fetched 109 kB in 0s (416 kB/s) > - MD5Sum:c4d33ab09e4f4a95c819dd1de88d0876 [weak] >Hashes of received file: > - > SHA256:8bbee530bbdb11a58a275c34878c372558223c294384897822eba1338b84db > 82 > - MD5Sum:8d6eee1b2b773c9be12536396ba949a6 [weak] > - Filesize:2857 [weak] >Last modification reported: Wed, 26 Oct 2022 14:32:16 + > E: Failed to fetch some archives. > E: apt-get for sources failed > ... > > > I can reproduce the problem locally with > $ apt-get source golang-github-grpc-ecosystem-go-grpc- > middleware/experimental > > This is not supposed to happen, and I haven't seen this before. So far as I can tell, the timeline is: - 2022-10-26 package is uploaded - 2022-10-31 package is removed as obsolete - 2022-11-03 the same package is re-uploaded, with a different GPG signature The file in the archive matches the "expected" hashes, whereas deb.d.o is returning the original file. Regards, Adam
Bug#1023424: Re; Bug#1023424: Vulnerabilities CVE-2022-1292, CVE-2022-2068, CVE-2022-2097
Control: severity -1 important Control: tags -1 - bullseye On Thu, 2022-11-03 at 20:35 +, nospam099-git...@yahoo.com wrote: > The component OpenSSL1.1.1n-0+deb11u3 suffers from 3 vulnerabilities: > * (CVE-2022-1292)[https://nvd.nist.gov/vuln/detail/CVE-2022-1292] > (critical) > * (CVE-2022-2068)[https://nvd.nist.gov/vuln/detail/CVE-2022-2068] > (critical) No. Both of the above are already resolved in 1.1.1n-0+deb11u3, as indicated by https://security-tracker.debian.org/tracker/CVE-2022-1292 and https://security-tracker.debian.org/tracker/CVE-2022-2068 (indeed, the former was fixed in 1.1.1n-0+deb11u2). > * (CVE-2022-2097)[https://nvd.nist.gov/vuln/detail/CVE-2022-2097] > (medium) > and https://security-tracker.debian.org/tracker/CVE-2022-2097 has this tagged as waiting for additional updates to fix it alongside. Regards, Adam
Bug#1014556: firefox-esr: FTBFS on mipsel ("terminate called after throwing an instance of 'std::bad_alloc'")
Source: firefox-esr Version: 91.0esr-1 Severity: serious Tags: ftbfs Control: found -1 91.9.0esr-1~deb11u1 Hi, firefox-esr fails to build on mipsel for some time now. The exact module generating the issue seems to vary, but the general pattern is always: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc warning: `style` (lib) generated 5 warnings error: could not compile `style`; 5 warnings emitted Caused by: process didn't exit successfully: `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=style CARGO_MANIFEST_DIR=/<>/servo/components/style CARGO_PKG_AUTHORS='The Servo Project Developers' CARGO_PKG_DESCRIPTION='' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE=MPL-2.0 CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=style CARGO_PKG_REPOSITORY='' CARGO_PKG_VERSION=0.0.1 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=0 CARGO_PKG_VERSION_PATCH=1 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/<>/build-browser/release/deps:/usr/lib' OUT_DIR=/<>/build-browser/mipsel-unknown-linux-gnu/release/build/style-5f575a1017a414d0/out /usr/bin/rustc --crate-name style --edition=2018 servo/components/style/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C panic=abort -C embed-bitcode=no --cfg 'feature="bindgen"' --cfg 'feature="gecko"' --cfg 'feature="nsstring"' --cfg 'feature="regex"' --cfg 'feature="serde"' --cfg 'feature="toml"' -C metadata=d1d3345ab1bffe89 -C extra-filename=-d1d3345ab1bffe89 --out-dir /<>/build-browser/mipsel-unknown-linux-gnu/release/deps --target mipsel-unknown-linux-gnu -C linker=/<>/build/cargo-linker -C incremental=/<>/build-browser/mipsel-unknown-linux-gnu/release/incremental -L dependency=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps -L dependency=/<>/build-browser/release/deps --extern app_units=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libapp_units-8a0e6019c7a17637.rmeta --extern arrayvec=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libarrayvec-0a2f26e757c8e7a2.rmeta --extern atomic_refcell=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libatomic_refcell-369d4ff936f52a0a.rmeta --extern bitflags=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libbitflags-b8ab48b7c522be2f.rmeta --extern byteorder=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libbyteorder-8434aa3db92bc1c0.rmeta --extern cssparser=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libcssparser-6484261978955fc0.rmeta --extern derive_more=/<>/build-browser/release/deps/libderive_more-68d3c527ad52aaa5.so --extern euclid=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libeuclid-5fcab4507c0d0d71.rmeta --extern fallible=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libfallible-ee6cefe1070eb0e8.rmeta --extern fxhash=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libfxhash-8b19836252d9bcb5.rmeta --extern gecko_profiler=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libgecko_profiler-42c1e6a9175860bb.rmeta --extern hashbrown=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libhashbrown-801993171a89048f.rmeta --extern hashglobe=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libhashglobe-b92334fa65865d23.rmeta --extern indexmap=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libindexmap-908c705f0c9634f8.rmeta --extern itertools=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libitertools-601a41e4453f7bf2.rmeta --extern itoa=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libitoa-e4beb6a015027174.rmeta --extern lazy_static=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/liblazy_static-b8d8428139d524da.rmeta --extern log=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/liblog-797f4b0c738c4a87.rmeta --extern malloc_size_of=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libmalloc_size_of-87a183261927da3f.rmeta --extern malloc_size_of_derive=/<>/build-browser/release/deps/libmalloc_size_of_derive-f62a0b0dc189f161.so --extern matches=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libmatches-d81962fbd4808e6b.rmeta --extern debug_unreachable=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libdebug_unreachable-38dc1136f592db07.rmeta --extern nsstring=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libnsstring-69f2403b7cca97f1.rmeta --extern num_derive=/<>/build-browser/release/deps/libnum_derive-49756c415f0ea547.so --extern num_integer=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libnum_integer-466557df871188d5.rmeta --extern num_traits=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libnum_traits-502ada73ba790820.rmeta --extern num_cpus=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libnum_cpus-227a5e388b905860.rmeta --extern owning_ref=/<>/build-browser/mipsel-unknown-linux-gnu/release/deps/libowning_ref-37690676c28f58b9.rmeta --extern parking_lot=/<>/b
Bug#988086: Exim delivery process crashes on each mail with NULL-pointer
On Wed, 2021-05-05 at 11:07 +, halfdog wrote: > This is weird: I have only bullseye/bullseye-updates/bullseye- > security > in my sources list. I applied all updates on 2nd of May with > no Exim package available. Then after the 21nails disclosure > I run the updates (timestamps in UTC): > > 2021-05-02 07:05:31 status installed initramfs-tools:all 0.140 > ... > 2021-05-04 16:49:48 upgrade exim4-daemon-light:amd64 4.94-17 4.94-19 > > But there is no transaction for 4.94-19 in PTS between these > two dates, next is > > [2021-05-05] exim4 4.94-19 MIGRATED to testing (Debian testing > watch) The "testing watch" script only runs daily, in the early morning UTC. The 4.94-19 package actually migrated on the morning of the 4th (again UTC): 20210504101451|control-suite|dak|added|testing|exim4 4.94-19 source The upload including the 21nails fixes is: 20210504134823|process-upload|dak|ACCEPT|exim4_4.94.2-1_multi.changes Regards, Adam
Bug#977910: debian-archive-keyring: bullseye SRM key
On Tue, 2020-12-22 at 18:40 +, Adam D. Barratt wrote: > We need an SRM key for bullseye, so that we can include it in the > release. > I've generated the key, just seeing if JMW wants to add a sig. Regards, Adam
Bug#982122: redis: experimental package OOMs s390x buildds
Hi Chris, On Mon, 2021-02-15 at 18:28 +, Chris Lamb wrote: > Ah, indeed, the failure mode means that the log never made it to > > buildd.d.o. > > Curious, not heard of that failure mode — is there someplace I can > learn about that? No worries if not. I'm not sure if it's documented, but in this case I think enough of the system was unresponsive or killed to make the connection back to buildd.d.o fail. > > I've attached a copy of the log from zani. > > Ah, thanks. Unfortunately, it does not point us straight to the > solution. I note that you titled this bug "package OOMs" — I point > this out because the "OOM" text the log is actually the name of the > test. As in, here is tests/integration/corrupt-dump.tcl: > [...] > Do we have confirmation somewhere that the build is actually OOMing, > rather than it just timing out on a test that was designed to test > *for* an OOM condition. This OOM-related bug *should* be fixed by > virtue of them adding the test to begin with (!) but if we can show > that it is still OOMing, I suspect that upstream will be able to > address it quickly. I don't know how much context would be needed, but the machine definitely OOMed: Feb 3 20:45:22 zani/zani kernel: redis-server invoked oom-killer: gfp_mask=0x6000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=0 Feb 3 20:45:22 zani/zani kernel: redis-server cpuset=/ mems_allowed=0 Feb 3 20:45:22 zani/zani kernel: CPU: 0 PID: 45952 Comm: redis-server Not tainted 4.19.0-14-s390x #1 Debian 4.19.171-2 Feb 3 20:45:22 zani/zani kernel: Hardware name: IBM 8561 LT1 400 (z/VM 7.1.0) Feb 3 20:45:22 zani/zani kernel: Call Trace: Feb 3 20:45:22 zani/zani kernel: ([<00113f2a>] show_stack+0x5a/0x78) Feb 3 20:45:22 zani/zani kernel: [<00802d1a>] dump_stack+0x8a/0xb8 Feb 3 20:45:22 zani/zani kernel: [<00800962>] dump_header+0x82/0x2c0 Feb 3 20:45:22 zani/zani kernel: [<002b46fe>] oom_kill_process+0xde/0x380 Feb 3 20:45:22 zani/zani kernel: [<002b550c>] out_of_memory+0x24c/0x3b8 Feb 3 21:07:50 zani/zani kernel: [<002bd032>] __alloc_pages_nodemask+0x10b2/0x1160 Feb 3 21:07:50 zani/zani kernel: [<0012b0c6>] page_table_alloc+0x15e/0x2c8 Feb 3 21:07:50 zani/zani kernel: [<002f8b76>] __pte_alloc+0x2e/0xf8 Feb 3 21:07:50 zani/zani kernel: [<002ff258>] __handle_mm_fault+0xfc0/0x11c0 Feb 3 21:07:50 zani/zani kernel: [<002ff584>] handle_mm_fault+0x12c/0x298 Feb 3 21:07:50 zani/zani kernel: [<00123a12>] do_dat_exception+0x182/0x440 Feb 3 21:07:50 zani/zani kernel: [<0080d9d4>] pgm_check_handler+0x190/0x1e4 ... Feb 3 21:07:50 zani/zani kernel: sshd invoked oom-killer: gfp_mask=0x7080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), nodemask=(null), order=2, oom_score_adj=-1000 Feb 3 21:07:50 zani/zani kernel: sshd cpuset=/ mems_allowed=0 Feb 3 21:07:50 zani/zani kernel: CPU: 0 PID: 1463 Comm: sshd Not tainted 4.19.0-14-s390x #1 Debian 4.19.171-2 Feb 3 21:07:50 zani/zani kernel: Hardware name: IBM 8561 LT1 400 (z/VM 7.1.0) Feb 3 21:07:50 zani/zani kernel: Call Trace: Feb 3 21:07:50 zani/zani kernel: ([<00113f2a>] show_stack+0x5a/0x78) Feb 3 21:07:50 zani/zani kernel: [<00802d1a>] dump_stack+0x8a/0xb8 Feb 3 21:07:50 zani/zani kernel: [<00800962>] dump_header+0x82/0x2c0 Feb 3 21:07:50 zani/zani kernel: [<002b46fe>] oom_kill_process+0xde/0x380 Feb 3 21:07:50 zani/zani kernel: [<002b550c>] out_of_memory+0x24c/0x3b8 Feb 3 21:07:50 zani/zani kernel: [<002bd032>] __alloc_pages_nodemask+0x10b2/0x1160 Feb 3 21:07:50 zani/zani kernel: [<0013e414>] copy_process.part.4+0x24c/0x1fb0 Feb 3 21:07:50 zani/zani kernel: [<00140550>] _do_fork+0xf0/0x430 Feb 3 21:07:50 zani/zani kernel: [<001409ce>] sys_clone+0x3e/0x50 Feb 3 21:07:50 zani/zani kernel: [<0080d630>] system_call+0xd8/0x2bc ... Feb 3 21:07:50 zani/zani kernel: oom_reaper: reaped process 45952 (redis-server), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB ... Feb 3 21:07:50 zani/zani kernel: sshd invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, oom_score_adj=0 ... Feb 3 21:07:50 zani/zani kernel: munin-node invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, oom_score_adj=0 ... Feb 3 21:07:50 zani/zani kernel: oom_reaper: reaped process 36654 (schroot), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB ... Feb 3 21:07:50 zani/zani kernel: oom_reaper: reaped process 34994 (sbuild), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB ... Feb 3 21:07:50 zani/zani kernel: oom_reaper: reaped process 1508 (syslog-ng), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB ... Feb 3 21:07:50 zani/zani kernel: oom_reaper: reaped process 1863 (samhain), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB ... Feb 3 21:07:50 zani/zani kernel: dpkg-buildpackage invoked oom-killer: gfp_mask=0x6200ca(GFP_
Bug#982122: redis: experimental package OOMs s390x buildds
Source: redis Version: 5:6.2~rc3-1 Severity: serious Tags: ftbfs Hi, Both s390x buildds hit OOM conditions while attempting to build redis 6.2 in experimental. The log from zani ends with: [33/63 done]: integration/rdb (10 seconds) Testing integration/corrupt-dump [ok]: corrupt payload: #7445 - with sanitize [...] [ok]: corrupt payload: fuzzer findings - hash convert asserts on RESTORE with shallow sanitization [ok]: corrupt payload: OOM in rdbGenericLoadStringObject [TIMEOUT]: clients state report follows. sock2aa3bc1aa00 => (SPAWNED SERVER) pid:45952 Killing still running Redis server 41748 Regards, Adam
Bug#982123: librsvg: FTBFS on ppc64el
Source: librsvg Version: 2.44.10-2.1+deb10u3 Severity: serious Tags: ftbfs Hi, The librsvg package in proposed-updates fails to build on ppc64el. >From the most recent attempt: ERROR: rsvg-test thread '' panicked at 'assertion failed: bounds.x1 >= bounds.x0', rsvg_internals/src/surface_utils/iterators.rs:36:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. fatal runtime error: failed to initiate panic, error 3349341568 Aborted # random seed: R02S374bda2a068f02db60f864f2b10e8489 1..189 # Start of rsvg-test tests # Start of reftests tests # Storing test result image at /<>/tests/output/css-import-out.png ok 1 /rsvg-test/reftests/css-import.svg PASS: rsvg-test 1 /rsvg-test/reftests/css-import.svg # Storing test result image at /<>/tests/output/duplicate-id-out.png ok 2 /rsvg-test/reftests/duplicate-id.svg PASS: rsvg-test 2 /rsvg-test/reftests/duplicate-id.svg # Storing test result image at /<>/tests/output/filter-component-transfer-from-reference-page-out.png # 856 pixels differ (with maximum difference of 255) from reference image # Storing test result image at /<>/tests/output/filter-component-transfer-from-reference-page-diff.png not ok 3 /rsvg-test/reftests/filter-component-transfer-from-reference-page.svg FAIL: rsvg-test 3 /rsvg-test/reftests/filter-component-transfer-from-reference-page.svg ERROR: rsvg-test - too few tests run (expected 189, got 3) ERROR: rsvg-test - exited with status 134 (terminated by signal 6?) Regards, Adam
Bug#975372: minidlna: "rm: cannot remove '/var/log/minidlna': Is a directory" on purge
Hi, On Fri, 2021-01-01 at 14:21 +0100, Salvatore Bonaccorso wrote: > Uplaoding 1.2.1+dfsg-1 + CVE fix cannot work. We have already > released 1.2.1+dfsg-2+deb10u1 in the security archives, so any > version we pick to fix issues need to be highter, no matter if we do > several rollbacks or only the #975372 fix. > > So we need in any case 1.2.1+dfsg-2+deb10u2 (no matter if "complete" > rollback, or just the bugfix). > > Given the move of the logdir and systemd unit has now been done with > the DSA, I think my preference would be to only just address the > "fallout" from the logdir move and so adress #975372. > > Adam D. Barratt is Cc'ed in this message, who is a stable release > managers in case he would like to indicate a preference. > > Adam would that be fine with you with your SRM hat on, to let all the > -2 changes pass to stable (agreeing that that would usually not be > stable material under normal cicumstances) and so just address the > introduced #975372? As you say, such changes would not normally be considered as part of a stable update. However, given that they've already been published via the security archive and as such been on user systems for a month or so by this stage, I think attempting to walk back the additional changes now is likely to cause us more pain than just going with them, and hoping that #975372 is the only issue caused as a result. Regards, Adam
Bug#977911: debian-archive-keyring: bullseye archive signing key
Source: debian-archive-keyring Version: 2019.1 Severity: serious X-Debbugs-Cc: ftpmas...@debian.org, debian-rele...@lists.debian.org Hi, We need a new archive signing key for bullseye, so that we can include it in the release. Regards, Adam
Bug#977910: debian-archive-keyring: bullseye SRM key
Source: debian-archive-keyring Version: 2019.1 Severity: serious X-Debbugs-Cc: debian-rele...@lists.debian.org Hi, We need an SRM key for bullseye, so that we can include it in the release. Regards, Adam
Bug#973660: thunderbird: FTBFS on s390x in buster
Package: src:thunderbird Version: 78.3.1-2~deb10u1 Severity: serious Tags: ftbfs Control: affects -1 release.debian.org security.debian.org X-Debbugs-Cc: t...@security.debian.org Hi, Since 78.3.1, thunderbird FTBFS on s390x in buster(-security). The relevant part of the logs appears to be: make[5]: Entering directory '/<>/obj-thunderbird/config/external/icu/data' mkdir -p '.deps/' config/external/icu/data/icudata_gas.o /usr/bin/clang -std=gnu99 -o icudata_gas.o -DNDEBUG=1 -DTRIMMED=1 -fPIC -Wa,--noexecstack -include /<>/obj-thunderbird/mozilla-config.h -DMOZILLA_CLIENT -g -I/<>/config/external/icu/data -I/<>/config/external/icu/data/ '-DICU_DATA_FILE="icudt67b.dat"' -DICU_DATA_SYMBOL=icudt67_dat -c /<>/config/external/icu/data/icudata_gas.S /<>/config/external/icu/data/icudata_gas.S:17:17: error: Could not find incbin file 'icudt67b.dat' .incbin "icudt67b.dat" ^ make[5]: *** [/<>/config/rules.mk:743: icudata_gas.o] Error 1 make[5]: Leaving directory '/<>/obj-thunderbird/config/external/icu/data' make[4]: *** [/<>/config/recurse.mk:74: config/external/icu/data/target-objects] Error 2 Regards, Adam
Bug#968102: [Pkg-mozext-maintainers] Bug#968102: Bug#968102: new upstream release (2.16)
On Wed, 2020-10-07 at 11:11 +0200, Carsten Schoenert wrote: > Hello Mechtilde, > > Am 07.10.20 um 10:34 schrieb Mechtilde: > > Hello, > > > > I will do a update-proposal for buster ASAP. > > > > Do I still have to consider something to get it drectly into buster > > and > > not just with the next point release. > > that's a decision finally made by the RT. > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#upload-stable > > I'm sure if you kindly ask and can describe why an upload to > stable-update instead of proposed-updates is useful for Debian As a point of clarity here - there's no such thing as "an upload to stable-updates", and it's certainly not "instead of proposed-updates". The update *always* goes to proposed-updates, and may then be copied to stable-updates from there. Regards, Adam
Bug#964291: stretch-pu: package mariadb-10.1 10.1.45-0+deb9u1
Control: severity -1 normal On Sun, 2020-07-05 at 09:59 +0300, Otto Kekäläinen wrote: > Package: release.debian.org > Severity: serious No. p-u bugs (and basically all release.d.o bugs) are (still) normal at most. Please don't inflate severity like that. It may be RC for your individual package, it is not so for the release management process. > Tags: stretch, moreinfo Tagging your bug "moreinfo" means that it's not ready for processing by SRM. Is that what you intended? Regards, Adam
Bug#932296: qa.debian.org: getwatch filling up /tmp
On Wed, 2020-06-17 at 00:14 +0200, Lucas Nussbaum wrote:
> On 16/06/20 at 21:07 +0100, Adam D. Barratt wrote:
> > On Tue, 2020-06-16 at 16:40 +0200, Julien Cristau wrote:
> > > On Wed, Dec 18, 2019 at 02:03:13PM +0100, Julien Cristau wrote:
> > > > Control: severity -1 serious
> > > >
> > > > On Thu, Aug 08, 2019 at 01:45:27PM +0200, Julien Cristau wrote:
> > > > > On Wed, Jul 17, 2019 at 10:11:39PM +0200, Lucas Nussbaum
> > > > > wrote:
> > > > > > On 17/07/19 at 14:01 +0200, Julien Cristau wrote:
> > > > > > > something in udd seems to extract entire source packages
> > > > > > > to
> > > > > > > /tmp/getwatch.*. This fills up the disk. Please make it
> > > > > > > not
> > > > > > > do that.
> > [...]
> > > > This happened again. If it won't get fixed I'll go ahead and
> > > > disable that job.
> > > >
> > > Done now, removed the "upstream" importer from the config file.
> > >
> >
> > It looks like that wasn't enough, as ullmann filled its disk again.
> >
> > I've now also updated rudd.conf to disable the importer there.
As a quick note on that, the "disable" key in the configuration doesn't
appear to actually disable anything; from
/srv/udd.debian.org/udd/rlibs/udd-daemon.rb:
def run_importer(imp)
raise 'bugs importer is special' if imp == 'bugs'
if imp.has_key?('disabled')
puts "Not running #{imp['name']}: disabled"
end
init_log if not defined?($log)
$log.debug "Running #{imp['name']}"
So RUDD seems to log that the importer was marked as disabled, and then
run it anyway.
> I emptied the 'upstream' UDD table (no data is better than wrong
> data).
>
> In a previous message, it was proposed to use temporary space under
> /srv, but /srv only has 3.1 GB left. Could you maybe create a
> /srv/udd.debian.org/tmp with maybe 10G ?
>
> Also, does DSA offer the service to send icinga notifications to
> service
> owners? Apparently the condition where this happens is quite rare
> occurences on 08/2019, 12/2019, 06/2020), so notifying me after the
> files were cleaned up from /tmp makes it hard to identify which
> packages cause this issue. If I could get notified when a warning
> limit is reached, it would be much easier to debug.
I'm not sure what the usual policy on that is, but I didn't clean up
/tmp after disabling the importer last night:
drwx-- 3 udd uddadm 4096 Jun 16 20:20 getwatch.qmapshack.n13QHA
drwx-- 3 udd uddadm 4096 Jun 16 20:20 getwatch.picard-tools.Zg0jud
drwx-- 3 udd uddadm 4096 Jun 16 20:50 getwatch.qmapshack.aH184l
drwx-- 3 udd uddadm 4096 Jun 16 20:50 getwatch.picard-tools.SqIkjD
drwx-- 3 udd uddadm 4096 Jun 16 21:20 getwatch.qmapshack.1pIg10
drwx-- 3 udd uddadm 4096 Jun 16 21:20 getwatch.picard-tools.g3weib
drwx-- 3 udd uddadm 4096 Jun 16 21:50 getwatch.qmapshack.oklPSa
drwx-- 3 udd uddadm 4096 Jun 16 21:50 getwatch.picard-tools.Lo3UhJ
So it looks like it's the same couple of packages over and over.
Regards,
Adam
Bug#932296: qa.debian.org: getwatch filling up /tmp
On Tue, 2020-06-16 at 16:40 +0200, Julien Cristau wrote: > On Wed, Dec 18, 2019 at 02:03:13PM +0100, Julien Cristau wrote: > > Control: severity -1 serious > > > > On Thu, Aug 08, 2019 at 01:45:27PM +0200, Julien Cristau wrote: > > > On Wed, Jul 17, 2019 at 10:11:39PM +0200, Lucas Nussbaum wrote: > > > > On 17/07/19 at 14:01 +0200, Julien Cristau wrote: > > > > > something in udd seems to extract entire source packages to > > > > > /tmp/getwatch.*. This fills up the disk. Please make it not > > > > > do that. [...] > > This happened again. If it won't get fixed I'll go ahead and > > disable that job. > > > Done now, removed the "upstream" importer from the config file. > It looks like that wasn't enough, as ullmann filled its disk again. I've now also updated rudd.conf to disable the importer there. Regards, Adam
Bug#950309: stretch-pu: package mariadb-10.1 10.1.44-0+deb9u1
Control: tags -1 +confirmed -moreinfo Control: severity -1 normal On Fri, 2020-01-31 at 10:32 +0200, Otto Kekäläinen wrote: > Package: release.debian.org > Severity: serious Nope. > Tags: stretch, moreinfo Filing the request with "moreinfo" is an interesting choice. :-) > User: release.debian@packages.debian.org > Usertags: pu > > Changelog: > > mariadb-10.1 (10.1.44-0+deb9u1) stretch; urgency=high > > * SECURITY UPDATE: New upstream version 10.1.44. Includes fixes for > the > following security vulnerabilities: > - CVE-2020-2574 > * Previous upstream version 10.1.43 includes a fix for a > regression introduced in the previous release: > - MDEV-20987: InnoDB fails to start when FTS table has FK > relation > * Previous release 10.1.42 includes fix for the following security > vulnerability: > - CVE-2019-2974 > Please go ahead. Regards, Adam
Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3
On Thu, 2019-11-07 at 10:49 -0800, Felix Lechner wrote: > Also, as a side note, would someone please explain why someone still > on stretch would need lintian? I am personally on stable, but most > package maintainers out there seem to track testing or the bleeding > edge, unstable. Well, at least some debian.org infrastructure, including the ftp-master host, are still running stretch, for a starting point. Regards, Adam
Bug#940521: buster-pu: package mariadb-10.3 10.3.18-0+deb10u1
Control: severity -1 normal Control: tags -1 -moreinfo +confirmed [For reference, X-Debbugs-Cc is generally better than your mail client's CC when submitting bugs, as it means the recipient gets the mail from the BTS with the bug number included] On 2019-09-16 20:08, Otto Kekäläinen wrote: MariaDB 10.3.17 included a severe regression that broke replication in setups where it is used. See details in #939819. As per suggested there by Adam, we could upload a stable update to fix this. There was no bug in Debian packaging. Changes only include upstream changes. Changelog: mariadb-10.3 (1:10.3.18-0+deb10u1) buster; urgency=high * New upstream version 10.3.18. Fixes regression introduced in 10.3.17 (MDEV-20247: Replication hangs with "preparing" and never starts) (Closes: #939819) I do wish it were possible to get more targetted fixes for things like this. :-| Please go ahead. How are we looking for the 10.1 update for stretch? Regard, Adam
Bug#939866: [debian-mysql] Bug#939866: Bug#939866: mariadb-server-10.1: replication hangs in state "Slave_IO_Running: Preparing" after upgrade from 10.1.38 to 10.1.41
On Fri, 2019-09-13 at 21:10 +0300, Otto Kekäläinen wrote: > To clarify, 10.3.18 has been uploaded to Debian unstable. Issue is > still open for Buster and Stretch. Is there a likely ETA for when this might be resolvable? If you could prepare (preferably targeted) updates via the usual p-u path then we can look at releasing them via stable-updates so that affected users don't have to wait for the next point release. Regards, Adam
Bug#933002: docker.io: CVE-2019-13139
On Sun, 2019-08-18 at 16:22 +0100, Adam D. Barratt wrote: > On Sun, 2019-08-18 at 16:56 +0200, Arnaud Rebillout wrote: > > * The bug you want to fix in stable must be fixed in unstable > > already (and not waiting in NEW or the delayed queue) > > > > My issue with this particular bug (#933002) is that for now, > > docker.io doesn't build in unstable. It will take a while before > > it > > builds again, as there was changes in the dependency tree. > > > > On the other hand, fixing this bug in stable is just a matter of > > importing the patch from upstream and rebuilding the package. > > > > So how am I supposed to handle that? Waiting for docker.io to be > > fixed and built again in unstable will delay the fix in stable for > > weeks, I don't think it's a good option. > > Nevertheless, that is the case I'm afraid. Updates to stable via > proposed-updates are not appropriate for urgent security updates - > that is what the security archive is for. For the record, this fix became part of DSA 4521. > Looking at > https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=docker.io > , there doesn't appear to be a bug filed for the build failure, so > there's no indication of what the issues are, nor what needs to be > done to fix them. and it looks like the build failures got fixed. Regards, Adam
Bug#933002: docker.io: CVE-2019-13139
On Sun, 2019-08-18 at 16:56 +0200, Arnaud Rebillout wrote: > * The bug you want to fix in stable must be fixed in unstable > already (and not waiting in NEW or the delayed queue) > > My issue with this particular bug (#933002) is that for now, > docker.io doesn't build in unstable. It will take a while before it > builds again, as there was changes in the dependency tree. > > On the other hand, fixing this bug in stable is just a matter of > importing the patch from upstream and rebuilding the package. > > So how am I supposed to handle that? Waiting for docker.io to be > fixed and built again in unstable will delay the fix in stable for > weeks, I don't think it's a good option. Nevertheless, that is the case I'm afraid. Updates to stable via proposed-updates are not appropriate for urgent security updates - that is what the security archive is for. Looking at https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=docker.io , there doesn't appear to be a bug filed for the build failure, so there's no indication of what the issues are, nor what needs to be done to fix them. Regards, Adam
Bug#917485: Bug#919043: nmu: ckermit_302-5.3 (stretch)
Control: tags 919043 + confirmed On Sun, 2019-04-14 at 12:26 +0200, Sebastian Andrzej Siewior wrote: > On 2019-04-13 22:25:19 [+0100], Adam D. Barratt wrote: > > On Fri, 2019-02-15 at 00:04 +0100, Sebastian Andrzej Siewior wrote: > > > I'm proposing this attached debdiff. > > > For testing I compiled it against libssl1.0-dev 1.0.2j-5 and then > > > upgraded to the version provided by the security repository. No > > > error > > > message. I expect it work - it would be awesome if the reporter > > > could > > > confirm this (I can provided the binary packages if required). > > > > Did anything happen there? > > Nope. :-( In the interest of keeping things moving, please feel free to go ahead. Jonathan - feedback here would be appreciated, as we are looking at freezing uploads next weekend in preparation for the point release the following weekend. Regards, Adam
Bug#917485: Bug#919043: nmu: ckermit_302-5.3 (stretch)
On Fri, 2019-02-15 at 00:04 +0100, Sebastian Andrzej Siewior wrote: > On 2019-02-02 14:46:54 [+0100], Andreas Beckmann wrote: > > I'm not going to touch that package, please go ahead with preparing > > a > > NMU (or probably rather QA upload if it is gone from sid) to > > stretch, > > since you seem to know how to properly fix this bug once and for > > all :-) > > I'm proposing this attached debdiff. > For testing I compiled it against libssl1.0-dev 1.0.2j-5 and then > upgraded to the version provided by the security repository. No error > message. I expect it work - it would be awesome if the reporter could > confirm this (I can provided the binary packages if required). Did anything happen there? Regards, Adam
Bug#924129: debian-installer: Kernel for armhf for stretch unbootable
On Tue, 2019-03-26 at 10:39 -0700, Vagrant Cascadian wrote: > On 2019-03-26, Adam D. Barratt wrote: > > On 2019-03-15 06:44, Adam D. Barratt wrote: > > > The updated images for armhf have been available in p-u for a > > > couple of > > > days now. > > > > > > Feedback would be appreciated, as we would like to be able to > > > accept > > > the new kernel upload into p-u, which will block a further > > > rebuild here > > > as it brings an ABI bump. (The existing images should continue to > > > work > > > until the older packages are decrufted in the next point > > > release.) > > > > Thanks to Peter for the feedback. > > > > Vagrant (or anyone else) - anything to add? > > Just tested fine on BananaPI: > > https://cdn-aws.deb.debian.org/debian/dists/stretch-proposed-update > s/main/installer- > armhf/20170615+deb9u5+b3/images/netboot/netboot.tar.gz > > Installed to SATA. No surprises or anything unusual. > > I'd say it's ready; please push it into stretch. Thanks for testing. As I mentioned on IRC, we can't "push it into stretch" without a point release, and the whole point of this exercise was to avoid having to schedule another short-notice point release. However, assuming KiBi has no objections, it sounds like we can go ahead with getting the -9 ABI kernel into p-u in preparation for the 9.9 point release in a few weeks time. Assuming I haven't missed anything, the d-i version in p-u should continue to be suitable for installing stretch on armhf in the meantime (at least until the p-u freeze hits, at which point d-i will get rebuilt against the new kernel). Regards, Adam
Bug#924129: debian-installer: Kernel for armhf for stretch unbootable
On 2019-03-15 06:44, Adam D. Barratt wrote: The updated images for armhf have been available in p-u for a couple of days now. Feedback would be appreciated, as we would like to be able to accept the new kernel upload into p-u, which will block a further rebuild here as it brings an ABI bump. (The existing images should continue to work until the older packages are decrufted in the next point release.) Thanks to Peter for the feedback. Vagrant (or anyone else) - anything to add? KiBi - do you have any opinions on us going ahead with accepting the new kernel (including the ABI bump) into p-u? Regards, Adam
Bug#924129: debian-installer: Kernel for armhf for stretch unbootable
On Sun, 2019-03-10 at 09:51 -0700, Vagrant Cascadian wrote: > On 2019-03-10, Cyril Brulebois wrote: > > Vagrant Cascadian (2019-03-09): > > > > > Thanks for your report; that's known and fixed on the kernel > > > > > side > > > > > already; how to deal with d-i is discussed in: > > > > > https://lists.debian.org/debian-boot/2019/03/msg00165.html > > > > > > > > > > Currently waiting on some input from Vagrant: > > > > > https://lists.debian.org/debian-boot/2019/03/msg00179.html > > > > > > I rebuilt the package from the stretch git branch on armhf > > > against > > > stretch+stretch-updates, and the build went fine. I tested the > > > netboot > > > image and it too seems to be working. [...] > > I've asked the release team (cc-ed), and it was confirmed binNMUing > > debian-installer seems appropriate. This will be done shortly. > > Great! The updated images for armhf have been available in p-u for a couple of days now. Feedback would be appreciated, as we would like to be able to accept the new kernel upload into p-u, which will block a further rebuild here as it brings an ABI bump. (The existing images should continue to work until the older packages are decrufted in the next point release.) Regards, Adam
Bug#875358: Powermock RC #875358
On Fri, 2019-03-01 at 23:34 +0100, Markus Koschany wrote: > I have removed powermock from all reverse-dependencies. This bug > should no longer be a blocker for Buster and powermock can be safely > removed from testing. You didn't, however, ask for unblocks for the reverse-dependencies. I've now unblocked them, and added a removal hint for powermock. This will hopefully sort itself out early next week. Regards, Adam
Bug#916520: devscripts: depends on gnupg | .., gnupg removed from unstable
On Sat, 2018-12-15 at 12:51 +, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Sat, 2018-12-15 at 13:34 +0100, Bernd Zeimetz wrote: > > devscripts depends on gnupg | gnupg2. As buildds/sbuild/... only > > install the first altenative package, builds of all packages > > which depend on devscripts in a way are broken since gnupg was > > removed from unstable. Please either use gnupg1 / gpgv1 and/or > > switch the order of the dependencies. > > When do you think that gnupg removed from unstable? The gnupg2 > 2.2.12-1 > upload from yesterday still appears to include it: > > gnupg | 2.2.12-1 | unstable | all I suspect I know what's going on here. The arch:all build didn't appear until after the dinstall in which the arch:any builds were accepted, so dak isn't currently including it in the packages files for unstable as it's outdated in relation to the arch:any binaries. This should resolve itself after the next dinstall, so everything should be happy again in a few hours time. Regards, Adam
Bug#916520: devscripts: depends on gnupg | .., gnupg removed from unstable
Control: tags -1 + moreinfo On Sat, 2018-12-15 at 13:34 +0100, Bernd Zeimetz wrote: > devscripts depends on gnupg | gnupg2. As buildds/sbuild/... only > install the first altenative package, builds of all packages > which depend on devscripts in a way are broken since gnupg was > removed from unstable. Please either use gnupg1 / gpgv1 and/or > switch the order of the dependencies. When do you think that gnupg removed from unstable? The gnupg2 2.2.12-1 upload from yesterday still appears to include it: gnupg | 2.2.12-1 | unstable | all Regards, Adam
Bug#913674: release.debian.org: Regression: Recent upgrade of opensc breaks Yubikey NEO support
Control: severity -1 normal
On Tue, 2018-11-13 at 22:54 +0100, Hilko Bengen wrote:
> Package: release.debian.org
> Severity: grave
RC bugs in psuedo-packages / teams generally don't make much sense. (On
the whole, anything > normal against release.d.o is likely to be
wrong.)
> Tags: stretch
>
> A few weeks ago I reported that a security patch in
> opensc/0.16.0-3+deb9u1 broke support for Yubkey NEO devices (#910786,
> severity serious). Unfortunately, this did not prevent opensc from
> being included in the recent stretch point release.
Indeed, because no-one reported it to us. (No, filing an RC bug doesn't
count as notifying SRM, I'm afraid.)
> What can we do to fix the package now?
Firstly, one needs to identify whether the same issue affects the
package in unstable.
Once it's been confirmed that unstable is no{t, longer} affected,
someone should produce a fixed package and open a p-u bug to document
uploading that to proposed-updates.
Regards,
Adam
Bug#905332: debdiff
On 2018-11-06 14:43, wf...@niif.hu wrote: Dear Security Team, please consider yourselves notified and please debian-secur...@lists.debian.org is *not* a contact point for the Security Team, it's a public discussion list. Regards, Adam
Bug#910543: bfs 1.2.4-1 fstype test fails on Hurd
Control: severity -1 important On Sun, 2018-10-07 at 21:28 +, Tavian Barnes wrote: > Package: bfs > Version: 1.2.4-1 > Severity: serious > Justification: fails to build from source (but built successfully in > the past) > > Dear Maintainer, > > bfs recently failed to build on Hurd: > https://buildd.debian.org/status/fetch.php?pkg=bfs&arch=hurd-i386&ver > =1.2.4-1&stamp=1538407170&raw=0 Build failures on non-release architectures aren't RC (rather by definition); downgrading. Regards, Adam
Bug#910009: exim4-config: upgrade fails when trying to execute conffile difference visualizer
Control: tags -1 + moreinfo unreproducible On 2018-10-01 10:19, Vincent Lefevre wrote: Package: exim4-config Version: 4.91-8 Severity: grave Justification: renders package unusable [...] *** exim4.conf.template (Y/I/N/O/D/Z) [default=N] ? D dpkg (subprocess): unable to execute conffile difference visualizer (less -Lis): No such file or directory dpkg: error processing package exim4-config (--configure): conffile difference visualizer subprocess returned error exit status 2 How is this possibly a bug in exim4-config? That package does not specify what command dpkg should use in order to page diffs. Looking at the dpkg source code, it first checks $PAGER and if that's not set falls back to running the "pager" executable. That suggests one of two things: - you have $PAGER set to "less -Lis" and for some reason don't have less available - your /usr/bin/pager alternative points to something that's not installed on your system. 1) What is $PAGER set to in the environment in which you performed the upgrade? 2) What does /usr/bin/pager point to? (Please chase any symlinks to the ultmate endpoint) 3) How precisely did you invoke dpkg? Regards, Adam
Bug#860064: #860064 dnsmasq will not start after dns-root-data upgrade
On Thu, 2018-07-19 at 18:23 +0100, Adam D. Barratt wrote: > On Thu, 2018-07-19 at 18:42 +0200, Christoph Martin wrote: > > tags 860064 +stretch > > tags 860064 +jessie > > thanks > > > > Am 01.07.2018 um 15:38 schrieb Adam D. Barratt: > > > On Sun, 2018-07-01 at 11:38 +, Martin, Christoph wrote: > > > > dns-root-data had an update a week before. the file with the > > > > dns > > > > root > > > > keys was updated. at least the format has changed. > > > > > > To re-iterate, no such change has happened recently in stretch. > > [...] > > > The file /usr/share/dns/root.ds was changed in both jessie and > > > > stretch > > with the update at june 24th: > > Please explain how the file was changed in stretch on that date. > Specifically, which version of dns-root-data was updated, from which > version. > > Sorry to keep going on about this, but there wasn't a dns-root-data > update in the stretch point release that occurred on June 24th, so > I'm very confused as to what effect you're apparently seeing. To correct myself, there wasn't even a stretch point release on that date, just a jessie one. The remainder of my request still stands - please provide exact details of the upgrade demonstrating the breakage in stretch, including binary package names and before and after versions. Regards, Adam
Bug#860064: #860064 dnsmasq will not start after dns-root-data upgrade
On Thu, 2018-07-19 at 18:42 +0200, Christoph Martin wrote: > tags 860064 +stretch > tags 860064 +jessie > thanks > > Am 01.07.2018 um 15:38 schrieb Adam D. Barratt: > > On Sun, 2018-07-01 at 11:38 +, Martin, Christoph wrote: > > > dns-root-data had an update a week before. the file with the dns > > > root > > > keys was updated. at least the format has changed. > > > > To re-iterate, no such change has happened recently in stretch. [...] > > The file /usr/share/dns/root.ds was changed in both jessie and > stretch > with the update at june 24th: Please explain how the file was changed in stretch on that date. Specifically, which version of dns-root-data was updated, from which version. Sorry to keep going on about this, but there wasn't a dns-root-data update in the stretch point release that occurred on June 24th, so I'm very confused as to what effect you're apparently seeing. regards, Adam
Bug#903406: gridengine: FTBFS on armhf due to OpenJDK VM changes
On Mon, 2018-07-09 at 16:43 +0100, Adam D. Barratt wrote: > gridengine fails to build on armhf due to the VM-related changes in > OpenJDK 8u144-b01-2, which mean that the lib/server directory no > longer exists on that architecture. > > I've build-tested the attached patch on abel.d.o (the armhf > porterbox). fwiw, the nearest I found to an explicit mention of the change was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874276#61 : > and why the server VM is no longer available on armhf > (maybe it never was?). With the last upload we now build openjdk from the ARM32 hotspot jvm, which only provides the client vm. zero always advertises itself as the server VM. Regards, Adam
Bug#903406: gridengine: FTBFS on armhf due to OpenJDK VM changes
Source: gridengine Version: 8.1.9+dfsg-4 Severity: serious Tags: patch Control: block 903015 by -1 Hi, gridengine fails to build on armhf due to the VM-related changes in OpenJDK 8u144-b01-2, which mean that the lib/server directory no longer exists on that architecture. I've build-tested the attached patch on abel.d.o (the armhf porterbox). Regards, Adam--- a/source/aimk.orig 2018-07-09 14:23:01.642562774 + +++ b/source/aimk 2018-07-09 14:25:39.495856441 + @@ -2002,7 +2002,10 @@ set JAVA_LIB_ARCH = "" echo "WARNING: no JAVA_LIB_ARCH for architecture $buildarch" endsw - if ( "$JAVA_LIB_ARCH" != "") then + if ( "$buildarch" == "lx-armhf") then +# Debian/armhf doesn't ship a "server" VM +set JAVA_LFLAGS="-L$JAVA_HOME/jre/lib/$JAVA_LIB_ARCH/client" + else if ( "$JAVA_LIB_ARCH" != "") then set JAVA_LFLAGS="-L$JAVA_HOME/jre/lib/$JAVA_LIB_ARCH/server" else set JAVA_LFLAGS=""
Bug#860064: #860064 dnsmasq will not start after dns-root-data upgrade
On Sun, 2018-07-01 at 11:38 +, Martin, Christoph wrote: > dns-root-data had an update a week before. the file with the dns root > keys was updated. at least the format has changed. To re-iterate, no such change has happened recently in stretch. I understand that the update in jessie may have introduced such a change, but at this stage there's unfortunately nothing that either the security or release teams can do about that, as jessie is EOL and has moved to the LTS team. Regards, Adam
Bug#860064: #860064 dnsmasq will not start after dns-root-data upgrade
On Mon, 2018-06-25 at 10:44 +0200, Christoph Martin wrote: > severity 860064 critical > On which grounds are you claiming this qualifies for critical severity? It doesn't introduce a security hole, cause severe data loss or break your whole system. I have difficulty with dnsmasq and dns-root-data being "unrelated software", particularly given that dnsmasq-base has "Recommends: dns-root-data". Regards, Adam
Bug#860064: #860064 dnsmasq will not start after dns-root-data upgrade
On Mon, 2018-06-25 at 10:44 +0200, Christoph Martin wrote: > severity 860064 critical > tags 860064 +jessie > thanks > > yesterday jessie and stretch upgraded the dns-root-data package, > which includes the new root DNSSEC keys with a time to live value > added. This is factually incorrect. Absolutely nothing changed in stretch with respect to dns-root-data since October 2017. Please don't spread misinformation. > Because auf this update and the bug in dnsmasq, every dnsmasq > installation on jessie and stretch which has dns-root-data installed > will fail to work. > > The patch in the bug report is easy and works. > > We need an urgent update for jessie and stretch. Why is an update for stretch required, given that nothing changed? Regards, Adam
Bug#901185: exim4-config: fails to install
Control: tags -1 + moreinfo On Sun, 2018-06-10 at 00:17 +0200, Eric Valette wrote: > Paramétrage de exim4-config (4.91-5) ... > /etc/exim4/update-exim4.conf.conf: ligne 32: dc_eximconfig_configtype > : commande introuvable > /etc/exim4/update-exim4.conf.conf: ligne 32: dc_eximconfig_configtype > : commande introuvable > That doesn't make huge amounts of sense, at least at first glance. update-exim4.conf, which is what will be being called here, sources update-exim4.conf.conf, but that shouldn't be leading to "command not found" errors. The mention of line 32 is also interesting, as the standard file appears to be 31 lines long. Could you share the content of the file on the relevant machine, please? Regards, Adam
Bug#883071: [release.debian.org] need to recompile eclipse-titan (6.1.0-1) in stable
severity 883071 normal user release.debian@packages.debian.org usertags 883071 + nmu tags 883071 + stretch retitle 883071 nmu: eclipse-titan thanks On 2017-11-29 9:50, Pilisi Gergely wrote: Package: release.debian.org [1] Severity: grave No. The bug in your package might well be Release Critical, the request to rebuild it is most certainly not. Please use "reportbug release.debian.org" when filing such bugs, it will automatically set most of the metadata correctly for you. The Titan compiler needs the same gcc version (major.minor) which compiled the eclipse/titan binaries. When the package was built for stretch, the gcc version was 6.2.x, now it is 6.3.x Now if the user wants to build a TTCN-3 project with the titan compiler, then it will abort with an error: /usr/include/titan/cversion.h:7:2: error: #error The version of GCC does not match the expected version (GCC 6.2.0) A simple recompile will solve this issue, the new binaries will be created with gcc 6.3.x and Titan will work again. So please, recompile eclipse-titan. Regards, Adam
Bug#879231: security update: ruby2.3
On Sat, 2017-11-04 at 22:08 +0100, Salvatore Bonaccorso wrote: > Hi Antonio > > Sorry for the late reply > > On Mon, Oct 23, 2017 at 11:49:28AM -0200, Antonio Terceiro wrote: > > Hi security team, > > > > I have prepared a security update for ruby2.3. > > > > It includes all the pending recent CVE's, plus a fix for a bug that > > causes runaway child processes hogging the CPU, noticed at least in > > puppet. > > For the later one, not directly a security issue, strictly speaking > we > would need an ack from the SRM to see they would ack it to a point > release and then we can pick it as well for a security update. The > patch though looks confined enough that I would trust it's okay as > well for SRM to see it included (Cc'ed explicity Adam). Assuming that's "0005-thread_pthread.c-do-not-wakeup-inside-child- processe.patch", it looks okay to me. As I've previously mentioned to Salvatore in another discussion, the fact that the patch hasn't been applied in unstable, afaict, doesn't fit our usual requirements for accepting patches in stable. I understand there are reasons for that, and the upload going via the security archive does make things slightly easier from that perspective, but as thinks stand I imagine we'll end up pushing +deb9u2 into unstable during the next point release, as we did with +deb9u1 recently. Regards, Adam
Bug#876768: Re: ruby-pygments.rb: fails to run if RLIMIT_NOFILE is very high
Control: block 877043 by -1 Hi, On Mon, 2017-09-25 at 17:44 +0100, James Cowgill wrote: > weechat recently FTBFS due to asciidoctor dying: > https://buildd.debian.org/status/fetch.php?pkg=weechat&arch=mips64el&; > ver=1.9.1-1&stamp=1506204287&raw=0 > > This happens because: > - The RLIMIT_NOFILE hard limit is set to a large value (eg 1048576). > - On startup, ruby-pygments's mentos.py attempts to close all files. > - Since RLIMIT_NOFILE is large, it will attempt to close 1 million > file > descriptors. > - The mips64el buildds are not powerful enough to complete this in > the > timeout time set in popen.rb (default 8 seconds). > - The pygments call fails, returns nil, and causes asciidoctor to > crash. This also happens on several architectures in stretch, affecting the recent update to weechat there, which unfortunately didn't make it in to today's point release as a result. I'd therefore like to get this fixed in stretch. Would you like to handle that yourself? Regards, Adam
Bug#864947: Re: parl-desktop-world depends on cruft package firefox-esr-l10n-be
On Sun, 2017-06-18 at 12:19 +0100, peter green wrote: > Tags 864947 +patch > Thanks > > > parl-desktop-world depends on firefox-esr-l10n-be which is no > > longer built by firefox-esr. I'm still trying to figure out where > > this is coming from, I can't find any evidence of it in the source > > package but rebuilding the binaries doesn't make it go away. > > > > Ok, figured it out, the reference comes from boxer-data > > So to fix this bug requires an update to boxer-data followed by a > (sourceful) rebuild of debian-parl. Patch for boxer-data is at http:/ > /debdiffs.raspbian.org/main/b/boxer-data/boxer- > data_10.5.20%2brpi1.debdiff , once I have confirmed this mail is in > the buglog I will clone/block. The crufty firefox-esr binaries were removed during today's stretch point release, so both packages will need updates in stable - once they're fixed in unstable. Regards, Adam
Bug#872525: [pkg-gnupg-maint] Bug#872525: debian-archive-keyring FTBFS with gnupg 2.1.23
On Fri, 2017-08-18 at 21:30 +0100, Adam D. Barratt wrote: > 1. Have the rules that generate the keyrings clean them afterwards. For > example, changing: > > keyrings/debian-archive-keyring.gpg: active-keys/index > jetring-build -I $@ active-keys > > to > > keyrings/debian-archive-keyring.gpg: active-keys/index > jetring-build -I $@ active-keys > gpg --import-options import-export --import < $@ > $@.tmp > mv -f $@.tmp $@ > > and similarly for the removed keyring. (and maybe for the trusted.gpg.d > files as well?) Hmmm. Do you know which version of gpg added support for the "import-export" option? It doesn't appear to be supported by jessie's gpg1 or gpg2, which would make this option more awkward if one ever wanted to backport d-a-k to jessie in future. Regards, Adam
Bug#872525: [pkg-gnupg-maint] Bug#872525: debian-archive-keyring FTBFS with gnupg 2.1.23
[CC += 870780] On Fri, 2017-08-18 at 03:46 -0400, Daniel Kahn Gillmor wrote: > On Fri 2017-08-18 10:02:49 +0300, Adrian Bunk wrote: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/debian-archive-keyring.html > > > > ... > > gpg --no-options --no-default-keyring --no-auto-check-trustdb > > --trustdb-name ./trustdb.gpg \ > > --keyring keyrings/team-members.gpg --verify \ > > keyrings/debian-archive-keyring.gpg.asc \ > > keyrings/debian-archive-keyring.gpg > > gpg: Signature made Thu May 25 06:30:03 2017 -12 > > gpg: using RSA key C5CE5DC2C542CD59 > > gpg: BAD signature from "Adam D. Barratt " > > [unknown] [...] > The difference between the keyrings is the trust packets: [...] > This is happening because of a combination of several factors: > > One of them is https://bugs.debian.org/870780 -- the > debian-archive-keyring really shouldn't have OpenPGP trust packets in it > in the first place. Those are deliberately underspecified and > vendor-specific: [...] > The larger problem here is that jetring (and debian-archive-keyring, and > anything else which uses jetring) seems to assume some things about what > GnuPG does with the contents of ~/.gnupg. [...] > If #870780 was resolved (perhaps by fixing jetring to use GnuPG's > external interfaces?) and a new debian-archive-keyring.gpg.asc was > created by Adam (or some other member of the team) then i think this > problem would go away. As discussed on IRC, I think the fundamental fix here needs to be in jetring. In the short term, however, we could resolve the issue in d-a-k in one of two ways. 1. Have the rules that generate the keyrings clean them afterwards. For example, changing: keyrings/debian-archive-keyring.gpg: active-keys/index jetring-build -I $@ active-keys to keyrings/debian-archive-keyring.gpg: active-keys/index jetring-build -I $@ active-keys gpg --import-options import-export --import < $@ > $@.tmp mv -f $@.tmp $@ and similarly for the removed keyring. (and maybe for the trusted.gpg.d files as well?) 2. Add the manual equivalent of the above to the "pre-build" section of README.maintainer, leaving the package creating crufty files and the responsibility of cleaning them up resting with the person generating the package. Particularly if we want/need to clean up the trusted.gpg.d files as well, I'm inclined towards option 1, even if it does mean a small bit of repetition in the makefile. Regards, Adam
Bug#863101: Uscan uses all available memory of the system when run against guitarix
On Sun, 2017-05-21 at 23:09 +0200, Víctor Cuadrado Juan wrote: > On 21/05/17 22:05, Adam D. Barratt wrote: > > > > I've been unable to reproduce this using either jessie or sid's uscan > > (running on a jessie host, admittedly). I'd be interested if anyone else > > can reproduce this or if there's anything unusual about the machine. > > Seems that it isn't only present on uscan: while running debsign I get a > segmentation fault. > > I've carried out heavy tasks on the machine (compiling,etc), and apart from > this > everything looks fine. Then I have to admit to being stumped right now. I honestly find it very difficult to believe that there's a generic issue of this kind affecting debsign or uscan that no-one has yet reported in the more than two months since the last upload. Regards, Adam
Bug#863101: Uscan uses all available memory of the system when run against guitarix
Control: tags -1 + moreinfo unreproducible On Sun, 2017-05-21 at 21:06 +0200, Víctor Cuadrado Juan wrote: > When run against guitarix package git repo, at commit 7ff29bd, > for obtaining `guitarix2-0.35.3.tar.xz` that would become the > `guitarix_0.35.3.orig.tar.xz` symlink, `uscan --verbose` uses > all available ram of the system and if lucky it outputs > "Out of memory!". I've been unable to reproduce this using either jessie or sid's uscan (running on a jessie host, admittedly). I'd be interested if anyone else can reproduce this or if there's anything unusual about the machine. On a side note, looking at the watchfile: (?:|.*/)guitarix2(?:[_\-]v?|)(\d[^\s/]*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz) The parenthesised groups are "either nothing, or zero or more characters followed by a slash", "either nothing, or [one of underscore, backslash or hyphen, possibly followed by v]", "a digit possibly followed by any number of characters that aren't whitespace or a slash", and then an extension. It seems very unlikely to me that those are actually the things you want to be matching - if you're trying to make the matching optional, then "(foo)?" would be far more idiomatic an obvious than "(foo|)" or "(| foo)", and the chances that there'll be a literal backslash in the URL are quite small. Is there any particular reason you're not using something simpler, along the lines suggested by the manpage? This gives the expected result for me: version=3 http://sf.net/guitarix/ guitarix2(?:[_-]v?)?(\d.*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz) Regards, Adam
Bug#859255: binNMU needed for more R packages.
severity 859255 normal user release.debian@packages.debian.org usertags 859255 binnmu thanks On Sat, 2017-04-01 at 15:24 +0900, Charles Plessy wrote: > Package: release.debian.org > Severity: grave > X-Debbugs-CC: debian-...@lists.debian.org, debian-scie...@lists.debian.org I fixed this last time, but didn't explicitly tell you. release.debian.org bugs are *not* RC, please don't set them as such. The packages that you're asking for binNMUs for might be broken, the release metapackage is not. Regards, Adam
Bug#855970: [debian-archive-keyring] The release repository of testing (Stretch), and security updates repository too, have three misiing public keys
Control: severity -1 normal Control: tags -1 -security +moreinfo On Thu, 2017-02-23 at 22:30 +0100, Łukasz Konieczny wrote: > Package: debian-archive-keyring > Version: 2014.3 > Severity: serious > Tags: security > X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org > > --- Please enter the report below this line. --- > The release repository of testing (Stretch), and security updates > repository too, have three misiing public keys. Terminal output of > apt-get update is attached to this mail. Some text is in Polish language. The keys are certainly in the package, so I'm not sure why your apt isn't seeing them. What does gpg --keyring /usr/share/keyrings/debian-archive-keyring.gpg --list-keys 8B48AD6246925553 produce on your system? Regards, Adam
Bug#734837: Why is tk8.4 removal triggering autoremoval messages of not depending packages at this point in time (Was: staden is marked for autoremoval from testing)
On Sat, 2016-12-31 at 15:38 +0100, Thibaut Paumard wrote: > I would believe removing tk8.4 by hand from testing could fix the lot of > associated autoremovals. > > Dear release team, thoughts on that? tk8.4 and tcl8.4 were already re-removed from testing this morning. Regards, Adam
Bug#847575: closed by Hilko Bengen (no embedded dietlibc)
On Tue, 2016-12-27 at 16:13 -0500, Theodore Ts'o wrote: > On Tue, Dec 27, 2016 at 07:56:36PM +0000, Adam D. Barratt wrote: > > Thankfully none of that worked. I say thankfully, because you'd have > > given release.d.o an allegedly RC bug (it may be RC for e2fsprogs, it's > > certainly not so for release.d.o) and removed the original bug from > > where it belongs. (The binNMU doesn't resolve the fact that the original > > issue existed - and for some versions still exists - in e2fsprogs.) > > It only exists in the versions of e2fsprogs shipping in Jessie and > before. So unless the SRM's think that it's worth it to fix this > issue via a change to e2fsprogs going to proposed-updates for Jessie > (I'm not entirely convinced but if you want me to add the Built-Using > and ask for a update to Jessie stable, I can do that, and we can punt > on the binNMU for e2fsck-static since it will be obsoleted by the fix > of e2fsprogs in Debian stable.) I already scheduled the binNMUs for the handful of architectures that I could, in the cloned #849488. You may wish to check the architecture list there and confirm whether any of the others were typoes or if the three architectures mentioned are sufficient. Regards, Adam
Bug#847575: closed by Hilko Bengen (no embedded dietlibc)
Control: clone -1 -2 Control: close -1 Control: reassign -2 release.debian.org Control: severity -2 normal Control: retitle -2 nmu: e2fsck-static Control: tags -2 + jessie pending On Tue, 2016-12-27 at 12:31 -0500, Theodore Ts'o wrote: > retitle -1 release.debian.org: binNMU for e2fsck-static to rebuild against > latest dietlibc > reassign -1 release.debian.org > user release.debian@packages.debian.org > usertag -1 binnmu > thanks Thankfully none of that worked. I say thankfully, because you'd have given release.d.o an allegedly RC bug (it may be RC for e2fsprogs, it's certainly not so for release.d.o) and removed the original bug from where it belongs. (The binNMU doesn't resolve the fact that the original issue existed - and for some versions still exists - in e2fsprogs.) > Agreed, that seems to be the best way to handle things. So that means > we would need to do a binNMU for e2fsck-static/1.42.12-2 for the > following architectures: > > alpha amd64 arm hppa i386 ia64 powerpc ppc64 s390 sparc > > I've reassigned this to the release team to see if the Stable Release > Managers agree (which hopefully they will). Only three of those architectures - amd64, i386 and powerpc - are in stable so are the only ones that are relevant as far as the release.d.o bug is concerned. I've scheduled binNMUs for those; you'll have to handle the others separately, or explain which Debian architectures you actually meant (for instance, "arm" hasn't been used as a Debian architecture name for several releases now). Regards, Adam
Bug#840589: Questioning severity of the bug
On Sun, 2016-10-16 at 18:25 +0200, Ole Streicher wrote: > Hi Peter, > > could you explain why you think this is of severity "serious"? In my > opinion, FTBFS should be "important" as long as there is at least one > useful architecture. Your opinion is not consistent with RC bug policy. See https://release.debian.org/stretch/rc_policy.txt , specifically section 4. A regression in building on a release architecture is RC. If the package has never built on a particular architecture, or the failure occurs on a non-release architecture, the issue is conventionally considered to be of important severity. [...] > IMO it is up to the maintainer's decision to fix the FTBFS here, or to > remove the failing archs from Debian to let the package pass to testing. It is. Until the packages are removed, however, the fact that they fail to build remains a release-critical issue. > So, if you not oppose to, I would lower the severity and make it non-RC. Even if Peter doesn't, I oppose it. The bug *is* RC. Regards, Adam
Bug#840355: Failed to create spool file /var/spool/exim4//input//...-D: Permission denied
On Tue, 2016-10-11 at 04:38 +0800, 積丹尼 Dan Jacobson wrote: > Can't send mail, because: > 2016-10-11 04:30:53 Failed to create spool file > /var/spool/exim4//input//1bthDp-0002gq-Fy-D: Permission denied That looks awfully similar to https://lists.exim.org/lurker/message/20161012.203414.c4c043d5.en.html (which has just had a reply saying it will be fixed in RC3) Regards, Adam
Bug#833574: monotone: FTBFS on powerpc (test suite failure)
On Sat, 2016-10-08 at 00:29 +0300, Adrian Bunk wrote: > I would suggest to upload 1.1-4+deb8u2 (created on top of 1.1-4+deb8u1) > with 51-sigpipe-test.diff added to jessie, but Julien (or any other SRM) > should confirm that. Please open a p-u bug with the proposed fix (as a source debdiff) attached to discuss that; random mails to debian-release@ are awkward to track and tend to get lost. Regards, Adam
Bug#836571: jessie-pu: package rabbitvcs/0.16-1
Control: tags -1 +confirmed -patch +jessie
Control: severity -1 normal
On Sun, 2016-09-04 at 07:32 +0100, Christopher Hoskin wrote:
> Package: release.debian.org
> Severity: critical
*No*. The bug you're fixing may be critical, the request to fix it in
stable is at most normal.
> Tags: patch
> User: release.debian@packages.debian.org
> Usertags: pu
>
> The attached patch fixes bug #817231 in the rabbitvcs package. This is
> classified as a critical bug on the grounds that it can cause serious
> data loss (e.g. loss of entire home folder). There are several reports
> of this actually happening to users of the software on Debian and
> other systems:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817231
> https://github.com/rabbitvcs/rabbitvcs/issues/127
> http://askubuntu.com/questions/473433/rabbitsvn-deleted-all-my-folders
> https://github.com/rabbitvcs/rabbitvcs/issues/70
>
> Bug #817231 has now been closed in unstable. Given the nature of the
> bug, I thought perhaps it should also be fixed in jessie-updates?
Given the fact that the package has no reverse-dependencies and before
your NMU in unstable had not been updated for two years, I wonder
whether removal might have been a better option.
> The attached patch acheives this. (I understand that the distribution
> needs to be set to jessie in debian/changelog, rather than {jessie|
> stable}-updates[0].)
One can't upload to stable-updates, indeed, rather by definition. (It's
an SRM-selected subset of packages in proposed-updates, not a standalone
target.)
I assume your rationale for suggesting a release via stable-updates,
rather than simply waiting for the next point release (which will be in
just under two weeks time) is the potential for data loss. Whilst this
is indeed unfortunate, I think we've only previously used -updates for
fixing RC bugs when they were regressions caused by other packages
published via -updates or in a point release.
+rabbitvcs (0.16-1.1) jessie; urgency=medium
That version number is wrong, for multiple reasons - most importantly,
that it's already been used for your NMU to unstable. Please use either
0.16-1+deb8u1 or 0.16-1.1~deb8u1, depending on whether the patch in the
jessie upload is applied to a fresh copy of 0.16-1 or the unstable
package is "backported".
With that fixed, please feel free to get the package uploaded.
Regards,
Adam
Bug#826667: Bug#826714: jessie-pu: package biber/1.9-3+deb8u1
Control: tags 826714 + pending On Fri, 2016-06-10 at 19:04 +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Fri, 2016-06-10 at 10:06 +0300, Niko Tyni wrote: [...] > > IMO updating biber in jessie to work around this (like it already does > > in sid/stretch) is the safest thing to do, but YMMV of course. > > Ack, let's do that. Uploaded and flagged for acceptance. Regards, Adam
Bug#826667: Bug#826714: jessie-pu: package biber/1.9-3+deb8u1
Control: tags -1 + confirmed On Fri, 2016-06-10 at 10:06 +0300, Niko Tyni wrote: > I think the root cause is in libunicode-linebreak-perl, now filed as > #826932. Thanks for the information. > IMO updating biber in jessie to work around this (like it already does > in sid/stretch) is the safest thing to do, but YMMV of course. Ack, let's do that. Regards, Adam
Bug#826563: stable-updates fix for Bug#826563: perl: Apparent regression in TryCatch
On Tue, 2016-06-07 at 00:46 +0100, Dominic Hargreaves wrote: > On Mon, Jun 06, 2016 at 08:54:23PM +0100, Dominic Hargreaves wrote: [...] > > In hindsight, it's obvious that Debian's testing of this update wasn't > > sufficient either. Such breaking changes in perl stable updates are, > > I believe, exceedingly rare, but equally we had not attempted a wholesale, > > or near-wholesale update in Debian stable before, and the breakage > > wasn't reported in any real-world testing using the stable update > > installed from source. In future, we should perform similar automated > > testing against jessie-proposed-updates as we do in experimental when > > a new major version of perl is introduced. [...] > I've prepared an updated package of libdevel-declare-perl, which builds > and tests out fine with both perl 5.20.2-3+deb8u4 and 5.20.2-3+deb8u5. > > A debdiff for stable is attached. Release team, are you happy for me > to upload (is the distribution correct for stable-updates)? Yes, it is, in as much as one never uploads to stable-updates - one uploads to stable, via p-u, and we cherry-pick uploads from there sideways into -updates at our discretion once they're ready. Please go ahead with the upload to p-u and we'll see from there. In general it's also preferable if a new release.d.o bug is filed to track the upload, rather than CCing debian-release on bugs belonging to another package. (I realise that this is a regression, but the popcon stats for libdevel-declare-perl have a "recent" count of 10, which does make me wonder how wide an impact this is actually having in practice.) Regards, Adam
Bug#826334: dget: removes existing dir by default without asking
Control: reassign -1 dpkg-dev 1.17.27 Control: affects -1 devscripts Control: retitle -1 dpkg-source -x overwrites existing directories On Sat, 2016-06-04 at 18:08 +0200, ydir...@free.fr wrote: > dget unpacks the downloaded source by default, even if the target directory > was > pre-existing. Moreover, it does not just unpack it above the pre-existing > dir, > but removes it first, together with all the other files it may contain ! Nope. dget simply calls "dpkg-source -x". The effect is trivially reproducible by calling "dpkg-source -x somepackage.dsc an-existing-directory" without needing to involve dget at all. Regards, Adam
Bug#823274: login error
Control: forcemerge 823236 -1 On Tue, 2016-05-03 at 02:00 +0530, Hema .p wrote: > Package: sso.debian.org > Severity: grave > > Hi, > > I can't login to sso.debian.org using my Alioth account "hemaprathaban-guest". > > Error message: > Authentication failed > Invalid authenticating information You already reported this a few hours ago, as bug #823236. Please don't file duplicates, they don't help anyone. Regards, Adam
Bug#819958: totem: This file cannot be played over the network. Try downloading it locally first.
On 2016-04-07 10:03, Raphael Hertzog wrote: [...] ii gstreamer1.0-plugins-bad1.6.3-1+b2 ii gstreamer1.0-plugins-base 1.6.3-1 ii gstreamer1.0-plugins-good 1.6.3-1 1.6.3 plugins but ii libgstreamer1.0-0 1.8.0-1 1.8.0 library I solved the problem by upgrading the plugins to the 1.8.0 version in unstable... Can we have stricter dependencies between the plugins and the library? Also ccing the release team to see if they can speed up/force the migration of the plugins. The migration's already being attempted but failing due to missing binNMUs for gstreamer1.0-vaapi. Those were scheduled earlier this morning, so hopefully things will unblock in the near future. Regards, Adam
Bug#819586: debian-installer-netboot-images: unhelpful handling of GPG errors
Source: debian-installer-netboot-images Version: 20120712 Severity: serious Justification: silently ignores failures, creating broken packages Hi, Whilst preparing the dini uploads for the upcoming point releases, on debdiffing the binary packages against the previous versions I noticed that one of them seemed to have lost all of its files and had an Installed-Size of 32. Checking the build log, I found that this was due to one of the Release file checks failing with: gpgv: BAD signature from "Debian Archive Automatic Signing Key (7.0/wheezy) " (This appears to have been an issue with a particular mirror, fwiw.) The checks in get-images.sh do: if gpgv --keyring /usr/share/keyrings/debian-archive-keyring.gpg $RELEASE_FILE.gpg $RELEASE_FILE ; then get_di_built_using $1 get_installer $1 fi Whilst a failure to verify the Release signature does mean that we don't attempt to build an image using untrusted inputs, the package build continues with no sign of a problem having occurred until the binary packages are examined. Regards, Adam
Bug#816205: tagging 816205
On Mon, 2016-03-28 at 14:39 +0200, Mathieu Parent (Debian) wrote: > 2016-03-26 18:35 GMT+01:00 Adam D. Barratt : > > On Sat, 2016-03-26 at 17:14 +0100, Mathieu Parent wrote: > >> tags 816205 + jessie-ignore > >> thanks > > > > Was that discussed with anyone on the Release Team before the tag was > > added? > > No.I've done it to remove this bug from my UDD dashboard. I see. Please don't do that in future. The tags have a specific purpose (which isn't "I don't want to fix or see this in $release") and should only be set by, or with the agreement of, the Release Team. See the bolded sections of https://www.debian.org/Bugs/Developer#tags Regards, Adam
Bug#816205: tagging 816205
On Sat, 2016-03-26 at 17:14 +0100, Mathieu Parent wrote: > tags 816205 + jessie-ignore > thanks Was that discussed with anyone on the Release Team before the tag was added? >From a quick look at the bug log it may well be suitable for a -ignore tag, but it shouldn't simply be added by the maintainer or a bug triager (with a couple of exceptions where the SRMs have previously agreed scope with some people). Regards, Adam
Bug#808874: debian-installer: FTBFS on i386: 586 vs. 686
On Fri, 2015-12-25 at 18:55 +0100, Cyril Brulebois wrote: > Ben Hutchings (2015-12-24): > > On Thu, 2015-12-24 at 03:30 +0100, Cyril Brulebois wrote: > > > Ben Hutchings (2015-12-24): > > > > I already updated base-installer for this, and I think the only other > > > > change needed was in build/config/i386.cfg. I've pushed a change to > > > > that. > > > > > > Checking my notes, it appears the following bits were involved last time: > > > base-installer, debian-installer, debian-cd, installation guide. > > > > > > The first two seem covered now, thanks. > > > > > > Adding debian-cd@ for the third (sorry, didn't do any research for this > > > one). > > > > I opened bug #808958 with a patch. > > > > > The last one seems to have been dealt with in r69410, r69411, r69412 > > > last time; something similar might do the trick this time. > > > > Updated in r70113, r70114. > > Perfect, thanks! It looks like the 20160101 upload included relevant changes, and built happily on i386. Is there anything remaining to fix? Regards, Adam
Bug#806387: menu tests paradoxical
Control: severity -1 normal On Thu, 2015-11-26 at 22:47 +0100, Jörg Frings-Fürst wrote: > Package: lintian > Version: 2.5.38.1 > Severity: serious Definitely not. > Hi, > > Since the tech-ctte decision at bug #741573 is the command listed both in a > menu file and a desktop file prohibited. > > Therefor I get the warning "xsane: command-in-menu-file-and-desktop-file xsane > usr/share/menu/xsane:6" > > After remove the command from the menu file I get this error: "E: xsane: menu- > item-missing-required-tag command usr/share/menu/xsane:6" Well, yes. You're supposed to remove the whole stanza (and in many cases the whole file), not just one little bit of it. The referenced TC decision says: 2. In addition to those changes, the Technical Committee resolves that packages providing a .desktop file shall not also provide a menu file for the same application. I'm not clear how one gets from "shall not also provide a menu file for the same application" to "can also provide a menu file for the same application as long as there's no command= in it". At worst the wording of the tag needs improving; the above description doesn't indicate any kind of functionality bug in the checks, just a misunderstanding of the intended action. Regards, Adam
Bug#802474: Error in dist squeeze armel content list
Control: reassign -1 ftp.debian.org Control: forcemerge 801200 -1 On 2015-10-20 13:25, Andreas Hänel wrote: Package: release.debian.org Severity: grave The Release Team don't run the archive. Reassigning to ftp.debian.org. When trying to install python on following release: uname -a Linux GeSyNAS 2.6.31.8.nv+v2 #1 Thu Apr 18 17:40:54 HKT 2013 armv5tel GNU/Linux /etc/debian_version = 6.0.3 [...] Err http://ftp.us.debian.org/debian/ squeeze/main python2.6-minimal armel 2.6.6-8+b1 404 Not Found [IP: 128.61.240.89 80] Err http://ftp.us.debian.org/debian/ squeeze/main python2.6 armel 2.6.6-8+b1 404 Not Found [IP: 128.61.240.89 80] Failed to fetch http://ftp.us.debian.org/debian/pool/main/p/python2.6/python2.6-minimal_2.6.6-8+b1_armel.deb 404 Not Found [IP: 128.61.240.89 80] Failed to fetch http://ftp.us.debian.org/debian/pool/main/p/python2.6/python2.6_2.6.6-8+b1_armel.deb 404 Not Found [IP: 128.61.240.89 80] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Regards, Adam
Bug#799717: stress: ships /usr/share/info/dir.gz on arm64
Control: tags -1 -jessie On 2015-10-11 16:56, Eriberto Mota wrote: tags 799717 jessie thanks Hi Uwe, Thanks for your report. Currently, this issue is found in Jessie, not in Sid. So, I added a tag 'jessie'. That's not how to indicate that. If the bug is fixed in sid, mark it as fixed in the version that's in sid (or the version that it was initially fixed in, if that's different). Tagging the bug "jessie" only really makes sense if the same version is present in jessie and sid but the bug doesn't affect sid for some reason. Regards, Adam
Bug#801770: devscripts: rmadison does not run properly but instead has a mishmash of rubbish
Control: tags -1 + moreinfo unreproducible
Control: severity -1 important
On 2015-10-14 13:12, Sharon Kimble wrote:
Package: devscripts
Version: 2.15.9
Severity: grave
Justification: renders package unusable
An issue with a single script in the package does not render the whole
package unusable (even for an "important" script).
rmadison emacs24
<��0
E��l9[)���fՀ���؇�{OK)�� t7���}"�S�8�ە���1�ʹ�E��GA2�4z�p ���E��q�J���Qa4
�uq(��J��0�Q(�+.IL�IE�9,�b#������f���� TC0��X�
�@Ri0O��OAA��
H�%�����"����Bv������B7�h���%��%�y�4� �����";
This is on a fresh install of jessie yesterday, 64bit. I've tried
upgrading to
the version of devscripts in testing, but it makes no difference, still
the
same mishmash.
I was hoping to see the output showing what version of emacs24 in all
debian
repos.
I'm unable to reproduce this:
adam@mowgli:~$ rmadison emacs24
debian:
emacs24 | 24.4+1-4.1~bpo70+1 | wheezy-backports | source, amd64, i386,
ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x,
sparc
emacs24 | 24.4+1-4.1 | sid | source, hurd-i386
emacs24 | 24.4+1-5 | jessie-kfreebsd | source,
kfreebsd-amd64, kfreebsd-i386
emacs24 | 24.4+1-5 | jessie | source, amd64, arm64,
armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x
emacs24 | 24.5+1-2 | stretch | source, amd64, arm64,
armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x
emacs24 | 24.5+1-2 | sid | source, amd64, arm64,
armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el,
mipsel, powerpc, ppc64el, s390x
new:
adam@mowgli:~$
(2.15.3, on jessie amd64)
Please provide the output of:
- grep -i rmadison /etc/devscripts.conf
- env | grep -i proxy
- which rmadison
- type rmadison
Regards,
Adam
Bug#740998: closed by Michael Gilbert (Bug#740998: fixed in ndisc6 1.0.1-2)
On Sun, 2015-10-11 at 16:50 +0100, Dominic Hargreaves wrote: > On Sat, Feb 14, 2015 at 01:36:05AM +, Debian Bug Tracking System wrote: > > > ndisc6 (1.0.1-2) unstable; urgency=medium > > . > >* QA upload. > >* Set maintainer to the Debian QA Group (see #713004). > >* Add conflicts between rdnssd and network-manager (closes: #740998). > > This bug just hit me in Debian stable (as it happens, it appeared to > be a particularly severe form where /etc/resolv.conf was wiped out > altogether; perhaps some sort of race condition?) > > I'm not sure why rdnssd was installed at all. I can't see any mention > of it in debian-installer, and not a single package Depends or Recommends > it. Morever it was installed without resolvconf (which I suspect would > have mitigated this issue), despite it recommending resolvconf, and no > change to the default of installing recommends having taken place. > > Release team; would you consider a QA upload of this package targetted > at stable, fixing this bug in the same way that Michael fixed it in > unstable - this will hopefully stop others having the experience of > having networking break on a freshly installed Debian system every 20 > minutes or so. This was previously discussed in #778492, where there was some concern from the installer side as to possible side effects of the change. CCing -boot to see what current thoughts are. Regards, Adam
Bug#791112: #791112: libcrypto++: library transition may be needed when GCC 5 is the default
On Mon, 2015-08-17 at 11:16 +0200, Christian Hofstaedtler wrote: > Hi, > > I've noticed a new libcrypto++ has entered sid, but the transition > tracker[1] doesn't seem to agree on the library names, or something > (it still shows libcrypto++ as "bad"). > > What's going on there? > > [1] https://release.debian.org/transitions/html/auto-libcrypto++.html libcrypto9-dbg depends on libcrypto9. Until the transition's at a point where those packages can be decrufted from unstable, the tracker will see a package being built from src:libcrypto++ that depends on libcrypto9, and flag it as bad. Regards, Adam
Bug#791467: Processed: block 791467 with 792468, block 792379 with 792468
Control: unblock 792379 with 792468 On Wed, 2015-07-15 at 04:15 +, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: [...] > Bug #792379 [sponsorship-requests] RFS: plowshare4/1.0.5-2 [RC] -- > filesharing website tool implemented in bash > 792379 was not blocked by any bugs. > 792379 was blocking: 791467 > Added blocking bug(s) of 792379: 792468 You need to get the fixed package uploaded to unstable first, regardless of any request to update stable. The approval or otherwise of the p-u request is not blocking that. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#792365: lintian gives false positive for minified js file
Control: severity -1 normal On 2015-07-14 9:26, Pirate Praveen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 package: lintian version: 2.5.33 severity: grave reason: gives wrong lintian error A single false positive for a tag that's not on the auto-reject list is in no way Release Critical. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#791751: Please give back openldap (2.4.40+dfsg-2) on mipsel
On Wed, 2015-07-08 at 18:44 +0200, Luca Bruno wrote: > Dear wb-team, > latest openldap upload (2.4.40+dfsg-2) saw a spurious failure in its > testsuite > on mipsel. > As diff with previous version is quite limited and failure unrelated, we > suspect this was a momentary glitch somewhere. > > Can we please give it a second try there? > > gb openldap_2.4.40+dfsg-2 . mipsel Done. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#791469: apt-get upgrade generates Python errors
Control: reassign -1 python-aptdaemon 0.31+bzr413-1.1+deb6u1 On Sun, 2015-07-05 at 09:06 -0400, Bruce Momjian,,, wrote: > Running apt-get upgrade or apt-get purge generates this Python error: > > Reading package lists... Done > Building dependency tree > Reading state information... Done > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > 3 not fully installed or removed. > After this operation, 0 B of additional disk space will be used. > Do you want to continue [Y/n]? y > Setting up python-aptdaemon (0.31+bzr413-1.1+deb6u1) ... > /usr/lib/python2.5/site-packages/aptdaemon/worker.py:811: Warning: > 'with' will become a reserved keyword in Python 2.6 > Compiling /usr/lib/python2.5/site-packages/aptdaemon/worker.py ... > File "/usr/lib/python2.5/site-packages/aptdaemon/worker.py", line 811 > with set_euid_egid(trans.uid, trans.gid): >^ > SyntaxError: invalid syntax > > pycentral: pycentral pkginstall: error byte-compiling files (12) > pycentral pkginstall: error byte-compiling files (12) That error is being generated by the python-aptdaemon package's postinstall script, not apt; reassigning. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787515: tortoisehg: uninstallable in sid
Package: tortoisehg Version: 3.1.1-1 Severity: serious Hi, tortoisehg depends on "mercurial (>= 3.0~), mercurial (<< 3.2~)", but 3.4 has been in unstable for a month now, rendering tortoisehg uninstallable. This is the last package blocking the migration of mercurial 3.4 to testing so I may temporarily remove it until it's fixed to be compatible with 3.4 Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785091: spatialite-bin: spatialite gives a Segmentation fault.
On Tue, 2015-05-12 at 12:13 +0100, Andy G Wood wrote: > Hi Sebastiaan, > > On Tuesday 12 May 2015 12:03:43 Sebastiaan Couwenberg wrote: [...] > > > Justification: breaks unrelated software > > > > This justification is not supported by your bugreport. > > > > Which unrelated software does this issue break? > > Sorry, perhaps this is not "unrelated", but > > ogr2ogr -a_srs WGS84 -f "SQLite" -dsco SPATIALITE=YES \ > -where 'PTT="143471"' -nln "143471" -append \ > wcp_2015.sqlite wcp.xml > > Segfaults too. Software designed to be able to use spatialite is fairly far away from the definition of "unrelated to spatialite". :-) Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784979: Make package fit for testing
On Mon, 2015-05-11 at 14:02 +0200, Jörg Frings-Fürst wrote: > remove the packages libgphoto2-2-dev and libgphoto2-port10 at update to make > the package fit for testing and finish the auto-libgphoto2 transition. Those binary packages have already stopped being built by libgphoto2. That's normal for a transition. They were semi-automatically removed by the ftp-team on most architectures earlier today and only remain on sparc. This is not any sort of bug in libgphoto2, much less an RC one. Please do not abuse such severities. I'm closing this now. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
