Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
Noah Meyerhans wrote: > The biggest difficulty, as far as I can tell from my look at Chromium from > several months ago, is that our patch set [1] needs a lot of attention with > every chromium release. And let me ask another silly question: where can we actually see a CI log for a failed build? buildd.d.o only features the latest successful one (for 93rd Chromium). signature.asc Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
Noah Meyerhans wrote: > On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote: >> >> So what's happening with chromium in both sid and stable? I saw on >> >> d-release that it was removed from testing (#998676 and #998732), with a >> >> discussion about ending security support for it in stable. >> > >> > The problem really is lack of maintenance. In my opinion, chromium >> > deserves an active *team* to support it in Debian. <...> The security >> > team doesn't have the bandwidth to do it themselves, they need a team to >> > help them. >> >> Sorry for a silly question, but whatʼs so wrong with the build done by >> linuxmint.com [1], so Debian needs a whole team to duplicate their effort? >> Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my >> (limited) experience. > > Well, you can start with the fact that the Mint chromium source packages > don't even include the chromium source, If the fact is that their ad-hoc downloader does not generate orig tarball, I fail to see much trouble here. They are using the same `chromium-browser-official` releases. > let alone the sources for all the other things they build (NodeJS, and more). Well, they actually do not build NodeJS, but use a blob from nodejs.org (just like Google does). Nothing good, of course, but I hope itʼs not the case that Chromium build fails when NodeJS is actually built from sources that are supposed to correspond to that blob? Or had nobody tried that? If the latter, why? Is there some policy, that mandates that preinstalled node(1) must be used? > One lesson we may take from Mint, though, is that it's not worth trying to > patch Chromium as much as we'd like. Anything that we can do to simplify the > Chromium packaging will help us keep the package up-to-date, which in turn > will help us keep our users safer. In my opinion, we should be pretty > aggressive about dropping as many of the Chromium patches as possible, even > if that means we link against bundled/vendored dependencies. Indeed. As a passer-by I really wonder why that path had been taken at all in the first place. If Chromium devs are into hard-pinning dependencies, they presumably have good reasons to do that. > Legal/licensing considerations are still important and I don't know if we > actually *can* ship builds based on the bundled stuff. I cannot imagine how it can be illegal for Debian what is legal for Google or Flathub in this case. Were there some prior discussions about that? signature.asc Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
Paul Gevers wrote: > On 05-12-2021 03:36, Andres Salomon wrote: >> So what's happening with chromium in both sid and stable? I saw on d-release >> that it was removed from testing (#998676 and #998732), with a discussion >> about ending security support for it in stable. > > The problem really is lack of maintenance. In my opinion, chromium deserves > an active *team* to support it in Debian. <...> The security team doesn't > have the bandwidth to do it themselves, they need a team to help them. Sorry for a silly question, but whatʼs so wrong with the build done by linuxmint.com [1], so Debian needs a whole team to duplicate their effort? Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my (limited) experience. [1] http://packages.linuxmint.com/pool/upstream/c/chromium/ signature.asc Description: PGP signature
Bug#989104: kgpg 21.04 depends on 20.08 libkfʼs
Package: kgpg Version: 4:21.04.0-1 Severity: serious X-Debbugs-Cc: d...@gnui.org Dear maintainer, kgpg 21.04.0-1 depends on libkf5akonadicontact5-20.08 and libkf5akonadicore5-20.08, which are indeed packages from 20.08 KDE and cannot be installed along with their 21.04 versions. As a result kgpg and, say, kmail are in conflict. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: amd64 (x86_64) Versions of packages kgpg depends on: ii gnupg2.2.27-2 ii kio 5.82.0-1 ii libc62.31-12 ii libgcc-s110.2.1-6 ii libkf5akonadicontact54:21.04.1-1 pn libkf5akonadicontact5-20.08 pn libkf5akonadicore5-20.08 ii libkf5akonadicore5abi2 4:21.04.1-1 ii libkf5archive5 5.82.0-1 ii libkf5codecs55.82.0-1 ii libkf5configcore55.82.0-1 ii libkf5configgui5 5.82.0-1 ii libkf5configwidgets5 5.82.0-1 ii libkf5contacts5 5:5.82.0-1 ii libkf5coreaddons55.82.0-1 ii libkf5crash5 5.82.0-1 ii libkf5dbusaddons55.82.0-1 ii libkf5i18n5 5.82.0-1 ii libkf5jobwidgets55.82.0-1 ii libkf5kiocore5 5.82.0-1 ii libkf5kiofilewidgets55.82.0-1 ii libkf5kiogui55.82.0-1 ii libkf5kiowidgets55.82.0-1 ii libkf5notifications5 5.82.0-1 ii libkf5service-bin5.82.0-1 ii libkf5service5 5.82.0-1 ii libkf5textwidgets5 5.82.0-1 ii libkf5widgetsaddons5 5.82.0-1 ii libkf5windowsystem5 5.82.0-1 ii libkf5xmlgui55.82.0-2 ii libqt5core5a 5.15.2+dfsg-5 ii libqt5dbus5 5.15.2+dfsg-5 ii libqt5gui5 5.15.2+dfsg-5 ii libqt5network5 5.15.2+dfsg-5 ii libqt5printsupport5 5.15.2+dfsg-5 ii libqt5widgets5 5.15.2+dfsg-5 ii libstdc++6 10.2.1-6 kgpg recommends no packages. kgpg suggests no packages. signature.asc Description: PGP signature
Bug#864565: fixed in chromium-browser 60.0.3112.72-1
Control: found -1 chromium-shell/63.0.3239.84-1~deb9u1
Control: tag -1 stretch
> Source: chromium-browser
> Source-Version: 60.0.3112.72-1
>
> We believe that the bug you reported is fixed in the latest version of
> chromium-browser
Sorry, but it seems to me, that this bug is not fixed in stable
(Stretch) and its chromium-shell version 63.0.3239.84-1~deb9u1:
$ chromium-shell
[25398:25398:0128/041122.890412:311365848311:FATAL:v8_initializer.cc(248)]
Couldn't mmap v8 natives data file, status code is 1
#0 0x55a1fe5d0eb6
#1 0x55a1fe5e81da
#2 0x55a1ff27181d
#3 0x55a1fe0c5e79
#4 0x55a1fefaf635
#5 0x55a1fd950e71
#6 0x55a1fd611c58
#7 0x7f2c139822b1 __libc_start_main
#8 0x55a1fd6158ea _start
Aborted
$ type chromium-shell
chromium-shell is hashed (/usr/bin/chromium-shell)
$ strace chromium-shell
<...>
open("/usr/bin/snapshot_blob.bin", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/bin/natives_blob.bin", O_RDONLY) = -1 ENOENT (No such file or
directory)
<...>
open("/usr/bin/content_shell.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = -1 EACCES
(Permission denied)
<...>
Did I miss something?
Bug#758746: [FINALLY FIXED] kde-workspace-bin: Energy saving schemes have no effect
The bug in KDE seems to be fixed now too, so that menu / KRunner items are back. Although I am not sure, whether it is enough to upgrade ‘kde-workspace-bin’ to the version 4.11.13-2 or the issue was in some other package. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758746: [NOT FIXED] kde-workspace-bin: Energy saving schemes have no effect
Updating ‘cgmanager’ up to version 0.33-2 indeed solves the issue with polkit / logind: $ qdbus --system org.freedesktop.login1 \ /org/freedesktop/login1 \ org.freedesktop.login1.Manager.CanSuspend now returns ‘yes’, while before update: ‘challenge’; and so $ qdbus --system org.freedesktop.login1 \ /org/freedesktop/login1 \ org.freedesktop.login1.Manager.Suspend true now works properly, while before update it returned: ‘Permission denied’. But KDE does not care – items ‘Suspend’ and ‘Hibernate’ in KMenu, KRunner, etc are still absent, KDE’s power management schemes still have no effect. So the problem seems to be more complicated. This might be related: $ qdbus org.freedesktop.PowerManagement.Inhibit \ /org/freedesktop/PowerManagement \ org.freedesktop.PowerManagement.CanSuspend false And yes, when the init is ‘systemd-sysv’ (not ‘sysvinit-core’) all works as expected. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
