Bug#947345: pkgdiff: wishlist:new upstream
Package: pkgdiff Version: 1.7.2-1 Severity: wishlist Dear Maintainer, You might know pkgdiff 1.8 has been released. Please packaging new version. Best regards Yukiharu. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 pkgdiff depends on: ii gawk 1:5.0.1+dfsg-1 ii perl 5.30.0-9 ii rpm4.14.2.1+dfsg1-1+b1 ii wdiff 1.2.2-2+b1 pkgdiff recommends no packages. Versions of packages pkgdiff suggests: pn abi-compliance-checker pn abi-dumper -- no debconf information
Bug#932046: simple-scan: Ctrl+1 does nothing but is documented to scan a page
Hi Jörg, thanks for forwarding this, it's fixed now, i.e., the shortcut works as expected and documented. I'll close the bug. Cheers - Bruno signature.asc Description: This is a digitally signed message part
Bug#947329: FTBFS: debian/bppphyview/usr/share/man/man1/phyview.1: No such file or directory
Control: tags -1 unreproducible Control: tags -1 moreinfo Hi, On Tue, Dec 24, 2019 at 03:56:45PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > > Hi! During a rebuild of your package it FTBFS with the following error: > > dh_installman: mv debian/bppphyview/usr/share/man/man1/phyview.1.dh-new > debian/bppphyview/usr/share/man/man1/phyview.1: No such file or directory That's pretty strange. The very simple debian/bppphyview.manpages just specifies man/*.1 and man/phyview.1 exists in the source. I've checked the build in a pbuilder chroot and it builds nicely. Are you really sure that your build environment is OK? Kind regards, Andreas. -- http://fam-tille.de
Bug#914569: beets: zsh completion broken
Control: tag -1 +moreinfo +unreproducible Hi Clint (2018.11.25_05:15:04_+0200) > % beet import ../ > _beet:zregexparse:4: invalid regex : ) > (with zsh 5.6.2-3) Works for me, with zsh 5.7.1-1+b1. Something changed in zsh? Or something unusual about the directory you were in? SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#936924: Moving libsvm to Debian Science team
Hi Chen-Tse, On Tue, Dec 24, 2019 at 10:39:55AM -0500, Chen-Tse Tsai wrote: > Thanks, Andreas. > > I just submitted a PR for dropping python2 dependencies: > https://salsa.debian.org/science-team/libsvm/merge_requests/1 > > Any comment is appreciated. I'll be working on upgrading to new upstream. Looks very good! I injected the patch by Helmut Grohne (#862234) as well. For the upgrade I was simply using https://salsa.debian.org/r-pkg-team/maintenance-utilities/blob/master/routine-update I developed it for R packages but it works for other packages as well. Since I noticed that the new upstream source includes some windows binaries I'll remove them via Files-Excluded. I hope that you are happy that I'm doing these routine tasks and will sponsor the package for you once ready. Kind regards, Andreas. > Thanks, > Chen-Tse > > > On Mon, Dec 23, 2019 at 4:03 PM Andreas Tille wrote: > > > On Mon, Dec 23, 2019 at 03:06:37PM -0500, Chen-Tse Tsai wrote: > > > I have a quick question. Previously the python modules are installed to > > > /usr/share/pyshared/. Should I use /usr/lib/python3/dist-packages instead > > > if I change it to python3? I see this in the policy and this is also what > > > liblinear uses. Just want to double check. > > > > Yes, follow liblinear example. > > > > Thanks for your work on this > > > > Andreas. > > > > -- > > http://fam-tille.de > > -- http://fam-tille.de
Bug#947344: RM: libgdal-grass/experimental [mipsel] -- ROM; Build dependency not available
Package: ftp.debian.org Severity: normal Control: block 947342 by -1 Please remove libgdal-grass from mipsel in experimental too, mesa is not available there for which grass will have to be removed. Kind Regards, Bas
Bug#947343: RM: libgdal-grass [mipsel] -- ROM; Build dependency not available
Package: ftp.debian.org Severity: normal Control: block 947342 by -1 Please remove libgdal-grass from mipsel, mesa is not available there for which grass will have to be removed. Kind Regards, Bas
Bug#947342: RM: grass [mipsel] -- ROM; Build dependency not available
Package: ftp.debian.org Severity: normal Please remove grass from mipsel, mesa is not available there and the missing build will block testing migration. Kind Regards, Bas
Bug#936270: Any update? We'll remove python-routes soon
Hi Thomas, On Mon, 23 Dec 2019, Thomas Goirand wrote: > situation of Calibre? When do you think your package will be ready? As I > understand, Calibre itself is ready, but what about the plugins? Are the Kovid has announced the shift to Py3 [1], and asked the Plugin authors to update their plugins. This is under way. At the same time several fixes for the Py3 version were found. How far the plugins are updated I cannot evaluate easily (as I don't use all the several hundreds of them). > Now, we have 2 alternatives: get routes py2 support removed, and then, > calibre py2 removal bug becomes RC, or we attempt to reintroduce a few When will this happen? > I don't think we should wait for another 6 months to act here. Kovid himself plans to switch upstream officially around mid next year, which is obviously too late for you. When do you want to go ahead with the removal? I have more or less given up on my opposition and go with the flow, so if it is RC it is RC and I upload the Py3 version with its shortcomings. Best Norbert [1] https://www.mobileread.com/forums/showthread.php?t=325721 -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1
On Sun, Dec 22, 2019 at 4:22 PM Dmitry Shachnev wrote: > > Hi Sandro! > > On Sun, Dec 22, 2019 at 02:47:10PM -0500, Sandro Tosi wrote: > > > The current version packaged in Debian is very outdated, > > > even in unstable. Please consider packaging the current > > > upstream release. > > > > I'm echoing this request: the just released numpy/1.18.0 requires > > sphinx >= 2.2.0, so we cannot upgrade numpy without an updated sphinx. > > please consider package it at the earliest. > > Unfortunately sphinx ≥ 2.0 dropped support for Python 2. > > So I should either wait until all blocking bugs of #938528 are resolved, or > introduce a new source package like sphinx-python2 for the old version. i think there a quite too many packages blocking 938528 (counts is 100), so yeah maybe a src:sphinx2 (to track 1.8.5) and src:sphinx (to track 2+) seems like the best solution to keep old packages around and not prevent progress for the modules more forward-looking. > However the latter solution will mean that we can no longer have shared > sphinx-common and libjs-sphinxdoc packages, and we will need to have two > versions of dh_sphinxdoc too (or one version that will generate different > dependencies for old and new sphinx). This is something I wanted to avoid, > because it is extra work for supporting a Python 2 version that will be > dead in a few days. hm, that's a good point indeed; i'm not sure we can drop python-sphinx and make all of those packages RC > Recently your script bumped many Python 2 removal bugs to RC, with the > intention to accelerate porting those packages to Python 3 (or getting them > removed). Maybe better to wait a couple of months and then just upload new > Sphinx and break its Python 2 reverse build-dependencies? only 49 of those 100 blocked packages are currently RC, so it will take quite more time i suspect; also some of those packages are sphinx extensions, that will have to go at the same time as sphinx maybe? > Can you patch old Sphinx support into numpy for the time being? tbh, i'd rather not :) maybe you can consider uploading 2.2+ to experimental, just to see if there's any breakage with the new version (even for packages already using python3-sphinx), and i can upload numpy in experimental Cheers, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#947341: ITP: libusb-libusb-perl -- Perl interface to the libusb-1.0 API
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libusb-libusb-perl Version : 0.09 Upstream Author : Simon Reinhardt * URL : https://metacpan.org/release/USB-LibUSB * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl interface to the libusb-1.0 API USB::LibUSB provides a Perl interface to the libusb-1.0 API. It provides access to most basic libusb functionality including read-out of device descriptors and synchronous device I/O. Staying as close as possible to the libusb-1.0 API, this module adds convenient error handling and additional high-level functionality (e.g. device discovery with vid, pid and serial number). Easy to build more functionality without knowing about XS. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#947064: texlive-fonts-extra: fourier-orns.sty broken, docs using the Fourier font no longer compile
Hi Sebastian, I am a bit baffled about your reports. In one of the first emails you send: On Fri, 20 Dec 2019, Seb wrote: > ~> dpkg -l texlive-fonts-extra > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ NameVersion Architecture Description > +++-===-===--==> > ii texlive-fonts-extra 2019.20191208-1 all TeX Live: Additional > fonts And 3 days later you send: On Mon, 23 Dec 2019, Seb wrote: > ~> dpkg -l texlive-fonts-extra > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ NameVersion Architecture Description > +++-===-===--=== > ii texlive-fonts-extra 2018.20190227-2 all TeX Live: Additional I have no idea what is going on on your side, but it seems you are either mixing distributions, reporting from different corners, or whatever. Anyway, * IF you are running buster (that is, TL 2019.20191208), then the OTF file should not be loaded at all, I checked the source code. * IF you are running testing or sid (2019.201912XX), then the files are there, and with one of the two solutions I mentioned you can get it working. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#947064: fourier: problem with font lookup
On Mon, 23 Dec 2019, TeX Live Mailing List wrote: > It will be fixed for the next Fourier release (January, I hope). Thanks a lot! Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#947340: linux-base: can't be upgraded
Package: linux-base Version: 4.6 Severity: grave Justification: renders package unusable Hi. Since last April, the package can't be upgraded as it conflicts with the current version of kernel-common. Would be nice if this could be resolved. Probably it's this change: * Take over kernel-img.conf(5) manual page from kernel-common ▒ (Closes: #925415) ▒ but then this should be reflected in kernel-common, or it should have been coordinated with its maintainer in the first place. Cheers, Chris.
Bug#947331: buster-pu: package roundcube/1.3.8+dfsg.1-2
Control: tags -1 - moreinfo > +roundcube (1.3.10+dfsg.1-1~deb10u1) buster; urgency=medium > + > + * d/control: revert bump of Standards-Version, as we want to release to > +stable. > + * d/upstream/signing-key.asc: revert Minimize OpenPGP certificate. > + * Add patch to Fix "Retry to connect to IMAP server" (Closes: #947320) > > I'm assuming both from the position of the latter change in the > changelog, and the metadata of the referenced bug, that it isn't > actually applied in unstable yet? The two reverts I did just to minimize the debdiff, but think they won't harm to ship them to stable. Yes #947320 isn't fixed in unstable nor experimental yet. But I will make sure, that the next version 1.4.1, that will hit unstable in the next days will have this patch applied. I created that patch in 2017 and had applied it locally to test and than I forgotten as the bug was actually fixed to add it to Debian. But that's why I'm very certain, that it doesn't beak anything. hefee signature.asc Description: This is a digitally signed message part.
Bug#947339: slingshot: should this package be removed?
Source: slingshot Severity: serious Hello, iI think there are several issues with slingshot: - python2-only package - upstream dormant since 8+ years - no updates on https://github.com/ryanakca/slingshot/issues/9 since Aug 9 if I dont hear back within a week with a good reason to keep this package in debian, i'll file for its removal. Regards, Sandro -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages slingshot depends on: ii fonts-freefont-ttf 20120503-9 ii python 2.7.16-1 pn python-pygame slingshot recommends no packages. slingshot suggests no packages.
Bug#937544: pyspread: Python2 removal in sid/bullseye
Hey Andreas, upstream is porting this application to python3 at https://gitlab.com/pyspread/pyspread and they just released an alpha version for it. Since pyspread is no longer in testing, then maybe you can consider package this version for unstable? this will unlock several python2 modules pyspread depends on. thanks for considering, Sandro
Bug#947338: cherrytree: should this package be removed?
Source: cherrytree Severity: serious Hello, i believe there are several issues with cherrytree: - python2-only application - depends on pygtk, deprecated - depends on gtksourceview, deprecated - upstream is rewriting it in C++, so there's no hope for a py3k port i think it's time to remove it (and eventuall re-introduce it in Debian once the C++ port is completed); if i dont hear back within a week with a good reason to keep this package in Debian, i'll file for it's removal. Regards, Sandro -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cherrytree depends on: ii p7zip-full 16.02+dfsg-6 ii python 2.7.16-1 ii python-chardet 3.0.4-3 ii python-dbus1.2.8-3 pn python-enchant ii python-gtk22.24.0-6 pn python-gtksourceview2 cherrytree recommends no packages. cherrytree suggests no packages.
Bug#947337: stockfish: Please package the new version (10)
Source: stockfish Version: 9-2 Severity: normal Dear stockfish maintainer, The new version for stockfish is ready; please consider packaging it in Debian. Thanks! -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#947170: transition: botan
在 2019-12-23一的 19:06 -0500，Boyuan Yang写道： > 在 2019-12-22日的 14:11 +0100，László Böszörményi (GCS)写道： > > On Sun, Dec 22, 2019 at 1:45 PM László Böszörményi wrote: > > > But > > > libqtshadowsocks doesn't and has a dead upstream for more than a year. > > > I added its maintainer as Cc if s/he can fix it. > > I was way too quick. There's a fix for botan support[1] already. > > The question of keeping dead upstream packages in the archive still > > stands. > > Considering the upstream status of those projects, I am filing Removal > requests for libqtshadowsocks and shadowsocks-qt5 to the FTP Masters. Thanks > for noticing. Those two packages are now removed. I believe the transition should now be ready. -- Cheers, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#711135: Last Mile: CLOUD COMPUTING 2020 || April 26 - 30, 2020 - Nice, France
INVITATION: = Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results to: - CLOUD COMPUTING 2020, The Eleventh International Conference on Cloud Computing, GRIDs, and Virtualization The submission deadline of January 7, 2020 is approaching Authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org = == CLOUD COMPUTING 2020 | Call for Papers === CALL FOR PAPERS, TUTORIALS, PANELS CLOUD COMPUTING 2020, The Eleventh International Conference on Cloud Computing, GRIDs, and Virtualization General page: http://www.iaria.org/conferences2020/CLOUDCOMPUTING20.html Submission page: http://www.iaria.org/conferences2020/SubmitCLOUDCOMPUTING20.html Event schedule: April 26 - 30, 2020 - Nice, France Contributions: - regular papers [in the proceedings, digital library] - short papers (work in progress) [in the proceedings, digital library] - ideas: two pages [in the proceedings, digital library] - extended abstracts: two pages [in the proceedings, digital library] - posters: two pages [in the proceedings, digital library] - posters: slide only [slide-deck posted at www.iaria.org] - presentations: slide only [slide-deck posted at www.iaria.org] - demos: two pages [posted at www.iaria.org] - doctoral forum submissions: [in the proceedings, digital library] Proposals for: - mini symposia: see http://www.iaria.org/symposium.html - workshops: see http://www.iaria.org/workshop.html - tutorials: [slide-deck posed on www.iaria.org] - panels: [slide-deck posed on www.iaria.org] Submission deadline: January 7, 2020 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Print proceedings will be available via Curran Associates, Inc.: http://www.proceedings.com/9769.html Articles will be archived in the free access ThinkMind Digital Library: http://www.thinkmind.org The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and comply with the editorial rules: http://www.iaria.org/editorialrules.html CLOUD COMPUTING 2020 Topics (for topics and submission details: see CfP on the site) Call for Papers: http://www.iaria.org/conferences2020/CfPCLOUDCOMPUTING20.html TRENDS: New trends Fog-computing; Mobile Edge Computing; Cloudlets; Hosted Cloud services (WebRTC, Containers, Cloud micro-services); Cloud computing and SDN/NFV; Cloud computing and 5G; Cloud computing and LTE Pro 4.5; Cloud computing ad Big Data; High performance computing (HPC) in the Cloud; Superfluid Clouds; Mobile Apps to the public Clouds; Vehicular Cloud networks; Cloud orchestration features; Converged edge systems; Cloud federation; Micro-cloud provider federation; Open-implementation Cloud infrastructures; Untrusted Cloud environments; Multiple Clouds and data centers; Power Constrained VMs; Cloud Green abstraction layer CLOUD: Cloud computing Cloud economics; Core cloud services; Cloud technologies; Cloud computing; On-demand computing models; Hardware-as-a-service; Software-as-a-service [SaaS applications]; Platform-as-service; Storage as a service in cloud; Data-as-a-Service; Service-oriented architecture (SOA); Cloud computing programming and application development; Scalability, discovery of services and data in Cloud computing infrastructures; Trust and clouds; Client-cloud computing challenges; Geographical constraints for deploying clouds CLOUD: Challenging features Privacy, security, ownership and reliability issues; Performance and QoS; Dynamic resource provisioning; Power-efficiency and Cloud computing; Load balancing; Application streaming; Cloud SLAs; Business models and pricing policies; Cloud service subscription models; Cloud standardized SLA; Cloud-related privacy; Cloud-related control; Managing applications in the clouds; Mobile clouds; Roaming services in Clouds; Agent-based cloud computing; Cloud brokering; Cloud contracts (machine readable); Cloud security; Security and assurance properties in cloud environments; Big Data Analytics in clouds; Cloud computing back-end solutions; Cloud applications portability; Cloud-native application design; Security by
Bug#947336: RFS: wcd/6.0.3-1 [QA] -- saves time typing when you want to change directories
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wcd" * Package name: wcd Version : 6.0.3-1 Upstream Author : Erwin Waterlander , * URL : http://waterlan.home.xs4all.nl * License : GPL-2+ * Vcs : https://salsa.debian.org/sudip-guest/wcd.git Section : utils It builds those binary packages: wcd - saves time typing when you want to change directories To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wcd Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wcd/wcd_6.0.3-1.dsc Changes since the last upload: * QA upload. * Update to upstream 6.0.3. * Update Standards-Version to 4.4.1. * Update compate level to 12. * Mark maintainer to QA. * Remove the patch, this version is not using build date. * Combine both NEWS file to a single NEWS. * Push to salsa and update Vcs. Note: There is a pending FTCBFS bug report, I will take care of that and also simplify the d/rules in the next update unless someone adopts it before that. -- Regards Sudip
Bug#947105: [Pkg-puppet-devel] Bug#947105: Bug#947105: puppet: Default install uses outdated configuration file and directory locations
On 12/23/19 7:52 PM, micah anderson wrote: > "Todd H. Poole" writes: > >> As for departing from prior behavior, I'll give you that: that's why there >> was so much messaging around the 4.x release and such a strong up-tick in >> the quality of the upstream docs around that time. If you were to change >> this now, I'd absolutely advocate doing so as part of your Puppet 6.x >> release. > > For me, /etc/puppetlabs indicates the PuppetLabs provided packages, and > *not* the Debian provided packages. This is where they install things, > and I think it would be confusing to mix those two namespaces. Yeah, there's that too! +1 ... Thomas
Bug#743675:
I tried to contact you, but was unsuccessful. I need an urgent answer
Bug#947335: lxc-checkpoint does not work under cgroupv2 / unified hierarchy
Package: lxc Version: 1:3.1.0+really3.0.4-2 Severity: normal Tags: upstream User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Control: forwarded -1 https://github.com/lxc/lxc/issues/3240 Dear Maintainer, Title says everything, and this is an upstream issue reported as https://github.com/lxc/lxc/issues/3240 Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.73 ii libc6 2.29-3 ii libgcc11:9.2.1-21 ii liblxc11:3.1.0+really3.0.4-2 ii lsb-base 11.1.0 Versions of packages lxc recommends: ii apparmor 2.13.3-7 ii bridge-utils 1.6-2 pn debootstrap ii dirmngr 2.2.17-3 ii dnsmasq-base [dnsmasq-base] 2.80-1+b1 ii gnupg2.2.17-3 ii iproute2 5.4.0-1 ii iptables 1.8.3-2 pn libpam-cgfs pn lxc-templates pn lxcfs ii openssl 1.1.1d-2 pn rsync ii uidmap 1:4.7-2 Versions of packages lxc suggests: ii btrfs-progs 5.4-1 ii lvm2 2.03.02-3 pn python3-lxc -- debconf information: lxc/auto_update_config:
Bug#947334: lxc-checkpoint needs the criu package
Package: lxc Version: 1:3.1.0+really3.0.4-2 Severity: normal Dear Maintainer, lxc-checkpoint command needs "criu", which is only available in Debian experimental now. But "criu" is neither suggested nor recommended. Some kind of dependency by lxc seems necessary. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.73 ii libc6 2.29-3 ii libgcc11:9.2.1-21 ii liblxc11:3.1.0+really3.0.4-2 ii lsb-base 11.1.0 Versions of packages lxc recommends: ii apparmor 2.13.3-7 ii bridge-utils 1.6-2 pn debootstrap ii dirmngr 2.2.17-3 ii dnsmasq-base [dnsmasq-base] 2.80-1+b1 ii gnupg2.2.17-3 ii iproute2 5.4.0-1 ii iptables 1.8.3-2 pn libpam-cgfs pn lxc-templates pn lxcfs ii openssl 1.1.1d-2 pn rsync ii uidmap 1:4.7-2 Versions of packages lxc suggests: ii btrfs-progs 5.4-1 ii lvm2 2.03.02-3 pn python3-lxc -- debconf information: lxc/auto_update_config:
Bug#937900: [pkg-lxc-devel] Bug#937900: python-lxc: Python2 removal in sid/bullseye
Le 24 décembre 2019 21:08:39 GMT+01:00, Antonio Terceiro a écrit : >On Thu, Dec 19, 2019 at 07:58:15PM +, Evgeni Golov wrote: >> Hi Moritz, >> >> yeah, that sounds reasonable. >> >> PEB, terceiro, any objections? > >nope, just go ahead Same -- PEB (from my phone)
Bug#946305: linux-image-5.3.0-2-amd64, linux-image-5.3.0-3-amd64 problems copying a large group of files
Under linux kernel-image-4.19.0-6-amd64 Linux 4.19 for 64-bit PCs (signed) (4.19.67-2 + deb10u1) no problems occur when copying folders with files total volume > 100 Gb. Problems were found when working under the linux-image kernel-5.3.0-3-amd64 Linux 5.3 for 64-bit PCs (signed) (5.3.15-1) After copying an array of files in 1.4 Tb from one disk to another, by testing copied "*.rar-files" some files are found with partially distorted content. How this is possible is not yet clear. "rar t" on such files gives messages "checksum error". There may not be any such bad files or be from 1 to 6-7 on the entire array of files. And from copy to copy such failures occur in arbitrary files. A total of 4511 rar files of 1.4 Tb were copied. This happens when you copy through: - copy with " Double Commander" - "cp-Rp"../Download" " / media/u1/u-z/U-Z/" - time ionice -c Best-effort-n 7 cp-Rp "../Download" "/media/user/disk2/" In all 3 cases, copying is about 3 or more hours. After that testing the copied files using time ionice -c Best-effort-n 7 rar t-r "*.rar" &> "log.txt" allows you to detect failures that occur when copying rar archives, the message "checksum error" on such files. I. when you test such copied archives, then you find the replacement of entire blocks on the unknown where the dirt has taken, but the size of the files does not change. So at least you can find it. What's going on with files not protected by CRC codes, one can only guess. This shouldn't be happening! I re-copy the failed files manually through "Double Commander" and then test them this archive. And it passes without mistakes. Testing a copied 1.4 Tb archive array takes between 2.5 hours and 3 hours. Then defragment copied through "e4defrag -v 'path to files massive'". Again I check rar-files through time ionice -c Best-effort-n 7 rar t-r "*.rar" &> "log.txt" And then it turns out that again arbitrarily appear archives, which are reported "checksum error". But at the subsequent individual testing of such archives no "checksum error" messages appear. It turned out that after defragment the copied files, you just need to reset the cache: sync; echo 3 > /proc/sys/vm/drop_caches (with administrator rights) And after resetting the cache, start testing the copied archives. Then "checksum error" messages do not appear. When copying individual folders from this array with "*.rar files" there are no such problems. The problem is related to caching information in Debian. The method of "scientific poke" picked up parameters for Seagate ST2000 disks (disks with" Hot-Plug " Barracuda ST2000DMD001, Constellation ES.3 ST2000NM0033 and CS ST2000NC001, not " Hot-Plug» Barracuda ST2000DM008). About the "vm.dirty_background_ratio " look at the installed package "linux-source" in the folder " /usr/src/linux-source-5.3.tar.xz". Open the archive tar-x-f "/usr/src / linux-source-5.3.tar.xz" And look in the folder " linux-source-5.3/Documentation/admin-guide/sysctl/vm.rst". In General, in the folder "linux-source-5.3/Documentation" a lot of very important documentation on configuring Debian. It is necessary to install for Linux kernel-image-5.3.0-3-amd64 Linux 5.3 for 64-bit PCs (signed) (5.3.15-1): In " /etc/sysctl.d/local.conf" vm.dirty_background_ratio = 5 vm.dirty_background_ratio = 10 (default), =9, = 8, =7, and even at =6 when copying through all three copy methods (see above), there are distortion of information when copying from disk to disk. In "Double Commander" are visible temporary slowdown copying and even temporarily repeatedly pausing copying. Using "Double Commander" you can clearly see the change in the speed of copying and the process itself. Interesting, that in the process copying repeatedly were attempts the most Debian to increase the speed of copying, but with the simultaneous further speed drop to 120 Mb/s, although copying started at 170 Mb/s. When "vm.dirty_background_ratio = 5" stopped occurring after copying 1.4 Tb of rar files of the message "checksum error" at "rar t". That is, we can assume that the information is now copied without distortion. On other computers, the acceptable value is " vm.dirty_background_ratio " can be another. When set to " vm.dirty_background_ratio=5 " copying an array of 1.4 Gb files in "Double Commander" takes the same time as in time ionice -c Best-effort-n 7 cp-Rp "../Download" " /media/u1/disk2/" , i.e. about 3 hours and, in the future, when testing the copied information no errors occur.
Bug#446036:
-- יש קרנות ירושה שלא הוגשו על ידיך שמורשה על שמך מלקוחי שנפטר, אשר אותו שם משפחה לאום איתך. צרו איתי קשר לפרטים נוספים
Bug#947331: buster-pu: package roundcube/1.3.8+dfsg.1-2
Control: tags -1 + moreinfo On Tue, 2019-12-24 at 20:45 +0100, Sandro Knauß wrote: > upstream releases only bugfix releases for the 1.3 branch. As they, > do not add any new feature IMO it would makes sense to ship the > newest 1.3.10 for Debian Buster users. I have packaged 1.3.10 for > Debian. +roundcube (1.3.10+dfsg.1-1~deb10u1) buster; urgency=medium + + * d/control: revert bump of Standards-Version, as we want to release to +stable. + * d/upstream/signing-key.asc: revert Minimize OpenPGP certificate. + * Add patch to Fix "Retry to connect to IMAP server" (Closes: #947320) I'm assuming both from the position of the latter change in the changelog, and the metadata of the referenced bug, that it isn't actually applied in unstable yet? Regards, Adam
Bug#937449: severity of 937449 is normal, retitle 937449 to RM: RoQA: pygopherd, python2, not in testing ...
On Tue, Dec 24, 2019 at 3:46 AM Dimitri John Ledkov wrote: > > So the advise in all of the removal bugs is wrong? > > """ > > If the package has no reverse dependencies, confirm that > the package can be removed, reassign this issue to ftp.debian.org, > make sure that the bug priority is set to normal and retitle the > issue to "RM: PKG -- removal triggered by the Python2 removal". > > """ IMO yes, it should have been worded differently, but what's done is done :) > Ok, I will only clone issues into FTP.debian.org bug tracker from now on. thanks a lot! -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#947333: libghc-base-prelude-doc: missing parens in /usr/share/doc/libghc-base-prelude-doc/html/base-prelude.txt
Package: libghc-base-prelude-doc Version: 1.3-1 Severity: normal In the file /usr/lib/ghc-doc/hoogle/libghc-base-prelude-doc.txt, linked to by /usr/lib/ghc-doc/hoogle/libghc-base-prelude-doc.txt, the line (>>=) :: Monad m => m a -> a -> m b -> m b should read (>>=) :: Monad m => m a -> (a -> m b) -> m b Similarly, (<$>) :: Functor f => a -> b -> f a -> f b should read (<$>) :: Functor f => (a -> b) -> f a -> f b and (<*>) :: Applicative f => f a -> b -> f a -> f b should read (<*>) :: Applicative f => f (a -> b) -> f a -> f b I'd imagine these are just the tip of the iceberg. The underlying problem is probably in Hoogle, since it's what generates this file.
Bug#947332: nm.debian.org: keycheck for different processes
Package: nm.debian.org Severity: wishlist Coupled with https://bugs.debian.org/899305 here I have another thing to take note of: * keycheck should clearly check for different things for different processes (i.e., number of signatures) * also run keycheck for dc_ga, as we really want to block on small keys, or keys lacking the required capabilities, but we don't want it to show the non-required bits -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#947281: inspircd: fails to start due to apparmor policy
Control: tags 947281 confirmed pending Christian Barcenas wrote... > The AppArmor policy that is included with the unstable inspircd package > specifies an incorrect path to the pidfile for the inspircd daemon. Thanks for catching this and the detailled analysis. Upload will follow soon. Christoph signature.asc Description: PGP signature
Bug#937900: [pkg-lxc-devel] Bug#937900: python-lxc: Python2 removal in sid/bullseye
On Thu, Dec 19, 2019 at 07:58:15PM +, Evgeni Golov wrote: > Hi Moritz, > > yeah, that sounds reasonable. > > PEB, terceiro, any objections? nope, just go ahead signature.asc Description: PGP signature
Bug#947331: buster-pu: package roundcube/1.3.8+dfsg.1-2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
upstream releases only bugfix releases for the 1.3 branch. As they,
do not add any new feature IMO it would makes sense to ship the newest
1.3.10 for Debian Buster users. I have packaged 1.3.10 for Debian.
This was also requested for stetch, but I had not find time to do the
actual work: #887507.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'),
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru roundcube-1.3.8+dfsg.1/CHANGELOG roundcube-1.3.10+dfsg.1/CHANGELOG
--- roundcube-1.3.8+dfsg.1/CHANGELOG2018-10-23 13:12:53.0 +0200
+++ roundcube-1.3.10+dfsg.1/CHANGELOG 2019-08-28 13:24:49.0 +0200
@@ -1,6 +1,40 @@
CHANGELOG Roundcube Webmail
===
+RELEASE 1.3.10
+--
+- Managesieve: Fix so "Create filter" option does not show up when Filters
menu is disabled (#6723)
+- Enigma: Fix bug where revoked users/keys were not greyed out in key info
+- Enigma: Fix error message when trying to encrypt with a revoked key (#6607)
+- Enigma: Fix "decryption oracle" bug [CVE-2019-10740] (#6638)
+- Fix compatibility with kolab/net_ldap3 > 1.0.7 (#6785)
+- Fix bug where bmp images couldn't be displayed on some systems (#6728)
+- Fix bug in parsing vCard data using PHP 7.3 due to an invalid regexp (#6744)
+- Fix bug where bold/strong text was converted to upper-case on html-to-text
conversion (6758)
+- Fix bug in rcube_utils::parse_hosts() where %t, %d, %z could return only tld
(#6746)
+- Fix bug where Next/Prev button in mail view didn't work with multi-folder
search result (#6793)
+- Fix bug where selection of columns on messages list wasn't working
+- Fix bug in converting multi-page Tiff images to Jpeg (#6824)
+- Fix wrong messages order after returning to a multi-folder search result
(#6836)
+- Fix PHP 7.4 deprecation: implode() wrong parameter order (#6866)
+- Fix bug where it was possible to bypass the position:fixed CSS check in
received messages (#6898)
+- Fix bug where some strict remote URIs in url() style were unintentionally
blocked (#6899)
+- Fix bug where it was possible to bypass the CSS jail in HTML messages using
:root pseudo-class (#6897)
+- Fix bug where it was possible to bypass href URI check with
data:application/xhtml+xml URIs (#6896)
+
+RELEASE 1.3.9
+-
+- Fix TinyMCE download location (#6694)
+- Fix bug where a message/rfc822 part without a filename wasn't listed on the
attachments list (#6494)
+- Fix handling of empty entries in vCard import (#6564)
+- Fix bug in parsing some IMAP command responses that include unsolicited
replies (#6577)
+- Fix PHP 7.2 compatibility in debug_logger plugin (#6586)
+- Fix so ANY record is not used for email domain validation, use A, MX, CNAME,
instead (#6581)
+- Fix so mime_content_type check in Installer uses files that should always be
available (i.e. from program/resources) (#6599)
+- Fix missing CSRF token on a link to download too-big message part (#6621)
+- Fix bug when aborting dragging with ESC key didn't stop the move action
(#6623)
+- Fix bug where next row wasn't selected after deleting a collapsed thread
(#6655)
+
RELEASE 1.3.8
-
- Fix PHP warnings on dummy QUOTA responses in Courier-IMAP 4.17.1 (#6374)
diff -Nru roundcube-1.3.8+dfsg.1/composer.json-dist
roundcube-1.3.10+dfsg.1/composer.json-dist
--- roundcube-1.3.8+dfsg.1/composer.json-dist 2018-10-23 13:12:54.0
+0200
+++ roundcube-1.3.10+dfsg.1/composer.json-dist 2019-08-28 13:24:50.0
+0200
@@ -30,6 +30,6 @@
},
"suggest": {
"pear/net_ldap2": "~2.2.0 required for connecting to LDAP",
-"kolab/Net_LDAP3": "dev-master required for connecting to LDAP"
+"kolab/net_ldap3": "dev-master required for connecting to LDAP"
}
}
diff -Nru roundcube-1.3.8+dfsg.1/debian/changelog
roundcube-1.3.10+dfsg.1/debian/changelog
--- roundcube-1.3.8+dfsg.1/debian/changelog 2018-11-05 04:38:45.0
+0100
+++ roundcube-1.3.10+dfsg.1/debian/changelog2019-12-23 22:59:40.0
+0100
@@ -1,3 +1,33 @@
+roundcube (1.3.10+dfsg.1-1~deb10u1) buster; urgency=medium
+
+ * d/control: revert bump of Standards-Version, as we want to release to
+stable.
+ * d/upstream/signing-key.asc: revert Minimize OpenPGP certificate.
+ * Add patch to Fix "Retry to connect to IMAP server" (Closes: #947320)
+
+ -- Sandro Knauß Mon, 23 Dec 2019 22:59:40 +0100
+
+roundcube
Bug#947330: FTBFS: *** No rule to make target 'libc2b.a', needed by '../bin/cb2bib'. Stop.
Source: cb2bib Version: 1.9.9-1 Severity: serious Justification: FTBFS Hi! During a rebuild of your package it FTBFS with the following error: g++ -pipe -g -O2 -fdebug-prefix-map=/<>/debian/build/src=. -fstack-protector-strong -Wformat -Werror=format-security -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -W -dM -E -o moc_predefs.h /usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/data/dummy.cpp make[3]: *** No rule to make target 'libc2b.a', needed by '../bin/cb2bib'. Stop. Thanks for your work, Lisandro. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'buildd-unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#947329: FTBFS: debian/bppphyview/usr/share/man/man1/phyview.1: No such file or directory
Source: bppphyview Version: 0.6.1-1 Severity: serious Justification: FTBFS Hi! During a rebuild of your package it FTBFS with the following error: dh_installman: mv debian/bppphyview/usr/share/man/man1/phyview.1.dh-new debian/bppphyview/usr/share/man/man1/phyview.1: No such file or directory Thanks for your work! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'buildd-unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#947328: FTBFS: dh_installman: mv debian/xca/usr/share/man/man1/xca.1.dh-new: No such file or directory
Source: xca Version: 2.1.2-2 Severity: serious Justification: FTBFS Hi! During a rebuild your package FTBFS with the following error: dh_installman: mv debian/xca/usr/share/man/man1/xca.1.dh-new debian/xca/usr/share/man/man1/xca.1: No such file or directory Thanks for your work! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'buildd-unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#947327: FTBFS: /usr/bin/env: ‘python’: No such file or directory
Source: poppler Version: 0.71.0-6 Severity: serious Justification: FTBFS Hi! During a rebuild of your package it FTBFS with the following error: [ 58%] Generating glib-docs-build.stamp cd /<>/obj-x86_64-linux-gnu/glib/reference && ../../../make-glib-api-docs --src-dir=/<> --build-dir=/<>/obj-x86_64-linux-gnu /usr/bin/env: ‘python’: No such file or directory make[3]: *** [glib/reference/CMakeFiles/glib-docs.dir/build.make:64: glib/reference/glib-docs-build.stamp] Error 127 make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:672: glib/reference/CMakeFiles/glib-docs.dir/all] Error 2 Thanks for your work, Lisandro. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'buildd-unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#947326: dh: unable to load addon python3: Can't locate Debian/Debhelper/Sequence/python3.pm in @INC
Source: antimony Version: 0.9.3-1 Severity: serious Justification: FTBFS Hi! While rebuilding your package against a new Qt version it FTBFS due to some python error: dpkg-buildpackage: info: host architecture amd64 fakeroot debian/rules clean dh clean --with python3 --buildsystem=cmake dh: unable to load addon python3: Can't locate Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the Debian::Debhelper::Sequence::python3 module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 10) line 1. BEGIN failed--compilation aborted at (eval 10) line 1. Thnaks for your work, Lisandro. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'buildd-unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#946932: /usr/sbin/ebtables-nft-restore requires /etc/ethertypes
On Dec 24, Marco d'Itri wrote: > I am working on the package, but I need some clarifications before I can > upload it. Also, where do the names in the first column come from, since they are not in the IANA registry? -- ciao, Marco signature.asc Description: PGP signature
Bug#941947: RFS: misspell-fixer/0.1-1 [ITP] -- Tool for fixing common misspellings, typos in source code
On Tue, Dec 24, 2019 at 11:21:15AM +, Lajos Veres wrote: > Thank you. > Do I understand well that removing those 2 files would fix these issues? Yeah. > On Mon, 23 Dec 2019, Adam Borowski wrote: > > There are minor issues such as: > > * unused file debian/misspell-fixer-docs.docs > > * redundant debian/README.source (Homepage: is a field it two other files > > already) > > > > but, I've uploaded to NEW as is. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#947325: snapd: strict confinement is not enabled
Package: snapd Version: 2.42.1-1 Severity: grave Tags: security Justification: user security hole If one installs the example snap hello-world and launches hello-world.evil in apparmored system the application is NOT strictly confined by default. ~$ snap run hello-world.evil Hello Evil World! This example demonstrates the app confinement You should see a permission denied error next If you see this line the confinement is not working correctly, please file a bug My snap debug info ~$ snap debug confinement partial ~$ snap debug sandbox-features apparmor: kernel:caps kernel:domain kernel:file kernel:mount kernel:namespaces kernel:network_v8 kernel:policy kernel:ptrace kernel:query kernel:rlimit kernel:signal parser:unsafe policy:downgraded support-level:partial confinement-options: classic devmode dbus: mediated-bus-access kmod: mediated-modprobe mount:freezer-cgroup-v1 layouts mount-namespace per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles stale-base-invalidation seccomp: bpf-actlog bpf-argument-filtering kernel:allow kernel:errno kernel:kill_process kernel:kill_thread kernel:log kernel:trace kernel:trap kernel:user_notif udev: device-cgroup-v1 tagging I believe the default setting should be "strict" or, at least, the package should have clear documentation on how to enable the strict mode (which, according to upstream, is the default...) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 5.3.15 (SMP w/8 CPU cores; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages snapd depends on: ii adduser 3.118 ii apparmor 2.13.3-7 ii ca-certificates 20190110 ii gnupg2.2.17-3 ii libapparmor1 2.13.3-7 ii libc62.29-6 ii libcap2 1:2.27-1 ii libseccomp2 2.4.2-2 ii libudev1 244-3 ii openssh-client 1:8.1p1-2 ii squashfs-tools 1:4.4-1 ii systemd 244-3 ii udev 244-3 Versions of packages snapd recommends: ii gnupg 2.2.17-3 Versions of packages snapd suggests: ii zenity 3.32.0-4 -- no debconf information
Bug#916076: kamoso: segmentation fault in GStreamer opening hamburger menu
Control: tags -1 moreinfo
I've upgraded to Bullseye and I'm still able to reproduce it. I've attached
new backtraces: one from gdb and a longer one from Dr. Konqi#0 0x7fffdf974af3 in linear_to_ytiled (mem_copy_align16=,
mem_copy=, swizzle_bit=,
src_pitch=,
src=0x7fffe02dbb90 "89A\377@>I\377\071\067B\377,+/\377\035\034
\377\035\033\032\377%#\"\377+$$\377' \377'\036
\377*!#\377+!%\377-#'\377\061(*\377\066-/\377\062,*\377-'%\377)!\037\377&\036\034\377%\035\033\377&\036\034\377*\"
\377,$\"\377+#!\377*\" \377$\033\033\377) \377*!!\377)
\377*!!\377-$$\377/&'\377-$%\377\061*+\377*#$\377'
!\377+$%\377-&'\377,%&\377\061(*\377\063*,\377\063*,\377\063)+\377\062(*\377\061&*\377/$(\377/!&\377.
%\377(!\"\377*#$\377"..., dst=, y3=,
y0=, x3=, x2=,
x1=, x0=) at
../src/intel/isl/isl_tiled_memcpy.c:369
xo = 0
swizzle = 0
xo0 =
swizzle1 =
yo = 128
bytes_per_column =
y1 =
xo1 =
x =
column_width =
y2 =
swizzle0 =
column_width =
bytes_per_column =
y1 =
y2 =
xo0 =
xo1 =
swizzle0 =
swizzle1 =
x =
yo =
xo =
swizzle =
xo =
swizzle =
xo =
swizzle =
#1 linear_to_ytiled_faster (x0=0, x1=0, x2=128, x3=128, y0=y0@entry=0,
y1=y1@entry=32, dst=0x7ffe6180
"Wfd\377Sb_\377Ra^\377_li\377\275\265\257\377\262\255\250\377\306\301\274\377\357\354\351\377KUT\377MWV\377Q[Z\377Q[Z\377HEM\377IGK\377DBF\377HGI\377;MG\377;MG\377:LF\377\071KE\377\026\026\026\377\023\023\023\377\023\023\023\377\023\023\023\377\274\262\252\377\301\272\265\377\327\320\313\377\352\353\347\377LY[\377IWW\377JXX\377GUU\377\070\071A\377@>I\377\071\067B\377,+/\377",
src=0x7fffe02bbb90
"Wfd\377Sb_\377Ra^\377_li\377`mj\377JRU\377\062:=\377\062\065C\377F\377\070\071A\377\070;E\377:=G\377:?I\377J\377\071>J\377\066;G\377\063\070D\377\062\065C\377\064\067E\377\070;I\377:=K\377:;I\377<>J\377;=I\377\070:F\377\063\065A\377./=\377*+9\377+)8\377,*9\377,*9\377-+:\377\060,;\377\061-<\377\061->\377\061->\377\062.?\377\063/@\377/+8\377/+8\377-)8\377+'6\377"...,
src_pitch=16384, swizzle_bit=0, copy_type=ISL_MEMCPY) at
../src/intel/isl/isl_tiled_memcpy.c:684
mem_copy =
#2 0x7fffdf978698 in intel_linear_to_tiled (copy_type=ISL_MEMCPY,
tiling=ISL_TILING_Y0, has_swizzling=false, src_pitch=16384, dst_pitch=16384,
src=, dst=, yt2=128, yt1=0, xt2=16384, xt1=0) at
../src/intel/isl/isl_tiled_memcpy.c:899
x0 =
y1 =
x2 =
y0 =
x3 = 128
x1 =
yt0 = 0
yt3 = 128
tw = 128
th = 32
span =
tile_copy = 0x7fffdf974a10
xt =
xt0 = 0
xt3 = 16384
yt =
swizzle_bit = 0
tile_copy =
xt0 =
xt3 =
yt0 =
yt3 =
xt =
yt =
tw =
th =
span =
swizzle_bit =
x0 =
y0 =
x3 =
y1 =
x1 =
x2 =
#3 _isl_memcpy_linear_to_tiled (xt1=0, xt2=16384, yt1=yt1@entry=0,
yt2=yt2@entry=128, dst=dst@entry=0x7ffe6170
"||z\377}}{\377}}{\377wwu\377fge\377fge\377dfb\377dfb\377`c_\377bba\377ddc\377iih\377[^Z\377\\_[\377]`\\\377]`\\\377nnm\377kki\377mmk\377oom\377\203\203|\377\200\200y\377\200\200y\377\202\202{\377`ba\377bdc\377fhg\377hih\377JLL\377LNN\377OQQ\377RTT\377`g\\\377[bW\377Z`Y\377bha\377vvu\377ppo\377ppo\377vvu\377\205\206\202\377\210\210\202\377\210\210\202\377\211\211\203\377gjf\377dfb\377egc\377fhd\377ffd\377gge\377"...,
src=src@entry=0x7fffe01bbb90
"||z\377}}{\377}}{\377wwu\377}}{\377}}{\377~~|\377\177\177}\377{{y\377z|x\377wyu\377vxq\377xzs\377|~v\377}\177w\377y|q\377{\177r\377|\200s\377~\177u\377~\177u\377~\177u\377}~t\377zzs\377|\200u\377z~s\377y{s\377wyq\377xxr\377||v\377\207\204\201\377~{x\377|yv\377|zt\377~|v\377~~w\377}}v\377|\177t\377vvo\377xxq\377zzs\377}}v\377\200\201w\377\203\205y\377\203\205y\377\177\201u\377}\177s\377|}s\377}~t\377\201\201z\377\200\200y\377"...,
dst_pitch=16384, src_pitch=16384, has_swizzling=false, tiling=ISL_TILING_Y0,
copy_type=ISL_MEMCPY) at ../src/intel/isl/isl_tiled_memcpy_normal.c:44
No locals.
#4 0x7fffdf9689a5 in isl_memcpy_linear_to_tiled (xt1=,
xt2=, yt1=yt1@entry=0, yt2=yt2@entry=128,
dst=dst@entry=0x7ffe6170
"||z\377}}{\377}}{\377wwu\377fge\377fge\377dfb\377dfb\377`c_\377bba\377ddc\377iih\377[^Z\377\\_[\377]`\\\377]`\\\377nnm\377kki\377mmk\377oom\377\203\203|\377\200\200y\377\200\200y\377\202\202{\377`ba\377bdc\377fhg\377hih\377JLL\377LNN\377OQQ\377RTT\377`g\\\377[bW\377Z`Y\377bha\377vvu\377ppo\377ppo\377vvu\377\205\206\202\377\210\210\202\377\210\210\202\377\211\211\203\377gjf\377dfb\377egc\377fhd\377ffd\377gge\377"...,
src=src@entry=0x7fffe01bbb90
Bug#801233:
Hola querida, ¡Felicitaciones de la temporada para ti! Por favor, tengo una cuestión vital que me gustaría discutir con usted, así que intente y me responda lo antes posible
Bug#947324: opendkim-tools: Please provide miltertest binary (split from opendkim-tools)
Package: opendkim-tools Version: 2.11.0~alpha-12 Severity: wishlist Dear Maintainer, The miltertest program in opendkim-tools is not really opendkim specific (I use it to test dkimpy-milter). It would be nice if it were in its own binary so it could be installed without any other opendkim components. Thanks, Scott K -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages opendkim-tools depends on: ii libbsd00.9.1-2 ii libc6 2.28-10 ii libdb5.3 5.3.28+dfsg1-0.5 ii libldap-2.4-2 2.4.47+dfsg-3+deb10u1 ii liblua5.1-05.1.5-8.1+b2 ii libmemcached11 1.0.18-4.2 ii libmemcachedutil2 1.0.18-4.2 ii libopendbx11.4.6-13+b1 ii libopendkim11 2.11.0~alpha-12 ii librbl12.11.0~alpha-12 ii libssl1.1 1.1.1d-0+deb10u2 ii libunbound81.9.0-2+deb10u1 ii libvbr22.11.0~alpha-12 opendkim-tools recommends no packages. opendkim-tools suggests no packages. -- no debconf information
Bug#947323: libcap-ng: Please install libs back into /usr/lib/ when usrmerge arrives
Source: libcap-ng Severity: normal Version: 0.7.9-2.1 Dear libcap-ng maintainer, With the progress of usrmerge, it should be reasonable to move libcap-ng so files back to /usr/lib/ when usrmerge becomes the default of Debian installation. (See https://bugs.debian.org/829126 and https://bugs.debian.org/828992 for the original reason of moving the library into /lib). -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#947322: RFS: xsane/0.999-8 -- featureful graphical frontend for SANE (Scanner Access Now Easy)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "xsane" Package name: xsane Version : 0.999-8 Upstream Author : Oliver Rauch URL : dead License : GPL-2+ Vcs : https://jff.email/cgit/xsane.git Section : graphics It builds those binary packages: xsane- featureful graphical frontend for SANE (Scanner Access Now Easy) xsane-common - xsane architecture independent files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xsane Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/x/xsane/xsane_0.999-8.dsc or from git: https://jff.email/cgit/xsane.git/?h=release%2Fdebian%2F0.999-8 Changes since the last upload: * Add missing pnm, xpm and rc files into the doc directory (Closes: #941344). * Declare compliance with Debian Policy 4.4.1.2 (No changes needed). * debian/control: - Add Rules-Requires-Root: no. * Switch to debhelper-compat: - debian/control: change to debhelper-compat (=12). - remove debian/compat. * Rename NEWS.Debian to NEWS. The build with sbuild --no-arch-all && sbuild --no-arch-any && sbuild and pdebuild and the tests with Lintain are ok. Puiparts fails about "package purging left files on system" mostly from a mime package. +--+ | Summary | +--+ Build Architecture: amd64 Build Type: full Build-Space: 52800 Build-Time: 30 Distribution: sid Host Architecture: amd64 Install-Time: 252 Job: /data/entwicklung/linux/debian/xsane/xsane_0.999-8.dsc Lintian: info Machine Architecture: amd64 Package: xsane Package-Time: 293 Piuparts: fail Source-Version: 0.999-8 Space: 52800 Status: successful Version: 0.999-8 Finished at 2019-12-24T16:05:19Z Build needed 00:04:53, 52800k disk space CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#947321: buster-pu: package dkimpy/0.9.1-1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu This proposed update includes fixes for all user reported bugs since the last version available before buster froze. These are all issues reported by actual package users (not all on Debian). The two most imoprtant issues are: - Updating the ARC (Authenticated Receive Chain) code to match the final version of the spec. RFC 8617 is published not, so it is highly unlikely to change again during Buster's lifetime. - Ignoring unknown service types: Since 0.9.1 was released, a new DKIM service type, TLSRPT, has been defined and is starting to see use. RFC 6376 (DKIM RFC) always required unknown service types to be ignored, but since there had only ever been one, that check was never implemented. This change will prevent mis-processing of TLSRPT service signatures. Some of the fixes (like the pydns CNAME processing issue, for example) don't directly affect dkimpy as packaged in Debian, but I would prefer to use the upstream bugfix release without modification to minimize risk I make a mistake when extracting changes. I have the package ready to go. I've run the autopkgtest in a Buster chroot and it passes. All these fixes are in version 1.0.1 in Testing. Thanks. Full debian/changelog with upstream changelog entries follows: * Update debian/watch to only see 0.9 versions for stable updates * Update debian/gbp.conf to use buster branches * New upstream bugfix releases: * 0.9.6 - Follow CNAMES when looking up key records when using DNS (pydns) (LP: #1856421) - Provide specialized error message when signing or verifying ed25519 signatures and pynacl is not installed (LP: #1854475) - Catch binascii related key format errors (LP: #1854477) * 0.9.5 - Ignore unknown service types in key records (LP: #1847020) - This is required by RFC 6376 and predecessors. It becomes important now that RFC 8460, which defines a new DKIM service type exists. This change is required to avoid processing tlsrpt keys like regular email keys, which is incorrect, they have different requirements. * 0.9.4 - Add LICENSE to MANIFEST.in so it is included in the tarball (LP: #1845318) * 0.9.3 - Fix linesep setting in arcsign script (LP: #1838262) (Thanks to Gowtham Gopalakrishnan for the report and the patch) - Fix default canonicalization for DKIM signature verification to be simple/simple per RFC 6376 (LP: #1839299) (Thanks to Cyril Nicodème for the report and a suggested fix) * 0.9.2 - Fix the arcsign script so it works with the current API (Note: the new srv_id option is the authserv_id to use in the ARC signatures - Only AR fields with an authserv-id that matches srv_id will be considered for ARC signing) - Fix cv=none processing for initial signature in chain - Add additional text documenting use of srv_id for ARC signing to docstrings and man 1 arcsign (LP: #1808301) - Use same line seperator for output as input in dkimsign/arcsign (LP: #1808686) - Refactor canonicalization.py strip_trailing_lines to avoid using re for more consistent processing across python versions (Thanks to Jonathan Bastien-Filiatrault for the change) - Refactor header folding for more consistent results, including reduced stray whitespace (Also Jonathan Bastien-Filiatrault) - Don't log message headers and body unless explicitely requested. This should also reduce memory usage on large messages. (Jonathan Bastien-Filiatrault) - Clarify the crlf does not count towards line length in fold - Adjust fold maxlen to one shorter for lines after the first, since they already have a leading space (LP: #1823008) Scott K diff -Nru dkimpy-0.9.1/ChangeLog dkimpy-0.9.6/ChangeLog --- dkimpy-0.9.1/ChangeLog 2018-12-09 14:04:26.0 -0500 +++ dkimpy-0.9.6/ChangeLog 2019-12-24 10:22:40.0 -0500 @@ -1,3 +1,50 @@ +2019-12-24 Version 0.9.6 +- Follow CNAMES when looking up key records when using DNS (pydns) + (LP: #1856421) +- Provide specialized error message when signing or verifying ed25519 + signatures and pynacl is not installed (LP: #1854475) +- Catch binascii related key format errors (LP: #1854477) + +2019-10-07 Version 0.9.5 +- Ignore unknown service types in key records (LP: #1847020) + - This is required by RFC 6376 and predecessors. It becomes important +now that RFC 8460, which defines a new DKIM service type exists. This + change is required to avoid processing tlsrpt keys like regular email + keys, which is incorrect, they have different requirements. + +2019-09-25 Verstion 0.9.4 +- Add LICENSE to MANIFEST.in so it is included in the tarball (LP: + #1845318) + +2019-08-09 Version 0.9.3 +- Fix linesep setting in arcsign script
Bug#946932: /usr/sbin/ebtables-nft-restore requires /etc/ethertypes
On Dec 20, Alberto Molina Coballes wrote: > /etc/ethertypes has been removed from ebtables and 2.0.11-2 has been > uploaded to unstable, please Marco include /etc/ethertypes in netbase > with Replaces/Breaks ebtables (<< 2.0.11-2) and comment us when a new > release is available in order to include Depends in both ebtables and > iptables. I am working on the package, but I need some clarifications before I can upload it. http://www.iana.org/assignments/ethernet-numbers is mentioned in the comment, but do not understand how it would be relevant to the ethertypes. Did you follow some policy in updating the file? I see that e.g. TRILL is missing, but it contains entries for DEC protocols which probably have not been used in 20 years. Unless there are specific requirements that I am not aware of then I would rather remove the historical entries from the file like I am currently doing for /etc/services. -- ciao, Marco signature.asc Description: PGP signature
Bug#947320: roundcube-core: Retry to connect to IMAP server
Package: roundcube-core
Version: 1.3.8+dfsg.1-2
Severity: important
Tags: patch
Hey,
An IMAP server may have temporally issues, like to much load and roundcube
fails with
"Empty startup gretting".
Hefee
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'),
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages roundcube-core depends on:
ii dbconfig-common 2.0.13
ii debconf [debconf-2.0] 1.5.73
ii dpkg1.19.7
ii libapache2-mod-php 2:7.3+69
ii libapache2-mod-php7.3 [libapache2-mod-php] 7.3.12-1
pn libjs-bootstrap4
ii libjs-codemirror5.49.2-1
ii libjs-jquery3.3.1~dfsg-3
pn libjs-jquery-minicolors
ii libjs-jquery-ui 1.12.1+dfsg-5
pn libjs-jstimezonedetect
ii libmagic1 1:5.37-6
pn php-auth-sasl
ii php-cli 2:7.3+69
ii php-common 2:69
pn php-intl
pn php-mail-mime
pn php-masterminds-html5
pn php-mbstring
pn php-mcrypt
pn php-net-sieve
pn php-net-smtp
pn php-net-socket
ii php-pear1:1.10.9+submodules+notgz-1
ii php7.0-cli [php-cli]7.0.33-0+deb9u6
ii php7.0-json [php-json] 7.0.33-0+deb9u6
ii php7.2-cli [php-cli]7.2.9-1
ii php7.2-json [php-json] 7.2.9-1
ii php7.3-cli [php-cli]7.3.12-1
ii php7.3-json [php-json] 7.3.12-1
pn roundcube-mysql | roundcube-sqlite3 | roundcub
ii ucf 3.0038+nmu1
Versions of packages roundcube-core recommends:
ii apache2 [httpd-cgi] 2.4.41-1
pn php-gd
pn php-pspell
Versions of packages roundcube-core suggests:
pn php-crypt-gpg
pn php-mkopinsky-zxcvbn-php
pn php-net-ldap2
pn php-net-ldap3
pn roundcube-plugins
Description: Retries to connect to IMAP server.
As it may happen, that an IMAP server will have temporally issues and answers
with "Empty startup greeting".
Author: Hefee
Last-Update: 2019-12-24
---
--- a/program/lib/Roundcube/rcube_imap.php
+++ b/program/lib/Roundcube/rcube_imap.php
@@ -144,7 +144,11 @@ class rcube_imap extends rcube_storage
$attempt = 0;
do {
-$data = $this->plugins->exec_hook('storage_connect',
+if ($attempt > 0) {
+usleep(rand(1000, 10));
+}
+rcube::write_log('imap','Connecting to IMAP server
attempt:'.$attempt);
+$data = $this->plugins->exec_hook('storage_connect',
array_merge($this->options, array('host' => $host, 'user' =>
$user,
'attempt' => ++$attempt)));
@@ -156,7 +160,7 @@ class rcube_imap extends rcube_storage
rcube_utils::parse_socket_options($data['socket_options'],
$data['host']);
$this->conn->connect($data['host'], $data['user'], $pass, $data);
-} while(!$this->conn->connected() && $data['retry']);
+} while(!$this->conn->connected() && $data['attempt'] < 6);
$config = array(
'host' => $data['host'],
Bug#947311: graphicsmagick: CVE-2019-19953
This problem (and some others) are fixed in GraphicsMagick 1.3.34, which is released today. Bob On Tue, 24 Dec 2019, Salvatore Bonaccorso wrote: Source: graphicsmagick Version: 1.4+really1.3.33+hg16117-1 Severity: important Tags: security upstream Forwarded: https://sourceforge.net/p/graphicsmagick/bugs/617/ Hi, The following vulnerability was published for graphicsmagick. CVE-2019-19953[0]: | In GraphicsMagick 1.4 snapshot-20191208 Q8, there is a heap-based | buffer over-read in the function EncodeImage of coders/pict.c. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-19953 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19953 [1] https://sourceforge.net/p/graphicsmagick/bugs/617/ [2] http://hg.graphicsmagick.org/hg/GraphicsMagick/rev/28f8bacd4bbf Please adjust the affected versions in the BTS as needed. Regards, Salvatore -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Bug#947282: yapps2: diff for NMU version 2.2.1-3.1
On Tue, Dec 24, 2019 at 11:49:19AM +0100, Matthias Urlichs wrote: > Hello Colin, > > I've prepared an NMU for yapps2 (versioned as 2.2.1-3.1) and uploaded it > > to DELAYED/10. Please feel free to tell me if I should delay it longer. > > Thanks for taking care of this, I'm swamped with other work. > > Feel free to re-submit directly, no need for DELAYED as far as I am > concerned. OK, thanks. Moved to 0-day and it looks like it's been processed now. I'll leave this bug open for you to acknowledge with your next maintainer upload if you want. -- Colin Watson [cjwat...@debian.org]
Bug#947216: yapps2: should this package be removed?
On Mon, Dec 23, 2019 at 06:29:05PM -0500, Sandro Tosi wrote: > Colin Watson wrote: > > I've made a DELAYED/10 NMU to fix these bugs, as well as removing the > > Python 2 binary package and fixing #911730. I think that gets things > > thanks for quickly addressing this. I think you can upload your NMU > directly to unstable, the maintainer doesnt seem responsive and you're > fixing an RC bug. The maintainer replied to ack my NMU, so I rescheduled it and it's been accepted now. Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#936924: Moving libsvm to Debian Science team
Thanks, Andreas. I just submitted a PR for dropping python2 dependencies: https://salsa.debian.org/science-team/libsvm/merge_requests/1 Any comment is appreciated. I'll be working on upgrading to new upstream. Thanks, Chen-Tse On Mon, Dec 23, 2019 at 4:03 PM Andreas Tille wrote: > On Mon, Dec 23, 2019 at 03:06:37PM -0500, Chen-Tse Tsai wrote: > > I have a quick question. Previously the python modules are installed to > > /usr/share/pyshared/. Should I use /usr/lib/python3/dist-packages instead > > if I change it to python3? I see this in the policy and this is also what > > liblinear uses. Just want to double check. > > Yes, follow liblinear example. > > Thanks for your work on this > > Andreas. > > -- > http://fam-tille.de >
Bug#947319: missing directory
It seems a directory is missing : --- Could not enumerate user data directory /var/lib/lightdm/data: Error opening directory '/var/lib/lightdm/data': No such file or directory --- I attached the last lines of my /var/log/syslog Dec 24 15:31:43 l systemd[1]: anacron.service: Succeeded. Dec 24 15:39:30 l systemd[1]: Starting Cleanup of Temporary Directories... Dec 24 15:39:31 l systemd[1]: systemd-tmpfiles-clean.service: Succeeded. Dec 24 15:39:31 l systemd[1]: Started Cleanup of Temporary Directories. Dec 24 15:47:42 l systemd[1]: Started Getty on tty2. Dec 24 15:47:47 l systemd[1]: Started Session 5 of user j. Dec 24 16:05:02 l systemd[1]: Stopping Authorization Manager... Dec 24 16:05:02 l systemd[1]: Stopped target Sound Card. Dec 24 16:05:02 l systemd[1]: Stopping Save/Restore Sound Card State... Dec 24 16:05:02 l systemd[1]: Stopped target Graphical Interface. Dec 24 16:05:02 l systemd[1]: Stopped target Multi-User System. Dec 24 16:05:02 l systemd[1]: Stopped target Login Prompts. Dec 24 16:06:37 l systemd-modules-load[168]: Inserted module 'firewire_sbp2' Dec 24 16:06:37 l systemd[1]: Starting Flush Journal to Persistent Storage... Dec 24 16:06:37 l systemd[1]: Started Flush Journal to Persistent Storage. Dec 24 16:06:37 l systemd[1]: Started Set the console keyboard layout. Dec 24 16:06:37 l systemd[1]: Reached target Local File Systems (Pre). Dec 24 16:06:37 l systemd[1]: Started udev Kernel Device Manager. Dec 24 16:06:37 l systemd-udevd[197]: Using default interface naming scheme 'v240'. Dec 24 16:06:37 l systemd-udevd[197]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Dec 24 16:06:37 l systemd-udevd[202]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Dec 24 16:06:37 l systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped. Dec 24 16:06:37 l systemd[1]: Condition check resulted in FUSE Control File System being skipped. Dec 24 16:06:37 l systemd[1]: Condition check resulted in File System Check on Root Device being skipped. Dec 24 16:06:37 l systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. Dec 24 16:06:37 l systemd[1]: Condition check resulted in Kernel Configuration File System being skipped. Dec 24 16:06:37 l systemd[1]: Found device RTL-8100/8101L/8139 PCI Fast Ethernet Adapter. Dec 24 16:06:37 l systemd[1]: Found device FUJITSU_MHM2100AT 5. Dec 24 16:06:37 l systemd[1]: Activating swap /dev/disk/by-uuid/03a421c3-c67f-4c3a-8731-8b01bf8b9571... Dec 24 16:06:37 l systemd[1]: Activated swap /dev/disk/by-uuid/03a421c3-c67f-4c3a-8731-8b01bf8b9571. Dec 24 16:06:37 l systemd[1]: Reached target Swap. Dec 24 16:06:37 l systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway. Dec 24 16:06:37 l systemd[1]: Mounting /tmp... Dec 24 16:06:37 l systemd[1]: Mounted /tmp. Dec 24 16:06:37 l systemd[1]: Reached target Local File Systems. Dec 24 16:06:37 l systemd[1]: Condition check resulted in Commit a transient machine-id on disk being skipped. Dec 24 16:06:37 l systemd[1]: Starting Set console font and keymap... Dec 24 16:06:37 l systemd[1]: Starting Load AppArmor profiles... Dec 24 16:06:37 l systemd[1]: Starting Create Volatile Files and Directories... Dec 24 16:06:37 l systemd[1]: Started Set console font and keymap. Dec 24 16:06:37 l systemd[1]: Started Create Volatile Files and Directories. Dec 24 16:06:37 l apparmor.systemd[256]: Restarting AppArmor Dec 24 16:06:37 l apparmor.systemd[256]: Reloading AppArmor profiles Dec 24 16:06:37 l systemd[1]: Starting Network Time Synchronization... Dec 24 16:06:37 l systemd[1]: Starting Update UTMP about System Boot/Shutdown... Dec 24 16:06:37 l systemd[1]: Started Update UTMP about System Boot/Shutdown. Dec 24 16:06:37 l kernel: [0.00] Linux version 4.19.0-6-686-pae (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) Dec 24 16:06:37 l kernel: [0.00] x86/fpu: x87 FPU will use FXSAVE Dec 24 16:06:37 l kernel: [0.00] BIOS-provided physical RAM map: Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 0x000ea400-0x000f] reserved Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 0x0010-0x0ffe] usable Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 0x0fff-0x0bff] ACPI data Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 0x0c00-0x0fff] ACPI NVS Dec 24 16:06:37 l kernel: [0.00] BIOS-e820: [mem 0xfffe-0x] reserved Dec 24 16:06:37 l kernel: [0.00] Notice: NX (Execute Disable) protection missing in CPU! Dec 24 16:06:37 l
Bug#947319: lightdm: fails during startup (no invite)
Package: lightdm Version: 1.26.0-4 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Fresh install. * What exactly did you do (or not do) that was effective (or ineffective)? I never saw lightdm working since I installed the new system. * What was the outcome of this action? I can't use the graphical environnement. * What outcome did you expect instead? Enable graphical environnement. -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.19.0-6-686-pae (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lightdm depends on: ii adduser3.118 ii dbus 1.12.16-1 ii debconf [debconf-2.0] 1.5.71 ii libaudit1 1:2.8.4-3 ii libc6 2.28-10 ii libgcrypt201.8.4-5 ii libglib2.0-0 2.58.3-2+deb10u2 ii libpam-systemd [logind]241-7~deb10u2 ii libpam0g 1.3.1-5 ii libxcb11.13.1-2 ii libxdmcp6 1:1.1.2-3 ii lightdm-gtk-greeter [lightdm-greeter] 2.0.6-1 ii lsb-base 10.2019051400 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+19 Versions of packages lightdm suggests: pn accountsservice pn upower pn xserver-xephyr -- debconf information: * shared/default-x-display-manager: lightdm lightdm/daemon_name: /usr/sbin/lightdm
Bug#947318: libexiv2-14: ExivGroup invalid memory access
Package: libexiv2-14 Version: 0.25-4 Severity: important Tags: buster Affects: gwenview The attached (extracted) exif data dump can be used to crash (lib)exiv2 under debian buster. This is causing crashes of gwenview or similar graphical image viewers. But it can reproduced easier with the exiv command tool: $ valgrind exiv2 -pt dfa12848-c367-463f-8308-1508466631e1.exv ==18807== Memcheck, a memory error detector ==18807== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==18807== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==18807== Command: exiv2 -pt dfa12848-c367-463f-8308-1508466631e1.exv ==18807== Exif.Image.ImageDescription Ascii 1 Exif.Image.Make Ascii 1 Exif.Image.Model Ascii 1 Exif.Image.Software Ascii 1 Exif.Image.DateTime Ascii 1 Exif.Image.ArtistAscii 1 Exif.Image.ExifTag Long1 134 Exif.Photo.ExifVersion Undefined 1 (0) Exif.Photo.DateTimeOriginal Ascii 1 Exif.Photo.DateTimeDigitized Ascii 1 Exif.Photo.ComponentsConfiguration Undefined 1 Exif.Photo.UserComment Undefined 1 Exif.Photo.SubSecTimeAscii 1 Exif.Photo.SubSecTimeOriginalAscii 1 Exif.Photo.SubSecTimeDigitized Ascii 1 Exif.Photo.FlashpixVersion Undefined 1 (0) Exif.Photo.SceneType Undefined 1 (0) Exif.Photo.ImageUniqueID Ascii 1 Exif.Image.GPSTagLong1 272 Exif.GPSInfo.GPSVersionIDByte1 0 Exif.GPSInfo.GPSLatitudeRef Ascii 1 () Exif.GPSInfo.GPSLongitudeRef Ascii 1 () Exif.GPSInfo.GPSAltitudeRef Byte1 Above sea level Exif.GPSInfo.GPSProcessingMethod Undefined 1 0 Exif.GPSInfo.GPSDateStampAscii 1 ==18807== Invalid read of size 1 ==18807==at 0x49C95BB: Exiv2::Internal::printUcs2(std::ostream&, Exiv2::Value const&, Exiv2::ExifData const*) (tags.cpp:2324) ==18807==by 0x498B26B: Exiv2::Metadatum::print[abi:cxx11](Exiv2::ExifData const*) const (metadatum.cpp:80) ==18807==by 0x11DB7B: Action::Print::printMetadatum(Exiv2::Metadatum const&, Exiv2::Image const*) (actions.cpp:711) ==18807==by 0x11E00E: Action::Print::printMetadata(Exiv2::Image const*) (actions.cpp:536) ==18807==by 0x11E2D7: Action::Print::printList() (actions.cpp:526) ==18807==by 0x122CFF: Action::Print::run(std::__cxx11::basic_string, std::allocator > const&) (actions.cpp:241) ==18807==by 0x10EA4C: main (exiv2.cpp:171) ==18807== Address 0x54a5f7f is 1 bytes before a block of size 1 alloc'd ==18807==at 0x483650F: operator new[](unsigned long) (vg_replace_malloc.c:423) ==18807==by 0x49C95A1: DataBuf (types.hpp:194) ==18807==by 0x49C95A1: Exiv2::Internal::printUcs2(std::ostream&, Exiv2::Value const&, Exiv2::ExifData const*) (tags.cpp:2321) ==18807==by 0x498B26B: Exiv2::Metadatum::print[abi:cxx11](Exiv2::ExifData const*) const (metadatum.cpp:80) ==18807==by 0x11DB7B: Action::Print::printMetadatum(Exiv2::Metadatum const&, Exiv2::Image const*) (actions.cpp:711) ==18807==by 0x11E00E: Action::Print::printMetadata(Exiv2::Image const*) (actions.cpp:536) ==18807==by 0x11E2D7: Action::Print::printList() (actions.cpp:526) ==18807==by 0x122CFF: Action::Print::run(std::__cxx11::basic_string, std::allocator > const&) (actions.cpp:241) ==18807==by 0x10EA4C: main (exiv2.cpp:171) ==18807== Exif.Image.XPTitle Byte1 Uncaught exception: basic_string::_M_create ==18807== ==18807== HEAP SUMMARY: ==18807== in use at exit: 1,452 bytes in 23 blocks ==18807== total heap usage: 662 allocs, 639 frees, 130,284 bytes allocated ==18807== ==18807== LEAK SUMMARY: ==18807==definitely lost: 0 bytes in 0 blocks ==18807==indirectly lost: 0 bytes in 0 blocks ==18807== possibly lost: 0 bytes in 0 blocks ==18807==still reachable: 1,452 bytes in 23 blocks ==18807== suppressed: 0 bytes in 0 blocks ==18807== Rerun with --leak-check=full to see details of leaked memory ==18807== ==18807== For counts of detected and suppressed errors, rerun with: -v ==18807== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Or when started without valgrind exiv2 -pt dfa12848-c367-463f-8308-1508466631e1.exv Exif.Image.ImageDescription
Bug#947317: uscan: Please allow .gitattributes override
Package: devscripts Version: 2.19.5+deb10u1 Severity: wishlist Dear Maintainer, I'm packaging phppgadmin[1]. Upstream provides several nice test suites, but they are strip from the official release tarball using a .gitattributes file with export-ignore lines[2]. Tests include a lot of files, like selenium core-lib. In turn, selenium bundle many external libraries. It makes sense to me that the final user doesn't want the full test suite deployed. So I fell unconfortable asking upstream to change their way of not releasing all this. However, I do want to get these files, at least in the source, so I can run unit tests. Uscan already provides a nice way to use upstream git. However, uscan calls "git archive" that also takes into account the .gitattributes file, so that it also removes the "/tests" files. Right now, I'm building a orig file using "git deborig" [3]. This is quite ugly. I believe it would be easy for uscan to override or ignore this .gitattributes file, like "git deborig" does. That would help a lot. Please provide a way to override / ignore / patch upstream .gitattributes. Hint: git archive have an option --worktree-attributes, that allows such override [4]. As far as I known, uscan doesn't provide a way to run code between "git clone" and "git archive". [1] https://tracker.debian.org/pkg/phppgadmin [2] https://github.com/phppgadmin/phppgadmin/blob/master/.gitattributes [3] https://salsa.debian.org/postgresql/phppgadmin/blob/debian/sid/debian/README.source [4] https://manpages.debian.org/buster/git-man/git-archive.1.en.html -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- Not present -- System Information: Debian Release: 10.2 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages devscripts depends on: ii dpkg-dev 1.19.7 ii fakeroot 1.23-1 ii file 1:5.35-4+deb10u1 ii gnupg 2.2.12-1+deb10u1 ii gpgv 2.2.12-1+deb10u1 ii libc6 2.28-10 ii libfile-homedir-perl 1.004-1 ii libfile-which-perl1.23-1 ii libipc-run-perl 20180523.0-1 ii libmoo-perl 2.003004-2 ii libwww-perl 6.36-2 ii patchutils0.3.4-2 ii perl 5.28.1-6 ii python3 3.7.3-1 ii sensible-utils0.0.12 ii wdiff 1.2.2-2+b1 Versions of packages devscripts recommends: ii apt 1.8.2 ii at 3.1.23-1 ii curl7.64.0-4 ii dctrl-tools 2.24-3 ii debian-keyring 2019.02.25 ii dput1.0.3 ii equivs 2.2.0 ii libdistro-info-perl 0.21 ii libdpkg-perl1.19.7 ii libencode-locale-perl 1.05-1 ii libgit-wrapper-perl 0.048-1 ii libgitlab-api-v4-perl 0.16-1 ii liblist-compare-perl0.53-1 ii liblwp-protocol-https-perl 6.07-2 ii libsoap-lite-perl 1.27-1 ii libstring-shellquote-perl 1.04-1 ii libtry-tiny-perl0.30-1 ii liburi-perl 1.76-1 ii licensecheck3.0.31-3 ii lintian 2.15.0 ii man-db 2.8.5-2 ii patch 2.7.6-3+deb10u1 ii python3-apt 1.8.4 ii python3-debian 0.1.35 ii python3-magic 2:0.4.15-2 ii python3-requests2.21.0-1 ii python3-unidiff 0.5.4-1 ii python3-xdg 0.25-5 ii strace 4.26-0.2 ii unzip 6.0-23+deb10u1 ii wget1.20.1-1.1 ii xz-utils5.2.4-1 Versions of packages devscripts suggests: pn adequate pn autopkgtest pn bls-standalone ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-1 ii build-essential 12.6 pn check-all-the-things pn cvs-buildpackage ii debhelper 12.1.1 pn devscripts-el pn diffoscope pn disorderfs pn dose-extra pn duck pn faketime pn gnuplot pn how-can-i-help ii libauthen-sasl-perl 2.1600-1 pn libdbd-pg-perl ii libfile-desktopentry-perl
Bug#947064: texlive-fonts-extra: fourier-orns.sty broken, docs using the Fourier font no longer compile
Hi Hilmar, Well, then... Why do you report an issue for Package: texlive-fonts-extra Version: 2019.20191208-1 Severity: important ...if you don't have that version installed? Hmm... I did not change anything by hand to what "reportbug" had observed or computed. So what must have happened is that I sent the initial bug report from the machine where I had first observed it, but later on I copy-pasted messages generated on another computer. Sorry, my fault. These two computers, one at work, the other at home, are supposed to be clones; I now know that they are not exact clones. I confirm that one computer (the one for the initial bug report) says 2019.20191208-1 and the other one 2018.20190227-2 . Kind regards, Sébastien.
Bug#947316: xserver-xorg-video-nvidia: (EE) No devices detected, after upgrading to Asrock TRX40 Creator
Package: xserver-xorg-video-nvidia Version: 440.44-1 Severity: important Tags: upstream Xorg startup fails to find any devices. This started happening when I upgraded my motherboard & CPU. The previous motherboard was Asrock X399 Taichi, and the new motherboard is Asrock TRX40 Creator. All other components are identical. The Xorg.0.log file is attached below. It is interesting that the NVidia module is still probed and installed properly, and the framebuffer console is working without problems, and nvidia-smi and nvidia-xconfig probe and find all the right stuff (outputs are attached below). It’s just that Xorg fails to identify any devices, without so much as even an indication that an attempt was made. As per information I found in Internet, I tried writing an xorg.conf file that specifies the BusID fields addresses explicitly (as "PCI:1:0:0" and "PCI:33:0:0"), but it did not help. On NVidia driver version 430.64, this causes the Xorg list this error: "Device(s) detected, but none match those in the config file." And on NVidia driver version 440.44, it causes no change whatsoever in Xorg.0.log. This behavior is consistent and occurs every time that Xorg startup is attempted. -- Package-specific info: uname -a: Linux hariyu 5.3.0-3-amd64 #1 SMP Debian 5.3.15-1 (2019-12-07) x86_64 GNU/Linux /proc/version: Linux version 5.3.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20191130 (Debian 9.2.1-21)) #1 SMP Debian 5.3.15-1 (2019-12-07) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 440.44 Sun Dec 8 03:38:56 UTC 2019 GCC version: gcc version 9.2.1 20191130 (Debian 9.2.1-21) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06] (rev a1) (prog-if 00 [VGA controller]) Subsystem: eVga.com. Corp. GP102 [GeForce GTX 1080 Ti] [3842:6593] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [420 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 Capabilities: [900 v1] Secondary PCI Express Kernel driver in use: nvidia Kernel modules: nvidia 21:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GM204 [GeForce GTX 970] [1043:8508] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 Capabilities: [900 v1] Secondary PCI Express Kernel driver in use: nvidia Kernel modules: nvidia dmesg: [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.3.0-3-amd64 root=/dev/mapper/hariyu-root ro vsyscall=emulate resume=/dev/hariyu/swap zswap.enabled=1 zswap.compressor=lz4 zswap.zpool=z3fold zswap.max_pool_percent=75 nopti nospectre_v2 vga=120x60 mce=off [0.374683] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.3.0-3-amd64 root=/dev/mapper/hariyu-root ro vsyscall=emulate resume=/dev/hariyu/swap zswap.enabled=1 zswap.compressor=lz4 zswap.zpool=z3fold zswap.max_pool_percent=75 nopti nospectre_v2 vga=120x60 mce=off [0.980278] pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none [0.980278] pci :21:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none [0.980278] pci :01:00.0: vgaarb: bridge control possible [0.980278] pci :21:00.0: vgaarb: bridge control possible [0.980278] pci :01:00.0: vgaarb: setting as boot device [0.980278] vgaarb: loaded [2.455378] fb0: EFI VGA frame buffer device [2.458706] Linux agpgart interface v0.103 [5.819204] nvidia: loading out-of-tree module taints kernel. [5.819457] nvidia: loading out-of-tree module taints kernel. [5.821623] nvidia: module license 'NVIDIA' taints kernel. [5.821993] nvidia: module
Bug#947315: ITS: funcoeszz
Package: funcoeszz Version: 15.5-1.1 Severity: important Dear Maintainer, Hereby I declare my intentention to salvage the funcoeszz package as described in the developer's reference and also https://wiki.debian.org/PackageSalvaging by uploading a new upstream version and fixing all bugs. After checking the qualification criteria, I am filing this Intent To Salvage (ITS) bug, following the process outlined in: https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging For reference: > After the 21 days delay, if no answer has been sent to the bug [..] … I make this the 14th January 2020. Greetings,
Bug#915194: gcc-8-cross: mips64el-linux-gnuabi64-gcc-8 munmap_chunk(): invalid pointer when build for o32
YunQiang Su 于2018年12月2日周日 上午1:46写道：
>
> On Sun, 2 Dec 2018 00:30:21 +0800 YunQiang Su wrote:
> > Package: src:gcc-8-cross
> > Version: 23
> >
> > These bellow cmd will show:
> > munmap_chunk(): invalid pointer
> > Aborted
> >
I know what's the problem of this patch:
prefix_info.name = (const char *) prefixed_name;
this line change the address of prefix_info.name on fly,
and when the compile process finish, it will try to be free,
and then this problem happens.
I have no clear idea about how to fix it yet.
>
> And an new discovery: i386 version don't have problem...,
> aka only amd64 version has problem.
>
> > $ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -c -mabi=32
> > -xc -
> > $ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -B
> > /non_exists/ -c -mabi=32 -xc -
> > $ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -B
> > /usr/share -c -mabi=32 -xc -
> > $ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -EB -c
> > -mabi=32 -xc -
> >
> >
> > Some other example that work well
> >
> > $ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -c -mabi=n32
> > -xc -
> > $ # works well, use abi=n32
> >
> > $ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -c -mabi=64
> > -xc -
> > $ # works well, use abi=64
> >
> > $ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -B
> > /usr/mips64el-linux-gnuabi64/bin/ -c -mabi=32 -xc -
> > $ # works well, add -B option
> >
> > $ echo "int a(){ return 1; }" | mips64el-linux-gnuabi64-gcc-8 -B
> > /usr/bin/ -c -mabi=32 -xc -
> > $ # works well, add -B option
> >
> > $ echo "int a(){ return 1; }" | mips64-linux-gnuabi64-gcc-8 -c -mabi=32 -xc
> > -
> > $ # works well, add use mips64 aka eb
> >
> > $ echo "int a(){ return 1; }" | mips64-linux-gnuabi64-gcc-8 -EL -c
> > -mabi=32 -xc -
> > $ # works well, add use mips64 aka eb, and with -EL option.
> >
> > Is it an upstream bug?
> >
> > --
> > YunQiang Su
> >
> >
--
YunQiang Su
Bug#947314: RM: python-tunigo -- ROM; Tunigo service no longer operational
Package: ftp.debian.org Severity: normal Hi! As the uploader of python-tunigo, I request the removal of the package from Debian. The Tunigo API service that this library wraps is no longer operational. Thanks, -- Stein Magnus Jodal jo...@debian.org signature.asc Description: PGP signature
Bug#939095: RFS: axtls/2.1.5+ds-1 [ITP] -- Highly configurable client/server TLSv1.2 library
Adam Borowski 于2019年12月24日周二 上午6:42写道：
>
> On Mon, Dec 23, 2019 at 03:17:36PM +0800, Yangfl wrote:
> > Hmm clearly lua-bitop is lack of support for lua5.3. Have to remove
> > the lua test part and hope everything will be fine...
>
> It builds and passes tests now, but trying to run the example server fails
> with:
>
> axhttpd -p 8080
> ERR: Couldn't bind to port 8080
>
> With strace, I see:
>
> socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
> setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> bind(3, {sa_family=AF_INET6, sa_data="\37\220\0\0\0\0\0\0\0\0\0\0\0\0"}, 16)
> = -1 EINVAL (Invalid argument)
>
> or
>
> socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
> setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> bind(3, {sa_family=AF_INET6, sa_data="\37\220|\177\0\0\0\0\0\0\0\0\0\0"}, 16)
> = -1 EINVAL (Invalid argument)
>
> Same with -s, or on two other machines (amd64 and arm64).
>
Works under new patch fixing the call to bind.
Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}
On 24 December 2019 at 09:34, Graham Inggs wrote: | Control: severity -1 serious | | On Mon, 23 Dec 2019 at 22:30, Dirk Eddelbuettel wrote: | > I would be very surprised if these were not self-inflicted by us. I know CRAN | > (much) better than BioC, but both of them are doing extensive self-tests (and | > generally without any arbitrary restrictions, say about timing and versions) | > we may impose. | | This situation reminds me of #877288, where I believe Debian's | autopkgtests detected the problem before upstream. Maybe, maybe not. Here is the BioC build report for iranges and s4vectors: http://bioconductor.org/checkResults/3.10/bioc-LATEST/IRanges/ http://bioconductor.org/checkResults/3.10/bioc-LATEST/S4Vectors/ "All green". To me th likeliest cause is one of synchronization: BioC generally "steps" in full releases dependenting on R releases, that does not map to our rolling scheme. That is, to me, what happened in #877288 too -- R releases and BioC releases out of step. (And I still don't know what the best move would be as thinks could break with either BioC release or devel...) | > I tried a quick test on a Debian testing machine I use for (extensive) | > reverse dependency checks (at the upstream level) but it was incloncusive. | | Hopefully we get an answer from upstream BioConductor soon. Well as shown above there is not bug they see. | > Still a pity that r-base is held back by this. | | This is better than allowing a package that breaks others to migrate | into testing. What if the breakage is in fact self-inflicted? | If there is no progress for some time, Release Team may remove | r-bioc-iranges and r-bioc-s4vectors from testing to allow r-base to | migrate, as in any other transition. I guess we have to wait. I run R via the CRAN-ports-for-Ubuntu or via unstable-on-testing so I have R 3.6.2 on both but it is not fair to our users to withhold it. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#947313: python3-pecan: fails to install
Package: python3-pecan Version: 1.3.3-2 Severity: serious python3-pecan fails to install: Errors were encountered while processing: python3-pecan E: Sub-process /usr/bin/dpkg returned an error code (1) Setting up python3-pecan (1.3.3-2) ... update-alternatives: error: alternative path /usr/bin/python3-pecan doesn't exist dpkg: error processing package python3-pecan (--configure): installed python3-pecan package post-installation script subprocess returned error exit status 2 Errors were encountered while processing: python3-pecan -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#867123: [PATCH] mdoc: Update operating system release numbers
Hi Colin, Colin Watson wrote on Mon, Dec 23, 2019 at 10:37:09PM +: > On Sat, Dec 21, 2019 at 02:51:23PM +0100, Ingo Schwarze wrote: >> Consequently, i just pushed the patch to the upstream groff repository, >> with the following tweaks: >> >> * I included the following versions which appeared to be missing: >> - NetBSD 6.0.6 and 7.2 >> - DragonFly 3.0.2 and 3.2.2 >> >> * I did *not* include the following releases because x.y.0 are not >>included for any other DragonFly releases: DragonFly 3.6.0 and 3.8.0. >>I'm not a DragonFly user and i'm not completely sure what would make >>most sense for that system, so i just stuck to existing practice as >>best i could. > Thanks. I have no complaints with these - I wasn't completely sure what > I was doing and am happy for the corrections. Thanks for checking! > (There was a small typo, which I've fixed on master. It's very easy for > one's eyes to swim when dealing with these macros.) Thanks for correcting that, and sorry for stealing your commit. I somehow overlooked that you have upstream groff commit access, too (which i should have known anyway). Yours, Ingo
Bug#947312: kopanocore: CVE-2019-19907
Source: kopanocore Version: 8.7.0-5 Severity: important Tags: security upstream Control: found -1 8.7.0-3 Hi, The following vulnerability was published for kopanocore. CVE-2019-19907[0]: | HrAddFBBlock in libfreebusy/freebusyutil.cpp in Kopano Groupware Core | before 8.7.7 allows out-of-bounds access, as demonstrated by | mishandling of an array copy during parsing of ICal data. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-19907 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19907 [1] https://stash.kopano.io/projects/KC/repos/kopanocore/commits/4e02b420fff Regards, Salvatore
Bug#947311: graphicsmagick: CVE-2019-19953
Source: graphicsmagick Version: 1.4+really1.3.33+hg16117-1 Severity: important Tags: security upstream Forwarded: https://sourceforge.net/p/graphicsmagick/bugs/617/ Hi, The following vulnerability was published for graphicsmagick. CVE-2019-19953[0]: | In GraphicsMagick 1.4 snapshot-20191208 Q8, there is a heap-based | buffer over-read in the function EncodeImage of coders/pict.c. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-19953 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19953 [1] https://sourceforge.net/p/graphicsmagick/bugs/617/ [2] http://hg.graphicsmagick.org/hg/GraphicsMagick/rev/28f8bacd4bbf Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#947310: mesa: FTBFS on mipsel: Cannot find (any matches for) "usr/lib/*/libvulkan_*.so"
Source: mesa Version: 19.3.1-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) mesa doesn't seem to be building Vulkan drivers on mipsel, but the Architecture field of mesa-vulkan-drivers says it should be: https://buildd.debian.org/status/fetch.php?pkg=mesa=mipsel=19.3.1-2=1576796202=0 > Vulkan drivers: no ... > dh_install -a > dh_install: Cannot find (any matches for) > "usr/share/vulkan/explicit_layer.d/*.json" (tried in ., debian/tmp) > > dh_install: mesa-vulkan-drivers missing files: > usr/share/vulkan/explicit_layer.d/*.json > dh_install: Cannot find (any matches for) "usr/share/vulkan/icd.d/*.json" > (tried in ., debian/tmp) > > dh_install: mesa-vulkan-drivers missing files: usr/share/vulkan/icd.d/*.json > dh_install: Cannot find (any matches for) "usr/lib/*/libvulkan_*.so" (tried > in ., debian/tmp) > > dh_install: mesa-vulkan-drivers missing files: usr/lib/*/libvulkan_*.so > dh_install: Cannot find (any matches for) > "usr/lib/*/libVkLayer_MESA_overlay.so" (tried in ., debian/tmp) > > dh_install: mesa-vulkan-drivers missing files: > usr/lib/*/libVkLayer_MESA_overlay.so > dh_install: missing files, aborting This might be because mipsel is present in the list of architectures where LLVM is enabled (confflags_GALLIUM += -Dllvm=true etc.), and is present in the list of architectures where the Vulkan loader is enabled (confflags_VULKAN += -Dvulkan-overlay-layer=true), but is absent from the list of architectures where VULKAN_DRIVERS += amd, despite that list being documented as "only build on the subset of arches where we have LLVM enabled and where the Vulkan loader is built". smcv
Bug#946268: Please add support for custom entries
On Ma, 17 dec 19, 19:49:37, andreimpope...@gmail.com wrote:
>
> Additionally, if the variable is always set the checks must be changed
> slightly, otherwise the script would always error out.
If I'm being a little bit paranoid about checks on the file I figured I
might as well issue a message in case the file is a symlink.
Updated patch attached.
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
From 3179b3155004a455f3ceb1e5a67e7d5b4d359f60 Mon Sep 17 00:00:00 2001
From: Andrei POPESCU
Date: Sun, 8 Dec 2019 11:53:36 +0200
Subject: [PATCH] Add option to append one or more custom entries from an
external file
This patch adds a new option U_BOOT_CUSTOM_ENTRIES to specify an
external file to be appended to extlinux.conf.
default:
Add the new option commented out, with the default value.
u-boot-update:
Do some basic checks on the file (exists, regular file, readable,
non-zero length).
Issue an info message in case the file is a symlink.
Issue a warning in case the file is not owned by root, but don't
error out (the sysadmin may have good reasons for that).
u-boot-update.8:
Document the new option in the manpage, including some safety/security
warnings.
---
default | 1 +
u-boot-update | 36
u-boot-update.8 | 2 ++
3 files changed, 39 insertions(+)
diff --git a/default b/default
index 4389a87..7e6804d 100644
--- a/default
+++ b/default
@@ -11,4 +11,5 @@
#U_BOOT_TIMEOUT="50"
#U_BOOT_FDT=""
#U_BOOT_FDT_DIR="/usr/lib/linux-image-"
+#U_BOOT_CUSTOM_ENTRIES="/etc/default/u-boot-custom"
diff --git a/u-boot-update b/u-boot-update
index 2bf151b..dddb923 100755
--- a/u-boot-update
+++ b/u-boot-update
@@ -82,6 +82,7 @@ U_BOOT_TIMEOUT="${U_BOOT_TIMEOUT:-50}"
U_BOOT_MENU_LABEL="Debian GNU/Linux kernel"
U_BOOT_PARAMETERS="${U_BOOT_PARAMETERS:-ro quiet}"
U_BOOT_FDT_DIR="${U_BOOT_FDT_DIR:-/usr/lib/linux-image-}"
+U_BOOT_CUSTOM_ENTRIES="${U_BOOT_CUSTOM:-/etc/default/u-boot-custom}"
# Find parameter for root from fstab
if [ -z "${U_BOOT_ROOT}" ]
@@ -216,5 +217,40 @@ done
_NUMBER=""
+# Append custom entries if any
+if [ -f "${U_BOOT_CUSTOM_ENTRIES}" ]
+then
+if [ ! -r "${U_BOOT_CUSTOM_ENTRIES}" ]
+then
+echo 'E: The file '"${U_BOOT_CUSTOM_ENTRIES}"' is unreadable'
+exit 1
+fi
+
+if [ ! -s "${U_BOOT_CUSTOM_ENTRIES}" ]
+then
+echo 'E: The file '"${U_BOOT_CUSTOM_ENTRIES}"' is empty'
+exit 1
+fi
+
+if [ ! -O "${U_BOOT_CUSTOM_ENTRIES}" ]
+then
+echo 'W: The file '"${U_BOOT_CUSTOM_ENTRIES}"' is NOT owned by root'
+fi
+
+if [ -h "${U_BOOT_CUSTOM_ENTRIES}" ]
+then
+_SYMLINK_TARGET=$(readlink -f "${U_BOOT_CUSTOM_ENTRIES}")
+echo 'I: The file '"${U_BOOT_CUSTOM_ENTRIES}"' is a symbolic link pointing to '"${_SYMLINK_TARGET}"
+fi
+
+echo 'P: Appending custom entries from '"${U_BOOT_CUSTOM_ENTRIES}"'...'
+
+# Writing custom entries
+_CONFIG="${_CONFIG}
+
+$(< "${U_BOOT_CUSTOM_ENTRIES}")
+"
+fi
+
Update "${_U_BOOT_DIRECTORY}/extlinux.conf" "${_CONFIG}"
diff --git a/u-boot-update.8 b/u-boot-update.8
index 3397bc8..7e88000 100644
--- a/u-boot-update.8
+++ b/u-boot-update.8
@@ -26,6 +26,8 @@ This variable specifies additional boot parameters that are appended to each ker
This variable specifies the root partition. It is automatically extracted from /etc/fstab. U\-BOOT supports both devices and UUIDs.
.IP "U_BOOT_TIMEOUT=""\fB50\fR""" 4
This variable specifies the time that U\-BOOT should wait for user input during boot. Values are in decisecond greater than 0 (e.g. '10' for a 1 second timeout), 0 specifies to wait forever. The default is 50.
+.IP "U_BOOT_CUSTOM_ENTRIES=""/path/to/file""" 4
+This variable specifies the name of a file containing one or more custom entries. The file is appended \fBas is\fR, without any checks for validity or safety. For security reasons the file should not be writable to untrusted users as it can be used to gain root access to the system (e.g. by adding a boot entry with "init=/bin/sh" as kernel parameter). u\-boot\-update will issue a warning if the file is not owned by root. The default is '/etc/default/u-boot-custom'.
.SH FILES
/etc/default/u-boot
--
2.20.1
signature.asc
Description: PGP signature
Bug#947282: yapps2: diff for NMU version 2.2.1-3.1
Hello Colin, > Package: yapps2 > Version: 2.2.1-3 > Severity: normal > Tags: patch pending > > Dear maintainer, > > I've prepared an NMU for yapps2 (versioned as 2.2.1-3.1) and uploaded it > to DELAYED/10. Please feel free to tell me if I should delay it longer. > > Regards, > Thanks for taking care of this, I'm swamped with other work. Feel free to re-submit directly, no need for DELAYED as far as I am concerned. -- -- Matthias Urlichs signature.asc Description: OpenPGP digital signature
Bug#946655: dh_perl: why is ${perl:Depends} substituted as perl:any for programs only?
Niels Thykier:
> Helmut Grohne:
>> Hi Niko,
>>
>> On Sun, Dec 15, 2019 at 08:34:47PM +0200, Niko Tyni wrote:
>>> I don't understand. AFAICS if the interpreter needing the modules is
>>> /usr/bin/perl, the perl:any dependency will pull in compatible standard
>>> library extension modules: the perl -> perl-base dependency guarantees
>>> perl will be the same arch as /usr/bin/perl, and the perl -> libperl5.30
>>> dependency pulls in the modules for that architecture.
>>>
>>> If it's an embedded interpreter, a compatible set of those is already
>>> shipped with the interpreter (in libperl5.30).
>>>
>>> So where's the problem here?
>>
>> There is no problem. Thank you for the explanation.
>>
>> Does that mean we can move forward with using perl:any for modules?
>>
>
> Hi,
>
> If you are in agreement over this, then I am happy to implement the change.
>
>> I think the check in dh_perl line 142 should be changed from
>>
>> perlarch .= ':any' if $deps == PROGRAM and not $dh{V_FLAG_SET};
>>
>> to
>>
>> perlarch .= ':any' if $deps & (PROGRAM|PM_MODULE) != 0 and not
>> $dh{V_FLAG_SET};
>>
>> Helmut
>>
>
> Wouldn't that be:
>
> perlarch .= ':any' if ($deps & (~(PROGRAM|PM_MODULE))) == $deps \
> and not $dh{V_FLAG_SET};
>
>
No, that was wrong too.
Any way, the following question stands:
> If $deps contains any of XS_MODULE or ARCHDEP_MODULE, then I presume we
> should use "perl" rather than "perl:any" - even if there is a perl
> script/perl module.
>
> Thanks,
> ~Niels
>
When answered, I get to play with bit patterns until I remember the
correct rune.
Thanks,
~Niels
Bug#946655: dh_perl: why is ${perl:Depends} substituted as perl:any for programs only?
Helmut Grohne:
> Hi Niko,
>
> On Sun, Dec 15, 2019 at 08:34:47PM +0200, Niko Tyni wrote:
>> I don't understand. AFAICS if the interpreter needing the modules is
>> /usr/bin/perl, the perl:any dependency will pull in compatible standard
>> library extension modules: the perl -> perl-base dependency guarantees
>> perl will be the same arch as /usr/bin/perl, and the perl -> libperl5.30
>> dependency pulls in the modules for that architecture.
>>
>> If it's an embedded interpreter, a compatible set of those is already
>> shipped with the interpreter (in libperl5.30).
>>
>> So where's the problem here?
>
> There is no problem. Thank you for the explanation.
>
> Does that mean we can move forward with using perl:any for modules?
>
Hi,
If you are in agreement over this, then I am happy to implement the change.
> I think the check in dh_perl line 142 should be changed from
>
> perlarch .= ':any' if $deps == PROGRAM and not $dh{V_FLAG_SET};
>
> to
>
> perlarch .= ':any' if $deps & (PROGRAM|PM_MODULE) != 0 and not
> $dh{V_FLAG_SET};
>
> Helmut
>
Wouldn't that be:
perlarch .= ':any' if ($deps & (~(PROGRAM|PM_MODULE))) == $deps \
and not $dh{V_FLAG_SET};
If $deps contains any of XS_MODULE or ARCHDEP_MODULE, then I presume we
should use "perl" rather than "perl:any" - even if there is a perl
script/perl module.
Thanks,
~Niels
Bug#947196: "BadMatch" error on X_ShmPutImage when using GLX_ALPHA_SIZE
This patch to openscad works around the problem:
https://salsa.debian.org/knielsen-guest/openscad/commit/7225800b534a36e5ad84c56c274889b8d0edc0ce
It uses Xrender to query visuals returned from glXChooseFBConfig(), and
filter out those with alphaMask=0.
With this patch, all openscad tests are passing with mesa 19.3.1-2.
However, I'm unsure if this is the correct approach? It does not seem right
that querying Xrender would be required just to specify GLX_ALPHA_SIZE to
glXChooseFBConfig(). Maybe there is a simpler fix for openscad, or possibly
this is a bug in mesa that should be fixed?
- Kristian.
commit 7225800b534a36e5ad84c56c274889b8d0edc0ce (HEAD -> newstuffs, salsa/newstuffs)
Author: Kristian Nielsen
Date: Tue Dec 24 11:05:45 2019 +0100
Add a patch to work-around test failures against latest mesa
diff --git a/debian/changelog b/debian/changelog
index 9ca95cd5..7fe6f8ad 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,8 +2,9 @@ openscad (2019.05-4) unstable; urgency=medium
* Make openscad-testrun default to run tests in parallel.
* Limit --parallel build based on available memory (Closes: #945162)
+ * Work-around "BadMatch" error with mesa >= 19.3 (Closes: 947196)
- -- Kristian Nielsen Sat, 07 Dec 2019 11:12:30 +0100
+ -- Kristian Nielsen Tue, 24 Dec 2019 10:29:22 +0100
openscad (2019.05-3) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index b8299716..96ab274e 100644
--- a/debian/control
+++ b/debian/control
@@ -27,6 +27,7 @@ Build-Depends:
# workaround for https://github.com/openscad/openscad/issues/1543
libqt5opengl5-dev,
libglew-dev (>= 1.5.4) | libglew1.6-dev | libglew1.5-dev (>= 1.5.4),
+libxrender-dev,
libgmp-dev | libgmp10-dev | libgmp3-dev,
libmpfr-dev,
python3:any,
diff --git a/debian/patches/Prefer-FBConfig-with-alpha-support-for-GLX-off-screen-con.patch b/debian/patches/Prefer-FBConfig-with-alpha-support-for-GLX-off-screen-con.patch
new file mode 100644
index ..1364dcba
--- /dev/null
+++ b/debian/patches/Prefer-FBConfig-with-alpha-support-for-GLX-off-screen-con.patch
@@ -0,0 +1,84 @@
+From: Kristian Nielsen
+Date: Tue, 24 Dec 2019 10:22:05 +0100
+Subject: Prefer FBConfig with alpha support for GLX off-screen context
+
+This is to work-around a problem seen with mesa >= 19.3 (Debian
+bug#947196). When GLX_ALPHA_SIZE>0 is passed to glXChooseFBConfig(),
+the first configurations returned result in a BadMatch error in
+glXSwapBuffers(). Picking the first returned configuration with
+alphaMask > 0 (as reported by Xrender) avoids the failure.
+---
+ features/glew.prf | 2 +-
+ src/OffscreenContextGLX.cc | 25 ++---
+ 2 files changed, 23 insertions(+), 4 deletions(-)
+
+diff --git a/features/glew.prf b/features/glew.prf
+index d4c83bd..1c3b4c4 100644
+--- a/features/glew.prf
b/features/glew.prf
+@@ -7,7 +7,7 @@ GLEW_DIR = $$(GLEWDIR)
+ QMAKE_LIBDIR += $$GLEW_DIR/lib64
+ }
+
+-unix:LIBS += -lGLEW
++unix:LIBS += -lGLEW -lXrender
+ mingw-cross-env*: {
+{
+ CONFIG += link_pkgconfig
+diff --git a/src/OffscreenContextGLX.cc b/src/OffscreenContextGLX.cc
+index 1f29155..933c4c8 100644
+--- a/src/OffscreenContextGLX.cc
b/src/OffscreenContextGLX.cc
+@@ -43,6 +43,7 @@ OffscreenContext.mm (Mac OSX version)
+
+ #include
+ #include
++#include
+
+ #include
+ #include
+@@ -145,7 +146,25 @@ bool create_glx_dummy_window(OffscreenContext )
+ return false;
+ }
+
+- auto visinfo = glXGetVisualFromFBConfig( dpy, fbconfigs[0] );
++ auto fbconfig = fbconfigs[0];
++ auto visinfo = glXGetVisualFromFBConfig( dpy, fbconfig );
++ // If Xrender is available, use it to prefer an fbconfig with alpha.
++ // This is to work-around a problem seen with mesa >= 19.3, where
++ // the configs without alpha-support cause a BadMatch failure in
++ // glXSwapBuffers() (Debian bug#947196).
++ int event_basep, error_basep;
++ if (XRenderQueryExtension(dpy, _basep, _basep)) {
++ for (int i = 0; i < num_returned; i++) {
++ auto v = glXGetVisualFromFBConfig(dpy, fbconfigs[i]);
++ auto pf = XRenderFindVisualFormat(dpy, v->visual);
++ if (pf && pf->direct.alphaMask > 0) {
++ visinfo = v;
++ fbconfig = fbconfigs[i];
++ break;
++ }
++ }
++ }
++
+ if (visinfo == nullptr) {
+ std::cerr << "glXGetVisualFromFBConfig failed\n";
+ XFree(fbconfigs);
+@@ -183,7 +202,7 @@ bool create_glx_dummy_window(OffscreenContext )
+ // Most programs would call XMapWindow here. But we don't, to keep the window hidden
+ // XMapWindow( dpy, xWin );
+
+- auto context = glXCreateNewContext(dpy, fbconfigs[0], GLX_RGBA_TYPE, nullptr, true);
++ auto context = glXCreateNewContext(dpy, fbconfig, GLX_RGBA_TYPE, nullptr, true);
+ if (context == nullptr) {
+ std::cerr << "glXCreateNewContext failed\n";
+ XDestroyWindow(dpy, xWin);
+@@ -192,7 +211,7 @@ bool create_glx_dummy_window(OffscreenContext )
+ return false;
+ }
+
+- //GLXWindow glxWin = glXCreateWindow(
Bug#930679: Please add overridable tag for not using dh sequencer
On Sat, 14 Dec 2019 22:39:34 -0800 Felix Lechner wrote: > Hi Sam, > > On Tue, Jun 18, 2019 at 4:27 AM Sam Hartman wrote: > > > > Based on that I think we'd like lintian to detect when dh is not used > > and allow maintainers to override the tag if they have an adequate > > justification for not using dh. > > I tentatively added a new tag called 'no-dh-sequencer' to Lintian. I produces false positives on packages with non-trivial rules files that cannot use the catch-all wildcard '%:\n\tdh $@' (because it interferes with other pattern rules). e.g. nvidia-cuda-toolkit .PHONY: binary binary-arch binary-indep build build-arch build-indep clean install binary-arch build build-arch build-indep clean install: dh $@ binary binary-indep: # the documentation packages must be built on amd64 (otherwise some parts are missing) test "$(DEB_HOST_ARCH)" = "amd64" dh $@ Andreas
Bug#947309: imagemagick: CVE-2019-19949
Source: imagemagick Version: 8:6.9.10.23+dfsg-2.1 Severity: important Tags: security upstream Forwarded: https://github.com/ImageMagick/ImageMagick/issues/1561 Hi, The following vulnerability was published for imagemagick. CVE-2019-19949[0]: | In ImageMagick 7.0.8-43 Q16, there is a heap-based buffer over-read in | the function WritePNGImage of coders/png.c, related to | Magick_png_write_raw_profile and LocaleNCompare. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-19949 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19949 [1] https://github.com/ImageMagick/ImageMagick/issues/1561 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#947308: imagemagick: CVE-2019-19948
Source: imagemagick Version: 8:6.9.10.23+dfsg-2.1 Severity: important Tags: security upstream Forwarded: https://github.com/ImageMagick/ImageMagick/issues/1562 Hi, The following vulnerability was published for imagemagick. CVE-2019-19948[0]: | In ImageMagick 7.0.8-43 Q16, there is a heap-based buffer overflow in | the function WriteSGIImage of coders/sgi.c. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-19948 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19948 [1] https://github.com/ImageMagick/ImageMagick/issues/1562 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#947307: ibverbs-providers: obsolete conffiles
Package: ibverbs-providers Version: 27.0-1 Severity: normal adequate reports: ibverbs-providers:amd64: obsolete-conffile /etc/libibverbs.d/nes.driver ibverbs-providers:amd64: obsolete-conffile /etc/libibverbs.d/cxgb3.driver Please remove them using dpkg-maintscript-helper's rm_conffile. Thanks Cheers -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (650, 'unstable-debug'), (650, 'unstable'), (601, 'testing'), (600, 'experimental-debug'), (600, 'buildd-unstable'), (600, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ibverbs-providers:amd64 depends on: ii libc62.29-6 ii libibverbs1 27.0-1 ibverbs-providers:amd64 recommends no packages. ibverbs-providers:amd64 suggests no packages. -- no debconf information -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#947306: waitress: CVE-2019-16785 CVE-2019-16786
Source: waitress Version: 1.3.1-4 Severity: grave Tags: security upstream Hi, The following vulnerabilities were published for waitress, both are fixed in new upstream version 1.4.0. CVE-2019-16785[0]: | Waitress through version 1.3.1 implemented a "MAY" part of the RFC7230 | which states: "Although the line terminator for the start-line and | header fields is the sequence CRLF, a recipient MAY recognize a single | LF as a line terminator and ignore any preceding CR." Unfortunately if | a front-end server does not parse header fields with an LF the same | way as it does those with a CRLF it can lead to the front-end and the | back-end server parsing the same HTTP message in two different ways. | This can lead to a potential for HTTP request smuggling/splitting | whereby Waitress may see two requests while the front-end server only | sees a single HTTP message. This issue is fixed in Waitress 1.4.0. CVE-2019-16786[1]: | Waitress through version 1.3.1 would parse the Transfer-Encoding | header and only look for a single string value, if that value was not | chunked it would fall through and use the Content-Length header | instead. According to the HTTP standard Transfer-Encoding should be a | comma separated list, with the inner-most encoding first, followed by | any further transfer codings, ending with chunked. Requests sent with: | "Transfer-Encoding: gzip, chunked" would incorrectly get ignored, and | the request would use a Content-Length header instead to determine the | body size of the HTTP message. This could allow for Waitress to treat | a single request as multiple requests in the case of HTTP pipelining. | This issue is fixed in Waitress 1.4.0. 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-2019-16785 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16785 [1] https://security-tracker.debian.org/tracker/CVE-2019-16786 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16786 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#947305: Please replace obsolete install and remove command from modprobe.d files
Package: nvidia-kernel-support Version: 430.64-4 Severity: normal /etc/nvidia/current/nvidia-modprobe.conf contains the lines below with 'install' or 'remove' commands in modprobe.d files. According to kmod developers, these are long obsolete and should be replaced by 'softdep' commands. I'd be happy to offer a patch if the VCS links worked. install nvidia modprobe -i nvidia-current $CMDLINE_OPTS install nvidia-modeset modprobe nvidia ; modprobe -i nvidia-current-modeset $CMDLINE_OPTS install nvidia-drm modprobe nvidia-modeset ; modprobe -i nvidia-current-drm $CMDLINE_OPTS install nvidia-uvm modprobe nvidia ; modprobe -i nvidia-current-uvm $CMDLINE_OPTS remove nvidia modprobe -r -i nvidia-drm nvidia-modeset nvidia-uvm nvidia remove nvidia-modeset modprobe -r -i nvidia-drm nvidia-modeset -Topi
Bug#934264: Please update (4.6.2?) and provide/switch to python3
On Tue, Dec 24, 2019 at 09:49:18AM +0200, Adrian Bunk wrote: > > Works for me (with test failures later), but I am using plain chroot. > > Problems related to running graphical tests are not something I would > care too much about right now, important would be that the package > builds and works. > > After disabling the tests and dh_numpy -> dh_numpy3 in debian/rules the > package builds for me. > > Trying to install the resulting package fails with: > E: Package 'python3-wxgtk3.0' has no installation candidate > E: Package 'python3-envisage' has no installation candidate > > python3-wxgtk4.0 exists (not sure whether it also works with mayavi2). I pushed all this to Git. > python-envisage has not yet been converted to Python3 and seems to be > required: > $ mayavi2 > Traceback (most recent call last): > File "/usr/bin/mayavi2", line 464, in > from mayavi.plugins.app import Mayavi, setup_logger > File "/usr/lib/python3/dist-packages/mayavi/plugins/app.py", line 19, in > > from .mayavi_workbench_application import MayaviWorkbenchApplication > File > "/usr/lib/python3/dist-packages/mayavi/plugins/mayavi_workbench_application.py", > line 13, in > from envisage.ui.workbench.api import WorkbenchApplication > ModuleNotFoundError: No module named 'envisage' That's recorded as TODO item in d/changelog now. Thanks for all your hints, Andreas. -- http://fam-tille.de
Bug#947293: libkate: autopkgtest failures due to libkate-tools removal
Control: forcemerge 946632 -1
On 2019-12-23 21:31:26, Steve Langasek wrote:
> Package: libkate
> Version: 0.4.1-10
> Severity: serious
> Tags: patch
> Justification: autopkgtest regression
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu focal ubuntu-patch
>
> Dear maintainers,
>
> With the removal of libkate-tools in libkate 0.4.1-10, the libkate
> autopkgtest consistently fails, because all of the commands it previously
> attempted to run were in the libkate-tools package:
>
> [...]
> autopkgtest [12:55:24]: test test-cmd-tools: - - - - - - - - - - stderr - -
> - - - - - - - -
> /tmp/autopkgtest-lxc.c5qiodhi/downtmp/build.Liw/src/debian/tests/test-cmd-tools:
> 25: kateenc: not found
> /tmp/autopkgtest-lxc.c5qiodhi/downtmp/build.Liw/src/debian/tests/test-cmd-tools:
> 31: katalyzer: not found
> /tmp/autopkgtest-lxc.c5qiodhi/downtmp/build.Liw/src/debian/tests/test-cmd-tools:
> 37: katedec: not found
> /tmp/autopkgtest-lxc.c5qiodhi/downtmp/build.Liw/src/debian/tests/test-cmd-tools:
> 40: errorunable to run katedec: not found
> [...]
>
>
> (https://ci.debian.net/data/autopkgtest/unstable/amd64/libk/libkate/3520793/log.gz)
That's #946632.
>
> I think the autopkgtest should simply be dropped, since there is nothing
> left for it to do at present. Please see the attached patch.
>
> Cheers,
> --
> Steve Langasek Give me a lever long enough and a Free OS
> Debian Developer to set it on, and I can move the world.
> Ubuntu Developer https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
> diff -Nru libkate-0.4.1/debian/tests/control
> libkate-0.4.1/debian/tests/control
> --- libkate-0.4.1/debian/tests/control2019-11-26 16:03:42.0
> -0600
> +++ libkate-0.4.1/debian/tests/control1969-12-31 18:00:00.0
> -0600
> @@ -1,2 +0,0 @@
> -Depends: @
> -Tests: test-cmd-tools
> diff -Nru libkate-0.4.1/debian/tests/test-cmd-tools
> libkate-0.4.1/debian/tests/test-cmd-tools
> --- libkate-0.4.1/debian/tests/test-cmd-tools 2019-11-26 16:03:42.0
> -0600
> +++ libkate-0.4.1/debian/tests/test-cmd-tools 1969-12-31 18:00:00.0
> -0600
> @@ -1,49 +0,0 @@
> -#!/bin/sh
> -#
> -# Test the kate command line tools to ensure they can run without
> -# returning an error.
> -
> -set -e
> -
> -retval=0
> -
> -success() { echo "success:" "$@"; }
> -error() { echo "error:" "$@"; retval=1; }
> -
> -cat > input.srt < -1
> -00:00:08,000 --> 00:00:14,000
> -This is a simple subtext block
> -that will be encoded into an ogg file.
> -
> -2
> -00:00:15,000 --> 00:00:16,000
> -This is the second subtext block.
> -
> -EOF
> -
> -if kateenc -t srt -l cy -c SUB -o output.ogg input.srt ; then
> -success "kateenc could encode an SRT file to OGG"
> -else
> -error "unable to run kateenc"
> -fi
> -
> -if katalyzer output.ogg ; then
> -success "running katalyzer worked"
> -else
> -error "unable to run katalyser"
> -fi
> -
> -if katedec output.ogg ; then
> -success "running katedec worked"
> -else
> -error"unable to run katedec"
> -fi
> -
> -if KateDJ --version ; then
> -success "running KateDJ worked"
> -else
> -error "unable to run KateDJ"
> -fi
> -
> -exit $retval
--
Sebastian Ramacher
signature.asc
Description: PGP signature
Bug#937449: severity of 937449 is normal, retitle 937449 to RM: RoQA: pygopherd, python2, not in testing ...
So the advise in all of the removal bugs is wrong? """ If the package has no reverse dependencies, confirm that the package can be removed, reassign this issue to ftp.debian.org, make sure that the bug priority is set to normal and retitle the issue to "RM: PKG -- removal triggered by the Python2 removal". """ Ok, I will only clone issues into FTP.debian.org bug tracker from now on. On Tue, 24 Dec 2019, 06:32 Sandro Tosi, wrote: > On Mon, 23 Dec 2019 09:30:55 + Dimitri John Ledkov > wrote: > > severity 937449 normal > > retitle 937449 RM: RoQA: pygopherd, python2, not in testing > > found 937449 > > reassign 937449 ftp.debian.org > > thanks > > > > > > > > Dimitri, please do not reassign py2removal bugs to ftp.d.o for > removal, but file new ones, otherwise we're just removing a valid bug > from the source package view for no good reason. thanks >
Bug#947168: duplicate-short-description doesn't deal well with Haskell packages
Hi Felix,
Il 23/12/19 10:58, Felix Lechner ha scritto:
> Hi s3v,
>
> This message only deals with your supplemental question about geany-plugins.
>
> On Sun, Dec 22, 2019 at 3:21 AM s3v wrote:
>>
>> duplicate-short-description was not emitted for geany-plugins despite there
>> are
>> two binary packages with the same short description.
>
> That tag is emitted locally:
>
> $ dget
> https://deb.debian.org/debian/pool/main/g/geany-plugins/geany-plugins_1.36+dfsg-1.dsc
> $ frontend/lintian geany-plugins_1.36+dfsg-1.dsc
> I: geany-plugins source: debian-watch-uses-insecure-uri
> http://plugins.geany.org/geany-plugins/geany-plugins-(.*).tar.gz
> I: geany-plugins source: duplicate-short-description
> geany-plugin-git-changebar geany-plugin-keyrecord
> I: geany-plugins source: out-of-date-standards-version 4.1.2 (released
> 2017-11-30) (current is 4.4.1)
> I: geany-plugins source: public-upstream-key-not-minimal
> upstream/signing-key.asc has 125 extra signature(s) for keyid
> B507ACD04BA283C9
> I: geany-plugins source: public-upstream-key-not-minimal
> upstream/signing-key.asc has 16 extra signature(s) for keyid
> FBD5225B588752A1
> I: geany-plugins source: testsuite-autopkgtest-missing
> I: geany-plugins source: unused-file-paragraph-in-dep5-copyright
> paragraph at line 80
> I: geany-plugins source: unused-override
> file-contains-fixme-placeholder debian/control:124 FIXME
> I: geany-plugins source: wildcard-matches-nothing-in-dep5-copyright
> geanylatex/* (paragraph at line 75)
> I: geany-plugins source: wildcard-matches-nothing-in-dep5-copyright
> geanylatex/src/geanylatex.c (paragraph at line 80)
> P: geany-plugins source: insecure-copyright-format-uri
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> P: geany-plugins source: package-uses-old-debhelper-compat-version 9
> P: geany-plugins source: rules-requires-root-missing
>
>> I don't see geany-plugins in
>> https://lintian.debian.org/tags/duplicate-short-description.html
>
> The web page states at the top that not all occurrences were shown.
> Perhaps that message could be clearer:
>
> * only 1024 instances are listed on this page.
Ouch!
I read the message box on the top of the web page but I thought the
alphabetically ordered list was truncated to the first (but complete) 1024
items.
My bad :|
Thank you for explanation and for your time.
>
>> Could I open new bug report?
>
> In general, it is probably better to open a separate report. The bug
> number issue is not something you or I can do anything about; perhaps
> they can encode it in base64 to make it shorter. Also, bugs regularly
> are no bugs at all, so that is not offensive. For complex secondary
> issues, we will duplicate and retitle your report. Either way is fine.
I will do :)
>> duplicate-short-description tag has been emitted for a lot of Haskell
>> packages
>> but short descriptions seem to be different.
>
> Lintian checks d/control in the source package. All of the entries look like:
>
> Description: ${haskell:ShortDescription}${haskell:ShortBlurb}
> ${haskell:LongDescription}
> .
> ${haskell:Blurb}
>
>> I admit I've not checked all Haskell packages but all short descriptions in
>> control file are in the form
>>
>> Description: ${haskell:ShortDescription}${haskell:ShortBlurb}
>>
>> maybe ${haskell:ShortBlurb} is not properly handled?
>
> You are right. The variable is not handled at all. The current Lintian
> check does not work for Haskell packages.
>
> Checking the source packages, as we currently do, has the advantage
> that no built packages need be present. Lintian can run separately on
> *.dsc, *.deb and *.changes, and we prefer to run on source packages
> whenever possible. That does not work when variables are used, and
> should perhaps be changed for all of Lintian.
>
> A hybrid option would be to check the installation packages second, if
> present, and suppress any tags not actually warranted.
>
> This is a great bug and will require some thinking.
>
I think most immediate solution could be substituting Haskell variables by
Lintian itself before emitting tags.
${haskell:ShortDescription} and ${haskell:LongDescription} are already in
d/control, ${haskell:ShortBlurb} and ${haskell:Blurb} are always the same.
A most general solution would be preferable, I know. But, from my experience of
translator in DDTP, Haskell packages are only ones using variables in their
descriptions.
I'm able to open new bug report if other variables will be encountered or
Haskell packages change their variable values.
duplicate-short-description is a "wishlist" tag and I think Lintian's Team
efforts may be focused elsewhere if handling variables feature is too hard to be
implemented.
Please note that Debian Policy have not suggestions for variables in package
descriptions, so those variables would be in any form or place.
My 2 cents :)
Kind regards and thanks again for your great work on Debian packages.
Bug#946082: should depend on shiboken2
control: severity -1 serious control: tags -1 patch pending NMU ongoing G. On Tue, 03 Dec 2019 20:41:34 +0100 Tommaso Colombo wrote: > Package: libshiboken2-dev > Version: 5.13.2-2 > Severity: important > > Since PySide 5.13, the CMake files shipped in libshiboken2-dev have a > dependency on the /usr/bin/shiboken2 executable. If the shiboken2 package is > not installed, find_package(Shiboken2) fails in CMake. > > Installing shiboken2 fixes the issue. > > This breaks the build of packages which build-depend on libshiboken2-dev. For > example: > https://buildd.debian.org/status/fetch.php?pkg=freecad=amd64=0.18.4%2Bdfsg1-1%2Bb1=1574113872=0 > > How to reproduce: > > $ cat > CMakeFiles.txt > find_package(Shiboken2) > ^D > > $ cmake -Wno-dev . > -- The C compiler identification is GNU 9.2.1 > -- The CXX compiler identification is GNU 9.2.1 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Shiboken2Config: Using default python: .cpython-38-x86_64-linux-gnu > CMake Error at /usr/lib/x86_64-linux- > gnu/cmake/Shiboken2-5.13.2/Shiboken2Targets.cmake:75 (message): > The imported target "Shiboken2::shiboken2" references the file > > "/usr/bin/shiboken2" > > but this file does not exist. Possible reasons include: > > * The file was deleted, renamed, or moved to another location. > > * An install or uninstall procedure did not complete successfully. > > * The installation package was faulty and contained > > "/usr/lib/x86_64-linux-gnu/cmake/Shiboken2-5.13.2/Shiboken2Targets.cmake" > > but not all the files it references. > > Call Stack (most recent call first): > /usr/lib/x86_64-linux- > gnu/cmake/Shiboken2-5.13.2/Shiboken2Config.cpython-38-x86_64-linux-gnu.cmake:40 > (include) > /usr/lib/x86_64-linux-gnu/cmake/Shiboken2-5.13.2/Shiboken2Config.cmake:5 > (include)
Bug#944424: cairo-dock-plug-ins: libetpan 1.9.4 uses now pkg-config
Hi, On Sat, Nov 09, 2019 at 09:30:07PM +0100, Ricardo Mones wrote: > I've just uploaded the new version to experimental, so you can test > building with it. > > In a month or so will raise the severity of this bug when uploading to > unstable. Please, let me know if you need more time to solve this. The version of libetpan currently in experimental will be uploaded to unstable on 1st week of 2020, unless somebody objects to. regards, -- Ricardo Mones ~ The world will end in 5 minutes. Please log out.Unknown signature.asc Description: PGP signature
