Bug#899221: [RFC @point 11.] Bug#899221: break up emacs-goodies-el into many elpafied packages
Hi Julian and Emacsen Team, Thank you very much for taking the time to reply to these questions. You can skip the rest of this email if you're busy, and there will be no more CCed emails :-) Breaking up emacs-goodies-el and working to make it a transitional package is now underway. David, I'm very grateful for your bug triaging. It makes sense to cut down on the number of packages before considering the possibility of maintaining any. Also, thanks for doing dpkg-dev-el and debian-el. Sean, so I guess we're in phase 2 (breaking out those two pkgs was phase 1). I'll definitely be returning to reread your comments when we hit phase 3—considering becoming upstream for a subset of packages. Thank you :-) On Mon, Jun 25, 2018 at 10:48:41PM +0100, Julian Gilbey wrote: > On Thu, Jun 14, 2018 at 03:25:14PM -0400, Nicholas D Steeves wrote: > > > > 0. Is the Emacsen Team going to maintain all of the new packages? If > > so, can Peter S Galbraith and Julian Gilbey be added to the team and > > to the Uploaders for all these new packages? > > I have really not had the skill or time to maintain these, > unfortunately. For this reason, I don't think it's worth listing me > on the elpa-ified packages, and I think Peter said that he was happy > for you all to adopt the package (so not to list him either). Thanks for confirming, I won't add either of you. > > 1. Src:emacs-goodies-el is a native 3.0 package, but includes many > > quilt packages. I think the historical reason for this is that it > > allowed the maintainer to manually update a lisp file from a mailing > > list, wiki, or forum copy, and then resolve conflicts between hunks of > > the patch and the new upstream source. Also, this preserves > > separation between these sources and Debian changes... > > > > It is clear that any bin:emacs-goodies-el component that has a living > > upstream should be transitioned to a non-native elpafied package, but > > maybe this would be a good time to take advantage of one of the > > conveniences of native-packaging for packages that do no have a living > > upstream? eg: We apply the stack of patches to the native package > > source. Conversely, if maintaining a pristine copy of the original > > source is more desirable then wouldn't a non-native package be more > > appropriate? > > This all sounds sensible to me. To Team: At this point the plan seems to be to outright drop anything with a dead upstream. 11. At what point in the future do you think packages should be removed from goodies when a maintainer for the elpa-variant hasn't yet stepped forward? eg: Let's define this best case scenario: all 90 subpackages have been triaged before DebCamp. Worst case of: sometime before September. Aug 12th is six months before the "no-rentry into testing" deadline of Feb 2019. > > 4. I noticed that emacs-goodies-el has not had a dependency on an > > elpafied packages added each time a file is removed. This seems to > > indicate that when this work is completed bin:emacs-goodies-el will > > just silently disappear and users will be left without the modes they > > are used to having after an upgrade. Is this intended, or should > > emacs-goodies-el become a dummy transitional package? > > emacs-goodies-el should certainly become a dummy transitional package > - that is good Debian practice. Then the git repo will also have to > be preserved. > > > 5. It seems like emacs-goodies-el should be kept around as a dummy > > package for the purposes of bug tracking, because I don't think anyone > > should be rushed to triage src:emacs-goodies-el's many bug reports. > > See point 4: it still will be. For the bug reports, when the package > is elpa-ified, it would be good to at least reassign the bugs to the > relevant new package, though that is a fair bit of work. > > I have nothing to add to the XEmacs discussion. To Team: Ok, with the work in progress src:emacs-goodies-el is dropping XEmacs support, and this is documented in debian/NEWS. Cheers, Nicholas signature.asc Description: PGP signature
Bug#557932: split out matlab-mode
On Fri, Jun 29, 2018 at 09:45:33PM -0300, David Bremner wrote: > > retitle 557932 replace matlab.el with elpa-matlab > user debian-emac...@lists.debian.org > usertag 557932 elpafy > quit > > There is an active upstream for this one, and a reasonable number of > downloads on melpa, so probably we should preserve it. > > Splitting to it's own package will also reduce the impact of this issue > of competing file extensions, since presumably less people will install > elpa-matlab and want to edit objective-C. I filed #902739 to reach a larger audience of potential matlab+emacs users, because this is one I'm not confident QAing. Question 11. at #899221 affects this bug (and others). Cheers, Nicholas signature.asc Description: PGP signature
Bug#902612: Packages should not touch users' home directories
On Thu, Jun 28, 2018 at 8:56 AM, Sean Whitton wrote: >> Packages must not contain files in /home, and packages' maintainer >> scripts must not write to users' home directories. The programs in >> those packages may create directory hierarchies as described in >> §3.8.3 "Home Directory Specifications and Conventions" when run by >> a user. Would it be clearer to say "programs and shell scripts" to explicitly permit wrapper scripts §9.9 written by the maintainer? Best wishes, Mike
Bug#902659: mirrors.shu.edu.cn issues
Hi, We have look into the debian mirror, and we cannot judge the cause of the failure on your monitoring system. From the log of ftpsync, the debian mirror is normal. So the debian mirror is normal. In your monitor page, the error message is Connection refused. If the mirrror-master is using rsync to monitor the debian mirror. please tell use to add the limit of the rsync. And if the mirror-master is using HTTP to monitor it, we cannot find anything at all. By the way, we cannot find us in the debian mirror sites page https://www.debian.org/mirror/list.en.html . Best Regards. Li Shengzhou Shanghai University Open Source Community 在 2018年6月29日 +0800 PM4:51，Peter Palfrader ，写道： Package: mirrors User: mirr...@packages.debian.org Usertags: mirror-problems Hi! according to https://mirror-master.debian.org/status/mirror-info/mirrors.shu.edu.cn.html our monitoring system can't get to your mirror most of the times. Please look into it. If we can't ensure your mirror is working, we will have to remove it from our mirrors list. Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `- https://www.debian.org/
Bug#476414: Permissions needed
To fix this (if your file system supports file capabilities): 1. Install the libcap2-bin package. 2. As root, enter the following command: setcap cap_sys_resource=ep /usr/bin/wodim Note that this enables wodim to override a variety of resource limits, which is a risk to system security and stability. You might want to mitigate that risk by only allowing trusted user accounts to execute it. For example: chgrp users /usr/bin/wodim chmod o-x /usr/bin/wodim setcap cap_sys_resource=ep /usr/bin/wodim Note also that all of these changes (permissions and file capabilities) will be reset next time the wodim package is upgraded or reinstalled. --- Ideally, the wodim executable should be given the file capability by a package installation script, and it should drop that privilege early in its execution, right after making its setrlimit call. This would solve the problem while greatly mitigating the risks.
Bug#902739: RFP: matlab-mode -- major mode for editing Matlab dot-m / .m files
Package: wnpp Severity: wishlist Package name: matlab-mode Version : neither upstream tags releases Upstream Author : Honglin Yu or Oleh Krehel URL : https://github.com/yuhonglin/matlab-mode or https://github.com/abo-abo/matlab-mode/tree/master/toolbox License : GPL-2+ and GPL-2+ Programming Lang: elisp or elisp+matlab Description : major mode for editing Matlab dot-m / .m files Matlab.el will be dropped from src:emacs-goodies.el. (Bug #557932) I am filing this request for packaging an elpafied replacement because I do not anticipate ever learning enough MATLAB to adequately QA this package. Sincerely, Nicholas
Bug#902716: reportbug.debian.org has invalid certificate
> In the changelog for reportbug, it refers to the SMTP server as > reportbug.debian.org. However, when connecting to reportbug.debian.org > port 587, and using STARTTLS, an invalid certificate is presented. > > Version: 3 (0x2) > Serial Number: 3836 (0xefc) > Signature Algorithm: sha1WithRSAEncryption > Issuer: C = NA, ST = NA, L = Ankh Morpork, O = Debian SMTP, OU = > Debian SMTP CA, CN = Debian SMTP CA, emailAddress = hostmaster@puppet.debian. > org > Validity > Not Before: Dec 12 00:00:11 2017 GMT > Not After : Dec 12 00:00:11 2018 GMT > Subject: C = NA, ST = NA, L = Ankh Morpork, O = Debian SMTP, OU = > Debian SMTP CA, CN = buxtehude.debian.org, emailAddress = hostmaster@buxtehu > > Please use a valid certificate for reportbug.debian.org. > > In addition, on port 443, https://reportbug.debian.org is an invalid > certificate. It's only valid for: > * bugs-beach.debian.org > * bugs-buxtehude.debian.org > * bugs.debian.org Hey Don, has something change on the BTS side certificates today? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#902738: netanim: Please package the latest upstream release 3.108-1
Source: netanim Version: 3.100-1 Severity: normal Dear netanim maintainer, Netanim upstream has released new version 3.108, which provides compatibility with Qt5. Upgrading to 3.108 can help remove the depdency to legacy Qt4 and help us move another step ahead towards Qt4's removal. Netanim hasn't receive any uploads since its initial upload in 2012. Please package the latest version and refresh the package. Thanks! -- Regards, Boyuan Yang -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#902737: RFS: sunpinyin/3.0.0~rc1+ds1-1 [RC]
Package: sponsorship-requests Severity: important X-Debbugs-CC: guoli...@debian.org debian-input-met...@lists.debian.org sunwea...@debian.org Dear Mike, Liang, debian-input-method members and mentors, As part of bug fixes and package rebuild in Debian Input Method Team, I prepared a team upload for package "sunpinyin" and I'm currently looking for a sponsor for this package. Besides, I am looking for a DD to help to create a git repository under Debian group on Salsa platform and grant me (hosiet-guest) write access so that I could push and maintain changes there. Levels of rebuild (and bugfix): Level 1: * sunpinyin (libsunpinyin), fcitx (separate RFS #902675) ^ we are here Level 2: * xsunpinyin, fcitx-sunpinyin, ibus-sunpinyin, ucimf-sunpinyin * Package name: sunpinyin Version : 3.0.0~rc1+ds1-1 Upstream Author : Sun Microsystems, Inc and other Sunpinyin Developers * URL : https://github.com/sunpinyin/sunpinyin/ * License : LGPL-2.1 or CDDL Section : libs It builds those binary packages: libsunpinyin-dev - Simplified Chinese Input Method from SUN (development) libsunpinyin3v5 - Simplified Chinese Input Method from SUN (runtime) python-sunpinyin - Simplified Chinese Input Method from SUN (Python binding) sunpinyin-utils - Simplified Chinese Input Method from SUN (utilities) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sunpinyin Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sunpinyin/sunpinyin_3.0.0~rc1+ds1-1.dsc Git packaging repository (proposed, not exist yet): https://salsa.debian.org/debian/sunpinyin Git packaging repository (temporary, will be removed after upload): https://salsa.debian.org/hosiet-guest/sunpinyin Changes since the last upload: sunpinyin (3.0.0~rc1+ds1-1) unstable; urgency=medium . * Team upload. * New upstream snapshot 20180629. + Added support for riscv64 architecture. (Closes: #898019) + Made the build reproducible. (Closes: #860201) + Various fixes. * debian: Apply "wrap-and-sort -abst". * debian/control: + Update Maintainer field with debian-input-method mailing list address. (Closes: #899693) + Bump debhelper compat to v11. + Bump Standards-Version to 4.1.4. + Update homepage information. (Closes: #860202) + Drop unnecessary build dependency quilt. + Drop old -dbg package in favor of automatic -dbgsym package. + Migrate git packaging repo onto Salsa platform. + Update Uploaders list and use @debian.org mail address. * debian/copyright: + Explicitly write wrapper files in Files-Excluded field. + Refresh information. * debian/changelog: + Remove trailing spaces. * debian/patches/backport: Backport all latter commits from trunk. * debian/rules: + Use "dh_missing --fail-missing". + Add full hardening. + Update dh_strip for automatic debug package migration. * debian/watch: Refine and reintroduce watch file. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#902736: ITP: maildir-deduplicate -- find and delete duplicated mails in a Maildir
Package: wnpp Severity: wishlist Owner: Adam Borowski * Package name: maildir-deduplicate Version : 2.1.0 Upstream Author : Kevin Deldycke * URL : https://maildir-deduplicate.readthedocs.io/en/develop/ * License : GPL2+ Programming Lang: Python Description : find and delete duplicated mails in a Maildir This program searches a set of mail folders for duplicated mails. Those are notorious when you receive the same notification via different ways, get mails crossposted to multiple mailing lists, etc. Detection is done by coercing a subset of headers into a canonical form and taking a hash. As protection against false positives, message bodies of candidate duplicates are diffed as well, rejecting those that don't look similar enough. This should avoid most decoration from mailing lists. . Only the Maildir format is supported.
Bug#552164: cleaning up unmaintained files in emacs-goodies-el
control: notforwarded -1 control: retitle -1 drop filladapt.el filladapt.el seems to have no active maintainer outside of emacs-goodies-el and we're getting out of that business, so filladapt should be dropped.
Bug#584305: cleaning up files in emacs-goodies-el without upstream
control: retitle -1 drop tail.el control: notforwarded -1 The comments in tail.el say that "active developement" is in CVS on alioth. I couldn't find any other upstream activity on it, so I propose to drop it from emacs-goodies-el. If there is demand (and an upstream maintainer), we can bring it back as an elpa-package.
Bug#557932: split out matlab-mode
retitle 557932 replace matlab.el with elpa-matlab user debian-emac...@lists.debian.org usertag 557932 elpafy quit There is an active upstream for this one, and a reasonable number of downloads on melpa, so probably we should preserve it. Splitting to it's own package will also reduce the impact of this issue of competing file extensions, since presumably less people will install elpa-matlab and want to edit objective-C.
Bug#902735: ITP: golang-github-dsnet-golib -- Collection of mostly unrelated helper Go packages.
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-dsnet-golib Version : 0.0~git20171103.1ea1667-1 Upstream Author : Joe Tsai * URL : https://github.com/dsnet/golib * License : BSD-3-clause Programming Lang: Go Description : Collection of mostly unrelated helper Go packages This repository stores a collection of mostly unrelated helper libraries. Functionality that the author (Joe Tsai) found common among his various projects are pulled out and placed here: . * bufpipe: implements a buffered pipe * cron: parses and runs cron schedules * hashmerge: merges hash checksums * jsonfmt: implements a JSON formatter * memfile: implements an in-memory emulation of os.File * unitconv: implements string conversion functionality for unit prefixes Reason for packaging: Needed by the upcoming Hugo v0.43
Bug#902734: ITP: golang-github-burntsushi-locker -- simple Go package for conveniently using named read/write locks
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-burntsushi-locker Version : 0.0~git20171006.a6e239e-1 Upstream Author : Andrew Gallant * URL : https://github.com/BurntSushi/locker * License : public-domain Programming Lang: Go Description : simple Go package for conveniently using named read/write locks Package locker is a simple Go package to manage named ReadWrite mutexes. These appear to be especially useful for synchronizing access to session-based information in web applications. . The common use case is to use the package level functions, which use a package level set of locks (safe to use from multiple goroutines simultaneously). However, you may also create a new separate set of locks. . All locks are implemented with read-write mutexes. To use them like a regular mutex, simply ignore the RLock/RUnlock functions. Reason for packaging: Needed by the upcoming Hugo v0.43
Bug#902733: cryptsetup-initramfs: cryptroot script generates corrupt crypttab in verbose mode
Package: cryptsetup-initramfs
Version: 2:2.0.3-4
Severity: important
Dear Maintainer,
The copy_file routine in hook-functions echo's information ('Adding ... ') about
the copy to stdout in verbose mode. This makes its way to the crypttab in the
initramfs, as part of copying keyfiles from get_crypttab_entry function in the
cryptroot script. There is a call to copy_exec which causes similar bad
behavior, when using an explicit keyscript= in /etc/crypttab.
(see also #89516 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898516)
So don't use update-initramfs in verbose mode. Which makes debugging these
recent changes difficult. My workaround is to unset and re-set $verbose around
the calls to copy/exec_file. I'm sure there's a better solution, as this info
needs to make its way to stdout.
Additionally, it's not clear that an empty KEYFILE_PATTERN means no keyfiles
will be copied. Given the transition to remove CRYPTSETUP, I think this needs
addressed.
Also, I think copying the keyfiles and scripts in get_crypttab_entry will lead
to this being performed multiple times, depending on the particular setup and
how many volumes are un/locked at boot. Not an issue to the process, but it
makes reading the log interesting.
Thanks!
-- Package-specific info:
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-2-amd64 (SMP w/8 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)
LSM: AppArmor: enabled
Versions of packages cryptsetup-initramfs depends on:
ii busybox 1:1.27.2-2
ii cryptsetup-run 2:2.0.3-4
ii initramfs-tools [linux-initramfs-tool] 0.130
Versions of packages cryptsetup-initramfs recommends:
ii console-setup 1.184
ii kbd2.0.4-3
cryptsetup-initramfs suggests no packages.
-- Configuration Files:
/etc/cryptsetup-initramfs/conf-hook changed [not included]
-- no debconf information
Bug#902670: tomcat7: version number causes exception in osgi startup
Hi, On 29/06/2018 18:05, Markus Koschany wrote: > Ok, that makes sense. If this is the only MANIFEST file that needs an update, > we can patch it with the next update. I changed the version number in just the one MANIFEST file and the application started without an issue. Is this bug enough to release a new update or should I prepare to patch our other servers manually? EmTeedee
Bug#902316: gnupg failing completely in dgit autopkgtests [and 1 more messages]
Ian Jackson writes ("Re: Bug#902316: gnupg failing completely in dgit
autopkgtests [and 1 more messages]"):
> I attempted to work around this problem by explicitly starting and
> stopping the gpg-agent. This has dramatically reduced the failure
> probability.
...
> I am going to try even more ridiculous workarounds.
Well, I have managed to get it to pass with dgit 5.5+exp7, in
experimental, in the ci's "unstable" queue. My workarounds include:
* A global lock (for the whole test suite, in case anything is going
in parallel) which arranges that only one gnupg is ever run at
once
* When I want to run gnupg with a particular GNUPGHOME I use
gpg-connect-agent to kill any existing agents, repeatedly if need
be until it prints "no gpg-agent running".
* I then start an agent of my own (with a loop to wait for it to be
ready), run gpg, and use gpg-connect-agent to shut it down again.
(again, with a loop).
This involves two nexted wrapper scripts, one to take the lock and one
to mess with gpg-agent. In fact I also have a wrapper script for
gpg-agent so that I can pass --debug-quick-random.
With this I no longer seem to need the wrapper that would try to run
gpg again when it failed. That wasn't a very good workaround anyway.
I intend to merge my new workarounds into unstable soonish.
In the meantime I will leave this bug open because it is still a repro
recipe for a startup race bug: run the dgit 5.5 test suite (with
"whatever is in sid in late June 2018") in ci.debian.net.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#846793: (no subject)
Hi Frédéric, > What's the status? I don't see anything in > https://packages.debian.org/sid/all/fonts-stix/filelist Sorry for the late answer. Looks like it is still in the NEW queue[0], FTP Masters are busy currently... this is not in my hands anymore. :( Regards, Hugo [0] https://ftp-master.debian.org/new/fonts-stix_2.0.0-1.html -- Hugo Lefeuvre (hle)|www.owl.eu.com 4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
Bug#819842: pyliblo: Build not reliable
Version: 0.10.0-3 I wrote: > I have both successful and unsuccessful build logs for this package. > All of them for version 0.10.0-1. > > Status: successful pyliblo_0.10.0-1_amd64-20160225-2103 > Status: successful pyliblo_0.10.0-1_amd64-20160227-1325 > Status: successful pyliblo_0.10.0-1_amd64-20160313-1519 > Status: attempted pyliblo_0.10.0-1_amd64-20160402-0031 > Status: attempted pyliblo_0.10.0-1_amd64-20160402-1951 > Status: attempted pyliblo_0.10.0-1_amd64-20160402-2012 > Status: attempted pyliblo_0.10.0-1_amd64-20160402-2024 > Status: attempted pyliblo_0.10.0-1_amd64-20160521-1427 > Status: successful pyliblo_0.10.0-1_amd64-20160621-2143 However, I can't reproduce this anymore in stretch (version 0.10.0-3), after trying 100 times, so I hereby declare this issue as fixed, whatever the original problem could be. Thanks.
Bug#902732: ITP: golang-github-bep-go-tocss -- simple-to-use LibSass Go API
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bep-go-tocss Version : 0.0~git20180625.471c87b-1 Upstream Author : Bjørn Erik Pedersen * URL : https://github.com/bep/go-tocss * License : Expat Programming Lang: Go Description : simple-to-use LibSass Go API This is currently a, hopefully, simple to use LibSass Go API. It uses the C bindings in https://github.com/wellington/go-libsass/libs to do the heavy lifting. . The primary motivation for this project is to add SCSS support to Hugo (https://gohugo.io/). It is has some generic tocss package names hoping that there will be a solid native Go implementation that can replace LibSass in the near future. Reason for packaging: Need for the upcoming Hugo v0.43
Bug#902731: RFS: pidgin-plugin-window-merge/0.3-git20180429-1 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pidgin-plugin-window-merge" * Package name : pidgin-plugin-window-merge Version : 0.3-git20180429-1 * URL : https://github.com/dm0-/window_merge * License : GPL-3 Section : net It builds those binary packages: pidgin-plugin-window-merge - Pidgin plugin for merging windows To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pidgin-plugin-window-merge Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pidgin-plugin-window-merge/pidgin-plugin-window-merge_0.3-git20180429-1.dsc More information about hello can be obtained from https://github.com/dm0-/window_merge Regards, Mikhail Novosyolov
Bug#902730: ITP: sharness -- Sharness is a portable shell library to write, run, and analyze automated tests for Unix programs. Since all tests output TAP, the Test Anything Protocol, they can be run
Package: wnpp Severity: wishlist Owner: Lars Kruse * Package name: sharness Version : 1.0.0 Upstream Author : Christian Couder * URL : https://github.com/chriscool/sharness * License : GPL2+ Programming Lang: Shell Description : Sharness is a portable shell library to write, run, and analyze automated tests for Unix programs. Since all tests output TAP, the Test Anything Protocol, they can be run with any TAP harness (e.g. "prove"). Each test is written as a shell script, for example: test_expect_success "Success is reported like this" " echo hello world | grep hello " test_expect_failure "We expect this to fail" " test 1 = 2 " Sharness is used by a few Debian packages as part of their DEP8 tests (via autopkgtest): * gearmand * git-reintegrate * git-remote-bzr * git-remote-hg * hiera-eyaml * jemalloc * mod-gearman * munin * pass-otp * puppet-lint * puppet-module-puppetlabs-concat * puppet-module-puppetlabs-ntp * puppet-module-puppetlabs-stdlib (the list was assembled via https://codesearch.debian.net) Currently these packages embed a copy of the sharness.sh file below debian/tests. I will file bug reports against these packages (including patches) after the sharness package is available, in order to help them getting rid of their embedded code copies. I am part of the munin packaging team, thus the munin package would benefit immediately from this package. I plan to maintain the sharness package for the foreseeable future. I will need a sponsor for uploading this package. Cheers, Lars
Bug#902729: Missing Conflicts with libmariadb2
Package: libmariadb3 Version: 1:3.0.3-2 Severity: serious Hi, Trying to install libmariadb3 on a system which already has libmariadb2 installed fails with: > Unpacking libmariadb3:amd64 (1:3.0.3-2) ... > dpkg: error processing archive > /var/cache/apt/archives/libmariadb3_1%3a3.0.3-2_amd64.deb (--unpack): > trying to overwrite '/usr/lib/x86_64-linux-gnu/mariadb/plugin/dialog.so', > which is also in package libmariadb2:amd64 2.3.3-1 The plugins are in an unversioned directory, present in both packages, and so the two packages cannot be co-installed. Please add suitable dependency relationships to the new libmariadb3 package to allow upgrades to work. Regards, James
Bug#881205: NMU for backintime 1.1.24
Hi, On Wed, Jun 13, 2018 at 11:19:15PM +0200, Fabian Wolff wrote: > since there has not been any progress on this for a while now, I have > decided to prepare a non-maintainer upload myself, including the > latest upstream release, 1.1.24, as well as some minor maintenance > work. > > Jonathan, could you have a look at this? Of course I won't upload a > NMU without your consent. Also, I would need a sponsor. I have > uploaded my package to Mentors: I really appreciate your efforts and I'm sorry not to have had time to respond before now. > I have also forked your repository and pushed my changes: > > https://salsa.debian.org/wolff-guest/pkg-backintime > > If you're satisfied with my changes, I can add a debian/1.1.24-0.1 tag > and open a merge request, or you could give me write access to your > repository so that I can push the changes myself. Would you like to co-maintain? If so, please add yourself to uploaders and prepare a maintainer upload (rather than NMU). I added you to the repository members in anticipation. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
Bug#902728: CVE-2018-12600
Package: imagemagick Version: 8:6.9.9.39+dfsg-1 Severity: important Tags: security https://github.com/ImageMagick/ImageMagick/issues/1178 https://github.com/ImageMagick/ImageMagick/commit/921f208c2ea3cc45847f380257f270ff424adfff ImageMagick6: https://github.com/ImageMagick/ImageMagick6/commit/ae71c12bbaa34d942e036824ff389c22b7dacade Cheers, Moritz
Bug#902727: CVE-2018-12599
Package: imagemagick Severity: important Tags: security https://github.com/ImageMagick/ImageMagick/issues/1177 https://github.com/ImageMagick/ImageMagick/commit/ae04fa4be910255e5d363edebd77adeee99a525d ImageMagick6: https://github.com/ImageMagick/ImageMagick6/commit/081f518eb9cb38e683b8b9ccb9e4ab5c52f82c2f Cheers, Moritz
Bug#902395: document chromium --use-gl=osmesa
control: reassign -1 wnpp control: severity -1 wishlist control: retitle -1 RFP: chromium-doc -- documentation of command line switches On Mon, Jun 25, 2018 at 6:53 PM, Dan Jacobson wrote: > User is told to use > chromium --use-gl=osmesa > > User cannot find it on man page. [...] > Please document such undocumented items, > one should not need a network connection to look them up. This information is rarely if ever kept up to date in the chromium source package. The best information I've seen about this is [0], which has been kept fairly up to date for years now. The table there could be added as a new chromium-doc source package. Best wishes, Mike [0] https://peter.sh/experiments/chromium-command-line-switches
Bug#902726: 2018/06/25 security release
Package: gitlab Severity: grave Tags: security https://about.gitlab.com/2018/06/25/security-release-gitlab-11-dot-0-dot-1-released/ Cheers, Moritz
Bug#902725: CVE-2018-12617
Source: qemu Severity: important Tags: security This was assigned CVE-2018-12617: https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg03385.html https://gist.github.com/fakhrizulkifli/c7740d28efa07dafee66d4da5d857ef6 Cheers, Moritz
Bug#902723: CVE-2018-1000528
Source: gosa Severity: grave Tags: security This was assigned CVE-2018-1000528: https://github.com/gosa-project/gosa-core/commit/56070d6289d47ba3f5918885954dcceb75606001 https://github.com/gosa-project/gosa-core/issues/14 Cheers, Moritz
Bug#902724: CVE-2018-1000517
Package: busybox Version: 1:1.27.2-2 Severity: important Tags: security This was assigned CVE-2018-1000517: https://git.busybox.net/busybox/commit/?id=8e2174e9bd836e53c8b9c6e00d1bc6e2a718686e Cheers, Moritz
Bug#900856: enlightenment: Sound fails to work after upgrade
On Fri, Jun 29, 2018 at 3:26 AM Mike Brodbelt wrote: > On 29/06/18 04:26, Felipe Sateler wrote: > > > Thanks. However, it has some flaws that need to be reworked for this to > > work at all: > > > > 1. We can't rely on gcc being installed > > Would "dpkg-architecture -qDEB_BUILD_MULTIARCH" be a reasonable > replacement? > Unfortunately not. It is part of dpkg-dev, which is also not installed by default (and requiring it via pulseaudio doesn't make much sense). I think using /proc/1/comm or /proc/1/exe are better alternatives. > > 2. It doesn't check /proc is actually mounted > > 3. dpkg status check is racy: sysvinit might be upgraded at the same > > time, and thus not be "installed" > > 4. dpkg status check is for the wrong package: sysvinit no longer exists > > (I think you want sysvinit-core). > > 5. The postinst should be the one for libpulse0, not pulseaudio > > Will have a poke at these when I get a minute. > > > You missed the conffile mark because it is shipped in libpulse0 :) > > That would explain that :-) > > > I don't have objections in principle, but I want a good and relatively > > not-risky implementation first. > > Ack. > > > BTW, it might be easier to do the review/fixup dance in a merge request > > on salsa: https://salsa.debian.org/pulseaudio-team/pulseaudio > > OK. Haven't played with that before, but will have a look. > It's not strictly required, but I would prefer that, thanks. -- Saludos, Felipe Sateler
Bug#880675: (no subject)
Fixed in glibc, but not in CLDR yet: https://sourceware.org/bugzilla/show_bug.cgi?id=22996
Bug#902721: CVE-2018-1000539
Package: ruby-json-jwt Severity: grave Tags: security This was assigned CVE-2018-1000539: https://github.com/nov/json-jwt/pull/62 https://github.com/nov/json-jwt/commit/3393f394f271c87bd42ec23c300727b4437d1638 Cheers, Moritz
Bug#902722: CVE-2018-1000532
Package: beep Severity: important Tags: security Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000532 Cheers, Moritz
Bug#902719: CVE-2018-1000546
Package: triplea Severity: important Tags: security This was assigned CVE-2018-1000546: https://0dd.zone/2018/05/31/TripleA-XXE/ https://github.com/triplea-game/triplea/issues/3442 Cheers, Moritz
Bug#902720: CVE-2018-1000544
Package: ruby-zip Severity: grave Tags: security This was assigned CVE-2018-1000544: https://github.com/rubyzip/rubyzip/issues/369 Cheers, Moritz
Bug#902718: CVE-2018-12900
Source: tiff Severity: important Tags: security Please see http://bugzilla.maptools.org/show_bug.cgi?id=2798 Cheers, Moritz
Bug#902717: [macchanger] make default macchanger behavior configurable
Package: macchanger Version: 1.7.0-5.3+b1 Severity: wishlist --- Please enter the report below this line. --- While I can easily edit /etc/macchanger/ifupdown.sh to change the -e flag to something else, I'm sure this is not the preferred method. It would be nice to have an OPTIONS variable in /etc/default/macchanger which seems to be the preferred locale for configuration changes. I'm happy to create a patch if it would be helpful. I did notice that the git repository for macchanger no longer works and I am not able to find the new one. --- System information. --- Architecture: Kernel: Linux 4.9.0-6-amd64 Debian Release: 9.4 500 stable-updates ftp.us.debian.org 500 stable security.debian.org 500 stable repository.spotify.com 500 stable ftp.us.debian.org 100 stretch-backports ftp.us.debian.org 100 stable www.deb-multimedia.org --- Package information. --- Depends (Version) | Installed =-+-= libc6(>= 2.4) | debconf (>= 0.5) | OR debconf-2.0 | dpkg (>= 1.15.4) | OR install-info | Package's Recommends field is empty. Package's Suggests field is empty.
Bug#902716: reportbug.debian.org has invalid certificate
Package: reportbug Version: 7.1.10 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, In the changelog for reportbug, it refers to the SMTP server as reportbug.debian.org. However, when connecting to reportbug.debian.org port 587, and using STARTTLS, an invalid certificate is presented. Version: 3 (0x2) Serial Number: 3836 (0xefc) Signature Algorithm: sha1WithRSAEncryption Issuer: C = NA, ST = NA, L = Ankh Morpork, O = Debian SMTP, OU = Debian SMTP CA, CN = Debian SMTP CA, emailAddress = hostmaster@puppet.debian. org Validity Not Before: Dec 12 00:00:11 2017 GMT Not After : Dec 12 00:00:11 2018 GMT Subject: C = NA, ST = NA, L = Ankh Morpork, O = Debian SMTP, OU = Debian SMTP CA, CN = buxtehude.debian.org, emailAddress = hostmaster@buxtehu Please use a valid certificate for reportbug.debian.org. In addition, on port 443, https://reportbug.debian.org is an invalid certificate. It's only valid for: * bugs-beach.debian.org * bugs-buxtehude.debian.org * bugs.debian.org - -- Package-specific info: ** Environment settings: EDITOR="vim" INTERFACE="text" ** /home/bminton/.reportbugrc: reportbug_version "2.10.1" mode standard ui text sign gpg keyid 0424DC19B678A1A9 email "br...@minton.name" realname "Brian Minton" - -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.1+ (SMP w/16 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 reportbug depends on: ii apt1.6.2 ii python33.6.6-1 ii python3-reportbug 7.1.10 ii sensible-utils 0.0.12 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf-utils 1.5.67 ii debsums2.2.2 ii dlocate1.07+nmu1 ii emacs24-bin-common 24.5+1-11+deb9u1 ii emacs25-bin-common 25.2+1-6+b2 ii exim4 4.91-5 ii exim4-daemon-heavy [mail-transport-agent] 4.91-5 ii file 1:5.33-3 ii gir1.2-gtk-3.0 3.22.30-2 ii gir1.2-vte-2.910.52.2-1 ii gnupg 2.2.8-3 ii pgpgpg [pgp] 0.13-9.1+b1 ii python3-gi 3.28.2-1 ii python3-gi-cairo 3.28.2-1 pn python3-gtkspellcheck pn python3-urwid ii xdg-utils 1.1.3-1 Versions of packages python3-reportbug depends on: ii apt1.6.2 ii file 1:5.33-3 ii python33.6.6-1 ii python3-apt1.6.1 ii python3-debian 0.1.32 ii python3-debianbts 2.7.2 ii python3-requests 2.18.4-2 python3-reportbug suggests no packages. - -- Configuration Files: /etc/reportbug.conf changed: submit query-bts check-available cc config-files compress sign gpg verify mode expert - -- no debconf information -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQT5xLt2Dng/DewQpoprjrOgZc+6qQUCWzabNAAKCRBrjrOgZc+6 qThBAP4mA8+u/8wgKZWWNF9t4w0BYMDTblbrfHbSbZbtAwM5WgD9GpjVsM9m0Qub axl7+2QaMX3oCPQ4cqRdXT5Lu3NpT/2IdQQBFggAHRYhBO7QFYAT3C5tbgAepDe5 UHrP8gFuBQJbNps4AAoJEDe5UHrP8gFusF4A/31aJVgCRBBZtDIRJqWii9jLJkRe rqJDkL4bZ6Sd4S+IAQDcLik2abMLHRUgx4wodBNEKeUT75sgwefRhUivNB9EDw== =LV9j -END PGP SIGNATURE-
Bug#902715: python3-psycopg2 fails to install with Python 3.7
Package: python3-psycopg2 Version: 2.7.5-1 Severity: serious Setting up python3-psycopg2 (2.7.5-1+b1) ... File "/usr/lib/python3/dist-packages/psycopg2/tests/test_async_keyword.py", line 43 self.conn = self.connect(async=True) ^ SyntaxError: invalid syntax dpkg: error processing package python3-psycopg2 (--configure): installed python3-psycopg2 package post-installation script subprocess returned error exit status 1
Bug#902714: minieigen: FTBFS with Boost >= 1.65
Source: minieigen
Version: 0.50.3+dfsg1-5
Severity: wishlist
Tags: ftbfs patch
Hi Maintainer
The attached patch from upstream allows minieigen to build with recent
versions of Boost.
Severity is wishlist since Debian are stuck with Boost 1.62.
Regards
Graham
Description: Make minieigen more compliant with user defined data types
Remove std::abs from code, use Eigen::NumTraits instead of
boost::is_complex to check if data type is complex
Origin: upstream, https://github.com/eudoxos/minieigen/commit/7bd0a2e82477a2172b428a3801d9cae0800f
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/minieigen/+bug/1765330
Author: Jeb Collins
Last-Update: 2016-02-17
--- a/src/visitors.hpp
+++ b/src/visitors.hpp
@@ -104,8 +104,8 @@
template static MatrixBaseT __div__scalar(const MatrixBaseT& a, const Scalar2& scalar){ return a/scalar; }
template static MatrixBaseT __idiv__scalar(MatrixBaseT& a, const Scalar2& scalar){ a/=scalar; return a; }
- template static void visit_reductions_noncomplex(PyClass& cl, typename boost::enable_if >::type* dummy = 0){ /* do nothing*/ }
- template static void visit_reductions_noncomplex(PyClass& cl, typename boost::disable_if >::type* dummy = 0){
+ template static void visit_reductions_noncomplex(PyClass& cl, typename boost::enable_if_c::IsComplex >::type* dummy = 0){ /* do nothing*/ }
+ template static void visit_reductions_noncomplex(PyClass& cl, typename boost::disable_if_c::IsComplex >::type* dummy = 0){
// must be wrapped since there are overloads:
// maxCoeff(), maxCoeff(IndexType*), maxCoeff(IndexType*,IndexType*)
cl
@@ -118,8 +118,8 @@
// we want to keep -0 (rather than replacing it by 0), but that does not work for complex numbers
// hence two versions
- template static bool prune_element(const Scalar& num, RealScalar absTol, typename boost::disable_if >::type* dummy=0){ return std::abs(num)<=absTol || num!=-0; }
- template static bool prune_element(const Scalar& num, RealScalar absTol, typename boost::enable_if >::type* dummy=0){ return std::abs(num)<=absTol; }
+ template static bool prune_element(const Scalar& num, RealScalar absTol, typename boost::disable_if_c::IsComplex >::type* dummy=0){using namespace std; return abs(num)<=absTol || num!=-0; }
+ template static bool prune_element(const Scalar& num, RealScalar absTol, typename boost::enable_if_c::IsComplex >::type* dummy=0){using namespace std; return abs(num)<=absTol; }
static MatrixBaseT pruned(const MatrixBaseT& a, double absTol=1e-6){ // typename MatrixBaseT::Scalar absTol=1e-6){
MatrixBaseT ret(MatrixBaseT::Zero(a.rows(),a.cols()));
@@ -358,9 +358,9 @@
visit_if_decompositions_meaningful(cl);
}
// for complex numbers, do nothing
- template static void visit_if_decompositions_meaningful(PyClass& cl, typename boost::enable_if >::type* dummy = 0){ /* do nothing */ }
+ template static void visit_if_decompositions_meaningful(PyClass& cl, typename boost::enable_if_c::IsComplex >::type* dummy = 0){ /* do nothing */ }
// for non-complex numbers, define decompositions
- template static void visit_if_decompositions_meaningful(PyClass& cl, typename boost::disable_if >::type* dummy = 0){
+ template static void visit_if_decompositions_meaningful(PyClass& cl, typename boost::disable_if_c::IsComplex >::type* dummy = 0){
cl
.def("jacobiSVD",::jacobiSVD,"Compute SVD decomposition of square matrix, retuns (U,S,V) such that self=U*S*V.transpose()")
.def("svd",::jacobiSVD,"Alias for :obj:`jacobiSVD`.")
Bug#902713: astropy-healpix: flaky autopkgtest: tolerance too small?
Source: astropy-healpix Version: 0.2-4 Severity: important User: debian...@lists.debian.org Usertags: flaky While inspecting regressions in autopkgtest results¹, I noticed that your package failed multiple times²³ without apparent changes and passed later again, all with a very similar if not equal error (copied below). The last one was involved in delaying the migration of pytest. Could you please investigate and make your autopkgtest more robust? Please contact me if you need help and you think I can provide that (I am not subscribed to this bug). Recent discussion of gating migration by autopkgtests on debian-devel⁴ noted that if this is going to work, and in particular if we are going to *block* migration when it causes autopkgtest regressions rather than merely delaying it, intermittent autopkgtest failures are likely to have to be considered RC due to their impact on the tested package's dependencies; for now I've filed it as important. Paul ¹ https://ci.debian.net/packages/a/astropy-healpix ² https://ci.debian.net/data/autopkgtest/unstable/amd64/a/astropy-healpix/515744/log.gz ³ https://ci.debian.net/data/autopkgtest/testing/amd64/a/astropy-healpix/518587/log.gz ⁴ https://lists.debian.org/debian-devel/2018/05/msg00061.html https://ci.debian.net/data/autopkgtest/testing/amd64/a/astropy-healpix/518587/log.gz autopkgtest [15:11:14]: test python-astropy-healpix: [--- = test session starts == platform linux2 -- Python 2.7.15, pytest-3.6.2, py-1.5.3, pluggy-0.6.0 Running tests with astropy_healpix version 0.2. Running tests in /usr/lib/python2.7/dist-packages/astropy_healpix. Date: 2018-06-27T15:11:14 Platform: Linux-4.9.0-4-amd64-x86_64-with-debian-buster-sid Executable: /usr/bin/python Full Python Version: 2.7.15 (default, May 1 2018, 05:55:50) [GCC 7.3.0] encodings: sys: ascii, locale: UTF-8, filesystem: UTF-8, unicode bits: 20 byteorder: little float info: dig: 15, mant_dig: 15 Numpy: 1.14.4 Scipy: not available Matplotlib: 2.2.2 Astropy: 2.0.7 healpy: 1.11.0 Cython: not available Using Astropy options: remote_data: none. rootdir: /usr/lib/python2.7/dist-packages/astropy_healpix, inifile: plugins: hypothesis-3.44.1 collected 283 items ../../../../usr/lib/python2.7/dist-packages/astropy_healpix/tests/test_bench.py . [ 0%] [ 0%] ../../../../usr/lib/python2.7/dist-packages/astropy_healpix/tests/test_core.py . [ 0%] ... [ 11%] ../../../../usr/lib/python2.7/dist-packages/astropy_healpix/tests/test_core_cython.py . [ 12%] [ 37%] [ 62%] . [ 78%] ../../../../usr/lib/python2.7/dist-packages/astropy_healpix/tests/test_healpy.py . [ 79%] .F. [ 94%] ../../../../usr/lib/python2.7/dist-packages/astropy_healpix/tests/test_high_level.py . [ 94%] ... [100%] === FAILURES === _ test_interp_weights __ @given(nside_pow=integers(0, 28), nest=booleans(), lonlat=booleans(), > lon=floats(0, 360, allow_nan=False, allow_infinity=False).filter(lambda lon: abs(lon) > 1e-5), lat=floats(-90, 90, allow_nan=False, allow_infinity=False).filter( lambda lat: abs(lat) < 89.99 and abs(lat) > 1e-5)) /usr/lib/python2.7/dist-packages/astropy_healpix/tests/test_healpy.py:182: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /usr/lib/python2.7/dist-packages/hypothesis/core.py:579: in execute result = self.test_runner(data, run) /usr/lib/python2.7/dist-packages/hypothesis/executors.py:58: in default_new_style_executor return function(data) /usr/lib/python2.7/dist-packages/hypothesis/core.py:571: in run return test(*args, **kwargs) /usr/lib/python2.7/dist-packages/astropy_healpix/tests/test_healpy.py:182: in test_interp_weights lon=floats(0, 360, allow_nan=False, allow_infinity=False).filter(lambda lon: abs(lon) > 1e-5), /usr/lib/python2.7/dist-packages/hypothesis/core.py:518: in test result = self.test(*args, **kwargs) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ nside_pow = 27, lon = 0.00023989560322235096, lat = 89.9636937073379 nest = False, lonlat = False @given(nside_pow=integers(0, 28), nest=booleans(), lonlat=booleans(), lon=floats(0, 360, allow_nan=False, allow_infinity=False).filter(lambda lon: abs(lon) > 1e-5), lat=floats(-90, 90, allow_nan=False, allow_infinity=False).filter( lambda lat: abs(lat) < 89.99 and abs(lat) > 1e-5)) @settings(max_examples=500, derandomize=True) @example(nside_pow=27, lon=1.28043134e-05, lat=-41.81031451395941, nest=False, lonlat=False)
Bug#902626: Stretch kvm accelerated qemu-system-i386 on i386 archirecture enters infinite loop at startup
Package: qemu-system-x86 Version: 1:2.8+dfsg-6+deb9u4 Followup-For: Bug #902626 Michael Tokarev writes: > 28.06.2018 21:19, Bernard wrote: >> Package: qemu-system-x86 >> Version: 1:2.8+dfsg-6+deb9u4 >> Severity: important >> >> I am on i386 architecture with a CodeDuo processor. > [] >> I tried the 4.16 kernel from stretch-backport, and the behaviour was >> the same: ok without acceleration, black screen with -enable-kvm. >> >> Workaround: my CPU is actually amd64 capable; I have a partition where >> amd64 Strech is installed for tests, and surprise there the VMs are >> running fine and are kvm accelerated with qemu-system-i386. So I ended >> up crossgrading the kernel to amd64 (explains the "amd64" in the >> system information section below) on my main brand new Stretch i386 >> system, and now the VMs are working ok and are accelerated. >> >> So the problem seems kvm.ko and kvm_intel.ko related, but to me it >> seemed more logical to raise the bug through the package triggering >> the bug. > > No, the problem is most likely due to qemu, not kvm modules, but that's > not really interesting. > > The fact is that we aren't testing any 32bit host mode at all. In the past > it often failed to _compile_, now there's an automatic compile farm that > constantly tries to compile things and alarms when it doesn't work. But > no one tries to run the binaries on 32bit host. I used to do that in the > past but that time was long gone. > > I can say even more: upstream is seriously thinking about dropping 32bit > host support completely, not only on x86 but on other architectures too, > because supporting 32bit mode, especially to run 64bit guests, is not > easy at all. So don't be surprized if one day it wont work at all, > by definition (not by incident like now) You mean the kvm acceleration part is not easy with 64bit guests on 32bits hosts? I expect the pure emulation part of qemu to be still maintained, it's its core idea and useful for testing new architectures/configurations. > I for one don't have any 32bit system here to test it on. My main system > is 64bits and it runs all the software I use every day, in order to > install 32bit system I'll have to move partitions around to find an > empty space and reboot to another system. I don't have other computers > over here. Maybe it will work in a chroot, I dunno, but there, it is > always a pain to work with anyway. > > But even if I'll able to see what you see, I've very little confidence > in whenever it will be fixable. These bugs are definitely of a very low > priority for upstream, and especially not interesting for old versions > (current qemu version is 2.12, next is 3.0). > > Also, think how many people are running stretch now, but you're the first > to notice this issue. That indeed was a shock, so far I have always found another poor soul experiencing the same bug as myself. But looking at the current i386 rank vs. the amd64 one on the Popularity Contest web page, I realize now I should not have been surprised. > > So, in short, please don't hold your breath waiting till this will be fixed. > Instead, try to switch to 64bit, -- that will be the real fix. > > Thanks, > > /mjt So I understand that you want to move the bug in the "won't fix" category. Fair enough. Sincerely. -- Bernard
Bug#902712: xpra: Failed to add PIDs to scope's control group
Package: xpra Version: 2.3.1+dfsg-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, when trying to start xpra, I'm getting a systemd related permission denied error: $ xpra start using systemd-run to wrap 'start' server command 'systemd-run' '--description' 'xpra-start' '--scope' '--user' '/usr/bin/xpra' 'start' '--systemd-run=no' Job for run-r858c054fccc842979d1acd07880eda75.scope failed. See "systemctl status run-r858c054fccc842979d1acd07880eda75.scope" and "journalctl -xe" for details. $ systemctl status run-r858c054fccc842979d1acd07880eda75.scope --user ● run-r858c054fccc842979d1acd07880eda75.scope - xpra-start Loaded: loaded (/run/user/1000/systemd/transient/run-r858c054fccc842979d1acd07880eda75.scope; transient) Transient: yes Active: failed (Result: resources) Jun 29 08:37:32 bminton.is-a-geek.net systemd[12680]: run-r858c054fccc842979d1acd07880eda75.scope: Failed to add PIDs to scope's control group: Permission denied Jun 29 08:37:32 bminton.is-a-geek.net systemd[12680]: run-r858c054fccc842979d1acd07880eda75.scope: Failed with result 'resources'. Jun 29 08:37:32 bminton.is-a-geek.net systemd[12680]: Failed to start xpra-start. - -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.1+ (SMP w/16 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 xpra depends on: ii adduser 3.117 ii libavcodec57 10:3.4.2-dmo3 ii libavformat57 10:3.4.2-dmo3 ii libavutil55 10:3.4.2-dmo3 ii libc6 2.27-3 ii libglib2.0-0 2.56.1-2 ii libgtk2.0-0 2.24.32-2 ii libswscale4 10:3.4.2-dmo3 ii libvpx5 1.7.0-3 ii libwebp6 0.6.1-2 ii libx11-6 2:1.6.5-1 ii libx264-152 3:0.152.2851+gitba24899-dmo2 ii libx265-160 1:2.8-dmo2 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxi62:1.7.9-1 ii libxkbfile1 1:1.0.9-2 ii libxrandr22:1.5.1-1 ii libxtst6 2:1.2.3-1 ii python2.7.15-3 ii python-gi-cairo 3.28.2-1 ii python-gtk2 2.24.0-5.1+b1 ii python-rencode1.0.5-1+b1 ii x11-xserver-utils 7.7+8 ii xserver-xorg-input-void 1:1.4.1-1+b2 ii xserver-xorg-video-dummy 1:0.3.8-1+b1 Versions of packages xpra recommends: ii keyboard-configuration 1.184 ii ksshaskpass [ssh-askpass]4:5.13.1-1 ii openssh-client 1:7.7p1-2 ii python-dbus 1.2.8-2 ii python-gtkglext1 1.1.0-9.1 ii python-imaging 4.3.0-2 ii python-lz4 0.10.1+dfsg1-0.2 ii python-lzo 1.08-1 ii python-pil 5.1.0-1 ii ssh-askpass 1:1.2.4.1-10 ii ssh-askpass-gnome [ssh-askpass] 1:7.7p1-2 Versions of packages xpra suggests: ii cups-common 2.2.8-3 ii cups-filters1.20.3-1+b1 ii gstreamer1.0-plugins-bad1:1.14.1-dmo2 ii gstreamer1.0-plugins-base 1.14.1-dmo1 ii gstreamer1.0-plugins-good 1.14.1-dmo1 ii gstreamer1.0-plugins-ugly 1:1.14.1-dmo1 ii openssh-server 1:7.7p1-2 ii printer-driver-cups-pdf [cups-pdf] 3.0.1-5 ii pulseaudio 12.0-1 ii pulseaudio-utils12.0-1 ii python-avahi0.7-4 ii python-cups 1.9.73-2 pn python-gst-1.0 ii python-netifaces0.10.4-1 pn python-opencv ii python-pyopencl 2018.1.1-2 ii python-yaml 3.12-1+b1 pn v4l2loopback-dkms - -- no debconf information -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQT5xLt2Dng/DewQpoprjrOgZc+6qQUCWzaT4gAKCRBrjrOgZc+6 qaSHAP0d6j3Wnnc8kcyb9rur/G1bZcC3BHKLrBJfUYMIz8r0bAD/Zj+gG9KKNbiS UstR8+/a0lRAquStkPY5V8RaltFIkVuIdQQBFggAHRYhBO7QFYAT3C5tbgAepDe5 UHrP8gFuBQJbNpPoAAoJEDe5UHrP8gFukEcBAKqXrtDoq/jbk22pa1gf9qcBQWFe aBP9O39958u1SL+6AP936BvzDRoHpCQyrXhq4s24WKGyFFXsCS0HVUKJ5Jl5AQ== =Hk3B -END PGP SIGNATURE-
Bug#902709: diffoscope: test failures everywhere
retitle 902709 diffoscope: FTBFS: /usr/lib/python3.6/tempfile.py:509: FileNotFoundError thanks Hi Mattia, > So, I believe there is a bug here that needs to be fixed. I can't reproduce this locally. > Incidentally, Chris: any reason you did binary uploads instead of source > only uploads? No, I don't have source-only uploads enabled by default due to security work. I don't think that is relevant here, however. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#902629: missing required versioned dependency on python-lxml may cause FTBFS
On Fri, Jun 29, 2018 at 06:08:52AM +0900, Norbert Preining wrote: > Hi Nicholas, > > > I've already fixed this in g...@salsa.debian.org:debian/html5-parser.git > > > > If it's possible to fix the FTBR on i386 in sid, then that fix seems > > like it ought to included into the proposed 0.4.4-2 upload. Sadly I > > don't know why it's occurring so can't fix it. > > I am not sure what is the problem on i386, does the current 0.4.4-2 not > build there? > > Should I upload 0.4.4-2? I spoke with mapreri on #debian-python. A very terse summary is that if it is uploaded now it will continue to FTBFS on arm64, because that where the py3.7 transition is in-progress. A reasonable compromise seems like it might be something like: do a source-only upload to the delayed queue, with at least seven days delay. Cheers, Nicholas signature.asc Description: PGP signature
Bug#862963: Update for sql-ledger ITA
On Mon, Jan 8, 2018 at 3:51 PM Robert J. Clay wrote: > > there is still an open issue that is a 'serious' bug [2] regarding: > > "Can't locate bin/mozilla/login.pl in @INC". That I have added a patch to mitigate the issue. And it does seems to work, although I'm only able to get as far as the 'Create Dataset' page because a template selection is required and that directory is missing any contents in the distribution archive. -- Robert J. Clay rjc...@gmail.com
Bug#862953: calendar.js file for SQL Ledger
Maik,
On Mon, Jan 8, 2018 at 2:52 PM Robert J. Clay wrote:
> > things like the missing calendar.js used to happen in the past with SQL
> > Ledger upstream.
>
>I appreciate the information you noted but in case it wasn't clear;
> the issue is that the Lintian error is coming up at all, not that the
> source for calendar.js is actually missing. And I think it's actually
> coming up because at least one line is too long (">512") for it to be
> able to fully check it. I have an idea how to mitigate that so I'll
> know more when I have a chance to investigate it further.
I was able to mitigate that issue with a patch in the new
packaging. Will just have to see if it has causes any issues in
operation.
--
Robert J. Clay
rjc...@gmail.com
j...@rocasa.us
Bug#902711: lilo.conf.5: Use an one-font-change macro for a single argument and correct some of them
Package: lilo Version: 1:24.2-3 Severity: minor Tags: patch Dear Maintainer, Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z lilo.conf.5 [ "test-groff" is a developmental version of "groff" ] 144 (macro BI): only 1 argument, but more are expected 161 (macro BI): only 1 argument, but more are expected 209 (macro BI): only 1 argument, but more are expected 238 (macro BI): only 1 argument, but more are expected 302 (macro BI): only 1 argument, but more are expected 340 (macro BI): only 1 argument, but more are expected 345 (macro BI): only 1 argument, but more are expected 367 (macro BI): only 1 argument, but more are expected 374 (macro BI): only 1 argument, but more are expected 392 (macro BI): only 1 argument, but more are expected 406 (macro BI): only 1 argument, but more are expected 418 (macro BI): only 1 argument, but more are expected 429 (macro BI): only 1 argument, but more are expected 434 (macro BI): only 1 argument, but more are expected 500 (macro BI): only 1 argument, but more are expected 516 (macro BI): only 1 argument, but more are expected 524 (macro BI): only 1 argument, but more are expected 527 (macro BI): only 1 argument, but more are expected 536 (macro BI): only 1 argument, but more are expected 571 (macro BI): only 1 argument, but more are expected 609 (macro BI): only 1 argument, but more are expected 615 (macro BI): only 1 argument, but more are expected 635 (macro BI): only 1 argument, but more are expected 652 (macro BI): only 1 argument, but more are expected 768 (macro BI): only 1 argument, but more are expected 774 (macro BI): only 1 argument, but more are expected 871 (macro BI): only 1 argument, but more are expected 927 (macro BI): only 1 argument, but more are expected 962 (macro BI): only 1 argument, but more are expected 978 (macro BI): only 1 argument, but more are expected 990 (macro BI): only 1 argument, but more are expected 1002 (macro BI): only 1 argument, but more are expected 1008 (macro IR): only 1 argument, but more are expected 1011 (macro BI): only 1 argument, but more are expected 1014 (macro BI): only 1 argument, but more are expected 1035 (macro BI): only 1 argument, but more are expected 1039 (macro BI): only 1 argument, but more are expected 1049 (macro BI): only 1 argument, but more are expected 1054 (macro BI): only 1 argument, but more are expected 1059 (macro BI): only 1 argument, but more are expected The patch is in the attachment. ### -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.110-1 (SMP w/2 CPU cores) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages lilo depends on: ii debconf [debconf-2.0] 1.5.67 ii dpkg 1.19.0.5+b1 ii libc6 2.27-3 ii libdevmapper1.02.1 2:1.02.145-4.1 ii perl 5.26.2-6 lilo recommends no packages. Versions of packages lilo suggests: ii e2fsprogs 1.44.2-1 -- debconf information excluded -- Bjarni I. Gislason --- lilo.conf.5 2018-06-29 17:23:16.0 + +++ lilo.conf.5.new 2018-06-29 17:31:53.0 + @@ -141,7 +141,7 @@ One way is the use of header information From a text file with all the information about 'bmp-colors', 'bmp-table' and 'bmp-timer' options together with the 'bitmap' option are stored in the special LILO header of the bitmap image file by the -.BI "lilo -E" +.B lilo \-E command. Another way works without these special header information: All the information about 'bmp-colors', 'bmp-table' and 'bmp-timer' options together with the 'bitmap' option are stored in the configuration file. @@ -158,7 +158,7 @@ not specified, "transparent" is assumed. then "none" is assumed. The list entries are separated by commas, with no spaces. .TP -.BI "bmp-retain" +.B bmp-retain Option applies to all 'image=' and 'other=' sections. (See COMMON OPTIONS, below.) .TP @@ -206,7 +206,7 @@ by udev. You find the right ID in the di boot = /dev/disk/by-id/ata-SAMSUNG_SV1604N_S01FJ10X99 .fi .TP -.BI "change-rules" +.B change-rules Defines boot-time changes to partition type numbers (`hiding'). .IP .nf @@ -235,7 +235,7 @@ section (see below), with the suffixes " See section "Partition type change rules" of html/user_21-5.html inside the old documentation for more details. .TP -.BI "compact" +.B compact Tries to merge read requests for adjacent sectors into a single read request. This drastically reduces load time and keeps the map file smaller. Using `compact' is especially recommended when booting @@ -299,7 +299,7 @@ Other options include the specification .sp probably only useful for floppy disks and loopback devices, because for hard disks
Bug#869994: work around solution
On 18 May 2018, Reto Schoch wrote: > Your suggested workaround made me once again have a glimpse on the > developer's website and there I found at the top of the FAQ that he > meanwhile has a respond to this issue, namely: > perl 5.26 @INC error If you get something like this instead of the login > screen I also can now see that the author added that information, as well as the reference URL for the issue, to the SQL-Ledger FAQ. Since I'm having to patch it anyway for the Debian package and it's being installed to a known directory, I'm using the example given in that reference for "Script Authors". And it does seems to work, although I'm only able to get as far as the 'Create Dataset' page because a template selection is required and that directory is missing any contents in the distribution archive. -- Robert J. Clay rjc...@gmail.com j...@rocasa.us
Bug#902710: bcrypt fails to import with python3.7: ModuleNotFoundError: No module named '_cffi_backend'
Package: python3-bcrypt Version: 3.1.4-2 Severity: normal Hi, on unstable, with python3.7: $ python3.7 Python 3.7.0 (default, Jun 27 2018, 14:40:03) [GCC 8.1.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import bcrypt Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/bcrypt/__init__.py", line 25, in from bcrypt import _bcrypt ModuleNotFoundError: No module named '_cffi_backend' Spotted because it makes "import paramiko" fail. Christoph
Bug#902582: (some kind of) transition: add python3.7 as a supported python3 version
Control: forwarded -1 https://release.debian.org/transitions/html/python3.7.html On Thu, Jun 28, 2018 at 08:48:39AM +0200, Matthias Klose wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Please setup a tracker to add python3.7 as a supported python3 version. This > is non-blocking, as packages can migrate on their own once built. > > is_affected = .build-depends ~ /python3-all-dev/; > is_good = .depends ~ /python3 \(<< 3\.8\)/ | .depends ~ /python3.7/; > is_bad = .depends ~ /python3 \(<< 3\.7\)/ | .breaks ~ /python \(>= 3\.7\)/; This is https://release.debian.org/transitions/html/python3.7.html (as you've probably already seen). Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
Bug#902709: diffoscope: test failures everywhere
Package: diffoscope Version: 98 Severity: serious Tags: ftbfs So, autopkgtest is failing, for both the tests (with and without recommends): https://ci.debian.net/data/autopkgtest/testing/amd64/d/diffoscope/529342/log.gz The ubuntu build also failed with a very similar error: https://launchpadlibrarian.net/376469998/buildlog_ubuntu-cosmic-amd64.diffoscope_98_BUILDING.txt.gz And also the reproducible builds build FTBFS with the same errors. So, I believe there is a bug here that needs to be fixed. Incidentally, Chris: any reason you did binary uploads instead of source only uploads? Considering how widespread the same failures are I have to believe that the fact it built for you is odd, instead of the other way around as it usually is :) -- 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#902622: I am also affected by this issue
> >ln -s / file: > > is an ugly workaround that does work. In case it isn't obvious to others, this symlink work-around needs to be put in whatever will be the current working directory for firefox. The users' home directory is a good guess. Diane
Bug#900232: collectd: diff for NMU version 5.8.0-5.1
Control: tags 900232 + pending Dear maintainer, I've prepared an NMU for collectd (versioned as 5.8.0-5.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Sinéad O'Connor: Drink Before The War diff -Nru collectd-5.8.0/debian/changelog collectd-5.8.0/debian/changelog --- collectd-5.8.0/debian/changelog 2018-05-04 16:52:07.0 +0200 +++ collectd-5.8.0/debian/changelog 2018-06-29 19:42:43.0 +0200 @@ -1,3 +1,14 @@ +collectd (5.8.0-5.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix "FTBFS: sed: can't read /usr/lib/pkgconfig/OpenIPMIpthread.pc: +No such file or directory": +Drop hack for broken OpenIPMIpthread.pc from debian/rules; apparently the +problem in #474087 was fixed in 2010. +(Closes: #900232) + + -- gregor herrmann Fri, 29 Jun 2018 19:42:43 +0200 + collectd (5.8.0-5) unstable; urgency=medium * debian/rules: diff -Nru collectd-5.8.0/debian/rules collectd-5.8.0/debian/rules --- collectd-5.8.0/debian/rules 2018-05-04 16:39:28.0 +0200 +++ collectd-5.8.0/debian/rules 2018-06-18 19:05:12.0 +0200 @@ -200,13 +200,6 @@ dh_autoreconf - # This is a work-around for #474087 (broken openipmi .pc files). - mkdir debian/pkgconfig - sed -re 's/^(Requires:.*) pthread(.*)$$/\1\2/' \ - /usr/lib/pkgconfig/OpenIPMIpthread.pc \ - > debian/pkgconfig/OpenIPMIpthread.pc - - PKG_CONFIG_PATH="$(CURDIR)/debian/pkgconfig:$$PKG_CONFIG_PATH" \ ./configure $(confflags) CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" \ JAVAC="$(JAVAC)" JAR="$(JAR)" JAVA_CPPFLAGS="$(JAVA_CPPFLAGS)" \ JAVA_LDFLAGS="$(JAVA_LDFLAGS)" \ signature.asc Description: Digital Signature
Bug#902708: RFS: apt-btrfs-snapshot/3.6.2-3 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "apt-btrfs-snapshot" * Package name : apt-btrfs-snapshot Version : 3.6.2-3 Upstream Author : Michael Vogt , Mikhail Novosyolov * URL : https://gitlab.com/nixtux-packaging/apt-btrfs-snapshot * License : GPL Section : admin It builds those binary packages: apt-btrfs-snapshot - Automatically create snapshot on apt operations To access further information about this package, please visit the following URL: https://mentors.debian.net/package/apt-btrfs-snapshot Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/apt-btrfs-snapshot/apt-btrfs-snapshot_3.6.2-3.dsc More information about hello can be obtained from https://gitlab.com/nixtux-packaging/apt-btrfs-snapshot/blob/master/README.md Regards, Mikhail Novosyolov
Bug#902707: mark oxygen-icon-theme Multi-Arch: foreign
Package: oxygen-icon-theme
Version: 5:5.47.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:kcalutils
kcalutils cannot satisfy its cross Build-Depends, because its dependency
on oxygen-icon-theme is not satisfiable. In general, Architecture: all
packages can never satisfy cross Build-Depends unless marked Multi-Arch:
foreign. In this case, such a marking is fine, because its maintainer
scripts only update icon caches, which is and architecture-independent
operation and its only dependency, hicolor-icon-theme, is already thus
marked. Please consider applying the attached patch.
Helmut
diff --minimal -Nru oxygen-icons5-5.47.0/debian/changelog
oxygen-icons5-5.47.0/debian/changelog
--- oxygen-icons5-5.47.0/debian/changelog 2018-06-15 12:10:56.0
+0200
+++ oxygen-icons5-5.47.0/debian/changelog 2018-06-29 19:23:47.0
+0200
@@ -1,3 +1,10 @@
+oxygen-icons5 (5:5.47.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Mark oxygen-icon-theme Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne Fri, 29 Jun 2018 19:23:47 +0200
+
oxygen-icons5 (5:5.47.0-1) unstable; urgency=medium
* New upstream release (5.47.0).
diff --minimal -Nru oxygen-icons5-5.47.0/debian/control
oxygen-icons5-5.47.0/debian/control
--- oxygen-icons5-5.47.0/debian/control 2018-06-15 12:10:56.0 +0200
+++ oxygen-icons5-5.47.0/debian/control 2018-06-29 19:22:12.0 +0200
@@ -20,6 +20,7 @@
Package: oxygen-icon-theme
Architecture: all
+Multi-Arch: foreign
Depends: hicolor-icon-theme, ${misc:Depends}
Breaks: fdpowermon-icons
Replaces: fdpowermon-icons
Bug#902635: qtscript-opensource-src: Please include patch to workaround memory issues on sparc64
Control: tag -1 moreinfo Hi John! El jueves, 28 de junio de 2018 18:38:47 -03 John Paul Adrian Glaubitz escribió: [snip] > Hi! > > I just noticed there is an easy workaround to address the Javascript crashes > on sparc64 [1]. JavaScriptCore allows one to use a 32-bit JSValue - even on > 64-bit systems. In fact, this is done on PPC64 for some reason. > > I have tried this for sparc64 as well and it seems that the Javascript > engine works correctly with that change. > > Attaching a patch, please include in the next upload. Point is: is this a fix or papering over the real problem? I would like to know *for sure* that I'm not applying a hack with this patch. In other words: why it should use 32bits instead of 64? Thanks in advance, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#902706: missing sub2po binary
Package: translate-toolkit Version: 2.3.0-2 Severity: normal Hello, the package, although including the manpage for sub2po, lacks its binary. Could you please check what happened? Have a nice day, David pgpU707oSnOsb.pgp Description: Firma digitale OpenPGP
Bug#902705: chromium-widevine: missing component
Package: chromium-widevine Version: 66.0.3359.117-1~deb9u1 Severity: normal online services that use widevine won't run without /opt/google/chrome/libwidevinecdm.so which was copied to /usr/lib/chromium dpkg -L chromium-widevine /. /usr /usr/lib /usr/lib/chromium /usr/lib/chromium/libwidevinecdmadapter.so /usr/share /usr/share/doc /usr/share/doc/chromium-widevine /usr/share/doc/chromium-widevine/NEWS.Debian.gz /usr/share/doc/chromium-widevine/changelog.Debian.gz /usr/share/doc/chromium-widevine/copyright
Bug#902667: terminology: Terminology fails to start
On 2018-06-29 Mark Dickie wrote: > Package: terminology > Version: 1.2.1-1 > Severity: important > Dear Maintainer, > mark@plata:~$ terminology > terminology: error while loading shared libraries: libelementary.so.1: cannot > open shared object file: No such file or directory > Package libelementary1 does not contain .so > dpkg --listfiles libelementary1 [...] > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) [...] > ii libelementary11.20.7-5 Hello, I really have no idea how this could have happened. I have just installed libelementary1 1.20.7-5 for testing: (sid)ametzler@argenau:~$ dpkg -s libelementary1 | grep ^Version Version: 1.20.7-5 (sid)ametzler@argenau:~$ dpkg --listfiles libelementary1 | grep 'libelementary\.so' /usr/lib/x86_64-linux-gnu/libelementary.so.1.20.7 /usr/lib/x86_64-linux-gnu/libelementary.so.1 cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#902704: lunzip FTCBFS: uses the build architecture compiler
Source: lunzip
Version: 1.10-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
lunzip fails to cross build from source, because it uses the build
architecture compiler. Its homegrown ./configure does not recognize the
standard --host nor the CC environment variable. Explicit passing of CC=
via argv is necessary here. After doing so, lunzip cross builds
successfully. Please consider applying the attached patch.
Helmut
diff --minimal -Nru lunzip-1.10/debian/changelog lunzip-1.10/debian/changelog
--- lunzip-1.10/debian/changelog2018-02-13 07:59:29.0 +0100
+++ lunzip-1.10/debian/changelog2018-06-29 19:08:24.0 +0200
@@ -1,3 +1,10 @@
+lunzip (1.10-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: Pass CC to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne Fri, 29 Jun 2018 19:08:24 +0200
+
lunzip (1.10-1) unstable; urgency=medium
* Uploading to sid.
diff --minimal -Nru lunzip-1.10/debian/rules lunzip-1.10/debian/rules
--- lunzip-1.10/debian/rules2018-02-13 07:58:48.0 +0100
+++ lunzip-1.10/debian/rules2018-06-29 19:08:22.0 +0200
@@ -1,8 +1,13 @@
#!/usr/bin/make -f
+-include /usr/share/dpkg/buildtools.mk
+
%:
dh ${@}
+override_dh_auto_configure:
+ dh_auto_configure -- 'CC=$(CC)'
+
override_dh_auto_install:
dh_auto_install -- DESTDIR=$(CURDIR)/debian/lunzip
Bug#902699: segfault on bad connection
On 2018/06/29 18:32, Joey Hess wrote: > I can frequently segfault ncmpc by connecting to a server that's at the other > end of the house and almost out of wifi range. Was fixed in upstream version 0.29, but this package lags behind a year.
Bug#902703: RFS: hw-probe/1.4-4-git20180614 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "hw-probe" * Package name : hw-probe Version : 1.4-4-git20180614 Upstream Author : Andrey Ponomarenko * URL : https://github.com/linuxhw/hw-probe * License : LGPG-2 Section : utils It builds those binary packages: hw-probe - Hardware probe and system info collection tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hw-probe Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hw-probe/hw-probe_1.4-4-git20180614.dsc More information about hello can be obtained from https://linux-hardware.org Regards, Mikhail Novosyolov
Bug#902702: boost1.62: FTBFS with python3.7 supported: libs/python/src/converter/builtin_converters.cpp:51:35: error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
Source: boost1.62
Version: 1.62.0+dfsg-5.1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Control: block 902582 by -1
boost1.62 fails to build when binNMU'd against python3.7. This example
build log is from amd64, but other architectures seem to be the same:
https://buildd.debian.org/status/fetch.php?pkg=boost1.62=amd64=1.62.0%2Bdfsg-5.1%2Bb1=1530275308=0
common.copy
/<>/boost1.62-1.62.0+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu/libboost_mpi_python-py37.a
cp
"build-3.7/boost/bin.v2/libs/mpi/build/gcc-6.4.0/release/debug-symbols-on/link-static/threading-multi/libboost_mpi_python-py37.a"
"/<>/boost1.62-1.62.0+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu/libboost_mpi_python-py37.a"
gcc.compile.c++
build-3.7/boost/bin.v2/libs/python/build/gcc-6.4.0/release/debug-symbols-on/threading-multi/converter/builtin_converters.o
"x86_64-linux-gnu-g++-6" -ftemplate-depth-128 -g -O2
-fdebug-prefix-map=/<>/boost1.62-1.62.0+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security
-Wno-unused-local-typedefs -O3 -finline-functions -Wno-inline -Wall -g
-Wdate-time -D_FORTIFY_SOURCE=2 -pthread -fPIC -DBOOST_ALL_NO_LIB=1
-DBOOST_PYTHON_SOURCE -DNDEBUG -I"." -I"/usr/include/python3.7m" -c -o
"build-3.7/boost/bin.v2/libs/python/build/gcc-6.4.0/release/debug-symbols-on/threading-multi/converter/builtin_converters.o"
"libs/python/src/converter/builtin_converters.cpp"
libs/python/src/converter/builtin_converters.cpp: In function 'void*
boost::python::converter::{anonymous}::convert_to_cstring(PyObject*)':
libs/python/src/converter/builtin_converters.cpp:51:35: error: invalid
conversion from 'const void*' to 'void*' [-fpermissive]
return PyUnicode_Check(obj) ? _PyUnicode_AsString(obj) : 0;
...failed gcc.compile.c++
build-3.7/boost/bin.v2/libs/python/build/gcc-6.4.0/release/debug-symbols-on/threading-multi/converter/builtin_converters.o...
...skipped
libboost_python-py37.so.1.62.0
for lack of
converter/builtin_converters.o...
...skipped
>/boost1.62-1.62.0+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu>libboost_python-py37.so.1.62.0
for lack of
libboost_python-py37.so.1.62.0...
...skipped
>/boost1.62-1.62.0+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu>libboost_python-py37.so
for lack of
>/boost1.62-1.62.0+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu>libboost_python-py37.so.1.62.0...
...skipped
libboost_mpi_python-py37.so.1.62.0
for lack of
libboost_python-py37.so.1.62.0...
...skipped
>/boost1.62-1.62.0+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu>libboost_mpi_python-py37.so.1.62.0
for lack of
libboost_mpi_python-py37.so.1.62.0...
...skipped
>/boost1.62-1.62.0+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu>libboost_mpi_python-py37.so
for lack of
>/boost1.62-1.62.0+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu>libboost_mpi_python-py37.so.1.62.0...
...skipped
mpi.so
for lack of
libboost_mpi_python-py37.so.1.62.0...
...skipped
>/boost1.62-1.62.0+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu>mpi.so
for lack of
mpi.so...
...skipped
libboost_python3-py37.so.1.62.0
for lack of
converter/builtin_converters.o...
...skipped
>/boost1.62-1.62.0+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu>libboost_python3-py37.so.1.62.0
for lack of
libboost_python3-py37.so.1.62.0...
...skipped
>/boost1.62-1.62.0+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu>libboost_python3-py37.so
for lack of
>/boost1.62-1.62.0+dfsg/debian/tmp/usr/lib/x86_64-linux-gnu>libboost_python3-py37.so.1.62.0...
gcc.compile.c++
build-3.7/boost/bin.v2/libs/python/build/gcc-6.4.0/release/debug-symbols-on/link-static/threading-multi/converter/builtin_converters.o
"x86_64-linux-gnu-g++-6" -ftemplate-depth-128 -g -O2
-fdebug-prefix-map=/<>/boost1.62-1.62.0+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security
-Wno-unused-local-typedefs -O3 -finline-functions -Wno-inline -Wall -g
-Wdate-time -D_FORTIFY_SOURCE=2 -pthread -DBOOST_ALL_NO_LIB=1
-DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB -DNDEBUG -I"."
-I"/usr/include/python3.7m" -c -o
"build-3.7/boost/bin.v2/libs/python/build/gcc-6.4.0/release/debug-symbols-on/link-static/threading-multi/converter/builtin_converters.o"
"libs/python/src/converter/builtin_converters.cpp"
libs/python/src/converter/builtin_converters.cpp: In function 'void*
boost::python::converter::{anonymous}::convert_to_cstring(PyObject*)':
libs/python/src/converter/builtin_converters.cpp:51:35: error: invalid
conversion from 'const void*' to 'void*' [-fpermissive]
return PyUnicode_Check(obj) ? _PyUnicode_AsString(obj) : 0;
...failed gcc.compile.c++
build-3.7/boost/bin.v2/libs/python/build/gcc-6.4.0/release/debug-symbols-on/link-static/threading-multi/converter/builtin_converters.o...
...skipped
libboost_python-py37.a(clean)
for lack of
converter/builtin_converters.o...
...skipped
libboost_python-py37.a
for lack of
converter/builtin_converters.o...
...skipped
Bug#902701: ITP: python-ipfix -- IPFIX implementation for Python
Package: wnpp Severity: wishlist Owner: Luca Boccassi * Package name: python-ipfix Version : 0.9.7 Upstream Author : Brian Trammell * URL : https://github.com/britram/python-ipfix * License : LGPL-3.0 Programming Lang: python Description : IPFIX implementation for Python Upstream description: "This module provides a Python interface to IPFIX message streams, and provides tools for building IPFIX Exporting and Collecting Processes. It handles message framing and deframing, encoding and decoding IPFIX data records using templates, and a bridge between IPFIX ADTs and appropriate Python data types." This module allows applications to programmatically parse IPFIX streams. Need it in $dowstream, so unless there are objections I'll upload sometimes next week. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#902700: RFS: pulseeffects/4.1.1
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "pulseeffects" * Package name : pulseeffects Version : 4.1.1-3 Upstream Author : Wellington Wallace * URL : https://github.com/wwmm/pulseeffects * License : GPL-3 Section : sound It builds those binary packages: pulseeffects - Sound input and output effects for PulseAudio To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pulseeffects Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pulseeffects/pulseeffects_4.1.1-3.dsc More information about hello can be obtained from https://github.com/wwmm/pulseeffects Changes since the last upload: pulseeffects (4.1.1-3) unstable; urgency=low * version dependency 'calf-plugins (>= 0.90.0)' to fix https://github.com/wwmm/pulseeffects/issues/227 -- Mikhail Novosyolov Fri, 29 Jun 2018 18:45:00 +0300 Regards, Mikhail Novosyolov
Bug#902699: segfault on bad connection
Package: ncmpc Version: 0.27-1+b1 Severity: normal I can frequently segfault ncmpc by connecting to a server that's at the other end of the house and almost out of wifi range. Timeout Thread 1 "ncmpc" received signal SIGSEGV, Segmentation fault. mpd_glib_enter (source=0x0) at src/gidle.c:339 339 src/gidle.c: No such file or directory. (gdb) bt #0 mpd_glib_enter (source=0x0) at src/gidle.c:339 #1 0xeac4 in mpdclient_enter_idle_callback (user_data=0x557c7ad0) at src/mpdclient.c:44 #2 0x774900f5 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x774904c0 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x774907d2 in g_main_loop_run () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0xdded in main (argc=3, argv=0x7fffdfd8) at src/main.c:403 (gdb) ping says: 14 packets transmitted, 8 received, 42% packet loss, time 13144ms rtt min/avg/max/mdev = 7.007/230.404/437.850/137.718 ms ncmpc is timing out a lot and reconnecting, and is slow to respond to navigation keystrokes, I assume because it's blocking on network traffic. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ncmpc depends on: ii libc62.27-3 ii libglib2.0-0 2.56.1-2 ii liblirc-client0 0.10.0-2+b1 ii libmpdclient22.11-1 ii libncursesw6 6.1+20180210-4 ii libtinfo66.1+20180210-4 ncmpc recommends no packages. Versions of packages ncmpc suggests: ii mpd 0.20.19-1+b2 pn ncmpc-lyrics -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#902698: ITP: golang-github-tmc-scp -- simple interface to copying files over a go.crypto/ssh session
Package: wnpp Severity: wishlist * Package name: golang-github-tmc-scp Version : 0.0+20170223 Upstream Author : travis.cl...@gmail.com * URL : https://github.com/tmc/scp * License : BSD-1-Clause Programming Lang: Go Description : basic implementation of scp for go simple interface to copying files over a go.crypto/ssh session
Bug#902684: mythtv-status: motd functionality not working correctly
On Fri, 2018-06-29 at 16:27 +0100, Ian Campbell wrote: > The patch there is ok as a local workaround, I think, but maybe not > appropriate > for the package, I'd guess either creating /var/run/mythtv-status.motd and > having a snippet produce that or just having a snippet produce the desired > content on the fly would be better. Perhaps something like this which just came in is helpful: http://lists.mythtv.org/pipermail/mythtv-users/2018-June/396661.html Ian.
Bug#902697: ITP: golang-github-jhoonb-archivex -- archives folders (recursively) and files to zip and tar formats
Package: wnpp Severity: wishlist * Package name: golang-github-jhoonb-archivex Version : 0.0+20170409 Upstream Author : jpbanc...@gmail.com * URL : https://github.com/jhoonb/archivex * License : BSD-3-Clause Programming Lang: Go Description : archives folders (recursively) and files to zip and tar formats
Bug#902696: ITP: golang-github-wunderlist-ttlcache -- in-memory LRU cache with expiration
Package: wnpp Severity: wishlist * Package name: golang-github-wunderlist-ttlcache Version : 0.0+20140611 Upstream Author : WunderList * URL : https://github.com/wunderlist/ttlcache * License : MIT Programming Lang: Go Description : in-memory LRU cache with expiration
Bug#902695: ITP: golang-github-fromkeith-gossdp -- golang port of node-ssdp
Package: wnpp Severity: wishlist * Package name: golang-cloudfoundry-archiver Version : 0.0+20180102 Upstream Author : fromkeith * URL : https://github.com/fromkeith/gossdp * License : BSD-3-Clause Programming Lang: Go Description : golang port of node-ssdp
Bug#902694: ITP: golang-cloudfoundry-archiver -- utilities for extracting and compressing tgz and zip files
Package: wnpp Severity: wishlist * Package name: golang-cloudfoundry-archiver Version : 0.0+20170223 Upstream Author : Cloud Foundry * URL : https://github.com/cloudfoundry/archiver * License : Apache-2.0 Programming Lang: Go Description : utilities for extracting and compressing tgz and zip files
Bug#902693: easyloggingpp: Incomplete debian/copyright?
Source: easyloggingpp Version: 9.96.4+dfsg-1 Severity: serious Justication: Policy 12.5 X-Debbugs-CC: Stephen Kitt Hi, I just ACCEPTed easyloggingpp from NEW but noticed it was missing attribution in debian/copyright for at least a bunch of files under cmake/ (This is in no way 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#902691: ITP: golang-github-mdlayher-ethernet -- marshaling and unmarshaling of IEEE 802.3 Ethernet II frames and IEEE 802.1Q VLAN tags
Package: wnpp Severity: wishlist * Package name: golang-github-mdlayher-ethernet Version : 0.0+20180403 Upstream Author : mdlay...@gmail.com * URL : https://github.com/mdlayher/ethernet * License : MIT Programming Lang: Go Description : marshaling and unmarshaling of IEEE 802.3 Ethernet II frames and IEEE 802.1Q VLAN tags
Bug#902690: Should Suggest: python-pygments-doc
Package: python3-pygments Version: 2.2.0+dfsg-1 Severity: wishlist It would be nice if pygments suggested it's own documentation (python-pygments-doc) in both the python and python3 flavours. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-trunk-amd64 (SMP w/8 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 python3-pygments depends on: ii python3 3.6.6-1 Versions of packages python3-pygments recommends: ii python3-pkg-resources 39.2.0-1 Versions of packages python3-pygments suggests: ii ttf-bitstream-vera 1.10-8
Bug#902670: tomcat7: version number causes exception in osgi startup
Am 29.06.2018 um 17:20 schrieb EmTeedee: > Hi, > > The application we are using uses Eclipse Equinox, which is an OSGI framework. > It is not trying to parse the debian version number, it is trying to parse the > version of exported OSGI packages. > This is used to resolve dependencies and is a core feature of OSGI. > > It looks like the offending version number comes from the Export-Package[1] > attribute in /usr/share/tomcat7/lib/tomcat-jdbc.jar:/META-INF/MANIFEST.MF > In the stable package (7.0.56-3+deb8u11), the version reads "7.0.56" > In the security update (7.0.56-3+really7.0.88-1) it reads > "7.0.56-3+really7.0.88" > > This simply isn't a valid version specification, see e.g. > http://www.eclipse.org/virgo/documentation/virgo-documentation-3.7.0.M01/docs/virgo-user-guide/html/ch02s02.html#d0e341 > > The stable package must have set this version number independently. If this is > actually 7.0.88, I suggest that that should be put in there. Ok, that makes sense. If this is the only MANIFEST file that needs an update, we can patch it with the next update. signature.asc Description: OpenPGP digital signature
Bug#902689: ITP: golang-github-mdlayher-raw -- reading and writing data at the device driver level for a network interface
Package: wnpp Severity: wishlist * Package name: golang-github-mdlayher-raw Version : 0.0+20180403 Upstream Author : mdlay...@gmail.com * URL : https://github.com/mdlayher/raw * License : MIT Programming Lang: Go Description : reading and writing data at the device driver level for a network interface
Bug#902692: gnome-software: Categorize Shell Extensions
Package: gnome-software Version: 3.28.2-1 Severity: wishlist Dear Maintainer, Shell extensions are so many that they need to be categorized to browse them easier. Pr0m -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-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) LSM: AppArmor: enabled Versions of packages gnome-software depends on: ii appstream0.12.1-1 ii apt-config-icons 0.12.1-1 ii dconf-gsettings-backend [gsettings-backend] 0.28.0-2 ii gnome-software-common3.28.2-1 ii gsettings-desktop-schemas3.28.0-1 ii libappstream-glib8 0.7.7-2 ii libatk1.0-0 2.28.1-1 ii libc62.27-3 ii libcairo21.15.10-3 ii libfwupd21.0.8-1 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libglib2.0-0 2.56.1-2 ii libgnome-desktop-3-173.28.2-1 ii libgspell-1-11.6.1-1 ii libgtk-3-0 3.22.30-2 ii libgtk3-perl 0.034-1 ii libgudev-1.0-0 232-2 ii libjson-glib-1.0-0 1.4.2-4 ii libpackagekit-glib2-18 1.1.10-1 ii libpolkit-gobject-1-00.105-20 ii libsecret-1-00.18.6-2 ii libsoup2.4-1 2.62.2-2 ii packagekit 1.1.10-1 ii software-properties-gtk 0.96.20.2-1 gnome-software recommends no packages. Versions of packages gnome-software suggests: pn apt-config-icons-hidpi pn fwupd pn gnome-software-plugin-flatpak pn gnome-software-plugin-limba pn gnome-software-plugin-snap -- no debconf information
Bug#902670: tomcat7: version number causes exception in osgi startup
Le 29/06/2018 à 16:35, Markus Koschany a écrit : > I don't think we can fix the version of tomcat7 without making it > impossible to upgrade from Jessie to Stretch. I think the issue is the version in the OSGi metadata of the MANIFEST.MF file, not the version of the package. This is something we can probably fix. Emmanuel Bourg
Bug#902688: stretch-pu: package openstack-debian-images/1.20~deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
The OpenStack image, as released in Stretch at this URL:
http://cdimage.debian.org/cdimage/openstack/current-9/
suffers from a very annoying "feature": it has the wrong order for the
datasource_list, with CloudStack being before OpenStack. As a consequence,
when the official OpenStack image boots, it takes 120 seconds of waiting
for a datasource which doesn't exist.
So I propose a simple fix, ordering cloud metadata server source in a
different way. As much as I understand, this should not affect the
CloudStack users, and anyway, this image is aimed at the OpenStack users.
This has also no consequence for Amazon EC2 users, as all the sources it
had previous to it are still before it.
Note that I have tested the fix on my own OpenStack deployement, and
indeed, the fixed image booted without waiting for 120 seconds for the
CloudStack metadata server.
Patch is attached. Please allow me to upload
openstack-debian-images/1.20~deb9u2 to Stretch.
Note: diff is attached, pre-built package here:
http://sid.gplhost.com/stretch-proposed-updates/openstack-debian-images/
Cheers,
Thomas Goirand (zigo)
diff -Nru openstack-debian-images-1.20~deb9u1/build-openstack-debian-image
openstack-debian-images-1.20~deb9u2/build-openstack-debian-image
--- openstack-debian-images-1.20~deb9u1/build-openstack-debian-image
2017-06-23 17:02:30.0 +0200
+++ openstack-debian-images-1.20~deb9u2/build-openstack-debian-image
2018-06-29 17:06:12.0 +0200
@@ -557,7 +557,8 @@
else
# For OpenStack, we would like to use Ec2 and no other API
echo "# to update this file, run dpkg-reconfigure cloud-init
-datasource_list: [ NoCloud, AltCloud, CloudStack, ConfigDrive, OpenStack, Ec2,
MAAS, OVF, GCE, None ]" >${MOUNT_DIR}/etc/cloud/cloud.cfg.d/90_dpkg.cfg
+datasource_list: [ NoCloud, AltCloud, ConfigDrive, OpenStack, CloudStack, Ec2,
MAAS, OVF, GCE, None ]" >${MOUNT_DIR}/etc/cloud/cloud.cfg.d/90_dpkg.cfg
+
fi
# Needed to have automatic mounts of /dev/vdb
diff -Nru openstack-debian-images-1.20~deb9u1/debian/changelog
openstack-debian-images-1.20~deb9u2/debian/changelog
--- openstack-debian-images-1.20~deb9u1/debian/changelog2017-06-23
17:02:30.0 +0200
+++ openstack-debian-images-1.20~deb9u2/debian/changelog2018-06-29
17:06:12.0 +0200
@@ -1,3 +1,10 @@
+openstack-debian-images (1.20~deb9u2) stretch; urgency=medium
+
+ * Set CloudStack after OpenStack in the datasource_list, to avoid a 120s
+delay in cloud-init when booting a machine in an OpenStack cloud.
+
+ -- Thomas Goirand Fri, 29 Jun 2018 17:06:12 +0200
+
openstack-debian-images (1.20~deb9u1) stretch-proposed-updates; urgency=medium
* Also add security updates for non wheezy/jessie.
Bug#902687: Should Suggest: dput-ng-doc
Package: dput-ng Version: 1.21 Severity: wishlist Since an additional documentation package is available, it would be nice if dput-ng would Suggest: dput-ng-doc Thanks -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-trunk-amd64 (SMP w/8 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 dput-ng depends on: ii python3 3.6.6-1 ii python3-dput 1.21 dput-ng recommends no packages. Versions of packages dput-ng suggests: pn python3-twitter
Bug#901023: vlc: Hadware decoding does not work with 3.0.2
On 6/29/18 2:51 PM, Rémi Denis-Courmont wrote: Le jeudi 28 juin 2018, 18:52:46 EEST Vincas Dargis a écrit : On Mon, 11 Jun 2018 20:20:18 +0300 =?ISO-8859-1?Q?R=E9mi?= Denis-Courmont wrote: You either have to use libav, or a more recent FFmpeg, or manually turn off threaded decoding in VLC preferences. Whatn FFmpeg version I should build VLC with for threading to work, can I simply grab the latest 4.x? Could it be that bug #898428 could be avoided with latest FFmpeg? As said, the bug can be avoided using recent FFmpeg and then recompiling VLC against that more recent FFmpeg. It does not matter if VLC 4 or 3 is used. Sorry for not being clear enough, I have meant any FFmpeg 4.x release is enough, or I should use master?
Bug#870256: Loosing focus after using spellcheck replacement
Control: reassign -1 orca Control: tags -1 + upstream fixed-upstream Alex ARNAUD, le lun. 31 juil. 2017 12:53:08 +0200, a ecrit: > Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1384987 > > DESCRIPTION FROM UPSTREAM: > > "Dear all, > > From the migration to e10s Firefox no longer sends the correct events when > coming back in a form field after opening the context menu. Users would to > open this menu to check miss spelled word. This was fixed within orca, to be available in orca 3.30. Samuel
Bug#902686: Should Suggest: dbus-1-doc
Package: libdbus-1-dev Version: 1.12.8-3 Severity: wishlist It would be nice if libdbus-1-dev suggested it's own documentation. Curreently, dbus-1-doc suggests libdbus-1-dev, but it should be the other way around: if you have the development headers installed you probably want the documentation as well. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-trunk-amd64 (SMP w/8 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 libdbus-1-dev:amd64 depends on: ii libdbus-1-3 1.12.8-3 ii pkg-config 0.29-4+b1 libdbus-1-dev:amd64 recommends no packages. libdbus-1-dev:amd64 suggests no packages.
Bug#902685: ITP: golang-github-wayn3h0-go-uuid -- go implementation of UUID described in RFC 4122
Package: wnpp Severity: wishlist * Package name: golang-github-wayn3h0-go-uuid Version : 2.2.1-1 Upstream Author : golang-p...@wayn3h0.com * URL : https://github.com/golang-plus/uuid * License : Apache-2.0 Programming Lang: Go Description : go implementation of UUID described in RFC 4122
Bug#902684: mythtv-status: motd functionality not working correctly
Package: mythtv-status Version: 0.10.8-1 Severity: normal Hello, I just installed this package and the motd updating functionality is not working. I can see that it is correctly populating /var/run/motd.dynamic but that is not being incorporated into the actual motd (wherever that is/however that happens). In a mail to mythtv-user[0] another user noticed that apparently it is now necessary (on Ubuntu) to create a snippet in /etc/update-motd.d. I've not tried this on my Debian system yet, but I note that the directory does exist. The patch there is ok as a local workaround, I think, but maybe not appropriate for the package, I'd guess either creating /var/run/mythtv-status.motd and having a snippet produce that or just having a snippet produce the desired content on the fly would be better. Thanks, Ian. [0] http://lists.mythtv.org/pipermail/mythtv-users/2018-June/396660.html -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 4.16.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages mythtv-status depends on: ii debconf [debconf-2.0] 1.5.66 ii libconfig-auto-perl0.44-1 ii libdate-manip-perl 6.71-1 ii libmime-tools-perl 5.509-1 ii libsys-sigaction-perl 0.23-1 ii libwww-perl6.33-1 ii libxml-libxml-perl 2.0128+dfsg-5 ii lsb-base 9.20170808 ii perl 5.26.2-5 Versions of packages mythtv-status recommends: ii libmythtv-perl29.1+fixes20180603.git1777cc4425-dmo1 ii libnet-upnp-perl 1.4.3-1 Versions of packages mythtv-status suggests: pn molly-guard -- debconf information: * mythtv-status/email: none * mythtv-status/host: localhost * mythtv-status/enable: true
Bug#902670: tomcat7: version number causes exception in osgi startup
Hi, The application we are using uses Eclipse Equinox, which is an OSGI framework. It is not trying to parse the debian version number, it is trying to parse the version of exported OSGI packages. This is used to resolve dependencies and is a core feature of OSGI. It looks like the offending version number comes from the Export-Package[1] attribute in /usr/share/tomcat7/lib/tomcat-jdbc.jar:/META-INF/MANIFEST.MF In the stable package (7.0.56-3+deb8u11), the version reads "7.0.56" In the security update (7.0.56-3+really7.0.88-1) it reads "7.0.56-3+really7.0.88" This simply isn't a valid version specification, see e.g. http://www.eclipse.org/virgo/documentation/virgo-documentation-3.7.0.M01/docs/virgo-user-guide/html/ch02s02.html#d0e341 The stable package must have set this version number independently. If this is actually 7.0.88, I suggest that that should be put in there. EmTeedee [1]: the complete attribute looks like this: Export-Package: org.apache.tomcat.jdbc.naming;uses:="javax.naming,org. apache.juli.logging,javax.naming.spi";version="7.0.56",org.apache.tom cat.jdbc.pool;uses:="org.apache.juli.logging,javax.sql,org.apache.tom cat.jdbc.pool.jmx,javax.management,javax.naming,javax.naming.spi,org. apache.tomcat.jdbc.pool.interceptor";version="7.0.56",org.apache.tomc at.jdbc.pool.interceptor;uses:="org.apache.tomcat.jdbc.pool,org.apach e.juli.logging,javax.management.openmbean,javax.management";version=" 7.0.56",org.apache.tomcat.jdbc.pool.jmx;uses:="org.apache.tomcat.jdbc .pool,org.apache.juli.logging,javax.management";version="7.0.56"
Bug#902661: linux-image-4.16.0-2-amd64: kernel BUG at /build/linux-uwVqDp/linux-4.16.16/mm/usercopy.c:100!
Control: reassign -1 nvidia-driver 390.48-3 Control: forcemerge 901919 -1 On Fri, 29 Jun 2018 11:02:37 +0200 Fabian wrote: > Package: src:linux > Version: 4.16.16-2 > Severity: important > > Dear Maintainer, > > starting X via 'startx' causes every screen to stay black, no more > interaction with mouse or keyboards is possible. So I connected via ssh > and tried to execute 'systemctl reboot'. Only the ssh connection was > closed but the system stayed running without any interaction. > After a reboot I looked again via ssh what dmesg prints out. > It said "usercopy: Kernel memory exposure attempt detected from SLUB > object 'nvidia_stack_cache' (offset: 11440, size 3)!", followed by the > message mentioned in the subject. > Therefore the system is not usable with X in this configuration. > > nvidia-driver is in version 390.67-1 Version 390.67-1 shipped a NEWS entry telling you what to do - add this to the kernel cmdline: slab_common.usercopy_fallback=y -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#902683: stretch-pu: package python-proliantutils/2.1.11-2
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
I've prepared an update to python-proliantutils which fixes FTBFS when
there is internet connectivity in the build host. Please find the diff
attached to this bug report. Trivially, it replaces 1.1.1.1 by a never
reachable IP address in the test suite.
This update package will fix #902241.
The resulting built package is here:
http://sid.gplhost.com/stretch-proposed-updates/proliantutils/
Cheers,
Thomas Goirand (zigo)
diff -Nru python-proliantutils-2.1.11/debian/changelog
python-proliantutils-2.1.11/debian/changelog
--- python-proliantutils-2.1.11/debian/changelog2016-09-26
19:13:41.0 +0200
+++ python-proliantutils-2.1.11/debian/changelog2018-06-29
16:25:22.0 +0200
@@ -1,3 +1,10 @@
+python-proliantutils (2.1.11-2+deb9u1) stretch; urgency=medium
+
+ * Add replace-quad1-by-doc-reserved-ip.patch which fixes FTBFS when the
+build machine has internet connectivity (Closes: #902241).
+
+ -- Thomas Goirand Fri, 29 Jun 2018 16:25:22 +0200
+
python-proliantutils (2.1.11-2) unstable; urgency=medium
* d/s/options: extend-diff-ignore of .gitreview
diff -Nru
python-proliantutils-2.1.11/debian/patches/replace-quad1-by-doc-reserved-ip.patch
python-proliantutils-2.1.11/debian/patches/replace-quad1-by-doc-reserved-ip.patch
---
python-proliantutils-2.1.11/debian/patches/replace-quad1-by-doc-reserved-ip.patch
1970-01-01 01:00:00.0 +0100
+++
python-proliantutils-2.1.11/debian/patches/replace-quad1-by-doc-reserved-ip.patch
2018-06-29 16:25:22.0 +0200
@@ -0,0 +1,23 @@
+Description: Replace 1.1.1.1 by doc reserved IPs
+ Looks like there's connectivity to 1.1.1.1 when the build machine has
+ internet access. Swiching to 198.51.100.1 never works, as it is a reserved
+ IP range for documentation purpose.
+ .
+ Note that upstream already removed 1.1.1.1 from its test decoration, so it
+ isn't needed to forward the patch in upstream master branch.
+Author: Thomas Goirand
+Bug-Debian: https://bugs.debian.org/902241
+Forwarded: not-needed
+Last-Update: 2018-06-29
+
+---
python-proliantutils-2.1.11.orig/proliantutils/tests/ilo/test_firmware_controller.py
python-proliantutils-2.1.11/proliantutils/tests/ilo/test_firmware_controller.py
+@@ -551,7 +551,7 @@ class FirmwareImageUploaderTestCase(unit
+ self.assertEqual(returned_sock, ssl_mock.wrap_socket())
+
+ @ddt.data(('foo.bar.com', exception.IloConnectionError),
+- ('1.1.1.1', exception.IloConnectionError),
++ ('198.51.100.1', exception.IloConnectionError),
+ ('any_kind_of_address', exception.IloConnectionError),)
+ @ddt.unpack
+ def test__get_socket_throws_exception_in_case_of_failed_connection(
diff -Nru python-proliantutils-2.1.11/debian/patches/series
python-proliantutils-2.1.11/debian/patches/series
--- python-proliantutils-2.1.11/debian/patches/series 1970-01-01
01:00:00.0 +0100
+++ python-proliantutils-2.1.11/debian/patches/series 2018-06-29
16:25:22.0 +0200
@@ -0,0 +1 @@
+replace-quad1-by-doc-reserved-ip.patch
Bug#902661: linux-image-4.16.0-2-amd64: kernel BUG at /build/linux-uwVqDp/linux-4.16.16/mm/usercopy.c:100!
Control: reassign -1 src:nvidia-graphics-drivers 390.67-1 On Fri, 2018-06-29 at 11:02 +0200, Fabian wrote: > Package: src:linux > Version: 4.16.16-2 > Severity: important > > Dear Maintainer, > > starting X via 'startx' causes every screen to stay black, no more > interaction with mouse or keyboards is possible. So I connected via ssh > and tried to execute 'systemctl reboot'. Only the ssh connection was > closed but the system stayed running without any interaction. > After a reboot I looked again via ssh what dmesg prints out. > It said "usercopy: Kernel memory exposure attempt detected from SLUB > object 'nvidia_stack_cache' (offset: 11440, size 3)!", followed by the > message mentioned in the subject. > Therefore the system is not usable with X in this configuration. > > nvidia-driver is in version 390.67-1 [...] And the bug should have been reported against that. Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Bug#902412: RFS: sodalite/0.14.2-1 [ITP]
Hi Heiko Nickerl, > I am looking for a sponsor for my package "sodalite". Thank you for this package. I'm not sponsoring this package, but I have some comments: 1. debian/copyright: OK 2. postinst: Printing something unecessary to screen during postinst looks unusual. I believe the messages would be better to appear in Description. See: Policy Section 3.9 https://www.debian.org/doc/debian-policy/#maintainer-scripts "The package installation scripts should avoid producing output which is unnecessary for the user to see and should rely on dpkg to stave off boredom on the part of a user installing many packages." Others may be good.
Bug#902241: [PKG-Openstack-devel] Bug#902241: python-proliantutils: FTBFS in stretch (AssertionError: IloConnectionError not raised)
On 06/23/2018 08:42 PM, Santiago Vila wrote:
> ==
> FAIL:
> proliantutils.tests.ilo.test_firmware_controller.FirmwareImageUploaderTestCase.test__get_socket_throws_exception_in_case_of_failed_connection_2
> proliantutils.tests.ilo.test_firmware_controller.FirmwareImageUploaderTestCase.test__get_socket_throws_exception_in_case_of_failed_connection_2
> --
> _StringException: Traceback (most recent call last):
> File "/usr/lib/python2.7/dist-packages/ddt.py", line 129, in wrapper
> return func(self, *args, **kwargs)
> File "proliantutils/tests/ilo/test_firmware_controller.py", line 566, in
> test__get_socket_throws_exception_in_case_of_failed_connection
> self.assertRaises(expected_exception_type, fw_img_uploader._get_socket)
> File "/usr/lib/python2.7/unittest/case.py", line 473, in assertRaises
> callableObj(*args, **kwargs)
> File "/usr/lib/python2.7/unittest/case.py", line 116, in __exit__
> "{0} not raised".format(exc_name))
> AssertionError: IloConnectionError not raised
>
> [...]
>
> I admit this is strange because it seems to build ok in the
> reproducible builds autobuilders.
>
> I can even reproduce it with plain dpkg-buildpackage (i.e. without sbuild)
> on a brand new machine from Digital Ocean, so if you could not reproduce
> this, please contact me privately. As a last resort, I could give you
> access to one of such machines.
>
> Thanks.
Hi Santiago,
Thanks for your bug report.
This isn't strange at all. What's happening is that it builds fine
without external connection. I tried disabling internet connectivity on
my laptop to build the package, and it built fine. That's also what
happens on the buildd and in the reproducible environment, where
probably you do have external connectivity on your builders and on the
Digital Ocean machine.
What I believe happens is that the test
test__get_socket_throws_exception_in_case_of_failed_connection
expects connectivity to 1.1.1.1 to fail (as this is the purpose of the
test: to check if an exception is raised when connectivity fails),
though it doesn't fail, there really is a host behind 1.1.1.1 these
days. Probably there wasn't any machine responding to 1.1.1.1 when the
package was uploaded.
Replacing the IP by 198.51.100.1, which is reserved by IETF for
documentation (according to
https://en.wikipedia.org/wiki/Reserved_IP_addresses) fixes the issue.
I have reported the issue upstream:
https://bugs.launchpad.net/proliantutils/+bug/1779342
and I will probably attempt to fix it upstream and in Stretch.
Cheers,
Thomas Goirand (zigo)
Bug#902670: tomcat7: version number causes exception in osgi startup
Am 29.06.2018 um 13:07 schrieb EmTeedee: > Package: tomcat7 > Version: 7.0.56-3+really7.0.88-1 > Severity: important > Tags: jessie jessie-security > > During startup the current version number causes an application using > ecplise osgi to fail with an exception. I don't think we can fix the version of tomcat7 without making it impossible to upgrade from Jessie to Stretch. Why do you parse the version string of Debian's Tomcat7 package? I believe this should be fixed at the application level. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#902682: RFS: groonga/8.0.4-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "groonga" * Package name: groonga Version : 8.0.4-1 Upstream Author : Groonga Project * Url : http://groonga.org/ * Licenses: LGPL-2.1 Section : database It builds those binary packages: * groonga * groonga-server-common * groonga-server-gqtp * libgroonga-dev * libgroonga0 * groonga-tokenizer-mecab * groonga-token-filter-stem * groonga-plugin-suggest * groonga-bin * groonga-httpd * groonga-doc * groonga-examples * groonga-munin-plugins To access further information about this package, visit the following URL: https://mentors.debian.net/package/groonga Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/groonga/groonga_8.0.4-1.dsc More information about groonga can be obtained from http://groonga.org/ Changes since last upload: * New upstream version 8.0.4. * debian/patches/fix-nginx-FTBFS-on-kfreebsd.patch - Refresh patch to fix FTBFS on kFreeBSD. Regards, pgpT7dSpKRXRO.pgp Description: PGP signature
Bug#863247: java-package: ARM support bitrotted
Hi Emmanuel, I updated the merge request, let me know if anything more is needed. I would like to see this included in the next Debian point release. Thanks, Richard. On 6/5/2018 10:07 AM, Richard Ruigrok wrote: > Hi Emmanuel, > > I uploaded a patch with a merge request: > https://salsa.debian.org/java-team/java-package/merge_requests/1 > > Let me know if this works. > > Thanks, > > Richard. > > > On 5/30/2018 8:47 AM, Emmanuel Bourg wrote: >> Le 30/05/2018 à 16:30, Richard Ruigrok a écrit : >> >>> Should the patch be submitted on GitHub: >>> https://github.com/Debian/java-package ? >> Hi Richard, >> >> Thank you for looking into this. You can submit a PR on the Debian's >> GitLab instance: >> >> https://salsa.debian.org/java-team/java-package >> >> The GitHub repository is no longer synchronized and will be removed in >> the future. >> >> Emmanuel Bourg -- Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Bug#902681: gparted: GParted fails to shrink an LVM PV with lvm2 >= 2.02.171
Package: gparted
Version: 0.30.0-3
Severity: normal
Tags: patch upstream
Dear Maintainer,
== GParted fails to shrink an LVM2 PV reporting this
# lvm pvresize -v --setphysicalvolumesize 786432K '/dev/sda9'
0 physical volume(s) resized / 1 physical volume(s) not resized
Wiping internal VG cache
Wiping cache of LVM-capable devices
/dev/sda9: Requested size 712.00 MiB is less than real size 1.00 GiB. Proceed?
[y/n]:[n]
Physical Volume /dev/sda9 not resized.
== Confirmed on Debian 10 Buster with these packages
$ dpkg -l lvm2 gparted
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==---=
ii gparted0.30.0-3 amd64GNOME partition editor
ii lvm2 2.02.176-4.1 amd64Linux Logical Volume Manager
== Relevant bug references
Issue #1 - Can't shrink LVM partition due to pvresize prompt
https://gitlab.gnome.org/GNOME/gparted/issues/1
Bug 1460577 - regression: lvm2 pvresize command suddenly became interactive,
breaking automated usage
https://bugzilla.redhat.com/show_bug.cgi?id=1460577
== Attached patch
Attached is the upstream patch to workaround the change in pvresize.
Patch applies to gparted >= 0.14.0.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.16.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gparted depends on:
ii libatkmm-1.6-1v5 2.24.2-3
ii libc6 2.27-3
ii libgcc1 1:8.1.0-8
ii libglib2.0-0 2.56.1-2
ii libglibmm-2.4-1v5 2.56.0-2
ii libgtk2.0-0 2.24.32-1
ii libgtkmm-2.4-1v5 1:2.24.5-2
ii libpangomm-1.4-1v52.40.1-4
ii libparted-fs-resize0 3.2-21+b1
ii libparted23.2-21+b1
ii libsigc++-2.0-0v5 2.10.0-2
ii libstdc++68.1.0-8
ii libuuid1 2.32-0.1
gparted recommends no packages.
Versions of packages gparted suggests:
pn dmraid
ii dmsetup2:1.02.145-4.1
ii dosfstools 4.1-2
pn gpart
ii jfsutils 1.1.15-3
pn kpartx
ii mtools 4.0.18-2+b1
ii ntfs-3g1:2017.3.23-2
ii reiser4progs 1.2.0-2
ii reiserfsprogs 1:3.6.27-2
ii xfsprogs 4.15.1-1
ii yelp 3.28.1-1
-- no debconf information
>From 2f090b4a2b649c30c649d36b9919e1d4a4f65c07 Mon Sep 17 00:00:00 2001
From: Mike Fleetwood
Date: Mon, 11 Jun 2018 12:57:52 +0100
Subject: [PATCH] Fix LVM2 PV shrinking with lvm2 2.02.171 and later (#1)
Shrinking an LVM2 Physical Volume on CentOS 7 with the latest
lvm2 2.02.177 fails like this:
Shrink /dev/sda9 from 1.00 GiB to 768.00 MiB
* calibrate /dev/sda9
* check file system on /dev/sda9 for errors and (if possib...(SUCCESS)
* shrink file system (ERROR)
* lvm pvresize -v --setphysicalvolumesize 786432K '/dev/...(ERROR)
0 physical volume(s) resized / 1 physical volume(s) not resized
Wiping internal VG cache
Wiping cache of LVM-capable devices
/dev/sda9: Requested size 712.00 MiB is less than real size 1.00 GiB.
Proceed? [y/n]:[n]
Physical Volume /dev/sda9 not resized.
This upstream change to lvm2 [1] makes pvresize prompt for confirmation
whenever the --setphysicalvolumesize option is used. (The change was
included in lvm2 2.02.171 and later, which is used in recent
distributions. The reporter found the issue on Ubuntu 18.04 LTS and I
reproduced the issue on RHEL/CentOS 7.5). The set size option has to be
used when shrinking the PV before shrinking the partition therefore fix
this issue by adding lvm common option --yes when using the set size
option.
[1]
https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=cbc69f8c693edf0d1307c9447e2e66d07a04bfe9
pvresize: Prompt when non-default size supplied.
Closes #1 - Can't shrink LVM partition due to pvresize prompt
---
src/lvm2_pv.cc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/lvm2_pv.cc b/src/lvm2_pv.cc
index 15af3eb..5f7c7bb 100644
--- a/src/lvm2_pv.cc
+++ b/src/lvm2_pv.cc
@@ -102,7 +102,7 @@ bool lvm2_pv::resize( const Partition & partition_new,
OperationDetail & operati
{
Glib::ustring size = "" ;
if ( ! fill_partition )
- size = " --setphysicalvolumesize " +
+ size = " --yes --setphysicalvolumesize " +
Utils::num_to_str( floor( Utils::sector_to_unit(
partition_new .get_sector_length(),
partition_new .sector_size, UNIT_KIB ) ) ) + "K " ;
return !
