Bug#1081194: LLVM 19: lowering severity, and please remove your removal hint

[Andres Salomon]

On Fri, 27 Sep 2024 10:21:16 + sylvestre...@ledru.info wrote:


Le dimanche 15 septembre 2024 à 21:05, Sylvestre Ledru  a 
écrit :
> 
> Hello,
> 
> Le 15/09/2024 à 20:11, Sebastian Ramacher a écrit :
> 
> > To move forward in this regard, we would like to ask the LLVM

> > maintainers to provide us with a plan for trixie. Which llvm-toolchain
> > versions are you planning to release with? Which llvm-toolchain version
> > should be the default version (llvm-defaults is currently pointing to
> > 16). If we are aware of your plans, we can help with getting reverse
> > dependencies to migrate or in the worst case removed from testing.
> 
> 
> I would like to upgrade llvm-defaults to 19 when it 19.1.0 is released

> (in a few weeks)
> And starts to fill bugs when it is done
> 
> And only keep 18 and 19 for trixie.
> 
> how does it sound?


I guess it is ok with you then :)

I prepared llvm-defaults to point to 19.

Ok for the upload in unstable?
Thanks
Sylvestre





Just pinging everyone here, as the chromium team would like to get 
things moving with 19.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1078105: chromium (and chrome!) on Sid (only) have an event propogation issue

[Andres Salomon]

According to the upstream bug report, this bug should be fixed in 
chromium 129. Can you please check with the latest sid or 
bookworm-security packages and report back?


On 8/7/24 16:05, Phil Dibowitz wrote:
Bug is available again. It had been deleted for "abuse" and it has been 
undeleted.


On 8/6/24 8:12 PM, Andres Salomon wrote:

It's normal when they mark it as a security issue. Otherwise, no.

I agree that the whole sid-specific thing makes it sound like it's 
relate to an upgraded library (eg, xorg libs); especially since we're 
using the same compiler version in sid and bookworm. I'm unfortunately 
unable to reproduce this in a virtualbox instance (cinnamon/X nor 
gnome/wayland), so it could also be something driver-related, too.



On 8/6/24 22:42, Phil Dibowitz wrote:

Woah. Is that... normal?

I no longer have access. :(

It's weird it _only_ happens on Sid, which is why I also wanted to 
report it here... like there's some dependency in sid that causes an 
issue?


Anyway - I know a bunch of Googler's, I'll see if I can track 
something down.


Thanks!

On 8/6/24 7:32 PM, Andres Salomon wrote:

On 8/6/24 20:31, Phil Dibowitz wrote:
[...]


Upstream bug:
https://issues.chromium.org/issues/357905828


D'oh, locked down already.

Thank you for reporting this - if you still have permission to view 
the upstream bug, please let us know when it's fixed.








--
I'm available for contract & employment work, please contact me if 
interested.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1082907: chromium: FTBFS with reverted libxml2

[Andres Salomon]

Control: tags -1 pending

On 9/28/24 02:48, Sebastian Ramacher wrote:

Source: chromium
Version: 129.0.6668.70-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

libxml2 has been reverted to the 2.9.x series in unstable due to the ABI
breaks in later release series. chromium FTBFS with the reverted
version:

[...]

   ^
/usr/include/libxml2/libxml/xmlerror.h:869:5: note: candidate function not 
viable: no known conversion from 'void (void *, const xmlError *)' (aka 'void 
(void *, const _xmlError *)') to 'xmlStructuredErrorFunc' (aka 'void (*)(void 
*, _xmlError *)') for 2nd argument
 xmlSetStructuredErrorFunc   (void *ctx,
 ^
1 error generated.

Cheers


Fixed in git:
https://salsa.debian.org/chromium-team/chromium/-/commit/30752c7908569d024b4a385446c51ac23957b338

I'm anticipating a new upstream release on Tuesday, so I'll upload then.

And thank you for fixing libxml2!


--
I'm available for contract & employment work, please contact me if 
interested.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1082956: apt: autoremove --purge changed behavior; immediately removes packages

[Andres Salomon]

On 9/29/24 08:58, David Kalnischkies wrote:

Control: severity -1 normal

(I hope at the end its understandable why I downgrade the severity)

Hi,

Am Sat, Sep 28, 2024 at 10:11:24PM GMT, schrieb Andres Salomon:

Here's the log from my terminal:

[…]

dilinger@debian:~$ sudo apt autoremove --purge libgtk-3-common
Building dependency tree... 0%


This line is suspicious as it should have disappeared – like the rest of
the progress reporting. That it hasn't indicates that your terminal
acted on more input than expected – as in you pressed ENTER for a bit
too long firing of the apt command generating a new line.


This makes sense. I was running this inside of a (K)VM, so everything is 
a bit slower than bare metal. I could see how multiple ENTER keypresses 
could get registered (either due to slowness, or as a hardware issue).





Harmless, right … ?



Summary:
   Upgrading: 0, Installing: 1, Removing: 448, Not Upgrading: 0
   Download size: 79.7 kB
   Freed space: 1,714 MB

Get:1 http://deb.debian.org/debian trixie/main amd64 pinentry-curses amd64 
1.2.1-4+b1 [79.7 kB]


In fact, I can easily reproduce this behaviour with any apt command
usually asking a question if I keep holding ENTER for a bit longer…
which is not too unsurprising as pressing ENTER on the confirmation
prompt is considered a valid confirmation. I wonder a bit how the
line ends up disappearing through.

A command which defaults to 'No' on enter like the very wrong:
  apt upgrade -o Dir::Usr=/sys/firmware/efi/efivars
(to force a more space needed warning at least on my system)
has the output appearing…


A wait, I get why: "Continue?" (and the other prompts) are not
terminated by a newline, so if you press enter at the intended time
the newline is added and the download happens on a fresh line (or in the
case of the default No we generate additional output producing a new
line).


I tried it just now on both bookworm and trixie; hitting ENTER twice 
while running 'sudo apt remove ' results in the prompt not showing 
up at all.





If you pressed enter too early the newline will have been entered
somewhere in the previous output already (remember the 0% ?),
so the download progress line happens to override the silently
confirmed prompt.


That is a fun one! And a bit surprising nobody else stumbled over this
as this can be reproduced with any and all versions of apt (and massive
amounts of other terminal software). In our case it seems reasonable to


I think it's unlikely that one would accidentally hit ENTER twice 
_unless_ dealing with a buggy keyboard or slow hardware, and with slow 
hardware I could imagine people hitting CTRL-C before it gets very far, 
so I could see why it hadn't been reported earlier.




"just" ignore any input given before we show the prompt. Except that
someone might be doing e.g. "echo yeah | apt …" and that would break,
so better only if input is a tty.

Now, that "breaks" a user on slow machines that take a while to generate
the listings that just hits confirm after the REMOVE section is done (in
old order – now we know why it was given first 😉), so they have to wait
now for the prompt, but… oh well, --no-remove --assume-yes could work
for this straw man user instead I guess (https://xkcd.com/1172/).
Agreed that the tradeoff of making a user with slow hardware wait for 
the prompt (or add additional args) is better than having someone 
accidentally remove important packages.




MR on salsa: https://salsa.debian.org/apt-team/apt/-/merge_requests/375



Thank you!



Best regards

David Kalnischkies




--
I'm available for contract & employment work, please contact me if 
interested.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1075982: Bug#1077345: chromium: video on wayland, each frame emits warning to stderr: "gbm_pixmap_wayland.cc(82)] Cannot create bo with format=YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE"

[Andres Salomon]

On 9/28/24 22:42, Guillem Jover wrote:

Control: forwarded -1 https://issues.chromium.org/issues/331796411
Control: tags -1 upstream fixed-upstream

Hi!

On Sun, 2024-07-28 at 09:51:09 -0700, Daniel Kahn Gillmor wrote:

Package: chromium
Version: 126.0.6478.126-1~deb13u1
Severity: normal



When i use chromium to watch a video, using sway and wayland (no X11 or
XWayland on this system), i get very noisy messages to stderr,
apparently about one message per frame of video.
>> I typically use set --ozone-platform-hint=auto, or set it explicitly 
>> in chrome://flags/#ozone-platform-hint (See

>> https://bugs.debian,org/1075982, where i explain why i think this
>> should be the default).

This upstream bug (just like 
https://issues.chromium.org/issues/329678163 before it) is exactly why I 
haven't enabled wayland by default. Upstream just doesn't seem to care 
about fixing wayland bugs in a timely fashion yet.


If wayland users have to manually switch chromium from using xwayland to 
wayland, then hopefully they'll know how to switch it back when upstream 
inevitably breaks the wayland backend.


I really hope this upstream situation changes soon.




In particular, i see a line like this appear roughly once per frame:

```
[635461:635515:0728/122929.891862:ERROR:gbm_pixmap_wayland.cc(82)] Cannot 
create bo with format= YUV_420_BIPLANAR and usage=SCANOUT_CPU_READ_WRITE
```


This was reported upstream, and seems to have been fixed a few days
ago with the following patch, which is not part of any release yet:

   https://chromium-review.googlesource.com/c/chromium/src/+/5873796

As a temporary workaround adding the following option works for me:

   --disable-gpu-memory-buffer-video-frames

I guess the options are to either backport that patch, wait for a
release with the fix to happen or temporarily add the above option
in the package conffile?



Thanks for this! I can include the patch in the next 129 upload 
(probably uploaded on Wednesday). Since I'm not currently using wayland, 
I'd appreciate if you could test it out once I do so, and tell me if it 
resolves the issue completely or not.






Thanks,
Guillem


--
I'm available for contract & employment work, please contact me if 
interested.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1082956: apt: autoremove --purge changed behavior; immediately removes packages

[Andres Salomon]

Package: apt
Version: 2.9.8
Severity: serious
Justification: breaks entire system
X-Debbugs-Cc: dilin...@queued.net

On bookworm, running 'apt [auto]remove --purge ' will provide a list
of packages to be removed, and prompt the user before actually removing
those packages. It has been this way (previously with apt-get, and then
with apt) for decades. It is a genuinely useful way to see if a
legacy library on the system can be safely removed, and then (by hitting
'Y' or whatever at the prompt) to actually do the removal(s).

Here's a truncated example from bookworm:

dilinger@5400:~$ sudo apt autoremove --purge libgtk-3-common
[sudo] password for dilinger: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libutempter0 pinentry-curses xterm
Suggested packages:
  pinentry-doc xfonts-cyrillic
The following packages will be REMOVED:
  accountsservice* apg* avahi-utils* bogofilter* bogofilter-bdb*
  bogofilter-common* bolt* bookworm* cheese* cheese-common*
[...]
  xdg-desktop-portal-gnome* xdg-desktop-portal-gtk* xdg-user-dirs-gtk* xkbset*
  xwayland* yelp* yelp-xsl* zenity* zenity-common*
The following NEW packages will be installed:
  libutempter0 pinentry-curses xterm
0 upgraded, 3 newly installed, 496 to remove and 0 not upgraded.
Need to get 927 kB of archives.
After this operation, 1,868 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.


In trixie, this behavior has somehow become inconsistent. See the
logs below, where I was prompted in the first apt execution
removing libgtk2.0-common, but not in the second for removing
libgtk-3-common. I was expecting to be prompted in that second call to apt
to be sure if I wanted to continue, but instead apt just went ahead and 
blew away half of my desktop installation.

I don't understand why there's any difference in the two apt runs; I'm
guessing something related to dependency checking? But regardless, this
is potentially devasting behavior for a user (for me, this was just a
throwaway VM, but I would be _extremely_ unhappy if this happened on,
say, my laptop). I'll keep the VM image around if you need further logs
or info.

Here's the log from my terminal:


dilinger@debian:~$ sudo apt autoremove --purge libgtk2.0-common
REMOVING:   
  gnome-accessibility-themes*  ibus-gtk*libgtk2.0-bin*
  gnome-themes-extra*  libgail-common*  libgtk2.0-common*
  gnome-themes-extra-data* libgail18t64*
  gtk2-engines-pixbuf* libgtk2.0-0t64*

Summary:
  Upgrading: 0, Installing: 0, Removing: 10, Not Upgrading: 0
  Freed space: 35.9 MB

Continue? [Y/n] 
(Reading database ... 155112 files and directories currently installed.)
Removing gnome-accessibility-themes (3.28-3) ...
Removing gnome-themes-extra:amd64 (3.28-3) ...
Removing gnome-themes-extra-data (3.28-3) ...
Removing gtk2-engines-pixbuf:amd64 (2.24.33-6) ...
Removing ibus-gtk:amd64 (1.5.30-1) ...
Removing libgail-common:amd64 (2.24.33-6) ...
Removing libgail18t64:amd64 (2.24.33-6) ...
Removing libgtk2.0-bin (2.24.33-6) ...
Removing libgtk2.0-0t64:amd64 (2.24.33-6) ...
Removing libgtk2.0-common (2.24.33-6) ...
Processing triggers for man-db (2.13.0-1) ...
Processing triggers for libc-bin (2.40-2) ...
(Reading database ... 150908 files and directories currently installed.)
Purging configuration files for gnome-accessibility-themes (3.28-3) ...
Purging configuration files for libgtk2.0-0t64:amd64 (2.24.33-6) ...
Purging configuration files for libgtk2.0-common (2.24.33-6) ...
dilinger@debian:~$ dpkg -l |grep libgtk
ii  libgtk-3-0t64:amd64 3.24.43-4   
 amd64GTK graphical user interface library
ii  libgtk-3-bin3.24.43-4   
 amd64programs for the GTK graphical user interface library
ii  libgtk-3-common 3.24.43-4   
 all  common files for the GTK graphical user interface library
ii  libgtk-4-1:amd644.16.2+ds-1 
 amd64GTK graphical user interface library
ii  libgtk-4-bin4.16.2+ds-1 
 amd64programs for the GTK graphical user interface library
ii  libgtk-4-common 4.16.2+ds-1 
 all  common files for the GTK graphical user interface library
ii  libgtk-4-media-gstreamer4.16.2+ds-1 
 amd64GStreamer media backend for the GTK graphical user interface 
library
ii  libgtk-vnc-2.0-0:amd64  1.3.1-1+b2  
 amd64VNC viewer widget for GTK+3 (runtime libraries)
ii  libgtk3-perl0.038-3 
 all  Perl bindings for the GTK+ graphical user interface library
ii  libgtkmm-4.0-0:amd64 

Bug#1081241: chromium: Please upgrade build-dep to llvm/clang 18 or 19

[Andres Salomon]

On 9/9/24 17:23, Andres Salomon wrote:

On 9/9/24 17:16, Sylvestre Ledru wrote:


Le lundi 9 septembre 2024 à 23:12, Andres Salomon 
 a écrit :


 >
 >
 > We're currently using clang-16 in sid because it's also in 
bookworm, and

 > it's easier to use the same compiler for both distributions.
 >
 > It's likely* we'll need to backport clang-18 or 19 to stable - can you
 > give me a timeline for when you're planning to remove clang-16 from
 > stable?
We aren't planning to remove it from stable. I guess you meant 
testing/sid, right ?




Yes, sorry, I meant sid. :)



 > If it's in the near-term, then we'll probably start testing out
 > chromium in sid with clang-18 and backporting it to stable. If it's a
 > few months out, then (with the assumption that clang 19.1.0 final will
 > be released any day now and hopefully transition to trixie relatively
 > quickly,) we'll focus on clang-19.
I think you should start soon if you can :)


Okay thanks, I will do that!



*Sigh*. I was hoping to wait ~6 months before backporting clang-19, but 
it's looking like we might have to move that timeline up and go with 
clang-18 in bookworm.


Tim's been hitting some compiler bugs:

"Just because I happened to notice the miscompile in one location in all 
of v8 on ppc64 doesn't mean that amd64/arm64 aren't affected in a less 
dramatic way -- the bug only triggers on a couple of sites for me, but 
what's making me wonder more about miscompilation on all architectures 
is the fact that upstream Chromium doesn't understand the NULL pointer 
bug I patched out in the GPU process.  That one absolutely hit amd64; I 
was having the browser process crash every second time I tried a Google 
search on the AMD GPU systems.  Since the miscompilation here basically 
changes a variable to NULL, it's starting to smell like the same 
compiler bug..."


and

"I tried compiling the same problematic code for aarch64 on llc-16 and
llc-17.  There is a significant difference in generated assembly in the
exact same location of the codebase as ppc64; the only difference is I
think on aarch64 the differences will lead to incorrect operation vs. an
outright crash.  I really, *really* would not trust clang 16 on current
Chromium releases at this point!"


Any strong opinions (or suggestions) from the llvm maintainers or RMs at 
this point?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1081241: chromium: Please upgrade build-dep to llvm/clang 18 or 19

[Andres Salomon]

On 9/9/24 17:16, Sylvestre Ledru wrote:


Le lundi 9 septembre 2024 à 23:12, Andres Salomon  
a écrit :


 >
 >
 > We're currently using clang-16 in sid because it's also in bookworm, and
 > it's easier to use the same compiler for both distributions.
 >
 > It's likely* we'll need to backport clang-18 or 19 to stable - can you
 > give me a timeline for when you're planning to remove clang-16 from
 > stable?
We aren't planning to remove it from stable. I guess you meant 
testing/sid, right ?




Yes, sorry, I meant sid. :)



 > If it's in the near-term, then we'll probably start testing out
 > chromium in sid with clang-18 and backporting it to stable. If it's a
 > few months out, then (with the assumption that clang 19.1.0 final will
 > be released any day now and hopefully transition to trixie relatively
 > quickly,) we'll focus on clang-19.
I think you should start soon if you can :)


Okay thanks, I will do that!


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1081241: chromium: Please upgrade build-dep to llvm/clang 18 or 19

[Andres Salomon]

We're currently using clang-16 in sid because it's also in bookworm, and 
it's easier to use the same compiler for both distributions.


It's likely* we'll need to backport clang-18 or 19 to stable - can you 
give me a timeline for when you're planning to remove clang-16 from 
stable? If it's in the near-term, then we'll probably start testing out 
chromium in sid with clang-18 and backporting it to stable. If it's a 
few months out, then (with the assumption that clang 19.1.0 final will 
be released any day now and hopefully transition to trixie relatively 
quickly,) we'll focus on clang-19.



 * Aside from clang-16 compiler bugs, newer Rust also depends on 
clang-17 or above. For Firefox 128esr they're going with a version of 
rustc-web that can build against clang-16, but both chromium and 
firefox-esr will likely need to continue upgrading rustc-web in stable.



On 9/9/24 16:54, Sylvestre Ledru wrote:

Package: chromium
Version: 120.0.6099.109-1
Severity: important

Dear Maintainer,

We would like to remove llvm-toolchain-16 and chromium uses clang 16.
Please update to 18 or 19.

Thanks
Sylvesre

