Bug#929848: How is the packaging of pplpy going?
Hi, Le 18/07/2019 à 21:55, Tobias Hansen a écrit : > On 7/18/19 3:17 PM, Julien Puydt wrote: >> Hi, >> >> Le 18/07/2019 à 20:12, Tobias Hansen a écrit : >>> I pushed it now to https://salsa.debian.org/science-team/pplpy/ >>> >>> Feel free to work on / upload it. >> Excellent! >> >> I worked on it a little. >> >> But I don't understand the lines in d/rules where you put "export >> whatever=whatever" as dependencies... does it work? >> >> Cheers, >> >> JP > > Great, thanks! That export thing is to prevent sphinx accessing the internet, > from > > https://wiki.debian.org/Python/LibraryStyleGuide#Sphinx_documentation > I didn't know it was possible to do exports like this, but indeed: https://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html#Target_002dspecific I worked on the package some more ; I think it's ready : it builds and autopkgtest is happy... You might still want to have a look first. JP
Bug#932424: [Pkg-utopia-maintainers] Bug#932424: network-manager-gnome: No more translation
Am 19.07.19 um 06:55 schrieb Arnaud Meyer: > Package: network-manager-gnome > Version: 1.8.22-2 > Severity: important > Tags: l10n > > Dear Maintainer, > > Since latest 1.8.22 release in testing, the NM applet for GNOME (used > here on MATE) doesn't show translated text anymore. All drop-down menus > and configuration windows are shown in English on my French locale > system. Hm, probably a result of the switch from intltool to gettext in 1.8.22. https://gitlab.gnome.org/GNOME/network-manager-applet/commit/b3c89c31f8f0ee2cc7ae3e094938846813345d57 Will investigate. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#932328: logrotate.timer "breaks" activity report of /etc/cron.daily/exim4-base
On 7/19/19 7:29 AM, Sven Hartge wrote:
On 18.07.19 20:01, Sven Hartge wrote:
On 17.07.19 20:46, Sven Hartge wrote:
Possible solution (untested): Also create a exim4-base.timer and .service and
create a Before= dependency on logrotate.service.
I've whipped up a little Proof-of-Concept to test this, available also
at https://salsa.debian.org/hartge-guest/exim4/tree/systemd-timer
I'm testing this right now on two of my systems to see how this behaves,
especially the Before=logrotate.{service,timer} ordering.
Yes, my test was successful, by ordering the exim4-base.service
Before=logrotate.service, the latter only starts after the first has
completed.
Grüße,
Sven.
This morning I installed the .timer and .service files manually on 3
machines, and ran systemctl enable exim4-base.timer and systemctl start
exim4-base.timer. One of these machines is my hoe mail server (+- 100
mails/day), the other 2 are clients that usually only mail me a daily
report.
With kind regards, Erik Laan,
Bug#932421: systemd : Depends: libip4tc0 (>= 1.6.0+snapshot20161117) but it is not going to be installed
reassign 932421 release.debian.org severity 932421 normal retitle 932421 nmu: systemd_242-2 user release.debian@packages.debian.org usertag 932421 + binnmu thanks Am 19.07.19 um 04:43 schrieb 積丹尼 Dan Jacobson: > Package: systemd > Version: 242-2 > Severity: minor > > # aptitude search ~o > i libip4tc0 - netfilter libip4tc library > # aptitude purge libip4tc0 > ... > The following packages have unmet dependencies: > systemd : Depends: libip4tc0 (>= 1.6.0+snapshot20161117) but it is not going > to be installed > > You are depending on a package that doesn't exist. No matter in sid or > in experimental. nmu systemd_242-2 . ANY . experimental . -m "rebuild against libip4tc2" -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#932328: logrotate.timer "breaks" activity report of /etc/cron.daily/exim4-base
On 18.07.19 20:01, Sven Hartge wrote:
> On 17.07.19 20:46, Sven Hartge wrote:
>
>> Possible solution (untested): Also create a exim4-base.timer and .service and
>> create a Before= dependency on logrotate.service.
>
> I've whipped up a little Proof-of-Concept to test this, available also
> at https://salsa.debian.org/hartge-guest/exim4/tree/systemd-timer
>
> I'm testing this right now on two of my systems to see how this behaves,
> especially the Before=logrotate.{service,timer} ordering.
Yes, my test was successful, by ordering the exim4-base.service
Before=logrotate.service, the latter only starts after the first has
completed.
Grüße,
Sven.
signature.asc
Description: OpenPGP digital signature
Bug#932367: sagemath: Sage does not start because of a missing symbol in GAP wrapper
Hello, thanks for the report. For (fresh) testing/sid, sagemath must be rebuilt against the new GAP version 4r10p2 . Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#931106:
Bug#932423: flameshot: copy function fails and stalls
Package: flameshot Version: 0.6.0-11 Severity: normal mate-desktop on debian buster here flameshot starts but stalls after drawing a selection on the screen and then choosing 'copy' . -- the 'save' and many of the draw functions work, but 'copy' for some reason causes a stall. (the mouse cursor can still be moved, but then nothing is selectable with mouse-click. So I cannot choose 'save' or even hit 'Escape' to get out of the selection mode of flameshot.) when ran from the terminal box, " flameshot QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::setRenderHint: Painter must be active to set rendering hints QPainter::setCompositionMode: Painter not active QPainter::translate: Painter not active QPainter::setPen: Painter not active QPainter::setBrush: Painter not active QPainter::setBrush: Painter not active Killed " the user needs to go to another terminal (ctl-alt-f1) and do kill -9 _flameshot_pid_ , otherwise nothing happens. The other function buttons are not selectable after choosing the 'copy' function.
Bug#932422: User does as instructed, and "i" becomes "iB"
Package: aptitude
Version: 0.8.11-7
User does as instructed, and "i" becomes "iB"!
# aptitude search ~U
i gdal-bin - Geospatial Data Abstraction Library - Utility programs
# aptitude install gdal-bin
The following NEW packages will be installed:
libgdal26{ab} (D: libogdi4.0) (gdal-bin D: libgdal26) libgeotiff5{a} (D:
libgdal26) (gdal-bin D: libgdal26 D: libgeotiff5)
The following packages will be upgraded:
gdal-bin
The following actions will resolve these dependencies:
...
Keep the following packages at their current version:
1) libgdal26 [Not Installed]
Upgrade the following packages:
2) gdal-bin [2.4.1~rc1+dfsg-1~exp1 (now) -> 2.4.2+dfsg-1 (unstable)]
Accept this solution? [Y/n/q/?]
The following packages will be upgraded:
gdal-bin
# aptitude search ~U
iB gdal-bin - Geospatial Data Abstraction Library - Utility programs
Bug#932421: systemd : Depends: libip4tc0 (>= 1.6.0+snapshot20161117) but it is not going to be installed
Package: systemd Version: 242-2 Severity: minor # aptitude search ~o i libip4tc0 - netfilter libip4tc library # aptitude purge libip4tc0 ... The following packages have unmet dependencies: systemd : Depends: libip4tc0 (>= 1.6.0+snapshot20161117) but it is not going to be installed You are depending on a package that doesn't exist. No matter in sid or in experimental.
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Hi Hilmar, I forgot to mention one thing. The version of luaotfload was 2.98 (almost the same as your 2.97). What I saw may be the same as what you told. I tend to agree with the upstream developer as he also consideres this issue as an open bug at https://github.com/u-fischer/luaotfload/issues/49 Anyway 1.8 GB is much better (for Japanese) than 6GB. Ryutaroh From: Ryutaroh Matsumoto Subject: Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts Date: Fri, 19 Jul 2019 10:39:30 +0900 (JST) > Hi Hilmar, > > Thank you for your response. > I have checked this issue under TeXLive 2019 as of July 18 > (installed by "install-tl") under ubuntu 19.04 > (not debian/ubuntu packages) > > The memory consumption of the latex file included in this > bug report was "only" 1.8 GB after rm -rf ~/.texlive2019. > Noto CJK fonts versions are those of ubuntu 19.04 > (not the latest ones). > It was 6 GB when I filed this report. > Maybe 32-bit Linux can now handle the Noto CJK fonts. > > At least we can say significant improvement is in the upstream, > though 1.8 GB seems a bit larger than necessary... > > I again compiled the same latex file by xelatex, > but the processing finished immediately and > I could not see the memory consumption by "top"... > > Ryutaroh > > > From: =?UTF-8?Q?Hilmar_Preu=c3=9fe?= > Subject: Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto > CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto > CJK fonts > Date: Thu, 18 Jul 2019 16:24:39 +0200 > >> On 18.07.19 13:39, Ryutaroh Matsumoto wrote: >> >> Hi Ryutaroh, >> >>> I believe that the problem is spotted and fixed at >>> https://github.com/u-fischer/luaotfload/issues/55 >>> >>> The above seems to be uploaded to ctan on July 15. >>> Maybe the next release of texlive-luatex package will close >>> this issue without special effort. >>> >> >> 2019-05-18 luaotfload v2.97 >> * fix issue #47 >> * fix whatsits interfering with letterspacing (issue #53) >> * fix luaotfload-tool switches version and find not working >> correctly (PR#59) >> * fix luaotfload-tool support of ttc fonts (PR#58) >> * sync with context files from 2019-05-18 (improves handling of >> large fonts, see e.g. issue #55 and PR#58) >> >> So, I'd expect that v2.97 solves the problem. This version however is in >> Debian unstable, hence I gave it another try. I've noticed a virtual >> memory allocation of luatex having a size of 1,9 GB when building the >> cache. Not sure, if this is an significant improvement over the initial >> situation. >> >> Hilmar >> -- >> sigfault >> #206401 http://counter.li.org >>
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Hi Hilmar, Thank you for your response. I have checked this issue under TeXLive 2019 as of July 18 (installed by "install-tl") under ubuntu 19.04 (not debian/ubuntu packages) The memory consumption of the latex file included in this bug report was "only" 1.8 GB after rm -rf ~/.texlive2019. Noto CJK fonts versions are those of ubuntu 19.04 (not the latest ones). It was 6 GB when I filed this report. Maybe 32-bit Linux can now handle the Noto CJK fonts. At least we can say significant improvement is in the upstream, though 1.8 GB seems a bit larger than necessary... I again compiled the same latex file by xelatex, but the processing finished immediately and I could not see the memory consumption by "top"... Ryutaroh From: =?UTF-8?Q?Hilmar_Preu=c3=9fe?= Subject: Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts Date: Thu, 18 Jul 2019 16:24:39 +0200 > On 18.07.19 13:39, Ryutaroh Matsumoto wrote: > > Hi Ryutaroh, > >> I believe that the problem is spotted and fixed at >> https://github.com/u-fischer/luaotfload/issues/55 >> >> The above seems to be uploaded to ctan on July 15. >> Maybe the next release of texlive-luatex package will close >> this issue without special effort. >> > > 2019-05-18 luaotfload v2.97 > * fix issue #47 > * fix whatsits interfering with letterspacing (issue #53) > * fix luaotfload-tool switches version and find not working > correctly (PR#59) > * fix luaotfload-tool support of ttc fonts (PR#58) > * sync with context files from 2019-05-18 (improves handling of > large fonts, see e.g. issue #55 and PR#58) > > So, I'd expect that v2.97 solves the problem. This version however is in > Debian unstable, hence I gave it another try. I've noticed a virtual > memory allocation of luatex having a size of 1,9 GB when building the > cache. Not sure, if this is an significant improvement over the initial > situation. > > Hilmar > -- > sigfault > #206401 http://counter.li.org >
Bug#900678: slic3r: Segfaults at start since new wxwidgets.
On Wed, Oct 10, 2018 at 09:26:17AM +1300, Olly Betts wrote: > If we could automate "GDK_BACKEND=x11" (or equivalent via the GDK > API) in wxwidgets that would be a neater way to address this until > the upstream code is updated to not require X11, but that seems to > be tricky to do because we don't know if wxGLCanvas will be used > or not at the point where we need to do this. Forcing X11 for all > apps using the gtk3 flavour of wxwidgets3.0 seems a bad idea. It occurs to me that we could add the code to force X11 so that it activates when the libwx_gtk3u_gl-3.0.so is loaded. If the app is linked to that library that makes it very likely wxGLCanvas will be used, and if it isn't linked to that library, it won't be. I tend to think this is probably better handled by adding workaround code to affected apps though - they'll need it to work under Wayland on other distros after all. Cheers, Olly
Bug#521201: Fwd: Bug#521201: texlive-latex-recommended: powerdot requires enumitem.sty, which is in texlive-latex-extra
> I think I'd prefer to move powerdot to c-latexextra, instead of adding I agree with that. powerdot is getting less and less important. 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#932416: link to the commit that I believe introduced the bug
I believe that the bug was probably introduced with this commit: https://salsa.debian.org/installer-team/rootskel/commit/b6048aafed7d73ba42da04d6f7a798710f271384 -- Chris
Bug#932420: ITP: ruby-jekyll-admin -- traditional CMS-style graphical interface to Jekyll sites
Package: wnpp Severity: wishlist Owner: Daniel Leidert -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: ruby-jekyll-admin Version : 0.8.1 Upstream Author : Mert Kahyaoğlu * URL : https://github.com/jekyll/jekyll-admin * License : MIT/X Programming Lang: Ruby Description : traditional CMS-style graphical interface to Jekyll sites Jekyll Admin is a plugin that provides users with a traditional CMS-style graphical interface to author content and administer Jekyll sites. The frontend is based on Javascript and can only be accessed locally. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl0xEUsACgkQS80FZ8KW 0F0FCA/9HKWgr4f0JXopSNnk87Ts5a+puvQ8j/If2PUnuIGof5QIl0cJSjFWiwTO QTsBa9XjMHke+odnj/ZOBZx5XOFaUM4BQqYpiLxAdZobmvc211/hCm7efom6NZrQ NqgK4HNPQT5nVtV6doHhl8/7lNN+J+rg/gsz6MdtQLd2kyqgVOs0BWlNeqitbBpD 9hrpjdExO9R0S+U9AkMiPZYiiGZuohuegAGTzXQd9kaq5+PbFBKh7RyZ4BmLssAb IABu547KgYOLLJl49nP8peYVDgIT7AdRgTNDtd5h+yA88wCN4/4SxNULcLJZZQJy 1cCK+QPH28iBioY5m/hYTQxIOTifBOnjUDfuJTmxn5Sx/TZS9b/E7cER4dNniO2h r7zcI3vPexiD5SbLMnSY3ty3CCXUcQObiEebfeOnsJ95T+hJvumvq9D73ph0vOGp +QwJ6R8vRurDg3fru93m7eXE+s33CT9t79HmM98FeERNwGHx1uuY4FA2wy8dy4cz KKoM9BugXb3F+8df0CxxLWRXdJG93ZawPwEsb55HCS3nO3+YkGlALA83QQNlfkUQ kXuPfwfHorfjGnf+BYITs/kSo1BvLGppz8EDdIiukGyqYwCfURp0P17mQmZulpty y+5SUSgY34/HJFoZP/Pjd/b1pPOP0Arl8FRrp8ywDgdkOPmVSV4= =fxnZ -END PGP SIGNATURE-
Bug#930628: Bug #930628 Warning to Remove the Symlink Workaround
If anyone happened to have used my workaround of installed a temporary symlink flang-mod-33 -> flang-mode-34, be sure the remove that symlink before doing the update. -- James Ronald Lovell Huntsville, AL, USA
Bug#930628: Bug #930628 Confirmation of Fix
Yep, update 20190329-2 fixes the issue on my system. Thanks for the great work! -- James Ronald Lovell Huntsville, AL, USA
Bug#932419: kakoune: Please package new release; v2019.07.01
Package: kakoune Version: 2019.01.20-2 Severity: wishlist Kakoune has released a new version. Please consider updating the packaged version. Thanks. https://github.com/mawww/kakoune/releases/tag/v2019.07.01 -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kakoune depends on: ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libncursesw6 6.1+20181013-2 ii libstdc++68.3.0-6 ii libtinfo6 6.1+20181013-2 kakoune recommends no packages. kakoune suggests no packages. -- no debconf information -- John Eikenberry [ j...@zhar.net - http://zhar.net ] "Perfection is attained, not when no more can be added, but when no more can be removed." -- Antoine de Saint-Exupery
Bug#932418: ITP: ruby-jekyll-commonmark -- commonmark markdown converter for jekyll
Package: wnpp Severity: wishlist Owner: Daniel Leidert -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: ruby-jekyll-commonmark Version : 1.3.1 Upstream Author : Pat Hawks * URL : https://github.com/jekyll/jekyll-commonmark * License : MIT/X Programming Lang: Ruby Description : commonmark markdown converter for jekyll Jekyll Markdown converter plugin that uses libcmark, the reference parser for CommonMark. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl0xEDQACgkQS80FZ8KW 0F0HBhAArGkp5m+UJ/nz21oSFBEKyb+Avfj3Z8JRmrTUEiBp7CQCTgpWE7H7cJqY +/NKsmmqE5YJQwRpnFUrQhu16HDD21r03D4Q7etLlREzf6c7nAuzyfD4unlj3kiP y/vSogJq1Nc9bOrgGNOq2iFwzELNfmzRKhAjotWZtVx1+UX/64jljHBdrfxtI54v OnUdI5tJOjNbnbInheuBl4dRZv4b5PFNyxtEUrJcFGVk6iyVTNHWsEHBAdwJop8P D7T6ShRw3IqYcfvTQrq8Ss/MKh/zyiXod4/quQAWP4btLbZdfiKVHKoEe4P/3iml /Bny8SLdSiBQ/6vZyZXacuKDNvAmbuUnS7FIZb62yiSf5jod3wh9f28J1QMy3iCT slw9eOVmrZNQ2UhPfELu4KD+fnvV/+HKua2RIFBS87ZhoETlQqoCCsk04u45CkYU na2b51+UlJQda3v2WIYMCKnybo1m+lHDd9drws1l9qlloTUthn00r5JCdse8HKaU B+xgqcDCMchQlqDG7vCS0ynh/9KgOXVvE//rG1II6wEVo56EEwuqaeaMh+fX9Syr FO2AebkcMzoQ/4u6LT/mUGIG3sjgtl8uEiF/Z2clhUfwRufT5cq9Sz1Rqhe4wkPJ Lbq30gpTquFKl70/YV/CEwtWoDsjyssE6cO3zRqxcURzvIbEZmI= =KM5y -END PGP SIGNATURE-
Bug#892058: Key sync with SKS et al
> Although I had uploaded my public key to the keyserver network > months ago, it was never synced with keyring.debian.org. Hi, Is there a security-related reason why the key servers are not synced? If it is safe to do it occasionally, isn't it safer to do it all the time---especially to get revocations? Kind regards, Felix Lechner
Bug#932417: nmu: ocamlnet_4.1.2-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please rebuild ocamlnet to use camlzip 1.08-1, uploaded to unstable yesterday. Without this, ocamlnet fails to install as it depends on an old build of camlzip. nmu ocamlnet_4.1.2-3 . ANY . unstable . -m "rebuild against camlzip 1.08-1" -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: arm64, i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8), LANGUAGE=en_ZA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#932416: debian-installer: running d-i in parallel on multiple consoles may lead to race conditions
Package: debian-installer Severity: normal Dear Maintainer, I have observed some failures when running debian-installer in a paravirtualized Xen environment, but I do not believe that this issue is necessarily limited to paravirtualized Xen. When running the installer with a preseed file, installation fails at random points during the process. For instance, I have seen it fail as soon as the "choose language" step. Or it may fail when downloading installer components. In some instances, the file /var/lib/dpkg/info/lilo-installer.isinstallable goes missing, and the line "d-i lilo-installer/skip boolean true" from my preseed file is ignored. When manually running the installer, the program has been known to fail at the first step, "choose language". I spent some time tracking down the problem, and I believe it is caused by race conditions due to running multiple copies of the installer in parallel. My Xen domU is booted with the kernel command line "console=hvc0", and /proc/consoles has two entries: hvc0 and tty0. I have not seen the issues described above on a system that only has one entry in /proc/consoles. For instance, a Xen domU using HVM virtualization and booted with the kernel command line "console=ttyS0" only has a single entry in /proc/consoles. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#932404: firefox-esr, FTBFS "possible zip bomb".
On Fri, Jul 19, 2019 at 01:19:15AM +0200, Santiago Vila wrote: > On Fri, 19 Jul 2019, Mike Hommey wrote: > > > reassign -1 unzip > > found -1 6.0-24 > > notfound -1 6.0-23 > > > > This is a false positive from the changes in unzip 6.0-24. > > Please note that this is not necessarily a false positive. > It could be a buggy zipfile as well, like the ones reported here: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931895 > > I could ask Mark Adler (patch author) about this one, the same way I > did with the java "false positives", but please provide first a simple > way to reproduce the problem which does not involve building the > entire firefox source package. Download http://ftp.mozilla.org/pub/firefox/releases/68.0.1/linux-x86_64/en-US/firefox-68.0.1.tar.bz2 Extract it Unzip omni.ja The file *is* funky, but afaik it does not have overlapping components. Mike
Bug#932371: Subject: RFS: xsnow/1:2.0.8-1 [ITA] -- snow on desktop
On Fri, Jul 19, 2019 at 01:12:02AM +0200, Adam Borowski wrote: > On Thu, Jul 18, 2019 at 04:04:24PM +0200, Willem Vermin wrote: > > * Package name: xsnow > >Version : 1:2.0.8-1 > > > > Changes since the last upload: > > > > xsnow (1:2.0.8-1) unstable; urgency=low > > > > * New upstream release Also, please say "New maintainer (Closes: #931349)" to unorphan the package. -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄ (funeral doom metal).
Bug#932404: firefox-esr, FTBFS "possible zip bomb".
On Fri, 19 Jul 2019, Mike Hommey wrote: > reassign -1 unzip > found -1 6.0-24 > notfound -1 6.0-23 > > This is a false positive from the changes in unzip 6.0-24. Please note that this is not necessarily a false positive. It could be a buggy zipfile as well, like the ones reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931895 I could ask Mark Adler (patch author) about this one, the same way I did with the java "false positives", but please provide first a simple way to reproduce the problem which does not involve building the entire firefox source package. Thanks.
Bug#622970: Reassigned to insserv #622970
On Sun, 17 Apr 2011 20:09:40 +0200 Thomas Hood wrote: > I have just reassigned this report from resolvconf to > insserv because I believe that the insserv maintainers > will have more insight into the problem than I have. > > Here is a summary of what we have found out, as > described earlier in the report's message log. > > Resolvconf was misbehaving on the submitter's two fresh > squeeze machines. This was because resolvconf's initscript > had been installed in rcS.d at the traditional sequence > number S38 rather than at the appropriate sequence number > for the submitter's systems, S13. This was because, > although the submitter's systems had evidently been > subjected to boot sequence reordering by (I presume) > insserv, the /etc/init.d/.legacy-bootordering flag file was > still present on his systems. > > This incongruous situation --- reordered boot sequence, but > legacy flag file present --- may have resulted from the > presence of initscripts on the system lacking LSB headers. > -- > Thomas Hood This is an interesting bug. Though I'm not sure if it is still a problem. As far as I know, current versions of update-rc.d and insserv do not check for the ".legacy-bootordering" file flag (or create or remove it). I could be mistaken, but I think this was either resolved quietly in the past, or is outside our scope. I tried running the latest insserv with and without /etc/init.d/.legacy-bootordering in place and didn't encounter differences in behaviour. I think we can probably mark this one as closed unless someone comes up with a way insserv is misbehaving in this situation. - Jesse
Bug#932408: linux-image-4.19.0-5-amd64: kernel panic not syncing
On Thu, 2019-07-18 at 21:36 +0100, Terry wrote: > Package: src:linux > Version: 4.19.37-5 > Severity: important > > Dear Maintainer, > > I performed an upgrade from stretch to buster today and the kernel > paniced with a not syncing error. > > I've attempted to switch of acpi but adding the options acpi=off > pci=noacpi to the boot line but this didn't have any effect. [...] Disabling use of ACPI on any PC made in the last 15 years is likely to make things worse, anyway. Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part
Bug#932371: Subject: RFS: xsnow/1:2.0.8-1 [ITA] -- snow on desktop
On Thu, Jul 18, 2019 at 04:04:24PM +0200, Willem Vermin wrote: > * Package name: xsnow >Version : 1:2.0.8-1 > Changes since the last upload: > > xsnow (1:2.0.8-1) unstable; urgency=low > > * New upstream release > * Changed Standards-Version: 3.9.8 4.3.0 actually. Not that anyone really cares about those, but changing _to_ an ancient version raises eyebrows. > * Bump debhelper compat level to 11. You use compat 12, yet the dependency is only >= 11. Please either make it ">= 12~", or, better, drop debian/compat and use the new-style "Depends: debhelper-compat (=12)". This doesn't suffer from unsightly ~ nor the reason for it (backports). But... I think the changelog should include at least two other important bits: 1. you nuked the old packaging and rewritten it. Nice! 2. non-free -> main. Awesome! Alas, the second part is specially important as it requires a trip through NEW, for copyright review. Also, the actual program doesn't seem to work for me. XFCE, compositor on, two monitors (2560x1600 and 1200x1600), amdgpu, 64 cores. Trying to toggle "fullscreen" or "below" _briefly_ spawns some snow, then nothing; no other setting appears to do anything. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄ (funeral doom metal).
Bug#932415: dconf-cli: "dconf dump" output should have a fixed, reproducible order
Package: dconf-cli Version: 0.30.1-2 Severity: normal The "dconf dump" output should have a fixed, reproducible order, e.g. in lexicographic order. This is useful to detect changes in configuration. Currently, it depends on the version of glib2.0: the order has changed from 2.58.3-2 to 2.60.5-1. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) 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=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dconf-cli depends on: ii libc6 2.28-10 ii libdconf1 0.30.1-2 ii libglib2.0-0 2.60.5-1 dconf-cli recommends no packages. dconf-cli suggests no packages. -- no debconf information
Bug#932414: KDE GTK settings conflict with GTK settings of XFCE4
Package: task-kde-desktop
Version: 3.53
When I set up KDE's appearance, it creates a file in my $HOME called
.gtkrc-2.0 and a symlink .gtkrc-2.0-kde4 -> /home/me/.gtkrc-2.0. I think
it creates that file because I set the theme to GTK. However, when I
switch from KDE to XFCE, that file conflicts with XFCE's appearance
settings. I have to delete or move that file so that my settings in XFCE
will be properly applied.
The contents of the .gtkrc-2.0 file:
# File created by KDE Gtk Config
# Configs for GTK2 programs
include "/usr/share/themes/Redmond/gtk-2.0/gtkrc"
style "user-font"
{
font_name="DejaVu Sans Condensed Book"
}
widget_class "*" style "user-font"
gtk-font-name="DejaVu Sans Condensed Book 10"
gtk-theme-name="Redmond"
gtk-icon-theme-name="oxygen"
gtk-fallback-icon-theme="gnome"
gtk-cursor-theme-name="Oxygen 01 Yellow"
gtk-toolbar-style=GTK_TOOLBAR_ICONS
gtk-menu-images=0
gtk-button-images=0
gtk-primary-button-warps-slider=0
I would suggest that KDE create and access those files in a
sub-directory in my $HOME such as the currently empty .kde/env.
I am using xfce4 4.12.5.
I am using Linux office 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5
(2019-06-19) x86_64 GNU/Linux.
Lady Aleena
Bug#633858: -v not as safe as it sounds
The patch has been applied upstream and will appear in insserv 1.21.0. - Jesse
Bug#932413: python3-rpy2 should depend on tzlocal
Package: python3-rpy2 Version: 3.0.5-1 Severity: normal Dear Maintainer, python3-rpy2 should probably include a dependency on tzlocal or import tzlocal should not be top level import. /usr/lib/python3/dist-packages/rpy2/robjects/pandas2ri.py directly imports tzlocal It looks like the following might also work. --- /tmp/pandas2ri.py 2019-07-18 15:10:43.668445312 -0700 +++ pandas2ri.py2019-07-18 15:11:10.229349808 -0700 @@ -21,5 +21,4 @@ import numpy import pytz -import tzlocal import warnings @@ -157,4 +156,5 @@ timezone = default_timezone else: +import tzlocal timezone = tzlocal.get_localzone() return timezone -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-rpy2 depends on: ii python3 3.7.3-1 pn python3-cffi-backend-api-max pn python3-cffi-backend-api-min ii python3-jinja22.10.1-1 ii python3-numpy 1:1.16.2-1 ii python3-pytest3.10.1-2 ii python3-simplegeneric 0.8.1-2 ii r-base-core 3.5.2-1 python3-rpy2 recommends no packages. Versions of packages python3-rpy2 suggests: ii python-rpy-doc [python-rpy-docs] 1.0.3-30 -- no debconf information
Bug#932395: RFS: ipmitool/1.8.18-7
On Thu, Jul 18, 2019 at 08:15:58PM +0200, Jörg Frings-Fürst wrote: >Package name: ipmitool >Version : 1.8.18-7 > Changes since the last upload: > > * debian/watch: Use tags instead releases. > * Migrate to debhelper 12: > - Change debian/compat to 12. > - Bump minimum debhelper version in debian/control to >= 12. > * Declare compliance with Debian Policy 4.4.0 (No changes needed). > * debian/control: Add missing Depend init_system_helpers to fix > lintan warning. "to fix lintian warning" doesn't mean anything -- please say _what_ warning is being fixed. Lintian merely points out errors. And: "init-system-helpers (>> 0.1)" is bogus, as there was no version in the archive that would have failed that. The warning is clear: "update-rc.d defaults-disabled" needs init-system-helpers >= 1.50 > * New debian/patches/0615-manpage_typo.patch: Fix typos in man pages. > * Add DEP 8 smoketest (Closes: #903676). > Thanks to "Dann Frazier" . This test also seems to be bogus: what does it even test? It doesn't proceed anywhere beyond option parsing. Am I missing something, like a library with non-trivial initialization? Otherwise, I'd say this test should be marked as "superficial" or removed entirely. (A "superficial" test can still be useful if not entirely trivial.) > * Remove not longer needed debian/ipmitool.ipmievd.default (Closes: > #907832). > - New debian/ipmitool.maintscript to remove /etc/default/ipmitool. > - Add IPMIEVD_OPTIONS direct into debian/ipmitool.ipmievd.service. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ NADIE anticipa la inquisición de españa! ⠈⠳⣄
Bug#906124: Additional debug info
On Thu, 18 Jul 2019 15:06:55 -0400
Mathieu Trudel-Lapierre wrote:
> On Thu, Jul 18, 2019 at 10:01 AM Colin Watson
> wrote:
> > On Mon, Jul 08, 2019 at 09:15:49PM +0300, Vladislav Yarmak wrote:
> > > On Mon, 8 Jul 2019 14:57:08 +0100 Colin Watson
> > > wrote:
> [...]
>
> > > @@ -720,7 +718,16 @@ grub_cmd_linux (grub_command_t cmd __att
> > > return GRUB_ERR_NONE;
> > > }
> > > grub_dprintf ("linux", "linuxefi failed (%d)\n",
> > > grub_errno);
> > > - grub_errno = GRUB_ERR_NONE;
> > > + /* Preserve default workflow if verify module is
> > > loaded and
> > > + signatures are being checked. Condition below is
> > > even with
> > > + code which parses "check_signatures" variable in
> > > verify.c */
> > > + const char *env_chk_sig = grub_env_get
> > > ("check_signatures");
> > > + if (env_chk_sig &&
> > > + (env_chk_sig[0] == '1' || env_chk_sig[0] == 'e') &&
> > > + grub_dl_get("verify"))
> > > + grub_errno = GRUB_ERR_NONE;
> > > + else
> > > + goto fail;
> > > }
> > > }
> > > }
>
> I'm concerned that this approach does not necessarily fit the bill for
> every environment either. For one thing, we really don't want things
> to return GRUB_ERR_NONE anymore (so the fallback patch ought to go
> anyway, it defeats the purpose of Secure Boot); but also, it is not a
> given that if SB fails to validate, that verify is sufficient
> validation. I see this as a deployment-specific option, and probably a
> matter of whether the module is included in an signed GRUB UEFI binary
> or not, rather than whether some environment settings are present.
> Config and environment can be changed on the fly, a signed binary
> succesfully loaded by firmware and enforcing SB is much more difficult
> to trick in letting things get loaded. This is further complicated by
> the fact that anything could also load, or decide not to load, the
> verify module. Whether something is loaded or available as a module
> is not sufficient to decide whether you want to further validate and
> allow a kernel or not.
I still hope somebody notices that grub_dl_get in condition in patch.
Let's not ignore sad fact linuxefi module does not fit the bill in first
place, because it loads unsigned ramdrive and intrusion into boot chain
is trivial.
Maybe it at least can protect kernel? No, Microsoft keys already were
used to sign insecure binaries:
https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk
This way entire shim and grub can be silently replaced. So I just don't
get which security requirements you are referring to.
On the other hand, GRUB2 allows to use signatures even for config
files and ramdrive, and in condition of such secure deployment PGP
signature has cryptographic sense. This way it is possible to build
end-to-end protected boot chain.
But I have to admit, in case of default deployment trust to PGP module
may be used to circumvent linuxefi validation. For example, by trusting
additional key in config file and placing that signature for kernel. It
appears not so easy to fix it and now I doubt if there a real chance to
mix that different security models in source code of single binary,
because valid ways of building trust depend not from code, but from way
binary was signed and it's baked-in config. Thus, for GRUB binary which
was signed by user with embedded public key and enforcing config, trust
to "verify"/"pgp" module is absolutely legit.
Nonetheless, faulty PGP support in Debian 10 GRUB is a clear security
degradation because now Secure Boot support doesn't holds any security
model and user disabled from means to fix it. What do you think about
splitting code of MS-signed binaries and user-generated images with
grub-mkimage? Or maybe there are some other way?
--
Best Regards,
Vladislav Yarmak
Bug#521201: Fwd: Bug#521201: texlive-latex-recommended: powerdot requires enumitem.sty, which is in texlive-latex-extra
Hi Hilmar, please consider to move enumitem.sty from texlive-latex-extra to texlive-latex-recommended or even texlive-latex-base. I think I'd prefer to move powerdot to c-latexextra, instead of adding enumitem to c-latexrecommended (I see no need for c-latex[base). But if you think that would be bad, I don't mind moving enumitem; it's tiny, after all. Wdyt? --thanks, karl.
Bug#932412: ITP -- ruby-ahoy-email -- Simple, powerful email tracking for Rails
Package: wnpp Severity: wishlist Owner: Utkarsh Gupta * Package name : ruby-ahoy-email Version : 0.5.2 Upstream Author : Andrew Kane * URL : https://github.com/ankane/ahoy_email * License : Expat Programming Lang : Ruby Description: Simple, powerful email tracking for Rails Email analytics for Rails . This includes: * A history of emails sent to each user * Easy UTM tagging * Optional open and click tracking Best, Utkarsh
Bug#931739: [Pkg-kde-extras] Bug#931739: quassel-core: key too small error after upgrade to buster
On donderdag 18 juli 2019 20:11:46 CEST RedOmen wrote: > I tried to use the instructions here: > https://bugs.quassel-irc.org/projects/quassel-irc/wiki/Client-Core_SSL_suppo > rt but could not get it to work. > > I ended up having to remove all the /var/lib/quassel/ files and running > dpkg-reconfigure quassel-core and manually recreating my accounts but > that seems to have fixed it. You were bitten by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732728. The command that you need(ed) is contained in the postinst script of the package. You can view it by downloading the .deb file from https://packages.debian.org/buster/amd64/quassel-core/download (or find it in /var/cache/apt/archives/), open/extract it and then open/extract control.tar.xz in which you'll find the postinst file. For completeness, here's the relevant part of postinst that generates the certificate: # some variables QUASSEL_GROUP=quassel QUASSEL_USER=quasselcore QUASSEL_HOME=/var/lib/quassel QUASSEL_LOG=/var/log/quassel QUASSEL_CERT=$QUASSEL_HOME/quasselCert.pem if [ ! -e $QUASSEL_CERT ] ; then echo "Generating SSL certificate as $QUASSEL_CERT ..." ( umask 0027 && runuser -u $QUASSEL_USER -- openssl req -x509 -nodes -batch -days 680 -newkey rsa \ -keyout $QUASSEL_CERT -out $QUASSEL_CERT ) fi I know it's not important for you anymore, but in case others run into the same issue, they should now have enough to just regenerate the certificate. signature.asc Description: This is a digitally signed message part.
Bug#932411: lintian: duplicate-files could suggest how to fix it
Package: lintian Version: 2.16.0 Severity: wishlist Control: tags -1 patch Based on https://wiki.debian.org/dedup.debian.net#Tips_for_reducing_duplication_in_packages How: jdupes is simpler, but rdfind+symlinks is currently more popular (8 vs 42 according to codesearch). This may be because jdupes is newer, but I don't know. When: Needs to be after install, including of documentation if that is what is affected (dh_installdocs and dh_installexamples are after dh_install). I chose dh_link as the most appropriately named of the steps after that. Testing: https://salsa.debian.org/science-team/statsmodels/commit/c8a95ff6f4abd7daba0441bfc003d7d49c3f2d38 seems to work, but that's all I've done. (In particular, I have _not_ built Lintian to check this is the right place/syntax for a tag message.) --- a/checks/duplicate_files.desc +++ b/checks/duplicate_files.desc @@ -13,6 +13,11 @@ Info: The package ships the two (or more contents. . Note: empty files are exempt from this check. + . + Duplicates can often be replaced with symlinks by running + jdupes -rl debian/binarypackagename/usr/ + after they are installed, e.g. in override_dh_link. Consider + reporting this upstream. Tag: duplicate-changelog-files Severity: normal
Bug#932410: nautilus: drag-and-drop of files/folders is failing
Package: nautilus Version: 3.30.5-2 Severity: important Dear Maintainer, Since I did a fresh install of Debian 10, nautilus is quite frequently failing to drag and drop files and folders. By failing, I mean there is no error on the GUI side, but also it is as if I have never done the drag-and-drop, everything stays in their old place. I could not find a certain pattern to replicate the issue but it happens a lot. Also, after a while this happens, nautilus crashes with segfault (not always). In case it matters, I have `gdm 3.30.2-3` and using Wayland. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Drag-and-drop files/folders (no external drives). No appearant way to replicate, but happens frequently. * What exactly did you do (or not do) that was effective (or ineffective)? Could not find a solution yet. * What was the outcome of this action? On the GUI side, drag-and-dropped files remain at their old location, no error displays. Here is the relevant part from my syslog: ``` Jul 18 23:56:23 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 18 23:56:23 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 18 23:56:23 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 18 23:56:23 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 18 23:56:59 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 18 23:56:59 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 18 23:57:27 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 18 23:57:27 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 18 23:59:45 myhostname nautilus[19573]: g_object_ref: assertion 'G_IS_OBJECT (object)' failed Jul 18 23:59:45 myhostname nautilus[19573]: g_object_ref: assertion 'G_IS_OBJECT (object)' failed Jul 18 23:59:45 myhostname nautilus[19573]: g_object_ref: assertion 'G_IS_OBJECT (object)' failed Jul 18 23:59:45 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 18 23:59:45 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 18 23:59:45 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 18 23:59:45 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 19 00:00:07 myhostname nautilus[19573]: g_file_get_path: assertion 'G_IS_FILE (file)' failed Jul 19 00:00:08 myhostname nautilus[19573]: g_file_get_path: assertion 'G_IS_FILE (file)' failed Jul 19 00:00:16 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled ``` Another time with segfault: ``` Jul 19 00:12:17 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 19 00:14:30 myhostname dbus-daemon[1367]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus- org.freedesktop.hostname1.service' requested by ':1.2177' (uid=1000 pid=19573 comm="/usr/bin/nautilus --gapplication-service ") Jul 19 00:14:30 myhostname nautilus[19573]: nautilus_notebook_sync_tab_label: assertion 'NAUTILUS_IS_NOTEBOOK (notebook)' failed Jul 19 00:14:30 myhostname nautilus[19573]: nautilus_notebook_sync_tab_label: assertion 'NAUTILUS_IS_NOTEBOOK (notebook)' failed Jul 19 00:14:30 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 19 00:14:30 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 19 00:14:30 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 19 00:14:30 myhostname nautilus[19573]: ../../../../../gdk/wayland/gdkselection-wayland.c:261: error reading selection buffer: Operation was cancelled Jul 19 00:14:35 myhostname kernel: [ 6606.391604] naut
Bug#932409: libconfig-model-dpkg-perl: When the installed debian-policy is older than the hardcoded one, the error message is unhelpful
Package: libconfig-model-dpkg-perl Version: 2.122 Severity: normal While running dh-make-perl (0.106, not uploaded yet) for a new package, with an out-of-date policy installed (4.3.0 instead of 4.4.0), I got the following error: ``` Warning in 'source Standards-Version': Current standards version is '4.3.0'. Please read https://www.debian.org/doc/debian-policy/upgrading-checklist.html for the changes that may be needed on your package to upgrade it from standard version '4.4.0' to '4.3.0'. Offending value: '4.4.0' ``` while it is true that there is an issue on my system (I should have made sure the latest policy version was installed), the message is quite bizarre and unhelpful ;) Idealy, we whould check if the installed version is older than the hardcoded version and warn the user about the outdated local version and not ask him to check for "upgrades" in policy ;) Cheers, -- nodens -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libconfig-model-dpkg-perl depends on: ii libapt-pkg-perl0.1.36+b1 ii libarray-intspan-perl 2.003-1 ii libconfig-model-backend-yaml-perl 2.133-2 ii libconfig-model-perl 2.133-1 ii libexporter-lite-perl 0.08-1 ii liblog-log4perl-perl 1.49-1 pn libmodule-corelist-perl ii libmouse-perl 2.5.6-1+b1 ii libparse-recdescent-perl 1.967015+dfsg-2 ii libsoftware-licensemoreutils-perl 1.004-1 ii libtext-autoformat-perl1.74-2 ii libtext-levenshtein-damerau-perl 0.41-1 ii liburi-perl1.76-1 ii libwww-perl6.36-2 ii libyaml-perl 1.27-1 ii licensecheck 3.0.31-3 ii lintian2.15.0 ii perl 5.28.1-6 Versions of packages libconfig-model-dpkg-perl recommends: ii libconfig-model-tkui-perl 1.369-2 libconfig-model-dpkg-perl suggests no packages. -- no debconf information
Bug#932404: firefox-esr, FTBFS "possible zip bomb".
reassign -1 unzip
found -1 6.0-24
notfound -1 6.0-23
This is a false positive from the changes in unzip 6.0-24.
On Thu, Jul 18, 2019 at 09:04:24PM +0100, peter green wrote:
> package: firefox-esr
> version: 60.8.0esr-1
> severity: serious
>
> While trying to update firefox-esr in raspbian bullseye I ran into a
> "possible zip bomb" error. The failure also shows up on the reproducible
> builds site for i386 and arm64 so it's not raspbian specific.
>
> > warning [debian/tmp/usr/lib/firefox-esr/browser/omni.ja]: 34207731 extra
> > bytes at beginning or within zipfile
> >(attempting to process anyway)
> > error [debian/tmp/usr/lib/firefox-esr/browser/omni.ja]: reported length of
> > central directory is
> >-34207731 bytes too long (Atari STZip zipfile? J.H.Holm ZIPSPLIT 1.1
> >zipfile?). Compensating...
> > error: invalid zip file with overlapped components (possible zip bomb)
> > make[2]: [debian/rules:309: stamps/install-browser] Error 12 (ignored)
> > touch stamps/install-browser
> > make[2]: Leaving directory '/build/1st/firefox-esr-60.8.0esr'
> > debian/rules override_dh_install
> > make[2]: Entering directory '/build/1st/firefox-esr-60.8.0esr'
> > awk '{print "debian/tmp/" $1 }' < debian/noinstall | xargs rm -r
> > rm: cannot remove
> > 'debian/tmp/usr/lib/firefox-esr/browser/defaults/preferences/firefox-l10n.js':
> > No such file or directory
> > make[2]: *** [debian/rules:327: stamps/dh_install] Error 123
> > make[2]: Leaving directory '/build/1st/firefox-esr-60.8.0esr'
> > make[1]: *** [debian/rules:353: install] Error 2
> > make[1]: Leaving directory '/build/1st/firefox-esr-60.8.0esr'
> > make: *** [debian/rules:353: binary] Error 2
> > dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned
> > exit status 2
>
Bug#814772: proftpd-basic: includes ~-files in config, incluing a whole directory
tags 814772 + pending stop On 15.02.16 10:51, Harald Witt wrote: > Removing the ~-file "example.conf~" fixed the problem. > But I think it's usual not to include ~-files. > Documented that behavior in config template, so users can care. Tag bug as pending. H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#932408: linux-image-4.19.0-5-amd64: kernel panic not syncing
Package: src:linux Version: 4.19.37-5 Severity: important Dear Maintainer, I performed an upgrade from stretch to buster today and the kernel paniced with a not syncing error. I've attempted to switch of acpi but adding the options acpi=off pci=noacpi to the boot line but this didn't have any effect. The details below are from the same machine booted with the 4.9 kernel. I'll send images of the panic shortly. Kind regards, Terry. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Hewlett-Packard product_name: HP Compaq dc5800 Microtower product_version: chassis_vendor: Hewlett-Packard chassis_version: bios_vendor: Hewlett-Packard bios_version: 786F2 v01.04 board_vendor: Hewlett-Packard board_name: 2820h board_version: ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 82Q33 Express DRAM Controller [8086:29d0] (rev 02) Subsystem: Hewlett-Packard Company 82Q33 Express DRAM Controller [103c:281e] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:01.0 PCI bridge [0604]: Intel Corporation 82Q33 Express PCI Express Root Port [8086:29d1] (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [88] Subsystem: Hewlett-Packard Company 82Q33 Express PCI Express Root Port [103c:281e] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0300c Data: 41d1 Capabilities: [a0] Express (v1) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE+ DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #2, Speed 2.5GT/s, Width x16, ASPM L0s, Exit Latency L0s <1us, L1 <4us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #1, PowerLimit 75.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Off, PwrInd On, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet+ LinkState- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb:Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0:Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- Capabilities: [140 v1] Root Complex Link Desc: PortNumber=02 ComponentID=01 EltType=Config Link0: Desc: TargetPort=00 TargetComponent=01 AssocRCRB- LinkType=MemMapped LinkValid+ Addr: fed19000 Kernel driver in use: pcieport Kernel modules: shpchp 00:03.0 Communication controller [0780]: Intel Corporation 82Q33 Express MEI Controller [8086:29d4] (rev 02) Subsystem: Hewlett-Packard Company 82Q33 Express MEI Controller [103c:281e] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrSta
Bug#900117: Add systemd service file
On Sat, May 26, 2018 at 12:03:34PM +0200, Michael Biebl wrote: > Package: consolation > Version: 0.0.6-2 > Severity: wishlist > Tags: patch > > Hi, > > please consider applying the attached patch which adds a native systemd > .service file. This allows for better tracking of the daemon when > running under systemd. I also locked down the service a little > (Protect*, PrivateTmp). There is possibly room to lock the service down > even further, but this should be a good start. Hello Michael, Sorry for the delay. I have added your .service file to the upstream package. However for Debian, how does this will interact with options set in /etc/default/consolation ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#932407: gdnsd: CVE-2019-13951 CVE-2019-13952
Source: gdnsd Version: 2.4.2-1 Severity: important Tags: security upstream Forwarded: https://github.com/gdnsd/gdnsd/issues/185 Hi, The following vulnerabilities were published for gdnsd. CVE-2019-13951[0]: | The set_ipv4() function in zscan_rfc1035.rl in gdnsd 3.2.0 has a | stack-based buffer overflow via a long and malformed IPv4 address in | zone data. CVE-2019-13952[1]: | The set_ipv6() function in zscan_rfc1035.rl in gdnsd 3.2.0 has a | stack-based buffer overflow via a long and malformed IPv6 address in | zone data. 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-13951 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13951 [1] https://security-tracker.debian.org/tracker/CVE-2019-13952 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13952 [2] https://github.com/gdnsd/gdnsd/issues/185 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#932406: ITP: vavr0 -- object-functional language extension for Java
Package: wnpp Severity: wishlist Owner: Andrej Shadura -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: vavr0 Version : 0.10.0 Upstream Author : Daniel Dietrich * URL : ttp://vavr.io * License : Apache-2.0 Programming Lang: Java Description : object-functional language extension for Java Vavr (formerly called Javaslang) is an object-functional language extension for Java 8+. . Vavr aims to reduce the lines of code and increase code quality. It provides persistent collections, functional abstractions for error handling, concurrent programming, pattern matching and much more. . Vavr fuses the power of object-oriented programming with the elegance and robustness of functional programming. Its feature-rich, persistent collection library smoothly integrates with Java's standard collections. . Vavr does not depend on any libraries (other than the JVM). This package will ship only Vavr 0.x. It will be maintained by the Java Team. Vavr is a build dependency of the Kotlin compiler. - -- Cheers, Andrej -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl0w2fgUHGFuZHJld3No QGRlYmlhbi5vcmcACgkQXkCM2RzYOdKkoQf/eqDf7MwHo0/2pBdyt34ebrizfbip RvzDgjX3z0hU4UWDkMWwhQYP+1nyztO7G0BFbqYmziHPTbRSQR0wgJFLbYSwAXZF GwFXn4Xjei0a7INSrba5h8nj0J8e4Geb4o4JfUOt7plBB2lZQxSqAJ2fqr76DKrH oOdJuRAvVQ8dkTakTWOhIqORzvE1EUACnW5vU01PZKSAHf+PCNwKLvmV2eM8gx4s hwwjEl9Z35tORP7z4VAh08XvyIms/Nu1snPHrw5gYIy5vt3Kf0JPDOUG8Ojrzqln qgmu92HM1lrkAYK0VvEbCzKJb2KVqkAgjFVOF2ygOX1Jxdz5EjCTrzoEIg== =Yk1c -END PGP SIGNATURE-
Bug#885893: shairport-sync update hangs during service restart
Package: shairport-sync Followup-For: Bug #885893 -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information Hi Chris! I'm sorry I can't help you with the patch. I'm running testing on the affected machine and during some upgrade somewhere in 2018 I got systemdified - without asking. Since then I was to lazy to roll back and are running systemd since. With systemd the problem disappeared. Thomas
Bug#932405: gnome-shell: sometimes crashes when system services are restarted (probably bluetooth.service)
Package: libgnome-bluetooth13 Version: 3.28.2-3 Severity: important Affects: gnome-shell gnome-shell sometimes crashes when needrestart is allowed to restart system services. Based on the backtrace I suspect that restarting bluetooth.service is probably the trigger, but I can't reproduce the crash by just restarting bluetooth.service. I've included information on gnome-shell's dependencies in case I was wrong about the cause. Notice frame 3 in particular: > #3 0x7f2be42dc70d in adapter_notify_cb > (adapter=0x55cf28588a00, pspec=, client=0x55cf28fdc300 > [ClutterTextBuffer]) > at ../lib/bluetooth-client.c:542 I think this means the BluetoothClient that was meant to receive the signal has been freed (this code would probably benefit from more g_signal_connect_object()?) and the same address has been reused for a ClutterTextBuffer. #0 0x7f2c2136b840 in g_type_check_instance_cast (type_instance=0x20, iface_type=0x55cf26dcfe30 [GtkTreeModel]) at ../../../gobject/gtype.c:4052 #1 0x7f2be42dc63d in iter_search (store=0x20, iter=iter@entry=0x7ffdf0ca1880, parent=parent@entry=0x0, func=func@entry=0x7f2be42dc4b0 , user_data=0x7f2c08007730) at ../lib/bluetooth-client.c:110 #2 0x7f2be42dc6a1 in get_iter_from_proxy (store=, iter=iter@entry=0x7ffdf0ca1880, proxy=) at ../lib/bluetooth-client.c:183 #3 0x7f2be42dc70d in adapter_notify_cb (adapter=0x55cf28588a00, pspec=, client=0x55cf28fdc300 [ClutterTextBuffer]) at ../lib/bluetooth-client.c:542 #7 0x7f2c21363b6f in (instance=instance@entry=0x55cf28588a00, signal_id=, detail=) at ../../../gobject/gsignal.c:3447 #4 0x7f2c21346e8d in g_closure_invoke (closure=0x55cf28f11890, return_value=0x0, n_param_values=2, param_values=0x7ffdf0ca1ab0, invocation_hint=0x7ffdf0ca1a30) at ../../../gobject/gclosure.c:810 #5 0x7f2c2135a555 in signal_emit_unlocked_R (node=node@entry=0x55cf26394840, detail=detail@entry=100, instance=instance@entry=0x55cf28588a00, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffdf0ca1ab0) at ../../../gobject/gsignal.c:3635 #6 0x7f2c213634ae in g_signal_emit_valist (instance=, signal_id=, detail=, var_args=var_args@entry=0x7ffdf0ca1c80) at ../../../gobject/gsignal.c:3391 #8 0x7f2c2134b564 in g_object_dispatch_properties_changed (object=0x55cf28588a00 [Adapter1Proxy], n_pspecs=, pspecs=) at ../../../gobject/gobject.c:1088 #9 0x7f2c2134d9f1 in g_object_notify_by_spec_internal (pspec=, object=0x55cf28588a00 [Adapter1Proxy]) at ../../../gobject/gobject.c:1181 #10 0x7f2c2134d9f1 in g_object_notify (object=0x55cf28588a00 [Adapter1Proxy], property_name=property_name@entry=0x7f2c214f75f0 "g-name-owner") at ../../../gobject/gobject.c:1229 #11 0x7f2c21498c6b in on_name_owner_changed (connection=, sender_name=, object_path=, interface_name=, signal_name=, parameters=, user_data=0x55cf28add960) at ../../../gio/gdbusproxy.c:1356 #12 0x7f2c21487f04 in emit_signal_instance_in_idle_cb (data=0x7f2c0c2b2ac0) at ../../../gio/gdbusconnection.c:3743 #13 0x7f2c21260898 in g_main_dispatch (context=0x55cf26392e10) at ../../../glib/gmain.c:3189 #14 0x7f2c21260898 in g_main_context_dispatch (context=context@entry=0x55cf26392e10) at ../../../glib/gmain.c:3854 #15 0x7f2c21260c88 in g_main_context_iterate (context=0x55cf26392e10, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:3927 #16 0x7f2c21260f82 in g_main_loop_run (loop=0x55cf26686350) at ../../../glib/gmain.c:4123 #17 0x7f2c2073df8c in meta_run () at core/main.c:689 #18 0x55cf24e46782 in main (argc=, argv=) at ../src/main.c:501 -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgnome-bluetooth13 depends on: ii libc6 2.28-10 ii libcanberra-gtk3-0 0.30-7 ii libcanberra00.30-7 ii libglib2.0-02.60.5-1 ii libgtk-3-0 3.24.10-1 ii libnotify4 0.7.7-4 ii libudev1241-7 libgnome-bluetooth13 recommends no packages. libgnome-bluetooth13 suggests no packages. -- no debconf information Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii evolution-data-server3.30.5-1
Bug#929410: [Pkg-tigervnc-devel] Bug#929410: Bug#929410: RANDR extension not present
Hi Ola,
Am 30.06.19 um 19:04 schrieb Ola Lundqvist:
> Hi
>
> It is too late for buster. Deadline has passed more than a week ago. If I had
> been faster maybe it had been possible.
>
> Maybe we can get it to a point release. Do you know how much changes there
> are between 1.9.0+dfsg-3 and the one you mentioned?
> It seems to fall in the criteria to fix regression against current stable.
should fit. Debdiff attached. There are three minor bugs fixed 929410, 932264,
and 905905. Only code change is a
different WM_CLASS for xtigervncviewer. Moreover, xrandr libraries are now
enabled. Thus, additional code will be active
in x0tigervncserver.
Best,
Joachim
diff -Nru tigervnc-1.9.0+dfsg/debian/changelog tigervnc-1.9.0+dfsg/debian/changelog
--- tigervnc-1.9.0+dfsg/debian/changelog 2018-12-01 22:51:29.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/changelog 2019-07-18 17:59:04.0 +0200
@@ -1,3 +1,16 @@
+tigervnc (1.9.0+dfsg-4~RC3) UNRELEASED; urgency=medium
+
+ [ Joachim Falk ]
+ * Fix gnome shell integration of xtigervncviewer by updating
+xtigervncviewer.desktop and WM_CLASS of xtigervncviewer. (Closes: #905905)
+ * Added missing dependencies to enable RANDR support in x0tigervncserver,
+i.e., tigervnc-scraping-server. Also ensure that dropping these
+dependencies will lead to a fatal build error in the future. (Closes: #929410)
+ * Bumped version number in Debian provided man pages to TigerVNC 1.9
+(Closes: #932264).
+
+ -- Joachim Falk Thu, 18 Jul 2019 17:57:33 +0200
+
tigervnc (1.9.0+dfsg-3) unstable; urgency=medium
[ Joachim Falk ]
diff -Nru tigervnc-1.9.0+dfsg/debian/control tigervnc-1.9.0+dfsg/debian/control
--- tigervnc-1.9.0+dfsg/debian/control 2018-12-01 22:51:29.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/control 2019-06-15 20:50:33.0 +0200
@@ -24,6 +24,7 @@
libpam0g-dev,
libxft-dev,
libxcursor-dev,
+ libxrandr-dev,
libwrap0-dev,
libfltk1.3-dev (>= 1.3.3),
xorg-server-source (>= 2:1.20),
diff -Nru tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1 tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1
--- tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1 2018-12-01 22:50:28.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1 2019-07-18 17:53:14.0 +0200
@@ -1,4 +1,4 @@
-.TH tigervncserver 1 "Jan 5th, 2017" "TigerVNC 1.7" "Virtual Network Computing"
+.TH tigervncserver 1 "Jul 18th, 2019" "TigerVNC 1.9" "Virtual Network Computing"
.SH NAME
tigervncserver \- start or stop a TigerVNC server
.SH SYNOPSIS
diff -Nru tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man5/vnc.conf.5x tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man5/vnc.conf.5x
--- tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man5/vnc.conf.5x 2018-12-01 22:50:28.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man5/vnc.conf.5x 2019-07-18 17:52:52.0 +0200
@@ -9,7 +9,7 @@
.\" License as specified in the file COPYING that comes with the
.\" Debian GNU/Linux distribution.
.\"
-.TH vnc.conf 5x "Jan 5th, 2017" "TigerVNC 1.7" "Virtual Network Computing"
+.TH vnc.conf 5x "Jul 18th, 2019" "TigerVNC 1.9" "Virtual Network Computing"
.SH NAME
vnc.conf \- configuration file for Virtual Network Computing
.SH SYNOPSIS
diff -Nru tigervnc-1.9.0+dfsg/debian/patches/0175-xtigervncviewer-WM_CLASS.patch tigervnc-1.9.0+dfsg/debian/patches/0175-xtigervncviewer-WM_CLASS.patch
--- tigervnc-1.9.0+dfsg/debian/patches/0175-xtigervncviewer-WM_CLASS.patch 1970-01-01 01:00:00.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/patches/0175-xtigervncviewer-WM_CLASS.patch 2019-06-15 14:11:27.0 +0200
@@ -0,0 +1,16 @@
+Description: Update WM_CLASS to correspond to the one given in the xtigervncviewer.desktop file
+Author: Joachim Falk
+
+Index: pkg-tigervnc/vncviewer/vncviewer.cxx
+===
+--- pkg-tigervnc.orig/vncviewer/vncviewer.cxx
pkg-tigervnc/vncviewer/vncviewer.cxx
+@@ -197,7 +197,7 @@ static void init_fltk()
+
+ // Proper Gnome Shell integration requires that we set a sensible
+ // WM_CLASS for the window.
+- Fl_Window::default_xclass("vncviewer");
++ Fl_Window::default_xclass("TigerVNC Viewer");
+
+ // Set the default icon for all windows.
+ #ifdef WIN32
diff -Nru tigervnc-1.9.0+dfsg/debian/patches/series tigervnc-1.9.0+dfsg/debian/patches/series
--- tigervnc-1.9.0+dfsg/debian/patches/series 2018-12-01 22:51:29.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/patches/series 2019-06-15 14:11:27.0 +0200
@@ -1,5 +1,6 @@
0102-fix-spelling-error-in-manpages-to-shutup-lintian.patch
0151-make-cmake-enable-options-mandatory-if-turned-on.patch
+0175-xtigervncviewer-WM_CLASS.patch
# rework/0200-add-tcpwrappers-support.patch # This patch is still not ported
# These patches are lifted from RedHat
@@ -16,6 +17,7 @@
#rh/dustbin/tigervnc-xserver119.patch # buster has xserver120 and T
Bug#932324: dh-make-elpa: please switch dh-make-perl dependency to libdebian-source-perl
Hello, On Thu 18 Jul 2019 at 10:20AM -03, David Bremner wrote: > Should we ask for more things to be split out? We could, but based on my memory of the code used by dh-make-elpa, I think doing such a split would require someone to design a Perl library for arbitrary dh-make-* tools. It would probably be reasonable for those working on dh-make-elpa to do that work, rather than the dh-make-perl people. -- Sean Whitton signature.asc Description: PGP signature
Bug#932404: firefox-esr, FTBFS "possible zip bomb".
package: firefox-esr
version: 60.8.0esr-1
severity: serious
While trying to update firefox-esr in raspbian bullseye I ran into a "possible zip
bomb" error. The failure also shows up on the reproducible builds site for i386 and
arm64 so it's not raspbian specific.
warning [debian/tmp/usr/lib/firefox-esr/browser/omni.ja]: 34207731 extra bytes
at beginning or within zipfile
(attempting to process anyway)
error [debian/tmp/usr/lib/firefox-esr/browser/omni.ja]: reported length of
central directory is
-34207731 bytes too long (Atari STZip zipfile? J.H.Holm ZIPSPLIT 1.1
zipfile?). Compensating...
error: invalid zip file with overlapped components (possible zip bomb)
make[2]: [debian/rules:309: stamps/install-browser] Error 12 (ignored)
touch stamps/install-browser
make[2]: Leaving directory '/build/1st/firefox-esr-60.8.0esr'
debian/rules override_dh_install
make[2]: Entering directory '/build/1st/firefox-esr-60.8.0esr'
awk '{print "debian/tmp/" $1 }' < debian/noinstall | xargs rm -r
rm: cannot remove
'debian/tmp/usr/lib/firefox-esr/browser/defaults/preferences/firefox-l10n.js':
No such file or directory
make[2]: *** [debian/rules:327: stamps/dh_install] Error 123
make[2]: Leaving directory '/build/1st/firefox-esr-60.8.0esr'
make[1]: *** [debian/rules:353: install] Error 2
make[1]: Leaving directory '/build/1st/firefox-esr-60.8.0esr'
make: *** [debian/rules:353: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit
status 2
Bug#931847: Boggus package-supports-alternative-init-but-no-init.d-script test?
Michael Biebl wrote: > Fwiw, I've only seen 100s of false positives so far. Claiming it's > certainty to be "certain" is overstating it "a little". Due to prioritisation of effort and energy the Lintian maintainers put very little time and effort into curating these "certainty" levels. I would thus not read anything into them whatsoever and certainly not be too irked if they do not match reality. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#929848: How is the packaging of pplpy going?
On 7/18/19 3:17 PM, Julien Puydt wrote: > Hi, > > Le 18/07/2019 à 20:12, Tobias Hansen a écrit : >> I pushed it now to https://salsa.debian.org/science-team/pplpy/ >> >> Feel free to work on / upload it. > Excellent! > > I worked on it a little. > > But I don't understand the lines in d/rules where you put "export > whatever=whatever" as dependencies... does it work? > > Cheers, > > JP Great, thanks! That export thing is to prevent sphinx accessing the internet, from https://wiki.debian.org/Python/LibraryStyleGuide#Sphinx_documentation Best, Tobias
Bug#932403: emacs-gtk: Running helm-ucs command (package helm-unicode) leads to emacs crash
Package: emacs-gtk Version: 1:26.1+1-3.2 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? - Installed emacs-gtk - Added MELPA in the package repositories - Installed helm-unicode * What exactly did you do (or not do) that was effective (or ineffective)? - when issueing "helm-ucs" -> emacs just crashes - I uninstalled emacs, and installed it with nixpkgs (nix-env): this version does not have the problem *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs-gtk depends on: ii emacs-bin-common 1:26.1+1-3.2 ii emacs-common 1:26.1+1-3.2 ii libacl12.2.53-4 ii libasound2 1.1.8-1 ii libatk1.0-02.30.0-2 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-31.12.16-1 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgif75.1.4-3 ii libglib2.0-0 2.58.3-2 ii libgnutls303.6.7-4 ii libgomp1 8.3.0-6 ii libgpm21.20.7-5 ii libgtk-3-0 3.24.5-1 ii libice62:1.0.9-2 ii libjpeg62-turbo1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii libm17n-0 1.8.0-2 ii libmagickcore-6.q16-6 8:6.9.10.23+dfsg-2.1 ii libmagickwand-6.q16-6 8:6.9.10.23+dfsg-2.1 ii libotf00.9.13-4 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-01.42.4-6 ii libpng16-161.6.36-6 ii librsvg2-2 2.44.10-2.1 ii libselinux12.8-1+b1 ii libsm6 2:1.2.3-1 ii libsystemd0241-5 ii libtiff5 4.0.10-4 ii libtinfo6 6.1+20181013-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb12:1.6.7-1 ii libxcb11.13.1-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxft22.3.2-2 ii libxinerama1 2:1.1.4-2 ii libxml22.9.4+dfsg1-7+b3 ii libxpm41:3.5.12-1 ii libxrandr2 2:1.5.1-1 ii libxrender11:0.9.10-1 ii zlib1g 1:1.2.11.dfsg-1 emacs-gtk recommends no packages. Versions of packages emacs-gtk suggests: pn emacs-common-non-dfsg -- no debconf information
Bug#923993: netdata: Avoid embedding a copy of dygraphs
close 923993 thanks Hi, given that nobody took any action on #749603 since 2014 (and I'm not interested either in maintaining libjs-dygraphs in debian) I'm closing this bug. Netdata has many embededd copies of different things and it doesn't make sense for us to keep this specific one for dygraphcs open. We do regularly check to see if there's stuff in the archive that we can move to and get rid of the embedded versions. Regards, Daniel
Bug#931847: Boggus package-supports-alternative-init-but-no-init.d-script test?
On 18.07.19 21:43, Michael Biebl wrote: > Hm, why the moreinfo tag? > This lintian check is clearly way too broad to be useful as-is. > At its current state, please demote it to pedantic (or reverting it > completely) until it actually is useful. Fwiw, I've only seen 100s of false positives so far. Claiming it's certainty to be "certain" is overstating it "a little". -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#931847: Boggus package-supports-alternative-init-but-no-init.d-script test?
On Thu, 11 Jul 2019 11:39:28 -0300 "Chris Lamb" wrote: > block 931847 by 911165 > tags 931847 + moreinfo > thanks > > Ansgar Burchardt wrote: > > > > My understanding of the policy is that, if a package supports an > > > alternative init (other than systemd) it must also support sysvinit. > > > > > > Also note that if the check is actually correct, this will create false > > > positive for all the systemd .service files not started at boot > > > (scheduled jobs, dbus activated,...). > > > > The current policy requirement is that everything would need to provide > > a sysvinit script, see https://bugs.debian.org/911165 > > > > Sadly the process to change this is stuck. > > (I'm just applying some routine bug triage here; not a comment on the > bug's merits.) Hm, why the moreinfo tag? This lintian check is clearly way too broad to be useful as-is. At its current state, please demote it to pedantic (or reverting it completely) until it actually is useful. Thanks, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#932402: new upstream (1.0.9)
Package: redfishtool Severity: wishlist Hi, please upgrade to the current upstream release (1.0.9) and upload it to unstable. Regards, Daniel
Bug#932012: Please upload backport for stretch
On Tue, 16 Jul 2019 08:29:23 -0700, Felix Lechner wrote: > On Tue, Jul 16, 2019 at 6:34 AM gregor herrmann wrote: > > So the .dsc refers to libio-async-loop-epoll-perl_0.20.orig.tar.gz > > and libio-async-loop-epoll-perl_0.20-1~bpo9+1.debian.tar.xz and both > > don't seem to exist on mentors. > I built and uploaded it again, this time from testing instead of > stretch. Can you please try again? Thank you, uploaded in imported into the repo. Please close this bug when it hits the archive or at your convenience. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#912367: stretch-pu: package gthumb/3:3.4.4.1-5
On 7/18/19 4:19 PM, Salvatore Bonaccorso wrote: > hey! > > On Thu, Jul 18, 2019 at 03:55:40PM -0300, Herbert Fortes wrote: >> On Tue, 16 Jul 2019 20:38:15 +0100 "Adam D. Barratt" >> wrote: >>> On Sat, 2019-03-09 at 16:41 +, Adam D. Barratt wrote: On Mon, 2018-12-03 at 08:17 +0100, Julien Cristau wrote: > Control: tag -1 confirmed >>> [...] > Go ahead, thanks. Ping? >>> >>> Ping? If nothing happens by August 15th then I plan to close this bug. >>> >>> Regards, >>> >>> Adam >>> >> >> Uploaded. > > As discussed in the backlog of this bug, this should actually have > been 3:3.4.4.1-*5*+deb9u1, but I see > > gthumb | 3:3.4.4.1-6+deb9u1 | oldstable-new | source, amd64 > > should that be rejected and re-uploaded? > Yes! Reject the upload. > - gthumb_3.4.4.1-5_3.4.4.1-5+deb9u1.diff.gz
Bug#932401: patch: CVE-2019-13636
Source: patch Version: 2.7.6-3 Severity: important Tags: security upstream Control: found -1 2.7.6-4 Hi, The following vulnerability was published for patch. CVE-2019-13636[0]: | In GNU patch through 2.7.6, the following of symlinks is mishandled in | certain cases other than input files. This affects inp.c and util.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-13636 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13636 [1] https://git.savannah.gnu.org/cgit/patch.git/commit/?id=dce4683cbbe107a95f1f0d45fabc304acfb5d71a Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#932400: RM: node-husl -- ROM; Orphaned upstream and replaced by node-hsluv
Package: ftp.debian.org Severity: normal node-husl is no more maintained upstream [1]: it has been replaced by hsluv. This package has no reverse dependencies, I think it can safely be removed form Debian archive. Cheers, Xavier [1]: https://www.npmjs.com/package/husl
Bug#932148: RFS: pysolfc/2.6.4-1 [RC]
Control: severity -1 important Juhani Numminen kirjoitti 16.7.2019 klo 0.33: > Dear mentors, > > I am looking for a sponsor for the games-team's package pysolfc. > Hugo Lefeuvre had been preparing an upload in git for quite some > time already. Due to #931851 I was inspired to join the effort. > For reference, I've notified Hugo (and the whole team) of my progress: > https://lists.debian.org/debian-devel-games/2019/07/msg1.html > > * Package name: pysolfc >Version : 2.6.4-1 >Upstream Author : Shlomi Fish > * URL : https://pysolfc.sourceforge.io/ >: https://github.com/shlomif/PySolFC/ > * License : GPL >Section : games > > It builds those binary packages: > pysolfc - collection of more than 1000 solitaire card games > > The source is not at mentors.debian.net since I'm away from my usual > GPG key and cannot sign the package today. It's in mentors now. One can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pysolfc/pysolfc_2.6.4-1.dsc I've set the RFS bug severity to important, as there's a release-critical bug fix.
Bug#912367: stretch-pu: package gthumb/3:3.4.4.1-5
hey! On Thu, Jul 18, 2019 at 03:55:40PM -0300, Herbert Fortes wrote: > On Tue, 16 Jul 2019 20:38:15 +0100 "Adam D. Barratt" > wrote: > > On Sat, 2019-03-09 at 16:41 +, Adam D. Barratt wrote: > > > On Mon, 2018-12-03 at 08:17 +0100, Julien Cristau wrote: > > > > Control: tag -1 confirmed > > [...] > > > > Go ahead, thanks. > > > > > > Ping? > > > > Ping? If nothing happens by August 15th then I plan to close this bug. > > > > Regards, > > > > Adam > > > > Uploaded. As discussed in the backlog of this bug, this should actually have been 3:3.4.4.1-*5*+deb9u1, but I see gthumb | 3:3.4.4.1-6+deb9u1 | oldstable-new | source, amd64 should that be rejected and re-uploaded? Regards, Salvatore
Bug#929848: How is the packaging of pplpy going?
Hi, Le 18/07/2019 à 20:12, Tobias Hansen a écrit : > I pushed it now to https://salsa.debian.org/science-team/pplpy/ > > Feel free to work on / upload it. Excellent! I worked on it a little. But I don't understand the lines in d/rules where you put "export whatever=whatever" as dependencies... does it work? Cheers, JP
Bug#932399: uscan: fails for archive.org urls with error 400 URL must be absolute
Package: devscripts Version: 2.19.5 Severity: important How to reproduce? --debian/watch content version=4 https://archive.org/download/dinisnoise_source_code/ \ din-(.+)\.tar\.gz --cli log - $ uscan --verbose uscan info: uscan (version 2.19.5) See uscan(1) for help uscan info: Scan watch files in . uscan info: Check debian/watch and debian/changelog in . uscan info: package="din" version="5.2.1-6" (as seen in debian/changelog) uscan info: package="din" version="5.2.1" (no epoch/revision) uscan info: ./debian/changelog sets package="din" version="5.2.1" uscan info: Process watch file at: debian/watch package = din version = 5.2.1 pkg_dir = . uscan info: Last orig.tar.* tarball version (from debian/changelog): 5.2.1 uscan info: Last orig.tar.* tarball version (dversionmangled): 5.2.1 uscan info: Requesting URL: https://archive.org/download/dinisnoise_source_code/ uscan info: Matching pattern: (?:(?:https://archive.org)?\/download\/dinisnoise_source_code\/)?din-(.+)\.tar\.gz uscan info: Found the following matching hrefs on the web page (newest first): din-42.tar.gz (42) index=42-1 din-41.tar.gz (41) index=41-1 din-40.tar.gz (40) index=40-1 din-39.0.1.tar.gz (39.0.1) index=39.0.1-1 din-39.tar.gz (39) index=39-1 din-38a.tar.gz (38a) index=38a-1 din-38.tar.gz (38) index=38-1 din-37a.tar.gz (37a) index=37a-1 din-36.tar.gz (36) index=36-1 din-35.tar.gz (35) index=35-1 din-34.tar.gz (34) index=34-1 din-33.tar.gz (33) index=33-1 din-32.tar.gz (32) index=32-1 din-31.tar.gz (31) index=31-1 din-30.tar.gz (30) index=30-1 din-29.tar.gz (29) index=29-1 din-28.tar.gz (28) index=28-1 uscan info: Looking at $base = https://archive.org/download/dinisnoise_source_code/ with $filepattern = din-(.+)\.tar\.gz found $newfile = din-42.tar.gz $newversion = 42 which is newer than $lastversion = 5.2.1 uscan info: Matching target for downloadurlmangle: /download/dinisnoise_source_code/din-42.tar.gz uscan info: Upstream URL(+tag) to download is identified as /download/dinisnoise_source_code/din-42.tar.gz uscan info: Filename (filenamemangled) for downloaded file: din-42.tar.gz uscan: Newest version of din on remote site is 42, local version is 5.2.1 uscan:=> Newer package available from /download/dinisnoise_source_code/din-42.tar.gz uscan info: Downloading upstream package: din-42.tar.gz uscan info: Requesting URL: /download/dinisnoise_source_code/din-42.tar.gz uscan warn: In directory ., downloading /download/dinisnoise_source_code/din-42.tar.gz failed: 400 URL must be absolute uscan info: Failed to download upstream package: din-42.tar.gz uscan info: Start checking for common possible upstream OpenPGP signature files uscan info: End checking for common possible upstream OpenPGP signature files uscan info: Missing OpenPGP signature. uscan info: New orig.tar.* tarball version (oversionmangled): 42 uscan warn: No upstream tarball downloaded. No further processing with mk_origtargz ... uscan info: Scan finished where as the link is working with firefox
Bug#927254: closed by Xavier Guimard (Bug#927254: fixed in vue-router.js 3.0.7+ds-1)
Le 17/07/2019 à 16:57, Dmitry Bogatov a écrit : > > control: reopen -1 > control: tags -1 -pending > > [2019-07-10 19:39] "Debian Bug Tracking System" >> This is an automatic notification regarding your Bug report >> which was filed against the libjs-vue-router package: >> >> #927254: libjs-vue-router: ships node module instead of browser one >> >> It has been closed by Xavier Guimard . > > It did not solve my problem. Package libjs-vue-router still provides files > in /usr/share/nodejs: > > $ dpkg -L libjs-vue-router |grep -v /usr/share/doc > /. > /usr > /usr/share > /usr/share/javascript > /usr/share/nodejs > /usr/share/nodejs/vue-router > /usr/share/nodejs/vue-router/dist > /usr/share/nodejs/vue-router/dist/vue-router.common.js > /usr/share/nodejs/vue-router/dist/vue-router.esm.browser.js > /usr/share/nodejs/vue-router/dist/vue-router.esm.browser.min.js > /usr/share/nodejs/vue-router/dist/vue-router.esm.js > /usr/share/nodejs/vue-router/dist/vue-router.js > /usr/share/nodejs/vue-router/dist/vue-router.min.js > /usr/share/nodejs/vue-router/package.json > /usr/share/javascript/vue-router > > Futhermore, it bundles dangling symlink: > > $ readlink /usr/share/javascript/vue-router > ../../lib/nodejs/vue-router/dist > > When I try to build Laminar with > "/usr/share/nodejs/vue-router/dist/vue-router.min.js" > > I get following error: > > Uncaught TypeError: t is not a function > at L (vue-router.min.js:6) > at t (vue-router.min.js:6) > at vue-router.min.js:6 > at Array.forEach () > at T (vue-router.min.js:6) > at $ (vue-router.min.js:6) > at new vt (vue-router.min.js:6) > at app.js:796 > > Interestingly, if I use /usr/share/nodejs/vue-router/dist/vue-router.js, > I get another (already seen) error: > > Uncaught TypeError: Regexp is not a function > at compileRouteRegex (vue-router.min.js:formatted:783) > at addRouteRecord (vue-router.min.js:formatted:722) > at vue-router.min.js:formatted:686 > at Array.forEach () > at createRouteMap (vue-router.min.js:formatted:685) > at createMatcher (vue-router.min.js:formatted:859) > at new VueRouter (vue-router.min.js:formatted:1947) > at app.js:796 Hello, I embedded path-to-regexp in build (https://salsa.debian.org/js-team/vue-router.js/commit/65478a93), now difference with upstream build is minimal. Could you try this (with vue-router.js built from https://salsa.debian.org/js-team/vue-router.js) ? Cheers, Xavier
Bug#906124: Additional debug info
On Thu, Jul 18, 2019 at 10:01 AM Colin Watson wrote:
> On Mon, Jul 08, 2019 at 09:15:49PM +0300, Vladislav Yarmak wrote:
> > On Mon, 8 Jul 2019 14:57:08 +0100 Colin Watson
> > wrote:
[...]
> > @@ -720,7 +718,16 @@ grub_cmd_linux (grub_command_t cmd __att
> > return GRUB_ERR_NONE;
> > }
> > grub_dprintf ("linux", "linuxefi failed (%d)\n", grub_errno);
> > - grub_errno = GRUB_ERR_NONE;
> > + /* Preserve default workflow if verify module is loaded and
> > + signatures are being checked. Condition below is even with
> > + code which parses "check_signatures" variable in verify.c */
> > + const char *env_chk_sig = grub_env_get ("check_signatures");
> > + if (env_chk_sig &&
> > + (env_chk_sig[0] == '1' || env_chk_sig[0] == 'e') &&
> > + grub_dl_get("verify"))
> > + grub_errno = GRUB_ERR_NONE;
> > + else
> > + goto fail;
> > }
> > }
> > }
I'm concerned that this approach does not necessarily fit the bill for
every environment either. For one thing, we really don't want things
to return GRUB_ERR_NONE anymore (so the fallback patch ought to go
anyway, it defeats the purpose of Secure Boot); but also, it is not a
given that if SB fails to validate, that verify is sufficient
validation. I see this as a deployment-specific option, and probably a
matter of whether the module is included in an signed GRUB UEFI binary
or not, rather than whether some environment settings are present.
Config and environment can be changed on the fly, a signed binary
succesfully loaded by firmware and enforcing SB is much more difficult
to trick in letting things get loaded. This is further complicated by the fact
that anything could also load, or decide not to load, the verify module.
Whether something is loaded or available as a module is not sufficient to
decide whether you want to further validate and allow a kernel or not.
In short, I have very much the same opinion as what Colin expresses below.
>
> This specific approach isn't suitable, I'm afraid. The copied code is
> too fragile (things could go badly wrong if the check_signatures parsing
> were changed upstream and we forgot to update this patch to match).
> More importantly, this approach encodes an implicit assumption that if
> that environment variable is set then some other bit of code is actually
> set up to consume it and verify the kernel in some other way. This is
> not robust, because there's nothing to say that the pgp module is loaded
> if the linux module is loaded: it would be quite possible to have an
> image that contains the linux module but not the pgp module, and then
> you have a UEFI Secure Boot bypass just by setting check_signatures=1.
> (Note that the module layout is a bit different in 2.04 than in 2.02,
> which is why it's important to prepare this patch against the latest
> version.)
>
[...]
> In fact, perhaps part of the solution could be to integrate the shim
> checking with the verifiers framework, and then linuxefi would (if
It's supposed to get ported to the verifiers framework now that we
have that available; I expect making sure PGP can be done via
verifiers too, and then integration would be pretty, efficient, and
solid.
> anything) just need to check that some appropriate verifier has been
> run, rather than the current code that predates verifiers and does the
> check by hand. This would make much more logical sense: rather than
> scattering verification logic around all over the place, it would all be
> neatly encapsulated in verifiers. Doing this would probably be part of
> a useful path to getting shim verification upstream, too. And, even if
> we do end up backporting this to 2.02 which doesn't have verifiers, it's
> always easier to unroll a well-encapsulated approach into a series of
> ad-hoc checks than the other way round.
>
Mathieu Trudel-Lapierre
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1
Bug#912367: stretch-pu: package gthumb/3:3.4.4.1-5
On Tue, 16 Jul 2019 20:38:15 +0100 "Adam D. Barratt" wrote: > On Sat, 2019-03-09 at 16:41 +, Adam D. Barratt wrote: > > On Mon, 2018-12-03 at 08:17 +0100, Julien Cristau wrote: > > > Control: tag -1 confirmed > [...] > > > Go ahead, thanks. > > > > Ping? > > Ping? If nothing happens by August 15th then I plan to close this bug. > > Regards, > > Adam > Uploaded. Regards, Herbert
Bug#932397: rdma-core: please consider uploading v24.0 to buster-backports
Source: rdma-core Severity: wishlist Dear Maintainer(s), The Microsoft Azure accelerated networking uses Mellanox devices. When using Dataplane Development Kit (DPDK) the Mellanox usermode driver uses rdma-core/libibverbs to access the hardware. DPDK supports a multi-process mode where a primary and secondary process share the same hardware. In order to get multi-process mode working, Mellanox had to make changes to libibverbs. These changes went in v23. Given this happened too late for buster, it shipped with v22 which causes problems for Debian images running on Azure with these features. Would you please consider uploading rdma-core 24.0-2 to buster- backports, now that it's open for business, when time permits? Thank you! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#906124: Additional debug info
On Thu, 18 Jul 2019 15:00:44 +0100
Colin Watson wrote:
> This format is difficult to review and apply, not least because later
> versions of the source package have moved on in different ways. For
> the next version, please just send a patch against
> grub-core/loader/i386/linux.c (etc.) directly that makes your change
> relative to what's currently in the Debian source package.
> Please prepare your patch against the version in unstable (preferably
> https://salsa.debian.org/grub-team/grub), not the version in buster.
> Patches generally flow backwards from unstable rather than forwards
> from stable releases.
I thought it is more preferable to replace one patch with another in
order to keep patch stack size. But placing one more patch on top of
all rest sounds also OK for me.
> This specific approach isn't suitable, I'm afraid. The copied code is
> too fragile (things could go badly wrong if the check_signatures
> parsing were changed upstream and we forgot to update this patch to
> match). More importantly, this approach encodes an implicit
> assumption that if that environment variable is set then some other
> bit of code is actually set up to consume it and verify the kernel in
> some other way. This is not robust, because there's nothing to say
> that the pgp module is loaded if the linux module is loaded: it would
> be quite possible to have an image that contains the linux module but
> not the pgp module, and then you have a UEFI Secure Boot bypass just
> by setting check_signatures=1. (Note that the module layout is a bit
> different in 2.04 than in 2.02, which is why it's important to
> prepare this patch against the latest version.)
It is not true because grub_dl_get("verify") in "if" condition checks if
required module was loaded. And before I emailed my patch and said
"tested", I made efforts and *really* tested various cases this
condition should cover, one by one.
Point about code copy is also weak because "verify"/"pgp" module
internally contains this condition code at least in two locations and
sudden change of interpretation for such security variables is a
security risk regardless of anything else.
In fact, even if we export from "verify" module some function which
exposes state of "sec" variable, it still will not guarantee internal
state will be always represented by boolean values of that variable or
those values retain its sense. In some sense, my solution relies on a
public documented interface of that module, while function export
solution relies on internal mechanics of module, requiring additional
hacks to expose it.
> I'm not sure exactly how this should look, but I'm pretty sure that
> it's going to be too hard to get this right in
> grub-core/loader/i386/linux.c, and that it needs to live in
> grub-core/loader/i386/efi/linux.c which has more context about what's
> going on. I think it would help to push the integration with PGP
> signature checking down to grub_linuxefi_secure_validate or somewhere
> near that. That would allow also taking advantage of the kernel's
> UEFI quirks handling in the case where a kernel has been PGP-signed
> (since we'd be able to enter the kernel without calling
> ExitBootServices), and it would allow for less fragile code layout.
If we agree about condition which checks "verify"/"pgp" module state, I
can modify grub_linuxefi_secure_validate to skip validation when PGP is
active same way it does if secureboot is not enabled at all (there are
already some cases when linuxefi skips validation, so it will be
probably ok to keep in one place).
--
Best Regards,
Vladislav Yarmak
Bug#932339: Likely caused by and confined to Lintian
Control: reassign 932339 src:lintian This bug occurs due to a configuration error in Lintian's test in t/tags/checks/systemd/systemd-general. An init file for 'systemd-aliasd' is named d/systemd-aliasd.init (and d/rules attempts to install it via 'dh_installinit --name systemd-aliasd') while, according to the man page for dh_installinit, the file should be named .d/systemd-general.systemd-aliasd.init. The naming error occurred probably because the test builds only one user package. Other files may also need to be renamed. The hanging symptom is likely due to incorrect error handling in t/bin/build-test-packages, which is a part of Lintian. Kind regards Felix
Bug#630123: libio-aio-perl: please split out libeio
tag 630123 + moreinfo thanks Hey, On Sat, 11 Jun 2011 13:20:44 +0200 Alessandro Ghedini wrote: > block 630123 by 629384 > thanks > > On Sat, Jun 11, 2011 at 10:31:34AM +0100, Nicholas Bamber wrote: > > Package: libio-aio-perl > > Severity: wishlist > > > > The libeio library is also used by nodejs. > > I've done the initial packaging of libeio at [0]. Jonas (who also happens to > be one of the nodejs maintainers) seemed interested in sponsoring it, but > I've not heard from him in 4-5 days. I know it's been long since this was open, are you still willing to do the same? Also, if no replies, I plan on closing this in sometime :) Let me know what you think about the same. Best, Utkarsh signature.asc Description: OpenPGP digital signature
Bug#901508: try this
Did you try adding export? > export http_proxy=. > rinse .. -- regards Thomas
Bug#525350: hardcoded s3.amazonaws.com prevents use with walrus
tag 525350 + moreinfo thanks Hey, On Thu, 23 Apr 2009 17:40:52 -0400 Joey Hess wrote: > Package: libnet-amazon-s3-perl > Severity: normal > > s3.amazonaws.com is hardcoded throughout the code. If this were moved to > a single, configurable variable, then it would be possible to use this > library to talk to a s3 compatible server such as walrus > (http://eucalyptus.cs.ucsb.edu/wiki/EucalyptusStorage_v1.4) I think this is covered in the new upstream releases, could you please check back and let me know if this bug is still valid? Best, Utkarsh signature.asc Description: OpenPGP digital signature
Bug#637744: proftpd-mod-ldap: LDAPServer scope doesn't work
On 10.04.17 22:27, Hilmar Preuße wrote: > Am 16.02.2017 um 00:53 tastete Dmitry Katsubo: Hi Dimitry, The proftp 1.3.6 is meanwhile available in Debian stable. Could you confirm that is works as expected? Hilmar >> I think this is about the same matter. If I remember correctly, I have >> originally using "LDAPSearchScope subtree", which at some moment was >> broken >> (bug#500731), and then I tried "LDAPServer ldap://localhost??sub"; >> which also >> didn't work, but after updating to v1.3.2 it worked fine. Then I >> believe it was >> broken again (bug#637744). >> >> Maybe I miss something (quite some time had passed), however I confirm >> that >> "LDAPServer ldap://localhost??sub"; works for me since v1.3.2 up to >> v1.3.5a-1 >> which I am using now. >> >> Do you want to focus on "LDAPSearchScope subtree" issue at the moment? >> Well, I quickly tried >> >> LDAPServer localhost >> LDAPSearchScope subtree >> >> and it seems to work as expected. I cannot be 100% sure, but I'll let one >> know in bugzilla if I find any problem. >> > Thanks for response! > > The upstream bug http://bugs.proftpd.org/show_bug.cgi?id=4289 is now > solved in 1.3.6. Please be so kind to check if that log entry[1] > together w/ the FAQ[2] solves/describes your problem. Currently my > impression is: we have various methods to specify the search scope and > (depending on the used version) some work and some don't. :-( > No, the 1.3.6 is not available in Debian and won't be before the next > release. > -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#692181: libnet-amazon-s3-perl: HTTPRequest.pm incomplete S3 protocol support
tag 692181 + moreinfo
thanks
Hey,
On Fri, 02 Nov 2012 18:31:37 -0700 Erik Anderson
wrote:
> Package: libnet-amazon-s3-perl
> Version: 0.53-1
> Severity: minor
> Tags: patch
>
> As seems to often be the case, attempts to use a library beyond its
stated capabilities results in discoveries of incomplete coding.
>
> I do recognize there is a newer version of this library, however
looking over it appears to indicate similar business rules in this area.
>
> Proposed feature changes to HTTPRequest.pm:
>
> Methods
> Old rule: permits DELETE, GET, HEAD, PUT
> New rule: permits DELETE, GET, HEAD, PUT, POST
>
> Sub-resources
> Old rule: permits one of acl, torrent, location
> New rule: permits one each of acl, lifecycle, location, logging,
notification, partNumber, policy, requestPayment, torrent, uploadId,
uploads, versionId, versioning, versions, website
>
> Sample code:
>
> sub initiateMultipartUpload
> {
> my $path = shift;
> my $newUpload = Net::Amazon::S3::HTTPRequest->new({
> s3 => $s3,
> method => 'POST',
> # $s3->_urlescape escapes dots and slashes, uri_escape_utf8 escapes
slashes. Why?
> path => $config->path . uri_escape_utf8($path, '^A-Za-z0-9\-\._~\x2f')
. '?uploads'
> });
>
> my $newUploadReq = $newUpload->http_request;
> #die $newUploadReq->as_string;
> my $xpc = $s3->_send_request($newUploadReq);
> # Amazon isn't returning a Content-Type for this request, so it likely
won't be parsed for us
> $xpc = $s3->_xpc_of_content($xpc) if ( $xpc && !ref($xpc) );
> return undef unless $xpc && !$s3->_remember_errors($xpc);
>
> my $bucket = $xpc->findvalue("//s3:Bucket");
> my $key = $xpc->findvalue("//s3:Key");
> my $uploadID = $xpc->findvalue("//s3:UploadId");
>
> return {
> bucket => $bucket,
> key => $key,
> upload_id => $uploadID
> };
> }
>
> Please note that perl is not my first language, I would be very
suprised if there were not issues with style or not doing things "the
perl way"
Something tells me that these are already in the upstream now, could you
cross check if this bug is still valid?
Best,
Utkarsh
signature.asc
Description: OpenPGP digital signature
Bug#918506: Issue still present
This issue hit me during the upgrade to Buster. To make it through I temporarily chsh'ed debian-spamd to /bin/sh but this is clearly not ideal. Cheers, -- Ben
Bug#932396: Lutris: Update
Package: lutris Version: 0.5.0.1 Severity: normal Package: wnpp Severity: wishlist * Package name: Lutris * Home page: https://lutris.net/ * License: GPLv3 * Description: (from the website) Lutris is an open gaming platform for Linux. It helps you install and manage your games in a unified interface. Our goal is to support every game which runs on Linux,from native to Windows games (via Wine) to emulators and browser games. Heya, I just wanted to know what is the status of Lutris on Debian. My friend from Lutris development team has asked me to open a new ITP due to the previous one was closed, as it was inactive for a long period of time. Is there a chance or possibility for Lutris to be in any of Debian repos? Your Regards, H. A. Demirok -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lutris depends on: ii cabextract 1.9-1 ii curl 7.64.0-4 ii fluid-soundfont-gs 3.1-5.1 ii gir1.2-gnomedesktop-3.0 3.30.2.1-2 ii gir1.2-gtk-3.0 3.24.5-1 ii gir1.2-notify-0.70.7.7-4 ii gir1.2-webkit2-4.0 2.24.2-1 ii p7zip16.02+dfsg-6 ii psmisc 23.2-1 ii python3 3.7.3-1 ii python3-evdev1.1.2+dfsg-1+b10 ii python3-gi 3.30.4-1 ii python3-pil 5.4.1-2 ii python3-requests 2.21.0-1 ii python3-yaml 3.13-2 ii unzip6.0-23 ii x11-xserver-utils7.7+8 Versions of packages lutris recommends: ii lib32gcc1 1:8.3.0-6 ii libc6-i386 2.28-10 lutris suggests no packages. -- no debconf information
Bug#929848: How is the packaging of pplpy going?
Hi Julien, I pushed it now to https://salsa.debian.org/science-team/pplpy/ Feel free to work on / upload it. Thanks! Tobias On 7/18/19 10:27 AM, Julien Puydt wrote: > Hi, > > how is the packaging of pplpy going? > > I wanted to lend a hand, but didn't find 'pplpy' on salsa. > > Cheers, > > JP
Bug#931739: quassel-core: key too small error after upgrade to buster
I tried to use the instructions here: https://bugs.quassel-irc.org/projects/quassel-irc/wiki/Client-Core_SSL_support but could not get it to work. I ended up having to remove all the /var/lib/quassel/ files and running dpkg-reconfigure quassel-core and manually recreating my accounts but that seems to have fixed it.
Bug#932395: RFS: ipmitool/1.8.18-7
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ipmitool" Package name: ipmitool Version : 1.8.18-7 Upstream Author : Alexander Amelkin URL : https://github.com/ipmitool/ipmitool License : BSD-3-clause Section : utils It builds those binary packages: ipmitool - utility for IPMI control with kernel driver or LAN interface (daemon) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ipmitool Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/ipmitool/ipmitool_1.8.18-7.dsc or from git https://jff.email/cgit/ipmitool.git/?h=release%2Fdebian%2F1.8.18-7 Changes since the last upload: * debian/watch: Use tags instead releases. * Migrate to debhelper 12: - Change debian/compat to 12. - Bump minimum debhelper version in debian/control to >= 12. * Declare compliance with Debian Policy 4.4.0 (No changes needed). * debian/control: Add missing Depend init_system_helpers to fix lintan warning. * New debian/patches/0615-manpage_typo.patch: Fix typos in man pages. * Add DEP 8 smoketest (Closes: #903676). Thanks to "Dann Frazier" . * Remove not longer needed debian/ipmitool.ipmievd.default (Closes: #907832). - New debian/ipmitool.maintscript to remove /etc/default/ipmitool. - Add IPMIEVD_OPTIONS direct into debian/ipmitool.ipmievd.service. The build with sbuild and pdebuild and the tests with Lintain and Piuparts are ok: +--+ | Summary | +--+ Build Architecture: amd64 Build Type: full Build-Space: 131236 Build-Time: 47 Distribution: sid Host Architecture: amd64 Install-Time: 36 Job: /data/entwicklung/linux/debian/ipmitool/ipmitool_1.8.18-7.dsc Lintian: info Machine Architecture: amd64 Package: ipmitool Package-Time: 117 Piuparts: pass Source-Version: 1.8.18-7 Space: 131236 Status: successful Version: 1.8.18-7 Finished at 2019-07-18T18:03:46Z Build needed 00:01:57, 131236k disk space Regards, Jörg Frings-Fürst -- 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#932328: logrotate.timer "breaks" activity report of /etc/cron.daily/exim4-base
On 17.07.19 20:46, Sven Hartge wrote:
> Possible solution (untested): Also create a exim4-base.timer and .service and
> create a Before= dependency on logrotate.service.
I've whipped up a little Proof-of-Concept to test this, available also
at https://salsa.debian.org/hartge-guest/exim4/tree/systemd-timer
I'm testing this right now on two of my systems to see how this behaves,
especially the Before=logrotate.{service,timer} ordering.
Grüße,
Sven.
signature.asc
Description: OpenPGP digital signature
Bug#925059: ITA: rdate -- sets the system's date from a remote host
Package: wnpp Severity: normal I intend to adopt rdate as my first package in debian. Thanks. Thiago Andrade Marques
Bug#891987: fixed in git?
Control: tag -1 pending It seems I filed a sortof duplicate bug, as the transition to build-depends on debhelper-compat (= 12) has already happened in git. What's needed to move this forward? I don't feel strongly about what the dh level we generate, but I'd like to unblock the perl team on uploading dh-make-perl. d
Bug#932394: gcc-defaults-ports: enable riscv64 cross-compilers for arm64
Source: gcc-defaults-ports Version: 1.182.1 Severity: wishlist Tags: patch X-Debbugs-Cc: debian-ri...@lists.debian.org I don't see cross-compilers for riscv64 on an arm64 system (e.g. gcc-riscv64-linux-gnu:arm64). It would be useful to me, at least... I *think* the following patch enables it, but I haven't done a full build to verify. Thanks for considering! live well, vagrant --- rules.orig 2019-07-18 14:48:02.313081245 -0300 +++ rules 2019-07-18 14:49:24.466493017 -0300 @@ -352,7 +352,7 @@ HOST_ARCHS_powerpc = amd64 i386 x32 ppc64el HOST_ARCHS_ppc64 = amd64 i386 x32 ppc64el HOST_ARCHS_ppc64el = amd64 i386 x32 ppc64 -HOST_ARCHS_riscv64 = amd64 i386 x32 +HOST_ARCHS_riscv64 = amd64 arm64 i386 x32 HOST_ARCHS_s390x = amd64 i386 x32 HOST_ARCHS_sh4 = amd64 i386 x32 HOST_ARCHS_sparc64 = amd64 i386 x32 @@ -375,7 +375,7 @@ CROSS_ARCHS = endif else # -ports package -ifneq (,$(filter $(DEB_HOST_ARCH),amd64 i386 x32)) +ifneq (,$(filter $(DEB_HOST_ARCH),amd64 arm64 i386 x32)) CROSS_ARCHS ?= alpha hppa m68k ppc64 riscv64 sh4 sparc64 \ $(if $(filter $(vendor), Ubuntu), mips mipsel mips64el, powerpc) \ $(if $(filter $(DEB_HOST_ARCH), amd64 i386), x32) signature.asc Description: PGP signature
Bug#932375: Re: Bug#932375: UXTerm: reversion of colors won't work
Do you use Gnome with Wayland? I don't know; probably it's still xorg after upgrading from Debian stretch. I'll double-check and post here in short.
Bug#885893: shairport-sync update hangs during service restart
On 31/12/2017 01:16, Thomas wrote:
> I did an update of my Debian/testing machine which still runs with
> _sysvinit_. During this the shairport-sync package was updated to
> 3.1.4-1.
>
> During configuration the daemon had to be restarted which hang
> the update process infinite.
>
> If I killed the shairport-sync process the update process continued but
> left a broken package.
>
> I think the problem is the following:
[snip]
Hi Thomas,
Thanks for your detailed bug report, and sorry that I have not been able
to give it any attention until now. I have prepared a patch which I
think would resolve this issue, but I don't have any Debian systems that
don't use systemd to test with at the moment. Would you mind testing the
following patch for me, please?
diff --git a/debian/shairport-sync.init b/debian/shairport-sync.init
index 17d9be501dbd..1b7aee7fe1a6 100755
--- a/debian/shairport-sync.init
+++ b/debian/shairport-sync.init
@@ -29,7 +29,12 @@ do_start_prepare() {
mkdir $piddir
chown ${USER}: $piddir
fi
+}
+do_start_cmd_override() {
# Add --daemon to the command-line arguments
DAEMON_ARGS="--daemon ${DAEMON_ARGS}"
+
+ # Continue with the standard do_start_cmd() implementation
+ do_start_cmd
}
Thanks,
Chris
--
Chris Boot
bo...@debian.org
signature.asc
Description: OpenPGP digital signature
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Control: tags 930292 - fixed-upstream Control: forwarded 930292 https://github.com/u-fischer/luaotfload/issues/49 Sorry I was wrong. The issue in the upstream is still open as above. Ryutaroh
Bug#932393: spice-html5: Windows guest display is inverted vertically
Package: spice-html5
Version: 0.1.7-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch
Dear Maintainer,
When running a Windows VM using the QXL driver from [1] the display is inverted
and therefore almost unusable.
In Ubuntu, the attached patch was applied to achieve the following:
* d/p/fix-windows-spice-upside-down-bitmaps.patch:
Handle non topdown bitmaps (LP: #1836361)
The Ubuntu bug is
https://bugs.launchpad.net/ubuntu/+source/spice-html5/+bug/1836361
Commit taken from upstream
https://github.com/freedesktop/spice-html5/commit/7ba763feb5322f0c97758070075b60cee5464f47
Thanks for considering the patch.
-- System Information:
Debian Release: buster/sid
APT prefers disco-updates
APT policy: (500, 'disco-updates'), (500, 'disco-security'), (500, 'disco'),
(100, 'disco-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.0.0-20-generic (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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
spice-html5-0.1.7/debian/patches/fix-windows-spice-upside-down-bitmaps.patch
spice-html5-0.1.7/debian/patches/fix-windows-spice-upside-down-bitmaps.patch
---
spice-html5-0.1.7/debian/patches/fix-windows-spice-upside-down-bitmaps.patch
1969-12-31 19:00:00.0 -0500
+++
spice-html5-0.1.7/debian/patches/fix-windows-spice-upside-down-bitmaps.patch
2019-07-12 10:24:36.0 -0400
@@ -0,0 +1,52 @@
+Description: Handle non topdown bitmaps
+ Backport of an upstream patch.
+ .
+ spice-html5 (0.1.7-3ubuntu1) eoan; urgency=medium
+ .
+ * d/p/fix-windows-spice-upside-down-bitmaps.patch:
+ Handle non topdown bitmaps (LP: #1836361)
+
+Origin: upstream,
https://github.com/freedesktop/spice-html5/commit/7ba763feb5322f0c97758070075b60cee5464f47
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1836361
+
+--- spice-html5-0.1.7.orig/bitmap.js
spice-html5-0.1.7/bitmap.js
+@@ -26,25 +26,31 @@
+ function convert_spice_bitmap_to_web(context, spice_bitmap)
+ {
+ var ret;
+-var offset, x;
++var offset, x, src_offset = 0, src_dec = 0;
+ var u8 = new Uint8Array(spice_bitmap.data);
+ if (spice_bitmap.format != SPICE_BITMAP_FMT_32BIT &&
+ spice_bitmap.format != SPICE_BITMAP_FMT_RGBA)
+ return undefined;
+
++if (!(spice_bitmap.flags & SPICE_BITMAP_FLAGS_TOP_DOWN))
++{
++src_offset = (spice_bitmap.y - 1 ) * spice_bitmap.stride;
++src_dec = 2 * spice_bitmap.stride;
++}
++
+ ret = context.createImageData(spice_bitmap.x, spice_bitmap.y);
+-for (offset = 0; offset < (spice_bitmap.y * spice_bitmap.stride); )
+-for (x = 0; x < spice_bitmap.x; x++, offset += 4)
++for (offset = 0; offset < (spice_bitmap.y * spice_bitmap.stride);
src_offset -= src_dec)
++for (x = 0; x < spice_bitmap.x; x++, offset += 4, src_offset += 4)
+ {
+-ret.data[offset + 0 ] = u8[offset + 2];
+-ret.data[offset + 1 ] = u8[offset + 1];
+-ret.data[offset + 2 ] = u8[offset + 0];
++ret.data[offset + 0 ] = u8[src_offset + 2];
++ret.data[offset + 1 ] = u8[src_offset + 1];
++ret.data[offset + 2 ] = u8[src_offset + 0];
+
+ // FIXME - We effectively treat all images as having
SPICE_IMAGE_FLAGS_HIGH_BITS_SET
+ if (spice_bitmap.format == SPICE_BITMAP_FMT_32BIT)
+ ret.data[offset + 3] = 255;
+ else
+-ret.data[offset + 3] = u8[offset];
++ret.data[offset + 3] = u8[src_offset];
+ }
+
+ return ret;
diff -Nru spice-html5-0.1.7/debian/patches/series
spice-html5-0.1.7/debian/patches/series
--- spice-html5-0.1.7/debian/patches/series 2018-08-16 10:14:00.0
-0400
+++ spice-html5-0.1.7/debian/patches/series 2019-07-12 10:24:36.0
-0400
@@ -1,2 +1,3 @@
add-ctrl-alt-del-button.patch
fix-windows-spice-upside-down.patch
+fix-windows-spice-upside-down-bitmaps.patch
Bug#932186: mediawiki2latex depends on cruft package.
Yes I agree removing dependency to texlive-generic-recommended and adding dependency to texlive-plain-generic will fix the problem. There is nothing that needs to be checked, as texlive-generic-recommended is empty except for the dependency to texlive-plain-generic which is available in sid as well as bullseye. So I herewith as Georges to do so. On 7/18/19 2:52 AM, peter green wrote: retitle 932186 mediawiki2latex depends on cruft package. thanks (sorry for screwing up the mail subject) On 16/07/2019 18:48, Dirk Hünniger wrote: I can take care of the issue. There is a list of required LaTeX packages in the INSTALL file in the root directory of the package. Still to do that right and not mess anything up, its better if I do it during my holidays in September. For now I propose to remove the dependency to texlive-generic-recommended and add a dependency to texlive-full. That seems OTT, textlive-generic-reccomended is a transitional package with no content and a dependency on texlive-plain-generic, so changing the dependency to texlive-plain-generic should fix this bug without breaking anything.
Bug#932391: dh-make-elpa: don't use create_compat anymore
Package: dh-make-elpa Version: 0.16 Severity: important The next upload of dh-make-perl will make this method go away. we should should use something like Build-Depends: debhelper-compat (=12) instead. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-make-elpa depends on: ii dh-elpa 1.16 ii dh-make-perl0.106 ii libarray-utils-perl 0.5-1 ii libfile-find-rule-perl 0.34-1 ii libfile-grep-perl 0.02-1 ii libgit-repository-perl 1.323-1 ii libtrycatch-perl1.003002-2+b5 ii perl5.28.1-6 Versions of packages dh-make-elpa recommends: ii devscripts 2.19.5 dh-make-elpa suggests no packages. -- no debconf information
Bug#932390: ITA: rdate -- sets the system's date from a remote host
Package: rdate Severity: normal Package: wnpp Severity: normal I intend to adopt rdate as my first package in debian. Thanks.
Bug#923322: Bug
Nevermind I found it at end of link #2 https://salsa.debian.org/qt-kde-team/kde/plasma-browser-integration/ merge_requests/3 Is ready for review. Scarlett -- Scarlett Gately Moore ( Formerly Clark ) Software engineer @ Blue Systems KDE Developer/Sysadmin Debian Contributor / Developer in training. IRC sgmoore signature.asc Description: This is a digitally signed message part.
Bug#932381: libdbus-1-3: lidbus _dbus_marshal_write_basic uses implementation defined behaviour (unaligned read)
Control: severity -1 normal Control: tags -1 + upstream On Thu, 18 Jul 2019 at 17:15:09 +0200, Witold Baryluk wrote: > In this case, value is often not aligned to native uint64 alignement, > and dereference does lead to a CPU trap on some architectures > and some compilers. Do you have evidence of libdbus accessing misaligned pointers in real use, or is this concern based on compiler warnings or reading the source code? libdbus goes to considerable lengths to ensure that marshalling always acts on correctly aligned pointers, despite appearances to the contrary: the message wire-format is designed to ensure that all values are naturally-aligned, and commit 6327adafe20603fce3c7507e20f300e07398b517 (first released in dbus 1.4.x in 2011) asserts at compile time that this is sufficient to give them their correct alignment. However, it is not immediately obvious to a reader or to the compiler that this is the case, and in particular you'll get compiler warnings when building dbus on strongly-aligned architectures like ARM. > I suggest to change all dereferences to types bigger than 1 byte to > use memcpy I have been meaning to try this for a while (git says my work-in-progress branch is from 2015), but this is hampered by not having a realistic benchmark that can assess whether it improves or reduces performance. > On 32-bit arm, it will pesimize correctly to read and combined aligned > reads (which is in total 3 extra instructions). On architectures like > 32-bit ARM, and Alpha (64-bit), MIPS (both 32 and 64 bit), 32-bit PowerPC > the resulting code with memcpy will in fact be faster than current code, > because it will not trap and emulate read in kernel, which is very slow. If the current code is, in fact, always accessing correctly-aligned pointers (so the trap-and-emulate case is something that could in theory happen, and would be slow if it happened, but is never actually reached), how much of a performance hit is expected for using memcpy and having the pessimized code generated? smcv
Bug#932375: UXTerm: reversion of colors won't work
On 2019-07-18 17:41 +0300, Md Ayquassar wrote: > Package: xterm > Version: 344-1 > By default, the color of a uxterm is black foreground and white background. > However, I'd like to have it reverse: white text on black background. To this > end, I put > > UXTerm*reverseVideo: true > > > into my ~/.Xresources, run xrdb ~/.Xresources, and reboot. I observe > no change: it's still black on white as before. This probably means that your ~/.Xresources file is ignored, i.e. xrdb -merge ~/.Xresources is not run automatically at your session startup. Do you use Gnome with Wayland? It is the default desktop in Debian 10[1], and apparently ignores your ~./Xresources by default[2]. The resource itself is the correct one. When I ran echo 'UXTerm*reverseVideo: true' | xrdb -merge - then uxterm indeed started in reverse video. Cheers, Sven 1. https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.de.html#wayland-by-default-on-gnome 2. https://wiki.debian.org/Wayland#Troubleshooting
Bug#932373: proftpd error reading passphrase for SFTPHostKey
retitle 932373 mod_sftp handling of OpenSSH-specific keys leads to confusing behavior severity 932373 minor forwarded 932373 https://github.com/proftpd/proftpd/issues/793 tags 932373 + upstream stop On 18.07.19 Markus Raps (m.r...@rapsplace.de) wrote: > yes exactly > > rm -f /etc/ssh/ssh_host_* > ssh-keygen -A -m PEM > > fixes the behavior. > Thanks. As we have a work around I mark that bug as minor. Hilmar -- sigfault signature.asc Description: PGP signature
Bug#932389: gnome-sound-recorder crashes when trying to play back a recording
Package: gnome-sound-recorder Version: 3.28.2-1 Severity: important Crashes with: ** (org.gnome.SoundRecorder:12342): CRITICAL **: 19:04:35.810: g_object_info_get_n_fields: assertion 'info != NULL' failed ** Gjs:ERROR:gi/object.cpp:481:bool ObjectInstance::field_getter_impl(JSContext*, JS::HandleObject, JS::HandleString, JS::MutableHandleValue): assertion failed: (field) Playing back a recording is not possible. Pretty embarrassing for a program which has two functions and a default workflow which involves these two functions... -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-sound-recorder depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1 ii gir1.2-glib-2.0 1.58.3-2 ii gir1.2-gst-plugins-base-1.0 1.14.4-2 ii gir1.2-gstreamer-1.0 1.14.4-1 ii gir1.2-gtk-3.0 3.24.5-1 ii gir1.2-pango-1.0 1.42.4-6 ii gjs 1.54.3-1 ii gstreamer1.0-plugins-base1.14.4-2 ii gstreamer1.0-plugins-good1.14.4-1 ii gstreamer1.0-pulseaudio 1.14.4-1 gnome-sound-recorder recommends no packages. gnome-sound-recorder suggests no packages. -- no debconf information
Bug#932388: pure-ftpd-postgresql: Postgresql-based auth fails without error after buster upgrade
Package: pure-ftpd-postgresql Version: 1.0.43-3 Severity: important Dear Maintainer, In stretch I had a working pure-ftpd system with postgresql-based authentication. Passwords were encrypted with crypt. After buster upgrade, authentication fails with no errors in the logs (logs only show authentication failure, even with double verbose flags). Downgrading pure-ftpd-common and pure-ftpd-postgresql to versions in stretch fixes the issue. Various facts: - Postgresql cluster was upgraded to v11 and reindexed. - Queries in postgresql.conf can be manually run on the database without issue. - Postgresql trace shows that all configured queries are successfully running and returning results. - Packages from stretch work fine even with the upgraded Postgresql - Changing the encryption type makes no difference ** contents of /etc/pure-ftpd/db/postgresql.conf: PGSQLServer localhost PGSQLPort 5432 PGSQLUser (redacted) PGSQLPassword (redacted) PGSQLDatabase (redacted) PGSQLCrypt crypt PGSQLGetPW SELECT "passwd" FROM users WHERE "userid"='\L' and not disabled PGSQLGetUID SELECT "uid" FROM users WHERE "userid"='\L' PGSQLGetGID SELECT "gid" FROM users WHERE "userid"='\L' PGSQLGetDir UPDATE users SET last_login=NOW() WHERE userid='\L' RETURNING "homedir"; ** End of /etc/pure-ftpd/db/postgresql.conf -- System Information: Debian Release: 10.0 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pure-ftpd-postgresql depends on: ii libc6 2.28-10 ii libcap2 1:2.25-2 ii libpam0g 1.3.1-5 ii libpq511.4-1 ii libssl1.1 1.1.1c-1 ii lsb-base 10.2019051400 ii openbsd-inetd [inet-superserver] 0.20160825-4 ii pure-ftpd-common 1.0.43-3 ii zlib1g1:1.2.11.dfsg-1 pure-ftpd-postgresql recommends no packages. pure-ftpd-postgresql suggests no packages. -- Configuration Files: /etc/pure-ftpd/db/postgresql.conf [Errno 13] Permission denied: '/etc/pure-ftpd/db/postgresql.conf' -- no debconf information
