Re: [Stretch] Status for architecture qualification
On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote: > Philipp Kern: > > On 2016-06-05 12:01, Niels Thykier wrote: > >> * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, > >>s390x > >>- *No* blockers at this time from RT, DSA nor security. > >>- s390, ppc64el and all arm ports have DSA concerns. > > What is the current DSA concern about s390x? > The concern listed as: "rely on sponsors for hardware (mild concern)" > > As I recall the argument went something along the lines of: > > "Debian cannot replace the hardware; if any of the machines dies, we > need a sponsor to replace it. If all of them dies and we cannot get > sponsored replacements, we cannot support the architecture any longer" > > (My wording) Yeah, but that's unfortunately one of the universal truths of this port. I mean in theory sometimes they turn up on eBay and people try to make them work[1]. It also seems true for other ports where we commonly relied on sponsors to hand us replacements. But maybe it's only ppc64el these days, maybe there are useful builds available for the others (including arm64 and mips) on the market now. Kind regards and thanks Philipp Kern [1] https://www.youtube.com/watch?v=45X4VP8CGtk (Here's What Happens When an 18 Year Old Buys a Mainframe)
Re: [Stretch] Status for architecture qualification
On 14/06/16 09:06, Philipp Kern wrote: > On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote: >> Philipp Kern: >>> On 2016-06-05 12:01, Niels Thykier wrote: * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, s390x - *No* blockers at this time from RT, DSA nor security. - s390, ppc64el and all arm ports have DSA concerns. >>> What is the current DSA concern about s390x? >> The concern listed as: "rely on sponsors for hardware (mild concern)" >> >> As I recall the argument went something along the lines of: >> >> "Debian cannot replace the hardware; if any of the machines dies, we >> need a sponsor to replace it. If all of them dies and we cannot get >> sponsored replacements, we cannot support the architecture any longer" >> >> (My wording) > > Yeah, but that's unfortunately one of the universal truths of this port. > I mean in theory sometimes they turn up on eBay and people try to make > them work[1]. > > It also seems true for other ports where we commonly relied on sponsors > to hand us replacements. But maybe it's only ppc64el these days, maybe > there are useful builds available for the others (including arm64 and > mips) on the market now. AFAIK we rely on sponsors for all ports. The difference is that if we eventually have to buy things ourselves, we can get mips*, arm* or x86 buildds (for example), but we can't reasonably get a s390x one. But that's not something we can change, so as long as there no other concerns, this shouldn't be a blocker. Emilio
Luidspreker herstelling
[ Is deze mail niet goed leesbaar? Klik hier voor de webversie. ](http://p.n2g11.com/l/219968491/c/0-jsla-lvykk9-voh) (http://loudspeakerrepair.com) == SERVICECENTER = == == VOOR EEN VLOTTE AFHANDELING VAN UW LUIDSPREKER HERSTELLINGEN [WWW.LOUDSPEAKERREPAIR.COM](http://loudspeakerrepair.com) = [Herstelling van alle oudere speakers](http://loudspeakerrepair.com) Vervanging rolranden [Herwikkelen spreekspoel===](http://loudspeakerrepair.com) [Herstelling luidsprekerdoek===](http://loudspeakerrepair.com) [Herstelling scheidingsfilter](http://loudspeakerrepair.com) [Op onze site http://loudspeakerrepair.com krijgt u een impressie van ons bedrijf en werkwijze](http://loudspeakerrepair.com) [Voor alle info 0476 945 785 ==](mailto:don...@telenet.be) [ 00 32 (0) 50 / 71 69 01=](mailto:don...@telenet.be) [ don...@telenet.be===](mailto:don...@telenet.be) DONNET Kruisken 16 9990 Maldegem donnet Kruisken 16 9991 Adegem België [ Nieuwsbrief opzeggen ](http://www.newsletter-abmeldung.n2g11.com/l/219968490/c/0-jsla-lvykk9-voh)
Re: [Stretch] Status for architecture qualification
On Tue, Jun 07, 2016 at 11:38:06AM -0700, Martin Michlmayr wrote: >* Steve McIntyre [2016-06-06 15:14]: >> However, I will admit (again) that armel is starting to lose upstream >> support in some cases. I'm tempted to suggest that Stretch should be >> the last release for armel for that reason. > >Which upstream problems do you see? There's a few projects that have abandoned claiming to support anything below ARMv7. The one that comes to mind most readily is libv8, but there have been others. >And do you know how long ARM/Linaro are planning to support it >upstream? *Personally* I reckon ARM are never going to stop supporting older CPUs in toolchains etc., however any new development will obviously be targeting newer v7 and v8 stuff. Linaro have never spent any time supporting pre-v7, as none of the Linaro members care about anything older than v7. Most are pushing for v8 primarily now. However, I'd predict most of the issues are going to be in other projects that neither ARM nor Linaro are working on. Now that even the Pi has moved on from v6, there's not going to be much push for supporting older CPU versions. I've had quite a few conversations with folks who are confused why we still target v4t... >I'm torn at the moment. On the one hand, we have a lot of armel users >and mainstream armel hardware was sold until fairly recently. On the >other hand, assuming LTS jessie will support armel, that might be long >enough for the hardware to get mostly (or finally :) obsolete. Yeah. As I've said, a partial architecture would be a good route here but I've not seen anybody working on such an option. >I definitely think we should make a decision one or the other way >and document it appropriately if we intend to drop armel after >stretch. Nod. -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Re: [Stretch] Status for architecture qualification
On 14/06/16 12:36, Steve McIntyre wrote: > On Tue, Jun 07, 2016 at 11:38:06AM -0700, Martin Michlmayr wrote: >> * Steve McIntyre [2016-06-06 15:14]: >>> However, I will admit (again) that armel is starting to lose upstream >>> support in some cases. I'm tempted to suggest that Stretch should be >>> the last release for armel for that reason. >> >> Which upstream problems do you see? > > There's a few projects that have abandoned claiming to support > anything below ARMv7. The one that comes to mind most readily is > libv8, but there have been others. Haskell had issues as well: https://lists.debian.org/debian-haskell/2015/11/msg00016.html Emilio
Re: [Stretch] Status for architecture qualification
On 06/14/2016 09:06 AM, Philipp Kern wrote: > Yeah, but that's unfortunately one of the universal truths of this port. > I mean in theory sometimes they turn up on eBay and people try to make > them work[1]. Hilarious talk, thanks a lot for the link :). > It also seems true for other ports where we commonly relied on sponsors > to hand us replacements. But maybe it's only ppc64el these days, maybe > there are useful builds available for the others (including arm64 and > mips) on the market now. The hardware sponsoring is the main thing that keeps us from making sparc64 an official port, I would say. The state of the port itself is great: We recently even got LibreOffice running on sparc64 (patches not yet merged) and the port is quite popular, according to popcon, sparc64 has already more users than arm64 and some of the mips ports :). If we were to add sparc64 to Debian, we could rebuild the archive within a few weeks. We have one user who has two Sun T2 servers which are new-in-box (NIB), would those be ok to set up as machines for DSA? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#827177: transition: qtbase-opensource-src
We are ready to binNMU: fcitx-qt5, gcin, hime, kdeclarative, libqtxdg, plasma- integration, qstyleplugins-src, gammaray, kwin, libfm-qt, lxqt-qtplugin, pyqt5, qtcurve and calibre. I'll ask for qt3d-opensource-src removal from unstable after I push 5.6.1 to experimental, hopefully today. qtquick1-opensource-src is going away, RM bug filled. I'll also take care of pushing qtcreator today. Thanks! -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016 at 11:36:24AM +0100, Steve McIntyre wrote: > There's a few projects that have abandoned claiming to support > anything below ARMv7. The one that comes to mind most readily is > libv8, but there have been others. I don't see libv8 on powerpc either. Don't think it has ever been there though, while it has been on armel. -- Len Sorensen
Bug#827275: release.debian.org: hint pixbros back into testing
Package: release.debian.org Severity: wishlist pixbros was removed from testing due to an RC bug. I have fixed the RC bug but it is not migrating back into testing because it is an arch all package that depends on an 32-bit-only package (fenix) that has never been available on amd64 but britney seems to want it on amd64: 11 days old (needed 10 days) pixbros/amd64 unsatisfiable Depends: fenix pixbros/amd64 unsatisfiable Depends: fenix-plugins-system Not considered -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#827177: transition: qtbase-opensource-src
Please also binNMU qtcreator, the new version needs some more maintainer time ;-) Thanks! -- SlackDeb: velo como un entrenamiento shaolin para geeks, en vez de meditación y tortura física, abstinencia de internet y sexo Horacio Francisco Sebastián "Perrito" Durán Barrionuevo, sobre un viaje que Federico "SlackDeb" Peretti estaba planeando con su novia. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#827288: jessie-pu: package audiofile/0.3.6-2
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Hi,
This update fixes CVE-2015-7747 (#801102). The security bug is marked
no-DSA, so the security team asked me to submit it as a normal stable
update.
The patch is copied directly from this Ubuntu bug (and is already
applied in Ubuntu):
https://bugs.launchpad.net/ubuntu/+source/audiofile/+bug/1502721
Thanks,
James
-- System Information:
Debian Release: stretch/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)diff -Nru audiofile-0.3.6/debian/changelog audiofile-0.3.6/debian/changelog
--- audiofile-0.3.6/debian/changelog 2016-06-14 14:21:11.0 +0100
+++ audiofile-0.3.6/debian/changelog 2016-06-14 16:39:56.0 +0100
@@ -1,3 +1,11 @@
+audiofile (0.3.6-2+deb8u1) jessie; urgency=high
+
+ * Team upload.
+ * Fix CVE-2015-7747: buffer overflow when changing both sample format and
+number of channels. (Closes: #801102)
+
+ -- James Cowgill Tue, 14 Jun 2016 16:39:49 +0100
+
audiofile (0.3.6-2) unstable; urgency=low
* Upload to unstable.
diff -Nru audiofile-0.3.6/debian/patches/CVE-2015-7747.patch audiofile-0.3.6/debian/patches/CVE-2015-7747.patch
--- audiofile-0.3.6/debian/patches/CVE-2015-7747.patch 1970-01-01 01:00:00.0 +0100
+++ audiofile-0.3.6/debian/patches/CVE-2015-7747.patch 2016-06-14 16:19:51.0 +0100
@@ -0,0 +1,161 @@
+Description: fix buffer overflow when changing both sample format and
+ number of channels
+Origin: backport, https://github.com/mpruett/audiofile/pull/25
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/audiofile/+bug/1502721
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801102
+
+Index: audiofile-0.3.6/libaudiofile/modules/ModuleState.cpp
+===
+--- audiofile-0.3.6.orig/libaudiofile/modules/ModuleState.cpp 2015-10-20 08:00:58.036128202 -0400
audiofile-0.3.6/libaudiofile/modules/ModuleState.cpp 2015-10-20 08:00:58.036128202 -0400
+@@ -402,7 +402,7 @@
+ addModule(new Transform(outfc, in.pcm, out.pcm));
+
+ if (in.channelCount != out.channelCount)
+- addModule(new ApplyChannelMatrix(infc, isReading,
++ addModule(new ApplyChannelMatrix(outfc, isReading,
+ in.channelCount, out.channelCount,
+ in.pcm.minClip, in.pcm.maxClip,
+ track->channelMatrix));
+Index: audiofile-0.3.6/test/Makefile.am
+===
+--- audiofile-0.3.6.orig/test/Makefile.am 2015-10-20 08:00:58.036128202 -0400
audiofile-0.3.6/test/Makefile.am 2015-10-20 08:00:58.036128202 -0400
+@@ -26,6 +26,7 @@
+ VirtualFile \
+ floatto24 \
+ query2 \
++ sixteen-stereo-to-eight-mono \
+ sixteen-to-eight \
+ testchannelmatrix \
+ testdouble \
+@@ -139,6 +140,7 @@
+ printmarkers_LDADD = $(LIBAUDIOFILE) -lm
+
+ sixteen_to_eight_SOURCES = sixteen-to-eight.c TestUtilities.cpp TestUtilities.h
++sixteen_stereo_to_eight_mono_SOURCES = sixteen-stereo-to-eight-mono.c TestUtilities.cpp TestUtilities.h
+
+ testchannelmatrix_SOURCES = testchannelmatrix.c TestUtilities.cpp TestUtilities.h
+
+Index: audiofile-0.3.6/test/sixteen-stereo-to-eight-mono.c
+===
+--- /dev/null 1970-01-01 00:00:00.0 +
audiofile-0.3.6/test/sixteen-stereo-to-eight-mono.c 2015-10-20 08:33:57.512286416 -0400
+@@ -0,0 +1,117 @@
++/*
++ Audio File Library
++
++ Copyright 2000, Silicon Graphics, Inc.
++
++ This program is free software; you can redistribute it and/or modify
++ it under the terms of the GNU General Public License as published by
++ the Free Software Foundation; either version 2 of the License, or
++ (at your option) any later version.
++
++ This program is distributed in the hope that it will be useful,
++ but WITHOUT ANY WARRANTY; without even the implied warranty of
++ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
++ GNU General Public License for more details.
++
++ You should have received a copy of the GNU General Public License along
++ with this program; if not, write to the Free Software Foundation, Inc.,
++ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
++*/
++
++/*
++ sixteen-stereo-to-eight-mono.c
++
++ This program tests the conversion from 2-channel 16-bit integers to
++ 1-channel 8-bit integers.
++*/
++
++#ifdef HAVE_CONFIG_H
++#include
++#endif
++
++#include
++#include
++#include
++#include
++#include
++#include
++
++#include
++
++#include "TestUtilities.h"
++
++int main (int argc, char **argv)
++{
++ AFfilehandle file;
++ AFfilesetup setup;
++ int16_t frames16[]
Bug#827291: transition: libpodofo
Package: release.debian.org Forwarded: https://release.debian.org/transitions/html/auto-libpodofo.html User: release.debian@packages.debian.org Usertags: transition I've got another libpodofo soname bump, from libpodofo0.9.3 to libpodofo0.9.4. The 3 affected packages (scribus, calibre and krename) all builds fine. calibre is currently entangled with the Qt private abi bump, and currently can't be built due to pyqt5 not being rebuilt yet. With a rebuilt pyqt5 calibre builds fine and gains dependencies on both libpodofo0.9.4 and qtbase-abi-5-6-1; that means that you either prefer to hold calibre and rebuild it only once for both transitions, or rebuild it twice; please tell me what you prefer :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#826577: marked as done (transition: qtquick1-opensource-src)
Your message dated Tue, 14 Jun 2016 19:38:40 +0200 with message-id <2b15e566-5cf8-0395-144b-fa9543a8e...@debian.org> and subject line Re: Bug#826577: transition: qtquick1-opensource-src has caused the Debian Bug report #826577, regarding transition: qtquick1-opensource-src to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 826577: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826577 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RT! With the arrival of Qt 5.6.1 we will be removing src:qtquick1-opensource-src. We have already been filing bugs against the affected packages, which should be really a few now. I would like to set up a tracker to have a proper view of the removal. I'll ask for a Qt 5.6.1 transition later. Note: I have not tried the ben file below. Thanks! Ben file: title = "qtquick1-opensource-src removal"; is_affected = (.build-depends ~ qtquick1-5-dev | .depends ~ libqt5declarative5 | .depends ~ qtquick1-5-dev-tools | .depends ~ qtquick1-5-examples | .depends ~ qtquick1-qml-plugins | .depends ~ qtquick1-qmltooling-plugins | .build-depends ~ qtdeclarative5-dev); is_good = .build-depends ~ qtdeclarative5-dev; is_bad = (.build-depends ~ qtquick1-5-dev | .depends ~ libqt5declarative5 | .depends ~ qtquick1-5-dev-tools | .depends ~ qtquick1-5-examples | .depends ~ qtquick1-qml-plugins | .depends ~ qtquick1-qmltooling-plugins); -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'buildd-unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.5.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- On 06/06/16 22:17, Emilio Pozuelo Monfort wrote: > On 06/06/16 17:16, Lisandro Damián Nicanor Pérez Meyer wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> >> Hi RT! With the arrival of Qt 5.6.1 we will be removing >> src:qtquick1-opensource-src. We have already been filing bugs against the >> affected packages, which should be really a few now. >> >> I would like to set up a tracker to have a proper view of the removal. >> I'll ask for a Qt 5.6.1 transition later. >> >> Note: I have not tried the ben file below. > > $ dak rm -Rn qtquick1-opensource-src > Will remove the following packages from unstable: > > libqt5declarative5 |5.5.1-2 | amd64, arm64, armel, armhf, hurd-i386, > i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, > ppc64el, s390x > qtquick1-5-dbg |5.5.1-2 | amd64, arm64, armel, armhf, hurd-i386, i386, > kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x > qtquick1-5-dev |5.5.1-2 | amd64, arm64, armel, armhf, hurd-i386, i386, > kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x > qtquick1-5-dev-tools |5.5.1-2 | amd64, arm64, armel, armhf, hurd-i386, > i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, > ppc64el, s390x > qtquick1-5-examples |5.5.1-2 | amd64, arm64, armel, armhf, hurd-i386, > i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, > ppc64el, s390x > qtquick1-opensource-src |5.5.1-2 | source > qtquick1-qml-plugins |5.5.1-2 | amd64, arm64, armel, armhf, hurd-i386, > i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, > ppc64el, s390x > qtquick1-qmltooling-plugins |5.5.1-2 | amd64, arm64, armel, armhf, > hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, > powerpc, ppc64el, s390x > > Maintainer: Debian Qt/KDE Maintainers > > --- Reason --- > > -- > > Checking reverse dependencies... > # Broken Build-Depends: > kadu: qtquick1-5-dev > kadu-mime-tex: qtquick1-5-dev > musescore: qtquick1-5-dev > phonon: qtquick1-5-dev > > Dependency problem found. This is being tracked in the qtbase 5.6.1 transition bug. Let's close this. Emilio--- End Message ---
Bug#821772: marked as done (transition: hunspell)
Your message dated Tue, 14 Jun 2016 19:40:56 +0200 with message-id <3940e552-b9b8-cc65-1b36-3de7297a6...@debian.org> and subject line Re: Bug#821772: transition: hunspell has caused the Debian Bug report #821772, regarding transition: hunspell to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 821772: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821772 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, new hunspell upstream release. As the time of this writing it hasn't cleared NEW, though. Upstream says: --- snip --- I bumped the soname because chunks of the exposed api were changed or deleted, but the part of the api used by anything outside of the hunspell utilities is unchanged and nearly everything in fedora at least rebuilds against it fine. trivial fix for enchant: http://bugzilla.abisource.com/show_bug.cgi?id=13772 trivial fix for libreoffice: https://gerrit.libreoffice.org/#/c/24218/ --- snip --- The enchant bug is filed as #821464. For LibreOffice I'll take care myself for this tiny patch (or more likely upload 5.1.3 rc1 which has it included) Ben file: title = "hunspell"; is_affected = .depends ~ "libhunspell-1.3-0" | .depends ~ "libhunspell-1.4-0"; is_good = .depends ~ "libhunspell-1.4-0"; is_bad = .depends ~ "libhunspell-1.3-0"; Ben will tell us but from looking in Packages I see the following source packages affected: aegisub codelite enchant firefox firefox-esr focuswriter goldendict gwaei hunspell icedove libreoffice libtext-hunspell-perl licq lokalize mudlet onboard plume-creator pyhunspell scribus sigil sonnet tea texstudio texworks I have a rebuild test of all those running right now. Regards, Rene -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 3.18.0-trunk-rpi2 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- On 16/05/16 21:21, Emilio Pozuelo Monfort wrote: > On 13/05/16 09:46, Rene Engelhard wrote: >> On Wed, May 11, 2016 at 11:53:41AM +0200, Rene Engelhard wrote: >>> Hi, >>> >>> On Wed, May 11, 2016 at 10:25:01AM +0200, Emilio Pozuelo Monfort wrote: Control: tags -1 confirmed >>> k[...] Go ahead. >>> >>> Thanks, uploaded. >> >> Now built everywhere. Could the binNMUs be scheduled? >> (if you wait for something, no big deal either, though) > > I was waiting for the rebuilds for other ongoing transitions to finish. These > are now scheduled. I removed the last rdep from testing. This is finished now. Emilio--- End Message ---
Bug#823667: marked as done (transition: poppler 0.44)
Your message dated Tue, 14 Jun 2016 19:39:23 +0200 with message-id <4b8a85ff-b9a5-d348-01af-ac5a7cf07...@debian.org> and subject line Re: Bug#823667: transition: poppler 0.42 has caused the Debian Bug report #823667, regarding transition: poppler 0.44 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 823667: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823667 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to ask a slot for a Poppler 0.42.0 transition. Currently there is Poppler 0.42.0 in experimental already. This transition impacts the existing poppler libraries in the following ways: - libpoppler57 → libpoppler60 Below it is a list of sources which are touched by the transition, and their situation, sorted by solutions: Sources that compile fine, and can be binNMU'ed: boomaga cups-filters gambas3 gdal gdcm inkscape ipe-tools libreoffice pdf2djvu pdf2htmlex popplerkit.framework texlive-bin texworks xpdf Sources that currently FTBFS: * calligra FTBFS for other reasons, not in testing already (can be ignored) Other cases: * derivations This source builds a libpoppler-based utility application which is only used during the build to generate other data, and no trace of that application are left in the resulting arch:all package. A change in poppler-glib 0.39 is the removal of an unused enum; this so far impacted only two sources: - ruby-gnome2 (#812677, fixed) - python-poppler (#812680) OTOH, this issue does not directly affect the libpoppler transition. I grouped all the bugs mentioned above (even the solved ones) with the following usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.39 https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.40 https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.42 Ben file: title = "poppler 0.42"; is_affected = .depends ~ "libpoppler57" | .depends ~ "libpoppler60"; is_good = .depends ~ "libpoppler60"; is_bad = .depends ~ "libpoppler57"; Thanks, -- Pino --- End Message --- --- Begin Message --- On 27/05/16 12:25, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 10/05/16 14:06, Emilio Pozuelo Monfort wrote: >> On 07/05/16 13:34, Pino Toscano wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> >>> Hi, >>> >>> I would like to ask a slot for a Poppler 0.42.0 transition. >>> Currently there is Poppler 0.42.0 in experimental already. >>> >>> This transition impacts the existing poppler libraries in the following >>> ways: >>> - libpoppler57 → libpoppler60 >>> >>> Below it is a list of sources which are touched by the transition, and their >>> situation, sorted by solutions: >>> >>> Sources that compile fine, and can be binNMU'ed: >>> >>> boomaga >>> cups-filters >>> gambas3 >>> gdal >>> gdcm >>> inkscape >>> ipe-tools >>> libreoffice >>> pdf2djvu >>> pdf2htmlex >>> popplerkit.framework >>> texlive-bin >>> texworks >>> xpdf >>> >>> Sources that currently FTBFS: >>> >>> * calligra >>> FTBFS for other reasons, not in testing already (can be ignored) >>> >>> Other cases: >>> >>> * derivations >>> This source builds a libpoppler-based utility application which is >>> only used during the build to generate other data, and no trace of >>> that application are left in the resulting arch:all package. >>> >>> A change in poppler-glib 0.39 is the removal of an unused enum; this so >>> far impacted only two sources: >>> - ruby-gnome2 (#812677, fixed) >>> - python-poppler (#812680) >>> OTOH, this issue does not directly affect the libpoppler transition. >>> >>> I grouped all the bugs mentioned above (even the solved ones) with the >>> following usertag: >>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.39 >>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.40 >>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.42 >> >> Let's wait for a few days until the upcoming gdal upload migrates to testing. > > Assuming there are no significant build regressions with the new version, you > can go ahead. I removed the last rdep in testing. This is done now. Cheers, Emilio--- End Message ---
Bug#821077: marked as done (transition: json-c)
Your message dated Tue, 14 Jun 2016 19:40:05 +0200 with message-id <00778d28-f840-141c-044b-78f777942...@debian.org> and subject line Re: Bug#821077: transition: json-c has caused the Debian Bug report #821077, regarding transition: json-c to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 821077: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821077 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Upstream has removed two symbols from the ABI: json_tokener_errors and mc_abort, and at least json_tokener_errors is used in at least one package, so we cannot simply ignore that. Thus I had to bump SOVERSION to 3 forcing a transition. New package has been update to experimental and is sitting in NEW. It will cause some FTBFS (two or three), but I will fix those before the transition ends. Ben file: title = "json-c"; is_affected = .depends ~ "libjson-c2" | .depends ~ "libjson-c3"; is_good = .depends ~ "libjson-c3"; is_bad = .depends ~ "libjson-c2"; -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- On 15/04/16 10:38, Ondřej Surý wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Upstream has removed two symbols from the ABI: json_tokener_errors and > mc_abort, and at least json_tokener_errors is used in at least one > package, so we cannot simply ignore that. Thus I had to bump > SOVERSION to 3 forcing a transition. > > New package has been update to experimental and is sitting in NEW. It > will cause some FTBFS (two or three), but I will fix those before the > transition ends. > > Ben file: > > title = "json-c"; > is_affected = .depends ~ "libjson-c2" | .depends ~ "libjson-c3"; > is_good = .depends ~ "libjson-c3"; > is_bad = .depends ~ "libjson-c2"; This is finished. Emilio--- End Message ---
Bug#827177: transition: qtbase-opensource-src
On 14/06/16 16:38, Lisandro Damián Nicanor Pérez Meyer wrote: > Please also binNMU qtcreator, the new version needs some more maintainer time > ;-) Thanks! All scheduled. Cheers, Emilio
Bug#826739: marked as done (transition: libconfuse)
Your message dated Tue, 14 Jun 2016 19:41:20 +0200 with message-id <9098996d-176e-b704-5e81-3a989daba...@debian.org> and subject line Re: Bug#826593: transition: confuse has caused the Debian Bug report #826593, regarding transition: libconfuse to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 826593: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826593 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi release team, looks like there was an uncoordinated library transition when libconfuse 3.0 was uploaded to unstable bumping the soname. I guess we should start binNMUing packages found by the autotracker [¹]. Regards, Michael [¹] https://release.debian.org/transitions/html/auto-confuse.html -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- On 06/06/16 22:31, Aurelien Jarno wrote: > On 2016-06-06 20:30, Emilio Pozuelo Monfort wrote: >> Control: tags -1 confirmed >> >> On 06/06/16 20:25, Aurelien Jarno wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> >>> Dear release team, >>> >>> Upstream has released a new version of confuse, which includes an ABI >>> change from libconfuse0 to libconfuse1. I have already uploaded the new >>> version to experimental, so a tracker is already available [1] to get >>> the list of reverse dependencies >>> >>> In addition I have been able to successfully build all reverse >>> dependencies against this version on amd64. I therefore do not expect >>> any particular issue with this transition. >> >> Go ahead. > > Thanks for the quick answer. I have just uploaded it to sid. This is over. Emilio--- End Message ---
Bug#826593: marked as done (transition: confuse)
Your message dated Tue, 14 Jun 2016 19:41:20 +0200 with message-id <9098996d-176e-b704-5e81-3a989daba...@debian.org> and subject line Re: Bug#826593: transition: confuse has caused the Debian Bug report #826593, regarding transition: confuse to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 826593: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826593 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear release team, Upstream has released a new version of confuse, which includes an ABI change from libconfuse0 to libconfuse1. I have already uploaded the new version to experimental, so a tracker is already available [1] to get the list of reverse dependencies In addition I have been able to successfully build all reverse dependencies against this version on amd64. I therefore do not expect any particular issue with this transition. Regards, Aurelien [1] https://release.debian.org/transitions/html/auto-confuse.html Ben file: title = "confuse"; is_affected = .depends ~ "libconfuse0" | .depends ~ "libconfuse1"; is_good = .depends ~ "libconfuse1"; is_bad = .depends ~ "libconfuse0"; -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- On 06/06/16 22:31, Aurelien Jarno wrote: > On 2016-06-06 20:30, Emilio Pozuelo Monfort wrote: >> Control: tags -1 confirmed >> >> On 06/06/16 20:25, Aurelien Jarno wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> >>> Dear release team, >>> >>> Upstream has released a new version of confuse, which includes an ABI >>> change from libconfuse0 to libconfuse1. I have already uploaded the new >>> version to experimental, so a tracker is already available [1] to get >>> the list of reverse dependencies >>> >>> In addition I have been able to successfully build all reverse >>> dependencies against this version on amd64. I therefore do not expect >>> any particular issue with this transition. >> >> Go ahead. > > Thanks for the quick answer. I have just uploaded it to sid. This is over. Emilio--- End Message ---
Bug#816389: transition: php7.0
On 01/03/16 14:19, Ondřej Surý wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi, > > this is a ben file for src:php5 to src:php7.0 transition. I tried to > remove src:php5.6, src:php5.6-json and src:php7.0 from affected list > to only track packages that depend on main packages. Can you give us a status update? Emilio
Bug#815036: transition: msgpack-c
On 25/02/16 02:28, James McCoy wrote: > On Mon, Feb 22, 2016 at 07:39:44PM +0100, Emilio Pozuelo Monfort wrote: >> Tracker at https://release.debian.org/transitions/html/msgpack-c.html > > Thanks! > >> On 21/02/16 16:54, James McCoy wrote: >>> On Wed, Feb 17, 2016 at 11:46:53PM -0500, James McCoy wrote: FTBFS: * webdis: + #811343 filed with patch * tmate: + New upstream version is needed + Will file a bug for this >>> >>> Filed #815381. >>> * kumofs: + configure script expects the C++ library (libmsgpack) and therefore fails + Trivial patch to remove that expectation leads to a compile failure due to mixing code with C and C++ linkage + No upstream activity in 5+ years + Debian maintainer MIA >>> >>> Given the above and a popcon of 5, should an RM bug be filed? >> >> Yeah I'd say so. > > #815845 filed. How is this progressing? Emilio
Bug#827291: transition: libpodofo
On 14/06/16 19:08, Mattia Rizzolo wrote: > Package: release.debian.org > Forwarded: https://release.debian.org/transitions/html/auto-libpodofo.html > User: release.debian@packages.debian.org > Usertags: transition > > I've got another libpodofo soname bump, from libpodofo0.9.3 to > libpodofo0.9.4. > > The 3 affected packages (scribus, calibre and krename) all builds fine. > > calibre is currently entangled with the Qt private abi bump, and > currently can't be built due to pyqt5 not being rebuilt yet. > With a rebuilt pyqt5 calibre builds fine and gains dependencies on both > libpodofo0.9.4 and qtbase-abi-5-6-1; that means that you either prefer > to hold calibre and rebuild it only once for both transitions, or > rebuild it twice; please tell me what you prefer :) In this case I prefer to wait (because the Qt transition can't be 'smooth'). Ping us once the Qt transition is over. Cheers, Emilio
Re: [Stretch] Status for architecture qualification
On 2016-06-14 03:06, Philipp Kern wrote: On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote: Philipp Kern: > On 2016-06-05 12:01, Niels Thykier wrote: >> * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, >>s390x >>- *No* blockers at this time from RT, DSA nor security. >>- s390, ppc64el and all arm ports have DSA concerns. > What is the current DSA concern about s390x? The concern listed as: "rely on sponsors for hardware (mild concern)" As I recall the argument went something along the lines of: "Debian cannot replace the hardware; if any of the machines dies, we need a sponsor to replace it. If all of them dies and we cannot get sponsored replacements, we cannot support the architecture any longer" (My wording) Yeah, but that's unfortunately one of the universal truths of this port. I mean in theory sometimes they turn up on eBay and people try to make them work[1]. It also seems true for other ports where we commonly relied on sponsors to hand us replacements. But maybe it's only ppc64el these days, maybe there are useful builds available for the others (including arm64 and mips) on the market now. Kind regards and thanks Philipp Kern [1] https://www.youtube.com/watch?v=45X4VP8CGtk (Here's What Happens When an 18 Year Old Buys a Mainframe) Fun story, i had a client who was considering getting their hands on a Z9, they asked me a few others to go with them to see IBM present a demo of it. Long story short the IBM guys started a job and literally started pulling CPU and Mem boards out of the machine mid job. The error log on the OS/2 maintenance laptop was going crazy, but the OS kept running the job. In other words, i don't think a s390x box will ever just die. Really interesting machines to say the least, hopefully one day i will get to play with one. The other issues with s390x is that in most cases you don't buy them. You essentially lease the CPU usage and IBM charges you based on how much CPU usage you've consumed over a given time. It makes me wonder how they ever get on eBay. IBM typically takes them back after you stop paying for it.
Bug#827299: jessie-pu: package libxml2/2.9.1+dfsg1-5+deb8u3
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Hi SRM,
It would be good to have libxml2 fixed as well in stable for #781232,
causing e.g. libsys-virt-perl FTBFS, or causing the problem for
libvirt as reported by Guido in #781232.
Attached is the proposed debdiff, by cherry-picking commit
beb7281055dbf0ed4d041022a67c6c5cfd126f25 from upstream.
Would that be accepted for the next jessie point release?
Regards,
Salvatore
diff -Nru libxml2-2.9.1+dfsg1/debian/changelog
libxml2-2.9.1+dfsg1/debian/changelog
--- libxml2-2.9.1+dfsg1/debian/changelog2016-05-28 06:58:09.0
+0200
+++ libxml2-2.9.1+dfsg1/debian/changelog2016-06-14 20:21:16.0
+0200
@@ -1,3 +1,11 @@
+libxml2 (2.9.1+dfsg1-5+deb8u3) jessie; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix a problem unparsing URIs without a host part like qemu:///system.
+This unbreaks libvirt, libsys-virt-perl and others (Closes: #781232)
+
+ -- Salvatore Bonaccorso Tue, 14 Jun 2016 20:20:41 +0200
+
libxml2 (2.9.1+dfsg1-5+deb8u2) jessie-security; urgency=high
* Non-maintainer upload by the Security Team.
diff -Nru
libxml2-2.9.1+dfsg1/debian/patches/0086-Fix-a-problem-properly-saving-URIs.patch
libxml2-2.9.1+dfsg1/debian/patches/0086-Fix-a-problem-properly-saving-URIs.patch
---
libxml2-2.9.1+dfsg1/debian/patches/0086-Fix-a-problem-properly-saving-URIs.patch
1970-01-01 01:00:00.0 +0100
+++
libxml2-2.9.1+dfsg1/debian/patches/0086-Fix-a-problem-properly-saving-URIs.patch
2016-06-14 20:21:16.0 +0200
@@ -0,0 +1,127 @@
+From beb7281055dbf0ed4d041022a67c6c5cfd126f25 Mon Sep 17 00:00:00 2001
+From: Daniel Veillard
+Date: Fri, 3 Oct 2014 19:22:39 +0800
+Subject: [PATCH] Fix a problem properly saving URIs
+
+As written by Martin Kletzander :
+Since commit 8eb55d782a2b9afacc7938694891cc6fad7b42a5, when you parse
+and save an URI that has no server (or similar) part, two slashes
+after the 'schema:' get lost. It means 'uri:///noserver' is turned
+into 'uri:/noserver'.
+
+basically
+ foo:///only/path
+
+means a host of "" while
+
+ foo:/only/path
+
+means no host at all
+
+ So the best fix IMHO is to fix the URI parser to record the first
+case and an empty host string and the second case as a NULL host string
+
+ I would not revert the initial patch, we should not 'invent' those
+slash, but we should instead when parsing keep the information that
+it's a host based path and that foo:/// means the presence of a host
+but an empty one.
+
+Once applied the resulting patch below, all cases seems to be saved
+properly:
+
+thinkpad:~/XML -> ./testURI uri:/noserver
+uri:/noserver
+thinkpad:~/XML -> ./testURI uri:///noserver
+uri:///noserver
+thinkpad:~/XML -> ./testURI uri://server/foo
+uri://server/foo
+thinkpad:~/XML -> ./testURI uri:/noserver/foo
+uri:/noserver/foo
+thinkpad:~/XML -> ./testURI uri:///
+uri:///
+thinkpad:~/XML -> ./testURI uri://
+uri://
+thinkpad:~/XML -> ./testURI uri:/
+uri:/
+thinkpad:~/XML ->
+
+ If you revert the initial patch that last case fails
+
+The problem is that I don't want to change the xmlURI structure to
+minimize ABI breakage, so I could not extend the field. The natural
+solution is to denote that uri:/// has an empty host by making
+the uri server field an empty string which works very well but breaks
+applications (like libvirt ;-) who blindly look at uri->server
+not being NULL to try to reach it !
+Simplest was to stick the port to -1 in that case, instead of 0
+application don't bother looking at the port of there is no server
+string, this makes the patch more complex than a 1 liner, but
+is better for ABI.
+---
+ uri.c | 34 +++---
+ 1 file changed, 19 insertions(+), 15 deletions(-)
+
+diff --git a/uri.c b/uri.c
+index d4dcd2f..ff47abb 100644
+--- a/uri.c
b/uri.c
+@@ -759,6 +759,8 @@ xmlParse3986HierPart(xmlURIPtr uri, const char **str)
+ cur += 2;
+ ret = xmlParse3986Authority(uri, &cur);
+ if (ret != 0) return(ret);
++ if (uri->server == NULL)
++ uri->port = -1;
+ ret = xmlParse3986PathAbEmpty(uri, &cur);
+ if (ret != 0) return(ret);
+ *str = cur;
+@@ -1106,7 +1108,7 @@ xmlSaveUri(xmlURIPtr uri) {
+ }
+ }
+ } else {
+- if (uri->server != NULL) {
++ if ((uri->server != NULL) || (uri->port == -1)) {
+ if (len + 3 >= max) {
+ temp = xmlSaveUriRealloc(ret, &max);
+ if (temp == NULL) goto mem_error;
+@@ -1143,22 +1145,24 @@ xmlSaveUri(xmlURIPtr uri) {
+ }
+ ret[len++] = '@';
+ }
+- p = uri->server;
+- while (*p != 0) {
+- if (len >= max) {
+-temp = xmlSaveUriRealloc(ret, &max);
+-if (temp == NULL) goto mem_error;
+-ret = temp;
++ if (uri->server != NULL) {
++ p = uri->server;
++
Bug#827177: transition: qtbase-opensource-src
On martes, 14 de junio de 2016 7:37:59 P. M. ART Emilio Pozuelo Monfort wrote: > On 14/06/16 16:38, Lisandro Damián Nicanor Pérez Meyer wrote: > > Please also binNMU qtcreator, the new version needs some more maintainer > > time ;-) Thanks! I *think* qtstyleplugins-src binNMUs haven't been scheduled. -- I wish to be cremated. One tenth of my ashes shall be given to my agent, as written in our contract. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#827177: transition: qtbase-opensource-src
On 14/06/16 22:31, Lisandro Damián Nicanor Pérez Meyer wrote: > On martes, 14 de junio de 2016 7:37:59 P. M. ART Emilio Pozuelo Monfort wrote: >> On 14/06/16 16:38, Lisandro Damián Nicanor Pérez Meyer wrote: >>> Please also binNMU qtcreator, the new version needs some more maintainer >>> time ;-) Thanks! > > I *think* qtstyleplugins-src binNMUs haven't been scheduled. You asked me to binNMU qstyleplugins-src! (note the missing t) :P Scheduled with the right package name now. Cheers, Emilio
Bug#815036: transition: msgpack-c
On Tue, Jun 14, 2016 at 07:43:27PM +0200, Emilio Pozuelo Monfort wrote: > On 25/02/16 02:28, James McCoy wrote: > > On Mon, Feb 22, 2016 at 07:39:44PM +0100, Emilio Pozuelo Monfort wrote: > >> On 21/02/16 16:54, James McCoy wrote: > >>> On Wed, Feb 17, 2016 at 11:46:53PM -0500, James McCoy wrote: > FTBFS: > > * webdis: > + #811343 filed with patch No action seen on this. I can try to push this upstream. The package hasn't seen any activity in almost a year (even with an upstream release in the interim). I could NMU this. > * tmate: > + New upstream version is needed > + Will file a bug for this > >>> > >>> Filed #815381. Fixed in experimental. > * kumofs: > + configure script expects the C++ library (libmsgpack) and therefore > fails > + Trivial patch to remove that expectation leads to a compile failure > due to mixing code with C and C++ linkage > + No upstream activity in 5+ years > + Debian maintainer MIA > >>> > >>> Given the above and a popcon of 5, should an RM bug be filed? > >> > >> Yeah I'd say so. > > > > #815845 filed. This has been removed from the archive. libdata-messagepack-perl has an upstream pre-release which works with the new msgpack-c. I've poked them to see if they're ready to make an official release. There's still been no reaction to my patch against libdata-messagepack-stream-perl upstream. I can poke them again. > How is this progressing? To summarize: + Will NMU webdis with my proposed patch and send it upstream + tmate is fixed in experimental + libdata-messagepack-perl has a fix upstream but no "stable" release including it + libdata-messagepack-stream-perl could be NMUed once libdata-messagepack-perl is available. Also, a new package has appeared in the interim which needs the new msgpack-c. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Uploading linux (4.6.2-1)
I intend to upload linux version 4.6.2-1 to unstable on Wednesday or Thursday. This includes a stable update and several security fixes. No ABI bump is required. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus signature.asc Description: This is a digitally signed message part
Re: [Stretch] Status for architecture qualification
On 14 June 2016 at 20:22, wrote: > On 2016-06-14 03:06, Philipp Kern wrote: >> >> On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote: >>> >>> Philipp Kern: >>> > On 2016-06-05 12:01, Niels Thykier wrote: >>> >> * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, >>> >>s390x >>> >>- *No* blockers at this time from RT, DSA nor security. >>> >>- s390, ppc64el and all arm ports have DSA concerns. >>> > What is the current DSA concern about s390x? >>> The concern listed as: "rely on sponsors for hardware (mild concern)" >>> >>> As I recall the argument went something along the lines of: >>> >>> "Debian cannot replace the hardware; if any of the machines dies, we >>> need a sponsor to replace it. If all of them dies and we cannot get >>> sponsored replacements, we cannot support the architecture any longer" >>> >>> (My wording) >> >> >> Yeah, but that's unfortunately one of the universal truths of this port. >> I mean in theory sometimes they turn up on eBay and people try to make >> them work[1]. >> >> It also seems true for other ports where we commonly relied on sponsors >> to hand us replacements. But maybe it's only ppc64el these days, maybe >> there are useful builds available for the others (including arm64 and >> mips) on the market now. >> >> Kind regards and thanks >> Philipp Kern >> >> [1] https://www.youtube.com/watch?v=45X4VP8CGtk >> (Here's What Happens When an 18 Year Old Buys a Mainframe) > > > Fun story, i had a client who was considering getting their hands on a Z9, > they asked me a few others to go with them to see IBM present a demo of it. > Long story short the IBM guys started a job and literally started pulling > CPU and Mem boards out of the machine mid job. The error log on the OS/2 > maintenance laptop was going crazy, but the OS kept running the job. > > In other words, i don't think a s390x box will ever just die. Really > interesting machines to say the least, hopefully one day i will get to play > with one. The other issues with s390x is that in most cases you don't buy > them. You essentially lease the CPU usage and IBM charges you based on how > much CPU usage you've consumed over a given time. It makes me wonder how > they ever get on eBay. IBM typically takes them back after you stop paying > for it. > In the talk he did say that for that acient machine he was offered subscription to the upgraded z/OS for some small amount of dollars a quarter. There is openmainframe project https://www.openmainframeproject.org/ , which I believe offers access to z/VM instances hosted by Marist colledge. At the openmainframeproject EU meetup, it was indicated that SUSE joined with indication that Open Build Service might be able to use resources hosted by Marist. I wonder if it makes sense to reach out, and see if there are resources available to use as porter boxes & build boxes. That way Debian might be able to get such donated resource available on ongoing basis and hopefully with some hw support. -- Regards, Dimitri.
Re: [Stretch] Status for architecture qualification
On Wed, 2016-06-15 at 01:37 +0300, Dimitri John Ledkov wrote: > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. Marist already support Debian with an s390x buildd: ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org "(sponsor=*marist*)" https://db.debian.org/machines.cgi?host=zani Our other sponsors for s390 are www.iic.kit.edu and www.zivit.de: ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org "(architecture=s390*)" sponsor -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#827177: transition: qtbase-opensource-src
On miércoles, 15 de junio de 2016 12:06:46 A. M. ART Emilio Pozuelo Monfort wrote: > On 14/06/16 22:31, Lisandro Damián Nicanor Pérez Meyer wrote: > > On martes, 14 de junio de 2016 7:37:59 P. M. ART Emilio Pozuelo Monfort wrote: > >> On 14/06/16 16:38, Lisandro Damián Nicanor Pérez Meyer wrote: > >>> Please also binNMU qtcreator, the new version needs some more maintainer > >>> time ;-) Thanks! > > > > I *think* qtstyleplugins-src binNMUs haven't been scheduled. > > You asked me to binNMU qstyleplugins-src! (note the missing t) :P Ahh, there is no doubt I'm full of typos :) Sorry for that one :) > Scheduled with the right package name now. Cool! By the way: - qtcreator: saw the FTBFS in ppc, started triaging it and upstream jumped in. Patch already available, I hope to push it tonight. - gcin, hime, gammaray: looking trough build logs, will file bugs after looking at them. -- If little green men land in your back yard, hide any little green women you've got in the house. Mike Harding, "The Armchair Anarchist's Almanac" Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#827341: transition: octomap
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, I'm filing this bug for a transition of octomap. It is in experimental. It builds on all architectures in testing, where it built previously. Ben file: title = "octomap"; is_affected = .depends ~ /\b(libdynamicedt3d1\.8|liboctomap1\.8|liboctovis1\.8|libdynamicedt3d1\.6|libdynamicedt3d1\.6\-dbg|liboctomap1\.6v5|liboctomap1\.6v5\-dbg|liboctovis1\.6v5|liboctovis1\.6v5\-dbg)\b/ is_good = .depends ~ /\b(libdynamicedt3d1\.8|liboctomap1\.8|liboctovis1\.8)\b/ is_bad = .depends ~ /\b(libdynamicedt3d1\.6|libdynamicedt3d1\.6\-dbg|liboctomap1\.6v5|liboctomap1\.6v5\-dbg|liboctovis1\.6v5|liboctovis1\.6v5\-dbg)\b/ All reverse dependencies test rebuilds. All rdepends are listed here: https://release.debian.org/transitions/html/auto-octomap.html Thanks -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.4.0-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