-- System Information:
Debian Release: trixie/sid
   APT prefers testing
   APT policy: (990, 'testing'), (600, 'unstable'), (500, 'oldstable'), (300, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common120.0.6099.109-1
ii  libasound2t64 [libasound2] 1.2.11-1+b1
ii  libatk-bridge2.0-0t64 [libatk-bridge2.0-0] 2.52.0-1
ii  libatk1.0-0t64 [libatk1.0-0]   2.52.0-1
ii  libatomic1 14-20240330-1
ii  libatspi2.0-0t64 [libatspi2.0-0]   2.52.0-1
ii  libc6  2.38-14
ii  libcairo2  1.18.0-1
ii  libcups2t64 [libcups2] 2.4.7-1.2+b1
ii  libdbus-1-31.14.10-3
ii  libdouble-conversion3  3.3.0-1
ii  libdrm22.4.117-1
ii  libevent-2.1-7t64 [libevent-2.1-7] 2.1.12-stable-10
ii  libexpat1  2.6.2-1
ii  libflac12t64 [libflac12]   1.4.3+ds-2.1
ii  libfontconfig1 2.14.2-6
ii  libfreetype6   2.13.2+dfsg-1
ii  libgbm123.3.5-1
ii  libgcc-s1  14-20240330-1
ii  libglib2.0-0t64 [libglib2.0-0] 2.80.2-2
ii  libgtk-3-0t64 [libgtk-3-0] 3.24.42-1
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-6
ii  liblcms2-2 2.14-2
ii  libminizip1t64 [libminizip1]   1:1.3.dfsg+really1.3.1-1
ii  libnspr4   2:4.35-1.1
ii  libnss32:3.102-1
ii  libopenh264-7  2.4.1+dfsg-1
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.4-1
ii  libpango-1.0-0 1.54.0+ds-1
ii  libpng16-16t64 [libpng16-16]   1.6.43-5
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.10-1
ii  libstdc++6 14-20240330-1
ii  libwebp7   1.4.0-0.1
ii  libwebpdemux2  1.4.0-0.1
ii  libwebpmux31.4.0-0.1
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.7-1+b1
ii  libxcb11.17.0-2
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2+b1
ii  libxkbcommon0  1.6.0-1
ii  libxml22.9.14+dfsg-1.3+b3
ii  libxnvctrl0525.125.06-1
ii  libxrandr2 2:1.5.4-1
ii  libxslt1.1 1.1.35-1
ii  xdg-desktop-portal-gnome [xdg-desktop-portal-back  44.2-3
 end]
ii  xdg-desktop-por

Bug#1080021: trixie-pu: package chromium/128.0.6613.113-1~deb13u1

[Andres Salomon]

On 8/29/24 12:32, Andres Salomon wrote:
[...]


The packaging changes between 127.0.6533.119-1 in sid and 
127.0.6533.119-1~deb13u1 remain the same as in past tpus (eg, #1076396). 
See attached.


Oops, I meant the packaging changes between 128.0.6613.113-1 and 
128.0.6613.113-1~deb13u1, of course.




--
I'm available for contract & employment work, please contact me if 
interested.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1080021: trixie-pu: package chromium/128.0.6613.113-1~deb13u1

[Andres Salomon]

Package: release.debian.org
Severity: normal
Tags: trixie
User: release.debian@packages.debian.org
Usertags: pu

As we discussed on IRC, Saturday's bookworm point release would be made 
easier if chromium in trixie were up-to-date with what's in bookworm. 
Given that chromium also has an additional 23 CVEs and 128 is already in 
pretty good shape, let's do another tpu.


The packaging changes between 127.0.6533.119-1 in sid and 
127.0.6533.119-1~deb13u1 remain the same as in past tpus (eg, #1076396). 
See attached.



Thanks,
Andres

--
I'm available for contract & employment work, please contact me if 
interested.
diff -urN chromium-128.0.6613.113-orig/debian/changelog chromium-128.0.6613.113/debian/changelog
--- chromium-128.0.6613.113-orig/debian/changelog	2024-08-14 17:11:25.0 +
+++ chromium-128.0.6613.113/debian/changelog	2024-08-18 01:43:13.173141364 +
@@ -1,3 +1,11 @@
+chromium (128.0.6613.113-1~deb13u1) trixie; urgency=high
+
+  * Rebuild for trixie.
+  * Revert libxml2-dev versioned build-dep, and re-add
+d/patches/bookworm/libxml/parseerr.patch.
+
+ -- Andres Salomon   Sun, 18 Aug 2024 01:41:43 +
+
 chromium (128.0.6613.113-1) unstable; urgency=high
 
   [ Andres Salomon ]
diff -urN chromium-128.0.6613.113-orig/debian/control chromium-128.0.6613.113/debian/control
--- chromium-128.0.6613.113-orig/debian/control	2024-08-08 04:17:58.0 +
+++ chromium-128.0.6613.113/debian/control	2024-08-18 01:43:49.953192381 +
@@ -72,7 +72,7 @@
  libopus-dev,
  libxtst-dev,
  libjpeg-dev,
- libxml2-dev (>= 2.12),
+ libxml2-dev,
  libgtk-3-dev,
  libxslt1-dev,
  liblcms2-dev,
diff -urN chromium-128.0.6613.113-orig/debian/patches/series chromium-128.0.6613.113/debian/patches/series
--- chromium-128.0.6613.113-orig/debian/patches/series	2024-08-14 03:41:47.0 +
+++ chromium-128.0.6613.113/debian/patches/series	2024-08-18 01:43:37.225174796 +
@@ -139,3 +139,6 @@
 # These patches enable full POWER ISA 3.0 (POWER9) acceleration when applied
 # They will not work on POWER8 (ISA 2.07) or below
 #ppc64le/core/baseline-isa-3-0.patch
+
+# build for trixie
+bookworm/libxml-parseerr.patch


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052105: gnome-shell-extension-no-annoyance: needs update for GNOME Shell 46

[Andres Salomon]

Sure, perhaps in two separate MRs though? One for the update from the 
new upstream, and the second to update all the debian/ stuff.


On 8/27/24 22:00, Hank Knox wrote:
Thanks for your response. The update involves getting the source from a 
different project than the one in your version, so it means changing all 
of the files, not just debian/. I do have a freshly-minted salsa 
account. Perhaps I could fork your project, make all the necessary 
changes to the source files and the debian/ files and submit a merge 
request from that? (I've done a very limited amount of work with git, 
more than enough to know there are gaps in my knowledge of how best use 
git.)


Hank

On 8/27/24 21:56, Andres Salomon wrote:
Sorry for the delayed response. I was planning to orphan this package, 
but I wanted to update it before I do that.


There is a git repo for the package here:

https://salsa.debian.org/dilinger/gnome-shell-extension-no-annoyance

If you can update that and submit a merge request for that, I'd 
happily take your updates. Or, if you don't have a salsa account 
and/or don't want to deal with that, a patch (diff -urN) of just the 
debian/ directory.



On 8/20/24 14:27, Hank Knox wrote:
I took the opportunity to learn enough about Debian packaging to 
package the updated fork at https://github.com/jirkavrba/noannoyance 
by taking a snapshot of that repo and modifying the current files in 
debian/. The package installs and runs fine on my own machine. I 
would be happy to contribute this package but am a complete newcomer 
to the Debian developer community and don't know how to best make the 
contribution. I don't want to burden anyone with my ignorance, and 
will happily follow any pointers, advice or instructions.


Hank Knox





--
I'm available for contract & employment work, please contact me if 
interested.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052105: gnome-shell-extension-no-annoyance: needs update for GNOME Shell 46

[Andres Salomon]

Sorry for the delayed response. I was planning to orphan this package, 
but I wanted to update it before I do that.


There is a git repo for the package here:

https://salsa.debian.org/dilinger/gnome-shell-extension-no-annoyance

If you can update that and submit a merge request for that, I'd happily 
take your updates. Or, if you don't have a salsa account and/or don't 
want to deal with that, a patch (diff -urN) of just the debian/ directory.



On 8/20/24 14:27, Hank Knox wrote:
I took the opportunity to learn enough about Debian packaging to package 
the updated fork at https://github.com/jirkavrba/noannoyance by taking a 
snapshot of that repo and modifying the current files in debian/. The 
package installs and runs fine on my own machine. I would be happy to 
contribute this package but am a complete newcomer to the Debian 
developer community and don't know how to best make the contribution. I 
don't want to burden anyone with my ignorance, and will happily follow 
any pointers, advice or instructions.


Hank Knox



--
I'm available for contract & employment work, please contact me if 
interested.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1078945: trixie-pu: package chromium/127.0.6533.119-1~deb13u1

[Andres Salomon]

Package: release.debian.org
Severity: normal
Tags: trixie
User: release.debian@packages.debian.org
Usertags: pu

Chromium is still blocked from migrating by libxml2, and trixie's 
version has racked up 37 CVEs. Now that the sid version builds for all 5 
architectures, it's time for another tpu.


The packaging changes between 127.0.6533.119-1 in sid and 
127.0.6533.119-1~deb13u1 are attached. Same changes as in #1076396.


Thanks,
Andres



--
I'm available for contract & employment work, please contact me if 
interested.
diff -urN a/debian/changelog b/debian/changelog
--- a/debian/changelog	2024-08-14 17:11:25.0 +
+++ b/debian/changelog	2024-08-18 01:43:13.173141364 +
@@ -1,3 +1,11 @@
+chromium (127.0.6533.119-1~deb13u1) trixie; urgency=high
+
+  * Rebuild for trixie.
+  * Revert libxml2-dev versioned build-dep, and re-add
+d/patches/bookworm/libxml/parseerr.patch.
+
+ -- Andres Salomon   Sun, 18 Aug 2024 01:41:43 +
+
 chromium (127.0.6533.119-1) unstable; urgency=high
 
   [ Andres Salomon ]
diff -urN a/debian/control b/debian/control
--- a/debian/control	2024-08-08 04:17:58.0 +
+++ b/debian/control	2024-08-18 01:43:49.953192381 +
@@ -72,7 +72,7 @@
  libopus-dev,
  libxtst-dev,
  libjpeg-dev,
- libxml2-dev (>= 2.12),
+ libxml2-dev,
  libgtk-3-dev,
  libxslt1-dev,
  liblcms2-dev,
diff -urN a/debian/files b/debian/files
--- a/debian/files	1970-01-01 00:00:00.0 +
+++ b/debian/files	2024-08-18 01:46:45.100360598 +
@@ -0,0 +1 @@
+chromium_127.0.6533.119-1~deb13u1_source.buildinfo web optional
diff -urN a/debian/patches/series b/debian/patches/series
--- a/debian/patches/series	2024-08-14 03:41:47.0 +
+++ b/debian/patches/series	2024-08-18 01:43:37.225174796 +
@@ -139,3 +139,6 @@
 # These patches enable full POWER ISA 3.0 (POWER9) acceleration when applied
 # They will not work on POWER8 (ISA 2.07) or below
 #ppc64le/core/baseline-isa-3-0.patch
+
+# build for trixie
+bookworm/libxml-parseerr.patch


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064465: Any progress

[Andres Salomon]

I have a branch that (I think) is mostly ready to go, but just getting 
127 ready has taken a huge amount of time. It still fails to build on arm*.


Once 127 is in better shape (and we update it in trixie), I'll merge the 
branch.



On 8/8/24 18:11, Charles Samuels wrote:

Hi Andres,

Are there additional things I can help with to get this moving along?

It'd be very useful when using Chromium for automated testing, for example,
via puppeteer.

cs



--
I'm available for contract & employment work, please contact me if 
interested.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1078105: chromium (and chrome!) on Sid (only) have an event propogation issue

[Andres Salomon]

It's normal when they mark it as a security issue. Otherwise, no.

I agree that the whole sid-specific thing makes it sound like it's 
relate to an upgraded library (eg, xorg libs); especially since we're 
using the same compiler version in sid and bookworm. I'm unfortunately 
unable to reproduce this in a virtualbox instance (cinnamon/X nor 
gnome/wayland), so it could also be something driver-related, too.



On 8/6/24 22:42, Phil Dibowitz wrote:

Woah. Is that... normal?

I no longer have access. :(

It's weird it _only_ happens on Sid, which is why I also wanted to 
report it here... like there's some dependency in sid that causes an issue?


Anyway - I know a bunch of Googler's, I'll see if I can track something 
down.


Thanks!

On 8/6/24 7:32 PM, Andres Salomon wrote:

On 8/6/24 20:31, Phil Dibowitz wrote:
[...]


Upstream bug:
https://issues.chromium.org/issues/357905828


D'oh, locked down already.

Thank you for reporting this - if you still have permission to view 
the upstream bug, please let us know when it's fixed.




--
I'm available for contract & employment work, please contact me if 
interested.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1078105: chromium (and chrome!) on Sid (only) have an event propogation issue

[Andres Salomon]

On 8/6/24 20:31, Phil Dibowitz wrote:
[...]


Upstream bug:
https://issues.chromium.org/issues/357905828


D'oh, locked down already.

Thank you for reporting this - if you still have permission to view the 
upstream bug, please let us know when it's fixed.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1033747: chromium: Build Chromium without the embedded libtiff

[Andres Salomon]

It's unfortunately going to have to wait. We're switching standard 
libraries, and linking to external libs is a bit rocky right now.


On the plus side, I reduced the time it takes to generate the 
orig.tar.xz from ~40 minutes to ~5 minutes, which should help a lot with 
testing the deletion of vendored libraries in the future!



On 7/22/24 13:55, Soren Stoutner wrote:

Can you add support for building with libtiff now that upstream has included
the appropriate plumbing and removed their dependency on the private header?



--
I'm available for contract & employment work, see:
https://spindle.queued.net/~dilinger/resume-tech.pdf


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074059: bookworm-pu: package nodejs/18.19.0+dfsg-6~deb12u2

[Andres Salomon]

On 7/4/24 03:01, Jérémy Lal wrote:



Le jeu. 4 juil. 2024 à 06:33, Salvatore Bonaccorso <mailto:car...@debian.org>> a écrit :


Hi,

On Wed, Jul 03, 2024 at 11:36:46PM +0200, Jérémy Lal wrote:
 > Le mer. 3 juil. 2024 à 23:04, Andres Salomon mailto:dilin...@queued.net>> a écrit :

[...]

 > > While we wait for this, is there any reason to keep the existing
 > > 18.20.3+dfsg-1~deb12u1 upload in the embargoed security queue?
Security
 > > packages are actively building against it, which is a bit of a
problem
 > > for reproducibility. Someone actually asked me about oddities
in the
 > > chromium package that was originally built for
bookworm-security, and
 > > now sits in the 12.6 point release. It turns out that it built
against
 > > the embargoed nodejs, but since that nodejs package was never
released,
 > > they can't use it to reproduce the chromium in 12.6.
 > >
 > > If there's a new nodejs bookworm-security package being
uploaded at some
 > > point and the currently embargoed nodejs package will never be
released,
 > > perhaps we should REJECT it now?
 > >
 >
 > Sorry, probably me being overbooked here.
 > I was supposed to check the regressions against it, and been on
another job
 > since then.

Aron is taking care of the DSA, so I do not want to interfer here with
his planning, but sharing an idea: There will be an upcoming release
for nodejs on Monday, 8th (actually was planned for today):
https://nodejs.org/en/blog/vulnerability/july-2024-security-releases
<https://nodejs.org/en/blog/vulnerability/july-2024-security-releases>

Do you think you will be less overbooked, can review the regression
report and with Aron's help work on fixing the new CVEs for mondays
release and we base the update upon that?


Yes, I'll have more time next week, so it's doable.


Again, I do not mean to interfer here with Aron was thinking about
releasing the packages.



I just uploaded another chromium security update, and it's once again 
building against a version of nodejs that hasn't been released to the 
public.


I encourage Jérémy to take as long as he needs to in ensuring that the 
nodejs upload (whether 18.19.x or 18.20.x) is properly tested and to his 
preferred standard of quality rather than attempting to squeeze it in 
based on my nagging him. And I also want to thank him for his continued 
handling of nodejs.


However, in the meantime while we wait for the nodejs upload to be ready 
for release, I'd encourage the security team to:


a) REJECT the upload until Jérémy has time to ensure it's ready for 
release (unless Jérémy objects), and


b) come up with a policy about how long embargoed security uploads that 
aren't quite ready for release can sit in the queue (and get used by 
other uploads for building) before removing them.


Thanks,
Andres

--
I'm available for contract & employment work, see:
https://spindle.queued.net/~dilinger/resume-tech.pdf


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076396: trixie-pu: package chromium/126.0.6478.126-1~deb13u1

[Andres Salomon]

Package: release.debian.org
Severity: normal
Tags: trixie
User: release.debian@packages.debian.org
Usertags: pu

Chromium has been blocked from migrating to testing by libxml2 for 
roughly two months now. There are 38 CVEs that have been fixed between 
the version currently in trixie (125.0.6422.60-1) and the version in sid
(126.0.6478.126-1). Several folks have asked for an updated version via 
tpu, so here we go again.


The packaging changes between 126.0.6478.126-1 in sid and 
126.0.6478.126-1~deb13u1 are attached.


Thanks,
Andres


--
I'm available for contract & employment work, see:
https://spindle.queued.net/~dilinger/resume-tech.pdf
diff -urN a/debian/changelog b/debian/changelog
--- a/debian/changelog	2024-06-25 07:28:40.0 +
+++ b/debian/changelog	2024-07-15 05:33:07.037062746 +
@@ -1,3 +1,11 @@
+chromium (126.0.6478.126-1~deb13u1) trixie; urgency=high
+
+  * Rebuild for trixie.
+  * Revert libxml2-dev versioned build dep, and re-add 
+d/patches/fixes/libxml-parseerr.patch.
+
+ -- Andres Salomon   Mon, 15 Jul 2024 05:28:21 +
+
 chromium (126.0.6478.126-1) unstable; urgency=high
 
   * New upstream security release.
diff -urN a/debian/control b/debian/control
--- a/debian/control	2024-06-25 07:28:40.0 +
+++ b/debian/control	2024-07-15 05:33:22.229088115 +
@@ -69,7 +69,7 @@
  libopus-dev,
  libxtst-dev,
  libjpeg-dev,
- libxml2-dev (>= 2.12),
+ libxml2-dev,
  libgtk-3-dev,
  libxslt1-dev,
  liblcms2-dev,
diff -urN a/debian/patches/series b/debian/patches/series
--- a/debian/patches/series	2024-06-25 07:28:40.0 +
+++ b/debian/patches/series	2024-07-15 05:40:59.241778940 +
@@ -144,3 +144,6 @@
 # These patches enable full POWER ISA 3.0 (POWER9) acceleration when applied
 # They will not work on POWER8 (ISA 2.07) or below
 #ppc64le/core/baseline-isa-3-0.patch
+
+# build for trixie
+bookworm/libxml-parseerr.patch


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076300: chromium: build against the version of libxml2 in testing and upload to testing-security

[Andres Salomon]

On Sun, 14 Jul 2024 09:26:32 +0200 Salvatore Bonaccorso 
 wrote:

Hi,

On Sat, Jul 13, 2024 at 09:55:25PM +0200, Amr Ibrahim wrote:
> Package: chromium
> Version: 125.0.6422.60-1
> Severity: normal
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> Dear Maintainer,
> 
> Could you please build chromium against the version of libxml2 in testing and

> upload to testing-security because going through unstable has been delayed for
> a long time?

At this stage of  the release ongoing for trixie chromium needs to go
via regular paths to testing. So closing the report.



Fwiw, I am planning to do a tpu upload (having officially given up on 
expecting libxml to transition anytime soon). No need to reopen the bug 
report, though.



--
I'm available for contract & employment work, see:
https://spindle.queued.net/~dilinger/resume-tech.pdf


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1073508: libxml2: just another API+ABI break; please bump soname

[Andres Salomon]

On Tue, 25 Jun 2024 04:17:09 -0400 Andres Salomon  
wrote:

[...]


The libxml package is currently keeping chromium from migrating to 
trixie, so I'm looking forward to this getting sorted out (whether 
upstream or with an SONAME bump or what).



Hi,

I'm just curious what the status is with fixing this. I saw an upload to 
experimental; is something planned for sid?


Thanks,
Andres


--
I'm available for contract & employment work, see:
https://spindle.queued.net/~dilinger/resume-tech.pdf


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072299: Compositor-related crashes

[Andres Salomon]

On 7/12/24 03:34, Daniel Richard G. wrote:

I did another round of debugging, and have some new findings to report.

To start with, I put a breakpoint on OnNoMemoryInternal(). That works
better than trying to catch the SIGILL. However, this failure mode has
been relatively infrequent with my modified 126.0.6478.126 build.

More common lately has been a straight segfault related to Mojo that
invariably brings down the entire browser. Here is a typical example:

 Thread 1 "chromium" received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x7f92e4ff8480 (LWP 876682)]
 0x55c72dfed9c2 in 
mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept(mojo::Message*)
 ()
 (gdb) bt
 #0  0x55c72dfed9c2 in 
mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept(mojo::Message*)
 ()


This is calling  owner_->HandleValidatedMessage(message), with owner_ 
likely having been initialized with invalid memory in the constructor. 
owner_ is a pointer to an InterfaceEndpointClient object.



 #1  0x55c72dff5314 in mojo::MessageDispatcher::Accept(mojo::Message*) 
()


This one is checking if validator_ (which is a 
HandleIncomingMessageThunk object) is not null, and then calls 
validator_->Accept(). So that InterfaceEndpointClient object that ends 
up in owner_ would've been passed to the validator_ constructor. The 
validator_ is copied over either via MessageDispatcher::SetValidator() 
or MessageDispatcher::operator=().


The operator= is a bit hard to grep for, but SetValidator() is called 
inside of the InterfaceEndpointClient() constructor (with the 3rd 
constructor arg).


Following the twisty maze of virtual classes (sigh, c++), I end up in 
the AssociatedRemote class, with internal_state_.Bind() passing along 
task_runner which is that InterfaceEndpointClient object.


At this point I get lost, but I was looking to see if GetTaskRunner() is 
attempting to allocate memory, failing, and returning null. It *will* 
return null in various places, but there are so many places that it's 
called from that it's hard to tell what's going on.





 #2  0x55c72dfefbed in 
mojo::InterfaceEndpointClient::HandleIncomingMessage(mojo::Message*) ()
 #3  0x55c72dff9496 in 
mojo::internal::MultiplexRouter::ProcessIncomingMessage(mojo::internal::MultiplexRouter::MessageWrapper*,
 mojo::internal::MultiplexRouter::ClientCallBehavior, 
base::SequencedTaskRunner*) ()
 #4  0x55c72dff8c73 in 
mojo::internal::MultiplexRouter::Accept(mojo::Message*) ()
 #5  0x55c72dff5314 in mojo::MessageDispatcher::Accept(mojo::Message*) 
()
 #6  0x55c72dfeb74e in 
mojo::Connector::DispatchMessage(mojo::ScopedHandleBase) ()
 #7  0x55c72dfebeda in mojo::Connector::ReadAllAvailableMessages() ()
 #8  0x55c72d7e03ff in 
base::TaskAnnotator::RunTaskImpl(base::PendingTask&)
 ()
 #9  0x55c72d801667 in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() 
()
 #10 0x55c72d873e6a in base::(anonymous 
namespace)::WorkSourceDispatch(_GSource*, int (*)(void*), void*) ()
 #11 0x7f92e80b97a9 in g_main_context_dispatch ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 #12 0x7f92e80b9a38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 #13 0x7f92e80b9acc in g_main_context_iteration ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 #14 0x55c72d872c00 in 
base::MessagePumpGlib::Run(base::MessagePump::Delegate*) ()
 #15 0x55c72d802190 in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool,
 base::TimeDelta) ()
 #16 0x55c72d7c18a9 in base::RunLoop::Run(base::Location const&) ()
 #17 0x55c72adc4fda in content::BrowserMainLoop::RunMainMessageLoop() ()
 #18 0x55c72adc114d in 
content::BrowserMain(content::MainFunctionParams) ()
 #19 0x55c72ca25b49 in 
content::ContentMainRunnerImpl::RunBrowser(content::MainFunctionParams, bool) ()
 #20 0x55c72ca25637 in content::ContentMainRunnerImpl::Run() ()
 #21 0x55c72ca221a4 in content::ContentMain(content::ContentMainParams) 
()
 #22 0x55c7284eafc5 in ChromeMain ()
 #23 0x7f92e644624a in __libc_start_call_main (
 main=main@entry=0x55c7284eac60 , argc=argc@entry=8,
 argv=0x7ffdc854dc48, argv@entry=0xec0002740e0)
 at ../sysdeps/nptl/libc_start_call_main.h:58
 #24 0x7f92e6446305 in __libc_start_main_impl (main=0x55c7284eac60 
,
 argc=8, argv=0xec0002740e0, init=, fini=,
 rtld_fini=, stack_end=0x7ffdc854dc38)
 at ../csu/libc-start.c:360
 #25 0x55c728167021 in _start ()

Right before, I'll get a message on the terminal like

 [885352:885352:0709/095917.737560:ERROR:interface_endpoint_client.cc(722)] 
Message 0 rejected by interface viz.mojom.Gpu

 [890042:890062:0709/222611.345773:ERROR:interface_endpoint_client.cc(722)] 
Message 0 rejected by interface blink.mojom.

Bug#1074059: bookworm-pu: package nodejs/18.19.0+dfsg-6~deb12u2

[Andres Salomon]

On 6/25/24 16:34, Jérémy Lal wrote:



Le mar. 25 juin 2024 à 22:22, Salvatore Bonaccorso > a écrit :

[...]


Thanks a lot for your work Adrian. Please note that there is currently
a nodejs upload pending for releasing via a DSA, which will rebase
nodejs to 18.20.3+dfsg-1~deb12u1 so this might invalidate those
changes.

Jérémy, Aron is that something you want to have included in your
prepared update?


Indeed, it's applied to 18.20.3+dfsg-1~deb12u1, along with other skipped 
tests.

I'll resume work on this by the end of the week.



While we wait for this, is there any reason to keep the existing 
18.20.3+dfsg-1~deb12u1 upload in the embargoed security queue? Security 
packages are actively building against it, which is a bit of a problem 
for reproducibility. Someone actually asked me about oddities in the 
chromium package that was originally built for bookworm-security, and 
now sits in the 12.6 point release. It turns out that it built against 
the embargoed nodejs, but since that nodejs package was never released, 
they can't use it to reproduce the chromium in 12.6.


If there's a new nodejs bookworm-security package being uploaded at some 
point and the currently embargoed nodejs package will never be released, 
perhaps we should REJECT it now?


--
I'm available for contract & employment work, see:
https://spindle.queued.net/~dilinger/resume-tech.pdf


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072299: Compositor-related crashes

[Andres Salomon]

On 6/25/24 00:23, Daniel Richard G. wrote:

On Thu, 2024 Jun 13 15:07-04:00, Andres Salomon wrote:


Oops, sorry, I didn't see this email. Let me finish getting v126 out the
door, and then circle back if the crash is still present there.


I still see the problem with .114, alas. Tabs crash, sometimes the whole
browser goes. I often leave my home PC with Chromium up in the morning,
only to find it gone in the evening.

While stopping on SIGILL has not caught the crashes leading to the
"invalid opcode" syslog error, GDB does occasionally stop at a location
indicating an out of memory condition. Here is a typical backtrace:

 (gdb) bt
 #0  0x5572f6c3dc4d in 
partition_alloc::internal::OnNoMemoryInternal(unsigned long) ()
 #1  0x5572f6c3dc59 in 
partition_alloc::TerminateBecauseOutOfMemory(unsigned long) ()
 #2  0x5572f31a33cf in 
gpu::ClientSharedImageInterface::CreateSharedImage(gpu::SharedImageInfo const&) 
()
 #3  0x5572f82ba0bd in 
cc::BitmapRasterBufferProvider::AcquireBufferForRaster(cc::ResourcePool::InUsePoolResource
 const&, unsigned long, unsigned long, bool, bool, bool) ()
 #4  0x5572f8225d8f in cc::TileManager::CreateRasterTask(cc::PrioritizedTile 
const&, cc::TargetColorParams const&, 
cc::TileManager::PrioritizedWorkToSchedule*) ()
 #5  0x5572f82237f4 in cc::TileManager::AssignGpuMemoryToTiles() ()
 [...]




That backtrace makes sense; it's running OnNoMemoryInternal(), which 
calls PA_IMMEDIATE_CRASH(), which generates an invalid opcode customized 
for various architectures (ironically to provide a better backtrace 
compared to calling abort() or something).


It's a maze of #ifdefs, but it appears that on x86, it calls 'int3' 
(which should emit SIGTRAP), followed by 'ud2' (undefined instruction). 
You can probably get gdb to catch the SIGTRAP, but that honestly doesn't 
help diagnose _why_ you're running out of memory.


I don't know how chromium handles GPU memory, but I wonder if the issue 
is that GPU memory can't be swapped, and the partition allocator is just 
grabbing way too much of it and wasting it?


Try changing the following in 
base/allocator/partition_allocator/src/partition_alloc/partition_alloc_constants.h 
, around line 144:


constexpr size_t kMaxPartitionPagesPerRegularSlotSpan = 4;

Change that value to be 3 or 2, and see if that helps. Keep in mind by 
doing this you're trading memory for speed, so memory allocations might 
be a bit slower.


If that doesn't help, it could also be that the CreateSharedImage() code 
for your specific graphics driver is leaking memory or something. If you 
can try a different graphics driver/stack, that could also point to a 
specific bug in the driver.




I am running Chromium under strong memory pressure (3 GB RAM with
hundreds of tabs open), but with a good amount of swap space (16 GB) of
which not more than 2 GB is typically used. When loading a new page or
the like, Chromium will sometimes spend a few seconds paging to swap,
and at other times it will crash. Prior to this bug report, however, the
crashes were very rare---swap access may have slowed things down, but
the browser otherwise ran like a tank. Now, I often get crashes in the
middle of typing text into a form window, which is especially
aggravating as the text is not restored with the page.

I have Memory Saver enabled. Are there any other settings you're aware
of that I should experiment with? I already keep an eye on Chromium's
Task Manager with the "Memory footprint" column in descending order, so
if a site goes nuts with RAM usage, I can usually catch it.



Memory Saver is exactly what I was going to recommend as a workaround, 
before I saw the backtrace.  ;)




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1073508: libxml2: just another API+ABI break; please bump soname

[Andres Salomon]

On Mon, 17 Jun 2024 16:38:58 +0200 (CEST) Thorsten Glaser 
 wrote:

On Mon, 17 Jun 2024, Aron Xu wrote:

>Control: tags -1 - pending

Oops, right.

>It looks that this libxml2 update is causing more troubles than
>expected, I would like to ask for your opinion whether it's better to
>revert to an older version for the moment?

Might be useful while you ask upstream what they’re doing there
with regards to both API and ABI, and/or someone diffs the API
and ABI surface of the old and new version and figures out whether
there are any other such surprises. Security fixes might need
backporting though.

Maybe they haven’t realised themselves and decide they need to
bump to libxml3 upstream at some point.


There's also a new upstream release (2.13), which probably also breaks 
the API/ABI from 2.12 again. So it might be worth jumping right to 2.13 
if you need to take a trip through NEW.


tree.h:
-XMLPUBFUN void
+XMLPUBFUN int
xmlSetTreeDoc   (xmlNodePtr tree,
 xmlDocPtr doc);
-XMLPUBFUN void
+XMLPUBFUN int
xmlSetListDoc   (xmlNodePtr list,
 xmlDocPtr doc);


parser.h:
@@ -327,6 +313,9 @@
 xmlParserNsData   *nsdb;/* namespace database */
 unsignedattrHashMax;/* allocated size */
 xmlAttrHashBucket *attrHash;/* atttribute hash table */
+
+xmlStructuredErrorFunc errorHandler;
+void *errorCtxt;
 };


The libxml package is currently keeping chromium from migrating to 
trixie, so I'm looking forward to this getting sorted out (whether 
upstream or with an SONAME bump or what).


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1073378: 1073378 chromium with 'Restore Pages' message

[Andres Salomon]

On 6/18/24 23:45, Andres Salomon wrote:
I noticed that chromium segfaults upon exit; I suspect that this is why 
the Restore Pages message pops up. I'll look into that segfault when I 
have more free time available.



Okay, here's the backtrace. There were a bunch of commits back in May to 
components/autofill/core/browser/address_data_manager.* and 
components/autofill/core/browser/geo/alternative_state_name_map_updater.* 
that is likely the culprit. I'm investigating further now.



