Bug#856816: unblock: openssh/1:7.4p1-7
Colin Watson: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock openssh, which I've just uploaded. This fixes two RC > bugs, and nothing else. > Hi, Looks good to me. - CC'ing KiBi for a d-i ack. Quote in full for his sake. > diff -Nru openssh-7.4p1/debian/.git-dpm openssh-7.4p1/debian/.git-dpm > --- openssh-7.4p1/debian/.git-dpm 2017-01-16 15:08:11.0 + > +++ openssh-7.4p1/debian/.git-dpm 2017-03-05 02:11:08.0 + > @@ -1,6 +1,6 @@ > # see git-dpm(1) from git-dpm package > -3f1016b4535faf6e48aa71e21569aa714a25193f > -3f1016b4535faf6e48aa71e21569aa714a25193f > +e18d2ba71e6bf009c53e65509da84b712c300471 > +e18d2ba71e6bf009c53e65509da84b712c300471 > 971a7653746a6972b907dfe0ce139c06e4a6f482 > 971a7653746a6972b907dfe0ce139c06e4a6f482 > openssh_7.4p1.orig.tar.gz > diff -Nru openssh-7.4p1/debian/NEWS openssh-7.4p1/debian/NEWS > --- openssh-7.4p1/debian/NEWS 2017-01-16 15:08:11.0 + > +++ openssh-7.4p1/debian/NEWS 2017-03-05 02:12:42.0 + > @@ -1,3 +1,15 @@ > +openssh (1:7.4p1-7) unstable; urgency=medium > + > + This version restores the default for AuthorizedKeysFile to search both > + ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2, as was the case in > + Debian configurations before 1:7.4p1-1. Upstream intends to phase out > + searching ~/.ssh/authorized_keys2 by default, so you should ensure that > + you are only using ~/.ssh/authorized_keys, at least for critical > + administrative access; do not assume that the current default will remain > + in place forever. > + > + -- Colin Watson Sun, 05 Mar 2017 02:12:42 + > + > openssh (1:7.4p1-1) unstable; urgency=medium > >OpenSSH 7.4 includes a number of changes that may affect existing > diff -Nru openssh-7.4p1/debian/changelog openssh-7.4p1/debian/changelog > --- openssh-7.4p1/debian/changelog2017-01-16 15:11:10.0 + > +++ openssh-7.4p1/debian/changelog2017-03-05 02:12:42.0 + > @@ -1,3 +1,15 @@ > +openssh (1:7.4p1-7) unstable; urgency=medium > + > + * Don't set "PermitRootLogin yes" on fresh installations (regression > +introduced in 1:7.4p1-1; closes: #852781). > + * Restore reading authorized_keys2 by default. Upstream seems to intend > +to gradually phase this out, so don't assume that this will remain the > +default forever. However, we were late in adopting the upstream > +sshd_config changes, so it makes sense to extend the grace period > +(closes: #852320). > + > + -- Colin Watson Sun, 05 Mar 2017 02:12:42 + > + > openssh (1:7.4p1-6) unstable; urgency=medium > >* Remove temporary file on exit from postinst (closes: #850275). > diff -Nru openssh-7.4p1/debian/openssh-server.templates > openssh-7.4p1/debian/openssh-server.templates > --- openssh-7.4p1/debian/openssh-server.templates 2017-01-16 > 15:08:11.0 + > +++ openssh-7.4p1/debian/openssh-server.templates 2017-03-05 > 02:11:08.0 + > @@ -1,6 +1,6 @@ > Template: openssh-server/permit-root-login > Type: boolean > -Default: false > +Default: true > _Description: Disable SSH password authentication for root? > Previous versions of openssh-server permitted logging in as root over SSH > using password authentication. The default for new installations is now > diff -Nru openssh-7.4p1/debian/patches/restore-authorized_keys2.patch > openssh-7.4p1/debian/patches/restore-authorized_keys2.patch > --- openssh-7.4p1/debian/patches/restore-authorized_keys2.patch > 1970-01-01 01:00:00.0 +0100 > +++ openssh-7.4p1/debian/patches/restore-authorized_keys2.patch > 2017-03-05 02:11:09.0 + > @@ -0,0 +1,35 @@ > +From e18d2ba71e6bf009c53e65509da84b712c300471 Mon Sep 17 00:00:00 2001 > +From: Colin Watson > +Date: Sun, 5 Mar 2017 02:02:11 + > +Subject: Restore reading authorized_keys2 by default > + > +Upstream seems to intend to gradually phase this out, so don't assume > +that this will remain the default forever. However, we were late in > +adopting the upstream sshd_config changes, so it makes sense to extend > +the grace period. > + > +Bug-Debian: https://bugs.debian.org/852320 > +Forwarded: not-needed > +Last-Update: 2017-03-05 > + > +Patch-Name: restore-authorized_keys2.patch > +--- > + sshd_config | 5 ++--- > + 1 file changed, 2 insertions(+), 3 deletions(-) > + > +diff --git a/sshd_config b/sshd_config > +index 4aea6c72..bcf3ac17 100644 > +--- a/sshd_config > b/sshd_config > +@@ -36,9 +36,8 @@ > + > + #PubkeyAuthentication yes > + > +-# The default is to check both .ssh/authorized_keys and > .ssh/authorized_keys2 > +-# but this is overridden so installations will only check > .ssh/authorized_keys > +-AuthorizedKeysFile .ssh/authorized_keys > ++# Expect .ssh/authorized_keys2 to be disregarded by default in future. > ++#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 > + > + #Authorize
Bug#856718: tellico_2.9.91-1~exp0.debian.tar.xz, 2.9.911 a.k.a 3.0beta1
Hi,
At https://mail.kde.org/pipermail/tellico-users/2016-April/001190.html
is a posting archived
which has subject Tellico 2.9.91 Released ("3.0 beta1")
Attached with that posting is a debian.tar.xz
Name: tellico_2.9.91-1~exp0.debian.tar.xz
Type: application/x-xz
Size: 10932 bytes
URL:
Now has this bugreport information about the existance of it.
I hope it helps.
At least it will help me finding back the debian.tar.xz
Groeten
Geert Stappers
--
Leven en laten leven
Bug#855398: unblock: thunar/1.6.11-1
Control: tags -1 confirmed moreinfo Yves-Alexis Perez: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Hi, this is a pre-approval/pre-upload request for Thunar. The last two > uploads (1.6.10-5 and 1.16.10-6) have included various fixes for > crashes. These fixes have been cherry-picked from upstream git, and now > there's an official release (1.6.11) included these fixes as well as > translations. > > [...] > > The diffstat might be a bit huge because of autogenerated files and > translations. I've removed those from the attached diff, which ends up with: > > 24 files changed, 8230 insertions(+), 7063 deletions(-) > > I didn't yet do the upload, so this is really a pre-approval request. > > Regards, > Please go ahead and remove the moreinfo tag once the upload has been built successfully on all relevant release architectures. Thanks, ~Niels
Bug#856697: [libreoffice-writer] libreoffice-writer missing required JRE
On Sat, Mar 04, 2017 at 07:11:23PM -0700, Tony Sultana wrote: >When I installed the libreoffice metapackage the JRE error disappeared but There is no JRE error. There is a JRE *warning*. As said, LO *does* start without a JRE. >the LLVM remained. I am troubleshooting the LLVM but I too don't think it >is related to libreoffice. Good. Regards, Rene
Bug#856826: installation-reports: Debian 8.6 installer with encrypted swap creates unusable swap logical volume
Package: installation-reports Severity: serious Justification: ? Dear Maintainer, * What led up to the situation? installing Debian 8.6 from the netinstall disk and confiuring LVM with encrypted root, swap and var logical volumes. Then, reboot as soon as the system has booted for the first time. * What exactly did you do (or not do) that was effective (or ineffective)? I've tried re-installing the system several times, deleting all of the partitions and setting everything up again from scratch. The same problem applies if you reboot immediately after booting the system for the first time. * What was the outcome of this action? the system boots the first time, and you are prompted for the swap logical volume password. Then, without making any changes, if you reboot, the system hangs with an "a start job is running" message, referring to swap. When this times out, the system boots, but with no swap disk. * What outcome did you expect instead? for the system to boot with an encrypted swap, as with Debian 7 (which I've tried on the same system, sucessfully). -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#841369: Wishlist: Change icon image for CQRLOG
Yes, it's already fixed in git version of CQRLOG. New icon is showing. Also the bigger problem should be fixed. I'm going to release new version soon. 2017-02-23 23:05 GMT+01:00 Colin Tuckley : > On 23/02/17 21:41, asciiw...@seznam.cz wrote: >> Any news regarding this issue? > > The bug is fixed upstream *but* there are problems with the upstream > change on systems that do not use Gnome. For example on KDE systems the > icon is not displayed. > > I've built a package for 2.0.4 with this fixed. > > However there is another, much bigger problem with cqrlog 2.0.4 ... > > Open SSL changes have broken the cqrlog interface to LotW and Clublog, > until this is also fixed I will not do *any* uploads of cqrlog. > > Colin > -- http://HamQTH.com/ok2cqr http://ok2cqr.com https://www.cqrlog.com/
Bug#856825: openssh-server: /usr/lib/tmpfiles.d/sshd.conf should use /run not /var/run
Package: openssh-server Version: 1:7.4p1-6 Severity: normal /usr/lib/tmpfiles.d/sshd.conf should create /run/sshd not /var/run/sshd. /var/run has been a symlink to /run for years so apps should use the canonical name.
Bug#856824: screen: /usr/lib/tmpfiles.d/screen-cleanup.conf should use /run not /var/run
Package: screen Version: 4.5.0-3 Severity: normal /usr/lib/tmpfiles.d/screen-cleanup.conf should create /run/screen not /var/run/screen. /var/run has been a symlink to /run for years so all configuration should use the canonical name.
Bug#856822: iodine: /usr/lib/tmpfiles.d/iodined.conf should use /run not /var/run
Package: iodine Version: 0.7.0-7 Severity: normal As /var/run has been a symlink to /run for a long time configuration should point to /run. /usr/lib/tmpfiles.d/iodined.conf should create /run/iodine not /var/run/iodine .
Bug#856823: mon: /usr/lib/tmpfiles.d/mon.conf should use /run not /var/run
Package: mon Version: 1.2.0-9+nmu4 Severity: normal /usr/lib/tmpfiles.d/mon.conf should create directory /run/mon not /var/run/mon.
Bug#855710: [Pkg-fonts-devel] Bug#855710: fontforge: Please provide fontforge-doc package with fontforge source package
Hi,
On Sun, 26 Feb 2017 19:42:25 +0530
Vasudev Kamath wrote:
> > I'll make a patch for it later.
Here's a patch for fontforge-doc. Could you review it, please?
> Thank you Yamane san. At the same time I would like to point out that we
> should remove fontforge-extras because same file is now shipped in
> fontforge and probably latest. I've not shipped it as part of fontforge
> to avoid conflicts, please consider this also when you are preparing
> patch :-).
fontforge-extra is another issue, IMO. Because fontforge-doc should
provide current fontforge information, so it should be the same version.
And -extras seems to be _better_ to be generated with fontforge source
package in next step.
--
Regards,
Hideki Yamane henrich @ debian.or.jp/org
http://wiki.debian.org/HidekiYamane
diff -Nru fontforge-20161005~dfsg/debian/changelog fontforge-20161005~dfsg/debian/changelog
--- fontforge-20161005~dfsg/debian/changelog 2016-11-13 00:07:51.0 +0900
+++ fontforge-20161005~dfsg/debian/changelog 2017-03-05 10:05:39.0 +0900
@@ -1,3 +1,9 @@
+fontforge (1:20161005~dfsg-5) unstable; urgency=medium
+
+ * generate fontforge-doc package (Closes: #853040, #855710)
+
+ -- Hideki Yamane Sun, 05 Mar 2017 10:05:39 +0900
+
fontforge (1:20161005~dfsg-4) unstable; urgency=medium
* Upload to unstable.
diff -Nru fontforge-20161005~dfsg/debian/control fontforge-20161005~dfsg/debian/control
--- fontforge-20161005~dfsg/debian/control 2016-11-12 21:52:15.0 +0900
+++ fontforge-20161005~dfsg/debian/control 2017-03-05 10:00:09.0 +0900
@@ -210,3 +210,14 @@
and many other formats.
.
This package contains the debugging symbols for fontforge.
+
+Package: fontforge-doc
+Architecture: all
+Depends: ${misc:Depends}
+Description: Documentation for FontForge
+ FontForge allows you to create or edit outline and bitmap fonts.
+ It is also a font format converter and can convert among PostScript
+ (ASCII & binary Type 1, some Type 3s, some Type 0s), TrueType, and
+ OpenType (Type2), CID-keyed, SVG, CFF and multiple-master fonts.
+ .
+ This package contains the documentation in HTML format.
diff -Nru fontforge-20161005~dfsg/debian/fontforge-doc.dirs fontforge-20161005~dfsg/debian/fontforge-doc.dirs
--- fontforge-20161005~dfsg/debian/fontforge-doc.dirs 1970-01-01 09:00:00.0 +0900
+++ fontforge-20161005~dfsg/debian/fontforge-doc.dirs 2017-03-05 10:03:46.0 +0900
@@ -0,0 +1 @@
+usr/share/doc/fontforge/html/
diff -Nru fontforge-20161005~dfsg/debian/fontforge-doc.install fontforge-20161005~dfsg/debian/fontforge-doc.install
--- fontforge-20161005~dfsg/debian/fontforge-doc.install 1970-01-01 09:00:00.0 +0900
+++ fontforge-20161005~dfsg/debian/fontforge-doc.install 2017-03-05 10:05:39.0 +0900
@@ -0,0 +1 @@
+html usr/share/doc/fontforge/
diff -Nru fontforge-20161005~dfsg/debian/rules fontforge-20161005~dfsg/debian/rules
--- fontforge-20161005~dfsg/debian/rules 2016-11-13 00:06:00.0 +0900
+++ fontforge-20161005~dfsg/debian/rules 2017-03-05 10:05:39.0 +0900
@@ -63,6 +63,10 @@
chmod -x \
debian/python-fontforge/usr/share/fontforge/python/gdraw/*.py
+build/fontforge-doc::
+ cp -arp $(CURDIR)/doc $(CURDIR)/debian/tmp/
+ find $(CURDIR)/debian/tmp/ -name ".gitignore" -delete
+
CDBS_BUILD_DEPENDS +=, d-shlibs
binary-post-install/$(libpkg) binary-post-install/$(devpkg):: debian/stamp-local-shlibs-$(lib)
debian/stamp-local-shlibs-$(lib): binary-install/$(libpkg) binary-install/$(devpkg)
Bug#856821: firmware-linux-nonfree: romheaders of R420_cp.bin for ati x800 xt agp gfx card in package not OK.
Package: firmware-linux-nonfree Version: 0.43 Severity: important Tags: newcomer Dear Maintainer, Copy-pasted: me@mybox:~/fw-radeon$ romheaders R420_cp.bin Image 1: PCI Expansion ROM Header: Signature: 0x (Not Ok) CPU unique data: 0x00 0x00 0x42 0x00 0xe0 0x00 0x00 0x00 0x00 0x00 0x40 0x00 0xe0 0x00 0x00 0x00 Pointer to PCI Data Structure: 0x Rom Header error occured. Bailing out. This is for the R420_cp.bin in firmware-linux-nonfree. I used another rom from 'net and though no GPU acceleration (noted disabled in dmesg), at least that one doesn't lock up my system at boot. At boot with this R420_cp.bin from firmware-linux-nonfree I get a black screen and system lockup, though X was previously working fine (no other changes) before the package's installation. Here's copy-paste for my rom from 'net for comparison: me@mybox:~/ati_ret_x800xt$ romheaders R420_cp.bin Image 1: PCI Expansion ROM Header: Signature: 0x55aa (Ok) CPU unique data: 0x40 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Pointer to PCI Data Structure: 0x0020 PCI Data Structure: Signature: 0x50434952 'PCIR' (Ok) Vendor ID: 0x1002 Device ID: 0x4a48 Vital Product Data: 0x PCI Data Structure Length: 0x0020 (32 bytes) PCI Data Structure Revision: 0x00 Class Code: 0x03 (VGA Display controller) Image Length: 0x00f1 blocks (123392 bytes) Revision Level of Code/Data: 0x Code Type: 0x01 (Open Firmware) Last-Image Flag: 0x80 (last image in rom) Reserved: 0x Platform specific data for Open Firmware compliant rom: Pointer to FCode program: 0x0040 Note: I still do NOT get GPU acceleration by any means, though using a rom that is not apparently volatile. Thank you. -- System Information: Debian Release: 8.7 APT prefers stable APT policy: (1000, 'stable'), (900, 'stable'), (50, 'unstable') Architecture: powerpc (ppc64) Kernel: Linux 3.16.0-4-powerpc64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#856820: unblock: forensics-extra/1.8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package forensics-extra. Some considerations: * This is a meta-package. * The package was already uploaded to Sid and it builds correctly as all (architecture independent). * There is a debdiff attached. * The debian/changelog says: forensics-extra (1.8) unstable; urgency=medium * debian/control: moved clamav from Depends to Recommends field in forensics-extra package. Clamav installs freshclam which can use Internet to download several signatures and also can slow down the disks. It can be inconvenient when using small computers over limited links. Thanks in advance. Regards, Eriberto diff -Nru forensics-extra-1.7/debian/changelog forensics-extra-1.8/debian/changelog --- forensics-extra-1.7/debian/changelog2017-02-27 01:21:19.0 -0300 +++ forensics-extra-1.8/debian/changelog2017-03-05 00:11:31.0 -0300 @@ -1,3 +1,13 @@ +forensics-extra (1.8) unstable; urgency=medium + + * debian/control: moved clamav from Depends to Recommends field in +forensics-extra package. Clamav installs freshclam which can use +Internet to download several signatures and also can slow down the +disks. It can be inconvenient when using small computers over limited +links. + + -- Joao Eriberto Mota Filho Sun, 05 Mar 2017 00:11:31 -0300 + forensics-extra (1.7) unstable; urgency=medium * debian/control: moved wifite, affected by pyrit (see previous changelog), diff -Nru forensics-extra-1.7/debian/control forensics-extra-1.8/debian/control --- forensics-extra-1.7/debian/control 2017-02-27 01:21:19.0 -0300 +++ forensics-extra-1.8/debian/control 2017-03-05 00:11:31.0 -0300 @@ -11,7 +11,7 @@ Package: forensics-extra Architecture: all -Recommends: pyrit, wifite +Recommends: clamav, pyrit, wifite Depends: aircrack-ng, bfbtester, binutils, @@ -20,7 +20,6 @@ bzip2, cabextract, chntpw, - clamav, cmospwd, crunch, cryptmount,
Bug#856819: Obsolete Vcs-Browser and Vcs-Git fields
Package: src:libsrtp2 Version: 2.0.0+20170123-2 Tags: patch Hi Jonas, thanks for updating the srtp package! I've attached a small patch to set Vcs-Browser and Vcs-Git fields to correct URLs. Regards, Andrey >From 4241ade5bdf46c93a962a7c13a4ca8ca2dc772bb Mon Sep 17 00:00:00 2001 From: Andrey Gursky Date: Sun, 5 Mar 2017 04:18:46 +0100 Subject: [PATCH] Set Vcs-Browser and Vcs-Git fields to the forked libsrtp2 package --- debian/control | 4 ++-- debian/control.in| 4 ++-- debian/control.in.in | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/debian/control b/debian/control index 84a8f16..abd3f96 100644 --- a/debian/control +++ b/debian/control @@ -18,8 +18,8 @@ Build-Depends: cdbs, Build-Depends-Indep: doxygen-latex Standards-Version: 3.9.8 Section: libs -Vcs-Git: https://anonscm.debian.org/git/pkg-voip/srtp.git -Vcs-Browser: https://anonscm.debian.org/git/pkg-voip/srtp.git +Vcs-Git: https://anonscm.debian.org/git/pkg-voip/libsrtp2.git +Vcs-Browser: https://anonscm.debian.org/git/pkg-voip/libsrtp2.git Homepage: https://github.com/cisco/libsrtp Package: libsrtp2-dev diff --git a/debian/control.in b/debian/control.in index 89d36a7..5c363df 100644 --- a/debian/control.in +++ b/debian/control.in @@ -7,8 +7,8 @@ Build-Depends: @cdbs@ Build-Depends-Indep: doxygen-latex Standards-Version: 3.9.8 Section: libs -Vcs-Git: https://anonscm.debian.org/git/pkg-voip/srtp.git -Vcs-Browser: https://anonscm.debian.org/git/pkg-voip/srtp.git +Vcs-Git: https://anonscm.debian.org/git/pkg-voip/libsrtp2.git +Vcs-Browser: https://anonscm.debian.org/git/pkg-voip/libsrtp2.git Homepage: https://github.com/cisco/libsrtp Package: libsrtp2-dev diff --git a/debian/control.in.in b/debian/control.in.in index 85608d4..c8a922e 100644 --- a/debian/control.in.in +++ b/debian/control.in.in @@ -7,8 +7,8 @@ Build-Depends: @cdbs@ Build-Depends-Indep: doxygen-latex Standards-Version: 3.9.8 Section: libs -Vcs-Git: https://anonscm.debian.org/git/pkg-voip/srtp.git -Vcs-Browser: https://anonscm.debian.org/git/pkg-voip/srtp.git +Vcs-Git: https://anonscm.debian.org/git/pkg-voip/libsrtp2.git +Vcs-Browser: https://anonscm.debian.org/git/pkg-voip/libsrtp2.git Homepage: https://github.com/cisco/libsrtp Package: __DEVPKGNAME__ -- 2.11.1
Bug#856818: [vim-youcompleteme] JediHTTP grants to unauthorized users modification of settings and code execution on behalf of the vim user
Package: vim-youcompleteme
Version: 0+20140207+git18be5c2-2
Severity: normal
Tags: security
X-Debbugs-CC: secur...@debian.org
This version (0+20140207+git18be5c2-2) of JediHTTP
(/usr/lib/vim-youcompleteme/ycm/server/) does not include the HMAC
mechanism. Each vim instance starts a HTTP proxy to Jedi to which
anybody on localhost can connect via TCP. Tested with Python files with
youcompleteme enabled.
For example one can run the following command as another user (httpie
for ease):
$ http -v POST 127.0.0.1:${port}/user_options @/tmp/default_settings.json
/tmp/default_settings.json based on
/usr/lib/vim-youcompleteme/ycm/server/default_settings.json.
You can change min_num_of_chars_for_completion to quickly prove that
settings have been updated.
One can also run arbitrary commands on behalf of the user. Just set
global_ycm_extra_conf to a path to a Python file and wait for the user
to exit vim.
--- System information. ---
Architecture: amd64
Kernel: Linux 3.16.0-4-amd64
Debian Release: 8.7
500 stable security.debian.org
500 stable ftp.pl.debian.org
500 oldstable ftp.pl.debian.org
50 testing security.debian.org
50 testing ftp.pl.debian.org
100 jessie-backports ftp.pl.debian.org
--- Package information. ---
Package's Depends field is empty.
Package's Recommends field is empty.
Package's Suggests field is empty.
--
Marcin Szewczyk
http://wodny.org
Bug#856817: It breaks all Korean words end of colum.
Package: libreoffice-writer Version: 1:4.3.3-2+deb8u5 Severity: important Hi, Version: 4.3.3.2 Build ID: 430m0(Build:2) Hangul is Korean alphabet that writes Korean speaking words. Each word is combination of individual Hanguls such as English words. The space or newline are separators of each word. Commercial Korean word processors understand it and handle Korean words as basic unit that composes whole sentence. If the sentence is longer than maximum column, it pushes down the last word to the following line without breaking the word's structure. LibreOffice-writer ignores cohesion of Korean word and breaks any Korean words at the end of column. Because of it writing a book or serious document demands manual formatting of each sentence, which is absurd. I give an example. Suppose there are five Korean words - AAA to EE - at the end of sentence. Position of the 2nd D in DDD exceeds maximum column width. AA BB CC, DDD EE (아주 급한 가속, 과도한 멈춤,) A Korean word proccesor handles it as below: AA BB CC, DDD EE, LibreOffice-writer breaks DDD into two wrong words "DD" and "D". AA BB CC, D DD EE, Until LibreOffice-writer fixes this outstanding problem, LibreOffice as a whole package won't be welcomed by Korean users on any operating system. I partly understand why Korean version of LibreOffice-writer in such sorry state. Firefox, Chrome have exact same problem. I think one capable developer who knows Hangul can fix it quickly. Regards, -- System Information: Debian Release: 8.2 Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libreoffice-writer depends on: ii libabw-0.1-1 0.1.0-2 ii libc6 2.23-5 ii libe-book-0.1-10.1.1-2 ii libgcc11:4.9.2-10 ii libicu52 52.1-8+deb8u4 ii libmwaw-0.3-3 0.3.1-2 ii libodfgen-0.1-10.1.1-2 ii libreoffice-base-core 1:4.3.3-2+deb8u5 ii libreoffice-core 1:4.3.3-2+deb8u5 ii librevenge-0.0-0 0.0.1-3 ii libstdc++6 4.9.2-10 ii libwpd-0.10-10 0.10.0-2+b1 ii libwpg-0.3-3 0.3.0-3 ii libwps-0.3-3 0.3.0-2 ii libxml22.9.1+dfsg1-5+deb8u1 ii uno-libs3 4.3.3-2+deb8u5 ii ure4.3.3-2+deb8u5 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages libreoffice-writer recommends: ii libreoffice-math 1:4.3.3-2+deb8u5 Versions of packages libreoffice-writer suggests: ii default-jre [java5-runtime]2:1.7-52 pn fonts-crosextra-caladea pn fonts-crosextra-carlito ii libreoffice-base 1:4.3.3-2+deb8u5 pn libreoffice-gcj ii libreoffice-java-common1:4.3.3-2+deb8u5 ii openjdk-7-jre [java5-runtime] 7u111-2.6.7-1~deb8u1 ii openjdk-8-jre [java5-runtime] 8u121-b13-3 Versions of packages libreoffice-core depends on: ii fontconfig2.11.0-6.3 ii fonts-opensymbol 2:102.6+LibO4.3.3-2+deb8u4 ii libatk1.0-0 2.14.0-1 ii libboost-date-time1.55.0 1.55.0+dfsg-3 ii libc6 2.23-5 ii libcairo2 1.14.0-2.1+deb8u1 ii libclucene-contribs1 2.3.3.4-4 ii libclucene-core1 2.3.3.4-4 ii libcmis-0.4-4 0.4.1-7 ii libcups2 1.7.5-12+devuan1.01 ii libcurl3-gnutls 7.38.0-4+deb8u5 ii libdbus-1-3 1.10.8-1+devuan1 ii libdbus-glib-1-2 0.102-1 ii libeot0 0.01-3 ii libexpat1 2.1.0-6+deb8u2 ii libexttextcat-2.0-0 3.4.4-1 ii libfontconfig12.11.0-6.3+deb8u1 ii libfreetype6 2.5.2-3+deb8u1 ii libgcc1 1:4.9.2-10 ii libgdk-pixbuf2.0-02.31.1-2+deb8u4 ii libgl1-mesa-glx [libgl1] 10.3.2-1+deb8u1 ii libglew1.10 1.10.0-3 ii libglib2.0-0 2.42.1-1+b1 ii libgltf-0.0-0 0.0.2-2 ii libglu1-mesa [libglu1]9.0.0-2 ii libgraphite2-31.3.6-1~deb8u1 ii libgtk2.0-0 2.24.25-3+deb8u1 ii libharfbuzz-icu0 0.9.35-2 ii libharfbuzz0b 1.2.7-1+b1 ii libhunspell-1.3-0 1.3.3-3 ii libhyphen02.8.8-1 ii libice6 2:1.0.9-1+b1 ii libicu52 52.1-8+deb8u4 ii libjpeg62-turbo 1:1.3.1-12 ii liblangtag1 0.5.1-3 ii liblcms2-22.6-3+b3 ii libldap-2.4-2 2.4.40+dfsg-1+deb8u2 ii libmythes-1.2-0 2:1.2.4-1 ii libneon27-gnutls 0.30.1-1 ii libnspr4 2:4.12-6 ii libnss3 2:3.26.2-1 ii libodfgen-0.1-1 0.1.1-2 ii libpango-1.0-01.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpng12-01.2.50-2+deb8u2 ii l
Bug#856816: unblock: openssh/1:7.4p1-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock openssh, which I've just uploaded. This fixes two RC bugs, and nothing else. diff -Nru openssh-7.4p1/debian/.git-dpm openssh-7.4p1/debian/.git-dpm --- openssh-7.4p1/debian/.git-dpm 2017-01-16 15:08:11.0 + +++ openssh-7.4p1/debian/.git-dpm 2017-03-05 02:11:08.0 + @@ -1,6 +1,6 @@ # see git-dpm(1) from git-dpm package -3f1016b4535faf6e48aa71e21569aa714a25193f -3f1016b4535faf6e48aa71e21569aa714a25193f +e18d2ba71e6bf009c53e65509da84b712c300471 +e18d2ba71e6bf009c53e65509da84b712c300471 971a7653746a6972b907dfe0ce139c06e4a6f482 971a7653746a6972b907dfe0ce139c06e4a6f482 openssh_7.4p1.orig.tar.gz diff -Nru openssh-7.4p1/debian/NEWS openssh-7.4p1/debian/NEWS --- openssh-7.4p1/debian/NEWS 2017-01-16 15:08:11.0 + +++ openssh-7.4p1/debian/NEWS 2017-03-05 02:12:42.0 + @@ -1,3 +1,15 @@ +openssh (1:7.4p1-7) unstable; urgency=medium + + This version restores the default for AuthorizedKeysFile to search both + ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2, as was the case in + Debian configurations before 1:7.4p1-1. Upstream intends to phase out + searching ~/.ssh/authorized_keys2 by default, so you should ensure that + you are only using ~/.ssh/authorized_keys, at least for critical + administrative access; do not assume that the current default will remain + in place forever. + + -- Colin Watson Sun, 05 Mar 2017 02:12:42 + + openssh (1:7.4p1-1) unstable; urgency=medium OpenSSH 7.4 includes a number of changes that may affect existing diff -Nru openssh-7.4p1/debian/changelog openssh-7.4p1/debian/changelog --- openssh-7.4p1/debian/changelog 2017-01-16 15:11:10.0 + +++ openssh-7.4p1/debian/changelog 2017-03-05 02:12:42.0 + @@ -1,3 +1,15 @@ +openssh (1:7.4p1-7) unstable; urgency=medium + + * Don't set "PermitRootLogin yes" on fresh installations (regression +introduced in 1:7.4p1-1; closes: #852781). + * Restore reading authorized_keys2 by default. Upstream seems to intend +to gradually phase this out, so don't assume that this will remain the +default forever. However, we were late in adopting the upstream +sshd_config changes, so it makes sense to extend the grace period +(closes: #852320). + + -- Colin Watson Sun, 05 Mar 2017 02:12:42 + + openssh (1:7.4p1-6) unstable; urgency=medium * Remove temporary file on exit from postinst (closes: #850275). diff -Nru openssh-7.4p1/debian/openssh-server.templates openssh-7.4p1/debian/openssh-server.templates --- openssh-7.4p1/debian/openssh-server.templates 2017-01-16 15:08:11.0 + +++ openssh-7.4p1/debian/openssh-server.templates 2017-03-05 02:11:08.0 + @@ -1,6 +1,6 @@ Template: openssh-server/permit-root-login Type: boolean -Default: false +Default: true _Description: Disable SSH password authentication for root? Previous versions of openssh-server permitted logging in as root over SSH using password authentication. The default for new installations is now diff -Nru openssh-7.4p1/debian/patches/restore-authorized_keys2.patch openssh-7.4p1/debian/patches/restore-authorized_keys2.patch --- openssh-7.4p1/debian/patches/restore-authorized_keys2.patch 1970-01-01 01:00:00.0 +0100 +++ openssh-7.4p1/debian/patches/restore-authorized_keys2.patch 2017-03-05 02:11:09.0 + @@ -0,0 +1,35 @@ +From e18d2ba71e6bf009c53e65509da84b712c300471 Mon Sep 17 00:00:00 2001 +From: Colin Watson +Date: Sun, 5 Mar 2017 02:02:11 + +Subject: Restore reading authorized_keys2 by default + +Upstream seems to intend to gradually phase this out, so don't assume +that this will remain the default forever. However, we were late in +adopting the upstream sshd_config changes, so it makes sense to extend +the grace period. + +Bug-Debian: https://bugs.debian.org/852320 +Forwarded: not-needed +Last-Update: 2017-03-05 + +Patch-Name: restore-authorized_keys2.patch +--- + sshd_config | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +diff --git a/sshd_config b/sshd_config +index 4aea6c72..bcf3ac17 100644 +--- a/sshd_config b/sshd_config +@@ -36,9 +36,8 @@ + + #PubkeyAuthentication yes + +-# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 +-# but this is overridden so installations will only check .ssh/authorized_keys +-AuthorizedKeysFile.ssh/authorized_keys ++# Expect .ssh/authorized_keys2 to be disregarded by default in future. ++#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 + + #AuthorizedPrincipalsFile none + diff -Nru openssh-7.4p1/debian/patches/series openssh-7.4p1/debian/patches/series --- openssh-7.4p1/debian/patches/series 2017-01-16 15:08:11.0 + +++ openssh-7.4p1/debian/patches/series 2017-03-05 02:11:08.0 + @@ -29,3 +29,4 @@ regress-mktemp.patch sandbox-x32-workaroun
Bug#856697: [libreoffice-writer] libreoffice-writer missing required JRE
When I installed the libreoffice metapackage the JRE error disappeared but the LLVM remained. I am troubleshooting the LLVM but I too don't think it is related to libreoffice. Thanks. Tony On Sat, Mar 4, 2017 at 12:36 AM, Rene Engelhard wrote: > Hi, > > On Sat, Mar 04, 2017 at 08:22:41AM +0100, Rene Engelhard wrote: > > > This is the same behavior when running localc, loimpress, lodraw and > > > lomath. If you install the libreoffice metapackage then it will > install > > > JRE. > > > > This is intended. Only stuff really needing it (and the metapackage) > depends > > on a JRE. > > And some packages which might or might not want to use Java-based features > have (e.g. as here in writer) Recommends or Suggests on it: > > Package: libreoffice-writer > Architecture: amd64 > Version: 1:5.2.5-2 > Priority: optional > Section: editors > Source: libreoffice > Maintainer: Debian LibreOffice Maintainers debian.org> > Installed-Size: 26106 > Pre-Depends: dpkg (>= 1.17.13) > Depends: libreoffice-base-core (= 1:5.2.5-2), libreoffice-core (= > 1:5.2.5-2), libabw-0.1-1, libc6 (>= 2.14), libe-book-0.1-1, > libetonyek-0.1-1, libgcc1 (>= 1:3.0), libicu57 (>= 57.1-1~), libmwaw-0.3-3, > libodfgen-0.1-1, librevenge-0.0-0, libstdc++6 (>= 5.2), libwpd-0.10-10, > libwpg-0.3-3, libwps-0.4-4, libxml2 (>= 2.7.4), uno-libs3 (>= 5.1.0~alpha), > ure, zlib1g (>= 1:1.1.4) > Recommends: libreoffice-math > Suggests: fonts-crosextra-caladea, fonts-crosextra-carlito, > libreoffice-base, libreoffice-gcj, libreoffice-java-common (>= 1:5.2.5~), > default-jre | openjdk-8-jre | openjdk-7-jre | openjdk-6-jre | gcj-jre | > sun-java5-jre | sun-java6-jre | java5-runtime | jre > > > ^^^ > Replaces: libreoffice-core (<< 1:3.3.2-5) > Filename: ./libreoffice-writer_5.2.5-2_amd64.deb > Size: 7584068 > MD5sum: 9a4d173abd074b858ff0dbbd1bb57d5f > SHA1: a4f122d56635ac6032d9c62db203d0321dcc460d > SHA256: f73b1826ef1553cbb2a604bead421f97774780d03ab576091752c5e1637ba482 > SHA512: c1f8c99a0a62dd6b1d2ebf3011f1b8c462811c93876dbbf790cd5f2e > a641b8b63f3fc4ae90846b2f89e1c219de932eb99fdcff09d949cec8a550fc1905d5 > Homepage: http://www.libreoffice.org > Description-en: office productivity suite -- word processor > LibreOffice is a full-featured office productivity suite that provides > a near drop-in replacement for Microsoft(R) Office. > . > This package contains the wordprocessor component for LibreOffice. > Description-md5: 7ddf1a7be67dc22b315f212f564325e8 > > Just tried it again, and indeed it works here. Current stretch. No idea > what you did which involves LLVM and/or enable-value-profiling but THAT is > probably your issue. > > Regards, > > Rene >
Bug#856815: kodi FTBFS on Alpha due to Intel assembler that is easily worked around
Source: kodi
Version: 2:17.0+dfsg1-3
Severity: wishlist
Tags: patch
User: debian-al...@lists.debian.org
Usertags: alpha
kodi FTBFS on alpha due to Intel specific code [1].
I attach a patch that enables generic code to be built rather
than Intel specific code and with that kodi builds to completion
on Alpha.
Cheers
Michael.
[1]
https://buildd.debian.org/status/fetch.php?pkg=kodi&arch=alpha&ver=2%3A17.0%2Bdfsg1-3&stamp=1487892844&raw=0
Index: kodi-17.0+dfsg1/xbmc/cores/DllLoader/DllLoader.h
===
--- kodi-17.0+dfsg1.orig/xbmc/cores/DllLoader/DllLoader.h
+++ kodi-17.0+dfsg1/xbmc/cores/DllLoader/DllLoader.h
@@ -23,7 +23,7 @@
#include "coffldr.h"
#include "LibraryLoader.h"
-#if defined(__linux__) && !defined(__powerpc__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && !defined(__s390x__)
+#if defined(__linux__) && !defined(__powerpc__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && !defined(__s390x__) && !defined(__alpha__)
#define USE_LDT_KEEPER
#include "ldt_keeper.h"
#endif
Index: kodi-17.0+dfsg1/xbmc/cores/DllLoader/ldt_keeper.c
===
--- kodi-17.0+dfsg1.orig/xbmc/cores/DllLoader/ldt_keeper.c
+++ kodi-17.0+dfsg1/xbmc/cores/DllLoader/ldt_keeper.c
@@ -19,7 +19,7 @@
*/
//#ifndef __powerpc__
-#if !defined(__powerpc__) && !defined(__ppc__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && !defined(__s390x__)
+#if !defined(__powerpc__) && !defined(__ppc__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && !defined(__s390x__) && !defined(__alpha__)
#include "ldt_keeper.h"
Index: kodi-17.0+dfsg1/xbmc/cores/VideoPlayer/VideoRenderers/LinuxRendererGL.h
===
--- kodi-17.0+dfsg1.orig/xbmc/cores/VideoPlayer/VideoRenderers/LinuxRendererGL.h
+++ kodi-17.0+dfsg1/xbmc/cores/VideoPlayer/VideoRenderers/LinuxRendererGL.h
@@ -293,7 +293,7 @@ protected:
inline int NP2( unsigned x ) {
-#if defined(TARGET_POSIX) && !defined(__POWERPC__) && !defined(__PPC__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && !defined(__s390x__)
+#if defined(TARGET_POSIX) && !defined(__POWERPC__) && !defined(__PPC__) && !defined(__arm__) && !defined(__aarch64__) && !defined(__mips__) && !defined(__s390x__) && !defined(__alpha__)
// If there are any issues compiling this, just append a ' && 0'
// to the above to make it '#if defined(TARGET_POSIX) && 0'
Index: kodi-17.0+dfsg1/xbmc/threads/Atomics.cpp
===
--- kodi-17.0+dfsg1.orig/xbmc/threads/Atomics.cpp
+++ kodi-17.0+dfsg1/xbmc/threads/Atomics.cpp
@@ -106,7 +106,7 @@ long cas(volatile long *pAddr, long expe
///
long long cas2(volatile long long* pAddr, long long expectedVal, long long swapVal)
{
-#if defined(__ppc__) || defined(__powerpc__) || defined(__arm__) || defined(__aarch64__) || defined(__s390x__) // PowerPC and ARM
+#if defined(__ppc__) || defined(__powerpc__) || defined(__arm__) || defined(__aarch64__) || defined(__s390x__) || defined(__alpha__)// PowerPC and ARM
// Not available/required
// Hack to allow compilation
throw "cas2 is not implemented";
Index: kodi-17.0+dfsg1/xbmc/threads/Atomics.h
===
--- kodi-17.0+dfsg1.orig/xbmc/threads/Atomics.h
+++ kodi-17.0+dfsg1/xbmc/threads/Atomics.h
@@ -22,7 +22,7 @@
//! @todo Inline these methods
long cas(volatile long *pAddr, long expectedVal, long swapVal);
-#if !defined(__ppc__) && !defined(__powerpc__) && !defined(__arm__) && !defined(__s390x__)
+#if !defined(__ppc__) && !defined(__powerpc__) && !defined(__arm__) && !defined(__s390x__) && !defined(__alpha__)
long long cas2(volatile long long* pAddr, long long expectedVal, long long swapVal);
#endif
long AtomicIncrement(volatile long* pAddr);
Index: kodi-17.0+dfsg1/xbmc/utils/MathUtils.h
===
--- kodi-17.0+dfsg1.orig/xbmc/utils/MathUtils.h
+++ kodi-17.0+dfsg1/xbmc/utils/MathUtils.h
@@ -37,7 +37,8 @@
defined(__mips__) || \
defined(__arm__) || \
defined(__s390x__) || \
-defined(__aarch64__)
+defined(__aarch64__) || \
+defined(__alpha__)
#define DISABLE_MATHUTILS_ASM_ROUND_INT
#endif
Bug#856814: Package trash-cli needs to be updated with newest version
Package: trash-cli Version: 0.12.9.14-2 Package's webpage: https://packages.debian.org/jessie/trash-cli The package trash-cli in Debian is outdated and contains multiple bugs that has been fixed with the latest version 0.17.1.14. The new version should replace the one in Debian.
Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, 2017-03-04 at 17:39 -0700, Sean Whitton wrote: > Dear Svante, > > On Sun, Mar 05, 2017 at 12:59:34AM +0100, Svante Signell wrote: > > > The security issues that I have raised. > > > > Which security issues? Please let me know (links please), so I can > > check them out. I really do take this seriously. On the other hand, > > are > > there any security issues with libpoppler known? > > I'm not referring to currently known security issues. I'm referring > to issues that are yet to be discovered. OK, got it. Are you still interested to sponsor this package, now when you know about status quo? If so, I'll create an account at alioth.debian.org and we'll continue from there. Just a sidenote: I've been using xpdf myself for many years, and found it a nice piece of standalone software. I'd really be sad to see it disappear from Debian. My search for good alternatives has not been successful so far. One issue is that I don't need is to edit the pdf. I don't even know if xpdf supports that? Thanks a lot for your interest :)
Bug#856652: RFS: xpdf/3.0.4.real-4
Dear Svante, On Sun, Mar 05, 2017 at 12:59:34AM +0100, Svante Signell wrote: > > The security issues that I have raised. > > Which security issues? Please let me know (links please), so I can > check them out. I really do take this seriously. On the other hand, are > there any security issues with libpoppler known? I'm not referring to currently known security issues. I'm referring to issues that are yet to be discovered. -- Sean Whitton signature.asc Description: PGP signature
Bug#856813: pidgin: AIM accounts will require 2.12 as of 2017-03-28
Package: pidgin Version: 2.11.0-3 Severity: normal Dear Maintainer, As has been reported on various tech-news sites, AOL is dropping support for older versions of the authentication methods which third-party clients such as Pidgin use to connect to the AOL Instant Messenger service. This dropping of support is scheduled to take effect on March 28th, well before the expected release of Debian stretch. The official word from upstream is that version 2.12 of Pidgin will include support for the newer authentication methods involved, and that this version is due for release in about a week. To release Debian stretch with a version of Pidgin which no longer supports connecting to one of the major instant-messaging networks, despite a version which does still support that being available, would obviously be undesirable. However, as we are already within the release freeze, including the fix is not as straightforward as simply packaging the new upstream version directly after its release. Please take whatever measures are appropriate to ensure that a version of pidgin which supports the new required authentication mode for AIM either ships with Debian stretch, or is available to users of stretch as promptly as possible after the release occurs. If such a version can be available (even if from another repository) to users of testing in the meantime, that would be even better. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages pidgin depends on: ii libatk1.0-0 2.22.0-1 ii libc6 2.24-9 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.16-1 ii libdbus-glib-1-20.108-2 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype62.6.3-3+b2 ii libgadu31:1.12.1-4 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-02.50.3-1 ii libgstreamer1.0-0 1.10.3-1 ii libgtk2.0-0 2.24.31-2 ii libgtkspell02.0.16-1.1 ii libice6 2:1.0.9-1+b1 ii libpango-1.0-0 1.40.3-3 ii libpangocairo-1.0-0 1.40.3-3 ii libpangoft2-1.0-0 1.40.3-3 ii libpurple0 2.11.0-3 ii libsm6 2:1.2.2-1+b1 ii libx11-62:1.6.4-3 ii libxss1 1:1.2.2-1 ii perl-base [perlapi-5.24.1] 5.24.1-1 ii pidgin-data 2.11.0-3 Versions of packages pidgin recommends: ii gstreamer1.0-alsa 1.10.3-1 ii gstreamer1.0-libav 1.10.3-1 ii gstreamer1.0-plugins-base 1.10.3-1 ii gstreamer1.0-plugins-good 1.10.3-1 Versions of packages pidgin suggests: ii libsqlite3-0 3.16.2-2 -- debconf-show failed
Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, 2017-03-04 at 16:50 -0700, Sean Whitton wrote: > On Sat, Mar 04, 2017 at 11:13:53PM +0100, Svante Signell wrote: > > OK, including the real upstream tarball solves that issue, right? > > It wouldn't, since the sources of hello.pdf are not included in that > tarball (apparently). On the contrary, they are present in the upstream tarball, but not in the debian *.orig* version. > > (Sorry, I don't really see the problem with me wanting to adopt the > > (real) xpdf package?) > > The security issues that I have raised. Which security issues? Please let me know (links please), so I can check them out. I really do take this seriously. On the other hand, are there any security issues with libpoppler known?
Bug#856698: (no subject)
Also, how many files and directories do you have under /etc/letsencrypt/archive? find /etc/letsencrypt/archive | wc -l ls /etc/letsencrypt/archive | wc -l There is a known issue with Certbot performing poorly when many old certificates are present.
Bug#785658: O: xscavenger -- A lode-runner-like platform game for X
Hi David, Mattia Rizzolo wrote: > On Mon, May 18, 2015 at 08:05:46PM +, David Ashley wrote: > > I am the original author for the game and have tried to contact the > > maintainer (Hwei Sheng Teoh hst...@debian.org) multiple times to > > notify him of sound related bugfixes that are available for > > longstanding issues (on the order of 10 years old). > > Right now I'm not seeing any relevant bug open against the package, Exactly. And the maintainer is obviously active as he did an upload last month: https://packages.qa.debian.org/x/xscavenger/news/20170216T192022Z.html And that's not the first one since this bug report was filed. > which should be the main point of contact for requests about a package. > Did you open any bug that got wrongly closed or something? If that's not the case, please file one bug report per issue as proper bug reports against xscavenger instead of mailing the maintainer directly. Direct mails can get forgotten or lost. Proper bug reports to the Bug Tracking System don't get lost. From this (IMHO inappropriate) bug report it's totally unclear what the actual issues are, so even reassigning it against xscavenger wouldn't really help. Cc'ing Hwei Sheng Teoh to make him aware of this bug report. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, Mar 04, 2017 at 11:13:53PM +0100, Svante Signell wrote: > OK, including the real upstream tarball solves that issue, right? It wouldn't, since the sources of hello.pdf are not included in that tarball (apparently). > (Sorry, I don't really see the problem with me wanting to adopt the > (real) xpdf package?) The security issues that I have raised. -- Sean Whitton signature.asc Description: PGP signature
Bug#856812: unblock: wolf4sdl/1.7+svn262+dfsg1-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package wolf4sdl. The version I uploaded today has a minimal change to fix a piuparts error (if you install wolf4sdl in jessie, remove it without purging it, upgrade to stretch, and install current stretch wolf4sdl, the second installation fails). unblock wolf4sdl/1.7+svn262+dfsg1-4 Thanks, S diffstat for wolf4sdl-1.7+svn262+dfsg1 wolf4sdl-1.7+svn262+dfsg1 changelog| 10 ++ wolf4sdl.preinst |3 ++- 2 files changed, 12 insertions(+), 1 deletion(-) diff -Nru wolf4sdl-1.7+svn262+dfsg1/debian/changelog wolf4sdl-1.7+svn262+dfsg1/debian/changelog --- wolf4sdl-1.7+svn262+dfsg1/debian/changelog 2015-05-05 08:19:18.0 +0100 +++ wolf4sdl-1.7+svn262+dfsg1/debian/changelog 2017-03-04 17:25:10.0 + @@ -1,3 +1,13 @@ +wolf4sdl (1.7+svn262+dfsg1-4) unstable; urgency=medium + + * Team upload. + * Only remove the alternative for /usr/games/wolf4sdl if it exists. +This fixes the following sequence: install wolf4sdl in jessie, +remove (but do not purge) wolf4sdl, upgrade from jessie to stretch, +and install wolf4sdl again. (Closes: #856722) + + -- Simon McVittie Sat, 04 Mar 2017 17:25:10 + + wolf4sdl (1.7+svn262+dfsg1-3) unstable; urgency=low * Enable parallel builds (Closes: #724522). diff -Nru wolf4sdl-1.7+svn262+dfsg1/debian/wolf4sdl.preinst wolf4sdl-1.7+svn262+dfsg1/debian/wolf4sdl.preinst --- wolf4sdl-1.7+svn262+dfsg1/debian/wolf4sdl.preinst 2015-05-05 08:13:58.0 +0100 +++ wolf4sdl-1.7+svn262+dfsg1/debian/wolf4sdl.preinst 2017-03-04 17:25:10.0 + @@ -3,7 +3,8 @@ if [ "$1" = "install" ] || [ "$1" = "upgrade" ] then - if dpkg --compare-versions "$2" lt-nl "1.7+svn262+dfsg1-3~" + if dpkg --compare-versions "$2" lt-nl "1.7+svn262+dfsg1-3~" && \ + [ -L /etc/alternatives/wolf4sdl ] then update-alternatives --quiet --remove-all wolf4sdl fi
Bug#856811: libsane: USB Scanner doesn't work after update to stretch
Package: libsane Version: 1.0.26~git20151121-1 Severity: important Dear Maintainer, I have a Fujitsu ScanSnap ix500. It works fine on my laptop running jessie. It does not work on my workstation running stretch. I've tried to install die Version from experimenatal as well, it does not work there as well. I asked for help here already: https://superuser.com/questions/1152274/i-o-error-on-xsane-frontend-but-not-on-std-out I already posted a related bug issue here: https://alioth.debian.org/tracker/?func=detail&atid=410366&aid=315564&group_id=30186 I am pretty certain it had worked on my workstation in November, but as I use the scanner only ocassionally it could be that I was using my Laptop then and forgot. My current status is even worse that what I had described in the linked elements above. At the moment I can not detect the scanner in any way on my stretch workstation. When I run lsusb it outputs: Bus 002 Device 002: ID 04c5:132b Fujitsu, Ltd Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 005: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / D-Link DUB-H4 USB 2.0 Hub Bus 001 Device 004: ID 040d:6204 VIA Technologies, Inc. Bus 001 Device 003: ID 046d:c03e Logitech, Inc. Premium Optical Wheel Mouse (M-BT58) Bus 001 Device 002: ID 046d:c30e Logitech, Inc. UltraX Keyboard (Y-BL49) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub That first entry is the Scanner. When I run sane-find-scanner it outputs: # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. # No SCSI scanners found. If you expected something different, make sure that # you have loaded a kernel SCSI driver for your SCSI adapter. # No USB scanners found. If you expected something different, make sure that # you have loaded a kernel driver for your USB host controller and have setup # the USB system correctly. See man sane-usb for details. # SANE has been built without libusb support. This may be a reason # for not detecting USB scanners. Read README for more details. # Not checking for parallel port scanners. # Most Scanners connected to the parallel port or other proprietary ports # can't be detected by this program. When I run sane-find-scanner on my jessie (without the scanner plugged it) it does not say "SANE has been built without libusb support." So, I assume that currently Debian-SANE cannot read from USB scanners? If not, then the message should be different. I don't have any more debugging info to share at the moment, but I can run any command that could yield more info if required. Have a nice day Ben Fuchs -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/8 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: sysvinit (via /sbin/init) Versions of packages libsane depends on: ii acl2.2.52-3+b1 ii adduser3.115 ii libavahi-client3 0.6.32-2 ii libavahi-common3 0.6.32-2 ii libc6 2.24-9 ii libexif12 0.6.21-2 ii libgphoto2-6 2.5.12-1 ii libgphoto2-port12 2.5.12-1 ii libieee1284-3 0.2.11-13 ii libjpeg62-turbo1:1.5.1-2 ii libsane-common 1.0.26~git20151121-1 ii libtiff5 4.0.7-5 ii libusb-1.0-0 2:1.0.21-1 ii udev 232-18 Versions of packages libsane recommends: ii libsane-extras 1.0.22.4 ii sane-utils 1.0.26~git20151121-1 Versions of packages libsane suggests: ii avahi-daemon 0.6.32-2 pn hplip -- no debconf information
Bug#856728: opentyrian: When run via menu the game silently exits if data is missing
On Sat, 04 Mar 2017 at 20:29:05 +0100, Alexandre Detiste wrote: > I had a patch for this that was proposed upstream, > then I completely forgot about it: > > https://bitbucket.org/opentyrian/opentyrian/pull-requests/6/display-dialog-box-if-files-are-missing/diff > > This could be reworked & simplified for Debian only. Freeze exception requested, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856810 On Sat, 04 Mar 2017 at 22:00:09 +0100, Andrej Mernik wrote: > I was actually thinking more that the post installer would run game-data- > packager if the user clicks yes. Sorry, that isn't possible for several reasons. game-data-packager is currently a CLI rather than interactive, and needs to be told where to find data as command-line arguments. If it was interactive (we want it to be a GUI eventually), then it would still be unsuitable to run from packages' maintainer scripts because GUIs should never run as root, because package installation while offline should work, and because maintainer scripts run with the dpkg lock held (so additional package installations are impossible). The long-term solution is likely to be putting a "launcher" wrapper in opentyrian's menu entry, which would run the real engine if everything is available, or launch the hypothetical future game-data-packager GUI if data files are missing. Several games (e.g. quake) already have a wrapper like this, although so far it just shows an error message, because turning game-data-packager into an interactive GUI is going to be a lot of work. S
Bug#856804: latex-cjk-common: Small typo in copyright file
Thanks Hilmar! Update coming up. Regards On 5 Mar 2017 03:22, "Hilmar Preuße" wrote: > Package: latex-cjk-common > Version: 4.8.4+git20150701-2 > Severity: minor > > > It was downloaded from > http://cjk.ffii.org/cjk-current.tar.gz > > And the project homepage is > http://cjk.ffi.org/ > > > Project homepage is too http://cjk.ffi.org/ . > > Hilmar > > > > -- System Information: > Debian Release: 8.7 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.16.0-4-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 > Init: systemd (via /run/systemd/system) > >
Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, 2017-03-04 at 14:01 -0600, Jason Crain wrote: > On Sat, Mar 04, 2017 at 08:19:43PM +0100, Svante Signell wrote: > > And BTW: poppler upstream seems to be freedesktop.org, i.e. gnome. > > Who > > can trust gnome nowadays, especially people preferring systemd-free > > software? > > Sniping at GNOME aside, freedesktop.org is independent from GNOME, > and > poppler's lead maintainer is a KDE developer. Nice to know, thanks:) As a sidenote: KDE is also a victim of systemd, no improvement wrt free software choice for the user here...
Bug#856810: unblock (pre-approval): opentyrian/2.1.20130907+dfsg-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
opentyrian (contrib) uses game-data-packager to package its data files
(which are freely downloadable but proprietary, and not under a
sufficiently clear license for non-free). If launched without those data
files, at the moment it silently exits, making users think it has crashed
(#856728, 'important' severity, which I think is proportionate).
Alexandre Detiste has contributed a patch to make opentyrian pop up an
error message using one of several xmessage clones. Would that be OK for
a stretch unblock?
Proposed debdiff attached.
S
diffstat for opentyrian-2.1.20130907+dfsg opentyrian-2.1.20130907+dfsg
changelog | 17 +++
control |6 ++--
copyright |2 -
patches/gdp.patch | 81 ++
patches/series|1
5 files changed, 104 insertions(+), 3 deletions(-)
diff -Nru opentyrian-2.1.20130907+dfsg/debian/changelog opentyrian-2.1.20130907+dfsg/debian/changelog
--- opentyrian-2.1.20130907+dfsg/debian/changelog 2015-04-02 17:20:57.0 +0100
+++ opentyrian-2.1.20130907+dfsg/debian/changelog 2017-03-04 22:36:42.0 +
@@ -1,3 +1,20 @@
+opentyrian (2.1.20130907+dfsg-2) unstable; urgency=medium
+
+ * Team upload.
+
+ [ Alexandre Detiste ]
+ * Display an error message when data is missing (Closes: #856728)
+ * Exit gracefully after displaying that error, in particular resetting
+the screen resolution if running fullscreen in X11
+ * Use HTTPS for Vcs-* URLs
+ * Update years in Etienne Millon's packaging copyright
+
+ [ Simon McVittie ]
+ * Add Suggests on the programs used to display the message
+ * Add DEP-3 metadata to Alexandre's patch
+
+ -- Simon McVittie Sat, 04 Mar 2017 22:36:42 +
+
opentyrian (2.1.20130907+dfsg-1) unstable; urgency=low
* Initial release (Closes: #553035)
diff -Nru opentyrian-2.1.20130907+dfsg/debian/control opentyrian-2.1.20130907+dfsg/debian/control
--- opentyrian-2.1.20130907+dfsg/debian/control 2015-04-01 10:39:01.0 +0100
+++ opentyrian-2.1.20130907+dfsg/debian/control 2017-03-04 22:36:42.0 +
@@ -10,8 +10,8 @@
libsdl-net1.2-dev,
Standards-Version: 3.9.6
Homepage: https://bitbucket.org/opentyrian/opentyrian/
-Vcs-Git: git://anonscm.debian.org/pkg-games/opentyrian.git
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-games/opentyrian.git
+Vcs-Git: https://anonscm.debian.org/git/pkg-games/opentyrian.git
+Vcs-Browser: https://anonscm.debian.org/cgit/pkg-games/opentyrian.git
Package: opentyrian
Architecture: any
@@ -19,6 +19,8 @@
${shlibs:Depends},
${misc:Depends},
tyrian-data | game-data-packager (>= 40),
+Suggests:
+ zenity | kde-baseapps-bin | x11-utils | libnotify-bin,
Description: open-source port of the DOS shoot-em-up Tyrian
Tyrian is an arcade-style vertical scrolling shooter. The story is set in
20,031 where you play as Trent Hawkins, a skilled fighter-pilot employed to
diff -Nru opentyrian-2.1.20130907+dfsg/debian/copyright opentyrian-2.1.20130907+dfsg/debian/copyright
--- opentyrian-2.1.20130907+dfsg/debian/copyright 2015-04-02 17:20:58.0 +0100
+++ opentyrian-2.1.20130907+dfsg/debian/copyright 2017-03-04 22:36:42.0 +
@@ -7,7 +7,7 @@
License: GPL-2+
Files: debian/*
-Copyright: 2013-2014, Etienne Millon
+Copyright: 2013-2015, Etienne Millon
2015, Alexandre Detiste
License: GPL-2+
diff -Nru opentyrian-2.1.20130907+dfsg/debian/patches/gdp.patch opentyrian-2.1.20130907+dfsg/debian/patches/gdp.patch
--- opentyrian-2.1.20130907+dfsg/debian/patches/gdp.patch 1970-01-01 01:00:00.0 +0100
+++ opentyrian-2.1.20130907+dfsg/debian/patches/gdp.patch 2017-03-04 22:36:42.0 +
@@ -0,0 +1,81 @@
+From: Alexandre Detiste
+Subject: Display an error message when data is missing
+Date: Sat, 04 Mar 2017 20:59:30 +0100
+
+A version of this patch has been forwarded upstream; this is a cut-down
+version suitable for Debian stretch.
+
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856728
+Forwarded: https://bitbucket.org/opentyrian/opentyrian/pull-requests/6
+
+--- a/src/varz.c
b/src/varz.c
+@@ -16,6 +16,10 @@
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ */
++#ifdef TARGET_UNIX
++#include
++#endif
++
+ #include "config.h"
+ #include "editship.h"
+ #include "episodes.h"
+@@ -498,6 +502,38 @@
+ }
+
+ SDL_Quit();
++
++#ifdef TARGET_UNIX
++#define MISSING_TEXT "One or more of the required Tyrian " TYRIAN_VERSION " data files could not be found.\n" \
++ "These can be installed using game-data-packager.\n"
++ if (code == 1)
++ {
++ char* argv[6];
++ pid_t child_pid;
++ child_pid = fork();
++ if(child_pid == 0) {
++ argv[0] = "zenity";
++ argv[1] = "--error";
++ argv[2] = "--text=" MISSING_TEXT;
++ argv[3] = "--title=Ty
Bug#650814: Parcel 03072547 delivery notification, UPS
Atención: Este mensaje contenía uno o más anexos que han sido eliminados Atención: (UPS-Package-03072547.doc.zip, UPS-Package-03072547.doc.js). Atención: Por favor, lea el(los) anexo(s) "GPFCorp-Attachment-Warning.txt" para más información. Dear Customer, Your item has arrived at the UPS Post Office at March 02, but the courier was unable to deliver parcel to you. Please check the attachment for complete details! Yours respectfully, Ricardo Atkins, UPS Mail Delivery Agent. Este es un mensaje del Servicio de Protección de Virus para Correo Electrónico MailScanner -- El archivo anexado original "UPS-Package-03072547.zip" se considera que ha sido infectado por un virus y el mismo ha sido reemplazado por este mensaje de aviso. Si desea recibir una copia del archivo anexado original *infectado*, por favor envíe un correo electrónico al departamento de soporte incluyendo este mensaje. Alternativamente, puede llamar a dicho departamento de, teniendo el contenido de este mensaje a mano. El Sat Mar 4 17:56:46 2017 el analizador de virus dijo: MailScanner: JScript Scripts are dangerous in email (UPS-Package-03072547.doc.js) Nota para el departamento de soporte: Revisar en the GPFCorp (ns) MailScanner en /var/spool/MailScanner/quarantine/20170304 (mensaje v24MujGK027046). -- Postmaster Powerfast-Ecuanex www.rumicucho.com For all your IT requirements visit: http://www.transtec.co.uk
Bug#856300: ITA: swatch -- Log file viewer with regexp matching,
Hello I already uploaded a new revision of swatch to the pkg-security team repo: https://anonscm.debian.org/cgit/pkg-security/swatch.git Greetings, Marcos
Bug#856809: gcc-6 on ppc64el: internal compiler error in push_reload, at reload.c:1349
Package: gcc-6 Version: 6.3.0-8 Severity: serious Control: affects -1 src:d-itg src:gtk-gnutella https://buildd.debian.org/status/fetch.php?pkg=gtk-gnutella&arch=ppc64el&ver=1.1.8-2+b1&stamp=1488642493&raw=0 ... cc -c -I../.. -I.. -I../if/gen -pthread -I/usr/include/glib-2.0 -I/usr/lib/powerpc64le-linux-gnu/glib-2.0/include -I/usr/include/p11-kit-1 -DCORE_SOURCES -DCURDIR=src/core -O2 -g -pthread -pipe -W -Wall -Wformat=2 -Wshadow fileinfo.c fileinfo.c: In function 'file_info_retrieve_binary': fileinfo.c:2113:1: internal compiler error: in push_reload, at reload.c:1349 } ^ https://buildd.debian.org/status/fetch.php?pkg=d-itg&arch=ppc64el&ver=2.8.1-r1023-3+b2&stamp=1488648471&raw=0 ... [ CXX ] ITGSend.o <- ITGSend.cpp ITGSend.cpp: In function 'void* flowParser(void*)': ITGSend.cpp:1024:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation] if (flows[id].l4Proto == LX_ERROR_BYTE) ^~ ITGSend.cpp:1029:6: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if' flows[id].minPayloadSize = flows[id].minPayloadSize + sizeof(int); ^ ITGSend.cpp: In function 'void* flowSender(void*)': ITGSend.cpp:2641:49: warning: enumeral mismatch in conditional expression: '' vs '' [-Wenum-compare] prototype = (DestHost->ai_family == AF_INET) ? IPPROTO_ICMP : IPPROTO_ICMPV6; ^ ITGSend.cpp:3608:1: internal compiler error: in push_reload, at reload.c:1349 } ^
Bug#856487: pulseaudio: SIGSEGV upon streaming to bluetooth headset
On Sat, Mar 4, 2017 at 6:27 PM, Linus Lüssing wrote: >> Are you sure it's definitely related to the gcc version? Did you actually >> try rebuilding with gcc-4.9 on the target machine? >> >> The thing is that assembly code is not interpreted by gcc but by the >> assembler >> which is part of the binutils package. Since binutils is updated >> in Debian very often, it may be well related to a bug in binutils. > > I didn't try from a chroot, but tried 2.28 as you suggested as > well as a few downgraded versions, which all failed: > > binutils 2.28-1 -> not > binutils 2.27.51.20161220-1 > binutils 2.27-9 -> not working > binutils 2.26-1 -> not working > binutils 2.26.1-1 -> not working > binutils 2.26-12 -> not working > > I also tried downgrading gcc-6, which didn't help either: > gcc 6.0.1-2 > > What worked then: > * gcc 4.9.4-2 + binutils 2.26.1-1 > * gcc 4.9.4-2 + binutils 2.28-1 > Thanks for the extensive testing! > Not really familiar with how binaries get created or uploaded in > Debian, but is it possible to determine the gcc + binutils > versions with which libsbc 1.3-1 and 1.3-1+b2 were created? Just > to double check whether the official uploads were indeed created > with gcc-4.9 for libsbc 1.3-1 and gcc-5/gcc-6 for 1.3-1+b2? The build logs are publicly available, for this build[1] the versions used were: binutils_2.25-8 gcc-4.9_4.9.2-19 [1] https://buildd.debian.org/status/fetch.php?pkg=sbc&arch=armhf&ver=1.3-1&stamp=1433137735&raw=0 -- Saludos, Felipe Sateler
Bug#856808: error during mount: first meta block group too large
Package: linux-image-4.9.0-2-amd64
Version: 4.9.13-1
Severity: important
Tags: patch upstream
Hi!
After rebooting one of my systems with 4.9.x I got hit by the following
error:
[ 309.934171] EXT4-fs (dm-5): mounting ext3 file system using the ext4
subsystem
[ 309.934748] EXT4-fs (dm-5): first meta block group too large: 1 (group
descriptor block count 1)
Unfortunately for me this is my /var filesystem.
This is https://bugzilla.kernel.org/show_bug.cgi?id=194567 and got fixed
by https://patchwork.ozlabs.org/patch/728066/
Rebuilding the kernel with the patch applied allows my system to mount
and boot again. Please add the fix to the next release, should be fix
not be included in a stable release until then.
Grüße,
Sven.
-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'unstable'), (500, 'testing'), (200, 'experimental'), (1, 'experimental-debug')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages linux-image-4.9.0-2-amd64:amd64 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.127
ii kmod24-1
ii linux-base 4.5
Versions of packages linux-image-4.9.0-2-amd64:amd64 recommends:
ii firmware-linux-free 3.4
ii irqbalance 1.1.0-2.2
Versions of packages linux-image-4.9.0-2-amd64:amd64 suggests:
pn debian-kernel-handbook
ii grub-pc 2.02~beta3-5
pn linux-doc-4.9
-- debconf-show failed
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index dde14a7ac6d7..a673558fe5f8 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3860,7 +3860,7 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
db_count = (sbi->s_groups_count + EXT4_DESC_PER_BLOCK(sb) - 1) /
EXT4_DESC_PER_BLOCK(sb);
if (ext4_has_feature_meta_bg(sb)) {
- if (le32_to_cpu(es->s_first_meta_bg) >= db_count) {
+ if (le32_to_cpu(es->s_first_meta_bg) > db_count) {
ext4_msg(sb, KERN_WARNING,
"first meta block group too large: %u "
"(group descriptor block count %u)",
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index dde14a7ac6d7..a673558fe5f8 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3860,7 +3860,7 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
db_count = (sbi->s_groups_count + EXT4_DESC_PER_BLOCK(sb) - 1) /
EXT4_DESC_PER_BLOCK(sb);
if (ext4_has_feature_meta_bg(sb)) {
- if (le32_to_cpu(es->s_first_meta_bg) >= db_count) {
+ if (le32_to_cpu(es->s_first_meta_bg) > db_count) {
ext4_msg(sb, KERN_WARNING,
"first meta block group too large: %u "
"(group descriptor block count %u)",
Bug#785658: O: xscavenger -- A lode-runner-like platform game for X
On Mon, May 18, 2015 at 08:05:46PM +, David Ashley wrote: > Package: wnpp > > I am the original author for the game and have tried to contact the > maintainer (Hwei Sheng Teoh hst...@debian.org) multiple times to > notify him of sound related bugfixes that are available for > longstanding issues (on the order of 10 years old). Right now I'm not seeing any relevant bug open against the package, which should be the main point of contact for requests about a package. Did you open any bug that got wrongly closed or something? -- 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#856652: RFS: xpdf/3.0.4.real-4
On Sun, 2017-03-05 at 02:50 +0500, Andrey Rahmatullin wrote: > On Sat, Mar 04, 2017 at 01:56:26PM -0600, Jason Crain wrote: > > > > The upstream xpdf source contains a file misc/hello.pdf for > > > > testing purposes, according to the INSTALL file. It would > > > > likely need to be repacked to remove that file. > > > > > > What's the problem with that file? It is not part of any > > > xpdf*.deb. > > > > Listed under "Source package missing source" on the FTP master's > > reject FAQ¹: > > > > "Source packages are part of the distribution. As such source must > > be present for all files in the source package itself, this > > includes convenience copies of other projects." > > > > I think this applies whether or not the file is used in the binary > > package. The source for that PDF is not included, making it not > > DFSG free. > > Yes, that's correct. OK, including the real upstream tarball solves that issue, right? (Sorry, I don't really see the problem with me wanting to adopt the (real) xpdf package?) The problem is that Debian created a stripped- down version of the upstream tarball, right? If not I'm completely lost.
Bug#856807: node-mocha: please make the build reproducible
forwarded 856807 https://github.com/mochajs/mocha/pull/2727 thanks Forwarded upstream to: https://github.com/mochajs/mocha/pull/2727 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#856807: node-mocha: please make the build reproducible
Source: node-mocha Version: 1.20.1-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: locale X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that node-mocha could not be built reproducibly. Patch attached. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/0004-reproducible_build.patch 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/0004-reproducible_build.patch 2017-03-04 22:08:07.627508560 + @@ -0,0 +1,15 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2017-03-04 + +--- node-mocha-1.20.1.orig/Makefile node-mocha-1.20.1/Makefile +@@ -1,7 +1,7 @@ + + REPORTER ?= dot + TM_BUNDLE = JavaScript\ mocha.tmbundle +-SRC = $(shell find lib -name "*.js" -type f | sort) ++SRC = $(shell find lib -name "*.js" -type f | LC_ALL=C sort) + SUPPORT = $(wildcard support/*.js) + + all: mocha.js --- a/debian/patches/series 2017-03-04 22:05:17.590246118 + --- b/debian/patches/series 2017-03-04 22:07:21.511163989 + @@ -3,3 +3,4 @@ 0002_fix_node_shebang.patch 0003_images_in_usr_share.patch register-coffeescript.patch +0004-reproducible_build.patch
Bug#856806: i7z: Possible wrong output with Nehalem
Package: i7z Version: 0.27.2+git2013.10.12-g5023138-3 Severity: normal Dear Maintainer, Running i7z in i7-870 Nehalem, it prints "i7z DEBUG: Detected a nehalem (i7/i5/Xeon) - 45nm" first and "i7z DEBUG: guessing Haswell" near the end. Haswell is a different newer family (i7-4170 eg, Sandy and Ivy are generations between it and Nehalem). The file helper_functions.c around line 420 has: *nehalem = true; *sandy_bridge = false; *ivy_bridge = false; *haswell = true; And other blocks always set one to true and the other three to false. Could that be a bug and the reason for the mixed reports? Just setting last to false could fix it, if no more tests needed to differentiate. The program also reports two conflicting values once running, first "True Frequency (without accounting Turbo) 2942 MHz" and below "Max Frequency without considering Turbo 3075.73 MHz (133.73 x [23])". The official value is ~2.9 GHz, the 23 multiplier is between official normal max (22) and minimum turbo (24 and up). Again I looked at the code, and in i7z_Single_Socket.c below line 285 I see it adds one when TURBO_MODE is 1. Maybe wrong? Maybe it should use another string to explain why? In other similar part of the file, below line 944, it says "True Frequency" instead (safety margin to allow transitions to/from turbo modes?). That function seems to be commented out. Other than those two, all looks OK. It even let me notice a bug in "cpupower frequency-info -n", which seems to be confused too and reports turbo levels as X * 100 instead of X * 133 (Nehalem vs newer), with the absurd result of normal max being well above the single core turbo. Thanks, GSR -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/8 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: sysvinit (via /sbin/init) Versions of packages i7z depends on: ii libc6 2.24-9 ii libncurses5 6.0+20151024-2 ii libtinfo5 6.0+20151024-2 ii msr-tools 1.3-2 ii ruby 1:2.1.0.4 ii ruby1.8 [ruby-interpreter]1.8.7.358-7 ii ruby1.9.1 [ruby-interpreter] 1.9.3.194-8.1+b1 ii ruby2.1 [ruby-interpreter]2.1.2-3 i7z recommends no packages. i7z suggests no packages. -- no debconf information
Bug#854699: Shutdown fails with an encrypted filesystem on virtio device
I've uploaded test packages to https://people.debian.org/~biebl/systemd/stretch/ You can install them by first installing apt-transport-https, then adding to your sources.list: deb [trusted=yes] https://people.debian.org/~biebl/systemd/stretch/ ./ Please report back if those packages fix your issues. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#856337: systemd: please support kernel 4.4, or don't hardcode dm interface versions
I've uploaded test packages to https://people.debian.org/~biebl/systemd/stretch/ You can install them by first installing apt-transport-https, then adding to your sources.list: deb [trusted=yes] https://people.debian.org/~biebl/systemd/stretch/ ./ Please report back if those packages fix your issues. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, Mar 04, 2017 at 01:56:26PM -0600, Jason Crain wrote: > > > The upstream xpdf source contains a file misc/hello.pdf for testing > > > purposes, according to the INSTALL file. It would likely need to be > > > repacked to remove that file. > > > > What's the problem with that file? It is not part of any xpdf*.deb. > > Listed under "Source package missing source" on the FTP master's reject FAQ¹: > > "Source packages are part of the distribution. As such source must be > present for all files in the source package itself, this includes > convenience copies of other projects." > > I think this applies whether or not the file is used in the binary > package. The source for that PDF is not included, making it not DFSG > free. Yes, that's correct. -- WBR, wRAR signature.asc Description: PGP signature
Bug#856805: gstreamer1.0-crystalhd: libgstbcmdec.so not found by gstreamer
Package: gstreamer1.0-crystalhd Version: 1:0.0~git20110715.fdd2f19-11+b1 Severity: important Dear Maintainer, I installed package gstreamer1.0-crystalhd on debian testing, but gst- inspect-1.0 revealed that the installed /usr/lib/gstreamer-1.0/libgstbcmdec.so was not being found by gstreamer (and so playback was not using CrystalHD). When I symlinked this file into directory /usr/lib/x86_64-linux- gnu/gstreamer-1.0/ (where the other gstreamer plugins live) it started working and I was able to play back videos using the CrystalHD decoder (as I had already installed the kernel driver). With regards, Luke -- System Information: Debian Release: 9.0 APT prefers jessie APT policy: (500, 'jessie'), (500, 'all'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-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) Versions of packages gstreamer1.0-crystalhd depends on: ii libc6 2.24-9 ii libcrystalhd3 1:0.0~git20110715.fdd2f19-11+b1 ii libglib2.0-02.50.3-1 ii libgstreamer-plugins-base1.0-0 1.10.3-1 ii libgstreamer1.0-0 1.10.3-1 gstreamer1.0-crystalhd recommends no packages. gstreamer1.0-crystalhd suggests no packages. -- no debconf information
Bug#856487: pulseaudio: SIGSEGV upon streaming to bluetooth headset
> Are you sure it's definitely related to the gcc version? Did you actually
> try rebuilding with gcc-4.9 on the target machine?
>
> The thing is that assembly code is not interpreted by gcc but by the assembler
> which is part of the binutils package. Since binutils is updated
> in Debian very often, it may be well related to a bug in binutils.
I didn't try from a chroot, but tried 2.28 as you suggested as
well as a few downgraded versions, which all failed:
binutils 2.28-1 -> not
binutils 2.27.51.20161220-1
binutils 2.27-9 -> not working
binutils 2.26-1 -> not working
binutils 2.26.1-1 -> not working
binutils 2.26-12 -> not working
I also tried downgrading gcc-6, which didn't help either:
gcc 6.0.1-2
What worked then:
* gcc 4.9.4-2 + binutils 2.26.1-1
* gcc 4.9.4-2 + binutils 2.28-1
Not really familiar with how binaries get created or uploaded in
Debian, but is it possible to determine the gcc + binutils
versions with which libsbc 1.3-1 and 1.3-1+b2 were created? Just
to double check whether the official uploads were indeed created
with gcc-4.9 for libsbc 1.3-1 and gcc-5/gcc-6 for 1.3-1+b2?
Regards, Linus
PS: All those tests above just with a plain
"$ CC=gcc-{4.9,6} dpkg-buildpackage -us -uc", so with the default
hardening flags.
Bug#850272: Bug#850268: Please stop using deprecated GNOME libraries (libgnome-2-0, libgnomevfs2-0, libgconf2-4)
On Sat, 04 Mar 2017 at 21:13:41 +, Simon McVittie wrote: > Thanks for uploading openjdk-8 without these obsolete dependencies. Please > do the same in the next openjdk-9 upload - I've checked the relevant code > and it seems to be essentially the same, so my justification from > openjdk-8 should be equally valid. > > This is low priority right now since openjdk-9 won't be in stretch anyway. Oops, I meant to send this to the cloned bug, not the original. S
Bug#805754: Processed: retitle to RFP: ensembl-tools -- Ensembl tools for genomic data processing
On Sat, Mar 04, 2017 at 10:59:15AM -0800, Afif Elghraoui wrote: > > I did, but VEP (the tool I was interested in) was moved to a separate > upstream project. I am moving soon, so will not have a chance to push my > current work for a while. It involved packaging some other Ensembl APIs > and seems to be difficult to keep up with. Thanks for the clarification. There is no need to hurry - I just thought that any effort you might have done should not bitrot on your local hard disk if you lost interest. Kind regards Andreas. -- http://fam-tille.de
Bug#850268: Please stop using deprecated GNOME libraries (libgnome-2-0, libgnomevfs2-0, libgconf2-4)
Thanks for uploading openjdk-8 without these obsolete dependencies. Please do the same in the next openjdk-9 upload - I've checked the relevant code and it seems to be essentially the same, so my justification from openjdk-8 should be equally valid. This is low priority right now since openjdk-9 won't be in stretch anyway. Regards, S
Bug#856453: Ctrl+D discard all changes and close the image creates new copy
Are you sure the pop-up window was focused when pressing Ctrl+D? That shortcut does duplicate the image when the main window is focused.
Bug#856728: opentyrian: When run via menu the game silently exits if data is missing
Hello, > I had a patch for this that was proposed upstream, > then I completely forgot about it: > > https://bitbucket.org/opentyrian/opentyrian/pull-requests/6/display-dialog-b > ox-if-files-are-missing/diff > > This could be reworked & simplified for Debian only. That would be great. Currently people might think the game keeps crashing and remove it without playing. > No, doing this in postinst script is dangerous (run as root, > files doesn't get registered as owned by opentyrian in dpkg database...) > we have a generic anwser to this generic problem and it's called > game-data-packager. > I was actually thinking more that the post installer would run game-data- packager if the user clicks yes. Best Regards, Andrej Mernik
Bug#856693: Drop ant dependency
Hi, On Sat, Mar 04, 2017 at 11:40:53AM -0800, tony mancill wrote: > were causing a serious issue, we could discuss splitting ant into > something like "ant-bin" (maybe there's a better name) and libant-java, > so only the latter library package is a dependency of > libapache-poi-java. > > In that case, I think we would still want to have an "ant" package that > depended on both the library and the "ant-bin" cli build tools that are > found in /usr/bin and /usr/share/ant/bin. Perhaps another reason to Or simply ant -> libant-java. IMHO no need for a extra ant-bin. > But in terms of overhead, I don't think there's anything to be concerned > about, because the ant wrapper scripts are tiny when compared to the jar > file itself: > > $ du -sh /usr/share/ant/bin > 40K /usr/share/ant/bin > > $ du -shL /usr/share/java/ant.jar > 2.0M /usr/share/java/ant.jar > > So this seems more like a question of style. Do you still think the > severity is important? Think so, yes. Doesn't the Java policy also say you should split the library out to a -java, anyways? Regards, Rene
Bug#855906: [pkg-go] Bug#855906: golang-codegangsta-cli: FTBFS: FAIL: TestCommandYamlFileTestDefaultValueFileWins (0.00s) helpers_test.go:10: Expected 15 (type int) - Got 7 (type int)
Vincent, are you requesting an unblock exception for this package? There are a bunch of other packages that are going to be removed from testing if this does not migrate. -- Martín Ferrari (Tincho)
Bug#856042: gnat: please use SOURCE_DATE_EPOCH for reproducible ALI timestamps
On 04.03.2017 17:31, Nicolas Boulenguez wrote: > Package: gnat-7 > Followup-For: Bug #856042 > > Thank you for applying the patch. > The test script passes (with "V=v;export V;c" instead of "V=v c"). does it make sense to backport it to gcc-6=?
Bug#847595: liblcms2-2 causes cd-iccdump to output incorrect locale names
On Fri, Mar 03, 2017 at 04:16:05PM +0800, Chris Lamb wrote: > Hey, > > +lcms2 (2.8-3) unstable; urgency=medium > + > + * New patch: lcms2-fix-strFrom16-byte-order.patch. > +Thanks to HW42 (Closes: #847595) > > Did this get sent upstream? :) We are seeing other distributions > hitting the same issue: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856447 The bug report has a "Forwarded to" header and the patch has a "Bug:" tag following DEP3: https://github.com/mm2/Little-CMS/issues/110 So, yes, this was sent upstream. Upstream chose a different way forward which albeit didn't work. Thomas
Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, Mar 04, 2017 at 08:19:43PM +0100, Svante Signell wrote: > And BTW: poppler upstream seems to be freedesktop.org, i.e. gnome. Who > can trust gnome nowadays, especially people preferring systemd-free > software? Sniping at GNOME aside, freedesktop.org is independent from GNOME, and poppler's lead maintainer is a KDE developer.
Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, Mar 04, 2017 at 07:28:37PM +0100, Svante Signell wrote: > On Sat, 2017-03-04 at 09:46 -0600, Jason Crain wrote: > > The upstream xpdf source contains a file misc/hello.pdf for testing > > purposes, according to the INSTALL file. It would likely need to be > > repacked to remove that file. > > What's the problem with that file? It is not part of any xpdf*.deb. Listed under "Source package missing source" on the FTP master's reject FAQ¹: "Source packages are part of the distribution. As such source must be present for all files in the source package itself, this includes convenience copies of other projects." I think this applies whether or not the file is used in the binary package. The source for that PDF is not included, making it not DFSG free. ¹ https://ftp-master.debian.org/REJECT-FAQ.html
Bug#757356: Scan code event not generated for some keys of the Apple keyboard' from 'Scan code event not generated for some keys of the Appple keyboard
I was recently annoyed that alt/meta don't generate scancodes when
swap_opt_cmd is on, and patched it (diff attached). This passes the
original scancodes through unmodified, even when the keycodes are
translated (e.g. Fn+F1 sends scancodes for Fn and F1, but keycode for
brightness down). Works for me, though I'm not sure if this is a good
approach overall.
--- a/drivers/hid/hid-apple.c 2017-03-04 01:34:38.655588991 -0500
+++ b/drivers/hid/hid-apple.c 2017-03-04 01:47:08.082599141 -0500
@@ -177,6 +177,15 @@
return NULL;
}
+static void input_event_with_scancode(struct input_dev *input,
+ __u8 type, __u16 code, unsigned int hid, __s32 value)
+{
+ if (type == EV_KEY &&
+ (!test_bit(code, input->key)) == value)
+ input_event(input, EV_MSC, MSC_SCAN, hid);
+ input_event(input, type, code, value);
+}
+
static int hidinput_apple_event(struct hid_device *hid, struct input_dev *input,
struct hid_usage *usage, __s32 value)
{
@@ -185,7 +194,8 @@
if (usage->code == KEY_FN) {
asc->fn_on = !!value;
- input_event(input, usage->type, usage->code, value);
+ input_event_with_scancode(input, usage->type, usage->code,
+usage->hid, value);
return 1;
}
@@ -217,8 +227,8 @@
else
clear_bit(usage->code, asc->pressed_fn);
-input_event(input, usage->type, trans->to,
- value);
+input_event_with_scancode(input, usage->type,
+ trans->to, usage->hid, value);
return 1;
}
@@ -238,8 +248,8 @@
clear_bit(usage->code,
asc->pressed_numlock);
-input_event(input, usage->type, trans->to,
- value);
+input_event_with_scancode(input, usage->type,
+ trans->to, usage->hid, value);
}
return 1;
@@ -250,7 +260,8 @@
if (asc->quirks & APPLE_ISO_KEYBOARD) {
trans = apple_find_translation(apple_iso_keyboard, usage->code);
if (trans) {
-input_event(input, usage->type, trans->to, value);
+input_event_with_scancode(input, usage->type,
+ trans->to, usage->hid, value);
return 1;
}
}
@@ -259,7 +270,8 @@
if (swap_opt_cmd) {
trans = apple_find_translation(swapped_option_cmd_keys, usage->code);
if (trans) {
- input_event(input, usage->type, trans->to, value);
+ input_event_with_scancode(input, usage->type,
+ trans->to, usage->hid, value);
return 1;
}
}
Bug#856652: RFS: xpdf/3.0.4.real-4
Dear Svante, On Sat, Mar 04, 2017 at 08:19:43PM +0100, Svante Signell wrote: > Maybe I don't understand. The version of xpdf I'm proposing is no > longer dependent on poppler. So why are you talking about poppler? > Which are the security issues of upstream xpdf? I'd really like to > know, and if possible forward these problems to upstream:Glyph & Cog, > LLC. Additionally, which are the poppler-based security issues? I'm not referring to currently known security issues. I'm referring to issues that are yet to be discovered. > See above. Which version of xpdf are you referring to, the poppler- > based one, or the upstream one? > > And BTW: poppler upstream seems to be freedesktop.org, i.e. gnome. Who > can trust gnome nowadays, especially people preferring systemd-free > software? I trust GNOME to quickly find and repair security issues in libpoppler. -- Sean Whitton signature.asc Description: PGP signature
Bug#856693: Drop ant dependency
On Sat, Mar 04, 2017 at 01:30:47AM +0100, Michael Biebl wrote: > Source: libapache-poi-java > Version: 3.10.1-3 > Severity: important > > libapache-poi-java is an indirect dependency of libreoffice, so pulled > in on every desktop installation. > > Having a build tool like ant being pulled because of a library > dependency is unwanted in such a case. Please consider dropping the > dependency on ant. Hi Michael, Thank you for noticing this. I agree that it look odd. However, the apache-poi sources use classes from ant.jar - for example, refer to the classes in this package [1] - and currently that jar is shipped along with the ant package. I question whether it would worth it, but if this were causing a serious issue, we could discuss splitting ant into something like "ant-bin" (maybe there's a better name) and libant-java, so only the latter library package is a dependency of libapache-poi-java. In that case, I think we would still want to have an "ant" package that depended on both the library and the "ant-bin" cli build tools that are found in /usr/bin and /usr/share/ant/bin. Perhaps another reason to consider a split is because ant depends on a JRE (although I think you're going to need one anyway in order to do anything useful with apache-poi). But in terms of overhead, I don't think there's anything to be concerned about, because the ant wrapper scripts are tiny when compared to the jar file itself: $ du -sh /usr/share/ant/bin 40K /usr/share/ant/bin $ du -shL /usr/share/java/ant.jar 2.0M/usr/share/java/ant.jar So this seems more like a question of style. Do you still think the severity is important? Cheers, tony [1] https://anonscm.debian.org/cgit/pkg-java/libapache-poi-java.git/tree/src/excelant/java/org/apache/poi/ss/excelant signature.asc Description: PGP signature
Bug#855049: Gnome-shell-pomodoro: New version on mentors
Control: tags -1 + pending The new version is now on mentors and I'm reviewing it with my mentor. It should arrive in the next few days in unstable. Thanks for your report, Joseph
Bug#856731: fonts-vollkorn 3.005-1 does not support Greek.
A proposed fix of this bug is available in this PPA: https://launchpad.net/~gunnarhj/+archive/ubuntu/fonts-vollkorn @Joakim: It would be great if you could install the package from the PPA and let us know if it works as expected for you. -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj
Bug#856728: opentyrian: When run via menu the game silently exits if data is missing
Le samedi 4 mars 2017, 13 h 35 min 14 s CET Andrej Mernik a écrit : > Package: opentyrian > Version: 2.1.20130907+dfsg-1 > Severity: important Hi, I had a patch for this that was proposed upstream, then I completely forgot about it: https://bitbucket.org/opentyrian/opentyrian/pull-requests/6/display-dialog-box-if-files-are-missing/diff This could be reworked & simplified for Debian only. > Alternatively, the installer script could ask the user if he wants to > download and install the data files too. No, doing this in postinst script is dangerous (run as root, files doesn't get registered as owned by opentyrian in dpkg database...) we have a generic anwser to this generic problem and it's called game-data-packager. Greets, Alexandre Detiste
Bug#855282: debsign not signing .buildinfo files breaks other tools
Control: severity -1 serious After reading [1] (debarchiver rejecting packages due to unsigned .buildinfo) this is IMHO an RC issue for stretch - dscverify rejecting packages signed by debsign is nothing that should end up in a release. cu Adrian [1] https://lists.debian.org/debian-user-german/2017/03/msg00025.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#856606: gitlab: fails to upgrade from 'stretch': nginx example configuration file not found
On 2017-03-04 13:27, Pirate Praveen wrote: > On ശനി 04 മാര്ച്ച് 2017 04:25 വൈകു, Andreas Beckmann wrote: >> Yes, upgrading packages must work. And especially between versions in >> testing (which will become relevant if 8.13.11+dfsg-4 migrates to >> testing). And later on from stable to stable-pu (in case you need to >> apply fixes after the release). > I thought you need support upgrading between stable to next stable only. > Can you show the relevant policy that says upgrading between versions in > testing has to work? I don't think that is written explicitly in the policy, but there seems to be general understanding that you must be able upgrade from one package version to the next package version within a suite (unstable, testing, stable) as well as between suites (oldstable->stable, stable->testing, testing->unstable). (This may not be true for packages in experimental, but once the package gets uploaded to unstable ... you want to be able to upgrade from the previous version in unstable to the current one). What is usually not supported are upgrades that skip stable releases (e.g. upgrading directly from old-oldstable to stable without upgrading from old-oldstable to oldstable first). If you disagree, please take this to the tech-ctte. >> What else would you want to do with a gitlab installation in testing if >> upgrading does not work? > Did you update /etc/gitlab/gitlab-debian.conf? I didn't touch anything, I'm just doing automated upgrade tests with piuparts, so all config files are at their defaults. > This happened because a > configuration file has changed. How am I supposed to make changes in > configuration files then? Use ucf? But you already use this. Or what do you mean with "making changes in configuration files"? Having briefly looked at the postinst script, it appears to me that all the nginx_* variables are not set at all ... Andreas
Bug#856804: latex-cjk-common: Small typo in copyright file
Package: latex-cjk-common Version: 4.8.4+git20150701-2 Severity: minor It was downloaded from http://cjk.ffii.org/cjk-current.tar.gz And the project homepage is http://cjk.ffi.org/ Project homepage is too http://cjk.ffi.org/ . Hilmar -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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 Init: systemd (via /run/systemd/system)
Bug#847462: the problem is with CUPS
On Sat 04 Mar 2017 at 21:06:56 +0200, Martin-Éric Racine wrote: > 2017-03-04 20:43 GMT+02:00 Brian Potkin : > > On Fri 03 Mar 2017 at 20:28:56 +0200, Martin-Éric Racine wrote: > > > >> 2017-03-03 18:25 GMT+02:00 Francesco Potortì : > >> > >> > This apparently has to do with the old problem of cups-pdf converting > >> > PDF to PS and back to PDF. > >> > > >> > I have an old Ubuntu Lucid installation where the problem does not > >> > exist. > >> > >> Debian and Ubuntu both briefly used a patch (around version 2.5.1 > >> IIRC) that bypassed the pdf2pdf filter. It worked well for simply > >> passing documents that were already in PDF format over to CUPS for > >> output to a PDF spool. However, it completely broke CUPS-PDF's > >> primary functionality which is to convert arbitrary document formats > >> into PDF, and it also prevented users from further manipulating the > >> documents via CUPS-PDF's configuration file options before outputting > >> them to the PDF spool. This resulted in complaints from users who > >> depended upon these features, so I removed the patch. > > > > The fullest discussion of this I know of is at > > > > https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/820820 > > > > Users should take note of the comment: > > > > > The reasons for not skipping this step are known to you > > > (it will severly impede the functionality of CUPS-PDF). > > > Furthermore, once again, CUPS-PDF is not meant for > > > processing PDF-input (i.e., it is not meant to be a > > > PDF-manipulation tool). > > > > However, cups-pdf is still seen as a general "convert something to a > > PDF" utility. At one time it might have served that purpose, but not > > now. Both text and PDF input produce a below-standard, non-searchable > > output. There is a case for clarifying its purpose as a cups-filters > > plus backend method for getting a decent quality, searchable PDF from > > PostScript input only. (Okular produces PostScript; Evince doesn't). > > As far as I can tell, the reason why the quality of the output has > varied over time is because the quality of Ghostscript itself has > varied a lot. > > There might be better filters than Ghostscript we could call to handle > the generic document conversion step. However, that's entirely > upstream's decision. I'd agree that any decision about the direction the software takes is one for upstream. Hopefully, changes in the Debain printing system will be taken into account. Meanwhile, I've implemented my own "print to PDF" system. Don't worry, it doesn't yet rival cups-pdf! -- Brian.
Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, 2017-03-04 at 11:49 -0700, Sean Whitton wrote: > Dear Svante, > > I agree with you that a poppler-based xpdf is not maintainable until > and unless xpdf upstream switches to poppler. However, it is not > clear to me why we shouldn't just remove xpdf from Debian. The main > reason that Debian insists on using shared libraries instead of > bundled copies of code is because it permits faster responses to > security problems uncovered in those shared libraries. A security > bug in poppler would now need to be fixed in xpdf's copy and in the > main library. Maybe I don't understand. The version of xpdf I'm proposing is no longer dependent on poppler. So why are you talking about poppler? Which are the security issues of upstream xpdf? I'd really like to know, and if possible forward these problems to upstream:Glyph & Cog, LLC. Additionally, which are the poppler-based security issues? > This might not be a big deal if xpdf was a package that read, say, > text files. However, PDFs are complex and are increasingly used as > vectors for malware. PDF readers are becoming an attack surface > comparable to web browsers, as more and more people use PDFs for more > and more of their work. So we need to ensure that Debian is in a > strong position to tackle any security issues that are > uncovered. Otherwise, we are doing a real disservice to our > users. It seems to me that one of the most sensible things we could > do to protect Debian users from malicious PDFs is to remove xpdf from > the Debian mirrors. See above. Which version of xpdf are you referring to, the poppler- based one, or the upstream one? And BTW: poppler upstream seems to be freedesktop.org, i.e. gnome. Who can trust gnome nowadays, especially people preferring systemd-free software?
Bug#855951: libsecret FTBFS with test failures on many architectures
On Thu, 23 Feb 2017 21:05:35 +0200, Adrian Bunk wrote: > Source: libsecret > Version: 0.18.5-2 > Severity: serious > > https://buildd.debian.org/status/package.php?p=libsecret > > FAIL: test-collection 18 /collection/delete-sync > - arm* > - i386 > - ppc64el > - s390x > > FAIL: test-session 4 /session/ensure-async-aes > - mipsel FWIW, the package currently builds for me in an i386 sid cowbuilder chroot (on an amd64 machine). Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Zueriwest: So wie denn i daem Summer signature.asc Description: Digital Signature
Bug#856133: shiboken FTBFS on i386/armel/armhf: other_collector_external_operator test failed
On Sat, 25 Feb 2017 16:07:03 +0200, Adrian Bunk wrote: > Source: shiboken > Version: 1.2.2-3 > Severity: serious > > https://buildd.debian.org/status/package.php?p=shiboken&suite=sid > FWIW, the package currently builds fine for me in an i386 sid cowbuilder chroot (and an amd64 machine). Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Zueriwest: So wie denn i daem Summer signature.asc Description: Digital Signature
Bug#847462: the problem is with CUPS
2017-03-04 20:43 GMT+02:00 Brian Potkin : > On Fri 03 Mar 2017 at 20:28:56 +0200, Martin-Éric Racine wrote: > >> 2017-03-03 18:25 GMT+02:00 Francesco Potortì : >> >> > This apparently has to do with the old problem of cups-pdf converting >> > PDF to PS and back to PDF. >> > >> > I have an old Ubuntu Lucid installation where the problem does not >> > exist. >> >> Debian and Ubuntu both briefly used a patch (around version 2.5.1 >> IIRC) that bypassed the pdf2pdf filter. It worked well for simply >> passing documents that were already in PDF format over to CUPS for >> output to a PDF spool. However, it completely broke CUPS-PDF's >> primary functionality which is to convert arbitrary document formats >> into PDF, and it also prevented users from further manipulating the >> documents via CUPS-PDF's configuration file options before outputting >> them to the PDF spool. This resulted in complaints from users who >> depended upon these features, so I removed the patch. > > The fullest discussion of this I know of is at > > https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/820820 > > Users should take note of the comment: > > > The reasons for not skipping this step are known to you > > (it will severly impede the functionality of CUPS-PDF). > > Furthermore, once again, CUPS-PDF is not meant for > > processing PDF-input (i.e., it is not meant to be a > > PDF-manipulation tool). > > However, cups-pdf is still seen as a general "convert something to a > PDF" utility. At one time it might have served that purpose, but not > now. Both text and PDF input produce a below-standard, non-searchable > output. There is a case for clarifying its purpose as a cups-filters > plus backend method for getting a decent quality, searchable PDF from > PostScript input only. (Okular produces PostScript; Evince doesn't). As far as I can tell, the reason why the quality of the output has varied over time is because the quality of Ghostscript itself has varied a lot. There might be better filters than Ghostscript we could call to handle the generic document conversion step. However, that's entirely upstream's decision. Martin-Éric
Bug#805754: Processed: retitle to RFP: ensembl-tools -- Ensembl tools for genomic data processing
Hi, Andreas, على السبت 4 آذار 2017 09:54، كتب Andreas Tille: > Hi Afif, > > you left an empty Git archive > >git://git.debian.org/git/debian-med/ensembl-tools.git > > Do you have any local repository with some preliminary work? Not that I > have any specific interest - but I wonder whether there is some stuff > hanging around which could help once somebody might like to work on > this. > I did, but VEP (the tool I was interested in) was moved to a separate upstream project. I am moving soon, so will not have a chance to push my current work for a while. It involved packaging some other Ensembl APIs and seems to be difficult to keep up with. regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Bug#856652: RFS: xpdf/3.0.4.real-4
Dear Svante, On Sat, Mar 04, 2017 at 06:43:35PM +0100, Svante Signell wrote: > This is the big problem, the two code bases are diverging. See a good > description about the status of xpdf from December 2013: > https://www.agwa.name/blog/post/the_sorry_state_of_xpdf_in_debian > > After my asking around to poppler and upstream Glyph & Cog, LLC, in the > name of Derek B. Noonburg, created a new upstream release, 3.04. See > the CHANGES file (changelog in the debian package) in the upstream > tarball for the latest fixes. > > However, Debian chose to continue trying to catch up with the patches > to libpoppler, in my opinion a very bad choice. The current state is > really bad, most of the bugs are due to the use of the libpoppler > backend. > [...] > The solution I've chosen is to remove the poppler backend completely. > That fixes 11+ important and normal bugs (and probably many minor and > wishlist ones too, I haven't looked into that yet) > > If somebody wants a poppler-based xpdf, it should be renamed to > something else, e.g. ppdf, and maybe even be integrated in the poppler > upstream code. Trying to merge xpdf frontend with the poppler backend > is just a loosing battle. Thank you for the further information, and especially for the link to Andrew Ayer's blog post. I agree with you that a poppler-based xpdf is not maintainable until and unless xpdf upstream switches to poppler. However, it is not clear to me why we shouldn't just remove xpdf from Debian. The main reason that Debian insists on using shared libraries instead of bundled copies of code is because it permits faster responses to security problems uncovered in those shared libraries. A security bug in poppler would now need to be fixed in xpdf's copy and in the main library. This might not be a big deal if xpdf was a package that read, say, text files. However, PDFs are complex and are increasingly used as vectors for malware. PDF readers are becoming an attack surface comparable to web browsers, as more and more people use PDFs for more and more of their work. So we need to ensure that Debian is in a strong position to tackle any security issues that are uncovered. Otherwise, we are doing a real disservice to our users. It seems to me that one of the most sensible things we could do to protect Debian users from malicious PDFs is to remove xpdf from the Debian mirrors. -- Sean Whitton signature.asc Description: PGP signature
Bug#856803: thunar: after many file updates, the displayed icons reference wrong file objects
Package: thunar Version: 1.6.10-6 Severity: important Dear Maintainer, when using the icon view in thunar and displaying a directory where many file updates happen with high frequency, the displayed icons and actual referenced file objects will start getting mixed up. Steps to reproduce: 1. set thunar to icon mode, open a directory where to build a LaTeX document 2. put a LaTeX document in that directory, e.g. use https://en.wikibooks.org/wiki/LaTeX/simple.tex 3. build the LaTeX document via 'pdflatex simple.tex' while having the directory displayed in thunar Expected outcome: Double clicking on any of the files within the directory should open up the corresponding file. Actual outcome: Double clicking on any of the files will open up _one of the other files_ in that directory. The references to the file objects and the displayed icons seem to get randomly mixed up. The status bar will still show the correct file that opens up on double click but the displayed icon and its label are wrong. Additional information: During the LaTeX build process, the icon display within the directory is refreshed very fast (icons changing position due to modification date sort order). On another system (still running Jessie but Xfce 4.12) the same process will redraw the icon view much less frequent and doesn't produce the issue. Both systems use SSDs. It can be assumed that the high frequency of the icon view refreshes/redraws causes the objects and references to get mixed up. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages thunar depends on: ii desktop-file-utils 0.23-1 ii exo-utils 0.10.7-1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-9 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.16-1 ii libdbus-glib-1-20.108-2 ii libexo-1-0 0.10.7-1 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-02.50.3-1 ii libgtk2.0-0 2.24.31-2 ii libgudev-1.0-0 230-3 ii libice6 2:1.0.9-2 ii libnotify4 0.7.7-1+b1 ii libpango-1.0-0 1.40.3-3 ii libsm6 2:1.2.2-1+b1 ii libthunarx-2-0 1.6.10-6 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util7 4.12.1-3 ii libxfconf-0-2 4.12.1-1 ii shared-mime-info1.8-1 ii thunar-data 1.6.10-6 Versions of packages thunar recommends: ii dbus-x11 1.10.16-1 ii gvfs 1.30.3-1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3+b2 ii libpangocairo-1.0-0 1.40.3-3 ii libpangoft2-1.0-01.40.3-3 ii thunar-volman0.8.1-2 ii tumbler 0.1.31-2+b3 ii xdg-user-dirs0.15-2 ii xfce4-panel 4.12.1-2 Versions of packages thunar suggests: pn thunar-archive-plugin ii thunar-media-tags-plugin 0.2.1-1+b2 -- no debconf information
Bug#847462: the problem is with CUPS
On Fri 03 Mar 2017 at 20:28:56 +0200, Martin-Éric Racine wrote: > 2017-03-03 18:25 GMT+02:00 Francesco Potortì : > > > This apparently has to do with the old problem of cups-pdf converting > > PDF to PS and back to PDF. > > > > I have an old Ubuntu Lucid installation where the problem does not > > exist. > > Debian and Ubuntu both briefly used a patch (around version 2.5.1 > IIRC) that bypassed the pdf2pdf filter. It worked well for simply > passing documents that were already in PDF format over to CUPS for > output to a PDF spool. However, it completely broke CUPS-PDF's > primary functionality which is to convert arbitrary document formats > into PDF, and it also prevented users from further manipulating the > documents via CUPS-PDF's configuration file options before outputting > them to the PDF spool. This resulted in complaints from users who > depended upon these features, so I removed the patch. The fullest discussion of this I know of is at https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/820820 Users should take note of the comment: > The reasons for not skipping this step are known to you > (it will severly impede the functionality of CUPS-PDF). > Furthermore, once again, CUPS-PDF is not meant for > processing PDF-input (i.e., it is not meant to be a > PDF-manipulation tool). However, cups-pdf is still seen as a general "convert something to a PDF" utility. At one time it might have served that purpose, but not now. Both text and PDF input produce a below-standard, non-searchable output. There is a case for clarifying its purpose as a cups-filters plus backend method for getting a decent quality, searchable PDF from PostScript input only. (Okular produces PostScript; Evince doesn't). -- Brian.
Bug#856789: education-desktop-other: modifies conffiles (policy 10.7.3): /etc/plymouth/plymouthd.conf
Control: reassign -1 debian-edu-artwork-softwaves 0.902-2 Control: retitle -1 debian-edu-artwork-softwaves: modifies conffiles (policy 10.7.3): /etc/plymouth/plymouthd.conf Control: affects -1 + education-desktop-other education-workstation education-standalone education-roaming-workstation Thanks for the analysis. Andreas
Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, Mar 04, 2017 at 07:31:30PM +0100, Svante Signell wrote: > I'll learn to use git, I let you know when I'm fluent enough for that. > However, creating an account on github is not any of my preferences, it > is non-free software. Maybe I can use gitlab (which is semi-non-free)? I completely understand your desire not to use GitHub. Any public git hosting will do. In fact, you can use Debian's git server, alioth.debian.org. SSH to alioth and create a repo in ~/public_git. -- Sean Whitton signature.asc Description: PGP signature
Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, 2017-03-04 at 07:50 -0700, Sean Whitton wrote: > On Fri, Mar 03, 2017 at 09:36:56PM +0100, Svante Signell wrote: > > BTW: Do I need to publish my packages somewhere locally? I > > currently > > don't have a web server running. Or is it possible to just use > > dput? > > If we're going to be using git, you just need to publish the git > repository somewhere (github is fine). I'll learn to use git, I let you know when I'm fluent enough for that. However, creating an account on github is not any of my preferences, it is non-free software. Maybe I can use gitlab (which is semi-non-free)?
Bug#854594: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed
On Sat, 2017-03-04 at 19:18 +0100, Yves-Alexis Perez wrote: > I'll > try to reproduce using a gstreamer pipeline in case that helps narrowing the > problem. Calling gst-play-1.0 works fine. -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, 2017-03-04 at 09:46 -0600, Jason Crain wrote: > On Sat, Mar 04, 2017 at 08:02:29AM -0700, Sean Whitton wrote: > > It sounds like the source should not in fact be repacked. What do > > you > > think, Svante? > > The upstream xpdf source contains a file misc/hello.pdf for testing > purposes, according to the INSTALL file. It would likely need to be > repacked to remove that file. What's the problem with that file? It is not part of any xpdf*.deb.
Bug#856801: golang-github-ngaut-deadline-dev: Provide long description
Package: golang-github-ngaut-deadline-dev
Version: 0.0~git20170224.0.71c16b1-1
Severity: normal
Tags: patch
Dear Maintainer,
please add a meaningful long-form description. Here's a suggestion.
Cheers,
-Hilko
@@ -17,4 +17,6 @@ Architecture: all
Depends: ${shlibs:Depends},
${misc:Depends}
Description: deadline reader/writer
- TODO: long description
+ This package provides convenience wrappers using a default timeout
+ value around Readers and Writers that also implement the
+ SetReadDeadline and SetWriteDeadline interfaces (such as net.Conn).
Bug#856711: "netlink/genl/genl.h: No such file or directory" although libnl-3-dev is installed
On Sat, Mar 04, 2017 at 06:10:28PM +0100, jean-christophe manciot wrote: > However, it seems that a .dsc file is necessary to build libpcap from > source with *sudo pbuilder build *.dsc*, and no such file exist with git > sources. > What am I missing? You need to build a source package first, please refer to the pbuilder user's manual. -- Romain Francoise https://people.debian.org/~rfrancoise/
Bug#856802: release.debian.org: unblock: sleuthkit/4.4.0-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team, please allow sleuthkit/4.4.0-5 into stretch. The symbols files for previous versions were incomplete which led to some mangled C++ symbols being tagged with the wrong default version number, 4.4.0, as specified in debian/rules. The problematic override... , | override_dh_makeshlibs: | dh_makeshlibs -- -v$(PVER) ` ... is still there but with the complete symbols specification it no longer has any effect. Cheers, -Hilko diff -Nru sleuthkit-4.4.0/debian/changelog sleuthkit-4.4.0/debian/changelog --- sleuthkit-4.4.0/debian/changelog 2017-01-25 23:31:47.0 +0100 +++ sleuthkit-4.4.0/debian/changelog 2017-02-25 17:34:05.0 +0100 @@ -1,3 +1,24 @@ +sleuthkit (4.4.0-5) unstable; urgency=medium + + * Upload to unstable. + + -- Joao Eriberto Mota Filho Sat, 25 Feb 2017 13:34:05 -0300 + +sleuthkit (4.4.0-4) experimental; urgency=medium + + * Fixed the symbols to support the x32 arch. +Thanks to Hilko Bengen . + + -- Joao Eriberto Mota Filho Sun, 19 Feb 2017 17:44:19 -0300 + +sleuthkit (4.4.0-3) experimental; urgency=medium + + * Split the symbols to improve the build over 32 and 64-bit architectures. +Thanks a lot to Hilko Bengen . This revision is relative +to #850828 (already closed). + + -- Joao Eriberto Mota Filho Sat, 18 Feb 2017 19:46:09 -0200 + sleuthkit (4.4.0-2) unstable; urgency=medium * Upload to unstable. diff -Nru sleuthkit-4.4.0/debian/libtsk13.symbols sleuthkit-4.4.0/debian/libtsk13.symbols --- sleuthkit-4.4.0/debian/libtsk13.symbols 2017-01-25 01:30:19.0 +0100 +++ sleuthkit-4.4.0/debian/libtsk13.symbols 2017-02-19 21:44:19.0 +0100 @@ -1,18 +1,20 @@ libtsk.so.13 libtsk13 #MINVER# +(arch=linux-i386 freebsd-i386 armel armhf mips mipsel hppa m68k powerpc powerpcspe sh4 x32)#include "libtsk13.symbols.32bit" +(arch=linux-amd64 freebsd-amd64 arm64 mips64 mips64el ppc64 ppc64el s390x alpha sparc64)#include "libtsk13.symbols.64bit" TSK_MD5_Final@Base 4.2.0 TSK_MD5_Init@Base 4.2.0 TSK_MD5_Update@Base 4.2.0 TSK_SHA_Final@Base 4.2.0 TSK_SHA_Init@Base 4.2.0 TSK_SHA_Update@Base 4.2.0 - (c++)"Guid::Guid()@Base" 4.3.0 - (c++)"Guid::Guid(Guid const&)@Base" 4.3.0 - (c++)"Guid::Guid(std::__cxx11::basic_string, std::allocator > const&)@Base" 4.3.0 - (c++)"Guid::Guid(std::vector > const&)@Base" 4.3.0 - (c++)"Guid::Guid(unsigned char const*)@Base" 4.3.0 - (c++)"Guid::operator=(Guid const&)@Base" 4.3.0 - (c++)"Guid::operator==(Guid const&) const@Base" 4.3.0 - (c++)"Guid::operator!=(Guid const&) const@Base" 4.3.0 + (c++)"Guid::Guid()@Base" 4.2.0 + (c++)"Guid::Guid(Guid const&)@Base" 4.2.0 + (c++)"Guid::Guid(std::__cxx11::basic_string, std::allocator > const&)@Base" 4.2.0 + (c++)"Guid::Guid(std::vector > const&)@Base" 4.2.0 + (c++)"Guid::Guid(unsigned char const*)@Base" 4.2.0 + (c++)"Guid::operator=(Guid const&)@Base" 4.2.0 + (c++)"Guid::operator==(Guid const&) const@Base" 4.2.0 + (c++)"Guid::operator!=(Guid const&) const@Base" 4.2.0 (c++)"hexDigitToChar(char)@Base" 4.3.0 (c++)"hexPairToChar(char, char)@Base" 4.3.0 (c++)"operator<<(std::basic_ostream >&, _TSK_DB_FILE_LAYOUT_RANGE const&)@Base" 4.2.0 @@ -158,7 +160,6 @@ (c++)"typeinfo name for TskAutoDb@Base" 4.2.0 (c++)"typeinfo name for TskDb@Base" 4.3.0 (c++)"typeinfo name for TskDbSqlite@Base" 4.3.0 - (c++)"void std::__insertion_sort<__gnu_cxx::__normal_iterator<_TSK_DB_FILE_LAYOUT_RANGE*, std::vector<_TSK_DB_FILE_LAYOUT_RANGE, std::allocator<_TSK_DB_FILE_LAYOUT_RANGE> > >, __gnu_cxx::__ops::_Iter_less_iter>(__gnu_cxx::__normal_iterator<_TSK_DB_FILE_LAYOUT_RANGE*, std::vector<_TSK_DB_FILE_LAYOUT_RANGE, std::allocator<_TSK_DB_FILE_LAYOUT_RANGE> > >, __gnu_cxx::__normal_iterator<_TSK_DB_FILE_LAYOUT_RANGE*, std::vector<_TSK_DB_FILE_LAYOUT_RANGE, std::allocator<_TSK_DB_FILE_LAYOUT_RANGE> > >, __gnu_cxx::__ops::_Iter_less_iter)@Base" 4.2.0 (c++)"void std::vector >::_M_emplace_back_aux(NTFS_META_ADDR const&)@Base" 4.3.0 (c++)"void std::vector, std::allocator >, std::allocator, std::allocator > > >::_M_emplace_back_aux, std::allocator > >(std::__cxx11::basic_string, std::allocator >&&)@Base" 4.3.0 (c++)"void std::vector >::_M_emplace_back_aux(TskAuto::error_record const&)@Base" 4.3.0 @@ -172,25 +173,6 @@ (c++)"vtable for TskAutoDb@Base" 4.2.0 (c++)"vtable for TskDb@Base" 4.3.0 (c++)"vtable for TskDbSqlite@Base" 4.3.0 - __cxa_allocate_dependent_exception@Base 4.2.0 - __cxa_allocate_exception@Base 4.2.0 - __cxa_begin_catch@Base 4.2.0 - __cxa_call_terminate@Base 4.2.0 - __cxa_call_unexpected@Base 4.2.0 - __cxa_current_exception_type@Base 4.2.0 - __cxa_deleted_virtual@Base 4.2.0 - __cxa_demangle@Base 4.2.0 - __cxa_end_catch@Base 4.2.0 - __cxa_free_dependent_exception@Base 4.2.0 - __cxa_free_exception@Base 4.2.0 - __cxa_get_exception_ptr@Base 4.2.0 - __cxa_get_globals@Base 4.2.0 - __cxa_get_globals_fast@Base 4.2.0 - __cxa_pure_virtual@Base 4.2.0 - _
Bug#854594: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed
On Sat, 2017-03-04 at 17:53 +0100, Julien Cristau wrote: > Is it multi-threaded? Does XInitThreads get called before any other X > function? It's a GTK (3) application so I assume multi-threaded yes. I've searched for XInitThreads in sources.debian.net but it doesn't seem to be called at all in gthumb or GTK3. There are gstreamer references though so I'll try to reproduce using a gstreamer pipeline in case that helps narrowing the problem. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#855920: Marking as unreproducible
Control: tag -1 - unreproducible
On Sat, 25 Feb 2017 15:43:13 +0100, Tomasz Buchert wrote:
> tags 855920 +unreproducible
> thanks
>
> I've run the build 10 times and it succeeded every time. The original
> report is probably due to some flakinesss. Marking as unreproducible.
I only tried once, and it immediately failed. This was in a sid
cowbuilder amd64 chroot. Log attached,
(Besides that I note that the package tries to access the internet
during building; AFAICS it tries to contact a DNS server.)
Cheers,
gregor
--
.''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Beatles
dpkg-checkbuilddeps: error: Unmet build dependencies: python3-pyinotify
dh-systemd
[1;33mW: Unmet build-dependency in source[0m
dh clean --with python3,systemd --buildsystem pybuild
dh_testdir -O--buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:184: python3.5 setup.py clean
running clean
removing
'/home/gregoa/src/NMUs/fail2ban/fail2ban-0.9.6/.pybuild/pythonX.Y_3.5/build'
(and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.5' does not exist -- can't clean it
debian/rules override_dh_clean
make[1]: Entering directory '/home/gregoa/src/NMUs/fail2ban/fail2ban-0.9.6'
rm -rf fail2ban.egg-info
rm debian/fail2ban.init
rm: cannot remove 'debian/fail2ban.init': No such file or directory
debian/rules:21: recipe for target 'override_dh_clean' failed
make[1]: [override_dh_clean] Error 1 (ignored)
dh_clean
: # auto generated
rm bin/fail2ban-python
make[1]: Leaving directory '/home/gregoa/src/NMUs/fail2ban/fail2ban-0.9.6'
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building fail2ban using existing ./fail2ban_0.9.6.orig.tar.gz
dpkg-source: info: building fail2ban in fail2ban_0.9.6-1.1.debian.tar.xz
dpkg-source: info: building fail2ban in fail2ban_0.9.6-1.1.dsc
[0mI: Generated dsc will be overwritten by build result; not generating
changes file[0m
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded
(cannot open shared object file): ignored.
[0mI: Copying COW directory[0m
[0mI: forking: rm -rf /var/cache/pbuilder/build/cow.28044[0m
[0mI: forking: cp -al /var/cache/pbuilder/base.cow
/var/cache/pbuilder/build/cow.28044[0m
[0mI: removed stale ilistfile /var/cache/pbuilder/build/cow.28044/.ilist[0m
[0mI: forking: chroot /var/cache/pbuilder/build/cow.28044
cowdancer-ilistcreate /.ilist 'find . -xdev -path ./home -prune -o \( \( -type
l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i ''[0m
[0mI: Invoking pbuilder[0m
[0mI: forking: pbuilder build --debbuildopts --debbuildopts --buildplace
/var/cache/pbuilder/build/cow.28044 --buildresult
/home/gregoa/src/NMUs/fail2ban --extrapackages ' eatmydata' --no-targz
--internal-chrootexec 'chroot /var/cache/pbuilder/build/cow.28044 cow-shell'
/home/gregoa/src/NMUs/fail2ban/fail2ban_0.9.6-1.1.dsc[0m
[0mI: Running in no-targz mode[0m
[0mI: using fakeroot in build.[0m
[1;33mW: pbuilder: network will not be disabled during build![0m
[0mI: Current time: Sat Mar 4 19:05:37 CET 2017[0m
[0mI: pbuilder-time-stamp: 1488650737[0m
[0mI: copying local configuration[0m
[0mI: mounting /proc filesystem[0m
[0mI: mounting /sys filesystem[0m
[0mI: creating /{dev,run}/shm[0m
[0mI: mounting /dev/pts filesystem[0m
[0mI: Mounting /var/cache/pbuilder/ccache[0m
[0mI: policy-rc.d already exists[0m
[0mI: Obtaining the cached apt archive contents[0m
[0mI: Setting up ccache[0m
[0mI: Copying source file[0m
[0mI: copying [/home/gregoa/src/NMUs/fail2ban/fail2ban_0.9.6-1.1.dsc][0m
[0mI: copying [/home/gregoa/src/NMUs/fail2ban/fail2ban_0.9.6.orig.tar.gz][0m
[0mI: copying
[/home/gregoa/src/NMUs/fail2ban/fail2ban_0.9.6-1.1.debian.tar.xz][0m
[0mI: Extracting source[0m
dpkg-source: warning: extracting unsigned source package
(fail2ban_0.9.6-1.1.dsc)
dpkg-source: info: extracting fail2ban in fail2ban-0.9.6
dpkg-source: info: unpacking fail2ban_0.9.6.orig.tar.gz
dpkg-source: info: unpacking fail2ban_0.9.6-1.1.debian.tar.xz
dpkg-source: info: applying deb_init_paths
dpkg-source: info: applying deb_manpages_reportbug
[0mI: Installing the build-deps[0m
[0mI: user script /var/cache/pbuilder/build/cow.28044/tmp/hooks/D10-man-db
starting[0m
I: Preseed man-db/auto-update to false
[0mI: user script /var/cache/pbuilder/build/cow.28044/tmp/hooks/D10-man-db
finished[0m
[0mI: user script /var/cache/pbuilder/build/cow.28044/tmp/hooks/D70build-area
starting[0m
I: Set APT=yes to run apt-get update.
[0mI: user script /var/cache/pbuilder/build/cow.28044/tmp/hooks/D70build-area
finished[0m
-> Attempting to satisf
Bug#856799: unblock: gmchess/0.29.6-2.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package gmchess unblock gmchess/0.29.6-2.1 diff -Nru gmchess-0.29.6/debian/changelog gmchess-0.29.6/debian/changelog --- gmchess-0.29.6/debian/changelog 2012-01-01 17:49:57.0 +0200 +++ gmchess-0.29.6/debian/changelog 2017-03-04 17:39:45.0 +0200 @@ -1,3 +1,10 @@ +gmchess (0.29.6-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * autoreconf to fix FTBFS on arm64. (Closes: #727872) + + -- Adrian Bunk Sat, 04 Mar 2017 17:39:45 +0200 + gmchess (0.29.6-2) unstable; urgency=low * Fix build on kfreebsd-* diff -Nru gmchess-0.29.6/debian/control gmchess-0.29.6/debian/control --- gmchess-0.29.6/debian/control 2011-10-21 18:34:57.0 +0300 +++ gmchess-0.29.6/debian/control 2017-03-04 17:39:45.0 +0200 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian Chinese Team Uploaders: Aron Xu -Build-Depends: debhelper (>= 8), autotools-dev, intltool (>= 0.35.0), gettext, perl (>= 5.8.1), libxml2, libglademm-2.4-dev (>= 2.6.0), libtool, imagemagick +Build-Depends: debhelper (>= 9.20160403~), autotools-dev, intltool (>= 0.35.0), gettext, perl (>= 5.8.1), libxml2, libglademm-2.4-dev (>= 2.6.0), libtool, imagemagick Standards-Version: 3.9.2 Homepage: http://code.google.com/p/gmchess/ diff -Nru gmchess-0.29.6/debian/rules gmchess-0.29.6/debian/rules --- gmchess-0.29.6/debian/rules 2011-10-21 18:34:57.0 +0300 +++ gmchess-0.29.6/debian/rules 2017-03-04 17:39:45.0 +0200 @@ -6,7 +6,7 @@ TMPDIR=debian/tmp %: - dh $@ + dh $@ --with autoreconf override_dh_auto_configure: dh_auto_configure -- \
Bug#805754: Processed: retitle to RFP: ensembl-tools -- Ensembl tools for genomic data processing
Hi Afif, you left an empty Git archive git://git.debian.org/git/debian-med/ensembl-tools.git Do you have any local repository with some preliminary work? Not that I have any specific interest - but I wonder whether there is some stuff hanging around which could help once somebody might like to work on this. Kind regards Andreas. On Fri, Feb 24, 2017 at 10:21:10AM +, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > > > retitle 805754 RFP: ensembl-tools -- Ensembl tools for genomic data > > processing > Bug #805754 [wnpp] ITP: ensembl-tools -- Ensembl tools for genomic data > processing > Changed Bug title to 'RFP: ensembl-tools -- Ensembl tools for genomic data > processing' from 'ITP: ensembl-tools -- Ensembl tools for genomic data > processing'. > > noowner 805754 > Bug #805754 [wnpp] RFP: ensembl-tools -- Ensembl tools for genomic data > processing > Removed annotation that Bug was owned by Debian Med Packaging Team > . > > stop > Stopping processing here. > > Please contact me if you need assistance. > -- > 805754: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805754 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > ___ > Debian-med-packaging mailing list > debian-med-packag...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging > -- http://fam-tille.de
Bug#856798: xfdesktop4: application menu on right click broken after editing launcher via menulibre
Package: xfdesktop4 Version: 4.12.3-3 Severity: normal Dear Maintainer, after installing menulibre and using it to edit menu items, the application menu functionality on right click of xfdesktop4 stops working and throws errors until xfdesktop4 is restarted. Steps to reproduce: 1. install menulibre 2. configure xfdesktop4 in such way, that the application menu is shown on right click on the desktop 3. open up menulibre 4. edit any launcher, e.g. select an icon and turn on 'Hide from menus' then save the launcher via the corresponding toolbar button Expected outcome: Menu entry should have been changed and the right click application menu on xfdesktop4 should continue to function with the changed launcher. Actual outcome: The application menu will not open on right click of xfdesktop4 anymore. A right click does nothing. Only killing and restarting xfdesktop4 helps. Additional Information: When pressing the save button in menulibre, the following xfdesktop4 error can be observed in ~/.xsession-errors log: (xfdesktop:8133): WARNING **: Unable to load menu: Error in Line 1, Sign 1: Document seems to be empty or it only contains empty space. Subsequent right clicks on xfdesktop4 will result in the following error: (xfdesktop:8133): GLib-CRITICAL **: g_node_last_child: assertion 'node != NULL' failed (xfdesktop:8133): garcon-CRITICAL **: garcon_menu_get_elements: assertion 'layout != NULL' failed -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfdesktop4 depends on: ii exo-utils0.10.7-1 ii libc62.24-9 ii libcairo21.14.8-1 ii libdbus-1-3 1.10.16-1 ii libdbus-glib-1-2 0.108-2 ii libexo-1-0 0.10.7-1 ii libgarcon-1-00.4.0-2 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.50.3-1 ii libgtk2.0-0 2.24.31-2 ii libnotify4 0.7.7-1+b1 ii libpango-1.0-0 1.40.3-3 ii libpangocairo-1.0-0 1.40.3-3 ii libthunarx-2-0 1.6.10-6 ii libwnck222.30.7-5.1 ii libx11-6 2:1.6.4-3 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util74.12.1-3 ii libxfconf-0-24.12.1-1 ii xfdesktop4-data 4.12.3-3 Versions of packages xfdesktop4 recommends: ii dbus-user-session [default-dbus-session-bus] 1.10.16-1 ii dbus-x11 [dbus-session-bus] 1.10.16-1 ii librsvg2-common 2.40.16-1+b1 ii tumbler 0.1.31-2+b3 ii xdg-user-dirs 0.15-2 Versions of packages xfdesktop4 suggests: pn menu -- no debconf information
Bug#856797: gnome-shell-pomodoro: New upstream 0.13.1 is ready.
Hi Richard, Yes, I'm already working on the packaging of this version right now. Will upload it to mentors in an hour or so. Joseph On Sat, Mar 4, 2017 at 9:43 AM, Richard Ayotte wrote: > Package: gnome-shell-pomodoro > Version: 0.13.0-1 > Severity: normal > > Upstream version 0.13.1 has been released. > > https://github.com/codito/gnome-pomodoro/releases/tag/0.13.1
Bug#856724: [INTL:da] Danish translation of the template apt-listbugs
On Sat, 4 Mar 2017 12:04:36 + (UTC) Joe Dalton wrote: [...] > Please include the attached Danish apt-listbugs translation. > Proofreading has given some small corrections. [...] Thanks for the update, I will soon take a look at it. Unfortunately, it is too late to have it included in Debian stretch (which is currently in full freeze, as you probably know). It will be included in an upload to Debian unstable (sid), and will migrate to Debian buster (after stretch is released as stable). -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpjpW3t3nGLt.pgp Description: PGP signature
Bug#855049:
Hi, Sorry for the late reply. Yes I saw that and I am planning to push the new release to mentors this morning. Joseph
Bug#856789: education-desktop-other: modifies conffiles (policy 10.7.3): /etc/plymouth/plymouthd.conf
On Sat, Mar 04, 2017 at 05:42:46PM +0100, Petter Reinholdtsen wrote: > [Andreas Beckmann] > > Package: education-desktop-other > [...] > > during a test with piuparts I noticed your package modifies conffiles. > > As education-desktop-other is a metapackage simply pulling in other > packages, the cause must be in some other package. I do not really have > any good idea which package it could be. The script update-debian-edu-artwork-softwaves (shipped with the package debian-edu-artwork-softwaves) causes it. This script is triggered after the packages plymouth and desktop-base have been installed and d-e-artwork is going to be set as default theme, including the one for plymouth. No easy way to fix this bug, I guess. IMO the only solution would be to drop the plymouth configuration from the script mentioned above and to let cfengine do the job after installation. IIRC it had been planned to use update-alternatives for the plymouth theme as well, but it has been too late for desktop-base to implement it for stretch. I guess this bug should be addressed to src:debian-edu-artwork. Wolfgang signature.asc Description: PGP signature
Bug#856652: RFS: xpdf/3.0.4.real-4
On Sat, 2017-03-04 at 08:02 -0700, Sean Whitton wrote: > Dear Jason, > > On Sat, Mar 04, 2017 at 12:00:19AM -0600, Jason Crain wrote: > > If you're going to adopt the Xpdf package, I thought you might want > > to > > know a little about Xpdf first and why the Debian package is the > > way > > that it is. The Debian package modifies Xpdf to make it use > > poppler > > (https://poppler.freedesktop.org) for rendering instead of using > > it's > > own internal code. I think this was done for security and bug > > fixes, > > and because the poppler upstream is more responsive than Xpdf. > > > > Poppler is a fork of Xpdf. Before poppler, it was common for > > applications which wanted to read PDFs to embed a copy of the Xpdf > > code. > > Poppler was created to turn sections of the Xpdf code into a > > library so > > that it could be more easily reused, to have a centralized place > > for > > development, and to put APIs over the code. I know about all this already. In fact I did port the code in January 2014 when it (3.03-11) was about to be removed from testing for Jessie. See the thread starting at https://lists.debian.org/debian-devel/2014/0 1/msg00254.html. These patches were not needed/accepted since somebody else had done the same work resulting in version 3.03-12. (I was never asked to publish my patches, and I did not check them versus the ones that went into the Debian package.) > > Debian's Xpdf is significantly different from upstream Xpdf. The > > package has build rules and patches which modify the code to be > > compatibile with poppler. Also, since the poppler devs do not > > guarantee > > stability for the old Xpdf functions, because those functions were > > never > > intended to be a stable interface, the patches will occasionally > > need to > > be modified to match any changes in poppler. This is the big problem, the two code bases are diverging. See a good description about the status of xpdf from December 2013: https://www.agwa.name/blog/post/the_sorry_state_of_xpdf_in_debian After my asking around to poppler and upstream Glyph & Cog, LLC, in the name of Derek B. Noonburg, created a new upstream release, 3.04. See the CHANGES file (changelog in the debian package) in the upstream tarball for the latest fixes. However, Debian chose to continue trying to catch up with the patches to libpoppler, in my opinion a very bad choice. The current state is really bad, most of the bugs are due to the use of the libpoppler backend. > Thank you very much for this input, Jason. > > It sounds like the source should not in fact be repacked. What do > you > think, Svante? The solution I've chosen is to remove the poppler backend completely. That fixes 11+ important and normal bugs (and probably many minor and wishlist ones too, I haven't looked into that yet) If somebody wants a poppler-based xpdf, it should be renamed to something else, e.g. ppdf, and maybe even be integrated in the poppler upstream code. Trying to merge xpdf frontend with the poppler backend is just a loosing battle. Just to give you a look into what I've done, I uploaded xpdf-3.04.real- 5 to mentors.debian.net. (Some minor changes are still needed I think, before I'm happy with the result). As said before: debdiff is not possible to use against 3.04-4, but it is with 3.04.real-4 and 3.04-5. Thanks for your attention, Svante
Bug#856797: gnome-shell-pomodoro: New upstream 0.13.1 is ready.
Package: gnome-shell-pomodoro Version: 0.13.0-1 Severity: normal Upstream version 0.13.1 has been released. https://github.com/codito/gnome-pomodoro/releases/tag/0.13.1
Bug#856796: ITP: bio-tradis -- analyse the output from TraDIS analyses of genomic sequences
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: bio-tradis Version : 1.3.1 Upstream Author : Wellcome Trust Sanger Institute * URL : https://github.com/sanger-pathogens/Bio-Tradis/ * License : GPL Programming Lang: Perl Description : analyse the output from TraDIS analyses of genomic sequences Bio-Tradis contains a set of tools to analyse the output from TraDIS analyses. . The Bio-Tradis analysis pipeline is implemented as an extensible Perl library which can either be used as is, or as a basis for the development of more advanced analysis tools. Remark: This package is maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/bio-tradis.git
Bug#856795: Please hide desktop entry in non-KDE desktops
Source: kde-spectacle Version: 16.08.3-2 Severity: important Hi, as most desktop environments bring their own snapshot utility, it would be good if org.kde.spectacle.desktop would not show up in the menu for those desktop environments. Please consider adding a OnlyShowIn=KDE; key or at least a NotShowIn=GNOME; Regards, Michael -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#321073: please add support for unionfs
Control: tags -1 - patch On Wed, Nov 15, 2006 at 09:41:14PM -0400, Anderson Lizardo wrote: > Hi, > > The attached patch adds support for unionfs snapshot in pbuilder. It's > based on a patch that I've made some time ago for version 0.128 [1], > but just recently I had some time to update it. > > I've tested it on Ubuntu 6.10 (kernel 2.6.17). It would be nice if > someone could test it on Debian unstable (I believe it will not work > on sarge) > > The patch is split in two parts: unionfs_harmless_changes.patch > contains changes that do not affect current functionality in any way > but are required by unionfs. The patch reorders some commands so that > BUILDPLACE is kept unchanged. > > The second patch (unionfs.patch) adds unionfs support. > > I've added some documentation in the man pages, but here is the basic > usage (assuming you already have a unpacked rootstrap in > /var/cache/pbuilder/build): > > pbuilder login --unionfs-snap /var/cache/pbuilder/unionfs-snap # login > to the rootstrap > pbuilder build --unionfs-snap /var/cache/pbuilder/unionfs-snap # build a > package > ... > > alternatively to the "--unionfs-snap" parameter, you can add this line > to .pbuilderrc: > > UNIONFS_SNAP=/var/cache/pbuilder/unionfs-snap/ > > and just use: > > pbuilder login > pbuilder build > ... > > To change the base rootstrap location, use "--buildplace " or > change BUILDPLACE= in .pbuilderrc. > > KNOWN ISSUE: > > - due to a limitation in unionfs, some packages that use > /proc/self/exe symlink to check for their full path (e.g. many perl > modules) may fail to build. This is fixed in recent unionfs releases, > but is disabled by default because it's experimental (look for > UNIONFS_MMAP in unionfs' INSTALL file). > > [1] http://www.mail-archive.com/ubuntu-motu@lists.ubuntu.com/msg00553.html Hi, It's been 11 years since this patch was posted. I very much doubt it still applies, but even if it did, overlayfs is the new unionfs, so this won't work. I personally don't think this belongs in pbuilder (there's cowbuilder, which wraps pbuilder to provide copy-on-write chroots via LD_PRELOAD overriding libc functions, so perhaps there could be an overlayfsbuilder (needs a snappier name)), but I'm not the primary maintainer so that's just my opinion. Regards, James
Bug#855049:
This bug has been fixed in 0.13.1 https://github.com/codito/gnome-pomodoro/issues/277
