Bug#1061591: rhsrvany: tests can fail on ci.debian.net due to wine32 installation
package: src:rhsrvany version: 1.1-2 severity: serious tag: patch runsrvany64 and runpnpwait64 autopkgtests can fail on amd64 on ci.debian.net because of foreign arch wine32 installability issues [0]. This currently prevents wine from migrating to testing [1]. The attached patch solves the problem by removing wine32 install from the scripts. wine32 isn't needed since the tests run correctly on amd64 when wine and wine64 are installed, which is the case for ci.debian.net. Best wishes, Mike [0] https://ci.debian.net/packages/r/rhsrvany/testing/amd64/42392786/ [1] https://qa.debian.org/excuses.php?package=wine --- a/debian/tests/runsrvany64 +++ b/debian/tests/runsrvany64 @@ -1,5 +1,4 @@ #!/bin/sh set -e -dpkg --add-architecture i386 && apt-get update && apt-get -y install wine32 wine /usr/share/virt-tools/rhsrvany.exe install wine /usr/share/virt-tools/rhsrvany.exe uninstall --- a/debian/tests/runpnpwait64 +++ b/debian/tests/runpnpwait64 @@ -1,4 +1,3 @@ #!/bin/sh set -e -dpkg --add-architecture i386 && apt-get update && apt-get -y install wine32 wine /usr/share/virt-tools/pnp_wait.exe
Bug#956181: zlib: provide minizip binary packages
Bastian Germann wrote:
> Mark has stated on https://github.com/madler/zlib/issues/742 that
> he will not be working on this.
I am willing to volunteer as zlib co-maintainer focusing solely on
minizip so that Mark need do no work related to it.
> Mark, are you aware that this has a patch already?
I updated the minizip patch to apply to zlib 1.2.13 (from previously
1.2.11), attached below. What do you think?
Best wishes,
Mike
diff -Nru zlib-1.2.13.dfsg/debian/changelog zlib-1.2.13.dfsg/debian/changelog
--- zlib-1.2.13.dfsg/debian/changelog 2022-11-05 12:24:46.0 +
+++ zlib-1.2.13.dfsg/debian/changelog 2023-08-02 01:30:53.0 +
@@ -1,3 +1,9 @@
+zlib (1:1.2.13.dfsg-1.1) UNRELEASED; urgency=medium
+
+ * Build minizip packages.
+
+ -- Michael Gilbert Wed, 02 Aug 2023 01:30:53 +
+
zlib (1:1.2.13.dfsg-1) unstable; urgency=low
* New upstream release.
diff -Nru zlib-1.2.13.dfsg/debian/control zlib-1.2.13.dfsg/debian/control
--- zlib-1.2.13.dfsg/debian/control 2022-11-05 12:24:46.0 +
+++ zlib-1.2.13.dfsg/debian/control 2023-08-02 01:30:53.0 +
@@ -4,7 +4,7 @@
Maintainer: Mark Brown
Standards-Version: 4.6.1
Homepage: http://zlib.net/
-Build-Depends: debhelper (>= 13), gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 sparc s390x mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64 mips64el mips64r6 mips64r6el x32] , dpkg-dev (>= 1.16.1)
+Build-Depends: debhelper (>= 13), gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 sparc s390x mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64 mips64el mips64r6 mips64r6el x32] , dpkg-dev (>= 1.16.1), autoconf
Package: zlib1g
Architecture: any
@@ -118,3 +118,50 @@
This package should ONLY be used for building packages, users who do
not need to build packages should use multiarch to install the relevant
runtime.
+
+Package: minizip
+Section: utils
+Architecture: any
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Replaces:
+ zlib-bin,
+Conflicts:
+ zlib-bin,
+Description: compression library - minizip tools
+ minizip is a minimalistic library that supports compressing, extracting,
+ viewing, and manipulating zip files.
+ .
+ This package includes the minizip and miniunzip tools.
+
+Package: libminizip1
+Architecture: any
+Multi-Arch: same
+Pre-Depends:
+ ${misc:Pre-Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Description: compression library - minizip library
+ minizip is a minimalistic library that supports compressing, extracting,
+ viewing, and manipulating zip files.
+ .
+ This package includes the minizip library.
+
+Package: libminizip-dev
+Architecture: any
+Multi-Arch: same
+Section: libdevel
+Depends:
+ ${misc:Depends},
+ libminizip1 (= ${binary:Version})
+Replaces:
+ libkml-dev (<< 1.3.0~r864+git20150723-0fa2f22-1~),
+Breaks:
+ libkml-dev (<< 1.3.0~r864+git20150723-0fa2f22-1~),
+Description: compression library - minizip development files
+ minizip is a minimalistic library that supports compressing, extracting,
+ viewing, and manipulating zip files.
+ .
+ This package includes development support files for the minizip library.
diff -Nru zlib-1.2.13.dfsg/debian/libminizip-dev.install zlib-1.2.13.dfsg/debian/libminizip-dev.install
--- zlib-1.2.13.dfsg/debian/libminizip-dev.install 1970-01-01 00:00:00.0 +
+++ zlib-1.2.13.dfsg/debian/libminizip-dev.install 2023-08-02 01:29:43.0 +
@@ -0,0 +1,4 @@
+usr/include/minizip
+usr/lib/*/libminizip.a
+usr/lib/*/libminizip.so
+usr/lib/*/pkgconfig/minizip.pc
diff -Nru zlib-1.2.13.dfsg/debian/libminizip1.install zlib-1.2.13.dfsg/debian/libminizip1.install
--- zlib-1.2.13.dfsg/debian/libminizip1.install 1970-01-01 00:00:00.0 +
+++ zlib-1.2.13.dfsg/debian/libminizip1.install 2023-08-02 01:29:43.0 +
@@ -0,0 +1 @@
+usr/lib/*/libminizip.so.*
diff -Nru zlib-1.2.13.dfsg/debian/libminizip1.symbols zlib-1.2.13.dfsg/debian/libminizip1.symbols
--- zlib-1.2.13.dfsg/debian/libminizip1.symbols 1970-01-01 00:00:00.0 +
+++ zlib-1.2.13.dfsg/debian/libminizip1.symbols 2023-08-02 01:30:53.0 +
@@ -0,0 +1,62 @@
+libminizip.so.1 libminizip1
+ call_zopen64@Base 1.1
+ call_zseek64@Base 1.1
+ call_ztell64@Base 1.1
+ fill_fopen64_filefunc@Base 1.1
+ fill_fopen_filefunc@Base 1.1
+ fill_zlib_filefunc64_32_def_from_filefunc32@Base 1.1
+ unzClose@Base 1.1
+ unzCloseCurrentFile@Base 1.1
+ unzGetCurrentFileInfo64@Base 1.1
+ unzGetCurrentFileInfo@Base 1.1
+ unzGetCurrentFileZStreamPos64@Base 1.1
+ unzGetFilePos64@Base 1.1
+ unzGetFilePos@Base 1.1
+ unzGetGlobalComment@Base 1.1
+ unzGetGlobalInfo64@Base 1.1
+ unzGetGlobalInfo@Base 1.1
+ unzGetLocalExtrafield@Base 1.1
+ unzGetOffset64@Base 1.1
+ unzGetOffset@Base 1.1
+ unzGoToFilePos64@Base 1.1
+ unzGoToFilePos@Base 1.1
+ unzGoToFirstFile@Base 1.1
+ unzGoToNextFile@Base 1.1
+ unzLocateFile@Base 1.1
+ unzOpen2@Base 1.1
+ unzOpen2_64@Base 1.1
+ unzO
Bug#1031655: Lutris: wine build does not support Esync/Fsync
control: severity -1 normal control: reassign -1 src:lutris Bernhard Übelacker wrote: > It looks like Lutris extracts the version > from the path the wine executable was found. Lutris parses version information from "wine --version" to conclude whether features are supported [0]. The wine in debian outputs package version detail, which lutris does not currently ignore and concludes that the version is not in its known good set (i.e. does not support particular features). Lutris needs to be updated to ignore the extra package details returned by the debian wine package. Best wishes, Mike [0] https://github.com/lutris/lutris/blob/v0.5.12/lutris/util/wine/wine.py#L274
Bug#1031573: RM: jthread -- ROM; abandoned upstream, unmaintained
package: ftp.debian.org severity: normal user: ftp.debian@packages.debian.org usertags: remove Please remove src:jthread from bookworm and sid. It no longer has reverse dependencies and is abandoned upstream. It has release critical bug #1031253 that I plan to not fix. Best wishes, Mike
Bug#1013082: wine: CombineZP doesn't display a picture
Günter Frenz wrote: > version 6.18~repack-1 is the last working version. When comparing this > to the current version 7.0, I noticed an error message in CombineZP > saying "CreateCompatibleBitmap failed", maybe this helps too. Bitmap handling was moved from dlls/gdi32 to dlls/win32u between 6.18 and 6.19 (commit 08f677ca). There was also refactoring related to bitmap memory allocation, which may be relevant (commit 6ea18f66). That should be a start to begin working out which commit caused the problem. Best wishes, Mike
Bug#1013082: wine: CombineZP doesn't display a picture
control: tag -1 moreinfo Günter Frenz wrote: > I'm using CombineZP (https://combinezp.software.informer.com/1.0/) with wine. > Since the > latest update the pictures are no longer displayed. Are you saying it worked correctly with wine 6.0.3~repack-1? If so, are you able to test the 6.x wine-development packages from snapshot.debian.org [0] to determine when the regression began? Best wishes, Mike [0] https://snapshot.debian.org/package/wine-development/
Bug#1011430: RM: vkd3d [s390x] -- ROM; tests fail on s390x, not yet intended to be supported in a stable release
package: ftp.debian.org severity: normal Please remove vkd3d binaries from s390x (testing only). s390x is not yet a supported architecture upstream and autopkg tests currently fail for that architecture. See #1010331. Best wishes, Mike
Bug#986456: chromium: Could not unzip extension on armhf
control: severity -1 minor control: forwarded -1 http://crbug.com/1060925 Daniel Thompson wrote: > 1. Install chromium > 2. Navigate to https://chrome.google.com/webstore > 3. Try to install an extension (I tested primarily with bitwarden >but I also checked a couple of "random" ones from the suggestions >list (Zoom, Dark Mode, Visor and saw the same results). > 4. Chromium reports "An error has occured: Could not unzip extension". Could you try a version of chromium before 67? This may be a known upstream bug [0]. Best wishes, Mike [0] http://crbug.com/1060925
Bug#980020: chromium: "undefined command" when printing to postscript printer
control: tag -1 moreinfo control: severity -1 minor Karl O. Pinc wrote: > Package: chromium > Version: 87.0.4280.88-0.4~deb10u1 > Severity: normal > > I find that trying to print to a postscript printer with chromium > prints instead: > > ERROR NAME; >undefined > COMMAND; >Invalid > OPERAND STACK; > > This did not always happen, but seems to be due to a security update. Are the latest chromium stable updates affected by this? The 87.0.4280.88-0.4~deb10u1 security upload was built incorrectly. Best wishes, Mike
Bug#988246: wine-development: not intended for a stable release
package: src:wine-development severity: serious This package is not intended to be released in a debian stable release. This bug serves to prevent migration of the package to testing. Best wishes, Mike
Bug#973240: chromium: APNGs flicker
control: severity -1 minor control: forwarded -1 http://crbug.com/1142228 control: retitle -1 chromium: APNGs flicker when built with system libpng This is only a problem when chromium is built using the libpng shared system library. Best wishes, Mike
Bug#982275: debianutils: add-shell depends on non-essential package
On Sat, Feb 13, 2021 at 5:01 AM Andreas Henriksson wrote: > > For systems where awk is not yet installed (chroots), installation of > > dash will currently fail since it's postinst calls add-shell from > > debianutils. > > Please share details about how to reproduce this situation! > > You say you don't have awk when dash postinst runs, but that would also > mean you don't have base-files (since it pre-depends on awk), which > means you're lacking essential packages while you're configuring > dash! > > Sounds to me like you're doing something very peculiar and likely > completely unsupported to be able to trigger this issue. Atleast I can't > think of any obvious way how to trigger it. Yes, I am doing something quite peculiar. I am trying to install the absolute minimal system possible, just enough to be able to run a shell (dash). In fact without even base-files. # mmdebstrap --verbose --variant=custom --include=sed,grep,libc-bin,dash,diffutils,coreutils unstable unstable [...] /usr/sbin/add-shell: 20: awk: not found Either another instance of /usr/sbin/add-shell is running, or it was previously interrupted. Please examine /etc/shells.tmp to see if it should be moved onto /etc/shells. dpkg: error processing package dash (--install): installed dash package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: dash I can add mawk to the list of packages to make it work, but that isn't quite so minimal ;) # mmdebstrap --verbose --variant=custom --include=sed,mawk,grep,libc-bin,dash,diffutils,coreutils unstable unstable > Replacing using awk with cat whenever possible sounds like a good thing > to do, so for the record I'm not against that. My skepticism is more > at why this is not a wishlist bug report (that would be much better to > adress early in a development cycle, rather than when we're already in > the bullseye freeze). Given the peculiarity and simple work around, I am ok with any severity. Best wishes, Mike
Bug#963176: Additional information.
control: tag -1 -moreinfo control: severity -1 minor control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=39439 On Mon, Jun 22, 2020 at 12:54 AM Gong S. wrote: > 10538.908:000a:000b:exception c005 in PE entry point > (proc=0x7b02d8c0,module=0x7b00,reason=PROCESS_ATTACH,res=0x32fb00) This error probably indicates that your wine installation path is mounted noexec. https://forum.winehq.org/viewtopic.php?t=2112 https://forum.winehq.org/viewtopic.php?t=7209 https://forum.winehq.org/viewtopic.php?f=2&t=20562 https://forum.endeavouros.com/t/setting-noexec-nodev-nosuid-mount-parameters-for-home-partition/7618 https://github.com/dnschneid/crouton/issues/528 Best wishes, Mike
Bug#982275: debianutils: add-shell depends on non-essential package
package: src:debianutils
severity: serious
version: 4.11.2
tag: patch
debianutil's add-shell script uses awk, but awk is not an
Essential:yes package. For systems where awk is not yet installed
(chroots), installation of dash will currently fail since it's
postinst calls add-shell from debianutils.
A simple fix seems possible, just change add-shell to use cat, which
is in coreutils (Essential:yes). Proposed update attached.
Best wishes,
Mike
--- debianutils-4.11.2/add-shell 2020-05-22 20:00:40.0 -0400
+++ debianutils-4.11.3/add-shell 2021-02-07 21:47:27.0 -0500
@@ -17,7 +17,7 @@
}
trap cleanup EXIT
-if ! awk '{print}' "$file" > "$tmpfile"
+if ! cat "$file" > "$tmpfile"
then
cat 1>&2 <
Bug#982062: chromium: Google is limiting private api availability for all chromium builds
control: severity -1 minor On Sat, Feb 6, 2021 at 3:09 AM jim_p wrote: > This means that sync and some other features will stop working from that day > on > and users that use them will complain and file bug reports. None of this is relevant to running chromium as a web browser, which is its intended purpose. Best wishes, Mike
Bug#969557: chromium: "clear browsing data" never completes
On Fri, Sep 4, 2020 at 4:57 PM Rory Campbell-Lange wrote: > Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Chromium on tainted kernels is not supported. Best wishes, Mike
Bug#972134: chromium: please, consider moving the package to team-maintainance to properly maintain it
On Tue, Dec 22, 2020 at 3:45 AM Michel Le Bihan wrote: > I my NMU 87.0.4280.88-0.2 has just been uploaded to unstable and I'm > interested in joining and helping with the package. My work is in > https://salsa.debian.org/mimi8/chromium/ . Please also see the > discussion under > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973848 . Hi Michel, Thank you for helping out with the package over the past couple months. Clearly I have not had time lately. I just added you to the salsa group. Please feel free to add yourself as an uploader. Best wishes, Mike
Bug#964177: chromium: high cpu load and frequent crashes
On Fri, Jul 3, 2020 at 3:39 AM Alexis Huxley wrote: > I've got Debian 10 and apply nightly updates as they become > available. I was running chromium version 80.0.3987.162 but > that was upgraded to 83.0.4103.116 a couple of nights ago. Since > then CPU load at page load time is very high, the interface is > generally sluggish and it crashes several times per day. The latest buster version was mistakenly built without optimization. I am working on an update. Best wishes, Mike
Bug#963176: Additional information.
On Mon, Jun 22, 2020 at 12:54 AM Gong S. wrote: > The output is attached. Based on the trace, one of the places wine finds kernelbase.dll on your system is Z:\\usr\\home\\root\\kernelbase.dll. Could this be an out of date version of the dll? > I also used the root account with no ".wine" directory, so it should be > considered clean. It's not a great idea to run wine as root. Best wishes, Mike
Bug#956499: MESA-LOADER: failed to open i915
On Sun, Apr 12, 2020 at 12:18 AM 積丹尼 Dan Jacobson wrote:
> I'm now seeing
>
> MESA-LOADER: failed to retrieve device information
> MESA-LOADER: failed to open i915 (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri) failed to load
> driver: i915
> MESA-LOADER: failed to open kms_swrast (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri) failed to load
> driver: kms_swrast
> MESA-LOADER: failed to open swrast (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri) failed to load
> swrast driver
These messages are output by mesa, so this is most likely a problem
with support for your hardware.
Best wishes,
Mike
Bug#963548: Received signal 11 SEGV_MAPERR
control: tag -1 moreinfo On Tue, Jun 23, 2020 at 10:27 AM 積丹尼 Dan Jacobson wrote: > Received signal 11 SEGV_MAPERR 7f0168b7a277 > #0 0x55e2011c3bf9 (/usr/lib/chromium/chromium+0x52b3bf8) > #1 0x55e201122e83 (/usr/lib/chromium/chromium+0x5212e82) > #2 0x55e2011c3781 (/usr/lib/chromium/chromium+0x52b3780) > #3 0x7f168c517110 (/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f) > #4 0x7f16877e8d3c (/lib/x86_64-linux-gnu/libc-2.30.so+0x85d3b) > #5 0x7f16877eaf33 (/lib/x86_64-linux-gnu/libc-2.30.so+0x87f32) > #6 0x7f16877ecbf9 __libc_malloc > #7 0x55e2011db94e operator new() > #8 0x7f1687a73a2c std::__cxx11::basic_string<>::reserve() > #9 0x7f1687a69498 std::__cxx11::basic_stringbuf<>::overflow() > #10 0x7f1687a7204a std::basic_streambuf<>::xsputn() > #11 0x7f1687a64714 std::__ostream_insert<>() > #12 0x55e2011c3cc9 (/usr/lib/chromium/chromium+0x52b3cc8) > ... > #46 0x7f168b2cd24f event_base_loop > #47 0x55e2011e1421 (/usr/lib/chromium/chromium+0x52d1420) > ... > #53 0x7f168c50bf27 start_thread > #54 0x7f168786031f clone Please attach a backtrace and the standard info that reportbug generates. Otherwise, this kind of report is not particularly useful. Best wishes, Mike
Bug#963176: Unable to run any programs due to kernelbase.dll failed to initialize.
control: tag -1 moreinfo control: severity -1 important On Fri, Jun 19, 2020 at 11:09 PM Gong S. wrote: > The current version of wine-development cannot launch any Windows programs, > including built-in ones like "winecfg" and "wineconsole". I am not able to reproduce this on i386. Is this on an arm system? Either way, can you provide relevant output from $ WINEDEBUG=+all winecfg-development Best wishes, Mike
Bug#962481: Printing to PDF makes files twenty million times bigger
control: severity -1 minor control: forwarded -1 http://crbug.com/1087707 control: retitle -1 print to pdf font subsetting issue I am not able to reproduce this with 81.0.4044.92-1 following the instructions in comment #13 from the upstream bug report. I get a 500K pdf file with only DejaVuSans,DejaVuSansMono embedded, not WenQuanYiZenHei,WenQuanYiZenHeiMono. Is there anything else about your configuration that would be relevant? Best wishes, Mike
Bug#963080: chromium dies in libva
control: severity -1 important On Thu, Jun 18, 2020 at 12:48 PM Harald Dunkel wrote: > libva-x11-2 is version 2.7.1-1. nvidia-graphics-drivers is version 440.82-2. > I cannot reproduce this using google-chrome 83.0.4103.106-1. This is caused by ffmpeg 4.3, see #963035. Best wishes, Mike
Bug#958103: chromium: Non-editable shortcuts on the new tab page
control: tag -1 moreinfo control: severity -1 minor On Sat, Apr 18, 2020 at 9:30 AM jim_p wrote: > I found it yesterday, when I made a new shortcut using the plus (+) icon > there. > I spelled something wrong and now I can not edit it nor remove it :D I just tested this, and it works for me. I created a new shortcut, then clicked the ... menu overlaying the top right of the shortcut icon, then clicked the Remove button in the dialog that popped up. This behaved exactly as expected, the shortcut was removed. Best wishes, Mike
Bug#956499: MESA-LOADER: failed to open i915
control: tag -1 moreinfo
On Sun, Apr 12, 2020 at 12:18 AM Dan Jacobson wrote:
> MESA-LOADER: failed to retrieve device information
> MESA-LOADER: failed to open i915 (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri) failed to load
> driver: i915
Do you have the libgl1-mesa-dri package installed? chromium already
recommends this.
Best wishes,
Mike
Bug#956181: zlib: provide minizip binary packages
package: src:zlib
severity: wishlist
tags: patch
I've been maintaining minizip as a separate source package for the
last few years. It has become clear that the version included in
zlib/contrib is a more definitive upstream (zlib upstream has done
updates in recent years, minizip upstream has not), so it would make
more sense to provide minizip as part of src:zlib [0].
A few years ago, you were concerned about minizip's ABI changing too
much [1]. That does not seem to have happened. I diffed minizip 1.1
with the version in zlib/contrib. The meaningful changes are small
and there is no ABI difference.
Anyway, here is a patch for src:zlib that adds minizip binary
packages. Please let me know what you think.
Best wishes,
Mike
[0] http://bugs.debian.org/843617
[1] http://bugs.debian.org/574978
diff -Nru zlib-1.2.11.dfsg/debian/changelog zlib-1.2.11.dfsg/debian/changelog
--- zlib-1.2.11.dfsg/debian/changelog 2020-02-24 16:07:12.0 -0500
+++ zlib-1.2.11.dfsg/debian/changelog 2020-04-07 21:50:15.0 -0400
@@ -1,3 +1,9 @@
+zlib (1:1.2.11.dfsg-2.1) UNRELEASED; urgency=medium
+
+ * Build minizip packages.
+
+ -- Michael Gilbert Wed, 08 Apr 2020 01:50:15 +
+
zlib (1:1.2.11.dfsg-2) unstable; urgency=low
* Acknowledge previous NMUs (closes: #949388).
diff -Nru zlib-1.2.11.dfsg/debian/control zlib-1.2.11.dfsg/debian/control
--- zlib-1.2.11.dfsg/debian/control 2020-02-24 16:07:12.0 -0500
+++ zlib-1.2.11.dfsg/debian/control 2020-04-07 21:50:15.0 -0400
@@ -4,7 +4,7 @@
Maintainer: Mark Brown
Standards-Version: 3.9.8
Homepage: http://zlib.net/
-Build-Depends: debhelper (>= 8.1.3~), gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 sparc s390x mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64 mips64el mips64r6 mips64r6el x32] , dpkg-dev (>= 1.16.1)
+Build-Depends: debhelper (>= 8.1.3~), gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 sparc s390x mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64 mips64el mips64r6 mips64r6el x32] , dpkg-dev (>= 1.16.1), autoconf
Package: zlib1g
Architecture: any
@@ -118,3 +118,50 @@
This package should ONLY be used for building packages, users who do
not need to build packages should use multiarch to install the relevant
runtime.
+
+Package: minizip
+Section: utils
+Architecture: any
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Replaces:
+ zlib-bin,
+Conflicts:
+ zlib-bin,
+Description: compression library - minizip tools
+ minizip is a minimalistic library that supports compressing, extracting,
+ viewing, and manipulating zip files.
+ .
+ This package includes the minizip and miniunzip tools.
+
+Package: libminizip1
+Architecture: any
+Multi-Arch: same
+Pre-Depends:
+ ${misc:Pre-Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Description: compression library - minizip library
+ minizip is a minimalistic library that supports compressing, extracting,
+ viewing, and manipulating zip files.
+ .
+ This package includes the minizip library.
+
+Package: libminizip-dev
+Architecture: any
+Multi-Arch: same
+Section: libdevel
+Depends:
+ ${misc:Depends},
+ libminizip1 (= ${binary:Version})
+Replaces:
+ libkml-dev (<< 1.3.0~r864+git20150723-0fa2f22-1~),
+Breaks:
+ libkml-dev (<< 1.3.0~r864+git20150723-0fa2f22-1~),
+Description: compression library - minizip development files
+ minizip is a minimalistic library that supports compressing, extracting,
+ viewing, and manipulating zip files.
+ .
+ This package includes development support files for the minizip library.
diff -Nru zlib-1.2.11.dfsg/debian/libminizip-dev.install zlib-1.2.11.dfsg/debian/libminizip-dev.install
--- zlib-1.2.11.dfsg/debian/libminizip-dev.install 1969-12-31 19:00:00.0 -0500
+++ zlib-1.2.11.dfsg/debian/libminizip-dev.install 2020-04-07 21:50:15.0 -0400
@@ -0,0 +1,4 @@
+usr/include/minizip
+usr/lib/*/libminizip.a
+usr/lib/*/libminizip.so
+usr/lib/*/pkgconfig/minizip.pc
diff -Nru zlib-1.2.11.dfsg/debian/libminizip1.install zlib-1.2.11.dfsg/debian/libminizip1.install
--- zlib-1.2.11.dfsg/debian/libminizip1.install 1969-12-31 19:00:00.0 -0500
+++ zlib-1.2.11.dfsg/debian/libminizip1.install 2020-04-07 21:50:15.0 -0400
@@ -0,0 +1 @@
+usr/lib/*/libminizip.so.*
diff -Nru zlib-1.2.11.dfsg/debian/libminizip1.symbols zlib-1.2.11.dfsg/debian/libminizip1.symbols
--- zlib-1.2.11.dfsg/debian/libminizip1.symbols 1969-12-31 19:00:00.0 -0500
+++ zlib-1.2.11.dfsg/debian/libminizip1.symbols 2020-04-07 21:50:15.0 -0400
@@ -0,0 +1,68 @@
+libminizip.so.1 libminizip1 #MINVER#
+ LoadCentralDirectoryRecord@Base 1.1
+ Write_EndOfCentralDirectoryRecord@Base 1.1
+ Write_GlobalComment@Base 1.1
+ Write_LocalFileHeader@Base 1.1
+ Write_Zip64EndOfCentralDirectoryLocator@Base 1.1
+ Write_Zip64EndOfCentralDirectoryRecord@Base 1.1
+ call_zopen64@Base 1.1
+ call_zseek64@Base 1.1
+ call_ztell64@Base 1.1
+ fill_fopen64_filefunc@Base
Bug#955690: wine-development: FTBFS: configure: error: MinGW compiler not found, cross-compiling PE files won't be supported.
On Fri, Apr 3, 2020 at 5:28 PM Stephen Kitt wrote: > Thanks for the report, the package is missing a build-dependency on > gcc-mingw-w64-x86-64. There is more to it than this. I am working on it now. > Michael, I can take care of fixing this, doing a rebuild to make sure and > uploading, if you could push your git repo ;-). Done. Best wishes, Mike
Bug#955540: chromium: Using ozone
control: tag -1 help On Thu, Apr 2, 2020 at 5:15 AM Bastian Germann wrote: > This requires chromium to build with the ozone interface in the > first place. Would it be possible to switch to using that (with the X11 > backend)? Would you take patches for it? Yes. Best wishes, Mike
Bug#953982: wine-development: wine in Debian fails to start "Uru", but upstream wine works fine (regression)
On Thu, Mar 19, 2020 at 8:28 AM Diafero wrote: > Version 5.0-3 also seems affected. Was the version that worked 4.21-1 or 4.21-2? Best wishes, Mike
Bug#953982: wine-development: wine in Debian fails to start "Uru", but upstream wine works fine (regression)
control: tag -1 moreinfo control: severity -1 minor On Sun, Mar 15, 2020 at 7:21 AM Diafero wrote: > But with recent versions (I tried 5.1 and 5.2) Could you test whether wine 5.0-3 (not wine-development) works or not? This will help determine which patches are most likely the problem. Best wishes, Mike
Bug#942962: chromium: Python2 removal in sid/bullseye
user debian-pyt...@lists.debian.org usertags 942962 py2keep usertags 942962 py3noport thanks
Bug#951915: wine32: Nearly impossible to install the package
control: tag -1 moreinfo On Sat, Feb 22, 2020 at 9:57 PM Jean-Philippe MENGUAL wrote: > 10 dependencies do not want to install: the install tries to replace > the /usr/share/doc/package directory, to change the changelog.Debian.gz > and, of course, refuses. I guess changelog.Debian.gz is different > between i386 and amd64. This should only be a problem if the i386 and amd64 packages have different version numbers [0]. For the packages you list, this is currently not the case for bullseye. I suppose this could be caused if the files in doc on your system had been modified from the as-shipped files from the original packages. > An alternate idea? Should I reportbug to each of these packages? On my system, there is no i386/amd64 mismatch with the packages you list. It is more likely a problem with your system, so please try to debug it first. Best wishes, Mike [0] http://bugs.debian.org/758616
Bug#951507: wine: please fix arm64 build failure with some gcc versions
control: retitle -1 wine: fails to build with clang 9 on arm64 On Mon, Feb 17, 2020 at 10:54 AM Gianfranco Costamagna wrote: > Hello, looks like wine is still failing on Ubuntu arm64, probably because of > new gcc or new glibc, or a combo of them both... The difference is that clang 9 is ubuntu's default and debian's default is clang 8. Best wishes, Mike
Bug#949246: wine32:i386: Running Fallout 1 or 2 under Wine 5.0~rc2-1 fullscreen results in black image [regression]
On Sat, Jan 18, 2020 at 11:05 PM Matti Hämäläinen wrote: > > On Sat, Jan 18, 2020 at 3:35 PM Matti Hamalainen wrote: > >> "virtual desktop" works, but is not a feasible option as on a 2560x1440 > >> screen > >> a 640x480 resolution game will be minuscule. > > > > winecfg can be used to change dimensions of the virtual desktop. > > True, but that does not make it actual fullscreen, and the game changes > the "virtual desktop" size anyway, because it has no windowed mode. A lower resolution mode of your monitor could be used before starting the game, but yes none of this is a solution. > >> Kernel: Linux 5.4.12-qcmm (SMP w/8 CPU cores) > > > > Can this be reproduced with a vanilla debian kernel? > > Yes. Exactly same symptom on linux-image-5.4.0-2-amd64 Please submit an upstream report [0]. The packages from snapshots could be used to determine which version introduced the problem [1]. Best wishes, Mike [0] https://bugs.winehq.org [1] https://snapshot.debian.org/package/wine-development
Bug#949246: wine32:i386: Running Fallout 1 or 2 under Wine 5.0~rc2-1 fullscreen results in black image [regression]
control: tag -1 moreinfo control: severity -1 minor On Sat, Jan 18, 2020 at 3:35 PM Matti Hamalainen wrote: > "virtual desktop" works, but is not a feasible option as on a 2560x1440 screen > a 640x480 resolution game will be minuscule. winecfg can be used to change dimensions of the virtual desktop. > Kernel: Linux 5.4.12-qcmm (SMP w/8 CPU cores) Can this be reproduced with a vanilla debian kernel? Best wishes, Mike
Bug#943563: chromium crash when trying to check error status after invalidateing framebuffer in WebGL
control: tag -1 moreinfo On Sat, Oct 26, 2019 at 10:48 AM Witold Baryluk wrote: > Thread 20 "Chrome_InProcGp" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffaa7fc700 (LWP 32634)] > 0x7fff770d9c37 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > (gdb) bt > #0 0x7fff770d9c37 in () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > #1 0x7fff76f76409 in () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > #2 0x59e1d3b1 in > gpu::gles2::GLES2DecoderImpl::InvalidateFramebufferImpl(unsigned int, int, > unsigned int const volatile*, int, int, int, int, char const*, > gpu::gles2::GLES2DecoderImpl::FramebufferOperation) () > #3 0x59e2030a in > gpu::gles2::GLES2DecoderImpl::HandleInvalidateFramebufferImmediate(unsigned > int, void const volatile*) () > #4 0x59dfa261 in gpu::error::Error > gpu::gles2::GLES2DecoderImpl::DoCommandsImpl(unsigned int, void const > volatile*, int, int*) () This looks like an error in the RadeonSI driver. Could you try installing libgl1-mesa-dri-dbgsym to fill in the ?? in the backtrace? Best wishes, Mike
Bug#935753: FATAL:memory_linux.cc Out of memory
control: tag -1 moreinfo > #4 0x58e64e4d in base::(anonymous > namespace)::OnNoMemorySize(unsigned long) [clone .constprop.237] () > #5 0x58ef0c85 in calloc () > #6 0x7fffaa96c7e9 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so > #7 0x7fffaa45f4b9 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so > #8 0x7fffaa4cd4b4 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so > #9 0x7fffd87ca1b5 in ?? () from > /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 > #10 0x7fffd87b6ec9 in ?? () from > /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 > #11 0x7fffd87b2a64 in ?? () from > /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 > #12 0x7fffd87b2fde in ?? () from > /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 > #13 0x5981d413 in > gl::RealGLXApi::glXQueryExtensionsStringFn(_XDisplay*, int) () [...] > ii libgl1-mesa-dri19.2.0~rc1-1 I wasn't able to reproduce your problem by upgrading packages to experimental. However, given /usr/lib/x86_64-linux-gnu/dri/i965_dri.so is involved in the backtrace, mesa 19.2.0~rc1 from experimental is most likely the cause. Since I couldn't reproduce it on my system, it is probably specific to your hardware. Could you try updating all of your mesa packages back to experimental and try again? Please also install libgl1-mesa-dri-dbgsym beforehand so we can see what is going on in the ?? parts of the backtrace. Best wishes, Mike
Bug#935753: FATAL:memory_linux.cc Out of memory
control: reopen -1 control: tag -1 - moreinfo On Sat, Aug 31, 2019 at 9:57 AM Dan Jacobson wrote: > > MG> Could you try this again without packages from experimental? I assume > MG> its caused by the update to libc6 2.29? > > Some other one. So now I use pure sid. Problem solved. Can you figure out which library it was? A serious bug needs to be filed against it. Best wishes, Mike
Bug#935753: FATAL:memory_linux.cc Out of memory
control: tag -1 moreinfo On Sun, Aug 25, 2019 at 4:36 PM Dan Jacobson wrote: > Versions of packages chromium depends on: [...] > ii libatk1.0-0 2.33.3+really2.33.3-1 [...] > ii libc62.29-0experimental1 [...] > ii libjpeg62-turbo 1:2.0.2-1~exp2 Could you try this again without packages from experimental? I assume its caused by the update to libc6 2.29? Best wishes, Mike
Bug#922431: Upstream is confused about Tracing consisting on non-source JS
On Wed, Jul 31, 2019 at 9:45 AM Sascha Wolke wrote: > @mike: If any help to find the sources is required, just name them and i > am going to find them. The sourceless files are in third_party/catapult/tracing, which is now stripped out of the debian source package. Best wishes, Mike
Bug#932678: glib2.0: tests timeout on i386 and mips
package: src:glib2.0 severity: serious version: 2.60.5-1 The latest glib2.0 upload fails to build on i386 and mips [0]. On i386, the gmenumodel test timed out. On mips, the gvariant test timed out. Best wishes, Mike [0] https://buildd.debian.org/status/package.php?p=glib2.0
Bug#932592: kopano-webapp: autopkgtest regression
package: src:kopano-webapp severity: serious version: 3.5.6+dfsg1-1 kopano-webapp currently has a failing autopkgtest [0]. This currently blocks migration of chromium since it is listed as an autopkgtest dependency for this package. == ERROR: test_login (test_webapp.TestWebApp) -- Traceback (most recent call last): File "/tmp/autopkgtest-lxc.720_qx5v/downtmp/build.vfl/src/debian/tests/test_webapp.py", line 70, in test_login elem.click() File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webelement.py", line 80, in click self._execute(Command.CLICK_ELEMENT) File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webelement.py", line 633, in _execute return self._parent.execute(command, params) File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", line 321, in execute self.error_handler.check_response(response) File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/errorhandler.py", line 242, in check_response raise exception_class(message, screen, stacktrace) selenium.common.exceptions.JavascriptException: Message: javascript error: circular reference (Session info: headless chrome=76.0.3809.62) It looks like a selenium issue, but I haven't debugged further than reading this log. If it has to do with chromium-driver, please create a chromium bug with more information. Best wishes, Mike [0] https://ci.debian.net/packages/k/kopano-webapp/testing/amd64/
Bug#931754: qa.debian.org: pass --debian to blhc
package: qa.debian.org severity: normal The blhc results on the build log scanner pages at qa.debian.org indicate that most packages have missing pie flags now that gcc injects it automatically on most archs. Please use the new --debian flag, which was added to account for this [0]. Best wishes, Mike [0] http://bugs.debian.org/845339
Bug#930469: chromium: Insta-segfault on start
control: tag -1 moreinfo On Thu, Jun 13, 2019 at 5:36 AM Guillem Jover wrote: > [23609:23609:0613/102304.872428:FATAL:render_process_host_impl.cc(4060)] > Check failed: render_process_host->InSameStoragePartition( > BrowserContext::GetStoragePartition(browser_context, site_instance, false )). This is the error. FATAL errors in chromium intentionally abort execution. That output should have also been seen without --debug, although upstream's handling of FATAL messages can be flaky. My best guess is that there is an incompatibility with profiles created before 75. If you start with --temp-profile, does that avoid the problem? Best wishes, Mike
Bug#930348: chromium: missing intrinsics on armhf
On Tue, Jun 11, 2019 at 2:21 PM Riku Voipio wrote: > I can make an upload if you prefer, or I can wait for you. No reason to delay, please go ahead. Best wishes, Mike
Bug#930348: chromium: missing intrinsics on armhf
package: src:chromium severity: serious version: 75.0.3770.80-1 The latest upload fails to build on armhf due to missing intrinsics [0]. Best wishes, Mike [0]https://buildd.debian.org/status/fetch.php?pkg=chromium&arch=armhf&ver=75.0.3770.80-1&stamp=1560141959&raw=0
Bug#928097: chromium: crc32 build errors on arm64
package: src:chromium severity: serious version: 74.0.3729.108-1 The latest upload fails to build on arm64 due to errors in crc32 [0]. Best wishes, Mike [0]https://buildd.debian.org/status/fetch.php?pkg=chromium&arch=arm64&ver=74.0.3729.108-1&stamp=1556085401&raw=0
Bug#928055: change "disable-pings" to "no-pings"?
control: severity -1 wishlist control: retitle -1 chromium: add "no-pings" flag On Fri, Apr 26, 2019 at 7:09 PM ilf wrote: > So either I am missing something here, or the Debian package > default-flags should replace "disable-pings" with "no-pings". The disable-pings flag has to do with the component updater [0]. Setting no-pings could be a useful addition. Best wishes, Mike [0]components/component_updater/component_updater_command_line_config_policy.cc
Bug#927983: chromium: "Open all" no longer works
control: tag -1 moreinfo, unreproducible control: severity -1 minor On Thu, Apr 25, 2019 at 6:33 PM Salvo Tomaselli wrote: > middle clicking on a bookmark directory used to open all of the items in > tabs. This no longer works. > > Also, right clicking and selecting "Open all" used to do the same. The menu > is still there, but it does nothing. I am not able to reproduce either of these. However I just created a new Bookmark Directory. Maybe it only affects directories created before 74? Best wishes, Mike
Bug#926032: [chromium] Buggy / Solarized videos
control: forcemerge -1 926151 control: severity -1 minor On Tue, Apr 2, 2019 at 5:21 AM wrote: > However it is a short term solution. Why would we have to disable a feature > like hardware acceleration and revert to a sluggish (and cpu hungry) software > rendering in order to (barely) make things work like they did before in > previous releases ? The vaapi patch is work in progress. It could be unapplied, but then hardware acceleration would be completely unavailable, which is equivalent to the workaround but of course takes away from those that have hardware that works. Best wishes, Mike
Bug#926031: unblock: chromium/73.0.3683.75-1
package: release.debian.org user: release.debian@packages.debian.org usertags: unblock Please consider unblocking chromium. This is a large upstream release with a bunch of security fixes. As has been done for the past few stable releases, the plan is to push ongoing upstream security updates to buster(-security). Best wishes, Mike unblock chromium/73.0.3683.75-1
Bug#923701: Black rectangles appears at top-left of window when using a tiling WM.
control: tag -1 pending control: severity -1 minor This should be fixed when chromium 73 is uploaded. Best wishes, Mike On Sun, Mar 3, 2019 at 9:51 PM Gong S. wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Package: chromium > Version: 72.0.3626.96-1~deb9u2 > > When launched in a tiling windowing manager, there is a black rectangle > appearing randomly in the title bar. > Moving the mouse will cause the rectangle to disappear-it looks like that it > is related to the mouse position. > It happens regardless of the theme and the GTK2 config. > This only happens when Chromium is in tiling mode; it does not affect > floating windows. > -BEGIN PGP SIGNATURE- > Version: ProtonMail > Comment: https://protonmail.com > > wsBcBAEBCAAGBQJcfJGRAAoJENi1YDlFXXQfmagIAKtN8CJruMfz2/fgwsgO > Y7pCu7anVxngSLPtv+CP/xVoViFKhfi4f1Zjvjoiwygs63KDzZAu2SazSuyU > xj+ELOf0F+2/7azXoBv1ATxVjFINDoz/yy2IcICYFqASmK5iuDo646bx+2+U > J4OgS74SKimZT7VjBIv6kbaimE2jqX2HDijpxPlO9OgMXgmn8u/YgLRANiRo > AVS0noM2eimjtr+GdOUQADnLwC4cZew8w102aMc3NvYgUSHbBywzpcp90eio > C2cpIxqDpWx/USkEAh6SlichfX5rnrDBJP7GytpaX7Wg3RPgii+zLXwN3+yx > xI5glwKTXkF3gHTb3OpnXSI= > =tnzV > -END PGP SIGNATURE- >
Bug#923298: chromium: file overlap with chromium-sandbox without Conficts and/or Replaces
control: tag -1 pending On Tue, Feb 26, 2019 at 4:39 AM Lee Garrett wrote: > your issue is related to mixing stable and testing, which is not supported and > causing your issue here. This may not be common knowledge, but mixed suites have always been a supported configuration. This is a legitimate bug. I have a fix queued for the next -security upload. Best wishes, Mike
Bug#923001: error message on start
control: severity -1 serious Increasing severity since policy 10.7.3 is violated: "Obsolete configuration files without local changes should be removed by the package during upgrade." The file in /etc/chromium.d is obsolete. Best wishes, Mike
Bug#923001: error message on start
control: notforwarded -1 control: reassign -1 chromium-ublock-origin On Sat, Feb 23, 2019 at 8:31 PM W. Martin Borgert wrote: > But the culprit was chromium-ublock-origin which was only > uninstalled, but not purged. After purging > chromium-ublock-origin, the message is gone. chromium-ublock-origin is now a transitional package. It should clean up its conffiles in /etc/chromium.d when removed. Best wishes, Mike
Bug#923028: fails to access microphone
control: severity -1 minor control: forwarded -1 http://crbug.com/835767 On Sat, Feb 23, 2019 at 4:21 AM W. Martin Borgert wrote: > When I access a meet jitsi site, e.g. > https://meet.jit.si/ChromiumFailsToAccessMyMicrophone > Chromium asks whether I allow access to camera and microphone. > When I allow, I get the error message > "Fails to access your microphone" from Jitsi. This is a known upstream bug. Best wishes, Mike
Bug#923001: error message on start
On Sat, Feb 23, 2019 at 1:58 PM W. Martin Borgert wrote: > Still, under chrome://extensions/, I see three extensions: > > - Chromium PDF Viewer > - CryptoTokenExtension > - GNOME Shell integration It likely relates to the GNOME shell extension, though it may not. I am not able to reproduce with a default install. Would you mind trying with it removed? Best wishes, Mike
Bug#923001: error message on start
control: severity -1 minor control: forwarded -1 http://crbug.com/724826 On Fri, Feb 22, 2019 at 4:36 PM W. Martin Borgert wrote: > When I start chromium as a newly added user (no chromium config > is present in $HOME) I get a warning dialog: > > > Failed to load extension from: . Manifest file > > is missing or unreadable > > OK This seems related to this upstream issue. Buggy extensions can cause this. You could try removing extensions one at a time to determine which one causes this. Best wishes, Mike
Bug#922207: Wine + AnyRail 6.1 - messing up KDE Desktop
control: tag -1 moreinfo control: severity -1 minor This sounds a lot like this upstream bug: https://bugs.winehq.org/show_bug.cgi?id=23676 It is in a different app and only seen with mesa and ati drivers, not nvidia. Which driver do you use? Does AnyRail allow you to disable 3d rendering? Best wishes, Mike
Bug#916298: steam: should depend on steam-devices
On Mon, Feb 4, 2019 at 3:03 AM Simon McVittie wrote: > This was reduced from Depends to Recommends in 1.0.0.59-4. Michael: > why this change? Recommends are installed by default by apt, so most users will get it installed automatically, but this also supports users that don't need or want it. You could even consider it from a policy perspective, steam-devices is not required for the steam package to be functional. Best wishes, Mike
Bug#921314: devscripts: provide salsa request_access command
package: devscripts severity: wishlist It would be a nice improvement if the salsa script supported gitlab's request_access, which allows a user to request membership to a team. Best wishes, Mike
Bug#877391: Please add apparmor profile
control: tag -1 moreinfo, help On Sat, Nov 11, 2017 at 4:05 PM Michael Gilbert wrote: > I also noticed that a similar file is already in apparmor-profiles. > Is that not sufficient? It looks like apparmor will no longer provide a chromium profile with buster. I'm not planning to look into this myself, but I would accept a well tested patch. Best wishes, Mike
Bug#918385: The name org.freedesktop.Notifications was not provided by any .service files
control: reassign -1 src:notification-daemon On Sat, Jan 5, 2019 at 12:42 PM Dan Jacobson wrote: > ERROR:object_proxy.cc(621)] Failed to call method: > org.freedesktop.Notifications.GetCapabilities: object_path= > /org/freedesktop/Notifications: org.freedesktop.DBus.Error.ServiceUnknown: > The name org.freedesktop.Notifications was not provided by any .service files > > Installing the Suggested notification-daemon does not fix it. The notification-daemon package itself does not provide a systemd service file. I'm not sure how notifications are intended to work in gnome since I don't use it, but it seems like either the service file or a dependency may be missing. Other providers of notification-daemon like dunst, xfce4-notifyd, and many others do include a notifications service file. You could choose one of those instead. Best wishes, Mike
Bug#919135: ERROR:context_group.cc(381)] ContextResult::kFatalFailure: too few texture image units supported (0, should be 8).
control: severity -1 minor control: forwarded -1 http://crbug.com/822418 On Sat, Jan 12, 2019 at 7:57 PM Dan Jacobson wrote: > [5799:5799:0113/084128.701923:ERROR:context_group.cc(381)] > ContextResult::kFatalFailure: too few texture image units supported (0, > should be 8). [...] > Doesn't happen with a fresh profile though. kFatalFailure means that there chromium at one point was able to communicate with your GPU, but then lost it. You may have a setting in your profile that is causing this, or maybe too many tabs open. It could be many things, could you try to identify specifically what causes it? Best wishes, Mike
Bug#921126: wine-development: checks for /run/user instead of /run/user/$uid
package: src:wine-development severity: serious version: 3.12-2 This has been fixed in wine [0]. It also needs to be fixed in wine-development. Best wishes, Mike [0] http://bugs.debian.org/918666
Bug#914886: chromium: SafeBrowsing is not working at all (sample included)
control: reopen -1 control: tag -1 - moreinfo On Sat, Jan 26, 2019 at 3:21 PM Michael Gilbert wrote: > From everything I can tell, this works correctly in current versions. > Please feel free to reopen if it can be demonstrated otherwise. This seems to be the same problem described in this gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=674504 Upstream has instituted quotas related to their API keys it seems: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-packagers/nEHAnX0mct0 Best wishes, Mike
Bug#919467: steam: data loss when switching from Valve's steam package
On Fri, Jan 18, 2019 at 12:31 AM Michael Gilbert wrote: > Two, Valve moves completely to XDG_DATA_HOME. I intended to say that Valve completely follows the XDG base directory specification, which is of course more than just XDG_DATA_HOME. Best wishes, Mike
Bug#919467: steam: data loss when switching from Valve's steam package
control: tag -1 - patch pending On Wed, Jan 16, 2019 at 6:33 AM Simon McVittie wrote: > This is basically my earlier patch from #916303, except that the default > is swapped: it will continue to use ~/.steam as the $STEAMDIR for new > installations, and only use ~/.local/share/Steam (or any other $STEAMDIR) > if that was already set up. This reduces the solution to #916303 to > "swap the default". I'm don't yet see what use case would require more than one steam installations per user, so I don't see the value of the links Valve dumps in ~/.steam. I am not yet on board with moving the steam dir to XDG_DATA_HOME. These are concerns that have already been mentioned. One, the user can seem to break their installation by changing the value of XDG_DATA_HOME. Second, this will cause clutter to both ~ and XDG_DATA_HOME. Right now the clutter is at least self contained to ~. The two viable solutions I see are. One, use a debian specific dir in ~/.steam. Two, Valve moves completely to XDG_DATA_HOME. Best wishes, Mike
Bug#906548: chromium: Chromium crashes with SEGV on startup on RPI
On Fri, Jan 11, 2019 at 1:03 PM Patrick Häcker wrote: > I can confirm, that version 72.0.3626.7-6 is fixing the issue. Thanks a lot > for > pointing me to the unstable version. > > So as soon as this version enters testing, this bug report can be closed. It can't be closed because the problem will still not be fixed in stretch. This is only fixed in unstable since gcc 8 is now used to compile chromium. Stretch only has gcc 6 and no one has identified yet which compiler bug causes this or how to work around the problem with older compilers. For anyone that cares about this issue, figuring that out would be very helpful. Best wishes, Mike
Bug#918666: wine hardcodes /run/user/$UID directory
control: tag -1 - moreinfo On Sat, Jan 12, 2019 at 1:19 AM Michael Gilbert wrote: > This is already the case. The current implementation automatically > falls back to TMPDIR if /run/user/$UID does not exist. It also > automatically handles creation of the wine subdirectory if it does not > exist. > > There may corner cases that are yet unhandled, can you better define > the problem you've actually seen? I think I see the problem. /run/user is checked for existence, not /run/user/$UID. Best wishes, Mike
Bug#918666: wine hardcodes /run/user/$UID directory
control: tag -1 moreinfo On Tue, Jan 8, 2019 at 4:21 AM Julian Andres Klode wrote: > wine hardcodes the use of /run/user/$UID/wine if it can determine > $UID (if getuid() exists) as the place to store server information. > > It's not clear to me who is responsible for creating those directories, > but I'm not sure we can rely on them being available, so wine should > fallback to /tmp if /run/user/$UID does not exist, I guess. This is already the case. The current implementation automatically falls back to TMPDIR if /run/user/$UID does not exist. It also automatically handles creation of the wine subdirectory if it does not exist. There may corner cases that are yet unhandled, can you better define the problem you've actually seen? > In fact, it should be using $XDG_RUNTIME_DIR, not > hardcoding /run/user/$UID. There is discussion in the upstream bug about the extra concerns that would need to be handled to support XDG_RUNTIME_DIR. At this time, I plan to wait for upstream to decide how to handle that. In the meantime, it will not be supported. > (this surfaced in Ubuntu autopkgtest for gpgv-win32). What was the actual error? Best wishes, Mike
Bug#917622: Keyboard shortcuts ignored in text fields
control: tag -1 moreinfo On Sat, Dec 29, 2018 at 7:27 AM Minh Duc Vo wrote: > Inputting a shortcut key combination while a text field is being focused will > not trigger the desired action for that combination. > For example, A Ctrl+T combination inputted while the cursor is placed in the > Omnibox will simply be ignored without any further effect. I am not able to reproduce this with the version you mention. Are you sure that there isn't something else interpreting key presses, perhaps your desktop environment or window manager? Best wishes, Mike
Bug#914886: chromium: SafeBrowsing is not working at all (sample included)
control: tag -1 moreinfo On Wed, Nov 28, 2018 at 4:09 AM Peter Gervai wrote: > Anyway, Chromium SafeBrowsing seems not to work at all, despite that both > "SafeBrowsing" and "Help improve SB" is on. > > Just go to this URL and see no warnings: > https://www[.]xn--bbox-vw5a[.]com/login > (It is a phishing site for bibox.com with TLS domain padlock.) > The URL is detected by both FireFox and Google SafeBrowsing website. I tried this both with and without safe browsing enabled in chromium 72. It always detected the site as insecure, the red Not Secure triangle, regardless of the safebrowsing setting. Maybe this was a temporary bug in version 70? Could you retest with a newer version? Best wishes, Mike
Bug#916725: chromium: Extensions which access Google Bookmarks fail
control: severity -1 normal On Mon, Dec 17, 2018 at 4:15 PM Sean Shapira wrote: > Extensions which attempt to access Google (not chrome) bookmarks no longer > function. This is a regression introducted since 69.0.3497.92-1~deb9u1. enable_one_click_signin is set to false starting with version 70 to prevent background interfacing with google services. It is the most likely cause here. Other users expect chromium to not interface with google's services, so you would need to debate them about whether or not this should be enabled. I am inclined to leave it disabled. Best wishes, Mike
Bug#917307: wine: "setup_exception stack overflow" in debian's wine 4.0
control: tag -1 moreinfo > The problem reproduces everytime during loading WorldOfWarcraft game. [...] > The game window is created but it is black and the terminal contains error > message > >> 0009:err:seh:setup_exception stack overflow 1760 bytes in thread 0009 This sounds very similar to this upstream bug: https://bugs.winehq.org/show_bug.cgi?id=46291 It requires a patch to the vkd3d package. Could you test whether it helps? Upstream's wine package most likely works since the world of warcraft client will fallback to directx 11 if directx 12 is not available. You could also try building the debian package without vkd3d. Pass --without-vkd3d to configure in debian/rules. Best wishes, Mike
Bug#913116: Needs to depend on chromium-sandbox
On Mon, Dec 17, 2018 at 4:40 AM Bastian Blank wrote: > > Since this can be used in place of chromium's setuid binary, my > > opinion is that the Depends relationship on chromium-sandbox is no > > longer required. > > Nope, at least if the package is supposed to work without admin > intervention. Debian policy does not (currently) demand this for dependency relationships. Policy states that dependencies represent other packages that are required for the first to work correctly. In this case, since chromium can be set up to work correctly without chromium-sandbox installed, it thus does not need to be considered a dependency. Whether or not the set requires administrator intervention is consequently not relevant, at least with respect to the statement policy makes about this. Best wishes, Mike
Bug#913116: Needs to depend on chromium-sandbox
On Fri, Nov 16, 2018 at 4:30 AM Bastian Blank wrote: > Debian does not support unprivileged user namespaces, so chromium needs > to depend on -sandbox to get a working package. The debian version of the kernel package provides kernel.unprivileged_userns_clone as a runtime selectable option for a while now. Since this can be used in place of chromium's setuid binary, my opinion is that the Depends relationship on chromium-sandbox is no longer required. Best wishes, Mike
Bug#915799: libGL.so.1 Missing
control: reassign -1 src:steam control: retitle -1 steam: fails to load libGL.so.1 Make sure you have either libgl1-mesa-glx:i386 or your proprietary driver's i386 glx package installed. See bug #718599. Best wishes, Mike
Bug#905202: libclc-r600: Unable to find '/usr/lib/clc/cypress-r600--.bc'
control: tag -1 moreinfo There is a new upstream version uploaded now, 0.2.0+git20180917. Does this fix the problem you're seeing? For anyone that would like to help here, it would be helpful to figure out which upstream commit fixed #898257, which is almost exactly the same problem. Best wishes, Mike
Bug#914822: Issues with error message "Invalid MIT-MAGIC-COOKIE-1 key"
control: tag -1 upstream control: severity -1 wishlist On Nov 28, 2018 at 7:12 PM Vincent Lefevre wrote: > 1. When X11 is not used like here, there is no reason to try to use > DISPLAY (or at least, error messages should be deferred). Note that > "env -u DISPLAY wine tversion.exe" doesn't output any error message. Why not correct the invalid DISPLAY setting in your displayless environment? I suppose wine could delay initializing X until it knows the application its launching actually needs it, but that is not how it is designed now. This is a new feature that you could request of upstream. Best wishes, Mike
Bug#856573: chromium: pulldown menus not working (not pulling down)
control: reassign -1 src:twm On Sun, Nov 4, 2018 at 3:33 PM Mark Carroll wrote: > I see the problem even in Chromium 69 with both twm and ctwm. This seems like it should be considered a bug in twm. The chromium upstream bug report includes a lightly tested patch to twm that fixes it. Best wishes, Mike
Bug#906548: chromium: Chromium crashes with SEGV on startup in Stable on RPI
control: severity -1 important control: fixed -1 70.0.3538.54-2 control: retitle -1 chromium: SEGV on startup in stretch on armhf > the version in stable crashes after the security update on a Raspberry Pi > on startup. The system ist mainly Debian stable with some Raspbian packages. > I couldn't find the dbgsym package, so please point me to it. Until then > this is the --debug output: The upstream discussion indicates that this is fixed after the update to gcc 8 in unstable, so it seems to be another problem specific to gcc 6 on arm. Since unstable now uses gcc 8, this only needs to be fixed in stretch now. Riku, do you have any ideas? Best wishes, Mike
Bug#908288: chromium: minimize/maximize window buttons can be missing
I looked into this. It is caused by upstream's removal of the gtk2 window button implementation around version 64, which is why only stretch is affected. It still uses gtk2. For anyone interested in this, I am willing to accept a forward port of upstream's old implementation. However, this isn't something I'll be looking into myself. Best wishes, Mike
Bug#912680: libasound2-plugins: broken symlinks in /etc/alsa/conf.d
control: severity -1 grave control: reassign -1 libasound2-plugins control: retitle -1 libasound2-plugins: broken symlinks in /etc/alsa/conf.d control: found 1 1.1.7-1 This is caused by broken symlinks added to libasound2-plugins between 1.1.6-1 and 1.1.7-1. Best wishes, Mike
Bug#908012: wine-development: gcc-8 build with -O2 causes some apps to crash
control: tag -1 moreinfo > Negative, wine stable is not affected, at least for my use-case. > According to the winehq bug, it all started from wine 3.8. What about the latest uploads of wine-development, do they work for you now? This should be fixed by upstream's DECLSPEC_HOTPATCH updates as of 3.17. Best wishes, Mike
Bug#910942: [wine-development] Please use wrap-and-sort
On Sat, Oct 13, 2018 at 12:39 PM Jens Reyer wrote: > To avoid these issues I suggest to use > > wrap-and-sort --wrap-always --short-indent --trailing-comma Hi Jens, Welcome back! Wrap and sort is itself the original source of the extra diff being seen and will continue to be in the future. I would prefer to maintain the original rough organization of dependencies, which is build tools, utilities, and data followed by libraries. Wrap and sort to me is not particularly useful. > [1] This time I just noticed you replaced the builddep "fontforge-nox | > fontforge" with "fontforge-nox". This reverts something I did on > purpose when I implemented the font-rebuilding, so that for local > rebuilds fontforge-nox doesn't get pulled in unnecessarily if fontforge > is already installed. That change is of course intentional. It is my opinion that it is preferable to try to avoid potential sources of variance in builds. A desire to reduce the number of installed packages for a build I think should not override that. Best wishes, Mike
Bug#905090: wine-development: Causing SEGV when using Qt.
On Thu, Sep 6, 2018 at 8:49 PM Michael Gilbert wrote: > This might be this upstream bug: > https://bugs.winehq.org/show_bug.cgi?id=45199 > > 3.13 was the first version built with gcc8. You could try rebuilding > with either gcc7 or with -O1 instead of -O2. The latest upload 3.16-1 is built with -O1. Would you mind testing whether that has any effect on this problem? Best wishes, Mike
Bug#908412: Followup
control: tag -1 confirmed control: severity -1 important On Sun, Sep 16, 2018 at 8:57 PM Jiri Palecek wrote: > I think this bug is caused by the addition of the Diablo patch. > Certainly, removing it fixed it. I already knew as much since it was the only substantive change in that upload. I agree that it is a sledgehammer taken to the problem it tries to solve, and I had already started working on it. Thank you for confirming that it causes breakage. Best wishes, Mike
Bug#908288: chromium: minimize/maximize window buttons can be missing
package: chromium severity: minor version: 68.0.3440.75-1~deb9u1 tag: upstream This is a regression introduced upstream. Seen in this version and possibly introduced earlier. It only affects the stretch package. Best wishes, Mike
Bug#908142: chromium crashes when changing domain name in Selenium tests
control: tag -1 moreinfo control: severity -1 minor On Thu, Sep 6, 2018 at 11:03 AM Nicolas Rodriguez wrote: > I use ArchLinux on my laptop with Chromium 68.0.3440.106 and it works > very well. > > I suggest to update Chromium to 68.0.3440.106. 69.0.3497.81-1~deb9u1 has just been uploaded. Does it fix this problem? Best wishes, Mike
Bug#905090: wine-development: Causing SEGV when using Qt.
control: tag -1 upstream control: severity -1 minor This might be this upstream bug: https://bugs.winehq.org/show_bug.cgi?id=45199 3.13 was the first version built with gcc8. You could try rebuilding with either gcc7 or with -O1 instead of -O2. Best wishes, Mike
Bug#907769: chromium: tab consistently crashes when visiting arduino webpage
control: reopen -1 control: tag -1 confirmed, upstream On Mon, Sep 3, 2018 at 9:27 AM Marius Mikucionis wrote: > I have replaced the packages (see the new list below) with the Debian ones > and the issue persists. I tested as well now, it is reproducible with the latest upload. > Is there a way to triangulate the offending library? The --debug command line option is useful. It appears to be a problem in v8. Best wishes, Mike
Bug#905090: wine-development: Causing SEGV when using Qt.
Should this be considered a bug in Qt since it fails to take into account the return value from wTInfoT? Also there was some refactoring upstream in 3.15 in wintab and winpos, would you mind retesting with the latest upload? Best wishes, Mike
Bug#901875: chromium: 2 non chrome extensions installed by default. crypto mining and pdf reader
control: severity -1 minor control: forwarded -1 http://crbug.com/473958 control: retitle -1 chromium: pdf and two factor extensions can't be removed Upstream intentionally builds these extensions in by default. In fact upstream hides them by default. If you don't want to see them in the debian extensions list, you can remove --show-component-extension-options from chromium's command line options. Best wishes, Mike
Bug#905694: chromium: *** version in stable/security-updates still has video/ffmpeg bug that was closed 2 months ago
On Wed, Aug 8, 2018 at 3:35 AM, Tim Connors wrote: > Kernel: Linux 4.16.0-0.bpo.2-amd64 (SMP w/4 CPU cores) This may be totally unrelated, but I see that you're using a backports kernel. Could you retry with an official stretch kernel? You might also try updating to the latest bpo kernel, 4.17. Best wishes, Mike
Bug#905269: chromium: Chromium anomalous behaviour
On Sun, Aug 12, 2018 at 8:04 PM, Michael Gilbert wrote: >> Kernel: Linux 4.9.0-7-amd64 (SMP w/4 CPU cores) > > Your kernel is quite out of date. Could you try 4.9.110-1 or newer? I read that wrong, you are up to date. There is a bug in xlib for certain locales [0], from my understanding of that bug pt_BR is one of them. Could you try a locale other than pt_BR? Best wishes, Mike [0] http://bugs.debian.org/822438
Bug#905269: chromium: Chromium anomalous behaviour
control: tag -1 moreinfo > Chromium showing an anomalous behaviour after last debian stable update > running under AMD graphical interface. A blue screen appears when the > browser is loading. Are you using the proprietary AMD driver? > -- System Information: > Debian Release: 9.5 > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-7-amd64 (SMP w/4 CPU cores) Your kernel is quite out of date. Could you try 4.9.110-1 or newer? There have been many bug fixes since 4.9.0, at least a few related to video problems. Best wishes, Mike
Bug#904796: chromium for arm64 lacks security updates
control: tag -1 pending On Tue, Aug 7, 2018 at 9:07 AM, Riku Voipio wrote: > I didn't push this to main stretch branch, as the security upload commit > is reconstructed rather the original from Michael. Changelog hasn't been > updated either. I had forgotten to push after the previous upload, done now. I will include this in the next stable-sec upload. Best wishes, Mike
Bug#897189: chromium 66 tab crash on certain sites with ublock origin
On Sat, Aug 11, 2018 at 8:11 PM, Michael Gilbert wrote: > As far as I can tell, this is upstream http://crbug.com/844377. It > was introduced in chromium 66 just like you experienced and symptoms > are nearly identical. > > I previously checked that their fix was applied in version > 68.0.3440.75-1~deb9u1 and have just double checked it, so as far as I > can tell it should be fixed. Can you provide any more detail? dbgsym > packages are in fact available [0]. Correction, missing dbgsym packages for stable-sec is a known bug [1]. You could try rebuilding from source, one of the outputs will be the dbgsym package. Best wishes, Mike [1] http://bugs.debian.org/894081
