Bug#917807: libcaca: CVE-2018-20544 CVE-2018-20545 CVE-2018-20546 CVE-2018-20547 CVE-2018-20548 CVE-2018-20549
Hi nicoo, On Mon, Mar 11, 2019 at 12:34:56AM +0100, Nicolas Braud-Santoni wrote: > clone 917807 -1 > retitle -1 Orphan libcaca > severity -1 normal > thanks > > > Hi Sam, > > I'm planning on fixing those security issues for Buster. > > Given that you last touched the package in 2014, and didn't address this > critical > bug within 3 months, may I go ahead and orphan the package while I'm at it? > > I will do so in the absence of an answer, but I shall make sure that my upload > is delayed until at least next Monday (2019-03-18), so you have time to > intercept it. Not the maintainer hiere, so disclaimer. When fixing the isuse just make sure to cherry-pick all needed changes, as far I remember there were for some of the upstream bugs iterations on the commits. Notabene: Upstream is same as Debian maintainer, so Sam might give you the needed input! Regards, Salvatore
Bug#924066: calibre: new calibre 3.40.1
Hi Jonatan, > Please consider to upgrade to the current upstream version of calibre > (3.40.1). I uploaded 3.40.1 to experimental - this kind of code change cannot enter now that we are near freeze. Thanks for the reminder Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#895378: sky2: sky2: did not recover correctly after waking up from S3
I have the same issue with the current Debian Buster kernel using an Acer Aspire 5930G both with suspension and the hibernation; I'm using the following kernel: $uname -a Linux debian 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 (2019-01-17) x86_64 GNU/Linux After suspension or hibernation, the network connection is not re-established with a NO-CARRIER error. A first work-around is to unload and reload the sky2 kernel driver with the folllowing commands: modprobe -r sky2 modprobe sky2 It seems a kernel bug and it is discussed, for example, in this Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798921 In this message (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798921/comments/28) the author suggests (on Debian) to start the kernel with the following parameters to work-around the bug: pci=nomsi,noaer I have tried and it works.
Bug#924292: btrfs-compsize FTCBFS: does not pass cross tools to make
Source: btrfs-compsize Version: 1.3-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap btrfs-compsize fails to cross build from source, because it does not pass cross tools to make. The easiest way of fixing that - using dh_auto_build - makes btrfs-compsize cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru btrfs-compsize-1.3/debian/changelog btrfs-compsize-1.3/debian/changelog --- btrfs-compsize-1.3/debian/changelog 2019-02-26 13:35:44.0 +0100 +++ btrfs-compsize-1.3/debian/changelog 2019-03-11 06:23:29.0 +0100 @@ -1,3 +1,10 @@ +btrfs-compsize (1.3-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Mon, 11 Mar 2019 06:23:29 +0100 + btrfs-compsize (1.3-1) unstable; urgency=medium * New upstream release. diff --minimal -Nru btrfs-compsize-1.3/debian/rules btrfs-compsize-1.3/debian/rules --- btrfs-compsize-1.3/debian/rules 2018-06-02 19:03:38.0 +0200 +++ btrfs-compsize-1.3/debian/rules 2019-03-11 06:23:28.0 +0100 @@ -5,6 +5,6 @@ dh $@ override_dh_auto_build: - +$(MAKE) $(shell dpkg-buildflags --export=cmdline) + dh_auto_build -- $(shell dpkg-buildflags --export=cmdline) override_dh_auto_install:
Bug#924291: netrek-client-cow: build can loop indefinitely on failure
Source: netrek-client-cow Version: 3.3.1-1 Severity: serious Justification: breaks build infrastructure When mkkey fails to run, netrek-client-cow has a very bad failure mode. It loops until mkkey succeeds: | until ./mkkey key.cow.linux "Client Of Win" "automatic packaged key" "qu...@us.netrek.org" "netrek.org/files/COW/" "inl,standard2"; do sleep 1; done When mkkey fails reliably and produces output, this causes the build to run indefinitely as sbuild only abort a build that has no output for a prologned time. This behaviour can make buildds and QA infrastructure hang. I suggest using a bounded loop and failing hard after a number of attempts. That's a very simple solution to the problem at hand. For instance: | attempts=32; until ./mkkey ...; do attempts=$((attempts - 1)); test $attempts -le 0 && exit 1; sleep 1; done Furthermore I question why a key should be created at build time and then be distributed to consumers of the package. That seems to run counter to the concept of a "key". If the key is to protect anything, it must not be public. Maybe the best course of action would be not creating this key at all during build. Helmut
Bug#924290: [rfc] information about EFI partitions
Package: installation-guide
Version: 20180930
Severity: wishlist
Tags: patch
Hi
recently I was learning about presseding UEFI installs and
I think the install guide could use a small addition to make
that journey easier. I also sent a patch to partman-auto-recipe.txt
but I am sure the readership of that is much less than the d-i manual.
Kind regards
Vince
From 4697c54b3f61bc145980f52206bb20e2280c0a63 Mon Sep 17 00:00:00 2001
From: Vincent McIntyre
Date: Mon, 11 Mar 2019 15:38:19 +1100
Subject: [RFC PATCH] Add some information about preseeding EFI partitions
---
en/appendix/preseed.xml | 17 +
1 file changed, 17 insertions(+)
diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
index c55860e34..9e334738a 100644
--- a/en/appendix/preseed.xml
+++ b/en/appendix/preseed.xml
@@ -1211,6 +1211,20 @@ d-i partman-auto/choose_recipe select atomic
# system labels, volume group names and which physical devices to include
# in a volume group.
+## Partitioning for EFI
+# If your system needs an EFI partition you could add something like
+# this to the recipe above, as the first element in the recipe:
+# 538 538 1075 free \
+# $iflabel{ gpt } \
+# $reusemethod{ } \
+# method{ efi } \
+# format{ } \
+# . \
+#
+# The fragment above is for the amd64 architecture; the details may be
+# different on other architectures. The 'partman-auto' package in the
+# D-I source repository may have an example you can follow.
+
# This makes partman automatically partition without confirmation, provided
# that you told it what to do using one of the methods above.
d-i partman-partitioning/confirm_write_new_label boolean true
@@ -1218,6 +1232,9 @@ d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
+# Force UEFI booting ('BIOS compatibility' will be lost). Default: false.
+#d-i partman-efi/non_efi_system boolean true
+
# When disk encryption is enabled, skip wiping the partitions beforehand.
#d-i partman-auto-crypto/erase_disks boolean false
--
2.11.0
Bug#924270: O: keepassx -- Cross Platform Password Manager
On Mon, 2019-03-11 at 11:29 +0800, Shengjing Zhu wrote: > I'm also long-time user of keepassx. I was also a user of keepassx. Its bugs and continual crashes were a real annoyance, so I was always on the lookout for a more stable, 100% compatible replacement. I found one, or more accurately one arrived in Debian. keepassxc is fork of keepassx, is in buster and now also strech- backports, works fine with on the same files keepassx used, and hasn't crashed yet. There is no reason for anyone to be too concerned over the fate of keepassx. signature.asc Description: This is a digitally signed message part
Bug#924289: update EFI example in partman-auto-recipe.txt
Package: debian-installer
Version: 20190119
Severity: wishlist
Tags: patch
Hello
I recently spent some time working on getting EFI installs going.
It took rather a lot of digging to find out how to set up an EFI
partition in a partitioning recipe so I thought I would try to
make the documentation more accessible.
Please consider merging the attached patch.
Kind regards
Vince
From 7fb9450e3d1aacde6a32cb74e9f7a0cbfdd57831 Mon Sep 17 00:00:00 2001
From: Vincent McIntyre
Date: Mon, 11 Mar 2019 15:02:54 +1100
Subject: [PATCH] Update EFI example
Use a common architecture (amd64) in preference to an unsupported one.
Also, give an example of a path to a specific recipe within partman-auto.
---
doc/devel/partman-auto-recipe.txt | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/doc/devel/partman-auto-recipe.txt b/doc/devel/partman-auto-recipe.txt
index bc8b541c5..5bf64ba5f 100644
--- a/doc/devel/partman-auto-recipe.txt
+++ b/doc/devel/partman-auto-recipe.txt
@@ -259,15 +259,16 @@ formated in revision 0 ext2.
filesystem{ ext2r0 }
mountpoint{ /boot } .
-And finally, an example of how to set up the efi boot partition needed on
-ia64.
+Finally, an example of how to set up an efi boot partition on amd64.
-100 100 150 fat16
-$primary{ }
+538 538 1075 free
+$iflabel{ gpt }
+$reusemethod{ }
method{ efi }
format{ } .
For other examples, see the architecture-specific recipes in partman-auto.
+The EFI example above was taken from partman-auto/recipe-amd64-efi/atomic.
5. LIMITATIONS
--
2.11.0
Bug#754809: bugs.debian.org still broken regarding DKIM
On Mon, 11 Mar 2019, Marco d'Itri wrote: > On Mar 11, Matija Nalis wrote: > > > Has this issue ever has been dealt with for bugs.debian.org (as it > > seems to have been solved for lists.debian.org in forked #752084) ? > No: it is obvious that the messages relayed by the BTS are still > modified. Right; the only way forward for this is to completely stop rewriting the subject of messages sent to submit@ or nnn@ or implement resending. > > I can provide whole forensic report if required, or do tests. > The problem is quite clear, but the is no commitment from the BTS > maintainers to choose a solution and maybe implement it. I don't have time to implement either in the near term. My current longer term plan is to switch to resending messages and rewriting From. -- Don Armstrong https://www.donarmstrong.com The game of science is, in principle, without end. He who decides one day that scientific statements do not call for any further test, and that they can be regarded as finally verified, retires from the game. -- Sir Karl Popper _The Logic of Scientific Discovery_ §11
Bug#813055: done?
Hi I think this may have been handled? % git remote -v origin https://salsa.debian.org/installer-team/partman-auto.git (fetch) origin https://salsa.debian.org/installer-team/partman-auto.git (push) % git log --oneline recipes-amd64-efi/atomic 4d2966b Set minimimum size of / partition a5df6f5 Increase the EFI System Partition size slightly to ensure that it's at least 512MiB, not just 512MB. See LP #1306164. 4df3586 Add x86 UEFI support, merging some code from Ubuntu to help What I am unable to check at present is whether requesting an 'atomic' partitioning in the preseed file and UEFI netbooting automagically selects the recipe above. Cheers Vince
Bug#924270: O: keepassx -- Cross Platform Password Manager
Hi, On Mon, Mar 11, 2019 at 3:15 AM Reinhard Tartler wrote: > > Package: wnpp > Severity: normal > > Keepassx is a graphical password manager, using the Qt4 toolkit. I'm no > longer using this package and have personally switched to > 'password-store'. Unfortunately, I've also failed to get a response > from upstream from > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920616 - which > recommends to replace keepassx with keepassxc, a community fork, > possibly because of unresponsive upstream. > > I am undecided whether or not this package should be included in Debian > 10 (aka buster). It clearly is useful to many people, but its long-term > maintenance is unclear. > > I'd encourage people interested in picking up this package to coordinate > with Julian Klode (CC'ed), the Debian keepassxc maintainer. > I'm also long-time user of keepassx. I checked the upstream. In surprise, I found the master version has switched to Qt-5. And the upstream author is Felix Geyer, who is DD as well. Felix, could you have some inputs here? In person, I hope keepassx is in buster. I can help uploading the master version(with Qt-5) if Qt-4 is really needed to be removed from buster. However I'm unsure if RT is fine with this big change(I assume it's not ok). -- Shengjing Zhu
Bug#919833: 90% of shell scripts probably don't have a .sh extension
On Sun, Jan 20 2019, 積丹尼 Dan Jacobson wrote: > Package: bash-completion > Version: 1:2.8-5 > Severity: wishlist > File: /usr/share/bash-completion/completions/sh > > I think 90% of shell scripts don't have a .sh extension. > Therefore > $ sh anyf > should still complete to > $ sh anyfile You could be right (specially since bash completes any filename), however, where did you get this statistic from?
Bug#924192: ntpsec: at boot ntpsec starts before DNS is available
On Sun, Mar 10, 2019 at 01:11:46AM -0800, Rick Thomas wrote: > Package: ntpsec > Version: 1.1.3+dfsg1-2 > Severity: important > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > the /etc/ntpsec/ntp.conf file (attached) has two "pool" directives and no > "server" directives. > So it requires DNS (hence network services) to find out the IP addresses it > needs for servers. > DNS fails on the first "peer" and (for some reason) succeeds on the second > "peer". > If ntpsec implemented the "preempt" option on "peer" directives, the first > "peer" would be > revisited after a few minutes and all would be well. But it doesn't. So the > first "peer" > is as if it never existed. >* What exactly did you do (or not do) that was effective (or ineffective)? > Wait several seconds after boot completes then issue "sudo service ntpset > restart" >* What was the outcome of this action? > This time around, it sees both sets of "peers". >* What outcome did you expect instead? > I would have hoped that the systemd stuff would wait until DNS was available > before starting up ntpsec. > Unfortunately, I don't know systemd configuration well enough to suggest a > patch. Hi Rick, Reading through the systemd network.target documentation here [1] (but also being somewhat new to it myself), I wonder if the behavior would work for your case if the Debian package changed: WantedBy=network-pre.target to After=network-online.target Wants=network-online.target in the unit file [2]. Would you be willing to test with that configuration? Thank you, tony [1] https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ [2] https://github.com/rlaager/ntpsec-pkg/blob/sid/debian/ntpsec-systemd-netif.path#L9 signature.asc Description: PGP signature
Bug#924279: sbuild-debian-developer-setup fails within docker
Quoting Tong Sun (2019-03-10 23:57:17) > When I run sbuild-debian-developer-setup within docker, this is what I'll get: > > root/# sbuild-debian-developer-setup > Please run sudo /usr/bin/sbuild-debian-developer-setup at > /usr/bin/sbuild-debian-developer-setup line 40. > root/# /usr/bin/sbuild-debian-developer-setup > Please run sudo /usr/bin/sbuild-debian-developer-setup at > /usr/bin/sbuild-debian-developer-setup line 40. > > A quick web search reveals that sbuild-debian-developer-setup has been > working within docker before so please consider fixing it. did you consider following the instruction that you see twice in the output above? signature.asc Description: signature
Bug#924288: suggested depend should be the modern nftables instead of the depreciated ufw
Package: postfix Version: 3.4.1-1 Postfix in buster still suggestions ufw, which is iptables based. Per https://wiki.debian.org/iptables , “iptables is being replaced by nftables starting with Debian Buster”. We should be suggesting nftables instead of ufw (or maybe both) to encourage its use.
Bug#807041: logind: laptop unexpectedly auto-suspends after some time of inactivity
On 10/03/2019 11:53, Michael Biebl wrote: Hi George Have you filed such an upstream bug report? https://github.com/systemd/systemd/issues/2346 It was closed though. :( Thanks, George
Bug#924261: stretch-pu: package certbot/0.28.0-1~deb9u1
After talking to kibi and jrtc27 on IRC, pushing up a new proposed diff with some tweaks to the control file and changelog. For more background about how this happened and why the move to v9 fixes it (with many, many thanks to Michael Biebl who walked me through this earlier when I sent up a flare for help): In the unstable branch, we switched to using dh_installsystemd instead of dh_systemd_enable in between the version that was in stable and the version in unstable. When preparing the SRU for the update, I undid those changes and reduced the compat level down to match the version that was in stretch (v10) to reduce the diff that would occur in stable. Unbeknownst to me, there was a change to the behavior of dh_systemd_enable between v9 and v10 that causes problems on upgrade. In v9, dh_systemd_enable would stop timers in prerm and then start them in postinst. In v10, however, dh_systemd_enable switches to using try-restart, which will noop on stopped timers. This means when the SRU was installed, the timer was stopped (in the old v9 prerm) and never started (in the new v10 postinst). Changing back to use v9 will mean that the package will invoke the start on the timer regardless of its current status, fixing broken systems and preventing new problems. This problem doesn't occur on fresh installs because the postinst is called differently, and although I tested certbot extensively (and had upstream do the same), none of us were looking closely at the timer functionality because "it wasn't supposed to change" (because that's never caused bugs before, god knows.) Sincerely, -- Harlan Lieberman-Berg ~hlieberman certbot-src.debdiff Description: Binary data
Bug#754809: bugs.debian.org still broken regarding DKIM
On Mar 11, Matija Nalis wrote: > Has this issue ever has been dealt with for bugs.debian.org (as it > seems to have been solved for lists.debian.org in forked #752084) ? No: it is obvious that the messages relayed by the BTS are still modified. > I can provide whole forensic report if required, or do tests. The problem is quite clear, but the is no commitment from the BTS maintainers to choose a solution and maybe implement it. -- ciao, Marco signature.asc Description: PGP signature
Bug#924287: unblock: afflib/3.7.17-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package afflib. The afflib had a FTBFS because a library symbol. The symbol was removed and a little updated was made in package. This upload closed bug #923959. The current changelog is: afflib (3.7.17-5) unstable; urgency=medium * Using new DH level format. Consequently: - debian/compat: removed. - debian/control: changed from 'debhelper' to 'debhelper-compat' in Build-Depends field and bumped level to 12. * debian/control: bumped Standards-Version to 4.3.0. * debian/libafflib0v5.symbols: - Added a Build-Depends-Package field. - Removed a symbol to fix a FTBFS. Thanks to Santiago Vila . (Closes: #923959) -- Joao Eriberto Mota Filho Thu, 07 Mar 2019 14:59:10 -0300 I attached a debdiff. Thanks a lot in advance. Eriberto diff -Nru afflib-3.7.17/debian/changelog afflib-3.7.17/debian/changelog --- afflib-3.7.17/debian/changelog 2018-09-29 23:20:47.0 -0300 +++ afflib-3.7.17/debian/changelog 2019-03-07 14:59:10.0 -0300 @@ -1,3 +1,17 @@ +afflib (3.7.17-5) unstable; urgency=medium + + * Using new DH level format. Consequently: + - debian/compat: removed. + - debian/control: changed from 'debhelper' to 'debhelper-compat' in +Build-Depends field and bumped level to 12. + * debian/control: bumped Standards-Version to 4.3.0. + * debian/libafflib0v5.symbols: + - Added a Build-Depends-Package field. + - Removed a symbol to fix a FTBFS. Thanks to Santiago Vila +. (Closes: #923959) + + -- Joao Eriberto Mota Filho Thu, 07 Mar 2019 14:59:10 -0300 + afflib (3.7.17-4) unstable; urgency=medium * Upload to unstable. diff -Nru afflib-3.7.17/debian/compat afflib-3.7.17/debian/compat --- afflib-3.7.17/debian/compat 2018-09-27 21:08:53.0 -0300 +++ afflib-3.7.17/debian/compat 1969-12-31 21:00:00.0 -0300 @@ -1 +0,0 @@ -11 diff -Nru afflib-3.7.17/debian/control afflib-3.7.17/debian/control --- afflib-3.7.17/debian/control2018-09-27 21:08:53.0 -0300 +++ afflib-3.7.17/debian/control2019-03-07 14:59:10.0 -0300 @@ -3,14 +3,14 @@ Priority: optional Maintainer: Debian Security Tools Uploaders: Joao Eriberto Mota Filho -Build-Depends: debhelper (>= 11), +Build-Depends: debhelper-compat (= 12), chrpath, libcurl4-openssl-dev, libexpat1-dev, libfuse-dev [!hurd-i386], libssl-dev, zlib1g-dev -Standards-Version: 4.2.1 +Standards-Version: 4.3.0 Homepage: https://github.com/sshock/AFFLIBv3 Vcs-Browser: https://salsa.debian.org/pkg-security-team/afflib Vcs-Git: https://salsa.debian.org/pkg-security-team/afflib.git diff -Nru afflib-3.7.17/debian/libafflib0v5.symbols afflib-3.7.17/debian/libafflib0v5.symbols --- afflib-3.7.17/debian/libafflib0v5.symbols 2018-09-29 14:14:43.0 -0300 +++ afflib-3.7.17/debian/libafflib0v5.symbols 2019-03-07 14:59:10.0 -0300 @@ -1,4 +1,5 @@ libafflib.so.0 libafflib0v5 #MINVER# +* Build-Depends-Package: libafflib-dev IID_ICompressCoder2@Base 3.7.6 IID_ICompressCoder@Base 3.7.6 IID_ICompressFilter@Base 3.7.6 @@ -373,7 +374,6 @@ (optional)_ZNSt6vectorIPN2s36BucketESaIS2_EE19_M_emplace_back_auxIJS2_EEEvDpOT_@Base 3.7.17 _ZNSt6vectorIPN2s38ContentsESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base 3.7.16 (optional)_ZNSt6vectorIPN2s38ContentsESaIS2_EE19_M_emplace_back_auxIJS2_EEEvDpOT_@Base 3.7.17 - _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE16_M_insert_uniqueIS5_EESt4pairISt17_Rb_tree_iteratorIS5_EbEOT_@Base 3.7.16 _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE8_M_eraseEPSt13_Rb_tree_nodeIS5_E@Base 3.7.16 _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE14_M_insert_nodeEPSt18_Rb_tree_node_baseSG_PSt13_Rb_tree_nodeIS8_E@Base 3.7.16 _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE24_M_get_insert_unique_posERS7_@Base 3.7.16
Bug#754809: bugs.debian.org still broken regarding DKIM
Has this issue ever has been dealt with for bugs.debian.org (as it seems to have been solved for lists.debian.org in forked #752084) ? Because I still have breakage when I submit mail to bugs.debian.org and I get failure notices from other hosts as noted in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830865#45 (note: my DKIM validates elsewhere, and I do not have any other issues with it except on bugs.debian.org mails). Forensic headers (requested in DMARC with fo=1) seems to indicate DKIM breaks along the way near bendel.debian.org, for example: Authentication-Results: mail.susi-moog.de; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=voyager.hr header.i=@voyager.hr header.b="EVrAhWxo"; dkim-atps=neutral Authentication-Results: mail.susi-moog.de; spf=none (mailfrom) smtp.mailfrom=lists.debian.org (client-ip=82.195.75.100; helo=bendel.debian.org; envelope-from=bounce-debian-bugs-rc=andreas.moog=warperbbs...@lists.debian.org; receiver=) Received: from localhost (localhost [127.0.0.1]) by bendel.debian.org (Postfix) with QMQP id ABCCC20BAE; Wed, 6 Mar 2019 03:15:08 + (UTC) X-Mailbox-Line: From debian-bugs-rc-requ...@lists.debian.org Wed Mar 6 03:15:08 2019 Old-Return-Path: X-Original-To: lists-debian-bugs...@bendel.debian.org Delivered-To: lists-debian-bugs...@bendel.debian.org Received: from localhost (localhost [127.0.0.1]) by bendel.debian.org (Postfix) with ESMTP id 9CF7820BA9 for ; Wed, 6 Mar 2019 03:15:08 + (UTC) X-Virus-Scanned: at lists.debian.org with policy bank bug X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-1 required=5.3 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable autolearn_force=no Received: from bendel.debian.org ([127.0.0.1]) by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525) with ESMTP id r-35XNxN_7Md for ; Wed, 6 Mar 2019 03:15:06 + (UTC) Received: from buxtehude.debian.org (buxtehude.debian.org [IPv6:2607:f8f0:614:1::1274:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "buxtehude.debian.org", Issuer "Debian SMTP CA" (not verified)) by bendel.debian.org (Postfix) with ESMTPS id 78D1B20BA4; Wed, 6 Mar 2019 03:15:06 + (UTC) Received: from debbugs by buxtehude.debian.org with local (Exim 4.89) (envelope-from ) id 1h1N1L-0008UD-2y; Wed, 06 Mar 2019 03:15:03 + X-Loop: ow...@bugs.debian.org I can provide whole forensic report if required, or do tests. -- Opinions above are GNU-copylefted.
Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it
> What might work is disabling the avdevice outdev AND > moving 'ffplay' to its own binary package. Before suggesting this, I would prefer the OP to test. I still do not entirely believe that this fixes his issue. Carl Eugen
Bug#924257: docker.io: Misses to install some golang packages
Hi, On 3/10/19 11:23 PM, Reinhard Tartler wrote: > Source: docker.io > Severity: normal > Control: block 923300 by -1 > > While working on the package 'golang-github-openshift-imagebuilder', I > was running into compilation errors, more specifically, unresolved > dependencies during the build: > >dh_auto_build -O--buildsystem=golang > cd obj-x86_64-linux-gnu && go install > -gcflags=all=\"-trimpath=/<>/golang-github-openshift-imagebuilder-1.0\+git20190308.705fe92/obj-x86_64-linux-gnu/src\" > > -asmflags=all=\"-trimpath=/<>/golang-github-openshift-imagebuilder-1.0\+git20190308.705fe92/obj-x86_64-linux-gnu/src\" > -v -p 4 github.com/openshift/imagebuilder > github.com/openshift/imagebuilder/cmd/imagebuilder > github.com/openshift/imagebuilder/dockerclient > github.com/openshift/imagebuilder/dockerfile > github.com/openshift/imagebuilder/dockerfile/command > github.com/openshift/imagebuilder/dockerfile/parser > github.com/openshift/imagebuilder/dockerfile/parser/dumper > github.com/openshift/imagebuilder/imageprogress > github.com/openshift/imagebuilder/signal > github.com/openshift/imagebuilder/strslice > src/github.com/openshift/imagebuilder/dockerfile/builder.go:15:2: cannot find > package "github.com/docker/docker/builder" in any of: > /usr/lib/go-1.11/src/github.com/docker/docker/builder (from $GOROOT) > > /<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/builder > (from $GOPATH) > src/github.com/openshift/imagebuilder/dockerfile/builder.go:16:2: cannot find > package "github.com/docker/docker/builder/dockerfile/command" in any of: > > /usr/lib/go-1.11/src/github.com/docker/docker/builder/dockerfile/command > (from $GOROOT) > > /<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/builder/dockerfile/command > (from $GOPATH) > src/github.com/openshift/imagebuilder/dockerfile/builder.go:17:2: cannot find > package "github.com/docker/docker/builder/dockerfile/parser" in any of: > /usr/lib/go-1.11/src/github.com/docker/docker/builder/dockerfile/parser > (from $GOROOT) > > /<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/builder/dockerfile/parser > (from $GOPATH) > src/github.com/openshift/imagebuilder/dockerfile/builder.go:18:2: cannot find > package "github.com/docker/docker/builder/fscache" in any of: > /usr/lib/go-1.11/src/github.com/docker/docker/builder/fscache (from > $GOROOT) > > /<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/builder/fscache > (from $GOPATH) > src/github.com/openshift/imagebuilder/dockerfile/builder.go:19:2: cannot find > package "github.com/docker/docker/builder/remotecontext" in any of: > /usr/lib/go-1.11/src/github.com/docker/docker/builder/remotecontext > (from $GOROOT) > > /<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/builder/remotecontext > (from $GOPATH) > src/github.com/openshift/imagebuilder/dockerfile/containerbackend.go:10:2: > cannot find package "github.com/docker/docker/container" in any of: > /usr/lib/go-1.11/src/github.com/docker/docker/container (from $GOROOT) > > /<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/container > (from $GOPATH) > src/github.com/openshift/imagebuilder/dockerfile/dispatchers.go:25:2: cannot > find package "github.com/docker/docker/image" in any of: > /usr/lib/go-1.11/src/github.com/docker/docker/image (from $GOROOT) > > /<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/docker/image > (from $GOPATH) > src/github.com/openshift/imagebuilder/dockerfile/metrics.go:4:2: cannot find > package "github.com/docker/go-metrics" in any of: > /usr/lib/go-1.11/src/github.com/docker/go-metrics (from $GOROOT) > > /<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/docker/go-metrics > (from $GOPATH) > src/github.com/openshift/imagebuilder/dockerfile/builder.go:26:2: cannot find > package "github.com/moby/buildkit/session" in any of: > /usr/lib/go-1.11/src/github.com/moby/buildkit/session (from $GOROOT) > > /<>/golang-github-openshift-imagebuilder-1.0+git20190308.705fe92/obj-x86_64-linux-gnu/src/github.com/moby/buildkit/session > (from $GOPATH) > src/github.com/openshift/imagebuilder/dockerfile/clientsession.go:9:2: cannot > find package "github.com/moby/buildkit/session/filesync" in any of: > /usr/lib/go-1.11/src/github.com/moby/buildkit/session/filesync (from > $GOROOT) > >
Bug#921159: Can't enter second option
Control: tags -1 + confirmed upstream On Fri, Feb 01 2019, 積丹尼 Dan Jacobson wrote: > Package: bash-completion > Version: 1:2.8-5 > > Why can't one enter a second option? > $ grep --no-filename --c Completions for grep are provided by the _longopt function, which completes every option that matches "--*file*" with _filedir completion. I have just submitted a merge request upstream as: https://github.com/scop/bash-completion/pull/291
Bug#924286: netatalk: Netatalk 3 in Buster
Package: netatalk Version: 3.1.10-1 Severity: normal Dear Maintainer, Please push netatalk 3 to buster before the freeze. It doesn't really help people if it's forever in sid. Push netatalk v2 to it's own package if needed, or 3 in it's own. I am glad to see it in sid, at least though. Thank you. -- System Information: Debian Release: 9.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/32 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages netatalk depends on: ii libacl1 2.2.52-3+b1 ii libatalk183.1.10-1 ii libattr1 1:2.4.47-2+b2 ii libavahi-client3 0.6.32-2 ii libavahi-common3 0.6.32-2 ii libc6 2.24-11+deb9u4 ii libcomerr21.43.4-2 ii libcrack2 2.9.2-5 ii libdb5.3 5.3.28-12+deb9u1 ii libdbus-1-3 1.10.24-0+deb9u1.0nosystemd1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.0-52.0.21-stable-3 ii libgcrypt20 1.7.6-2+deb9u3 ii libglib2.0-0 2.50.3-2 ii libgssapi-krb5-2 1.15-1+deb9u1 ii libk5crypto3 1.15-1+deb9u1 ii libkrb5-3 1.15-1+deb9u1 ii libldap-2.4-2 2.4.44+dfsg-5+deb9u2 ii libmysqlclient18 5.5.57-0+deb8u1 ii libpam-modules1.1.8-3.6 ii libpam0g 1.1.8-3.6 ii libwrap0 7.6.q-26 ii netbase 5.4 ii perl 5.24.1-3+deb9u5 ii python2.7.13-2 ii zlib1g1:1.2.8.dfsg-5 Versions of packages netatalk recommends: ii avahi-daemon 0.6.32-2 ii cracklib-runtime 2.9.2-5 ii db-util 5.3.1 pn libpam-cracklib ii lsof 4.89+dfsg-0.1 ii procps2:3.3.12-3.0nosystemd1 pn rc Versions of packages netatalk suggests: pn db4.2-util pn groff pn quota pn texlive-base-bin -- Configuration Files: /etc/netatalk/afp.conf changed [not included] -- debconf-show failed
Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it
On Sun, Mar 10, 2019 at 6:57 PM Carl Eugen Hoyos wrote: > 2019-03-10 23:21 GMT+01:00, Reinhard Tartler : > > On Sat, Mar 9, 2019 at 2:51 PM Carl Eugen Hoyos > wrote: > > > >> Could you test the configure option "--disable-outdev=sdl2"? > >> Your report indicates it should fix your issue, I am not convinced but > >> if it fixes your issue, Debian should consider using it as the device > >> is mostly a (cheap) debug feature. > > > Wouldn't that video break playback in 'ffplay'? > > Can you elaborate why you think so? > By looking at https://sources.debian.org/src/ffmpeg/7:4.1.1-1/fftools/ffplay.c/, I see plenty of references to SDL, many of which aren't guarded by #ifdefs. Looks like SDL2 is a hard dependency for a functional ffplay. > > Can you elaborate what makes you think so? > > Iirc, I was the only one speaking against its removal. > You mean dropping ffplay altogether? - I am having a hard time parsing that sentence. > But given that your avconv project never contained an sdl output > device I wonder what your expertise is here? > > I believe we may mis-communicating here. AFAIUI, the original poster wanted to make SDL an optional dependency. Even if the debian package was compiled with '--disable-outdev=sdl2', wouldn't the 'ffmpeg' binary package still continue to depend on sdl2 libraries? - In that case we haven't won anything by this. I guess the debian package would in addition have to pass the --disable-sdl2 switch to configure, which to my understanding would prevent 'ffplay' from being compiled. I would consider that a regression. What might work is disabling the avdevice outdev AND moving 'ffplay' to its own binary package. -- regards, Reinhard
Bug#924285: ITP: vagrant-librarian-puppet -- A Vagrant plugin to install Puppet modules using Librarian-Puppet
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: vagrant-librarian-puppet Version : 0.9.2 Upstream Author : Vox Pupuli * URL : https://github.com/voxpupuli/vagrant-librarian-puppet * License : MIT Programming Lang: Ruby Description : A Vagrant plugin to install Puppet modules using Librarian-Puppet vagrant-librarian-puppet is a plugin for Vagrant that will automatically run librarian-puppet before any provisioning step. It looks for a Puppetfile in the configured directory and uses that file with librarian-puppet. More details: - This plugin automates management of module dependencies when testing puppet modules, or simply when maintaining your local test VM for day-to-day puppet development. I removes the need to remember to install new modules with librarian-puppet after having pulled in other people's changes on the Puppetfile. - It is not a dependency for another package - I so far use it for testing individual puppet modules that I maintain, and to make it easier to test changes before committing. I also intend to use it at work to reduce friction around keeping modules up to date in the local dev VMs. - I don't know of another package that provides such functionality. It's also the only vagrant plugin that I know can help automate this. - Since I'm not a DD or a DM, I am planning on asking a friend who is a Debian Developer to help me out with shaping the package so that it's acceptable for debian. I would then intend to ask the ruby packaging team if they are willing to make this one of the team packages and I would continue maintaining it through the team.
Bug#924284: git-buildpackage: import-dscs overwrites pre-existing upstream tags
Package: git-buildpackage Version: 0.9.13 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I'm trying to import am existing package in git, with the caveat that I already set up the upstream branch and tags -- I want to base it off upstream's git history, so I can easily cherry-pick patches. Unfortunately, when running `gbp import-dscs --debsnap` I ran into two issues: 1. The current content of the branch are overwritten, including debian/gbp.conf, and so gbp stops observing parameters set there. It is easily worked around by passing those parameters on the CLI, but gbp should probably read its configuration once and keep it in memory through the whole execution. 2. gbp import-dscs will overwrite existing upstream branch and tags. The behaviour I expected would have been to keep the existing tags, and import the content of debian/ in the packaging branch (along with adding the necessary data for pristine-tar). Am I simply using gbp wrong, or is this legitimately a bug? If so, are you aware of a possible workaround? Best, nicoo - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git-buildpackage depends on: ii devscripts 2.19.3 ii git1:2.20.1-2 ii man-db 2.8.5-2 ii python33.7.2-1 ii python3-dateutil 2.7.3-3 ii python3-pkg-resources 40.8.0-1 ii sensible-utils 0.0.12 Versions of packages git-buildpackage recommends: ii pristine-tar 1.46 ii python3-requests 2.21.0-1 ii sbuild0.78.1-1 Versions of packages git-buildpackage suggests: pn python3-notify2 ii sudo 1.8.27-1 ii unzip6.0-22 - -- Configuration Files: /etc/git-buildpackage/gbp.conf changed: [DEFAULT] builder = sbuild -v --no-clean-source [buildpackage] postbuild = cd /opt/deb/buildarea && apt-ftparchive packages . > Packages export-dir = /opt/deb/buildarea dist = DEP14 [import-orig] [import-dsc] [dch] [pq] [clone] [pull] [create-remote-repo] [remote-config pkg-libvirt] remote-url-pattern = ssh://git.debian.org/git/pkg-libvirt/%(pkg)s template-dir = /srv/alioth.debian.org/chroot/home/groups/pkg-libvirt/git-template - -- no debconf information -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAlyFrBQRHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7MtWzQ//Wim9AsNfI08C79n8xNNx5rosYSsqnxaK ESKIuME46elcDIZzQmAPSerPmF0uL9fax01KpZkSIwyOjlIbgHnTsIxEg6rwls76 kgJWopcGFu7ip3mDa60EPtOHYQMjNoOolSiggw1CvcYE284vr2/+V8kIurd681qA ixDWRR6XddvBrbhEsNKJ+Uw2VuQidt2zrBaHZ19ArUN+6z7h5R0uTTOTxjeb0kJK ESJJnL7IwlwHVe67+U9dAhKJoVTXqCvC0cmWQSfvnVSDaE6rAbHCAqp3S+Sq9s3N RUWs5+nvr+TzPz95uE7tMIJiYYmL4IOFLXGcRHC1pwA7v25EO4Z7an1CAbH+oq+i 7+87RaetBwqa6MSSiIjmcfyo4Nfl2W75JcG8yArK+g+7BEk7Zv0XhuEeosqAsTtj 2QRl7flL5PCnS4sknf5ZM7ifj2M3kpLFfjTdjxaZecUH0+YsO+JqzPQyAvXfpEHd CS2EYl7042jgbNH/ZCZqxLbQIAFH66rQbqBc32yZGw8u0oL2ZHwAG27TGm8aLvO5 drmf760o/B6nRXYdV8VXbsBcYeguUuqPhfnfHTl3s1WB5pR1QjZ5uZFZDQS2mNLD VViSY7E1qdRrlhTYYpFZwblpdfAQWJlBuWcXk2cqyaRYF6MUu2g/wC5aCfeiTEHY Iqotka3eiN8= =vj98 -END PGP SIGNATURE-
Bug#924275: Pulls in lvm2 packages on systems not needing them
tag 924275 +pending
thanks
On Sun, Mar 10, 2019 at 09:29:04PM +0100, Sven Hartge wrote:
>
> While I like the new fsck-via-LVM-snapshot feature, I think adding lvm2
> to Recommends is too agressive here.
>
> On systems not using LVM this will needlessly pull in the whole LVM/DM
> machinery, including changes to the initramfs, as long as apt is in its
> default "install-recommends" configuration.
>
> Only on systems where the system admin has changed the default to
> "no-install-recommends" nothing will happen.
Agreed; thanks for pointing this out! I have the following patches
queued for the next release.
- Ted
>From 04738f2ff3b8a2acaf2de09856e07601817350b5 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Sun, 10 Mar 2019 19:41:11 -0400
Subject: [PATCH 1/2] e2scrub: check to make sure lvm2 is installed
Not all systems will have the lvm2 package installed, so check for
that. Pretty much all systems should have util-linux installed, but
check for that as well.
Of course, if lvm2 is installed we shouldn't find any LVM devices ---
but eventually the Demon Murphy will find a way to make it happen. :-)
Also, set the PATH so we don't have to worry about the script failing
due to /sbin not being in the path.
Signed-off-by: Theodore Ts'o
---
scrub/e2scrub.in | 12
scrub/e2scrub_all.in | 16
2 files changed, 28 insertions(+)
diff --git a/scrub/e2scrub.in b/scrub/e2scrub.in
index e1965db4e..51a909373 100644
--- a/scrub/e2scrub.in
+++ b/scrub/e2scrub.in
@@ -23,6 +23,8 @@
# check filesystems in VGs that have at least 256MB (or so) of
# free space.
+PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+
snap_size_mb=256
fstrim=0
reap=0
@@ -82,6 +84,16 @@ if [ -z "${arg}" ]; then
exitcode 1
fi
+if ! type lsblk >& /dev/null ; then
+echo "e2scrub: can't find lsblk --- is util-linux installed?"
+exitcode 1
+fi
+
+if ! type lvcreate >& /dev/null ; then
+echo "e2scrub: can't find lvcreate --- is lvm2 installed?"
+exitcode 1
+fi
+
# Find the device for a given mountpoint
dev_from_mount() {
local mountpt="$(realpath "$1")"
diff --git a/scrub/e2scrub_all.in b/scrub/e2scrub_all.in
index 23d122d25..d725a7f2e 100644
--- a/scrub/e2scrub_all.in
+++ b/scrub/e2scrub_all.in
@@ -18,6 +18,8 @@
# along with this program; if not, write the Free Software Foundation,
# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
+PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+
scrub_all=0
conffile="@root_sysconfdir@/e2scrub.conf"
@@ -68,6 +70,20 @@ while getopts "ArV" opt; do
done
shift "$((OPTIND - 1))"
+# If some prerequisite packages are not installed, exit with a code
+# indicating success to avoid spamming the sysadmin with fail messages
+# when e2scrub_all is run out of cron or a systemd timer.
+
+if ! type lsblk >& /dev/null ; then
+echo "e2scrub_all: can't find lsblk --- is util-linux installed?"
+exitcode 0
+fi
+
+if ! type lvcreate >& /dev/null ; then
+echo "e2scrub_all: can't find lvcreate --- is lvm2 installed?"
+exitcode 0
+fi
+
# Find scrub targets, make sure we only do this once.
ls_scrub_targets() {
lsblk -o NAME,FSTYPE,MOUNTPOINT -p -P -n | while read vars; do
--
2.19.1
>From 212ba2a8a81001bce21cce314f9bc2967f2df7c7 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Sun, 10 Mar 2019 20:01:58 -0400
Subject: [PATCH 2/2] debian: drop lvm2 from the recommends line
If the user doesn't intend to use lvm2, and it's not installed,
installing e2fsprogs shouldn't drag it (and all of its dependencies)
into the system.
Addresses-Debian-Bug: 924275
Signed-off-by: Theodore Ts'o
---
debian/control | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index 1bb8adb15..e454687f9 100644
--- a/debian/control
+++ b/debian/control
@@ -191,7 +191,7 @@ XB-Important: yes
Pre-Depends: ${shlibs:Depends}, ${misc:Depends}, libblkid1, libuuid1
Multi-Arch: foreign
Suggests: gpart, parted, fuse2fs, e2fsck-static
-Recommends: e2fsprogs-l10n, lvm2
+Recommends: e2fsprogs-l10n
Architecture: any
Description: ext2/ext3/ext4 file system utilities
The ext2, ext3 and ext4 file systems are successors of the original ext
--
2.19.1
Bug#911290: policy-rcd-declarative
I just uploaded (to experimental) a package policy-rcd-declarative, which ships a policy-rc.d script that can be configured through static files, in an attempt to address some of the issues pointed out in this bug report. It's not yet ready for prime time (hence the upload to experimental rather than unstable, given the short time before the buster release), but comments are definitely welcome. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#924282: stretch-pu: package python-mode/6.2.3-1.1~deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hi,
python-mode fails to install along xemacs21. This is a rebuild of the
fix that was applied in sid: skip xemacs21 in emacsen.install
The package is already uploaded.
Andreas
diff -Nru python-mode-6.2.3/debian/changelog python-mode-6.2.3/debian/changelog
--- python-mode-6.2.3/debian/changelog 2017-01-17 22:33:55.0 +0100
+++ python-mode-6.2.3/debian/changelog 2019-03-11 00:42:53.0 +0100
@@ -1,3 +1,17 @@
+python-mode (1:6.2.3-1.1~deb9u1) stretch; urgency=medium
+
+ * Non-maintainer upload
+ * Rebuild for stretch.
+
+ -- Andreas Beckmann Mon, 11 Mar 2019 00:42:53 +0100
+
+python-mode (1:6.2.3-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * Drop xemacs21 support (Closes: #909383, #680578, #837991)
+
+ -- Hilko Bengen Sat, 09 Feb 2019 16:56:13 +0100
+
python-mode (1:6.2.3-1) unstable; urgency=medium
* New upstream release.
diff -Nru python-mode-6.2.3/debian/emacsen-install
python-mode-6.2.3/debian/emacsen-install
--- python-mode-6.2.3/debian/emacsen-install2017-01-17 22:33:55.0
+0100
+++ python-mode-6.2.3/debian/emacsen-install2019-02-09 16:52:02.0
+0100
@@ -20,6 +20,11 @@
exit 0
fi
+if [ ${FLAVOR} = xemacs21 ]; then
+echo "$PACKAGE requires string-to-syntax, rx.el, which is not available in
xemacs21"
+exit 0
+fi
+
echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
FLAVORTEST=`echo $FLAVOR | cut -c-6`
Bug#890950: Bug#902416: Bug#890950: RE: Bug#902416: systemd: systemctl hibernate: unable to resume after upgrade
On Mon, 2019-03-11 at 00:20 +0100, Michael Biebl wrote: > Hi Ben > > Am 10.03.19 um 23:17 schrieb Ben Hutchings: > > I think it would make sense for systemd to only set the hibernation > > device if it's not already set (i.e. if /sys/power/resume contains > > "0:0\n"). > > I get $ cat /sys/power/resume > 8:4 > > which part is responsible for setting that? initramfs-tools, or any alternative that implements resume from hibernation. This is because writing to /sys/power/resume is the way to resume from hibernation, as well as the way to set the device for the next hibernation. (systemd writes the number of an active swap device, so it won't cause an immediate resume.) Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Bug#915370: fixed in tasksel 3.51
Control: found -1 3.51 I think this was closed by accident Re-opening this bug report. Dropping anacron from task-desktop/laptop should still happen. If not for buster, then for buster+1 -- 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#917807: libcaca: CVE-2018-20544 CVE-2018-20545 CVE-2018-20546 CVE-2018-20547 CVE-2018-20548 CVE-2018-20549
clone 917807 -1 retitle -1 Orphan libcaca severity -1 normal thanks Hi Sam, I'm planning on fixing those security issues for Buster. Given that you last touched the package in 2014, and didn't address this critical bug within 3 months, may I go ahead and orphan the package while I'm at it? I will do so in the absence of an answer, but I shall make sure that my upload is delayed until at least next Monday (2019-03-18), so you have time to intercept it. Best, nicoo On Sun, Dec 30, 2018 at 04:42:04PM +0100, Salvatore Bonaccorso wrote: > Source: libcaca > Version: 0.99.beta19-2 > Severity: important > Tags: security upstream fixed-upstream > > Hi, > > The following vulnerabilities were published for libcaca. > > CVE-2018-20544[0]: > | There is floating point exception at caca/dither.c (function > | caca_dither_bitmap) in libcaca 0.99.beta19. > > CVE-2018-20545[1]: > | There is an illegal WRITE memory access at common-image.c (function > | load_image) in libcaca 0.99.beta19 for 4bpp data. > > CVE-2018-20546[2]: > | There is an illegal READ memory access at caca/dither.c (function > | get_rgba_default) in libcaca 0.99.beta19 for the default bpp case. > > CVE-2018-20547[3]: > | There is an illegal READ memory access at caca/dither.c (function > | get_rgba_default) in libcaca 0.99.beta19 for 24bpp data. > > CVE-2018-20548[4]: > | There is an illegal WRITE memory access at common-image.c (function > | load_image) in libcaca 0.99.beta19 for 1bpp data. > > CVE-2018-20549[5]: > | There is an illegal WRITE memory access at caca/file.c (function > | caca_file_read) in libcaca 0.99.beta19. > > Note: obviously I realize given you are both upstream am Debian > maintainer you have already fixed this upstream with the reports > submitted and two of those issues are actually unimportant as the > Debian build does not use the fallback. > > Reporting these issues still in the BTS for tracking purpose. > > If you fix the vulnerabilities please also make sure to include the > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2018-20544 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20544 > [1] https://security-tracker.debian.org/tracker/CVE-2018-20545 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20545 > [2] https://security-tracker.debian.org/tracker/CVE-2018-20546 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20546 > [3] https://security-tracker.debian.org/tracker/CVE-2018-20547 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20547 > [4] https://security-tracker.debian.org/tracker/CVE-2018-20548 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20548 > [5] https://security-tracker.debian.org/tracker/CVE-2018-20549 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20549 > > Regards, > Salvatore > signature.asc Description: PGP signature
Bug#861027: gprolog bug still there despite easy fixes
Hi, the problem with Debian gprolog is that it's based on an experimental branch (modules), which is incomplete and is the cause of the bug. The fix may be as simple as getting the regular upstream and recompiling it. I'm a bit confused with the git-based packaging tools, so maybe I should revert to a plain packaging build... Give me a couple of days to try that path first. best, -salvador > On 10 Mar 2019, at 22h49, Cedric Ware wrote: > > > Hello Tony, > > tony mancill (Sunday 2019-03-10): >> I had a try at this. I pulled the latest upstream release 1.4.5 from >> gprolog.org [1], which is dated February of 2019 and it exhibits the >> same problem reported in this bug report. > > Are you sure? The official 1.4.5 works for me when compiled from > source and installed into a directory that is in my PATH. Remember > that the toplevel gprolog invokes various binaries, e.g. pl2wam; > are you sure you didn't have the buggy pl2wam in your PATH? It has > bitten me before while testing. > >> Also problematic is that the sources for version 1.4.5 found on >> gprolog.org differ substantially from the 1.4.5 sources found in Debian. > > As far as I understand it, that's because Debian's "1.4.5" isn't the > release, it's development code pulled from gprolog's git repository > a couple of years ago, sometime after 1.4.4 was released. > > Best regards, > Cedric Ware.
Bug#924280: ITP: golang-github-alcortesm-tgz -- Go library to extract tgz files to temporal directories.
Package: wnpp Severity: wishlist Owner: Dawid Dziurla * Package name: golang-github-alcortesm-tgz Version : 0.0~git20161220.9c5fe88-1 Upstream Author : Alberto Cortés * URL : https://github.com/alcortesm/tgz * License : Expat Programming Lang: Go Description : Go library to extract tgz files to temporal directories. Decompress a gziped tarball into a new temporal directory created just for this purpose. This package is in the dependency tree of Lazygit (#908894)
Bug#924161: unblock: lirc/0.10.1-5.1
On Sun, 10 Mar 2019 18:07:57 +0100 Nicolas Braud-Santoni
wrote:
> Control: tags -1 - moreinfo
>
> On Sun, Mar 10, 2019 at 08:58:00AM +, Niels Thykier wrote:
> > --link-doc requires dir-to-symlink migration via dpkg-maintscript-helper
> > in the maintscript. I do not see that in the debdiff, so I assume the
> > proposed changes will trigger a new bug (as I recall, an RC bug).
>
> Yes indeed!
> Thanks for catching this, here is the debdiff for the updated package.
>
> I also fixed some other issues, like #924158.
This needs a lot of more work :-(
* is this usage of --link-doc valid? the packages don't have a strictly
versioned Depends: lirc (= ${binary:version}), so I can install *only*
liblirc0 and have a dangling /usr/share/doc/liblirc0 and e.g. no
copyright file
* in all the *.maintscript files, add 0.10.1-5.1~ as 'prior-version'
argument - you don't want to run this stuff again on *every* upgrade
* lirc.maintscript has typos: /etx/...
* does the override_dh_installdocs target work with
dpkg-buildpackage -A/-B (i.e. building arch and indep packages separately)
* lirc.postinst: using wildcards looks very fragile
* lirc.posztrm: why do you manually delete conffiles on purge? dpkg does
that already. (If they are not conffiles, you can't use
dpkg-maintscript-helper on them.)
Andreas
PS: I hate cleaning up after misuse of --link-doc. Save brain cycles,
not bits on disks. Right now I'm afraid that you are turning a mess into
a greater mess.
PPS: I only looked at the debdiff, not at the package itself
Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible
Hi again
I finally found out why I could not use xstrdup so with that fixed I run
the tests again. No crash. My guess is that the crash is some other part of
the code and not the newly introduced functions.
// Ola
On Mon, 11 Mar 2019 at 00:09, Ola Lundqvist wrote:
> Hi Mike
>
> I have had a look at this. First of all I do not think the CVE is
> completely fixed even with the additional patch. I also do not fully
> understand how 6111-2.patch is supposed to work. More about this below.
> Let us give some example commands.
>
> [1] scp host:/foobar/a* b
> [2] scp host:a* b
> [3] scp -r host /foobar/a* b
> [4] scp -r host a* b
>
> My understanding is that only case 1 is protected by 6111-1.patch
> 6111-2.patch seems to protect against case 2.
>
> But to my understanding we do not protect against 3 and 4. Am I missing
> something?
>
> Anyway I have tried to see if I could reproduce the segfault. I do not
> know fully how you have tested it so I decided to copy the new code to a
> new test.c file and test different patterns.
> The functionality as such seems to be working fine.
>
> I did one change though to make it work. I changed xstrdup to strdup
> because I could not find link against it for some reason. Could that be
> your problem too?
>
> Essentially my test.c file looks like this:
> #include
> #include
> #include
> #include
> #include
> #define fatal sprintf
>
> ... the new functions code here ...
>
> int testpattern(char* pattern) {
> char **patterns = NULL;
> size_t npatterns = 0;
> int i = 0;
> printf(" Test pattern %s \n", pattern);
> brace_expand(pattern, , );
> for (i = 0; i < npatterns; i++) {
> printf("Pattern %d: %s\n", i, patterns[i]);
> }
> }
>
> int main(int argc, char** argv) {
> testpattern("filea");
> testpattern("dira/filea");
> testpattern("dira/file{a,b}");
> testpattern("file{a,b}");
> testpattern("file*");
> testpattern("file{a,b}{c,d}");
> testpattern("file{a,b}*");
> testpattern("dir{a,b}*/d");
> testpattern("dir{a,b}/file*{a,b}*");
> }
>
> I could not reproduce the crash. How did you reproduce it?
>
> Best regards
>
> // Ola
>
>
> On Fri, 8 Mar 2019 at 23:41, Mike Gabriel wrote:
>
>> Hi Colin, hi Debian LTS team,
>>
>> On Fr 01 Mär 2019 13:24:30 CET, Colin Watson wrote:
>>
>> > And yes, it looks OK - I'll upload it to unstable shortly.
>>
>> I have prepared a backport of this newly added patch [1] (see #923486
>> for details) to openssh in Debian jessie LTS, but with that patch
>> backported to openssh in Debian jessie, I get a segmentation fault
>> whenever I copy something using the scp cmdline tool (I have of course
>> backported all other patches regarding CVE-2019-6109 and CVE-2019-6111).
>>
>> I have attached the complete .debdiff between openssh 1:6.7p1-5+deb8u7
>> (in jessie-security) and my (not-yet-)proposal for 1:6.7p1-5+deb8u8.
>>
>> The critical patch is CVE-2019-6111-2.patch. With that patch added I
>> get segfaults with scp. Without that patch scp works, but is
>> susceptible to the earlier mentioned exploit for CVE-2019-6111.
>>
>> I am a bit lost here and would appreciate some ideas about what is
>> going wrong here.
>>
>> I will only be able to continue on this on Monday, but maybe someone
>> else can offer some genuine input over the weekend. Will be much
>> appreciated.
>>
>> Thanks+Greets,
>> Mike
>>
>> [1]
>>
>> https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874
>> --
>>
>> mike gabriel aka sunweaver (Debian Developer)
>> mobile: +49 (1520) 1976 148
>> landline: +49 (4354) 8390 139
>>
>> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
>> mail: sunwea...@debian.org, http://sunweavers.net
>>
>>
>
> --
> --- Inguza Technology AB --- MSc in Information Technology
> | o...@inguza.como...@debian.org|
> | http://inguza.com/Mobile: +46 (0)70-332 1551 |
> ---
>
>
--
--- Inguza Technology AB --- MSc in Information Technology
| o...@inguza.como...@debian.org|
| http://inguza.com/Mobile: +46 (0)70-332 1551 |
---
Bug#861027: gprolog bug still there despite easy fixes
Hello Tony, tony mancill (Sunday 2019-03-10): > I had a try at this. I pulled the latest upstream release 1.4.5 from > gprolog.org [1], which is dated February of 2019 and it exhibits the > same problem reported in this bug report. Are you sure? The official 1.4.5 works for me when compiled from source and installed into a directory that is in my PATH. Remember that the toplevel gprolog invokes various binaries, e.g. pl2wam; are you sure you didn't have the buggy pl2wam in your PATH? It has bitten me before while testing. > Also problematic is that the sources for version 1.4.5 found on > gprolog.org differ substantially from the 1.4.5 sources found in Debian. As far as I understand it, that's because Debian's "1.4.5" isn't the release, it's development code pulled from gprolog's git repository a couple of years ago, sometime after 1.4.4 was released. Best regards, Cedric Ware.
Bug#890950: Bug#902416: Bug#890950: RE: Bug#902416: systemd: systemctl hibernate: unable to resume after upgrade
Hi Ben Am 10.03.19 um 23:17 schrieb Ben Hutchings: > I think it would make sense for systemd to only set the hibernation > device if it's not already set (i.e. if /sys/power/resume contains > "0:0\n"). I get $ cat /sys/power/resume 8:4 which part is responsible for setting that? -- 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#920442: #920442: libcaca FTBFS in unstable
I also was able to build in unstable, but building in buster still FTBFS, so at one of the build-dependencies is still broken in buster. live well, vagrant
Bug#921266: Could this simple typo be the reason: "ream" <-> "realm"?
Control: severity -1 important Control: tags -1 moreinfo Hi Alf, > I now tried to collect debug info with the cli-version - it crashes the > same way with segfault: > > linphonec -d 5 -l linphone-debug > > the last lines in the debug output after password enty and before crash are: > > Authentication-Info: > qop=auth,rspauth="4aa9ccf88b3958bb460174863eccbb82",cnonce="0us2EQTtqGWgU6LP",nc=0001 > > > 2019-03-08 22:17:07:834 ortp-message-channel [0x55f42b920dd0] [721] > bytes parsed > 2019-03-08 22:17:07:834 ortp-message-Found transaction matching response. > 2019-03-08 22:17:07:834 ortp-message-Updating auth context for ream > [tel.t-online.de] next nonce is going to be [(null)] > > Please note the very last line: > > it wants to update auth for "ream" > instead of "realm" > > I cannot decide if this is just a typo in text output or actually a > wrong named parameter. This auth cycle is the second one which probably > only is used by German Telekom? > > If more information is needed, please let me know > > Fopr completeness I do attach the whole debug output as a plain txt-file > named linphone-debug. First of all, thanks a lot for your report. Based on your feedback of only affecting t-online.de configurations and also happening in the official Flatpak version (thus not being Debian specific) I'm downgrading the severity again. The ream <-> realm typo is just a typo as far as I can tell. It actually comes from here: https://github.com/BelledonneCommunications/belle-sip/blob/master/src/provider.c#L234 There have been quite a few commits to that file since it has been released https://github.com/BelledonneCommunications/belle-sip/commits/master/src/provider.c Release 1.6.3 which is imported in Debian has been tagged on 21.7.2017, so there are quite a few commits to check on. And the totally screwed up handling of the codebase by upstream, with dozens of interdependent libraries that need to be upgraded in lockstep and have not seen tagged release for almost two years, does not make it any easier. You could try the daily snapshot of the official flatpak, which should be available here flatpak --user install --from https://www.linphone.org/snapshots/flatpak-testing-repo/linphone.flatpakref [totally untested, I don't use flatpak] If you can still reproduce it, please report upstream at http://lists.nongnu.org/archive/html/linphone-users/ . Bernhard
Bug#913119: Bug#913138: linux-image-4.18.0-2-amd64: Hangs on lvm raid1
Control: tag 913138 pending Control: tag 913119 pending On 2019-02-26, martin wrote: > On 2019-02-26 21:11, Cesare Leonardi wrote: >> On 13/02/19 18:21, Dragan Milenkovic wrote: >>> This patch is already on its way to stable branches. I have tested it >>> and confirmed that it resolves the problem. >> >> Hello Dragan, do you know if the patch was eventually included >> upstream and possibly in which version? > > Looking at the change log it's in here: > https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.24 > > towards the bottom search for "blk-mq: fix a hung issue when fsync" Newer versions are in sid git, should be in next upload. live well, vagrant
Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
On 3/10/19 11:03 PM, Andrew Cooper wrote: > On 10/03/2019 21:35, Hans van Kranenburg wrote: >> >> [...] >> >> Using dom0_mem=2GiB,max:4GiB instead of dom0_mem=2GiB,max:2GiB (which I >> started with) makes the errors go away, so workaround confirmed. It's actually dom0_mem=2G,max:4G, I typed something before which was not identical to what I started that machine with. >> [...] >> I think I'm fine with this workaround. > > I think > https://lists.xen.org/archives/html/xen-devel/2014-12/msg00699.html is > the last attempt David made to upstream the fixes. > > Linux is still broken, and these fixes are still necessary. FMI, is this max:4G DTRT for me now in the meantime, or am I still facing more hidden problems while using this workaround? > Boris/Juergen: Any chance you could look into these patches? I have no > idea what they they're in against master, but its also liable its now > more complicated with the host max mfn calculations which have gone in > more recently. Thanks, Hans
Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible
Hi Mike
I have had a look at this. First of all I do not think the CVE is
completely fixed even with the additional patch. I also do not fully
understand how 6111-2.patch is supposed to work. More about this below.
Let us give some example commands.
[1] scp host:/foobar/a* b
[2] scp host:a* b
[3] scp -r host /foobar/a* b
[4] scp -r host a* b
My understanding is that only case 1 is protected by 6111-1.patch
6111-2.patch seems to protect against case 2.
But to my understanding we do not protect against 3 and 4. Am I missing
something?
Anyway I have tried to see if I could reproduce the segfault. I do not know
fully how you have tested it so I decided to copy the new code to a new
test.c file and test different patterns.
The functionality as such seems to be working fine.
I did one change though to make it work. I changed xstrdup to strdup
because I could not find link against it for some reason. Could that be
your problem too?
Essentially my test.c file looks like this:
#include
#include
#include
#include
#include
#define fatal sprintf
... the new functions code here ...
int testpattern(char* pattern) {
char **patterns = NULL;
size_t npatterns = 0;
int i = 0;
printf(" Test pattern %s \n", pattern);
brace_expand(pattern, , );
for (i = 0; i < npatterns; i++) {
printf("Pattern %d: %s\n", i, patterns[i]);
}
}
int main(int argc, char** argv) {
testpattern("filea");
testpattern("dira/filea");
testpattern("dira/file{a,b}");
testpattern("file{a,b}");
testpattern("file*");
testpattern("file{a,b}{c,d}");
testpattern("file{a,b}*");
testpattern("dir{a,b}*/d");
testpattern("dir{a,b}/file*{a,b}*");
}
I could not reproduce the crash. How did you reproduce it?
Best regards
// Ola
On Fri, 8 Mar 2019 at 23:41, Mike Gabriel wrote:
> Hi Colin, hi Debian LTS team,
>
> On Fr 01 Mär 2019 13:24:30 CET, Colin Watson wrote:
>
> > And yes, it looks OK - I'll upload it to unstable shortly.
>
> I have prepared a backport of this newly added patch [1] (see #923486
> for details) to openssh in Debian jessie LTS, but with that patch
> backported to openssh in Debian jessie, I get a segmentation fault
> whenever I copy something using the scp cmdline tool (I have of course
> backported all other patches regarding CVE-2019-6109 and CVE-2019-6111).
>
> I have attached the complete .debdiff between openssh 1:6.7p1-5+deb8u7
> (in jessie-security) and my (not-yet-)proposal for 1:6.7p1-5+deb8u8.
>
> The critical patch is CVE-2019-6111-2.patch. With that patch added I
> get segfaults with scp. Without that patch scp works, but is
> susceptible to the earlier mentioned exploit for CVE-2019-6111.
>
> I am a bit lost here and would appreciate some ideas about what is
> going wrong here.
>
> I will only be able to continue on this on Monday, but maybe someone
> else can offer some genuine input over the weekend. Will be much
> appreciated.
>
> Thanks+Greets,
> Mike
>
> [1]
>
> https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874
> --
>
> mike gabriel aka sunweaver (Debian Developer)
> mobile: +49 (1520) 1976 148
> landline: +49 (4354) 8390 139
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
> mail: sunwea...@debian.org, http://sunweavers.net
>
>
--
--- Inguza Technology AB --- MSc in Information Technology
| o...@inguza.como...@debian.org|
| http://inguza.com/Mobile: +46 (0)70-332 1551 |
---
Bug#924204: persepolis: the packaged version is outdated
Dear Salman, The problem is the incompatibility of the setup.py and debianhelper. It can be solved either with a patch in the Debian Package or directly in upstream. Solving it in the upstream is definitely a better idea, but it requires to test it in different operating systems, as it suppose to work in another operating systems as well. The best help would be rewriting a compatible setup.py and send it to the upstream. -- Sincerely yours, Moein Alinaghian
Bug#884463: passenger: CVE-2017-16355: arbitrary file read
Hey, It looks like version 5.0.30 is not impacted by the CVE[1], and to the best of my abilities, I couldn't reproduce the insecure behavior. I didn't try to read through the source to see if a fix patch *might* still do something useful. Commit 4043718264095cde6623c2cbe8c644541036d7bf[2] does merge cleanly, build and run, but I could not test that it fixes anything (being unable to repro the bug). I've included a debdiff, if you want to include it anyway (I only did a cursory test of the new package, so we would maybe want to do more extensive verification that the patch doesn't break anything). Regards, Martin 1: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16355 2: https://github.com/phusion/passenger/commit/4043718264095cde6623c2cbe8c644541036d7bf debdiff Description: Binary data
Bug#923181: Please add support for reporting mouse button presses to console programs which support mouse tracking
On Sun, Mar 10, 2019 at 10:26:23PM +, Daniel Abrecht wrote:
> Hello Bill
>
> On 10/03/2019 16.41, Bill Allombert wrote:
> > Do you know where in the GPM code this ioctl is used ?
>
> I'm not sure how gpm does it, but console application which use ncurses,
> such as dialog for example, do detect mouse clicks from it. vttest
> doesn't show them though, so it currently does it in another way. It has
> a patch for it though:
> https://sources.debian.org/src/gpm/1.20.4-6.2/patches/todo/xterm-mouse-for-console.patch/
Do you mean nobody used this ioctl before ? This might explain the
problem.
> > Do you have an example of program where this feature will be useful?
>
> I currently only know about dialog.
Could you write a simple test program ?
The problem with vttest is that it does not inhibit the normal copy
paste mechanism. So while it correctly detects the button press, the
result seems useless (try press- move-releas).
This might explain why gpm use another solution.
I attach a patch that try to silent the warning.
Cheers,
--
Bill.
Imagine a large red swirl here.
diff --git a/src/selection.c b/src/selection.c
index aa0fedf..4f65863 100644
--- a/src/selection.c
+++ b/src/selection.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "consolation.h"
@@ -61,8 +62,16 @@ linux_selection(int xs, int ys, int xe, int ye, int sel_mode)
s.sel.sel_mode = sel_mode;
fd = open("/dev/tty0",O_RDONLY);
if (check_mode(fd))
-if (ioctl(fd, TIOCLINUX, ((char*))+1)<0)
+ {
+int err = ioctl(fd, TIOCLINUX, ((char*))+1);
+if (err<0 && !(errno==EINVAL && (sel_mode_SELMOUSEREPORT)))
+/* The kernel return EINVAL for TIOCL_SELMOUSEREPORT when
+ TIOCL_GETMOUSEREPORTING reports 0. Unfortunately this cannot be
+ checked without race conditions, so it is simpler to ignore the
+ error.
+ */
perror("selection: TIOCLINUX");
+ }
close(fd);
}
Bug#924279: sbuild-debian-developer-setup fails within docker
Package: sbuild-debian-developer-setup Version: 0.78.1-1 Severity: normal Dear Maintainer, When I run sbuild-debian-developer-setup within docker, this is what I'll get: root/# sbuild-debian-developer-setup Please run sudo /usr/bin/sbuild-debian-developer-setup at /usr/bin/sbuild-debian-developer-setup line 40. root/# /usr/bin/sbuild-debian-developer-setup Please run sudo /usr/bin/sbuild-debian-developer-setup at /usr/bin/sbuild-debian-developer-setup line 40. A quick web search reveals that sbuild-debian-developer-setup has been working within docker before so please consider fixing it. thanks -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1012-azure (SMP w/2 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: unable to detect Versions of packages sbuild-debian-developer-setup depends on: ii apt-cacher-ng 3.2-1 ii cron [cron-daemon] 3.0pl1-132 ii perl5.28.1-4 ii sbuild 0.78.1-1 ii schroot 1.6.10-6+b1 sbuild-debian-developer-setup recommends no packages. sbuild-debian-developer-setup suggests no packages. -- no debconf information
Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it
2019-03-10 23:21 GMT+01:00, Reinhard Tartler : > On Sat, Mar 9, 2019 at 2:51 PM Carl Eugen Hoyos wrote: > >> Could you test the configure option "--disable-outdev=sdl2"? >> Your report indicates it should fix your issue, I am not convinced but >> if it fixes your issue, Debian should consider using it as the device >> is mostly a (cheap) debug feature. > Wouldn't that video break playback in 'ffplay'? Can you elaborate why you think so? > at the very least, it would break the "SDL2 output device" in libavdevice. Obviously. > I'm not sure if I'd agree with that being a "cheap debug [only] feature". You don't have to. > Can you elaborate what makes you think so? Iirc, I was the only one speaking against its removal. But given that your avconv project never contained an sdl output device I wonder what your expertise is here? Carl Eugen
Bug#908595: krb5-subdomain and ms-subdomain update policy rules ineffective
Control: severity -1 important Control: tags -1 + wontfix Control: tags -1 - patch Hi Dominik, > I discovered the following security bug in bind9 a few weeks ago, and > responsibly disclosed it to the ISC security officer. Unfortunately, until > today they did not acknowledge it is a security issue - in contrast, they > proved that they do not fully understand the issue, and now have added a new > feature in the 9.11.4.P2 release which wrongly addresses this security > issue. While I totally understand your frustration with upstream in regards to handling this, I'm sure you agree diverging from upstream on this would create a lot more problems than it solves. If you supplied a patch to NEWS.Debian explaining this and the proper way to mitigate it (use the newly introduced krb5-subself) I'm sure we could include it for Buster. Bernhard
Bug#861027: gprolog bug still there despite easy fixes
On Wed, Jul 04, 2018 at 06:55:11PM +0300, Cedric Ware wrote: > > Hello, > > I don't think anything changed with this bug, which still prevents > gprolog's inclusion in any stable release, and affects Ubuntu as well. > > I believe just pulling the latest upstream source would fix it. > > Alternatively, if downgrading to the stable gprolog-1.4.4 is an option, > the attached patch lets it compile with gcc 6. Tested on Debian 9.4. Hi Cedric, I had a try at this. I pulled the latest upstream release 1.4.5 from gprolog.org [1], which is dated February of 2019 and it exhibits the same problem reported in this bug report. Also problematic is that the sources for version 1.4.5 found on gprolog.org differ substantially from the 1.4.5 sources found in Debian. I suspect that we should report this upstream or downgrade to 1.4.4 as previously suggested. Cheers, tony [1] http://www.gprolog.org/gprolog-1.4.5.tar.gz > > Thanks in advance, > Cedric Ware. > diff -ru gprolog-1.4.4.orig/src/Ma2Asm/x86_64_any.c > gprolog-1.4.4/src/Ma2Asm/x86_64_any.c > --- gprolog-1.4.4.orig/src/Ma2Asm/x86_64_any.c2013-04-22 > 13:52:16.0 +0200 > +++ gprolog-1.4.4/src/Ma2Asm/x86_64_any.c 2018-05-10 16:31:10.534235899 > +0200 > @@ -204,8 +204,8 @@ >strcpy(asm_reg_cp, Off_Reg_Bank(MAP_OFFSET_CP)); > #endif > > -#ifdef M_x86_64_darwin > - pic_code = 1; /* NB: on darwin everything is PIC code > */ > +#if defined(M_x86_64_darwin) || defined(M_x86_64_bsd) || > defined(M_x86_64_linux) > + pic_code = 1; /* NB: on darwin and BSD everything is > PIC code, last gcc 6 needs this for linux */ > #elif defined(_WIN32) >pic_code = 0; /* NB: on MinGW nothing is needed for > PIC code */ > #endif signature.asc Description: PGP signature
Bug#923181: Please add support for reporting mouse button presses to console programs which support mouse tracking
Hello Bill On 10/03/2019 16.41, Bill Allombert wrote: > Do you know where in the GPM code this ioctl is used ? I'm not sure how gpm does it, but console application which use ncurses, such as dialog for example, do detect mouse clicks from it. vttest doesn't show them though, so it currently does it in another way. It has a patch for it though: https://sources.debian.org/src/gpm/1.20.4-6.2/patches/todo/xterm-mouse-for-console.patch/ > Do you have an example of program where this feature will be useful? I currently only know about dialog. But I'm working on a console keyboard which will need that functionality. I intend to use it on my librem 5 smartphone. It isn't finished yet though. Here are the sources of the different components of it and a video: https://github.com/Daniel-Abrecht/console-keyboard-multiplexer https://github.com/Daniel-Abrecht/console-keyboard-basic https://github.com/Daniel-Abrecht/libttymultiplex https://dpa.li/console-keyboard-multiplexer-demo.mp4 Regarding the other things you mentioned which could be improved, I'll create a new patch this week. Regards, Daniel Abrecht signature.asc Description: OpenPGP digital signature
Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it
On Sat, Mar 9, 2019 at 2:51 PM Carl Eugen Hoyos wrote: > Hi! > > Could you test the configure option "--disable-outdev=sdl2"? > Your report indicates it should fix your issue, I am not convinced but > if it fixes your issue, Debian should consider using it as the device > is mostly a (cheap) debug feature. > > Please report back, Carl Eugen > > Wouldn't that video break playback in 'ffplay'? - at the very least, it would break the "SDL2 output device" in libavdevice. I'm not sure if I'd agree with that being a "cheap debug [only] feature". Can you elaborate what makes you think so? -- regards, Reinhard
Bug#890950: RE: Bug#902416: systemd: systemctl hibernate: unable to resume after upgrade
On Sun, 2019-03-10 at 19:25 +0100, Michael Biebl wrote: > Hi Mario, > > > On Fri, 6 Jul 2018 12:41:37 + wrote: [...] > > Yes I could see two swap partitions causing the wrong one to be picked. > > It's trying to select the bigger of the two. > > > > If they don't match the one you're putting in > > /etc/initramfs-tools/conf.d/resume > > then that would cause problems. Please do confirm if you switch what's in > > initramfs conf.d/resume that the problem is fixed. > > > > Really matching code is needed for the initramfs-tools. I submitted some > > patches > > that may help here. You can refer to them at the end of this bug report: > > > > Somehow we dropped the ball here. > What's the state regarding those initramfs-tools patches? > Is there a chance to get them into buster? > If not, should we revert commit > https://github.com/systemd/systemd/commit/17c40b3a8fbfb797110c88d749bd5 > > What do you suggest? The current situation doesn't seem ideal. I think it would make sense for systemd to only set the hibernation device if it's not already set (i.e. if /sys/power/resume contains "0:0\n"). Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
On 10/03/2019 21:35, Hans van Kranenburg wrote: > found -1 4.19.20-1 > thanks > > Hi, > > Reviving a thing from Jan 2017 here. I don't have this thread in my > mailbox, so no inline quotes. > > I just installed some HP z820 workstation and rebooted it into Xen > 4.11.1+26-g87f51bf366-3 with linux 4.19.20-1 as dom0 kernel. > > During boot I'm greeted by a long list of... > > [ 14.518793] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536 > bytes) > [ 14.518899] mpt3sas :02:00.0: swiotlb buffer is full > [ 14.518956] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536 > bytes) > [ 14.518988] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes! > [ 14.519081] mpt3sas :02:00.0: swiotlb buffer is full > [ 14.519309] sd 6:0:1:0: pci_map_sg failed: request for 1310720 bytes! > [ 14.524611] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536 > bytes) > [ 14.527309] mpt3sas :02:00.0: swiotlb buffer is full > [ 14.527405] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes! > [...] > > ...and some hangs here and there. This indeed did not happen when > booting just Linux, without Xen. > > Some searching brought me to this Debian bug. So, thanks for writing > down all kinds of research here already. Even if it's not fixed upstream > yet, this helps a lot. :-) > > Using dom0_mem=2GiB,max:4GiB instead of dom0_mem=2GiB,max:2GiB (which I > started with) makes the errors go away, so workaround confirmed. > > I can try any of the linked patches, but I see that in message 54, > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850425#54 > Andrew says: "IIRC, they were essentially rejected,". Next message, Ian > asks "Do you have a reference ?", but I don't see any fup on that. > > I think I'm fine with this workaround. > > If someone will ever work on the upstream patches, then this is just to > let know that I might be able to help testing. However, I only have one > of this type of box and it's gonna be installed as server at some > non-profit organization without OOB access, replacing even older donated > hardware, so, it will be kinda limited... :) I think https://lists.xen.org/archives/html/xen-devel/2014-12/msg00699.html is the last attempt David made to upstream the fixes. Linux is still broken, and these fixes are still necessary. Boris/Juergen: Any chance you could look into these patches? I have no idea what they they're in against master, but its also liable its now more complicated with the host max mfn calculations which have gone in more recently. ~Andrew
Bug#891434: Bug#923839: shim-signed: setup of shim-signed failed with 'Could not delete variable: No space left on device'
Control: reassign 891434 src:grub2 Control: forcemerge 891434 923839 On Tue, Mar 05, 2019 at 03:43:31PM -0800, Steve Langasek wrote: > But I'm reassigning this bug to grub2, because I think the right answer for > nearly all efibootmgr write failures on update of the bootloader packages is > that grub should not be writing to nvram at all. Rather, in the common case > of a bootloader upgrade, the contents being written to nvram will match what > is already there. By detecting that there are no changes, we save ourselves > a write, which in the exceptional cases sidesteps a write failure, and in > the common case, reduces wear on the nvram which may have limited write > cycles. This is the same as #891434, which I've been working on recently, and at a high level you and I have reached the same conclusions about what's needed. (I've also been discussing it with Steve McIntyre, again reaching similar conclusions.) The problem that's been delaying this is that efibootmgr doesn't expose the interfaces we need. There's no way to ask it to write a variable only if it's changed, or even (any more) to write a new variable to a test file so that it can be compared with the existing contents in order to determine whether to set the variable. I initially thought that we might be able to ask efibootmgr to delete all but one entry from the same distributor and then to modify that one, but even that doesn't seem to be possible at the moment. And even if we did change efibootmgr to provide something along these lines (it might separately be a good idea to get it to minimise writes, at the very least), (a) it would be difficult to guarantee that we have a new enough version in an upstreamable way, and (b) having to fork efibootmgr several times in a single grub-install operation is annoying anyway. So, I've been working on converting grub-install to use libefivar and libefiboot directly, which are libraries used by modern-ish versions of efibootmgr. In many ways this is much nicer: we can say what we mean about exactly how variables are to be manipulated rather than operating at arm's length via a command-line interface that wasn't designed to offer this sort of fine control. In some ways it's uglier: we have to duplicate more of efibootmgr's logic than I'd like in order to build Boot* variables, such as EDD version detection, and it's possible that it will increase the maintenance burden for the future a bit. But regardless, this is the only approach I can think of that stands any chance of fixing this bug in the medium term, so it's what we've got. I got this almost working at the Cambridge BSP today before I ran out of time (very nearly bricking my own laptop in the process ...). I need to add suitable --debug messages, finish getting it working, ensure that it's only rewriting variables where needed, and generally tidy up the fairly large pile of code involved, so there's still probably at least four hours of work left to do on it, not to mention upstream review. However, I'm reasonably hopeful that I'll have this done for buster. -- Colin Watson [cjwat...@debian.org]
Bug#725884: hdparm: Standby (spindown) timeout option (-S) has no effect
Hi, I recently experienced the same issue here. Until Debian Stretch everything was fine, but I recently upgraded to Debian Buster (pre-release). I previously just set the spindown time and this used to work fine. Hdparm -Y on the devices (using the plain /dev/sd? paths) still worked, but automatic spindown was somehow broken. I tried enabling APM (setting it to 127) but that didn't change a thing - I previously only set spindown time and that worked just fine. I then switched to /dev/disk/by-id/ paths, that didn't work either. What I have noticed, however, is that spindown_time settings up to 59 work; anything from 60 (5 minutes) and up won't. Hope this helps. Cheers Stijn
Bug#923034: O: freeradius -- high-performance and highly configurable RADIUS server
[CCing the ML, might see a bit more traction there] On Sat, Feb 23, 2019 at 11:13:14AM +0100, Michael Stapelberg wrote: > I am orphaning this package effective immediately. I have never personally > used > FreeRADIUS, and only stepped in to help when I saw the package was in bad > shape. A few days ago I was talking to a co-worker who is with the group running our RADIUS infrastructure for the university on FreeRADIUS. He might be interested to help maintaining it in Debian. He's not a DD/DM and will need a bit of procedural help, but that would be a start. What's the current status regarding the "FreeRADIUS Packaging Team"? There are five persons listed in Uploaders, with Bugs filed for two of them to be removed and Michael stepping down. Sam, judging from #806617, is no longer interested as well. That would leave Mark (Cced). Dimiti (also Cced) is among Michael the only member of the Salsa Group. Bernhard
Bug#909379: segfault when leaving the python3-dbg interpreter
Hi Picca (2019.03.09_20:56:03_-0800) > I'm interested to hear about any API/ABI breakage in cffi modules, but I > just can't find the culprits, here. Sorry, was tired and closed the wrong clone of the bug. However, this bug is also no longer reproduceable, as mentioned in message 62 from Thomasz. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
found -1 4.19.20-1 thanks Hi, Reviving a thing from Jan 2017 here. I don't have this thread in my mailbox, so no inline quotes. I just installed some HP z820 workstation and rebooted it into Xen 4.11.1+26-g87f51bf366-3 with linux 4.19.20-1 as dom0 kernel. During boot I'm greeted by a long list of... [ 14.518793] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536 bytes) [ 14.518899] mpt3sas :02:00.0: swiotlb buffer is full [ 14.518956] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536 bytes) [ 14.518988] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes! [ 14.519081] mpt3sas :02:00.0: swiotlb buffer is full [ 14.519309] sd 6:0:1:0: pci_map_sg failed: request for 1310720 bytes! [ 14.524611] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536 bytes) [ 14.527309] mpt3sas :02:00.0: swiotlb buffer is full [ 14.527405] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes! [...] ...and some hangs here and there. This indeed did not happen when booting just Linux, without Xen. Some searching brought me to this Debian bug. So, thanks for writing down all kinds of research here already. Even if it's not fixed upstream yet, this helps a lot. :-) Using dom0_mem=2GiB,max:4GiB instead of dom0_mem=2GiB,max:2GiB (which I started with) makes the errors go away, so workaround confirmed. I can try any of the linked patches, but I see that in message 54, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850425#54 Andrew says: "IIRC, they were essentially rejected,". Next message, Ian asks "Do you have a reference ?", but I don't see any fup on that. I think I'm fine with this workaround. If someone will ever work on the upstream patches, then this is just to let know that I might be able to help testing. However, I only have one of this type of box and it's gonna be installed as server at some non-profit organization without OOB access, replacing even older donated hardware, so, it will be kinda limited... :) Hans
Bug#924277: ITP: puppet-module-deric-zookeeper -- Puppet module for Zookeeper
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: puppet-module-deric-zookeeper Version : 0.8.4 Upstream Author : Tomas Barton * URL : https://github.com/deric/puppet-zookeeper * License : Apache-2.0 Programming Lang: Puppet Description : Puppet module for Zookeeper Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This module manages both the installation and configuration of Zookeeper. Note: This module is needed for setting-up Ceilometer coordination using Zookeeper. Tests are showing that redis doesn't work in cluster for Ceilometer.
Bug#924274: RFS: golang-github-gokyle-fswatch
Dear Go team, I am looking for a sponsor for the package "golang-github-gokyle-fswatch". This package is a prerequisite for upcoming package "lazygit" (#908894). https://salsa.debian.org/go-team/packages/golang-github-gokyle-fswatch The package was tested on both gbp and sbuild. It's also lintian-clean. Please consider to review and upload it. Any kind of suggestions are appreciated. Thanks, -- Jongmin Kim OpenPGP key located at https://jongmin.dev/pgp OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE 9472 D39D 8D29 BAF3 6DF8 signature.asc Description: PGP signature
Bug#923465: fixed in freecad 0.18~pre1+dfsg1-5
Hi Salman, On 3/10/19 9:05 AM, Salman Mohammadi wrote: > Dear Maintainer, > > > I could install this package (0.18~pre1+dfsg1-4) with no problem and > this bug seems to be resolved. But on the tracker page, this package has > been marked for autoremoval on 29 March, with this message: > > Version 0.18~pre1+dfsg1-4 of freecad is marked for autoremoval from > testing on Fri 29 Mar 2019. It is affected by #923465. You should try to > prevent the removal by fixing these RC bugs. This message will go away once 0.18~pre1+dfsg1-5 migrates to testing in one day and replaces the -4 version.
Bug#915291: java3ds-fileloader FTBFS: error: package com.sun.j3d.utils.applet does not exist
On Sun, Dec 02, 2018 at 04:36:37PM +0200, Adrian Bunk wrote: > Source: java3ds-fileloader > Version: 1.2+dfsg-3 > Severity: serious > Tags: ftbfs > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/java3ds-fileloader.html > > ... > build: > [mkdir] Created dir: > /build/1st/java3ds-fileloader-1.2+dfsg/debian/build/classes > [javac] /build/1st/java3ds-fileloader-1.2+dfsg/debian/build.xml:13: > warning: 'includeantruntime' was not set, defaulting to > build.sysclasspath=last; set to false for repeatable builds > [javac] Compiling 38 source files to > /build/1st/java3ds-fileloader-1.2+dfsg/debian/build/classes > [javac] > /build/1st/java3ds-fileloader-1.2+dfsg/com/microcrowd/loader/java3d/max3ds/Main.java:59: > error: package com.sun.j3d.utils.applet does not exist > [javac] import com.sun.j3d.utils.applet.MainFrame; java3d (1.5.2+dfsg-16) unstable; urgency=medium * No longer build the applet to fix the build failure with Java 11 (Closes: #912468) * Standards-Version updated to 4.2.1 -- Emmanuel Bourg Sun, 04 Nov 2018 22:42:37 +0100 Based on this changelog entry, I don't know whether we should reassign this bug back to java3d or request removal of the bava3ds-fileloader package. Is there any chance that we'll be able to restore the applet package in java3d? Cheers, tony signature.asc Description: PGP signature
Bug#866898: Fwd: Re: Bug #866898 - Xorg issues
Forwarded Message Subject:Re: Bug #866898 - Xorg issues Date: Sun, 10 Mar 2019 20:44:24 + From: Matthew Vernon To: Andrew M.A. Cater Hi, On 10/03/2019 14:06, Andrew M.A. Cater wrote: Lurking in Debian BSP in Cambridge: does the above bug still apply? This was from an upgrade from Jessie -> Stretch and the end of the message chain suggests there's a workaround/ It's still a problem here, I'm afraid. I've not tried editing bash_logout, but as the issue is typically when switching out of X (rather than ending a login session), I doubt that'll fix it. Regards, Matthew
Bug#924276: unblock: dahdi-linux/1:2.11.1.0.20170917~dfsg-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package dahdi-linux * Fix of a serius bug (#923983) * An autopkgtest that works (the existing one was failing) and that checks more functionality. * Many smaller packaging fixes. I initially intended version 1:2.11.1.0.20170917~dfsg-6 to meet the soft freeze deadline and hence included in it a number of cleanups. Apart from those trivial changes, the only real change in the package itself (rather than the tests) was the addition of the script /usr/share/dahdi/dahdi/dahdi-modules that I used extensively in my own private packages and consider well-tested. The upload triggered a bug due to hardwired scripts. I fixed this (no bug filed). I also realised that the tests were not working properly when run in the test bed (I only tried them manually before). Fixed one and did what I could for the other. So sadly there are quite a few changes. But I don't want to see this package removed, as this would force the removal of asterisk as well. -- Tzafrir Debdiff: diff -Nru dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog --- dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog 2018-10-12 14:35:56.0 +0300 +++ dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog 2019-03-10 15:49:50.0 +0200 @@ -1,3 +1,31 @@ +dahdi-linux (1:2.11.1.0.20170917~dfsg-7) unstable; urgency=medium + + * dkms: use standard scripts (Closes: #923983). + * work around #923983 at upgrade time. + * Use dh_dkms instead of dh --with dkms, for the m-a -generated package. + * Standard version 4.3.0. + * More comprehensive and robust autopkgtest tests. +- The dkms-modules test is skippable for now. + * debian/dahdi-dkms.install is a generated file. + * dkms metainfo: same license as source. + + -- Tzafrir Cohen Sun, 10 Mar 2019 15:49:50 +0200 + +dahdi-linux (1:2.11.1.0.20170917~dfsg-6) unstable; urgency=medium + + * install dahdi-modules + * A new test: dynamic-loc-call + * dkms: also install oct612 module (Closes: #922008) + * dkms test: try loading all modules + * Rules-Require-Root: no + * rules: remove get-orig-source + * trivial lintian fixes + * debhelper compat level 12 + * rules: Use dpkg makefiles instead of our own parsing + * tests: uninstall modules + + -- Tzafrir Cohen Mon, 04 Mar 2019 23:29:36 +0200 + dahdi-linux (1:2.11.1.0.20170917~dfsg-5) unstable; urgency=medium * Added dpkg-dev as dependency for dpkg-architecture used by the @@ -95,7 +123,7 @@ - Patch dahdi_linux_extra updated to the 2.9.2 branch. * Use hotplug support: - patch hotplug_mod_params: change default of module parameters. - * Multiarch support. + * Multiarch support. * udev rules moved to package dahdi (in source package dahdi-tools). * Add a test for non-free files in case uscan was used. * Remove unused variables from control file. @@ -115,7 +143,7 @@ dahdi-linux (1:2.7.0+dfsg-1) unstable; urgency=low - [ Tzafrir Cohen ] + [ Tzafrir Cohen ] * New upstream release: - Patch fix_define_dev dropped: merged upstream. - Patch fix_xpp_usermode dropped: merged upstream. @@ -155,13 +183,13 @@ * Updated dahdi-linux-extra: - "Upstream" is now a complete git mirror. - Actually include ap400 in the list of modules to build. -- Updated OpenVox drivers: opvxa1200 is a subdirectory +- Updated OpenVox drivers: opvxa1200 is a subdirectory - Updated OpenVox drivers: opvxd115 added (digital cards). * Patch define_spinlock: include a (slightly big) build fix from upstream. * Standards version 3.9.2 (no change needed). * Switch to dh. * Patch notest: Remove a bogus upstream 'test' target. - * Lintian override for an odd interpteter a dummy kernel module init script. + * Lintian override for an odd interpteter a dummy kernel module init script. * Dahdi udev rules are now named 'dahdi-linux.conf'. * Patch xpp_fix_2fxs6fxo: bugfix for Xorcom 2FXX6FXO module code. @@ -171,7 +199,7 @@ * New Upstream release. - Patch uk_rotary dropped: merged upstream. -- Patch oslec_include_2634 dropped: merged upstream. +- Patch oslec_include_2634 dropped: merged upstream. - Patch xpp_usb_buffer_2635 dropped: merged upstream. - Patch voicebus_sem_h_2635 dropped: merged upstream. * dahdi_linux_extra now includes AP400 drivers (Closes: #582095). @@ -195,7 +223,7 @@ dahdi-linux (1:2.3.0.1+dfsg-1) unstable; urgency=low * New upstream version (Closes: #546319). - * Patch no_dummy removed: merged upstream. + * Patch no_dummy removed: merged upstream. * Patch wcb4xxp_extra_trunk removed: merged upstream. * Patch chanmute: make it also explicitly disable the untested DAHDI_AUDIO_NOTIFY. @@ -214,10 +242,10 @@ * Patch wcb4xxp_extra_trunk: backport extra PCI IDs for wcb4xxp (more HFC-[248]S cards). * Switch to a @debian.org address. -
Bug#924274: ITP: golang-github-gokyle-fswatch -- go library for simple UNIX file system watching
Package: wnpp Severity: wishlist Owner: Jongmin Kim X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-gokyle-fswatch Version : 0.0~git20121217.1dbdf83-1 Upstream Author : 2012 Kyle Isom * URL : https://github.com/gokyle/fswatch * License : ISC Programming Lang: Go Description : go library for simple UNIX file system watching This package provides a simple UNIX file system watching in Go. . It is based around the Watcher struct, which should be initialised with either NewWatcher or NewAutoWatcher. Both functions accept a variable number of string arguments specfying the paths to be loaded, which may be globbed, and return a pointer to a Watcher. This value can be started and stopped with the Start() and Stop() methods. The Watcher will automatically stop if all the files it is watching have been deleted. This package is a prerequisite for upcoming package "lazygit" (#908894). -- Jongmin Kim OpenPGP key located at https://jongmin.dev/pgp OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE 9472 D39D 8D29 BAF3 6DF8 signature.asc Description: PGP signature
Bug#924275: Pulls in lvm2 packages on systems not needing them
Package: e2fsprogs Version: 1.45.0-1 Severity: normal Hi! While I like the new fsck-via-LVM-snapshot feature, I think adding lvm2 to Recommends is too agressive here. On systems not using LVM this will needlessly pull in the whole LVM/DM machinery, including changes to the initramfs, as long as apt is in its default "install-recommends" configuration. Only on systems where the system admin has changed the default to "no-install-recommends" nothing will happen. I argue that you should remove "Recommends: lvm2" again, because systems not using LVM can't use the background-fsck anyway and don't need the additional packages and on systems where LVM is in use, the needed packages are already present. Grüße Sven -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (200, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages e2fsprogs depends on: ii libblkid12.33.1-0.1 ii libc62.28-8 ii libcom-err2 1.45.0-1 ii libext2fs2 1.45.0-1 ii libss2 1.45.0-1 ii libuuid1 2.33.1-0.1 Versions of packages e2fsprogs recommends: ii e2fsprogs-l10n 1.45.0-1 ii lvm22.03.02-2 Versions of packages e2fsprogs suggests: ii e2fsck-static 1.45.0-1 ii fuse2fs1.45.0-1 ii gpart 1:0.3-6 ii parted 3.2-24 -- Configuration Files: /etc/e2scrub.conf changed [not included] -- debconf-show failed
Bug#895320: Prototype fix
A prototype patch is attached. This splits up the offending .dot file
into two separate .dot files, each with a single graph. The package then
builds. Please double-check this. You'd need to ship this as a patch in
debian/patches. Let me know if you'd like me to finish this as an nmu.
>From 307cd1529334cd4759fd7d4afd56ec279616f4f4 Mon Sep 17 00:00:00 2001
From: Dima Kogan
Date: Sun, 10 Mar 2019 13:15:20 -0700
Subject: [PATCH] prototype fix for 895320
---
presentation/Makefile | 4 ++--
presentation/{my_prjs.dot => my_prjs1.dot} | 8
presentation/my_prjs2.dot | 7 +++
presentation/presentation.tex | 5 -
4 files changed, 13 insertions(+), 11 deletions(-)
rename presentation/{my_prjs.dot => my_prjs1.dot} (85%)
create mode 100644 presentation/my_prjs2.dot
diff --git a/presentation/Makefile b/presentation/Makefile
index cdafd80..fb621dc 100644
--- a/presentation/Makefile
+++ b/presentation/Makefile
@@ -13,7 +13,7 @@ dvi : presentation.dvi
.SUFFIXES: .ps .eps .pdf .dvi .tex .dot
-presentation.ps presentation.pdf presentation.dvi: my_prjs.eps dep_graph.eps
+presentation.ps presentation.pdf presentation.dvi: my_prjs1.eps my_prjs2.eps dep_graph.eps
.ps.pdf:
${PROG.${PS2PDF}} "$<" "$@"
@@ -44,6 +44,6 @@ clean-garbage:
myprojects.tex : presentation.tex
awk '/^%%%begin-myprojects/, /^%%%end-myprojects/' \
${.ALLSRC} > ${.TARGET}
-myprojects.ps myprojects.pdf myprojects.dvi: my_prjs.eps
+myprojects.ps myprojects.pdf myprojects.dvi: my_prjs1.eps my_prjs2.eps
.include
diff --git a/presentation/my_prjs.dot b/presentation/my_prjs1.dot
similarity index 85%
rename from presentation/my_prjs.dot
rename to presentation/my_prjs1.dot
index e2bcfe0..14a799c 100644
--- a/presentation/my_prjs.dot
+++ b/presentation/my_prjs1.dot
@@ -42,11 +42,3 @@ digraph FSA {
"pipestatus" -> "pkg_summary-utils";
}
-
-digraph FSA {
- graph [ ratio=compress layout=dot rankdir=UB ratio=0.4 ];
-
- node [ shape = hexagon style=filled fontsize=20 ];
- "lua-alt-getopt";
- "judyhash";
-}
diff --git a/presentation/my_prjs2.dot b/presentation/my_prjs2.dot
new file mode 100644
index 000..d4639cc
--- /dev/null
+++ b/presentation/my_prjs2.dot
@@ -0,0 +1,7 @@
+digraph FSA {
+ graph [ ratio=compress layout=dot rankdir=UB ratio=0.4 ];
+
+ node [ shape = hexagon style=filled fontsize=20 ];
+ "lua-alt-getopt";
+ "judyhash";
+}
diff --git a/presentation/presentation.tex b/presentation/presentation.tex
index 0a388f3..449dc44 100644
--- a/presentation/presentation.tex
+++ b/presentation/presentation.tex
@@ -1256,7 +1256,10 @@ hello: ELF 64-bit MSB executable, SPARC V9, relaxed
\begin{block}{My opensource projects using
mk-configure (filled hexagon), Mk files (box) and others (oval)}
\begin{figure}
- \includegraphics[width=\textwidth, height=0.60\textheight, keepaspectratio=false]{my_prjs.eps}
+ \includegraphics[width=\textwidth, height=0.60\textheight, keepaspectratio=false]{my_prjs1.eps}
+\end{figure}
+\begin{figure}
+ \includegraphics[width=\textwidth, height=0.60\textheight, keepaspectratio=false]{my_prjs1.eps}
\end{figure}
%\begin{figure}
% \includegraphics[width=0.7\textwidth, height=0.10\textwidth, keepaspectratio=false]{my_prjs2.eps}
--
2.20.0.rc2
Bug#924273: makehuman: Always fail in export
Package: makehuman
Version: 1.1.1-1.1
Severity: important
Tags: patch
Dear Maintainer,
When I used export menu in makehuman, I always got errors as follows,
and no exported file was created.
--error details
Creating folder /home/mine/makehuman/v1/exports/textures
Exception during event onFileSelected
Traceback (most recent call last):
File "./core/events3d.py", line 211, in callEvent
method(event)
File "./apps/gui/guiexport.py", line 112, in onFileSelected
exporter.export(gui3d.app.selectedHuman, filename)
File "plugins/9_export_collada/__init__.py", line 132, in export
exportCollada(filename("dae"), cfg)
File "plugins/9_export_collada/mh2collada.py", line 79, in
exportCollada
meshes = [obj.mesh.clone(config.scale, filterMaskedVerts=not
config.hiddenGeom) for obj in objects]
File "./core/module3d.py", line 160, in clone
self.filterMaskedVerts(other, update=False)
File "./core/module3d.py", line 311, in filterMaskedVerts
inverse_uv_idx[uv_idx] = np.arange(self.texco.shape[0],
dtype=np.int32)
ValueError: shape mismatch: value array of shape (21334,) could not be
broadcast to indexing result of shape (14517,)
I found this problem was already fixed in upstream(*1), so that I
suggest patch attached this report.
(*1) Upstream's commit: a5b4e3f8 in
github.com/makehumancomunity/makehuman
Of cause, I already apply this patch to makehuman in my debian box,
then I confirmed this problem was fixed.
Could you apply this patch?
Thank you in advance,
---
Takahide Nojima
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500,
'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8),
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages makehuman depends on:
ii makehuman-data 1.1.1-1.1
ii python-numpy1:1.16.2-1
ii python-opengl 3.1.0+dfsg-2
ii python-qt4 4.12.1+dfsg-2+b1
ii python-qt4-gl 4.12.1+dfsg-2+b1
ii python2.7 2.7.16-1
makehuman recommends no packages.
Versions of packages makehuman suggests:
pn makehuman-doc
-- no debconf information
diff -Nur debian.orig/changelog debian/changelog
--- debian.orig/changelog 2019-02-25 18:39:08.0 +0900
+++ debian/changelog 2019-03-11 03:21:06.703116091 +0900
@@ -1,3 +1,10 @@
+makehuman (1.1.1-1.2) unstable; urgency=medium
+
+ * Fix shape mismatch error in export menu by
+a5b4e3f8 commit of github.com/makehumancomunity/makehuman.
+
+ -- Takahide Nojima Mon, 11 Mar 2019 03:16:14 +0900
+
makehuman (1.1.1-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nur debian.orig/patches/fix-export-error.patch debian/patches/fix-export-error.patch
--- debian.orig/patches/fix-export-error.patch 1970-01-01 09:00:00.0 +0900
+++ debian/patches/fix-export-error.patch 2019-03-11 02:49:09.145980410 +0900
@@ -0,0 +1,11 @@
+--- a/makehuman/core/module3d.py
b/makehuman/core/module3d.py
+@@ -308,7 +308,7 @@
+ fuvs = self.fuvs[self.face_mask]
+ uv_idx = np.unique(fuvs.reshape(-1))
+ inverse_uv_idx = - np.ones(self.texco.shape[0], dtype=np.int32)
+-inverse_uv_idx[uv_idx] = np.arange(self.texco.shape[0], dtype=np.int32)
++inverse_uv_idx[uv_idx] = np.arange(uv_idx.shape[0], dtype=np.int32)
+ for i in xrange(self.vertsPerPrimitive):
+ fuvs[:,i] = inverse_uv_idx[fuvs[:,i]]
+
diff -Nur debian.orig/patches/series debian/patches/series
--- debian.orig/patches/series 2019-02-25 18:39:08.0 +0900
+++ debian/patches/series 2019-03-11 03:34:03.322022076 +0900
@@ -1,2 +1,3 @@
01_makehuman.py.patch
sphinx.ext.pngmath.patch
+fix-export-error.patch
Bug#924271: openarena: crashes at launch with "Couldn't compile shader" message.
Yes, that fixes the problem. Thanks! On Sun, 10 Mar 2019, 19:57 Simon McVittie, wrote: > Control: reassign -1 ioquake3 1.36+u20181222.e5da13f~dfsg-1 > Control: tags -1 + moreinfo > Control: affects -1 openarena quake3 > Control: affects 923226 + openarena quake3 > > On Sun, 10 Mar 2019 at 19:42:20 +, Matthew Hoare wrote: > >Program failed to launch with a lengthy error message (attached). > > Please upgrade ioquake3 to 1.36+u20181222.e5da13f~dfsg-2 (in unstable) > and try again: it should be fixed in that version. This looks very similar > to #923226, and indeed you seem to have the same older Intel GPU as the > reporter of #923226. > > smcv >
Bug#922657: Misfires when variable is put in a string
On Sun, Mar 10 2019, Gabriel F. T. Gomes wrote: > > It only adds the backslash to unset variables, but not when the variable > is set, for instance: > > zless /usr/share/$PATH/ > > does nothing, whereas > > zless /usr/share/$ASDF/ > zless /usr/share/\$ASDF/ > > causes the problem you describe... Marking as confirmed and upstream. Now reported upstream as https://github.com/scop/bash-completion/issues/290
Bug#924271: openarena: crashes at launch with "Couldn't compile shader" message.
Control: reassign -1 ioquake3 1.36+u20181222.e5da13f~dfsg-1 Control: tags -1 + moreinfo Control: affects -1 openarena quake3 Control: affects 923226 + openarena quake3 On Sun, 10 Mar 2019 at 19:42:20 +, Matthew Hoare wrote: > Program failed to launch with a lengthy error message (attached). Please upgrade ioquake3 to 1.36+u20181222.e5da13f~dfsg-2 (in unstable) and try again: it should be fixed in that version. This looks very similar to #923226, and indeed you seem to have the same older Intel GPU as the reporter of #923226. smcv
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
I tried the fix_db.pl script, there was no output. Here is the only relevant difference: --- debconf.old/config.dat▸-2019-03-10 18:43:37.265483165 +0100 +++ debconf/config.dat▸-2019-03-10 18:43:41.261085496 +0100 @@ -1151,7 +1151,7 @@ Name: libpam-modules/disable-screensaver Template: libpam-modules/disable-screensaver -Owners: libpam-modules +Owners: libpam-modules, libpam-modules:amd64 Name: libpam-runtime/conflicts Template: libpam-runtime/conflicts Other differences are only label translations for libraries/restart-without-asking in templates. -- Julien Leproust
Bug#924272: decopy: FTBFS (mv: cannot stat 'README.1': No such file or directory)
Package: src:decopy Version: 0.2.4.1-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.7 setup.py config running config debian/rules override_dh_auto_build make[1]: Entering directory '/<>' dh_auto_build I: pybuild base:217: /usr/bin/python3 setup.py build running build running build_py creating /<>/.pybuild/cpython3_3.7/build/decopy copying decopy/dep5.py -> /<>/.pybuild/cpython3_3.7/build/decopy copying decopy/matchers.py -> /<>/.pybuild/cpython3_3.7/build/decopy copying decopy/cmdoptions.py -> /<>/.pybuild/cpython3_3.7/build/decopy copying decopy/output.py -> /<>/.pybuild/cpython3_3.7/build/decopy copying decopy/decopy.py -> /<>/.pybuild/cpython3_3.7/build/decopy copying decopy/__init__.py -> /<>/.pybuild/cpython3_3.7/build/decopy copying decopy/parsers.py -> /<>/.pybuild/cpython3_3.7/build/decopy copying decopy/res.py -> /<>/.pybuild/cpython3_3.7/build/decopy copying decopy/datatypes.py -> /<>/.pybuild/cpython3_3.7/build/decopy copying decopy/tree.py -> /<>/.pybuild/cpython3_3.7/build/decopy ronn README.md roff: ./README.md.1 html: ./README.md.1.html+man mv README.1 decopy.1 mv: cannot stat 'README.1': No such file or directory make[1]: *** [debian/rules:11: override_dh_auto_build] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:6: build-indep] Error 2 dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit status 2 The build was made in my autobuilder with "dpkg-buildpackage -A" and it also fails here: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/decopy.html 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#867590: networkd removes statically set default route when RA expires
On Sun, Mar 10, 2019 at 12:12:57AM +0100, Michael Biebl wrote: > Is this still an issue with 241-1 from unstable? Sorry, this is a productive system, I cannot just do upgrades to unstable in that network setup to check wether a bug reported and worked around nearly two years ago was fixed upstream. Addiitonally, the network that the system is located in was re-built in the last two years and doesn't use HSRP any more. I guess we'll see after buster release whether the issue is fixedin whatever buster gets released with. Feel free to ping me to check whether removing the workaround breaks the system or not. I have made a note in the machine's work log and in the *.network file to try removing the workaround during the buster upgrade. Greetings Marc
Bug#895320: (no subject)
reassign -1 mk-configure
thanks
Hi. I looked into this, and the conclusions are:
- This is not an FTBFS for graphviz, but rather for mk-configure. The
graphviz package builds just fine, but ...
- The "dot" executable it produces has a bug: graphs spanning multiple
pages contain incorrect postscript
- This is an upstream bug in graphviz. I have a prototype patch that
fixes it. We need a workaround for mk-configure, and I'll try to get
something working in the near future. If somebody wants to beat me to
it, please feel free.
Description of bug and patch:
Let's say you have my_prjs.dot, attached in an earlier post in this
report. You run
dot -Tps my_prjs.dot > my_prjs.eps
As reported earlier, my_prjs.eps is bogus because gs barfs at it:
$ ps2pdf my_prjs-sid.eps
Error: /undefined in setupLatin1
Operand stack:
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval--
--nostringval-- 2 %stopped_push --nostringval-- --nostringval--
--nostringval-- false 1 %stopped_push 1999 1 3 %oparray_pop
1998 1 3 %oparray_pop 1982 1 3 %oparray_pop 1868 1 3
%oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval--
--nostringval-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
--dict:982/1684(ro)(G)-- --dict:0/20(G)-- --dict:78/200(L)--
Current allocation mode is local
Current file position is 15221
GPL Ghostscript 9.20: Unrecoverable error, exit code 1
Looking at the my_projs.eps file, its structure is
1. A chunk written by psgen_begin_job() in
plugin/core/gvrender_core_ps.c:
%!PS-Adobe-3.0
%%Creator: graphviz version ...
...
2. A chunk that comes from plugin/core/ps.txt, written by
psgen_begin_graph() in plugin/core/gvrender_core_ps.c:
%%Title: ...
...
%%BeginProlog
/DotDict 200 dict def
DotDict begin
/setupLatin1 { ... } bind def
...
setupLatin1
Note that this defines the setupLatin1 function, and it then calls this
function
3. There is no psgen_end_graph()
4. A chunk that comes from psgen_end_job()
%%Trailer
%%Pages: 1
%%BoundingBox: 36 36 975 418
end
restore
%%EOF
Note that this undefineds the setupLatin1 function
5. At this point steps 2,3,4 repeat for each page, with some omissions.
The immediate next chunk is
setupLatin1
This comes from psgen_begin_graph() again, but it doesn't re-define
setupLatin1
This is the source of the complaint: we're calling an undefined
function.
This is only an issue when touching .dot files that have more than one
graph. Two solutions are possible:
1. Don't clean up as much after each page, so that the setupLatin1
function remains defined
2. Perform more initialization at the start of each page, to redefine
setupLatin1 each time
A simple proof-of-concept fix to implement solution 2 is to modify
psgen_begin_graph() in plugin/core/gvrender_core_ps.c to change
if (job->common->viewNum == 0) {
to
if (true) {
This if() statement served to prevent redefining setupLatin1 (and a
whole lotta other stuff), and this fix redefines it each time.
Solution 1 is probably better, but it involves touching more code, and
I'd rather upstream did that. Laszlo: as the graphviz Debian maintainer,
can you please forward this upstream?
Thanks.
Bug#867269: Report appears lost when MTA can't be contacted
I was just about to file a bug report saying these exact things. Instead, I'll just say these things are still an issue. -- Kent West kent.w...@acu.edu
Bug#924238: unblock: maint-guide/1.2.43
Hi piuparts devels, On 10-03-2019 16:27, Osamu Aoki wrote: >> The piuparts regression should be fixed first please. > E: Unable to locate package maint-guide-vi Can you please reschedule maint-guide-vi in unstable? It seems the mirror was behind again. Paul signature.asc Description: OpenPGP digital signature
Bug#924271: openarena: crashes at launch with "Couldn't compile shader" message.
Package: openarena
Version: 0.8.8+dfsg-2
Severity: grave
Justification: renders package unusable
Dear Maintainer,
* What led up to the situation?
I attempted to launch the program.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Ran `openarena` from a terminal.
* What was the outcome of this action?
Program failed to launch with a lengthy error message (attached).
* What outcome did you expect instead?
I expected the program to launch normally.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages openarena depends on:
ii ioquake3 1.36+u20181222.e5da13f~dfsg-1
ii libc6 2.28-7
ii openarena-081-maps0.8.5split-11
ii openarena-081-misc0.8.5split-11
ii openarena-081-players 0.8.5split-11
ii openarena-081-players-mature 0.8.5split-11
ii openarena-081-textures0.8.5split-11
ii openarena-085-data0.8.5split-11
ii openarena-088-data0.8.8-9
ii openarena-data0.8.5split-11
Versions of packages openarena recommends:
ii openarena-oacmp1 3-4
openarena suggests no packages.
Versions of packages ioquake3 depends on:
ii ioquake3-server 1.36+u20181222.e5da13f~dfsg-1
ii libc62.28-7
ii libcurl3-gnutls 7.64.0-1
ii libgl1 1.1.0-1
ii libjpeg62-turbo 1:1.5.2-2+b1
ii libogg0 1.3.2-1+b1
ii libopenal1 1:1.19.1-1
ii libopus0 1.3-1
ii libopusfile0 0.9+20170913-1
ii libsdl2-2.0-02.0.9+dfsg1-1
ii libvorbis0a 1.3.6-2
ii libvorbisfile3 1.3.6-2
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages ioquake3 recommends:
ii x11-utils 7.7+4
-- no debconf information
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
tty] ioq3 1.36+u20181222.e5da13f~dfsg-1/Debian linux-x86_64 Jan 14
2019
tty] SSE instruction set enabled
tty] - FS_Startup -
tty] We are looking in the current search path:
tty] /home/empty/.openarena/baseoa
tty] /usr/lib/openarena/baseoa
tty] /usr/lib/openarena/baseoa/z_oacmp-volume1-v3.pk3 (370 files)
tty] /usr/lib/openarena/baseoa/pak6-patch088.pk3 (711 files)
tty] /usr/lib/openarena/baseoa/pak6-patch085.pk3 (559 files)
tty] /usr/lib/openarena/baseoa/pak6-misc.pk3 (229 files)
tty] /usr/lib/openarena/baseoa/pak5-TA.pk3 (139 files)
tty] /usr/lib/openarena/baseoa/pak4-textures.pk3 (1753 files)
tty] /usr/lib/openarena/baseoa/pak2-players.pk3 (669 files)
tty] /usr/lib/openarena/baseoa/pak2-players-mature.pk3 (231 files)
tty] /usr/lib/openarena/baseoa/pak1-maps.pk3 (100 files)
tty] /usr/lib/openarena/baseoa/pak0.pk3 (1042 files)
tty]
tty] --
tty] 5803 files in pk3 files
tty] execing default.cfg
tty] couldn't exec q3config.cfg
tty] couldn't exec autoexec.cfg
tty] Hunk_Clear: reset the hunk ok
tty][Detaching after fork from child process 7475]
- Client Initialization -
tty] Couldn't read q3history.
tty] - Initializing Renderer
tty] Trying to load "renderer_opengl2_x86_64.so" from
"/usr/lib/ioquake3"...
tty] ---
tty] QKEY found.
tty] - Client Initialization Complete -
tty] tty]
tty]q - R_Init -
tty]q[Detaching after fork from child process 7485]
[New Thread 0x7f89daf18700 (LWP 7486)]
SDL using driver "x11"
tty]q Initializing OpenGL display
tty]q Display aspect: 1.600
tty]q ...setting mode 3: 640 480
tty]q Trying to get an OpenGL 3.2 core context
tty]q SDL_GL_CreateContext failed: Could not create GL context:
GLXBadFBConfig
tty]q Reverting to default context
tty]q Using 24 color bits, 24 depth, 8 stencil display.
tty]q Available modes: '640x400 1280x800 640x360 720x405 864x486
960x540 1024x576 1280x720 640x480 800x600 1024x768'
tty]q GL_RENDERER: Mesa DRI Intel(R) Ironlake Mobile
tty]q Initializing OpenGL extensions
tty]q ...ignoring GL_EXT_texture_compression_s3tc
tty]q ...ignoring GL_S3_s3tc
tty]q ...ignoring GL_EXT_texture_filter_anisotropic
tty]q ...using
Bug#907490: gnome-shell: Unrecoverable failure in required component org.gnome.Shell.desktop
Control: severity -1 important Control: tags -1 + unreproducible On Mon, 03 Sep 2018 at 20:32:14 -0500, william l-k wrote: > Could this be what we were looking for: > > Aug 28 09:30:54 user gnome-shell[3348]: JS ERROR: TypeError: > this._currentWindow is null I don't think so: it doesn't look as though gnome-shell immediately exited. I don't think anyone is going to be able to solve this with the information available. If this hasn't recurred, hasn't happened to anyone else, and doesn't have an obvious cause logged, then we might have to write it off as "probably fixed in 3.30.x" or "probably won't happen again". smcv
Bug#924087: Package textdraw description typo
severity 924087 minor notfound 924087 0.2+ds-0+nmu1build2 found 924087 0.2+ds-0+nmu1 thanks Hi, On Sat, Mar 09, 2019 at 03:08:04PM +0200, Eliran Gonen wrote: > In the first line it looks like “ do draw “ should have been “ to draw “. Yup. When there ever will be an upload of textdraw again (I doubt that one will be necessary) Regards, Rene P.S: > Package: textdraw Why is this a "normal" bug (default is normal)? Looks pretty much the definition of "minor" to me.. > Version: 0.2+ds-0+nmu1build2 And then you should have written a correct Version: Version: is not free text but the BTS looks at it and constructs a graph. 0.2+ds-0+nmu1build2 didn*t ever and doesn*t and won*t ever exist in Debian...
Bug#921558: lsb-base: killproc does not pass name parameter to start-stop-daemon
control: tags -1 +moreinfo
[2019-02-06 20:20] Andreas Metzler
> Package: lsb-base
> Version: 10.2018112800
> Severity: serious
>
> Hello,
>
> there is a logic error in /lib/lsb/init-functions's killproc:
>
> base=${1##*/}
> if [ ! $pidfile ]; then
> name_param="--name $base --pidfile /var/run/$base.pid"
> else
> name_param="--pidfile $pidfile"
> fi
>
> The if clause checks for nonempty $pidfile instead of nonempty $base to
> decide whether --name is used.
>
> Also --pidfile $pidfile is always used, even when $pidfile is empty.
>
> I am reportig this as serious since sid's start-stop-daemon requires a
> name parameter in addition to --pidfile when the pidfile is not owned by
> root, therefore this bug causes init script failures. (#921205)
[ I am not familiar with src:lsb, but I need this issue resolved fixed
to keep src:sysvinit suitable for Buster. By the way, sysvinit does
not use killproc. ]
I believe it would be reasonable to add '--name $base' into `else'
clause. Opinions?
PS. Dear maintainer, are you still willing to give-up maintainership of
src:lsb ( comment in 888743)?
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#924116: lintian: false positive of package-uses-dh-runit-...
[2019-03-09 12:17] "Chris Lamb" > Hi Dmitry, > > > * bin:foo uses functionality of dh_runit (test -f debian/foo.runit), > >but bar does not (! test -f debian/bar.runit) > > Is this a 100% reliable test for "runit usage"? I'd rather check > something else rather than "debian/$binpkg.runit", but I'm not sure > how dh-runit works (for example, does the binary package ships a file > under /etc/runit/runsvdir/?) It works same as all debhelpers. If debian/foo.links, it means that dh_link will create some links. Well, with dh_runit you need also add `--with runit` option to `dh'. If you prefer, yes, dh_runit creates directories under /etc/sv/. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#923609: proposed solution
[2019-03-08 22:40] Niko Tyni > On Fri, Mar 08, 2019 at 02:39:53PM +, Dmitry Bogatov wrote: > > > I believe this patch would somewhat solve issue. Dear submitter, can you > > please apply this patch, build package and check, that `gdbm_load-nolfs' > > binary from created bin:gdbmtool does sensible thing? > > Thanks. It doesn't quite work as-is, because 'future=+all' in > DEB_BUILD_MAINT_OPTIONS still pulls the LFS flags in the build. But if > I take that away, it works at least for my trivial databases (both GDBM > and NDBM). I'll try to test a bit more later. Good. Try this version of patch, please. It seems to works for me in my i386 chroot. > It would make sense to limit this to 32-bit architectures as I believe the > 64-bit architectures always have LFS support no matter the build flags. I'd leave it as-is. Yes, it may be redundant on 64 bit platforms, but it will go away rather soon anyway. I'd rather not complicate `debian/rules'. > Shipping these -nolfs binaries and including instructions for upgrading > databases in the Buster release notes would be an acceptable fix for > this issue IMO. Good. By the way, should I file bug aganist release.debian.org now, or when we are settled on solution? From 8a76aafea8096d71a72ee16596c3cfaa12e0f291 Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Thu, 7 Mar 2019 20:19:11 + Subject: [PATCH] Provide version with LFS support disabled --- debian/rules | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/debian/rules b/debian/rules index fce1572..78eeb73 100755 --- a/debian/rules +++ b/debian/rules @@ -1,6 +1,6 @@ #!/usr/bin/make -f export LC_ALL = C -export DEB_BUILD_MAINT_OPTIONS = hardening=+all future=+all reproducible=+all +export DEB_BUILD_MAINT_OPTIONS = hardening=+all reproducible=+all include /usr/share/dpkg/default.mk # Upstream source code in src/version.c uses __DATE__ and __TIME__ @@ -35,21 +35,26 @@ ifeq ($(HAVE_DIETLIBC),yes) --libdir $(DIET_LIBDIR) \ --disable-shared \ --enable-static \ + --enable-largefile \ --enable-memory-mapped-io=no \ CC='diet gcc' CPPFLAGS='-UHAVE_MMAP' endif - dh_auto_configure -B glibc-build -- --enable-libgdbm-compat + dh_auto_configure -B glibc-build -- --enable-libgdbm-compat --enable-largefile + dh_auto_configure -B glibc-nolfs-build -- \ + CFLAGS='-static' --program-suffix=-nolfs --disable-largefile override_dh_auto_build: ifeq ($(HAVE_DIETLIBC),yes) dh_auto_build -B diet-build endif dh_auto_build -B glibc-build + dh_auto_build -B glibc-nolfs-build override_dh_auto_install: ifeq ($(HAVE_DIETLIBC),yes) dh_auto_install -B diet-build endif + dh_auto_install -B glibc-nolfs-build dh_auto_install -B glibc-build ifeq ($(HAVE_DIETLIBC),yes) -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#924058: runit: replace obsolete usleep with nanosleep in sv.c
[2019-03-08 23:43] Jan
> >From f7b8f943d1f7a8f26df8d81eeb0a2d5a69ee7e22 Mon Sep 17 00:00:00 2001
> From: Jan
> Date: Wed, 6 Mar 2019 18:38:04 +0100
> Subject: [PATCH] fix: replace obsolete usleep with nanosleep
>
> POSIX.1-2001 declares usleep obsolete,
> POSIX.1-2008 removes the specification of usleep,
> see https://linux.die.net/man/3/usleep
Looks good to me. Thank you. I will let this patch hang till release,
and will apply and upload after thaw. While change seems perfectly fine,
moving parts around freeze feels worriesome.
Gerrit, as you can see, there is some activity around runit, in
particular about C code. I consider releasing runit-2.1.2 with
all patches, accumulated in Debian package as runit-2.1.3 for
convenience of other distributions (Void, Gentoo). Do you object?
Would you like to do it yourself?
> ---
> runit-2.1.2/src/sv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/runit-2.1.2/src/sv.c b/runit-2.1.2/src/sv.c
> index 6cc2a8b..f97c5a2 100644
> --- a/runit-2.1.2/src/sv.c
> +++ b/runit-2.1.2/src/sv.c
> @@ -1,5 +1,6 @@
> #include
> #include
> +#include
> #include
> #include "str.h"
> #include "strerr.h"
> @@ -271,6 +272,7 @@ int control(char *a) {
> int main(int argc, char **argv) {
>unsigned int i, done;
>char *x;
> + const struct timespec sleeptime = {0, 42000};
>
>progname =*argv;
>for (i =str_len(*argv); i; --i) if ((*argv)[i -1] == '/') break;
> @@ -388,7 +390,7 @@ int main(int argc, char **argv) {
>fatal("unable to change to original directory");
>}
>if (done) break;
> - usleep(42);
> + nanosleep(, NULL);
>taia_now();
> }
>return(rc > 99 ? 99 : rc);
> --
> 2.20.1
>
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#499796: initscripts: rootfs over nfs hangs at reboot
[2019-03-09 17:59] Pierre Ynard
>
> part text/plain1139
> > > My opinion is that /etc/init.d/reboot should honor NETDOWN, and
> > > source it from /etc/default/halt. And then NETDOWN should be
> > > documented in /etc/default/halt, as requested in #703844.
> >
> > Actually, #696910 suggests that NETDOWN could also be disabled if
> > iSCSI is detected.
>
> Sorry for changing my mind again, but I found yet another bug about
> this, #632091, which points out that /etc/init.d/networking already
> uses extensive code to detect iSCSI and other network mounts. So maybe
> we should reuse that code in halt and reboot scripts to disable -i; and
> also integrate and support NETDOWN at reboot, because apparently people
> have been using it to handle this kind of setup, in addition to its
> original purpose about wake-on-lan.
>
> Allowing the admin to configure /etc/default/halt is good, detecting
> failure cases so it works out of the box is better. And if we
> don't want to expand initscripts knowledge about every problematic
> network filesystem, considering that other packages can't edit
> /etc/default/halt, it might be even better to let them drop files
> somewhere, maybe in /run/network, to signal this.
Well, let's start with something. What about this patch, that reuses
/etc/default/halt? I believe it is, maybe not most principal, but
solution to bug at hand.
From 3d53d5e2ecfec0f2b3b2e1fc95e4c56c4f6ddf78 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sat, 9 Mar 2019 20:30:12 +
Subject: [PATCH] Make /etc/init.d/reboot respect NETDOWN variable
# @@ -12,12 +12,17 @@
# +[ -f /etc/default/halt ] && . /etc/default/halt
# - reboot -d -f -i
# + local netdown="-i"
# + if [ "${NETDOWN}" = no ] ; then
# + netdown=""
# + fi
# + reboot -d -f ${netdown}
---
debian/src/initscripts/etc/init.d/reboot | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/debian/src/initscripts/etc/init.d/reboot
b/debian/src/initscripts/etc/init.d/reboot
index e1dcb1cc..cf56c1a4 100755
--- a/debian/src/initscripts/etc/init.d/reboot
+++ b/debian/src/initscripts/etc/init.d/reboot
@@ -12,12 +12,17 @@
PATH=/sbin:/usr/sbin:/bin:/usr/bin
. /lib/lsb/init-functions
+[ -f /etc/default/halt ] && . /etc/default/halt
do_stop () {
# Message should end with a newline since kFreeBSD may
# print more stuff (see #323749)
log_action_msg "Will now restart"
- reboot -d -f -i
+ local netdown="-i"
+ if [ "${NETDOWN}" = no ] ; then
+ netdown=""
+ fi
+ reboot -d -f ${netdown}
}
case "$1" in
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#620898: Moving bash from essential/required to important
[2017-01-21 20:54] Balint Reczey > Control: tags -1 confirmed > > Hi, > > On Sat, 27 Sep 2014 21:14:46 -0500 Troy Benjegerdes wrote: > > So can we have a prerm script for bash that sets the root > > shell back to /bin/sh, or at least asks the admin if they want > > zsh or tcsh, and warns about any other users? > > > > Any of this stuff of trying to have login figure out the > > right shell seems like a new remote exploit in the making. > > It is too late for making changes related to this bug in Stretch. :-( > In the next cycle we will evaluate switching to login implementatiln in > util-linux per #833256. This bug may be solved by the switch or later in > util-linux. Hi! What is the current state of bug? There was fine (IMO) proposal, So can we have a prerm script for bash that sets the root shell back to /bin/sh, or at least asks the admin if they want zsh or tcsh, and warns about any other users? but as bash=5.0-2 it did not make its way. What is missing? Should I submit patch, implementing this proposal? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#924268: 9base: move binaries to /usr/libexec
Package: 9base Version: 1:6-7 Severity: wishlist Dear Maintainer, since Debian now uses FHS-3.0, /usr/libexec is more suitable place for exectables then generic /usr/lib location. Please, consider moving. -- System Information: Distributor ID: Devuan Description:Devuan GNU/Linux beowulf/ceres Release:10 Codename: n/a Architecture: x86_64 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=eo.utf8, LC_CTYPE=eo.utf8 (charmap=UTF-8), LANGUAGE=eo.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: runit (via /run/runit.stopit) Versions of packages 9base depends on: ii libc6 2.28-8 9base recommends no packages. Versions of packages 9base suggests: pn wmii2 -- no debconf information pgpy5ceMMhQaa.pgp Description: PGP signature
Bug#703844: proposed wording
I believe something as simple, as this would do: From ce28f12b7682fc5750fe225ac563cacfdcf81ff0 Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Sat, 9 Mar 2019 20:48:07 + Subject: [PATCH] Document NETDOWN variable in /etc/default/halt --- debian/src/initscripts/etc/default/halt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/debian/src/initscripts/etc/default/halt b/debian/src/initscripts/etc/default/halt index 21bc1198..596b829e 100644 --- a/debian/src/initscripts/etc/default/halt +++ b/debian/src/initscripts/etc/default/halt @@ -1,2 +1,5 @@ # Default behaviour of shutdown -h / halt. Set to "halt" or "poweroff". HALT=poweroff + +# Bring networking down before halting/rebooting system. Set to "yes" or "no". +NETDOWN=yes -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgpvATqt_L1w5.pgp Description: PGP signature
Bug#924270: O: keepassx -- Cross Platform Password Manager
Package: wnpp Severity: normal Keepassx is a graphical password manager, using the Qt4 toolkit. I'm no longer using this package and have personally switched to 'password-store'. Unfortunately, I've also failed to get a response from upstream from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920616 - which recommends to replace keepassx with keepassxc, a community fork, possibly because of unresponsive upstream. I am undecided whether or not this package should be included in Debian 10 (aka buster). It clearly is useful to many people, but its long-term maintenance is unclear. I'd encourage people interested in picking up this package to coordinate with Julian Klode (CC'ed), the Debian keepassxc maintainer. Best, -rt
Bug#924269: chiark-really: providing bin:sudo
Package: chiark-really Version: 6.0.3 Severity: wishlist Dear Maintainer, please consider making chiark-really drop-in replacement for sudo. For my own purposes, alias sudo='PATH=/bin:/sbin:/usr/bin:/usr/sbin /usr/sbin/really' is perfectly fine, but some packages pull dependency on bin:sudo (ubuntu-dev-tools, as example). What about making bin:really-sudo, which provides `sudo` wrapper and Conflicts+Provides sudo? -- System Information: Distributor ID: Devuan Description:Devuan GNU/Linux beowulf/ceres Release:10 Codename: n/a Architecture: x86_64 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=eo.utf8, LC_CTYPE=eo.utf8 (charmap=UTF-8), LANGUAGE=eo.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: runit (via /run/runit.stopit) Versions of packages chiark-really depends on: ii libc6 2.28-8 chiark-really recommends no packages. chiark-really suggests no packages. -- no debconf information pgpr4ojwFryjB.pgp Description: PGP signature
Bug#922657: Misfires when variable is put in a string
Control: tags -1 + confirmed upstream On Tue, Feb 19 2019, 積丹尼 Dan Jacobson wrote: > > $ set apt-show-versions > $ zless /usr/share/doc/$@/ch > $ zless /usr/share/doc/$@/ch > chromium chromium-common chromium-sandbox chromium-shell > $ zless /usr/share/doc/\$@/chromium The backslash is added in _quote_readline_by_ref, by this statement: printf -v $2 %q "$1" It only adds the backslash to unset variables, but not when the variable is set, for instance: zless /usr/share/$PATH/ does nothing, whereas zless /usr/share/$ASDF/ zless /usr/share/\$ASDF/ causes the problem you describe... Marking as confirmed and upstream.
Bug#924134: unblock: libgwenhywfar/4.20.0-9
Hi release team, I just realized that the version information for Debian bug #875012 ([libgwenhywfar] Future Qt4 removal from Buster) was incomplete and inaccurate. I assume this to be caused by the merge of the upload history of the multiple unstable and experimental versions. I've just fixed the version in the BTS, so it should now accurately show which versions the Debian bug #875012 was fixed and which it was present. The main question I would like the release team to decide is, whether Debian bug #875012 is important enough to be fixed in buster. We don't have to, but we can (and I would like to) by unblocking libgwenhywfar/4.20.0-9. unblock libgwenhywfar/4.20.0-9 Thanks for considering and Best regards, Micha
Bug#917203: FTBFS on at least two architectures: test failure in the enigma algorithm
On Mon, Dec 24, 2018 at 12:20:05AM +, Steve McIntyre wrote: >Package: src:libmcrypt >Version: 2.5.8-3.3 >Severity: serious >Tags: ftbfs >Justification: fails to build from source (but built successfully in the past) > >Hi! > >I've been doing a full rebuild of the Debian archive, building all >source packages targeting armel and armhf using arm64 hardware. We are >planning in future to move all of our 32-bit armel/armhf builds to >using arm64 machines, so this rebuild is to identify packages that >might have problems with this configuration. > >While doing this, I found that libmcrypt failed its test suite for >armel running on arm64: > >... >Algorithm: enigma... failed compatibility >Expected: f3edda7da20f8975884600f014d32c7a08e59d7b >Got: 216540d5d71ec2d57f626a5609a3ebedbb9b32e4 >... > >I've tested on amd64 and things look fine, but building for arm64 on >arm64 also fails with exactly the same test failure as armel-on-arm64. Just retested again today at a BSP. The failing test (the enigma self-test) works OK on amd64, but fails reliably and repeatedly on at least arm64, armhf and ppc64el with the same failing result. I can only assume that something has changed in compiler setup here - these tests all passed when last uploaded over 4 years ago. Last "maintainer" upload in 2009. Arg. :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Bug#924261: stretch-pu: package certbot/0.28.0-1~deb9u1
On Sun, Mar 10, 2019 at 2:48 PM Adam D. Barratt wrote: > The source debdiff is clearly *not* empty. Your diffoscope output shows > changes to debian/changelog, debian/control, debian/compat, ... those > are all in the source package and thus would appear in a source > debdiff. Derp, was diffing the changes file instead of the .dsc. Attached. -- Harlan Lieberman-Berg ~hlieberman certbot-src.debdiff Description: Binary data
Bug#924261: stretch-pu: package certbot/0.28.0-1~deb9u1
On Sun, 2019-03-10 at 14:37 -0400, Harlan Lieberman-Berg wrote: > debdiffs of the .debs are attached. The source debdiff is empty. > > Diffoscope output is also attached. The source debdiff is clearly *not* empty. Your diffoscope output shows changes to debian/changelog, debian/control, debian/compat, ... those are all in the source package and thus would appear in a source debdiff. Regards, Adam
Bug#924267: intel-media-va-driver: [CFL] no H.264 encoding, no JPEG decoding
Package: intel-media-va-driver Version: 18.4.0+dfsg1-1 Severity: important Hi, I've been trying the intel-media-va-driver package on my Coffee Lake, where the old driver works fine. It seems I can't get H.264 encoding to work: gruessi:~> export LIBVA_DRIVER_NAME=iHD gruessi:~> nageru No --va-display was given, and the X11 display did not expose a VA-API H.264 encoder. DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument Assuming 131072kB available aperture size. May lead to reduced performance or incorrect rendering. get chip id failed: -1 [22] param: 4, val: 0 No suitable VA-API H.264 encoders were found in /dev/dri; giving up. Note that if you are using an Intel CPU with an external GPU, you may need to enable the integrated Intel GPU in your BIOS to expose Quick Sync. Alternatively, you can use --record-x264-video to use software instead of hardware H.264 encoding, at the expense of increased CPU usage and possibly bit rate. I've also tried JPEG decoding: gruessi:~> wget https://storage.sesse.net/trondisk2018-semifinal-multicam-mjpeg.mkv [you don't need the entire file, Ctrl-C after ~50 MB is fine] gruessi:~> futatabi --slow-down-input trondisk2018-semifinal-multicam-mjpeg.mkv gruessi:~/dev/nageru/obj> futatabi --slow-down-input trondisk2018-semifinal-multicam-mjpeg.mkv VA-API JPEG decoding initialized. decode_jpeg_vaapi:383 (vaCreateBuffer) failed with 5 VA-API hardware decoding failed; falling back to software. decode_jpeg_vaapi:383 (vaCreateBuffer) failed with 5 VA-API hardware decoding failed; falling back to software. decode_jpeg_vaapi:383 (vaCreateBuffer) failed with 5 In short, I can't get the driver to work at all, whereas the old driver (no LIBVA_DRIVER_NAME set) works fine. I haven't tried JPEG encoding, since I need working H.264 encoding before Nageru will allow me to try that, but I wouldn't be surprised if that is broken, too. :-) This is a Core i5-8400 (Coffee Lake). 00:02.0 Display controller: Intel Corporation UHD Graphics 630 (Desktop) 01:00.0 VGA compatible controller: NVIDIA Corporation TU106 [GeForce RTX 2070] (rev a1) -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-3-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nb_NO.utf8, LC_CTYPE=nb_NO.utf8 (charmap=UTF-8), LANGUAGE=nb_NO.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages intel-media-va-driver depends on: ii libc6 2.28-8 ii libgcc11:8.3.0-2 ii libigdgmm5 18.4.1+ds1-1 ii libpciaccess0 0.14-1 ii libstdc++6 8.3.0-2 ii libva2 [libva-driver-abi-1.4] 2.4.0-1 intel-media-va-driver recommends no packages. intel-media-va-driver suggests no packages. -- no debconf information
Bug#899662: *prod* Please fix pykerberos bug #899662?
On Sun, Mar 10, 2019 at 07:34:46PM +0100, Guido Günther wrote: >Hi, >On Sun, Mar 10, 2019 at 02:11:38PM +, Steve McIntyre wrote: >> Hi guys, >> >> I don't know if you've even seen this RC bug. Could you please update >> the maintainer address to point to something that works? > >I wasn't. I can do so next week. Awesome, thanks. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Bug#924266: libodb-api-bin has circular Depends on libodb-api-dev
Package: libodb-api-bin Version: 0.18.1-5 Severity: important Hello Alastair, There is a circular dependency between libodb-api-bin and libodb-api-dev: libodb-api-bin :Depends: libodb-api-dev (= 0.18.1-5) libodb-api-dev :Depends: libodb-api-bin (= 0.18.1-5) Circular dependencies are known to cause problems during upgrade between stable releases, so we should try to avoid them. Cheers, -- Bill. Imagine a large red swirl here.
