Bug#868316: cups-bsd: lpr does not print with "DefaultPolicy authenticated" in cupsd.conf
Le mardi, 29 août 2017, 09.00:57 h CEST Christoph Pleger a écrit : > The request has already been acted on and the issue is closed. They did > not exactly apply my patch, but their solution does quite the same. Yep. I've seen; I am uploading the upstream snapshot to experimental and will backport that patch to unstable immediately after. Thank you very much for your time and energy! Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#873566: ntfs-3g: Please update ntfs-3g to 2017.3.23
On Tue, Aug 29, 2017 at 4:21 AM, shirish शिरीष wrote: > Upstream released a new version of ntfs-3g on March 28 STABLE Version > 2017.3.23 (March 28, 2017) [...] > Link for the source-code > https://tuxera.com/opensource/ntfs-3g_ntfsprogs-2017.3.23.tgz This is often mixed. :( Debian packaging follows the Advanced Releases (ARs) as those are more mature with testing and should have the same feature set like the 'stable' noted releases. Cheers, Laszlo/GCS
Bug#873558: Updating the vobcopy Uploaders list
Hallo Steven, Am Dienstag, den 29.08.2017, 01:36 +0100 schrieb Stephen Birch: > Hi Tobias > > I'm still around but have not been active. Do you want me to step > up? Missing activity triggered my action as part of the MIA team, so sorry if I misses some activity from your side as I could only find some upload in 2007. So if you consider yourself still active, please close this bug and please work on the bugs in package. Debian is a doocracy afterall* ;-) Thanks and sorry for the inconvenience, Tobi * and activities are very effective for scaring away the MIA team ;-) > Steve > > > > On 29 Aug 2017, at 00:11, Tobias Frost wrote: > > > > Source: vobcopy > > Version: 1.2.0-6 > > Severity: minor > > User: m...@qa.debian.org > > Usertags: mia-teammaint > > > > Stephen Birch has not been working on > > the vobcopy package for quite some time. > > > > We are tracking their status in the MIA team and would like to ask > > you > > to remove them from the Uploaders list of the package so we can > > close > > that part of the file. > > > > (If the person is listed as Maintainer, what we are asking is to > > please > > step in as a new maintainer.) > > > > Thanks.
Bug#873566: Please update ntfs-3g to 2017.3.23
shirish शिरीष wrote: at bottom :- On 29/08/2017, Jean-Pierre André wrote: Upstream released a new version of ntfs-3g on March 28 STABLE Version 2017.3.23 (March 28, 2017) Here are the release notes - hanges to NTFS-3G: Delegated processing of special reparse points to external plugins Allowed kernel cacheing by lowntfs-3g when not using Posix ACLs Enabled fallback to read-only mount when the volume is hibernated Made a full check for whether an extended attribute is allowed Moved secaudit and usermap to ntfsprogs (now ntfssecaudit and ntfsusermap) Enabled encoding broken UTF-16 into broken UTF-8 Autoconfigured selecting vs Allowed using the full library API on systems without extended attributes support Fixed DISABLE_PLUGINS as the condition for not using plugins Corrected validation of multi sector transfer protected records Denied creating/removing files from $Extend Returned the size of locale encoded target as the size of symlinks Please note that all these changes are included into 2016.2.22AR.2 Dear Jean-Pierre André , It is very much possible that you are right, as I saw in changelog.Debian.gz the following - ┌─[shirish@debian] - [/usr/share/doc/ntfs-3g] - [10005] └─[$] zless changelog.Debian.gz ntfs-3g (1:2016.2.22AR.2-2) unstable; urgency=medium * Start the transition with upload to Sid. > [...] The full changelog is available on : http://jp-andre.pagesperso-orange.fr/changelog.html
Bug#873576: ruby-rest-client: FTBFS without network access
Source: ruby-rest-client
Version: 2.0.2-2
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful
Hi Lucas,
In Ubuntu, ruby-rest-client is failing to build because its test suite
depends on access to the Internet. First error in the logs:
Failures:
1) RestClient::Request timeouts raises ReadTimeout when it hits a read
timeout via :read_timeout
Failure/Error:
expect { request.execute }.to(
raise_error(RestClient::Exceptions::ReadTimeout))
expected RestClient::Exceptions::ReadTimeout, got # with backtrace:
# ./lib/restclient/request.rb:715:in `transmit'
# ./lib/restclient/request.rb:145:in `execute'
# ./spec/integration/request_spec.rb:33:in `block (4 levels) in '
# ./spec/integration/request_spec.rb:33:in `block (3 levels) in '
# ./spec/integration/request_spec.rb:33:in `block (3 levels) in '
(https://launchpad.net/ubuntu/+source/ruby-rest-client/2.0.2-2/+build/13150212)
Packages should not require access to third-party network servers in order
to build, and I believe several of the Debian buildds have policies that
block network access during builds by design, so I think this should be
considered a serious bug.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
Bug#873566: Please update ntfs-3g to 2017.3.23
On Tue, Aug 29, 2017 at 8:37 AM, shirish शिरीष wrote: > On 29/08/2017, Jean-Pierre André wrote: >>> Upstream released a new version of ntfs-3g on March 28 STABLE Version >>> 2017.3.23 (March 28, 2017) [...] >> Please note that all these changes are included into 2016.2.22AR.2 Indeed and it's packaged and already part of Debian. > It is very much possible that you are right, as I saw in > changelog.Debian.gz the following - [...] Upstream changes are not repeated in Debian changelog unless that has a strong impact on packaging - ie big feature change, package split or similar. > Although changelog.gz doesn't mention any of this - [...] > So the changelog.gz or either changelog.Debian.gz doesn't make mention > any of the new features :( That doesn't mean the new features are not present. But sure, let's see if upstream re-confirms it or know any missing feature. Regards, Laszlo/GCS
Bug#868316: cups-bsd: lpr does not print with "DefaultPolicy authenticated" in cupsd.conf
Hello, You might want to edit your pull-request to either target the branch-2.1 from upstream, or rebase yours on top of upstream's master; as-it-is it's quite confusing :-/ The request has already been acted on and the issue is closed. They did not exactly apply my patch, but their solution does quite the same. Regards Christoph
Bug#873577: datefudge breaks AddressSanitizer (and probably others)
Package: datefudge
Version: 1.22
Severity: normal
Hi,
datefudge.so gets prepended to the LD_PRELOAD list, so after
experimenting with the automatic approaches for a while I propose a
simple patch that adds environment variable DATEFUDGE_LD_PRELOAD that
can be used to inject *Sanitizer libraries as first in the list.
Cheers,
Ondrej
-- System Information:
Debian Release: 9.1
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'),
(500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.4.0-83-generic (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8),
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages datefudge depends on:
ii libc6 2.24-11+deb9u1
datefudge recommends no packages.
datefudge suggests no packages.
-- no debconf information
>From 42c30e4a31b36fb4ee0eca3d63ffc36559a8ea3d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ond=C5=99ej=20Sur=C3=BD?=
Date: Tue, 29 Aug 2017 08:47:08 +0200
Subject: [PATCH] Add DATEFUDGE_LD_PRELOAD support to allow prepending
*Sanitizer libraries as first in the path
---
datefudge.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/datefudge.sh b/datefudge.sh
index ad5ca3c..9699045 100755
--- a/datefudge.sh
+++ b/datefudge.sh
@@ -59,6 +59,9 @@ set_ld_environment()
add_ld_library_path "${path%/*}"
done
add_ld_preload "$lib"
+ if [ "$DATEFUDGE_LD_PRELOAD" ]; then
+ add_ld_preload "$DATEFUDGE_LD_PRELOAD"
+ fi
}
set_datefudge_vars()
--
2.11.0
Bug#789927: libanthyinput0: fails to upgrade from 'sid' - trying to overwrite /usr/lib/x86_64-linux-gnu/libanthyinput.so.0.0.0'
Hi, this isn't resolved yet: Package: libanthy0,libanthyinput0 Version: libanthy0/9100h-25+b2 Version: libanthyinput0/1:0.3-4 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2017-08-29 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: Selecting previously unselected package anthy-common. (Reading database ... 11002 files and directories currently installed.) Preparing to unpack .../anthy-common_1%3a0.3-2_all.deb ... Unpacking anthy-common (1:0.3-2) ... Selecting previously unselected package libanthy0:amd64. Preparing to unpack .../libanthy0_9100h-25+b2_amd64.deb ... Unpacking libanthy0:amd64 (9100h-25+b2) ... Selecting previously unselected package libanthy1:amd64. Preparing to unpack .../libanthy1_1%3a0.3-2_amd64.deb ... Unpacking libanthy1:amd64 (1:0.3-2) ... Selecting previously unselected package libanthyinput0:amd64. Preparing to unpack .../libanthyinput0_1%3a0.3-2_amd64.deb ... Unpacking libanthyinput0:amd64 (1:0.3-2) ... dpkg: error processing archive /var/cache/apt/archives/libanthyinput0_1%3a0.3-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libanthyinput.so.0.0.0', which is also in package libanthy0:amd64 9100h-25+b2 Processing triggers for libc-bin (2.24-15) ... Errors were encountered while processing: /var/cache/apt/archives/libanthyinput0_1%3a0.3-2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) This is a serious bug as it makes installation fail, and violates sections 7.6.1 and 10.1 of the policy. An optimal solution would consist in only one of the packages installing that file, and renaming or removing the file in the other package. Depending on the circumstances you might also consider Replace relations or file diversions. If the conflicting situation cannot be resolved then, as a last resort, the two packages have to declare a mutual Conflict. Please take into account that Replaces, Conflicts and diversions should only be used when packages provide different implementations for the same functionality. Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/lib/x86_64-linux-gnu/libanthyinput.so.0 /usr/lib/x86_64-linux-gnu/libanthyinput.so.0.0.0 This bug has been filed against both packages. If you, the maintainers of the two packages in question, have agreed on which of the packages will resolve the problem please reassign the bug to that package. You may then also register in the BTS that the other package is affected by the bug. -Ralf. PS: for more information about the detection of file overwrite errors of this kind see http://qa.debian.org/dose/file-overwrites.html.
Bug#818968: Long live Oysttyer
Hi Thorsten, On Sat, August 26, 2017 16:44, Thorsten Alteholz wrote: > Hi, > > I just wanted to tell everybody that oysttyer just entered unstable. > > Thorsten Thanks! Do you think it would be useful if oysttyer would also provide a transitional package ttytter, or should we remove ttytter wholesale now? Cheers, Thijs
Bug#873578: xserver-xorg-video-all: Consider removing xserver-xorg-video-intel as Recommended, or downgrade to Suggested
Package: xserver-xorg-video-all Version: 1:7.7+19 Severity: wishlist Dear Maintainer, The description of the package `xserver-xorg-video-intel` says: > The use of this driver is discouraged if your hw is new enough (ca. 2007 and newer). You can try uninstalling this driver and let the server use it's builtin modesetting driver instead. I think it is safe to assume that in 2017, the vast majority of Debian users will have hardware meeting this criteria, so having `xserver-xorg-video-all` Recommend `xserver-xorg-video-intel` seems wrong. For almost all users, having `xserver-xorg-video-intel` not recommended at all, or at the very least downgraded to Suggested status, would make much more sense. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (700, 'unstable'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xserver-xorg-video-all depends on: ii xserver-xorg-video-amdgpu 1.3.0-1 ii xserver-xorg-video-ati 1:7.9.0-1 ii xserver-xorg-video-fbdev1:0.4.4-1+b5 ii xserver-xorg-video-nouveau 1:1.0.15-2 ii xserver-xorg-video-vesa 1:2.3.4-1+b2 ii xserver-xorg-video-vmware 1:13.2.1-1+b1 Versions of packages xserver-xorg-video-all recommends: pn xserver-xorg-video-intel pn xserver-xorg-video-qxl xserver-xorg-video-all suggests no packages. -- no debconf information
Bug#868894: find_package option COMPONENTS ineffective because of hard-coded includes in TrilinosConfig.cmake
finally I reported it upstream at https://github.com/trilinos/Trilinos/issues/1655 - Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#865208: [Pkg-nginx-maintainers] Bug#865208: nginx: Package build against OpenSSL 1.0.2-t instead of 1.1.0-f
control: tags -1 wontfix On Tue, Jun 20, 2017 at 10:25:17AM +0300, Christos Trochalakis wrote: Hello Angelique, Closing that.
Bug#873579: suggestions to improve git-shell
Package: git Version: 1:2.14.1-2 Severity: wishlist File: /usr/bin/git-shell Dear Maintainer, I am writing this to the Debian Bug Tracker because I didn't find any issue tracker upstream that is actually monitored for non-bugs, and because I believe that a message written to the mailing list containing suggestions without patches are likely to be ignore if the suggestions come from a nobody like me. Please feel free to forward whereever you feel it appropriate. As a professional sysadmin, I frequently use ssh, passphraseless keys and ssh-forced-commands to invoke jobs remotely and securely. I usually use a script as forced command that parses SSH_ORIGINAL_COMMAND and executes the allowed commands. I have blogged about that in German in http://blog.zugschlus.de/archives/982-Login-als-technischer-User-mit-ssh-forced-commands.html, but the shell script should be international. I have recently talked to a colleague who uses git-shell for those tasks, even those that are not git-related. Actually, I find that idea quite neat. However, I do have some suggestions to make things even more easy. Basically, my intended use of git-shell is to have git-shell replace the if-elif-cascade in the ssh-forced-command script, having the subcommands made available by the script in the git-shell-command directory instead. (1) When using git-shell, the remote users gets git access to all git repositories that are readable by the user. This might not be wanted. Please consider a configuration file or a list of paths on the git-shell command line, so that the local admin can restrict the git repositories a git-shell user can access, including up to /nonexistent for "no access to git repositories at all". (2) Please consider adding an option --ssh-original-command which makes git-shell consider the contents of $SSH_ORIGINAL_COMMAND as its command line. This would allow using git-shell as "command" in an authorized_keys line, while enabling the user to still give commands on the ssh command line as if the account were open. Validation and parsing of the parameters can be done by git-shell and the program called from git-shell-commands. Thanks for your consideration. Greetings Marc
Bug#873580: mate-settings-daemon: Failed to acquire org.mate.SettingsDaemon
Package: mate-settings-daemon Version: 1.18.1-2 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * My problem is that the language icon is missing. * With the command "mate-settings-daemon --replace" the icon appears. * You can check and review it: http://imgur.com/a/7ox2V * The outcome through cmdline is: Failed to acquire org.mate.SettingsDaemon, and the output of "--replace" is:[1503983734,000,xklavier.c:xkl_engine_start_listen/] The backend does not require manual layout management - but it is provided by the application, and (mate-settings-daemon:5903): Gdk-CRITICAL **: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed. *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mate-settings-daemon depends on: ii libatk1.0-0 2.24.0-1 ii libc62.24-14 ii libcairo-gobject21.14.10-1 ii libcairo21.14.10-1 ii libcanberra-gtk3-0 0.30-3 ii libcanberra0 0.30-3 ii libdbus-1-3 1.11.16+really1.10.22-1 ii libdbus-glib-1-2 0.108-2 ii libdconf10.26.0-2+b1 ii libfontconfig1 2.12.3-0.2 ii libfreetype6 2.8-0.2 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.53.4-3 ii libgtk-3-0 3.22.18-1 ii libice6 2:1.0.9-2 ii libmate-desktop-2-17 1.18.0-1 ii libmatekbd4 1.18.2-1 ii libmatemixer01.18.0-1 ii libnotify4 0.7.7-2 ii libnspr4 2:4.16-1 ii libnss3 2:3.31-1 ii libpango-1.0-0 1.40.6-1 ii libpangocairo-1.0-0 1.40.6-1 ii libpolkit-gobject-1-00.105-18 ii libpulse010.0-2 ii libsm6 2:1.2.2-1+b3 ii libstartup-notification0 0.12-4+b2 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxi6 2:1.7.9-1 ii libxklavier165.4-2 ii mate-desktop-common 1.18.0-1 ii mate-polkit 1.18.1-1 ii mate-settings-daemon-common 1.18.1-2 ii x11-xserver-utils7.7+7+b1 mate-settings-daemon recommends no packages. mate-settings-daemon suggests no packages. -- no debconf information
Bug#871779: [Pkg-samba-maint] Bug#871779: /sbin/mount.cifs: Some remote folders missing when mounting the share using -o vers=2.x option
Here are the files, Yes, I tried vers=3.0 too, same result Regards Thibault On 08/17/2017 10:47 AM, Mathieu Parent wrote: > [...] >> Then when mounting the same folder with >> mount -t cifs //host-address/share -o >> username=user,password=mypassword,ro,vers=2.1 /path/to/folder/ >> > [...] >> The $RECYCLE.BIN folder is missing but also the byuno folder >> I would say I don't care about the RECYCLE.BIN one as it's the trash but the >> other one should be there. >> I checked the permissions/owner of this folder, it's the same as the others. > Have you tried vers=3.0? > > Can you provide a network capture (including the mount abd the ls): > - without vers=2.1 to win7 > - with vers=2.1 to win7, > - to win10 with cifs1.0 enabled > - to win10 with cifs1.0 disabled > > See https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Wire_Captures > > > Regards bug-smb.tar.gz Description: application/gzip
Bug#872626: python-statistics is already in experimental
Hi Ben, > Some more issues (some of these are issues I've reported upstream): > > * The GitHub repository has only one release made available > https://github.com/digitalemagine/py-statistics/releases>, and > has none of the versions from the PyPI page > https://github.com/digitalemagine/py-statistics/issues/4>. > > * The version at GitHub, version “3.4.0b3”, is not available > at PyPI https://pypi.org/project/statistics/> > https://github.com/digitalemagine/py-statistics/issues/5>. > > So for distributions depending on the version at PyPI, currently > “1.0.3.5”, it's not clear that they will work correctly with this > later version. > > * The Debian package version does not mangle the version to place > “3.4.0b3” earlier than (what will presumably be released later as) > “3.4.0”. When upstream makes a “3.4.0” release, it will sort > *earlier* in Debian than the existing upstream version “3.4.0b3”. > > This can be corrected with an appropriate change to the version > string for future Debian releases, but that doesn't solve the issue > for the already-released “3.4.0b3-1”. > > What are your thoughts on addressing these? Upstream has been quite responsive until now, so I propose to speak about it with him. Concerning the latter issue, there's no magic solution and this problem has been discussed for quite a while[0]. I like the 3.4.0final-1 solution because it avoids epoch usage. This is also the kind of problems we can discuss with upstream. Do you have any personal preferences ? Regards, Hugo [0] https://lists.debian.org/debian-dpkg/1998/06/msg00128.html -- Hugo Lefeuvre (hle)|www.owl.eu.com 4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA signature.asc Description: PGP signature
Bug#873520: lintian: Check for bad-distribution in debian/changelog too
Hey Jeremy,
> I was surprised to see that pyjunitxml 0.6-1.2 was accepted into
> Debian unstable with its debian/changelog still set to UNRELEASED. I
> guess the uploader managed to generate a valid .changes file.
I would be interested to know the story there!
> lintian already has a check for bad-distribution-in-changes-file
Indeed. A quick glance suggests that a little bit of refactoring would
be needed to avoid egregious code duplication between changes-file.pm
and changelog-file.pm, however.
Lintian devs; where might you suggest a "is_valid_distribution" utility
could live? It needs to do the -backports (etc.) stripping, etc.
Alternatively, could we just warn when $entries[0]->Distribution doesn't
match $info->field('distribution')..? Is this ever a sane thin to do?
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
Bug#873581: certbot: Excessive logging
Package: certbot Version: 0.10.2-1~bpo8+1 Severity: normal Certbog logs to /var/log/letsencrypt.log using DEBUG as the default log level. It rotates the log on each invocation, i.e. (at least) daily. If I understand correctly (main.py:setup_log_file_handler), 1000 log files are retained. On my server, I have hundreds of small log files: # ls /var/log/letsencrypt|wc -l 597 Most of the debug information contained in the logs are not very useful for sysadmins and it is quite difficult to find any relevant information about certificate renewals etc. Please consider making the log level configurable and make the default "info". Also it would be nice, if logrotate would handle log rotation, so the sysadmin could easily modify the rotation behaviour. Better yet, the possibility of logging directly into systemd journal would be great. -- System Information: Debian Release: 8.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages certbot depends on: ii init-system-helpers 1.22 ii python 2.7.9-1 ii python-certbot 0.10.2-1~bpo8+1 pn python:any certbot recommends no packages. Versions of packages certbot suggests: ii python-certbot-apache 0.10.2-1~bpo8+1 pn python-certbot-doc -- debconf-show failed
Bug#873582: python-boto3: Please package new upstream version
Source: python-boto3 Severity: normal Dear Maintainer, please consider packaging he nsw upstream version. The new version is e.g required for some new upstream releases of at least one rdep -- python-mrjob ; hence the prio normal. thanks for your contributions to debian. -- tobi
Bug#872626: python-statistics is already in experimental
On 29-Aug-2017, Hugo Lefeuvre wrote: > Upstream has been quite responsive until now, so I propose to speak > about it with him. That's a good situation :-) > Concerning the latter issue, there's no magic solution and this > problem has been discussed for quite a while[0]. I like the > 3.4.0final-1 solution because it avoids epoch usage. Avoiding epoch usage is nice (Though epoch is also fine, to solve an issue like this). In the years since that 1998 discussion, Debian Policy has an almost magic solution: an explicit rule for making some longer version strings compare earlier than shorter ones. 5.6.12. Version […] When comparing two version numbers […] The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters and so that a tilde sorts before anything, even the end of a part. For example, the following parts are in sorted order from earliest to latest: "~~", "~~a", "~", the empty part, "a". […] One common use of ~ is for upstream pre-releases. For example, 1.0~beta1~svn1245 sorts earlier than 1.0~beta1, which sorts earlier than 1.0. ‘dpkg --compare-versions’ now follows this algorithm. The version string “3.4.0~b3” will compare earlier than “3.4.0”. So we can instruct UScan to mangle the upstream version string, separating known pre-release markers by a “~” character to get the Debian upstream version string. For an example, see the packaging for ‘pysha3’ (the ‘debian/watch’ file). > Do you have any personal preferences ? For the immediate issue, we could have “3.4.0final-1” just to address the existing prior Debian version. In parallel, I think that the above upstream version mangling by UScan should be part of the Debian packaging; that will address future version strings from upstream. -- \ “The most dangerous man to any government is the man who is | `\ able to think things out for himself, without regard to the | _o__) prevailing superstitions and taboos.” —Henry L. Mencken | Ben Finney signature.asc Description: PGP signature
Bug#873583: tortoisehg: needs update for mercurial 4.3
Source: tortoisehg Version: 4.0-1 Severity: serious X-Debbugs-Cc: Tristan Seligmann tortoisehg depends on mercurial (<< 4.1~). mercurial's recently fixed security issues are currently held up in unstable because of this. Cheers, Julien
Bug#857090: update-command-not-found does nothing
Sorry for my late response... > This seems to be the case when you run update-command-not-found without any > Contents-file downloaded. If you run "apt update" after installation it > works without problems. Thanks for the hint. > I think update-command-not-found should make it clearer that you need to > update the apt-cache prior to running it. Indeed, that would be great. -- With kind regards, Christian Schrötter
Bug#873499: Should depend on "gnupg | gnupg2 | gpg"
On Tue, Aug 29 2017, Colin Watson wrote: > This package contains /usr/bin/gpg itself, and is useful on its own > only for public key operations (encryption, signature verification, > listing OpenPGP certificates, etc). If you want full capabilities > (including secret key operations, network access, etc), please > install the "gnupg" package, which pulls in the full suite of tools. > > pass requires secret key operations, not just public key operations. I've been using pass with gpg only already since gpg 2.1.23 became available using an equivs package to fulfill the dependency. Can you make an example of a "secret key operation"? I think gpg's description is misleading. gpg can definitely generate and manipulate secret keys by itself for example. The only difference is that you need to depend on dirmngr/gpgsm or the tools package explicitly.
Bug#872626: python-statistics is already in experimental
> For the immediate issue, we could have “3.4.0final-1” just to address > the existing prior Debian version. > > In parallel, I think that the above upstream version mangling by UScan > should be part of the Debian packaging; that will address future > version strings from upstream. Agree. I didn't think about that when packaging 3.4.0b3, thanks for the recommendation. By the way, my key was just replaced in the keyring, so if you want I can upload the package to unstable. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com 4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA signature.asc Description: PGP signature
Bug#873476: coreutils: /bin/cat doesnt display a line of a txt file without an end of line [shell prompt problem]
Le 29/08/2017 à 00:51, Bob Proulx a écrit : I was confused because this file used to be "displayable" with the cat command (which is very handy to do this kind of thing). I can guess that your prompt has probably gotten fancier. But regardless this is a good thing to find anyway. Because shouldn't that troublesome VERSION file have a newline at the end? Sounds like a worthwhile task to go poke at on that project. The program (namely displaycal: https://displaycal.net/) is not written specifically for Linux and not on a Linux system. This is a Python program and the author uses MS Windows (c) (r) with "some" EDI. Probably this file is used to concatenate (!) it with other files (there is also a VERSION_BASE file) and this is used internally by the program at build time. Regards Jean-Luc
Bug#873584: gcc-7: compiles in ARM mode instead of Thumb on armhf
Package: gcc-7 Severity: important X-Debbugs-CC: debian-...@lists.debian.org Hi, It appears that gcc-7 no longer compiles in Thumb mode by default on armhf. My guess is that it was caused by this change which was intended to remove all the java / gcj code: https://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-7/debian/rules.defs?r1=9038&r2=9039 The part at the top with the "with_arm_thumb" assignments should be reverted. Maybe there should be a mass-rebuild after this, but I'll let the ARM porters deal with that :) Thanks, James signature.asc Description: OpenPGP digital signature
Bug#873585: replace is not encoding agnostic anymore
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Package: ansible
Version: 2.3.1.0+dfsg-2
Severity: important
I have the following stuff in my ansible tasks:
{{{yaml
- - name: Keep all passwd-entries in /etc/password sane
replace:
dest: /etc/passwd
regexp: '^([^:]+):[^:]*:'
replace: '\1:x:'
}}}
This was working without problems until the update to 2.3. The reason is
that replace is not encoding agnostic anymore and you have to specify an
encoding. Unfortunatelly there are two problems with that:
- - /etc/passwd has different encodings in every line (The gecos field
with the name) So there cannot be a encoding specified for the whole
file.
- - Even if I specify the encoding, the playbook is used in old versions
too (mainly on stable debian or devuan) and there, an encoding
parameter will create an error.
In the end, utf8 is the worst charset for something that should be
robust as utf8 has holes and unspeciffied chars in the specifkation.
This problem currently produce the following failure on all machines
with unstable (3):
TASK [security : Keep all passwd-entries in /etc/password sane]
An exception occurred during task execution. To see the full traceback, use
-vvv. The error was: UnicodeDecodeError: 'utf8' codec can't decode byte 0xee in
position 668: invalid continuation byte
fatal: [ikki]: FAILED! => {"changed": false, "failed": true,
"module_stderr": "Traceback (most recent call last):\n File
\"/tmp/ansible_jSTtga/ansible_module_replace.py\", line 200, in \n
main()\n File \"/tmp/ansible_jSTtga/ansible_module_replace.py\", line 169, in
main\ncontents = to_text(f.read(), errors='surrogate_or_strict')\n File
\"/tmp/ansible_jSTtga/ansible_modlib.zip/ansible/module_utils/_text.py\", line
232, in to_text\n File \"/usr/lib/python2.7/encodings/utf_8.py\", line 16, in
decode\nreturn codecs.utf_8_decode(input, errors,
True)\nUnicodeDecodeError: 'utf8' codec can't decode byte 0xee in position 668:
invalid continuation byte\n", "module_stdout": "", "msg": "MODULE FAILURE",
"rc": 0}
The character that breaks stuff is a name of one of my users: Benoït
which is not that uncommon.
- -- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (400, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.11.9 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE=de_DE:en
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages ansible depends on:
ii python2.7.13-2
ii python-crypto 2.6.1-7+b1
ii python-httplib2 0.9.2+dfsg-1
ii python-jinja2 2.9.6-1
ii python-netaddr0.7.18-2
ii python-paramiko 2.0.0-1
ii python-pkg-resources 36.2.7-2
ii python-yaml 3.12-1+b1
Versions of packages ansible recommends:
ii python-cryptography 1.9-1
pn python-jmespath
pn python-kerberos
pn python-libcloud
pn python-selinux
pn python-winrm
pn python-xmltodict
Versions of packages ansible suggests:
pn cowsay
ii sshpass 1.06-1
- -- Configuration Files:
/etc/ansible/ansible.cfg changed:
[defaults]
gathering = smart
ansible_managed = Ansible managed file
retry_files_enabled = False
[privilege_escalation]
become_method = su
[paramiko_connection]
[ssh_connection]
pipelining = True
[accelerate]
[selinux]
[colors]
- -- no debconf information
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1
iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlmlMacACgkQpnwKsYAZ
9qxL7Qv/fizyzuSc5a3qN/yrAsq+jwa3dPylUJxaHfP5MX4a4Rh440MfE8iLJ9AW
rmLSzeULMogx3JoFok0v1bQTmtXUnNkTEIJcfjAkLuamOOH1UNMeibmS+pCr8VrO
RB2UEgiXWluOaXxz75EAQA+TrcVCweXmR6mCq9oXHnTZG+Kzse6O6lBDj/DmkKn5
Jkc+diIZ7qUuGsY13PZnvtvf1fDnPnlZ1Y88f+EpGgVj9dGQYOS/24znB9U1on/T
wzUFVf1+DpVDPuUHAwu1BIjxnSU0cxEGFiBRstmBLQSFusI0fuHaZxRS1VFTLhIb
xrzhsWM2mMXuCAiifinw9qQ+fj4IwdP5mm7O0aejO0wZQEtqbRNFDamXNRvyOa3K
Bt61ASedzz2kBn6NIapmnsBYfsJWLlpdttY9reQaF7eqoFLCZkaFwvXfTWxu3ds9
kSTyIhkth1XfWfyylDXJPHoGn8ZmtJDQ8iLAErzXyygg5wS88jYpvQqQYZP30uSv
78gwFm4s
=d4y3
-END PGP SIGNATURE-
Bug#873560: Updating the startup-notification Uploaders list
Control: tags -1 + pending Hello Tobias Frost, On Tue, Aug 29, 2017 at 01:25:28AM +0200, Tobias Frost wrote: > Source: startup-notification > Version: 0.12-4 > Severity: minor > User: m...@qa.debian.org > Usertags: mia-teammaint > > The Debian account of J.H.M. Dassen (Ray) , > listed in the Uploaders list of startup-notification, has been shut down > by the Debian Account Managers. [...] Please note that startup-notification uploaders are generated via @GNOME_TEAM@ in debian/control.in from the last X debian/changelog entries and the pkg-gnome.team list from gnome-pkg-tools package. I've removed jdassen from pkg-gnome.team list in https://anonscm.debian.org/viewvc/pkg-gnome/tools/gnome-pkg-tools/pkg-gnome.team?r1=52738&r2=52914 thus tagging this as pending. Remaining is: - actually upload the gnome-pkg-tools change to the archive. - rebuild startup-notigfication package (and any other package where he might still be in uploaders of via @GNOME_TEAM@). Once that's done he should no longer be part of uploaders. The same scheme is used by all pkg-gnome team maintained packages and thus dropping someone can be handled centrally in gnome-pkg-tools package (unless they've hard-coded themselves into Uploaders field). Regards, Andreas Henriksson
Bug#839748: Taking RFP
retitle -1 ITP: golang-gopkg-flosch-pongo2.v3 -- Django-syntax like template-engine for Go owner ! thanks
Bug#873586: lua-torch-torch7: please add arm64
Source: lua-torch-torch7 Version: 0~20170720-gaed3171-2 User: debian-...@lists.debian.org Usertags: arm64 This package may work on arm64 now that luajit is available on that architecture.
Bug#873566: Please update ntfs-3g to 2016.2.22AR.3
at bottom :- On 29/08/2017, Jean-Pierre André wrote: > > The full changelog is available on : > http://jp-andre.pagesperso-orange.fr/changelog.html > Dear Jean, First of all thank you for maintaining and taking time to reply to the bug-report. Aha, The changelog at your end http://jp-andre.pagesperso-orange.fr/changelog.html says Version 2016.2.22AR.3 (Feb 1, 2017) but Debian only has 1:2016.2.22AR.2-2 in buster, sid/unstable and experimental. The new point version has not been released yet for Debian. [$] apt-cache policy ntfs-3g ntfs-3g: Installed: 1:2016.2.22AR.2-2 Candidate: 1:2016.2.22AR.2-2 Version table: *** 1:2016.2.22AR.2-2 600 600 http://httpredir.debian.org/debian buster/main amd64 Packages 1 http://httpredir.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status Here is my sources.list and I just updated the index [$] cat /etc/apt/sources.list 1 Debian buster # 2 deb http://httpredir.debian.org/debian/ buster main contrib non-free 3 deb-src http://httpredir.debian.org/debian buster main contrib non-free 4 5 Debian unstable # 6 deb http://httpredir.debian.org/debian unstable main contrib non-free 7 deb-src http://httpredir.debian.org/debian unstable main contrib 8 9 Debian experimental # 10 deb http://httpredir.debian.org/debian experimental main contrib 11 deb-src http://httpredir.debian.org/debian experimental main contrib 12 13 # Debian Debug packages ### 14 deb http://debug.mirrors.debian.org/debian-debug/ buster-debug main 15 deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main 16 deb http://debug.mirrors.debian.org/debian-debug/ experimental-debug main 17 18 Third party repos ### 19 # deb https://riot.im/packages/debian/ buster main 20 21 ## Non-free 22 #deb http://www.deb-multimedia.org buster main non-free notice the lists directory time-stamp - [$] ll -h /var/lib/apt/ total 676K -rw-r--r-- 1 root root 176K 2017-08-29 15:10 extended_states -rw-r--r-- 1 root root 168K 2017-08-29 14:52 listchanges.db -rw-r--r-- 1 root root 168K 2017-08-29 14:49 listchanges-old.db -rw-r--r-- 1 root root0 2017-08-29 12:38 daily_lock drwxr-xr-x 3 root root 36K 2017-08-29 12:17 lists -rw-r--r-- 1 root root 112K 2015-12-27 15:44 extended_states.CoE7yB drwxr-xr-x 2 root root 4.0K 2013-11-21 17:37 periodic -rw-r--r-- 1 root root 245 2013-07-25 22:06 cdroms.list drwxr-xr-x 3 root root 4.0K 2013-07-25 22:03 mirrors Just to make sure I also looked the Debian tracker page https://tracker.debian.org/pkg/ntfs-3g which also doesn't mention the new point version as well 2016.2.22AR.3 Maybe when you release the point release to Debian then we will get the updated version. I did look at the build-depends maybe you are waiting for a library transition or something but didn't see any conflicts or anything on the tracker page [$] apt-rdepends --build-depends --follow=DEPENDS ntfs-3g Reading package lists... Done Building dependency tree Reading state information... Done ntfs-3g Build-Depends: chrpath Build-Depends: debhelper (>= 9) Build-Depends: dh-autoreconf Build-Depends: libfuse-dev (>= 2.9.3-16) Build-Depends: libgcrypt20-dev Build-Depends: libgnutls28-dev Build-Depends: libgpg-error-dev Build-Depends: pkg-config Maybe you are trying to rebuild with all new versions of the build-depends and in a problem somewhere. My understanding of debian packaging is pretty limited. I however did try the following links to see if I could get some clue https://tracker.debian.org/pkg/ntfs-3g/ nor anything on https://release.debian.org/transitions/ . Please share when you will be uploading to unstable so it can be tested and tell me if there is something, some command or something that needs testing before it lands in testing/buster. Looking forward to seeing ntfs-3g 2016.2.22AR.3 in Debian soonish. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#866364: Partial implementation of live boot localisation
Hello, On Thu, 29 Jun 2017, Narcis Garcia wrote: > No keyboard localisation when choosing "Debian Live with Localisation > Support". For example, choosing "Spanish" at this boot submenu, keyboard > is set to an USA layout (in any X, TTY and pty). > > Keyboard layout should do same associations as Debian-Installer suggests > for choosen language. What are you referring to? live-config is a generic tool that integrates in the boot sequence, the boot menu is not under its control and it's definitely not responsible of the "Debian Live with Localisation Support" thingie that you are speaking of. I'm tempted to close this bug right away but maybe it must be reassigned somewhere so please let us know what live image you did use for your test. Where did you get it from? If its a custom image, what tool did you use to build it? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#869614: fontforge: CVE-2017-11568 CVE-2017-11569 CVE-2017-11570 CVE-2017-11571 CVE-2017-11572 CVE-2017-11573 CVE-2017-11574 CVE-2017-11575 CVE-2017-11576 CVE-2017-11577
Control: clone -1 -2 -3 Control: retitle -1 fontforge: CVE-2017-11568 CVE-2017-11569 CVE-2017-11571 CVE-2017-11572 CVE-2017-11574 CVE-2017-11575 CVE-2017-11576 CVE-2017-11577 Control: retitle -2 fontforge: CVE-2017-11570 Control: retitle -3 fontforge: CVE-2017-11573 Control: fixed -1 20120731.b-5+deb8u1 Control: fixed -1 1:20161005~dfsg-4+deb9u1 Control: forwarded -2 https://github.com/fontforge/fontforge/issues/3097 Control: forwarded -3 https://github.com/fontforge/fontforge/issues/3098 Hi since the set of issues fixed together diverge a bit, let's split this bug up into the set of already fixed ones and then the two open CVEs yet. Btw, any plan to do as well an unstable upload? Regards, Salvatore
Bug#873589: clearsilver: FTBFS on arm64, mips*, ppc64el during clean - unable to guess system type
Source: clearsilver Version: 0.10.5-2 Severity: serious Tags: sid buster Hi, clearsilver FTBFS on arm64, mips* and ppc64el with this error: > checking build system type... ./config.guess: unable to guess system type > > This script, last modified 2001-09-04, has failed to recognize > the operating system you are using. It is advised that you > download the most up to date version of the config scripts from > > ftp://ftp.gnu.org/pub/gnu/config/ > > If the version you run (./config.guess) is already up to date, please > send the following data and any information you think might be > pertinent to in order to provide the needed > information to handle your system. > > config.guess timestamp = 2001-09-04 This happens during the "clean" phase of the build: > fakeroot debian/rules clean > dh clean --with python2 >dh_auto_clean > make -j6 distclean > make[1]: Entering directory '/<>' > Makefile:10: rules.mk: No such file or directory > ./configure > checking for gcc... gcc Calling "make distclean" should probably be skipped if rules.mk does not exist so that the configure script isn't run. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library
On Mon, Aug 28, 2017 at 12:49:22PM +0200, Giulio Paci wrote: > Hi Adam, > I just saw that building on freebsd-i386 failed due to memory exhaustion > during compilation of tests. The only workaround that I can see is to > prevent tests to be compiled if the memory is not enough to compile them. > Do you see any better alternative? Do you think it's a matter of just available memory, or of address space? It did build on all other architectures, including 32-bit ones, so the former is more likely, but you know the package better. kfreebsd-i386 is not a release architecture, though, so it's not vital to fix it immediately. You really don't want reverse-dependencies to get misbuilt, but I've just checked -- opengrm-ngram FTBFSes on kfreebsd-i386 with the old openfst so this should be safe. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄
Bug#873590: Update to Scilab 6
Package: scilab Please update to Scilab 6. http://www.scilab.org/en/community/news/scilab6
Bug#872559: RFS: opengrm-ngram/1.3.2-1 -- opengrm n-gram library
On Fri, Aug 18, 2017 at 03:48:26PM +0200, Giulio Paci wrote: > * Package name: opengrm-ngram >Version : 1.3.2-1 > It closes BUG: > #871061 > > It builds those binary packages: > > libngram-dev - opengrm n-gram library (development) > libngram-tools - opengrm n-gram library (tools) > libngram2 - opengrm n-gram library (runtime) Looks good. It does FTBFS on kfreebsd-i386 against the outdated openfst, which is good (no misbuilt packages). I wonder, though, perhaps an explicit "Build-Depends: libfst-dev >= 1.6.3-1" wouldn't be better to avoid it being tried over and over? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄
Bug#837809: [drm:si_dpm_set_power_state [radeon]] *ERROR* si_restrict_performance_levels_before_s
The message still occurs with Stretch kernel 4.9.0-3-amd64. [ +0.000192] fbcon: radeondrmfb (fb0) is primary device [ +0.179799] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_restrict_performance_levels_before_s [ +0.122488] Console: switching to colour frame buffer device 480x135 [ +0.087282] radeon :01:00.0: fb0: radeondrmfb frame buffer device [ +0.094945] [drm] Initialized radeon 2.48.0 20080528 for :01:00.0 on minor 0 The message is created in drivers/gpu/drm/radeon/si_dpm.c if si_restrict_performance_levels_before_switch fails. My graphics adapter is 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 250X] (prog-if 00 [VGA controller]) xset dpms force standby works fine on my system. Regards Heinrich Schuchardt
Bug#873591: emacs doesn't un-maximize properly with openbox 3.6.1-5
Package: emacs25 Version: 25.2+1-5 I have an installation of Debian testing that uses openbox as its window manager. Recently openbox was upgraded from version 3.6.1-4.1 to 3.6.1-5 which apparently broke emacs: if I open an emacs window and maximize it, then un-maximizing the window doesn't restore it to its previous size, but instead behaves as if I had manually resized it to fill the entire screen. I'm filing this bug for emacs because I have failed to find any other program that exhibits the same problem.
Bug#873580: mate-settings-daemon: Failed to acquire org.mate.SettingsDaemon
Control: close -1 Hi all, Στις 29/08/2017 11:21 πμ, ο gnugr έγραψε: > Package: mate-settings-daemon > Version: 1.18.1-2 > Severity: normal > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* My problem is that the language icon is missing. >* With the command "mate-settings-daemon --replace" the icon appears. >* You can check and review it: http://imgur.com/a/7ox2V >* The outcome through cmdline is: Failed to acquire > org.mate.SettingsDaemon, > and the output of "--replace" > is:[1503983734,000,xklavier.c:xkl_engine_start_listen/] The backend does not > require manual layout management - but it is provided by the application, and > (mate-settings-daemon:5903): Gdk-CRITICAL **: > gdk_window_thaw_toplevel_updates: > assertion 'window->update_and_descendants_freeze_count > 0' failed. > > *** End of the template - remove these template lines *** I just discovered that by adding another (3rd) option of Greek language for instance 'Greek Polytonic', the language layout icon appeared back. That might causes the problem the too many options Greek language has. Vangelis Mouhtsis signature.asc Description: OpenPGP digital signature
Bug#872994: fuse-emulator-gtk: screen with wrong size at startup.
On Fri, Aug 25, 2017 at 09:21:29PM +, Reds Reds wrote: > No, right now I don't see any error. > > It had to do with wayland option. > > I have other emulators, and Vice for commodore 64 didn't run at all > when I executed it. > > With wayland disabled, everything is normal again. Ok... that might be a problem in Gtk perhaps? Did you notice anything strange with other apps, or is it only with Fuse and Vice? Berto
Bug#873574: openssh-ssh1: Please migrate to openssl1.1 in Buster
On Tue, Aug 29, 2017 at 08:02:23AM +0200, Sebastian Andrzej Siewior wrote: > Please migrate to libssl-dev in the Buster cycle. It's unclear whether this will be possible, for the same reasons as in #828475. If upstream do it then I expect I'll backport the patch to openssh-ssh1, but there's been quite a bit of pushback upstream and IMO it's far too big a patch to carry as a distribution patch to something as security-critical as openssh. -- Colin Watson [cjwat...@debian.org]
Bug#873592: libawl-php: PHP 7 deprecated constructor syntax
Package: libawl-php Version: 0.57-1 Severity: minor Dear Maintainer, libawl-php in version 0.57-1 still uses the deprecated constructor syntax. Since PHP 7.0 is the default for Debian Stretch we would appreciate if you could include the patch to fix that in a timely release, since we have to turn off error_reporting otherwise. The patch in question is available upstream: https://gitlab.com/davical-project/awl/commit/ea2dbe88124a2943b709d12334c0f7db74580792 Thank you for your time. Best regards, Kim-Alexander Brodowski -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) libawl-php depends on no packages. Versions of packages libawl-php recommends: ii php7.0 [php] 7.0.19-1 libawl-php suggests no packages. -- no debconf information
Bug#873593: ITP: phpliteadmin -- web-based SQLite database admin tool
Package: wnpp Severity: wishlist Owner: Nicholas Guriev * Package name: phpliteadmin Version : 1.9.7.1 Upstream Author : phpLiteAdmin project * URL : https://www.phpliteadmin.org/ * License : GPL-3.0+ Programming Lang: PHP Description : web-based admin tool for SQLite databases Hello, everyone! I'd like to package phpLiteAdmin in Debian to simplify its use. I've started to work on packaging. I hope it will be useful as a Debian package.
Bug#873594: ITP: flatpak-builder -- Flatpak application building helper
Package: wnpp Severity: wishlist Owner: Simon McVittie * Package name: flatpak-builder Version : 0.9.8+$n_commits (until a release is made) Upstream Author : Alexander Larsson and others * URL : https://github.com/flatpak/flatpak-builder * License : LGPL Programming Lang: C Description : Flatpak application building helper Flatpak installs, manages and runs sandboxed desktop application bundles. See the flatpak package for a more comprehensive description. . flatpak-builder is a tool that makes it easy to build applications and their dependencies by automating the configure && make && make install steps. flatpak 0.9.8 includes flatpak-builder in the same source package (although we package it as a separate binary package in Debian). It has been separated out upstream since 0.9.8, and will have a parallel release schedule in future.
Bug#872315: Pending fixes for bugs in the rename package
tag 872315 + pending thanks Some bugs in the rename package are closed in revision 66cdaa5c79c9de2668abea6d74beeb2a608aecae in branch 'master' by Dominic Hargreaves The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/rename.git/commit/?id=66cdaa5 Commit message: Add Multi-Arch: foreign (Closes: #872315)
Bug#873595: RFP: libschedule-drmaac-perl -- Perl wrapper of the C binding of the DRMAA specification
Package: wnpp Severity: wishlist * Package name: libschedule-drmaac-perl Version : 0.81 Upstream Author : Tim Harsch * URL : https://metacpan.org/pod/distribution/Schedule-DRMAAc/Schedule_DRMAAc_ext.pm * License : BSD Programming Lang: Perl Description : Perl wrapper of the C binding of the DRMAA specification
Bug#873590: Update to Scilab 6
Le 29/08/2017 à 12:37, Amr Ibrahim a écrit : > Package: scilab > > Please update to Scilab 6. > http://www.scilab.org/en/community/news/scilab6 > I would rather wait until 6.0.1, which should come ... At some point... However, the work on Scilab 6 could be started in experimental. Sylvestre
Bug#873596: avahi FTCBFS: uninstallable python Build-Depends, fails to figure out what distribution Debian is
Source: avahi Version: 0.6.32-2 Tags: patch User: helm...@debian.org Usertags: rebootstrap avahi fails to cross build from source. Since xmltoman became M-A:foreign. avahi's Build-Depends are almost installable. Its python dependencies still fail with postinst errors. For cross building, one typically wants libpython from the host architecture and the rest from the build architecture. After annotating all of those dependencies, ./configure fails figuring out the target distribution. After telling it that we build for Debian, it cross builds successfully. Please consider applying the attached patch. Helmut diff --minimal -Nru avahi-0.6.32/debian/changelog avahi-0.6.32/debian/changelog --- avahi-0.6.32/debian/changelog 2017-01-23 09:41:58.0 +0100 +++ avahi-0.6.32/debian/changelog 2017-08-29 13:24:47.0 +0200 @@ -1,3 +1,14 @@ +avahi (0.6.32-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Make python build-depends work with cross compilation. Executable + and modules are annotated with :native. Only libpython comes from the + host architecture. ++ Tell ./configure that we are Debian. + + -- Helmut Grohne Tue, 29 Aug 2017 13:24:47 +0200 + avahi (0.6.32-2) unstable; urgency=medium [ Christian Hofstaedtler ] diff --minimal -Nru avahi-0.6.32/debian/control avahi-0.6.32/debian/control --- avahi-0.6.32/debian/control 2017-01-23 09:41:58.0 +0100 +++ avahi-0.6.32/debian/control 2017-08-29 13:24:45.0 +0200 @@ -21,10 +21,11 @@ libexpat-dev, libdaemon-dev (>= 0.11), libdbus-1-dev (>= 0.60), - python-all-dev (>= 2.6.6-3~), - python-gdbm (>= 2.4.3), - python-dbus , - python-gtk2 (>= 2.8.6-2) , + python-all-dev:any (>= 2.6.6-3~), + libpython-all-dev (>= 2.6.6-3~), + python-gdbm:native (>= 2.4.3), + python-dbus:native , + python-gtk2:native (>= 2.8.6-2) , libqt4-dev , xmltoman, intltool (>= 0.35.0) diff --minimal -Nru avahi-0.6.32/debian/rules avahi-0.6.32/debian/rules --- avahi-0.6.32/debian/rules 2017-01-23 09:41:58.0 +0100 +++ avahi-0.6.32/debian/rules 2017-08-29 13:24:47.0 +0200 @@ -3,7 +3,7 @@ %: dh $@ --with autotools-dev,python2,systemd,autoreconf -DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) +include /usr/share/dpkg/architecture.mk ifneq (linux,$(DEB_HOST_ARCH_OS)) CONFFLAGS += \ @@ -26,6 +26,10 @@ --enable-gtk3 endif +ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)) +CONFFLAGS += --with-distro=debian +endif + override_dh_auto_configure: dh_auto_configure -- $(CONFFLAGS) \ --enable-compat-libdns_sd \
Bug#871289: libprelude: diff for NMU version 3.1.0-0.5
Control: tags 871289 + patch Control: tags 871289 + pending Dear maintainer, I've prepared an NMU for libprelude (versioned as 3.1.0-0.5) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. -- 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 `- diffstat for libprelude-3.1.0 libprelude-3.1.0 changelog |9 + control |1 + rules |5 + 3 files changed, 15 insertions(+) diff -Nru libprelude-3.1.0/debian/changelog libprelude-3.1.0/debian/changelog --- libprelude-3.1.0/debian/changelog 2017-07-17 12:07:24.0 +0200 +++ libprelude-3.1.0/debian/changelog 2017-08-28 00:30:12.0 +0200 @@ -1,3 +1,12 @@ +libprelude (3.1.0-0.5) unstable; urgency=medium + + * Non-maintainer upload. + * Rebuild with GCC 7. (Closes: #871289) +- Build-depend on gcc >= 7. +- Update shlibs to ensure rdeps pull in the new version. + + -- Thomas Andrejak Mon, 28 Aug 2017 00:30:12 +0200 + libprelude (3.1.0-0.4) unstable; urgency=medium * Upload to unstable. diff -Nru libprelude-3.1.0/debian/control libprelude-3.1.0/debian/control --- libprelude-3.1.0/debian/control 2017-06-27 21:18:39.0 +0200 +++ libprelude-3.1.0/debian/control 2017-08-28 00:30:12.0 +0200 @@ -4,6 +4,7 @@ Maintainer: Pierre Chifflier Build-Depends: debhelper (>= 10), dh-python , +g++ (>= 4:7), gawk, gem2deb , libgcrypt20-dev, diff -Nru libprelude-3.1.0/debian/rules libprelude-3.1.0/debian/rules --- libprelude-3.1.0/debian/rules 2017-06-27 21:56:05.0 +0200 +++ libprelude-3.1.0/debian/rules 2017-08-28 00:30:12.0 +0200 @@ -52,5 +52,10 @@ override_dh_python3: dh_python3 -ppython3-prelude +override_dh_makeshlibs: + # For new symbols when compiled with GCC 7 + dh_makeshlibs -plibpreludecpp8 -V'libpreludecpp8 (>= 3.1.0-0.5~)' + dh_makeshlibs --remaining-packages + %: dh $@ $(DH_ADDONS) signature.asc Description: PGP signature
Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free
Wait... Is that actually even legal under RFC 1964? Doesn't this lead to leaks for correctly written applications? --Sam
Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free
Ah, looked at the commit. Yeah. This makes sense. This is somewhat of a behavior change. Do we want to just bring this into unstable, or do we want to backport it to stable releases? It seems like there is a possibility of problems in either direction.
Bug#865523: Build C library from src:brotli sources
Hi, unless there's an expectation that the SOVERSIONs will be different for each package, I would just keep them together in the libbrotli package. We can always split them later if such change happens as it would require library transition anyway. Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, fast DNS(SEC) resolver On Sat, Jun 24, 2017, at 15:52, Tomasz Buchert wrote: > On 22/06/17 13:57, Ondřej Surý wrote: > > [...] > > I did some work on the version in git now builds the shared libraries. > I've packaged all shared libs inside libbrotli, but probably should > split it more into 3 more libs (common, enc and dec). I'm however > surprised at the architecture: it would be much easier to just have a > one shared library for brotli in general. > > Let me know what you think. > > Tomasz > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature)
Bug#873597: virt-manager: gir1.2-spice-client-gtk-3.0 package has been renamed to gir1.2-spiceclientgtk-3.0
Package: virt-manager Version: 1:1.4.0-6 Severity: important Hi, The gir1.2-spice-client-gtk-3.0 package has been renamed to gir1.2-spiceclientgtk-3.0. The dependency must be adjusted. Regards, Laurent Bigonville -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-rc5-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages virt-manager depends on: ii dconf-gsettings-backend [gsettings-backend] 0.26.0-2+b1 ii gir1.2-gtk-3.0 3.22.19-1 ii gir1.2-gtk-vnc-2.0 0.7.1-1 ii gir1.2-libosinfo-1.0 1.1.0-1 ii gir1.2-libvirt-glib-1.0 1.0.0-1 ii gir1.2-vte-2.91 0.46.2-1 ii librsvg2-common 2.40.18-1 ii python 2.7.13-2 ii python-dbus 1.2.4-1+b2 ii python-gi3.22.0-2+b1 ii python-gi-cairo 3.22.0-2+b1 ii python-libvirt 3.5.0-1 ii python-requests 2.18.1-1 ii python2.72.7.13-4 ii virtinst 1:1.4.0-6 Versions of packages virt-manager recommends: pn gir1.2-spice-client-gtk-3.0 pn gnome-icon-theme ii libvirt-daemon-system3.6.0-1 Versions of packages virt-manager suggests: ii gir1.2-secret-1 0.18.5-3.1 ii gnome-keyring3.20.1-1 ii python-guestfs 1:1.34.6-5 pn ssh-askpass ii virt-viewer 6.0-1 -- no debconf information
Bug#873599: lxqt-panel FTBFS: error: ‘_explicit’ does not name a type; did you mean ‘explicit’?
Source: lxqt-panel
Version: 0.11.1-3
Severity: serious
Some recent change in unstable makes lxqt-panel FTBFS:
https://tests.reproducible-builds.org/debian/history/lxqt-panel.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/lxqt-panel.html
...
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/kbdlayout.cpp:36:18:
error: ‘_explicit’ does not name a type; did you mean ‘explicit’?
#define explicit _explicit
^
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/kbdlayout.cpp:36:18:
error: ‘_explicit’ does not name a type; did you mean ‘explicit’?
#define explicit _explicit
^
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/kbdlayout.cpp:36:18:
error: ‘_explicit’ does not name a type; did you mean ‘explicit’?
#define explicit _explicit
^
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/kbdlayout.cpp:36:18:
error: ‘_explicit’ does not name a type; did you mean ‘explicit’?
#define explicit _explicit
^
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/kbdlayout.cpp:36:18:
error: ‘_explicit’ does not name a type; did you mean ‘explicit’?
#define explicit _explicit
^
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/kbdlayout.cpp:36:18:
error: ‘_explicit’ does not name a type; did you mean ‘explicit’?
#define explicit _explicit
^
In file included from /usr/include/x86_64-linux-gnu/qt5/QtGui/qevent.h:56:0,
from /usr/include/x86_64-linux-gnu/qt5/QtGui/QList:1,
from
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/../kbdinfo.h:31,
from
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/kbdlayout.cpp:38:
/usr/include/x86_64-linux-gnu/qt5/QtGui/qvector2d.h:138:25: error: prototype
for ‘constexpr QVector2D::QVector2D(const QPoint&)’ does not match any in class
‘QVector2D’
Q_DECL_CONSTEXPR inline QVector2D::QVector2D(const QPoint& point) :
xp(point.x()), yp(point.y()) {}
^
/usr/include/x86_64-linux-gnu/qt5/QtGui/qvector2d.h:56:20: error: candidates
are: constexpr QVector2D::QVector2D(QVector2D&&)
class Q_GUI_EXPORT QVector2D
^
/usr/include/x86_64-linux-gnu/qt5/QtGui/qvector2d.h:56:20: error:
constexpr QVector2D::QVector2D(const QVector2D&)
/usr/include/x86_64-linux-gnu/qt5/QtGui/qvector2d.h:136:25: error:
constexpr QVector2D::QVector2D(float, float)
Q_DECL_CONSTEXPR inline QVector2D::QVector2D(float xpos, float ypos) :
xp(xpos), yp(ypos) {}
^
/usr/include/x86_64-linux-gnu/qt5/QtGui/qvector2d.h:134:25: error:
constexpr QVector2D::QVector2D()
Q_DECL_CONSTEXPR inline QVector2D::QVector2D() : xp(0.0f), yp(0.0f) {}
^
/usr/include/x86_64-linux-gnu/qt5/QtGui/qvector2d.h:140:25: error: prototype
for ‘constexpr QVector2D::QVector2D(const QPointF&)’ does not match any in
class ‘QVector2D’
Q_DECL_CONSTEXPR inline QVector2D::QVector2D(const QPointF& point) :
xp(point.x()), yp(point.y()) {}
^
/usr/include/x86_64-linux-gnu/qt5/QtGui/qvector2d.h:56:20: error: candidates
are: constexpr QVector2D::QVector2D(QVector2D&&)
class Q_GUI_EXPORT QVector2D
^
/usr/include/x86_64-linux-gnu/qt5/QtGui/qvector2d.h:56:20: error:
constexpr QVector2D::QVector2D(const QVector2D&)
/usr/include/x86_64-linux-gnu/qt5/QtGui/qvector2d.h:136:25: error:
constexpr QVector2D::QVector2D(float, float)
Q_DECL_CONSTEXPR inline QVector2D::QVector2D(float xpos, float ypos) :
xp(xpos), yp(ypos) {}
^
/usr/include/x86_64-linux-gnu/qt5/QtGui/qvector2d.h:134:25: error:
constexpr QVector2D::QVector2D()
Q_DECL_CONSTEXPR inline QVector2D::QVector2D() : xp(0.0f), yp(0.0f) {}
^
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/kbdlayout.cpp:36:18:
error: ‘_explicit’ does not name a type; did you mean ‘explicit’?
#define explicit _explicit
^
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/kbdlayout.cpp:36:18:
error: ‘_explicit’ does not name a type; did you mean ‘explicit’?
#define explicit _explicit
^
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/kbdlayout.cpp:36:18:
error: ‘_explicit’ does not name a type; did you mean ‘explicit’?
#define explicit _explicit
^
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/kbdlayout.cpp:36:18:
error: ‘_explicit’ does not name a type; did you mean ‘explicit’?
#define explicit _explicit
^
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11/kbdlayout.cpp:36:18:
error: ‘_explicit’ does not name a type; did you mean ‘explicit’?
#define explicit _explicit
^
/build/1st/lxqt-panel-0.11.1/plugin-kbindicator/src/x11
Bug#873598: spice-gtk: gir package missing dependencies
Source: spice-gtk Version: 0.34-1 Severity: serious Tags: patch Hi, gir1.2-spiceclientgtk-3.0 and gir1.2-spiceclientglib-2.0 have not any dependencies defined. It seems that the build is not calling dh_girepository See the attached patch. Cheers, Laurent Bigonville -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-rc5-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) diff -Nru spice-gtk-0.34/debian/changelog spice-gtk-0.34/debian/changelog --- spice-gtk-0.34/debian/changelog 2017-08-06 11:02:13.0 +0200 +++ spice-gtk-0.34/debian/changelog 2017-08-29 14:22:47.0 +0200 @@ -1,3 +1,10 @@ +spice-gtk (0.34-2) UNRELEASED; urgency=medium + + * debian/rules: Call the gir sequence so the gir1.2-* packages have the +correct dependencies defined. + + -- Laurent Bigonville Tue, 29 Aug 2017 14:22:47 +0200 + spice-gtk (0.34-1) unstable; urgency=medium * New upstream release @@ -7,7 +14,7 @@ - Rename gir1.2* to fix lintian warning - Install gir*.typelib to multiarch directory - Remove build-depends on gstreamer1.0-plugins-*(Closes: #863978) -- Chnage Depends on gstreamer1.0-plugins-* to Suggests(Closes: #849047) +- Change Depends on gstreamer1.0-plugins-* to Suggests(Closes: #849047) * debian/patches: - debian/patches/ssl-Rework-our-custom-BIO-type.patch, removed, applied upstream diff -Nru spice-gtk-0.34/debian/rules spice-gtk-0.34/debian/rules --- spice-gtk-0.34/debian/rules 2017-08-06 11:02:13.0 +0200 +++ spice-gtk-0.34/debian/rules 2017-08-29 14:17:01.0 +0200 @@ -1,7 +1,7 @@ #!/usr/bin/make -f %: - dh $@ --parallel --with autoreconf + dh $@ --parallel --with autoreconf,gir override_dh_auto_configure: dh_auto_configure -- \
Bug#873600: sudo: hangs forever
Package: sudo Version: 1.8.21-1 Sometimes sudo hangs forever: $ time timeout 42s sudo echo foo foo real0m0.035s user0m0.007s sys 0m0.006s $ time timeout 42s sudo echo foo foo real0m42.003s user0m0.005s sys 0m0.008s -- System Information: Architecture: i386 Versions of packages sudo depends on: ii libaudit1 1:2.7.7-1+b2 ii libc6 2.24-17 ii libpam0g1.1.8-3.6 ii libselinux1 2.6-3+b2 ii libpam-modules 1.1.8-3.6 ii lsb-base9.20170808 -- Jakub Wilk
Bug#864831: NTL update to 10.3.0
Hi, thanks for uploading sage 8.0 and sorry that I was not there to help. Now is a good time for the NTL transition. Julien, could you update the package to 10.3.0? Then we can test-build the reverse dependencies and ask for a transition. Best, Tobias
Bug#873601: jkmeter FTCBFS: binutils build dependency unsatisfiable, hard codes build architecture compiler
Source: jkmeter Version: 0.6.1-4 Tags: patch User: helm...@debian.org Usertags: rebootstrap jkmeter fails to cross build from source for two reasons: * Its explicit build dependency on binutils (host architecture) conflicts with its implicit dependency via build-essential (build architecture). In theory, one would do "toolchain dependency cross translation here", but dropping the redundant dependency is easier. * The upstream Makefile hard codes the build architecture compiler g++. After fixing both issues, jkmeter cross builds successfully. Please consider applying the attached patch. Helmut diff --minimal -Nru jkmeter-0.6.1/debian/changelog jkmeter-0.6.1/debian/changelog --- jkmeter-0.6.1/debian/changelog 2016-12-22 20:58:40.0 +0100 +++ jkmeter-0.6.1/debian/changelog 2017-08-29 14:36:28.0 +0200 @@ -1,3 +1,12 @@ +jkmeter (0.6.1-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Drop implicitly satisfied build dependency on binutils. ++ Make g++ substitutable in source/Makefile. + + -- Helmut Grohne Tue, 29 Aug 2017 14:36:28 +0200 + jkmeter (0.6.1-4) unstable; urgency=medium [ Alessio Treglia ] diff --minimal -Nru jkmeter-0.6.1/debian/control jkmeter-0.6.1/debian/control --- jkmeter-0.6.1/debian/control2016-12-22 20:58:04.0 +0100 +++ jkmeter-0.6.1/debian/control2017-08-29 14:36:27.0 +0200 @@ -6,7 +6,6 @@ Free Ekanayaka , JaromÃr MikeÅ¡ Build-Depends: - binutils, debhelper (>= 10), libclthreads-dev (>= 2.4.0), libclxclient-dev (>= 3.9.0), diff --minimal -Nru jkmeter-0.6.1/debian/patches/01-makefile.patch jkmeter-0.6.1/debian/patches/01-makefile.patch --- jkmeter-0.6.1/debian/patches/01-makefile.patch 2013-04-03 04:50:57.0 +0200 +++ jkmeter-0.6.1/debian/patches/01-makefile.patch 2017-08-29 14:36:28.0 +0200 @@ -1,13 +1,14 @@ Description: Put DESTDIR before PREFIX to set the installation path properly. Set prefix properly and removed -march=native cpp flag + Make g++ substitutable Author: JaromÃr MikeÅ¡ Author: Alessio Treglia Forwarded: Fons Adriaensen Index: jkmeter/source/Makefile === --- jkmeter.orig/source/Makefile 2011-08-03 02:45:40.420992633 +0200 +++ jkmeter/source/Makefile2011-08-03 02:46:35.887176814 +0200 @@ -19,14 +19,14 @@ # - @@ -26,3 +27,12 @@ all: jkmeter +@@ -40,7 +40,7 @@ + jkmeter: LDFLAGS += -L/usr/X11R6/lib + jkmeter: LDFLAGS += -pthread + jkmeter: $(JKMETER_O) +- g++ $(LDFLAGS) -o $@ $(JKMETER_O) $(LDLIBS) ++ $(CXX) $(LDFLAGS) -o $@ $(JKMETER_O) $(LDLIBS) + + $(JKMETER_O): + -include $(JKMETER_O:%.o=%.d)
Bug#873598: spice-gtk: gir package missing dependencies
Package: src:spice-gtk
Followup-For: Bug #873598
Hi,
While we are at it, the gir package can be marked as multi-arch same
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.13.0-rc5-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru spice-gtk-0.34/debian/changelog spice-gtk-0.34/debian/changelog
--- spice-gtk-0.34/debian/changelog 2017-08-06 11:02:13.0 +0200
+++ spice-gtk-0.34/debian/changelog 2017-08-29 14:30:00.0 +0200
@@ -1,3 +1,11 @@
+spice-gtk (0.34-2) UNRELEASED; urgency=medium
+
+ * debian/rules: Call the gir sequence so the gir1.2-* packages have the
+correct dependencies defined.
+ * Make the gir1.2-* packages Multi-Arch: same
+
+ -- Laurent Bigonville Tue, 29 Aug 2017 14:30:00 +0200
+
spice-gtk (0.34-1) unstable; urgency=medium
* New upstream release
@@ -7,7 +15,7 @@
- Rename gir1.2* to fix lintian warning
- Install gir*.typelib to multiarch directory
- Remove build-depends on gstreamer1.0-plugins-*(Closes: #863978)
-- Chnage Depends on gstreamer1.0-plugins-* to Suggests(Closes: #849047)
+- Change Depends on gstreamer1.0-plugins-* to Suggests(Closes: #849047)
* debian/patches:
- debian/patches/ssl-Rework-our-custom-BIO-type.patch, removed, applied
upstream
diff -Nru spice-gtk-0.34/debian/control spice-gtk-0.34/debian/control
--- spice-gtk-0.34/debian/control 2017-08-06 11:02:13.0 +0200
+++ spice-gtk-0.34/debian/control 2017-08-29 14:29:52.0 +0200
@@ -88,6 +88,7 @@
Package: gir1.2-spiceclientglib-2.0
Section: introspection
Architecture: any
+Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends}, ${gir:Depends}
Description: GObject for communicating with Spice servers
(GObject-Introspection)
@@ -126,6 +127,7 @@
Package: gir1.2-spiceclientgtk-3.0
Section: introspection
Architecture: any
+Multi-Arch: same
Depends: ${misc:Depends}, ${gir:Depends}
Description: GTK3 widget for SPICE clients (GObject-Introspection)
libspice-gtk3 provides gtk3 widget to show spice display
diff -Nru spice-gtk-0.34/debian/rules spice-gtk-0.34/debian/rules
--- spice-gtk-0.34/debian/rules 2017-08-06 11:02:13.0 +0200
+++ spice-gtk-0.34/debian/rules 2017-08-29 14:17:01.0 +0200
@@ -1,7 +1,7 @@
#!/usr/bin/make -f
%:
- dh $@ --parallel --with autoreconf
+ dh $@ --parallel --with autoreconf,gir
override_dh_auto_configure:
dh_auto_configure -- \
Bug#873602: pd-xsample FTBFS on ppc64el: UInt32 does not name a type
Package: pd-xsample Version: 0.3.2~git20161105.1.d16761a1-1 Severity: serious https://buildd.debian.org/status/fetch.php?pkg=pd-xsample&arch=ppc64el&ver=0.3.2%7Egit20161105.1.d16761a1-1&stamp=1486228622&raw=0 ... make[2]: Entering directory '/«PKGBUILDDIR»' info: using Makefile.pdlibbuilder version 0.4.4 info: using Pd API /usr/include/pd/m_pd.h info: making target all in lib xsample info: making source/main.o in lib xsample g++ -DPD -I "/usr/include/pd" -DUNIX -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fcheck-new -DPD -DFLEXT_SYS=2 -DFLEXT_SHARED -DFLEXT_USE_CMEM -I/usr/include/flext -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat -Werror=format-security -o source/main.o -c source/main.cpp In file included from source/main.cpp:13:0: source/main.h:82:9: error: 'UInt32' does not name a type inline UInt32 GetPrefetchConstant( int blockSizeInVectors,int blockCount,int blockStride ) ^~ /usr/share/pd-lib-builder//Makefile.pdlibbuilder:867: recipe for target 'source/main.o' failed make[2]: *** [source/main.o] Error 1 make[2]: Leaving directory '/«PKGBUILDDIR»' debian/rules:9: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory '/«PKGBUILDDIR»' debian/rules:6: recipe for target 'build-arch' failed make: *** [build-arch] Error 2 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 4.11.0-2-powerpc64le (SMP w/16 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), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#773346: reportbug should provide information about active LSM
Ping? Le 08/11/15 à 23:32, Laurent Bigonville a écrit : Le 08/11/15 23:13, Sandro Tosi a écrit : On Sun, Nov 8, 2015 at 9:27 PM, Laurent Bigonville wrote: On Fri, 2 Jan 2015 22:48:26 + Sandro Tosi wrote: Hi, Thanks for the reply! Any progress on this? well mmh, indeed """ I'm ok in running sestatus, but it seems this tool is only available if you are using SELinux and thus u have installed the relative binaries, is there a way to identify if SELinux is enabled without using that tool? """ and """ But this might be a bit too verbose, and I'm not sure whether the output is considered stable. I think that would be an important part to clarify, eventually if there is a parsable way to output this information; this will reduce the maintenance cost on reportbug side. """ An other tool which seem to have a stable output is /usr/sbin/getenforce, it outputs either Disabled, Permissive or Enforcing. But again this is a tool that is part of SELinux toolset (selinux-utils package). Like I said in my previous mail: Or we we could also, if don't want to rely on any external tools do the following I guess: - Check /proc/mount to see whether a "selinuxfs" filesystem is mounted that would indicate that selinux is at least enabled on the machine. (The mountpoint can, by default, either /sys/fs/selinux or /selinux) - Then a more granular status can be checked by looking in /enforce, /mls, /deny_unknown. The files contain 1/0 (true/false) to indicate whether SELinux is in enforcing mode, using MLS or denying unknown access vectors. This is basically what getenfoce utility (and libselinux) is doing internally: https://github.com/SELinuxProject/selinux/blob/master/libselinux/utils/getenforce.c https://github.com/SELinuxProject/selinux/blob/master/libselinux/src/enabled.c#L12 https://github.com/SELinuxProject/selinux/blob/master/libselinux/src/getenforce.c#L12 Cheers, Laurent Bigonville
Bug#812826: xim problem
Hi, On Mon, Aug 28, 2017 at 10:32:39AM -0700, Sean Whitton wrote: > Hello Osamu, > > On Sat, Aug 12 2017, Osamu Aoki wrote: > > > Since xim is rarely used protocol, please set to use ibus via im-config. > > I did some investigation. > > Did you know that your scripts launch ibus-daemon with the --xim option? Yes. But if ibus related libraries are available it uses such library to pass input instead of using xim. If ibus related libraries aren't available, ibus use xim to pass keyboard input. Osamu
Bug#873603: glx-diversions: Install and uninstall nvidia-driver fails with ERROR: The conflicting library '/usr/lib/i386-linux-gnu/libGL.so.1.2' is known to dpkg.
Package: glx-diversions Version: 0.5.1 Severity: important Dear Maintainer, I changed graphics card from AMD to Nvidia and errors with installation of nvidia-grive. Graphics card is 01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [GeForce GT 240] (rev a2). Error Messages: Errors were encountered while processing: * libgl1-nvidia-glx:amd64 * xserver-xorg-video-nvidia * nvidia-driver Setting up libgl1-nvidia-glx:amd64 (340.102-1) ... ERROR: The conflicting library '/usr/lib/i386-linux-gnu/libGL.so.1.2' is known to dpkg. diversion by glx-diversions from: /usr/lib/i386-linux-gnu/libGL.so.1.2 diversion by glx-diversions to: /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 dpkg: error processing package libgl1-nvidia-glx:amd64 (--configure): The problem was fixed by after running the following commands removing ‘/usr/lib/i386-linux-gnu/libGL.so.1.2’ ls -al /usr/lib/i386-linux-gnu/libGL.so.1.2 lrwxrwxrwx 1 root root 48 Mar 21 2016 /usr/lib/i386-linux-gnu/libGL.so.1.2 -> /usr/lib/i386-linux-gnu/fglrx/fglrx-libGL.so.1.2 root@server:~# rm -v /usr/lib/i386-linux-gnu/libGL.so.1.2 removed ‘/usr/lib/i386-linux-gnu/libGL.so.1.2’ sudo apt-get update I may have had old nvidia drivers or the nouveau installed at one time that caused this problem, however I cannot remember with any certainty. -- Package-specific info: Diversions: diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by glx-diversions diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/libGLESv2.so.
Bug#870304: yabause: diff for NMU version 0.9.14-2.1
Control: tags 870304 + patch
Control: tags 870304 + pending
Dear maintainer,
I've prepared an NMU for yabause (versioned as 0.9.14-2.1) and uploaded
it to DELAYED/10. Please feel free to tell me if I should cancel it.
cu
Adrian
--
"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
diff -Nru yabause-0.9.14/debian/changelog yabause-0.9.14/debian/changelog
--- yabause-0.9.14/debian/changelog 2016-10-29 10:53:24.0 +0300
+++ yabause-0.9.14/debian/changelog 2017-08-29 15:49:16.0 +0300
@@ -1,3 +1,11 @@
+yabause (0.9.14-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Search for gdkglext-config.h in the new location.
+(Closes: #870304)
+
+ -- Adrian Bunk Tue, 29 Aug 2017 15:49:16 +0300
+
yabause (0.9.14-2) unstable; urgency=medium
* Build without dynarec, as this fails with PIE.
diff -Nru yabause-0.9.14/debian/patches/gtkglext-patch.patch yabause-0.9.14/debian/patches/gtkglext-patch.patch
--- yabause-0.9.14/debian/patches/gtkglext-patch.patch 1970-01-01 02:00:00.0 +0200
+++ yabause-0.9.14/debian/patches/gtkglext-patch.patch 2017-08-29 15:49:10.0 +0300
@@ -0,0 +1,15 @@
+Description: Search for gdkglext-config.h in the new location
+Author: Adrian Bunk
+Bug-Debian: https://bugs.debian.org/870304
+
+--- yabause-0.9.14.orig/src/gtk/CMakeLists.txt
yabause-0.9.14/src/gtk/CMakeLists.txt
+@@ -12,7 +12,7 @@ set(PORT_INCLUDE_DIRS ${GTK2_INCLUDE_DIR
+ set(PORT_LIBRARIES ${GTK2_LIBRARIES})
+
+ if (OPENGL_FOUND)
+- find_path(GDKGLEXT_CONFIG_INCLUDE_DIR gdkglext-config.h PATHS ${CMAKE_SYSTEM_PREFIX_PATH} PATH_SUFFIXES lib/gtkglext-1.0/include)
++ find_path(GDKGLEXT_CONFIG_INCLUDE_DIR gdkglext-config.h PATHS ${CMAKE_SYSTEM_PREFIX_PATH} PATH_SUFFIXES include/gtkglext-1.0)
+ find_path(GTKGLEXT_INCLUDE_DIR gtk/gtkgl.h PATH_SUFFIXES gtkglext-1.0)
+ find_library(GDKGLEXT_LIBRARY gdkglext-x11-1.0)
+ find_library(GTKGLEXT_LIBRARY gtkglext-x11-1.0)
diff -Nru yabause-0.9.14/debian/patches/series yabause-0.9.14/debian/patches/series
--- yabause-0.9.14/debian/patches/series 1970-01-01 02:00:00.0 +0200
+++ yabause-0.9.14/debian/patches/series 2017-08-29 15:48:23.0 +0300
@@ -0,0 +1 @@
+gtkglext-patch.patch
Bug#873604: cloud.debian.org: grub shouldn't assume gfxterm
Package: cloud.debian.org Debian8 openstack image uses extlinux. Debian9 switched to grub. Unfortunately the default config for grub uses 'terminal_output gfxterm'. While this runs fine on my openstack setup, it does not boot at all on a simple libvirt+qemu system I have which utilizes rather barebones libvirt guest configs. (guest uses 100% cpu, guest kernel never starts booting) Unless there's a good reason for using gfxterm, I'd suggest adding 'GRUB_TERMINAL=console' to /etc/default/grub and using that to generate grub.cfg. This fixes my qemu booting issue and is in line with what the debian8 image did. (Or maybe even do GRUB_TERMINAL=serial considering the kernel is told to use the serial console.)
Bug#873605: libnova-dev: Multi-Arch not fully implemented
Package: libnova-dev
Version: 0.16-2
According to d/ch, libnova is Multi-Arch since 2012. But unfortunately,
I cannot co-install libnova-dev for different architectures:
$ sudo apt install libnova-dev:{amd64,armel}
Reading package lists... Done
Building dependency tree
Reading state information... Done
libnova-dev is already the newest version (0.16-2).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libnova-dev : Conflicts: libnova-dev:armel but 0.16-2 is to be installed
libnova-dev:armel : Conflicts: libnova-dev but 0.16-2 is to be installed
E: Unable to correct problems, you have held broken packages.
Am I right, that
- Multi-Arch: same has been forgotten for the -dev package?
- /usr/bin/libnovaconfig must go into a new package libnova-dev-bin with
Multi-Arch: foreign?
TIA & Cheers
--
"Furthermore, I consider that PySide2 must be packaged" -- Qt the Elder
Bug#873606: cups: 2.2.4 stopped being able to interact with our cups server
Package: cups Version: 2.2.4-1 Severity: important Hello, Since the upgrade to 2.2.4-1 (more precisely, it is the upgrade of libcups2 which breaks things), I'm not able to print any more: [with 2.2.3-2] $ lpq print2me is ready no entries [with 2.2.4-1] $ lpq lpq: Error - PRINTER environment variable names non-existent destination "print2me". $ lpr /usr/bin/lpr: Error - scheduler not responding. $ lp lp: Error - scheduler not responding. but oddly enough: $ lpstat -a print2me accepting requests since mar. 29 août 2017 14:13:48 CEST Anyway, I had to downgrade to 2.2.3-2 to get printing back working. I'm using $CUPS_SERVER=cups.bordeaux.inria.fr $CUPS_USER=thibault $PRINTER=print2me The server shows: CUPS 1.6.3 Description: File d'attente Follow Me Location: Follow Me BSO Driver: TOSHIBA ColorMFP (color, 2-sided printing) Connection: lpd://193.50.111.138/secure Defaults: job-sheets=none, none media=na_letter_8.5x11in sides=two-sided-long-edge I have attached the TCP sessions of each version. It seems like the cups client does not send $PRINTER to the server at all, thus "No default printer" beign returned. Samuel -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cups depends on: ii cdebconf [debconf-2.0] 0.229 ii cups-client 2.2.4-1 ii cups-common 2.2.4-1 ii cups-core-drivers 2.2.4-1 ii cups-daemon 2.2.4-1 ii cups-filters1.16.1-1 ii cups-ppdc 2.2.4-1 ii cups-server-common 2.2.4-1 ii debconf 1.5.63 ii ghostscript 9.21~dfsg-1 ii libavahi-client30.6.32-2 ii libavahi-common30.6.32-2 ii libc-bin2.24-14 ii libc6 2.24-14 ii libcups22.2.4-1 ii libcupscgi1 2.2.4-1 ii libcupsimage2 2.2.4-1 ii libcupsmime12.2.4-1 ii libcupsppdc12.2.4-1 ii libgcc1 1:7.2.0-1 ii libstdc++6 7.2.0-1 ii libusb-1.0-02:1.0.21-2 ii poppler-utils 0.48.0-2 ii procps 2:3.3.12-3 Versions of packages cups recommends: pn avahi-daemon ii colord 1.3.3-2 ii cups-filters [ghostscript-cups] 1.16.1-1 ii printer-driver-gutenprint5.2.13-1 Versions of packages cups suggests: ii cups-bsd 2.2.4-1 ii foomatic-db-compressed-ppds [foomatic-db] 20170723-1 ii hplip 3.17.7+repack0-3 ii printer-driver-cups-pdf [cups-pdf] 3.0.1-4 ii printer-driver-hpcups 3.17.7+repack0-3 ii smbclient 2:4.6.7+dfsg-1 ii udev 232-25 -- debconf information: cupsys/backend: lpd, socket, usb, snmp, dnssd cupsys/raw-print: true -- Samuel Hi ! I'm a .signature virus ! Copy me into your ~/.signature, please ! POST / HTTP/1.1 Content-Length: 729 Content-Type: application/ipp Host: cups.bordeaux.inria.fr:631 User-Agent: CUPS/2.2.3 (Linux 4.12.0-1-amd64; x86_64) IPP/2.0 Expect: 100-continue .G..attributes-charset..utf-8H..attributes-natural-language..fr-frD..requested-attributes..auth-info-requiredD... device-uriDjob-sheets-defaultDmarker-change-timeD... marker-colorsDmarker-high-levelsD... marker-levelsDmarker-low-levelsDmarker-messageDmarker-namesDmarker-typesDprinter-commandsDprinter-defaultsDprinter-infoDprinter-is-accepting-jobsDprinter-is-sharedDprinter-locationDprinter-make-and-modelD... printer-mandatory-job-attributesDprinter-nameD... printer-stateDprinter-state-change-timeDprinter-state-reasonsDprinter-typeDprinter-uri-supportedB..requesting-user-name..thibaultE..printer-uri.%ipp://localhost:631/printers/print2me.HTTP/1.1 100 Continue HTTP/1.1 200 OK Date: Tue, 29 Aug 2017 12:35:21 GMT Server: CUPS/1.6 IPP/2.1 Connection: Keep-Alive Keep-Alive: timeout=30 Content-Language: fr_FR Content-Type: application/ipp Content-Length: 1122 .G..attributes-charset..utf-8H..attributes-natural-language..fr-fr.!..marker-change-time.."..printer-is-accepting-jobs..."..printer-is-shared...#. printer-state..!..printer-state-change-time..Y.Z|D..printer-state-reasons..none#..printer-type0.E..printer-uri-supported.*ipp://193.50.111.172:631/printers/pri
Bug#873602: pd-xsample FTBFS on ppc64el: UInt32 does not name a type
Control: severity -1 important On 2017-08-29 08:45:40, Roberto Oliveira wrote: > Package: pd-xsample > Version: 0.3.2~git20161105.1.d16761a1-1 > Severity: serious > > https://buildd.debian.org/status/fetch.php?pkg=pd-xsample&arch=ppc64el&ver=0.3.2%7Egit20161105.1.d16761a1-1&stamp=1486228622&raw=0 It never built there, so it's important, not serious. Cheers > ... > make[2]: Entering directory '/«PKGBUILDDIR»' > info: using Makefile.pdlibbuilder version 0.4.4 > info: using Pd API /usr/include/pd/m_pd.h > info: making target all in lib xsample > info: making source/main.o in lib xsample > g++ -DPD -I "/usr/include/pd" -DUNIX -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC > -fcheck-new -DPD -DFLEXT_SYS=2 -DFLEXT_SHARED -DFLEXT_USE_CMEM > -I/usr/include/flext -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat > -Werror=format-security -o source/main.o -c source/main.cpp > In file included from source/main.cpp:13:0: > source/main.h:82:9: error: 'UInt32' does not name a type > inline UInt32 GetPrefetchConstant( int blockSizeInVectors,int > blockCount,int blockStride ) > ^~ > /usr/share/pd-lib-builder//Makefile.pdlibbuilder:867: recipe for target > 'source/main.o' failed > make[2]: *** [source/main.o] Error 1 > make[2]: Leaving directory '/«PKGBUILDDIR»' > debian/rules:9: recipe for target 'override_dh_auto_build' failed > make[1]: *** [override_dh_auto_build] Error 2 > make[1]: Leaving directory '/«PKGBUILDDIR»' > debian/rules:6: recipe for target 'build-arch' failed > make: *** [build-arch] Error 2 > > > > -- System Information: > Debian Release: buster/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: ppc64el (ppc64le) > > Kernel: Linux 4.11.0-2-powerpc64le (SMP w/16 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), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_US.UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > ___ > pkg-multimedia-maintainers mailing list > pkg-multimedia-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#873608: uhd FTBFS on armhf dues to NEON
Source: uhd Version: 3.10.2.0-1 Severity: serious https://buildd.debian.org/status/fetch.php?pkg=uhd&arch=armhf&ver=3.10.2.0-1&stamp=1503874671&raw=0 ... In file included from /«PKGBUILDDIR»/host/lib/convert/convert_with_neon.cpp:20:0: /usr/lib/gcc/arm-linux-gnueabihf/7/include/arm_neon.h: In member function 'virtual void __convert_fc32_1_sc16_item32_le_1_PRIORITY_SIMD::operator()(const input_type&, const output_type&, size_t)': /usr/lib/gcc/arm-linux-gnueabihf/7/include/arm_neon.h:6740:1: error: inlining failed in call to always_inline 'float32x4_t vdupq_n_f32(float32_t)': target specific option mismatch vdupq_n_f32 (float32_t __a) ^~~ /«PKGBUILDDIR»/host/lib/convert/convert_with_neon.cpp:36:53: note: called from here float32x4_t Q0 = vdupq_n_f32(float(scale_factor)); ^ In file included from /«PKGBUILDDIR»/host/lib/convert/convert_with_neon.cpp:20:0: /usr/lib/gcc/arm-linux-gnueabihf/7/include/arm_neon.h:10844:1: error: inlining failed in call to always_inline 'void vst1_s16(int16_t*, int16x4_t)': target specific option mismatch vst1_s16 (int16_t * __a, int16x4_t __b) ^~~~ /«PKGBUILDDIR»/host/lib/convert/convert_with_neon.cpp:65:17: note: called from here vst1_s16((reinterpret_cast(&output[i+6])), D15); ^~ In file included from /«PKGBUILDDIR»/host/lib/convert/convert_with_neon.cpp:20:0: /usr/lib/gcc/arm-linux-gnueabihf/7/include/arm_neon.h:9027:1: error: inlining failed in call to always_inline 'int16x4_t vrev32_s16(int16x4_t)': target specific option mismatch vrev32_s16 (int16x4_t __a) ^~ /«PKGBUILDDIR»/host/lib/convert/convert_with_neon.cpp:64:39: note: called from here int16x4_t D15 = vrev32_s16(D14); ^ In file included from /«PKGBUILDDIR»/host/lib/convert/convert_with_neon.cpp:20:0: /usr/lib/gcc/arm-linux-gnueabihf/7/include/arm_neon.h:7552:1: error: inlining failed in call to always_inline 'int16x4_t vmovn_s32(int32x4_t)': target specific option mismatch vmovn_s32 (int32x4_t __a) ^ /«PKGBUILDDIR»/host/lib/convert/convert_with_neon.cpp:63:38: note: called from here int16x4_t D14 = vmovn_s32(Q13); ^ ... NEON is not part of the armhf port baseline.
Bug#873609: gcc-7: Please cherry-pick a fix on gsplit-dwarf
Source: gcc-7 Severity: important Hello, Upstream regressed on the option -gsplit-dwarf causing breakage on all platforms. Removing this option causes llvm-toolchain-* to break on 32 bit archs (OOM) Please cherry-pick upstream revision r251399 into gcc packages so that this option can be used again. Upstream bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81993 Thanks, Sylvestre
Bug#873607: ITP: odb-api -- Observational Data processing API for meteorology
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: odb-api Version : 0.17.1 Upstream Author : European Centre for Medium-Range Forecasts (ECMWF) * URL : http://software.ecmwdf.int/wiki/display/ODBAPI * License : Apache Programming Lang: C++, Fortran, Python Description : Observational Data processing API for meteorology ODB API is a software developed at ECMWF for encoding and processing of observational data. It includes a SQL filtering and statistics engine, command line tools and APIs for C/C++, Fortran and Python. ODB API works with data format used in ECMWF observational feedback archive. Development of ODB API has been partially funded by the Met Office.
Bug#873611: nethogs does not run with error: creating socket failed
Package: nethogs Version: 0.8.0-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** I installed nethogs and it does not run. I am running it as root user. I get the following error message 'creating socket failed while establishing local IP - are you root?'. I have seen on the web that this has been fixed however this upgraded nethogs has not made to Debian 8.9. Does the updated nethogs package need to be pushed down to this version of Debian? I am willing to test the newer version of nethogs, but I need guidance on how to proceed. Thank you for your time. -- System Information: Debian Release: 8.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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: systemd (via /run/systemd/system) Versions of packages nethogs depends on: ii libc62.19-18+deb8u10 ii libgcc1 1:4.9.2-10 ii libncurses5 5.9+20140913-1+b1 ii libpcap0.8 1.6.2-2 ii libstdc++6 4.9.2-10 nethogs recommends no packages. nethogs suggests no packages. -- no debconf information
Bug#873612: lintian: please check latest-debian-changelog-entry-without-new-date for sources as well
Package: lintian Version: 2.5.52 Currently latest-debian-changelog-entry-without-new-date only checks binary changelogs. It would be useful if it checked also debian/control in source packages. (this is related to having it be a dak autoreject, as the lintian checks are performend only during the source upload, not during the binary only uploads from buildds) -- 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#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free
I am inclined to just put it in unstable and not backport, but created the bug to see if the security team felt otherwise. If you look at the pull request history for the upstream commit, it seems that it was languishing there for a while before getting merged, as well. -Ben
Bug#873610: dget:dget: does not preserve timestamps
Package: devscripts Version: 2.17.9 Severity: minor When I call dget with a path to a .dsc, it and its subfiles are downloaded and stored with the current timestamp. When I use wget on the same path, with no special options, the timestamps from the archive are retained. -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- DEBCHANGE_AUTO_NMU=no DEBCHANGE_MAINTTRAILER=no DEBCHANGE_MULTIMAINT_MERGE=yes DEBCHANGE_RELEASE_HEURISTIC=log -- System Information: Debian Release: buster/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages devscripts depends on: ii dpkg-dev 1.18.24 ii libc6 2.24-14 ii libfile-homedir-perl 1.00-1 ii perl 5.26.0-5 ii python3 3.5.3-3 Versions of packages devscripts recommends: ii apt 1.5~beta2 ii at 3.1.20-3 ii curl7.55.0-1 ii dctrl-tools 2.24-2 ii debian-keyring 2017.05.28 ii dput0.12.1 pn equivs ii fakeroot1.22-1 ii file1:5.31-1 ii gnupg 2.1.23-2 pn libdistro-info-perl ii libdpkg-perl1.18.24 ii libencode-locale-perl 1.05-1 pn libgit-wrapper-perl pn liblist-compare-perl ii liblwp-protocol-https-perl 6.07-2 pn libsoap-lite-perl ii liburi-perl 1.72-1 ii libwww-perl 6.15-2 ii licensecheck3.0.30-1 ii lintian 2.5.52 ii man-db 2.7.6.1-2 ii patch 2.7.5-1 ii patchutils 0.3.4-2 ii python3-debian 0.1.30 ii python3-magic 1:5.31-1 pn python3-unidiff ii sensible-utils 0.0.10 ii strace 4.11-1 ii unzip 6.0-21 ii wdiff 1.2.2-2 ii wget1.19.1-4 ii xz-utils5.2.2-1.3 Versions of packages devscripts suggests: ii adequate 0.15.1 pn autopkgtest pn bls-standalone ii bsd-mailx [mailx]8.1.2-0.20160123cvs-4 ii build-essential 12.3 pn check-all-the-things pn cvs-buildpackage pn devscripts-el ii diffoscope 85 pn disorderfs pn dose-extra pn duck pn faketime pn gnuplot ii gpgv 2.1.23-2 pn how-can-i-help pn libauthen-sasl-perl pn libfile-desktopentry-perl pn libnet-smtps-perl pn libterm-size-perl ii libtimedate-perl 2.3000-2 pn libyaml-syck-perl pn mozilla-devscripts pn mutt ii openssh-client [ssh-client] 1:7.5p1-7 pn piuparts ii quilt0.63-8.1 pn ratt pn reprotest pn svn-buildpackage pn w3m -- no debconf information
Bug#873614: libsubunit-dev: Multi-Arch: same is missing
Package: libsubunit-dev Version: 1.1.0-3 Because libsubunit-dev is not flagged as Mult-Arch: same, one cannot install for multiple architectures. This affects correct, depending packages, such as "check". Btw. the VCS field - or Alioth Git - is broken: https://anonscm.debian.org/cgit/openstack/subunit.git/ says "No repositories found".
Bug#873613: systemd gets confused at shutdown time
Package: systemd Version: 232-25+deb9u1 At shutdown time systemd just shows a message saying watchdog: watchdog0: watchdog did not stop! for 5 minutes :-(. If I boot without quiet, then systemd reveals that it gets confused by service dependencies, nfs mount points and probably some virtual block devices (mdadm, lvm2, crypt, etc). Basic problem seems to be indicated by the message nfs: server nfs-home not responding, timed out pretty late at shutdown time. 90 secs before it tried to unmount the local mount points. Apparently it ignored NFS completely. No wonder that it got stuck. Would you mind to check and fix for stretch? Thanx in advance Harri
Bug#870640: Make source package bootstrappable
Hi, Thanks for your reply. On Mon, Aug 28, 2017 at 06:49:02PM +0200, Mattia Rizzolo wrote: > On Mon, Aug 28, 2017 at 10:36:45PM +0900, Osamu Aoki wrote: ... > > Then the commit message made me wonder why perl library is needed for build > > script. It was unintuitive but reminded me of my own experience of > > writing buggy code and its failed test build for uscan.pl. It failed > > before even running "make test". This is because scripts/Makefile has > > "all" target from which the following code is run: > > > > perl -I ../lib -c $@ > > > > This is to catch syntax error but probably cause error if pertinent perl > > library modules are not available. (Actually, 2 such lines.) > > > > In order to skip such dependency to perl library modules during the > > build, I think, you need to disable these syntax checking lines by > > changing above mentioned lines to: > > > > ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) > > perl -I ../lib -c $@ > > endif > > Wouldn't make sense to move that thing to the test target instead? Also you mentioned later: > Well, rather not. Build profiles are a packaging thing, such check > should be done in d/rules, and have it call make with some other option. Valid points by itself. From the POV of logical factoring, yes I agree. But this is a Debian native package with script/Makefile already mentioning data in debian/*. So being picky on this point serves little benefits. >From practical checking of code by running test/test_* directly after updating the code, build system after logical factoring requires us to run test target manually in advance. Extra work. Also test target will likely to check all commands making it slow and non-focused. Anyway, if you insist logical solution: $ git diff # tab code broken diff --git a/scripts/Makefile b/scripts/Makefile index ece5455a..3a83cb0f 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -18,6 +18,8 @@ CFLAGS += -std=c99 LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS) CWRAPPERS = debpkg-wrapper SCRIPTS = $(patsubst %.pl,%,$(PL_FILES)) $(patsubst %.sh,%,$(SH_FILES)) +PL_CHECKS $(patsubst %.pl,%.pl.check,$(PL_FILES)) +SH_CHECKS $(patsubst %.pl,%.sh.check,$(SH_FILES)) COMPL_FILES := $(wildcard *.bash_completion) BC_BUILD_DIR:=bash_completion COMPLETION = $(patsubst %.bash_completion,$(BC_BUILD_DIR)/%,$(COMPL_FILES)) @@ -44,17 +46,18 @@ ifeq ($(shell dpkg-vendor --query Vendor),Ubuntu) # will be for preparing PPA uploads. sed -i 's/get_ubuntu_devel_distro()/"$(shell lsb_release -cs)"/' $@ endif - perl -I ../lib -c $@ %.tmp: %.sh $(VERSION_FILE) sed -e "s/###VERSION###/$(VERSION)/" $< > $@ - bash -n $@ +%.sh.check: % + bash -n $< %.tmp: %.pl $(VERSION_FILE) sed -e "s/###VERSION###/$(VERSION)/" $< > $@ - perl -I ../lib -c $@ %: %.tmp cp $< $@ chmod +x $@ +%.pl.check: % + perl -I ../lib -c $< %.1: %.pl podchecker $< @@ -88,7 +91,7 @@ clean: rm -f $(SCRIPTS) $(patsubst %,%.tmp,$(SCRIPTS)) \ $(GEN_MAN1S) $(SCRIPT_LIBS) $(CWRAPPERS) -test: +test: $(PL_CHECKS) $(SH_CHECKS) python3 -m flake8 --max-line-length=99 $(PYTHON3_SCRIPTS) $(foreach python,$(shell py3versions -r ../debian/control),$(python) setup.py test$(\n)) something along this should solve all stupid perl module build dependency issues. If you like this way, I am OK with this. > The following packages have unmet dependencies: > builddeps:/build/devscripts_2.17.10.dsc:arm64 : Depends: > libfile-desktopentry-perl:arm64 but it is not installable > Depends: > libfile-homedir-perl:arm64 but it is not installable > Depends: > libgit-wrapper-perl:arm64 but it is not installable > Depends: > liblist-compare-perl:arm64 but it is not installable > Depends: liburi-perl:arm64 > but it is not installable > Depends: libwww-perl:arm64 > but it is not installable Oh, unless you disable the target content in "devscripts.1: devscripts.1.in" , perl is needed for building this manpage. It calls perl via "perl ../debian/genmanpage.pl" > Depends: perl:arm64 but it > is not going to be installed Osamu
Bug#872057: The problem in flexbackup has to do with tar
Further tests have shown that the bug in flexbackup seems to surface only when using tar. I did not test all other tools supported by tar but several backups using cpio and zip all went through without the problem. Debian Jessie used tar 1.27 while Debian Stretch uses tar 1.29. I can't tell if the problem exists because there was a change in the way tar parses its input or commands or if there is a problem in tar itself. Maybe somebody who is better than me looking at “long command lines” (do flexbackup ... -n to make a dry run and see the command line) can tell what is wrong.
Bug#873606: cups: 2.2.4 stopped being able to interact with our cups server
found 873606 2.2.4-4 thanks On Tue 29 Aug 2017 at 14:52:58 +0200, Samuel Thibault wrote: > Package: cups > Version: 2.2.4-1 > Severity: important > > Hello, > > Since the upgrade to 2.2.4-1 (more precisely, it is the upgrade of > libcups2 which breaks things), I'm not able to print any more: > > [with 2.2.3-2] > $ lpq > print2me is ready > no entries > > [with 2.2.4-1] > $ lpq > lpq: Error - PRINTER environment variable names non-existent destination > "print2me". > $ lpr > /usr/bin/lpr: Error - scheduler not responding. > $ lp > lp: Error - scheduler not responding. > > but oddly enough: > $ lpstat -a > print2me accepting requests since mar. 29 août 2017 14:13:48 CEST > > > Anyway, I had to downgrade to 2.2.3-2 to get printing back working. > > > I'm using > $CUPS_SERVER=cups.bordeaux.inria.fr > $CUPS_USER=thibault > $PRINTER=print2me > > The server shows: CUPS 1.6.3 > > Description: File d'attente Follow Me >Location: Follow Me BSO > Driver: TOSHIBA ColorMFP (color, 2-sided printing) > Connection: lpd://193.50.111.138/secure >Defaults: job-sheets=none, none media=na_letter_8.5x11in > sides=two-sided-long-edge > > > I have attached the TCP sessions of each version. It seems like the cups > client does not send $PRINTER to the server at all, thus "No default > printer" beign returned. I was just about to post in reply to M G Berberich's mail to #870463 when this one arrived. My suggestion was (and still is) that the ~/.cups/lpoptions be moved and the PRINTER (or LPDEST) environment variable be set instead. (M G Berberich has been CC'ed). pcl is a local print queue set to print to a file. With 'lpstat -d' I get lpstat: error - PRINTER environment variable names non-existent destination "pcl". 'lp /etc/nsswitch' gives lp: Error - scheduler not responding. Regards, Brian.
Bug#871058: Raising severity of FTBFS bugs since vala 0.36 is in unstable
Control: severity -1 serious vala 0.36 is in unstable now. Thanks, Jeremy Bicha
Bug#871186: Raising severity of FTBFS bugs since vala 0.36 is in unstable
Control: severity -1 serious vala 0.36 is in unstable now. Thanks, Jeremy Bicha
Bug#873088: Wheezy update of git-annex?
Hello Richard, First I want to point out that git-annex 6.20170818-1 failed to build on arm64, you might want to ask for a give-back to retry with a newer compiler (gcc 7.2 landed in unstable since the failed build on arm64). Apart from that, the Debian LTS team would like to fix the security issues which are currently open in the Wheezy version of git-annex: https://security-tracker.debian.org/tracker/CVE-2017-12976 Would you like to take care of this yourself? If yes, please follow the workflow we have defined here: https://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-...@lists.debian.org (via a debdiff, or with an URL pointing to the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. Indicate clearly whether you have tested the updated package or not. If you don't want to take care of this update, it's not a problem, we will do our best with your package. Just let us know whether you would like to review and/or test the updated package before it gets released. You can also opt-out from receiving future similar emails in your answer and then the LTS Team will take care of git-annex updates for the LTS releases. Thank you very much. Raphaël Hertzog, on behalf of the Debian LTS team. PS: A member of the LTS team might start working on this update at any point in time. You can verify whether someone is registered on this update in this file: https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#873606: cups: 2.2.4 stopped being able to interact with our cups server
Hello, Brian Potkin, on mar. 29 août 2017 14:36:28 +0100, wrote: > I was just about to post in reply to M G Berberich's mail to #870463 > when this one arrived. My suggestion was (and still is) that the > ~/.cups/lpoptions be moved and the PRINTER (or LPDEST) environment > variable be set instead. (M G Berberich has been CC'ed). I had read that bug, and thus removed my .cups/lpoptions file already, with the same issue. I don't think the two bugs are related. Samuel
Bug#873615: Fails to detect changes in tarballs that share the same top-level directory
Package: tardiff
Version: 0.1-5
Severity: normal
Tags: patch
Hi,
Perhaps I'm not using this utility in the way it was intended to be
used, but it falsely reports tarballs to be identical if the top-level
directories are identical. This is because the tarballs get extracted
to the same location, and therefore files are always compared to
themselves. This is the case with Debian tarballs, since the top-level
directory will always be debian/.
I have attached a patch which fixes this.
I also detected a minor fault in its error messages. 'Too much arguments'
should be changed to "Too many arguments'.
Best regards,
Carlos
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.12.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages tardiff depends on:
ii libtext-diff-perl 1.44-1
ii perl 5.26.0-5
tardiff recommends no packages.
tardiff suggests no packages.
-- no debconf information
>From 7ff1a7d462dbd48e634aba4c1181b187310b667b Mon Sep 17 00:00:00 2001
From: Carlos Maddela
Date: Tue, 29 Aug 2017 23:24:57 +1000
Subject: [PATCH] Handle tarballs with the same top-level directory.
---
tardiff | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/tardiff b/tardiff
index 2577b8f..000e9b1 100755
--- a/tardiff
+++ b/tardiff
@@ -67,6 +67,10 @@ sub arguments{
sub untar{
my $tarball = shift(@_);
+my $prefix = shift(@_);
+
+my $tardir = "$tempdir/$prefix";
+mkdir $tardir or die "Couldn't create $tardir";
my $flag = "";
if($tarball =~ /\.gz$/){
@@ -75,7 +79,7 @@ sub untar{
$flag = "-j";
}
- open(TARLIST, '-|', qw(tar -C), $tempdir, $flag, qw(-xvf), $tarball)
+ open(TARLIST, '-|', qw(tar -C), $tardir, $flag, qw(-xvf), $tarball)
or die "Can't call tar as expected: $!";
local $/ = undef; # slurp mode
my $list = or die "Couldn't read from tar";
@@ -174,8 +178,8 @@ sub autofile{
sub tardiff{
my $error = 0;
- my $filelist1 = untar($tarball1) or die "Error: Could not unpack
$tarball1.";
- my $filelist2 = untar($tarball2) or die "Error: Could not unpack
$tarball2.";
+ my $filelist1 = untar($tarball1, 1) or die "Error: Could not unpack
$tarball1.";
+ my $filelist2 = untar($tarball2, 2) or die "Error: Could not unpack
$tarball2.";
my %files;
@@ -189,7 +193,7 @@ sub tardiff{
next if $opt_autoskip and autofile($file);
my $modified = 0;
if($opt_modified){
- $modified = comparefile($base1, $base2, $file);
+ $modified = comparefile("1/$base1", "2/$base2",
$file);
if($modified){
if($opt_stats){
print "/ $file $modified\n";
--
2.14.1
Bug#866121: add Depends gvfs-backends
On Tue, Jun 27, 2017 at 10:09:53PM +0800, 積丹尼 Dan Jacobson wrote: > Add Depends: gvfs-backends > or else right out of the box > $ epiphany > will produce error messages and the add blocker won't work. > > Or, just add it as a Recommends, I confirm this, a user has just reported this same problem to me, and it's not obvious what the missing component is. So I'd add gvfs-backends as a recommended package. Berto
Bug#873618: openvpn: after security-upgrade openvpn can't access cert-files when started via systemd
Package: openvpn Version: 2.4.3 Severity: important Dear Maintainer, after upgrading openvpn et al. (apt-get update, apt-get upgrade) the service fails to start with attached error messages (syslog_errors). The messages say, that certain files (certs, keys) are not existent. When I start manually (openvpn /etc/openvpn/lip.conf), openvpn runs absolutely flawless (started_manually). Even after giving full access rights to this files to everybody, openvpn don't start as service. -- System Information: Debian Release: 9.0 APT prefers stable Architecture: amd64 (x86_64) syslog_errors Description: Binary data started_manually Description: Binary data
Bug#873616: libdazzle: Incomplete debian/copyright?
Source: libdazzle Version: 3.25.5-1 Severity: serious Justication: Policy 12.5 X-Debbugs-CC: Jeremy Bicha Hi, I just ACCEPTed libdazzle from NEW but noticed it was missing attribution in debian/copyright for at least Garrett Regier, Async Open Source, James Henstridge etc etc. (This is not exhaustive so please check over the entire package carefully and address these on your next upload.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#873379: devscripts: Please enable hardening buildflags (for /usr/bin/debpkg)
Control: tag -1 moreinfo Hi Chris! On Sun, Aug 27, 2017 at 02:02:20AM -0700, Chris Lamb wrote: > Source: devscripts […] > Tags: patch […] > Patch attached. There is no patch attached to your mail :) -- 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#873617: libdbus-glib-1-dev: Multi-Arch issue
Package: libdbus-glib-1-dev Version: 0.108-2 I cannot install libdbus-glib-1-dev for more than one architecture at the same time. I assume, that Multi-Arch: same should be set, and that dbus-binding-tool must go in a new package libdbus-glib-1-dev-bin with Multi-Arch: foreign, right?
Bug#870312: flatpak FTBFS on amd64/arm64: ERROR: testlibrary - missing test plan
On Tue, 01 Aug 2017 at 00:38:58 +0300, Adrian Bunk wrote:
> Some recent change in unstable makes flatpak FTBFS on amd64/arm64:
>
> https://tests.reproducible-builds.org/debian/history/flatpak.html
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/flatpak.html
I can't reproduce this in my local sbuild, but it's still happening on
the reproducible-builds infrastructure. It might be related to the use
of pbuilder on reproducible-builds?
Have you reproduced this yourself, or are you reporting it purely based on
what you see on reproducible-builds.org?
> # random seed: R02Sbf4ab0218f9346d8617da03c0d7234c9
> # flatpak:ERROR:tests/testlibrary.c:668:add_remote: assertion failed (status
> == 0): (256 == 0)
This is status from:
g_spawn_sync (NULL, (char **)argv, NULL, flags, NULL, NULL, NULL, NULL,
&status, &error);
where argv is { "flatpak", "remote-add", ... } and error indicates that
g_spawn_sync() did not immediately fail (therefore status is a waitpid()
result). Applying WIFEXITED() and WEXISTATUS() indicates that
"flatpak remote-add ..." exited 1.
The next step is to make this fail in an environment where g_test_verbose()
would return true (or patch out that check), so that we see flatpak's stderr.
I'm not entirely sure why upstream suppressed its stderr here.
S
Bug#873619: template-glib: debian/copyright references online source without quote
Source: template-glib Version: 3.25.3-1 Severity: serious Justication: Policy 12.5 X-Debbugs-CC: Jeremy Bicha Hi, I just ACCEPTed template-glib from NEW but noticed it uses an URL as a source: Comment: A few files were incorrectly marked as GPL-3+ but those have been relicensed to LGPL-2.1+ by their author here: https://git.gnome.org/browse/template-glib/commit/?id=6f6bd5 It's great its been licensed correctly but referring to a URL requires that our users must be online to check the copyright (think of the Desert Island Test!), the site never changes, the URL does not go stale, etc. etc. Please additionally quote the relevant section of the page you are link. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#872715: Compat 10
Please see the new autoreconf policy https://lintian.debian.org/tags/useless-autoreconf-build-depends.html All the best! Viktor -- +36204242498 Ezen a készüléken sok az elütés. Elnézést!
Bug#873620: util-linux: dmesg stops if kernel ring buffer fills
Package: util-linux Version: 2.29.2-4 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? dmesg -T * What exactly did you do (or not do) that was effective (or ineffective)? dmesg -T * What was the outcome of this action? Output stopped on 8/25/17 (today is 8/29/17) * What outcome did you expect instead? Output of the last day or so entries *** End of the template - remove these template lines *** The default kernel printk buffer size is 262144 bytes (kernel parameter log_buf_len has a default of 2^18). I expected that it would wrap and begin new entries after filling. I have added a workaround to the grub menu entry to specify a 1M buffer length. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.12.0-1-686-pae (SMP w/2 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), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages util-linux depends on: ii fdisk 2.29.2-4 ii libblkid1 2.29.2-2 ii libc6 2.24-14 ii libmount1 2.29.2-2 ii libpam0g 1.1.8-3.6 ii libselinux12.6-3+b2 ii libsmartcols1 2.29.2-2 ii libsystemd0234-2.3 ii libtinfo5 6.0+20170715-2 ii libudev1 234-2.3 ii libuuid1 2.29.2-2 ii zlib1g 1:1.2.8.dfsg-5 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.1-1 ii kbd 2.0.4-1 ii util-linux-locales 2.29.2-2 -- debconf information: util-linux/noauto-with-nonzero-passnum:
Bug#873613: systemd gets confused at shutdown time
Control: tags -1 moreinfo On Tue, Aug 29, 2017 at 10:35 AM, Harald Dunkel wrote: > Package: systemd > Version: 232-25+deb9u1 > > At shutdown time systemd just shows a message saying > > watchdog: watchdog0: watchdog did not stop! > > for 5 minutes :-(. > > If I boot without quiet, then systemd reveals that it gets > confused by service dependencies, nfs mount points and > probably some virtual block devices (mdadm, lvm2, crypt, > etc). Please attach the full configuration for your mount points. > Basic problem seems to be indicated by the message > > nfs: server nfs-home not responding, timed out > Looks like systemd shut down your network before it unnmounted remote filesystems. > pretty late at shutdown time. 90 secs before it tried to > unmount the local mount points. Apparently it ignored NFS > completely. No wonder that it got stuck. > > Would you mind to check and fix for stretch? Could you attach full logs? Attaching the info generated by reportbug would be useful too. -- Saludos, Felipe Sateler
Bug#873379: devscripts: Please enable hardening buildflags (for /usr/bin/debpkg)
tags 873379 - moreinfo thanks Hi Mattia, > There is no patch attached to your mail :) Whoops! Let's try that again... Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff --git a/debian/rules b/debian/rules index d107992..6660cd5 100755 --- a/debian/rules +++ b/debian/rules @@ -1,6 +1,11 @@ #!/usr/bin/make -f UBU_SUGGESTS=debian-keyring, equivs, liblwp-protocol-https-perl, libsoap-lite-perl +DPKG_EXPORT_BUILDFLAGS = 1 + +export DEB_BUILD_MAINT_OPTIONS = hardening=+all + +include /usr/share/dpkg/buildflags.mk %: dh $@ --with python3
Bug#870472: Pending fixes for bugs in the rename package
tag 870472 + pending thanks Some bugs in the rename package are closed in revision b25fb51c36c992038bef83f07a2c6582c9a8ddd4 in branch ' dom/provide-prename' by Dominic Hargreaves The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/rename.git/commit/?id=b25fb51 Commit message: Add prename symlink, with suitable Breaks/Replaces on perl (Closes: #870472)
Bug#873618: openvpn: after security-upgrade openvpn can't access cert-files when started via systemd
Hi Georg, According to the syslog_errors messages it seems that your config is trying to use SSL/TLS certificate files hosted in root's home. This is not permitted now that the systemd unit uses "ProtectHome=true". A good way to avoid that problem and follow best practices would be to create a directory, say /etc/openvpn/lip, and put those files in there. Once in there, you don't need to weaken their permissions as they will be accessed as root prior to any UID downgrade. Another way would be to include them inline in the lip.conf instead. For details, see "INLINE FILE SUPPORT" from openvpn(8) man page. HTH, Simon signature.asc Description: OpenPGP digital signature
