Bug#766995: unblock: pnp4nagios/0.6.24+dfsg1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi release team, would you be willing to allow pnp4nagios to migrate to testing before 5th Nov? (Lower the migration time to 5 days) I finally had the time to finalize and *proper* test the package yesterday. A lot of work was required to make the package fit and up2date. The package was not in testing since 2014-04-30, but is in wheezy at the moment I'll be happy if we can ship with jessie pnp4nagios if possible. Note: I just uploaded -2 for a description fix. Thanks Markus Frosch unblock pnp4nagios/0.6.24+dfsg1-2 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141027133647.11341.17931.report...@ceronia.lazyfrosch.de
nvidia-cuda-toolkit may need some hinting?
Hi, nvidia-cuda-toolkit does not seem to migrate on its own and may need some hinting. From update_output.txt: FAILED Trying easy from autohinter: nvidia-cuda-toolkit/6.0.37-4 hwloc-contrib/1.10.0-1 eztrace-contrib/1.0.5-1 pycuda/i386/2014.1-2 pycuda/amd64/2014.1-2 leading: nvidia-cuda-toolkit,hwloc-contrib,eztrace-contrib,pycuda/i386,pycuda/amd64 start: 13+1066: i-8:a-1:a-0:a-0:k-1:k-1:m-0:m-0:p-0:s-2:a-1031:p-35 orig: 13+1066: i-8:a-1:a-0:a-0:k-1:k-1:m-0:m-0:p-0:s-2:a-1031:p-35 easy: 27+1066: i-15:a-8:a-0:a-0:k-1:k-1:m-0:m-0:p-0:s-2:a-1031:p-35 * i386: libsocl-contrib-1.1-1, libstarpu-contrib-1.1-7, libstarpu-contrib-dev, libstarpu-contribfft-1.1-1, libstarpu-contribmpi-1.1-2, starpu-contrib-examples, starpu-contrib-tools * amd64: libsocl-contrib-1.1-1, libstarpu-contrib-1.1-7, libstarpu-contrib-dev, libstarpu-contribfft-1.1-1, libstarpu-contribmpi-1.1-2, starpu-contrib-examples, starpu-contrib-tools FAILED Looks like the autohinter does not pick up starpu-contrib which had (maintainer-built) binNMUs (that look OK to me, but I may have overlooked something). (libsocl-contrib* is also built by starpu-contrib.) I also wouldn't mind some aging for nvidia-graphics-drivers. Thanks Andreas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544e56dd.6040...@debian.org
Re: nvidia-cuda-toolkit may need some hinting?
Hello, Andreas Beckmann, le Mon 27 Oct 2014 15:29:49 +0100, a écrit : nvidia-cuda-toolkit does not seem to migrate on its own and may need some hinting. I had the same question the other day. The various excuses page don't help because it's a binNMU migration issue on the libstarpu-contrib-1.1-7 package. € grep-excuses Samuel Thibault gives the right answer: starpu-contrib/i386 (1.1.3+dfsg-2 to 1.1.3+dfsg-2) ... Updated binary: starpu-contrib-tools (1.1.3+dfsg-2 to 1.1.3+dfsg-2+b1) Invalidated by dependency Not considered Depends: starpu-contrib/i386 gcc-4.8 (not considered) so it's waiting for gcc-4.8, which is not built on mips yet. Samuel -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141027145753.ga3...@type.bordeaux.inria.fr
Bug#767015: unblock: python-django/1.7.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package python-django (or reduce its waiting delay so that it migrates before the freeze). 1.7.1 is a bug fix only release that we should include. Django is a package that has many security updates and the closer to upstream we are, the easier it is to apply security patches after the release. unblock python-django/1.7.1-1 -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141027163254.10680.76271.report...@x230-buxy.home.ouaza.com
Bug#767021: unblock: volatility/2.4-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock the package volatility. This package is very important for forensics activities, allowing a full memory analysis. The current version, that adds support to Windows 8 memory dumps (and others) was released in end of August. This is a complex program and I spent time doing several tests and talking with the developers. Another point is that I needed to submit a new dependency, distorm3, to NEW and it was accepted on 2014-10-19 (I sent to NEW in 2014-09-20). I delayed the packaging because the upstream changed his site (from GitHub to another place[1]) and I had no information about this change and a new version via watch file. I uploaded the final package yesterday (Sunday) and I need one day only to get it in testing. So, please, reduce the migration time to 5 days. The package is fully tested, clean and working fine. The changelog can be viewed here[2]. Thanks a lot in advance. Regards, Eriberto [1] http://www.volatilityfoundation.org [2] http://metadata.ftp-master.debian.org/changelogs/main/v/volatility/unstable_changelog unblock volatility/2.4-1 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141027185740.17486.80724.report...@libra.gabcmt.eb.mil.br
Bug#767022: Please reduce freeze time for cloop
Package: release.debian.org
Severity: normal
Please reduce the freeze time for the package cloop.
The rationale behind this is following:
* the binary packages are harmless, i.e. no suid binaries inside, no
systemd killing init scripts or other potential trouble makers
* the package was removed from Testing because of an rc bug which was
filed against the cloop-src binary package which didn't build with
some kernel 3.10.x version on the user system (this is not even a
FTBFS problem of the source package and the kernel version in
question is history now). After my update all kernels starting with
at least 3.12 should be supported.
* I updated the package following current standards, and I also changed
the type to native (i.e. git-tracked fork with minimal deviations)
because it was simply neccessary: just take a look at the upstream
source to get the feeling, it contained an own debian subdirectory
and reused debian/changelog as upstream changelog. The old stable
version even had a directory with cruft in upstreams debian/ folder.
So I chose to finally separate the changelogs and make some other
editorial changes, and I will try to share the git repository with
the world as soon as somebody fixes
https://alioth.debian.org/scm/browser.php?group_id=30019
* this package itself has a long history and has a very low change
frequency. The upstream source changes are basically little
adaptions of the kernel module source to newer kernel versions. Apart
from the changes on Debian packaging, the few changes on the program
code were needed to solve the compiler warnings discovered with
hardening flags (which was easy since I personally wrote that
particular piece of source code back in my student times *g*).
So after all I think the package is in much better shape than it was
before.
Thanks for your cooperation,
Eduard.
$ debdiff cloop-utils_2.6.39.2-1_amd64.deb cloop-utils_3.14.1.1_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/share/doc/cloop-utils/changelog.Debian.gz
Control files: lines which differ (wdiff format)
Depends: libc6 (= [-2.3.2),-] {+2.14),+} libgcc1 (= 1:4.1.1), libstdc++6 (=
[-4.6),-] {+4.4.0),+} zlib1g (= 1:1.1.4)
Installed-Size: [-219-] {+112+}
Version: [-2.6.39.2-1-] {+3.14.1.1+}
$ debdiff cloop-src_2.6.39.2-1_all.deb cloop-src_3.14.1.1_all.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /usr/src/cloop.tar.xz
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/share/doc/cloop-src/README.Debian
-rw-r--r-- root/root /usr/share/doc/cloop-src/changelog.Debian.gz
-rw-r--r-- root/root /usr/src/cloop.tar.bz2
Control files: lines which differ (wdiff format)
Depends: module-assistant, debhelper (= 5.0.37), [-bzip2-] {+xz-utils+}
Installed-Size: [-70-] {+68+}
Version: [-2.6.39.2-1-] {+3.14.1.1+}
$ diff a/cloop-2.639 b/cloop-3.14.1.1/ -Nurd | diffstat
CHANGELOG | 89
ChangeLog | 638
+
Makefile |7
README| 12
VERSION |1
advancecomp-1.15/config.guess | 1197
--
advancecomp-1.15/config.sub | 469
++-
advfs.cc | 75
cloop.c | 54
cloop.mod.c | 89
create_compressed_fs_fast.c | 240 --
debian/README.Debian | 26
debian/changelog | 85
debian/cloop-module-_KVERS_.config| 15
debian/cloop-module-_KVERS_.postinst.modules.in | 22
debian/cloop-module-_KVERS_.postrm| 36
debian/cloop-module-_KVERS_.templates |5
debian/cloop-source.debhelper.log | 24
debian/cloop-source/usr/src/modules/cloop/CHANGELOG | 89
debian/cloop-source/usr/src/modules/cloop/Makefile| 70
Bug#767022: Please reduce freeze time for cloop
Control: tags -1 + moreinfo On Mon, 2014-10-27 at 20:14 +0100, Eduard Bloch wrote: Please reduce the freeze time for the package cloop. The rationale behind this is following: * the binary packages are harmless, i.e. no suid binaries inside, no systemd killing init scripts or other potential trouble makers * the package was removed from Testing because of an rc bug which was filed against the cloop-src binary package which didn't build with some kernel 3.10.x version on the user system (this is not even a FTBFS problem of the source package and the kernel version in question is history now). After my update all kernels starting with at least 3.12 should be supported. That removal from testing was over a year ago now. Why could the issues not have been resolved sooner than a few days before freeze? More to the point, assuming I can add up, the current upload of cloop will be eligible to migrate on the evening of November 4th anyway, which is before the freeze comes in to force. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1414440657.12825.4.ca...@adam-barratt.org.uk
Bug#767015: marked as done (unblock: python-django/1.7.1-1)
Your message dated Mon, 27 Oct 2014 20:04:59 + with message-id 1414440299.12825.2.ca...@adam-barratt.org.uk and subject line Re: Bug#767015: unblock: python-django/1.7.1-1 has caused the Debian Bug report #767015, regarding unblock: python-django/1.7.1-1 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.) -- 767015: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767015 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package python-django (or reduce its waiting delay so that it migrates before the freeze). 1.7.1 is a bug fix only release that we should include. Django is a package that has many security updates and the closer to upstream we are, the easier it is to apply security patches after the release. unblock python-django/1.7.1-1 -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- On Mon, 2014-10-27 at 17:32 +0100, Raphaël Hertzog wrote: Please unblock package python-django (or reduce its waiting delay so that it migrates before the freeze). 1.7.1 is a bug fix only release that we should include. Django is a package that has many security updates and the closer to upstream we are, the easier it is to apply security patches after the release. Aged to 7 days, as a compromise between testing time and migration. (I may not be so inclined during the freeze itself.) Regards, Adam---End Message---
Processed: Re: Bug#767022: Please reduce freeze time for cloop
Processing control commands: tags -1 + moreinfo Bug #767022 [release.debian.org] Please reduce freeze time for cloop Added tag(s) moreinfo. -- 767022: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767022 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b767022.141444066519715.transcr...@bugs.debian.org
Bug#767021: unblock: volatility/2.4-1
On Mon, 2014-10-27 at 16:57 -0200, Joao Eriberto Mota Filho wrote: Please unblock the package volatility. This package is very important for forensics activities, allowing a full memory analysis. [...] I uploaded the final package yesterday (Sunday) and I need one day only to get it in testing. So, please, reduce the migration time to 5 days. According to my maths, tonight's britney run is day one of volatility's 10 day count. Counting forward another nine days takes us to the package being eligible for migration in the evening run on the 5th, which is (just) before the freeze. Unless you plan to upload a further update to the package, I believe volatility will manage to migrate before the freeze without our intervention. Given the size of the diff, I'd personally be happier leaving that to happen. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1414442097.12825.6.ca...@adam-barratt.org.uk
Bug#767021: marked as done (unblock: volatility/2.4-1)
Your message dated Mon, 27 Oct 2014 21:42:10 +0100 with message-id 544eae22.2020...@thykier.net and subject line Re: Bug#767021: unblock: volatility/2.4-1 has caused the Debian Bug report #767021, regarding unblock: volatility/2.4-1 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.) -- 767021: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767021 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock the package volatility. This package is very important for forensics activities, allowing a full memory analysis. The current version, that adds support to Windows 8 memory dumps (and others) was released in end of August. This is a complex program and I spent time doing several tests and talking with the developers. Another point is that I needed to submit a new dependency, distorm3, to NEW and it was accepted on 2014-10-19 (I sent to NEW in 2014-09-20). I delayed the packaging because the upstream changed his site (from GitHub to another place[1]) and I had no information about this change and a new version via watch file. I uploaded the final package yesterday (Sunday) and I need one day only to get it in testing. So, please, reduce the migration time to 5 days. The package is fully tested, clean and working fine. The changelog can be viewed here[2]. Thanks a lot in advance. Regards, Eriberto [1] http://www.volatilityfoundation.org [2] http://metadata.ftp-master.debian.org/changelogs/main/v/volatility/unstable_changelog unblock volatility/2.4-1 ---End Message--- ---BeginMessage--- On 2014-10-27 21:34, Adam D. Barratt wrote: On Mon, 2014-10-27 at 16:57 -0200, Joao Eriberto Mota Filho wrote: Please unblock the package volatility. This package is very important for forensics activities, allowing a full memory analysis. [...] I uploaded the final package yesterday (Sunday) and I need one day only to get it in testing. So, please, reduce the migration time to 5 days. According to my maths, tonight's britney run is day one of volatility's 10 day count. Counting forward another nine days takes us to the package being eligible for migration in the evening run on the 5th, which is (just) before the freeze. Unless you plan to upload a further update to the package, I believe volatility will manage to migrate before the freeze without our intervention. Given the size of the diff, I'd personally be happier leaving that to happen. Regards, Adam I agree with Adam, there is no need for an unblock for the current upload. Accordingly, I will close the bug. ~Niels---End Message---
Bug#757539: Debian: apertium language pairs broken in jessie due to pcre3 update
On Wed, 2014-08-13 at 09:29 +0800, Paul Wise wrote: I don't think a proper fix is going to happen before the freeze so can we have the binNMUs so that apertium works in jessie? So it is now too late to easily fix this issue for jessie. In addition some language pairs got removed due to RC bugs being filed and the automatic removal process removing them. There are three ways forward: Have Kartik/Francis/Tino upload the latest upstream code and language pairs to unstable and unblock them for jessie. This seems unlikely. binNMU all of the relevant language pairs as initially requested, close the relevant RC bugs and unblock the binNMUed and removed packages. Remove apertium related packages from jessie entirely. It is fairly pointless to have apertium in Debian without working language pairs. Any thoughts from the Debian release team? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