Thread 1 "chromium" received signal SIGSEGV, Segmentation fault.
0x5c5f327c in base::internal::WeakReference::IsValid() const ()
(gdb) bt
#0  0x5c5f327c in base::internal::WeakReference::IsValid() const ()
#1  0x57d3d27c in 
__gnu_cxx::__normal_iteratorstd::vectorstd::allocator > > 
std::__find_if<__gnu_cxx::__normal_iteratorstd::vectorstd::allocator > >, 
__gnu_cxx::__ops::_Iter_predfalse, true, 
base::internal::CheckedObserverAdapter>::RemoveObserver(base::BatteryStateSampler::Observer 
const*)::{lambda(auto:1 const&)#1}, 
std::identity>(base::ObserverListfalse, true, 
base::internal::CheckedObserverAdapter>::RemoveObserver(base::BatteryStateSampler::Observer 
const*)::{lambda(auto:1 const&)#1}&, 
std::identity&)::{lambda(auto:1&&)#1}> 
>(__gnu_cxx::__normal_iteratorstd::vectorstd::allocator > >, 
__gnu_cxx::__normal_iteratorstd::vectorstd::allocator > >, 
__gnu_cxx::__ops::_Iter_predfalse, true, 
base::internal::CheckedObserverAdapter>::RemoveObserver(base::BatteryStateSampler::Observer 
const*)::{lambda(auto:1 const&)#1}, 
std::identity>(base::ObserverListfalse, true, 
base::internal::CheckedObserverAdapter>::RemoveObserver(base::BatteryStateSampler::Observer 
const*)::{lambda(auto:1 const&--Type  for more, q to quit, c to 
continue without paging--
)#1}&, std::identity&)::{lambda(auto:1&&)#1}>, 
std::random_access_iterator_tag)

()
#2  0x57d37eda in 
base::ObserverListbase::internal::CheckedObserverAdapter>::RemoveObserver(base::BatteryStateSampler::Observer 
const*) ()
#3  0x5f012998 in 
autofill::AlternativeStateNameMapUpdater::~AlternativeStateNameMapUpdater() 
()
#4  0x5f012abe in 
autofill::AlternativeStateNameMapUpdater::~AlternativeStateNameMapUpdater() 
()
#5  0x5f00c724 in 
autofill::AddressDataManager::~AddressDataManager()

()
#6  0x5f00cafe in 
autofill::AddressDataManager::~AddressDataManager()

()
#7  0x5f00b234 in 
autofill::PersonalDataManager::~PersonalDataManager()

()
#8  0x5f00b37e in 
autofill::PersonalDataManager::~PersonalDataManager()

()
#9  0x5dbfbb64 in KeyedServiceFactory::Disassociate(void*) ()
#10 0x5dbfbd82 in KeyedServiceFactory::ContextDestroyed(void*) ()
#11 0x5dbfa5cc in 
DependencyManager::PerformInterlockedTwoPhaseShutdown(DependencyManager*, 
void*, DependencyManager*, void*) ()

#12 0x5c22bc5d in ProfileImpl::~ProfileImpl() ()
#13 0x5c22be8e in ProfileImpl::~ProfileImpl() ()
--Type  for more, q to quit, c to continue without paging--
#14 0x5c22f687 in 
ProfileDestroyer::DestroyOriginalProfileNow(std::unique_ptrstd::default_delete >) ()
#15 0x5c230354 in 
OriginalProfileDestroyer::DoDestroyUnderlyingProfile() ()
#16 0x5c22edba in 
ProfileDestroyer::Start(std::setstd::less, 
std::allocator > const&) ()
#17 0x5c22e7e7 in 
ProfileDestroyer::DestroyOriginalProfileWhenAppropriateWithTimeout(std::unique_ptrstd::default_delete >, base::TimeDelta) ()
#18 0x5c22e671 in 
ProfileDestroyer::DestroyOriginalProfileWhenAppropriate(std::unique_ptrstd::default_delete >) ()


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074077: chromium: [0622/170142.247899:ERROR:elf_dynamic_array_reader.h(64)] tag not found

[Andres Salomon]

Since this is hardware-specific, I likely won't be able to reproduce it. 
Please file a bug upstream (at https://crbug.com/), include the specific 
hardware/motherboard (and maybe dmesg output) in your bug report, and 
respond to this bug report with a link to the upstream bug. Thanks!


On 6/22/24 18:09, Jon Davis wrote:

Package: chromium
Version: 125.0.6422.60-1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where 
appropriate ***


    * What led up to the situation?

     After a motherboard upgrade, chromium and all other available 
versions of

     the browser failed to run.

    * What exactly did you do (or not do) that was effective (or
      ineffective)?

     Trying other versions of chrome caused the same error message and core
     dump.

* What was the outcome of this action?

      Suspicion that the chrome browsers have a race condition bug in the
      initialization process, triggered by the higher CPU clock speed.

      The initial browser with a 125... version which failed was operating
      fine with the old motherboard running at 2GHz.

    * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: trixie/sid
   APT prefers testing
   APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common                                    125.0.6422.60-1
ii  libasound2t64                                      1.2.11-1+b1
ii  libatk-bridge2.0-0t64                              2.52.0-1
ii  libatk1.0-0t64                                     2.52.0-1
ii  libatomic1                                         14-20240330-1
ii  libatspi2.0-0t64                                   2.52.0-1
ii  libc6                                              2.38-13
ii  libcairo2                                          1.18.0-3+b1
ii  libcups2t64                                        2.4.7-3
ii  libdav1d7                                          1:1.4.3-dmo1
ii  libdbus-1-3                                        1.14.10-4+b1
ii  libdouble-conversion3                              3.3.0-1+b1
ii  libdrm2                                            2.4.121-2
ii  libevent-2.1-7t64                                  2.1.12-stable-10
ii  libexpat1                                          2.6.2-1
ii  libflac12t64                                       1.4.3+ds-2.1
ii  libfontconfig1                                     2.15.0-1.1
ii  libfreetype6                                       2.13.2+dfsg-1+b4
ii  libgbm1                                            24.0.8-1
ii  libgcc-s1                                          14-20240330-1
ii  libglib2.0-0t64                                    2.80.2-2
ii  libgtk-3-0t64                                      3.24.42-1
ii  libharfbuzz-subset0                                8.3.0-2+b1
ii  libharfbuzz0b                                      8.3.0-2+b1
ii  libjpeg62-turbo                                    1:2.1.5-3
ii  libjsoncpp25                                       1.9.5-6+b2
ii  liblcms2-2                                         2.14-2+b1
ii  libminizip1t64 
1:1.3.dfsg+really1.3.1-1

ii  libnspr4                                           2:4.35-1.1+b1
ii  libnss3                                            2:3.101-1
ii  libopenh264-7                                      1:2.4.1-dmo1
ii  libopenjp2-7                                       2.5.0-2+b3
ii  libopus0                                           1.4-1+b1
ii  libpango-1.0-0                                     1.54.0+ds-1
ii  libpng16-16t64                                     1.6.43-5
ii  libpulse0                                          16.1+dfsg1-5.1
ii  libsnappy1v5                                       1.2.1-1
ii  libstdc++6                                         14-20240330-1
ii  libwoff1                                           1.0.2-2+b1
ii  libx11-6                                           2:1.8.7-1+b1
ii  libxcb1                                            1.17.0-2
ii  libxcomposite1                                     1:0.4.5-1+b1
ii  libxdamage1                                        1:1.1.6-1+b1
ii  libxext6                                           2:1.3.4-1+b1
ii  libxfixes3                                         1:6.0.0-2+b1
ii  libxkbcommon0                                      1.6.0-1+b1
ii  libxml2                                            2.9.14+dfsg-1.3+b3
ii  libxnvctrl0                                        535.171.04-1
ii  libxrandr2                                         2:1.5.4-1
ii  libxslt1.1                                         1.1.35-1+b1
ii  xdg-desktop

Bug#1073378: 1073378 chromium with 'Restore Pages' message

[Andres Salomon]

I noticed that chromium segfaults upon exit; I suspect that this is why 
the Restore Pages message pops up. I'll look into that segfault when I 
have more free time available.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072299: Compositor-related crashes

[Andres Salomon]

On 5/31/24 18:59, Daniel Richard G. wrote:

On Fri, 2024 May 31 18:36-04:00, Andres Salomon wrote:


I'm going from memory here, but I believe the dak installation on
security.debian.org doesn't keep dbgsym packages for historical reasons.
Thus, they're only available once chromium gets moved to
stable-proposed-updates. https://tracker.debian.org/pkg/chromium shows
.60 as being the last one in stable-p-u. At some point in the next week
or two, someone from the release team will likely accept the newer
chromium packages into stable-p-u, at which point the dbgsym packages
for .141 (or whatever the latest version is) will be available.


Eeegh, not a great state of affairs for a package that revs this often.


Oh! Apparently my info is outdated. According to 
<https://bugs.debian.org/894081>, this was fixed back in August. It does 
indeed look like
<https://deb.debian.org/debian-security-debug/pool/updates/main/c/chromium/> 
has the dbgsym packages for .141.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072299: Compositor-related crashes

[Andres Salomon]

On 5/31/24 15:51, Daniel Richard G. wrote:

I believe I've found a correlation: The crashes seem to have started
with an instance of firefox-esr (115.11.0esr-1~deb12u1) that I was
running on the side, since earlier today. Once I closed Firefox, the
crashiness went away, completely.

(This is on the same laptop that needs --use-gl=egl to avoid visual
artifacts, so that might have something to do with this)

On Fri, 2024 May 31 15:27-04:00, Andres Salomon wrote:


Interesting. Any chance of a backtrace (with the chromium-dbgsym
package)? I'm wondering if some (bundled) third party lib has started
requiring newer cpu extensions or something.


I'm happy to provide this, but two questions:

1. In http://debug.mirrors.debian.org/debian-debug/pool/main/c/chromium/
as well as https://deb.debian.org/debian-debug/pool/main/c/chromium/,
I don't see any packages with a matching version string of
"125.0.6422.112-1~deb12u1" (and .141 isn't there yet). Am I missing
something?


I'm going from memory here, but I believe the dak installation on 
security.debian.org doesn't keep dbgsym packages for historical reasons. 
Thus, they're only available once chromium gets moved to 
stable-proposed-updates. https://tracker.debian.org/pkg/chromium shows 
.60 as being the last one in stable-p-u. At some point in the next week 
or two, someone from the release team will likely accept the newer 
chromium packages into stable-p-u, at which point the dbgsym packages 
for .141 (or whatever the latest version is) will be available.


It sucks, but it is what it is. You could either spend a bunch of time 
building chromium for the dbgsym packages, or I could put my local build 
of .141 online w/ dbgsym packages for you to try out (assuming amd64?), 
or you could downgrade to .60 and use those dbgsym packages.






2. To get the stack trace, is the right way just running the whole
thing in GDB, using "chromium -g"? Or do you set it up to make a
core dump? (Sure would be nice to have an Apport-like after-the-fact
workflow for this)




Yes, just running 'chromium -g' will launch it inside gdb; you may have 
to manually type 'run' to start it inside gdb, I forget.  But then 
you'll get a backtrace (or you can ctrl-c and run 'bt', if it's a 
deadlock or something). I haven't bothered w/ core dumps of chromium 
before, so I can't speak to that.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072299: Compositor-related crashes

[Andres Salomon]

On 5/31/24 14:48, Daniel Richard G. wrote:

Package: chromium
Version: 125.0.6422.112-1~deb12u1
Severity: important

Recently, I have been observing crashes of individual tabs, and even
of the entire browser, when navigating some Web pages. The crashed
tabs correlate with the following syslog messages (multiple instances
listed below):

2024-05-31T12:42:35.334876-04:00 runabout kernel: [1324259.940186] traps: 
Compositor[125485] trap invalid opcode ip:55a9cc8c18cd sp:7ff9a0ded490 error:0 
in chromium[55a9c7e22000+b13d000]
2024-05-31T12:57:20.174268-04:00 runabout kernel: [1325144.782743] traps: 
Compositor[125761] trap invalid opcode ip:55a9cc8c18cd sp:7ff9a0ded1e0 error:0 
in chromium[55a9c7e22000+b13d000]
2024-05-31T13:24:20.059327-04:00 runabout kernel: [1326764.664063] traps: 
Compositor[126515] trap invalid opcode ip:55daaca498cd sp:7f9f6c1ed1e0 error:0 
in chromium[55daa7faa000+b13d000]
2024-05-31T13:55:26.767783-04:00 runabout kernel: [1328631.258090] traps: 
Compositor[126307] trap invalid opcode ip:55daaca498cd sp:7f9f6c1ecfb0 error:0 
in chromium[55daa7faa000+b13d000]

The whole-browser crash occurs with no unusual messages to syslog or
~/.xsession-errors, strangely enough.

And even stranger, only today (May 31) have I started observing these
crashes. This particular version has been installed and running fine
since May 23, and now it's crashing left and right. /var/log/dpkg.log
shows no new package installs since the 25th, and I haven't futzed with
any configurations for at least that long.

Since the error relates to an invalid opcode, I'll include some details
about the CPU:

vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 CPU T7200  @ 2.00GHz
stepping: 6
microcode   : 0xc7
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti tpr_shadow dtherm


--Daniel


Interesting. Any chance of a backtrace (with the chromium-dbgsym 
package)? I'm wondering if some (bundled) third party lib has started 
requiring newer cpu extensions or something.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071662: chromium: Wrapper script does not correctly pass arguments to Chromium

[Andres Salomon]

Thanks for the heads up. While I work on fixing this, a temporary 
workaround you can use is ' -- ' before --user-agent. Eg,


chromium --headless --no-sandbox -- --user-agent="Mozilla/5.0 
(Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like 
Gecko) Chrome/41.0.2227.1 Safari/537.36"


On 5/23/24 07:11, Remco de Man wrote:

Package: chromium
Version: 125.0.6422.76-1~deb12u1
Severity: normal

Dear Maintainer,

When running 125.0.6422.76-1~deb12u1, when passing arguments to the chromium
wrapper script included in the Debian package, not all arguments are passed
correctly to the Chromium binary.

This happens especially when the arguments need any type of quoting, like
in the case of passing a custom User-Agent with --user-agent.

A minimal reproduction sample for me is running the following command:

chromium --headless --no-sandbox --user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS 
X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 Safari/537.36"

It seems that because the user agent contains spaces, this is not correctly
passed to the chromium binary. The regression was not present in the previous
security release, 125.0.6422.60-1~deb12u1, and seems to be caused by change
https://salsa.debian.org/chromium-team/chromium/-/commit/dc792dc4f3bfdd3e00f5fe7b7bf314077ed301bb

Because of this, many of our headless usage scenarios do not work correctly
anymore, since Chromium exits with the 'Multiple targets are not supported'
message, because it parses some of the user agent as seperate arguments to
its binary.

Seems like the wrapper script should be patched to handle this scenario,
or the change should be reverted.

-- System Information:
Debian Release: 12.5
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.82 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages chromium depends on:
ii  chromium-common125.0.6422.76-1~deb12u1
ii  libasound2 1.2.8-1+b1
ii  libatk-bridge2.0-0 2.46.0-5
ii  libatk1.0-02.46.0-5
ii  libatomic1 12.2.0-14
ii  libatspi2.0-0  2.46.0-5
ii  libc6  2.36-9+deb12u7
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-3+deb12u5
ii  libdav1d6  1.0.0-2+deb12u1
ii  libdbus-1-31.14.10-1~deb12u1
ii  libdouble-conversion3  3.2.1-1
ii  libdrm22.4.114-1+b1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-1
ii  libflac12  1.4.2+ds-2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-5
ii  libgbm122.3.6-1+deb12u1
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.6-2+deb12u2
ii  libgtk-3-0 3.24.38-2~deb12u1
ii  libharfbuzz-subset06.0.0+dfsg-3
ii  libharfbuzz0b  6.0.0+dfsg-3
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-4
ii  liblcms2-2 2.14-2
ii  libminizip11.1-8+deb12u1
ii  libnspr4   2:4.35-1
ii  libnss32:3.87.1-1
ii  libopenh264-7  2.3.1+dfsg-3
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.3.1-3
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpng16-161.6.39-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.9-3
ii  libstdc++6 12.2.0-14
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.3~deb12u1
ii  libxnvctrl0525.85.05-3~deb12u1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  125.0.6422.76-1~deb12u1

Versions of packages chromium suggests:
ii  chromium-driver  125.0.6422.76-1~deb12u1
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6 2.36-9+deb12u7
ii  libdrm2   2.4.114-1+b1
ii  libjsoncpp25  1.9.5-4
ii  libstdc++612.2.0-14
ii  libx11-6  2:1.8.4-2+deb12u2
ii  libxnvctrl0   525.85.05-3~deb12u1
ii  x11-utils 7.7+5
ii  xdg-utils 1.1.3-4.1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox   125.0.6422.76-1~deb12u1
pn  fonts-liberation   
ii  libgl1-mesa-dri22.3.6-1+deb12u1
pn  notification-daemon
pn  system-config-printer  
pn  udev   
pn  upower 

Versions of packages chromium-

Bug#1064465: chromium: Chromium cannot use webgl without X (should be compiled with swiftshader)

[Andres Salomon]

On 2/22/24 16:50, Charles Samuels wrote:


On Thursday, February 22, 2024 9:52:03 A.M. PST Andres Salomon wrote:

Swiftshader is manually disabled in Debian's chromium package. It's one
of those legacy patches that I've long meant to look at (and remove if
conditions allow it), but I haven't gotten to yet:
https://salsa.debian.org/chromium-team/chromium/-/commit/84db0501b0d6cb055fe
9f22057cd129fdefac710
  

It wasn't documented *why* swiftshader was disabled. Maybe related to
non-DFSG third party libs (see https://bugs.debian.org/909156)? In order
to reenable it, I need to poke around and see if I can figure out why it
was disabled in the first place.


I looked at all of swiftshader's dependencies' licenses:

SPIRV: Apache
astc-encoder: Apache
benchmark: Apache
boost: Boost license (already part of Debian)
cppdap: Apache
glslang: 3-BSD, 2-BSD, MIT, Apache, GPL3, an NVIDIA license, which seems to be
similar to the MIT/BSD licenses, Khronos License, already part of debian.
glslang is already part of Debian
json: MIT
libbacktrace: BSD
llvm: llvm is already part of Debian
llvm-subzero: same license as LLVM
marl: Apache

Let me know if there is any way I can help!



Thanks for checking into the licenses! The other thing to look into is 
whether there's any compiled stuff included in the swiftshader 
directory. Not just actual binaries (which at least 
debian/scripts/check-upstream should catch), but also .js and similar 
files that have been run through things like minify. With that out of 
the way, I'd be comfortable re-enabling swiftshader.




OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071197: ninja-build: 1.12 breaks chromium build

[Andres Salomon]

Control: reassign -1 src:chromium

On 5/16/24 11:49, Felix Geyer wrote:

On 15.05.24 23:49, Andres Salomon wrote:

Package: ninja-build
Version: 1.12.1-1
Severity: serious
Tags: affects -1 chromium
X-Debbugs-Cc: Andres Salomon 

Chromium in unstable breaks with ninja-build 1.12. See here for 
example, where the same chromium version (124.0.6367.201-1) built fine 
on architectures where older ninja-build was available, but failed on 
newer ninja-build:


   https://buildd.debian.org/status/logs.php?pkg=chromium&arch=amd64
   https://buildd.debian.org/status/logs.php?pkg=chromium&arch=armhf

I've also verified in a sid chroot that 1.12.1-1 fails to build chromium
124.0.6367.207, but if I downgrade ninja-build to 1.11.1-2 then that 
same version of chromium successfully builds.


I'll be investigating further to see if I can figure out whether the 
problem is a bug in chromium, gn, or ninja (and reassign accordingly 
if necessary). But in the meantime, I don't think it's a good idea for 
ninja-build to migrate to trixie just yet (hence the severity).


This looks like https://issues.chromium.org/issues/336911498

Felix


Thank you! Now I can get back to figuring out the other chromium bugs..


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071197: ninja-build: 1.12 breaks chromium build

[Andres Salomon]

Damn, now I can't reproduce it in my chroot. Oh well, I did a giveback 
on chromium just in case this was a temporary problem.. I'll see in a 
few hours what happens.



On Wed, 15 May 2024 17:49:18 -0400 Andres Salomon  
wrote:

Package: ninja-build
Version: 1.12.1-1
Severity: serious
Tags: affects -1 chromium
X-Debbugs-Cc: Andres Salomon 

Chromium in unstable breaks with ninja-build 1.12. See here for example, 
where the same chromium version (124.0.6367.201-1) built fine on 
architectures where older ninja-build was available, but failed on newer 
ninja-build:


   https://buildd.debian.org/status/logs.php?pkg=chromium&arch=amd64
   https://buildd.debian.org/status/logs.php?pkg=chromium&arch=armhf

I've also verified in a sid chroot that 1.12.1-1 fails to build chromium
124.0.6367.207, but if I downgrade ninja-build to 1.11.1-2 then that 
same version of chromium successfully builds.


I'll be investigating further to see if I can figure out whether the 
problem is a bug in chromium, gn, or ninja (and reassign accordingly if 
necessary). But in the meantime, I don't think it's a good idea for 
ninja-build to migrate to trixie just yet (hence the severity).


Thanks,
Andres





OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071197: ninja-build: 1.12 breaks chromium build

[Andres Salomon]

Package: ninja-build
Version: 1.12.1-1
Severity: serious
Tags: affects -1 chromium
X-Debbugs-Cc: Andres Salomon 

Chromium in unstable breaks with ninja-build 1.12. See here for example, 
where the same chromium version (124.0.6367.201-1) built fine on 
architectures where older ninja-build was available, but failed on newer 
ninja-build:


  https://buildd.debian.org/status/logs.php?pkg=chromium&arch=amd64
  https://buildd.debian.org/status/logs.php?pkg=chromium&arch=armhf

I've also verified in a sid chroot that 1.12.1-1 fails to build chromium
124.0.6367.207, but if I downgrade ninja-build to 1.11.1-2 then that 
same version of chromium successfully builds.


I'll be investigating further to see if I can figure out whether the 
problem is a bug in chromium, gn, or ninja (and reassign accordingly if 
necessary). But in the meantime, I don't think it's a good idea for 
ninja-build to migrate to trixie just yet (hence the severity).


Thanks,
Andres





OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070266: nmu: chromium_124.0.6367.118-1

[Andres Salomon]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: serious

Hello,

Snappy 1.2.0-1 was uploaded with broken symbols (see 
https://bugs.debian.org/1070217). This is fixed in snappy 1.2.0-2, but 
chromium in sid had already built against the broken version of snappy.


Please rebuild chromium against snappy 1.2.0-2 to fix its broken symbol 
dependencies. Because this chromium release has CVE fixes (and there's 
20-something pending CVEs in trixie already that would be fixed by 
chromium migration), I'm filing this with a higher severity than usual.


  nmu chromium_124.0.6367.118-1 . ANY . -m 'Rebuild against 
libsnappy1v5 to fix broken symbols (#1070217)'




OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070227: Fails to start with undefined symbol

[Andres Salomon]

Thanks. This is a duplicate (https://bugs.debian.org/1070217), but I'm 
leaving it open to ensure that chromium doesn't accidentally migrate to 
trixie while built against a broken libsnappy. And as a reminder that 
we'll probably need a binNMU once snappy is fixed, unless upstream has a 
new release



On Thu, 2 May 2024 10:57:25 +0200 Yuri D'Elia  wrote:

Package: chromium
Version: 124.0.6367.78-1
Severity: grave

The current package in debian unstable fails to start with the following
missing symbol:

$ chromium
grep: warning: stray \ before -
/usr/lib/chromium/chromium: symbol lookup error: /usr/lib/chromium/chromium: 
undefined symbol: _ZN6snappy11RawCompressEPKcmPcPm


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common124.0.6367.78-1
ii  libasound2t64  1.2.11-1+b1
ii  libatk-bridge2.0-0t64  2.52.0-1
ii  libatk1.0-0t64 2.52.0-1
ii  libatomic1 14-20240429-1
ii  libatspi2.0-0t64   2.52.0-1
ii  libc6  2.38-6
ii  libcairo2  1.18.0-3+b1
ii  libcups2t642.4.7-1.2+b1
ii  libdbus-1-31.14.10-4+b1
ii  libdouble-conversion3  3.3.0-1+b1
ii  libdrm22.4.120-2
ii  libevent-2.1-7t64  2.1.12-stable-8.1+b3
ii  libexpat1  2.6.2-1
ii  libflac12t64   1.4.3+ds-2.1
ii  libfontconfig1 2.15.0-1.1
ii  libfreetype6   2.13.2+dfsg-1+b4
ii  libgbm124.1.0~rc1-1
ii  libgcc-s1  14-20240429-1
ii  libglib2.0-0t642.78.4-7
ii  libgtk-3-0t64  3.24.41-4
ii  libjpeg62-turbo1:2.1.5-3
ii  libjsoncpp25   1.9.5-6+b2
ii  liblcms2-2 2.14-2+b1
ii  libminizip1t64 1:1.3.dfsg-3.1
ii  libnspr4   2:4.35-1.1+b1
ii  libnss32:3.99-1
ii  libopenh264-7  2.4.1+dfsg-1
ii  libopenjp2-7   2.5.0-2+b3
ii  libopus0   1.4-1+b1
ii  libpango-1.0-0 1.52.1+ds-1
ii  libpng16-16t64 1.6.43-5
ii  libpulse0  16.1+dfsg1-5


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070217: chromium: Symbol lookup error with libsnappy1v5>=1.2.0

[Andres Salomon]

Control: reassign -1 snappy

Thanks, I've verified it's related to snappy 1.2.0:

dilinger@debian-sid:~$ dpkg -l |grep snapp
ii  libsnappy1v5:amd64  1.1.10-1+b1 
amd64fast compression/decompression library

dilinger@debian-sid:~$ chromium
VMware: No 3D enabled (0, Success).
VMware: No 3D enabled (0, Success).
[6693:6693:0501/220817.653832:ERROR:chrome_browser_cloud_management_controller.cc(161)] 
Cloud management controller initialization aborted as CBCM is not 
enabled. Please use the `--enable-chrome-browser-cloud-management` 
command line flag to enable it if you are not using the official Google 
Chrome build.

[...]
dilinger@debian-sid:~$ sudo apt install libsnappy1v5
[...]
Setting up libsnappy1v5:amd64 (1.2.0-1) ...
Processing triggers for libc-bin (2.37-18) ...
dilinger@debian-sid:~$ chromium
/usr/lib/chromium/chromium: symbol lookup error: 
/usr/lib/chromium/chromium: undefined symbol: 
_ZN6snappy11RawCompressEPKcmPcPm



I guess the ABI quietly changed without any kind of SONAME change? 
Here's snappy 1.1.10:


root@hm90:/chromium-124.0.6367.78# objdump -T 
/usr/lib/x86_64-linux-gnu/libsnappy.so.1.1.10|grep RawCompressE
4850 gDF .text	009f  Base 
_ZN6snappy11RawCompressEPKcmPcPm


And here's snappy 1.2.0:

root@hm90:/chromium-124.0.6367.78# objdump -T 
/usr/lib/x86_64-linux-gnu/libsnappy.so.1.1.10|grep RawCompressE
5240 gDF .text	00a2  Base 
_ZN6snappy11RawCompressEPKcmPcPmNS_18CompressionOptionsE






On 5/1/24 20:06, Jethro Nederhof wrote:

Package: chromium
Version: 124.0.6367.78-1
Severity: important
X-Debbugs-Cc: jet...@jethron.id.au

Dear Maintainer,

Attempting to run chromium fails with:

/usr/lib/chromium/chromium: symbol lookup error: /usr/lib/chromium/chromium: 
undefined symbol: _ZN6snappy11RawCompressEPKcmPcPm

I suspect this is due to the upload of 1.2.0-1 of libsnappy1v5 on 2024-05-01.

The closest symbol I can find in the newer libsnappy.so.* files is 
_ZN6snappy11RawCompressEPKcmPcPmNS_18CompressionOptionsE

Thank you for your work packaging chromium!

Kind regards,
Jethro


-- System Information:
Debian Release: trixie/sid
   APT prefers unstable
   APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.7-1-siduction-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common  124.0.6367.78-1
ii  libasound2t641.2.11-1+b1
ii  libatk-bridge2.0-0t642.52.0-1
ii  libatk1.0-0t64   2.52.0-1
ii  libatomic1   14-20240429-1
ii  libatspi2.0-0t64 2.52.0-1
ii  libc62.37-19
ii  libcairo21.18.0-3+b1
ii  libcups2t64  2.4.7-1.2+b1
ii  libdbus-1-3  1.14.10-4+b1
ii  libdouble-conversion33.3.0-1+b1
ii  libdrm2  2.4.120-2
ii  libevent-2.1-7t642.1.12-stable-8.1+b3
ii  libexpat12.6.2-1
ii  libflac12t64 1.4.3+ds-2.1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b4
ii  libgbm1  24.0.6-1+b1
ii  libgcc-s114-20240429-1
ii  libglib2.0-0t64  2.78.4-7
ii  libgtk-3-0t643.24.41-4
ii  libjpeg62-turbo  1:2.1.5-3
ii  libjsoncpp25 1.9.5-6+b2
ii  liblcms2-2   2.14-2+b1
ii  libminizip1t64   1:1.3.dfsg-3.1
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.99-1
ii  libopenh264-72.4.1+dfsg-1
ii  libopenjp2-7 2.5.0-2+b3
ii  libopus0 1.4-1+b1
ii  libpango-1.0-0   1.52.1+ds-1
ii  libpng16-16t64   1.6.43-5
ii  libpulse016.1+dfsg1-5
ii  libsnappy1v5 1.2.0-1
ii  libstdc++6   

Bug#1068161: Video playback regression

[Andres Salomon]

Please let me know if this is still broken with chromium 124.

On 3/31/24 18:18, Daniel Richard G. wrote:

Package: chromium
Version: 123.0.6312.86-1~deb12u1
Severity: important

Video playback worked fine in the previous version,
122.0.6261.128-1~deb12u1

In the current version, when I attempt to play a video, the visual
portion is completed whited out. The playback controls are present,
playback position advances, audio can be heard, but the video is just a
solid, constant white (regardless of the site's background color).

During playback, the following pair of error messages are printed
repeatedly to the terminal:

 [179003:179003:0331/180459.326096:ERROR:raster_decoder.cc(2407)] 
[.RenderCompositor-0x38dc004ddc00]GL ERROR :GL_INVALID_OPERATION : 
glWritePixelsYUV: Failed to upload pixels to dest shared image
 
[179003:179003:0331/180459.385907:ERROR:shared_image_representation.cc(478)] 
Attempt to read from an uninitialized SharedImage. Initialized region: (0, 0, 
0, 0) Size: (544, 360)

I have downloaded the previous 122.0.6261.128-1~deb12u1 package, and
run it to confirm that it can still play video correctly. In fact, I
have 122 and 123 running side by side, with one working and the other
spewing errors.


--Daniel



OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Andres Salomon]

On Sun, 10 Mar 2024 15:27:21 + Scott Kitterman 
 wrote:



On March 10, 2024 3:23:32 PM UTC, "Martin-Éric Racine" 
 wrote:
>On Sat, 2 Mar 2024 18:40:13 +0100 Chris Hofstaedtler  wrote:
>> * Christoph Biedl  [240302 17:02]:
>> > Chris Hofstaedtler wrote...
>> >
>> > > please remove deborphan. It is stuck, featurewise, in a very old time
>> > > and does not support many currently available dpkg features properly
>> > > (multi-arch, versioned provides, etc).
>> >
>> > FWIW, deborphan is part of my regular workflow, and while you claim
>> > it has defects, it works for me pretty well.
>>
>> It works "well" if you use it in very limited usecases, yes (like I
>> did). It doesn't seem to work well for a lot of people using more of
>> the "features" it has.
>
>Just because it doesn't work for everyone is not a remotely good
>enough reason to ask for its removal. It works for most people. don't
>break it for them.
>
>> The t64 transition will apparently make deborphan mostly useless in
>> trixie.
>>
>> > [..]
>> > So: What are the alternatives? How do they work? Are they a drop-in
>> > replacment or do they introduce new dependencies? Are there feature that
>> > will be no longer supported?
>>
>> release-notes recommends:
>> 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#removing-non-debian-packages
>
>Which has nothing to do with what was asked.
>
>> Some people seem to recommend debfoster.
>
>Which really doesn't provide similar functionality.
>
>> > Leaving users in the void about this is just bad style.
>
>I totally agree. Not wanting to maintain it is a shitty reason for
>asking for its removal. If you don't wanna maintain is, just orphan
>it.


It's really a maintainer call if that's appropriate.  So far no one has jumped 
up to ask if they can take over the package.



I'd take the package. I'm one of those who've been using deborphan for 
20+ years and was very surprised to find it gone. If it's truly too 
buggy to consider trustworthy, I'll change the code to spit out a 
warning to users about that. I suspect most deborphan users are grizzled 
oldsters who know better than to blindly trust its recommendations anyway.


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069586: Chromium native Wayland support broken

[Andres Salomon]

Control: tags -1 forwarded https://crbug.com/329678163
Control: severity -1 serious

On 4/20/24 23:13, Stephan Verbücheln wrote:

Package: chromium
Version: 124.0.6367.60-1~deb12u1

Since the last update, Chromium does work with native Wayland. It is
starting up, but it is displaying an invisible window. It is listed in
the window switchers (Alt+Tab), Gnome Shell etc., but invisible.

Note: The default configuration uses X11 via XWayland and is working.

The setting can be managed via command line arguments or by typing
chrome://flags into the URL bar (filter for ozone).

Available settings:
default -> X11works
auto-> Wayland if available   does not work
x11   works
wayland   does not work

I have been using Chromium with native Wayland for many months without
problems until the last update.



Thanks for the heads up. Seems like this is v124-specific, and reported 
upstream at .


If they don't fix it in the stable channel, I'll backport a fix. In the 
meantime it does seem like you can get it work in wayland mode using 
command-line args, according to that bug report thread, though I haven't 
tested it myself (I'm on X11 here).




OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068540: chromium: depends on pre-t64 library

[Andres Salomon]

On 4/7/24 04:28, Sebastian Ramacher wrote:

Source: chromium
Version: 123.0.6312.105-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

chromium has a hard-coded dependency on libgtk-3-0 which changed the
package name as part of the time_t transition. Please update the
dependency accordingly - or even better - derive the dependency from the
corresponding -dev package installed during the build.



Unfortunately I can't derive the dependency during build, because 
chromium dlopens gtk3 (or 4) at runtime instead of linking against it at 
build.


I'll upload a new version shortly.


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068345: trixie-pu: package chromium/123.0.6312.105-1~deb13u1

[Andres Salomon]

On 4/4/24 07:31, Paul Gevers wrote:

Hi Andres,

On 04-04-2024 9:56 a.m., Paul Gevers wrote:
I have $(reschedule --days=0)-ed your upload to DELAYED. I'll do a 
final check when that lands before unblocking.


The upload seems to be not a pure changelog only change. The tpu upload 
has a debian/patches/system/ffmpeg.patch that's not in unstable. Was 
that a mistake or care to elaborate?


Paul



I think that's backwards - the tpu upload (as well as my 
bookworm-security uploads) lacks the ffmpeg.patch that's in the unstable 
uploads, because they're built from clean git clones.


The sid upload has the ffmpeg.patch by mistake. It's not in git (anymore 
- 
https://salsa.debian.org/chromium-team/chromium/-/commit/510d9a6ed4586737bc20284fafab402ec682ed5e 
), and I need to delete it from the sid uploads. Recently I started 
testing to see if, now that we're not building chromium for bullseye 
anymore, I could reasonably start building against the system ffmpeg 
again. I never finished testing, and that patch got left in.


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068345: trixie-pu: package chromium/123.0.6312.105-1~deb13u1

[Andres Salomon]

Package: release.debian.org
Severity: normal
Tags: trixie
User: release.debian@packages.debian.org
Usertags: pu

Given the time_t transition, several folks have requested chromium 
updates via t-p-u. The current version in testing (122.0.6261.57-1) has 
20 CVEs that are fixed in newer versions, as well as another pretty 
serious bug (#1066910). I'd like to go ahead and upload 
123.0.6312.105-1~deb13u1 to trixie.


No packaging changes between 123.0.6312.105-1 (currently in sid) and 
123.0.6312.105-1~deb13u1, other than the d/changelog entry:



chromium (123.0.6312.105-1~deb13u1) trixie; urgency=high

  * Rebuild for trixie.

 -- Andres Salomon   Wed, 03 Apr 2024 20:11:03 +




OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061950: Debian 12 PHP 8.2.7 - GH-11972: RecursiveCallbackFilterIterator

[Andres Salomon]

On Tue, 30 Jan 2024 13:53:49 +0100 Sebastian Kraetzig 
 wrote:

[...]


With PHP 8.2.11 and newer, this issue does not exist anymore as it has been
fixed there. When it's fixed, the PHP script immediately exits without any
error message.

I suggest that the changes from
https://github.com/php/php-src/commit/ffd7018fcdd13ca2966149e5141197a02707aff1
get backported to PHP 8.2.7 on Debian 12 (Bookworm). When I apply these
changes on top of the above mentioned PHP version, the issue is resolved.
At the bottom, you’ll find our tested patch.



I would rather see a proposed-stable-update happen with some newer 
version of 8.2.x, which would additionally fix those low-priority CVEs 
from https://bugs.debian.org/1043477


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068096: chromium: --temp-profile has no effect if it appears after --ozone-platform=wayland

[Andres Salomon]

Thanks for reporting! This is a bug in our wrapper script 
(/usr/bin/chromium), not in the upstream binary (/usr/lib/chromium).


We have some, uh, not great arg checking in the shell script:

while [ $# -gt 0 ]; do
  case "$1" in
--temp-profile )
  want_temp_profile=1
  shift ;;

-- ) # Stop option prcessing
  shift
  break ;;


So when you run with --ozone-platform[0], it hits the "Stop option 
prcessing" code path and doesn't look at further args.


If you're so inclined, I'd happily take a (tested) patch to rework the 
way we handle arg processing. Otherwise, I will get to this after I deal 
with some higher priority chromium stuff. :)



 [0] you can use --ozone-platform=auto to have it automatically detect 
whether to run in X or Wayland mode, btw



On 3/30/24 10:36, Daniel Kahn Gillmor wrote:

Package: chromium
Version: 122.0.6261.57-1
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

I regularly launch chromimum with --temp-profile to have a completely
isolated, throwaway browsing session.

I am experimenting with switching to wayland.  To use chromium with
wayland, i need to launch it with --ozone-platform=wayland.

Surprisingly, i discovered that if i launch it this way:

 chromium --ozone-platform=wayland --temp-profile

Then it launches with the primary chromium profile, *not* an ephemeral
profile.

But if i launch it this way:

 chromium --temp-profile --ozone-platform=wayland

then it does in fact use an ephemeral profile.  I discovered this by
using the former invocation to visit a site where i have a login, and
noticed that i was already logged in as soon as i visited it.

I consider this a pretty serious privacy violation: my entire client
side state was mapped in to a process that i expected to be otherwise
anonymous.

  --dkg


-- System Information:
Debian Release: trixie/sid
   APT prefers testing-debug
   APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chromium depends on:
ii  chromium-common  122.0.6261.57-1
ii  libasound2   1.2.10-3
ii  libatk-bridge2.0-0   2.50.0-1+b1
ii  libatk1.0-0  2.50.0-1+b1
ii  libatomic1   14-20240201-3
ii  libatspi2.0-02.50.0-1+b1
ii  libc62.37-15
ii  libcairo21.18.0-1+b1
ii  libcups2 2.4.7-1+b1
ii  libdbus-1-3  1.14.10-4
ii  libdouble-conversion33.3.0-1+b1
ii  libdrm2  2.4.120-2
ii  libevent-2.1-7t64 [libevent-2.1-7]   2.1.12-stable-8.1+b1
ii  libexpat12.5.0-2+b2
ii  libflac121.4.3+ds-2+b1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b1
ii  libgbm1  23.3.5-1
ii  libgcc-s114-20240201-3
ii  libglib2.0-0 2.78.4-1
ii  libgtk-3-0   3.24.41-1
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libjsoncpp25 1.9.5-6+b2
ii  liblcms2-2   2.14-2+b1
ii  libminizip1  1:1.3.dfsg-3+b1
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.99-1
ii  libopenh264-72.4.1+dfsg-1
ii  libopenjp2-7 2.5.0-2+b2
ii  libopus0 1.4-1+b1
ii  libpango-1.0-0   1.52.0+ds-1
ii  libpng16-16t64 [libpng16-16] 1.6.43-5
ii  libpulse016.1+dfsg1-3
ii  libsnappy1v5 1.1.10-1+b1
ii  libstdc++6   14-20240201-3
ii  libwebp7 1.3.2-0.4
ii  libwebpdemux21.3.2-0.4
ii  libwebpmux3

Bug#1066910: chromium: downloads non-free component libchromescreenai.so without asking

[Andres Salomon]

Control: tags -1 bookworm trixie sid

On 3/15/24 06:57, Helmut Grohne wrote:

Package: chromium
Version: 122.0.6261.128-1
Severity: serious

In recent versions, chromium started downloading a file
~/.config/chromium/screen_ai/*/libchromescreenai.so. Evidently, the
source of this shared object is not in the chromium source package. I
think the chromium package - being in main - should not download a
shared object and run it without user confirmation.

Helmut



Thanks for reporting this! It looks like this is controlled with the 
enable_screen_ai_service, I'll test that & fix it in the next series of 
upload.


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063461: Bug#1065283: lsof: diff for NMU version 4.95.0-1.1

[Andres Salomon]

Thanks! I'd planned to wait until the t64 transition was complete before 
doing a new upstream release of lsof, but a NMU to fix this FTBFS issue 
is good.


On 3/10/24 07:45, Sebastian Ramacher wrote:

Dear maintainer,

I've prepared an NMU for lsof (versioned as 4.95.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064031: rustc-web 1.70.0+dfsg1-7~deb12u1 flagged for acceptance

[Andres Salomon]

On 3/2/24 02:00, Andres Salomon wrote:

Actually, scratch that; I had missed #1064563.

I'll redo the deb11u2 package with conflicts/replaces for that, as well, 
and then resend it shortly.


On 3/2/24 01:49, Andres Salomon wrote:


Okay, here's an updated package with fixes:

rustc-web (1.70.0+dfsg1-7~deb12u2) bookworm; urgency=medium

   * Non-maintainer upload.
   * Increase allowed test failures on armhf and ppc64el to fix FTBFS.
   * Provide Conflicts/Replaces for rust*-mozilla*, which could still be
 installed from oldstable (closes: #1064562).




rustc-web (1.70.0+dfsg1-7~deb12u2) bookworm; urgency=medium

  * Non-maintainer upload.
  * Increase allowed test failures on armhf and ppc64el to fix FTBFS.
  * Provide Conflicts/Replaces for rust*-mozilla*, which could still be
installed from oldstable (closes: #1064562).
  * Add Provides/Conflicts/Replaces for libstd-rust-1.70 (closes: 
#1064563).




This should fix builds for armhf & ppc64el, and also specifies manual 
conflicts/replaces with a bunch of packages from rustc-mozilla. In 
addition, it adds a p/c/r in libstd-rust-web-1.70 for libstd-rust-1.70.


For the rust*mozilla* conflicts, I tested it by doing an 'apt install 
rustc-mozilla rust-mozilla-src rust-mozilla-gdb libstd-rust-mozilla-dev' 
from oldstable onto a bookworm environmente, and then installed the 
locally built 'libstd-rust-web-1.70 libstd-rust-web-dev rust-web-gdb 
rust-web-src rustc-web' packages over that. The older rustc-mozilla 
packages are properly removed by apt, with the exception of 
libstd-rust-mozilla-1.63 (which should be fine).


For the libstd-rust-1.70 conflict, I tested it by manually installing 
the 'rustc-web libstd-rust-web-1.70 libstd-rust-web-dev' packages in a 
trixie environment, and then 'apt install rustc libstd-rust-web-dev' 
over that. As expected, it removed the three *-web* packages and 
successfully installed the standard rustc packages.


diff -u rustc-web-1.70.0+dfsg1/debian/changelog rustc-web-1.70.0+dfsg1/debian/changelog
--- rustc-web-1.70.0+dfsg1/debian/changelog	2024-02-14 02:02:37.0 +
+++ rustc-web-1.70.0+dfsg1/debian/changelog	2024-03-02 07:23:17.763665420 +
@@ -1,3 +1,13 @@
+rustc-web (1.70.0+dfsg1-7~deb12u2) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Increase allowed test failures on armhf and ppc64el to fix FTBFS.
+  * Provide Conflicts/Replaces for rust*-mozilla*, which could still be
+installed from oldstable (closes: #1064562).
+  * Add Provides/Conflicts/Replaces for libstd-rust-1.70 (closes: #1064563).
+
+ -- Andres Salomon   Sat, 02 Mar 2024 07:23:15 +
+
 rustc-web (1.70.0+dfsg1-7~deb12u1) bookworm; urgency=medium
 
   * Non-maintainer upload.
diff -u rustc-web-1.70.0+dfsg1/debian/control rustc-web-1.70.0+dfsg1/debian/control
--- rustc-web-1.70.0+dfsg1/debian/control	2024-02-14 02:02:37.0 +
+++ rustc-web-1.70.0+dfsg1/debian/control	2024-03-02 07:05:53.739717477 +
@@ -58,9 +58,9 @@
 Suggests:
 # lld and clang are needed for wasm compilation
  lld-16, clang-16,
-Conflicts: rustc
+Conflicts: rustc, rustc-mozilla
 Provides: rustc (= ${binary:Version})
-Replaces: libstd-rust-dev (<< 1.25.0+dfsg1-2~~), rustc
+Replaces: libstd-rust-dev (<< 1.25.0+dfsg1-2~~), rustc, rustc-mozilla
 Breaks: libstd-rust-dev (<< 1.25.0+dfsg1-2~~)
 Description: Rust systems programming language
  Rust is a curly-brace, block-structured expression language.  It
@@ -81,6 +81,9 @@
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: libstd-rust-1.70
+Replaces: libstd-rust-1.70
+Provides: libstd-rust-1.70
 Description: Rust standard libraries
  Rust is a curly-brace, block-structured expression language.  It
  visually resembles the C language family, but differs significantly
@@ -103,9 +106,9 @@
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends},
  libstd-rust-web-1.70 (= ${binary:Version}),
-Conflicts: libstd-rust-dev
+Conflicts: libstd-rust-dev, libstd-rust-mozilla-dev
 Provides: libstd-rust-dev (= ${binary:Version})
-Replaces: libstd-rust-dev
+Replaces: libstd-rust-dev, libstd-rust-mozilla-dev
 Description: Rust standard libraries - development files
  Rust is a curly-brace, block-structured expression language.  It
  visually resembles the C language family, but differs significantly
@@ -131,7 +134,8 @@
 Recommends:
  gcc-mingw-w64-x86-64-posix [amd64],
  gcc-mingw-w64-i686-posix [i386],
-Conflicts: libstd-rust-dev-windows
+Conflicts: libstd-rust-dev-windows, libstd-rust-mozilla-dev-windows
+Replaces: libstd-rust-mozilla-dev-windows
 Build-Profiles: 
 Description: Rust standard libraries - development files
  Rust is a curly-brace, block-structured expression language.  It
@@ -154,8 +158,8 @@
 Architecture: all
 Depends: gdb, ${misc:Depends}
 Suggests: gdb-doc
-Conflicts: rust-gdb
-Replaces: rustc (<< 1.1.0+dfsg1-1)
+Conflicts: rust-gdb, rust-mozill

Bug#1064031: rustc-web 1.70.0+dfsg1-7~deb12u1 flagged for acceptance

[Andres Salomon]

Actually, scratch that; I had missed #1064563.

I'll redo the deb11u2 package with conflicts/replaces for that, as well, 
and then resend it shortly.


On 3/2/24 01:49, Andres Salomon wrote:


Okay, here's an updated package with fixes:

rustc-web (1.70.0+dfsg1-7~deb12u2) bookworm; urgency=medium

   * Non-maintainer upload.
   * Increase allowed test failures on armhf and ppc64el to fix FTBFS.
   * Provide Conflicts/Replaces for rust*-mozilla*, which could still be
     installed from oldstable (closes: #1064562).



OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064031: rustc-web 1.70.0+dfsg1-7~deb12u1 flagged for acceptance

[Andres Salomon]

On 2/28/24 01:23, Adam D. Barratt wrote:

On Tue, 2024-02-27 at 15:00 -0500, Andres Salomon wrote:

So it looks like I'll need a new upload to fix two bookworm
architecture
build failures (armhf and ppc64el), and also to fix #1064562. Should
I
file a new release.d.o bug, or continue using this one?


Given that both issues are related to the initial upload tracked in
this bug, re-using this one is ifne.



Okay, here's an updated package with fixes:

rustc-web (1.70.0+dfsg1-7~deb12u2) bookworm; urgency=medium

  * Non-maintainer upload.
  * Increase allowed test failures on armhf and ppc64el to fix FTBFS.
  * Provide Conflicts/Replaces for rust*-mozilla*, which could still be
installed from oldstable (closes: #1064562).


This should fix builds for armhf & ppc64el, and also specifies manual 
conflicts/replaces with a bunch of packages from rustc-mozilla.


I tested it by doing an 'apt install rustc-mozilla rust-mozilla-src 
rust-mozilla-gdb libstd-rust-mozilla-dev' from oldstable, and then 
installing the locally built 'libstd-rust-web-1.70 libstd-rust-web-dev 
rust-web-gdb rust-web-src rustc-web' packages over that. The older 
rustc-mozilla packages are properly removed by apt, with the exception 
of libstd-rust-mozilla-1.63 (which should be fine).



diff -urN rustc-web-1.70.0+dfsg1/debian/changelog rustc-web-1.70.0+dfsg1/debian/changelog
--- rustc-web-1.70.0+dfsg1/debian/changelog	2024-02-14 02:02:37.0 +
+++ rustc-web-1.70.0+dfsg1/debian/changelog	2024-03-02 05:37:16.955122720 +
@@ -1,3 +1,12 @@
+rustc-web (1.70.0+dfsg1-7~deb12u2) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Increase allowed test failures on armhf and ppc64el to fix FTBFS.
+  * Provide Conflicts/Replaces for rust*-mozilla*, which could still be
+installed from oldstable (closes: #1064562).
+
+ -- Andres Salomon   Fri, 01 Mar 2024 05:44:10 +
+
 rustc-web (1.70.0+dfsg1-7~deb12u1) bookworm; urgency=medium
 
   * Non-maintainer upload.
diff -urN rustc-web-1.70.0+dfsg1/debian/control rustc-web-1.70.0+dfsg1/debian/control
--- rustc-web-1.70.0+dfsg1/debian/control	2024-02-14 02:02:37.0 +
+++ rustc-web-1.70.0+dfsg1/debian/control	2024-03-02 05:37:16.955122720 +
@@ -58,9 +58,9 @@
 Suggests:
 # lld and clang are needed for wasm compilation
  lld-16, clang-16,
-Conflicts: rustc
+Conflicts: rustc, rustc-mozilla
 Provides: rustc (= ${binary:Version})
-Replaces: libstd-rust-dev (<< 1.25.0+dfsg1-2~~), rustc
+Replaces: libstd-rust-dev (<< 1.25.0+dfsg1-2~~), rustc, rustc-mozilla
 Breaks: libstd-rust-dev (<< 1.25.0+dfsg1-2~~)
 Description: Rust systems programming language
  Rust is a curly-brace, block-structured expression language.  It
@@ -103,9 +103,9 @@
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends},
  libstd-rust-web-1.70 (= ${binary:Version}),
-Conflicts: libstd-rust-dev
+Conflicts: libstd-rust-dev, libstd-rust-mozilla-dev
 Provides: libstd-rust-dev (= ${binary:Version})
-Replaces: libstd-rust-dev
+Replaces: libstd-rust-dev, libstd-rust-mozilla-dev
 Description: Rust standard libraries - development files
  Rust is a curly-brace, block-structured expression language.  It
  visually resembles the C language family, but differs significantly
@@ -131,7 +131,8 @@
 Recommends:
  gcc-mingw-w64-x86-64-posix [amd64],
  gcc-mingw-w64-i686-posix [i386],
-Conflicts: libstd-rust-dev-windows
+Conflicts: libstd-rust-dev-windows, libstd-rust-mozilla-dev-windows
+Replaces: libstd-rust-mozilla-dev-windows
 Build-Profiles: 
 Description: Rust standard libraries - development files
  Rust is a curly-brace, block-structured expression language.  It
@@ -154,8 +155,8 @@
 Architecture: all
 Depends: gdb, ${misc:Depends}
 Suggests: gdb-doc
-Conflicts: rust-gdb
-Replaces: rustc (<< 1.1.0+dfsg1-1)
+Conflicts: rust-gdb, rust-mozilla-gdb
+Replaces: rustc (<< 1.1.0+dfsg1-1), rust-mozilla-gdb
 Description: Rust debugger (gdb)
  Rust is a curly-brace, block-structured expression language.  It
  visually resembles the C language family, but differs significantly
@@ -176,8 +177,8 @@
 Architecture: all
 # When updating, also update rust-lldb.links
 Depends: lldb-16, ${misc:Depends}, python3-lldb-16
-Replaces: rustc (<< 1.1.0+dfsg1-1)
-Conflicts: rust-lldb
+Replaces: rustc (<< 1.1.0+dfsg1-1), rust-mozilla-lldb
+Conflicts: rust-lldb, rust-mozilla-lldb
 Description: Rust debugger (lldb)
  Rust is a curly-brace, block-structured expression language.  It
  visually resembles the C language family, but differs significantly
@@ -222,7 +223,8 @@
 Package: rust-web-src
 Architecture: all
 Depends: ${misc:Depends}
-Conflicts: rust-src
+Conflicts: rust-src, rust-mozilla-src
+Replaces: rust-mozilla-src
 Description: Rust systems programming language - source code
  Rust is a curly-brace, block-structured expression language.  It
  visually resembles the C language family, but differs significantly
diff -urN rustc-web-1.70.0+dfsg1/debian/rules

Bug#1064031: rustc-web 1.70.0+dfsg1-7~deb12u1 flagged for acceptance

[Andres Salomon]

So it looks like I'll need a new upload to fix two bookworm architecture 
build failures (armhf and ppc64el), and also to fix #1064562. Should I 
file a new release.d.o bug, or continue using this one?



(I'm ignoring armel and mipsel build failures, since firefox-esr hasn't 
built on either architecture in several years in bookworm, and also 
armel doesn't really have a matching upstream stage0 compiler.)




On Fri, 23 Feb 2024 14:57:46 + Adam D Barratt 
 wrote:

package release.debian.org
tags 1064031 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: rustc-web
Version: 1.70.0+dfsg1-7~deb12u1

Explanation: new source package to support builds of web browsers




OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050677: RE: chromium: VAAPI acceleration not working on Chromium 116

[Andres Salomon]

Hi,

Can you please verify that this has been fixed since Chromium >= 118? We 
currently have Chromium 122 in unstable/testing/stable.


Thanks,
Andres

On Wed, 27 Sep 2023 00:55:04 -0300 Leandro Cunha 
 wrote:

Hi,

It's a problem that persists in 117 on unstable, although on the
Chrome unstable channel (version 118.x) it seems to be resolved.

Graphics Feature Status
===
*   Canvas: Hardware accelerated
*   Canvas out-of-process rasterization: Disabled
*   Direct Rendering Display Compositor: Disabled
*   Compositing: Hardware accelerated
*   Multiple Raster Threads: Enabled
*   OpenGL: Enabled
*   Rasterization: Hardware accelerated
*   Raw Draw: Disabled
*   Skia Graphite: Disabled
*   Video Decode: Software only. Hardware acceleration disabled
*   Video Encode: Software only. Hardware acceleration disabled
*   Vulkan: Enabled
*   WebGL: Hardware accelerated
*   WebGL2: Hardware accelerated
*   WebGPU: Disabled

Driver Bug Workarounds
==
*   adjust_src_dst_region_for_blitframebuffer
*   clear_uniforms_before_first_program_use
*   count_all_in_varyings_packing
*   disable_post_sub_buffers_for_onscreen_surfaces
*   enable_webgl_timer_query_extensions
*   exit_on_context_lost
*   msaa_is_slow
*   rely_on_implicit_sync_for_swap_buffers
*   disabled_extension_GL_KHR_blend_equation_advanced
*   disabled_extension_GL_KHR_blend_equation_advanced_coherent
*   disabled_extension_GL_MESA_framebuffer_flip_y

Problems Detected
=
*   WebGPU has been disabled via blocklist or the command line.
Disabled Features: webgpu

*   Accelerated video encode has been disabled, either via blocklist,
about:flags or the command line.
Disabled Features: video_encode

*   Accelerated video decode has been disabled, either via blocklist,
about:flags or the command line.
Disabled Features: video_decode

*   Clear uniforms before first program use on all platforms:
(http://crbug.com/124764), (http://crbug.com/349137)
Applied Workarounds: clear_uniforms_before_first_program_use

*   Mesa drivers in Linux handle varyings without static use incorrectly:
(http://crbug.com/333885)
Applied Workarounds: count_all_in_varyings_packing

*   On Intel GPUs MSAA performance is not acceptable for GPU rasterization:
(http://crbug.com/527565), (http://crbug.com/1298585)


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064465: chromium: Chromium cannot use webgl without X (should be compiled with swiftshader)

[Andres Salomon]

Swiftshader is manually disabled in Debian's chromium package. It's one 
of those legacy patches that I've long meant to look at (and remove if 
conditions allow it), but I haven't gotten to yet: 
https://salsa.debian.org/chromium-team/chromium/-/commit/84db0501b0d6cb055fe9f22057cd129fdefac710


It wasn't documented *why* swiftshader was disabled. Maybe related to 
non-DFSG third party libs (see https://bugs.debian.org/909156)? In order 
to reenable it, I need to poke around and see if I can figure out why it 
was disabled in the first place.



On 2/22/24 10:32, Charles Samuels wrote:

Package: chromium
Version: 121.0.6167.160-1~deb12u1
Severity: normal
X-Debbugs-Cc: char...@derkarl.org

Dear Maintainer,

I'd like to use Chromium's webgl support in headless mode. However, If I don't
have an X-server running, and I try to access a website that uses webgl, the
browser simply doesn't support webgl, which forces me to use a non-Debian
Chromium.

I can reproduce this problem with:
$ unset DISPLAY
$ chromium --headless=new --enable-webgl --screenshot https://get.webgl.org

Then Chromium outputs messages like:

[843245:843245:0222/035252.118199:ERROR:gl_display.cc(520)] EGL Driver message
(Critical) eglInitialize: Could not open the default X display.

In theory, I should be able to run Chromium, per their documentation:

$ chromium --headless=new --use-gl=swiftshader --enable-webgl --screenshot
https://get.webgl.org

But it indicates that that is not supported.

In order to support swiftshader, a clone of
 must be present in third_party/
and the debian/rules should set the features: enable_swiftshader=true
dawn_use_swiftshader=true . It might also make sense to use
enable_swiftshader_vulkan=true as well

Thank you for your attention and the efforts you put into Debian.

cs


-- System Information:
Debian Release: 12.4
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-17-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
pn  chromium-common 
ii  libasound2  1.2.8-1+b1
ii  libatk-bridge2.0-0  2.46.0-5
ii  libatk1.0-0 2.46.0-5
ii  libatomic1  12.2.0-14
ii  libatspi2.0-0   2.46.0-5
ii  libbrotli1  1.0.9-2+b6
ii  libc6   2.36-9+deb12u3
ii  libcairo2   1.16.0-7
ii  libcups22.4.2-3+deb12u5
ii  libdbus-1-3 1.14.10-1~deb12u1
ii  libdouble-conversion3   3.2.1-1
ii  libdrm2 2.4.114-1+b1
ii  libevent-2.1-7  2.1.12-stable-8
ii  libexpat1   2.5.0-1
ii  libflac12   1.4.2+ds-2
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-5
ii  libgbm1 22.3.6-1+deb12u1
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgtk-3-0  3.24.38-2~deb12u1
ii  libjpeg62-turbo 1:2.1.5-2
ii  libjsoncpp251.9.5-4
ii  liblcms2-2  2.14-2
ii  libminizip1 1.1-8+deb12u1
ii  libnspr42:4.35-1
ii  libnss3 2:3.87.1-1
ii  libopenh264-7   1:2.3.1-dmo1
ii  libopenjp2-72.5.0-2
ii  libopus01.3.1-3
ii  libpango-1.0-0  1.50.12+ds-1
ii  libpng16-16 1.6.39-2
ii  libpulse0   16.1+dfsg1-2+b1
ii  libsnappy1v51.1.9-3
ii  libstdc++6  12.2.0-14
ii  libwebp71.2.4-0.2+deb12u1
ii  libwebpdemux2   1.2.4-0.2+deb12u1
ii  libwebpmux3 1.2.4-0.2+deb12u1
ii  libwoff1   

Bug#1064031: chromium and rustc in bookworm

[Andres Salomon]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu

Chromium now requires a Rust compiler to build, and it specifically 
needs a rustc with profiler support built into it. This package can 
hopefully be shared with firefox and other browser/web engines that end 
up needing a newer rustc.


[ Reason ]
Chromium 121 started removing C++ code in favor of Rust. For 121 in 
bookworm we reverted that patch, but that's not a long-term solution as 
more C++ code gets replaced with Rust code.


Chromium requires a Rust compiler with profiler support built into it, 
which was only added in rustc 1.70.0+dfsg1-3 (see #1043311). Since 
bookworm's rustc lacks this, we need a backport. We don't want to risk 
breaking existing Rust packages in bookworm by backporting the profiler 
patches to 1.63, so instead we'll do something similar to what firefox 
did in the past with rustc-mozilla and backport a newer rustc. Note the 
name "rustc-web" breaks with the traditional rustc-mozilla naming, since 
it's not really mozilla-specific any more.


As mentioned below in the mailing list thread, the firefox maintainer 
isn't certain if 1.70 will be new enough for firefox-esr 128; however, 
if a newer rustc is needed, they can update this package and I will make 
sure the newer version continues to work with chromium.


[ Impact ]
There's no impact for bookworm users, as packages in stable must 
explicitly choose to build against rustc-web. The rustc-web and 
libstd-rust-web-dev packages have appropriate conflicts/replaces to 
ensure there's no accidental installation with bookworm's existing rustc 
packages.


[ Tests ]
Chromium 121.0.6167.160-1~deb12u1 succeeds in building and running on 
bookworm with this rustc-web package.


[ Risks ]
Low/no risk.

[ Checklist ]
 [x] *all* changes are documented in the d/changelog
 [x] I reviewed all changes and I approve them
 [X] attach debdiff against the package in (old)stable
 [x] the issue is verified as fixed in unstable

[ Changes ]
Many of the changes were modeled after the older rustc-mozilla package 
from bullseye, but with some updates for the state of things in 
bookworm. As with rustc-mozilla, the bootstrap compilers are included in 
orig-stage0.tar.xz. Because I'd already backported llvm-toolchain-16 to 
bookworm, there was no need to modify rustc's llvm 16 dependencies.


The changelog entry:

rustc-web (1.70.0+dfsg1-7~deb12u1) bookworm; urgency=medium

  * Non-maintainer upload.
  * Rename rustc backport to rustc-web, intended to be used for browsers.
  * Generate & include bootstrap compilers via an orig-stage0.tar.xz.
  * Add mipsel bootstrap compiler back, as mipsel is still in bookworm.
  * Disable profiler on mipsel, as it likely doesn't work either.
  * Disable wasm.
  * Drop -all virtual package, which doesn't make sense for us.



I've included a diff against unstable's rustc (1.70.0+dfsg-7).

[ Other info ]
See d-release thread below.



On 2/13/24 19:32, Andres Salomon wrote:
Okay, so I've gotten rustc 1.70.0+dfsg-6 (the prior version needed some 
bootstrap fixes) built on bookworm, and managed to use it to build 
chromium as well. Unfortunately -6 isn't building on mips64el, but I 
strongly suspect that this is something that won't happen in bookworm.


I'm going to name the package rustc-web, and I'll send a patch for 
review hopefully tomorrow. Chromium 122's planned for release on Feb 
20th, and I haven't yet checked if they've removed more C++ code in 
favor of Rust.



On 1/22/24 21:22, Timothy Pearson wrote:



- Original Message -

From: "Andres Salomon" 
To: "Adrian Bunk" , debian-rele...@lists.debian.org, 
pkg-rust-maintain...@alioth-lists.debian.net,
debian@fabian.gruenbichler.email, infini...@debian.org, 
sylves...@debian.org

Cc: "Timothy Pearson" 
Sent: Monday, January 22, 2024 8:17:15 PM
Subject: Re: chromium and rustc in bookworm



On 1/22/24 15:34, Mike Hommey wrote:

On Mon, Jan 22, 2024 at 03:39:08AM +0200, Adrian Bunk wrote:

On Sun, Jan 21, 2024 at 06:55:31PM -0500, Andres Salomon wrote:

...

c) Much like the Firefox maintainer(s) created rustc-mozilla for
(old)oldstable, we create a 'rustc-chromium' package for bookworm. 
It could
even be used for Firefox if their ESR updates start needing newer 
Rust
language features (in which case, maybe 'rustc-newer' or 
'rustc-browsers' is
a better name for it? Or like Clang, include the major version and 
call it

'rustc-1.70').


As I'm still messing around with bookworm's rustc(+profiler) as 
well as
trying to get Chromium 121.x to build in Sid, I don't have a 
strong opinion
on this yet. However, I wanted to bring it to everyone's 
attention, and see
if anyone else did have strong opinions either way. If 

Bug#1062533: chromium: Chromium doesn't launch in ARM64!

[Andres Salomon]

Running 'grep chromium /var/log/dpkg.log' (or /var/log/dpkg.log.1 if it 
was already rotated) should tell you what version it was upgraded from.


On 2/1/24 15:43, Sally A.haj wrote:

I don't remember exactly, but I believe it was the very recent before
the latest, because I usually do update the system every week or so.

Thank you.
On Thu, 2024-02-01 at 15:36 -0500, Andres Salomon wrote:



On 2/1/24 15:23, Sally A.haj wrote:
[...]


     * What outcome did you expect instead?
 Before the latest update, it was working just fine.
I am using Gnome/Wayland on Raspberry Pi 4 for a quite some times,
and this the first time I face an issue with chromium.



Thanks for the report. What exactly was the previous version that
worked
for you?




OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1062533: chromium: Chromium doesn't launch in ARM64!

[Andres Salomon]

On 2/1/24 15:23, Sally A.haj wrote:
[...]


* What outcome did you expect instead?
Before the latest update, it was working just fine.
I am using Gnome/Wayland on Raspberry Pi 4 for a quite some times, and this the 
first time I face an issue with chromium.



Thanks for the report. What exactly was the previous version that worked 
for you?


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061268: debian-security-support: ending security support for chromium in bullseye

[Andres Salomon]

Package: debian-security-support
Version: 1:13+2023.12.23
Severity: normal

As documented in the release notes [0] and warned about via NEWS.Debian 
entry [1], support for chromium in bullseye-security has now ended. 
Please mark it as such in the d-s-s package as well. Thanks!



[0] 
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#browser-security
[1] 
https://salsa.debian.org/chromium-team/chromium/-/blob/bullseye/debian/NEWS?ref_type=heads

Bug#1043311: [Pkg-rust-maintainers] Bug#1043311: rustc: please enable profiler builtin

[Andres Salomon]

On Sat, 13 Jan 2024 03:42:35 -0500 Andres Salomon  
wrote:

>
> On 1/13/24 02:42, Andres Salomon wrote:
> > On Fri, 08 Sep 2023 13:35:44 -0400 Andres Salomon
> >  wrote:
> > >
> > >
> > > On Fri, Sep 8 2023 at 10:36:48 AM +02:00:00, Fabian Grünbichler
> > >  wrote:
> > > >>  On Tue, Aug 8 2023 at 06:22:28 PM -04:00:00, Andres Salomon
> > > >>
> > > [...]
> > > >>
> > > >>  This patch adds
> > > >> "cargo:rustc-link-search=/usr/lib/clang/15/lib/linux/" and
> > > >> "cargo:rustc-link-lib=static=clang_rt.profile-x86_64" (or 
whatever
> > > >>  architecture it happens to be building on) to the 
profiler_builtins

> > > >> build
> > > >>  flags when the target matches the host. In the case where the
> > > >> target is
> > > >>  different from the host, it assumes a wasm build and sets
> > > >>  "rustc-link-lib=static=clang_rt.builtins-wasm32" or
> > > >> "cargo:rustc-link-lib=static=clang_rt.builtins-wasm64" 
depending

> > > >> upon
> > > >>  whether the target is 32 or 64 bits, respectively.
> > > >
> > > > Thanks for the patch! the Windows part in d/rules looks wrong 
to me -

> > > > that is built with mingw, not wasi. I assume you are not
> > interested in
> > > > that part, so maybe it would also be an option to guard it 
based on
> > > > target and just build it for the regular one (or regular+wasm, 
but

> > not
> > > > windows/mingw)?
> > >
> >
> > After you pointed out the upstream patch on IRC
> > (https://github.com/rust-lang/rust/pull/114069), I backported it to
> > 1.70 and tried building it. It gets pretty far, but fails late in 
the
> > build on some tests. I'm going to do some more building (starting 
with

> > rustc by itself without the profiler stuff, to ensure that the test
> > failure I'm seeing is actually related to profiler). But in the
> > meantime, here's the backported patch. If I can get it fully built,
> > I'll follow up with the full debian patch or a merge request.
> >
> >
>
> Ugh, unfortunately I'm hitting the same build failure even without
> profiler enabled. This is just rustc from sid without any changes
> failing. I can file a separate FTBFS bug if it's not some issue with 
my

> build environment...


No idea why that's FTBFS in my chroot and using a podman container, but 
it does build under sbuild as mjt pointed out. That allowed me to 
successfully build the profiler stuff. Merge request is here:


https://salsa.debian.org/rust-team/rust/-/merge_requests/28

Bug#1043311: [Pkg-rust-maintainers] Bug#1043311: rustc: please enable profiler builtin

[Andres Salomon]

On 1/13/24 02:42, Andres Salomon wrote:
On Fri, 08 Sep 2023 13:35:44 -0400 Andres Salomon 
 wrote:

>
>
> On Fri, Sep 8 2023 at 10:36:48 AM +02:00:00, Fabian Grünbichler
>  wrote:
> >>  On Tue, Aug 8 2023 at 06:22:28 PM -04:00:00, Andres Salomon
> >>
> [...]
> >>
> >>  This patch adds
> >> "cargo:rustc-link-search=/usr/lib/clang/15/lib/linux/" and
> >> "cargo:rustc-link-lib=static=clang_rt.profile-x86_64" (or whatever
> >>  architecture it happens to be building on) to the profiler_builtins
> >> build
> >>  flags when the target matches the host. In the case where the
> >> target is
> >>  different from the host, it assumes a wasm build and sets
> >>  "rustc-link-lib=static=clang_rt.builtins-wasm32" or
> >> "cargo:rustc-link-lib=static=clang_rt.builtins-wasm64" depending
> >> upon
> >>  whether the target is 32 or 64 bits, respectively.
> >
> > Thanks for the patch! the Windows part in d/rules looks wrong to me -
> > that is built with mingw, not wasi. I assume you are not 
interested in

> > that part, so maybe it would also be an option to guard it based on
> > target and just build it for the regular one (or regular+wasm, but 
not

> > windows/mingw)?
>

After you pointed out the upstream patch on IRC 
(https://github.com/rust-lang/rust/pull/114069), I backported it to 
1.70 and tried building it. It gets pretty far, but fails late in the 
build on some tests. I'm going to do some more building (starting with 
rustc by itself without the profiler stuff, to ensure that the test 
failure I'm seeing is actually related to profiler). But in the 
meantime, here's the backported patch. If I can get it fully built, 
I'll follow up with the full debian patch or a merge request.





Ugh, unfortunately I'm hitting the same build failure even without 
profiler enabled. This is just rustc from sid without any changes 
failing. I can file a separate FTBFS bug if it's not some issue with my 
build environment...




 Debian rustc test report 
Specific test failures:
test [ui] tests/ui/io-checks/inaccessbile-temp-dir.rs ... FAILED
test [ui] tests/ui/io-checks/non-ice-error-on-worker-io-fail.rs ... FAILED
command did not execute successfully: BOOTSTRAP_CARGO="/usr/bin/cargo" 
DOC_RUST_LANG_ORG_CHANNEL="https://doc.rust-lang.org/1.70.0"; 
LD_LIBRARY_PATH="/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/stage0-bootstrap-tools/x86_64-unknown-linux-gnu/release/deps:/usr/lib" 
RUSTC="/usr/bin/rustc" RUSTC_BOOTSTRAP="1" 
RUSTC_FORCE_RUSTC_VERSION="compiletest" RUST_TEST_THREADS="16" 
RUST_TEST_TMPDIR="/rustc-1.70.0+dfsg1/build/tmp" 
"/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" 
"--compile-lib-path" 
"/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/stage2/lib" 
"--run-lib-path" 
"/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" 
"--rustc-path" 
"/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" 
"--src-base" "/rustc-1.70.0+dfsg1/tests/ui" "--build-base" 
"/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/test/ui" 
"--sysroot-base" 
"/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/stage2" "--stage-id" 
"stage2-x86_64-unknown-linux-gnu" "--suite" "ui" "--mode" "ui" 
"--target" "x86_64-unknown-linux-gnu" "--host" 
"x86_64-unknown-linux-gnu" "--llvm-filecheck" 
"/usr/lib/llvm-16/bin/FileCheck" "--nodejs" "/usr/bin/node" 
"--optimize-tests" "--target-linker" "x86_64-linux-gnu-gcc" 
"--host-linker" "x86_64-linux-gnu-gcc" "--host-rustcflags" "-Crpath" 
"--host-rustcflags" "-Cdebuginfo=0" "--host-rustcflags" 
"-Lnative=/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" 
"--target-rustcflags" "-Crpath" "--target-rustcflags" "-Cdebuginfo=0" 
"--target-rustcflags" 
"-Lnative=/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" 
"--python" "/usr/bin/python3" "--gdb" "/usr/bin/gdb" "--skip" 
"src/tools/tidy" "--verbose" "--json" "--llvm-version" "16.0.6" 
"--llvm-components" "aarch64 aarch64asmparser aarch64codegen aarch64desc 
aarch64disassembler aarch64info aarch64utils aggressiveins

Bug#1043311: [Pkg-rust-maintainers] Bug#1043311: rustc: please enable profiler builtin

[Andres Salomon]

On Fri, 08 Sep 2023 13:35:44 -0400 Andres Salomon  
wrote:

>
>
> On Fri, Sep 8 2023 at 10:36:48 AM +02:00:00, Fabian Grünbichler
>  wrote:
> >>  On Tue, Aug 8 2023 at 06:22:28 PM -04:00:00, Andres Salomon
> >>
> [...]
> >>
> >>  This patch adds
> >> "cargo:rustc-link-search=/usr/lib/clang/15/lib/linux/" and
> >>  "cargo:rustc-link-lib=static=clang_rt.profile-x86_64" (or 
whatever
> >>  architecture it happens to be building on) to the 
profiler_builtins

> >> build
> >>  flags when the target matches the host. In the case where the
> >> target is
> >>  different from the host, it assumes a wasm build and sets
> >>  "rustc-link-lib=static=clang_rt.builtins-wasm32" or
> >>  "cargo:rustc-link-lib=static=clang_rt.builtins-wasm64" depending
> >> upon
> >>  whether the target is 32 or 64 bits, respectively.
> >
> > Thanks for the patch! the Windows part in d/rules looks wrong to 
me -
> > that is built with mingw, not wasi. I assume you are not 
interested in

> > that part, so maybe it would also be an option to guard it based on
> > target and just build it for the regular one (or regular+wasm, but 
not

> > windows/mingw)?
>

After you pointed out the upstream patch on IRC 
(https://github.com/rust-lang/rust/pull/114069), I backported it to 
1.70 and tried building it. It gets pretty far, but fails late in the 
build on some tests. I'm going to do some more building (starting with 
rustc by itself without the profiler stuff, to ensure that the test 
failure I'm seeing is actually related to profiler). But in the 
meantime, here's the backported patch. If I can get it fully built, 
I'll follow up with the full debian patch or a merge request.



From d0b58f40a0e669897fafb614299d2a989997eda7 Mon Sep 17 00:00:00 2001
From: Josh Stone 
Date: Tue, 25 Jul 2023 13:11:50 -0700
Subject: [PATCH] Allow using external builds of the compiler-rt profile lib

This changes the bootstrap config `target.*.profiler` from a plain bool
to also allow a string, which will be used as a path to the pre-built
profiling runtime for that target. Then `profiler_builtins/build.rs`
reads that in a `LLVM_PROFILER_RT_LIB` environment variable.
---
 config.example.toml|  6 --
 library/profiler_builtins/build.rs |  6 ++
 src/bootstrap/compile.rs   |  4 
 src/bootstrap/config.rs| 30 --
 4 files changed, 38 insertions(+), 8 deletions(-)

--- a/config.example.toml
+++ b/config.example.toml
@@ -745,8 +745,10 @@ changelog-seen = 2
 # This option will override the same option under [build] section.
 #sanitizers = build.sanitizers (bool)
 
-# Build the profiler runtime for this target(required when compiling with options that depend
-# on this runtime, such as `-C profile-generate` or `-C instrument-coverage`).
+# When true, build the profiler runtime for this target(required when compiling
+# with options that depend on this runtime, such as `-C profile-generate` or
+# `-C instrument-coverage`). This may also be given a path to an existing build
+# of the profiling runtime library from LLVM's compiler-rt.
 # This option will override the same option under [build] section.
 #profiler = build.profiler (bool)
 
--- a/library/profiler_builtins/build.rs
+++ b/library/profiler_builtins/build.rs
@@ -6,6 +6,12 @@ use std::env;
 use std::path::Path;
 
 fn main() {
+println!("cargo:rerun-if-env-changed=LLVM_PROFILER_RT_LIB");
+if let Ok(rt) = env::var("LLVM_PROFILER_RT_LIB") {
+println!("cargo:rustc-link-lib=static:+verbatim={rt}");
+return;
+}
+
 let target = env::var("TARGET").expect("TARGET was not set");
 let cfg = &mut cc::Build::new();
 
--- a/src/bootstrap/compile.rs
+++ b/src/bootstrap/compile.rs
@@ -314,6 +314,10 @@ pub fn std_cargo(builder: &Builder<'_>,
 cargo.env("MACOSX_DEPLOYMENT_TARGET", target);
 }
 
+if let Some(path) = builder.config.profiler_path(target) {
+cargo.env("LLVM_PROFILER_RT_LIB", path);
+}
+
 // Determine if we're going to compile in optimized C intrinsics to
 // the `compiler-builtins` crate. These intrinsics live in LLVM's
 // `compiler-rt` repository, but our `src/llvm-project` submodule isn't
--- a/src/bootstrap/config.rs
+++ b/src/bootstrap/config.rs
@@ -454,7 +454,7 @@ pub struct Target {
 pub linker: Option,
 pub ndk: Option,
 pub sanitizers: Option,
-pub profiler: Option,
+pub profiler: Option,
 pub crt_static: Option,
 pub musl_root: Option,
 pub musl_libdir: Option,
@@ -715,9 +715,9 @@ define_config! {
 }
 }
 
-#[derive(Debug, Deserialize)]
+#[derive(Clone, Debug, Deserialize)]
 #[

Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address

[Andres Salomon]

On Sat, 14 Jan 2023 16:12:47 +0100 Salvatore Bonaccorso 
 wrote:

> Hi Jakub,
>
> On Thu, Jan 12, 2023 at 01:24:16PM +0100, Jakub Wilk wrote:
> > * Salvatore Bonaccorso , 2022-11-19 11:11:
> > > Given you were able to tackle the issue further, can you report 
the

> > > issue to upstream
> >
> > Don't count on me. Sorry!
>
> Okay thanks for beeing explicit on that. Then I guess it's on our end
> to try to get that upstream.
>
> Regards,
> Salvatore
>
>

This bug seems to also affect 64-bit mmap (though not nearly as badly), 
and is written about here:


https://zolutal.github.io/aslrnt/

Bug#1056562: chromium: hevc decoding is not supported

[Andres Salomon]

At least on my platform (amd64), enable_platform_hevc is automatically 
set to true:


 enable_hevc_parser_and_hw_decoder =
 proprietary_codecs &&
 (use_fuzzing_engine || is_win || is_apple || is_android || 
is_linux)


 enable_platform_hevc =
 proprietary_codecs && (enable_hevc_parser_and_hw_decoder ||


buildflag_header("media_buildflags") {
[...]
 flags = [
[...]
   "ENABLE_PLATFORM_HEVC=$enable_platform_hevc",

dilinger@hm90:~/sid-build/chromium-119.0.6045.159$ grep -q 
"ENABLE_PLATFORM_HEVC=true"  out/Release/toolchain.ninja; echo $?

0

Where is arm64 disabling it?

On Thu, Nov 23 2023 at 06:51:33 AM +00:00:00, Jianfeng Liu 
 wrote:

Package: chromium
Version: 119.0.6045.159-1~deb12u1
Severity: normal
Tags: patch

Dear Maintainer,

There are two build flags of chromium: enable_platform_hevc and
enable_hevc_parser_and_hw_decoder which will enable hevc codecs on
chromium. I have already made a patch to enable it:
https://salsa.debian.org/amazingfate/chromium/-/commit/2665056127fdac3abe84863eca5497fa4a503dd1.patch
I'm working on enabling v4l2 hardware decoding for arm64 linux 
chromium.

I've made some progress and some of the patches are already merged
upstream. This patch will let debian support v4l2 hardware decoding 
out

of box in future release.

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), 
(500, 'stable')

Architecture: arm64 (aarch64)

Kernel: Linux 5.4.225-200.el7.aarch64 (SMP w/64 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages chromium depends on:
ii  chromium-common119.0.6045.159-1~deb12u1
ii  libasound2 1.2.8-1+b1
ii  libatk-bridge2.0-0 2.46.0-5
ii  libatk1.0-02.46.0-5
ii  libatomic1 12.2.0-14
ii  libatspi2.0-0  2.46.0-5
ii  libc6  2.36-9+deb12u3
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-3+deb12u4
ii  libdbus-1-31.14.10-1~deb12u1
ii  libdouble-conversion3  3.2.1-1
ii  libdrm22.4.114-1+b1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-1
ii  libflac12  1.4.2+ds-2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-5
ii  libgbm122.3.6-1+deb12u1
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.6-2
ii  libgtk-3-0 3.24.38-2~deb12u1
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-4
ii  liblcms2-2 2.14-2
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.35-1
ii  libnss32:3.87.1-1
ii  libopenh264-7  2.3.1+dfsg-3
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.3.1-3
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpng16-161.6.39-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.9-3
ii  libstdc++6 12.2.0-14
ii  libwebp7   1.2.4-0.2+deb12u1
ii  libwebpdemux2  1.2.4-0.2+deb12u1
ii  libwebpmux31.2.4-0.2+deb12u1
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.3~deb12u1
ii  libxnvctrl0525.85.05-3~deb12u1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  119.0.6045.159-1~deb12u1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6 2.36-9+deb12u3
ii  libgcc-s1 12.2.0-14
ii  libjsoncpp25  1.9.5-4
ii  libstdc++612.2.0-14
ii  libx11-6  2:1.8.4-2+deb12u2
ii  libxnvctrl0   525.85.05-3~deb12u1
ii  x11-utils 7.7+5
ii  xdg-utils 1.1.3-4.1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox   119.0.6045.159-1~deb12u1
ii  fonts-liberation   1:1.07.4-11
ii  libgl1-mesa-dri22.3.6-1+deb12u1
ii  libu2f-udev1.1.10-3
ii  notification-daemon3.20.0-4+b1
ii  system-config-printer  1.5.18-1
ii  upower 0.99.20-2

Versions of packages chromium-sandbox depends on:
ii  libc6  2.36-9+deb12u3

-- no debconf information

Bug#1055765: chromium: Error: Can't open display (armhf) while other platforms (amd64, arm64, i386) are OK

[Andres Salomon]

Ah, so the "Can't open display" error is coming from xmessage, *not* 
chromium. I should fix that.


As far as qemu, I'd suggest filing a bug on that binfmt project to not 
use passthrough mode; I'm not sure if it should be something 
decided/set at build time, or if there's a way to get commandline 
arguments to qemu when executing binaries using the kernel's binfmt 
interface. Either way, that seems like something to discuss with the 
project author.


And for your purposes, if you want to just get the chromium version, 
you can skip the wrapper in /usr/bin and run 
`/usr/lib/chromium/chromium --version` instead. It won't be exactly the 
same output, but it will give you the version.




On Tue, Nov 14 2023 at 01:39:19 PM +01:00:00, Julien Neuhart 
 wrote:
Please find below the output of ‘bash -x /usr/bin/chromium 
—version’ (latest chromium version on armhf):


bash -x /usr/bin/chromium --version:
+ APPNAME=chromium
+ GDB=/usr/bin/gdb
+ LIBDIR=/usr/lib/chromium
+ BUILD_DIST=12.2
+ nosse3='The hardware on this system lacks support for the sse3 
instruction set.

The upstream chromium project no longer supports this configuration.
For more information, please read and possibly provide input to their
bug tracking system at http://crbug.com/1123353'
+ case `uname -m` in
++ uname -m
+ noneon='The hardware on this system lacks support for NEON SIMD 
extensions.

We now require NEON or equivalent architecture extensions on ARM-based
machines. See 
https://lists.debian.org/debian-devel/2023/09/msg00175.html

for more information.'
+ case `uname -m` in
++ uname -m
+ grep -q 'neon\|asimd' /proc/cpuinfo
+ xmessage 'The hardware on this system lacks support for NEON SIMD 
extensions.

We now require NEON or equivalent architecture extensions on ARM-based
machines. See 
https://lists.debian.org/debian-devel/2023/09/msg00175.html

for more information.'
Error: Can't open display:


Regarding QEMU, I’m a bit out of my depth to be honest.
Most of it is abstract to me, as I’m using a Docker buildkit which 
itself is relying on QEMU (as far as I know).


More precisely, I’m relying on this 
https://github.com/docker/setup-qemu-action GitHub Action, which 
itself relies on https://github.com/tonistiigi/binfmt to do the magic.


This repository seems to configure a custom version of QEMU (for 
instance, by applying patches) and configure it using:


set -x
./configure \
  --prefix=/usr \
  --with-pkgversion=$QEMU_VERSION \
  --enable-linux-user \
  --disable-system \
  --static \
  --disable-brlapi \
  --disable-cap-ng \
  --disable-capstone \
  --disable-curl \
  --disable-curses \
  --disable-docs \
  --disable-gcrypt \
  --disable-gnutls \
  --disable-gtk \
  --disable-guest-agent \
  --disable-guest-agent-msi \
  --disable-libiscsi \
  --disable-libnfs \
  --disable-mpath \
  --disable-nettle \
  --disable-opengl \
  --disable-pie \
  --disable-sdl \
  --disable-spice \
  --disable-tools \
  --disable-vte \
  --disable-werror \
  --disable-debug-info \
  --disable-glusterfs \
  --cross-prefix=$(xx-info)- \
  --host-cc=$(xx-clang --print-target-triple)-clang \
  --host=$(xx-clang --print-target-triple) \
  --build=$(TARGETPLATFORM= TARGETPAIR= xx-clang 
--print-target-triple) \

  --cc=$(xx-clang --print-target-triple)-clang \
  --extra-ldflags=-latomic \
  --target-list="$QEMU_TARGETS »

See 
https://github.com/tonistiigi/binfmt/blob/master/scripts/configure_qemu.sh 
and https://github.com/tonistiigi/binfmt/blob/master/Dockerfile for 
more details

Bug#1055905: Build dependencies not installable on (old)stable

[Andres Salomon]

On Mon, Nov 13 2023 at 08:52:38 PM -05:00:00, Daniel Richard G. 
 wrote:


(Where can I find the build logs? Those would have answered this
question, and more.)




That is a harder question to answer. :)

If you go to https://buildd.debian.org/status/package.php?p=chromium 
and select "Bookworm" for the suite, and hit "Go", you can see the 
build logs for the latest (bookworm) release. However, I have no idea 
how to get build logs for older releases - the "old" link takes you to 
older build logs for sid. I suspect that's a bug.

Bug#1055765: chromium: Error: Can't open display (armhf) while other platforms (amd64, arm64, i386) are OK

[Andres Salomon]

Control: found -1 117.0.5938.149-1~deb12u1

Thanks. More questions below:



On Mon, Nov 13 2023 at 08:28:41 PM +01:00:00, Julien Neuhart 
 wrote:
I’ve been able to reproduce the issue (e.g., Can’t open display) 
with versions 117.0.5938.149-1~deb12u1 and 118.0.5993.70-1~deb12u1.


uname -a:
Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP Fri Oct 
 6 13:20:44 UTC 2023 armv7l3 GNU/Linux



Okay, this looks fine. You're running qemu on an Ubuntu x86 host, so 
inside the VM it sees the Ubuntu kernel but as an armv7l architecture. 
Chromium's startup script should run `uname -m`, see 'armv7l', and do 
its 32-bit ARM checks.





cat /proc/cpuinfo:
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 106
model name  : Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz



Wait, what? Qemu doesn't bother to change /proc/cpuinfo for the VM, so 
it's going to think it's running an x86 CPU?





stepping: 6
microcode   : 0x
cpu MHz : 2793.437
cache size  : 49152 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 21
wp  : yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb 
rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq 
ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c 
rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti 
fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq 
rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec 
xsaves md_clear
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs taa itlb_multihit mmio_stale_data gds



Ugh, nor does it change cpu flags. The chromium script 
(/usr/bin/chromium) should've errored out with a message about NEON 
once it saw that the flags it needed in /proc/cpuinfo weren't present. 
So there's two problems here.


Can you please run `bash -x /usr/bin/chromium --version` and provide 
the output from that? Something's going wrong there. What *should* be 
happening is that you should be seeing the message:


"The hardware on this system lacks support for NEON SIMD extensions.
We now require NEON or equivalent architecture extensions on ARM-based
machines. See 
https://lists.debian.org/debian-devel/2023/09/msg00175.html

for more information."

Instead, it seems to be going ahead and launching chromium, which is 
likely then getting confused for other reasons. Feel free to use the 
latest available version of chromium for that test, you don't need to 
stick with 117 or whatever.


Now, there's also the separate question of what qemu's armhf emulation 
actually supports. It looks like, according to 
https://www.qemu.org/docs/master/system/qemu-cpu-models.html , you're 
running qemu in "Host passthrough" mode. That shouldn't work with 
chromium unless you modify /usr/bin/chromium to not check for 
NEON/ASIMD, and even then will probably have issues. I only see x86 and 
mips documented on that page, but I would suggest running qemu with 
something like "-cpu cortex-a15".

Bug#1055765: chromium: Error: Can't open display (armhf) while other platforms (amd64, arm64, i386) are OK

[Andres Salomon]

Probably the easiest way is to manually download the chromium and 
chromium-common deb packages, and then 'sudo apt install 
/path/to/chromium_117.x.y.z-1~deb12u1_armhf.deb 
/path/to/chromium-common_117.x.y.z-1~deb12u1_armhf.deb'.


If you go to 
https://snapshot.debian.org/package/chromium/117.0.5938.149-1~deb12u1/ 
in your browser, scroll down to the "chromium 117.0.5938.149-1~deb12u1" 
section, and then click on the link for 
"chromium_117.0.5938.149-1~deb12u1_armhf.deb" (or right click and click 
'save link as', or copy the link and supply it to wget/curl in the qemu 
environment), it should download it. Do the same thing in the 
"chromium-common 117.0.5938.149-1~deb12u1" section.


https://snapshot.debian.org/package/chromium/118.0.5993.70-1~deb12u1/ 
has more armhf deb packages, if the 117 packages aren't broken in your 
test. Unfortunately it looks like 118.0.5993.117-1 never successfully 
built for armhf on debian 12..




On Sun, Nov 12 2023 at 08:20:36 AM +01:00:00, Julien Neuhart 
 wrote:
Could you guide me on how ton install those versions? As far as I 
know, they are not available in bookworm directly. Thanks!


 Le 11 nov. 2023 à 21:51, Andres Salomon  a 
écrit :


 Okay, so not distribution-specific. Between 116 and 119 there were 
a considerable number of changes in the debian packaging, including 
switching from clang-14 to clang-16 for build (done in 
118.0.5993.117-1~deb12u1) and enabling NEON for armhf (done in 
117.0.5938.132-1~deb12u1). My immediate suspicion is the NEON 
change, so it would helpful if you could try those versions as well 
and report back. Also, if it turns out to be the NEON change, having 
the output of `uname -a` and `cat /proc/cpuinfo` (inside of qemu's 
armhf emulation) would be helpful.


 On Sat, Nov 11 2023 at 12:08:42 PM +01:00:00, Julien Neuhart 
 wrote:

 Hello Andres,
 Thanks for the quick follow up.
 So I’ve tested with Chromium 116.0.5845.180-1~deb12u1 and it 
works as expected on Debian 12.
 Note that I also had to explicitly install the chromium-common 
package:
 DEBIAN_FRONTEND=noninteractive apt-get install -y -qq 
--no-install-recommends chromium-common="116.0.5845.180-1~deb12u1" 
chromium="116.0.5845.180-1~deb12u1"

 Distributor ID:Debian
 Description:   Debian GNU/Linux 12 (bookworm)
 Release:   12
 Codename:  bookworm
 Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu 
SMP Fri Oct  6 13:20:44 UTC 2023 armv7l GNU/Linux

 Architecture: armhf
 chromium —version:
 ind: '/root/.config/chromium/Crash Reports/pending/': No such file 
or directory
 Chromium 116.0.5845.180 built on Debian 12.1, running on Debian 
12.2
 Le 10 nov. 2023 à 22:01, Andres Salomon  a 
écrit :

 Hi,
 Can you please try other versions if possible?  
119.0.6045.123-1~deb12u1 is currently in bookworm-security. 
116.0.5845.180-1~deb12u1 is still in bookworm. It would be helpful 
to know if this is a bookworm-specific regression, since it worked 
on bullseye's 116, or something broken in general with chromium 
119.
 It looks like a version of 117 and 118 also successfully built 
for armhf, as other option to try:
 
https://snapshot.debian.org/package/chromium/118.0.5993.70-1~deb12u1/
 
https://snapshot.debian.org/package/chromium/117.0.5938.149-1~deb12u1/
 On Fri, Nov 10 2023 at 09:49:00 PM +01:00:00, Julien Neuhart 
 wrote:

 Package: chromium
 Version: 119.0.6045.105-1~deb12u1
 Dear maintainers,
 While building with QEMU a Docker image based on Debian bookworm 
using the chromium package, I found out that the « armhf » 
variant seems broken, which is not the case for others platforms.

 Indeed, after having installed chromium with:
 DEBIAN_FRONTEND=noninteractive apt-get install -y -qq 
--no-install-recommends chromium
 Running « chromium —version » failed on armhf (Error: Can't 
open display) while working as expected in others platform 
(amd64, arm64, i386).
 Please note it is working fine in Debian 11 & package version 
116.0.5845.180.
 Full installation logs may be found here: 
https://github.com/gulien/chromium/actions/runs/6829257786

 armhf:
 Distributor ID: Debian
 Description: Debian GNU/Linux 12 (bookworm)
 Release:   12
 Codename: bookworm
 Kernel: Linux buildkitsandbox 6.2.0-1015-azure 
#15~22.04.1-Ubuntu SMP Fri Oct  6 13:20:44 UTC 2023 armv7l 
GNU/Linux

 Architecture: armhf
 chromium —version:
 Error: Can't open display:
 i386:
 Distributor ID: Debian
 Description: Debian GNU/Linux 12 (bookworm)
 Release:   12
 Codename: bookworm
 Kernel: Linux buildkitsandbox 6.2.0-1015-azure 
#15~22.04.1-Ubuntu SMP Fri Oct  6 13:20:44 UTC 2023 x86_64 
GNU/Linux

 Architecture: i386
 chromium —version:
 find: '/root/.config/chromium/Crash Reports/pending/': No such 
file or directory
 Chromium 119.0.6045.123 built on Debian 12.2, running on Debian 
12.2

 arm64:
 Distributor ID: Debian
 Description: Debian GNU/Linux 12 (bookw

Bug#1055765: chromium: Error: Can't open display (armhf) while other platforms (amd64, arm64, i386) are OK

[Andres Salomon]

Okay, so not distribution-specific. Between 116 and 119 there were a 
considerable number of changes in the debian packaging, including 
switching from clang-14 to clang-16 for build (done in 
118.0.5993.117-1~deb12u1) and enabling NEON for armhf (done in 
117.0.5938.132-1~deb12u1). My immediate suspicion is the NEON change, 
so it would helpful if you could try those versions as well and report 
back. Also, if it turns out to be the NEON change, having the output of 
`uname -a` and `cat /proc/cpuinfo` (inside of qemu's armhf emulation) 
would be helpful.


On Sat, Nov 11 2023 at 12:08:42 PM +01:00:00, Julien Neuhart 
 wrote:

Hello Andres,

Thanks for the quick follow up.

So I’ve tested with Chromium 116.0.5845.180-1~deb12u1 and it works 
as expected on Debian 12.


Note that I also had to explicitly install the chromium-common 
package:
DEBIAN_FRONTEND=noninteractive apt-get install -y -qq 
--no-install-recommends chromium-common="116.0.5845.180-1~deb12u1" 
chromium="116.0.5845.180-1~deb12u1"


Distributor ID: Debian
Description:Debian GNU/Linux 12 (bookworm)
Release:12
Codename:   bookworm
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP 
Fri Oct  6 13:20:44 UTC 2023 armv7l GNU/Linux

Architecture: armhf

chromium —version:
ind: '/root/.config/chromium/Crash Reports/pending/': No such file or 
directory

Chromium 116.0.5845.180 built on Debian 12.1, running on Debian 12.2

 Le 10 nov. 2023 à 22:01, Andres Salomon  a 
écrit :


 Hi,

 Can you please try other versions if possible?  
119.0.6045.123-1~deb12u1 is currently in bookworm-security. 
116.0.5845.180-1~deb12u1 is still in bookworm. It would be helpful 
to know if this is a bookworm-specific regression, since it worked 
on bullseye's 116, or something broken in general with chromium 119.


 It looks like a version of 117 and 118 also successfully built for 
armhf, as other option to try:
 
https://snapshot.debian.org/package/chromium/118.0.5993.70-1~deb12u1/
 
https://snapshot.debian.org/package/chromium/117.0.5938.149-1~deb12u1/


 On Fri, Nov 10 2023 at 09:49:00 PM +01:00:00, Julien Neuhart 
 wrote:

 Package: chromium
 Version: 119.0.6045.105-1~deb12u1
 Dear maintainers,
 While building with QEMU a Docker image based on Debian bookworm 
using the chromium package, I found out that the « armhf » 
variant seems broken, which is not the case for others platforms.

 Indeed, after having installed chromium with:
 DEBIAN_FRONTEND=noninteractive apt-get install -y -qq 
--no-install-recommends chromium
 Running « chromium —version » failed on armhf (Error: Can't 
open display) while working as expected in others platform (amd64, 
arm64, i386).
 Please note it is working fine in Debian 11 & package version 
116.0.5845.180.
 Full installation logs may be found here: 
https://github.com/gulien/chromium/actions/runs/6829257786

 armhf:
 Distributor ID: Debian
 Description: Debian GNU/Linux 12 (bookworm)
 Release:   12
 Codename: bookworm
 Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu 
SMP Fri Oct  6 13:20:44 UTC 2023 armv7l GNU/Linux

 Architecture: armhf
 chromium —version:
 Error: Can't open display:
 i386:
 Distributor ID: Debian
 Description: Debian GNU/Linux 12 (bookworm)
 Release:   12
 Codename: bookworm
 Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu 
SMP Fri Oct  6 13:20:44 UTC 2023 x86_64 GNU/Linux

 Architecture: i386
 chromium —version:
 find: '/root/.config/chromium/Crash Reports/pending/': No such 
file or directory
 Chromium 119.0.6045.123 built on Debian 12.2, running on Debian 
12.2

 arm64:
 Distributor ID: Debian
 Description: Debian GNU/Linux 12 (bookworm)
 Release:   12
 Codename: bookworm
 Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu 
SMP Fri Oct  6 13:20:44 UTC 2023 aarch64 GNU/Linux

 Architecture: arm64
 chromium --version:
 find: '/root/.config/chromium/Crash Reports/pending/': No such 
file or directory
 Chromium 119.0.6045.105 built on Debian 12.2, running on Debian 
12.2

 amd64:
 Distributor ID: Debian
 Description: Debian GNU/Linux 12 (bookworm)
 Release:   12
 Codename: bookworm
 Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu 
SMP Fri Oct  6 13:20:44 UTC 2023 x86_64 GNU/Linux

 Architecture: amd64
 chromium --version:
 find: '/root/.config/chromium/Crash Reports/pending/': No such 
file or directory
 Chromium 119.0.6045.123 built on Debian 12.2, running on Debian 
12.2

 Thanks,
 Julien

Bug#1055765: chromium: Error: Can't open display (armhf) while other platforms (amd64, arm64, i386) are OK

[Andres Salomon]

Hi,

Can you please try other versions if possible?  
119.0.6045.123-1~deb12u1 is currently in bookworm-security. 
116.0.5845.180-1~deb12u1 is still in bookworm. It would be helpful to 
know if this is a bookworm-specific regression, since it worked on 
bullseye's 116, or something broken in general with chromium 119.


It looks like a version of 117 and 118 also successfully built for 
armhf, as other option to try:

https://snapshot.debian.org/package/chromium/118.0.5993.70-1~deb12u1/
https://snapshot.debian.org/package/chromium/117.0.5938.149-1~deb12u1/

On Fri, Nov 10 2023 at 09:49:00 PM +01:00:00, Julien Neuhart 
 wrote:

Package: chromium
Version: 119.0.6045.105-1~deb12u1

Dear maintainers,

While building with QEMU a Docker image based on Debian bookworm 
using the chromium package, I found out that the « armhf » variant 
seems broken, which is not the case for others platforms.


Indeed, after having installed chromium with:
DEBIAN_FRONTEND=noninteractive apt-get install -y -qq 
--no-install-recommends chromium


Running « chromium —version » failed on armhf (Error: Can't open 
display) while working as expected in others platform (amd64, arm64, 
i386).


Please note it is working fine in Debian 11 & package version 
116.0.5845.180.


Full installation logs may be found here: 
https://github.com/gulien/chromium/actions/runs/6829257786


armhf:

Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release:12
Codename: bookworm
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP 
Fri Oct  6 13:20:44 UTC 2023 armv7l GNU/Linux

Architecture: armhf

chromium —version:
Error: Can't open display:

i386:

Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release:12
Codename: bookworm
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP 
Fri Oct  6 13:20:44 UTC 2023 x86_64 GNU/Linux

Architecture: i386

chromium —version:
find: '/root/.config/chromium/Crash Reports/pending/': No such file 
or directory

Chromium 119.0.6045.123 built on Debian 12.2, running on Debian 12.2

arm64:

Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release:12
Codename: bookworm
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP 
Fri Oct  6 13:20:44 UTC 2023 aarch64 GNU/Linux

Architecture: arm64

chromium --version:
find: '/root/.config/chromium/Crash Reports/pending/': No such file 
or directory

Chromium 119.0.6045.105 built on Debian 12.2, running on Debian 12.2

amd64:

Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release:12
Codename: bookworm
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP 
Fri Oct  6 13:20:44 UTC 2023 x86_64 GNU/Linux

Architecture: amd64

chromium --version:
find: '/root/.config/chromium/Crash Reports/pending/': No such file 
or directory

Chromium 119.0.6045.123 built on Debian 12.2, running on Debian 12.2

Thanks,

Julien

Bug#1055188: please disable video autoplay by default

[Andres Salomon]

Package: firefox-esr
Version: 115.4.0esr-1~deb12u1
Severity: wishlist

Last night my laptop crashed (hung hard) multiple times. I noticed that 
it was running really hot, and that several tabs I had open on a site 
(tabs.ultimate-guitar.com) were autoplaying videos in the background. I 
went into Settings, set autoplay "Default for all websites" to "Block 
Audio and Video", and my laptop has been running noticeably cooler ever 
since.


Now obviously my laptops fans & cpu scaling should be able to handle 
playing multiple videos, so I haven't solved the root of the problem, 
but also autoplaying videos is vile. It would be great if firefox in 
debian could change this setting to disable autoplaying of videos by 
default.

Bug#1054096: bookworm-pu: package llvm-toolchain-16/16.0.6-15~deb12u1

[Andres Salomon]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Here's the update to stable for clang-16, like we recently did for 
oldstable.


[ Reason ]

Chromium 118 wouldn't build on clang-13, so we added clang-16 to 
oldstable (#1053761). In order to be consistent across distributions 
(and also allowing us to drop a bunch of clang-14 & clang-15 workaround 
patches from chromium), we should add clang-16 to stable as well.


[ Impact ]

There's no impact for users, as packages in stable must explicitly 
choose to build against clang-16.


[ Tests ]

Chromium 118.0.5993.70 succeeded in building and running on bookworm 
with the clang-16 packages from llvm-toolchain-16_16.0.6-15~deb12u1.


[ Risks ]

Low/no risk. Clang-16 is not currently in stable.

On oldstable, it built for all archs except mipsel 
(https://buildd.debian.org/status/package.php?p=llvm-toolchain-16&suite=bullseye), 
so I'm not anticipating any other architecture build issues on stable.


[ Checklist ]

 [x] *all* changes are documented in the d/changelog
 [x] I reviewed all changes and I approve them
 [x] attach debdiff against the package in (old)stable
 [x] the issue is verified as fixed in unstable

[ Changes ]

This is the diff against llvm-toolchain-16_16.0.6-15 in trixie, since 
llvm-toolchain-16 isn't currently in bookworm:


diff -urN a/llvm-toolchain-16-16.0.6/debian/changelog 
b/llvm-toolchain-16-16.0.6/debian/changelog
--- a/llvm-toolchain-16-16.0.6/debian/changelog	2023-09-11 
13:40:42.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/changelog	2023-10-16 
13:14:10.0 +

@@ -1,3 +1,11 @@
+llvm-toolchain-16 (1:16.0.6-15~deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bullseye.
+  * Change build-dep from sid's llvm-spirv-16 to bookworm's 
llvm-spirv-14.

+
+ -- Andres Salomon   Mon, 16 Oct 2023 13:14:10 
+

+
llvm-toolchain-16 (1:16.0.6-15) unstable; urgency=medium

  * Second attempt to refresh D158066.patch (Closes: #1049362)
diff -urN a/llvm-toolchain-16-16.0.6/debian/control 
b/llvm-toolchain-16-16.0.6/debian/control
--- a/llvm-toolchain-16-16.0.6/debian/control	2023-09-10 
06:14:34.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/control	2023-10-16 
13:14:10.0 +

@@ -23,7 +23,7 @@
libctypes-ocaml-dev [amd64 arm64 armhf ppc64el riscv64 s390x],
dh-exec, dh-ocaml [amd64 arm64 armhf ppc64el riscv64 s390x],
libpfm4-dev [linux-any], python3-setuptools, libz3-dev,
-llvm-spirv-16 [ amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x ]  | hello [!i386],
+llvm-spirv-14 [ amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x ]  | hello [!i386],

spirv-tools [ linux-any ] | hello [ !i386],
wasi-libc | hello [ !any-i386],
libcurl4-openssl-dev | libcurl-dev,
diff -urN a/llvm-toolchain-16-16.0.6/debian/control.in 
b/llvm-toolchain-16-16.0.6/debian/control.in
--- a/llvm-toolchain-16-16.0.6/debian/control.in	2023-09-10 
06:14:36.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/control.in	2023-10-16 
13:14:10.0 +

@@ -23,7 +23,7 @@
libctypes-ocaml-dev [amd64 arm64 armhf ppc64el riscv64 s390x],
dh-exec, dh-ocaml [amd64 arm64 armhf ppc64el riscv64 s390x],
libpfm4-dev [linux-any], python3-setuptools, libz3-dev,
-llvm-spirv-16 [ amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x ]  | hello [!i386],
+llvm-spirv-14 [ amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x ]  | hello [!i386],

spirv-tools [ linux-any ] | hello [ !i386],
wasi-libc | hello [ !any-i386],
libcurl4-openssl-dev | libcurl-dev,



[ Other info ]

Bug#1053761: bullseye-pu: package llvm-toolchain-16/16.0.6-15~deb11u1

[Andres Salomon]

On Sat, Oct 14 2023 at 12:01:05 PM +01:00:00, Adam D. Barratt 
 wrote:

On Sat, 2023-10-14 at 00:54 -0400, Andres Salomon wrote:

 I built deb11u2 with the following changes from 16.0.6-15. Chromium
 successfully builds against it. Let me know if you want me to file a
 separate release.d.o bug for it, or just upload it, or what.


[...]

 --- a/llvm-toolchain-16-16.0.6/debian/control   2023-09-10
 06:14:34.0 +
 +++ b/llvm-toolchain-16-16.0.6/debian/control   2023-10-13
 16:24:09.0 +
 @@ -23,7 +23,7 @@
  libctypes-ocaml-dev [amd64 arm64 armhf ppc64el riscv64 s390x],
  dh-exec, dh-ocaml [amd64 arm64 armhf ppc64el riscv64 s390x],
  libpfm4-dev [linux-any], python3-setuptools, libz3-dev,
 -llvm-spirv-16 [ amd64 arm64 armel armhf i386 mips64el ppc64el
 riscv64 s390x ]  | hello [!i386],
 +llvm-spirv [ amd64 arm64 armel armhf i386 mips64el ppc64el
 riscv64
 s390x ]  | hello [!i386],



Please go ahead (as a source-only upload).



Thanks, uploaded.


fwiw, for bookworm it looks like we'll need to use either 
llvm-spirv-14

or llvm-spirv-15.



I'll get started on the bookworm llvm stuff once chromium's 
uploaded/built for bullseye-security.


BTW, the bullseye llvm package went and reverted d/control when I 
rebuilt it, so I had to change d/control.in as well. The actual diff 
for what I uploaded:



diff -urN a/llvm-toolchain-16-16.0.6/debian/changelog 
b/llvm-toolchain-16-16.0.6/debian/changelog
--- a/llvm-toolchain-16-16.0.6/debian/changelog	2023-09-11 
13:40:42.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/changelog	2023-10-13 
16:25:00.0 +

@@ -1,3 +1,16 @@
+llvm-toolchain-16 (1:16.0.6-15~deb11u2) bullseye; urgency=medium
+
+  * Build-dep on llvm-spirv instead of llvm-spirv-16 to make sbuild 
happy.

+
+ -- Andres Salomon   Fri, 13 Oct 2023 16:25:00 
+

+
+llvm-toolchain-16 (1:16.0.6-15~deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bullseye.
+
+ -- Andres Salomon   Tue, 10 Oct 2023 05:55:47 
+

+
llvm-toolchain-16 (1:16.0.6-15) unstable; urgency=medium

  * Second attempt to refresh D158066.patch (Closes: #1049362)
diff -urN a/llvm-toolchain-16-16.0.6/debian/control 
b/llvm-toolchain-16-16.0.6/debian/control
--- a/llvm-toolchain-16-16.0.6/debian/control	2023-09-10 
06:14:34.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/control	2023-10-13 
16:25:00.0 +

@@ -23,7 +23,7 @@
libctypes-ocaml-dev [amd64 arm64 armhf ppc64el riscv64 s390x],
dh-exec, dh-ocaml [amd64 arm64 armhf ppc64el riscv64 s390x],
libpfm4-dev [linux-any], python3-setuptools, libz3-dev,
-llvm-spirv-16 [ amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x ]  | hello [!i386],
+llvm-spirv [ amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 
s390x ]  | hello [!i386],

spirv-tools [ linux-any ] | hello [ !i386],
wasi-libc | hello [ !any-i386],
libcurl4-openssl-dev | libcurl-dev,
diff -urN a/llvm-toolchain-16-16.0.6/debian/control.in 
b/llvm-toolchain-16-16.0.6/debian/control.in
--- a/llvm-toolchain-16-16.0.6/debian/control.in	2023-09-10 
06:14:36.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/control.in	2023-10-13 
16:25:00.0 +

@@ -23,7 +23,7 @@
libctypes-ocaml-dev [amd64 arm64 armhf ppc64el riscv64 s390x],
dh-exec, dh-ocaml [amd64 arm64 armhf ppc64el riscv64 s390x],
libpfm4-dev [linux-any], python3-setuptools, libz3-dev,
-llvm-spirv-16 [ amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x ]  | hello [!i386],
+llvm-spirv [ amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 
s390x ]  | hello [!i386],

spirv-tools [ linux-any ] | hello [ !i386],
wasi-libc | hello [ !any-i386],
libcurl4-openssl-dev | libcurl-dev,

Bug#1053761: bullseye-pu: package llvm-toolchain-16/16.0.6-15~deb11u1

[Andres Salomon]

On Fri, Oct 13 2023 at 11:32:57 AM -04:00:00, Andres Salomon 
 wrote:



On Fri, Oct 13 2023 at 02:59:08 PM +01:00:00, Adam D. Barratt 
 wrote:

On Wed, 2023-10-11 at 06:37 +0100, Adam D. Barratt wrote:

 Control: tags -1 + confirmed

 On Tue, 2023-10-10 at 12:21 -0400, Andres Salomon wrote:
 > Chromium newest version FTBFS on bullseye with clang-13, but 
works

 > fine with clang-16.
 >


[...]

 Please go ahead.



Unfortunately the package isn't getting built anywhere, because it
Build-Depends on llvm-spirv-16, which also isn't in bullseye.

How did you manage to build the amd64 upload for NEW?



I don't have llvm-spirv-16 installed in the container where I built 
it, but I do have the 'hello' package installed. It looks like that's 
not going to work for i386 though, so shall I also build/upload 
llvm-spirv-16? Alternatively, it looks like an unreleased version of 
clang-16 (1:16.0.6-16) has changed the build-dep to allow for 
llvm-spirv-14 or llvm-spirv-15 
(https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/9af30d9926b6e93580262310fa652d19fcc15869). 
I could try changing the build-dep to the clang-11 and clang-13 
equivalent of 'llvm-spirv' and uploading llvm-toolchain-16 
1:16.0.6-15~deb11u2.






I built deb11u2 with the following changes from 16.0.6-15. Chromium 
successfully builds against it. Let me know if you want me to file a 
separate release.d.o bug for it, or just upload it, or what.




diff -urN a/llvm-toolchain-16-16.0.6/debian/changelog 
b/llvm-toolchain-16-16.0.6/debian/changelog
--- a/llvm-toolchain-16-16.0.6/debian/changelog 2023-09-11 
13:40:42.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/changelog 2023-10-13 
16:25:00.0 +

@@ -1,3 +1,16 @@
+llvm-toolchain-16 (1:16.0.6-15~deb11u2) bullseye; urgency=medium
+
+  * Build-dep on llvm-spirv instead of llvm-spirv-16 to make sbuild 
happy.

+
+ -- Andres Salomon   Fri, 13 Oct 2023 16:25:00 
+

+
+llvm-toolchain-16 (1:16.0.6-15~deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bullseye.
+
+ -- Andres Salomon   Tue, 10 Oct 2023 05:55:47 
+

+
llvm-toolchain-16 (1:16.0.6-15) unstable; urgency=medium

  * Second attempt to refresh D158066.patch (Closes: #1049362)
diff -urN a/llvm-toolchain-16-16.0.6/debian/control 
b/llvm-toolchain-16-16.0.6/debian/control
--- a/llvm-toolchain-16-16.0.6/debian/control   2023-09-10 
06:14:34.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/control   2023-10-13 
16:24:09.0 +

@@ -23,7 +23,7 @@
libctypes-ocaml-dev [amd64 arm64 armhf ppc64el riscv64 s390x],
dh-exec, dh-ocaml [amd64 arm64 armhf ppc64el riscv64 s390x],
libpfm4-dev [linux-any], python3-setuptools, libz3-dev,
-llvm-spirv-16 [ amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x ]  | hello [!i386],
+llvm-spirv [ amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 
s390x ]  | hello [!i386],

spirv-tools [ linux-any ] | hello [ !i386],
wasi-libc | hello [ !any-i386],
libcurl4-openssl-dev | libcurl-dev,

Bug#1053761: bullseye-pu: package llvm-toolchain-16/16.0.6-15~deb11u1

[Andres Salomon]

On Fri, Oct 13 2023 at 02:59:08 PM +01:00:00, Adam D. Barratt 
 wrote:

On Wed, 2023-10-11 at 06:37 +0100, Adam D. Barratt wrote:

 Control: tags -1 + confirmed

 On Tue, 2023-10-10 at 12:21 -0400, Andres Salomon wrote:
 > Chromium newest version FTBFS on bullseye with clang-13, but works
 > fine with clang-16.
 >


[...]

 Please go ahead.



Unfortunately the package isn't getting built anywhere, because it
Build-Depends on llvm-spirv-16, which also isn't in bullseye.

How did you manage to build the amd64 upload for NEW?



I don't have llvm-spirv-16 installed in the container where I built it, 
but I do have the 'hello' package installed. It looks like that's not 
going to work for i386 though, so shall I also build/upload 
llvm-spirv-16? Alternatively, it looks like an unreleased version of 
clang-16 (1:16.0.6-16) has changed the build-dep to allow for 
llvm-spirv-14 or llvm-spirv-15 
(https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/9af30d9926b6e93580262310fa652d19fcc15869). 
I could try changing the build-dep to the clang-11 and clang-13 
equivalent of 'llvm-spirv' and uploading llvm-toolchain-16 
1:16.0.6-15~deb11u2.

Bug#1053813: chromium: The URLs in the chromium man page return 404

[Andres Salomon]

We do patch the man page 
(), 
but those urls are wrong upstream. Feel free to submit patches 
upstream, or when I'm sending a bunch of other stuff upstream I'll fix 
this as well.


On Wed, Oct 11 2023 at 04:41:42 PM -05:00:00, Karl O. Pinc 
 wrote:

Package: chromium
Version: 117.0.5938.149-1~deb11u1
Severity: normal

Hi,

The chromium man page has URLs that are supposed to point to
GTK+ common command line arguments.  They return 404.

I believe that the proper URL to use instead is:



But it seems GTK4 has only environment vars, and those only
for debugging, so maybe the urls should be removed entirely.

Apologies if this is an upstream bug.  I see that

(sid, as of now) has the outdated urls.  And there's no
debian patch.  But the above man page also has links to the debian
bug tracker and it's debian policy to have man pages and
I know debian maintains a lot of man pages so
I'm going ahead and filing this and hoping it gets to the
right place.  Feel free to discard this report if unapplicable.

-- System Information:
Debian Release: 11.8
  APT prefers oldstable-security
  APT policy: (500, 'oldstable-security'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-26-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common
117.0.5938.149-1~deb11u1

ii  libasound2 1.2.4-1.1
ii  libatk-bridge2.0-0 2.38.0-1
ii  libatk1.0-02.36.0-2
ii  libatomic1 10.2.1-6
ii  libatspi2.0-0  
2.38.0-4+deb11u1

ii  libc6  2.31-13+deb11u7
ii  libcairo2  1.16.0-5
ii  libcups2   
2.3.3op2-3+deb11u6
ii  libdbus-1-3
1.12.28-0+deb11u1

ii  libdouble-conversion3  3.1.5-6.1
ii  libdrm22.4.104-1
ii  libevent-2.1-7 2.1.12-stable-1
ii  libexpat1  
2.2.10-2+deb11u5

ii  libflac8   1.3.3-2+deb11u2
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   
2.10.4+dfsg-1+deb11u1

ii  libgbm120.3.5-1
ii  libgcc-s1  10.2.1-6
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 
3.24.24-4+deb11u3

ii  libjpeg62-turbo1:2.0.6-4
ii  libjsoncpp24   1.9.4-4
ii  liblcms2-2 2.12~rc1-2
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.29-1
ii  libnss3
2:3.61-1+deb11u3

ii  libopenjp2-7   2.4.0-3
ii  libopus0   1.3.1-0.1
ii  libpango-1.0-0 1.46.2-3
ii  libpng16-161.6.37-3
ii  libpulse0  14.2-2
ii  libsnappy1v5   1.1.8-1
ii  libstdc++6 10.2.1-6
ii  libwebp6   
0.6.1-2.1+deb11u2
ii  libwebpdemux2  
0.6.1-2.1+deb11u2
ii  libwebpmux3
0.6.1-2.1+deb11u2

ii  libwoff1   1.0.2-1+b1
ii  libx11-6   
2:1.7.2-1+deb11u2

ii  libxcb11.14-3
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.5-2
ii  libxext6   2:1.3.3-1.1
ii  libxfixes3 1:5.0.3-2
ii  libxkbcommon0  1.0.3-2
ii  libxml2
2.9.10+dfsg-6.7+deb11u4
ii  libxnvctrl0
470.141.03-1~deb11u1

ii  libxrandr2 2:1.5.1-1
ii  libxslt1.1  

Bug#1053767: chromium: please to add support for s390x or armel

[Andres Salomon]

On Tue, Oct 10 2023 at 08:34:51 PM +02:00:00, William Desportes 
 wrote:

Source: chromium
Version: 117.0.5938.149-1
Severity: wishlist
User: debian-s...@lists.debian.org 


Usertags: s390x
User: debian-...@lists.debian.org 
Usertags: armel
X-Debbugs-Cc: debian-s...@lists.debian.org 

X-Debbugs-Cc: debian-...@lists.debian.org 



Dear Maintainer,

Chromium could be built on Debian s390x or armel, but it would 
probably require some upstream work.


For now when trying to build on my Linux One s390x VM I got this:

ERROR at 
//base/allocator/partition_allocator/partition_alloc.gni:25:3: 
Assertion failed.

  assert(false, "Unknown CPU: $current_cpu")
Unknown CPU: s390x

Let me know what direction to go if it's worth trying to add support 
for s390x or not.
I would definitely like to have armel supported, maybe it's a more 
suitable target. ()


Once both architectures are built DEP-8 tests will be able to use 
chromium-driver on them.




You have several options. If upstream is hostile to adding support for 
your architecture (as is the case for ppc64el, which has roughly 50 
architecture-specific patches in debian), you're welcome to become a 
chromium co-maintainer and maintain a set of patches that enable s390x 
or armel or whatever. Once a month or so, you'll probably need to 
refresh your patches to ensure they apply/build/function properly. And 
if you stop maintaining the patch set, your architecture will be 
dropped from the chromium packages.


If upstream is receptive to adding support for your architecture, you 
can send patches upstream to get chromium building on it. Once it can 
successfully build on your architecture with minimal or no changes, I'd 
be happy to enable the architecture. For example i386 is currently 
supported because it mostly works, and only requires 1-2 patches to get 
it building. If your architecture is already in that state, let me know 
and I can give it a try on a porter box and then upload to experimental.

Bug#1053761: bullseye-pu: package llvm-toolchain-16/16.0.6-15~deb11u1

[Andres Salomon]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Chromium newest version FTBFS on bullseye with clang-13, but works fine 
with clang-16.


[ Reason ]
Chromium 118 (which will likely be released as stable today, and 
probably with CVEs) fails to build on bullseye's clang-13 with an issue 
that I can't figure out. I've got plenty of clang-13 workarounds in 
chromium already, but this most recent issue is in a large (tens of 
thousands of lines long), complex autogenerated c++ file. The file is 
generated exactly the same on bookworm & bullseye, but fails on 
bullseye's clang-13 while succeeding on bookworm's clang-14. I'm stuck 
at this point, and having clang-16 in bullseye would allow us to easily 
continue chromium's bullseye-security support. It will also allow us to 
drop a bunch of crufty workaround patches.


[ Impact ]
There's no impact for users, as packages in stable must explicitly 
choose to build against clang-16.


[ Tests ]
Chromium 118.0.5993.54 succeeded in building and running on bullseye 
with clang-16 packages from llvm-toolchain-16_16.0.6-15~deb11u1.


[ Risks ]
Low/no risk. Clang-16 is not currently in bullseye.

[ Checklist ]
 [x] *all* changes are documented in the d/changelog
 [x] I reviewed all changes and I approve them
 [ ] attach debdiff against the package in (old)stable
 [x] the issue is verified as fixed in unstable

[ Changes ]

The changelog entry:

llvm-toolchain-16 (1:16.0.6-15~deb11u1) bullseye; urgency=medium
.
  * Non-maintainer upload.
  * Rebuild for bullseye.

No additional changes were necessary. I've not included a debdiff, 
since clang-16 is not already in bullseye.


[ Other info ]
For consistency and ease of maintenance I'll probably prepare this same 
package for bookworm, once 118 is released and all the security uploads 
are complete.

Bug#1052419: cups-daemon: NEWS.Debian is only tech-gibberish

[Andres Salomon]

On Thu, 21 Sep 2023 19:38:44 +0200 IOhannes m zmoelnig 
 wrote:

> Package: cups-daemon
> Version: 2.4.2-6
> Followup-For: Bug #1052419
>
> Just as a follow-up: after double-checking my cupsd.conf file, I see 
that
> the  section is present multiple-times in 
the
> document, once each in the "default", "authenticated" and "kerberos" 
Policy

> section.
> I assume, that the patch needs to be applied to the "default" 
policy, as for the

> other policies there is already an AuthType defined.
>
> is this correct?
> (the nature of a patch file does not make this obvious)
> this ought to be documented as well.
>
> And since i'm pretty sure that i've neve touched this file myself 
(at least
> etckeeper shows that it was only ever changed while i installed 
cups-daemon 1½
> years ago), i wonder why there was no dialog showing me the 
differences between

> the files.
>
>
> cheers


It is confusing. Given that the vast majority of people don't touch 
cupsd.conf, maybe the NEWS entry should say something like the 
following?


"If you've never touched cupsd.conf and are unsure what to do, it's 
probably safest to simply run the following commands:
sudo cp /etc/cups/cupsd.conf /etc/cups/cupsd.conf-bak; sudo cp  
/usr/share/cups/cupsd.conf.default /etc/cups/cupsd.conf


In case printing stops working after making that change, you can 
restore the old configuration file. However, note that restoring the 
old config will reintroduce the security hole. Do the configuration 
file restoration by running:

sudo mv /etc/cups/cupsd.conf-bak /etc/cups/cupsd.conf
"


Or even better, have a cups.postinst that checks /etc/cups/cupsd.conf's 
md5sum == 758e3a2fb820f5cfb8aed788f2c8f353, and if so automatically 
copy over that cupsd.conf.default config and restart cupsd. I just 
checked two machines (sid and bookworm) and my untouched cupsd.conf 
matches that checksum on both.

Bug#1053277: libcups2: typo in NEWS

[Andres Salomon]

Control: severity -1 important


On Sat, 30 Sep 2023 19:24:53 +0200 Thorsten Alteholz 
 wrote:

> Hi Christian,
>
> On 30.09.23 19:02, Christian T. Steigies wrote:
> > I did not find this file (because I don't have a full install), 
but I think

> > the filename should be cupsd.conf instead of cupds.conf.
>
> oops, thanks for telling. You are right, the correct name would have
> been cupsd.conf
>
>Thorsten
>
>
>


I think this should be a higher priority, since this is a security 
update and you're telling folks to ensure their config file is 
up-to-date. The typo for the config file path means a chunk of users 
won't know what file to check.


Even better would be to automatically update the config file of course, 
but I understand that's extremely difficult in this case..

Bug#1053256: ITP: bypass-paywalls-firefox-clean -- Firefox browser plugin to bypass various paywalls

[Andres Salomon]

Package: wnpp
Severity: wishlist
Owner: Andres Salomon 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: bypass-paywalls-firefox-clean
  Version : 3.3.5.0
  Upstream Contact: https://gitlab.com/magnolia1234
* URL : 
https://gitlab.com/magnolia1234/bypass-paywalls-firefox-clean
* License : MIT
  Programming Lang: Javascript 
  Description : Firefox browser plugin to bypass various paywalls

Add-on allows you to read articles from (supported) sites that implement a
paywall. You can also add a domain as custom site and try to bypass the
paywall.
.
Note: this plugin may leak information about your web browsing based on the
techniques used to bypass paywalls. For example, for some sites it will load
text from Google's webcache, thereby letting Google know that you read a
certain article. The plugin only operates on sites that you opt-into.


I use this package on both firefox and chromium, and would welcome this
to be co-maintained by Debian Mozilla Extension Maintainers if they're
interested. I've already got a working package, but I'm still trying to
figure out whether we really need separate source packages for the firefox
and chromium plugins.

Bug#1053255: mozilla-devscripts: dh_webext shouldn't look in .pc for manifest.json

[Andres Salomon]

Package: mozilla-devscripts
Version: 0.54.2+nmu1

While building a package using dh_webext, I noticed the following 
warning/error:


dh_webext: Found != 1 manifest.json, source PATH set to .

I was a bit confused because there's only one manifest.json file, but 
it turns out that the find command sees the following:


find . -name manifest.json -not -path './debian/*'
./manifest.json
./.pc/applications.patch/manifest.json

I have a quilt patch called debian/patches/applications.patch that 
modifies manifest.json. As such, when the package builds it creates 
that manifest.json file in the .pc directory. dh_webext shouldn't be 
picking that up; it should be ignoring everything in .pc.


I suggest the following command instead:
find . -name manifest.json -not -path './debian/*' -not -path './.pc/*'

In the script, that would look like this:
   candidates = subprocess.check_output(
   ["find", ".", "-name", "manifest.json", "-not", "-path", 
'./debian/*', "-not", "-path", './.pc/*'])

Bug#1053142: freetype proposed update breaks chromium

[Andres Salomon]

On Fri, Sep 29 2023 at 10:23:25 PM +10:00:00, Hugh McMaster 
 wrote:

Control: reassign 1053142 libfreetype6 2.12.1+dfsg-5+deb12u1

On Fri, 29 Sep 2023 10:37:22 +0200 Cord Beermann wrote:

 Hi,

 just wanted to give you a heads up on
 

 For me all chromium-Packages on stable die with a Segmentation 
Fault when

 libfreetype6 2.12.1+dfsg-5+deb12u1 is installed.

 Downgrading libfreetype6 to 2.12.1+dfsg-5 fixes it again.

 tested with chromium 114.0.5735.198-1~deb12u1, 
116.0.5845.180-1~deb12u1,

 117.0.5938.62-1~deb12u1

 Cord


Thanks. This is due to a bug in Chromium and a bug in FreeType.

I'm reverting the recent patch to FreeType to get Chromium going
again. The correct fix for FreeType has also been tested and verified,
and will be considered for bookworm after this weekend's 12.2 point
release.

Hugh


Just FYI, I uploaded a fixed chromium to bookworm-security yesterday. 
Whenever it finishes building,
the security team should issue the DSA and it should show up on 
mirrors.



https://salsa.debian.org/chromium-team/chromium/-/blob/bookworm/debian/changelog
https://salsa.debian.org/chromium-team/chromium/-/blob/bookworm/debian/patches/bookworm/freetype-COLRV1.patch

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

[Andres Salomon]

Thanks! Can we also roll that fix into the freetype bookworm p-u? Looks 
pretty simple to me; just ensuring that sfnt->get_colr_glyph_paint 
isn't NULL before calling it.




On Thu, Sep 28 2023 at 11:33:45 AM -04:00:00, Ben Wagner 
 wrote:

I have been able to figure out what is going on. The crash is due to a
typo in FreeType which was recently fixed [0]. This change is also
needed. I can confirm in a local build that with this typo fix the
reported Chromium crash (in libfreetype.so.6) is fixed. To be clear,
this FreeType change [0] is needed in addition to the the COLRv1
disable [1].

[0] 
<https://gitlab.freedesktop.org/freetype/freetype/-/commit/16f311d72582c117796a23e22074fe9624760ee1>
[1] 
<https://salsa.debian.org/debian/freetype/-/commit/f65637c7f84fa2ccfb14c11d0ed0f315fe83636d>


On Thu, Sep 28, 2023 at 10:36 AM Ben Wagner <mailto:bunge...@chromium.org>> wrote:


 I will take a look into this, but I am confused.
 FT_Get_Color_Glyph_Paint cannot be NULL as it is a regular exported
 function. This change will affect its behavior to always return 0
 (false) but that often happens anyway even without this change (most
 fonts don't have COLRv1 tables). For now it's fine to to revert the
 change as the original issue does not currently affect many users, 
but

 it is an issue that will need to be addressed.

 On Thu, Sep 28, 2023 at 10:22 AM Hugh McMaster <mailto:h...@debian.org>> wrote:

 >
 > On Thu, 28 Sep 2023 at 21:44, Hugh McMaster wrote:
 >>
 >> Hi Andres,
 >>
 >> On Thu, 28 Sept 2023 at 18:49, Andres Salomon wrote:
 >> >
 >> > Control: affects -1 chromium
 >> >
 >> >
 >> > On Thu, 28 Sep 2023 01:24:00 +0900 SuperCat wrote:
 >> > > Hi,
 >> > >
 >> > > In chromium source code, function 
SkScalerContext::GlyphMetrics

 >> > > SkScalerContext_FreeType::generateMetrics() will call
 >> > > FT_Get_Color_Glyph_Paint() if macro TT_SUPPORT_COLRV1 
exists. Somehow
 >> > > FT_Get_Color_Glyph_Paint will be a NULL pointer if this 
patch applied, and

 >> > > chromium will not be able to run.
 >> >
 >> >
 >> > This smells like an ABI change that doesn't really seem 
appropriate for a point release update. I can patch 
TT_SUPPORT_COLRV1 out of bookworm's Chromium, but I wonder if any 
other packages are using it on bookworm?

 >> >
 >> > For the record, Skia has the following code:
 >> >
 >> > #ifdef TT_SUPPORT_COLRV1
 >> >
 >> > // So undefine TT_SUPPORT_COLRV1 before 2.11.1 but not if 
FT_STATIC_CAST is defined.

 >> > #if (((FREETYPE_MAJOR)  < 2) || \
 >> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR)  < 11) || \
 >> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) == 11 && 
(FREETYPE_PATCH) < 1)) && \

 >> > !defined(FT_STATIC_CAST)
 >> > #undef TT_SUPPORT_COLRV1
 >> >
 >> >
 >> > So on bullseye (with freetype 2.10) it doesn't try to use 
COLRV1. On sid (with freetype 2.13) it will use COLRV1. If 
freetype's COLRV1 is going to remain disabled on bookworm via the 
proposed-update (with chromium being the only broken package), then 
I'll probably just bump that version check to only allow 
TT_SUPPORT_COLRV1 with FREETYPE_MINOR >= 13.

 >>
 >> FreeType 2.12.1 was released with experimental COLRv1 support 
enabled.
 >> This was unintentional, as the implementation shipped in this 
release

 >> was incomplete and incompatible with the final COLRv1 API.
 >>
 >> Upstream's intention was to enable COLRv1 support in FreeType 
2.13.0,

 >> which has a stable and complete COLRv1 API.
 >>
 >> I'm surprised Chromium actually used an experimental API, 
although

 >> this version check copied above seems like a bug.
 >>
 >> Grepping for TT_SUPPORT_COLRV1 yields a small number of packages.
 >> firefox*, godot and paraview are fine. Most of the openjdk-* 
packages

 >> aren't in bookworm.
 >
 >
 > After discussing the timing of Debian 12.2 with a release 
manager, I’ll revert the change shortly.

 >
 > Hugh

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

[Andres Salomon]

Control: affects -1 chromium


On Thu, 28 Sep 2023 01:24:00 +0900 SuperCat  
wrote:

> Hi,
>
> In chromium source code, function SkScalerContext::GlyphMetrics
> SkScalerContext_FreeType::generateMetrics() will call
> FT_Get_Color_Glyph_Paint() if macro TT_SUPPORT_COLRV1 exists. Somehow
> FT_Get_Color_Glyph_Paint will be a NULL pointer if this patch 
applied, and

> chromium will not be able to run.


This smells like an ABI change that doesn't really seem appropriate for 
a point release update. I can patch TT_SUPPORT_COLRV1 out of bookworm's 
Chromium, but I wonder if any other packages are using it on bookworm?


For the record, Skia has the following code:

#ifdef TT_SUPPORT_COLRV1

// So undefine TT_SUPPORT_COLRV1 before 2.11.1 but not if 
FT_STATIC_CAST is defined.

#if (((FREETYPE_MAJOR)  < 2) || \
((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR)  < 11) || \
((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) == 11 && 
(FREETYPE_PATCH) < 1)) && \

   !defined(FT_STATIC_CAST)
#undef TT_SUPPORT_COLRV1


So on bullseye (with freetype 2.10) it doesn't try to use COLRV1. On 
sid (with freetype 2.13) it will use COLRV1. If freetype's COLRV1 is 
going to remain disabled on bookworm via the proposed-update (with 
chromium being the only broken package), then I'll probably just bump 
that version check to only allow TT_SUPPORT_COLRV1 with FREETYPE_MINOR 
>= 13.

Bug#1051998: chromium: please to add support for riscv64

[Andres Salomon]

Hi,

Have these patches been submitted upstream? If so, what's the status? 
If not, why not?


BTW, quickly looking at those patches - when sending it upstream, I 
suspect that the #ifdef around the stddef.h should either be removed 
(stddef.h is available everywhere and if size_t requires it, size_t 
requires it), or that whole #include removed (there's no usage of 
size_t anywhere in the header).



On Fri, Sep 15 2023 at 10:44:44 PM +08:00:00, Bo YU 
 wrote:

Source: chromium
Version: 116.0.5845.180-1
Severity: wishlist
Tags: ftbfs patch moreinfo
User: debian-ri...@lists.debian.org 


Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org 



Dear Maintainer,

Now the chromium can be built[0] on Debian riscv64 with the attached 
patch.

And it seems it works to visit youtube or bilibili on my Unmatched
board with below arguments:

chromium --no-sandbox --use-gl=egl

But the patch can not be accepted by now because:

The patch will conflict with ppc's patch and it can not be maintained 
by

rebasing code on ppc patch. In fact, the patch of riscv64 looks like
small and maintenance easily independent. I would like to follow your
advice that how to deal with the situation.

My initial thought is that applying the ppc/riscv64 patch based on
$(DEB_HOST_ARCH_CPU). Sure, this may require a tricky scripts to do 
so.

I will try my best not to break workflow for all maintainers of
chromium and I will maintain these patch until Chromium upstream 
support

the riscv64 totally.

Once ready, I will remove the moreinfo tag.

Thanks for all the help porting/backport the chromium riscv64 patch 
from

distro like[1]&[2] and developers.

[0]: 

[1]: 

[2]: 



--
Regards,
--
  Bo YU

Bug#1051787: Subject: CVE-2023-4863: Heap buffer overflow in WebP

[Andres Salomon]

reassign 1051787 libwebp
thanks


Actually I'm mistaken, we're building against the system libwebp so 
there's no need to update chromium at all for this CVE. The webp fix is 
the only (linux) change that chromium made between .180 and .187.





On Tue, Sep 12 2023 at 11:34:26 AM -04:00:00, Andres Salomon 
 wrote:

clone 1051787 -1
reassign -1 libwebp
thanks

This bug's actually in libwebp. Unfortunately we're still embedding 
it in chromium, so we likely need to fix both chromium *and* libwebp 
in debian. There hasn't been a libwebp release yet, but the two 
relevant git commits are

<https://chromium.googlesource.com/webm/libwebp.git/+/902bc9190331343b2017211debcec8d2ab87e17a%5E%21/>
and what appears to be a followup fix to that,
<https://chromium.googlesource.com/webm/libwebp.git/+/95ea5226c870449522240ccff26f0b006037c520%5E%21/#F0>


On Tue, Sep 12 2023 at 09:12:40 AM -06:00:00, Jeffrey Cliff 
 wrote:

Package: chromium
Version: 116.0.5845.180-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team <mailto:t...@security.debian.org>>


Dear Maintainer,

116.0.5845.187 fixes a critical remote vulnerability in chrome

[$NA][1479274] Critical CVE-2023-4863: Heap buffer overflow in WebP.
Reported by Apple Security Engineering and Architecture (SEAR) and 
The Citizen

Lab at The University of Torontoʼs Munk School on 2023-09-06

<https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop_11.html>

Might want to look into this at least

(attempt 3, my reportbug broke sorry)

Jeff Cliff

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-debug'), (500,
'oldstable-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-gnulibre (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled


Versions of packages chromium depends on:
pn  chromium-common
ii  libasound2 1.2.9-2
ii  libatk-bridge2.0-0 2.49.91-2
ii  libatk1.0-02.49.91-2
ii  libatomic1 13.2.0-3
ii  libatspi2.0-0  2.49.91-2
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.37-7
ii  libcairo2  1.17.8-3
ii  libcups2   2.4.2-5
ii  libdbus-1-31.14.10-1devuan1
ii  libdouble-conversion3  3.3.0-1
ii  libdrm22.4.115-1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-2
ii  libflac12  1.4.3+ds-2
ii  libfontconfig1 2.14.2-5
ii  libfreetype6   2.13.2+dfsg-1
ii  libgbm123.1.7-1
ii  libgcc-s1  13.2.0-3
ii  libglib2.0-0   2.77.3-1
ii  libgtk-3-0 3.24.38-4
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-6
ii  liblcms2-2 2.14-2
ii  libminizip11:1.2.13.dfsg-3
ii  libnspr4   2:4.35-1.1
ii  libnss32:3.92-1
pn  libopenh264-7  
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.4-1
ii  libpango-1.0-0 1.51.0+ds-2
ii  libpng16-161.6.40-1
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.10-1
ii  libstdc++6 13.2.0-3
ii  libwebp7   1.2.4-0.2
ii  libwebpdemux2  1.2.4-0.2
ii  libwebpmux31.2.4-0.2
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.6-1
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.3
ii  libxnvctrl0525.125.06-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages chromium recommends:
pn  chromium-sandbox  

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Bug#1051787: Subject: CVE-2023-4863: Heap buffer overflow in WebP

[Andres Salomon]

clone 1051787 -1
reassign -1 libwebp
thanks

This bug's actually in libwebp. Unfortunately we're still embedding it 
in chromium, so we likely need to fix both chromium *and* libwebp in 
debian. There hasn't been a libwebp release yet, but the two relevant 
git commits are


and what appears to be a followup fix to that,



On Tue, Sep 12 2023 at 09:12:40 AM -06:00:00, Jeffrey Cliff 
 wrote:

Package: chromium
Version: 116.0.5845.180-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team >


Dear Maintainer,

116.0.5845.187 fixes a critical remote vulnerability in chrome

[$NA][1479274] Critical CVE-2023-4863: Heap buffer overflow in WebP.
Reported by Apple Security Engineering and Architecture (SEAR) and 
The Citizen

Lab at The University of Torontoʼs Munk School on 2023-09-06



Might want to look into this at least

(attempt 3, my reportbug broke sorry)

Jeff Cliff

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-debug'), (500,
'oldstable-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-gnulibre (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled


Versions of packages chromium depends on:
pn  chromium-common
ii  libasound2 1.2.9-2
ii  libatk-bridge2.0-0 2.49.91-2
ii  libatk1.0-02.49.91-2
ii  libatomic1 13.2.0-3
ii  libatspi2.0-0  2.49.91-2
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.37-7
ii  libcairo2  1.17.8-3
ii  libcups2   2.4.2-5
ii  libdbus-1-31.14.10-1devuan1
ii  libdouble-conversion3  3.3.0-1
ii  libdrm22.4.115-1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-2
ii  libflac12  1.4.3+ds-2
ii  libfontconfig1 2.14.2-5
ii  libfreetype6   2.13.2+dfsg-1
ii  libgbm123.1.7-1
ii  libgcc-s1  13.2.0-3
ii  libglib2.0-0   2.77.3-1
ii  libgtk-3-0 3.24.38-4
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-6
ii  liblcms2-2 2.14-2
ii  libminizip11:1.2.13.dfsg-3
ii  libnspr4   2:4.35-1.1
ii  libnss32:3.92-1
pn  libopenh264-7  
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.4-1
ii  libpango-1.0-0 1.51.0+ds-2
ii  libpng16-161.6.40-1
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.10-1
ii  libstdc++6 13.2.0-3
ii  libwebp7   1.2.4-0.2
ii  libwebpdemux2  1.2.4-0.2
ii  libwebpmux31.2.4-0.2
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.6-1
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.3
ii  libxnvctrl0525.125.06-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages chromium recommends:
pn  chromium-sandbox  

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Bug#1051355: Processed: your mail

[Andres Salomon]

On Mon, Sep 11 2023 at 03:27:30 PM -03:00:00, Leandro Cunha 
 wrote:
On Mon, Sep 11, 2023 at 4:07 AM Andres Salomon <mailto:dilin...@queued.net>> wrote:


 So apparently it's already fixed in sid and trixie:

 
<https://tracker.debian.org/news/1454349/accepted-llvm-toolchain-16-11606-11-source-into-unstable/>


 Bug didn't get closed because of the missing "(closes: " in that 
changelog entry. I'll push the clang-16 stuff to git so you can give 
it a test build on ppc.


 On Mon, Sep 11 2023 at 12:37:39 AM -05:00:00, Timothy Pearson 
<mailto:tpear...@raptorengineering.com>> wrote:


 For 16 to work we'll need the Debian clang team to include this 
patchset: <https://reviews.llvm.org/D158066> Any chance of that 
happening? - Original Message -


 From: "Andres Salomon" <mailto:dilin...@queued.net>> To: "Leandro Cunha" 
mailto:leandrocunha...@gmail.com>>, 
1051...@bugs.debian.org <mailto:1051...@bugs.debian.org> Cc: 
"Timothy Pearson" <mailto:tpear...@raptorengineering.com>> Sent: Sunday, September 10, 
2023 11:43:18 PM Subject: Re: Bug#1051355: Processed: your mail


 Alright, I built 117 w/ clang-16 on sid and it doesn't segfault. 
Same exact build but with clang-14 segfaults. Timothy, did you ever 
get the ppc64 issues with clang >= 15 squared away? It's looking 
like I'm going to need to upload a build with clang-16. On Sun, Sep 
10 2023 at 03:07:29 PM -03:00:00, Leandro Cunha 
mailto:leandrocunha...@gmail.com>> wrote:


 Hi, Em dom., 10 de set. de 2023 15:01, Andres Salomon 
mailto:dilin...@queued.net> 
<<mailto:dilin...@queued.net>>> escreveu:


 Unfortunately 117 *also* segfaults on sid. I'm tempted to try a 
newer clang, but probably not 15 since debian's planning to remove 
it. 16, I guess?


 Arch is already with Clang 16 and I tested Chromium 117 in a vm 
that I installed here and it was working normally.


So we already have this version on unstable? I saw it in experimental.
<https://metadata.ftp-master.debian.org/changelogs//main/l/llvm-defaults/llvm-defaults_0.57~exp4_changelog>



That's just the defaults package, which we don't really care about. 
Because we're dealing with different compilers across different 
distributions, we're hardcoding the specific clang version for each 
distribution's build.

Bug#1051355: Processed: your mail

[Andres Salomon]

So apparently it's already fixed in sid and trixie:

<https://tracker.debian.org/news/1454349/accepted-llvm-toolchain-16-11606-11-source-into-unstable/>

Bug didn't get closed because of the missing "(closes: " in that 
changelog entry. I'll push the clang-16 stuff to git so you can give it 
a test build on ppc.


On Mon, Sep 11 2023 at 12:37:39 AM -05:00:00, Timothy Pearson 
 wrote:
For 16 to work we'll need the Debian clang team to include this 
patchset:


<https://reviews.llvm.org/D158066>

Any chance of that happening?

----- Original Message -
 From: "Andres Salomon" <mailto:dilin...@queued.net>>
 To: "Leandro Cunha" <mailto:leandrocunha...@gmail.com>>, 1051...@bugs.debian.org 
<mailto:1051...@bugs.debian.org>
 Cc: "Timothy Pearson" <mailto:tpear...@raptorengineering.com>>

 Sent: Sunday, September 10, 2023 11:43:18 PM
 Subject: Re: Bug#1051355: Processed: your mail


 Alright, I built 117 w/ clang-16 on sid and it doesn't segfault. 
Same

 exact build but with clang-14 segfaults.

 Timothy, did you ever get the ppc64 issues with clang >= 15 squared
 away? It's looking like I'm going to need to upload a build with
 clang-16.

 On Sun, Sep 10 2023 at 03:07:29 PM -03:00:00, Leandro Cunha
 mailto:leandrocunha...@gmail.com>> 
wrote:

 Hi,

 Em dom., 10 de set. de 2023 15:01, Andres Salomon
 mailto:dilin...@queued.net> 
<<mailto:dilin...@queued.net>>> escreveu:

 Unfortunately 117 *also* segfaults on sid.

 I'm tempted to try a newer clang, but probably not 15 since 
debian's

 planning to remove it. 16, I guess?


 Arch is already with Clang 16 and I tested Chromium 117 in a vm 
that

 I installed here and it was working normally.

Bug#1051355: Processed: your mail

[Andres Salomon]

Alright, I built 117 w/ clang-16 on sid and it doesn't segfault. Same 
exact build but with clang-14 segfaults.


Timothy, did you ever get the ppc64 issues with clang >= 15 squared 
away? It's looking like I'm going to need to upload a build with 
clang-16.


On Sun, Sep 10 2023 at 03:07:29 PM -03:00:00, Leandro Cunha 
 wrote:

Hi,

Em dom., 10 de set. de 2023 15:01, Andres Salomon 
mailto:dilin...@queued.net>> escreveu:

Unfortunately 117 *also* segfaults on sid.

I'm tempted to try a newer clang, but probably not 15 since debian's 
planning to remove it. 16, I guess?


Arch is already with Clang 16 and I tested Chromium 117 in a vm that 
I installed here and it was working normally.

Bug#1051355: Processed: your mail

[Andres Salomon]

Unfortunately 117 *also* segfaults on sid.

I'm tempted to try a newer clang, but probably not 15 since debian's 
planning to remove it. 16, I guess?


On Fri, Sep 8 2023 at 05:36:17 PM -03:00:00, Leandro Cunha 
 wrote:

Hi,

On Fri, Sep 8, 2023 at 4:39 PM Andres Salomon <mailto:dilin...@queued.net>> wrote:




 On Fri, Sep 8 2023 at 03:31:37 PM -03:00:00, Leandro Cunha 
mailto:leandrocunha...@gmail.com>> wrote:


 Hi, On Fri, Sep 8, 2023 at 10:03 AM Debian Bug Tracking System 
mailto:ow...@bugs.debian.org>> wrote:


 Processing commands for cont...@bugs.debian.org 
<mailto:cont...@bugs.debian.org>: > affects 1051355 phpsysinfo 
phpldapadmin jquery-timepicker Bug #1051355 [chromium] chromium: 
Segmentation fault Added indication that 1051355 affects phpsysinfo, 
phpldapadmin, and jquery-timepicker > stop Stopping processing here. 
Please contact me if you need assistance. -- 1051355: 
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051355> Debian 
Bug Tracking System Contact ow...@bugs.debian.org 
<mailto:ow...@bugs.debian.org> with problems


 Apparently this should have been fixed in version 117.0.5938.48-1, 
if you want to release this version in beta stage as a distro they 
are making which is Arch and we can test it on Debian. 
<https://archlinux.org/packages/extra/x86_64/chromium/> 
<https://repology.org/project/chromium/versions>

 --
 Cheers, Leandro Cunha



 Do you have a crbug or commit or something that fixes it? I haven't 
started on 117 yet, and I also haven't really had time to debug this 
sid-specific 116 crash (other than building with downgraded packages 
from 9/1 and still getting the crash). This was a bad week for 
finding free time.


 Tim, I don't suppose you've looked at 117 yet? There's an early 
release out.





This version is expected to be released on September 12th and we can
wait. I believe it must have also been compiled for Linux with the
current changes.
<https://chromiumdash.appspot.com/schedule>

--
Cheers,
Leandro Cunha

Bug#1051575: brotli: please package new upstream release

[Andres Salomon]

Package: brotli
Version: 1.0.9-2
Severity: wishlist

Chromium fails to build against the version of brotli that's in Debian, 
as it started requiring BrotliDecoderAttachDictionary 
(). 
I can revert that for now, but it would be great to get an updated 
broli in Debian.


Brotli 1.1.0 was released last week. Please consider packaging it.

Thanks,
Andres

Bug#1051557: RFP: siso -- experimental build tool that aims to replace ninja

[Andres Salomon]

Package: wnpp
Severity: wishlist

Chromium has started replacing ninja with Siso. I don't have the time 
right now to package or even play with it, but if it's everything that 
the README promises then I suspect it would be useful to have it in the 
archive for others to use.





I don't see a dedicated LICENSE file yet, but source headers mention 
that it's under the same license as chromium:
// Use of this source code is governed by a BSD-style license that can 
be// found in the LICENSE file.


Siso is an experimental build tool (written in Go) that aims to 
significantly speed up Chromium's build.


It is a drop-in replacement for Ninja, which means it can be easily 
used instead of Ninja without requiring a migration or change in 
developer's workflows.It runs build actions on RBE natively, and falls 
back to local.It avoids stat, disk and network I/O as much as 
possible.It reduces CPU usage and memory consumption by sharing in one 
process memory space.It collects performance metrics for each action 
during a build and allows to analyze them using cloud trace/cloud 
profiler.

Bug#1051355: Processed: your mail

[Andres Salomon]

On Fri, Sep 8 2023 at 03:31:37 PM -03:00:00, Leandro Cunha 
 wrote:

Hi,

On Fri, Sep 8, 2023 at 10:03 AM Debian Bug Tracking System
mailto:ow...@bugs.debian.org>> wrote:


 Processing commands for cont...@bugs.debian.org 
:


 > affects 1051355 phpsysinfo phpldapadmin jquery-timepicker
 Bug #1051355 [chromium] chromium: Segmentation fault
 Added indication that 1051355 affects phpsysinfo, phpldapadmin, and 
jquery-timepicker

 > stop
 Stopping processing here.

 Please contact me if you need assistance.
 --
 1051355: 
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org  with 
problems


Apparently this should have been fixed in version 117.0.5938.48-1, if
you want to release this version in beta stage as a distro they are
making which is Arch and we can test it on Debian.



--
Cheers,
Leandro Cunha



Do you have a crbug or commit or something that fixes it?  I haven't 
started on 117 yet, and I also haven't really had time to debug this 
sid-specific 116 crash (other than building with downgraded packages 
from 9/1 and still getting the crash). This was a bad week for finding 
free time.


Tim, I don't suppose you've looked at 117 yet? There's an early release 
out.

Bug#1043311: [Pkg-rust-maintainers] Bug#1043311: rustc: please enable profiler builtin

[Andres Salomon]

On Fri, Sep 8 2023 at 10:36:48 AM +02:00:00, Fabian Grünbichler 
 wrote:

 On Tue, Aug 8 2023 at 06:22:28 PM -04:00:00, Andres Salomon


[...]


 This patch adds 
"cargo:rustc-link-search=/usr/lib/clang/15/lib/linux/" and

 "cargo:rustc-link-lib=static=clang_rt.profile-x86_64" (or whatever
 architecture it happens to be building on) to the profiler_builtins 
build
 flags when the target matches the host. In the case where the 
target is

 different from the host, it assumes a wasm build and sets
 "rustc-link-lib=static=clang_rt.builtins-wasm32" or
 "cargo:rustc-link-lib=static=clang_rt.builtins-wasm64" depending 
upon

 whether the target is 32 or 64 bits, respectively.


Thanks for the patch! the Windows part in d/rules looks wrong to me -
that is built with mingw, not wasi. I assume you are not interested in
that part, so maybe it would also be an option to guard it based on
target and just build it for the regular one (or regular+wasm, but not
windows/mingw)?


Yeah, I don't really care about that part - I was just trying to guess 
about what was 'correct'.

Bug#1051355: chromium: Segmentation fault

[Andres Salomon]

Downgrading to 116.0.5845.140-1 worked, so on a hunch I rebuilt .140-1 
against current sid and.. it crashes immediately the same way. So 
something in sid that we depend on changed between 8/31 and 9/6 that is 
causing this crash. Unfortunately no useful backtrace, so I'm guessing 
something compiler-related but I haven't dug further into it.





On Wed, Sep 6 2023 at 04:23:31 PM -03:00:00, Leandro Cunha 
 wrote:

Package: chromium
Version: 116.0.5845.180-1
Severity: grave
Justification: Renders package unusable

Dear Maintainer,

Your package is currently unusable, making it impossible to use it.
Please consider fixing this so other users can use it normally.
Thanks.
Just reiterating that the browser doesn't even open in Gnome 44 with 
Wayland.

The output in the terminal is as follows:
[4562:4562:0906/161027.517475:ERROR:chrome_browser_cloud_management_controller.cc(163)]
Cloud management controller initialization aborted as CBCM is not
enabled.
[4562:4590:0906/161028.019651:ERROR:nss_util.cc(357)] After loading
Root Certs, loaded==false: NSS error code: -8018
[0906/161028.521029:ERROR:elf_dynamic_array_reader.h(64)] tag not 
found

Falha de segmentação

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE

Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common
116.0.5845.180-1

ii  libasound2 1.2.9-2
ii  libatk-bridge2.0-0 2.49.91-2
ii  libatk1.0-02.49.91-2
ii  libatomic1 13.2.0-2
ii  libatspi2.0-0  2.49.91-2
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.37-7
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-5
ii  libdbus-1-31.14.10-1
ii  libdouble-conversion3  3.3.0-1
ii  libdrm22.4.115-1
ii  libevent-2.1-7 
2.1.12-stable-8

ii  libexpat1  2.5.0-2
ii  libflac12  1.4.3+ds-2
ii  libfontconfig1 2.14.2-4
ii  libfreetype6   
2.13.2+dfsg-1

ii  libgbm123.1.6-1
ii  libgcc-s1  13.2.0-2
ii  libglib2.0-0   2.77.2-1
ii  libgtk-3-0 3.24.38-4
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-6
ii  liblcms2-2 2.14-2
ii  libminizip1
1:1.2.13.dfsg-3

ii  libnspr4   2:4.35-1.1
ii  libnss32:3.92-1
ii  libopenh264-7  
2.3.1+dfsg-3

ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.4-1
ii  libpango-1.0-0 1.51.0+ds-2
ii  libpng16-161.6.40-1
ii  libpulse0  
16.1+dfsg1-2+b1

ii  libsnappy1v5   1.1.10-1
ii  libstdc++6 13.2.0-2
ii  libwebp7   1.2.4-0.2
ii  libwebpdemux2  1.2.4-0.2
ii  libwebpmux31.2.4-0.2
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.6-1
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   
2:1.3.4-1+b1

ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml2  

Bug#1041695: chromium: Crash when starting with --incognito option

[Andres Salomon]

Looks like you're missing function names from that backtrace - do you 
have chromium-dbgsym installed?




If you're running debian stable, you'd want to add "deb 
 proposed-updates-debug main" to 
your /etc/apt/sources.list, and then run 'apt install chromium-dbgsym 
chromium-common-dbgsym'


And if you need to temporarily downgrade chromium because the version 
in proposed-updates-debug isn't new enough, you can do something like 
'apt install chromium=115.0.5790.170-1~deb12u1 
chromium-common=115.0.5790.170-1~deb12u1' to downgrade.


Once you have the debugging symbol packages installed, if you grab that 
backtrace again it should be useable.


On Mon, Aug 21 2023 at 08:10:10 PM +00:00:00, Maxime Silvier 
 wrote:
I have taken a closer look at the issue with `chromium -g` command 
— by the way, it is still present in 
chromium=116.0.5845.96-1~deb12u1 but this log was from the 115.0.X 
version.
I hope I did not omit anything useful (the original log file had more 
than 600 lines).


Best regards.

- - -

# Env:
# LD_LIBRARY_PATH=
#
PATH=/home/maxim/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

#GTK_PATH=
#  CHROMIUM_FLAGS= --show-component-extension-options 
--enable-gpu-rasterization --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions 
--load-extension=/usr/share/chromium/extensions/keepassxc-browser,/usr/share/chromium/extensions/privacy-badger,/usr/share/chromium/extensions/ublock-origin

/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.5Cvn6Q

Reading symbols from /usr/lib/chromium/chromium...
(No debugging symbols found in /usr/lib/chromium/chromium)
[?2004h(gdb) handle SIG33 pass nostop noprint
handle SIG33 pass nostop noprint
[?2004l
SignalStop  Print   Pass to program Description
SIG33 NoNo  Yes Real-time event 33
[?2004h(gdb) set pagination 0
set pagination 0
[?2004l
[?2004h(gdb) run --icncognito
[?2004l
Starting program: /usr/lib/chromium/chromium --incognito
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".

[Detaching after fork from child process 4900]
[New Thread 0x719ff6c0 (LWP 4905)]
[Detaching after fork from child process 4906]
[Detaching after fork from child process 4907]
[Detaching after fork from child process 4908]
[New Thread 0x711fe6c0 (LWP 4911)]
[New Thread 0x701ff6c0 (LWP 4912)]
[New Thread 0x7fffef9fe6c0 (LWP 4913)]
[New Thread 0x7fffef1fd6c0 (LWP 4914)]
[New Thread 0x7fffee9fc6c0 (LWP 4915)]
[New Thread 0x7fffed9fa6c0 (LWP 4916)]
[New Thread 0x7fffee1fb6c0 (LWP 4917)]
[New Thread 0x7fffed1f96c0 (LWP 4918)]
[New Thread 0x7fffec9f86c0 (LWP 4919)]
[New Thread 0x7fffec1f76c0 (LWP 4920)]
[New Thread 0x7fffeafff6c0 (LWP 4921)]
[New Thread 0x7fffea7fe6c0 (LWP 4922)]
Gtk-Message: 11:50:40.232: Failed to load module "appmenu-gtk-module"
[New Thread 0x7fffe9ffd6c0 (LWP 4923)]
[Thread 0x7fffe9ffd6c0 (LWP 4923) exited]
[New Thread 0x7fffe9ffd6c0 (LWP 4924)]
[New Thread 0x7fffe97fc6c0 (LWP 4925)]
[New Thread 0x7fffe87fa6c0 (LWP 4927)]
[New Thread 0x7fffe8ffb6c0 (LWP 4926)]
[New Thread 0x7fffe7ff96c0 (LWP 4928)]
[New Thread 0x7fffe77f86c0 (LWP 4929)]
[New Thread 0x7fffe6fb76c0 (LWP 4930)]
[New Thread 0x7fffe67756c0 (LWP 4934)]
[Detaching after fork from child process 4935]
[4897:4897:0722/115040.316536:ERROR:chrome_browser_cloud_management_controller.cc(162)] 
Cloud management controller initialization aborted as CBCM is not 
enabled.

[New Thread 0x7fffe5e416c0 (LWP 4939)]
[New Thread 0x7fffe56406c0 (LWP 4944)]
[New Thread 0x7fffe4e3f6c0 (LWP 4945)]
[New Thread 0x7fffe45f26c0 (LWP 4960)]
[Detaching after fork from child process 4978]
[New Thread 0x7fffe3cf36c0 (LWP 4997)]

Thread 1 "chromium" received signal SIGSEGV, Segmentation fault.
0x576f956b in ?? ()
[?2004h[?2004l
[?2004h(gdb) bakcktrace
[?2004l
#0  0x576f956b in ?? ()
#1  0x in ?? ()
[?2004h(gdb) thread apply all backtrace
thread apply all backtrace
[?2004l

Bug#1043586: dnstwist: Failing autopkgtest with python3-selenium 4.11.2+dfsg-1

[Andres Salomon]

Control: affects -1 chromium


On Sun, 13 Aug 2023 12:31:13 +0200 Carsten Schoenert 
 wrote:

> Source: dnstwist
> Version: 0~20230509-1
> Severity: important
>
> Dear Maintainer,
>
> the autopkgtest of dnstwist is failing with the most recent version 
of

> python3-selenium.
>
> This is due a internal change in Selenium upstream since version 
4.11.0.
> Upstream is using a method/component called Selenium Manager since 
then
> and as we can't ship this due it's binary form calling 
webdriver.Chrome()
> needs to be extended about the information which driver needs to be 
used.

>

This is also going to cause chromium to fail to migrate to testing. (I 
say "going to" because chromium has other issues right now, but once 
those are fixed..)