Bug#908555: pydicom build depends on the removed python-gdcm
Source: pydicom Version: 1.1.0-2 Severity: serious Tags: ftbfs The following packages have unmet dependencies: builddeps:pydicom : Depends: python-gdcm but it is not going to be installed
Bug#908517: pushover: crashes due to missing dep on fonts-freefont-ttf
Control: found -1 0.0.5+git20180420-2 Control: severity -1 serious On Mon, Sep 10, 2018 at 07:54:17PM +0200, Adam Borowski wrote: > Package: pushover > Version: 0.0.5+git20180909-1 > Severity: normal > > (Reporting on the version that's stuck in NEW, no idea if it applies to the > old one too.) >... It does. And in any case this should be RC. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#908396: your mail
On Tue, Sep 11, 2018 at 09:08:35AM +0900, Mike Hommey wrote: > On Mon, Sep 10, 2018 at 08:40:08PM +0200, Moritz Mühlenhoff wrote: > > On Mon, Sep 10, 2018 at 02:54:54AM +0200, b...@debian.16bits.net wrote: > > > /proc/cpuinfo shows it supports sse, but not sse2. And movsd is a sse2 > > > instruction [1] > > > > This is an intentional upstream change which also affects the binaries > > provided by Mozilla: > > https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported > > > > It might be possible to disable the use of SSE2 for the i386 architecture > > (as every CPU covered by amd64 supports SSE2), but I have no idea how > > intrusive that would be (and might cause some problems in the long term > > if the non-SSE2 code paths are not covered by upstream CI/tests). It's > > also one additional patch to be carried forward until i386 is retired > > as an architecture. > > The problem from bug #877445 is actually trivial to fix, but the ones > from bug 908449/908396 would seem unrelated. I tried running firefox-esr > from stretch-security in qemu without sse2 (without kvm), and it... just > worked. I couldn't even reproduce #877445. The problem is that > apparently, even when doing emulation, qemu doesn't actually disable > instruction sets, it just hides them from cpuid. So, looking at a local build for i386, it appears that most of the SSE2 code in libxul comes from ... rust. Because the rust compiler happily emits SSE2 on i386, which it shouldn't be doing. Mike
Bug#908351: gajim: Throws errors soon after startup, doesn't work, won't quit
A follow-up, for what it may be worth... Typically, when gajim starts up for me, it automatically joins a groupchat after entering my account password, and the exceptions being thrown appear to relate to that. I have gone back to 1.0.3-1 (compiled from source) so that I have a working gajim and can continue with life, but if anyone wants me to try out anything with the 1.1.0+ source to reproduce/diagnose this, I'd be happy to give it a shot. -m
Bug#891994: epigrass: Depends on Qt4-only python-qwt5-qt4
Hi Andreas > > I would love if people would test this. Since it is not a Build-Depends > where I could see whether the build breaks or not and there is no test > suite to verify whether things work as expected I'm hesitating to just > change the dependencies. > > > Since Python2 is also becoming obsolete in Debian, PyQt-Qwt is > > only compiled for Python3 in Debian > > I'm aware of this and I contacted upstream about this long ago ... > I did try to run the program but I get Traceback (most recent call last): File "/usr/bin/epigrass", line 6, in from pkg_resources import load_entry_point File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3105, in @_call_aside File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3089, in _call_aside f(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3118, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 578, in _build_master ws.require(__requires__) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 895, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 781, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'dbfread' distribution was not found and is required by epigrass If you can tell me how to get it running, I can take a look at the migration to pyqt-qwt. Regards Gudjon
Bug#907322: jekyll: NMU in deferred/4
control: tags -1 patch pending the following diff is now in deferred/4, please let me know if you want me to cancel or reschedule it. thanks Gianfranco diff Description: Binary data
Bug#908554: mozjs60: Build --with-system-icu
Source: mozjs60
Version: 60.1.0-1
Severity: wishlist
We maybe able to build mozjs with the system icu libraries now that the
versions are in sync with the bundled copy. Since as far as can recall that was
the main reason we were using the bundled one being the system libraries were
too old.
I did quickly try a test build using --with-system-icu and it produced one test
failure:
## non262/Intl/DateTimeFormat/tz-environment-variable.js: rc = 3, run time =
0.113342
non262/Intl/DateTimeFormat/tz-environment-variable.js:62:9 Error: Assertion
failed: got "EST5EDT", expected "CST6CDT"
Stack:
@non262/Intl/DateTimeFormat/tz-environment-variable.js:62:9
inTimeZone@non262/Intl/DateTimeFormat/tz-environment-variable.js:36:9
@non262/Intl/DateTimeFormat/tz-environment-variable.js:60:5
TEST-UNEXPECTED-FAIL | non262/Intl/DateTimeFormat/tz-environment-variable.js |
(args: "") [0.1 s]
{"action": "test_start", "pid": 17199, "source": "jstests", "test":
"non262/Intl/DateTimeFormat/tz-environment-variable.js", "thread": "main",
"time": 1536640032.461421}
{"action": "test_end", "extra": {"jitflags": []}, "pid": 17199, "source":
"jstests", "status": "FAIL", "test":
"non262/Intl/DateTimeFormat/tz-environment-variable.js", "thread": "main",
"time": 1536640032.574763}
Bug#908553: pcb-rnd: Fail to launch
Package: pcb-rnd Version: 2.0.1-1 Severity: grave Justification: renders package unusable Dear Maintainer, Trying to launch pcb-rnd I get the following output on the terminal: Error in lihata node /usr/share/pcb-rnd/pcb-conf.lht:119.0:Invalid numeric value: 2.2 Error in lihata node /usr/share/pcb-rnd/pcb-conf.lht:119.0:Invalid numeric value: 2.2 Error in lihata node /usr/share/pcb-rnd/pcb-conf.lht:119.0:Invalid numeric value: 2.2 io_lihata parse error at /usr/share/pcb-rnd/default4.lht:39.0: Invalid coord value: '0.0' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:40.0: Invalid coord value: '0.0' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:38.0: Invalid coord value: '25.0mil' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:39.0: Invalid coord value: '0.0' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:40.0: Invalid coord value: '0.0' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:38.0: Invalid coord value: '25.0mil' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:39.0: Invalid coord value: '0.0' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:40.0: Invalid coord value: '0.0' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:38.0: Invalid coord value: '25.0mil' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:39.0: Invalid coord value: '0.0' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:40.0: Invalid coord value: '0.0' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:38.0: Invalid coord value: '25.0mil' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:39.0: Invalid coord value: '0.0' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:40.0: Invalid coord value: '0.0' io_lihata parse error at /usr/share/pcb-rnd/default4.lht:38.0: Invalid coord value: '25.0mil' Can't create an empty layout, exiting -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8), LANGUAGE=es_CL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pcb-rnd depends on: ii libatk1.0-0 2.28.1-1 ii libc6 2.27-6 ii libcairo2 1.15.12-1 ii libfontconfig1 2.13.0-5 ii libfreetype62.8.1-2 ii libgd3 2.2.5-4 ii libgdk-pixbuf2.0-0 2.36.12-2 ii libgl1 1.1.0-1 ii libglib2.0-02.56.1-2 ii libglu1-mesa [libglu1] 9.0.0-2.1 ii libgtk2.0-0 2.24.32-3 ii libgtkglext11.2.0-9 ii libice6 2:1.0.9-2 ii libpango-1.0-0 1.42.4-1 ii libpangocairo-1.0-0 1.42.4-1 ii libpangoft2-1.0-0 1.42.4-1 ii libpangox-1.0-0 0.0.2-5+b2 ii libsm6 2:1.2.2-1+b3 ii libstroke0 0.5.1-9 ii libx11-62:1.6.6-1 ii libxinerama12:1.1.4-1 ii libxm4 2.3.8-2 ii libxml2 2.9.4+dfsg1-7+b1 ii libxmu6 2:1.1.2-2 ii libxrender1 1:0.9.10-1 ii libxt6 1:1.1.5-1 pcb-rnd recommends no packages. Versions of packages pcb-rnd suggests: pn geda-gnetlist -- no debconf information
Bug#908552: dh-golang: Built-Using is incorrect
Package: dh-golang Version: 1.35 Severity: normal Dear Maintainer, it's been reported lately that the Built-Using field in docker.io is incorrect [1]. I started to investigate, but docker.io is a complicated package with some embedded libraries and a hell of a debian/rules, so it's not the best package to investigate this issue. Instead, I found a more suitable package that also exhibits the issue: notary [2]. This package has a simple debian/rule, and excludes the vendor directory entirely. So I built the latest version of this package (0.6.1~ds1-2 at the moment), and checked the resulting Built-Using. It turns out that the following libraries from Build-Depends are missing in Built-Using: - golang-github-cloudflare-cfssl-dev - golang-github-mattn-go-sqlite3-dev - golang-github-miekg-pkcs11-dev Let's take these packages one by one: * golang-github-miekg-pkcs11-dev This build dependency is optional. We need it because we build notary with the build tag 'pkcs11'. dh_golang is not aware of that, so I guess that's why it doesn't detect this dependency. * golang-github-cloudflare-cfssl-dev This dependency is needed for the testsuite only. If we don't have it, then there you go... # github.com/theupdateframework/notary/trustpinning src/github.com/theupdateframework/notary/trustpinning/certs_test.go:15:2: \ cannot find package "github.com/cloudflare/cfssl/config" in any of ... Should such a dep be eligigle to Built-Using or not? * golang-github-mattn-go-sqlite3-dev Similar to cloudflare: it's only needed for the testsuite. As a sidenote, I also spent some time investigating this issue on the docker.io package, and there's probably other problems to be solved there. I'm wondering, couldn't we generate the Built-Using field by recursing on the Build-Depends? Wouldn't it be more generic and failproof? Best regards, Arnaud [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908055 [2] https://salsa.debian.org/go-team/packages/notary -- 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/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 dh-golang depends on: ii debhelper 11.3.5 ii dpkg 1.19.0.5+b1 ii libdpkg-perl 1.19.0.5 ii perl 5.26.2-7 dh-golang recommends no packages. dh-golang suggests no packages. -- no debconf information
Bug#907363: src:mozjs52: FTBFS on i386: various test failures
On 10/09/18 20:46, Simon McVittie wrote: > Maybe compiling with -ffloat-store and/or -fexcess-precision=standard > would help? firefox-esr seems to be compiled to assume SSE2, which is > itself a RC bug (#908396) but might have been used to address this. > > I have tried building with various combinations of the above flags and the only thing that worked to allow the i386 tests to pass was "-msse2 -mfpmath=sse". -fexcess-precision is not available in C++ and -msse also failed.
Bug#907915: developers-reference: language in manual
Control: tags -1 patch Is the attached patch acceptable? I verified that OUTOFSYNC_ARCHES is set to null in the latest britney2 source. Thanks, Paul Hardy changes.patches.gz.sig Description: PGP signature changes.patches.gz Description: application/gzip
Bug#908551: apt-listchanges: apt update hangs if no mail system
Subject: apt-listchanges: apt update hangs if no mail system
Package: apt-listchanges
Version: 3.10
Tags: patch
Justification: breaks unrelated software
Severity: critical
-- System Information:
Debian Release: 9.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages apt-listchanges depends on:
ii apt 1.4.8
ii debconf [debconf-2.0] 1.5.61
ii debianutils 4.8.1.1
ii python3 3.5.3-1
ii python3-apt 1.4.0~beta3
ii ucf 3.0036
apt-listchanges recommends no packages.
Versions of packages apt-listchanges suggests:
ii citadel-server [mail-transport-agent] 902-4
pn python3-gi
pn www-browser
pn x-terminal-emulator
-- debconf information:
apt-listchanges/frontend: pager
apt-listchanges/which: news
apt-listchanges/confirm: false
apt-listchanges/email-address: root
apt-listchanges/save-seen: true
-- Desription of problem:
When performing a apt update today (Monday, September 10, 2018) there
was a news bit about the Apache/2 package that required reading and
confirmation.
Upon confirmation the apt-listchanges script returned to attempt to send
mail to the configured user email (which is just 'root' in this case.)
IF a system either does not have a mail service installed or is
impropery configured, apt-listchanges will hang while attempting to send
an email before it allows the update process to continue.
Ctrl-c breaks the hang as expected but also breaks the update process
leaving the system in a broken state, unable to update itself.
--BEGIN console output --
Get:70 http://ftp.us.debian.org/debian stretch/main amd64
libapache2-mod-php7.0 amd64 7.0.30-0+deb9u1 [1,225 kB]
Get:71 http://ftp.us.debian.org/debian stretch/main amd64 php7.0-common
amd64 7.0.30-0+deb9u1 [877 kB]
Get:72 http://ftp.us.debian.org/debian stretch/main amd64 patch amd64
2.7.5-1+deb9u1 [112 kB]
Get:73 http://ftp.us.debian.org/debian stretch/main amd64 php7.0 all
7.0.30-0+deb9u1 [53.4 kB]
Get:74 http://ftp.us.debian.org/debian stretch/main amd64
shared-mime-info amd64 1.8-1+deb9u1 [731 kB]
Fetched 73.6 MB in 22s (3,309 kB/s)
Reading changelogs... Done
apt-listchanges: Mailing root: apt-listchanges: news for GX520
^CE: Sub-process /usr/bin/apt-listchanges --apt || test $? -lt 10
received signal 2.
E: Failure running script /usr/bin/apt-listchanges --apt || test $? -lt 10
--END console output --
** I was able to work around this by editing the apt-listchanges script
file by commenting out the offending Mail section as follows:
-- BEGIN snippet --
if news or changes:
apt_listchanges.confirm_or_exit(config, frontend)
hostname = subprocess.getoutput('hostname')
# if apt_listchanges.can_send_emails(config):
# if changes:
# subject = _("apt-listchanges: changelogs for %s") %
hostname
# apt_listchanges.mail_changes(config, changes, subject)
# if news:
# subject = _("apt-listchanges: news for %s") % hostname
# apt_listchanges.mail_changes(config, news, subject)
---END snippet --
Running apt update after this change still allows the News flash and
confirm dialog, and then continues / completes the system updates as normal.
As with the other related 'Wishlist' bug reports for apt-listchanges,
there should be additional prompts added to this file to:
(1) Ask if the user wants to mail a report (default N). - Also notify
user that the process may hang if no mail subsystem exists (which I
believe is now the case starting with stretch) or is improperly
configured. (Just 'root')
(2) See other 3 reports related to MAIL for additional prompt suggestions.
- Thank you -
Bug#905674: parallel: move to nonfree
i haven't installed the latest version, but from https://www.gnu.org/software/parallel/man.html > If you do not want to help financing future development by letting other users see the citation notice or by paying, then please use another tool instead of GNU parallel i'm not enough of a laywer to definitively interpret "please" in that context, but my understanding is that generally it's taken as a required as opposed to optional. i'm assuming the verbage in the current source matches the website, but i haven't attempted to verify that On Mon, Sep 10, 2018 at 8:27 PM, Stefan Monnier wrote: > > usage of parallel requires agreeing to a click-wrap that is inconsistent > > with the DFSG. it should be moved to non-free > [...] > > parallell --bibtex: > > "When using programs that use GNU Parallel to process data for > publication > > please cite: > > ... > > Or you can get GNU Parallel without this requirement by paying 1 EUR. > > ... > > Type: 'will cite' and press enter." > > Apparently this was changed in the mean time to a wording that makes it > clear it's only a polite request and not a legal requirement. > > So, AFAICT it doesn't conflict with the DFSG (at least, not any more). > > > Stefan >
Bug#822743: dh-golang: should assist in calculating -dev packages Depends:
On 2 May 2016 at 13:59, Michael Hudson-Doyle wrote: > Hm, is there actually any case where Depends (or at least > golang-*-dev) and Build-Depends would differ? dh_golang could just > copy one to the other... There's some packages where these two fields differ for a good reason. A good example can be found in the consul package, and in particular this commit: https://salsa.debian.org/go-team/packages/consul/commit/1b8be7f0 Before this commit, the whole source code of consul was shipped in the -dev package, but the problem is that we ended up with circular dependencies. The consul command depends on docker, and docker depends on the consul library. So this commit tackle that, by only shipping a subset of consul in the -dev package, only the parts that make sense in a library. This solves the circular dependencies, and also it reduces the dependency graph of the -dev package, which is always good to take. My conclusion is that there's two cases to consider: 1. If the package is *only* a library, then the Build-Depends of the source package and the Depends of the -dev package are probably identical (except for a few packages like debhelper, which should be filtered out). In this situation, using a substvar generated by dh_golang would surely be helpful. 2. If the package provides both an application and a library, and the library only ships a subset of the source code, then Depends and Build-Depends are different. The most simple in this case is to let the maintainer handle that manually, although I agree it's error prone. Best, Arnaud
Bug#888656: flowcanvas: should this package be removed? (superseded by ganv)
Hi all, On Mon, Sep 10, 2018 at 11:39 PM, Paul Brossier wrote: > hi again, > > thanks for answering Felipe. > > Alessio, if cadence was in the archive, would removing the UI from > ladish seem like a good solution? I agree, it would most definitely be the right solution. Thanks. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A
Bug#905674: parallel: move to nonfree
> usage of parallel requires agreeing to a click-wrap that is inconsistent > with the DFSG. it should be moved to non-free [...] > parallell --bibtex: > "When using programs that use GNU Parallel to process data for publication > please cite: > ... > Or you can get GNU Parallel without this requirement by paying 1 EUR. > ... > Type: 'will cite' and press enter." Apparently this was changed in the mean time to a wording that makes it clear it's only a polite request and not a legal requirement. So, AFAICT it doesn't conflict with the DFSG (at least, not any more). Stefan
Bug#872132: fdisk recommends/suggests needed
Hi Andreas, Thanks for your message. I will add in Suggests field. Regards, Eriberto
Bug#908550: gimp: no gimp-dbg package for 2.10
Package: gimp Version: 2.10.6-3 Severity: wishlist Dear Maintainer, there is a segfault using the measuring tool (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908549), so I tried to install gimp-dbg but does not seem to exist for 2.10 Cheers --Yan -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.18.0-1-686-pae (SMP w/4 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 gimp depends on: ii gimp-data2.10.6-3 ii libaa1 1.4p5-44+b2 ii libbabl-0.1-00.1.56-1 ii libbz2-1.0 1.0.6-9 ii libc62.27-6 ii libcairo21.15.12-1 ii libfontconfig1 2.13.0-5 ii libfreetype6 2.8.1-2 ii libgcc1 1:8.2.0-6 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-4 ii libgegl-0.4-00.4.8-1+b1 ii libgexiv2-2 0.10.8-1 ii libgimp2.0 2.10.6-3 ii libglib2.0-0 2.58.0-3 ii libgs9 9.22~dfsg-3 ii libgtk2.0-0 2.24.32-3 ii libgudev-1.0-0 232-2 ii libharfbuzz0b1.8.8-2 ii libheif1 1.3.2-1 ii libilmbase23 2.2.1-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii liblzma5 5.2.2-1.3 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.3-0 1.3.0-2 ii libopenexr23 2.2.1-4 ii libopenjp2-7 2.3.0-1 ii libpango-1.0-0 1.42.4-3 ii libpangocairo-1.0-0 1.42.4-3 ii libpangoft2-1.0-01.42.4-3 ii libpng16-16 1.6.34-2 ii libpoppler-glib8 0.63.0-2 ii librsvg2-2 2.40.20-3 ii libstdc++6 8.2.0-6 ii libtiff5 4.0.9-6 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libwmf0.2-7 0.2.8.4-12 ii libx11-6 2:1.6.6-1 ii libxcursor1 1:1.1.15-1 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages gimp recommends: ii ghostscript 9.22~dfsg-3 Versions of packages gimp suggests: pn gimp-data-extras ii gimp-help-en [gimp-help] 2.8.2-0.1 pn gimp-python ii gvfs-backends 1.36.2-1 ii libasound21.1.6-1 -- no debconf information
Bug#908365: Package fails to build reproducibly
Am 10.09.18 um 19:22 schrieb Chris Lamb: > Hi Michael, > >> Now, I could try and convince upstream to not embed ABS_BUILD_DIR into >> the binary and maybe let the build system pass the build dir as env var. >> This would make those test-binaries a bit more cumbersome to use though, >> because you'd have to manually set the env var if you directly execute >> the test by hand. > > Hm, could you not install the test data to /usr/systemd/private/path> > whatever and then make the tests default to this, The binaries have a builtin check, which tests if they are executed from the build directory, and if so, use the data files from the build directory. Otherwise they use the datafiles from /usr/lib/systemd/tests/testdata/ overiddable by the > said env var? That would avoid the ugly requirement to set it manually > at the very least. If you run the test directly from the build directory, it's reasonable to assume that you actually want to use the data files from the build directory as well and not the ones from the installed system. Atm the binaries auto-detect that by encoding the build directory into the binary. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#908549: gimp: segfault when using measuring tool
Package: gimp Version: 2.10.6-3 Severity: normal Dear Maintainer, Gimp segfaults when trying to use the measuring tool: yan@hikuri:~$ gimp Missing fast-path babl conversion detected, Implementing missing babl fast paths accelerates GEGL, GIMP and other software using babl, warnings are printed on first occurance of formats used where a conversion has to be synthesized programmatically by babl based on format description *WARNING* missing babl fast path(s): "Y u16" to "Y' u8" *WARNING* missing babl fast path(s): "R'G'B' double" to "CIE Lab double" *WARNING* missing babl fast path(s): "cairo-ARGB32" to "R'G'B'A u8" *WARNING* missing babl fast path(s): "R'G'B'A u8" to "A double" (script-fu:3145): LibGimpBase-WARNING **: 19:31:53.812: script-fu: gimp_wire_read(): error Segmentation fault I did not find a gimp-dbg package, so can't give more info than this. Cheers, --Yan -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.18.0-1-686-pae (SMP w/4 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 gimp depends on: ii gimp-data2.10.6-3 ii libaa1 1.4p5-44+b2 ii libbabl-0.1-00.1.56-1 ii libbz2-1.0 1.0.6-9 ii libc62.27-6 ii libcairo21.15.12-1 ii libfontconfig1 2.13.0-5 ii libfreetype6 2.8.1-2 ii libgcc1 1:8.2.0-6 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-4 ii libgegl-0.4-00.4.8-1+b1 ii libgexiv2-2 0.10.8-1 ii libgimp2.0 2.10.6-3 ii libglib2.0-0 2.58.0-3 ii libgs9 9.22~dfsg-3 ii libgtk2.0-0 2.24.32-3 ii libgudev-1.0-0 232-2 ii libharfbuzz0b1.8.8-2 ii libheif1 1.3.2-1 ii libilmbase23 2.2.1-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii liblzma5 5.2.2-1.3 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.3-0 1.3.0-2 ii libopenexr23 2.2.1-4 ii libopenjp2-7 2.3.0-1 ii libpango-1.0-0 1.42.4-3 ii libpangocairo-1.0-0 1.42.4-3 ii libpangoft2-1.0-01.42.4-3 ii libpng16-16 1.6.34-2 ii libpoppler-glib8 0.63.0-2 ii librsvg2-2 2.40.20-3 ii libstdc++6 8.2.0-6 ii libtiff5 4.0.9-6 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libwmf0.2-7 0.2.8.4-12 ii libx11-6 2:1.6.6-1 ii libxcursor1 1:1.1.15-1 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages gimp recommends: ii ghostscript 9.22~dfsg-3 Versions of packages gimp suggests: pn gimp-data-extras ii gimp-help-en [gimp-help] 2.8.2-0.1 pn gimp-python ii gvfs-backends 1.36.2-1 ii libasound21.1.6-1 -- no debconf information
Bug#902025: emacs25: Emacs 26.1 released
Vincent Bernat writes: > As it seems things have settle down on the unversioned front, do you > plan to upload emacs 26.1? I do, and have been working on it, but haven't found enough time to finish the DFSG split yet, after I found some additional files that are probably going to have to be removed from main, and which may require some adaptation in the code/build-infrastructure. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#908548: r-cran-jsonld: embedded code copy of jsonld.js should be packaged separately
Package: r-cran-jsonld Version: 0.1.0+dfsg-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Binary package ships an embedded code copy of jsonld.js. According to Debian Policy § 4.13, this should be avoided and instead packaged independently. - - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAluXE6gACgkQLHwxRsGg ASGcWQ/+K/do5A98QQ979rfBOvxtB42rDvsCGZXr0gRuENmi2n5z/I5rrHFj+GxR tix/gII7GLVlY6x7yRIe8FXGQTamgswhjUEP5J8ZSecSXLbSbyTQuV3hqTCsHuzf IGodInnGDrmltSaTQvEic2mvJ7URkNlSic5aAWju/bXQlKSrphWkyDcy/d5MgJc0 RCipn+sYP9eoCyG3hohCp763mx97XMgz01LGJLAv05fEv5akQQNdkxsyDSSVtXB/ 9rphuLL30DY3OtbieCgr+kw0ftYLfxSrdP0/MX+782LOsAJ4nqtw6IIFJFSeaiL+ yvSTBknVQimMwQxuocPWx5C2cp59BemDUnM63OAeFbZdAIjzklVaztv/lq2e3h4q B0ptTAqrM72unf8eoM03xdsKhbs/m40YYW7olvL+XIYYZz4lYCMOAjr6CcHzmvzv jE68iMU2WuLUP+98H1Y0OUi4529XkvnlQSjP9nUHr0anaIYzMRI/LjxTDqYwJS0e IDBD5E5+ap4Pd2CK36h5G/hQsDc+vlNzPHz0AsPelWOdRpI0oRFZpypmm3gb9nSP OoCFlkUsAgmy6R+f0bx+P0sdk9WZlDmF9N9SKasy7I2xQ0nWnkQLwfyOtw8UFX8u nm6qMmVyqK3RWGmlmnSA0nfvggSmcy+svVNOc/WhhC41Tn03Ywc= =Jl5u -END PGP SIGNATURE-
Bug#908547: linux-perf is missing dependencies generated by dh_perl and dh_python
Package: src:linux Version: 4.5.1-1 Severity: important In linux-tools version 4.0.2-1 I changed the perfexecdir variable for the upstream perf Makefile from share/perf_$(VERSION)-core to lib/perf_$(VERSION)-core because perf started installing some binaries there. This also changed the installation directory for Perl and Python scripts and modules used in conjunction with perf. Unfortunately I forgot to update the invocations of dh_perl and dh_python at that time. In practice this may not matter much; perf embeds the respective interrpeter libraries and dpkg-shlibdeps generates dependencies based on that. Ben. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/4 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) LSM: AppArmor: enabled
Bug#876608: [Pkg-sass-devel] Bug#876608: ruby-compass (build) depends on ruby-sass (< 3.5), but 3.5.1-2 is in unstable
Hi Steve, Quoting Steve Langasek (2018-09-11 01:25:28) > > This is unlikely to change, since ruby-compass is dead upstream and > > ruby-sass has moved on. :-( > > So, should the maintainer turn this bug into an archive removal > request? I am fine with killing it. Reverse dependencies exist, however, which I believe need either removal or patching first. See bug#908544. Several reverse recommendations exist too, which I will take care of patching. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#908396: your mail
On Mon, Sep 10, 2018 at 08:40:08PM +0200, Moritz Mühlenhoff wrote: > On Mon, Sep 10, 2018 at 02:54:54AM +0200, b...@debian.16bits.net wrote: > > /proc/cpuinfo shows it supports sse, but not sse2. And movsd is a sse2 > > instruction [1] > > This is an intentional upstream change which also affects the binaries > provided by Mozilla: > https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported > > It might be possible to disable the use of SSE2 for the i386 architecture > (as every CPU covered by amd64 supports SSE2), but I have no idea how > intrusive that would be (and might cause some problems in the long term > if the non-SSE2 code paths are not covered by upstream CI/tests). It's > also one additional patch to be carried forward until i386 is retired > as an architecture. The problem from bug #877445 is actually trivial to fix, but the ones from bug 908449/908396 would seem unrelated. I tried running firefox-esr from stretch-security in qemu without sse2 (without kvm), and it... just worked. I couldn't even reproduce #877445. The problem is that apparently, even when doing emulation, qemu doesn't actually disable instruction sets, it just hides them from cpuid. Mike
Bug#907322: Fixed in Ubuntu
Control: owner -1 ! Dear Maintainer, Attached is the fix which I have just uploaded to Ubuntu. I plan on 0-day NMUing this with the appropriate Debian-specific packaging changes at the end of the work week unless you have objections or upload it prior to that. Thanks. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 jekyll_3.8.3+dfsg-2_3.8.3+dfsg-2ubuntu1.diff.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#908546: nbd-client: systemd nbd@.service device init
Package: nbd-client Version: 1:3.18-1 Severity: normal I have nbd1 IP NAME in /etc/nbdtab I have /dev/nbd1 /mountpoint ext4 _netdev,errors=remount-ro 0 0 in /etc/fstab So I can do nbd-client nbd1, and get mounted /mountpoint. But it is not started automatically after reboot. OK, I've created /etc/systemd/system/dev-nbd1.device.requires and symlinked nbd@.service here: ln -s /lib/systemd/system/nbd@.service /etc/systemd/system/dev-nbd1.device.requires/ But it is still not started automatically after reboot, as %i in nbd@.service is dev-nbd1 and not nbd1 and nbd-client cat't init dev-nbd1. So I've created nbd1.service in the /etc/systemd/system, replaced %i with nbd1 and symlinked it into /etc/systemd/system/dev-nbd1.device.requires And only now I got /mountpoint mounted after reboot.
Bug#908542: libsurefire-java: Maven pom contains unwanted rules
Le 11/09/2018 à 00:54, Emmanuel Bourg a écrit : > I haven't figured out the origin of these rules yet The rules added are the surefire own ignore rules. Still looking for what triggered their addition to the pom.
Bug#908545: postfix: upgrade queries about replacing /etc/postfix/makedefs.out, when it really should always do so
Package: postfix Version: 3.3.0-1ubuntu0.1 Severity: minor As you can tell from the version, I'm actually encountering this problem on Ubuntu, but this is merely a packaging matter so filing this upstream seemed valid! When upgrading Postfix, I was surprised to be asked Configuration file '/etc/postfix/makedefs.out' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** makedefs.out (Y/I/N/O/D/Z) [default=N] ? This would appear to have been added with version 3.1.4-1, specifically: * Install /etc/postfix/makedefs.out so users can see how the package was built which is a laudable and understandable goal. However, it seems quite unequivocal that the package-provided version of this file should always be used when installing the package, since the file itself opens with the following line: # Do not edit -- this file documents how Postfix was built for your machine. There does not seem to be a valid reason for a user to have a version of that file that differs at all from the package-provided version, then; any divergence, in fact, would be misleading. Presumably then this file should be included in a way that does not require user intervention to update the makedefs.out file (ex. the /etc/ copy could just be a symlink to a copy in /usr/share/postfix/, or perhaps there's some packaging magic that could be done?). (I suppose I should probably have filed this bug upstream with Debian, but I don't actually have any Debian systems running Postfix at the moment, only Ubuntu Server ones.)
Bug#908467: btrfsmaintenance: Setting idle IO priority via BTRFS_SCRUB_PRIORITY is broken
Control: tag -1 +moreinfo Hi Wolfgang, Thank you for filing this bug, I'm always happy to hear from users, and a bug is an opportunity to improve something! On Mon, Sep 10, 2018 at 08:58:03AM +0100, Wolfgang Weisselberg wrote: > Package: btrfsmaintenance > Version: 0.4.1-3 > Severity: normal > Tags: patch > > Dear Maintainer, > > BTRFS_SCRUB_PRIORITY="idle" (or not setting it at all) in > /etc/default/btrfsmaintenance should cause > /usr/share/btrfsmaintenance/btrfs-scrub.sh to start scrub > with idle IO priority. > > But it starts it with the default IO priority like any other > job. > > The reason seems to be that the default value for ioprio > is not set: [ text from patch and System Information ] From 'man btrfs-scrub', "The default IO priority of scrub is the idle class", thus 'btrfs-scrub' should default to the idle class when $ioprio is nil. eg: ioprio= btrfs scrub start -Bd $ioprio / # is equivalent to # btrfs scrub start -Bd / # which should default to -c 3 (idle) The idle priority might not be applied for other reasons. Would you please share the output to the following commands: First, please unapply your patch or reinstall btrfsmaintenance, since it looks like it is applied to /usr/share/btrfsmaintenance/btrfs-scrub.sh # while a btrfsmaintenance scheduled scrub is running ionice -p `pidof btrfs-scrub` # and cat /sys/block/sd*/queue/scheduler # and cat /sys/module/*/parameters/use_blk_mq Cheers, Nicholas signature.asc Description: PGP signature
Bug#876608: ruby-compass (build) depends on ruby-sass (< 3.5), but 3.5.1-2 is in unstable
Hello, > This is unlikely to change, since ruby-compass is dead upstream and > ruby-sass has moved on. :-( So, should the maintainer turn this bug into an archive removal request? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#908544: compass-bootstrap-sass-plugin depends on ruby-compass which has been removed from testing
Package: ruby-bootstrap-sass Dear Maintainer, The compass-bootstrap-sass-plugin binary package currently has a runtime dependency of "ruby-compass | ruby-sass". ruby-compass has an open RC bug and will likely be removed because it is dead upstream. Please change the depends to only state "ruby-sass". Thank you. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature
Bug#908520: firefox: Needs newer sqlite than what's listed in dependencies
On Mon, Sep 10, 2018 at 09:36:42PM +0300, Juho Turunen wrote: > Package: firefox > Version: 62.0-1 > Severity: normal > > Dear Maintainer, > > Firefox in unstable has dependency for sqlite3-0 (>=3.14.0). This version > doesn't seem to be new enough. > > After upgrading Firefox from older version I got an notification saying that > Firefox can't access bookmarks or address history due to places.sql being > locked. After deleting the file I got the same notice again even though > Firefox > was able to re-create the file. > > Updating sqllite3 to version 3.24.0-1 fixed the issue and the original > places.sqlite was working fine. What version did you have before that? Mike
Bug#908543: dxf2gcode: Please provide a way to specify a file contains inches
Package: dxf2gcode Version: 20170925-4 Severity: wishlist DXF files may contain hints about their measurement units, or they may be abstract numbers. dxf2code tries to guess but if it finds no information either way, it defaults to mm. Some files contain numbers in inches (e.g. in my case, the dxf resultant output from https://cloudconvert.com/svg-to-dxf). Loading these into dxf2code results in shapes that are too small. While this can be corrected by applying a "Scale All" factor of 25.4, it would be nicer if the units could be specified; e.g. $ dxf2code --inches output.dxf -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dxf2gcode depends on: ii poppler-utils 0.63.0-2 ii pstoedit3.73-1+b1 ii python3 3.6.5-3 ii python3-opengl 3.1.0+dfsg-2 ii python3-pyqt5 5.11.2+dfsg-1+b1 dxf2gcode recommends no packages. dxf2gcode suggests no packages. -- no debconf information
Bug#905350: Have you enabled the memory and swap cgroup managers?
Hi, To control memory with libvirt-lxc you need to have the memory controller and swap account controllers active. This means (on Debian) adding: cgroup_enable=memory swapaccount=1 to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub doing sudo update-grub and then rebooting. You are probably seeing lots of messages in your logs like: Failed to open file '/sys/fs/cgroup/memory/machine/lxc-41320-containername.libvirt-lxc/memory.memsw.usage_in_bytes in your logs. Peter C -- Dr Peter Chubb Tel: +61 2 9490 5852 http://ts.data61.csiro.au/ Trustworthy Systems Group Data61 (formerly NICTA)
Bug#908542: libsurefire-java: Maven pom contains unwanted rules
Package: libsurefire-java Version: 2.21.0-2 Severity: serious When libsurefire-java/2.21.0-2 was built last week extra rules were automatically added to the pom of the Maven plugin: --- maven-surefire-plugin-2.21.0-1.pom 2018-09-11 00:24:27.213383006 +0200 +++ maven-surefire-plugin-2.21.0-2.pom 2018-09-11 00:24:37.677124688 +0200 @@ -37,6 +37,20 @@ + org.apache.maven maven-plugin-descriptor * * * *, + org.apache.maven maven-toolchain * * * *, + org.apache.maven.plugins maven-assembly-plugin * * * *, + org.apache.maven.plugins maven-deploy-plugin * * * *, + org.apache.maven.plugins maven-enforcer-plugin * * * *, + org.apache.maven.plugins maven-failsafe-plugin * * * *, + org.apache.maven.plugins maven-scm-publish-plugin * * * *, + org.apache.maven.plugins maven-site-plugin * * * *, + org.apache.maven.plugins maven-surefire-plugin * * * *, + org.apache.rat apache-rat-plugin * * * *, + org.codehaus.mojo animal-sniffer-maven-plugin * * * *, + org.jacoco jacoco-maven-plugin * * * *, + org.powermock * * * * * + 2.21.0 libsurefire-java In particular, the rule: org.apache.maven.plugins maven-surefire-plugin * * * * causes many packages to fail to build from source because they are unable to resolve the version of the Surefire plugin (see #908535, #908536 and #908537) I haven't figured out the origin of these rules yet, maybe a recent change in maven-debian-helper. Once the root cause is identified the surefire package must be rebuilt.
Bug#907912: closed by Sylvestre Ledru (Bug#907912: fixed in llvm-toolchain-7 1:7~+rc3-1)
Control: reopen -1 This didn’t work for some reason: > https://buildd.debian.org/status/package.php?p=llvm-toolchain-7=sid In my testbuilds, LLVM built fine on sparc64 with OpenMP disabled. Will have a look tomorrow. Adrian > On Sep 10, 2018, at 11:54 PM, Debian Bug Tracking System > wrote: > > This is an automatic notification regarding your Bug report > which was filed against the src:llvm-toolchain-7 package: > > #907912: llvm-toolchain-7: Please disable libomp on unsupported architectures > > It has been closed by Sylvestre Ledru . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Sylvestre Ledru > by > replying to this email. > > > -- > 907912: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907912 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > >
Bug#888656: flowcanvas: should this package be removed? (superseded by ganv)
hi again, thanks for answering Felipe. Alessio, if cadence was in the archive, would removing the UI from ladish seem like a good solution? cheers, piem On 09/10/2018 11:33 PM, Filipe Coelho wrote: > hey all. > > ladish is pretty much dead. > that said, you could build the project with just the backend/CLI, and > leave the gtk ui behind. > this satisfies cadence (claudia) needs, since it actually implements a > full new frontend for ladish. > > if that is not an option, just remove ladish altogether and take it out > as dependency from cadence. > it is not a hard requirement for it to run, it will just lose some > features. > > > On 10.09.2018 22:20, Paul Brossier wrote: >> hi all, >> >> flowcanvas should definitely removed, and ganv adopted, since it is >> being used in newer tools such as Cadence (see >> https://github.com/falkTX/Cadence) >> >> ideally, ladish should be switched from using flowcanvas to using ganv. >> I started looking at that, but there is quite a few API changes between >> flowcanvas and ganv, so it is a bit more than a trivial search and >> replace. >> >> Maybe drobilla or falktx (CCed) would want to help here? >> >> cheers, piem >> >> >> On 01/28/2018 03:12 PM, treb...@tuxfamily.org wrote: >>> Le 2018-01-28 14:38, Simon McVittie a écrit : Source: flowcanvas Severity: important User: debian...@lists.debian.org Usertags: proposed-removal Control: clone -1 -2 Control: reassign -2 ladish Control: retitle -2 ladish: should this package be removed? flowcanvas depends on numerous obsolete GNOME 2-era libraries (e.g. #885095) and hasn't had a maintainer upload since 2009. Its upstream website says: **Note**: FlowCanvas is dead, long live Ganv! ganv is also in Debian as src:ganv; it's orphaned in Debian, but appears to have commit activity upstream. flowcanvas has one reverse-dependency in Debian, gladish (src:ladish), whose most recent maintainer upload was in 2014. web.archive.org says the ladish.org website has been down since mid 2014. >>> ladish looks to be maintained by alessio (last commit 20 Apr 2017) >>> here : >>> https://github.com/alessio/ladish/ >>> (the same goes laditools as well) >>> >>> >>> These packages both seem like candidates for removal from unstable. >>> It would be a big regression from a user point of view since it'll >>> remove >>> the "studio" (reopen everything in one-click) from Debian with no >>> alternative. >>> >>> >>> If you agree, please reassign this bug to the ftp team with cont...@bugs.debian.org commands similar to these: severity xx normal reassign xx ftp.debian.org retitle xx RM: flowcanvas -- RoQA; depends on obsolete libraries, superseded by ganv severity yy normal reassign yy ftp.debian.org retitle yy RM: ladish -- RoQA; depends on obsolete libraries, appears unmaintained upstream (replacing RoQA with RoM if you are a maintainer of the appropriate package). Thanks, smcv >>> Hope that helps. >>> Olivier >>> > > signature.asc Description: OpenPGP digital signature
Bug#908540: redis: FTBFS randomly (failing tests)
Package: src:redis
Version: 5:4.0.11-2
Tags: ftbfs
Hello Chris.
I tried to build this package in buster but it failed:
[...]
debian/rules build-indep
dh build-indep
dh_update_autotools_config -i
dh_autoreconf -i
dh_auto_configure -i
debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build --parallel -- V=1
make -j1 "INSTALL=install --strip-program=true" V=1
make[2]: Entering directory '/<>'
cd src && make all
make[3]: Entering directory '/<>/src'
cc -std=c99 -pedantic -DREDIS_STATIC='' -Wall -W
-Wno-missing-field-initializers -O2 -g -ggdb -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -I../deps/hiredis -I../deps/linenoise
-I../deps/lua/src -DUSE_JEMALLOC -I/usr/include/jemalloc/include -Wdate-time
-D_FORTIFY_SOURCE=2 -MM *.c > Makefile.dep 2> /dev/null || true
rm -rf redis-server redis-sentinel redis-cli redis-benchmark redis-check-rdb
redis-check-aof *.o *.gcda *.gcno *.gcov redis.info lcov-html Makefile.dep
dict-benchmark
[... snipped ...]
"start_server {} {
start_server {} {
start_server {} {
set master_id 0 ; # Current master
set start_time [clock seconds] ; # T..."
("uplevel" body line 2)
invoked from within
"uplevel 1 $code "
(procedure "start_server" line 3)
invoked from within
"start_server {} {
start_server {} {
start_server {} {
start_server {} {
set master_id 0 ; # Current master
set start_time [clo..."
("uplevel" body line 2)
invoked from within
"uplevel 1 $code "
(procedure "start_server" line 3)
invoked from within
"start_server {tags {"psync2"}} {
start_server {} {
start_server {} {
start_server {} {
start_server {} {
set master_id 0 ; # Curre..."
(file "tests/integration/psync2.tcl" line 1)
invoked from within
"source $path"
(procedure "execute_tests" line 4)
invoked from within
"execute_tests $data"
(procedure "test_client_main" line 10)
invoked from within
"test_client_main $::test_server_port "
Killing still running Redis server 27611
Killing still running Redis server 27619
Killing still running Redis server 27627
Killing still running Redis server 27805
Killing still running Redis server 27813
make[1]: *** [debian/rules:27: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:16: build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit
status 2
That's just how the build ends and not necessarily the relevant part,
so I've put a bunch of failed build logs here:
https://people.debian.org/~sanvila/build-logs/redis/
The failures happen randomly. Sometimes it fails, sometimes it does not.
Some of above logs were build attempts on n1-standard-1 machines from GCE.
If you have access to such machines, that would be a good way to
trigger the failures. In either case, if you need help to reproduce
the randomness, please say so and I could give you access to a test
machine where this happens.
Note: I'm deliberately not using a severity here. Let's hope you see
this as a special case of non-reproducibility :-)
Thanks.
Bug#908094: i3lock-fancy: new upstream version
Simon Désaulniers writes: > Noted. May be that would be worth to formulate as a question to xss-lock's > upstream too? Maybe. However it is probably not a bug in xss-lock... How would you phrase such a question? -- Brian May
Bug#907774: Confirmed
Hello, I can confirme owncloud desktop client stopped working for me as well. Reverting to this package made it work again: http://ftp.debian.org/debian/pool/main/q/qtbase-opensource-src/libqt5network5_5.11.1+dfsg-6_amd64.deb Regards, Adam.
Bug#905123: Acknowledgement (uwsgi don't start, can't open pid file)
Hello, I found out that problem is related to a patch to do_command file: https://salsa.debian.org/uwsgi-team/uwsgi/commit/d35c0aaa538049d099bf41b6282656f1370d8574 I've reverted the double quotes in the file do_command , and now it starts fine. Can you consider to revert those last changes? At the moment upgrading the package result in a not working program (at least without some workaround requiring to change default.ini file, that is overwritten in a following upgrade). Thanks, Diego. -- Diego Roversi
Bug#908539: golang-github-rjeczalik-notify: FTBFS randomly (TestWatcherInotify fails)
Package: src:golang-github-rjeczalik-notify
Version: 0.9.1-1
Severity: important
Tags: ftbfs
Dear maintainer:
I tried to build this package in buster but it failed:
[...]
debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
dh_update_autotools_config -i -O--buildsystem=golang
dh_autoreconf -i -O--buildsystem=golang
dh_auto_configure -i -O--buildsystem=golang
dh_auto_build -i -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install
-gcflags=\"-trimpath=/<>/obj-x86_64-linux-gnu/src\"
-asmflags=\"-trimpath=/<>/obj-x86_64-linux-gnu/src\" -v -p 1
github.com/rjeczalik/notify
golang.org/x/sys/unix
github.com/rjeczalik/notify
dh_auto_test -i -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1
github.com/rjeczalik/notify
=== RUN TestEventString
--- PASS: TestEventString (0.00s)
=== RUN TestNotifySystemAndGlobalMix
[... snipped ...]
=== RUN TestNonrecursiveTreeInternal
--- PASS: TestNonrecursiveTreeInternal (3.94s)
=== RUN TestRecursiveTree
--- PASS: TestRecursiveTree (8.36s)
=== RUN TestRecursiveTreeWatchInactiveMerge
--- PASS: TestRecursiveTreeWatchInactiveMerge (1.84s)
=== RUN TestRecursiveTree_Windows
--- PASS: TestRecursiveTree_Windows (2.20s)
=== RUN TestCanonicalNoSymlink
--- PASS: TestCanonicalNoSymlink (0.00s)
=== RUN TestJoinevents
--- PASS: TestJoinevents (0.00s)
=== RUN TestTreeSplit
--- PASS: TestTreeSplit (0.00s)
=== RUN TestTreeBase
--- PASS: TestTreeBase (0.00s)
=== RUN TestTreeIndexSep
--- PASS: TestTreeIndexSep (0.00s)
=== RUN TestTreeLastIndexSep
--- PASS: TestTreeLastIndexSep (0.00s)
=== RUN TestCleanpath
--- SKIP: TestCleanpath (0.00s)
util_test.go:141: TODO(rjeczalik)
=== RUN TestCanonical
--- PASS: TestCanonical (0.13s)
=== RUN TestCanonicalCircular
--- PASS: TestCanonicalCircular (0.13s)
=== RUN TestCanonical_RelativeSymlink
--- PASS: TestCanonical_RelativeSymlink (0.00s)
=== RUN TestWatcherInotify
--- FAIL: TestWatcherInotify (3.36s)
testing_test.go:219: testing_test.go:464: ExpectAny received an event
which does not match any of the expected ones (i=0): want one of
[{F:"", C:(chan notify.EventInfo)(nil),
P:"src/github.com/rjeczalik/fs/fs.go", NP:"", E:0x1, NE:0x0, S:interface
{}(nil), Dir:false} {F:"", C:(chan notify.EventInfo)(nil),
P:"src/github.com/rjeczalik/fs/fs.go", NP:"", E:0x20, NE:0x0, S:interface
{}(nil), Dir:false} {F:"", C:(chan notify.EventInfo)(nil),
P:"src/github.com/rjeczalik/fs/fs.go", NP:"", E:0x10, NE:0x0, S:interface
{}(nil), Dir:false}]; got notify.InCloseWrite:
"/<>/obj-x86_64-linux-gnu/src/github.com/rjeczalik/notify/testdata/203247513/src/github.com/rjeczalik/fs/fs.go"
=== RUN TestWatcher
--- PASS: TestWatcher (4.42s)
=== RUN TestStopPathNotExists
--- PASS: TestStopPathNotExists (3.69s)
=== RUN TestWatcherUnwatch
--- PASS: TestWatcherUnwatch (4.19s)
=== RUN TestWatchpoint
--- PASS: TestWatchpoint (0.00s)
FAIL
FAILgithub.com/rjeczalik/notify 51.939s
dh_auto_test: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1
github.com/rjeczalik/notify returned exit code 1
make: *** [debian/rules:6: build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit
status 2
The failure happens randomly, approximately half of the time for me.
I've put a bunch of build logs here:
https://people.debian.org/~sanvila/build-logs/golang-github-rjeczalik-notify/
Please make the build reliable.
If you need help to reproduce it, please say so. As a last resort I could offer
a test machine where this happens very often.
Thanks.
Bug#888656: flowcanvas: should this package be removed? (superseded by ganv)
hey all. ladish is pretty much dead. that said, you could build the project with just the backend/CLI, and leave the gtk ui behind. this satisfies cadence (claudia) needs, since it actually implements a full new frontend for ladish. if that is not an option, just remove ladish altogether and take it out as dependency from cadence. it is not a hard requirement for it to run, it will just lose some features. On 10.09.2018 22:20, Paul Brossier wrote: hi all, flowcanvas should definitely removed, and ganv adopted, since it is being used in newer tools such as Cadence (see https://github.com/falkTX/Cadence) ideally, ladish should be switched from using flowcanvas to using ganv. I started looking at that, but there is quite a few API changes between flowcanvas and ganv, so it is a bit more than a trivial search and replace. Maybe drobilla or falktx (CCed) would want to help here? cheers, piem On 01/28/2018 03:12 PM, treb...@tuxfamily.org wrote: Le 2018-01-28 14:38, Simon McVittie a écrit : Source: flowcanvas Severity: important User: debian...@lists.debian.org Usertags: proposed-removal Control: clone -1 -2 Control: reassign -2 ladish Control: retitle -2 ladish: should this package be removed? flowcanvas depends on numerous obsolete GNOME 2-era libraries (e.g. #885095) and hasn't had a maintainer upload since 2009. Its upstream website says: **Note**: FlowCanvas is dead, long live Ganv! ganv is also in Debian as src:ganv; it's orphaned in Debian, but appears to have commit activity upstream. flowcanvas has one reverse-dependency in Debian, gladish (src:ladish), whose most recent maintainer upload was in 2014. web.archive.org says the ladish.org website has been down since mid 2014. ladish looks to be maintained by alessio (last commit 20 Apr 2017) here : https://github.com/alessio/ladish/ (the same goes laditools as well) These packages both seem like candidates for removal from unstable. It would be a big regression from a user point of view since it'll remove the "studio" (reopen everything in one-click) from Debian with no alternative. If you agree, please reassign this bug to the ftp team with cont...@bugs.debian.org commands similar to these: severity xx normal reassign xx ftp.debian.org retitle xx RM: flowcanvas -- RoQA; depends on obsolete libraries, superseded by ganv severity yy normal reassign yy ftp.debian.org retitle yy RM: ladish -- RoQA; depends on obsolete libraries, appears unmaintained upstream (replacing RoQA with RoM if you are a maintainer of the appropriate package). Thanks, smcv Hope that helps. Olivier
Bug#908536: jnr-posix: FTBFS in buster/sid (Plugin org.apache.maven.plugins:maven-surefire-plugin:2.18.1 could not be resolved)
Package: src:jnr-posix Version: 3.0.45-2 Severity: serious Tags: ftbfs Dear maintainer: I tried to build this package in buster but it failed: [...] debian/rules build-indep dh build-indep --buildsystem=maven --with javahelper dh_update_autotools_config -i -O--buildsystem=maven dh_autoreconf -i -O--buildsystem=maven dh_auto_configure -i -O--buildsystem=maven mh_patchpoms -plibjnr-posix-java --debian-build --keep-pom-version --maven-repo=/<>/debian/maven-repo Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 jh_linkjars -i -O--buildsystem=maven dh_auto_build -i -O--buildsystem=maven /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<> -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/<>/debian/maven.properties org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package javadoc:jar javadoc:aggregate -DskipTests -Dnotimestamp=true -Dlocale=en_US Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release [INFO] Scanning for projects... [INFO] [INFO] --< com.github.jnr:jnr-posix >-- [INFO] Building jnr-posix 3.0.45 [INFO] [ jar ]- [WARNING] The POM for org.apache.maven.plugins:maven-surefire-plugin:jar:2.18.1 is missing, no dependency information available [INFO] [INFO] [INFO] Skipping jnr-posix [INFO] This project has been banned from the build due to previous failures. [INFO] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 0.423 s [INFO] Finished at: 2018-09-10T10:23:13Z [INFO] [ERROR] Plugin org.apache.maven.plugins:maven-surefire-plugin:2.18.1 or one of its dependencies could not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.apache.maven.plugins:maven-surefire-plugin:jar:2.18.1 has not been downloaded from it before. -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<> -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/<>/debian/maven.properties org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package javadoc:jar javadoc:aggregate -DskipTests -Dnotimestamp=true -Dlocale=en_US returned exit code 1 make: *** [debian/rules:7: build-indep] Error 1 dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit status 2 The build was made in my autobuilder with "dpkg-buildpackage -A" but it also fails here: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jnr-posix.html where you can get a full build log if you need it. If this is really a bug in one of the build-depends, please use reassign and affects, so that this is still visible in the BTS web page for this package. Thanks.
Bug#908537: jruby-joni: FTBFS in buster/sid (Plugin org.apache.maven.plugins:maven-surefire-plugin:2.20.1 could not be resolved)
Package: src:jruby-joni Version: 2.1.18-1 Severity: serious Tags: ftbfs Dear maintainer: I tried to build this package in buster but it failed: [...] debian/rules build-indep dh build-indep --buildsystem=maven dh_update_autotools_config -i -O--buildsystem=maven dh_autoreconf -i -O--buildsystem=maven dh_auto_configure -i -O--buildsystem=maven mh_patchpoms -plibjruby-joni-java --debian-build --keep-pom-version --maven-repo=/<>/debian/maven-repo dh_auto_build -i -O--buildsystem=maven /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<> -Dclassworlds.conf=/etc/maven/m2-debian.conf org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package -DskipTests -Dnotimestamp=true -Dlocale=en_US WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release [INFO] Scanning for projects... [INFO] [INFO] < org.jruby.joni:joni >- [INFO] Building Joni 2.1.18 [INFO] [ jar ]- [WARNING] The POM for org.apache.maven.plugins:maven-surefire-plugin:jar:2.20.1 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 0.245 s [INFO] Finished at: 2018-09-10T13:52:45Z [INFO] [ERROR] Plugin org.apache.maven.plugins:maven-surefire-plugin:2.20.1 or one of its dependencies could not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.apache.maven.plugins:maven-surefire-plugin:jar:2.20.1 has not been downloaded from it before. -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<> -Dclassworlds.conf=/etc/maven/m2-debian.conf org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package -DskipTests -Dnotimestamp=true -Dlocale=en_US returned exit code 1 make: *** [debian/rules:4: build-indep] Error 1 dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit status 2 The build was made in my autobuilder with "dpkg-buildpackage -A" but it also fails here: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jruby-joni.html where you can get a full build log if you need it. If this is really a bug in one of the build-depends, please use reassign and affects, so that this is still visible in the BTS web page for this package. Thanks.
Bug#908535: aether-ant-tasks: FTBFS in buster/sid (Plugin org.apache.maven.plugins:maven-surefire-plugin:2.9 could not be resolved)
Package: src:aether-ant-tasks Version: 1.0.1-2 Severity: serious Tags: ftbfs Dear maintainer: I tried to build this package in buster but it failed: [...] debian/rules build-indep dh build-indep --buildsystem=maven --with javahelper dh_update_autotools_config -i -O--buildsystem=maven dh_autoreconf -i -O--buildsystem=maven dh_auto_configure -i -O--buildsystem=maven mh_patchpoms -plibaether-ant-tasks-java --debian-build --keep-pom-version --maven-repo=/<>/debian/maven-repo jh_linkjars -i -O--buildsystem=maven dh_auto_build -i -O--buildsystem=maven /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<> -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/<>/debian/maven.properties org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package -DskipTests -Dnotimestamp=true -Dlocale=en_US WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release [INFO] Scanning for projects... [INFO] [INFO] < org.eclipse.aether:aether-ant-tasks >- [INFO] Building Aether Ant Tasks 1.0.1.v2014 [INFO] [ jar ]- [WARNING] The POM for org.apache.maven.plugins:maven-surefire-plugin:jar:2.9 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 0.289 s [INFO] Finished at: 2018-09-10T12:41:11Z [INFO] [ERROR] Plugin org.apache.maven.plugins:maven-surefire-plugin:2.9 or one of its dependencies could not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.apache.maven.plugins:maven-surefire-plugin:jar:2.9 has not been downloaded from it before. -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<> -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/<>/debian/maven.properties org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package -DskipTests -Dnotimestamp=true -Dlocale=en_US returned exit code 1 make: *** [debian/rules:4: build-indep] Error 1 dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit status 2 The build was made in my autobuilder with "dpkg-buildpackage -A" but it also fails here: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/aether-ant-tasks.html where you can get a full build log if you need it. If this is really a bug in one of the build-depends, please use reassign and affects, so that this is still visible in the BTS web page for this package. Thanks.
Bug#908538: ufo2ft: FTBFS in buster/sid (failing tests)
Package: src:ufo2ft Version: 1.1.0-1 Severity: serious Tags: ftbfs Dear maintainer: I tried to build this package in buster but it failed: [...] debian/rules build-indep dh build-indep --with python3 --buildsystem=pybuild dh_update_autotools_config -i -O--buildsystem=pybuild dh_autoreconf -i -O--buildsystem=pybuild dh_auto_configure -i -O--buildsystem=pybuild I: pybuild base:217: python3.6 setup.py config running config dh_auto_build -i -O--buildsystem=pybuild I: pybuild base:217: /usr/bin/python3 setup.py build running build running build_py creating /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft copying Lib/ufo2ft/outlineCompiler.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft copying Lib/ufo2ft/postProcessor.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft copying Lib/ufo2ft/util.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft copying Lib/ufo2ft/maxContextCalc.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft copying Lib/ufo2ft/fontInfoData.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft copying Lib/ufo2ft/markFeatureWriter.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft copying Lib/ufo2ft/preProcessor.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft copying Lib/ufo2ft/featureCompiler.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft copying Lib/ufo2ft/kernFeatureWriter.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft copying Lib/ufo2ft/__init__.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft creating /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft/featureWriters copying Lib/ufo2ft/featureWriters/markFeatureWriter.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft/featureWriters copying Lib/ufo2ft/featureWriters/kernFeatureWriter.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft/featureWriters copying Lib/ufo2ft/featureWriters/__init__.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft/featureWriters copying Lib/ufo2ft/featureWriters/baseFeatureWriter.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft/featureWriters creating /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft/filters copying Lib/ufo2ft/filters/removeOverlaps.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft/filters copying Lib/ufo2ft/filters/transformations.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft/filters copying Lib/ufo2ft/filters/cubicToQuadratic.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft/filters copying Lib/ufo2ft/filters/decomposeComponents.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft/filters copying Lib/ufo2ft/filters/__init__.py -> /<>/.pybuild/cpython3_3.6_ufo2ft/build/ufo2ft/filters running egg_info creating Lib/ufo2ft.egg-info writing Lib/ufo2ft.egg-info/PKG-INFO writing dependency_links to Lib/ufo2ft.egg-info/dependency_links.txt writing requirements to Lib/ufo2ft.egg-info/requires.txt writing top-level names to Lib/ufo2ft.egg-info/top_level.txt writing manifest file 'Lib/ufo2ft.egg-info/SOURCES.txt' reading manifest file 'Lib/ufo2ft.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' writing manifest file 'Lib/ufo2ft.egg-info/SOURCES.txt' dh_auto_test -i -O--buildsystem=pybuild I: pybuild base:217: cd /<>/.pybuild/cpython3_3.6_ufo2ft/build; python3.6 -m pytest tests = test session starts == platform linux -- Python 3.6.6, pytest-3.6.4, py-1.6.0, pluggy-0.6.0 -- /usr/bin/python3.6 cachedir: ../../../.pytest_cache rootdir: /<>, inifile: setup.cfg collecting ... collected 86 items tests/compiler_test.py::CompilerTest::test_TestFont_CFF PASSED [ 1%] tests/compiler_test.py::CompilerTest::test_TestFont_TTF FAILED [ 2%] tests/compiler_test.py::CompilerTest::test_deprecated_arguments PASSED [ 3%] tests/compiler_test.py::CompilerTest::test_features PASSED [ 4%] tests/compiler_test.py::CompilerTest::test_interpolatableTTFs_lazy FAILED [ 5%] tests/compiler_test.py::CompilerTest::test_mti_features PASSED [ 6%] tests/compiler_test.py::CompilerTest::test_removeOverlaps FAILED [ 8%] tests/compiler_test.py::CompilerTest::test_removeOverlaps_CFF PASSED [ 9%] tests/fontInfoData_test.py::GetAttrWithFallbackTest::test_caret_slope PASSED [ 10%] tests/fontInfoData_test.py::GetAttrWithFallbackTest::test_family_and_style_names PASSED [ 11%] tests/fontInfoData_test.py::GetAttrWithFallbackTest::test_redundant_metadata PASSED [ 12%] tests/fontInfoData_test.py::GetAttrWithFallbackTest::test_vertical_metrics PASSED [ 13%] tests/fontInfoData_test.py::PostscriptBlueScaleFallbackTest::test_with_blue_zones PASSED [ 15%] tests/fontInfoData_test.py::PostscriptBlueScaleFallbackTest::test_without_blue_zones PASSED [ 16%] tests/fontInfoData_test.py::NormalizeStringForPostscriptTest::test_no_change PASSED [ 17%] tests/kernFeatureWriter_test.py::KernFeatureWriterTest::test__cleanupMissingGlyphs PASSED [ 18%]
Bug#908533: compton: Change compton sources
Package: compton Version: 0.1~beta2+20150922-1 Severity: wishlist Dear Maintainer, Compton from https://github.com/chjj/compton was unmantained. Last commit was from 2 years ago. There is a new fork (https://github.com/yshui/compton) that is updated and it is mantained. Maybe you could consider generate debian compton packages from this fork. Thanks. ;) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), LANGUAGE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages compton depends on: ii libc62.27-3 ii libconfig9 1.5-0.4 ii libdbus-1-3 1.12.8-2 ii libgl1 1.1.0-1 ii libgl1-mesa-glx 18.1.6-1 ii libpcre3 2:8.39-4 ii libx11-6 2:1.6.5-1 ii libxcomposite1 1:0.4.4-2 ii libxdamage1 1:1.1.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxinerama1 2:1.1.3-1+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 compton recommends no packages. compton suggests no packages. -- no debconf information
Bug#908534: RM: lyz/2.1.5-3-g895ff3a-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Broken with Firefox 60, removal bug for sid is #908532 Cheers, Moritz
Bug#908532: RM: lyz -- RoQA; unmaintained, RC-buggy
Package: ftp.debian.org Severity: normal Hi, please remove lyz. It's orphaned since 2015 without an adopter and now broken with the XUL deprecation in Firefox. Cheers, Moritz
Bug#908531: ITP: pynwb -- Python library for working with Neurodata in the NWB format
Package: wnpp Severity: wishlist Owner: Yaroslav Halchenko * Package name: pynwb Version : 0.4.1 Upstream Author : PyNWB Team * URL : https://github.com/NeurodataWithoutBorders/pynwb * License : BSD-3 with additional statement Programming Lang: Python Description : Python library for working with Neurodata in the NWB format PyNWB is a Python package for working with NWB files. It provides a high-level API for efficiently working with Neurodata stored in the NWB format. . Neurodata Without Borders: Neurophysiology (NWB:N) is a project to develop a unified data format for cellular-based neurophysiology data, focused on the dynamics of groups of neurons measured under a large range of experimental conditions. I hope to place it under Debian-Science (or Debian-Med?) team maintenance.
Bug#908530: libganv-dev: pc file is incomplete
Package: libganv-dev
Version: 1.4.2~dfsg0-2
Severity: normal
Hi,
The pc file installed by libganv-dev is lacks the path to headers from gtkmm.
Switching from gtk+ to gtkmm shoudl be enough (untested, so not tagging patch):
---
diff --git a/ganv.pc.in b/ganv.pc.in
index 3edf190..4f6ee61 100644
--- a/ganv.pc.in
+++ b/ganv.pc.in
@@ -6,6 +6,6 @@ includedir=@INCLUDEDIR@
Name: ganv
Version: @GANV_VERSION@
Description: A Gtk canvas widget for graph based interfaces
-Requires: gtk+-2.0
+Requires: gtkmm-2.4
Libs: -L${libdir} -l@LIB_GANV@
Cflags: -I${includedir}/ganv-@GANV_MAJOR_VERSION@
---
cheers, piem
-- System Information:
Debian Release: 9.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libganv-dev depends on:
ii libganv-1-1v5 1.4.2~dfsg0-2
ii libglib2.0-dev2.50.3-2
ii libgraphviz-dev 2.38.0-17
ii libgtk2.0-dev 2.24.31-2
ii libgtkmm-2.4-dev 1:2.24.5-1
ii pkg-config0.29-4+b1
libganv-dev recommends no packages.
libganv-dev suggests no packages.
-- no debconf information
Bug#898306: [spl] Conflicts with splat, but should not
Antonio Russo wrote on 09/09/2018 04:00 PM: > This is really bug 894608 again. The long and short of that is: uninstall spl. > You do not need it (spl-dkms, on the other hand, is ABSOLUTELY essential). > Thank you. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Bug#908529: please package new upstream version (1.23) -- fixes trim_errors?
Package: gddrescue Version: 1.22-1 Severity: important New upstream version available. Here is the relevant portion of the changelog. The second item two looks like it might be important, so I've set severity accordingly. 2018-02-13 Antonio Diaz Diaz * Version 1.23 released. * rescuebook.cc (trim_errors): Fix wrong change to non-scraped. * Added new option '--same-file'. * Added new option '--shift' to ddrescuelog. * fillbook.cc (fill_block): Write location data as one line. * fillbook.cc (read_buffer): Do not require a seekable infile. * ddrescue.texi: Added chapter 'Output'. * check.sh: Added 'combined rescue' test. * io.cc: Added missing '#include '. Cheers, Nicholas
Bug#888656: flowcanvas: should this package be removed? (superseded by ganv)
hi all, flowcanvas should definitely removed, and ganv adopted, since it is being used in newer tools such as Cadence (see https://github.com/falkTX/Cadence) ideally, ladish should be switched from using flowcanvas to using ganv. I started looking at that, but there is quite a few API changes between flowcanvas and ganv, so it is a bit more than a trivial search and replace. Maybe drobilla or falktx (CCed) would want to help here? cheers, piem On 01/28/2018 03:12 PM, treb...@tuxfamily.org wrote: > Le 2018-01-28 14:38, Simon McVittie a écrit : >> Source: flowcanvas >> Severity: important >> User: debian...@lists.debian.org >> Usertags: proposed-removal >> Control: clone -1 -2 >> Control: reassign -2 ladish >> Control: retitle -2 ladish: should this package be removed? >> >> flowcanvas depends on numerous obsolete GNOME 2-era libraries >> (e.g. #885095) and hasn't had a maintainer upload since 2009. Its >> upstream >> website says: >> >> **Note**: FlowCanvas is dead, long live Ganv! >> >> ganv is also in Debian as src:ganv; it's orphaned in Debian, but appears >> to have commit activity upstream. >> >> flowcanvas has one reverse-dependency in Debian, gladish (src:ladish), >> whose most recent maintainer upload was in 2014. web.archive.org says >> the ladish.org website has been down since mid 2014. > > ladish looks to be maintained by alessio (last commit 20 Apr 2017) here : > https://github.com/alessio/ladish/ > (the same goes laditools as well) > > > >> These packages both seem like candidates for removal from unstable. > > It would be a big regression from a user point of view since it'll remove > the "studio" (reopen everything in one-click) from Debian with no > alternative. > > > >> If you agree, please reassign this bug to the ftp team with >> cont...@bugs.debian.org commands similar to these: >> >> severity xx normal >> reassign xx ftp.debian.org >> retitle xx RM: flowcanvas -- RoQA; depends on obsolete libraries, >> superseded by ganv >> >> severity yy normal >> reassign yy ftp.debian.org >> retitle yy RM: ladish -- RoQA; depends on obsolete libraries, >> appears unmaintained upstream >> >> (replacing RoQA with RoM if you are a maintainer of the appropriate >> package). >> >> Thanks, >> smcv > > Hope that helps. > Olivier > signature.asc Description: OpenPGP digital signature
Bug#907719: tagging 907719
Control: tags -1 - moreinfo On Fri, Aug 31, 2018 at 09:55:35PM +0100, Adam D. Barratt wrote: > # Awaiting fix in unstable > tags 907719 + moreinfo This has now happened with the NMU. Regards, Salvatore
Bug#908528: devscripts: uscan: simplify common dversionmangle usage
Package: devscripts Version: 2.18.4 Severity: wishlist User: devscri...@packages.debian.org Usertags: uscan Dear maintainer, I noticed a ton of packages use something like this dversionmangle=s/\+(debian|dfsg|ds|deb)(\.\d+)?$// which, IIRC; is suggested by some wiki page. I'd propose some =auto thing that applies that regex. Actually, I'd propose a regex that allows package's versions to not have a dot between 'dfsg' and the number, i.e.: dversionmangle=s/\+(debian|dfsg|ds|deb)(\.)?(\d+)?$// Thanks for considering. -- 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#908527: : autopkgtest regression: depends on r-cran-earth
Control: retitle -1 r-cran-caret autopkgtest depends on r-cran-earth Hmm, that was sent too quickly. On Mon, 10 Sep 2018 22:27:43 +0200 Paul Gevers wrote: > I was looking into the failure of python-taskflow on the ci.debian.org ^^^ should have been r-cran-caret obviously. I'll stop filing bugs now and go to bed. Paul signature.asc Description: OpenPGP digital signature
Bug#908527: : autopkgtest regression: depends on r-cran-earth
Source: r-cran-caret Version: 6.0-79-1 User: debian...@lists.debian.org Usertags: regression Dear maintainers, I was looking into the failure of python-taskflow on the ci.debian.org infrastructure. It seems the root cause of the current failure (log copied below) is a missing test dependency. Thanks for considering. Paul https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-caret/967190/log.gz Removing autopkgtest-satdep:amd64 because I can't find r-cran-earth:amd64 signature.asc Description: OpenPGP digital signature
Bug#908248: Patch available but not part in mainstream
Hello team, There seems to be patch available, but not part of upstream kernel source yet (checked against 4.18.7 git), provided by AMD employee. Applied the patch listed from page below to 4.18.6 kernel from kernel.org and no issues visible related to udev stuck as reported before. https://lore.kernel.org/patchwork/patch/974869/ (https://lore.kernel.org/patchwork/patch/974869/) BRTL
Bug#764678: dh-systemd: Please support systemd user services
> Work is being done on dh_installsystemduser > Some bits have already landed in init-system-helpers [1] and there is an > open MR for debhelper [2]. > Once that MR lands in debhelper, picking a package like gpg-agent and > converting it to the new helper might be a good idea to give it some > real world testing and shake out any bugs. thanks! I'm reading this bug report, so feedback here would be great. or feel free to let me know via a report in the BTS for either gpg-agent or dirmngr and i'll wrap it up that way. the ongoing work on debhelper is much appreciated! --dkg
Bug#908345: transition: ldc / phobos 81
Matthias Klumpp: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi! > Yet another LDC ABI and standard library transition is currently going > on (since D does not provide a stable ABI, this happens with every > upload of a new LDC release). > > The Ben file that was auto-generated looks okay to me: > https://release.debian.org/transitions/html/auto-ldc.html > (for some reason it switched to "!?" state recently though, likely due > to LDC migrating to testing before the transition was done.) > > Is it still necessary to create transition tracking bugs for correctly > auto-generated transitions? Or should I in that case just wait for the > release team to schedule bugs on their own at some point? > > Cheers, > Matthias > Hi Matthias, I tried scheduling binNMUs for libundead and glib-d but they both FTBFS. Could you please review the issues and file bugs (or upload fixes) to resolve the situation? Thanks, ~Niels
Bug#908526: python-taskflow: autopkgtest depends on long gone packages
Source: python-taskflow Version: 3.1.0-3 User: debian...@lists.debian.org Usertags: fails-always Dear maintainers, I was looking into the failure of python-taskflow on the ci.debian.org infrastructure. It seems the root cause of the current failure (log copied below) is trivial to fix. The autopkgtest depends on package(s?) that is only available as transitional dummy package in jessie-backports. Updating the test dependencies may just get the autopkgtest to pass. Thanks for considering. Paul https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-taskflow/954350/log.gz Removing autopkgtest-satdep:amd64 because I can't find python-oslo-serialization:amd64 signature.asc Description: OpenPGP digital signature
Bug#907573: Please provide u-boot image for qemu
On 2018-08-29, Ivo De Decker wrote: > Upstream u-boot ships a config for qemu. It would be nice to have the u-boot > package build this. I tested it on armhf and arm64. Qemu can be started with > "-bios /path/to/u-boot.bin". All that is needed is a boot.src or > extlinux.conf. On a clean install with d-i, running u-boot-update (from > u-boot-menu) is enough. Flash-kernel could probably support this too, but it > would need to be updated. Thanks for the suggestion! > If you think this is a good idea, I can write a patch (or create a merge > request) that creates a u-boot-qemu package. I wonder if this would be > usefull on other architectures (besided arm*). I've been hesitant to include the qemu targets in the past, but if it would actually be useful to people, I could see enabling u-boot-qemu for at least arm64, armhf and *maybe* some of the mips, ppc, x86 and x86_64 targets. U-Boot v2019.09-rc3 contains: qemu-ppce500_defconfig qemu_arm64_defconfig qemu_mips64el_defconfig qemu-x86_64_defconfig qemu_arm_defconfig qemu_mips_defconfig qemu-x86_defconfig qemu_mips64_defconfig qemu_mipsel_defconfig I would want to have a documented way of what it actually takes to use them, upstream and/or in README.Debian. I've tried some of these targets in the past and was unable to figure it out, but it's been a while. There are also patches for riscv submitted upstream, which might be useful for riscv64 while real hardware is still quite limited: https://lists.denx.de/pipermail/u-boot/2018-September/339977.html live well, vagrant signature.asc Description: PGP signature
Bug#908525: qcontrol FTCBFS: upstream Makefile hard codes the build architecture pkg-config
Source: qcontrol Version: 0.5.6-1 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap qcontrol fails to cross build from source, because the upstream Makefile hard codes the build architecture pkg-config. After making it substitutable it gets substituted by dh_auto_build and qcontrol cross builds successfully. Please consider applying the attached patch. Helmut --- qcontrol-0.5.6.orig/Makefile +++ qcontrol-0.5.6/Makefile @@ -3,18 +3,19 @@ CFLAGS += -c -g -Os -Wall -Wextra CPPFLAGS += -DQCONTROL_VERSION=\"$(VERSION)\" +PKG_CONFIG ?= pkg-config LDFLAGS += -g LIBS_DYNAMIC += -lpthread LIBS_STATIC += /usr/lib/$$(dpkg-architecture -qDEB_HOST_MULTIARCH)/liblua5.1.a -lpthread -lm -ldl -CFLAGS += $(shell pkg-config --cflags lua5.1) +CFLAGS += $(shell $(PKG_CONFIG) --cflags lua5.1) -LIBS_DYNAMIC += $(shell pkg-config --libs lua5.1) +LIBS_DYNAMIC += $(shell $(PKG_CONFIG) --libs lua5.1) -ifeq ($(shell pkg-config --exists libsystemd-daemon 2>/dev/null && echo 1),1) +ifeq ($(shell $(PKG_CONFIG) --exists libsystemd-daemon 2>/dev/null && echo 1),1) CPPFLAGS_DYNAMIC += -DHAVE_SYSTEMD -CFLAGS_DYNAMIC += $(shell pkg-config --cflags libsystemd-daemon) -LIBS_DYNAMIC += $(shell pkg-config --libs libsystemd-daemon) +CFLAGS_DYNAMIC += $(shell $(PKG_CONFIG) --cflags libsystemd-daemon) +LIBS_DYNAMIC += $(shell $(PKG_CONFIG) --libs libsystemd-daemon) endif SOURCES=qcontrol.c system.c qnap-pic.c ts209.c ts219.c ts409.c ts41x.c evdev.c a125.c synology.c
Bug#908410: Fwd: Bug#908410: Acknowledgement (RFS: gradle-apt-plugin/0.10-1 [ITP])
Le 10/09/2018 à 18:44, Miroslav Kravec a écrit :
> Thanks! It took some effort, so I'm glad the package is considered to be
> well packaged.
There was just a redundant build dependency on default-jre-headless
(implied by default-jdk), and the ${maven:Depends} variable was useless
because it only works with maven-debian-helper.
> How long does it usually take to get package approved?
It can be very fast or take a few weeks, we never now. It's just a
matter of patience.
Bug#908521: Proposed CGI
Le 10/09/2018 à 20:46, Xavier a écrit : > Merge request created here: > > https://salsa.debian.org/qa/qa/merge_requests/9 Updated: https://salsa.debian.org/qa/qa/merge_requests/10
Bug#908523: libcppunit-dev: cppunit.m4 is no more provided
severity 908523 minor retitle 908523 /usr/share/doc/libcppunit-dev/README.Debian contains documentation about removed AM_PATH_CPPUNIT() thanks Hi, On Mon, Sep 10, 2018 at 09:10:09PM +0200, Ludovic Rousseau wrote: > But /usr/share/doc/libcppunit-dev/README.Debian contains a documentation > of the M4 macro AM_PATH_CPPUNIT() Remains from old days probably. > Another strange thing is that /usr/share/aclocal/cppunit.m4 is listed as > provided by libcppunit-dev from unstable by > https://packages.debian.org/search?searchon=contents=cppunit.m4=filename=unstable=any packages.debian.orgs file contents are grossly outdated. No news. > I could not find a replacement for cppunit.m4 in > https://www.gnu.org/software/autoconf-archive/The-Macros.html#The-Macros pkg-config. > If upstream decided to remove cppunit.m4, which looks to be the case, > then maybe you should remove the file > /usr/share/doc/libcppunit-dev/README.Debian Which would make this a minor bug only, as it's only documentation. > I also note that cppunit-config was also removed. Using cppunit.m4 from the > Debian stable does not work without cppunit-config. True. Use pkg-config (PKG_CHECK_MODULES or however it's called) > I suggest to: > - remove README.Debian or, at least, change its content. > - add a line in changelog that cppunit-config and cppunit.m4 have been > removed upstream and are no more provided In a change which happened months ago? No. Besides that, it's called evolution and replacing it with something standard. Other *-config removals didn't end up promimently either; this is _developer_ material anyway. (If at all, NEWS, and that one would bother too many people imho.) Regards, Rene
Bug#907806: How to disable tests for Python2 only?
On Mon, Sep 10, 2018 at 11:44:00AM -0400, Yaroslav Halchenko wrote: > > > ... sorry to repeat myself but having team maintained packages on > > github is not inviting to others. Is there any reason not to > > use Salsa? > > yeap, let's make a repo on salsa. Would you be ok to retain my weird > "based on upstream git" setup? https://salsa.debian.org/science-team/scikit-learn (I did so about one year ago but you decided to stay on Github. I removed the old repo and injected what I cloned this morning and added a pristine-tar branch. I volunteer to do it even a third time but not more. ;-) ) Hope this helps and thanks for caring for the package. I agree that packaging the new upstream version is probably the best strategy if it is in the not too distant future (= we will not loose all the rdepends from testing) Kind regards Andreas. -- http://fam-tille.de
Bug#908524: pipewire: Section should not be “libs”
Package: pipewire Version: 0.2.2-1 Severity: minor Dear Maintainer, The section “libs” is for packages that install supporting functionality for other packages. Its packages are primarily of interest only as dependencies in other packages. The package ‘pipewire’ installs primarily an application, to be directly used on the system. It should not be in the “libs” section. By the section descriptions, this package might belong in section “net” or some other section. Please set the field “Section” appropriately on this package. Since the package is already in Debian with a different section, you will also need to submit a request to override the existing section https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#override-file>. Then mark that new bug report as blocked by this one, to show the dependency between them. -- \ “The conflict between humanists and religionists has always | `\ been one between the torch of enlightenment and the chains of | _o__) enslavement.” —Wole Soyinka, 2014-08-10 | Ben Finney signature.asc Description: PGP signature
Bug#908523: libcppunit-dev: cppunit.m4 is no more provided
Package: libcppunit-dev Version: 1.14.0-3 Severity: important Hello, The file /usr/share/aclocal/cppunit.m4 is not (no more) provided by this package. From /usr/share/doc/libcppunit-dev/changelog.gz I found: 2016-10-15 Markus Mohrhard [fcc84eec40acf8506f2a5fcc3fe0399663d1ce18] cppunit.m4 is gone But /usr/share/doc/libcppunit-dev/README.Debian contains a documentation of the M4 macro AM_PATH_CPPUNIT() Another strange thing is that /usr/share/aclocal/cppunit.m4 is listed as provided by libcppunit-dev from unstable by https://packages.debian.org/search?searchon=contents=cppunit.m4=filename=unstable=any The version 1.13.2-2.1 from stable provides the cppunit.m4 I guess the file disappeared with version 1.14. I could not find a replacement for cppunit.m4 in https://www.gnu.org/software/autoconf-archive/The-Macros.html#The-Macros If upstream decided to remove cppunit.m4, which looks to be the case, then maybe you should remove the file /usr/share/doc/libcppunit-dev/README.Debian I also note that cppunit-config was also removed. Using cppunit.m4 from the Debian stable does not work without cppunit-config. I suggest to: - remove README.Debian or, at least, change its content. - add a line in changelog that cppunit-config and cppunit.m4 have been removed upstream and are no more provided Regards, -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages libcppunit-dev depends on: ii libcppunit-1.14-0 1.14.0-3 libcppunit-dev recommends no packages. Versions of packages libcppunit-dev suggests: pn libcppunit-doc -- no debconf information
Bug#908501: Does not depend on zlib1g-dev
Control: tags -1 pending Hi Andrey, On Mon, Sep 10, 2018 at 07:38:28PM +0500, Andrey Rahmatullin wrote: > > /usr/include/htslib/bgzf.h includes zlib.h and htslib.pc contains > Requires.private: zlib yet the package doesn't depend on zlib1g-dev. Good catch. I've fixed this in Git. I'll delay the upload a bit since we can make this part of the next transition of htslib and samtools. Kind regards Andreas. -- http://fam-tille.de
Bug#908522: python-dateutil breaks patroni autopkgtest
Source: python-dateutil, patroni
Control: found -1 python-dateutil/2.7.3-1
Control: found -1 patroni/1.4.4-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainers,
With a recent upload of python-dateutil the autopkgtest of patroni fails
in testing when that autopkgtest is run with the binary packages of
python-dateutil from unstable. It passes when run with only packages
from testing. I copied some of the output at the bottom of this report.
Currently this regression is contributing to the delay of the migration
of python-dateutil to testing [1]. Due to the nature of this issue, I
filed this bug report against both packages. Can you please investigate
the situation and reassign the bug to the right package? If needed,
please change the bug's severity.
For reference of the patroni maintainers, bug 907718: "RRULE UNTIL
values must be specified in UTC when DTSTART is timezone-aware" already
exist against the python-dateutils package with multiple affected
packages and multiple bugs blocking the "fix". I can't judge from the
error logging if this is at all related.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=python-dateutil
https://ci.debian.net/data/autopkgtest/testing/amd64/p/patroni/967658/log.gz
=== FAILURES
===
_ TestPostgresql.test_wait_for_startup
_
self =
def test_wait_for_startup(self):
state = {'sleeps': 0, 'num_rejects': 0, 'final_return': 0}
def increment_sleeps(*args):
print("Sleep")
state['sleeps'] += 1
def isready_return(*args):
ret = 1 if state['sleeps'] < state['num_rejects'] else
state['final_return']
print("Isready {0} {1}".format(ret, state))
return ret
def time_in_state(*args):
return state['sleeps']
with patch('subprocess.call', side_effect=isready_return):
with patch('time.sleep', side_effect=increment_sleeps):
self.p.time_in_state = Mock(side_effect=time_in_state)
self.p._state = 'stopped'
self.assertTrue(self.p.wait_for_startup())
> self.assertEquals(state['sleeps'], 0)
E AssertionError: 114 != 0
tests/test_postgresql.py:812: AssertionError
signature.asc
Description: OpenPGP digital signature
Bug#908521: Proposed CGI
Merge request created here: https://salsa.debian.org/qa/qa/merge_requests/9
Bug#908471: atril: include AppArmor profile in the package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2018-09-10 at 13:42 +0200, Yves-Alexis Perez wrote: > On Mon, 2018-09-10 at 11:31 +, Mike Gabriel wrote: > > Sure, we can do this. Can you provide a patch against the package? Thanks! > > Unfortunately no, at least not a tested patch. Besides the trivial renaming > s/evince/atril/, I guess there are other differences in the package and I > don't know enough internals to provide a working patch. So I did a naive copy/paste of the evince profile, and it didn't work at all: ** (atril:13700): ERROR **: 20:53:51.229: Unable to fork a new child process: Failed to execute child process “/usr/lib/x86_64-linux-gnu/webkit2gtk- 4.0/WebKitWebProcess” (Permission denied) I have to admit I'm quite confused to have atril forking a Webkit renderer for a PDF file, but that also mean it's harder than just reusing the profile. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAluWvhAACgkQ3rYcyPpX RFul5gf+KQtAqjUrrzGR72fSj21QeaVLy12zQcODComFu2KDl6LBg8S9hxdgHbo4 CanUJw0ZHRsF5waNVpRGkiRTeiyQ+rPz0DjtsQ7hZBHow/O2+hYubQbHHdPup70A G96UInvDHowQDOODE3VE9CyahtKFUXaysPCdaZxndWdR3K8qa7K+VHthv0EkJyLa JSFz+F13VXq5It9A9wKTa/UE5es9Q6LHPFq2WihNew/WUmq0BU2KaN5MwhNqS0hG 3gIDz31VV6VM2v/jeNUsFnhLyvCiOdHWEZZan4v31bjh3v7p174J3IbSpkFXCUjZ Vge2YcgsNiqsZNrvRZ2MADDVxTc0bQ== =4S6+ -END PGP SIGNATURE-
Bug#908396: your mail
On Mon, Sep 10, 2018 at 02:54:54AM +0200, b...@debian.16bits.net wrote: > /proc/cpuinfo shows it supports sse, but not sse2. And movsd is a sse2 > instruction [1] This is an intentional upstream change which also affects the binaries provided by Mozilla: https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported It might be possible to disable the use of SSE2 for the i386 architecture (as every CPU covered by amd64 supports SSE2), but I have no idea how intrusive that would be (and might cause some problems in the long term if the non-SSE2 code paths are not covered by upstream CI/tests). It's also one additional patch to be carried forward until i386 is retired as an architecture. Cheers, Moritz
Bug#908521: fakeupstream.cgi: new service to group node modules
Package: qa.debian.org Severity: wishlist Tags: patch Hi all, as explained in Thorsten mail (https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2018-September/027849.html), node modules may be embedded sometime. After a long discussion with other members (follow the thread), I built a CGI to build a version usable by uscan. You can find a complete example of this CGI usage: https://salsa.debian.org/js-team/node-mongodb/tree/groupedsources/debian Important points: * gbp.conf includes "components" * debian/watch declares the 3 sources using CGI To see the full diff, launch `git diff debian/3.1.1-1 groupedsources debian` in node-mongodb repository (note that d/copyright contains many changes due to version upgrade) Like fakeupstream.cgi, this CGI is stateless and builds redirection to packages on npmjs.com. I will push a merge request on salsa to propose it when I'll get a BTS number. NB: this CGI has been built to be installed separately but can easily be merged into fakeupstream.cgi. Cheers, Xavier -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#908520: firefox: Needs newer sqlite than what's listed in dependencies
Package: firefox Version: 62.0-1 Severity: normal Dear Maintainer, Firefox in unstable has dependency for sqlite3-0 (>=3.14.0). This version doesn't seem to be new enough. After upgrading Firefox from older version I got an notification saying that Firefox can't access bookmarks or address history due to places.sql being locked. After deleting the file I got the same notice again even though Firefox was able to re-create the file. Updating sqllite3 to version 3.24.0-1 fixed the issue and the original places.sqlite was working fine. -- Package-specific info: -- Addons package information -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (515, 'stable'), (510, 'testing'), (509, 'unstable'), (505, 'experimental'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages firefox depends on: ii debianutils 4.8.1.1 ii fontconfig2.11.0-6.7+b1 ii libatk1.0-0 2.22.0-1 ii libc6 2.27-5 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-6 ii libfontconfig12.12.6-0.1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-03.22.11-1 ii libjsoncpp1 1.7.4-3 ii libnspr4 2:4.12-6 ii libnss3 2:3.38-1 ii libpango-1.0-01.40.5-1 ii libsqlite3-0 3.24.0-1 ii libstartup-notification0 0.12-4+b2 ii libstdc++66.3.0-18+deb9u1 ii libvpx5 1.7.0-3 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb-shm0 1.12-1 ii libxcb1 1.12-1 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-2+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii procps2:3.3.12-3+deb9u1 ii zlib1g1:1.2.11.dfsg-1 Versions of packages firefox recommends: ii libavcodec53 6:0.8.20-0+deb7u1 ii libavcodec56 6:11.12-1~deb8u1 ii libavcodec57 7:3.2.12-1~deb9u1 Versions of packages firefox suggests: pn fonts-lmodern ii fonts-stix [otf-stix] 1.1.1-4 ii libcanberra0 0.30-3 ii libgssapi-krb5-2 1.15-1+deb9u1 ii libgtk2.0-02.24.31-2 -- no debconf information
Bug#620507: ITA: eterm -- Enlightened Terminal Emulator
Hi José, On Mon, Sep 10, 2018 at 1:36 PM Jose Antonio Jimenez Madrid wrote: > > retitle 620507 ITA: eterm -- Enlightened Terminal Emulator > owner 620507 ! > thanks > > > Hi, > > long time has passed since I tried to adopt this package. After reading > some documentation I think I am in good shape to > adopt this package by applying some patches to close several bugs. Please, feel free to take over Eterm. If you need any help to get it uploaded on Debian, just let me know. Best, -- Muammar El Khatib. Linux user: 403107. GPG Key = 71246E4A. http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `-
Bug#908519: linux: asciidoctor dependency blocks ia64 build
Source: linux Severity: normal User: debian-i...@lists.debian.org Usertags: ia64 Dear Maintainer, Due to some ruby issues, asciidoctor is currently blocking the linux package from building on ia64. Since asciidoctor is only used to build the linux-perf documentation, does it make more sense to: 1) move asciidoctor into the Build-Depends-Indep: section in the control file, or 2) flag asciidoctor as [!ia64]? I think #1 is the correct answer, but it's entirely possible my understanding of build dependencies is incomplete. Thanks, Jason -- System Information: Debian Release: buster/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: ia64 Kernel: Linux 4.18.0-1-mckinley (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#483811: [fam] fam segfaults
I experienced more core dumps, but haven't had time to examine them.
In particular, at a time I had three core dumps in a row on Jul 14:
-rw--- 1 ale staff 6180864 Jul 14 17:10
core_epoch=1531581032_pid=5409_file=!usr!sbin!famd
-rw--- 1 ale staff 9302016 Jul 14 17:09
core_epoch=1531580943_pid=5317_file=!usr!sbin!famd
-rw--- 1 ale staff 26234880 Jul 14 17:05
core_epoch=1531580714_pid=26593_file=!usr!sbin!famd
The first of these only run for 1 minute. The "closure" in
TCP_Client::unblock_handler (closure=0x295ca20) at TCP_Client.c++:270
is always a LocalClient with a bad to_be_scanned element. In the first (short)
dump, it had:
to_be_scanned = {
, std::allocator >> =
std::set with 251 elements = {
Elements 0 to 102 were bad memory pointers.
Elements 103 to 250 were entries of type DirEntry with a common parent
corresponding to
a courierimapkeywords directory of a Courier-MTA mail folder. The parent
had 1170
entries, and this batch matched entries 12 to 159 in the parent. Since
those file names
contain Unix epoch, I could check that most --not all-- of them were in
ascending order.
One file was listed twice, and was out of order.
Dates ranged from June to a few hours before crash.
}, }
Courier at times removes a bunch of those files and stores the corresponding
IMAP keywords
in a single ":list" file. I have to study the code better to understand how
parent and
clients can be notified of Interest* deletion. Maybe next month...
Bug#908475: d/p/debian/scsi-udev-rule no more needed?
On Mon, Sep 10, 2018 at 4:50 PM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:
> > So it seems these days the udev rules as provided upstream are good
>> > as-is and we could drop that.
>>
>> There was a bug report where the upstream were reported as buggy,
>> resulting in that patch.
>>
>> https://github.com/bzed/pkg-open-vm-tools/pull/10
>>
>>
>> So right now I can't see whats wrong with the current udev rules as
>> they work for me in wheezy/jessie/stretch/buster. Also I don't think
>> that running /bin/sh to set values in /sys is the appropriate way
>> if there is a way around that.
>>
>
> First of all thanks for your immediate answer.
>
> I wanted to quickly reply as well, but deploying my guest is blocked by so
> many things at the moment (mostly memory).
> I want to check on my own how it behaves in the Ubuntu version I got the
> report and if it is any different to Debian/sid.
>
Got hold of a system to test that.
You are absolutely right, the rules I assumed to be the same are not.
There seem to be three versions:
Upstream - work but echo??
ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="VMware*",
ATTRS{model}=="Virtual disk*", ENV{DEVTYPE}=="disk", RUN+="/bin/sh -c 'echo
180 >/sys$DEVPATH/device/timeout
'"
ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="VMware*",
ATTRS{model}=="VMware Virtual S", ENV{DEVTYPE}=="disk", RUN+="/bin/sh -c
'echo 180 >/sys$DEVPATH/device/time
out'"
Debian - work and look nice
ACTION=="add", SUBSYSTEMS=="scsi", ENV{DEVTYPE}=="scsi_device",
ATTRS{vendor}=="VMware*" , ATTRS{model}=="Virtual disk*",
ATTRS{timeout}=="?*", ATTR{timeout}="180"
ACTION=="add", SUBSYSTEMS=="scsi", ENV{DEVTYPE}=="scsi_device",
ATTRS{vendor}=="VMware*" , ATTRS{model}=="VMware Virtual S",
ATTRS{timeout}=="?*", ATTR{timeout}="180"
Ubuntu - don't work
ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="VMware*",
ATTRS{model}=="Virtual disk*", ENV{DEVTYPE}=="disk", ATTR{timeout}="180"
ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="VMware*",
ATTRS{model}=="VMware Virtual S", ENV{DEVTYPE}=="disk", ATTR{timeout}="180"
I need to sort out from where ours are, but they surely are our fault that
I need to sort out.
But it is too late for that today :-)
Sorry for the noise and thank you.
Closing the bug.
Given this takes much longer than it should I wanted to let you know that
> I'll report back here what I find as soon as it works.
>
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
Bug#908517: pushover: crashes due to missing dep on fonts-freefont-ttf
Package: pushover Version: 0.0.5+git20180909-1 Severity: normal (Reporting on the version that's stuck in NEW, no idea if it applies to the old one too.) If fonts-freefont-ttf is not installed, pushover segfaults on startup. Thus, please add the dependency. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.7+ (SMP w/6 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages pushover depends on: ii libboost-filesystem1.62.0 1.62.0+dfsg-8 ii libboost-system1.62.0 1.62.0+dfsg-8 ii libc6 2.27-6 ii libfribidi01.0.5-3 ii libgcc11:8.2.0-6 ii liblua5.3-05.3.3-1 ii libpng16-161.6.34-2 ii libsdl-mixer1.21.2.12-14 ii libsdl-ttf2.0-02.0.11-4 ii libsdl1.2debian1.2.15+dfsg2-1 ii libstdc++6 8.2.0-6 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages pushover recommends: ii pushover-data 0.0.5+git20180909-1 pushover suggests no packages. -- no debconf information
Bug#908518: sicherboot: avoid uuid-runtime dependency by using kernel directly
Package: sicherboot
Version: 0.1.5
Severity: wishlist
Tags: patch
Hi. Something I've been meaning to suggest for some time: avoid the
dependency on uuid-runtime by using /proc/sys/kernel/random/uuid instead
of uuidgen. Patch attached.
--
https://rjy.org.uk/
>From 9b9eda0672a0a75120c7e3d5fc27bc13bc117337 Mon Sep 17 00:00:00 2001
From: RjY
Date: Mon, 10 Sep 2018 18:21:42 +0100
Subject: [PATCH] Obtain random uuid from /proc/sys, remove uuid-runtime
dependency
Avoid the dependency on uuid-runtime by asking the kernel for a random
UUID via the /proc/sys/kernel/random interface. uuidgen and uuidd are
excessive unless time-based UUIDs are required in abundance, while
sicherboot needs only a single random UUID created at initial setup.
(We may assume the /proc/sys interface always exists, as sicherboot is
less useful on non-Linux kernels due to its hard dependency on systemd.)
---
debian/control | 2 +-
shippable.yml | 2 +-
sicherboot | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index dad6226..b572ec2 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Vcs-Browser: https://github.com/julian-klode/sicherboot
Package: sicherboot
Architecture: all
-Depends: ${misc:Depends}, ${shlibs:Depends}, efitools, binutils, systemd, uuid-runtime
+Depends: ${misc:Depends}, ${shlibs:Depends}, efitools, binutils, systemd
Enhances: dracut, systemd, initramfs-tools
Description: systemd-boot integration with UEFI secure boot support
sicher*boot manages kernels and systemd-boot on a secure boot
diff --git a/shippable.yml b/shippable.yml
index 176f9b6..81aafbe 100644
--- a/shippable.yml
+++ b/shippable.yml
@@ -7,5 +7,5 @@ build:
pull: true
ci:
- touch /etc/kernel/cmdline
-- apt-get install -y -qq efitools binutils systemd fakeroot uuid-runtime
+- apt-get install -y -qq efitools binutils systemd fakeroot
- run-parts -v tests
diff --git a/sicherboot b/sicherboot
index 8b47b4a..7a8617f 100755
--- a/sicherboot
+++ b/sicherboot
@@ -205,7 +205,7 @@ generate_keys() {
chown root:root "${KEY_HOME}"
chmod 700 "${KEY_HOME}"
cd "${KEY_HOME}"
-uuidgen > "${KEY_HOME}/uuid"
+cat /proc/sys/kernel/random/uuid > "${KEY_HOME}/uuid"
_generate_key PK PK
_generate_key KEK PK
_generate_key db KEK
--
2.19.0.rc2
Bug#908072: diffoscope: `bin/diffoscope --list-debian-substvars` output depends on installed packages
tags 908072 + pending
thanks
Fixed in Git, pending upload:
https://salsa.debian.org/reproducible-builds/diffoscope/commit/889e4bf7394d465ae2c9a17a0661bb401c30f54a
diffoscope/main.py | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
I didn't go with the:
- import rpm
+ try:
+import rpm
+ except ImportError:
+tool_required.all.add('rpm2cpio') # lol hack
+ raise
… solution as, for example, we were not importing changes.py (and thus
calling @tool_required('gpg')) but this was only due to not importing
the enhanced Debian comparator in debian.py so this would have been
somewhat too distant of an action.
This solution also allows for a big stonkin' comment regarding this
ugliness.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
Bug#908513: libreoffice - missing gallery when Dmaths is installed
tag 908513 + moreinfo thanks On Mon, Sep 10, 2018 at 07:05:55PM +0200, Hans-J. Ullrich wrote: > I think there is a litttle issue with the gallery in libreoffice. Why in LibreOffice? > If the libreoffice-dmaths package is installed, then I can gent no access to > the libreoffice-gallery. > (Clicking on the "Gallery"-icon showes me the dmaths gallery). > > When libreoffice-dmaths is uninstralled, then the gallery (all pictures and > so on) are appearng again. > I looked into the settings of libreoffice and searched at Google and others, > but could not find a solution, > how to set the gallery-path to the "normal" gallery withj installed dmaths. > > I believe, this is a bug. If I am wrong, please point me to the right > settings. But that sounds like a dmaths bug? Maybe it needs to be adapted to LO 6.1? I at least see many oor:op="replace" in dmaths? Maybe it is replacing too much of LOs orginal gallery "config"? dmaths is a separate extension. CC'ing the dmaths maintainer. Regards, Rene
Bug#868050: RFS: golang-github-shibukawa-configdir -- Configuration directories handling for Go
On Sun, Sep 9, 2018 at 6:20 PM Paride Legovini wrote: > I fixed the ITP, changed the release distribution back to UNSTABLE, > pushed these changed to salsa, and deleted the release tag on my local > copy of the repository. I don't have the permissions to delete the tag > on salsa: you will have to do so. As you are there, you could also > delete the following tag: > > upstream/0.0_git20170330.0.e180dbd > > which is not used and was already there when I took up the packaging. > Forget to say, I've uploaded and deleted the tags. https://ftp-master.debian.org/new/golang-github-shibukawa-configdir_0.0~git20170330.e180dbd-1.html -- Shengjing Zhu
Bug#908516: Apparmor profile breaks print preview
Package: evince
Version: 3.30.0-2
Severity: normal
The apparmor profile installed by evince breaks the print preview
functionality by blocking access to gio-launch-desktop. Adding the
following line to /etc/apparmor.d/usr.bin.evince seems to fix the issue,
though you should probably consult apparmor.d(5) and pick something more
sensible that "uxr" as a permission:
/usr/lib/@{multiarch}/glib-2.0/gio-launch-desktop uxr,
Best wishes,
Ryan
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_CA.UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to en_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages evince depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.30.0-1
ii evince-common3.30.0-2
ii gsettings-desktop-schemas3.28.0-1
ii libatk1.0-0 2.30.0-1
ii libc62.27-6
ii libcairo-gobject21.15.12-1
ii libcairo21.15.12-1
ii libevdocument3-4 3.30.0-2
ii libevview3-3 3.30.0-2
ii libgdk-pixbuf2.0-0 2.38.0+dfsg-4
ii libglib2.0-0 2.58.0-3
ii libgnome-desktop-3-173.30.0-1
ii libgtk-3-0 3.24.0-2
ii libnautilus-extension1a 3.30.0-2
ii libpango-1.0-0 1.42.4-3
ii libpangocairo-1.0-0 1.42.4-3
ii libsecret-1-00.18.6-2
ii shared-mime-info 1.9-2
Versions of packages evince recommends:
ii dbus-user-session [default-dbus-session-bus] 1.12.10-1
ii dbus-x11 [dbus-session-bus] 1.12.10-1
Versions of packages evince suggests:
ii gvfs 1.36.2-1
pn nautilus-sendto
ii poppler-data 0.4.9-2
ii unrar1:5.5.8-1
-- Configuration Files:
/etc/apparmor.d/usr.bin.evince changed:
/usr/bin/evince {
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
# Terminals for using console applications. These abstractions should ideally
# have 'ix' to restrict access to what only evince is allowed to do
#include
# By default, we won't support launching a terminal program in Xterm or
# KDE's konsole. It opens up too many unnecessary files for most users.
# People who need this functionality can uncomment the following:
##include
##include
/usr/bin/evince rmPx,
/usr/bin/evince-previewer Px,
/usr/bin/yelp Cx -> sanitized_helper,
/usr/bin/bug-buddy px,
# 'Show Containing Folder' (LP: #1022962)
/usr/bin/nautilus Cx -> sanitized_helper, # Gnome
/usr/bin/pcmanfm Cx -> sanitized_helper, # LXDE
/usr/bin/krusader Cx -> sanitized_helper, # KDE
/usr/bin/thunar Cx -> sanitized_helper, # XFCE
# For Xubuntu to launch the browser
/usr/bin/exo-open ixr,
/usr/lib/@{multiarch}/xfce4/exo-1/exo-helper-1 ixr,
/etc/xdg/xdg-xubuntu/xfce4/helpers.rc r,
/etc/xdg/xfce4/helpers.rc r,
# For text attachments
/usr/bin/gedit ixr,
/usr/lib/@{multiarch}/glib-2.0/gio-launch-desktop uxr,
# For Send to
/usr/bin/nautilus-sendto Cx -> sanitized_helper,
# allow directory listings (ie 'r' on directories) so browsing via the file
# dialog works
/ r,
/**/ r,
# This is need for saving files in your home directory without an extension.
# Changing this to '@{HOME}/** r' makes it require an extension and more
# secure (but with 'rw', we still have abstractions/private-files-strict in
# effect).
owner @{HOME}/** rw,
owner /media/** rw,
owner @{HOME}/.local/share/gvfs-metadata/** l,
owner /{,var/}run/user/*/gvfs-metadata/** l,
owner @{HOME}/.gnome2/evince/* rwl,
owner @{HOME}/.gnome2/accels/rw,
owner @{HOME}/.gnome2/accelsevince rw,
owner @{HOME}/.gnome2/accels/evince rw,
# Maybe add to an abstraction?
/etc/dconf/** r,
owner @{HOME}/.cache/dconf/user rw,
owner @{HOME}/.config/dconf/userr,
owner /{,var/}run/user/*/dconf/ w,
owner /{,var/}run/user/*/dconf/user rw,
owner /{,var/}run/user/*/dconf-service/keyfile/ w,
owner /{,var/}run/user/*/dconf-service/keyfile/user rw,
owner /{,var/}run/user/*/at-spi2-*/ rw,
owner /{,var/}run/user/*/at-spi2-*/** rw,
Bug#908503: libopenmp-dev: missing Breaks+Replaces
Same issue down here. -- *James John*
Bug#908515: urwid interface can't call PAGER and crashes due to AttributeError
Package: reportbug Version: 7.5.0 Severity: normal Tags: upstream When trying to display changes in configuration files using the urwid interface, reportbug exits with: Getting changed configuration files... Traceback (most recent call last): File "/usr/bin/reportbug", line 2266, in main() File "/usr/bin/reportbug", line 1109, in main return iface.user_interface() File "/usr/bin/reportbug", line 1831, in user_interface ui.system(PAGER + ' ' + ' '.join(changed)) AttributeError: module 'reportbug.ui.urwid_ui' has no attribute 'system' -- Package-specific info: ** Environment settings: EDITOR="vim" PAGER="less" DEBEMAIL="r...@debian.org" EMAIL="r...@debian.org" DEBFULLNAME="Ryan Kavanagh" NAME="Ryan Kavanagh" INTERFACE="urwid" ** /home/rak/.reportbugrc: reportbug_version "4.12.6" mode expert ui urwid realname "Ryan Kavanagh" email "r...@debian.org" no-cc header "X-Debbugs-CC: r...@debian.org" smtphost reportbug.debian.org keyid 4A11C97A sign gpg mutt -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reportbug depends on: ii apt1.6.4 ii python33.6.6-1 ii python3-reportbug 7.5.0 ii sensible-utils 0.0.12 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils ii debsums 2.2.3 ii dlocate 1.07+nmu1 ii emacs24-bin-common24.5+1-11 ii emacs25-bin-common25.2+1-6+b3 ii file 1:5.34-2 ii gnupg 2.2.10-1 ii opensmtpd [mail-transport-agent] 6.0.3p1-4 ii pgpgpg [pgp] 0.13-9.1+b1 ii python3-urwid 2.0.1-2+b1 pn reportbug-gtk ii xdg-utils 1.1.3-1 Versions of packages python3-reportbug depends on: ii apt1.6.4 ii file 1:5.34-2 ii python33.6.6-1 ii python3-apt1.6.2 ii python3-debian 0.1.33 ii python3-debianbts 2.7.2 ii python3-requests 2.18.4-2 python3-reportbug suggests no packages. -- no debconf information -- |)|/ Ryan Kavanagh | GPG: 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A signature.asc Description: PGP signature
Bug#908514: libnet-snmp-perl: Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Net/SNMP.pm line 2620
Package: libnet-snmp-perl
Version: 6.0.1-2
Severity: normal
Tags: patch upstream
-- System Information:
Debian Release: 9.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
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 libnet-snmp-perl depends on:
ii perl 5.24.1-3+deb9u4
libnet-snmp-perl recommends no packages.
Versions of packages libnet-snmp-perl suggests:
pn libcrypt-des-perl
ii libdigest-hmac-perl 1.03+dfsg-1
ii libio-socket-inet6-perl 2.72-2
Hi,
I have a script that uses SNMP.pm to connect to a device via snmp v3. While
executing the `open` sub there occures the following error due to a missing
check if a variable is defined before it is used:
```
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Net/SNMP.pm line 2620.
CRITICAL - cannot create session object: Time synchronization failed during
discovery
```
The variable `$this->{_error}` at this line is undefined but is beeing access
by `$this->{_error} =~ /usmStatsNotInTimeWindows/`. The following patch fixes
this problem by first checking if any error occured (`$this->{_error}` is
defined) and only then compares its values:
```
# diff -U 3 SNMP.pm.old SNMP.pm
--- SNMP.pm.old 2018-09-10 19:19:39.200267652 +0200
+++ SNMP.pm 2018-09-10 19:18:55.449787618 +0200
@@ -2618,7 +2618,7 @@
# assume that the synchronization has failed.
if (($this->{_security}->discovered()) &&
- ($this->{_error} =~ /usmStatsNotInTimeWindows/))
+ ((!$this->{_error}) || $this->{_error} =~ /usmStatsNotInTimeWindows/ ))
{
$this->_error_clear();
DEBUG_INFO('discovery and synchronization complete');
```
Bug#908503: (no subject)
Same issue down here. -- *James John*
Bug#883241: chrony: daemon doesn't automatically start
On Sun, 7 Jan 2018 17:53:29 +0100 Vincent Blut wrote: > > After reading the bug report again, I notice that I did not ask you to > disable systemd-timesyncd. So could you please run “systemctl disable > systemd-timesyncd” and report chronyd’s status after rebooting? FWIW, I had the same problem (on an up-to-date Strech machine) and disabling the systemd-timesyncd service seems to have fixed it, chronyd starts up fine now. HTH, -- Mikael
Bug#891778: zatacka crashes on map selection
Hello,
tried to reproduce this crash in a Stretch amd64 VM.
It wants to open the directory "maps":
benutzer@debian:~$ strace -f zatacka 2>&1 | grep maps
open("maps", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
Therefore a null pointer is handed to readdir.
Until 0.1.8-2 this directory got created and the file map1.jpg installed as
maps1.jpg:
--- 0.1.8-2/zatacka-0.1.8/debian/rules 2018-09-10 18:43:42.0 +0200
+++ 0.1.8-3/zatacka-0.1.8/debian/rules 2013-05-02 17:03:14.0 +0200
...
- install -m 0644 maps/map1.jpg
$(CURDIR)/debian/zatacka/usr/share/zatacka/maps/maps1.jpg
Since 0.1.8-3 the package does not contain the whole directory.
Yet the file map1.jpg is conatined as map1.jpg, but the application
tries to open a directory "maps".
Kind regards,
Bernhard
From 657b33ad80500229998592916a1b371be48b6891 Mon Sep 17 00:00:00 2001
From: Bernhard Ãbelacker
Date: Mon, 10 Sep 2018 19:06:55 +0200
Subject: [PATCH] Install maps/maps1.jpg
Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891778
---
Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index 45b28ba..2931caa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -10,10 +10,11 @@ LICENSE
install-data-local:
@$(PRE_INSTALL)
- $(mkinstalldirs) $(DESTDIR)$(DEFAULT_LIBDIR)/$(PACKAGE); \
+ $(mkinstalldirs) $(DESTDIR)$(DEFAULT_LIBDIR)/$(PACKAGE)/maps; \
$(INSTALL_DATA) $(srcdir)/img/main_screen.jpg $(DESTDIR)$(DEFAULT_LIBDIR)/$(PACKAGE); \
$(INSTALL_DATA) $(srcdir)/img/barrier.jpg $(DESTDIR)$(DEFAULT_LIBDIR)/$(PACKAGE); \
$(INSTALL_DATA) $(srcdir)/maps/map1.jpg $(DESTDIR)$(DEFAULT_LIBDIR)/$(PACKAGE);
+ $(INSTALL_DATA) $(srcdir)/maps/map1.jpg $(DESTDIR)$(DEFAULT_LIBDIR)/$(PACKAGE)/maps/maps1.jpg;
uninstall-local:
rm -rf $(DEFAULT_LIBDIR)/zatacka/*
--
2.11.0
apt install xserver-xorg sddm openbox xterm mc dpkg-dev devscripts colordiff
gdb zatacka zatacka-dbgsym libsdl-ttf2.0-0-dbgsym
apt build-dep zatacka
systemctl start sddm
mkdir zatacka/orig -p
cdzatacka/orig
apt source zatacka
cd ../..
export DISPLAY=:0
$ zatacka
Speicherzugriffsfehler
benutzer@debian:~$ gdb -q --args zatacka
Reading symbols from zatacka...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/games/zatacka
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x76da8a82 in __readdir (dirp=0x0) at ../sysdeps/posix/readdir.c:44
44 ../sysdeps/posix/readdir.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0 0x76da8a82 in __readdir (dirp=0x0) at ../sysdeps/posix/readdir.c:44
#1 0x75dc in ?? ()
#2 0x5700 in main ()
(gdb)
benutzer@debian:~$ gdb -q --args zatacka
Reading symbols from zatacka...Reading symbols from
/usr/lib/debug/.build-id/53/5cb8e1b018c227f6540c2ec464eb78aa5b4c67.debug...done.
done.
(gdb) set height 0
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/zatacka/orig/zatacka-0.1.8/src
Source directories searched:
/home/benutzer/zatacka/orig/zatacka-0.1.8/src:$cdir:$cwd
(gdb) run
Starting program: /usr/games/zatacka
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x76da8a82 in __readdir (dirp=dirp@entry=0x0) at
../sysdeps/posix/readdir.c:44
44 ../sysdeps/posix/readdir.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0 0x76da8a82 in __readdir (dirp=dirp@entry=0x0) at
../sysdeps/posix/readdir.c:44
#1 0x75dc in menu (screen=0x557a8f20) at fx.cpp:425
#2 0x5700 in main (argc=, argv=) at
main.cpp:40
(gdb) list menu
293
294 bool menu(SDL_Surface *screen){
306 DIR *dir;
339 dir=opendir("maps"); //open maps directory
340 while(!quit){
341 SDL_Delay(1); //don't use 100% cpu
342 while(SDL_PollEvent()){
343 switch(event.type){
354 case SDL_KEYDOWN:
355 if(lineno==0){ //if I
am not catching keys for some line
356 switch(event.key.keysym.sym){
//I am catching control keys
424 case SDLK_m:
425 if(NULL ==
(dent=readdir(dir))) { //if I am at the end of directory list
426
rewinddir(dir); //return to beginning
427
strcpy(bgpath,"none"); //in the end of list is none background
428
Bug#908512: Docked apps icons appear broken (with a standard icon)
Package: wmaker Version: 0.95.8-2 Severity: normal Docked apps icons appear broken (with a standard icon), these are GNUstep applications as well as non-GNUstep applications. And the following GNUstep applications (once the apps are launched, an icon appears). but for TalkSoup.app, VolumeControl.app, and TextEdit.app they are not 64x64, more like 32x32... Best,
Bug#908513: libreoffice - missing gallery when Dmaths is installed
Package: libreoffice Version: 1:6.1.1~rc1-2 Severity: normal Dear Maintainer, I think there is a litttle issue with the gallery in libreoffice. If the libreoffice-dmaths package is installed, then I can gent no access to the libreoffice-gallery. (Clicking on the "Gallery"-icon showes me the dmaths gallery). When libreoffice-dmaths is uninstralled, then the gallery (all pictures and so on) are appearng again. I looked into the settings of libreoffice and searched at Google and others, but could not find a solution, how to set the gallery-path to the "normal" gallery withj installed dmaths. I believe, this is a bug. If I am wrong, please point me to the right settings. Thanks for reading this and your help. Best regards Hans -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.17.0-3-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libreoffice depends on: ii libreoffice-avmedia-backend-gstreamer 1:6.1.1~rc1-2 ii libreoffice-avmedia-backend-vlc1:6.1.1~rc1-2 ii libreoffice-base 1:6.1.1~rc1-2 ii libreoffice-calc 1:6.1.1~rc1-2 ii libreoffice-core 1:6.1.1~rc1-2 ii libreoffice-draw 1:6.1.1~rc1-2 ii libreoffice-impress1:6.1.1~rc1-2 ii libreoffice-math 1:6.1.1~rc1-2 ii libreoffice-report-builder-bin 1:6.1.1~rc1-2 ii libreoffice-writer 1:6.1.1~rc1-2 ii python3-uno1:6.1.1~rc1-2 Versions of packages libreoffice recommends: ii fonts-crosextra-caladea 20130214-2 ii fonts-crosextra-carlito 20130920-1 ii fonts-dejavu2.37-1 ii fonts-liberation1:1.07.4-7 ii fonts-liberation2 2.00.1-7 pn fonts-linuxlibertine ii fonts-noto-hinted 20171026-2 ii fonts-noto-mono 20171026-2 ii fonts-sil-gentium-basic 1.102-1 ii libreoffice-java-common 1:6.1.1~rc1-2 ii libreoffice-librelogo 1:6.1.1~rc1-2 ii libreoffice-nlpsolver 0.9+LibO6.1.1~rc1-2 ii libreoffice-ogltrans1:6.1.1~rc1-2 ii libreoffice-report-builder 1:6.1.1~rc1-2 ii libreoffice-script-provider-bsh 1:6.1.1~rc1-2 pn libreoffice-script-provider-js ii libreoffice-script-provider-python 1:6.1.1~rc1-2 ii libreoffice-sdbc-postgresql 1:6.1.1~rc1-2 ii libreoffice-wiki-publisher 1.2.0+LibO6.1.1~rc1-2 Versions of packages libreoffice suggests: ii cups-bsd 2.2.8-5 ii firefox-esr 60.2.0esr-1~deb9u2 ii ghostscript 9.22~dfsg-2.1 ii gnupg2.2.10-1 pn gpa ii gstreamer1.0-libav 1.15.0.1+git20180723+db823502-1 ii gstreamer1.0-plugins-bad 1.14.2-1 ii gstreamer1.0-plugins-base1.14.2-1 ii gstreamer1.0-plugins-good1.14.2-1 ii gstreamer1.0-plugins-ugly1.14.2-1 ii hunspell-de-at [hunspell-dictionary] 20161207-5 ii hunspell-de-ch [hunspell-dictionary] 20161207-5 ii hunspell-de-de [hunspell-dictionary] 20161207-5 ii hyphen-de [hyphen-hyphenation-patterns] 1:6.1.0~rc2-2 ii imagemagick 8:6.9.10.8+dfsg-1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.8+dfsg-1 pn libgl1 pn libreoffice-grammarcheck pn libreoffice-help ii libreoffice-kde5 1:6.1.1~rc1-2 pn libreoffice-l10n pn libreoffice-officebean pn libsane1 ii libxrender1 1:0.9.10-1 pn myspell-dictionary ii mythes-de [mythes-thesaurus] 20160424-3 ii openclipart-libreoffice 1:0.18+dfsg-14 ii openjdk-8-jre8u181-b13-1~deb9u1 ii pstoedit 3.73-1+b1 ii thunderbird 1:52.9.1-1 ii unixodbc 2.3.6-0.1 Versions of packages libreoffice-core depends on: ii fontconfig2.13.0-5 ii fonts-opensymbol 2:102.10+LibO6.1.1~rc1-2 ii libboost-date-time1.62.0 1.62.0+dfsg-8 ii libboost-locale1.62.0 1.62.0+dfsg-8 ii libc6 2.27-5 ii libcairo2 1.15.12-1 ii libclucene-contribs1v52.3.3.4+dfsg-1 ii libclucene-core1v52.3.3.4+dfsg-1 ii
Bug#620507: ITA: eterm -- Enlightened Terminal Emulator
retitle 620507 ITA: eterm -- Enlightened Terminal Emulator owner 620507 ! thanks Hi, long time has passed since I tried to adopt this package. After reading some documentation I think I am in good shape to adopt this package by applying some patches to close several bugs. Regards, Jose
Bug#908506: gio-launch-desktop exits with exit code 255
Control: tags -1 + moreinfo On Mon, 10 Sep 2018 at 11:57:32 -0400, Ryan Kavanagh wrote: > gio-launch-desktop immediately exits with exit code 255. How was it invoked? (Please strace the parent process if necessary.) I can run, for example /usr/lib/x86_64-linux-gnu/glib-2.0/gio-launch-desktop gnome-calculator and it works. However, /usr/lib/x86_64-linux-gnu/glib-2.0/gio-launch-desktop nonexistent exits 255 with no diagnostics (and looking at the source code, any other failure mode will also exit 255 with no diagnostics). smcv
Bug#903444: diffoscope: FileNotFoundError: [Errno 2] No such file or directory: '/home/lamby/.binwalk/magic' with gfxboot/4.5.2-1.1-6
On Mon, Sep 10, 2018 at 06:06:47PM +0100, Chris Lamb wrote: > tags 903444 + pending > thanks > > Fixed in Git, pending upload: > > > https://salsa.debian.org/reproducible-builds/diffoscope/commit/075acf2f8c599e0f53463fee368a1a929e94a8eb .oO wow That's a crazy one, thanks for tracking this down! -- 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
